2024年6月10日〜12日の3日間で、AWS re:Inforce 2024 が米国ペンシルベニア州フィラデルフィアにて開催されました。re:Inforce は、AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスで、今年は 250 を超えるセッション、100 以上のインタラクティブセッションを有する AWS セキュリティに関する最大規模のイベントです。 基調講演では、AWS CISO である Chris Betz が、冒頭に AWS の “Culture of Security” についてお伝えするとともに、AWS のセキュリティに関する最新のイノベーションとビジョンを共有しました。また基調講演の後半では Amazon CSO の Steve Schmidt が、生成 AI の安全な利用を支える強力なセキュリティ文化について独自の視点を共有し、Eli Lilly 社の Ash Edmondson 氏がエンタープライズ規模でクラウド活用を進めるために不可欠な”Trust”を形作っていくためのアプローチについて明かしました。 基調講演や発表された新サービス・新機能の詳細については、ぜひ本ブログ後半で紹介する “AWS re:Inforce 2024 re:Cap” の記事もご参照ください。 AWS re:Inforce 2024 Japan Tour 日本のお客様が AWS re:Inforce により簡単に参加し、一層役立てていただくことを目的とし、AWS では航空券や現地での移動・宿泊、より AWS re:Inforce を楽しんでいただくための特別コンテンツをパッケージングした Japan Tour を昨年より企画しています。今回も、Japan Tour を利用して多くの日本のお客様に現地を訪れていただくことができました。ここではそのコンテンツの一部をご紹介します。 ネットワーキングイベント 各社から参加されるお客様同士の交流を目的としたイベントが開催されました。この他にも、日本・東南アジア・オセアニア地区のお客様や AWS 関係者が集まったグローバルなディナーイベントもあり、活発に情報交換をしていただくことができました。 AWS CISO Chris Betz との交流会 AWS CISO で、今回の AWS re:Inforce 2024 の基調講演スピーカーである Chris Betz が参加する特別セッションが行われました。事前に参加者から募集した質問に対して、直接 Chris が答えていく形で、基調講演では語り尽くせなかった Amazon/AWS の Culter of Security やその背景などについて更に理解を深める場となりました。 EXPOツアー AWS re:Inforce は様々なセッションやワークショップの他に、グローバルの様々な AWS パートナーによる EXPO も開催されました。限られた時間のなかで効率的に動向を把握し、魅力的なセキュリティソリューションの発見につなげていただくために、同時通訳付きで、多様なジャンルのパートナーブースに訪問する EXPO ツアーを提供し、多くの方にご活用いただきました。 現地での最速 Wrapup セッション 基調講演や発表された新サービス・機能を最速で現地で解説する日本語の Wrapup セッションを開催しました。ツアー参加者の方が、帰国後の出張報告などで活用いただくことができる実務的な内容となっており、好評いただきました。 AWS ニューヨークオフィス訪問 – 日本人 AWS 従業員との交流会 & AWS Builder Studio ツアー ツアー参加者の方には、AWS re:Inforceイベント終了後に AWS ニューヨークオフィス へお連れし、NYC で働く日本人 AWS 従業員との交流会に参加いただきました。グローバルの金融の中心地であるニューヨークで活動する金融チームの従業員、AWS サービス開発チームに所属する従業員らとともに、グローバルからみる日本企業への大きな期待や Culture of Security を含む AWS のメカニズムや働き方、AWS のサービスを安心して使っていただくため日々取り組んでいることなどを紹介し、参加者の方が皆様耳を傾けていらっしゃいました。 またこのオフィスに併設されている AWS Builder Studio を見学するツアーも開催しています。AWS Builder Studio は AWS の様々なテクノロジーを活用したソリューションを体験し、プロトタイピングを進めていくためのスタジオです。参加された皆様からは、「実際に動作するソリューションに触れられて興味深い」「自社への応用について具体的に想像する機会になった」などの声をいただきました。 AWS re:Inforce 2024 re:Cap 2024年7月26日に、 AWS re:Inforce 2024 re:Cap イベント を実施しました。本イベントでは、AWS ユーザー様や、AWS パートナー様のセキュリティリーダー向けに実施されたセッション（ 資料 、 動画 ）に加え、AWS re:Inforce 2024 にて発表されたセキュリティ関連の新サービス・新機能に関するまとめ（ 資料 、 動画 ）やユーザー事例のダイジェスト（ 資料 、 動画 ）をご紹介しており、セキュリティ意思決定を行う経営層へ向けたメッセージから現場のエンジニアに役立つ情報まで幅広い内容をお届けしました。 さらに re:Cap ならではの内容として、現地イベントに参加した以下のお客様によるセッションレポートや、Japan Tour の魅力についてもご紹介いただきました。 株式会社みずほフィナンシャルグループ ＩＴ・システム統括部クラウド統括チーム 調査役 佐藤 慶彦様 株式会社日本経済新聞社、CDIO 室、セキュリティエンジニア 藤田 尚宏様（ 資料 、 動画 ） 株式会社電通総研 コーポレート本部サイバーセキュリティ推進部 シニアアーキテクト 松永 桂子様 また、Security-JAWS コミュニティを代表して吉江様、吉田様からは、現地セッションに登壇した貴重な実体験について共有いただきました。（ 資料 、 動画 ） 2024年8月19日には、Security-JAWS コミュニティの勉強会にて「AWS re:Inforce 2024 もう一つの re:Cap」（ 動画 ）として、上記 re:Cap イベントでは触れられなかったre:Inforce 2024 の裏側やこぼれ話、Japan Tour の体験についても紹介させていただいておりますので、合わせて録画をご覧ください。 おわりに 本ブログでは、AWS セキュリティ最大規模のカンファレンスである AWS re:Inforce 2024 の開催と Japan Tour、その後の re:Cap についてご紹介してきました。ご覧いただいた方にとって、AWS re:Inforce への興味・関心を持っていただければ幸いです。 AWS re:Inforce 2025 は、今回と同じフィラデルフィア、Pennsylvania Convention Center にて2025年6月16日〜18日までの3日間の日程で開催されることが決定しました。少々気が早いですが、皆様と AWS re:Inforce 2025 の会場でお会いできることを楽しみにしています！ 過去の同種イベントの開催報告 AWS re:Inforce 2022 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2022-recap-seminar/ AWS re:Inforce 2021 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2021-recap-seminar/ AWS re:Inforce 2019 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2019-recap-seminar/ 本Blogについて 本Blogはセキュリティソリューションアーキテクト勝原 達也にて執筆いたしました。 TAGS:  AWS Security ,  re:Infoce

概要 クラウド上で複雑な分散型システムを運用する際、問題の根本原因を迅速に特定し、インシデントを解決することは大変な作業です。トラブルシューティングでは、複数の AWS サービスからのメトリクス、ログ、トレースをチェックする必要があり、問題を包括的に把握することが必要ですが、容易ではありませんが困難です。効果的なインシデント解決に必要な時間と手間をどのように軽減できるでしょうか？ この問題の解決方法として、このブログでは、 Alarm Context Tool (ACT) を紹介します。これは、 Amazon CloudWatch Alarms に追加のコンテキストを提供し、トラブルシューティングと分析を支援するソリューションです。 AWS Lambda 、 Amazon CloudWatch 、 AWS X-Ray 、 AWS Health 、 Amazon Bedrock などの AWS サービスを活用し、メトリクス、ログ、トレースを集約、分析し、有意義な洞察を生成します。ACT はトラブルシューティングプロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。 主な利点 トラブルシューティングの簡素化 ACT は、CloudWatch、X-Ray、 Amazon RDS Performance Insights 、 CloudWatch Container Insights などさまざまな情報源から関連データを自動的に収集、分析します。これにより、根本原因を特定し、トラブルシューティングに要する時間を削減できます。異なる AWS サービスからのデータを統合することで、ACT はシステムの状態とパフォーマンスの包括的な状況を提供し、インシデントの迅速な解決を可能にします。 コスト効率 アラーム通知内に詳細なコンテキストと洞察を提供することで、ACT は手動によるデータ収集と解析に関連する運用上のオーバーヘッドとコストを削減します。オペレーターは複数の AWS サービスを深く確認することなく、問題を素早く理解できます。これにより、問題の診断に必要な時間と労力が削減され、運用コストが低減し、リソースの活用が向上し、平均修復時間 (MTTR) が短縮されます。 拡張されたオブザーバビリティ ACT は Amazon Bedrock の生成 AI 機能を活用して、所見の要約、潜在的な根本原因の特定、関連するドキュメントへのリンクの提示を行います。これにより、AWS 環境のオブザーバビリティが高まり、保守やオペレーション作業が簡素化されます。AI で強化されたインサイトの統合により、オペレータは実行可能な情報を受け取ることができ、ログやメトリクスの分析ではなく、問題の解決に集中できるようになります。 アーキテクチャ このソリューションは、AWS Lambda 関数、CloudWatch Alarms、X-Ray トレーシング、Amazon Bedrock の AI 機能を組み合わせて構築されています。アーキテクチャの概要は次のとおりです。 図1. アーキテクチャ図 CloudWatch Alarms は、Amazon SNS トピックに通知を送信します。 Lambda 関数 は、SNS トピックをサブスクライブします。 Lambda 関数 は、CloudWatch メトリクスとログ、X-Ray トレース、RDS Performance Insights、Container Insights、AWS Health などのソースからデータを集約します。 Amazon Bedrock は、集約されたデータを処理し、要約、インサイト、根本原因を生成します。 Amazon SES は、処理された情報を電子メールで関係者に送信します。 X-Ray トレーシング は、 Powertools for AWS Lambda (Python) から Tracer を使用することで、Lambda 関数の実行の詳細なトレースを提供し、関数のパフォーマンスと動作の深い可視化を実現します。 事例シナリオ: ACT の実用例 シナリオの概要 CloudWatch Synthetics Canary の障害により、アラームがトリガーされます。これは、マイクロサービス API の間欠的なエラーまたは高い待ち時間の兆候です。ACT Lambda 関数が呼び出されて、追加のコンテキストを収集し、問題の詳細な分析を提供します。ACT がこのシナリオでトラブルシューティングを簡素化する方法は次のとおりです。 図2. Alarm Context Tool のトレースマップ データの収集と分析 アラームがトリガーされると、ACT Lambda 関数は以下のデータ収集のステップを実行します: CloudWatch メトリクス: この関数は、エラー率、レイテンシー、リクエスト数などの関連メトリクスを CloudWatch から収集します。 CloudWatch Logs: この関数は、今回の Canary 実行に関連する関連ログを CloudWatch Logs から収集します。 X-Ray トレース: API の実行フローの中で、失敗の正確な場所を特定するために、詳細なトレースが取得されます。たとえば、トレースデータは films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルへのクエリ中に問題が発生したことを示しています。 ヘルスイベント: この関数は、特定のサービスに影響を与える可能性のある関連イベントについて AWS Health にクエリします。 アラーム履歴: この関数はアラームの履歴を検査し、今回の場合は、これが継続的に発生している問題であると判断します。 リソース情報: この関数は、特定のリソースである CloudWatch Synthetics Canary の詳細を取得します。 Amazon Bedrock 分析: Amazon Bedrock は集約されたデータを分析し、判明事項の概要を生成します。 生成 AI によるインサイト Amazon Bedrock は収集したデータを分析し、調査結果の要約を生成します。この例では、DynamoDB テーブルで読み取りトラフィックが高くなり、プロビジョンドスループットを超過しているため、Bedrock はこれをルート要因と特定しています。 通知と報告 この関数は、調査結果を要約し、潜在的な解決策を示して関係者に電子メールを送信します。この電子メールには以下の内容が含まれています。 Root Cause Analysis (根本原因分析): 収集されたデータに基づき、DynamoDB テーブルがプロビジョンドスループットを超えていることなどの主要な問題を特定します。 Alarm Frequency and Immediacy(アラームの頻度と緊急性): アラームの過去のデータを分析して、その起動頻度を判断し、根本的な問題が再発するか、断続的か、一回限りのものかを特定に役立ちます。 Additional Metrics Analysis (追加のメトリクス分析): 失敗したカナリア実行やサーバーサイドエラーなど、関連するメトリクスからの洞察。 Potential Solutions (潜在的な解決策): DynamoDB のプロビジョンドスループットを増やすこと、パーティションキーの設計を最適化すること、アプリケーションコードで指数関数的バックオフを実装することなどの推奨事項。 AWS Health イベント: システムに影響を与える可能性のある、メンテナンスイベントや変更の予定。 例の概要 (抜粋) Root Cause Analysis (根本原因分析) この問題は、DynamoDB テーブルの Movies がプロビジョニングされたスループット容量を超えていることに関連しているようです。 films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルをクエリしているときに、 ProvisionedThroughputExceededException が発生しました。 Alarm Frequency and Immediacy (アラームの頻度と緊急性) アラームは過去数時間に複数回トリガーされており、問題が繰り返し発生していることを示しています。OK 状態と ALARM 状態が頻繁に切り替わることから、問題はトラフィックの急増に関連していることがわかります。 Additional Metrics Analysis (その他のメトリクス分析) Failed メトリクスの値は 1 で、最近の Canary 実行 の失敗を示します。 5xx メトリクスの値は 1 で、サーバー側のエラー（502 Bad Gateway）を示唆しています。 SuccessPercent メトリクスは、Canary 実行が失敗した場合は 0% と表示されます。 Potential Solutions (潜在的な解決策) 問題を解決するには、次の手順を検討してください。 Movies DynamoDB テーブルのプロビジョニングされたスループット容量を増やします。 パーティションキー設計のベストプラクティスを実装する。 アプリケーションコードにジッターを伴うエクスポネンシャルバックオフを実装します。 Relevant Documentation (関連ドキュメント) DynamoDB Provisioned Throughput DynamoDB Read/Write Capacity Mode DynamoDB Guidelines for Tables 結論 このブログでは、Amazon CloudWatch Alarm をより豊富な文脈と洞察によって強化し、トラブルシューティングと分析を支援するソリューションである Alarm Context Tool (ACT) を紹介しました。ACT は複数の AWS サービスと Amazon Bedrock の生成 AI 機能を活用しています。これにより、インシデント解決プロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。 ACT について、さらに学び、使用を開始するには GitHub リポジトリ のセットアップ手順に従ってください。 ACT の使用ついての質問や改善の提案、問題がある場合は、 GitHub リポジトリ で気軽に Issue を作成してください。皆様のフィードバックと貢献を大切にし、ACT をより良いものにしていきます。 著者について Alex Livingstone Alexは、Amazon CloudWatch、AWS X-Ray、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for OpenTelemetry などのAWS オブザーバビリティツールに焦点を当てた Principal Solution Architect です。彼は、お客様がクラウドで運用し、アプリケーションに関する洞察を得るのを支援することが大好きです。ぜひ、LinkedIn (/aelivingstone) で彼を探してください 。 本記事は、 Respond to CloudWatch Alarms with Amazon Bedrock Insights を翻訳したものです。翻訳は テクニカルアカウントマネージャー の 日平 が担当しました。

通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch に 2 分の遅れで取り込まれるため、アラームが起動しない可能性があります。 Amazon CloudWatch アラーム を使用して AWS リソースを監視し、メトリクスが事前に定義されたしきい値を超えたときに自動的にアクションを実行していますか？ メトリクスに対してアラームを設定 したり、 ログに対してアラームを設定 したりし、 アラームを組み合わせ 、アラームがトリガーされたときに 特定のアクションを実行 していますか？ メトリクス数式 、 Metrics Insights クエリ 、または 別のリソースのデータソース に基づいてアラームを作成する必要があるユースケースがある場合、このブログはアラームの作成、管理、大規模な利用におけるベストプラクティスを理解するのに役立ちます。 このブログでは、一般的なアラームの推奨使用例について説明し、データ欠損シナリオや、アラームが発報するまでの時間を短くするための構成など、具体的な使用例についても詳しく説明します。 このブログでは、以下の内容を取り上げます。 すべての Amazon CloudWatch アラームの設定に適用される一般的なアラームの推奨事項 既存のアラームの調整 データが欠落している場合の推奨アラーム設定 より早い警告のための推奨アラーム設定 Metric Insights アラームを使用した動的アラームの作成 価値の低いアラームのクリーンアップ アラームの推奨事項 CloudWatch アラームを素早く設定し、モニタリングのベストプラクティスに従うには、CloudWatch コンソールの Alarm recommendations を使用します。CloudWatch は、他の AWS サービスによって公開されるメトリクスに対して設定することを推奨される アラームの推奨事項 を提供しています。これらの推奨事項は、モニタリングのベストプラクティスに従うためにアラームを設定する必要があるメトリクスを特定するのに役立ちます。推奨事項には、設定するアラームのしきい値も示されています。これらの推奨事項に従うことで、AWS インフラストラクチャの重要なモニタリングを見落とすことがなくなります。 CloudWatch コンソールのメトリクスのセクションで、推奨アラームのフィルタを選択できます。また、コンソールを使用して、推奨アラームの定義をインフラストラクチャとしてコード化したものをダウンロードし、このコードを使用して AWS CloudFormation 、 AWS CLI 、または Terraform でアラームを作成することができます。図 1 は、CloudWatch メトリクスのコンソール画面で利用可能な推奨アラームのフィルタを示しています。 図 1. CloudWatch Metrics コンソールのアラームに関する推奨事項 アラームの調整 アラームを作成するときは、期間、評価期間 (N)、アラームを発生させるデータポイント数 (M) の設定を指定して、CloudWatch がアラームの状態を変更するタイミングを評価できるようにします。M/N 設定の主な利点は、すべての ‘N’ データポイントではなく、’M’ データポイントでアラームの状態の変更を評価できることです。M/N 設定を使えば、状態の変更に考慮されるデータポイント数を決められます。ただし、アラームの状態を計算するには常に N 個のデータポイントが必要です。この期間内のデータポイント数が N 未満の場合、アラームは欠落データの扱いの設定に従って、不足分のデータポイントを補います。 図 2. CloudWatch アラームの評価 M/N 設定は、メトリクスが CloudWatch に遅延して受信された場合でも、アラームの誤った遷移を防ぎます。遅延したメトリクスは、メトリクスデータが正確に反映されない恐れがあります。この誤った遷移は、M/N 設定によって防ぐことができます。そのため、3/3 ではなく 2/3 のように M < N を設定することをお勧めします。ほとんどの場合、最新のデータポイントにはメトリクスの遅延の問題があります。そのため、M の設定を使用して、最新のデータポイントを除外できます。 例えば、次のような設定のアラームを考えてみましょう。 指標: MyMetric Threshold: >50 Period: 60(sec) 統計値: SUM Evaluation Period: 3 M / N: 2 / 3 この例では、アラームに戻される可能性のあるウィンドウは次のとおりです。 1) [12, 13, 40, 50, 60, 90, 10, 20] ==> 設定された数 (3) より多くのデータポイントがあっても、アラームは最新の N 個のデータポイントを使用して状態の判断を試みます。この場合、N は 3 です。アラームは最新の 3 つのデータポイント 90、10、20 を確認します。ここでは、アラームが実行されるには、2 つのデータポイントが閾値を超えている必要がありますが、1 つのデータポイントしか閾値を超えていません。 2) [12, 13, 40, 50, 60, 90, 100, 20] ==> 最新の 3 つのデータポイントのうち 2 つが閾値を超えているため、 ALARM 状態になります。 M 個を超えるデータポイントがブリーチ (breach) した場合、アラームは ALARM 状態に遷移します。 データが欠落している場合のアラームの設定 欠落データの扱いの設定は、サービスがダウンしてデータポイントを CloudWatch に公開できない場合の遅延時に、アラームが ALARM 状態に移行するまでの時間に大きな影響を与えます。各アラームについて、CloudWatch に欠落データ (TMD) ポイントを notBreaching、breaching、ignore、missing のいずれとして扱うかを指定できます。デフォルトの動作は missing です。欠落データ機能は、欠落データの動作が危険を示す場合は欠落データを breaching として扱うべきであるなど、さまざまなシナリオで役立ちます。欠落データを気にしない場合は、欠落データを notBreaching または ignore として設定することもできます。アラームの状態を判断するためには一定数のデータポイント(N 個)が必要ですが、実際にはデータポイントの個数が N に満たない x 個の場合、欠落データの扱い設定に従い、残りの N – x 個のデータポイントを仮想的に補完し、アラームの状態を判断します。 より早く警告するためのアラームの設定 より正確なアラームをより早期に検知したい場合、これが出来ない一般的な根本原因はデータ欠損です。つまり、メトリクスのデータポイントが常に遅れているため、または送信元のサービス/アプリ/リソースがダウンしているためにアラームで受信されない場合です。メトリクスデータが常に遅延して CloudWatch に取り込まれるため、アラームの遅延が発生する可能性があります。これにより、その期間の評価がすでに完了した後にメトリクスデータポイントがバックフィルされ、バックフィルされたデータポイントが閾値を超えていてもアラームが発生しません。 Metric Math を使用すれば、アラーム自体で欠落データを処理できます。Metrics Math (FILL、repeat) を使えば、最後の値を繰り返すことができ、データが遅延する場合に便利です。Metrics Math (FILL、breaching value) を使えば、ダウンタイムの際にアラームをより早く反応させることができます。 これらに対処するための推奨構成を含むいくつかのユースケースを見てみましょう。 ユースケース １ EC2 インスタンスがダウンしているため、データポイントが一部欠損している場合。アラーム設定は以下のとおりです。 Metric: EC2/CPUUtilization Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N: 2 / 3 Treat Missing Data : Breaching 上記の設定の場合、TMD が 「Breaching」 に設定されていても、アラームが ALARM 状態に移行するまでに 7 分かかります。インシデントの早期検知と復旧は、ビジネスとエンドユーザー体験にとって重要なため、この遅延は重要なワークロードには適さない可能性があります。 ソリューション : データポイントが欠落している場合に ALARM 状態への移行を早めるために、Metrics Math (FILL、breaching value) を使用することをお勧めします。たとえば、Metrics Math の FILL(m1,90) は、CPUUtilization メトリクスの欠落値を 90 に埋める式です。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかるのに対し、この設定では 2 分しかかかりません。 Metric: EC2/CPUUtilization ## FILL(m1,90) Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N: 2 / 3 Treat Missing Data: Breaching ユースケース 2: EC2 インスタンスに閾値を超えるデータポイントがあるが、通知が遅れアラーム状態に移行するのに時間がかかりすぎる場合。 Metric: EC2/CPUUtilization ## FILL(m1, REPEAT) Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N : 2 / 3 Treat Missing Data: Breaching 上記の設定では、TMD を 「Breaching」 に設定しても、アラームが ALARM 状態に遷移するまでに 7 分かかります。これは重要なワークロードには適さない可能性があります。 ソリューション : 違反データポイントがある場合に ALARM 状態への移行を速めるため、Metrics Math (FILL(m1, REPEAT)) を使用することをお勧めします。たとえば、Metrics Math FILL(m1, REPEAT) は、CPUUtilization メトリクスの違反値で埋めます。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかりますが、この設定では 2 分しかかかりません。 ユースケース 3: メトリクスデータが常に 2 分の遅延を伴って CloudWatch に取り込まれているため、アラームが発動することが無い場合。 ソリューション : このような状況では、M/N を高く設定すると役立ちます。たとえば、M/N を 3/5 ではなく 3/7 に設定すると、2 分後にバックフィルされる遅延データポイントを考慮しやすくなります。 上記のすべてのユースケースソリューションは、 AWS CloudFormation または AWS Cloud Development Kit (CDK) / Terraform を使用して、Metrics Mathとアラーム作成が自動化されるので、大規模に実装できます。 Metric Insights アラームを使用した動的アラーム SQL クエリを使って、アカウント間の動的なリソースフリート全体に対して Metrics Insights アラームを単一のアラームで設定できます。 Amazon CloudWatch Metrics Insights アラームを アカウント間 で CloudWatch アラームと Metrics Insights クエリを組み合わせることで、高速に変化する環境を一貫してモニタリングし、異常が検出されたときにアラートを発する動的なアラームを設定できるようになります。Metrics Insights アラームの一般的な使用例としては、アカウント内の Amazon DynamoDB テーブルへのリクエストがそのテーブルのプロビジョンド読み取りキャパシティユニットを超え、スロットリングが発生したときにアラームをトリガーしたり、アカウント内の Amazon ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラームをトリガーすることがあります。これらのユースケースは、アラームライフサイクルを最適化するために自動化できます。 価値の低いアラームのクリーンアップ 価値の低い、または構成ミスのある CloudWatch アラームを削除すると、CloudWatch アラームの費用を削減できます。AWS リージョン全体で数千の Amazon CloudWatch アラーム がある場合でも、リージョン全体で価値の低いアラームや構成ミスのあるアラームを素早く特定できます。 アラームの削除を自動化 することで、価値の低いアラームや構成ミスのあるアラームを削除し、コストを削減できます。 まとめ このブログでは、CloudWatch アラームを使用した信頼性の高いモニタリングのための重要なヒントと戦略について学びました。アラームの推奨事項の一般的なユースケースを説明し、欠落データのシナリオや警告を早期に発する設定など、具体的なユースケースについて詳しく説明しました。 詳細は、 AWS Observability ベストプラクティス 、 AWS One Observability ワークショップ 、 AWS re:Invent Observability 動画 を参照してください。 著者について Karthik Chemudupati Karthik Chemudupati は、コスト最適化とオペレーショナル・エクセレンスの実現を支援する AWS の Principal Technical Account Manager (TAM) です。彼は 20 年以上にわたりソフトウェアエンジニアリング、クラウドオペレーション、自動化の経験を持っています。2016 年に TAM として AWS に入社し、米国西部で 10 社以上の企業顧客と働きました。仕事以外では、家族と過ごす時間を楽しんでいます。 Sharmadha Muthuram Sharmadha Muthuram は、AWS Professional Services の Senior Cloud Infrastructure Architect です。お客様が AWS で成功するため、技術的なガイダンス、設計、および実装プロジェクトのリードを行っており、お客様のクラウド移行を円滑に行えるよう熱心に取り組んでいます。コンピューターエンジニアリングの修士号をイリノイ大学で取得しています。仕事の合間には、旅行や様々な料理を体験することが趣味です。 Jean Schwerer Jean Schwerer は CloudWatch の Senior Product Manager です。技術を愛する元エンジニアで、技術製品の製品管理に 10 年以上の経験を積んでおり、お客様の使用事例やニーズに深く知ることを楽しんでいます。 本記事は、 Elevating Your AWS Observability: Unlocking the Power of Amazon CloudWatch Alarms を翻訳したものです。翻訳は テクニカルアカウントマネージャーの日平が担当しました。

