ハイブリッドおよびマルチクラウドのアーキテクチャ パターン

この記事は、ハイブリッドおよびマルチクラウドのデプロイ、アーキテクチャ パターン、ネットワーク トポロジについて説明する、マルチパート シリーズのパート 2 です。このパートでは、一般的なハイブリッドおよびマルチクラウドのアーキテクチャ パターンについて説明します。これらのパターンが適するシナリオについて説明し、Google Cloud Platform(GCP)を使用してそれらのパターンを実装するためのベスト プラクティスを提示します。

シリーズは次のパートで構成されています。

ハイブリッドやマルチクラウドのアーキテクチャを設定するにあたり、要件および制約条件の元となるアプリケーション ワークロードは、企業ごとにそれぞれ異なります。これらの制約や要件を満たすようにアーキテクチャを設計し、調整する必要がありますが、適用できるパターンとしては、いくつかの一般的なパターンに整理できます。

パターンは 2 つのカテゴリに分類されます。

  • アプリケーションの分散デプロイに依存する一連のパターン。これらのパターンは、コンピューティング環境のさまざまなプロパティや特性を活用して、最適なコンピューティング環境でアプリケーションを実行する際に使用されます。

  • アプリケーションの冗長デプロイに基づく一連のパターン。これらのパターンでは、同じアプリケーションを複数のコンピューティング環境にデプロイし、容量や復元力を高めることを目指します。

分散デプロイ パターン

従来のコンピューティング環境からハイブリッド設定またはマルチクラウド設定に移行する際には、既存のアプリケーションによる制約を考慮します。また、各コンピューティング環境が提供するユニークな機能を最大限に活用することも目的となります。分散デプロイ パターンでは、これら両方の目的をバランスよく達成することを目指します。

階層型ハイブリッド

ほとんどの場合、アプリケーションはフロントエンドまたはバックエンドのいずれかに分類できます。

  • フロントエンド アプリケーションは、エンドユーザーまたはデバイスに直接に公開されます。そのため、フロントエンド アプリケーションでは、パフォーマンスが重視されることが多く、新機能の開発や製品の改良ごとに頻繁にリリースが繰り返される場合があります。フロントエンド アプリケーションは、データの保存と管理をバックエンド アプリケーションに依存するため、通常、ステートレスになり管理するデータも少量になります。

  • 一方、多くのバックエンド アプリケーションは、データの管理に重点を置きます。このようなアプリケーションの主な課題は、データを適切に処理し保護することです。バックエンド アプリケーションの新しいリリースの頻度は、フロントエンド アプリケーションよりも少なくなる傾向にあります。

階層型ハイブリッド パターンでは、まず既存のフロントエンド アプリケーションをパブリック クラウドへデプロイすることに焦点を当てます。このパターンでは、限定公開コンピューティング環境にすでに存在しているバックエンド アプリケーションが再利用されます。その際、フロントエンド アプリケーションの移行は状況に合わせて行います。

次の図は、典型的な階層型ハイブリッド パターンを示しています。

階層型ハイブリッド パターン

時間の経過とともに、パブリック クラウドにデプロイされるアプリケーションの割合が増え、それとともにバックエンド アプリケーションのパブリック クラウドへの移行が検討されます。

メリット

フロントエンド アプリケーションの移行に最初に焦点を当てることのメリットはいくつかあります。

  • フロントエンド アプリケーションは、通常バックエンド アプリケーションに依存します。他のフロントエンド アプリケーションに依存する場合もありますが、バックエンド アプリケーションがフロントエンド アプリケーションに依存することはありません。したがって、フロントエンド アプリケーションの分離や移行は、複雑な依存関係のあるバックエンド アプリケーションの移行ほど複雑ではありません。

  • 一方、フロントエンド アプリケーションは、ステートレスであるか、それ自身はデータを管理しない場合が多いため、移行するのが容易である傾向があります。

既存または新規開発のフロントエンド アプリケーションをパブリック クラウドにデプロイすることには、いくつかの重要なメリットがあります。

  • 多くのフロントエンド アプリケーションは頻繁に変更されます。パブリック クラウドでこれらのアプリケーションを実行する場合、継続的インテグレーション / 継続的デプロイ(CI / CD)プロセスの設定が簡単になり、新パージョンのロールアウトを効率的かつ自動的に行うことができるようになります。

  • パフォーマンス重視あるいは頻繁に変更されるフロントエンド アプリケーションにおいては、負荷分散、マルチ リージョン デプロイ、自動スケーリング機能といった、クラウドでのデプロイによるメリットが最大限に活かせます。

  • ユーザー インターフェースや API を実装している場合でも、IoT(Internet of Things: モノのインターネット )データの取り込みを処理している場合でも、フロントエンド アプリケーションでは、FirebaseCloud Content Delivery NetworkCloud IoT などのクラウド サービスを活用できます。

