本稿では、重複した IP アドレス範囲を持つネットワーク間接続のいくつかの方法を紹介していますが、第一に VPC の IP アドレス範囲は、通信するネットワークと重複しないように慎重に設計することが重要です。 お客様のネットワークにて、IP アドレス範囲が重複したリソース同士が通信する必要のある状況がよく見られます。これは、企業が買収された際、同じプライベート (RFC1918) アドレス範囲を使用している場合によく発生します。しかし、固有の IP アドレス範囲を持つサービスプロバイダーが、同じ IP アドレス範囲を持つ2つの異なるコンシューマーにアクセスを提供する際に発生する可能性もあります。 ネットワークの重複は意図せず発生することもあります。 Amazon SageMaker や AWS Cloud9 などの一部の AWS サービスでは、特定の IP アドレス範囲が自動的に予約されます。さらに、Docker などの一部のサードパーティ製品でも同様のことが行われます。定義済みの IP アドレスとの重複を避けるため、VPC を構築する際は、サービスやアプリケーションのドキュメントを必ず確認してください。 本稿では、IPv4 ベースのネットワークが抱える上記の障害に対するソリューションをいくつか説明します。アドレス空間のサイズを考えると、IPv6 を使用しているお客様にはこの問題は発生しないと予想されます。 アプリケーション間の通信方法によって、選択するソリューションが異なることに注意してください。アプリケーション間で完全な双方向接続が必要な場合があります (つまり、ネットワークセッションがどちら側からでも確立できる状態) 。また、「アウトバウンド」接続だけが必要な場合もあります。これは、一方のネットワークから他方のネットワークへのセッションは確立できるが、その逆はできない場合です。これらのパターンは、重複する IP アドレス範囲に対処するためのネットワークの設計方法に影響します。 Option 1: IP ネットワークのリナンバリング これは常にお客様へ最初に提案することです。上記のサービスプロバイダーのシナリオでは機能しません。ただし、ネットワークのリナンバリングを行う機会があれば、それが最善の選択肢です。ネットワーク構成の変更は簡単ではありませんが、次のような長期的な苦労を避けることができます。 ネットワーク管理コストの増加：以下に示す他ソリューションのほとんどは、有料のアプライアンスまたはサービスが必要です。ネットワークのリナンバリングは無料ではありません (結局、時間と人件費が発生します)。しかし長期的に見れば、重複するネットワークを相互に接続するために必要なコンポーネントを運用するための継続的なコストを削減できます。 複雑さの増大：一般的に、IP アドレス範囲の重複する2つ以上のネットワークを接続することは困難です！長期的に見れば、アプリケーション環境が拡大・変化したり、ネットワークが追加されるほど、ますます複雑になる可能性があります。 複雑なトラブルシューティング：問題が発生したとき、何が起きているのか、どこで起きているのか、そして対処するために何をすべきかを理解するのは、重複した IP アドレスに対処する必要がなくても十分複雑です。これら全てが混乱を招き、トラブルシューティングに通常よりもはるかに長い時間がかかる可能性があります。 互換性の問題：以下のソリューションはすべて、何らかの方法でネットワークアドレス変換 (NAT) を利用しています。一部のアプリケーションは、NAT では動作せず、他のアプリケーションでも使用方法に制限が生じる可能性があります。現在、 NAT で動作しないアプリケーションをお持ちでない場合でも、将来的にそのようなアプリケーションが環境にデプロイされる可能性があります。ネットワークのリナンバリングを実行すると、この問題を完全に回避できます。 NAT を利用すると管理オーバーヘッドも増えます：アプリケーションは重複する IP アドレスを使用するため、アプリケーションが使用する元の IP アドレスと NAT された IP アドレスを追跡し更新する際に、ファイアウォールルールが複雑になります。 一般に、長期的に見てより安価で容易になるため、重複するネットワークは可能な限り、リナンバリングすることを強く推奨します。 Option 2: AWS PrivateLink 2017年、AWS は PrivateLink の提供を開始しました。これは、IP アドレス範囲が重複している場合も含め、VPC 間で API またはアプリケーションのエンドポイントを簡単に公開できる HyperPlane ベースのサービスです。また、複数のコンシューマーに接続性を提供する必要があり、リモート IP アドレス範囲を制御できないサービスプロバイダーにも理想的です。さらに、IP アドレスが重複する複雑なネットワークを持つお客様にも同じメリットがあります。これは、基礎的なネットワークアドレススキームに変更を加える必要がないため、ここで示した中で最もシンプルな方法です。 下の図では、“Provider” VPC 内にあるアプリケーションを見ることができます。このアプリケーションには Network Load Balancer (NLB) が接続されており、PrivateLink を使用することで複数の “Consumer” VPC と NLB を共有することができます。下の図では、全 Consumer VPC、Provider VPC で IP アドレス範囲が重複しています。これは最悪のシナリオです。 各 Consumer VPC では、PrivateLink エンドポイントがローカル IP アドレスを持つ Elastic Network Interface として表示されます。Provider VPC では、Consumer VPC からの接続は、Provider VPC 内のローカル IP アドレスから来たように見えます。基盤となる HyperPlane サービスは、PrivateLink を機能させるために両側で NAT 操作を実行しています。 他にも次のようなセキュリティ上の利点があります。 PrivateLink の接続を確立する際、プロバイダーは Consumer VPC の所有者にリクエストを送信する必要があります。次に、所有者が承認する必要があります。これは VPC ピアリングの仕組みと同じです。プロバイダーは、承認なしにコンシューマー向けの PrivateLink を作成することはできません。 コンシューマーとプロバイダー間で許可されるのは、設定済みの TCP ポートのみです。これにより、コンシューマーは Provider VPC 内の特定のリソースにのみアクセスでき、それ以外にはアクセスできないことが保証されます。 Provider VPC 内のアプリケーションが Consumer VPC への接続を確立する方法はありません。 最後に、スケーラビリティのメリットがあります。プロバイダーはアプリケーションを数百の ConsumerVPC に公開できます。 PrivateLink には、NLB の形で冗長性が組み込まれています。これにより、バックエンドサーバーおよび Consumer VPC の構成にトラフィックが配信されます。さらに、PrivateLink エンドポイントを配置するサブネットも選択できます。下の図では、複数のアベイラビリティーゾーンにまたがるマルチサブネット環境を示しています。 お客様からよくある質問の 1 つとして、オンプレミスネットワークでこのような接続を実現する方法です。下の図では、複数の独立したカスタマーに接続された Provider VPC があり、各カスタマーは VPN 経由で AWS に接続されています。Provider VPC や全カスタマーの IP アドレス範囲が重複していることに注意してください。唯一の課題は、VPN サービスがアタッチされる VPC に割り当てられる IP アドレス範囲が、オンプレミスと重複しない IP アドレス範囲を見つけることです。この例では、オンプレミスのクライアントは VPN VPC 内の PrivateLink エンドポイントに割り当てられた IP アドレスに接続します。 このソリューションは、図のCustomer C が示す通り AWS Direct Connect でも機能します。Customer C も VPN VPC で異なる IP アドレス範囲を持っています。これは 172.16.0.0/16 が既に使用されているため、VPN VPC では異なる IP アドレス範囲を使用する必要があるためと考えられます。これは問題ではありません。VPN VPC の IP アドレス範囲は、Customer C が使用するネットワークとの重複を排除する必要があるだけなため、選択できる範囲は非常に広いです。 このオプションの設定は、追加メンテナンスが不要で、冗長性が高く、拡張性も高いため、簡単です。さらに、顧客ネットワーク間を分離できます。サービスプロバイダー環境でアプリケーションを作成する場合は、PrivateLink がネットワーク柔軟性を提供できるようにソリューションを設計することを検討してください。 価格ページ 通り、PrivateLink にはコストがかかることに注意してください。アプリケーションは単一の TCP ポートとして提供される必要があるため、アプリケーションによってはこのソリューションでは動作しない場合があります。アプリケーションが UDP を使用する場合、または複数の TCP ポートを持ち、クライアントがバックエンドサーバーのアフィニティを維持する必要がある場合、PrivateLink は適していません。 Option 3: VPCで複数 IP アドレス範囲を利用 アプリケーションが異なる層に分かれている場合があります。ユーザーや他のアプリケーションからのリクエストに応答するフロントエンドやミドルウェア、データベース、キャッシュ等で構成される1つ以上の “バックエンド” 層です。この環境では、フロントエンドのサブネットに重複しない IP アドレスを持たせる一方で、バックエンドのサブネットは他のアプリケーションと重複させることができます。 以下の図は、3つのアプリケーション VPC が AWS Transit Gateway に接続する様子を示しています。VPC の IP アドレス範囲は重複していますが、IP アドレス範囲の異なるフロントエンドサブネットが Transit Gateway にアドバタイズされているため、エンドユーザーはそれぞれにアクセスできることに注意してください。この場合、各 VPC の全てのサブネットをアドバタイズすべきではないため、Transit Gateway への自動ルート伝播を無効にする必要があります。 この環境では、IP アドレス範囲が重複する各 VPC (図では 10.0.0.0/22) を作成し、その後、各 VPC に重複しない2つ目の IP アドレス範囲を追加します。フロントエンドサブネットでは、Transit Gateway をターゲットとする他のフロントエンドサブネットへのルートを追加できます (またはデフォルトルートを使用できます)。 これは、バックエンドサブネットにあるサーバーをどのように管理するかという課題を解決するものではありません。実現する方法は、各 VPC のフロントエンドサブネットに踏み台ホストを配置することです。これにより、管理者は SSH または RDP を使用して踏み台ホストを経由して、バックエンドサブネットにアクセスできるようになります。また、 AWS Systems Manager を使用して、ホスト上でコマンドをリモート実行したり、バックエンドホストへの SSH トンネルを作成することもできます。 バックエンドサーバーでは、リポジトリからのコードのダウンロードや適切なサーバーからの更新、アプリケーションログの送信、パフォーマンスメトリクスの提供などが引き続き必要となります。このために、AWS サービス ( Amazon CloudWatch や Amazon Simple Storage Service (Amazon S3) など) のプライベートエンドポイントと組み合わせて使用することができます。サーバーが AWS 以外のエンドポイントへのアウトバウンドアクセスを必要とする場合は、フロントエンドサブネットでホストされている NAT またはプロキシサービスが必要となります。 このオプションは、重複するネットワークの一部だけをリナンバリングする必要がある場合、(フロントエンドのサブネットのみを変更することで) 作業を減らしつつ、(複雑なNATソリューションを実行せずにアプリケーションとユーザーが通信できるため) リスクの大部分を低減できることを意味します。ただし、追加コストがかかります。踏み台ホスト、NAT またはプロキシインスタンス、AWS サービス用プライベートエンドポイントなどです。また、管理コストをできるだけ低く抑えるために、このインフラストラクチャを自動化して展開および管理することを強く推奨します。 この図では、Web サーバー (または他アプリケーションのフロントエンドコンポーネント) はフロントエンドサブネットに配置されていますが、そのサブネットにロードバランサーを配置し、 Amazon Elastic Compute Cloud (Amazon EC2) コンポーネントを到達不可能な IP アドレス範囲を使用して別のサブネットに保持することもできます。 このオプションでは、他アプリケーションとの重複を心配することなく、数千の IP アドレスを持つバックエンドワークロードのサブネットをデプロイできます。さらに、フロントエンドサブネットには必要最小限の IP アドレスのみを使用して、(VPC の) 外部ネットワークからアプリケーションへのアクセスを確保できます。 最後に、バックエンドサブネットには IPv4 の代わりに IPv6 の使用を検討してください。このシナリオで IPv4 を使用する場合、(上記で説明した方法を除いて) バックエンドサブネットには到達できません。IPv6 を使用することで、サブネットをオーバーラップする必要がなくなり、IPv6 に移行すると回避策なしにサブネット内のリソースに到達できるようになります。 Option 4: Private NAT Gateway を使用してサブネットを隠蔽する 2021年、Private NAT Gateway の提供を開始しました 。 NAT Gateway が VPC ネットワーク全体をインターネットから “隠す” (単一の Elastic IP アドレスから来たように見せる) のと同じように、Private NAT Gateway も VPC から他のプライベートネットワークに接続する際にそれを可能にします。Elastic IP アドレスと Internet Gateway の代わりに、Private NAT Gateway はVPC 内で割り当てられたプライベート IP アドレスを、VPC が “隠れる “ ためのアドレスとして使用します。 これは、VPC からオンプレミスネットワークや他 VPC に接続したいが、VPC 内のリソースには直接接続したくない環境で役立ちます。オプション3 と非常に似ていますが、VPC からの外部接続を提供するために NAT やプロキシインスタンスを実行する必要がない点が異なります。 次の図は、Private NAT Gateway の動作を示しています： VPC の IP アドレス範囲は10.0.0.0/16ですが、その IP アドレス範囲外の2つのサブネット (10.31.10.0/24と10.31.11.0/24) が追加されていることに注意してください。各アベイラビリティーゾーンに Private NAT Gateway が追加されています (Internet-facing NAT Gateway と同様に1つで十分ですが、冗長性のため2つを推奨します)。これらは、セカンダリ IP アドレス範囲のサブネットに追加されています。NAT Gateway は、サブネットの IP アドレスを使用して、バックエンドサブネットからのワークロードの IP アドレスを変換します。 Transit Gateway 内で、フロントエンドサブネットへのルートを追加することで、戻りのトラフィックを Private NAT Gateway に送ることができます。VPC 内では、バックエンドサブネットからのトラフィックは、Internet-facing NAT Gateway のルートテーブルとほぼ同じ方法で Private NAT Gateway にルーティングされます。 この場合、バックエンドサブネットのインスタンス管理は、フロントエンドサブネットの SSM または踏み台ホストを使用して行う必要があります。アプリケーションのデプロイが自動化されていれば、これらのホストを人間が管理する必要はありません。これは望ましい結果です。 前のオプション同様に、IP アドレスを節約しつつ、ワークロードの関連性の高い重要な部分にルーティング可能で利用できる状態を維持する優れた方法です。このタイプの環境を作成する方法の詳細な手順は、 こちらの投稿 で見つけることができます。 Private NAT Gateway の使用には、 料金ページ に示されているように料金が発生することにご注意ください。 まとめ この投稿では、重複する IP ネットワークに対処するいくつかの方法を紹介しました。以下の表は、それぞれのオプションの比較を示しています。 オプション サービスコスト 冗長性 完全なネットワーク到達性 ソリューションの複雑さ メンテナンスの複雑さ 最適な対象 1: リナンバリング 低 N/A はい 低 低 全ての方におすすめ 2: PrivateLink 中 はい いいえ 低 低 サービスプロバイダー 3: VPCで複数 IP アドレス範囲を利用 中 はい いいえ 中 中 コンテナ / 大きなワークロード 4: Private NAT Gateway 中 可能 いいえ 中 中 コンテナ / 大きなワークロード 重複するネットワークをリナンバリングすることが、長期的には (コストや複雑さ、可視性の面で) 最も良い選択肢であることを覚えておいてください。PrivateLinkは、接続先のネットワークを制御できないサービスやアプリケーションプロバイダーに対処することに特化して設計されています。 本稿は、2022年6月16日に Networking & Content Delivery で公開された “ Connecting Networks with Overlapping IP Ranges ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

Amazon Quantum Ledger Database(Amazon QLDB) は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。本ブログでは、Amazon QLDB のサポート終了に伴う移行先のソリューションについてご紹介します。 Amazon QLDB のサポート終了 Amazon QLDB は、フルマネージド型の台帳データベースサービスです。Amazon QLDB は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。今回の Amazon QLDB のサポート終了のアナウンスに伴い、AWS では Amazon Aurora PostgreSQL への移行に関する ２ つのブログを公開しています。 ・ Amazon QLDB の Amazon Aurora PostgreSQL への移行 ・ 監査のユースケースで Amazon QLDB を Amazon Aurora PostgreSQL に置き換える また、Amazon QLDB の移行先候補としては、AWS のパートナーのソリューションもあります。ここでは、Amazon QLDB の移行先として株式会社 Scalar のソリューションであります ScalarDL をご紹介します。 株式会社 Scalar について 株式会社 Scalar は「データマネジメントの未来を創る」というビジョンのもとに、データの完全性・真正性を保証する ScalarDL や、データベースの仮想化を実現する ScalarDB などの製品を開発している会社です。 Amazon QLDB と ScalarDL Amazon QLDB は、追記型で不変なデータの変更履歴を提供します。この変更履歴は暗号学的な方法で保護されており、単にそれらを表示するだけでなく、各変更の完全性をさかのぼって検証することができます。 一方、ScalarDL も同様に追記型であり、暗号学的な方法に基づく不変なデータの変更履歴とその完全性検証機能を提供します。 ScalarDL は、データベースにおける改ざんなどの任意の故障(ビザンチン故障)の検知を実現するデータベースミドルウエアです。AWS Marketplace でも提供されており、Amazon DynamoDB や Amazon Aurora などと組み合わせて利用することができます。 Marketplace： ScalarDL Ledger Marketplace： ScalarDL Auditor 以降では、Amazon QLDB と ScalarDL の違いについて具体的に触れていきたいと思います。 Amazon QLDB と ScalarDL の違い Amazon QLDB と ScalarDL はどちらもデータの変更履歴機能と完全性検証機能を提供する点で共通していますが、そのデータモデルやアクセスインタフェース等いくつかの違いがあります。 データ操作 Amazon QLDB は、PartiQL と呼ばれる問合せ言語を用いて台帳のデータを追加・更新したり、参照したりすることができます。PartiQLはSQL互換な問合せ言語で、SELECT、INSERT、UPDATE といったステートメントで台帳にアクセスすることが可能です。 一方、ScalarDL では、「コントラクト」と呼ばれるビジネスロジックを記述した小さなプログラムを介して台帳にアクセスします。具体的には、コントラクトは Java 言語で記述することができ、get()、scan()、put() といったインタフェースを提供しているため、これらを用いて PartiQL の SELECT、INSERT、UPDATE ステートメントによる操作を置き換えることができます。 データモデル Amazon QLDB と ScalarDL では異なるデータモデルを採用しているため、移行に際してはいくつかの注意が必要です。Amazon QLDB はテーブルやインデックスといったリレーショナルデータベースに似たデータモデルを採用する一方、ScalarDL は高いスケーラビリティを実現するため、Key-Value 型に似たフラットでシンプルなデータモデルを採用しています。具体的に ScalarDL の台帳は、文字列型のID (アプリケーションが利用する主キー) で特定可能なレコードの集合として表現されます。そのため、ScalarDL ではテーブルを明示的に作るかわりに、ID にテーブルを識別するプレフィックスを含めることで仮想的にテーブル相当の機能を実現します。また、インデックスが必要な場合には、このデータモデル上でインデックスキーとレコードのマッピングを作成します。 なお、ScalarDL への移行をより容易にするため、株式会社 Scalar からテーブルやインデックスの作成および PartiQL の各種ステートメントに相当する事前定義済みのコントラクトの提供が 予定されています。 履歴表示処理 Amazon QLDB は、テーブル内のレコードの過去のバージョンにアクセスするため、history() 関数を提供しています。history() 関数を使用すると、時間の経過とともにデータレコードがどのように変化したかを確認できます。 ScalarDL では、コントラクトにおいて scan() インタフェースを使用することで、任意の範囲の過去のレコードバージョンを取得・表示することができます。 レコードの完全性 Amazon QLDB では、ダイジェストと呼ばれる暗号学的ハッシュを用いて台帳内のレコードの完全性を検証することができます。具体的には、ある時点における台帳のサマリーであるダイジェストを信頼できる第三者が保管しておき、そのダイジェストとレコードのバージョンを指定して検証を行います。レコードのバージョンのハッシュ値とマークルツリーと呼ばれる木構造で管理されたハッシュ値を用いてダイジェストを再計算することで、当該レコードバージョンの完全性を確認できます。 ScalarDL でもAmazon QLDB におけるダイジェストと似たように、暗号学的ハッシュを用いてレコードの完全性を検証できます。ScalarDL では、過去のレコードバージョンがハッシュチェーンでつながれています。そのため、過去の更新履歴をさかのぼって各レコードバージョンの内容を再計算し、正しくハッシュチェーンが構成されているかを検証することで、レコードの完全性を確認できます。この検証は、validate-ledger と呼ばれる CLI や API を使用して行います。また、ScalarDL では、コントラクトの実行や validate-ledger の実行の結果として、レコードのハッシュ値等を含んだ「プルーフ」を取得することができます。このプルーフを信頼できる第三者が保管しておくことで、検証の信頼性を高めることができます。さらに、Auditor と呼ばれるコンポーネントを追加で利用すれば、例えば、台帳を管理するプログラム自体の改ざんも含め、任意の故障(ビザンチン故障)を検知できるようになります。 更新イベントのフィード Amazon QLDB streams は、台帳で発生したすべてのデータ更新イベントをニアリアルタイムで Amazon Kinesis Data Streams にフィードします。フィードされたストリームデータは、台帳における重要なデータの更新状況の分析や疑わしいアクティビティの検出などに活用できます。 ScalarDL では、上記に似た分析プラットフォームを実現するために、台帳で読み書きされたデータを HTAP (ハイブリッド型トランザクション／アナリティクス処理) エンジンである ScalarDB へフィードできる「ファンクション」という機能を提供しています。ファンクションは、コントラクトと同様に Java 言語のプログラムであり、分析処理向けのデータ変換ロジックなども記述することができます。フィードされたデータは、ScalarDB を利用して、用途に合った様々な分析を行うことが可能です。 まとめ 以上、ScalarDL のご紹介と Amazon QLDB との違いについてご説明しました。Amazon QLDB からの移行先として ScalarDL について詳しく知りたい場合は、ScalarDL のドキュメンテーションサイトをご参照ください。 ・ ScalarDL Technical Overview ・ ScalarDL の実装 (製品ドキュメンテーション) また、Amazon QLDB からScalarDL への移行については、アプリケーションやデータの移行含め株式会社 Scalar にてサポート頂けますので、ScalarDL への移行を検討したい場合は、株式会社 Scalar か AWS の担当までお気軽にお問い合わせください。 問い合わせ先： qldb-migration@scalar-labs.com 本ブログ執筆にあたり、株式会社 Scalar の山田様、根本様にご協力頂きました。お二方、ありがとうございました。 著者について 山田 浩之 は、株式会社 Scalar の CTO 兼 co-CEO として、ScalarDL および ScalarDB の研究開発を指揮しています。 根本 潤 は、株式会社 Scalar の Principal Researcher として、ScalarDL および ScalarDB の研究開発を行っています。 内山 義夫は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。  

