翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# セルベースアーキテクチャ用にサーバーレスセルルーターを設定する
*Amazon Web Services、Mian Tariq、Ioannis Lioupras*
## 概要
セルベースのグローバルアプリケーションのシステムに対するエントリポイントとして、セルルーターはユーザーを適切なセルに効率的に割り当て、ユーザーにエンドポイントを提供します。セルルーターは、ユーザーとセルとの間のマッピングの保存、セルの容量のモニタリング、必要に応じた新しいセルのリクエストなどの機能を処理します。中断の可能性がある間、セルルーターの機能を維持することが重要です。
このパターンのセルルーターの設計フレームワークは、耐障害性、スケーラビリティ、全体的なパフォーマンスの最適化に焦点を当てています。このパターンでは、クライアントが初回ログイン時にエンドポイントをキャッシュし、セルと直接通信する静的ルーティングを使用します。このデカップリングは、セルルーターの障害発生時にセルベースのアプリケーションの機能が中断されないようにすることで、システムの耐障害性を向上させます。
このパターンでは、 AWS CloudFormation テンプレートを使用してアーキテクチャをデプロイします。テンプレートのデプロイの詳細、または を使用して同じ設定をデプロイするには AWS マネジメントコンソール、[「追加情報](#serverless-cell-router-architecture-additional)」セクションを参照してください。
**重要**
このパターンで示されているデモンストレーション、コード、 CloudFormation テンプレートは、説明のみを目的としています。素材は、設計パターンを説明し、理解を支援する目的でのみ提供されています。デモとコードは本番用ではないため、本稼働のアクティビティには使用しないでください。本番環境でこのコードまたはデモを使用しようとすることはお勧めしません。試みた場合はお客様の責任となります。このパターンまたはそのコンポーネントを本番環境に実装する前に、適切な専門家に相談し、徹底的なテストを実行することをお勧めします。
## 前提条件と制限
**前提条件**
+ アクティブな Amazon Web Services (AWS) アカウント
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) の最新バージョン
+ CloudFormation スタック、 AWS Lambda 関数、および関連リソースを作成するために必要なアクセス許可を持つ [AWS 認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
**製品バージョン**
+ Python 3.12
## アーキテクチャ
次の図は、セルルーターの大まかな設計を示しています。
この図は、次のワークフローを段階的に示しています。
1. ユーザーは、セルルーター API エンドポイントのフロントとして機能する Amazon API Gateway に問い合わせます。
1. Amazon Cognito は認証と認可を処理します。
1. AWS Step Functions ワークフローは以下のコンポーネントで構成されます。
+ **オーケストレーター** ‒ は AWS Step Functions `Orchestrator`を使用してワークフローまたはステートマシンを作成します。ワークフローはセルルーター API によってトリガーされます。`Orchestrator` は、リソースパスに基づいて Lambda 関数を実行します。
+ **ディスパッチャー** – `Dispatcher` Lambda 関数は、登録された新しいユーザーごとに 1 つの静的セルを識別して割り当てます。この関数は、ユーザー数が最も少ないセルを検索してユーザーに割り当て、エンドポイントを返します。
+ **マッパー** ‒ `Mapper`オペレーションは、 CloudFormation テンプレートによって作成された `RoutingDB` Amazon DynamoDB データベース内のuser-to-cellのマッピングを処理します。トリガーされた `Mapper` 関数は、既に割り当てられたユーザーにエンドポイントを提供します。
+ **スケーラー** – `Scaler` 関数は、セルの占有率と使用可能な容量を追跡します。必要に応じて、`Scaler` 関数は Amazon Simple Queue Service (Amazon SQS) を介して、プロビジョンとデプロイレイヤーにリクエストを送信して、新しいセルをリクエストできます。
+ **バリデーター** – `Validator` 関数はセルエンドポイントを検証し、潜在的な問題を検出します。
1. は、セル情報と属性 (API エンドポイント、状態 AWS リージョン、メトリクス) `RoutingDB`を保存します。
1. セルの使用可能な容量がしきい値を超えると、セルルーターは Amazon SQS を介してプロビジョニングおよびデプロイサービスをリクエストして、新しいセルを作成します。
新しいセルが作成されると、`RoutingDB` はプロビジョンとデプロイレイヤーから更新されます。ただし、このプロセスはこのパターンの範囲外です。セルベースアーキテクチャ設計の前提の概要と、このパターンで使用されるセルルーター設計の詳細については、「[追加情報](#serverless-cell-router-architecture-additional)」セクションを参照してください。
## ツール
**AWS のサービス**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) は、分散ソフトウェアシステムとコンポーネントの統合と分離に役立つ、安全で耐久性があり、利用可能なホスト型キューを提供します。
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、Lambda 関数と他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。
**その他のツール**
+ 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。
**コードリポジトリ**
このパターンのコードは GitHub 内の [Serverless-Cell-Router](https://github.com/aws-samples/Serverless-Cell-Router/) リポジトリで利用できます。
## ベストプラクティス
セルベースのアーキテクチャを構築する際のベストプラクティスについては、以下の AWS Well-Architected ガイダンスを参照してください。
+ [Reducing the Scope of Impact with Cell-Based Architecture](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html)
+ [AWS Well-Architected フレームワークの信頼性の柱: REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html)
## エピック
### ソースファイルを準備する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| コードリポジトリの例を複製します。 | 「Serverless-Cell-Router」GitHub リポジトリをコンピュータに複製するには、次のコマンドを使用します。git clone https://github.com/aws-samples/Serverless-Cell-Router/
| 開発者 |
| AWS CLI 一時的な認証情報を設定します。 | の認証情報 AWS CLI を使用して を設定します AWS アカウント。このチュートリアルでは、 AWS IAM Identity Center **コマンドラインまたはプログラムによるアクセス**オプションによって提供される一時的な認証情報を使用します。これにより`AWS_ACCESS_KEY_ID`、、`AWS_SECRET_ACCESS_KEY`、および `AWS_SESSION_TOKEN` AWS 環境変数が、 で使用する適切な認証情報で設定されます AWS CLI。 | 開発者 |
| S3 バケットを作成する | CloudFormation テンプレートによるデプロイのために Serverless-Cell-Router Lambda 関数を保存してアクセスするために使用される S3 バケットを作成します。S3 バケットを作成するには、次のコマンドを実行します。aws s3api create-bucket --bucket --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1
| 開発者 |
| .zip ファイルを作成します。 | [Functions](https://github.com/aws-samples/Serverless-Cell-Router/tree/main/Functions) ディレクトリにある Lambda 関数ごとに 1 つの .zip ファイルを作成します。これらの .zip ファイルは、Lambda 関数のデプロイに使用されます。Mac では、次の `zip` コマンドを使用します。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
| 開発者 |
| .zip ファイルを S3 バケットにコピーします。 | すべての Lambda 関数の .zip ファイルを S3 バケットにコピーするには、次のコマンドを使用します。aws s3 cp mapper-scr.zip s3://
aws s3 cp dispatcher-scr.zip s3://
aws s3 cp scaler-scr.zip s3://
aws s3 cp validator-scr.zip s3://
aws s3 cp dynamodbDummyData-scr.zip s3://
| 開発者 |
### CloudFormation スタックを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation テンプレートをデプロイします。 | CloudFormation テンプレートをデプロイするには、次の AWS CLI コマンドを実行します。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= \
ParameterKey=CognitoDomain,ParameterValue= \
--region
| 開発者 |
| 進捗確認。 | にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/cloudformation/]() で CloudFormation コンソールを開き、スタック開発の進行状況を確認します。ステータスが `CREATE_COMPLETE` の場合、スタックは正常にデプロイされています。 | 開発者 |
### 評価と検証
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ユーザーにセルを割り当てます。 | `Orchestrator` を開始するには、次の curl コマンドを実行します。curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells
`Orchestrator` は `Dispatcher` 関数の実行をトリガーします。次に、`Dispatcher` はユーザーの存在を検証します。ユーザーが見つかった場合、`Dispatcher` は関連するセル ID とエンドポイント URL を返します。ユーザーが見つからない場合、`Dispatcher` はユーザーにセルを割り当て、割り当てられたセルの残容量を評価するためにセル ID を `Scaler` 関数に送信します。
`Scaler` 関数は以下の応答を返します。
`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 開発者 |
| ユーザーセルを取得します。 | `Orchestrator` を使用して `Mapper` 関数を実行するには、次のコマンドを実行します。curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper
`Orchestrator` は、ユーザーに割り当てられたセルを検索し、以下の応答でセル ID と URL を返します。
`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 開発者 |
### クリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リソースをクリーンアップします。 | アカウントで追加料金が発生しないようにするには、次の操作を行います。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/serverless-cell-router-architecture.html) | アプリ開発者 |
## 関連リソース
**リファレンス**
+ [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 障害分離境界: 静的安定性](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html)
**動画**
[Physalia: Cell-based Architecture to Provide Higher Availability on Amazon EBS](https://www.youtube.com/watch?v=6IknqRZMFic)
[https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0](https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0)
## 追加情報
**セルベースアーキテクチャ設計の前提**
このパターンではセルルーターに焦点を当てていますが、環境全体を理解することが重要です。環境は 3 つの個別のレイヤーで構成されています。
+ ルーティングレイヤー、またはセルルーターを含むシンレイヤー
+ さまざまなセルで構成されるセルレイヤー
+ セルをプロビジョニングしてアプリケーションをデプロイするプロビジョンとデプロイレイヤー
各レイヤーは、他のレイヤーに影響を与える障害が発生した場合でも機能を維持します。 AWS アカウント は障害分離の境界として機能します。
次の図は、レイヤーの概要を示しています。セルレイヤーおよびプロビジョンとデプロイレイヤーは、このパターンの範囲外です。
セルベースアーキテクチャの詳細については、「[Reducing the Scope of Impact with Cell-Based Architecture: Cell routing](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/cell-routing.html)」を参照してください。
**セルルーターの設計パターン**
セルルーターはセル間で共有されるコンポーネントです。潜在的な影響を軽減するには、ルーティングレイヤーが、できるだけ薄くてシンプルで水平方向にスケーラブルな設計を使用することが重要です。ルーティングレイヤーは、システムのエントリポイントとして機能し、ユーザーを適切なセルに効率的に割り当てるために必要なコンポーネントのみで構成されます。このレイヤー内のコンポーネントは、セルの管理や作成には関与しません。
このパターンでは静的ルーティングを使用します。つまり、クライアントは最初のログイン時にエンドポイントをキャッシュし、その後セルとの直接通信を確立します。クライアントとセルルーター間の定期的なインタラクションが開始されると、現在のステータスを確認したり、更新を取得したりします。この意図的なデカップリングにより、セルルーターのダウンタイム発生時に既存のユーザーの操作を中断することなく、システム内で継続的な機能と耐障害性を提供します。
このパターンでは、セルルーターは次の機能をサポートしています。
+ プロビジョンとデプロイレイヤーのセルデータベースからセルデータを取得し、ローカルデータベースを保存または更新します。
+ セル割り当てアルゴリズムを使用して、アプリケーションの新しい登録ユーザーごとにセルを割り当てます。
+ ユーザーとセル間のマッピングをローカルデータベースに保存します。
+ ユーザー割り当て中にセルの容量をチェックし、ベンディングマシンのイベントをプロビジョンとデプロイレイヤーに上げてセルを作成します。
+ セル作成基準アルゴリズムを使用してこの機能を提供します。
+ 静的セルの URL を提供して、新しい登録ユーザーのリクエストに応答します。これらの URL は、有効期限 (TTL) を使用してクライアントでキャッシュされます。
+ 新規または更新された URL を提供して、無効な URL の既存のユーザーリクエストに応答します。
CloudFormation テンプレートによってセットアップされるデモセルルーターをさらに理解するには、以下のコンポーネントとステップを確認してください。
1. Amazon Cognito ユーザープールを設定して構成します。
1. セルルーターの API Gateway API を設定して構成します。
1. DynamoDB テーブルを作成します。
1. SQS キューを作成して設定します。
1. `Orchestrator` を実装します。
1. Lambda 関数 (`Dispatcher`、`Scaler`、`Mapper`、`Validator`) を実装します。
1. 評価して検証します。
プロビジョンとデプロイレイヤーが既に確立されていることが前提です。実装の詳細は、このアーティファクトの範囲外です。
これらのコンポーネントは 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 を設定し構成します。次の要素を実装します。
+ `POST` メソッドを含む `CellRouter` API リソース
+ ステップ 5 で実装された Step Functions ワークフローとの統合
+ Amazon Cognito オーソライザーによる認可
+ 統合リクエストと応答マッピング
+ 必要なアクセス許可の割り当て
*3. DynamoDB テーブルを作成する*
[https://console.aws.amazon.com/dynamodb/]() で DynamoDB コンソールを開き、次の設定で `tbl_router` という名前の標準 DynamoDB テーブルを作成します。
+ **パーティションキー** – `marketId`
+ **ソートキー** – `cellId`
+ **キャパシティモード** – プロビジョンド
+ **ポイントインタイムリカバリ (PITR)** – オフ
**[インデックス]** タブで、`marketId-currentCapacity-index` というグローバルセカンダリインデックスを作成します。`Scaler` Lambda 関数は、インデックスを使用して、割り当てられたユーザーの数が最も少ないセルを効率的に検索します。
次の属性を使用してテーブル構造を作成します。
+ `marketId` – Europe
+ `cellId` – cell-0002
+ `currentCapacity` – 2
+ `endPoint_1` – <最初のリージョンのエンドポイント>
+ `endPoint_2` – <2 番目のリージョンのエンドポイント>
+ `IsHealthy` – True
+ `maxCapacity` – 10
+ `regionCode_1` ‒ `eu-north-1`
+ `regionCode_2` ‒ `eu-central-1`
+ `userIds` –
*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` 関数に送信されます。関数は、次のような事前定義された評価基準を使用してリクエストを処理します。
1. **リージョン** – ユーザーが配置されているマーケットのセルを選択します。たとえば、ユーザーが欧州からグローバルアプリケーションにアクセスする場合は、欧州 AWS リージョン で が使用するセルを選択します。
1. **近接またはレイテンシー** – ユーザーに最も近いセルを選択します。例えば、ユーザーがオランダからアプリケーションにアクセスする場合、関数はフランクフルトとアイルランドを使用するセルを考慮します。どのセルが最も近いかの決定は、ユーザーのロケーションとセルリージョン間のレイテンシーなどのメトリクスに基づきます。このパターン例では、情報はプロビジョンとデプロイレイヤーから静的に供給されます。
1. **正常性** – `Dispatcher` 関数は、指定されたセルの状態 (正常 = true または false) に基づいて、選択したセルが正常かどうかを確認します。
1. **容量** – ユーザーディストリビューションは*セル内の最小ユーザー数*ロジックに基づいているため、ユーザーはユーザー数が最も少ないセルに割り当てられます。
**注記**
これらの基準は、このパターン例の説明のみを目的に示されています。実際のセルルーター実装では、より細かいユースケースに基づく基準を定義できます。
`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 キューを介してプロビジョンとデプロイレイヤーへのリクエストを開始し、新しいセルのプロビジョニングとデプロイを要求します。セルのスケーリングは、次のような一連の評価基準に基づいて実行できます。
1. **最大ユーザー数** – 各セルの最大ユーザー数は 500 です。
1. **バッファ容量** – 各セルのバッファ容量は 20% です。つまり、各セルはいつでも 400 のユーザーに割り当てることができます。残りの 20% のバッファ容量は、将来のユースケースや予期しないシナリオ (セルの作成やサービスのプロビジョニングが利用できない場合など) の処理用に予約されています。
1. **セルの作成** – 既存のセルが容量の 70% に達するとすぐに、追加のセルを作成するリクエストがトリガーされます。
**注記**
これらの基準は、このパターン例の説明のみを目的に示されています。実際のセルルーター実装では、より細かいユースケースに基づく基準を定義できます。
デモンストレーションの `Scaler` コードは、`Dispatcher` が新しく登録されたユーザーにセルを正常に割り当てた後、`Orchestrator` によって実行されます。`Scaler` は `Dispatcher` からセル ID を受け取ると、事前定義された評価基準に基づいて、指定されたセルに追加のユーザーを受け入れるのに十分な容量があるかどうかを評価します。セルの容量が不十分な場合、`Scaler` 関数は Amazon SQS サービスにメッセージをディスパッチします。このメッセージは、プロビジョンとデプロイレイヤー内のサービスによって取得され、新しいセルのプロビジョニングが開始されます。
**バリデーター関数**
`Validator` 関数は、セルアクセスに関連する問題を特定して解決します。ユーザーがグローバルアプリケーションにサインインすると、アプリケーションはユーザープロファイル設定からセルの URL を取得し、ユーザーリクエストをセル内の 2 つの割り当てられたリージョンのいずれかにルーティングします。URL にアクセスできない場合、アプリケーションは検証 URL リクエストをセルルーターにディスパッチできます。セルルーター `Orchestrator` は `Validator` を呼び出します。`Validator` は検証プロセスを開始します。検証には、次のようなチェックが含まれる可能性があります。
+ リクエスト内のセル URL をデータベースに保存されている URL と相互参照して、潜在的な更新を特定して処理する
+ ディープヘルスチェックを実行する (セルのエンドポイントへの `HTTP GET` リクエストなど)
結論として、`Validator` 関数はクライアントアプリケーションリクエストに応答を配信し、検証ステータスを必要な修復ステップとともに提供します。
`Validator` は、ユーザーエクスペリエンスを向上させるように設計されています。インシデントによりセルが一時的に使用できなくなり、特定のユーザーがグローバルアプリケーションにアクセスできないシナリオを考えてみましょう。`Validator` 関数では、一般的なエラーを提示する代わりに、指示的な修復ステップを提供できます。これらのステップには以下のようなアクションが含まれます。
+ インシデントについてユーザーに通知する。
+ サービスが利用できるようになるまでのおおよその待機時間を提示する。
+ 追加情報を取得するためのサポート連絡先番号を提示する。
`Validator` 関数のデモコードは、リクエスト内のユーザーが指定したセル URL と `tbl_router` テーブルに保存されているレコードが一致することを確認します。この `Validator` 関数は、セルが正常かどうかも確認します。