アマゾン ウェブ サービス (AWS) の Landing Zone Accelerator on AWS (LZA) ソリューションは、AWS のベストプラクティスと複数のグローバルコンプライアンスフレームワークに合わせて設計されたクラウド基盤をデプロイします。ワークロードが厳しく規制され、コンプライアンス要件が複雑なお客様は、LZA を使用してマルチアカウント環境をより適切に管理および管理できます。他の AWS サービスと連携して使用すると、35 以上の AWS サービスにわたる包括的なローコードソリューションが提供されます。 お客様は、 VMware Cloud on AWS を使用してオンプレミスの vSphere 環境を統合し、既存のワークロードをより迅速にクラウドに移行することができます。組織がこれらのクラウドサービスを活用している場合、VMware のワークロードをネイティブに管理された AWS サービスと統合することで、オペレーションオーバーヘッドを削減し、総所有コスト (TCO) を最適化できます。 このブログ記事では、LZA Landing Zone と VMware Cloud on the AWS 環境の統合に関する技術的な考慮事項について説明します。読者が VMware Cloud Software Defined Data Center (SDDC) の導入とベストプラクティス 、 VMware Cloud on AWS ネットワークアーキテクチャ 、および LZA の 導入 に精通していることを前提としています。 Connected VPC 用アカウントに関する重要な考慮事項 まず、SDDC の導入時に VMware SDDC に接続する仮想プライベートクラウド (VPC) に使用するアカウントを決定します。 このブログ記事では、開発アカウント、テストアカウント、本番アカウントをデフォルトで厳密に分離する LZA Landing Zone の例を紹介します。つまり、 AWS Transit Gateway のルーティングテーブル設定により、セキュリティ上の理由からこれらのアカウントは相互に通信できなくなります。この記事で説明するアーキテクチャ設計では、お客様の意図は、既存のセキュリティ仕様を尊重しながら VMware Cloud on AWS と LZA を統合することにあります。LZA 環境内で適用されるコンプライアンスは、自動的に VMware Cloud on AWS へ拡張されないため、VMware SDDC ワークロードに必要なコンプライアンス要件を満たすために、VMware Cloud 環境内で追加の手順が必要になる場合があります。 これらの考慮事項を念頭に置いて、この記事では AWS Control Tower を使用して作成された Organization の例を紹介します。この例では、接続された VPC ワークロードに使用する AWS アカウントを作成します。以下の図 1 は、このアカウントが「sddc」という名前の組織単位 (OU) と「SDDC-Team1」という名前の LZA アーキテクチャにどのように適合するかを示しています。ワークロードをさらに分離する場合は、必要に応じて同じ OU 内に追加のアカウントをデプロイできます。その後、専用の「 SDDC_Connected_VPC 」をこれらの AWS アカウントにデプロイできます。このアプローチにより、組織内のこの OU 内のすべての AWS アカウントに特定のサービスコントロールポリシー (SCP) を定義できます。これにより、VMware ワークロードで使用されるネイティブ AWS サービスを、他の LZA 環境から独立して構成できるようになります。 図1.ルートアカウントの下で組織単位 (OU) に構造化された AWS アカウント 導入したら、図 2 に示すような機能的なアカウントアプローチを使用して、さまざまなチームが「 SDDC_Connected_VPC 」に同時にアクセスできるようにしながら、特定のアカウントの特定のワークロードを分離する機能をサポートすることをお勧めします。下の図 2 は、LZA のデプロイ時に作成できるマルチアカウント構造の例を示しています。このマルチアカウント組織アプローチは、お客様が AWS Organizations サービス (OU と SCP) を活用して複数の AWS アカウントを一元管理する方法を示しています。 図２.LZA のリファレンスアーキテクチャでは、各チームが SDDC VPC に個別かつ並行してアクセスできるため、特定のアカウントの特定のワークロードを分離できる LZA と VMware Cloud との接続に必要な 3 つのコミュニケーションパス LZA を VMware Cloud on AWS SDDC と統合するためのアーキテクチャでは、ネットワークアーキテクチャを慎重に計画する必要があります。LZA を AWS 上の VMware Cloud と統合するための技術的要件は次のとおりです。 VMware Cloud on AWS SDDC ワークロードと AWS クラウドサービス間の通信を有効にします。例: Amazon Simple Storage Service ( Amazon S3 )、Amazon Relational Database Services ( Amazon RDS )、 Amazon FSx 、Amazon Elastic File System ( Amazon EFS ) など オンプレミスのデータセンターから VMware Cloud on AWS への VMware vMotion および VMware HCX ベースのワークロード移行に関する通信を可能にします。 AWS Network Firewall のパケット検査をサポートしながら、VMware Cloud on AWS SDDC からインターネットへの通信を有効にします。 これらの要件を満たすには、VMware Cloud on AWS と次の環境間の通信をサポートする 3 つの通信ネットワークパスを作成する必要があります。 1.オンプレミスのデータセンターから VMware Cloud on AWS SDDC への接続 2.LZA ワークロード AWS アカウントの VPC ( SDDC_Connected_VPC ) から VMware Cloud on AWS SDDC への接続 3.共有ネットワークアカウントにデプロイされた LZA Transit Gateway から、 リージョン内ピアリング を使用した VMware Transit Connect への接続 図3. LZA ネットワークアーキテクチャは、AWS Transit Gateway と VMware Transit Connect 間の接続アーキテクチャを特徴とする。ユーザーがインターネットゲートウェイあるいは AWS Transit Gateway を経由して SDDC_Connected_VPC に到達するオレンジ色の点線は、VMware Cloud on AWS SDDC および LZA からのすべての外部接続が、常に AWS Transit Gateway アタッチメントを使用して境界 VPC を通過する様子を示す パス 1: オンプレミスのデータセンターから VMware Cloud on AWS SDDC への接続 LZA と VMware Cloud on AWS をデプロイする場合、帯域幅の拡大、待ち時間の短縮、ユーザーの一貫したネットワークエクスペリエンスを実現するには、インターネット接続を使用しない、オンプレミス環境からクラウドへの専用接続が必要です。図 4 に示すアーキテクチャでは、可用性の高いハイブリッド接続を実現するために、冗長な AWS Direct Connect ネットワーク接続を使用します。 図4. AWS Direct Connect Gateway は、オンプレミスのデータセンターから LZA ネットワークアカウント経由で VMware Cloud on AWS アカウントへのハイブリッド接続をサポート さらに、マルチリージョン接続を可能にするために、AWS Direct Connect 経由のトランジット仮想インターフェイス (Transit VIF) でオンプレミス環境を AWS Direct Connect Gateway に接続します。この AWS Direct Connect Gateway は、1 つ以上のリージョンの LZA ネットワークアカウントにある AWS Transit Gateway に関連付けられます。 AWS Transit Gateway は高可用性設計がされているため、冗長性のために追加の Transit Gateway をデプロイする必要はありません。AWS Direct Connectと AWS Transit Gateway の詳細については こちら をご覧ください。 AWS Transit Gateway は、オンプレミス接続を提供するために、同じリージョン内の VMware Transit Connect との「リージョン内ピアリング」を使用して構成されています。VMware ワークロードとの通信に加えて、HCX ネットワーク拡張などの HCX 機能を使用して、レイヤー 2 ネットワークを既存のデータセンターから VMware Cloud on AWS SDDC に拡張できます。HCX を使用して移行された仮想マシンは IP アドレスとメディアアクセス制御 (MAC) アドレスを保持できるため、クラウドで実行中のワークロードにシームレスに移行できます。 1 つの AWS Direct Connect Gateway との異なる Gateway Association で同じルートをアドバタイズしないように注意する必要があります。つまり、VMware Cloud on AWS と AWS Transit Gateway との間のネットワークトラフィックは、データセンターと通信するときに同じルートを使用する必要があります。 パス 2: LZA ワークロードアカウント VPC から VMware Cloud on AWS SDDC への接続 LZA の「 SDDC_Connected_VPC 」は、SDDC と一緒にデプロイされた Elastic Network Interface (ENI) を使用して SDDC に接続されます。この「 SDDC_Connected_VPC 」を使用すると、SDDC で実行されている仮想マシンと AWS サービスを統合できます。この高スループットで低レイテンシーのリンクは、 Amazon EFS 、 Amazon FSx 、 Amazon S3 、 Amazon RDS などのデータ集約型サービスやレイテンシーの影響を受けやすいサービスを統合する場合に特に重要です。 また、「 SDDC_Connected_VPC 」を使用して、LZA アーキテクチャに従って、SDDC 内の VMware 仮想マシンのインターネット入力負荷分散用の Elastic Load Balancer を実行することもできます。VMware Cloud on AWS のワークロードをネイティブ AWS サービスで拡張する方法の詳細については こちら をご覧ください。 パス 3: 共有サービスへの接続とインターネットアウトバウンド接続 このアーキテクチャでは、「 SDDC_Connected_VPC 」へのトラフィックと、VMware Transit Connect リージョン内ピアリングと LZA AWS Transit Gateway ピアリングによるオンプレミスへの接続以外にも、他のすべてのトラフィックをリージョン内ピアリング経由で LZA AWS Transit Gateway に送信する必要があります。 これには、 Amazon Route 53 インバウンド DNS リゾルバーや他の VPC との通信など、LZA 内のすべての共有サービスへのトラフィックが含まれます。SDDC 内のワークロードのインターネット接続も、このリージョン内ピアリングを通過します。上記の図 3 は、AWS Transit Gateway と VMware Transit Connect 間の接続のアーキテクチャを示しています。VMware のブログ 「VMware Cloud on AWS の VMware Transit Connect イントラリージョンピアリング入門」 で、VMware Transit Connect から AWS Transit Gateway へのリージョン内ピアリングを設定する方法について説明しています。 ルートの伝播を コントロール して、エンドポイント VPC と LZA オペレーションアカウントのみが Transit Gateway 経由で VMware Cloud on AWS SDDC 環境と通信できるようにすることが重要です。LZA と VMware Transit Connect 間の通信を有効にするには、ルートテーブルを伝達する必要があります。 VMware Transit Connect マネージドプレフィックスリスト を使用していない限り、VMware Transit Connect はそのルートをデフォルトで LZA Transit Gateway に伝達しないことに注意してください。 この方法では、すべての受信トラフィックと出力トラフィックが境界ファイアウォールを通過して検査されます。図 3 の図のオレンジ色の点線は、VMware Cloud on AWS SDDC と LZA からのすべての外部接続が、常に AWS Transit Gateway アタッチメントを使用して境界 VPC を通過する様子を示しています。 SDDC の DNS 構成による通信プライバシーの保護 通信のプライバシーを確保するには、内部エンドポイントを使用して SDDC から AWS にデプロイされたワークロードとサービスに通信します。VMware Cloud on AWS vCenter マネジメントコンソールでは、LZA ランディングゾーンに設定されている Amazon Route 53 DNS リゾルバーの IP アドレスを入力できます。 まとめ この記事では、LZA Landing Zone で AWS を実行するネイティブ AWS サービスやインターネットとの通信を可能にしながら、VMware Cloud on AWS SDDC をデプロイするために使用可能なネットワークアーキテクチャについて説明しました。これにより、AWS ネイティブサービスを最大限に活用し、2つの異なるコンピューティング環境にワークロードをデプロイし、オペレーションオーバーヘッドコストを削減できます。 AWS Public Sector Blog ニュースレター を購読して、公共部門からの AWS ツール、ソリューション、イノベーションに関する最新情報をメールで受け取るか、 お問い合わせ ください。 この アンケート から AWS Public Sector Blog をお読みになってのご意見を、少しのお時間を割いて私たちに共有してください。アンケートからのフィードバックをもとに、読者の好みに合わせたコンテンツを作成していきます。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。

