One-stop dynamic multi-environment construction case

はじめに：起業チームとして、サービスガバナンスの問題に対するワンストップソリューションを迅速に導入できることは非常に素晴らしいことです。ソリューション全体の検討と実装を通じて、R&D チームは K8s、Nginx Ingress、および MSE について深く理解することができました。「当部門の R&D チームには専門の運用保守チームがありません。すべての開発者が各製品の仕組みを深く理解しています。考えてみれば理にかなっています。」
作成者：Li Siyuan、Wu Liangjun

問題の背景


2013 年 12 月に設立された Zhijing Technology は、紡績業界をリードするインターネット企業であり、国のハイテク企業として認定されています。「百布」「全布」「天工」「織景ゴールドバー」「織景紡績スマート製造パーク」「織景スマート倉庫物流パーク」といった事業セクターを運営し、ビッグデータ、クラウドコンピューティング、IoT などの新世代情報技術を活用して、紡績・アパレル業界の情報流、物流、資金流を包括的に連携させ、業界の協働的かつ柔軟でインテリジェントなアップグレードを支援し、紡績・アパレル業界の垂直統合型デジタルスマートサービスプラットフォームの構築に取り組んでいます。



グループ会社のビジネスチームとして設立から 2 年以上が経過し、並行して開発・リリースされるプロジェクトが増加しています。特筆すべきは、現在マイクロサービス分割の初期段階にあり、現在は 35 のマイクロサービスが存在し、分割後は約 60 のマイクロサービスになる予定です。このような状況下、当初は 1 組の開発 / テスト / 本番環境を使用して R&D プロセスを直列で実行していました。プロジェクト数、開発・テスト要件の増加、およびマイクロサービスの分割に伴い、従来の方法はもはや適さなくなりました。以下に、このプロセスで直面した 3 つの問題を簡潔に挙げます。



プロジェクトのテスト環境が占有される


最も典型的な問題は、プロジェクトのテスト環境が障害修正のテスト処理によって頻繁に占有され、プロジェクトのテストが断続的になり、テストに集中できる環境が確保できないことです。同時に、テストプロセスがプロジェクトの並行進行での主なボトルネックとなっており、検証がプロジェクトのイテレーション進捗に影響を及ぼしています。



開発結合デバッグ環境の不安定さ


開発体験を確保するため、開発環境では開発者が自由にデプロイできるようにしています。1 つの環境を共用しているため、異なる開発者が開発環境にリリースすることで、結合デバッグが頻繁に中断されます。多くの開発者はエンドツーエンドのオフライン結合デバッグに切り替え、アップストリームおよびダウンストリームのアプリケーションを個人のマシンにデプロイしています。マイクロサービス化の推進後、特に膨大な数のマイクロサービスアプリケーションを前に、このモデルは実質的に推進困難となりました。開発段階でのコードデバッグの移植性をどのように解決するかが、我々が直面した第 2 の問題です。



オンライングレースケール環境の欠如


第 3 の問題は、最も重要な問題でもあります。以前は、プロダクトマネージャーが機能検証するための専用プレリリース環境が不足していました。新機能はテスト完了後、直接オンライン環境にリリースされます。顧客への悪影響を避けるため、R&D チームはリリース計画を夜間に組むことが多くなります。R&D チームのリリースの満足度はさておき、オンライン環境でのグレースケールリリース機能の欠如は、新機能がリリース後にすべてのユーザーに展開されることを意味します。プロダクト設計の欠陥やコードの脆弱性が発生した場合、その影響はネットワーク全体に及び、リスクは甚大かつ制御不能です。



以上の課題を踏まえ、オフラインでは複数プロジェクトの開発とテストを支えるための分離された複数環境の整備が必要であり、同時にオンラインではグレースケールリリース要件に対応する柔軟なトラフィックルーティング戦略が必要です。



ソリューションの調査と検討


当社の実際の状況を踏まえ、開発チームが運用保守チームに依存しない、すなわち DEV = OPS を目標としています。ワンクリックで論理的に分離された開発 / プロジェクト環境を立ち上げ、プレリリース環境の分離をサポートします。本番環境では、グレースケールルールのトラフィックと自然トラフィックを設定し、フルリンクグレースケールの検証を実施できるようにします。



現在の問題の分析とインターネット上の既存のソリューションを調査した結果、いずれもプロジェクト環境ガバナンスとサービストラフィックガバナンスのソリューションに集約されます。いくつかの一般的なソリューションを簡潔に挙げ、最終的に Alibaba Cloud Microservices Engine (MSE) のフルリンクグレースケールと Cloud Effect アプリケーションデリバリープラットフォーム AppStack を組み合わせた統合ソリューションを選択しました。



独自開発の Ribbon 実装


