7 月に、プレビュー版として Agents for Amazon Bedrock をご紹介 しました。現在、 Agents for Amazon Bedrock は一般公開されています。 Agents for Amazon Bedrock は、多段階のタスクのオーケストレーションによって、生成系人工知能 (AI) アプリケーション開発を加速するのに役立ちます。Agents は、基盤モデル (FM) の推論機能を使用して、ユーザーが要求したタスクを複数のステップに分解します。Agents は、デベロッパーから指示された手順に従ってオーケストレーション計画を作成します。その後、企業の API を呼び出すことと、検索拡張生成 (RAG) を使用してナレッジベースにアクセスすることによって計画を実行し、エンドユーザーに最終的な応答を提供します。この仕組みを知りたい場合は、「 高度な推論入門 」や「 RAG 入門 」など Agents に関する私の以前のブログをチェックしてください。 本日より、Agents for Amazon Bedrock には、オーケストレーションの制御の改善や思考の連鎖による推論の可視性の向上など、強化された機能も搭載されています。 目立たないところでは、Agents for Amazon Bedrock は、小売注文の管理や保険金請求の処理など、ユーザーが要求するタスクのプロンプトエンジニアリングとオーケストレーションを自動化しています。エージェントはオーケストレーションプロンプトを自動的に作成し、ナレッジベースに接続されている場合は会社固有の情報で補足し、API を呼び出して自然言語でユーザーに応答します。 デベロッパーは、新しいトレース機能を使用して、計画を実行する際に使用された推論を追っていくことができます。オーケストレーションプロセスの中間ステップを表示し、この情報を使用して問題のトラブルシューティングができます。 また、エージェントが自動的に作成するプロンプトにアクセスして変更できるため、エンドユーザーエクスペリエンスをさらに向上させることができます。この自動的に作成されたプロンプト (またはプロンプトテンプレート) を更新して、FM によるオーケストレーションと応答を改善し、オーケストレーションのより細かい制御を可能にできます。 推論手順の表示方法とプロンプトの変更方法を紹介します。 推論手順を表示 トレースにより、思考の連鎖 (CoT) と呼ばれるエージェントの推論を可視化できます。CoT トレースを使用して、エージェントがどのようにタスクを実行するかをステップバイステップで確認できます。CoT プロンプトは、 ReAct ( 推論 と 行動 の相乗効果) と呼ばれる推論技術に基づいています。ReAct と特定のプロンプト構造の詳細については、 私の以前のブログ記事「高度な推論入門」 をご覧ください。 まず、 Amazon Bedrock コンソール に移動し、既存のエージェントの作業ドラフトを選択します。次に、 [テスト] ボタンを選択し、サンプルユーザーリクエストを入力します。エージェントの応答で、 [トレースを表示] を選択します。 CoT トレースには、エージェントの推論がステップバイステップで表示されます。各ステップを開いて CoT の詳細を確認します。 可視性が向上することで、エージェントがタスクを完了するために用いた論理的根拠を理解しやすくなります。デベロッパーは、この情報を使用してプロンプト、手順、およびアクションの説明を改良し、ユーザーエクスペリエンスを繰り返しテストして改善する際のエージェントのアクションと応答を調整できます。 エージェントが作成したプロンプトを変更する エージェントは、指示された手順に基づいてプロンプトテンプレートを自動的に作成します。ユーザー入力の前処理、オーケストレーション計画、および FM 応答の後処理を更新できます。 まず、Amazon Bedrock コンソールに移動し、既存のエージェントの作業ドラフトを選択します。次に、 [高度なプロンプト] の横にある [編集] ボタンを選択します。 ここでは、4 種類のテンプレートにアクセスできます。前処理テンプレートでは、エージェントが ユーザー入力をコンテキスト化および分類する方法を定義します。オーケストレーションテンプレートでは、短期記憶、実行可能なアクションと利用可能なナレッジベースのリストとその説明、および問題を分解してこれらのアクションと知識をさまざまな順序または組み合わせで使用する方法のいくつかの例をエージェントに提供します。ナレッジベース応答生成テンプレートでは、ナレッジベースがどのように使用され、応答に要約されるかを定義します。後処理テンプレートでは、エージェントが最終応答をフォーマットしてエンドユーザーに提示する方法を定義します。テンプレートのデフォルトをそのまま使用することも、テンプレートのデフォルトを編集してオーバーライドすることもできます。 留意点 ここでは、Amazon Bedrock のエージェントを使用する際に知っておくべきベストプラクティスと重要事項をいくつか紹介します。 Agents は、特定のタスクに集中できるようにすると最高のパフォーマンスを発揮します。目的 (手順) が明確で、利用可能な一連のアクション (API) に焦点が当てられているほど、FM は適切な手順を推論して特定しやすくなります。エージェントにさまざまなタスクを任せる必要がある場合は、エージェントを別々に分けて作成することを検討してください。 その他のガイドラインは次のとおりです。 API の数 – エージェントでは 3～5 個の API を使用し、少数の入力パラメータをいくつか指定します。 API 設計 – 冪等性の確保など、API を設計する際の一般的なベストプラクティスに従います。 API 呼び出しの検証 – API 設計のベストプラクティスに従って、すべての API 呼び出しに網羅的な検証を行います。これは特に重要です。なぜなら、大規模言語モデル (LLM) は幻覚のような入出力を生成する可能性があり、これらの検証はそのような事態が発生した場合に役立つことが証明されているからです。 利用可能なリージョンと料金 Agents for Amazon Bedrock は現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。エージェントによる推論呼び出し ( InvokeModel API) に対して課金されます。 InvokeAgent API は別途課金されません。「 Amazon Bedrock の料金 」にはすべての詳細が記載されています。 詳細はこちら Agents for Amazon Bedrock の製品ページ Agents for Amazon Bedrock ユーザーガイド コンソールの Agents for Bedrock –  Antje 原文は こちら です。