本記事は 2024年4月3日に公開された ” Build a personalized student companion powered by generative AI on Amazon Bedrock ” を翻訳したものです。 学生の学習ニーズは多様で、教育者が利用できるリソースは限られているため、 個別学習 は現代の教育における差し迫った課題です。一対一での相談や仲間との学習グループといった従来の学習サポート方法では、カスタマイズされたガイダンスを提供したり、知識のギャップを埋めるには不十分であることがよくあります。さらに学習者それぞれが異なる長所、短所、学習スタイルを持つという本質的な多様性が、この課題をより複雑にしており、画一的なアプローチはますます時代遅れになっています。 この急速に進化する環境において、 生成 AI と 大規模言語モデル（LLM） の出現は、これらの長年にわたる教育上の課題に取り組むための変革の機会をもたらしています。膨大なデータセットに基づいてトレーニングを受けた LLM は、自然言語を理解し、意味を解釈し、文脈的に関連性のある人間らしい応答を生成できます。 Retrieval-Augmented Generation（RAG） は、応答を生成する前にトレーニングデータ以外の信頼できる知識ベースを参照することで、LLMの出力をさらに向上させます。 この記事では、パーソナライズされた学習サポートの課題に対応する、自分のペースで進められる学生コンパニオンの導入方法を説明します。学生のプロフィールと教育機関の学習コンテンツコーパスを組み合わせることで、生成 AI モデルを使用して学生体験をパーソナライズし、各学生固有の長所と短所に合わせた教育支援を提供します。コンテンツ生成のための LLM を呼び出すための Amazon Bedrock 、教育コンテンツを統合するための Knowledge Bases for Amazon Bedrock 、更新されていく学生の成績データストアとして Amazon Aurora Serverless など、AWS サーバーレステクノロジーを利用しています。このアプローチは、AIの力を利用して、学習者の多様なニーズとスキルセットに応える、パーソナライズされた適応性のある学習コンパニオンを作成します。 前提条件 この記事で説明したアプローチを実装するには、次のものが必要です。 コース教材やその他の教育リソースなど、教育機関の学習コンテンツコーパスを含む既存の Amazon Simple Storage Service (Amazon S3) バケット。 登録されたモジュールや成績などの学生登録データを保存するための、ユーザーアカウントにある Amazon Aurora データベースインスタンス。 学生の ID を管理し、アプリケーションへのアクセスを許可するように設定された ID プロバイダーサービス。たとえば、 Amazon Cognito を使用してユーザーの認証と認可を処理することはできますが、サービスの設定はこの記事では対象外です。 ソリューション概要 パーソナライズされた学習コンパニオンは、各学生の独自のプロフィールとスキルセットに適応する必要があります。次のシナリオを考えてみましょう。科学に熱心なエマと、特定の概念に苦労しているマイケルが同じコースに登録されています。エマは理解を深めるために高度な洞察と難しい質問が役立つでしょうが、マイケルは教材を補強するために簡単な説明と追加の例が必要です。パーソナライズされた学習コンパニオンは、それに応じてアプローチを調整し、両方の学生がそれぞれの強みと改善すべき分野に合わせてカスタマイズされたサポートを受けられるようにします。 このワークフローを実証するために、この記事では次の図に示すアーキテクチャの概要を説明します。 図1.パーソナライズされた学習コンパニオンのハイレベルアーキテクチャ。主なコンポーネントは、学習コンパニオンチャットボット、Amazon Bedrock、Amazon Aurora Serverless、Amazon OpenSearch Serverless、Amazon S3 バケットです。 ソリューションの手順 パーソナライズされた学生コンパニオンを構築するワークフローは、次の手順に従います。 アプリケーションは、教育機関のデータベースから、成績や登録モジュールを含む学生の記録を取得します。 アプリケーションは学生データをプロンプトと組み合わせ、LLMを呼び出してパーソナライズされた学生プロフィールを作成します。 プロンプト拡張プロセスでは、学生のプロフィールと入力質問を統合し、学生固有の強みや改善すべき分野に応じてモデルの出力を調整します。 アプリケーションは、教育機関の学習コンテンツコーパスを検索して、学生の入力問題に関連する資料を探します。 LLMは、関連する学習教材とカスタマイズされた学生プロフィールの両方を組み込んだ個別の回答を生成するために呼び出されます。 学生の個々のプロフィールとニーズに合わせてカスタマイズされた回答が学生に配信されます。 ステップ1 — 学生記録の取得 パーソナライズされた学生プロフィールを生成するには、学生の学業成績、成績、履修モジュールからの構造化データを分析する必要があります。このデータには通常、学生が教育機関での学習期間中に継続的に更新される取引情報が含まれます。LLM を呼び出してプロフィール生成を行う際にこのデータを効果的に利用するには、RAG を使用します。RAG により、LLM は学生記録データベースから関連情報を取得して組み込むことができるため、生成されたプロフィールが学生の現在の学業状況と学習要件を正確に反映できるようになります。 以下の簡単なデータベーススキームは、Amazon Aurora PostgreSQL 互換エディションをデータベースとして使用する場合のユースケースを示しています。 CREATE TABLE student ( /* Students table, including student Id and name */ id SERIAL PRIMARY KEY, name TEXT ); CREATE TABLE module ( /* Modules table, including module ID and label */ id SERIAL PRIMARY KEY, label TEXT ); CREATE TABLE enrollment ( /* Students’ enrolled modules and grades */ id SERIAL PRIMARY KEY, student_id INTEGER REFERENCES student(id), module_id INTEGER REFERENCES module(id), grade INTEGER ); 次のコードスニペットは、データベースから学生の成績を取得するのに役立ちます。 import psycopg2 def get_student_modules_and_grades(connection_string, student_id): modules_and_grades = [] conn = psycopg2.connect(connection_string) cursor = conn.cursor() query = """ SELECT module.label, enrollment.grade FROM module JOIN enrollment ON module.id = enrollment.module_id WHERE enrollment.student_id = %s """ cursor.execute(query, (student_id,)) for row in cursor: module = { "label": row[0], "grade": row[1] } modules_and_grades.append(module) conn.close() return modules_and_grades ステップ 2 — パーソナライズされた学生プロフィールを作成する 前のステップの出力に基づいて、アプリケーションはLLMを呼び出して学生プロフィールを生成します。次のコードスニペットは、Amazon Bedrock で利用可能になった新しい Claude 3 Sonnet モデルを使用したこのステップを示しています。 import boto3 import json PROFILE_PROMPT = """ You are a student companion chatbot tasked with generating a unique profile for a student based on their enrolled modules and grades. The profile should have three parts: Domain of Speciality: Based on the modules the student is enrolled in, identify their likely domain or field of speciality. Main Strengths: Based on the grades obtained, determine the student's main strengths or areas of academic excellence. Areas of Improvement: Based on the relatively lower grades, suggest areas where the student could potentially improve. Here are the modules the student is enrolled in and the grades they have obtained: {modules_and_grades} Generate a student profile with the three parts mentioned above, keeping in mind the input modules and grades. Assistant: """ def create_user_profile(connection_string, student_id): PROFILE_PROMPT = PROFILE_PROMPT.format( modules_and_grades = get_student_modules_and_grades( connection_string, student_id)) bedrock = boto3.client(service_name='bedrock-runtime') messages = [ { "role": "user", "content": [ { "type": "text", "text": PROFILE_PROMPT} ] } ] body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1000, "messages": messages }) response = bedrock.invoke_model( modelId="anthropic.claude-3-sonnet-20240229-v1:0", contentType='application/json', accept='application/json', body=body ) response_body = json.loads(response.get('body').read() return response_body このコードは、学生が登録したモジュールと成績に基づいて、学生の専門分野、長所、改善点という3つの部分に分かれてパーソナライズされた学生プロフィールを返します。 ステップ3 — 学生プロフィールを使用して学習教材をカスタマイズする 学生固有のプロフィールが生成されたら、プロンプトエンジニアリングを使用して学生の入力クエリをプロフィールデータで拡張することができます。これにより学生の学業上のニーズや強みに合わせたパーソナライズされた学習コンテンツを生成できます。これにより、LLM は学生のプロフィールを理解し、それに応じて回答を調整することができます。以下はプロンプトのテンプレートです。 AUGMENTED_PROMPT = """ You are a personalized student companion chatbot. Your task is to provide a detailed answer to the following question while tailoring the response based on the given student profile: Student Profile: {student_profile} Learning material: {learning_corpus} Question: {input_question} When generating the answer, keep the following in mind: - Adjust the level of complexity and depth based on the student's strengths and areas of improvement identified in the profile. - Provide examples and explanations that align with the student's domain of specialty. - Offer suggestions or additional resources to help the student improve in areas where they may be struggling. Your personalized answer: """ ステップ 4 — 教育機関の学習コーパスからコンテンツを取得する 学生の意見に関連するコンテンツを取得するには、Amazon Bedrock でナレッジベースを作成し、教育機関の学習コンテンツコーパスをアップロードする必要があります。Knowledge Bases for Amazon Bedrock を作成する手順については、「 ナレッジベースを作成する 」を参照してください。その後、Bedrock retrieve API を使用してナレッジベースをクエリし、学生が入力した質問に関連する関連資料を取得できます。このステップを実装するコードスニペットは、LLMを呼び出すコードとともにステップ5に示されています。 ステップ 5 — LLM を呼び出してパーソナライズされたコンテンツを生成する 学生プロフィール、質問内容、およびナレッジベースから取得した関連資料が揃ったら、LLMを使用して、学生固有のニーズと強みに合わせた個別の回答を生成できます。まず、手順 3 の拡張プロンプトテンプレートを使用して、学生プロフィール、取得した学習教材、学生が入力した質問を 1 つのプロンプトに集約して、拡張プロンプトを作成します。次に、拡張されたプロンプトを使用して Amazon Bedrock API を通じて LLM を呼び出し、パーソナライズされたレスポンスを生成します。 次のコードスニペットは、このプロセスを示しています。 def question_answering_and_generation(kb_id, profile, question, prompt): # Retrieving contextual learning material from Bedrock Knowledge Base kb_client=boto3.client(service_name='bedrock-agent-runtime') response = knowledge_client.retrieve( knowledgeBaseId=kb_id,retrievalQuery={ 'text': question }) answer = response['retrievalResults'][0]['content'] # Augmenting the prompt for LLM invocation full_prompt = prompt.format( student_profile=profile, learning_corpus= answer, input_question=question) runtime_client = boto3.client('bedrock-runtime') messages = [ { "role": "user", "content": [ { "type": "text", "text": full_prompt } ] } ] body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 300, "messages": messages }) # Invoke Claude with the agumented prompt response = runtime_client.invoke_model( modelId="anthropic.claude-3-sonnet-20240229-v1:0", contentType='application/json', body=body #body=json.dumps({ "prompt": full_prompt }) ) # Return the generated response return json.loads(response.get('body').read()) 最後に、ステップ6でパーソナライズされた回答を学生に返します。 例 ソリューションを説明するために、この記事で前述したエマとマイケルの例を使用します。エマとマイケルの両方が数学のモジュールに在籍していて、ピタゴラスの定理について学んだ幾何学の授業に出席したばかりだとしましょう。エマの成績によると、彼女は自然科学と数学に堪能ですが、美術と外国語はまだ上達できます。反対に、マイケルは美術と文学には優れていますが、数学と応用科学には多少の困難があります。2人とも授業で見たピタゴラスの定理をよりよく理解するために、学生用コンパニオンチャットボットを使用します。 次のスクリーンショットでは、エマの見解とマイケルの学習中の学生コンパニオンに対する見解を示しています。 最初のスクリーンショットは、パーソナライズされた学生コンパニオンとのエマの体験を示しています。 図 2.ピタゴラスの定理に関するエマの質問に対する個別の回答。 スクリーンショットの最初の部分は、学習コンパニオンアプリケーションが、ステップ 2 でデータベースから抽出された現在の成績に基づいてエマの学生プロフィールをどのように更新したかを示しています。2つ目の部分では、このパーソナライズされたプロフィールと、教育機関の学習コーパスのコンテンツを使用して、数学と科学の豊富なバックグラウンドに基づいて回答をパーソナライズしました。 次のスクリーンショットは、パーソナライズされた学生コンパニオンとのマイケルの体験を示しています。マイケルの個人的な対応は、彼の美術の強みを活かした視覚的なアプローチをとることで、数学を改善したいという彼のニーズに応えています。 図 3.ピタゴラスの定理に関するマイケルの質問に対する個別の回答。 この例は、同じ入力クエリの結果が、各学生の固有の長所、短所、専門分野に合わせてカスタマイズされた個別の応答を生成する方法を示しています 結論 この記事では、生成 AI を使用して、学生固有のプロフィールとニーズに合わせてパーソナライズされた学習コンテンツを提供するソリューションについて説明しました。Amazon Bedrock を使用して大規模言語モデルを呼び出し、Amazon Aurora Serverless や Amazon Bedrock ナレッジベースなどの AWS サーバーレスサービスと統合することで、各学生の長所、短所、専門分野に基づいてカスタマイズされた説明を生成する適応型システムを構築しました。これにより、教育機関は自分のペースで AI 駆動型学習支援を大規模に提供できるようになり、多様な学習要件や限られた教育者リソースの課題に取り組むことができます。数学の授業の簡単な例で説明しましたが、ここで概説した原則は、分野や学習環境を超えて適用できます。全体として、この記事では、AWS の包括的な AI およびサーバーレスサービスを活用して、Amazon Bedrock で利用できる生成 AI の強力な機能を通じて、どのように個別教育を変革できるかを紹介しました。 さらに詳しく: 教育と学習の経験を改善するための生成AIアプリケーションを開発する。 AWS Behind the Cloud ポッドキャストの第 5 話 を視聴、生成 AI が世界の教育分野にどのような影響を与えているかについて詳しく学んでください。 誰にとってもいつでも利用可能で、個別化され、生涯にわたる 教育に AWS がどのように役立つか の詳細をご覧ください 高等教育におけるイノベーションの推進要因と、 AWS が高等教育機関のイノベーションにどのように役立つか について詳しく学んでください。 Nizar Kheir Nizar は Amazon Web Services (AWS) のシニアソリューションアーキテクトで、様々な業界にわたって15年以上活躍してきました。現在はフランスおよび EMEA に及ぶパブリックセクターの顧客と連携し、IT インフラストラクチャのモダナイズや AWS Cloud を活用したイノベーションの促進を支援しています。 本ブログはソリューションアーキテクトの田村健祐が翻訳しました。原文は こちら です。

8月19日より、 AWS CodeBuild を利用して macOS でアプリケーションを構築できます。 macOS 14 Sonoma で実行されるマネージド Apple M2 マシンでアーティファクトを構築できるようになりました。AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、すぐにデプロイできるソフトウェアパッケージを作成する、フルマネージド継続的インテグレーションサービスです。 Apple のシステム ( iOS 、 iPadOS 、 watchOS 、 tvOS 、および macOS ) 向けのアプリケーションの構築、テスト、署名、および配布には、macOS でのみ実行される Xcode を使用する必要があります。AWS クラウドで Apple のシステム向けに構築するユーザーは、継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインを Amazon Elastic Cloud Compute (Amazon EC2) Mac インスタンス で実行するように設定している可能性が高いです。 2020 年に Amazon EC2 Mac をリリースして以来 、私はさまざまな業界や地域の お客様とかなりの時間 を過ごし、macOS でのパイプラインの設定と最適化をサポートしてきました。最も単純な形式では、お客様のパイプラインは次の図のようになります。 パイプラインは、ソースコードリポジトリに新しいコミットまたはプルリクエストがある場合に開始されます。マシンにインストールされたリポジトリエージェントは、さまざまなスクリプトをトリガーして環境を設定し、アプリケーションを構築およびテストして、最終的に App Store Connect にデプロイします。 Amazon EC2 Mac は、macOS マシンの管理とオートメーションを大幅に簡素化します。私はよく申し上げるのですが、EC2 Mac インスタンスには、Amazon EC2 で私が好んで使用している機能 ( Amazon Elastic Block Store (Amazon EBS) ボリューム、スナップショット、仮想プライベートクラウド (VPC)、セキュリティグループなど) がすべて備わっており、クラウドで macOS を実行している Mac mini に適用されます。 ただし、お客様には 2 つの課題があります。1 つ目は、ビルドに必要なすべてのツールを備えた Amazon マシンイメージ (AMI) を準備することです。最小限のビルド環境には Xcode が必要ですが、 Fastlane (および Ruby ) や他のビルドまたは開発ツールとライブラリをインストールするのが一般的です。ほとんどの組織では、macOS と Xcode バージョンの複数の組み合わせに対応するために、複数のビルド環境が必要です。 2 つ目の課題は、ビルドの数と期間に応じて、ビルドフリートをスケールすることです。大規模な組織では通常、1 日あたり数百または数千のビルドがあり、数十台のビルドマシンが必要になります。そのフリートのスケールインとスケールアウトは、コスト削減に役立ちます。EC2 Mac インスタンスは、専用予約されています。1 つのインスタンスは 1 つの専有ホストに割り当てられます。 専有ホストのフリートをスケール するには、特定の設定が必要です。 これらの課題に対処し、macOS ビルドマシンの設定と管理を簡素化するために、本日は CodeBuild for macOS をご紹介します。 CodeBuild for macOS は、最近リリースされた リザーブドキャパシティフリート をベースとしています。これには、CodeBuild によって管理される、Amazon EC2 を利用するインスタンスが含まれます。リザーブドキャパシティフリートでは、ビルド環境用に一連のハードウェア専有インスタンスを設定します。これらのマシンはアイドル状態のままとなり、ビルドまたはテストをすぐに処理できる状態であるため、ビルド時間が短縮されます。リザーブドキャパシティフリートでは、マシンは常に実行されており、プロビジョニングされている限りコストが発生し続けます。 CodeBuild は、ビルドを実行するための標準ディスクイメージ (AMI) を提供します。これには、開発およびビルド環境用の Xcode、Fastlane、Ruby、Python、Node.js、および他の一般的なツールのプリインストールバージョンが含まれています。 インストールされているツールの詳細なリスト は、ドキュメントでご覧いただけます。今後、これらのツールの更新バージョンを含む追加のディスクイメージを提供する予定です。必要に応じて、独自のカスタムディスクイメージを使用することもできます。 さらに、CodeBuild を利用すると、自動スケーリングを簡単に設定できます。必要なキャパシティをお知らせいただければ、当社がそこからすべてを管理します。 CodeBuild for macOS の動作を見てみましょう どのように機能するかを示すために、iOS で AWS Amplify の利用を開始するという私のお気に入りのプロジェクト用に CI/CD パイプラインを作成します。このチュートリアルと、それに付随するソースコードは、クラウドベースのバックエンドを備えたシンプルな iOS アプリケーションを作成する方法について説明するためのものです。アプリケーションは、GraphQL API ( AWS AppSync )、NoSQL データベース ( Amazon DynamoDB )、ファイルベースのストレージ ( Amazon Simple Storage Service (Amazon S3) )、およびユーザー認証 ( Amazon Cognito ) を利用します。 AWS Amplify for Swift は、これらすべてのサービスを結び付けます。 チュートリアルと、アプリケーションのソースコードは、Git リポジトリで入手できます 。これには、 アプリケーションのビルド、テスト、およびデプロイを自動化するスクリプト が含まれています。 CodeBuild for macOS を利用して新しい CI/CD パイプラインを設定するには、大まかには次のステップを実行します: ビルドプロジェクトを作成します。 マシンの専有フリートを作成します。 1 個以上のビルドトリガーを設定します。 パイプライン定義ファイル ( buildspec.yaml ) をプロジェクトに追加します。 開始するには、 AWS マネジメントコンソール を開き、CodeBuild を選択して、 [プロジェクトを作成] を選択します。 [プロジェクト名] を入力し、 [ソース] コードリポジトリへの接続を設定します。この例では GitHub を使用します。CodeBuild は GitLab と BitBucket もサポートしています。ドキュメントでは、 サポートされているソースコードリポジトリ の最新リストをご覧いただけます。 [プロビジョニングモデル] で、 [リザーブドキャパシティ] を選択します。これは、Amazon EC2 Mac インスタンスを使用できる唯一のモデルです。まだフリートを定義していないため、ビルドプロジェクトの作成中に作成することにしました。 [フリートを作成] を選択します。 [コンピューティングフリートの設定] ページで、 [コンピューティングフリート名] を入力し、オペレーティングシステムとして [macOS] を選択します。 [コンピューティング] で、ビルドプロジェクトに必要なメモリの量と vCPU の数を選択し、 [キャパシティ] で必要なインスタンスの数を選択します。 この例では、 [マネージドイメージ] を使用します。これには、Xcode 15.4 と、iOS 17.5 のシミュレーターランタイムなどのパッケージが含まれています。ドキュメントで、 このイメージにプリインストールされているパッケージのリスト をご覧いただけます。 完了したら、 [フリートを作成] を選択して、CodeBuild プロジェクトの作成ページに戻ります。 次のステップとして、新しいサービスロールを作成して、ビルド環境に必要な許可を定義するよう CodeBuild に指示します。このプロジェクトのコンテキストでは、Amplify の設定をプルして AWS Secrets Manager にアクセスするための許可を含める必要があります。これを実行するためのステップバイステップの指示はここには記載しませんが、 サンプルプロジェクトコードには私が追加した許可のリストが含まれています 。 ビルドコマンドのセットをプロジェクト定義で提供するか、またはプロジェクトに含まれる buildspec.yaml ファイルで提供するかを選択できます。私は後者を選択します。 これはオプションですが、ビルドアーティファクトを S3 バケットにアップロードしたいと思います。S3 バケットでは、各ビルドをアーカイブできます。したがって、 [アーティファクト 1 – プライマリ] セクションで、 [タイプ] として [Amazon S3] を選択し、 [バケット名] とアーティファクトの [名前] を入力します。アップロードするファイル名は、 buildspec.yaml ファイルで指定されます。 ページの下部で、GitHub WebHook を追加するプロジェクトトリガーを設定します。これにより、GitHub 上のプロジェクトにコミットまたはプルリクエストが送信されるたびに CodeBuild がビルドを開始するように設定されます。 最後に、ページの下部にあるオレンジ色の [プロジェクトを作成] ボタンを選択して、このプロジェクトを作成します。 ビルドのテスト プロジェクトには、ビルドの準備、プロジェクトの構築、テストの実行、 Apple の TestFlight へのデプロイを行うためのビルドスクリプトが既に含まれています。 プロジェクトのルートに buildspec.yaml ファイルを追加して、これらの既存のスクリプトをオーケストレートします。 version: 0.2 phases: install: commands: - code/ci_actions/00_install_rosetta.sh pre_build: commands: - code/ci_actions/01_keychain.sh - code/ci_actions/02_amplify.sh build: commands: - code/ci_actions/03_build.sh - code/ci_actions/04_local_tests.sh post_build: commands: - code/ci_actions/06_deploy_testflight.sh - code/ci_actions/07_cleanup.sh artifacts: name: $(date +%Y-%m-%d)-getting-started.ipa   files: - 'getting started.ipa' base-directory: 'code/build-release' このファイルを Git リポジトリに追加し、次のコマンドで GitHub にプッシュします: git commit -am "add buildpsec" buildpec.yaml コンソールで、ビルドが開始されたことを確認できます。 ビルドを選択すると、ログファイルを表示したり、 [フェーズの詳細] を選択してビルドの各フェーズの高レベルのステータスを確認したりできます。 ビルドが成功すると、iOS アプリケーションの IPA ファイルが S3 バケットにアップロードされているのを確認できます。 CodeBuild が実行する最後のビルドスクリプトは、バイナリを App Store Connect にアップロードします。App Store Connect の TestFlight セクションで新しいビルドを確認できます。 知っておくべきこと Amazon EC2 Mac インスタンスを準備して最初のビルドを受け入れるまでに、8～10 分 かかります。これは CodeBuild に固有の事象ではありません。マシンの準備時間中に送信するビルドはキューに入れられ、マシンが使用可能になり次第、順番に実行されます。 CodeBuild for macOS はリザーブドフリートで動作します。ビルドの 1 分ごとに料金が発生するオンデマンドフリートとは異なり、リザーブドフリートは、ビルドが実行されていない場合でも、ビルドマシンがお客様専用に予約されている時間について課金されます。キャパシティ予約は、 Software License Agreement for macOS (第 3.A.ii 条) が定めるとおり、Amazon EC2 Mac の 24 時間の最小割り当て期間に従います。 マシンのフリートは、AWS アカウントの CodeBuild プロジェクト間で共有できます。フリート内のマシンは、お客様専用に予約されています。CodeBuild だけがマシンにアクセスできます。 CodeBuild はビルド間で作業ディレクトリをクリーンアップしますが、マシンは他のビルドに再利用されます。これにより、 CodeBuild ローカルキャッシュメカニズム を使用して、ビルド後に選択したファイルを迅速に復元できます。同じフリートで異なるプロジェクトを構築する場合は、新しいビルドを開始する前に、 macOS キーチェーン などのグローバル状態と、 SwiftPM および Xcode パッケージキャッシュ などのビルドアーティファクトを必ずリセットしてください。 カスタムビルドイメージを使用する場合は、それらが 64 ビット Mac-Arm アーキテクチャ用にビルドされているようにしてください。また、 AWS Systems Manager Agent (SSM Agent) をインストールして起動する必要があります。CodeBuild は、 SSM Agent を利用して独自のエージェントをインストールし、マシンを管理します。最後に、AMI が CodeBuild 組織 ARN で使用できることを確認します。 CodeBuild for macOS は、次の AWS リージョン でご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト)。これらは、Amazon EC2 Mac M2 インスタンスを提供しているリージョンと同じです。 今すぐ使用を開始して、 macOS で最初の CodeBuild プロジェクトを作成 しましょう。 — seb 原文は こちら です。

2023年 3 月、 Jeff Barr は マレーシアの AWS リージョン の計画を発表しました。8月19日、3 つのアベイラビリティーゾーンと API 名「ap-southeast-5」を備えた AWS アジアパシフィック (マレーシア) リージョンの一般提供についてお知らせできることを嬉しく思います。 AWS アジアパシフィック (マレーシア) リージョンは、マレーシア初のインフラストラクチャリージョンであり、アジアパシフィックでは香港、ハイデラバード、ジャカルタ、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京の既存のアジアパシフィックリージョンと、中国本土の北京および寧夏リージョンに加わる 13 番目のリージョンです。 クアラルンプールのオフィス街中心部にあるペトロナスツインタワー。 マレーシアの新しい AWS リージョンは、マレーシア政府による戦略的 マダニ経済政策 (Madani Economy Framework) を支援する上で極めて重要な役割を果たします。このイニシアチブは、2030 年までにすべてのマレーシア国民の生活水準を向上させるとともに、マレーシアおよび ASEAN 全体のイノベーションを支援することを目的としています。新しい AWS リージョンの構築と運用により、マレーシアの国内総生産 (GDP ) は約 121 億 ドル (573 億 MYR) 増加すると推定され、2038 年までに外部企業にて毎年平均 3,500 件以上のフルタイム相当の雇用が生まれるとされています。 マレーシアの AWS リージョンは、クラウドサービスに対する高い需要に応えながら、マレーシアおよび東南アジア全体のイノベーションをサポートするのに役立ちます。 マレーシアでの AWS 2016 年、Amazon Web Services (AWS) はマレーシア初の AWS オフィスを開設しました。それ以降、AWS はマレーシアのデジタルトランスフォーメーションを促進するために、インフラストラクチャとテクノロジーに継続的に投資し、毎月何十万ものアクティブなお客様をサポートしてきました。 Amazon CloudFront – 2017 年、AWS はマレーシア初のエッジロケーションの立ち上げを発表しました。これにより、エンドユーザーのパフォーマンスと可用性が向上しました。現在、マレーシアには 4 つの Amazon CloudFront ロケーションが存在します。 AWS Direct Connect – マレーシアのお客様のアプリケーションパフォーマンスの向上、データの保護、ネットワークコストの削減を引き続き支援するため、AWS は 2017 年、マレーシアに Direct Connect ロケーションを追加開設することを発表しました。現在、マレーシアには 2 つの AWS Direct Connect ロケーションがあります。 AWS Outposts – AWS インフラストラクチャと AWS サービスを拡張する完全マネージド型サービスである AWS Outposts は、低レイテンシー要件を満たすためにオンプレミスで実行する必要があるアプリケーションに最適です。2020 年以降、マレーシアのお客様は AWS Outposts を注文して、データセンターやオンプレミスのロケーションにインストールできるようになりました。 マレーシアの AWS のお客様 マレーシアでのクラウドの採用は、近年着実に勢いを増しています。マレーシアの AWS のお客様の例と、さまざまなワークロードで AWS がどのように使用されているかを次に示します。 PayNet – PayNet はマレーシアの全国決済ネットワークであり、マレーシアの金融市場向けの共通中心インフラストラクチャです。PayNet は AWS を使用して、MyDebit オンラインキャッシュレス決済システムや電子決済レポートなど、全国の重要な決済ワークロードを実行しています。 Pos Malaysia Berhad (Pos Malaysia) – Pos Malaysia は全国郵便および宅配サービスプロバイダーであり、マレーシアの全国郵便サービス義務に基づくサービスを提供する権限を持つ唯一の組織です。重要なアプリケーションを AWS に移行したことで、Pos Malaysia のビジネスの俊敏性が向上し、カスタマーエクスペリエンスの向上にもつながりました。また、 Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) を使用して、1,100 万を超える住所と 3,500 を超える小売タッチポイントのネットワークへの配送を処理できるようにコンピューティング能力を拡張し、サービスが中断されないようにしています。 Deriv – 世界最大のオンラインブローカーの 1 つである Deriv は、 Amazon Q Business を使用して、カスタマーサポート、マーケティング、採用部門にわたる業務の生産性、効率性、イノベーションを向上させています。Deriv は Amazon Q Business を活用することで生産性を向上し、オンボーディングにかかる時間の 45% 短縮を実現しました。 アジアパシフィック大学 – マレーシアを代表する工業大学の 1 つであるアジアパシフィック大学 (APU) は、Lambda などの AWS のサーバーレステクノロジーを使用して運用コストを削減しています。AWS サービスの自動スケーラビリティ機能により、高可用性と迅速なデプロイが実現され、学生やスタッフがいつでも APU のアプリケーションとサービスにアクセスできるようになり、全体的なユーザーエクスペリエンスが向上しました。 Aerodyne – Aerodyne Group は、ドローンベースのエンタープライズソリューションを提供する DT3 (ドローンテック、データテック、デジタルトランスフォーメーション) ソリューションプロバイダーです。世界中のドローン事業者の事業拡大を支援するために、AWS で DRONOS Software as a Service (SaaS) プラットフォームを実行しています。 ともにクラウドスキルを構築 AWS とマレーシアのさまざまな組織は、必要とされるクラウドスキルをマレーシアのビルダーが身に付けられるように、密接に連携してきました。取り組みの一部をご紹介します。 AWS re/Start による Program AKAR – Program AKAR は、AWS と PayNet によって開始された最初の金融サービス連携クラウドスキルプログラムです 。この新しいプログラムは、この分野でのキャリアに必要とされる応用可能なスキルを学生に習得させ、マレーシアのデジタル経済におけるスキルギャップの拡大を埋めることを目的としています。最初のコラボレーションの一環として、PayNet、AWS re/Start、WEPS は、2024 年に 100 人の学生を対象にプログラムを開始することを約束しました。まず、アジアパシフィック大学の 50 人の学生がパイロットとして参加します。 AWS Academy – AWS Academy は、無料ですぐに学習できるクラウドコンピューティングカリキュラムを学生に提供し、業界で認められた認定資格やクラウドでのキャリアに備えさせることで、産業界と学界のギャップを埋めることを目的としています。AWS Academy は現在、マレーシアの 48 の大学でさまざまな分野のコースを運営しています。2018 年以降、23,000 人の学生がこのプログラムを通じてトレーニングを受けています。 PETRONAS の AWS Skills Guild – PETRONAS は 50 か国以上に拠点を置くグローバルなエネルギーおよびソリューションプロバイダーで、2014 年以来 AWS を使用しています。また、AWS は PETRONAS と協力し、AWS Skills Guild プログラムを使用して従業員をトレーニングしています。 マレーシアの持続可能性に対する AWS の貢献 Amazon は「 気候変動対策に関する誓約 」(The Climate Pledge) により、2040 年までに事業全体で二酸化炭素排出量をネットゼロにすることにコミットしており、2025 年までに事業運営に必要な電力を 100% 再生可能エネルギーで賄えるように取り組みを進めています。 2023 年 9 月、AWS は世界のエネルギー転換における持続可能性と脱炭素化の取り組みを加速させるために、世界的なクリーンエネルギー企業である Petronas および Gentari との 連携を発表 しました。そのすぐ後の 2023 年 12 月、AWS の顧客である PKT Logistics Group は、世界におけるネットゼロカーボン達成への道のりを加速させるために、300 社を超えるグローバル企業と連携し、「The Climate Pledge (気候変動対策に関する誓約)」に参加した 最初のマレーシア企業 となりました。 2024 年 7 月、AWS と Zero Waste Management は共同で史上初の AWS InCommunities Malaysia イニシアチブである Green Wira Programme に取り組みました。このプログラムは、マレーシアの持続可能な未来を実現するために、学校で持続可能性に関する取り組みを行う教育者を養成するものです。 Amazon は、より持続可能な未来を創造するために、事業全体にわたって投資およびイノベーションに取り組んでいます。 知っておくべきこと マレーシアの AWS コミュニティ – マレーシアには、1 人の AWS ヒーロー、9 人の AWS コミュニティビルダー、そしてマレーシアのさまざまな都市にある 3 つの AWS ユーザーグループに所属する約 9,000 人のコミュニティメンバーが存在します。マレーシアの AWS ユーザーグループへの参加に興味がある場合は、 Meetup と Facebook のページにアクセスしてください。 AWS のグローバルフットプリント – この立ち上げに伴い、AWS の事業活動の場は、世界各地の 34 の地理的リージョンにおける 108 のアベイラビリティーゾーンに広がりました。また、メキシコ、ニュージーランド、サウジアラビア王国、台湾、タイ、および AWS European Sovereign Cloud に 18 のアベイラビリティーゾーンと 6 つの AWS リージョンを追加する計画も発表されました。 今すぐ利用可能 – 新しいアジアパシフィック (マレーシア) リージョンでは、お客様のビジネスをサポートする準備が整いました。このリージョンで利用できるサービスの詳細なリストは、「 リージョン別の AWS サービス 」ページに記載されています。 詳細については、「 AWS グローバルインフラストラクチャ 」のページにアクセスしてください。そして、 ap-southeast-5 で構築を開始しましょう。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

こんにちは。 AWS パブリックセクター技術統括本部の松本です。 2023 年 6 月、 自治体のお客様向け「ガバメントクラウド利用タスクリスト」を公開します というブログで、RFP/RFI にお役立ていただける作業内容一覧 (タスクリスト) を公開しました。 その後、GCAS (Government Cloud Assistant Service) の機能整備が進んだり、 地方公共団体情報システムのガバメントクラウドの利用について 【第 2.1 版】 や「ガバメントクラウド利用における推奨構成（AWS 編）」が一般公開されたりと、ガバメントクラウドの利用について様々なアップデートありました。 状況の変化に合わせタスクリストについて内容を更新したため、自治体においては調達仕様の策定、事業者においては事業者間の役割分担の明確化にご利用ください。 本ブログでは、2024 年版 タスクリストの概要と利用方法について解説します。 タスクリストの全体構成 2024 年版 タスクリストは 6 つのシートから構成されています。 以下の表でそれぞれのシートの概要を解説します。 シート名 概要 免責事項 本タスクリストを利用する上での注意点や免責事項が記載してあります。 テンプレート タスクリストのテンプレートです。本シートをコピーしてご利用ください。 単独利用方式中心の構成例 政令市に多い、単独利用方式を中心にガバメントクラウド環境を構成する場合のアーキテクチャを示しています。 単独利用方式中心の役割分担例 単独利用方式中心の場合について、テンプレートのシートを埋めた例を示しています。 共同利用方式中心の構成例 小-中規模自治体に多い、共同利用方式を中心にガバメントクラウド環境を構成する場合のアーキテクチャを示しています。 共同利用方式中心の役割分担例 共同利用方式中心の場合について、テンプレートのシートを埋めた例を示しています。 タスクリストの概要 大きくはタスクリストのテンプレートと、2 つの構成例 (単独利用方式中心/共同利用方式中心)の場合にタスクリストをどのように埋めていけばいいかについて記載した Excel ファイルとなっています。 例えば、タスクリストのテンプレートは以下の図のように大きく「タスクの分類・概要」が記載してある列と「関係する事業者名」を記載する列で構成されています。 構成例・役割分担例については以下の構成図をもとに「単独利用方式中心の例」と「共同利用方式中心の例」について記載しています。 構成例・役割分担例はあくまでサンプルですので、自治体ごとに最適な構成・役割分担をご採用ください。 各項目の概要や先行事例、ガバメントクラウドにおける事業者の役割定義について知りたい方は、 AWS Summit Japan 2024 の セッション「先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくこと」 をご視聴ください。 テンプレートの使い方 ① 構成図を書いてみる 構成図を書く際のポイント まず、ガバメントクラウド全体の構成を把握するために概要でいいので構成図を記載します。 構成図を記載するためのアイコン等は AWS アーキテクチャアイコン でダウンロードできます。 役割分担を明確にする目的で構成図を書く際のポイントについて以下にまとめましたので、ご参考ください。 ② 関係する事業者名を記載する 「2. テンプレート」シートをコピーし、事業者名をガバメントクラウド環境に関連する事業者名へ変更します。 可能であれば、「回線運用管理補助者」や「統合運用管理補助者」等、 地方公共団体情報システムのガバメントクラウドの利用について 【第 2.1 版】 に記載されている役割定義、利用方式についても併記します。 ③ 各タスクの担当事業者を決める 次に、各タスクを事業者へ割り振っていきます。各行について ◯ がつくようにしますが、タスクによっては複数の事業者が関係します。 その場合はテキストで各事業者が何を実施するのか補足を記載します。 タスクの担当を整理する中で「① 構成図を書いてみる」で作成した構成図に記載が漏れていた AWS サービスなどがあれば追記していきます。 完成した構成図と役割分担表を調達の際のドキュメントにお役立ていただいたり、事業者へ共有し委託作業範囲の明確化にご利用ください。 以上が 2024 年版 タスクリストの使い方でした。 ダウンロード タスクリストは以下リンクよりダウンロード可能です。 ガバメントクラウド事業者タスクリストのダウンロードはこちら まとめ この記事では 2024 年版 タスクリストの概要と利用方法についてお伝えしました。 自治体ごとに既存環境や各事業者の役割分担は異なり、整理に苦労されている方も多いと思います。 このタスクリストを事業者間の役割分担を明確化や調達の際のドキュメント作成にぜひご活用ください。 免責事項 タスクリストの情報はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本タスクリストはあくまで一例であり、全ての作業内容を充足するものではありません。 本タスクリストはガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本タスクリストの利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承の上、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けております。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