バックエンド アプリケーションが規制や法令による制限対象となるデータを管理している場合は、永久にまたは制限内で作業する方法が見つかるまで、限定公開のコンピューティング環境に保管することをおすすめします。

一方、あまり一般的ではありませんが、階層型ハイブリッド パターンを逆向きに適用し、限定公開コンピューティング環境でフロントエンド アプリケーションを維持しながら、クラウドでバックエンド アプリケーションをデプロイすることもできます。このアプローチは、大規模でモノリシックなフロントエンド アプリケーションを扱う場合に適しています。その場合、バックエンドの機能抽出を繰り返しながら、クラウドで新しいバックエンドをデプロイするほうが簡単かもしれません。

ベスト プラクティス

階層型ハイブリッド パターンを適用する際には、次の方法を検討してください。

  • 下りゲート型トポロジまたはメッシュ型トポロジのいずれかを使用します。ユーザーの操作のほとんどが複数のコンピューティング環境をまたがるシステムに関係しているため、システム間の高速かつ低レイテンシの接続が重要になります。高可用性、低レイテンシ、スループット レベルの適切性を実現するように設計することが重要になります。

  • コンピューティング環境間の通信のレイテンシを最小限に抑えるには、対象となる限定公開のコンピューティング環境に地理的に最も近い GCP のリージョン相互接続されたロケーションを選択します。

  • 階層型ハイブリッド設定では、通常、GCP から限定公開のコンピューティング環境に向かうデータ量(下り)よりも GCP に向かうデータ量(上り)のほうが大きくなります。それでもなお、GCP からのトラフィックには下り料金が発生することに注意してください。Dedicated Interconnectダイレクト ピアリングを使用すればこれらの料金を削減できます。

  • 環境間の通信が単方向になるようにします。パブリック クラウドで実行されるフロントエンド アプリケーションは、限定公開のコンピューティング環境で実行しているバックエンドと通信できますが、その逆はできません。

  • 環境間で交換されるデータはプライベートであるため、バーチャル プライベート ネットワーク(VPN)のトンネル、TLS(Transport Layer Security)、またはその両方を使用してすべての通信が暗号化されるようにしてください。

  • 既存のバックエンド サービスの出入口として、特に、プロトコル、API、認証メカニズムがバックエンド間で一致していない場合に、API ゲートウェイをデプロイすることをおすすめします。API ゲートウェイは、統合レイヤとしての機能に加えチョーク ポイントとしても機能します。このゲートウェイを使用することにより、あらゆる環境間の通信に適用可能な追加のセキュリティおよび監査の機能を実装できます。

  • システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。

個別のワークロードについては、これらのベスト プラクティスをご検討ください。

  • このパターンでは、フロントエンドに重点を置いていますが、バックエンドをモダナイズする必要性にも注意してください。バックエンドの開発ペースがフロントエンドの開発ペースより大幅に遅い場合、その差はプロジェクトの複雑さを増長させる要因となり得ます。

  • 「変換して移行」(transform-and-move migration)を可能にするには、Kubernetes を GCP と限定公開のコンピューティング環境に共通のランタイム レイヤとして使用します。Kubernetes を使用すると、時期を分けてワークロードをモダナイズし GCP に移行できます。この機能は、ワークロードが別のワークロードに大きく依存しているために個別に移行できない場合に重要になります。

  • 環境間の双方向通信はしないでください。そのためには、パブリック クラウドに CI / CD システムをデプロイすることも検討してください。

  • 階層型ハイブリッドでは、環境間で一貫したツールの利用と CI / CD プロセスの使用により、運用効率を向上させることをおすすめしますが、このプラクティスは必須ではありません。

  • フロントエンド ワークロードを実行するために Kubernetes を使用する場合は、セレクタなしのサービスを使用して、限定公開のコンピューティング環境で実行されているサービスまたは API ゲートウェイを検出可能にします。Kubernetes のスタブドメインを使用することにより、Consul など外部の DNS ベースサービス発見システムと統合できます。

分割されたマルチクラウド

分割されたマルチクラウド パターンは、異なるベンダーによって運営される複数のパブリック クラウド環境を組み合わせて、最適なコンピューティング環境にアプリケーションをデプロイする柔軟性を提供します。次の図は、典型的な分割されたマルチクラウド パターンを示しています。

分割されたマルチクラウド パターン

