クラウドネイティブ開発でこのような問題点に遭遇したことはありませんか?

背景

クラウドネイティブ時代において、国内外の多くのクラウドベンダーが強力な技術的配当をリリースしています。安価で安定的かつ効率的なクラウド設備をどのように活用するかが、今日の大きな課題となっています。クラウド上では、仮想ネットワーク、仮想マシン、データベース、メッセージキューなどのインフラストラクチャとミドルウェアを簡単に作成できます。コンテナ サービス、EDAS、SAE、関数コンピューティングなどの PaaS およびサーバーレス サービスを使用して、アプリケーション管理の負担を軽減することもできます。

しかし、物事は順調に進んだわけではありませんでした。アプリケーションのクラウドへの移行は止めることのできない歴史的トレンドですが、開発者はすぐにクラウド移行のもう一方の側面、つまりクラウドとオフライン環境間のネットワーク接続の欠如によって引き起こされる開発エクスペリエンスの断片化の感覚を経験しました。開発者は、クラウドに移行する前に、コード開発、テスト、共同デバッグなどの開発プロセスのクローズドループをローカルで完了できます。クラウドに移行すると、データベース、キャッシュ、メッセージ キュー、その他のマイクロサービス アプリケーションがクラウド上の仮想ネットワークに展開され、開発プロセスをローカルで完了できなくなります。

彼が中東の裕福な人であれば、ネットワークに接続するために物理的な専用回線を使用することを検討するかもしれません。なぜなら、光ファイバー敷設費、建物内光ケーブルレンタル費、港湾占有費、交通費などに数百万ドルを支払うだけでよく、同時にセキュリティチームを説得して環境が完全に接続されるようにする必要があるからです。

専門的な運用・保守担当者であれば、ネットワークを接続するために仮想プライベート ネットワークを設定することを検討するかもしれません。彼は仮想プライベート ネットワーク サーバーの構築に多大な労力を費やしましたが、同僚がまだそれを使用できないことに気づき、次のように不満を漏らしました。

「VPN をオンにすると、ローカル システムのネットワーク トラフィック全体がクラウドに転送され、他の操作ができなくなります。」 「VPN の設定に加えて、アプリケーションの実行パラメータも設定する必要があり、面倒すぎる！」 「クラウド サービスがローカル サービスを呼び出せないのはなぜですか? クラウド ネットワーク ルートを追加しましたか?」...

こうした問題を見ると、運用・保守担当者も疲れを感じてしまいます...

現在、当社は多額の費用や人手を費やすことなく、すぐに使用できるプラグイン ツールを提供しています。 IDE 内のスイッチをオンにするだけで、IDE によって起動されたアプリケーションを通じてクラウド環境内のデータベース、MQ、キャッシュなどのマイクロサービスにアクセスできるようになります。すべての作業はプラグインによって実行されます。

導入

このツールは、弊社が独自に開発した「エンドクラウド相互接続」プラグインです。 「エンド」は開発エンド、「クラウド」はクラウドネットワークを指します。何らかの方法で「エンド」と「クラウド」間の双方向通信を実現し、従来の仮想プライベート ネットワークの問題はありません。

エンドクラウド相互接続機能は、クラウドツール製品 Alibaba Cloud Toolkit (略称 ACT) に統合されており、Intellij IDEA と Eclipse の 2 つの IDE をサポートしています。インストールするには、プラグイン マーケットで「Alibaba Cloud Toolkit」を検索するだけです。たとえば、Intellij IDEA では次のように検索します。

私たちは2018年にエンドクラウド相互接続プロジェクトの研究開発を開始しました。この過程で、さまざまな規模のバージョンを繰り返し、3つのマイルストーンを通過しました。これまでに何十万人もの人々に利用されてきました。以下に、その機能サポートと実装の原則を紹介します。

エンドツーエンドのクラウド相互接続 1.0

フェーズ 1.0 では、ローカル サービスとクラウド サービス間の双方向の相互接続の問題が解決され、ローカル サービスがクラウド リソースにアクセスできるだけでなく、クラウド サービスと通信することも可能になります。

双方向の相互接続

以下は、エンドクラウド相互接続のコアアーキテクチャであり、チャネルサービスとプロキシマシンの 2 つのモジュールに分かれています。