(本記事は 2024/05/14に投稿された Continuously replicate Amazon DynamoDB changes to Amazon Aurora PostgreSQL using AWS Lambda を翻訳した記事です。) Amazon DynamoDB は、あらゆる規模で高性能アプリケーションを実行できるように設計された、フルマネージド型のサーバーレスなキーバリュー NoSQL データベースです。 Amazon Aurora は、クラウド向けに構築された MySQL および PostgreSQL と互換性のあるリレーショナルデータベースです。Aurora は、従来のエンタープライズデータベースのパフォーマンスと可用性と、オープンソースデータベースのシンプルさとコスト効率を兼ね備えています。サーバーレステクノロジーにより、キャパシティのプロビジョニングやパッチ適用などのインフラストラクチャ管理のタスクが不要になり、アプリケーションスタック全体の俊敏性を向上させます。 この投稿では、 Amazon DynamoDB Streams と AWS Lambda を使用して DynamoDB から Amazon Aurora PostgreSQL 互換エディション にデータをレプリケートすることで、大規模なリアルタイムのデータ変更を処理するソリューションを紹介します。 ユースケース 私たちのこのユースケースでは、お客様はオンプレミス環境でレガシーレポートアプリケーション、ビジネスインテリジェンス（BI）ツール、データウェアハウスを実行していました。長期計画として、データウェアハウスを Amazon Redshift にモダナイズしたいと考えていました。一方、ダウンストリームのレガシーレポート環境をサポートするために、DynamoDB から Amazon Aurora PostgreSQL 互換エディションにデータをレプリケートし、ユーザーがワンタイムクエリや集計クエリを実行できるようにしました。DynamoDB から Amazon Aurora PostgreSQL にデータをレプリケートするのは一般的なパターンではありませんが、お客様はデータを Amazon Aurora PostgreSQL に持ち込むことを希望しました。これにより、一時的に既存のレガシーアプリケーションを実行し続けることができ、同時に Amazon Redshift への移行を開始することができました。 ソリューション概要 DynamoDB では、パーティションキーと、オプションでソートキーを定義するだけでデータを操作できます。一方、Amazon Aurora などのリレーショナルデータベースでは、扱う属性ごとにテーブルスキーマを定義する必要があります。DynamoDB テーブルから変更をレプリケートするには、 DynamoDB Streams を使用して、アイテムレベルの変更を時系列でキャプチャし、この情報を最大 24 時間ログに保存します。レプリケーションは DynamoDB Streams が有効になってから開始されます。つまり、DynamoDB テーブルに既存のデータがあり、それを Aurora にレプリケートする必要がある場合は、 DynamoDB データを Amazon S3 にエクスポート するか、 AWS Data Pipeline を使用して DynamoDB データをエクスポートおよびインポート したりするなど、1 回限りのロードで対処する必要があります。DynamoDB はスキーマレスであるため、レプリケーションが中断されないように、DynamoDB に新しい属性を追加する場合は、リレーショナルデータベースの構造を最新の状態に保つ必要があります。Aurora は 1 秒あたり数十万件のトランザクション（TPS）を処理できますが、DynamoDB が受信する TPS がそれを超えると、Aurora でレイテンシーが発生する可能性があります。ソリューションを実装する前に、TPS の要件を理解し、レイテンシーの SLA に整合させることが重要です。 お客様と作業を進める中で、 Amazon Data Firehose を使用して DynamoDB から Aurora にデータをストリーミング するオプションについても話し合いました。しかし、お客様は、追加コストなしですぐに使用できるソリューションであり、24 時間以内のデータ保持に関するお客様のサービスレベルアグリーメント（SLA）を満たしていることから、DynamoDB Streams の利用を希望しました。 次の図は、ソリューションのアーキテクチャとワークフローを示しています。 データベース間のデータレプリケーションを有効にするには、次の手順を実行します。 DynamoDB テーブルを作成します。 DynamoDB から SQL へのテーブルマッピングを構成します。 DynamoDB テーブルの DynamoDB Streams を有効にします。 Powertools for AWS Lambda を使用して Amazon CloudWatch Logs および AWS Secrets Manager パラメータ用の Lambda 関数を作成します。 DynamoDB Streams の Lambda トリガーを設定します。 DynamoDB の変更を Amazon RDS で検証します。 前提条件 この記事を読むには、次の前提条件が必要です。 AWS コマンドラインインターフェイス （AWS CLI）のインストールと設定 AWS アカウント と AWS アカウントのリソースを操作するための適切な権限 AWS 上の仮想プライベートクラウド（VPC） データがレプリケートされる Aurora Serverless v2 DynamoDB から SQL へのテーブルマッピングの構成 次の表は、DynamoDB テーブルと SQL データベース間のマッピングを示しています。このユースケースでは、1 つの DynamoDB テーブルを 1 つの Aurora PostgreSQL テーブルにマッピングしています。 DynamoDB Table (Employees) SQL Table (Employees) Id (PrimaryKey), Type: Number Id (PrimaryKey), Type: Number empName, Type: String Name, Typre: Varchar(20) empDepartment, Type: String Department, Type: Varchar(10) 両方のテーブルの Id を主キーとして使用します。 DynamoDB SQL INSERT INSERT MODIFY UPDATE REMOVE DELETE DynamoDB テーブルの作成 次の AWS CLI コマンドは、 パーティションキー Id を数値として指定した Employees という名前の DynamoDB テーブルを作成しています。 aws dynamodb create-table \ --table-name Employees \ --attribute-definitions \ AttributeName=Id,AttributeType=N \ --key-schema \ AttributeName=Id,KeyType=HASH \ --provisioned-throughput \ ReadCapacityUnits=5,WriteCapacityUnits=5 \ --table-class STANDARD このテーブルは、5 つの読み取りキャパシティーユニット（RCU）と 5 つの書き込みキャパシティーユニット（WCU）でプロビジョニングされたスループットで構成されています。プロビジョニングされたキャパシティ料金の詳細については、 プロビジョニングされたキャパシティの料金 を参照してください。 DynamoDB テーブルで DynamoDB Streamsの有効化 DynamoDB Streams を有効 にするには、次の手順を実行します。 DynamoDB コンソールで、作成したテーブルに移動し、 エクスポートおよびストリーム タブを選択します。 DynamoDB ストリームの詳細 について、 オンにする を選択します。 DynamoDB Streams を有効にすると、DynamoDB テーブルのすべてのデータ操作言語（DML）アクションがストリーム内の項目としてキャプチャされます。 表示タイプ では新しく更新された値をキャプチャするために 新しいイメージ を選択し、新しい値を使って宛先を置き換えます。 ストリームをオンにする を選択します。 同様のことは CLI でも実行できます。次のコマンドは、新しいイメージの表示タイプを使用して Employees テーブルでのストリーミングを有効にします。 aws dynamodb update-table \ --table-name Employees \ --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE CloudWatch Logs と Secrets Manager パラメータ用の Lambda 関数を作成 このユースケースでは、SQL Replicator と呼ばれる Lambda 関数を使用します。この関数は、DynamoDB テーブルでデータが変更されたときに DynamoDB Streams によって呼び出されます。この関数は Aurora PostgreSQL Serverless への変更をレプリケートし、そのログは Powertools for Lambda を使用して CloudWatch Logs にキャプチャされます。Lambda のコードは Python で記述されています。PostgreSQL の接続には Psycopg データベースアダプターを使用し、logger と シークレットストア には Powertools for Lambda (Python) を使用します。 Lambda ロールポリシー Lambda ロールは、次の AWS 管理ポリシー を使用して構築されています。 AWSLambdaInvocation-DynamoDB — DynamoDB Streams への読み取りアクセスを提供します。 AWSLambdaBasicExecutionRole — CloudWatch Logs への書き込み権限を提供します。 awsLambdaVPCAccessExecutionRole — VPC 内のリソースにアクセスしながら Lambda 関数を実行する最小限の権限を提供します。ネットワークインターフェースの作成、表示、削除および CloudWatch Logs への書き込み権限が含まれます。 SecretsManagerReadWrite — AWS マネジメントコンソール 経由で Secrets Manager への読み取り/書き込みアクセスを提供します。 Secrets Manager で 送信先の RDS データベースシークレットを作成 し、Lambda 関数から使用することができます。統合については、 Improve security of Amazon RDS master database credentials using AWS Secrets Manager を参照してください。 次の Python コードは、DynamoDB から PostgreSQL にデータを同期する Lambda 関数用です。これには以下のアクションが含まれています。 json 、 psycopg2 、 aws_lambda_powertools などの必要なライブラリをインポートします。 ログを記録するために、 aws_lambda_powertools から logger を初期化します。 Secrets Manager から RDS データベースの認証情報を取得します。 psycopg2 を使用して PostgreSQL データベースに接続します。 DynamoDB イベントの各レコードについて、イベントタイプ（INSERT、 MODIFY、REMOVE）に基づいて PostgreSQL で CRUD 操作を実行します。 psycopg2 cursor を使用して SQL クエリを実行し、PostgreSQL データベース内のレコードを insert、update、deleteします。 各ステップで logger を使用して関連情報を記録します。 PostgreSQL からレコードを選択して同期されたデータを検証します。 最後にトランザクションをコミットします。 # Library imports import json import psycopg2 from aws_lambda_powertools import Logger from aws_lambda_powertools.utilities import parameters #Initialize Powertools Logger logger = Logger() #instruct Logger to log the incoming event @logger.inject_lambda_context(log_event=True) #Lambda Handler def lambda_handler(event, context): try: # Retrieve the secret value from AWS Secrets Manager secret_value = json.loads(parameters.get_secret(name="dev/rds")) #DB Connect mydb = psycopg2.connect( user=secret_value["username"], password=secret_value["password"], host=secret_value["host"], dbname=secret_value["engine"], port= secret_value["port"] ) mycursor = mydb.cursor() # For every record in the event for record in event["Records"]: event_name = record["eventName"] #based on the record event if event_name == "INSERT": logger.info("Inserting record", extra = { "record": record}) sql_script = "INSERT INTO public.\"Employees\" VALUES (%s,%s,%s)" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA"), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA"), ) mycursor.execute(sql_script,sql_value) logger.info("Record inserted successfully into Employees table") elif event_name == "MODIFY": logger.info("Modifying record", extra = { "record": record}) sql_script = "UPDATE public.\"Employees\" SET \"Name\" = %s, \"Department\" = %s WHERE \"Id\" = %s" sql_value = ( record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA")), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA")), int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record modified successfully into Employees table") elif event_name == "REMOVE": logger.info("Removing record", extra = { "record": record}) sql_script = "DELETE FROM public.\"Employees\" WHERE \"Id\" = %s" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record removed successfully from Employees table") #Verifying with the select the select statement mycursor.execute('SELECT * FROM public."Employees"') records = mycursor.fetchall() mycursor.close() mydb.commit() logger.info("Received event: ", extra = { "records": records}) except (Exception, psycopg2.Error) as error: logger.exception("Error while fetching data from PostgreSQL", extra= {"error": error}) 関数コードの「dev/rds」を、Lambda がデータベース認証に利用するシークレットの名前に置き換えます。RDS データベースのシークレットの作成については、 AWS Secrets Manager データベースシークレットの作成する を参照してください。 Secrets Manager のシークレットの値 参照用のシークレットの値は次のとおりです。 {"username":"admin","password":"xxxxxx","engine":"postgres","host":"database.cluster-abcdefghjklmn.us-east-1.rds.amazonaws.com","port":5432,"dbClusterIdentifier":"database-3"} Amazon Aurora は VPC にデプロイされているため、Lambda を同じ VPC にアタッチしました。Lambda と Amazon Aurora の両方にセキュリティグループルールを設定して、両者の接続を許可しています。詳細については、 Lambda 関数を使用して Amazon RDS データベースにアクセスする を参照してください。追加のヘルプについては、 Amazon RDS のトラブルシューティング を参照することもできます。 DynamoDB Streams の Lambda トリガーを設定 Lambda トリガーを使用すると、DynamoDB テーブルのデータ変更に対応するアプリケーションを構築することができます。DynamoDB と Lambda の統合の詳細については、 DynamoDB Streams と AWS Lambda のトリガー を参照してください。 トリガーは Lambda 関数を実行し、エラーが返された場合には、正常に処理されるか、データの有効期限が切れになるまでバッチを再試行します。より小さなバッチで再試行したり、再試行回数を制限したり、その他のオプションを Lambda 関数に設定したりすることもできます。バッチ処理の詳細については、 ポーリングストリームとバッチストリーム を参照してください。 Lambda トリガーは、DynamoDB の DML ボリュームに基づいてバッチサイズが 100 に設定されています。 Amazon RDS で DynamoDB の変更を検証する DynamoDB Streams と Lambda 関数をセットアップしたら、データ配信を検証することができます。AWS CLI またはコンソールを使用して DynamoDB の insert、update、delete を実行できます。この記事では、AWS CLI のサンプルコードを提供します。PostgreSQL クライアントを使用して接続し（この記事では pgAdmin を使用）、データを検証できます。 Insert AWS CLI で次のコードを使用して insert を実行します。 aws dynamodb put-item \ --table-name Employees --item "{\"Id\": {\"N\": \"2001\"},\"empDepartment\": {\"S\": \"AnyDept\"},\"empName\": {\"S\": \"Akua\"}}" Update AWS CLI で次のコードを使用して update を実行します。 aws dynamodb update-item --table-name Employees \ --key "{\"Id\": {\"N\": \"2001\"}}" \ --update-expression "SET empDepartment = :newval" \ --expression-attribute-values "{\":newval\": {\"S\": \"ExDept\"}}" 次のスクリーンショットは、テーブル内の update された値を示しています。 Delete AWS CLI で次のコードを使用して delete を実行します。 aws dynamodb delete-item --table-name Employees --key "{\"Id\": {\"N\": \"2001\"}}" 次のスクリーンショットは、レコードが delete されたことを示しています。 クリーンアップ Lambda 関数を削除します。 DynamoDB テーブルを削除します。 Aurora PostgreSQL Serverless データベースを削除します。 まとめ この記事では、Lambda を使用して DynamoDB の変更を Aurora に継続的にレプリケートするイベント駆動型ソリューションを構築しました。このソリューションは、ダウンストリームのレガシーレポートワークロードをサポートすることでお客様の問題を解決し、1 回限りのクエリと集計クエリを実行できるようにしました。 このソリューションを試してみて、コメントや質問がある場合はコメント欄に残してください。 著者について Aravind Hariharaputran は、Amazon Web Services のプロフェッショナルサービスチームのデータベースコンサルタントです。彼は Microsoft SQL Server を専門とするデータベース全般に情熱を注いでいます。お客様がオンプレミスのデータベースワークロードを AWS クラウドに移行して最適化するのを支援する技術ソリューションの構築を支援しています。家族と過ごしたり、クリケットをしたりすることを楽しんでいます Sakthivel Chellapparimanam は、Amazon Web Services の AWS プロフェッショナルサービスのクラウドアプリケーションアーキテクトです。お客様のクラウドアプリケーションの構築とクラウドへのアプリケーションの移行を支援しています。