あるパブリック クラウド環境から別のパブリック クラウド環境にワークロードを必要に応じてシフトできるようにすることができます。その場合、ワークロードの移植性が重要な要件になります。ワークロードを複数のコンピューティング環境にデプロイしつつ、環境間でワークロードを移動を可能にする場合は、環境間の違いを抽象化する必要があります。

GCP は、さまざまな方法でワークロードをデプロイするために使用できる豊富なサービスを提供します。それでもなお、GCP と他のクラウド プロバイダを組み合わせ、複数のクラウド環境をまたいでワークロードを分割するほうが合理的な場合があります。次に例を示します。

  • 単一のベンダーにコミットするのを避けるため、複数のクラウド プロバイダにアプリケーションを分散する。

  • 規制上の理由から、GCP がまだ存在していない国のユーザーベースとデータの特定の部分にサービスを提供する。

  • 複数のクラウド プロバイダにアプリケーションをデプロイし、各プロバイダが提供する良質のサービスの中から最適なものを選択できるようにする。

メリット

分割されたマルチクラウド パターンの主なメリットは次のとおりです。

  • ベンダーのロックインを避けることができます。このパターンは戦略リスクを軽減し、後で計画やパートナーシップを柔軟に変更できます。

  • ワークロードの移植性を維持し、コンピューティング環境間でワークロードをシフトすることで運用を最適化できます。

ベスト プラクティス

  • 分割されたマルチクラウド設定の戦略上のメリットは、追加されるシステムの複雑さとのバランスを考慮して評価してください。複数のクラウド環境にわたるワークロードの移植性の実現と一貫したツールの利用には、開発、テスト、運用の作業の増大が伴います。

  • マルチクラウド環境は、ミッション クリティカルなワークロードの場合、あるいは法律上または規制上の理由により、単一のパブリック クラウド環境でワークロードを処理できない場合にのみ使用してください。

  • 特に通信が同期的に処理されている場合、さまざまなパブリック クラウド環境で動作しているシステム間の依存関係を最小限に抑えます。こうした依存関係は、パフォーマンスや全体の可用性の低下の原因となります。

  • 環境の違いを抽象化するには、コンテナと Kubernetes の使用を検討してください。

  • CI / CD プロセス、および、デプロイとモニタリングに使用するツールは、クラウド環境間で一貫性を保ちます。

  • メッシュ型またはゲート型のトポロジのいずれかを使用します。

  • 環境間で交換されるデータはプライベートであるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が確実に暗号化されるようにしてください。

  • システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。

  • Kubernetes を使用する場合は、ExternalDNS を使用して、コンピューティング環境全体で DNS 名でサービスを検出可能にするようにしてください。

  • エニーキャスト IP ベースの GCP ロードバランサを使用して、複数の GCP リージョンにわたってリクエストのバランスを取ることは可能ですが、複数のクラウドにまたがってユーザー リクエストを配信するためにリクエストを分散することはできません。この分散では、NS1DynAkamai などのサービス プロバイダが提供するラウンドロビンや Geo DNS を使用する必要があります。

分析向けハイブリッド / マルチクラウド

企業向けシステムでは、ほとんどのワークロードが次のカテゴリに分類されます。

  • トランザクション ワークロードには、営業、財務処理、エンタープライズ リソース プランニング、通信などのインタラクティブ型アプリケーションが含まれます。

  • 分析ワークロードには、意思決定プロセス支援のためのデータの変換、分析、改良、可視化を行うアプリケーションが含まれます。

分析システムは、API のクエリまたはデータベースへのアクセスによってトランザクション システムからデータを取得しますが、ほとんどの企業では、分析システムとトランザクション システムが分離され疎結合されてしまう傾向があります。分析向けハイブリッド / マルチクラウド パターンでは、2 つの異なるコンピューティング環境で 2 種類のワークロードを実行することによって、既存の分割を活用します。元データは、限定公開のコンピューティング環境で実行されるワークロードから最初に抽出され、GCP にロードされ分析処理に使用されます。その結果の一部は、トランザクション システムにフィードバックされる可能性があります。

分析向けマルチクラウド パターン

メリット

クラウド内で分析ワークロードを実行することには、いくつかの重要なメリットがあります。

  • 分析ワークロードは、しばしば大量のデータを処理する必要があり、爆発的になる可能性があるため、パブリック クラウド環境でのデプロイに特に適しています。コンピューティング リソースを動的にスケーリングすることにより、大規模なデータセットを迅速に処理し、事前投資を回避したり、コンピューティング機器を過剰にプロビジョニングする必要がありません。

  • GCP は、最初のデータ取得から、処理、分析、最終的な可視化まで、データのライフサイクル全体を通じてデータを管理する豊富なサービスを提供します。

  • Cloud Storage はデータレイクの構築に適しています。

  • 上りトラフィック - 限定公開のコンピューティング環境から GCP へのデータ移行は無料です

