Amazon Web Services ブログ

NEW:サービスディスカバリのためのAWS Cloud Mapとのアプリケーション統合

By: Alexandr Moroz, Sr. Product Manager, Amazon Route 53; Madhuri Peri, Sr. IoT Architect, AWS Professional Services; Aaron Molitor, Sr. Infrastructure Architect, AWS Professional Services; and Sarma Palli, Sr. DevOps Architect, AWS Professional Services

AWS Cloud Mapを利用するとクラウドをマッピングすることができます。Amazon S3のバケットやAmazon DynamoDBのテーブル、Amazon SQSのキュー
Amazon EC2やAmazon ECS、Amazon EKSやAWS Lambda上で構成されたカスタムクラウドサービスの様な任意のリソースに対しても分かりやすい名前を定義できます。AWS SDKと認証されたAPIクエリを使って分かりやすい名前にてリソースの場所やメタデータを検出することができます。
デプロイメントステージやバージョンの様なカスタム属性によって、リソースをさらにフィルターし、検出することができます。

API サービスディスカバリーの新機能

Amazon EC2インスタンスでホストされているデータベースの様なエンタープライズアプリケーションコンポーネントにデータベースサービスのエンドポイントを提供する場合は、アプリケーションのEC2インスタンスのIPアドレスをAWS Cloud Mapに登録する必要があります。INSTANCE_STATUSの様な追加のメタデータ属性を登録することもでき、AWS Cloud Mapでこの属性を使用し、サービスがREADYであることを検出し、AWS Cloud Map上でステータスがREADYである状態にのみアプリケーションが接続を試みる様にできます。様々なマイクロサービスやエンタープライズアプリケーションが検出されたいエンドポイントを持つ場合、AWS Cloud Mapをそれらの登録に利用することができます。その様なエンドポイントの例として、Auto Scaling groupsと共に使われるELBクラシックロードバランサ、アプリケーションロードバランサ(ALB)、ネットワークロードバランサ(NLB)があります。

computeスタックの選択

モダンなアプリケーションアーキテクチャはサービスエンドポイントを公開し公告し、エンドポイントの登録・解除し、それらにリクエストする方法を必要とします。アプリケーションの依存性は、サービスレジストリが重要になるアプリケーション自体が解決する事が期待されます。

これらのマイクロサービスは、アーキテクチャ自身に向いてる使い方の異なったパターンに従います。

  1. Auto Scaling groupやELB(クラシック、アプリケーションロードバランサ、ネットワークロードバランサ)の様なELBロードバランサを前に置いたEC2上で動くトラディショナルなワークロード
  2. イベント駆動型ワークロード向けのAmazon API Gatewayや AWS Lambda
  3. EC2やFargate起動タイプを利用するAmazon Elastic Container Service(ECS)上のコンテナベースのワークロード、ロングランニングなサービスやデーモン、実行完了する(Batch /cronタイプ)ワークドロード用のAmazon Elastic Container Service for Kuvernetes(EKS)

この図は異なるアーキテクチャを実行するコンポーネントで構成された典型的なエンタープライズアプリケーションを示しています。
Amazon EKS上で動くwebサーバ、Amazon ECS上で動くbackend、サーバレスイベント登録サービス、Amazon Relation Database Service(RDS)上のデータベースを利用したEC2 Auto Scaling groups(ASG)上のpaymentsがあります。

 

サービスディスカバリーの観点から、次の図はどの様にアプリケーションが検出され、リクエストされたいのかを示しています。

 

これらのマイクロサービス（異なるクラウドcomputeプロダクトで動く)のそれぞれを、DNSベースおよびAPIベースのサービスディスカバリーを使用してAWS Cloud Mapに登録し、コンポーネントがトラフィックの準備が整ったときに検出のために属性を活用する方法をみてみましょう。

マイクロサービスのエンドポイントと検出