(本記事は 2024/05/03に投稿された Introducing configurable maximum throughput for Amazon DynamoDB on-demand を翻訳した記事です。) Amazon DynamoDB はあらゆる規模のモダンなアプリケーションを開発できるサーバレスの NoSQL データベースサービスです。DynamoDB オンデマンドモード はキャパシティプランニングなしで毎秒数百万ものリクエストに対応し、テーブルに対してリクエストが発行されていない時には自動的にゼロへスケールダウンするため、真のサーバレスエクスペリエンスを提供します。オンデマンドモードのシンプルなリクエスト単位の料金モデルでは実際に使用したキャパシティに対してのみ料金が発生するため、アイドルキャパシティについて心配する必要がありません。データベースのワークロードを予測することが複雑な新しいアプリケーションを構築する場合や、トラフィックパターンが予測できない、変動しやすいアプリケーションを構築する場合、また、従量課金制のサーバレススタックを使用する場合に、オンデマンドモードを使用するお客様が増えています。オンデマンドモードを使用するテーブルの場合、DynamoDB は需要に合わせてお客様のワークロードの増減に応じてすぐにスケーリングし、アプリケーションがリクエストに応答できるようにします。 各オンデマンドテーブルのデフォルトのスループットレートは毎秒 40,000 回の読み取りリクエストと毎秒 40,000 回の書き込みリクエストです（ AWS サービスクォータ を利用して増やすことができます）。これはアカウント内のすべてのテーブルに一律に適用され、アカウント内のさまざまなワークロードや要件に合わせてカスタマイズしたり調整することはできません。オンデマンドモードではさまざまなトラフィックパターンに対応するために即座にスケーリングされるため、最適化されていなかったり、急いで書かれたコードによって急速なスケールアップを引き起こしリソースを消費してしまうことで、テーブルレベルの使用量やコストを抑えることが困難になる可能性があります。お客様から、コストとパフォーマンスの最適なバランスを実現するために、オンデマンドモードでの柔軟性と詳細な設定機能を求める声が頻繁に寄せられています。 本日、個々のオンデマンドテーブルと関連するグローバルセカンダリインデックス（GSI）の最大読み取りまたは書き込み（あるはその両方）スループットを設定できる新しいオプション機能をリリースします。これにより、テーブルレベルのコストとパフォーマンスのバランスをより簡単に取ることができます。指定された最大スループットを超えるオンデマンドリクエストは制限されますが、最大スループット設定はアプリケーションの要件に基づいていつでも変更できます。オンデマンドの最大スループットは、新規および既存のシングルリージョンおよびマルチリージョンのテーブル（グローバルテーブル）、インデックス、および Amazon Simple Storage Service （Amazon S3）ワークフローからのテーブルの復元時とデータのインポート時にも設定できます。 この記事では、一般的なユースケースをいくつか紹介し、オンデマンドテーブルの最大スループットを実装して組織の目標を達成する方法を説明します。また、この機能が他の DynamoDB リソースとどのように連携するかについても説明します。 一般的なユースケース このセクションではオンデマンドテーブルの最大スループットを設定する一般的なユースケースについて説明します。 オ ンデマンドスループットコストの最適化 ：オンデマンドテーブルの最大スループットの値を柔軟に設定できるため、コストの予測と管理がさらに高まり、お客様はさまざまなワークロード要件や予算に基づいて、本番環境と開発環境全体でサーバレスエクスペリエンスをより幅広く採用できるようになります。 コスト急増の防止 ：オンデマンドテーブルに最大スループットを事前に定義しておくことで、チームは最適化されていないコードや不正なプロセスから発生する可能性のある読み取りまたは書き込み量の偶発的な急増を防ぐことができます。この対策により、アプリケーション開発の初期段階や非生産的な環境であっても、コストへの影響を適切に管理することができます。 API使用量の管理 ：お客様がプロビジョニングされたキャパシティからオンデマンドモードに切り替えるシナリオでは、オンデマンドスループットの上限消費しきい値を設定することで、予期せずテーブルに対して実行できるワークロードトラフィック量にチームが不意を突かれることがないようにすることができます。これにより、組織が一定期間内でリソースを過剰に消費することを防ぎます。 ダウンストリームサービスの保護 ：お客様のアプリケーションにはサーバレスと非サーバレステクノロジーを含めることができます。サーバレスアーキテクチャの部分は需要に合わせてすぐに拡張されますが、キャパシティが固定化されたダウンストリームのコンポーネントは過負荷となる可能性があります。オンデマンドテーブルに最大スループットを設定することで、大量のイベントが複数のダウンストリームコンポーネントに伝播することによる予期しない副作用の発生することを防ぐことができます。 はじめに オンデマンドテーブルを作成すると、デフォルトでは、ワークロードに対する最大スループットの設定は有効になっていません。これは、テーブル毎、および関連するグローバルセカンダリインデックスに設定できるオプション機能です。これにより、読み取りと書き込み最大スループットを個別に設定して、特定の要件に基づいたアプローチを微調整できます。オンデマンドテーブルの最大スループットはベストエフォートで適用されるため、保証されたリクエスト上限ではなく目標として考える必要があります。 バーストキャパシティ が原因で、ワークロードが指定された最大スループットを一時的に超える可能性があります。この機能を使用するのに追加のコストはなく、 AWS コマンドラインインターフェース （AWS CLI）、 AWS マネジメントコンソール 、AWS SDK、または AWS CloudFormation を使用して開始することができます。 DynamoDB のコンソールを使用してオンデマンドテーブルの最大スループットを有効にするには、次の手順を実行します。 DynamoDB コンソールのナビゲーションペインで テーブル を選択します。 テーブルの作成 を選択します。 テーブルの名前、パーティションキー、およびソートキーを指定します。 テーブル設定 で、 設定をカスタマイズ を選択します。 読み取り/書き込みキャパシティの設定 には、 オンデマンド を選択します。 最大テーブルスループット で、読み取り、書き込み、またはその両方の制限を指定します (1 ～ 40,000 リクエストユニット)。 テーブルの作成 を選択します。 また、CLI、SDK、または AWS CloudFormation を使用して、 MaxReadRequestUnits と MaxWriteRequestUnits を含む OnDemandThroughput パラメータを使用して、テーブルまたはインデックスのオンデマンド最大スループットを設定することもできます。これらのパラメータを使用すると、 1 〜 AccountMaxTableLevelReads または AccountMaxTableLevelWrites の有効範囲内で、読み取りと書き込みの最大単位を指定できます。値を -1 に設定すると制限が無効になるため、オンデマンドテーブルのスループット制限を必要としないシナリオに柔軟に対応できます。 テーブルとインデックスの最大スループット設定を個別に構成できる柔軟性があります。さらに、特定の要件に基づいて、これらの設定を読み取り、書き込み、またはその両方に選択的に適用できます。ベストプラクティスに従って、グローバルセカンダリインデックスの最大スループット設定は関連するテーブルの最大スループット設定と一致させることをお勧めします。これは、グローバルセカンダリインデックスがテーブルに書き込まれたデータを効果的に複製できるようにするために MaxWriteRequestUnits において特に重要となります。 次の例は、CLI を使用してテーブルとインデックスのオンデマンド最大スループットを設定する方法を示しています。 aws dynamodb create-table \ --table-name MusicCollection \ --attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S AttributeName=Genre,AttributeType=S \ --key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --on-demand-throughput MaxReadRequestUnits=500,MaxWriteRequestUnits=1000 \ --global-secondary-indexes \ "[ { \"IndexName\": \"My-Index\", \"KeySchema\": [ {\"AttributeName\":\"Genre\",\"KeyType\":\"HASH\"}, {\"AttributeName\":\"SongTitle\",\"KeyType\":\"RANGE\"} ], \"Projection\": { \"ProjectionType\":\"INCLUDE\", \"NonKeyAttributes\":[\"Artist\"] }, \"OnDemandThroughput\": { \"MaxReadRequestUnits\": 500, \"MaxWriteRequestUnits\": 1000 } } ]" { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "Genre", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "CREATING", "CreationDateTime": 1704890776.114, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "26b92833-aaf5-4e66-9d30-283d066785a7", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST" }, "GlobalSecondaryIndexes": [ { "IndexName": "My-Index", "KeySchema": [ { "AttributeName": "Genre", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "Projection": { "ProjectionType": "INCLUDE", "NonKeyAttributes": [ "Artist" ] }, "IndexStatus": "CREATING", "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "IndexSizeBytes": 0, "ItemCount": 0, "IndexArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/index/My-Index", "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } グローバルテーブル オンデマンドモードの最大スループットを設定してグローバルテーブルの容量を管理できます。これは ProvisionedThroughput と同様のセマンティクスに従います。１つのグローバルテーブルレプリカで読み取りまたは書き込み（あるいはその両方）の最大スループット設定を指定すると、同じ最大スループット設定がすべてのレプリカテーブルに自動的に適用されます。データを適切にレプリケーションするためには、グローバルテーブル内のレプリカテーブルとセカンダリインデックスに同一の書き込みスループット設定がされていることが重要です。 UpdateTable API に導入された OnDemandThroughputOverride パラメーターを使用すると、レプリカごとに個別の読み取り制限を設定できるため、他のレプリカ設定から柔軟に独立できます。グローバルテーブルのキャパシティ設定について詳しくは、 グローバルテーブルを管理するためのベストプラクティスと要件ガイド を参照してください。 次の例は、CLI を使用してグローバルテーブルレプリカの MaxReadRequestUnits のオーバーライドを追加する方法を示しています。 aws dynamodb update-table \ --table-name MusicCollection \ --replica-updates '[ { "Create": { "RegionName": "us-west-2", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } } ]' { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "UPDATING", "CreationDateTime": 1710345744.514, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "4219b238-c3d4-472e-aba3-82ac4e5554ce", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST", "LastUpdateToPayPerRequestDateTime": 1710345744.514 }, "StreamSpecification": { "StreamEnabled": true, "StreamViewType": "NEW_AND_OLD_IMAGES" }, "LatestStreamLabel": "2024-03-13T16:03:49.907", "LatestStreamArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/stream/2024-03-13T16:03:49.907", "GlobalTableVersion": "2019.11.21", "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE" } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } テーブルの更新が完了すると、 DescribeTable 応答には読み取り用のオーバーライドされた値が含まれるようになります。 … "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } ] … S3 ワークフローからの復元とインポート DynamoDB のバックアップと復元機能は、オンデマンドの最大スループットもサポートします。バックアップは作成時のスループット設定を保持し、手動で上書きしない限り、復元時に新しいテーブルに適用されます。 ImportTable を使用して Amazon S3 からデータをインポートする場合、 CreateTable オペレーションで提供される柔軟性と同様に、オンデマンドの最大スループット制限を指定するオプションがあります。 復元またはインポートに OnDemandThroughput を指定しても、これらの操作の実行時間には影響しません。 モニタリング、アラートおよびトラブルシューティング オンデマンドテーブルの最大テーブルスループットを指定する前に、ワークロードとトラフィックを理解することが重要です。AWS には、アプリケーションのモニタリングと理解に役立つさまざまなサービスがあります。たとえば、 Amazon CloudWatch はログ、メトリックス、イベントとしてモニタリングデータを収集し、AWS のリソース、アプリケーション、サービスを一元的に把握できるようにします。 アプリケーションを効果的にモニタリング することで、アプリケーションの通常の状態を把握できます。ワークロードを理解したら、レート制限に最適なテーブルを判断できます。モニタリングを簡素化にするために、CloudWatch は OnDemandMaxReadRequestUnits と OnDemandMaxWriteRequestUnits のメトリクスを提供しています。これらのメトリックスは５分間隔で発行され、 ProvisionedReadCapacityUnits と ProvisionedWriteCapacityUnits のメトリクスの頻度と一致します。 オンデマンドテーブルの最大スループットはベストエフォートベースで適用されるため、保証されたリクエストの上限ではなく目標として考える必要があります。バーストキャパシティが原因で、ワークロードが指定された最大スループットを一時的に超える可能性があります。場合によっては、DynamoDB はバーストキャパシティーを使用して、テーブルのスループット設定を超える読み取りまたは書き込みに対応します。バーストキャパシティーを使用すると、スロットリングされていた可能性のある予期しない読み込みまたは書き込みリクエストに対して一時的に対応できます。詳細については、 バーストキャパシティを効果的に使用する を参照してください。 アプリケーションがオンデマンドテーブルに設定した最大読み取りまたは書き込みスループットを超えると、DynamoDB は ThrottlingException メッセージで示されるように、これらのリクエストのスロットリングを開始し、システムが事前に設定されたスループット設定を準拠していることを示します。オンデマンドの最大スループット制限を超えてスロットリングした場合、「Throughput exceeds the maximum OnDemandThroughput configured on table or index」というメッセージが返されます。例外メッセージはこの機能専用のもので、スロットリングしているインスタンスをすばやく識別するために機能します。DynamoDB の例外に関する詳細については、 DynamoDB でのエラー処理 を参照してください。 まとめ この記事では、オンデマンドテーブルの最大スループットを設定して、不要な DynamoDB スループットコストの暴走を回避し、ダウンストリームアプリケーションへの影響を抑える方法を示しました。この機能を使用するのに追加コストはかかりません。AWS マネジメントコンソール、AWS CLI、AWS SDK、DynamoDB API、または AWS CloudFormation を使用して開始できます。詳細については、 DynamoDB 開発者ガイド を参照してください。 著者について Lee Hannigan は、アイルランドのドニゴールを拠点とするシニア DynamoDB スペシャリストソリューションアーキテクトです。ビッグデータと分析テクノロジーの強固な基盤に支えられた分散システムに関する豊富な専門知識を持っています。DynamoDB スペシャリストソリューションアーキテクトとして、 DynamoDB の機能を活用したワークロードの設計、評価、最適化に関してお客様を支援することに優れています。 Mazen Ali は AWS の Amazon DynamoDB のプリンシパルプロダクトマネージャーで、ニューヨーク市を拠点としています。プロダクトマネジメントとテクノロジー関連の分野で豊富な経歴を持ち、お客様の要件を理解し、プロダクト戦略を定義し、クロスファンクショナルチームと協力して魅力的なエクスペリエンスを構築することに情熱を注いでいます。仕事以外では、旅行、読書、スキー、ハイキングを楽しんでいます。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2024 年 8 月のアップデート まとめはいかがでしたでしょうか。今月はアップデート以外に、開発者向けに Amazon Connect のスキルアップに役立つトレーニングをお知らせいたします。 それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートとトレーニングについて 2024 年 9 月のアップデート一覧 AWS Contact Center Blog のご紹介 AWS Black Belt Online Seminar のご紹介 1.注目のアップデートとトレーニングについて 注目#1 Amazon Connect Developer Learning & Badge Plan (Amazon Connect の新しい学習プランが公開) 2024年8月に、学習プランの1つ目として、コンタクトセンターのエンジニア、通信エンジニア、IVR エンジニア、テレフォニー管理者を対象とした Amazon Connect Communications Specialist を公開しました。ここでは、テレフォニー、IVR、フロー、ルーティング、オムニチャネルデプロイ、および AWS サービスとの統合を学ぶことができます。そして2024年9月に、2つ目の学習プランとして、Amazon Connect 開発者向けに特別に作成された Amazon Connect Developer Learning を公開しました。Amazon Connect のコア開発コンセプト、ビジネスユースケースに適した Amazon Connect の統合手法、Amazon Connect のフロントエンドやバックエンドの統合、AWS CloudFormation と AWS CDK を使用した Amazon Connect のソリューションをデプロイする方法を学ぶことができます。 このカリキュラムを修了し、ナレッジチェックを 80% 以上のスコアで合格すると、 Amazon Connect Developer Specialist デジタルバッジが Credly のプラットフォームを介して AWS から提供されます。これはクラウドスキルや経験を伝えるために役立てることができます。 このトレーニングは無償で利用可能で、現在は英語で提供しています。学習には AWS Skill Builder のアカウントが必要です。 注目#2 Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens がエージェントのパフォーマンス評価を自動化する新しい方法をサポート) Amazon Connect Contact Lens のパフォーマンス評価機能で、会話から得たインサイト(検出された問い合わせ理由など)に基づいて、パフォーマンス評価の質問を自動的に該当なしとしてマークできるようになりました。また、最長保留時間、保留数、エージェントの対話および保留時間などの追加のメトリクスを使用して、評価フォームに質問への回答を自動的に入力できるようになりました。これにより、例えば、アカウントを開設するために電話をかけてきた顧客のみを対象として、エージェントが新しいアカウントのメリットと価格を説明したかどうかを確認できます。さらに、エージェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操作により顧客を待たせなかったかどうかなどを自動的に評価できます。 パフォーマンス評価の自動化は、評価フォームで以下の設定を実施します。 評価フォーム内のすべての質問に対してオートメーションを設定します。メトリクスを使用するには、評価フォームの「スコアと重み」タブで「スコアリングの有効化」をオンにします。 評価フォームを有効にする前に [完全自動評価を有効にする] をオンにします。 2. 2024年9月のアップデート一覧 Amazon Connect expands AWS CloudFormation support for agent hierarchies (Amazon Connect がエージェント階層向けの AWS CloudFormation のサポートを拡大) – 09/14/2024 AWS CloudFormation を使用したエージェント階層構造の設定が可能になりました。CloudFormation テンプレートを活用すると、Amazon Connect の階層レベルを安全で効率的な方法で、かつ同じ設定を繰り返し実行できるようにデプロイできるため、手動設定に伴う人為的ミスのリスクが軽減されます。CloudFormation を使えば、時間とともに生じる設定の変更を追跡し、自動的かつ管理された方法で更新を適用することも可能です。また、バージョン管理機能によって必要に応じて変更をすぐにロールバックできます。CloudFormation のエージェント階層向けサポートは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド AWS CloudFormation ユーザーガイド ( AWS::Connect::UserHierarchyGroup / AWS::Connect::UserHierarchyStructure ) Amazon Connect launches AWS CloudFormation support for agent status (Amazon Connect がエージェントステータスに関する AWS CloudFormation のサポートを開始) – 09/14/2024 ルーティングプロファイル、キュー、Amazon S3 バケット、AWS Lambda などのコンタクトセンター設定に使用されるリソースに加えて、エージェントステータスも AWS CloudFormation でサポートされるようになりました。CloudFormation テンプレートを使用すると、Amazon Connect のカスタムエージェントステータスを安全で効率的な方法で、かつ同じ設定を繰り返し実行できるようにデプロイできます。これにより、設定を一貫して維持することができます。CloudFormation を使えば、時間とともに生じる設定の変更を追跡し、自動的かつ管理された方法で更新を適用することも可能です。また、バージョン管理機能によって必要に応じて変更をすぐにロールバックできます。CloudFormation のエージェントステータス向けサポートは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド AWS CloudFormation ユーザーガイド ( AWS::Connect::AgentStatus ) Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens がエージェントのパフォーマンス評価を自動化する新しい方法をサポート) – 09/06/2024 Amazon Connect Contact Lens のパフォーマンス評価機能で、会話から得たインサイト(検出された問い合わせ理由など)に基づいて、パフォーマンス評価の質問を自動的に該当なしとしてマークできるようになりました。また、最長保留時間、保留数、エージェントの対話および保留時間などの追加のメトリクスを使用して、評価フォームに質問への回答を自動的に入力できるようになりました。今回のリリースでは、特定の条件下で該当する評価質問についてのみ、自動的に入力できます。例えば、アカウントを開設するために電話をかけてきた顧客のみを対象として、エージェントが新しいアカウントのメリットと価格を説明したかどうかを確認できます。さらに、エージェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操作により顧客を待たせなかったかどうかを自動的に評価できます。これらの新機能により、パフォーマンス評価の自動化と精度の向上を期待できます。この機能は、Contact Lens のパフォーマンス評価が既に利用可能なすべてのリージョンで利用できます。 関連リンク 管理者ガイド (自動評価を送信するルールを作成) 管理者ガイド (自動評価フォームを作成) Release Notes Amazon Connect now provides a weekly view of agent schedules (Amazon Connect でエージェントのスケジュールの週次ビューが使用可能に) – 09/04/2024 予測、キャパシティプランニング、およびエージェントスケジューリングにおけるスケジュール機能で、エージェントのスケジュールの週次ビューが提供されるようになりました。これにより、コンタクトセンターのマネージャーは1週間分の人員配置を一目で把握しやすくなりました。今回のリリースにより、サービスレベル、占有率、予測時間と予定時間などの毎日集計されるメトリクスによって、必要なカバレッジが毎日提供されていることを確認できるようになりました。例えば、週次ビューから、水曜日に人員超過が発生し、金曜日に人員不足が発生しているかどうかを簡単に確認できます。そして、週次ビュー内でエージェントのシフトを水曜日から金曜日に移動できます。週次ビューでは、エージェントが毎日適切なシフトになっていること(各エージェントが8時間のシフトになっていることなど)、連続して働いている日数が多すぎないこと(各エージェントが毎週少なくとも2日間休暇を取っていることなど)の確認も簡単に行えます。週次ビューでは、エージェントのシフトを日々管理するのに費やす時間を短縮することにより、マネージャーの生産性が向上し、複数の日々の人員配置を単一のビューで確認しやすくなります。この機能は、Amazon Connect の予測、キャパシティプランニング、およびエージェントスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect now offers intraday forecasts (Amazon Connect が日内予測の提供を開始) – 09/04/2024 予測、キャパシティプランニング、スケジューリング機能の一部として、機械学習を活用した日内予測をダッシュボードで確認できるようになりました。日内予測では、15 分ごとに更新されるキューの平均応答時間、コンタクト件数、平均処理時間の将来の予測データを参照することができます。これらの予測結果を確認することで、1 日を通してキューのデータが推移するかを監視し、顧客の待ち時間やサービスレベルを改善するための対策を積極的に講じることができます。例えばコンタクトセンター管理者は、コンタクト件数が予想レベルを下回った場合、日内予測を使用してその落ち込みがいつまで続くかを特定し、必要な人員配置レベルを決定し、残りのエージェントをバックオフィス業務や他の件数の多いキューにシフトさせることができます。この機能は、Amazon Connect の予測、キャパシティプランニング、およびエージェントスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens can now generate transcriptions in 10 new languages (Amazon Connect Contact Lens で 10 の新しい言語で文字起こしが生成可能に) – 09/04/2024 Amazon Connect Contact Lens は、カタロニア語 (スペイン)、デンマーク語 (デンマーク)、オランダ語 (オランダ)、フィンランド語 (フィンランド)、インドネシア語 (インドネシア)、マレー語 (マレーシア)、ノルウェー語 (ブークモール) (ノルウェー)、ポーランド語 (ポーランド)、スウェーデン語 (スウェーデン)、タガログ語/フィリピン語 (フィリピン) を含む 10 の新しい言語で文字起こしをサポートします。今回のリリースにより、Contact Lens 会話分析では 33 の言語の文字起こしがサポートされます。 関連リンク Amazon Connect Contact Lens について 管理者ガイド 3. AWS Contact Center Blog のご紹介 エージェントワークスペースで機微情報を扱う方法 (日本語翻訳) コンタクトセンターのエージェントは、複雑なワークフローを伴うトピックでもお客様をサポートしています。 Amazon Connect エージェントワークスペース 内のステップバイステップガイドは、特定のユースケースを処理する方法をエージェントに明確な手順として示します。ステップバイステップガイドはエージェント向けのワークフローで、エージェントの選択に基づいて分岐したり、外部システムとデータを送受信したりできます。ステップバイステップガイドはエージェントの生産性を高め、トレーニング時間を短縮し、一貫したカスタマーエクスペリエンスの提供を支援します。このようにステップバイステップガイドを操作する際、エージェントは機密データや極秘データを収集・入力することも頻繁にあります。そのようなデータは、通話ログや画面録画に記録されるべきではありません。 このブログ記事では、特定のステップバイステップガイドが呼び出されたときに自動的に録画を一時停止し、ワークフローが完了したら録画を再開するソリューションについて詳しく説明します。このソリューションでは、ワークフロー区間中の記録を自動的に停止する方法についても説明しています。 Integrate your AI-powered IVR/IVA for seamless customer interactions with Amazon Connect (英語記事) コンタクトセンターの運用において、ユーザーエクスペリエンスとエージェントの生産性を向上させるため、生成 AI を活用することが考えられます。近年、エージェントアシストやインテリジェントボットなどの機能が注目を集めているのは、このようなコンタクトセンターの AI 支援型への変化を推進する流れによるものです。多くのお客様は既に、対話型音声応答 (IVR) や知的バーチャルアシスタント (IVA) を主要なカスタマーサポートチャネルとして活用し、解決時間の短縮と業務効率の最適化を図っています。そして、AI 駆動のカスタマー・インタラクションと人間のエージェントによるインタラクションのシームレスな統合を求める企業が増えています。本ブログ記事では、企業が AI 駆動の IVR システムや IVA と Amazon Connect をシームレスに統合することで、カスタマーエクスペリエンスをさらに向上させる方法について紹介します。また、そのような統合によるメリットや、AI 駆動のアシスタントとエージェントの間のシームレスな会話の引き継ぎを可能にするアーキテクチャパターンについても深掘りします。 Frost Radar recognizes AWS as a 2024 Leader for Contact Center as a Service in APAC and EMEA (英語記事) 2024年の Frost Radar レポートでは、アジア太平洋 (APAC) 地域およびヨーロッパ、中東、アフリカ (EMEA) 地域におけるコンタクトセンターサービス (CCaaS) 市場で、Amazon Web Services(AWS) がリーダーとして評価されています。このレポートでは、 Amazon Connect の継続的な革新と成長が高く評価されています。両レポートでは、Amazon Connect のクラウドネイティブなアーキテクチャ、高度な機能、そしてグローバルに高可用かつ拡張性のある通話ネットワークが、市場トレンドの変化に適応した事が成長できた主要な要因として取り上げられています。APAC の Frost Radar レポートでは、人工知能 (AI)、分析、機械学習 (ML)、自然言語処理 (NLP) の最新技術を活用して Amazon Connect が絶え間なく進化している取り組みが高く評価されています。また、顧客中心のイノベーション手法にも注目が集まっており、Amazon Connect の新機能の95%が顧客からのフィードバックに基づいて開発されていることが強調されています。Frost & Sullivan のアジア太平洋情報通信技術ディレクターである Krishna Baidya 氏は、「 AWS は Amazon Connect の AI 駆動のイノベーションによってアジア太平洋のクラウドコンタクトセンター市場をリードしており、顧客中心のアプローチと業界特化型ソリューションにより、デジタルトランスフォーメーションのパートナーとして位置付けられています」と述べています。本ブログ記事では、Frost Radar レポートが示す Amazon Connect の革新性と成長について詳しく紹介しています。 4. AWS Black Belt Online Seminar のご紹介 Amazon Connect のユーザー管理 (Amazon Connect 再入門シリーズ) ( PDF | YouTube ) Amazon Connect インスタンスを設定する際は、事前に Amazon Connect のユーザー管理方法を決定する必要があります。ユーザーとは、Amazon Connect アカウントを必要とするすべての人 (エージェント、コールセンターマネージャー、アナリストなど) のことです。本セッションでは Amazon Connect のユーザー管理の全体像について紹介し、Amazon Connect で利用できる ID 管理方式や、ユーザー管理に関連した各種機能、セキュリティ面からの注意点について解説します。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 10 月 31 日 (木) 14:00-18:00 に、 AWS AI Day を開催します。物理的に来場する点に加えて、ライブ配信での視聴が事前登録できるようになりました。現地では、QuizKnock が審査員を行う AI ハッカソン決勝戦、展示ブース、スピーカーと会話ができる Ask a Speaker の場があるため、可能でしたら来場いただいたほうが良いですが、お時間の都合で難しい場合は、ライブ配信をご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年9月30日週の主要なアップデート 9/30(月) Amazon Aurora MySQL で RDS Data API のサポート Amazon Aurora MySQL で RDS Data API をサポートしました。これにより、MySQL のコネクションを管理する必要なく、AWS SDK や API 経由で SQL ステートメントを実行できるようになりました。Aurora MySQL では Serverless v1 のみサポートしていましたが、これが Serverless v2、Provisioned で利用可能になった形です。コネクションプーリングを Data API 側で管理をしてくれるため、例えば Lambda からの接続がやりやすくなるメリットがあります。Aurora MySQL の 3.07 以降のバージョンで Data API をサポートしています。 AWS CloudShell で VPC 連携、Docker 対応、起動時間の高速化など最新機能を全リージョンでサポート AWS CloudShell で、VPC のサポート、起動時間の改善、Docker サポートといった最新機能をすべての商用リージョンでサポート開始しました。これらの機能は、CloudShell の一部のリージョンで利用可能でしたが、今回のアップデートですべての商用リージョンで提供開始になりました。CloudShell の VPC サポートにより、VPC 内にCloudShell 環境を作成できるようになりました。また、Docker 統合により、CloudShell の環境で Docker を扱えるようになり、コンテナの開発やデプロイが可能となりました。 AWS re:Post で生成 AI バーチャルアシスタント機能の追加 AWS re:Post と呼ばれる、Q&A コミュニティがあります。AWS のお客様、パートナー、AWS の従業員が参加しており、オンラインコミュニティを通じてエキスパートの回答を得られる仕組みがあります。今回のアップデートで、AWS re:Post に投稿した質問に、生成 AI を活用したバーチャルアシスタントが回答を提供してくれるようになりました。質問を投げた直後に回答が得られるため、一般的な技術ガイダンスをすばやく確認できます。場合によってはハルシネーションが発生することがあり、正確性を精査する必要がありますが、回答までの待ち時間をショートカットでき、便利にご活用いただけます。 10/1(火) Amazon Redshift で RA3.large インスタンスの提供開始 Amazon Redshift で、新たに小さなインスタンスタイプの RA3.large (2 vCPU と 16 GiB メモリ) を提供開始しました。RA3 世代は、コンピュートとストレージが分離されており、それぞれ個別にスケールを変更できる柔軟性があります。加えて、データシェアリング、Zero-ETL、マルチ AZ といった機能を利用できます。RA3 世代の中で一番小さいインスタンスサイズは、ra3.xlplus (4 vCPU と 32 GiB メモリ) でしたが、より小さいインスタンスがサポートされ、ワークロードにあわせた最適なリソースを構築しやすくなりました。 Amazon ElastiCache でリザーブドノードのサイズ柔軟性をサポート Amazon ElastiCache でリザーブドノードのサイズ柔軟性をサポートしました。これまでは、特定のノードタイプ (例 : cache.r7g.xlarge) を指定してリザーブドノードを購入し、指定したタイプでのみ割引が提供される方式でした。このアップデートで、購入したノードタイプに設定されているレートに基づき、同じノードファミリーに所属する他のノードタイプに自動的に割引が適用されるようになりました。例えば、r7g.xlarge ノードを購入し、r7g.2xlarge のより大きなノードにスケールアップをした場合、r7g.2xlarge ノードの 50% の使用量に対して、割引レートが自動的に適用されます。詳細は こちらのブログ をご確認ください。 AWS Incident Detection and Response で日本語対応のサポート AWS Incident Detection and Response サービスで、日本語でのインシデント対応をサポートしました。AWS Incident Detection and Response は、AWS Enterprise Support をご利用いただいているお客様を対象に、プロアクティブな対応とインシデント管理を提供するサービスです。インシデント管理エンジニア (IME) が、24 時間 365 日体制で、お客様のワークロードからのアラームを 5 分以内に検知して対応を行い、緩和と復旧のためのガイドをお客様に提供します。従来は英語のみのサポートでしたが、このアップデートで日本語を話す IME とコミュニケーションができるようになりました。ミッションクリティカルで重要なシステムに活用することで、問題が発生したときに迅速な対応がしやすくなります。利用を進める際には、担当営業にご確認ください。詳細は Document や FAQ をご覧ください。 10/2(水) Amazon AppStream 2.0 で自動タイムゾーン変更機能を提供 Amazon AppStream 2.0 で、アプリケーションおよびデスクトップストリーミングセッションにおいて、自動タイムゾーン変更機能を有効にできるようになりました。この新機能により、例えば、クライアントデバイスが日本語のタイムゾーンとなっている場合、アクセス先の AppStream 2.0 の環境においても、タイムゾーン、言語、入力方法が自動的に日本語タイムゾーンに基いて調整されます。この機能を利用するためには、2024 年 9 月 18 日以降にリリースされた AppStream 2.0 エージェントが含まれるイメージを使用する必要があります。 Amazon AppStream 2.0 のマルチセッションフリートで、プリンターリダイレクトとユーザーが選択した地域設定が利用可能 Amazon AppStream 2.0 のマルチセッションフリートで、ローカルプリンターリダイレクトとユーザー選択の地域設定をサポートしました。これらの機能はすでにシングルセッションフリートで利用可能でしたが、今回のローンチによりマルチセッションフリートにも拡張された形です。ローカルプリンターリダイレクトにより、ユーザーはストリーミングアプリケーションから印刷ジョブをローカルコンピューターに接続されたプリンターにリダイレクトできます。なお、AppStream 2.0 ストリーミングインスタンスにプリンタードライバーをインストールする必要はありません。 10/3(木) Amazon Aurora Serverless v2 で最大 256 ACU が利用可能に Amazon Aurora Serverless v2 で、最大 256 Aurora Capacity Unit (ACU) をサポートするようになりました。Aurora Serverless v2 は、オートスケールの仕組みがあり、最小、最大の ACU を指定する中で、ワークロードに合わせて自動的にオートスケールできます。1 ACU は、約 2 GiB のメモリと、それに対応する CPU、ネットワークリソースが提供されます。元々は、128 ACU が最大でしたが 256 ACU までサポートされるようになり、よりリソースが要求されるワークロードに適用しやすくなりました。 AWS Glue インタラクティブセッションでオートスケールの一般提供開始 AWS Glue のインタラクティブセッションでオートスケール機能の一般提供を開始しました。AWS Glue インタラクティブセッションは、AWS Glue のジョブ開発を効率化するためのサーバーレス機能です。Jupyter 互換のノートブックや PyCharm、IntelliJ、VS Code などの IDE を使用して、リモートの Apache Spark ランタイム環境にアクセスできます。今回のアップデートで、Glue バージョン 3.0 以上の AWS Glue インタラクティブセッションで、ワークロードに基づいてリソースを動的に拡大縮小できるようになりました。自動スケーリングにより、セッションのリソースを過剰にプロビジョニングしたり、ワーカー数の最適化に時間を費やしたり、アイドル状態のワーカーに対して支払いをしたりする心配がなくなります。 10/4(金) Amazon Workspaces で、ローカルデバイス間とのファイル転送機能を提供開始 Amazon WorkSpaces は、WorkSpaces パーソナルセッションとローカルコンピュータ間のファイル転送をサポートしました。従来は S3 や FSx などの他のサービスを経由してファイル転送を実現していましたが、直接のファイル転送ができるようになり、より利便性が向上しました。ファイル転送機能は、デフォルトでは無効化されており、グループポリシーを変更することでファイル転送機能を有効化できます。詳細は こちら をご覧ください。 Amazon EC2 でインスタンス作成後に vCPU の数変更やハイパースレッディングの無効化が可能に Amazon EC2 でインスタンス起動後に、CPU オプションを変更できるようになりました。停止中の EC2 インスタンスを対象に、vCPU 数の変更やハイパースレッディングの無効化が可能になり、ライセンスコストを削減できる場合があります。どのように費用が変わるかはライセンスによりますので、詳細はライセンス元などにご確認ください。この機能はすべての商用リージョンで利用可能です。詳細は こちらのドキュメント を参照ください。 AWS Application Composer は AWS Infrastructure Composer に名称変更 AWS Application Composer が AWS Infrastructure Composer に名称変更しました。re:Invent 2022 でローンチ以来、シンプルなドラッグアンドドロップインターフェースによって、サーバーレスアプリケーションアーキテクチャの構成を提供していました。ローンチ以降、CloudFormation リソースへのサポートを拡大し、お客様が必要とするアーキテクチャを構築できる選択肢が広がり、よりわかりやすく AWS Infrastructure Composer という名称に変更しました。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