ベスト プラクティス

分析向けハイブリッド / マルチクラウド パターンを実装するにあたり、次のベスト プラクティスを検討してください。

  • ハンドオーバー型トポロジを使用してデータの取り込みを有効にします。分析結果をトランザクション システムにフィードバックする必要がある場合は、ハンドオーバー型と下りゲート型トポロジの両方を組み合わせます。

  • Cloud Pub/Sub のキューまたは Cloud Storage のバケットを使用して、限定公開のコンピューティング環境で実行しているトランザクション システムから GCP にデータを渡すことができます。これらのキューまたはバケットは、データ処理パイプラインおよびワークロードの送信元として機能します。

  • 既存の Hadoop または Spark のワークロードがある場合は、ジョブを Cloud Dataproc に移行し、既存の HDFS データを Cloud Storage に移行することを検討してください。

  • 限定公開のコンピューティング環境から GCP へ最初にデータ転送を実行する場合は、データセットのサイズと使用可能な帯域幅に最も適した転送方法を選択します。

  • 複数環境間でツールとプロセスの一貫性を保ちます。分析向けハイブリッド シナリオにおける前提条件ではありませんが、このプラクティスは運用効率を高めるのに役立ちます。

エッジ型ハイブリッド

クラウドでワークロードを実行するには、クライアント側が高速かつ信頼性の高いインターネット接続性を備えている必要があります。今日のネットワークにおいては、この要件がクラウド導入の障害になることはほとんどありません。ただし、次に示すように継続的な接続を利用できないシナリオはあり得ます。

  • 石油リグ、船舶、その他の車両においては、断続的な接続しか利用できない、もしくはレイテンシの高い衛星リンクを介してのみアクセスが可能な場合があります。

  • また、工場や発電所がインターネットに接続されている可能性もあります。インターネット接続で保証される可用性では、これらの施設における信頼性の要件を満たすのに不十分な場合があります。

  • 小売店舗やスーパーマーケットでは、接続に間断がある、または使用している接続において、ビジネス クリティカルな取引の処理に必要な信頼性やスループットが提供されない場合もあります。

エッジ型ハイブリッド パターンでは、時間あるいはビジネスの面でクリティカルなワークロードをネットワークのエッジでローカル実行し、他の種類のワークロードにクラウドを使用することで、これらの課題に対処しています。エッジ型ハイブリッド設定において、インターネット接続は、管理目的やデータの同期化またはアップロード(非同期の場合も多い)に使用される重要でないコンポーネントであり、緊急時や重要業務のトランザクションには関係させません。

エッジ型ハイブリッド パターン

メリット

特定のワークロードをエッジやクラウド内のその他の場所で実行することには、いくつかのメリットがあります。

  • 時間やビジネスの面でクリティカルなワークロードをエッジで実行した場合、レイテンシが低下し自足性も向上します。また、インターネットに接続できない場合や一時的に利用できない場合でも、重要なトランザクションをすべて実行できます。同時に、全体のワークロードのかなりの部分をクラウドで実行することは有益です。

  • 既存の投資をコンピューティングおよびストレージ機器に再利用できます。

  • 時の経過に伴い、特定のアプリケーションをリワークするか、エッジが所在する場所に信頼性の高いインターネット接続を装備することによって、エッジで実行されるワークロードの割合を徐々に減らすことができます。

  • 上りトラフィック - エッジから GCP へのデータ移行は無料です

ベスト プラクティス

エッジ型ハイブリッド パターンを実装するときは、次の推奨事項を考慮してください。

  • 通信が単方向である場合は、上りゲート型トポロジを使用します。双方向通信の場合は、上り / 下りゲート型トポロジを考慮してください。

  • エッジで実行されるシステムとクラウド環境で実行されるシステムの間の依存関係を最小限に抑えます。各依存関係により、エッジ型ハイブリッド設定で得られる信頼性とレイテンシの向上のメリットが損なわれる可能性があります。

  • 複数のエッジを効率的に管理して操作するには、クラウドに集中コントロール プレーンを用意します。

  • クラウド環境とエッジ環境を通して、CI / CD プロセス、および、デプロイとモニタリング用のツールが一貫していることを確認します。

  • エッジ ロケーションの間、およびエッジ ロケーションとクラウドの間の差異を抽象化するために、コンテナと Kubernetes を使用することを検討してください。Kubernetes では、共通のランタイム層を提供するため、コンピューティング環境全体でワークロードを一貫して開発、実行、操作し、ワークロードをエッジとクラウド間で移動できます。

  • システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。

  • 環境間で交換されるデータはプライベートであるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が確実に暗号化されるようにしてください。

