このドキュメントでは、Istio サービス メッシュを使用して、仮想マシンでアプリケーションを実行しているオンプレミスのデータセンターなどの環境を Google Kubernetes Engine（GKE） に移行するアーキテクチャについて説明します。サービス メッシュを使用すると、ネットワーク機能をサービス機能から分離できるため、移行とリファクタリングの複雑さを軽減できます。
このドキュメントでは、移行の理由とフェーズの概要について説明します。このアーキテクチャを使用すると、1 回のオペレーションで移行を行うことができます（これをビッグバン移行といいます）。また、機能ごとに段階的な移行を行うこともできます。付属のデプロイメント ドキュメントでは、移行例について説明しています。
このアーキテクチャとそのデプロイメント ガイドは、次の要素を最小限に抑えながら、段階的な移行でモダナイズする複雑なインフラストラクチャを管理している IT 担当者を対象としています。
- ダウンタイム
- リファクタリングの作業
- ネットワークの運用上の複雑さ
ここで説明するコンセプトはすべてのクラウドに適用されるため、このドキュメントではクラウド テクノロジー、コンテナ、マイクロサービスに精通していることを前提としています。
Google Cloud への移行: スタートガイドで説明されているように、クラウドへの移行にはいくつかのパターンがあります。このドキュメントのアーキテクチャでは、リファクタリング パターン（移動と改善）を使用しています。このパターンは、アプリケーション全体ではなく、アプリケーションの各機能に適用されます。
移行時は、アプリケーションの一部の機能が Google Cloud に移行し、その他が移行元の環境に残るハイブリッド アーキテクチャになります。移行が完了すると、アプリケーション全体が Google Cloud でホストされます。
アーキテクチャ
次の図は、サービス メッシュを使用して、移行元の環境内で稼働するマイクロサービスか Google Cloud のいずれかにトラフィックをルーティングする方法を示しています。
このアーキテクチャは、次のコンポーネントで構成されます。
移行元の環境。この場合は、移行するサンプル ワークロードをホストする Compute Engine インスタンス。移行元の環境をオンプレミスにすることも、他のクラウド プラットフォームでホストすることもできます。
サービス メッシュ。この場合は Istio Gateway。異なるサービスをリンクします。サービス メッシュは、サービス ディスカバリ、安全な通信、ロード バランシング、トラフィック管理、オブザーバビリティなどの付加価値の高いネットワーキング機能を提供します。
サービス メッシュの一般的な実装では、各サービスと、これらの機能を提供するプロキシをペアにします。多くの場合、サービス プロキシはサイドカーと呼ばれます。サイドカーの役割は、アプリケーションの認識がなくても、接続されているアプリケーションを強化して改善させることです。付属のデプロイガイドでは、Envoy をサイドカー プロキシとして使用します。
マイクロサービスで構成されたアプリケーションを含むワークロード。マイクロサービスとは、アプリケーション機能に対応するように構築されたスタンドアロン コンポーネントを指します。このアーキテクチャでは、ユーザーを区別できないさまざまなマイクロサービスでアプリケーションが構成されています。たとえば、書籍のレビューを処理するコンポーネントはマイクロサービスです。
マイクロサービス パターンでは、アプリケーションは複数のマイクロサービスの集合体で、それぞれが特定の目的を持っています。たとえば、書籍の評価を処理する 1 つのマイクロサービスと、書籍のレビューを処理する 1 つのマイクロサービスがあるとします。これらのマイクロサービスは疎結合で、定義した API を介した相互のインターフェースとして機能します。これらは異なる言語やフレームワーク（多言語で記述されたアプリケーションなど）で作成でき、異なるライフサイクルを割り当てることが可能です。
マイクロサービスの境界をさらに定義するためのコンテナ。このアーキテクチャの移行先の環境は Kubernetes でオーケストレーションされているため、次のツールを使用してマイクロサービスをコンテナ化することをおすすめします。
- Docker は、オペレーティング システムレベルでユーザー空間レベルのプログラムを隔離するためのツールです。コンテナと呼ばれるパッケージを実行します。
- Kubernetes は、コンテナ化されたワークロードのための代表的なオーケストレーション ソリューションです。サービス ディスカバリ、ロード バランシング、自己修復の Pod とノード、Secret、構成管理などの機能が用意されています。
- GKE は、Google Cloud の一部である、プロダクション レディなマネージド Kubernetes 環境です。
サービス メッシュを使用して移行を実行するには、次の操作を行います。
- 以前の環境を評価する: 情報を収集し、移行先の環境の要件と、テストと検証のベースラインを確立します。
- 移行先の環境で基盤を構築する: 移行先の環境をプロビジョニングし、Infrastructure as Code 手法を適用して、監査可能、繰り返し可能、かつ自動的にプロビジョニング可能なインフラストラクチャを構築します。
- サービスをデプロイして移行先の環境へのトラフィックのルーティングを開始する: 1 回のオペレーションですべてのマイクロサービス インスタンスを同時にデプロイするか、段階的なデプロイで一度に 1 つのマイクロサービスをデプロイします。
- 以前の環境へのトラフィックのルーティングを停止する: 移行先の環境で実行されているサービスにのみトラフィックをルーティングするようにルーティング ルールを設定します。
- 以前の環境を廃止する: 移行先の環境のプロビジョニング フェーズで設定したロードバランサを指すように DNS レコードを更新します。
このドキュメントでは、このような移行の設計上の考慮事項について説明します。関連するデプロイメント ガイドでは、移行を完了するための詳しい手順について説明しています。
設計上の考慮事項
このセクションでは、信頼性、運用効率、費用、パフォーマンスの最適化に関する特定の要件を満たすアーキテクチャの開発に役立つガイダンスを提供します。
信頼性
以降のセクションでは、移行の信頼性に関する考慮事項について説明します。
段階的な移行戦略を使用する
このアーキテクチャは、単一オペレーションの移行にも使用できますが、段階的な移行戦略を使用することをおすすめします。1 つ以上のアプリケーションを一度に移行する場合、さまざまな課題とリスクが伴います。1 回のオペレーションで移行を完了することは容易ではありません。時間と予算に制約がある場合、1 回のオペレーションでの移行に重点を置くと、新しいアプリケーション機能に取り組むための余力が十分得られなくなります。
一方、機能ごとの段階的な移行では、移行するワークロードのサイズが小さくなるため、全体的な複雑さが少なくなります。1 つの機能のフットプリントが、アプリケーション全体の場合と比較すると小さくなります。リスクが高い 1 回の実行ではなく、段階的な移行を行うことで、小規模な移行イベントにリスクを分散できます。また、段階的な移行では、さまざまな種類の機能に対応するために複数の移行戦略を計画し、設計して開発することもできます。
最初に移行する機能を選択する方法とステートフル機能を移行する方法については、「Google Cloud への移行: ワークロードの評価と検出」の最初に移行するアプリの選択をご覧ください。
コンプライアンス テストスイートを使用する
移行を容易にするために、コンプライアンス テストスイートを使用することをおすすめします。コンプライアンス テストスイートは、環境に対して実行して、指定された要件のセットを満たしているかどうかを確認するテストセットです。環境が有効である場合、要件を満たしています。たとえば、テスト リクエストに対するレスポンスの検証や、アプリケーションの依存関係がインストールされているかどうかの確認を行うことができます。
モニタリング、トレース、サービス メッシュの可視化ツールを使用して、手動で検証を行うことができます。その後、次の方法でテストスイートを実装し、時間の経過とともに進化させることが可能です。
- 負荷テスト: テスト トラフィックを環境に自動的に送信して結果を評価することで、テストスイートを進化させることが可能です。
- コンプライアンス テストツール: 専用のツールを使用して、テストスイートの設計と開発を行うことができます。
移行中と移行後に、ベースラインとしての移行元の環境および移行先の環境に対してコンプライアンス テストスイートを実行します。
テストスイートでは、移行中に次のアスペクトを検証することに集中する必要があります。
- プロビジョニング: 構成する前に、環境で必要となるリソースをプロビジョニングします。
- 構成: 環境でリソースをプロビジョニングした後、アプリケーションのニーズに合わせてリソースを構成します。構成テストスイートによって、環境でアプリケーションをホストするための準備が整っていることを確認できます。
- ビジネス ロジック: 環境のプロビジョニングと構成を検証したら、アプリケーションのビジネス ロジックを検証します。たとえば、リクエストに対するレスポンスを検証できます。
Chef InSpec、RSpec、Serverspec は、自動コンプライアンス テストスイートを開発するためのツールです。どのプラットフォームでも動作し、組み込みコントロールをはじめ、独自のコントロールを実装できるように拡張可能です。
移行先の環境をプロビジョニングするときに、コンプライアンス テストスイートを使用して検証できます。ハードウェアやネットワーク トポロジなど、以前の環境と移行先の環境の最終的な違いを考慮してテストスイートを更新する必要があります。完全アクセス権を持っているオンプレミス環境から、通常はスタック全体への完全アクセス権を持っていないパブリック クラウド環境に移行するということを念頭に置いてください。
以前の環境のロード バランシング レイヤから移行先の環境にトラフィックをルーティングする前に、移行先の環境によって公開されるマイクロサービスに対してビジネス ロジックのコンプライアンス テストスイートを実行することをおすすめします。テストスイートにより、マイクロサービスが期待どおりに動作していることを確認できます。たとえば、サービス メッシュによって公開されるサービスから返されたレスポンスを検証できます。変更をロールバックして以前の環境に戻す必要がある場合に備え、元のルートをバックアップ オプションとして保持できます。本番環境のトラフィックのごく一部を、移行先の環境で実行されているマイクロサービスのインスタンスにルーティングすることで、移行先の環境を確認し、時間の経過とともにトラフィック量を増加させることができます。
クロス環境リクエストを許可しない
コンプライアンス テストの段階では、環境間のリクエストを禁止するようにルーティング ルールを改善することをおすすめします。これにより、クライアント リクエストを以前の環境または移行先の環境に届いたときに、その環境にとどめることができます。環境間のリクエストを禁止することで、移行先の環境を正しく検証できるようになります。これらのリクエストを禁止しないと、知らないうちに、移行先の環境ではなく以前の環境でテストの成功が報告される可能性があります。
以前の環境を廃止する
以前の環境を廃止する前に、次の条件がすべて満たされていることを確認してください。
- 以前の環境で実行されているマイクロサービスのインスタンスにトラフィックがルーティングされていない。
- 移行元の環境のインターフェースからトラフィックが送信されていない。
- 移行先の環境が完全に検証されている。
これらの条件が満たされたら、移行先の環境のプロビジョニング フェーズで設定したロードバランサを指すように DNS レコードを更新できます。移行先の環境の検証が完了していない場合は、以前の環境を廃止しないでください。検証はビジネス ロジックのみに制限しないでください。パフォーマンスやスケーラビリティなど、機能性以外の他の要件も検討する必要があります。
運用効率
以降のセクションでは、移行の運用効率に関する考慮事項について説明します。
以前の環境を評価する
移行計画を設計または実装する前に、以前の環境を評価して情報を収集し、移行先の環境の要件と、テストおよび検証のベースラインを確立する必要があります。まずは、移行するすべてのアプリケーション機能のカタログを構築します。機能ごとに、次の一連の質問に答えることができるようにします（これは質問の一部で、すべてではありません）。
- ランタイム環境とパフォーマンスの要件は何ですか？
- 他の機能との依存関係はありますか？
- この機能はビジネス クリティカルですか？
- この機能はステートレスですか、ステートフルですか？
- 移行にどの程度のリファクタリングが予測されますか？
- この機能によってカットオーバーに余裕が生まれますか？
詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。
ステートレス リソースとステートフル リソース
このアーキテクチャでは、サービス機能（ビジネス ロジックの実装方法）とネットワーク機能（トラフィックをサービス機能にルーティングする方法とタイミング）を分離するために、サービス メッシュを使用しています。付属のデプロイメントでは、Istio をサービス メッシュとして使用しています。
以前の環境では、ほとんどのサービス呼び出しがモノリシック プラットフォームで発生するため、ネットワークは関係していません。マイクロサービス アーキテクチャでは、サービス間の通信がネットワーク経由で行われるため、サービスでこの異なるモデルに対処する必要があります。サービス メッシュでは、ネットワーク通信に対処する機能が抽象化されるため、アプリケーションごとに実装する必要はありません。また、サービス メッシュでは、構成を必要としない安全な通信チャネル、ロード バランシング、トラフィック管理、オブザーバビリティ機能が提供されるため、ネットワーク運用の複雑さも軽減されます。
サービス メッシュをデプロイして構成することで、トラフィックを以前の環境または移行先の環境に動的にルーティングできます。トラフィック管理はメッシュに含まれるサービスに対して透過的であるため、移行をサポートするためにアプリケーションの構成を変更する必要はありません。
このアプローチはステートレスな機能に適していますが、ステートフルでありレイテンシの影響を受けやすい機能、または他の機能と非常に密結合な機能を移行するには、追加の計画とリファクタリングを行う必要があります。
- ステートフル: ステートフル機能を移行する場合、ダウンタイムを最小限に抑え、移行中の同期と整合性の問題を軽減するため、データも移行する必要があります。データ移行戦略の詳細については、「Google Cloud への移行: 大規模なデータセットの転送」のデータ移行方法の評価をご覧ください。
- レイテンシの影響を受けやすい: ある機能が他の機能との通信時にレイテンシの影響を受けやすい場合は、移行プロセス中に追加のコンポーネントをデプロイすることが必要となる可能性があります。この感度を下げるために、データのプリフェッチやレイヤのキャッシュ保存に使用できるプロキシが一般的に使用されます。
- 他の機能との密結合: 2 つ以上の機能が密結合の場合は、同時に移行する必要があります。このアプローチは、アプリケーション全体を移行するよりも簡単ですが、単一の機能を移行するよりも困難となる場合があります。
サービス メッシュにサービスを登録する
以前の環境はサービス メッシュと直接統合されていないため、移行を構成するときに、移行元の環境で実行されているすべてのサービスを手動でサービス メッシュに登録する必要があります。環境がすでに Kubernetes で実行されている場合は、サービス メッシュ API との組み込み統合を使用して登録を自動化できます。
以前の環境を登録したら、サービス メッシュを使用して、以前の環境で実行されているマイクロサービスを公開します。その後、以前の環境のインターフェースから移行先の環境のインターフェースに、マイクロサービスへのトラフィックを段階的に転送できます。
クライアントではロード バランシング レイヤを介して 2 つの環境のインターフェースにアクセスするため、サービスは中断されません。サービス メッシュ内のトラフィック ルーティングはクライアントに対して透過的であるため、クライアントはルーティング構成の変更を意識しません。
費用の最適化
このアーキテクチャでは、課金対象である次の Google Cloud コンポーネントを使用します。
アーキテクチャをデプロイするときに、料金計算ツールを使うと、予想使用量に基づいて費用を見積もることができます。
パフォーマンスの最適化
このアーキテクチャでは、Compute Engine で実行されているサービスと GKE で実行されているサービスとでトラフィックがほぼ均等に分割されます。サービス メッシュは、GKE クラスタと Compute Engine インスタンスのどちらで実行されているかにかかわらず、選択したサービスのインスタンス間でトラフィックを分散します。すべてのトラフィックがサービス メッシュを通過する場合は、Compute Engine で実行されているワークロードをサービス メッシュに直接接続するのではなく、サービス メッシュ内のサービスを指すように再構成する必要があります。DestinationRule リソースを使用して、各サービスのリビジョンのロード バランシング ポリシーを構成できます。
デプロイ
このアーキテクチャをデプロイするには、Istio メッシュ拡張を使用して移行をデプロイするをご覧ください。
次のステップ
- GKE について読む。
- Istio について読む。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。