1.



当社は Spring Cloud フレームワークを使用しています。通常の業務開発では、バックエンドサービス間の呼び出しは Feign または RestTemplate を通じて行われ、Ribbon コンポーネントがロードバランシング機能を担っています。グレースケールの核心はルーティングです。Ribbon のデフォルトロードバランシングアルゴリズムを書き換え、ロードバランシング呼び出しの前にトラフィックルーティングロジックを追加することで、サービストラフィックの転送を制御できます。



このソリューションを実装する場合、大規模な組織ではゼロから 1 へ、そして 100 へと進化させることができます。当社にとって、ルーティング機能だけを実装するのであれば、コアシナリオのみをサポートするシンプルなバージョンを作るのはさほど難しくありません。しかし、成熟して実用的な段階に達するには、専門的な技術リソースを投入して管理・保守する必要があります。同時に、Spring Cloud マイクロサービスフレームワーク自体の複雑さに加え、マイクロサービス数が徐々に増加するにつれてリンクが長くなり、関連するマイクロサービスガバナンスの問題の特定と解決にも多くの時間とコストがかかります。



物理的な分離（ブルーグリーンデプロイ）


2.



このソリューションでは、グレースケール対象のサービスのためにネットワーク的に分離され、リソースが独立した環境を構築し、その環境にグレースケールバージョンのサービスをデプロイします。基本環境とは隔離されているため、基本環境内の他のサービスはグレースケールが必要なサービスにアクセスできません。そのため、これらのサービスをグレースケール環境に冗長デプロイして、呼び出しリンク全体が正常にトラフィック転送を行えるようにする必要があります。さらに、レジストリセンターなどの依存ミドルウェアコンポーネントもグレースケール環境に冗長デプロイして、マイクロサービス間の可視性を確保し、取得するノード IP アドレスが現在のネットワーク環境にのみ属するようにする必要があります。このソリューションでは、これらのビジネスシナリオのためにマシンを増設して複数セットのグレースケール環境を維持する必要があり、運用保守コストとマシンコストが過大となり、コストがメリットを大幅に上回ります。ただし、アプリケーション数が少なく、2、3 つのアプリケーションのみであれば、この方法は非常に便利で受け入れられます。



MSE ラベルルーティング + AppStack アプリケーションオーケストレーション（我々の選択）


これら 2 つの製品のドキュメントは以下のリンクから確認できます：
Cloud Effect アプリケーションデリバリープラットフォーム AppStack：
https://help.aliyun.com/document_detail/321856.html
Alibaba Cloud Microservices Engine (MSE) フルリンクグレースケール：
https://help.aliyun.com/document_detail/170454.html


前述の 2 つの記事を通じて、読者はこれら 2 つの製品について既に概要を理解しているものと想定します。一言で説明すると、AppStack はアプリケーション環境管理とパイプラインリリースを担当し、MSE はトラフィックのフルリンクグレースケールを担当します。



MSE フルリンクグレースケールの重要な概念

MSE ラベルルーティングの以下の図を参照しながら、アプリケーションマーキング、トラフィックカラーリング / 自動カラーリング、識別リンク転送など、MSE ラベルルーティングのいくつかの重要な概念を重点的に紹介します。同時に、以下の図は我々のソリューションの核心原理でもあります。ドメイン名を使用して、異なる論理的に分離された環境を識別します。



3.

コアダイアグラム



1. アプリケーション（サービス）マーキング


コア概念図を参照すると、各アプリケーションには (base/gray) のタグが付与されています。このタグにより、タグに基づいたトラフィックルールを定義できます。



MSE アプリケーションの作成時に、特定のアノテーションと環境変数を使用して MSE アプリケーションをマークします。



特定のアノテーション：
alicloud.service.tag=dev1
環境変数：
spring.cloud.nacos.discovery.metadata.version


4.

特定のアノテーションと環境変数の追加



たとえば、アノテーションによるマーキング後、MSE のラベルルーティングでトラフィックルールを定義できます。また、Nacos 上のサービスにラベル関連のメタデータ（_micro.service.env_）が付与されていることも確認できます。



5.

MSE トラフィックルール設定



6.

Nacos のメタデータ情報



コンテナの環境変数を追加する追加の方法もあります：
spring.cloud.nacos.discovery.metadata.version


この方法は、Nacos のサービスメタデータに version 属性を追加します。たとえば、MSE クラウドネイティブゲートウェイはこの version 属性を使用してトラフィック管理を行い、MSE フルリンクグレースケールは alicloud.service.tag で定義されたタグを使用してトラフィック管理を行います。



7.

グレー関連の環境変数をコンテナに追加



8.

MSE トラフィックルール設定にグレーノードが表示される



9.