冗長デプロイ パターン

以下のセクションでは、複数のコンピューティング環境にわたるアプリケーションの冗長デプロイに依存する一般的なパターンについて説明します。これらのパターンでは、同じアプリケーションを複数のコンピューティング環境にデプロイし、処理能力や復元力を高めることを目指しています。

環境ハイブリッド

環境ハイブリッド パターンとは、既存のデータセンター上にワークロードの本番環境を維持し、パブリック クラウドを他の非本番環境に使用することです。

移行するワークロードを評価するにあたり、特定のアプリケーションをパブリック クラウドで実行することが問題につながるケースに直面することがあります。

  • 法令または規制上の制約により、特定の国にデータを保管する必要が生じる場合があります。
  • サードパーティ製品のライセンス条項により、クラウド環境で特定のソフトウェアを操作できない場合があります。
  • ワークロードを移動する場合と同様、アプリケーションがローカルでのみ使用可能なハードウェア デバイスへのアクセスを必要とする場合があります。

このような場合は、本番環境だけでなく、開発、テスト、ステージング システムなど、アプリケーションのライフサイクルに関わるすべての環境を考慮する必要があります。クラウドの移行を困難にする可能性のある制限事項は、多くの場合、本番環境とそのデータに適用されますが、他の環境には適用されません。

次の図は、典型的な環境ハイブリッド パターンを示しています。

環境ハイブリッド パターン

本番環境のシステムとは異なる環境で開発およびテストシステムを実行することは危険であり、既存のベスト プラクティスや環境間の相違を最小限に抑える試みに反するとも考えられます。このような懸念は裏付けのあるものですが、開発プロセスとテストプロセスのステージを区別すれば問題になりません。

  • 開発、テスト、デプロイの各プロセスはアプリケーションごとに異なりますが、通常は次のようなステージごとのバリエーションがあります。

    • 開発: リリース候補を作成する。
    • 機能テストまたはユーザー受け入れテスト: リリース候補が機能要件を満たしていることを確認する。
    • パフォーマンスと信頼性のテスト: リリース候補が非機能要件を満たしていることを確認する。
    • ステージングまたはデプロイテスト: デプロイ手順が動作していることを確認する。
    • 本番環境。

単一の環境で複数のステージを実行するのは実用的ではないため、通常は各ステージにつき 1 つ以上の専用環境が必要となります。

テスト結果が意味を持ち、本番環境にもあてはまることを確実にするには、アプリケーションのライフサイクル全体で使用する一連の環境が、可能な限り、次のルールを満たしている必要があります。

  • すべての環境が機能的に同等であること。つまり、オペレーティング システムとライブラリのアーキテクチャ、API、バージョンが同等で、システムが環境全体で同じように動作する必要があります。この同等性により、アプリケーションがある環境では動作するが別の環境では機能しないまたは欠陥が再現できないといった状況が回避されます。

  • パフォーマンスと信頼性のテスト、ステージング、本番環境に使用される環境が非機能的に同等であること。つまり、それらのパフォーマンス、スケール、構成、およびそれらが操作され、維持される方法は、同じであるか、違いがあったとしてもわずかなものである必要があります。そうしないと、パフォーマンス テストとステージング テストが無意味になります。

重要なのは、開発と機能テストに使用される環境がその他の環境と非機能的に異なっても構わないことです。このような状況は、環境ハイブリッド パターンによく当てはまります。

  • 共通ランタイム レイヤとして Kubernetes に依存し、ワークロードの移植性を確保し、コンピューティング環境の違いを抽象化することで、すべての環境で同等の機能を実現します。

  • 限定公開のコンピューティング環境における本番環境、ステージング、パフォーマンス、信頼性テストのための環境を稼働させ、機能的および非機能的な同等性を確保します。

  • パブリック クラウドで開発および機能テスト環境を実行します。これらの環境は機能的には他の環境と同等ですが、パフォーマンスなどの非機能面では異なる場合があります。

メリット