9 月 25 日、 Amazon Elastic Compute Cloud (Amazon EC2) の C8g および M8g インスタンスの一般提供についてお知らせします。 C8g インスタンスは、 AWS Graviton4 ベース で、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、ゲーム、動画エンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習 (ML) 推論、広告配信など、コンピューティングを多用するワークロードに適しています。 同じく Graviton4 ベースの M8g インスタンスは、汎用ワークロードにおいて優れたコストパフォーマンスを実現します。アプリケーションサーバー、マイクロサービス、ゲームサーバー、中規模データストア、キャッシュフリートなどのアプリケーション向けのインスタンスです。 これらの 2 つのインスタンスにおける改善点をいくつか見てみましょう。C8g および M8g インスタンスは、同等の 7g インスタンスと比較して、最大 3 倍の vCPU (最大 48xl)、3 倍のメモリ (C8g で最大 384 GB、M8g で最大 768 GB)、75% 増のメモリ帯域幅、2 倍の L2 キャッシュを実現します。これにより、大量のデータの処理、ワークロードのスケールアップ、結果が出るまでの時間の短縮、総保有コスト (TCO) の削減を実現します。また、Graviton3 ベースのインスタンスが最大 30 Gbps のネットワーク帯域幅と最大 20 Gbps の Amazon Elastic Block Storage (Amazon EBS) 帯域幅 を提供するのに対して、これらのインスタンスは、最大 50 Gbps のネットワーク帯域幅と最大 40 Gbps の Amazon EBS 帯域幅を提供します。R8g インスタンスと同様、C8g および M8g インスタンスには、2 つのベアメタルサイズ (metal-24xl と metal-48xl) があります。インスタンスを適切なサイズに設定し、物理リソースへの直接アクセスからメリットを得るワークロードをデプロイできます。 C8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8g.medium 1 2 最大 12.5 最大 10 c8g.large 2 4 最大 12.5 最大 10 c8g.xlarge 4 8 最大 12.5 最大 10 c8g.2xlarge 8 16 最大 15 最大 10 c8g.4xlarge 16 32 最大 15 最大 10 c8g.8xlarge 32 64 15 10 c8g.12xlarge 48 96 22.5 15 c8g.16xlarge 64 128 30 20 c8g.24xlarge 96 192 40 30 c8g.48xlarge 192 384 50 40 c8g.metal-24xl 96 192 40 30 c8g.metal-48xl 192 384 50 40 M8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) m8g.medium 1 4 最大 12.5 最大 10 m8g.large 2 8 最大 12.5 最大 10 m8g.xlarge 4 16 最大 12.5 最大 10 m8g.2xlarge 8 32 最大 15 最大 10 m8g.4xlarge 16 64 最大 15 最大 10 m8g.8xlarge 32 128 15 10 m8g.12xlarge 48 192 22.5 15 m8g.16xlarge 64 256 30 20 m8g.24xlarge 96 384 40 30 m8g.48xlarge 192 768 50 40 m8g.metal-24xl 96 384 40 30 m8g.metal-48xl 192 768 50 40 便利なヒント AWS Graviton4 プロセッサは、常時オンのメモリ暗号化、すべての vCPU の専用キャッシュ、ポインター認証のサポートにより、セキュリティを強化します。 これらのインスタンスは、従来の仮想化機能の多くを専用ハードウェアとソフトウェアにオフロードする、多用なビルディングブロックの集合である AWS Nitro System 上に構築されています。AWS Nitro System は高パフォーマンス、高可用性、高セキュリティを実現し、仮想化のオーバーヘッドを削減します。 C8g および M8g インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションで実行される、マイクロサービスベースのコンテナ化されたアプリケーションを含む、すべての Linux ベースのワークロードに適しています。 今すぐご利用いただけます C8g および M8g インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。Amazon EC2 でのいつものお支払いと同様に、使用した分の料金のみをお支払いいただきます。詳細については、「 Amazon EC2 の料金 」を参照してください。アプリケーションを Graviton インスタンスタイプに移行する際に役立つ一連の AWS Graviton リソース をご覧ください。また、 AWS Graviton Fast Start プログラムにアクセスして Graviton の導入を開始することもできます。 詳細については、 Amazon EC2 インスタンスページ にアクセスしてください。また、 EC2 の AWS re:Post 、または通常の AWS サポートの担当者までフィードバックをぜひお寄せください。 –  Veliswa 原文は こちら です。

この記事は Migrating from AWS App Mesh to Amazon VPC Lattice (記事公開日: 2024 年 10 月 1 日) を翻訳したものです。 慎重に検討した結果、2026 年 9 月 30 日をもって AWS App Mesh のサポートを終了することを決定しました。この日まで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリソースの作成や新しいアカウントのオンボーディングなど、通常通りにサービスを利用できます。また、AWS はこの期間中も、AWS App Mesh にセキュリティと可用性に関する重要な更新を引き続き提供します。新規のお客様は、2024 年 9 月 24 日以降、AWS App Mesh にオンボーディングできなくなります。 マイクロサービスアーキテクチャの採用が進むにつれて、モダンな分散アプリケーションの複雑さを管理することが、多くの組織にとっての課題となっています。 Amazon VPC Lattice は、 re:Invent 2022 で発表 されたフルマネージドサービスで、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda 、 Amazon Elastic Compute Cloud (Amazon EC2) など、さまざまな AWS サービス間の通信の一貫した接続性、セキュリティ、監視を可能にします。 AWS App Mesh は、 Kubernetes クラスター内のサービスに高度なトラフィック管理と可観測性の機能を提供します。一方で VPC Lattice は、サイドカープロキシを管理する必要性をなくすことで、アプリケーションネットワーキングをシンプルにします。 本記事では、VPC Lattice が複雑な分散アプリケーションの管理をどのようにシンプルにできるかを探求し、App Mesh から VPC Lattice への移行に関する Amazon EKS のお客様へのガイダンスを提供します。 Amazon ECS で App Mesh を使用しているお客様は「 AWS App Mesh から Amazon ECS Service Connect への移行 」という記事をお読みいただくことをおすすめします。 App Mesh と VPC Lattice の比較 App Mesh と VPC Lattice はどちらもトラフィック管理とアプリケーション認識型ネットワーキングを提供しますが、基本的な概念とアーキテクチャが異なります。移行を開始する前に、これらの違いを理解することが重要です。 まず、リソースの論理的な境界線を提供するために、VPC Lattice には Service Network という概念があり、これは App Mesh の Service Mesh に相当します。 次に、VPC Lattice でアプリケーション内のマイクロサービスを表すには Service を作成します。これは App Mesh の Virtual Service に相当します。 VPC Lattice の Target Group は、App Mesh の Virtual Node と同じく、サービスを Kubernetes Pod グループに紐づけます。 最後に、VPC Lattice の Listener と Listener Rule は、App Mesh の Virtual Router と Route と似ています。これらは、Service 内の Target Group へのトラフィックルーティングを定義します。 以下の図は、各サービスの異なるコンポーネント間の比較を示しています。 App Mesh リソースの VPC Lattice のリソースへの変換 アーキテクチャ上、App Mesh はトラフィックルーティングのため、Pod ごとにサイドカーコンテナとして実行されるセルフマネージドの Envoy プロキシ に依存しています。 対照的に、VPC Lattice はマネージドなコントロールプレーンとデータプレーンを提供するため、Pod 内にコンポーネントを追加する必要はありません。可観測性のため、App Mesh はメトリクスを Amazon CloudWatch に転送する Amazon CloudWatch Agent with Prometheus Metrics Collection のインストールを必要とします。一方で VPC Lattice は、CloudWatch で ビルトインのメトリクス を提供します。 Amazon EKS 上で App Mesh を使用してアプリケーションを実行する場合、 Kubernetes Ingress 、 AWS Load Balancer Controller 、 App Mesh Virtual Gateway を使用してクラスター外部にアプリケーションを公開することが一般的です。 しかし、AWS アカウントや VPC をまたいでアプリケーションを公開するには、多くの場合 AWS Transit Gateway のような追加のネットワークリソースが必要です。 VPC Lattice は、ロードバランシングと AWS Resource Access Manager (RAM) を組み込むことで、この問題をネイティブに解決します。これにより、異なる AWS アカウントで実行されている他の AWS リソースから Kubernetes の Service にアクセスできるようになります。 さらに、VPC Lattice は Kubernetes リソースを VPC Lattice オブジェクトに紐づける Gateway API を実装しています。 加えて、VPC Lattice は 認証ポリシー によって AWS Identity and Access Management (IAM) 認証をサポートし、マイクロサービス間の大まかな粒度での認可を実現します。 料金設定については、App Mesh では Envoy プロキシの追加のコンピュートリソースに対してのみ料金が発生します。しかし 、VPC Lattice のコストは、プロビジョニングされたサービスの数、各サービスへのトラフィックのデータ処理料金、各サービスが受信する HTTP リクエストの数 (HTTP/HTTPS リスナーのみ) に基づいて決定されます。 詳細は、VPC Lattice の 料金ページ をご覧ください。 移行戦略 App Mesh から VPC Lattice へのアプリケーションの移行時には、 インプレース 、 カナリア 、 Blue/Green など、複数の戦略から選択できます。適切な戦略は、ゼロダウンタイムの必要性やメンテナンスウィンドウを設定できるかどうかなど、アプリケーションの要件によって異なります。 インプレースでの移行戦略では、App Mesh で実装された既存の Kubernetes Pod を新しい Pod で置き換えます。このアプローチは、各 Pod が Envoy サイドカーコンテナを削除するために再起動されるので、移行中のダウンタイムを許容できるアプリケーションに適しています。 別の方法として Blue/Green デプロイ戦略では、VPC Lattice 用に構成された新しい Namespace にアプリケーションの 2 つ目のコピーをデプロイし、元のアプリケーションは App Mesh で運用を続けます。 このアプローチでは、両方の環境を同時に実行しながら、ダウンタイムなしで App Mesh から VPC Lattice にトラフィックを徐々に移行できます。 移行のウォークスルー このセクションでは、サンプルアプリケーションを App Mesh から Amazon VPC Lattice に移行するための手順の概要を、インプレース移行戦略を用いて説明します。 詳細な手順については、本記事の後半で説明します。 このウォークスルーで使うアプリケーションは、 Polyglot デモ と呼ばれる複数階層のデモアプリケーションです。このアプリケーションは次の 3 つのマイクロサービスで構成されています。 フロントエンド：商品カタログのユーザーインターフェース Product Catalog バックエンド：カタログに保存されているアイテムのリストを提供する REST API サービス Catalog Detail バックエンド：バージョン番号やベンダー名など、各アイテムの追加情報を提供する REST API サービス 次の図は Polyglot デモのフロントエンドのユーザーインターフェースを示しています。これには、異なるサービス間のトラフィックフローのアーキテクチャ図が含まれています。フロントエンドサービスは Product Catalog サービスを呼び出します。Product Catalog サービスは次に Catalog Detail サービスを呼び出します。 Product Catalog アプリケーションのアーキテクチャ 移行のステップ このセクションでは、App Mesh から VPC Lattice にアプリケーションを移行する際の主なステップについて説明します。 ステップ 1：Amazon EKS クラスターとサンプルアプリケーションのデプロイ はじめに、 eksctl を使用して今回のデモの基盤となる EKS クラスターを作成します。クラスターが作成されたら、App Mesh とVPC Lattice の機能を示すために、Polyglot デモアプリケーションをデプロイします。最後に、すべてが必要に応じて機能していることを確認するために、Polyglot デモアプリケーションのテストを実行します。 ステップ 2：App Mesh を使用してサンプルアプリケーションを設定する AWS App Mesh Controller と関連する Kubernetes カスタムリソース定義 (CRD) をインストールします。これらのコンポーネントにより、Kubernetes API を通じて App Mesh リソースを作成できます。 次に、App Mesh を使用して Polyglot デモアプリケーションを実装し、Virtual Service と Virtual Node を作成します。 現実のシナリオであることを強調するために、Product Catalog サービスの 2 つのバージョンをデプロイし、VPC Lattice への移行中にアクティブな Canary ロールアウトをデモンストレーションします。 最後に、アプリケーションをテストして、構成が正しいことを再確認します。 これで、この環境は移行を開始する準備ができました。 ステップ 3：VPC Lattice リソースを作成する AWS Gateway API Controller と関連する Kubernetes CRDをインストールします。App Mesh Controller と同様に、Kubernetes API を通じて VPC Latticeリソースを作成できるようになります。続いて、移行に必要な中心となる VPC Lattice コンポーネントを作成します。これには、 VPC Lattice Service Network にマッピングするクラスター内のVPC Lattice GatewayClass と Gateway 、サンプルアプリケーションのトラフィックルールを作成するための TargetGroupPolicy と HTTPRoute が含まれます。 ステップ 4：サンプルアプリケーションを VPC Lattice に移行する インプレースでの移行の場合、Envoy プロキシなどの既存の App Mesh コンポーネントを Pod から削除し、アプリケーションを新しい VPC Lattice エンドポイントで構成する必要があります。そのためにまず、Kubernetes Namespace にアノテーションを付与して、 App Mesh Controller が Pod を操作できない ようにします。次に、VPC Lattice エンドポイントを使うように、Polyglot デモアプリケーションを再デプロイします。最後に、Polyglot デモアプリケーションをテストして、VPC Lattice を通じて正しく機能することを確認します。 ステップ5：アプリケーションの公開とカナリアデプロイメントの実装 VPC Lattice では、アプリケーションへのトラフィックを許可するために Elastic Load Balancing (ELB) を使用する必要があります。このステップでは、App Mesh Virtual Gatewayを削除し、 AWS Load Balancer Controller で新しい Network Load Balancer を作成します。最後に、Product Catalog の 2 番目のバージョンを再デプロイし、VPC Lattice HTTPRoute を使用して、重み付けルーティングにより両方の Pod 間でトラフィックを分散します。 VPC Lattice リソースの確認 VPC Lattice から App Mesh への移行した後に、VPC Lattice に関連するさまざまなリソースがアカウントでプロビジョニングされ、 VPC Lattice コンソール で確認できます。 1. リソースの論理的な境界として VPC Lattice Service Network を作成しました。 AWS マネジメントコンソールで、Product Catalog Service Network を示すスクリーンショット 2. Kubernetes HTTPRoute を使って、アプリケーションの各階層に 1 つずつ、3 つの VPC Lattice Service を作成しました。 AWS コンソールでの、VPC Lattice Service のスクリーンショット 3. 3 つの VPC Lattice Target Group を作成し、各 VPC Lattice Service に 1 つずつアタッチしました。各Target Group のルーティングルールとヘルスチェックは、Kubernetes の TargetGroupPolicy リソースで設定しました。 AWS コンソールの VPC Lattice Target Group のスクリーンショット 4. 最後に、VPC Lattice を使って、サービスの HTTPRoute を更新することで、Product Detail マイクロサービスの 2 つのバージョン間でトラフィックを分散しました。以下の YAML スニペットのバックエンドルールは、アプリケーションの重み付けルーティングを示しています。 rules: - backendRefs: - name: proddetail namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 - name: proddetail2 namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 Bash 以下の図は、App Mesh から VPC Lattice に移行した後のアプリケーションのアーキテクチャを示しています。 VPC Lattice で実装された Polygot デモアプリケーション ハンズオンの手順 このサンプルの移行を再現するには、この GitHub リポジトリ のステップバイステップの説明をご覧ください。 まとめ 本記事では、分散アプリケーションのアプリケーションネットワーキングサービスである VPC Lattice を探求しました。App Mesh の機能・リソースと比較し、既存の App Mesh デプロイの移行戦略について説明しました。VPC Lattice は App Mesh と比較して、マルチアカウントネットワーキング、設定の簡素化、観測性の向上、その他の AWS サービスとのシームレスな統合といった、いくつかの利点を提供します。 詳細については、次の VPC Lattice のリソースとブログを参照してください。 ユーザーガイド API リファレンス FAQ 料金 クォータ Amazon VPC Lattice と Amazon EKS における AWS IAM 認証の実装 Amazon VPC Lattice を使用した、アプリケーションのためのセキュアなマルチアカウント・マルチ VPC 接続の構築 VPC Lattice と Pod Identity IAM セッションタグを使用した EKS クラスター間セキュア通信 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

7 月に、AWS は Llama 3.1 モデルが Amazon Bedrock で利用可能になったことをお知らせしました 。 生成 AI テクノロジーが驚くべきスピードで向上している中、今日は Amazon Bedrock で利用可能になった Meta からの新しい Llama 3.2 モデル をご紹介したいと思います。 Llama 3.2 は、 大規模言語モデル (LLM) における Meta の最新の進歩を象徴するマルチモーダルビジョンモデルと軽量モデルを提供し、強化された機能と、さまざまなユースケース全体へのより広範な適用性を実現します。 責任あるイノベーションとシステムレベルでの安全性 に重点を置くこれらの新しいモデルは、幅広い業界ベンチマークで最新鋭のパフォーマンスを実証し、新世代の AI エクスペリエンスの構築に役立つ機能を導入します。 これらのモデルは、画像推論でビルダーにインスピレーションを与えるように設計されており、エッジアプリケーションでも利用しやすいため、AI の可能性が広がります。 Llama 3.2 のモデルコレクションは、エッジデバイスに適したテキスト専用の軽量な 1B および 3B パラメータモデルから、高解像度画像のマルチモーダルサポートを含めた高度な推論タスクに対応できる小サイズと中サイズの 11B および 90B パラメータモデルまで、さまざまなサイズで提供されます。Llama 3.2 11B と 90B はビジョンタスクをサポートするための最初の Llama モデルで、画像エンコーダ表現を言語モデルに統合する新しいモデルアーキテクチャを備えています。新しいモデルは、低減されたレイテンシーと改善されたパフォーマンスで AI ワークロードをより効率的に行うように設計されているため、幅広いアプリケーションに適しています。 すべての Llama 3.2 モデルは、128,000 のコンテキスト長をサポートすることで、Llama 3.1 で導入されたトークン容量拡張を維持しています。さらに、これらのモデルは、英語、ドイツ語、フランス語、イタリア語、ポルトガル語、ヒンディー語、スペイン語、およびタイ語を含む 8 言語に対する強化された多言語サポートも提供します。 既存のテキスト対応の Llama 3.1 8B、70B、および 405B モデル に加えて、Llama 3.2 もマルチモーダルユースケースをサポートしています。今後は、Meta の 4 つの新しい Llama 3.2 モデルである 90B、11B、3B、および 1B を Amazon Bedrock で使用して、クリエイティブなアイデアを構築、実験、およびスケールできるようになります。 Llama 3.2 90B Vision (テキスト + 画像入力) – Meta の最先端モデルであり、エンタープライズレベルのアプリケーションに最適です。このモデルは、一般知識、長文テキスト生成、多言語翻訳、コーディング、数学、および高度な推論に秀でています。また、画像推論機能も導入するため、画像理解タスクやビジュアル推論タスクの実行が可能になります。このモデルは、画像キャプション生成、画像テキスト検索、ビジュアルグラウンディング、ビジュアル質問応答とビジュアル推論、およびドキュメントビジュアル質問応答などのユースケースに最適です。 Llama 3.2 11B Vision (テキスト + 画像入力) – コンテンツ作成、会話型 AI、言語理解、およびビジュアル推論を必要とするエンタープライズアプリケーションに最適です。このモデルは、テキスト要約、センチメント分析、コード生成、および指示への追随で優れたパフォーマンスを実証しており、画像について推論する追加機能もあります。このモデルのユースケースは 90B バージョンと似ており、画像キャプション生成、画像テキスト検索、ビジュアルグラウンディング、ビジュアル質問応答とビジュアル推論、およびドキュメントビジュアル質問応答などがあります。 Llama 3.2 3B (テキスト入力) – 低レイテンシーの推論を必要とし、計算リソースが限られているアプリケーション向けに設計されており、テキスト要約、分類、および言語翻訳タスクに優れています。このモデルは、AI 搭載のモバイルライティングアシスタントやカスタマーサービスアプリケーションなどのユースケースに最適です。 Llama 3.2 1B (テキスト入力) – Llama 3.2 のモデルコレクションの中で最も軽量なモデルであり、エッジデバイスやモバイルアプリケーションでの検索と要約に最適です。このモデルは、個人情報管理や多言語での知識検索などのユースケースに最適です。 また、Llama 3.2 はカノニカルなツールチェーンコンポーネントとエージェント型アプリケーションを構築するための標準化されたインターフェイスである Llama Stack 上に構築されているため、構築とデプロイがこれまでになく簡単になります。Llama Stack API アダプタとディストリビューションは、Llama モデルの機能を最も効果的に活用できるように設計されており、さまざまなベンダー全体で Llama モデルのベンチマークを行う能力をお客様に提供します。 Meta は、複数の言語にまたがる 150 を超えるベンチマークデータセットで Llama3.2 をテストし、人間による評価を大規模に実施して、他の主要基盤モデルとの競争力を備えたパフォーマンスを実証しました。では、これらのモデルが実際に機能する仕組みを見てみましょう。 Amazon Bedrock での Llama 3.2 モデルの使用 Llama 3.2 モデルの使用を開始するには、 Amazon Bedrock コンソール に移動して、ナビゲーションペインで [モデルアクセス] を選択します。そこで、新しい Llama 3.2 モデルである Llama 3.2 1B、3B、11B Vision、および 90B Vision へのアクセスをリクエストします。 新しいビジョン機能をテストするため、別のブラウザタブを開いて、 Our World in Data ウェブサイト から Share of electricity generated by renewables グラフを PNG 形式でダウンロードしました。グラフの解像度は非常に高いため、サイズを 1024 ピクセル幅に変更します。 Amazon Bedrock コンソールに戻り、ナビゲーションペインの [プレイグラウンド] で [チャット] を選択し、カテゴリとして [Meta] を選択してから、 [Llama 3.2 90B Vision] モデルを選択します。 [ファイルを選択] を使用してサイズ変更されたグラフ画像を選択し、以下のプロンプトを使用します。 Based on this chart, which countries in Europe have the highest share? [実行] を選択すると、モデルが画像を分析して結果を返します。 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK を使用して、プログラム的にモデルにアクセスすることもできます。Llama 3.1 モデルを使用するときと違い、今回は ドキュメントの記述どおりにモデル ID を更新 するだけで済みます。また、米国および EU リージョン用の新しい クロスリージョン推論エンドポイント も使用できます。これらのエンドポイントは、それぞれ米国と EU 内のどのリージョンでも機能します。例えば、Llama 3.2 90B Vision モデルのクロスリージョン推論エンドポイントは以下のようになります。 us.meta.llama3-2-90b-instruct-v1:0 eu.meta.llama3-2-90b-instruct-v1:0 以下は、 Amazon Bedrock Converse API を使用した AWS CLI コマンドの例です。CLI の --query パラメータを使用して結果をフィルタリングし、出力メッセージのテキストコンテンツのみを表示します。 aws bedrock-runtime converse --messages '[{ "role": "user", "content": [ { "text": "Tell me the three largest cities in Italy." } ] }]' --model-id us.meta.llama3-2-90b-instruct-v1:0 --query 'output.message.content[*].text' --output text 出力では、 "assistant" からの応答メッセージが得られます。 The three largest cities in Italy are: 1.Rome (Roma) - population: approximately 2.8 million 2.Milan (Milano) - population: approximately 1.4 million 3.Naples (Napoli) - population: approximately 970,000 AWS SDK のいずれかを使用する場合も、それほど違いはありません。例えば、以下は AWS SDK for Python (Boto3) で Python を使用して、コンソールの例と同じ画像を分析する方法です。 import boto3 MODEL_ID = "us.meta.llama3-2-90b-instruct-v1:0" # MODEL_ID = "eu.meta.llama3-2-90b-instruct-v1:0" IMAGE_NAME = "share-electricity-renewable-small.png" bedrock_runtime = boto3.client("bedrock-runtime") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Based on this chart, which countries in Europe have the highest share?" messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Llama 3.2 モデルは、 Amazon SageMaker JumpStart でも利用できます。SageMaker JumpStart は、コンソールを使用して行う、または SageMaker Python SDK 経由でプログラム的に行う事前トレーニングされたモデルのデプロイを容易にする 機械学習 (ML) ハブです。SageMaker JumpStart では、責任あるイノベーションとシステムレベルでの安全性をサポートするために設計された、モデルの入力 (プロンプト) と出力 (応答) の安全性レベルの分類に役立つ新しいセーフガードモデルにアクセスしてデプロイすることも可能です。これには Llama Guard 3 11B Vision も含まれます。 また、今すぐ SageMaker JumpStart を使用して、Llama 3.2 1B および 3B モデルを簡単にファインチューニングすることもできます。ファインチューニングされたモデルは、 カスタムモデルとして Amazon Bedrock にインポート できます。Amazon Bedrock と Amazon SageMaker JumpStart でのすべての Llama 3.2 モデルコレクションのファインチューニングは、近日提供される予定です。 一般公開されている Llama 3.2 モデルの重みは、カスタムニーズに合わせて調整されたソリューションの提供を容易にします。例えば、Llama 3.2 モデルを特定のユースケースに合わせてファインチューニングし、 それをカスタムモデルとして Amazon Bedrock に取り込む ことができるため、ドメイン固有のタスクでのパフォーマンスが他のモデルを上回る可能性があります。パフォーマンス強化のためにファインチューニングを行う分野がコンテンツ制作、言語理解、またはビジュアル推論であるかにかかわらず、Amazon Bedrock と SageMaker での Llama 3.2 の可用性は、ソリューションの差別化を可能にするユニークで高性能な AI 機能の作成に役立ちます。 Llama 3.2 モデルアーキテクチャの詳細 前バージョンの成功を土台として構築された Llama 3.2 は、最上のパフォーマンスと多用途性を実現するように設計された高度なアーキテクチャを備えています。 自己回帰言語モデル – Llama 3.2 は最適化されたトランスフォーマーアーキテクチャを中核としているため、以前のコンテキストに基づいて次のトークンを予測することによるテキストの生成が可能になります。 ファインチューニング手法 – Llama 3.2 の指示チューニング型バージョンは、2 つの主な手法を採用しています。 教師付きファインチューニング (SFT) – このプロセスは、特定の指示に従って、より関連性の高い応答を生成するようにモデルを調整します。 人間のフィードバックによる強化学習 (RLHF) – この高度な手法は、モデルの出力を人間の好みに合わせて調整し、有用性と安全性を強化します。 マルチモーダル機能 – 11B および 90B Vison モデルでは、Llama 3.2 が画像理解に対する新しいアプローチを導入しています。 個別にトレーニングされた画像推論アダプタの重みがコア LLM の重みと統合されます。 これらのアダプタは、クロスアテンションメカニズム経由でメインモデルに接続されています。クロスアテンションは、モデルのあるセクションが別のコンポーネント出力の関連する部分に注目できるようにすることで、モデルの異なるセクション間での情報フローを可能にします。 画像が入力である場合、モデルは画像推論プロセスを「tool use」操作として扱い、テキスト処理と並行して高度なビジュアル分析を実行できるようにします。この文脈での tool use とは、モデルがその機能を補強して、タスクをより効果的に完了するために、外部のリソースや関数を使用するときに使用される総称です。 最適化された推論 – すべてのモデルがグループ化されたクエリアテンション (GQA) をサポートしています。推論の速度と効率性を向上させる GQA は、特に大規模な 90B モデルに有益です。 このアーキテクチャは、さまざまなモデルサイズ全体で優れたパフォーマンスと適応性を維持すると同時に、テキストの生成と理解から複雑な推論と画像分析におよぶ幅広いタスクを Llama 3.2 が処理できるようにします。 知っておくべきこと 現在、 Meta からの Llama 3.2 モデル は、以下の AWS リージョン にある Amazon Bedrock で一般提供されています。 Llama 3.2 1B および 3B モデルは米国西部 (オレゴン) および欧州 (フランクフルト) で利用でき、 クロスリージョン推論 では米国東部 (オハイオ、バージニア北部) および欧州 (アイルランド、パリ) リージョンで利用できます。 Llama 3.2 11B Vision および 90B Vision モデルは米国西部 (オレゴン) リージョンで利用でき、 クロスリージョン推論 では米国東部 (オハイオ、バージニア北部) で利用できます。 今後の更新については、 完全な AWS リージョンリスト を参照してください。コストの見積もりには、 Amazon Bedrock の料金ページ をご覧ください。 Llama 3.2 の特徴と機能の詳細については、 Amazon Bedrock ドキュメントの Llama モデルセクション をご覧ください。 Amazon Bedrock コンソール で Llama 3.2 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock までフィードバックをお寄せください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。皆さんが Amazon Bedrock で Llama 3.2 を使用して何を構築しているのかを教えください! – Danilo 原文は こちら です。