AWS Cloud Mapは論理名とアプリケーションのコンポーネント/リソースをマップするマネージドソリューションです。アプリケーションは、AWS SDKの利用や RESTful API呼び出し、DNSクエリのいづれかを使用してリソースを検出できます。AWS Cloud MapはAmazon DynamoDBのテーブル、Amazon Simple Queue Serviceのキュー、インスタンスやECSタスク、サーバレススタックを使って構成される任意のハイレベルアプリケーションサービスの様な登録されたリソースを取り扱います。

リソースを登録すると、属性を使用して返されるリソースをフィルタすることができる属性とクライアントを指定できます。例えば、アプリケーションは特定のGammaやProdの様な特定のデプロイメントステージのリソースを要求できます。加えて、IPをベースとしたリソースに対するヘルスチェックの有効化することができ、AWS Cloud Mapが健全なエンドポイントのみを返す様にすることができます。各API呼び出しは認証され、開発者はサービスロケーションや設定へのアクセスをAWS Identity and AccessManagement(IAM)を利用してコントロールすることができます。これによりクライアントは利用することが許可されたサービスを検出します。

基本を確認しましょう

2つの可能なサービスディスカバリーがあります

  • 登録/解除するマイクロサービスそのもの
  • 検出される/リクエストする他のマイクロサービス

マイクロサービスの登録は以下の手順になります。

  1. namespaeを作成する
  2. serviceを作成する
  3. serviceを登録する

Step1と2は各serviceに対して1度のみ行います。マイクロサービスを登録と解除をするユーティリティ関数を作成しなければなりません。このユーティリティ関数はcomputeスタックの選択によらずマイクロサービスを呼び出し、CI/CD/Devopsプロセスを通じてデプロイされます。Step3は継続する操作であり、基となるEC2 computeが変更される度に更新されなければなりません。
例：EC2 Amazon Machine Image(AMI)の変更や、serviceに対するプログラムの変更、バージョンの変更など

namespaceの作成

namespaceはexample1.example.comやexample2.example.comの様に同じドメイン名を共有するserviceの論理的なグループです。VPC内部からのみこれらのnamespaceへリクエストできる様にしたい場合は、private namespaceを選択します。インターネット上からアクセスさせる様にする場合はpublic namespaceを作成します。私たちの例では、public namespaceはexample1になりますが、example1の項目の利用に関する総数のトラッカー/レポーティングサービスは内部サービスになるかもしれません。

DNSベースでのサービスディスカバリーを利用するマイクロサービス:

APIベースでのサービスディスカバリーを利用するマイクロサービス:

serviceの作成

serviceを登録する際、AWS Cloud Mapはserviceをhosted zoneにレコードを作成します。これはserviceの名前とnamespaceの名前の組み合わせです。必要に応じてseriviceに対するヘルスチェックを定義する事ができます。

作成するserviceがAレコード、AAAレコード、SRVレコードのいづれかを使用したDNSベースの検出である場合は、次の構文を利用してserviceを作成できます。この例はEC2インスタンスまたは(ECS/EKS上の)コンテナとして実行されているアプリケーションコードです。

APIのみのnamespaceのみを利用するserviceの場合は、APIコールは次の様になります。

serviceのcompute backendの登録

コンテナのIPアドレスの登録/解除

Amazon ECSは ECS上で動くcomputeワークロードに対するサービスディスカバリーを可能とするためにAWS Cloud Mapと強く統合されています。ECSのserviceに対してサービスディスカバリーを有効にすると、AWS Cloud Mapの全てのTaskインスタンスを自動的にトラックします。これで、アプリケーションは、DNSクエリーとAWS Cloud MapのDiscoverInstances API呼び出しを利用してアプリケーションを検出することができる様になりました。呼び出しを発行するECSのコントロールプレーンはTask（およびコンテナ）のIPアドレスをAWSクラウドマップに登録します

