翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # サーバーレス **Topics** + [AWS Amplify を使用してサーバーレスの React Native モバイルアプリを構築する](build-a-serverless-react-native-mobile-app-by-using-aws-amplify.md) + [複数の SaaS 製品間のテナントを単一のコントロールプレーンで管理する](manage-tenants-across-multiple-saas-products-on-a-single-control-plane.md) + [静的 IP アドレスに関連付けられたエンドポイントを使用して、Amazon S3 の署名付き URL の生成とオブジェクトのダウンロードを統合する](consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.md) + [組織でクロスアカウント Amazon EventBridge 接続を作成する](create-cross-account-amazon-eventbridge-connection-organization.md) + [で Kinesis Data Streams と Firehose を使用して Amazon S3 に DynamoDB レコードを配信する AWS CDK](deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.md) + [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md) + [psycopg2 ライブラリを にインポート AWS Lambda して PostgreSQL データベースとやり取りする](import-psycopg2-library-lambda.md) + [Amazon API Gateway を Amazon SQS と統合して非同期 REST API を処理する](integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.md) + [Amazon API Gateway と AWS Lambda を使用してイベントを非同期的に処理する](process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.md) + [Amazon API Gateway と Amazon DynamoDB Streams を使用してイベントを非同期的に処理する](processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.md) + [Amazon API Gateway、Amazon SQS、および AWS Fargate でイベントを非同期的に処理する](process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.md) + [AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.md) + [AWS Lambda 関数で Python を使用して S3 オブジェクトの並列読み取りを実行する](run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.md) + [から OpenSearch AWS Lambda にテレメトリデータを送信してリアルタイムの分析と視覚化を行う](send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.md) + [セルベースアーキテクチャ用にサーバーレスセルルーターを設定する](serverless-cell-router-architecture.md) + [VPC エンドポイントを介して Amazon S3 バケットへのプライベートアクセスを設定する](set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.md) + [Amazon Bedrock AWS Step Functions を使用して の状態をトラブルシューティングする](troubleshooting-states-in-aws-step-functions.md) + [その他のパターン](serverless-more-patterns-pattern-list.md) # AWS Amplify を使用してサーバーレスの React Native モバイルアプリを構築する *Amazon Web Services、Deekshitulu Pentakota* ## 概要 このパターンでは、AWS Amplify と以下の AWS サービスを使用して React Native モバイルアプリのサーバーレスバックエンドを作成する方法を説明しています。　 + AWS AppSync + Amazon Cognito + Amazon DynamoDB Amplify を使用してアプリケーションのバックエンドを設定してデプロイすると、Amazon Cognito はアプリケーションユーザーを認証し、アプリケーションへのアクセスを許可します。　 次に、AWS AppSync はフロントエンドアプリケーションおよびバックエンドの DynamoDB テーブルとやり取りし、データを作成して取得します。 **注記** このパターンでは、例としてシンプルな「ToDoList」アプリを使用しますが、同様の手順を使用して、任意の React Native モバイルアプリケーションを作成できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.amplify.aws/cli/start/install/) がインストール済みおよび設定済み + XCode (任意のバージョン) + Microsoft Visual Studio (任意のバージョン、任意のコードエディター、任意のテキストエディター) + Amplify Gurify に精通している + Amazon Cognito に精通している + AWS AppSync に精通している + DynamoDB に精通している + Node.js に精通している + npm に精通している + React と React Native に精通している + JavaScript と ECMAScript 6 (ES6) に精通している + GraphQL に精通している ## アーキテクチャ 次の図は、AWS クラウドで React Native モバイルアプリのバックエンドを実行するためのアーキテクチャの例を示しています。 ![\[AWS サービスで React Native モバイルアプリを実行するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c95e0150-5762-4c90-946c-efa3a22913e4/images/5beff5f9-9d14-49dc-a046-b74e5bfbd13f.png) 以下は、アーキテクチャ図を示しています。 1. Amazon Cognito はアプリユーザーを認証し、アプリへのアクセスを許可します。　 1. 次に、AWS AppSync はフロントエンドアプリおよびバックエンドの DynamoDB テーブルとやり取りし、データを作成して取得します。 ## ツール **AWS サービス** + [AWS Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html) は、フロントエンドのウェブおよびモバイルデベロッパーが AWS で迅速かつ簡単にフルスタックアプリケーションを構築できるようにする専用のツールと機能のセットです。 + [AWS AppSync](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html) は、Amazon DynamoDB、AWS Lambda、および HTTP API を含む、複数のソースからのデータを組み合わせることで、アプリケーション開発者にとって便利でスケーラブルな GraphQL インターフェイスを提供します。 + [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 データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。 **コード** このパターンで使用されているサンプルアプリケーションのコードは、GitHub [aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) リポジトリから入手できます。このサンプルファイルを使用するには、このパターンの [**エピック**] セクションの指示に従ってください。 ## エピック ### React Native アプリを作成して実行します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | React Native 開発環境のセットアップ | 手順については、React Native ドキュメントの「[開発環境のセットアップ](https://reactnative.dev/docs/next/environment-setup)」を参照してください。 | アプリ開発者 | | iOS シミュレーターで ToDoList React Native モバイルアプリを作成して実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ### アプリの新しいバックエンド環境を初期化します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AAmplify でアプリをサポートするために必要なバックエンドサービスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**React Native Amplify アプリの構成設定の例**
? Name: ToDoListAmplify

? Environment: dev

? Default editor: Visual Studio Code

? App type: javascript

? Javascript framework: react-native

? Source Directory Path: src

? Distribution Directory Path: /

? Build Command: npm run-script build

? Start Command: npm run-script start

? Select the authentication method you want to use: AWS profile

? Please choose the profile you want to use: default
詳細については、Amplify Dev Center ドキュメントの「[新しい Amplify バックエンドの作成](https://docs.amplify.aws/lib/project-setup/create-application/q/platform/js/#create-a-new-amplify-backend)」を参照してください。`amplify init` コマンドは、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用して以下のリソースをプロビジョニングします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ### Amplify React Native アプリに Amazon Cognito 認証を追加する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Cognito 認証サービスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**認証サービスの設定例**
? Do you want to use the default authentication and security configuration? \ 
Default configuration
 
? How do you want users to be able to sign in? \ 
Username 

? Do you want to configure advanced settings? \ 
No, I am done
`amplify add auth` コマンドは、プロジェクトのルートディレクトリ内のローカルフォルダ (**amplify**) に、必要なフォルダ、ファイル、依存関係ファイルを作成します。このパターンで使用する TodoList アプリの設定では、この目的で **aws-exports.js** が作成されます。 | アプリ開発者 | | Amazon Cognito サービスを AWS クラウドにデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)プロジェクトにデプロイされたサービスを確認するには、以下のコマンドを実行して Amplify コンソールに移動します。`amplify console` | アプリ開発者 | | React Native に必要な Amplify ライブラリをインストールし、iOS には CocoaPods 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | | Amplify サービスをインポートして設定します。 | アプリのエントリポイントファイル (**App.js** など) で、次のコード行を入力することで、Amplify サービスの設定ファイルをインポートして読み込みます。
import Amplify from 'aws-amplify'
import config from './src/aws-exports'
Amplify.configure(config)
Amplify サービスをアプリのエントリポイントファイルにインポートした後にエラーが発生した場合は、アプリを停止してください。次に、XCode を開き、プロジェクトの iOS フォルダーから **TodoListAmplify.xcWorkspace** を選択して、アプリを実行します。 | アプリ開発者 | | WithAuthenticator 高次コンポーネント (HOC) を使用するようにアプリのエントリポイントファイルを更新します。 | `withAuthenticator` HOC は、わずか数行のコードを使用して、サインイン、サインアップ、パスワードを忘れた場合のワークフローをアプリ内で実現します。詳細については、Amplify Dev Center で「[オプション 1: ビルド済み UI コンポーネントを使用する](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#option-1-use-pre-built-ui-components)」を参照してください。また、React ドキュメントの [高次コンポーネント](https://reactjs.org/docs/higher-order-components.html) についても説明します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)**WithAuthenticator HOC コード例**
import Amplify from 'aws-amplify'
import config from './src/aws-exports'
Amplify.configure(config)
import { withAuthenticator } from 'aws-amplify-react-native';


const App = () => {
  return null;
};


export default withAuthenticator(App);
iOS シミュレーターでは、アプリには Amazon Cognito サービスが提供するログイン画面が表示されます。 | アプリ開発者 | | 認証サービスの設定をテストします。 | iOS シミュレータで、以下の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)[Amazon Cognito コンソール](https://console.aws.amazon.com/cognito/)を開いて、**アイデンティティプール**に新しいユーザーが作成されたかどうかを確認することもできます。 | アプリ開発者 | ### AWS AppSync API と DynamoDB データベースをアプリにコネクトします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS AppSync API と DynamoDB データベースを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**API とデータベースの設定例**
? Please select from one of the below mentioned services: \ 
GraphQL 

? Provide API name: todolistamplify

? Choose the default authorization type for the API \ 
Amazon Cognito User Pool

Do you want to use the default authentication and security configuration

? Default configuration How do you want users to be able to sign in? \ 
Username

Do you want to configure advanced settings? \ 
No, I am done.

? Do you want to configure advanced settings for the GraphQL API \ 
No, I am done.

? Do you have an annotated GraphQL schema? \ 
No

? Choose a schema template: \ 
Single object with fields (e.g., "Todo" with ID, name, description)

? Do you want to edit the schema now? \ 
Yes
**GraphQL スキーマの例**
 type Todo @model {
   id: ID!
   name: String!
   description: String
}
| アプリ開発者 | | AWS AppSync API をデプロイします。　 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)このパターンで使用する TodoList アプリの設定には、以下の設定例を適用してください。**AWS AppSync API の設定例**次の設定では、AWS AppSync に GraphQL API を作成し、Dynamo DB に **Todo** テーブルを作成します。
 ? Are you sure you want to continue? Yes
