セルベースのアーキテクチャ用にサーバーレスセルルーターを設定する

作成者: Mian Tariq (AWS) と Ioannis Lioupras (AWS）

[概要]

グローバルセルベースのアプリケーションのシステムへのエントリポイントとして、セルルーターはユーザーを適切なセルに効率的に割り当て、ユーザーにエンドポイントを提供する責任があります。セルルーターは、マッピングの保存 user-to-cell、セル容量のモニタリング、必要に応じて新しいセルのリクエストなどの機能を処理します。中断が発生する可能性がある間は、セルルーターの機能を維持することが重要です。

このパターンのセルルーター設計フレームワークは、耐障害性、スケーラビリティ、全体的なパフォーマンスの最適化に焦点を当てています。このパターンは静的ルーティングを使用し、クライアントは初回ログイン時にエンドポイントをキャッシュし、セルと直接通信します。このデカップリングは、セルルーターの障害発生時にセルベースのアプリケーションの中断のない機能を確保できるようにすることで、システムの耐障害性を向上させます。

このパターンは、 AWS CloudFormation テンプレートを使用してアーキテクチャをデプロイします。テンプレートのデプロイの詳細、または を使用して同じ設定をデプロイするには AWS Management Console、「追加情報」セクションを参照してください。

重要： このパターンで示されているデモンストレーション、コード、 AWS CloudFormation テンプレートは、説明のみを目的としています。提供されるマテリアルは、設計パターンを説明し、理解を支援する目的のみを目的としています。デモとコードは本番稼働用ではないため、ライブ本番稼働アクティビティには使用しないでください。本番環境でコードまたはデモを使用しようとすることは強くお勧めせず、お客様の責任となります。このパターンまたはそのコンポーネントを本番環境に実装する前に、適切な専門家に相談し、徹底的なテストを実行することをお勧めします。

前提条件と制限

前提条件

製品バージョン

アーキテクチャ

次の図は、セルルーターの大まかな設計を示しています。

図は、以下のワークフローをステップスルーします。

新しいセルが作成されると、 RoutingDBはプロビジョニングおよびデプロイレイヤーから更新されます。ただし、このプロセスはこのパターンの範囲を超えています。セルベースのアーキテクチャ設計の前提の概要と、このパターンで使用されるセルルーター設計の詳細については、「追加情報」セクションを参照してください。

ツール

AWS のサービス

その他のツール

コードリポジトリ

このパターンのコードは、 GitHub Serverless-Cell-Router リポジトリで使用できます。

ベストプラクティス

セルベースのアーキテクチャを構築する際のベストプラクティスについては、以下の AWS Well-Architected ガイダンスを参照してください。

エピック

git clone https://github.com/aws-samples/Serverless-Cell-Router/

aws s3api create-bucket --bucket <bucket name> --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1

zip -j mapper-scr.zip Functions/Mapper.py
zip -j dispatcher-scr.zip Functions/Dispatcher.py
zip -j scaler-scr.zip Functions/Scaler.py
zip -j cp validator-scr.zip Functions/Validator.py
zip -j dynamodbDummyData-scr.zip Functions/DynamodbDummyData.py

aws s3 cp mapper-scr.zip s3://<bucket name>
aws s3 cp dispatcher-scr.zip s3://<bucket name>
aws s3 cp scaler-scr.zip s3://<bucket name>
aws s3 cp validator-scr.zip s3://<bucket name>
aws s3 cp dynamodbDummyData-scr.zip s3://<bucket name>

aws cloudformation create-stack --stack-name serverless.cell-router \
--template-body file://Serverless-Cell-Router-Stack-v10.yaml \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=LambdaFunctionMapperS3KeyParameterSCR,ParameterValue=mapper-scr.zip \
ParameterKey=LambdaFunctionDispatcherS3KeyParameterSCR,ParameterValue=dispatcher-scr.zip \
ParameterKey=LambdaFunctionScalerS3KeyParameterSCR,ParameterValue=scaler-scr.zip \
ParameterKey=LambdaFunctionAddDynamoDBDummyItemsS3KeyParameterSCR,ParameterValue=dynamodbDummyData-scr.zip \
ParameterKey=LambdaFunctionsS3BucketParameterSCR,ParameterValue=<S3 bucket storing lambda zip files> \
ParameterKey=CognitoDomain,ParameterValue=<Cognito Domain Name> \
--region <enter your aws region id, e.g. "eu-central-1">

curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells

curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper

関連リソース

リファレンス

動画

Physalia: Amazon で高可用性を実現するセルベースのアーキテクチャ EBS

追加情報

セルベースのアーキテクチャ設計の前提

このパターンはセルルーターに焦点を当てていますが、環境全体を理解することが重要です。環境は、次の 3 つの個別のレイヤーで構成されています。

各レイヤーは、他のレイヤーに影響を与える障害が発生した場合でも機能を維持します。障害分離境界として機能し AWS アカウント ます。

次の図は、レイヤーの概要を示しています。セルレイヤーとプロビジョニングおよびデプロイレイヤーは、このパターンの範囲外です。

セルベースのアーキテクチャの詳細については、「セルベースのアーキテクチャによる影響範囲の削減: セルルーティング」を参照してください。

セルルーター設計パターン

セルルーターは、セル間で共有されるコンポーネントです。潜在的な影響を軽減するには、Routing レイヤーができるだけ薄いシンプルで水平方向にスケーラブルな設計を使用することが重要です。ルーティングレイヤーは、システムのエントリポイントとして機能し、ユーザーを適切なセルに効率的に割り当てるために必要なコンポーネントのみで構成されます。このレイヤー内のコンポーネントは、セルの管理や作成には関与しません。

このパターンは静的ルーティングを使用します。つまり、クライアントは初回ログイン時にエンドポイントをキャッシュし、その後セルとの直接通信を確立します。クライアントとセルルーター間の定期的なインタラクションが開始され、現在のステータスを確認したり、更新を取得したりできます。この意図的なデカップリングにより、セルルーターのダウンタイム発生時に既存のユーザーに対して中断のないオペレーションが可能になり、システム内で継続的な機能と回復力を提供します。

このパターンでは、セルルーターは次の機能をサポートしています。

AWS CloudFormation テンプレートでセットアップされているデモセルルーターをさらに理解するには、以下のコンポーネントとステップを確認してください。

前提は、プロビジョニングレイヤーとデプロイレイヤーが既に確立されていることです。実装の詳細は、このアーティファクトの範囲を超えています。

これらのコンポーネントは AWS CloudFormation テンプレートによって設定および設定されるため、次の手順は説明的で高レベルに示されています。前提は、セットアップと設定を完了するために必要な AWS スキルがあることです。

1. Amazon Cognito ユーザープールのセットアップと設定

にサインインし AWS Management Console、 で Amazon Cognito コンソールを開きますhttps://console.aws.amazon.com/cognito/。アプリケーション統合、ホストされた UICellRouterPool、および必要なアクセス許可を使用して、 という名前の Amazon Cognito ユーザープールを設定および設定します。

2. セルルーターの API Gateway をセットアップおよび設定APIする

で API Gateway コンソールを開きますhttps://console.aws.amazon.com/apigateway/。Amazon Cognito ユーザープール と統合された Amazon Cognito オーソライザーを使用してCellRouter、 APIという名前の を設定および設定しますCellRouterPool。次の要素を実装します。

3. DynamoDB テーブルを作成する

で DynamoDB コンソールを開きhttps://console.aws.amazon.com/dynamodb/、次の設定tbl_routerで という名前の標準 DynamoDB テーブルを作成します。

Indexes タブで、 という名前のグローバルセカンダリインデックスを作成しますmarketId-currentCapacity-index。Scaler Lambda 関数は、インデックスを使用して、割り当てられたユーザーの数が最も少ないセルを効率的に検索します。

次の属性を使用してテーブル構造を作成します。

4. SQSキューの作成と設定

で Amazon SQSコンソールを開きhttps://console.aws.amazon.com/sqs/、Amazon SQSキー暗号化でCellProvisioning設定された という標準SQSキューを作成します。

5. Orchestrator の実装

Orchestrator ルーターの として機能する Step Functions ワークフローを作成します。ワークフローは、セルルーター を介して呼び出すことができますAPI。ワークフローは、リソースパスに基づいて指定された Lambda 関数を実行します。ステップ関数をセルルーター API の API Gateway と統合しCellRouter、Lambda 関数を呼び出すために必要なアクセス許可を設定します。

以下の図に、ワークフローを示しています。選択状態は、Lambda 関数のいずれかを呼び出します。Lambda 関数が成功すると、ワークフローは終了します。Lambda 関数が失敗すると、フェイル状態が呼び出されます。

6. Lambda 関数の実装

Dispatcher、Mapper、Scaler、および Validator関数を実装します。デモンストレーションで各関数を設定および設定するときは、関数のロールを定義し、DynamoDB テーブル で必要な操作を実行するために必要なアクセス許可を割り当てますtbl_router。さらに、各関数をワークフロー に統合しますOrchestrator。

ディスパッチャー関数

このDispatcher関数は、新しい登録ユーザーごとに 1 つの静的セルを識別して割り当てる責任があります。新しいユーザーがグローバルアプリケーションに登録すると、リクエストは Dispatcher関数に送信されます。関数は、次のような事前定義された評価基準を使用してリクエストを処理します。

注： これらの基準は、この例のパターンを説明するためにのみ表示されます。実際のセルルーターの実装では、より洗練されたユースケースベースの基準を定義できます。

は Dispatcher 関数をOrchestrator呼び出して、ユーザーをセルに割り当てます。このデモ関数では、市場値は として定義される静的パラメータですeurope。

このDispatcher関数は、セルが既にユーザーに割り当てられているかどうかを評価します。セルがすでに割り当てられている場合、Dispatcher関数はセルのエンドポイントを返します。ユーザーにセルが割り当てられていない場合、 関数はユーザー数が最も少ないセルを検索し、ユーザーに割り当て、エンドポイントを返します。セル検索クエリの効率は、グローバルセカンダリインデックスを使用して最適化されます。

マッパー関数

このMapper関数は、データベース内のマッピングの user-to-cellストレージとメンテナンスを監督します。登録された各ユーザーに単一のセルが割り当てられます。各セルには 2 つの異なる URLs- 各AWSリージョンに 1 つずつあります。API Gateway でホストされるAPIエンドポイントとして機能するこれらのURLs関数は、グローバルアプリケーションを指すインバウンドとして機能します。

Mapper 関数がクライアントアプリケーションからリクエストを受信すると、DynamoDB テーブルでクエリを実行して、 user-to-cell指定された E メール ID に関連付けられているマッピングtbl_routerを取得します。割り当てられたセルが見つかった場合、Mapper関数はセルの 2 つの をすぐに提供しますURLs。また、このMapper関数はセル の変更を積極的にモニタリングしURLs、ユーザー設定の通知または更新を開始します。

Scaler 関数

Scaler 関数はセルの残容量を管理します。新しいユーザー登録リクエストごとに、Scaler関数はDispatcher、関数がユーザーに割り当てられたセルの利用可能な容量を評価します。指定された評価基準に従ってセルが所定の制限に達した場合、関数は Amazon SQSキューを介して Provision and Deploy レイヤーへのリクエストを開始し、新しいセルのプロビジョニングとデプロイを要求します。セルのスケーリングは、次のような一連の評価基準に基づいて実行できます。

注: これらの基準は、この例のパターンを説明するためにのみ表示されます。実際のセルルーターの実装では、より詳細なユースケースベースの基準を定義できます。

デモScalerコードは、 が新しく登録したユーザーにセルをDispatcher正常に割り当てOrchestratorた後、 によって実行されます。はScaler、 からセル ID を受信するとDispatcher、事前定義された評価基準に基づいて、指定されたセルに、追加のユーザーに対応するのに十分な容量があるかどうかを評価します。セルの容量が不十分な場合、Scaler関数は Amazon SQSサービスにメッセージをディスパッチします。このメッセージは、プロビジョニングおよびデプロイレイヤー内のサービスによって取得され、新しいセルのプロビジョニングを開始します。

バリデータ関数

このValidator関数は、セルアクセスに関連する問題を特定して解決します。ユーザーがグローバルアプリケーションにサインインすると、アプリケーションはユーザープロファイル設定URLsからセルの を取得し、ユーザーリクエストをセル内の 2 つの割り当てられたリージョンのいずれかにルーティングします。にアクセスできない場合、アプリケーションURLsは検証URLリクエストをセルルーターにディスパッチできます。セルルーターは をOrchestrator呼び出しますValidator。は検証プロセスValidatorを開始します。検証には、その他のチェックとして以下が含まれる場合があります。

結論として、 Validator関数はクライアントアプリケーションリクエストに応答し、必要な修復ステップとともに検証ステータスを提供します。

Validator は、ユーザーエクスペリエンスを向上させるように設計されています。インシデントによりセルが一時的に使用できなくなるため、特定のユーザーがグローバルアプリケーションにアクセスできないシナリオを考えてみましょう。Validator 関数は、一般的なエラーを提示する代わりに、指示的な修復ステップを提供できます。これらのステップには、次のアクションが含まれる場合があります。

Validator 関数のデモコードは、リクエストURLs内のユーザーが指定したセルがtbl_routerテーブルに保存されたレコードと一致することを確認します。このValidator関数は、セルが正常かどうかも確認します。