このうち、モジュールの機能は次のとおりです。

プロキシ マシン: クラウド内のトラフィックの転送を担当します。エンドクラウド相互接続ソリューションでは、プロキシ マシンに対する要件が非常に低くなります。通常の仕様の ECS は、「乞食バージョン」のプロキシ マシンとして機能します。さらに、Debian、Ubuntu、Redhat などの Linux システムには、エンドクラウド相互接続に必要な基盤ライブラリがすでに含まれているため、追加のソフトウェアをインストールする必要はありません。チャネル サービス: ローカル トラフィックの転送を担当します。エンドクラウド相互接続スイッチをオンにしてアプリケーションを起動すると、プラグインによってチャネル サービス プロセスがローカルで起動されます。このプロセスの責任は非常に単純です。ローカル アプリケーションとクラウド プロキシ マシン間のトラフィックの転送のみを担当し、その他の操作は行いません。

チャネル サービスとプロキシ マシンは暗号化されたチャネルを使用して通信し、仲介者はチャネル内のデータを盗むことはできません。マイクロサービス アプリケーションでは、Java ネイティブ プロキシ パラメータと独自開発のトラフィック インターセプト ソリューションを組み合わせて、アプリケーション トラフィックをチャネル サービスに転送します。

開発者が IDE でアプリケーションを起動すると、エンドクラウド相互接続プラグインが自動的にチャネル サービスを開始し、関連するパラメータをアプリケーションに挿入します。起動後、アプリケーション トラフィックは手動による介入なしに自動的にチャネル サービスに転送されます。

アーキテクチャの観点から見ると、エンドクラウド相互接続は仮想プライベート ネットワークに似ており、どちらもサーバーとクライアントに分かれています。しかし実際には、次の図にまとめられているように、両者の間には大きな違いがあります。

両者とも「クラウドからローカルへのアクセス」をサポートしていますが、具体的な原理は異なります。仮想プライベート ネットワーク ソリューションを採用した場合、他のクラウド サービスがローカル サービスにアクセスするときに、ネットワーク ルーティングを手動で構成する必要があります。そうしないと、ネットワークにアクセスできなくなります。マイクロサービス フレームワークを変換することで、エンド クラウド相互接続により、クラウド サービスがプロキシ マシンを呼び出すことが可能になり、ネットワーク ルーティングを設定せずにプロキシ マシンを介してローカル アプリケーションに転送されます。使いやすさとセキュリティの面では、エンドクラウド相互接続は仮想プライベート ネットワークよりも優れています。

エンドツーエンドのクラウド相互接続 2.0

1.0 フェーズでは、最も基本的な開発ニーズを満たす、ローカルとクラウド間の双方向通信を実現しました。実際のビジネスでは、顧客はより高い要求を提示しています。

弊社の顧客の 1 社には大規模な R&D チームがあり、全員が開発にエンドクラウド相互接続を使用しています。しかし、共同デバッグ中に問題が発見されました。R&D 担当者 A によって開始されたサービス呼び出しが、R&D 担当者 B の予期されたローカル ノードではなく、他のノードに転送されることがありました。この問題は、マイクロサービス フレームワークのルーティング メカニズムによって発生します。環境内にサービス用のノードが複数ある場合、呼び出しにはランダム (またはラウンドロビン) アルゴリズムが使用されます。マイクロサービス モジュールの数が増え、リンクが長くなるほど、この問題は深刻になります。

2.0 では、複数人による精密な共同デバッグ機能が提供され、サービス要求を「ターゲット」にすることができ、サービス共同デバッグの効率が大幅に向上します。さらに、クラウド環境におけるマイクロサービス ノードのローカル デバッグを容易にし、デバッグの効率を向上させるエージェント ベースのリモート デバッグ機能も提供しています。

同時に、End-Cloud Interconnect 2.0は、水平的な製品サポートを通じて、EDAS、SAE、MSEなどのクラウドネイティブ製品の開発者にサービスを提供でき、広く賞賛されています。

複数人による精密共同デバッグ

次の図は、複数人による共同デバッグの典型的なシナリオを示しています。

