この記事は Introducing configurable TCP idle timeout for Gateway Load Balancer を翻訳したものです。 Amazon Web Service (AWS) Gateway Load Balancer (GWLB) は、サードパーティのファイアウォールアプライアンスをデータ経路に挿入できるマネージドな AWS サービスです。 GWLB は、サードパーティアプライアンスのデプロイ、スケーリング、管理を支援し、「Bump-in-the-Wire」デバイスとしてトラフィックをターゲットに透過的に渡します。顧客は、トラフィック検査のユースケースにおいて、GWLBターゲットとしてサードパーティのファイアウォールアプライアンスをデプロイします。詳細については、 GWLB ドキュメント を参照してください。 GWLBの設定可能なTCPアイドルタイムアウト機能を紹介します。この機能により、GWLB の Transmission Control Protocol (TCP) アイドルタイムアウトを60秒から6000秒の範囲で設定できるようになります。 この投稿では、この機能の基本と利用のベストプラクティス、および AWSマネジメントコンソール  と API を使用してセットアップする方法について説明します。 前提条件 以下のセクションでは、仮想プライベートクラウド ( VPC ) 、サブネット、 VPC ルーティングテーブルなどの基本的な AWS のネットワーキングサービスを理解していることを前提としています。また、 GWLB のターゲットとしてサードパーティのファイアウォールをセットアップする方法を理解していることも前提とします。 GWLB アーキテクチャの詳細については、 GWLB の投稿 を参照してください。 GWLB の TCP アイドルタイムアウトとは？ GWLB は、フローの最初のパケットを確認するとフローテーブルにフローエントリを作成します。 GWLB は、2 タプル、3 タプル、または 5 タプルのハッシュを使ってフローを定義し、フローのすべてのパケットをバックエンドターゲットの1つにルーティングします。 GWLBは、各フローエントリを1つのバックエンドターゲットアプライアンスに結びつけることで、トラフィックの対称性を維持します。このトラフィックの対称性は、トラフィック検査やファイアウォールのユースケースにおいて必要不可欠です。 GWLB は、そのフローのパケットが GWLB を通過する限り、フローをアクティブと見なします。フローのパケットが停止すると、そのフローはアイドルと見なされ、アイドルタイマーが開始されます。所定のアイドル時間が経過すると GWLB はフローテーブルからフローエントリを削除します。 なぜ GWLB に設定可能な TCP タイムアウトが必要か？ これまで、GWLB は固定のTCPアイドルタイムアウト値 (350秒) をサポートしていました。アイドルタイムアウト後に GWLB に到着するパケットは新しいフローと見なされ、別のターゲットに転送される可能性がありました。 しかし、多くのファイアウォールやレガシーデータベースなどのアプリケーションは、デフォルトの TCP アイドルタイムアウト値としてより長い時間が設定されています。 GWLB とアプリケーションのタイムアウト値の不一致により、アプリケーション側で長時間アイドル状態だったフローが GWLB のタイムアウトによって異なるターゲットに転送され、トラフィックフローの中断を引き起こす可能性があります。 GWLBの設定可能なTCPアイドルタイムアウト機能を使用すると、ファイアウォールやアプリケーションの TCP アイドルタイムアウト値を GWLB と合わせることができ、トラフィックフローの継続性を確保し、トラフィックの中断を減らすことができます。 Palo Alto Networks 、 Fortinet 、 Cisco 、 Check Point などのサードパーティのファイアウォールは、350 秒を超える TCP アイドルタイムアウト値をサポートしており、デフォルトの TCP アイドルタイムアウト値が 3600 秒に設定されていることもよくあります。このGWLB とターゲットアプライアンスの TCP アイドルタイムアウト値の不一致により、トラフィックが中断する可能性があります。図1a、図1b にて、トラフィック中断につながる構成例と一連の動作を示します。このシナリオでは、バックエンドのファイアウォールアプライアンスのTCPアイドルタイムアウト値はデフォルトの60分を使用している想定です。 図1a は、フローが最初に確立されたときの GWLB とバックエンドファイアウォールアプライアンスのフローテーブルを示しています。 図1a: 新規フロー確立時の GWLB とファイアウォールのフローテーブル [1] VPC – 1 にデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが、TCP フローを開始し、Availability Zone (AZ) – b の GWLB エンドポイント (GWLB-EP B) にデータを送信します。 [2] GWLB – EP Bはトラフィックをファイアウォール VPC にデプロイされた GWLB に送信します。 [3] GWLB はこのフローをフローテーブルに見つけられないため、新しいフローエントリを作成します。TCP アイドルタイムアウト値は 350 秒に設定されます。GWLB はこのフローのバックエンドターゲットとして T2 を選択します。 [4] GWLB は元のトラフィックを GENEVE トンネルにカプセル化し、このデータを T2 に送信します。 [5] T2はテーブル内に新しいフローエントリを作成し、TCP アイドルタイムアウト値を 3600 秒に設定します。 データフローが停止すると、GWLB の TCP アイドルタイムアウトがトリガーされます。図1bは、データフローが停止してから350秒後の GWLB とバックエンドファイアウォールのフローテーブルを示しています。 [6] Flow-1 の GWLB TCP アイドルタイムアウトが期限切れになります。この時点で、GWLB はフローテーブルからこのフローエントリを削除します。 [7] バックエンドのファイアウォールアプライアンスは、フローエントリをテーブルに保持します。アイドルタイマーは 3250 秒になります。 図1bは、送信元のEC2インスタンスが同じフローの他のパケットを送信したときの一連の動作を示しています。 図1b: トラフィックフローが再びアクティブになったときのGWLBとファイアウォールのフローテーブル [8] 350秒以上アイドル状態が続いた後、ソースのEC2インスタンスが同じフローの他のパケットを GWLB-EP B に送信します。 [9] GWLB-EP B はトラフィックを GWLB に送信します。 [10] GWLB はこのフローをフローテーブルに見つけられないため、GWLB はこのフローを新規のフローと見なし、新しいフローエントリ (Flow-2) を作成します。アイドルタイムアウトは 350 秒に設定されます。今回は GWLB のハッシュアルゴリズムによって T1 がこのフローのバックエンドターゲットとして選択されます。 [11、12] T1 はパケットを受信しますが、 TCP フローであるためパケットをドロップします。これは、ステートフルファイアウォールでは、TCP フローのトラフィックを同じファイアウォールアプライアンスに対称的にルーティングする必要があるためです。この場合、T1 はこのフローの TCP ハンドシェイクを見ていないため、このフローを拒否します。これにより、トラフィックが中断します。 ステップ [10] は、GWLB がクロスゾーンロードバランシングを有効にしていることを前提としています。ただし、クロスゾーンロードバランシングが無効で、同じAZに複数のファイアウォールアプライアンスがデプロイされている場合でも、ステップ [11] と [12] で説明した問題が発生する可能性があります。 設定可能なTCPアイドルタイムアウトをどのように使用するか? GWLB の IP リスナーに対して TCP アイドルタイムアウトを設定できます。この設定は IPv4 トラフィックと IPv6 トラフィックの両方に適用されます。 ステップ 1: GWLB リスナーの詳細を編集する GWLB の詳細ページで、 [Actions] を選択し、 [View listener details] を選択します (図 2 参照)。 図 2: GWLB リスナーの詳細 ステップ 2: TCP アイドルタイムアウト値を編集する GWLB の [Attributes] タブで、TCP アイドルタイムアウトの詳細を編集 [Edit] します (図 3 参照)。 図 3: TCP アイドルタイムアウトを編集する 希望の TCP アイドルタイムアウト値を入力し、変更を保存します (図 4 参照)。 図 4: TCP アイドルタイムアウト値を入力する 新しく導入された modify-listener-attributes アプリケーションプログラムインターフェイス (API) 呼び出しを使用して、TCP アイドルタイムアウト値を編集できます。 aws elbv2 modify-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:<Region>:<AWS Account ID>:listener/gwy/<GWLB name>/<GWLB ID>/<Listener ID> \ --attributes \ Key=tcp.idle_timeout.seconds,Value=3700 modify-listener-attributes API 呼び出しを使用する際は、TCP アイドルタイムアウト値をキーと値のペアとして指定する必要があります。 elbv2 CLI ドキュメントを参照して、サポートされているコマンドの完全なリストを確認してください。 ステップ 3: 新しい構成を確認する 図 5: GWLB IP リスナーの新しい TCP アイドルタイムアウトを確認する ステップ 4: Amazon CloudWatch メトリクスを使用して監視する GWLB は、タイムアウトしたフローの総数を監視できる新しい Amazon CloudWatch メトリクスをサポートするようになりました。 RejectedFlowCount と RejectedFlowCount_TCP メトリクスを使用して、拒否されたフローの総数と拒否された TCP フローの総数を監視できます (図 6 参照)。これらのメトリクスは、GWLB のフローテーブルが上限に達し、 GWLB がフローを拒否した場合にのみ増加します。GWLB の TCP アイドルタイムアウトは徐々に増やすことをお勧めします。 図 6: RejectedFlowCount メトリクスを使用した CloudWatch アラーム GWLB TCP アイドルタイムアウト値の設定に関する推奨事項 GWLB の TCP アイドルタイムアウトに非常に高い値に設定すると、GWLB はフローエントリをフローテーブル内でより長い期間アクティブに保ちます。そのため、GWLB のフローテーブルが大きくなります。これにより、GWLB のフローテーブルサイズを使い果たすリスクが生じます。このリスクを軽減するために、GWLB のフローテーブル内の使用可能なフロー数を示す AvailableFlowCount CloudWatch メトリクスを監視することをお勧めします。 長期実行フローのあるアプリケーションに関する推奨事項 このセクションでは、インライントラフィック検査のユースケースでトラフィックの中断を回避するために、GWLB の設定可能な TCP アイドルタイムアウト機能を使用する 3 つの推奨事項について説明します。 推奨事項 1: GWLB の TCP アイドルタイムアウト値を、ファイアウォールアプライアンスの TCP アイドルタイムアウト値よりわずかに高い値に設定することで、トラフィックの中断を回避できます。また、ファイアウォールアプライアンスが TCP セッションがタイムアウトしたときに TCP RST を送信するように設定することをお勧めします (サポートについてはファイアウォールベンダーに確認してください)。長期間アイドル状態が続く TCP フローにおいて、この設定より、バックエンドのファイアウォールターゲットがフローをタイムアウトさせることができます。バックエンドファイアウォールからの TCP RST により、クライアントの TCP セッションが適切に閉じられます。この構成により、クライアントデバイスやアプリケーションのコードを変更せずに、検査アーキテクチャを展開できます。 この構成は、TCP キープアライブをアプリケーションコード内に実装できない従来のアプリケーション、および Red Hat Enterprise Linux などの基盤となる OS のデフォルト設定を継承するアプリケーションに対して推奨されます。大規模なレガシーアプリケーションを抱えており、すべてのアプリケーション/クライアント/サーバーをアップグレードするためには長期間のメンテナンスウインドウが必要となる場合、この方法は実用的なアプローチです。 推奨事項 2: クライアント/サーバーの TCP アイドルタイムアウト値を、GWLB またはファイアウォールアプライアンスよりも低い値に設定します。これにより、クライアントまたはサーバーが、 GWLB またはファイアウォールアプライアンスでタイムアウトする前に、接続を適切に更新できるようになります。このアプローチでは、すべてのクライアント/サーバーを更新する必要があります。詳細については、 Implementing long-running TCP connections within VPC networking を参照してください。この方法は優れた解決策ですが、すべてのクライアント/サーバー/アプリケーションを更新する必要があります。 推奨事項 3: アプリケーション内で TCP キープアライブを実装します。これにより、クライアント/サーバーが TCP キープアライブを送信して TCP セッションを維持できるようになります。このオプションでも、アプリケーションを変更する必要があります。 表 1 にこれらの推奨事項の概要を示します。   必要な構成変更 作業量 推奨事項 1 GWLB タイムアウト値 > ファイアウォールのタイムアウト値に設定 低 GWLB のみ構成する必要あり。 推奨事項 2 クライアント/サーバーのタイムアウトを GWLB/ファイアウォールのタイムアウトより短く設定 高 すべてのクライアントまたはサーバーを更新する必要あり 推奨事項 3 アプリケーション内で TCP キープアライブを設定 高 すべてのアプリケーションを更新する必要があり 表 1 :推奨事項の概要 短期間のフローに関する推奨事項 アクティブなフローの総数は、GWLB の使用コストを決定する要素の 1 つです。TCP セッションが短期間で終了すると予想されるアプリケーションの場合、GWLB の TCP アイドルタイムアウト値を減らすことで、GWLB の使用量を最適化できます。このようなユースケースでは、GWLB の TCP アイドルタイムアウト値を予想されるセッション期間よりわずかに長い値に設定することをお勧めします。 このような要件は、一般的に、パトロールカー、救急車、軍用車両などのデバイスが、複数のセルラーネットワークやモバイルネットワーク事業者（MNOs）を使用して AWS にデータをストリーミングする場合に見られます。デバイスのセッションは、異なる MNOs 間を切り替えるたびに途切れ、アプリケーションコードが新しい TCP セッションを作成します。 留意事項 GWLB の既存のフローは、TCP アイドルタイムアウト値を変更しても影響を受けません。それらのフローのトラフィックは中断されずに続行されます。新しい TCP アイドルタイムアウトは、GWLB の新しいフローエントリにのみ適用されます。 TCP キープアライブは、GWLB の TCP アイドルタイムアウト値を更新します。 アイドルタイムアウト値は、IPv4 と IPv6 の両方に適用されます。 RejectedFlowCount_TCP メトリクスは、その値がゼロ以外の場合にのみ CloudWatch で利用可能になります。つまり、GWLB のフローテーブルがいっぱいになり、GWLB が TCP フローを拒否し始めた後にこのメトリクスを使用できるようになります。 結論 この投稿では、GWLB の TCP アイドルタイムアウト値を 60 秒から 6000 秒の範囲で設定できる新機能を紹介しました。コンソールと API を使用してこの機能を使用する方法を説明しました。さらに、長期間のフローと短期間のフローの両方に対するこの機能の使用に関するベストプラクティスと、環境に適した値を設定するために特定の CloudWatch メトリクスを監視する推奨事項についても説明しました。 この機能の詳細については、 ドキュメント をご覧ください。 この記事の著者は Milind Kulkarni と Ankit Chadha です。

6 月 20 日と 21 日の 2 日間にわたり、幕張メッセにおいて 13 回目となる AWS Summit Japan が開催され、会場では 3 万人以上、オンラインも合わせると過去最高となる 5 万人超の方の参加者を記録しました。本イベントでは 150 以上のセッションと 250 以上のブース展示が行われ、AWS の最新情報が共有されました。 物流業担当チームでは「倉庫ｘ生成AIからの物流DX」と題しまして、Amazon Bedrock をはじめ Amazon QuickSight、Amazon Location Service 等 を活用した高度な在庫管理に関するデモを行いました。多くのお客様にお立ち寄りいただき会話させていただく中で、生成AIに対する期待値の高さと倉庫の在庫管理に関する課題の大きさを感じました。本ブログではデモの内容とそれに使われたサービスやアーキテクチャについて解説いたします。 本デモは「生成AIってQAツール的な使い方では浸透してきているけど、基幹システムのような既存の仕組みとの連携という観点ではまだ進んでいないよね」、「生成AIを活用して業務改善しろ、と言われているけど具体的に何をやったら良いかわからない」という現状に対する一つの提案として企画がスタートしました。企画を進めるにあたり「こういった課題もあるんじゃないか」という形で発想が広がり、最終的なデモの形となりました。以下がデモの全体像となります。シナリオとしてドラッグストアの在庫倉庫をイメージしています。 以下がデモのアーキテクチャ図になります。倉庫在庫データを管理するため、ダミーの Warehouse Management System (WMS) を Amazon Aurora 上に構築し、WMSに対する操作を Amazon API Gateway で API として提供しています。WMS は、入出庫、在庫、ピッキング、棚卸などの倉庫業務を効率化・最適化するためのソフトウェアシステムで倉庫を扱う企業で広く利用されています。また、今回のシナリオでは倉庫在庫だけではなく店舗在庫も管理しています。店舗在庫の管理システムとしては Amazon Dynamo DB を利用しています。 デモのシナリオを順を追って説明します。 ① 入庫 工場で生産した製品を物流拠点となる在庫倉庫に入庫します。従来の倉庫では、それぞれの製品を在庫管理するために、バーコードやQRコード、RFID（Radio Frequency Identification）タグなどを貼り付けてあります。デモでは、RFIDの一種であるNFC（Near Field Communication）タグを使用して在庫管理を実現し、Android 端末のChromeブラウザに搭載されたWebNFC APIを利用したWebアプリケーションをNFCタグを読み取ることで、倉庫管理システムへの入庫登録処理が完了します。NFC は導入コストの関係から採用しましたが、読み取り速度や複数読み取りの要件があるケースでは少し使いづらいかもしれません。 こういった要件があるケースではカメラによるバーコード（QR含む）の一括読み込みや、RFIDタグの一種であるUHF帯タグが選択されます。読み取りのWebアプリケーションは Amazon CloudFront + Amazon S3 の静的ホスティングを利用しています。 入庫処理用の画面 ② 在庫確認（倉庫側） 倉庫側の在庫確認する仕組みとして Amazon QuickSight を利用しています。Amazon QuickSight は様々な業界やユースケースで利用可能なビジネスインテリジェンスツールです。デモは在庫数の割合や各拠点の在庫数の分布等をダッシュボードで表現しました。Amazon QuickSight はマルチデバイスに対応しているため、常設のモニタに KPI を投影したり、倉庫内を頻繁に移動する社員がモバイルデバイスで状況を確認したりと、幅広い活用が可能です。このようにダッシュボードを利用し、在庫切れリスクの早期発見、適正在庫数の維持、需要予測と備蓄計画の立案に活用いただけます。 また、Amazon QuickSight の大きな魅力はデータソースの選択肢が豊富なことです。AWS サービスである Amazon S3 や Amazon Redshift はもちろん、リレーショナルデータベースの Oracle や PostgreSQL、SaaS のデータプラットフォームである Snowflake など、様々なデータソースをサポートしています。今回は WMS の リレーショナルデータベースである Amazon Aurora をデータソースとして参照し、データベース内の入庫情報と出庫情報を基に、リアルタイムで在庫状況をダッシュボード上に表示しています。 ③在庫確認、発注指示（店舗側） 店舗のスタッフが店舗内の在庫状況を確認したり、倉庫に対して店舗への発注指示をするための仕組みとして Agents for Amazon Bedrock を活用したチャット用のWebアプリケーションを開発しました。今回はわかりやすくデモをお見せするために、簡略化して発注完了＝出荷完了としています。 この機能の実装にあたっては Agents for Amazon Bedrock を活用しています。Agents for Amazon Bedrock では「アクショングループ」という形で機能を定義しておくことで、Agent 経由で定義された機能を呼び出すことができます。 今回は事前に Agent が質問に応じて適切にアクションができるようアクショングループに以下5つの処理を登録しました。 倉庫に対する発注リクエストは、WMS の Amazon Aurora に アクセスして、発注希望数＜在庫数の場合は満たす場合は発注と倉庫在庫数の更新を行い、発注完了のメッセージと、発注番号を返す。発注希望数＞在庫数となる場合は、在庫が足りていないため発注不可を返す。 商品の情報確認リクエストは、WMS の Amazon Aurora にアクセスして商品情報を返す。 店舗在庫の確認リクエストは、店舗用の Amazon DynamoDB にアクセスして在庫情報を返す。 過去の発注履歴リクエストは、店舗用の Amazon DynamoDB にアクセスして発注履歴情報を返す。 発注番号をもとにした配送状況確認リクエストは、配送状況マップの URL を返す。 それぞれのアクションは各 AWS Lambda で実行されています。 自然言語で質問をすると、Agent が質問内容を解釈して、どのアクションを実行するのが適切か判断し、そのアクションの実行結果を返してくれます。 もし、アクションを実行するのに足りない情報がある場合(例えば、発注に関するリクエストが来た際に、商品名または、発注希望数の値が不足している場合)、必要な情報をユーザから収集します。 この仕組みにより、これまで店舗のスタッフが業務ごとに複数のインターフェースを使って作業を行っていたことが、1 つのインターフェースだけで完結することができます。 現在は発注処理を行うには、人が発注内容を確認して出荷処理を行うことが一般的ですが、Agents for Amazon Bedrock をうまく活用することで生成 AI によって発注内容の確認から出荷処理まで自動化することで省人化、出荷までのリードタイムの短縮化を実現できます。 また、発注完了後は、地理空間情報に関する処理を提供する Amazon Location Service によって、輸送状況をリアルタイムで確認することができます。AWS Summit Japan の会場である幕張メッセを倉庫とし、ドラッグストアである AWS 目黒オフィスまでの輸送をデモとして紹介しました。 輸送車のデジタコやモバイル端末から位置情報を取得し、Amazon Location Service のマップ上に表示させることで、渋滞など交通状況を踏まえた最適ルートを案内させることで輸送業務の最適化に繋げることができます。 まとめ このブログでは、AWS Summit Japan 2024 物流業界向けブースのデモ 「倉庫ｘ生成AIからの物流DX」の内容をご紹介しました。物流業界は2024年問題を始め解決すべき課題が山積しています。これら課題を解決する有力な手段が生成AIと考えます。今回のデモでお示したように、生成AIを活用した自然言語によるインターフェースで、デジタルに詳しくない作業員でも、簡単に在庫管理システム等を操作できるようになり、生産性の向上が期待できます。さらに生成AIは、使い方によってはレガシーシステムの刷新やシステム開発の効率化にも貢献できます。物流が抱える課題の解決に向けて、生成AIの活用を検討してみてはいかがでしょうか。 このブログは、デモを開発したソリューションアーキテクト （横山、宇加治、稲田、駒野、三宅、山本） が執筆しました。

Amazon DocumentDB (with MongoDB compatibility) は、 ヘルスケア 、 ゲーム 、 金融 など、さまざまな分野でモダンアプリケーションを構築するお客様にメリットをもたらします。フルマネージド型のドキュメントデータベースであり、柔軟性、スケーラビリティ、高パフォーマンス、高度な機能によってユーザー体験を向上できます。Amazon DocumentDB がサポートする JSON データモデルを利用する企業は、半構造化データへの対応により、 アプリケーション開発の高速化 とデータの 読み取り速度の向上 を実現できます。 ある推計によると、 非構造化データは企業の新規データの 80 ～ 90% を占める 可能性があり、構造化データをはるかに上回る速度で増加しています。この傾向は、 生成 AI の新しい機会によって加速されています。AWS のお客様は、この技術をどのように活用し、自社の豊富なデータに適用できるかについて、ますます関心を寄せています。多くのお客様は、ベクトルデータベースエンジンを使用して、レコメンデーションエンジンを実装したり、リッチメディアを検索したり、クエリのコンテキストと意味に合わせてより関連性の高い文書を取得したりすることを検討しています。 最近の Amazon DocumentDB でのベクトル検索サポート などの機能リリースまでは、ワークロードにベクトル検索機能を実現するには、企業はデータをマネージドデータベースサービスから別のベクトルデータベースエンジンやサービスに連携させる必要があり、アーキテクチャのコストと複雑さが増加していました。このようなアーキテクチャの変更により、アプリケーションがドキュメントとは別の場所にエンベディングを格納および取得する必要があるため、さらにコード変更が必要になります。 既存の Amazon DocumentDB クラスターでセマンティック検索機能を有効にすると、最新の機械学習 ( ML ) および生成 AI ( AI ) アプリケーションを容易に構築できます。Amazon DocumentDB でベクトル検索を使用し、Amazon Bedrock や Amazon SageMaker などの AWS ML サービス、OpenAI、Hugging Face、LangChain などのサードパーティサービスと連携できます。また、ベクトルを元のドキュメントに格納できるようになりました。この機能は、HNSW インデックスのサポートによってさらに強化され、低レイテンシーでベクトル類似度検索を実行し、高い関連性の結果を生成できるようになりました。 この記事では、エンベディングを Amazon DocumentDB に正しくロードした後、LangChain を使用して大規模言語モデル (LLM) にクエリを行うチャットボットを作成する例を示します。 LLM による検索補助生成 Retrieval Augmented Generation (RAG) を使用すると、基盤モデルの外部からデータを取得し、取得された関連データをコンテキストとしてプロンプトに追加することで、プロンプトを強化できます。これは、エンドユーザーに対話型の体験を提供できるチャットボットを構築する際に有用です。企業のナレッジベースやコンテンツから、ユーザーのリクエストに最も関連する情報を取得し、ユーザーのリクエストとともにコンテキストとしてバンドルし、LLM に送信して生成 AI レスポンスを取得するため、直感的なインターフェースを提供します。 この例では、LangChain の PyPDFDirectoryLoader を使用して、 Amazon DocumentDB Developer Guide の PDF バージョンを取り込みました。これを使用して、サービスの機能、使用法、ベストプラクティスについて質問できるチャットボットを作成しました。完全なソリューションは、 amazon-documentdb-samples GitHub リポジトリにあります。 Amazon DocumentDB にデータをロードする前に、コレクションに HNSW インデックスを作成します: collection.create_index([("vectorContent","vector")], vectorOptions= { "type": "hnsw", "similarity": "euclidean", "dimensions": 1536, "m": 16, "efConstruction": 64}, name="hnsw") IVFFlat とは異なり、HNSW にはトレーニングステップが関与しないため、初期データロードなしでインデックスを生成できます。 開発者ガイドを LangChain の RecursiveCharacterTextSplitter を使用して分割した後、 Amazon Titan Embeddings G1 Text model (amazon.titan-embed-text-v1) を使用してエンベディングを作成します。 embeddings = BedrockEmbeddings(model_id= "amazon.titan-embed-text-v1", client=bedrock_client) INDEX_NAME = "hnsw" vector_store = DocumentDBVectorSearch.from_documents( documents=docs, embedding=embeddings, collection=collection, index_name=INDEX_NAME, ) 最後に、 Anthropic Claude for Amazon Bedrock  を 推論エージェント として初期化し、ユーザーが要求したタスクを複数のステップに分割します。 llm = BedrockChat(model_id="anthropic.claude-3-sonnet-20240229-v1:0", client=bedrock_client) ソリューションをテストするために、 PromptTemplate を作成し、 RetrievalQA チェーンを使用して、HNSW インデックスから質問に関連するドキュメントを収集します。これらのドキュメントを使用して、次のスクリーンショットに示すように、質問に対する一意の回答を作成します。 クエリ、チャット履歴、コンテキストを引数として受け取る RAG の使用例、および Amazon DocumentDB での集約パイプラインを使用したベクトル検索 の方法については、完全なノートブックを確認できます。 サマリー Amazon DocumentDB のベクトル検索は、JSON ベースのドキュメントデータベースの柔軟性と豊富なクエリ機能と、ベクトル検索の強力な機能を組み合わせたものです。 LangChain のような強力なフレームワークと、 Amazon Titan Text Embeddings のようなテキストエンベディング、そして Amazon Bedrock 経由でアクセスできる Anthropic の Claude 3 のような基盤モデルを使うことで、セマンティック検索体験、商品レコメンデーション、パーソナライゼーション、チャットボット、不正検知、異常検知などの ML と生成 AI ソリューションを構築できます。 既存のワークロードでベクトル検索を使い始めるには、 amazon-documentdb-samples GitHub リポジトリを参照し、この記事で説明した例をダウンロードしてください。 著者について この記事は、Andrew Chen, Cody Allen, Inderpreet Singh によって投稿された記事を翻訳したものです。 原文は こちら です。