11月28日、 Amazon Bedrock で独自のデータを使用して基盤モデル (FM) をプライベートかつ安全にカスタマイズして、ドメイン、組織、ユースケースに固有のアプリケーションを構築できるようになったことを紹介できることを嬉しく思います。カスタムモデルを使用すると、会社のスタイル、意見、サービスを反映した独自のユーザーエクスペリエンスを作成できます。 微調整 では、タスク固有の独自のラベル付きトレーニングデータセットを供給することによってモデルの精度を高め、FM をさらに専門的にできます。 事前トレーニングの継続 では、カスタマーマネージドキーを使用した安全で管理された環境で、ラベルのない独自のデータを使用してモデルをトレーニングできます。事前トレーニングの継続によって、当初のトレーニングよりもしっかりした知識と適応性が蓄積されて、モデルがさらにドメイン固有のものになります。 2 つのモデルカスタマイズオプションについて簡単に説明します。 Amazon Bedrock コンソール または API を使用して、微調整ジョブや事前トレーニング継続ジョブを作成できます。コンソールで、 [Amazon Bedrock] に移動し、 [カスタムモデル] を選択します。 Meta Llama 2、Cohere Command Light、Amazon Titan の FM を微調整する Amazon Bedrock は、 Meta Llama 2 、 Cohere Command Light 、および Amazon Titan のモデル の微調整もサポートするようになりました。コンソールで微調整ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [微調整ジョブの作成] を選択します。 AWS SDK for Python (Boto3) を使用した簡単なデモを次に示します。Cohere Command Light を微調整してダイアログを要約するようにしましょう。デモの目的で、公開されている dialogsum データセットを使用していますが、これを貴社固有のデータにして構いません。 Amazon Bedrock での微調整に備えて、データセットを JSON Lines 形式に変換して Amazon S3 にアップロードしてあります。各 JSON 行には、プロンプトフィールドと完了フィールドの両方が必要です。最大 10,000 件のトレーニングデータレコードを指定できますが、数百の例で既にモデルのパフォーマンスが向上していることがわかる場合があります。 {"completion": "Mr. Smith's getting a check-up, and Doctor Haw...", "prompt": Summarize the following conversation.\n\n#Pers..."} {"completion": "Mrs Parker takes Ricky for his vaccines.Dr.P...", "prompt": "Summarize the following conversation.\n\n#Pers..."} {"completion": "#Person1#'s looking for a set of keys and asks...", "prompt": "Summarize the following conversation.\n\n#Pers..."} 簡潔にするために、プロンプトフィールドと完了フィールドを編集しました。 次のコマンドを使用して、微調整をサポートしている使用可能な基盤モデルを一覧表示できます。 import boto3 bedrock = boto3.client(service_name="bedrock") bedrock_runtime = boto3.client(service_name="bedrock-runtime") for model in bedrock.list_foundation_models( byCustomizationType="FINE_TUNING")["modelSummaries"]: for key, value in model.items(): print(key, ":", value) print("-----\n") 次に、モデルカスタマイズジョブを作成します。微調整をサポートする Cohere Command Light モデル ID を指定し、カスタマイズタイプを FINE_TUNING に設定し、トレーニングデータの Amazon S3 ロケーションを示します。必要に応じて、微調整のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "cohere.command-light-text-v14:7:4k" bedrock.create_model_customization_job( customizationType="FINE_TUNING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "1", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-summarization.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) # ジョブのステータスを確認 status = bedrock.get_model_customization_job(jobIdentifier=job_name)["status"] ジョブが完了すると、カスタムモデルの一意のモデル ID を受け取ります。微調整されたモデルは、Amazon Bedrock によって安全に保管されます。モデルをテストしてデプロイするには、 プロビジョンドスループット を購入する必要があります。 結果を見てみましょう。データセットから例を 1 つ選択し、微調整前のベースモデルと、微調整後のカスタムモデルに、次のダイアログを要約するように依頼します。 prompt = """次の会話を要約してください。\\n\\n #人物 1#: こんにちは。John Sandals という名前で予約しています。\\n #人物 2#: 身分証明書を見せていただけますか。\\n #人物 1#: はい。これです。\\n #人物 2#: どうもありがとうございます。Sandals 様、クレジットカードはお持ちですか。\\n #人物 1#: はい、もちろん。アメリカンエキスプレスでいいですか。\\n #人物 2#: 申し訳ありません。現在、私どもでは、マスターカードと VISA しか受け付けておりません。\\n #人物 1#: アメリカンエキスプレスでは駄目なんですね。 それでは、VISA もあります。\\n #人物 2#: ありがとうございます。お部屋番号は 507 で、禁煙、クイーンサイズベッドになります。よろしいですか。\\n #人物 1#: はい、結構です。\\n #人物 2#: ありがとうございます。こちらがキーになります。何かご用のときは、いつでもダイヤル 0 にお掛けください。\\n\\n Summary: """ Amazon Bedrock InvokeModel API を使用してモデルをクエリします。 body = { "prompt": prompt, "temperature": 0.5, "p": 0.9, "max_tokens": 512, } response = bedrock_runtime.invoke_model( # 微調整前の応答にはオンデマンド推論モデル ID を使用する # modelId="cohere.command-light-text-v14", # 微調整後の応答には、デプロイしたカスタムモデルの ARN を使用する modelId=provisioned_custom_model_arn, modelId=base_model_id, body=json.dumps(body) ) 微調整前の基本モデルの応答は次のようなものです。 #人物 2# は John Sandals の予約について応対しています。John は自分のクレジットカード情報を伝え、#人物 2# は、マスターカードと VISA しか受け付けないことを確認しました。John の部屋は 507 号室で、何か必要な場合は #人物 2# が対応します。 微調整後の応答は次のようなものです。短く、的を射たものです。 John Sandals は予約したホテルにチェックインしています。#人物 2 # は彼のクレジットカードを受け取って鍵を渡します。 Amazon Titan Text の事前トレーニングの継続 (プレビュー) Amazon Bedrock での事前トレーニングの継続は、現在、Titan Text Express や Titan Text Lite などの Amazon Titan Text モデルのパブリックプレビューでご利用いただけます。コンソールで事前トレーニング継続ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [継続的な事前トレーニングジョブの作成] を選択します。 次も boto3 を使った簡単なデモです。投資会社に勤務しているとしましょう。金融業界の用語に関する知識をモデルに追加するために、財務レポートとアナリストレポートで事前トレーニングを継続したいとします。デモ用に、トレーニングデータとして Amazon の株主レターのコレクションを選択しました。 事前トレーニングの継続に備えて、今度も、データセットを JSON Lines 形式に変換し、Amazon S3 にアップロードしてあります。ラベル付けされていないデータを扱っているので、各 JSON 行にはプロンプトフィールドのみが必要です。最大 100,000 件のトレーニングデータレコードを指定でき、通常は少なくとも 10 億個のトークンを供給すると有効性が確認できます。 {"input": "Dear shareholders: As I sit down to..."} {"input": "Over the last several months, we to..."} {"input": "work came from optimizing the conne..."} {"input": "of the Amazon shopping experience f..."} 簡潔にするために、入力フィールドを編集しました。 次に、データを指すカスタマイズタイプ CONTINUED_PRE_TRAINING のモデルカスタマイズジョブを作成します。必要に応じて、事前トレーニングの継続のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "amazon.titan-text-express-v1" bedrock.create_model_customization_job( customizationType="CONTINUED_PRE_TRAINING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "10", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-continued-pretraining.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) ジョブが完了すると、別の一意のモデル ID を受け取ります。カスタマイズしたモデルは、Amazon Bedrock によって今度も安全に保管されます。微調整の場合と同様に、モデルをテストしてデプロイするには、プロビジョンドスループットを購入する必要があります。 留意点 知っておくべき重要な事項をいくつか次に示します。 データプライバシーとネットワークセキュリティ – Amazon Bedrock を利用すると、自らのデータを管理できるほか、すべての入力とカスタマイズは、ご利用の AWS アカウント以外には非公開のままとなります。プロンプト、完了、カスタムモデル、微調整や事前トレーニングの継続に使用されるデータなどのデータは、サービスの改善には使用されず、サードパーティのモデルプロバイダーと共有されることもありません。データは、API 呼び出しが処理される AWS リージョンに残ります。すべてのデータは、送信時および保管時に暗号化されます。 AWS PrivateLink を使用して VPC と Amazon Bedrock の間にプライベート接続を作成できます。 課金 – Amazon Bedrock では、モデルのカスタマイズ、保存、および推論に対して課金されます。モデルのカスタマイズでは、処理されたトークン数に応じて課金されます。これは、トレーニングデータセット内のトークンの数にトレーニングエポックの数を掛けたものです。エポックとは、カスタマイズ中にトレーニングデータを 1 回完全に通過することです。モデルストレージは、1 か月あたり、モデルごとに課金されます。推論は、プロビジョニングされたスループットを使用してモデルユニットごとに時間単位で課金されます。料金に関する詳細については、「 Amazon Bedrock の料金 」を参照してください。 カスタムモデルとプロビジョニングされたスループット – Amazon Bedrock では、プロビジョニングされたスループットを購入することで、カスタムモデルで推論を実行できます。これにより、長期契約と引き換えに一貫したスループットレベルが保証されます。アプリケーションのパフォーマンスニーズを満たすために必要なモデルユニットの数を指定します。カスタムモデル評価の初期段階では、プロビジョニングされたスループットを長期契約なしで時間単位で購入できます。長期契約がない場合、プロビジョニングされたスループットごとに 1 モデルユニットのクォータを使用できます。1 つのアカウントにつき最大 2 つのプロビジョニングされたスループットを作成できます。 可用性 Meta Llama 2、Cohere Command Light、および Amazon Titan Text FM の微調整サポートは、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。事前トレーニングの継続は、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでパブリックプレビューとしてご利用いただけます。詳細については、「 Amazon Bedrock デベロッパーエクスペリエンス 」ウェブページと ユーザーガイド をご覧ください。 Amazon Bedrock で FM を今すぐカスタマイズしましょう! –  Antje 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 re:Invent ではキーノート以外にも多数のブレイクアウトセッションが実施されましたが、Youtubeにはそのセッションの多くの録画がアップロードされています。400以上のセッション録画があがっており、観やすいように技術ジャンルごと（例えばDatabaseとかServerless等）に分けて再生リストが作られています。ぜひre:Inventのキャッチアップにご利用ください。 – AWS Events 再生リスト (Youtube) 前回もご案内したように、日本語でのre:Invent振り返りオンラインセミナーも来年開催予定です。業界カット、ソリューションカットで整理して説明しますので、ご興味がある方はぜひお申込みください。 – AWS re:Invent Recap – ソリューション編 – AWS re:Invent Recap – インダストリー編 また、1月18日(木)に実施される初心者向けセミナー「AWS Builders Online Series」のクロージングセッションでも50分間でAWS キーメッセージと主要アップデートが解説されます。こちらもご活用ください。 – AWS Builders Online Series それでは、先週の主なアップデートについて振り返っていきましょう。 2023年12月11日週の主要なアップデート 12/11(月) AWS AppConfig now supports AWS PrivateLink AWS AppConfig が AWS PrivateLink をサポートしました。これにより、インターネットゲートウェイをもたないVPC内のリソースからAppConfigのAPIにアクセスすることが可能になります。 AWS CloudShell has migrated to Amazon Linux 2023 (AL2023) 管理コンソール内から簡単に呼び出せるシェル環境 AWS CloudShell のOSが Amazon Linux 2 (AL2) から Amazon Linux 2023 (AL2023) に変更されました。既存のCloud Shell環境のホームディレクトリは維持されていますが、OSが提供するパッケージは異なりますので（例えばPython 2はサポートされなくなります）、利用の前には動作を確認いただくのが良いでしょう。詳細は こちらのドキュメント を参照してください。 AWS Lambda supports additional concurrency metric for improved quota monitoring AWS Lambda のCloudWatchメトリクスとして ClaimedAccountConcurrency が追加されました。これは、使用されたunreserved concurrency、割り当て済のreserved concurrency とprovisioned concurrencyの合計をレポートするもので、あとどれぐらい同時実行可能かを把握するために利用できます。 AWS CodeDeploy now supports application stop hooks during Amazon EC2 Auto Scaling Group scale-ins CodeDeploy は ASG (Auto Scaling Group) スケールイン中にアプリケーションの停止フック (Stop Hook)を呼び出すことができるようになりました。これによりスケールダウン時の進行中タスクの完了や、アプリケーションリソースの開放等を適切なタイミングで実行可能です。AGS インスタンスの更新操作中にもフックを呼び出すことができるため、アプリケーション稼働させながらインスタンスにパッチを適用する際にも活用可能です。 Amazon Athena now supports user identities for data access and audit Amazon Athena で AWS IAM Identity Center からの trusted identity propagation がサポートされました。これによりシングルサインオンしたユーザーの権限に基づいたクエリや、監査が可能になります。詳細は こちらのドキュメント を参照してください。 12/12(火) Introducing managed package repository support for Amazon CodeCatalyst Amazon CodeCatalyst でマネージドパッケージリポジトリが一般提供開始（GA）になりました。CodeCatalyst ユーザーが npm パッケージをセキュアに保存し、共有可能なパッケージリポジトリです。またこのレポジトリ経由でOSSのパッケージも取得可能です。詳細は こちらのドキュメント を参照してください。 Amazon MSK extends AWS IAM support to all programming languages for existing clusters Amazon Managed Streaming for Apache Kafka (Amazon MSK) のIAMサポートが、AWS SDKが動作するすべてのプログラミング言語で利用できるようになりました。これによりIAMベースでKafkaリソースへのアクセス制御が可能になります。この連携はオープンスタンダードである SASL/OAUTHBEARER ベースで実装されています。詳細は こちらのブログ をご覧ください。 12/13(水) Connect GraphQL APIs to existing MySQL and PostgreSQL databases with AWS Amplify AWS Amplify は AWS Cloud Development Kit (CDK) で作成された GraphQL API のバックエンドとしてこれまでのDynamoDBサポートに加え、既存のMySQLとPostgreSQLを利用できるようになりました。これにより既存のデータソースを活用しつつ、ウェブ/モバイルアプリ用のフロントエンド用 API レイヤーを簡単に構築できます。詳細は こちらのブログ をご覧ください。 Amazon EC2 Inf2 instances, optimized for generative AI, now available globally Amazon EC2 Inf2 インスタンスの利用可能なリージョンが拡大され、新たに東京、ムンバイ、シンガポール、アイルランド、フランクフルトリージョンで利用可能になりました。Inf2 インスタンスは、 AWS Inferentia2 アクセラレーターを内蔵した深層学習等の推論に向くインスタンスで、大規模言語モデル (LLM) やビジョントランスフォーマ向けに高いコストパフォーマンスを提供します。 12/14(木) AWS Lambda adds support for Python 3.12 AWS Lambda のマネージドランタイムおよびコンテナイメージで Python 3.12 がサポートされました。また、Amazon CloudFrontのエッジロケーションで稼働するLambda@Edgeでも同様にPython3.12が利用可能になっています。 AWS Data Exchange now supports data grants for sharing data across organizations AWS Data Exchange で data grants が一般提供開始(GA)になりました。Data Exchangeに登録したリソース(S3やRedshiftの表等)へのリードオンリーアクセスを期限付きで別のAWSアカウントに共有する機能です。Data Exchangeの管理コンソールから簡単な操作で設定が可能です。詳細は ドキュメントをご覧ください 。 AWS IoT Core allows customers to use their own CAs with fleet provisioning AWS IoT Core で、 ユーザー独自のCA (Certificate Authority)をフリートのプロビジョニングに利用可能になりました。AWS IoT にはセキュアな通信のために X.509 クライアント証明書を発行する機能がありますが、今回の機能更新により独自の公開鍵インフラストラクチャ (PKI)を利用することが可能になります。 12/15(金) Amazon Kinesis Data Firehose supports delivery of decompressed CloudWatch Logs to destinations Amazon Kinesis Data Firehose で CloudWatch Logs からの出力ファイルを展開して転送先(S3とSplunk)に連携する機能が追加されました。CloudWatch Logsのデータは初期状態でgzip圧縮されているため、連携後の処理でgzipファイルが扱えない場合は別途展開を実装する必要がありましたが、この機能によりKinesis Data Firehoseの設定だけで展開可能になります。展開処理には追加の費用が発生しますので 料金表を確認してください （現時点では日本語ページは新料金が反映されていないので、英語に変更してご覧ください）。 Amazon Linux announces support for KVM and VMWare images with AL2023.3 Amazon Linux 2023 の3回目の四半期アップデートである AL2023.3 のKVMおよびVMware用のイメージがダウンロード可能になりました。 こちらから ダウンロード可能です。AL2023.3の変更点については こちらのリリースノート を参照してください。 Amazon Connect Cases now supports creating rules for monitoring and updating your cases クラウドコンタクトセンター Amazon Connect でケース（問い合わせ）をプログラム的に管理し、エスカレーションワークフローを設定できる機能が追加されました。Amazon Connect Case のルールデザイナーでルールを設定可能です。例えば、ケースが更新されるたびにタスクを自動的に作成したり、アラートメールを送るといった自動化が可能です。また、コンタクトセンターの会話を分析するAmazon Connect Contact Lensと連携して、会話内容に応じたフォローアップタスクの設定も可能です。 今年も毎週お届けしてきた 週刊AWS は、次号(12/25予定)が年内の最終号になる予定です。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

概要 クラウドアプリケーションとサービスを効果的に運用するには、監視とオブザーバビリティに重点を置く必要があります。チームにとって、メトリクスの定義、キャプチャ、分析、オペレーションの可視性の確保、ログから実用的な洞察を抽出することが重要です。 多くの企業では、技術チームがインテグレーションシステムを共有して、管理するサービスやインフラストラクチャを監視しています。共有されたオブザーバビリティシステムは、組織のパフォーマンスと可用性のデータを統合します。これにより、チームはサービスとコンポーネント間の関係を視覚化できます。チームはリアルタイムのデータを利用して共同作業を行い、パフォーマンス、可用性、またはセキュリティ問題の原因を迅速に特定します。 ワークロードがさまざまなクラウドで実行されるマルチクラウド環境では、一元化されたオブザーバビリティソリューションを作成すると、アプローチがサイロ化され、複雑さが増し、直接的および間接的なコストが増加する可能性があります。マルチクラウド環境でワークロードを実行するお客様にとって、全体像を把握し、統一された方法で監視を行うことは非常に重要です。 AWS は、ハイブリッド環境やマルチクラウド環境におけるモニタリングとオブザーバビリティの改善に役立ついくつかのサービスを提供しています。これらのサービスの1つが Amazon CloudWatch で、AWS、オンプレミス、その他のクラウド上のリソースとアプリケーションの状態を監視するのに役立ちます。 この記事ではAmazon CloudWatch の機能を使い、 Azure Monitor からのメトリクスデータクエリを使用して、マルチクラウド環境のワークロードを監視する方法を紹介します。 この機能により、ハイブリッド環境やマルチクラウド環境で実行されるワークロードや、独自のカスタムデータソースを可視化できます。Amazon EC2 インスタンスと Azure 仮想マシンの両方からの CPU 使用率などのデータを同じダッシュボードでクエリして視覚化し、このデータから アラームを作成 できます。 図 1. 機能の概要 CloudWatch データソースは、メトリクスクエリを実行する AWS Lambda を利用しています。クライアントシークレットや Azure サブスクリプション ID などのリモート認証情報のストレージは、 AWS Secrets Manager によって管理されます。 AWS CloudFormation はこれをユーザーに代わってスタックとして作成します。このアプローチは拡張可能なソリューションを生み出します。メトリクスデータソースの同じフレームワークに基づいて構築されています。このフレームワークにより、 Amazon S3 の CSV ファイルのデータや、 Amazon Managed Service for Prometheus のメトリクスを CloudWatch に組み込むことができます。他のデータソースの詳細については、 ドキュメント を参照してください。 前提条件 AWS アカウントを保有していること Owner 権限を持つ Azure アカウントのサブスクリプションを保有していること ステップ 1. Microsoft Entra ID ポータルで「アプリの登録」を作成する Azure メトリクスデータを Amazon CloudWatch にインテグレーションするには、Azure テナントから「アプリの登録」を作成する必要があります。このプロセスについては簡単に説明しますが、この記事では Azure ロールベースのアクセス制御 (Azure RBAC) や特定のセキュリティとガバナンスのニーズに関する詳細は説明しません。 ここで説明するプロセスを実装する前に、必ずレビューして、セキュリティ要件を満たしていることを確認してください。この設定では、Amazon CloudWatch のサブスクリプション内のすべてのリソースへの Reader アクセスをモニタリングできることに注意してください。 クラウドアプリケーションの管理者として Microsoft Entra 管理センター にサインインします。 「ID」 メニューを選択し、次に「アプリケーション」を選択し、「アプリの登録」を選択します。 「新規登録」を選択します。 名前 (例: Amazon CloudWatch) を入力し、ユースケースに合ったテナントオプションを選択します。これはデフォルトの 「この組織ディレクトリのみに含まれるアカウント (既定のディレクトリ のみ – シングル テナント)」設定のままにします。 「登録」 を選択します。 「証明書とシークレット」メニューを選択し、「新しいクライアントシークレット」を選択します。 「説明」 と 「有効期限」 を入力します。 このシークレットは、有効期限が切れる前に AWS 側で更新する必要があることに注意してください。 「追加」を選択します。 「値」をコピーして安全に保管してください。これは、パスワードやその他のアクセストークンに似た機密性の高い文字列です。 「概要」メニューから次のフィールドをコピーします。 アプリケーション (クライアント) ID ディレクトリ (テナント) ID 「アプリの登録」を作成したら、次のステップ 2 で Azure サブスクリプションからデータを読み取る権限を付与する必要があります。 代替方法: Azure CLI を使用してアプリ登録を作成する このコマンドは、単一テナントの「アプリの登録」を作成します。 az ad app create --display-name 'Amazon CloudWatch' \ --sign-in-audience 'AzureADMyOrg' 前のコマンドから返された ID を以下の引数に置き換えます。 az ad sp create --id 'ID' 引数の ID を、以下の引数の最初のコマンドの ID に置き換えます。 az ad app credential reset --id 'ID' 出力に表示されるパスワードは、Amazon CloudWatch の設定に使用されるため、書き留めておきます。 代替方法: Azure PowerShell を使用してアプリの登録を作成する このコマンドは、単一のテナントの「アプリの登録」を作成します。 New-AzADApplication -DisplayName "Amazon CloudWatch" -SignInAudience "AzureADMyOrg" 前のコマンドから返された App_ID を以下の引数で置き換えます。 New-AzADServicePrincipal -ApplicationId "App_ID" 最初のコマンドから返された ID を以下の引数に置き換えます。 New-AzADAppCredential -ObjectId "ID" | Format-List シークレット値は Amazon CloudWatch の設定に使用されるため、書き留めておきます。 ステップ 2. ポータルで Azure サブスクリプションにアクセス許可を付与する Microsoft Azure Portal にサインインし、グローバル検索ボックスで 「サブスクリプション」を検索します。 Amazon CloudWatch とインテグレーションしたいサブスクリプションを選択します。 メニューから「アクセス制御 (IAM)」を選択し、次に「追加」を選択し、「ロールの割り当ての追加」を選択します。 リストから「Monitoring Data Reader」を選択し、「次へ」を選択します。 「メンバーを選択する」を選択し、「アプリの登録」の名前を入力します。 名前を入力するまでリストに表示されない場合があることに注意してください。「アプリの登録」の名前を選択し、「選択」をクリックします。 最後に、「次へ」を選択し、「レビューと割り当て」を選択します。 これらの権限が適用されていることを確認するには、サブスクリプション内の他のリソース (仮想マシンなど) の IAM ページを確認してください。 代替方法: Azure CLI を使用して Azure サブスクリプションにアクセス許可を付与する 以下のコマンドの Subscription_ID をサブスクリプションに置き換え、app_ID を上記で使用した az コマンドの出力に置き換えます。 az role assignment create --role 'Monitoring Data Reader' \ --scope '/subscriptions/Subscription_ID' --assignee 'app_ID' 代替方法: Azure PowerShell を使用して Azure サブスクリプションにアクセス許可を付与する New-AzADServicePrincipal コマンドから返された ID を下の引数に置き換え、Subscription_ID をサブスクリプションに置き換えてください。 New-AzRoleAssignment -ObjectId "Id" -Scope "/subscriptions/Subscription_ID" -RoleDefinitionName "Monitoring Data Reader" ステップ 3: Azure からメトリクスデータを読み取るように CloudWatch を設定する まず、CloudWatch コンソールの左側のナビゲーションで「設定」を選択し、次に「メトリクスのデータソース」を選択します。 図 2. CloudWatch サービスの設定ページ 次に、「データソースを作成」、「Azure Monitor」、「次へ」 の順に選択します。 図 3. メトリクスデータソースのリストから Azure Monitor 選択 データソースに名前を付けます。この名前は、作成された CloudFormation スタックの名前として表示されることに注意してください。Directory (tenant) ID、Application (client) ID、およびシークレットデータを入力し、「データソースを作成」を選択します。 図 4. Azure アプリの認証情報を使用して新しいデータソースを構成する CloudFormation へのリンクを辿ることで、スタックの進行状況を確認できます。通常、このプロセスは 2 分以内に完了します。Prometheus や Amazon RDS などの他のメトリクスデータソースでは、オプションで VPC 内に Lambda 関数を作成できます。これにより、プロビジョニング時間が 1 ～ 2 分長くなる場合があります。この画面が表示されたら、インテグレーションは完了です。 図 5. CloudWatch の完成したインテグレーションページ ステップ 4. Azure 環境のデータを視覚化する CloudWatch を使用して Azure Monitor にメトリクスデータのクエリを実行できるようになりました。「CloudWatch メトリクスを開く」ボタンをクリックするか、左側のナビゲーションメニューで「すべてのメトリクス」を選択し、次に「マルチソースクエリ」を選択して、ドロップダウンでデータソース名を選択します。 図 6. マルチソースクエリのコンソールの図 サブスクリプション、リソースグループ、その他のフィールドを選択します。CloudWatch は、AWS アカウントと同様に Azure サブスクリプションを監視するようになりました。 図 7. CloudWatchを使用して Azure VM の CPU を視覚化 このインテグレーションがどのように機能するかについて一言 – Azure Monitor (CloudWatch の他のメトリクスデータソースタイプと同様) は CloudWatch に永続化されません。そのため、CloudWatch は Azure のデータにアクセスする際にオンデマンドで Azure にクエリを実行します。これは CloudWatch アラームにも当てはまります。CloudWatch アラームも同様に、アラーム評価ごとに十分なデータポイントをクエリして、アラート条件が満たされているかどうかを確認します。メトリクス Lambda に対応するロググループで、すべてのクエリの詳細を確認できます。 よくある問題のトラブルシューティング Lambda はメトリクスデータソースインテグレーションのクエリを実行するために使用され、ログは CloudWatch Logs に保存されます。ロググループは、設定のエラーを見つけるために利用できます。 最もよく見られるエラーと、解決方法に関する注意事項は次のとおりです。 エラーメッセージ： INFO Sending response: { Data: [], SubscriptionIds: [] } これは、Azure IAM が権限を適用しておらず、Lambda が Azure からのサブスクリプションを列挙できないことを示しています。正しいサブスクリプションでステップ 2 が完了していることを確認してください。 エラーメッセージ： INFO An error occurred: RestError: Commonly allowed time grains:... すべてのメトリクスデータソースのタイプがこの機能をサポートしているわけではありません。ストレージアカウントの使用状況メトリクスなど、Azure Monitor に集約される頻度が低いデータを表示しようとすると発生する場合があります。これは、あまり頻繁に入力されないメトリクスでは予想される動作です。詳細については、Azure Monitor API のドキュメントをご覧ください。 エラーメッセージ： INFO An error occurred: AuthenticationRequiredError: invalid_client ensure your credentials are correct これは通常、AWS Secrets Manager に間違った認証情報が保存されていることが原因です。テナント ID、アプリケーション ID、シークレット値が正しいことを再確認してください。CloudFormation スタックを再作成しなくても、これらの値を AWS Secrets Manager で直接変更できます。 インテグレーションを次のレベルへ ハイブリッドおよびマルチクラウドの監視およびオブザーバビリティソリューションは、クラウド運用を監視するための強力なメカニズムです。CloudWatch をソリューションの中心的なコンポーネントとして使用することで、これらの機能を自動化し、拡張機能を使用して付加価値を高めることができます。最も強力な方法の 1 つは、Azure 環境内のメトリクスデータに基づいてアラームを作成することです。CloudWatch アラームは、管理者へのページ送信、JIRA チケットの作成、サーバーの再起動、フェイルオーバーの開始など、あらゆる自動ワークフローをトリガーできます。 CloudWatch は 1 つ以上のクラウド環境で問題が発生したときにアラートを出す、複合アラームを作成できます。Azure と AWS の両方で動作するワークロードがあり、両方のプロバイダーにデプロイすると機能停止が発生することを考えてみましょう。クラウド環境全体の HTTP エラーの総数に基づく複合アラームを使用し、アクションをトリガーします。これらはすべて、Azure と AWS の両方で作成されたクラウドネイティブなメトリクスに基づいています。ユースケースによっては、環境ごとにアラームを分けるよりもこの方が適している場合があります。 コストと削除 CloudWatch で外部メトリクスデータソースを使用しても追加料金は発生しませんが、Lambda、Secrets Manager、CloudWatch Logs、および CloudWatch アラームの使用には標準料金がかかります。 Azure Monitor API からデータを取得する場合の料金の詳細については、Azure のドキュメントを参照してください。 ステップ 3 で作成した CloudFormation スタックを削除するだけで、インテグレーションを解除できます。これにより、Lambda 関数とシークレット情報が Secrets Manager から削除されます。 まとめ CloudWatch を使用してマルチクラウドのオブザーバビリティソリューションを作成すると、さまざまな環境のメトリクスを視覚化してアクションを実行できます。アラーム、ダッシュボード、 Metric Math などの CloudWatch の機能を使用すると、高度なクエリを作成して、サイロ化されたオペレーションデータを解放し、複数のクラウドプロバイダーを使用する際の複雑さに対処する時間を短縮できます。この機能を使用することで、AWS から外部のメトリクスデータにアクセスしてアクションを実行できるため、CloudWatch はメトリクスデータを運用するための中心的な役割を果たします。 著者について Rich McDonough Rich McDonough は、Amazon Web Services (AWS) のPrincipal Technologist です。IT業界で20年以上の経験を持つ彼は、ディレクター、アーキテクト、DevOpsの役職を歴任し、スタートアップの分野でスキルを磨きました。主なフォーカスエリアは、バックエンド開発、DevOps プラクティスの作成、デジタルネイティブビジネスのクラウド移行でした。現実世界のビジネス上の問題に対処し、AWS サービスの運用を加速させる拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築できるようお客様をサポートしている同氏は、「オペレーションエクセレンスに理不尽なほど情熱を注いでいる」のです。Rich は、ワークショップの講師、講演、AWSの顧客のためのソリューション開発を楽しんでいます。 Aidan Keane Aidan Keane は AWS の Senior Specialist Solutions Architect で、Microsoft ワークロードを専門としています。彼はテクノロジー業界で25年間働いており、テクノロジーに情熱を注いでおり、顧客向けの新しい技術ソリューションの構築と探求を楽しんでいます。仕事以外では、ゴルフ、サイクリング、リバプールFCに情熱を注ぐ熱心なスポーツ愛好家です。彼は家族との充実した時間を楽しんでいるほか、アイルランドやペルーへ旅行しています。 Aviad Tamir Aviad Tamir は、金融サービス業界向けのソリューションを専門とする AWS の Senior Solutions Architect です。彼はテクノロジー業界で25年間にわたり、新興企業と大企業の両方で働いてきました。彼はオープンソースの哲学、知識の共有、より良いソフトウェアの構築が好きです。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

2023 年 11 月 30 日、 Amazon Route 53 Application Recovery Controller の新機能であるゾーンオートシフトを提供開始しました。これにより、AWS がある アベイラビリティーゾーン に影響する潜在的な障害を特定したときに、ワークロードのトラフィックをそのアベイラビリティーゾーンから自動的かつ安全にシフトし、障害が解決したら元のアベイラビリティーゾーンに戻すことができます。 耐障害性の高いアプリケーションのデプロイでは、通常、リソースをリージョンの複数のアベイラビリティーゾーンにデプロイします。アベイラビリティーゾーンとは、独立した電力、接続、ネットワーク機器、および氾濫原を確保するために、意味のある距離（通常100 km 以内）離れた物理データセンター群のことです。 デプロイの失敗、構成の誤り、オペレーターのミスなど、アプリケーションのエラーからユーザーを保護するために、2022年に 手動またはプログラムでゾーンシフトをトリガーする機能 を導入しました。これにより、あるアベイラビリティーゾーンでメトリクス値の低下を検出したときに、トラフィックをそのアベイラビリティーゾーンから遠ざけることができます。そのためには、すべての新しい接続を正常なアベイラビリティーゾーンのインフラストラクチャのみに転送するようにロードバランサーを設定します。これにより、障害の根本原因を調査する間、顧客はアプリケーションの利用を継続できます。障害が解消されたら、ゾーンシフトを停止して、トラフィックが再びすべてのゾーンに分散されるようにします。 ゾーンシフトは、 Application Load Balancer (ALB) または Network Load Balancer (NLB) の クロスゾーン負荷分散 がオフになっている場合に機能します。これは NLB のデフォルト設定です。ロードバランサーには 2 つのレベルの負荷分散があります。最初のレベルは DNS で設定されます。ロードバランサーはアベイラビリティーゾーンごとに 1 つ以上の IP アドレスを公開し、ゾーン間のクライアントサイドの負荷分散を実現します。トラフィックがアベイラビリティーゾーンに到達すると、ロードバランサーは登録された正常なターゲット、通常は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにトラフィックを送信します。デフォルトでは、ALB はすべてのアベイラビリティーゾーンのターゲットにトラフィックを送信します。ゾーンシフトを正しく機能させるには、クロスゾーン負荷分散を無効にするようにロードバランサーを設定する必要があります。 ゾーンシフトが始まると、次の図に示すように、DNS は全てのトラフィックを一つのアベイラビリティーゾーンから遠ざけます。 手動によるゾーンシフトは、ユーザー側で発生したエラーからワークロードを保護するために役立ちます。しかし、アベイラビリティーゾーンで障害発生の可能性がある場合、時に障害の特定や検出が困難な場合もあります。アベイラビリティーゾーン単位でメトリクスを追跡することは多くないかもしれません。そのため、アプリケーションメトリクスを使用してアベイラビリティーゾーンの問題を検出することは困難です。さらに、サービスがアベイラビリティーゾーンの境界を越えて依存関係を呼び出すことも多くあります。その結果、すべてのアベイラビリティーゾーンでエラーが発生してしまいます。モダンマイクロサービスアーキテクチャでは、これらの検出と復旧の手順を数十または数百の個別のマイクロサービスで実行しなければならないことが多く、復旧に数時間かかってしまいます。 お客様から、アベイラビリティーゾーンで発生した可能性のある障害を特定する負担を軽減できないかとご要望を頂いてきました。確かに、AWS が内部のモニタリングツールを使用すれば、潜在的な問題についてお客様より先に検出できる可能性があります。 今回のリリースにより、アベイラビリティーゾーンで発生する可能性のある障害からワークロードを保護するようにゾーンのオートシフトを設定できるようになりました。AWS が、ネットワークトラフィックのシフトをいつトリガーするかを決定するために、独自の AWS 内部モニタリングツールとメトリクスを利用します。シフトは自動的に開始され、API を呼び出す必要はありません。ゾーンに電源障害やネットワーク障害などの潜在的な障害が発生していることが検出されると、インフラストラクチャの NLB または ALB トラフィックのオートシフトが自動的にトリガーされ、障害が解決された時点でトラフィックを元に戻します。 言うまでもなく、トラフィックを一つのアベイラビリティーゾーンから遠ざけることはデリケートなオペレーションであり、慎重に準備する必要があります。アプリケーションの可用性を誤って低下させないように、一連の保護手段を構築しました。 まず、トラフィックを一度に複数のアベイラビリティーゾーンから移動させないようにするために、当社には内部制御があります。次に、毎週 30 分間、インフラストラクチャの移行を練習します。お客様は練習実行をブロックする時間帯を定義できます。例えば、月曜日から金曜日の 08:00～18:00 のように定義します。3 つ目は、練習実行中の サーキットブレイカー として機能する 2 つの Amazon CloudWatch アラームを定義できます。1 つは練習実行をまったく開始しないようにするアラーム、もう 1 つは練習実行中のアプリケーションの正常性を監視するアラームです。練習中にどちらかのアラームがトリガーされると、練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。練習終了時のアプリケーション正常性をチェックするアラームの状態は、実行の結果 (成功または失敗) を示します。 責任共有モデル により、お客様も 2つの責任を担います。 第一に、お客様はすべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。ゾーンオートシフトがトリガーされると、 AWS Auto Scaling はリソースをスケーリングするのに通常よりも時間がかかる場合があります。リソースを事前にスケーリングすることで、最も要求の厳しいアプリケーションの復旧時間を予測できます。 通常のユーザートラフィックを吸収するために、アプリケーションが 3 つのアベイラビリティーゾーンに 6 つの EC2 インスタンス (2×3 インスタンス) を必要とするとします。ゾーンオートシフトを設定する前に、1 つのアベイラビリティーゾーンが利用できない場合にトラフィックを吸収するのに十分な容量が残りのアベイラビリティーゾーンにあることを確認する必要があります。この例では、アベイラビリティーゾーンごとに 3 つのインスタンスがあることを意味します (トラフィックが 2 つのアベイラビリティーゾーンに移動されたときに 2×3 = 6 つのインスタンスを維持して負荷分散する必要があるため、3 つのアベイラビリティーゾーンに 3×3 = 9 つのインスタンスが必要) 。 実際には、高い信頼性が求められるサービスを運用する場合、顧客を起点とする負荷の急上昇やまれにあるホスト障害などの不測の事態に備えて、ある程度の冗長容量をオンラインで運用するのが一般的です。この方法で既存の冗長性を満たすことで、アベイラビリティーゾーンの問題が発生したときに迅速に復旧できるだけでなく、他のイベントに対する堅牢性も高まります。 第二に、お客様は選択したリソースのゾーンオートシフトを明示的に有効にする必要があります。AWS は、選択したリソースにのみゾーンオートシフトを適用します。ゾーンオートシフトの適用は、アプリケーションに割り当てられる合計容量に影響します。先ほど説明したように、残りのアベイラビリティーゾーンに十分な容量をデプロイして、アプリケーションを準備する必要があります。 もちろん、この追加容量をすべてのアベイラビリティーゾーンにデプロイすることにはコストがかかります。当社がレジリエンスについて話すとき、アプリケーションの可用性とコストのどちらを決めるかというビジネス上のトレードオフがあることを説明します。これが、選択したリソースにのみゾーンオートシフトを適用するもう 1 つの理由です。 ゾーンオートシフトの設定方法を確認しましょう ゾーンオートシフトの設定方法を示すために、よく知られている TicTacToe Web アプリケーション を CDK スクリプト を使ってデプロイします。クロスゾーン負荷分散を無効化するための CDK スクリプトのカスタマイズ方法は本記事の最後に記載しています。デプロイ後、 AWS マネジメントコンソール の Route 53 Application Recovery Controller ページを開きます。左側のペインで、 「ゾーンオートシフト」 を選択します。次に、ウェルカムページで、 「ゾーンオートシフトを設定」 を選択します。 デモアプリケーションのロードバランサーを選択します。現在、クロスゾーン負荷分散が無効になっているロードバランサーのみがゾーンオートシフトの対象であるということに注意してください。コンソールの警告からもわかるように、アベイラビリティーゾーンが 1 つ失われても動作を継続するのに十分な容量がアプリケーションにあることも確認します。 ページを下にスクロールして、AWS に 30 分間の練習を実行させたくない時間と曜日を設定します。最初は、オートシフトに慣れるまで、月曜日から金曜日の 08:00〜18:00 は練習をブロックします。時間はUTCで表され、 サマータイム によって変化しないことに注意してください。 UTC Converter を使用すると便利です。最初は営業時間を外して問題ありませんが、アプリケーションのトラフィックが少ない時や全くない場合に観測できないかもしれない問題を確実にキャプチャできるように、営業時間中にも練習を実行する設定をお勧めします。おそらく、ピーク時に影響を与えずにゾーンオートシフトを実行することが最も要求されることかもしれませんが、テストしたことがないことに、どの程度自信を持てるでしょうか。 常時ブロックしないのが理想ですが、それが常に現実的であるとは限らないことを我々は認識しています。 同じページのさらに下にある 2 つのサーキットブレーカーアラームを入力します。最初のものは練習の開始を防ぎます。このアラームを使って、今は練習を始めるのに良いタイミングではないと示します。例えば、アプリケーションで現在問題が発生している場合や、アプリケーションの新しいバージョンを本番環境にデプロイする場合などです。2 番目の CloudWatch アラームは、練習実行の結果を示します。これにより、ゾーンオートシフトにより、アプリケーションが練習実行にどのように反応しているかを判断できます。アラームが緑色のままであれば、すべてがうまくいったことがわかります。 練習中にこれら 2 つのアラームのいずれかがトリガーされると、ゾーンオートシフトは練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。 最後に、30 分間の練習が毎週実行され、アプリケーションの可用性が低下する場合があることに同意します。 そして、 「作成」 を選択します。 設定は以上です。 数日後、コンソールの 「リソースのゾーンシフト履歴」 タブに練習実行の履歴が表示されます。2 つのサーキットブレーカーアラームの履歴をモニタリングして、すべてが正しくモニタリングされ、設定されていることを確認しています。 オートシフト自体をテストすることはできません。アベイラビリティーゾーンで潜在的な問題を検出すると、自動的にトリガーされます。この記事で共有した手順をテストするためにアベイラビリティーゾーンをシャットダウンできるかどうかサービスチームに尋ねたところ、丁寧に断られました。 オートシフトと同じように動作する手動シフトをトリガーすれば、設定のテストができます。 さらに知っておくべきこと ゾーンオートシフトは、現在中国と GovCloud を除くすべての AWS リージョンで追加料金なしで利用できます。 crawl, walk, run方式の適用をお勧めします。まず、手動のゾーンシフトから始め、アプリケーションに対する信頼性を確立します。次に、営業時間外に練習実行を設定したゾーンオートシフトを有効にします。最後に、営業時間中のゾーンオートシフトの練習を含めるようにスケジュールを変更します。イベントに対するアプリケーションの応答を、イベントを発生させたくないときにテストする必要があります。 また、トラフィックを 1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンに戻したときに、アプリケーションのすべての部分がどのように復旧するかを総合的に考えることをお勧めします。私が思いつくリスト (完全なものではありませんが) は次のようなものです。 まず、既に説明したように、容量増加の計画を立てます。次に、各アベイラビリティーゾーンで発生する可能性のある単一障害点について考えてみましょう。例えば、単一の EC2 インスタンスで実行されるセルフマネージドなデータベースや、1 つのアベイラビリティーゾーンに存在するマイクロサービスなどです。ゾーンシフトを必要とするアプリケーションには、 Amazon DynamoDB や Amazon Aurora などのマネージドデータベースを使用することを強くお勧めします。これらには、レプリケーションとフェイルオーバーのメカニズムが組み込まれています。3 番目に、アベイラビリティーゾーンが再び利用可能になったときに切り替える計画を立ててください。リソースのスケーリングにはどの程度の時間が必要ですか? キャッシュをrehydrateする必要がありますか? 回復力のあるアーキテクチャと方法論について詳しくは、同僚 Adrian が執筆した この素晴らしいシリーズ記事 をご覧ください。 最後に、現在ゾーンオートシフトの対象となるのは、クロスゾーン負荷分散が無効になっているロードバランサーのみであることに注意してください。CDK スクリプトからクロスゾーン負荷分散を無効にするには、 StickinessCookieDuration を削除し、ターゲットグループに load_balancing.cross_zone.enabled=false を追加する必要があります。 CDK と Typescript を使った例を以下に示します。 // Add the auto scaling group as a load balancing // target to the listener. const targetGroup = listener.addTargets('MyApplicationFleet', { port: 8080, // for zonal shift, stickiness & cross-zones load balancing must be disabled // stickinessCookieDuration: Duration.hours(1), targets: [asg] }); // disable cross zone load balancing targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false"); さあ、次はあなたがゾーンオートシフトのメリットが得られるアプリケーションを選んでみましょう。まず、各アベイラビリティーゾーンのインフラストラクチャ容量を確認してから、サーキットブレーカーアラームを定義します。モニタリングが正しく設定されていることを確認したら、 ゾーンオートシフトを有効 にします。 原文は こちら です。翻訳はソリューションアーキテクトの新谷 歩生が担当しました。

このブログは 2020 年 9 月 21 日に Cher Simon (プリンシパルパートナーソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 多くの組織は、単一の AWS アカウントでクラウドジャーニーを開始し、規制、コンプライアンス、セキュリティ、またはコスト追跡の目的で、徐々に マルチアカウント環境 にクラウド活用を拡大していきます。組織はしばしば、高可用性、スケーラビリティ、パフォーマンスのために、 AWS グローバルインフラストラクチャー の複数のリージョンにワークロードとアプリケーションをデプロイすることを選択します。マルチアカウントかつマルチリージョン環境で構築および運用するには、グローバルな災害復旧 (DR) およびビジネス継続性戦略が必要です。お客様は、オーバーヘッドを削減し、バックアップのコンプライアンスを改善するために、組織の AWS アカウント全体のクロスリージョンバックアップタスクを統合および自動化する集中化されたバックアップ管理プロセスを求めています。 AWS Backup は、 Amazon EBS 、 Amazon EC2 、 Amazon RDS 、 Amazon Aurora 、 Amazon DynamoDB 、 Amazon EFS 、 AWS Storage Gateway など、AWS サービス全体のデータバックアップを簡素化および自動化する、フルマネージドでコスト効果の高いバックアップサービスです。さらに、AWS Backup は AWS Organizations と連携して、マルチアカウント環境におけるリソースのバックアップポリシーをひとつに集約したビューとして提供します。お客様は、リソースにタグ付けをするだけで AWS Backup が管理するクロスリージョンコピーのバックアップポリシーにそのリソースを関連付けることができます。この記事では、AWS Backup でバックアップポリシーをデプロイすることにより、組織の AWS アカウント全体のバックアップタスクを集中的に管理する方法をご紹介します。 前提条件 はじめに、管理アカウントで組織単位 (OU) を作成し、次の図に示すような組織階層に 3 つのメンバーアカウント (Prod アカウント、QA アカウント、Dev アカウント) を配置します。 ルート OU には Prod OU と Non-Prod OU の 2 つの OU が含まれています。 Prod アカウント を Prod OU に配置します。 Non-Prod OU の中に QA OU と Dev OU を作成します。 QA アカウント を QA OU に配置します。 Dev アカウント を Dev OU に配置します。 この チュートリアル のステップ 1 とステップ 2 に従って、同じ組織階層とアカウント構造を作成できます。次に、この ガイド に従って、AWS Organizations のすべての機能を有効にします。これで AWS Backup は、AWS Organizations で構成した組織の AWS アカウント全体のバックアップと復元の操作を管理およびモニタリングできます。 Prod アカウントで以下のリソースを作成し、 backup をキー、 prod を値としてタグ付けをします。 米国東部 (バージニア北部) リージョンに 1 つの Amazon RDS PostgreSQL データベース 欧州 (アイルランド) リージョンに 1 つの Amazon EFS ファイルシステム QA アカウントと Dev アカウントで以下のリソースを作成し、 backup をキー、 nonprod を値としてタグ付けをします。 米国東部 (バージニア北部) と欧州 (アイルランド) リージョンにそれぞれ 1 つの Amazon EC2 インスタンス。既存のリソースを使用することもできます。 のちほど、これらのリソースを米国東部 (バージニア北部) と欧州 (アイルランド) からアジアパシフィック (東京) に自動的にクロスリージョンコピーするため、管理アカウントでバックアップポリシーを作成します。 注意: AWS Backup がサポートするクロスリージョンコピーの対象サービスは こちら をご確認下さい。 ソリューションの概要 次の図は、この記事で説明するマルチアカウントバックアップアーキテクチャのアウトラインを示しています。 Prod OU 用に 1 つ目のバックアップポリシーと、 Non-Prod OU 用に 2 つ目のバックアップポリシーを作成します。次に、メンバーアカウントでの IAM ロールとバックアップボールトのプロビジョニングを自動化するため、 AWS CloudFormation StackSets をデプロイします。 組織の AWS アカウント全体のリソースを保護し、データのバックアップを他のリージョンにレプリケートするには、次の手順に従います。 クロスアカウント管理のオプトイン IAM ロールの作成 バックアップボールトの作成 バックアップポリシーの作成 バックアップポリシーのターゲットへのアタッチ AWS アカウント全体のバックアップと復元のアクティビティモニタリング ステップ 1: クロスアカウント管理のオプトイン 管理アカウントにログインし、 AWS Backup コンソール に移動し、左側のナビゲーションペインで 設定 を選択します。 バックアップポリシー と クロスアカウントモニタリング の両方で オンにする をクリックします。ステータスが オン になっていることを確認します。 AWS Backup がサポートする全てのリソースタイプを有効化します。 ステップ 2: IAM ロールの作成 AWS Backup がバックアップおよび復元の操作を実行できるように AWS Identity and Access Management (IAM) でサービスロールを設定します。メンバーアカウントに IAM ロールをデプロイするには、次の手順を実行します。 管理アカウントで AWS CloudFormation コンソール に移動し、ナビゲーションペインから StackSets を選択します。 StackSets ページの上部で StackSet の作成 を選択します。 Amazon S3 URL に https://awsstorageblogresources.s3.us-west-2.amazonaws.com/chersimoncrossregioncopyblog/IAMStackSet.yaml を貼り付けます。 StackSet の名前 を指定します。 IAM Configuration で crossaccountbackuprole と入力します。 次へ を選択します。 StackSet オプションの設定画面は何も変更せず、 次へ を選択します。 リージョンの指定 で 米国東部 (バージニア北部) を選択します。その他のデフォルト設定はそのままにします。 次へ を選択します。 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 にチェックし、 送信 を選択します。 スタックインスタンス タブで StackSet のデプロイ進捗を確認し、次のスクリーンショットのように全てのスタックインスタンスのステータスが SUCCEEDED になるのを待ちます。 注意: AWS Backup は、メンバーアカウントにロールが存在するか、ロールを引き受けることができるかどうかを検証しません。今回のケースでは crossaccountbackuprole が、バックアップポリシーに追加する各アカウントで適切かどうか確認することをお勧めします。 ステップ 3: バックアップボールトの作成 AWS Backup のリカバリーポイントは、バックアップボールトに保存されている特定の時点におけるリソースのバックアップコンテンツを指します。次の手順を完了して、AWS Backup で保護する各アカウントのソースリージョンと宛先リージョンの両方に個別のバックアップボールトを作成します。 管理アカウントにログインしたままで AWS CloudFormation コンソール に移動し、ナビゲーションペインから StackSets を選択します。 StackSets ページの上部で StackSet の作成 を選択します。 Amazon S3 URL に https://awsstorageblogresources.s3.us-west-2.amazonaws.com/chersimoncrossregioncopyblog/BackupVaultStackSet.yaml を貼り付けます。 StackSet の名前 を指定します。 AWS Backup Configuration で prodbackupvault と入力します。 次へ を選択します。 StackSet オプションの設定画面は何も変更せず、 次へ を選択します。 組織単位 (OU) にデプロイ を選択します。 AWS OU ID に、 Prod OU の OU ID を入力します。OU ID は AWS Organizations コンソール のナビゲーションペインから AWS アカウント を選択し、 Prod OU の OU ID を取得します。 リージョンの指定 で 米国東部 (バージニア北部) 、 アジアパシフィック (東京) 、 欧州 (アイルランド) を選択します。その他のデフォルト設定はそのままにします。 次へ を選択します。 送信 を選択します。 Non-Prod OU でこの 7 ステップを繰り返してください。 ステップ 4 の AWS Backup Configuration は nonprodbackupvault に置き換えてください。 ステップ 6 の AWS OU ID を Non-Prod OU の OU ID に置き換えてください。 注意: バックアップボールト名は大文字小文字を区別し、AWS Backup は目的のバックアップボールトが存在するかどうかを検証しません。保護したい各メンバーアカウントとリージョンに適切なバックアップボールトが作成されていることを必ず確認してください。 ステップ 4: バックアップポリシーの作成 Prod-OU 用のバックアップポリシーを作成するには、次の手順に従ってください。 管理アカウントで AWS Backup コンソール に移動し、 バックアップポリシー を選択して バックアップポリシーを作成 を選択します。 ポリシーの作成 セクションで、次の操作を行います。 ポリシー名 に prodbackuppolicy と入力します。 ポリシーの説明を入力します。 バックアッププランを設定 セクションの バックアッププランの詳細 で、次のように指定します。 バックアッププラン名 に prodbackupplan と入力します。 バックアッププランのリージョン で、 米国東部 (バージニア北部) 、 欧州 (アイルランド) 、 アジアパシフィック (東京) を選択します。 バックアップルールを追加 セクションの バックアップルール名 に prodbackuprule と入力します。 バックアップボールト に prodbackupvault と入力します。(※下記のスクリーンショットとはレイアウトが変わっている可能性があります。) バックアップ頻度 で 毎日 を選択します。 バックアップウィンドウ で バックアップウィンドウのデフォルトを使用 – おすすめ を選択します。この選択でバックアップジョブは午前 5 時 (UTC) から 8 時間以内に開始されます。 コールドストレージへの移行 で 月 を選択し、 3 と入力します。 保持期間 で 月 を選択し、 6 と入力します。 注意: コールドストレージが利用できるサービスの最新情報は こちら をご参照ください。対象外のリソースがコールドストレージ移行に追加された場合、その移行は無視されます。このチュートリアルにおいては、Amazon RDS がコールドストレージ移行の対象外です。 コピーを生成-オプション で、 コピー先にコピー-オプション に アジアパシフィック (東京) を選択します。 送信先バックアップボールト に prodbackupvault と入力します。 詳細設定 を展開し、 コールドストレージへの移行 で 月 を選択し、 3 と入力します。 保持期間 で 月 を選択し、 6 と入力します。 リソースを割り当てる セクションで、次のように指定します。 リソース割り当て名 に prodresources と入力し、 IAM ロール に crossaccountbackuprole と入力します。 リソースタグキー に backup 、 タグ値 に prod と入力します。 ポリシーの作成 を選択します。 Non-Prod OU 用のバックアップポリシーを作成するために、これらの 4 つのステップを繰り返します。 ステップ 2a の ポリシー名 は nonprodbackuppolicy に置き換えます。 ステップ 3a の バックアッププラン名 は nonprodbackupplan に置き換えます。 ステップ 3c の バックアップルール名 は nonprodbackuprule に置き換えます。 ステップ 3d の バックアップボールト は nonprodbackupvault に置き換えます。 ステップ 3i の 送信先バックアップボールト は nonprodbackupvault に置き換えます。 ステップ 4a の リソース割り当て名 は nonprodresources に置き換えます。 ステップ 4b の タグ値 は nonprod に置き換えます。 ステップ 5: バックアップポリシーのターゲットへのアタッチ これで、バックアップポリシーをターゲットである個々のアカウントまたは OU にアタッチする準備が整いました。OU にバックアップポリシーを適用すると、選択した OU のメンバーアカウント全体のリソースが保護されます。 管理アカウントで AWS Backup コンソール に移動し、 バックアップポリシー から prodbackuppolicy を選択します。 ターゲット セクションで アタッチ を選択し、 Prod OU を選択します。 アタッチ を選択します。 同様に nonprodbackuppolicy を選択し、 Non-Prod OU を選択します。 ステップ 6: AWS アカウント全体のバックアップと復元のアクティビティモニタリング 管理アカウントの AWS Backup コンソール の クロスアカウントモニタリング で、組織の AWS アカウント全体のバックアップ、コピー、復元ジョブをモニタリングできます。 AWS Backup コンソールで バックアップを復元 するには、メンバーアカウントの AWS Backup コンソールの 保護されたリソース を選択し、リストから リソース ID を選択します。復元する復旧ポイントを選択し、 復元 を選択します。プロンプトに従ってパラメータを指定します。 バックアップを復元 を選択します。 おめでとうございます！AWS のマルチアカウント環境全体でバックアップタスクとクロスリージョンコピーを集中管理するための AWS Backup の構成が完了しました。 クリーンアップ 今後の課金を避けるために、次の手順でサンプルリソースを削除してください。 バックアップポリシーからターゲット OU を削除します。 この ガイド に従って、バックアップポリシー、バックアッププラン、リカバリポイントを削除します。 AWS CloudFormation コンソールで スタックセットからのスタックインスタンスの削除 をし、次に スタックセットの削除 をすることで、IAM ロールとバックアップボールトを削除します。 まとめ この記事では、AWS Backup を使用してクロスアカウント管理を集中化し、クロスリージョンコピーのバックアップポリシーをデプロイする方法を示しました。また、既存および新しい AWS アカウント全体に必要な IAM ロールとバックアップボールトを自動化するためのサンプル CloudFormation StackSets も提供しました。 これで、管理オーバーヘッドを最小限に抑えながら、DR プランにこのプロセスを組み込み、AWS 環境全体でビジネス継続性戦略を簡素化できるようになりました。 &nbsp; この記事を読んでいただきありがとうございました。 翻訳はソリューションアーキテクトの松本が担当しました。 <!-- '"` --> Cher Simon Cher Simon は AWS で機械学習とデータ分析に特化したプリンシパルパートナーソリューションアーキテクトです。Cher は、エンタープライズ規模、データドリブン、AI を駆使したインダストリーソリューションのアーキテクトとして 20 年の経験があります。日々のお客様との業務においてクラウドネイティブなソリューションの構築を行う一方で、Cher は著者でもあり、AWS カンファレンスでも頻繁にスピーカーを勤めています。

会話型アプリケーションの開発には、認証ワークフロー、API インターフェース、データ管理、ビジネスロジックを実現するインテントなど、複数の複雑なコンポーネントが含まれます。これらの要素を適切に統合し、セットアップすることは、特に会話型アプリケーションを構築するのが初めての開発者や、AWS サービスでの豊富な経験がない開発者にとっては、難易度が髙いです。 この記事では、 AWS Amplify のパワーの活用と Amazon Lex のシームレスな統合によって会話型アプリケーションを構築する方法を紹介します。この記事では、認証ワークフロー、API インターフェース、データ管理、ビジネスロジックを実現するインテントなどの重要なバックエンドコンポーネントの確立に焦点を当て、会話型アプリケーションをシームレスに構築するための実用的なソリューションを提供します。 ソリューションの概要 このソリューションは、ユーザーが自然言語のクエリや発話を使用して AWS のサービスと対話できるようにする高度な仮想アシスタントアプリケーションのデモを行います。この仮想アシスタントは自然言語理解（NLU）のために Lex を利用し、強力な会話 AI として振る舞います。 仮想アシスタントに簡単なクエリを送信することで、AWS アカウント内のタスクを自動化することができます。Amplify の幅広いツールとサービスのセットを使用することで、仮想アシスタントのコア機能に集中しながら、簡単に堅牢なフルスタックの Web アプリケーションを作成することができます。 図1: アプリケーションアーキテクチャ このソリューションは、以下のコンポーネントで構成されています（図1）： React フレームワーク ： React のコンポーネントベースのアーキテクチャは、UI 要素の作成を簡素化し、開発者が仮想アシスタントのインターフェースのために再利用可能でモジュール化されたコンポーネントを構築することを可能にします。状態を管理する機能により、アシスタントとのインタラクション中にシームレスなユーザー体験を保証します。 Amplify ： Amplifyは、開発プロセスを効率化する一連のツールとサービスを提供し、開発者が認証や API といった AWS の必須サービスにフロントエンドを迅速につなぎこめるようにします。これにより、ユーザー管理やデータアクセス制御などの機能の実装が簡素化されます。 AWS AppSync ： AWS AppSync は GraphQL API 開発を簡素化し、バックエンドに問い合わせるための単一のエンドポイントを提供します。これにより、仮想アシスタントはバックエンドのサービスとセキュアにやり取りを行うことができ、会話の管理や、ユーザーのセッションデータと応答を効率的に取得することができます。 Amazon DynamoDB : DynamoDB は、仮想アシスタントのバックエンドにスケーラブルで柔軟なデータストレージソリューションを提供します。DynamoDB は、効率的なデータ検索と永続化を可能にし、ユーザーとのやり取りを後で使用するために確実に保存し、シームレスな会話履歴の実装を容易にします。 Amazon Lex ： Lex を使用すると、開発者は、インテント、スロット、およびサンプル発話を定義することによって、カスタム会話インターフェースを作成することができます。これにより、仮想アシスタントはユーザーのクエリを理解し、それを特定のインテントにマッピングすることができ、ユーザーのリクエストに応え、AWS のタスクを自動化することができるようになります。 AWS Lambda ： AWS Lambda は、Lex によって検出されたユーザークエリに基づいてアクションを実行し、インテントを充足させるロジックを処理します。ユーザーのリクエストに応じてバックエンドロジックをスケーラブルに実行できます。仮想アシスタントがユーザーに代わって様々な AWS サービスとやりとりし、AWS のオペレーションを効率的に自動化することができます。 オープンソースのコードとデプロイ手順はこの GitHub リポジトリ にあります。このソリューションでは、以下のような簡単なクエリ/発話を送信することで、AWS アカウントの様々なワークフローや操作を自動化することができます。 t3 microで 2 台の Red Hat インスタンスを起動 すべての Red Hat インスタンスを検索 パブリックサブネットにデプロイされたインスタンスの有無の確認 ワイドオープンなセキュリティグループルールの有無の確認 10.11.12.13 からのトラフィックを許可するようにセキュリティグループのルールの変更 S3 バケットのリストアップ バケット XYZ で “ppt ” の検索 自然言語を使用することは、様々な AWS のサービスを操作する必要がある非技術者の AWS ユーザーが AWS を簡単に利用できるようにします。彼らは、コマンドラインインタフェース（CLI）ツールやソフトウェア開発キット（SDK）の専門的な知識に精通していない可能性があります。 さらに重要な点として、このアプリケーションはアシスタントを搭載した色々な種類の Web アプリケーションを Amplify を活用して構築するためのガイドとしても使用することができます。 図2：ユーザーがアシスタントにクエリを送信しているアプリケーションのスクリーンショット ソリューションのコンポーネント このソリューションは、AWS サービスと相互に作用する強力なバーチャル・アシスタントを形成するいくつかの主要コンポーネントで構成されている。以下はコンポーネントとその利点です。 フロントエンド フロントエンドはインタラクティブな会話型ウェブアプリケーションの重要なコンポーネントです。私たちは create-react-app Node パッケージを使用してプロジェクトの構造をセットアップし、最新の JavaScript で開発環境を準備します。メインの App コンポーネントは App.js に含まれており、関連する React コンポーネントをインポートし、Amplify バックエンドを設定します。App コンポーネントは基本的な React ルーターで構成され、他の React コンポーネントへの主要なルートがいくつかあります： Conversations コンポーネント ： このコンポーネントは、現在のユーザーとアシスタントの会話を一覧表示し、ユーザーが新しい会話を作成したり、既存の会話を削除したりできるようにします。Material UI カードが各会話を表し、会話の説明といくつかのアクションボタンを含んでいます。 Interact コンポーネント ： このコンポーネントは、特定のユーザーの会話をハイライトし、ユーザーが会話の履歴を表示したり、アシスタントに新しいクエリ/発話を送信することを可能にします。また、このコンポーネントは、テキスト、アラート、表、またはその他の形式のものを、アシスタントから受信して表示します（図2）。 バックエンド – 認証 Amplify を使用して Amazon Cognito ユーザープールを作成します。ユーザープールはフルマネージドなユーザーディレクトリとして機能し、ユーザー登録、認証、アカウントの回復、およびその他の操作をすぐに処理します。アプリケーションに認証を追加するには、“amplify add auth” コマンドを使用し、App コンポーネントのエクスポートを “withAuthenticator” コンポーネントでラップするだけです。詳しくは こちら を参照してください。 バックエンド – GraphQL API AppSync と DynamoDB による GraphQL API は、アプリケーションのフロントエンドとバックエンド間の効率的なデータ管理とコミュニケーションを可能にします。また、ユーザーは以前の会話を再開したり、アシスタントから返された以前の回答/データを取得したりできるようにする必要があります。これらの機能を実現するために、Amplify を使用して DynamoDB テーブルでバックアップされた AppSync GraphQL API を作成します。必要なのは、“amplify add api” コマンドを実行し、GraphQL スキーマを定義することだけです。デプロイされると、Amplify は自動的にスキーマを完全に機能する GraphQL API に変換します。 図3：GraphQL APIスキーマ GraphQL スキーマ – モデル API はユーザーの会話データ（ユーザーによって開始された会話とその属性）、および発話データ（ユーザーによって送信された実際のクエリ、またはアシスタントによって生成された応答）を永続化するので、2つのモデルタイプでアプリケーションをモデル化できます： 会話タイプと発話タイプです。Amplify はそれぞれのモデルタイプを独自の DynamoDB テーブルにマッピングします。以下の GraphQL スキーマは、@model ディレクティブを使用してこれら2つのモデルタイプを定義する方法を示しています（図3）。 GraphQL スキーマ – 属性とリレーションシップ スキーマでは、モデルタイプごとに他の属性に加えて主キーを定義することもできます。両方のモデルタイプの主キーは、自動的に生成される「id」フィールドで構成されます。会話モデルの追加属性の例としては、会話の名前と説明、会話を作成したユーザー、createdAt のタイムスタンプなどがあります（図3）。会話は多くの発言から構成されるため、スキーマでこの関係をモデル化する方法が必要です。そのために、@hasMany ディレクティブを使用して、Conversation モデルと Utterance モデルの間に一方向の1対多のリレーションシップを作成します（図3）。このリレーションシップを使用すると、会話データを API に問い合わせることができ、オプションで会話に含まれる発話のリストを含めることができます。 GraphQL スキーマ – アクセスパターン API が重要なアプリケーションのアクセスパターンに対応できていることを確認する必要があります。例えば、前述の “Conversations” React コンポーネントでは、そのユーザーに固有の会話のリストを表示する必要があります。これを行うには、@index ディレクティブを使用して、Conversation モデルの “user” 属性にセカンダリインデックスを設定します（図3）。 GraphQL スキーマ – 認証ルール ユーザーデータを保護し、ユーザーごとのデータアクセスを許可するために、認可レイヤーを追加する必要があります。このアプリケーションのデータの機密性を考慮すると、DynamoDB のテーブルレコード（上記で定義したいずれかのモデル）には、それぞれの所有者のみがアクセスできるようにする必要があります。そのために、スキーマで定義された各モデルに対して@auth ディレクティブを使用し、認可ストラテジーとして “allow:owner” を指定します（図3）。この認可戦略は、サインインした各ユーザー（オーナーとも呼ばれる）が、自分自身の会話や発話のみを作成/読み取り/更新/削除できることを意味します。裏側では、Amplify は先に作成された Cognito ユーザープールを活用して、レコード作成時のレコード所有者の身元を含む所有者フィールドを保存します。このオーナーフィールドは、アクセスを承認する前にユーザーの JWT トークンのクレームと照合されます。 アプリケーションバックエンド: Amazon Lex bot Lexを使って、ユーザーのリクエストに関連するインテントを識別できるボットを作成します。まず、希望するインテントとスロットのリストを作成していきます。各インテントに対して、ボットがインテントを認識できるように訓練するための発話例のリストを提供します。以下は、このボットの一部として定義されたいくつかのインテント例です。完全なリストは GitHub のリポジトリ を参照してください。 EC2-list ：異なるタイプのユーザーフィルター（タイプ、ami、サブネットタイプ）に基づいてインスタンスの一覧表示 EC2-create ：異なる設定（count、type、ami）に基づいてインスタンスを作成 S3-search ：バケットまたは複数のバケットから特定のパターンに一致するオブジェクトを検索 S3-copy-to-bucket : 検索結果から特定したオブジェクトを新しいバケットにコピー Sg-rule-list : 制限されていないセキュリティグループのルールをリストアップ ユーザーのインテントが正常に検出されると、ボットはカスタム Lambda 関数を利用してインテント処理を実行する。この Lambda 関数は、ユーザーのクエリを処理するビジネスロジックが含まれているアプリケーションのバックエンドとして機能する。 例えば、ユーザーが「 Find all Red Hat instances 」というクエリを送信すると、Lex ボットは「 EC2-list 」というインテントを識別し、Lambda 関数を呼び出します。Lambda 関数内では、カスタムロジックが実行され、ユーザーが提供した条件に一致する Amazon Elastic Compute Cloud （Amazon EC2）インスタンスのリストを特定して返します。Lambda 関数の柔軟性を活かし、必要に応じて特定のカスタムインテントを満たすようにコードをカスタマイズすることもできます。 アプリケーションのホスティング アプリケーションをホストするには、 AWS Amplify Hosting を使用することをお勧めします。AWS Amplify Hosting は、フルスタックの CI/CD ワークフローをすぐに利用できます。これにより、コードのコミットに応じてフロントエンドとバックエンドの変更を単一のワークフローで継続的にデプロイすることができます。これを行うには、まず Amplify コンソールから git ブランチに接続する必要があります。あるいは、プロジェクトのバックエンドとフロントエンドの両方をビルドして公開する amplify publish コマンドを使って、手動デプロイでアプリケーションをホストすることもできます。 アプリケーションのビルドとデプロイ GitHub リポジトリ には、前提条件のリスト、詳細なデプロイ手順、使用コマンド例、クリーンアップ手順が掲載されています。 まとめ この記事では、Lex チャットボット、リクエスト処理用の Lambda、データ管理用の GraphQL API 、認証用の Cognito を備えた、アシスタント機能付きの Web アプリケーションをに Amplify を使用して構築する方法を記載しました。具体的には、ユーザが自然言語を使用して AWS と対話し、AWS の操作/設定を自動化することを可能にする “Cloud Assistant” アプリケーションを構築しました。この特定のアプリケーションは、新規 AWS ユーザーの学習曲線をフラットにしてくれますが、それは同時に、一般的なアシスタントを搭載した Web アプリケーションを構築することの有用性と価値も示しています。 Amplify を使ったフルスタックのウェブとモバイルアプリケーションの作成と、それが提供する様々なツールと機能の詳細については、 AWS Amplify をご覧ください。 この記事は、 Build a Conversational AI app to Interact with AWS using AWS Amplify を翻訳したものです。 翻訳は Solutions Architect の&nbsp; Takuya Setaka が担当しました。

この記事は、Salesforce Einstein AI の製品担当ディレクター、 Daryl Martis&nbsp; が共同執筆しています。 これは、Salesforce Data Cloudと Amazon SageMaker の統合について説明するシリーズの第 3 回目の投稿です。 第 1 回 と 第 2 回 では、Salesforce Data Cloud と Einstein Studio と SageMaker の統合により、企業が SageMaker を使用して Salesforce データに安全にアクセスし、そのツールを使用してモデルを構築、トレーニング、および SageMaker でホストされているエンドポイントにデプロイする方法を示します。SageMaker エンドポイントを Salesforce Data Cloud に登録して、Salesforce の予測を有効にすることができます。 この投稿では、ビジネスアナリストやシチズンデータサイエンティストが Amazon SageMaker Canvas でコードなしで機械学習 (ML) モデルを作成し、Salesforce Einstein Studio と統合するためのトレーニング済みモデルをデプロイして強力なビジネスアプリケーションを作成する方法を示します。SageMaker Canvas では、コードを書かなくても Salesforce Data Cloud のデータにアクセスし、数回クリックするだけでモデルをビルド、テスト、デプロイできます。加えて、SageMaker Canvas により特徴の重要度と SHAP 値を使用して予測結果を理解できるため、ML モデルによって算出された予測を簡単に説明できるようになります。 SageMaker Canvas SageMaker Canvas を使用すると、ビジネスアナリストやデータサイエンスチームは、コードを1行も記述しなくても、MLモデルや生成系 AI&nbsp;モデルを構築して使用できます。SageMaker Canvas には、分類、回帰、予測、自然言語処理 (NLP)、およびコンピュータビジョン (CV) に関する正確な ML 予測を生成するための視覚的なポイントアンドクリックインターフェイスが用意されています。さらに、 Amazon Bedrock の基盤モデル (Foundation Models, 以下 FM と呼称) や Amazon SageMaker JumpStart &nbsp;で公開されている FM にアクセスして評価し、生成系 AI ソリューションをサポートするためのコンテンツ生成、テキスト抽出、テキスト要約も行うことができます。加えて、 自ら構築した ML モデルを持ち込んで 、SageMaker Canvas 上で直接予測を生成できます。 Salesforce Data Cloud と Einstein Studio Salesforce Data Cloud は、あらゆるタッチポイントから顧客データをリアルタイムで更新できるデータプラットフォームです。 Einstein Studio は、Salesforce Data Cloud 上の AI ツールへのゲートウェイとなります。Einstein Studio では、システム管理者とデータサイエンティストが数回のクリックまたはコードを使用して簡単にモデルを作成できます。Einstein Studio の独自モデル導入 (BYOM) 機能により、SageMaker などの外部プラットフォームから作成されたカスタムモデルまたは Generative AI モデルを Salesforce Data Cloud に接続することができます。 ソリューション概要 SageMaker Canvas を使用して Salesforce Data Cloud 内のデータを使用して ML モデルを構築する方法を示すために、製品を推奨する予測モデルを作成してみましょう。このモデルでは、顧客の人口統計、マーケティングエンゲージメント、購入履歴など、Salesforce Data Cloud に保存されている特徴量を使用します。製品レコメンデーションモデルは、Salesforce Data Cloud のデータを使用して SageMaker Canvas のノーコードのユーザーインターフェイスを使用して構築およびデプロイされます。 ここでは、 Amazon Simple Storage Service (Amazon S3) に保存されている サンプルデータセット を使用します。このデータセットを Salesforce データクラウドで使用するには、「 Data Cloud で Amazon S3 Data Stream を作成する 」を参照してください。モデルを作成するには、次の変数が必要です。 Club Memeber — お客様がクラブ会員の場合 Campaign — 顧客が参加しているキャンペーン State — 顧客が居住する州または都道府県 Month — 購入月 Case Count — お客様が提起したケースの数 Case Type Return — 顧客が過去1年間に製品を返品したかどうか Case Type Shipment Damaged — 過去1年間に購入者の貨物が破損していたかどうか Enganement Score — 顧客のエンゲージメントのレベル（メールキャンペーンへの応答、オンラインストアへのログインなど） Tenure — 顧客と会社との関係の存続期間 Clicks — 購入前の 1 週間以内にお客様が行った平均クリック数 Pages Visited — 購入前の 1 週間以内に顧客が訪問した平均ページ数 Product Purchased — 実際に購入された製品 これ以降の手順で、エンタープライズデータにアクセスし、予測モデルを構築するために SageMaker Canvas 内で起動した Salesforce Data Cloud コネクタをどのように使用するのかの概要を示していきます。 SageMaker Canvas ドメインを登録するように Salesforce 接続アプリケーションを設定します。 SageMaker Canvas で Salesforce Data Cloud の OAuth を設定します。 組み込みの SageMaker Canvas Salesforce データクラウドコネクタを使用して Salesforce データクラウドデータに接続し、データセットをインポートします。 SageMaker Canvas でモデルを構築してトレーニングします。 モデルを SageMaker Canvas にデプロイし、予測を行います。 SageMaker 推論エンドポイントへのフロントエンド接続として　 Amazon API Gateway エンドポイントを デプロイします。 API Gateway エンドポイントを Einstein Studio に登録します。手順については、「 独自の AI モデルを Data Cloud に取り込む 」を参照してください。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 始める前に、以下の作業手順に沿って SageMaker ドメインを作成し、SageMaker Canvas を有効にしてください。 Amazon SageMaker Studio ドメインを作成します。手順については、「 Onboard to Amazon SageMaker Domain 」を参照してください。 上記の手順で作成されたドメイン ID とユーザープロファイルによって使用される実行ロールを書き留めておきます。このロールには、以降のステップで権限を追加していきます。 以下のスクリーンショットは、この記事のために作成したドメインを示しています。 次に、ユーザープロファイルに移動し、 Edit を選択します。 Amazon SageMaker Canvas 設定セクションに移動し、 Enable Canvas base permissions &nbsp;を選択します。 Enable direct deployments of Canvas models と Enable Model Registory registration permissions for all users &nbsp;を選択します。 これにより、SageMaker Canvas は SageMaker コンソールのエンドポイントにモデルをデプロイできるようになります。これらの設定は、ドメインまたはユーザープロファイルレベルで構成できます。ユーザープロファイル設定はドメイン設定よりも優先されます。 Salesforce 接続アプリケーションを作成または更新する 次に、SageMaker Canvas から Salesforce Data Cloud への OAuth フローを有効にするための Salesforce 接続アプリケーションを作成します。次の手順を完了します。 Salesforce にログインし、 Setup に移動します。 App Manager を検索し、新しい接続アプリケーションを作成します。 次の情報を入力します。 Connected App Name &nbsp;に名前を入力します。 API Name はデフォルトのままにします (自動的に入力されます)。 Connect Email に、連絡先メールアドレスを入力します。 Enable OAuth Settings を選択します。 Calllback URL &nbsp;に&nbsp; https://&lt;domain-id&gt;.studio.&lt;region&gt;.sagemaker.aws/canvas/default/lab &nbsp;と入力します。 &lt;domain-id&gt; にSageMaker ドメインのドメイン ID を、 &lt;region&gt; にリージョンを指定してください。 &nbsp;接続アプリケーションに次のスコープを設定します。 API を介してユーザーデータを管理します（ API ）。 いつでもリクエストを実行できます ( refresh_token , offline_access )。 Salesforce Data Cloud&nbsp;に対して ANSI SQL クエリを実行します（ Data_Cloud_query_api ）。 データクラウドプロファイルデータ を管理します（ Data Cloud_profile_api ）。 ID URL サービスにアクセスします（ id , profile , email , address , phone ）。 固有のユーザー識別子にアクセスします（ openid ）。 接続アプリケーションの IP 緩和設定を [IP 制限の緩和] に設定します。 Salesforce Data Cloud コネクタの OAuth 設定 SageMaker Canvas は AWS シークレットマネージャーを使用して、Salesforce 接続アプリケーションからの接続情報を安全に保存します。SageMaker Canvas では、管理者は個々のユーザープロファイルまたはドメインレベルで OAuth 設定を構成できます。シークレットはドメインとユーザープロファイルの両方に追加できますが、SageMaker Canvas は最初にユーザープロファイル内のシークレットを探すことに注意してください。 OAuth 設定を構成するには、次の手順を実行します。 SageMaker コンソールのドメインまたはユーザープロファイル設定の編集に移動します。ナビゲーションペインからドメインを選択し、設定したいユーザープロファイルを選択してください。その後、 Edit を押下してください。 ナビゲーションペインに表示されている Step4 Canvas setting &nbsp;を選択します。 OAuth settings &nbsp;の Add OAuth configureration を選択します。その後 Data Source で、 Salesforce Data Cloud を選択します。 シークレット設定では、新しいシークレットを作成するか、既存のシークレットを使用できます。この例では、新しいシークレットを作成し、Salesforce 接続アプリケーションからクライアント ID とクライアントシークレットを入力します。 Submit を押下します。 SageMaker Canvas で OAuth を有効にする方法の詳細については、「 Salesforce データクラウド用の OAuth の設定 」を参照してください。 これで、Salesforce データクラウドから SageMaker Canvas にデータアクセスして AI モデルと ML モデルを構築できるようにするセットアップが完了しました。 Salesforce データクラウドからデータをインポートする データをインポートするには、次の手順を実行します。 SageMaker ドメインで作成したユーザープロファイルから Launch を選択し、 Canvas を選択します。 Canvas アプリに初めてアクセスする場合、作成には約 10 分かかります。 ナビゲーションペインで&nbsp; Data Wrangler を選択します。 Create メニューで Tabular&nbsp; を選択し、表形式のデータセットを作成します。 データセットに名前を付け、&nbsp; Create を選択します。 Data Source で、&nbsp; Salesforce Data Cloud を選択し、&nbsp; Add Connection を選択してデータレイクオブジェクトをインポートします。 以前に Salesforce Data Cloud への接続を設定したことがある場合は、新しい接続を作成する代わりにその接続を使用するオプションが表示されます。 新しい Salesforce データクラウド接続の名前を入力し、&nbsp; Add Connection を選択します。 完了するまでに数分かかります。 接続を承認するための Salesforce ログインページにリダイレクトされます。 ログインが成功すると、リクエストはデータレイクオブジェクトリストとともに SageMaker Canvas にリダイレクトされます。 Amazon S3 経由でアップロードされたモデルトレーニング用の機能を含むデータセットを選択します。 ファイルをドラッグアンドドロップし、 Edit in SQL を選択します。 Salesforce はすべてのデータクラウドオブジェクト項目に “__c” &nbsp;を追加します。SageMaker Canvas の命名規則により、フィールド名には “__” &nbsp;は使用できません。 SQL を編集して列の名前を変更し、モデルトレーニングに関係のないメタデータを削除します。テーブル名をオブジェクト名に置き換えます。 SELECT "state__c" as state , "case_type_shipment_damaged__c" as case_type_shipment_damaged , "campaign__c" as campaign , "engagement_score__c" as engagement_score , "case_count__c" as case_count , "case_type_return__c" as case_type_return , "club_member__c" as club_member , "pages_visited__c" as pages_visited , "product_purchased__c" as product_purchased , "clicks__c" as clicks , "tenure__c" as tenure , "month__c" as month FROM product_recommendation__dlm ; Run SQL を選択し、 Create dataset を選択します。 データセットを選択し、 Create a model を選択します。 推奨製品を予測するモデルを作成するには、モデル名を指定し、 Problem type に Predictive analysis を選択し、 Create を選択します。 モデルの構築とトレーニング モデルを構築してトレーニングするには、次の手順を実行します。 モデルを起動したら、ターゲット列を product_purched に設定します。 SageMaker Canvas には、各列とターゲット列の主要な統計と相関関係が表示されます。SageMaker Canvas には、モデルの構築を開始する前にモデルをプレビューしてデータを検証するためのツールが用意されています。 プレビューモデル機能を使用してモデルの精度を確認し、データセットを検証してモデルを構築する際の問題を回避します。 データを確認してデータセットに変更を加えたら、ビルドタイプを選択します。 Quick build の方が速いかもしれませんが、モデルの構築にはデータのサブセットしか使用しません。この記事では、　 Standard build を選択しました。 標準ビルドの完了には 2 ～ 4 時間かかることがあります。 SageMaker Canvas は、モデルの構築中にデータセット内の欠損値を自動的に処理します。また、他のデータ準備変換を適用して、データを使って機械学習ができるように準備します。 モデルの構築が開始されたら、ページを離れることができます。 My models ページでモデルが Ready と表示されると、分析と予測の準備が整います。 モデルを作成したら、 My models に移動し、 View を選択して作成したモデルを表示し、最新バージョンを選択します。 Analyze タブに移動して、各特徴量が予測に与える影響を確認します。 モデルの予測に関する追加情報については、 Scoring タブに移動してください。 製品予測を開始するには、 Predict を選択します。 モデルをデプロイして予測を行う まずはSageMaker Canvas上で作成したモデルの予測結果をプレビューしてみましょう。以下は予測結果をプレビューするためモデルをデプロイし、予測を開始する作業手順となっています。 Batch prediction と Single prediction のどちらを行うかを選択できます。この投稿では、 Single prediction を選択します。 Single prediction を選択すると、SageMaker Canvas にはユーザーが入力できる機能が表示されます。 Update を選択して値を変更し、リアルタイムの予測を表示できます。 モデルの精度と、その特定の予測に対する各特徴量の影響が表示されます。 （訳者注）このようにして、 SageMaker Canvas で作成したモデルを SageMaker Canvas 上で予測を実行することができます。ここまでの操作で、モデルは期待した通りに動いていることがわかります。 SageMaker Canvas で作成したモデルを外部から実行するためには、作成したモデルをデプロイする必要があります。以下はその手順について記載します。 SageMaker Canvas 上からモデルをデプロイするには、デプロイ名を指定し、インスタンスタイプとインスタンス数を選択して、&nbsp; Deploy を選択します。 モデルのデプロイには数分かかります。 デプロイが成功すると、モデルのステータスが In Service に更新されます。 SageMaker Canvas には、デプロイメントをテストするためのオプションが用意されています。 View details を選択します。 Details タブには、モデルエンドポイントの詳細が表示されます。インスタンスタイプ、カウント、入力形式、応答内容、およびエンドポイントは、表示される主な詳細の一部です。 Test deployment を選択して、デプロイされたエンドポイントをテストします。 単一予測と同様に、ビューには入力フィーチャが表示され、エンドポイントをリアルタイムで更新およびテストするオプションが提供されます。 新しい予測は、エンドポイントの呼び出し結果とともにユーザーに返されます。 SageMaker エンドポイントを公開するための API の作成 Salesforce のビジネスアプリケーションを強化する予測を生成するには、SageMaker Canvas のデプロイによって作成された SageMaker 推論エンドポイントを API ゲートウェイ経由で公開し、それを Salesforce Einstein に登録する必要があります。 リクエストとレスポンスの形式は、Salesforce Einstein と SageMaker 推論エンドポイントによって異なります。API Gateway を使用して変換を実行するか、 AWS Lambda を使用してリクエストを変換し、レスポンスをマッピングすることができます。Lambda と API Gateway 経由で SageMaker エンドポイントを公開するには、「 Call an Amazon SageMaker model endpoint using Amazon API Gateway and AWS Lambda 」を参照してください。 次のコードスニペットは、リクエストとレスポンスを変換する Lambda 関数です。 import json import boto3 import os client = boto3.client("runtime.sagemaker") endpoint = os.environ['SAGEMAKER_ENDPOINT_NAME'] prediction_label = 'product_purchased__c' def lambda_handler(event, context): &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;features=[] &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;# Input Sample : {"instances": [{"features": ["Washington", 1, "New Colors", 1, 1, 1, 1, 1, 1, 1, 1]}, {"features": ["California", 1, "Web", 100, 1, 1, 100, 1, 10, 1, 1]}]} &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;for instance in event["instances"]: &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;features.append(','.join(map(str, instance["features"]))) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;body='\n'.join(features) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;response = client.invoke_endpoint(EndpointName=endpoint,ContentType="text/csv",Body=body,Accept="application/json") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;response = &nbsp;json.loads(response['Body'].read().decode('utf-8')) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;prediction_response={"predictions":[]} &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;for prediction in response.get('predictions'): &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;prediction_response['predictions'].append({prediction_label:prediction['predicted_label']}) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;return prediction_response 設定に基づいて、Lambda 関数の endpoint と prediction_label の値を更新します。 SageMaker 推論エンドポイントをキャプチャするには、環境変数 SAGEMAKER_ENDPOINT_NAME を追加します。 Einstein Studio に登録されているモデル出力 JSON キーと一致するように予測ラベルを設定します。 Lambda 関数のデフォルトのタイムアウトは 3 秒です。予測リクエストの入力サイズによっては、SageMaker リアルタイム推論 API の応答に 3 秒以上かかる場合があります。 Lambda 関数のタイムアウトを増やしますが、 API Gateway のデフォルトの統合タイムアウト (29 秒) 未満に保ちます。 Salesforce アインシュタインスタジオにモデルを登録 Einstein Studio に API Gateway エンドポイントを登録するには、「 Bring Your Own AI Models to Data Cloud . 」を参照してください。 結論 この記事では、SageMaker Canvas を使用して Salesforce Data Cloud に接続し、自動化された機械学習機能を通じて予測を生成する方法をコードを 1 行も記述せずに説明しました。データセット全体を使ってモデルをトレーニングする標準ビルドを実行する前に、モデルのパフォーマンスを早期にプレビューできる SageMaker Canvas モデルビルド機能を実演しました。また、SageMaker Canvas内の単一の予測インターフェースを使用したり、機能の重要度を利用して予測を理解したりするなど、モデル作成後のアクティビティについても紹介しました。次に、SageMaker Canvas で作成した SageMaker エンドポイントを API として利用できるようにしました。これにより、Salesforce Einstein Studio と統合して強力な Salesforce アプリケーションを作成できます。 今後の記事では、SageMaker Canvas の Salesforce Data Cloud のデータを使用して、視覚的なインターフェイスとシンプルな自然言語プロンプトを使用して、データの洞察と準備をさらに簡単にする方法を紹介します。 SageMaker Canvas を使い始めるには、「 SageMaker Canvas Immersion Day 」と「 Amazon SageMaker Canvas 入門 」を参照してください。 著者について Daryl Martis は、Salesforce Data Cloud の Einstein Studio の製品担当ディレクターです。彼は、AI/MLやクラウドソリューションなど、エンタープライズ顧客向けの世界クラスのソリューションの計画、構築、立ち上げ、管理において10年以上の経験があります。彼は以前、ニューヨーク市のファイナンスサービス業界で働いていました。 Linkedin で彼をフォローしてください。 Rachna Chadha は、AWS のストラテジック・アカウント担当プリンシパル・ソリューション・アーキテクト AI/ML です。Rachna は楽観主義者で、AIを倫理的かつ責任を持って使用することで、将来の社会を改善し、経済的および社会的繁栄をもたらすことができると信じています。余暇には、家族と過ごしたり、ハイキングをしたり、音楽を聴いたりするのがラフナは好きです。 Ife Stewart は、AWS のストラテジック ISV セグメントの主任ソリューションアーキテクトです。彼女は過去 2 年間にわたって Salesforce データクラウドに携わり、Salesforce と AWS 全体で統合されたカスタマーエクスペリエンスの構築を支援してきました。Ife はテクノロジー分野で10年以上の経験があります。彼女はテクノロジー分野における多様性とインクルージョンの提唱者です。 Ravi Bhattiprolu は AWS のシニアパートナーソリューションアーキテクトです。Ravi は、戦略的パートナーである Salesforce や Tableau と協力して、両社の顧客がビジネス目標を実現するのに役立つ、革新的で優れた設計の製品とソリューションを提供しています。 Miriam Lebowitz は、AWS のストラテジック ISV セグメントのソリューションアーキテクトです。彼女はSalesforce Data Cloudを含むSalesforce全体のチームと関わっており、データ分析を専門としています。仕事以外では、お菓子作り、旅行、友人や家族との充実した時間を楽しんでいます。 翻訳はソリューションアーキテクトの辻 浩季が担当しました。原文は こちら です。

はじめに この投稿では、Amazon Elastic Container Service ( Amazon ECS ) におけるアーキテクチャの原則について詳しく説明し、Amazon ECS におけるアプリケーションの高可用性とレジリエンス(回復力)を実現しやすくする機能のいくつかを概説します。Amazon ECS が AWS の可用性と回復力のパターンをどのように活用するように設計されているのか、そして Amazon ECS API などを利用してそうした考え方をどのように簡単に利用できるようになっているのかについて見ていきましょう。これにより、お客様のソリューションの要求に最適な Amazon ECS 構成と機能を選択できるようになると考えています。 AWS の目標は、お客様がビジネスの革新に集中できるように「差別化に繋がらない重労働」を取り除くことです。モダンアプリケーションの多くは、さまざまな障害モードに耐え、高い可用性を備えていることが求められます。回復力と可用性の高いソリューションを構築することは、困難で時間がかかることがあり、多くの場合その投資はビジネスの成功には不可欠ですが、それだけではソリューションを顧客に提供する際の差別化にはなりません。 Amazon ECS は AWS のフルマネージドのコンテナオーケストレーションサービスであり、 Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Fargate 、または Amazon ECS Anywhere を通じてオンプレミスのハードウェア上でコンテナ化されたアプリケーションを効率的にデプロイ、管理、スケーリングするのに有用です。 Amazon ECS は、AWS が使用している技術を活用して、高可用性を実現しやすくするように構築されています。お客様は Amazon ECS を有効に活用いただくことにより、自社とビジネスを真に差別化する重要な要素であるアプリケーションに集中することができます。 ソリューションの概要 可用性とレジリエンス（回復力） 障害の軽減について検討する際には通常、次の 2 つの領域について検討する必要があります。 そのソリューションはどの程度の可用性が必要なのか そのソリューションにはどの程度の回復力が必要なのか 可用性は、ソリューションが有用な作業を行える確率です。たとえば、ソリューションがカップケーキを販売する Web サイトである場合、ソリューションの可用性は、顧客がいつでもカップケーキを正常に購入できるかどうかで測定できます。ある時点で顧客がカップケーキの購入を完了できなければ、可用性の指標に悪影響を及ぼします。 回復力は可用性に影響しますが、微妙に異なります。回復力とは、悪条件下でも運用を継続できる能力と、通常の運用に戻る速さのことです。カップケーキの例では、顧客が最初に失敗した時点からどれだけ速くカップケーキを購入できるようになるか、で回復力を測ります。別の言い方をすれば可用性は、ある期間にわたってソリューションが動作しなくなった時間の比率として測定でき、回復力は、障害からの回復にかかる平均時間として測定できます。 Amazon ECS のコントロールプレーンを設計する際、私たちはこの 2 つの概念を深く検討し、両方に対応できるサービスとして設計しました。最初に、Amazon ECS がどのように設計され可用性を向上させることができるのかを探り、次に Amazon ECS がどのように設計及び管理されて回復力を向上させているかを確認していきます。 可用性 アプリケーションの稼働期間中に何らかの障害が発生することはほぼ間違いないと考えていいでしょう。AWS の設計で考慮しているのは、 予期せぬ事態を想定すること です。予期していなかった理由で、ある時点で何かがおかしくなることが起こりえます。障害率が非常に低い場合であっても規模が十分に大きい場合には、一定の規模の障害が発生することが想定されます。たとえば、99.99% の可用性で 100 万台のサーバーがある場合、これらのサーバーのうち、いつでも約 100 台に障害が発生すると予想されます。これに対応するため、AWS では、障害が通常の運用の一部であると想定してサービスを設計するようにしています。Amazon ECS では、この考え方を管理レイヤーのサービス設計に取り入れ、Amazon ECS 上に展開されるアプリケーションでも同じことを行うメカニズムを提供する機能を構築しました。 アベイラビリティーゾーンを使用した静的安定性 AWS は、AWS リージョンとアベイラビリティーゾーンの階層構造を通じて、冗長性の高いインフラストラクチャをお客様に提供します。各 AWS リージョンでは、 shared-nothing パターンが採用されています。つまり、各リージョンは他のリージョンから分離され、独立しているため、あるリージョンで起きた障害は他のリージョンには影響を及ぼしません。各 AWS リージョンは複数のアベイラビリティーゾーンによって構成されています。アベイラビリティーゾーンは、ネットワーク遅延の問題を回避するために地理的に十分近接していますが、相関的な障害を避けることを意図して冗長で独立した運用を行えるように、リージョン内に地理的に分散しています。アベイラビリティーゾーンは、それぞれが独自の冗長電源、ネットワーク、およびアベイラビリティーゾーン間接続を備えた 1 つ以上の個別のデータセンターで構成されます。これらのリージョンとアベイラビリティーゾーンという 2 つの構成要素は、可用性の高いサービスを構築するための基盤となります。 Becky Weiss と Mike Furr は、「 アベイラビリティーゾーンを使用した静的安定性 」という記事で、「静的安定性」の意味について説明しています。その記事では AWS のサービスが、アベイラビリティーゾーン全体で事前にスケーリングされた アクティブ – アクティブ ステートレスサービスをどのように活用するか概説しています。Amazon ECS コントロールプレーンは、多数の個別サービスで構成されるマイクロサービスアーキテクチャとなっています。これらのマイクロサービスは、Becky と Mike の記事で概説されているアクティブ – アクティブパターンに基づいて、AWS インフラストラクチャを使用して可用性を最大化するように設計されています。Amazon ECS は、サービス全体の完全かつ独立したコピーがすべてのリージョンにデプロイされています。各マイクロサービスは、リージョン内のすべてのアベイラビリティゾーンにデプロイされ、少なくとも 3 つのアベイラビリティゾーンにまたがってピーク負荷の 150% 以上のオーバープロビジョニングが行われます。これにより 1 つのアベイラビリティーゾーンで障害が発生した場合でも、Amazon ECS は残りのアベイラビリティーゾーンによってマイクロサービスの稼働に十分なキャパシティを確保しているため、お客様のリクエストに応え続けることができます。 Amazon ECS サービスと配置戦略 ワークロードは、コンソール、AWS コマンドラインインターフェイス ( AWS CLI )、または Amazon ECS API を介して直接 Amazon ECS クラスターにプロビジョニングされます。クラスターで実行されているワークロードのインスタンス を起動方法に関係なく「タスク」と呼びます。Amazon ECS のコントロールプレーンは、各マイクロサービスのコピーが少なくとも 3 つのアベイラビリティーゾーンで実行されていることを確認することで、基盤となるインフラストラクチャの障害による影響を軽減します。これと同様の考え方を適用することで、お客様のワークロードにおいて同様の可用性を実現することができます。Amazon ECS を Amazon EC2 で使用する場合、AWS リージョンにおいて利用可能である必要な数のアベイラビリティーゾーンにわたって、サービス内のタスクに spread 戦略を使用するようにサービスを設定します。 Amazon EC2 で Amazon ECS を使用する際にワークロードがアベイラビリティーゾーン全体に分散されるようにするには、それらのアベイラビリティーゾーンのクラスターに Amazon EC2 キャパシティーが登録されていることを確認する必要があります。 Amazon EC2 Auto Scaling グループ (ASG) キャパシティープロバイダー をクラスターに登録し、Amazon EC2 Auto Scaling グループが複数のアベイラビリティーゾーンで Amazon EC2 インスタンスを起動するように設定されていることを確認します。Amazon EC2 のキャパシティが複数のアベイラビリティーゾーンに分散されている場合、タスク配置をアベイラビリティーゾーン全体にできるだけ均等に分散するために spread 配置戦略 を選択することになるでしょう。 Amazon ECS と AWS Fargate を併用すると、タスクをアベイラビリティーゾーン全体に分散させることがさらに簡単になります。サービスを作成するとき、または RunTask リクエストにおいて、タスクのネットワーク設定で複数の Amazon VPC サブネットを指定する必要があります。Amazon VPC の各サブネットはそれぞれ単一のアベイラビリティーゾーンにあります。Amazon ECS は、タスクのプロビジョニング中に設定されたサブネットを使用してタスクを起動するアベイラビリティーゾーンを決定し、すべてのワークロードがこれらのサブネットに分散されるようにします。AWS Fargate は、常にサブネットを介してアベイラビリティーゾーン全体にタスクを分散します。この分散は、サービスをデプロイする場合はサービス名、RunTask を介して単一タスクを起動する場合はタスク定義のファミリー名に基づいています。 分散システムにおけるフォールバックの回避 障害の発生を軽減するためにできることはすべて行ったとしても、ある時点で予期しないイベントによってインフラストラクチャまたはソフトウェアに障害が発生することはあり得ます。Jacob Gabrielson は、「 分散システムでのフォールバックの回避 」という記事の中で、Amazon が障害に直面した際にフォールバック（障害が起きた際に異なるメカニズムを使用して、同じ結果を達成しようとする考え方）することで、かえって障害を悪化させてしまう可能性を発見したことについて概説しています。これを軽減するために、私たちはアクティブ – アクティブ・ソリューションを好んでおり、障害及び、サービス・アーキテクチャにおけるバイモーダル動作（バイモーダル動作とは、サービスが通常モードと障害モードで異なる動作を示すこと）を回避するように努めています。Jacob が概説しているように、我々の経験ではこれは複雑さとリスクをもたらすものです。 自分達のサービスの可用性を向上させるため、1 つのアベイラビリティーゾーンが失われてもサービスが存続できるように (通常、これは利用可能な容量の 33% に相当します)、事前に十分なスケーリングを行っています。例えばあるサービスにおいて、ある程度の余裕があるピーク時のトラフィック負荷をサポートするために 6 つのワーカーが必要であり、そのサービスが 3 つのアベイラビリティーゾーンでホストされている場合、アベイラビリティーゾーンごとに 3 つのワーカー（つまり、アベイラビリティーゾーン毎にプロビジョニングされるワーカー全体の 50%）をプロビジョニングすることで、合計 9 つのワーカーをプロビジョニングします。これにより、1 つのアベイラビリティーゾーンに障害が発生した場合でも、残りのアベイラビリティーゾーンでは十分に事前にスケーリングされ、ピーク時でもサービスがリクエストを処理し続けるのに必要なキャパシティを確保できます。 Amazon ECS サービスで同じ可用性を実現するには、サービスに必要なタスク数をピーク時のトラフィック負荷よりも 50% 大きくし、3 つのアベイラビリティーゾーンに分散して配置します。デプロイ中、またはスケーリングアクティビティの結果として、Amazon ECS は、設定した配置戦略を確実に反映するようにします。Spread 配置の場合、Amazon ECS は設定したアベイラビリティーゾーンにタスクを分散します。 必要なタスク数を決定するには、次の方法をとることができます。 1) まず、サービスを運用する上で必要なタスクの最大数を決定します。これを「基本希望数」と呼びます。 2) 使用する予定のアベイラビリティーゾーンの数を決定します。これを「AZ スプレッド数」と呼びます。 3) 1 つのアベイラビリティーゾーンが利用できなくなった場合でも、ピーク時のトラフィック量を満たし続けるために必要な追加タスク数を計算します。これを「目標希望数」と呼びます。 これを次のように計算します。 目標希望数 = 基本希望数 X ( AZ スプレッド数 / (AZ スプレッド数 – 1) ) たとえば、6 つのタスクが必要で、AZ が 3 つある場合、次のようになります。 目標希望数 = 6 X ( 3 / ( 3 – 1) ) = 9 アベイラビリティーゾーンが 3 つ以上あるリージョンで展開されるような大規模なサービスでは、サービスの構成要素をより多くのアベイラビリティーゾーンに分散させることで、1 つのアベイラビリティーゾーンにおいて必要な事前スケーリング規模を削減することができます。これにより、可用性要件を満たしながら、コストを削減できます。たとえば、us-east-1 には 6 つのアベイラビリティーゾーンがあります (2023/12/15 時点)。次の例を見ると、ピーク負荷を処理するために 600 個の Amazon ECS タスクを必要とするサービスに対して、より多くのアベイラビリティーゾーンで均すことのメリットがわかります。 3 つの AZ で 600 件のタスク:目標希望数 = 600 X ( 3 / ( 3 – 1 ) ) = 900 6 つの AZ で 600 件のタスク:目標希望数 = 600 X ( 6 / ( 6 – 1 ) ) = 720 このケースでは、可用性目標を達成しつつより多くのアベイラビリティーゾーンを使用することでコンピューティングコストを節約できることがわかります。50% の追加コンピューティングが必要なのではなく、上記のシナリオでは 20% で同じ結果が得られます。ワークロードの性質によっては、AZ 間のデータ転送料金が増加し、コストが増加する可能性に注意する必要があります。 このアプローチには多くの利点があります。まず、ロードバランサーと ロードバランサーのヘルスチェック が正しく設定されていれば、1 つのアベイラビリティーゾーンで障害が発生してもサービスは引き続き稼働します。第二に、Jacob が記事で概説したリスクを確実に軽減することになるため、障害を軽減するためのフォールバックがなくて済みます。第三に、このアプローチはテスト環境や検証環境などにおいて同じ設定で環境を構築し、単一のアベイラビリティーゾーン内のすべてのワーカーノードを強制終了することで、簡単にテストすることができます。 Amazon ECS ではアベイラビリティーゾーンからのトラフィックを除外する方法を標準的な運用手順の一部として使用しており、準本番環境および本番環境で定常的に適用しています。これは、顧客に対する高可用性の義務を果たすための重要な考え方です。 シャーディングによるワークロード分離 Amazon ECS では、シャーディングによるワークロード分離を使用しています。これは、Colm MacCártThaigh の記事「 シャッフルシャーディングを使ったワークロードの分離 」で紹介された概念です。これにより、サービスのスケーリングが可能になり、顧客の一連のワークロードを分離する境界を設けることができます。リージョン内の Amazon ECS コントロールプレーンを構成するサービスの中核となるセットは、いわゆるセルに分割されています。各セルは、コントロールプレーンの完全で独立したインスタンスであり、そのリージョンの顧客ワークロードのサブセットを管理します。各セルは前述のように、ピーク負荷容量の 150% 以上で、少なくとも 3 つのアベイラビリティーゾーンにわたってプロビジョニングされます。このセルベースのパーティショニングを使用して、お客様の障害分離をさらに強化しています。顧客のワークロードはリージョン内のセルのサブセットに関連付けられ、それらのワークロードを管理するプロセスは他のセルのプロセスとは異なっています。 このアーキテクチャパターンは、規模と可用性の両方に大きなメリットをもたらすことがわかりました。セルはコントロールプレーンの障害分離境界として機能し、アベイラビリティーゾーンはインフラストラクチャの障害分離境界として機能します。ハードウェアまたはソフトウェアの障害が原因で障害が発生した場合、その障害は通常、単一の障害ゾーンとお客様のワークロードの一部に限定されます。このパターンは、スケーリングを検討する際に非常に役立ちます。セルは本番環境全体の比較的小さな単位であると同時に、完全なソリューションでもあるため、テスト環境や検証環境などの非本番環境において単一セルであっても本番環境相当のスケーリングのテストを行うことができます。本番サービスのスケーリング制約を理解するには、1 つのセルに対してスケーリングのテストを実施するだけで済みます。なぜなら 1 つのセルが本番環境全体の小さな単位であり完全なソリューションであることから、その制約を把握することで本番サービスのスケーリング制約を類推することができるためです。 Amazon ECS のお客様は、クラスターとサービスを組み合わせてこれらの障害分離境界を活用することができます。クラスターを作成すると、1 つ以上の Amazon ECS セルに関連付けられます。クラスターにプロビジョニングされたワークロードは、クラスターが配置されているセル内にあるコントロールプレーンセルによって管理されます。 ソリューションを設計する際の考慮事項の 1 つは、1 つ以上のクラスターをプロビジョニングするかどうかです。Amazon ECS クラスターは、ワークロードをグループ化するために使用される論理的な名前空間です。これは、Amazon ECS 内の障害ゾーンとワークロードを関連させるのに役立ちます。1 つ以上のクラスターをプロビジョニングした場合、異なる Amazon ECS クラスターにおいて相関的な障害からの保護が可能になります。Amazon ECS クラスター内のサービスと Amazon EC2 インスタンスのサービスクォータは比較的大きく、リージョンあたり数千のクラスター、クラスターあたり数千の Amazon ECS サービスに対応できることにお気づきかもしれません。クラスターには料金はかかりません。また、同じ Amazon Virtual Private Cloud ( Amazon VPC ) ネットワークに多くのクラスターを配置できます。ワークロードは同じネットワーク内のクラスタ間で自由に通信できるため、コストをかけずに可用性のニーズに合わせてクラスタを使用することができます。 レジリエンス（回復力） 前述したように、レジリエンス（回復力）とは、悪条件下でも運用を継続できるサービス能力と、通常の運用に戻ることができる速さです。水平方向にスケーリングするワークロードでは、何か障害が発生したとしてもサービスを引き続き利用できるようにしたいと考えています。これは前のセクションで説明したように、事前スケーリングとアベイラビリティーゾーンの静的安定性によって実現されます。回復力の観点からは、サービスができるだけ早く定常状態に戻るようにすると同時に、稼働している状態をできるだけ保ちたいと考えています。 安全なハンズオフ（手放し）デプロイの自動化 AWS では自動化を重視しており、継続的デプロイはこの自動化の重要な部分です。Clare Ligouri は、安全な継続的デプロイを自動化するためのパターンを説明する 素晴らしい記事 を公開しています。 Amazon ECS は、継続的デプロイによって 1 日に複数回デプロイされます。サービスの変更は、障害発生時の影響範囲 (”Blast Radius : 爆発半径“とも呼ばれます)を緩和するために、1 つの AWS リージョンのアベイラビリティーゾーンに一度に 1 つずつ適用されます。また、サービスの新しいリビジョンがそのアベイラビリティーゾーン内のサーバーセットのごく一部にのみ導入されるような頻度でデプロイメントが管理されるようにします。Clare は記事の中で、これをローリングデプロイと呼んでいます。これは、Amazon ECS がお客様のサービスに対してデフォルトでサポートしているのと同じデプロイ戦略です。デプロイが成功しているかを確認するために、サービスの全体的な状態を追跡し、望ましくない動作をすばやく特定できるメトリクスを使用しています。これらのメトリクスで望ましくない結果が見つかった場合、デプロイは自動的にロールバックされます。同時に、1 つのアベイラビリティーゾーンで検出された障害は、影響を受けたアベイラビリティーゾーンのトラフィックを即座に除外する自動化プロセスによって軽減されます。これは、単一の AZ 障害に対応するための事前スケーリングがすでに実施されているため、お客様に影響を与えることなく実現できます。 自動化された安全なハンズオフデプロイとシャーディングによるワークロードの分離 前述のように、Amazon ECS コントロールプレーンを構成するサービスのコアセットは、セルと呼ぶものに分割されています。サービスの回復力をさらに向上させるため、デプロイは単一のセル内と単一のアベイラビリティーゾーン内で行われます。このアプローチにより、アベイラビリティーゾーンでの事前スケーリングを使用して、障害発生時やワークロードの分離時に AZ を除外し、デプロイから生じる予期しない問題への影響をさらに抑えることができます。その結果、変更は一部のサービスワーカーに少しずつ展開されます。 変更は変更セット（変更を加えられる一塊のグループ）としてリリースされます。新しい変更セットを導入する際には、非常に保守的なアプローチを取っています。徹底的なテストが完了すると、新しい変更セットは、ローリングデプロイ戦略を使用して本番環境に少しずつ導入されます。新しい変更セットは、1 つのアベイラビリティーゾーンと 1 つのセル内の 1 つのリージョンに導入され、一部のワーカーにのみ導入されます。デプロイは自動ロールバックアラームで監視されます。いずれかの時点で悪影響が検出された場合、デプロイはすぐにロールバックされます。私たちは待機時間 (Bake Time : Clare の記事 に記載) と初期段階の小さな変更の積み重ねを活用して、変更セットの信頼性を向上させていきます。十分に信頼性が高くなれば、導入のスピードを上げていきます。私たちは、単一の変更セットが、同時に 1 つのリージョンの単一のアベイラビリティーゾーンにのみデプロイされるようにすることに強くこだわっています。 AWS CodePipeline と Amazon ECS を使用すると、同じデプロイパターンをモデル化し、サービスに対して同様のレジリエンス（回復力）を実現できます。 まとめ この投稿では、Amazon ECS で採用しているレジリエンス（回復力）と可用性の原則をいくつか紹介しました。これらのパターンを使用することで、1 つの AZ に障害が発生した場合でも可用性の高いサービスを提供できると同時に、エンジニアリングチームはソフトウェアを安全かつ継続的に提供できるようになります。これらのパターンについては、この記事全体にわたって参照されている Amazon Builders’ Library のドキュメントで詳しく説明されています。これらのドキュメントが、可用性のニーズを満たすサービスを設計する際に有用なガイドとなることを願っています。 この投稿で説明したパターンを使用することには様々な利点があり、それによって Amazon ECS には予期しない障害に直面したとしても高い可用性と回復力が確保されるようになっています。こうしたパターンを継続的デプロイパイプラインに組み込むことで、障害を軽減するメカニズムの標準化ができます。私たちは、コントロールプレーンをセルに分割するというワークロードの分離テクニックを活用し、少なくとも 3 つのアベイラビリティーゾーンにわたってソリューションを事前にスケーリングしています。この考え方を自動ロールバックアラームを備えたローリングデプロイ戦略と組み合わせることで、サービスの可用性を維持しながら開発者の俊敏性を実現することができます。すべてのサービスがこのレベルの可用性や俊敏性を実現する必要があるわけではないため、場合によりこれらのパターンは適切ではないケースもあります。高可用性と回復力の目標を達成する必要がある、大規模で成長過程にあるサービスには、この投稿で紹介した方法論はうまく機能するでしょう。このトピックの詳細については、re: Invent 2023 のセッション “ Deep dive into Amazon ECS resilience and availability (CON401) “を参照ください。 翻訳はパートナーソリューションアーキテクトの髙橋達矢が担当しました。原文は こちら です。