はじめに 2024 年 6 月 20 日、21 日に AWS Summit Japan を開催し、“あなたのアイデアをその場でアプリ化！生成 AI プレイグラウンド PartyRock” というタイトルでブースの展示を行いました。当日は、絶えずたくさんの来場者の方々にブースにお越しいただき、PartyRock でのアプリケーション作成を体験してもらうことができました。 本ブログでは、ブース展示のサポーターとして参加した新入社員の九曜と山本が、当日の様子や来場者の皆様から頂いた声を通し、PartyRock の魅力についてより皆さんにご紹介いたします。 PartyRock とは PartyRock とは、“誰でも生成 AI のアプリケーションを作成でき、実験を通して学べる教育ツール” です。メールのドラフトを作成したり、アイデアについて意見を求めたり、ちょっとした資料に使うイラストを作成したりなど、生成 AI は様々な用途で利用され始めています。PartyRock は、様々なユースケースをコーディング一切不要でアプリケーション化できる、AWS アカウント不要の Amazon Bedrock の生成 AI プレイグラウンドです。こんなアプリケーションが欲しいな…を言語化するだけで誰でも簡単にアプリケーションを作成することができます。また、自分で作成したアプリケーションを他の利用者にシェアすることも可能です。 そんな PartyRock の良さを、より多くの人に知ってもらいたい！という気持ちから、今回のブースの展示が企画されました。 また、PartyRock に関しましては、 PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス | Amazon Web Services ブログ にてより詳しく説明しています。 ブース紹介 今回の AWS Summit Japan 2024 PartyRock ブースでは、PartyRock をきっかけに、AWS での 生成 AI の可能性を来場者の方々に体験してもらおう！というテーマで展示制作を行いました。 当日は、AWS Summit Village にて PartyRock ブースを展示し、来場者の方々にあらかじめ用意したアプリケーション体験してもらったり、アイデアをその場でアプリケーション化していただきました。 あらかじめ用意したアプリケーションは、 AWS Summit Japan 2024 で紹介したサンプルアプリ集 誰でも簡単に生成 AI を活用！ AWS Japan メンバーが作った PartyRock アプリ集 | Amazon Web Servic… にてより詳しくご覧いただけます。 実際の様子 当日は絶えずたくさんの来場者の方々にブースにお越しいただきました。著者たちも当日ブースを対応しました。そこで特に人気だった PartyRock のアプリケーションをご紹介させていただきます。 人気だった PartyRock のアプリケーションのご紹介 難しいドキュメントも博士と太郎くんが何でも解説アプリ こちらのアプリケーションは、ドキュメントのファイルをアップロードし、“難しいドキュメントでも、博士と太郎くんが会話しながらわかりやすく解説してくれる” というものです。それぞれ博士と太郎くんの言葉遣いなども細かく再現されており、難しいドキュメントの内容がスラスラと読める便利アプリケーションです。博士と太郎くんイメージ画像も 生成 AI を用いて作成されます。 お客様からは「会話形式で解説してくれるのは面白い。」「博士の口調が『〜じゃ。』のようになっていて親しみやすい。」というように会話形式のスタイルに好印象を持った感想や、「わからない部分も追加で聞くと博士が答えてくれるので便利。」「会社のドキュメントを使って似たようなことができると良い。」といった利便性を評価した感想もいただきました。 新サービス企画支援アプリ こちらのアプリケーションは、サービス名と概要を入力するだけで、Amazon 流の新サービス検討プロセス「Working Backwards」に従って、新サービスの「プレスリリース」をドラフトします。サービス名と概要のインプットからアイデアを膨らまし、簡単に Amazon 風のサービス紹介、サービスイメージ画像を生成します。 お客様からは「一つの入力だけで、画像やテキストなどの様々なフォームの出力がチェーン状に繋げられて面白い」「出力結果を元にさらに詳しい内容をチャットで聞けるのはのはすごい」などの声をいただきました。 ブース全体を通して、ご来場いただいた方からは、 「AWS アカウント不要で使えるのは素晴らしい。」 「エンジニアでなくても簡単にアプリが作れる。IT を身近にするための良いサービス。ハッカソンに活用できそう。」 といったように、アプリに触れて PartyRock の良さを実感したコメントを多くいただきました。 PartyRock ブース展示中の様子 （新入社員でデザイン・発注を担当した PartyRock オリジナルグッズ）1/2 & PartyRock ブース展示中の様子 2/2 PartyRock から始まる、生成 AI 業務活用の可能性！ チャットボットや画像生成など、個人として生成 AI を利用している方は多いかもしれませんが、仕事や会社で活用を進めているという方はまだ比較的少ないのではないでしょうか？ AWS では、これまでに 100 以上の本番環境での生成 AI 活用を支援してきました。業種業界を問わず、早期に生成 AI 活用を実現しビジネス成果を上げたお客様には 3 つの共通点があります。 1 つ目は、生成 AI 活用プロジェクトに最大 4 人の少人数で取り組んでいること、2 つ目は、3 ヶ月以内というスピーディー企画・開発期間で本番導入に至っていること、そして 3 つ目は、システムを定量的に評価していることです。 これらの共通点は、AWS Japan のあらゆるお客様の生成 AI 活用を継続的に支援してきた経験から見えてきたものです。AWS Japan は 2023 年に AWS LLM 開発支援プログラムを提供し、基盤モデル開発を行う国内企業 17 社に技術支援を提供しました。2024 年には生成 AI 実用化推進プログラムを発表し、生成 AI の活用によってビジネス課題の解決にチャレンジする企業・団体に、包括的な支援を提供しています。 このセクションでは、PartyRock で触れていただいた AI の可能性を、実際に業務活用するための道筋をご紹介します。 AWS を用いた生成 AI 業務活用への道のり Phase 1：生成 AI 活用の計画を探索 生成 AI 業務活用への第一歩は、活用アイデアを探索することから始まります。ビジネスでの業務活用にあたり、まず「生成 AI でどのようなものが作れるのか」「それをどのように業務に活かすことができるのか」というアイデアを膨らませることが大切です。 そこで役に立つサービスが、今回 Summit でご紹介した PartyRock です。 PartyRock ホームページ画像 PartyRock で業務活用のアイデアを膨らませた次のステップでは、生成 AI に対する理解を深め、展開のためのアクションプランを立てていきます。 生成 AI を用いたシステムを導入するにあたり、社内で多くの人々が関係者となります。IT 知識の有無に関わらず、「導入を検討しているシステムがどのようなものなのか」「生成 AI でどのような効果が得られるのか」など、AI リテラシーを高めると共に、組織全体で計画を立てていくことが必要になってきます。 このような具体的なアクションプランを練る一つの方法は、AWS の提供する ML Enablement Workshop  （MLEW） の実施です。 MLEW は、生成 AI を含めた AI/ML 技術を自社ビジネスに適用し、成長につなげるための実行計画を策定するワークショップです。ワークショップでは、組織横断でのチームの組成企画を行い、ビジネス側と開発側が一体となり取り組みます。 ビジネスオーナーと開発者が一体となり、生成 AI が生み出すビジネス効果のコンセンサスを共有することが、プロジェクト成功の鍵となります。 株式会社ココペリにおける AWS 生成 AI 事例: ML Enablement Workshop によるユースケース特定とその検証 | A… PartyRock からのスタートではないですが、MLEW を実際に行ったお客様を紹介します。 ココペリ様は「中小企業にテクノロジーを届けよう」というビジョンのもと、IT 技術で全国の金融機関と共に中小企業同士を繋ぐサービスを提供しています。提供サービスの一つに、 中小企業 DX 支援プラットフォーム「Big Advance」 があります。 Big Advance に  AI/ML を活用する際に、技術的な側面のみならずビジネス視点での成長戦略を含めて練りたいとのことでワークショップを実施し、生成 AI のユースケースの特定、 タスクと効果測定 KPI の決定に繋がりました。 Phase 2：本番データを用いた検証 生成 AI でできることを理解し業務活用のアイデアを練ることができたら、次は、本番データを用いて実験を行ってみましょう。AWS ジャパンでは、お客様の AWS アカウント上に簡単にデプロイできる生成 AI アプリケーションのサンプル実装を公開しています。これらを利用することで、セキュアな実験環境を作って検証を行うことができます。ここでは、サンプルアセットを 2 つ紹介します。 Bedrock Claude Chat Bedrock Claude Chat  （BrChat）は生成 AI を用いたチャット機能をすばやくかつセキュアにデプロイできるアプリケーションです。検索拡張生成（RAG, Retrieval Augmented Generation）、またシステムプロンプトを埋め込んだカスタムボットの共有などチャットに特化した機能を提供しています。BrChat を使ってチャットボットを作成した ブログ も公開されていますのでご参照ください。 Generative AI Use Cases JP Generative AI Use Cases JP  （GenU） は 生成 AI の様々なユースケースをワンストップで試せるアプリケーションです。チャットだけでなく、要約、画像生成、検索拡張生成、文書校正、翻訳、 Web コンテンツの抽出といった機能をすぐに試し効果を体感できます。 独自の生成 AI ワークフローをすばやく構築する際には  Amazon Bedrock Prompt Flows  を使うこともできます。 Amazon Bedrock Prompt Flows は 7 月にプレビューが公開された機能で、GUI を使って基盤モデル、Knowledge Base、AWS Lambda などのAWS サービスを簡単に統合し、生成 AI ワークフローをデプロイすることができます。 実験の結果、狙ったユースケースを実現できたら、早期にテストユーザーに実験で作成した生成 AI ユースケースを試してもらい、想定したビジネス効果が得られそうかを確認します。 Phase 3：ユーザーへの展開を開始 Phase 2 で実験を重ね、一定の効果が見込めればユーザーへの本格的な展開に移行します。この段階では、Amazon Bedrock や Amazon SageMaker などの生成 AI アプリケーションを構築するためのサービスをフルに活用しましょう。この段階でも継続的に改善を重ね、必要に応じて Phase 1 や Phase 2 に立ち返ってみましょう。 ユーザーへの展開に成功しているお客様の事例を 2 つ紹介します。 北海道文化放送様 では、Amazon Bedrock を活用し FAX 受信からニュース原稿および動画までの作成フローを自動化し、毎月 100～120 本のコンテンツ増加を実現しました。 三井物産株式会社様 では、入札書類の解析を自動化するソリューションを開発し、解析作業を 70 % 短縮することに成功しました。 最後に 初めてブース展示に立ち、サービスをお客様に紹介するという経験は、私たち新入社員のソリューションアーキテクトとして非常に緊張するものでした。しかし、PartyRock を実際に体験していただき、お客様の生の反応を直に感じ取ることができ、貴重な機会になりました。 今回の AWS Summit Japan は、多くの人に PartyRock を体験していただき、新たなビジネスアイデアを考えるきっかけとなる有意義なイベントであったと思います。 生成 AI に興味をお持ちの方は、まずはぜひ PartyRock で気軽にアプリを作ってみてください。PartyRock が、生成 AI の業務活用ジャーニーをスタートさせるきっかけになると幸いです。 本ブログは、ソリューションアーキテクトの九曜と山本が執筆し、ソリューションアーキテクトの松本が監修しました。 著者について 九曜 克之 （Katsuyuki Kuyo） アマゾン ウェブサービス ジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 趣味はマンガを読むことです。 山本 ひかる （Hikaru Yamamoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 お客様の技術課題に Dive Deep できるよう毎日勉強中。 松本 敢大 （Kanta Matsumoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。好きな AWS サービスは AWS IoT Core。趣味はカメラで、動物が好きです。

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。 過去の記事はこちらになります。 ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』 ガバメントクラウド活用のヒント『ガバメントクラウド上で CIDR 重複を起こさないために！』 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 当記事 少し発展的な内容となっておりますので、ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、見積もりで注意すべきポイントについて扱っていきます。見積もりを作成したいベンダーの方々や、ベンダーから提出された見積もりに過不足がないかチェックしたい自治体の方々を対象としています。 ※このブログは、地方公共団体の基幹業務システムを構成する代表的な AWS サービスを対象として、見積もりのポイントを示すための参考情報であり、実際に構成するサービスは利用する ASP ベンダーのアプリケーションに依存しますのでご留意ください。 以下のセクションで構成されています。 コンピューティング費用の見積もり ネットワーク費用の見積もり ガバナンス・セキュリティ費用の見積もり バックアップ費用の見積もり AWS Pricing Calculator への入力 コスト削減のヒント まとめ ※本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。 コンピューティング費用の見積もり クラウド費用全体のうち、コンピューティング費用が大部分を占めるので、コンピューティングサービスの見積もりは非常に重要です。現行システムの OS/CPU/メモリや、CPU 使用率・メモリ使用率の情報があれば、それを参考にインスタンスを選定していきます。 Amazon EC2 の見積もり インスタンスタイプの選択 インスタンスタイプには、インスタンスファミリー、インスタンス世代、インスタンスの追加機能、インスタンスサイズなどの情報が含まれます。例えば、 c7gn.xlarge というインスタンスタイプでは、インスタンスファミリーが c、インスタンス世代が 7、追加機能が g と n、インスタンスサイズが xlarge であるということがわかります。 EC2 のインスタンスタイプの選択の詳細については、詳しくは「 AWS における効率的なコンピュートサービス活用入門 」の資料もご覧ください。 インスタンスファミリーの選択 インスタンスファミリーはメモリ・I/O・CPU クロック重視・GPU・FPGA 搭載などの種類を表します。多くの種類がありますが、一般的にはメモリ要件に合わせて、メモリは少なくてもよいときはコンピューティング最適化の C インスタンス、より大きいメモリ量が必要なときはメモリ最適化の R インスタンス、その他のときは汎用の M インスタンスを選択することが多いです。 定常的な CPU 性能が不要な検証環境などでは、安価に利用できる T インスタンスを選択する場合もあります。 例えば、インスタンスサイズとしては同じ medium を利用した場合でも、vCPU 数やメモリの大きさに以下のような違いがあります。 インスタンスタイプ vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) コスト (/GB 月 ) M7g.medium 1 4 EBS のみ 最大 12.5 最大 10 USD 0.0527 C7g.medium 1 2 EBS のみ 最大 12.5 最大 10 USD 0.0455 R7g.medium 1 8 EBS のみ 最大 12.5 最大 10 USD 0.0646 ※コストは東京リージョン、Linux のインスタンス インスタンス世代の選択 同じインスタンスファミリーでも、世代が進むにつれて数字が大きくなります。一般的には新しい世代の方が高性能でコストパフォーマンスもよいので、要件に合わせてできるだけ新しい世代のもののご利用をお勧めします。 インスタンスの追加機能の選択 第 6 世代以降では、すべてのインスタンスタイプで CPU タイプを表す記号が付与されています。例えば、　Intel Xeon 搭載なら i、AMD EPYC 搭載なら a、 AWS Graviton (Arm ベースの CPU) 搭載なら g です。ご利用のアプリケーションパッケージがご利用のインスタンスの CPU に対応しているか確認すると良いでしょう。 その他の情報については、 インスタンスタイプのページ などをご参照ください。 インスタンスサイズの選択 インスタンスサイズが増加すると、 vCPU 数とメモリ、EBS 帯域幅、ネットワーク帯域幅が増加します。移行対象となるシステムで現在利用している vCPU 数やメモリサイズを参考にして選択してください。 計算命令を多用するシステムであれば、CPU 数やクロック数を基準に見積もりを考えた方が良いでしょう。それに対し、I/O (データアクセス) が主体なものは、高速ストレージを主体に見積もりをする方が良いでしょう。データアクセス処理をメモリ領域で処理することで、高額な I/O コストを支払う場合に比べてメモリを増やす方が安価にすることが出来る場合があります。 また、現在のサーバリソースの使用率を加味することで、より適切なインスタンスの使用を検討できます。例えば、現行システムが AMD プロセッサを利用したオンプレミスサーバーで動いており、そのサーバーの CPU コア数が 8 で CPU 使用率が 20%、メモリが 32GiB で使用率が 70% の時、必要な vCPU 数が 2 、メモリが23GiB となるので、r6a.xlarge を選定する、ダウンサイジングという考え方も検討することが可能です。 Amazon EBS の見積もり EBS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります (マグネ ティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。 実際に利用しているサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパ シティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることが出来ます。 Amazon EBS ボリュームの種類については、 ドキュメント もご覧ください。 IOPS/スループットの追加 gp3 タイプを例に挙げて、IOPS/スループットの追加の考え方についてご説明いたします。gp3 では、デフォルトで 3,000 IOPS、125 MiB/秒のスループットを一貫したベースラインパフォーマンスとして提供しています。追加料金を支払うことで、最大で16,000 IOPS、1,000 MiB/秒のスループットまでプロビジョニングできます。また、EC2 のインスタンスごとに IOPS およびスループットの上限もございますのでご注意ください。 IOPS およびスループット追加は、実際に稼働した上で Amazon CloudWatch などで監視し、IOPS やスループットがボトルネックとなっている場合にご検討いただくことになると思います。 gp3 タイプの IOPS およびスループットの詳細については ドキュメント もご覧ください。 EBS のスナップショットの考え方 スナップショットの料金に関わってくるパラメータには、以下のようなものがあります。 スナップショットを取得する頻度 初期スナップショットの容量（=EBS の容量） 増分スナップショットあたりの増加容量 フルバックアップではなく増分バックアップですので、前回のスナップショットからの変更分のみ新たに保存されます。 RDS の見積もり RDSでは以下の要素に応じて料金が発生します。 利用するノード数 利用するノード数には、マルチ AZ 構成、リードレプリカ構成(数)なども含みます。 構築するインスタンスタイプ RDS のインスタンスタイプは、EC2 と同様に主に「汎用」、「メモリ最適化」、「コンピューティング最適化」、その他があり、RDS で実行するワークロードの特性により選択することになります。 既存システムから現状ワークロード指標を検討する場合、現状のワークロードを分析し、必要リソースを確認し初期見積もり値を決定します。繁忙期が存在する場合、繁忙期のワークロード量もさらに分析を行い加味することが必要です。パフォーマンス分析レポートを定期的に取得している場合は、そのレポートを基に分析を行うことも可能です。 新規システムとして検討する場合で、類似のシステム (利用者数や業務数・機能要件の観点に基づき) がある場合は、該当システムのリソース状況から選定し初期見積もりを行います。類似のシステムが無い場合、小規模・中規模想定のシステムとしてインスタンスタイプを見積もり、その後、パフォーマンステスト実施後に再度、ワークロードを分析し、改めて見積もりを行います。 初期見積もりが終わった後、早期に見積もりの妥当性を確認するための PoC を実施します。その結果を踏まえ、改めて必要なインスタンスタイプの見積もりを行います。 詳細については、以下のページもご覧ください。 Amazon RDS インスタンスタイプ | AWS DB インスタンスクラス – Amazon Relational Database Service RDS プロキシ利用有無 RDS プロキシは、基となるインスタンスの容量に基づいて料金が設定されています。サーバーレスアプリケーション (例: Amazon Lambda など) を開発している場合、データベース接続をプールおよび共有することでセッション接続・切断が効率的に行えます。 詳細については、以下のページもご参照ください。 Amazon RDS Proxy | 高可用性データベースプロキシ | Amazon ウェブサービス 商用ライセンス利用の有無 RDS で商用データベースを利用する際は、ライセンス費用も発生します。ライセンスの支払い体系としては、ライセンス持ち込み (BYOL) とライセンスインクルード (LI) があります。 データベースストレージボリュームサイズ RDS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります(マグネティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。 データベースストレージのボリュームは、実際のレコード件数に基づくサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパシティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易 (RDS ストレージの自動スケーリング) なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることができます。 詳細については、以下のページもご参照ください。 Amazon RDS DB インスタンスストレージ – Amazon Relational Database ServiceAmazon R… Amazon RDS DB インスタンスのストレージを使用する – Amazon Relational Database Service モニタリングとしての Performance Insights 利用有無と保存期間 データベースのモニタリング方法としては、Amazon CloudWatch メトリクスや、Enhanced Monitoring があります。 さらに、データベースアクティビティのモニタリング方法として Performance Insights が挙げられます。データベース内のパフォーマンスデータを蓄積してボトルネックを特定するのに役立ちます。直近で 7 日間のパフォーマンス履歴は、無料で保存できますが、それ以前のデータベースアクティビティを確認したい場合、料金が発生します。アプリケーションの実行サイクルを加味して、日・週・月・半期・年度の単位でデータベースアクティビティを分析する必要があるかをあらかじめ想定する必要があります。 詳細については、以下のページもご参照ください。 Amazon RDS の Amazon CloudWatch メトリクス – Amazon Relational Database Serv… 拡張モニタリングを使用した OS メトリクスのモニタリング – Amazon Relational Database Service Performance Insights（RDSのパフォーマンスを分析、チューニング）| AWS 料金 – Performance Insights | AWS バックアップストレージサイズ 自動バックアップが保持される日数として 1 日～ 35 日が選択できます。保存期間によりバックアップ料金が異なります。 CloudWatch を利用したRDSの監視・ログ出力 CloudWatch を利用し RDS の CPUUtilization、FreeableMemory などの監視や通知設定が可能となります。また、各ログの収集も可能となります。メトリックの数やダッシュボード利用数、アラーム設定数、ログサイズ等により CloudWatch の料金は異なります。 詳細は、 料金 – Amazon CloudWatch | AWS 　をご確認ください。 最後に 合わせて、以下の公式サイト情報もご確認ください。 料金 – Amazon RDS | AWS 料金 – Amazon Aurora | AWS Amazon RDS の月額費用を計算する方法を教えてください。 Amazon RDS のコスト見積もり ネットワーク費用の見積もり ガバメントクラウドの AWS アカウントでは、庁舎と AWS 環境を閉域で接続するために、AWS Direct Connect や AWS Transit Gateway などのサービスを活用します。ガバメントクラウドでよくある構成 3 パターンについて 2024 年 4 月時点での料金をまとめましたので、近いパターンをご参照ください。地方公共団体からガバメントクラウドへの接続パターンや、ネットワークアカウントとそれを管理するネットワーク構築運用補助者のタスクの詳細については、 ガバメントクラウドの道案内『ネットワーク構築運用補助者編』のブログ をご覧ください。また、現在の価格や詳しい情報については、それぞれのサービスの料金ページをご覧ください。 利用する AWS アカウントの整理 以下で説明するそれぞれのパターンについて、以下の 2 つのアカウントが出現します。 ネットワークアカウント：自治体庁舎からの専用線接続を集約するために存在するアカウントです。AWS Direct Connect で庁舎と AWS 環境を接続し、AWS Transit Gateway をハブとして、アプリケーションアカウント内の VPC との通信を実現しています。AWS Direct Connect や AWS Transit Gateway はこのネットワークアカウントに集約し、ネットワーク構築運用補助者が運用管理を行います。 アプリケーションアカウント：アプリケーションが動作しているコンピューティングリソースが存在するアカウントです。異なるベンダーの管理するアプリケーションアカウントが複数存在する場合が一般的です。 VPN や AWS PrivateLink なしの構成 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 （契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます） AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 AWSと外部: VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway アタッチメント から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS PrivateLink を利用した構成 共同利用方式 (アプリケーション分離) などで自治体庁舎の IP アドレス範囲とアプリケーションが存在する IP アドレス範囲が重複してしまう場合、通信するために AWS PrivateLink というサービスを用いることがあります。 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます) AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 AWS内: AWS PrivateLink を設置してアプリケーション VPC 通信を中継させる VPC について、VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: AWS PrivateLink のインターフェイスエンドポイントについて、時間単位で 0.014USD/時間、データ処理料金として 0.01USD/GB それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 (AWS PrivateLink 経由で通信するアカウントの場合) AWS内: ネットワークロードバランサー (NLB) の料金。詳しくは 料金ページ をご覧ください。 VPN を利用した構成 情報ハイウェイや地域データセンターなどで複数の自治体庁舎からの通信を集約する場合、 Site-to-Site VPN などを利用してネットワークスライシング (物理ネットワークを仮想的に分割すること) を行うことがあります。この場合ネットワークアカウントは複数の団体で共用になりますが、今回は 1 つ目の団体 (団体 A) が負担する料金についてまとめました。 ※一般的に Site-to-Site VPN はインターネット経由で用いるため、Direct Connect が必ずしも必要ではない点にご注意ください。今回 Direct Connect 経由で Site-to-Site VPN を利用しているのは、現行の自治体システムでは基本的に閉域を採用しているためです。 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます) AWSと外部: Site-to-Site VPN の料金 0.048USD/時間 AWSと外部: Site-to-Site VPN を経由して AWS 外部に送信されたデータ量に対して 0.114USD/GB AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway の Private IP VPN アタッチメントに対して 0.07USD/時間 それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 AWSと外部: VPC から Direct Connect を経由して Direct Connect ロケーション方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway アタッチメントから Transit Gateway に送信されたデータ量に対して 0.02USD/GB ここにあげた AWS の費用以外にも自治体庁舎側の回線費用などが発生する場合があります。 また、Direct Connect の通信経路は要件によって冗長化する必要が生じます。この場合、Direct Connect のコストが大きくなりますので、合わせてご確認ください。Direct Connect の冗長化については、AWS Black Belt Online Seminar AWS Direct Connect の 資料 をご覧ください。 ガバナンス・セキュリティ費用の見積もり ガバメントクラウドにおいて必須適用テンプレートによって自動適用されるガバナンスやセキュリティのサービスには、以下のようなものがあります。 AWS CloudTrail AWS を操作した際の証跡ログを半永久的に保存可能です。 データ処理やデータ保持に料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Config AWS リソースの構成変更記録、構成変更を管理します。リソースの設定や関係に変更があった際に配信される設定項目の数や、AWS Config ルールなど、評価の数に対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 Amazon GuardDuty 脅威の検知と継続的監視を行います。分析した CloudTrail イベント件数やログのデータ量などに対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Security Hub 組織内のさまざまなセキュリティデータを集約して、一元的に可視化したり優先順位づけします。実行されたセキュリティチェックの件数や他サービスからの検出結果の取り込み件数などに対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Trusted Advisor お客様が AWS のベストプラクティスに準拠するための推奨事項を提供します。こちらはガバメントクラウドで加入しているサポートプラン (後述) に含まれております。 バックアップ費用の見積もり 地方公共団体情報システム非機能要件の標準 では、大規模災害が発生した際の標準的な復旧目標時間は「 1 か月以内に再開」とされています。これを満たしコストを抑えられる災害対策の手法として、セカンダリリージョン (東京リージョンを常時稼働させるリージョン (プライマリリージョン) とする場合は大阪リージョン) にバックアップを保持しておき、災害時はプライマリリージョンが復旧してから、データをセカンダリリージョンのバックアップから復元し、システムの稼働を再開するという手法が考えられます。 バックアップ戦略も含め、AWS でのディザスタリカバリ (DR) アーキテクチャとクラウドでのリカバリ戦略については、 こちらのブログ をご覧ください。どのようなDR戦略を取るかによって費用は変わってきますが、以下では一例としてバックアップ＆リストア方式を採用する場合の費用の計算方法について記載します。 バックアップ & リストア方式を採用する場合 自治体でよく用いられるバックアップ&リストア方式について、主にかかる費用としては以下のようになります。 東京リージョンにおいて追加でかかる費用 EC2 と EBS のバックアップストレージ料金：大阪リージョンにコピーする EC2 と EBS のスナップショット (AMI) を取得しますが、それを保存する容量に対して料金がかかります。 0.05USD/ 月GB です。 データベースのバックアップストレージ料金：大阪リージョンにコピーするデータベースのスナップショットを取得しますが、それを保存する容量に対して料金がかかります。ただし、料金がかからない場合もあります。例えば Amazon RDS for MySQL の場合は、データベースストレージの容量と同じ分だけ無料でバックアップに利用できます。 東京リージョンから大阪リージョンへの データ転送料 USD 0.09/ GB がかかります。 大阪リージョンにおいて追加でかかる費用 EC2 と EBS のバックアップストレージ料金：東京リージョンからコピーしてきたスナップショットを保存する容量に対して USD 0.05/ 月GB の料金がかかります。 データベースのバックアップストレージ料金：東京リージョンからコピーしてきたデータベースのスナップショットを保存する容量に対して料金がかかります。例えば、Amazon RDS for MySQL の場合は USD 0.095/ 月GiB です。 料金試算例については、こちらの資料もご覧ください。 東京と大阪リージョンを活用して、バックアップ＆リストア戦略で災害対策 ( DR ) を実現する AWS Pricing Calculator への入力 AWS Pricing Calculator で見積もりを作成する際の入力方法のヒントをご紹介します。 以下のヒントは、すべての項目について列挙しているわけではなく、迷うことが多いポイントについて整理したものですので、ご注意ください。 こちらの構成をもとに入力のヒントを作成しております。 EC2 関連費用の入力 リージョンを選択します。 テナンシー：通常、「共有インスタンス」を選択します。 ワークロード：通常、「一定の使用量」を選択します。 インスタンスタイプ：このブログの「コンピューティング費用の見積もり」の章を参考にして決定したインスタンスタイプを選択します。表示される表は、デフォルトではオンデマンド利用料が低い順に並んでいます。 お支払いオプション：「使用状況」は常に起動させるサーバーでは 「 100 Utilization percent per month」 を選択します。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。 「Amazon Elastic Block Store (EBS) – オプション」の章では、Amazon EBSの章を読んでいただき、 EBS の詳細についてご記入ください。以下の説明は gp3 インスタンスを選択された場合のものです。 IOPS は、3,000 IOPS までは無料、それ以上は追加料金がかかります。 スループットは、125 MiB/ 秒までは無料、それ以上は追加料金がかかります。 スナップショット頻度を選択すると、スナップショットあたりの増分を入力できます。これは一般的には EBS 自体の容量よりも小さい値です。 RDS 関連費用の入力 リージョンを選択します。 ガバメントクラウドでは通常、「使用状況」は常に起動させるデータベースでは「 100 %Utilized/Month」を選択します。 デプロイオプションは可用性などの要件に合わせてご選択ください。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。 RDS プロキシを利用する必要があるかどうかは、 こちらのページ をご覧ください。 インスタンスタイプやストレージ量は、このブログの「コンピューティング費用の見積もり」の章を参考にして決定したものを選択します。 バックアップストレージは、保持したいバックアップの容量を入力してください。ただし、インスタンスのストレージ量と同じ容量が無料で提供されるので、追加分を入力してください。 ネットワーク費用の入力 AWS Transit Gateway の費用は、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。 リージョンを選択します。 Transit Gateway のアタッチメント数は、 Direct Connect や VPC、VPN など Transit Gateway と接続するものすべての個数です。例えば冒頭の図の構成の場合 2 個になります。 「Transit Gateway のアタッチメントごとに処理されたデータ」は、アタッチメントごとに Transit Gateway に送信するデータ量の推定値を入力してください。 AWS PrivateLink をご利用になる場合の費用も、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。 AWS Direct Connect のポート料金や、AWS Direct Connect 経由で AWS の外に出る通信量にかかる費用については、AWS Direct Connect のサービスを選択した画面から入力してください。 リージョンを選択します。 「サービスの設定」に関わるポート数などの値は、ネットワーク構築運用補助者にご質問ください。 「データ転送 (送信)」に、AWS Direct Connect 経由で AWS の外に出る通信量をご入力ください。 ガバナンス・セキュリティ費用の入力 高額になりやすい費用として、Amazon CloudWatch の費用がございますので、そちらについて目安をご紹介いたします。 EC2 インスタンスが EC2 詳細モニタリングで 12 個の追加メトリクスを公開する場合、そのインスタンスでは最高価格階層で月額最大 3.60 USD、最低価格階層で月額最大 0.24 USD の料金が発生します。詳しくは、 こちら をご覧ください。 バックアップ費用の入力 東京リージョンから大阪リージョンへのデータ転送量については、「AWS Data Transfer」のメニューのうち送信データ転送から、「その他すべてのリージョン」を選択し、量を入力ください。 コスト削減のヒント 一般的には以下のような方法で、コストを削減できます。ぜひ参考にしていただいて、ガバメントクラウドの費用削減にお役立てください。 ダウンサイジング インスタンスタイプを小さいサイズに変更すると、大きな費用削減効果が得られます。大きいインスタンスサイズが適用されている場合は、現行のシステムの CPU 使用率やメモリ使用率などを鑑みて、より小さいインスタンスサイズが適用できないかをご検討いただくことをお勧めします。また、AWS ではアセスメントを支援する無償のプログラムがありますので、ぜひアカウント営業経由でお声掛けください。 見積もりからは離れますが、運用中に AWS Cost Explorer の「 サイズの適正化に関する推奨事項 」や Performance Insights で低使用率のインスタンスを確認し、インスタンスタイプを小さいサイズに変更できます。 リザーブドインスタンス等の割引オプションの利用 Amazon EC2 では、リザーブドインスタンスなどの割引オプションを適用することで、割引を得ることができます。現状、ガバメントクラウドでも、条件を満たせばリザーブドインスタンスなどの割引オプションを利用することができます。ガバメントクラウドにおける割引オプションの詳しい条件については、デジタル庁にご確認ください。 最新世代インスタンス利用 / コスト効率の良いCPUへ変更 冒頭でご説明したように、EC2 や RDS のインスタンスタイプに書かれている数字が大きいインスタンスの方が最新世代のインスタンスであり、コスト効率が高いです。言い換えると、同料金の場合でもスペックが向上するため、新しい世代を使えばインスタンスタイプを小さくできる可能性があります。 また、AWS Graviton プロセッサはクラウドワークロードに最高のコストパフォーマンスを提供するように設計されたプロセッサであり、移行することでコストパフォーマンスも向上する場合がございます。 AWS Graviton プロセッサへの移行の際に気をつける点については こちらのページ をご覧ください。 最新世代ストレージタイプ利用 インスタンスの世代と同様に、ストレージの世代も最新のものを利用した方がコストパフォーマンスが高いです。具体的には、gp2 ではなく gp3 を利用した方が良いでしょう。 開発環境を不使用時は停止する運用への変更 以下の 3 つの方法で、 EC2 の停止と起動をスケジューリングできます。 Amazon EventBridge スケジューラ と AWS Lambda : シンプルな実装方法にしたい場合はこちらが選択できます。 AWS Systems Manager Resource Scheduler : 既に　AWS Systems Manager (SSM) をご利用の場合は、こちらの方法を使うことで SSM での管理に統一できます。ただし、提供された機能を利用するため少しカスタマイズはしにくくなっています。 AWS Instance Scheduler : 複数のサービスを利用したソリューションです。複数のアカウントのインスタンスを管理できます。 また、負荷に時間や季節による変化があるようなシステムの場合、負荷に合わせて EC2 の台数を増減させたりインスタンスサイズを変化させたりすることで、負荷が小さい期間のコストを抑えることができます。合わせてご確認ください。 低コストのストレージクラスの利用 オブジェクトストレージである Amazon S3 では、スタンダードクラスのみでなく、アクセス頻度が少ない場合に費用削減効果を発揮する S3 Standard-Infrequent Access クラスや、アーカイブ保存用の S3 Glacier Deep Archive などがあります。保存するオブジェクトへのアクセス頻度を元に、最適なストレージクラスを選択されることをお勧めします。 増分バックアップの考慮 見積もり上でリージョン間転送料が多い場合、フルバックアップの想定で計算されていることがあります。実際には AWS Backup の機能などを用いることによって、フルバックアップではなく増分バックアップにすることができ、データ転送量を抑えることができる場合があります。 まとめ 本ブログでは、ガバメントクラウド上のシステムに関する見積もりで注意すべき点についてお伝えしました。 費用の大部分を占めるであろうコンピューティング費用の見積もりを中心に、見積もりに役立てていただけると幸いです。 自治体に所属している方または関連するベンダーの方で、このブログに関してご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した見積もりに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