パブリック クラウドでの開発と機能テストのワークロードの実行には、いくつかのメリットがあります。

  • 必要に応じて、環境を自動的にスピンアップまたは破棄できます。たとえば、commit リクエストまたは pull リクエストごとに環境全体をプロビジョニングし、テストを実行できるようにする一方で、必要がなくなったら環境を破棄できます。

  • 開発環境とテスト環境は、しばしば断続的に使用されます。非アクティブ時に仮想マシン(VM)インスタンスを停止するか、オンデマンドで環境をプロビジョニングすることにより費用を削減できます。

  • パブリック クラウドでこれらの環境を実行することで、クラウドや関連ツールに精通し、他のワークロードの移行に役立てることができます。

ベスト プラクティス

環境パターンを正常に実装するには、次の推奨事項を検討してください。

  • ミラー型トポロジを使用して、異なる環境のシステムが相互に通信することを防ぎます。システムは環境間で通信する必要がなく、共通の ID を確立する必要がないためです。

  • ワークロードを移植可能にし、環境間の差を抽象化するために、コンテナと Kubernetes を使用する一方で、ワークロードの移植性の制限にも注意してください。

  • CI / CD プロセスがコンピューティング環境全体で一貫しており、同一のバイナリ、パッケージ、およびコンテナのセットがあらゆる環境にデプロイされていることを確認します。

  • ワークロードをデプロイ、構成、および操作するために、コンピューティング環境全体で機能する共通のツールチェーンを確立します。Kubernetes を使用すると、異なるコンピューティング環境で実行しているクラスタに接続または認証する方法のわずかな違いを除いて、この一貫性が得られます。

  • Kubernetes を使用する場合は、Jenkins などの CI システムを使用して、クラスタにデプロイして各環境で動作するデプロイ パイプラインを実装します。Google Kubernetes Engine(GKE)で Jenkins 自体を実行することもできます。

  • GCP と既存のクラウド環境でのロギングとモニタリングには、同じツールを使用します。Prometheus などのオープンソースのモニタリング システムの使用を検討してください。別のチームがテスト環境と本番環境のワークロードを管理する場合は、別々のツールを使用することもできますが、同じツールを使用するとトレーニングの労力と複雑さを軽減できます。

  • データベース、ストレージ、メッセージング サービスを選択する場合は、GCP で同等のマネージド サービスが提供されるプロダクトを使用してください。マネージド サービスを使用することにより、開発環境とテスト環境を管理する作業を軽減できます。次の表は、どの GCP プロダクトが一般的な OSS 製品と互換性があるかを示しています。

OSS 製品 GCP プロダクトとの互換性
Apache HBase Cloud Bigtable
Apache Beam Cloud Dataflow
Apache Hadoop Cloud Dataproc
MySQL、PostgreSQL Cloud SQL
Redis Cloud Memorystore
ネットワーク ファイル システム(NFS) Cloud Filestore
JMS、Kafka Cloud Pub/Sub

ビジネス継続性ハイブリッド / マルチクラウド

ミッション クリティカルなシステムは、災害時に復元力を発揮するように設定されることが理想です。複数のリージョンにわたってシステムとデータを複製し、単一障害点を回避することで、自然災害によるローカル インフラストラクチャへのリスクを最小限に抑えることができます。しかし、このアプローチでは、人為的ミスやソフトウェアの欠陥によって引き起こされる停止のリスクには対応できません。したがって、こうした自然災害以外の原因による障害が発生した場合でも、許容可能な時間内にシステムを復旧し、データ損失を最小限に抑えるための障害復旧(DR)計画も重要になります。

DR 計画の重要な部分は、データを地理的に異なる場所に頻繁にバックアップして、リカバリ ポイント目標(RPO)を最小限に抑えることです。さらに、コールド、ウォーム、およびホット スタンバイ システムをセカンド ロケーションに確保することで、復旧時間目標(RTO)を最小限に抑えることができます。

ミッション クリティカルなシステムを中央データセンターで実行する場合、DR の 1 つのアプローチとして、別のリージョンにある第 2 のデータセンターにスタンバイ システムを確保する方法があります。しかし、より費用対効果の高い方法は、フェイルオーバーのためにパブリック クラウドによるコンピューティング環境を使用することです。これはビジネス継続性ハイブリッド パターンの背後にある考え方です。

ビジネス継続性ハイブリッド パターン

一般的ではなく、必要になることがまれなバリエーションとしては、本番環境と DR 環境に別のクラウド プロバイダを使用するという、ビジネス継続性マルチクラウド パターンがあります。ワークロードのコピーを複数のクラウド プロバイダにデプロイすることで、マルチ リージョン デプロイで提供される以上の可用性を実現できます。

メリット