こんにちは、AWS の七尾です。AWS のパブリックセクター官公庁事業本部にて DX Advocate として、官公庁のお客様のクラウド活用を支援しています。 クラウドを活用して、お客様と社会課題解決や様々なチャレンジをご一緒出来てることを嬉しく思っているこの頃です。 今日は、ご支援しているプロジェクトの一つで、デジタル庁が新しく始める、デジタルマーケットプレイス(DMP)について紹介させて頂きます。 最近お問合せが多い取り組みですので、ぜひ最後までお読みいただければと思います。 先にご紹介ですが、AWS では DMP への商品登録をお手伝いするワークショップを開催します。 SaaS 事業者様同士の交流会セッションもあります。ぜひご参加下さい。 内容とお申込みは、こちらのサイトをご覧ください。 はじめに 行政機関にお勤めの方で、IT の調達は仕様書を作るのが大変、事業者にたくさん参加してもらいたいけどなかなか集まらない、提案や見積が複数届いたけど、複数社を同じ軸で比較するのが難しい、という悩みを持った方はいらっしゃらないでしょうか。 また、IT ソリューションを販売する事業者の方々は、仕様書の解読や、自社製品の機能とのギャップ洗い出す作業が大変だったり、そもそも、どの行政機関で自社製品のニーズがあるのか分からない、と思ったことはないでしょうか。 今回ご紹介するのは、こうした買い手側、売り手側の悩みの解決を目指す、デジタル庁の新しい取り組みになります。 「デジタルマーケットプレイス（DMP）」はじまります デジタル庁は、省庁や自治体などの行政機関がクラウドソフトウェア（SaaS）を調達する際に、オンライン上でほしいソフトウェアを検索、比較して、調達できるような手法を検討しています。 まずは売り手であるソフトウェア会社、販売会社がデジタル庁と基本契約を結び、製品やサービスをオンライン上のカタログサイトに登録、掲載します。 買い手側である行政機関の職員は、このカタログサイトにアクセスすることで、ニーズに合ったソフトウェアを検索し、調達したいソフトウェアが見つかったら、販売会社も検索することが出来ます。カタログサイト内で公平に比較の上、調達したいソフトウェア、販売会社を選び、個別契約の締結に進みます。 この一連の仕組みが「デジタルマーケットプレイス」と呼ばれています。 出展：2023 年 10 月 4 日 デジタル社会実現ツアー 2023 デジタル庁様ご講演資料より 本格稼働は 2024 年秋 デジタル庁によると、2023 年度は α 版と呼ばれる実証サイトを構築し、売り手側、買い手側のニーズや操作性等の確認・調査を行うとされています*1。 この調査結果をもとに、2024 年度にシステム等の改修を進め、2024 年度秋を目途に、実際に行政機関が DMP 上で選択したソフトウェアを調達できるようにする計画です。 より良いニーズの把握や操作性の確認のためには、α 版の段階で掲載商品が沢山あったほうが望ましく、ソフトウェアを提供の事業者の皆様は、ぜひ登録して頂けたらと思います。 英国の事例を参考に デジタル庁が取り組むデジタルマーケットプレイスは、英国が既に運用しているデジタルマーケットプレイスを参考にしています。 英国では、2014 年より DMP が本格運用されています。2018 年には、登録されているサービスの ９ 割以上が中小事業者、スタートアップによるものになっており、 2021 年時点では、調達金額のうち 4 割が中小企業・スタートアップになっているそうです。 こうした取り組みはオーストラリアやカナダ等複数の国々でも導入されています *1。 こんな SaaS があったんだ カタログサイトでソフトウェアを探す際には、タグを使うことが出来ます。 現在公表されているタグを見ると、デジタル田園都市国家構想や、防災、子育て、こども、教育、業務改革といった、行政機関の政策タグと、チャットやウェブ会議、データ分析・BI 、旅費管理などといった、機能タグの２つのタグカテゴリーが用意されています。 こうしたタグ機能があると、IT にあまり詳しくない方で、「どういう風に検索したらいいか分からない」という人にとっても、「子育て関係の SaaS って、どんなものがどのくらいあるのかな？」といったふうに、自分の業務や関心から、ざっくり検索してみて大枠をつかむことも出来ると思います。 こうした検索の中で、これまで営業訪問を受けたり、イベントに参加して知り得た SaaS 以外の、これまで知らなかった新しい SaaS に出会えるかもしれません。 特に地域によっては、都市部のように最新の SaaS に関する情報を得ることが難しい行政機関もあると思いますので有効そうです。 こうした点をデジタル庁は、「情報の非対称性の解消」、と説明しています。 出展：2023 年 10 月 4 日 デジタル社会実現ツアー 2023 デジタル庁様ご講演資料よ り 自社の製品を探してもらえる SaaS 製品を売りたい、紹介したい事業者にとっては、カタログサイトに登録しておけば、買い手側である行政機関が検索してくれるため、これまで訪問したり電話したりしたこともなかった行政機関の検討の俎上に載るかもしれません。 当然、マーケットプレイスですので検索された後に比較が行われ、必ずしも購入に繋がらないこともあるかもしれませんが、それでもニーズをもつ買い手側の方から、自社製品を探してもらえることは嬉しいですよね。 デジタル庁によると、このデジタルマーケットプレイスによって、クラウドを活用する中小企業やスタートアップの SaaS 事業者のビジネスが増えることを狙っているそうです。 こうした事業者の中には魅力的な SaaS を持っていても、マーケティングや営業活動に大きな予算を避けない方々もいらっしゃるでしょうから、大きなメリットを感じられるのではないでしょうか。 出展：2023 年 10 月 4 日 デジタル社会実現ツアー 2023 デジタル庁様ご講演資料より どうやって SaaS を登録したらいいの？ 自社 SaaS を登録したい、リセラー登録したい、といった事業者の皆様は 11 月 30 日にオープンした事業者向けの カタログサイト α 版 を訪問ください。 α 版への登録方法等の情報が掲載されています。（カタログサイトは PC でご覧下さい） また、AWS では、このデジタルマーケットプレイスの取り組みを応援しており、AWS としてのフォローアップ説明会と、登録に関心のある事業者同士の交流会の開催を予定しています。 内容やお申込みについては、こちらの「 デジタルマーケットプレイス 実証カタログサイト DMP (α 版) ワークショップ・交流会案内サイト 」をご覧ください。 スタートアップ企業がデジタル庁と共創 これまでこのデジタルマーケットプレイスについてご紹介してきましたが、このサイトを構築しているのは、株式会社 dotD（ドットディー）という スタートアップ企業なんです。 dotD さんは、2023 年 10 月に設立 5年を迎え、これまで複数の共創事業や新規事業づくりのためのプラットフォーム（ dotHatch ）を自社開発したりと様々な取り組みをしてきた企業ですが、今回の DMP&nbsp; で、中央省庁の調達に初めてチャレンジしました。 中小企業やスタートアップに活躍してほしいデジタルマーケットプレイス自体が、設立 5 年のスタートアップ企業さんによって創られているのはとてもいいですね。 デジタルマーケットプレイス構築の dotD 小野田 CEO のコメント 設立 5 年目を迎えたばかりのスタートアップ企業ですが、この度デジタルマーケットプレイス（DMP）のサイト構築を担当させていただき大変光栄に思っております デジタル庁様が行政 IT 調達（クラウドソフトウェア）のカタログ化を行い、IT 事業者のクラウド製品を行政の皆さんがより効率的に調達できる仕組みの一端となっておりますが、本事業を通じてデジタルマーケットプレイスの実現に貢献し、新しい IT 調達の仕組みを通じた行政のデジタル化とイノベーション促進を支援して参りたいと思っております。 また、AWS クラウドの採用と プロフェッショナル・サービス ( 通称、ProServe プロサーブ ) の支援により、素早く効果的なインフラを構築することができました。 今後も AWS のパートナー支援プログラムの多彩なサポート提供を期待し、私たちのビジネスがより成長し、革新的なサービスを提供するための支援をいただけることを楽しみにしています。 公共案件への参入を AWS が支援しています dotD 小野田さんのコメントにもありましたが、dotD 社を AWS&nbsp; の プロフェッショナル・サービスチームが支援しました。 今回は、デジタル庁様の案件に対して要件の検討、ユーザガイドの作成、インフラやアプリケーションに関するセキュリティ診断等の部分を支援しました。 実際にプロジェクトに参画している、AWS&nbsp; プロフェッショナルサービスチームの上土井 裕人さんのコメントです。 「これまでの公共案件で蓄積したノウハウを活かし、dotD さんのようなスタートアップ企業が、デジタル庁プロジェクトへ参画することを支援できたことを嬉しく思います。 このように、スタータップ企業が、アジャイル開発などクラウドを活かした手法や、民間ビジネスで得られた知見を公共領域に持ち込んで頂き、それを公共領域の知見のある AWS&nbsp; プロフェッショナルサービスが支えることは、とても良い共創関係だと思います。 これからも続けていきたいと思いますので、参画をご検討だったり、お悩みお持ちのスタートアップ企業の方々は、ぜひお問合せ下さい。」 デジタルマーケットプレイスへの期待 公共調達の仕組みが大きく簡素化されることと、SaaS というクラウドによる提供形態の製品の紹介の場が作られることにより、これまで公共調達に参加しにくかったスタートアップ企業にとっては大きなメリットとなります。 また、買い手側も DMP というオンライン上で、いつでもどこでも、自分たちのニーズに合った製品を探し出すことが出来るようになります。 こうした、売り手と買い手双方にメリットのある場が創られることにより、売り手は品ぞろえを増やしたり、製品の低価格化ができるようにもなり、買い手の DMP 上での体験価値はさらに向上し、また買いやすくなるという、好循環が生まれます。 このような良い循環関係は、Amazon が大切にしてきたビジネスモデルにとても似ているものになります。 AWS はこれまでAWS クラウドをお使い頂いているスタートアップやパートナー企業の支援と、行政機関がクラウドを効果的に購入できるようになるための調達改革の支援を続けてまいりました。 それらの取り組みを今後、デジタル庁の DMP が創ろうとしている良い循環に沿って実施していくことにより、スタートアップを始めとした民間企業による行政・社会課題の解決を加速させ、国民・市民一人ひとりがデジタルの恩恵を享受できる社会の実現を目指していきます。 繰り返しのご案内ですが、製品登録に関心を持たれた方は、「デジタルマーケットプレイス 実証カタログサイト DMP (α 版) ワークショップ・交流会案内サイト」&nbsp; をご確認下さい。 おわりに 今回はデジタル庁が進めるデジタルマーケットプレイスについて紹介させて頂きました。 こうした取り組みによって、中小企業やスタートアップの公共案件参入が進むことに大きな期待を持っています。 興味を持った方は、下記に参考情報をまとめましたので、ご覧ください。 最後までお読みいただき有難うございました。 参考リンク デジタル庁 事業者向けのカタログサイト α 版 デジタルマーケットプレイス 実証カタログサイト DMP (α 版) ワークショップ・交流会案内サイト 株式会社 dotD AWS プロフェッショナルサービス AWS スタートアップ支援プログラム 出展： *1 デジタル庁　調達仕様書「情報システムの公平かつ迅速な調達のための 調査研究仕様書」より

