A brief analysis of microservice full-link grayscale solutions

単一アーキテクチャでのサービス公開

まず、単一アーキテクチャでサービスモジュールの新バージョンをリリースする方法を見ていきましょう。次の図に示すように、Cart サービスモジュールに新バージョンのバージョンアップが必要です。

Cart サービスはアプリケーションの不可欠な一部であるため、新バージョンをオンラインにする際は、アプリケーション全体をコンパイル、パッケージ化、デプロイする必要があります。サービスレベルの公開に関する課題は、アプリケーション全体のデプロイメントの課題となります。対応するサービスの新しいバージョンが独立したサービスではないことを踏まえた、効果的なリリース戦略を策定する必要があります。

従来から、業界ではブルーグリーンリリースやカナリアリリースなど、成熟したサービスリリースの事例があります。ブルーグリーンリリースでは、新バージョンを旧バージョンと同じマシン仕様と台数で冗長デプロイする必要があります。つまり、サービスは同一の 2 つのデプロイメント環境を持つことになります。ただし、この時点では旧バージョンのみが外部サービスを提供し、新バージョンはホットスタンバイとして待機します。サービスを新バージョンに切り替える際は、すべてのトラフィックを新バージョンに向けるだけでよく、旧バージョンはホットスタンバイとして待機します。この例の模式図を以下に示します。トラフィックの切り替えは、L4 プロキシに基づくトラフィック制御で完了できます。

ブルーグリーンリリースでは、全体のトラフィック切り替えを行うため、元サービスのマシン規模に基づいて新バージョンの環境をクローンする必要があります。これは、元の 2 倍のマシンリソースを必要とすることを意味します。カナリアリリースの中心的な考え方は、リクエスト内容またはリクエストトラフィックに基づいて、オンライントラフィックの一部を新バージョンに転送し、カナリア検証がパスされた後に新バージョンへのリクエストトラフィックを段階的に調整することです。これは段階的なリリース方式です。この例におけるカナリアリリースの模式図を以下に示します。コンテンツベースまたは比率ベースのトラフィック制御は、L7 プロキシを持つマイクロサービスゲートウェイを通じて実現する必要があります。

その中で、トラフィックルーティングはコンテンツベースのカナリア方式です。たとえば、リクエストに header tag=gray を持つトラフィックを対応する v2 バージョンにルーティングします。トラフィックシフティングは比率ベースのカナリア方式で、オンライントラフィックを異なる方式で分割します。ブルーグリーンリリースと比較して、カナリアリリースはマシンリソースコストとトラフィック制御能力の面で優れていますが、リリースサイクルが長く、運用インフラに対する要件が高いというデメリットがあります。

マイクロサービスアーキテクチャでのサービス公開

分散マイクロサービスアーキテクチャでは、アプリケーションから分割されたサービスは独立してデプロイ、運用、バージョンアップされます。単一サービスの新バージョンをオンラインにする際、もはや対応する全体のバージョンを起動する必要はなく、各マイクロサービスのリリースプロセスに集中すればよいのです。

Cart サービスの新バージョンを検証するために、仲介リンク全体を通じて何らかの方式でトラフィックを Cart のカナリアバージョンに選択的にルーティングできます。これはマイクロサービスガバナンスの分野におけるトラフィックガバナンスの課題です。一般的なガバナンス戦略には、プロバイダーベースとコンシューマーベースのガバナンス戦略があります。

1. プロバイダーベースのガバナンス戦略。Cart のトラフィックフロールールを設定し、ユーザーが Cart にルーティングする際に Cart のトラフィックフロールールを使用します。

2. コンシューマーベースのガバナンス戦略。ユーザーのトラフィック流出ルールを設定し、ユーザーが Cart にルーティングする際にユーザーのトラフィック流出ルールを有効にします。

さらに、これらのガバナンス戦略は前述のブルーグリーンリリースやカナリアリリースのシナリオと組み合わせて、真のサービスレベルのバージョンリリースを実現できます。

フルリンクカナリアリリースとは

上記のマイクロサービスシステムで Cart サービスを公開するシナリオを引き続き考えます。この時点で Order サービスの新バージョンもリリースする必要がある場合、この新機能は Cart サービスと Order サービスの両方にまたがる変更を含むため、カナリア検証中にカナリアトラフィックが Cart サービスと Order サービスの両方のカナリアバージョンを通過できるようにする必要があります。次の図に示す通りです。

前項で提案した 2 つのガバナンス戦略に基づき、Order サービス用のガバナンスルールを追加で設定し、カナリア環境の Cart サービスからのトラフィックが Order サービスのカナリアバージョンに転送されるようにする必要があります。このアプローチは論理的には正しいように見えますが、実際のビジネスシナリオでは、ビジネス内のマイクロサービスの規模と数はこの例をはるかに超えています。1 つのリクエストリンクはいくつものマイクロサービスを通過する可能性があり、新機能のリリースには複数のマイクロサービスが同時に変更される場合もあります。また、ビジネス内のサービス間の依存関係は複雑で、リリースが頻繁に行われ、複数バージョンの並行開発が進むにつれて、トラフィックガバナンスルールはますます肥大化し、システム全体の保守性と安定性に悪影響をもたらしています。