Xiao Wang はサービス A を担当し、Xiao Zhang はサービス B を担当しています。要件の反復で、コード開発が完了し、現在は共同デバッグを行っています。マイクロサービス フレームワークは呼び出しにランダム (またはラウンドロビン) 戦略を使用するため、次の 2 つの問題が発生します。

テスターの Xiao Ma が環境で機能テストを実行しています。テスト要求が Xiao Wang と Xiao Zhang のローカル ノードに呼び出され、テストが期待どおりに実行されなくなります。 Xiao Wang によって開始されたテスト要求は、彼と Xiao Zhang のノードではなく他のノードに呼び出され、共同デバッグの効率が低下します。

複数人による精密な共同デバッグ機能により、Xiao Wang が開始したリクエストのみが彼のローカル ノードと Xiao Zhang のローカル ノードに転送され、テスト Xiao Ma のリクエストは安定したクラウド環境でのみ呼び出されます。

Xiao Wang と Xiao Zhang が行う必要があるのは比較的簡単です。コンソールでフルリンクフロー制御機能を有効にし、テスト用のフロー制御環境を作成するだけです。フロー制御環境では、要求識別ルールを構成し、Cookie、ヘッダー、要求パラメータなどのディメンションを通じてテスト要求であるかどうかを判断できます。判定が通れば、環境内のノードにリクエストが呼び出されます。

次に、Xiao Wang と Xiao Zhang は、次に示すように、IDE でこのテスト環境にローカル ノードを追加できます。

設定が完了すると、特性を満たすリクエストのみが Xiao Wang と Xiao Zhang のノードに呼び出されます。下の図では、ヘッダーに「test」が含まれるリクエストのみがノードに呼び出されます。

リモートデバッグ

リモート デバッグは常にトラブルシューティングの重要な手段ですが、クラウド ネイティブ環境ではリモート デバッグは簡単な作業ではありません。これは、デフォルトでは、クラウド上のマイクロサービス ノードは通常、パブリック ネットワークからアクセスできないためです。リモート デバッグが必要な場合は、ターゲット ノードへのパブリック ネットワーク アクセスを開き、デバッグ ポート トラフィックを許可するようにセキュリティ ポリシーを設定する必要があります。

現在、3 つのサービス A、B、C があり、各サービスに 3 つのノードがある場合、それぞれ 3 つのセキュリティ グループを作成し、9 つのパブリック ネットワーク カードをマシン ノードにバインドする必要があります。以下のように表示されます。

このアプローチには次の問題があります。

コストの無駄: 各マイクロサービス ノードはパブリック ネットワーク カードにバインドする必要があり、コストはテスト ノードの数と正の相関関係にあります。複雑な構成: クラウドでは、マシン ノードを維持して「必要なときに構築し、使用されていないときにリリースする」というオンデマンド使用目的を達成するために、弾性スケーリング戦略が採用されることがよくあります。新しいマシン ノードを作成するたびに、パブリック ネットワーク カードとセキュリティ グループを個別に構成する必要があり、使いにくくなります。セキュリティ リスクが存在します: すべてのマイクロサービス ノードがパブリック ネットワークに公開されると、セキュリティ リスクが増大します。

一部のシナリオでは、セキュリティ要件により、イントラネット マシン ノードはパブリック ネットワーク カードをマウントできません。これらの問題に対して、End-Cloud Interconnect は以下に示すようにプロキシベースのリモート デバッグをサポートしています。

デバッグ要求はチャネル サービスを通じてエージェントに転送され、エージェントによってターゲット デバッグ ノードに転送されます。トンネル サービスとプロキシ マシン間のチャネルは暗号化されます。セキュリティ要件が非常に厳しいシナリオでは、セキュリティ グループ (またはホワイトリスト) ポリシーを使用して、プロキシ マシンのセキュリティ レベルをさらに向上させることができます。

使用方法に関しては、Alibaba Cloud Remote Debug を設定するだけで済みます。構成内容は基本的に IDE に付属するリモート デバッグ構成と同じですが、次に示すようにプロキシを使用した接続をサポートしています。

設定項目は次のとおりです。

プロキシ: クラウド プロキシ マシンを指定します。プラグインを実行すると、手動による介入なしにチャネル サービス接続エージェントが自動的に起動されます。ホスト: リモート デバッグのターゲット マシン ノードの IP を指定します。図は172.16.0.1を示しています。ポート: リモート デバッグ用のターゲット マシンのデバッグ ポートを指定します。写真は5005です。