? Do you want to generate code for your newly created GraphQL API Yes
? Choose the code generation language target javascript
? Enter the file name pattern of graphql queries, mutations and subscriptions src/graphql/**/*.js
? Do you want to generate/update all possible GraphQL operations - \ 
queries, mutations and subscriptions Yes
? Enter maximum statement depth \
[increase from default if your schema is deeply nested] 2
| アプリ開発者 | | アプリのフロントエンドを AWS AppSync API に接続します。 | このパターンで提供されているサンプル TodoList アプリケーションを使用するには、[aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) GitHub リポジトリの **App.js** ファイルからコードをコピーします。次に、サンプルコードをローカル環境に統合します。リポジトリの **App.js** ファイルにあるサンプルコードは以下の処理を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | アプリ開発者 | ## 関連リソース + 「[AWS Amplify](https://aws.amazon.com/amplify/)」 + [Amazon Cognito](https://aws.amazon.com/cognito/) + [AWS AppSync](https://aws.amazon.com/appsync/) + 「[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)」 + 「[React](https://reactjs.org/)」 (React ドキュメント) # 複数の SaaS 製品間のテナントを単一のコントロールプレーンで管理する *Amazon Web Services、Ramanna Avancha、Kishan Kavala、Anusha Mandava、Jenifer Pascal* ## 概要 このパターンは、AWS クラウドの単一のコントロールプレーンで、複数の Software as a Service (SaaS) 製品にまたがるテナントのライフサイクルを管理する方法を示しています。提供されるリファレンスアーキテクチャは、組織が個々の SaaS 製品間で冗長な共有機能の実装を減らし、ガバナンスの効率性を大幅に向上させるのに役立ちます。 大手企業は、さまざまなビジネスユニット間で複数のSaaS製品を保有できます。多くの場合、これらの製品は、さまざまなサブスクリプションレベルの外部テナントが使用できるようにプロビジョニングする必要があります。共通のテナントソリューションがない場合、IT 管理者はコア製品の機能開発に集中するのではなく、複数のSaaS API 間で差別化されていない機能の管理に時間を費やす必要があります。 このパターンで提供される共通テナントソリューションは、次のような組織の共有 SaaS 製品機能の多くを一元管理するのに役立ちます。 + セキュリティ + テナントプロビジョニング + テナントデータストレージ + テナントコミュニケーション + 製品管理 + マトリックス記録とモニタリング ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Amazon Cognito または第三者の ID プロバイダー (IdP) に関する知識 + Amazon API Gateway に関する知識 + AWS Lambda に関する知識 + Amazon DynamoDB に関する知識 + AWS Identity and Access Management (IAM) + AWS Step Functions に関する知識 + AWS CloudTrail と Amazon CloudWatch に関する知識 + Python ライブラリとコードに関する知識 + さまざまなタイプのユーザー (組織、テナント、管理者とアプリケーションユーザー)、サブスクリプションモデルとテナント分離モデルを含む SaaS API に関する知識 + 組織のマルチプロダクト SaaS 要件とマルチテナントサブスクリプションに関する知識 **制限事項** + 一般的なテナントソリューションと個々の SaaS 製品との統合は、このパターンには含まれていません。 + このパターンでは、Amazon Cognito サービスは単一の AWS リージョンにのみデプロイされます。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon API Gateway + Amazon Cognito + AWS CloudTrail + Amazon CloudWatch + Amazon DynamoDB + IAM + AWS Lambda + Amazon Simple Storage Service (Amazon S3) + Amazon Simple Notification Service (Amazon SNS) + AWS Step Functions **ターゲットアーキテクチャ** 次の図は、AWS クラウドの 1 つのコントロールプレーンで複数の SaaS 製品間におけるテナントライフサイクルを管理するためのワークフローの例を示しています。 ![\[1 つのコントロールプレーンでテナントライフサイクルを管理するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4306bc76-22a7-45ca-a107-43df6c6f7ac8/images/700faf4d-c28f-4814-96aa-2d895cdcb518.png) この図表は、次のワークフローを示しています: 1. AWS ユーザーは、API ゲートウェイエンドポイントを呼び出して、テナントのプロビジョニング、製品のプロビジョニングまたは管理関連のアクションを開始します。 1. ユーザーは、Amazon Cognito ユーザープールまたは別の IdP から取得したアクセストークンにより認証されます。 1. 個々のプロビジョニングまたは管理タスクは、API Gateway API エンドポイントと統合された Lambda 関数により、実行されます。 1. 共通テナントソリューション (テナント、製品、ユーザー用) の管理 API は、必要な入力パラメータ、ヘッダー、トークンをすべて収集します。その後、管理 API は関連する Lambda 関数を呼び出します。 1. 管理 API と Lambda 関数の両方の IAM 権限は、IAM サービスにより、検証されます。 1. Lambda 関数は、DynamoDB と Amazon S3 のカタログ (テナント、製品、ユーザー用) のデータを保存し、取得します。 1. アクセス権限が検証されると、特定のタスクを実行するために、AWS Step Functions ワークフローが呼び出されます。この図の例は、テナントのプロビジョニングワークフローを示しています。 1. 個々の AWS Step Functions ワークフロータスクは、あらかじめ決められたワークフロー (ステートマシン) で実行されます。 1. 各ワークフロータスクに関連付けられた Lambda 関数の実行に必要かつ重要なデータは、DynamoDB または Amazon S3 から取得されます。他の AWS リソースは、AWS CloudFormation テンプレートでプロビジョニングする必要がある場合があります。 1. 必要に応じて、ワークフローは特定の SaaS 製品用に追加の AWS リソースをプロビジョニングするリクエストをその製品の AWS アカウントに送信します。 1. リクエストが成功または失敗する場合、ワークフローはステータス更新をメッセージとして Amazon SNS トピックに発行します。 1. Amazon SNS は Step Functions ワークフローの Amazon SNS トピックにサブスクライブされています。 1. 次に、Amazon SNS はその後、ワークフローステータスの更新を AWS ユーザーに送り返します。 1. API 呼び出しの監査証跡を含む各 AWS サービスのアクションのログは CloudWatch に送信されます。CloudWatch では、ユースケースごとに特定のルールとアラームを設定できます。 1. ログは監査の目的で Amazon S3 バケットにアーカイブされます。 **自動化とスケール** このパターンは、CloudFormation テンプレートで、共通テナントソリューションのデプロイの自動化に役立ちます。このテンプレートは、関連するリソースの迅速なスケールアップまたはスケールダウンにも役立ちます。 詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS CloudFormation テンプレートの使用](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。 ## ツール **AWS サービス** + 「[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)」は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。 + 「[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」は、AWS アカウントのガバナンス、コンプライアンス、運用のリスクの監査をサポートします。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、AWS のリソースや、AWS で実行されるアプリケーションをリアルタイムにモニタリングします。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [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 Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。 ## ベストプラクティス このパターンのソリューションでは、単一のコントロールプレーンで複数のテナントのオンボーディングを管理し、複数のSaaS製品へのアクセスをプロビジョニングします。コントロールプレーンは、管理ユーザーがほかの 4 つの機能に固有のプレーンを管理することに役立ちます。 + セキュリティプレーン + ワークフロープレーン + コミュニケーションプレーン + ログ記録とモニタリング ## エピック ### セキュリティプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マルチテナント SaaS プラットフォームの要件を確立します。 | 以下の要件の詳細を確立します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | クラウドアーキテクト、AWS システム管理者 | | Amazon Cognito サービスを設定します。 | 「*Amazon Cognito 開発者ガイド*」の「[Amazon Cognito の使用開始方法](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-getting-started.html)」に記載されている指示に従ってください。 | クラウドアーキテクト | | 必要な IAM ポリシーを設定します。 | ユースケースに必要なIAMポリシーを作成します。その後、ポリシーを Amazon Cognito の IAM ロールにマッピングします。詳細については、*Amazon Cognito デベロッパーガイド*の「[ポリシーを使用したアクセスの管理](https://docs.aws.amazon.com/cognito/latest/developerguide/security-iam.html#security_iam_access-manage)」と「[ロールベースアクセスコントロール](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)」を参照してください。 | クラウド管理者、クラウドアーキテクト、AWS IAM sセキュリティ | | 必要な API アクセス権限を設定します。 | IAM ロールとポリシーおよび Lambda 認証で API Gatewayのアクセス権限を設定します。手順については、「*Amazon API Gateway 開発者ガイド*」の以下のセクションを参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | クラウド管理者、クラウドアーキテクト | ### データプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 必要なデータカタログを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*Amazon DynamoDB デベロッパーガイド*の「[DynamoDB のセットアップ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SettingUp.html)」を参照してください。 | DBA | ### コントロールプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数と API Gateway API を作成して、必要なコントロールプレーンタスクを実行します。 | Lambda 関数と API Gateeway API を個別に作成して、次の項目の追加、削除と管理を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*AWS Lambda デベロッパーガイド*の「[Amazon API Gateway での AWS Lambda の使用](https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html)」を参照してください。 | アプリ開発者 | ### ワークフロープレーンを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Step Functions ワークフローが実行する必要のあるタスクを特定します。 | 次の AWS Step Functions ワークフロー要件の詳細を特定して文書化します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)主要な利害関係者が要件を承認していることを確認してください。 | アプリ所有者 | | 必要な AWS Step Functions ワークフローを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | アプリ開発者、ビルドリード | ### コミュニケーションプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon SNS トピックを作成します。 | Amazon SNS トピックを作成して、以下に関する通知を受信します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)詳細については、*Amazon SNS デベロッパーガイド*の「[SNS トピックの作成](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html)」を参照してください。 | アプリ所有者、Cloud アーキテクト | | エンドポイントを各 Amazon SNS トピックにサブスクライブします。 | Amazon SNS トピックにパブリッシュされたメッセージを受信するには、各トピックにエンドポイントをサブスクライブする必要があります。詳細については、*Amazon SNS デベロッパーガイド*の「[Amazon SNS トピックのサブスクライブ](https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html)」を参照してください。 | アプリ開発者、Cloud アーキテクト | ### 記録プレーンとモニタリングプレーンの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 共通テナントソリューションの各コンポーネントの記録を有効にします。 | 作成した共通テナントソリューション内の各リソースの記録をコンポーネントレベルで有効にします。手順については、以下を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)IAM ポリシーを使用することで、各リソースのログを一元化されたロギングアカウントに統合できます。詳細については、「[集中記録と複数アカウントのセキュリティガードレール](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/centralized-logging-and-multiple-account-security-guardrails.html)」を参照してください。 | アプリ開発者、AWS システム管理者、クラウド管理者 | ### 共通テナントソリューションのプロビジョニングとデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートを作成します。 | CloudFormation テンプレートを使用して、共通テナントソリューション全体とそのすべてのコンポーネントのデプロイとメンテナンスを自動化します。詳細については、「[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。 | アプリ開発者、DevOpsエンジニア、CloudFormation 開発者 | ## 関連リソース + [Amazon Cognito ユーザープールをオーソライザーとして使用して REST API へのアクセスを制御する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)(*Amazon API Gateway デベロッパーガイド*) + [API Gateway Lambda オーソライザーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)(*Amazon API Gateway デベロッパーガイド*) + [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)(*Amazon Cognito デベロッパーガイド*) + [クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)(*Amazon CloudWatch ユーザーガイド*) # 静的 IP アドレスに関連付けられたエンドポイントを使用して、Amazon S3 の署名付き URL の生成とオブジェクトのダウンロードを統合する *Song Jin、Eunhye Jo、Jun Soung Lee (Amazon Web Services)* ## 概要 このパターンは、オブジェクトのダウンロード用に安全なカスタム署名付き URL を作成することで、Amazon Simple Storage Service (Amazon S3) へのアクセスを簡素化します。このソリューションは、一意のドメインと静的 IP アドレスを持つ、単一のエンドポイントを提供します。これは、API エンドポイントと Amazon S3 エンドポイントの両方を、静的 IP アドレスを持つ統合ドメインに集約する必要があるユーザー向けにカスタマイズされています。このユースケースでは、ユーザーが IP とドメインの許可リストのファイアウォールポリシーに従い、API アクセスを特定のドメインと IP アドレスに制限します。 このアーキテクチャでは AWS のサービス、Amazon API Gateway AWS Global Accelerator、 AWS Lambda Application Load Balancer AWS PrivateLink、Amazon S3 などのキーを使用します。この設計では、署名付き URL を生成するための API と Amazon S3 エンドポイントを 1 つのドメインに一元化し、2 つの静的 IP アドレスを持つアクセラレーターにリンクします。これにより、ユーザーが署名付き URL をリクエストし、静的 IP アドレスを持つ統合ドメインエンドポイントを介して Amazon S3 オブジェクトをダウンロードする一連の流れがスムーズになります。 このアーキテクチャは、厳格なポリシーやコンプライアンス要件を持つ、公共部門、医療、金融などのユーザーにとって特に有益です。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + カスタムドメインのパブリックホストゾーン + AWS リージョン 任意の で AWS Certificate Manager (ACM) にインポートされたドメイン **制限事項** + Amazon S3 バケット名はエンドポイントのドメイン名と一致する必要があります。この要件の目的は、単一の API エンドポイント経由で Amazon S3 エンドポイントにサービスを提供できるようにすることです。 + API Gateway で使用されるカスタムドメイン名は、単一の API エンドポイントのドメイン名と一致する必要があります。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ 次の図は、このパターンのターゲットアーキテクチャとワークフローを示したものです。 ![\[署名付き URL の生成とオブジェクトのダウンロードのためのコンポーネントとワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e19ebcb5-2138-481e-952e-3cfee9ad9e97/images/effd197c-d4d7-4990-8b66-3eb1c64aab4c.png) この図は、次の概念とワークフローを示しています。 1. ユーザーは、カスタムドメイン名と関連する IP アドレスを使用して AWS Global Accelerator、 を通じて提供されるカスタムエンドポイントを使用して署名付き URL を生成するリクエストを開始します。 1. Lambda 関数は、カスタムエンドポイントを指す署名付き URL を生成します。生成された署名付き URL を含む 301 リダイレクトで応答します。ユーザーはリダイレクトされた署名付き URL を通じて、Global Accelerator から提供されるカスタムエンドポイントを使用し、オブジェクトを自動的にダウンロードします。 署名付き URL を生成し、オブジェクトをダウンロードするワークフローのアーキテクチャ全体のコンポーネントは、次のとおりです。 + Global Accelerator による静的 IP アドレスのプロビジョニング。 + アクセラレーターのエイリアスを、Amazon Route 53 パブリックホストゾーンに A レコードとしてカスタムドメイン名で登録。 + 登録されたカスタムドメイン名と一致するバケット名を持つ Amazon S3 バケットの作成。 + API Gateway と Amazon S3 サービスの VPC エンドポイントの作成。 + Global Accelerator に接続するための内部向け Application Load Balancer の設定。 + ACM 証明書がアタッチされた API Gateway のカスタムドメイン名の割り当て。 + Lambda 関数と統合されたプライベート API Gateway のデプロイ。 + Lambda 関数には、 AWS Identity and Access Management (IAM) ロールがアタッチされています ([GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) アクセス許可があります）。 ## ツール **AWS のサービス** + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/) は、複数のアベイラビリティーゾーンにある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの複数のターゲットに、受信するアプリケーショントラフィックを分散します。 + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) は、複数の AWS リージョンのエンドポイントをサポートするグローバルサービスです。 AWS グローバルネットワーク経由で最適なエンドポイントにトラフィックを誘導するアクセラレーターを作成できます。これにより、世界中のユーザーが使用するインターネットアプリケーションの可用性とパフォーマンスが向上します。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から VPC 外のサービスへの一方向のプライベート接続を確立するのに役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンは、必要に応じて AWS CDK または Terraform を使用してデプロイできます。「[エピック](#consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-epics)」セクションには、両方のデプロイ方法の手順を記載しています。このパターンのコードは、GitHub 内の以下のリポジトリで入手できます。 + **AWS CDK** – [s3-presignedurl-staticips-endpoint-with-cdk](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-cdk) + **Terraform** – [s3-presignedurl-staticips-endpoint-with-terraform](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-terraform) ## ベストプラクティス + 本番環境のセキュリティを強化するには、[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) などの認可メカニズムを実装して、`PresignedUrl` 生成 API へのアクセスを制限することが重要です。 + 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドメイン名の決定 | 統合 Amazon S3 エンドポイントのパブリックドメイン名を決定します。このドメイン名は Amazon S3 バケット名としても使用されます。 | AWS 管理者、ネットワーク管理者 | | パブリックホストゾーンの作成 | Amazon Route 53 に[パブリックホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)を作成します。このドメイン名は、API Gateway で使用されるドメイン名と一致する必要があります。 | AWS 管理者、ネットワーク管理者 | | SSL 証明書の準備 | AWS Certificate Manager (ACM) を使用して、ウェブアプリケーションドメインの SSL 証明書を[リクエスト](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html)または[インポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)します。 | AWS 管理者、ネットワーク管理者 | ### Terraform を使用してパターンをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Terraform 開発環境の設定 | 開発環境を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | `.tfvars` および** **`provider.tf` ファイルの変更 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html)次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | ネットワークリソースのプロビジョニング | ネットワークリソースをプロビジョニングするには、次のコマンドを実行します。
cd ./2.vpc_alb_ga
terraform init
terraform plan --var-file=apg.tfvars
terraform apply --var-file=apg.tfvars
`apply ` コマンドの実行中、確認を求められたら「**yes**」と入力します。 | AWS 管理者、クラウド管理者 | | API Gateway、Amazon S3、Lambda のプロビジョニング | ネットワークリソースをプロビジョニングするには、次のコマンドを使用します。
cd ./2.apigw_s3_lambda
terraform init
terraform plan --var-file=apg.tfvars
terraform apply --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | ### を使用してパターンをデプロイする AWS CDK | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK 開発環境を設定します。 | 開発環境を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | `config/index.ts` ファイルでドメイン設定を指定する | 定数変数のオプションを編集するには、次のコマンドを使用します。
export const options = {
    certificateArn: '{arn of the acm which created before}',
    dnsAttr: {
        zoneName: '{public hosted zone name}',
        hostedZoneId: 'hosted zone Id',
    },
    domainNamePrefix: '{Prefix for the domain}',
    presignPath: 'presign',
    objectsPath: 'objects',
};
コマンドの各プレースホルダーを、必要な情報に置き換えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 管理者、クラウド管理者 | | スタックのデプロイ | 仮想プライベートクラウド (VPC) 用とアプリケーション用の 2 つのスタックをデプロイするには、次のコマンドを使用します。
$ npm install 
$ cdk synth 
$ cdk deploy --all
| AWS 管理者、クラウド管理者 | ### パターンをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | エンドポイントの IP アドレスの確認 | このパターンのドメインに静的 IP アドレスがあることを確認するには、次のコマンドを使用します。
nslookup ${s3-bucket-prefix}.${domain}
| ネットワーク管理者 | | 後からダウンロード可能なテストファイルをアップロード | テストファイルを、Amazon S3 バケットの `'/objects'` フォルダにアップロードします。 | AWS 管理者、クラウド管理者 | | 署名付き URL を生成する API を起動 | 署名付き URL を生成するには、ブラウザまたは API クライアント ([Postman](https://www.postman.com/product/what-is-postman/) など) から次の形式で URL を呼び出します。
https://${s3-bucket-prefix}.${domain}/presign/objects/${uploaded-filename}
`${s3-bucket-prefix}` および `${domain}` のプレースホルダー値を、前のステップで設定した各値に置き換えます。 | アプリ所有者 | | 結果を確認 | 期待される結果は、301 (Moved Permanently) リダイレクトステータスコードを受け取ることです。このレスポンスには、テストファイルのダウンロードを自動的に開始する署名付き URL が含まれます。 | テストエンジニア | ### Terraform でのクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API Gateway、Amazon S3、および Lambda リソースの破棄 | 次のコマンドを使用して、各リソースを削除します。
cd ./2.apigw_s3_lambda
terraform init
terraform plan --destroy --var-file=apg.tfvars
terraform destroy --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | | ネットワークリソースの破棄 | 次のコマンドを使用して、各ネットワークリソースを削除します。
cd ./1.vpc_alb_ga
terraform init
terraform plan --destroy --var-file=apg.tfvars
terraform destroy --var-file=apg.tfvars
| AWS 管理者、クラウド管理者 | ### でクリーンアップする AWS CDK | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スタックの破棄 | VPC スタックとアプリケーションスタックの両方を破棄するには、次のコマンドを使用します。
$ cdk destroy --all
| AWS 管理者、クラウド管理者 | | Amazon S3 バケットを空にして削除する | デフォルトでは削除されない、オブジェクトの Amazon S3 バケットとログの Amazon S3 バケットを[空](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)にして[削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)します。これらの Amazon S3 バケット名は `${s3-bucket-prefix}.${domain}` と `${s3-bucket-prefix}.${domain}-logs` です。バケットの削除に [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) を使用する場合は、次のコマンドを使用します。
$ aws s3 rm s3://${s3-bucket-prefix}.${domain} --recursive
$ aws s3 rb s3://${s3-bucket-prefix}.${domain} --force
$ aws s3 rm s3://${s3-bucket-prefix}.${domain}-logs --recursive
$ aws s3 rb s3://${s3-bucket-prefix}.${domain}-logs --force
`${s3-bucket-prefix}` と `${domain}` を、前のステップで設定した値に置き換えます。 | AWS 管理者、クラウド管理者 | ## 関連リソース **AWS ブログ** + [が提供する静的 IP アドレスを介した Amazon API Gateway へのアクセス AWS Global Accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/accessing-an-aws-api-gateway-via-static-ip-addresses-provided-by-aws-global-accelerator/) + [JavaScript AWS CDK 用の署名付き URL をモジュラーで生成する](https://aws.amazon.com/blogs/developer/generate-presigned-url-modular-aws-sdk-javascript/) + [Hosting Internal HTTPS Static Websites with ALB, S3, and PrivateLink](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/) # 組織でクロスアカウント Amazon EventBridge 接続を作成する *Amazon Web Services、Sam Wilson および Robert Stone* ## 概要 大規模な分散システムでは、Amazon EventBridge を使用して、 AWS Organizations 組織内のさまざまな Amazon Web Services (AWS) アカウント間で状態の変化を通信します。しかし、EventBridge は通常、同じ AWS アカウント内のエンドポイントまたはコンシューマーのみをターゲットにできます。例外は、別のアカウントのイベントバスです。そのイベントバスは有効なターゲットです。別のアカウントのイベントバスからイベントを使用するには、イベントをソースアカウントのイベントバスから送信先アカウントのイベントバスに反映する必要があります。異なる 内のアプリケーション間で重要なイベントを管理する際の課題を回避するには AWS アカウント、このパターンで示されている推奨アプローチを使用します。 このパターンは、 AWS Organizations 組織 AWS アカウント 内の複数の が関与する EventBridge を使用してイベント駆動型アーキテクチャを実装する方法を示しています。このパターンでは AWS Cloud Development Kit (AWS CDK) Toolkit と を使用します AWS CloudFormation。 EventBridge には、イベントを受信、フィルタリング、変換、ルーティング、配信するのに役立つサーバーレスのイベントバスが用意されています。イベント駆動型アーキテクチャの重要なコンポーネントである EventBridge は、メッセージの作成者とそのメッセージの使用者の分離に対応しています。これは、単一のアカウントでは簡単です。マルチアカウント構成では、1 つのアカウントのイベントバス上のイベントを同じ組織内の他のアカウントで使用するために、さらなる考慮が必要です。 作成者と使用者のアカウント固有の考慮事項については、「[追加情報](#create-cross-account-amazon-eventbridge-connection-organization-additional)」セクションを参照してください。 ## 前提条件と制限 **前提条件** + 少なくとも 2 つの が関連付けられている AWS Organizations 組織 AWS アカウント + を使用して両方の でインフラストラクチャをプロビジョニング AWS アカウント できる の AWS Identity and Access Management (IAM) ロール AWS アカウント AWS CloudFormation + Git が[ローカルにインストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)されている + AWS Command Line Interface (AWS CLI) [ローカルにインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)されている + AWS CDK [ローカルにインストール](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)され、両方の で[ブートストラップされている](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto) AWS アカウント **製品バージョン** このパターンは、次のツールとバージョンを使用して構築され、テストされています。 + AWS CDK ツールキット 2.126.0 + Node.js 18.19.0 + npm 10.2.3 + Python 3.12 このパターンは、任意のバージョンの AWS CDK v2 または npm で動作する必要があります。Node.js のバージョン 13.0.0～13.6.0 は AWS CDKと互換性がありません。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、あるアカウントからイベントを送信し、別のアカウントで消費するためのアーキテクチャワークフローを示しています。 ![\[送信元のプロデューサーアカウントと送信先のコンシューマーアカウントを接続する 3 ステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/34a5f3ae-511d-4636-999f-c73396770117/images/ccc4878a-6281-4a77-a483-4e6f299d7807.png) ワークフローの主なステップは、次のとおりです。 1. ソースアカウントのプロデューサー AWS Lambda 関数は、アカウントの EventBridge イベントバスにイベントを配置します。 1. クロスアカウント EventBridge ルールは、送信先アカウントの EventBridge イベントバスにイベントをルーティングします。 1. 送信先アカウントの EventBridge イベントバスには、コンシューマー Lambda 関数を呼び出すターゲット Lambda ルールがあります。 ベストプラクティスは、コンシューマー Lambda 関数の失敗した呼び出しを処理するために[デッドレターキュー (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) を使用することです。しかし、わかりやすくするために DLQ はこのソリューションでは省略されています。ワークフローに DLQ を実装し、ワークフローが障害から回復する機能を向上させる方法の詳細については、[AWS Lambda 「エラー処理パターンの実装](https://aws.amazon.com/blogs/compute/implementing-aws-lambda-error-handling-patterns/)」ブログ記事を参照してください。 **自動化とスケール** AWS CDK は、必要なアーキテクチャを自動的にプロビジョニングします。EventBridge は、 AWS リージョンに応じて 1 秒あたり数千レコードまでスケールできます。詳細は、「[Amazon EventBridge quotas](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html)」を参照してください。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。このパターンでは、 AWS CDK アプリケーションの操作に役立つコマンドラインクラウド開発キットである [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) を使用します。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 **その他のツール** + [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 + [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。 + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub の [cross-account-eventbridge-in-organization](https://github.com/aws-samples/aws-cdk-examples/tree/main/python/cross-account-eventbridge-in-organization) リポジトリで入手可能です。 ## ベストプラクティス EventBridge を使用する際のベストプラクティスは、次のリソースを参照してください。 + [Amazon EventBridge イベントパターンのベストプラクティス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-patterns-best-practices.html) + [Amazon EventBridge でルールを定義する際のベストプラクティス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules-best-practices.html) ## エピック ### ローカル AWS CDK デプロイ環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースアカウントと送信先アカウントのローカル認証情報を設定する。 | 「[Setting up new configuration and credentials](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new)」を確認し、環境に最も適した認証方法と認証情報を使用します。ソースアカウント認証と送信先アカウント認証の両方 AWS CLI に を設定してください。この手順では、`sourceAccount` と `destinationAccount` の 2 つの AWS プロファイルをローカルに設定していることを前提としています。 | アプリ開発者 | | 両方をブートストラップします AWS アカウント。 | アカウントをブートストラップするには、次のコマンドを実行します。
cdk bootstrap --profile sourceAccount
cdk bootstrap --profile destinationAccount
| アプリデベロッパー | | パターンコードをクローンする。 | リポジトリをクローンするには、次のコマンドを実行します。
git clone git@github.com:aws-samples/aws-cdk-examples.git
次に、ディレクトリを新しくクローンしたプロジェクトフォルダに変更します。
cd aws-cdk-examples/python/cross-account-eventbridge-in-organization
| アプリデベロッパー | ### ソースアカウントに ProducerStack をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations とアカウントの詳細`cdk.json`を使用して を変更します。 | プロジェクトのルートフォルダで、`cdk.json` に次の変更を加えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリ開発者 | | ProducerStack リソースをデプロイする。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk deploy ProducerStack --profile sourceAccount
プロンプトが表示されたら、新しい IAM ロールと、 を通じて作成されたその他のセキュリティ関連のアクセス許可を受け入れます AWS CloudFormation。 | アプリ開発者 | | ProducerStack リソースがデプロイされていることを確認する。 | リソースを確認するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### ConsumerStack を送信先アカウントにデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ConsumerStack リソースをデプロイする。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk deploy ConsumerStack --profile destinationAccount
プロンプトが表示されたら、新しい IAM ロールと、 を通じて作成されたその他のセキュリティ関連のアクセス許可を受け入れます CloudFormation。 | アプリ開発者 | | ConsumerStack リソースがデプロイされていることを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### イベントの生成と消費 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロデューサー Lambda 関数を呼び出す。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | | イベントが受信されたことを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | アプリデベロッパー | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ConsumerStack リソースを破棄する。 | このパターンをテストとして使用している場合は、追加コストが発生しないように、デプロイされたリソースを削除します。プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk destroy ConsumerStack --profile destinationAccount
スタックの削除を確認するプロンプトが表示されます。 | アプリデベロッパー | | ProducerStack リソースを破棄する。 | プロジェクトのルートディレクトリから、次のコマンドを実行します。
cdk destroy ProducerStack --profile sourceAccount
スタックの削除を確認するプロンプトが表示されます。 | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 送信先アカウントでイベントが受信されなかった。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | | コンソールから Lambda 関数を呼び出すと、次のエラーが返される。`User: arn:aws:iam::123456789012:user/XXXXX is not authorized to perform: lambda:Invoke` | Lambda `ProducerStack-ProducerLambdaXXXX` 関数に対する適切な`lambda:Invoke`アクション許可を受け取るには、 AWS アカウント 管理者にお問い合わせください。 | ## 関連リソース **リファレンス** + [AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) + [Amazon EventBridge のイベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) + [Amazon EventBridge のルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) **チュートリアルと動画** + [Tutorial: Creating and configuration an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html) + [AWS re:Invent 2023 - Amazon EventBridge を使用した高度なイベント駆動型パターン (COM301-R)](https://www.youtube.com/watch?v=6X4lSPkn4ps) ## 追加情報 **プロデューサールール** ソースアカウントでは、プロデューサーからのメッセージを受け入れる EventBridge イベントバスが作成されます (「*アーキテクチャ*」セクションを参照)。このイベントバスには、IAM アクセス許可が付随するルールが作成されます。このルールは、次の `cdk.json` 構成に基づいて、送信先アカウントの EventBridge イベントバスをターゲットにします。 ``` "rules": [ { "id": "CrossAccount", "sources": ["Producer"], "detail_types": ["TestType"], "targets": [ { "id": "ConsumerEventBus", "arn": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount" } ] } ] ``` 消費するイベントバスごとに、イベントパターンとターゲットのイベントバスを含める必要があります。 *イベントパターン* [イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)は、このルールが適用されるイベントをフィルタリングします。この例では、イベントソースとレコードの `detail_types` は、どのイベントをソースアカウントのイベントバスから送信先アカウントのイベントバスに送信するかを識別します。 *ターゲットイベントバス* このルールは、別のアカウントに存在するイベントバスを対象としています。ターゲットイベントバスを一意に識別するには完全な `arn` (Amazon リソースネーム) が必要であり、`id` は AWS CloudFormationで使用される[論理 ID](https://docs.aws.amazon.com/cdk/v2/guide/identifiers.html#identifiers_logical_ids) です。ターゲットイベントバスは、ターゲットルールの作成時に実際に存在する必要はありません。 **送信先アカウント固有の考慮事項** 送信先アカウントでは、ソースアカウントのイベントバスからメッセージを受信する EventBridge イベントバスが作成されます。ソースアカウントからイベントを発行できるようにするには、[リソースベースのポリシー](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html)を作成する必要があります。 ``` { "Version": "2012-10-17", "Statement": [{ "Sid": "AllowOrgToPutEvents", "Effect": "Allow", "Principal": "*", "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-XXXXXXXXX" } } }] } ``` `events:PutEvents` 権限を付与することは特に重要です。これにより、同じ組織内の他のアカウントがこのイベントバスにイベントを発行できるようになります。`aws:PrincipalOrgId` を組織 ID として設定すると、必要なアクセス許可が付与されます。 **イベントパターン** 含まれているイベントパターンは、ユースケースに応じて変更できます。 ``` rule = events.Rule( self, self.id + 'Rule' + rule_definition['id'], event_bus=event_bus, event_pattern=events.EventPattern( source=rule_definition['sources'], detail_type=rule_definition['detail_types'], ) ) ``` 不要な処理を減らすために、イベントパターンでは、送信先アカウントによって処理されるべきイベントのみが送信先アカウントのイベントバスに送信されるように指定する必要があります。 *リソースベースのポリシー* この例では、組織 ID を使用して、どのアカウントが送信先アカウントのイベントバスにイベントを配置できるかを制御します。ソースアカウントの指定など、より制限の厳しいポリシーの使用を検討します。 *EventBridge クォータ* 次の[クォータ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html)に留意してください。 + イベントバスあたり 300 ルールがデフォルトのクォータです。これは必要に応じて拡張できますが、ほとんどのユースケースに合わせる必要があります。 + 1 つのルールにつき 5 つのターゲットが最大許容数です。アプリケーションアーキテクトは、イベントパターンをきめ細かく制御できるように、送信先アカウントごとに個別のルールを使用することをお勧めします。 # で Kinesis Data Streams と Firehose を使用して Amazon S3 に DynamoDB レコードを配信する AWS CDK *Amazon Web Services、Shashank Shrivastava、Daniel Matuki da Cunha* ## 概要 このパターンは、Amazon Kinesis Data Streams および Amazon Kinesis Data Streams および Amazon Data Firehose を使用して Amazon DynamoDB から Amazon Simple Storage Service (Amazon S3) にレコードを配信するためのサンプルコードとアプリケーションを提供します。このパターンのアプローチでは [AWS Cloud Development Kit (AWS CDK) L3 コンストラクト](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)を使用し、Amazon Web Services (AWS) クラウド上のターゲット S3 バケットにデータが配信される AWS Lambda 前に でデータ変換を実行する方法の例を示します。 Kinesis Data Streams は、DynamoDB テーブルの項目レベルの変更を記録し、それらを必須の Kinesis Data Streams にレプリケートします。アプリケーションは Kinesis Data Streams にアクセスし、項目レベルの変更をほぼリアルタイムで表示できます。Kinesis Data Streams では、Firehose や Amazon Managed Service for Apache Flink など、他の Amazon Kinesis サービスにもアクセスできます。つまり、リアルタイムのダッシュボードの提供、アラートの生成、動的な料金設定、広告の実装、高度なデータ分析の実行を行うアプリケーションを構築できます。 このパターンは、データ統合のユースケースに使用できます。たとえば、輸送車両や産業機器は、DynamoDB テーブルに大量のデータを送信できます。その後、このデータを変換して Amazon S3 でホストされているデータレイクに保存できます。その後、Amazon Athena、Amazon Redshift Spectrum、Amazon Rekognition、 AWS Glueなどのサーバーレスサービスを使用して、データをクエリして処理し、潜在的な欠陥を予測できます。 ## 前提条件と制限 *前提条件* + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI)、インストールおよび設定済み。詳細については、 AWS CLI ドキュメント[の「 の開始方法 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。 + Node.js (18.x\$1) と npm、インストールおよび設定済み。詳細については、[`npm`ドキュメントの Node.js と npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) のダウンロードとインストールを参照してください。 + aws-cdk (2.x\$1) がインストールされ設定済み。詳細については、 AWS CDK ドキュメント[の「 の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)」を参照してください。 + GitHub [aws-dynamodb-kinesisfirehose-s3-インジェスト](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/) リポジトリは、ローカルマシンにクローン化されて設定されています。 + DynamoDB テーブルの既存のサンプルデータ。データは以下のフォーマットを使用する必要があります：`{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}` ## アーキテクチャ 次の図は、Kinesis データストリームと Firehose を使用して DynamoDB から Amazon S3 にレコードを配信するためのワークフローの例を示しています。 ![\[Kinesis データストリームと Firehose を使用して DynamoDB から Amazon S3 にレコードを配信するためのワークフローの例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e2a9c412-312e-4900-9774-19a281c578e4/images/6e6df998-e6c2-4eaf-b263-ace752194689.png) この図表は、次のワークフローを示しています: 1. データは Amazon API Gateway を DynamoDB のプロキシとして使用して取り込まれます。他のソースを使用して DynamoDB にデータを取り込むこともできます。  1. アイテムレベルの変更は、Kinesis Data Streams でほぼリアルタイムで生成され、Amazon S3 に配信されます。 1. Kinesis データストリームは Firehose にレコードを送信し、変換と配信を行います。  1. Lambda 関数は、レコードを DynamoDB レコード形式から、レコード項目の属性名と値のみを含む JSON 形式に変換します。 ## ツール *AWS のサービス* + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義して割り当てるのに役立つソフトウェア開発フレームワークです。 + [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDK アプリの操作に役立つコマンドラインクラウド開発キットです。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 *コードリポジトリ* このパターンのコードは、GitHub 内の「[aws-dynamodb-kinesisfirehose-s3-Ingestion](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/)」リポジトリで利用できます。 ## エピック ### サンプルコードのセットアップおよび設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SDK の依存関係をインストールします。 | ローカルマシンで、次のコマンドを実行して、`package.json`、`pattern/aws-dynamodb-kinesisstreams-s3`、および `sample-application` ディレクトリのファイルから依存関係をインストールします。
cd /pattern/aws-dynamodb-kinesisstreams-s3 
npm install && npm run build
cd /sample-application/
npm install && npm run build
  | アプリ開発者、AWS 全般 | | CloudFormation テンプレートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | アプリケーション開発者、一般的な AWS、AWS DevOps | ### リソースのデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースを確認してデプロイしてください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | アプリケーション開発者、一般的な AWS、AWS DevOps | ### DynamoDB テーブルにデータを取り込み、ソリューションをテストします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB テーブルにサンプルデータを取り込みます。 | 次のコマンドを実行して、DynamoDB テーブルにリクエストを送信します AWS CLI。`aws dynamodb put-item --table-name --item '{"": {"S": ""},"MessageData":{"S": ""}}'`例:`aws dynamodb put-item --table-name SourceData_table --item '{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}'`デフォルトでは、`put-item` オペレーションが成功しても、は出力として値を返しません。操作が失敗した場合はエラーを返します。データは DynamoDB に保存され、Kinesis データストリームと Firehose に送信されます。 DynamoDB テーブルにデータを追加するには、さまざまな方法が使用できます。詳細については、「DynamoDB ドキュメント」の「[テーブルへのデータのロード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SampleData.LoadData.html)」を参照してください。 | アプリ開発者 | | S3 バケットに新しいオブジェクトが作成されたことを確認します。 | にサインイン AWS マネジメントコンソール し、S3 バケットをモニタリングして、送信したデータで新しいオブジェクトが作成されていることを確認します。 詳細については、「Amazon S3 ドキュメント」の「[GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html)」を参照してください。 | アプリ開発者、AWS 全般 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | `cdk destroy` コマンドを実行して、このパターンで使用されているリソースをすべて削除します。 | アプリ開発者、AWS 全般 | ## 関連リソース + [s3-static-site-stack.ts](https://github.com/awslabs/aws-solutions-constructs/blob/main/source/use_cases/aws-s3-static-website/lib/s3-static-site-stack.ts#L25) (GitHub リポジトリ) + [aws-apigateway-dynamodb](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-apigateway-dynamodb) モジュール (GitHub リポジトリ) + [aws-kinesisstreams-kinesisfirehose-s3](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-kinesisstreams-kinesisfirehose-s3) モジュール (GitHub リポジトリ) + 「[DynamoDB Streams の変更データキャプチャ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html)」 (「DynamoDB ドキュメント」) + 「[Kinesis Data Streams を使用して DynamoDB への変更をキャプチャする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)」 (「DynamoDB ドキュメント」) # Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する *Corey Schnedl、Marcelo Barbosa、Mario Lopez Martinez、Anbazhagan Ponnuswamy、Gaurav Samudra、Abhilash Vinod、Amazon Web Services* ## 概要 このパターンでは、[カスタムドメイン](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html)の [API マッピング](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html)機能を使用して Amazon API Gateway 用のパスベースの API バージョニングソリューションを実装する方法を示します。 Amazon API Gateway は、API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。サービスのカスタムドメイン機能を使用すると、API ユーザーに提供できる直感的な URL を使用して、シンプルなカスタムドメイン名を作成できます。API マッピングを使用して、API ステージをカスタムドメイン名に接続することができます。ドメイン名を作成し、DNS レコードを設定したら、API マッピングを使用して、カスタムドメイン名を使用して API にトラフィックを送信します。 API が公開されると、コンシューマーに利用されます。パブリック API が進化するにつれて、そのサービス契約も新機能が反映されるように進化します。ただし、既存の機能を変更または削除することは賢明ではありません。重大な変更は、コンシューマーのアプリケーションに影響を与え、実行時にアプリケーションを破損する可能性があります。API バージョニングは、下位互換性を損なったり、契約に違反したりしないようにするために重要です。 API のバージョニングには、コンシューマーが簡単に採用できるようにするための明確な戦略が必要です。パスベースの URL を使用した API のバージョニングは、最も簡単で一般的に使用されるアプローチです。このタイプのバージョニングでは、バージョンは API URI の一部として明示的に定義されます。次の URL の例で、コンシューマーが URI を使用してリクエストのために API バージョンを指定する方法を示します。 `https://api.example.com/api/v1/orders ` `https://api.example.com/api/v2/orders ` `https://api.example.com/api/vX/orders` このパターンでは、 を使用して、API 用のスケーラブルなパスベースのバージョニングソリューションのサンプル実装 AWS Cloud Development Kit (AWS CDK) を構築、デプロイ、テストします。 AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするオープンソースのソフトウェア開発フレームワークです。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + このパターンのサンプルリポジトリを使用し、Amazon API Gateway カスタムドメイン機能を使用するには、ドメインの所有権が必要です。Amazon Route 53 を使用して、組織のドメインを作成および管理できます。Route 53 を使用してドメインを登録または移管する方法については、Route 53 ドキュメントの「[新しいドメインの登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register-update.html)」を参照してください。 + API のカスタムドメイン名をセットアップする前に、 AWS Certificate Managerで [SSL/TLS 証明書](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-specify-certificate-for-custom-domain-name.html)を準備する必要があります。 + API エンドポイントにマッピングするために DNS プロバイダーのリソースレコードを作成または更新する必要があります。このマッピングを行わないと、カスタムドメイン名宛ての API リクエストが API Gateway に届きません。 **制限事項** + カスタムドメイン名は、すべての AWS リージョン で 内で一意である必要があります AWS アカウント。 + 複数のレベルで API マッピングを設定するには、リージョン別カスタムドメイン名と TLS 1.2 セキュリティポリシーを使用する必要があります。 + API マッピングでは、カスタムドメイン名とマップされた API が同じ AWS アカウントにある必要があります。 + API マッピングに含めることができるのは、文字、数字、および `$-_.+!*'()/` の文字だけです。 + API マッピングのパスの最大文字数は 300 文字です。 + ドメイン名ごとに、複数のレベルで 200 個の API マッピングを設定できます。 + TLS 1.2 セキュリティポリシーでは、HTTP API をリージョン別カスタムドメイン名にだけマッピングできます。 + WebSocket APIs HTTP API または REST API と同じカスタムドメイン名にマッピングすることはできません。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + このサンプル実装では、[AWS CDK in TypeScript](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) バージョン 2.149.0 を使用します。 ## アーキテクチャ 以下の図に、アーキテクチャのワークフローを示します。 ![\[API マッピングとカスタムドメインを使用してパスベースの API バージョニングソリューションを実装するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e1b32d2b-410f-4ace-967e-f0b8aaf0304c/images/fa9f04f1-efa6-4fb1-a541-ae3da4076b00.png) この図表は、以下を示すものです: 1. API ユーザーが、カスタムドメイン名を使用して Amazon API Gateway にリクエストを送信します。 1. API Gateway が、リクエストの URL に示されているパスに基づいて、ユーザーのリクエストを API Gateway の適切なインスタンスとステージに動的にルーティングします。次の表に、さまざまな URL ベースのパスを API Gateway のさまざまなインスタンスの特定のステージにルーティングする方法の例を示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-path-based-api-versioning-by-using-custom-domains.html) 1. 送信先 API Gateway インスタンスがリクエストを処理し、結果をユーザーに返します。 **自動化とスケール** API のバージョンごとに個別の AWS CloudFormation スタックを使用することをお勧めします。このアプローチでは、カスタムドメイン API マッピング機能によって、ルーティング先にできるバックエンド API を完全に分離できます。このアプローチの利点は、別の API を変更するリスクを発生させることなく、API のさまざまなバージョンを個別にデプロイまたは削除できることです。このアプローチは、CloudFormation スタックを分離することで耐障害性を向上させます。また、HTTP エンドポイント AWS Lambda、 アクションなど、API AWS Fargateのさまざまなバックエンドオプションも提供します AWS のサービス。 [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/gitflow-branching-strategy.html) などの Git 分岐戦略を分離された CloudFormation スタックと組み合わせて使用して、さまざまなバージョンの API にデプロイされるソースコードを管理できます。このオプションを使用すると、新しいバージョン用にソースコードを複製することなく、さまざまなバージョンの API を管理できます。Gitflow を使用すると、リリースの実行時に git リポジトリ内のコミットにタグを追加できます。それにより、特定のリリースに関連するソースコードの完全なスナップショットが作成されます。更新を実行する必要がある場合は、特定のリリースのコードをチェックアウトし、更新を行い、対応するメジャーバージョンと一致する CloudFormation スタックに更新済みのソースコードをデプロイできます。このアプローチでは、API の各バージョンには分離されたソースコードがあり、個別の CloudFormation スタックにデプロイされるため、別の API バージョンが破壊されるリスクが軽減されます。 ## ツール **AWS のサービス** + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです CloudFormation。このパターンのサンプル実装では、[AWS CDK in TypeScript](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) を使用します。TypeScript AWS CDK で を操作するには、Microsoft TypeScript コンパイラ (`tsc`)、[Node.js](https://nodejs.org/)、ノードパッケージマネージャー () などの使い慣れたツールを使用します`npm`。必要に応じて [Yarn](https://yarnpkg.com/) を使用できますが、このパターンの例では `npm` を使用します。[AWS コンストラクトライブラリ](https://docs.aws.amazon.com/cdk/v2/guide/libraries.html#libraries-construct)を構成するモジュールは、`npm ` リポジトリの [npmjs.org](https://docs.npmjs.com/) を介して配布されます。 + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html) は、保護されたウェブアプリケーションリソースに転送される HTTP と HTTPS リクエストをモニタリングできるウェブアプリケーションファイアウォールです。 **その他のツール** + [Bruno](https://www.usebruno.com/) はオープンソースの git フレンドリーな API テストクライアントです。 + [cdk-nag](https://github.com/cdklabs/cdk-nag) は、ルールパックを使用して AWS CDK アプリケーションのベストプラクティスをチェックするオープンソースユーティリティです。 **コードリポジトリ** このパターンのコードは、GitHub の「[path-based-versioning-with-api-gateway](https://github.com/aws-samples/path-based-versioning-with-api-gateway)」リポジトリで入手できます。 ## ベストプラクティス + 堅牢な継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して、 AWS CDKで構築された CloudFormation スタックのテストとデプロイを自動化します。この推奨事項の詳細については、「[AWS Well-Architected DevOps のガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」を参照してください。 + AWS WAF は、Amazon API Gateway などのサービスと簡単に統合できるマネージドファイアウォールです。 AWS WAF は、このバージョニングパターンが機能するために必要なコンポーネントではありませんが、 API Gateway AWS WAF に を含めるセキュリティのベストプラクティスとしてお勧めします。 + 古いバージョンの API を効率的に廃止し、削除できるように、API コンシューマーに定期的に最新バージョンの API にアップグレードするよう促します。 + このアプローチを本番環境で使用する前に、API の認可戦略とファイアウォールを導入してください。 + [最小特権アクセスモデル](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) AWS アカウント を使用して、 の AWS リソース管理へのアクセスを実装します。 + で構築されたアプリケーションのベストプラクティスとセキュリティに関する推奨事項を適用するには AWS CDK、[cdk-nag ユーティリティ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/check-aws-cdk-applications-or-cloudformation-templates-for-best-practices-by-using-cdk-nag-rule-packs.html)を使用することをお勧めします。 ## エピック ### ローカル環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを実行して、サンプルアプリケーションのリポジトリをクローン作成するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/path-based-versioning-with-api-gateway
| アプリ開発者 | | リポジトリのクローンを作成した場所にナビゲートします。 | リポジトリのクローンを作成したフォルダに移動するには、次のコマンドを実行します。
cd api-gateway-custom-domain-versioning
| アプリ開発者 | | 必要な依存ファイルをインストールします。 | 必要な従属関係をインストールには、次のコマンドを実行します。
npm install
| アプリ開発者 | ### CloudFormation ルーティングスタックをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルーティングスタックのデプロイを開始します。 | CloudFormation ルーティングスタック `CustomDomainRouterStack` のデプロイを開始するには、次のコマンドを実行します。`example.com` は、所有しているドメインの名前に置き換えてください。
npx cdk deploy CustomDomainRouterStack --parameters PrerequisiteDomainName=example.com
次のドメイン DNS 検証タスクが正常に実行されるまで、スタックのデプロイは成功しません。 | アプリ開発者 | ### ドメインの所有権を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドメインの所有権を検証します。 | 証明書は、関連付けられたドメインの所有権を証明するまで、**保留中の検証**のステータスのままになります。所有権を証明するには、ドメインに関連付けられているホストゾーンに CNAME レコードを追加します。詳細については、 AWS Certificate Manager ドキュメントの[「DNS 検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)」を参照してください。適切なレコードを追加すると、`CustomDomainRouterStack` デプロイが成功します。 | アプリ開発者、AWS システム管理者、ネットワーク管理者 | | API Gateway カスタムドメインを指すエイリアスレコードを作成します。 | 証明書が正常に発行および検証されたら、Amazon API Gateway カスタムドメイン URL を指す [DNS レコードを作成します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-regional-api-custom-domain-create.html#apigateway-regional-api-custom-domain-dns-record)。カスタムドメイン URL は、カスタムドメインのプロビジョニングによって一意に生成され、CloudFormation 出力パラメータとして指定されます。次の内容は[レコードの例](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html)です。**ルーティングポリシー**: シンプルルーティング**レコード名**: `demo.api-gateway-custom-domain-versioning.example.com`**Alias (エイリアス)**: あり**レコードタイプ**: AWS リソースを指す「A」タイプの DNS レコード**値**: `d-xxxxxxxxxx.execute-api.xx-xxxx-x.amazonaws.com`**TTL (秒)**: 300 | アプリ開発者、AWS システム管理者、ネットワーク管理者 | ### CloudFormation スタックをデプロイして API を呼び出す | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `ApiStackV1` スタックをデプロイします。 | `ApiStackV1` スタックをデプロイするには、以下のコマンドを実行します。
npm run deploy-v1
次の CDK コードは API マッピングを追加します。
var apiMapping = new CfnApiMapping(this, "ApiMapping", {
      apiId: this.lambdaRestApi.restApiId,
      domainName: props.customDomainName.domainName,
      stage: "api",
      apiMappingKey: "api/v1",
    });
| アプリ開発者 | | `ApiStackV2` スタックをデプロイします。 | `ApiStackV2` スタックをデプロイするには、以下のコマンドを実行します。
npm run deploy-v2
| アプリ開発者 | | API を呼び出します。 | Bruno を使用して API を呼び出し、API エンドポイントをテストするには、「[追加情報](#implement-path-based-api-versioning-by-using-custom-domains-additional)」の手順を参照してください。 | アプリ開発者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | このサンプルアプリケーションに関連付けられたリソースを破棄するには、次のコマンドを実行します。
npx cdk destroy --all
ドメイン所有権の検証プロセスのために手動で追加した Route 53 DNS レコードを必ずクリーンアップしてください。 | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 証明書を検証できないため、`CustomDomainRouterStack` のデプロイがタイムアウトする。 | 前のタスクで説明したように、適切な DNS 検証 CNAME レコードが追加されていることを確認してください。新しい証明書は、DNS 検証レコードの追加後に、**[保留中の検証]** のステータスを最大 30 分間表示し続けます。詳細については、 AWS Certificate Manager ドキュメントの[「DNS 検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)」を参照してください。 | ## 関連リソース + [Amazon CloudFront を使用したヘッダーベースの API Gateway バージョニングの実装](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/) – この AWS コンピューティングブログ記事では、このパターンで説明されているパスベースのバージョニング戦略の代わりに、ヘッダーベースのバージョニング戦略を提供しています。 + [AWS CDK ワークショップ](https://cdkworkshop.com/20-typescript.html) – この入門ワークショップでは、 を使用して AWS でアプリケーションを構築およびデプロイすることに重点を置いています AWS Cloud Development Kit (AWS CDK)。このワークショップでは、Go、Python、TypeScript をサポートしています。 ## 追加情報 **Bruno を使用した API のテスト** オープンソース API テストツールである [Bruno](https://www.usebruno.com/) を使用して、パスベースのルーティングがサンプルアプリケーションに対して適切に動作していることを検証することをお勧めします。このパターンでは、サンプル API のテストを容易にするサンプルコレクションを用意しています。 API を呼び出してテストするには、次の手順を実行します。 1. [Bruno をインストールします。](https://www.usebruno.com/downloads) 1. Bruno を開きます。 1. このパターンの[コードリポジトリ](https://github.com/aws-samples/path-based-versioning-with-api-gateway)で、「**Bruno/Sample-API-Gateway-Custom-Domain-Versioning**」を選択し、コレクションを開きます。 1. ユーザーインターフェイス (UI) の右上にある **[環境]** ドロップダウンを表示するには、コレクション内の任意のリクエストを選択します。 1. **[環境]** ドロップダウンで、**[設定]** を選択します。 1. `REPLACE_ME_WITH_YOUR_DOMAIN` 値をカスタムドメインに置き換えます。 1. **[保存]** を選択し、**[設定]** セクションを閉じます。 1. **[サンドボックス環境]** では、**[アクティブ]** オプションが選択されていることを確認します****。 1. 選択したリクエストの **->** ボタンを使用して API を呼び出します。 1. V2 と比較して V1 で検証 (数値以外の値を渡す) がどのように処理されるかに注意してください。 API 呼び出しの例と V1 と V2 の検証の比較のスクリーンショットを確認するには、このパターンの[コードリポジトリ](https://github.com/aws-samples/path-based-versioning-with-api-gateway)の `README.md` ファイル内にある「**サンプル API をテストする**」を参照してください。 # psycopg2 ライブラリを にインポート AWS Lambda して PostgreSQL データベースとやり取りする *Amazon Web Services、Louis Hourcade* ## 概要 [Psycopg](https://www.psycopg.org/docs/) は Python 用の PostgresSQL データベースアダプタです。開発者は、この `psycopg2` ライブラリを使用して、PostgreSQL データベースとやり取りする Python アプリケーションを作成します。 Amazon Web Services (AWS) では、開発者は [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) を使用して、アプリケーションやバックエンドサービスのコードも実行できます。Lambda は、サーバーをプロビジョニングしたり管理したりすることなくコードを実行する、サーバーレスでイベント駆動型のコンピューティングサービスです。 デフォルトでは、[Lambda でサポートされている Python ランタイム](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)を使用する新しい関数を作成すると、 AWSによって提供される [Lambda のベースイメージ](https://github.com/aws/aws-lambda-base-images)から Lambda ランタイム環境が作成されます。`pandas` や `psycopg2` などのライブラリは、ベースイメージに含まれません。ライブラリを使用するには、ライブラリをカスタムパッケージにバンドルして Lambda にアタッチする必要があります。 ライブラリをバンドルしてアタッチする方法は複数あります。以下に例を示します。 + [.zip ファイルアーカイブ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html)から Lambda 関数をデプロイします。 + カスタムコンテナイメージから Lambda 関数をデプロイします。 + [Lambda レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html#lambda-layer-versions)を作成して、Lambda 関数にアタッチします。 このパターンでは、最初の 2 つのオプションについて説明します。 .zip デプロイパッケージを使用すると、Lambda 関数に `pandas` ライブラリを追加するのが比較的簡単になります。Linux マシンにフォルダを作成し、Lambda スクリプトを `pandas` ライブラリとライブラリの依存関係とともにフォルダに追加して、フォルダを圧縮して、Lambda 関数のソースとして提供します。 .zip デプロイパッケージを使用するのは一般的な方法ですが、この方法は `psycopg2` ライブラリでは機能しません。このパターンではまず、.zip デプロイパッケージを使用して `psycopg2` ライブラリを Lambda 関数に追加した場合に表示されるエラーを示します。次に、このパターンでは、Dockerfile から Lambda をデプロイし、`psycopg2` ライブラリが機能するように Lambda イメージを編集する方法を示します。 パターンがデプロイする 3 つのリソースの詳細については、「[追加情報](#import-psycopg2-library-lambda-additional)」セクションを参照してください。 ## 前提条件と制限事項 **前提条件** + このパターンで使用される AWS リソースをデプロイするための十分なアクセス許可 AWS アカウント を持つアクティブな + AWS Cloud Development Kit (AWS CDK) を実行してグローバルにインストールする `npm install -g aws-cdk` + Git クライアント + Python + Docker **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** + [Lambda でサポートされている](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) Python ランタイムバージョン + Psycopg2 バージョン 2.9.3 + Pandas バージョン 1.5.2 ## アーキテクチャ **ソリューションの概要** Lambda で `psycopg2` ライブラリを使用する際に直面する可能性のある課題を説明するために、このパターンでは、次の 2 つの Lambda 関数をデプロイします。 + .zip ファイルから作成された Python ランタイムを含む 1 つの Lambda 関数。`psycopg2` および `pandas` ライブラリは、[pip](https://pypi.org/project/pip/) を使用してこの .zip デプロイパッケージにインストールされます。 + Dockerfile から作成された Python ランタイムを含む 1 つの Lambda 関数。Dockerfile は、Lambda コンテナイメージに `psycopg2` および `pandas` ライブラリをインストールします。 最初の Lambda 関数は、`pandas` ライブラリとその依存関係を .zip ファイルにインストールし、Lambda はそのライブラリを使用できます。 2 番目の Lambda 関数は、Lambda 関数のコンテナイメージを構築することで、Lambda で `pandas` および `psycopg2` ライブラリを実行できることを示しています。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [pandas](https://pandas.pydata.org/) は、データの分析と操作を行うための Python ベースのオープンソースツールです。 + [Psycopg](https://www.psycopg.org/docs/) は、マルチスレッドアプリケーション用に設計された Python 言語用の PostgreSQL データベースアダプタです。このパターンでは Psycopg 2 を使用します。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub の [import-psycopg2-in-lambda-to-interact-with-postgres-database](https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database) リポジトリで使用できます。 ## ベストプラクティス このパターンでは、 AWS CDK を使用して Dockerfile から Lambda 関数を作成する作業例を示します。アプリケーションでこのコードを再利用する場合は、デプロイされたリソースがすべてのセキュリティ要件を満たしていることを確認してください。インフラストラクチャがデプロイされる前に設定ミスを見つけるには、クラウドインフラストラクチャ設定をスキャンする [Checkov](https://www.checkov.io/) などのツールを使用します。 ## エピック ### リポジトリのクローンを作成し、デプロイを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | ローカルマシンに GitHub リポジトリのクローンを作成するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database.git
cd AWS-lambda-psycopg2
| AWS 全般 | | デプロイを設定します。 | 次の情報を使用して `app.py` ファイルを編集します AWS アカウント。
aws_acccount = "AWS_ACCOUNT_ID"
region = "AWS_REGION"
# Select the CPU architecture you are using to build the image (ARM or X86)
architecture = "ARM"
| AWS 全般 | ### AWS アカウントをブートストラップしてアプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | をブートストラップします AWS アカウント。 | [AWS 環境をブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)していない場合は、 AWS アカウントの AWS 認証情報を使用して次のコマンドを実行します。
cdk bootstrap aws:///
| AWS 全般 | | コードをデプロイします。 | AWS CDK アプリケーションをデプロイするには、次のコマンドを実行します。
cdk deploy AWSLambdaPyscopg2
| AWS 全般 | ### AWS マネジメントコンソールから Lambda 関数をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | .zip ファイルから作成された Lambda 関数をテストします。 | .zip ファイルから作成された Lambda 関数をテストするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)Lambda はデフォルトイメージ内に必要な PostgreSQL ライブラリを見つけられないため、`psycopg2` ライブラリを使用できません。 | AWS 全般 | | Dockerfile から作成された Lambda 関数をテストします。 | Lambda 関数内で `psycopg2` ライブラリを使用するには、Lambda Amazon マシンイメージ (AMI) を編集する必要があります。Dockerfile から作成された Lambda 関数をテストするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)次のコードは、 AWS CDK テンプレートが作成する Dockerfile を示しています。
# Start from lambda Python3.13 image
FROM public.ecr.aws/lambda/python:3.13

# Copy the lambda code, together with its requirements
COPY lambda/requirements.txt ${LAMBDA_TASK_ROOT}
COPY lambda/lambda_code.py ${LAMBDA_TASK_ROOT}

# Install postgresql-devel in your image
RUN yum install -y gcc postgresql-devel

# install the requirements for the Lambda code
RUN pip3 install -r requirements.txt --target "${LAMBDA_TASK_ROOT}"

# Command can be overwritten by providing a different command in the template directly.
CMD ["lambda_code.handler"]
Dockerfile は、Python ランタイム用に AWS 提供された Lambda イメージを取得し、[postgresql-devel](https://yum-info.contradodigital.com/view-package/updates/postgresql-devel/) をインストールします。これには、PostgreSQL 管理サーバーと直接やり取りするアプリケーションをコンパイルするために必要なライブラリが含まれています。Dockerfile は、`requirements.txt` ファイルで示されている `pandas` および `psycopg2` ライブラリもインストールします。 | AWS 全般 | ## 関連リソース + [AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/home.html) + [AWS Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ## 追加情報 このパターンでは、 AWS CDK テンプレートは 3 つのリソースを持つ AWS スタックを提供します。 + Lambda 関数の [AWS Identity and Access Management (IAM) ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。 + Python ランタイムを含む Lambda 関数。関数は `Constructs/lambda/lambda_deploy.zip` デプロイパッケージからデプロイされます。 + Python ランタイムを含む Lambda 関数。関数は `Constructs` フォルダの Dockerfile からデプロイされます。 両方の Lambda 関数のスクリプトは、`pandas` ライブラリと `psycopg2` ライブラリが正常にインポートされたかどうかを確認します。 ``` import pandas print("pandas successfully imported") import psycopg2 print("psycopg2 successfully imported") def handler(event, context): """Function that checks whether psycopg2 and pandas are successfully imported or not""" return {"Status": "psycopg2 and pandas successfully imported"} ``` `lambda_deploy.zip` デプロイパッケージは `Constructs/lambda/build.sh` bash スクリプトを使用して構築されます。このスクリプトは、フォルダを作成し、Lambda スクリプトをコピーして、`pandas` ライブラリと `psycopg2` ライブラリをインストールし、.zip ファイルを生成します。.zip ファイルを自分で生成するには、この bash スクリプトを実行して AWS CDK スタックを再デプロイします。 Dockerfile は、Python ランタイムを使用する Lambda 用に AWS 提供されたベースイメージで始まります。Dockerfile は、デフォルトのイメージの上に `pandas` ライブラリと `psycopg2` ライブラリをインストールします。 # Amazon API Gateway を Amazon SQS と統合して非同期 REST API を処理する *Amazon Web Services、Natalia Colantonio Favero および Gustavo Martim* ## 概要 REST API をデプロイするときに、クライアントアプリケーションが公開できるメッセージキューの公開が必要となる場合があります。例えば、サードパーティー API のレイテンシーや応答の遅延の問題が発生したり、データベースクエリの応答時間を回避したり、同時実行 API が多数ある場合にサーバーのスケーリングを回避したりすることが必要となる場合があります。このようなシナリオでは、キューに公開するクライアントアプリケーションは、API がデータを受信したことだけを認識していればよく、データの受信後に何が起こるかを認識する必要はありません。 このパターンでは、[Amazon API Gateway](https://aws.amazon.com/api-gateway/) を使用して [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) にメッセージを送信することで、REST API エンドポイントを作成します。これにより、SQS キューへの直接アクセスを回避しながら、2 つのサービス間の統合を簡単に実装できるようになります。 ## 前提条件と制限事項 + [アクティブな AWS アカウント](https://portal.aws.amazon.com/billing/signup/iam) ## アーキテクチャ ![\[API Gateway を Amazon SQS と統合するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/70984dee-e49f-4446-9d52-49ce826c3909/images/737ba0b2-da8f-4478-8c54-0a4835fd69f9.png) 次の図は、これらのステップを示しています。 1. Postman などのツール、別の API、またはその他のテクノロジーを使用して、POST REST API エンドポイントをリクエストします。 1. API Gateway は、リクエストの本文で受信したメッセージをキューにポストします。 1. Amazon SQS はメッセージを受信し、成功または失敗のコードを含む応答を API Gateway に送信します。 ## ツール + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + 「[Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。   ## エピック ### SQS キューを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | キューを作成する。 | REST API からメッセージを受信する SQS キューを作成するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### Amazon SQS へのアクセスを提供する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを作成します。 | この IAM ロールは、API Gateway リソースに Amazon SQS へのフルアクセスを付与します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者、AWS 管理者 | ### REST API を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | REST API を作成する | これは、HTTP リクエストが送信される REST API です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | API Gateway を Amazon SQS に接続します。 | このステップにより、メッセージが HTTP リクエストの本文内から Amazon SQS に流れるようになります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### REST API をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | REST API をテストします。 | 不足している設定がないかをチェックするテストを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | API 統合を変更して、リクエストを Amazon SQS に適切に転送します。 | 統合エラーを修正するには、設定を完了します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | Amazon SQS でメッセージをテストして検証します。 | テストを実行し、テストが正常に完了したことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | 特殊文字を使用して API Gateway をテストします。 | メッセージでは許容されない特殊文字 (& など) を含むテストを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)This is because special characters aren't supported by default in the message body. 次のステップでは、特殊文字をサポートするように API Gateway を設定します。コンテンツタイプの変換の詳細については、「[API Gateway ドキュメント](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html)」を参照してください。 | アプリ開発者 | | 特殊文字をサポートするように API 設定を変更します。 | メッセージ内の特殊文字を許容するように設定を調整します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)新しいメッセージには特殊文字を含める必要があります。 | アプリ開発者 | ### REST API をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API をデプロイします。 | REST API をデプロイするには、以下を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | | 外部ツールを使用してテストします。 | 外部ツールを使用してテストを実行し、メッセージが正常に受信されたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | アプリ開発者 | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API を削除します。 | [API Gateway コンソール](https://console.aws.amazon.com/apigateway/)で、作成した API を選択し、**[削除]** を選択します。 | アプリ開発者 | | IAM ロールを削除します。 | [IAM コンソール](https://console.aws.amazon.com/iam/)の **[ロール]** ペインで、**AWSGatewayRoleForSQS** を選択し、**[削除]** を選択します。 | アプリ開発者 | | SQS キューを削除します。 | [Amazon SQS コンソール](https://console.aws.amazon.com/sqs/)の **[キュー]** ペインで、作成した SQS キューを選択し、**[削除]** を選択します。 | アプリ開発者 | ## 関連リソース + [SQS-SendMessage](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services-reference.html#SQS-SendMessage) (API Gateway ドキュメント) + [API Gateway でのコンテンツタイプの変換](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html) (API Gateway ドキュメント) + [\$1util 変数](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#util-template-reference) (API Gateway ドキュメント) + [API Gateway REST API を Amazon SQS と統合して一般的なエラーを解決する方法 (](https://repost.aws/knowledge-center/api-gateway-rest-api-sqs-errors)AWS re:Post 記事) # Amazon API Gateway と AWS Lambda を使用してイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Marime Kthiri、Nadim Majed、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway と を使用してイベントを非同期的に処理するアーキテクチャの例を示しています AWS Lambda。このアーキテクチャは、最大 15 分間の処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし、[AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) AWS アカウント、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-tools)」セクションをご確認ください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) ツールキット](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)バージョン 2.85.0 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 + [Node.js](https://nodejs.org/en/download/) バージョン 18.13.0 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 **制限事項** + ジョブの最大ランタイムは、Lambda 関数の最大ランタイム (15 分) によって制限されます。 + 同時ジョブリクエストの最大数は、Lambda 関数の予約済み同時実行数によって制限されます。 ## アーキテクチャ 次の図は、イベント処理およびエラー処理 Lambda 関数と Amazon EventBridge イベントアーカイブに保存されたイベントとのジョブ API の相互作用を示しています。 ![\[AWS クラウド architecture showing user interaction with jobs API, Lambda functions, and EventBridge.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e027130c-44c1-41ab-bbe9-f196a49bd9ac/images/3c437b65-48e3-477d-aeea-6ff938cc3285.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. API Gateway REST API であるジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、イベント処理 Lambda 関数を非同期的に呼び出します。 1. イベント処理関数はイベントを処理し、ジョブ結果を Amazon DynamoDB テーブルに置きます。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、イベント処理関数はイベントをエラー処理関数に送信します。 1. エラー処理関数は、DynamoDB `jobs` テーブルにジョブパラメータを置きます。 1. ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを EventBridge イベントアーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを通じて AWS のサービスを操作するのに役立つオープンソースツールです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」 は、アプリケーションをさまざまなソースのデータに接続するために支援するサーバーレスイベントバスサービスです。例えば、Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、その他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **その他のツール** + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Event Processing with API Gateway and Lambda](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk) リポジトリにあります。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + Amazon API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。追加の入力検証とセキュリティレベルの向上が必要なユースケースの場合は、[AWS WAF を使用した API 保護](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)を評価します。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-lambda-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | AWS CDK でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)に対応していることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | deploy コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API に[リクエストを送信](https://learning.postman.com/docs/sending-requests/requests/#next-steps)します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [バックエンド Lambda 関数の非同期呼び出しを設定する](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-integration-async.html) # Amazon API Gateway と Amazon DynamoDB Streams を使用してイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Mariem Kthiri、Nadim Majed、Alessandro Trisolini、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway、Amazon DynamoDB Streams、および を使用してイベントを非同期的に処理するためのアーキテクチャの例を示しています AWS Lambda。このアーキテクチャは、同じ入力パラメータを使用した並列処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。この例では、Lambda をバックエンドとして使用すると、ジョブの期間は 15 分に制限されます。この制限を回避するには、代替サービスを使用して受信イベント (例:) を処理します AWS Fargate。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし AWS アカウント、[AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-tools)」セクションをご確認ください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) バージョン 2.85.0 以降 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 以降 + [Node.js](https://nodejs.org/en/download/) バージョン 18 以降 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 以降 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 以降 **制限事項** + スロットリングを避けるため、DynamoDB Streams の推奨最大リーダー数は 2 です。 + ジョブの最大ランタイムは、Lambda 関数の最大ランタイム (15 分) によって制限されます。 + 同時ジョブリクエストの最大数は、Lambda 関数の予約済み同時実行数によって制限されます。 ## アーキテクチャ **アーキテクチャ** 次の図は、Amazon EventBridge イベントアーカイブに保存されたイベントと、DynamoDB Streams およびイベント処理とエラー処理の Lambda 関数とのジョブ API の相互作用を示しています。 ![\[アーキテクチャとプロセスの図 (図の後にステップがリストされています)。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/68a46501-16e5-48e4-99c6-fc67a8b4133a/images/29fe6982-ad81-4099-9c65-08b17c96e78f.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. ジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、ジョブパラメータを `jobs_table` Amazon DynamoDB テーブルに置きます。 1. `jobs_table` DynamoDB テーブルの DynamoDB ストリームは、イベント処理 Lambda 関数を呼び出します。 1. イベント処理 Lambda 関数はイベントを処理し、ジョブ結果を DynamoDB `jobs_table` テーブルに置きします。一貫した結果を確保するために、イベント処理関数は[楽観的ロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)メカニズムを実装します。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs_table` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、イベント処理関数のソースマッピングは、エラー処理を行う Amazon Simple Notification Service (Amazon SNS) トピックにイベントを送信します。 1. エラー処理 SNS トピックは、イベントをエラー処理関数に非同期的にプッシュします。 1. エラー処理関数は、DynamoDB `jobs_table` テーブルにジョブパラメータを置きます。 ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを Amazon EventBridge アーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義して割り当てるのに役立つソフトウェア開発フレームワークです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」 は、アプリケーションをさまざまなソースのデータに接続するために支援するサーバーレスイベントバスサービスです。たとえば、AWS Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、または他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 **その他のツール** + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Processing with API Gateway and DynamoDB Streams](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk) リポジトリから取得できます。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。ユースケースで追加の入力検証とセキュリティレベルの向上が必要な場合は、 [AWS WAF を使用して API を保護します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 + スロットリングを避けるために、[DynamoDB Streams ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.Processing)では、ユーザーが同じストリームのシャードから 3 つ以上のコンシューマーで読み取ることを推奨していません。コンシューマーの数をスケールアウトするため、[Amazon Kinesis Data Streams ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)を使用することをお勧めします。 + この例では、DynamoDB `jobs_table` テーブル内の項目の一貫した更新を確保するために、[楽観的ロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)が使用されています。ユースケースの要件によっては、悲観的ロックなど、より信頼性の高いロックメカニズムを実装する必要がある場合があります。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-dynamodb-streams-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | [AWS CDK](https://aws.amazon.com/cdk/) でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)をサポートしていることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | `deploy` コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API にリクエストを送信します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [DynamoDB Streams のデータキャプチャを変更する](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) + [バージョン番号によるオプティミスティックロック](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html) + [Kinesis Data Streams を使用して DynamoDB への変更をキャプチャする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html) # Amazon API Gateway、Amazon SQS、および AWS Fargate でイベントを非同期的に処理する *Amazon Web Services、Andrea Meroni、Mariem Kthiri、Nadim Majed、Alessandro Trisolini、Michael Wallner* ## 概要 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、開発者が API を作成、配布、保守、監視、保護するために規模に関係なく使用できるフルマネージドサービスです。最大で数十万個の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。 API Gateway の重要なサービスクォータは、統合タイムアウトです。このタイムアウトは、バックエンドサービスがレスポンスを返さなければならない最大時間で、その後は REST API がエラーを返します。29 秒のハードリミットは、同期ワークロードでは一般的に許容されます。ただし、この制限は、非同期ワークロードで API Gateway を使用するデベロッパーにとっての課題です。 このパターンは、API Gateway、Amazon Simple Queue Service (Amazon SQS)、および を使用してイベントを非同期的に処理するアーキテクチャの例を示しています AWS Fargate。このアーキテクチャは、期間制限なしでの処理ジョブの実行をサポートし、インターフェイスとして基本的な REST API を使用します。 [Projen](https://pypi.org/project/projen/) は、ローカル開発環境をセットアップし AWS アカウント、[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)、[Docker](https://docs.docker.com/get-docker/)、[Node.js](https://nodejs.org/en/download/) と組み合わせてサンプルアーキテクチャをターゲットにデプロイするために使用されます。Projen は、[事前コミット](https://pre-commit.com/)と、コードの品質保証、セキュリティスキャン、ユニットテストに使用されるツールを使用して、[Python](https://www.python.org/downloads/) 仮想環境を自動でセットアップします。詳しくは「[ツール](#process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-tools)」セクションをご確認ください。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + ワークステーションにインストールされている以下のツール: + [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) バージョン 2.85.0 以降 + [Docker](https://docs.docker.com/get-docker/) バージョン 20.10.21 以降 + [Node.js](https://nodejs.org/en/download/) バージョン 18 以降 + [Projen](https://pypi.org/project/projen/) バージョン 0.71.111 以降 + [Python](https://www.python.org/downloads/) バージョン 3.9.16 以降 **制限事項** + 同時ジョブは 1 分あたり 500 タスクに制限されます。これは、Fargate がプロビジョニングできるタスクの最大数です。 ## アーキテクチャ 次の図は、ジョブ API と `jobs` Amazon DynamoDB テーブル、イベント処理 Fargate サービス、およびエラー処理 AWS Lambda 関数とのやり取りを示しています。イベントは Amazon EventBridge イベントアーカイブに保存されます。 ![\[図に続く説明を含むアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8a03149c-8f34-4593-84d5-accc1800a0a2/images/5e1071aa-4fbc-495c-bc22-8e62a32a136b.png) 一般的なワークフローには、以下のステップが含まれます。 1. AWS Identity and Access Management (IAM) に対して認証し、セキュリティ認証情報を取得します。 1. HTTP `POST` リクエストを `/jobs` ジョブ API エンドポイントに送信し、リクエスト本文のジョブパラメータを指定します。 1. API Gateway REST API であるジョブ API は、ジョブ識別子を含む HTTP レスポンスを返します。 1. ジョブ API は、SQS キューにメッセージを送信します。 1. Fargate は SQS キューからメッセージをプルし、イベントを処理し、ジョブ結果を `jobs` DynamoDB テーブルに置きます。 1. ステップ 3 の `/jobs/{jobId}` ジョブ識別子を `{jobId}` として、ジョブ API エンドポイントに HTTP `GET` リクエストを送信します。 1. ジョブ API は DynamoDB `jobs` テーブルにクエリを実行してジョブ結果を取得します。 1. ジョブ API は、ジョブ結果を含む HTTP レスポンスを返します。 1. イベント処理が失敗した場合、SQS キューはイベントをデッドレターキュー (DLQ) に送信します。 1. EventBridge イベントはエラー処理関数を開始します。 1. エラー処理関数は、DynamoDB `jobs` テーブルにジョブパラメータを置きます。 1. ジョブ API エンドポイントに HTTP `GET` リクエストを送信することで、`/jobs/{jobId}` ジョブパラメータを取得できます。 1. エラー処理が失敗した場合、エラー処理関数はイベントを EventBridge アーカイブに送信します。 EventBridge を使用して、アーカイブされたイベントを再生できます。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) を使用すると、サーバーや Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理する必要なくコンテナを実行できます。Amazon Elastic Container Service (Amazon ECS) と組み合わせて使用されます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、その他の AWS アカウントのイベントバスなどです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) 」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。 その他のツール + [autopep8](https://github.com/hhatto/autopep8) は、Python Enhancement Proposal (PEP) 8 スタイルガイドに基づいて自動的に Python コードをフォーマットします。 + [Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードをスキャンして、一般的なセキュリティ問題を見つけます。 + [Commitizen](https://commitizen-tools.github.io/commitizen/) は Git コミットチェッカーと `CHANGELOG` ジェネレーターです。 + [cfn-lint](https://github.com/aws-cloudformation/cfn-lint) は linter AWS CloudFormation です + [Checkov](https://github.com/bridgecrewio/checkov) は、Infrastructure as Code (IaC) のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [jq](https://stedolan.github.io/jq/download/) は JSON を構文解析するコマンドラインツールです。 + [Postman](https://www.postman.com/) は API プラットフォームです。 + [事前コミット](https://pre-commit.com/)は Git フックマネージャーです。 + [Projen](https://github.com/projen/projen) はプロジェクトジェネレーターです。 + 「[pytest](https://docs.pytest.org/en/7.2.x/index.html)」は、小さくて読みやすいテストを書くための Python フレームワークです。 **コードリポジトリ** このアーキテクチャコードの例は、GitHub [Asynchronous Processing with API Gateway and SQS](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-sqs-cdk) リポジトリにあります。 ## ベストプラクティス + この例のアーキテクチャには、デプロイされたインフラストラクチャのモニタリングは含まれません。モニタリングが必要なユースケースの場合は、[CDK モニタリングコンストラクト](https://constructs.dev/packages/cdk-monitoring-constructs)または別のモニタリングソリューションの追加を評価します。 + このアーキテクチャ例では、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して、ジョブ API へのアクセスを制御します。`JobsAPIInvokeRole` を引き受ける権限を持つユーザーは、ジョブ API を呼び出すことができます。そのため、アクセスコントロールメカニズムはバイナリです。より複雑な認可モデルが必要なユースケースの場合は、別の[アクセスコントロールメカニズム](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)の使用を評価します。 + ユーザーが `/jobs` ジョブ API エンドポイントに HTTP `POST` リクエストを送信すると、入力データは 2 つの異なるレベルで検証されます。 + API Gateway は、最初の[リクエスト検証](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)を担当します。 + イベント処理関数は、2 番目のリクエストを実行します。 ユーザーが `/jobs/{jobId}` ジョブ API エンドポイントに対して HTTP `GET` リクエストを実行する場合、検証は実行されません。ユースケースで追加の入力検証とセキュリティレベルの向上が必要な場合は、 [AWS WAF を使用して API を保護します](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | リポジトリをローカルに複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-sqs-cdk.git
| DevOps エンジニア | | プロジェクトを設定します。 | ディレクトリをリポジトリルートに変更し、[Projen](https://github.com/projen/projen) を使用して Python 仮想環境とすべてのツールを設定します。
cd asynchronous-event-processing-api-gateway-api-gateway-sqs-cdk
npx projen
| DevOps エンジニア | | 事前コミットフックをインストールします。 | 事前コミットフックをインストールするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | DevOps エンジニア | ### サンプルアーキテクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブートストラップ AWS CDK。 | [AWS CDK](https://aws.amazon.com/cdk/) でブートストラップするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap
| AWS DevOps | | サンプルアーキテクチャをデプロイします。 | にサンプルアーキテクチャをデプロイするには AWS アカウント、次のコマンドを実行します。
AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy
| AWS DevOps | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストの前提条件をインストールします。 | [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[Postman](https://www.postman.com/downloads/)、[jq](https://jqlang.github.io/jq/) をワークステーションにインストールします。[Postman](https://www.postman.com/downloads/) を使用してこのサンプルアーキテクチャをテストすることをお勧めしますが、必須ではありません。代替の API テストツールを選択する場合は、[AWS 署名バージョン 4 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)に対応していることを確認し、また、[REST API をエクスポート](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html)して検査できる公開 API エンドポイントを参照してください。 | DevOps エンジニア | | `JobsAPIInvokeRole` を引き受けます。 | `deploy` コマンドから出力された `JobsAPIInvokeRole` を[引き受け](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)ます。
CREDENTIALS=$(AWS_PROFILE=$ aws sts assume-role \
--no-cli-pager \
--role-arn $ \
--role-session-name JobsAPIInvoke)
export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)
export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)
| AWS DevOps | | Postman を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | AWS DevOps | | サンプルアーキテクチャをテストします。 | サンプルアーキテクチャをテストするには、ジョブ API にリクエストを送信します。詳細については、[Postman ドキュメント](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)を参照してください。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | [Amazon CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | | [CloudWatch Logs ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/ecs/EventProcessingServiceLogs` が既に存在するため、サンプルアーキテクチャの破壊とその後の再デプロイは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | ## 関連リソース + [API Gateway マッピングテンプレートとアクセスロギング変数リファレンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) + [一般的なエラーを解決するために、API Gateway REST API を Amazon SQS と統合する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-rest-api-sqs-errors/) # AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する *Elie El khoury、Amazon Web Services* ## 概要 このパターンでは、 AWS Step Functions と を統合する方法について説明します AWS Systems Manager。 AWS SDK サービス統合を使用して、ステートマシンワークフローからタスクトークンで Systems Manager **startAutomationExecution** API を呼び出し、トークンが成功または失敗の呼び出しで戻るまで一時停止します。この統合の例を示すために、このパターンはオートメーションドキュメント (ランブック) ラッパーを `AWS-RunShellScript` または `AWS-RunPowerShellScript` ドキュメントの周囲に実装し、`.waitForTaskToken` を使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` を同期的に呼び出します。Step Functions での AWS SDK サービス統合の詳細については、「 [AWS Step Functions デベロッパーガイド](https://docs.aws.amazon.com/step-functions/latest/dg/supported-services-awssdk.html)」を参照してください。 Step Functions ****は、分散アプリケーションの構築、IT およびビジネスプロセスの自動化、サービスを使用したデータおよび機械学習パイプラインの構築に使用できる、ローコードのビジュアルワークフロー AWS サービスです。ワークフローは失敗、再試行、並列化、サービス統合、オブザーバビリティを管理するので、より価値の高いビジネスロジックに集中できます。 の一機能であるオートメーションは AWS Systems Manager、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon Simple Storage Service (Amazon S3) AWS のサービス などの の一般的なメンテナンス、デプロイ、修復タスクを簡素化します。Amazon S3 オートメーションを使用すると、自動化の同時実行性をきめ細かく制御できます。例えば、同時実行のターゲットにするリソースの数や、オートメーションを停止する前に許容可能なエラーの発生数を指定することが可能です。 ランブックのステップ、パラメータ、例など、実装の詳細については、「[追加情報](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional)」セクションを参照してください。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + AWS Identity and Access Management Step Functions と Systems Manager にアクセスするための (IAM) アクセス許可 + Systems Manager Agent (SSM Agent) が[インストールされた](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html) EC2 インスタンス + ランブックを実行する予定のインスタンスにアタッチされた [Systems Manager の IAM インスタンスプロファイル](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) + 以下の IAM 権限を持つ Step Functions ロール (最小特権の原則に従う): ``` { "Effect": "Allow", "Action": "ssm:StartAutomationExecution", "Resource": "*" } ``` **製品バージョン** + SSM ドキュメントスキーマバージョン 0.3 以降 + SSM エージェントバージョン 2.3.672.0 以降。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Step Functions + AWS Systems Manager Automation **ターゲットアーキテクチャ** ![\[Systems Manager 自動化タスクを Step Functions から同期的に実行するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/47c19e4f-d68d-4f91-bb68-202098757529/images/2d248aae-d858-4565-8af2-593cde0da780.png) **自動化とスケール** + このパターンは、ランブックを複数のインスタンスにデプロイするために使用できる AWS CloudFormation テンプレートを提供します。(GitHub [Step Functions and Systems Manager implementation](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken) を参照してください)。 ## ツール **AWS のサービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 **コード** このパターンのコードは、GitHub 内の「[Step Functions and Systems Manager implementation](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken)」リポジトリで利用できます。  ## エピック ### ランブックの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートをダウンロードします。 | GitHub リポジトリの `cloudformation ` フォルダから `ssm-automation-documents.cfn.json` テンプレートをダウンロードします。 | AWS DevOps | | ランブックを作成します。 | にサインインし AWS マネジメントコンソール、[CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開き、テンプレートをデプロイします。CloudFormation テンプレートのデプロイの詳細については、CloudFormation ドキュメントの[CloudFormation 「コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。 CloudFormation  CloudFormation テンプレートは 3 つのリソースをデプロイします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.html) | AWS DevOps | ### サンプルステートマシンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストステートマシンを作成します。 | [AWS Step Functions デベロッパーガイド](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html)の手順に従って、ステートマシンを作成して実行します。定義には、次のコードを使用してください。必ず、アカウント内の有効な Systems Manager 対応インスタンスの ID で `InstanceIds` 値を更新してください。
{
  "Comment": "A description of my state machine",
  "StartAt": "StartAutomationWaitForCallBack",
  "States": {
    "StartAutomationWaitForCallBack": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
      "Parameters": {
        "DocumentName": "SfnRunCommandByInstanceIds",
        "Parameters": {
          "InstanceIds": [
            "i-1234567890abcdef0"
          ],
          "taskToken.$": "States.Array($$.Task.Token)",
          "workingDirectory": [
            "/home/ssm-user/"
          ],
          "Commands": [
            "echo \"This is a test running automation waitForTaskToken\" >> automation.log",
            "sleep 100"
          ],
          "executionTimeout": [
              "10800"
          ],
          "deliveryTimeout": [
              "30"
          ],
          "shell": [
              "Shell"
          ]
            }
      },
      "End": true
    }
  }
}
このコードはランブックを呼び出して、Systems Manager Automation への `waitForTaskToken` 呼び出しを示す 2 つのコマンドを実行します。`shell` パラメータ値 (`Shell` または `PowerShell`) は、オートメーションドキュメントが `AWS-RunShellScript` または `AWS-RunPowerShellScript` を実行するかどうかを決定します。タスクは `/home/ssm-user/automation.log` ファイルに「これはテスト実行オートメーションの WaitForTaskToken」と書き込み、100 秒間スリープしてからタスクトークンが返され、ワークフロー内の次のタスクがリリースされます。代わりに `SfnRunCommandByTargets` ランブックを呼び出したい場合は、前のコードの `Parameters` セクションを以下のコードに置き換えてください。
"Parameters": {
          "Targets": [
            {
              "Key": "InstanceIds",
              "Values": [
                "i-02573cafcfEXAMPLE",
                "i-0471e04240EXAMPLE"
              ]
            }
          ],
| AWS DevOps | | ステートマシンの IAM ロールを更新します。 | 前のステップでは、ステートマシンの専用の IAM ロールが自動的に作成されます。ただし、ランブックを呼び出すアクセス許可は付与されません。以下のアクセス許可を追加して、ロールを更新します。
{
      "Effect": "Allow",
      "Action": "ssm:StartAutomationExecution",
      "Resource": "*"
 }
| AWS DevOps | | 同期呼び出しを検証します。 | ステートマシンを実行して、Step Functions と Systems Manager オートメーション間の同期呼び出しを検証します。 出力例については、「[追加情報](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional)」セクションを参照してください。  | AWS DevOps | ## 関連リソース + [の開始方法 AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html) (*AWS Step Functions デベロッパーガイド*) + [タスクトークンを使用してコールバックを待機する](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token) (*AWS Step Functions デベロッパーガイド*、サービス統合パターン) + [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) と [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) の API コール (Boto3 ドキュメント)  + [AWS Systems Manager 自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) (*AWS Systems Manager ユーザーガイド*) ## 追加情報 **実装の詳細** このパターンは、2 つの Systems Manager ランブックをデプロイする CloudFormation テンプレートを提供します。 + `SfnRunCommandByInstanceIds` は、インスタンス ID を使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` コマンドを実行します。 + `SfnRunCommandByTargets` は、ターゲットを使用して `AWS-RunShellScript` または `AWS-RunPowerShellScript` コマンドを実行します。 各ランブックには、Step Functions の `.waitForTaskToken` オプションを使用する際に同期呼び出しを実現するための 4 つのステップが実装されています。 | | | [ステップ] | [アクション] | 説明 | | --- |--- |--- | | **1** | `Branch` | `shell` パラメータ値 (`Shell` または `PowerShell`) をチェックして、Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定します。 | | **2** | `RunCommand_Shell`、または `RunCommand_PowerShell` | 複数の入力を受け取り、`RunShellScript` または `RunPowerShellScript` コマンドを実行します。詳細については、Systems Manager コンソールの `RunCommand_Shell` または `RunCommand_PowerShell` オートメーションドキュメントの **[詳細]** タブを確認してください。 | | **3** | `SendTaskFailure` | ステップ 2 が中止またはキャンセルされたときに実行されます。Step Functions [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) API を呼び出し、ステートマシンから渡されたトークン、障害エラー、障害の原因の説明の 3 つのパラメータを入力として受け入れます。 | | **4** | `SendTaskSuccess` | ステップ 2 が成功すると実行されます。ステートマシンから渡されたトークンを入力として受け入れる Step Functions [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) API を呼び出します。 | **ランブックパラメータ** `SfnRunCommandByInstanceIds` ランブック: | | | パラメータ名 | タイプ | オプションまたは必須 | 説明 | | --- |--- |--- |--- | | `shell` | 文字列 | 必須 | Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定するインスタンスシェル。 | | `deliveryTimeout` | 整数 | オプションです。 | インスタンスの SSM Agent にコマンドが配信されるまで待機する時間 (秒単位)。このパラメータの最小値は 30 (0.5 分)、最大値は 2,592,000 (720 時間) です。 | | `executionTimeout` | String | オプションです。 | コマンドが失敗したと見なされるまでに完了するまでの時間 (秒単位)。デフォルト値は 3,600 (1 時間) です。最大値は 172800 (48 時間) です。 | | `workingDirectory` | String | オプションです。 | インスタンスの作業ディレクトリへのパス。 | | `Commands` | StringList | 必須 | 実行するシェルスクリプトまたはコマンド。 | | `InstanceIds` | StringList | 必須 | コマンドを実行するインスタンス ID です。 | | `taskToken` | String | 必須 | コールバックレスポンスに使用するタスクトークン。 | `SfnRunCommandByTargets` ランブック: | | | 名前 | 型 | オプションまたは必須 | 説明 | | --- |--- |--- |--- | | `shell` | 文字列 | 必須 | Linux で `AWS-RunShellScript` を実行するか Windows で `AWS-RunPowerShellScript` を実行するかを決定するインスタンスシェル。 | | `deliveryTimeout` | 整数 | オプションです。 | インスタンスの SSM Agent にコマンドが配信されるまで待機する時間 (秒単位)。このパラメータの最小値は 30 (0.5 分)、最大値は 2,592,000 (720 時間) です。 | | `executionTimeout` | 整数 | オプションです。 | コマンドが失敗したと見なされるまでに完了するまでの時間 (秒単位)。デフォルト値は 3,600 (1 時間) です。最大値は 172800 (48 時間) です。 | | `workingDirectory` | String | オプションです。 | インスタンスの作業ディレクトリへのパス。 | | `Commands` | StringList | 必須 | 実行するシェルスクリプトまたはコマンド。 | | `Targets` | MapList | 必須 | 指定したキーと値のペアを使用してインスタンスを識別する検索条件の配列。例: `[{"Key":"InstanceIds","Values":["i-02573cafcfEXAMPLE","i-0471e04240EXAMPLE"]}]` | | `taskToken` | String | 必須 | コールバックレスポンスに使用するタスクトークン。 | **出力例** 次の表に、ステップ関数からの出力例を示します。ステップ 5 (`TaskSubmitted`) からステップ 6 (`TaskSucceeded`) までの合計実行時間が 100 秒を超えていることがわかります。これは、step 関数が `sleep 100` コマンドが終了するのを待ってから、ワークフロー内の次のタスクに移ったことを示しています。 | | | ID | タイプ | [ステップ] | [リソース] | 経過時間 (ミリ秒) | タイムスタンプ | | --- |--- |--- |--- |--- |--- | | ** 1** | `ExecutionStarted` | | - | 0 | 2022 年 3 月 11 日午後 2 時 50 分 34.303 秒 | | ** 2** | `TaskStateEntered` | `StartAutomationWaitForCallBack` | - | 40 | 2022 年 3 月 11 日午後 2 時 50 分 34.343 秒 | | ** 3** | `TaskScheduled` | `StartAutomationWaitForCallBack` | - | 40 | 2022 年 3 月 11 日午後 2 時 50 分 34.343 秒 | | ** 4** | `TaskStarted` | `StartAutomationWaitForCallBack` | - | 154 | 2022 年 3 月 11 日午後 2 時 50 分 34.457 秒 | | ** 5** | `TaskSubmitted` | `StartAutomationWaitForCallBack` | - | 657 | 2022 年 3 月 11 日午後 2 時 50 分 34.960 秒 | | ** 6** | `TaskSucceeded` | `StartAutomationWaitForCallBack` | - | 103835 | 2022 年 3 月 11 日午後 2 時 52 分 18.138 秒 | | ** 7** | `TaskStateExited` | `StartAutomationWaitForCallBack` | - | 103860 | 2022 年 3 月 11 日午後 2 時 52 分 18.163 秒 | | ** 8** | `ExecutionSucceeded` | | - | 103897 | 2022 年 3 月 11 日午後 2 時 52 分 18.200 秒 | # AWS Lambda 関数で Python を使用して S3 オブジェクトの並列読み取りを実行する *Eduardo Bortoluzzi、Amazon Web Services* ## 概要 このパターンを使用して、Amazon Simple Storage Service (Amazon S3) バケットからドキュメントのリストをリアルタイムで取得して要約できます。このパターンは、Amazon Web Services (AWS) の S3 バケットからオブジェクトを並列に読み取るためのサンプルコードを提供します。このパターンは、Python を使用して AWS Lambda 関数で I/O バインドタスクを効率的に実行する方法を示しています。 ある金融会社は、このパターンをインタラクティブなソリューションで使用して、相関する金融取引をリアルタイムで手動で承認または拒否しました。金融取引ドキュメントを市場に関連する S3 バケットに保存しました。オペレーターは S3 バケットからドキュメントのリストを選択し、ソリューションが計算した取引の合計値を分析して、選択したバッチを承認または拒否することを決定しました。 I/O にバインドされたタスクは複数のスレッドをサポートします。このサンプルコードでは、Lambda 関数が最大 1,024 スレッドをサポートしている場合でも、[concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3.13/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor) は最大 30 の同時スレッドで使用されます (これらのスレッドの 1 つがメインプロセスです)。この制限があるのは、スレッドが多すぎると、コンテキストの切り替えとコンピューティングリソースの使用率が原因でレイテンシーの問題が発生するためです。また、すべてのスレッドが S3 オブジェクトのダウンロードを同時に実行できるように、`botocore` でプールの最大接続数を増やす必要があります。 サンプルコードは、S3 バケット内で JSON データとともに 8.3 KB オブジェクトを 1 つ使用します。オブジェクトは複数回読み込まれます。Lambda 関数がオブジェクトを読み取ると、JSON データは Python オブジェクトにデコードされます。2024 年 12 月、この例を実行した後の結果は、2,304 MB のメモリで設定された Lambda 関数を使用して 2.3 秒で 1,000 回の読み込みを処理し、27 秒で 10,000 回の読み込みを処理しました。 は、128 MB から 10,240 MB (10 GB) のメモリ設定 AWS Lambda をサポートしますが、Lambdamemory を 2,304 MB を超えて増やすと、この特定の I/O バウンドタスクの実行時間を短縮することはできませんでした。 [AWS Lambda Power Tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning) ツールを使用して、さまざまな Lambda メモリ設定をテストし、タスクの最適な費用対効果の比率を検証しました。詳細については、「[追加リソース](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-additional)」のセクションを参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Python 開発の習熟度 **制限事項** + Lambda 関数は、最大 [1,024 の実行プロセスまたはスレッド](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution)を持つことができます。 + 新しい AWS アカウント の Lambda メモリ制限は 3,008 MB です。それに応じて AWS Lambda Power Tuning ツールを調整します。詳細については、「[トラブルシューティング](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-troubleshooting)」セクションを参照してください。 + Amazon S3 には、[パーティション化されたプレフィックスごとに 1 秒あたり 5,500 件の GET/HEAD リクエスト](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)の制限があります。 **製品バージョン** + Python 3.9 以降 + AWS Cloud Development Kit (AWS CDK) v2 + AWS Command Line Interface (AWS CLI) バージョン 2 + AWS Lambda Power Tuning 4.3.6 (オプション) ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Lambda + Amazon S3 + AWS Step Functions ( AWS Lambda Power Tuning がデプロイされている場合) **ターゲットアーキテクチャ** 次の図は、S3 バケットからオブジェクトを並行して読み取る Lambda 関数を示しています。この図には、Lambda 関数メモリを微調整するための AWS Lambda Power Tuning ツール用の Step Functions ワークフローもあります。このファインチューニングは、コストとパフォーマンスのバランスをとるのに役立ちます。 ![\[Lambda 関数、S3 バケット、AWS Step Functions を示す図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/828696e2-6df7-4536-9205-951c99449f4e.png) **自動化とスケール** Lambda 関数は、必要に応じて迅速にスケールします。需要が高いときに Amazon S3 から 503 Slow Down エラーを受信しないように、スケーリングにいくつかの制限を設定することをお勧めします。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK) v2](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) は、コードで AWS クラウド インフラストラクチャを定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。デプロイするインフラストラクチャの例が作成されました AWS CDK。 + [AWS Command Line InterfaceAWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。このパターンでは、 AWS CLI バージョン 2 を使用してサンプル JSON ファイルをアップロードします。 + [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) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数と他の AWS のサービスを組み合わせてビジネスクリティカルなアプリケーションを構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。[アイドルワーカースレッドの再利用](https://docs.python.org/3.8/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor)は Python バージョン 3.8 で導入され、このパターンの Lambda 関数コードは Python バージョン 3.9 以降用に作成されました。 **コードリポジトリ** このパターンのコードは、「[aws-lambda-parallel-download](https://github.com/aws-samples/aws-lambda-parallel-download)」GitHub リポジトリで利用できます。 ## ベストプラクティス + この AWS CDK コンストラクトは、インフラストラクチャをデプロイするための AWS アカウントユーザーのアクセス許可に依存します。 AWS CDK Pipelines またはクロスアカウントデプロイを使用する場合は、[「スタックシンセサイザー](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-synthesizers)」を参照してください。 + このサンプルアプリケーションでは、S3 バケットでアクセスログが有効になっていません。本番コードでアクセスログを有効にするのがベストプラクティスです。 ## エピック ### 開発環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Python がインストールされているバージョンを確認します。 | このコードは Python 3.9 と Python 3.13 で特別にテストされており、これらのリリース間のすべてのバージョンで動作するはずです。Python のバージョンを確認するには、ターミナルで `python3 -V` を実行し、必要に応じて新しいバージョンをインストールします。必要なモジュールがインストールされていることを確認するには、`python3 -c "import pip, venv"` を実行します。エラーメッセージが表示されない場合は、モジュールが正しくインストールされ、このサンプルを実行する準備ができていることを意味します。 | クラウドアーキテクト | | をインストールします AWS CDK。 | まだインストール AWS CDK されていない場合は、[「 の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)」の手順に従ってください。インストールされている AWS CDK バージョンが 2.0 以降であることを確認するには、 を実行します`cdk –version`。 | クラウドアーキテクト | | 環境 をブートストラップします。 | まだブートストラップされていない場合、環境をブートストラップするには、「[AWS CDKで使用する環境をブートストラップする](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html)」の手順に従ってください。 | クラウドアーキテクト | ### サンプルリポジトリのクローンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 最新バージョンのリポジトリのクローンを作成するには、次のコマンドを実行します。
git clone --depth 1 --branch v1.2.0 \
git@github.com:aws-samples/aws-lambda-parallel-download.git
| クラウドアーキテクト | | 作業ディレクトリをクローニングされたリポジトリに変更します。 | 次のコマンドを実行します。
cd aws-lambda-parallel-download
| クラウドアーキテクト | | Python 仮想環境を作成します。 | Python 仮想環境を作成するには、次のコマンドを実行します。
python3 -m venv .venv
| クラウドアーキテクト | | 仮想環境をアクティブ化します。 | 仮想環境を有効にするには、次のコマンドを実行します。
source .venv/bin/activate
| クラウドアーキテクト | | SDK の依存関係をインストールします。 | Python 依存関係をインストールするには、`pip` コマンドを実行します。
pip install -r requirements.txt
| クラウドアーキテクト | | コードを参照します。 | (オプション) S3 バケットからオブジェクトをダウンロードするサンプルコードは、`resources/parallel.py` にあります。インフラストラクチャコードは `parallel_download` フォルダにあります。 | クラウドアーキテクト | ### アプリをデプロイしてテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションをデプロイします。 | `cdk deploy` を実行します。 AWS CDK 出力を書き留めます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | クラウドアーキテクト | | サンプル JSON ファイルをアップロードします。 | リポジトリには、約 9 KB のサンプル JSON ファイルが含まれています。作成したスタックの S3 バケットにファイルをアップロードするには、次のコマンドを実行します。
aws s3 cp sample.json s3://
を AWS CDK 出力の対応する値``に置き換えます。 | クラウドアーキテクト | | アプリを実行します。 | アプリを実行するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | クラウドアーキテクト | | ダウンロード数を追加します。 | (オプション) 1,500 の GET オブジェクト呼び出しを実行するには、`Test` パラメータの**イベント JSON** で次の JSON を使用します。
{"repeat": 1500, "objectKey": "sample.json"}
| クラウドアーキテクト | ### オプション: AWS Lambda 電源調整を実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Lambda Power Tuning ツールを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html)実行の最後に、**[実行の入力と出力]** タブに結果が表示されます。 | クラウドアーキテクト | | AWS Lambda パワーチューニングの結果をグラフで表示します。 | **[実行の入力と出力]** タブで、`visualization` プロパティリンクをコピーし、新しいブラウザタブに貼り付けます。 | クラウドアーキテクト | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットからオブジェクトを削除します。 | デプロイされたリソースを破棄する前に、S3 バケットからすべてのオブジェクトを削除します。
aws s3 rm s3:// \
--recursive
を AWS CDK 出力の値``に置き換えることを忘れないでください。 | クラウドアーキテクト | | リソースを破棄します。 | このパイロット用に作成されたすべてのリソースを破棄するには、次のコマンドを実行します。
cdk destroy
| クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `'MemorySize' value failed to satisfy constraint: Member must have value less than or equal to 3008` | 新しいアカウントでは、Lambda 関数で 3,008 MB 以上を設定できない場合があります。 AWS Lambda Power Tuning を使用してテストするには、Step Functions の実行を開始するときに、入力 JSON に次のプロパティを追加します。
"powerValues": [
    512,
    1024,
    1536,
    2048,
    2560,
    3008
  ]
| ## 関連リソース + [Python – concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor) + [Lambda クォータ — 関数の設定、デプロイ、実行](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution) + [Python AWS CDK での の使用](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-python.html) + [AWS Lambda パワーチューニングによる関数のプロファイリング](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) ## 追加情報 **Code** 次のコードスニペットは、並列 I/O 処理を実行します。 ``` with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor: for result in executor.map(a_function, (the_arguments)): ... ``` `ThreadPoolExecutor` は、スレッドが利用可能になると再利用します。 **テストと結果** これらのテストは 2024 年 12 月に実施されました。 最初のテストでは 2,500 のオブジェクト読み取りが処理され、次のような結果になりました。 ![\[メモリの増加に伴う呼び出し時間の短縮と呼び出しコストの増加。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f6743412-1e52-4c4c-a51c-ac0f75b3b998.png) 3,009 MB から、処理時間レベルはメモリが増えてもほぼ同じままでしたが、メモリサイズの増加に伴ってコストが増加しました。 別のテストでは、256 MB の倍数の値を使用し、10,000 のオブジェクト読み取りを処理して、1,536 MB から 3,072 MB のメモリの範囲を調査しました。その結果は次のとおりです。 ![\[呼び出し時間の短縮と呼び出しコストの増加の差が減少しました。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/c75d4443-74d8-4b93-9b4d-b2640869381e.png) 最高の費用対効果の比率は、2,304 MB のメモリ Lambda 設定でした。 比較として、2,500 のオブジェクト読み取りのシーケンシャルプロセスには 47 秒かかりました。2,304 MB の Lambda 設定を使用した並列処理には 7 秒かかり、85% 短縮されました。 ![\[シーケンシャル処理から並列処理に切り替えるときの時間の短縮を示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f3dcc44d-ac20-4b75-897d-1d71f0d59781.png) # から OpenSearch AWS Lambda にテレメトリデータを送信してリアルタイムの分析と視覚化を行う *Amazon Web Services、Tabby Ward、Guy Bachar、David Kilzer* ## 概要 最新のアプリケーションはますます分散され、イベント駆動型になり、リアルタイムのモニタリングとオブザーバビリティの必要性が強化されています。 AWS Lambda は、スケーラブルでイベント駆動型のアーキテクチャを構築する上で重要な役割を果たしているサーバーレスコンピューティングサービスです。ただし、Amazon CloudWatch Logs のみに依存すると、Lambda 関数のモニタリングとトラブルシューティングが難しくなるため、作業に遅延が発生し、保持期間が限定される可能性があります。 この課題に対処するために、Lambda Telemetry API AWS を導入しました。これにより、Lambda 関数はテレメトリデータをサードパーティーのモニタリングおよびオブザーバビリティツールに直接送信できます。この API は、ログ、メトリクス、トレースのリアルタイムストリーミングをサポートし、Lambda 関数のパフォーマンスと状態を包括的かつタイムリーに表示します。 このパターンでは、オープンソースの分散検索および分析エンジンである [OpenSearch](https://opensearch.org/docs/latest/) と Lambda Telemetry API を統合する方法について説明します。OpenSearch は、大量のデータの取り込み、保存、分析を行う強力かつスケーラブルなプラットフォームを提供するため、Lambda テレメトリデータに最適です。具体的には、このパターンは、 AWSによって提供される Lambda 拡張機能を使用して、Python で記述された Lambda 関数から OpenSearch クラスターに直接ログを送信する方法を示しています。このソリューションは柔軟性が高くカスタマイズも可能です。したがって、独自の Lambda 拡張機能を作成することも、サンプルソースコードを調整して希望する出力形式に変更することもできます。 このパターンでは、Lambda Telemetry API と OpenSearch の統合を設定する方法を説明し、セキュリティ、コスト最適化、スケーラビリティに関するベストプラクティスも提供します。目的は、Lambda 関数の理解を深め、サーバーレスアプリケーションの全体的なオブザーバビリティを向上させることです。 | | | 注: このパターンは、Lambda Telemetry API とマネージド OpenSearch の統合を中心としています。ただし、説明されている原則と手法は、セルフマネージド型の OpenSearch と Elasticsearch にも適用できます。 | | --- | ## 前提条件と制限事項 統合プロセスを開始する前に、次の前提条件を満たしていることを確認してください。 **AWS アカウント**: 次の AWS リソースを作成および管理するための適切なアクセス許可 AWS アカウント を持つアクティブな 。 + AWS Lambda + AWS Identity and Access Management (IAM) + Amazon OpenSearch Service (マネージド OpenSearch クラスターを使用している場合) **OpenSearch クラスター**: + 既存のセルフマネージド OpenSearch クラスターまたは OpenSearch Service などのマネージドサービスを使用できます。 + OpenSearch Service を使用している場合は、OpenSearch Service ドキュメントの「[Getting started with Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsg.html)」の手順に従って OpenSearch クラスターを設定します。 + OpenSearch クラスターが Lambda 関数からアクセス可能であり、アクセスポリシー、暗号化、認証などの必要なセキュリティ設定で構成されていることを確認します。 + Lambda テレメトリデータを取り込むために必要なインデックスマッピングと設定で OpenSearch クラスターを構成します。詳細については、OpenSearch Service ドキュメントの「[Loading streaming data into Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html)」を参照してください。 **ネットワーク接続**: + Lambda 関数に OpenSearch クラスターにアクセスするために必要なネットワーク接続があることを確認します。仮想プライベートクラウド (VPC) の設定方法のガイダンスについては、OpenSearch Service ドキュメントの「[Launching your Amazon OpenSearch Service domains within a VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)」を参照してください。 **IAM ロールとポリシー**: + Lambda 関数が OpenSearch クラスターにアクセスし、 AWS Secrets Managerに保存されている認証情報にアクセスするために必要なアクセス許可を持つ IAM ロールを作成します。 + `AWSLambdaBasicExecutionRole` ポリシーや OpenSearch を操作するために必要な追加のアクセス許可など、適切な IAM ポリシーをロールにアタッチします。 + Lambda 関数に付与された IAM アクセス許可により OpenSearch クラスターへのデータの書き込みが許可されていることを確認します。IAM アクセス許可の管理の詳細については、Lambda ドキュメントの「[実行ロールを使用した Lambda 関数のアクセス許可の定義](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。 **プログラミング言語の知識**: + Lambda 関数と Lambda 拡張機能のサンプルコードを理解して変更するには、Python (または選択したプログラミング言語) に関する基本的な知識が必要です。 **開発環境**: + Lambda 関数と拡張機能を構築およびデプロイするために必要なツールと依存関係を使用して、ローカル開発環境を設定します。 **AWS CLI または AWS マネジメントコンソール**: + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) をインストールして設定するか、適切な認証情報 AWS マネジメントコンソール で を使用して必要な を操作します AWS のサービス。 **モニタリングとログ記録**: + Amazon CloudWatch や などのサービスを含む AWS、 のモニタリングとログ記録 AWS CloudTrail のベストプラクティスに精通し、モニタリングと監査を行います。 + Lambda 関数の CloudWatch Logs をチェックして、Lambda Telemetry API 統合に関連するエラーや例外を特定します。トラブルシューティングのガイダンスについては、[Lambda Telemetry API ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html)を参照してください。 ## アーキテクチャ このパターンでは、OpenSearch Service を使用して、Lambda 関数によって生成されたログとテレメトリデータを保存します。このアプローチでは、ログを OpenSearch クラスターに直接すばやくストリーミングできるため、CloudWatch Logs を仲介として使用する際のレイテンシーとコストを削減できます。 | | | Lambda 拡張機能コードは、OpenSearch API を直接使用するか、[OpenSearch クライアントライブラリ](https://opensearch.org/docs/latest/clients/index/)を使用して、テレメトリを OpenSearch Service にプッシュできます。Lambda 拡張機能は、OpenSearch API でサポートされている一括操作を使用してテレメトリイベントをバッチ処理し、1 回のリクエストで OpenSearch Service に送信できます。 | | --- | 次のワークフロー図は、エンドポイントとして OpenSearch クラスターを使用する場合の Lambda 関数のログワークフローを示しています。 ![\[OpenSearch クラスターにテレメトリデータを送信するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/57fe8796-9f36-46cf-8304-f506242b9f04/images/283ccdcd-a0e1-40a2-a95a-3bd046bfa8ca.png) アーキテクチャには以下のコンポーネントが含まれています。 + Lambda 関数: 実行中にログとテレメトリデータを生成するサーバーレス関数。 + Lambda 拡張機能: Lambda Telemetry API を使用して OpenSearch クラスターと直接統合する Python ベースの拡張機能。この拡張機能は、Lambda 関数と同じ実行環境で一緒に実行されます。 + Lambda Telemetry API: Lambda 拡張機能がログ、メトリクス、トレースなどのテレメトリデータをサードパーティーのモニタリングおよびオブザーバビリティツールに直接送信できるようにする API。 + Amazon OpenSearch Service クラスター: AWSでホストされているマネージド OpenSearch クラスター。このクラスターは、Lambda 拡張機能を介して Lambda 関数からストリーミングされたログデータの取り込み、保存、インデックス作成を行います。 ワークフローは以下のステップで構成されます。 1. Lambda 関数が呼び出され、実行中にログとテレメトリデータが生成されます。 1. Lambda 拡張機能は関数と一緒に実行され、Lambda Telemetry API を使用してログとテレメトリデータをキャプチャします。 1. Lambda 拡張機能は、OpenSearch Service クラスターとの安全な接続を確立し、ログデータをリアルタイムでストリーミングします。 1. OpenSearch Service クラスターは、Kibana やその他の互換性のあるアプリケーションなどのツールを使用して、ログデータの取り込み、インデックス作成、保存を行い、検索、分析、視覚化に使用できるようにします。 CloudWatch Logs を回避し、ログデータを OpenSearch クラスターに直接送信するため、このソリューションには次のようないくつかの利点があります。 + リアルタイムのログストリーミングと分析により、より迅速なトラブルシューティングが可能になり、オブザーバビリティが向上します。 + CloudWatch Logs に関連するレイテンシーと保持制限の可能性が軽減されます。 + 高い柔軟性により、Lambda 拡張機能をカスタマイズする、特定の出力形式や追加の処理用に独自の拡張機能を作成するといった作業に対応できます。 + OpenSearch Service の検索、分析、視覚化機能と統合して、ログ分析とモニタリングを行うことができます。 「[エピック](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-epics)」セクションでは、Lambda 拡張機能の設定、Lambda 関数の設定、OpenSearch Service クラスターとの統合の段階的な手順を説明します。セキュリティ上の考慮事項、コスト最適化戦略、ソリューションのモニタリングとトラブルシューティングのヒントについては、「[ベストプラクティス](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-best-practices)」セクションを参照してください。 ## ツール **AWS サービス** + [AWS Lambda](https://aws.amazon.com/lambda/) はサーバーのプロビジョニングや管理をする必要がなく、コードを実行できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。 + [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) は、 が提供するフルマネージドサービス AWS であり、OpenSearch クラスターをクラウドに簡単にデプロイ、運用、スケーリングできます。 + [Lambda 拡張機能](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)は、カスタムコードを一緒に実行することで、Lambda 関数の機能を拡張します。Lambda 拡張機能を使用して、Lambda を、モニタリング、オブザーバビリティ、セキュリティ、およびガバナンスのさまざまなツールと統合します。 + [AWS Lambda Telemetry API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html) を使用すると、拡張機能を使用して、Lambda から直接拡張モニタリングおよびオブザーバビリティデータをキャプチャし、任意の送信先に送信できます。 + [CloudFormation](https://aws.amazon.com/cloudformation/) では、 AWS リソースをモデル化してセットアップできるため、それらのリソースの管理に費やす時間が減り、アプリケーションに集中する時間が増えます。 **コードリポジトリ** + [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)には、独自の拡張機能の構築を開始するのに役立つ AWS および AWS パートナーからのデモとサンプルプロジェクトが含まれています。 + [OpenSearch の Lambda テレメトリ統合の例](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension)には、Lambda 関数から OpenSearch クラスターにログを送信する方法を示す Lambda 拡張機能のサンプルが用意されています。 **その他のツール** + [OpenSearch](https://opensearch.org/faq/) は、大量のデータを取り込み、保存、分析するための強力なプラットフォームを提供するオープンソースの分散検索および分析エンジンです。 + Kibana は、OpenSearch で使用できるオープンソースのデータ視覚化および探索ツールです。視覚化と分析の実装はこのパターンの範囲外になりますので注意してください。詳細については、[Kibana のドキュメント](https://www.elastic.co/guide/en/kibana/current/index.html)とその他のリソースを参照してください。 ## ベストプラクティス Lambda Telemetry API を OpenSearch と統合するときは、次のベストプラクティスを考慮してください。 **セキュリティとアクセスコントロール** + **安全な通信**: Lambda 関数と OpenSearch クラスター間のすべての通信を HTTPS を使用して暗号化します。Lambda 拡張機能と OpenSearch 設定で必要な SSL/TLS 設定を構成します。 + **IAM アクセス許可**: + 拡張機能は Lambda 関数と同じ実行環境で実行されるため、ファイルシステム、ネットワーク、環境変数などのリソースへの同じレベルのアクセスを継承します。 + Lambda Telemetry API にアクセスして OpenSearch クラスターにデータを書き込むために必要な最小限の IAM アクセス許可を Lambda 関数に付与します。[最小特権の原則](https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html)を使用して、アクセス許可の範囲を制限します。 + **OpenSearch アクセス制御**: OpenSearch クラスターにきめ細かなアクセス制御を実装して、機密データへのアクセスを制限します。OpenSearch では、ユーザー認証、ロールベースのアクセス制御、インデックスレベルのアクセス許可などの組み込みのセキュリティ機能を使用します。 + **信頼できる拡張機能**: 常に信頼できるソースからのみ拡張機能をインストールします。などのInfrastructure as Code (IaC) ツールを使用して、IAM アクセス許可を含む同じ拡張機能設定を複数の Lambda 関数にアタッチするプロセス CloudFormation を簡素化します。IaC ツールは、以前に使用された拡張機能とバージョンの監査レコードも提供します。 + **機密データの処理**: 拡張機能を構築するときに、機密データのログを回避してください。監査のためにログ記録または永続化する前に、ペイロードとメタデータをサニタイズします。 **コスト最適化** + **モニタリングとアラート**: Lambda 関数から OpenSearch に送信されるデータの量を追跡するモニタリングとアラートのメカニズムを設定します。これにより、潜在的なコスト超過を特定して対処できます。 + **データ保持**: OpenSearch の Lambda テレメトリデータに適したデータ保持期間を慎重に検討してください。保持期間が長くなるとストレージコストが増加する可能性があるため、オブザーバビリティのニーズとコスト最適化のバランスを取ります。 + **圧縮とインデックス作成**: データ圧縮を有効にし、OpenSearch インデックス作成戦略を最適化して、Lambda テレメトリデータのストレージフットプリントを削減します。 + **CloudWatch への依存を減らす**: Lambda Telemetry API を OpenSearch と直接統合することで、CloudWatch Logs への依存を減らすことができ、コスト削減につながる可能性があります。これは、Lambda Telemetry API によって OpenSearch に直接ログを送信できるため、CloudWatch にデータを保存して処理する必要がなくなるためです。 **スケーラビリティと信頼性** + **非同期処理**: Amazon Simple Queue Service (Amazon SQS) や Amazon Kinesis などの非同期処理パターンを使用して、Lambda 関数の実行を OpenSearch データインジェストから切り離します。これにより、Lambda 関数の応答性を維持し、システムの全体的な信頼性を向上させることができます。 + **OpenSearch クラスターのスケーリング**: OpenSearch クラスターのパフォーマンスとリソース使用率をモニタリングし、必要に応じてスケールアップまたはスケールダウンして、増加する Lambda テレメトリデータを処理します。 + **フェイルオーバーとディザスタリカバリ**: 定期的なバックアップや障害発生時にデータをすばやく復元する機能など、OpenSearch クラスターの堅牢なディザスタリカバリ戦略を実装します。 **オブザーバビリティとモニタリング** + **ダッシュボードと視覚化**: Kibana または他のダッシュボードツールを使用して、OpenSearch のテレメトリデータに基づいて Lambda 関数のパフォーマンスと状態に関するインサイトを提供するカスタムダッシュボードと視覚化を作成します。 + **アラートと通知**: Lambda 関数の異常、エラー、パフォーマンスの問題を積極的にモニタリングするようにアラートと通知を設定します。これらのアラートと通知を既存のインシデント管理プロセスと統合します。 + **トレースと相関関係**: Lambda テレメトリデータにリクエスト ID や相関 ID などの関連するトレース情報が含まれていることを確認し、分散サーバーレスアプリケーション全体でエンドツーエンドのオブザーバビリティとトラブルシューティングを実現します。 これらのベストプラクティスに従うことで、Lambda Telemetry API と OpenSearch の統合の安全性、コスト効率、スケーラビリティを確保し、サーバーレスアプリケーションに包括的なオブザーバビリティを提供できます。 ## エピック ### Lambda 拡張機能レイヤーを構築およびデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースコードをダウンロードします。 | [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)リポジトリからサンプル拡張機能をダウンロードします。 | アプリ開発者、クラウドアーキテクト | | `python-example-telemetry-opensearch-extension` フォルダに移動します。 | ダウンロードした [AWS Lambda 拡張機能](https://github.com/aws-samples/aws-lambda-extensions)リポジトリには、いくつかのユースケースと言語ランタイムに関する多数の例が含まれています。[python-example-telemetry-opensearch-extension](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension) フォルダに移動し、Python OpenSearch 拡張機能を使用して OpenSearch にログを送信します。 | アプリ開発者、クラウドアーキテクト | | 拡張機能エンドポイントを実行するアクセス許可を追加します。 | 次のコマンドを実行して、拡張機能エンドポイントを実行可能にします。
chmod +x python-example-telemetry-opensearch-extension/extension.py
| アプリ開発者、クラウドアーキテクト | | 拡張機能の依存関係をローカルにインストールします。 | 以下のコマンドを実行して、Python コードのローカル依存関係をインストールします。
pip3 install -r python-example-telemetry-opensearch-extension/requirements.txt -t ./python-example-telemetry-opensearch-extension/
これらの依存関係は、拡張機能コードとともにマウントされます。 | アプリ開発者、クラウドアーキテクト | | 拡張機能の .zip パッケージを作成して、レイヤーとしてデプロイします。 | 拡張機能の .zip ファイルには、拡張機能実行可能ファイルがある `extensions/` というルートディレクトリと、拡張機能のコアロジックとその依存関係がある `python-example-telemetry-opensearch-extension/` という別のルートディレクトリが含まれている必要があります。拡張機能の .zip パッケージを作成します。
chmod +x extensions/python-example-telemetry-opensearch-extension
zip -r extension.zip extensions python-example-telemetry-opensearch-extension
| アプリ開発者、クラウドアーキテクト | | 拡張機能を Lambda レイヤーとしてデプロイします。 | 拡張機能の .zip ファイルと次のコマンドを使用してレイヤーを公開します。
aws lambda publish-layer-version \
--layer-name "python-example-telemetry-opensearch-extension" \
--zip-file "fileb://extension.zip"
| アプリ開発者、クラウドアーキテクト | ### 拡張機能を関数に統合する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レイヤーを関数に追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)Lambda 関数へのレイヤーの追加についての詳細は、「[Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html)」を参照してください。 | アプリ開発者、クラウドアーキテクト | | 関数の環境変数を設定します。 | 関数ページで、**[設定]** タブを選択し、次の環境変数を関数に追加します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | アプリ開発者、クラウドアーキテクト | ### ログ記録ステートメントを追加して関数をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 関数にログ記録ステートメントを追加します。 | [組み込みのログ記録メカニズム](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html)のいずれか、または任意のログ記録モジュールを使用して、関数にログ記録ステートメントを追加します。Python でのメッセージのログ記録の例を次に示します。
print("Your Log Message Here")
logger = logging.getLogger(__name__)

logger.info("Test Info Log.")
logger.error("Test Error Log.")
| アプリ開発者、クラウドアーキテクト | | 関数をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)すべてが適切に機能すると、「**Executing function: succeeded**」と表示されます。 | アプリ開発者、クラウドアーキテクト | ### OpenSearch でログを表示する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インデックスをクエリします。 | OpenSearch で、次のコマンドを実行してインデックスをクエリします。
SELECT * FROM index-name
ログはクエリ結果に表示されます。 | クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 接続の問題 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | | データインジェストエラー | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | ## 関連リソース + [OpenSearch の Lambda テレメトリー統合の例](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension) (GitHub リポジトリ) + [Lambda 拡張機能を使用して Lambda 関数を補強する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) (Lambda ドキュメント) + [Lambda Telemetry API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html) (Lambda ドキュメント) + [AWS Lambda Telemetry API の](https://aws.amazon.com/blogs/compute/introducing-the-aws-lambda-telemetry-api/)紹介 (AWS ブログ記事) + [AWS Lambda Telemetry API と Prometheus および OpenSearch の統合](https://aws.amazon.com/blogs/opensource/integrating-the-aws-lambda-telemetry-api-with-prometheus-and-opensearch) (AWS ブログ記事) ## 追加情報 **ログ構造の変更** 拡張機能は、デフォルトでネストされたドキュメントとしてログを OpenSearch に送信します。これにより、ネストされたクエリを実行して各列の値を取得できます。 デフォルトのログ出力が特定のニーズを満たさない場合は、 が提供する Lambda 拡張機能のソースコードを変更することでカスタマイズできます AWS。 AWS は、出力をビジネス要件に合わせて調整するようお客様にお勧めします。ログ出力を変更するには、拡張機能のソースコード内の `telemetry_dispatcher.py` ファイルで `dispatch_to_opensearch` 関数を見つけ、必要な変更を行います。 # セルベースアーキテクチャ用にサーバーレスセルルーターを設定する *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 ## アーキテクチャ 次の図は、セルルーターの大まかな設計を示しています。 ![\[セルルーターの 5 つのステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/feb90b51-dd91-483b-b5a3-b0a5359686e3.png) この図は、次のワークフローを段階的に示しています。 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 アカウント は障害分離の境界として機能します。 次の図は、レイヤーの概要を示しています。セルレイヤーおよびプロビジョンとデプロイレイヤーは、このパターンの範囲外です。 ![\[ルーティングレイヤー、複数のセルアカウントを持つセルレイヤー、プロビジョンとデプロイレイヤー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/137ac34d-43c3-42b6-95de-a365ff611ce8.png) セルベースアーキテクチャの詳細については、「[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 ステートが呼び出されます。 ![\[4 つの関数があり、Fail ステートで終了するワークフローの図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/cfe8d029-6f30-49a1-aaad-cad503bdcbae.png) *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` 関数は、セルが正常かどうかも確認します。 # VPC エンドポイントを介して Amazon S3 バケットへのプライベートアクセスを設定する *Martin Maritsch、Nicolas Jacob Baer、Gabriel Rodriguez Garcia、Shukhrat Khodjaev、Mohan Gowda Purushothama、Joaquin Rinaudo、Amazon Web Services* ## 概要 Amazon Simple Storage Service (Amazon S3) では、署名付き URL を使用して、任意のサイズのファイルをターゲットユーザーと共有できます。デフォルトでは、Amazon S3 の署名付き URL には有効期限内にインターネットからアクセスできるため、使いやすくなっています。ただし、企業環境では、多くの場合、Amazon S3 の署名付き URL へのアクセスをプライベートネットワークのみに制限する必要があります。 このパターンは、インターネットトラバーサルなしでプライベートネットワークからの署名付き URL を使用して S3 オブジェクトを安全に操作するためのサーバーレスソリューションを示しています。このアーキテクチャでは、ユーザーは内部ドメイン名を介して Application Load Balancer にアクセスします。トラフィックは、Amazon API Gateway と S3 バケットの仮想プライベートクラウド (VPC) エンドポイントを介して内部でルーティングされます。この AWS Lambda 関数は、プライベート VPC エンドポイントを介してファイルをダウンロードするための署名URLs を生成し、機密データのセキュリティとプライバシーを強化するのに役立ちます。 ## 前提条件と制限 **前提条件** + AWS アカウント 企業ネットワークに接続された にデプロイされたサブネットを含む VPC ( 経由など AWS Direct Connect)。 **制限事項** + S3 バケットにはドメインと同じ名前を付ける必要があるため、[Amazon S3 バケットの命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)を確認することをお勧めします。 + このサンプルアーキテクチャには、デプロイされたインフラストラクチャのモニタリング機能は含まれていません。ユースケースでモニタリングが必要な場合は、[AWS モニタリングサービス](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)の追加を検討してください。 + このサンプルアーキテクチャには、入力検証は含まれません。ユースケースで入力検証とセキュリティの強化が必要な場合は、 [を使用して API AWS WAF を保護することを検討してください](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。 + このサンプルアーキテクチャには、Application Load Balancer によるアクセスログ記録は含まれません。ユースケースでアクセスのログ記録が必要な場合は、[ロードバランサーのアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)を有効にすることを検討してください。 バージョン + Python バージョン 3.11 以降 + Terraform バージョン 1.6 以降 ## アーキテクチャ **ターゲットテクノロジースタック** ターゲットテクノロジースタックでは、次の AWS サービスが使用されます。 + **Amazon S3** は、ファイルのアップロード、ダウンロード、および保存を安全に行うために使用されるコアストレージサービスです。 + **Amazon API Gateway** は、S3 バケットを操作するためのリソースとエンドポイントを公開します。このサービスは、データをダウンロードまたはアップロードするための署名付き URL を生成する役割を果たします。 + **AWS Lambda** は、Amazon S3 からファイルをダウンロードするための署名付き URL を生成します。API ゲートウェイは Lambda 関数を呼び出します。 + **Amazon VPC** は VPC 内にリソースをデプロイして、ネットワークを隔離します。VPC には、トラフィックフローを制御するためのサブネットとルーティングテーブルが含まれています。 + **Application Load Balancer** は、受信トラフィックを API ゲートウェイまたは S3 バケットの VPC エンドポイントにルーティングします。これにより、企業ネットワークのユーザーは内部でリソースにアクセスできます。 + **Amazon S3 の VPC エンドポイント**を使用すると、パブリックインターネットを経由することなく、VPC 内のリソースと Amazon S3 間の直接のプライベート通信が可能になります。 + **AWS Identity and Access Management (IAM)** は、 AWS リソースへのアクセスを制御します。アクセス許可は、API およびその他のサービスとの安全なやり取りを確保するために設定されます。 **ターゲットアーキテクチャ** ![\[VPC エンドポイントを介した S3 バケットへのプライベートアクセスの設定\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/683ca6a1-789c-4444-bcbf-e4e80d253df3/images/1ca7ee17-d346-4eb9-bf61-ccf42528a401.png) この図表は、以下を示すものです: 1. 企業ネットワークのユーザーは、内部ドメイン名を使用して Application Load Balancer にアクセスできます。企業ネットワークと のイントラネットサブネットの間に接続が存在することを前提としています AWS アカウント ( Direct Connect 接続経由など）。 1. Application Load Balancer は、受信トラフィックを API ゲートウェイにルーティングして、Amazon S3 または S3 バケットの VPC エンドポイントにデータをダウンロードまたはアップロードするための署名付き URL を生成します。どちらのシナリオでも、リクエストは内部でルーティングされるため、インターネットを経由する必要はありません。 1. API ゲートウェイは、S3 バケットを操作するためのリソースとエンドポイントを公開します。この例では、S3 バケットからファイルをダウンロードするためのエンドポイントを提供しますが、アップロード機能を提供するために拡張することもできます。 1. Lambda 関数は、パブリック Amazon S3 ドメインの代わりに Application Load Balancer のドメイン名を使用して Amazon S3 からファイルをダウンロードするための署名付き URL を生成します。 1. ユーザーは署名付き URL を受け取り、それと Application Load Balancer を使用して Amazon S3 からファイルをダウンロードします。ロードバランサーには、API を意図していないトラフィックを S3 バケットの VPC エンドポイントに送信するデフォルトルートが含まれています。 1. VPC エンドポイントは、カスタムドメイン名を使用して署名付き URL を S3 バケットにルーティングします。S3 バケットは、ドメインと同じ名前にする必要があります。 **自動化とスケール** このパターンでは、Terraform を使用してコードリポジトリから AWS アカウントにインフラストラクチャをデプロイします。 ## ツール **ツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りするのに役立つオープンソースツールです。 **コードリポジトリ** このパターンのコードは、[https://github.com/aws-samples/private-s3-vpce](https://github.com/aws-samples/private-s3-vpce) の GitHub リポジトリで入手できます。 ## ベストプラクティス このパターンのサンプルアーキテクチャでは、[IAM アクセス許可](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)を使用して API へのアクセスを制御します。有効な IAM 認証情報を持つユーザーは誰でも API を呼び出すことができます。より複雑な認可モデルが必要なユースケースにおいては、[別のアクセスコントロールメカニズムの使用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)をご検討ください。 ## エピック ### ソリューションを にデプロイする AWS アカウント | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS 認証情報を取得します。 | AWS 認証情報とアカウントへのアクセスを確認します。手順については、 AWS CLI ドキュメントの[「設定と認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」を参照してください。 | AWS DevOps、AWS 全般 | | リポジトリのクローン作成 | このパターンで提供されている GitHub リポジトリのクローンを作成します。
git clone https://github.com/aws-samples/private-s3-vpce
| AWS DevOps、AWS 全般 | | 変数を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | | ソリューションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | ### ソリューションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストファイルを作成します。 | Amazon S3 にファイルをアップロードして、ファイルのダウンロードのテストシナリオを作成します。[Amazon S3 コンソール](https://console.aws.amazon.com/s3/)または次の AWS CLI コマンドを使用できます。
aws s3 cp /path/to/testfile s3://your-bucket-name/testfile
| AWS DevOps、AWS 全般 | | 署名付き URL 機能をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps、AWS 全般 | | クリーンアップ | 不要になったリソースは必ず削除してください。
terraform destroy
| AWS DevOps、AWS 全般 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 番号記号 (\$1) などの特殊文字を含む S3 オブジェクトキー名により URL パラメータが破損し、エラーが発生します。 | URL パラメータを適切にエンコードし、S3 オブジェクトキー名が [Amazon S3 ガイドライン](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html)に従っていることを確認します。 | ## 関連リソース Amazon S3: + [署名付き URLsを使用したオブジェクトの共有](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) + [バケットポリシーを使用した VPC エンドポイントからのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html) Amazon API Gateway: + [API Gateway のプライベート APIs に VPC エンドポイントポリシーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-endpoint-policies.html) Application Load Balancer: + [ALB、S3、および PrivateLink を使用した内部 HTTPS 静的ウェブサイトのホスティング](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/) (AWS ブログ記事) # Amazon Bedrock AWS Step Functions を使用して の状態をトラブルシューティングする *Aniket Kurzadkar、Sangam Kushwaha (Amazon Web Services)* ## 概要 AWS Step Functions エラー処理機能は、[ワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)の状態中に発生するエラーを確認するのに役立ちますが、それでもエラーの根本原因を見つけてデバッグするのは難しい場合があります。このパターンでは、この課題に対処し、Amazon Bedrock が Step Functions でステートの実行中に発生するエラーの解決にどのように役立つかを示します。 Step Functions はワークフローオーケストレーションを実現するため、開発者はプロセスを簡単に自動化できます。また、Step Functions にはエラー処理機能も用意されており、次のような利点があります。 + 開発者は、問題が発生しても完全には失敗しない、より回復力の高いアプリケーションを作成できます。 + ワークフローには、さまざまなタイプのエラーを異なる方法で処理する条件付きロジックを含めることができます。 + システムは、エクスポネンシャルバックオフを使用して、失敗した操作を自動的に再試行できます。 + エラーシナリオに対して代替の実行パスを定義できるため、ワークフローを適応させて処理を続行できます。 Step Functions ワークフローでエラーが発生した場合、このパターンでは、Step Functions でサポートされている Claude 3 などの基盤モデル (FM) にエラーメッセージとコンテキストを送信する方法を示します。FM はエラーを分析し、分類し、潜在的な修復手順を提案できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + [AWS Step Functions とワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)の基本的な理解 + Amazon Bedrock [API 接続](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html) **制限事項** + このパターンのアプローチは、さまざまな AWS のサービスに使用できます。ただし、結果は、Amazon Bedrock によって評価 AWS Lambda される によって作成されたプロンプトによって異なる場合があります。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについて確認するには、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照し、サービスのリンクを選択してください。 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[Step Functions、Amazon Bedrock、Amazon SNS を使用したエラー処理と通知のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/78f86c74-c9de-4562-adcc-105b87a77a54/images/d8eda499-ea1d-45e5-8a36-e04a44ad5c4b.png) この図は、Step Functions ステートマシンでのエラー処理と通知の自動ワークフローを示しています。 1. 開発者がステートマシンの実行を開始します。 1. Step Functions ステートマシンが状態の処理を開始します。この場合、次の 2 通りの結果が想定されます。 + (a) すべてのステートが正常に実行されると、ワークフローは Amazon SNS に直接進み、E メールで成功通知が送信されます。 + (b) いずれかのステートが失敗すると、ワークフローはエラー処理の Lambda 関数に移動します。 1. エラーが発生した場合、次の処理が行われます。 + (a) Lambda 関数 (エラーハンドラー) がトリガーされます。Lambda 関数は、Step Functions ステートマシンから渡されたイベントデータからエラーメッセージを抽出します。次に、Lambda 関数はこのエラーメッセージに基づいてプロンプトを準備し、Amazon Bedrock に送信します。プロンプトは、発生した特定のエラーに関連する解決策と提案をリクエストします。 + (b) 生成 AI モデルをホストする Amazon Bedrock が、入力プロンプトを処理します (このパターンでは、Amazon Bedrock がサポートする多くの FM の 1 つである Anthropic Claude 3 基盤モデル (FM) を使用します)。AI モデルがエラーコンテキストを分析します。その後、モデルは、エラー発生の原因説明、可能性のある解決策、今後同じ間違いを起こさないようにするための提案を含むレスポンスを生成します。 Amazon Bedrock が、AI によって生成されたレスポンスを Lambda 関数に返します。Lambda 関数がレスポンスを処理し、フォーマットや主要な情報の抽出を行います。その後、Lambda 関数はステートマシンの出力にレスポンスを送信します。 1. エラー処理または実行が正常に完了すると、ワークフローは Amazon SNS をトリガーして E メールで通知を送信し、終了します。 ## ツール **AWS のサービス** + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、主要な AI スタートアップや Amazon が提供する高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにするフルマネージド型サービスです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 ## ベストプラクティス + Amazon Bedrock はトレーニングされたデータから学習する生成 AI モデルであり、そのデータを使用してコンテキストのトレーニングと生成も行います。ベストプラクティスとして、データ漏洩の問題につながる恐れのある個人情報は隠します。 + 生成 AI は有益なインサイトを提供できますが、特に本番環境において、重大なエラー処理の決定には人間による監視が必要です。 ## エピック ### ワークフロー用のステートマシンを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ステートマシンの作成。 | ワークフローに適したステートマシンを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ### Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を作成する。 | Lambda 関数をインポートするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | | Lambda コードで必要なロジックを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html)
client = boto3.client(
        service_name="bedrock-runtime", region_name="selected-region"
    )

    # Invoke Claude 3 with the text prompt
    model_id = "your-model-id" # Select your Model ID, Based on the Model Id, Change the body format

    try:
        response = client.invoke_model(
            modelId=model_id,
            body=json.dumps(
                {
                    "anthropic_version": "bedrock-2023-05-31",
                    "max_tokens": 1024,
                    "messages": [
                        {
                            "role": "user",
                            "content": [{"type": "text", "text": prompt}],
                        }
                    ],
                }
            ),
        )
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ### Step Functions を Lambda と統合する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Step Functions でエラーを処理するように Lambda を設定します。 | ワークフローを中断せずにエラーを処理するように Step Functions を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Lambda が Amazon Bedrock API にアクセスできない (実行する権限がない) | このエラーは、Lambda ロールに Amazon Bedrock API へのアクセス許可がない場合に発生します。この問題を解決するには、Lambda ロールに `AmazonBedrockFullAccess` ポリシーを追加します。詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonBedrockFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)」を参照してください。 | | Lambda タイムアウトエラー | プロンプトによっては、レスポンスを生成して返すまでに 30 秒以上かかる場合があります。この問題を解決するには、設定時間を長くします。詳細については、*AWS Lambda デベロッパーガイド*の「[Lambda 関数のタイムアウトを設定する](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)」を参照してください。 | ## 関連リソース + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) + [Amazon Bedrock API access](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html) + [最初の Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) + [Step Functions を使用したワークフローの開発](https://docs.aws.amazon.com/step-functions/latest/dg/developing-workflows.html#development-run-debug) + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) # その他のパターン **Topics** + [Athena による Amazon DynamoDB テーブルへのアクセス、クエリ、結合](access-query-and-join-amazon-dynamodb-tables-using-athena.md) + [GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する](automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.md) + [AWS リソース評価を自動化する](automate-aws-resource-assessment.md) + [AWS SAM を使用してネストされたアプリケーションのデプロイを自動化](automate-deployment-of-nested-applications-using-aws-sam.md) + [GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する](automate-the-deployment-of-aws-supply-chain-data-lakes.md) + [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md) + [DynamoDB TTL を使用して項目を Amazon S3 に自動的にアーカイブする](automatically-archive-items-to-amazon-s3-using-dynamodb-ttl.md) + [CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md) + [Amazon OpenSearch Service におけるマルチテナントサーバーレスアーキテクチャの構築](build-a-multi-tenant-serverless-architecture-in-amazon-opensearch-service.md) + [AWS クラウドで高度なメインフレームファイルビューアを構築](build-an-advanced-mainframe-file-viewer-in-the-aws-cloud.md) + [AWS のサービスを使用してバリューアットリスク (VaR) を計算](calculate-value-at-risk-var-by-using-aws-services.md) + [AWS Service Catalog 製品を異なる AWS アカウントと AWS リージョンにコピー](copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.md) + [Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.md) + [CQRS とイベントソーシングを使用してモノリスをマイクロサービスに分解する](decompose-monoliths-into-microservices-by-using-cqrs-and-event-sourcing.md) + [React ベースのシングルページアプリケーションを Amazon S3 と CloudFront にデプロイする](deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.md) + [プライベートエンドポイントと Application Load Balancer を使用して、Amazon API Gateway API を内部 Web サイトにデプロイする](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md) + [インフラストラクチャをコードとして使用して、AWS クラウドにサーバーレスデータレイクをデプロイして管理する](deploy-and-manage-a-serverless-data-lake-on-the-aws-cloud-by-using-infrastructure-as-code.md) + [Terraform と Amazon Bedrock を使用して AWS に RAG ユースケースをデプロイする](deploy-rag-use-case-on-aws.md) + [Amazon Bedrock エージェントとナレッジベースを使用して、完全に自動化したチャットベースのアシスタントを開発する](develop-a-fully-automated-chat-based-assistant-by-using-amazon-bedrock-agents-and-knowledge-bases.md) + [RAG と ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md) + [Step Functions を使用して IAM アクセスアナライザーで IAM ポリシーを動的に生成](dynamically-generate-an-iam-policy-with-iam-access-analyzer-by-using-step-functions.md) + [Amazon Cognito と IaC オートメーションを使用して Amazon Quick Sight ビジュアルコンポーネントをウェブアプリケーションに埋め込む](embed-quick-sight-visual-components-into-web-apps-cognito-iac.md) + [Amazon S3 へのAmazon EMR ロギングが有効になっていることを確認する](ensure-amazon-emr-logging-to-amazon-s3-is-enabled-at-launch.md) + [DynamoDB テーブルのコストをオンデマンドで見積る](estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.md) + [Amazon Personalize を使用して、パーソナライズされ再ランク付けされたレコメンデーションを生成します](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md) + [AWS Glue ジョブと Python を使用してテストデータを生成します](generate-test-data-using-an-aws-glue-job-and-python.md) + [SQL Server から PostgreSQL に移行する際に、PII データに SHA1 ハッシュを実装する](implement-sha1-hashing-for-pii-data-when-migrating-from-sql-server-to-postgresql.md) + [AWS Step Functions を使用して、サーバーレス Saga パターンを実装する](implement-the-serverless-saga-pattern-by-using-aws-step-functions.md) + [AWS CDK を使用して複数の AWS リージョン、アカウント、OU にわたって Amazon DevOps Guru を有効にすることで、運用パフォーマンスを向上させます。](improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.md) + [Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md) + [AWS Glue を使用して Apache Cassandra ワークロードを Amazon Keyspaces に移行する](migrate-apache-cassandra-workloads-to-amazon-keyspaces-by-using-aws-glue.md) + [複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md) + [AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する](optimize-multi-account-serverless-deployments.md) + [を使用して、検証、変換、パーティショニングで ETL パイプラインをオーケストレーションする AWS Step Functions](orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.md) + [Amazon Athena を使用して SQL で Amazon DynamoDB テーブルをクエリする](query-amazon-dynamodb-tables-sql-amazon-athena.md) + [AWS Fargate を使用して、イベント駆動型でスケジュール済みの大規模ワークロードを実行する](run-event-driven-and-scheduled-workloads-at-scale-with-aws-fargate.md) + [Amazon Cognito にカスタム属性を送信し、トークンに挿入する](send-custom-attributes-cognito.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md) + [AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md) + [自然言語を OpenSearch と Elasticsearch のクエリ向けにクエリ DSL に変換する](translate-natural-language-query-dsl-opensearch-elasticsearch.md) + [アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする](unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.md) + [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md) + [Amazon Bedrock エージェントを使用してテキストベースのプロンプトで Amazon EKS でのアクセスエントリコントロールの作成を自動化する](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md)