上記の課題に対処するため、開発者は実際のビジネスシナリオと本番環境での経験に基づいて、エンドツーエンドのカナリアリリース方式、すなわちフルリンクカナリアリリースを提案しました。フルリンクカナリアリリースのガバナンス戦略は、リンクが通過する特定のマイクロサービスに関わらず、仲介チェーン全体に焦点を当てます。トラフィック制御は、リクエストリンクからリクエストリンクへのサービス転送に依存します。わずかなガバナンスルールだけで、ゲートウェイから全バックエンドサービスに至る複数のトラフィック分離環境を構築でき、密接に関連する複数サービスのスムーズで安全なリリースと、複数バージョンのサービスの同時開発を効果的に保証し、ビジネスの急速な発展をさらに促進します。

フルリンクカナリアリリースソリューション

実際のビジネスシナリオでフルリンクカナリアリリースをどのように迅速に実装できるでしょうか。従来は主に、物理環境分離と論理環境分離の 2 つのソリューションがありました。

物理環境分離

物理環境分離は、その名の通り、マシンの複雑性を増すことで真のトラフィック分離環境を構築します。

この種のシナリオでは、カナリアサービス向けにネットワーク的に隔離された独立リソース環境が必要で、サービスのカナリアバージョンをデプロイします。正式環境から隔離されているため、正式環境内の他のサービスはカナリアを必要とするサービスにアクセスできません。そのため、これらのオンラインサービスをカナリア環境にも冗長デプロイして、仲介リンク全体がトラフィックを正常に転送できるようにする必要があります。さらに、レジストリなどの他の依存ミドルウェアコンポーネントもカナリア環境に冗長デプロイして、マイクロサービス間のアクセス性を確保し、取得されるノード IP アドレスが現在のネットワーク環境のみに属することを保証する必要があります。

主にエンタープライズテスト環境やプレリリース開発環境の構築に適用されるこの方式は、オンラインカナリア公開やトラフィック誘導のシナリオに対して十分な柔軟性を備えていません。さらに、マイクロサービスアーキテクチャでは複数バージョンのマイクロサービスの共存は一般的であり、これらのビジネスシナリオに対して物理環境方式で複数セットのカナリア環境を維持する必要があります。環境数が多い場合、運用コストとマシンコストが膨大になり、コストが利益をはるかに超えます。環境数がわずか 2、3 セットであれば、この方式は依然として実用的で受け入れられます。

論理環境分離

もう 1 つのソリューションは、論理環境分離を構築することです。サービスのカナリアバージョンのみをデプロイすればよく、トラフィックが仲介リンクを通過する際、ゲートウェイ、ミドルウェア、および通過するマイクロサービスがカナリアトラフィックを識別し、対応するサービスのカナリアバージョンへ動的に転送します。次の図に示す通りです。

上記の図は、この方式の効果をよく示しています。異なる色で異なるバージョンのカナリアトラフィックを表しています。マイクロサービスゲートウェイとマイクロサービス自体の両方がトラフィックを識別し、ガバナンスルールに基づいて動的に判断する必要があることがわかります。サービスバージョンが変更されると、この呼び出しリンクの転送もリアルタイムで変化します。マシンベースのカナリア環境と比較して、この方式はマシンコストと運用人件費を大幅に削減できるだけでなく、開発者がフルリンクにわたってオンライントラフィックを迅速かつ正確に制御するのに役立ちます。

では、フルリンクカナリアリリースをどのように実現するのでしょうか。上記の議論を通じて、以下の課題を解決する必要があります。

1. リンク上の各コンポーネントとサービスが、リクエストトラフィックの特性に基づいて動的にルーティングできること。

2. サービス配下の全ノードをグループ化して、バージョンを区別すること。

3. トラフィックにカナリア識別子とバージョン識別子を付与すること。

4. 異なるバージョンのカナリアトラフィックを識別できること。

次に、上記の課題を解決するために必要な技術を紹介します。

ラベルルーティング

ラベルルーティングは、サービスノード情報をサブスクライブするサービスコンシューマが、異なるタグ名とタグ値に基づいてサービス配下の全ノードをグループ化し、必要に応じてサービスの特定のノードグループ (サブセット) にアクセスできるようにします。サービスコンシューマは、サービスプロバイダノード上の任意のラベル情報を使用できます。選択したラベルの実際の意味に基づいて、コンシューマはより多くのビジネスシナリオにラベルをルーティングできます。

ノードマーキング

