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

Amazon Web Services、Mian Tariq、Ioannis Lioupras

概要

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

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

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

前提条件と制限

前提条件

製品バージョン

アーキテクチャ

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

この図は、次のワークフローを段階的に示しています。

新しいセルが作成されると、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: Cell-based Architecture to Provide Higher Availability on Amazon EBS

https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0

追加情報

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

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

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

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

セルベースアーキテクチャの詳細については、「Reducing the Scope of Impact with Cell-Based Architecture: Cell routing」を参照してください。

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

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

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

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

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

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

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

1. Amazon Cognito ユーザープールを設定して構成する

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

2。セルルーターの API Gateway API を設定し構成する

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

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

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

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

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

4. SQS キューを作成し設定する

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

5。オーケストレーターを実装する

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

以下の図に、ワークフローを示しています。Choice ステートは Lambda 関数の 1 つを呼び出します。Lambda 関数が成功すると、ワークフローは終了します。Lambda 関数が失敗すると、Fail ステートが呼び出されます。

6。Lambda 関数を実装する

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

ディスパッチャー関数

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

Orchestrator はディスパッチャー関数を呼び出して、ユーザーをセルに割り当てます。このデモ関数では、マーケット値は europe として定義された静的パラメータです。

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

マッパー関数

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

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

スケーラー関数

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

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

バリデーター関数

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

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

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

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