クラウドネイティブ製品サポート

End-Cloud Interconnect 2.0 は、Alibaba Cloud 上の 3 つの主要なマイクロサービス製品、EDAS (エンタープライズ分散アプリケーション サービス)、SAE (サーバーレス アプリケーション エンジン)、MSE (マイクロサービス エンジン) をサポートしています。これら 3 つの製品はすべて、さまざまな企業のニーズを満たすマイクロサービス ガバナンス機能をサポートしています。製品の特徴は次のとおりです。

エンタープライズレベルの分散アプリケーション サービス EDAS (Enterprise Distributed Application Service): アプリケーションのライフサイクル管理と監視のためのワンストップ PaaS プラットフォームです。 Kubernetes/ECSへのデプロイをサポートし、Java/Go/Python/PHP/.NetCoreなどの多言語アプリケーションのリリース、運用、サービスガバナンスを非侵襲的にサポートします。 Java は過去 5 年間に Spring Cloud と Apache Dubbo のすべてのバージョンをサポートしており、Service Mesh はワンクリックで有効にして多言語アプリケーションに対応できます。 Serverless App Engine (SAE): サーバーレス アーキテクチャとマイクロサービス アーキテクチャの統合を実現し、オンデマンド使用量と従量課金制を真に実装して、アイドル状態のコンピューティング リソースを節約します。また、IaaS の運用・保守が不要となり、開発・運用効率も向上します。 SAE は、Spring Cloud や Dubbo などの一般的なマイクロサービス アーキテクチャをサポートし、コンソール、Jenkins、クラウド エフェクト、プラグインなどのデプロイメント方法をサポートします。マイクロサービス アプリケーションに加えて、Docker イメージを通じて任意の言語でアプリケーションをデプロイすることもできます。 Micro Service Engine (MSE): 業界の主流であるオープンソース マイクロサービス エコシステム向けのワンストップ マイクロサービス プラットフォームであり、マイクロサービス ユーザーがオープンソース マイクロサービス テクノロジーを使用して、より安定的、便利、低コストでマイクロサービス システムを構築できるように支援します。完全に管理された登録センター、構成センター (Nacos/ZooKeeper/Eureka と互換性あり)、ゲートウェイ (Zuul/Kong/Spring Cloud Gateway と互換性あり)、および非侵入型のオープンソースの拡張サービス ガバナンス機能を提供します。

したがって、EDAS ユーザー、SAE ユーザー、MSE ユーザーのいずれであっても、エンドクラウド相互接続機能を使用してクラウド開発の効率を向上させることができます。プラグインに関しては、製品自体の違いを除いて、これら 3 つの製品の設定手順は基本的に同じです。設定ページは次のようになります。

今後は、Alibaba Cloud 上でより多くのクラウドネイティブ製品の相互接続をサポートするとともに、Alibaba Cloud 外のクラウドネイティブ開発者にもサービスを提供していきます。乞うご期待。

エンドツーエンドのクラウド相互接続 3.0

バージョン 2.0 では、Java アプリケーションとクラウド間の相互運用性の問題が解決され、多くの詳細が比較的完全なレベルにまで洗練されていますが、コンテナー フィールドと診断機能のサポートが欠けています。これらの機能は 3.0 フェーズで完成しました。

Kubernetes ユーザーの場合は、追加のクラウド プロキシ マシンを構成せずに、3.0 プラグインの Kubernetes プロキシ機能を使用できます。

Java 以外の言語を使用している場合、またはアプリケーション実行環境に特定の要件がある場合は、3.0 プラグインのコンテナー レベルの相互接続機能を使用して、Docker でアプリケーションをローカルで実行できます。 Docker コンテナでは、アプリケーションは通常どおりクラウド サービスやリソースにアクセスでき、トラフィックはプロキシを介して自動的に転送されます。

ローカルで実行されているアプリケーションで発生する呼び出し例外をどう処理すればよいか分からない場合は、3.0 プラグインのローカル リンク診断機能を使用できます。ローカルアプリケーションの呼び出しリンクを一元的に収集し、呼び出し例外が一目でわかるようにします。

これらの機能については以下で詳しく説明します。