はじめに コンタクトセンターのエージェントは、顧客対応時に様々な課題に直面します。技術的な問題のトラブルシューティング、請求に関する交渉の解決、または単に役立つ正確な情報を提供する場合など、幅広いトピックがあり、それらすべてに効果的に対応しなければなりません。これを実現するためには、顧客をサポートするために必要な様々な問題や技術に精通していく、数ヶ月、時には数年の経験が必要となります。 しかし、対応が終わった後も仕事は終わりません。エージェントは、顧客記録の更新、ケースメモの記録、未解決の問題のフォローアップなど、重要なアフターコールワークを完了する必要があります。この管理作業は時間がかかりますが、高い顧客満足度 (CSAT) スコアと運用効率を維持するために不可欠です。複数のチャネルを通じ、増え続ける顧客からの問い合わせに対応するため、エージェントは優れた顧客体験を提供しながら、大量の顧客対応を迅速に処理するプレッシャーにさらされています。この増大する作業量は、燃え尽き症候群、高い離職率、サービスレベルのばらつきにつながる可能性があります。 生成 AI は、顧客サービスのライフサイクル全体で人間のエージェントを補助し、生産性の大幅な向上の機会を提供します。日常的な対応後のタスクを自動化し、エージェントにリアルタイムの情報支援を提供することで、生成 AI はエージェントの力を増幅させる役割として機能し、エージェントがより速く賢く作業できるようにします。このブログ記事では、 Amazon Connect の生成 AI 機能が、顧客対応中と対応後の エージェントの生産性 をどのように向上させるかを探ります。 まず、 Amazon Q in Connect がリアルタイムのエージェント支援の提供、関連するステップバイステップガイドの推奨により、対応中のエージェントをどのようにサポートできるかを見ていきましょう。その後、Amazon Connect Contact Lens がエージェントのアフターコンタクトワークを支援する方法を紹介します。 Amazon Q によるリアルタイムのエージェント支援 Amazon Q in Connect では、生成 AI を使用しエージェントに対して回答やアクションの提案を行い、顧客の質問に対する問題解決を迅速化し、顧客満足度を向上させます。会話分析と自然言語処理 (NLP) を使用することで、Amazon Q in Connect は顧客の問題を自動的に検出し、エージェントが追加情報を必要とする場合には対話型の検索にも対応できます。 Amazon Q in Connect では、現在、ナレッジ記事、Wiki、FAQ から派生したソリューションだけでなく、 関連するステップバイステップガイドも推奨 し、現在のタスクを完了するために必要な適切な手順を提供します。Amazon Connect のステップバイステップガイドは、コンタクトセンターのエージェントが顧客からの問い合わせを迅速かつ効率的に解決するのに役立ちます。これらのカスタマイズ可能なガイドは、業務に合わせたワークフローを提供し、エージェントが顧客の問題に対処するために必要な手順を説明します。コーディング不要、ドラッグアンドドロップでワークフローを構築でき、管理者は注文処理、支払い管理、返品処理などさまざまな顧客対応のためのガイドを設計できます。これらのガイドは、顧客のコンテキストに基づいて動的に適応し、問題に関する関連情報を表示し、エージェントに適切なアクションを案内します。ステップバイステップガイドは、すでに Amazon Connect の エージェントワークスペース で利用可能です。Amazon Q in Connect は、この案内支援を表示し、生成された回答やソリューションと共にガイドを提供します。これにより、新しいエージェントの研修時間を短縮したり、経験豊富なエージェントの生産性を向上させることができます。エージェントは常に次の最適なステップを知ることができ、より迅速で正確な解決につながります。 またステップバイステップガイドをナレッジ記事に関連付けることで、関連する情報を表示でき、エージェントはエージェントワークスペースから離れることなく、質問に答えて問題を迅速に解決するための次のステップを実行できます。コンテキストに応じた情報とベストプラクティスガイドを得られることで、エージェントは問題をより速く処理でき、より一貫性と正確性のある解決策を提供できます。これにより、平均処理時間、最初の問題解決率、顧客満足度スコアなどの重要なメトリクスが改善されます。 では Amazon Q in Connect がエージェントの生産性を向上させる例を見てみましょう。 例: Amazon Q in Connect による顧客との対話支援 エージェントが支払い方法の更新を必要とする顧客と対話しています。顧客が「支払い方法の更新」をリクエストした後、Amazon Q in Connect は、リアルタイムで応答と関連するステップバイステップガイドの推奨を提供し、エージェントをサポートします。このガイドはプロセスを合理化し、エージェントにワークスペース内で顧客の請求情報を更新する正確な手順を示すことで、エージェントは複数のタブやアプリケーションを行き来する必要がなくなります。 このガイドはエージェントの他のアプリケーションと並んで対話型のフローとして提供されるため、文脈を失ったり作業の流れを中断することなく、シームレスに作業を進めることができます。 Amazon Q in Connect では、会話のトピックが変わった際にもエージェントが問題を処理できるよう支援します。例えば、顧客から返品についての電話があった場合、Amazon Q in Connect は当初、一般的な「返品と交換」ガイドを推奨するかもしれません。しかし、エージェントが不具合製品の問題であると特定すると、Amazon Q は特定の「不具合製品の返品」ワークフローを表示します。異なる記事を探す無駄な時間はなくなり、エージェントは正確な手順を画面で確認できます。 顧客対応後、エージェントは返金リクエストを送信する必要があります。エージェントが Amazon Q in Connect にチャットで「返金処理が必要」と質問すると、関連するナレッジベースの情報と承認されたプロセスのフローが表示されます。Amazon Q は自然言語のリクエストを処理し、正確な情報とタスク完了のための手順を返します。 関連する知識を手元で参照できることで、Amazon Q in Connect はエージェントの操作やアプリケーションの切り替えを最小限にし、エージェントが迅速に情報を見つけ、手順に従い、タスクを完了できるようにします。これにより、コンタクトセンターにおける大きな生産性の低下要因の 1 つを解消します。Amazon Q in Connect は、パフォーマンスメトリクスの向上だけでなく、新しいエージェントの研修時間を短縮し、より直感的なデスクトップ体験を提供します。これにより、従業員の満足度が向上し、高コストである離職が減少します。Amazon Q in Connect のような生成 AI 機能を備えることで、コンタクトセンターはナレッジベースを最大限に活用し、エージェントに高速でスマートな顧客サービスを提供する力を与えることができます。 ステップバイステップガイドとナレッジコンテンツの連携 Amazon Q in Connect でステップバイステップガイドを推奨事項とともに表示するためには、まずコンテンツにガイドを関連付ける必要があります。1 つのコンテンツに関連付けられるガイドは 1 つですが、必要に応じて複数のコンテンツに 1 つのガイドを関連付けることができます。管理者は、 Amazon Q in Connect API で利用可能な CreateContentAssociation を使用して、ナレッジコンテンツに関連するガイドを関連付けることができます。この API を使用すると、顧客タスクを効果的に解決するために必要なガイドつきワークフロー、フォーム、および埋め込まれたサードパーティアプリケーションでナレッジコンテンツを拡張することができます。他の Amazon Q in Connect API ( GetContentAssociation 、 ListContentAssociation 、 DeleteContentAssociation ) と組み合わせることで、いつ、どこで、どのように Amazon Q in Connect によるエージェントへの手順の支援を展開するか、完全に制御できます。 Amazon Connect Contact Lens によるアフターコンタクトワークの自動化 生成 AI が支援できるのは、エージェントとの対話中だけではありません。Amazon Connect Contact Lens は、会話分析と品質管理機能を提供し、コンタクトセンターがコンタクトの品質とエージェントのパフォーマンスを監視、測定、継続的に改善することで、よりよい全体的な顧客体験を実現できるようにします。 Contact Lens は、生成 AI によるコンタクト後の要約を提供 します。これは、 長い顧客との対話を、簡潔で一貫性があり前後関係が理解できるコンタクトサマリーに要約するものです。これにより、コールセンターの管理者はエージェントの対応をレビューする際に迅速に洞察を得て、品質とコンプライアンスのレビューに費やす時間を節約、エージェントのパフォーマンス改善の機会をより迅速に特定できるため、顧客体験を改善できます。 これらの要約は、エージェントがアフターコンタクトワーク (ACW) をより効果的に行うのに役立つものとなっています 。コンタクト後の要約を使えば、エージェントは顧客対話ごとに手動でメモを取る必要がなくなります。これは、エラーが発生しやすく、時間もかかるプロセスでした。この機能は、生成 AI の力を活用して、対話が終了するとすぐに前後関係が理解できるコンタクト後の要約を自動的に生成します。数秒で、全体の対話が分析され、主要な議論のポイント、提起された問題、取られたアクション、およびコンタクトからの他の重要なコンテキストを捉えた詳細な要約が、エージェントと管理者に提示されます。生成 AI による要約は、顧客記録にシームレスに添付できる、コンタクトの完全な記録を提供します。これにより、エージェントのワークフローからこの面倒な作業が排除されます。これにより、アフターコンタクトワークが削減され、エージェントは優れた顧客サービスの提供に時間を集中できるようになります。 Amazon Connect Contact Lens では、API、Kinesis Steams、問い合わせコントロールパネル (CCP)、連絡先の詳細ページを介してチャットと音声の要約にアクセスできます。これにより、 Amazon Connect Cases や Salesforce などの他のアプリケーションとのシームレスな統合が可能になり、エージェントは顧客の記録を迅速に更新し、プラットフォーム間でデータの一貫性を確保できます。これらの ACW 要約を活用する様々な方法について説明しましょう。 例: Amazon Connect Contact Lens の要約によるアフターコンタクトワークの効率化 エージェントが顧客との対話を完了した後、次の顧客との対話に移る前に ACW を行う必要があります。これを支援するため、Amazon Connect Contact Lens は CCP で対話の要約を提供しています。現在、音声対話がサポートされており、対話が切断されエージェントが ACW に移行された数秒後に、要約が CCP で利用可能になります。この画面では、完全な書き起こしと主要なハイライトが表示されますが、簡単な参照のために対話の要約が一番上に表示されます。エージェントはこの要約を参照して ACW 活動を完了したり、必要に応じて要約をラップアップのフィールドに直接コピーすることができます。 管理者にとって、コンタクトセンター全体で何が起こっているかを把握することは重要です。コンタクト詳細ページでは、エージェントがコンタクトを終了する前の ACW 中でも、ACW 要約はすぐに利用可能になります。音声とチャットの両チャネルでサポートされており、管理者、許可されたエージェント、または他の Amazon Connect ユーザーが、コンタクトの概要を素早く確認できます。 この要約は、コンタクトセンター内の他の用途でも役立つ可能性があります。Contact Lens の ListRealTimeContactAnalysisSegments (音声) および ListRealTimeContactAnalysisSegmentsV2 (チャット) API を使用すると、対話が終了した数秒後に 生成 AI が対応した会話の要約を返すことができます。 これらの API は、例えば ACW 活動を完了する際に参照するために要約をステップバイステップガイドに含めるなど、エージェント のワークフローに統合することができます。また、この API は、エージェント が使用する他のアプリケーションで ACW タスクを実行するためにも使用できます。 前述の方法に加えて、これらの要約は、コンタクトセンター全体で使用されるその他のアプリケーションの生産性を向上させるためにも使用できます。音声とチャットの両方のチャネルをサポートしている Amazon Kinesis Data Streams に対話の要約の直接 ストリーミング する機能により、コンタクトセンターは有効化されたすべての対話に対して、特に要約コンテンツに基づいて分析ツールやエージェント体験の強化を構築できます。 Amazon Kinesis を AWS Lambda や Amazon Data Firehose などのサービスに直接統合すれば、お客様はこのデータを活用してビジネス上の課題に対処し、Salesforce の顧客関係管理 (CRM) などのアプリケーションやシステムとシームレスに統合できます。この統合により、顧客データが最新の状態で維持され、エージェントの手動操作を必要とせずに様々な接点でアクセス可能になるため、全体的な運用効率と顧客満足度が向上します。 デモ Amazon Q in Connect と Contact Lens が、エージェントの対話をどのように支援するかご覧ください 結論 コンタクトセンターのエージェントは多大な作業負荷と事務的な負担に直面することが多く、それが生産性の妨げとなりエージェントの燃え尽き症候群につながる可能性がありますが、生成 AI の機能はこの課題に対する強力なソリューションを提供します。Amazon Connect では、生成 AI を活用して単調な作業を自動化し、対話中にリアルタイムの支援を提供し、包括的な対話後の要約を生成することで、エージェントがより効率的に業務を行い、より迅速な解決を実現し、全体的な顧客満足度を向上させることができます。状況に応じた知識を手元で参照できるようにし、ワークフローを合理的にすることで、エージェントは最も重要な業務、パーソナライズされた高品質のサービスを提供することに集中できます。企業が顧客体験を重視し続ける中、Amazon Connect の Amazon Q や Amazon Connect Contact Lens などの生成 AI 技術への投資は、生産性の向上、運用コストの削減、そしてより熱心で効果的なスタッフの育成に不可欠となるでしょう。AI の力を活用することで、コンタクトセンターは新たなレベルの効率性を実現し、大規模に優れた顧客体験を提供することができます。 Amazon Q in Connect の開始に役立つリソース インスタンスで Amazon Q in Connect を有効化する方法を学びたいですか ? Amazon Connect 管理者ガイドでは、Connect in Q を有効にする方法と機能の包括的な概要が提供されています。詳細は「 インスタンスで Amazon Q in Connect を有効にする 」をご覧ください。 Amazon Q in Connect を実際に体験したいですか ? この Amazon Q in Connect ワークショップ に従って、Amazon Q を有効化し、ドメインを設定し、コンテンツを接続し、生成 AI による応答とソリューションをエージェントに配信する方法を学びましょう。 ステップバイステップガイドを Amazon Q in Connect のコンテンツと統合したいですか ? Amazon Q in Connect では、コンテンツにビューを関連付けることができます。詳細は「 Amazon Q in Connect をステップバイステップガイドと統合する 」をご覧ください。 Amazon Connect ステップバイステップガイドの開始に役立つリソース Amazon Connect の最初のステップバイステップガイドの構築を開始したいですか ?   ステップバイステップガイドのワークショップ に従って、パーソナライズされた、動的で、コンテキストに応じた体験を提供するために Amazon Connect 属性と連携するサンプルガイドの構築、デプロイ、テストの方法についてさらに学びます。 ステップバイステップガイドを深く掘り下げたいですか ? Amazon Connect 管理者ガイド で、サードパーティのアプリケーションの連携の方法について詳しく学びます。 Amazon Connect Contact Lens の開始に役立つリソース Amazon Connect Contact Lens のハンズオン体験をしたいですか? Amazon Connect Contact Lens ワークショップ に従って、Amazon Connect Contact Lens 内で利用可能な機能のセットアップと探索方法を学びます。 生成 AI が生成する通話後の要約を学びたいですか? Amazon Connect 管理者ガイド で、これらの要約を有効化し、表示し、コンタクトセンターで使用する方法について学びます。 ステップバイステップガイドを深く掘り下げたいですか? Amazon Connect 管理者ガイド で、サードパーティのアプリケーションをオンボーディングする方法について学びます。 筆者紹介 Alex Schrameyer (代名詞 he/him) は、インディアナ州インディアナポリスに拠点を置く AWS のエージェントエクスペリエンス担当ワールドワイドソリューションアーキテクトリードです。卓越したエージェント体験こそが優れたカスタマーサービスの基礎であると考え、エージェントが優れた能力を発揮し、お客様に喜んでもらえる環境を作ることに重点を置いています。アレックスは世界中を旅するのが好きで、あなたの地元の野球場やテーマパークでも見かけるかもしれません。 TP Kohli は、AI/ML アプリケーションの構築、管理、およびスケーリングに注力するシニアプロダクトマネージャーです。彼は現在、生成 AI を使用して、コンタクトセンター顧客に最高の対話分析機能と品質管理機能を Amazon Connect で提供する責任者です。TP は、顧客のユースケースを解決すること、顧客の信頼を得ること、コンタクトセンターの顧客が対応の品質とエージェントのパフォーマンスを監視、測定、継続的に改善し、より良い全体的なエンドカスタマーエクスペリエンスを提供できるよう、最高のユーザーエクスペリエンスを提供することを愛しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