9 月 23 日、AI21 Labs のパワフルな新しい Jamba 1.5 ファミリーの大規模言語モデル (LLM) が Amazon Bedrock でご利用いただけるようになりました。これらのモデルは、ロングコンテキスト言語機能を大幅に向上させたもので、幅広いアプリケーションでスピード、効率、パフォーマンスを実現しています。Jamba 1.5 ファミリーのモデルには、Jamba 1.5 Mini と Jamba 1.5 Large が含まれます。どちらのモデルも、256K トークンのコンテキストウィンドウ、構造化された JSON 出力、関数呼び出しをサポートし、ドキュメントオブジェクトのダイジェストが可能です。 AI21 Labs は、企業向けの基盤モデルと人工知能 (AI) システムの構築におけるリーダーです。AI21 Labs と AWS は協力して、あらゆる業界のお客様が、現実世界の課題を解決し、戦略的コラボレーションを通じてイノベーションを促進する 生成 AI アプリケーションを構築、デプロイ、スケールできるよう支援しています。AI21 Labs の高度な本番対応モデルと Amazon の専用サービスおよび強力なインフラストラクチャを組み合わせることで、お客様は安全な環境で LLM を活用して、情報の処理、コミュニケーション、学習の未来を形作ることができます。 Jamba 1.5 とは? Jamba 1.5 モデルは、トランスフォーマーモデルアーキテクチャと Structured State Space モデル (SSM) テクノロジーを組み合わせた独自のハイブリッドアーキテクチャを活用しています。この革新的なアプローチにより、Jamba 1.5 モデルは、従来のトランスフォーマーモデルの高性能な特性を維持しながら、最大 256K トークンの長いコンテキストウィンドウを処理できます。このハイブリッド SSM/トランスフォーマーアーキテクチャの詳細については、ホワイトペーパー「 Jamba: A Hybrid Transformer-Mamba Language Model 」を参照してください。 これで、Amazon Bedrock で AI21 の新しい Jamba 1.5 モデルが 2 つ使用できるようになりました。 Jamba 1.5 Large は、あらゆるプロンプト長にわたる複雑な推論タスクに優れているため、長い入力と短い入力の両方で高品質の出力を必要とするアプリケーションに最適です。 Jamba 1.5 Mini は、長いプロンプトの低レイテンシー処理に最適化されているため、長いドキュメントやデータをすばやく分析できます。 Jamba 1.5 モデルの主な強みは次のとおりです。 長いコンテキスト処理 – 256K トークンのコンテキスト長を備えた Jamba 1.5 モデルは、長いドキュメントの要約や分析、エージェントワークフローや RAG ワークフローなど、エンタープライズアプリケーションの品質を向上させることができます。 多言語 – 英語、スペイン語、フランス語、ポルトガル語、イタリア語、オランダ語、ドイツ語、アラビア語、ヘブライ語をサポートしています。 デベロッパーに優しい – 構造化された JSON 出力、関数呼び出しをネイティブでサポートし、ドキュメントオブジェクトのダイジェストが可能です。 スピードと効率性 – AI21 は Jamba 1.5 モデルのパフォーマンスを測定し、同等のサイズの他のモデルよりも長いコンテキストでの推論が最大 2.5 倍速いことを示しました。詳細なパフォーマンス結果については、 AI21 ウェブサイトの Jamba モデルファミリーの発表 をご覧ください。 Amazon Bedrock の Jamba 1.5 モデルの使用を開始する 新しい Jamba 1.5 モデルを使い始めるには、 Amazon Bedrock コンソール に移動し、左下のペインで [Model access] (モデルアクセス) を選択して、Jamba 1.5 Mini または Jamba 1.5 Large へのアクセスをリクエストしてください。 Amazon Bedrock コンソールで Jamba 1.5 モデルをテストするには、左側のメニューペインの [Text] (テキスト) または [Chat] (チャット) プレイグラウンドを選択します。次に、 [Select model] (モデルを選択) を選択し、カテゴリとして [AI21] を選択し、モデルとして [Jamba 1.5 Mini] または [Jamba 1.5 Large] を選択します。 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と現在のサンプルプロンプトを使用してモデルを呼び出す方法のコード例を取得できます。 Amazon Bedrock ドキュメントのコード例 に従って、 AWS SDK を使用して利用可能なモデルにアクセスし、さまざまなプログラミング言語を使用してアプリケーションを構築できます。 次の Python コード例は、テキスト生成用の Amazon Bedrock Converse API を使用して Jamba 1.5 モデルにテキストメッセージを送信する方法を示しています。 import boto3 from botocore.exceptions import ClientError # Create a Bedrock Runtime client. bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") # Set the model ID. # modelId = "ai21.jamba-1-5-mini-v1:0" model_id = "ai21.jamba-1-5-large-v1:0" # Start a conversation with the user message. user_message = "What are 3 fun facts about mambas?" conversation = [ { "role": "user", "content": [{"text": user_message}], } ] try: # Send the message to the model, using a basic inference configuration. response = bedrock_runtime.converse( modelId=model_id, messages=conversation, inferenceConfig={"maxTokens": 256, "temperature": 0.7, "topP": 0.8}, ) # Extract and print the response text. response_text = response["output"]["message"]["content"][0]["text"] print(response_text) except (ClientError, Exception) as e: print(f"ERROR: Can't invoke '{model_id}'.Reason: {e}") exit(1) Jamba 1.5 モデルは、ペアドキュメント分析、コンプライアンス分析、長いドキュメントの質問回答などのユースケースに最適です。複数の情報源の情報を簡単に比較したり、文章が特定のガイドラインを満たしているかどうかを確認したり、非常に長いドキュメントや複雑なドキュメントを処理したりできます。サンプルコードは AI21-on-AWS GitHub リポジトリ にあります。 Jamba モデルに効果的にプロンプトを表示する方法の詳細については、 AI21 のドキュメント をご覧ください。 今すぐご利用いただけます AI21 Labs の Jamba 1.5 ファミリーモデルは、本日、米国東部 (バージニア北部) AWS リージョンの Amazon Bedrock で一般公開されます。 今後の更新については、 全リージョンのリスト を確認してください。詳細については、 Amazon Bedrock の AI21 Labs 製品ページと 料金ページ をご覧ください。 Amazon Bedrock コンソール で Jamba 1.5 モデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 community.aws サイトにアクセスして、深く掘り下げた技術コンテンツを検索し、ビルダーコミュニティがソリューションで Amazon Bedrock を使用する方法を見出しましょう。 –  Antje 原文は こちら です。

AWS Community Days は世界中で盛んに開催されています。 AWS Community Day アルゼンチン にスポットライトを当てます。ここでは、 Jeff Barr が基調講演とトークショーを行い、かつて Bill Gates 氏を追ってマクドナルドに行ったときの面白い話など、Jeff の知恵をコミュニティと共有しました。 Jeff の経験について読む ことをお勧めします。 9 月 16 日週のリリース 私が注目したローンチは次のとおりです。先ずは GA リリースを見ていきましょう。 Amazon EC2 X8g インスタンスが一般公開されました – X8g インスタンス は AWS Graviton4 プロセッサを搭載しており、AWS Graviton2 ベースの Amazon EC2 X2gd インスタンスよりもパフォーマンスが最大 60% 向上しています。X8g インスタンスは、Graviton2 ベースの X2gd インスタンスよりも最大 3 倍大きい vCPU (最大 48 倍) とメモリ (最大 3 TiB) を備えた大きなサイズを提供します。 Amazon Redshift 向け Amazon Q 生成 SQL が一般公開されました – Amazon Redshift クエリエディタ の Amazon Q 生成 SQL は、Amazon Redshift 用のすぐに使えるウェブベースの SQL エディタです。生成 AI を使用してユーザーの意図、クエリパターン、スキーマメタデータを分析し、一般的な SQL クエリパターンを Amazon Redshift 内で直接特定します。これにより、ユーザーのクエリ作成プロセスが加速され、実用的なデータインサイトを引き出すのに必要な時間が短縮されます。 AWS SDK for Swift が一般公開されました 。 AWS SDK for Swift は、Apple プラットフォーム、AWS Lambda、および Linux ベースの Swift on Server アプリケーションから Amazon Web Services にアクセスするための、モダンで使いやすいネイティブな Swift インターフェイスを提供します。一般リリースされたので、お客様は本番環境のワークロードに AWS SDK for Swift を使用できます。詳細については、 AWS SDK for Swift デベロッパーガイド をご覧ください。 AWS Amplify が、非同期のサーバーサイドの関数呼び出しによる長時間実行タスクのサポートを開始 。デベロッパーは AWS Amplify を使用して、GraphQL API 応答をブロックすることなく、生成 AI モデル推論、バッチ処理ジョブ、メッセージキューイングなどの操作で Lambda 関数を非同期で呼び出すことができます。これにより、特に即時の応答が不要な場合や、長時間実行されているタスクをオフロードする必要があるシナリオで、応答性とスケーラビリティが向上します。 Amazon Keyspaces (Apache Cassandra 向け) がマルチリージョンテーブルの列追加のサポートを開始 – 今回のリリースにより、 Amazon Keyspaces (Apache Cassandra 向け) の既存のマルチリージョンテーブルのスキーマを変更して、新しい列を追加できます。レプリカリージョンの 1 つでスキーマを変更するだけで、Keyspaces はテーブルが存在する他のリージョンに新しいスキーマをレプリケートします。 Amazon Corretto 23 が一般公開されました – Amazon Corretto は OpenJDK の無償かつマルチプラットフォーム対応の本番環境向けディストリビューションです。Corretto 23 は OpenJDK 23 の機能リリースで、更新されたベクトル API、拡張されたパターンマッチングとスイッチ式などが含まれています。2025 年 4 月までサポートされます。 既存の Amazon OpenSearch Service ドメインに OR1 インスタンスを使用 – OpenSearch 2.15 では、既存のドメイン設定を更新し、データノードに OR1 インスタンスを選択するだけで、既存の Amazon OpenSearch Service ドメインに OR1 インスタンスを活用できます。これにより、OpenSearch 2.15 を実行しているドメインを、ブルー/グリーンデプロイを使用して OR1 インスタンスにシームレスに移行します。 Amazon S3 Express One Zone が、カスタマーマネージドキーによる AWS KMS のサポートを開始 – デフォルトでは、 S3 Express One Zone は S3 マネージドキー (SSE-S3) を使用してサーバー側の暗号化ですべてのオブジェクトを暗号化します。S3 Express One Zone はカスタマーマネージドキーをサポートしているため、データのセキュリティを暗号化して管理するためのオプションが増えました。S3 Express One Zone と SSE-KMS を併用する場合、S3 バケットキーは追加料金なしで常に有効になります。 AWS Chatbot を使用して Microsoft Teams や Slack から Amazon Bedrock エージェントとやり取りする – 以前は、お客様は Microsoft Teams または Slack でカスタムチャットアプリケーションを開発し、それを Amazon Bedrock のエージェント と統合する必要がありました。これで、エージェントエイリアスを AWS Chatbot チャネル設定に接続することで、チャットチャネルから Amazon Bedrock エージェントを呼び出すことができます。 マネージド GitLab ランナー向けの AWS CodeBuild サポート – お客様は、GitLab CI/CD ジョブイベントを受信してエフェメラルホストで実行するように AWS CodeBuild プロジェクト を設定できます。この機能により、GitLab ジョブを AWS とネイティブに統合できるようになり、IAM、AWS Secrets Manager、AWS CloudTrail、Amazon VPC などの機能を通じてセキュリティと利便性が向上します。 既存のサービスがさらに多くのリージョンでご利用いただけるようになりました。 Amazon Aurora PostgreSQL Optimized Reads が AWS GovCloud (米国) リージョンで利用できるように なりました。 Amazon DocumentDB が 欧州 (スペイン) および アフリカ (ケープタウン) リージョンで利用できるようになりました。 Amazon MSK は、Graviton3 ベースの M7G インスタンスのサポートが 欧州 (ロンドン) リージョン でも受けられるようになりました。 Amazon EC2 G6 インスタンス が スペインリージョン で利用可能になり、 High Memory インスタンスが アフリカ (ケープタウン) リージョン で利用できるようになりました。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 EKS での安全なクラスター間通信 – Amazon VPC Lattice と Pod Identity を使用して EKS クラスター間のアプリケーション通信を保護する方法と、独自のマイクロサービスアプリケーションに適応する際に参考となる例を示します。 Cohere Rerank を使用して RAG パフォーマンスを向上させる – この記事では、Cohere Rerank を使用して RAG システムの検索効率と精度を向上させる方法に焦点を当てます。 AWS オープンソースのニュースと更新 – 同僚の Ricardo Sueiras が AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community Days  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催される AWS Community Day は、 イタリア (9 月27 日)、 台湾 (9 月28 日)、 サウジアラビア (9 月28 日)、 オランダ (10 月 3 日)、 ルーマニア (10 月 5 日) で開催されます。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 9 月 23 日週はここまでです。9 月 30 日週の Weekly Roundup もお楽しみに! — Abhishek この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本ブログは「 Methodology for incident response on generative AI workloads 」を翻訳したものとなります。 AWS カスタマーインシデント対応チーム (CIRT) は、生成 AI ベースのアプリケーションに関連するセキュリティインシデントの調査に使用できる方法論を開発しました。生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイド に記載されているガイダンスと原則に従う必要があります。生成 AI ワークロードでは、いくつかの追加要素も考慮する必要があるため、このブログ投稿で詳しく説明します。 本ブログでは、はじめに生成 AI ワークロードの一般的なコンポーネントについて説明します。次に、イベント発生前における準備と生成 AI ワークロードのインシデント対応方法論をご紹介します。インシデント対応方法論は、生成 AI ワークロードのセキュリティイベントをトリアージして対応する際に考慮すべき 7 つの要素で構成されています。最後に、方法論を検討するのに役立つインシデントの例を応用シナリオを使用してご紹介します。 生成 AI ワークロードのコンポーネント 図 1 に示すように、生成 AI アプリケーションには次の 5 つのコンポーネントが含まれます。 インフラストラクチャ、生成 AI アプリケーション、および組織のプライベートデータを所有または管理する組織。 生成 AI アプリケーション自体に特に関係のない組織内のインフラストラクチャ。これには、データベース、バックエンドサーバー、および Web サイトが含まれます。 生成 AI アプリケーション。これには以下が含まれます。 基盤モデル — 多数のパラメーターを持ち、膨大な量の多様なデータに基づいてトレーニングされた AI モデル。 カスタムモデル — 組織固有の要件に合わせて、組織の特定のデータやユースケースに基づいてファインチューニングまたはトレーニングされたモデル。 ガードレール — 生成 AI アプリケーションが希望する範囲内で動作することを保証するためのメカニズムまたは制約。例としては、コンテンツフィルタリング、安全上の制約、倫理ガイドラインなどがあります。 エージェント — 生成 AI アプリケーションが会社のシステムやデータソース全体で複数ステップのタスクを実行できるようにするワークフロー。 ナレッジベース — 生成 AI アプリケーションがアクセスして使用できるドメイン固有の知識、ルール、またはデータのリポジトリ。 トレーニングデータ — 検索拡張生成 (RAG) などの手法用のデータを含む、生成 AI アプリケーションのモデルのトレーニング、ファインチューニング、または拡張に使用されるデータ。 注 : トレーニングデータは組織の プライベートデータ とは異なります。生成 AI アプリケーションは通常、プライベートデータに直接アクセスすることはありませんが、一部の環境では設定によってアクセスが可能な場合もあります。 プラグイン — 生成 AI アプリケーションと統合して、特殊な機能を提供したり、外部サービスやデータソースにアクセスしたりできる追加のソフトウェアコンポーネントまたは拡張機能。 プライベートデータとは、生成 AI リソースまたはアプリケーションが通常の運用中に操作しないプライベートに保存されたお客様の機微データを指します。 ユーザーとは、生成 AI アプリケーションの操作や、アプリケーションにアクセスするアイデンティティです。人間でも人間以外 (機械など) でもかまいません。 図 1 : 生成 AI ワークロードの一般的なコンポーネント 生成 AI ワークロードでのインシデント対応に備える セキュリティイベントに備えるには、 「人」、「プロセス」、「テクノロジー」 の 3 つのドメインに渡って準備が必要です。準備内容の概要については、『セキュリティインシデント対応ガイド』の準備項目を参照してください。さらに、生成 AI ワークロードに関連するセキュリティイベントの準備には、以下を含める必要があります。 人材: インシデント対応スタッフとセキュリティ運用スタッフへの生成 AI に関するトレーニング — 担当スタッフが生成 AI の概念と組織で使用されている AI/ML サービスに精通していることを確認する必要があります。 AWS Skill Builder では、これら両方の科目に関する無料コースと有料コースの両方を提供しています。 プロセス: 新しいプレイブックの開発 — 生成 AI ワークロードに関連するセキュリティイベントのための新しいプレイブックを開発する必要があります。これらの開発方法の詳細については、以下のサンプルプレイブックを参照してください。 Amazon Bedrock セキュリティイベントへの対応 Amazon SageMaker セキュリティイベントへの対応 Amazon Q セキュリティイベントへの対応 各サービスのプレイブックを出発点として使用し、組織や各サービスの使用状況に合わせて変更することができます。 テクノロジー: 生成 AI アプリケーションのプロンプトと呼び出しをログに記録する — AWS CloudTrail で利用できるような基本的なログに加えて、アプリケーションに入力されるプロンプトと出力内容を分析できるように、 Amazon Bedrock モデルの呼び出しログを記録することを検討する必要があります。詳細については、「 Amazon Bedrock モデル呼び出しのログ記録 」を参照してください。CloudTrail データイベントのログは、Amazon Bedrock、Amazon Q、Amazon SageMaker でも利用できます。一般的なガイダンスについては、「 セキュリティインシデント対応のためのロギング戦略 」を参照してください。 重要: ログには機微情報が含まれる場合があります。この情報を保護するには、他のセキュリティログと同様に、これらのログへの最小権限アクセスを設定する必要があります。 データマスキング を使用して機微なログデータを保護することもできます。 Amazon CloudWatch では、 ロググループのデータ保護ポリシー を使用してデータをネイティブにマスクできます。 生成 AI ワークロードにおけるインシデント対応の方法論 準備項目が完了したら、生成 AI ワークロードのインシデント対応方法論を使用したアクティブな対応が可能になります。これは生成 AI アプリケーションに関連するセキュリティイベントを迅速にトリアージするのに役立ちます。 方法論には 7 つの要素があり、このセクションで詳しく説明します。各要素は、コンポーネントが別のコンポーネントと相互作用する方法や、コンポーネントを変更する方法を記述します。これらの要素を考慮することは、検知、分析、封じ込め、根絶、復旧の各段階を含むセキュリティインシデントの 運用段階 における行動の指針となります。 アクセス — 生成 AI アプリケーションのコンポーネントをホストする組織のアクセスパターンを特定し、それらのパターンからの逸脱や異常を調査します。アプリケーションが外部からアクセス可能か、または内部からアクセス可能かを確認します。 Amazon GuardDuty を使用すると、AWS 環境への異常なアクセスや潜在的な不正アクセスを特定しやすくなります。アプリケーションに外部からアクセスできる場合、脅威アクターは AWS 環境に直接アクセスできない可能性があり、 GuardDuty はそれを検出しません。アプリケーションへの認証の設定方法によって、不正アクセスの検出と分析の方法が決まります。 AWS アカウントまたは関連するインフラストラクチャへの不正アクセスの証拠がある場合は、関連する権限やタイムラインなど、不正アクセスの範囲を特定します。不正アクセスにサービスの認証情報 ( Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの認証情報など) が含まれる場合は、サービスに脆弱性がないか確認してください。 インフラストラクチャの変更 — サーバー、データベース、サーバーレスコンピューティングインスタンス、内部または外部の Web サイトなどの生成 AI アプリケーションをサポートするインフラストラクチャを確認して、アクセスまたは変更されたかを判断します。インフラストラクチャの変更を調査するには、CloudTrail ログを分析して対象範囲内のリソースの変更を調べたり、他のオペレーティングシステムログやデータベースアクセスログを分析します。 AI の変更 — ユーザーが生成 AI アプリケーションのコンポーネントにアクセスしたか、またそれらのコンポーネントに変更を加えたかを調査します。カスタムモデルの作成または削除、モデルの可用性の変更、生成 AI ロギング機能の改ざんまたは削除、アプリケーションコードの改ざん、生成 AI ガードレールの削除または変更など、不正アクティビティの兆候がないか確認します。 データストアの変更 — 設計または意図されたデータアクセスパターンを特定し、ユーザーが生成 AI アプリケーションのデータストアにアクセスしたかどうか、およびこれらのデータストアに変更を加えたかどうかを判断します。また、生成 AI アプリケーションへのエージェントの追加または変更も検討する必要があります。 呼び出し — 文字列やファイル入力を含む生成 AI モデルの呼び出しを分析して、プロンプトインジェクションやマルウェアなどの脅威がないかを確認します。 OWASP Top 10 for LLM は、呼び出し関連の脅威を理解するための出発点として使用できます。また、呼び出しログを使用して、プロンプトを分析して、プロンプトインジェクションの試みを示唆する可能性のある疑わしいパターン、キーワード、または構造がないか調べることができます。ログにはモデルの出力と応答も記録されるため、プロンプトインジェクションを示唆する特徴的でない、または安全でないモデルの動作を特定するための動作分析に役立ちます。ログ内のタイムスタンプを時系列分析に使用すると、組織的なプロンプトインジェクションの試みを経時的に検出し、モデル呼び出しを開始したユーザーまたはシステムに関する情報を収集できるため、潜在的な悪用の原因を特定するのに役立ちます。 プライベートデータ — 対象範囲の生成 AI アプリケーションが、個人データまたは機微データにアクセスが可能か確認します。次に、そのデータへの不正アクセスや改ざんがないか調べます。 代理行為 — 代理行為とは、アプリケーションが組織のリソースを変更したり、ユーザーに代わってアクションを実行したりする機能を指します。たとえば、生成 AI アプリケーションは、メールを送信するために使用されるコンテンツを生成し、そのために別のリソースまたは関数を呼び出すように構成されている場合があります。生成 AI アプリケーションに他の機能を呼び出す機能があるかどうかを判断する必要があります。次に、不正な変更が行われたのか、それとも生成 AI アプリケーションが不正な機能を呼び出したのかを調査します。 次の表は、方法論の 7 つの要素に取り組むのに役立ついくつかの質問を示しています。回答を参考にしてください。 トピック トピックに対する質問 アクセス コンピューティング環境にまだアクセスできますか？ あなたの組織に不正アクセスの証拠は残っていますか？ インフラストラクチャの変更 サポートするインフラリソースへのアクセス、および変更が実施されましたか？ AI の変更 AI モデル、コード、リソースへのアクセス、および変更が実施されましたか？ データストアの変更 データストア、ナレッジベース、エージェント、プラグイン、またはトレーニングデータへのアクセス、および変更が実施されましたか？ 呼び出し どのようなデータ、文字列、ファイルがモデルへの入力として使用されましたか？ どのようなプロンプトが送信されましたか？その結果、どのような応答が生成されましたか？ プライベートデータ 生成AIリソースはどのような個人データや機微データにアクセスできますか？ プライベートデータの変更や改ざんは発生していませんか？ 代理行為 生成 AI リソースを使用して組織内でコンピューティング サービスを開始できますか? 生成 AI リソースに変更を加える権限がありますか? 不正な変更が加えられましたか? インシデントの例 調査と対応のための方法論の使い方を見ていきましょう。ここでは不正なユーザーが公開されたコードリポジトリに流出した認証情報を使用して、 AWS 上でホストされている生成 AI アプリケーションに侵入するというセキュリティイベントの例を扱います。私たちの目標は、どのリソースがアクセス、変更、作成、削除されたかを判断することです。 AWS で生成 AI のセキュリティイベントを調査するために確認すべき主なログソースは以下の通りです: CloudTrail CloudWatch VPC Flow Logs Amazon Simple Storage Service (Amazon S3) データイベント (組織の S3 バケットへのアクセスの証拠用) Amazon Bedrock モデル呼び出しのログ (アプリケーションがこのサービスを使用している場合) アクセス 生成 AI アプリケーションのアクセス分析は、標準的な 3 層ウェブアプリケーションのアクセス分析と似ています。まず、組織が AWS アカウントにアクセスできるかどうかを判断します。AWS アカウントのルートユーザーのパスワードを紛失または変更した場合は、 パスワードをリセット します。次に、ルートユーザーの 多要素認証（MFA）デバイス をすぐに有効にすることを強くお勧めします。これにより、脅威アクターがルートユーザーでアクセスするのを防ぐことができます。 次に、アカウントへの不正アクセスが続いているかどうかを確認します。 AWS Identity and Access Management (IAM) と AWS Security Token Service (Amazon STS) によって記録された変更を伴うアクションを特定するには、GitHub の「 AWS アカウントの認証情報が侵害された場合のセキュリティプレイブック 」の「 分析 」セクションを参照してください。最後に、アクセスキーがパブリックリポジトリやアプリケーションコードに保存されていないことを確認してください。代替案については、「 長期的なアクセスキーに対する代替方法 」を参照してください。 インフラストラクチャの変更 アプリケーションのインフラストラクチャの変更を分析するには、 コントロールプレーンとデータプレーン の両方を考慮する必要があります。この例では、生成 AI アプリケーションのダウンストリームコンポーネントへの認証に Amazon API Gateway が使用され、他の付帯的なリソースがアプリケーションとやり取りしていたとします。CloudTrail でこれらのリソースに対するコントロールプレーンの変更を確認することもできますが、リソースのオペレーティングシステムで行われた変更を確認するには、追加のログ記録を有効にする必要があります。この要素に関して CloudTrail で見つかる可能性のあるコントロールプレーンイベントの一般的な名称は次のとおりです。 ec2:RunInstances ec2:StartInstances ec2:TerminateInstances ecs:CreateCluster cloudformation:CreateStack rds:DeleteDBInstance rds:ModifyDBClusterSnapshotAttribute AI の変更 許可されていない変更には、システムプロンプト、アプリケーションコード、ガードレール、およびモデルの可用性が含まれますが、これらに限定されません。AWS がホストする生成 AI リソースへの内部ユーザーアクセスは CloudTrail に記録され、次のいずれかのイベントソースで表示されます。 bedrock.amazonaws.com sagemaker.amazonaws.com qbusiness.amazonaws.com q.amazonaws.com 以下は、このシナリオ例における生成 AI リソースログの改ざんを表す CloudTrail のイベント名の例をいくつか示しています。 bedrock:PutModelInvocationLoggingConfiguration bedrock:DeleteModelInvocationLoggingConfiguration AI/ML モデルのサービス設定へのアクセスを表す CloudTrail の一般的なイベント名は次のとおりです。 bedrock:GetFoundationModelAvailability bedrock:ListProvisionedModelThroughputs bedrock:ListCustomModels bedrock:ListFoundationModels bedrock:ListProvisionedModelThroughput bedrock:GetGuardrail bedrock:DeleteGuardrail このシナリオ例では、不正なユーザーが AWS アカウントにアクセスしています。ここで、侵害されたユーザーに、すべてのリソースへのフルアクセスを許可するポリシーが添付されているとします。このアクセスにより、権限のないユーザーは Amazon Bedrock の各コンポーネントを列挙し、アプリケーションの一部であるナレッジベースとガードレールを特定できます。 その後、不正なユーザーは Amazon Bedrock 内の他の 基盤モデル (FM) へのモデルアクセスをリクエストし、既存のガードレールを削除します。他の基盤モデルにアクセスできるということは、不正なユーザーが生成 AI アプリケーションを自分の目的で使用しようとしていることを示している可能性があり、ガードレールの削除により、モデルによるフィルタリングや出力チェックが最小限に抑えられます。AWS では、 IAM ポリシーとリソースベースのポリシー を使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、 AWS Lambda 関数、およびアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限することを推奨します。また、Amazon Bedrockなどの重要なコンポーネントや生成 AI アプリケーションの他のコンポーネントにアクセスできる IAM ユーザー、ロール、サービスアカウントには、MFA の使用を強制する必要があります。 データストアの変更 通常、データストアやナレッジベースの使用およびアクセスはモデル呼び出しを通じて行います。Amazon Bedrock の場合は、 bedrock:InvokeModel という API を呼び出します。 ただし、不正なユーザーが環境にアクセスした場合、生成 AI アプリケーションが統合するデータソースとナレッジベースを作成、変更、または削除できます。これにより、データまたはモデルの流出または破壊、データ汚染が発生し、モデルのサービス拒否状態が発生する可能性があります。以下は、このシナリオ例の AI/ML データソースへの変更を表す CloudTrail の一般的なイベント名です。 bedrock:CreateDataSource bedrock:GetKnowledgeBase bedrock:DeleteKnowledgeBase bedrock:CreateAgent bedrock:DeleteAgent bedrock:InvokeAgent bedrock:Retrieve bedrock:RetrieveAndGenerate 実行可能なアクションの完全なリストについては、 Amazon Bedrock API リファレンス を参照してください。 このシナリオでは、不正なユーザーが生成 AI アプリケーションへのフルアクセス権を持ち、ある程度の一覧の取得が行われたことを確認しました。その後、不正なユーザーが生成 AI アプリケーションのナレッジベースである S3 バケットを特定し、不正確なデータをアップロードしたため、LLM が破損しました。この脆弱性の例については、LLM アプリケーションの OWASP TOP 10 の「 LLM03 訓練データの汚染 」セクションを参照してください。 呼び出し Amazon Bedrock は特定の API を使用して モデル呼び出し を行います。Amazon Bedrock のモデルが呼び出されると、CloudTrail はそのモデルをログに記録します。ただし、生成 AI モデルに送信されたプロンプトと、そこから受信した出力応答を確認するには、モデル呼び出しのログ記録を設定しておく必要があります。 これらのログは非常に重要です。なぜなら、脅威アクターがモデルを使ってデータストアから情報を引き出そうとしたり、モデルが学習またはファインチューニングされたデータを開示しようとしたかどうかなど、重要な情報を明らかにする可能性があるからです。たとえば脅威アクターが、機微データを抽出したり、セキュリティコントロールをバイパスしたり、ポリシーに違反するコンテンツを生成したりするように巧妙に作りこまれたプロンプトをモデルに与えようとしたかどうかが、ログから明らかになることがあります。ログを使用すると、セキュリティイベントで使用される可能性のある誤った情報、スパム、またはその他の悪意のある出力を生成するためにモデルが使用されたかどうかもわかります。 注 : Amazon Bedrock などのサービスでは、呼び出しログの記録はデフォルトで無効になっています。可能な場合は、生成 AI サービスのデータイベントとモデル呼び出しのログ記録を有効にすることをお勧めします。ただし、プライバシーや法的な理由から、組織によっては呼び出しログを取得して保存したくない場合があります。一般的な懸念事項の 1 つは、ユーザーが機微データをインプットとして入力することです。これにより、保護する資産の範囲が広がります。これはビジネス上の決定であり、考慮に入れる必要があります。 このシナリオの例では、モデル呼び出しのログ記録が有効になっていないため、インシデント対応者が呼び出しログを収集して、不正呼び出しに関するモデルへの入力または出力データを確認できなかったとします。インシデント対応者は、 LLM からのプロンプトとそれに続く応答を特定することができませんでした。このログを有効にしないと、呼び出し要求に関連するリクエストデータ、応答データ、メタデータ全体を確認することもできませんでした。 Amazon Bedrock のモデル呼び出しのログ記録に含まれる可能性のあるイベント名には、次のものが含まれます。 bedrock:InvokeModel bedrock:InvokeModelWithResponseStream bedrock:Converse bedrock:ConverseStream 以下は、Amazon Bedrock モデル呼び出しログ記録のログエントリのサンプルです。 図 2: プロンプトと応答を含むモデル呼び出しログのサンプル プライベートデータ アーキテクチャの観点から見ると、生成 AI アプリケーションは組織のプライベートデータに直接アクセスすべきではありません。生成 AI アプリケーションのトレーニングに使用されるデータまたは RAG 用のデータをデータストアデータとして分類し、プライベートデータから分離する必要があります。ただし、生成 AI アプリケーションがプライベートデータを使用する場合を除きます（たとえば、生成 AI アプリケーションが患者の医療記録に関する質問に答える必要がある場合）。組織のプライベートデータを生成 AI アプリケーションから確実に分離する 1 つの方法は、 別のアカウント を使用し、最小権限の原則に従って必要に応じて認証と認可を行うことです。 代理行為 LLM における 過剰な代理行為 とは、AI システムが過度の自律性や意思決定力を持ち、意図せず潜在的に有害な結果をもたらすことを指します。これは、LLM が不十分な監視や制約、または人間の価値観との整合性が不十分な状態で導入された場合に発生する可能性があります。その結果、多くの人間が有益または倫理的と考えるものとは異なる選択をモデルが行うことになります。 このシナリオの例では、生成 AI アプリケーションには、アプリケーションが必要としないサービスに対する過剰な権限を持っています。アプリケーションコードが Amazon Simple Email Service (Amazon SES) へのフルアクセス権を持つ実行ロールで実行されていたとします。これにより、LLM がプロンプトに応答して不正なユーザーに代わってスパムメールを送信する可能性があります。生成 AI アプリケーションプラグインとエージェントの権限と機能を制限することで、これを防ぐことができます。詳細については、LLM08 過剰な代理行為の証拠である OWASP LLM Top 10 を参照してください。 調査中にログを分析する際、 SourceIpAddress フィールドと UserAgent フィールドの両方が生成的な AI アプリケーション (たとえば、 sagemaker.amazonaws.com 、 bedrock.amazonaws.com 、 q.amazonaws.com ) に関連付けられます。他のサービスから一般的に呼び出されたり呼び出されたりする可能性のあるサービスの例としては、Lambda、Amazon SNS、Amazon SES などがあります。 結論 生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイド に記載されているガイダンスと原則に従う必要があります。ただし、これらのワークロードでは、いくつかの追加要素も考慮する必要があります。 本ブログで紹介した方法論を参考にして、これらの新しい要素に対応することができます。この手法は、生成 AI アプリケーションの使用が不正使用の対象または仕組み、あるいはその両方となるインフラストラクチャへの不正アクセスを調査する場合に参考になります。この方法論により、生成 AI ワークロードに関連するセキュリティインシデントに備えて対応するための体系的なアプローチが可能になり、これらの重要なアプリケーションのセキュリティと整合性を維持するのに役立ちます。 生成 AI アプリケーションを設計するためのベストプラクティスの詳細については、「 AWS セキュリティリファレンスアーキテクチャ用の生成 AI 」を参照してください。一般的な生成 AI アプリケーションの戦術的緩和策については、「 セキュアデザインのためのブループリントとアンチパターンへの緩和戦略 」を参照してください。 この投稿について質問がある場合は、 AWS セキュリティ、アイデンティティ、コンプライアンス re: Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Anna McAbee Anna は、AWS で金融サービス、生成 AI、インシデント対応を専門とするセキュリティスペシャリストソリューションアーキテクトです。仕事以外では、Anna はテイラー・スウィフト、フロリダ・ゲイターズのフットボールチームを応援したり、ワインテイスティングをしたり、世界中を旅したりするのを楽しんでいます。 Steve De Vera Steve は AWS カスタマーインシデント対応チーム (CIRT) のマネージャーです。アメリカンスタイルの BBQ に情熱を注いでおり、BBQ コンテストの認定の審査員も務めています。彼は Brisket という名前の犬を飼っています。 AJ Evans AJ は AWS カスタマーインシデント対応チーム (CIRT) のセキュリティエンジニアです。記入犯罪とネットワーク侵入を専門に扱った元米国シークレットサービスの特別捜査官としての経験を活かして、AWS のお客様を保護しています。最新のサイバー脅威に対応していないときは、AJ はゲーム、音楽演奏、カスタム PC の構築、自作の 3D プリントを楽しんでいます。 Jennifer Paz Jennifer は 10 年以上の経験を持つセキュリティエンジニアで、現在は AWS カスタマーインシデント対応チーム (CIRT) に所属しています。Jennifer は、お客様がセキュリティ上の課題に取り組むのを支援し、複雑なソリューションを実装してセキュリティ態勢を強化することを楽しんでいます。仕事をしていないときは、Jennifer は熱心なウォーカー、ジョガー、ピックルボール愛好家、旅行者、そして美食家であり、常に新しい料理のへの探求を求めています。 翻訳はプロフェッショナルサービス本部の高橋、藤浦が担当しました。