Nacos にグレー環境のメタデータ情報が存在する



10.

MSE クラウドネイティブゲートウェイでグレーバージョンを選択可能



2. トラフィックカラーリング / 自動カラーリング


簡単に言うと、トラフィックカラーリングとはトラフィックに特別な識別子を付けることです。HTTP リクエストの場合はリクエストヘッダーに識別情報を載せ、メッセージの場合はメッセージヘッダーに識別情報を載せます。ここでは主に HTTP トラフィックのカラーリングについて説明します。1 つは HTTP リクエストに識別情報を手動で追加する方法です。たとえば、フロントエンドがバックエンド API をリクエストする際に xx:111 という識別情報を追加すると、そのトラフィックは「染色」されたと言えます。自動カラーリングとは、識別子のない HTTP リクエストがタグ付きの Nacos サービスを経由した後、次のサービスを呼び出す際に、その Nacos サービスのラベル情報が自動的にリクエストヘッダーに含まれることです。簡単な例を挙げると、アプリケーション a がアプリケーション b（グレー）を呼び出し、次にアプリケーション b がアプリケーション c を呼び出す場合、x-mse-tag:gray のリクエストヘッダーが自動的に付与されます。これが自動カラーリングです。



ここで特に x-mse-tag:xxx について説明します。これは MSE システムの予約済み識別子です。染色を表すだけでなく、リンク転送（リクエストリンク上の各ノードがこのラベルを順番に伝達する）とデフォルトルーティングルール（xxx で識別されるサービスを優先し、見つからない場合は base サービス、つまり未タグのサービスを選択する）も表します。このデフォルトルーティングルールは明示的に定義する必要はありません。



当社のソリューションでもこの点を特別に活用しています。コア概念図を参照すると、ドメイン名にトラフィック識別子を付与し、Ingress-Nginx でトラフィック識別子を解析して、x-mse-tag:xxx を通じてリンク全体に伝達します。これにより、リンク全体で xxx で識別されるサービスが優先的に選択され、識別子のない base サービスがフォールバックとして使用されます。



3. 識別リンク転送


トラフィックが染色された後、つまりリクエストヘッダーに特定の識別子が付与された後、その識別子を呼び出しリンク内でどのように伝達するかを説明します。たとえば、user-id: 100 というヘッダーを持つ HTTP リクエストが A→B→C を経由する場合、A を呼び出す際に user-id: 100 が付与され、A が B を呼び出す際にも user-id: 100 のリクエストヘッダーが付与され、B が C を呼び出す際にも user-id: 100 が付与される必要があります。これが識別子のリンク転送です。この識別リンク転送により、A/B/C アプリケーションに対して user-id の値に基づくルーティング戦略を定義できます。MSE の識別リンク転送の方法は、環境変数 alicloud.service.header=x-user-id を定義することです。エントリアプリケーション A（すべてのバージョン、グレー + base）に環境変数を追加した後、B と C の呼び出しプロセスでリクエストヘッダー x-user-id が自動的に追加され、A、B、C の各ノードで特定のルールに基づいたルーティングを定義できます。もちろん、特別なリクエストヘッダー x-mse-tag はデフォルトでリンク転送され、MSE がこの識別子を階層的に伝達してデフォルトルーティングルール（タグ優先、base をフォールバック）を実装します。MSE 識別リンク転送の原理は以下の通りです。分散リンクトレーシングフレームワークの実装により、各アプリケーションのプローブがリクエストをインターセプトして識別子を解析し、スレッドスペースに一時的に保存してから、後続の呼び出し時にプローブを通じて次のリクエストに識別子を挿入します。分散リンクトレーシングのフレームワークを通じて識別子の転送が完了します。



11.



Cloud Effect アプリケーションデリバリープラットフォーム AppStack の概要

Cloud Effect AppStack を導入した主な目的は、開発者が MSE に必要な設定作業をホワイトスクリーン管理方式で自ら完了できるようにすることです。同時に、マイクロサービスアーキテクチャでは、アプリケーション分割後に各アプリケーションに独自のオーナーを持たせることを目指しています。



12.



AppStack を通じて、K8s のデプロイメント、サービス、Ingress などの詳細を隠蔽できます。R&D メンバーはアプリケーション + 環境 + パイプラインに着目して作業します。これにより、開発者は AppStack のパイプラインを通じてアプリケーションの環境デプロイメントを完了し、各環境には MSE ラベルルーティングの要件に従って異なるラベルが付けられます。



13.

複数環境でのアプリケーションデプロイメント



14.

MSE ラベルルーティングの要件に従い各環境に異なるラベルを付与



ここでは AppStack のコア機能の詳細には立ち入りません。主にアプリケーションオーケストレーションを使用して各アプリケーションの各環境をデプロイ可能にし、MSE ラベルルーティングに必要な各種環境変数とアノテーションを設定できるようにすることが目的です。