この記事は、こちらのブログ「 Deploying Karpenter Nodes with Multus on Amazon EKS 」（2024年5月24日公開）を翻訳したものです。 コンテナベースの通信事業者のワークロードでは、トラフィックやネットワークの分離のために Multus CNI をよく使用します。 Amazon Elastic Kubernetes Service（Amazon EKS） は Multus CNI をサポートしており、複数のネットワークインターフェイスをアタッチし、Kubernetes ベースのアプリケーションに対して高度なネットワーク構成や分離を適用することができます。AWS でアプリケーションを実行する利点の 1 つは、リソースの弾力性（スケールアウトおよびスケールイン）です。ノードの弾力性は、 Karpenter のようなクラスターオートスケーラーを使用することで実現できます。Karpenter は、アプリケーションの需要に応じて最適なコンピュートリソースを自動的に起動します。Karpenter は、迅速かつシンプルな Kubernetes クラスターのプロビジョニングを目的として設計されており、Amazon EKS ノードグループの外部でグループレスのノードをプロビジョニングします。 目的 この投稿では、Multus インターフェイス付きの EKS ノードプールを Karpenter でプロビジョニングされるデプロイモデルを紹介します。このデプロイモデルは、特に通信事業者のワークロードに推奨されますが、これに限定されるものではありません。このモデルは、Karpenter をグループレスのノードプールおよびオートスケーリングソリューションとして活用することを目的としています。グループレスのワーカー（ノードプール）は、Multus CNI を必要とするアプリケーション Pod 用であり、一方でAmazon EKS マネージド型ノードグループのワーカーは、プラグイン、アドオン、および Karpenter 自体など、Multus CNI を必要としないポッドを実行します。この投稿では、Karpenter が複数の Elastic Network Interface（ENI）を持つワーカーのリアルタイムスケーリングを管理し、スケーラビリティとネットワーク分離の厳しい要件を満たす方法も示します。 なぜこのようなデプロイモデルなのか？ Karpenter の主なユースケースは、デプロイ時やスケールアウトイベント時に Kubernetes クラスターのワーカーノードをプロビジョニングすることです。この投稿では、Karpenter のもう一つのユースケースとして、Multus CNI を使用するアプリケーションをホスティングするノードプールをプロビジョニングする方法を紹介します。このデプロイモデルは、アプリケーションのワーカーノードを Amazon EKS マネージド型ノードグループから切り離します。このアプローチの利点は、1）アプリケーションワーカーは特定のインスタンスタイプやサイズに限定されず、インスタンスのタイプやファミリーの幅広い選択肢を利用できること。2）アプリケーションのスケールアウト機能が Amazon Elastic Compute Cloud（Amazon EC2） Auto Scaling グループに結びつかず、Amazon EKS マネージド型ノードグループを通じて Auto Scaling グループを利用する場合よりも、柔軟にスケールできることです。また、EC2 Auto Scaling グループに依存しないため、Karpenter は Amazon EC2 fleet API を直接使用してワーカーノードを迅速にプロビジョニングできます。これはアプリケーションのスケールアウトシナリオにおいてかなり重要です。標準の Karpenter ベースのノードプロビジョニングは、単一の VPC サブネットに接続されたノードを作成するため、Multus CNI をサポートしていません。この投稿では、EC2NodeClass を使用することにより、user-data を活用した ENI 管理を導入することで、Karpenter を介して Multus をサポートするソリューションを提供します。 デプロイ このセクションで説明される手順の詳細は、こちらの GitHub リポジトリを参照しています。 このデプロイは、Multus CNI を使用したアプリケーション Pod を Karpenter で柔軟に実行できることを示しています。Karpenter を介して Multus 用の ENI を作成およびアタッチするアプローチを適用し、併せて Karpenter のスケーリング機能も実演します。 前提条件 この投稿の手順を進めるには、以下の前提条件が必要です。 AWS CloudShell 環境設定 このセットアップでは、VPC、EKS クラスター、EKS マネージド型ノードグループ、セキュリティグループ、および関連するVPCコンポーネントを作成します。 1. ここでは CloudShell 環境を使用して EKS クラスターを構成し、サンプルアプリケーションをデプロイします。CloudShell コンソールに移動し、この GitHub リポジトリをダウンロードして、必要なツール（awscli、kubectl、eksctl、helmなど）をインストールするための次のスクリプトを実行します。 sudo chmod +x tools/installTools.sh ./tools/installTools.sh 2. テンプレート `vpc-infra-mng.yaml` を使用して AWS CloudFormation スタックを作成します。2つのアベイラビリティゾーン（例：`us-west-2a` および `us-west-2b`）を選択します。スタック名を `karpenterwithmultus` とします（このスタック名は後で CloudShell 環境で使用します）。他のパラメータはデフォルトのままにしておくことができます。次の  AWS Command Line Interface (AWS CLI) コマンドを使用するか、 AWS マネジメントコンソール の CloudFormation メニューを使用してスタックを作成します。 aws cloudformation create-stack --stack-name karpenterwithmultus --template-body file://cfn-templates/vpc-infra-mng.yaml --parameters ParameterKey=AvailabilityZones,ParameterValue=us-west-2a\\,us-west-2b --region us-west-2 --capabilities CAPABILITY_NAMED_IAM 次の手順を実行する前に、最初の CloudFormation スタック作成が完了していることを確認してください。EKSクラスターとワーカーノードの構築には約15分かかる場合があります。 結果として得られるアーキテクチャは次の図のようになります。 3. CloudShell で、Karpenter バージョン、EKS クラスター名、および AWS リージョン を定義するために環境変数を作成します。パラメータ値を環境に応じて変更して、CloudShell コンソールに移動して次のコマンドを実行します。 export KARPENTER_NAMESPACE=karpenter export K8S_VERSION=1.29 export KARPENTER_VERSION=v0.32.3 export AWS_PARTITION="aws" export VPC_STACK_NAME="karpenterwithmultus" export CLUSTER_NAME="eks-${VPC_STACK_NAME}" export AWS_DEFAULT_REGION=us-west-2 export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)" export TEMPOUT=$(mktemp) 注： `VPC_STACK_NAME`は、CloudFormationテンプレート`vpc-infra-mng.yaml`で指定した名前を使います。 デフォルトのリージョンに注意してください。後のステップで、`nodepool.yaml`にはアベイラビリティゾーン（AZ）を指定します。 この例では CloudShell を admin ノードとして使用します。CloudShell がタイムアウトすると、環境変数が失われます。CloudShell 以外の admin ノードを使用しても問題ないです。 Kubeconfig を更新し、Amazon EKS コントロールプレーンへのアクセスをテストします。 aws eks update-kubeconfig --name $CLUSTER_NAME kubectl get nodes kubectl get pods -A エラーが表示されなければ、K8Sクラスターへのアクセスが確認されます。 プラグインの設定 4. Multus CNI をインストールします。 Multus CNI は、Kubernetes 用のコンテナネットワークインターフェースプラグインであり、Pod に複数のネットワークインターフェースをアタッチできます。Multus CNI と VPC CNI が Amazon EKS でどのように機能するかについて理解したい場合は、こちらの Amazon Container の記事 を参照してください。 kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/multus/v4.0.2-eksbuild.1/multus-daemonset-thick.yml kubectl get daemonsets.apps -n kube-system 5. Multus の IP アドレスレンジを専有させるために Multus サブネット用の CIDR 予約が必要です。CIDR 予約で明示的なフラグを設定すると、VPC が ENI などの VPC リソースを作成する際にこれらの CIDR ブロックに使わないようになります。次の CIDR 予約コマンドを Multus サブネットで実行し、/27 の IP レンジを確保します。 Multus1Az1subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus1Az1-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus1Az1subnetId} --cidr 10.0.4.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus1Az2subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus1Az2-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus1Az2subnetId} --cidr 10.0.5.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus2Az1subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus2Az1-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus2Az1subnetId} --cidr 10.0.6.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} Multus2Az2subnetId=$(aws ec2 describe-subnets --filters "Name=tag:Name,Values=Multus2Az2-${VPC_STACK_NAME}" --query "Subnets[*].SubnetId" --output text) aws ec2 create-subnet-cidr-reservation --subnet-id ${Multus2Az2subnetId} --cidr 10.0.7.32/27 --reservation-type explicit --region ${AWS_DEFAULT_REGION} 注： エラーが発生した場合、例えば`subnet ID doesn’t exist`のエラーが表示された場合は、正しい AWS_DEFAULT_REGION 環境変数が定義されているかどうかを確認してください。 6. Whereabouts プラグインをインストールします。Whereabouts は、前のステップで設定した Multus Pod IP アドレスを管理するために使用する IPAM CNI プラグインです。Whereabouts を使用した Multus Pod IP アドレスは、Custom Resource Definition（CRD）Network-Attachment-Definitions（NAD）を介して定義されます。 kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/daemonset-install.yaml kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/whereabouts.cni.cncf.io_ippools.yaml kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/whereabouts/master/doc/crds/whereabouts.cni.cncf.io_overlappingrangeipreservations.yaml kubectl get daemonsets.apps -n kube-system 7. クラスターに NetworkAttachmentDefinitions を適用します。これは、後でアプリケーション Pod を作成するときに、Pod 上の Multus インターフェースのコンフィグになります。このファイルを確認すると、前のステップで設定した CIDR 予約プレフィックスが定義されていることがわかります。 kubectl apply -f sample-application/multus-nad-az1.yaml kubectl apply -f sample-application/multus-nad-az2.yaml IAM ロールの設定 8. Karpenter IAM ロールおよび Karpenter に必要なその他の前提条件を作成します。このステップが完了すると、「Successfully created/updated stack – <Karpenter-${CLUSTER_NAME}>」というメッセージが表示されるはずです。 curl -fsSL https://raw.githubusercontent.com/aws/karpenter/"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > $TEMPOUT \ && aws cloudformation deploy \ --stack-name "Karpenter-${CLUSTER_NAME}" \ --template-file "${TEMPOUT}" \ --capabilities CAPABILITY_NAMED_IAM \ --parameter-overrides "ClusterName=${CLUSTER_NAME}" eksctl create iamidentitymapping \ --username system:node:{{EC2PrivateDNSName}} \ --cluster "${CLUSTER_NAME}" \ --arn "arn:aws:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}" \ --group system:bootstrappers \ --group system:nodes eksctl utils associate-iam-oidc-provider \ --cluster "${CLUSTER_NAME}" \ --approve eksctl create iamserviceaccount \ --cluster "${CLUSTER_NAME}" --name karpenter --namespace karpenter \ --role-name "${CLUSTER_NAME}-karpenter" \ --attach-policy-arn "arn:aws:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}" \ --role-only \ --approve export KARPENTER_IAM_ROLE_ARN="arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-karpenter" echo $KARPENTER_IAM_ROLE_ARN 9. Multus に必要な AWS Identity and Access Management (IAM) ポリシーを作成し、それを Karpenter ノードロールにアタッチします。EC2NodeClass の userdata セクションには、Karpenter でプロビジョニングされたノードに ENI を作成、アタッチ、およびコンフィグするためのスクリプトが含まれています。ノードには、Karpenter ノードロールに適切なポリシーをアタッチする必要があります。 aws iam create-policy --policy-name karpenter-multus-policy --policy-document file://config/multus-policy.json | jq -r '.Policy.Arn' karpentermultuspolicyarn=$(aws iam list-policies | jq -r '.Policies[] | select(.PolicyName=="karpenter-multus-policy") | .Arn') aws iam attach-role-policy --policy-arn $karpentermultuspolicyarn --role-name KarpenterNodeRole-${CLUSTER_NAME} 10.（オプション）スポットインスタンスを使用するためのロールを、下記のコマンドで作成します。 aws iam create-service-linked-role --aws-service-name spot.amazonaws.com || true 既にロールが正常に作成されている場合は、次のようなメッセージが表示されます。 # An error occurred (InvalidInput) when calling the CreateServiceLinkedRole operation: Service role name AWSServiceRoleForEC2Spot has been taken in this account, please try a different suffix. 注 ：このステップはオプションであり、Karpenter ノードプールでスポットインスタンスを使用したい場合にのみ必要です。 Karpenter のインストール 11. Karpenter をインストールします。 helm registry logout public.ecr.aws helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION} --namespace karpenter --create-namespace \ --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=${KARPENTER_IAM_ROLE_ARN} \ --set settings.aws.clusterName=${CLUSTER_NAME} \ --set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile-${CLUSTER_NAME} \ --set settings.aws.interruptionQueueName=${CLUSTER_NAME} \ --set controller.resources.requests.cpu=1 \ --set controller.resources.requests.memory=1Gi \ --set controller.resources.limits.cpu=1 \ --set controller.resources.limits.memory=1Gi \ --wait 12. Karpenter Pod が `Running` 状態にあるか確認するために次のコマンドを実行します。 kubectl get pods -n karpenter -o wide 13. `nodepool.yaml` ファイルに含まれる Multus サブネットタグ名、AZ、およびセキュリティグループタグ名を更新します。Karpenter ノードプール構成の詳細については、こちらの Karpenter の記事を参照してください。 sed -i "s/##Multus1SubnetAZ1##/Multus1Az1-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus2SubnetAZ1##/Multus2Az1-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus1SubnetAZ2##/Multus1Az2-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus2SubnetAZ2##/Multus2Az2-${VPC_STACK_NAME}/g" config/nodepool.yaml sed -i "s/##Multus1SecGrpAZ1##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus2SecGrpAZ1##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus1SecGrpAZ2##/Vpc1SecurityGroup/g" config/nodepool.yaml sed -i "s/##Multus2SecGrpAZ2##/Vpc1SecurityGroup/g" config/nodepool.yaml `nodepool.yaml` を正しい AZ 名で更新し、次のコマンドを実行します。この例では、`us-west-2a` および `us-west-2b` を使用しています。 AZ1='us-west-2a' AZ2='us-west-2b' sed -i "s/##AVAILABILITY_ZONE1##/${AZ1}/g" config/nodepool.yaml sed -i "s/##AVAILABILITY_ZONE2##/${AZ2}/g" config/nodepool.yaml 次のコマンドを使用して EKS クラスター名を更新します。 sed -i "s/##CLUSTER_NAME##/${CLUSTER_NAME}/g" config/nodepool.yaml Karpenter ノードプール構成を適用します。 kubectl apply -f config/nodepool.yaml 注：`config/nodepool.yaml` ファイルを確認すると、EC2NodeClass の userdata セクションがカスタマイズされていることがわかります。userdata 内のスクリプトは、Amazon EC2 ノードプールの作成時に MULTUS ENI をプロビジョニング、アタッチ、およびコンフィグします。これはノードプール上の MULTUS ENI LCM を設定するところです。追加のノードチューニングが必要な場合は、userdata セクションに追加することができます。 ノードプールコンフィグにエラーがある場合は、Karpenter コントローラーのログを確認してください。 kubectl logs -f -n karpenter -l app.kubernetes.io/name=karpenter -c controller 14. ノードプール内のノードで Multus DaemonSet Pod とアプリケーション Pod が同時にスケジュールされると競合状態が発生します。この課題を解決するために、Karpenter のノードプールを `StartupTaints` で構成する必要があります。`StartupTaint` は、Multus が準備完了するまでアプリケーション Pod が新しいノードにスケジュールされるのを防ぎます。Multus が準備できたら Taint が削除されます。Taint の削除を自動化するために、この投稿では DaemonSet ベースのソリューションを使用します。 まず、Taint を削除するまたの DaemonSet 用のネームスペースを作成します。 kubectl create namespace cleartaints DaemonSet `daemonset-clear-taints` がノード上の Taint を削除できるようにするための RBAC コントロールを提供する必要があります。次のコマンドで、`cleartaints` ネームスペースに限定された Service Account 、Service Account Role 、および Role Binding を作成します。 kubectl apply -f config/sa-role-rolebinding.yaml `cleartaints` というネームスペースで、` daemonset-clear-taints ` という名前の DaemonSet を作成して適用します。 kubectl apply -f config/cleartaints.yaml DaemonSet Pod を確認します。Karpenter ノードプールでのみ実行されるため、この時点では DaemonSet は表示されません。 kubectl get ds -n cleartaints Node-Latency-For-K8s のデプロイ 15.（オプション）ノードプールのスケールアウト速度に関するデータを収集するために、 Node-Latency-For-K8s ソリューション をデプロイできます。Node-Latency-For-K8s は、ノード起動遅延を分析するためのオープンソースツールです。このツールは、ノードがインスタンス化されるから、アプリケーション Pod が実行されるまでの各フェーズでかかった時間を測定します。後のステップではいくつかの例を取り上げます。 export VERSION="v0.1.10" SCRIPTS_PATH="https://raw.githubusercontent.com/awslabs/node-latency-for-k8s/${VERSION}/scripts" TEMP_DIR=$(mktemp -d) curl -Lo ${TEMP_DIR}/01-create-iam-policy.sh ${SCRIPTS_PATH}/01-create-iam-policy.sh curl -Lo ${TEMP_DIR}/02-create-service-account.sh ${SCRIPTS_PATH}/02-create-service-account.sh curl -Lo ${TEMP_DIR}/cloudformation.yaml ${SCRIPTS_PATH}/cloudformation.yaml chmod +x ${TEMP_DIR}/01-create-iam-policy.sh ${TEMP_DIR}/02-create-service-account.sh ${TEMP_DIR}/01-create-iam-policy.sh && ${TEMP_DIR}/02-create-service-account.sh export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)" export KNL_IAM_ROLE_ARN="arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-node-latency-for-k8s" docker logout public.ecr.aws helm upgrade --install node-latency-for-k8s oci://public.ecr.aws/g4k0u1s2/node-latency-for-k8s-chart \ --create-namespace \ --version ${VERSION} \ --namespace node-latency-for-k8s \ --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=${KNL_IAM_ROLE_ARN} \ --set env[0].name="PROMETHEUS_METRICS" \ --set-string env[0].value=true \ --set env[1].name="CLOUDWATCH_METRICS" \ --set-string env[1].value=false \ --set env[2].name="OUTPUT" \ --set-string env[2].value=markdown \ --set env[3].name="NO_COMMENTS" \ --set-string env[3].value=false \ --set env[4].name="TIMEOUT" \ --set-string env[4].value=250 \ --set env[5].name="POD_NAMESPACE"\ --set-string env[5].value=default \ --set env[6].name="NODE_NAME" \ --set-string env[6].value=\(v1\:spec\.nodeName\)\ --wait サンプルアプリケーションのデプロイ 16. サンプルアプリケーションをデプロイします。次のコマンドは、各 AZ に1つのアプリケーションレプリカを持つ Deployment をインストールします。これにより、Karpenter がアプリケーションをスケジュールできるようにノードプールの作成がトリガーされます。 `multitool-deployment-az1.yaml`、`multitool-deployment-az2.yaml` の各ファイルで、正しい AZ 名に更新します。 sed -i "s/##AVAILABILITY_ZONE1##/${AZ1}/g" sample-application/multitool-deployment-az1.yaml sed -i "s/##AVAILABILITY_ZONE2##/${AZ2}/g" sample-application/multitool-deployment-az2.yaml kubectl apply -f sample-application/multitool-deployment-az1.yaml kubectl apply -f sample-application/multitool-deployment-az2.yaml 各 Deployment には `karpenter-node` というアフィニティキーがあり、これによりアプリケーション Pod はラベル「`karpenter-node`」が付いたワーカーノードにのみスケジュールされます。Deployment が作成されるときに、Karpenter ノードプールはラベルを割り当てるため、これらの Deployment の Pod をスケジュール/実行するためにノードをスケールします。 次のコマンドを使用して、Karpenter が新しい Amazon EKS ワーカーノードをスケーリングするのを監視します。 kubectl get nodes -o wide Karpenter のログを確認します。 kubectl logs -f -n karpenter -l app.kubernetes.io/name=karpenter -c controller Karpenter が新しい EC2 インスタンスを起動し、EKS クラスターに参加し、`Ready` 状態になると、`Pending` 状態のポッドが `Running` 状態に移行します。 kubectl get pods -o wide 次の図のように、Multus インターフェースを持つ Karpenter ワーカーが追加されたアーキテクチャが完成します。 17. 次のコマンドを使用して、アプリケーション Pod が `Running` 状態であることを確認します。 $ kubectl get node NAME STATUS ROLES AGE VERSION NAME STATUS ROLES AGE VERSION ip-10-0-2-110.us-west-2.compute.internal Ready <none> 8m25s v1.28.5-eks-5e0fdde ip-10-0-2-156.us-west-2.compute.internal Ready <none> 29m v1.28.5-eks-5e0fdde ip-10-0-3-117.us-west-2.compute.internal Ready <none> 8m20s v1.28.5-eks-5e0fdde ip-10-0-3-146.us-west-2.compute.internal Ready <none> 29m v1.28.5-eks-5e0fdde $ kubectl get pod NAME READY STATUS RESTARTS AGE scaleouttestappaz1-6695b7f878-xjh66 1/1 Running 0 10m scaleouttestappaz2-7f88f964b6-8sz9r 1/1 Running 0 10m `kubectl describe pod` または `kubectl exec` を使用して Pod を確認し、Multus インターフェースとアドレスを確認できます。 kubectl describe pod|grep "multus " Normal AddedInterface 42s multus Add eth0 [10.0.2.73/32] from aws-cni Normal AddedInterface 42s multus Add net1 [10.0.4.32/24] from default/nad-multussubnet1az1-ipv4 Normal AddedInterface 42s multus Add net2 [10.0.6.32/24] from default/nad-multussubnet2az1-ipv4 Normal AddedInterface 45s multus Add eth0 [10.0.3.212/32] from aws-cni Normal AddedInterface 44s multus Add net1 [10.0.5.32/24] from default/nad-multussubnet1az2-ipv4 Normal AddedInterface 44s multus Add net2 [10.0.7.32/24] from default/nad-multussubnet2az2-ipv4 1つのポッドを選択し、次の `exec` コマンドを実行して Multus Pod の IP アドレスを確認します。`net1` および `net2` インターフェースが Multus インターフェースとして表示されます。Amazon EC2 ワーカー上では、Multus ENI はそれぞれ `eth1` および `eth2` と同じサブネットに属しています。 $ kubectl exec scaleouttestappaz1-6695b7f878-xjh66 -- ifconfig net1 net1 Link encap:Ethernet HWaddr 02:11:D3:5B:D6:6B inet addr:10.0.4.35 Bcast:10.0.4.255 Mask:255.255.255.0 inet6 addr: fe80::211:d300:15b:d66b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:450 (450.0 B) TX bytes:978 (978.0 B) $ kubectl exec scaleouttestappaz1-6695b7f878-xjh66 -- ifconfig net2 net2 Link encap:Ethernet HWaddr 02:8B:1B:57:0D:35 inet addr:10.0.6.35 Bcast:10.0.6.255 Mask:255.255.255.0 inet6 addr: fe80::28b:1b00:157:d35/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:51 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5070 (4.9 KiB) TX bytes:558 (558.0 B) 注 ：Multus Pod IP アドレスを確認します。これらの IP は、ステップ 6 で定義した NetworkAttachmentDefinitions ファイルで設定した範囲に属しています。 （オプション）Karpenter ノードプールのプロビジョニングにかかる時間を調べるために、Node-Latency-For-K8s のログを新しく作成されたノードで確認できます。`node-latency-for-k8s-node-latency-for-k8s-chart-xxxxx` Pod のログを取得します。例として、ログの取得に約5分かかる場合があります。 $ kubectl -n node-latency-for-k8s logs node-latency-for-k8s-node-latency-for-k8s-chart-7bzvs 2023/12/22 16:57:09 unable to measure terminal events: [Pod Ready] ### i-0cb4baf2a1aa35077 (10.0.3.7) | c6i.2xlarge | x86_64 | us-east-1d | ami-03eaa1eb8976e21a9 | EVENT | TIMESTAMP | T | COMMENT | |--------------------------|----------------------|-----|---------| | Pod Created | 2023-12-22T16:46:30Z | 0s | | | Instance Pending | 2023-12-22T16:46:41Z | 11s | | | VM Initialized | 2023-12-22T16:46:51Z | 21s | | | Network Start | 2023-12-22T16:46:53Z | 23s | | | Network Ready | 2023-12-22T16:46:54Z | 24s | | | Cloud-Init Initial Start | 2023-12-22T16:46:54Z | 24s | | | Containerd Start | 2023-12-22T16:46:54Z | 24s | | | Containerd Initialized | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Config Start | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Final Start | 2023-12-22T16:46:55Z | 25s | | | Cloud-Init Final Finish | 2023-12-22T16:47:16Z | 46s | | | Kubelet Start | 2023-12-22T16:47:16Z | 46s | | | Kubelet Initialized | 2023-12-22T16:47:17Z | 47s | | | Kubelet Registered | 2023-12-22T16:47:17Z | 47s | | | Kube-Proxy Start | 2023-12-22T16:47:20Z | 50s | | | VPC CNI Init Start | 2023-12-22T16:47:20Z | 50s | | | AWS Node Start | 2023-12-22T16:47:25Z | 55s | | | Node Ready | 2023-12-22T16:47:27Z | 57s | | 注 ：起動時に実行される userdata スクリプト（約20-25秒）は、ノードが Ready になるまでの時間に加算されます。userdata スクリプトを使用しない場合、Karpenterノードの Readby になる時間は約30秒です。 （オプション）Multus Pod IP の自動割り当て Pod への Multus 接続には、Multus IP をワーカーノード上の対応する Multus ENI のセカンダリIPとして割り当てることが重要です。この GitHub リンク を使用して、InitContainer ベースの IP 管理ソリューションまたは Sidecar ベースの IP 管理ソリューションをアプリケーション Pod 内で使用して、Multus IP を自動的に Multus ENI にセカンダリ IP として割り当てることができます。 スケーリング 18. 次のコマンドを使用してスケールアウトを実行し、Karpenter を使用したノードの追加スケーリングをテストし、ノードのスケーリングを監視します。 kubectl scale --replicas=5 deployment/scaleouttestappaz1 kubectl scale --replicas=5 deployment/scaleouttestappaz2 kubectl get nodes -o wide -w kubectl get pods 19.（オプション）Karpenter のスケールアウト速度に関するデータをもう一度収集します。新しく作成されたノードプールワーカーで `node-latency-for-k8s-node-latency-for-k8s-chart-xxxxx` Pod のログを取得します。 $ kubectl -n node-latency-for-k8s logs node-latency-for-k8s-node-latency-for-k8s-chart-28wsr ### i-005dfff5abc7be596 (10.0.2.176) | c6i.2xlarge | x86_64 | us-east-1c | ami-03eaa1eb8976e21a9 2023/12/22 17:14:55 unable to measure terminal events: [Pod Ready] | EVENT | TIMESTAMP | T | COMMENT | |--------------------------|----------------------|-----|---------| | Pod Created | 2023-12-22T17:04:16Z | 0s | | | Instance Pending | 2023-12-22T17:04:20Z | 4s | | | VM Initialized | 2023-12-22T17:04:29Z | 13s | | | Network Start | 2023-12-22T17:04:33Z | 17s | | | Network Ready | 2023-12-22T17:04:33Z | 17s | | | Cloud-Init Initial Start | 2023-12-22T17:04:33Z | 17s | | | Containerd Start | 2023-12-22T17:04:33Z | 17s | | | Cloud-Init Config Start | 2023-12-22T17:04:34Z | 18s | | | Cloud-Init Final Start | 2023-12-22T17:04:34Z | 18s | | | Containerd Initialized | 2023-12-22T17:04:35Z | 19s | | | Cloud-Init Final Finish | 2023-12-22T17:05:00Z | 44s | | | Kubelet Start | 2023-12-22T17:05:00Z | 44s | | | Kubelet Initialized | 2023-12-22T17:05:00Z | 44s | | | Kubelet Registered | 2023-12-22T17:05:03Z | 47s | | | Kube-Proxy Start | 2023-12-22T17:05:05Z | 49s | | | VPC CNI Init Start | 2023-12-22T17:05:05Z | 49s | | | AWS Node Start | 2023-12-22T17:05:09Z | 53s | | | Node Ready | 2023-12-22T17:05:11Z | 55s | | 2023/12/22 17:14:55 Serving Prometheus metrics on :2112 20. Karpenter は、`Pending` 状態のポッドの数に応じて必要なノードを自動的にプロビジョニングする柔軟性があります。レプリカの数を増やすことで、スケールインとスケールアウトをもう一度行うことができます。Karpenter がプロビジョニングしたインスタンスタイプとサイズを注目してください。 スケールイン： kubectl scale --replicas=1 deployment/scaleouttestappaz1 kubectl scale --replicas=1 deployment/scaleouttestappaz2 Karpenter が既存のノードプールを終了するのを待ち、終了したら再度スケールアウトします。この例では、ネットワークアドレス定義で利用可能な IP アドレスの数の制限まで Pod をスケールアウトできます。 kubectl scale --replicas=10 deployment/scaleouttestappaz1 kubectl scale --replicas=10 deployment/scaleouttestappaz2 クリーンアップ CloudFormation スタックを逆の順序で全て削除します。 kubectl delete -f sample-application/multitool-deployment-az1.yaml kubectl delete -f sample-application/multitool-deployment-az2.yaml sleep 120 # to ensure all the karpenter nodes are terminated kubectl delete -f config/nodepool.yaml kubectl delete -f config/cleartaints.yaml kubectl delete -f config/sa-role-rolebinding.yaml helm uninstall karpenter -n karpenter helm uninstall -n node-latency-for-k8s node-latency-for-k8s aws iam detach-role-policy --policy-arn $karpentermultuspolicyarn --role-name KarpenterNodeRole-${CLUSTER_NAME} karpentermultuspolicyarn=$(aws iam list-policies | jq -r '.Policies[] | select(.PolicyName=="karpenter-multus-policy") | .Arn') aws iam delete-policy --policy-arn $karpentermultuspolicyarn 結論 この投稿では、Karpenter を Multus CNI と組み合わせて使用し、Multus が使用する ENI のライフサイクルをどのように管理するかを示しました。Karpenter でプロビジョニングされたノードプールのワーカーには、Multus 対応のインターフェースがアタッチされます。また、Karpenter をオートスケーリングソリューションとして使用する利点も示しました。Karpenter は、Kubernetes クラスターでワークロードを実行する際に、効率とコストを次のように改善します： Kubernetes スケジューラーが未スケジュールとしてマークしたポッドを監視する。 Pod によって要求されたスケジューリング制約（リソースリクエスト、ノードセレクター、アフィニティ、トレランス、トポロジスプレッド制約）を評価する。 Pod の要件を満たすノードをプロビジョニングする。 ノードが不要になったときにノードを削除する。 Karpenter は、アプリケーションのスケーリング要件に対応するための柔軟なツールです。 Karpenter とベストプラクティスに関する詳細は、 AWS GitHub リンク を参照してください。 著者 Rolando Jr Hilvano Rolando Jr Hilvano is a Principal Solutions Architect in the Worldwide Telecom Business Unit at Amazon Web Services (AWS). He specializes in 5G space and works with telecom partners and customers in building and deploying Cloud Native Telco workloads on AWS. Ashutosh Tulsi Ashutosh Tulsi is a Principal Solutions Architect in the AWS Worldwide Telecom Business unit working with Communication Service Providers (CSPs) and Telco ISV Partners. His goal is to enable CSP’s achieve Operational and Cost efficiencies by providing solutions that assist in migrating the 4G / 5G Networks to the AWS Cloud. Young Jung Dr. Young Jung is a Principal Solutions Architect in the AWS Worldwide Telecom Business Unit. His primary focus and mission are to help telco Core/RAN partners and customers to design and build cloud-native NFV solutions on AWS environment. He also specializes in Outposts use cases of telco industry for telco’s edge service implementation powered by AWS services and technologies. Neb Miljanovic Neb Miljanovic is an AWS Telco Partner Solutions Architect supporting migration of Telecommunication Vendors into public cloud space. He has extensive experience in 4G/5G/IMS Core architecture and his mission is to apply that experience to migration of 4G/5G/IMS Network Functions to AWS using cloud-native principles. Sudhir Shet Sudhir Shet is a Principal Partner Solutions Architect in the AWS Global Telecom IBU team, specializes in IMS and 5G, working with various global telecom partners and CSPs to create cloud-native 5G/IMS NFV solutions on AWS. 翻訳はソリューションアーキテクトの陳誠が担当しました。

Heroku は、開発者が AWS 上でアプリケーションをデプロイ、運用、スケーリングできるようにする完全にマネージドされたプラットフォームサービス( PaaS )ソリューションです。2007 年に設立され、2010 年からは Salesforce の一部となっています。Heroku は、小規模スタートアップから大企業の大規模デプロイメントまで、数百万件のアプリケーションで選ばれているプラットフォームです。これらのアプリケーションをスムーズに運営するには、AWS が提供するビルディングブロックを使って、プラットフォームの基盤となるインフラストラクチャに継続的な投資が必要不可欠です。 このブログ記事では、Heroku が 2023 年に完了した、 アプリケーションメトリクスとアラート機能 のストレージバックエンドを自社管理の Apache Cassandra クラスターから Amazon DynamoDB に移行するインフラアップグレードについて説明します。 Heroku は、この移行を顧客への影響なしに完了することができました。Amazon DynamoDB への移行により、プラットフォームの信頼性が向上すると同時に、運用コストも削減されました。本記事では、システムアーキテクチャ、DynamoDB へ移行した理由、移行の実施方法、そして移行完了後の成果について詳しく説明します。 (本記事は 2024/05/09 に投稿された How Heroku reduced their operational overhead by migrating their 30 TB self-managed database from Amazon EC2 to Amazon DynamoDB を翻訳した記事です。) サービスとしてのメトリクス（ MetaaS ） Heroku のアプリケーションメトリクスは、内部のサービスである MetaaS（ Metrics as a Service ）によって提供されています。MetaaS は、Heroku で稼働しているアプリケーションから様々な観測値を収集します。例えば、特定の HTTP リクエストを処理するのにかかる時間などです。集計された生データに対し、アプリケーション単位、分単位の統計値(中央値、最大値、99 % 応答時間など)が計算されます。この時系列メトリクスデータは、 Heroku ダッシュボード に表示されたり、アラートやオートスケーリングの機能に活用されます。 MetaaS の中核は、高スケールでマルチテナントな時系列データ処理プラットフォームです。毎秒数十万件の観測値が最初に Heroku 上の Apache Kafka に取り込まれます。ストリーム処理ジョブのコレクションが Kafka からこれらの観測値を消費し、Heroku が各顧客アプリケーションについて追跡しているさまざまなメトリクスを計算します。そして、最終的には長期保存とクエリのためデータベース（元々は Amazon EC2 上の Apache Cassandra ）に書き込みます。MetaaS の時系列データベースには数 TB ものデータが保存されており、ピーク時には毎秒数万件の新しいデータポイントが作成され、最大秒間に数千件のリードクエリが行われます。 下記の図は従来のアーキテクチャを示しています。 DynamoDB を選択した理由 Cassandra によって構成された MetaaS は、長年 Heroku に良いサービスを提供してきました。しかし 2022 年末頃、Heroku のエンジニアチームはバックエンドストレージを構成する他の方法を探り始めました。MetaaS が使用している Kafka クラスターは、Kafka 運用の経験が豊富なチームによって提供されていますが、Cassandra クラスターは MetaaS 固有のものでした。 Heroku は、データベースインフラを監視するエンジニアチームは非常に小さいため、Kafka クラスターと同様に専門家チームが運用・保守するマネージドサービスに移行することが重要だと考えていました。そこで、大量のデータを高スケールで分散システムに格納しつつ、あらゆるスケールでの高速な書き込みパフォーマンスを維持できる AWS のマネージドデータベースを探しました。結果的に、Heroku の他のチームがデータストレージおよび処理に使用している DynamoDB が、一貫性とパフォーマンスの要件に合っていたため、MetaaS のワークロードにも適していると判断されました。 慎重なマイグレーション 計画を立て、コードを書き換えた後、既存の顧客に影響を与えずに、高スケールで高スループットの分散システムのバックエンドストレージを入れ替えるという作業が残されていました。既存 MetaaS アーキテクチャは Heroku の移行に有利でした。Kafka から時系列データを Cassandra に書き込むためのストリーム処理ジョブがすでに用意されていたので、同じデータを DynamoDB に書き込むための並行したジョブを立ち上げるのが簡単でした。これが移行の最初のステップで、システムの他の部分には何の影響もありませんでした。 Heroku の顧客にとって運用メトリクスは非常に重要です。DynamoDB へのデータ書き込みが正常に行われていることを確認するため、チームは従来の単体テストや統合テストに加えて、既存単体テスト及び統合テストを規範としたテストを実施しました。まずは Cassandra と DynamoDB の両方からデータを読み出すクエリを少量実行し、データの整合性を確認しました。2 つのコードパスで結果が異なるクエリはすべてログに記録されました。プリプロダクションでのテスト後、徐々にクエリの割合を増やし、最終的には 100 % のクエリが両方のコードパスを経由するようになりました。この変更によって、お客様は Cassandra のコードパスでクエリ結果をもらい、あまり影響がありませんでしたが、従来の単体テストや統合テストでは見つからなかった微妙なエッジケースを特定し修正することができました。 スムーズな移行 DynamoDB が Cassandra と同じ結果を一貫して返していることを検証実験で確認できたため、本番稼働の準備が整いました。MetaaS はデータを 30 日以内しか保持しておらず、それ以降は削除されます( DynamoDB では便利な TTL 機能 を使用)。つまり、Cassandra から過去のデータを移行する必要がありませんでした。両方のデータベースに同じデータが書き込まれていることを確認した後は、2 つのデータベースが同期されるのを待つだけでよかったのです。 テスト環境から始め、徐々に DynamoDB からのみ読み出すクエリに切り替えていきました。見落とされていた可能性のある問題のある動作に関する顧客からの報告がないかを慎重に確認しながら進めました。そのような報告はなく、2023 年 5 月以降、MetaaS へのすべてのクエリが DynamoDB から提供されるようになりました。Heroku は、変更を戻す必要がないことを確認するため、数週間待ちました。 以下の図は、更新されたアーキテクチャを示しています。 結果 1 年以上の運用経験を経て、Heroku はマネージドデータベースサービスの採用を正しい判断であったと確信しました。DynamoDB は信頼性と拡張性に優れています。Heroku は、データベースサーバーのパッチ適用とチューニングに必要な運用負荷を 90% 削減し、当初の目標を達成できました。また、DynamoDB はこれまでの Amazon EC2 上の自社運用 Cassandra クラスターよりも高速かつ低コストであることがわかりました。具体的には、クエリの最大レイテンシーを 75% 削減し、コストを約 50% 削減できました。 例えば、以下のグラフに示されているように、18 時までは Cassandra をクエリしていたため、p99 レイテンシーにかなりの変動が見られましたが、18 時以降は DynamoDB をクエリしているため、そのような変動は見られなくなりました。 教訓 Heroku のサービスは VPC エンドポイント を通じて DynamoDB にアクセスしています。 AWS Identity and Access Management ( IAM )ポリシーを設定し、DynamoDB へのトラフィックが VPC エンドポイントを経由するよう要求することで、VPC 内のアプリケーションがインターネットに露出することなく DynamoDB にアクセスできるようになっています。 Heroku は、Heroku ダッシュボードで顧客がメトリクスを見る頻度によってトラフィックが週の中で変動するため、 DynamoDB Auto Scaling を使って MetaaS テーブルのプロビジョンド読み取りキャパシティを管理しています。一方、書き込みパターンはより予測可能なため、自動スケーリングの最大利用率目標の 90 % を上回るようにテーブルの書き込みキャパシティを手動で設定しています。 ピークがある場合は自動スケーリングが費用削減に効果的ですが、予測可能なワークロードの場合は必要なキャパシティを正確に設定することで、コストを節約できます。 DynamoDB への書き込みは常に最低 1 つの書き込みキャパシティユニット( WCU )を消費しますが、書き込むレコードのサイズに応じて、それ以上の WCU を消費する可能性があります( 1 KB 当たり 1 WCU、最大 400 KB まで)。MetaaS が保存するレコードのほとんどは非常に小さいものの、わずかに 400 KB 制限を超えるものがあることがわかりました。Heroku は、これらの大きなレコードを DynamoDB に書き込む前に gzip で圧縮することで、この問題を解決（また、コストも節約）できました。MetaaS データはそれほど頻繁には照会されないため、圧縮と解凍の CPU 時間コストは、WCU の削減と柔軟なスキーマ変更の利便性に比べて無視できます。 最後に、テスト初期の段階で、DynamoDB への書き込みに予期せぬパフォーマンスボトルネックが発生していました。原因は、DynamoDB SDK で使用されている HTTP クライアントの設定不足でした。高スケールのワークロードの場合、デフォルト設定ではなく、チューニングを行うことが重要です。Heroku は、DynamoDB への同時接続数を増やし、再利用のために維持するアイドル接続数を調整し、デフォルトよりも積極的なタイムアウトとリトライ設定を行うことで、大幅な改善を達成しました。 まとめ このブログ記事では、Heroku がセルフマネージドの Cassandra クラスターから DynamoDB へのインフラストラクチャ移行させた方法について説明しました。Heroku はこの移行を顧客への影響なしに完了し、プラットフォームの信頼性を向上させると同時にコストを削減できました。Heroku は、 EC2 上のセルフマネージド Cassandra から DynamoDB に移行したことで、クラウドインフラストラクチャコストを最大 50 % 削減しました。また、パフォーマンスの改善は、DynamoDB のクエリパフォーマンスがはるかに予測可能になったためです。Cassandra では、ピーク時にレイテンシースパイクが最大約 80 ms に達していましたが、DynamoDB では一貫して 20 ms 未満でクエリが実行されるようになり、顧客へのメトリクス提供遅延が大幅に改善されました。 DynamoDB を使ったハイスケールなワークロードの運用について、他にもヒントや質問はありますか? コメントでお知らせください。DynamoDB の使用を始めるには、 開発者ガイド と AWS DynamoDB コンソール をご覧ください。 このブログ記事は、Heroku と AWS の共同作成で、 Herokuブログ ともにクロスポストされています。 元作者情報 Rielah De JesusはAmazon Web Service のプリンシパルソリューションアーキテクトであり、ワシントンDC、メリーランド、バージニアの多くのエンタープライズ級のお客様のクラウド移行を支援し、成功させてきました。現在のロールではカスタマーアドボケイトおよびテクニカルアドバイザーとして、Salesforceを始めとする複数の組織のAWSプラットフォームでの成功の支援をしています。また、Women in ITの熱心な支持者でもあり、テクノロジーとデータを創造的に活用して日常的な課題を解決する方法を見つけることに情熱を注いでいます。 David Murrayは、Salesforceのソフトウェアアーキテクトで、現在Herokulのバックエンド全般を担当しています。過去には、ネットワーク、データベース、セキュリティ、テクニカルライティングなどの分野を経験してきたほか、 愛猫Sammyについてaws reinventで講演 を行いました。コンピューターのことを考えていないときは、ボートこぎ、自転車乗り、ボードゲームなどを楽しんでいます。