Gartner の 2024 Magic Quadrant for DaaS (Desktop as a Service) では、AWS が初めてリーダーに位置付けられました。2023 年、私たちはチャレンジャーとして認められました。これは、ライセンスポータビリティ ( Microsoft 365 Apps for Enterprise を含む )、地理的戦略、およびコストの最適化とオートメーションに重点を置いた運用能力を備えた多様な仮想デスクトップサービスのポートフォリオを提供することにより、幅広いお客様のニーズを満たすという当社の取り組みの成果であると考えています。また、仮想デスクトップサービスの各側面を管理するための使いやすいインターフェイスに重点を置いているため、お客様がサードパーティーのツールを利用する必要はほとんどありません。 詳細については、 Gartner の 2024 Magic Quadrant for Desktop as a Service (DaaS) の全文をご覧ください。 AWS DaaS サービス DaaS サービスのラインナップ ( エンドユーザーコンピューティング ポートフォリオの一部) を簡単に見てみましょう。 Amazon WorkSpaces ファミリー – 2014 年の初め に最初に発売され、それ以来頻繁に強化されてきた Amazon WorkSpaces は、クラウドで Microsoft Windows、Ubuntu、Amazon Linux、または Red Hat Enterprise Linux を実行するデスクトップコンピューティング環境を提供します。リモートワーカーやハイブリッドワーカー、ナレッジワーカー、デベロッパーワークステーション、学習環境をサポートするように設計された WorkSpaces は、16 の AWS リージョンで、GPU 搭載 グラフィックス G4dn バンドル を含む 6 種類のバンドルサイズからお選びいただけます。 WorkSpaces Personal は、各ユーザーに永続的なデスクトップを提供します。アプリケーションをインストールしてファイルやデータを保存する必要があるデベロッパーやナレッジワーカーなどに最適です。ユーザーが常設デスクトップ (コンタクトセンター、トレーニング、仮想学習、バックオフィスへのアクセスなど) を必要としない場合は、 WorkSpaces Pools を使用して管理を簡素化し、コストを削減できます。 WorkSpaces Core は、 Citrix 、 Leostream 、 Omnissa 、 Workspot などのサードパーティーの VDI ソリューションと連携するように設計されたマネージド仮想デスクトップインフラストラクチャを提供します。 Amazon WorkSpaces クライアントはデスクトップとタブレットで利用でき、ウェブアクセス ( Amazon WorkSpaces セキュアブラウザ ) と Amazon WorkSpaces シンクライアント を利用すると、さらに多くの選択肢があります。Microsoft の適切な Windows 10 または 11 デスクトップライセンスをお持ちの場合は、 クラウドに独自のライセンスを持ち込んで (BYOL とも)、専用のハードウェア上で実行できます。 Amazon WorkSpaces ファミリー について読んだり、 WorkSpaces の機能 を確認したりして、WorkSpaces でできることについて詳しく知ることができます。 Amazon AppStream 2.0 – 2016 年後半にリリースされた Amazon AppStream では、コードを記述したり、アプリケーションをリファクタリングしたりすることなく、SaaS アプリケーションやデスクトップアプリケーションに瞬時にストリーミングでアクセスできます。インフラストラクチャを管理しなくても、アプリケーションを簡単にスケールして世界中のユーザーが利用できるようにすることができます。コンピューティング、メモリ、ストレージ、GPU、およびオペレーティングシステムの幅広いオプションにより、リモートワーカーの活動の幅を広げると同時に、自動スケーリングを利用してオーバープロビジョニングを回避できます。 Amazon AppStream には、常時オン (インスタント接続)、オンデマンド (起動まで 2 分)、調整可能 (予測できない需要に対応) の 3 種類の フリートタイプ があります。料金はタイプによって異なり、Windows と Linux の場合は 1 秒あたり、1 時間単位で細かく設定されています。詳細については、 Amazon AppStream 2.0 の料金 をご覧ください。 – Jeff ; Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価やその他認定を受けたベンダーのみを選択するようテクノロジーユーザーに勧告するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 GARTNER は、Gartner の登録商標およびサービスマークです。Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。All rights reserved. グラフィックは、Gartner が発行した大規模な調査文書の一部であり、文書全体の文脈で評価されるべきものです。ガートナーのドキュメントは、AWS からのリクエストに応じて入手可能です。 原文は こちら です。

Graviton 4 を搭載し、メモリを最適化した X8g インスタンスは、現在、最大 3 TiB の DDR5 メモリと最大 192 個の vCPU を備えた、10 の仮想サイズと 2 つのベアメタルサイズで利用できるようになりました。X8g インスタンスは、これまでで最もエネルギー効率が良く、これまでで同等の EC2 Graviton インスタンスの中で最高の料金パフォーマンスとスケールアップ機能を備えています。メモリと vCPU の比率が 16 対 1 のこれらのインスタンスは、Electronic Design Automation、インメモリデータベースとキャッシュ、リレーショナルデータベース、リアルタイム分析、およびメモリに制約のあるマイクロサービス向けに設計されています。インスタンスはすべての高速物理ハードウェアインターフェイスを完全に暗号化し、 AWS Nitro System と Graviton4 のセキュリティ機能も追加されています。 5 万社を超える AWS のお客様が、150 を超える Graviton 搭載インスタンスの既存のラインアップを既に利用しています。 Valkey 、 Redis 、 Apache Spark 、 Apache Hadoop 、 PostgreSQL 、 MariaDB 、 MySQL 、 SAP HANA Cloud など、さまざまなアプリケーションを実行しています。新しい X8g インスタンスは、12 種類のサイズで利用でき、スケールアップ (より大きなインスタンスを使用) とスケールアウト (より多くのインスタンスを使用する) のどちらかを選択できるため、上記のアプリケーションにとってさらに優れたホストとなります。また、現在個別のインスタンスで実行されているメモリの使用量が多い既存のワークロードの柔軟性も高まります。 インスタンス 前世代 (X2gd) インスタンスと比較すると、X8g インスタンスは 3 倍のメモリ、3 倍の vCPU、2 倍以上の EBS 帯域幅 (40 Gbps 対 19 Gbps)、2 倍のネットワーク帯域幅 (50 Gbps 対 25 Gbps) を備えています。 X8g インスタンス内の Graviton4 プロセッサは、X2gd インスタンスの Graviton2 プロセッサの 2 倍 (2 MiB 対 1 MiB) のコアあたり L2 キャッシュを備え、メモリ帯域幅が 160% 高く、コンピューティングパフォーマンスを最大 60% 向上させることができます。 X8g インスタンスは、第 5 世代の AWS Nitro System および Graviton4 プロセッサを使用して構築されています。これには、命令レベルで制御フローを妨害しようとする低レベルの攻撃に対する保護を提供する Branch Target Identification (BTI) などの追加のセキュリティ機能が組み込まれています。これと Graviton4 のその他のセキュリティ機能の詳細については、「 Amazon の新しい CPU がサイバーセキュリティの脅威にどのように対処するか 」を読み、 re:Invent 2023 AWS Graviton セッションをご覧ください。 仕様はこのようになっています。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 x8g.medium 1 16 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.large 2 32 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.xlarge 4 64 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.2xlarge 8 128 GiB 最大 10 Gbps 最大 15 Gbps x8g.4xlarge 16 256 GiB 最大 10 Gbps 最大 15 Gbps x8g.8xlarge 32 512 GiB 10 Gbps 15 Gbps x8g.12xlarge 48 768 GiB 15 Gbps 22.5 Gbps x8g.16xlarge 64 1,024 GiB 20 Gbps 30 Gbps x8g.24xlarge 96 1,536 GiB 30 Gbps 40 Gbps x8g.48xlarge 192 3,072 GiB 40 Gbps 50 Gbps x8g.metal-24xl 96 1,536 GiB 30 Gbps 40 Gbps x8g.metal-48xl 192 3,072 GiB 40 Gbps 50 Gbps インスタンスは ENA 、 ENA Express 、および EFA Enhanced Networking をサポートしています。上の表からわかるように、これらは十分な量の EBS 帯域幅を提供し、 io2 Block Express 、 EBS 汎用 SSD 、 EBS プロビジョンド IOPS SSD を含むすべての EBS ボリュームタイプ をサポートしています。 稼働中の X8g インスタンス vCPU あたり 16 GiB、またはインスタンスあたり最大 3 TiB のメモリを使用できるアプリケーションとユースケースを見てみましょう。 データベース – X8g インスタンスにより、SAP HANA と SAP Data Analytics Cloud は、以前よりも大規模で野心的なワークロードを処理できるようになりました。Graviton4 搭載インスタンス上で実行された SAP は、Graviton3 インスタンスで実行されている同じワークロードと比較して、分析ワークロードのパフォーマンスが最大 25%、トランザクションワークロードのパフォーマンスが最大 40% 向上したことを測定しました。X8g インスタンスにより、SAP は Graviton ベースの使用をさらに大規模なメモリバウンドソリューションにまで拡大できます。 Electronic Design Automation – EDA ワークロードは、Graviton、Trainium、Inferentia などの新世代のチップや、ニトロシステムのビルディングブロックを形成するチップの設計、テスト、検証、テープアウトのプロセスの中心です。AWS をはじめとする多くのチップメーカーは、これらのワークロードに AWS クラウド を採用し、規模と弾力性を利用して設計プロセスの各段階に適切な量のコンピューティング能力を供給しています。これにより、エンジニアは結果を待たずに済むため、より迅速にイノベーションを進めることができます。これは、2022 年後半から 2023 年初頭にかけて Graviton4 の開発を支援するために使用されたクラスターの 1 つからの長期スナップショットです。ご覧のとおり、このクラスターは大規模に稼働しており、ピーク時には通常の使用量の 5 倍にもなります。 毎日および毎週のアクティビティが急増し、テープアウトフェーズでは全体的な使用量が飛躍的な伸びがあることがわかります。クラスター内のインスタンスはサイズスペクトルの中でも大きいため、ピークは同時に稼働している数十万のコアを表しています。必要なときにコンピューティングをスピンアップし、不要な場合はダウンできるため、ハードウェアに専用の投資をしなくても、これまでにない規模で利用できます。 新しい X8g インスタンスにより、当社と EDA のお客様は、Graviton プロセッサでさらに多くのワークロードを実行できるようになり、コストを削減し、エネルギー消費量を削減すると同時に、新製品をこれまで以上に迅速に市場に投入できるようになります。 今すぐご利用いただけます X8g i インスタンスは、9 月 18 日から米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト) の各 AWS リージョンにおいて、オンデマンド、スポット、リザーブドインスタンス、Savings Plan、ハードウェア専有インスタンス、専有ホスト形式でご利用いただけます。詳細については、 X8g ページ をご覧ください。 原文は こちら です。