パブリック クラウドをビジネス継続性のために使用することには、多くのメリットがあります。

  • GCP には十数個のリージョンがあり、同じ大陸内の別のサイトや別の大陸のサイトにもデータをバックアップまたは複製できます。

  • 停止した VM インスタンスにはストレージの費用しか発生せず、実行中の VM インスタンスよりも大幅に安価なので、コールド スタンバイ システムの保守の費用を最小限に抑えることができます。

  • GCP の従量制モデルは、実際に使用するストレージとコンピューティング容量に対してのみ支払いが発生することを保証し、必要に応じて DR 環境を拡張または縮小できます。

ベスト プラクティス

ビジネス継続性パターンを使用している場合は、次のベスト プラクティスを検討してください。

  • フェイルオーバー手順と復旧手順とともにインフラストラクチャについて文書化した障害復旧計画を作成します。

  • RPO と RTO に基づいて、GCP へのデータ バックアップで十分かどうか、またはコールド、ウォーム、またはホット スタンバイ システムを維持する必要があるかどうかを決定します。GCP での一般的なシナリオとアドバイスについては、障害復旧計画ガイドをご覧ください。

  • データ バックアップのみを実行する場合は、ハンドオーバー型トポロジを使用します。それ以外の場合は、ミラー型トポロジを検討してください。

  • 異なる環境で動作するシステム間の依存関係を最小限に抑えます。こうした依存関係は、パフォーマンスや全体の可用性の低下の原因となります。

  • 環境間で双方向にデータを複製すると、スプリット ブレインが発生する可能性があります。すなわち、2 つの環境間の通信が切断されると、両側のシステムにおいて他の環境が利用できなくなったと判断されてしまう可能性があります。その際、システムは自分がデータへの排他的アクセス権を持っていると判断し、最終的に矛盾する変更の発生につながってしまいます。この問題を防止する 1 つの方法は、第 3 のコンピューティング環境を追加することです。このアプローチにより、データ レプリケーションに依存しているシステムがデータの変更を安全であると判断する前に、クォーラムをチェックするようにすることができます。また、接続が復元された後、競合するデータの変更を調整できるようにすることもできます。

  • CI / CD システムとアーティファクトのリポジトリが単一障害点にならないようにします。1 つの環境が利用できない場合でも、新しいリリースをデプロイしたり、構成の変更を適用したりできる必要があります。

  • 環境間で交換されるデータはプライベートであるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が確実に暗号化されるようにしてください。

  • スタンバイ システムを使用している場合は、ワークロードが移植可能であることを確認して、システム間で一貫したシステムが維持されるようにしてください。コンテナと Kubernetes の使用を検討してください。

  • スタンバイ システムのデプロイを CI / CD プロセスに統合します。この統合により、アプリケーションのバージョンと構成が環境全体で一貫が保たれます。

  • ホット スタンバイ システムを使用する場合、ロードバランサを使用して自動フェイルオーバーを作成しますが、ロードバランサにも障害が発生する可能性があるのでご注意ください。予防措置として、障害発生時にユーザーをスタンバイ システムに再ルーティングできるように DNS を構成します。適度に短い TTL を使用して、DNS の変更が迅速に伝達され、Cloud DNS が提供する稼働時間 100% の SLA の利点を生かせるようにします。

  • DR には、CloudEndureActifioCommvault などのパートナー ソリューションを検討してください。

クラウド バースト機能

インターネット アプリケーション、特にユーザーを対象とするアプリケーションでは、使用状況が極端に変動する可能性があります。ほとんどの企業向けアプリケーションでは、このような問題に直面することはありませんが、バッチジョブや CI / CD ジョブなど、バーストの原因となるさまざまなワークロードに対処する必要があります。

従来のデータセンター ベースのコンピューティング環境では、リソースを多めにプロビジョニングすることによって、バーストの原因となるワークロードに対応できますが、この方法は費用効率が優れません。バッチジョブについては、実行時間を引き延ばすことで使用率を最適化できますが、ジョブを遅延させるため時間が重視される場合には実用的でありません。

クラウド バースト パターンとは、限定公開のコンピューティング環境をベースラインのワークロードに使用することにより、余分な容量が必要なときに一時的なバーストをクラウドに担わせることです。

クラウド バースト パターン

クラウド バースト シナリオの重要な要件は、ワークロードの移植性です。ワークロードを複数の環境にデプロイできるようにするには、環境間の違いを抽象化する必要があります。