アマゾン ウェブ サービス (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 \ &nbsp;&nbsp;&nbsp; --resource-identifier arn:aws:elasticloadbalancing:ap-southeast-2:123456789012:loadbalancer/net/zonal-shift-demo/1234567890abcdef \ &nbsp;&nbsp;&nbsp; --away-from apse2-az3 \ &nbsp;&nbsp;&nbsp; --expires-in 12h \ &nbsp;&nbsp;&nbsp; --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 \ &nbsp;&nbsp;&nbsp; --zonal-shift-id &lt;zonal-shift-id&gt; \ &nbsp;&nbsp;&nbsp; --expires-in 4h AZ3 のゾーンレプリカが回復したら、ゾーンシフトをキャンセルするか、自動的に期限切れになるのを待つことができます。キャンセルするには、CancelZonalShift API コールにゾーンシフト ID を指定して使用します。たとえば、次の CLI コマンドを使用します： aws arc-zonal-shift cancel-zonal-shift \ &nbsp;&nbsp;&nbsp; --zonal-shift-id &lt;zonal-shift-id&gt; 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 &nbsp;(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 &amp;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:// &lt; can-nodes &gt; .json Bash vehicle-model.json という名前のモデルマニフェストを作成してください。あなたのモデルマニフェストは、以下に示すシグナル（下記で詳細に説明された完全修飾名）から構成されるべきです。 Vehicle.Cameras.Front.Image Vehicle.Speed Vehicle.Acceleration Vehicle.Airbag.CollisionIntensity { "name": "fw-vision-system-model", "signalCatalogArn": "&lt;signal-catalog-ARN&gt;", "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": "&lt;your model manifest arn&gt;", "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- &lt; provisioned-identifier &gt; -vehicle --model-manifest-arn &lt; Your model manifest ARN &gt; --decoder-manifest-arn &lt; Your decoder manifest ARN &gt; 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": "&lt;your signal catalog&gt;", "targetArn": "&lt;your target&gt;", "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` &gt; 1", "minimumTriggerIntervalMs": 10000, "triggerMode": "ALWAYS" } }, "dataDestinationConfigs": [ { "s3Config": { "bucketArn": "&lt;your S3 bucket&gt;", "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": "&lt;Your signal catalog ARN&gt;", "targetArn": "&lt;Your vehicle ARN&gt;", "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": "&lt;Your S3 bucket&gt;", "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 でデータを確認する&nbsp; 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 は、アノテーションと人が関わるワークフローのために使用でき、衝突回避ソフトウェアの正確さと関連性を向上させることができます。今後のブログでは、ワークフローのこの部分のオプションを探る予定です まとめ&nbsp; この記事では、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'&lt;/p&gt;&lt;h2&gt; &lt;/h2&gt; 結論 これらの新しいブロックとエンティティタイプ( 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&amp;Dの社内プロジェクトとして人手不足解消・働き方改革のためのエッジ AI/IoT のプラットフォーム構想として出発し、構想を現実のものとするため、当初はまずはコトを広めるためのモノであるカメラとサービスとしての Viereka Manager の提供を開始されました。 大企業の中でスタートした Vieureka 様が実施された改革は多岐にわたりますが、まずはツールとしての AWS クラウドやマイクロサービスの活用により継続的な価値向上や開発効率の向上を行えるようにしました。 また、カーブアウトに伴って広くパートナーデバイスにオープンなビジネススキームへと変革し、88社のエコシステムを構築し、ビジネスKPIもモノの売上げから、コトの KPI、すなわち ARR や対応端末数への変革も実施されました。 一方、実際のサービスでの運用の中で、重要だが顧客価値にとっては本質ではないデバイスマネジメントが共通課題であるという気づきから、これを Vieureka 様がデバイスに依存しないサービスとし、お客様が価値提供に注力できるようになります。 &nbsp; このように、大企業内の社内プロジェクトからスタートし、様々な改革を実施すると共に、モノに依存しないデバイスプラットフォームへとビジネスを拡大された事例はモノコト変革において多くの参考になる要素がありました。 スマート道路モニタリングのサービス開発 登壇者: カヤバ株式会社 技術本部 基盤技術研究所 情報技術研究室 主幹研究員 髙松 伸一 様 動画 資料リンク 油圧部品を中心としたB2Bの製造販売事業を行っているカヤバ様は、主力製品である自動車部品の開発で培われた車両挙動の計測・分析技術を保有されています。このアセットを応用し、R&amp;D 部門が起点となって従来の受託製造モデルとは異なる、今までにないコト売り型のビジネス開発を推進されました。登壇いただいた高松様からは、新規事業創出や開発文化改革、デジタライゼーションなど、多面的な変革を芽吹かせようと取り組んでいる活動についてご紹介いただきました。 カヤバ様が提供する「スマート道路モニタリング」サービスは、従来手間のかかった自治体管理道路の路面調査を、日常パトロールカーにセンサーを搭載することで、走行するだけで計測、クラウドに収集することで定量的に路面状態を調査できるソリューションです。このサービスにより人手不足の解消と全路線の調査の実現を行えます。この新規事業はこれまでの製造業としてのビジネスと大きくモデルが異なり、また所管組織もなかったことから、実現には社内での推進合意に課題があったそうです。 これらの課題に対して高松様はスマートプロダクトビジネスと既存事業の特徴や相違点を整理し、トップとの調整を重ね引受先体制を検討するとともに、社内外へアセットをアピールすることによって、ブランド力を強化して味方を増やし、ソリューションの価値を向上させることで事業化を実現されました。多くの製造業のお客様にとって、従来の製造ビジネス（モノ）からスマートプロダクト（コト）へのシフトは組織やビジネスの構造を変える必要があり、大きなチャレンジとなりますが、カヤバ様の取り組みは先駆者事例として共感とともにご参考にいただけたのではないかと思います。 SaaS デリバリー戦略 登壇者: TOPPAN デジタル株式会社　ICT 開発センター DXソリューション開発部1T　棗田 昂 様 動画 資料リンク TOPPAN デジタル様は校正から社内回覧までの業務を自動化・オンライン化する SaaS「review-it! for Package」を提供されています。 TOPPAN デジタル株式会社の棗田様からは、SaaS 事業、特に B2B に販売していく上で最も重要であると考える「デリバリー」という考え方についてお話しいただきました。 デリバリーとは「価値の伝達」であり、SaaS におけるデリバリー戦略は、各事業フェーズ毎に異なると説明されています。 0-1におけるデリバリーの重点ポイントは、あるファーストクライアントの事例を例に本気で課題を解決しようとしている顧客に熱量を持ってプロダクトが目指す未来や提供したい価値を伝達することの重要性を伝達することであるとおっしゃっています。 次に、1-10におけるデリバリーの重点ポイントは、メインストリーム市場の顧客に対してあらゆる価値の伝達の仕方が可能なサービスを作ることが重要であると述べられました。 しかし、メインストリーム市場は、初期市場との間の性質が大きく異なり、価値観のギャップを埋めていくことが重要であり、且つ難しいポイントにもなります。TOPPAN様が直面した課題は、プロダクトの改善において意思決定の難易度が上がった点にあります。この課題に直面する中で、開発メンバーに対する依頼も一方通行となり、開発メンバーのモチベーション低下という悪影響にもつながりました。サービスの観点では、要望が多岐にわたり、それらに対して個別に対応する中でプロダクトの全体像がぼやけるという問題も発生しました。 このような問題が発生した原因について出てきた仮説が「価値を売っていたつもりが機能を売っていたのではないか」ということでした。お客様に求められる要望を受け続けていく「Fit &amp; 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 永田 享 が担当しました。