我々のソリューション


前述の機能を調査した上で、当社の実際のシナリオとビジネスニーズ、および異なる環境の特性に基づいて、複数環境の抽象化を定義しました。これに基づいて、ワンストップの動的マルチ環境機能を構築し、主要なシナリオに対して異なる実装を設計しました。環境の定義


Alibaba Cloud Microservices Engine (MSE) のラベルルーティングと Cloud Effect アプリケーションオーケストレーション AppStack の調査を通じて、前述の問題と組み合わせ、最終的に R&D システム全体に必要な環境システムを定義しました。複数セットの開発環境（基本環境を含む）+ 複数セットのプロジェクト環境（基本環境を含む）+（統合）テスト環境 + プレリリース環境 +（グレースケール対応）本番環境で構成され、以下の図の通りです。



15.



複数セットの開発環境：開発段階での複数プロジェクトの結合デバッグをサポートすることが目標です。核心的な要件は、各プロジェクトの動的な分離とデバイスクラウド相互接続のサポートです。プロジェクトの動的分離とは、各プロジェクトが独自の開発結合デバッグ環境を持ち、変更されたアプリケーションのみをデプロイすればよいことを意味します。デバイスクラウド相互接続は、ローカルで実行中のアプリケーションを MSE システムに登録してローカルデバッグを実現します。2 つの R&D チームはポイントツーポイントでローカルデバッグを行い、問題を特定できます。基本開発環境はフォールバックサービスの呼び出しを担当します。各アプリケーションの本番デプロイ後、基本開発環境を同期更新して、基本環境が最新の本番バージョンであることを保証する必要があります。



複数セットのプロジェクト環境：大規模な技術改革や主要なビジネスプロジェクトなど、長期間を要する大規模プロジェクトをサポートすることが目標です。これらのプロジェクトは、テスト環境を長期間占有して内外の関係者と安定したテストを実施する必要があります。核心的な要件は、各プロジェクトの動的な分離です。プロジェクトの動的分離の定義は前述と同じです。



テスト環境：日常的な障害修正や、統合してリリースする必要のある複数の小規模プロジェクトなど、短期間で迅速なプロジェクトテストと統合テストをサポートすることが目標です。また、日次の自動化テストの実行環境でもあります。プロジェクト環境の機能ブランチも、テスト環境の自動化テストに合格してからオンライン化する必要があります。



プレリリース環境：プロダクトマネージャーが実環境でプロダクトの機能検証と受け入れテストを実施することをサポートすることが目標です。プレリリース環境で使用するデータベースなどのインフラストラクチャは本番環境と一致しています。もちろん、システム設計にはより高い要件が課されます。たとえば、上位互換性を維持する必要があり、データベースではカラムの追加はできても削除はできず、SQL で select * を使用できないなどの制約があります。DMS を使用してデータベーススキーマの変更を制約し、コードレビューで保証しています。詳細は省略します。



本番環境：ルールベースのトラフィック + 自然トラフィックのフルリンクグレースケールをサポートすることが目標です。ここでのルールベースのトラフィックとは、明確な特徴を持つトラフィックを指します。MSE のトラフィックルールでリクエストヘッダー、パラメータ、Cookie、本文のデータなどがルールに適合するリクエストを明確に定義できます。自然トラフィックはその逆で、特徴を指定しません。たとえば、全トラフィックの 1% をグレースケール環境にルーティングする場合を自然トラフィックと理解しています。



全体として、現在の環境システムでは、開発環境とプロジェクト環境が動的な分離を伴うため、基本環境をデプロイしてサービス機能を満たす必要があります。この基本環境は、MSE ラベルルーティングでの未タグ（base）アプリケーションの提供者でもあります。



この環境システムの運用フローは主に次の通りです：



1. 機能ブランチを開発環境にプルし、フロントエンドとバックエンドのローカル開発と結合デバッグを行い、その後プロジェクト環境でテストする



2. プロジェクト環境でテストチームによるテストが完了後、アプリケーションを（統合）テスト環境にデプロイする



3. （統合）テスト環境で他の機能ブランチと統合し、自動化テストと簡単な検証が完了後、プレリリース環境にデプロイする



4. プロダクトマネージャーがプレリリース環境で機能の受け入れテストを実施し、合格後に本番環境へリリースしてグレースケール検証を行う



5. 本番環境でルールベースのトラフィック + 自然トラフィックによるグレースケール検証を行い、合格後にすべてのトラフィックをルーティングする



6. 最後に、機能ブランチをトランクにマージした後、最新の本番バージョンで開発 / プロジェクトの基本環境を更新する