クラウド バースト パターンは、インタラクティブ型、バッチ型両方のワークロードに適用可能です。ただし、インタラクティブ型のワークロードを処理する場合は、環境間でリクエストを分散する方法を決定する必要があります。

  • 受信したユーザー リクエストを既存のデータセンターで走行するロードバランサにルーティングし、ロードバランサでローカルおよびクラウドのリソース全体に分散させることができます。このアプローチでは、クラウドに割り当てられているリソースをトラックし、リソースの自動アップ スケーリングまたはダウン スケーリングを実行するために、既存のデータセンターで走行しているロードバランサまたは別のシステムが必要です。

    画像

    一方で、このアプローチを使用することで、アクティビティの低い時間帯にはすべてのクラウド リソースをデコミッションできます。一方、リソース トラックのメカニズムを実装すると、既製のロードバランサ ソリューションの機能の範囲を超え全体的な複雑さが増してしまう可能性があります。

  • あるいは、リクエストを GCP に最初にルーティングして環境に分散させることもできます。GCP ロードバランサは GCP リソース間のバランシングと自動スケーリングしかサポートしないため、GCP ロードバランサと追加のカスタム負荷分散メカニズムを組み合わせてリクエストの配信を促進させる必要があります。これによっても、アプローチは複雑さを増してしまいます。

    負荷の低い時間帯に GCP のすべてのリソースをシャットダウンする場合、ラウンドロビン DNS を使用した負荷分散は実用的ではありません。DNS の更新はゆっくりと伝播する傾向があるため、負荷分散に DNS を使用すると、リクエストを処理するためのリソースがない時間帯にユーザー リクエストが GCP にルーティングされてしまうリスクがあります。

これらの問題から、クラウド バースト機能は一般的に、インタラクティブ型のワークロードよりもバッチ型のワークロードに適しているということになります。

メリット

このアーキテクチャ パターンの主なメリットは次のとおりです。

  • クラウド バースト機能は、データセンターや限定公開のコンピューティング環境にある既存の資産の再利用を可能にします。この再利用は、永続的に、または、機器の交換期限までの間ずっと有効になり得ます。その時点で、クラウドの完全移行を検討できます。

  • ピーク時の要求を満たすために過剰な容量を維持する必要がなくなり、限定公開のコンピューティング環境の利用率と費用効率を高めることができます。

  • クラウド バースト機能により、過剰なコンピューティング リソースを必要とせずにバッチジョブを適切なタイミングで実行できます。

ベスト プラクティス

クラウド バースト機能を実装する際は、以下のベスト プラクティスを検討してください。

  • メッシュ型トポロジを使用して、クラウドで実行されるワークロードが他のコンピューティング環境で実行されるワークロードと同じ方法でリソースにアクセスできるようにします。ワークロードが許可されている場合は、クラウドから他のコンピューティング環境へのアクセスのみを許可します。

  • コンピューティング環境間の通信のレイテンシを最小限に抑えるには、対象となる限定公開のコンピューティング環境に地理的に最も近い GCP のリージョン相互接続されたロケーションを選択します。

  • バッチ型のワークロードにのみクラウド バースト機能を使用する場合は、すべての GCP リソースを非公開にして、インターネットからこれらのリソースに直接アクセスできないようにすることで、セキュリティ攻撃の可能性を低減させます。

  • 24 時間を超えて実行されず緊急性もないジョブの場合、通常の VM インスタンスよりも大幅に安価なプリエンプティブ VM インスタンスの使用を検討してください。ただし、ジョブが実行されている VM がプリエンプトされた場合、システムは自動的にジョブを再開できる必要があります。

  • コンテナを使用してワークロードの移植性を実現します。リソースを大量に消費するバッチ型のワークロードの場合、これらのコンテナを Compute Engine VM に直接デプロイし、マネージド インスタンス グループを使用して VM の数をスケーリングできます。インタラクティブ型のワークロードや多様かつ多くのリソースを必要としないワークロードの場合は、Google Kubernetes Engine(GKE)クラスタ オートスケーリングと組み合わせて使用し、これらのコンテナをデプロイすることもできます。ただし、GKE ではゾーンごとに少なくとも 1 つのノードが常に稼働している必要があります。

  • GCP から別のコンピューティング環境に送信されたトラフィックをモニタリングします。このトラフィックは、下り料金の対象となります。

  • 環境間で交換されるデータはプライベートであるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が確実に暗号化されるようにしてください。

  • ストレージ集中型ワークロードの場合、CloudianClearSkyAvere vFXTEgnyteSwiftStack などのハイブリッド ストレージ ソリューションとの統合を検討してください。

  • バースト クラウド パターンを使用して、CI システムを動的にスケーリングします。Jenkins を使用する場合、Google Compute Engine プラグインを使用して、Compute Engine で Jenkins インスタンスを管理および自動スケーリングできます。

  • システムが環境境界を越えて安全に認証できるように、環境間に共通の ID を確立します。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...