Kubernetes エージェント

バージョン 3.0 の Kubernetes プロキシ機能では、Kubernetes クラスターに基づいてプロキシ チャネルを自動的に開くことができます。

Kubernetes 指向の開発では、kubectl コマンドと kubeconfig 構成ファイルを通じて API サーバーと通信し、クラスター内のコンテナーにアクセスできます。 API サーバーはリクエストを認証、承認、暗号化します。 API サーバーをパブリック ネットワーク アクセスに開くと、kubectl を介してローカルで対話型コマンドを実行するときに、API サーバーは次に示すように中間プロキシとして機能します。

この機能に基づいて、End-Cloud Interconnect 3.0 プラグインは、アプリケーションの起動時に kubectl を呼び出してプロキシ コンテナを一時的に作成します。 API サーバーと一時プロキシ コンテナーを組み合わせることで、ローカル アプリケーションはクラウド サービスやその他のリソースにアクセスできるようになります。全体的なリンクは次のとおりです。

プロキシ コンテナーは 64 MB ～ 128 MB のノード メモリを占有し、ローカル アプリケーションが停止されると自動的に削除されます。

プラグインの設定も非常に簡単です。 kubeconfig 構成ファイルを設定し、プラグインで Kubernetes 名前空間を選択するだけです。

ローカル アプリケーションを起動すると、プラグインは kubeconfig 構成ファイルを使用して kubectl を呼び出し、一時コンテナーを作成し、チャネルを開いてトラフィックを転送します。アプリケーションが終了すると、プラグインは kubeconfig 構成ファイルを使用して kubectl を呼び出して一時コンテナを削除します。

コンテナレベルの相互接続

コンテナ レベルの相互接続とは、Docker コンテナがローカルで起動され、マイクロサービス アプリケーションがコンテナ内で実行されることを意味します。マイクロサービス アプリケーションはクラウド環境と相互接続できます。次のようなシナリオの場合は、コンテナ レベルの相互接続が適切な選択です。

Java 以外の言語のアプリケーション。アプリケーションの実行時には、オペレーティング システムに対して特定の要件があります。

このモードでは、マイクロサービス アプリケーションとチャネル サービスの両方がコンテナーを使用して実行され、全体的な相互作用は次のようになります。

実装レベルでは、コンテナ レベルの相互接続は iptables を使用してトラフィックを傍受し、プロキシ コンテナ内のチャネル サービスに転送します。その後、チャネル サービスはクラウド プロキシを介してデータをターゲット アドレスに転送します。アーキテクチャ的には、このモードは、アプリケーション コンテナーがトラフィックをチャネル サービス コンテナー (サイドカー コンテナー) に転送する Service Mesh のサイドカー モードに多少似ています。ただし、エンドクラウド相互接続のチャネル コンテナーは透過的なデータ転送のみを実行しますが、サービス メッシュのサイドカーはマイクロサービスの検出とガバナンスを実行できるため、異なります。

使用時には、プラグインはコンテナの Alibaba Microservice Container 構成を実行し、その相互作用は次のようになります。

アプリケーション コンテナーで Java 言語アプリケーションを実行している場合、プラグインは追加の特定のパラメーターを設定しなくても、迅速なアプリケーション デバッグをサポートします。アプリケーションを起動すると、プラグインは環境変数を通じて JDWP デバッグ パラメータを挿入し、デバッグ ポートを開きます。このプラグインは、Intellij IDEA のスマート検出機能とさらに組み合わせられ、以下に示すように、Attach デバッガーを介してコンテナ内の Java アプリケーションをワンクリックでデバッグできます。

図に示すように、プラグインはコンテナ内のアプリケーションのログ出力を IDE ウィンドウに出力します。ログ内の「アドレス: 5005 でトランスポート dt_socket をリッスンしています」は、コンテナー内の Java アプリケーションがデバッグ ポートを開いたことを示します。 「デバッガーをアタッチ」をクリックすると、IDE はコンテナー内の Java アプリケーションのデバッグ ポートに接続します。次に、以下のようにコードをデバッグできます。

ローカルリンク診断

開発プロセス中に、ダウンストリーム サービス インターフェイスが 500 を返し、インターフェイス呼び出しが失敗したことだけがわかっていて、具体的な理由がわからないというシナリオに遭遇したことはありませんか。このモジュールの開発者に確認を依頼したところ、かなり時間が経ってから「今ちょっと忙しいので、後で確認します」という返事が返ってきました。確認する時間ができたときに、問題が別のモジュールにあることに気づき、別のクラスメートを探して確認するように頼みますか? ...

このようなシナリオは開発プロセスではよくあることであり、小さな問題でもトラブルシューティングに多大な労力と時間が必要になることがよくあります。このシナリオは、リンク トラッキング テクノロジーの典型的なシナリオです。現在、エンドクラウド相互接続機能にリンク トラッキングを統合しているため、ローカル コール リンクもクラウドに報告され、例外が発生した場合に問題が一目でわかります。

たとえば、現在の環境にはトランザクション センター、製品センター、在庫センターの 3 つのサービスがあり、テストのクラスメートと一緒に新しいバージョンの機能を検証しているとします。テスターがページ上の注文プロセスをテストしていたところ、以下に示すように注文が失敗したことがわかりました。

多くのモジュールが関係しているため、トラブルシューティングには非常に長い時間がかかります。 End-Cloud Interconnect 3.0 プラグインは、ARMS (Application Real-Time Monitoring Service) の Java エージェントを統合します。非侵入型コード追跡メカニズムを通じて通話リンクに関する情報を収集し、統合された収集とインテリジェントな分析のために ARMS サーバーに報告します。例外が発生した場合、問題を明確に把握するには、クラウド内の TraceId に基づいて呼び出しリンクをクエリするだけで済みます。

TraceId は、リンク トラッキングの最下層で使用される概念です。フロントエンドページから生成され、下流の各ノードに送信されます。使いやすさを考慮して、プラグインにはローカル リンクを印刷するためのスイッチも用意されています。オンにすると、次に示すように、ローカル アプリケーション サービス呼び出しリンクに関する関連情報が出力されます。

リンク出力には次の情報が含まれます。

TraceId: リクエストの全体的な処理プロセスをマークするために使用されます。分散マイクロサービス呼び出しシナリオでは、TraceId はフロントエンド アプリケーション ノードからダウンストリーム リンクの各ノードに透過的に送信されます。この TraceId に基づいて、EDAS コンソールまたは ARMS コンソールで全体的なリンク処理プロセスを照会できます。サービス: Spring Cloud サービス、Dubbo サービス、HSF サービスなど、現在のアプリケーションのリクエスト処理エントリ。API: リンク処理中のメソッド シグネチャ。行: メソッドによって処理される特定の行番号。コスト: このメソッドとその下流処理にかかる時間 (ミリ秒単位)。 Ext: 要求処理ステータス コード、データベース アクセス SQL、リソース ターゲット アドレスなどの拡張情報。コンソール リンク: このリンク情報は ARMS コンソールで収集されます。このリンクをクリックすると、完全なリンク情報を直接表示できます。

コンソール リンクをクリックすると、次に示すように、このリクエストの上流および下流の処理リンクが表示されます。

各サービス内の処理の詳細をさらに確認することもできます。

これを読んで、トラブルシューティングのためのアイデアがさらに得られたと感じますか? :)

最後に

クラウド ネイティブの波は止められず、ビジネスをクラウドに移行することが企業にとって唯一の方法です。しかし、クラウドへの移行は決してスムーズな道のりではなく、その過程では常に何らかの困難や課題に遭遇します。クラウドネイティブ テクノロジーの成熟度が高まっているため、これらの問題には必ず対応する解決策が見つかるでしょう。

開発分野においては、国内のクラウドベンダーの中でもトップクラスの実績を誇ります。 2018 年の End-Cloud Interconnection 1.0 バージョンのインキュベーションから 2021 年の現在の End-Cloud Interconnection 3.0 バージョンまで、大小さまざまな多くの問題と課題に直面しましたが、最終的にはすべて 1 つずつ解決されました。この機能により、パブリック クラウドとプライベート クラウドの開発者は開発、テスト、共同デバッグ ループをローカルで完了できるようになり、非常に便利になります。

今後も開発者の皆様に、より優れた、より強力で、より使いやすいクラウドネイティブ ツールを提供し続けていきますので、ご期待ください。