生成 AI の普及が進む中で、活用方法に関する相談が増えています。 AWS のソリューションアーキテクトは、自分の能力を補完することを目的に、お客様に生成AIの活用を提案することがあります。本ブログでは、デザインの専門知識がないソリューションアーキテクトの私が、生成 AI を活用してデザインの能力を補い、ダッシュボードのデザインを改善した事例とその方法をご紹介します。対象のダッシュボードは AWS Summit 2024 Japan で展示した Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ です。 利用した生成 AI ソリューション AWS Japan のソリューションアーキテクトが利用した生成 AI ソリューションは aws-samples に公開している generative-ai-use-cases-jp (略称: GenU ) のチャット機能です。今回、生成 AI サービスは Amazon Bedrock、大規模言語モデル（ LLM : Large language Models ）は Claude-3-Sonnet を利用しました。 (図：generative-ai-use-cases-jp のチャット機能のユーザーインターフェース) generative-ai-use-cases-jp のソリューションは、 AWS アカウントに無料でデプロイできます。発生するコストは GenU で使用する AWS サービス料金のみです。 生成 AI を活用した UI デザイン改善の背景 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモにおいて、私の担当は、 Amazon Managed Grafana でダッシュボードを作り、 Amazon Monitron のデータを可視化することでした。AWS Summit 2024 Japan の開催2日前で残されたのは作業は、一部のデザイン改良です。さらにデザインを良くして、ご来場者の方々に関心を持っていただけるダッシュボードにしたいと考えていました。しかし、デザインの専門知識がない私が短期間で自力で改良することは困難だったので、生成AIの活用を試みました。 要件 今回のデザインの 要件は 3 つでした。 要件 1 (必須要件)：プロジェクトビューの 4 つの円グラフの項目数の合計が 36 。しかし、それぞれに相関関係がなく、異なる36色を設定する。 要件 2 (必須要件)：プロジェクトビューの 4 つの円グラフでは、多くの暗い色が設定されており、明るい色に変更して視認性を高める。 要件 3 (推奨要件)：遠くからでも見えるように、フォントサイズや背景色を見直し、タイトルやサブタイトルの可読性を高める。 生成 AI を活用したダッシュボードデザイン変更 Before / After 約 2 時間の作業で、生成 AI の活用により要件を満たすデザインに変更できました。 結果 要件 1 ：要件を満たす。 要件 2：プロンプト実行で重ねることで、要件をほぼ満たす。 要件 3：要件を満たす。 ダッシュボードのデザインは以下のように変わりました。 (図：ダッシュボード Before ) (図：ダッシュボード After ) 要件 1 : 4 つの円グラフで異なる 36 の色を設定する 要件 1 を実現するため、以下の手順を踏みました。改善前は、右上から時計回りで配置している「障害の原因」、「実施結果」、「障害モード」の 3 つの円グラフに同じ青色が設定されていました。さらに、「障害の原因」と「障害モード」には濃い緑色が使われていました。そこで、まず左上の「ステータス」円グラフの 5 色を手動で設定後、時計回りで「障害の原因」、「実施結果」、「障害モード」の 3 つの円グラフの配色を GenU で異なる色に変更しました。 (図: 要件 1 の実行順（オレンジの矢印） ) 右上の円グラフ「障害の原因」の色を変更するため、 GenU に以下のプロンプトを実行しました。ポイントは、生成 AI にグラフィカルデザイナーという明確な役割を与えたことです。また、「障害の原因」円グラフは最大 9 つの値を表示します。そこで、左上の円グラフ「ステータス」の色と被らない 9 色を提示するよう生成 AI に求めました。 あなたはグラフィカルデザイナーです。円グラフで9つの値を表示します。以下の条件を踏まえて、各値を見えやすい配色をRGBで考えてください。 ・背景色：黒（#000000） ・左隣に円グラフがあり、表示カラーはRGB(115, 191, 105)、RGB(255, 120, 10)、RGB(234, 234, 234)、RGB(250, 222, 42)、RGB(242, 73, 92)の5色で、これらの色と被らないこと。 ・円グラフ内に％表示する文字は白文字で、各値の配所により埋没しないこと。 その結果、 GenU から次のように円グラフ「ステータス」と異なる 9 つの RGB 値が提示されました。 (図：円グラフ「障害の原因」のプロンプトと実行結果 ) 時計回りに、各円グラフの配色提案のプロンプトを実行しました。 1 つ目の学びは、 Claude-3-Sonnet は、複数のプロンプト間の表現のゆらぎを吸収してくれることです。前回は、円グラフ「ステータス」を「左隣の円グラフ」と表現していましたが、今回は「円グラフ A 」と違う表現を使いました。このように表現が異なっていても、Claude-3-Sonnet は内容を正しく理解し、適切なプロンプトを返してくれました。 (図：円グラフ「実施結果」のプロンプトと実行結果 ) 円グラフ「障害モード」の配色についても、同様のプロンプトを実行しました。その結果、各円グラフの配色がユニークになり、要件 1 を実現することができました。 (図：要件 1 プロンプト実行後の円フラフの配色 ) 要件 2 : 明るい配色の円グラフにする 要件 1 の実現でユニークな色に設定はできましたが、一部の色の間に視認性に大きな差はありませんでした。また、暗めの色が多く採用されていたため、要件 2 (明るい配色) が未達です。そこで、円グラフの配色を明るい色を中心に変更することにしました。円グラフ「障害の原因」から時計回りに進み、同様の手順で実施しました。 (図：要件 2 の実行順 ) 下記のように要件 1 の実現で得られた配色において、明るい色は残しつつ、暗い色を変更するプロンプトを実行しました。 円グラフBは以下の4色を残して、再提案をしてください。 RGB(27, 156, 152) – 涼しげなターコイズブルー RGB(115, 194, 251) – 明るいスカイブルー RGB(226, 153, 186)- ライトピンク RGB(175, 175, 247) – 薄いラベンダー 2 つ目の学びは、 Claude-3-Sonnet が各円グラフのデータ項目数を把握しており、指定なしでも適切な色数を提案してくれたことです。 Claude-3-Sonnet は過去のプロンプトの内容を記憶しており、「円グラフ B 」と主語を明記することで、円グラフの構成を正確に判断しています。具体的には、円グラフ「障害の原因」は 8 つのデータ項目で、 4 色を残して 残りの色の変更をリクエストしました。各円グラフのデータ項目数は異なりますが、プロンプトには残す 4 色しか明記していません。しかし、 Claude-3-Sonnet は適切に 4 色の提案をしてくれました。 (図：円グラフ「障害の原因」のプロンプトと実行結果 2 ) 提案された色を確認し、目的の配色を得られるよう、繰り返しプロンプトを実行しました。要件 2 の実現には、プロンプトを何度も繰り返す必要があったため、 3 つの要件の中で最も時間がかかりました。また、 3 つ目の学びは、人間が異なる色と識別できる 36 色を設定することは、生成AIを使っても難しいことが分かりました。 (図：要件 2 プロンプト実行後の円フラフの配色 ) 要件 3：タイトルやサブタイトルの可読性を高める タイトルやサブタイトルの可読性を高めるために、ダッシュボードタイトルの白ラベルとプロジェクトビューなどのグレーラベルの配色について GenU に意見を求めました。ダッシュボード画像を GeuU に添付して、以下のプロンプトを実行しました。ポイントは要件 1 と同様に役割を与えたことです。次に画像からラベルの色が識別できるか不明だったので、ラベルで設定している背景色を明記したことです。 あなたはグラフィカルデザイナーで、ダッシュボードの最終確認をします。 部下が設備予知保全ダッシュボードの背景色とプロジェクトビューの背景色の考えてきました。画像を参考に2つの背景色が妥当か確認してください。 もっと良くなる背景色があれば提案をしてください。 ダッシュボード背景色：#000000 設備予知保全ダッシュボード背景色：#FFFFFF プロジェクトビュー背景色：#898989 GenU からの応答には、ラベルの背景色に加えて、円グラフの配色とフォントサイズについての改善案が含まれており、想定以上の回答を得ることができました。 この設備予知保全ダッシュボードのデザインは全体的にシックで落ち着いた印象があり、良いバランスだと思います。ただし、いくつか改善点があります。 ダッシュボード背景色の#000000(黒)は適切ですが、設備予知保全ダッシュボードの背景色の#FFFFFF(白)は、グラフやデータと対比が強すぎて目が疲れる可能性があります。代わりに#F5F5F5(薄いグレー)などの落ち着いた色を使うことをお勧めします。 プロジェクトビューの背景色の#898989(灰色)は少し暗すぎます。代わりに#BDBDBD(明るい灰色)などの明るめの色を使うと、より見やすくなると思います。 グラフの色使いは適切ですが、もう少しアクセントカラーを効果的に使うとよりインパクトがでるでしょう。例えば、重要な指標の円グラフに鮮やかな色(赤や青など)を使うなどです。 フォントの色とサイズにも気をつける必要があります。現在のデザインでは、一部のテキストが背景に埋もれて見づらい部分があります。 全体として落ち着いた色使いでまとまっていますが、適度なアクセントと対比を加えることで、より見やすく分かりやすいダッシュボードになると思います。必要に応じて調整をお願いします。 ( 図：要件3のプロンプトと実行結果 ) そこで、フォントカラーとサイズの適切な設定についても GenU にアドバイスを求めました。 フォントの色とサイズで良くする点がありましたら、提案をしてください。 その結果、フォントの色と最適なサイズの提案が返ってきました。 フォントの色とサイズについて、以下のように提案します。 【フォントの色】 メインタイトル(「設備予知保全ダッシュボード」) 現在の白は背景の黒に埋もれて見づらいので、より明るい色の方が良いでしょう。 提案: RGB(220,220,220)の明るいグレー サブタイトル(「プロジェクトビュー」など) 現在の灰色は大丈夫ですが、もう少し明るめの色の方が見やすくなります。 提案: RGB(160,160,160) データラベル(グラフ内の値など) 現在の白は問題ありませんが、アクセントになる色を使うとより見やすくなります。 提案: RGB(255,200,0)の黄色を使う 【フォントのサイズ】 メインタイトル: 現在の24ptはちょうど良いサイズ サブタイトル: 現在の18ptは小さ過ぎます。20ptが適切でしょう。 データラベル: グラフによって最適なサイズは異なりますが、 概ね12pt~14ptが見やすいサイズになると思われます。 その他の補助テキスト: 10ptが最小サイズとして適切です。 このようにフォントの色とサイズを最適化することで、データが一目で視認でき、より分かりやすいダッシュボードになると考えられます。必要に応じて更なる調整をお願いします。 (図：フォントカラーとフォントサイズのプロンプト結果 ) ※画像ではメインタイトルのフォント色の提案が切れています。 内容を確認すると、フォントカラーは 10 進法表記での提案でした。 しかし、 AWS Managed Grafana ではラベルのフォントカラーを HEX 表記で設定するため、 HEX 表記の提案を求めました。 色はHEXで教えてください。 HEX表記での提案が返ってきました。 分かりました。フォントの色をHEX表記で提案します。 【フォントの色】 メインタイトル(「設備予知保全ダッシュボード」) 提案: #DCDCDC (明るいグレー) サブタイトル(「プロジェクトビュー」など) 提案: #A0A0A0 データラベル(グラフ内の値など) 提案: #FFCC00 (黄色) (図：フォントカラーHEXのプロンプトと実行結果 ) GenU の提案に基づき、ラベルの背景色とフォントサイズを設定したところ、メインタイトルとサブタイトルのラベルの色が同色化しました。 そこで、 GenU の提案を一部採用することにしました。具体的には、メインタイトルの白色は変更せず、プロジェクトビューなどのサブタイトルについては、 GenU の提案に従って背景色とフォントサイズを変更しました。 (図：ラベル Before ) (図：ラベル GenU 提案 ) (図：ラベル After（最終）) 以上により、 AWS Summit 2024 Japan で展示するダッシュボードデザインの設定が終わりました。プロジェクトビューの 4 つの円グラフの配色は、ユニークかつ以前より鮮やかなものになりました。さらに、プロジェクトビューなどのサブタイトルの文字色を黒に変更したことで、可読性が高まりました。 (図：要件 3 プロンプト実行後のダッシュボード画面) おわりに このブログでは、 生成 AI ソリューション generative-ai-use-cases-jp (略称: GenU )を利用し、 AWS Summit 2024 Japan で展示した「Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ」のデザインを改善した事例とその手法を紹介しました。 最後に、Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードを紹介している AWS ブログを紹介します。こららのブログには、デモの目的や構成を紹介しています。デモに関心にある方は、ぜひご覧ください。 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモを AWS Summit 2024 Japan で展示します (Part 1) Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモを AWS Summit 2024 Japan で展示しました(Part 2:サービス解説編 ) AWS Summit Japan 製造業向け展示の見どころ紹介！ このブログについて AWS Summit 2024 Japan で展示した 「 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ 」は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発しました。 ブログ執筆者 梶山　政伸 (Masanobu Kajiyama) ソリューションアーキテクトとして、製造業のお客様と共にクラウドジャーニーをしています。趣味は旅行で、欧州・中東・アジアの19ヶ国を訪れました。