本ブログは、小売業向け AWS の e-book 「小売業のデジタルコマースを最適化する 4 つの重要なステップ」の概要と、具体的なユースケースと関連する技術のハイライトを解説するものです。このガイドは、クラウドで次世代テクノロジーを活用し、小売業界を変革する方法に関心を持っている小売業界および IT 業界のビジネスリーダーを対象としています。 クラウドによる e コマースの変革 米国における 2023 年の e コマース売上高は 1 兆 1,187 億 USD（前年比 7.6% 増）で、総売上高の 15.4% を占め、世界全体では 7.4 兆 USD に達しています。小売企業は優れた購買体験やカスタマーサービスを提供するため、スマートなデジタルコマースプラットフォームに注目しています。 生成 AI などの革新的な技術が e コマースに新たな機会をもたらし、先進企業はフルフィルメントの自動化やパーソナライズされた顧客体験の提供を行っています。多くの大規模小売企業は、従来の e コマースに代わり、新しいデジタルアーキテクチャに投資しています。デジタルコマースはオムニチャネル体験を提供し、俊敏で柔軟性があり、費用対効果の高いプラットフォームであることが不可欠です。リアルタイムストリーミングや会話型コマース、パーソナライゼーションなどの機能により、新たな消費者層へのリーチやコンバージョン率の向上に役立ちます。 モダナイゼーションのステップ：デジタルコマースの可能性を引き出すための 4 つのステップ AWS は小売企業向けに、e コマースプラットフォームを構築するための 4 段階のプロセスを推奨しています。これは、既存のデジタル投資を活用しつつ、クラウド機能を導入することで、迅速な成功と優れた顧客体験の提供を目指すものです。 俊敏で費用対効果の高いデジタルコマースプラットフォームを構築する パーソナライズされた没入型の体験を提供してコンバージョン率を高める 革新的なソリューションでより多くの消費者にリーチする 消費者の期待に応え、それを上回る ステップ 1：俊敏で費用対効果の高いデジタルコマースプラットフォームを構築する 小売企業の目標は、チャネル間でスムーズかつ切れ目のない顧客体験を実現することです。これには俊敏で費用対効果の高いデジタルコマースが不可欠です。クラウドへの移行により、企業はその多機能性を活用して費用対効果を得られます。 モダナイズされた IT インフラを持つ小売企業は、マイクロサービスアーキテクチャを導入し、個別のビジネス機能を API で組み合わせることができます。これによりコマースアプリケーションを大規模に構築できます。 また、ヘッドレスコマースの手法により、バックエンドサービスをフロントエンド（POSシステム、e コマースサイト、モバイルアプリなど）から分離します。これらの手法により、企業はどのチャネルからでも一貫した顧客体験を提供し、さらにその体験をパーソナライズして、コスト削減とイノベーション促進を実現できます。 AWS への移行で、企業はコストを最大 66% 削減しながら、スケーラビリティ、柔軟性、セキュリティを向上させられます。 小売企業は、レガシーアプリケーションをクラウドに移行することで、モダンなデジタルコマースプラットフォームへの移行を開始できます。徐々にマイクロサービスベースのプラットフォームへの投資を増やしながら、古いシステムを段階的に廃止できます。また、業界団体への加入は市場での優位性獲得に役立ちます。AWS は 2022 年に MACH Alliance に加盟し（関連 ブログ ）、小売企業が自由にソリューションを組み合わせ、新機能を提供し、優れた顧客体験を構築できる共通の e コマースアーキテクチャの構築を支援しています。 例えば、英国第 2 位のスーパーマーケットチェーン Sainsbury’s は、AWS への移行により、年に 5～6 回だったプロダクトリリースが 1 日に複数回行われるようになり、カスタマーエンゲージメントが 5 倍に増加しました。 ステップ 2：パーソナライズされた没入型の体験を提供してコンバージョン率を高める e コマースウェブサイトは、優れた顧客体験を通じたコンバージョン率の向上を目指しています。これには購入プロセスから「フリクション」、つまりは煩雑さを減らすことが重要です。ページ読み込み速度の改善、検索の効率化、チェックアウトの簡素化などが効果的です。AR（拡張現実）、パーソナライズ、ライブストリーミングなどの新機能導入も、顧客満足度とロイヤルティの向上に貢献します。 AWS は継続的に新しい e コマースツールやソリューションに投資し、パートナーコミュニティを拡大しています。AWS への移行により、企業は既存のパッケージツールを活用してデジタルコマースの運用を効率化し、コンバージョン率と売上を向上できます。これにより企業はリスクと資源を抑えつつ、革新的な商品開発が可能になります。 AWS for Retail は、没入型小売体験の創出に必要な高度なコンピューティング能力を提供し、新世代の顧客体験をサポートします。 AWS とそのパートナーは、小売企業向けに多様なソリューションを提供しています。これらは顧客体験の最適化、運用効率の向上、売上増加を目的としており、以下のようなソリューションがあります。 Amazon Personalize によるパーソナライゼーション Amazon Interactive Video Service と Firework を使用したライブストリーミングと動画内ショッピング Amazon OpenSearch Service や Algolia 、 Constructor などによる強力な検索機能 Amazon CloudFront による高速コンテンツ配信 Amazon Lex を利用したチャットボット Hexa によるモバイルでの 3D 商品表示とバーチャル試着 Matterport と Obsess を活用した仮想ストア 企業は 3D コマース、AR、バーチャル試着などを活用してオンラインで実店舗に近い体験を提供できます。没入型の小売ソリューションは、ブランド価値の維持とデジタルトレンドセッターとの連携を支援して購買体験を変革します。 例えば、大手オンラインアパレル小売企業の Zappos は、AWS への移行により、e コマース体験を大幅に改善しました。分析と機械学習を用いて、消費者に合わせたサイジングや検索結果を提供し、99% の検索を 48 ミリ秒未満で完了させるなど、高速で柔軟な顧客体験を提供しています。 ステップ 3：革新的なソリューションでより多くの消費者にリーチする 消費者はスムーズな商品発見、パーソナライズされた体験、多様なサービスチャネル、セルフヘルプオプションなどを求めています。また、ソーシャルメディアを通じた e コマースビジネスの潜在価値は高く、2025 年には米国で 1,000 億 USD 規模に成長すると予想されています。 小売業のデジタルマーケティング担当者は、多様なアプローチを追求し、ターゲット層に応じた戦略を立てる必要があります。こうしたことに対して、企業はオンラインマーケットプレイスやソーシャルコマースプラットフォームを通じて、高度な購買体験を提供する必要があります。 オムニチャネルデジタルコマースでは、 AI や機械学習を活用して、適切な消費者に適切なタイミングでリーチできます。Amazon のようなデジタルマーケットプレイスの構築も、ブランドのリーチ拡大に有効な方法です。 世界中の小売企業が AWS とそのパートナーと協力し、最先端のデジタルコマースプラットフォームを構築しています。これには、ゲームプラットフォームでの商品広告配信、 Amazon Pinpoint や Amazon Advertising などを活用した自動化されたインテリジェントなマーケティングシステム、そしてオンラインマーケットプレイスが含まれます。特に Amazon Pinpoint は、多様なチャネルを通じて顧客とつながる柔軟なマーケティングサービスを提供し、業界トップクラスの配信率を実現しています。また、AWS パートナーの Cisco Meraki はスケーラブルなマーケットプレイス作成を容易にするプラットフォームを提供しています。 例えば、日本のオンラインスナック小売企業の snaq.me は、約 5 万人の会員にパーソナライズされたおやつを提供しています。以前の独自システムの問題を解決するため、Amazon Pinpoint に移行しました。これにより、適切な対象者に的確なメッセージを届けられるようになり、日常業務が 4 時間短縮され、1 日あたりの売上収益が 3 倍に増加しました。 ステップ 4：消費者の期待に応え、それを上回る 効果的なデジタルストアフロントを構築した後、小売企業は顧客ロイヤルティの維持に注力する必要があります。これには、多様な買い物方法のサポートと効率的な注文処理が不可欠です。つまり、適切な商品を適切な場所に適切なタイミングで届けるという基本に常に対応することです。革新的な小売企業は、BOPIS（オンラインで購入して店舗で受け取り）、BOSFS（オンラインで購入して店舗から配送）、ROPIS（オンラインで予約して店舗で受け取り）などのフルフィルメントオプションを提供しています。また、「エンドレスアイル」を設けて、店舗にない商品の直接配送も可能にしています。 返品と交換のプロセスも簡素化し、顧客のニーズに応じて様々なオプションを提供しています。 これらの複雑なサービスと物流プロセスを管理するため、クラウドベースのソリューションが有効です。これにより、ジャストインタイム配送や円滑な返品処理が可能となり、長期的に顧客満足度を維持できます。 AWS は 20 年以上にわたり、小売企業向けの優れたショッピング体験を提供するソリューションを支援してきました。主な例として、オムニチャネルフルフィルメント、 Amazon Connect による効率的なカスタマーサービス、インテリジェントなサプライチェーン管理、スマートストアの実現、分析と機械学習による顧客離れの低減、ラストマイルフルフィルメントの強化、生成AIを活用した効率性の向上などがあります。これらのソリューションにより、小売企業は顧客満足度を高め、業務効率を改善し、競争力を維持できています。 例として、英国の大手食料品チェーン Morrisons は、Amazon Connect を導入し、8 週間で俊敏でスケーラブルなクラウドベースのコンタクトセンターを実装しました。これにより、新しい顧客体験の提供と自立した運用が可能になりました。 一方、高級フットウェアブランドの Kurt Geiger は、オンライン顧客体験の向上に取り組んでいましたが、不正広告によるカスタマージャーニーの中断に悩まされていました。AWS パートナーの Namogoo の機械学習ソリューションを導入し、不正広告をブロックした結果、コンバージョン率が 6% 向上し、400 万ポンド以上の収益回復を実現しました。 次のステップ：AWS でデジタルコマースの最適化を実現する 小売企業の成功には、イノベーションと最適化が不可欠です。AWS は、世界最先端の小売業から生まれたクラウドサービスのリーダーとして、消費者の期待に応え、運用を最適化し、ビジネスインサイトを強化するソリューションを提供しています。 AWS を活用するためのステップとして、現在のプラットフォームの評価、迅速な成功機会の特定、AWSソリューションの検討、AWSリテールコンピテンシーパートナーとの連携が挙げられます。AWS にご相談いただき、競合他社に先駆けて市場機会をつかみ、再現性のある成功を実現しましょう。詳細は、本 e-book やその他の e-book もぜひご覧ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。

本ブログは、カシオ計算機株式会社と Amazon Web Services Japan が共同で執筆しました。 カシオ計算機は、時計、電子辞書、電卓、電子文具、電子楽器などを手掛けており、グループ全体で 9,594 名（ 2024 年 3 月末時点）が所属しております。 同社では、全社員に向けて 2023 年より社内業務支援のため AI チャットボットの検討および試行を開始し、2024 年 3 月に全社展開を行いました。 AI チャットボットではコード作成支援や技術調査、文書作成やアイデア創出など多様な業務利用が想定され、精度が良く且つ用途にあった基盤モデルを都度選択できる必要があり Amazon Bedrock の採用しています。 採用アーキテクチャ 本チャットボットシステムは専用線を用いた閉域網で社内利用できるようにして、フロントエンドは Next.js 、バックエンド処理は FastAPI で実装しました。また、これらのアプリケーションはコンテナ化した上で AWS App Runnner でホストし、 Amazon Bedrock の複数の基盤モデルを利用できるようにしています。 また、 2024 年の全社展開後、 3 月に公開された Anthropic の  Claude 3 Sonnet をすぐに利用できるように対応し、さらに Anthropic の  Claude 3.5 Sonnet については 6 月の公開から数日のスピードで実装及び検証、公開を実現しました。 このスピード感を実現できた背景として、実装に AWS 標準のライブラリである Boto3 を使ったことがあげられます。 Boto3 はストリーミング処理など複雑な処理を簡単に実装でき、 LangChain などの外部ライブラリを使わずとも、 Boto3 の豊富な機能で柔軟な開発が可能でした。さらに、利用する基盤モデルの切り替えも、モデルの指定を変更するだけで対応できるため、非常にシンプルかつ効率的に実現できています。 今後も新しい基盤モデルが提供され次第、有用性を見極めたうえで、順次利用できるようにアップデートしていきます。 その他のアーキテクチャのポイントとしては、プロンプトログを Amazon DynamoDB に保存しており、 zero-ETL により Amazon OpenSearch Service へ連携し、ダッシュボードでの可視化によりリアルタイムでの利用状況分析を可能にしています。 AWS CodePipeline を利用した CI/CD にも対応し、自動ビルドや自動デプロイを実現しており、機能追加や拡張に迅速に対応可能な環境を整備しました。 これらのインフラ環境は全て IaC ( AWS CDK ) で実装しており、これによりシステム構成の変更や環境の横展開などデプロイ作業における柔軟かつ迅速な対応を実現しています。 今回の社内 AI チャットボットは、カシオ計算機の CCoE および AI アルゴリズム開発部の 3 名を中心に実装し、内製で 1 ヵ月程度で構築を完了しました。 利用状況 本チャットボットシステムは、グループ会社を含むカシオ計算機国内従業員に公開されています。 2024 年 9 月現在で 1,600 人強の登録者がおり、そのうちアクティブユーザは約 1,200 名 となっています。現時点ではコーディングサポートとしての利用が最も多く、次いで文章作成/構成、検索、翻訳、ブレストが続きます。特に Claude 3.5 Sonnet はコーディング能力と日本語能力が非常に高く、多種多様な業務に幅広く活用されており、社員の生産性向上に大きく寄与しています。 今後の展望 現在、カシオ計算機内での社内チャットボットの利用は、前述のようにシステム開発業務が中心ですが、アイデア出しなど創造性の高い業務への生成 AI の活用も徐々に広がってきています。 Anthropic の Claude 3.5 Sonnet をはじめとした日本語性能の高い高品質な生成AIに大きなポテンシャルを感じており、今後も利用ユースケースの拡大を狙い、今後も社内での周知を通して浸透を図る予定です。 また、 PoC レベルでは画像生成や PDF 解析、 RAG による社内文書検索の実装等も進めており、ガイドライン整備や精度向上のチューニング等が完了次第、順次全社展開していく予定です。特に RAG に関しては大きな期待を寄せており、さらなる業務効率化や生産性向上を目指して日々対応を進めています。 まとめ カシオ計算機で実用化された社内 AI チャットボットにより、 Amazon Bedrock を利用して社員のスキルの底上げを図ることができました。今後は更なるユースケース拡充を狙って、 AWS サービスを活用した RAG や基盤モデルのバリエーション増を検討し活用の幅を広げていきます。 シニアソリューションアーキテクト 秦 将之

本ブログは、小売業向け AWS の e-book 「スマートストアテクノロジーの力を活用する」の概要と、具体的なユースケースと関連する技術のハイライトを解説するものです。このガイドは、インテリジェントなクラウドベースのテクノロジーによってカスタマーエクスペリエンスを変革し、店舗オペレーションを自動化する実践的な方法に関心を持っている流通・小売業の意思決定者の方々を対象としています。 スマートストアイノベーションの紹介 実店舗が流通・小売業の基盤であり続ける理由 オンライン売上が増加する中、2024 年の米国小売売上の 72% は依然として実店舗が占める見込みです。これは、実店舗は、買い物客が商品を発見、吟味し、見て触れて、購入する人気の場所であり続けているためです。消費者はここ数年で当たり前になったデジタルツールや非接触型サービスを求めており、流通・小売業者はオムニチャネルコマースに適応して消費者の期待に応えるデジタルトランスフォーメーションを実現する必要があります。また、購買行動の主な傾向として、デジタル技術の使用、パーソナライズされた体験、体験重視の売り場への期待、デジタルの影響を受ける店舗での売上などが挙げられます。 クラウドネイティブソリューションの成熟度が低い現在は、実店舗変革の好機です。しかし、多くの流通・小売業者がクラウドを重視しているものの、クラウドファースト運用の加速にはまだ課題があります。 小売体験を変革するスマートストア AWS のスマートストアソリューションは、流通・小売業者の競争力維持に貢献します。主な特徴は以下のとおりです。 フリクションレスチェックアウトによるスムーズな購買体験 コンピュータビジョン技術を用いた在庫管理と購買行動分析 顧客ロイヤルティデータと購入履歴を活用したて、店舗でのパーソナライズドされたオファーの提供 効果的な勤務管理ソリューションによる従業員の生産性向上 これらの機能により、カスタマーエクスペリエンスの向上、オペレーションの効率化、市場変化への迅速な適応が可能となります。AWS はクラウドテクノロジーを活用し、流通・小売業界のイノベーションをリードしています。AWS for Retail は、幅広いサービスとテクノロジーを提供し、多くの小売業者がデジタル機能のデプロイや実店舗のアプローチ変革に活用しています。本 e-book では、店舗オペレーションの強化や従来のチェックアウト体験を刷新するソリューションなど、具体的な機能やユースケースを紹介しています。 AWS スマートストアテクノロジーで流通・小売業のイノベーションを加速する 流通・小売業界では、デジタルと現実の融合による変革が進んでいます。AWS のスマートストア機能を活用することで、顧客体験の向上と店舗オペレーションの効率化が可能です。これにより、イノベーションの加速、コスト削減、ビジネスの成長に合わせたスケーリングが実現できます。スマートストアの例として 3 つの観点で様々なユースケースが挙げられています。1) 店舗でのデジタル活用では、ユニファイド/コンポーザブルコマースやパーソナライズされたレコメンデーション、リテールメディアネットワークなど、2) 店舗オペレーションの自動化では、店舗フルフィルメントやスマートな在庫管理、損失防止など、3) 決済体験では、フリクションレスチェックアウトや非接触型の本人確認と支払い、RFID と IoT チェックアウト などです。これらのいくつかをハイライトとして取り上げます。 店舗でのデジタル活用 買い物客は、店舗での体験にさらに多くのことを期待しています。AWS スマートストアの機能では、体験と期待の両方を変革するテクノロジーを活用できます。AWS のスマートストアソリューションにより、流通・小売業者は、顧客満足度を高める迅速でスムーズかつ魅力的なショッピング体験を提供しながら、オペレーションの俊敏性を高めることができます。 ユニファイドコマースとコンポーザブルコマース ユニファイドコマースは、チャネルや接点に関わらず統一された顧客体験を提供し、顧客満足度とブランドロイヤルティを向上させます。多くの流通・小売業者は、柔軟な「コンポーザブル」なソフトウェアアプリケーションを採用してオペレーションを統合しています。AWS は ISV パートナーと協力し、 MACH アライアンス のメンバーとして、コンポーザブルコマースアーキテクチャを促進し、流通・小売業者のシステムモダナイゼーションを支援しています。この MACH 原則に沿って販売チャネルを開発した流通・小売業者は、競合他社より 80% 迅速に新機能をデプロイできるようになります。 パーソナライズされたレコメンデーション 消費者は高度なパーソナライゼーションを求めており、 Amazon Personalize はこのニーズに応える機械学習ソリューションを提供しています。オーストラリアの 美容・スキンケア企業 Mecca は、Amazon Personalize を導入 後、迅速にカスタマイズされた商品レコメンデーションを生成し、週に 1,000 万件以上のレコメンデーションをマーケティングキャンペーンで活用しています。 リテールメディアネットワーク 店舗内広告は消費財ブランドが買い物客に製品を紹介するために使用され、AWS for Retail のデジタル機能によってブランドは店内の顧客をターゲットにでき、小売業者は店舗内広告を収益化できます。 Amazon フレッシュ はその良い例で、AWS のデマンドサイドプラットフォーム（DSP）を使用してブランドは広告スペースを獲得し、顧客へのリーチを細かく管理できます。 店舗オペレーションの自動化 流通・小売業者は、店舗を最大限の効率で運営し、消費者に再来店してもらうために、日々さまざまな業務活動に取り組んでいます。スマートストアテクノロジーは、エッジコンピューティング、店舗フルフィルメント、損失防止、勤務管理ソリューションなど、最新のクラウドソリューション、IoT デバイス、分析によって、流通・小売業者の極めて複雑な店舗オペレーションを支援します。 店舗フルフィルメント AWS のクラウドベース e コマースサービスを導入した英国の大手食料品店チェーンが、AWS パートナーの支援を得て、オンライン注文から配達までの効率的なシステムを構築し、ラストマイル配送のパートナーとともに最適化されたルートで商品を配送している事例が紹介されています。 スマート在庫管理 消費財企業は店舗の棚画像をリアルタイムに在庫や棚割り分析する新技術を活用しており、AWS はシンガポールを拠点とする Trax と提携してグローバルなデータ分析を行っています。このように在庫を理想的なレベルに保つよう商品の需要を正確に予測するために Amazon SageMaker を用いて大規模な機械学習を行えます。 損失防止 流通・小売業者は、エッジテクノロジーと IoT を活用した損失防止ソリューションで利益の保護を図っています。Edge as a Service（EaaS）は、盗難防止、在庫管理、従業員安全確保などのメリットを提供します。 Rigado の IoT Edge-as-a-Service は、AWS リテールコンピテンシーパートナーソリューションとして、小売業者のスマートストア移行を支援し、RFID と IoT 技術で在庫監視と店舗安全管理を可能にしています。 決済体験 過去 1 年間で、米国の消費者 10 人中約 9 人が、待ち時間が長いことを理由に実店舗での購入を避けています。これは、消費者の 85% がチェックアウト体験を「非常に重要」または「重要」と捉えている一方で、チェックアウト体験に満足しているのがわずか 23% にすぎない理由の一つでもあります。 AWS for Retail では、チェックアウト処理を簡素化する幅広いソリューションを用意しています。そのいくつかを取り上げます。 フリクションレスチェックアウト 流通・小売業者は、顧客の利便性向上と店舗生産性向上のため、セルフレジやスキャンアンドゴーなどのフリクションレスソリューションを導入しています。 Amazon の Just Walk Out テクノロジー は、買い物客が商品を手に取ると自動的に仮想カートに追加され、店を出る際に自動精算される先進的なシステムで、レジ待ちのない快適なショッピング体験を提供しています。 非接触型の本人確認と支払い Amazon One は手のひらを使用する高速かつ便利な非接触型の本人確認サービスです。デバイスの上に手のひらをかざすだけで、店舗や施設に入り、本人確認を行って、商品やサービスの代金を支払うことができます。これは、店舗運営者にとって顧客満足とロイヤルティを高める手段にもなります。 RFID と IoT チェックアウト RFID は小売店での商品追跡に使用される無線技術です。 AWS リテールコンピテンシーパートナー である TensorIoT はフリクションレスチェックアウトシステムの設計・デプロイを支援しています。韓国の Uncommon Store は AWS の支援を受けて完全無人店舗を実現し、デバイスデータや動画ストリームの管理に AWS IoT Core や Amazon Kinesis Video Streams を活用しています。また、Amazon はこの技術を レジなし店舗という体験 にも応用できると考えています。 AWS リテールコンピテンシーパートナーと共にイノベーションを加速する コンポーザブルアプリケーションは MACH に準じた開発フレームワークをベースとしているため、流通・小売業者はヘッドレス API アーキテクチャレイヤーの上にビルディングブロックのマイクロサービスを組み合わせることができます。ビルディングブロックは、スマートストアポートフォリオで構成されています。このポートフォリオには、流通・小売業者を実装へと導くユースケースと重要な統合ポイントが含まれます。 AWS リテールコンピテンシーパートナー は、ユニファイドコマースやコンポーザブルコマース、カスタマーエンゲージメント、サプライチェーンと流通、実店舗/デジタルストア/仮想ストア、高度な小売データサイエンス、小売の基幹業務アプリケーションにわたり、流通・小売業者のイノベーションジャーニーを加速する革新的なテクノロジーサービスを提供します。 まとめ: Born from Retail, built for retailers AWS は、世界で最も大きく最も成功している流通・小売業者の 1 つである企業のもとで生まれました。AWS のスマートストアのサービスでは、その経験を共有し、流通・小売業者が「実験とイノベーションの迅速化」「需要に合わせた迅速なスケール」「テクノロジー投資の最適化」を実現できるようにご支援します。 店舗にインテリジェンスを導入することで、顧客満足度向上と売上増加というメリットを享受できるようになります。AWS と、その幅広い業界パートナーネットワークが、流通・小売業の変革をどのようにサポートできるかの詳細について、ぜひ e-book やその他の e-book をご覧ください。 消費財企業が成長するための極意 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。

