クラウドへの道: 複雑な分析アプリケーションをクラウドに移行する

組織のクラウド コンピューティングの取り組みには通常、オンプレミスのアプリケーションをクラウドに移行するプロセスが含まれます。このプロセスにはいくつかの課題がありますが、最終的には多くのメリットがもたらされます。

[[349444]]

組織にとってワークロードをクラウド プラットフォームに移行するのは簡単な場合もありますが、オンプレミス サーバーを IaaS コンピューティング プラットフォームに移行できれば、さらにメリットが高まります。場合によっては、ワークロードをクラウドに移行することが組織にとってより困難になることがあります。たとえば、組織のワークロードに複数の層のインフラストラクチャとソフトウェアが関係していたり​​、詳細で複雑なプロビジョニング プロセスが必要な場合、クラウドへの移行ははるかに困難になる可能性があります。

ヘルスケアプロバイダー Optum のチーフエンジニアである Bill Schneider 氏は、最近の Interop 2020 のプレゼンテーション「私たちのクラウドの旅: レガシーアプリケーションの AWS への移行」で、これらの課題を乗り越えたチームの経験について語りました。 Schneider 氏は、彼と彼のチームがオンプレミスの分析アプリケーション (少なくともその大部分) を AWS クラウド プラットフォームに移行した方法、クラウド アーキテクチャを選択した理由、ワークロードを移行してから得られたメリットについて説明します。

ヘルスケアデータ分析ツールの開発と管理

シュナイダー氏と彼のチームは、オプタムの顧客が医療データを管理するのに役立つ OPA と呼ばれるアプリケーションを開発および管理しています。このアプリケーションにより、患者データを検索して分析し、医療費や受けたケアの質などの要素と相関関係を調べることができます。このアプリケーションは、Optum の従業員と顧客が使用する一般向けリソースです。

もともと、OPA は 4 つの主要コンポーネントで構成されるオンプレミス アプリケーションでした。これは、Optum が作成または収集した生データを保存するファイルから始まります。そこからデータは Oracle データ ウェアハウスに渡され、そこで処理および再編成されます。データ変換が完了すると、Oracle が提供するデータ マートに移動します。最後に、MicroStrategy 分析アプリケーションによってデータ マートからデータが抽出され、ユーザーのクエリが処理されます。

クラウドへの移行

現在、OPA は主にクラウド プラットフォームで実行されています。ただし、データ パイプラインはオンプレミスに保存されているデータから開始されますが、AWS S3 バケットにアップロードされ、その後 AWS Redshift に保存される前に保存されるため、オンプレミス コンポーネントはまだ存在します。 Redshift では、AWS クラウドでホストされている MicroStrategy アプリケーション インスタンスを通じてデータをクエリできます。

クラウドベースのパイプラインへのトラフィックは、Elastic Load Balancer (ELB) によって管理され、トラフィックをさまざまな MicroStrategy インスタンスにルーティングします。弾性ロードバランサ (ELB) を使用することで、Schneider 氏と彼のチームは証明書管理を簡素化できました。また、OPA アプリケーションに新しいクライアントを追加するときに DNS レコードを更新する必要もありません。

なぜクラウドの旅を始めるのでしょうか?

もともと OPA を動かしていたオンプレミス アーキテクチャにはいくつかの制限がありました。 Schneider 氏は、Oracle ソフトウェアのライセンス費用に加えて、エンドユーザーへのレポートの応答性を高めるためにメモリ内キャッシュに大きく依存していたため、アプリケーションはスケーリングの課題にも直面していたと指摘しました。したがって、より多くの顧客をサポートするには、シュナイダー氏とチームは、より多くの使用可能なメモリを備えたサーバーを追加する必要がありました。

OPA をクラウド プラットフォームに移行すると、両方の課題に対する解決策が提供されます。 Optum は、Oracle のデータ ウェアハウスおよびデータ マート ツールの代わりに AWS Redshift を使用することで、ソフトウェア ライセンス コストを削減しました。同時に、クラウド プラットフォームを使用すると、アプリケーションが最大 10 億行のデータを処理する場合でも、十分なパフォーマンスを確保するために、アプリケーション インスタンスにさらに多くのインフラストラクチャ リソースを割り当てることが容易になります。

アプリケーションをクラウド プラットフォームに移行した後に得られる 3 番目の利点は、完全に自動化されたオーケストレーションです。 Schneider 氏と彼のチームは、プロビジョニングと管理タスクを処理するために AWS Lambda でホストされているコードを呼び出す AWS Step Functions を実装しました。 「各ステップ機能は、『データ検索を実行する』や『リリースを展開する』といった高レベルのプロセスを表しています」とシュナイダー氏は説明した。 「これらのステップ関数は一連の Lambda を呼び出し、各 Lambda は AWS インフラストラクチャやセキュリティグループの設定などの個別のタスクを実行します。」

このアプローチでは、アプリケーション インスタンスを自動的にデプロイできるため、新しいアプリケーション環境を手動で立ち上げる必要がなくなります。シュナイダー氏は、これはアプリケーションのオンプレミス バージョンと比較して効率が大幅に向上することを意味すると述べています。オンプレミス バージョンでは、チームは一部の管理タスクを調整するために Puppet などの IaC ツールを使用しており、それ以外は手動のワークフローに依存しています。

クラウド移行の課題

シュナイダー氏は、OPA のクラウドへの道のりには浮き沈みがなかったわけではないと語った。主な課題の 1 つは、アプリケーション開発者が開発作業を実行するオンプレミスのワークステーションからクラウドベースの環境に安全に接続するための方法を見つけることです。これを実現するために、Optum は当初、特別なファイアウォール例外を作成する必要がありましたが、エンジニアが HTTPS 経由でクラウド内のコンピューターでコマンドを実行できるようにする AWS の SSM サービスも活用しました。

MicroStrategy のアプリケーションは、クラウド コンピューティングが標準になるずっと前から存在していましたが、高度に動的なアプリケーション スタックの一部として実行するようには設計されていませんでした。これによりいくつかの問題が発生しましたが、彼のチームはベンダーと協力して問題を解決することができました。

シュナイダー氏は、アプリケーションをクラウドに移行して以来、社内の技術的負債もオプタムにとってより差し迫った課題になっていると述べた。クラウドでは、技術的負債はパフォーマンス上の課題を引き起こすだけでなく、直接的なコストへの影響も生じます。今後、彼のチームにとっての重要な優先事項は、OPA の技術的な問題を継続的に特定して対処し、コストとパフォーマンスの両面でアプリケーションが可能な限り効率的であることを保証することです。

結論は

従来のアプリケーションはクラウド プラットフォーム専用ではありません。ホストされている仮想マシンに直接移動することができます。また、これは最初からクラウドで生まれたクラウド ネイティブ アプリケーションだけのものではありません。 Optum のクラウド ジャーニーのストーリーが示すように、組織は複雑な多層オンプレミス アプリケーションをクラウドに移行することで、スケーラビリティと自動化機能を最大限に活用できます。