環境ハイブリッド アーキテクチャ パターンでは、ワークロードの本番環境を既存のデータセンターに保持します。その後、開発環境やテスト環境などの環境にパブリック クラウドを使用します。このパターンは、複数のコンピューティング環境にわたる同じアプリケーションの冗長デプロイに依存します。デプロイの目的は、容量、アジリティ、復元力を高めることです。
移行するワークロードを評価するにあたり、特定のアプリケーションをパブリック クラウドで実行することが問題につながるケースに直面することがあります。
- 法令または規制上の制約により、特定の国にデータを保管する必要が生じる場合があります。
- サードパーティ製品のライセンス条項により、クラウド環境で特定のソフトウェアを操作できない場合
- ローカルでのみ使用可能なハードウェア デバイスへのアクセスがアプリケーションで必要になる場合
このような場合は、本番環境だけでなく、開発、テスト、ステージング システムなど、アプリケーションのライフサイクルに関わるすべての環境を考慮する必要があります。これらの制限は、多くの場合、本番環境とそのデータに適用されます。実際のデータを使用しない他の環境には適用されない場合があります。組織のコンプライアンス部門または同等のチームに確認してください。
次の図は、典型的な環境ハイブリッド アーキテクチャ パターンを示しています。
本番環境のシステムとは異なる環境で開発 / テストシステムを実行することは危険であり、既存のベスト プラクティスや環境間の相違を最小限に抑える試みに反するとも考えられます。このような懸念は裏付けのあるものですが、開発プロセスとテストプロセスのステージを区別すれば問題になりません。
開発、テスト、デプロイの各プロセスはアプリケーションごとに異なりますが、通常は次のようなステージごとのバリエーションがあります。
- 開発: リリース候補を作成する。
- 機能テストまたはユーザー受け入れテスト: リリース候補が機能要件を満たしていることを確認する。
- パフォーマンスと信頼性のテスト: リリース候補が非機能要件を満たしていることを確認します。負荷テストとも呼ばれます。
- ステージングまたはデプロイテスト: デプロイ手順が動作していることを確認する。
- 本番環境: 新しいアプリまたは更新されたアプリをリリースします。
単一の環境でこれらの複数のステージを実行するのは実用的ではないため、通常は各ステージにつき 1 つ以上の専用環境が必要となります。
テスト環境の主な目的は、機能テストを実行することです。ステージング環境の主な目的は、アプリケーションのデプロイ手順が意図したとおりに機能するかどうかをテストすることです。リリースがステージング環境に到達するまでに、機能テストが完了している必要があります。ステージングは、本番環境デプロイにソフトウェアをデプロイする前の最後のステップです。
テスト結果が意味を持ち、本番環境にもあてはまることを確実にするには、アプリケーションのライフサイクル全体で使用する一連の環境が、可能な限り、次のルールを満たしている必要があります。
- すべての環境が機能的に同等であること。つまり、オペレーティング システムとライブラリのアーキテクチャ、API、バージョンが同等で、システムが環境全体で同じように動作する必要があります。この同等性により、アプリケーションがある環境では動作するが別の環境では機能しないまたは欠陥が再現できないといった状況が回避されます。
- パフォーマンスと信頼性のテスト、ステージング、本番環境に使用される環境が非機能的に同等であること。つまり、それらのパフォーマンス、スケール、構成、およびそれらが操作され、維持される方法は、同じであるか、違いがあったとしてもわずかなものである必要があります。そうしないと、パフォーマンス テストとステージング テストが無意味になります。
一般に、開発と機能テストに使用される環境がその他の環境と非機能的に異なっても構いません。
次の図に示すように、テスト環境と開発環境は Google Cloud 上に構築されています。Cloud SQL などのマネージド データベースは、Google Cloud での開発とテストのオプションとして使用できます。開発とテストでは、オンプレミス環境と同じデータベース エンジンとバージョン、機能的に同等のバージョン、またはテスト ステージ後に本番環境にロールアウトされる新しいバージョンを使用できます。ただし、2 つの環境の基盤となるインフラストラクチャは同じではないため、パフォーマンス ロードテストに対するこのアプローチは有効ではありません。
次のシナリオは、環境ハイブリッド パターンに適しています。
- 適用可能で実現可能な場合は、共通ランタイム レイヤとして Kubernetes に依存することで、すべての環境で同等の機能を実現します。このアプローチを実現するための重要な技術として、Google Kubernetes Engine（GKE）Enterprise エディションを使用できます。
- ワークロードの移植性を確保し、コンピューティング環境間の違いを抽象化します。ゼロトラスト サービス メッシュを使用すると、さまざまな環境間で必要な通信分離を制御して維持できます。
- パブリック クラウドで開発および機能テスト環境を実行します。これらの環境は機能的には他の環境と同等ですが、パフォーマンスなどの非機能面では異なる場合があります。このコンセプトは上の図に示されています。
- プライベート コンピューティング環境における本番環境、ステージング、パフォーマンス（負荷テスト）、信頼性テストのための環境を稼働させ、機能的および非機能的な同等性を確保します。
設計上の考慮事項
- ビジネスニーズ: アプリケーションのデプロイ戦略とリリース戦略にはそれぞれ長所と短所があります。選択したアプローチが特定の要件に合っていることを確認するには、ビジネスニーズと制約を徹底的に評価したうえで選択してください。
- 環境の違い: このパターンでは、このクラウド環境を使用する主な目的は開発とテストです。最終的な状態は、テスト済みのアプリケーションを限定公開のオンプレミス環境（本番環境）でホストすることです。クラウド環境では想定どおりに機能し、本番環境（オンプレミス）では機能しない可能性のある機能を開発してテストしないようにするには、技術チームが両方の環境のアーキテクチャと機能を理解している必要があります。これには、他のアプリケーションやハードウェア インフラストラクチャ（トラフィック検査を実行するセキュリティ システムなど）に対する依存関係が含まれます。
- ガバナンス: クラウドで開発できる内容とテストに使用できるデータを制御するには、承認とガバナンスのプロセスを使用します。このプロセスは、オンプレミス本番環境に存在しないクラウド機能を開発環境とテスト環境で使用しないようにするのにも役立ちます。
- 成功基準: 組織のソフトウェアの品質保証基準に沿って、明確で事前定義された測定可能なテスト成功基準が必要です。これらの標準は、開発してテストするすべてのアプリケーションに適用します。
- 冗長性: 開発環境とテスト環境では、本番環境ほど信頼性が要求されない場合がありますが、冗長な機能とさまざまな障害シナリオをテストする機能は必要です。障害シナリオの要件によっては、開発環境とテスト環境の一部として冗長性を設計する必要があります。
利点
パブリック クラウドでの開発と機能テストのワークロードの実行には、いくつかのメリットがあります。
- 必要に応じて環境を自動的に開始または停止できます。たとえば、commit リクエストまたは pull リクエストごとに環境全体をプロビジョニングし、テストを実行できるようにする一方で、必要がなくなったら環境を無効にできます。このアプローチには次のような利点もあります。
- 非アクティブ時に仮想マシン（VM）インスタンスを停止するか、オンデマンドでのみ環境をプロビジョニングすることにより費用を削減できます。
- プルリクエストごとにエフェメラル環境を開始すると、開発とテストを高速化できます。また、メンテナンス オーバーヘッドが削減され、ビルド環境の不整合が軽減されます。
- パブリック クラウドでこれらの環境を実行することで、クラウドや関連ツールに精通し、他のワークロードの移行に役立てることができます。このアプローチは、コンテナと Kubernetes を使用してワークロードのポータビリティを検討する場合に特に役立ちます。たとえば、環境間で GKE Enterprise を使用する場合などです。
ベスト プラクティス
環境ハイブリッド アーキテクチャ パターンを正常に実装するには、次の推奨事項を検討してください。
- 最適なネットワークとセキュリティの設計など、アプリケーション通信の要件を定義します。次に、ミラーリングされたネットワーク パターンを使用して、異なる環境のシステム間の直接通信を防ぐようにネットワーク アーキテクチャを設計します。環境間で通信が必要な場合は、制御された方法で行う必要があります。
選択するアプリケーションのデプロイとテストの戦略は、ビジネス目標と要件に合わせて調整する必要があります。これには、ダウンタイムなしで変更をロールアウトしたり、幅広いリリースの前に特定の環境やユーザー グループに機能を段階的に実装したりすることが含まれます。
ワークロードを移植可能にし、環境間の差を抽象化するために、Kubernetes でコンテナを使用できます。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
ワークロードのデプロイ、構成、運用のために、コンピューティング環境全体で機能する共通のツールチェーンを確立します。Kubernetes を使用すると、この一貫性が得られます。
CI/CD パイプラインがコンピューティング環境全体で一貫しており、同一のバイナリ、パッケージ、またはコンテナのセットがこれらの環境全体にデプロイされていることを確認します。
Kubernetes を使用する場合は、Tekton などの CI システムを使用して、クラスタにデプロイして各環境で動作するデプロイ パイプラインを実装します。詳細については、Google Cloud の DevOps ソリューションをご覧ください。
安全で信頼性の高いアプリケーションを継続的にリリースするには、DevOps プロセス（DevSecOps）の不可欠な部分としてセキュリティを組み込みます。詳細については、Dev(Sec)Ops ツールキットを使用して、インターネット接続アプリケーションを 1 時間以内に配信して保護するをご覧ください。
Google Cloud と既存のクラウド環境でのロギングとモニタリングには、同じツールを使用します。オープンソースのモニタリング システムの使用を検討してください。詳細については、ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターンをご覧ください。
テスト環境と本番環境のワークロードを異なるチームが管理する場合は、別々のツールを使用することもできます。ただし、同じツールを異なるビュー権限で使用すると、トレーニングの労力と複雑さを軽減できます。
機能テスト用のデータベース、ストレージ、メッセージング サービスを選択する場合は、Google Cloud で同等のマネージド サービスが提供されるプロダクトを使用してください。マネージド サービスを使用することにより、開発環境とテスト環境を管理する作業を軽減できます。
機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec などがあります。
次の表は、どの Google Cloud プロダクトが一般的な OSS 製品と互換性があるかを示しています。
| OSS 製品 | Google Cloud プロダクトとの互換性 |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL、PostgreSQL | Cloud SQL |
| Redis クラスタ、Redis、Memcached | Memorystore |
| ネットワーク ファイル システム（NFS） | Filestore |
| JMS、Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |