Spring Cloud を使用して複数のクラウド リージョンで Java マイクロサービスを実行する方法

翻訳者 |李睿

校正：孫淑娟

Java マイクロサービスをパブリック クラウド インフラストラクチャ上で実行する場合は、複数のクラウド リージョンを利用できます。これはいくつかの理由から良いアイデアです。

まず、クラウド コンピューティングの可用性ゾーンとリージョンは、ハードウェアの問題、クラウド サービスのアップグレード後に発生したバグ、または人為的なエラーが原因で失敗することがよくあります。最も有名な S3 の停止の 1 つは、AWS の従業員が誤った操作コマンドを発行したために発生しました。

クラウド リージョンに障害が発生すると、そのリージョン内のマイクロサービスも障害が発生します。ただし、マイクロサービス インスタンスを複数のクラウド リージョンで実行すると、米国東部リージョンで大規模な障害が発生しても実行を継続できます。

2 番目に、ユーザーは米国東部にマイクロサービスを展開し、アプリケーションを大西洋を越えたヨーロッパで実行することを選択できます。ヨーロッパのユーザーから米国東部のアプリケーション インスタンスまでの往復レイテンシは約 100 ミリ秒です。これを、米国東部 (マイクロサービスが実行されているデータセンターの近く) からのユーザー トラフィックの 5 ミリ秒の往復遅延と比較してください。ヨーロッパのユーザーからアプリケーションの速度が遅いという報告があっても驚かないでください。マイクロサービス インスタンスが米国東部およびヨーロッパ西部リージョンにデプロイされていた場合、このような否定的なフィードバックは聞こえてこなかったでしょう。

最後に、ヨーロッパからのユーザー要求に対応し、米国のデータベース インスタンスからデータを要求する Java マイクロサービスについて考えてみましょう。この場合、データ保存規則に違反する可能性があります (GDPR 規則により要求されたデータが個人データとして分類されている場合)。ただし、マイクロサービス インスタンスがヨーロッパで実行され、ヨーロッパのクラウド リージョンのデータベース インスタンスから個人データを取得する場合、規制当局が懸念するような問題は発生しません。

以下はこの記事のトピックの紹介ですが、複数のクラウド リージョンで Java マイクロサービスを実行することの利点がいくつかわかっていただければ幸いです。 Spring Cloud を使用して、複数のクラウド リージョンでマイクロサービスを開発およびデプロイする方法を学びます。

高レベルの概念

以下は地理的に分散したJava Messengerを例にとると、マイクロサービスと Spring Cloud が複数のクラウド リージョン環境でどのように機能するかを深く理解できます。

アプリケーション (複数のマイクロサービスで構成) は、米国西部、米国中部、ヨーロッパ西部、アジア南部の複数のクラウド リージョンで実行されます。すべてのアプリケーション インスタンスはステートレスです。

Spring Cloud コンポーネントは、アプリケーション インスタンスと同じクラウド リージョンで実行されます。アプリケーションは、構成設定の配布に Spring Config Server を使用し、スムーズでフォールト トレラントなサービス間通信に Spring Discovery Server を使用します。

YugabyteDB は、リモートで簡単に実行できる分散データベースとして選択されました。さらに、PostgreSQL ソース コード上に構築されている限り、Spring Data や Spring エコシステムの他のコンポーネントと自然に統合されます。この記事では、YugabyteDB のマルチリージョン デプロイメント オプションについては説明しません。

ユーザー トラフィックは、グローバル外部クラウド ロード バランサーを介してマイクロサービス インスタンスに到達します。つまり、ロード バランサは、地球上のどこからでもアクセスできる単一の IP アドレスを提供します。その IP アドレス (またはそれに変換する DNS 名) はユーザーの Web またはモバイル フロントエンドに提供され、その IP を使用してアプリケーション バックエンドに接続します。ロード バランサは、ユーザー要求を最も近いアプリケーション インスタンスに自動的に転送します。このクラウド コンポーネントについては、以下で詳しく説明します。

ターゲットアーキテクチャ

マルチリージョンJava M essengerのターゲット アーキテクチャは次のとおりです。

ソリューション全体は Google Cloud Platform 上で実行されます。ユーザーは、別のクラウド コンピューティング プロバイダーが提供するクラウド サービスを好むため、安心して使用できます。多くのユーザーは、Google Cloud が提供する開発者エクスペリエンス、豊富で手頃な価格のインフラストラクチャ、高速で安定したネットワーク、およびこの記事で説明したその他の利点のために、Google Cloud を好んで使用しています。

マイクロサービス インスタンスは、必要な数のクラウド リージョンにデプロイできます。

上の図には、リージョン AとリージョンB という 2 つのランダムなクラウド リージョンがあります。マイクロサービス インスタンスは、クラウド リージョン内の複数のアベイラビリティー ゾーン (たとえば、リージョン Aのゾーン A とゾーン B ) で実行することも、クラウド リージョン内 (リージョンB のゾーン A) で実行することもできます。

クラウド リージョンごとに Spring Discovery および Config Server のインスタンスを 1 つ用意するのが妥当ですが、レイテンシを最小限に抑えるために、アベイラビリティ ゾーンごとに各サーバーのインスタンスを意図的に実行します。

どのマイクロサービスインスタンスがユーザーリクエストに対応するかを決定するのは誰ですか?グローバル外部ロードバランサが意思決定者です。

ユーザーが携帯電話で Java Messenger を開いてメッセージを送信するとします。メッセージを含むリクエストはロード バランサに送信され、次の方法で転送されます。

（１）リージョンAは、ユーザーに最も近いクラウドリージョンであり、リクエスト時点では正常な状態（中断なし）である。ロードバランサーはこれらの基準に基づいてリージョンを選択します。

（2）このクラウドリージョンでは、マイクロサービスインスタンスはゾーンAとゾーンBの両方で利用可能です。そのため、両方のアベイラビリティゾーンがアクティブで正常に機能している場合、ロードバランサーはどちらかのアベイラビリティゾーンを選択できます。このリクエストがゾーンBに送信されると仮定します。

以下では、各マイクロサービスが何を担当するかについて説明します。現時点では、メッセージング マイクロサービスがすべてのアプリケーション データ (メッセージ、チャネル、ユーザー プロファイルなど) をマルチリージョンの YugabyteDB デプロイメントに保存することを知っておいてください。 Attachments マイクロサービスは、グローバルに分散された Google Cloud Storage を使用してユーザー画像を保存します。

マイクロサービスと Spring Cloud

以下では、マイクロサービスと、それが Spring Cloud をどのように活用できるかについてさらに詳しく説明します。

Messenger マイクロサービスは、チャネルやワークスペース間でメッセージを送信するためにすべての Messenger アプリケーションに必要な主要な機能を実装します。 Attachments マイクロサービスは画像やその他のファイルをアップロードし、そのソース コードは Geo Messenger のリポジトリで表示できます。

Spring Cloud 構成サーバー

どちらのマイクロサービスも Spring Boot 上に構築されています。起動すると、Spring Cloud Config Server から構成設定が取得されます。これは、分散環境で構成ファイルを外部化する必要がある場合に適したオプションです。

構成サーバーは、Git リポジトリ、Vault、JDBC 互換データベースなど、さまざまなバックエンドから構成をホストおよび取得できます。 Java Geo Messenger の場合、Git オプションを使用すると、アプリケーションから次の行が取得されます。 2 つのマイクロサービスによって要求されるプロパティ ファイルは、Spring Boot が構成サーバーから設定を読み込みます。

ヤム
1春。設定。インポート= configserver : http : //${CONFIG_SERVER_HOST}:${CONFIG_SERVER_PORT}

Spring Cloud Discovery サーバー

Messenger および Attachments マイクロサービスが起動されると、それらは Spring Cloud Netflix コンポーネントである Spring Cloud Discovery Server のリージョン ローカル インスタンスに登録されます。

検出サーバー インスタンスの場所は、構成サーバー インスタンスから転送される次の構成設定で定義されます。

ヤム
1ユーレカ。クライアント。サービス URL 。 defaultZnotallow = http : //${DISCOVERY_SERVER_HOST}:${DISCOVERY_SERVER_PORT}/eureka

ブラウザで HTTP アドレスを開いて、サービスが Discovery Server に正常に登録されたことを確認することもできます。

マイクロサービスは、アプリケーションの spring.application.name 設定を介して渡される名前を使用して、 application.properties ファイルに登録されます。上記のように、次の名前が選択されます。

・春。応用。 Messengerマイクロサービスの場合はname = messenger
・春。応用。 name =添付ファイルサービスの場合の添付ファイル

マイクロサービス インスタンスはこれらの名前を使用して、検出サーバーを介して相互に要求を検索し、送信します。たとえば、ユーザーがディスカッション チャネルに写真をアップロードする場合、そのリクエストはまず Messenger サービスに送信されます。次に、Messenger は Discovery Server の助けを借りて、このタスクを Attachments マイクロサービスに委任します。

まず、Messenger サービスは添付ファイルに対応するインスタンスを取得します。

ジャワ
< ServiceInstance > serviceInstances = discoveryClientをリストします。 getInstances ( "添付ファイル" );

 ServiceInstanceインスタンス;

 if ( ! serviceInstances . isEmpty ()) {
インスタンス=サービスインスタンス
 .get ( ThreadLocalRandom . current () . nextInt ( 0 、 serviceInstances . size () ));
 }

システム。外。 printf ( "URI %s のサービス %s に接続しました\n" ,
実例。 getInstanceId ()、インスタンス。 URIを取得します。

次に、Messenger マイクロサービスは添付ファイルのインスタンス URI を使用して HTTP クライアントを作成し、InputStream 経由で画像を送信します。

ジャワ
.htmlクライアント httpClient = HttpClient 。新しいビルダー() 。建てる（）;

 HttpRequestリクエスト= HttpRequest 。新しいビルダー()
 。 uri ( URI . create (インスタンス. getUri () + "/upload?fileName=" +ファイル名))
 。ヘッダー( "Content-Type" 、 MIME タイプ)
 。 POST ( HttpRequest . BodyPublishers . ofInputStream (新しいSupplier < InputStream > () {
 @オーバーライド
パブリック入力ストリームを取得する（）{
 inputStream を返します。
 }
 })）。建てる（）;

AttachmentsサービスはRESTエンドポイントを通じてリクエストを受け取り、最終的に画像を Google Cloud Storage に保存し、画像URL をMessengerマイクロサービスに返します。

ジャワ
パブリックオプション<文字列> storeFile (文字列filePath 、文字列fileName 、文字列contentType ) {
クライアントがnullの場合
クライアントを初期化します。
 }

文字列objectName = generateUniqueObjectName (ファイル名);

 BlobId blobId = BlobId 。 (バケット名、オブジェクト名)の
BlobInfo blobInfo = BlobInfo 。新しいビルダー( blobId )。建てる（）;

試す{
クライアント。作成( blobInfo 、 Files.readAllBytes ( Paths.get ( filePath )) ) ;
 } IOExceptionをキャッチします。
システム。エラー。 println ( "ファイルの読み込みに失敗しました:" + fileName );
 e .スタックトレースを印刷します。

戻り値はオプションです。空の（）;
 }

システム。外。 printf (
 "ファイル %s がバケット %s に %s %n としてアップロードされました" 、 filePath 、 bucketName 、 objectName );

文字列objectFullAddress = "http://storage.googleapis.com/" +バケット名+ "/" +オブジェクト名;

システム。外。 println ( "画像の公開アドレス: " + objectFullAddress );

戻り値はオプションです。 ( objectFullAddress )の;
 }

マイクロサービスの完全な実装と、それらが Discovery Server を介してどのように通信するかを調べたい場合は、GitHub リポジトリにアクセスしてください。

Google Cloud Platform にデプロイ

Java ジオメッセンジャーは現在、Google Cloud Platform 上の 3 つの地理的な場所と 5 つのクラウド リージョン（北米（「us-west2」 、 「us-central1」 、 「us-east4」） 、ヨーロッパ（「Europe-west3」） 、アジア（「Asia-east1」））にデプロイされています。 ​

デプロイするには、次の手順に従ってください。

（1）Googleプロジェクトを作成します。

（2）カスタムの高度なネットワークを作成します。

（3）Google Cloud Storageを設定します。

（4）仮想マシンのインスタンステンプレートを作成します。

（5）アプリケーションインスタンスで仮想マシンを起動します。

（6）グローバル外部ロードバランサーを構成します。

上記の手順の詳細な説明は省略します。代わりに、次の図を使用して、ステップ 2 で高度な Google ネットワークが選択された理由を説明します。

アプリケーション インスタンスが米国の Google Cloud Platform にデプロイされ、ユーザーがインドからアプリケーションに接続するとします。ユーザーの場所からアプリケーションまでの経路には、高速パスと低速パスがあります。

この展開に標準ネットワークを選択した場合は、低速パスが使用されます。この場合、ユーザーのリクエストはパブリック インターネットを経由して移動し、米国に到着する前に多くのクラウド コンピューティング プロバイダーのネットワークに出入りします。最終的に、リクエストは米国内のアプリケーション インスタンスに近い Google PoP (プレゼンス ポイント) に到達し、Google ネットワークに入り、アプリケーションに到達します。

展開で高度なネットワークを使用する場合は、高速パスを選択します。この場合、ユーザー リクエストはユーザーに最も近い PoP から Google ネットワークに入り、そこから出ることはありません。 PoP はインドにあり、リクエストは高速で安定した接続を介して米国のアプリケーション インスタンスに高速化されます。さらに、クラウド外部ロードバランサーにはプレミアム レベルが必要です。そうしないと、最も近い PoP でユーザー リクエストを傍受し、近くのアプリケーション インスタンスに転送することができません。

フォールトトレランスのテスト

マイクロサービスが世界中のすべての大陸に展開されると、通常時とダウンタイム時にクラウド ロード バランサーがどのように動作するかを確認できます。

ブラウザでロード バランサーが使用する IP アドレスを開き、ディスカッション チャネルの 1 つに写真付きのメッセージをいくつか送信します。

最後のリクエストを処理したのは、Messenger および Attachments マイクロサービスのどのインスタンスですか?それはあなたが世界のどこにいるかによります。この例では、米国東部 (ig-us-east) のインスタンスがトラフィックを処理します。

米国東部リージョンが利用できなくなり、そのリージョン内のすべてのマイクロサービスが利用できなくなった場合、アプリケーションはどうなりますか?

複数リージョンの展開でも問題ありません。ロードバランサーは米国東部で問題を検出し、トラフィックを最も近い別の場所に転送します。この場合、大西洋に近い米国東海岸に住んでいる限り、トラフィックはヨーロッパに転送されます。

米国東部リージョンの停止をシミュレートするために、そのリージョンの VM に接続し、すべてのマイクロサービスをシャットダウンしました。ロード バランサーは、そのリージョンのマイクロサービスが応答しなくなったことを検出し、トラフィックをヨーロッパのデータセンターに転送し始めます。

すぐにフォールト トレランスをお楽しみいただけます。

テストパフォーマンス

フォールト トレランスに加えて、Java マイクロサービスを複数のクラウド リージョンにデプロイすると、ユーザー リクエストがどこにあっても、アプリケーションは低レイテンシでユーザー リクエストに対応できるようになります。

これを実現するには、まず、ほとんどのユーザーがいるクラウド リージョンにマイクロサービス インスタンスをデプロイし、ルーティング用のグローバル外部ロード バランサーを構成する必要があります。これは、「複数のクラウド リージョンにわたる Java アプリケーションのデプロイメントの自動化」という記事で説明されている内容です。

次に、これらの場所にデータを正しく配置する必要があります。マイクロサービス インスタンスと同様に、データベースも複数のリージョンで実行する必要があります。そうしないと、マイクロサービスとデータベース間のレイテンシが高くなり、全体的なパフォーマンスが低下します。

ここで説明するアーキテクチャでは、複数のクラウド リージョンに展開できる分散 SQL データベースである YugabyteDB が使用されます。

結論

パブリック クラウド環境向けの Java アプリケーションを開発する場合は、複数のリージョンにアプリケーション インスタンスを展開して、グローバル クラウド コンピューティング インフラストラクチャを活用する必要があります。これにより、ソリューションの回復力とパフォーマンスが向上し、データ ガバナンスの要件に準拠するようになります。

クラウド リージョン全体で実行および調整されるマイクロサービスを作成することは難しくないことを覚えておくことが重要です。 Spring エコシステムは Spring Cloud フレームワークを提供し、Google などのパブリック クラウド プロバイダーは作業を容易にするために必要なインフラストラクチャとサービスを提供します。

原題: Spring Cloud で複数のクラウド リージョンにわたって Java マイクロサービスを実行する、著者: Denis Magda