9月10日、レジリエンスを中核として基盤モデル (FM) 開発向けに設計された専用インフラストラクチャである Amazon SageMaker HyperPod での Amazon Elastic Kubernetes Service (EKS) のサポート が発表されました。お客様が EKS を使用して HyperPod クラスターをオーケストレーションすることを可能するこの新しい機能は、 Kubernetes の力と、大規模モデルのトレーニング用に設計された Amazon SageMaker HyperPod のレジリエントな環境を組み合わせます。Amazon SageMaker HyperPod は、1,000 個を超える AI アクセラレータ全体での効率的なスケーリングに役立つため、トレーニング時間が最大 40% 短縮されます。 Amazon SageMaker HyperPod では、お客様が Kubernetes ベースのインターフェイスを使用してクラスターを管理できるようになりました。この統合により、トレーニング、微調整、実験、推論などのさまざまなワークロードを最適化するために、Slurm と Amazon EKS をシームレスに切り替えることが可能になります。包括的な監視機能を実現する CloudWatch Observability EKS アドオンは、統合されたダッシュボードで CPU、ネットワーク、ディスク、およびその他の低レベルのノードメトリクスに関するインサイトを提供します。この強化されたオブザーバビリティは、クラスター全体でのリソースの活用、ノードレベルのメトリクス、ポッドレベルのパフォーマンス、コンテナ固有の使用率データに拡張されるため、効率的なトラブルシューティングと最適化の促進につながります。 re:Invent 2023 でリリースされた Amazon SageMaker HyperPod は、大規模なモデルを効率的にトレーニングし、デプロイしようとしている AI スタートアップと企業にとっての主力ソリューションになりました。これには、トレーニング時間を最大 20% 短縮するために役立つ モデル並列 および データ並列 ソフトウェア最適化を提供する、 SageMaker の分散型トレーニングライブラリ との互換性があります。SageMaker HyperPod は、障害のあるインスタンスを自動的に検出して修復または交換するため、データサイエンティストはモデルのトレーニングを数週間または数か月間、中断することなく実行できます。これは、データサイエンティストがインフラストラクチャの管理ではなく、モデル開発に集中することを可能にします。 Amazon EKS と Amazon SageMaker HyperPod の統合は、スケーラビリティと豊富なオープンソースツールを備えていることから機械学習 (ML) ワークロードで人気を集めている Kubernetes の利点を活用します。多くの場合、組織は生成 AI ユースケースに必要なものを含めたアプリケーションを構築するために、Kubernetes で標準化を行っています。Kubernetes では、コンプライアンスやガバナンスの標準を満たしながら、環境全体で機能を再利用できるからです。本日の発表により、お客様は 1000 個を超える AI アクセラレータ全体でリソースの活用をスケールし、最適化できるようになります。この柔軟性は、開発者エクスペリエンス、コンテナ化されたアプリケーションの管理、FM トレーニングと推論ワークロードのための動的なスケーリングを向上させます。 Amazon SageMaker HyperPod での Amazon EKS サポートは、詳細なヘルスチェック、自動化されたノードリカバリ、ジョブの自動再開機能を通じてレジリエンスを強化して、大規模なジョブや長時間実行されるジョブのトレーニングが中断されないことを確実にします。ジョブ管理は、Kubernetes 環境用に設計されたオプションの HyperPod CLI を用いて合理化できますが、お客様は独自の CLI ツールを使用することも可能です。 Amazon CloudWatch Container Insights との統合は、高度なオブザーバビリティを提供するので、クラスターのパフォーマンス、正常性、および使用率に関するより深いインサイトを得ることができます。さらに、データサイエンティストは、自動化された ML ワークフローのために Kubeflow といったツールを使用することもできます。この統合には Amazon SageMaker のマネージド MLflow も含まれており、実験追跡とモデル管理のための堅牢なソリューションを提供します。 大まかに説明すると、Amazon SageMaker HyperPod クラスターはクラウド管理者が HyperPod クラスター API を使用して作成するものであり、HyperPod によって完全に管理されるため、ML インフラストラクチャの構築と最適化に関わる差別化につながらない重労働が排除されます。これらの HyperPod ノードのオーケストレーションには Amazon EKS が使用され (Slurm が HyperPod ノードをオーケストレーションする方法と似ています)、お客様に使い慣れた Kubernetes ベースの管理者エクスペリエンスを提供します。 Amazon SageMaker HyperPod での Amazon EKS サポートの使用を開始する方法を見ていきましょう シナリオを準備することから初めて、 前提条件 を確認し、Amazon SageMaker HyperPod EKS ワークショップの手順に従って、VPC とストレージリソースで設定されている単一の AWS CloudFormation スタックで Amazon EKS クラスターを作成します。 Amazon SageMaker HyperPod クラスターを作成して管理するには、 AWS マネジメントコンソール  か  AWS コマンドラインインターフェイス (AWS CLI) を使用できます。AWS CLI を使用して、クラスター構成を JSON ファイルで指定します。SageMaker HyperPod クラスターのオーケストレーターには、以前に作成された Amazon EKS クラスターを選択します。次に、プライベート Subnet があり、自動ノードリカバリを有効にするために NodeRecovery  が Automatic   に設定されている、「worker-group-1」という名前のクラスターワーカーノードを作成します。 OnStartDeepHealthChecks  には InstanceStress と InstanceConnectivity を追加して、詳細なヘルスチェックを有効にします。 cat > eli-cluster-config.json << EOL { "ClusterName": "example-hp-cluster", "Orchestrator": { "Eks": { "ClusterArn": "${EKS_CLUSTER_ARN}" } }, "InstanceGroups": [ { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.p5.48xlarge", "InstanceCount": 32, "LifeCycleConfig": { "SourceS3Uri": "s3://${BUCKET_NAME}", "OnCreate": "on_create.sh" }, "ExecutionRole": "${EXECUTION_ROLE}", "ThreadsPerCore": 1, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ], }, .... ], "VpcConfig": { "SecurityGroupIds": [ "$SECURITY_GROUP" ], "Subnets": [ "$SUBNET_ID" ] }, "ResilienceConfig": { "NodeRecovery": "Automatic" } } EOL InstanceStorageConfigs を追加して、追加の Amazon EBS ボリューム をプロビジョニングし、HyperPod ノードにマウントすることができます。 SageMaker HyperPod API を使用してクラスターを作成するため、以下の AWS CLI コマンドを実行します。 aws sagemaker create-cluster \ --cli-input-json file://eli-cluster-config.json この AWS コマンドは、新しい HyperPod クラスターの ARN を返します。 { "ClusterArn": "arn:aws:sagemaker:us-east-2:ACCOUNT-ID:cluster/wccy5z4n4m49" } 次に、 SageMaker コンソール で HyperPod クラスターのステータスを確認し、ステータスが InService に変わるまで待ちます。 または、AWS CLI を使用して describe-cluster コマンドを実行することで、クラスターのステータスを確認することも可能です。 aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster クラスターの準備が整ったら、SageMaker HyperPod クラスターノードにアクセスできるようになります。ほとんどの運用では、開発環境からリソースとジョブを管理するために kubectl コマンドを使用して、SageMaker HyperPod のマネージドインフラストラクチャのメリットを得ながら Kubernetesオーケストレーションを最大限に利用することができます。今回は、高度なトラブルシューティングや直接的なノードアクセスのために、「 Access your SageMaker HyperPod cluster nodes 」ページにある手順に従って、個々のノードへのログインに AWS Systems Manager (SSM) を使用します。 EKS がオーケストレーションする SageMaker HyperPod クラスターでジョブを実行するには、「 Run jobs on SageMaker HyperPod cluster through Amazon EKS 」ページに概説されている手順に従います。HyperPod CLI とネイティブ kubectl コマンドを使用して、利用可能な HyperPod クラスターを検索し、トレーニングジョブ (ポッド) を送信できます。ML 実験とトレーニング実行の管理には、 Kubeflow Training Operator 、 Kueue 、および Amazon SageMaker のマネージド MLflow を使用できます。 最後に、SageMaker コンソールで最近追加された EKS クラスターの ステータス と Kubernetes バージョン を表示して、SageMaker HyperPod 環境の包括的な概要を把握できます。 クラスターのパフォーマンスと正常性のインサイトは、 Amazon CloudWatch Container Insights を使用して監視できます。 知っておくべきこと 以下に、Amazon SageMaker HyperPod での Amazon EKS サポートについて知っておく必要のある重要点をいくつか紹介します。 レジリエントな環境 – この統合は、詳細なヘルスチェック、自動化されたノードリカバリ、およびジョブの自動再開機能を備えた、よりレジリエントなトレーニング環境を提供します。SageMaker HyperPod は障害を自動的に検出および診断して回復させるため、基盤モデルのトレーニングを中断することなく数週間または数か月間継続させることができます。これは、トレーニング時間を最大 40% 短縮できます。 強化された GPU オブザーバビリティ – Amazon CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスに関する詳細なメトリクスとログを提供します。これは、クラスターのパフォーマンスと正常性の包括的な監視を可能にします。 サイエンティストが簡単に使用できるツール – このリリースには、ジョブ管理のためのカスタム HyperPod CLI 、分散型トレーニングのための Kubeflow Training Operator、スケジューリングのための Kueue、および実験追跡のための SageMaker のマネージド MLflow が含まれています。また、モデル並列およびデータ並列最適化を提供する SageMaker の分散トレーニングライブラリとも連動して、トレーニング時間を大幅に短縮します。これらのライブラリとジョブの自動再開機能を組み合わせることで、大規模モデルの効率的で中断のないトレーニングが可能になります。 柔軟なリソース活用 – この統合により、開発者エクスペリエンスと FM ワークロードのスケーラビリティが向上します。データサイエンティストは、トレーニングタスクや推論タスク全体でコンピューティングキャパシティを効率的に共有できます。既存の Amazon EKS クラスターを使用したり、新しい EKS クラスターを作成して HyperPod コンピューティングにアタッチしたりすることや、ジョブの送信、キュー登録、監視のために独自のツールを使用することができます。 Amazon EKS で Amazon SageMaker HyperPod の使用を開始するには、SageMaker HyperPod EKS ワークショップ、 aws-do-hyperpod プロジェクト 、および awsome-distributed-training プロジェクト などのリソースを活用できます。このリリースは、Amazon SageMaker HyperPod を利用できる AWS リージョン (欧州 (ロンドン) リージョンを除く) で一般提供されています。料金の情報については、 Amazon SageMaker の料金ページ をご覧ください。 このブログ記事は共同で作成されました。この記事で紹介した情報の収集と絞り込みに大きく貢献してくれた、Manoj Ravi、Adhesh Garg、Tomonori Shimomura、Alex Iankoulski、Anoop Saha、そしてチーム全員に感謝しています。この包括的な記事の作成には、彼らの集合的な専門知識がきわめて重要な役割を果たしました。 – Eli. 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半に渡ってご講演いただきました。 前回 に引き続きこのブログではイベントの最後に行われたパネルディスカッションの内容をレポートします。 パネルディスカッション：AWS と紡いできたデジタル変革の歴史 株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （インフラストラクチャ） 堀川 茂 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （SCM・インテグレーションエンジニアリング） 北口 泰大 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （コアエンジニアリング） 村田 雄一 氏 アマゾン ウェブ サービス ジャパン合同会社 流通小売・消費財・サービスビジネスグループ 本部長 五十嵐 建平 皆様のキャリア、ご担当領域 まず、パネリストの皆様にご自身の経歴をお話しいただきました。 大谷氏は 2016 年にファーストリテイリングに入社し、主にエンジニアリングの内製化やテクノロジーの事業への根付かせることをミッションとしています。現在は技術の最高責任者であり、同時にセキュリティも担当されています。AWS との関わりとしては、ファーストリテイリングのサービスのほとんどが AWS 稼働しており、足掛け 12 年以上にわたり AWS を活用しています。実は前職が AWS のソリューションアーキテクトです。AWS 時代にファーストリテイリングを顧客訪問した経験もあるといったエピソードもご紹介いただきました。 堀川氏は 2012 年の入社以来、オンプレミスからクラウドシフトを進められた経験を持ち、AWS との関わりも 12 年前から続いています。ファーストリテイリングという事業会社に入ったことで、エンジニアとしての目標がシステムを入れることではなく業務成果そのものになったことは大きな転換でした。 北口氏は 2018 年の入社以来、共通基盤の開発やデータ連携基盤などを担当されています。現在は物流領域の業務改革とデジタルツール整備が注力ポイントです。AWS との関わりはファーストリテイリング入社後からで、新しいシステムを作る際には AWS のプロダクトチームとも協議しながら、最適なシステムの形を探りながら構築にあたっているとのことです。 村田氏は 2017 年の入社以来、有明プロジェクトをその立ち上げから経験されました。最初は e コマース（EC）の機能を提供するバックエンドシステムの開発からスタートし、インフラチームや品質保証などを経験したのち、現在は内製開発を統括する部長を務められています。EC の領域では AWS を徹底的に活用しており、AWS から継続的な支援を受けています。コールセンターの業務改革として Amazon Connect を活用する新しい取り組みについてもご紹介いただきました。 黎明期 – カルチャーの醸成 「黎明期 – カルチャーの醸成」というテーマからディスカッションが行われました。 最も在籍年数の長い堀川氏に入社当初のエピソードを振り返っていただきました。堀川氏はセミナーに参加したり、ベンダーの支援を受けながら AWS の使い方を学ばれたそうです。AWS の活用を決めるより前から、AWS のソリューションアーキテクト等の力を借りて経験を積まれました。当初はアーキテクチャレビューの仕組みなどはありませんでしたが、品質が担保できずにシステム障害が発生するなどの失敗も経験されました。アーキテクチャレビューの仕組みはそうした失敗から学んで生まれたものだったのです。 大谷氏からは有明の自動倉庫のプロジェクトについてお話を伺うことができました。IT プロジェクトとは違い、倉庫の設置やハードウェアの設置などの物理的な制約があり、事業会社ならではの痛みを感じたとのことでした。当時はまだ混沌の中にあり、整理された話ではなかったそうですが、優秀な人材を次々と採用することで知恵を出し合える環境が生まれてきました。重大な課題に対して連携して話し合う中で、自然と今のようなカルチャーが醸成されていったそうです。 堀川氏からは、SAP の導入で AWS と 4TB のインスタンス利用を交渉した経緯も紹介されました。当時はオンプレミスでしかできないという思い込みがあったとのことですが、将来の成長を見据えて AWS と交渉し、実現に至ったそうです。この経験から、できないことでもきちんと交渉すれば実現できるということを学びました。 このように、ファーストリテイリングの皆様は AWSの活用を決めた黎明期からさまざまな失敗や課題を乗り越えながら、現在のカルチャーを醸成してこられました。失敗を恐れずにチャレンジし、課題解決に向けて連携することが、ファーストリテイリングのカルチャーの基盤となっていることがよくわかります。 AWS との緊密な協力関係のもと、こうした新しいカルチャーを育んでいったことが、ファーストリテイリングのデジタル変革を可能にした大きな要因だったのです。 移行期 – アーキテクチャの変更 次のテーマはアーキテクチャの変更が起こった移行期についてです。村田氏は従来のモノリシックな EC パッケージからヘッドレスアーキテクチャのプラットフォーム化を進め、マイクロサービス化や Immutable Infrastructure の採用、マルチリージョン展開、オープンソースやマネージドサービスの活用、技術の標準化などを実現されたことを紹介しました。ビジネスロジックの複雑さとパフォーマンスやスケーラビリティの課題があったことも振り返られました。 北口氏は、当初はオンプレミスのアプリをクラウド上に載せただけの状態からスタートし、グローバル展開を見据えてコンテナ化や CI/CD の仕組み作りを進めた経緯を説明してくださいました。コストを意識したツール提供や、業務部門との密な連携によるコスト意識の共有なども行われていることが分かりました。大谷氏からアーキテクチャ標準化の取り組みも語られました。 Amazon Aurora や Amazon ElastiCache の標準採用、プログラミング言語やフレームワークの選定基準策定が行われた経緯が紹介されました。ツールが乱立して苦労した経験から、ある程度の標準化は必要不可欠と考えられていることがうかがえます。 一方で、大谷氏は技術選定に適度な幅を持たせることの重要性も指摘します。標準化を徹底しすぎると柔軟性を失うため、エンジニアにとって適切な選択の幅を残すことも重要です。これらの標準化は大規模な並行開発が進んでいた時期に行われました。グローバル展開を見据えてアーキテクチャ変革を段階的に実施し、プラットフォーム化、マイクロサービス化、標準化などが行われていったのです。 拡張期 – グローバル化 グローバル化におけるチャレンジという観点で、村田氏よりローカル対応についてご説明いただきました。約 30 の地域で複数のブランドでビジネスを展開しており、グローバルワンのプラットフォームを作る一方で、各国からの要望にも対応する必要があります。適切なプライオリティ付けと効率化が重要ですが、グローバルで作ったものが必ずしも全世界で当てはまるわけではなく、配送の仕組みやデータプライバシーの取り扱いなど、国ごとに対応が必要な部分も出てきます。加えて大谷氏は、技術の問題を必ずしも技術者だけで決められないケースがあり、地政学的リスクなどでは経営判断が必要になることがあると補足しました。 堀川氏はネットワークの最適化の観点で起こった変化をご説明くださいました。AWS への移行当初はすべての店舗からの通信を東京に集約していましたが、現在は AWS のネットワークをフル活用し、各国から最寄りの AWS リージョンに直結することで AWS のバックボーンネットワークを利用することでスピードとアベイラビリティを向上しました。 北口氏は、拠点系のシステムでは特にカスタマイズや要件のバリエーションが多いことを踏まえ、在庫の一貫性を持った管理や入出荷業務の効率化などの根本的な部分をグローバルワンとして構築した上で、ラッパー層としてローカルカスタマイズを行うアプローチをとっていると述べられました。 多国籍なチームを運営する上でのカルチャーの共有も重要です。多国籍なチーム構成だからこそ、ミッションステートメントに代表される価値観の共有が意思決定や一体感につながると説明がありました。クラウドジャーニーを推進するどのような組織においても、このミッションステートメントの共有によるインクルーシブな環境の構築は学ぶところがあります。 セキュリティ CSO を兼務する大谷氏より、セキュリティについてもコメントをいただきました。現代社会における情報システムでは特にセキュリティの重要性が高まっており、企業全体でセキュリティ水準を上げることが求められています。セキュリティは単なるテクノロジーの問題ではなく、経営層の意識や物理的なセキュリティ対策など、さまざまな側面から取り組む必要があるものです。 IT セキュリティだけでなく、お客様の情報を守るためには運用面での対策も欠かせません。ファーストリテイリングでは、IT セキュリティの基準を満たすだけでなく、さらにその水準を上げていくことが課題となっています。そのためには、セキュリティを俯瞰的に捉え、企業のミッションに照らし合わせて適切な基準を設定し、組織文化として根付かせることが重要だと述べられました。 一方で、セキュリティを過度に厳格化すれば、IT の創造性や付加価値が失われてしまう恐れがあります。セキュリティと IT の柔軟性のバランスを取ることが肝心であり、そのバランスを失わないようにすることがセキュリティチームの重要な役割だと大谷氏は述べられました。 まとめ 最後に皆様からクロージングコメントをいただきました。クラウドやプラットフォームの製品選定においては、現在の機能だけでなく、その組織のカルチャーを踏まえて今後の進化を見据えることが重要です。AWSはもともと、小売業である Amazon のビジネス課題を解決するために生まれており、お客様へのこだわりという点でファーストリテイリングと共通点の多い文化を持ち、お客様のための課題解決に向けた進化を続けていると評価いただきました。AWS との 12 年に渡る協業関係を振り返り、今後もグローバル展開に向けて AWS との戦略的な連携を強化していく考えを示されました。 最後に、さまざまなバックグランドを持ったエンジニアの皆さんにジョインしていただき、仲間を増やしていきたいという熱意のこもったメッセージをいただき、ご講演を締めくくっていただきました。 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半にわたってご講演いただきました。 前回 に引き続きこのブログでは講演内容をレポートします。 ファーストリテイリングの IT を支える AWS インフラストラクチャ 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 堀川 茂氏 堀川氏より、同社の AWS クラウド活用の歴史と現状、そして大規模クラウド環境を少人数で運用するための工夫についてお話しいただきました。 ファーストリテイリングがクラウドを必要とした背景には、グローバルで 3,500 以上の店舗、約20 の国と地域での e コマース（EC） 事業、世界中の倉庫や工場といったサプライチェーン全体をつなぐ必要性がありました。ビジネスの急速な拡大に追随するため、データセンターを各事業ごとに構えるのではなく、グローバルにスケール可能で迅速にインフラを調達できるクラウドが不可欠でした。クラウド化の大きなきっかけとなったのは、2017 年 の EC サイトダウンでした。3 日間のダウンタイムを経験し、オンプレミス環境での容量増強の難しさや流量制御の課題に直面したことで、クラウド化の必要性を強く認識されました。 ファーストリテイリングのクラウドジャーニーは、2012 年頃から一部のキャンペーンサイトで AWS の利用を開始したことに始まります。2013年には既存の基幹システムの老朽化に伴い、クラウド化プロジェクトが始動しました。2016年から2017年にかけて開始された「有明プロジェクト」を通じて、オンプレミスからクラウドへの移行（リフト & シフト）が大規模に進められました。2021 年頃からはグローバル展開が加速し、AWS の利用も更に拡大しました。 クラウド活用の成果として、以下の 5 点が挙げられました。 スケーラビリティとキャパシティの確保：需要に応じて簡単にスケールアップやキャパシティ拡張が可能になった アーキテクチャのモダナイゼーション：マイクロサービス化など、レガシーシステムから現代的なアーキテクチャへの移行が実現した エンジニアの確保：クラウドエンジニアの採用が容易になり、パートナーや開発者の確保が改善された アベイラビリティの確保：コスト効率の良い方法で、災害対策用のバックアップサイトを別のアベイラビリティゾーンや地域に構築できるようになった インフラコストの最適化：繁忙期と閑散期でリソースを調整し、インフラコストを最適化できるようになった 現在の AWS 利用状況としては、60 以上のアカウント、15 以上のリージョン、13,000 以上の仮想マシン、3,000 以上のデータベース、12 万以上のコンテナを運用しています。これらの大規模インフラを 20 人程度の少数チームで管理するために、さまざまな工夫を行っています。主な取り組みとして以下が紹介されました。 アーキテクチャーレビュー：コマース、エンタープライズ、CTO の 3 つのレビューボードを設置し、プロジェクトの計画から運用要件、セキュリティまで多角的な観点でチェックを行っています。 自動化・コード化：Infrastructure as Code (IaC) の活用、コスト管理の自動化、標準化された AWS アカウント作成の自動化などを導入しています。 セルフサービス化：アプリケーションチームが自身で責任を持ってコードのビルド、テスト、デプロイできる仕組みを構築しています。 コスト管理：タグベースでシステムごとのコストの推移を可視化し、アプリケーションチームが自ら責任を持ってコストを管理できるようにしています。 システム監視基盤の統一：散在していた監視基盤を統合し、全担当者がメトリクスやアプリケーションの振る舞いを一元的に把握できるようにしました。これにより、トラブルシューティングの時間短縮を実現しています。 セキュリティ対策：AWS が提供する様々なセキュリティソリューションを活用し、マルチアカウントでの統合的なセキュリティ管理を実現。セキュリティアカウントに情報を集約し、SIEM 基盤と連携させることで、脆弱性の早期検知と対策を可能にしています。 今後の取り組みとして、ECS コンテナタスクよりも幅広く、粒度の細かいパラメータ制御もセルフサービスで行えるための Kubernetes の活用や、グローバル展開をさらに加速させるために各地域のインフラチームを強化し、follow the sun の運用の実現を目指しています。また、グローバルでのプロジェクト推進体制の構築も進めています。 自動化やセルフサービス化、統一監視基盤の導入など、さまざまな工夫により少人数での大規模クラウド運用を実現しています。グローバル展開を加速させる企業が AWS を活用して大規模なクラウド環境を効率的に運用する方法をご紹介いただきました。 ユニクロ・ジーユーのECアプリの裏側をご紹介 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 秋元 俊祐 氏 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 佐野 大輔 氏 続いて、コアエンジニアリングチームの方々よりユニクロ・ジーユーの EC アプリの裏側をご紹介いただきました。まず、秋元氏より e コマース（EC）サイトのカート機能における大幅な性能改善とコスト削減の事例についてご紹介いただきました。 カート機能は、ユニクロやジーユーのアプリやウェブサービスで商品を選び、購入手続きを行う際に重要な役割を果たします。従来のアーキテクチャでは、 Application Load Balancer の下に Amazon Elastic Container Service (Amazon ECS) があり、Amazon ECS の API Service が Amazon Aurora からデータを読み取る構成でした。しかし、この構成では人気商品のセール時などにトラフィックが急増すると、データベースがボトルネックとなり、レスポンスタイムが大幅に悪化する問題がありました。また、データベースのインスタンスを上位のものに変更することでインフラコストが圧迫されるという課題もありました。 これらの課題を解決するため、NoSQL の一つである Redis をメインデータベースとして採用することを決定しました。 Amazon ElastiCache を利用することで、高いスケーラビリティを確保しつつ、性能を大幅に向上させることができました。 新しいアーキテクチャでは、API Service から直接 Amazon ElastiCache にデータの読み書きを行い、Amazon ElastiCache と Amazon Aurora の間で非同期のデータ同期を行うようにしました。これにより、Redis の性能を最大限に引き出すことができました。 実装上の工夫として、Lua スクリプトを用いた自前のロック機能の実装や、Redis の Sorted Set による更新されたカートの効率的な抽出などが行われました。また、データマイグレーションはゼロダウンタイムで実施され、運用を継続しながら徐々に Redis にデータを移行することができました。 結果として、以前問題が発生したセールの 2 倍以上のトラフィックがあった際も、まったく性能劣化が見られませんでした。レスポンスタイムは p95 で10秒超から 160ms と大幅に改善され、さらに大きなトラフィック増加にも対応できる見込みが立ちました。コスト面でも大きな削減が実現し、Amazon ElastiCache for Redis の Data Tiering 機能を利用することで、さらなるコスト最適化が図られています。 最終的に、データベースのコストが 60 %以上削減され、将来 10 年に渡るスケーラビリティを確保することができました。クラウドサービスを効果的に活用することで、性能向上とコスト削減を同時に実現できることを示していただきました。 続いて、サーチプラットフォームについて、佐野氏よりご紹介いただきました。ファーストリテイリングのシステムは、各業務のマイクロサービスが相互に接続されており、データ連携基盤や API 連携で構成されています。サーチプラットフォームは、商品検索機能を提供するマイクロサービスで、在庫情報や価格情報、商品情報などを他のプラットフォームから取得して利用しています。主な機能には、キーワード検索、カテゴリーページの商品リスト作成、キーワードサジェスト、類似商品リスト作成、店舗在庫検索などがあります。 Amazon OpenSearch Service は現在サーチプラットフォームを含む一部のプラットフォームで利用されています。Amazon OpenSearch Service の特徴として、以下の 3 点が挙げられました。 柔軟な構造を持つデータを大量に登録可能 キーワード検索や柔軟なクエリの実現 フルマネージドサービスで、リクエスト量に応じたスケールイン/アウトが容易 Amazon OpenSearch Service の長所として、参照用途のアプリケーションに高い性能と拡張性を発揮すること、EC における商品検索のような典型的な機能を既に持っているため開発量を削減できることが挙げられました。 グローバルデジタルコマースの検索に求められる要件として、複数のブランド、多くの国・地域への展開、多言語サポートを効率的にサポートすることが重要です。サーチプラットフォームの実装におけるポイントとして、以下の 4 点が挙げられました。 機能性：言語特有の解析機能を自作するのは困難で非効率であり、構文解析や正規化などの機能が最初からサービスに組み込まれていることが重要 展開容易性：自動的にデータが Amazon OpenSearch Service に流れ込むアーキテクチャーの採用 拡張性：スケールイン/アウトの容易な実行 運用性：単語・シノニム登録のための効率的なツールの開発 今後の課題として、単語・シノニム登録の業務運用コスト削減が挙げられました。これに対して、機械学習由来の技術（大規模言語モデル、ベクターサーチ、セマンティックサーチなど）の活用が検討されています。また、キーワード検索以外にも、ユーザー体験を向上させる機能の開発や、サーチプラットフォームの改善と並行して新しい地域への展開を進めていくことが課題として挙げられました。 データ連携基盤の実行制御を実現する Amazon ECS を活用したアプリケーション開発 株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 阪本 圭 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 吉元 裕人 氏 続いて、インテグレーションエンジニアリングチームによる、データ連携基盤の取り組みについて阪本氏より紹介がありました。 まず、チームの主な役割として、システム開発の効率化とデータ連携基盤の開発・管理・運用が挙げられました。情報製造小売業として、End-to-End のプロセスに投資を行ってきた結果、データ連携やバッチ処理が複雑化・大規模化していました。そのため、データの整流化とデータ利活用のためのツール整備、そして多ブランド・多国展開後のデータ量に対応した高速な処理の実現が必要とされました。 これらの課題に対して、2 つの主要なコンセプトで取り組んでいます。1 つ目はバッチ処理基盤の整備です。処理依存性や並列分散を制御できるフレームワークを準備し、複雑な依存関係を管理しやすい形に整理しました。2 つ目はデータ連携基盤の整備です。ハブアンドスポーク型のクラウドネイティブな基盤を構築し、あらゆる情報を一元管理してデータの整流化を図っています。特徴として、定義ベースで簡単にルーティング制御ができること、ビジネス領域ごとの特性に合わせて分散配置できること、さまざまなプロトコルやデータフォーマットをカバーできることがあります。 この基盤に求められる中心的な要件として、以下の 4 点が挙げられました。 安定性：ビジネスの中核を担うため、高い安定性が必要であること パフォーマンス：ビジネスの変動に耐えられる性能とキャパシティをプランニングできること 可搬性：簡易に分散展開できること 多様なアプリケーションとの連携：さまざまなアプリケーションとのシームレスな連携が可能であること 続いて、データ連携基盤の具体的なアーキテクチャや、開発していく中での課題や工夫について吉元氏よりご紹介いただきました。 データ連携基盤は、各業務領域間でデータを効率的に連携させるためのハブアンドスポーク型のシステムとして設計されており、現在 10 のサービスとして 2 つのクラウド、6 つのリージョンで運用されています。システムの開発経緯としては、2015 年にバッチ処理基盤として始まり、徐々に機能を拡張してデータ連携基盤へと進化してきました。2019 年にはコンテナ化やインフラのコード化を実施し、2021 年にはマルチクラウドのサポートを強化しています。 開発・運用において重視している点として、環境の再現性、拡張性、カスタマイズの容易さ、スケーラビリティ、クラウド非依存性などが挙げられました。特に、Amazon ECS を利用したタスク実行の管理に関しては、API 呼び出しに単位時間当たりの回数制限があったり同期的なタスクの状態管理が困難であったりという課題に対して、解決策を独自に実装しています。 具体的には、ワーカーアプリケーションをラッパーでくるむことで、フレームワーク全体の一部として動作させ、ハートビートやコールバックを通じてタスクの状態を同期的に把握する仕組みを実装しています。これにより、ECS クラスターへの状態確認のための頻繁なポーリングによる問い合わせを回避し、アプリケーションの実行状況をよりタイムリーに把握・管理できるようになりました。 今後のチャレンジとしては、以下の 3 点が挙げられました。 導入の更なる省力化・セルフサービス化の推進：業務アプリケーションチームが容易にデータ連携の仕組みを構築できるようにする 新しいサービスとの連携強化：デジタル改革に伴う新サービスとの安定した連携を実現する データ活用の促進：データの蓄積・分析プロセスとの一層の統合を図り、ビジネス価値の創出につなげる 最後に、この取り組みを通じて、複雑化していたデータ連携やバッチ処理の整理統合を図り、クラウドサービスを適切に活用しながら独自のソリューションとしてパッケージ化することで、ビジネスへの貢献を目指していることをご紹介いただきました。 （ Part 3 に続く） 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし、「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半にわたってご講演いただきました。本ブログでは、3 回に分けてその内容をレポートします。 オープニング ：ファーストリテイリングにおけるビジネスの変革とデジタルの取り組みについて 株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏 はじめに、大谷氏よりファーストリテイリングのビジネスコンセプトと、デジタル変革に向けた「有明プロジェクト」についてご説明いただきました。 ファーストリテイリングでは、「服を変え、常識を変え、世界を変えていく」というミッションステートメントのもと、ユニクロ、ジーユー、プラステ、セオリー、コントワー・デ・コトニエ、プリンセス タム・タムなど 8 つのブランドを展開しています。現在 約 30 の 国・地域で約 3,600 店舗を構え、世界のアパレル製造小売りでは第 3 位の規模となる売上収益 2.7 兆円（2023 年 8 月期）の企業グループです。特にユニクロが海外事業の牽引役となり、売上の 6 割が海外からのものです。お客様一人ひとりの毎日の生活を良くするための「究極の普段着」としての「LifeWear」の提供を目指しており、高品質の服を手に取りやすい価格で届けることをコンセプトとしています。また、「PEACE FOR ALL」の活動を通じて、平和を願う著名人とコラボレーションした T シャツの利益を紛争や差別など、戦争で被害を受けた人々に還元するなど、社会貢献にも力を入れています。 ファーストリテイリングはデジタル変革の取り組みとして有明プロジェクトを推進しています。これは製造小売業から「情報製造小売業」への転換を目指すもので、お客様の本当に欲しいものだけを届けるための変革です。お客様の声を起点に、商品企画、生産・物流、販売までをデジタルでつなげ、必要な分だけ、必要なタイミングで商品を届けることを目指しています。約 11 万人の従業員が世界中でワンチームとなり、データを駆使してお客様のニーズを的確に捉え、そのニーズにスピーディーに応えられるよう業務改革に取り組んでいます。 企画から販売までの一連のプロセスをデータで可視化し最適化することで、無駄を排除しお客様満足度向上とコスト削減を両立させようとしています。エンジニアはこの中心に位置し、デジタル業務改革サービス部という名前のとおり IT の中だけに閉じずに、業務のやり方を変革することが根幹にあるとご説明いただきました。 具体的な取り組みとしては、店舗と e コマース（EC）でシームレスな買い物体験を実現すべく、RFID を活用したセルフレジの導入も進めています。また、自動走行ロボットの導入による物流の自動化・効率化の推進も行なっており、ソフトウェア・ハードウェアの双方において幅広い取り組みがあります。 有明プロジェクトは、デジタルの力を最大限活用してビジネストランスフォーメーションを実現し、「情報製造小売業」への変革を成し遂げることを目的としています。先端技術を取り入れながら AWS 上に最適なプラットフォームを構築し、お客様への付加価値提供を実現する大規模な挑戦です。デジタル変革を通じて、ファーストリテイリングは「服を変え、常識を変え、世界を変えていく」ミッションを実現していこうとしているのです。 ファーストリテイリングの内製化の進化 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 部長 村田 雄一 氏 続いて、ファーストリテイリングの内製開発を推進するコアエンジニアリングチームの村田氏より、同社のデジタル変革の歴史と内製化の取り組みについてご紹介いただきました。 同社は早くから業務にデジタル技術を取り入れることの重要性を認識しており、1988 年の POS システム導入に始まり、1990 年代から自社で商品情報や販売情報のデジタル処理を行うようになりました。2000 年代にはオンラインストアを開設し、2010 年代の店舗スタッフによるデジタルデバイスの活用など各種のデジタル変革を進めてきました。そして 2016 年から始まった全社改革プロジェクトである有明プロジェクトの中で、本格的にエンジニアリングの内製化を開始しました。この内製化の取り組みにより、RFID を活用したセルフレジや在庫管理の改革、グローバル展開のための EC プラットフォームの構築などが実現されています。 内製化の背景には、情報の力を活用して製造小売業から本格的な情報小売業へ転身するという戦略があり、そのためにはプラットフォームを自社で作る必要があったことが挙げられます。また、「業務 = システム」という考え方に基づき、現場を深く理解し、単純明快なトータルシステムを組み、将来の方向性と矛盾しないシステムを構築することが重要視されていました。内製化の推進にあたっては、まず EC の領域から着手し、会員基盤の構築、カタログサイト開設、オンラインストア機能の拡張など、段階的に機能を拡張していきました。新規事業国から始め、日本、そしてグローバルへと展開範囲を広げていった点も特徴的です。 組織面では、グローバル人材を積極的に登用し英語を公用語とするなど国際化を進めています。また、正社員とパートナー企業が一つのスクラムチームを組むハイブリッド体制を採用しています。エンジニア人材の育成においては、ビジネスを理解し技術的な意思決定に反映できるシニアエンジニアを戦略的に育成することに注力しています。具体的には、アーキテクチャレビューボードを設置し、さまざまな業務要件を理解してアーキテクチャに落とし込む訓練を行っています。ボードメンバーをローテーションすることで、継続的な人材育成を図っています。 内製化による主な成果としては、トラブル発生時の解決スピードの向上とシステムに対するコントロール力の獲得が挙げられます。自社で作った仕組みなので問題の所在がわかりやすく、迅速な対応が可能です。技術の選定やビジネスロジックの理解など、重要な意思決定を迅速に行えるようになったことも大きな成果です。一方で、もともと持っていた服屋としてのカルチャーと IT エンジニアリングのカルチャー、日本的なカルチャーとグローバルのカルチャーの橋渡しや、グローバル展開に伴うスケール対応が課題となっています。今後は年間売上高 10 兆円を目指し、世界最高水準のグローバルエンジニアリング組織を日本発で作ることを目標としています。そのためには、ビジネスを理解し技術的な意思決定ができるシニアエンジニアの継続的な育成が不可欠であり、エンジニアにとって世界で最もやりがいのある職場を提供していく考えです。世界レベルのビジネスにチャレンジできる貴重な機会を提供し、困難に立ち向かうことでエンジニアが最も成長できる環境を整備していきたいとのことでした。 グローバル展開×店舗と EC の融合×売上 10 兆円への事業成長を支えるマイクロサービスプラットフォーム 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム リーダー 佘 嘯 氏 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 井上 夏樹 氏 続いて、ファーストリテイリング コアエンジニアリングチームの方々より、グローバル展開を支えるマイクロサービスプラットフォームと、EC・店舗を融合するための取り組みについてご紹介いただきました。まず佘氏よりこれまでの取り組みの概要をご説明いただきました。 従来は各ブランドや地域ごとに異なる EC システムを使用していたため、機能開発や運用にかかるコストが高く、非効率な部分がありました。そこで 2017 年から世界で一つの EC ソリューションを提供すべく EC の刷新に着手し、2020 年には日本で、2021 年にはアメリカで、そして 2024 年に韓国でもグローバル EC パッケージをリリースしました。新しい EC プラットフォームでは、デザインだけでなく機能面でも統一されています。グローバル EC プラットフォームの展開に際しては、マルチブランド対応や各国の言語・支払方法・法制度への配慮、グローバル標準化とローカライズの両立が基本方針とされています。今後もファーストリテイリングの事業拡大にあわせて、世界各地域への継続的な導入を進めていく計画です。 ファーストリテイリングの EC は、実店舗と連動する点に特徴があります。EC には一般的な購入履歴や通知、チャットボットなどに加え、実店舗と EC の融合のための O2O (Online to Offline、Offline to Online)の機能が搭載されています。O2O サービスには EC で購入した商品を店舗に配送して受け取る「店舗受取り」、EC から元々店舗にある在庫を受け取る申し込みができる「ORDER & PICK」、店舗在庫から自宅への直接配送「店舗発送」の 3 つのモデルがあります。これにより配送料の無料化や配送時間の短縮、店舗への顧客誘導、倉庫キャパシティの最適化が実現できます。 続いて、井上氏より EC システムの構成やアーキテクチャについてご紹介いただきました。ファーストリテイリングでは EC システムをグローバルなプラットフォームとして開発・運用しています。そしてフロントエンドとバックエンドの責務を明確に分離し、バックエンドはブランド横断的なマイクロサービス群を構築し、フロントエンドはブランド別に作られています。 リクエストフローで見るとユーザー端末→フロントエンドクライアント→ BFF (Backend for Frontend) →バックエンドマイクロサービスという構成になっています。 BFF の役割は、複数のマイクロサービスを呼び出してデータを集約し、クライアントが使いやすい形式でレスポンスを返すことです。合わせてデータキャッシュや認証・認可の処理も行います。バックエンドは特定のビジネスドメインを担うマイクロサービスが独立した API として提供さ れています。具体的な例を挙げると、ユーザーが商品を購入する場合には、買い物かご、商品情報、金額計算、クーポン、在庫、決済、注文管理などのマイクロサービスが呼び出されます。フロントエンドはウェブのレスポンシブな SPA (Single Page Application) とモバイルネイティブアプリから構成されます。SPA は共通のデザインシステムと国際化の仕組みを活用することで、仕組みは整えつつ各国にローカライズできるようにしています。モバイルアプリは Flutter で共通のコードベースを作りつつ、一部 Android/iOS のネイティブコードも使用します。 技術スタックとしては、インフラストラクチャ、ミドルウェア、プログラミング言語、フレームワークのすべてにおいて標準化を重視しています。バックエンドに Go や Java Spring Boot、フロントエンドに TypeScript や React、モバイルに Kotlin や Swift などを採用しています。 今後はグローバル展開を加速させる予定です。現地の言語、決済方法、物流、法制度などさまざまな要件をクリアしながら、段階的にロールアウトを進めていきます。また、年間売上高 10 兆円を目指すにあたり、トラフィック増加への対応が課題となっています。End to End での性能計測と改善に注力し、スケーラビリティの確保を図ります。 EC と実店舗を融合した O2O の取り組みも重要です。店舗と EC がシームレスに連携し、いつでもどこでも欲しい商品を購入できる体験を実現することが目標です。システムの高度化と店舗網の強みを生かし、お客様の利便性向上を追求していきます。 ( Part 2 に続く) 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

9月2日週、 最新の AWS ヒーロー が発表されました! AWS ヒーローは、インサイト、ベストプラクティス、革新的なソリューションを惜しみなく共有し、他のユーザーを支援する、素晴らしい技術エキスパートです。 AWS GenAI Loft は大盛況で、現在 サンフランシスコ と サンパウロ にて開催中です。また、今後数か月の間に ロンドン 、 パリ 、 ソウル で開催される予定です。9月2日週、サンフランシスコで開催されたワークショップの様子をご紹介します。 9月2日週のリリース 私が注目したいくつかのリリースをご紹介します。 Storage Browser for Amazon S3 (アルファリリース) – オープンソースの Amplify UI React コンポーネントです。 ウェブアプリケーションに追加すると、S3 に保存されているデータ用のシンプルなインターフェイスをエンドユーザーに提供 できます。このコンポーネントは、新しい ListCallerAccessGrants API を使用して、S3 アクセス権限の定義に従い、アクセスできるすべての S3 バケット、プレフィックス、オブジェクトを一覧表示します。 AWS Network Load Balancer – 設定可能な TCP アイドルタイムアウトのサポート を開始しました。詳細については、この ネットワーキングとコンテンツ配信のブログ記事 を参照してください。 AWS Gateway Load Balancer – こちらも 設定可能な TCP アイドルタイムアウトをサポート しています。詳細については、この ブログ記事 をご覧ください。 Amazon ECS – AWS Fargate を使用した AWS Graviton ベースの Spot コンピューティングのサポート を開始しました。これにより、耐障害性を備えた ARM ベースのアプリケーションを、オンデマンドと比較して最大 70% 低いコストで実行できます。 AWS リージョンのアベイラビリティーゾーンのゾーングループ – すべての AWS リージョンで一貫した命名形式を使用して、 ゾーングループコンストラクトをアベイラビリティーゾーン (AZ) まで拡張 できるよう取り組んでいます。 Amazon Managed Service for Apache Flink – Apache Flink 1.20 のサポート を開始しました。アップグレードすると、バグ修正、パフォーマンスの向上、Flink コミュニティによって追加された新機能といった利点をご活用、ご体験いただけます。 AWS Glue – ジョブキューイングの提供 を開始しました。Glue ジョブを開始するにあたってクォータまたは制限が不十分な場合、AWS Glue は自動的にジョブをキューに入れ、制限が解放されるのを待つようになりました。 Amazon DynamoDB – テーブルとインデックスの属性ベースのアクセス制御 (ABAC) のサポート を開始しました (限定プレビュー)。ABAC は、ユーザー、ロール、AWS リソースにアタッチされたタグに基づいてアクセス権限を定義する承認戦略です。詳細については、この データベースのブログ記事 をご覧ください。 Amazon Bedrock – Stability AI の上位テキスト画像変換モデル (Stable Image Ultra、Stable Diffusion 3 Large、Stable Image Core) が利用可能 になり、高品質のビジュアルを迅速かつ正確に生成できるようになりました。 Amazon Bedrock Agents – Anthropic Claude 3.5 Sonnet のサポート を開始しました。これには、開発者とエンドユーザーのエクスペリエンスを向上させる、関数呼び出しでの Anthropic 推奨 ツールの使用 も含まれます。 Amazon Sagemaker Studio – Studio ノートブックから直接 Amazon EMR Serverless を使用 して、インタラクティブにクエリ、検索、視覚化を行い、 Apache Spark ジョブを実行できるようになりました。 Amazon SageMaker – トレーニングジョブ、モデル、エンドポイントのリソースクラスなどの SageMaker リソースを操作するためのオブジェクト指向インターフェイスを提供する、新しい Python SDK である sagemaker-core をご紹介 します。 AWS AppSync – GraphQL API に DEBUG ログレベルと INFO ログレベルを含める ことで、モニタリングを改善しました。ログの冗長性をより細かく制御できるようになったため、API のトラブルシューティングが容易になると同時に、読みやすさとコストが最適化されます。 Amazon WorkSpaces Pools – Windows 10 または 11 のライセンスを持ち込む ことで、オンプレミスデスクトップと仮想デスクトップを切り替えても、一貫したデスクトップエクスペリエンスを提供できるようになりました。 Amazon SES – 最適なセットアップの推奨事項や、 Virtual Deliverability Manager による E メールの配信性を強化するオプションなど、SES の主要な機能を発見して有効化するのに役立つ、新しい 強化オンボーディングエクスペリエンス です。 Amazon Redshift – Amazon Redshift Data API がセッションの再利用のサポート を開始しました。これにより、あるクエリ実行から別のクエリ実行までセッションのコンテキストが保持され、同じデータウェアハウスへのクエリを繰り返す際の接続セットアップレイテンシーが短縮されます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Amazon Q Developer コードチャレンジ – シドニーで開催された 2024 年の AWS Summit では、2 つのチーム (片方のチームは Amazon Q Developer を使用し、もう片方のチームは使用しない) がコーディングの腕前を競いました。基本的な計算と文字列の操作から始めて、複雑なアルゴリズムや難解な暗号のコーディングまで行いました。 結果をご覧ください 。 AWS、Gartner 初の Magic Quadrant for AI Code Assistants でリーダーに選出 – 新しいテクノロジーが、ソフトウェア開発ライフサイクル全体を容易にし、開発者の生産性を向上させているのを見るのは素晴らしいことです。 LlamaIndex と Amazon Bedrock で強力な RAG パイプラインを構築 – シンプルなユースケースも高度なユースケースも含む、詳細なチュートリアルです。 Amazon Bedrock のプロンプト管理とプロンプトフローを使用したプロンプトの大規模な評価 – 自動プロンプト評価システムを実装して、プロンプト開発を合理化し、AI 生成コンテンツの全体的な品質を向上させています。 Amazon Redshift データインジェストオプション – 利用可能なインジェスト方法の概要と、さまざまなユースケースでの動作について説明します。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今年の AWS Summit は終了間近です。まだご登録いただけるのは、 トロント (9 月 11 日) と オタワ (10 月 9 日) の 2 つです。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。今後開催される AWS Community Day は、Antje Barth が基調講演を行うサンフランシスコベイエリア (9 月 13 日)、 アルゼンチン (9 月 14 日)、 アルメニア (9 月 14 日)、 DACH (ミュンヘン、9 月 17 日) です。 AWS GenAI Loft – クラウドと AI に関する AWS の専門知識を示すコラボレーションスペースと没入型体験です。また、スタートアップや開発者に、AI 製品やサービスへの実践的なアクセス、業界のリーダーとの限定セッション、投資家や仲間との貴重なネットワーキングの機会を提供します。 お近くの GenAI Loft の開催地を見つけて 、ご登録ください。 近日中に開催されるすべての AWS による対面およびバーチャルイベント は、こちらで閲覧することができます。 9月9日週はここまでです。9月16日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。 この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします!

2024 年 7 月と 8 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Cost Anomaly Detection AWS Cost Anomaly Detection は、機械学習モデルを使用して、AWS サービスの異常な支出パターンを検出して警告する機能です。本セッションでは、AWS Cost Anomaly Detection の概要、基本的な利用方法およびよくある質問について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS サービスのコスト異常を検出したい方 想定外のコスト発生時に迅速に対応したい方 AWS Cost Anomaly Detection の概要・基本的な利用方法を知りたい方 本 BlackBelt で学習できること AWS Cost Anomaly Detection の概要、基本的な利用方法について学んでいただけます コストモニターやしきい値などの設定例などについても学んでいただけます スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon ECS 入門 AWS の提供する、フルマネージド型のコンテナオーケストレーションサービスである、Amazon Elastic Container Service (Amazon ECS) をご存じでしょうか？本セッションでは、Amazon ECS の概要やその構成要素、振る舞いについて解説し、今から Amazon ECS を始めるために役立つ様々なリソースをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用予定のアプリケーションまたはインフラ担当者 Amazon ECS の概要や始め方を知りたい方 クラウドの既存ワークロードのコンテナ化を検討中の方 オンプレミスのコンテナワークロードのクラウド移行を検討中の方 本 BlackBelt で学習できること Amazon ECS とはどんなサービスなのか Amazon ECS の構成や動作概要 Amazon ECS の始め方 スピーカー 吉田 英史 ソリューションアーキテクト Amazon MemoryDB Amazon MemoryDB は耐久性をもったインメモリデータベースという新しいデータベースです。本セッションでは、Amazon MemoryDB の特徴と機能、ユースケースといった基礎的な部分から、バックエンドの動きやどのように耐久性を担保しているのかという技術的背景をまとめて解説致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon MemoryDB とは何かを知りたい方 Amazon MemoryDB をご利用予定の方 Amazon ElastiCache や Redis をご利用中で、より耐久性を高めたい方 本 BlackBelt で学習できること Amazon MemoryDB の特徴と機能 Amazon MemoryDB のユースケース どのように耐久性を担保しているのか 他のサービスとの使い分け、有効な活用方法 スピーカー 堤 勇人 ソリューションアーキテクト AWS MGN プライベートネットワーク経由でサーバを Amazon EC2 へ移行する方法 AWS Application Migration Service(AWS MGN) は、お客様のアプリケーションを AWS に移行するために推奨される主要なサービスです。本セッションでは「プライベートなネットワークを利用した AWS MGN による移行」を実施する方法を学習することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インターネット経由の経路が用意できない場合などに、プライベートなネットワークを用いた移行方法について理解したい方 AWS MGN の機能についてより詳しく理解したい方 本 BlackBelt で学習できること AWS MGN による移行に必要な通信要件 AWS MGN のプライベートなネットワーク経由での移行を実現する追加作業 スピーカー 鈴木　槙将 ソリューションアーキテクト Amazon CloudFront EdgeComputing 編 Amazon CloudFront の EdgeComputing に関するセミナーです。EdgeComputing の種類、実装方法、ユースケース等について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 CloudFront の利用を検討される方またはご利用中の方 EdgeComputing の CloudFront Functions / Lambda@Edge に興味がある方 本 BlackBelt で学習できること CloudFront Functions / Lambda@Edge の実装、使い所、ユースケース スピーカー 小林 謙介 パートナーセールスソリューションアーキテクト Amazon Connect のユーザー管理（Amazon Connect 再入門シリーズ） 本セッションでは Amazon Connect のユーザー管理の全体像についてご紹介します。Amazon Connect で利用できる ID 管理方式や、ユーザー管理に関連した各種機能、セキュリティ面からの注意点について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect を導入検討されていて、 Amazon Connect のユーザー管理方式やセキュリティについて全体的に理解したい方 Amazon Connect を既に導入済みで、 現行の Amazon Connect 環境のユーザー管理方式やセキュリティについてレビューを実施したい方 本 BlackBelt で学習できること Amazon Connect における ID 管理の全般的な機能について Amazon Connect のユーザー管理においてセキュリティ面から注意すべき点について スピーカー 遠藤 亘 ソリューションアーキテクト SaaS 成功のための基礎戦略と AWS 活用法　〜 SaaS 入門編〜 SaaS サービスを開発する際に必要な知識を解説するシリーズが登場しました。今回は、これから SaaS ビジネスを立ち上げる方や、既存のパッケージサービスを SaaS 化する際に必要な知識をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 SaaS についての基礎知識をつけたい方 自社サービスの SaaS 化を検討されている方 顧客向けに SaaS サービスの構築を提案されたい方 本 BlackBelt で学習できること SaaS を構築する際の基礎的な考え方 スピーカー 前田 進吾 ソリューションアーキテクト SaaS 成功のための基礎戦略と AWS 活用法 〜 SaaS Business 基礎編 〜 SaaS サービスを開発する際に必要な知識を解説するシリーズです。今回は、これから SaaS ビジネスを立ち上げる方や、既存のパッケージサービスを SaaS 化する際に必要な知識をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 SaaS についての知識が不安な方 SaaS プロダクトの開発を始める方 パッケージの SaaS 化を検討している方 本 BlackBelt で学習できること SaaS プロダクトを作るときのフェーズについて説明します。特に AWS がお勧めしている SaaS Journey Framework について解説し、自社の企業タイプに合った SaaS Journey の進み方について学ぶことができます。 スピーカー 遠藤 宣嗣 ソリューションアーキテクト SaaS Builder Toolkit for AWS (SBT) の紹介 AWS がオープンソースで開発する SaaS Builder Toolkit for AWS (SBT) の概要と使い方について紹介します。SBT は、SaaS 開発・運用のベストプラクティスが実装された再利用可能なツールキットです。SBT を活用することで、開発工数を抑えながら、ベストプラクティスに準拠した SaaS のコントロールプレーンを構築することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS で SaaS の構築を検討中の方 SaaS のベストプラクティスについて深く学びたい方 SaaS の開発、運用に携わっている方 本 BlackBelt で学習できること SaaS 開発/運用のベストプラクティス SaaS コントロールプレーンの構築方法 SaaS on AWS のリファレンスアーキテクチャ スピーカー 櫻谷広人 パートナーソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2024-09 AWS IoT Greengrass 開発運用編 ソリューションアーキテクト 宇佐美雅紀 2024-09 AWS Shield Advanced ソリューションアーキテクト 岡 豊 2024-09 AWS Fargate 入門 ソリューションアーキテクト 吉田 英史 2024-09 AWS Payment Cryptography ソリューションアーキテクト 松原 武司 2024-10 Amazon EKS 入門 ソリューションアーキテクト 鈴木 祥太

9月4日より、 Stability AI の 3 つの新しい Text-to-Image モデル (Stable Image Ultra、Stable Diffusion 3 Large、Stable Image Core) を Amazon Bedrock で使用できるようになりました。これらのモデルは、複数サブジェクトのプロンプト、画質、タイポグラフィのパフォーマンスを大幅に改善し、マーケティング、広告、メディア、エンターテインメント、小売など、さまざまなユースケースで質の高いビジュアルを迅速に生成するために使用できます。 これらのモデルは、すばらしいフォトリアリズムで画像を生成することに秀でており、優れたディテール、色、ライティングを誇り、リアルな手や顔をレンダリングするなどの一般的な課題に対処します。モデルの高度なプロンプト理解により、空間推論、構成、スタイルを含む複雑な指示を解釈できます。 Amazon Bedrock で使用できる 3 つの新しい Stability AI モデルは、さまざまなユースケースをカバーしています。 Stable Image Ultra – プロフェッショナルな印刷メディアや大判の用途に最適な、極めて質の高いフォトリアリスティックな出力を生成します。Stable Image Ultra は、優れたディテールとリアリズムのレンダリングに秀でています。 Stable Diffusion 3 Large – 生成速度と出力の質のバランスに優れています。ウェブサイト、ニュースレター、マーケティング資料など、ボリュームが多く、質の高いデジタルアセットを作成するのに最適です。 Stable Image Core – 高速で手頃な料金の画像生成に最適化されており、アイデア出しの最中にコンセプトを迅速にイテレーションするのに最適です。 次の表は、モデルの主な特徴をまとめたものです。 特徴 Stable Image Ultra Stable Diffusion 3 Large Stable Image Core パラメータ 160 億 80 億 26 億 入力 テキスト テキストまたは画像 テキスト タイポグラフィ 大規模な表示向けに カスタマイズ 大規模な表示向けに カスタマイズ さまざまなサイズやアプリケーションにわたる 汎用性と読みやすさ 視覚的な 美しさ フォトリアリスティックな 画像出力 非常にリアルで 細部まできめ細かい 優れたレンダリング、 詳細指向ではない Stable Diffusion XL (SDXL) と比較した場合の Stable Image Ultra と Stable Diffusion 3 Large の主な改善点の 1 つは、生成された画像のテキストの質です。革新的な Diffusion Transformer アーキテクチャにより、スペルやタイポグラフィのエラーが少なくなっています。このアーキテクチャは、画像とテキストに 2 つの個別の重みセットを実装しますが、2 つのモダリティ間での情報の流れを可能にします。 これらのモデルを使用して作成された画像をいくつかご紹介します。 Stable Image Ultra – プロンプト: photo, realistic, a woman sitting in a field watching a kite fly in the sky, stormy sky, highly detailed, concept art, intricate, professional composition. Stable Diffusion 3 Large –  プロンプト: comic-style illustration, male detective standing under a streetlamp, noir city, wearing a trench coat, fedora, dark and rainy, neon signs, reflections on wet pavement, detailed, moody lighting. Stable Image Core – プロンプト: professional 3d render of a white and orange sneaker, floating in center, hovering, floating, high quality, photorealistic. Amazon Bedrock の新しい Stability AI モデルのユースケース Text-to-Image モデルは、さまざまな業界の企業に変革の可能性を提供するとともに、マーケティング部門や広告部門のクリエイティブワークフローを大幅に合理化できます。これにより、キャンペーン、ソーシャルメディアコンテンツ、製品モックアップのために、質の高いビジュアルを迅速に生成できます。クリエイティブプロセスを迅速化することで、企業は市場のトレンドにより迅速に対応し、新しい取り組みの市場投入までの時間を短縮できます。さらに、これらのモデルはブレインストーミングセッションを強化できるため、さらなるイノベーションにつながるコンセプトを、即座に、かつ、視覚的に表現できます。 e コマースビジネスでは、AI 生成画像を使用することで、多様な製品ショーケースやパーソナライズされたマーケティング資料を大規模に作成できます。ユーザーエクスペリエンスやインターフェイスデザインの領域では、これらのツールによってワイヤーフレームやプロトタイプを迅速に生成し、デザインのイテレーションプロセスを加速できます。Text-to-Image モデルを採用することで、さまざまなビジネス機能にわたるビジュアルコミュニケーションにおいて、大幅なコスト削減、生産性の向上、競争力の向上を実現できます。 さまざまな業界のユースケースの例をいくつかご紹介します。 広告とマーケティング Stable Image Ultra: 高級ブランドの広告やフォトリアリスティックな製品ショーケース Stable Diffusion 3 Large: 質の高い製品マーケティング画像や印刷キャンペーン Use Stable Image Core: ソーシャルメディア広告のビジュアルコンセプトの迅速な A/B テスト E コマース Stable Image Ultra: 高級製品のカスタマイズやオーダーメイドの商品 Stable Diffusion 3 Large: e コマースサイト全体のほとんどの製品ビジュアル Stable Image Core: 製品画像の迅速な生成と、リストの最新状態の維持 メディアとエンターテインメント Stable Image Ultra: 超リアルなキーアート、マーケティング資料、ゲームビジュアル Stable Diffusion 3 Large: 環境テクスチャ、キャラクターアート、ゲーム内アセット Stable Image Core: ラピッドプロトタイピングとコンセプトアートの探索 それでは、これらの新しいモデルの実際の動作を、まずは AWS マネジメントコンソール を使用して、次に AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用して見てみましょう。 Amazon Bedrock コンソールでの新しい Stability AI モデルの使用 Amazon Bedrock コンソール で、ナビゲーションペインから [モデルアクセス] を選択し、 [Stability AI] セクションの 3 つの新しいモデルへのアクセスを有効にします。 アクセスできるようになったので、ナビゲーションペインの [プレイグラウンド] セクションで [画像] を選択します。モデルには、 [Stability AI] と [Stable Image Ultra] を選択します。 プロンプトとして、次のように入力します。 A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says "Stable Image Ultra in Amazon Bedrock". 他のオプションはすべてデフォルト値のままにし、 [実行] を選択します。数秒後、要求した内容が表示されます。画像は次のとおりです。 AWS CLI での Stable Image Ultra の使用 コンソールの [画像プレイグラウンド] にいる間に、プレイグラウンドウィンドウの角にある 3 つの小さなドットを選択し、 [API リクエストを表示] を選択します。このようにして、コンソールで実行した操作と同等の AWS コマンドラインインターフェイス (AWS CLI) コマンドを確認できます。 aws bedrock-runtime invoke-model \ --model-id stability.stable-image-ultra-v1:0 \ --body "{\"prompt\":\"A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says \\\"Stable Image Ultra in Amazon Bedrock\\\".\",\"mode\":\"text-to-image\",\"aspect_ratio\":\"1:1\",\"output_format\":\"jpeg\"}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ invoke-model-output.txt Stable Image Core または Stable Diffusion 3 Large を使用するために、 モデル ID を置き換える ことができます。 前述のコマンドは、テキストファイル内の JSON オブジェクト内に Base64 形式で画像を出力します。 1 つのコマンドで画像を取得するために、出力 JSON ファイルを標準出力に書き込み、 jq ツールを使用してエンコードされた画像を抽出し、その場でデコードできるようにします。出力は img.png ファイルに書き込まれます。完全なコマンドは次のとおりです。 aws bedrock-runtime invoke-model \ --model-id stability.stable-image-ultra-v1:0 \ --body "{\"prompt\":\"A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says \\\"Stable Image Ultra in Amazon Bedrock\\\".\",\"mode\":\"text-to-image\",\"aspect_ratio\":\"1:1\",\"output_format\":\"jpeg\"}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ /dev/stdout | jq -r '.images[0]' | base64 --decode > img.png AWS SDK での Stable Image Ultra の使用 Stable Image Ultra を AWS SDK for Python (Boto3) で使用する方法は次のとおりです。このシンプルなアプリケーションは、Text-to-Image プロンプトをインタラクティブに要求し、Amazon Bedrock を呼び出して画像を生成します。 import base64 import boto3 import json import os MODEL_ID = "stability.stable-image-ultra-v1:0" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-west-2") print("Enter a prompt for the text-to-image model:") prompt = input() body = { "prompt": prompt, "mode": "text-to-image" } response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(body)) model_response = json.loads(response["body"].read()) base64_image_data = model_response["images"][0] i, output_dir = 1, "output" if not os.path.exists(output_dir): os.makedirs(output_dir) while os.path.exists(os.path.join(output_dir, f"img_{i}.png")): i += 1 image_data = base64.b64decode(base64_image_data) image_path = os.path.join(output_dir, f"img_{i}.png") with open(image_path, "wb") as file: file.write(image_data) print(f"The generated image has been saved to {image_path}") アプリケーションは、結果として得られる画像を output ディレクトリ (存在しない場合は作成されます) に書き込みます。既存のファイルを上書きしないように、コードは既存のファイルをチェックして、 img_<number>.png 形式で使用可能な最初のファイル名を見つけます。 Stable Diffusion モデルの使用方法の他の例は、 AWS ドキュメント の「 コードライブラリ 」でご覧いただけます。 お客様の声 Stability AI の Global Alliance Director である Ken Hoge 氏から、Stable Diffusion モデルが Text-to-Image から、動画、音声、3D へと業界をどのように再編しているか、また Amazon Bedrock がオールインワンで安全かつスケーラブルなソリューションでお客様をサポートする方法を学びましょう。 Stride Learning の Product Owner である Nicolette Han 氏とともに、読書が生き生きとした体験になる世界に足を踏み入れましょう。Amazon Bedrock と AWS のサポートにより、Stride Learning の Legend Library は、子供向けの物語の魅力的で安全なイラストを作成するために AI を使用して、若者が文学に関わり、理解する方法を変革しています。 知っておくべきこと 新しい Stability AI モデルである Stable Image Ultra 、 Stable Diffusion 3 Large 、および Stable Image Core は、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で9月4日からご利用いただけます。このリリースにより、Amazon Bedrock は、創造性を高め、コンテンツ生成ワークフローを加速するための幅広いソリューションを提供します。ご自身のユースケースのコストを理解するには、 Amazon Bedrock の料金ページ をご覧ください。 Stable Diffusion 3 の詳細については、基盤となるテクノロジーを詳細に説明する 研究論文 をご覧ください。 まずは、 「Amazon Bedrock ユーザーガイド」の Stability AI のモデルのセクション をご覧ください。他のユーザーがソリューションで生成 AI をどのように使用しているかを知り、詳細な技術コンテンツで学ぶには、 community.aws にアクセスしてください。 – Danilo 原文は こちら です。

AWS ヒーロープログラム では、AWS コミュニティ内で意義ある貢献をしている優れた個人を表彰しています。これらの技術エキスパートは、インサイト、ベストプラクティス、革新的なソリューションを惜しみなく共有し、他のユーザーが AWS で効率を高め、より迅速に構築できるように支援しています。ヒーローとは、多大な貢献とリーダーシップを通じて、より広範な AWS コミュニティを強化することに尽力しているソートリーダーです。 AWS ヒーローの最新のグループをご紹介します! Faye Ellis 氏 – ロンドン (英国) コミュニティヒーローである Faye Ellis 氏は、Pluralsight の Principal Training Architect です。Ellis 氏は同社において、組織や個人が AWS スキルを身に付けられるようサポートすることに特化して取り組んでおり、世界中の何百万もの人々に AWS を教えてきました。同氏はまた、世界中の人々がやりがいのあるクラウドキャリアを築けるようにすることにも尽力しています。IT 業界で 10 年超の経験を持つ同氏は、ミッションクリティカルなシステムの設計とサポートに関する専門知識を活かして、アクセスしやすく理解しやすい方法でクラウドテクノロジーを説明しています。 Ilanchezhian Ganesamurthy 氏 – チェンナイ (インド) コミュニティヒーローである Ilanchezhian Ganesamurthy 氏は現在、北欧の大手 IT サービス企業である Tietoevry で Director – Generative AI (GenAI) and Conversational AI (CAI) を務めています。2015 年以来、同氏は AWS User Group India に積極的に関与しており、2018 年には AWS User Group Chennai の共同主催者の役割を務めました。同グループのメンバーは 4,800 人にまで増えています。Ganesamurthy 氏は多様性と包括性を推進し、次世代のクラウドエキスパートを育成することの重要性を認識しています。同氏は AWS Cloud Clubs の強力な支持者であり、クラウドプロフェッショナルを目指す人々をサポートするために、業界のつながりを活用して、チェンナイ支部がイベントやネットワーキングを主催するのを支援しています。 Jaehyun Shin 氏 – ソウル (韓国) コミュニティヒーローである Jaehyun Shin 氏は、韓国のオンラインファッション小売業者である MUSINSA の Site Reliability Engineer です。同氏は 2017 年に AWS Korea User Group (AWSKRUG) に参加し、それ以来、AWSKRUG Serverless and Seongsu Groups の共同所有者を務めています。この間、Shin 氏は AWS コミュニティビルダーとして、専門知識を活かして新しい Korea User Group のリーダーをメンタリングおよび育成してきました。また、AWS Community Day やハンズオンラボのイベント主催者としても積極的に活動し、韓国の AWS コミュニティをさらに強化してきました。 Jimmy Dahlqvist 氏 – マルメ (スウェーデン) サーバーレスヒーローである Jimmy Dahlqvist 氏は、AWS アドバンストティアサービスパートナーであり、スウェーデンの大手コンサルティング会社の 1 つである Sigma Technology Cloud の Lead Cloud Architect and Advisor です。2024 年、同氏は自身のすべてのサーバーレスアドベンチャーの拠点として Serverless-Handbook を立ち上げました。Dahlqvist 氏は AWS 認定の対象分野の専門家でもあり、AWS 認定があらゆる人々にとって公平であるようにするワークショップに定期的に参加しています。 Lee Gilmore 氏 – ニューカッスル (英国) サーバーレスヒーローである Lee Gilmore 氏は、イングランド北東部のニューカッスルに拠点を置く AWS コンサルティングパートナーである Leighton の Principal Solutions Architect です。テクノロジー業界で 20 年超の経験を持つ同氏は、過去 10 年間にわたって、サーバーレスおよびクラウドネイティブテクノロジーを専門としてきました。Gilmore 氏は、自らの仕事の中心であるドメイン駆動型設計とイベント駆動型アーキテクチャに熱心に取り組んでいます。さらに、serverlessadvocate.com で詳細な記事を定期的に執筆するとともに、GitHub でオープンソースのフルソリューションを共有し、国内外のイベントで頻繁に講演しています。 Maciej Walkowiak 氏 – ベルリン (ドイツ) DevTools ヒーローである Maciej Walkowiak 氏は、ドイツのベルリンを拠点とする独立 Java コンサルタントです。同氏は約 20 年にわたって、高速かつスケーラブルでメンテナンスが容易な Java アプリケーションの設計と開発において、スタートアップから大企業まで、さまざまな企業をサポートしてきました。これらのアプリケーションの大部分は、ソフトウェア構築に同氏が好んで使用するツールである Spring Framework と Spring Boot をベースとしています。2015 年以来、同氏は Spring エコシステムに深く関わっており、AWS API と Spring プログラミングモデルをつなぐ GitHub の Spring Cloud AWS プロジェクトを率いています。 御田 稔 氏 – 東京 (日本) コミュニティヒーローである 御田 稔 氏は、KDDI アジャイル開発センター株式会社 (KAG) のテックエバンジェリストです。2021 年に Japan AWS User Group (JAWS-UG) に参加し、現在は東京支部、SRE 支部、NW-JAWS の 3 つのコミュニティの運営をリードしています。近年は AWS で生成 AI を活用することに注力しており、Amazon Bedrock の入門レベルの技術書をコミュニティメンバーと共同執筆し、日本で出版しました。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブサイト にアクセスしてください。 – Taylor 原文は こちら です。

本ブログは 2024年8月9日に公開された「 Using SAW to diagnose common issues in your AWS environment 」を翻訳・一部改変したものとなります。 はじめに AWS環境でシステム問題を手動でトラブルシューティングし解決することは、繰り返し作業が多く、間違いが起こりやすいです。 AWSサポートでは、AWSのお客様がセルフサービスによる診断と修復を可能にする機能であるサポートオートメーションワークフロー（SAW）を提供しています。 SAWは、 AWS System Manager を活用して、トラブルシューティングプロセスを簡素化し、解決手順を示す、使いやすい厳選されたオートメーションランブックを提供しています。 ランブックを使用すると、接続問題のトラブルシューティング、権限エラーの診断、 Amazon Elastic Compute Cloud（Amazon EC2） アクセスのリセットなどをすばやく行うことができます。 オートメーションランブック（プレフィックスは AWSSupport または AWSPremiumSupport です）は、Amazon EC2、 Amazon Simple Storage Service（Amazon S3） 、 Amazon Elastic Kubernetes Service（EKS） 、 Amazon Elastic Container Service（ECS） などのさまざまなAWSサービスで利用できます。 この記事では、SAW がどのようにトラブルシューティングを自動化して、AWS環境の一般的な問題を診断するかを説明します。 オートメーションランブックによって合理化されたトラブルシューティングにより、システム問題の根本原因の分析と修復をより迅速に行うことができます。 サポートオートメーションワークフロー（SAW）とは AWS Systems Manager SAW について学ぶ前に、SAW の基盤である AWS System Managerとは何かを理解する必要があります。AWS Systems Managerは、AWSのアプリケーションとリソースの運用ハブであり、安全なエンドツーエンドの管理ソリューションです。 SAWは、 Amazon Systems Manager Automation の上に構築されたオートメーションランブックです。これらのランブックは、AWSリソースの一般的な問題のトラブルシューティングや、ネットワークの問題の特定、ログの収集と分析などに役立ちます。 AWS環境でのトラブルシューティングと診断の強化 SAW は、Amazonの哲学の核心である、Customer Obsession を表しています。 SAWの起源は顧客体験に根ざしています。 お客様が AWS サポートにお問い合わせすると、当社のエンジニアが問題を解決し、解決策とともに問題を文書化します。 その中で、繰り返し発生する問題の傾向と、顧客体験を向上させる可能性を確認しました。 これらの洞察から、お客様をより良くサポートするため、セルフサービスを可能にするカスタムツールを構築しました。 SAWは、当社の経験、ベストプラクティス、長年にわたって学んだ教訓を活用して、反復的で時間のかかる手動の顧客タスクを排除し、発生する可能性のあるさまざまなトラブルシューティングの問題に対処するための強力なツールとなっています。 SAWが役立つユースケースには、SSH接続の問題のトラブルシューティング、EC2のディスク使用状況の分析、Amazon S3の問題の診断、Amazon EKSまたはAmazon ECS環境での重要なログの収集などがあります。 これらのランブックは、EC2インスタンスへのSSHアクセスがない場合や、インスタンスがAWS System Manager VPCエンドポイントの有効になっているプライベートサブネットにある場合に特に役立ちます。 次のような他のユースケースも見つかるかもしれません。 診断、トラブルシューティング、修復： AWSPremiumSupport-Troubleshootec2DiskUsage を使用して、Amazon EC2インスタンスのディスク使用に関する問題を調査し、場合によっては修正します。さらに、ボリューム、パーティション、ファイルシステムの拡張をオペレーティングシステム（OS）レベルで自動化することもできます。 管理分析と設定更新の自動化： AWSSupport-EnableVPCFlowLogs を使用して、AWS アカウントの複数のサブネット、ネットワークインターフェイス、VPC の Amazon VPC フローログを設定します。 コスト最適化と運用レビュー： AWSPremiumSupport-PostgreSQLWorkloadReview 使用して、Amazon Relational Database Service（Amazon RDS）のPostgreSQLデータベース使用統計のスナップショットをキャプチャします。 診断目的のログ収集:たとえば、 AWSSupport-CollecteKSInstanceLogs を利用して、クラスターの問題をトラブルシューティングするために、Amazon Elastic Kubernetes Service（Amazon EKS）からオペレーティングシステムレベルのログファイルを収集できます。 さまざまなユースケースに役立つ他のランブックを見るには、 SAW のランディングページ にアクセスしてください。役立つリストがあります。 SAWを使用して手動プロセスを合理化し、時間と労力を節約する方法を見ていきましょう。 SAWの使用を開始する 前提条件 SAWを続行するには、以下が必要です。 使用する AWS Identity and Access Management（IAM）ユーザまたは IAM ロールに、 Systems Manager コンソール にアクセスするための 最低限必要な IAM 権限 があることを確認してください。 ランブックを開始するために、次の権限があることを確認してください。 ssm:StartAutomationExecution ssm:GetAutomationExecution ssm:SendCommand プレフィックス AWSPremiumSupport が付いたランブックを使用する場合は、AWSビジネスまたはエンタープライズサポートプランを利用していることを確認してください。 ランブックがEC2インスタンスでアクションを実行するためには、 AWS Systems Manager Agent（SSM Agent） がインストールされ必要な権限が付与されていることを確認してください。そのためには、AWS 管理ポリシー AmazonSsmManagedInstanceCore を EC2インスタンスプロファイルに対応するIAMロールにアタッチする必要があります。 SAW ランブックを使用するには、 AWS Systems Managerコンソール に移動し、使用するAWSリージョンを選択します。 Systems Managerコンソールで、左側のナビゲーションメニューの [共有リソース] セクションの下にある [ドキュメント] を探してください。 ここでは、Amazonが提供しているすべてのAWS Systems Managerドキュメントを見ることができます。 AWS サポートが管理する SAW ランブックを見つけるためには、検索ボックスに AWSSupport と入力してください。 まず、 AWSSupport-ListEC2Resources ランブックを例に見てみましょう。 このドキュメントは、AWSアカウントの EC2 インスタンス、Elastic IP、EBSボリューム、Auto Scaling グループなどのEC2関連リソースを一覧表示するのに役立ちます。 ランブックを実行するには、「 オートメーションを実行する 」を選択します。 実行が完了すると詳細が表示され、実行結果の出力が表示されます。 AWS CLIを使用してランブックを実行する場合は、 aws ssm start-automation-execution コマンドを使用することで実行できます。 以下は、すべてのAWSリージョンのEC2リソースを一覧表示するコマンド例です。 aws ssm start-automation-execution --document-name "AWSSupport-ListEC2Resources" --parameters '{"RegionsToQuery":["All"]}' 出力: { "AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1" } オートメーションのステータスを取得するには、次のコマンドを実行します。 aws ssm describe-automation-executions \ --filter "Key=ExecutionId,Values=6053b7c6-7ec7-4b9b-b52c-04ddd912ede1" 上記コマンドの values の値を、手元の Automation ExecutionId に置き換えてください。 出力: { "AutomationExecutionMetadataList": [ { "AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1", "DocumentName": "AWSSupport-ListEC2Resources", "DocumentVersion": "7", "AutomationExecutionStatus": "InProgress", "ExecutionStartTime": "2024-03-13T09:53:45.685000+00:00", "ExecutedBy": "arn:aws:sts::123456789012:assumed-role/Administrator/Admin", "LogFile": "", "Outputs": {}, "Mode": "Auto", "CurrentStepName": "listVolumes", "CurrentAction": "aws:executeScript", "Targets": [], "ResolvedTargets": { "ParameterValues": [], "Truncated": false }, "AutomationType": "Local" } ] } ユースケース SSH接続の問題のトラブルシューティング AWSSupport-TroubleshootSSH ランブックは、Linux SSHの一般的な問題を解決します。 このランブックは、 Amazon EC2Rescue tool for Linux (ec2rl) の実行を効率化し、SSH経由でLinuxマシンにリモート接続できない一般的な問題を修正 します。 このランブックでは、AWS Systems Managerによって管理されていないEC2インスタンスもサポートします。 オフライン修復を指定すると、修正プロセス中に EC2 インスタンスが自動的に停止・起動します。 AWS Systems Manager エージェントが EC2 インスタンスにインストールされているかに関わらず、このランブックは、EC2インスタンスに接続できないときにSSHエラーを診断して問題を解決するのに役立ちます。 たとえば、SSHの設定ミスのためにEC2インスタンスに接続できない場合は、このランブックを起動して、数回クリックするだけでこのエラーから回復できます。 $ ssh ec2-user@1.2.3.4 ssh: connect to host 1.2.3.4 port 22: Connection refused 分析したいEC2インスタンスを選択し、ランブックを実行します。 EC2インスタンスにSSMエージェントがインストールされている場合は、 インスタンスプロファイルに十分なIAM権限があり 、AWS System Managerで管理できることを確認してください。 そうでない場合は、ランブックのオフライン修復を使用することで、問題のあるインスタンスの設定を見直します。 設定の見直しでは、問題のあるインスタンスの EBSボリュームをデタッチし、レスキューインスタンスアタッチした上で設定を確認します。不適切な設定が修正されたのち、 EBS ボリュームは元のインスタンスに再度アタッチされます。 このオートメーションはインスタンスを停止し、操作を試みる前にAMIを作成することに注意してください。 インスタンスストアボリューム に保存されているデータは失われます。 Elastic IPアドレスを使用していない場合、パブリックIPアドレスは変更される可能性があります。 オフライン修復を使用するには、問題のあるEC2インスタンスを選択し、次のパラメータを使用してこのランブックを実行します。 Action: FixAll (CheckAllはオフラインモードではサポートされていません) AllowOffline: True Subnet: {EC2 インスタンスと同じサブネットを選択} オフライン修復でオートメーションを実行すると、レスキュー EC2インスタンスが作成されます。レスキュー EC2 インスタンスに問題のあるインスタンスのEBSボリュームがアタッチされ、エラーの修正が行われます。 オートメーションが完了したら、実行結果とリソースを確認できます。 私の場合は、誤って構成されたSSHファイルが修正され、EC2インスタンスに正常に接続できました。このエラーの修正には1〜2分しかかかりません。 EC2アクセスとパスワードの回復 AWSSupport-ResetAccess ランブックは、WindowsとLinuxの両方でEC2管理権限が失われたアクセス問題を解決することを目的としたランブックです。 このランブックは、指定した EC2 インスタンスで EC2Rescue ツールを使用して、EC2 コンソール経由で EC2 インスタンスのパスワード復号化を再度有効化するか（Windows）、新しい SSH キーペアを生成して追加します（Linux）。 EC2 Windowsインスタンスのキーペアを紛失した場合、このオートメーションによりパスワード対応のAMIが作成され、新しいキーペアを使用して新しいEC2インスタンスを起動できます。 SSHのトラブルシューティングランブックと同様に、このオートメーションによりインスタンスが停止するため、ステップを実行する前に、アタッチされた インスタンスストアボリューム （存在する場合）にデータが残っていないことを確認してください。 さらに、Elastic IPアドレスを使用していない場合、インスタンスを停止するとパブリックIPアドレスが変更される可能性もあります。 EC2インスタンスへのアクセスを回復するには、EC2インスタンスを選択してランブックを実行するだけです。 SubnetId には問題のあるEC2インスタンスと同じサブネットIDを選択するか、デフォルト値の CreateNewVPC のままにします。ドキュメント「 EC2 インスタンスでのパスワードと SSH キーのリセット 」を参照してください。 ステップが実行されると、次のステップの手順が出力セクションに表示されます。 このランブックは、オートメーションの一環として、バックアップAMIとパスワード対応の AMIを作成します。 キーペアを紛失したときのアクセスを回復するには、パスワード対応の AMIを使用して、新しいキーペアで新しいEC2 Windowsインスタンスを起動できます。 同様に、同じランブックを使用して、EC2 LinuxインスタンスのSSHアクセスを回復できます。 この方法では、新しい SSH プライベートキーが作成され、暗号化された状態で AWS System Manger Parameter Store に保存されます。パラメータ名は /ec2rl/openssh/{インスタンス ID}/key です。 私の場合、オートメーションにより、 -----BEGIN OPENSSH PRIVATE KEY----- で始まる新しい OpenSSH プライベートキーが生成されました。ファイルを保存してRSA形式に変換します。RSA形式 —–BEGIN RSA PRIVATE KEY—– のプライベートキーを入手した場合はこの手順を省略できます。 $ chmod 600 saw.pem $ ssh-keygen -p -N "" -m pem -f saw.pem Key has comment 'Added by EC2 Rescue for Linux' Your identification has been saved with the new passphrase. 取得したプライベートキーを使用して、EC2 Linuxインスタンスに正常に接続できます。 $ ssh -i saw.pem ec2-user@1.2.3.4 EC2のディスク使用量を分析し、空きディスク容量を増やす AWS ビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランのお客様は、 AWSPremiumSupport-Troubleshootic2DiskUsage ランブックを利用して、EBSボリュームの使用状況を分析したり、オペレーティングシステム（OS）レベルでパーティションやファイルシステムの拡張を自動化したりすることもできます。 AWSリージョン、AWS中国リージョン、AWS GovCloud（米国）リージョンで利用でき、WindowsインスタンスとLinuxインスタンスの両方をサポートしています。 ディスク容量を増やすプロセスの効率化の詳細については、 AWS re:Post の記事 を参照してください。 たとえば、Linuxファイルシステムの空きディスク容量が不足していて、それらを拡張したい場合は、まずEBSボリュームのサイズを増やし、 複数の AWS CLI コマンドを実行してファイルシステムを拡張する必要があります 。 EC2インスタンスが多い大規模な環境では、多大な時間と労力がかかり、運用の負担になる可能性があります。 aws ssm start-automation-execution コマンドまたは StartAutomationExecution APIでオートメーションランブックを活用して、オートメーションをバッチで実行できます。 ディスク使用量の診断に役立つだけでなく、問題を修復して、ボリュームとそのファイルシステムを一度に拡張することもできます。 EKSまたはECSノードから重要なログを収集します Amazon Elastic Kubernetes Service（EKS）とAmazon Elastic Container Service（ECS）は、AWS上のフルマネージドなコンテナオーケストレーションサービスです。 どちらも、コンテナ化されたアプリケーションを実行するための異なるコンピューティングオプションを提供します。 コンピュートリソースの典型的なタイプの1つは、EC2インスタンスの使用です。インスタンスをクラスターに追加して、Amazon EKS または Amazon ECS で管理できるようにする必要があります。 しかし、インスタンスにトラブルシューティングが必要な問題がある場合は、 EKS Log Collector または ECS Log Collector を使用して、エラーを特定するための重要なシステムレベルの情報（kubelet、ECSエージェント、システム構成など）を収集することが不可欠です。 ただし、EC2インスタンスがSSHアクセスを提供しないか、プライベートネットワークの設定によって制限されているため、スクリプトの実行とログの収集が難しい場合があります。 AWSSupport-CollectEKSInstanceLogs と AWSSupport-CollectECSInstanceLogs はこれらの問題の解決に役立つランブックです。 どちらもEKSまたはECSからのログ収集プロセスを自動化し、収集手順を簡素化します。これらのランブックでは SSMが管理するEC2インスタンスを選択できます。ログ収集スクリプトを実行した結果は EC2 インスタンスに保存されます。 さらに、バンドルログをAmazon S3バケットにアップロードするオプションも提供しています。これは、複数のインスタンスを一元的に確認する必要がある場合に役立ちます。 EKSクラスターのトラブルシューティング AWSSupport-TroubleshooteKSWorkerNode は、 Kubernetes ワーカーノードが Amazon EKSクラスターに参加できない 原因を迅速に特定するのに役立つ典型的なランブックです。 Amazon EKS クラスターには、ノードと呼ばれるワーカーマシンのセットがあります。 ほとんどのユースケースでは、 EKS に最適化された AMI で EC2インスタンスを起動し、それをクラスターのコンピュートリソースとして登録する必要があります。 ただし、クラスターにノードを追加するときに失敗する可能性のある要因がいくつかあります。たとえば、VPC設定の誤り、ユーザーデータの誤り、必要なタグの欠落、接続の問題などです。 以前は、各構成を確認してこれらの問題のトラブルシューティングを行っていましたが、明らかではないエラーを見逃すこともありました。ランブックを使用して、これらすべての時間を節約できます。 可能性のあるエラーと原因が Outputs セクションに表示されます。 さらに、AWSビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランに加入しているお客様は、 AWSPremiumSupport-TroubleshooteKSCluster ランブックにもアクセスできます。 Kubernetes Cluster Autoscaler、内部ロードバランサーの作成に関する問題、ワーカーノードの使用する AMI のレビュー、Amazon ECR からのイメージの取得失敗、マネージドノードが安定しないなど、Amazon EKS 環境でよくあるエラーをトラブルシューティングする別のオプションを提供します。 どのようなチェックが実行されるかについては、 AWS re:Post の記事 を参照してください。 ECSのトラブルシューティング Amazon ECSは、コンテナ化されたアプリケーションのライフサイクルを管理するためにECSタスクを使用します。 ただし、ECSタスクはさまざまな理由で開始できず、根本原因を特定するのが難しい場合があります。 AWS Support-TroubleshootsTaskFailedToStart は、このような状況に役立つランブックです。 構成を自動的に見直して接続をテストすることで、タスクの開始を妨げる可能性のある一般的な問題の分析プロセスを合理化し、問題を解決するために実行可能なガイダンスを提供します。 たとえば、パブリックサブネットで次の接続エラーでECSタスクを開始できない場合を考えます。 ルートテーブルとネットワークの設定、さらに、VPCとサブネットのネットワーク設定タスクをが正しいことを確認しましたが、タスクを開始できない根本原因が不明です。 この場合、入力パラメータ ClusterName と TaskId を使用してランブックを実行することで、失敗したタスクを診断できます。今回は、ECSタスクを起動するときにパブリックIPの自動割り当てオプションを有効していなかったことが原因として出力されました。また、Output セクションでは問題の対処法も確認できます。 SAW についてもっと知る この投稿では、サポートオートメーションワークフローのいくつかのユースケースを説明し、トラブルシューティングプロセスをどのように強化できるかを学びました。 AWSサポートは継続的にトラブルシューティング技術を革新し、より良いサポート体験を提供することに専念しています。 AWS SAWの可能性をまだ探っていない人は、今日試してみることを勧めます。 What’s New with AWS から、新機能に関する発表を購読してください。 AWS サポートチームが作成した AWS Support self-service runbooks の使用方法 をご覧ください。 AWS YouTubeチャンネルでデモ AWS Supports You: Using Support Automation Workflows を見てください。 Systems Manager オートメーションランブックリファレンスを確認してください。これは、AWS Systems Manager で利用できるさまざまなオートメーションランブックに関する詳細情報を提供する包括的なリソースです。 定義済みの各ランブックには、詳細な説明、ステップバイステップの説明、入力と出力の例が記載されています。 特定のAWSサービスに基づいて分類された幅広いランブックを見つけることができます。 著者略歴 Eason Cao Eason は、AWSコンテナソリューションを専門とし、5年以上の業界経験を持つシニアクラウドサポートエンジニアです。 AWSのコンテナサービスの専門家として、顧客がクラウド環境の課題を克服し、分散システムを最適化できるよう支援することに専念しています。 翻訳はクラウドサポートアソシエイトの Ayu Sonoda が担当しました。

この記事は、 SaaS authentication: Identity management with Amazon Cognito user pools を翻訳したものです。 Amazon Cognito は、数百万人のユーザーにスケールできるカスタマーアイデンティティおよびアクセス管理 (CIAM) サービスです。 Cognito 開発者ガイド では利用可能なマルチテナンシーモデルについて詳しく説明されていますが、どのモデルを使うべきかを判断するのは時に難しい場合があります。このブログ記事では、各モデルを使う際のガイダンスを提供し、お客様の意思決定に役立つよう、長所と短所を確認します。 Cognito の概要 Amazon Cognito は、Web およびモバイルアプリのユーザーアイデンティティ管理とアクセス制御を行います。Cognito の ユーザープール を使えば、アプリにサインアップ、サインイン、アクセス制御を追加できます。Cognito ユーザープールは、特定の AWS リージョン 内のユーザーディレクトリで、ユーザーはアプリケーションに対して認証とユーザー登録ができます。さらに、Cognito ユーザープールは OpenID Connect (OIDC) のアイデンティティプロバイダー (IdP) でもあります。アプリユーザーは、ユーザープールに直接サインインするか、サードパーティの IdP を経由して連携できます。Cognito は、認証が成功すると、バックエンド API やリソースへのセキュアなアクセスに使えるユーザープールトークンを発行します。 Cognito は 3 種類のトークンを発行します: ID トークン – 名前、メールアドレス、電話番号などのユーザーアイデンティティクレームが含まれます。このトークンタイプは、ユーザーを認証し、アプリや API ゲートウェイでの認可決定を可能にします。 アクセストークン – ユーザークレーム、グループ、許可されたスコープが含まれます。このトークンタイプは、認証されたユーザーとアプリケーションの権限に基づいて、API 操作へのアクセスを許可します。また、アプリケーションやサービス内で、ユーザーベースの詳細なアクセス制御を可能にします。 リフレッシュ (更新) トークン – ID トークンとアクセストークンの有効期限が切れた場合に、新しいトークンを取得します。アクセストークンと ID トークンは短命ですが、リフレッシュトークンは長命です。デフォルトでは、リフレッシュトークンはユーザーがサインインしてから 30 日後に期限切れになりますが、これは 60 分から 10 年の範囲で設定できます。 トークンの使用方法とその内容の詳細については、 Cognito 開発者ガイド を参照してください。 マルチテナンシーアプローチ Software as a Service (SaaS) アーキテクチャでは、しばしばサイロ、プール、ブリッジのデプロイメントモデルが使われます。これらのモデルは、Cognito のような CIAM サービスにも適用されます。サイロモデルは、テナントを専用リソースに分離します。プールモデルは、リソースをテナント間で共有します。ブリッジモデルは、サイロ化されたコンポーネントとプール化されたコンポーネントを接続させて使います。この記事では、SaaS アイデンティティ管理における Cognito のサイロモデルとプールモデルを比較します。 リソースの持ち方を複数のティアごとに分けることで、サイロモデルとプールモデルを組み合わせることも可能です。たとえば、機密性の高いテナントデータ用のサイロ化されたティアと、共有機能用のプール化されたティアを持つことができます。これはサイロモデルに似ていますが、ティアに接続するためのルーティングの複雑さが加わります。複数のプールやサイロがある場合、これは純粋なサイロモデルと同様のアプローチですが、管理するコンポーネントが増えます。 これらのモデルの詳細については、 AWS SaaS Lens を参照してください。 以下のセクションでは、5 つのパターンを詳しく説明し、それぞれのパターンが使える状況、長所と短所を探っています。この記事の残りの部分では、これらのさまざまなパターンの詳細を掘り下げ、独自の要件と制約に最もよく合ったものを選択できるようにしています。 パターン 1: カスタム属性を使った SaaS アイデンティティの表現 SaaS アプリケーションでマルチテナンシーを実装するには、テナントコンテキスト (訳者注: テナント識別子やティア) をユーザーのアイデンティティ (訳者注: メールアドレスなどのユーザー属性) に関連付ける必要があります。これにより、SaaS アプリケーションを構成するマルチテナントポリシーや戦略を実装できます。Cognito には、アイデンティティを表す情報である ユーザープール属性 があります。名前やメールアドレスなどの 標準属性 はユーザーのアイデンティティを記述するものです。Cognito はまた、 ユーザーとテナントの関係 を保持するための tenantId などの カスタム属性 をサポートしています。 Amazon Cognito でカスタム属性をマルチテナンシーに使うことで、各ユーザーのテナントコンテキストをユーザープロファイルに保存できます。 マルチテナンシーを有効にするには、 tenantId のようなカスタム属性をユーザープロファイルに追加します。新規ユーザー登録時に、この tenantId 属性にユーザーが所属するテナントを示す値を設定できます。たとえば、 tenantId が “1234” のユーザーは Tenant A に、 tenantId が “5678” のユーザーは Tenant B に所属します。 この tenantId 属性値は、ユーザー認証成功後に ID トークンで返されます (この値は トークン生成前の Lambda トリガー を使ってアクセストークンにも追加できます)。アプリケーションはこのクレームを検査し、ユーザーが所属するテナントを判断できます。 tenantId 属性は通常 SaaS プラットフォームレベルで管理され、ユーザーやアプリケーション層からは読み取り専用です (注: SaaS プロバイダーは tenantId 属性を読み取り専用に設定する必要があります)。 テナント ID を保存するだけでなく、カスタム属性を使ってさらにテナントコンテキストをモデル化できます。たとえば tenantName 、 tenantTier 、 tenantRegion などの属性を定義し、アプリケーションに関連する情報コンテキストを適切に設定できます。ただし、カスタム属性をデータベースのように使わないよう注意が必要です。アイデンティティを表すものであり、アプリケーションデータを保存するものではありません。カスタム属性には、付与するアクセス権限の決定と JSON Web トークン (JWT) をコンパクトに保てる範囲の情報を含めるべきです。また、 Cognito ディレクトリに保存される情報は比較的静的である必要があります。頻繁に変化するデータを更新するには、ディレクトリを変更する必要があり、面倒です。 カスタム属性自体は、Amazon Cognito ユーザープールの作成時に定義する必要があり、最大 50 のカスタム属性を作成できます。プールが作成されると、これらのカスタム属性フィールドがそのユーザープールの全ユーザープロファイルに存在するようになります。ただし、まだ値は設定されていません。実際のテナント属性値は、ユーザープールに新しいユーザーが作成された時にのみ設定されます。これには 2 つの方法があります。 ユーザー登録時に、 確認後の Lambda トリガー を使って、ユーザーの入力に基づき適切なテナント属性値を設定できます。 管理者ユーザーが AdminCreateUser API 操作で新しいユーザーをプロビジョニングし、その時にテナント属性値を指定できます。 ユーザー作成後、必要に応じて管理者が AdminUpdateUserAttributes API 操作、またはユーザーが UpdateUserAttributes API 操作でカスタムテナント属性値を更新できます。ただし、ポイントはカスタム属性自体はユーザープール作成時に事前定義する必要があり、値はユーザー作成とプロビジョニングフローの後に設定されることです。図 1 は、カスタム属性が ID トークンに関連付けられ、その後ダウンストリームのアプリケーションで使用される様子を示しています。 図 1: カスタム属性を使ってテナントコンテキストを関連付ける 図 1 に示すように: ユーザープロファイルからのカスタムテナント属性値が、ユーザー認証成功後に生成される Cognito ID トークンに含まれます。これらの値は、 Amazon API Gateway などの他の AWS サービスのアクセス制御に使用できます。 Amazon API Gateway に Lambda オーソライザー関数を設定し、ID トークン署名を検証 (この目的には aws-jwt-verify ライブラリ を使用できます) し、各リクエストのテナント ID クレームを検査できます。 Lambda オーソライザー関数は、ID トークンから抽出したテナント ID 値に基づき、認証済みユーザーがアクセスを許可されているバックエンドリソースやサービスを判断できます。 この方法を使うと、 このブログ記事 で説明されているように、ユーザークレームに加えてテナントクレームをコンテキストとして使用することで、細かいアクセス制御を提供できます。ユーザーアイデンティティと関連テナントの詳細を 1 つのトークンに埋め込むこのパターンを、AWS では SaaS アイデンティティ と呼んでいます。 個別のユーザープール、共有プール、カスタム属性を使うマルチテナンシーアプローチは、いずれもユーザーのアイデンティティにテナントコンテキストを埋め込むことに依存しています。これは、Cognito が認証後に発行する JWT にテナント情報が入ったクレームを含めることで実現されます。 JWT はユーザー名、メールアドレスなどのユーザーアイデンティティ情報をエンコードします。テナント識別子やメタデータを含むカスタムクレームを追加することで、テナントコンテキストがユーザーアイデンティティに密接に関連付けられます。JWT に埋め込まれたテナントコンテキストにより、アプリケーションは各ユーザーに関連付けられたテナントに基づいてアクセス制御と認可を実装できます。 発行された JWT のユーザーアイデンティティ情報とテナントコンテキストの組み合わせが SaaS アイデンティティ、つまりユーザーとテナントの両次元にまたがる統合アイデンティティを表します。アプリケーションはこの SaaS アイデンティティを使って、マルチテナントのロジックやポリシーを実装します。 パターン 2: 共有ユーザープール (プールモデル) 単一で共有された Amazon Cognito ユーザープールは、マルチテナント SaaS アプリケーションのアイデンティティ管理を簡素化します。1 つに統合されたプールでは、変更と設定がテナント全体に一か所で適用されるため、オーバーヘッドを削減できます。 たとえば、パスワードの複雑さのルールやその他の設定をユーザープールレベルで 一度定義すると、これらの設定がテナント間で共有されます。新しいテナントを追加する際は、既存の共有プールの設定を使用するため、テナントごとに同じ設定をしなくて済み、効率化されます。新しいテナントをオンボーディングする際に、テナントごとに個別のプールをデプロイする必要がなくなります。 さらに、共有プールから発行されるトークンは、同じ発行者 (Issuer) によって署名されます。共有プールを使用する場合、トークンはテナント固有の発行者にはなりません。共通のアイデンティティニーズを持つ SaaS アプリでは、テナントごとのカスタマイズができなくなりますが、共有マルチテナントプールを使用することは、迅速なオンボーディングに適しています。 プールモデルの長所: このモデルでは、テナントに対して単一の共有ユーザープールを使用します。これにより、複数のユーザープールを設定する代わりに、ユーザー属性を設定するだけでオンボーディングが簡素化されます。 テナントは同じアプリケーションクライアントとユーザープールを使用して認証するため、SaaS クライアントの設定が単純になります。 プールモデルの短所: 1 つのプールを共有するため、パスワードポリシーや MFA などの設定は統一され、テナントごとのカスタマイズは不可となります。 リソースクォータ の一部 (アプリケーションクライアントの数やカスタム属性の数など) はユーザープールレベルで管理されるため、このモデルを採用する際はクォータを慎重に検討する必要があります。 パターン 3: グループベースのマルチテナンシー (プールモデル) Amazon Cognito ユーザープールでは、管理者がグループを追加し、ユーザーをグループに関連付けることができます。これにより、Cognito によって管理され、 ID トークン 内で利用可能な特定の属性 ( cognito:groups と cognito:roles ) が導入されます ( アクセストークン には cognito:groups 属性のみが含まれます)。 これらのグループを使用して、各テナントごとにグループを作成することで、マルチテナンシーを実現できます。ユーザーは、カスタムの tenantId 属性の値に基づいて、適切なテナントグループに割り当てることができます。次に、アプリケーションは、トークンにエンコードされたユーザーのテナントグループメンバーシップに基づいてリソースとデータへのアクセスを制限する認可ロジックを実装できます。これにより、Cognito のネイティブグループ構造を利用してテナント分離とアクセス制御を提供し、カスタム属性に完全に依存する必要がなくなります。 トークンに含まれるグループ情報は、ダウンストリームのサービスで認可決定に使用できます。グループは、より細かいアクセス制御のためにカスタム属性と組み合わせて使用されることが多くあります。たとえば、 AWS SaaS Factory チーム が開発した SaaS Factory Serverless SaaS – Reference Solution では、テナントアイデンティティはカスタム tenantId によって決定しますが、テナント内でのユーザーの役割は Cognito グループを使用して指定されています。このリファレンスソリューションにおいて、テナントアイデンティティ属性はテナント分離を提供し、グループは特定のテナント内で適用される個々のユーザーの役割とアクセス権限を定義しています。 図2は、グループがユーザーに関連付けられ、その後 Lambda オーソライザーがそれぞれの認証済みユーザーがアクセスを許可されているバックエンドリソースとサービスを決定する方法を示しています。 図 2: グループベースのマルチテナンシー このモデルでは、グループはロールベースの制御を提供し、テナント ID などのカスタム属性はテナント分離を実施するために必要な情報を提供します。認可決定は、ユーザーのグループメンバーシップと属性値を評価することで、各テナントとユーザーに合わせた細かいアクセス制御を提供します。つまり、グループは直接的にロールベースのチェックを可能にし、カスタム属性はテナントの条件付きアクセスのための広範なコンテキストを提供します。両者を組み合わせることで、マルチテナントアプリケーションで細かい認可を実装するために必要なデータを提供できます。 グループベースのマルチテナンシーの長所: このモデルでは、複数テナントに対して単一の共有ユーザープールを使用するため、オンボーディングはユーザー属性の設定で済み、複数のプールを構成する必要がありません。 テナントは同じアプリケーションクライアントとプールを通して認証を行うため、SaaSクライアントの構成が簡素化されます。 グループベースのマルチテナンシーの短所: 1 つのプールを共有するため、パスワードポリシーや MFA などの設定は統一され、テナントごとのカスタマイズは不可となります。 ユーザープールあたり最大10,000グループの制限があります。 パターン 4: テナントごとに専用のユーザープールを用意する (サイロモデル) Cognito でのマルチテナントアイデンティティのもう1つのよくある方法は、各テナントに対して個別のユーザープールをプロビジョニングすることです。Cognito のユーザープールはユーザーディレクトリなので、個別のプールを使用することで最大の分離が可能になります。ただし、この方法ではアプリケーション側でテナントのルーティングロジックを実装し、ユーザーのテナントに基づいて認証対象のユーザープールを決定する必要があります。 テナントルーティング テナントごとに個別のユーザープール (または後で説明するアプリケーションクライアント) を使用する場合、アプリケーションには各ユーザーを適切なプール (またはクライアント) にルーティングするロジックが必要です。このアプローチでは、次のようなオプションを使用できます: URL にサブドメインを使用してテナントにマッピングします。たとえば、tenant1.myapp.com は Tenant 1 のユーザープールにルーティングされます。これにはサブドメインをテナントプールにマッピングする必要があります。 テナントごとに一意のメールドメインを使用します。たとえば、@tenant1.com は Tenant 1 のプールに行きます。これにはメールドメインをプールにマッピングする必要があります。 ユーザーにテナントをドロップダウンリストから選択させます。これにはテナントの選択肢を設定する必要があります。 ユーザーにテナント ID コードを入力させます。これにはコードをプールにマッピングする必要があります。 選択したアプローチに関係なく、主な要件は次のとおりです: テナントを識別するデータポイント (サブドメイン、メール、選択、コードなど) ユーザーからテナント識別情報を取得し、対応するユーザープールを検索してルーティングするためのマッピングデータセット 適切なユーザープールにリダイレクトするためのルーティングロジック たとえば、 AWS SaaS Factory Serverless Reference Architecture では、図 3 に示すアプローチを使用しています。 図 3: テナントごとに専用のユーザープール ワークフローは次のとおりです: ユーザーはサインイン時にテナント名を入力します。 テナント名からユーザープール ID、アプリケーションクライアント ID、API URL などのテナント固有の情報を取得します。 テナント固有の情報が SaaS アプリに渡され、正しいユーザープールとアプリクライアントで認証を初期化し、認可コードフローを初期化するために使用されます。 アプリは Cognito のホストされた UI に認証のためにリダイレクトします。 ユーザー資格情報が検証され、Cognito から OAuth コードが発行されます。 OAuth コードが Cognito の JWT と交換されます。 JWT を使用してユーザーをマイクロサービスにアクセスするために認証します。 テナントごとにプールを 1 つずつ持つモデルの長所: ユーザーは単一のディレクトリに存在し、クロステナントでの可視性はありません。トークンはそのプールに固有の鍵で発行され、署名されます。 各プールでは、パスワードルールや MFA 要件などのセキュリティポリシーをテナントごとにカスタマイズできます。 プールは、データ保管の要件を満たすために異なる AWS リージョンでホストできます。 テナントごとにプールを 1 つずつ持つモデルの潜在的な短所: アカウントあたりのプール数に制限があります (デフォルトは 1,000 プール、最大は 10,000 プールです)。 複数のプール、特にカスタマイズされた設定のプールを作成するには、追加の自動化が必要です。 アプリケーションは、認証リクエストを正しいユーザープールに向けるためのテナントルーティングを実装する必要があります。 各プールの設定が個別に管理され、テナントルーティング機能が追加されるため、トラブルシューティングが難しくなる可能性があります。 まとめると、個別のユーザープールはテナントの分離を最大化しますが、より複雑なプロビジョニングとルーティングが必要になります。大規模なマルチテナントデプロイメントの場合は、プール数の制限も考慮する必要があるかもしれません。 パターン 5: テナントごとのアプリケーションクライアント (ブリッジモデル) グループとカスタム属性を使用する以外に、単一のユーザープールでテナントごとに個別のアプリケーションクライアントを使用することでも、テナントの分離を実現できます。アプリケーションクライアントの Cognito 設定 (OAuth スコープ、ホストされた UI のカスタマイズ、セキュリティポリシーなど) は、テナントごとに固有のものにできます。また、アプリケーションクライアントを使用すれば、テナントごとに外部 IdP のフェデレーションも可能です。ただし、パスワードポリシーなどのユーザープールレベルの設定は共有されたままです。 図 4 は、単一のユーザープールに複数のアプリケーションクライアントを設定する方法を示しています。それぞれのアプリケーションクライアントは、各テナントに割り当てられています。ただし、このアプローチでは、アプリケーション内でテナントをどのアプリケーションクライアントにマッピングするかを判断するためのロジックを実装する必要があります (共有ユーザープールの場合と同様のアプローチです)。ユーザーが認証されると、Amazon API Gateway に Lambda オーソライザー関数を設定して ID トークンの署名を検証できます。その後、Lambda オーソライザー関数は、認証されたユーザーがアクセスを許可されているバックエンドリソースとサービスを判断できます。 図 4: アプリケーションクライアントベースのマルチテナンシー SAML または OpenID Connect フェデレーションを使って独自の IdP を利用したいテナントの場合は、ユーザーをテナントの連携 IdP にリダイレクトして認証する専用のアプリケーションクライアントを作成できます。これには以下のような主なメリットがあります: アプリケーションクライアントに単一の外部 IdP が有効化されている場合、ホストされた UI は自動的にユーザーをリダイレクトし、Cognito のサインイン画面を表示しません。これにより、テナントにとっては馴染みのあるサインイン体験が提供され、テナント IdP にセッションが既にある場合は、シームレスな体験になります。 ユーザーの追加や離脱、パスワードの管理など、ユーザーアクティビティの管理は、テナント側の IdP で完全に処理されます。SaaS プロバイダーはこれらのプロセスに関与する必要がありません。 重要なのは、フェデレーションを使用する場合でも、Cognito は外部認証が成功すると引き続きトークンを発行することです。つまり、SaaS プロバイダーは、IdP に関係なく、認可時に Cognito から発行される一貫したトークンを検証できます。 属性マッピング 外部 IdP と連携する場合、Amazon Cognito は発行するトークンに属性を動的にマッピングできます。これにより、IdP で作成されたグループ、メールアドレス、ロールなどの属性が認証時に Cognito に渡され、トークンに追加されます。 マッピングは、サインイン時に毎回行われ、既存のマッピング済み属性を上書きして IdP の最新の値と同期します。したがって、マッピング済み属性に関連する外部 IdP での変更は、サインイン後に Cognito に反映されます。メールアドレスのようにサインインに必要なマッピング済み属性がある場合、IdP に同等の属性があってマッピングする必要があります。Cognito の対象属性は変更可能に設定する必要があります。作成後は不変の属性はマッピングによっても上書きできません。 重要 : SaaS アイデンティティの場合、テナント属性は外部 IdP からマッピングするのではなく、Cognito で定義する必要があります。これにより、テナントが値を改ざんするのを防ぎ、分離を維持できます。ただし、グループやロールなどのユーザー属性は、テナントの IdP からマッピングしてアクセス許可を管理できます。これにより、テナントは独自の IdP グループを使用してアプリケーションのロールを設定できます。 ブリッジモデルの長所: このモデルでは、OAuth スコープ、UI、IdP などのテナント固有の設定が可能です。 テナントユーザーは外部 IdP を通じて馴染みのあるワークフローにアクセスでき、外部 IdP を使用する場合、テナントユーザー管理は外部で行われます。 カスタムクレームマッピングは必要ありませんが、オプションで使用できます。 Cognito はトークンを発行して認可を行えます。 ブリッジモデルの短所: ユーザーをテナントごとの正しいアプリクライアントにルーティングする必要があります。 ユーザープールごとのアプリクライアント数に制限があります。 パスワードポリシーなどの一部のユーザープール設定は共有されたままです。 動的なグループクレームの変更はできません。 まとめ このブログ記事では、 Amazon Cognito ユーザープールが SaaS ソリューションのマルチテナント ID をどのように有効にできるかについて、さまざまな方法を探りました。単一の共有ユーザープールは管理を簡素化しますが、ユーザープールレベルのポリシーをカスタマイズするオプションが制限されます。一方、個別のプールは分離と構成の柔軟性を最大化しますが、複雑さが増します。複数のアプリケーションクライアントを使用すると、外部 IdP や OAuth スコープなどのカスタマイズされたオプションと、ユーザープールの集中管理ポリシーとのバランスを取ることができます。カスタムクレームマッピングは柔軟性がありますが、追加のロジックが必要です。 これら 2 つのアプローチを組み合わせることもできます。たとえば、一部の上位層のテナントには専用のユーザープールを用意し、他のテナントはマルチテナントプールを共有するなどです。最適な選択は、特定のテナントのニーズと必要なカスタマイズ次第です。 このブログ記事では主に静的なアプローチについて説明しましたが、 トークン生成前の Lambda トリガー を使用してトークンを動的に変更し、クレームを追加、変更、削除することもできます。このトリガーは、ID トークンとアクセストークンの両方でグループメンバーシップを上書きすることもできます (訳者注: アクセストークンのカスタマイズには、Cognito の高度なセキュリティ機能を有効化する必要があります)。その他のクレーム変更は ID トークンにのみ適用されます。このトリガーの一般的な使用例は、テナント属性をトークンに動的に注入することです。 SaaS アーキテクチャとテナントの要件に対して、それぞれのアプローチの長所と短所を評価してください。ハイブリッドモデルが最適な場合が多くあります。Cognito のユーザープール、IdP、トリガーなどの構成要素を使用すると、テナント全体で認証と認可を細かく調整できます。 これらのトピックの詳細については、Cognito 開発者ガイドの 一般的な Amazon Cognito シナリオ と関連ブログ記事 How to Use Cognito Pre-Token Generation trigger to Customize Claims in ID Tokens を参照してください。   Shubhankar Sumar Shubhankar はAWSのシニアソリューションアーキテクトで、英国の企業ソフトウェアや SaaS のお客様と協力して、セキュアで拡張性があり、効率的で費用対効果の高いシステムを設計するのを支援しています。彼は多くの SaaS ソリューションを構築してきた経験豊富なソフトウェアエンジニアです。Shubhankar の専門分野は、クラウド上でマルチテナントプラットフォームを構築することです。また、顧客とも密接に連携して、SaaS アプリケーションに GenAI 機能を導入することにも取り組んでいます。 Owen Hawkins Owen は20年以上の情報セキュリティの経験を持ち、AWS のプリンシパル・ソリューション・アーキテクトとして深い専門知識を持っています。彼はデジタルバンキングのセキュリティに関する豊富な経験を活かして、ISV の顧客に密接に協力しています。Owen は SaaS およびマルチテナントアーキテクチャに特化しています。彼は企業がクラウドを安全に活用できるようにすることに情熱を持っています。複雑な課題を解決することは Owen にとって大きな喜びであり、AWS でアプリケーションを保護し実行するための革新的な方法を見つけることにやりがいを感じています。 翻訳はソリューションアーキテクト 中山 七美 が担当しました。原文は こちら です。

この記事は、 Tenant portability: Move tenants across tiers in a SaaS application を翻訳したものです。 今日の急速に変化する Software as a Service (SaaS) 環境において、テナントのポータビリティは、競争力を維持しようとする SaaS プロバイダーにとって重要な機能です。テナントのティア間の円滑な移動を可能にするポータビリティにより、企業は変化するニーズに適応できます。しかし、ティア移動のリクエストに手動で対応することは大きなボトルネックとなり、スケーラビリティを阻害し、多大なリソースを必要とします。テナントの数とポータビリティのリクエストが増加するにつれ、このアプローチはサステナブルではなくなり、より効率的な解決策を実装することが不可欠になります。 このブログ記事では、テナントのポータビリティの重要性を掘り下げ、 SaaS サーバーレスリファレンスアーキテクチャ へのシームレスな統合にフォーカスしながら、実装に不可欠なステップを概説します。次の図はティア移動のプロセスを示しており、テナントと管理者の役割、およびアーキテクチャ内の新規および既存サービスにおける影響が強調されています。次のセクションでは、この図に示されたイベントの順序を詳しく説明します。 図1. SaaS サーバーレスリファレンスアーキテクチャ内でテナントのポータビリティを組み込む なぜテナントのポータビリティが必要なのか? * 柔軟性: テナントによるティアのアップグレードまたはダウングレードの場合、ティアの移動は変化するテナントの需要、選択、予算、ビジネス戦略に合わせて行われます。これらのティア変更は、通常、テナントと SaaS プロバイダー間のサービス契約の変更を伴います。 * サービス品質: SaaS 管理者によるテナント移行は、セキュリティ違反や、テナントがサービス制限に達した際の対応として行われます。これらのインシデントでは、サービスレベル契約 (SLA) を維持するためにテナントの移行が必要になる可能性があります。 大まかなポータビリティフロー テナントのポータビリティは、通常、ティア間の移行をシームレスに行うために適切にオーケストレーションされたプロセスを通じて実現されます。このプロセスは以下のステップで構成されています: 図2. テナントポータビリティの大まかなフロー アイデンティティストアの移行 : テナントのアイデンティティストアをターゲットのティアに移行する必要があるかどうかを評価します。既存のアイデンティティストアがターゲットティアと互換性がない場合は、移行先ティアのアイデンティティストアと管理者ユーザーをプロビジョニングする必要があります。 テナント設定の更新 : SaaS アプリケーションは、テナント ID やティアなど、運用に必要なテナント設定情報を保存しています。 リソース管理 : ターゲットのティアにリソースをプロビジョニングし、インフラストラクチャとテナントのマッピングテーブルを更新するためのデプロイメントパイプラインを開始します。 データ移行 : テナントのデータを古いティアからターゲットティアの新しくプロビジョニングされたインフラストラクチャに移行します。 カットオーバー : テナントのトラフィックを新しいインフラストラクチャにリダイレクトし、更新されたリソースをダウンタイムなく利用できるようにします。 検討事項のウォークスルー ここでは、ポータビリティのワークフローにおける各ステップを詳しく見ていき、実装における重要な検討事項を強調します。 1. アイデンティティストアの移行 アイデンティティの移行における主な検討事項は、パスワードのリセットやユーザー ID の変更を必要とせずに、一貫したエンドユーザーエクスペリエンスを維持しながら、ユーザーの ID を移行することです。 フロントエンドが使用できる新しい ID ストアと関連するアプリケーションクライアントを作成した後、ユーザーを移行するメカニズムが必要になります。Amazon Cognito を使用した リファレンスアーキテクチャ では、各テナントが独自のユーザープールを持つことを「サイロ」と呼び、複数のテナントが ユーザーグループ を通じてユーザープールを共有することを「プール」と呼んでいます。 スムーズな移行プロセスを確保するため、ユーザーとコミュニケーションを取り、パスワードのリセットを回避するオプションを提供することが重要です。1 つのアプローチとして、期限までにログインするようユーザーに通知し、パスワードのリセットを回避することができます。ログイン時に ジャストインタイムマイグレーション を採用し、既存のパスワードを維持することで、ユーザーエクスペリエンスを阻害せずにパスワードを保持できます。 ただし、これにはすべてのユーザーが移行するまで待つ必要があり、移行期間が長期化する可能性があります。補完的な対策として、期限後に残りのユーザーを 一括インポート を使用して移行することができます。これにより、パスワードのリセットが強制されますが、一定の期間内で一貫した移行を確実に行えます。ただし、一部のユーザーには不便をかけることになります。 2. テナント設定の更新 SaaS プロバイダーは、すべてのテナント関連の設定を保持するためにメタデータストアを利用しています。移行プロセス中にテナントメタデータを更新する際は、慎重に行う必要があります。新しいティアのためにテナント設定を更新する際は、次の 2 つの重要な側面を考慮する必要があります。 移行プロセス全体を通して テナント ID を保持する ことで、移行後のテナントのログ、メトリクス、コスト請求について円滑に統合でき、イベントの継続的な記録が可能になります。 新しいティアに合わせて、テナントの使用量の上限を高めるための 新しい API キー とスロットリングメカニズムを確立します。 SaaS リファレンスアーキテクチャに新しいテナントポータビリティサービスを導入することで、この処理を行います。このサービスは、ティア変更のリクエストに基づいてテナントに異なる AWS API Gateway の使用量プランを割り当て、後続サービスの呼び出しを調整します。その後、既存のテナント管理サービスを拡張し、リクエストに基づいてテナントメタデータ (ティア、ユーザープール ID、アプリクライアント ID) を更新する必要があります。 3. リソース管理 インフラストラクチャのプロビジョニングにおけるポータビリティの成功は、以下の 2 つの重要な側面に依存します。 移行プロセス中の テナント分離 構成を尊重 し、クロステナントのアクセスを防ぎます。ロールベースのアクセス制御 (RBAC) または 属性ベースのアクセス制御 (ABAC) を使用して、これを確実にすることができます。前のステップでテナント ID が保持されている場合、ABAC 分離が移行中でも管理しやすいものとなります。 新しいティアで 計装とメトリクス収集 が正しく設定されていことを確認します。SaaS 運用の監視可視性を確保するために、同一の メトリクスフィルター を再作成します。 リファレンスアーキテクチャにおいて、インフラストラクチャのプロビジョニングとデプロビジョニングを処理するには、テナントプロビジョニングサービスを拡張します。 テナントスタックのマッピングテーブルを更新して、移行したテナントスタックの詳細を記録します。 必要に応じてインフラストラクチャのプロビジョニングまたは削除のパイプラインを開始します (例えば、データ移行とユーザーカットオーバーの手順の後に不要なインフラストラクチャを削除するパイプラインを実行します）。 最後に、関連するセキュリティ設定を適用し、 コンプライアンス に準拠したアプリケーションのバージョンをデプロイすることで、新しいリソースが必要なコンプライアンス基準を満たすことを確認します。 これらの事項に対処することで、SaaS プロバイダーはテナント分離と運用の継続性を維持しながら、シームレスな移行を確実にすることができます。 4. データ移行 データ移行戦略は、ストレージエンジンや分離アプローチなどのアーキテクチャに大きく影響されます。移行中のユーザーのダウンタイムを最小限に抑えるには、移行プロセスの加速、サービスの可用性維持、増分更新のためのレプリケーションチャネルの設定に重点を置く必要があります。さらに、プールモデルに移行する際のデータ整合性を確保し、データ損失を回避するために、サイロモデルでテナントが行ったスキーマ変更に対処することが重要です。 リファレンスアーキテクチャを拡張し、新しいデータ移行サービスを導入することで、異なるティア間での Amazon DynamoDB データ移行を可能にできます。DynamoDB パーティション移行には、 AWS Glue 、 カスタムスクリプト 、 DynamoDB テーブルの複製 、 パーティションの一括削除 などの複数のアプローチがあります。ゼロダウンタイムの移行を実現するには、 ハイブリッドアプローチ をお勧めします。このソリューションは、DynamoDB のスキーマがティアを越えて一貫している場合にのみ適用されます。スキーマが変更されている場合は、データ移行に カスタムソリューション が必要です。 5. カットオーバー カットオーバーフェーズでは、ユーザーを新しいインフラストラクチャに切り替え、継続的なデータレプリケーションを無効化し、 コンプライアンス要件 が満たされていることを確認します。これには、高い機密性が求められるサイロへの移行時には特に、テスト実行や監査や認証の取得を含むことになります。カットオーバーが成功した後、一時的なインフラストラクチャの削除や、以前のティアからの不要なテナントデータ履歴の削除など、クリーンアップ活動が必要です。ただし、データを削除する前に、監査証跡が規制要件に準拠して保存されており、データ削除が組織のポリシーに沿っていることを確認してください。 まとめ ポータビリティはマルチテナント SaaS にとって重要な機能です。テナントはデータと構成情報をティア間で移行でき、上記のようにリファレンスアーキテクチャに組み込むことで移行を簡便に実施できます。主な考慮事項は、一貫したアイデンティティを維持すること、コンプライアンスを維持すること、ダウンタイムを減らすこと、プロセスを自動化することです。   Aman Lal Aman Lal は、SaaS の開発、コンテナ技術、プラットフォームエンジニアリングを専門とする AWS のクラウドアーキテクトです。イノベーションへの情熱を持ち、AWS のお客様の多様なニーズに合わせたクリエイティブなソリューションを考案することに秀でています。Aman は Amazon のエンジニアリングプラクティスを゙使って、お客様に対してスケーラブルなプロダクトの構築とクラウドインフラの最適化をリードし、ビジネス価値を生み出しています。 Varun Saxena Varun は、ソフトウェアエンジニアとビルダーとしての16年以上の経験を持つAWSのクラウドアーキテクトです。彼は、AI を含む最先端のテクノロジーを活用して、クラウドネイティブのアプリケーションを設計・構築することに特化しています。これにより、世界中のフォーチュン企業のデジタルトランスフォーメーションと事業の成功を推進しています。より迅速かつ効率的なソリューションを提供することに専念している Varun は、テクノロジーを活用して複雑なビジネス上の課題を解決し、全体的な効率性と収益性を高めるために、クライアントが望む成果を達成するのを支援しています。彼は、正しいものを構築し、かつ正しく構築することの確固たる支持者です。 翻訳はソリューションアーキテクト 中山 七美 が担当しました。原文は こちら です。

この記事は、Deltek の Kevin Plexico と Shakun Vohra が共同で執筆した How Deltek uses Amazon Bedrock for question and answering on government solicitation documents を翻訳したものです。翻訳は Solutions Architect の宮口直樹が担当しました。 文書を使用した質疑応答 (Q&A) は、カスタマーサポートチャット、法律調査アシスタント、ヘルスケアアドバイザーなど、さまざまなユースケースで一般的に使用されるアプリケーションです。 Retrieval Augmented Generation (RAG) は、大規模言語モデル（LLM）の力を活用して自然言語で文書とやり取りするための主要な方法として登場しました。 このブログ記事では、 AWS Generative AI Innovation Center (GenAIIC) が Deltek 向けに開発したカスタムソリューションの概要を紹介します。 Deltek は政府契約およびプロフェッショナルサービスの両分野におけるプロジェクトベースのビジネスで世界的な標準として認められた企業です。Deltek は 30,000 を超えるクライアントに業界特化型のソフトウェアと情報ソリューションを提供しています。 この共同プロジェクトでは、AWS GenAIIC チームは Deltek 向けに、単一および複数の政府調達文書に対する Q&A を可能にする RAG ベースのソリューション作成しました。このソリューションでは、 Amazon Textract 、 Amazon OpenSearch Service 、 Amazon Bedrock などの AWS サービスを利用しています。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要な AI 企業から、高性能な基盤モデル (FM) と LLM を単一の API で選択して利用できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための機能を提供します。 Deltek は、PDF 以外のファイル形式のサポートやデータ取り込みパイプラインのよりコスト効率の高いアプローチの実装など、特定の要件により適合させるために、このソリューションの強化に継続的に取り組んでいます。 RAG とは何か？ RAG は、LLM が応答を生成する前に、学習データソース以外の信頼できる知識ベースを参照できるようにすることで、LLM の出力を最適化するプロセスです。このアプローチは、誤った情報、古い情報、一般的すぎる情報を提示したり、用語の混同により不正確な応答を生成したりするなど、LLM に関連する課題を対処します。RAG により、LLM は組織内部のナレッジや特定の分野を参照することで、モデルを再学習する必要なく、より関連性が高く、正確で、コンテキストに即した応答を生成できます。これによって組織は生成されるテキスト出力をより制御できるようになり、ユーザーは LLM がどのように応答を生成したかについての洞察を得ることができます。RAG はさまざまな状況で LLM の性能を改善するための費用対効果の高いアプローチとなります。 主な課題 単一の文書に対して Q&A で RAG を適用するのは簡単ですが、複数の関連文書に同じことを適用するには、いくつかの特殊な課題が生じます。例えば、時間の経過とともに変化する文書に対して Q&A を行う場合、質問が時間とともに変化する概念に関するものであれば、文書の時系列順序を考慮することが必要です。順序を考慮しないと、過去のある時点では正確だったが、時系列に沿って整理された文書群の中のより最新の情報に基づくと、現在では古くなっている回答を提供してしまう可能性があります。時間的側面を適切に扱うことは、単一の文書から、時間の経過とともに変化する相互にリンクした文書群への質問応答を拡張する際の重要な課題です。 ソリューションの概要 ユースケースの例として、時系列の関係にある 2 つの文書に対する Q&A について説明します。1 つは長い提案依頼書（RFP）の草案文書、もう 1 つは関連する後続の情報提供依頼書（RFI）への政府の回答で、追加および改訂された情報が提供されています。 このソリューションは、2 つのステップで RAG アプローチを展開しています。 最初のステップはデータ取り込みで、以下の図に示す通りです。これには、PDF 文書の一回限りの処理が含まれます。ここでのアプリケーションコンポーネントは、テキストの分割やバックグラウンドでのサービス呼び出しなどの簡単な処理を行うユーザーインターフェイスです。手順は以下の通りです。 ユーザーが文書をアプリケーションにアップロードします。 アプリケーションは Amazon Textract を使用して、入力文書からテキストと表を取得します。 テキスト埋め込みモデルがテキストチャンクを処理し、各テキストチャンクの埋め込みベクトルを生成します。 テキストチャンクの埋め込み表現と関連するメタデータが OpenSearch Service にインデックス化されます。 2 番目のステップは以下の図に示す通り Q&A です。このステップでは、ユーザーが取り込まれた文書に関する質問をし、自然言語での回答を期待します。ここでのアプリケーションコンポーネントは、バックグラウンドで別のサービスを呼び出すなどの簡単な処理を行うユーザーインターフェースです。手順は以下の通りです。 ユーザーが文書に関する質問をします。 アプリケーションは、入力された質問の 埋め込みベクトル を取得します。 アプリケーションは、OpenSearch Service から取得したデータと質問を Amazon Bedrock に渡して、回答を生成します。モデルはセマンティック検索を実行し、文書から関連するテキストチャンク（コンテキスト）を見つけ出します。埋め込みベクトルは、質問をテキストから数値表現の空間にマッピングします。 質問とコンテキストが組み合わされ、LLM へのプロンプトとして入力されます。言語モデルは、ユーザーの質問に対する自然言語の回答を生成します。 我々のソリューションでは、PDF、PNG、JPEG、TIFF をテキストデータに変換できる Amazon Textract を使用しました。また、表などの複雑なレイアウトも分析しやすい形式に整形します。次のセクションでは、Amazon Textract の機能を示す例を紹介します。 OpenSearch は、Elasticsearch から派生したオープンソースの分散検索および分析スイートです。大量のデータを効率的に保存し、クエリを実行するためにベクトルデータベース構造を使用しています。OpenSearch Service には現在、数万のアクティブユーザーがいて、数十万のクラスターを管理し、月間数百兆のリクエストを処理しています。私たちは OpenSearch Service とその基盤となるベクトルデータベースを使用して、以下のことを行いました。 文書をベクトル空間にインデックス化し、関連項目を近接して配置することで関連性を向上させる Q&A のステップで、ベクトル間の近似最近傍探索を使用して、関連する文書チャンクを迅速に取得する OpenSearch Service 内のベクトルデータベースにより、関連データチャンクを効率的に保存し、迅速に取得することができ、これが質問応答システムの基盤となりました。文書をベクトルとしてモデル化することで、明示的なキーワード一致がなくても関連する段落を見つけられるようになりました。 テキスト埋め込みモデルは、テキストからの単語やフレーズを密なベクトル表現にマッピングする機械学習 (ML) モデルです。テキスト埋め込みは、RAG のような情報検索システムで以下の目的でよく使用されます。 ドキュメント埋め込み – 埋め込みモデルを使用して、文書の内容をエンコードし、埋め込み空間にマッピングします。通常、文書を段落、セクション、または固定サイズのチャンクなどの小さな単位に分割することが一般的です。 クエリ埋め込み – ユーザーのクエリをベクトルに埋め込みし、セマンティック検索を実行して文書チャンクと照合できるようにします。 この記事では、最大 8,000 トークンを受け取り、1,536 次元の数値ベクトルを出力するモデルである Amazon Titan Embeddings G1 – Text v1.2 を使用しました。このモデルは Amazon Bedrock 経由で利用可能なモデルです。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの有力な AI 企業から、すぐに使用できる基盤モデルを提供しています。プライバシーとセキュリティを維持しながら、これらのモデルにアクセスし、生成AIアプリケーションを構築するための単一のインターフェースを提供します。我々は、Amazon Bedrock の Anthropic Claude v2 を使用して、質問とコンテキストに基づいた自然言語の回答を生成しました。 以下のセクションでは、このソリューションの 2 つのステップをより詳しく見ていきます。 データ取り込み まず、RFP および RFI の回答文書の下書きが、Q&A の時に使用できるように処理されます。データ取り込みには、以下のステップが含まれます。 文書は Amazon Textract に渡され、テキストに変換されます。 言語モデルが表に関する質問に適切に答えられるようにするため、Amazon Textract の出力から表を CSV 形式に変換するパーサーを作成しました。表を CSV に変換することで、モデルの理解力が向上します。たとえば、以下の図は PDF 形式の RFI 回答書の一部と、対応する抽出されたテキストを示しています。抽出されたテキストでは、表が CSV 形式に変換され、他のテキストの中に配置されています。 長い文書の場合、抽出されたテキストが LLM の入力サイズ制限を超える可能性があります。そのような場合、テキストを小さなオーバーラップ部分を含む複数のチャンクに分割できます。チャンクのサイズとオーバーラップの割合は、ユースケースによって異なる場合があります。セクション単位のチャンク分割（各文書セクションごとに独立してチャンク分割を行う）を適用しており、後述のユースケースにて説明します。 一部の文書クラスは、標準的なレイアウトや形式に従っている場合があります。例えば、RFP には、定義されたセクションを含む特定のレイアウトがあることが多いです。このレイアウトを使用すれば、各文書セクションを独立して処理できます。また、目次が存在しても関連性がない場合は、削除される可能性があります。このブログ記事の後半で、文書構造の検出と利用のデモンストレーションを行います。 各テキストチャンクの埋め込みベクトルは、埋め込みモデルから取得されます。 最後のステップで、埋め込みベクトルが OpenSearch Service データベースにインデックス化されます。埋め込みベクトルに加えて、文書名、文書セクション名、公開日などのメタデータも、テキストフィールドとしてインデックスに追加されます。文書が時系列的に関連している場合、公開日は有用なメタデータで、LLM が最新の情報を特定できるようになります。次のコードスニペットは、インデックスの中身を示しています。 index_body = { "embedding_vector": <embedding vector of a text chunk>, "text_chunk": <text chunk>, "document_name": <name>, "section_name": <section name>, "release_date": <release date>, # 更なるメタデータを追加できます } Q&A Q&A フェーズでは、ユーザーは前のステップで取り込まれた RFP および RFI について自然言語で質問ができます。まず、セマンティック検索を実行し、ユーザーの質問に関連するテキストチャンクを取得します。次に、取得したコンテキストを使って質問を拡張してプロンプトを作成します。最後に、プロンプトを Amazon Bedrock に送信し、LLM が自然言語の回答を生成します。詳細な手順は以下の通りです。 入力された質問の埋め込みベクトルが、Amazon Bedrock の Amazon Titan 埋め込みモデルから取得されます。 質問の埋め込みベクトルを使用して、OpenSearch Service でセマンティック検索を実行し、関連性の高い上位 K 個のテキストチャンクを見つけます。以下は、OpenSearch Service に渡される検索クエリ本文の例です。検索クエリの構造化の詳細については、 OpenSearch のドキュメント を参照してください。 search_body = { "size": top_K, "query": { "script_score": { "query": { "match_all": {}, # skip full text search }, "script": { "lang": "knn", "source": "knn_score", "params": { "field": "embedding-vector", "query_value": question_embedding, "space_type": "cosinesimil" } } } } } 取得したメタデータ (セクション名や文書のリリース日付など) は、テキストのコンテキストを補強し、以下のように大規模な言語モデル (LLM) にさらに情報を提供するために使用されます。 def opensearch_result_to_context(os_res: dict) -> str: """ Convert OpenSearch result to context Args: os_res (dict): Amazon OpenSearch results Returns: context (str): Context to be included in LLM's prompt """ data = os_res["hits"]["hits"] context = [] for item in data: text = item["_source"]["text_chunk"] doc_name = item["_source"]["document_name"] section_name = item["_source"]["section_name"] release_date = item["_source"]["release_date"] context.append( f"<<Context>>: [Document name: {doc_name}, Section name: {section_name}, Release date: {release_date}] {text}" ) context = "\n \n ------ \n \n".join(context) return context 入力された質問は取得したコンテキストと組み合わされてプロンプトが作成されます。質問の複雑さや特殊性によっては、大規模な言語モデル (LLM) にさらなる説明とガイダンスを提供するために、初期プロンプトに追加で Chain-of-Thought (CoT) プロンプトを追加する必要があるかもしれません。CoT プロンプトは、質問を適切に理解し、回答を作成するために必要な論理的な推論と思考のプロセスを LLM に示すように設計されています。これは、LLM が質問に含まれる重要な情報を理解し、どのような回答が必要かを判断し、適切かつ正確な回答を構築するために従うべき一種の内部モノローグまたは認知的経路を示しています。本ユースケースでは、以下の CoT プロンプトを使用しています。 """ Context below includes a few paragraphs from draft RFP and RFI response documents: Context: {context} Question: {question} Think step by step: 1- Find all the paragraphs in the context that are relevant to the question. 2- Sort the paragraphs by release date. 3- Use the paragraphs to answer the question. Note: Pay attention to the updated information based on the release dates. """ プロンプトは、Amazon Bedrock の LLM に渡され、自然言語で回答が生成されます。Amazon Bedrock の Anthropic Claude V2 モデルでは、以下のような推論パラメータを使用しています。再現性を確保し、LLM のハルシネーションを防ぐために、Temperature パラメータは通常 0 に設定されます。一般的な RAG アプリケーションでは、 top_k と top_p はそれぞれ 250 と 1 に設定されます。 max_tokens_to_sample は、生成が期待される最大トークン数に設定します（英語の場合、1 トークンは約 3/4 語に相当します）。詳細については、 推論パラメータ を参照してください。 { "temperature": 0, "top_k": 250, "top_p": 1, "max_tokens_to_sample": 300, "stop_sequences": ["\n\nHuman:\n\n"] } 使用例 デモとして、関連する 2 つの文書に対する Q&A の例を説明します。1 つは 167 ページの PDF 形式の RFP 草案 、もう 1 つは後に公開された 6 ページの PDF 形式の RFI 回答書 で、RFP 案に対する追加情報と更新内容が含まれています。 以下は RFP 草案と RFI 回答書に基づいて、プロジェクトの規模要件が変更されたかどうかを尋ねる質問例です。 “Have the original scoring evaluations changed? if yes, what are the new project sizes?” 次の図は、回答が含まれている RFP 草案の関連セクションを示しています。 以下の図は、回答が含まれている RFI 回答書の関連セクションを示しています。 LLM が正しい応答を生成するためには、OpenSearch Service から取得したコンテキストに、前の図に示した表が含まれている必要があります。また、LLM は公開日などのメタデータからコンテンツの順序を整理し、自然言語で読みやすい回答を生成できる必要があります。 データ取り込みのステップは以下の通りです。 RFP 草案および RFI 回答書は、Amazon Textract にアップロードされ、テキストと表がコンテンツとして抽出されます。さらに、正規表現を使用して文書のセクションと目次を特定しました (それぞれ以下の図を参照)。このユースケースでは、目次に関連する情報がないため、削除できます。 各文書のセクションを独立して、オーバーラップを含む小さなチャンクに分割しました。本ユースケースでは、チャンクサイズを 500 トークン、オーバーラップを 100 トークンとしました（英語の場合、1 トークンは約 3/4 語に相当します）。 BPE トークナイザ を使用しており、各トークンは約 4 バイトに相当します。 Amazon Bedrock の Amazon Titan Embeddings G1 – Text v1.2 モデルを使用して、各テキストチャンクの埋め込みベクトルを取得します。 各テキストチャンクは、セクション名や文書公開日などのメタデータとともに、OpenSearch Service インデックスに格納します。 Q&A の手順は以下の通りです。 入力された質問は、まず埋め込みモデルを使って数値ベクトルに変換されます。このベクトル表現は、次のステップでのセマンティック検索と関連コンテキストの取得に使用されます。 上位 K 件の関連テキストチャンクとメタデータが OpenSearch Service から取得されます。 opensearch_result_to_context 関数と事前定義されたプロンプトテンプレートを使用して、入力の質問と取得したコンテキストに基づいてプロンプトが作成されます。 プロンプトは Amazon Bedrock 上の LLM に送信され、自然言語での回答が生成されます。以下は、Anthropic Claude v2 によって生成された応答で、 RFP 草案および RFI 回答書に示された情報と一致しています。質問は “Have the original scoring evaluations changed? If yes, what are the new project sizes?” でした。CoT プロンプトを使用することで、モデルは質問に正確に答えることができます。 主な機能 このソリューションは主に以下の機能を持ちます。 セクション単位のチャンク分割 – 文書のセクションを識別し、各セクションを独立して小さなチャンクに分割し、一部オーバーラップさせることでデータ取り込みを最適化します。 表から CSV への変換 – Amazon Textract で抽出された表を CSV 形式に変換し、言語モデルが表を理解し質問に答える能力を向上させます。 インデックスへのメタデータ追加 – セクション名や文書の公開日などのメタデータをテキストチャンクと共に OpenSearch Service インデックスに格納します。これにより、言語モデルが最新または関連性の高い情報を特定できるようになります。 CoT プロンプト – chain-of-thought プロンプトを設計し、質問を適切に理解し正確な回答を作成するために必要な論理的ステップについて、言語モデルにさらなる明確化とガイダンスを提供します。 これらの機能により、文書に関する質問への回答におけるソリューションの精度と能力が向上しました。実際、Deltek の専門家による LLM 生成レスポンスの評価では、このソリューションは全体で 96% の精度を達成しました。 結論 このブログ記事では、複数の政府調達文書に対する質問回答のための生成 AI アプリケーションについて概説しました。この記事で触れたソリューションは、AWS GenAIIC チームが Deltek と協力して開発したパイプラインを簡略化したものであり、時系列で個別に公開される長大な文書に対する Q&A を可能にするアプローチを説明しました。Amazon Bedrock と OpenSearch Service を使用することで、この RAG アーキテクチャはエンタープライズレベルの文書量に対応できます。さらに、CoT ロジックを使用してプロンプトテンプレートを紹介し、LLM がユーザーの質問に対して正確な応答を生成するのを支援しました。このブログ記事では、複雑な提案文書とその改訂版のレビューを合理化するための実世界の 生成 AI ソリューションの概要を提供することを目的としました。 Deltek はこのソリューションを固有のニーズに合わせて積極的に改良し最適化しています。この改良には、PDF 以外のファイル形式のサポート拡大や、データ取り込みパイプラインのためのコスト効率が良い手法の採用が含まれます。 プロンプトエンジニアリング と 生成 AI を活用した Q&A の詳細は、 Amazon Bedrock ハンズオン をご覧ください。技術サポートまたは AWS 生成 AI 専門家に連絡するには、 GenAIIC ウェブページ をご覧ください。 リソース Amazon Bedrock の詳細は、以下のリソースを参照してください。 Amazon Bedrock ワークショップ Amazon Bedrock ユーザーガイド OpenSearch Service の詳細は、以下のリソースを参照してください。 Amazon OpenSearch Service ドキュメント Amazon OpenSearch ワークショップ AWS の RAG リソースについては、以下のリンクを参照してください。 RAG (検索拡張生成) Amazon Bedrock のナレッジベース 著者について Kevin Plexico は、Deltek の情報ソリューション部の Senior Vice President で、政府請負業者および AEC 業界の顧客に対する調査、分析、仕様書作成を監督しています。 彼は 5,000 を超える顧客に不可欠な政府市場の情報を提供する GovWin IQ の提供を主導し、業界最大の規模の分析チームを管理しています。 Kevin はまた、Deltek の Specification Solutions 製品を統括しており、MasterSpec ®、SpecText などの建設仕様書コンテンツを作成しています。 Shakun Vohra は、20 年以上のソフトウェアエンジニアリング、AI/ML、ビジネスプロセスの改革、データ活用の専門知識を持つ傑出した技術リーダーです。 Deltek では、複数の大陸にまたがる多様な高パフォーマンスチームを率いて大きな成長を遂げました。 Shakun は、技術戦略と企業の目標を合わせ、経営陣と協力して組織の方向性を形作ることに長けています。 戦略的なビジョンとメンターシップで知られ、次世代のリーダーと変革的な技術ソリューションの育成に一貫して尽力してきました。 Amin Tajgardoon は、AWS Generative AI Innovation Center の Applied Scientist です。 コンピューターサイエンスと機械学習に関する幅広い経験を持っています。 特に Amin 氏は、ディープラーニングと予測、予測の説明手法、モデルドリフト検出、確率的生成モデル、そして医療分野における AI の応用に注力してきました。 Anila Joshi は、10 年以上にわたり AI ソリューションの構築に携わってきました。 AWS Generative AI Innovation Center の Applied Science Manager として、可能性の限界を押し広げる AI の革新的な応用を先導し、顧客が安全なジェネレーティブ AI ソリューションを構想、特定、実装するのを支援することで、顧客による AWS サービスの採用を加速させています。 Yash Shah と彼の率いるサイエンティスト、専門家、エンジニアのチームは、AWS Generative AI Innovation Center で、AWS の主要顧客と協力し、Generative AI の可能性を最大限に引き出し、ビジネス価値を生み出すことに取り組んでいます。 Yash は 7 年半以上 Amazon に在籍し、複数の地理的地域にわたり、ヘルスケア、スポーツ、製造業、ソフトウェア業界の顧客と協働してきました。 Jordan Cook は、AWS 分野で 20 年近くの実績を持つ Sr. Account Manager で、セールスとデータセンター戦略を専門としています。Jordan は、Amazon Web Services に関する広範な知識と、クラウドコンピューティングに対する深い理解を活かし、企業がクラウドインフラストラクチャを最適化し、運用効率を高め、イノベーションを促進できるよう、カスタマイズされたソリューションを提供しています。

本ブログは 2024 年 9 月 4 日に公開されたBlog ” Build a mobile driver’s license solution based on ISO/IEC 18013-5 using AWS Private CA and AWS KMS ” を翻訳したものです。 モバイル運転免許証 (mDL) は、モバイルデバイスに保存される物理的な運転免許証のデジタル版です。物理的な身分証明書には、紛失、盗難、偽造、破損、または古い情報が含まれる可能性があり、同意なしに個人を特定できる情報 ( PII ) を露出させる可能性があります。mDL は、身分証明書に比べて大幅な改善がされます。さまざまな組織が連携して、飛行機搭乗時の本人確認から年齢確認が必要な活動での情報提供まで、さまざまな状況で mDL を使用できるように取り組んでいます。 mDL システムにおける信頼は、公開鍵暗号方式に基づいています。mDL は発行機関によって秘密鍵で署名され、発行機関 (issuing authority) の公開鍵を使用して検証されます。 このブログでは、mDL 仕様 ISO/IEC 18013-5:2021 に従って、 AWS Private Certificate Authority (AWS Private CA) と AWS Key Management Service (AWS KMS) を使用して、 Amazon Web Services (AWS) で mDL 発行機関を構築する方法を紹介します。これらの AWS サービスは、ISO/IEC 18013-5 が発行機関に課す暗号化要件に適合しています。本ブログは mDL のユースケースに合わせて調整されていますが、AWS Private CA と AWS KMS を使用した署名と検証のメカニズムは、多様なデジタルアイデンティティ検証にも参考にできます。 ソリューションの概要 AWS Private CA は、独自のプライベート認証局（CA）を運用するための初期投資や継続的なメンテナンスコストなしに、高可用性のプライベート CA サービスを提供します。CA 管理者は、AWS Private CA を使用して、外部の CA に依存せずに、オンラインのルート CA や下位 CA を含む完全な CA 階層構造を作成できます。AWS Private CA を使用することで、組織内で信頼される証明書の発行、更新、失効を行うことができます。 AWS Private CA は、 ISO/IEC 18013-5 で規定されたフォーマットの証明書 を発行できます。ISO/IEC 18013-5 で発行機関認証局 (IACA: issuing authority certificate authority) と呼ばれる認証局 (CA) をAWS Private CA で 構築できます。本ブログでは、AWS Private CA を使用して IACA の自己署名ルート証明書と mDL 文書署名用証明書を作成します。 AWS KMS は、データを保護するために使用される暗号化キーを作成および管理するためのマネージドサービスです。AWS KMS は、FIPS 140-2 レベル 3 認証済みのハードウェアセキュリティモジュール (HSM) を使用して AWS KMS キーを保護します。これは、ISO/IEC 18013-5 で説明されている発行機関を構築する際の要件です。mDL 文書の署名と検証のために、AWS KMS で非対称キーペアを作成します。AWS KMS に保存された非対称キーペアによって署名された証明書署名要求 (CSR) をプログラムで作成します。CSR は AWS Private CA サービスに送信され、ISO/IEC 18013-5 で指定された証明書の証明書プロファイル要件に適合する mDL 文書署名用証明書を発行します。 AWS KMS で作成された KeyUsage 値が SIGN_VERIFY の非対称キーペアの秘密鍵を使用して、mDL 文書に署名します。署名された mDL 文書はモバイルデバイスに送信され、デジタルウォレットに保存され、mDL リーダーによる検証のために提示で使用されます。mDL リーダーには、さまざまな発行機関からの IACA 証明書が設定されており、それぞれの発行機関によって署名された mDL 文書を検証できます。発行機関の一例としては、運転免許証を発行する米国州政府機関などが挙げられます。 最小権限 本ブログのソリューションでは、AWS KMS と AWS Private CA サービスを使用します。ブログで説明する手順を実行する前に、選択した AWS Identity and Access Management (IAM) プリンシパルが最小特権の原則に従っており、必要最小限の権限のみが付与されていることを確認してください。詳細については、 IAM のセキュリティベストプラクティス をご覧ください。 ソリューションアーキテクチャ AWS で mDL 発行機関を構築するためのサンプルソリューションアーキテクチャを図 1 に示します。この図は、プライベート CA のセットアップから mDL 文書署名用証明書の発行、mDL の発行と検証までの段階的なプロセスを示しています。このアーキテクチャを使用して構築されるインフラストラクチャには、文書署名用証明書を発行するルート証明機関が含まれます。証明書の要件は、ISO/IEC 18013-5 のセクション B.1 証明書プロファイルで確認できます。 図 1 : AWS における mDL 発行機関のアーキテクチャとプロセスフロー このブログでは、 AWS Command Line Interface (AWS CLI) コマンドを使用しますが、必要に応じて AWS SDK API 呼び出しに置き換えることができます。AWS CLI の手順と併せて、AWS KMS を使用して mDL 文書署名用の CSR をプログラムで作成し署名するための GitHub サンプル も提供されています。 このソリューションで使用されているコマンドの詳細については、 AWS Private CA と AWS KMS の AWS CLI コマンドドキュメントをご覧ください。 ソリューションの詳細 mDL の署名と検証に必要なインフラストラクチャを作成する手順です。 ステップ 1: AWS Private CA での IACA CA の作成 このステップでは、信頼の起点となる IACA (発行機関 CA) を作成します。IACA ルート CA は、mDL の検証に使用される信頼の基点です。 以下の内容で、ローカルに ca_config.txt ファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルのセクション（付録 B ）から派生しています。必要に応じて、ファイル内の Country と CommonName の値を変更できます。 { "KeyAlgorithm": "EC_prime256v1", "SigningAlgorithm": "SHA256WITHECDSA", "Subject": { "Country": "US", "CommonName": "mDL IACA Root" } } IACA ルート証明書は、証明書失効リスト（ CRL ）とペアになります。CRL の設定に関する情報は、 証明書失効リスト（ CRL ）の設計 を参照してください。CRL を設定するために、以下の情報を含む revocation_config.txt というローカルファイルを作成します。 CustomCname と S3BucketName の値は例示です。AWS アカウント内で作成した値に更新してください。 ExpirationInDays は要件に合わせて更新してください。CRL を含む Amazon Simple Storage Service （ Amazon S3 ） バケットに暗号化を設定することをお勧めします。 { "CrlConfiguration": { "CustomCname": "example.com", "Enabled": true, "S3BucketName": "crlmdlbucket", "ExpirationInDays": 5000 } } AWS CLI コマンドを呼び出して、 プライベート認証局（ CA ）を作成 します。必要に応じて region パラメータを置き換えてください。以下のコマンドの file:// パスを、 ca_config.txt と revocation_config.txt ファイルを保存した場所に更新してください。 aws acm-pca create-certificate-authority \ --region us-west-1 \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revocation_config.txt \ --certificate-authority-type "ROOT" コマンドは以下の出力を生成するはずです。出力には作成された CA の Amazon リソースネーム (ARN) が含まれています。この ARN は後続のステップで必要になります。 { "CertificateAuthorityArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113" } ステップ 2: IACA ルート証明書の CSR の取得 IACA ルート証明書を作成します。この作成プロセスは CSR の取得から始まります。この手順で IACA ルート証明書の CSR を取得します。 certificate-authority-arn パラメータには、ステップ 1 で生成された CA ARN が含まれています。 次のコマンドは、 Privacy-Enhanced Mail （ PEM ）形式 の CSR を出力します。 aws acm-pca get-certificate-authority-csr \ --region us-west-1 \ --output text \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 出力される CSR の形式は以下の通りです： -----BEGIN CERTIFICATE REQUEST----- .. -----END CERTIFICATE REQUEST----- 出力されたテキストを IACA.csr というファイル名で保存してください。 ステップ 3: ルート証明書の生成 このステップでは、IACA ルート証明書を発行します。ISO/IEC 18013-5 の証明書プロファイルセクションから参照された以下の内容を使用して、 extensions.txt という名前のファイルを作成します。 KeyUsage 拡張機能の KeyCertSign と CRLSign を true に設定する必要があります。CRL 配布ポイントのカスタム拡張機能が設定され、証明書の有効期間は 9 年または 3285 日（次のステップで設定）に設定する必要があります。IACA ルート証明書は mDL の発行にのみ使用されるため、ISO/IEC 18013-5 の表 B.1 に示されているように、最大有効期間を 9 年とすれば十分です。さらに、CRL ディストリビューションポイント拡張機能が存在する必要があります。以下の例では、CDP 拡張機能でエンコードされた CRL URL は http://example.com/crl/0116z123-dv7a-59b1-x7be-1231v72571136.crl で、CA 作成時に適用された CA CRL 設定および CA ID の両方に合致しています。CDP 拡張機能の Base 64 エンコーディングについては、この Java サンプル を参照してください。 { "Extensions": { "KeyUsage": { "KeyCertSign": true, "CRLSign": true }, "CustomExtensions": [ { "ObjectIdentifier": "2.5.29.31", "Value": "MEgwRqBEoEKGQGh0dHA6Ly9leGFtcGxlLmNvbS9jcmwvMDExNnoxMjMtZHY3YS01OWIxLXg3YmUtMTIzMXY3MjU3MTEzNi5jcmw=" } ] } } 以下のコマンドを AWS Private CA に対して実行して、証明書を作成します。 aws acm-pca issue-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --template-arn "arn:aws:acm-pca:::template/BlankRootCACertificate_PathLen0_APIPassthrough/V1" \ --signing-algorithm "SHA256WITHECDSA" \ --csr fileb://IACA.csr \ --validity Value=3285,Type="DAYS" \ --api-passthrough file://extensions.txt このコマンドは、以下の出力を生成します： { "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318" } AWS Private CA で作成された IACA ルート CA には、デフォルトで CRL 配布ポイント (CDP) 拡張が含まれていないことに注意してください。しかし、これは ISO/IEC 18013-5 の IACA ルート証明書プロファイルによると必須の拡張機能です。これを実装するために、CDP 拡張を埋め込むカスタム拡張を API パススルー を使用して渡します。この拡張機能で指定される配布ポイントは、ステップ 1 で作成された CA ARN に含まれる CA ID である 0116z123-dv7a-59b1-x7be-1231v7257113 を使用して指定する必要があります。 ステップ 4: ルート証明書の取得 このステップでは、PEM 形式の IACA ルート証明書を取得します。 以下のコードを使用して IACA ルート証明書を取得します： aws acm-pca get-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318 \ --output text コマンドの出力は、以下のような PEM 形式の証明書となります： -----BEGIN CERTIFICATE----- .. -----END CERTIFICATE----- この出力されたテキストを IACA-Root-CA-Cert.pem という名前のファイルに保存します。 ステップ 5: ルート証明書のインポート 以下のコードを使用して、ルート証明書を AWS Private CA にインポートし、認証局をアクティブにして証明書を発行できる状態にします。 aws acm-pca import-certificate-authority-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate fileb://IACA-Root-CA-Cert.pem コマンドを実行すると、 success が表示されるはずです。 ステップ 6: AWS KMS での非対称キーの作成 この手順では、AWS KMS で非対称署名キーを作成します。このキーは、モバイル運転免許証（ mDL ）の文書に対する証明書署名要求（ CSR ）の署名に使用されます。 以下のコマンドを使用して非対称キーを作成します： aws kms create-key \ --region us-west-1 \ --key-spec ECC_NIST_P256 \ --key-usage SIGN_VERIFY コマンドを実行すると、以下のような出力が得られます： { "KeyMetadata": { "AWSAccountId": "123412345678", "KeyId": "3ab87971-1fe2-45d9-955a-5dc7f65558zf", "Arn": "arn:aws:kms:us-west-1:123412345678:key/3ab87971-1fe2-45d8-955c-5dc7f65558ef", "CreationDate": "2024-05-18T19:53:27.318000 + 00:00", "Enabled": true, "Description": "", "KeyUsage": "SIGN_VERIFY", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "ECC_NIST_P256", "KeySpec": "ECC_NIST_P256", "SigningAlgorithms": [ "ECDSA_SHA_256" ], "MultiRegion": false } } 出力から Arn の値をメモしてください。ステップ 7 で、mDL 文書署名用証明書の CSR 作成ユーティリティを構成する際に使用します。 ステップ 7: CSR 作成ユーティリティを使用した文書署名用証明書の CSR の生成 AWS の非対称キーで署名された CSR を作成するサンプルユーティリティを GitHub で公開しました。 GitHub リポジトリ をクローンし、リポジトリの README ファイルの指示に従って設定し、実行します。 このプログラムは、以下のような PEM 形式の CSR を出力します。 -----BEGIN CERTIFICATE REQUEST----- .. -----END CERTIFICATE REQUEST----- 出力をコピーし、 document-signing-kms.csr という名前のファイルに保存します。手順 8 で、この CSR に基づいて mDL 文書用の署名証明書を作成する際にこのファイルを使用します。 ステップ 8: mDL 文書署名用証明書の生成 このステップでは、AWS KMS の非対称キーを使用して署名された CSR から、 文書署名用証明書を発行します 。 以下の内容で extensionSigner.txt というファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルの節から派生しています。以下の JSON スニペットは、 DigitalSignature フィールドが true に設定された KeyUsage 拡張を含む拡張機能の構造を示しています。 { "Extensions": { "KeyUsage": { "DigitalSignature": true }, "ExtendedKeyUsage": [ { "ExtendedKeyUsageObjectIdentifier": "1.0.18013.5.1.2" } ] } } 以下の AWS CLI コマンドを使用して証明書を作成します。 aws acm-pca issue-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --template-arn "arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1" \ --signing-algorithm "SHA256WITHECDSA" \ --csr fileb://document-signing-kms.csr \ --validity Value=1825,Type="DAYS" \ --api-passthrough file://extensionSigner.txt 出力： { "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba" } 出力から CertificateArn を使用して、モバイル運転免許証（ mDL ）文書署名用証明書を取得します。 ステップ 9: mDL 文書署名用証明書の取得 このステップでは、AWS Private CA から PEM 形式の文書署名用証明書を取得します。 次のコマンドで文書署名用証明書を取得します： aws acm-pca get-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba \ --output text コマンドの出力を document_signing_cert.pem に保存します。 ISO/IEC 18013-5 で要求される Concise Binary Object Representation (CBOR) を用いて後ほどパッケージ化するために利用する mDL 文書署名用証明書を得ることができました。 ステップ 10: mDL リーダーによる発行機関の mDL 署名証明書チェーンの取り込み mDL リーダーは、ユーザーが提示した mDL を暗号学的に検証した後、その mDL を信頼することができます。この検証には、リーダーがユーザーに mDL を発行した発行機関の mDL 署名証明書チェーンを保持している必要があります。ISO/IEC 18013-5 で規定されている分散型公開鍵基盤 (PKI) 信頼モデルで要求されているように、mDL リーダーは発行機関の mDL 署名証明書チェーンを取得する必要があります。 ステップ 11: ユーザーによる発行機関への mDL 署名リクエスト ユーザーは発行機関に mDL への署名を要求します。 ステップ 12: 発行機関によるユーザーへの署名済み mDL の発行 発行機関はユーザーの身元を認証し、署名された mDL を発行します。発行機関は、モバイルセキュリティオブジェクト (MSO) として知られる CBOR エンコードされたオブジェクトとともに、mDL データをユーザーのデバイスに提供します。MSO には、ダイジェストアルゴリズム、個々の mDL データ要素のダイジェスト、および有効期間が含まれています。この MSO が ISO/IEC 18013-5:2021 のセクション 9.1.2.4 で要求されるように生成およびエンコードされた後、発行機関によって MSO に署名することができます。この署名は、以下のコマンドに示すように AWS KMS で生成できます。エンコードされた MSO の生成については、このブログでは扱いません。 sha256sum ユーティリティを使用して、エンコードされた MSO オブジェクトの SHA-256 ダイジェストを生成するには、次のコマンドを使用します。 sha256sum < EncodedMSO > EncodedMSODigest ステップ 6 で作成した AWS KMS の非対称キーを使用してダイジェストに署名します。 aws kms sign \ --region us-west-1 \ --key-id 3ab87971-1fe2-45d8-955c-5dc7f65558ef \ --message fileb://EncodedMSODigest \ --message-type DIGEST \ --signing-algorithm ECDSA_SHA_256 \ --output text \ --query Signature | base64 --decode この署名は、発行機関の証明書と MSO と組み合わされて、 CBOR Object Signing and Encryption (COSE) の署名付きメッセージを形成し、mDL データ要素とともにリーダーに提示されます。リーダーはこの署名を検証して、MSO の完全性を確認できます。 ステップ 13: ユーザーによる mDL リーダーへの mDL の提示 ユーザーは、空港などで本人確認のために mDL を mDL リーダーに提示します。このプロセスは、ISO/IEC 18013-5:2021 の 6.3.2.2 項で mDL 初期化と呼ばれています。mDL は、この初期化ステップでアクティブ化されます。 ステップ 14: mDL リーダーによるユーザーのモバイルデバイスからの mDL データのリクエスト mDL リーダーは、ユーザーのモバイルデバイスに mDL 取得リクエストを発行します。mDL の重要な特徴は、mDL 所有者が個人識別情報（ PII ）の一部を提示できることです。mDL リーダーは、氏名や生年月日などの特定の属性を要求し、mDL 所有者はこの情報の開示に同意する必要があります。mDL リーダーのリクエストには、mDL 所有者に共有を求める個人識別情報の項目リストが含まれています。 ステップ 15: ユーザーによる mDL データ共有の同意 ユーザーは、mDL 共有リクエストを通知するメッセージを受け取ります。このメッセージには、リクエストされている個人識別情報（ PII ）の項目リストが表示されます。ユーザーがリクエストに同意すると、MSO を含む mDL データがリーダーと共有されます。 ステップ 16: リーダーによる mDL の整合性の検証 リーダーは mDL データを受信し、その完全性を検証します。mDL データ要素に MSO を含めることで、mDL リーダーは受信したデータの完全性を検証するメカニズムを得られます。mDL リーダーは、デバイスから提示された個々の mDL データ要素をハッシュ化して検証できます。すべてのデータ要素が MSO の対応するエントリと一致する場合、mDL リーダーはデータが改ざんされていないことを確認できます。 例として、mDL に以下のデータ要素が含まれていると仮定します： 24(<< { "digestID": 0, "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1', "elementIdentifer": "given_name", "elementValue": "John" } >>), 24(<< { "digestID": 1, "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368', "elementIdentifer": "family_name", "elementValue": "Doe" } >>) さらに、データ要素のダイジェストを格納するモバイル セキュリティ オブジェクトはこちらです。 24(<< { "version": "1.0", "digestAlgorithm": "SHA-256", "valueDigests": { "org.iso.18013.5.1": { 0: h'D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E', 1: h'4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5' } } } >>) MSO の整合性チェックでは、まず MSO の有効期間 (図示されていません) が期限切れでないことを確認します。次に、発行機関の公開鍵を使用して署名 (図示されていません) を検証します。これらの確認が完了した後、各データ要素を検証する必要があります。各要素 ( digestID 、 random 、 elementIdentifier 、 elementValue ) の CBOR 表現はバイト列としてエンコードされ、SHA-256 を使用してハッシュ化されます。例えば、以下は D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E と等しくなるはずです。 SHA256(CBOR byte representation of 24(<< { "digestID": 0, "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1', "elementIdentifer": "given_name", "elementValue": "John" } >>)) ) 同様に、次の例は 4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5 と等しくなるはずです。 SHA256(CBOR byte representation of 24(<< { "digestID": 1, "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368', "elementIdentifer": "family_name", "elementValue": "Doe" } >>)) ) すべてのデータ要素がこのハッシュ検証チェックに合格すれば、mDL リーダーは提示された mDL の内容を信頼できるものとして扱うことができます。 まとめ このソリューションでご覧いただいたように、モバイル運転免許証 (mDL) は、個人のプライバシーを保護するために、セキュリティの向上と柔軟な同意管理を提供します。暗号化による署名と検証の原理は新しいものではなく、AWS KMS と AWS Private CA はどちらも、運転免許証やその他の種類の身分証明書など、デジタル ID アプリケーションのサポートに適しています。AWS KMS の非対称鍵と AWS Private CA の詳細については、 AWS KMS の非対称鍵機能を使用したデジタル署名 と AWS で完全なプライベート証明書インフラストラクチャをホストおよび管理する方法 をご覧ください。 本ブログに関するフィードバックがある場合は、以下のコメント欄にコメントを投稿してください。このブログに関する質問がある場合は、 AWS re:Post (AWS Certificate Manager) および AWS re:Post (AWS KMS) で新しいスレッドを立てるか、 AWS サポートにお問い合わせ ください。 Ram Ramani: Ram は AWS のプリンシパルセキュリティアーキテクトで、データ保護とプライバシーの重点分野をリードする責任を担っています。この役職以前は、様々な組織でソフトウェア開発者として応用数学と機械学習に焦点を当てて活動していました。 Raj Jain: Raj は Amazon FinTech 組織のシニアソフトウェアエンジニアで、AWS およびより広範な Amazon インフラストラクチャの基盤となるセキュリティとコンプライアンスサービスの開発を担当しています。Raj は Bell Labs Technical Journal に論文を発表し、IETF 標準の著者であり、AWS セキュリティブログを執筆し、12 件の特許を保有しています。 Kyle Schultheiss: Kyle は AWS Cryptography チームのシニアソフトウェアエンジニアです。2018 年の立ち上げ以来、AWS Private CA サービスに取り組んでいます。以前の役割では、Amazon Virtual Private Cloud、Amazon EC2、Amazon Route 53 などの他の AWS サービスにも貢献しました。 本ブログは Security Solutions Architect の 中島 章博が翻訳しました

VMware 仮想環境のモダナイゼーションに取り組む際には、信頼性が高くコスト効率の良いデータ保護が重要になります。一般にデータ保護ソリューションを評価する際には、ソフトウェア、ストレージ、運用にかかる複雑なコスト計算が必要でした。 AWS が提供する AWS Backup はそれらの課題を解決し、よりシンプルなデータ保護の選択肢を提供します。 AWS Backup は、ソフトウェアのライセンス費用を前払いする必要のない従量課金でポリシー型のマネージドサービスであり、データ保護にかかるコストをシンプル化します。 加えて、AWS Backup には VMware 仮想マシン（VM）を Amazon Elastic Compute Cloud （EC2） インスタンスとして直接リストアする機能も備えているため、ミッションクリティカルなデータ保護と同時に AWS へのシームレスな移行、将来的なクラウドネイティブ化にも役立ちます。 本記事では、オンプレミスまたはクラウドベースの VMware 仮想環境を運用している方々を主な対象に、AWS Backup の実利用コストを見積もるための有用なヒントを提供します。 AWS Backup 利用料金を理解する AWS Backup の基本となる利用料金は、下記のようにシンプルです。 「バックアップデータが消費するストレージ領域の量 (月平均 GB)」 × 「単価（$/GB）」 しかし、VMware VM を AWS Backup でバックアップする場合、「バックアップデータが消費するストレージ領域の量」は、対象 VM、データタイプ、フォーマットによって異なる場合があります。 例えば、とあるバックアップ対象 VM には 90 GB のディスク割り当てたものの、オペレーティングシステム（OS）は 10 GB のストレージ利用だけを認識しており、一方 VMware vSphere からは 20 GB の物理ストレージが実際に消費されているケースを想像してみましょう。考慮すべきパラメーターは複数ありそうです。 結論からお伝えすると、AWS Backup のバックアップデータが消費するストレージは、割り当てられたデータと削除されたデータの両方を含むディスク使用量に等しくなります。これは通常、VM の割り当てられたサイズよりも小さくなり、VM の OS レベルの使用量よりも大きくなります。また、AWS Backup サービスコンソールに表示されるバックアップサイズは「バックアップデータが消費するストレージ領域の量」を表していません。代わりに、VMware 仮想環境で割り当てられた (プロビジョニングされた) ディスクサイズを反映しています。 本記事では、AWS Backup を使用して VMware 仮想環境の VM をバックアップした際の 1 ヶ月間の利用料金から逆算することで、「バックアップデータが消費するストレージ領域」を確かめていきます。 VMware 仮想環境と AWS マネジメントコンソール の双方において ストレージ容量は GB として表記されますが、実際には GiB（ギビバイト）を示している ことに注意してください。AWS Backup もバックアップストレージ、リストア、データ転送の価格計算に GiB（ギビバイト）を単位として使用していることに注意してください。 参考までに、「1 GB = 1,000³ bytes」、「1 GiB = 1,024³ bytes」です。 前提条件 今回のテストは以下の条件で実施しています。 VMware 仮想環境について 次の表は、本テストで使用した VMware 仮想環境の構成をまとめています。 VMware vSphere バージョン 8.0 ホストサーバー Amazon EC2 i3.metal * 1 台 リージョン N.Virginia 備考 VMware 仮想環境として VMware Cloud on AWS を使用 作成する VM はすべてシンプロビジョニング バックアップ対象の Windows VM について 次の表は、AWS Backup を使用してイメージバックアップを取得した Windows VM の情報をまとめています。 OS Windows Server 2019 VM ハードウェアバージョン 19 割り当てディスク容量 (C ドライブのみ) 90 GiB VMware vSphere によって認識されたストレージ使用量 19.66 GiB 備考 対象 VM はシンプロビジョニングとして作成 C ドライブには約 10 GiB の追加ファイル（主に ISO ファイル）を保存 バックアップ中、対象 VM の電源はオフ 図 1 は、AWS Backup でバックアップする Windows VM が vSphere からどのように認識されているかを示しています。 　　　　　　　　　　　　　　　図 1. バックアップ対象の Windows VM 図 2 は、Windows OS レイヤでは割り当てディスクが 90 GiB であると認識していることを示しています。 96,630,589,440 bytes は約 90 GiB となります。 　　　　　　　　　　　　　　　図 2. Windows OS によって認識される割り当てられたディスクのサイズ AWS Backup について 次の表は、対象 Windows VM のイメージバックアップを初めて取得した際の AWS Backup の情報をまとめています。 バックアップ作成日 2023 年 11 月 18 日 バックアップ保持期間 2023 年 11 月 18 日 – 2024 年 1 月 20 日 ストレージ層 ウォーム (Warm) リージョン N.Virginia 備考 AWS Backup の利用コストは、対象 Windows VM の初回イメージバックアップのみを対象とする バックアップ保持期間中に増分バックアップ、追加バックアップ、またはコールドストレージへの移行は実施していない 図 3 は、AWS マネジメントコンソールから AWS Backup の取得バックアップ情報を示しています。 コンソール中ではストレージ容量は GB として表示されますが、実際には GiB（ギビバイト）を表しています。 　　　　　　　　　　　　　　　図 3. AWS マネジメントコンソールにおける AWS Backup の情報 以下は、 AWS CloudShell で AWS Command Line Interface (CLI) を実行して取得した詳細な値です。 　　　　　　　　　　　　　　　図 4：AWS CLI から取得した AWS Backup の詳細情報 図 4 では、「BackupSizeInBytes」は AWS Backup によって認識されているバックアップサイズを表しています。この情報によると AWS Backup によって認識されるバックアップサイズは 90 GiB となっています。 「96,636,764,160 bytes = 90 GiB」です。ただし、この値は AWS Backup でバックアップデータによって実際に消費されるストレージ容量を表していません。 実際に課金された AWS Backup 利用コスト 2023 年 12 月 1 日から 2023 年 12 月 31 日までの 1 ヶ月間（31 日間）の AWS Backup 利用料金は 0.95 ドルでした。これを 2023 年 12 月時点での N.Virginia AWS リージョン の AWS Backup ウォームストレージの単価 0.05 ドル /GiB で除算して、AWS Backup が課金したストレージ使用量を逆算します。計算結果は以下のようになります。図 5 でハイライトします。 AWS Backup が課金したストレージ使用量 0.95 （USD） ÷ 0.05 （USD/GiB） = 19.0 （GiB） 　　　　　　　　　　　　　　　図 5. 実際に課金された AWS Backup 利用料金 図 6 で示す通り、2023 年 11 月 18 日以前にはバックアップを実施していないため利用料金は発生していません。 　　　　　　　　　　　　　　　図 6. テスト以前の AWS Backup 利用料金 最後に、関連する値を以下の表にまとめます。 対象 VM に割り当てられたディスク容量（シンプロビジョニング） VMware vSphere が認識する使用済みストレージ容量 AWS CLI から取得したバックアップサイズ 課金された AWS Backup のストレージ消費量 90 GiB 19.66 GiB 90 GiB 19.0 GiB 上表のとおり、このテストケースにおいては AWS Backupによって保存および課金されたデータ量は VMware vSphereから確認できた実際のストレージ使用量とほぼ同じであることがわかります。 テストケースの確認結果 このテストケースが示すように、VMware VM のバックアップに対して AWS Backup が課金したデータ量は、対象 VM の論理的な割り当て容量（90 GiB）ではなく、VMware vSphere によって認識されるストレージ使用量（19.66 GiB）とほぼ同じサイズ（19.0 GiB）でした。実際の VMware VM が VMDK ファイルであることを考慮すると、AWS Backup が課金するストレージ消費量は VMware vSphere が認識する使用済みストレージ容量と同等になります。 AWS Backup は保存されたバックアップデータを圧縮あるいは重複排除しません。 これを念頭に入れると、AWS Backup が課金するストレージ消費量は、VMware vSphere が認識する使用済みストレージ容量にほぼ一致することが理解できます。 念のため Linux VM でも追加のテストを行いましたが、結果は同様でした。シンプロビジョニング構成の VMware 仮想環境では、AWS Backup で課金されるストレージ消費量は、対象 VM に割り当てられたディスク容量ではなく、実際の使用済みストレージに等しくなります。 まとめ 本記事では、VMware 仮想環境における AWS Backup の利用料金に影響を与える主要な要素である バックアップストレージについてガイドしました。AWS Backup 利用料金のコア部分を理解することで、AWS Backup の予算をより正確に見積もることができます。 実際のバックアップコストは個々の使用パターンや要件に依存します。データ量、データ変更率、バックアップ頻度、保持期間など複数の要因も最終的な利用料金に影響を与えます。それらを踏まえつつも、今回ご紹介したガイドを AWS Backup の利用コストを予測するための出発点としてご活用ください。 参考情報 AWS Backup の料金 AWS Backup の VMware サポート AWS Backup が Amazon EC2 への VMware ワークロードの復元をサポート開始 AWS Backup でバックアップした VMware 仮想マシンを Amazon EC2 としてリストアする AWS Backup と VMware Cloud on AWS を活用した VMware ワークロードのデータ保護シンプル化 著者について 武田 紘一 VMware ワークロードのスペシャリストソリューションアーキテクトです。AWS への入社以前は通信業界と製造業界でインフラエンジニアおよびプロジェクトリーダーとして、VMware ならびにクラウドサービス技術に関する専門知識を活かしてきました。2022 年からは VMware vExpert として VMware User Group （VMUG） にも参画しています。 原文は こちら です。

この投稿はネットアップ合同会社 瀧山 毅 氏、松田 紘典 氏にサイバーレジリエンスにおけるデータリストアの解説と AWS における実装ポイントについて寄稿いただいたものです。 同シリーズの第 1 回「 サイバーレジリエンスとはなにか？ 」、第 2 回「 Amazon FSx for NetApp ONTAP イミュータブルバックアップの利用でランサムウェア対策の強化 」も併せてご覧ください。 こちらは、サイバーレジリエンスブログシリーズの第 3 回です。今回まで組織にとって重要な資産「データ」の観点から、サイバーレジリエンスの基本を解説してきました。 シリーズの最終回となる今回は、「バックアップとリストアの重要性」と「ランサムウェア被害を想定したリストアシナリオ」についてご紹介します。 今取得しているバックアップ大丈夫ですか？ ランサムウェアの被害が年々拡大および複雑化する中、バックアップの取得はランサムウェア対策の手段の 1 つとして現在多くの人に認知されています。NetApp はデータを蓄積・保護するストレージを扱う企業としてバックアップの重要性を理解しているため、たびたび  ”今取得しているバックアップ大丈夫ですか？” とお客様に聞くことがあります。その中で ”うちは問題なく取得できているはず” 、”どこどこのバックアップソフトを使用しているので大丈夫” という風に回答いただくことがありました。 併せて取得したバックアップのリストア実績について尋ねると ”ファイルレベルではあるけど、大規模な形での復元はない” 、”バックアップ成功しているってログがあるから特に気にしていない” という回答も少なからず聞く機会がありました。このようなコメントをいただいた中、今取得しているバックアップが有事の際に本当に使えると胸を張って言える企業が何社いるのだろうかという疑問を感じることがあります。 実際に警察庁が広報資料としてまとめている ”令和５年におけるサイバー空間をめぐる脅威の情勢等について” にてランサムウェア被害企業・団体のバックアップ取得・活動状況がレポートされており、バックアップ取得の有無に関しては有効回答数 140 件中 ８ 件 (6%) が取得していない状況で、リストアに関しては 126 件中被害直前の水準まで復元できた企業・団体が 21 件 (17％) のみで 105 件 (83％) の企業・団体が被害直前の水準まで復元できなかったという結果になっています。 図 1: バックアップの取得・活用状況 *1 (*1) 警視庁Webサイト,“令和５年におけるサイバー空間をめぐる脅威の情勢等について”, https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf, (2024/08/20 閲覧) レポートのようにファイルが元の水準で復元できず、そのためシステムや業務を長期間停止せざるを得ない事態になった場合、後日多くの労力とお金を費やしてシステムの改善等する必要に迫られると推測されます。このようなことを避けるため一度バックアップに求められる要素について考えてみたいと思います。 バックアップに求められる要素って何だろうか？ よく情報セキュリティで聞かれる項目として機密性 (Confidentiality)、完全性 (Integrity)、可用性  (Availability) がありますが、バックアップをこの項目に当てはめてざっくりと考えると以下のような内容になると考えています。 機密性:バックアップデータの改ざん/削除防止がされていること 完全性:データを完全な状態に復元可能な状態であること 可用性:どこから／どこにでも復元可能な状態であること 上記の項目を考慮して具体的にランサムウェア対策としてのバックアップに必要な要素としては以下のようなことが挙げられると思います。 RPO を顧慮した細かいバックアップの取得（可用性） 3-2-1 ルールを考慮したバックアップ（可用性） バックアップデータの保護/改ざん防止対策（機密性） 業務可能な状態でのデータ復旧のためのプロセス策定（完全性） 可用性と機密性に関してはバックアップの方式や取得方法のため、バックアップ取得後の完全性を考慮したデータ復旧にフォーカスしたお話をしたいと思います。完全性を考慮したバックアップを実施するということは “バックアップ成功しました。はい、終わり。” ではなく、取得したバックアップデータが業務に耐えうる水準でリストアできるかを確認するまでを実施することが理想であり、ランサムウェア攻撃等の有事に備えた有効な復旧プロセスの確立も含めて考慮する必要があります。ただし確認のため策定した復旧プロセスを経てリストアテストを実施するということになると、システムの規模によりますがリストアのためのストレージの空き容量や既存システムへの影響度合いも考慮する必要があるため簡単且つ定期的に実施できないというのが現状となります。 前置きは長くなりましたが、実は Amazon FSx for NetApp ONTAP (以降 FSx for ONTAP と記載します) 環境ですと簡単に復旧プロセスを含めたリストアテストが実施できます。 ※もちろんオンプレミスの ONTAP も同様に可能です。 次に FSx for ONTAP 環境でどのようにして簡単にリストアテストが実行できるか理由を記載します。 なぜ Amazon FSx for NetApp ONTAP ではリストアが簡単なのか サービス利用者が FSx for ONTAP に保管したデータについて、NetApp ONTAP のファイルシステム内では、データの保存場所を示すポインタ情報とデータブロックに分けて管理しています。Snapshot 作成を実行すると、前回作成した Snapshot とポインタ情報を比較し、ポインタ情報の更新部分を Snapshot 差分量として扱うことで、データブロックを動かさず Snapshot を作成することができます。この動作はリストアを行う際にも利用しており、データブロックを動かさないためバックアップデータを高速にリストアやクローンすることが可能となっています。 一般的なリストアテストでは、Snapshot をテスト領域にリストアしファイルが復旧するか確認するかと思います。リストアテストしたいデータが例えば 100TB 存在する場合、どのような影響が考えられるでしょうか。100TB をコピーする時間やコピー中ストレージにかかる負荷が本番サービスに影響を与えないか確認する必要があり、データ量が多ければ多いほどリストアテストを実施することが難しくなっていきます。NetApp ONTAP のファイルシステムでデータ管理を行なっている場合は、データブロックとポインタ情報を賢く扱うため、バックアップ・リストア・クローンが簡単に行えるようになります。 完全性を持ったバックアップを取得する方法については、関連する記事「 Amazon FSx for NetApp ONTAPイミュータブルバックアップの利用でランサムウェア対策の強化 」にて、改ざんできないバックアップ (Tamperproof Snapshot) 機能を紹介しています。 ランサムウェア攻撃を受けた際のデータリストアシナリオ ランサムウェア攻撃を受けファイルサーバ内のデータが改ざんされてしまった場合、どのような復旧操作が必要となるでしょうか。被害のないバックアップデータからリストアする操作を行いますが、被害を受けたファイルサーバはどのような攻撃を受けたか調査を行う必要があるため上書きリストアすることはできません。 この状況下でファイルサーバを復旧するには、バックアップデータを新たな領域にコピーし復旧する操作が必要となってきます。NetApp ONTAP では Snapshot から高速でボリュームを複製する FlexClone 機能があります。 この FlexClone 機能を使いデータリストアテストを行ってみましょう。 Amazon FSx for NetApp ONTAP にてデータリストアテスト 攻撃を受けファイルが改ざんされた共有データ data2 があります。 図 2: クライアントのエクスプローラーでの共有データ data2 の確認 FSx for ONTAP ファイルシステムの管理エンドポイントに ssh でログインします。取得済みの Snapshot 一覧を表示し被害を受ける前の Snapshot データがあることを確認します。 ::> snapshot show 図 3: Snapshot の確認 data2 の Snapshot を指定し FlexClone を data3 として作成します。 ::> volume clone create -flexclone <Clone Volume Name> -type RW -parent-vserver <SVM Name> -parent -volume <Origin Volume Name> -parent-snapshot <Snapshot Name> -junction-active ture -junction-path /<junction-path> 図 4: volume clone の作成 data3 を参照すると改ざんされる前のファイルがリストアできていることが確認できます。 図 5: クライアントのエクスプローラーでの共有データ data2 のリストア確認 復旧した data3 を恒久的に利用する場合は親ボリュームと切り離し (split) 通常のボリュームにすることができます。Split 操作を行う場合、Split 操作にて追加で必要となる容量を確認します。 ::> volume clone show -estimate -vserver <SVM Name> flexclone <Clone Volume Name> 図 6: volume clone の確認 FSx for ONTAP の空き容量を確認します。 ::> storage aggregate show 図 7: FSx for ONTAP のファイルシステム容量の確認 ボリュームを Split します。 ::> volume clone split start -flexclone <Clone Volume Name> 図 8: volume の split の設定 リストアテストが終了し、複製したデータが不要となった場合は以下の手順でクリーンナップすることができます。テストで使用した data3 ボリュームをオフラインにし、ボリュームを削除します。 ::> volume offline <Clone Volume Name> ::> volume delete <Clone Volume Name> ::> volume show 図 9: volume のオフライン作業、削除、削除されたことの確認 まとめ バックアップはランサムウェア攻撃を含む多くの有事に対する最後のかなめとして重要な位置づけにある中、意外とユーザが望む水準の状態まで復元できなかった企業が多いことがわかりました。NetApp としてはバックアップに関し一つ踏み込んだ形で、定期的にリストアまでのプロセスを含んだ一連の流れを実施することを推奨しています。その中で FSx for ONTAP 環境で出来るバックアップ・リストアについて Snapshot/FlexClone で実施する方法をご紹介させていただきました。 定期的に防災訓練のようにデータ復旧の一連の流れを実施することにより、バックアップの質のみならず有事の際の対応も早くなりランサムウェア攻撃等の被害を最小限にすることが可能と考えておりますのでぜひ実践下さい。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 AWSでは日本のお客様向けに「 日本の生成AI活用を支援 」というポータルサイトを設けています。週刊生成AI with AWSのブログシリーズはその週のニュースをサクッと確認していただくことを目指して書いていますが、こちらのポータルサイトは生成AIに取り組む際に有益な情報を集約しています。コンテンツを随時拡充していますので、ぜひチェックしてみてください。 先週、イベントを企画していますということを書きましたが、その第一弾のWebサイトが公開されました。「 AWS AI Day 」というイベントで、10/31に対面形式となります。生成AIの最新動向やユースケースを学べるようにコンテンツをくんでいますので、みなさんのご参加をお待ちしています。また、「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、9 月 2 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: KDDIアジャイル開発センター様、生成AIによる営業活動サポートの効果を確認 KDDIアジャイル開発センター株式会社 様は、生成AIを活用した社内外の課題解決に取り組んでいます。その取り組みのひとつが営業支援プロダクト「議事録パックン」です。営業活動を通じた知見の集積には、個々人の日報が重要です。ですが日報作成の時間確保や、その情報を有効活用する仕組みが上手くいっていないという課題がありました。これを解決するためにAmazon Bedrockを活用し、会議の録画・録音データや書き起こしテキストから、議事録を出力しそれに基づいて顧客に対する提案の骨子を出力する仕組みを構築しました。これによって議事録と提案書の作成時間を1時間短縮するという効果を確認しています。 ブログ記事「IBC2024でのAWSの見どころは生成AIとクラウドの進歩」を公開 年に一度開催されるIBC(International Broadcasting Convention)にむけて、AWSは生成AIからクラウドを利用したライブ制作ソリューションまで、メディア&エンターテインメント業界向けの最新技術をご紹介する準備を進めており、この記事ではその見どころをダイジェスト形式で紹介しています。 サービスアップデート Amazon BedrockでStability AIの画像生成モデル3種が利用可能に Amazon Bedrockで、Stability AIが提供する最新の画像生成モデル(テキストから画像を生成するモデル)がご利用頂けるようになりました。今回利用可能になったのは、Stable Image Ultra, Stable Diffusion 3 Large, Stable Image Coreの3種類です。それぞれのモデルは生成される画像の品質と生成スピードのバランスが異なっており、用途に応じたものを選択頂けるようになっています。 ブログ記事 や 製品webページ もご覧ください。現時点ではオレゴンリージョンでご利用頂けます。 Agents for Amazon BedrockがAnthropicのClaude 3.5 Sonnetをサポート 組織内に蓄えられた情報を利用したり、複雑なステップを要するタスクを実行する生成AIアプリケーションの開発を容易にするAgents for Amazon BedrockがAnthropic Claude 3.5 Sonnetをサポートしました。この機能は東京リージョンでもご利用頂けます。 Amazon SageMakerのオブジェクト指向SDK、sagemaker-coreを発表 Amazon SageMakerの操作を容易にするPython向けSDK、sagemaker-coreを発表しました。sagemaker-coreはリソースオブジェクトをパラメータとして渡すことができ、複雑なパラメータを手動で指定する手間を削減します。またリソースの状態やポーリングロジックなどを抽象化する仕組みをもっており、開発者がよりモデルの構築・デプロイに集中できるようになっています。 ドキュメント はこちらです。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。