本記事は 2024 年 10 月 1 日に公開された “ New – Size flexibility for Amazon ElastiCache reserved nodes ” を翻訳したものです。 Amazon ElastiCache は、完全マネージド型の Redis OSS と Memcached 互換のキャッシングサービスです。2024 年 10 月 1 日より、すべてのリザーブドノードオファリングでサイズの柔軟性をサポートするようになりました。これにより、予約時に指定したサイズ以外のノードタイプに対してもリザーブドノード割引が適用されるようになります。 サイズの柔軟性をサポートしたリザーブドノードでは、予約購入時に特定のノードサイズを指定する必要がなくなり、キャパシティプランニングのオーバーヘッドが削減され、ワークロードやキャパシティの変化に合わせてクラスターのサイズを調整できるようになります。この記事では、この新しいサイズ柔軟性機能により、ElastiCache クラスターに割引価格がどのように適用されるかを説明します。 Amazon ElastiCache は、数十万人のお客様のアプリケーションのパフォーマンスを向上させ、より高いスケーラビリティを実現し、コストを最適化するのに役立っています。ElastiCache は、データキャッシング、Web、モバイルアプリ、ヘルスケアアプリ、金融アプリ、ゲーム、アドテック、IoT (モノのインターネット)、メディアストリーミング、セッションストア、リーダーボード、機械学習 (ML)、マイクロサービスベースのアプリケーションなど、高パフォーマンスが必要とされる用途に適しています。ElastiCache はフルマネージドサービスであり、キャッシュのハードウェアプロビジョニング、監視、ノード交換、ソフトウェアパッチ適用の管理をお客様にかわって支援します。 ElastiCache には、サーバーレスとセルフデザイン (ノードベース) の 2 つのデプロイオプションがあります。ノードベースのクラスターの場合、ノードタイプ、ノード数、AWS アベイラビリティーゾーン間でのノード配置を選択します。 リザーブドノード を購入して、1 年または 3 年の期間 ElastiCache ノードタイプを予約し、オンデマンドノード価格に比べて割引 (最大 55%) を受けることができます。ElastiCache リザーブドノードは、前払い不要、一部前払い、全額前払いの構成で利用できます。長期契約でより多くの前払いをすれば、予約期間中の割引率が高くなります。 従来は、特定のインスタンスタイプ (例: cache.r7g.xlarge) の予約を購入した場合、指定されたタイプに対してのみ割引が適用されていました。これにより クラスターのスケールアップまたはダウン のためにノードサイズを変更した場合、リザーブドノードによる割引が適用されなくなっていました。 この柔軟性の欠如により、リザーブドノードでは 1 年または 3 年の期間の使用を予約する必要があるため、長期的な容量計画が困難になっていました。 2024 年 10 月 1 日以降、すべての ElastiCache リザーブドノードはより柔軟になり、特定の AWS リージョンとキャッシュエンジン (Redis OSS または Memcached) のノードファミリー (例: cache.r7g) 内のすべてのノードサイズに適用されるようになります。割引料金は利用に応じて自動的に適用されるため、リザーブドノード割引を実行中のキャッシュノードに合わせる必要がなくなり、管理オーバーヘッドが軽減されます。 割引料金を計算するために、各 ElastiCache ノードには ユニット で測定される 正規化係数 があります。リザーブドノードユニットは、リザーブドノードのインスタンスファミリー内の実行中のノードに適用できます。任意のノードの正規化係数を確認するには、 ノードサイズチャート を参照できます。これは、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Relational Database Service (Amazon RDS) などの他のサービスが、予約のサイズを柔軟に変更できるプロセスと同様です。 シナリオ 1: クラスターのスケールアウトとスケールダウン 例えば、Memcached エンジンで cache.r7g.4xlarge ノード (正規化係数 32) のリザーブドノードを購入した場合です。 このリザーブドノードは、同じリージョン内の任意の Memcached cache.r7g ノードで使用できます。 ノードサイズを小さくしてより多くのノード (同じアカウント内の同じクラスターまたは別のクラスター内) を実行し、リザーブドノードの恩恵を受けることができます。 例えば： cache.r7g.large ノード 8 台 (8 * 4 = 32 ユニット) cache.r7g.xlarge ノード 4 台 (4 * 8 = 32 ユニット) cache.r7g.2xlarge ノード 2 台 (2 * 16 = 32 ユニット) cache.r7g.4xlarge ノード 1 台 (1 * 32 = 32 ユニット) シナリオ 2: 異なるサイズのノードの併用 この cache.r7g.4xlarge のリザーブドノードは、cache.r7g.large ノード 4 台 (4 * 4 = 16 ユニット) と cache.r7g.xlarge ノード 2 台 (2 * 8 = 16 ユニット) のような、異なるサイズのノードの組み合わせにも使用できます。 リザーブドノードの価格は、自動的に、より大きなサイズのノードタイプに適用される前に、同じ種類の中で実行中の小さいサイズのノードタイプに適用されます。リザーブドノードの恩恵を受けるインスタンスを選択することはできません。 たとえば、cache.r7g.large ノード 8 台 (32 ユニット) とcache.r7g.4xlarge ノード 1 台 (32 ユニット) を実行している場合、cache.r7g.large ノード 8 台がリザーブドノードによってカバーされます。 シナリオ 3: クラスターのスケールアップ リザーブドノードよりも大きなノードを実行する場合、超過分に対して時間単位の オンデマンド価格が課金されます。例えば、実行中の 2 ノード cache.m7g.large Redis OSS クラスターをカバーするために、cache.m7g.large Redis OSS のリザーブドノードが 2 つある時、より多くの vCPU を活用するために cache.m7g.2xlarge ノードを使用してクラスターをスケールアップしたい場合を考えます。リザーブドノードの合計は 8 ユニット (ノードのサイズに対応した単位) で、新しいクラスター (16 ユニット) の 50% のリソースを確保できます。つまり、1 つの 2xlarge ノードに相当します。残りのノードは、cache.m7g.2xlarge ノードの時間単位の オンデマンド価格に基づいて課金されます。また、追加で 1 つの cache.m7g.2xlarge リザーブドノードを購入すれば、クラスター全体のリソースを確保できます。 シナリオ 4: クラスターのスケールダウン 所定の使用時間内に適格な実行中のノードが足りない場合、その時間の残りのリザーブドノードユニットは無駄になってしまいます。例えば、Redis OSS エンジンの cache.t4g.medium リザーブドノードがあり、1 ノードの Redis OSS クラスターを cache.t4g.small にスケールダウンした場合、その地域で他の Redis OSS cache.t4g ノードを起動しない限り、残りの 1 ノード分のユニットは消失してしまいます。 結論 ノードタイプの柔軟性は、すべての ElastiCache エンジンのすべてのリージョンで利用できるようになり、10 月 1 日から既存および新規購入のリザーブドノードに自動的に適用されます。柔軟なリザーブドノードの詳細については、 Amazon ElastiCache リザーブドノードページ をご覧ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Kevin McGehee は、Amazon In-Memory Databases チームのプリンシパルエンジニアです。優秀な開発者と共に、パフォーマンスが高く保守性の高いシステムを構築することに情熱を注いでいます。 Goumi Viswanathan は、Amazon In-Memory Databases チームのシニアプロダクトマネージャーです。 12 年以上のプロダクト経験があり、データベースソリューションを提供するクロスファンクショナルチームをリードしています。 仕事以外では、旅行と屋外での時間を楽しんでいます。

みなさま、こんにちは！Generative AI Specialist の大渕です。この記事では、RAG (Retrieval Augmented Generation) を使って自社の課題を解決したり自社サービスを強化したりしたいと考えているみなさまに耳寄りな情報をお届けします。 2024年9月19日に、RAG に関する悩みを持っている方を対象とした AWS オンラインセミナー「RAG の困りごとは今日で一気に解決！ AWS 生成 AI Dive Deep」が開催され、実用的な情報盛りだくさんの 3 つのセッションが実施されました。セミナーの見どころとしては、以下のとおりです。いずれかにピピっと来たら、ぜひこの記事を読み進めてください。 RAG の概要ではなく、実践的なテクニックや開発の進め方を知ることができる RAG でよくある課題とその解決策を具体的に知ることができる RAG に欠かせない AWS サービスとその使い分けを知ることができる セッションの紹介 それではさっそく、セッションの内容を紹介します。資料と動画も公開されているので、詳しく知りたい方はそれぞれのリンクをクリックしてください。 RAG on AWS dive deep [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 公共部門ソリューションアーキテクト 宮口 直樹 はじめのセッションでは、SA 宮口より、RAGを構築する上で多くの方が悩むであろう、ベクトル DB、埋め込みモデル、チャンキングなどの各コンポーネントのサービス選定のポイントを紹介しました。それぞれのコンポーネントを実現する AWS サービスや OSS の選択肢を知り、それぞれの特徴や機能の違いを理解することで、ユースケースに合わせてサービスを選択できるようになります。また、基盤モデルの進化に伴い、テキストだけではなくマルチモーダル RAG も実用レベルになってきたことから、マルチモーダル RAG の概要と実現方式についても紹介しました。 あなたの RAG の精度を改善！Advanced RAG on AWS のすヽめ [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 機械学習ソリューションアーキテクト 本橋 和貴 2つ目のセッションでは、SA 本橋より、RAG の精度改善のさまざまなテクニックを紹介しました。「 Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証 」という AWS ブログでも紹介した Advanced RAG のそれぞれの手法と使いどころが説明されており、RAG の精度改善に取り組もうとしている方にとって、非常に有用な内容となりました。また、精度改善のために闇雲にリッチな手法を適用するのではなく、都度評価を実施してどこに問題があるのかを明らかにした上で適切な手法を選んでいくべき、という指針にも言及がありました。最後には、Graph RAG に関する紹介もあり、今後も RAG がさまざまなユースケースで使われるだろうことが予見される締めくくりでした。 本セッションの内容をもとにしたブログ「 RAG の精度を向上させる Advanced RAG on AWS の道標 」も公開していますので合わせてご覧ください。 Retrieval-Augmented Generation (RAG) の評価 [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 Telco Solutions Architect 近藤 健二郎 最後のセッションでは、SA 近藤より、RAG の評価についての実践的な考え方やテクニックを紹介しました。RAG の評価方法として確立された手法はまだないため、実行しようとすると一筋縄ではいかないこともありますが、実用化に向けた試行錯誤の効果を測るには評価は欠かせません。そこで、一般的な RAG の評価に関する課題やよく利用される評価項目と、RAG 評価の実践的なプラクティスを紹介しました。これから RAG を試す人や RAG を構築中の人に、評価に関する気付きを与えるセッションとなりました。 いただいた質問と回答 セミナーでは、参加者の皆様からたくさんの質問をいただきました。代表的な質問と回答を以下にまとめたので、参考にしていただければ幸いです。 Q. RAG で使いたいドキュメントに表データがあるのですが、上手く読み込めていないようです。表データを含むドキュメントを扱う際の良い方法はありますか。 A. 前処理として LLM を用いた表のマークダウン化をお試しされてはいかがでしょうか。Amazon Bedrock Knowledge BasesのAdvanced Parsing (高度なパース) 機能では、LLM (Anthropic Claude 3) を用いた図表の読み取りが可能です。詳しくは こちらのブログ記事 をご参照ください。 Q. Cohere のリランキングモデルを AWS から使う方法を教えてください。 A. Cohereのリランキングモデルは、Amazon SageMaker JumpStart を通じて簡単にデプロイし、利用することができます。詳しくは こちらのブログ記事 “Improve RAG performance using Cohere Rerank” を参照してください。 Q. Graph RAG における LlamaIndex はどのような役割を担っていますか？ A. Amazon NeptuneはグラフDBであり、LlamaIndexのようなツールを用いることで、ドキュメントをグラフDBに格納可能な形式に変換して保存することができます。詳しくは LlamaIndexのドキュメント をご参照ください。 まとめ 生成AI の業務活用においてよく使われる RAG ですが、いざ業務で使おうとするとさまざまな課題に遭遇します。その課題は、速度や性能だったりしますが、どのように解決したら良いのか悩まれている方も多いと思います。このセミナーの内容が、そんな悩めるみなさまにとって、課題解決の糸口を見つけるきっかけとなれば幸いです。 RAG のベクトル DB の部分を Amazon OpenSearch Service で構築したいとお考えの場合、こちらの GitHub repo のサンプルコードがお役に立つかもしれません。CDK で実装されており、日本語テキストのためのトークナイザ Sudachi プラグインが適用された状態の OpenSearch domain を簡単に構築することができます。本セミナーの 2つ目の Advanced RAG のセッションで紹介されたテクニックを試すためのベースとしてお使いいただけます。

このブログは、第一三共株式会社 研究統括部 研究イノベーション企画部と、アマゾン ウェブ サービス ジャパン合同会社 ソリューション アーキテクト 中島丈博による共著です。 2024 年 6 月 20 日、21 日に幕張メッセで開催された AWS Summit Japan では、EXPO として AWS Village と呼ばれる展示エリアが用意され、AWS のサービスやインダストリーソリューションを扱う 90 以上のAWS 展示と、50 以上のお客様事例展示がございました。その中に展開された Industry Zone では、各業界向けの最新の AWS ソリューションの展示や、実際に AWS を活用している企業のブースも併設されました。 また、第一三共株式会社は業界セッション「 創薬を加速する第一三共のセルフサービス型クラウド基盤　～モブワークで挑む基盤内製と人材育成の両立～ 」へ登壇し、Industry Zone のヘルスケア・ライフサイエンス業界向けブースに出展されました。 今回のブログでは、Industry Zone の第一三共株式会社ブースで展示された創薬研究プラットフォームについて、プラットフォーム概要、AWS アーキテクチャをご紹介します。 第一三共株式会社における創薬研究プラットフォームのご紹介 第一三共株式会社は、革新的な医薬品を継続的に創出し、多様な医療ニーズに対応する製品を提供することで、世界中の人々の健康と豊かな生活に貢献することを目指している製薬企業です。医薬品の研究開発は、その膨大な時間とコスト、そして極めて低い成功確率から、非常に挑戦的な領域です。通常、新薬の開発には 10 〜 20 年という長い期間と、数百億から数千億円に及ぶ莫大な費用がかかります。また、創薬の成功確率は数万分の 1 とも言われており、ますます難易度が増しています。 このような課題に対し、私たちは最新の技術を活用して創薬プロセスの革新を試みております。実験自動化による効率の向上や時間短縮、AI・データサイエンス技術の導入による成功確率の向上が期待される中、これらを支えるデータ蓄積・解析基盤の構築が不可欠です。 当社では、ここ数年にわたり AWS クラウドを全面的に活用し、創薬研究の効率化と成功確率の向上を目指したプラットフォームを構築してきました。 本ブログでは、これらの取り組みから 実験データ転送の自動化 柔軟に利用可能なハイパフォーマンスコンピューティング (HPC) クラスター環境 収集・正規化されたデータの可視化と解析 の 3 つの活用事例についてご紹介します。 実験データの自動転送・処理 実験機器のハイスループット化は近年も著しく、データの効率的な転送や安全な保管は創薬研究においても重要な課題です。私たちのグループの次世代 DNA シーケンサー (NGS) は 1 回のランで数百 GB の生データを出力し、繁忙期には数日おきにランが行われています。従来のデータ転送は、大容量データの扱いに向かない GUI 操作や外付けストレージ（HDD、SSD）の輸送によって行われるケースが多くありました。これらは時間がかかる上に操作ミスによるデータの破損の危険を高めます。そこで私たちは、NGS のランの最中にリアルタイムでデータを Amazon Simple Storage Service (Amazon S3) バケットに転送するシステムを構築しました。Amazon S3 バケットは HPC 用ファイルシステムである Amazon FSx for Lustre と同期されており、Amazon S3 にアップロードされたデータは HPC 環境からアクセス可能です。結果として、NGS のラン終了の 1–2 時間後には出力されたデータの解析を始めることができ、研究サイクルの迅速化が達成されています。執筆時点では AWS コマンドラインインターフェイス (AWS CLI) を社内の PC から定期実行することでシステムを稼働させていますが、AWS では転送サービスの選択肢も多く、転送完了をトリガーとして AWS Lambda によりデータを自動処理するといった将来像も考えることができ、その拡張性は大きな魅力です。 柔軟に利用可能な HPC クラスター環境の開発 私たちのグループでは探索的な研究を主に行っており、トライ&エラーを頻繁に繰り返しています。新規の解析手法を試しても多くは採用されません。また、私たちが関わるバイオインフォマティクス分野はオープンソースの解析ツールが広く用いられており、それらの多くは必要リソースを明記していません。これらの要因によって、必要な計算リソースの見積もりは困難になっています。そのような背景において、AWS クラウド環境の柔軟性は大きな利点となります。 データ解析用の HPC 環境は AWS ParallelCluster を用いて構築し、GPU インスタンスを含めた様々な性能の Amazon EC2 インスタンスを、必要に応じてジョブスケジューラ（Slurm）から利用することができます。前述の NGS のデータ解析はファイル入出力の負荷も大きいのですが、ファイルシステムは Amazon FSx for Lustre を用いることで高速に処理を実行できています。ファイルシステムは Amazon S3 に関連付けておき、処理が終わったデータは Amazon S3 へアーカイブし Amazon FSx for Lustre からのリリースを行なっています。こうすることで、Amazon FSx for Lustre は作業場所、Amazon S3 は保管場所、という役割分担ができコストも抑えることができます。Amazon FSx for Lustre と Amazon S3 のデータ同期は速く、不便を感じることはありません。 その他、 NICE DCV を用いてゲノムブラウザ等の GUI アプリケーションを Amazon EC2 で実行しつつ PC 画面に結果を表示するアーキテクチャも構築しています。また、 AWS Batch を用いてコンテナ化された定型処理を実行可能です。様々な実行環境を備えておくことで、各ツールに応じて最適なものを選択できるようにし、効率良く探索的な創薬研究を行えるようになりました。 収集・正規化されたデータの可視化と解析 私たちのグループではデータを解析・可視化するだけでなく、他の研究者が自身で解析を行うための Web アプリケーションを提供しております。複数のアプリケーションを個別に管理することは多大な労力を要するため、アプリケーション公開のための基盤を構築しました。 この基盤は Amazon Elastic Container Service (Amazon ECS) を用いて設計し、Web ツールを展開するために必要なサーバーインフラの設定は、 AWS Step Functions を活用して全て自動化しました。これにより、開発者は Docker コンテナでアプリケーションを開発し、 Amazon Elastic Container Registry (Amazon ECR) に push するだけで、自動的に Web サーバーのポートが開き、その開いたポートにアクセスするだけでアプリケーションへの接続が可能となります。このような構成を構築したことにより、開発者はアプリケーション公開のための環境を整える必要がなくなり、アプリケーション開発という本質的な業務に集中できるようになりました。さらに、複数のアプリケーションを一つの基盤で管理できるため、効率性と一貫性が向上しました。また、研究データの中には、特許性や共同研究契約などの理由で、一部の研究者にしか閲覧が認められないデータも存在します。こうしたデータを扱うために、アプリケーションの閲覧権限も設定する必要がありました。それを実現するために、ユーザー認証機能を Amazon Cognito と Azure AD を組み合わせて実装しました。これにより、所属部署によってアクセス権を設定可能にし、ユーザー管理を個別に行うのではなく、所属部署で一元管理できるようになりました。これはアプリの管理者にとって、ユーザー管理の手間を大幅に減らし、効率的な運用を可能にしました。 以上のように、収集・正規化されたデータの可視化と解析に関する基盤は、開発者が本質的な業務に集中できる環境を提供し、効率的かつ安全なデータ管理を可能にしています。 アジャイルアプリケーション開発に取り組んだ事例の紹介 アプリケーション開発にあたって、開発者とユーザーのワーキンググループを結成し、ユーザーのニーズに基づいて研究データ解析のためのアプリケーション開発に取り組んでおります。内製でアプリケーション開発を行う場合、ユーザーと開発者との距離が近いため、コミュニケーションが密に取りやすいと実感しています。そのため、要件を適宜確認し、フィードバックを頻繁にもらい、アプリケーションの改善を複数回にわたって行ってきました。実際にこのアプローチにて医薬品候補化合物の活性評価試験結果を可視化するビューワーを作成しました。 ユーザーの意見を反映した可視化方法を採用する等により、データサイエンティストと研究者が共同で効果的なアプリケーションの開発を実現しました。 AWS アーキテクチャのご紹介 ここからは、創薬研究プラットフォームの「データサイエンティストの研究環境」と「研究者に向けたアプリケーションのデプロイ環境」についてそれぞれご紹介します。 データサイエンティストの研究環境 データサイエンティストの研究環境は AWS クラウドでのハイパフォーマンスコンピューティング (HPC) クラスターによって構成されており、両方の HPC クラスターでバイオインフォマティクスの分野で広く利用されているワークフローエンジンである Nextflow がセットアップされています。 解析環境は AWS ParallelCluster と AWS Batch を利用した 2 つの HPC クラスターについてご紹介します。 ジョブスケジューラー Slurm を利用可能な AWS ParallelCluster による解析環境 AWS ParallelCluster は AWS がサポートするオープンソースのクラスター管理ツールです。クラスター構成を yaml ファイルで定義すると、infrastructure as code (IaC) を使用してワークフローの各ステップのニーズに合わせて設定した Amazon EC2 インスタンスのクラスターをプロビジョニングします。 本環境ではバイオインフォマティシャンは AWS Systems Manager (SSM) Session Manager を利用してヘッドノードに SSH ログインしてジョブを実行します。SSM は、AWS アプリケーションおよびリソースを安全でセキュアにオペレーションするためのフルマネージドサービスであり、Session Manager はリソース管理のための SSM 機能です。ここではバイオインフォマティシャンがヘッドノードにインターネットを経由してセキュアに SSH アクセスするために利用しています。 AWS ParallelCluster では Nextflow の Executor 機能を利用することで、SLURM のリソースマネージャーを使用してパイプラインスクリプトを実行しています。こちらについては Nextflow のドキュメント や ブログ が参考となります。またストレージは 大容量データを取り扱うことから高パフォーマンスが求められるため、HPC で使用される分散ファイルシステムである Lustre をフルマネージドで提供する Amazon FSx for Lustre を利用しています。Amazon FSx for Lustre は Amazon S3 とシームレスに連携可能なため、様々な AWS サービスとのデータ連携が容易となります。 バッチコンピューティングのフルマネージドサービス AWS Batch による解析環境 AWS Batch は AWS クラウドでバッチコンピューティングワークロードを実行するためのフルマネージドサービスです。Docker コンテナイメージを利用可能でジョブの実行とコンピューティングリソース管理をAWSが実施するため、ユーザーは結果の分析や問題の解決に集中することが可能です。 Nextflow を AWS Batch で利用するには Nextflow のドキュメントに紹介されたマニュアル をもとに構築します。また、Nextflow は AWS Batch を サポート しており、Executor 機能を利用することが可能です。Nextflow ジョブはヘッドジョブとして実行され、その後パイプラインに定義したタスクに応じてタスクジョブが実行されます。ゲノムデータなどのインプットデータや解析によって得られたアウトプットデータは、Amazon S3 を利用してデータの取得と保存が可能です。 研究者に向けたアプリケーションのデプロイ環境 研究者に向けたアプリケーションのデプロイ環境は Docker コンテナの実行環境となります。 アプリケーションのユーザーであるバイオロジストはロードバランサーを介してコンテナ上で実行されるアプリケーションにアクセスします。その際、認証基盤はウェブアプリとモバイルアプリ用のアイデンティティプラットフォームである Amazon Cognito を利用しており、既存の Azure AD へのフェデレーションログインを可能としています。また Amazon Cognito は Application Load Balancer (ALB) と共に利用することで ユーザー認証機能をALB に実装可能 なため、認証機能をプラットフォームに実装することでセキュアな環境を構築しています。さらに開発者はアプリケーションに認証機能の実装は必要ないため、開発の負担を減らすことができます。 次に、アプリケーションのデプロイについてご紹介します。開発者が Web アプリケーションを Docker コンテナを利用して構築したら、Amazon ECR に Docker イメージを push します。push されると、それをトリガーにして Amazon EventBridge 経由で AWS Step Functions を起動します。AWS Step Functions はフルマネージドな AWS のワークフローサービスであり、様々なワークロードの自動化やオーケストレーションを大規模に実行可能なサービスです。今回実装したワークフローではロードバランサーの設定や認証機能の実装、コンテナイメージの実行を行っています。 おわりに 本ブログでご紹介した第一三共株式会社の展示や関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 第一三共株式会社 山田 倫太郎 (Rintaro Yamada) 研究イノベーション企画部 研究員: 創薬研究において、データ活用のためのクラウド環境構築や解析ツールの開発などをしています。趣味は、温泉巡りをすること、ピアノを弾くことです。 梶谷 嶺 (Rei Kajitani) 研究イノベーション企画部 専門研究員: 創薬のためのバイオインフォマティクス解析を行いつつ、クラウド環境構築や実験機器との連携の支援をしています。ゲノムに興味を持っています。 国本 亮 (Ryo Kunimoto) 研究イノベーション企画部 データ駆動型創薬担当: 創薬のためのバイオおよびケモインフォマティクス研究、及び研究環境構築に広く関わっています。 中川 寛之 (Hiroyuki Nakagawa) デジタル&テクノロジー部 研究領域担当: Cloud Center of Excellenceのメンバーとして、研究領域のクラウドネイティブな形態への変革とそれを支えるモード2ITの取り組みやアジャイルソフトウェア開発の価値観の普及に奔走しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。