では、サービスノードに異なるタグをどのように付けるのでしょうか。現在主流のクラウド技術に後押しされ、ほとんどのビジネスはコンテナ化への移行を積極的に進めています。ここでは、コンテナベースのアプリケーションを例に、Kubernetes Service をサービス検出として使用する場合と、より軽量な Nacos レジストリを使用する場合の 2 つのシナリオで、サービスワークロードノードへのラベル付け方法を紹介します。

Kubernetes Service をサービス検出として使用する業務システムでは、サービスプロバイダがサービスリソースを API サーバーに送信することでサービスの公開を完了します。サービスコンシューマは、そのサービスリソースに関連付けられた Endpoint リソースをリッスンし、Endpoint リソースから関連する業務用 Pod リソースを取得し、ノードからラベルデータを読み取って、ノードのメタデータ情報として使用します。したがって、業務アプリケーション記述リソースの デプロイメント の Pod テンプレート内のノードにラベルを追加するだけで済みます。

Nacos をサービス検出として使用する業務システムでは、一般的にマイクロサービスフレームワークに基づいてマーキング方式を決定する必要があります。Java で Spring Cloud マイクロサービス開発フレームワークを使用している場合、ビジネスコンテナに対応する環境変数を追加することでタグの追加操作を完了できます。ノードに version=gray のカナリア識別子を付与したい場合は、ビジネスコンテナに「spring.cloud.nacos.discovery.metadata.version=gray」を追加します。これにより、フレームワークがノードを Nacos に登録する際に「version=gray」のラベルが付与されます。

トラフィックカラーリング

リクエストリンク上のコンポーネントは、異なるカナリアトラフィックをどのように識別するのでしょうか。答えはトラフィックカラーリングです。リクエストトラフィックに異なるカナリア識別子を付与することで区別します。リクエストの発生源でトラフィックにフラグを立てることができ、フロントエンドは異なるユーザー情報やプラットフォーム情報に基づいてリクエスト送信時にトラフィックをマークします。フロントエンドでこれができない場合は、マイクロサービス側で特定のルーティングルールに一致するリクエストに動的にトラフィック識別子を付与することもできます。さらに、トラフィックがリンク上のカナリアノードを通過する際、リクエスト情報にカナリア識別子が含まれていない場合は、動的にカラーリングを行う必要があります。これにより、後続のフローでトラフィックがサービスのカナリアバージョンに優先的にアクセスできるようになります。

分散トレース

もう 1 つの非常に重要な課題は、カナリア識別子がリンク全体で直接伝達されるようにする方法です。リクエストがソースで受信された場合、リクエストがゲートウェイを通過する際、ゲートウェイはプロキシとして機能するため、開発者がゲートウェイのルーティング戦略でリクエスト内容の変更を実装していない限り、リクエストをそのまま次のサービスに転送します。次に、リクエストトラフィックは最初のマイクロサービスから次のマイクロサービスへ転送されます。新しい転送リクエストはビジネスコードのロジックに基づいて生成されます。この新しい転送リクエストにカナリア識別子を付与して、リンク上で伝達できるようにするにはどうすればよいでしょうか。

単一アーキテクチャから分散マイクロサービスアーキテクチャへの進化に伴い、サービス間の連携は同じスレッド内のサービス間連携から、ローカルプロセス内およびリモートプロセス間のサービス間連携へと変化しました。さらに、リモートサービスは複数レプリカでデプロイされる可能性があり、複数リクエストが通過するノードは予測不可能で不確実です。連携の各ホップでネットワーク障害やサービス障害が発生する可能性があります。分散トレース技術は、分散システム内のリンクの入出力リクエストを詳細に記録します。その中核となる考え方は、グローバルに一意なトレース ID と各リンク用のスパン ID を通じて、リクエストリンクが通過するノードとリクエストにかかった時間を記録することです。ここで、トレース ID はリンク全体を通じて伝達される必要があります。

分散トレースの考え方を利用して、カナリア識別子などの定義情報も転送できます。業界で一般的に使用されている分散トレース製品はすべて、ユーザー定義データのリンク伝達をサポートしており、そのデータ処理プロセスを次の図に示します。

論理環境分離

まず、動的ルーティング機能を維持する必要があります。Spring Cloud や Dubbo 開発フレームワークでは、アウトバウンドトラフィック用のフィルターを定義し、このフィルター内でトラフィック識別とラベルルーティングを完了できます。同時に、分散トレース技術を使用してトラフィック識別のリンク伝達とトラフィックの動的モニタリングを完了する必要があります。さらに、中規模のトラフィックガバナンスプラットフォームを導入し、各ビジネスラインの開発者がフルリンクカナリアルールを定義できるようにする必要があります。次の図に示す通りです。

全体的に見て、フルリンクカナリアリリースの実現には、コストと技術的複雑性、およびその後のメンテナンスと拡張の両面で高い要件がありますが、リリースプロセス中のアプリケーションの安定性をより細かい粒度で向上させることができます。