環境ハイブリッド アーキテクチャ パターンでは、ワークロードの本番環境を既存のデータセンターに維持します。その後、開発環境やテスト環境などの環境にパブリック クラウドを使用します。このパターンは、複数のコンピューティング環境にわたる同じアプリケーションの冗長デプロイに依存します。このデプロイの目的は、容量、アジリティ、復元力を高めることです。
移行するワークロードを評価するにあたり、特定のアプリケーションをパブリック クラウドで実行することが問題につながるケースに直面することがあります。
- 法令または規制上の制約により、特定の国にデータを保管する必要が生じる場合があります。
- サードパーティ製品のライセンス条項により、クラウド環境で特定のソフトウェアを操作できない場合
- アプリケーションがローカルでのみ使用可能なハードウェア デバイスへのアクセスを必要とする場合
このような場合は、本番環境だけでなく、開発、テスト、ステージング システムなど、アプリケーションのライフサイクルに関わるすべての環境を考慮する必要があります。これらの制限事項は、多くの場合、本番環境とそのデータに適用されます。実際のデータを使用しない他の環境には適用されない場合があります。組織のコンプライアンス部門または同等のチームに確認してください。
次の図は、典型的な環境ハイブリッド アーキテクチャ パターンを示しています。
本番環境のシステムとは異なる環境で開発 / テストシステムを実行することは危険であり、既存のベスト プラクティスや環境間の相違を最小限に抑える試みに反するとも考えられます。このような懸念は裏付けのあるものですが、開発プロセスとテストプロセスのステージを区別すれば問題になりません。
開発、テスト、デプロイの各プロセスはアプリケーションごとに異なりますが、通常は次のようなステージごとのバリエーションがあります。
- 開発: リリース候補を作成する。
- 機能テストまたはユーザー受け入れテスト: リリース候補が機能要件を満たしていることを確認する。
- パフォーマンスと信頼性のテスト: リリース候補が非機能要件を満たしていることを確認する。負荷テストとも呼ばれます。
- ステージングまたはデプロイテスト: デプロイ手順が動作していることを確認する。
- 本番環境: 新しいアプリケーションまたは更新されたアプリケーションをリリースします。
単一の環境でこれらの複数のステージを実行するのは実用的ではないため、通常は各ステージにつき 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 |