Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

マルチクラウド戦略を成功に導くアーキテクチャ設計

By DoiTMay 17, 20226 min read

このページはEnglishDeutschEspañolFrançaisItalianoPortuguêsでもご覧いただけます。

マルチクラウドを成功させる鍵は、自社のアプリケーションworkloadポートフォリオに最適化したアーキテクチャを設計することです。本記事では、その指針となる分散型・冗長型のデプロイパターンを解説します。

multicloud-architecture

最適なデプロイパターンでマルチクラウド成功の基盤を築く

明確な目的を持ったマルチクラウド戦略は、企業のビジネス目標達成を力強く後押しします。ただし、マルチクラウドを使いこなすには、複数のクラウドサービスを一体化させるための洗練されたアーキテクチャ設計が欠かせません。自社固有のアプリケーションworkloadポートフォリオに合わせたカスタマイズが必要ですが、幸い、土台として活用できる代表的なパターンがいくつか存在します。

これらのパターンは、分散型または冗長型のいずれかのデプロイ方式に基づいています。

  • 分散型デプロイパターン:各コンピューティング環境が持つ特性や強みを活かし、アプリケーションを最適な環境で実行します。
  • 冗長型デプロイパターン:キャパシティや耐障害性を高めるために、同じアプリケーションを複数のコンピューティング環境にデプロイします。

分散型デプロイパターン

分散型パターンの狙いは、既存アプリケーションがもたらす制約への対応と、各コンピューティング環境ならではの強みの活用との両立にあります。パターンを選定する際は、俊敏性、拡張性、セキュリティ、信頼性といった観点を踏まえて検討することが重要です。

階層型ハイブリッド

階層型ハイブリッドのデプロイパターンでは、まず既存のフロントエンドアプリケーションをケースバイケースでパブリッククラウドに移し、既存のバックエンドアプリケーションはプライベートのコンピューティング環境に残したまま再利用します。とはいえ、クラウドにデプロイされるアプリケーションの比率は時間とともに高まるため、最終的にはバックエンドアプリケーションもパブリッククラウドへ移行することになるかもしれません。

フロントエンドを優先するのには明確な理由があります。フロントエンドはバックエンドに依存しますが、その逆は成り立たないからです。依存関係が少ないため、フロントエンドアプリケーションは一般にバックエンドよりも分離・移行が容易です。さらに、バックエンドよりも変更頻度が高く、クラウドの柔軟性を活かしやすいという利点もあります。クラウドを使えば、効率的かつ自動化されたアップデートを実現する継続的インテグレーション/継続的デプロイ(CI/CD)プロセスを容易に構築でき、ロードバランシング、マルチリージョンデプロイ、オートスケーリングといった機能でパフォーマンスも引き上げられます。

一方、厳格なコンプライアンス要件のあるデータを扱うバックエンドは、プライベート環境に残しておくほうが賢明な場合もあります。多くの国ではデータローカライゼーションが求められ、企業はデータを国内で保存・処理することが義務付けられています。たとえばEUのGDPR(一般データ保護規則)は個人データの保管について厳格な規定を設けており、オンプレミスでの対応が最適となるケースも少なくありません。

分割型マルチクラウド

分割型マルチクラウドパターンでは、異なるベンダーのパブリッククラウド環境間でworkloadsを移動させることができます。アプリケーションを最適なコンピューティング環境にデプロイする柔軟性を確保するうえで、workloadsのポータビリティは欠かせません。複数のコンピューティング環境間でworkloadsを行き来させるには、環境ごとの差異を抽象化しておく必要があります。

分割型マルチクラウドパターンの大きな利点は、特定のクラウドサービスプロバイダーに縛られず、ベンダーロックインを回避できる点にあります。必要に応じてworkloadsを別の環境に移せるため、障害によるダウンタイムのリスクを抑えられるうえ、各プロバイダーの強みとなる機能を選んで活用できます。

このパターンに必要なworkloadsポータビリティを確保しておけば、環境間でworkloadsを移すたびに運用を最適化することも可能になります。一方で、workloadsポータビリティには弱点もあります。追加の開発・テスト・運用の負担が発生するうえ、ポータビリティを優先しすぎると、クラウドプラットフォームの活用範囲が最大公約数的な機能にとどまり、クラウドプロバイダーのフルマネージドサービスを使えなくなる恐れもあります。さらに、Egressコストが急増する可能性も無視できません。

workloadsポータビリティを支えるのがコンテナ化であり、Kubernetesがその上で機能することで、企業はベンダーロックインの回避を進められます。

分析・MLハイブリッドおよびマルチクラウド