Taskが停止した場合(新しいバージョンがデプロイされているか、クラッシュまたは再起動さている)、ECSのコントロールプレーンは解除プロセスを行います。

コンテナを動かす為にECSを利用している場合、これはECSとAWS Cloud Map API統合とシームレスに実行されます。

API Gateway URLとAWS Lambda

マイクロサービスをAPI namespaceと作成した場合、IP/ポート情報を入力せずに、任意の属性を利用できます。

EC2インスタンスIPアドレスの登録と解除

EC2インスタンスが起動する時に、起動時の設定であるuserdataにてEC2インスタンスのIPアドレスをserviceに登録するコマンドを発行します。他のアプローチとしては、マイクロサービスのauto scaling groupに対して実行されるLambda functionを実行し、IPアドレスをリストし、インスタンスをサービスに登録する方法があります。

EC2インスタンスを利用していて、Auto Scaling groupを利用しているインスタンスの場合、解除スクリプトを実行する為にlifecycle hookを利用します。他のアプローチとしては、Auto Scaling groupに対して定期的に実行されるLambda functionやAuto Scaling groupの通知イベントで発火するLambda Functionを利用する方法があります。

クエリー/検出

DNSとAPIによる両方のサービスディスカバリーがAWS Cloud Mapによりサポートされています。サポートされているDNSレコードのタイプは、A,AAAA,SRVおよびCNAMEです。

サービスが他のサービスを検出できる様にするのは、マイクロサービスアーキテクチャにおいて典型的です。名前やエンドポイントだけでクエリーし、サービスの裏で動いているcomputeスタック(AWS Lambda/container/EC2)のIPアドレスは使用しないことをお勧めします。

APIコマンド、list_servicesとget_servicesは利用可能なサービスとそれに対応する詳細情報を提供します。

DNSプロトコルはクライアントが応答をキャッシュするので、キャッシュ設定を実施してください。ここではAWS Cloud Mapはリージョナルエンドポイントを利用しています。作成されたすべてのAレコードはWEIGHTED応答かMULTIVALUE回答ポリシーのいずれかを使用します。Javaベースのcomputeスタックを使用している場合、JVMがDNS名前解決をキャッシュするため、DNSベースのサービスディスカバリーを選択しない場合があります。JVMがホスト名をIPアドレスに解決すると指定された期間(TTL)の間、IPアドレスがキャッシュされます。この様な場合、APIベースのサービスディスカバリーを使用し、AWS Cloud Mapを使用する他のマイクロサービスと同じアプローチを活用することができます。

 

DiscoverInstances API

DiscoverInstances APIはリージョナルエンドポイントを使い、特定したnamespaceとserviceに登録されたインスタンスを検出します。新しいインスタンスを登録する、または既存インスタンスを取り除く様なサービスの更新はDNSよりもAPIですぐに利用可能です。APIは検出時に使用できる追加のメタデータ(サービス属性)を使用してリソースを装飾する機能を提供します。たとえば、bule、green、または他のアプリケーション属性を持つサービスを取得します。これらの属性値を利用して検出の実行中にヘルスチェックを補完することができます。(インスタンスが準備できているかどうかを調べるなど)

次の図は、登録されたECS TaskインスタンスがAWS Cloud Mapコンソールにどの様に表示されるかを示すスクリーンショットです。


 

このアイディアは、コンテナやEC2インスタンスがオンラインになるかオフラインになるとcomputeのIPアドレスを登録や登録解除する為にAWS Cloud Map APIを呼び出す必要があるということです。

AWS Cloud Mapへアクセスすることから始めましょう。より学びたい場合は、こちらのGitHubレポジトリのデモコードを確認してみてください。EKSを使ったcomputeワークロードであれば、EKSがAWS Cloud Mapに自動的に全てのサービスを発行する事を解説しているこちらの ブログポストを参照してください。

 

この記事は SA 浅野が翻訳しました。原文はこちら。