この記事は、“ Enhanced interoperability with SMART on FHIR support in Amazon HealthLake ” を翻訳したものです。 はじめに 2021 年 7 月の開始以来、 Amazon HealthLake は AWS Identity and Access Management (IAM) を通じて安全なアクセスを提供してきました。AWS は最近、 SMART on FHIR 1.0.0 のサポートを含む新しい FHIR API 機能を Amazon HealthLake で発表しました 。SMART on FHIR のサポートにより、HealthLake は FHIR スコープとローンチコンテキストを使用した SMART フレームワークに基づく認可を提供するようになりました。この記事では、Okta を ID プロバイダー (IdP) として使用して、HealthLake で SMART on FHIR を実装する方法について説明します。 患者と医療従事者に健康データへの安全なアクセスを提供するための革新的な取り組みを行う開発者は、さまざまな形式と標準のために複数の課題に直面しています。 ONC Cures Act Final Rule は、医療業界に対し、開発者が医療従事者のワークフローをサポートする新しいアプリケーションを作成し、患者が自身の健康記録にアクセスできるようにする標準の採用を促しています。その標準の 1 つである SMART on FHIR は、開発者が 1 度アプリケーションを作成すれば、医療機関がさまざまな開発者のアプリケーションをテストし、適切なものを見つけられるようにするアーキテクチャ上の解決策を提案しています。「SMART」は Substitutable Medical Applications and Reusable Technologies を意味し、「on FHIR」は Fast Healthcare Interoperability Resources (FHIR) 標準の利用を示しています。 SMART フレームワークの概要 SMART アプリケーションを展開するためのフレームワークは、外部アプリケーションを電子健康記録 (EHR) システムに接続する上で重要な役割を果たします。このフレームワークにより、EHR システムの内外でアプリケーションを起動できるようになります。このフレームワークは、医師、患者、その他の個人やシステムが FHIR API を使用して設計されたさまざまなアプリケーションをサポートしています。ユーザーは、アプリケーションに自分の健康データへのアクセス権を付与できるため、アプリケーションがエンドユーザーデバイスやサーバー上で実行されているかどうかに関係なく、さまざまなアーキテクチャ構成で安全で信頼できるプロトコルが保証されます。 SMART on FHIR 1.0.0 には、以下の 4 つのユースケースが含まれています。 独立して起動できるスタンドアロンの患者向けアプリケーション。 EHR ポータルから起動できる患者向けアプリケーション。 独立して起動できるスタンドアロンの医療従事者向けアプリケーション。 EHR ポータルから起動できる医療従事者向けアプリケーション。 SMART 認証と FHIR アクセス 次の図は、FHIR リソースサーバーとして HealthLake を利用する SMART on FHIR アプリケーションのスタンドアロンの起動とアクセス許可のステップを示しています。これらのステップとワークフローを詳しく見ていきましょう。 ステップ 1: アプリケーションが認証を要求します SMART on FHIR クライアントアプリケーションは、FHIR リソースへのアクセスを認可するために、起動時に ID 情報なしで HTTP GET リクエストを FHIR サーバーの SMART 構成メタデータ [base]/.well-known/smart-configuration の検出 URL に送信します。この構成メタデータには、OAuth の authorization_endpoint と token_endpoint の URL が含まれています。その後、アプリケーションは、FHIR サーバーが「認可」に使用するエンドポイント URL のクエリコンポーネントに以下のパラメータを追加して、認可リクエストを作成します。 response_type: これは固定値です – code client_id: クライアントの識別子です redirect_uri: 登録済みクライアントが持つリダイレクト URI のいずれかと一致する必要があります launch: EHR 起動フローを使用する場合、EHR から受け取った起動値と一致する必要があります。これはスタンドアロンの起動ワークフローでは必須ではないオプションのパラメータです scope: アプリが必要とするアクセスを記述する必要があり、臨床、コンテキスト、ID データのスコープを含む必要があります SMART アプリケーションの起動フレームワーク IG で説明されているように、データのスコープは次のように形成されます。 最も一般的に使用されるスコープの例は次のとおりです。 patient/*.read – 現在の患者に関連するリソースを読み取る権限 user/*.* – 現在のユーザーがアクセスできるすべてのリソースを読み書きする権限 他に一般的に使用される医療以外のスコープは以下の通りです。 launch – EHR から起動されたアプリのコンテキストを取得する権限 launch/patient – EHR 外からアプリが起動され、患者のコンテキストが必要な場合、認証サーバーから選択する患者のリストが提供される offline_access – アクセストークンの有効期限が切れた後、オフラインの場合でも、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する online_access – ユーザーがオンラインの場合に、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する state : リクエストとコールバック間の状態を維持するために使用される不透明な値 aud : これは「対象者」を指し、アプリがデータを取得する FHIR リソースサーバーの URL です。 ステップ 2: 認可リクエストを評価する 認可プロセスは認可サーバーに依存し、サーバーはユーザーに許可を求めることができます。その後、サーバーはクライアント ID、設定されたポリシー、時にはユーザーの入力などの要因に基づいて、アクセスを許可するか拒否するかを決定します。アプリケーションは、認可サーバーから認可コードが送り返された場合、またはアクセスが拒否された場合はエラーレスポンスが送り返された場合に、この決定を受け取ります。 ステップ 3: 認可コードをアクセストークンと交換する アプリケーションが認証コードを取得すると、そのコードをアクセストークンと交換する処理に進みます。この交換は、EHR 認証サーバーのトークン URL エンドポイントに対して HTTP POST リクエストを行うことで実現します。その際、コンテンツタイプとして application/x-www-form-urlencoded. を使用します。 ステップ 4: FHIR API を通じた医療データへのアクセス アプリケーションが有効なアクセストークンを取得すると、FHIR サーバーのエンドポイントに FHIR API 呼び出しを行うことで、データを取得する機能を持ちます。API リクエストには、アクセストークンを “Bearer” トークンとして次の形式で含む認証ヘッダーが含まれています: Authorization: Bearer {{access_token}}. ここで、プレースホルダー {{access_token}} は、前のステップで取得した実際のトークン値に置き換えられます。 ステップ 5: リフレッシュトークン アプリケーションはリフレッシュトークンを使用して新しいトークンを取得します。リフレッシュトークンは、アクセストークンの有効期間よりも長いセッションを許可するために発行されます。 Amazon HealthLake 上の SMART on FHIR の実装例 SMART on FHIR を定義する仕様と標準について説明したので、次は Okta を ID プロバイダー (IdP) として使用して HealthLake で実装する方法を示します。HealthLake では他の OAuth 2.0 IdP を使用することもできることに注意してください。 Amazon HealthLake での SMART アクセスの設定 ステップ 1: サードパーティの認可サーバーをセットアップし、’well-known’ 構成を取得する 認可サーバーは若干の違いがあるかもしれませんが、認可サーバーから ‘well-known’ 構成からベース URI と十分なメタデータを取得することが重要です。次の Okta のスクリーンショットは、Okta IDP のメタデータ URI を含むデフォルトの認可サーバー構成を示しています。 ID プロバイダーからのメタデータ情報には、認可エンドポイント、トークンエンドポイント、サポートされる付与タイプとスコープなどの詳細が含まれています。この情報は、次のセクションで強調されているように、SMART 機能を持つ HealthLake データストアを作成する際に使用されます。 ステップ 2: HealthLake と Auth Server 間の通信を確立する SMART on FHIR サポートを備えた Amazon HealthLake データストアを作成する際は、特定のクレームを返す AWS Lambda 関数の ARN と、FHIR API リクエストを実行するための許可を持つ IAM サービスロールを指定する必要があります。Lambda 関数の作成の詳細については、 Amazon HealthLake 開発者ガイド を参照してください。この Lambda 関数は、FHIR API リクエストに応答して、Amazon HealthLake サービスに必要な要素を返します。 次の図は、SMART on FHIR アプリケーション、IDP、Amazon HealthLake、Lambda 関数間の通信を示しています。 ステップ 3: HealthLake データストアの作成時に IdP 構成を保存する HealthLake データストアの所有者が決定します FHIR 相互作用に関連付けられた IAM ロール 復号化とトークン検証方法 (ローカル検証または ID プロバイダーとのトークン検査) と ID プロバイダーの構成。検査 Lambda 関数を作成した後、ユーザーは IdentityProviderConfiguration を格納する機能が強化された create data store API を呼び出すことができます。このパラメータは、認可戦略、検出 API メタデータを構成し、細かい認可を有効にします。この構成は新しいデータストアを作成する際にのみ利用可能で、既存のデータストアでは有効にできないことに注意してください。さらに、この構成はコマンドラインインターフェイス (CLI) とソフトウェア開発キット (SDK) からのみアクセス可能で、コンソールからはアクセスできません。 この新しい CreateFHIRDatastoreRequest の構造では、新しいデータストアを作成する際に IdentityProviderConfiguration がオプションのパラメータとなっています。 この構成では、次のフィールドを受け入れます。 AuthorizationStrategy : SMART 認証の場合は SMART_on_FHIR_V1 、非 SMART 認証の場合は AWSAuth を指定してください。値が SMART_on_FHIR_V1 の場合、以下のすべてのフィールドが必須になります。 FineGrainedAuthorizationEnabled : 細かい権限管理を HealthLake で行いたい場合は true 、そうでない場合は false を選択してください。 Metadata – 検出 API リクエストコールを受信したときに返される認証サーバーのメタデータを格納します。 SmartConfigurationMetadata は、 FHIR 仕様 に示されているものと同様の JSON オブジェクトで、authorization_endpoint と token_endpoint が含まれています。 IDPLambdaARN : トークン検証を行うカスタム Lambda の ARN です。 これらの設定を完了すると、HealthLake は SMART アプリケーションから送信された”Bearer” トークンをデコードできるようになり、それらのリクエストに対して認証と承認を実行できるようになります。 Amazon HealthLake の SMART on FHIR サポートの主要機能とメリット 適用性と柔軟性: ヘルスケアプロバイダーは、シームレスにサードパーティのアプリケーションを既存のシステムに統合できるようになります。これにより、臨床ワークフローのカスタマイズと拡張が可能になり、効率性と使いやすさが向上します。 患者中心のケア: HealthLake の SMART on FHIR サポートにより、患者は自身の健康データに安全にアクセスし、患者向けアプリケーションと対話できるようになります。これにより、患者の積極的な関与、エンパワーメント、健康状態の自己管理が促進されます。 相互運用性の向上: FHIR 標準データ形式を活用することで、SMART on FHIR は異なるシステム間で構造化された健康データを交換できるようになり、互換性と一貫性が確保されます。これにより、効率的なケアの調整、研究、集団健康管理が促進されます。 開発者に優しい環境: SMART オープンソースプラットフォームは、イノベーションを促進し、新しいヘルスケアソリューションの創出を奨励します。 結論 SMART on FHIR は、医療の相互運用性に変革をもたらすアプローチで、医療従事者、開発者、患者を同様に力づけます。アプリケーションをシームレスに統合し、ケアの調整を強化し、患者の関与を促進する機能により、SMART on FHIR は医療分野のデジタル変革を可能にする重要な要素となります。Amazon HealthLake がこの標準をサポートすることで、相互運用性、イノベーション、そして最終的には患者の良好なアウトカムを実現します。Amazon HealthLake を使い始め、健康データを数分で安全に保存、変換、トランザクション、分析する方法の詳細を知るには、以下の過去のブログをご覧ください。 Amazon HealthLake に関する過去のブログへのリンク Amazon HealthLake を使用して患者データの洞察を解き放つ 新しい Amazon HealthLake の機能により、次世代のイメージングソリューションと精密健康分析が可能に Amazon HealthLake の新しい FHIR API 機能により、お客様はデータ交換を加速し、ONC と CMS の相互運用性とパティエントアクセスルールを満たすことができます <!-- '"` --> TAGS: Amazon HealthLake , AWS Lamda , comprehend medical Yogesh Dhimate Yogesh DhimateはAWSのシニアパートナーソリューションアーキテクトです。Yogesh は、グローバルなヘルスケア分野のISV（独立系ソフトウェアベンダー）がAWS上で相互運用性ソリューションを構築することをサポートしています。AWSに入社する前は、MuleSoft（現Salesforce）でヘルスケア業界向けソリューションのテクニカルリーダーおよびプロダクトマネージャーとして働いていました。 Bakha Nurzhanov Bakha NurzhanovはAWSのインターオペラビリティ・ソリューションアーキテクトであり、ヘルスケアの相互運用性とイノベーションの技術リーダーです。Bakha は、グローバルなヘルスケア顧客をサポートし、グローバル技術チームにおけるヘルスケアの相互運用性に関する専門知識を深め、ヘルスケアイノベーションの開発をリードしています。AWSに入社する前は、様々なヘルスケアプロバイダー組織において、20年以上にわたりインテグレーションアーキテクトおよび開発者として働いていました。 Mirza Baig Mirza Baig はヘルスAI分野のプリンシパルソリューションアーキテクトで、主にヘルスAIソリューションの採用促進に注力しています。アマゾンに入社する前は、エンビジョン・ヘルスケア、シスコ、米国大統領府などの大規模組織で、ソフトウェア開発、データ基盤、サイバーセキュリティ、ネットワークエンジニアリングにおける技術職およびリーダーシップの役割を担っていました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

このブログは、 How to expansively train Robot Learning by Customers on AWS using functions generated by Large Language Models を翻訳したのものです。 ロボット工学業界では、 強化学習 (RL) が、伝統的な経路計画アルゴリズムでは処理できない複雑な問題、特に複雑な操作を伴う問題に広く利用されています。RL における報酬関数は、目的を設定しエージェントの学習プロセスに指示を与える重要な要素です。効果的な報酬関数を作成することは難しいですが RL エージェントが適切に動作するためには不可欠です。 Eureka は、NVIDIA の研究者による大規模言語モデル (LLM) を使用して、報酬関数を手作業で設計するのではなく、洗練された報酬関数を生成する素晴らしいプロジェクトです。強化学習の業界では、報酬関数の作成は試行錯誤のプロセスのままです。ロボット工学者は報酬関数を自動的に生成および改良する方法を求めています。 このテーマの画期的な成果である Eureka は、難しい問題を解決するための一種の自動化を提供します。 Eureka の研究論文 によると、LLM によって生成された報酬関数は、全体で 50 % のパフォーマンス向上があり、タスクの 80 % 以上で人手による報酬関数設計を上回ります。 このブログ記事では、Nvidia の Eureka を Amazon Web Services (AWS) 上で実行し、Amazon Bedrock for LLMs を使用する方法を説明します。ロボット学習のプロセスをオンプレミスのトレーニングインスタンスから AWS に移行する際、エンジニアが対処する必要のある課題がいくつかあります。 シミュレーション/トレーニングプロセスを複数のノードに分散してスケーリングし、トレーニングプロセスを加速させ、コストを節約します。 クラウド上でロボットのシミュレーション/トレーニングプロセスを可視化し、エンジニアが参加できるようにすることで、タスク効率を向上させます。 Amazon Bedrock の LLM を使用して、報酬関数を生成します。 ソリューションの概要 このブログ記事では、ロボット業界の顧客が上記の課題を解決するために AWS が提案するソリューションの 1 つについて説明します。このソリューションでは、以下のツールを使用します。 自動運転データフレームワーク (Autonomous Driving Data Framework: ADDF) は、AWS の自動車チームが再利用可能でモジュール化された汎用コード資産を提供することを目的としたオープンソースプロジェクトです。ADDF はデータ処理、シグナル抽出、シーン検出、シミュレーション、データ可視化用のモジュールを提供しています。この記事では、このプロジェクトをロボット業界でどのように活用できるかを示します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、コンテナ のスケジューリング、アプリケーション可用性の管理、クラスターデータの保管を行う Kubernetes コントロールプレーンノードの可用性とスケーラビリティを AWS が管理する、マネージド型の Kubernetes サービスです。この記事では、EKS 上でロボットの学習とシミュレーションを行います。 NICE DCV は、お客様にリモートデスクトップとアプリケーションストリーミングを安全に提供する高性能のリモートディスプレイプロトコルです。この記事では、EKS 上で行われるロボットシミュレーションと学習プロセスを DCV でストリーミングする方法を示します。 このソリューションは次のように設計されます: 図 1: ソリューションの高レベル設計 この画像では、このデザインのアーキテクチャを示しています。まず、コードとトレーニングアーティファクトを Amazon S3 バケットにデプロイします。Amazon DataSync が、コードとアーティファクトを Amazon EKS クラスター内のポッドにマウントされる Amazon FSx と同期します。 Amazon EKS 側では、トレーニング/シミュレーションのために イベント駆動型アーキテクチャ を採用しています。シミュレーション/トレーニングのワークロードは、ワーカーポッドで実行されます。これらのワーカーポッドはステートレスです。タスクコントローラーポッドは、タスクに基づいてトレーニング/シミュレーションのワークロード定義を生成する責任があります。ワーカーにワークロードをスケジュールするために、 Amazon Simple Queue Service (Amazon SQS) を使用しています。各タスクコントローラーは、1 つのトレーニングジョブのシミュレーションとトレーニングを制御します。 タスクコントローラーは、選択された LLM からさまざまな報酬関数をサンプリングするサービスを提供する Amazon Bedrock とも通信します。一方、ユーザーは DCV モジュールを介してシミュレーションを視覚化および操作できます。ADDF では、インフラストラクチャを簡単に設定できます。ADDF は、Amazon EKS、DCV コンポーネント、この特別なプロジェクト向けの他の AWS リソースなど、必要なモジュールをデプロイします。 ローカル開発環境での前提条件は以下の通りです: Python 3.8 以上のバージョン git CLI AWS 認証情報 AWS CLI aws-cdk CLI バージョン 2.20.0 以上 kubectl CLI バージョン 1.29 以上 Amazon EKS クラスターのセットアップ この項では、インフラストラクチャのセットアップに焦点を当てます。以前別のプロジェクトで ADDF を使用したことがある場合は、該当する手順を飛ばしてください。 ステップ 1: ADDF リポジトリをローカルディレクトリに clone します。 現在、複数のリリースがあります。この記事執筆時の最新バージョンは release/3.5.0 を使用することをおすすめします。 git clone --origin upstream --branch release/3.5.0 https://github.com/awslabs/autonomous-driving-data-framework.git ステップ 2: Python の仮想環境を作成し、依存関係をインストールする cd autonomous-driving-data-framework python3 -m venv .venv &amp;&amp; source .venv/bin/activate pip3 install -r requirements.txt 今度は、アカウントに対する有効な AWS 認証情報があることを確認してください。アカウントの bootstrapping に必要になります。以下のコマンドで &lt;REGION&gt; と &lt;ACCOUNT_ID&gt; と &lt;ROLE_NAME&gt; を置き換えてください: export AWS_DEFAULT_REGION = cdk bootstrap aws:/// Step 3: Deploy Amazon EKS Cluster and DCV modules. このステップでは、セットアップに必要なモジュールをデプロイします。以下のものがデプロイされます： Amazon FSx for Lustre : これは Amazon EKS 上の Pod にマウントされます。また、S3 バケットから Amazon FSx へのデータ同期を設定します。これとデータ同期をデプロイするには、次のモジュール定義が必要です。Amazon FSx の定義は manifests/robotic-training-on-eks/storage.yaml に定義されています。 eureka モジュールにも、K8S リソースとして Amazon FSx ストレージクラスがデプロイされます。依存関係のあるモジュールでは、Amazon FSx が作成されます。また、追加の Amazon FSx K8S リソースをデプロイし、Amazon FSx を Pod にマウントできるようにします。 Amazon ECR : これはロボット学習/シミュレーション画像を格納するために使用されます。 Amazon S3 バケット: このバケットはデータストアとして使用されます。学習データ、学習出力、コードをこのバケットに保存します。 Amazon EKS: これは、学習/シミュレーション Pod をスケジューリングするためのフレームワークとなります。この例では、少なくとも 2 つの g5.2xlarge インスタンスをデプロイします。 NICE DCV イメージと Kubernetes (K8S) リソース: DCV に関連する 3 つのモジュールがあります。1 つは DCV サーバーイメージを格納する ECR を作成し、もう 1 つは DCV イメージを作成し、最後のモジュールは K8S リソース (DaemonSet、ClusterRole、ClusterBinding など) を作成します。これらのモジュールはそのままの状態で構いません。設定の更新は必要ありません。 dcv-eks モジュールの README を確認してください。DCV サーバー用のシークレットを設定する必要があります。 次のコマンドを実行して、ADDF モジュール全てをデプロイできます: seedfarmer apply manifests/robotic-training-on-eks/deployment.yaml 次のような出力が正常にデプロイされた場合に表示されます: 図 2: デプロイされる ADDF モジュール ステップ 4: Kubectl とクレデンシャルをセットアップ。 ステップ 3 で Amazon EKS クラスターをデプロイしました。この ブログ記事の範囲では、 kubectl コマンドを使用して Amazon EKS でアプリケーションを実行する必要があります。 このリンク に従い、バージョン 2.29 の kubectl クライアントをインストールしてください。 モジュールがデプロイ済みであれば、すべてのリソースが Amazon CloudFormation のスタックとして存在します。AWS コンソールから Amazon CloudFormation サービスに移動し、 addf-robotic-training-on-eks-core-eks という名前のスタックを探して選択し、出力を参照すると、次の図のように clusterConfigCommand が表示されます。 Figure 3: Amazon EKS Cloud Formation Stack Output 次に、 clusterConfigCommand の値をターミナルにコピーして実行してください。資格情報は適切に更新されます。次のコマンドを実行して K8s クライアントを検証できます: kubectl get svc 出力は次のようになります。 NAME &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLUSTER-IP &nbsp;&nbsp; EXTERNAL-IP &nbsp;&nbsp; PORT(S)&nbsp;&nbsp; AGE kubernetes &nbsp;&nbsp; ClusterIP &nbsp;&nbsp; 172.20.0.1 &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 443/TCP &nbsp;&nbsp; 177m ステップ 5: GPU オペレータをインストールする。 ステップ 3 で GPU 対応ノードを持つ Amazon EKS クラスターを設定したはずです。ADDF EKS モジュールは、GPU ドライバーが事前にインストールされたインスタンスを起動します。ただし、GPU リソースを必要とする K8s ワークフローをスケジュールするには、クラスターに GPU オペレータプラグイン をインストールする必要があります。GPU オペレータは、K8S 内のすべての NVIDIA GPU リソースを自動的に処理します。この手順で、GPU 関連のワークロードに NVIDIA GPU オペレータをインストールします。ステップ 5.1 と 5.3 はオプションです。これらの追加機能を利用したい場合は、 このリンク の下にある必要なファイルがあります。 (オプション) DCGM メトリクス パブリッシャー をインストールします。 これは GPU の利用状況など GPU 関連のメトリクスを公開するための、GPU オペレーターのオプションのステップです。 kubectl create namespace gpu-operator curl https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/main/etc/dcp-metrics-included.csv &gt; dcgm-metrics.csv kubectl create configmap metrics-config -n gpu-operator --from-file = dcgm-metrics.csv ステップ 5.2 (必須) GPU オペレータをインストールします。 ステップ 5.1 をスキップした場合、次のコマンドでは DCGM 関連のフラグ (次のコマンドの太字部分) を設定する必要はありません。 # run command in bash bash -c "helm install --wait --generate-name \ -n gpu-operator \ nvidia/gpu-operator \ --set driver.enabled = false \ --set toolkit.version = v1.14.4-ubi8 \ --set dcgmExporter.config.name = metrics-config \ --set dcgmExporter.env[0].name = DCGM_EXPORTER_COLLECTORS \ --set dcgmExporter.env[0].value =/etc/dcgm-exporter/dcgm-metrics.csv" # Validate installation by checking out whether all the pods in namespace gpu-operator are Running or Completed kubectl get pods -o wide -n gpu-operator GPU ドライバのインストールは ADDF EKS モジュールによってデプロイされた K8S ノードグループの AMI に既にインストール済みのため、GPU オペレータでは無効化されていることに注意してください。 今のところ、稼働可能な Amazon EKS クラスターが準備できています。 ロボット訓練とシミュレーション Isaac Gym デモンストレーション シミュレーション環境のセットアップ ADDF リポジトリのさまざまなモジュールと GPU Operator のデプロイが成功したら、シミュレーション/トレーニングのワークロードのデプロイを開始できます。 このブログ記事では、Eureka コントローラーポッドとトレーニングポッドをデプロイします。すべてのアプリケーションポッドは kubectl を使って手動でデプロイされます。各トレーニングタスクに対して、1 つのコントローラーポッドがあります。このブログの範囲では、shadow-hand タスクを実演します。異なるユースケースでテストしたい場合は、別のコントローラーポッドをデプロイできます。トレーニングポッドは K8s のデプロイメントとしてスピンアップします。トレーニングポッドの数は、各ノードで使用可能な GPU 数などのリソース制限によって制限されます。 上記のセクションに記載した方法でモジュールをデプロイすると、eureka モジュールが必要なすべての出力を保存します。具体的には、次の 3 つの項目が出力されます。 1. IamRoleArn: これはユーザーがクラウド上でシミュレーション/学習を実行するために作成された役割です。以下の権限が含まれています: a. Amazon FSx の読み取り/書き込み b. Amazon S3 バケットの読み取り/書き込み c. Amazon SQS の読み書き d. Amazon Bedrock の権限。 e. Amazon EKS クラスターのサービスアカウントがこのロールを引き受けるための信頼関係 2. ApplicationImageUri: このモジュールでは、基本ライブラリを含む ECR イメージを公開します。この実演では、このブログ記事内のすべての使用に対して 1 つの単一のイメージを再利用します。 3. SqsUrl: このモジュールは、Amazon SQS メッセージキューも作成します。コントローラーがエンキューし、ワーカーはシミュレーション/トレーニングの目的でデキューします。 ステップ 1: アーティファクトを S3 にアップロードする 。このステップでは、前に作成した S3 バケットに次のファイルをアップロードします。Amazon Datasync を利用しているので、ファイルをアップロードした後、データは自動的に Amazon S3 から Amazon FSx に同期されます。Amazon FSx をポッドにマウントすれば、すべてのポッドが共通の外部ドライブを共有できます。 Eureka: これは元の Eureka から フォークされたライブラリ です。複数のノードにシミュレーションをデプロイしてスケーラビリティを持たせることを目的としています。 IssacGym: この リンク から IssacGym Preview 4 にアクセスしてください。IssacGym をダウンロードするリンクが表示されます。次のコマンドで &lt;LINK_TO_DOWNLOAD_ISSACGYM&gt; をダウンロード用の正しいリンクに置き換えてください。 Fbx Fix Patch: これは FBX モジュールのエラーを修正するホットパッチです。Adobe は公式に Fbx Python をサポートしていないため、Fbx を実行するにはこのパッチを当てる必要があります。 BUCKET は ADDF モジュールで作成したデータバケットです。 mkdir robotic_data &amp;&amp; cd robotic_data # Get Eureka for distributed simulation git clone https://github.com/sauronalexander/Eureka.git # Get IssacGym wget tar -xvf IssacGym_Preview_4_Package.tar.gz rm IssacGym_Preview_4_Package.tar.gz # Get Fbx fix patch git clone https://github.com/Shiiho11/FBX-Python-SDK-for-Python3.x.git mv FBX-Python-SDK-for-Python3.x/2020.0.1_3.8.3_x64/FbxCommon.py ./ mv FBX-Python-SDK-for-Python3.x/2020.0.1_3.8.3_x64 ./fbx rm -rf FBX-Python-SDK-for-Python3.x # Upload files to s3 aws s3 sync ./* s3:// --recursive これからは、ローカルの Python スクリプトを編集し、コードを S3 と同期できます。コード成果物はすぐにすべての Pod から参照可能になります。もう 1 つの手法は、コードをイメージにビルドインすることです。この記事の単純化のため、コード変更の度にイメージのリビルドは行いません。 ステップ 2: Python Anaconda 環境をセットアップします。 このステップでは、必要な Python ライブラリをインストールします。IssacGym などの依存関係パッケージのインストールには、Nvidia ドライバが準備されている必要があります。このステップでは、環境をセットアップするために、各ノードに 1 つの Pod をデプロイします。各 Pod では、ホストノード内のディレクトリを使用するローカルマウントを確立します。この Pod は、Nvidia GPU ドライバをチェックアウトし、Anaconda 環境を共有ディレクトリにあらかじめインストールします。このセットアップが完了すると、ワーカー Pod とコントローラー Pod は、シミュレーション/トレーニングのワークロードを実行するために、この Anaconda 環境を再利用します。これにより、環境のセットアップ時間が大幅に節約されます。 anaconda_setup.yaml 内の画像 URI とロール ARN を、前のステップで作成した適切な画像 URI と IAM ロール (以下の太字の部分を参照) に置き換えてください。 apiVersion: v1 kind: ServiceAccount metadata: name: aws-s3-access annotations: eks.amazonaws.com/role-arn: automountServiceAccountToken: true --- apiVersion: apps/v1 kind: DaemonSet metadata: name: anaconda-daemonset labels: app: anaconda-setup spec: selector: matchLabels: app: anaconda-setup template: metadata: labels: app: anaconda-setup spec: terminationGracePeriodSeconds: 30 # Set the termination grace period serviceAccountName: aws-s3-access automountServiceAccountToken: true containers: - name: anaconda-setup-container image: resources: limits: nvidia.com/gpu: 1 # requesting 3 GPU, 1 shared gpu is 3GB in g5 … # Wait for around 10 minutes until the setup is complete. You can verify the setup to be completed by check if the conda setup pods are ready watch -n 5 kubectl get pods # When it is ready, you can delete the pods kubectl delete -f anaconda_setup.yaml ステップ 3: LLM アクセスを設定する この プロジェクトでは、LLM を使って報酬関数を生成できることを示します。私たちの実装では、Anthropic の Claude 3 (Amazon Bedrock 上) と OpenAI の ChatGPT の 2 つの LLM ファミリをサポートします。 ステップ 3.1: Claude 3 へのアクセスを設定する AWS コンソール (リージョン us-east-1 または us-west-2) で Amazon Bedrock に移動してください。Amazon Bedrock LLM には一部の特定のリージョンでのみアクセスできます。 左側のパネルで「Model Access」を選択します。 使用するモデルをチェックしてください。Claude 3 モデル (Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus、および Claude 3.5 Sonnet) のみがサポートされています。 「Save」をクリックすると、Python で Claude 3 モデルを操作できるようになります。 ステップ 3.2: ChatGPT アクセスの設定 OpenAPI API キーを取得する この API キーを管理し、コントローラーポッドを Amazon EKS クラスターにデプロイする際、環境変数として使用できます。 デモンストレーション – シミュレーション/トレーニングの実行 次に、 eureka.yaml に記載されている Eureka アプリケーションをデプロイできます。 必要に応じて、以下を置き換えてください。 イメージ URI: 前のセクションで展開したモジュールでは、Amazon ECR の 1 つに Ubuntu イメージを公開します。イメージ URI は eureka モジュールの出力名 &lt;ApplicationImageUri&gt; になります。 EUREKA_TRAINING_QUEUE_URL: ADDF モジュールで作成した &lt;SqsUrl&gt; に置き換えてください。 OPENAI_API_KEY: ステップ 3.2 で取得したキーに置き換えてください。Claude 3 を使用する場合はこのステップを省略できます。 AWS_REGION: デプロイする予定のリージョン &lt;REGION&gt; に置き換えてください。 EUREKA_ENV: 学習に使用するタスク名です。 EUREKA_SAMPLE: LLM から生成される報酬関数のサンプル数です。各反復で並列に評価されます。 EUREKA_MAX_ITERATIONS: LLM から生成された報酬が評価される最大反復回数です。 EUREKA_NUM_VAL: 最終評価ラウンド数 (20000 回の反復) で、並列に実行できる数です。 上記の設定を変更した後は、次のコマンドを使用してポッドをデプロイできます。この例では、 shadow-hand タスクを実行します。コントローラーのポッドは shadow-hand という名前です。 kubectl apply -f eureka.yaml # You can check the progress using kubectl logs shadow-hand --follow ノート: タスクごとに 1 つの controller pod をデプロイできます (これは EUREKA_ENV で定義されます)。一方で、controller では複数のタスクを並列でデプロイできます。 ロボットシミュレーション/トレーニングの視覚化を DCV で行うデモンストレーション Figure 3: Application Streaming Architecture in EKS このセクションでは、DCV サーバーを使用してシミュレーションとトレーニングをストリーミングする方法を説明します。DCV をストリーミングするための全体的なアーキテクチャは以下のようになります。 DCV コンポーネントは、Amazon EKS クラスターへの DaemonSet としてデプロイされます。つまり、ノードごとに 1 つの DCV Pod が存在します。アプリケーション Pod、あるいは私たちのユースケースではワーカー Pod は全て、DCV Pod との間でディレクトリを共有します。DCV Pod はそのディレクトリに X11 ディスプレイソケットを作成し、ワーカー Pod はそのソケットを通じて DCV Pod 内の DCV サーバにアプリケーションをレンダリングできます。ワーカー Pod 内で実行される IssacGym は X11 ソケット上にレンダリングされます。次に、DCV サーバはユーザ接続を受け入れ、リモートデスクトップ上に IssacGym を表示します。パブリックの Amazon サブネットでは、NodePort サービスを使用できます。このブログ記事の範囲では、プライベートサブネットを使用します。次の接続方法は、プライベートサブネットとパブリックサブネットの両方で使用できます。 K8S ポートフォワーディングを使用して接続します。次のコマンドを使用できます: # First, determine which worker pod you want to connect to by running: kubectl get pods # Next, run the following command to forward the traffic kubectl port-forward $(kubectl get pods -n dcv --field-selector spec.nodeName =$(kubectl get pod -o = jsonpath ='{.spec.nodeName }') -o jsonpath ='{ range .items[ * ] }{.metadata.name }{"\n"}{ end }') -n dcv 9999:8443 上記のコマンドは、指定されたワーカー Pod が実行されているノードを見つけます。次に、そのノードで実行されている DCV Pod の名前を見つけます。そして、DCV サーバーがリッスンしているポート 8443 を、ローカルホストのポート 9999 にフォワードします。 ブラウザから https://localhost:9999 にアクセスできます。DCV サーバーからユーザー名とクレデンシャルの入力を求めるプロンプトが表示されます。 Figure 4: DCV Login Page in Web Browser DCV モジュールのセットアップで設定したユーザー名/パスワードを入力してください。次に、DCV サーバーに接続できるはずです。シミュレーションが画面に表示されるはずです。 Figure 5: Training shadow-hand in multiple pods クリーンアップ アプリケーションの Pod を削除するには、次のコマンドを実行できます: kubectl delete -f eureka.yaml このデプロイデモのモジュールを破棄するには、次のコマンドを実行できます。 seedfarmer destroy manifests/robotic-training-on-eks/deployment.yaml まとめ このブログ投稿では、Amazon EKS、Amazon FSx for Lustre、Amazon ECR、そして NICE DCV などの Amazon サービスを使用して、Nvidia の Eureka と Isaac Gym を使ってスケーラブルなロボット研修パイプラインを構築する方法を説明しました。また、ADDF を使ってインフラストラクチャを構成し、GPU オペレーターをインストール、IAM ロールを作成、コントローラーとワーカーの Pod をデプロイする方法も示しました。 さらに、AWS Bedrock の Claude 3 のような LLM を強化学習タスクの報酬関数生成に統合する方法も示しました。最後に、NICE DCV リモートデスクトップを使ってロボットのシミュレーションを視覚化するストリーミングする方法をご紹介しました。このソリューションは、ロボット開発チームが AWS 上で最新の AI モデルを使った報酬モデリングを活用し、より効果的に協業しながら研修を加速できるように設計されています。 オープンソースの ADDF プロジェクトは、このようなロボットの学習パイプラインをすばやくプロトタイピングできるようインフラストラクチャをコードとして再利用できるよう設計されています。 今後の課題として、このフレームワークで学習したポリシーを実際のロボットに移行することを検討しています。このフレームワークを活用すれば、実世界で高度な操作作業を行うためにロボットを訓練することも可能だと考えています。 AWS の自動車向け製品サービスについて詳しくは AWS for automotive ページ をご覧ください。または、 お問い合わせ ください。 参照 AWS の自動運転データフレームワーク (ADDF) を使用してカスタマイズされたワークフローを開発・デプロイ このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。

本ブログは、株式会社ユビタスと Amazon Web Services Japan が共同で執筆いたしました。 株式会社ユビタス は、NVIDIA の投資を受けたテクノロジー企業で、世界有数の GPU 仮想化とクラウドストリーミング技術を有しています。クラウドと AI 分野での最高のサービスを提供することを目指しています。ユビタスは、台湾大学や東京大学などの著名大学と協力し、繁体字・日本語の大規模言語モデル（LLM）を学習させるほか、AI キャラクターソリューション「 UbiONE 」を立ち上げ、ブランドキャラクター「 AI Vtuber: Ubi-chan 」を発表するなど、生成 AI の分野でイノベーションと実用化を行っています。 課題 UbiONE は、金融や医療など様々な業界向けにカスタマイズされた対話型 AI キャラクターソリューションになります。各業界には固有の要件があり、それに対応する対話機能とフロントエンド・バックエンドの構築が求められていました。しかし、従来の開発アプローチでは、このカスタマイズ作業に多大な労力とリソースを要していました。 検証内容 そこで、LLM の開発を加速するため、 Amazon EC2 P5 インスタンスと AWS ParallelCluster を活用した検証を行いました。まず 16 台の NVIDIA H100 GPU 搭載 Amazon EC2 P5 インスタンスで 1 ヶ月間の事前学習を実施し、高性能なクラウド計算環境を構築できました。その結果、深層学習とAIモデルのトレーニングスピードが大幅に向上しました。 次に、AWS の技術支援を受けながら AWS ParallelCluster を導入しました。この優れたクラスタ管理ツールにより、計算リソースの使い勝手が格段に改善され、学習時間が従来比で 90% 短縮されました。さらに Slurm システムを活用してリソース割り当てと管理を最適化することで、効率的なリソース活用を実現しています。 フロントエンド環境では、 Amazon S3 、 Amazon CloudFront 、 Amazon EKS 、 Elastic Load Balancing などの AWS サービスを組み合わせてアプリケーションとサービスをサポートしています。これらのサービスにより、ストレージ、トラフィック分散、動的プロビジョニングが可能になり、複数のカスタマイズされた AI キャラクターバージョンを高速に構築・管理し、効率的に展開および更新することができます。 検証結果 その結果として、従来の開発プロセスに比べて大幅な作業量の削減と開発効率の向上をもたらすことが確認できました。さらに、AWS のスケーラブルなクラウドインフラストラクチャを活用することで、様々な業界のお客様の要件を的確に満たすカスタマイズされた AI キャラクターを柔軟に提供できることが実証されました。 今後の展望 今後もユビタスは AWS が提供する先進的なクラウドサービスを積極的に活用し、プロダクト開発のさらなる効率化、機能拡張、精度向上を図っていく方針です。 幅広い観点からは、UbiONE を金融や医療に留まらず、さまざまな業界への展開を視野に入れています。各業界の専門知識を AI モデルに取り込むことで、高度な対話機能を備えた特化ソリューションの開発を図っていく予定です。 一方で深さの面でも、対話エンジンの高度化や API 機能の拡充、ユーザーインターフェースの改善など、リッチでシームレスなユーザー体験を実現するための継続的な開発投資を行っていく予定です。 まとめ 今回の検証を通して、Amazon EC2 P5 と AWS ParallelCluster の組み合わせが AI モデル開発の大幅な効率化に有効であることが確認できました。さらに、Amazon S3、Amazon CloudFront、Amazon EKS、Elastic Load Balancing を活用したサービスのプロビジョニングにより、AI における競争力が一層高まりました。ユビタスは引き続き AWS の技術を活用し、革新的な AI ソリューションの提供に注力していきます。

私が、 Amazon プライムデー のセールよりもワクワクすると思うものは何でしょうか? Amazon Web Services (AWS) がどのようにしてすべてを実現させたのかについて、学ぶことです。毎年、 Jeff Barr の年次投稿で、チャートの上位にランクインするメトリクスを確認するのを心待ちにしています。そのスケールにはいつも驚かされます。 2024年は Channy Yun と Jeff Barr が、 AWS が 2024 年のプライムデーを強化して記録的な売り上げを達成した方法 の舞台裏を紹介してくれます。詳細については投稿を読んでいただきたいのですが、毎年びっくりさせられるメトリクスの 1 つが、 Amazon Aurora のものです。プライムデーには、6,311 件の Amazon Aurora データベースインスタンスが 3,760 億のトランザクションを処理し、2,978 テラバイトのデータを保存し、913 テラバイトのデータを転送しました。 他にも嬉しいニュースがあります。 2 つの新しい AWS 認定試験の登録受付が開始されました 。 AWS 認定 AI プラクティショナー と AWS 認定機械学習エンジニア – アソシエイト のベータ版に登録できます。これらの認定資格は、基幹業務の専門家から経験豊富な機械学習 (ML) エンジニアまで、すべての人を対象としており、 需要の高い人工知能と機械学習 (AI/ML) のキャリア に備えるのに役立ちます。AWS 認定 AI プラクティショナーと AWS 認定機械学習エンジニア – アソシエイトを対象とした 4 段階の試験準備計画を実行することで、試験の準備ができます。 8月12日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) EC2 G6e インスタンスの一般公開 – NVIDIA L40S Tensor Core GPU を搭載した G6e インスタンスは、機械学習や空間コンピューティングの幅広いユースケースに使用できます。G6e インスタンスを使用すると、最大 13B のパラメータを持つ大規模言語モデル (LLM) と、画像、動画、音声を生成するための拡散モデルをデプロイできます。 Karpenter 1.0のリリース – Karpenter は、柔軟かつ効率的で高性能な Kubernetes コンピューティング管理ソリューションです。Karpenter は Amazon Elastic Kubernetes Service (Amazon EKS) または任意の準拠の Kubernetes クラスターで使用できます。詳細については、 Karpenter 1.0 のリリースに関する投稿 をご覧ください。 Amazon SageMaker Pipelines 用のドラッグアンドドロップ UI – 今回のリリースにより、コードを記述しなくても、エンドツーエンドの AI/ML ワークフローをすばやく作成、実行、モニタリングして、モデルのトレーニング、ファインチューニング、評価、デプロイを行えるようになりました。ワークフローのさまざまなステップをドラッグアンドドロップし、UI で接続して AI/ML ワークフローを作成できます。 Amazon EC2 オンデマンドキャパシティ予約の分割、移動、変更 – Amazon EC2 オンデマンドキャパシティ予約を管理する新機能により、キャパシティ予約の分割、キャパシティ予約間でのキャパシティの移動、キャパシティ予約のインスタンス適格属性の変更を行えるようになりました。これらの機能の詳細については、「 既存のキャパシティ予約から利用可能なキャパシティを分割する 」を参照してください。 Amazon Q Business のドキュメントレベル同期レポート – Amazon Q Business のこの新機能により、データソース同期ジョブ中に処理された各ドキュメントの詳細なインデックス作成ステータス、メタデータ、アクセスコントロールリスト (ACL) の詳細を含む包括的なドキュメントレベルのレポートが提供されるようになりました。Amazon Q Business がクロールおよびインデックス登録を試みたドキュメントのステータスを確認できるだけでなく、特定のドキュメントが期待どおりの回答で返されなかった理由をトラブルシューティングすることもできます。 AWS Control Tower でのランディングゾーンのバージョン選択 – ランディングゾーンバージョン 3.1 以降では、現行バージョンのランディングゾーンを更新またはリセットしたり、選択したバージョンにアップグレードしたりできます。詳細については、 AWS Control Tower ユーザーガイドの「 ランディングゾーンのバージョンを選択する 」を参照してください。 AWS re:Post での AWS サポート公式チャンネルのリリース – AWS サポートと AWS Managed Services (AMS) の専門家が作成した、AWS で大規模な運用を実現するための厳選されたコンテンツにアクセスできるようになりました。この新しいチャンネルでは、複雑な問題に対する技術的解決策、運用上のベストプラクティス、AWS サポートと AMS のサービスに関するインサイトを確認できます。詳細については、 re: Post の AWS サポート公式チャンネル をご覧ください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS サービスの地域拡大 8月19日週に実施された AWS サービスの新しい AWS リージョンへの拡張の一部を次に示します。 Amazon VPC Lattice が、さらに 7 つのリージョンで利用可能に – Amazon VPC Lattice は、米国西部 (北カリフォルニア)、アフリカ (ケープタウン)、欧州 (ミラノ)、欧州 (パリ)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、南米 (サンパウロ) で利用できるようになりました。今回のリリースにより、Amazon VPC Lattice は 18 の AWS リージョンで一般利用できるようになりました。 QuickSight の Amazon Q が、さらに 5 つのリージョンで利用可能に – QuickSight の Amazon Q は、既存の米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト) リージョンに加えて、アジアパシフィック (ムンバイ)、カナダ (中部)、欧州 (アイルランド)、欧州 (ロンドン)、南米 (サンパウロ) で一般提供が開始されました。 AWS Wickr がヨーロッパ (チューリッヒ) リージョンで利用可能に – AWS Wickr は、米国東部 (バージニア北部)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (ロンドン)、欧州 (フランクフルト)、欧州 (ストックホルム) リージョンに加えて、欧州 (チューリッヒ) でも利用できるようになりました。 リージョン別の利用可能な AWS サービスの一覧を参照できます。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent 2024 – 第 1 ラウンドのセッションカタログ をご覧ください。2024年の AWS re:Invent でのさまざまな学習機会のすべてを詳しく確認し、今すぐアジェンダの作成を開始しましょう。あらゆる関心と学習スタイルに合ったセッションが見つかるでしょう。 AWS Summit – 2024 年の AWS Summit シーズンが終わりに近づいています。 クラウドコンピューティングコミュニティがつながり、コラボレーションして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください: ジャカルタ (9 月 5 日)、 トロント (9 月 11 日)。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 コロンビア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日)、 ベイエリア (9 月 13 日) です。 AWS GenAI Lofts – AWS AI のエキスパートとつながり、業界のリーダーによる講演、ワークショップ、Fireside Chat、質疑応答に参加しましょう。すべての Loft は無料で、AI ジャーニーの加速に役立つよう、あらゆる参加者が何かを得られるように、細心の注意を払って厳選されています。Loft は、 サンフランシスコ (8 月 14 日～9 月 27 日)、 サンパウロ (9 月 2 日～11 月 20 日)、 ロンドン (9 月 30 日～10 月 25 日)、 パリ (10 月 8 日～11 月 25 日)、 ソウル (11 月) で開催される予定です。 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 8月19日週はここまでです。8月26日週の Weekly Roundup もお楽しみに! – Prasad この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

はじめに データは現代企業にとって非常に重要な経営資源の一つとなっています。しかし、多くの企業がデータの活用において様々な課題に直面しているのが実情です。 そこで AWS では、パートナー企業と協力して「データ活用ワークショップ(WS)」を開催しました。今回の WS では、複数のユーザー企業が一同に会し、各社が抱える課題や対処方法を共有し合いました。そして、パートナー企業の支援のもと、短期間ながらも素晴らしい成果を上げることができました。 本記事では、その WS の様子と、データ活用におけるパートナー企業の重要性について紹介していきます。データ活用は一企業だけでは難しく、専門知識を持つパートナーと協力することが成功の鍵となります。ぜひ参考にしてみてください。 データ活用 WS とは データ活用 WS について説明する前に、データ活用における代表的な 4 つの課題について述べていきたいと思います。 &nbsp;データの収集と管理の難しさ 企業は複数のソースからデータを収集しますが、データ形式が統一されていないことが多く、収集と管理に手間がかかります。また、データの信頼性や完全性を確保することも大きな課題です。 データ分析人材の不足 データ分析に必要なスキルを持つ人材が不足しているのが実情です。データサイエンティストなどの専門家の確保は容易ではありません。 データ活用の具体的な方法がわからない データを収集し分析することは重要だと認識していても、実際にビジネスにどのように活用すればよいかわからないケースが多数あります。 データ活用に対する経営層の理解不足 データ活用の重要性を経営層が十分に理解していないと、投資が進まず取り組みが遅れがちになります。 データ活用 WS ではこれらの課題について、ユーザー企業が意識して取り組めるような座組みとなっています。まず、参加者は IT 部門が参加するようなテクノロジーに特化した勉強会のようなものではなく、実際にその会社ごとに持つ課題を深掘りして、その課題を解決するような分析ソリューションを構築します。そのためには、事業部門側の積極的関与が必要になります。本WS では、事業部門と IT 部門の参加を必須としており、さらに実際にデータ活用を根付かせるには経営層の理解が必要になることから、エグゼクティブスポンサーをつけていただくことを必須としています。 それにより、データ活用 WS で作られた分析業務を行うダッシュボードは、 IT 部門が作ったきりで使われないダッシュボードになることなく、常に事業部門の意見が取り入れた使い勝手の良いものとなり、さらにこの関係性を継続することにより、常に改善され続けるソリューションとなります。 またデータ分析が根付くには、経営層の理解が必要になります。理解があるからこそ、データの民主化が実現され、今回 のWS 参加者以外にも浸透していくことが期待されます。 &nbsp; 以上のような課題解決に重要な考え方は、こちらの Blog「 データドリブンカルチャーの作り方 」を参照ください。WS の中でもこちらの Blog の内容に触れ、組織のあり方についてもお伝えしました。 この WS では、AWS のデータ分析におけるスペシャリストの講義を受けた上で、Amazon 流のモノづくりのスタイルである Working Backwards を取り入れたグループワークで課題を洗い出し、解決策を考えます。考えた内容は各社で発表しあい、他社からの学びを得ることができるようになっています。さらにパートナー企業がサポートをするため、参加企業は WS の中で有識者からたくさんの知見を得ることができるようになっています。 図1. データ活用WS DAY1 から DAY4 までの流れ 実施期間としては、だいたい 3-4 ヶ月間かけてDay1 〜 Day4 を実施し、Day4 の成果報告会にて各社の成果を発表いただきます。 Amazon S3 をデータレイクとして、 AWS Glue Crawler でデータカタログを作成し、 Amazon Athena でクエリし、 Amazon QuickSight にてダッシュボードを作るパターンとするのが、最初のステップとして取り組みやすく、本 WSの中でも推奨しています。 今回は、ユーザー企業 3 社（ 藤田観光株式会社様 、 株式会社ルネサンス様 、医療機器メーカー A 社様）と、パートナー企業 3 社（ クラスメソッド株式会社様 、 株式会社ジェーエムエーシステムズ様 、 株式会社システナ様 ）が参加されました。参加企業の参加時のレベル感はまちまちで、企業内でも部署によっても差がある企業が多いです。これまで実施してきた中でも、データがサイロ化されており事業部ごとにそれぞれデータを保有しているため属人化された作業になっている企業が多く、そういった企業や、そこまでも至っていない企業でも参加が可能になっています。 図2. 各社のデータ活用具合と課題感 4 日間の様子については、以下の章をご覧ください。 データ活用WS実施の様子 Day1 Day1 では、ベースとなるアイデアの発散フェーズと位置づけ、座学とグループワークの 2 つのアジェンダを実施しました。座学では、AWS スペシャリストからの QuickSight に関する基礎知識のインプットセッションが提供されました。 グループワークでは、各々がデータ活用に関して「これまでやってきたこと」「うまくいったこと」「うまくいかなかったこと」を付箋に書き出し、事業部門と IT 部門がそれぞれの取り組みについて理解を深めました。参加企業の中には、この日が事業部門と IT 部門の参加者が初対面という場面もありましたが、ディスカッションを通して互いの意見への理解を深められていました。最後にはディスカッションを通して整理した①過去の取り組み ②自社のデータ活用のレベル感 ③現時点での課題 について、各社より発表をして頂きました。 写真1. グループワークの様子 個人ワークで付箋に書き出し→ホワイトボードに張り付けて整理する、というセットを繰り返し課題の整理を行いました。 Day2 Day2 では、ダッシュボードイメージを作成することをゴールに、座学とグループワークの 2 つのアジェンダを実施しました。 座学では、データ分析・可視化の必要性や、分析要件や指標の定義の仕方、可視化の手法のご紹介といった、ビジネス現場におけるデータ分析の基礎について、AWS のスペシャリストより講義を行いました。座学で学んだデータ分析の考え方をもとに、グループワークではダッシュボードを使うユーザーのペルソナを設定していきます。 図3. Day2 ディスカッションのまとめ方例 当日は上記のフォーマットに従ってホワイトボードで意見を整理していきます。 ダッシュボードイメージを考える際、Amazon 自身が新製品や新サービス開発・社内の業務改善の際に実践している「Working Backwards」と呼ばれるメカニズム（フレームワーク） を活用して課題を整理します。Working Backwards では、「お客様は誰ですか？」「現在の課題と新しい可能性は何ですか？」「お客様にとっての最大のメリットは何ですか？」「お客様のニーズやウォンツをどのように知りましたか？」「お客様の体験はどのように変わりますか？」という5 つの質問を通じて、本当に必要なサービスを企画・開発していきます。今回のグループワークでは、参加企業の皆さまから見た「お客様（＝ダッシュボードを使う人）」について徹底的に議論し、必要な要素を洗い出していきました。この際に、事業部門のお困りごとに関するリアルな声が反映されていくことで、より「使われる」ダッシュボードの開発に繋がります。Day2を終え参加者からは、「『お客様を起点に考える』にとても共感しました。」「 今までやりたいことが膨らみ過ぎて、手が付けられない状態になっていました。 Day2 で焦点が整理され、初手の動きが明確化できました。」という感想を頂いており、 座学やグループワークを通してデータ可視化の手順や考え方について学びを得ていただきました。 写真2. Day2発表の様子 &nbsp; Day3 Day3 では、Day2-Day3 の間の期間で開発されたダッシュボードに対し、ダッシュボードの利用者である事業部門の参加者へ中間報告を行います。 一番多かった企業では当日約 40 名様に参加頂き、実際に使う事業側の方から「こういったデータが見たかった」「こういう軸があるとさらに意思決定に役立てられそう」といった意見が飛び交いました。ここで得たフィードバックをもとにユーザー企業の IT 部門の参加者はさらに改良を重ね、Day4 に向けて完成させていきます。この開発期間中、パートナー企業の優れた技術力が開発メンバーの大きな助けとなります。参加企業が QuickSight の使い方に悩んでいる際は、パートナー企業に相談しながら解決策を一緒に考えていました。このようにパートナー企業の力を借りることで高品質なダッシュボードを素早く実装することが出来ました。 Day4 Day4 では、参加企業が Amazon オフィスに集まり成果物の成果発表会を実施します。 ここでは各社から開発までの道のりや今回実装したダッシュボードの発表がなされ、どの企業も短期間で開発したとは思えない素晴らしい出来栄えを披露いただきました。参加企業の 1 社は、データソースからそのままのデータでは表現が難しいものを、データパイプラインを構築した上、１つのダッシュボードの中で期間の比較を簡単に行えるように、検索フィールドを含めた比較的難易度の高い機能をパートナーの支援を受けながら構築し、実用性の高さから会場を沸かせていました。 写真3. 最終発表会の様子 また最後には、参加企業それぞれから MVP を 1 名ずつ選出させていただきました。伴走支援頂いたそれぞれのパートナー企業より、ユーザーに求められるダッシュボードを根気強く作り上げた各社の開発担当者が表彰されました。MVP に選出された皆さまからは、「データをただ見せるだけではあまり意味が無く、誰がどの様に何のために使うのか、という設定がとても重要になってくると学びになりました。」「ダッシュボード作成が可能な人材を社内に増やしていき、QuickSight の利用拡大を加速させる布教活動にも取り組みたいと思っております。」とコメントを頂きました。表彰された MVP の皆さまには AWS より書籍を贈呈いたしました。 成果発表会の終了後は、参加企業同士の懇親会の場が設けられています。データ活用 WS を通して得た学びや、この取り組みを自社に持ち帰り全社展開していくにあたっての悩みなど、ざっくばらんに意見交換がなされました。終了後のアンケートでは、「業界は違うものの、他社の取り組みや課題感を知ることで自分たちの立ち位置を知ることができ、かなり刺激的だった」という声が多くあがっていました。 今後の展望 データ活用 WS は、今後さらにパートナー企業と連携を強化しながら、継続して実施していく予定です。お客様からのフィードバックを参考にしながら、WS の内容を日々改善・進化させています。 また、WS に参加された企業においても、AWS やパートナー企業の支援を受けながら、WS で構築した分析基盤をベースにさらに様々なデータを取り込み、他の部門での課題についても解決できるようなソリューションを構築していく予定です。 事業部門を巻き込んで、会社全体の組織を変革したいとお考えの方は、ぜひお気軽にご相談ください。データ活用の取り組みを通じて、貴社の事業変革をサポートさせていただきます。 まとめ 本 Blog では、データ活用 WS でパートナー協業型の実施企業の様子をお伝えしました。業界問わず、様々な企業がデータ分析に課題を抱えており、データ活用を推進するためのノウハウや人材の確保が重要な課題となっています。今回の WS では異なる業種の企業が自社の状況を振り返り、それぞれの考え方を共有し合うことで、お互いに学びあい新たな可能性を見出すことができました。参加企業からは、「新しい視点を得ることができました。」「他社の事例から多くの気づきがありました。」「パートナー様および AWS メンバーの方々には手取り足取り色々教えていただきまして、ありがとうございました。」といったコメントをいただきました。コメントにもある通り、自社だけで進めるのではなく、他社の知見やパートナー企業、AWS とともに課題解決が実際にできていました。データ活用は単独の企業だけでは難しく、様々なパートナーと協業することが成功の鍵となります。今後もこうした機会を設けながら、データ活用の裾野を広げていきたいと考えています。 著者について 戸塚 智哉 戸塚智哉(Tomoya Tozuka)は、飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 &nbsp; 新田 美咲 新田 美咲(Misaki Nitta) は、サービス産業営業本部 エンタープライズアカウント第 3 営業部のアカウントマネージャーです。主にフィットネス業界、ホテル業界、SIerのお客様のご支援を担当しています。趣味は旅行で、最近行って感動した地域はハイジの世界が連想されるスイスのグリンデルワルトです。 &nbsp; &nbsp; &nbsp;

本投稿は Migrate an Amazon QLDB Ledger to Amazon Aurora PostgreSQL (記事公開日: 2024 年 7 月 18 日) のブログを翻訳したものです。 「 監査のユースケースで Amazon QLDB をAmazon Aurora PostgreSQL に置き換える 」のブログでは、データ変更に対して信頼できる監査を維持することが重要な要件である台帳データベースの一般的なユースケースにおいて、 Amazon Aurora PostgreSQL 互換エディション が Amazon QLDB の優れた代替手段である理由を説明しました。 この投稿では、Amazon QLDB 開発者ガイドの チュートリアル にある米国自動車省 (DMV) のサンプル台帳を例として、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するプロセスを示します。このソリューションをあなた自身の移行におけるベースとして使用し、スキーマと移行戦略に合わせて必要に応じて変更することができます。 移行決定 データベースを移行するときは、どのデータを移行するかを決定する必要があります。一部のアプリケーションでは、すべての履歴データを含むデータベース全体を移行することが求められます。また、最新のデータ (たとえば、過去 12 ヶ月分) のみを移行し、古いデータをアーカイブするのが最適な選択である場合もあります。ただし、アプリケーションのカットオーバーを迅速に行うために最新のデータを移行し、後で古いデータを新しいデータベースに移行することを決定する企業もあります。現在、一括で移行できることはほとんどないため、カットオーバーまでの期間、ターゲットデータベースをソースデータベースと同じ最新の状態に保つ必要があります。 この記事で紹介したソリューションは、ベースとして移行元の台帳データ全体をターゲットデータベースに移行し、移行元で継続中の変更をカットオーバーまでターゲットにコピーすることです。このソリューションはモジュール式なので、特定の移行戦略に合わせてカスタマイズできます。 また、移行中にターゲットデータベース内のデータをモデル化し、台帳データをそのモデルに適合するように変換する方法を決定する必要があります。Amazon QLDB ドキュメントデータモデルは、ネストされた要素を含む可能性のある複雑で構造化されたドキュメントをサポートします。Amazon QLDB のテーブルには、ドキュメント構造の異なるオブジェクトが含まれている場合があります。台帳の柔軟な文書モデルをより厳格なリレーショナルデータベーススキーマにマッピングするのは難しい場合があります。さらに、文書の構造は時間の経過とともに変化する可能性があります。移行プロセスでは、特定の文書のすべてのリビジョンが同じ構造であることを前提とすることはできません。このような課題を考えると、データを JSON として Amazon Aurora PostgreSQL に移行することもできます。これにより移行が大幅に簡素化されますが、リレーショナルデータベースのデータにアクセスするための最も効率的なオプションではない可能性があります。別の方法は、移行中に台帳データを正規化し、文書モデルをリレーショナルモデルに変換し、時間の経過とともに発生した文書モデルへの変更を考慮に入れることです。このアプローチはより複雑で、より多くのコーディングが必要であり、予期しない変換エラーが発生して移行プロセスが中断される傾向がありますが、RDBMS でのデータへのアクセス方法および使用方法によっては、より適切な選択となる場合があります。 このソリューションでは、両方のアプローチを提示します。車両登録サンプルアプリケーションの台帳データはリレーショナルモデルに正規化されますが、台帳からの改訂メタデータは Amazon Aurora PostgreSQL に JSONB タイプとして保存されます。 ソリューション概要 移行は、フルロードと継続的なレプリケーションの 2 つのフェーズで実行されます。フルロードでは、ソースデータベースからターゲットデータベースへのデータの効率的な一括ロードが実行されます。ソースデータベースは、アプリケーションがターゲットデータベースを切り替えて使用するまでトラフィックを処理し続ける可能性があるため、フルロードでは移行されなかったデータ変更が含まれている可能性があります。継続的なレプリケーションまたは変更データキャプチャ（CDC）フェーズでは、継続的に変更を取得してターゲットデータベースに移行し、アプリケーションがターゲットデータベースを参照するまでソースと同じ最新の状態に保ちます。 フルロードフェーズでは、Amazon QLDB 台帳は AWS Step Functions ステートマシンによって Amazon Simple Storage Service (Amazon S3) のバケットに エクスポート されます。エクスポートには、エクスポートが開始された時点のすべてのトランザクションのデータが含まれます。 AWS Glue ジョブは、エクスポートされたファイルから台帳文書のリビジョンを抽出し、 AWS Database Migration Service (AWS DMS) が使用できる CSV 形式に変換します。AWS Glue ジョブは、変換された CSV ファイルを Amazon S3 に書き込みます。AWS DMS タスクは Amazon S3 から CSV ファイルを読み取り、そのデータを Aurora PostgreSQL データベースにロードします。この記事では Amazon Aurora PostgreSQL へのデータ移行について説明していますが、AWS DMS は 様々なターゲットエンドポイント をサポートしているため、ここで説明するプロセスを他のデータベースへの移行にも適用できます。 次の図は、ソリューションのアーキテクチャを示しています。 継続的なレプリケーションフェーズでは、台帳への新しい更新がキャプチャされ、ほぼリアルタイムでターゲットの Aurora PostgreSQL データベースに移行されます。このプロセスは Amazon QLDB ストリーミング 機能に依存しています。このソリューションでは、エクスポートの最後の台帳ブロックを識別して、エクスポート開始後にコミットされた最初のブロックからストリームを開始できるようにします。新しいトランザクションが台帳にコミットされると、Amazon QLDB はそれらの変更を Amazon Kinesis Data Streams に送信します。 AWS Lambda 関数は、次の図に示すように、 Amazon Kinesis Data Streams からのイベントを使用し、そのデータをターゲットデータベースに書き込みます。 前提条件 移行ソリューションは、インフラストラクチャをセットアップし、移行に使用されるコードをデプロイする複数の AWS CloudFormation テンプレートを使用してデプロイされます。CloudFormation テンプレートと関連ファイルは GitHub repo で入手でき、PCにダウンロードする必要があります。以下のコマンドでプロジェクトコードをダウンロードします。 git clone git@github.com:aws-samples/example-qldb-ledger-migration.git プロジェクトには次のファイルが含まれています。 setup.yml – 車両登録台帳、ターゲットの Aurora PostgreSQL データベース、および関連する VPC ネットワーキングをデプロイしてデータを作成します ledger-export.yml – コンポーネントをデプロイして台帳からデータをエクスポートします ledger-full-migration.yml – AWS Glue コンポーネントと AWS DMS コンポーネントをデプロイして、エクスポートされた台帳データをターゲットデータベースに抽出、変換、ロード (ETL) します ledger-cdc-migration.yml – Amazon QLDB ストリーミング用の Kinesis Data Stream と、ターゲットデータベースに台帳の変更を書き込むストリームコンシューマーを設定します dmv-postload-ddl.sql – 移行のフルロードフェーズが完了した後にターゲットデータベースにインデックスを作成するための SQL ステートメントが含まれます ソースデータベースとターゲットデータベースの作成 このデモンストレーションでは、ソースとして動作する Amazon QLDB 台帳とターゲットとして機能する Aurora PostgreSQL クラスターを作成し、VPC と関連ネットワーク、データベース認証情報を保持する AWS Secrets Manager シークレット、S3 バケット、 AWS Identity and Access Management (IAM) ロール、および Aurora クラスターを起動するために必要なその他のコンポーネントを作成します。セットアップにより、台帳データベースにデータが入力され、Aurora PostgreSQL クラスターにデータベースとスキーマが作成され、移行用のデータベースユーザーが作成されます。 このソリューションは RDS Data API に依存していますが、すべてのリージョンで利用できるわけではありません。 この表 を参照して、使用しているリージョンが Data API をサポートしていることを確認してください。 このソリューションをあなた自身の移行の基礎として使用していて、Amazon QLDB 台帳と Aurora PostgreSQL クラスターがすでにセットアップされている場合、このセクションはスキップできます。 AWS CloudFormation を使用してコンポーネントをデプロイするには、以下のステップを実行します。 AWS CloudFormation コンソールのナビゲーションペインで 「 スタック 」 を選択します。 「 スタックの作成 」 を選択し、「 新しいリソースを使用（標準） 」 を選択します。 「 テンプレートファイルのアップロード 」 を選択します。 「 ファイルの選択 」 を選択し、PC 上の GitHub プロジェクトから setup.yml ファイルを選択します。 「 次へ 」 を選択します。 「 スタックの詳細を指定 」ページで、 スタック名 に ledger-migrate-setup と入力します。 &nbsp;VPC の CIDR が環境内の他の VPC と競合しない限り、すべての入力パラメータはデフォルトのままにします。競合する場合は、 VPCCIDR 、 DatabaseSubnetCIDRs 、 PublicSubnetCIDRs の各パラメータを変更して、競合しないようにしてください。また、デフォルトの AuroraDBInstanceClass パラメータを調整する必要がある場合もあります。すべてのインスタンスタイプがすべてのリージョンで利用できるわけではありません。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 スタックが CREATE_COMPLETE ステージになったら、「 出力 」タブを選択してスタックの出力を表示します。これらの値は、移行プロセスの後続ステップの入力として使用されます。 Amazon QLDB からデータをエクスポート 移行の最初のステップは、ソース台帳から S3 バケットにデータをエクスポートすることです。エクスポートは多数のファイルで構成され、各ファイルには JSON 形式の 1 つ以上の台帳ブロックが含まれます (詳細については、 QLDB のジャーナルエクスポート出力 を参照してください)。中規模の台帳のエクスポートでも数時間かかる場合があります。エクスポート時間を短縮するために、1 つの台帳に対して複数のエクスポートを並行して実行して、エクスポートごとに台帳の一部を処理することができます。Amazon QLDB はデフォルトで最大 2 つの同時エクスポートをサポートします。台帳が非常に大きい(数百ギガバイト) 場合は、AWS サポートに連絡して制限の引き上げをリクエストしてください。 このソリューションでは、Step Functions を使用してエクスポートを実行します。ステートマシンは、必要な数の同時エクスポートをパラメータとして受け入れます。台帳ダイジェストを取得してジャーナルの最後のブロック番号を取得し、それを使用して台帳を均等に分割し、エクスポート全体で作業を均等に分割します。ステートマシンはエクスポートジョブを開始し、すべて完了するまでループします。すべてのエクスポートジョブが完了すると、ステートマシンは各エクスポートの最後のブロックのダイジェストとプルーフハッシュを取得し、Amazon S3 に保存します。これにより、ソースの台帳が削除された後にエクスポートは暗号で検証されます (このプロセスはこの記事では説明しません)。 エクスポートを実行するには、まず AWS CloudFormation を使用して必要なコンポーネントをデプロイする必要があります。以下のステップを完了します。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「 スタックの作成」 &nbsp;を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「 テンプレートファイルをアップロード」 &nbsp;を選択します。 「 ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-export.yml ファイルを選択します。 「 次へ」 &nbsp;を選択します。 「 スタックの詳細を指定」 ページで、「 スタック名」 &nbsp;に ledger-export と入力します。 &nbsp; LedgerName パラメータの値はデフォルト値 ( “vehicle-registration” ) のままにしておきます。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 &nbsp;スタックが CREATE_COMPLETE ステージになったら、Step Functions コンソールを開き、ナビゲーションペインで 「ステートマシン」 を選択します。 LedgerExporter ステートマシン を選択します。 ステートマシンは インプットとしてJSON オブジェクトを受け入れます。 &nbsp;次のスニペットを JSON エディターに入力します。AWS サポートを通じて同時エクスポートの制限を増やした場合は、 ExportCount の値を新しい制限に変更してください。 { "LedgerName": "vehicle-registration", "BucketPrefix": "dmv/", "ExportCount": 2 } &nbsp;「 実行の開始 」を選択します。 ステートマシンは、&nbsp; vehicle-registration 台帳の場合は約 10 分間実行されますが、台帳が大きい場合はさらに長く実行されます。完了すると、実行ステータスは「 成功 」になります。実行詳細ページの グラフビュー セクションには、ステートマシンのステップが視覚的に表示されます。 &nbsp; Export ノードを選択し、 Output セクションからエクスポート ID をコピーして、テキストエディタに保存します。これらはこれ以降のステップで必要になります。 ダイジェスト ノードを選択し、 LastBlockNum &nbsp;と&nbsp; LastBlockTimestamp の値を、後で使用できるようにテキストエディタにコピーします。 エクスポートが完了しました。このプロセスにより、 ledger-export-&lt;ACCOUNT ID&gt; という名前の S3 バケットが作成されました。このバケットには、JSON 形式でエクスポートされた台帳データを含む dmv というフォルダがあります。フォルダの名前は、ステートマシンへの入力の&nbsp; BucketPrefix パラメーターで設定されました。 データの抽出と変換 台帳のエクスポートが完了したら、次のステップは、エクスポートされた JSON ファイルから台帳データを抽出し、それを CSV ファイルに変換して Amazon Aurora PostgreSQL に効率的に読み込むことです。このソリューションは、抽出と変換を実行する AWS Glue ジョブを作成します。AWS Glue は Apache Spark を使用してエクスポートデータセットを複数のコンピューティングノードに分散して同時処理することで、大規模な台帳からのデータを処理するのに必要な時間を短縮します。AWS Glue ジョブは、エクスポートステップで作成された S3 バケットからエクスポートされたデータを読み取り、その出力をプロセスによって作成された新しい ETL バケットに書き込みます。 AWS Glue ジョブは、 k 台帳のテーブルをターゲットデータベース用に設計したスキーマに変換し、台帳文書の構造をリレーショナルデータベースの行と列にフラット化するように構築されています。このプロセスを使用して台帳を移行するには、データモデルに合わせて AWS Glue ジョブの PySpark コードの一部を変更する必要があります。 抽出と変換を実行するには、AWS CloudFormation を使用して必要なコンポーネントをデプロイします。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「 スタックの作成」 &nbsp;を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「 テンプレートファイルをアップロード」 &nbsp;を選択します。 「 ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-full-migration.yml ファイルを選択します。 「 次へ」 &nbsp;を選択します。 このテンプレートは、移行のこのフェーズと次のフェーズに必要なコンポーネントをデプロイします。 「 スタックの詳細を指定」 &nbsp;ページで、「 スタック名」 &nbsp;に ledger-full-migrage と入力します。 エクスポートスタックとは異なり、このテンプレートには入力パラメータが必要です。 &nbsp;次の入力パラメータを指定します。 &nbsp; LedgerName には、 ledger-migrate-setup スタックの LedgerName 出力パラメータの値を入力します。 &nbsp; ExportIds には、state 関数実行からコピーしたexport IDs を、カンマ区切りのリスト形式で入力します。 &nbsp; ベースプレフィックスのエクスポート に、&nbsp; dmv/ と入力します。 &nbsp; グルーワーカータイプ に、&nbsp; G.2X と入力します。 &nbsp; グルーワーカーの数 に、 2 と入力します。 &nbsp; レプリケーション・インスタンス・サブネット に、 ledger-migrate-setup スタックの DatabaseSubnets パラメータからサブネットを入力します。 &nbsp; レプリケーションインスタンスクラス に、dms.r6i.large と入力します。 &nbsp; セキュリティグループ については、 ledger-migrate-setup スタックの DatabaseSecurityGroups パラメータからセキュリティグループを選択します。 &nbsp; ターゲットデータベースシークレット名 には、 ledger-migrate-setup スタックの MigrateDatabaseUserSecretName 出力パラメータの値を入力します。 &nbsp; ターゲットデータベース名 には、 ledger-migrate-setup スタックの TargetDatabaseName 出力パラメータの値を入力します。 「 次へ」 &nbsp;を選択します。 「 スタックオプションの設定」 &nbsp;ページで、「 次へ」 &nbsp;を選択します。 「 確認して作成」 &nbsp;ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「 送信」 &nbsp;を選択します。 &nbsp;CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブ を選択します。 &nbsp; ledger-dmv-migrate ジョブを選択し、「 ジョブの実行」 &nbsp;を選択します。 &nbsp;ジョブの名前を選択して、ジョブの詳細ページを開きます。 &nbsp;「 実行 」 タブを選択すると、ジョブのステータスが表示されます。 ジョブが完了すると、そのステータスは「 成功 」 になります。 CloudFormation テンプレートは ledger-etl-&lt;AccountId&gt; という名前の S3 バケットを作成しました。AWS Glue ジョブは、その出力をバケットの dmv というフォルダに書き込みます。Amazon S3 コンソールを開き、 ledger-etl-&lt;AccountId&gt; バケットに移動して、 dmv フォルダを開くことができます。 vehicle-registration 台帳の各テーブルに対応するフォルダのリストが表示されます。これらのフォルダには、テーブル内の削除されていないすべてのドキュメントの最新リビジョンが含まれています。ターゲットの Aurora PostgreSQL データベースに書き込まれる監査テーブルの内容を含む各台帳テーブル用の追加フォルダがあります。監査テーブルには、それぞれの元帳テーブル内のすべての文書の完全な改訂履歴が含まれています。 フォルダとそのコンテンツを確認してみてください。 table_counts フォルダには、台帳の各テーブルの名前と、テーブル内のそれぞれのドキュメントリビジョン数を含む1つのファイルが格納されます。これは、すべてのレコードがターゲットデータベースに移行されたことを確認するのに役立ちます。 フルデータ移行 フルデータの移行では、AWS DMS を使用して前のステップの AWS Glue ジョブの CSV 出力を読み取り、それを Amazon Aurora PostgreSQL にロードします。AWS DMS は、データをロードする前にターゲットデータベースのテーブルを切り捨てます。この記事ではターゲットデータベースとして Amazon Aurora PostgreSQL を使用していますが、AWS DMS では AWS Glue ジョブの出力を 他の多くのデータベース に移行できます。 移行を開始するには、次の手順を実行します。 &nbsp;AWS DMS コンソールのナビゲーションペインで 「 データベース移行タスク」 &nbsp;を選択します。 &nbsp; dmv-full-migration task を選択し、「 アクション 」ドロップダウンで「 再起動/再開 」を選択します。 &nbsp;警告として ターゲットデータベースへのデータ損失の可能性がある再起動/再開 を選択します。 移行タスクの実行が開始されます。そのステータスにはジョブの進行状況が反映されます。ジョブが完了すると、そのステータスは 「 ロード完了」 &nbsp;になります。この時点で、Amazon QLDB の vehicle-registration 台帳からエクスポートされたすべてのデータが Aurora PostgreSQL データベースに移行されます。次に、Aurora PostgreSQL データベースにインデックスと制約を作成します。 &nbsp;Amazon RDS コンソールで、前のセクションで行ったように台帳データベースに接続します。 &nbsp;GitHub プロジェクトの dmv-postload-ddl.sql ファイルからすべての行をコピーし、RDS クエリエディタに貼り付けて、「 実行」 &nbsp;を選択します。 &nbsp;RDS クエリエディタを使用して、次のクエリのいくつかを実行して、移行されたデータを確認します。 select * from dmv.person; select * from dmv.person_audit_log; select * from dmv.vehicle; select * from dmv.vehicle_audit_log; select * from dmv.vehicle_registration; select * from dmv.vehicle_registration_audit_log; select * from dmv.drivers_license; select * from dmv.drivers_license_audit_log; テーブルの ql_audit カラムは PostgreSQL の JSON タイプです。この列には、Amazon QLDB 台帳からのリビジョンメタデータが含まれています。 &nbsp;次のクエリを実行して、JSON オブジェクトの個々のフィールドにアクセスする方法を確認してください。 select person_id, ql_audit-&gt;'ql_txid' transaction_id, ql_audit-&gt;'ql_txtime' transaction_timestamp from dmv.person_audit_log; 継続的な変更データの複製 フルデータの移行プロセスでは、台帳からエクスポートされたすべてのデータが移行されます。ただし、台帳を使用するアプリケーションが Aurora PostgreSQL データベースを使用するように変更されるまで、エクスポート後も台帳を引き続き使用できます。移行の次のステップは、実行された変更をキャプチャし、ほぼリアルタイムで Aurora PostgreSQL データベースに複製することです。このソリューションでは、Amazon QLDB ストリーミング 機能を使用して、台帳の変更を Kinesis Data Stream にほぼリアルタイムで送信します。Lambda 関数はデータストリームからの台帳イベントを処理して、 RDS Data API で Aurora PostgreSQL データベースに書き込みます。次の図は、このワークフローを示しています。 AWS CloudFormation を使用して変更データのレプリケーションに必要なコンポーネントをデプロイするには、以下のステップを実行します。 &nbsp;AWS CloudFormation コンソールのナビゲーションペインで 「 スタック」 &nbsp;を選択します。 「スタックの作成」 を選択し、「 新しいリソースを使用 (標準)」 &nbsp;を選択します。 「テンプレートファイルをアップロード」 &nbsp;を選択します。 「ファイルを選択」 &nbsp;を選択し、コンピューター上の GitHub プロジェクトから ledger-cdc-migration.yml ファイルを選択します。 「次へ」 &nbsp;を選択します。 「 スタックの詳細を指定 」ページで、「 スタック名 」に ledger-cdc-migrate と入力します。 次のスタックパラメータを入力します。 AuroraClusterArn には、 ledger-migrate-setup スタックの AuroraClusterArn 出力パラメータの値を入力します。 AuroraDatabaseName には、 ledger-migrate-setup スタックの TargetDatabaseName 出力パラメータの値を入力します。 DatabaseUserSecretArn には、 ledger-migrate-setup スタックからの MigrateDatabaseUserSecretARN 出力パラメータの値を入力します。 KinesisShardCount &nbsp;に 1 と入力します。 LastFullLoadBlock には、エクスポートステートマシンから取得した LastBlockNum の値を入力します。 LedgerName には、 ledger-migrate-setup スタックから LedgerName 出力パラメータの値を入力します。 LedgerStreamStartTime には、エクスポートステートマシンから取得した LastBlockTimestamp の値を入力します。 「次へ」 &nbsp;を選択します。 「スタックオプションの設定」 ページで、「 次へ」 &nbsp;を選択します。 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、 送信」 &nbsp;を選択します。 CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブ を選択します。 スタックのデプロイが完了すると、進行中のレプリケーションがアクティブになります。 レプリケーションの動作を確認するには、Amazon QLDB コンソールの PartiQL エディタに移動します。 「 台帳の選択 」ドロップダウンメニューで vehicle-registration 台帳を選択し、次のクエリを入力します。 update Person set FirstName = 'Melvin' where GovId = 'P626-168-229-765'; &nbsp;RDS クエリエディタに移動し、ターゲットデータベースに対して次のクエリを実行します。 select * from dmv.person_audit_log where gov_id = 'P626-168-229-765' 監査テーブルには、Melvin Parker の 2 つのレコードが含まれています。元のバージョンには、「MelVIN」というスペルのファーストネーム、0 の version 、および INSERT を表す I の operation が含まれています。アップデートされたバージョンでは、ファーストネームが「Melvin」と修正され、 version は 1 になり、UPDATE の operation は U になっています。 &nbsp;次に、以下のクエリを実行します。 select * from dmv.person where gov_id = 'P626-168-229-765' 更新されたpersonsテーブルには、Melvin Parkerのレコードの最新リビジョンが含まれています。名前とバージョン番号を書き留めておきます。 後片付け この記事で作成した AWS インフラストラクチャを削除するには、AWS CloudFormation コンソールを開き、 ledger-cdc-migrate , ledger-full-migrate , ledger-export, setup.yml の順に 削除 します。 スタックには、 ledger-export-&lt;AccountId&gt; と ledger-etl-&lt;AccountId&gt; という 2 つの S3 バケットが残ります。これは、ソリューションが本番台帳の移行に適合している場合に、重要な Amazon QLDB 台帳データが誤って削除されないようにするためです。vehicle-registration 台帳の移行では、各バケットの コンテンツを削除 してから バケットを削除 します。 ソリューションを台帳に合わせて調整 この移行ソリューションは、独自の台帳で使用できるように調整できます。カスタムスキーマを作成するには、プロジェクトソースの setup.yml テンプレートファイルにある PrepareTargetDatabase リソースのスキーマ定義を変更する必要があります。また、 dmv-postload-ddl.sql ファイルを変更して、カスタムスキーマのプライマリインデックスとセカンダリインデックスを作成する必要があります。 ledger-dmv-migrate のAWS Glue ジョブのPySparkコードでは、141行目から146行目まで、ソース台帳内のテーブルの変換関数と出力列が、 table_converters というPython dictで定義されています。変換機能により、台帳からの 1 つの文書リビジョンを CSV として出力できる列にフラット化します。ソースデータベースとターゲットデータベースのデータモデルの table_converters および関連する変換関数の定義を変更します。AWS Glue ジョブのソースコードは、GitHub プロジェクトの ledger-full-migration.yml ファイルの PutGlueJobCodeToS3 リソースで定義されています。 table_converters = { 'Person': { 'name': 'person', 'func': convert_person, 'columns': ['doc_id', 'version', 'person_id', 'first_name', 'last_name', 'dob', 'gov_id', 'gov_id_type', 'address', 'ql_audit'] }, 'Vehicle': { 'name': 'vehicle', 'func': convert_vehicle, 'columns': ['doc_id', 'version', 'vin', 'type', 'year', 'make', 'model', 'color', 'ql_audit'] }, 'VehicleRegistration': { 'name': 'vehicle_registration', 'func': convert_vehicle_registration, 'columns': ['doc_id', 'version', 'vin', 'license_plate_num', 'state', 'city', 'pending_penalty_amt', 'valid_from_dt', 'valid_to_dt', 'primary_owner', 'secondary_owners', 'ql_audit'] }, 'DriversLicense': { 'name': 'drivers_license', 'func': convert_drivers_license, 'columns': ['doc_id', 'version', 'person_id', 'license_plate_num', 'license_type', 'valid_from_dt', 'valid_to_dt', 'ql_audit'] } } Kinesis Data Stream からの台帳更新を使用する Lambda 関数には、同じロジックが含まれていますが、これも変更する必要があります。変更するコードは、GitHub プロジェクトの ledger-cdc-migration.yml ファイル内の StreamConsumerFunction リソースで定義されています。 最後に、 ledger-full-migration.yml ファイル内の SourceEndpoint リソースは、AWS Glue ジョブによって生成される CSV ファイルの構造を定義する AWS DMS ソースエンドポイントを定義します。この定義は、新しい構造に合わせて変更する必要があります。AWS DMS テーブル定義形式の詳細については、「 AWS DMS のソースとしての Amazon S3 の外部テーブルの定義 」を参照してください。 移行を実行する前に、ターゲットデータベースをバックアップしてください。移行ソリューションはターゲットデータベースのテーブルを切り捨て、エラーが発生しても移行全体をロールバックしません。 サマリー この投稿では、Amazon QLDB 開発者ガイドのチュートリアルにある車両登録サンプルデータベースを使用して、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するためのソリューションを紹介しました。このソリューションを独自の台帳の移行に適応させることができ、モジュラー設計により移行戦略に合わせて調整できます。 このソリューションの詳細や移行計画については、AWS の担当者にお問い合わせください。 著者について Dan Blaner は、台帳とリレーショナルデータベースを専門とするプリンシパルソリューションアーキテクトです。彼は学ぶこと、物事を理解すること、他の人が物事を理解するのを助けることを楽しんでいます。休みはベースを弾き、仲の良い友達と bad music 作りを楽しんでいます。

本投稿は Replace Amazon QLDB with Amazon Aurora PostgreSQL for audit use cases (記事公開日: 2024 年 7 月 18 日) のブログを翻訳したものです。 Amazon Quantum Ledger Database (Amazon QLDB) はフルマネージド型の台帳データベースサービスで、台帳にコミットされたすべてのトランザクションの完全かつ検証可能な履歴を提供します。Amazon QLDB 台帳の中核となるのがジャーナルです。ジャーナルは追加専用のデータ構造で、ブロックとして保存されたトランザクションの連続的かつイミュータブルなレコードが含まれます。ジャーナル内のブロックは、暗号ハッシュを使用して連結されます。暗号ハッシュチェーンは、暗号検証方法を使用してトランザクションデータの整合性を提供します。トランザクション履歴のイミュータブルで 暗号化による検証可能性 という 2 つの特性は Amazon QLDB 固有のものであり、お客様が Amazon QLDB を使用してデータの整合性の高い監査と変更履歴を提供する理由でもあります。 この投稿では、監査用に Amazon QLDB の代わりに Amazon Aurora PostgreSQL 互換エディション を使用する方法と、Amazon QLDB が提供する独自の機能の一部を Amazon Aurora PostgreSQL のどの機能に置き換えることができるかについて説明します。 ジャーナルの置き換え Amazon QLDB では、基になるジャーナルには、クエリステートメントやデータ定義コマンドを含む、コミットされたすべてのトランザクションの不変なレコードが格納されます。ジャーナルのトランザクション履歴は Amazon Simple Storage Service (Amazon S3) バケットにエクスポートして、監査目的でアクセスできます。Amazon Aurora PostgreSQL は、変更に関する永続的で不変なレコードを保持しません。代わりに、その履歴を監査データとして生成し、データベースの外部に保存する必要があります。 Amazon Aurora PostgreSQL は オープンソース監査ロギングエクステンションである pgAudit をサポートしています。これにより、PostgreSQL の標準のロギングと比べてきめ細かなセッションおよびオブジェクトの監査ロギングが可能になります。DDL 操作、読み取り、書き込み、ロールと権限の変更、関数の実行、バキュームやチェックポイントなどのユーザー開始操作などの監査するイベントを選択できます。ログ出力は、Amazon RDS コンソールからアクセスできる標準の postgres.log ファイルに送信され、 最大 7 日間保存 できます。監査ログデータを永続的に保持するには、 ログを Amazon CloudWatch Logs に送信するように Aurora クラスターを設定 して、ログを無期限に保持することができます。 Amazon CloudWatch Logs は、ログのクエリ、モニタリング、アラート、および管理機能を提供します。CloudWatch Logs は保存時にログファイルを暗号化します。ログの削除を禁止する機能を含め、 AWS Identity and Access Management (IAM) を使用して CloudWatch Logsへのアクセスを管理できます。 CloudWatch Logs は、監査人がデータベース監査を行う際に使用するのが難しいインターフェイスかもしれません。「 Amazon S3 と Amazon Athena を使用して Amazon RDS for PostgreSQL の一元化された監査データ収集を構築する 」という投稿では、監査人が監査データをクエリするためのわかりやすいインターフェイスを提供するソリューションを提供しています。このソリューションでは、 Amazon Data Firehose を使用してデータベースのログを CloudWatch Logs から Amazon S3 に送信し、 Amazon Athena を使用して SQL でクエリを実行できます。次の図は、このアーキテクチャを示しています。 history() 関数の置き換え Amazon QLDB history() 関数を使用すると、テーブル内のすべてのレコードのすべてのリビジョンにアクセスできます。history() 関数を使用して、時間の経過とともにデータレコードがどのように変化したかを確認できます。別のテーブルの行に加えられた変更のコピーを格納する監査テーブルを使用して、この機能を Amazon Aurora PostgreSQL で複製できます。 監査テーブルの従来のアプローチは、監査対象のテーブルの構造を反映したテーブルです。トリガーは、メインテーブルの INSERT、UPDATE、DELETE のたびに実行されて、監査テーブルに変更された行のコピーを送信します。この方法のバリエーションでは、監査された行が JSON として保存されるため、ソーステーブルの構造が変更された場合に監査テーブルの構造を変更する必要がなくなります。テーブル権限は、監査テーブル内の行の変更を禁止するように設定されています。次の図は、この設計を示しています。 このアプローチは、正しい権限があればユーザーが監査テーブルのデータを変更できるという点で Amazon QLDB のHistory とは異なります。データアクセス権限の監査は、監査テーブル内のデータの整合性を維持するために重要です。監査テーブルを安全な専用の監査データベースに分離することで、この問題が解消され、監査データの信頼性が高まります。「 Amazon Aurora PostgreSQL テーブルの監査記録を作成する 」という投稿では、次の図に示すように、 AWS Database Migration Service (AWS DMS) を使用してソースデータベースの変更を取得し、監査データベースに安全に保存するソリューションを提供しています。 Amazon QLDB streamsの置き換え Amazon QLDB streams は、ニアリアルタイムで台帳イベントを Amazon Kinesis Data Streams にフィードします。ストリームレコードには、台帳へのデータ更新と、データベースで実行されたクエリステートメントのレコードが含まれます。ストリームを使用して、台帳から他のシステムにデータを複製できます。ストリームイベントをニアリアルタイムで分析して、疑わしいアクティビティや重要なテーブルやデータへの変更を特定できます。 データレプリケーション Aurora をプライマリデータベースとして使用する場合、AWS DMS を使用して Aurora から他のシステムにデータをレプリケーションできます。AWS DMS は、1 回限りのデータ移行用だけではありません。ソースの Aurora PostgreSQL データベースから変更データキャプチャ (CDC) を使用して 1 つ以上のターゲットデータベースへの継続的なレプリケーションをサポートしています。Amazon QLDB ストリームを使用してデータをレプリケートする場合とは異なり、AWS DMS を介して Amazon Aurora PostgreSQL からデータをレプリケートする場合、追加のコーディングは必要ありません。AWS DMS は、宣言型 JSON 構文を使用して、ソースデータベースとターゲットデータベース間でデータをマッピングおよび変換します。 ニアリアルタイムの監査 Amazon Aurora PostgreSQL を使用してニアリアルタイムの監査機能を利用するには、 Database Activity Streams を使用できます。Database Activity Streams は、Aurora クラスターから Kinesis Data Stream に低レベルの監査情報をニアリアルタイムでフィードします。Amazon QLDB ストリームと同様に、監査イベントをフィルタリング、分析、処理するカスタム Kinesis Data Stream コンシューマーを構築できます。Database Activity Streams は、Amazon QLDB が提供するものよりもはるかに幅広く監査のデータポイントをキャプチャします。Aurora は Amazon QLDB のように DML イベントと DDL イベントを報告しますが、接続、ロールと権限の変更、関数の実行、バキュームやチェックポイントなどのユーザー開始操作も報告します。Database Activity Streams と Amazon QLDB ストリームの主な違いは、Amazon QLDB はコミットされたトランザクションのアクションのみを報告するため、読み取り後にトランザクションをキャンセルすることで、ユーザーが検出されない読み取りを実行できることです。Aurora は、コミットされていないトランザクションも含め、すべてのアクションをアクティビティストリームに報告します。 Database Activity Streams は、データベース管理者のアクティビティの信頼できるログを提供します。Aurora クラスターのアクティビティストリームのアクティベーションはデータベースの外部で実行され、その操作へのアクセスはデータベース権限ではなく IAM 権限によって制御されます。データベース管理者には、監査データの収集や Kinesis Data Stream への公開を妨げるだけの十分なアクセス権がありません。また、データベース管理者は Kinesis Data Stream 内の監査データにアクセスできないため、そのデータの処理を妨害することはできません。 Amazon QLDB では、基礎となるジャーナルにはコミットされたすべてのトランザクションの不変なレコードが格納されます。ジャーナルのトランザクション履歴には、テーブルの history() 関数をクエリするか、Kinesis Data Streams を介してジャーナルを再ストリーミングすることで、いつでもアクセスできます。この機能は Database Activity Streams には存在しません。 ストリーミングされた監査データの有効期限が切れると、そのデータは失われます。監査データを保持するには、Amazon Data Firehose を使用してストリーミングされた監査イベントを 、Amazon S3 に保存することで無期限に保持できます。「 Filter Amazon Aurora database activity stream data for segregation and monitoring 」という投稿では、Firehose を使用して監査イベントをフィルタリングして Amazon S3 に送信して長期保存するソリューションを記載しています。 pgAudit と Aurora Database Activity Streams による監査の詳細については、「 Part 1: Audit Aurora PostgreSQL databases using Database Activity Streams and pgAudit 」を参照してください。 まとめ この投稿では、監査機能および変更履歴機能を提供する Amazon Aurora PostgreSQL の機能について説明しました。この機能は、監査ユースケース向けに Amazon QLDB が提供する独自の機能の一部に取って代わることができます。 次の記事「 Amazon QLDB のAmazon Aurora PostgreSQL への移行 」では、Amazon QLDB 台帳から Amazon Aurora PostgreSQL にデータを移行するのに役立つソリューションを提供します。 台帳移行の計画や、Amazon Aurora PostgreSQL が台帳データの適切な保存先であるかどうかの判断については、AWS の担当者にお問い合わせください。 著者について Dan Blaner は、台帳とリレーショナルデータベースを専門とするプリンシパルソリューションアーキテクトです。彼は学ぶこと、物事を理解すること、他の人が物事を理解するのを助けることを楽しんでいます。休みはベースを弾き、仲の良い友達とbad music 作りを楽しんでいます。

はじめに 6 月 20 日と 21 日の 2 日間にわたり、幕張メッセにおいて 13 回目となる AWS Summit Japan が「AWS と創る次の時代」をテーマに開催され、会場では 3 万人以上、オンラインも合わせると過去最高となる 5 万人超の方の参加者を記録しました。私たちは 2 年目の新入社員有志でチームを作り、&nbsp;“ 新入社員プロジェクト生成AI を活用した&nbsp;Virtual Summit Assistant ” というタイトルでブース展示を行いました。当日は絶えず沢山の来場者の方々にブースにお越しいただき、アプリケーションを体験していただきました。このブログでは、“ 新入社員プロジェクト生成AI を活用した&nbsp;Virtual Summit Assistant ” の展示内容をダイジェストでご紹介します。展示に使われている AWS サービスやアーキテクチャの詳細な紹介については個別の解説ブログを発行予定です。 “新入社員プロジェクト生成 AI を活用した Virtual Summit Assistant” とは 展示内容の説明に入る前に、まず私たちがどのような課題から今回の展示作成に至ったのかについてお話しします。以前 AWS Summit に参加した際にAWS Summit に来場者として訪れた際に感じた 2 つの課題がありました。1 つ目は、会場が広く、目的地に辿り着けないということです。Summit 会場では 250 を超える展示があり、自分が見たいブースがどこにあるのかわからないことがありました。2 つ目は「どのセッション・ブースを訪ればいいのかわからない」というものです。去年 Summit に参加した際、入社数ヶ月だった私たちは、AWS に関する知識がまだ浅く、様々なセッションやブースの中から、自分の興味分野やレベルにあったものを探すのは難しかったため、自分の好みを反映したおすすめを教えてほしいという声がありました。 そこで私たちはアバターが Summit 会場の案内とおすすめセッションを教えてくれる Virtual Summit Assistant を開発しました。このプロダクトは画像のようなアバターに今回の AWS Summit に関する情報、例えばセッションやブースに関する質問をすることで、回答を返してくれるバーチャルアシスタントです。 この展示のアーキテクチャは以下のようになっています。 Virtual Summit Assistant の中心は、 Amazon Simple Storage Service &nbsp;(S3)、 Amazon Kendra 、 Amazon Bedrock &nbsp;を用いた検索拡張生成 (RAG, Retrieval Augmented Generation) です。Web ユーザーインターフェースは、 Amazon CloudFront と Amazon S3 によって提供されています。アーキテクチャは、 Amazon Cognito 、 Amazon Transcribe 、 Amazon Polly などの複数のマネージドサービスによってサポートされています。Web ユーザーインターフェースは、ユーザー登録と認証用のための&nbsp; Amazon Cognito 、 Amazon Transcribe &nbsp;と&nbsp; Amazon Polly &nbsp;を用いて入力音声の書き起こしと回答文を音声出力へ変換しています。 検索拡張生成 (RAG, Retrieval Augmented Generation) は、大規模言語モデルで回答の精度を向上させるための手法です。RAG を使わない構成ではユーザーが基盤モデルに何か質問をする際、ユーザーはアプリを介して質問を送り基盤モデルが質問内容を受け取って回答を生成しますが、この方法では基盤モデル学習時に学んだデータを元に回答を生成するため、学習をしていない知識、例えば今回の Summit に関する情報や、外部公開されていない企業独自の情報は回答できません。そのような課題の解決に有効なアプローチが RAG になっています。 RAG では従来の構成に加えてナレッジソースと呼ばれるデータソースを用意します。ナレッジソースには、基盤モデルが回答を生成する際に参考にしてほしいデータを入れておきます。ユーザーが質問した際は、一旦ナレッジソースに問い合わせを行い質問に関連するデータを抽出します。そして、抽出したデータとユーザーからの質問を合わせて基盤モデルに送信し、基盤モデルはナレッジソースのデータを参考にしながら回答を生成します。こうすることで、基盤モデルは学習していないデータに関しても正確な情報を回答できるようになります。今回の場合はナレッジソースとして&nbsp;Amazon S3 を使用し、Amazon S3 内に Summit のセッションやブースに関する情報を txt 形式で格納しています。 Generative AI Avatar Chat を用いた開発 今回の開発ではアーキテクチャの設計や開発を、一から行った訳ではなく Generative AI Avatar Chat と呼ばれるサンプルアプリケーションをもとにカスタマイズを加える形で行いました。このサンプルアプリケーションを使うと、3D アバターをインタフェースとして持つ生成 AI チャットボットを簡単に構築できます。デフォルトで RAG の構成も実装されるため、情報を追加することで専門知識や社内情報を含めた回答を行うことも可能です。質問文の入力には文字または音声を利用可能です。こちらのアプリケーションコードは AWS リソースを用いたソリューションを提供している AWS Samples にて公開されており、AWS CDK のデプロイにより数ステップで構築ご利用いただけます。 今回のプロジェクトは、業務の合間時間を使いながら約 3 ヶ月で完成させなければならないというタイトなスケジュールでしたが、このようなサンプルアプリケーションをベースに、自分たちでカスタマイズを加えることで短い期間でも開発を行うことができました。 ブース紹介 当日は絶えずたくさんの来場者の方々にブースにお越しいただきました。著者も当日ブース対応を担当しました。このアシスタントは会場内の 5 箇所、計 9 台の Kiosk 端末で設置しました。お客様からは、「このようなアシスタントが案内してくれると、店舗人員を減らせてよい。」「アバターと RAG で使用するドキュメントを変えるだけで様々な環境やユースケースに対応可能で良い。」や、「新卒が業務の合間にここまで作れるなんて、自分たちのカリキュラムにも組み込みたい。」など、アプリケーションや新入社員プロジェクトなど、様々な側面からフィードバックをいただきました。 最後に 以上、私たちが本展示の開発過程、主な機能、Summit 当日の様子をご説明しました。最後に新入社員開発プロジェクトを通して学んだことを 3 つご紹介します。1 つ目はチーム内外とのコミュニケーションです。Summit という大きなイベントでのブース展示、登壇を行う過程で非常に多くの方にご協力いただきました。その中で開発における役割分担、議論の記録の取り方、複数人でコミュニケーションを取る場合の文書化の重要性など、多くの人を巻き込んだプロジェクトにおけるコミュニケーションの取り方について学びを得ました。2 つ目として新年度から開発がスタートした本プロジェクトは日々の業務の両立をどう行うのか、特に各メンバーの役割と進捗の管理など、プロジェクトのマネジメントに関する経験がとして得られました。 最後はユーザ目線の開発経験です。開発経験の少ない新卒メンバーが、Summit ユーザーの視点を元にした課題定義、発案、開発までの一連の流れを体験することができたのは、ペインポイントの整理からニーズベースでの開発という意味で大きな経験になりました。 開発メンバーとブースの様子 今回、開発したVirtual Summit Assistant は空港、ショッピングモール、病院、イベント会場などの施設案内を必要とするような場所への導入が考えられます。自然言語により質問が可能なため、ユーザーはより自分の希望に合った案内を受けることができますし、アバターや音声入力といった親しみやすさにより、小さなお子様や高齢者の方も簡単にご利用いただくことが可能です。このような商業施設への導入という観点では、さらなる追加機能の例として、アクセスするデータソースや API の種類を増やすことで、情報提供の幅を増やす。例えば、混雑情報のようなリアルタイムで変化する情報の提供などから、レストラン予約といったアクションをこのアバターが推薦できるなどが新機能として考えられます。 実際に Summit に参加されたお客様から、「案内板に付加価値をつけることが可能。イベントで使用したい。」「無人店舗を検討中のため使用してみたい。」などのフィードバックをいただきました。このように様々なユースケースで使用していただけるのではないかと思っています。このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWS 担当営業もしくはこちらの窓口 ( https://aws.amazon.com/jp/contact-us/ )までご連絡ください。 著者について 松本 敢大 (Kanta Matsumoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。 好きな AWS サービスは AWS IoT Core。 趣味はカメラで、犬が好きです。 &nbsp; &nbsp; &nbsp; &nbsp; 中本 翔太 (Shota Nakamoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は飲食、旅行など、サービス業のお客様を中心に技術支援を行っています。 好きな AWS サービスは Amazon Bedrock。 &nbsp; &nbsp; &nbsp; &nbsp; 大久保 裕太 (Yuta Okubo) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は不動産、建設業のお客様を中心に技術支援を行っています。 好きな AWS サービスは Amazon Kinesis Video Streams と Amazon Braket。 &nbsp; &nbsp; &nbsp; &nbsp; 池田 優 (Yu Ikeda) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は金融業のお客様を中心に技術支援を行っています。 好きな AWS サービスは&nbsp;Amazon Elastic Compute Cloud。 &nbsp; &nbsp;