はじめに コンタクトセンターでは、プロンプトを使用して顧客とやり取りしたり、顧客から情報を入手したり、顧客に最新情報を提供します。プロンプトは録音されたオーディオファイルで、コールフローの中で再生されます。コンタクトセンターの管理者は、新しいプロンプトを追加したり、既存のプロンプトを変更したりして、ビジネスニーズに迅速に対応する必要があります。 多くのプロンプトを追跡、管理するのは時間がかかる作業です。複数のチャネル、複数の言語にわたってプロンプトを管理する場合、この作業はさらに複雑になります。加えてプロンプトを複数の環境全体にデプロイする場合、さらに複雑さが増します。手動でプロンプトを更新中に軽微なエラーが生じると、顧客へのメッセージの一貫性が失われ、顧客に混乱が生じ、問い合わせの誤ったルーティングにつながる可能性があります。Amazon Connect では、企業は Prompts API を使用して自動化ツールによりプロンプトをプログラム的に管理し、プロンプトの作成と管理のプロセスを合理化できます。 このブログ記事では、API オペレーションを使用して Amazon Connect のプロンプトを管理するウェブベースのアプリケーションをデプロイする方法について説明します。この記事では、プロンプトについての 6 つの API アクション (List Prompts、Create Prompt 、 Update Prompt 、 Describe Prompt、Delete Prompt、Get Prompt File) を使用します。 ソリューション概要 このソリューションは、AWS CloudFormation テンプレートを使用してデプロイされます。このテンプレートでは、 Amazon S3 バケットを作成し、すべてのアセットを Amazon CloudFront で利用します。ユーザーは Amazon CloudFront の URL を呼び出してウェブのユーザーインターフェイス (UI) を表示します。このUIで選択したプロンプトの API に基づいて、 Amazon Connect で適切なオペレーションが開始されます。 注: このサンプルプロジェクトは、検証の一環でデプロイするために設計されています。アイデンティティアクセス管理 (IAM) ポリシーの権限は最小の権限しか使用しませんが、デプロイされた Amazon CloudFront はパブリックにアクセス可能です。必要に応じて、 CloudFront ディストリビューションを保護 するための適切な対策を講じてください。 前提条件 このブログ投稿では、以下のサービスの使用について理解し、以下の条件を満たしていることを前提としています。 管理コンソール上とプログラム経由の両方で管理者アクセスを持つ AWS アカウント 既存の Amazon Connect インスタンス AWS IAM によりポリシーとロールを作成できること Amazon CloudFront でディストリビューションを作成できること Amazon S3 でバケットを作成できること AWS CloudFormation によりスタックを実行できること Connect API オペレーションを実行できる AWS IAM アクセスとシークレットキー認証情報 以下は、最低限必要なアクセス権限が設定されたサンプルポリシーです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:GetObject", "connect:DescribeInstance", "connect:UntagResource", "connect:ListPrompts", "connect:TagResource", "s3:ListBucket" ], "Resource": [ "arn:aws:connect:YOUR_REGION:YOUR_ACCOUNT_ID:instance/YOUR_INSTANCE_ID", "arn:aws:s3:::YOUR_S3_BUCKET_NAME/*", "arn:aws:s3:::YOUR_S3_BUCKET_NAME" ] }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "connect:CreatePrompt", "connect:UpdatePrompt", "connect:DescribePrompt", "connect:UntagResource", "connect:DeletePrompt", "connect:TagResource", "connect:GetPromptFile" ], "Resource": "arn:aws:connect:YOUR_REGION:YOUR_ACCOUNT_ID:instance/YOUR_INSTANCE_ID/prompt/*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "connect:ListInstances", "Resource": "*" } ] } ソリューションのデプロイ AWS マネジメントコンソールにサインインし、Amazon Connect インスタンスのあるリージョンを選択します をクリックし、AWS CloudFormation テンプレートを起動します 一意な スタック名 を設定します。（例 : prompts-api-web-ui ） IAM リソース作成承認のチェックボックスにチェックを入れます スタックの作成 を選択します。この AWS CloudFormation テンプレートがすべてのリソースを作成するには約10分程度時間が必要です。完了すると、ステータスが CREATE_COMPLETE に変わります。 作成されたスタックの 出力 セクションを開きます CloudfrontEndpoint の値をコピーします コピーしたURLをブラウザの新しいタブかウィンドウに貼り付け、CloudFront Web UI にアクセスします プロンプトの管理用 Web UI へのアクセス 初期設定 IAM ユーザーのアクセスキー ID を Access Key に、シークレットアクセスキーを Secret Key に、リージョンを Region に入力します。( アクセスキー ID とシークレットアクセスキーの作成方法 ) Amazon Connect インスタンスの ARN を Instance ARN に入力します( Amazon Connect インスタンスの ARN 確認方法 ) Save Configuration ボタンをクリックします Amazon Connect インスタンスでプロンプトを管理するためのソリューションのテスト 次にナビゲーションパネルから 6 つのプロンプトに関する API オペレーションをテストします。 1. List Prompts: プロンプトの一覧取得 ナビゲーションメニューから List Prompts を選択します Amazon Connect インスタンスのすべてのプロンプトが中央のパネルに表形式で一覧表示されます。結果はプロンプト名に基づいてソートできます。右側のパネルには、プロンプト ID、ARN、名前を含む JSON リストが表示されます Amazon Connect コンソールにログインし、両方のユーザーインターフェイスでプロンプトを確認します 2. Create Prompt: プロンプトの作成 ナビゲーションメニューから Create Prompt を選択します 一意なプロンプト名を Name に入力します 有効な説明を Description に入力します プロンプトの Amazon S3 URI を入力します (Amazon Connect インスタンスにインポートするプロンプトファイルの Amazon S3 ロケーション) Create Prompt を選択します。作成した新しいプロンプトが表と、更新された JSON の出力から確認できます。 Amazon Connect コンソールからも新たに作成したプロンプトが見えることを確認します 3. Update Prompt: プロンプトの更新 中央のパネルから更新するプロンプトファイル名を選択します ナビゲーションメニューから Update Prompt を選択します 名前や説明が既に入力されたポップアップウィンドウが表示されます ウィンドウで修正する値を入力し、 Update Prompt をクリックします。画像の例では、説明 (Description) を更新しています Amazon Connect コンソールからもプロンプトの説明が更新されたことを確認します 4. Describe Prompt: プロンプトの詳細確認 中央のパネルから確認するプロンプトファイル名を選択します ナビゲーションメニューから Describe Prompt を選択します 右のパネルの表示 (プロンプトの ARN、ID、Name、Description、Tags) が前のセクションで Update Prompt を実行した内容に更新されます 5. Get Prompt File: プロンプトの音声ファイルの取得 中央のパネルから再生、ダウンロードしたいプロンプト名を選択します ナビゲーションメニューから Get Prompt File ボタンをクリックします 右のパネルにプロンプトの署名付き URL を含んだ API レスポンスが表示されます 新しいタブでプロンプトの音声ファイルを再生します 6. Delete Prompt: プロンプトの削除 中央のパネルから削除したいプロンプトのファイル名を選択します ナビゲーションパネルから Delete Prompt ボタンをクリックします 削除確認のポップアップで Yes をクリックします プロンプトが削除されると、中央のパネルのプロンプト一覧と、右の JSON 出力結果のパネルが更新されます クリーンアップ 今後料金が発生しないように、このブログの手順で作成した Amazon S3 バケットのコンテンツをすべて削除してください。 Amazon S3 バケットを空 にし、 バケットを削除 します。 AWS CloudFormation スタックを削除 することで、作成されたその他すべてのリソースも削除できます。 結論 このブログ記事では、新しく提供された Amazon Connect Prompts API を使用してプロンプトをプログラムで管理する方法について、ウェブ UI の例を使用して示しました。お客様は API を使用して、Amazon Connect 内に保存されているプロンプトを抽出し、Amazon S3 バケットにバックアップできるようになりました。たとえば、新しく有名人を雇って録音した挨拶の音声など、既存のオーディオファイルをプログラムで既存のプロンプトと置き換えることができます。プロンプト変更のログは管理コンソール内で保存、表示されます。プロンプトの API 操作は、AWS CloudTrail、AWS CloudFormation、およびタグ付けをサポートしています。 関連リンク このソリューションの作成に使用されたテクノロジーや機能の詳細については、以下を参照してください。 Amazon Connect AWS SDK 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

はじめに このブログ投稿では、AWS ネイティブのオブザーバビリティツールを使用してモダンサーバーレスアプリケーションの現在の状態を測定する方法と、それを最小限の労力で開始する方法について紹介します。 Amazon CloudWatch や AWS X-Ray などのツールについて確認し、これらのサービスが、ログ、メトリクス、トレースの完全なオブザーバビリティに向けたアプリケーションのインストルメント化にどのように役立つかについて見ていきます。他の AWS サービスとのシームレスな統合についてや、カスタムダッシュボード、アラーム、異常検出などのアクセス可能な追加機能をどうすれば有効にできるかを学習できます。これらはすべて、コンプライアンスやセキュリティの要件を満たしながら実現されます。開始するにあたって必要な知識があることを確認するために、AWS オブザーバビリティツールを最大限に活用するためのトレーニングオプションについて説明します。 図 1: ネイティブツールによる AWS オブザーバビリティのベストプラクティス 次のセクションでは、さまざまなメカニズムやベストプラクティスについて説明します。 コーディングなしで簡単に開始可能 AWS オブザーバビリティツールは、サーバーレスアプリケーションのオブザーバビリティを開始するための、最も速くかつ最も簡単なオプションを提供します。それらのツールは AWS のサービスと連携するように特別に設計されており、簡単にセットアップおよび設定することができます。CloudWatch ではログの集約、メトリクスの収集、アプリケーションのトレースマップの作成を行うことができます。 AWS Lambda を使用している場合は、 Amazon CloudWatch Lambda Insights を使用して関数に関するメトリクスの取得を開始します。セットアップはすぐに終わり、追加のコーディングは不要です。必要になるのは、 Lambda コンソールから もしくは プログラムから 、各関数の [拡張モニタリング (Enhanced Monitoring)] を有効化することだけです。これにより、呼び出し率、所要時間、エラー数などの主要メトリクスが提供され、関数のパフォーマンスに関する洞察を得られます。さらに、CPU 時間、メモリ使用量、ネットワークパフォーマンスなどのシステムレベルのメトリクスも提供されます。これらのメトリクスを可視化するために、カスタムダッシュボードを作成してニーズに合わせてデータをさらに調整することができます。以下の画像は単一の Lambda 関数のメトリクスのダッシュボードを示しています。 図 2: CloudWatch Lambda Insights の単一の関数 (シングルファンクション) のパフォーマンスモニタリングダッシュボード 最新のイベントをより詳細に確認する必要がある場合は、ページ下部で最新の 1,000 回の呼び出しと最新の 1,000 個のアプリケーションログをすぐに確認できます。 図 3: CloudWatch Lambda Insights の呼び出しビュー 特に気になる呼び出しがあり、その関連するログを確認したい場合は、 Amazon CloudWatch Logs Insights ページを表示します。CloudWatch Logs Insights では、ユーザーはクエリを実行してログデータの検索や分析を行うことができます。調査したい呼び出し結果を選択すると、CloudWatch Logs Insights は結果を迅速に分析するための事前構築済みクエリを自動的に表示します。また、すぐに利用可能なクエリのセットも用意されており、必要に応じてカスタマイズすることができます。CloudWatch Lambda Insights と CloudWatch Logs Insights を一緒に使用すると、問題の根本原因を検出するまでの平均時間を短縮できます。このツールが提供する可能性を広げるには、 CloudWatch Lambda Insights の使い方に関するデモ をご覧ください。 図 4: Lambda 関数のログのヒストグラムを示す CloudWatch Logs Insights のクエリ結果 サーバーレスアプリケーションが AWS サーバーレスアプリケーションモデル (AWS SAM) で実行されている場合は、最小限の設定で メトリクス を有効化することができます。これにより、 Amazon CloudWatch Application Insights を使用して、機械学習で生成されたダッシュボードを調べ、メトリクスの異常やログエラーの検出など、モニタリング対象のアプリケーションにある潜在的な問題を明らかにすることができます。 CloudWatch Application Insights の紹介デモ を見て、その利点について理解を深めることができます。以下のスナップショットは、CloudWatch Application Insights により検出された Step Functions アプリケーションでの問題を、根本原因分析、およびキャプチャされたエラーログと共に示しています。 図 5: AWS SAM を使用した Step Functions アプリケーションで自動的に検出された問題を示す CloudWatch Application Insights ダッシュボード アプリケーションが Amazon Elastic Container Service (Amazon ECS) や AWS Fargate を使用したサーバーレスコンテナを実行している場合、 Amazon CloudWatch Container Insights の有効化 のみでメトリクスやログの使用を開始することができます。 CloudWatch Container Insights ツールを使用すると、コンテナ化されたワークロードとその基盤となるインフラストラクチャのパフォーマンスや状態をリアルタイムで可視化することができます。タスクやサービス、クラスターのレベルのメトリクスを確認できます。 CloudWatch Logs Insights と統合されているため、パフォーマンスログにアクセスして詳細を調べることができます。以下の図は、クラスターのパフォーマンスを示す CloudWatch Container Insights ダッシュボードです。 図 6: ECS Fargate クラスターのパフォーマンスメトリクスに関する CloudWatch Container Insights ダッシュボード Fargate を使用して Amazon Elastic Kubernetes Service (Amazon EKS) でサーバーレスコンテナを実行している場合にも、 CloudWatch Container Insights を活用することができます。この機能を設定するには、 CloudWatch エージェント もしくは AWS Distro for OpenTelemetry エージェント をインストールおよび設定します。Distro for OpenTelemetry の詳細については 公式ウェブサイト をご覧ください。 図 7: EKS Fargate クラスターのパフォーマンスメトリクスに関する CloudWatch Container Insights ダッシュボード CloudWatch Container Insights には、コンテナクラスターの論理分布をグラフィカルに表示する [コンテナマップ (Container Map)] が用意されています。メモリや CPU の使用率の異常値をすばやく識別できるように、各ノードの色はヒートマップを表しています。以下の画像では、同じクラスターに属する複数の名前空間が示されています。クラスターノードは他のノードと比較してメモリ使用率が最も高いため、黄色に変わっています。 図 8: EKS Fargate クラスターの CloudWatch Container Insights マップ表示 さらに、CloudWatch Container Insights には、マップ表示からリスト表示に切り替えるためのリソースビューが用意されています。このビューはメトリクスやログとシームレスに統合されています。[ログを表示 (View logs)] や [ダッシュボードを表示 (View dashboard)] をクリックすると、それぞれログやメトリクスのチャートが表示されます。以下の画像は、EKS クラスターのリソースとその CPU 使用率およびメモリ使用率のリストを示しています。 図 9: CPU およびメモリの使用率を示す EKS クラスターリソースビュー (緑色で強調表示されているのは [ログを表示 (View logs)] ボタンと [ダッシュボードを表示 (View dashboard)] ボタンで、CloudWatch Logs Insights と特定のログまたはメトリクスビューへさらに深く移動可能) このブログ投稿のこのセクションで見てきたすべてのツールは、AWS サービスがデフォルトで CloudWatch に公開している メトリクス や ログ を扱います。これにより、コーディングを必要とせずに、最小限の労力で、アプリケーションの重要なデータポイントの収集を迅速に開始することができます。 図 10: CloudWatch が各サーバーレスサービスに提供するメトリクスとログのオプションの概要 次のセクションでは、カスタムメトリクス、カスタムログ、およびトレースを取得するようにアプリケーションをインストルメント化した場合に、そこから追加の洞察を得る方法について見ていきます。 ニーズに合わせたインストルメンテーションによるオブザーバビリティのカスタマイズ アプリケーションのパフォーマンスモニタリング機能を拡張するにつれ、デフォルトのメトリクスとデフォルトのログが提供するものを超える洞察を得る必要が出てきます。AWS ネイティブのオブザーバビリティツールは、特別なニーズを満たし、カスタムメトリクスの作成やカスタムログの収集、分散トレーシングの設定を可能にします。オブザーバビリティを次のレベルに引き上げるためにアプリケーションをインストルメント化する方法を見ていきます。 AWS Lambda のインストルメント化 ログ アプリケーションログのインストルメント化は、数行のコードを追加することで実現できます。たとえば、 Node.js の場合、コンソールオブジェクトのメソッドの使用、もしくは stdout または stderr に書き込みを行う任意のロギングライブラリの使用というオプション があります。Lambda は、追加の設定の必要なく、これらの関数ログを CloudWatch に自動的に送信します。 メトリクス Lambda からカスタムメトリクス を収集するベストプラクティスは、 EMF (Embedded Metric Format) を使用して CloudWatch Logs に非同期に公開を行うことです。EMF により、CloudWatch Logs が自動的にログからメトリクスを抽出し、アラームやダッシュボードを作成できるようになります。EMF を使用すると、実行時間を長くする PutMetricData API を Lambda 関数が呼び出す必要がなくなります。関数の実行時間を短縮することでランタイムコストが削減され、パフォーマンスが向上します。 Amazon では、EMF を簡単に使い始められるように、Node.js、Python、Java、および C# 用の オープンソースクライアントライブラリ を提供しています。代わりに、定義済み JSON フォーマットに従って PutLogEvents API を使用することで、 手動でログを生成する ことも可能です。 この Lambda ロギングとカスタムメトリクスの操作 に関するブログ投稿は、Lambda がデフォルトで提供する最も重要なメトリクスや、EMF を使用しカスタムメトリクスを活用してアプリケーション固有の情報を取得する方法を確認するのに役立ちます。アプリケーション固有の情報からは、ログやメトリクスを取得することで、パフォーマンス関連のデータのみに頼ることなく優れた洞察を得ることができます。 EMF の使用を開始するにあたり、 AWS Serverless Observability Workshop では、Lambda での EMF によるロギングメトリクスの処理について詳しく学ぶためのハンズオンを提供しています。 トレース Lambda での X-Ray トレースの開始 は、[設定 (Configuration)] の [アクティブトレース (Active tracing)] ボタンを切り替えるか、プログラムでそれを実行するだけで行うことができます。その結果、Lambda 関数は自身をトレーシング用にインストルメント化します。トレースを下流の他の Lambda 関数や AWS サービスに伝搬させるには、コードを追加する必要があります。それには 2 つのオプションが利用可能です。 – Distro for OpenTelemetry による Lambda トレーシングの設定 – X-Ray SDK ( Node.js , Python , Java など) Powertools for AWS Lambda によるベストプラクティスの導入の簡素化および加速 開発チームには、Amazon のオープンソースプロジェクト Powertools for AWS Lambda を使用して、Lambda のオブザーバビリティのベストプラクティスを実装することをお勧めします。Powertools for AWS Lambda では、構造化ロギング、EMF メトリクス、分散トレーシング用のユーティリティが提供されているため、オブザーバビリティを実装するためのコードを簡単に記述し、ベストプラクティスを遵守することができます。 たとえば、 アプリケーションログの相関 ID を実装する 場合、Powertools を使うと関数のパフォーマンスに影響を与えずにそのプロセスが簡略化することができます。Powertools は Python 、 Java 、 TypeScript 、 .NET で利用可能です。 サーバーレスコンテナ (Fargate を使用した ECS/EKS) のインストルメント化 Amazon EKS は、Kubernetes コントロールプレーン用の CloudWatch エージェントをインストールすることなく CloudWatch Logs と統合しています。この Amazon EKS コントロールプレーンのロギングにより、監査 (audit) ログと診断 (diagnostic) ログが CloudWatch Logs に直接提供されるため、クラスターを実行する際のセキュリティを確保できます。 CloudWatch Container Insights を使用すると、Amazon ECS、Amazon EKS、AWS Fargate で実行されているコンテナ化されたアプリケーションのパフォーマンスを収集、分析、および可視化できます。Container Insights では Kubernetes podの CrashLoopBackOff エラーのような診断情報も提供されるため、問題をより迅速に切り分け、調査し、解決するのに役立ちます。 異なるソースからデータやログを収集し、それらを統合して CloudWatch Logs、Amazon S3、Amazon Relational Database Service (Amazon RDS) などの複数の宛先にルーティングするには、 Fluent Bit をお勧めします。Fluent Bit は軽量のオープンソースマルチプラットフォームログプロセッサーで、Docker や Kubernetes と完全な互換性があります。また、パフォーマンスが大幅に向上するため、CloudWatch Container Insights のデフォルトソリューションとして Fluent Bit を使用することをお勧めします。 Amazon EKS 用 CloudWatch Container Insights における Fluent Bit 統合の詳細についてはこの ブログ投稿 をご覧ください。 次のセクションでは、ネイティブのオブザーバビリティツールを使用することですぐに利用可能なその他の機能について見ていきます。 すぐに使える高度な機能 AWS オブザーバビリティツールには、自動化されたカスタムダッシュボード、アラーム、異常検出、サードパーティツールとの統合など、すぐに使える高度な機能が搭載されています。 アプリケーションの運用における修正を行うには、アプリケーションのメトリクスに基づいて設定可能な閾値でトリガー可能な CloudWatch アラーム を使用することをお勧めします。たとえば、CPU 使用率が 80% に達したら Amazon ECS クラスターをスケールアウトするようなアラームを作成することができます。 サーバーレスアプリケーションのボトルネックを特定するには、X-Ray を使用してトレース結果を視覚的に表現したトレースマップを生成することをお勧めします。それにより、エラーが発生しているノード、レイテンシーの大きなコネクション、もしくは失敗したリクエストなどを特定することができます。 以下の画像は X-Ray トレースマップ (訳注：2023 年 11 月に、X-Ray サービスマップと CloudWatch ServiceLens マップは CloudWatch コンソール上で統合され X-Ray トレースマップとなりました) の要素を示しています。このマップにより、アプリケーションの特定のノードにある問題を簡単に特定することができます。図のように Lambda 関数を選択すると、より詳細なメトリクスを取得できます。レイテンシー、リクエスト、障害のチャートが表示されます (もしくは特定のトレースの詳細やキャプチャされたログに移動するかもしれません)。これにより、マップ内で特定された問題とアプリケーションログを関連付けて、考えられる根本原因と是正方法を迅速に判断することができます。 図 11: Lambda 関数の詳細を示す X-Ray トレースマップ (訳注：2023 年 11 月に、X-Ray サービスマップと CloudWatch ServiceLens マップは統合され X-Ray トレースマップとなりました) 特定のトレースを絞り込むには、[トレースを表示 (View traces)] に移動します。これにより、トレースのクエリとフィルタリングを行うことができる [トレース (Traces)] コンソールが表示されます。フィルタリングに応じて、一連のトレースがコンソール下部に表示されます。いずれかのトレース ID をクリックすると、選択したトレースに関するトレースマップ、セグメントタイムライン、およびログが表示されます。これは、トレース結果とログの関連付けを単一のビュー内で行い、調査中の問題の潜在的な根本原因を迅速に特定できる強力なツールです。 図 12: 単一のビューで潜在的な相関関係に対するセグメントタイムラインやログを示すトレースの詳細 この例と X-Ray トレースマップの設定方法の詳細については、 Well-Architected サーバーレスアプリケーションに関するブログ投稿 、もしくは One Observability WorkShop の ServiceLens セクション をご覧ください。 次のセクションでは、成果を達成する方法、コストを最適化する方法、および複数ある CloudWatch のツールの中でどこにどれだけの支出があるのか、詳細に把握する方法について詳細を把握する方法について説明します。 AWS ネイティブのオブザーバビリティツールによるコスト効率化 AWS ネイティブのオブザーバビリティツールは、長期的な契約やライセンスなしで使用を開始できる「従量課金 (pay-as-you-go)」の価格モデルを提供しています。これにより、予算にあわせてコストを柔軟に調整できます。メトリクス、ログ、トレースに対するコスト最適化オプションを見ていきましょう。 メトリクス メトリクスを扱う際には、 AWS 無料利用枠 に含まれる基本的なモニタリングメトリクスがあります。Lambda の拡張モニタリングを有効にして CloudWatch Lambda Insights を使用し、ビジネスやアプリケーションのカスタムメトリクスを作成する場合には、作成されたメトリクスに関する料金が発生します。 カスタムメトリクスは時間ごとに案分計算されるため、Lambda 関数の呼び出し回数が 1 時間あたり 1 回未満の場合には、呼び出しが行われた時間に対してのみ請求が行われます。 メトリクスは設定した 名前空間 、 メトリクス名 、 ディメンションセット ごとに作成されます。新しい組み合わせはそれぞれ新しいメトリクスとして記録されるため、ディメンションをどの程度細かく定義するかに注意してください。 例えば、以下のプロパティを持つカスタムメトリクスを公開するとします: Dimensions: Env=Prod, Geo=EMEA, Unit: Count, Timestamp: 2023-09-14T12:30:00Z, Value: 120 Dimensions: Env=Dev, Geo=AMER, Unit: Count, Timestamp: 2023-09-14T12:31:00Z, Value: 130 Dimensions: Env=Prod, Geo=LATAM, Unit: Count, Timestamp: 2023-09-14T12:32:00Z, Value: 93 Dimensions: Env=Staging, Geo=APAC, Unit: Count, Timestamp: 2023-09-14T12:33:00Z, Value: 91 これらはすべて一意のディメンションセットを持っているため、4 つの異なるメトリクスとしてカウントされます。 カーディナリティの高いシステムでは、カスタムメトリクスのコストを最適化するオプションの 1 つは、情報をディメンションセット以外のプロパティに保存することです。EMF (Embedded Metric Format) を使用すると、追加のプロパティをログに記録することができます。これにより、CloudWatch Logs Insights のクエリを通じてアクセス可能な、本来の高いカーディナリティのコンテキストが CloudWatch Logs に保存されます。 コスト削減のもう 1 つの機会は、定期的にはモニタリングされていないものの根本原因分析や個別のシナリオのためにはまだ必要となるようなメトリクスを特定することです。これらのメトリクスはログとしてのみ保存し、必要なときにのみクエリを実行するようにします。料金は取り込まれたログとオンデマンドで実行されたクエリに対してのみ発生し、メトリクスに対しては発生しません。あとでそれらのログのメトリクスを有効にする必要がある場合は、 メトリクスフィルター を使用すればログデータからメトリクスを生成することができます。 必要な時間だけこの機能を有効化してからそのあとでメトリクスフィルターを削除すれば、不要なカスタムメトリクスの使用やコストを回避できます。 ログ CloudWatch ログのコストを最適化するには、ログ取り込み料金が最も高いロググループに注目します。これにより、ログレベルを評価し、必要に応じて調整することで料金を最適化することができます。この AWS ナレッジセンターの記事 の手順に従って、コストの多いロググループを特定してください。 ログの保存ポリシーを最新に維持しておくことは、ログアーカイブの不要なコストの削減につながります。デフォルトでは、CloudWatch ログ保持ポリシーは「失効しない (Never expire)」に設定されているため、ログを無期限に保持する必要がない場合は、この設定を変更する必要があります。この ブログ投稿 は、ロググループの保持ポリシーを自動的に更新し続ける方法を紹介しています。 CloudWatch Logs Insights でクエリを実行すると、スキャンされるデータのサイズに応じて料金が発生します。そのため、分析コストを削減するには、クエリを短時間で実行するようにしてください。 トレース AWS X-Ray トレースのコストを最適化するには、アプリケーションや環境ごとに適切なサンプリングルールを選択します。広範囲にわたるトレースでは月額コストが増加するため、サンプリングレートを引き上げるかどうかを判断するには、ユースケースごとに評価を行う必要があります。たとえば、開発環境のように一般的にはトラフィックが少ない環境では、潜在的な問題を捉えるためにサンプリングレートを高く設定することが費用対効果の高い選択肢となる可能性があります。トラフィックの多い環境では、サンプリングレートを低くしても、潜在的な問題を捉えるには十分なデータが得られます。 AWS 請求コンソールツール 請求サイクルの終了前にコストの急増や変化を認識しておくと、タイムリーな是正措置を講じることができます。CloudWatch と X-Ray の 請求アラート を設定すると、料金が特定の目標予算を超えた場合にアラームが送られます。 コストが増加した場合、AWS では CloudWatch の料金を把握するためのコストと使用状況レポート (CUR) を提供しています。これにより、詳細を把握してコストの増加原因を特定し、必要に応じて調整を行うことができます。AWS ではコストと使用状況レポートを使い始めるための CUR ライブラリを提供しています。このライブラリには CloudWatch コストに対するクエリサンプル が含まれています。 次のセクションでは、CloudWatch ネイティブツールを活用して、さまざまな標準や要件への準拠を維持しながらセキュリティ体制を改善する方法について説明します。 コンプライアンス、セキュリティ、およびデータ保護 CloudWatch のコンプライアンスやセキュリティにおける重要な側面は、AWS のさまざまなコンテナ化されたマイクロサービスやサーバーレスアプリケーションからログとメトリクスを収集・集約・要約できることです。Container Insights は、Amazon ECS、Amazon EKS、Amazon Elastic Compute Cloud (Amazon EC2) 上の Kubernetes プラットフォーム、および Lambda 関数の CloudWatch ログで利用できます。このデータを一元管理することで、 CloudWatch ダッシュボード を使用してインフラストラクチャやアプリケーションの包括的かつ統合されたビューを維持できるようになり、潜在的なセキュリティ脅威やコンプライアンス違反の検出や対応が容易になります。 ここで、お客様が他の AWS サーバーレスサービスと共に CloudWatch をどのように活用したかに関するケーススタディをいくつかご紹介します。 トムソン・ロイター: Amazon CloudWatch を使用してフェイルオーバー時間を 30 分から 3 分に短縮 Indusface: サイバーセキュリティプロバイダー Indusface は、AWS 上のビジネスクリティカルなアプリケーションに対して 99.99% のアプリケーションファイアウォール稼働時間を保証します CloudWatch はまた、トラフィックの異常な急増やリソース使用率、コンプライアンス管理やセキュリティモニタリングのためのAPI 呼び出しパターンなど、特定の閾値や条件が満たされた場合に、リアルタイムの通知や自動応答を提供します。このプロアクティブなアプローチにより、潜在的なセキュリティリスクがより重大な問題に発展する前にそれを特定および是正することができます。さらに、CloudWatch は AWS リソースの設定を継続的にモニタリングし記録するサービスである AWS Config との統合をサポートしており、全体的なコンプライアンス体制を評価し、確立済みのベースラインからの逸脱を検出するために必要な可視性や洞察を提供します。 堅牢な分散トレーシングシステムである X-Ray は、リクエストとレスポンスに対するエンドツーエンドの可視性を提供することで、開発者がサーバーレスアプリケーションをリアルタイムに分析およびデバッグし、クラウドのコストとパフォーマンスの両方のメトリクスをモニタリングできるようにします。ただし、アプリケーションデータへのこのレベルのアクセスには、厳格なセキュリティ対策とコンプライアンス標準への遵守が必要です。 CloudWatch と X-Ray は、堅牢なアクセス制御メカニズムによる複数の保護レイヤーを実装することでデータのセキュリティを保護します。 AWS Identity and Access Management (IAM) を使用すると、誰が CloudWatch や X-Ray のデータにアクセスして特定のアクション (アラームの作成や変更、メトリクスやトレースの表示、ログへのアクセスなど) を実行できるかを指定する詳細なアクセス許可やポリシーを定義できます。このきめ細かなアクセス制御により、権限のある人のみが機密データにアクセスできるように制御できるため、不正アクセスや潜在的なデータ侵害のリスクが軽減されます。 CloudWatch と X-Ray はいずれも、保存時と転送中の両方のデータの暗号化をサポートしており、 AWS Key Management Service (AWS KMS) を活用して機密情報を不正アクセスから保護し、データセキュリティに関する業界のベストプラクティスを確実に遵守します。CloudWatch と X-Ray はまた、HIPAA、SOC、PCI などを含む 複数の AWS コンプライアンスプログラムの一部でもあります。CloudWatch のコンプライアンスとセキュリティの使用についての詳細は、AWS 全般のリファレンスの Amazon CloudWatch のコンプライアンス検証 、 Amazon CloudWatch のセキュリティ 、 AWS X-Ray のコンプライアンス検証 および AWS X-Ray でのセキュリティ をご覧ください。 コンプライアンスとセキュリティの議論をする上では、データ保護についてもよくテーマに上がります。 CloudWatch ログデータ保護 は、パターンマッチングと機械学習モデルを使用して機密データを検出するのに役立ちます。CloudWatch Logs は、マネージドデータ識別子を使用することで、クレジットカード番号や金融、医療、AWS シークレットキー、デバイスの IP アドレスや MAC アドレス、特定の国や地域のパスポート番号などの PII や PHI のデータを検出できます。 CloudWatch ログ内の機密データを検出するには、データ保護ポリシーを作成する必要があります。ポリシーを設定すると、以下のように CloudWatch ロググループで機密データの検出とカウントを確認できるようになります。 図 13: CloudWatch Logs で検出された機密データ ここで、CloudWatch Logs Insights を使用してロググループにクエリを実行すると、以下の図にあるように機密データがマスクされていることがわかります。ここでは、顧客の氏名、電子メール、クレジットカードのみがデータ保護ポリシーで機密データとして設定されています。 図 14: CloudWatch Logs Insights の「マスクされた」機密データ データ保護の実装の詳細については、 CloudWatch Data Protection workshop をご覧ください。 最後のセクションでは、CloudWatch、X-Ray、および AWS ネイティブのオブザーバビリティについて詳しく学び、お客様とお客様のチームを次のレベルに引き上げるために利用できるさまざまなオプションについて説明します。 開始方法 – アクセス可能なトレーニングリソース CloudWatch と X-Ray の学習をより簡単かつアクセスしやすいものにするために、AWS では以下のリソースを提供しています。 CloudWatch と X-Ray の公式ドキュメントは、非常に重要な出発点となります。このドキュメントには CloudWatch の包括的な概要、その機能、およびサービスの開始方法が記載されています。ドキュメントは最新の変更や改善を反映するように定期的に更新され、ユーザーが常に最も正確で最新の情報を得られるようにしています。 AWS Skill Builder の AWS Observability コース では、モニタリングの核となる原則、CloudWatch を使用してアラームを生成する方法、およびメトリクスを可視化し分析する方法について掘り下げています。 よりソーシャルかつ協調的なアプローチを好む学習者には、 AWS re:Invent 、 AWS Summit 、 AWSome Day などの AWS イベントに参加することは非常に有益です。これらのイベントは、CloudWatch、X-Ray、その他の AWS サービスの最新の進歩について学び、ワークショップに参加し、他の専門家とのネットワークを築く機会を提供します。さらに、AWS ユーザーグループに参加したり、 AWS デベロッパーコミュニティ などのオンラインフォーラムに参加したりすることで、学習者は最新のトレンド、ベストプラクティス、実際のユースケースについて常に情報を得ることができます。 AWS トレーニングと認定 は、開発者、アーキテクト、運用などの様々な役割にあわせた複数のコースを備えた有料のクラスルームトレーニングアプローチであり、学習者が自分の職務に関連する知識とスキルを確実に習得できるようにします。AWS トレーニングと認定のクラスはさまざまな言語で世界中で提供されており、トレーニングプログラムとサービスは AWS の専門家によって構築されています。 AWS トレーニングパートナー (ATP) は、既にトレーニングパートナーを配置している場合や、オンデマンドのクラスルームやデジタルサービスにトレーニングパートナーを組み込みたい場合の代替手段となるものです。ATP は AWS が作成したトレーニングを提供するために AWS により選ばれており、AWS にクラウドネイティブアプリケーションを移行もしくは構築するスキルの開発に役立ちます。 ハンズオン学習には、AWS ソリューションアーキテクト主導のものもセルフペースのものもあります。 AWS One Observability Workshop や EKS Observability では、AWS リソースのデプロイやセットアップに関する包括的なステップバイステップガイドを取り扱っています。 ベストプラクティスや FAQ を確認するには、 Practices FAQs – Amazon CloudWatch や AWS X-Ray – FAQ をご覧ください。 最後に、 CloudWatch Quick Start は CloudWatch や X-Ray などのクラウドネイティブのオブザーバビリティツールがインフラストラクチャ、サーバーレス、アプリケーションモニタリングなどでどのように機能するかについてのすべての学習およびトレーニングリソースにアクセスするためのワンストップガイドになっています。 まとめ AWS ネイティブのオブザーバビリティツールは、オブザーバビリティへの取り組みとベストプラクティスの採用に向けた最速かつ最も簡単な道筋を提供します。CloudWatch と X-Ray が提供する統合およびすぐに使用できる機能により、サーバーレスアプリケーションをゼロから理解するためのツールが手に入ります。ワークロードが成長するにつれて、AWS オブザーバビリティツールには、サーバーレスデプロイの複雑さを簡素化し、アプリケーションのさまざまな領域が望みどおりの結果をもたらしているかどうかを確認するためのカスタマイズに必要な機能が備わっています。これらはすべて、各業界セグメントのセキュリティや規制を遵守しながら実現されます。AWS オブザーバビリティツールを使い始めるために、リソースやオンラインコース、ブログ投稿、ハンズオンワークショップが豊富にあります。それらはチームが自信や知識を得てアプリケーションパフォーマンスやビジネス目標を改善するのに役立ちます。 著者について Esteban Guevara Esteban Guevara は DevOps と AWS ネイティブのオブザーバビリティソリューションを専門とするテクニカルアカウントマネージャーです。Esteban は、お客様のオブザーバビリティと AWS クラウドジャーニーを支援することに情熱を注いでいます。彼は Enterprise On-Ramp サポートプログラムに 2022 年の開始から携わってきました。 Doyita Mitra Doyita Mitra はアマゾンウェブサービスのソリューションアーキテクトで、分散システム、モニタリング、オブザーバビリティの分野に興味を持っています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

サーバーレス環境でマイクロサービスベースのワークロードを実行しているお客様は、必要なデータが数百または数千のコンポーネントに分散されている場合があるため、インシデントのトラブルシューティングに問題を抱えることがよくあります。このブログ投稿では、 Amazon CloudWatch ServiceLens (※訳注)と AWS X-Ray を使用してサーバーレスワークロードの平均解決時間 (MTTR、障害からの復旧や障害の影響の軽減にかかる平均時間) を短縮する方法について説明します。モニタリング戦略の成功にはオブザーバビリティの 3 つの柱 (メトリクス、ログ、トレース) のすべてが必要です。それが成功すれば、1 つのビューからそれらの 3 つの柱を元に洞察を得ることができます。 ※訳注：CloudWatch ServiceLens マップと X-Ray サービスマップは 2023年11月に CloudWatch コンソール内で X-Ray トレースマップに統合されました。 依存関係の理解 CloudWatch ServiceLens は、分散環境を可視化してサービス間の依存関係を理解するのに役立ちます。メトリクス、ログ、トレースがひとつのサービスマップ (※訳注：現 トレースマップ) にまとめられるため、 コンポーネント間の統合に焦点を当てること 、および問題が発生した際にそれを正確に特定することができます。リソースやインストルメント (計装) されたアプリケーションは有向グラフ上にノードとして表示され、ノード間のエッジはそれらの間で発生するトランザクションを表します。問題が発生しているノードにはエラーの種類に応じて色付きのアウトラインが表示されます。これは、アーキテクチャ内で障害の発生しているポイントや現在アラーム状態にあるポイントを強調表示するのに役立ちます。 図 1: CloudWatch ServiceLens マップ (※訳注：現 トレースマップ) デフォルトでは、各ノードのサイズやノード間のエッジは受信しているリクエストの数を表します。これを変更するには歯車アイコンを選択して [設定 (Preferences)] ダイアログボックスを開き、サイズ設定の基準となる代替メトリクス ([レイテンシー (Latency)] など) を選択します。ノードを選択するとパネルが開き、時間の経過に伴うレイテンシー、リクエスト、障害を示す追加メトリクスや、ログ、トレース、およびより詳細なダッシュボードへのリンクが表示されます。 図 2: DynamoDB テーブルのメトリクス このパネルには、そのリソースに関連するアラートも表示されます。以下の画像では、DynamoDB テーブルに対する 2 つのアラートが現在アラーム状態にあることがわかります。 図 3: DynamoDB テーブルのアラート サービスマップ (※訳注：現 トレースマップ) に戻って、障害が発生しているノードの 1 つに注目し、[接続を表示 (View connections)] を選択してその特定のリソースに対するすべての受信リクエストおよび送信リクエストに焦点を当ててみましょう。あるいは、 X-Ray グループ を使用してサービスグラフ内のノードのサブセットに焦点を当てることもできます。さらに詳しく知りたい場合は、 グループとそのユースケース に関する過去のブログ記事をご覧ください。 図 4: PetSearch マイクロサービスに対する受信リクエストおよび送信リクエスト 上の画像から、バックエンドの PetSearch マイクロサービスにリクエストを送っているノードは 3 つあり、そのうちの 2 つでのみ問題が発生していることがわかります。これらのエッジのうち 1 つを選択すると、そのパスに沿ったトラフィックについて要約した [応答時間分布グラフ (Response time distribution graph)] を含むパネルが表示されます。レイテンシーについてのトラブルシューティングを行う場合には、応答時間が遅いことを示すグラフの一部を強調表示して、[フィルタリングされたトレースを表示 (View filtered traces)] ボタンを押し、選択された時間枠内のトレースのリストを取得できます。この場合、フロントエンドの PetSite サービスからの 24% のエラー率の方が気になるので、[24% Faults (5xx)] の横にあるチェックボックスを選択して [フィルタリングされたトレースを表示 (View filtered traces)] を押します。 図 5: 応答時間分布 これにより新しいページが表示されます。必要に応じてクエリをさらに絞り込むことができます。テーブルから最初のトレースを選択すると、[トレースの詳細 (Trace details)] ページが表示されます。 図 6: トレースの詳細 [セグメントのタイムライン (Segment Timeline)] を使用すると、分散システム全体で何が起こったのかや、各レスポンスのステータスやリクエストへの応答にかかった時間を明確に把握できます。タイムラインからセグメントを選択すると、詳細情報を含むパネルが表示されます。[例外 (Exceptions)] タブでは、障害の根本原因が認可エラーにつながる権限の問題であることを確認できます。このページには、そのトレースに関連するすべてのサービスのログメッセージの相関リストも表示されるため、複数の異なるロググループのログを 1 か所で確認することができます。 AWS X-Ray との統合 ServiceLens は、X-Ray からのトレースを使用してサービスマップ (※訳注：現 トレースマップ) を構築し、サービス間の依存関係を把握します。キャプチャしたいインタラクションによっては ワークロードのインストルメント化 が必要になる場合もありますが、多くの AWS サービスは (インストルメント化不要で) すぐに使用可能な X-Ray 統合をサポートしており、オプトインするだけで使用できます。X-Ray 統合に関する全リストについては AWS X-Ray と他の AWS サービスとの統合 をご覧ください。 AWS Lambda 関数で X-Ray を有効にするには AWS Lambda コンソール を開きます リストから関数を選択します [設定 (Configuration)] タブを選択し、[モニタリングおよび運用ツール (Monitoring and operations tools)] を選択します [その他の監視ツール (Additional monitoring tools)] の [編集 (Edit)] を選択し、[AWS X-Ray] の [アクティブトレース (Active tracing)] を切り替えます 図 7: AWS Lambda モニタリングおよび運用ツール 図 8: AWS X-Ray の有効化 Lambda 関数のアクティブトレースを有効にするページでは、[拡張モニタリング (Enhanced monitoring)] という見出しで CloudWatch Lambda Insights を有効にするオプションも表示されます。この機能はシステムレベルのメトリクスを収集、集計および要約するために使用されます。詳細については、 AWS Lambda エラーをモニタリング する方法について詳しく説明した過去のブログ記事をご覧ください。 まとめ この記事では、CloudWatch ServiceLens と AWS X-Ray を使用して分散ワークロードをモニタリングおよび観察する方法について、サービス間の統合に焦点を当てて説明しました。問題についてのアラートを受け取った際には、ServiceLens は関連するトレースの掘り下げに役立ちます。それにより、障害についての診断を行い、通常の業務に戻るための計画に取り掛かることができるようになります。 モニタリングとオブザーバビリティについて、もっと知りたいですか？ AWS オブザーバビリティベストプラクティス と AWS ネイティブツールを使用して AWS Lambda ワークロードをモニタリングする ためのガイドをご覧ください。AWS ネイティブツールもしくはマネージドオープンソースツールを使用したガイド付きハンズオン体験については、 One Observability Workshop をご覧ください。 著者について Erich Wolz Erich Wolz はコロラド州デンバーを拠点とするシニアテクニカルアカウントマネージャーで、ネットワークエンジニアリングと Python 開発のバックグラウンドを持っています。 Jesse Sullivan Jesse Sullivan はテネシー州クラークスビルを拠点とするシニアテクニカルアカウントマネージャーで、クラウドネイティブのモニタリングやオブザーバビリティを専門としています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

2023 年 5 月 3 日のアップデート このアップデートにより、Amazon Route 53 Application Recovery Controller のゾーンシフトは、以下の AWS リージョン でも利用できるようになりました。 詳しくは、更新された What’s New ポスト または ゾーンシフト のドキュメントでご確認ください。 本日は、 Elastic Load Balancing (ELB) に組み込まれた Amazon Route 53 Application Recovery Controller (Route 53 ARC) の新機能であるゾーンシフトをご紹介します。ゾーンシフトを実行することで、単一のアベイラビリティゾーン (AZ) 内のアプリケーション障害からの迅速なリカバリを実現することができます。 この記事では、ゾーンシフトの仕組みと、ロードバランサーのヘルスチェック機能などを利用する高い耐障害性を持つマルチ AZ アプリケーションにおける信頼性戦略へどのように適合するかを説明します。さらに、AWS サービスによるマルチ AZ アプリケーションの設計と監視、ゾーンシフトについて、AWS re:Invent 2022: Operating highly available multi-AZ applications のセッションを補足として確認頂く事ができます。 以下の AWS リージョンで、本日からプレビューでゾーンシフトの利用を開始できます： 米国東部 (オハイオ州)、米国東部 (バージニア州) 、米国西部 (オレゴン州) 、アジア太平洋 (ジャカルタ) 、アジア太平洋 (シドニー) 、アジア太平洋 (東京) 、ヨーロッパ (フランクフルト) 、ヨーロッパ (アイルランド) 、ヨーロッパ (ストックホルム) 。ゾーンシフトは、クロスゾーン負荷分散がオフになっているアプリケーションロードバランサー (ALB) およびネットワークロードバランサー (NLB) で使用することができます。ゾーンシフトを使用する際、追加の料金はかかりません。 AZ を利用したフォールトトレラントサービスの構築 AWS サービスや AWS 上で耐障害性の高いアプリケーションを運用するお客様が採用している、信頼性の高いシステムを設計するための重要な戦略は、複数の独立した レプリカ を使用し、一つのレプリカが故障した場合の計画を立てることです。この戦略では、システム全体を複数のアプリケーションレプリカ (通常は 3 つ) として構築し、一度に 1 つのレプリカが故障することを想定して計画を立てます。そして、1 つのレプリカが一時的にオフラインになった場合でも、負荷を処理できるように、各レプリカに十分な容量を用意する必要があります。 次に、すべての一般的な障害モード (つまり、デプロイの失敗、応答待ち時間の長さ、エラー率の上昇) が 1 つのレプリカ、または 1 つの 障害コンテナ に封じ込めるようにします。そして、万が一レプリカに障害が発生した場合は、そのレプリカを一時的にシステムから切り離すことで、顧客への正常なサービスを回復することができます。正常なサービスが回復したら、故障したレプリカを調査して修復することができます。障害の原因は、ソフトウェアの導入、オペレーターのミス、ハードウェア障害、電源障害、ネットワーク機器の障害、証明書の有効期限切れ、さらにはデータセンターの障害など、さまざまです。障害が発生するのはまれですが、1 つのレプリカにとどめるように制御し、迅速に回復できるようにすることで、より信頼性の高いシステムを運用できるようになります。 この戦略はリカバリ指向であり、調査や修復よりもまずリカバリを優先させることを意味します。まず、障害のあるレプリカを切り離し、アプリケーションを正常な状態に回復させます。その後、根本的な原因を調査して障害のあるレプリカを修復し、レプリカをサービスに戻すことができます。根本原因を特定する前に、まず復旧できることを確認することで、平均復旧時間 (MTTR) を短縮し、顧客に対する影響期間を短縮します。 この戦略の重要な部分は、2 つのレプリカが同時に、または連携して故障する可能性を最小化することです。そのためには、レプリカが可能な限り独立して動作するようにする必要があります。これには通常、一度に 1 つのレプリカだけにソフトウェアを展開する、一度に 1 つのレプリカだけに変更を加える、レプリカ間で制限を分散させる (または「ジッタリング」する) などの一連の対策が必要です。これは、ファイルシステムのサイズ、ヒープメモリの制限、証明書の有効期限、スケジュールされたジョブの実行時間などの運用上の項目です。そのようにすることで、復数のレプリカで同時に問題が発生することを防ぎます。例えば、レプリカに異なる制限を設定することで、制限に関連する問題の初期発生を 1 つのレプリカに抑え、一時的な切り離しを可能とします。 レプリカを独立した物理的なフォールトコンテナに配置すると、システムはこのレプリカ戦略からさらに多くの恩恵を受けることができます。AWS で構築する場合、物理的なフォールトコンテナとして AZ を使用します。AZ を利用することで、レプリカを十分な距離 (通常は数マイル) 離れた物理データセンターに配置し、多様な電力、接続性、ネットワークデバイス、および洪水対策ができるようにすることができます。この場合も、2 つのレプリカで同時に発生するイベントの数を最小限に抑え、相関性のある障害を防止することを目的としています。 ハード障害からの復旧 アプリケーションを複数の独立したレプリカとして構築し、AZ にあわせて配置し、1 つのレプリカの損失を処理するのに十分な容量をプロビジョニングしたら、次のステップは、AZ またはゾーンレプリカ内の異常なレプリカを迅速に検出して切り離すメカニズムをセットアップすることです。ALB または NLB を使用する場合、AZ の障害に対する防御の最前線はヘルスチェックです。ヘルスチェックでは、ロードバランサーは一定の間隔で各ターゲットを調査し、正常なレスポンス、つまり HTTP ステータス 200 があるかどうかをチェックします。正常でないレスポンスやタイムアウトがあった場合、障害が検出され、通常1分以内に、リクエストは障害のあるターゲットから正常なターゲットへルーティングされます。さらに、各ロードバランサーノードは Amazon Route 53 のヘルスチェックによって健全性をチェックされ、AZ 内のターゲットがすべて正常でない場合は、ロードバランサーの DNS から該当の AZ が削除されます。 ターゲットのヘルスチェックは、明らかに検出可能な障害、つまりターゲットインスタンスの故障のようなハードな障害に対して迅速かつ効果的です。その他のハード障害の例としては、接続を受け付けなくなったアプリケーションや、ヘルスチェックの応答で HTTP ステータス 500 を返しているアプリケーションなどがあります。ヘルスチェックが最も効果的になるようにするために、ディープヘルスチェックハンドラーを設計すると便利です。これにより、アプリケーションをより徹底的にテストすることができます。しかし、ディープヘルスチェックは、過負荷のような状況で発生しうる誤った検知を回避する必要があるため、慎重に検討する必要があります。詳しくは、Amazon Builder’s Library の優れた記事 ヘルスチェックの実装 を参照してください。 ハードな障害を検出するために使用できるもう 1 つの機能は、最小健全性ターゲットです。ALB と NLB は最近この機能を追加し、ターゲットグループまたは AZ 内の正常なターゲットの最小数を指定できるようになりました。これで、1 つのゾーンレプリカに障害が発生し、設定した最小容量の閾値を下回った場合、そのレプリカはヘルスチェックに失敗し、トラフィックは他のレプリカにルーティングされます。これにより、障害が発生したレプリカが過負荷状態になるのを防ぐことができます。 グレー障害からの回復 ディープヘルスチェックを実施していても、より曖昧で断続的なグレー障害モードが発生し、検出が困難な場合があります。例えば、ゾーン展開の後、レプリカは正常であるとプローブに応答するかもしれませんが、顧客に影響を与える機能的なバグがあるかもしれません。また、新しいコードのパフォーマンスが低下していたり、断続的にクラッシュしているにもかかわらず、チェックすると正常に見えるほど応答性が良い場合もあります。パケットロスや断続的な依存関係の障害など、インフラに関わる微妙な問題も、ヘルスチェックを通過しても応答が遅くなる可能性があります。 このようなグレー障害の場合、ゾーンレプリカ全体のカスタマーエクスペリエンスを調査できる、人間または自動化されたより高度なメカニズムを用意することが有効です。そして、ゾーンレプリカがグレー障害を経験しているとき、人または自動化されたシステムによって、その AZ を切り離す事ができます。AWS は長年この 2 本立ての戦略を使ってきましたが、今回、お客様が AWS でアプリケーションを実行する際に、同様の戦略を採用しやすくしました。ELB には、クロスゾーン負荷分散をオフにした ALB と NLB の両方について、ゾーンシフトを開始するためのオプションが追加されました。このビルトインリカバリーコントロールにより、アプリケーションに不具合が生じた場合に、AZ から一時的に離れることができます。 まず、クロスゾーン負荷分散がオフになっていることを確認します。次の図に示すように、これにより、ロードバランサーノードは、ローカル AZ 内のターゲットにのみリクエストをルーティングするように設定されます。こうすることで、各ゾーンの障害コンテナをロードバランサーとそのターゲットに合わせ、1 つのゾーンのレプリカ内の障害を簡単に検出できるようになります。ALB と NLB の両方でクロスゾーン負荷分散をオフにすることができます。 図 1. クロスゾーン負荷分散オン/オフ時のルーティング方法 さて、ELB でゾーンシフトを開始することができます。ゾーンシフトの制御は組み込まれているため、設定は不要ですが、 AWS Identity and Access Management (IAM) ユーザーまたはロールがゾーンシフト API を呼び出す権限を持っていることを確認する必要があります。ゾーンシフトでは、単純な StartZonalShift API コールを使用して、不健全なゾーンレプリカからお客様のトラフィックを一時的に移動させることができます。他のレプリカが正常で、顧客にサービスを提供できる容量があれば、数分以内に顧客体験を回復することができます。その後、顧客が快適にアプリケーションを使い続けている間に、異常なゾーンレプリカのデバッグと修復に取り組むことができます。修復したゾーンにアプリケーションのワークロードを戻す準備ができたら、ゾーンシフトをキャンセルするか、単に期限切れにすることができます。 ゾーンシフトはどのように機能するのか？ ゾーンシフト API を呼び出して AZ からトラフィックを移動するよう要求した場合、どのように動作するのでしょうか？次の図に示すように、クロスゾーン負荷分散をオフにして、NLB の背後にある 3 つの AZ で動作するウェブサービスを考えてみましょう。NLB の各ゾーンエンドポイントで合成監視をしているので、各 AZ のリクエストの成功率とレイテンシを見ることができます。 Amazon CloudWatch ダッシュボードでは、顧客リクエストの 1 % (P99) に 1 秒のレイテンシーが発生していることがわかります。AZ ごとのメトリクスを見ると、AZ3 では同様にレイテンシが増加しており、AZ1 と AZ2 ではレイテンシは変化せず、通常の範囲 (~60ms) であることがわかります。何が原因でレイテンシーが上昇しているのかはまだ分かりませんが、問題は AZ3 のレプリカに含まれていることが強く示唆されます。リクエストは成功し続けているので、ヘルスチェックは通過していますが、このようなレイテンシの増加は顧客に問題を引き起こす可能性があります。 図 2. CloudWatch Synthetics が 1 つの AZ でレイテンシの上昇を検出した 3-AZ ロードバランサーアーキテクチャー 図 3. 顧客と AZ ごとのビューを持つ運用中の CloudWatch ダッシュボード。レイテンシーメトリクスは、カスタマーエクスペリエンスと 1 つの AZ でレイテンシーの上昇を示す Webサービスに1つのAZを切り離しても、処理するのに十分な予備の計算能力がある場合、まず回復するために AZ3 からトラフィックをシフトし、その後問題を調査することができます。これはどのように機能するのでしょうか？ゾーンシフトを開始すると、顧客のトラフィックを AZ3 から遠ざけるように要求します。ゾーンシフトにより、AZ3 のロードバランサーのヘルスチェックが失敗し、その IP アドレスは DNS から削除されます。この結果、新しい接続は他の AZ のみに向かうことになります。クライアントの動作や接続の再利用状況によっては、既存の接続が枯渇するまでに時間がかかることがありますが、通常は数分で完了します。 StartZonalShift API コールを使用すると、AZ からトラフィックをシフトさせることができ、ゾーンシフト ID を返します。ゾーンシフトによってトラフィックが AZ から一時的に切り離されます。一時的な期限の設定が必要となります。これはロードバランサーの永続的な設定変更ではありません。StartZonalShift API を使用した次の CLI コマンドの例は、12 時間で期限切れになるように設定されたゾーンシフトを開始します： aws arc-zonal-shift start-zonal-shift \     --resource-identifier arn:aws:elasticloadbalancing:ap-southeast-2:123456789012:loadbalancer/net/zonal-shift-demo/1234567890abcdef \     --away-from apse2-az3 \     --expires-in 12h \     --comment "Anomaly detected in AZ3, shifting away proactively" 図 4. 同じ 3-AZ ロードバランサーアーキテクチャで、障害のある AZ からトラフィックを遠ざけるためにゾーンシフトが有効になっている。 ゾーン・シフトが有効になり、CloudWatch のダッシュボードでは、顧客のエンドポイントで ResponseTime メトリックが正常に戻っていることが示されています。モニタリングでは、AZ3 でレイテンシーの問題が残っていますが、その AZ は顧客のトラフィックを受けなくなりました。また、ProcessedBytes が AZ1 と AZ2 で上昇し、AZ3 で低下していることも確認できます。 図 5. ゾーンシフトにより、障害を受けた AZ からリクエストを遠ざけることで、顧客エクスペリエンスが回復したことを示す運用中の CloudWatch ダッシュボード 顧客は再び通常のサービスを受けられるようになったので、今度は AZ3 で問題を調査します。最近 AZ にデプロイされたのではないでしょうか？他のチームメンバーがその AZ のレプリカに影響を与えるような作業をしていたのでしょうか？あるいは、 AWS Health Dashboard に表示されている AZ3 に進行中の問題があるのでしょうか？障害の理由が何であれ、問題を調査し、対処するための時間ができました。必要な期間だけゾーンシフトを維持することができます。 トラブルシューティングのための時間を確保するためにゾーンシフトを延長する必要がある場合は、簡単な UpdateZonalShift API 呼び出しで実行できます。次の CLI コマンドの例では、ゾーンシフトが今から 4 時間後に期限切れになるように設定しています： aws arc-zonal-shift update-zonal-shift \     --zonal-shift-id <zonal-shift-id> \     --expires-in 4h AZ3 のゾーンレプリカが回復したら、ゾーンシフトをキャンセルするか、自動的に期限切れになるのを待つことができます。キャンセルするには、CancelZonalShift API コールにゾーンシフト ID を指定して使用します。たとえば、次の CLI コマンドを使用します： aws arc-zonal-shift cancel-zonal-shift \     --zonal-shift-id <zonal-shift-id> Amazon Virtual Private Cloud (Amazon VPC) エンドポイントサービスを使用している場合、Amazon VPC エンドポイントサービスに関連付けられたリージョンの NLB のゾーンシフトを開始すると、ゾーンシフトが対応するすべての Amazon VPC エンドポイントにも自動的に適用されることに注意してください。これにより、AWS PrivateLink によって NLB に到着するトラフィックもゾーンシフトを考慮するようになります。 単一 AZ アプリケーションの障害に対応するための準備 さて、回復のためにゾーンシフトを開始する方法について説明しましたが、この戦略を効果的に準備し適用する方法について見ていきましょう。 障害を検出する アプリケーションに異常なゾーンレプリカが1つでもあると、それを検出できるようにする必要があります。これを確実に行うには、アプリケーションの健全性を示すゾーンごとのシグナルが必要です。これを行うには、いくつかの補完的な方法があります。 パッシブ・モニタリング　 ほとんどのアプリケーションは、致命的なエラー、例外、応答時間、HTTP ステータスコード (HTTP ステータス 200 や HTTP ステータス 500 など) を追跡するメトリクスを作成します。メトリックのディメンションにホストの AZ の情報を含めると、単一のゾーンレプリカの問題を示す集約メトリックを作成することができます。さらに、ALB と NLB の両方が、UnhealthyHostCount や ProcessedBytes などの AZ 単位のメトリックを提供します。ALB は、HTTP ステータス 500 エラーの AZ ごとのカウントも提供します。これらのメトリクスはすべて判断材料になります。 アクティブモニタリングと外形監視　 パッシブ・モニタリングに加えて、アプリケーションに対して合成リクエストを作成し、カスタマーエクスペリエンスをより完全に把握できるようにすると便利です。Amazon CloudWatch Synthetics は、エンドポイントに対して選択したコードを定期的に実行し、メトリクスを作成できるマネージド型カナリアサービスを提供します。ALB と NLB の両方が、標準のリージョンの DNS 名に加えて、ゾーン DNS 名を提供します。これにより、以下のように、各ゾーンのアプリケーションレプリカの応答性と信頼性を個別に監視するカナリアを作成することができます： ELB name: zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com Zone 2A: ap-southeast-2a.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com Zone 2B: ap-southeast-2b.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com Zone 2C: ap-southeast-2c.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com CloudWatch Synthetics はマネージドサービスであり、また別 AWS リージョンにカナリアを配置する事も可能な為、アププリケーションが実行されているリージョン内で障害が発生しても、継続してモニタリングが可能となります。 追加入力 　アプリケーションの健全性に関するシグナルを直接監視することに加えて、AWS Health Dashboard からの通知など、他のインプットを評価することが有用な場合があります。Health Dashboard が AZ の問題を示すとき、必ずしも自分のアプリケーションが影響を受けていることを意味しないことに注意してください。このため、通常は、アプリケーションのゾーンレプリカの健全性も直接測定するのがベストです。 ダッシュボードと集計 　AZ からトラフィックを移動させるための一般的な出発点は、その種のトラフィック移動を自動化しようとする前に、オペレータが手動でアクションを起こすこと (つまり、人間が決定を下すこと) です。人間のオペレーターにとって、先に示した例のようなシンプルな CloudWatch ダッシュボードは、AZ の単一の全体的なビューを提供し、迅速な決定を下すのに役立つことができます。CloudWatch のダッシュボードはグローバルであることに注意してください。そのため、作成後はどの AWS リージョンからでもアクセスすることができ、耐障害性を高めることができます。 ゾーンシフトのベストプラクティス ゾーンシフトは、稼働中のアプリケーションから容量を奪う可能性があるため、本番で使用する場合は注意が必要です。ここでは、ゾーンシフトを安全に使用するための準備と安全確認について説明します。 プリスケールキャパシティヘッドルーム 　リカバリ指向の戦略をとる場合、1 つのゾーンレプリカをオフラインにしてもピークトラフィックに対応できるような十分なヘッドルームを備えた計算容量を事前にスケーリングすることをお勧めします。ゾーンシフトは、この点をさらに重要視しています。ゾーンシフトを開始すると、ロードバランサーの後ろから 1 つの AZ のキャパシティが一時的に削除されます。つまり、ゾーンシフトを使用する前に、すべての AZ に十分なキャパシティがあることを確認する必要があります。クロスゾーン負荷分散をオフにした 3-AZ の ALB または NLB の場合、1 つの AZ からシフトすると、他の 2 つの AZ のそれぞれで約 50 ％の追加負荷が予想されます。2AZ のロードバランサーの場合、もう一方の AZ の負荷が 2 倍になることを想定しておく必要があります。 キャパシティを事前にスケーリングする代わりにスケーリングポリシーを使用することにした場合、使用するポリシーとメトリックについて慎重に考えてください。例えば、平均 CPU 使用率は、ゾーンシフトに対応して増加をもたらさないかもしれません。それは、Auto Scaling グループのある部分が CPU 使用率を下げると、別の部分が上昇するからです。 すべてのゾーンレプリカが正常で、トラフィックを受けていることを確認します 　ゾーンシフトは、ある AZ にあるアプリケーションレプリカを異常とみなすことで機能します。したがって、レプリカの 1 つに影響を与えるイベントが発生する前に、他のゾーンレプリカでターゲットが正常で、トラフィックを積極的に受け入れていることを確認する必要があります。この認識を維持するために、ここに示すダッシュボードの例のように、異常なターゲットと AZ ごとの bytesProcessed の両方の ELB メトリクスを含むダッシュボードを作成します。 事前にテストする 　どのような回復メカニズムでもそうですが、必要なときに機能するかどうかを確認するために、定期的に練習する必要があります。実際のイベントの前に、理想的にはテスト環境と本番環境の両方でゾーンシフトを使用することをお勧めします。テストすることで、運用上のイベントが発生したときに、慣れと自信を持つことができます。 API または CLI を使用する練習をする 　障害を素早くうまく処理するためには、通常、最も早く、最も信頼性の高い、依存関係の少ないツールを使用することをお勧めします。使いやすいように、ゾーンシフトは AWS マネジメントコンソール で利用できます。ただし、迅速な復旧が不可欠な場合は、復旧手順書で、可能であれば、事前に保存された AWS 認証情報を使用して、 AWS コマンドラインインターフェース (AWS CLI) または zonal shift API コールを使用するようにオペレータに伝えることをお勧めします。 ゾーンシフトでトラフィックを一時的にしか移動させない 　アプリケーションの異常なゾーンレプリカが修復されるとすぐに、そのレプリカをサービスに戻す必要があります。これにより、アプリケーション全体が完全に冗長で弾力性のある状態にできるだけ早く戻るようにします。 慎重に自動化する 　次のステップとして、ゾーンシフトの自動化に取り組むのは自然な流れです。これは合理的ですが、エッジケースについては慎重に考えてください。たとえば、トラフィックが急激に増加してアプリケーションが過負荷になった場合、通常、AZ を切り離すことは望ましくありません。また、追加する自動化は、ゾーンシフトが始まったときに他のレプリカが正常であることを確認するように注意してください。 第二のリージョンから監視する 　 隣接する AWS リージョンからアクティブモニタリングを行うことを検討してください。近くのリージョンはアプリケーションの顧客体験をよりよく表すことができ、別のリージョンから監視することで、アプリケーションと監視の間で運命が共有されるという問題が軽減されます。 ゾーンシフトの試行 Route 53 ARC のゾーンシフトを始めるのに役立つように、サンプルの NLB アプリケーションでこの機能を試すために、ダウンロードしてデプロイできる AWS CloudFormation テンプレートの例が含まれています。 AWS Fault Injection Service  (AWS FIS) を使用して、グレー障害イベントをシミュレートし、回復するためにゾーンシフトを開始することができます。このテンプレートは、このブログ記事で説明したものと同様のアーキテクチャを作成します。ダウンロードには以下が含まれます： クロスゾーン負荷分散をオフにした 3-AZ NLB Auto Scaling グループ。1MB のファイルを提供するために Apache Web サーバーを実行しているホスト NLB 経由で 1MB ファイルをポーリングする地域限定の CloudWatch Synthetics カナリア (顧客の視点) 3 つの AZ ごとの CloudWatch Synthetics カナリアは、特定のゾーン NLB エンドポイントに対して 1MB ファイルをポーリングします (AZ ごとの視点) 異常検知に基づく CloudWatch アラーム すべてのデータを 1 つのビューで表示する CloudWatch ダッシュボード AWS FIS 実験テンプレート： 1 つの AZ にグレー障害 ( 2 %のパケットロス) を 30 分間注入する。 この CloudFormation テンプレートを使って、自分でゾーンシフトを試してみてください。以下の手順で、回復志向の戦略がどのように機能するかを確認することができます： ゾーンシフトが利用可能な任意の AWS リージョンに CloudFormation テンプレート をダウンロードし、デプロイします。 AWS Management Console で、CloudWatch ダッシュボードを開き、データパターンが確立されるのを待ちます。 FIS ダッシュボードを開き、1 つのゾーンレプリカでパケットロスを注入する実験 PacketLossOnInstancesIn-AZ-B を開始します。 CloudWatch ダッシュボードに戻り、3 ～ 5 分待ってから、カスタマーエクスペリエンスの ResponseTime メトリックの変化を確認します。2 つの AZ は正常な応答時間を持ち、1 つの AZ は応答時間が上昇し、問題が発生しているゾーンレプリカを示すはずです 応答時間が上昇しているゾーンレプリカの AZ ID をメモまたはコピーします Route 53 ARC コンソールを開き、 Zonal shift を選択します Start zonal shift を選択し、 Select the Availability Zone ドロップダウン・メニューで、CloudWatch ダッシュボードからメモまたはコピーした AZ ID を選択します Resources テーブルで、CloudFormation スタックから NLB の ARN を選択します Set zonal shift expiration で、6 hours を選択します Acknowledgement チェックボックスを選択し、 Start を選択します ここで、CloudWatch ダッシュボードに戻ります。カスタマーエクスペリエンスの列が回復を示す一方、問題のあるゾーンレプリカのカナリアが問題を示し続けていることがわかるはずです。また、 BytesProcessed グラフで、トラフィックが 1 つのレプリカから離れ、他のレプリカに向かって移動していることがわかるはずです。 これで、FIS 実験をキャンセルするか、期限切れにすることができ、影響を受けるゾーンレプリカの問題は解決します。Route 53 ARC コンソールで、開始したゾーンシフトを選択し、 Cancel zonal shift を選択します。 最後に、CloudFormation スタックを削除して、ゾーンシフトの実験からリソースをクリーンアップします。 ゾーンシフトを使用するには、zonal shift API に対するパーミッションが必要です。Elastic Load Balancing のマネージドポリシーである ElasticLoadBalancingFullAccess または AdministratorAccess を持つ IAM ユーザーとロールには、アクセスが自動的に付与されます。また、独自の IAM ポリシーで arc-zonal-shift API アクションへのアクセスを明示的に付与することも可能です。 現在利用可能 Route 53のARC ゾーンシフトは、クロスゾーン負荷分散をオフにした ALB と NLB で、冒頭に記載した AWS リージョンで利用可能になりました。今後、より多くの AWS リージョンとロードバランサーの構成がサポートされる予定です。ゾーンシフトをお試しいただき、ご意見をお聞かせください！ Gavin McCullagh Gavin は AWS レジリエンスインフラストラクチャおよびソリューションチームのプリンシパルエンジニアです。2011 年から AWS に勤務し、Amazon の内部負荷分散や DNS ソリューションのほか、Amazon Route 53 、Amazon Route 53 リゾルバー、Amazon Route 53 アプリケーションリカバリコントローラーなどの AWS サービスにも携わっています。Gavin は、ダブリン大学で化学の学士号と博士号を、アイルランド国立大学メイヌース校のハミルトン研究所でコンピューターサイエンスの修士号を取得しています。 Deepak Suryanaryanan Deepak は AWS レジリエンスインフラストラクチャおよびソリューションチームのゼネラルマネージャーです。2011 年から AWS に勤務しており、Amazon Route 53 Application Recovery Controller などの機能を使用して、マルチ AZ やマルチリージョンのアプリケーション向けにリカバリ指向のアーキテクチャを運用するなど、AWS で耐障害性の高いアプリケーションを構築する方法について顧客と定期的に話し合っています。Deepak はマドラス大学とノースカロライナ州立大学で工学の学位を、デューク大学で経営学修士号を取得しています。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。

昨今の空港においては、フライトに搭乗するまでの時間をより楽しく、充実したものにするために、さまざまな環境・設備が用意されています。搭乗直前まで必要なものを小売店で買い込んだり、空港ラウンジでくつろいだり、コンコースに立ち並ぶ数多くのレストランやバーを利用することもできます。 旅行者は日常的にこうしたサービスを利用しているが、必ずしも利便性が高いとは限りません。長いレジの列や待ち時間のために、旅行者が不満を感じたり、不必要な時間のロスに遭遇することが数多くあります。 最近の調査 では、旅行者が空港の小売店で買い物をする際、「お得感」を差し置いて「利便性」を最も重要な要素として挙げる傾向が強まっているのも驚くことではありません。 一方、IATA は、 航空旅客数が 2025 年までに 2022 年の総数を超えると予測しています 。このことは、空港の小売店やラウンジがより忙しくなり、旅行者を効率的に出入りさせなければならないというプレッシャーが高まることを意味します。 Amazon One や Amazon による Just Walk Out テクノロジーのような新しいテクノロジーは、空港の小売業者が航空旅行者の急増に対応し、多忙な航空旅行者に、より迅速で便利な旅のナビゲーションを提供するのに役立ちます。 新たな利便性の追加 空港の売店、レストランやバー、空港ラウンジなど、Amazon One は旅行者に新たな利便性をもたらします。Amazon が提供するこの手のひらベースの ID・決済サービスは、日常の行動を簡素化するように設計されており、Amazon One デバイスに手のひらをかざすだけで、支払い、会場への入場、本人確認ができます。 Amazon One を使えば、面倒な手続き、待ち時間を避けて、素早く出入りができます。そして、荷物を気にしながらカードやデジタル財布を探す代わりに、手のひらを使って次のことができます： 商品のお支払い 年齢制限のある商品を購入する際の年齢確認 特典の獲得と交換 空港ラウンジへの迅速な入室 これはより迅速なサービス、より短い列、そしてより良い空港体験を意味します。 また、企業にとって業務効率、訪問数、顧客スループット、収益の向上を意味します。 Amazon One の仕組み Amazon One は、手のひらを使って支払いや入力、本人確認ができる無料の非接触型サービスです。Amazon One を初めて利用するユーザーは、クレジットカードまたはデビットカード、Amazon アカウント、携帯電話番号をオンラインで事前登録することができます。このプロセスの所要時間は約 1 分です。その後、参加店舗で Amazon One デバイスに手のひらをかざすと、数秒で登録手続きが完了します。 Figure 1 – High-level overview of how Amazon One works 空港の店舗でより迅速な支払いが可能 フライトの前に旅行の必需品を買い込みたいとき、あるいはちょっとした贈り物を買いたいとき、ゲートに向かう途中にある多くの小売店のひとつに立ち寄りたくなります。しかし、搭乗時間が数分後に迫っている場合は、素早く出入りする必要がありますが、Amazon One なら手のひらだけで数秒で支払いが完了するので、財布や携帯電話を取り出す必要がありません。 また、 Amazon の Just Walk Out テクノロジー と組み合わせることで、店舗運営者はさらに便利な 小売旅行体験 を提供できます。 Just Walk Out テクノロジーは、 コンピューター ビジョン、センサー フュージョン、ディープ ラーニング を組み合わせたもので、消費者にチェックアウトの手間をかけずに、迅速でスムーズな買い物方法を提供します。 買い物客は来店し、必要なものを手に取り、出て行くだけです。 まず旅行者は、入場ゲートでAmazon One デバイスに手のひらをかざすことで、Just Walk Out 対応店舗に入ることができます。そして店内に入ったら、棚から必要なものをすべて手に取って店を出ることができます。Amazon One のプロフィールにリンクされたクレジットカードには、店舗を出た後に購入した商品の代金が請求されます。つまり、サービスがより迅速になり、旅行中のストレスが 1 つ減ります。 食品サービスおよび小売事業を展開する OHM Concession Group は最近、カンザスシティ国際空港全域の店舗で Amazon One および Just Walk Out テクノロジーを導入しました。 OHM Concessions Group の社長兼 CEO のミラン・パテル氏は、「空港での特典や直前の旅行商品の入手は手間がかからないに越したことはありません。」と述べています。 「Just Walk Out テクノロジーと Amazon One により、旅行者は迅速かつスムーズな店舗体験を通じて、必要なものをこれまで以上に簡単に入手できるようになります。 この経験は、より多くの旅行者に、より早くサービスを提供することを可能にします。」 The &Go store at Kansas City International Airport operated by OHM Concession Group 食事体験を効率化 空港には、離陸前に簡単な食事やドリンクを楽しめる幅広いレストランやバーが揃っています。 ただし、ピーク時間帯には、混雑したダイニングルームでは迅速なサービスが提供できない可能性があります。 遅れそうなとき、従業員が会計を処理するのを待っているとイライラすることがあります。 Amazon One を備えたレストランの場合、手のひらをデバイスの上にかざすだけで食事の支払いが完了し、次のステップに進むことができます。 手のひらで年齢を確認する 空港のバーやレストランは、ピーク時には人気スポットとなりますが、お気に入りの酒類などの飲み物を購入するには、年齢確認のため、運転免許証を出さなければならないことがよくあります。余分なステップがあると取引が遅くなり、周りの人を長く待たせることになります。Amazon One とその 年齢確認機能 の提供開始によって、この状況は変わりつつあります。登録が完了し、政府発行の身分証明書と自撮り写真をリンクさせたら、デバイスに手のひらをかざすだけで 21 歳以上であることを示すことができます。支払いの準備ができたら、再び手のひらを Amazon One デバイスにかざすだけで、注文の代金が請求されます。すべてのプロセスは迅速かつシームレスです。バーテンダーはより多くのゲストに素早くサービスを提供することができます。 空港ラウンジへの迅速なアクセス フライト前の空港ラウンジは、慌ただしい旅行者にとって、穏やかで静かなオアシスとなります。しかし、ラウンジに入る前に長い列に並んだり、会員ステータスを確認したりするのは、骨の折れるほど時間のかかる作業です。今後 ラウンジの混雑が予想される ため、この問題はさらに悪化する可能性があります。Amazon One は、旅行者がラウンジの入場ゲートをこれまで以上に素早く通過できるようサポートします。例えば、Amazon One を使えば、ラウンジでくつろぎながら、手のひらをかざすだけで会員ステータスを確認し、ラウンジに入り、サービスを享受することができます。 ラウンジへの簡単なアクセス、バーでの手間のかからない年齢確認、レストランでの素早いチェックアウト、スムーズな店舗での買い物など、これらは Amazon One テクノロジーが、増え続ける飛行機旅行者の生活をより便利にするほんの一部です。 結論 旅行者は、チェックイン、保安検査、搭乗など、すでに多くの「必要な」列に並んでおり、さらなる遅延や摩擦ポイントに敏感です。これが、「シームレスでスムーズなショッピング」が旅行者の 満足度を高める要因 の 1 つとなっている理由です。Amazon と AWS は空港、レストラン、小売店と提携し、旅のあらゆるステップで旅行者のエクスペリエンスを変えるお手伝いをしています。 Amazon One を消費者に届けましょう。 消費者にシームレスなサービス、より迅速な支払い、パーソナライズされたエクスペリエンスを提供したいと考えている企業は、Amazon One がどのように役立つかについて詳しく知るために 当社にお問い合わせください 。 著者について Armughan Javaid Armughan Javaid “AJ “は、Amazon の Just Walk Out テクノロジーの戦略、開発、市場参入チームを率いています。AJ は、旅行業界のリーダーたちが、旅全体でゲストのエクスペリエンスを革新するのをサポートする役割を担っています。AJ は、小売業界とオムニチャネル・コマース・テクノロジーの幅広い経験を活かし、旅行業界のリーダーたちが業務効率を高め、ビジネス成果を上げられるよう支援しています。以前は、AJ がアマゾン ウェブ サービス（AWS）のプラクティスリーダーとして、クラウド変革プログラムに取り組んでいました。AJ はワシントン D.C. エリアのAmazon HQ2 を拠点としています。 翻訳はソリューションアーキテクトの程が担当しました。原文は こちら です。

本日、 AWS IoT FleetWise が車両のビジョンシステムデータ収集をサポートすることを発表します。この機能により、顧客はカメラ、LiDAR、レーダー、その他のビジョンサブシステムからのメタデータ、オブジェクトリストと検出データ、画像やビデオを収集できます。現在プレビューで利用可能なこの新機能は、既存の AWS IoT FleetWise の機能を拡張し、顧客がデータからより多くの価値とコンテキストを抽出し、より接続された、便利な車両を構築できるようにします。 現代の車両には複数のビジョンシステムが搭載されています。ビジョンシステムの例には、先進運転支援（ADAS）のユースケースを可能にする周囲視界カメラとレーダーの配列や、半自動運転のユースケースで運転者の注意を支援する運転者およびキャビン監視システムが含まれます。これらのシステムのほとんどは、車両上でセンサーフュージョンやAI/ML による推論のための洗練されたアルゴリズムを使用して、ある程度の計算を行います。 ビジョンシステムは、構造化された（数字、テキスト）および非構造化された（画像、ビデオ）形式で大量のデータを生成します。この課題により、車両の干渉を最小限に抑えながら、特定のイベントに関連する複数の車両センサーのモダリティからデータを同期させることが困難になります。たとえば、データサイエンティストが車両カメラによって検出された道路状況の正確さを分析する場合、テレメトリデータ（例：速度とブレーキ圧）、構造化されたオブジェクトリストとメタデータ、非構造化された画像/ビデオデータを確認することが望まれます。これらすべてのデータポイントを整理し、同じイベントに関連付けることは重労働です。通常、車両の操作への干渉を最小限に抑えるために関心のあるデータポイントのみを収集し、メタデータを追加し、データを同期させるために追加のソフトウェアと計算能力が必要です。 AWS IoT FleetWise のビジョンシステムデータを使用すると、自動車会社はカメラ、レーダー、LiDAR などの車両ビジョンシステムからデータを簡単に収集し、整理できます。これは、構造化されたビジョンシステムデータ、メタデータ、テレメトリデータをクラウド内で同期させ、顧客がイベントの完全な画像ビューを組み立て、洞察を得ることを容易にします。いくつかのシナリオは以下の通りです： 急ブレーキイベントが発生した際に何が起こったかを理解するために、顧客はイベントが発生する前後のデータを収集したいと考えます。収集されるデータには、推論（例：障害物が検出された）、タイムスタンプとカメラ設定（メタデータ）、および車両周辺で発生したこと（例：画像、ビデオ、バウンディングボックスと検出オーバーレイを備えた光/レーダーマップ）が含まれる場合があります。 顧客は、交通の妨げとなる事故、山火事、障害物など、道路上の異常なイベントに関心があります。顧客は、多数の車両にわたってテレメトリデータとオブジェクトリストデータを大規模に収集し始め、その後、異常なイベント（例：大きな高速道路上での速度が0）を示す一連の車両に焦点を当て、それらの車両からビジョンシステムデータを収集します。 AWS IoT FleetWise を使用してビジョンシステムデータを収集する際、顧客は帯域幅とデータサイズを最適化するためにデータ収集キャンペーンでイベントを指定するなど、サービスの高度な機能とインターフェースを活用できます。顧客は、車両のビジョンシステム、その属性、およびテレメトリセンサーを定義してモデリングすることから AWS で始めることができます。車両に展開された顧客のエッジエージェントは、CAN ベースの車両センサー（例：バッテリー温度）からのデータと、ビジョンシステムセンサーを含む車両サブシステムからのデータを収集します。顧客は、標準センサーとビジョンシステムの両方からデータ信号を同時に収集するために、同じイベントベースまたは時間ベースのデータ収集キャンペーンを使用できます。クラウド内では、顧客は定義された車両属性およびその他のメタデータ、テレメトリデータ、および構造化されたビジョンシステムデータの統合ビューを見ることができ、 Amazon Simple Storage Service（Amazon S3） 内で非構造化ビジョンシステムデータを表示するためのリンクがあります。データは、車両、キャンペーン、およびイベント識別子を使用して同期されたままです。その後、顧客は AWS Glue などのサービスを使用して、下流の分析のためにデータを統合できます。 Continental AG は運転者の利便性機能の開発を進めています コンチネンタルAGは、自動運転のための先駆的な技術とサービスを開発しています。「コンチネンタルは、クラウドでの自動車ソフトウェア開発を加速する技術の開発においてAWS と緊密に協力してきました。AWS IoT FleetWise のビジョンシステムデータを使用することで、カメラと動作計画データを簡単に収集し、自動駐車支援を改善し、フリート全体の監視と報告を可能にすることができます。」 Yann Baudouin, Head of Data Solutions – Engineering Platform and Ecosystem, Continental AG HL Mando は、ドライバーの安全性とパーソナライゼーションを向上させる機能を開発しています。 HL Mando は、自動車業界向けの部品とソフトウェアのトップサプライヤーです。「Mando では、運転や操作が容易な車両を作る技術革新に取り組んでいます。私たちのソリューションは、車両のテレメトリーデータおよび車両カメラデータを効率的に収集する能力に依存しています。AWS IoT FleetWise を通じて収集するデータを使用して、ドライバーの安全性とパーソナライゼーションを向上させることができる車両ソフトウェア機能の改善を楽しみにしています」 Seong-Hyeon Cho, Vice Chairman/CEO, HL Mando ThunderSoft は自動車およびフリートソリューションを開発しています ThunderSoft は、自動車会社や企業に知的なオペレーティングシステムや技術を提供しています。「ThunderSoft は、全世界の次世代のコネクテッド車技術を推進するために努力しており、AWS との連携を続けることを楽しみにしています。AWS IoT FleetWise からのビジョンシステムデータの登場により、私たちはお客様に対して先進的運転支援システム（ADAS）やフリート管理のための革新的なソリューションを提供することができるようになります」 Pengcheng Zou, CTO, ThunderSoft 解決策の概要 ADAS のユースケースを例に、ビジョンシステムデータの収集プロセスを見てみましょう。ADAS エンジニアが生産車両に衝突回避システムを展開していると想像してください。このシステムが車両の衝突を回避する方法の一つは、特定のシナリオ（例えば、別の車両との追突の危険が迫っている場合）で自動的にブレーキをかけることです。 このシステムに使用されるソフトウェアはすでに厳格なテストを経ていますが、エンジニアは現行世代および次世代の車両向けにソフトウェアを継続的に改善したいと考えています。この場合、エンジニアは衝突が検出されたすべてのシナリオを確認したいと思います。事故中に何が起こったかを理解するために、エンジニアは衝突が検出される前後の画像とテレメトリーデータで構成されるビジョンデータを見ます。S3 バケットに入ったら、エンジニアはデータを視覚化、分析、ラベル付けすることができます。 前提条件 始める前に、以下が必要です： サポートされているリージョンでのコンソール、CLI およびプログラムによるアクセス権を持つ AWS アカウント 。 AWS IoT FleetWise および Amazon S3 リソースを作成およびアクセスするための権限。 AWS IoT FleetWise ビジョンシステムデモガイド に記載されている手順に従い、「Playback ROS2 data」の章の終わりまでを完了させる。 （オプション）Galactic バージョンの ROS 2 をサポートする ROS 2 環境。ビジョンシステムデータのプレビュー期間中、AWS IoT FleetWise リファレンスエッジエージェントは ROS 2 ミドルウェアをサポートしており、ビジョンシステムの信号を収集します。 ウォークスルー ステップ1：車両をモデル化する ファイル ros2-nodes.json を作成して、シグナルカタログを作成します。このファイル内の名前や説明は自由に変更してください。 { "name": "fw-vision-system-catalog", "description": "vision-system-catalog", "nodes": [ { "branch": { "fullyQualifiedName": "Types" } }, { "struct": { "fullyQualifiedName": "Types.sensor_msgs_msg_CompressedImage" } }, { "struct": { "fullyQualifiedName": "Types.std_msgs_Header" } }, { "struct": { "fullyQualifiedName": "Types.builtin_interfaces_Time" } }, { "property": { "fullyQualifiedName": "Types.builtin_interfaces_Time.sec", "dataType": "INT32", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.builtin_interfaces_Time.nanosec", "dataType": "UINT32", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.std_msgs_Header.stamp", "dataType": "STRUCT", "structFullyQualifiedName": "Types.builtin_interfaces_Time" } }, { "property": { "fullyQualifiedName": "Types.std_msgs_Header.frame_id", "dataType": "STRING", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_CompressedImage.header", "dataType": "STRUCT", "structFullyQualifiedName": "Types.std_msgs_Header" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_CompressedImage.format", "dataType": "STRING", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_CompressedImage.data", "dataType": "UINT8_ARRAY", "dataEncoding": "BINARY" } }, { "branch": { "fullyQualifiedName": "Vehicle", "description": "Vehicle" } }, { "branch": { "fullyQualifiedName": "Vehicle.Cameras", "description": "Vehicle.Cameras" } }, { "branch": { "fullyQualifiedName": "Vehicle.Cameras.Front", "description": "Vehicle.Cameras.Front" } }, { "sensor": { "fullyQualifiedName": "Vehicle.Cameras.Front.Image", "dataType": "STRUCT", "structFullyQualifiedName": "Types.sensor_msgs_msg_CompressedImage" } }, { "struct": { "fullyQualifiedName": "Types.std_msgs_msg_Float32" } }, { "property": { "fullyQualifiedName": "Types.std_msgs_msg_Float32.data", "dataType": "FLOAT", "dataEncoding": "TYPED" } }, { "sensor": { "fullyQualifiedName": "Vehicle.Speed", "dataType": "STRUCT", "structFullyQualifiedName": "Types.std_msgs_msg_Float32" } }, { "branch": { "fullyQualifiedName": "Vehicle.Airbag", "description": "Vehicle.Airbag" } }, { "sensor": { "fullyQualifiedName": "Vehicle.Airbag.CollisionIntensity", "dataType": "STRUCT", "structFullyQualifiedName": "Types.std_msgs_msg_Float32" } }, { "struct": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.header", "dataType": "STRUCT", "structFullyQualifiedName": "Types.std_msgs_Header" } }, { "struct": { "fullyQualifiedName": "Types.geometry_msgs_Quaternion" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Quaternion.x", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Quaternion.y", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Quaternion.z", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Quaternion.w", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.orientation", "dataType": "STRUCT", "structFullyQualifiedName": "Types.geometry_msgs_Quaternion" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.orientation_covariance", "dataType": "DOUBLE_ARRAY", "dataEncoding": "TYPED" } }, { "struct": { "fullyQualifiedName": "Types.geometry_msgs_Vector3" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Vector3.x", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Vector3.y", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.geometry_msgs_Vector3.z", "dataType": "DOUBLE", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.angular_velocity", "dataType": "STRUCT", "structFullyQualifiedName": "Types.geometry_msgs_Vector3" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.angular_velocity_covariance", "dataType": "DOUBLE_ARRAY", "dataEncoding": "TYPED" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.linear_acceleration", "dataType": "STRUCT", "structFullyQualifiedName": "Types.geometry_msgs_Vector3" } }, { "property": { "fullyQualifiedName": "Types.sensor_msgs_msg_Imu.linear_acceleration_covariance", "dataType": "DOUBLE_ARRAY", "dataEncoding": "TYPED" } }, { "sensor": { "fullyQualifiedName": "Vehicle.Acceleration", "dataType": "STRUCT", "structFullyQualifiedName": "Types.sensor_msgs_msg_Imu" } } ] } JSON aws iotfleetwise create-signal-catalog --cli-input-json file://ros2-nodes.json Bash AWS IoT FleetWise は、ビジョンシステムと CAN バスのデータを同時に収集することができます。また、任意の vss-json ファイルから CAN シグナルを追加することで、シグナルカタログを更新することも可能です。ファイル内の name フィールドが作成したシグナルカタログと一致していることを確認してください。 aws iotfleetwise update-signal-catalog --cli-input-json file:// < can-nodes > .json Bash vehicle-model.json という名前のモデルマニフェストを作成してください。あなたのモデルマニフェストは、以下に示すシグナル（下記で詳細に説明された完全修飾名）から構成されるべきです。 Vehicle.Cameras.Front.Image Vehicle.Speed Vehicle.Acceleration Vehicle.Airbag.CollisionIntensity { "name": "fw-vision-system-model", "signalCatalogArn": "<signal-catalog-ARN>", "description": "Vehicle model to demonstrate FleetWise vision system data", "nodes": ["Vehicle.Cameras.Front.Image","Vehicle.Speed","Vehicle.Airbag.CollisionIntensity","Vehicle.Acceleration"] } JSON aws iotfleetwise create-model-manifest --cli-input-json file://vehicle-model.json Bash モデルマニフェストを更新し、active: に設定してください。 aws iotfleetwise update-model-manifest --name fw-vision-system-model --status ACTIVE Bash デコーダマニフェストファイル decoder-manifest.json を作成します。JSON を適切なモデルマニフェスト ARN に反映するように調整します。もし CAN シグナルも使用している場合は、 AWS IoT FleetWise のドキュメント を参照して、ビジョンシステムと CAN シグナルの両方が含まれる例のデコーダマニフェストを参照してください。デコーダマニフェストを作成した後、デコーダマニフェストを active ステータスに更新する必要があります。 { "name": "fw-vision-system-decoder-manifest", "modelManifestArn": "<your model manifest arn>", "description": "decoder manifest to demonstrate vision system data", "networkInterfaces":[ { "interfaceId": "10", "type": "VEHICLE_MIDDLEWARE", "vehicleMiddleware": { "name": "ros2", "protocolName": "ROS_2" } }, ], "signalDecoders":[ { "fullyQualifiedName": "Vehicle.Cameras.Front.Image", "type": "MESSAGE_SIGNAL", "interfaceId": "10", "messageSignal": { "topicName": "/carla/ego_vehicle/rgb_front/image_compressed:sensor_msgs/msg/CompressedImage", "structuredMessage": { "structuredMessageDefinition": [ { "fieldName": "header", "dataType": { "structuredMessageDefinition": [ { "fieldName": "stamp", "dataType": { "structuredMessageDefinition": [ { "fieldName": "sec", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "INT32" } } } }, { "fieldName": "nanosec", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "UINT32" } } } } ] } }, { "fieldName": "frame_id", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "STRING" } } } } ] } }, { "fieldName": "format", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "STRING" } } } }, { "fieldName": "data", "dataType": { "structuredMessageListDefinition": { "name": "listType", "memberType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "UINT8" } } }, "capacity": 0, "listType": "DYNAMIC_UNBOUNDED_CAPACITY" } } } ] } } }, { "fullyQualifiedName": "Vehicle.Speed", "type": "MESSAGE_SIGNAL", "interfaceId": "10", "messageSignal": { "topicName": "/carla/ego_vehicle/speedometer:std_msgs/msg/Float32", "structuredMessage": { "structuredMessageDefinition": [ { "fieldName": "data", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT32" } } } } ] } } }, { "fullyQualifiedName": "Vehicle.Airbag.CollisionIntensity", "type": "MESSAGE_SIGNAL", "interfaceId": "10", "messageSignal": { "topicName": "/carla/ego_vehicle/collision_intensity:std_msgs/msg/Float32", "structuredMessage": { "structuredMessageDefinition": [ { "fieldName": "data", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT32" } } } } ] } } }, { "fullyQualifiedName": "Vehicle.Acceleration", "type": "MESSAGE_SIGNAL", "interfaceId": "10", "messageSignal": { "topicName": "/carla/ego_vehicle/imu:sensor_msgs/msg/Imu", "structuredMessage": { "structuredMessageDefinition": [ { "fieldName": "header", "dataType": { "structuredMessageDefinition": [ { "fieldName": "stamp", "dataType": { "structuredMessageDefinition": [ { "fieldName": "sec", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "INT32" } } } }, { "fieldName": "nanosec", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "UINT32" } } } } ] } }, { "fieldName": "frame_id", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "STRING" } } } } ] } }, { "fieldName": "orientation", "dataType": { "structuredMessageDefinition": [ { "fieldName": "x", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "y", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "z", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "w", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } } ] } }, { "fieldName": "orientation_covariance", "dataType": { "structuredMessageListDefinition": { "name": "listType", "memberType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } }, "capacity": 9, "listType": "FIXED_CAPACITY" } } }, { "fieldName": "angular_velocity", "dataType": { "structuredMessageDefinition": [ { "fieldName": "x", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "y", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "z", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } } ] } }, { "fieldName": "angular_velocity_covariance", "dataType": { "structuredMessageListDefinition": { "name": "listType", "memberType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } }, "capacity": 9, "listType": "FIXED_CAPACITY" } } }, { "fieldName": "linear_acceleration", "dataType": { "structuredMessageDefinition": [ { "fieldName": "x", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "y", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } }, { "fieldName": "z", "dataType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } } } ] } }, { "fieldName": "linear_acceleration_covariance", "dataType": { "structuredMessageListDefinition": { "name": "listType", "memberType": { "primitiveMessageDefinition": { "ros2PrimitiveMessageDefinition": { "primitiveType": "FLOAT64" } } }, "capacity": 9, "listType": "FIXED_CAPACITY" } } } ] } } } ] } JSON aws iotfleetwise create-decoder-manifest --cli-input-json file://decoder-manifest.json aws iotfleetwise update-decoder-manifest —name fw-vision-system-decoder-manifest —status ACTIVE Bash ステップ2：車両の作成 上記のモデルマニフェストおよびデコーダマニフェストを使用して車両を作成します。事前のステップで作成したプロビジョニングされた AWS IoT のモノと同じ名前を使用してください。 aws iotfleetwise create-vehicle --vehicle-name FW-VSD-ROS2- < provisioned-identifier > -vehicle --model-manifest-arn < Your model manifest ARN > --decoder-manifest-arn < Your decoder manifest ARN > Bash ステップ3：キャンペーンの作成 AWS IoT FleetWise があなたの S3 バケットにアクセスできるようにするために、ここにある指示に従ってアクセスポリシーを設定します（「すべてのキャンペーンのバケットポリシー」を参照）。 検出された衝突イベントに基づいてデータを収集するイベントベースのキャンペーンを作成し、トリガー前の5秒間とトリガー後の5秒間のデータを含めます。 { "name": "fw-vision-system-collectCollision", "description": "Collect 10 seconds of data from a subset of signals if vehicle detected a collision - 5 pretrigger seconds, 5 posttrigger seconds", "signalCatalogArn": "<your signal catalog>", "targetArn": "<your target>", "signalsToCollect": [ { "name": "Vehicle.Cameras.Front.Image", "maxSampleCount": 1000, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Speed", "maxSampleCount": 1000, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Acceleration", "maxSampleCount": 1000, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Airbag.CollisionIntensity", "maxSampleCount": 1000, "minimumSamplingIntervalMs": 10 } ], "postTriggerCollectionDuration": 5000, "collectionScheme": { "conditionBasedCollectionScheme": { "conditionLanguageVersion": 1, "expression": "$variable.`Vehicle.Airbag.CollisionIntensity` > 1", "minimumTriggerIntervalMs": 10000, "triggerMode": "ALWAYS" } }, "dataDestinationConfigs": [ { "s3Config": { "bucketArn": "<your S3 bucket>", "dataFormat": "PARQUET", "storageCompressionFormat": "NONE", "prefix": "collisionData" } } ] } JSON aws iotfleetwise create-campaign --cli-input-json file://campaign.json Bash 別のキャンペーンを作成して、タイムイベントとして10秒間のデータを収集します。 { "name": "fw-vision-system-collectTimed", "description": "Collect 10 seconds of data from a subset of signals", "signalCatalogArn": "<Your signal catalog ARN>", "targetArn": "<Your vehicle ARN>", "signalsToCollect": [ { "name": "Vehicle.Cameras.Front.Image", "maxSampleCount": 500, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Speed", "maxSampleCount": 500, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Acceleration", "maxSampleCount": 500, "minimumSamplingIntervalMs": 10 }, { "name": "Vehicle.Airbag.CollisionIntensity", "maxSampleCount": 500, "minimumSamplingIntervalMs": 10 } ], "postTriggerCollectionDuration": 5000, "collectionScheme": { "timeBasedCollectionScheme": { "periodMs": 10000 } }, "dataDestinationConfigs": [ { "s3Config": { "bucketArn": "<Your S3 bucket>", "dataFormat": "PARQUET", "storageCompressionFormat": "NONE", "prefix": "timeData" } } ] } JSON aws iotfleetwise create-campaign --cli-input-json file://campaign-timed.json Bash すべてのキャンペーンを承認していることを確認してください！ aws iotfleetwise update-campaign --name fw-rich-sensor-collectCollision --action APPROVE aws iotfleetwise update-campaign --name fw-rich-sensor-collectTimed --action APPROVE Bash ステップ4: Amazon S3 でデータを確認する  AWS IoT FleetWise は、データを Amazon S3 にロードするのに最大 15 分かかります。S3 バケットには、次の 3 種類のファイルが表示されます。1/ 生データまたは iON ファイルで、AWS IoT FleetWise がデコードするデータのバイナリブロブが含まれています。これらのファイルは、エラーを深く調査するために使用できます。2/ 非構造化データファイルで、収集された画像/ビデオのバイナリが含まれています。3/ 処理済みデータ（構造化データ）ファイルで、デコードされたメタデータ、オブジェクトリスト、テレメトリデータが含まれており、対応する非構造化データファイルへのリンクが含まれています。 さらに進めるには、以下のことができます。 キャンペーン ID、イベント ID、および車両 ID を使用して、AWS Glue を使ってデータを join します。 AWS Glue Crawler を使用してデータをカタログ化し、検索可能にします。 Amazon Athena でアドホッククエリを使用してデータを探索し、興味のあるシーンを特定します。 データは、興味のあるシーンから次のバージョンのモデルと車両ソフトウェアを開発するための視覚化、ラベリング、再シミュレーションのためのダウンストリームツールに渡すことができます。例えば、 Foxglove Studio などのサードパーティソフトウェアを使用して、Amazon S3 に保存されている画像を使用して衝突前後に何が起こったかを視覚化することができます。 Amazon Rekognition は、衝突時に存在した追加のオブジェクトを自動的に発見してラベル付けするために使用できます。 Amazon SageMaker Groundtruth は、アノテーションと人が関わるワークフローのために使用でき、衝突回避ソフトウェアの正確さと関連性を向上させることができます。今後のブログでは、ワークフローのこの部分のオプションを探る予定です まとめ  この記事では、AWS IoT FleetWise ビジョンシステムデータが、高度な車両センサーシステムからデータを簡単に収集・整理し、イベントの包括的なビューを構築し、洞察を得ることを可能にする方法を紹介しました。この新機能は、自動車顧客のデータ駆動型ユースケースの範囲を拡大します。次に、ADAS 開発のサンプルユースケースを使用して、条件ベースのキャンペーンを作成するプロセスを説明しました。これは ADAS システムの改善に役立ち、Amazon S3 でそのデータにアクセスする方法を示しました。 詳しくは、 AWS IoT FleetWise のサイトをご覧ください。皆様のフィードバックや質問をお待ちしております。 この記事は Akshay Tandon と Matt Pollock によって書かれた Announcing AWS IoT FleetWise vision system data (Preview) の日本語訳です。この記事は IoT Solutions Architect の 井上 昌幸 が翻訳しました。 著者 Akshay Tandon は、Amazon Web Services の AWS IoT FleetWise チームでプリンシパル・プロダクト・マネージャーを務めています。彼は自動車と製品に関するすべてに情熱を注いでおり、顧客の声を聞き、彼らのニーズを満たすための革新的な製品やサービスを想像することを楽しんでいます。Amazon では、AlexaのAI/ML 分野とAmazon トランスポーテーション・サービスのフリートマネジメント分野で製品イニシアティブを率いてきました。彼は 10 年以上の製品管理経験を持っています。 Matt Pollock は、Amazon Web Services でシニア・ソリューション・アーキテクトとして働いており、現在は自動車の OEM やサプライヤーと協力しています。テキサス州オースティンを拠点とし、2005 年以来、さまざまな業界におけるデジタルと物理システムのインターフェースで顧客と協力してきました。技術的に困難な問題に対するスケーラブルなソリューションを構築していないときは、娘にひどい冗談を言って楽しんでいます。

Amazon Textract は、あらゆる文書や画像からテキスト、手書き文字、データを自動的に抽出する機械学習（ML）サービスです。Amazon Textractには、あらゆるドキュメントから表構造を自動的に抽出する機能を提供する AnalyzeDocument API内のTables機能があります。この投稿では、 Tables 機能に加えられた改良点と、様々な文書からテーブル構造の情報を簡単に抽出する方法について説明します。 財務報告書、給与明細書、分析証明書ファイルなどの文書に含まれる表構造は、多くの場合、情報を容易に解釈できるようにフォーマットされています。また、読みやすく整理しやすいように、テーブルのタイトル、テーブルのフッター、セクションのタイトル、サマリー行などの情報が表構造内に含まれていることもよくあります。今回の機能強化以前では、同様の文書において AnalyzeDocument のTables機能はこれらの要素をセルとして識別し、テーブルの境界の外側に存在するタイトルやフッターを抽出しませんでした。そのためこのようなケースでは、それらの情報を識別したり、APIのJSON出力から個別に抽出したりするための後処理の仕組みをカスタムで用意する必要がありました。今回のテーブル機能の強化の発表により、表形式データの様々な側面の抽出がよりシンプルになります。 2023年4月、Amazon Textractは、Tables機能によってドキュメントに存在するタイトル、フッター、セクションタイトル、サマリー行を自動的に検出する機能を導入しました。この投稿では、これらの機能強化について説明し、ドキュメント処理のワークフローで理解し使用するのに役立つ例を紹介します。また、APIを使用し、 Amazon Textract Textractorライブラリ でレスポンスを処理するコードの例を通して、これらの改良を利用する方法を説明します。 ソリューション概要 次の画像は、更新されたモデルが、ドキュメント内のテーブルだけでなく、すべてのテーブルのヘッダーとフッターも識別していることを示しています。このサンプルの財務報告書には、テーブルのタイトル、フッター、セクションタイトル、サマリーが含まれています。 テーブル機能の強化により、APIレスポンスに4つの新しい要素が追加され、それぞれのテーブル要素を簡単に抽出できるようになり、さらにテーブルの種類を区別する機能も追加されました。 テーブル要素 Amazon Textractは、テーブルセルやマージセルなど、テーブルのいくつかのコンポーネントを識別することができます。 Block オブジェクトとして知られるこれらのコンポーネントは、境界ジオメトリ、関係性、信頼スコアなど、コンポーネントに関連する詳細を内包しています。 Block は、 文書内で互いに近接したピクセル群の中で認識される項目を表します。今回の機能強化で導入された新しい テーブルのBlocks を以下に示します： テーブルのタイトル – TABLE_TITLE という新しい Block タイプが追加され、指定したテーブルのタイトルを識別できるようになりました。タイトルは、1行または複数行にすることができ、通常、テーブルの上にあるか、テーブル内のセルとして埋め込まれています。 テーブルのフッター – TABLE_FOOTER という新しい Block タイプが追加され、指定したテーブルのフッターを識別できるようになりました。フッターは、1行または複数行にすることができ、通常、テーブルの下にあるか、テーブル内のセルとして埋め込まれています。 セクションタイトル – TABLE_SECTION_TITLE という新しい Block タイプが追加され、検出されたセルがセクションタイトルかどうかを識別できるようになりました。 要約セル – TABLE_SUMMARY という新しい Block タイプが追加され、検出されたセルが給与明細の合計のような要約セルかどうかを識別できるようになりました。 テーブルのタイプ AmazonTextractは文書内のテーブルを特定すると、そのテーブルの詳細をすべて TABLE というトップレベルの Block タイプに抽出します。テーブルにはさまざまな形や大きさがあります。たとえば、文書にはテーブルが含まれていることがよくありますが、そのテーブルにはテーブルヘッダーがあることもないこともあります。こうした種類のテーブルを区別しやすくするために、 TABLE Block に2種類の新しいエンティティタイプを追加しました： SEMI_STRUCTURED_TABLE と STRUCTURED_TABLE です。これらのエンティティタイプは、構造化テーブルと半構造化テーブルを区別するのに役立ちます。 構造化テーブルとは、明確に定義された列ヘッダを持つテーブルです。しかし半構造化テーブルでは、データは厳密な構造に従っていない場合があります。たとえば、ヘッダーが定義されたテーブルではない表構造のデータです。新しいエンティティタイプは、後処理でどのテーブルを残すか削除するかを柔軟に選択できます。次の画像は、 STRUCTURED_TABLE と SEMI_STRUCTURED_TABLE の例です。 APIの出力を分析する このセクションでは、Tables機能強化による AnalyzeDocument のAPI出力を後処理するために、 Amazon Textract Textractorライブラリ を使用する方法を探ります。これにより、テーブルから関連する情報を抽出することができます。 Textractorは、Amazon TextractのAPIやユーティリティとシームレスに動作し、APIから返されたJSONレスポンスをプログラム可能なオブジェクトに変換するために作成されたライブラリです。また、ドキュメント上のエンティティを視覚化し、カンマ区切り値（CSV）ファイルなどの形式でデータをエクスポートするために使用することもできます。これは、Amazon Textractのお客様が後処理パイプラインを設定しやすくすることを目的としています。 今回の例では、10-K SECファイリングドキュメントの次のサンプルページを使用しています。 このあと出てくるコードはこちらの GitHubリポジトリ で参照できます。このドキュメントを処理するために、Textractorライブラリを利用し、API出力を後処理してデータを可視化するためにインポートしています。 pip install amazon-textract-textractor 最初のステップは、テーブル情報を抽出するために、 features=[TextractFeatures.TABLES] パラメータで示される Amazon Textractのテーブルの AnalyzeDocument 機能を呼び出すことです。このメソッドは、リアルタイム（または同期的）に AnalyzeDocument APIを呼び出し、それは単一ページのドキュメントを処理することに注意してください。しかし、 非同期 の StartDocumentAnalysis APIを使えば、複数ページ文書（最大3,000ページ）を処理することができます。 from PIL import Image from textractor import Textractor from textractor.visualizers.entitylist import EntityList from textractor.data.constants import TextractFeatures, Direction, DirectionalFinderType image = Image.open("sec_filing.png") # Pillowによって文書画像を読み込む extractor = Textractor(region_name="us-east-1") # textractorクライアントの初期化、必要に応じてリージョンを書き換えてください document = extractor.analyze_document( file_source=image, features=[TextractFeatures.TABLES], save_image=True ) この document オブジェクトには、確認可能なドキュメントに関するメタデータが含まれています。ドキュメント内の他のエンティティとともに、ドキュメント内の1つのテーブルを認識していることに注目してください。 This document holds the following data: Pages - 1 Words - 658 Lines - 122 Key-values - 0 Checkboxes - 0 Tables - 1 Queries - 0 Signatures - 0 Identity Documents - 0 Expense Documents – 0 テーブル情報を含むAPI出力が得られたので、前述したレスポンス構造を使ってテーブルのさまざまな要素を視覚化します。 table = EntityList(document.tables[0]) document.tables[0].visualize() Textractor ライブラリは、検出されたテーブル内の様々なエンティティを、テーブル要素ごとに異なるカラーコードでハイライトします。各要素をどのように抽出できるか、さらに深く掘り下げてみましょう。次のコードスニペットは、テーブルのタイトルを抽出するデモです。 table_title = table[0].title.text table_title 'The following table summarizes, by major security type, our cash, cash equivalents, restricted cash, and marketable securities that are measured at fair value on a recurring basis and are categorized using the fair value hierarchy (in millions):' 同様に、以下のコードを使ってテーブルのフッターを抽出することができる。table_footersはリストであることに注意してください。これは、テーブルに関連付けられたフッターが1つ以上存在する可能性があることを意味します。次のコード・スニペットに示すように、出力には3つのフッターが表示されます。 table_footers = table[0].footers for footers in table_footers: print (footers.text) (1) The related unrealized gain (loss) recorded in "Other income (expense), net" was $(116) million and $1.0 billion in Q3 2021 and Q3 2022, and $6 million and $(11.3) billion for the nine months ended September 30, 2021 and 2022. (2) We are required to pledge or otherwise restrict a portion of our cash, cash equivalents, and marketable fixed income securities primarily as collateral for real estate, amounts due to third-party sellers in certain jurisdictions, debt, and standby and trade letters of credit. We classify cash, cash equivalents, and marketable fixed income securities with use restrictions of less than twelve months as "Accounts receivable, net and other" and of twelve months or longer as non-current "Other assets" on our consolidated balance sheets. See "Note 4 - Commitments and Contingencies." (3) Our equity investment in Rivian had a fair value of $15.6 billion and $5.2 billion as of December 31, 2021 and September 30, 2022, respectively. The investment was subject to regulatory sales restrictions resulting in a discount for lack of marketability of approximately $800 million as of December 31, 2021, which expired in Q1 2022. 下流のためのデータ生成 Textractorライブラリは、下流システムや他のワークフローへのテーブルデータの取り込みを簡素化するのにも役立ちます。たとえば、抽出したテーブルデータを、人間が読めるMicrosoftExcelファイルへ書き出すことができます。この記事を書いている時点では、マージされた表をサポートしている形式はこれだけです。 table[0].to_excel(filepath="sec_filing.xlsx") また、 Pandas DataFrame に変換することもできます。DataFrameは、PythonやRなどのプログラミング言語でのデータ操作、分析、可視化によく使われます。 Pythonでは、DataFrameはPandasライブラリの主要なデータ構造です。DataFrameは柔軟で強力であり、データ分析の専門家が様々なデータ分析やMLタスクのために最初に選択することがよくあります。以下のコードスニペットは、抽出されたテーブル情報を1行のコードでDataFrameに変換する方法を示しています。 df=table[0].to_pandas() df 最後に、テーブルデータをCSVファイルに変換する。CSVファイルは、リレーショナルデータベースやデータウェアハウスにデータを取り込むためによく使われます。以下のコードを見てください。 table[0].to_csv() ',0,1,2,3,4,5\n0,,"December 31, 2021",,September,"30, 2022",\n1,,Total Estimated Fair Value,Cost or Amortized Cost,Gross Unrealized Gains,Gross Unrealized Losses,Total Estimated Fair Value\n2,Cash,"$ 10,942","$ 10,720",$ -,$ -,"$ 10,720"\n3,Level 1 securities:,,,,,\n4,Money market funds,"20,312","16,697",-,-,"16,697"\n5,Equity securities (1)(3),"1,646",,,,"5,988"\n6,Level 2 securities:,,,,,\n7,Foreign government and agency securities,181,141,-,(2),139\n8,U.S. government and agency securities,"4,300","2,301",-,(169),"2,132"\n9,Corporate debt securities,"35,764","20,229",-,(799),"19,430"\n10,Asset-backed securities,"6,738","3,578",-,(191),"3,387"\n11,Other fixed income securities,686,403,-,(22),381\n12,Equity securities (1)(3),"15,740",,,,19\n13,,"$ 96,309","$ 54,069",$ -,"$ (1,183)","$ 58,893"\n14,"Less: Restricted cash, cash equivalents, and marketable securities (2)",(260),,,,(231)\n15,"Total cash, cash equivalents, and marketable securities","$ 96,049",,,,"$ 58,662"\n'</p><h2> </h2> 結論 これらの新しいブロックとエンティティタイプ( TABLE_TITLE , TABLE_FOOTER , STRUCTURED_TABLE , SEMI_STRUCTURED_TABLE , TABLE_SECTION_TITLE , TABLE_FOOTER , TABLE_SUMMARY )の導入は、Amazon Textractによるドキュメントからの表構造の抽出の大きな進歩を意味します。 これらのツールは、構造化されたテーブルと半構造化されたテーブルの両方に対応し、ドキュメント内の位置に関係なく、重要なデータが見落とされないようにする、より繊細で柔軟なアプローチを提供します。 つまり、多様なデータタイプや表構造を、より高い効率性と正確さで扱えるようになったのです。ドキュメント処理のワークフローに自動化の力を取り入れ続ける中で、これらの機能強化が、より合理的なワークフロー、より高い生産性、より洞察力のあるデータ分析への道を開くことは間違いありません。 AnalyzeDocument とTables機能の詳細については、 AnalyzeDocument を参照してください。 翻訳はSolutions Architect 近藤が担当しました。原文は こちら です。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているソリューションアーキテクトの山本、シニア事業開発マネージャーの和田です。 2023年11月9日に製造業向けオンラインセミナー「製品・サービスのスマート化に向けた変革と挑戦 〜クラウド活用は前提、併せて必要となる社内変革とは？ 〜」を開催いたしました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 製造業のお客様にとって、自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくことが求められています。多くのお客様が IoT による自社製品のコネクティッド化に取り組まれていますが、継続的に提供価値を向上するためには、システムだけの変革だけでなく、組織、人材、開発プロセス、販売方法、KPI などの変革も必要です。 当セミナーでは、自社製品やソリューションのサービタイゼーションを検討/実施されているお客様向けに、実現するために課題となる部分のご説明や解決のための方法、お客様事例のご紹介を行いました。 どうぞ皆様の事業のご参考に、各講演者の録画/資料をご活用下さい。 モノからコトへ サービタイゼーションの勘所 登壇者：AWS シニア事業開発マネージャー 和田 健太郎 動画 資料リンク コト売りにおいてはソリューションを素早く立ち上げ、かつ立ち上げたソリューションを継続的に改善することが重要です。しかし、コト売りへの変革において製造業のお客様は様々な課題を抱えていらっしゃいます。Amazon ではイノベーションを起こすためには、組織、アーキテクチャ（システム）、メカニズム、企業文化の4つの要素が重要と捉えていますが、本セッションでは、これらの要素から製造業に求められる変革のポイントをご説明致しました。システム面ではクラウドを活用頂くことが有効ですが、クラウドの活用は前提として、その他の変革を合わせて進めて頂くことが重要です。また、これらの変革に取り組まれているお客様の事例と、AWSのご支援内容をご紹介させて頂きました。 サービタイゼーション実現のためにモノ売り企業に求められる変革 登壇者: Vieureka 株式会社 事業開発グループ 久芳 俊博 様 動画 資料リンク Vieureka 株式会社の久芳様からは、大企業の中のプロジェクトからスタートし、カーブアウトを経て、サービス提供における気づきから新たな事業を開始したストーリーについてお話しいただきました。 もともと Vieureka 様は Panasonic 様R&Dの社内プロジェクトとして人手不足解消・働き方改革のためのエッジ AI/IoT のプラットフォーム構想として出発し、構想を現実のものとするため、当初はまずはコトを広めるためのモノであるカメラとサービスとしての Viereka Manager の提供を開始されました。 大企業の中でスタートした Vieureka 様が実施された改革は多岐にわたりますが、まずはツールとしての AWS クラウドやマイクロサービスの活用により継続的な価値向上や開発効率の向上を行えるようにしました。 また、カーブアウトに伴って広くパートナーデバイスにオープンなビジネススキームへと変革し、88社のエコシステムを構築し、ビジネスKPIもモノの売上げから、コトの KPI、すなわち ARR や対応端末数への変革も実施されました。 一方、実際のサービスでの運用の中で、重要だが顧客価値にとっては本質ではないデバイスマネジメントが共通課題であるという気づきから、これを Vieureka 様がデバイスに依存しないサービスとし、お客様が価値提供に注力できるようになります。   このように、大企業内の社内プロジェクトからスタートし、様々な改革を実施すると共に、モノに依存しないデバイスプラットフォームへとビジネスを拡大された事例はモノコト変革において多くの参考になる要素がありました。 スマート道路モニタリングのサービス開発 登壇者: カヤバ株式会社 技術本部 基盤技術研究所 情報技術研究室 主幹研究員 髙松 伸一 様 動画 資料リンク 油圧部品を中心としたB2Bの製造販売事業を行っているカヤバ様は、主力製品である自動車部品の開発で培われた車両挙動の計測・分析技術を保有されています。このアセットを応用し、R&D 部門が起点となって従来の受託製造モデルとは異なる、今までにないコト売り型のビジネス開発を推進されました。登壇いただいた高松様からは、新規事業創出や開発文化改革、デジタライゼーションなど、多面的な変革を芽吹かせようと取り組んでいる活動についてご紹介いただきました。 カヤバ様が提供する「スマート道路モニタリング」サービスは、従来手間のかかった自治体管理道路の路面調査を、日常パトロールカーにセンサーを搭載することで、走行するだけで計測、クラウドに収集することで定量的に路面状態を調査できるソリューションです。このサービスにより人手不足の解消と全路線の調査の実現を行えます。この新規事業はこれまでの製造業としてのビジネスと大きくモデルが異なり、また所管組織もなかったことから、実現には社内での推進合意に課題があったそうです。 これらの課題に対して高松様はスマートプロダクトビジネスと既存事業の特徴や相違点を整理し、トップとの調整を重ね引受先体制を検討するとともに、社内外へアセットをアピールすることによって、ブランド力を強化して味方を増やし、ソリューションの価値を向上させることで事業化を実現されました。多くの製造業のお客様にとって、従来の製造ビジネス（モノ）からスマートプロダクト（コト）へのシフトは組織やビジネスの構造を変える必要があり、大きなチャレンジとなりますが、カヤバ様の取り組みは先駆者事例として共感とともにご参考にいただけたのではないかと思います。 SaaS デリバリー戦略 登壇者: TOPPAN デジタル株式会社　ICT 開発センター DXソリューション開発部1T　棗田 昂 様 動画 資料リンク TOPPAN デジタル様は校正から社内回覧までの業務を自動化・オンライン化する SaaS「review-it! for Package」を提供されています。 TOPPAN デジタル株式会社の棗田様からは、SaaS 事業、特に B2B に販売していく上で最も重要であると考える「デリバリー」という考え方についてお話しいただきました。 デリバリーとは「価値の伝達」であり、SaaS におけるデリバリー戦略は、各事業フェーズ毎に異なると説明されています。 0-1におけるデリバリーの重点ポイントは、あるファーストクライアントの事例を例に本気で課題を解決しようとしている顧客に熱量を持ってプロダクトが目指す未来や提供したい価値を伝達することの重要性を伝達することであるとおっしゃっています。 次に、1-10におけるデリバリーの重点ポイントは、メインストリーム市場の顧客に対してあらゆる価値の伝達の仕方が可能なサービスを作ることが重要であると述べられました。 しかし、メインストリーム市場は、初期市場との間の性質が大きく異なり、価値観のギャップを埋めていくことが重要であり、且つ難しいポイントにもなります。TOPPAN様が直面した課題は、プロダクトの改善において意思決定の難易度が上がった点にあります。この課題に直面する中で、開発メンバーに対する依頼も一方通行となり、開発メンバーのモチベーション低下という悪影響にもつながりました。サービスの観点では、要望が多岐にわたり、それらに対して個別に対応する中でプロダクトの全体像がぼやけるという問題も発生しました。 このような問題が発生した原因について出てきた仮説が「価値を売っていたつもりが機能を売っていたのではないか」ということでした。お客様に求められる要望を受け続けていく「Fit & Gap」のアプローチでは、様々な機能を作り続けていく必要が出てきてしまいます。 これに対して、顧客側が「サービス側が提示した現実界」に合わせる Fit to Standard を目指すため、プロダクトフィードバックループプロセスと組織の改善を実施しました。課題の把握とサービスビジョンのすり合わせをカスタマーサクセス、現場課題や製品像を把握して意思決定を行いデザインチームに仕様を落とし込むプロダクトマネージャーによる製品の意思決定を行い、デザイナーにより要望やUIを整理するといった改善を行いました。 結果として、新たなプロダクトフィードバックループ「Ver2.0」により、各チームが密に連携して現場での実用性を重要視した機能開発と優先度付けをした上で意思決定を行うことができるようになりました。フィードバックループをスピード感を持って機能改善していく上で AWS は無くてはならない存在であるとおっしゃっています。また、受注数が大きく伸び、受注までのリードタイムを圧縮することもできるようになりました。 AWS ではじめる・拡げる、スマートプロダクト＆サービス 登壇者: AWS シニアソリューションアーキテクト 吉川 晃平 動画 資料リンク イベント最後のセッションでは、新たなビジネス機会創出と付加価値獲得を目指し自社製品のスマートプロダクト化を目指す製造業の皆様向けに、Solutions Architect 吉川が主にテクノロジーの観点から AWS のサービスをつかって製品のスマートプロダクト化とサービス提供をおこなう方法をご紹介しました。スマートプロダクト化においてはユーザーの声をタイムリーにサービス・デバイスに反映させる迅速さが成功の秘訣です。これを実現するには試行を増やし、リリースサイクルを短縮させる組織力とソリューションが必要となります。 AWS はすぐに使えるマネージドサービスを中心に 200 を超えるサービスがあり、これを組み合わせることで開発量を抑えながら迅速にお客様のサービスをアップデートすることができます。このセッションではスマートプロダクトの開発・運用に必要な３つの要素、「デバイスとサービスの接続」「デバイス設計の加速」「継続的な機能更新と改善」に着目し、サービス、デバイスそれぞれについて、AWS を活用する方法をご紹介しました。また、多くのサービスの中から、ユースケースに適したサービスを選択する方法、継続的な開発・運用に適した環境、デバイス設計でのクラウド活用、サービスに機械学習を組み込む方法など、広くスマートプロダクトビジネスに役立つAWS活用方法や事例をお話しました。 終わりに 本セミナーでは、製造業のお客様が自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくために必要な考え方やポイントについて紹介し、実際にサービタイゼーションを実現されたお客様の事例と体験談を共有いただきました。 本ブログは、事業開発マネージャーの和田健太郎、ソリューションアーキテクトの山本直志、吉川晃平、村松健が執筆しました。

現代のコマースアプリケーションには、急速な変化に対応できる柔軟でスケーラブルなソリューションが必要です。 MACH アーキテクチャ（Microservices-based, API-first, Cloud-native SaaS, Headless）は、デジタル世界で競争力を維持したい企業に柔軟性、スケーラビリティ、俊敏性を提供できるため、近年ますます人気が高まっています。 MACH の詳細については、以前のブログ「 AWS 上で優れた MACH を実現するには 」をご覧ください。 MACH アーキテクチャによるソリューションを構築するためには、企業はマイクロサービスベースのアーキテクチャの動的な需要に対応でき、信頼性が高く堅牢なクラウド技術が必要です。 MACH Alliance の Enabler メンバー (*) であるアマゾンウェブサービス (AWS) は、MACH ソリューションを構築するための理想的なプラットフォームとなる数多くのメリットを提供します。 *) MACH Alliance の Enabler メンバーは、MACH アーキテクチャに多く採用されるサービスやテクノロジーを提供する組織に該当します。 セキュリティ：AWS はエンドツーエンドのアプローチを採用して、物理的な設備、オペレーション、ソフトウェアを含むインフラストラクチャのセキュリティ対策と強化を行っています。 柔軟性：AWS は、あらゆる規模や複雑さのアプリケーションの構築とデプロイに使用できる、200 種類を超える豊富な機能のサービスを幅広く提供しています。 スケーラビリティ：AWS を使うと、必要に応じてアプリケーションをスケールアップまたはスケールダウンできるため、必要なときにコンピューティングリソースやストレージリソースにアクセスできるようになります。 アベイラビリティ：現在、AWS クラウドは世界中の 31 の地理的リージョンにある 99 のアベイラビリティーゾーンにまたがっており、さらに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンの計画が発表されています。これにより、可用性の高いグローバルアプリケーションを構築できます。 費用対効果：AWS では、長期契約や前払いなしに、コンピューティング能力、ストレージ、その他のリソースを従量課金でご利用いただけます。 イノベーション：AWS は常に革新を続けており、ご利用者様が競合他社の一歩先を行き、新しいテクノロジーを活用できるようにするための新サービスや機能を提供しています。 MACH ソリューションのための AWS 2006 年に AWS を提供し始めてから、ウェブサイトやソフトウェアアプリケーションの急速な変化と革新を促進する最新のアーキテクチャを構築できるよう、小売業者やパートナーを支援してきました。これには、マイクロサービス、API、およびクラウド向けの設計の使用が含まれます。 AWS には数多くのメリットがあり、MACH ソリューションを構築するための理想的なプラットフォームとなっています。AWS の包括的なサービススイート、API ファーストのアプローチ、クラウドネイティブ設計、ヘッドレスソリューション機能により、ご利用者様に MACH アプリケーションを簡単に構築、展開、管理するための信頼性が高く堅牢なクラウドインフラストラクチャを提供します。 AWS が MACH ソリューションの構築にどのように役立つかについて詳しく知りたい場合は、電子書籍「 Architectural guidance for building composable MACH solutions on AWS 」をダウンロードしてください。 この電子書籍では、ベストプラクティスや実際のユースケースを含め、AWS で MACH アプリケーションを設計してデプロイする方法に関するガイダンスを提供します。 電子書籍をダウンロード » MACH Two で AWS に会いましょう | アムステルダム、6 月 13 ～ 14 日 コンポーザブルスタックへのリプラットフォームを検討しているなら、このイベントは見逃せません。すでに取り組み始めている方や、次の大きな技術変化についてもっと知りたい方には、良い機会です。MACH Two は、進捗について話し合い、アイデアを共有し、実際のビジネスインパクトを紹介するためのコミュニティの大きなステージです。 MACH Two に参加して、IKEA、PUMA、ASICS、Philips、AmerCareRoyal などの MACH 分野の主要な小売イノベーターの仲間入りをしましょう。 AWS は MACH Two のヘッドラインスポンサーです。ぜひアムステルダムで当社のチームに会って、AWS で MACH を運用することのメリットについて議論しましょう。 Daniele Stroppa Daniele Stroppa は 小売業界の AWS パートナーをリードする EMEA のテクニカルリーダーです。Daniele は、AWS の小売テクノロジーおよびコンサルティングパートナー向けのソリューションアーキテクチャと技術戦略を担当しています。AWS に 8 年間在籍しており、Amazon Elastic Compute Cloud (Amazon EC2) コンテナサービスチームとソリューションアーキテクチャチームでの職務を担当してきました。Daniele はソフトウェア開発と、開発者が最適な結果を出せるよう支援することにに情熱を傾けています。 Renata Melnyk Renata Melnyk は、AWS で消費財および小売業界のパートナーマーケティングにおけるグローバルリーダーであり、AWS 業界のビジネスリーダーと AWS パートナーと共に戦略的な市場開拓イニシアチブをグローバル規模で計画、構築、実行できるよう支援しています。Renata Melnyk の AWS での経験は 10 年近くに渡り、AWS ワールドワイドパブリックセクター、AWS スタートアップ、AWS パートナー、AWS プロダクトマーケティング、AWS パートナーマーケティング組織などの中核となるビジネス分野で働いてきました。 本記事は、 Build modern commerce MACH solutions on AWS を翻訳したものです。 翻訳は Solutions Architect 永田 享 が担当しました。

第 1 部 ( 日本語 ) では、企業内のある組織から別の組織に AWS アカウントを移行する際、ガイダンスと考慮事項が必要となる Organizations のさまざまな機能を確認しました。組織ポリシー、 AWS Resource Access Manager (AWS RAM) による共有、および AWS グローバル条件コンテキストキーに焦点を当てました。 3 部構成の第 2 回となるこの投稿では、AWS サービスに 委任された管理者 として登録されている AWS アカウントを移行する場合のふるまいを明らかにして、アクションを示します。AWS サービスの委任された管理者を登録解除するとどうなるかを理解し、計画を立てるのに役立つ情報とガイダンスを用意しました。また、AWS サービスの既存の委任された管理者がいる組織に AWS アカウントを移行する場合のガイダンスも提供します。第 1 部と同様に、引き続き組織のユーザーガイドに記載されている情報を基に、 組織からメンバーアカウントを削除 した上で、 AWS アカウントを組織に招待 します。組織間で AWS アカウントを移行するには、その AWS アカウントを組織から削除し、AWS アカウントをスタンドアロンにしてから、別の組織への招待を受け入れる必要があります。組織から AWS アカウントを削除する前に、その組織に委任された管理者が登録されているかどうかを確認することをお勧めします。 この記事では、 AWS Command Line Interface (AWS CLI) の例を使用しています。これらを利用するには、まず AWS CLI をインストールして設定する必要があります。詳細については、「 AWS CLI のインストール 」を参照してください。 AWS Organizations の委任された管理者 メンバーアカウントを組織の 委任された管理者 に指定すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは、互換性のある AWS サービスの管理アクションを実行できます。これにより、AWS Organizations の管理と AWS サービスの管理を分けることができます。委任された管理者として登録されているメンバーアカウントを組織から移行する場合、その AWS アカウントを委任された管理者から解除した上で組織から削除する必要があります。AWS アカウントを委任された管理者から解除して組織から削除する前に、その AWS アカウントに何が起こるか、考慮すべきアクションを理解しておく必要があります。 組織の委任された管理者を現在サポートしている AWS サービスのリストを次のセクションに含めています。AWS サービス名または サービスプリンシパル名 のいずれかで探すことができます。AWS CLI の list-delegated-services-for-account コマンドを使用して、登録済みの委任された管理者の AWS アカウントを出力することでサービスプリンシパル名を確認できます。一部の AWS サービスでは、委任された管理者が設定されているかどうかを AWS サービスコンソールでも確認できます。 次の AWS CLI の例では、指定された AWS アカウントが委任された管理者となっている AWS サービスを確認します。< account-id > を、 確認したい AWS アカウント ID に置き換えてください。 PROMPT > aws organizations list-delegated-services-for-account --account-id < account-id > 組織内に AWS サービスの委任された管理者である AWS アカウントがあるかどうかを確認するには、AWS CLI list-delegated-administrators コマンドを使用します。次の例では、AWS CLI コマンドを使用して、特定の AWS サービスに割り当てられている委任された管理者の AWS アカウントを特定し、その AWS アカウントが委任された管理者となっているサービスプリンシパルがリストされることを確認します。 次の AWS CLI の例では、組織内の委任された管理者として指定されているすべての AWS アカウントのリストを取得します。 PROMPT > aws organizations list-delegated-administrators 次の AWS CLI の例では、指定されたアカウントが委任された管理者である AWS サービスを取得します。前のステップで見つかったそれぞれの “Id” 値に < account-id > を置き換え、“DeleatedAdministrators“ のリストを確認するコマンドを繰り返します。 PROMPT > aws organizations list-delegated-services-for-account --account-id < account-id > 指定した AWS サービスに委任された管理者が設定されているかどうかを確認するには、AWS CLI の list-delegated-administrator コマンドを使用できます。次の AWS CLI の例では、指定されたサービスプリンシパルの AWS サービスで委任された管理者として指定されているすべての AWS アカウントを取得します。< service-principal > を確認したい AWS サービスのサービスプリンシパル名に置き換えてください。 PROMPT > aws organizations list-delegated-administrators --service-principal < service-principal > 組織の管理アカウントの認証情報と AWS CLI deregister-delegated-administrator コマンドを使用して、互換性のある AWS サービスで委任された管理者である AWS アカウントの登録を解除できます。 AWS Audit Manager , Amazon Detective , AWS Firewall Manager , Amazon GuardDuty , Amazon Macie , AWS Security Hub , Amazon VPC IP Address Manager (IPAM) などの一部の AWS サービスには、委任された管理者への AWS アカウントの登録と登録解除のための独自のコマンドまたはコンソールオプションがあります。現時点で委任された管理者をサポートしている AWS サービスのコマンドのバリエーションを詳しく説明します。 次の AWS CLI の例では、引数で指定された AWS サービスにおいて、同じく引数で指定されたメンバーアカウントを委任された管理者から解除します。< account-id > を、委任された管理者から解除したいメンバーアカウントの AWS アカウント ID 番号に置き換えてください。< service-principal > を、この AWS アカウントが委任された管理者となっている AWS サービスのサービスプリンシパル名に置き換えてください。 PROMPT > aws organizations deregister-delegated-administrator --account-id < account-id > --service-principal < service-principal > AWS Service Catalog , AWS CloudFormation StackSets , AWS Network Manager , Amazon S3 Storage Lens , AWS Trusted Advisor , AWS Config などの特定の AWS サービスにおいては、ケースに合わせて 1 つの組織内に複数の委任された管理者アカウントを持つことができます。この記事の後半で、それぞれのクォータについて詳しく説明します。複数の委任された管理者をサポートする AWS サービスでは上限のアカウント数に至るまでは、現在の委任された管理者の登録を解除することなく、別の AWS アカウントを登録できます。これは、組織を維持する予定があり、現在の委任された管理者を別の組織に移すことを検討している場合のオプションとして使用できます。多数の AWS アカウントを移行する間の作業をサポートするために、または組織を維持する場合には、組織内で別の委任された管理者を構成することを検討してください。組織に残っている AWS アカウント、または最後に移行するもしくは閉じる（削除する）既存の AWS アカウントを選択します。移行中に、委任された管理者設定すべてをこの AWS アカウントに割り当てることができます。 組織の委任された管理者だった AWS アカウントが別の組織に移行されると、その AWS アカウントはメンバーアカウントとして新しい組織に参加します。この AWS アカウントは、互換性のある AWS サービスの委任された管理者として登録されていません。 AWS アカウントを別の組織に移行するときは、新しい組織の委任された管理者と連携するように AWS アカウントを設定する必要があるかどうかを確認する必要があります。多くの AWS サービスでは、新しい組織で委任された管理者と連携する通常の設定を再度行うだけで移行できます。ただしいくつかの AWS サービスでは、委任された管理者アカウントにおいて移行のための特別な設定が必要な場合があります。次のセクションで解説する委任された管理者をサポートしている AWS サービスのリストには、そのようなガイダンスも含まれています。対象組織に AWS サービスの委任された管理者である AWS アカウントがあるかどうかを確認するには、AWS CLI の list-delegated-administrators コマンドを使用できます。組織内に委任された管理者が見つかった場合は、AWS CLI list-delegated-services-for-account コマンドを使用して、どの AWS サービスなのかを確認することができます。この情報を使用して、組織に AWS アカウントを追加するときに必要なアクションを計画できます。 AWS Organizations の委任された管理者をサポートしている AWS サービス 次の AWS サービスのリストは AWS Organizations と連携し、かつ委任された管理者もサポートしています。このセクションには、AWS サービスの委任された管理者として AWS アカウントを登録解除する前に考慮すべきガイダンスと動作が含まれています。また既存の委任された管理者がいる組織に移行したときも、AWS アカウントの設定を確認できます。 AWS Account Management: account.amazonaws.com AWS Account Management の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Account Management の管理アクションを実行できなくなります。その AWS アカウントは、組織内の他のメンバーアカウントの AWS アカウント管理 API オペレーション を呼び出すことができなくなります。 AWS Audit Manager: auditmanager.amazonaws.com AWS Audit Manager の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Audit Manager の管理アクションを実行できなくなります。AWS アカウントでそれまでに収集された証拠には、引き続きアクセスができます。ただしその後は AWS Audit Manager は証拠の収集と AWS アカウントへの添付を停止します。委任された管理者の登録を解除するには、その組織の管理アカウントの AWS Audit Manager コンソールまたは AWS CLI の deregister-organization-admin-account コマンドを使用できます。 AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com AWS CloudFormation StackSets の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS CloudFormation StackSets の管理アクションを実行できなくなります。その AWS アカウントは、サービスマネージド型のアクセス許可でスタックセットを作成または管理することができなくなります。サービスマネージド型のアクセス許可でそれまでに作成されたスタックセットは、組織の管理アカウントに保持されます。AWS CloudFormation StackSets の委任された管理者として、1 つの組織に最大 5 つのメンバーアカウントを登録できます。 AWS アカウントを別の組織に移行する前に、移行先組織に設定されている StackSets のデプロイ対象を確認してください。移行する AWS アカウントに StackSets が適用されるかどうかをデプロイ対象から判断する必要があります。 セルフマネージド型の権限 を使用して StackSets を設定している場合、 ターゲットアカウント または 管理者アカウント を移行しても影響はありません。このブログシリーズの第 1 部で説明した、管理者アカウントの AWSCloudFormationStackSetAdministrationRole と、ターゲットアカウントの AWSCloudFormationStackSetExecutionRole の 条件キー に関連する AWS Identity and Access Management (IAM) ロールポリシーを確認してください。 AWS Compute Optimizer: compute-optimizer.amazonaws.com AWS Compute Optimizer の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーと IAM ロールは AWS Compute Optimizer の管理アクションを実行できなくなります。その AWS アカウントは、組織内のメンバーアカウントの Compute Optimizer レコメンデーションにアクセスして管理したり、組織の Compute Optimizer 推奨設定を管理できなくなります。 AWS Config: config-multiaccountsetup.amazonaws.com AWS Config の 委任された管理者アカウント の登録を解除すると、その AWS アカウントの Config ルールとコンフォーマンスパック、設定された IAM ユーザーおよび IAM ロールは AWS Config の管理アクションを実行できなくなります。この AWS アカウントでは、 Config ルール と コンフォーマンスパック を組織全体にデプロイおよび管理できなくなります。委任された管理者アカウントによってデプロイされたコンフォーマンスパックと Config ルールは、その AWS アカウントと組織のすべてのメンバーアカウントから自動的に削除されます。AWS Config の Config ルールとコンフォーマンスパックの委任された管理者は、1 つの組織に最大 3 つのメンバーアカウントを登録できます。 AWS アカウントを別の組織に移行する場合、その AWS アカウントが管理アカウントまたは AWS Config ルールとコンフォーマンスパックの既存の委任された管理者と連携できるように、AWS Config 設定レコーダー が有効になっていることを確認する必要があります。設定レコーダーが無効な場合、既存の組織のルールとコンフォーマンスパックのデプロイは、AWS アカウントが組織に追加されてから 7 時間以内に再試行されます。 AWS Config: config.amazonaws.com AWS Config データ集約の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは AWS Config の管理アクションを実行できなくなります。その AWS アカウントは組織全体の AWS Config データを集約できなくなり、設定されたアグリゲータはデータを受信しなくなります。AWS Config データ集約の委任された管理者として、1 つの組織に最大 3 つのメンバーアカウントを登録できます。同じ組織の委任された管理者として同じ AWS アカウントを登録した場合、設定されているアグリゲータは引き続きデータを収集します。 AWS アカウントを別の組織に移行する場合、AWS Config アグリゲータを使用している移行先の委任された管理者と連携するために、該当アカウントで AWS Config を有効にしておく必要があります。 Amazon Detective: detective.amazonaws.com Amazon Detective の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは Amazon Detective の管理アクションを実行できなくなります。Amazon Detective は委任された管理者アカウントでは無効になり、組織の行動グラフはすべて削除されます。 Amazon Detective の委任された管理者を登録解除するには、管理アカウントの Detective のコンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Detective のコンソールを使用する場合、現在のリージョンの Detective 管理者アカウント のみが削除されるため、リージョンごとに管理者を削除する必要があります。AWS CLI の disable-organization-admin-account コマンドを使用する場合は、組織の管理アカウントの認証情報を使用し、各リージョンの Detective 管理者アカウントを削除する必要があります。コンソールまたは AWS CLI の deregister-delegated-administrator コマンドを使用して、指定された組織の委任された管理者を削除する必要があります。 アカウントを別の組織に移行するときは、Amazon Detective の [アカウント管理] 設定を確認してください。Amazon Detective は、 新しい組織の AWS アカウントを Amazon Detective メンバーアカウントとして自動的または手動で有効にする ように設定できます。 Amazon DevOps Guru: devops-guru.amazonaws.com Amazon DevOps Guru の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは Amazon DevOps Guru の管理アクションを実行できなくなります。この AWS アカウントでは、組織全体の DevOps Guru のすべてのインサイトとメトリクスをまとめて表示することはできなくなります。組織の管理アカウントは、引き続き組織内のすべての AWS アカウントのすべてのインサイトにアクセスできます。 AWS Firewall Manager: fms.amazonaws.com AWS Firewall Manager の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS Firewall Manager の管理アクションを実行できなくなります。 AWS Firewall Manager 管理者 アカウントによって作成されたすべての Firewall Manager ポリシーは、関連する AWS Config マネージドルールも含めて削除されます。AWS Firewall Manager ポリシーを削除すると、 Network Firewall 、 Security group (共通)、 AWS WAF の ポリシーの範囲 の設定によって、Firewall Manager が保護を保持または削除するか、 Firewall Manager が管理するリソースを削除するかが決まります。 DNS Firewall ポリシー を削除すると、 Amazon Route 53 Resolver DNS Firewall ルールグループと任意の Amazon Virtual Private Cloud (VPC) との間のマネージドな関連付けが削除されることに注意してください。 委任された管理者を削除する前に、セキュリティポリシー、アプリケーション、プロトコルリストを含む Firewall Manager の設定を控えておく必要があります。この情報を使用して、別の委任された管理者アカウントにこの設定を引き継ぐことができます。Firewall Manager のセキュリティポリシー、アプリケーション、およびプロトコルを一覧表示するには、組織の管理アカウントの認証情報と AWS CLI の list-policies 、 list-apps-lists 、 list-protocols-lists コマンドをそれぞれ使用します。 委任された管理者を削除するには、委任された管理者アカウントの Firewall Manager コンソールを使用するか、委任された管理者アカウントの認証情報を使用して、バージニア北部リージョン (us-east-1) で AWS CLI の disassociate-admin-account コマンドを使用します。ある AWS アカウントを組織から削除したときに、その AWS アカウントがまだ委任された管理者として登録されていることがわかった場合は、AWS CLI の deregister-delegated-administrator コマンドを使用できます。ある AWS アカウントを別の組織に移行する場合、その AWS アカウントが既存の AWS Firewall Manager ポリシーに関するスコープポリシーに含まれているか、(必要に応じて) 除外されているかを確認してください。 Amazon GuardDuty: guardduty.amazonaws.com Amazon GuardDuty の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon GuardDuty の管理アクションを実行できなくなります。委任された管理者アカウントの登録を解除しても、その AWS アカウントまたは組織のメンバーアカウントの GuardDuty は無効になりません。組織内の AWS アカウントは関連付けを解除され、すべての設定が保持されたまま GuardDuty がスタンドアロンで動作する AWS アカウントに変換されます。 Amazon GuardDuty の委任された管理者を登録解除するには、管理アカウントの GuardDuty コンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Amazon GuardDuty コンソールを使用する場合、 GuardDuty の管理者設定はすべてのリージョンで無効化され 、組織で指定されている GuardDuty の委任された管理者設定は削除されます。AWS CLI の deregister-delegated-administrator コマンドを使用する場合は、各リージョンの GuardDuty の管理者設定を無効化してから、このコマンドを使用して組織で指定された委任された管理者設定を削除する必要があります。 ある AWS アカウントを別の組織に移行した際、組織単位で Amazon GuardDuty を有効にしたリージョンでは、自動的に GuardDuty メンバーアカウントとして関連付けられます。GuardDuty が組織単位で有効でなく AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの GuardDuty コンソールを使用してその AWS アカウントを 手動でメンバーアカウントとして追加 できます。 IAM Access Analyzer: access-analyzer.amazonaws.com IAM Access Analyzer の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、IAM Access Analyzer の管理アクションを実行できなくなります。この AWS アカウントは、委任された管理者アカウントとして作成した、信頼ゾーンが組織であるすべてのアナライザーに対する権限を失います。構成済みのアナライザーはすべて無効な状態になり、新しい検出結果の生成や既存の検出結果の更新は行われなくなります。これらのアナライザーにおける既存の検出結果にもアクセスできなくなります。ただし、同じ AWS アカウントをこの組織の委任された管理者として再度登録することで、再びそれらの検出結果にアクセスできるようになります。委任された管理者と同じ AWS アカウントを使用しないことがわかっている場合は、委任された管理者を変更する前にアナライザーを削除することを検討してください。これにより、生成された検出結果がすべて削除されます。別の AWS アカウントを委任された管理者として登録し、新しいアナライザーを作成すると、同じ検出結果の新しいインスタンスがこの AWS アカウントで生成されます。ある AWS アカウントを別の組織に移行するときに、信頼ゾーンが組織であるアナライザーがすでに作成されている場合、移行した AWS アカウントは自動的に分析対象のセットに含まれます。 AWS IAM Identity Center (successor to AWS Single Sign-On): sso.amazonaws.com AWS IAM Identity Center の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS IAM Identity Center の管理アクションを実行できなくなります。AWS IAM Identity Center で設定された権限や割り当ては影響を受けず、エンドユーザーは引き続き AWS アクセスポータルからアプリケーションと AWS アカウントにアクセスできます。 Amazon Inspector: inspector2.amazonaws.com Amazon Inspector の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon Inspector の管理アクションを実行できなくなります。その AWS アカウントは組織を対象にした Amazon Inspector を監視することができなくなり、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Elastic Container Registry (Amazon ECR) の設定データやセキュリティ検出の結果など、関連付けされた組織のメンバーアカウントのメタデータにアクセスできなくなります。委任された管理者を登録解除しても、その AWS アカウントまたは組織のメンバーアカウントの Inspector は無効になりません。組織の AWS アカウントは関連付けを解除され、スキャン設定を保持したまま Inspector がスタンドアロンで動作する AWS アカウントに変換されます。 組織の管理アカウントの Amazon Inspector コンソールを使用して委任された管理者を削除する場合、すべてのリージョンから委任された管理者を削除する必要があります。AWS CLI の deregister-delegated-administrator コマンドを使用すると、委任された管理者がすべてのリージョンから自動的に削除されます。同じ組織の Inspector に別の委任された管理者を設定する場合は、組織のメンバーを委任された管理者アカウントに手動で関連付ける必要があります。 ある AWS アカウントを別の組織に移行すると、「 自動的に有効化 」が設定されたリージョンでは、その AWS アカウントは自動的に委任された管理者と Inspector に関して関連付けられます。移行した AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Inspector コンソールを使用して、 手動でメンバーアカウントとして追加 できます。 AWS License Manager: license-manager.amazonaws.com: license-manager.member-account.amazonaws.com AWS License Manager の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、AWS License Manager の管理アクションを実行できなくなります。AWS RAM を使用して AWS License Manager のライセンス設定を AWS アカウントと直接共有するのか、組織と連携して共有するのかを確認する必要があります。このブログシリーズの第 1 部では、所有者アカウントとコンシューマーアカウントの両方について、AWS RAM リソースの共有と組織間を移行する際の考慮事項について説明しています。 Amazon Macie: macie.amazonaws.com Amazon Macie の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon Macie の管理アクションを実行できなくなります。この AWS アカウントは、すべての AWS リージョンのすべての Macie におけるメンバーアカウントの Macie 設定、データ、およびリソースにアクセスできなくなります。委任された管理者アカウントの登録を解除しても、その AWS アカウントまたは組織のメンバーアカウントの Macie は無効になりません。組織のメンバーアカウントは関連付けを解除され、すべての設定が保持されたまま Macie がスタンドアロンで動作する AWS アカウントに変換されます。 Amazon Macie の委任された管理者を登録解除するには、組織の管理アカウントの認証情報を使用して、AWS CLI の disable-organization-admin-account コマンドを実行する必要があります。Macie 管理者が設定されたリージョンでその設定を削除し、次に AWS CLI の deregister-delegated-administrator コマンドを使用して組織で指定された委任された管理者を削除する必要があります。 ある AWS アカウントを別の組織に移行する場合、 自動有効化 が設定されたリージョンでは、AWS アカウントは Macie に関して自動的に委任された管理者と関連付けられます。AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Macie コンソールを使用して 手動でメンバーアカウントとして追加 できます。 AWS Network Manager: networkmanager.amazonaws.com AWS Network Manager の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Network Manager の管理アクションを実行できなくなります。登録されている他のメンバーアカウントのトランジットゲートウェイは、その AWS アカウントのグローバルネットワークから登録解除されます。ネットワークトポロジが更新され、他のメンバーアカウントのリソースが表示されなくなります。Network Manager の委任された管理者として、組織毎に最大 10 個のメンバーアカウントを登録できます。 AWS Security Hub: securityhub.amazonaws.com AWS Security Hub の 委任された管理者アカウント の登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Security Hub の管理アクションを実行できなくなります。委任された管理者を登録解除しても、その AWS アカウントまたは組織のメンバーアカウントの Security Hub は無効になりません。組織のメンバーアカウントは関連付けを解除され、すべての設定が保持されたまま Security Hub がスタンドアロンで動作する AWS アカウントに変換されます。 AWS Security Hub の委任された管理者を登録解除するには、管理アカウントの Security Hub コンソールまたは AWS CLI の disable-organization-admin-account コマンドを使用する必要があります。Security Hub コンソールを使用する場合、Security Hub 管理者はすべてのリージョンで削除され、組織で指定されている Security Hub の委任された管理者は削除されます。AWS CLI の disable-organization-admin-account コマンドを使用する場合は、組織の管理アカウントの認証情報を使用し、各リージョンの Security Hub 管理者を削除する必要があります。完了したら、AWS CLI の deregister-delegated-administrator コマンドを使用して、組織に指定されている委任された管理者を削除します。 ある AWS アカウントを別の組織に移行する場合、 自動有効化 をオンにしたリージョンでは、その AWS アカウントは自動的に Security Hub の委任された管理者と関連付けられます。AWS アカウントが関連付けられていない場合は、委任された管理者アカウントの Security Hub コンソールを使用して 手動でメンバーアカウントとして追加 できます。 Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com Amazon Simple Storage Service (Amazon S3) Storage Lens の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントに設定された IAM ユーザーおよび IAM ロールは、Amazon S3 Storage Lens の管理アクションを実行したり、組織レベルのダッシュボードを作成することができなくなります。委任された管理者によって作成された Amazon S3 Storage Lens 組織レベルのダッシュボードは、自動的に無効になります。登録解除された AWS アカウントは、データがクエリに使用できるそれぞれの期間に応じて、無効になっているダッシュボードの履歴データを引き続き表示できます。Amazon S3 Storage Lens の委任された管理者として、1 つの組織に組織に最大 5 つのメンバーアカウントを登録できます。 AWS Service Catalog: servicecatalog.amazonaws.com AWS Service Catalog の 委任された管理者 アカウントの登録を解除すると、 IAM ユーザーおよび IAM ロールは、AWS Service Catalog の管理アクションを実行できなくなります。さらに、ポートフォリオを作成、削除、共有する権限がなくなります。この AWS アカウントから作成された AWS Service Catalog ポートフォリオの共有は削除されます。 委任された管理者アカウントによって共有されているポートフォリオから製品をプロビジョニングした AWS アカウントが組織内に 1 つ以上残っている場合は、同じ組織に別の委任された管理者アカウントを設定することで、すべての共有製品を移行できます。また、AWS Service Catalog の委任された管理者として、1 つの組織に最大 50 個のメンバーアカウントを登録できます。組織の管理アカウントに共有ポートフォリオがある場合は、そのポートフォリオを委任された管理者アカウントに移行することを強くお勧めします。 共有製品を同じ組織の AWS Service Catalog の委任された管理者アカウントに移行するには、下記の手順を実施します: 移行元の委任された管理者アカウントの AWS Service Catalog 共有ポートフォリオにプロビジョニング済みの製品が含まれているかどうかを確認します。製品が見つかった場合は、委任された管理者として登録されている別の AWS アカウントのポートフォリオに製品を移行できます。ポートフォリオを共有しているアカウント ID をすべて書き留めておきます。 AWS Service Catalog における別の委任された管理者アカウントを登録します。この AWS アカウントは、全てのプロビジョニング済み製品のポートフォリオの管理に使用されます。 元の製品と同じテンプレートを使用して、移行先の委任された管理者アカウントに新しいポートフォリオを作成します。これにより、プロビジョニング済み製品のリソースが終了したり再作成されたりすることがなくなります。 ステップ 3 で作成したポートフォリオを、ステップ 1 で特定した AWS アカウントに共有してインポートします。これらは、ポートフォリオから作られたプロビジョニング済み製品を持つ AWS アカウントです。 ポートフォリオを共有している各 AWS アカウントで、移行先の委任された管理者アカウントにおける共有された、プロビジョニング済み製品を選択の上で更新して製品を変更します。“Changing the product will update this provisioned product to a different product template. This may terminate resources and create new resources.(製品を変更すると、このプロビジョニング済み製品が別の製品テンプレートに更新されます。これにより、リソースが終了し、新しいリソースが作成される可能性があります。)“ というメッセージが表示されます。元の製品と同じテンプレートを使用してポートフォリオを作成した場合は、このメッセージは無視してかまいません。 移行元の委任された管理者アカウントからすべてのポートフォリオと関連付けられた製品を移行したら、移行元の委任された管理者アカウントのポートフォリオから元の共有を削除できます。移行元の委任された管理者アカウントは登録解除できます。 [オプション] 委任された管理者アカウントの登録を解除しても、委任された管理者が作成したポートフォリオと共有が削除されない場合は、委任された管理者をもう一度登録した上で登録解除します。この 2 番目のアクションにより、この AWS アカウント用に作成されたポートフォリオと共有が削除されます。 プロビジョニング済み製品の AWS アカウントを AWS Service Catalog の共有ポートフォリオから別の組織に移行する場合、その製品を移行先組織のポートフォリオに関連付けることができます。移行先組織における AWS Service Catalog の委任された管理者として登録されたアカウントでポートフォリオと製品を再作成し、その組織内で共有できます。対象の AWS アカウントを移行先組織に参加させて、プロビジョニング済み製品を移行先組織内で共有されている製品に更新できます。このアプローチは、組織を削除する予定で、別の組織に移行しても共有ポートフォリオを維持したい場合に使用できます。 共有製品を別の組織の委任された管理者アカウントに移行するには、下記の手順を実施します: 移行元の委任された管理者アカウントの AWS Service Catalog 共有ポートフォリオにプロビジョニング済みの製品が含まれているかどうかを確認します。製品が見つかったら、そのポートフォリオを共有している AWS アカウント ID をすべて書き留めておきます。 「AWS 組織アカウント」または「AWS アカウント」のいずれかを使用するようにポートフォリオ共有を更新し、上記の移行先組織に移行する AWS アカウントの AWS アカウント ID を指定します。これにより組織から AWS アカウントを削除しても、製品はその AWS アカウントに残ります。 コンシューマーアカウントで、共有ポートフォリオが表示されていない場合は、それをインポートして、製品に対して必要なプリンシパルの権限を更新します。 移行先組織で AWS Service Catalog に関する委任された管理者の AWS アカウントを登録します。この AWS アカウントは、全てのプロビジョニング済み製品のポートフォリオの管理に使用されます。 移行元の製品と同じテンプレートを使用して、移行先の委任された管理者アカウントに新しいポートフォリオを作成します。これにより、プロビジョニング済み製品のリソースが終了したり再作成されたりすることがなくなります。移行元の共有ポートフォリオにおけるプロビジョニング済み製品を保持している移行中 AWS アカウントのために、新しいポートフォリオを元の組織または移行先組織と共有します。 移行元組織からポートフォリオコンシューマーアカウントを削除すると、共有ポートフォリオと製品が表示され、プロビジョニング済み製品は変更されずに残っていることがわかります。 移行先組織にコンシューマーアカウントを追加する際、共有ポートフォリオが表示されていない場合はそれをインポートし、製品に対して必要なプリンシパルの権限を更新します。 ポートフォリオを共有している各 AWS アカウントで、プロビジョニング済み製品を選択し、新しい委任された管理者アカウントから共有した製品に更新します。プロビジョニング済み製品を、移行元組織で共有されていた元の製品から、移行先組織で作成した同じ製品に変更します。“Changing the product will update this provisioned product to a different product template. This may terminate resources and create new resources. (製品を変更すると、このプロビジョニング済み製品が別の製品テンプレートに更新されます。これにより、リソースが終了し、新しいリソースが作成される可能性があります。)“ というメッセージが表示されます。元の製品と同じテンプレートを使用してポートフォリオを作成した場合は、このメッセージは無視してかまいません。 移行元組織の委任された管理者アカウントで、過去に作成した AWS アカウント共有を削除します。これにより、ポートフォリオと製品がコンシューマーアカウントから削除され、新たに共有されたポートフォリオと、新しい所有者のプロビジョニング済み製品のみが残ります。 [オプション] 移行元組織の委任された管理者アカウントが別の組織に移行する場合、移行元の委任された管理者アカウントからすべてのポートフォリオと関連付けられた製品を移行したら、この AWS アカウントを委任された管理者として登録解除できます。 [オプション] 委任された管理者アカウントの登録を解除しても、委任された管理者が作成したポートフォリオと共有が削除されない場合は、委任された管理者をもう一度登録した上で登録解除します。このアクションにより、この AWS アカウント用に作成されたポートフォリオと共有が削除されます。 AWS Systems Manager: ssm.amazonaws.com AWS Systems Manager の 委任された管理者 アカウントの登録を解除すると、AWS Systems Manager Explorer と Change Manager の両方に影響します。AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、AWS Systems Manager Explorer または Change Manager の管理アクションを実行できなくなります。この AWS アカウントは、組織のリソースデータ同期の API オペレーションにアクセスできなくなります。AWS Systems Manager Explorer は、委任された管理者の組織のリソースデータ同期とそれに含まれるデータをすべて削除します。このアクションを実施すると、元に戻すことはできなくなります。この AWS アカウントでは、変更テンプレート、変更リクエスト、変更ランブック、承認ワークフローの管理など、組織全体の Change Manager アクティビティを管理できなくなります。委任された管理者アカウントで作成された、複数の組織単位 (OU) に変更を適用する Change Manager リクエストはすべて残ります。ただし、これらは正常に実行されません。これには、スケジュールされたリクエストや承認待ちのリクエストも含まれます。 AWS Trusted Advisor: reporting.trustedadvisor.amazonaws.com AWS Trusted Advisor の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、AWS Trusted Advisor の管理アクションを実行できなくなります。その AWS アカウントは、Trusted Advisor Priority のレコメンデーションを確認、承認、解決、拒否、および再開できなくなります。さらに、Trusted Advisor Priority からのメール通知は届かなくなります。AWS Trusted Advisor の委任された管理者として、組織に最大 5 つのメンバーアカウントを登録できます。 Amazon VPC IP Address Manager (IPAM): ipam.amazonaws.com Amazon VPC IP Address Manager (IPAM) の 委任された管理者 アカウントの登録を解除すると、その AWS アカウントで設定された IAM ユーザーおよび IAM ロールは、IPAM の管理アクションを実行できなくなります。この AWS アカウントでは、組織内の IP アドレス割り当てを管理および監視できなくなり、組織のメンバーアカウント間で IPAM プールを共有することもできなくなります。委任された管理者を削除するには、組織の管理アカウントの IPAM コンソールまたは AWS CLI の disable-ipam-organization-admin-account コマンドを使用できます。 AWS アカウントの登録を解除したときに、AWS RAM を使用して IPAM プールを組織で共有している場合、リソース共有は保持されます。ただし、メンバーアカウントは共有 IPAM にアクセスできなくなります。このような共有 IPAM プールを使用しようとすると、“The operation AllocateIpamPoolCidr is not supported. Account <account-id> is not monitored by IPAM ipam-<ipam-id>.(AllocateIPamPoolCIDR 操作はサポートされていません。<account-id> は IPAM <ipam-id> によって監視されていません。)”という例外処理が表示されます。AWS アカウントが組織を離れると、IPAM プールのリソース共有内の組織のプリンシパルはすべて自動的に共有から切り離されます。 IPAM の委任された管理者として登録されていて、かつ組織の共有 IPAM プールを持つ AWS アカウントを別の組織に移行する場合は、同じ IPAM プール構成を別の AWS アカウントに設定できます。現在の委任された管理者の登録を解除したら、代替の IPAM を設定した AWS アカウントを委任された管理者として登録し、組織で共有します。組織に残っている AWS アカウント、または以前に共有された IPAM プールから CIDR ブロックが割り当てられた Amazon VPC を持つ AWS アカウントは、新しく設定された IPAM プールに引き継がれます。 IPAM の委任された管理者として登録されている AWS アカウントを移行する場合、AWS アカウントを移行した後でも、移行先組織の AWS アカウントで保持されている IPAM を使用できます。IPAM を維持して使用する計画がある場合は、移行元組織に残る AWS アカウントのリソースに対する CIDR ブロックの 割り当ての解除 を検討する必要があります。そうしなければ、CIDR ブロックは引き続き割り当て済みとしてマークされます。移行先組織に移行しない AWS アカウントのリソースに割り当て済みとマークされた CIDR ブロックは、移行先組織の委任された管理者による管理対象ではなくなります。移行先組織で IPAM を使用するには、その AWS アカウントを IPAM の委任された管理者として登録する必要があります。その AWS アカウントでは、移行先組織のプリンシパルを関連付けるように、AWS RAM リソース共有を変更する必要があります。IPAM から CIDR ブロックが割り当てられた Amazon VPC を持つ同じ組織に移行した AWS アカウントが追跡されます。移行先組織にすでに IPAM の委任された管理者がいる場合は、その組織に移行する AWS アカウントのリソースに割り当てるための CIDR ブロックを使用する新規または既存の IPAM を構成できます。 まとめ このブログでは、委任の機能と互換性のある AWS サービスに関して、組織の中で委任された管理者を特定し、そのような AWS アカウントを移行する場合の動作とアクションを特定するための解説をしました。組織の委任された管理者として登録されている AWS アカウントは、組織を削除する前に登録を解除する必要があることを学びました。またある AWS アカウントが、いずれかの AWS サービスの委任された管理者であるかどうかを判断する方法と、AWS アカウントを委任された管理者から解除するときに想定される動作と実行するアクションについても学びました。 このブログシリーズでは、AWS Organizations のさまざまな機能を順を追って説明し、AWS Organizations を使用する場合や、AWS アカウントをある組織から別の組織に移行する際のガイダンスと注意を解説しています。 シリーズの 第 1 部 ( 日本語 ) では、AWS Organizations のさまざまな機能について説明し、AWS Organizations を使用して AWS アカウントをある組織から別の組織に移行する場合のガイダンスと注意を解説しました。 第 3 部 では、組織内で「信頼されたアクセス」が設定された AWS サービスを特定し、AWS アカウントを移行する前のアクションと動作を解説します。 ブログ著者について: Karl Schween Karl Schween は、Amazon Web Services の Principal Solutions Architect です。彼は、お客様がビジネス上の問題に対処できるような、拡張性が高く柔軟で回復力のあるクラウドアーキテクチャを構築できるよう支援しています。 Deepa Pahuja Deepa Pahuja は、Amazon Web Services の Senior Solutions Architect です。Deepa は、お客様と協力して、クラウドネイティブサービスを使用してビジネス上の問題を解決するアーキテクチャを構築することを楽しんでいます。仕事以外では、Deepa は新しい場所の探検、ハイキング、ダンスを楽しんでいます。 翻訳はプロフェッショナルサービス本部の須田が担当しました。原文は こちら です。

コンタクトセンターを管理されている方であれば、エージェントが顧客の信頼とロイヤリティの構築に果たす重要な役割をご存知でしょう。コンタクトセンターに問い合わせをしたことのある人なら、複雑な意思決定を導き、必要な場合には迅速かつ正確なソリューションを提供するエージェントがいかに重要であるかをご存知でしょう。これには時間がかかり、正しく行われなければ、フラストレーションにつながりかねません。 Amazon Connect の生成系 AI 機能 本日、コンタクトセンターが顧客にサービスを提供する方法を変革するために、 Amazon Connect の既存の人工知能（AI）機能に、 Amazon Bedrock を通じて利用可能な大規模言語モデル（LLM） を活用した生成系 AI 機能が追加されたことを発表します。LLM は、一般に基盤モデル（FM）として知られる膨大な量のデータで事前に訓練されており、理解し、学習し、テキストを生成し、インタラクティブな会話に参加し、質問に答え、ダイアログや文書を要約し、推奨することができます。 Amazon Q in Connect：カスタマーサポートを迅速に行うために推奨される応答とアクション 組織は常に変化しています。このような組織の変化に対応し、高いレベルのパフォーマンスを維持するために、コンタクトセンターでは、エージェントの採用、トレーニング、コーチングを継続的に行っています。トレーニングやコーチングを受けたとしても、エージェントは顧客に卓越したサービスを提供するために、製品ガイドや組織の方針など、さまざまな情報源を検索しなければなりません。これは、顧客の待ち時間を増やし、顧客満足度を下げ、コンタクトセンターのコストを増加させる可能性があります。 Amazon Q in Connect は、Amazon Connect Wisdom として提供されていた機能を含む、生成系 AI を搭載したエージェントアシスタントで、顧客の意図を理解し、関連する情報源を使用して、エージェントが顧客固有のニーズを伝え、解決するための正確な応答とアクションを、すべてリアルタイムで提供します。2024 年 3 月 1 日まで、Amazon Q in Connect を無料でお試しいただけます。この機能は簡単に有効化でき、Amazon Connect コンソールで開始できます。 Amazon Connect Contact Lens: 生成されたコンタクト要約で生産性向上 顧客とのやり取りを改善し、今後の参考のために詳細を確認できるようにするために、コンタクトセンターの管理者は、エージェントが顧客とのやり取りの後に手動で作成するメモを頼っています。これらのメモには、顧客の問題にどのように対処したか、会話の重要な瞬間、保留中のフォローアップ項目などの詳細が含まれます。 Amazon Connect Contact Lens は、生成系 AI を搭載したコンタクトの要約を提供し、コンタクトセンターの管理者がより効率的にコンタクトの品質とエージェントのパフォーマンスを監視し、改善することを可能にします。例えば、要約を使用して、顧客との約束を追跡し、フォローアップアクションの迅速な完了を確認することができます。顧客との対話の後に、Contact Lens は会話を簡潔にまとめて要約します。 Amazon Connect in Amazon Lex：スロット解決の支援機能を提供 Amazon Lex を使用することで、チャットボット、バーチャルエージェント、インタラクティブボイスレスポンス（IVR）を構築することができます。これにより、顧客は人間のエージェントに話しかけることなく予約をすることができます。例えば、「自分と2人の子供の旅行の予約を変更したい」という場合、従来のボットでは数値（旅行の予約は何人か？）を解釈するのが難しいかもしれません。 新しいスロット解決支援機能により、Amazon Lex はユーザーの発話からスロットの値を非常に正確に解決できるようになりました（例えば、先ほどの質問に対して正しい数値 3 と答える）。これは、精度を向上させ、より良い顧客体験を提供する LLM の高度な推論機能によるものです。より良いセルフサービス体験の構築を支援する新しい生成系 AI 機能を含めた、 Amazon Lex の機能 の全てをご覧ください。 Amazon Connect Customer Profiles：パーソナライズされた顧客体験のための統一された顧客プロファイルを迅速に作成 顧客はパーソナライズされた顧客サービス体験を期待しています。これを提供するために、コンタクトセンターは顧客の嗜好、購買、インタラクションを包括的に理解する必要があります。これを実現するために、コンタクトセンターの管理者は、多くのアプリケーションからの顧客データを統合することで、統一された顧客プロファイルを作成します。これらのアプリケーションは、それぞれ異なるタイプの顧客データをさまざまなデータストアにさまざまなフォーマットで保存しています。これらのさまざまなデータストアからデータをつなぎ合わせるには、コンタクトセンター管理者はデータを理解し、それをどのように整理して統一されたフォーマットにまとめるかを考えなければならず、そのために、統一された顧客プロファイルをコンパイルするのに数週間を費やしています。 本日より、 Amazon Connect Customer Profiles は LLM を使用することで、統一された顧客プロファイルの作成に必要な時間を短縮します。コンタクトセンター管理者が Amazon Simple Storage Service（Amazon S3） 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデータソースを追加すると、Customer Profiles はデータを分析し、データフォーマットとコンテンツが何を表しているか、データが顧客のプロファイルにどのように関連しているかを理解します。そして、Customer Profiles は、異なるソースからのデータをどのように整理し、組み合わせて完全で正確なプロファイルにするかを自動的に決定します。わずか数ステップで、管理者は顧客プロファイルを確認し、必要な編集を行い、セットアップを完了することができます。 Amazon Connect のアプリ内、Web、ビデオ通話機能 組織として、あなたは素晴らしく、使いやすく、便利な顧客サービスを提供したいと考えています。この記事の前半で、セルフサービスのチャットボットと、それがどのように役立つかをお話ししました。時には、顧客はチャットや音声通話よりも密なコミュニケーションを希望することがあります。 Amazon Connect には、 アプリ内、Web、ビデオ通話機能 があり、リッチでパーソナライズされた顧客体験の提供を支援します。フルマネージドなコミュニケーションウィジェットを使用すれば、数行のコードだけで、Web やモバイルアプリケーションにこれらの機能を実装することができます。これにより、顧客はページを離れることなく、Web またはモバイルアプリケーションを通じてサポートを受けることができます。ビデオは、エージェントのみ、顧客のみ、またはエージェントと顧客の両方で有効にすることができます。 Amazon Connect SMS：双方向 SMS 機能 ほとんどの人がモバイルデバイスを所有しており、外出先でもテキストベースのサポートを受けられる柔軟性を好んでいます。コンタクトセンターのリーダーはこのことを知っており、これまでは顧客に双方向の SMS を提供するために、独立したサードパーティのソリューションに頼ってきました。 Amazon Connect は、コンタクトセンターのリーダーがこの柔軟性を提供できるように、 双方向 SMS 機能 の提供を開始しました。これにより、顧客満足度が向上し、コストのかかるサードパーティのソリューションと統合することなく、エージェントの生産性が向上します。SMS チャットは、通話やチャットと同じ設定で、 Amazon Connect Agent Workspace や分析も有効にすることができます。 詳細はこちら Amazon Q in Connect 製品ページ Amazon Connect の使用を開始するユーザーガイド 機能をサポートするリージョンは こちら サポートされる言語は こちら フィードバックの送信 AWS re:Post for Amazon Connect 、またはAWSサポート窓口からご連絡ください。 – Veliswa Veliswa Boya Veliswa Boyaは、シニア・デベロッパー・アドボケイトで、南アフリカを拠点にサハラ以南のアフリカのビルダー・コミュニティと緊密に連携しています。開発者からアナリスト、アーキテクト、クラウドエンジニア、そして現在はデベロッパー・アドボケイトと、技術分野で多くの役割を担っています。Veliswaは特に、技術初心者やAWSを使い始めたばかりの人たちとの仕事を楽しんでいます。 翻訳は、ソリューションアーキテクトの濱上が担当しました。原文は こちら です。

AWSは EventBridge Pipesによるロギング のサポートを発表しました。 Amazon EventBridge Pipes は、イベントのプロデューサとコンシューマを接続し、オプションでフィルタ、変換、エンリッチメントを行うことができるポイント・ツー・ポイントの統合ソリューションです。EventBridge Pipesを利用することで、イベント駆動型アプリケーションを構築する際に、開発者が記述・管理する必要のある統合コードの量を削減できます。よくある統合ソリューションには、 Amazon Kinesis streamsとフィルタリングの接続、 Amazon DynamoDB と Amazon EventBridge の統合、 Amazon SQS と AWS Step Functions の統合などがあります。 EventBridge Pipesのロギングでは、パイプ実行のさまざまな段階についての洞察が得られます。これは Amazon CloudWatchのメトリクスサポート を拡張し、トラブルシューティングとデバッグのための方法を提供します。 パイプの実行ステップ内の様々な成功シナリオと失敗シナリオを把握できるようになりました。イベント変換またはエンリッチメントが成功または失敗した場合、ログを使用してより深く掘り下げ、構成されたパイプに問題がないかトラブルシューティングを開始することができます。 EventBridge Pipesの実行ステップ パイプの実行ステップを理解することは、ログに記録される情報の量を決定する適切なログレベルを選択するのに役立ちます。 パイプの実行は、ソースからターゲットに移動するパイプによって受信されるイベントまたはイベントのバッチです。イベントがパイプを通過すると、 AWS Step Functions 、 AWS Lambda 、 Amazon API Gateway 、 EventBridge API Destinations を使用して、フィルタリング、変換、またはエンリッチメントをすることができます。 パイプの実行は、エンリッチメントとターゲットの2つの主要なステージで構成されます。これらのステージは両方とも、変換と呼び出しのステップを含みます。 Input Transformer を使用すると、イベントがエンリッチメントを受けたり、下流のターゲットにディスパッチされる前に、イベントのペイロードを変更することができる。これにより、構成されたパイプの実行中に、イベントデータの操作をきめ細かく制御することができます。 パイプの実行が開始されると、実行はエンリッチメントの段階に入ります。エンリッチメントステージを設定しない場合、実行はターゲットステージに進みます。 パイプの実行、変換、エンリッチメント、ターゲットの各フェーズで、EventBridge はデバッグやトラブルシューティングに役立つ情報をログに記録できます。パイプのログには、ペイロード、エラー、変換、AWSリクエスト、AWSレスポンスが含まれます。 パイプ実行の詳細については、 こちらのドキュメント を参照してください。 EventBridge Pipes でログレベルを設定 パイプでロギングを有効にすると、EventBridge は実行ステップごとにログ・エントリを作成し、これらのログを指定したログ宛先に送信します。 EventBridge Pipesは3つのログ送信先をサポートしています： Amazon CloudWatch Logs、 Amazon Kinesis Data Firehose stream、 Amazon S3 です。送信されるレコードは、パイプのログ・レベル（OFF、ERROR、INFO、TRACE）を設定することでカスタマイズできます。 OFF – EventBridge はレコードを送信しません。 ERROR – EventBridge は、パイプの実行中に発生したエラーに関連するレコードを送信します。例えば、Execution Failed、Execution Timeout、Enrichment Failures などがあります。 INFO – EventBridge は、パイプ実行中に実行されたエラーと選択された情報に関連するレコードを送信します。例としては、Execution Started、Execution Succeeded、Enrichment Stage Succeeded などがあります。 TRACE – EventBridge は、パイプ実行の任意のステップ中に生成されたすべてのレコードを送信します。 ERRORログレベルは、失敗したパイプ実行の背後にある理由を知る上で有益です。パイプ実行はタイムアウト、エンリッチメントの失敗、変換の失敗、ターゲット呼び出しの失敗など、さまざまな理由で失敗することがあります。ERROR ログを有効にすると、パイプエラーの具体的な原因を知ることができ、問題の解決が容易になります。 INFOログレベルは、ERROR情報をさらに詳細に補足します。INFO ログレベルは、エラーを通知するだけでなく、パイプ実行の開始、エンリッチメントフェーズへの移行、変換フェーズへの移行、ターゲットステージの開始と正常終了に関する洞察を提供します。 より詳細な分析のために、パイプの実行に関する包括的な洞察を得るために TRACE ログレベルを使用することができます。これはサポートされている全てのパイプログを包含し、INFO や ERROR ログを超えた詳細なビューを提供します。TRACE ログレベルでは、スキップされたパイプ実行ステージや、変換やエンリッチメントプロセスの開始などの重要な情報が明らかになります。 ログレベルと送信されるログの詳細については、 ドキュメントを参照 してください。 EventBridge Pipesのロギングに実行データを含める さらにデバッグを助けるためにパイプログ内に実行データを含めることを選択できます。このデータはイベントペイロード、AWS リクエスト、および構成されたエンリッチメントとターゲットコンポーネントに送受信されたレスポンスで構成されます。 また、パイプの実行中に AWS サービスに送信されたペイロード、リクエスト、およびレスポンスに関するさらなる洞察を得るために、実行データを使用することもできます。 実行データを組み込むことで、パイプの実行をより深く理解し、発生した問題のデバッグを支援することができます。 ログ内の実行データには3つの部分があります： payload ： イベント自体の内容。イベントのペイロードには機密情報が含まれている可能性があり、EventBridge はその内容を編集しようとしません。実行データを含めるかどうかはオプションで、オフにすることもできます。 awsRequest ： エンリッチメントまたはターゲットにシリアライズされた JSON 形式で送信されたリクエスト。API Destinations の場合、これにはそのエンドポイントに送信された HTTP リクエストが含まれます。 awsResponse ： エンリッチメントまたはターゲットがJSON形式で返すレスポンス。 API Destinations の場合、これは設定されたエンドポイントから返されるレスポンスです。 イベントのペイロードは、イベント自体が更新可能な場合に入力されます。これらのステージには、最初のパイプ実行、エンリッチメントフェーズ、ターゲットフェーズが含まれる。 awsRequest と awsResponse は、どちらもエンリッチメントとターゲティングの最終段階で生成されます。 ログレベルと実行データの詳細については、 こちらのドキュメント をご覧ください。 EventBridge Pipes ログを使い始める この例では、ロギングを有効にして実行データを含むパイプを作成します。パイプは、エンリッチメントステップなしでターゲット上の入力トランスフォーマーを使用して2つの Amazon SQS キューを接続します。Input Transformer は、ターゲットに到達する前にイベントのペイロードをカスタマイズします。 ソースキューとターゲットキューの作成 # ソース用のキューを作成する aws sqs create-queue --queue-name pipe-source # ターゲット用のキューを作成する aws sqs create-queue --queue-name pipe-target EventBridge Pipesに移動し、 Create pipe を選択します。 ソースとして SQS を選択し、SQS q ueue として pipe-source を選択します。 フィルタリングとエンリッチメントのフェーズをスキップして、新しい Target を追加します。Target サービスとして SQS を、 Queue として pipe-target を選択します。 ターゲット入力トランスフォーマセクションを開き、トランスフォーマーフィールドにトランスフォーマーコードを入力します。 { "body": "Favorite food is <$.body>" } Pipe settings を選択して、新しいパイプのロググループを設定します。 CloudWatch Logs がログ宛先として設定されていることを確認し、ログレベルとして Trace を選択する。“ Include execution data ” チェックボックスをチェックします。これにより、全てのトレースが新しいCloudWatchロググループにログされ、パイプで送信されるSQSメッセージが含まれます。 Create Pipe を選択 送信元キューに SQS メッセージを送信します。 # キューURLの取得 aws sqs get-queue-url --queue-name pipe-source # URLを使ってキューにメッセージを送信する aws sqs send-message --queue-url {QUEUE_URL} --message-body "pizza" 全てのトレースログはモニタリングタブに表示されます。詳細は CloudWatch Logs セクションを参照してください。 まとめ EventBridge Pipes は、イベント・プロデューサとコンシューマ間のポイント・ツー・ポイントの統合を可能にします。EventBridge Pipes でログがサポートされたことで、パイプ実行のさまざまな段階を把握できるようになりました。パイプのログ送信先は CloudWatch Logs、Kinesis Data Firehose、Amazon S3 に設定できます。 EventBridge Pipes は3つのログレベルをサポートしています。 ERROR ログレベルは、エラーに関連するレコードをログ宛先に送信するように EventBridge を構成します。 INFO ログレベルは、パイプ実行中のエラーおよび選択された情報に関連するレコードを送信するように EventBridge を構成します。 TRACE ログレベルは、生成されたすべてのレコードをログ宛先に送信します。 ログに実行データを含めることができ、これにはイベント自体、およびパイプで構成された AWS サービスに対して行われたAWSリクエストとレスポンスが含まれます。これは、パイプの実行に関する更なる洞察を得るのに役立ちます。 EventBridge Pipes Logs の詳細については、ドキュメントをお読みください。 サーバーレスの学習リソースについては、 Serverless Land をご覧ください。 この記事の翻訳は Solutions Architect ポールが担当しました。原文は こちら からご覧いただけます。

はじめに 収益の拡大、業務の効率化、コストの削減を目的に、モノのインターネット (IoT) ソリューションを採用する企業経営者が増えています。産業用機械であれ自律走行車であれ、自社の機器をクラウドに接続しながらセキュリティと安全性を配慮するのは難しいことです。AWS は インダストリアルIoTソリューションにおける10のセキュリティゴールデンルール の中で、製造環境からクラウドへのセキュアな接続と、オンプレミスのリソースへのセキュアなリモートアクセスを確立することを推奨しています。同様に、コネクテッド・モビリティ・ソリューションでは、一般的にプライベート・セルラー・ネットワークを使用して車両をクラウド・サービスに接続しています。 このブログでは、プライベートネットワークを使用して IoT デバイスを安全かつセキュアに AWS に接続するための一般的なアーキテクチャパターンとベストプラクティスについて説明します。 AWS IoT Core 認証プロバイダ の Virtual Private Cloud (VPC) エンドポイント機能 を利用することで、 AWS IoT Greengrass を搭載したデバイスを、パブリックなインターネットアクセスなしに VPC 内で動作させることが可能になりました。さらに、これらのデバイスは AWS PrivateLink を使用して Amazon Elastic Container Registry (Amazon ECR)、 AWS Secrets Manager 、 Amazon CloudWatch logs などの他の AWS サービスにアクセスできます。このアプローチは、プライベート接続を確立しインターネットからネットワークトラフィックを分離することで、接続ソリューションの安全性をより柔軟に確保し、また組織のセキュリティベストプラクティスに準拠するのに役立ちます。 ソリューション概要 このソリューションでは、Amazon VPC 内のプライベートエンドポイントを使用して IoT デバイスを AWS IoT Core と AWS IoT Greengrass に接続できます。プライベートエンドポイントは、仮想ネットワークアドレス空間からのプライベート IP アドレスを使用して、デバイスを VPC 内の AWS IoT Core データエンドポイント と AWS IoT Greengrass にプライベート接続します。 インターフェイス VPC エンドポイント は、インターネットにデータを晒すことなく VPC と AWS サービス間の接続を確立するために使用できる AWS サービスである AWS PrivateLink によって提供されるサービスに接続するために使用されます。接続されたデバイスと AWS IoT Core および AWS IoT Greengrass 間のネットワークトラフィックは、 AWS site-to-site VPN または AWS Direct Connect を使用し、パブリックインターネットへの接続を回避します。ソリューションアーキテクチャとソリューションコンポーネントについて説明します。 シナリオ1：IoT デバイスをプライベートネットワークを使って AWS IoT Core に接続する 図1：プライベートネットワークを通じて AWS IoT Core に接続する工場内の IoT デバイス ソリューションの説明 この手順には以下のステップが含まれています： 工場にあるアセットは「AWS IoT データエンドポイント」のドメイン名を解決する必要があります。AWS IoT デバイスデータエンドポイントは、IoT デバイスの通信ニーズに合わせて設計されたパブリッシュ/サブスクライブプロトコルをサポートしています。事前に構成されたドメインネームシステム (DNS) リゾルバにクエリを送信します。 企業データセンターの DNS リゾルバ には「AWS IoTデータエンドポイント」DNSドメインのすべての DNS クエリをAmazon Route 53 Resolver インバウンド エンドポイントに向ける条件付きフォワーダルールが設定されています。 転送されたクエリは、AWS Direct Connect または AWS Site-to-Site VPN を介して Amazon Route 53 Resolver インバウンドエンドポイントに到着します。すべてのインバウンド DNS クエリは、リゾルバに向かう途中でこの VPC を通過します。信頼性を高めるため、リゾルバでは DNS クエリに 2 つの IP アドレスを指定する必要があります。高可用性を実現するために、2つの異なるアベイラビリティゾーンに IP アドレスを指定することを推奨します。 Amazon Route 53 Resolver インバウンドエンドポイントは、VPC 内の VPC + 2リゾルバにクエリを送信します。 Amazon Route 53 Resolver は、AWS IoT Core データドメイン名の DNS クエリを解決します。 VPC に関連付けられたプライベートホストゾーンは、AWS IoT Core データエンドポイントの DNS レコードを保持するため、Amazon Route 53 Resolver はクエリを解決できます。 AWS IoT Core データエンドポイント宛てのトラフィックは、DNS を使用してエンドポイントのネットワークインターフェイスのプライベート IP アドレスに解決され、VPC エンドポイントと AWS IoT Core 間の接続を使用して AWS サービスにプライベートで送信されます。 セキュリティーを考慮するため、 VPC インターフェイスのエンドポイントにセキュリティグループとネットワーク ACL を設定します VPC 条件コンテキストキーを使用して、VPC エンドポイントを介した AWS IoT Core データへのアクセスを制御します 以下の表は、AWS IoT データ VPC エンドポイントに必要な詳細を示しています。詳細は ドキュメント をご覧ください。 図2：IoT デバイスに対応する DNS エイリアスを持つ VPC エンドポイント 図3：AWS コンソールでの VPC エンドポイントの設定 注: インタフェース VPC エンドポイントの作成 に関する詳細は、 AWS IoT Core とインターフェース VPC エンドポイントの作成 と共に参照してください。Amazon Route 53 でプライベートホストゾーンを作成する詳細については、 ドキュメント を参照してください。 シナリオ 2: AWS IoT Greengrass を搭載したデバイスが AWS IoT 認証情報 VPC エンドポイントを使用して AWS IoT Core に接続する場合 図4：プライベートネットワーク経由で AWS IoT Core に接続する AWS IoT Greengrass 搭載デバイス ソリューションの説明 この手順には以下のステップが含まれています： AWS IoT Greengrass クライアントデバイスであるセンサーは、MQTT を介して AWS IoT Greengrass コアデバイスと接続し、通信します。エッジの AWS IoT Greengrass コアソフトウェアは「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon Simple Storage Service (Amazon S3)」ドメイン名を解決する必要があります。事前に設定された DNS リゾルバにクエリを送信します。ユースケースに基づき、追加のエンドポイントが必要になる場合があります。 企業データセンターの DNS リゾルバには「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」 の DNS ドメインに対するすべての DNS クエリを Amazon Route 53 Resolver インバウンドエンドポイントに向ける条件付きフォワーダールールがあります。 転送されたクエリは、AWS Direct Connect または AWS Site-to-Site VPN を介して Amazon Route 53 Resolver インバウンド エンドポイントに到達します。すべてのインバウンド DNS クエリは、リゾルバに向かうに途中でこの VPC を通過します。信頼性を高めるため、リゾルバでは DNS クエリに 2 つの IP アドレスを指定する必要があります。高可用性を実現するために、2つの異なるアベイラビリティゾーンに IP アドレスを指定することを推奨します。 Amazon Route 53 Resolver インバウンドエンドポイントは、VPC 内の VPC + 2リゾルバにクエリを送信します。 Amazon Route 53 Resolver は、「AWS IoT データエンドポイント」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」の DNS クエリを解決します。 VPC に関連付けられた プライベートホストゾーンは、Amazon Route 53 Resolver がクエリを解決できるように、「AWS IoT データ」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」 の DNS レコードを保持します。 「AWS IoT データ」、「AWS IoT 認証情報プロバイダ」および「Amazon S3」エンドポイント宛てのトラフィックは、DNS を使用してエンドポイントのネットワークインターフェースのプライベート IP アドレスに解決され、VPC エンドポイントと AWS IoT Core 間の接続を使用して AWS サービスにプライベートに送信されます。 注: AWS IoT Greengrass Core ソフトウェアがコンポーネントをデプロイする際、AWS からコンポーネントのアーティファクトをダウンロードします。Amazon S3 の VPC エンドポイントを設定することにより、Greengrass Core デバイスがこれらのアーティファクトに安全かつ効率的にアクセスできるようになります。 AWS IoT Greengrass nucleus の設定では、greengrassDataPlaneEndpoint を iotdata に設定する必要があります。詳細は Greengrass nucleus configuration を参照してください。この設定は、Greengrass nucleus が AWS IoT Greengrass サービスと通信するために使用するエンドポイントを指定します。iotdata に設定することで、Greengrass Core は AWS IoT Greengrass と通信するために AWS IoT データプレーンエンドポイントを使用します。この設定は、コアデバイスが AWS IoT Core と効率的に通信し、運用やデプロイに必要なデータを送受信できるようにするために重要です。 次の表は、対応するカスタム・プライベート DNS エイリアスに関する情報です。詳細については、 ドキュメント を参照してください。 図5：AWS IoT Greengrass 搭載デバイスに対応する DNS エイリアスを持つ VPC エンドポイント AWS IoT データエンドポイント (com.amazonaws.region.iot.data) は、AWS IoT Greengrass サービスのコンポーネント、デプロイメント、コアデバイスを管理するために使用されます。 このエンドポイントでの認証と認可は、「 AWS IoT Greengrass のデバイス認証と認可 」で説明されているように、X.509 証明書を使用して行われます。 IoT のユースケースと使用する機能によっては、追加のエンドポイントが必要になる場合があります。たとえば、AWS が提供する AWS IoT Greengrass コンポーネントの場合、コンポーネントが機能するために必要なサービスを理解するためにドキュメントを参照してください。よくある例をいくつか挙げます: 図 6: AWS サービス VPC エンドポイントの例 AWS IoT 認証情報プロバイダ VPC エンドポイント (com.amazonaws.<region>.iot.credentials) は、 Amazon Simple Storage Service (Amazon S3) や Amazon Elastic Container Registry (Amazon ECR) のような、X.509 認証と認可をサポートしていない他の AWS クラウド サービスと通信するために使用されます。これらの場合、AWS IoT Core または AWS IoT Greengrass コンポーネントは、X.509 証明書を使用して AWS IoT 認証情報プロバイダのエンドポイントを呼び出し、認証と承認を取得します。エンドポイントは、クライアントが X.509 をサポートしていないサービスの呼び出しに使用する一時的なセキュリティ トークンを発行します。 Amazon S3 と Amazon ECR サービスへの呼び出しは、AWS IoT Greengrass コンポーネントのデプロイ時に必要です。また、AWS IoT Greengrass コンポーネントは、AWS SDK を使用して X.509 証明書の認証および認可メカニズムをサポートしていない他のクラウド サービスと通信する場合にもセキュリティトークンを必要とします。独自のコンポーネントを使用している場合は、依存関係を確認し、追加のエンドポイントが必要かどうかを判断するために追加のテストを実行する必要があるかもしれません。 VPC エンドポイント経由での AWS IoT Core へのアクセス制御 VPC 条件コンテキストキーを使用することで、AWS IoT Core へのデバイスアクセスを VPC エンドポイント経由のみに許可するように制限できます。SourceVpc キーを使用して、ポリシーで指定した VPC からのリクエストかどうかを確認できます。SourceVpce キーを使用して、リクエストの VPC エンドポイント識別子とポリシーで指定したエンドポイント ID を比較し、特定の VPC エンドポイントへのアクセスを制限します。VPCSourceIp を使用すると、リクエストの送信元 IP アドレスをポリシーで指定した IP アドレスと比較できます。 注: このポリシーはパブリック IoT データ・エンドポイントへの接続試行を拒否します AWS IoT Greengrass 用の VPC エンドポイントポリシーの作成 CreateDeployment や ListEffectiveDeployments など、AWS IoT Greengrass のコントロールプレーン操作用のインターフェイス VPC エンドポイントを作成する場合、VPC エンドポイントポリシーを使用して、AWS IoT Greengrass のコントロールプレーン操作へのアクセスを制御することができ、セキュリティ体制の改善に役立ちます。ポリシーは以下の情報を指定します： アクションを実行できるプリンシパル プリンシパルが実行できるアクション プリンシパルがアクションを実行できるリソース 以下は、AWS IoT Greengrass のエンドポイントポリシーの例です。エンドポイントにアタッチすると、このポリシーは、すべてのリソースのすべてのプリンシパルに、リストされた AWS IoT Greengrass アクションへのアクセスを許可します。 { "Statement": [ { "Principal": "*", "Effect": "Allow", "Action": [ "greengrass:CreateDeployment", "greengrass:ListEffectiveDeployments" ], "Resource": "*" } ] } AWS IoT data VPC エンドポイントと AWS IoT Core 認証情報プロバイダエンドポイントの制限事項 このブログを書いている時点では、IoT データ VPC エンドポイントと 認証情報プロバイダエンドポイントにはいくつかの制限があります。例えば、 IoT データ VPC エンドポイントの MQTT ベースのキープアライブ期間は230秒に制限され、各 VPC エンドポイントは最大 10 万台の同時接続デバイスをサポート 両方のエンドポイントで許可されるのは IPv4 トラフィックのみ どちらのエンドポイントも Amazon Trust Service (ATS) 証明書のみを提供し、VPC エンドポイントポリシーはサポートされない ただし、これら制限はありますが AWS IoT Core データエンドポイントと AWS IoT Core 認証情報プロバイダ機能は、プライベートネットワークを使用して多数のデバイスを AWS に接続するための安全な方法を提供します。機能と制約に関する最新情報については、 AWS のドキュメント を確認してください。 まとめ デバイスは様々な環境、場所、シナリオでデプロイされるため、IoT ソリューションを実装する際には柔軟性とセキュリティが必要です。このブログでは、プライベートネットワークを使用して IoT 実装されたデバイスと AWS IoT Greengrass を搭載したデバイスを AWS IoT Core と他の AWS サービスに安全に接続するためのアーキテクチャとベストプラクティスについて説明しました。このソリューションは、接続されたデバイスとネットワークをインターネットから分離し、プライベートネットワークを使用して AWS にデータを送信する機能を提供します。このアプローチは、プライベートネットワーク上で安全な通信を確立し、パブリックネットワークにおけるセキュリティ事象から AWS リソースを保護するのに役立ち、組織のセキュリティベストプラクティスと要件に沿った運用を可能にします。詳細については、 AWS IoT でのセキュリティ をご覧ください。 リソース: インターフェイスVPCエンドポイントでAWS IoT Coreを使用する https://docs.aws.amazon.com/iot/latest/developerguide/IoTCore-VPC.html AWS Direct Connect https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html VPC エンドポイントを経由しての AWS IoT Core へのアクセス制御 https://docs.aws.amazon.com/iot/latest/developerguide/IoTCore-VPC.html#Control-VPC-access VPCとネットワーク間のDNSクエリの解決 https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html Back to Basics: Understanding IOT Core VPC Endpoint Patterns https://www.youtube.com/watch?v=r0NzJjMjhyw AWS IoT Greengrass とインターフェイス VPC エンドポイント (AWS PrivateLink) https://docs.aws.amazon.com/greengrass/v2/developerguide/vpc-interface-endpoints.html     Ryan Dsouza は、AWS のプリンシパル・インダストリアル IoT (IIoT) セキュリティ・ソリューション・アーキテクトです。Ryan はニューヨークを拠点に、AWS の広範かつ深い機能を使って、より安全でスケーラブルかつ革新的な IIoT ソリューションの設計、開発、運用を支援し、測定可能なビジネス成果を提供しています。Ryan は、デジタル・プラットフォーム、スマート製造、エネルギー管理、ビルディング・オートメーション、産業オートメーション、OT/IIoT セキュリティなど、さまざまな業界で 25 年以上の経験を積んでいます。Ryan は、すべてのコネクテッドデバイスにセキュリティを導入し、すべての人にとってより良く、より安全で、よりレジリエントな世界を構築するチャンピオンになることに情熱を注いでいます。AWS 以前は、Accenture、SIEMENS、General Electric、IBM、AECOM に勤務し、顧客のデジタルトランスフォーメーション・イニシアチブに貢献してきました。 この記事は Ryan Dsouza によって書かれた Common architecture patterns to securely connect IoT devices to AWS using private networks の日本語訳です。この記事は SA の渡邉が翻訳しました。

生成系AIが、企業のビジネスを変革しています。企業はAIを使用して、データ主導の意思決定を改善し、オムニチャネル体験を強化し、次世代の製品開発を推進しています。企業は、電子メール、プッシュ通知、その他のアウトバウンドコミュニケーションチャネルを通じたマーケティング活動を強化する目的で、特に生成系AIを使用しています。ガートナーは、「2025年までに、大企業によるアウトバウンドマーケティングメッセージの30%が機械によって生成される」と 予測しています 。しかし、魅力的な顧客コミュニケーションを実現するには、生成系AIだけでは不十分です。調査によると、最もインパクトのあるコミュニケーションはパーソナライズされたもの、つまり、適切なメッセージを適切なタイミングで適切なユーザーに表示されるものです。 マッキンゼーによると 、「71％の消費者は、企業がパーソナライズされたインタラクションを提供することを期待している」。お客様は、 Amazon Personalize と生成系AIを使用して、マーケティングキャンペーン用の簡潔でパーソナライズされたコンテンツを作成し、広告のエンゲージメントを高め、会話型チャットボットを強化することができます。 開発者は、 Amazon Personalize を使用して、 Amazon.com がリアルタイムでパーソナライズされたレコメンデーションに使用しているのと同じ種類の機械学習（ML）技術を搭載したアプリケーションを構築できます。Amazon Personalizeを使えば、開発者はMLの専門知識がなくても、パーソナライズされた製品やコンテンツのレコメンデーションを通じてユーザーエンゲージメントを向上させることができます。Amazon Personalizeが提供する レシピ （特定のユースケースをサポートするために用意されたアルゴリズム）を使用することで、特定の製品やコンテンツのレコメンデーション、パーソナライズされたランキング、ユーザーのセグメンテーションなど、さまざまなパーソナライゼーションを実現できます。さらに、フルマネージドのAIサービスとして、Amazon PersonalizeはMLを活用したお客様のデジタル変革を加速し、パーソナライズされたレコメンデーションを既存のウェブサイト、アプリケーション、メールマーケティングシステムなどに簡単に統合できるようにします。 この投稿では、Amazon Personalizeと Amazon Bedrock の生成系AIを使用してマーケティングキャンペーンを向上させる方法を説明します。Amazon Personalizeと生成系AIを組み合わせることで、個々の消費者の嗜好に合わせたマーケティングを行うことができます。 Amazon PersonalizeとAmazon Bedrockを具体的にどのように連携させるのでしょうか？マーケターとして、プラットフォーム上でユーザーの行動に基づいて、ユーザーが楽しめそうな映画を推薦するようなカスタマイズされたメールを送りたいと想像してみてください。あるいは、ユーザーが興味を持ちそうな新しい靴を宣伝するために、ターゲットを絞ったメールを送りたいかもしれません。以下の使用例では、生成系AIを使用して2つの一般的なマーケティングメールを改善します。 ユースケース1 : 生成系AIを使用して個人向けにパーソナライズされたメールを届ける Amazon PersonalizeとAmazon Bedrockを使用すると、パーソナライズされたレコメンデーションを生成し、各ユーザーに合わせた送信メッセージを作成できます。 次の図は、生成系AIによってパーソナライズされたメールを配信するためのアーキテクチャとワークフローを示しています。 まず、ユーザーの インタラクション のデータセットをAmazon Personalizeにインポートし、トレーニングを行います。Amazon Personalizeは、 Top Picks for You レシピを使用してモデルを自動的にトレーニングします。出力として、Amazon Personalizeはユーザーの好みに沿ったレコメンデーションを提供します。 以下のコードを使用して、ユーザーにおすすめのアイテムを特定することができます： get_recommendations_response = personalize_runtime.get_recommendations( recommenderArn = workshop_recommender_top_picks_arn, userId = str(user_id), numResults = number_of_movies_to_recommend) 詳細は、 Amazon Personalize API reference を参照してください。 得られたレコメンデーションの出力は、 プロンプト の一部としてAmazon Bedrockに取り込まれます。プロンプトには、ユーザーの特徴、デモグラフィック、Amazon Personalizeのレコメンデーションアイテムが含まれます。 例えば、ユーザーにとって魅力的で楽しいパーソナライズされたEメールを作成したいマーケティング担当者は、次のようなプロンプトを使用するかもしれません： ユーザの興味を引くために魅力的で楽しいパーソナライズされたメールを作成してください。ユーザーは最近ファミリー向けの映画を見ました。リトル・マーメイド、エンカント、スパイダーマン：イントゥ・ザ・スパイダーバースがおすすめのアイテムです。 上のプロンプトを使って下のサンプルコードで、 Claude2 のようなAmazon Bedrockで提供されている基盤モデル(FM)の1つを呼び出すことで、ユーザーにパーソナライズされたメールを作成することができます： personalized_email_response = bedrock_client.invoke_model( body = prompt, modelId = identifier_of_the_model) 詳細は、 Amazon Bedrock API reference を参照してください。 Amazon Bedrockは、ユーザーにパーソナライズされたEメールを返します： 件名 : 映画鑑賞のお供に、お勧めの一本をどうぞ！ <ユーザー名>様 秋の心地よさを感じたいですか？大丈夫です！ソファーでくつろぎながら、大切な人と楽しめるオススメの映画ベスト3です： 1. リトル・マーメイド この古典的なディズニー映画は、人間界を夢見る人魚姫アリエルが主人公。人間界を夢見る人魚姫アリエルは、海の魔女アーシュラと契約し、大きな教訓を得ます。 2. ミラベルと魔法だらけの家 魔法の家に住むコロンビアのマドリガル一家を描いたディズニー映画。一家はそれぞれユニークな才能を持っていますが、幼いマリベルだけは違います。 3. スパイダーマン：イントゥ・ザ・スパイダーバース このスーパーヒーロー・アニメ映画は必見のアクション映画。スパイダーマンであるブルックリンの若者マルズモラレスが、他のスパイダーの力を持つ人物と協力して宇宙を救う。 愛すべきキャラクター、キャッチーな曲、そして感動的なストーリー、この3作品で間違いなし！ポップコーンをどうぞ！ ユースケース2 : 生成AIを使用して多人数向けのマーケティングキャンペーンを強化する 一対多のメールマーケティングでは、一般的なコンテンツではエンゲージメントが低くなる（開封率がの低下や配信停止）可能性があります。これを回避する1つの方法は、魅力的な件名の送信メッセージを手作業で作成することです。これは非効率的な時間の使い方につながります。Amazon PersonalizeとAmazon Bedrockをワークフローに統合することで、興味のあるユーザーセグメントを素早く特定し、関連性とエンゲージメントが高いメールコンテンツのバリエーションを作成することができます。 次の図は、生成系AIによってマーケティングキャンペーンを向上させるためのアーキテクチャとワークフローを示しています。 一対多のメールを作成するには、まず、ユーザーの インタラクション のデータセットをAmazon Personalizeにインポートしてトレーニングします。Amazon Personalizeは ユーザーセグメンテーション レシピを使用してモデルをトレーニングします。ユーザーセグメンテーションレシピを使用すると、Amazon Personalizeは選択されたアイテムに対して興味を示すユーザーをターゲットオーディエンスとして自動的に選定します。 ターゲットオーディエンスを特定し、アイテムのメタデータを取得するには、次のサンプルコードを使用できます： create_batch_segment_response = personalize.create_batch_segment_job( jobName = job_name, solutionVersionArn = solution_version_arn, numResults = number_of_users_to_recommend jobInput = { "s3DataSource": { "path": batch_input_path } }, jobOutput = { "s3DataDestination": { "path": batch_output_path } } ) 詳細は、 Amazon Personalize API reference を参照してください。 Amazon Personalizeは、各アイテムのターゲットとなる推奨ユーザーのリストをbatch_output_pathに出力します。その後、プロンプトと共になにかのFMを使用して、Amazon Bedrockにユーザーセグメントを呼び出すことができます。 このユースケースでは、新しくリリースされたスニーカーをEメールで売り込みたいとします。プロンプトの例は以下のようになります： ユーザーセグメント “sneaker heads “に対して、最新のスニーカー “Ultra Fame II “を宣伝するキャッチーなメールを作成してください。ユーザーに10％割引の割引コード「FAME10」を提供します。 最初のユースケースと同様に、Amazon Bedrockで以下のコードを使用します： personalized_email_response = bedrock_client.invoke_model( body = prompt, modelId = identifier_of_the_model) 詳細は、 Amazon Bedrock API reference を参照してください。 Amazon Bedrockは、各ユーザーが選択したアイテムに基づいて、パーソナライズされたメールを返します： 件名 : <<名前>>, 殿堂入りへの切符があなたを待っている <<名前>>様, 待ちに待った。新しい”Ultra Fame II”をご覧ください！これまでで最も革新的で快適なUltra Fameシューズだ。その新しいデザインは、一歩一歩を踏みしめるたびに、あなたを魅了するだろう。さらに、快適性、サポート性、スタイルがミックスされた、殿堂入りにふさわしいシューズだ。 乗り遅れるな。FAME10というコードを使えば、次の一足が10％割引になります。 最高のエンゲージメントにつながるメールをテストして決定するために、Amazon Bedrockを使用すると、手動でテストコンテンツを作成するのにかかる時間のほんの一部で、キャッチーな件名とコンテンツのバリエーションを生成することができます。 結論 Amazon PersonalizeとAmazon Bedrockを統合することで、パーソナライズされた販促コンテンツを適切なオーディエンスに配信することが可能になります。 FMによる生成系AIは、企業が消費者のためにこれまで以上にパーソナライズされた体験を構築する方法を変えています。Amazon PersonalizeやAmazon BedrockのようなAWSのAIサービスは、ユーザーにパーソナライズされた製品、コンテンツ、魅力的なマーケティングメッセージを推奨し、配信するのに役立ちます。AWS上の生成系AIでの作業の詳細については、 AWS上の生成系AIで構築するための新しいツールを発表 をご覧ください。 翻訳はSolutions Architect近藤が担当しました。原文は こちら です。

このシリーズの 第 1 部 では、 Amazon DynamoDB のデータローディング戦略と短時間実行時の DynamoDB の動作について学びました。この記事では、クエリのパフォーマンスと継続した負荷に対してDynamoDBはどのように対応するかについて学びます。 クエリの実行 任意に大規模なトラフィックを発生させ、現実の動作をシミュレートするために、複数のマルチスレッドクライアントが必要です。これらのクライアントは、各クエリはランダムに生成したIPアドレスを可能な限り速くリクエスト送信します。これらはテーブルが提供できるクエリ容量を消費し、残りはスロットリングされます。これを実現するために、同じ単純なクエリクライアントを実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの自動スケーリンググループを作成しました。 クエリテスト: オンデマンドテーブル、単一のパーティションキー値 最初のテストでは、単一の値を持つパーティションキーデザインを使用してデータをロードしたオンデマンドテーブルに対してクエリを実行します。前述のように、この単一パーティションキー値の使用はロード速度を遅くしました。それでは、このパーティションキーがクエリ速度にどのような影響を与えるか見てみましょう。 毎秒 6,000 回の読み取りが一定の速度で行われることが期待されます。データは 1 つのパーティションにあり、各パーティションは 毎秒最大 3,000 の読み取りユニットを持ち、結果整合性のあるクエリはそれぞれ 0.5 の読み取りユニットを消費します。したがって、数学的には毎秒 6,000 回のクエリルックアップを 1 つの非常にホットなスロットリングパーティションに対して達成するはずです。しかし、実際の結果はまったく異なります。 次の図 1 には、テスト開始時と最初の 10 分間の状況が表示されています。 図 1: 1 つのオンデマンドテーブル、1つのパーティションキー値のクエリテスト 図 1 では、このクエリが 4,500 の読み取りユニットを消費しており、これは秒間 9,000 回の結果整合性のあるクエリに相当します。これは期待を上回っています。発生していることは次のとおりです。各パーティションには、冗長性のためにデータが 3 つのノードに広く分散されています。リーダーノードはすべての書き込みを受け取り、2 つのフォロワーノードは迅速にそれに続きます。強力な整合性のある読み取りは常に最新のデータを取得するためにリーダーノードに送信されます。リーダーノードは毎秒 3,000 回の読み取りを処理できるため、パーティションは毎秒 3,000 回の強力な整合性のある読み取りを処理できます。結果整合性のある読み取りは 3 つのノードのいずれかに送られます。3 つのノードがすべてアクティブな場合、パーティションは理論的には毎秒 9,000 の読み取りを処理できます。これがここで見られる結果です。通常の運用中には、 3 つのノードのうち1つが短時間ダウンする場合があります。これは内部メンテナンスのためであったり、クエリに応答できないログレプリカに置き換えられたりします。そのような場合、パーティションは毎秒 6,000 回の結果整合性のある読み取りしか処理できず、これはまだ正常な動作と見なされます。そのため、時折毎秒 9,000 回の結果整合性のある読み取りで実行されることがあるとしても、パーティションが毎秒 6,000 回の結果整合性のある読み取りを維持できると仮定して設計するべきです。 連続してクエリを行うと、10 分後にスループットが急上昇する様子が図 2 に示されています。 図 2: テストを継続するとスループットが 2 倍に増加 スループットは正確に 2 倍に増加しました。DynamoDB は、単一のホットパーティションを検知し、それを 2 つの新しいパーティションに分割することを決定し、スループットキャパシティを 2 倍にしました（そして追加費用は発生しませんでした）。 DynamoDB にはアダプティブキャパシティと呼ばれる機能があり、その中で 頻繁にアクセスされるアイテムを分離 する機能をSplit for heat と呼ばれます。 DynamoDB は、あるパーティションが継続的に高い読み取りまたは書き込みスループットを受け取っているのを観測すると、そのパーティションを 2 つの新しいパーティションに分割することがあります。これにより、これらのアイテムが利用できる読み取りおよび書き込みキャパシティが 2 倍になります。 Split for heat のロジックは、最近のトラフィックパターンに基づいてソートキーの分割ポイントを選択し、その結果として得られる 2 つの新しいパーティションに均等に熱を分散させるように調整されます。分割ポイントはほとんど中央になることはめったにありません。IP アドレスのユースケースでは、分割は最もクエリを受けている IP 範囲を分離することを目的とします。 分割ポイントを選択する際、DynamoDB はテーブルがローカルセカンダリインデックス（LSI）を持っているかどうかを考慮する必要があります。もし LSI が存在する場合、分割ポイントはアイテムコレクション（同じパーティションキーを共有するアイテム）の間のみになります。LSI が存在しない場合、DynamoDB はアイテムコレクション内での分割が可能で、その際には分割ポイントの位置にソートキーの値が使用されます。これにより、同じパーティションキーを持つアイテムが、ソートキーの値に基づいて異なるパーティションに割り当てられる可能性があります。パーティションキーのハッシュはパーティションの配置の最初の要素を提供し、ソートキーの値はその配置をさらに微調整します。IP テーブルが LSI で構築されていた場合、単一のアイテムコレクションはさらなる分割ができないため、ここでの Split for heat はクエリのパフォーマンス向上に寄与しません。 Split for heat は読み取りと書き込みに適用され、高いトラフィックが継続するときはいつでも適用されます。実際、 第 1 部 で単一のパーティションキーを使用してランダムなCSVファイルをロードする際、ロードの終盤でパーティションの分割が観察されました。DynamoDB のこの機能は適応力がありますが、それによってクエリテストがより多くのパーティションで開始され、クエリテストに不当な影響を与える可能性があったため、ベンチマーク時にはそれを望まなかったのです。分割が発生しないようにするため、私はシーケンシャルな CSV ファイルからロードすることを選択しました。なぜなら、DynamoDB の Split for heat のロジックは（常に増加するソートキーの値を持つ単一のパーティションキーなど）、一部のソートキーの値に集中した負荷を検出することが難しく、分割が開始しないようになっているからです。これは timestamp をソートキーなどにした場合が顕著です。単一のパーティションキーに負荷は集中しているが、ソートキーは常に最も値が大きいものだけが書きこみされ一度の負荷しか掛かっていない為です。このような場合もし分割を行っても負荷が分散されません。 テストに戻りましょう。しばらくすると、次の図 3 で示されるように、スループットが再び2倍になります。 図 3: テストを続けると、さらに 2 倍になっている この時点で、データを持つ 2 つのパーティションは両方とも分割され、4 つのパーティションがクエリを処理するようになり、最大レートは 2 倍になりました。 安定した負荷のもとで合計 90 分間実行した後、グラフは次の図 4 のパターンを示しました。 図 4: 90 分間のクエリパフォーマンス 図 4 には注目すべき点がたくさんあります。初期の読み取り速度はパーティションキャパシティの制限によって制約され、Split for heat することでキャパシティを増やすために繰り返しパーティションが追加されました。約 1 時間後、パーティションは限界近くまで分割されました。 分割プロセスの一環として、クエリレートに一時的な低下が生じることがあり、負荷が集中しても毎秒 6,000 回の結果整合性のある読み込みに抑えておき、時々 9,000 回付近まで上がることがあるということを織り込んだ設計にすべきというリマインダーです。また、旧パーティションから新パーティションへの切り替えの時点で、そのパーティションへの書き込み（または強力な整合性のある読み取り）に対して約1秒間の Internal Server Error 応答が発生するのは予想されるものです。これは、パーティションの旧リーダーノードが新しいリーダーノードに移るためです。 テストの最後の30分間には、スループットは最終的にテーブルレベルの読み取りスループット制限で 120,000 RCU に制約されました。すべてのアカウントには、 テーブルに付与できるプロビジョニングされた読み取りキャパシティの制限 があります（書き込みには別の制限があります）。これは、オンデマンドテーブルの最大スループットを制御するために暗黙的に使用されます。ほとんどの AWS リージョンでは、デフォルトで 40,000 読み取りユニットです。テストの前に、テストアカウントのテーブルレベルの読み取りスループット制限を 80,000 読み取りユニットに増やしました。これにより、テーブルの制限が発動する前に分割と倍増を観察する時間が増えました。80,000 読み取りユニットのテーブルで結果整合性のあるクエリを実行すると、上記で説明した 50 パーセントのブーストのおかげで、最大 120,000 読み取りユニットの定常状態を達成できます。 では、真ん中の異常なピークについて話しましょう。 バーストキャパシティ のおかげで、一時的にスループットがテーブルの制限を超えることがあります。これは、アダプティブキャパシティのもう一つの機能であるバーストキャパシティによって、テーブルがキャパシティを借りることができるからです（ベストエフォートベースで）。これが、220,000 読み取りユニット（毎秒 440,000 クエリ）までの大きなピークを作り出す原因です。パーティションはもはやボトルネックではなく、バーストキャパシティが提供および消費され始めました。 許容されるバーストキャパシティは有限であり（このテーブルの場合、80,000 * 300 = 24,000,000 読み取りユニット相当）、その後はテーブルレベルの読み取りスループット制限に基づいてトラフィックが制限されます。 もしクエリの負荷を制限以下に軽減していれば、バーストキャパシティは後で再び蓄積されるでしょうが、クエリレートは常にテーブルがサポートできる最大まで保たれていたため、ラインはテーブルレベルの読み取りスループット制限で平坦に続いています。 もし、強力な整合性のある読み取りを行っていた場合、毎秒 80,000 読み取りが限界です。結果整合性のある読み取りを行っているので、上のセクションで説明した仕組みで追加の 50 パーセントがあり、チャートが示すように、毎秒 120,000 読み取りユニットで実行することができます。 ここで興味深いのは、特別な計画なしに、パーティションキーの値が 1 つだけであり（ベストプラクティスのアドバイスに反して）、1 時間後にはインフラが毎秒 44 万クエリを処理でき、制限はアカウント関連のクォータによるものだけだったということです。アイテム単体のスループットと混同しないでください。ソートキーはランダムの値でクエリを実行しています。パーティションという粒度で負荷は分散されていることを注意してください。 クエリテスト: オンデマンドテーブル、複数のパーティションキー値 2 つ目のテストでは、ベストプラクティスのアドバイスに従い、複数のパーティションキー値を使用します。次に、新しいオンデマンドテーブルを使用してプロセスを開始します。図 5 がそれに続きます。期待される結果は何でしょうか？ 図 5: 200 以上のパーティションキー値を使用したクエリテスト 直ちに、毎秒 15,000 読み取りユニット（30,000クエリ）という高いスループットを達成しました。これは以前の開始時点の 4 倍です。なぜなら、新しく作成されたオンデマンドテーブルに存在する 4 つのパーティションをすべて使用しているからです。トラフィックを高く保ち続けると、パーティションは分割され、その後もさらに分割されます。次に続くのが図 6 です。 図 6: パーティション分割でスループットが向上 パーティションキーが 1 つの場合と同じパターンですが、今回は分割可能なパーティションが 1 つではなく 4 つから始まっています。 最終的なグラフは最初のものと非常に似ていますが、ピークは1時間後ではなく 45 分後に来ています。次に続くのが図 7 です。 図 7：クエリを 1 時間実行した場合のスループット ここからの要点は、パーティションキーを良く分散させる方が良いということです。200 以上のパーティションキーを持つ方が、1 つだけの場合よりも高速にスケールアウトします。 また、アダプティブキャパシティのため、DynamoDB をベンチマークする際には、最初の 5 分で見えるものが 1 時間後にも同じとは限らないということです！ クエリテスト： 毎秒 100 万リクエスト 最後に、毎秒 100 万リクエストを目指したテストで締めくくります。 このために、テーブルに 500,000 の読み取りユニットをプロビジョニングします（これにはデフォルトのアカウントクォータの引き上げが必要です）。これは毎秒 100 万のクエリに十分以上のキャパシティを提供するはずです。テーブルをプロビジョニングしたままにするか、作成後にオンデマンドに切り替えるかは選択できます。ただし、オンデマンドテーブルはプロビジョニングされたテーブルよりもパーティションを積極的に分割する傾向があります。しかし、今回のテストではプロビジョニングされたままにしておきます。その理由の 1 つは、プロビジョニングされたスループットが 50 万読み取りユニットである赤いラインを示すことです。これは基本的には毎秒 100 万のリクエストを実現する目標となります。 次の図は、最初の 15 分間で観測された結果を示しています。 図 8: 500,000 RCU でプロビジョニングされたテーブルに対する、200 以上のパーティションキー値を持つ初期読み取りトラフィック 前述の図 8 に示されているように、最初はテーブルが約 225,000 読み取りユニットまたは毎秒 450,000 クエリを達成しました。テーブルレベルでスループットが制限されていなかったため、私たちの読み取りスループットを制限しているホットパーティションがいくつかあったと推測できます。データをより多くのパーティションキー値に広く分散させ、テーブルのパーティションにより均等にデータを配置するためのより良いメカニズムを見つけるべきでしょうか？理想的にはそうですが、試してみないとわかりません。 図 9: 15 分後の読み取りトラフィックが倍増 前述の図 9 は、Split for heat が 15 分後にスループットを倍増させ、消費された RCU が 470,000 個であることから、最終的には毎秒 940,000 の結果整合性のあるクエリを達成していることを示しています。毎秒 100 万クエリにほぼ達しています。さらに 1 時間経過すると、次に続く図 10 に示されている全体的なトラフィックパターンが生成されます。 図 10: 90 分間の読み取りトラフィック、毎秒 1,440,000 クエリの安定を達成 これは、ほぼ毎秒 150 万クエリの定常状態です。テーブルレベルの読み取りスループット制限の結果、そこで止まったに過ぎないです。 レイテンシはどうでしょう？次の図 11 に示す Amazon CloudWatch のメトリクスで見ることができます。 図 11: CloudWatch のクエリレイテンシのメトリクス CloudWatch は、毎秒 100 万以上のクエリを実行した場合でも、クエリあたり平均 1.72～1.88 ミリ秒と安定していることを報告しています。これはスケール時の一貫したパフォーマンスです。 クエリテスト：まとめ DynamoDB は、パーティションが継続的な読み書きトラフィックを受ける場合、そのパーティションを分割することがあります。これにより、そのパーティション内のアイテムの利用可能なスループットが 2 倍になります。分割ポイントは、最近のトラフィックパターンに基づいて理想的な位置が計算されます。テーブルに LSI が存在する場合、分割ポイントはアイテムコレクション間でのみ設定できます。 プロビジョニングされたテーブルへのトラフィックは、読み取りまたは書き込みキャパシティの設定によって制限される可能性があります。オンデマンドテーブルは、テーブルレベルの読み取りおよび書き込みスループット制限に基づく暗黙の最大プロビジョニングキャパシティがあります。これらの制限は引き上げることができます。 バーストキャパシティにより、一時的にテーブルの制限を超えるトラフィックが可能となります。 高いカーディナリティのパーティションキーを使用すると、アイテムをパーティションにスムーズに割り当てることができ、すべてのパーティションがテーブルのスループットに寄与できます。低いカーディナリティのパーティションキーを使用すると、パーティション間での作業負荷が不均一になる可能性があります。このような状況では、Split for heat が特に有用です。ただし、LSI が存在する場合や、ソートキーが増加し続ける場合など、分割が有益でないと判断された場合は、Split for heat はアイテムコレクション内で行うことはできません。 この記事と 第 1 部 で説明した DynamoDB のスケーリング動作とベストプラクティスのヒントについては、ブックマーク可能なリファレンスガイド 第 3 部 をご覧ください。 作者情報 Jaso n Hunter はカリフォルニアを拠点とする DynamoDB 専門のプリンシパルソリューションアーキテクト。2003 年より NoSQL データベースの開発に従事。Java、オープンソース、XML への貢献で知られる。 Vivek Natarajan は Purdue 大学で CS を専攻しており、AWS のソリューションアーキテクトインターン生である。 (本記事は 2023/01/30 に投稿された Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 2: Querying) を翻訳した記事です。翻訳は SA 鈴木が担当しました。)

Amazon DynamoDB の一般的な原則は、高いカーディナリティのパーティションキーを選択することです。しかし、なぜそのようにすべきなのか、そしてそうしなかった場合の影響は何か？お客様のユースケースをもとに、この疑問に深く迫り、異なるパーティションキーの設計とテーブルの設定を使用して DynamoDB のロードおよびクエリのパフォーマンスを調査します。 各実験の後、生成されたパフォーマンスグラフを分析し、私たちが観察したパターンを説明し、繰り返しの改善イテレーションを通じて、DynamoDB の内部構造の基礎を紹介し、パフォーマンスの高いアプリケーションを構築するためのベストプラクティスを紹介します。テーブルのパーティション、パーティションキー値、ホットパーティション、Split for heat、バーストキャパシティ、およびテーブルレベルのスループット制限についても説明します。 この 3 部構成のシリーズでは、まず初めに探究する問題を紹介し、データロードの戦略と短時間の DynamoDB 実行時の挙動に焦点を当てます。 第 2 部 では、クエリのパフォーマンスと継続した負荷に対して DynamoDB はどのように対応するかについて説明します。このシリーズは、学びとベストプラクティスをまとめた 第 3 部 で終了します。 AWS の試算によれば、今回調査するソリューションは非常にスケーラブルであり、アイテムの読み取りにかかるコストは約 0.18 ドル、継続的なストレージコストは月額 0.05ドルであり、完全に柔軟なオンデマンドモードでは 1 ドルで 800 万回の検索が可能です。最初はゆっくりとした読み取りから始め、最終的には平均レイテンシが 2 ミリ秒以下で数百万回のリクエストを処理している状態になります。 お客様の使用例: IPアドレス検索 この投稿は、高いカーディナリティのパーティションキーの重要性に関するお客様の質問に触発されました。多くの DynamoDB のユースケースでは、自然で明白な高いカーディナリティのパーティションキー（例: 顧客 ID や資産 ID など）がありますが、今回のケースは異なります。Accenture Federal Services は私たちに連絡して、IP アドレスのメタデータ検索サービスを設計したいと伝えました。彼らのデータセットは何十万もの IP アドレス範囲から成り、各範囲には開始アドレス（例: 192.168.0.0）、終了アドレス（例: 192.168.10.255）、および関連するメタデータ（例: 所有者、国、適用するセキュリティルールなど）が含まれていました。彼らのクエリは IP アドレスを受け入れ、それを含む範囲を見つけ、メタデータを返す必要がありました。 Accenture Federal Services が知りたかった事： このルックアップサービスにおいて DynamoDB がどの程度有効か。 どのようなテーブル設計が最適か。 実行時間、コスト、スケーラビリティの観点から最も効率的な設計は何か。 DynamoDB が達成できる 1 秒あたりの理論的な最大ルックアップ数はどのくらいか。 彼らはまた、自分たちのユースケースが古典的な DynamoDB のユースケースのように見えないことを懸念していました。彼らは、それがパフォーマンスを制限するかどうかを知りたかったのです。 この投稿では、これらの問題に取り組み、これらの質問に答えます。 ルックアップアルゴリズム テーブルを設計する前に、基本的なアルゴリズムを用意することが重要です。このアルゴリズムは、IP アドレスを受け入れ、効率的にそのアドレスを含む範囲を特定する必要があります。 DynamoDB のテーブルスキーマには、パーティションキーとオプションのソートキーがあります。追加の属性が存在するかもしれませんが、それらは（セカンダリインデックスに配置されない限り）インデックスされません。 パーティションキーとソートキーに詳しくない場合は、まず DynamoDB の基礎 を学ぶことをお勧めします。動画が好きな方は、「 DynamoDB: Its purpose, main features, and key concepts 」と「 DynamoDB: Under the hood, managing throughput, advanced design patterns 」をご覧いただくとよいでしょう。 DynamoDB からデータを取得する 1 つの方法は、 Query 操作を実行することです。 Query はさまざまなことができますが、その 1 つは、パーティションキーが正確に指定され、ソートキーが不等式で指定された（パーティションキーが X に等しく、ソートキーが Y に等しくない）アイテムを取得することです。IP を IP 範囲から検索するために Query を使用できます。ただし、データが次の 2 つの条件を満たしている場合です: データセット内の IP 範囲は重なってはいけません。これは本質的な条件であり、そうでなければデータセットは曖昧になります（同じ IP が複数のメタデータエントリを持つ可能性があるため）。 IP 範囲は隙間なくすべての IP アドレスを完全に記述しています。これは常に成り立つわけではありません。なぜなら、一部の IP 範囲は特に予約されていてメタデータを持っていないためです。しかし、合成範囲を使用してこの仮定を真にすることができます。合成範囲はメタデータが利用できないことを示すペイロードでギャップを埋めることができます。 各 IP 範囲は DynamoDB 内のアイテム（行）として保存できます。今のところ、単一の固定パーティションキー値（すべてのアイテムで同じ値）と、範囲の開始 IP アドレスに等しいソートキー値を仮定しましょう。以下の図 1 は、このデータモデルを示しています（後でこのデータモデルを改善します）。 図 1：固定パーティションキーを使用したデータモデル Query はパーティションキーが 0 に等しく、かつソートキーが検索対象の IP アドレス以下であるアイテムを後方にスキャンし、 結果を 1 つに限定 することで見つけることができます。最初に一致した項目が、返すべきメタデータです。重複やギャップがないことが分かっているので、終了範囲の値を考慮する必要はありません。以下は、 AWS Lambda 関数のテスト実行を示す Python コードです: import json import boto3 from boto3.dynamodb.conditions import Key client = boto3.resource('dynamodb') table = client.Table('IPAddressRanges') def lambda_handler(event, context): pk = '0' ip = event.get('ip') response = table.query( KeyConditionExpression=Key('PK').eq(pk) & Key('SK').lte(ip), ScanIndexForward = False, Limit = 1 ) print(response['Items'][0]) このアルゴリズムがどのように機能するのか理解するのに苦労している場合は、視覚的な表現が助けになるかもしれません。田舎にあるフェンスがあり、そこにはランダムな間隔でたくさんのフェンスの支柱が立っていると想像してください。フェンスに沿って歩く特定の距離に対応するフェンスの区間を見つけたいとします。この問題を解決するためには、まずその距離だけ歩き進み、それから後ろに向かって歩いてフェンスの支柱に遭遇します。そのフェンスの支柱には、その区間に関するメタデータがすべて含まれています。各フェンスの支柱は、それに続く区間を説明しています。反対側のフェンスの支柱には、それに続く区間のメタデータが含まれています。もしフェンスに隙間がある場合、その隙間の直前のフェンスの支柱には「ここに隙間がある」と記されています。 ただし、1 つのパーティションキー値だけを使用すると、クエリは簡単になりますが、これは DynamoDB のパーティションキー値間のカーディナリティを高くするベストプラクティス に直接反してしまいます。これに関する影響をテストしてみましょう。 データ形式 テストを実行するには、まず実際のデータ形式を考慮する必要があります。ソースデータは CSV ファイルにあり、1 行に 1 つの IP 範囲が記載されており、ギャップやオーバーラップはありません。各行には開始および終了の IP 値とメタデータが含まれています。以下は、可読性を高めるために空白を追加した模擬例です: Netblock , start , end , metadata 1.0.0.0/24 , 1.0.0.0 , 1.0.0.255 , Range 1.0.0.0/24 metadata 1.0.1.0/24 , 1.0.1.0 , 1.0.1.255 , Range 1.0.1.0/24 metadata 1.0.2.0/23 , 1.0.2.0 , 1.0.3.255 , Range 1.0.2.0/23 metadata 1.0.4.0/22 , 1.0.4.0 , 1.0.7.255 , Range 1.0.4.0/22 metadata 1.0.8.0/21 , 1.0.8.0 , 1.0.15.255 , Range 1.0.8.0/21 metadata 1.0.16.0/20 , 1.0.16.0 , 1.0.31.255 , Range 1.0.16.0/20 metadata 1.0.32.0/19 , 1.0.32.0 , 1.0.63.255 , Range 1.0.32.0/19 metadata 1.0.64.0/18 , 1.0.64.0 , 1.0.127.255 , Range 1.0.64.0/18 metadata 1.0.128.0/17 , 1.0.128.0 , 1.0.255.255 , Range 1.0.128.0/17 metadata 開始 IP 文字列をソートキーとして使いたくなるかもしれませんが、文字列を数字のように扱うのは危険です。.100 が .1 と .2 の間にくることがあります。1.0.32.0 が 001.000.032.000 になるように、値にゼロパッドするのが 1 つの解決策です。数字が常に3 桁である場合、文字列と数字は同様にソートされます。 もっと良い方法があります: 各 IP アドレスをその自然な数値に変換することです。IP アドレスはほとんどの場合、1.0.32.0 のようなドット付き 4 進数形式で書かれていますが、これはあくまで人間にとって分かりやすい表現です。基本的に、IP アドレス（IPv4 の場合）は単一の 32 ビットの値です。 IP アドレス 1.0.32.0 を 2 進数に変換すると（ただし、可読性のためにピリオドは保持されます）、00000001.00000000.00100000.00000000 となり、これを 10 進数に変換すると 16,785,408 になります。これがソートキーとして使用される番号モデルです。不等式演算がシンプルで効率的であり、かつ ストレージがコンパクト です。 次に続く図 2 は、IP アドレスを数値に変換した後のテーブルがどのように見えるかのスニペットです。 図 2: IP アドレスを数値に変換したテーブル ローディング さて、テストを開始する準備が整いました。まずは、ロード性能から始めます。CSV ファイルは、シンプルなループを使用したシングルスレッドの Python スクリプトでロードします。すべてのテスト結果は us-east-1 リージョンから収集されました。 ロードテスト: オンデマンドテーブル、シーケンシャルな CSV、単一のパーティションキー 最初のテストとして、新しく作成されたオンデマンドテーブルに対して一括ロードを実行します。CSV ファイルからロードし、Python コードによってすべてのアイテムに同じパーティションキーを割り当て、IP 範囲の文字列を数値に変換します。CSV ファイルのデータは IP 範囲でソートされており、低い IP が先頭にあることに留意してください。このような順序は CSV ファイルで一般的であり、後の実験で重要となります。次に示す図 3 は、その結果です。 図 3: 最初のロードテストの結果：オンデマンドテーブル、シーケンシャルな CSV、単一のパーティションキー 図 3 に示されているように、最初のロードテストは毎秒 1,000 書き込みユニットの安定したレートで実行されます。残りの書き込みリクエストは制限されています。 裏側で何が起こっているかを以下に説明します: すべての DynamoDB テーブルは複数の物理パーティションに分散されています。各物理パーティションは毎秒 3,000 の読み取りユニットと毎秒 1,000 の書き込みユニットをサポートできます。1 つのパーティションキー値を使用することで、すべての書き込みが 1 つのパーティションに送信され、それがボトルネックを引き起こしています。 新しいオンデマンドテーブルが 1 つのパーティションしか割り当てないことを意味するわけではありません。オンデマンドテーブルは常にライブトラフィックに適応し、新しく作成されたオンデマンドテーブルは最大で 4,000 の書き込みリクエストユニットおよび 12,000 の読み取りリクエストユニットを提供できると記載されています。詳細については、「 読み取り/書き込みキャパシティーモード 」を参照してください。 これらのスループット性能は、まさに 4 つのパーティションを持つテーブルと同じです。つまり、4 つのパーティションが利用可能でも、単一のパーティションキー値を使用しているため、すべてのトラフィックはそのうちの 1 つのパーティションに割り当てられ、他の 3 つのパーティションは非アクティブなままです。 データがどのようにパーティションに割り当てられるかを簡単に復習しましょう: 各パーティションは、テーブルのキースペースのサブセットを担当します。パーティションキー値はハッシュ化され、数値に変換されます。そして、その数値を含む範囲のパーティションが、そのパーティションキー値の読み取りまたは書き込みを処理します。パーティションキー値が常に同じであれば、一般的に同じパーティションがすべての読み取りと書き込みを処理します。異なるパーティションキーが同じ数値範囲の一般領域にハッシュすることがあり、その場合、その範囲を処理するパーティションに配置されます。パーティションは分割でき、そのアイテムを 2 つの新しいパーティションに移動し、数値範囲に新しい分割ポイントを導入できます。パーティションはアイテムコレクション内で分割できる場合もあります（同じパーティションキー値を持つアイテム間で）、その場合、ソートキーは分割ポイントの計算に考慮されます。 しかし、1 つのパーティションキー値を使うと、最初はすべてのアイテムが同じパーティションに配置されるため、書き込みが大幅に制限されます。 ロードテスト: オンデマンドテーブル、シーケンシャルな CSV、複数のパーティションキー データを複数のパーティションキー値に分散させれば、ロードを高速化できます。例えば、IP アドレスの最初の部分をパーティションキー値として選択することができます。例えば、192.168.0.0 はパーティションキーが 192 になります。これにより、書き込みが 200 以上のパーティションキー値に分散され、作業がパーティション間でより均等に分散されるはずです。 クエリを調整して IP 範囲に基づいて正しいパーティションキーを指定し、範囲がパーティションキーの境界を越えないようにローダーを調整する必要があります。そうでなければ、コアロジックが失敗します。新しいテーブルデザインは、次に続く図 4 のようになります。 図 4: 各 /8 アドレス範囲に対する異なるパーティションキーを示すテーブルデザイン 次に続く図 5 は、ロードテスト中のパフォーマンスを示しています。 図 5: 2 回目のロードテストの結果: 今回は多くのパーティションキーを使用 ロードは毎秒約 1,250 回の書き込みに改善されました。なぜそれ以上ではないのか、なぜ作業がパーティション間でうまく分散されないのか。それは CSV ファイルが順次処理されているからです。各パーティションキー値に対応する何千もの範囲が次から次へと続いています。あるパーティションが一時的にすべてのトラフィックを処理し、そして別のパーティションが、また別のパーティションが順にトラフィックを処理します。十分に均等に広がっていません。唯一の改善点は、パーティションキー値が切り替わり、新しいパーティションがスロットリングされるパーティションとして順番に割り当てられるときです。 このケースからの教訓は、順次処理された CSV ロードはトラフィックをうまく分散しないということです。 ロードテスト： オンデマンドテーブル、ランダムなCSV、複数のパーティションキー CSV ファイルのエントリの順序をランダムにすると（ファイルを調整するか、Python ローダー内で内部的なシャッフルを行う）、ロードをより均等に分散させ、パフォーマンス向上が期待できます。次に示す図 6 は、我々のテスト結果を示しています。 図 6: 3 回目のロードテストの結果: 今回は行をランダム化した CSV ファイルを使用 このテストは 2 分未満で終了しました。最初と最後のタイミングは部分的なものであり、秒単位のレートを推測することはできません。完全に測定された中央の 1 分間では、毎秒約 3,600 回の書き込みに達しました。これは4つのパーティションが効果的に利用されていることとよく一致しています。データの書き込み順序をランダムにするだけで、書き込みスループットが大幅に向上しました。 これらの理由から、CSV ファイルの行が（つまり、パーティションキー値でグループ化されている）パーティションキー値でソートされている場合は、CSV のロードをランダムにすることが重要です。 また、もしソースデータが他の DynamoDB テーブルの Scan の結果である場合は、ロード前にソースデータをランダムにすることが役立ちます。なぜなら、 Scan で返されるアイテムは自然にパーティションキーのハッシュ値でグループ化され、ロード中に安定したヒートマップが生成される可能性があるからです。 ロードテスト： プロビジョニングされたテーブル、ランダムなCSV、複数のパーティションキー ここまでのテストはすべて、新しく作成されたオンデマンドテーブルを対象としていました。では、10,000 の書き込みキャパシティユニット（WCU）でプロビジョニングされたテーブルをテストしてみましょう（シンプルにするため、オートスケーリングは有効にしません）。引き続きランダムな CSV ファイルを使用します。次に示す図 7 は、私たちが観測した結果です。 図 7: 4 回目のロードテストの結果: 10,000 WCU でプロビジョニングされたテーブルを使用 ロードは1分未満で完了しました。すべてのアクティビティは、毎秒約 6,000 回の書き込みで、1分未満のデータポイントに集約され、その1分間のピークはこれを上回っていました。 10,000 WCU で新たにプロビジョニングされたテーブルは、新しいオンデマンドテーブルよりもパーティションが多く必要です（この書き込み負荷を処理するためには少なくとも10のパーティションが必要です）。そして、これらの追加のパーティションに多くのパーティションキー値を分散させることで、パフォーマンスを向上させることができました。 これはプロビジョニングがオンデマンドよりも優れているという意味ではありません。なぜなら、オンデマンドは素早くトラフィックに応じて キャパシティとパーティションを調整し、増やしていく からです。ただし、オンデマンドテーブルのデフォルトサイズは10,000 WCU 未満です。テーブルが最初から高いトラフィック負荷を受けると予想される場合は、新しいオンデマンドテーブルを特定の初期キャパシティでプロビジョニングし、それを後でオンデマンドに切り替えることでテーブルを事前にウォームアップすることをお勧めします。 ローディングテスト: まとめ 最大の負荷率は、物理パーティションの数、パーティションキー値の数、そして負荷がパーティション全体にわたって作業を並列化する能力に依存します。より多くのパーティションは負荷率を増加させる傾向がありますが、パーティションが最も有益なのは、十分なパーティションキー値が作業をパーティション全体に分散させ、かつロードのロジックが作業をパーティションキー値にわたって分散させる場合です。 第 2 部 では、クエリのパフォーマンスと、継続した負荷に対して DynamoDB はどのように対応するかについて探求します。 まとめ この 3 部構成のシリーズでは、異なるパーティションキー設計を使用してロードおよびクエリのパフォーマンスをテストすることで、DynamoDB の内部について学びました。テーブルのパーティション、パーティションキーの値、ホットパーティション、Split for heat、バーストキャパシティ、およびテーブル全体のスループット制限について説明しました。 いつものように、ご質問やフィードバックはコメントでお気軽にどうぞ。 作者情報 Jaso n Hunter はカリフォルニアを拠点とする DynamoDB 専門のプリンシパルソリューションアーキテクト。2003 年より NoSQL データベースの開発に従事。Java、オープンソース、XML への貢献で知られる。 Vivek Natarajan は Purdue 大学で CS を専攻しており、AWS のソリューションアーキテクトインターン生である。 (本記事は 2023/01/30 に投稿された Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 1: Loading) を翻訳した記事です。翻訳は SA 鈴木が担当しました。)

重要な情報は Amazon FSx for Windows File Server 上に保存された Windows ファイルシステムなどのソースを含め、組織内の複数のデータソースに散在している可能性があります。 FSx for Windows File Server 用の Amazon Kendra コネクタ を使用して、FSx for Windows File Server 上の Windows ファイルシステムに保存されているドキュメント (HTML、PDF、MS Word、MS PowerPoint、およびプレーンテキスト) にインデックスを付け、 Amazon Kendra のインテリジェント検索を使用してこれらのコンテンツ全体の情報を検索できるようになりました。 組織は、共有 Windows ファイルシステム上のファイルに非構造化データを保存し、Windows アクセスコントロールリスト (ACL) を使用して、企業の Active Directory (AD) ドメインで設定されたアクセス権限に従って、ユーザーがファイルを読み取り、書き込み、作成できるようにすることで、それを保護します。このデータから特定の情報を見つけるには、ファイルを検索するだけでなく、ユーザーにアクセス権限があることを確認する必要があります。FSx for Windows File Server 用の Amazon Kendra コネクタは、FSx for Windows File Server に保存されたファイルにインデックスを付け、Amazon Kendra インデックスに ACL を取り込むことで、ユーザーによる検索クエリのレスポンスに、そのユーザーが読むことを許可されたドキュメントからの結果のみが含まれるようにします。 この投稿では、FSx for Windows File Server で ACL を使用してファイルシステムにセキュアに保存された一連のドキュメントを例にしています。これらのドキュメントは、コネクタを使用してこのファイルシステムをインデックスのデータソースとして構成および同期することで、Amazon Kendra インデックスに取り込まれます。そして、ユーザが検索クエリを実行すると、Amazon Kendra インデックスは、ユーザが所属するユーザ名とグループに基づいた ACL を使用し、ユーザがアクセスすることを許可されたドキュメントのみを返すことを実証します。また、設定の詳細と各段階のスクリーンショットが含まれているため、Amazon Kendra コネクタ for FSx for Windows File Server をセットアップする際の参考資料としてご利用ください。 前提条件 Amazon Kendra コネクタ for FSx for Windows File Server を試すには、以下が必要です: AWS Identity and Access Management (IAM) ロールおよびポリシーを作成する権限を持つ AWS アカウント 。詳細については、 アクセス管理の概要: アクセス許可とポリシー を参照してください。 AWS の基本的な知識と、Windows ACL および Microsoft AD ドメイン管理の実務知識。 FSx for Windows File Server上のファイルシステムへの管理者アクセス権、およびそのファイルシステムが属するADドメインへの管理者アクセス権。あるいは、 FSx for Windows File Server のクイックスタート を使用して、これをデプロイすることもできます。 AWS_Whitepapers.zip は、機能を試すために使用します。最新版については、 AWS Whitepapers & Guides を参照してください。または、独自のドキュメントを使用することもできます。 ソリューション・アーキテクチャ 次の図は、ソリューション・アーキテクチャを示しています: この例のドキュメントは、 FSx for Windows File Server (図中の4) 上のファイルシステム (3) に保存されています。ファイルは、FSx for Windows File Server が属する AWS Directory Service (1) を使用して作成された AD ドメインのユーザーとグループの構成に基づいて、ACL で設定されています。この FSx for Windows File Server 上のファイルシステムは、Amazon Kendra (5) のデータソースとして設定されます。 AWS Single Sign On (AWS SSO) は、AD をアイデンティティソースとして有効化され、Amazon Kendra インデックスは、顧客の検索ソリューションデプロイメント (6) からの検索クエリのユーザーコンテキストのユーザー名とグループ検索に AWS SSO (2) を使用するように設定されている。この例で設定された FSx for Windows File Server ファイルシステム、AWS Managed Microsoft AD サーバー、 Amazon Virtual Private Cloud (Amazon VPC)、およびサブネットは、 FSx for Windows File Server のクイックスタート を使用して作成されます。 FSx for Windows File Server の設定 次のスクリーンショットは、FSx for Windows File Server 上のファイルシステムが、Amazon FSx のコンソールで見たように、この例で使用されている AWS Managed Microsoft AD ドメインの一部として設定されていることを示しています。 AWS Managed Microsoft AD の設定 FSx for Windows File Server が属する AD は、以下の Directory Service コンソールのスクリーンショットのように、AWS Managed Microsoft AD として設定されています。 サンプルデータセットのユーザー、グループ、ACL 設定 この投稿では、いくつかの AWS 公開ホワイトペーパーからなるデータセットを使用し、FSx for Windows File Server 上のファイルシステム上のカテゴリ ( Best_Practices 、 Databases 、 General 、 Machine_Learning 、 Security 、 Well_Architected ) に基づいたディレクトリに格納しました。以下のスクリーンショットは、ファイルシステムが属する AD ドメインの一部である Windows bastion ホストから見たフォルダを示している。 ユーザーとグループは AD ドメインで以下のように設定されています: kadmin – group_kadmin patricia – group_sa 、 group_kauthenticated james – group_db_sa 、 group_kauthenticated john – group_ml_sa 、 group_kauthenticated mary、julie、tom – group_kauthenticated 次のスクリーンショットは、AWS Managed Microsoft AD ドメインに設定されたユーザーとグループを、Windows bastion ホストから見たものです。 各ディレクトリのファイルの ACL は、FSx for Windows File Server が属する AD ドメインのユーザーとグループの構成に基づいて設定されます: すべての認証済みユーザー (group_kauthenticated) – Best_Practices と General ディレクトリのドキュメントにアクセス可能 ソリューションアーキテクト (group_sa) – Best_Practices 、 General 、 Security 、および Well_Architected ディレクトリのドキュメントにアクセス可能 データベース分野の専門ソリューションアーキテクト (group_db_sa) – Best_Practices 、 General 、 Security 、 Well_Architected 、 Database ディレクトリのドキュメントにアクセス可能 機械学習分野の専門ソリューションアーキテクト (group_ml_sa) – Best_Practices 、 General 、 Security 、 Well_Architected 、 Machine_Learning の各ディレクトリにアクセス可能 管理者 (group_kadmin) – 6つのディレクトリのいずれのドキュメントにもアクセス可能 以下のスクリーンショットは、Windows bastion ホストから見た、サンプルデータの各ディレクトリの ACL 構成を示している。 AWS Single Sign-On の設定 AWS SSO は、AD ドメインを ID ソースとして構成されています。以下のスクリーンショットは AWS SSO コンソールでの設定です。 以下のスクリーンショットのように、AD から AWS SSO でグループが同期されます。 以下のスクリーンショットは、AD から同期された group_kauthenticated グループのメンバーを示しています。 Amazon Kendra コネクタ for FSx for Windows File Server を使用したデータソースの設定 Amazon Kendra コンソール上の Amazon Kendra インデックスに、Amazon Kendra コネクタ for FSx for Windows File Server を使用してデータソースを構成します。 新しい Amazon Kendra インデックスを作成する ことも、既存のインデックスを使用して新しいデータソースを追加することもできます。 Amazon Kendra インデックスにデータソースを追加する場合、 Amazon FSx の下の Add connector を選択して FSx for Windows File Server コネクタを選択します。 データソース名とリソースタグを追加する手順は、以下のスクリーンショットに示すように、他のデータソースの追加と同様です。 Amazon FSx 上の特定のファイルシステムとファイルシステムのタイプ (この場合は FSx for Windows File Server) を構成するための詳細は、 Source セクションで構成されます。ファイルシステムの管理者権限を持つユーザーの認証情報は、 AWS Secrets Manager のシークレットを使用して構成されます。 データソース設定の VPC とセキュリティグループの設定には、Amazon FSx と AD サーバーの VPC、サブネット、セキュリティグループの詳細が含まれます。次のスクリーンショットでは、データソース用に新しい IAM ロールも作成しています。 データソース構成の次のステップでは、Amazon FSx コネクタフィールドを Amazon Kendra ファセットまたはフィールド名にマッピングします。次のスクリーンショットでは、設定を変更しないままにしています。この後のステップでは、設定を確認し、データソースを作成することを確認します。 サンプルデータがデータソースとして保存されている FSx for Windows File Server 上のファイルシステムを構成した後、このデータソースに対してカスタムドキュメントエンリッチメント (CDE) の基本操作を構成し、ドキュメントが保存されているディレクトリに基づいて Amazon Kendra インデックス filed_category が構成されるようにします。データソースの同期は CDE 構成の後に開始され、取り込みワークフロー中にドキュメントの _category 属性が構成されるようにします。 次のスクリーンショットに示すように、Amazon Kendra インデックスのユーザーアクセスコントロール設定は、AWS SSO 統合を通じてユーザーとグループを検索するために構成されています。Amazon Kendra Search コンソールからユーザー名とグループ名に基づいて検索するために、JSONトークンベースのユーザーアクセスコントロールが有効になっています。 Amazon Kendra インデックスのファセット定義で、 _category に facetable と displayable のボックスがチェックされていることを確認します。これにより、CDE の基本操作で設定された _category の値を検索時にファセットとして使用することができます。 Amazon Kendraでの検索 データソースの同期が完了したら、Amazon Kendra コンソールのナビゲーションペインで Search indexed content を選択して、Amazon Kendra Search コンソールから検索を開始します。今回は Amazon Kendra のインデックスに取り込むデータセットとして AWS のホワイトペーパーを使用しているため、検索クエリとして “What’s DynamoDB? ” を使用しています。FSx for Windows File Server 上のファイルシステム上のファイルへのアクセスは、認証されたユーザにのみ許可されているため、ユーザ名やグループを設定せずにこの検索クエリを使用すると、結果が得られません。 まず、ユーザ名を mary@kendra-01.com に設定しましょう。ユーザ mary は group_kauthenticated に属しているので、 Best_Practices ディレクトリと General ディレクトリのドキュメントにアクセスする権限があります。以下のスクリーンショットでは、検索応答にファセット category が Best Practices と General に設定された文書が含まれています。CDE の基本操作は、 source_uri に含まれるディレクトリ名に応じてファセット category を設定します。これにより、FSx for Windows File Server 用のコネクタによって Amazon Kendra に取り込まれた ACL が、ユーザー名に基づいた検索結果で実施されていることが確認できます。 ここで、ユーザー名を patricia@kendra-01.com に変更します。ユーザー patricia は group_sa に属し、 Best_Practices と General ディレクトリに加えて、 Security と Well_Architected ディレクトリにアクセスできます。検索応答には、これらの追加ディレクトリからの結果が含まれます。 次のスクリーンショットで、ユーザ名を james@kendra-01.com 、 john@kendra-01.com 、 kadmin@kendra-01.com に変更すると、検索応答の結果がどのように変化するかを観察できます。 クリーンアップ Amazon Kendra コネクタ for FSx for Windows File Server を試すために AWS インフラストラクチャをデプロイした場合は、以下のようにインフラストラクチャをクリーンアップします: FSx for Windows File Server のクイックスタート を使用した場合は、作成した AWS CloudFormation スタックを削除し、作成したリソースをすべて削除します。 新しい Amazon Kendra インデックスを作成した場合は、そのインデックスを削除します。 コネクタを使用して新しいデータソースを追加しただけの場合は、そのデータソースを削除します。 AWS SSO 設定を削除します。 結論 Amazon Kendra コネクタ for FSx for Windows File Server は、非構造化コンテンツに散在する情報のセキュアでインテリジェントな検索を可能にします。データは、ACL を使用して FSx Windows File Server 上のファイルシステムに安全に保存され、Microsoft AD ドメイン資格情報に基づいてユーザーと共有されます。 Amazon Kendra コネクタ for FSx for Windows File Server の詳細については、 Amazon FSx データソース (コンソール) を使い始める と Amazon FSx でデータソースを使用する を参照してください。 カスタムドキュメントエンリッチメントについては、 取り込みプロセスでドキュメントのメタデータをカスタマイズ と、 Amazon Kendra のカスタムドキュメントエンリッチメントによってコンテンツとメタデータを充実させて検索体験を向上させる を参照してください。 この記事の翻訳はソリューションアーキテクトの林 航平が担当しました。原文は こちら です。 著者について Abhinav Jawadekar は Amazon Web Services のシニアパートナーソリューションーキテクトです。AWS パートナーのクラウド・ジャーニーを支援しています。

セキュリティの脅威がより高度化し、その脅威が広がりやすくなるにつれ、お客様はより Amazon CloudFront と AWS WAF を使用して、Web アプリケーションと API のパフォーマンス、回復性、セキュリティを向上させています。 CloudFront はコンテンツ配信ネットワーク (CDN) で、CloudFront の数百のエッジロケーションのうち、ユーザーに最も近い場所からデータを配信することで、世界中のユーザーの待ち時間を短縮します。 AWS WAF は Web アプリケーションファイアウォールで、一般的なエクスプロイトや望ましくないボットの通信トラフィックから Web アプリケーションを保護するために、悪意のあるリクエストを Web サーバーに到達する前に分析・ブロックします。 お客様は CloudFront と AWS WAF を使用してアプリケーションを保護できます。 ただし、開発者、スタートアップ、中小企業は、1)どのセキュリティ保護を有効にするのか、2)セキュリティルールを作成する方法、3)単一の IP アドレスから異常な数のリクエストが発生した時にその共通ログパターンを特定するなどの手法について、セキュリティの専門家に相談できないことがよくあります。 こうしたお客様は、CloudFront 内のシンプルで管理が容易なセキュリティを含め、アプリケーションの安全を確保する方法について追加のガイドを求めることが多いのです。 ここで、 CloudFront セキュリティダッシュボード のご利用開始を発表いたします。これは AWS WAF の可視性とコントロールを CloudFront ディストリビューションに直接提供する統合エクスペリエンスです。 対話型のセキュリティダッシュボードは、可観測性、調査ツール、使い勝手の良い設定インターフェースを組み合わせたもので、簡潔で直感的で便利に使用できます。 サービスコンソールを行ったり来たりすることなく、アプリケーション配信とセキュリティを1か所で管理 アプリケーションの上位のセキュリティトレンド、許可/ブロックされたトラフィック、ボットアクティビティの可視性に優れる ビジュアルログ分析機能を使用してログのクエリを実行することなく、トラフィックパターンをすばやく理解 セキュリティルールを記述することなく、組み込みのブロックコントロールを使用してインラインでアクションを実行 17種類以上のカテゴリに基づいて、許可またはブロックするボットを制御することで、望ましくないボットを防止 この投稿では、次の図に示すように、CloudFront セキュリティダッシュボードを使用してアプリケーションをセキュリティで保護するためのエンドツーエンドのワークフローについて説明します。 まず、コアセキュリティ保護を有効にし、セキュリティ推奨事項を確認して有効にし、アプリケーションを HTTP フラッドから保護する方法を学習します。 次に、組み込みレポートを使用したトラフィックのモニタ方法、ボットからの保護方法、異常なトラフィック パターンの調査方法、およびセキュリティルールの作成をすることなくインラインで軽減を適用する方法を学習します。 ディストリビューション用に AWS WAF がすでに有効になっている場合は、いずれかの CloudFront ディストリビューション 内の新しい Security タブに移動して、履歴メトリクスを含む新しいセキュリティ ダッシュボードの調査を開始します。 それ以外の場合は、この投稿の手順に従って AWS WAF のセキュリティ保護を有効にすることで、メトリクスの収集を開始できます。 図1 – CloudFront セキュリティダッシュボード セキュリティ保護の有効化、推奨事項の確認、HTTPフラッドへの対応 アプリケーションのセキュリティを確保する最初のステップは、新規または既存のディストリビューションに対してセキュリティ保護を有効にすることです。 これらの手順に従う際、適切な場合は推奨される保護が表示されることがあります。 この投稿では、AWS WAF が有効になっているお客様も手順に従えるように、推奨事項の有効化を個別のステップとして分離しています。 Amazon CloudFront コンソールを開きます。 Create distribution を選択してディストリビューションを作成し、保護したいオリジンを入力します。 また、既存のディストリビューションの場合は、ディストリビューションの Security タブに移動して Edit を選択します。 Web Application Firewall(WAF) セクションで、料金の見積もりを確認し、 Enable security protections を選択します。 残りのディストリビューション設定を確認し、 Create distribution を選択するか、既存のディストリビューションを編集している場合は Save changes を選択します。 CloudFront は、アプリケーションに推奨される AWS の標準保護機能を有効にした状態で AWS WAF を自動的に作成および構成します。 含まれているコアのセキュリティ保護機能では、Amazon の内部の脅威インテリジェンスに基づいて潜在的な脅威からの IP アドレスをブロックしたり、OWASP Top 10 で説明されている Web アプリケーションで最も一般的な脆弱性から保護したり、悪意のある者がアプリケーションの脆弱性を発見することから防御したりします。 セキュリティ推奨事項の確認と有効化 図2 – 有効化されたセキュリティ保護機能 CloudFront は、該当する場合に既存構成の要素を利用して適切なセキュリティ推奨事項を提供します。セキュリティタブで Edit ボタンを選択してセキュリティフォームに移動し、ディストリビューションに追加したい推奨セキュリティルールを有効化します。次の図に示す例では、CloudFront を使用して WordPress アプリケーションを高速化および保護しています。 WordPress 専用の保護機能を有効にするために、WordPress の保護チェックボックスにチェックを入れます。 図3 – セキュリティ構成の編集による推奨機能の有効化 さらに、HTTP フラッディングなどのボリューム攻撃からアプリケーションを保護するために、推奨されるレート制限ルールを使用することをお勧めします。前の図を参考にレート制限のチェックボックスに単純にチェックを入れるだけで、こうした攻撃を緩和できます。 レートは各アプリケーション固有のものであるため、CloudFront がアプリケーションの適切なレートを設定および微調整して、これらの攻撃を軽減するのに役立ちます。 有効化後、レート制限はブロックせずにモニターモードでメトリクスをキャプチャします。 レート制限ルールのメトリクスは、次の図に示す Security – Web Application Firewall (WAF) コンテナーのレート制限セクションで確認できます。 レートを超えた場合、 Monitor mode – rate exceeded のテキストを選択すると、レートがどのくらい頻繁に超過したかが表示されます。 また、必要に応じてレートを調整し、準備ができたらブロッキングを有効にすることもできます。 図4 – 上位のレート超過リクエスト アプリケーションのセキュリティを監視および改善する CloudFront のセキュリティダッシュボードは、セキュリティトレンド、ボットリクエスト、リクエストログの 3 つの可視化セクションに分かれています。 セキュリティトレンドセクションでは、トラフィックの概要を一目で確認できます。 総トラフィック、許可/ブロックトラフィックの比率、攻撃タイプ、クライアントの場所などの変化をすばやく把握できます。 特定の国からのトラフィックをブロックしたい場合は、次の図にあるようにその国をマウスオーバー表示してトグルをブロックに設定することができます。 図5 – 上位の攻撃タイプと発信元の国 ボットのコントロール 2番目のセクションのボットリクエストでは、アプリケーションにアクセスしているボットに関する情報が表示されます。 ボット保護が無効な場合、このセクションは、リクエストサンプリングに基づいて、トラフィックのどれだけがボットから来ているかを示します(次の図を参照)。 図6 – サンプリングされたボットトラフィックの概要 AWS WAF の Bot Control を有効にすることで、ボット保護を選択できます。これは、自己識別ボットにラベルを付け、一般的な望ましいボットかを検証し、高信頼度のボットシグネチャを検出する共通の保護レベルを提供します。これにより、リクエストサンプリングではなく、実際のリクエストに基づいて、カテゴリー別に詳細なボットアクティビティを確認できます。多くのお客様は、インフラストラクチャコストを下げるためにボットをブロックすることを選択しています。 ボットトラフィックの詳細な可視性を確認し、許可またはブロックするボットを制御するには、 Manage bot protection ボタンを選択し、 Enable Bot Control for common bots をチェックして、 Save changes をクリックします。 図7 – ボット保護を有効にする設定画面 Bot Control を有効にすると、各未検証ボットがボットカテゴリごとにどのように処理されるかを構成するオプションが表示され、詳細なメトリクスが表示されます。次の図では、未検証の非ブラウザユーザエージェント、HTTP ライブラリ、SEO ボットはモニターモードになっている一方で、リンクチェッカーとセキュリティボットはそれぞれ チャレンジまたは CAPTCHA を受け取ります。 AWS によって既知の一般的で検証可能なボット(たとえば、既知の検索エンジンクローラー)は、ここで設定したアクションの対象にはなりません。 Bot Control は、これらのボットが主張するソースから来ていることを確認する検証を実行してから、検証済みとしてマークします。 図8 – ボット保護有効時の詳細なメトリクスを確認する Bot Requests セクション 画面上で検索、フィルタリング、ログを検査する 最後に、特定のトラフィックパターンを隔離するために、ログを詳細に調査したいと考えるかもしれません。 たとえば、特定のトラフィックがどこから来ているか、最も要求されている URI パスは何かなどです。 最終セクションの Request Logs は、ログクエリを書いたり CloudFront コンソールを離れたりせずにそのような質問に答えるのが簡単になるように設計されています。 ログが有効になっていない場合は、予想されるリクエスト数に基づいて、ログを有効にする価格を見積もるために、組み込みの価格計算機を使用します。 ログを有効にするには、次の図に示すように Enable AWS WAF logs をチェックし、 Enable を選択します。CloudFront は CloudWatch ロググループを作成し、CloudWatch にログを記録するように AWS WAF 設定を更新します。 図9 – AWS WAF のログを有効化する 数分以内にログデータが流れ始めているのが見えます。 個々のリクエストに続いて、HTTP メソッド、上位 URI パス、上位 IP アドレス、上位国別の集計が視覚的に表示されます。 これにより、たとえばリクエストの異例なボリュームが単一の IP アドレスから発生している場合や、特定の URI パスを対象としている場合、またはこれまでログに表示されなかった国から発信されている場合など、すぐにパターンを視覚的に把握できます。 IP アドレス、国、ユーザエージェント、 URI パスなどの属性に基づいてリクエストをフィルタリングし、望ましくないトラフィックを特定するのに役立ちます。 特定されると、個々のリクエストまたはビジュアライゼーションを選択し、悪意のあるトラフィックを直ちにブロックするアクションを実行します。 たとえば、次の図に示すように IP アドレスをポイントしてブロックするなどです。 図10 – Requests logs の表示画面 利用と価格 CloudFront セキュリティダッシュボードは、各 CloudFront ディストリビューションに追加料金なしで含まれています。 CloudFrontコンソールの任意のディストリビューションの Security タブを選択することでアクセスできます。 追加のインサイトと構成オプションは、AWS WAF コンソールで利用できます。 ダッシュボードを介して作成された Web ACL には標準の AWS WAF 料金が適用され、ダッシュボードを介してクエリされたメトリックとログには標準の CloudWatch 料金が適用されます。 インラインでのセキュリティ保護の設定中に、構成可能な価格見積もりが提供されます。 価格設定の詳細については、AWS WAF の料金 と CloudWatch の料金 を参照してください。 CloudFront は、毎月 1 TB のデータ転送と 1,000 万 HTTP(S) リクエストを無料で提供しています。 Amazon Simple Storage Service (Amazon S3) や Application Load Balancer(ALB) などのAWSオリジンをCloudFrontの背後に使用している場合、オリジンフェッチのデータ転送は無料です。 詳細については、 Amazon CloudFront の料金 を参照してください。 まとめ CloudFront セキュリティダッシュボードの導入により、一般的なセキュリティ脅威からアプリケーションを保護および監視するためのシンプルで便利な方法が得られました。この投稿では、CloudFront セキュリティダッシュボードを使用してアプリケーションを確保および監視する方法を学びました。 コアのセキュリティ保護と推奨事項を有効にし、HTTP フラッドから保護し、ログで異常を視覚的に特定し、トラフィックをブロックする方法を学びました。 さらに、ボットを監視し、どのボットがアプリケーションにアクセスできるかを制御する方法を学びました。 CloudFront と AWS WAF の詳細については、 CloudFront デベロッパーガイド と AWS WAF デベロッパーガイド を参照してください。 この記事は、 Introducing CloudFront Security Dashboard, a Unified CDN and Security Experience  を翻訳したものです。 このブログの翻訳は Solutions Architect の加藤知愛が担当しました。

ID 管理は、適切なユーザーがテクノロジーリソースに適切にアクセスできるようにするためのポリシーとテクノロジーのフレームワークです。 Amazon Connect インスタンスの ID 管理は、次の 3 つの方法のいずれかで設定できます。 Amazon Connect にユーザーを保存する方法 既存のディレクトリにリンクする方法 SAML 2.0 ベースの認証を使用する方法 Amazon Connect は、 Security Assertion Markup Language (SAML) 2.0 による ID フェデレーションをサポートしているため、お客様の組織から Amazon Connect インスタンスへのウェブベースのシングルサインオン (SSO) が可能になります。 これにより、ユーザーは 1 つの ID とパスワードで複数のアプリケーションに安全にアクセスできます。 Amazon Connect において、既定では Amazon Connect インスタンスから ID プロバイダー (IdP) への 1:1 のマッピングが可能です。 多くの場合、企業の環境には複数の ID プロバイダー (IdP) があり、様々なアプリケーションに固有のユースケースに対応したり、プライマリ IdP に障害が発生した場合のバックアップメカニズムとして使用したりしています。 このブログ記事では、単一の Amazon Connect インスタンスに追加の ID プロバイダを設定するために必要な手順について詳しく解説します。 ソリューション概要 Amazon Connect インスタンスに追加の IdP を設定するために必要な手順の概要を以下に示します。 お使いの SSO 環境に、追加する SAML ID プロバイダー (IdP) 用の Amazon Connect SSO アプリケーションを作成します。 追加の SAML IdP 用に、AWS IAM でアイデンティティプロバイダリファレンスを作成します。 新しい IdP を含むように信頼関係を更新することで、既存の SAML IdP で使用されている既存の IAM ロールを再利用します。 Amazon Connect の修正されたロールを使用するように SAML IdP アプリケーションを設定します。 Amazon Connect で両方の IdP アプリケーションを使用して SSO をテストします。 このブログ記事では、IdP の例として Okta と AWS Identity Center を使用していますが、この手順は SAML 2.0 準拠のすべての ID プロバイダー に適用されます。 ハイレベルなアーキテクチャ図 シーケンス図 以下の図は、SAML リクエストが行き交う手順を詳しく示しています。 ユーザーは Amazon Connect にログインするためのリンクを含む内部ポータルを参照します。 フェデレーションサービスは組織の ID ストアに認証を要求します。 ID ストアはユーザーを認証し、認証レスポンスをフェデレーションサービスに返します。 認証が成功すると、フェデレーションサービスは SAML アサーションをユーザーのブラウザに送信します。 ユーザーのブラウザは SAML アサーションを AWS サインイン SAML エンドポイントに送信します。 AWS サインインは SAML リクエストを受け取り、リクエストを処理してユーザーを認証し、認証トークンを Amazon Connect に転送します。 Amazon Connect は AWS からの認証トークンを使用してユーザーを認証し、ユーザーのブラウザで Amazon Connect を開きます。 追加の IdP を設定するための前提条件は、既存の SAML 2.0 IdP を持つ Amazon Connect インスタンスがすでにセットアップされていることです。 ステップ 1: お使いの SSO 環境で、追加 IdP 用に Amazon Connect SAML アプリケーションを設定する このステップでは、追加の SAML IdP 内に Amazon Connect アプリケーションを作成し、メタデータをエクスポートします。 SAML 2.0 IdP で Amazon Connect アプリケーションを作成し、デフォルトリレーに以下のように入力します。 https://<リージョンID>.console.aws.amazon.com/connect/federate/<インスタンスID> <リージョンID> は Amazon Connect インスタンスのリージョン（例えば米国東部（バージニア北部）の場合は us-east-1）に置き換えてください。 アプリケーションのメタデータをエクスポートします。 IdP でアプリケーションを作成して IdP メタデータを取得する詳細な方法については、IdP のドキュメントを参照してください。 ステップ 2: IAM で追加の IdP 用の ID プロバイダーリファレンスを作成する このステップでは、IAM 内に追加 IdP 用の ID プロバイダー設定を作成します。 IAM コンソール を開きます。 「 アクセス管理 」で「 ID プロバイダー 」を選択します。 「 プロバイダを追加 」を選択します。 [ SAML ] を選択します。 [ プロバイダ名 ] にプロバイダーの名前を入力します。 例: AWSIdentityCenter-SSO-Agent IAM Identity Center または SSO アプリケーションからダウンロードしたメタデータファイルをアップロードします。 [ プロバイダを追加 ] を選択します。 ID プロバイダーを開き、ARN を書き留めます。 ステップ 3: プライマリ IdP の既存の IAM ロールを編集して、追加の IdP を追加する (信頼関係を編集) このステップでは、プライマリ IdP の Amazon Connect ユーザーに関連付けられている既存のロールを再利用し、新しい ID プロバイダーを参照するように信頼関係を編集します。 AWS アカウントの IAM に移動します。 「 ロール 」を選択します。 プライマリ IdP に使用されている既存の IAM ロールを選択します。 「 信頼関係 」を選択し、「 信頼ポリシーを編集 」 を選択します。 追加の IdP の ID プロバイダーの ARN を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": [ "arn:aws:iam::<AWSアカウントID>:saml-provider/AWSIdentityCenter-SSO-Agent", "arn:aws:iam::<AWSアカウントID>:saml-provider/Okta_Connect_Agent" ] }, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] } ロール ARN をメモします。「 IAM 」> 「 ロール 」 から該当のロールを選択すると確認できます。 ステップ 4: Amazon Connect の修正されたロールを使用するように SAML IdP アプリケーションを設定する このステップは、お使いの SSO ID プロバイダーによって異なります。以下の手順は AWS Identity Center IdP 用です。 お使いの SSO IdP 内で IAM ロールを参照する方法の詳細については Amazon Connect SSO Setup Workshop を参照してください。 IAM Identity Center に管理者としてログインします。 「 アプリケーションの割り当て 」にある「 アプリケーション 」を選択します。 Amazon Connect SSO アプリケーション名を選択します。 「 アクション 」を選択します。 「 属性マッピングを編集 」を選択します。 [ 新規属性マッピングを追加 ] を選択し、以下を設定します。 「 https://aws.amazon.com/SAML/Attributes/Role 」のユーザー属性を追加し、「<コピーしたIdPロールARN>,<コピーしたIAM IDプロバイダ ARN>」と設定します。 変更を保存します。 ユーザーをアプリケーションに割り当てます。 ステップ 5: Amazon Connect で両方の IdP アプリケーションを使用して SSO をテストする プライマリ SSO IdP にログインして Amazon Connect を起動します。 追加の SSO IdP にログインして Amazon Connect を起動します。 結論 この投稿では、追加の SAML 2.0 ID プロバイダーを追加して Amazon Connect インスタンスを強化する方法を学びました。 つまり、プライマリ IdP に問題が発生した場合でも、ユーザーは代替 ID プロバイダーを使用して Amazon Connect インスタンスに簡単にログインできるため、アクセスが中断されることはなく、シームレスなカスタマーエクスペリエンスを確保できます。 Amazon Connect の詳細については、 Amazon Connect のドキュメントを参照してください。 著者略歴 Mo Miah は Amazon Connect を専門とするソリューションアーキテクトです。彼は 16 年以上コンタクトセンターテクノロジーに関わってきた経験があります。 イギリスのロンドンにて、お客様が Amazon Connect の強力な AI/ML 機能を活用することでビジネス上の成果を達成できるよう支援することを楽しんでいます。 仕事以外では Mo はアクティブでいることを楽しんでおり、2 人の若い娘がいるので忙しくしています。 Sutapa Dasgupta は、Amazon Connect を専門とする AWS プロフェッショナルサービスのシニアコンサルタントです。 彼女は、大規模なコンタクトセンターの設計とクラウド移行、およびクラウド上でカスタマーエンゲージメントワークロードをモダナイゼーションするお客様のご支援経験があります。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。