このパターンでは、トランザクショナルシステムをオンプレミスに残し、分析workloadsをクラウドにデプロイして、必要に応じてデータを連携させます。トランザクショナルシステムは、財務、コミュニケーション、営業などの日常業務を支える役割を担います。一方の分析workloadsは、意思決定に役立つインサイトを得るためにデータを処理・可視化するアプリケーションを指します。このパターンは両者を切り離し、それぞれを異なるコンピューティング環境で実行する点に特徴があります。

分析workloadsをクラウドで実行すれば、リソースを過剰にプロビジョニングするリスクを抱えずに、コンピューティングリソースを動的にスケールさせて膨大なデータを高速に処理できます。主要なクラウドプロバイダーは、データの取得からライフサイクル全体の管理までを網羅した包括的なサービスも提供しています。

エッジハイブリッド

クラウドでworkloadsを動かすには継続的なネットワーク接続が前提ですが、それが常に確保できるとは限りません。船舶、スーパーマーケット、一部の製造工場などはインターネットに安定して接続できない一方で、IoT(モノのインターネット)が活躍する重要な現場でもあります。組み込みセンサーやチップが有用なデータを送受信するには接続性が欠かせません。そこで有効なのがエッジハイブリッドパターンです。時間的・ビジネス的にクリティカルなworkloadsはネットワークのエッジでローカルに実行し、それ以外はクラウドで処理します。

クリティカルなworkloadsをローカルで動かすことで、低レイテンシと自己完結性が確保されます。インターネット接続が不安定でも、重要なトランザクションを止めずに処理し続けられます。同時に、workloadsの大半についてはクラウドの恩恵を引き続き享受できます。このパターンを効果的に機能させるには、エッジで動くシステムとクラウドで動くシステムとの依存関係をできる限り少なくすることが肝心です。

冗長型デプロイパターン

冗長型デプロイパターンは、キャパシティや耐障害性を高めるために、同じアプリケーションを複数のコンピューティング環境にデプロイする方式です。

ハイブリッド環境

ハイブリッド環境パターンは、冗長型にも分散型にもなり得ます。開発、テスト、UATにはパブリッククラウド環境を利用し、本番workloadsはプライベートデータセンターで稼働させます。規制やコンプライアンスの制約により、本番環境やそのデータのクラウド移行は難しくても、それ以外の環境であればハードルは大きく下がります。

パブリッククラウドを開発や機能テストに使えば、必要に応じて環境を立ち上げたり片付けたりできます。仮想マシンインスタンスを使用していないときに停止したり、必要なときだけオンデマンドで環境をプロビジョニングしたりすることで、コストもしっかり管理できます。

事業継続のためのハイブリッドおよびマルチクラウド

災害復旧(DR)計画は、自然災害や人為的災害によって被害を受けたシステムを復旧させるうえで欠かせません。中でも重要なのが、目標復旧時点(RPO)を最小化するために、地理的に離れた拠点へ頻繁にデータをバックアップすることです。さらに、第二の拠点でスタンバイシステム(レイテンシに応じてコールド、ウォーム、ホットの3段階)を維持しておけば、目標復旧時間(RTO)の短縮にもつながります。

とはいえ、よりコスト効率の高い選択肢は、DR環境としてパブリッククラウドを活用することです。これが事業継続ハイブリッドパターンです。Infrastructure as Codeを使えばDR環境を短時間で立ち上げられるため、いざDRが発動した際の実際の復旧時間まで縮められる可能性があります。

クラウドバースティング

バースト性の高いworkloadsをオンプレミスだけで運用しようとすると、ピーク時に備えてリソースを過剰にプロビジョニングする必要があるため、コストが一気に膨らみがちです。バースティングのデプロイパターンでは、平常時の負荷はプライベートのコンピューティング環境で処理し、スケールアップが必要なときだけクラウドにバーストさせます。そのため、インタラクティブなworkloadsよりもバッチworkloadsに向いています。ここでもworkloadsポータビリティが鍵となります。

このパターンの大きな魅力は、既存のオンプレミス環境への投資をそのまま活かせる点です。ピーク需要を見込んで余分にリソースを確保する必要がなくなるため、プライベートのコンピューティング環境をより効率的に運用できる可能性もあります。

次のステップ

ハイブリッドやマルチクラウドのソリューションを構築するうえでは、複雑な判断が求められます。中でも、最適なアーキテクチャの設計は避けて通れない課題です。判断を下す前に、自社の組織文化、DevOpsの実践状況、技術スタックを総合的に見極める必要があります。あらゆる要件を一度に満たす万能の技術ソリューションは存在しませんが、本記事で紹介した分散型・冗長型のデプロイパターンを応用することで、最適解に近づける可能性は十分にあります。経験豊富なクラウドパートナーがいれば、自社のビジネス目標に合わせたマルチクラウド活用の最適な進め方を共に描いていけるはずです。