12 月 2 日、NVIDIA H200 Tensor コア GPU と、AWS でのみ利用可能な 3.2 GHz のオールコアターボ周波数 (最大コアターボ周波数 3.8 GHz) のカスタム第 4 世代 Intel Xeon スケーラブルプロセッサーを搭載した Amazon Elastic Compute Cloud (Amazon EC2) P5en インスタンス の一般提供についてお知らせします。これらのプロセッサでは、メモリ帯域幅が 50% 向上し、PCIe Gen5 で CPU と GPU 間のスループットが最大 4 倍になるので、機械学習 (ML) トレーニングと推論ワークロードのパフォーマンスが大きく向上します。 P5en は、Nitro v5 を使用する最大 3200 Gbps の第 3 世代 Elastic Fabric Adapter (EFAv3) を搭載しており、前世代の EFA と Nitro を使用する P5 に比べてレイテンシーが最大 35% 向上しています。これにより、 深層学習 、 生成 AI 、 リアルタイムデータ処理 、 ハイパフォーマンスコンピューティング (HPC) などの用途における分散型トレーニングワークロードの集団通信パフォーマンスが向上します。 P5en インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) GPU (H200) ネットワーク帯域幅 (Gbps) GPU ピアツーピア (GB/秒) インスタンスストレージ (GB) EBS 帯域幅 (Gbps) p5en.48xlarge 192 2048 8 3200 900 8 x 3.84 100 9 月 9 日、 Amazon EC2 P5e インスタンスが発表 されました。このインスタンスは、1128 GB の高帯域幅 GPU メモリを搭載した 8 基の NVIDIA H200 GPU、第 3 世代 AMD EPYC プロセッサ、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージを備えています。これらのインスタンスは GPUDirect RDMA をサポートし、EFAv2 による最大 3200 Gbps の集約ネットワーク帯域幅を提供します。これにより、ノード間通信で CPU をバイパスすることでレイテンシーを低減し、パフォーマンスを効率的にスケールアウトすることが可能になります。 P5en インスタンスでは、推論とネットワークレイテンシーがさらに削減され、さまざまな GPU アクセラレーションアプリケーションの全体的な効率性を高めることができます。P5 インスタンスと比較して、P5en インスタンスでは、ローカルストレージのパフォーマンスが最大 2 倍向上し、 Amazon Elastic Block Store (Amazon EBS) の帯域幅が最大 25% 向上するので、ローカルストレージを使用してモデルの重みをキャッシュしているユーザーの推論レイテンシーパフォーマンスがさらに向上します。 頻繁なデータ交換を必要とする大規模なデータセットやワークロードでは、特に CPU と GPU 間のデータ転送に時間がかかる場合があります。P5 や P5e インスタンスと比較して、PCIe Gen 5 での CPU と GPU 間の帯域幅が最大 4 倍になるため、複雑な 大規模言語モデル (LLM) とマルチモーダル 基盤モデル (FM) に加えて、シミュレーション、医薬品発見、天気予報、財務モデリングなど、メモリを大量に消費する HPC 用途のモデルトレーニング、微調整、推論の実行におけるレイテンシをさらに改善できます。 Amazon EC2 P5en インスタンスの使用を開始する 米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京) の AWS リージョンで利用可能な EC2 P5en インスタンスは、 EC2 Capacity Blocks for ML 、オンデマンド、Savings Plan の購入オプションを通して使用できます。 オプションとしてキャパシティ予約を含む P5en インスタンスの使用方法を紹介したいと思います。EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で米国東部 (オハイオ) の AWS リージョンの [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 p5en.48xlarge インスタンス用の EC2 キャパシティブロックが必要な期間を指定します。EC2 キャパシティブロックを予約できる合計日数は 1～14 日、21 日、または 28 日です。EC2 キャパシティブロックは最大 8 週間前に購入できます。 [キャパシティブロックを検索] を選択すると、ユーザー指定の日付範囲内で仕様を満たす利用可能な最低料金のオプションが返されます。EC2 キャパシティブロックの詳細、タグ、および合計料金情報を確認し、 [購入] を選択します。 これで、EC2 キャパシティブロックが正常にスケジュールされます。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 Capacity Blocks for ML 」を参照してください。 購入したキャパシティブロック内でインスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して実行することができます。 ここでは、16 個の P5en インスタンスを実行して EFAv3 のメリットを最大化 する AWS CLI コマンドの例を示します。この構成では、8 つのプライベート IP アドレスで最大 3200 Gbps の EFA ネットワーク帯域幅と最大 800 Gbps の IP ネットワーク帯域幅が提供されます。 $ aws ec2 run-instances --image-id ami-abc12345 \ --instance-type p5en.48xlarge \ --count 16 \ --key-name MyKeyPair \ --instance-market-options MarketType='capacity-block' \ --capacity-reservation-specification CapacityReservationTarget={CapacityReservationId=cr-a1234567} --network-interfaces "NetworkCardIndex=0,DeviceIndex=0,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=1,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=2,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=3,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=4,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=5,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=6,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=7,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=8,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=9,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=10,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=11,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=12,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=13,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=14,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=15,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=16,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=17,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=18,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=19,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=20,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=21,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=22,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=23,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=24,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=25,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=26,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=27,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=28,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=29,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=30,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=31,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" ... P5en インスタンスを起動するとき、 AWS Deep Learning AMI (DLAMI) を使用して EC2 P5en インスタンスをサポートできます。DLAMI は、事前設定された環境でスケーラブルで安全な分散型 ML アプリケーションをすばやく構築するためのインフラストラクチャとツールを ML の専門家や研究者に提供します。 Amazon Elastic Container Service (Amazon ECS) または Amazon Elastic Kubernetes Service (Amazon EKS) のライブラリを使用して、P5en インスタンス上で AWS Deep Learning Containers でコンテナ化された ML アプリケーションを実行できます。 大規模なデータセットにすばやくアクセスするには、最大 30 TB のローカル NVMe SSD ストレージを使用するか、 Amazon Simple Storage Service (Amazon S3) で費用対効果の高い事実上無制限のストレージを使用することができます。P5en インスタンスで Amazon FSx for Lustre ファイルシステムを使用して、大規模な深層学習と HPC ワークロードに必要な数百 GB/秒のスループットと 1 秒あたり数百万回の入出力オペレーション (IOPS) でデータにアクセスすることもできます。 今すぐご利用いただけます 現在、Amazon EC2 P5en インスタンスは、EC2 Capacity Blocks for ML、オンデマンド、Savings Plan の購入オプションを通して、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京) の AWS リージョンと米国東部 (アトランタ) ローカルゾーン us-east-1-atl-2a でご利用いただけます。詳細については、 Amazon EC2 料金のページ を参照してください。 Amazon EC2 コンソール で Amazon EC2 P5en インスタンスを試してみてください。詳細については、 Amazon EC2 P5 インスタンスのページ を参照してください。フィードバックは、 EC2 の AWS re:Post 、または通常の AWS サポートの担当者までお寄せください。 – Channy 原文は こちら です。

データベース管理システム (DBMS) では、同時実行制御が重要な役割を果たし、複数のトランザクションを同時に実行できるようにします。これにより、データの矛盾や破損を防ぐことができます。同時実行制御とは、特に共有リソースにアクセスする際のトランザクションの相互作用を管理するメカニズムを指します。分散データベース管理システム (D-DBMS) では、データが複数のノードに分散しているため、データ複製、ネットワークの遅延、一貫性の維持などの課題が生じ、同時実行制御の重要性がさらに高まります。 効率的にスケールする分散システムを設計する際、絶え間ない調整を避けることが重要になります。そのため、コンポーネントは他のコンポーネントの状態を継続的に確認できないため、前提を立てる必要があります。これらの前提は、「楽観的」または「悲観的」に分類できます。楽観的な前提は、楽観的同時実行制御 (OCC) の中心的な考え方で、競合は稀であると想定し、ロックを使わずにトランザクションを進行させ、競合が発生した際にのみ解決します。この手法は、分散環境でのスケーラビリティ向上に特に有効ですが、ACID 特性 (アトミック性、一貫性、分離性、耐久性) を維持するために、堅牢な競合検出と解決が必要です。一方、悲観的な前提は、悲観的同時性実行制御 (PCC) の基礎をなすもので、競合は一般的に発生すると想定し、トランザクション中にリソースにロックをかけて干渉を防ぎます。これにより一貫性は確保できますが、スケーラビリティとパフォーマンスが制限される可能性があります。OCC と PCC のどちらを選択するかは、早期の調整を避けて後で競合に対処するか、事前に全てのトランザクション競合を防ぐかによって決まります。 この記事では、効率的なトランザクションパターンを設計するための貴重な洞察を提供し、一般的な同時実行性の課題に対する効果的な解決策の例を示しながら、同時実行制御について深く掘り下げます。また、 サンプルコード を含め、 Amazon Aurora DSQL (DSQL) での同時実行性性制御の例外を滞りなく管理する方法を紹介します。 PCC または OCC を使用する場合 OCC と PCC のどちらを選択するかは、ワークロードとデータベース環境に合わせて慎重に検討する必要があります。 PCC は、ロック管理を最適化できる単一インスタンスのデータベースに適しています。同じ株価指標を継続的に更新するような、小さなキー範囲での頻繁な更新が行われる高競合シナリオで優れた性能を発揮します。この手法は単一インスタンスの RDBMS では効果的ですが、分散システムでは効果が低くなります。 一方、OCC は、リソースのロックを行わずにトランザクションを進行させ、コミット段階でのみ競合をチェックすることで、低競合環境で最も優れたパフォーマンスを発揮します。これにより、実行オーバーヘッドとブロッキングの遅延が削減され、競合が少ない、またはノンブロッキングの実行が重要なワークロードに適しています。OCC は高競合シナリオの管理がより複雑になる可能性がありますが、水平スケーリングの恩恵を受けるスケーラブルなキー範囲や追加のみの操作などの分散システムを効果的にサポートします。 Aurora DSQL のための OCC の利点 Aurora DSQL は楽観的同時実行制御を採用しています。これは、リレーショナルデータベースよりも非リレーショナルデータベースでよく使われる手法です。楽観的同時実行制御では、同じ行を更新しようとする他のトランザクションについてあまり考慮せずにトランザクションロジックを実行します。トランザクション完了時に、データベースへの変更をコミットしようとします。その際、Aurora DSQL は他の同時実行トランザクションからの書き込みが干渉していないかを確認します。干渉がなければトランザクションは正常にコミットされますが、干渉があった場合はデータベースがエラーを返します。このような場合、ユーザーは悲観的同時実行制御を使うデータベースと同様に、どのように処理を進めるかを決める必要があります。ほとんどのユースケースでは、トランザクションをリトライするのが最善のアプローチです。 Aurora DSQL では、クライアントの遅延や長時間実行されるクエリが他のトランザクションに影響を与えたり遅延させたりすることはありません。これは、SQL の実行中ではなく、コミット時にサーバー側で競合が処理されるためです。一方、ロッキングベースの設計では、クライアントがトランザクション開始時に行や全テーブルに排他ロックを取得します。クライアントが予期せず停止した場合、これらのロックが無期限に保持される可能性があり、他の操作がブロックされ、不定長の待ち行列が発生する可能性があります。対して、OCC では、即座に競合を通知し、確定的な結果を提供するため、即座にリトライやアボートができます。ロックベースのシステムでは通常、タイムアウト期間に達した後にのみリトライやキャンセルのロジックが実行されます。このため、Aurora DSQL は、特に AWS リージョン間にまたがる大規模な分散アプリケーションの構築時に発生する現実的な障害や故障に対してより堅牢です。 マルチリージョンクラスターでは、ユーザーがトランザクションを送信すると、SQL 操作がトランザクションが送信されたリージョン (リージョン 1) のローカルストレージで実行されます。トランザクションが完了すると、そのトランザクションに関与したキーとともに事後イメージが、別のリージョン (リージョン 2) に送信されます。リージョン 2 には、そのリージョンの現在の変更をすべて認識しているトランザクション処理リーダーがいます。リーダーはリージョン 1 から事後イメージとトランザクションに関与したキーのリストを受け取ると、それがリージョン内で現在アクティブに変更されているすべてのキーと競合していないかを確認します。競合がなければ、コミットの確認を送り返します。 競合がある場合、最初にコミットしたトランザクションが成功し、残りのトランザクションはリトライする必要があります。その結果、同時実行制御の競合が発生します。 Aurora DSQL は、マルチリージョンのアクティブ・アクティブ可用性を持つ組織のビジネス継続性を実現します。OCC は、同期レプリケーションを使用したマルチリージョンのトランザクションの効率を向上させます。Aurora DSQL は、リージョン間の通信なしにローカルでの読み取りおよび書き込みトランザクションを処理し、トランザクションのコミット要求時にのみリージョン間の整合性を確認します。OCC により、ロックの交渉が不要になるため、Aurora DSQL は完全な事後イメージを事前に処理し、マルチ AZ およびマルチリージョンの定足数に対してチェックできます。このアプローチにより、ロックのオーバーヘッドなしにトランザクションを処理できるため、アベイラビリティゾーンおよびリージョン間の同期トランザクションのレイテンシーが低減されます。 次の図は、マルチリージョンクラスター (アクティブ-アクティブ) を示しています。 楽観的同時実行制御とアイソレーションレベル 他の分散 SQL データベースがSerializable分離レベルをサポートするのに対し、Aurora DSQL は PostgreSQL の repeatable read 分離レベルに相当する強力なスナップショット分離をサポートしています。トランザクションは、開始時のデータベースのスナップショットからデータを読み取ります。これは読み取り専用のトランザクションに特に役立ちます。読み取り専用のトランザクションは待機する必要がなく、OCC の影響も受けにくいためです。 トランザクションパターンのガイダンス 同時に実行されるデータベーストランザクションが同じレコードを更新すると、コンフリクトのリスクがあります。適切なデータモデリングでこのリスクを低減できますが、コンフリクトは避けられません。開発者は、データベースの提供する同時実行管理機能を理解し、アプリケーションに効果的に実装する必要があります。 Aurora DSQL は楽観的同時実行制御を使用しているため、同一キーに対する高頻度の並行更新が発生するユースケースでは、プログラミングアプローチが異なる必要があります。作業が完了したら、トランザクションのコミットを試みます。Aurora DSQL は、他の更新トランザクションがあなたのトランザクションに干渉していないかを確認します。干渉がなければ、トランザクションは成功します。そうでなければ、データベースがエラーを報告します。その場合、すぐにトランザクションをリトライするか、エクスポネンシャルバックオフとジッターを導入して、後続の競合の可能性を減らすかを決める必要があります。 OCC は常にデータベースでのトランザクションの進行を支援しますが、高い競合状態では性能が低下する可能性があります。そのため、以下のようなトランザクションパターンのガイドラインに従うことをお勧めします: トランザクションが失敗する可能性があることを前提に、常にリトライできるようにトランザクションを設計してください 行レベルの競合やデータ更新の競合を最小限に抑えるため、各トランザクションにタイムアウトロジックを実装してください。設定するタイムアウト値は、不要なトランザクションのキャンセルを避けるため、最大クエリ時間を考慮する必要があります 競合が激しく、リトライ率が高い場合は、失敗したトランザクションが異なるランダムな間隔でリトライされるよう、エクスポネンシャルバックオフとジッターを実装してください 既存のキーに対する更新が多い (更新とアップサート) システムでは、競合の可能性を最小限に抑えるため、トランザクションの範囲を小さく保つことが重要です Aurora DSQL で OCC の例外が発生する可能性のあるいくつかのユースケースと、コード例を見ていきましょう。 例 1: リージョン間トランザクションでのデータ競合 Aurora DSQL などの分散 SQL システムでは、OCC 例外が発生する一般的なシナリオは、複数のリージョンが同じデータを同時に更新しようとする場合です。この例では、同じアカウントデータを操作する 2 つのリンクされたリージョン、 us-east-1 と us-east-2 を持つクラスターを想定しましょう。 「us-east-1」のトランザクション A では、アカウントの残高とバージョンを読み取り、更新の準備をしています 同時に、「us-east-2」のトランザクション B も同じアカウントの残高とバージョンを読み取り、自身の更新を行う準備をしています トランザクション B は、アカウントの残高を正常に更新し、バージョンをインクリメントしました その後、トランザクション A が古いバージョンを使って更新をコミットしようとすると、バージョンがトランザクション B によって更新されたため、OCC 例外が発生しました このシナリオは、異なるリージョンの同じデータに対する同時トランザクションが、OCC 例外につながる可能性を示しています。 それでは、コード例を使って詳しく見ていきましょう。 テーブルを作成し、レコードを挿入します: CREATE TABLE orders.accounts ( id int PRIMARY KEY, balance DECIMAL(10, 2), version INT NOT NULL ); INSERT INTO accounts (id, balance, version) VALUES (1, 100.00, 1); トランザクション A がアカウントの残高とバージョンを読み取ります: BEGIN ; SELECT id, balance, version FROM accounts WHERE id = 1 ; トランザクション B が同じデータを読み取り、更新し、バージョンをインクリメントします: BEGIN ; UPDATE accounts SET balance = balance + 50, version = version + 1 WHERE id = 1 AND version = 1 ; COMMIT ; トランザクション A が古いバージョンのアカウントを使って更新しようとすると、OCC 競合が発生します: UPDATE accounts SET balance = balance - 30, version = version + 1 WHERE id = 1 AND version = 1 ; commit ; この場合、トランザクション A は、バージョン番号がトランザクション B によって変更されたことをシミュレートした OCC 例外のため、失敗します。 ERROR: change conflicts with another transaction, please retry: (OC000) 実際に何が起きたのかの詳細を見ていきましょう。 トランザクション A は読み取り/書き込みトランザクションなので、読み取り段階では、クエリプロセッサーが SELECT を解析し、シャードマップを参照してこのデータを保持するストレージノードを特定し、それらのノードからデータを取得します。トランザクション B も読み取り/書き込みトランザクションで、クエリプロセッサーは UPDATE ステートメントの一部として、読み取りセットと書き込みセットを作成します。トランザクション B がコミットを発行すると、クエリプロセッサーは読み取りセットと書き込みセットをパッケージ化し、トランザクションプロセッサーに送信します。各トランザクションプロセッサーは、他のトランザクションによる読み取りセットの変更がないかを確認します。変更がなければ、事前イメージと事後イメージをコミットレイヤーに読み書きし、コミットを永続化し、バージョンは増分されません。トランザクション A が UPDATE ステートメントを発行します。クエリプロセッサーはすでに更新に必要なすべてのデータを持っているので、書き込みセットを作成し、読み取りセットと書き込みセットをトランザクションプロセッサーに渡します。読み取りセットのデータが変更されたため、トランザクションプロセッサーは変更を拒否し、OCC 例外を返します。この時点で、クライアントはトランザクション B による更新を含む同じトランザクションをリトライできます。 例 2: SELECT FOR UPDATE を使用したライトスキューの管理 前述のとおり、Aurora DSQL は通常、読み取ったレコードに対して同時実行性チェックを行いません。 SELECT FOR UPDATE はこの動作を変更し、読み取った行に同時実行性チェックのフラグを立てます。 これが Aurora DSQL でライトスキューを管理する方法です。 ライトスキューでは、2 つの同時トランザクションが共通のデータセットを読み取り、それぞれが共通のデータセットを変更する更新を行いますが、お互いに重複しません。重複がないため (同じデータを変更しないため)、同時実行性の保護は発動しません。 Aurora DSQL では、 FOR UPDATE 句により、フラグ付きの行に対する追加のチェックを行うことで、Optimistic Concurrency Control (OCC) の標準的な動作が変更されます。この調整により、トランザクション が同じデータセットに同時にアクセスする際に発生する可能性のある異常を防ぐことができます。ロック機構を使ってコンフリクトを管理する従来の Pessimistic Concurrency Control (PCC) とは異なり、OCC は潜在的な書き込みコンフリクトを別の方法で処理します。以下の例は、FOR UPDATE 句がこのコンテキストでどのように同時実行性チェックを強制するかを示しています。 この状況が実際に起こりうる例を見てみましょう。 最初に、 Orders テーブルを作成し、いくつかの行を挿入します: CREATE TABLE IF NOT EXISTS orders.orders ( order_id int PRIMARY KEY, customer_id INTEGER NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount NUMERIC(10, 2) ); INSERT INTO orders.orders (order_id, customer_id, order_date, total_amount) VALUES (1, 12, '2024-09-26 14:30:00', 99.99); INSERT INTO orders.orders (order_id, customer_id, order_date, total_amount) VALUES (2, 123, '2024-09-26 14:32:00', 99.99); 2. トランザクション A は、 FOR UPDATE 句を使用して読み取り/書き込みトランザクションを開始しますが、まだ更新を実行したり、コミットしていません: begin ; select order_id, customer_id, total_amount from orders.orders where order_id = 1 FOR UPDATE ; トランザクション B は独自の読み取り/書き込みトランザクションを開始し、コミットします: begin ; select order_id, customer_id, total_amount from orders.orders where order_id = 1 FOR UPDATE ; update orders.orders SET total_amount = 103 WHERE order_id = 1 ; commit ; 3. トランザクション A は、同じトランザクション内で accounts テーブルの更新を試みます: UPDATE orders.accounts SET balance = balance + 60, version = version + 1 WHERE id = 1 AND version = 1 ; commit ; 4. トランザクション A がコミットを発行すると、次の OCC 例外が発生します: ERROR: change conflicts with another transaction, please retry: (OC000) OCC 例外が発生しましたが、変更された読み取りセットを持っていた orders テーブルではなく、別のテーブルが更新されていました。 実際に何が起きたのかを詳しく見ていきましょう このシナリオでは、トランザクション A が order_id=1 の詳細を含む読み取りセットを作成します。一方、読み取り/書き込みトランザクションであるトランザクション B も同じ order_id を読み取りと更新します。その後、トランザクション A が accounts テーブルの残高を更新しようとすると、OCC エラー (OC000) が発生します。トランザクション A が開始されると、クエリプロセッサーは読み取りセットを作成し、コミットする前に書き込みセットを生成するのを待ちます。しかし、トランザクション A が進行中の間に、トランザクション B がトランザクション A の読み取りセットと同じ order_id を更新してコミットします。トランザクション A が accounts テーブルを更新しようとすると、クエリプロセッサーは書き込みセットを作成し、トランザクションプロセッサーによる検証のために読み取りセットと書き込みセットの両方を渡します。この段階で、トランザクションプロセッサーは読み取りセットのデータに新しいバージョンがあることを検知し、トランザクションを拒否し、トランザクション A にリトライを強制します。 この例では、Aurora DSQL でライトスキューを管理したい場合、for update を使うのが効率的な方法であることを示しました。 注意: FOR UPDATE は読み書きトランザクション内でのみ機能します。読み取り専用トランザクションで FOR UPDATE を使用しようとすると、警告が表示され、読み取られた行の更新は報告されません。 postgres=# commit ; WARNING: SELECT FOR UPDATE in a read-only transaction is a no-op COMMIT また、SELECT FOR UPDATE フィルターには、選択するテーブルのプライマリーキーを含める必要があります。今回の場合、orders テーブルのプライマリーキーは order_id なので、この SELECT FOR UPDATE は失敗します。 postgres=> select customer_id from orders where orders.customer_id=123 for update ; ERROR: locking clause such as FOR UPDATE can be applied only on tables with equality predicates on the key しかし、このクエリは主キーを含むフィルターが設定されているため、成功します。 postgres=> begin ; BEGIN postgres=> select customer_id from orders where orders.customer_id=123 and order_id=2 for update ; customer_id 123 (1 row) 例 3: カタログの同期が取れていない例外 データ競合は OCC 例外の主な原因ですが、カタログの同期が取れていない問題も、これらのエラーをトリガーする可能性があります。これらのエラーは、アクティブなセッション中に、テーブルの作成や変更などのデータベーススキーマの変更が行われた際に発生します。例えば、1 つのトランザクションがテーブルを作成している間に、別のトランザクションがそのテーブルの読み取りや書き込みを試みると、セッションのカタログ情報が古くなっているため、OCC エラー (OC001 など) が発生する可能性があります。 操作をリトライすると、初期の失敗後にデータベースカタログが更新されるため、問題が解決されることが多いです。本番環境でこのようなエラーのリスクを最小限に抑えるには、マルチスレッド方式で DDL 操作を行うのは避けることをお勧めします。同時並行のスキーマ変更は、競合状態、トランザクションの失敗、ロールバックの原因となる可能性があります。制御された単一スレッドの環境で DDL 変更を管理することで、競合の問題を軽減し、データベース操作をより滑らかに行うことができます。 これが実際にどのように起こるかの具体例を見てみましょう。 トランザクション A によってテーブルが作成されます: CREATE TABLE orders.accounts ( id INT PRIMARY KEY, balance int, version int ); 既にセッションを開いているトランザクション B が、テーブルにレコードを書き込もうとすると: insert into orders.accounts VALUES (1, 10, 1); postgres=*> insert into orders.accounts VALUES (1, 10, 1); ERROR: schema has been updated by another transaction, please retry: (OC001) LINE 1: insert into orders.accounts VALUES (1, 10, 1); この例では、トランザクション A がテーブルを作成し、トランザクション B が同じテーブルにレコードを書き込もうとしますが、OCC エラーが発生します。しかし、その後のリトライは成功します。 以下は、OCC 例外 (OC001) に遭遇する可能性のある他のいくつかのシナリオで、通常はリトライで解決できます: トランザクション A が既存のテーブルにカラムを追加している間、トランザクション B がそのテーブルから読み取りまたは書き込みを試みると、OCC 例外が発生します。 トランザクション A がテーブルをドロップし、トランザクション B がその後同じテーブルにアクセスしようとします。 トランザクション A がテーブルにカラムを追加し、トランザクション B が同時に別の名前のカラムを追加しようとします。 進行中のトランザクションと競合するカタログの変更。 要約すると、OCC 例外 (OC001) は、データベーススキーマやカタログの変更が同時に行われることが原因で発生することが多いですが、適切なリトライメカニズムを実装することで、一般的に解決できます。 OCC 例外のリトライメカニズムによる処理 OCC では、トランザクションの競合時にリトライを管理するためのベストプラクティスとして、バックオフとジッターの実装が重要です。これにより、同期的なリトライによる更なる競合や、システムの過負荷を回避できます。バックオフにより、競合後のリトライが即座ではなく、徐々に長くなる遅延を設けることで、システムの負荷を軽減できます。ジッターは、これらの遅延にランダム性を導入します。バックオフとジッターを組み合わせることで、OCC を採用する分散システムにおけるコンテンション問題を軽減し、リトライロジックの効率を高めることができます。詳細については、 Exponential Backoff And Jitter を参照してください。以下のコードサンプルは、 このリポジトリ から入手できます。 高トランザクション環境で OCC の例外をシミュレーションし、バックオフとジッター戦略を使ってリトライを管理するシナリオを見ていきましょう。 まず、 create.py スクリプトを使用して、注文スキーマと accounts および orders の 2 つのテーブルを作成します python create.py --host --database postgres --user --region --schema orders load_generator.py スクリプトを実行 して、データベースにロードを生成し、 orders テーブルにデータを挿入します python load_generator.py --host --database postgres --user --region --schema orders --tablename orders --threads 10 OCC 条件を導入するために、別の PostgreSQL セッションで accounts テーブルを変更し、新しい列を追加します ALTER TABLE order.accounts ADD COLUMN balance INT ; スキーマが更新された後、 load_generator.py スクリプトは次のエラーで失敗します Error during insert: schema has been updated by another transaction, please retry: (OC001) 次に、 retry_backoff_jitter.py スクリプトを実行して、組み込みのリトライメカニズムを使用した load_generator.py スクリプトの拡張版を実行し、バックオフとジッターを統合します。 python retry_backoff_jitter.py --host --database postgres --user --region --schema orders --tablename orders --threads 10 accounts テーブルに別のスキーマ変更を加えます ALTER TABLE order.accounts ADD COLUMN totalsale INT ; リトライロジックが発動すると、スクリプトが OCC 例外をリトライで処理しているのが確認できます Error during batch insert: schema has been updated by another transaction, please retry: (OC001), retrying in 2.11 seconds (attempt 1/5) Error during batch insert: schema has been updated by another transaction, please retry: (OC001), retrying in 2.03 seconds (attempt 2/5) リトライ戦略に応じて、この値を微調整することができます。この場合、遅延時間の単位は秒になります。 分散システムでの OCC 例外の効果的な管理には、バックオフとジッターを組み込むことができる包括的なリトライ戦略が必要です。アプリケーションのキースペースの高コンテンション領域 (ホットキー) を避けられない場合でも、予測可能性を確保し、スループットを最大化し、高コンテンション率 (ホットキー) を示す負荷領域の安定性を高めることができます。リトライロジックに加えて、更新インプレースではなく追加のみのパターンを好むことで、最初からコンテンションを最小限に抑えることが重要です。ほとんどの最新のアプリケーション設計と Aurora DSQL などの分散データベースは、既存のキーを更新するのではなく新しいキーを導入することで、最適なシステムのスケーラビリティを実現できます。さらに、冪等性を実装することで、リトライによる重複操作や データ不整合を防ぐことができ、永続的な障害に対するデッドレターキューを設けることで、エスカレーションと手動による介入を可能にし、システムの信頼性をさらに高めることができます。 結論 同時実行制御は、あらゆるデータベース管理システムにとって重要な側面であり、分散データベースを扱う際にはさらに重要になります。Aurora DSQL で OCC を使用することは、分散アーキテクチャのため適切です。トランザクション実行中にリソースロックを必要としないため、スループットとシステム効率が向上します。 Aurora DSQL における OCC の主な利点は次のとおりです: 遅いクライアントや長時間実行クエリに対するレジリエンス – OCC では、コンテンション処理がクエリ実行中ではなくコミット段階で行われるため、1 つの遅いトランザクションが他のトランザクションに影響を与えたり遅延させたりすることはありません。 スケーラブルなクエリ処理 – Aurora DSQL の逆方向検証アプローチは、現在のトランザクションをコミット済みのトランザクションと比較するため、コーディネーションなしにクエリプロセッサーレイヤーをスケールアウトできます。 現実的な障害に対するロバスト性 – OCC により、Aurora DSQL はデッドロックやパフォーマンスボトルネックを引き起こす可能性のあるロック機構に依存しないため、大規模な分散アプリケーションを構築する際の障害やエラーに対してより強靭になります。 OCC には大きな利点がありますが、最適なパフォーマンスを得るには、トランザクションパターンを慎重に検討する必要があります。トランザクションが失敗する可能性があることを前提とし、タイムアウトと ジッター を伴うエクスポネンシャルバックオフを実装し、 SELECT FOR UPDATE を使ってライトスキューを管理するといった原則は、Aurora DSQL を使う開発者にとって重要なガイドラインです。 Aurora DSQL の同時実行制御メカニズムとベストプラクティスを理解することで、複雑で高トランザクションの負荷がかかる環境でも、データの整合性と可用性を維持しながら、システムの分散機能を活用できます。Aurora DSQL の詳細については、 ドキュメントをご覧ください 。 著者について Rajesh Kantamani は、シニア データベース スペシャリスト SA です。彼は、Amazon Web Services 上でデータベース ソリューションの設計、移行、最適化を支援し、スケーラビリティ、セキュリティ、パフォーマンスを確保することに特化しています。余暇には、家族や友人と屋外で過ごすことが好きです。 Prasad Matkar は、EMEA 地域を担当する AWS のデータベース専門ソリューションアーキテクトです。関係データベースエンジンに焦点を当て、AWS へのデータベースワークロードの移行とモダナイゼーションについて、お客様に技術的なサポートを提供しています。

リレーショナルデータベースは、マイクロサービス、ウェブサイト、モバイルバックエンド、SaaS アプリケーションなど、さまざまなアプリケーションやサービスの強力で柔軟な構成要素です。10 年前、私たちは Amazon Aurora を立ち上げ、商用データベースの 1/10 のコストで、MySQL および PostgreSQL との完全な互換性を持つ、並外れた高パフォーマンスと可用性を提供しました。お客様から、管理が容易で、ワークロードに合わせてスケールアップ・ダウンでき、マルチリージョンやマルチ AZ の高可用性アーキテクチャの構築が簡単なリレーショナルデータベースを求める声が寄せられています。 本日、私たちは常時利用可能なアプリケーションに最適な、最速のサーバーレス分散 SQL データベース「Amazon Aurora DSQL」をご紹介します。Aurora DSQL は、事実上無限のスケーラビリティ、最高の可用性、そしてインフラストラクチャ管理ゼロを提供します。ワークロードの需要に合わせて、データベースのシャーディングやインスタンスのアップグレードなしにスケーリングできます。革新的なアクティブ・アクティブの分散アーキテクチャにより、シングルリージョン構成で 99.99%、マルチリージョン構成で 99.999% の可用性を実現し、高可用性アプリケーションの構築に最適です。サーバーレスの設計により、パッチ適用、アップグレード、メンテナンスダウンタイムなどの運用負荷が不要になります。Aurora DSQL は PostgreSQL 互換であり、開発者は既知のリレーショナルデータベースの概念、ドライバー、ツール、フレームワークを使ってアプリケーションを迅速に構築・デプロイできます。 この記事では、Aurora DSQL の利点と始め方について説明します。 Aurora DSQL アーキテクチャと利点 Aurora DSQL は、コンポーネントの障害やアベイラビリティゾーン (AZ) の中断に対応できるシングルリージョン構成と、データの処理と保存の場所を完全に制御できるマルチリージョン構成の 2 つの構成で実行するように設計されています。独自の分離されたアクティブ・アクティブ・アーキテクチャにより、フェイルオーバーやスイッチオーバーによるダウンタイムがなくなるため、高可用性とビジネス継続性を簡単に設計できます。 Aurora DSQL は、3 つの AZ にわたるアクティブ・アクティブ構成のシングルリージョンクラスターを提供します。これにより、レプリケーションラグや従来のデータベースフェイルオーバー操作を最小限に抑えることができます。ハードウェアやインフラストラクチャの障害が発生した場合、手動操作なしで健全なインフラストラクチャにリクエストを自動的にルーティングします。Aurora DSQL のトランザクションは、マルチリージョンでも遅延の影響を最小限に抑えつつ、ACID (Atomicity、Consistency、Isolation、Durability) プロパティ全てを提供します。強力なスナップショット分離を実装し、クラスターエンドポイントへの読み書きに対して強力なデータ整合性を提供します。 次の図は、単一リージョンにおける Aurora DSQL の高可用性クラスタートポロジーを示しています。 シングルリージョン構成では、Aurora DSQL はすべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたログデータを 3 つの AZ にある ユーザーストレージレプリカに同期的に複製します。クラスターストレージレプリカは、最適なデータベースパフォーマンスのためにストレージフリートに分散されています。Aurora DSQL は、自動でのフェイルオーバーリカバリが設計されています。コンポーネントや AZ に障害が発生した場合、健全なコンポーネントにアクセスを自動的に切り替え、非同期でレプリカを修復します。障害が発生したレプリカが復元されると、Aurora DSQL は自動的にそれらをストレージクォーラムに追加し、クラスターで利用可能にします。 Aurora DSQL は、アプリケーションに最高の耐障害性が必要な場合に、99.999% のマルチリージョン可用性を提供します。 マルチリージョンクラスターは、シングルリージョンクラスターと同じ耐障害性と接続性を提供しつつ、2 つのリージョン エンドポイントを通じて可用性を向上させます。リンクされたクラスターの両方のエンドポイントは、単一の論理データベースを表し、強力なデータ整合性を持つ同時読み書き操作をサポートします。これにより、地理的な場所、パフォーマンス、または耐障害性の目的に応じて、アプリケーションと接続のバランスを取ることができ、読み取り側が常に同じデータを確実に見ることができます。 次の図は、Aurora DSQL マルチリージョンクラスターを使用したアプリケーションのアーキテクチャを示しています。 マルチリージョンクラスターを作成すると、Aurora DSQL は別のリージョンにもう 1 つクラスターを作成し、それらをリンクします。リンクされたリージョンを追加することで、コミットされたトランザクションからの変更がすべて他のリンクされたリージョンに確実に複製されます。各リンクされたクラスターにはリージョンエンドポイントがあり、Aurora DSQL はリージョン間で同期的に書き込みを複製するため、リンクされたクラスターのどこからでも強い整合性のある読み書きが可能です。 第 3 のリージョンがウィットネスリージョンとして機能します。ウィットネスリージョンは、リンクされたクラスターに書き込まれたデータを受け取りますが、クラスターや関連エンドポイントは持ちません。暗号化されたトランザクションログの限定的なウィンドウを保存し、Aurora DSQL がマルチリージョンの耐久性と可用性を提供するために使用されます。 その他の Aurora DSQL 機能 Aurora DSQL は、あらゆる負荷に対応できる事実上無制限のスケールを提供します。クエリ処理層、コミット層、ストレージ層がそれぞれ独立してスケーリングし、読み取り/書き込み比、データサイズ、クエリの複雑さなど、さまざまな特性のワークロードに適応します。つまり、ビジネスの成長に伴いデータベースの性能を維持する必要がなくなるため、開発者は次の重要な機能の開発に集中できます。 開発者は単一の API コールで新しいクラスターを素早く作成し、数分で PostgreSQL と互換性のあるデータベースの使用を開始できます。多くの一般的な PostgreSQL ドライバーやツール、ACID トランザクション、SQL クエリ、セカンダリインデックス、結合、挿入、更新などの基本的なリレーショナル機能をサポートしています。 Aurora DSQL は、シンプルな宣言型のプライバシーとセキュリティ制御、および AWS Identity and Access Management (IAM) と AWS CloudTrail との完全な統合により、セキュリティ体制を強化します。ユーザーのパスワードベースの認証をブロックしつつ、 PostgreSQL ワイヤープロトコル の互換性は維持しています。IAM を使用したトークンベースの認証をサポートし、 AWS Command Line Interface (AWS CLI) と AWS SDK でトークン生成のヘルパー関数を提供しています。 従来のデータベースとは異なり、Aurora DSQL は、従来のロック方式ではなく、楽観的同時性制御 (OCC) を使用しています。スケールアウトするにつれ、OCC により、長時間のトランザクションが他の実行中のトランザクションを遅らせることはありません。Aurora DSQL における OCC の詳細については、 Amazon Aurora DSQL の同時性制御 を参照してください。 結論 Aurora DSQL を使えば、強力な一貫性を持つレジリエントなアプリケーションを簡単に構築できます。これにより、規制上の課題に対応でき、アプリケーションのダウンタイムやデータ損失を気にする必要がありません。革新的な機能を活用すれば、データ管理とアプリケーションのスケーラビリティに新しいアプローチを取ることができます。 プレビューで利用可能になった Aurora DSQL を、ぜひ体験してみてください。 Aurora DSQL コンソール にアクセスするか、 プログラムからアクセスする ための AWS CLI や AWS SDK を使用してください。 詳しくは、 Aurora DSQL の概要 ページをご覧いただくか、詳細情報については包括的な ユーザーガイド をご参照ください。 著者について Raluca Constantin は、AWS 分散 SQL データベースチームのシニアデータベースエンジニアです。 Arun Sankaranarayanan は、ロンドン拠点のデータベース専門ソリューションアーキテクトです。

12 月 1 日、 Amazon Connect は、 生成 AI 、高度なセキュリティ機能、および効率的なボット管理を通じて、企業がコンタクトセンターの運用を強化するのに役立つ一連の新機能を導入しました。これらのイノベーションは、セキュリティとコンプライアンスを維持しながら、有意義な人間とのやり取りのための時間とスペースを増やすことで、企業がより良い顧客体験を提供するのに役立ちます。 コンタクトセンターのマネージャーは、セルフサービスの解決率の最適化、エージェントのパフォーマンスの効率的な評価、およびデータプライバシーコンプライアンスの維持において、常に課題に直面しています。さらに、会話型 AI エクスペリエンスの作成と管理には、多くの場合、専門的な専門知識と複数のサービスにわたる複雑な統合が必要です。 これらの課題に対処するために、Amazon Connect は、ターゲットを絞ったキャンペーンのための生成 AI を活用した顧客セグメンテーション、オムニチャネル サポートのためのネイティブ WhatsApp ビジネス メッセージング、チャット インタラクションにおけるセキュアな顧客データの収集、Amazon Connect インターフェースにおける簡素化された会話型 AI ボット管理、 Amazon Q in Connect の新たな機能強化などの主要機能を導入しました。Amazon Connect では、 Amazon Connect Contact Lens による新しい分析機能も追加され、ボットのパフォーマンスとコンタクトセンターの運用を最適化できるようになりました。 ここでは、最高水準のデータセキュリティとオペレーショナルエクセレンスを維持しながら、よりパーソナライズされた効率的なカスタマーエクスペリエンスを実現するのに役立つ新機能を紹介します。 生成 AI 搭載機能 Amazon Connect は、新しい生成 AI 機能を統合して顧客との対話を自動化および強化し、よりスマートなターゲティングとより効率的なコンタクトセンター管理を可能にします。 生成 AI セグメンテーションとトリガーベースのキャンペーン – 生成 AI を利用した支援を使用して、会話プロンプトを使用して お客様セグメント を作成します。これにより、企業は自然言語による説明を使用して正確な顧客セグメントを作成できるため、特定の顧客グループを簡単に特定してリーチできます。トリガーキャンペーンにより、組織はカート放棄などの特定の顧客イベントに基づいて顧客とコミュニケーションをとることができます。 すぐに使える提案から始めることもできます。 会話型 AI ボットの作成を簡素化し、Amazon Q in Connect で強化しましょう– Amazon Lex を搭載した会話型 AI ボットを Amazon Connect ウェブインターフェイス内で直接作成、編集、管理できます。これらのボットは、カスタマーサービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect で強化できるようになりました。Amazon Q in Connect は、コンタクトセンターのエージェントが推奨応答やアクションを行うのを支援することに加えて、自動音声応答 (IVR) とデジタルチャネルにわたるエンドカスタマーのセルフサービスインタラクションをサポートするようになりました。 この統合は、大規模言語モデル (LLM) による高度な会話機能を提供することで、従来の音声およびチャットボットの Amazon Lex 機能を超えています。システムは、設定済みのナレッジベース、顧客情報、ウェブコンテンツ、およびサードパーティのアプリケーションデータをインテリジェントに検索して、事前定義された意図と一致しない顧客の質問に回答します。管理者はインスタンスにカスタムガードレールを設定して、応答生成の制限を定義し、 Amazon Q in Connect のパフォーマンスを監視できます。 生成 AI による自動評価: スーパーバイザーは、生成 AI を使用して連絡先の最大 100% を自動的に評価できます。 生成 AI による連絡先分類: 自然言語インテントを使用して既存のセマンティックマッチ機能を改善します。 インターフェースとツールの改良 ボットの管理と監視の機能が強化され、自動エクスペリエンスの作成と最適化が簡単になりました。 WhatsApp ビジネス メッセージング用の Amazon Connect – WhatsApp ビジネス メッセージングとネイティブに統合されているため、顧客は音声、SMS、チャット、ビジネス向け Apple メッセージなどの既存 の Amazon Connect チャネル に加えて、 WhatsApp 経由でサポートを受けることができます。Amazon Connect のオムニチャネル機能に加えて、企業は Amazon Connect アプリケーション内で一貫したサービスの提供と管理を維持しながら、希望するコミュニケーションチャネルで顧客と会うことができます。 コンタクトレンズの会話型 AI ボットダッシュボード — Amazon Connect に組み込まれた会話 AI ボットのパフォーマンスをモニタリングするための分析を提供します。 連絡先の詳細に関するセルフサービス音声 (IVR) 録音と対話ログ — 音声録音を含むセルフサービス対話の包括的な記録を提供します。 日中予測の改善 — 日中の予測を以前に公開された予測と比較できます。 Amazon Connect 付きセールスフォースコンタクトセンター (プレビュー) — Amazon Connect のデジタルチャネルとユニファイドルーティングを Salesforce カスタマーリレーションシップマネジメント (CRM) システムにネイティブに統合します。 この新しいサービスにより 、企業は Amazon Connect と Salesforce チャネルの両方に単一のルーティングおよびワークフローシステムを使用できるようになり、通話、チャット、ケースを適切なセルフサービスまたはエージェントインタラクションにインテリジェントに転送できます。興味があれば、 サインアップしてプレビューに参加してください 。 チャットのセキュリティ強化 チャットインタラクションのセキュリティとコンプライアンスを強化し、機密情報の安全な処理を可能にする新機能。 チャット内の機密顧客データの収集 — Amazon Connect のチャットとメッセージングには 、チャットでのやり取り中に機密性の高い顧客情報を安全に処理できるデータプライバシーオプションが含まれるようになりました。この機能は、個人を特定できる情報 (PII) とペイメントカード業界 (PCI) のデータを保護し、データ保護規制の遵守を促進します。 主なメリット Amazon Connect の最新機能は、生成 AI、強化されたセキュリティ、および合理化されたボット管理を組み合わせて、企業を支援します: カスタマーエクスペリエンスの変革 — Amazon Connect は AI を活用したセグメンテーションを通じて顧客とのやりとりを向上させ、パーソナライズされたエンゲージメント戦略を可能にします。WhatsApp Business の新しいメッセージングは、オムニチャネルサポート機能を拡張し、顧客が希望するチャネルで対応できるようにします。さらに、Amazon Q in Connect などの高度なボット機能により、セルフサービスの解決率が向上し、より効率的なカスタマーエクスペリエンスが実現します。 セキュリティと運用の強化 — コンタクトセンターは、業務効率を維持しながら、PCI 準拠のチャットインタラクションでセキュリティ体制を強化できるようになりました。カスタム AI ガードレールは適切な回答の生成を促進し、シンプルなボット管理インターフェースにより専門知識が不要になります。分析および予測機能により、包括的なパフォーマンスモニタリングが可能になり、データ主導の意思決定が可能になり、コンタクトセンターの最適な運営が可能になります。 価格と提供状況 — これらの機能は現在、 Amazon Connect がサポートされているすべての AWS リージョンでご利用いただけます 。価格については、 Amazon Connect 料金表をご覧ください。 実装ガイダンスについては、 Amazon Connect のドキュメントを参照してください 。 – Eli 原文は こちら です。

本記事は 2024 年 11 月 13 日に AWS for Industries で公開された “ Create frictionless retail experiences with Just Walk Out RFID lanes ” を翻訳したものです。 本日、 Amazon Just Walk Out は、小売業者が 1 日程度で店舗に RFID チェックアウト機能を追加できる新しい RFID レーンを発表しました。急速に変化する小売環境において、従来の POS システムはボトルネックの原因となり、チェックアウトに時間がかかり、スタジアムやコンサート会場のような人通りの多い場所ではスタッフの非効率的な使用につながります。Just Walk Out RFID レーンは、迅速でスムーズなチェックアウトソリューションを提供することで、こうした課題に対応します。これらのレーンは、既存のシステムにシームレスに統合され、あらゆる規模のスペースに適応し、店舗レイアウトの再構成の柔軟性を高めるように設計されています。さまざまな決済プロバイダーと統合し、運営の人件費を削減することで、最終的に全体的な買い物体験を向上させます。Just Walk Out RFID レーンは、より迅速なチェックアウト時間とより効率的な運営を可能にすることで、小売業者や会場運営者のビジネスを変革するのに役立ちます。 RFID レーンのセットアップと購入を説明する 30 秒のビデオ 顧客からのフィードバック 「この技術は、レジ待ちを無くし、ファン体験を劇的に向上させました。また、次のシーズンの前に、在庫管理機能のために会場全体で RFID タグを導入することも楽しみにしています。これは、スムーズなチェックアウトを実現することと同じくらい、あるいはそれ以上に大きな機会です。」 — Miami Dolphins, Hard Rock Stadium & Formula 1 Crypto.com Miami Grand Prix リテール・オペレーションズ・シニア・マネージャー ローレン・ガーリー Just Walk Out RFID レーン：ユースケースと利点 混雑エリアの管理と繁忙時間帯の混雑軽減は、多くの小売業者にとって課題です。パイロット実験では、Just Walk Out RFID レーンが従来の POS システムと比較して最大 4 倍速いチェックアウトスピードを実現し、ペースの速い環境やスポーツイベント、コンサートに理想的であることが示されました。また、パイロット顧客は店舗運営に必要な労働力を 40% 削減し、棚卸しにかかる時間を 96% 短縮しました。Just Walk Out RFID レーンは、小売業者や会場運営者が、大規模イベント時に大勢の群衆を効率的に処理できるダイナミックな買い物環境を作り出す力を与えます。例えば、会場運営者はコンサートやハーフタイム中にアリーナやスタジアムでの待ち時間を迅速に短縮し、商品購入をスムーズにすることで、ファンにとってよりスムーズで効率的な買い物体験を確保します。同様に、商品やアパレルの小売業者はブラックフライデーや年末セールなどのピーク時の買い物期間に、レジでのボトルネックや長い行列を最小限に抑えて、より効果的に対処できます。Just Walk Out RFID レーンにより、小売業者や会場運営者はあらゆる規模の店舗をサポートし、未使用のスペースを素早く恒久的または一時的な小売拠点 (ポップアップショップや季節限定イベントなど) に変えることができる柔軟性を得られます。これらの RFID レーンは迅速な設置と容易な再配置が可能なように設計されており、以下のような主要なメリットをもたらします： 機動性 ：RFID レーンを簡単に再構成し、一時的または恒久的な配置で柔軟なレイアウトを実現。 柔軟性 ：様々な支払い方法、POS システム、ロイヤルティプログラムと統合可能。 正確性 ：棚卸しに必要な労力を削減。 汎用性 ：従来のチェックアウトシステムと組み合わせたり、単独の POS として独立して運用可能。 RFID 技術とは何か、そしてどのように機能するのか？ RFID は、電波を介してアイテムの識別、分類、追跡を可能にすることで、非接触型の小売体験を実現する技術です。このプロセスは、RFID タグとレーンからなる二部構成のシステムを通じて動作し、各タグにはデータを保存し送信するマイクロチップが含まれています。RFID タグが RFID レーンの範囲内にある場合、マイクロチップはタグ上のデータをレーンに送信します。各タグは固有の番号で応答し、レーンがそれを受信して解読します。タグからのデータは処理された後、ホストシステムに送られます。リーダーとタグの間のこのデータ交換は高速かつ効率的で、ミリ秒単位で行われます。 Just Walk Out は RFID タグを提供するためにエイブリィ・デニソン社と提携しています。エイブリィ・デニソン社は業界で最も包括的な高性能・高品質の RFID 製品ポートフォリオを提供しており、迅速な導入のための標準サイズとフォーマットのオプション、UPC 統合ソリューション、補助的なハングタグと粘着ラベル、ブランド付きや装飾されたハングタグ、幅広いサイズオプション、そして ARC 認証やその他のユースケース仕様を満たす様々なインレイオプションなどが含まれます。 Just Walk Out は、レーンハードウェア、タグプリンター、タグ印刷 UI、また店舗での作業で必要な工具類を提供します。電源と接続性を用意すれば、商品にタグを付けるだけです。Just Walk Out RFID レーンにより、小売業者は自社のエコシステムに統合することができ、Just Walk Out のデータを主要な POS や ERP システム、ロイヤルティプログラム、柔軟な決済プロバイダーと同期させることができます。Just Walk Out は、データが自動的にあなたのシステムに流れ込むことを確保し、これにより分析や在庫管理において既存のプロセスを継続して使用することができます。 Just Walk Out RFID レーンがあなたのビジネスに与える影響を学ぶ Just Walk Out は、お客様のために革新を続け、柔軟で適応性の高いソリューションによってあなたのビジネスを変革することをより容易にしています。あらゆるスペースにシームレスに統合し、変化するニーズに迅速に対応する能力を持つ Just Walk Out RFID レーンは、多様な小売環境を管理するための汎用的なアプローチを提供します。Just Walk Out RFID レーンについてさらに詳しく知り、このソリューションについて理解を深めるには、 Just Walk Out ビジネス開発チームにお問い合わせください 。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。 Mouni R. Mouni R. は AWS の製品管理 (技術) シニアマネージャーです。彼は、店内での買い物客と店舗管理者の体験を作り出す Just Walk Out 製品・設計チームを率いています。彼のチームは、コンピュータビジョンと RFID 技術を活用して、スムーズな買い物体験と店舗運営体験を可能にしています。

みなさま、AWS re:Invent 2024 はお楽しみいただけましたでしょうか。 2024 年 12 月 6 日に実施した [AWS Black Belt Online Seminar] AWS re:Invent 2024 速報 の資料及び動画についてご案内させて頂きます。動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画へのリンクは「  AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「  AWS Black Belt Online Seminar の Playlist  」をご覧ください。 AWS re:Invent 2024 速報 AWS re:Invent 2024 で発表されたばかりの新サービス、新機能を 1 時間に凝縮して一挙紹介！ 資料（  PDF  ） | 動画（  YouTube  ） 対象者 AWS に興味をお持ちのすべての方 AWS re:Invent 2024 を見逃してしまった方、振り返りたい方 日本語でわかりやすく新サービス、新機能の概要を知りたい方 本 BlackBelt で学習できること AWS re:Invent 2024 で発表されたばかりの新サービス、新機能 スピーカー 小林 正人 ( Kobayashi Masato ) Solutions Architect また、併せて以下のイベントへ是非ご参加ください。 AWS re:Invent 2024 re:Cap – Keynote 編 〜AWS re:Invent キーノートの主要メッセージ、新サービス、アップデートをご紹介〜 2024 年 12 月 17 日（火）、19 日（木）、20 日（金） 登録はこちら AWS re:Invent Recap – インダストリー編 〜AWS の最新アップデートをインダストリー別にご紹介〜 2025 年 1 月 28 日（火）〜 登録はこちら AWS re:Invent Recap – ソリューション編 〜AWS の最新アップデートをソリューション別にご紹介〜 2025 年 2 月 4 日（火）〜 登録はこちら 本 BlackBelt を通じて、みなさまが深堀りしたいと思えるサービスが見つかり、より詳細にその機能やメリットを調べていただくきっかけとなれば幸いです。 また、毎週のアップデートをまとめている 週刊 AWS も公開される予定ですので楽しみにお待ち下さい！

12 月 1 日、 AWS Security Incident Response を発表しました。これは、企業がセキュリティイベントを迅速かつ効果的に管理できるように設計された新しいサービスです。このサービスは、お客様がアカウントの乗っ取り、データ侵害、ランサムウェア攻撃など、さまざまなセキュリティイベントに備え、対応し、復旧できるようにすることを目的としています。 セキュリティ インシデント対応は、 Amazon GuardDuty と、 AWS Security Hub を介した統合されたサードパーティの脅威検出ツールからのセキュリティ検出結果のトリアージと調査を自動化します。コミュニケーションと調整が容易になり、セキュリティイベント中に支援できる AWS カスタマーインシデント対応チーム (CIRT) のセキュリティ専門家に 24 時間 365 日連絡できます。このサービスは、準備から検出、分析、復旧まで、インシデント対応ライフサイクルの各段階にわたって、より包括的なサポートをお客様に提供することを目的としています。 セキュリティイベントは、お客様にとってますます広範囲に及び、複雑になっています。セキュリティチームは毎日、膨大な数のアラートに直面することが多く、リソースの優先順位が間違っていたり、効果が低下したりする可能性があります。検出結果を手動で調査すると、リソースに負担がかかり、顧客が重要なセキュリティアラートを見落とす可能性があります。さらに、複数の利害関係者による対応の調整、さまざまな環境での権限の管理、およびアクションの文書化は、プロセスを複雑にします。お客様へのサポートを強化し、セキュリティイベント中にお客様が直面する、差別化されていないさまざまな面倒な点を取り除く機会があります。 主な機能 AWS Security Incident Response は、お客様がセキュリティイベントに効果的に備え、対応し、復旧できるよう支援する 3 つの主要機能を通じてこれらの課題に対処します: セキュリティ インシデント対応では、セキュリティ ハブを介して GuardDuty のセキュリティ検出結果とサポートされているサードパーティ ツールを自動的に優先順位付けし、即時対応が必要な優先度の高いインシデントを特定します。このサービスは、自動化とお客様固有の情報を使用して、予想される行動に基づいてセキュリティ検出結果をフィルタリングおよび抑制し、チームが重要なセキュリティアラートに集中できるようにします。 このサービスは、事前設定された通知ルールと権限設定を提供することで、インシデント対応を簡素化します。これらの設定は、サードパーティのセキュリティプロバイダーを含む社内外の利害関係者に適用できます。お客様は、メッセージング、安全なデータ転送、ビデオ会議のスケジュール設定などの統合機能を備えた集中コンソールにアクセスでき、すべてサービス API または AWS マネジメントコンソール からアクセスできます。その他の機能には、ケース履歴の自動追跡とレポート機能があり、セキュリティチームは修復と復旧作業に集中できます。 お客様は、セルフサービスの調査ツールと AWS CIRT による年中無休のサポートを利用できます。また、お客様はインシデントを個別に処理することも、サードパーティのセキュリティベンダーと相互運用することもできます。これらのオプションにより、お客様は特定のニーズと要件に基づいてインシデント対応を選択、管理、実施できます。 コア機能に加えて、お客様は、セキュリティインシデント対応のパフォーマンスを長期的に測定、監視、および改善するのに役立つメトリックを備えたサービスダッシュボードの恩恵を受けます。これらの指標には、平均解決時間 (MTTR)、特定期間内のアクティブなケースとクローズされたケースの数、トリアージされた検出結果の数、およびその他の主要業績評価指標が含まれます。お客様は、情報を照合したり、1 回限りのレポートを作成したりしなくても、これらの指標にすぐにアクセスできます。 開始方法 オンボーディングプロセスはいくつかのステップで完了できます。セキュリティインシデントレスポンスは AWS Organizations と統合され、セキュリティレイヤーを追加して、現在および将来のアカウントに包括的なセキュリティを提供します。お客様はまず、組織内の中央アカウントを選択します。このアカウントでは、すべてのアクティブおよび過去のセキュリティイベントを作成および管理できます。 次に、お客様はプロアクティブなインシデント対応機能を有効にできます。これにより、セキュリティ インシデント対応がセキュリティ ハブを通じて GuardDuty やサードパーティの検出ツールからの検出結果を監視および調査できるようにするサービス レベルの権限が作成されます。これらの検出結果は、サービス自動化と、一般的な IP アドレス、 AWS ID およびアクセス管理 (IAM) プリンシパル、その他の関連属性を含む顧客固有のデータを使用して自動的に並べ替えられ、修復されます。自動的に修復できない検出結果については、セキュリティ インシデント対応部門がセキュリティ ケースを作成し、お客様の組織内の適切な関係者に通知します。 お客様は、特定の IAM ロールをデプロイすることで、コンテインメントアクションを実行するサービスの権限を設定することもできます。これらのセキュリティインシデント対応抑制機能を使用することで、お客様はインシデント対応時間を短縮し、セキュリティイベントがアカウントやリソースに与える影響を最小限に抑えることができます。 空き状況と使用開始 AWS セキュリティインシデントレスポンスは現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、ストックホルム) の 12 の AWS リージョンでご利用いただけます。 AWS セキュリティインシデントレスポンスの詳細については、 製品ページ をご覧ください。 – Betty 原文は こちら です。

ある時点で、AWS のすべてのお客様が、できるだけ早く将来に移行したいと言っています。モダナイゼーションの取り組みを簡素化し、成長を促進し、クラウドに適応すると同時に、コストも削減したいと考えています。これらの顧客は通常、組織のさまざまな部門が管理する多様なテクノロジースタック上で実行されている、オンプレミスで実行されている大規模なレガシーアプリケーションスイートを所有しています。さらに困難なことに、これらの組織は多くの場合、厳しいセキュリティとコンプライアンスの要件を満たさなければなりません。 共有の準備をする Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Service (Amazon ECS) コンテナサービス、 Amazon Elastic Kubernetes Service (Amazon EKS) コンテナサービス、独自の HTTPS サービスなどの AWS リソースを、 Amazon Virtual Private Cloud (Amazon VPC) と AWS アカウントの境界を越えて共有し、 Amazon EventBridge を介してイベントドリブンアプリを構築したり、 AWS Step Functions でワークフローをオーケストレーションしたりするために使用できるようになりました。既存のワークロードを更新し、最新のクラウドネイティブアプリをオンプレミスのレガシーシステムに接続し、すべての通信をプライベートエンドポイントとネットワーク経由でルーティングできます。 これらの新機能は Amazon VPC Lattice と AWS PrivateLink を基盤として構築されており、ネットワークの設計と制御のための新しいオプションが多数用意されています。また、すべてのテクノロジースタックを統合してオーケストレーションするための優れた新しい方法もいくつか用意されています。たとえば、既存のオンプレミスアプリケーションを利用するハイブリッドイベント駆動型アーキテクチャを構築できます。 現在、一部のお客様は AWS Lambda 関数または Amazon Simple Queue Service (Amazon SQS) キューを使用してデータを VPC に転送しています。このような差別化されていない重労働を、よりシンプルで効率的なソリューションに置き換えることができるようになりました。 これらすべてをまとめることで、場所に関係なく、モダナイゼーションの取り組みを加速し、アプリケーション間の統合を簡素化するのに役立つ一連のサービスを利用できます。EventBridge と Step Functions は PrivateLink および VPC ラティス と連携して動作し、HTTPS ベースのパブリックアプリケーションとプライベートアプリケーションをイベント駆動型アーキテクチャとワークフローに統合することができます。 重要な用語と概念は次のとおりです: リソースオーナー VPC — 共有するリソースがある VPC。この VPC の所有者は、1 つ以上の関連するリソース設定を使用してリソースゲートウェイを作成し、 AWS Resource Access Manager (RAM) を使用してリソースコンシューマー (別の AWS アカウントなど) や、EventBridge と Step Functions を使用してイベント駆動型のアーキテクチャとワークフローを構築する開発者などのリソースコンシューマーとリソース設定を共有します。リソースオーナーとは、この VPC の管理と給餌を担当する組織内の人物 (おそらくあなた) と定義しましょう。 リソースゲートウェイ — ゲートウェイに関連付けられているリソース設定で示されるように、クライアントがリソースオーナー VPC 内のリソースにアクセスできるように、VPC への入口を提供します。1 つのリソースゲートウェイで複数のリソースを利用することができます。 リソース — リソースオーナー VPC 内の HTTPS エンドポイント。これは、データベース、データベースクラスター、EC2 インスタンス、複数の EC2 インスタンスの前にある Application Load Balancer 、AWS Cloud Map を介して検出可能な ECS サービス、 Network Load Balancer の背後にある Amazon Elastic Kubernetes Service (Amazon EKS) サービス、または AWS Site-to-Site VPN または AWS Direct Connect を介してオンプレミスで実行されているレガシーサービスになります。 リソース構成 — 特定のリソースゲートウェイを介してアクセスできるリソースのセットを定義します。リソースは IP アドレス、DNS 名、または (AWS リソースの場合) ARN で参照できます。 リソースコンシューマー — リソースオーナー VPC 内のリソースに接続して提供されるサービスを使用するアプリケーションの構築を担当する組織内の担当者。 リソースの共有 このパワーのすべては、さまざまな方法で活用できます。この記事ではその1つに焦点を当てます。 まず、私はリソースオーナーの役割を果たします。VPC コンソールで リソースゲートウェイ をクリックし、ゲートウェイがないことを確認し、 リソースゲートウェイの作成 をクリックして開始します: 名前 ( main-rg ) と IP アドレスタイプを割り当ててから、ゲートウェイを配置する VPC とプライベートサブネットを選択します (これは 1 回限りの選択であり、新しいリソースゲートウェイを作成しない限り変更できません)。また、インバウンドトラフィックを制御するために最大 5 つのセキュリティグループを選択します: 下にスクロールして、必要なタグを割り当て、 リソースゲートウェイの作成 をクリックして次に進みます: 新しいゲートウェイは数秒でアクティブになります。感謝の気持ちを込めてうなずき、 リソース設定を作成 をクリックして先に進みます: 次に、最初のリソース構成を作成する必要があります。リソースオーナー VPC のプライベートサブネット上の EC2 インスタンスで HTTPS サービスを実行しているとしましょう。サービスに DNS 名を割り当て、インスタンスの IP アドレスを返す Amazon Route 53 エイリアスレコードを使用します: この例では、パブリックホストゾーンを使用しています。すでにプライベートホストゾーンのサポートに取り組んでいます。 DNS のセットアップがすべて完了したら、 リソース設定の作成 をクリックして次に進みます。名前 ( rc-service1 ) を入力し、タイプとして リソース を選択し、先に作成したリソースゲートウェイを選択します: 下にスクロールして EC2 インスタンスをリソースとして定義し、DNS 名を入力し、ポート 80 と 443 の共有を設定します: ここで、少し寄り道をして、RAM コンソールに移動してリソース共有を作成し、他の AWS アカウントがリソースにアクセスできるようにします (これはオプションであり、クロスアカウントシナリオにのみ該当します)。サービスごとに 1 つのリソース共有を作成することもできますが、ほとんどの場合、共有を 1 つ作成し、それを使用して関連サービスのコレクションをパッケージ化します。これを実行して、 共有サービスと呼びます : 回り道から戻って、リソース共有のリストを更新し、作成したリソース共有を選択して、 リソース構成の作成 をクリックします: リソース設定は数秒で準備完了です。 まとめと計画時間 先に進む前に、簡単にまとめて計画を立てましょう。私が (リソースプロバイダーの役割で) これまでに持っていることは次のとおりです: MainVPC — 私のリソースオーナー VPC。 main-rg — MainVPC のリソースゲートウェイ。 rc-service1 — main-rg のリソース設定です。 service1 — MainVPC のプライベートサブネットの EC2 インスタンスで固定 IP アドレスでホストされている HTTPS サービス。 さて、次は何でしょう? 共有 — これが最初の、そして最もわかりやすい使用法です。 AWS リソースアクセスマネージャー (RAM) を使用してリソース設定を別の AWS アカウントと共有し、別の VPC からサービスにアクセスできます。一方 (リソースコンシューマーとして)、共有されているサービスに接続するための簡単な手順をいくつか実行します: サービスネットワーク — サービスネットワークを作成し、リソース設定をサービスネットワークに追加し、VPC に VPC エンドポイントを作成してサービスネットワークに接続できます。 エンドポイント — VPC に VPC エンドポイントを作成し、そのエンドポイントを介して共有リソースにアクセスできます。 モダナイズ — 従来の Lambda または SQS 統合を削除して、差別化されていない面倒な作業を取り除くことができます。 ビルド — EventBridge と Step Functions を使用して、イベント駆動型アーキテクチャを構築し、アプリケーションをオーケストレーションすることができます。このオプションを選びます! EventBridge とステップ関数によるプライベートリソースへのアクセス EventBridge と Step Functions により、Slack、Salesforce、アドビなどの SaaS プロバイダーのものなど、パブリック HTTPS エンドポイントに簡単にアクセスできるようになりました。12 月 1 日のリリースにより、プライベート HTTPS サービスの利用も同様に簡単になりました。 リソースコンシューマーとしては、EventBridge 接続を作成し、共有されたリソース設定を参照して、イベントドリブンアプリケーションからサービスを呼び出すだけです。私がすでに知っていることはすべてまだ当てはまり、民間サービスにアクセスする新たな力を得ました。 EventBridge 接続を作成するには、EventBridge コンソールを開き、 統合 メニューの 接続 をクリックします: 既存の接続 (今のところなし) を確認してから、 接続を作成 をクリックして次に進みます: 接続の名前 ( MyService1 ) と説明を入力し、 API タイプとして プライベート を選択し、前に作成したリソース設定を選択します: 下にスクロールすると、接続しているサービスの認証を設定する必要があります。 カスタム設定 と 基本認証 を選択し、サービスの ユーザー名 と パスワード を入力します。また、クエリ文字列に Action=Forecast を追加して (認証にはたくさんのオプションがあることがわかります)、 作成 をクリックします: 接続は数分で作成され、準備が整います。次に、 HTTP タスク を使用して接続を選択し、API エンドポイントの URL を入力し、HTTP メソッドを選択して Step Functions ワークフローで使用します: これで、Step Functions ワークフローでプライベートリソースを利用できるようになりました! この接続をイベントバスとパイプの EventBridge API デスティネーションターゲットとして使用することもできます。 知っておくべきこと これらの素晴らしい新機能について知っておくべきことがいくつかあります: 料金 — VPC へのデータ転送にかかる GB 単位の料金を含め、 ステップファンクション 、 EventBridge 、 PrivateLink 、 VPC ラティス の既存の料金が適用されます。 リージョン – 21の AWS リージョンで Resource Gateway と Resource Configurations を作成、使用できます: 米国東部 (オハイオ州、バージニア州北部)、米国西部 (カリフォルニア州北部、オレゴン州)、アフリカ (ケープタウン)、アジア太平洋 (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、中東 (バーレーン)、南米 (サンパウロ)。 開発中 — 前述したように、プライベートホストゾーンのサポートに取り組んでいます。また、EventBridge と Step Functions を通じて、他のタイプの AWS リソースへのアクセスをサポートすることも計画しています。 – Jeff ; 原文は こちら です。

本稿は、2024 年 9 月 4 日に AWS Cloud Enterprise Strategy Blog で公開された “ Centralizing or Decentralizing Generative AI? The Answer: Both ” を翻訳したものです。 はじめに ビジネスおよび IT の意思決定者にとって、もはや、生成 AI を採用するかどうかでは問題ではなく、どのようにして最大限の効果と最小限のリスクで実装するかという点です。生成 AI の管理と展開を、集中化するか、分散化するかは、長期的な影響を伴う重要な戦略的決定です。 ブログの記事「 集中化か分散化か？ 」で強調されているように、企業は生成 AI のような変革技術を導入する際に、集中化と分散化のトレードオフを考慮する必要があります。集中化は全社的なガバナンス、規模の経済、統一されたデータ管理を実現できる一方で、分散化はより迅速なイノベーションとビジネスニーズへのより緊密な対応を可能にするかもしれません。 私たちは、両方の戦略の強みを活用するハイブリッドモデルという、より洗練されたアプローチを推奨します。すなわち、インフラを集中化しながらイノベーションを分散化するというアプローチです。この戦略は、強固なガバナンスと俊敏なデリバリーを組み合わせ、生成 AI のインパクトを最大限に引き出すための体制を整えます。 ビジネスニーズの特定 生成 AI の技術に焦点を当てるのではなく、価値と競争優位性を生み出すことができる、影響力の大きい分野を特定します。 カスタマーサービス： AI 搭載のチャットボットでサポートを強化しながらコストを削減。 マーケティング： AI を活用して、大規模なパーソナライズされたコンテンツ作成を実現。 製品開発： AI で設計コンセプトとシミュレーションを生成。 製薬： AI で分子構造を探索することで、新薬開発を加速。 金融サービス： リスク評価、不正検出、個別アドバイスに AI を活用。 ソフトウェア開発： AI によるコーディングとバグ検出により生産性を向上。 サプライチェーン： AI 主導の予測分析と物流計画による最適化。 人事： 候補者のスクリーニングとマッチングに AI を活用し、採用プロセスを合理化。 特定するための重要な質問 生成 AI が対応できる重要なビジネス上の問題や機会とはどのようなものですか？ 生成 AI から最も恩恵を受ける組織の領域や機能は何ですか？ 差別化された AI ソリューションを構築するために、組織が活用できる独自のデータ資産や専門知識は何ですか？ ビジネスニーズとユースケースを明確に定義することで、組織は生成 AI の展開とガバナンスをサポートするのに最も適した組織構造と運用モデルを決定することができます。 ハイブリッドアプローチ：両方の長所を活かす 生成 AI にとって最適な組織構造とはどのようなものでしょうか。私たちは AWS エンタープライズストラテジストとして、財務および人事チームが、まずリソースのインパクトを最大限に高め、次にビジネスニーズに迅速に対応し、最後にガードレールの構築と、一般化された作業の方法を確立できることに感銘を受けています。 これらの領域にベストプラクティスとナレッジをもたらす集中化されたチームを擁しており全社的な業務を行っていますが、誰もが人材と財務の管理もあわせて期待されています。 AI は同様にビジネスのあらゆる側面に浸透していくでしょう。現場レベルではモデルの出力結果の妥当性を評価する能力など、スキルや知識が必要とされるいくでしょう。 インフラレイヤーの集中化 AI インフラストラクチャを集中化することで、企業は規模の経済性を実現しながら、トレーニング、ファインチューニング、独自 AI モデルの開発といった複雑でリソース集約的なプロセスを効率的に管理できるようになります。この統合により、データ管理、分析、モデルのメンテナンスが合理化され、企業全体のコストと複雑性が削減されます。 集中化により、一貫したデータ品質、セキュリティ、コンプライアンス基準が確保され、信頼性の高い生成 AI モデルの開発と展開を成功させる上で重要な要素となります。これらのリソースを統合することで、組織は AI 技術を導入する際に直面する課題をより効果的に乗り越え、その潜在的なメリットを最大限に活用することができます。 通常、専門のデータチームが、この集中管理されたインフラを管理し、組織内の他の部門に対してガイダンス、トレーニング、ツール、ガバナンスを提供します。このチームは高度な AI/ML スキルを持ち、組織の生成 AI を利用する能力が確固たるインフラの上に構築されるようにします。 ビジネス領域全体に AI イノベーションを分散 生成 AI のインフラは集中化の恩恵を受ける一方で、イノベーションは分散化された環境でこそ活気づきます。分散化アプローチは、ビジネス領域全体にわたる AI のユースケースの多様性に対応します。法律文書の要約から、金融データの分析、研究開発における設計、マーケティングコンテンツの作成まで、さまざまなユースケースに対応します。これらのアプリケーションには、異なる基盤モデルだけでなく、カスタマイズ、ファインチューニング、品質管理対策、ユーザーインターフェース設計、既存のアプリケーションやビジネスプロセスとの統合が必要です。 このようなユースケースの多様性と個別性が進むにつれて集中化された環境は効率が悪くなっていきます。各部門の独自のニーズや迅速なイノベーションサイクルに対応することが困難になるためです。しかし、データメッシュ (データを分散化し、AI を分散化するモデル) は、ビジネス部門のニーズにうまく適合できるでしょう。 財務や人事のように、ベストプラクティスを提供する中央集権型のチームは存在しますが、組織の各部門は独自の能力を開発し発揮しています。生成 AI の場合、組織全体にわたるチームに権限を与えることで、モデルの結果を評価し、AI をワークフローに統合し、イノベーションを一から推進することを意味します。 データメッシュにより、各分野や部門の専門チームが AI アプリケーションのオーナーの役割を担います。これらのチームはビジネス上の課題やオポチュニティに最も近い位置にあり、影響力の大きい AI ユースケースを特定し、実装する上で最適な立場にあります。AI ソリューションのプロトタイプを迅速に作成し、テストと改善を行うことで、特定の業務上の文脈や戦略目標との緊密な整合性を確保することができます。これにより、生成 AI ソリューションの開発と展開が加速されるだけでなく、各部門の特定の業務上の文脈や戦略目標との緊密な整合性が確保されます。 分散モデルにおける効果的なガバナンスの維持 分散モデルでは、より迅速なイノベーションと特定のビジネスニーズへのより緊密な適合が実現しますが、組織全体で一貫性、品質、コンプライアンスを確保するための効果的なガバナンスと統制を維持することが重要です。 これを実現するには、いくつかの主要な戦略が必要です。 集中化されたプラットフォームとツール： 生成 AI ソリューションを構築し展開する際に、各部門のチームが活用できる標準化されたツール、モデル、API のセットを提供する集中化されたプラットフォームを提供します。これにより、品質、セキュリティ、コンプライアンスのベースラインが確保されます。 共有責任モデル： 生成 AI の推進の中心となるデータサイエンスおよびエンジニアリングチームが標準、ガイドライン、ベストプラクティスを設定し、各部門のチームがそれぞれのコンテキストに合わせてカスタマイズして適用する共有責任モデルを確立します。 ガバナンス委員会： 中心となるチームと各部門チームの代表者が集まる部門横断的なガバナンス委員会を結成し、生成 AI ソリューションの展開を検討し承認します。これにより、戦略的な整合性と一貫したリスク管理を維持することができます。 集中化されたモニタリングと監査： 組織全体における生成 AI アプリケーションのパフォーマンス、利用状況、コンプライアンスを追跡するための集中化されたモニタリングと監査を実施します。 知識の共有とコラボレーション： 生成 AI の推進の中心となる各部門のチーム間で知識の共有とコラボレーションの文化を醸成し、洞察、方法論、教訓の交換を促進します。これにより、一貫した品質とベストプラクティスの採用を確保できます。 中央化されたプラットフォームのサポートにより、ビジネス部門のチームは成長する 分散化は孤立を意味するものではありません。各部門のチームは、ガイダンス、トレーニング、ツール、ガバナンスを提供する集中化されデータサイエンスサポートの恩恵を受けます。これにより、統制と統一性を維持しながら、最新の方法論とテクノロジーへのアクセスを確保できます。中央集権型の専門知識は、通常、プラットフォームチームとして独自のモデルのトレーニングを担当するチームから提供されます。 ブログ記事「責任ある AI のベストプラクティス: 責任ある信頼できる AI システムの促進」 では、生成 AI のライフサイクル全体にわたって公平性、透明性、説明責任を維持する方法について説明しています。これは、生成 AI ソリューションを分散型かつ部門特化型で展開する際に極めて重要です。これにより、ソリューションが組織の倫理原則に沿ったものとなり、偏見を助長したり、意図しない被害を引き起こしたりすることがなくなります。 おわりに 生成 AI の実装の未来は、集中化と分散化を戦略的にバランスさせることにあります。 集中化されたインフラは、今日の規制環境において不可欠なセキュリティ、スケーラビリティ、コンプライアンスのインフラを提供します。分散化された実行レイヤーは、特定のビジネスニーズに合わせた AI ソリューションを迅速に開発し、展開することを可能にします。このハイブリッドモデルは、組織が俊敏性を高めながらコントロールを維持することを可能にする強力な戦略的優位性を提供します。コアとなるインフラを集中化し、アプリケーション開発を分散化することで、企業は AI 導入の複雑性を乗り越えながら、その変革の可能性を最大限に引き出すことができます。 AI 主導の未来で成功を収めるには、企業はイノベーションの最前線に身を置き、同時に、集中化と分散化の両方の要素を活用する緻密な戦略を今から策定することで、強固なガバナンスと拡張性を確保する必要があるのです。 —Matthias Patzak and Tom Godden 参考になるサイト: 集中化か分散化か？ – by Mark Schwartz Welcome to a New Era of Building in the Cloud with Generative AI on AWS – by Swami Sivasubramanian Data Lakes vs. Data Mesh: Navigating the Future of Organizational Data Strategies – by Matthias Patzak How Technology Leaders Can Prepare for Generative AI – by Phil Le-Brun Your AI is Only as Good as Your Data – by Tom Godden Navigating the Generative AI Landscape: A Strategic Blueprint for CEOs and CIOs – by Tom Godden AWS でのデータレイク データメッシュとは何ですか? Matthias Patzak マティアスは、AWS ソリューションアーキテクチャ部門のプリンシパルアドバイザーを経て、2023 年初めにエンタープライズストラテジストチームに加わりました。この役職において、マティアスは、クラウドがイノベーションのスピード、IT の効率性、およびテクノロジーが人、プロセス、テクノロジーの観点から生み出すビジネス価値の向上にどのように役立つかについて、経営陣と共同で取り組んでいます。 AWS 入社前は、マティアスは AutoScout24 の IT 担当副社長、Home Shopping Europe の最高経営責任者を務めていました。両社において、マティアスはリーン・アジャイルの運用モデルを大規模に導入し、クラウドへの移行を成功に導きました。その結果、納期の短縮、ビジネス価値の向上、企業評価の向上を実現しました。 Tom Godden トム・ゴッデンは、Amazon Web Services (AWS) のエンタープライズストラテジスト兼エバンジェリストです。AWS 入社前は、Foundation Medicine の最高情報責任者 (CIO) として、FDA の規制下にある世界トップクラスの癌ゲノム診断、研究、患者治療結果のプラットフォームの構築に携わり、治療結果の改善と次世代の精密医療の実現に貢献しました。それ以前は、Alphen aan den Rijn Netherlands にある Wolters Kluwer で複数の上級技術リーダー職を歴任し、ヘルスケアおよび生命科学業界での経験は 17 年以上に及びます。トムはアリゾナ州立大学で学士号を取得しています。

本日、強化された AWS Pricing Calculator が、請求とコスト管理コンソールからパブリックプレビュー機能として利用できるようになったことを発表致します。新機能では、新しいワークロードや既存の AWS 使用量の変更についてディスカウントを含めた正確なコスト見積もりを行うことができます。これにより、あるリージョンから別のリージョンへのワークロード移行、既存のワークロードの変更もしくは新しいワークロードの計画やコミットメント購入計画などについて時間を節約しコスト見積もりの正確性を向上させることができます。 既存の Web サイトとしての Pricing Calculator と異なり、強化された Pricing Calculator を開始するには開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。 AWS Pricing Calculator のこれまでの歩み 最もよくある一般的な質問の 1 つは、” AWS 上でワークロードを実行するとどのくらいコストがかかりますか？” というものです。これに応えるために、2007 年に AWS Simple Monthly Calculator をローンチしました。これは、最新の料金変更に対応し、簡単にコスト見積もりを行えるツールです。2018 年には、 AWS Pricing Calculator をローンチしました。シンプルな UI で幅広いサービスに対応しており Pricing Calculator はすぐに AWS ワークロードのコストを見積もるための頼りになるリソースとなりました。2023 年には、 1 つのツールですべてのアーキテクチャのニーズに対応した料金を調査できるよう Simple Monthly Calculator の廃止 を決定しました。これ以来、Pricing Calculator の機能を向上させ拡張し続けてきました。 本日のローンチ以前は、AWS Pricing Calculator を利用して AWS 上のワークロードのコスト影響を評価できました。しかし、ディスカウントについては自分自身で計算する必要がありました。さらに、変更を加える場合にはまず既存の使用量を収集する必要がありました。また、コストの見積もりを保存したりチームで共有するための出力や管理プロセスを構築する必要がありました。 強化された Pricing Calculator （パブリックプレビュー） お客様からのフィードバックを取り入れて、請求とコスト管理コンソールで利用できる新しく強化された AWS Pricing Calculator を開発しました。まず、AWS アカウントで Pricing Calculator にログインし、見積もりに過去の AWS 使用量をインポートできるようになりました。また、これらの見積もりをアカウントに直接保存し、今後のリファレンスとできます。次に、AWS が請求書を作成するために利用しているものと同じ計算ロジックを利用して AWS 請求全体のコストを見積もることができるようになりました。この機能により、Savings Plans や Reserved Instances などの様々なディスカウントが全体のコストにどのように影響するのかより詳しく理解するために役立ちます。最後に、ディスカウントを適用させながら、特定のワークロード（すべての AWS 使用量のサブセット）のコストをインタラクティブに見積もることができます。開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。それでは、詳細について見ていきましょう。 2 種類の見積もり 新しい Pricing Calculator の機能は、パブリックプレビューとして 2 種類のコスト見積もりをサポートしています。ワークロード見積もりと請求見積もりです。 ワークロード見積もり を利用すると、様々なワークロードやアプリケーションの変更によるコスト影響をインタラクティブにモデル化し、ディスカウントを適用した効果を自動的に含ませることができます。アプリケーションを所有している場合や、アプリケーションに関する財務もしくは組織内の使用量に関して責任を持っている場合は、こちらの見積もりが役に立ちます。ワークロード見積もりは、管理アカウント、メンバーアカウントとスタンドアロンアカウントすべての AWS アカウントで利用できます。 請求見積もり を利用すると、管理アカウントのユーザーは AWS サービスの使用量の変化に加えて、Savings Plans と Reserved Instances を含んだりコミットメント金額を調整した見積もりを作成できます。これはすべてのコストと使用量が一括請求で計算されることにより実行されます。一括請求での見積もりは、アカウント間で割引の共有を行いながら活用できるため、より長期間のコミットメントを含めたシナリオを評価したいお客様によって特に有益です。 おそらく皆さんは、この新しい Pricing Calculator の機能を活用する色々な方法について考えているのではないでしょうか？まさに、新しいビジネスをサポートするための既存ワークロードの拡張や新規ワークロードの追加、レジリエンシー、パフォーマンスもしくはコスト最適化などの理由による新しいリージョンへの移行や推奨されるライトサイジングの実装といったシナリオに活用できます。既存の Amazon EC2 の使用量を変更しながら新しく Amazon RDS を追加する必要があるユースケースについて、お客様が手短な回答を探している例について見てみましょう。 ワークロード見積もり あなたが所属するチームが m5d.16xlarge インスタンスの使用量を月あたり 355 時間から 1460 時間に増やすことを決めました。見積もりコストは増加しますが、他のワークロードを変化させた場合のコスト影響も一緒に確認したいとします。 自分のアカウントで Pricing Calculator にログインし、使用可能なパラメーターとしての日付範囲やフィルター（リージョン、アカウント、タグやコストカテゴリなど）を用いて過去のワークロードをインポートし、ワークロード見積もりを作成してください。EC2 サービスの使用量のみをインポートすることができます。これを実行するために、Amazon Elastic Compute Cloud サービスでフィルタリングし、新しい使用グループを作成して名前を付け、詳細を設定してサービスの使用量を編集してください。 図 1. ワークロード見積もりへ過去の EC2 使用量を追加した例 図 2. 既存 EC2 の使用量詳細の編集例 状態の列が “Modified” となり、フィルタリングされたベースライン使用量と変更された推定コストの比較をすぐに確認することができます。 図 3. ワークロード見積もりのランディングページ例 既存の EC2 使用量を変更することに加えて、チームはさらに新しく追加する Amazon Aurora MySQL データベースの使用量に関するコスト影響を把握したいと考えています。このような場合は、新しい Amazon Aurora の使用量を同じワークロード見積もりに加えることができます。これを行うために、“Amazon Relational Database Service” でフィルタし、新しいサービス使用量を加え、詳細を設定することでコストへの影響をすぐに確認することができます。 図 4. 新しく Amazon RDS ( Aurora 使用量）を追加した例 図 5. 新しい Amazon Aurora の詳細設定例 新しく Amazon Aurora の使用量を設定すると、Amazon Aurora の使用量をすぐに反映した見積もりをテーブルで再度確認できます。 図 6. 更新されたワークロード見積もりページ例 請求見積もり チームがワークロードの成長によるコストへの影響について理解した後に、増加した使用量をカバーする新しい Savings Plans を購入する必要があるとします。請求見積もりの機能により、Savings Plans と Reserved Instances の両方を含む AWS 請求全体のコストをモデル化することができます。例えば、m5d.16xlarge EC2 インスタンスの月あたりの使用量を 355 時間から 1460 時間へ増やし、この増加分をカバーするために $1.00/hour の EC2 Instance Savings Plans を追加購入するとします。この場合、請求見積もりを使用することで、全体への影響を把握できます。これを行うためには、新しい請求シナリオを作成し、先月の EC2 使用量をインポートします。次に、増加した使用量を反映させるために関連する使用量の行を変更し、さらに新しい Savings Plans を請求シナリオに追加します。これらの手順を完了させたら、‘Create report’ をクリックして請求シミュレーションを開始してください。 図 7. 請求見積もりページ例 シミュレーション結果が作成されると、請求見積もりのリストで確認することができます。見積もりのタイトルをクリックして、詳細を確認できます。請求見積もりの結果ページでは、一括請求ファミリーのコストと使用量に関する課税前の重要な情報が表示されます。上位 7 サービスと明細項目レベルで変更されたコストと使用量を確認できます。明細項目では、シナリオで使用量が変更された行とコミットメントでカバーされ変更された行やディスカウント適用に伴い変更された行が含まれます。 図 8. 請求結果ページ例 注意点 レイテンシー ：ワークロード見積もりでは、すぐにコスト見積もりを取得できます。請求見積もりでは、処理するデータのサイズに依存しますが、新しい設定の詳細を利用して完全な請求を計算する必要があるため、最大 12 時間の待ち時間が発生する可能性があります。これは非同期処理となり、完了するとメール通知を受け取ります。 Savings Plans コストモデリング ：時間あたりのコミットメント金額が異なる個別の Savings Plans を購入した場合のコストへの影響について分析するために、新しくローンチされた Savings Plans Purchase Analyer を利用し、様々な購入シナリオにまたがった推定削減額、カバレッジと使用率をインタラクティブにモデル化できます。もし、組織の使用量にまたがった既存のすべての Savings Plans、Reserved Instances とディスカウントに加えて、新しく追加したり変更した使用量、Savings Plans や Reserved Instances によるコスト影響を総合的に把握したいのであれば、Pricing Calculator の請求見積もり機能を利用してください。 結論 新しい Pricing Calculator の機能は、コスト計画に対する確信を高め、組織が必要とする重要なビジネスの意思決定に必要なクリティカルな回答を得るための処理を迅速にします。詳細については、 AWS Pricing Calculator の ユーザーガイド 、 API ドキュメント や 料金 を参照してください。（訳者注：ワークロード見積もりは、無料で作成できます。請求見積もりは、月 5 件まで無料で作成できますが、以降は 1 件あたり $2 の費用が発生します。） 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Jeremiah Myers Jeremiah は、AWS Billing and Cost Management services のシニアテクニカルプロダクトマネージャーです。クラウドコストの責任者がAWS 上の将来のワークロードをよりよく計画できる支援に注力しています。以前のキャリアでは、複数のグローバルソフトウェア製品をローンチし、ベンチャー企業をバックアップするスタートアップを共同成立しました。 Bowen Wang Bowen は、AWS Billing and Cost Management services のプリンシパルプロダクトマーケティングマネージャーです。財務やビジネスのリーダーがクラウドの価値と Cloud Financial Management を最適化する方法をより理解できるようにすることに重点を置いています。以前のキャリアでは、テックスタートアップの中国市場参入を支援していました。

Amazon Connect に、 生成 AI 、高度なセキュリティ機能、そして合理化されたボット管理を通じて、コンタクトセンター運用を強化する新機能を導入しました。これらのイノベーションは、セキュリティとコンプライアンスを維持しながら、有意義なやり取りの時間を増やすことで、組織がより良い顧客体験を提供するのに役立ちます。 コンタクトセンターの管理者は、セルフサービス解決率の最適化、エージェントのパフォーマンスの効率的な評価、データプライバシーコンプライアンスの維持といった課題に常に直面しています。さらに、会話型 AI インタフェースの構築と管理には、多くの場合、専門知識と複数のサービスにまたがる複雑な統合が必要とされます。 これらの課題に対応するため、Amazon Connect は以下のような機能を導入しました： ターゲットを絞ったキャンペーン向けの生成 AI を活用した顧客セグメンテーション オムニチャネルサポートのためのネイティブ WhatsApp Business メッセージング チャットでの顧客機微情報の安全な収集 Amazon Connect インターフェースでの会話型 AI ボット管理の簡素化 Amazon Q in Connect の新機能 また、Amazon Connect は Amazon Connect Contact Lens による新しい分析機能を追加し、ボットのパフォーマンスとコンタクトセンター運用の最適化が可能になりました。 これらの新機能により、最高水準のデータセキュリティと運用の卓越性を維持しながら、よりパーソナライズされた効率的な顧客体験を創出することができます。 生成 AI を活用した機能 Amazon Connectは、顧客との会話を自動化し強化するための新しい生成 AI 機能を統合しました。これにより、よりスマートなターゲティングとより効率的なコンタクトセンター管理が可能になります。 生成 AI セグメンテーションとトリガーベースのキャンペーン – 会話型プロンプトを使用して 顧客セグメント を作成する生成 AI 支援機能を活用します。これにより、組織は自然言語による説明を用いて正確な顧客セグメントを作成できるようになり、特定の顧客グループの識別とリーチがより容易になります。トリガーキャンペーンでは、カート放棄などの特定の顧客イベントに基づいて顧客とコミュニケーションを取ることができます。 提案機能からすぐに使い始めることもできます。 会話型AIボットの作成を簡素化し、Amazon Q in Connect で強化 – Amazon Connect のインターフェースで、 Amazon Lex の会話型 AI ボットの作成、編集、管理が直接行えるようになりました。さらにこれらのボットを顧客サービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect によって強化できます。Amazon Q in Connect は、コンタクトセンターのエージェントに推奨応答やアクションを提案するだけでなく、音声自動応答 (IVR) やデジタルチャネルを通じたエンドユーザーのセルフサービス対応もサポートしました。 この統合により、大規模言語モデル (LLM) を活用した高度な会話能力が提供され、従来の Amazon Lex の音声やチャットボット機能を大幅に拡張します。システムは、あらかじめ設定された応答パターンに合致しない顧客の質問に対して、設定済みのナレッジベースや顧客情報、Web コンテンツ、サードパーティアプリケーションのデータをインテリジェントに検索して回答します。管理者は、インスタンスごとにカスタムガードレールを設定し、回答生成の制限を定義したり、 Amazon Q in Connect のパフォーマンスを監視したりすることができます。 生成 AI を活用したエージェントの自動評価 : スーパーバイザーは生成 AI を使用して、最大で 100% のコンタクトを自動的に評価できるようになりました。 生成 AI を活用したコンタクトの分類 : 自然言語インテントを使用して、既存のセマンティックマッチ機能を改善しました。 インターフェースとツールの改善 ボットの管理とモニタリングの機能を強化し、自動化されたエクスペリエンスの作成と最適化が簡素化されました。 WhatsApp Business メッセージングとの連携 – WhatsApp Business メッセージングとネイティブに統合し、既存の Amazon Connect チャネル (音声、SMS、チャット、 Apple Messages for Business ) に加えて、 WhatsApp 経由でのサポートを顧客に提供可能になりました。Amazon Connect のオムニチャネル機能にこの機能が追加されたことによって、組織は Amazon Connect アプリケーション内で一貫したサービス提供と管理を維持しながら、顧客に応じたコミュニケーションチャネルで対応できるようになります。 Contact Lens 会話型 AI ボットダッシュボード – Amazon Connect で構築された会話型 AI ボットのパフォーマンスを監視するための分析機能を提供します。 コンタクトの詳細におけるセルフサービス音声 (IVR) の録音 – 音声録音を含む、セルフサービス対話の包括的な記録を提供します。 当日予測の改善 – 予測、キャパシティプランニング、スケジューリング機能の一部として、以前に公開された予測と当日予測の比較が可能になりました。 Salesforce Contact Center with Amazon Connect (プレビュー) – Amazon Connect のデジタルチャネルとユニファイドルーティングを Salesforce の顧客関係管理 (CRM) システムにネイティブ統合します。この 新しい統合 により、組織は Amazon Connect と Salesforce のチャネルの両方に単一のルーティングおよびワークフローシステムを使用し、通話、チャット、ケースを最適なセルフサービスまたはエージェントとの対話へインテリジェントに振り分けることができます。ご興味をお持ちの方は、 プレビューへの参加 にサインアップしてください。 チャットのセキュリティ強化 チャットにおけるセキュリティとコンプライアンスを強化する新機能により、機密情報の安全に取り扱うことが可能になります。 チャットでの機密顧客データの収集 – Amazon Connect のチャットおよびメッセージング に、チャット対話中の顧客機密情報を安全に扱うためのデータプライバシーオプションが追加されました。この機能は、個人を特定可能な情報 (PII) とペイメントカード業界 (PCI) データを保護し、データ保護規制へのコンプライアンスを促進します。 主なメリット Amazon Connect の最新機能は、生成 AI、強化されたセキュリティ、合理化されたボット管理を組み合わせることで、組織に以下のメリットをもたらします : 顧客体験の変革 – Amazon Connect は AI を活用したセグメンテーションを通じて顧客とのインタラクションを向上させ、パーソナライズされたエンゲージメント戦略を可能にします。新しい WhatsApp Business メッセージングはオムニチャネルサポート機能を拡張し、顧客の好むチャネルで対応します。さらに Amazon Q in Connect を含む高度なボット機能によりセルフサービスの解決率が向上し、より効率的な顧客体験を提供します。 セキュリティと運用の強化 – コンタクトセンターは、運用効率を維持しながら PCI 準拠のチャット機能によりセキュリティを強化できるようになりました。カスタム AI ガードレールは適切な応答生成を促進し、シンプルなボット管理インターフェースにより専門知識の必要性が排除されます。分析と予測機能は包括的なパフォーマンス監視を提供し、最適なコンタクトセンター運用のためのデータ駆動型の意思決定を可能にします。 価格と利用可能リージョン – これらの機能は、 Amazon Connect がサポートされている すべての AWS リージョン で本日から利用可能です。価格設定については、 Amazon Connect の料金ページ をご覧ください。実装ガイダンスについては、 Amazon Connect のドキュメント をご参照ください。 Elizabeth Fuentes 私の使命は、複雑な概念をわかりやすい説明に分解し、開発者が継続的にスキルと知識を広げられるようにすることです。カンファレンス、チュートリアル、オンラインリソースを通じて、私は自分の専門知識を世界中の開発者コミュニティと共有し、彼らが潜在能力を最大限に発揮するためのツールと自信を提供しています。実践的なアプローチと、複雑なものを簡素化するというコミットメントをもって、私は AWS テクノロジーの世界における成長と学習のきっかけとなるよう努めています。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。

この記事は Effective use: Amazon ECS lifecycle events with Amazon CloudWatch logs insights (記事公開日: 2023 年 12 月 22 日) を翻訳したものです。 導入 スタートアップ企業から大手企業まで、コンテナサービスの採用が増加傾向にあることが観察されています。この傾向は、アプリケーションのデプロイが容易になったことや、オンプレミス環境からクラウドへの移行がしやすくなったことが要因となっています。多くのお客様が選択するプラットフォームの一つが、 Amazon Elastic Container Service（Amazon ECS） です。Amazon ECS の強力でシンプルな特性により、お客様は単一のタスク管理から、企業全体のアプリケーションポートフォリオの監視、さらには数千のタスクの管理にまでスケールアップすることができます。Amazon ECS を利用することで、自社でコンテナオーケストレーションサービスを運用する際に伴う管理の負担が解消されます。 お客様と仕事をしていると、Amazon ECS イベントの活用をさらに高める価値ある機会があることに気づきました。ライフサイクルイベントは、サービスイベントをメトリクスやログと関連付けることで、トラブルシューティングに役立つ洞察を提供します。Amazon ECS は最新の100件のイベントのみを表示するため、過去のイベントを遡って確認することが難しい場合があります。 Amazon CloudWatch Container Insights を使用することで、この問題が解決されます。Container Insights は Amazon ECS のライフサイクルイベントを Amazon CloudWatch Log Group に保存するからです。この連携により、イベントを遡って分析することが可能となり、運用効率が向上します。 Amazon EventBridge は、アプリケーションをシームレスに接続するサーバーレスのイベントバスです。Container Insights と併せて、Amazon ECS はイベントソースとして機能し、Amazon CloudWatch Logs は Amazon EventBridge のターゲットとして動作します。これにより、Amazon CloudWatch Logs Insights を使用したインシデント後の分析が可能になります。 本記事では、Container Insights や Amazon EventBridge 、あるいはその両方を使用して、 Amazon CloudWatch Logs Insights のクエリ を通じて Amazon ECS のサービスイベントを効果的に分析する方法を説明します。これらのクエリは、開発および運用のワークフローを大幅に改善します。 前提条件 このテクニカルガイドで紹介する手法を実践するためには、お客様のアカウントで以下の機能が有効になっている必要があります。 アクティブなワークロードがある Amazon ECS クラスター Amazon EventBridge は、イベントを Amazon CloudWatch ログに直接ストリーミングするか、Amazon ECS CloudWatch Container Insights を有効にするように設定されている ここでは、Amazon CloudWatch Logs または Container Insights にイベントをストリーミングするように Amazon EventBridge をセットアップするための詳細なガイドを紹介します。 Walkthrough 有用なライフサイクルイベントパターン Elastic Container Service（Amazon ECS）が発行するイベントは、以下の4つのグループに分類できます： コンテナインスタンス状態変更イベント – これらのイベントは、Amazon ECS コンテナインスタンスの状態に変更があった場合にトリガーされます。これは、タスクの開始や停止、Amazon ECS エージェントのアップグレード、その他のシナリオなど、様々な理由で発生する可能性があります。 タスク状態変更イベント – これらのイベントは、タスクの状態に変更があるたびに発行されます。例えば、タスクが「PENDING（保留中）」から「RUNNING（実行中）」に移行する場合や、「RUNNING（実行中）」から「STOPPED（停止）」に移行する場合などです。また、タスク内のコンテナが停止した場合や、 AWS Fargate Spot キャパシティーの終了通知を受け取った場合にもイベントがトリガーされます。 サービスアクションイベント – これらのイベントは、サービスの状態に関する情報を提供し、INFO、WARN、ERROR に分類されます。サービスが安定状態に達した場合、サービスが継続的にタスクを配置できない場合、Amazon ECS API がスロットリングされた場合、またはタスクを配置するためのリソースが不足している場合に生成されます。 サービスデプロイメント状態変更イベント – これらのイベントは、デプロイメントが進行中、完了、または失敗した場合に発行されます。通常、サーキットブレーカーロジックとロールバック設定によってトリガーされます。 これらのイベントの詳細な説明と例、および考えられるユースケースについては、 Amazon ECS イベントのドキュメント を参照してください。 それでは、運用サポートにイベントを活用する実際の例をいくつか見ていきましょう。これらの例を、イベントパターンに基づいて4つのカテゴリに分類しました： タスクパターン、サービスアクションパターン、サービスデプロイメントパターン、ECS コンテナインスタンスパターン です。各カテゴリには一般的な使用例が含まれており、具体的なクエリとその結果を示しています。 Amazon CloudWatch Logs Insights クエリの実行方法 この記事の後半で紹介する Amazon CloudWatch Logs Insights クエリを実行するには、以下の手順に従ってください。 Amazon CloudWatch コンソール を開き、「 Logs(ログ) 」を選択し、次に「 Logs Insights（ログのインサイト） 」を選択します。 クエリを実行する Amazon ECS イベントとパフォーマンスログを含むロググループ「/aws/events/ecs/containerinsights/(クラスター名)/performance」を選択します。 目的のクエリを入力し、「 Run(クエリの実行) 」を選択して結果を表示します。 タスクイベントパターン シナリオ 1: このシナリオでは、運用チームが環境内で観察された HTTP ステータス 5XX （サーバーサイドの問題）エラーの原因を調査する必要がある状況に遭遇しています。そのために、彼らは Amazon ECS タスクが意図したタスクライフサイクルを正しく踏んでいるかどうかを確認しようとしています。チームは、タスクのライフサイクルイベントが 5XX エラーの原因となっている可能性を疑っており、効果的なトラブルシューティングと解決を行うために、これらの問題の正確な原因を絞り込む必要があります。 必要なクエリ クエリー入力: detail.containers.0.taskArn: 対象タスク ARN fields time as Timestamp, `detail-type` as Type, detail.lastStatus as `Last Status`, detail.desiredStatus as `Desired Status`, detail.stopCode as StopCode, detail.stoppedReason as Reason | filter detail.containers.0.taskArn = "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/6e81bd7083ad4d559f8b0b147f14753f" | sort @timestamp desc | limit 10 結果: サービスイベントがタスクライフサイクルの確認にどのように役立つかを見てみましょう。結果から、タスクの最終ステータスが以下のように進行したことがわかります： PROVISIONING > PENDING > ACTIVATING > RUNNING > DEACTIVATING > STOPPING > DEPROVISIONING > STOPPED これは タスクライフサイクルの流れ を確認するものであり、タスクは最初に「DEACTIVATED（非アクティブ化）」され、その後「STOPPED（停止）」されたことがわかります。このタスクの停止は、「Task failed container health checks（タスクがコンテナのヘルスチェックに失敗した）」という理由で、スケジューラ（ServiceSchedulerInitiated）によって開始されたことが確認できます。 同様に、クエリを使用して、ロードバランサーのヘルスチェックに失敗したタスクのライフサイクルの詳細を取得することもできます。結果は以下のようになります： 以下のクエリで、detail.containers.0.taskArn を目的のタスクARNに置き換えてください： fields time as Timestamp, `detail-type` as Type, detail.lastStatus as `Last Status`, detail.desiredStatus as `Desired Status`, detail.stopCode as StopCode, detail.stoppedReason as Reason | filter detail.containers.0.taskArn = "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/649e1d63f0db482bafa0087f6a3aa5ed" | sort @timestamp desc | limit 10 StopTask を呼び出して手動で停止されたタスクの別の例を見てみましょう。この場合、アクションは UserInitiated （ユーザーによって開始された）で、理由は Task stopped by user （ユーザーによってタスクが停止された）となっています： さらに、両方のケースにおいて、Desired State （必要なステータス）が（誰がタスクの停止を開始したかに関係なく）タスクの Last Status （前回のステータス）をどのように導いているかを確認することができます。 参考：タスクライフサイクル シナリオ 2: サービス内でタスクの失敗が頻繁に発生し、これらの問題の根本原因を診断する手段が必要となるシナリオを考えてみましょう。タスクは、リソースの制限やアプリケーションのエラーなど、さまざまな理由で終了する可能性があります。この問題に対処するために、サービス内のすべてのタスクの停止理由をクエリして、根底にある問題を明らかにすることができます。 必要なクエリ クエリー入力: detail.group: 対象のサービス名 filter `detail-type` = "ECS Task State Change" and detail.desiredStatus = "STOPPED" and detail.group = "service:circuit-breaker-demo" |fields detail.stoppingAt as stoppingAt, detail.stoppedReason as stoppedReason,detail.taskArn as Task | sort @timestamp desc | limit 200 ヒント: サービスの自動スケーリングが有効になっていて、サービスに頻繁なスケーリングイベントがある場合は、上記のクエリにさらにフィルターを追加して、スケーリングに関連するイベントを除外し、他の停止理由に焦点を絞ることができます。 filter `detail-type` = "ECS Task State Change" and detail.desiredStatus = "STOPPED" and detail.stoppedReason not like "Scaling activity initiated by" and detail.group = "service:circuit-breaker-demo" |fields detail.stoppingAt as stoppingAt, detail.stoppedReason as stoppedReason,detail.taskArn as Task | sort @timestamp desc | limit 200 結果: 結果では、サービス内のタスクの停止理由と、それぞれのタスクIDを確認することができます。これらの停止理由を分析することで、タスクの終了につながる具体的な問題を特定できます。停止理由に応じて、考えられる解決策には、アプリケーションの調整、リソース割り当ての調整、タスク定義の最適化、またはスケーリング戦略の微調整などが含まれる可能性があります。 シナリオ 3: セキュリティチームが特定のネットワークインターフェース、MAC アドレス、またはアタッチメント ID の使用に関する重要な情報を必要とするシナリオを考えてみましょう。Amazon ECS がタスクの開始と停止時に自動的に Elastic Network Interface（ENI）をプロビジョニングおよびデプロビジョニングすることは重要なポイントです。しかし、タスクが停止されると、Elastic Network Interface（ENI）や ENI に割り当てられた Media Access Control（MAC）情報を使用して、あるタスク ID を特定するための記録や関連性がすぐに利用できなくなります。Amazon ECS が自動的に ENI を管理する特性上、これらの識別子の履歴を追跡する能力が制限される可能性があるため、このようなデータを求めるセキュリティチームの要求に応えることが課題となります。 必要なクエリ クエリー入力: detail.attachments.0.details.1.value : 対象となる ENI ID 追加:タスク ARN とクラスター ARN の詳細の置換 fields @timestamp, `detail.attachments.0.details.1.value` as ENIId,`detail.attachments.0.status` as ENIStatus, `detail.lastStatus` as TaskStatus | filter `detail.attachments.0.details.1.value` = "eni-0e2b348058ae3d639" | parse @message "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/*\"" as TaskId | parse @message "arn:aws:ecs:us-east-1:111122223333:cluster/*\"," as Cluster | parse @message "service:*\"," as Service | display @timestamp, ENIId, ENIStatus, TaskId, Service, Cluster, TaskStatus ENI ID で検索するには、detail.attachments.0.details.2.valueの値を MAC アドレスに置き換えてください。 fields @timestamp, `detail.attachments.0.details.1.value` as ENIId, `detail.attachments.0.details.2.value` as MAC ,`detail.attachments.0.status` as ENIStatus, `detail.lastStatus` as TaskStatus | filter `detail.attachments.0.details.2.value` = '12:eb:5f:5a:83:93' | parse @message "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/*\"" as TaskId | parse @message "arn:aws:ecs:us-east-1:111122223333:cluster/*\"," as Cluster | parse @message "service:*\"," as Service | display @timestamp, ENIId, MAC, ENIStatus, TaskId, Service, Cluster, TaskStatus 結果: ENI ID により、ENI がプロビジョニングされたタスク/サービス/クラスターの詳細と、関連付いたタスクの状態が結果に表示されます。 ENI と同様に、 MAC アドレスでクエリを実行しても ENI の時と同じ詳細内容を確認できます。 サービスアクションイベントパターン シナリオ 4: 最も多くの障害が発生しているサービスを特定し、その解決を優先する必要がある状況に遭遇するかもしれません。これを達成するために、問題が発生している上位 N 個のサービスをクエリして特定したいと考えています。 必要なクエリ: filter `detail-type` = "ECS Service Action" and @message like /(?i)(WARN)/ | stats count(detail.eventName) as countOfWarnEvents by resources.0 as serviceArn, detail.eventName as eventFault | sort countOfWarnEvents desc | limit 20 結果: WARN イベントをフィルタリングし、サービス固有の発生を集計することで、即座に対応が必要なサービスを特定できます。たとえば、このケースでは ecsdemo-auth-no-sd というサービスが SERVICE_TASK_START_IMPAIRED エラーに直面しています。これにより、最も影響の大きい問題の緩和と、マイクロサービスエコシステム全体の信頼性向上にリソースを集中させることができます： サービス展開イベントパターン シナリオ 5: Amazon ECS のすべてのサービスには、INFO、WARN、ERROR のいずれかのイベントタイプがあることがわかっているので、これを検索パターンとして使用して、問題のあるサービスについてワークロードを分析することができます。 必要なクエリ: fields @timestamp as Time, `resources.0` as Service, `detail-type` as `lifecycleEvent`, `detail.reason` as `failureReason`, @message | filter `detail.eventType` = "ERROR" | sort @timestamp desc | display Time, Service, lifecycleEvent, failureReason | limit 100 結果: 以下の結果では、ecsdemo-backend サービスがタスクの正常なデプロイに失敗しており、これによって Amazon ECS のサーキットブレーカーメカニズムが作動し、サービスのデプロイメントが停止されています。テーブルの左側にある展開矢印を使用すると、イベントに関するより詳細な情報を得ることができます： サービス展開イベントパターン シナリオ 6: このシナリオでは、あなたは運用チームから通知を受け取りました。最近の Amazon ECS サービスへのデプロイメント後も、アプリケーションの以前のバージョンがまだ表示されているとのことです。新しいデプロイメントが予想通りに古いものを置き換えなかったという状況に直面しており、混乱や潜在的な問題を引き起こしています。運用チームは、デプロイメントプロセス中に発生したイベントの一連の流れを理解し、何が問題だったのか原因を特定し、デプロイメントを確実に成功するために必要な是正措置を実施したいと考えています。 必要なクエリ クエリー入力: resources.0: 対象サービス ARN fields time as Timestamp, detail.deploymentId as DeploymentId , detail.eventType as Severity, detail.eventName as Name, detail.reason as Detail, `detail-type` as EventType | filter `resources.0` ="arn:aws:ecs:us-east-1:12345678910:service/CB-Demo/circuit-breaker-demo" | sort @timestamp desc | limit 10 結果: デプロイメント中に何が問題だったのかを理解するため、サービスイベントを分析してみましょう。イベントの順序を調べることで、明確なタイムラインが浮かび上がります： サービスが最初は安定状態にあり（7行目）、デプロイメントは適切であった（6行目の ecs-svc/6629184995452776901）ことがわかります。 新しいデプロイメント（ecs-svc/4503003343648563919）が発生し、おそらくコードのバグがあったと思われます（5行目）。 このデプロイメントのタスクが起動に失敗しています（3行目）。 この問題のあるデプロイメントがサーキットブレーカーロジックをトリガーし、以前の正常なデプロイメント（4行目の ecs-svc/6629184995452776901）へのロールバックを開始しています。 最終的にサービスは安定状態に戻ります（1行目と2行目）。 このイベントの流れは、何が起こったかの時系列的な視点を提供するだけでなく、関連するデプロイメントと問題の潜在的な理由についての具体的な洞察も提供しています。これらのサービスイベントを分析することで、運用チームは問題のあるデプロイメント（つまり、ecs-svc/4503003343648563919）を特定し、さらに調査して根本的なコードの問題を特定し対処することができ、将来のデプロイプロセスの信頼性が高まります。 ECS コンテナインスタンスのイベントパターン: シナリオ 7: クラスター内のコンテナインスタンスに対する Amazon ECS エージェントの更新履歴を追跡したいと考えています。追跡可能な履歴があれば、エージェントに必要なパッチと更新がインストールされていることを確認できるため、セキュリティ基準への準拠が保証されます。また、問題のある更新があった場合にロールバックの検証も可能になります。この情報は、運用効率とサービスの信頼性に役立ちます。 必要なクエリ: fields @timestamp, detail.agentUpdateStatus as agentUpdateStatus, detail.containerInstanceArn as containerInstanceArn,detail.versionInfo.agentVersion as agentVersion | filter `detail-type` = "ECS Container Instance State Change" | sort @timestamp desc | limit 200 結果: 結果からわかるように、コンテナインスタンスのエージェントは v 1.75.0 でした。 エージェントの更新がトリガーされると、エージェントを更新するプロセスはシーケンス9で開始され、最終的にシーケンス1で完了しました。 当初、コンテナインスタンスは ECS Agent バージョン 1.75.0 で動作していました。 その後、シーケンス 9 で更新操作が開始され、新しい Amazon ECS エージェントバージョンが存在することが示されました。 一連のアップデートアクションの後、エージェントアップデートはシーケンス1で正常に終了しました。 この情報は、バージョン移行と更新手順の明確なスナップショットを提供し、ECS クラスターのセキュリティ、信頼性、および機能性を確保するために Amazon ECS エージェントの更新を追跡することの重要性を強調しています。 クリーンアップ サンプルクエリの探索が完了したら、追加のコストが発生しないように、Amazon EventBridge ルールと Amazon ECS CloudWatch コンテナインサイトを必ず無効にしてください。 結論 この記事では、トラブルシューティングに貴重なリソースである Amazon ECS イベントの可能性を最大限に活用する方法を探ってきました。Amazon ECS は、タスク、サービス、デプロイメント、およびコンテナインスタンスに関する有用な情報を提供します。Amazon CloudWatch Logs で ECS イベントを分析することで、時間の経過に伴うパターンの特定、他のログとのイベントの相関関係の把握、繰り返し発生する問題の発見、そして様々な形式の分析を行うことができます。 我々は、Amazon ECS イベントを検索し活用するための簡単でありながら強力な方法を概説しました。これには、予期せぬ停止を素早く診断するためのタスクのライフサイクルの追跡、セキュリティを強化するための特定のネットワーク詳細を持つタスクの特定、問題のあるサービスの特定、デプロイメントの問題の理解、そして信頼性のための Amazon ECS エージェントの最新状態の確認が含まれます。システムの運用に関するこの幅広い視点により、問題に積極的に対処し、コンテナのパフォーマンスに関する洞察を得て、スムーズなデプロイを促進し、システムのセキュリティを強化することができます。 その他の参考資料 ライフサイクルイベントの基本について説明したので、次はトラブルシューティングの目的で Amazon CloudWatch Log Insights コンソールでこれらのライフサイクルイベントをクエリするベストプラクティスを見てみましょう。 Amazon CloudWatch クエリのドメイン固有言語 (DSL) の詳細については、ドキュメント ( CloudWatch ログインサイトのクエリ構文 ) を参照してください。 Amazon ECS イベントの EventBridge をさらに処理することで、異常検出をさらにセットアップすることができます。これについては、「 Amazon EventBridge を利用した Amazon Elastic Container Service Anomaly Detector 」で詳しく説明されています。 翻訳はクラウドサポートエンジニアの桐生が担当しました。原文は こちら です。

本記事は 2024 年 11 月 21 日に公開された “ Amazon ElastiCache version 8.0 for Valkey brings faster scaling and improved memory efficiency ” を翻訳したものです。 2024 年 11 月 21 日、 Amazon ElastiCache で Valkey 8.0 のサポートを追加しました。 ElastiCache for Valkey バージョン 8.0 では、ElastiCache Serverless のスケーリングが高速化され、ノードベースのクラスターのメモリ最適化が実現されています。 このブログ記事では、これらの改善点をどのように活用できるかについて説明します。 ご存知ない方に説明しますと、 Valkey は、オープンソースのインメモリ型キーバリューデータストアです。Redis OSS の代替として使用できます。 Linux Foundation が管理しており、活発な開発者コミュニティからの貢献により急速に改善が進んでいます。 AWS は Valkey に積極的に貢献しています。AWS の Valkey への貢献について詳しくは、 Amazon ElastiCache と Amazon MemoryDB の Valkey サポート を発表 をご覧ください。 先月、価格を改定した ElastiCache バージョン 7.2 for Valkey を 発表 しました。 ElastiCache は、Valkey、Memcached、Redis OSS と互換性のあるフルマネージド型のキャッシングサービスで、99.99% の可用性を備えたモダンアプリケーション向けにリアルタイムでコスト最適化されたパフォーマンスを提供します。 ElastiCache は、マイクロ秒単位の読み取りと書き込みのレスポンスタイムで、1 秒あたり数百万のオペレーションまでスケールし、データベースとアプリケーションのパフォーマンスを向上させます。 ElastiCache Serverless のスケーリング改善 ElastiCache Serverless を使用すると、1 分以内にキャッシュを作成し、アプリケーションのトラフィックパターンに基づいて容量をスケーリングできます。 これまで、キャッシュの適切なサイジングはコストとパフォーマンスのバランスを取る作業でした。 ピーク時に十分なバッファを持った容量をプロビジョニングすることはできましたが、使用していない容量に対しても料金を支払う必要がありました。 あるいは、必要最小限の容量をプロビジョニングし、必要に応じて手動でスケーリングすることもできましたが、予期せぬトラフィックの急増が発生した場合にパフォーマンスのボトルネックに遭遇する可能性がありました。 私たちは、最も要求の厳しいワークロードでも容量計画を必要とせずにキャッシュを運用できるよう、ElastiCache Serverless をリリースしました。 リリース以来、多くのお客様から、バイラル化した(いわゆるバズった)ライブイベントなどに発生する突発的なトラフィックに対して、より迅速にアプリケーションをスケーリングできるようにしてほしいという要望をいただいています。 ElastiCache Serverless version 8.0 for Valkey は、急激な負荷変動や急速にスケールするワークロードへの対応を改善しました。 以前の ElastiCache Serverless では、10-12 分ごとに 1 秒あたりのリクエスト数 (RPS) を 2 倍にすることができました。 Valkey 8.0 では、ElastiCache Serverless は 13 分以内に 0 から 500 万 RPS までスケールでき、2-3 分ごとに対応可能な RPS を 2 倍にすることができます。 これらの改善をどのように実現したのか、そしてベンチマークの結果について見ていきましょう。 Valkey 8.0 では、AWS が新しいマルチスレッドアーキテクチャを通じて 100 万以上の RPS を達成するなど、大幅なパフォーマンス向上を実現しました。 新しい I/O スレッド実装により、メインスレッドと I/O スレッドが並行して動作し、コマンドの読み取りと解析、レスポンスの書き込み、I/O イベントのポーリングなどのタスクをオフロードできます。 この設計により、同期メカニズムを最小限に抑え、Valkey のシンプルさを維持しながらパフォーマンスを向上させています。 オープンソースの Valkey 8.0 における I/O マルチスレッドの具体的な改善点については、 Unlock 1 Million RPS: Experience Triple the Speed with Valkey をご覧ください。 これらの改善点は、ElastiCache Serverless version 8.0 for Valkey で活用され、より高速なバーストスケーリングとスケールアウト操作を処理できるようになりました。 オンデマンドでより多くのコアを有効化し、I/O スレッディングを最適化することで、ElastiCache Serverless は追加のスループットをサポートするために I/O スレッドを動的に割り当てることができます。 さらに、ElastiCache Serverless は、新しいシャードへのデータ移行を含む水平スケーリングを処理するために、追加の I/O スレッドを割り当てることができます。 この強化されたスケーリング機能により、ElastiCache Serverless は高トラフィックのシナリオやトラフィックの急増をより効果的に処理でき、高スループットと最小限のレイテンシーを必要とするアプリケーションに恩恵をもたらします。 ベンチマークデータ ElastiCache Serverless for Valkey 8.0 でアプリケーションワークロードをどれだけ迅速にスケールできるかを示すために、典型的なキャッシングのユースケースを選びました。 アプリケーションが 512 バイトの値をキャッシュし、読み取りと書き込みのトラフィックの比率がおよそ 80 対 20 であると仮定します。 このテストでは、アプリケーションのリクエストレートが 0 RPS から 500 万 RPS まで増加すると想定しています。 ElastiCache Serverless for Valkey バージョン 7.2 まず、以前のバージョンである ElastiCache Serverless version 7.2 for Valkey で実行されているワークロードを見てみましょう。 以下のグラフは、キャッシュに対するワークロードによって実行された 1 秒あたりのリクエスト数 (RPS) と、p50 および p99 レイテンシーを示しています。 グラフが示すように、ElastiCache Serverless for Valkey バージョン 7.2 は、グラフの紫色の線で示されているように、ピークの 500 万 RPS までスケールするのに約 50 分かかり、10 分ごとに RPS が効果的に 2 倍になっています。 この間、p50 読み取りレイテンシー (青線) は 1 ミリ秒未満を維持していますが、p99 レイテンシー (オレンジ色と赤色の線) は最大 9 ミリ秒まで上昇します。 ElastiCache Serverless for Redis バージョン 8.0 次に、ElastiCache Serverless for Valkyl バージョン 8.0 で実行されている同じワークロードを見てみましょう。 グラフからわかるように、ElastiCache Serverless version 8.0 for Valkey は、はるかに高速なスケーリングを実現し、0 から 500 万回/秒 のピークまで 13 分未満で到達し、実質的に 2 分ごとに対応可能な RPS を 2 倍にしています。 応答時間の特性は一貫しており、読み取り応答時間の 50 パーセンタイル値は 1 ミリ秒未満を維持し、応答時間の 99 パーセンタイル値は 7～8 ミリ秒まで上昇します。 結果の概要 以下の表は、ベンチマーク結果をまとめたものです。 ElastiCache モード ベースラインからピーク RPS に到達するまでの時間 p50 読み取りレイテンシー p99 読み取りレイテンシー ElastiCache Serverless version 7.2 for Valkey 50 分 800 マイクロ秒未満 8-9 ms ElastiCache Serverless version 8.0 for Valkey 13 分 800 マイクロ秒未満 7-8 ms メモリ使用量の改善 Valkey 8.0 では、ワークロードのメモリ使用量とリソース消費を削減するのに役立つ、重要なメモリ効率の改善が導入されています。 まず、この分野で AWS が OSS Valkey に貢献した改善点について見ていきましょう。 OSS Valkey 8.0 の主な機能強化の 1 つは、クラスター構成におけるメモリ管理の最適化です。 以前の Valkey のクラスターモードでは、16,384 個のハッシュスロットにデータを分散させており、特に大規模なデプロイメントでは大量のメタデータのオーバーヘッドが必要でした。 Valkey 8.0 では「スロットごとの辞書」モデルを採用し、スロットごとのメタデータ要件を削減することでメモリ使用量を低減しています。 このアップデートにより、キーあたり 32 バイトのメモリ削減が実現し、ワークロードのキーサイズによっては大幅なメモリ削減につながる可能性があります。 Valkey 8.0 の改善点に関する技術的な詳細については、 Storing more with less: Memory Efficiency in Valkey 8 をご覧ください。 では、これが Valkey の ElastiCache バージョン 8.0 でどのように実現されているかを見てみましょう。 Valkey 用の ElastiCache Serverless の価格設定では、これらのメモリ最適化を見込んで、潜在的なコスト削減を反映させました。 GB あたりおよび ECPU あたりの価格を引き下げ、ストレージの最小容量を 1 GB から 100 MB に削減し、Valkey 用の ElastiCache Serverless の価格を Redis OSS 版と比べて 33% 低く設定しました。 さらに、Valkey 8.0 では、SET データ構造を使用するユーザーは、SET の要素あたり 24 バイト少なくなり、さらなるコスト削減が可能になります。 クラスターモードで Valkey 8.0 を実行するノードベースのクラスターでは、このメモリ効率化によりあらゆる面でメモリ消費量が削減されます。 ベンチマークでは、16 バイトのキーと 100 バイトの値を使用する文字列のワークロードをテストしました。 同一のデータを Valkey 7.2 を実行するクラスターと Valkey 8.0 を実行するクラスターに格納し、この新しいリリースで実現できるメモリ削減量を明らかにしました。 サーバーレスキャッシュにデータを追加するためには valkey-benchmark ツールを使用しました。 src/valkey-benchmark \ -t set \ -n 10000000 \ -r 10000000 \ -d 100 Valkey 7.2 クラスターのメモリ使用量を確認しました: Valkey 7.2> DBSIZE (integer) 6322820 Valkey 7.2> INFO MEMORY # Memory used_memory:1491244824 used_memory_human:1.39G 次に、Valkey 8.0 クラスターのメモリ使用量を確認しました。 Valkey 8.0> DBSIZE (integer) 6319345 Valkey 8.0> INFO MEMORY # Memory used_memory:1192317904 used_memory_human:1.11G この特定のワークロードでは、ノードベースのクラスターのメモリ使用量が 1.39 GB から 1.11 GB に減少し、メモリ使用量が 20% 削減されました。 このメモリ使用量の削減は、このワークロードの種類に特有のものです。 ワークロードの詳細によって、メモリ使用量の削減量は異なる場合があります。 まとめ ElastiCache for Valkey バージョン 8.0 が、すべての AWS リージョンで利用可能になりました。 Redis OSS および Valkey 7.2 から Valkey 8.0 へ、ElastiCache Serverless キャッシュとノードベースの ElastiCache クラスターをアップグレードし、パフォーマンスとメモリ使用率の改善を活用することをお勧めします。 スケーリングの改善とメモリ効率の向上に加えて、ElastiCache for Valkey への移行はコスト削減にも役立ちます。 ElastiCache Serverless for Valkey は、他のエンジン向けの ElastiCache Serverless と比べて 33% 低価格で、ノードベースの ElastiCache for Valkey は 20% 低価格です。 ElastiCache Serverless for Valkey は、月額 6 ドルという低価格で始めることができます。 ElastiCache for Valkey のバージョン 8.0 の詳細については、What’s new ページをご覧ください。ElastiCache for Valkey の使用開始方法については、 Amazon ElastiCache for Valkeyの開始方法 の詳細な手順をご参照ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Abhay Saxena は、Amazon Web Services のインメモリデータベースチームのプロダクトマネージャーで、ElastiCache Serverless を担当しています。 ElastiCache チームに参加する前は、Amazon で 13 年以上プロダクトマネージャーとして勤務していました。 Rashim Gupta は AWS のシニアマネージャー、製品管理で、Amazon ElastiCache と Amazon MemoryDB の製品責任者を務めています。 AWS で 6 年以上の経験を持ち、コンピュート、ストレージ、データベースの分野でプロダクトマネージャーとして従事してきました。

本記事は 2024 年 11 月 12 日に公開された “ Use Amazon ElastiCache as a cache for Amazon Keyspaces (for Apache Cassandra) ” を翻訳したものです。 この投稿では、ブックアワードのデータを保存するために Amazon Keyspaces (for Apache Cassandra) テーブルを使用するアプリケーションのライトスルーキャッシュとして Amazon ElastiCache を使用する方法をご紹介します。Amazon Keyspaces にプログラムでアクセスするために Cassandra Python クライアントドライバー を使用し、ElastiCache クラスターに接続するために Redis クライアント を使用します。 Amazon Keyspaces は、スケーラブルで高可用性を備えた、フルマネージド型の Cassandra 互換データベースサービスで、どのようなスケールでも数ミリ秒の読み取りと書き込みのレスポンスタイムを提供します。 Amazon Keyspaces はサーバーレスであるため、クラスター内のノードを通じてワークロードのストレージと計算リソースをデプロイ、管理、維持する代わりに、テーブルに直接ストレージと読み取り/書き込みスループットリソースを割り当てます。 ほとんどのワークロードでは、Amazon Keyspaces が提供する 1 桁ミリ秒の応答時間で十分であり、Amazon Keyspaces が返す結果をキャッシュする必要はありません。 しかし、アプリケーションが読み取り操作でサブミリ秒の応答時間を必要とする場合や、読み取り集中型でありながらコストに敏感な場合、あるいはパーティションごとに 1 秒あたり 3,000 読み取りキャパシティユニット (RCU) を超えるような繰り返しの読み取りが必要な場合があります。 Amazon ElastiCache は、フルマネージド型で高可用性を備えた分散型の高速インメモリデータストアで、Amazon Keyspaces テーブルのキャッシュとして使用でき、読み取りレイテンシーをサブミリ秒レベルまで短縮し、読み取りスループットを向上させ、バックエンドデータベースのコストを増やすことなく、より高い負荷にスケールできます。 Amazon ElastiCache は、オープンソースのキーバリューストアである Valkey および Redis OSS と互換性があります。 この投稿で説明するアプローチとコードは、これらのエンジンの両方で動作します。 この投稿では、ライトスルーキャッシュ方式と遅延読み込みを使用しています。 ライトスルーキャッシュは、初期レスポンス時間を改善し、キャッシュされたデータを基盤となるデータベースと同期した状態に保ちます。 遅延読み込みでは、キャッシュミスが発生した場合にのみデータがキャッシュにロードされるため、キャッシュのリソース使用量が削減されます。 キャッシュ設計の詳細については、 キャッシングパターン と キャッシュ設計 を参照してください。 前提条件 Amazon Keyspaces への接続の前提条件 には、TLS 証明書のダウンロードと TLS を使用するための Python ドライバーの設定、関連する Python パッケージのダウンロード、そしてキースペースとテーブルへの接続設定が含まれます。 以下は、 Amazon Keyspaces SigV4 認証プラグイン を使用して Amazon Keyspaces テーブルに接続するための定型コードです。 from cassandra.cluster import * from ssl import SSLContext, PROTOCOL_TLSv1_2 , CERT_REQUIRED from cassandra.auth import PlainTextAuthProvider from cassandra_sigv4.auth import SigV4AuthProvider from cassandra.query import SimpleStatement import time import boto3 ssl_context = SSLContext(PROTOCOL_TLSv1_2) ssl_context.load_verify_locations('/home/ec2-user/sf-class2-root.crt') ssl_context.verify_mode = CERT_REQUIRED boto_session = boto3.Session() auth_provider = SigV4AuthProvider(boto_session) cluster = Cluster(['cassandra.us-east-1.amazonaws.com'], ssl_context=ssl_context, auth_provider=auth_provider, port=9142) session = cluster.connect() sigv4 プラグインを使用することが、推奨されるセキュリティのベストプラクティスです。ただし、Cassandra が認証とアクセス管理に使用する従来のユーザー名とパスワードとの下位互換性のために、 サービス専用の認証情報 を使用して Amazon Keyspaces に接続することもできます。 ElastiCache クラスターへの接続手順については、 ElastiCache への接続 を参照してください。 以下は、ElastiCache クラスターに接続するための定型コードです： from rediscluster import RedisCluster import logging logging.basicConfig(level=logging.ERROR) redis = RedisCluster(startup_nodes=[{"host": "keyspaces-cache.eeeccc.clustercfg.use1.cache.amazonaws.com", "port": "6379"}], decode_responses=True, skip_full_coverage_check=True) if redis.ping(): logging.info("Connected to Redis") Amazon Keyspaces テーブルスキーマ この例では、catalog というキースペースにある book_awards という名前の Amazon Keyspaces テーブルを使用して、ブックアワードに関するデータを保存しています。 パーティションキーは award と year のカラムで構成されています。 次のスクリーンショットに示すように、このテーブルには category と rank という 2 つのクラスタリングキーカラムがあります。 このキースキーマにより、パーティション全体にデータが均等に分散され、この投稿で説明するアクセスパターンに対応できます。 Amazon Keyspaces のデータモデリングのベストプラクティスについては、 データモデリングのベストプラクティス：データモデル設計のための推奨事項 を参照してください。 以下のスクリーンショットは、このテーブルのサンプルデータを数行表示しています。 次のセクションでは、Amazon Keyspaces の操作とそれらの操作のキャッシュ結果に関するサンプルコードスニペットを見ていきます。 このブログ記事のコードスニペットは参考用であり、入力の検証とエラー処理はサンプルには含まれていません。 単一行の INSERT および DELETE 操作 ライトスルーキャッシングプロセスでは、プライマリデータベースの更新直後にキャッシュが積極的に更新されます。 基本的なロジックは以下のようにまとめることができます： アプリケーションが Amazon Keyspaces の行を追加または削除します その直後に、キャッシュ内の行も追加または削除されます 以下の図は、ライトスルーキャッシング戦略を示しています。 以下のサンプルコードは、book_awards データに対する INSERT および DELETE 操作に対して、ライトスルー戦略を実装する方法を示しています。 #Global variables keyspace_name="catalog" table_name="book_awards" #Write a row def write_award(book_award): write_award_to_keyspaces(book_award) write_award_to_cache(book_award) #write row to the Keyspaces table def write_award_to_keyspaces(book_award): stmt=SimpleStatement(f"INSERT INTO {keyspace_name}.{table_name} (award, year, category, rank, author, book_title, publisher) VALUES (%s, %s, %s, %s, %s, %s, %s)", consistency_level=ConsistencyLevel.LOCAL_QUORUM) session.execute(stmt,(book_award["award"], book_award["year"], book_award["category"], book_award["rank"], book_award["author"], book_award["book_title"], book_award["publisher"])) #write row to the cache def write_award_to_cache(book_award): #construct Redis key name key_name=book_award["award"] + str(book_award["year"])+ book_award["category"] + str(book_award["rank"]) #write to cache using Redis set, ex=300 sets TTL for this row to 300 seconds redis.set(key_name, str(book_award), ex=300) #Delete a row def delete_award(award, year, category, rank): delete_award_from_keyspaces(award, year, category, rank) delete_award_from_cache(award, year, category, rank) #delete row from Keyspaces table def delete_award_from_keyspaces(award, year, category, rank): stmt = SimpleStatement(f"DELETE FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank=%s ;", consistency_level=ConsistencyLevel.LOCAL_QUORUM) session.execute(stmt, (award, int(year), category, int(rank))) #delete row from cache def delete_award_from_cache(award, year, category, rank): #construct Redis key name key_name=award + str(year)+ category + str(rank) #delete the row from cache if it exists if redis.get(key_name) is not None: book_award=redis.delete(key_name) プライマリーキーによる単一のブックアワードの取得 遅延ロードを使用した基本的なデータ取得ロジックは、以下のようにまとめることができます。 アプリケーションがデータベースからデータを読み取る必要がある場合、まずキャッシュをチェックしてデータが利用可能かどうかを確認します。データが利用可能な場合 (キャッシュヒット)、キャッシュされたデータが返され、呼び出し元にレスポンスが送信されます データが利用できない場合 (キャッシュミス)： データベースにデータを問い合わせます データベースから取得したデータをキャッシュに格納し、そのデータを呼び出し元に返します 以下の図は、データ取得のロジックを示しています。 このユースケースで想定される最も一般的なアクセスパターンの 1 つは、すべてのプライマリキーの列が既知の場合にブックアワードを要求することです。 レイジーローディング戦略では、アプリケーションはまずキャッシュからリクエストされたデータの取得を試みます。キャッシュに行が見つからない場合、データベースから行を取得し、将来の使用のためにキャッシュします。 TTL (Time to Live) は、キーの有効期限を秒単位で指定する整数値です。Valkey や Redis OSS では、この値に秒またはミリ秒を指定できます。この例では TTL 値を 300 秒に設定していますが、アプリケーションのニーズに応じて設定を変更できます。 さらに、Python の time ライブラリを使用して、データベースからの結果取得とキャッシュからの結果取得の応答時間を比較することができます。 #Global variables keyspace_name="catalog" table_name="book_awards" #Read a row def get_award(award, year, category, rank): #construct Redis key name from parameters key_name=award + str(year)+ category + str(rank) start=time.time() book_award=redis.get(key_name) end=time.time() elapsed=(end - start)*1000 #if row not in cache, fetch it from Keyspaces table if not book_award: print("Fetched from Cache: ", book_award) stmt = SimpleStatement(f"SELECT * FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank=%s ;") start=time.time() res=session.execute(stmt, (award, int(year), category, int(rank))) end=time.time() elapsed=(end - start)*1000 if not res.current_rows: print("Fetched from Database: None") return None else: #lazy-load into cache book_award=redis.set(key_name, str(res.current_rows), ex=300) print("Fetched from Database in: ", elapsed, "ms") return res.current_rows else: print("Fetched from Cache in: ", elapsed, "ms") return book_award 複数のパラメータに基づく結果セットの取得 ここでのもう 1 つの一般的なアクセスパターンは、「X 年の Y カテゴリーにおける上位 N 件の受賞データを取得する」と想定されています。 この記事では、リクエストパラメータを連結し、この連結された文字列を、リクエストパラメータに一致する賞のリストの Redis キーとして使用します。 #Global variables keyspace_name="catalog" table_name="book_awards" #Read one or more rows based on parameters def get_awards(parameters): #construct key name from parameters key_name="" for p in parameters: key_name=key_name + str(p) start=time.time() book_awards=redis.lrange(key_name, 0, -1) end=time.time() elapsed=(end - start)*1000 #if result set not in cache, fetch it from Keyspaces table if not book_awards: print("Fetched from Cache: ", book_awards) stmt = SimpleStatement(f"SELECT * FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank<=%s ;") start = time.time() res=session.execute(stmt, parameters) end=time.time() elapsed=(end - start)*1000 if not res.current_rows: print("Fetched from Database: None") return None else: #lazy-load into cache redis.rpush(key_name, str(res.current_rows)) redis.expire(key_name, 300) print("Fetched from Database in: ", elapsed, "ms") return res.current_rows else: print("Fetched from Cache: ", elapsed, "ms") return book_awards テストケース 最初のテストケースでは、単一行のデータ挿入、キャッシュヒット、キャッシュミス、データ削除のシナリオにおけるキャッシュと遅延ロードの動作を検証します。 def test_case_1(): book_award={"award": "Golden Read", "year": 2021, "category": "sci-fi", "rank": 2, "author": "John Doe", "book_title": "Tomorrow is here", "publisher": "Ostrich books"} #insert an award to the DB and cache write_award(book_award) print("Test Case 1:") print("New book award inserted.") #cache hit - get award from cache print("\n") print("Verify cache hit:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #let the cache entry expire print("\n") print("Waiting for cached entry to expire, sleeping for 300 seconds...") time.sleep(300) #cache miss - get award from DB and lazy load to cache print("\n") print("Entry expired in cache, award expected to be fetched from DB:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #cache hit - get award from cache print("\n") print("Verify that award is lazy loaded into cache:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #delete the award from cache and DB print("\n") print("Deleting book award.") delete_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) #confirm the award was deleted from cache and DB print("\n") print("Verify that the award was deleted from cache and DB:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) if res: print(res) このテストケースを実行すると、予想通り以下のような出力が生成されます。 キャッシュからデータを取得する場合は 1 ミリ秒未満の往復時間が観測され、データベースへの問い合わせの場合はミリ秒単位の応答時間が観測されます。 Test Case 1: New book award inserted. Verify cache hit: Fetched from Cache in: 0.3809928894042969 ms {'award': 'Golden Read', 'year': 2021, 'category': 'sci-fi', 'rank': 2, 'author': 'John Doe', 'book_title': 'Tomorrow is here', 'publisher': 'Ostrich books'} Waiting for cached entry to expire, sleeping for 300 seconds... Entry expired in cache, award expected to be fetched from DB: Fetched from Cache: None Fetched from Database in: 14.202594757080078 ms [Row(year=2021, award='Golden Read', category='sci-fi', rank=2, author='John Doe', book_title='Tomorrow is here', publisher='Ostrich books')] Verify that award is lazy loaded into cache: Fetched from Cache in: 0.4191398620605469 ms [Row(year=2021, award='Golden Read', category='sci-fi', rank=2, author='John Doe', book_title='Tomorrow is here', publisher='Ostrich books')] Deleting book award. Verify that the award was deleted from cache and DB: Fetched from Cache: None Fetched from Database: None 2 番目のテストケースでは、複数のパラメータに基づいて結果セットを取得する際のキャッシュと遅延ロードの動作を検証します。 このポストの Amazon Keyspaces テーブルスキーマ セクションで説明したように、Amazon Keyspaces テーブルには書籍の受賞データがあらかじめ読み込まれています。 このテストケースでは、データベースに新しい行を挿入する代わりに、事前に読み込まれたデータを扱います。 def test_case_2(): print("Test Case 2:") print("Get top 3 Must Read book awards for year 2021 in the Sci-Fi category") print("\n") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #cache-hit - get awards from cache print("\n") print("Verify cache hit on subsequent query with same parameters:") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #let the cache entry expire print("\n") print("Waiting for cached entry to expire, sleeping for 300 seconds...") time.sleep(300) #cache miss - get award from DB and lazy load to cache print("\n") print("Entry expired in cache, awards expected to be fetched from DB.") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #cache hit - get award from cache print("\n") print("Verify that awards are lazy loaded into cache:") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) 遅延ロードとキャッシングのワークフローの動作を確認できます。 最初の呼び出しではキャッシュに結果が見つからないため、キャッシュの基盤となる Amazon Keyspaces テーブルからデータを取得し、キャッシュにロードします。 2 回目の呼び出しでは、キャッシュから結果を取得します。 キャッシュされた結果が期限切れになると、データベースから結果を再度取得し、キャッシュに遅延ロードされます。これにより、同じパラメータでの後続の get_awards 呼び出しでキャッシュからの高速な取得が可能になります。 キャッシュからのデータ取得では 1 ミリ秒未満の往復時間が、データベースへの往復ではミリ秒単位の往復時間が観察できます。 Test Case 2: Get top 3 Must Read book awards for year 2021 in the Sci-Fi category Fetched from Cache: [] Fetched from Database in: 21.03400230407715 ms [Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')] Verify cache hit on subsequent query with same parameters: Fetched from Cache: 0.36835670471191406 ms ["[Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')]"] Waiting for cached entry to expire, sleeping for 300 seconds... Entry expired in cache, awards expected to be fetched from DB. Fetched from Cache: [] Fetched from Database in: 32.64594078063965 ms [Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')] Verify that awards are lazy loaded into cache: Fetched from Cache: 0.3757476806640625 ms ["[Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')]"] スクリプト例 サンプルスクリプトとテスト関数は、この GitHub リポジトリ で確認できます。 検討事項 この投稿では、ブックアワードのデータに対する 2 つの最も一般的なアクセスパターンの結果をキャッシュする基本的な実装を紹介します。 アクセスパターンの性質に応じて、他にもデータをキャッシュする方法があります： パーティションキーの値のみに基づいて結果をキャッシュ（クライアント側でフィルタリング） – アプリケーションですべてのリクエストパラメータを処理する代わりに、パーティションキーの列のみ（例えば、賞と年）に基づいて結果セットをキャッシュすることができます。その他のフィルタリングはすべてクライアント側で処理されます。これは、異なるクエリ間で、このパーティションキー値を持つ少数の行のみを結果セットから除外する必要がある場合に有用です。結果セットを一度だけキャッシュし、クライアント側で異なるクラスタリング列の値やフィルタ条件を処理します。 すべてのキーパラメータを順序付け（例：昇順）してハッシュ化 – ハッシュ値をキャッシュ結果のキーとして使用できます。同じキーパラメータを使用して同じ結果が要求された場合、ハッシュは一貫性を保ち、キャッシュは必要な結果セットを返します。このオプションは、クエリが動的で、クエリ間でキー条件の順序が異なる場合に役立ちます。 すべてのクエリパラメータ（キー条件とフィルタ）を順序付け（例：昇順）してハッシュ化 – ハッシュ値をキャッシュ結果のキーとして使用できます。同じクエリパラメータが異なる順序で要求された場合でも、ハッシュは一貫性を保ち、キャッシュは必要な結果セットを返します。このオプションは、クエリパラメータとフィルタが動的で、クエリ間でパラメータの順序が異なる場合に役立ちます。 まとめ このブログでは、Amazon Keyspaces にデータを保存し、1 ミリ秒未満の読み取り応答時間が必要な、読み取りの多いコストに敏感なアプリケーションのキャッシュとして Amazon ElastiCache を使用する方法を紹介しました。 Amazon ElastiCache を使用することで、クエリの性質に基づいてカスタムキャッシュ戦略を柔軟に設計できます。 また、適切な TTL 値と共に、独自のキャッシュへのデータ投入とエビクションのロジックを設定することもできます。 詳細については、 ElastiCache クラスターの設計と管理 をご参照ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Juhi Patil は、ロンドンを拠点とする NoSQL スペシャリストソリューションアーキテクトで、ビッグデータテクノロジーのバックグラウンドを持っています。 現在の役割では、お客様の Amazon Keyspaces および Amazon DynamoDB ベースのソリューションの設計、評価、最適化を支援しています。

この記事は Enhance Ecommerce Visualization with Avataar’s Creator Platform on AWS (記事公開日: 2024 年 7 月 29 日) を翻訳したものです。 ボストン・コンサルティング・グループ の調査によると、2027 年までに e コマースは世界の小売売上の 41% を占めると予測されています。オンライン販売は、物理的な接触なしで品質保証が必要となるため、オフライン販売とは大きく異なります。Wyzowl の 2024 年ビデオマーケティング統計 によると、82% の購買者がブランドのビデオを見た直後に購入しており、87% がビデオの品質がブランドへの信頼に影響すると述べています。人間の脳は視覚的に魅力的な情報に報酬を与えるため、可視化が顧客の信頼を得る鍵となります。 AWS パートナーである Avataar は、この知見に基づき、AI を使用して写実的な製品コンテンツを生成することでブランドを支援し、オンラインショッピング体験を再定義しています。Avataar は Amazon Bedrock と Amazon Elastic Compute Cloud (EC2) を活用した Creator Platform を提供しています。この Creator Platform は、その可視化機能によりショッピング体験を向上させ、顧客の想像力と注意を捉えます。結果として、これは顧客エンゲージメントを高め、その後のアクションを促進します。インドの自動車製造会社である Bajaj は、Avataar のインタラクティブな仮想製品ショールームを実装することでこれらの利点を経験しました。同社はオンラインでの試乗予約の成約率が 9% に達し、平均エンゲージメント時間が 3 倍に増加したことを確認しています。 Avataar のプラットフォームで e コマース体験を再構築 Avataar の技術の中核にあるのは、生成 AI とコンピュータービジョンアルゴリズムの組み合わせです。これらのアルゴリズムは、従来の製品写真や 3D レンダリングソフトウェアソリューションの制約に縛られない、実生活に即した製品可視化体験を生成するように設計されています。Avataar は、シルエット写真や製品の特定の側面を詳細に表現するクローズアップショットを含む、魅力的な製品画像を生成するためにデータセットを訓練しました。 このプラットフォームは、テキストプロンプトからライフスタイル画像も生成できます。 Avataar の Creator workspace に 3D モデルを追加し、この製品が実際の環境でどのように見えるかをテキストプロンプトで説明するだけです。あとは、AI ソリューションが驚くべき結果を生み出してくれます。以下の画像で見られるように、左の画像は理想的な環境を従来の写真撮影で表現したものです。これはコストと時間がかかるアプローチで、市場投入までの時間が長くなります。 Avataar の Creator platform を使用すると、ブランドは製品のデジタルツインを使用し、AI にテキストプロンプトを提供することで理想的な背景を作成できます。AI 背景生成機能により、ブランドはコスト効率良く、ターゲット層に合わせた様々な設定を検証できます。 従来の画像 vs. Avataar の生成画像 さらに、このプラットフォームは 3D カタログ用の空間動画を生成するためのユーザーフレンドリーなフレームワークを提供しています。Avataar はテンプレート化されたアプローチを通じて小売業者にスケーラビリティを提供します。カテゴリーごとにひとつのテンプレートを作成し、動画内の 3D モデルを簡単に置き換えることで、カタログ全体の動画を生成できます。 さらに驚くべきことは何でしょうか？これらすべてが、Avataar の生成 AI 技術を活用したコンテンツ制作システムによって実現され、同時にコンテンツ制作費を最大 40% 削減することが可能ということです。 Avataar は、小売業者が様々な販売プラットフォームに対応できるよう、必要とされるフォーマットとアスペクト比で出力を統合する機能も提供しています。このシームレスな統合により、チームの手作業の労力が削減され、市場投入までの時間が短縮されます。 AWS は Avataar の e コマース向けビジュアル探索をどのように支えているか Avataar の技術は、没入型でリアルなビジュアルショッピング体験を創造するために、3D コンピュータービジョン、生成 AI 、ニューラルレンダリングの最先端の研究を適用しています。AWS は、Avataar の高負荷な処理要求に対応できる強力なクラウドコンピューティング基盤を提供しています。AI アルゴリズムの実行をサポートするために必要なスケーラビリティ、信頼性、パフォーマンスを AWS が提供することで、Avataar の AI システムと人間が協力し、大規模に空間コンテンツを提供できます。さらに、AWS のグローバルインフラストラクチャは、最小限の遅延で最適なコンテンツ配信をサポートし、世界中の顧客のユーザー体験を向上させています。 AWS ParallelCluster 、 Amazon CloudFront 、 Elastic Load Balancing などの AWS サービスを使用することで、Avataar は効率的に運用するだけでなく、e コマース環境の需要の変化に応じてシームレスにスケールアップできます。Avataar を使用することで、小売業者は顧客を魅了し、コンバージョンを促進する 3D 対応の製品ストーリーを作成できます。例えば Samsung は、Avataar と協力してバナーページに 没入型コンテンツを採用 し、プレミアム製品のソーシャルコンバージョンとエンゲージメントを 10 倍に増加させました。 ステップ バイ ステップ：Avataar の Creator platform を使用した可視化 Avataar のセルフサービス型 Creator platform は、ユーザーが簡単かつ効率的に非常にリアルな製品ビジュアルを作成できるようにします。以下のステップに従って始めましょう： ステップ 1 ：Creator へのアクセス。 Avataar Creator platform には3つの方法でアクセスできます： 1) 公開リンクを使用して メールアドレスでログイン する。 2) AWS Marketplace — 製品ストーリーテリングのための生成 AI にアクセスする。 3) Avataar または Avataar を使用している同僚から受け取った招待メールのリンクを使用する。 ステップ 2 ：プロジェクトの作成と設定。 プラットフォームにログインしたら、「プロジェクト」タブからプロジェクト名とカテゴリーを指定して、新しいプロジェクトを開始できます。3D オブジェクトファイルをアップロードし、オブジェクトに関連する詳細情報を追加します。キャンバス上でオブジェクトをプレビューし、送信してアップロードを完了します。 ステップ 3 ：レンダリング品質の向上とアニメーションの設定。 Avataar の Creator platform 独自の機能として、強化されたレンダラーがあります。トグルを有効にするだけで、非常に写実的な設定でオブジェクトを可視化できます。必要に応じて、さらに詳細を追加するために照明設定とノイズレベルを調整できます。動画の場合、画像、クリップ、テキストをインポートし、これらをそれぞれアニメーション化する柔軟性があります。 ステップ 4 ： AI 背景生成機能の使用。 オブジェクトのカメラアングルを設定し、AI 背景生成機能を使用します。希望するライフスタイル背景をテキストで入力し、生成された複数の背景オプションから選択して、トレイに追加します。 ステップ 5 ：レンダリングされた画像と動画のエクスポート。 画像や動画をエクスポートするには、「エクスポート」をクリックし、出力タイプを選択します。画像の場合、同じカテゴリーの製品に対して再度アングルを手動で選択する手間を省くために、テンプレートを保存することもできます。 ステップ 6 ：コンテンツの作成。 Avataar のクリエイターにログインし、魅力的な画像や動画の作成を始めましょう。このコンテンツを使用して、e コマースリスティングのエンゲージメントとコンバージョンの向上を促進しましょう。 e コマースの多次元的な未来 AWS を活用した Avataar の Creator platform を通じて、ブランドは大規模に写実的な画像を提供し、市場投入までの時間を短縮し、商品リストを向上させることができます。小売業界が進化するにつれ、顧客の信頼とロイヤリティを獲得し、維持するために、製品の可視化がより重要になっています。Avataar の空間体験により、小売業者やブランドは従来のストーリーテリングの物理的限界を超え、e コマースビジネスの未来に備えることができます。 関連記事へのリンク Scaling product visualization and storytelling in retail with Avataar’s GenAI Spatial storytelling across industries: Applications in retail and beyond The inner circle Q&A: Jane Rawnsley, Senior Vice President, Creative, Avataar AWE panel: Rendering believable 3D assets for ecommerce Avataar’s Creator platform documentation Avataar in AWS Marketplace 著者について Pratishtha Gupta Pratishtha は、Avataar でカスタマーサクセスを先導し、米国と中東全域の重要な企業および中堅市場のアカウントを管理しています。10 年以上にわたる卓越したキャリアの中で、彼女はデータ駆動型のアプローチを用いて、クライアントとの強固なパートナーシップを育成し、自身の製品に大きな成長をもたらしています。 Akanksha Tripathi Akanksha は、小売業者やブランド向けの AI を活用したコンテンツ制作プラットフォームである Avataar で、GTM（Go-to-Market）パートナーシップを率いています。彼女の役割では、強固なパートナーシップエコシステムを育成・管理し、AWS などの戦略的パートナーとのビジネス成長と共同イノベーション イニシアチブ を推進しています。 Santanu Chattopadhyay Santanu Chattopadhyay は、小売・消費財業界ソリューションを担当する AWS APJ（アジア太平洋地域）パートナーテクノロジーリーダーです。彼は、最先端の AWS サービスを使用して小売・消費財業界のソリューションを構築および強化するために、APJ 全域のパートナーと協力しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。 原文 はこちら。

本記事は、2024/03/28 に公開された Sync users and groups from Okta with Amazon QuickSight を翻訳したものです。 注：2023年8月現在、Amazon QuickSight は AWS IAM Identity Center 対応アプリケーションとなっています。この機能により、QuickSight をサブスクライブしている管理者は、IAM Identity Center を使用して、ユーザーがOkta やその他の外部 ID プロバイダでログインできるようになります。詳細については、QuickSight ドキュメントの「 Simplify business intelligence identity management with Amazon QuickSight and IAM Identity Center (AWS blog post)」および「 Configure your Amazon QuickSight account with IAM Identity Center 」を参照してください。この新しいインテグレーションを使用することをお勧めします。このブログ投稿は、既存のアカウント構成の参考として提供されています。 Amazon QuickSight は、クラウドベースでサーバーレスかつ組み込み可能なビジネスインテリジェンス（BI）サービスです。QuickSight は完全に管理されたサービスとして、インタラクティブなダッシュボードを作成、公開することができ、あらゆるデバイスからアクセスしたり、アプリケーション、ポータルおよびウェブサイトに埋め込むことができます。 QuickSight は、Standard Edition と Enterprise Edition の両方で、Security Assertion Markup Language 2.0 (SAML 2.0) による ID フェデレーションをサポートしています。フェデレーションを使用すると、企業の ID プロバイダー（IdP）を使用してユーザーを管理し、ログイン時にそのユーザーを QuickSight に渡すことができます。IdP には、Microsoft Active Directory Federation Services、Ping One Federation Server、Okta などがあります。 本稿執筆時点では、QuickSight はエンタープライズグレードの認証メカニズムとして、フェデレーテッド・シングル・サインオン（SSO）と Active Directory（AD）のインテグレーションをサポートしています。後者では、役割の割り当てとコンテンツの認可のために、ネイティブの AD グループをシームレスに同期することができます。しかし、SAML を使用して連携 SSO を行う場合、適切なロールでユーザを自動的にプロビジョニングすることもできます。現在、このインテグレーションは、IdP と QuickSight 間のグループとユーザーまたはグループのメンバーシップを自動的に同期させてはいますが、その同期を遅延させています。これは、自動的にプロビジョニングされたユーザーに対して、アセットへの適切なアクセスを許可し、権限を付与するために重要です。 主な課題は以下の 3 つです。 サードパーティ IdP からのユーザーとグループの自動同期 ユーザーのグループへの自動割り当て ユーザーとグループが IdP から削除された場合の QuickSight からのデプロビジョニング この投稿では、スケーラブルな方法でこれらの課題を克服するための手順とコードサンプルを提供します。Okta を使用したソリューションを示しますが、他の IdP を使用することもできます。これは実績のあるソリューションで、QuickSight の複数のお客様で使用され、実装されています。 ソリューション概要 このソリューションでは、QuickSight と以下の AWS サービスを使用して、ユーザー、グループ、およびそれらのメンバーシップを IdP から自動的に同期します。この場合、IdP は唯一の信頼できるソースとして機能します。 AWS Lambda はサーバーレス、イベント駆動型のコンピュートサービスで、サーバーのプロビジョニングや管理を行うことなく、事実上あらゆるタイプのアプリケーションやバックエンド・サービスのコードを実行できます。200 以上の AWS サービスや SaaS（Software as a Service）アプリケーションから Lambda をトリガーすることができ、使用した分だけ料金を支払うようになっています。 AWS Step Functions は、開発者が AWS サービスを使用して分散アプリケーションを構築し、プロセスを自動化し、マイクロサービスをオーケストレーションし、データと機械学習（ML）パイプラインを作成するのを支援するビジュアルワークフローサービスです。 Amazon EventBridge は、イベントを使用してアプリケーション・コンポーネントを接続するサーバーレス・サービスで、スケーラブルなイベント駆動型アプリケーションを簡単に構築できる。イベントにマッチするルールを作成し、1 つまたは複数のターゲット関数またはストリームにルーティングできます。 AWS Identity and Access Management （IAM）は、ユーザーの AWS リソースへのアクセスを安全に制御するのに役立ちます。IAM を使用して、誰が AWS リソースを使用できるか（認証）、どのリソースを使用できるか、どのように使用できるか（認可）を制御できます。詳細については、 IAM ユーザーガイド を参照してください。 次の図は、サードパーティの IdP からユーザーとグループの同期を実行するワークフローを示しています。 このソリューションは、オンデマンド・モードでもスケジュール・モードでも実装できます。どちらの場合でも、このソリューションが最初に行うのは、一連の Lambda 関数の実行をオーケストレーションする Step Functions ワークフロー（ Okta-QuickSight-Sync ）のトリガーです。 QuickSight-Okta-Group-Sync – QuickSight 間でグループを同期します。 QuickSight-Okta-User-Sync – ユーザーとそのグループ・メンバーシップを作成します。 QuickSight-Okta-User-Deprovisioning – QuickSight ユーザーを削除し、行き場のなくなったアセットを QuickSight の専用管理ユーザーに転送します。 以下のセクションでは、AWS CloudFormation を使用してソリューションリソースを構成する手順を説明します。まず、CloudFormation スタックに必要なパラメータを取得する必要があります。 OKTAAPIToken OKTADomain OKTAQuickSighAPPId QuickSightAdminUserName QuickSightAdminIAMRole QuickSightAuthorIAMRole QuickSightReaderIAMRole 前提条件 以下の前提条件が必要です。 QuickSight アカウントのサブスクリプション QuickSight へのフェデレーションが有効な Okta サブスクリプション AWS アカウントの管理者権限 （訳者注）本ソリューションを手順に従って試す場合、QuickSight アカウント作成および CloudFormation の実行は バージニア北部（us-east-1）リージョン で行ってください。 IdP から OKTAAPIToken を取得し、Lambda から API コールを行う まず、CloudFormation スタックのパラメーターとして使う API トークンを作成します。 以下のステップを完了します。 管理者アカウントでOktaドメインにログインします。 ナビゲーションペインの Security で API を選択します。 Tokens タブで、Create token を選択します。 トークン名（例：Okta API token for QuickSight user and group Sync）を入力し、 Create token を選択します。 Okta がトークン値を生成します。 トークン値をコピーし、後のステップで使用するために保存します。 OK, got it を選択し、モーダルウィンドウを閉じます。 Okta は以下のように Token Value を生成します。 トークンの詳細は API ページに記載されています。詳細には、トークンの作成日、有効期限、最終使用日のタイムスタンプが含まれます。 API トークンの有効期限は Okta のアカウント構成によって異なります。トークンの有効期限切れにより Lambda コードが失敗した場合は、新しいトークンを生成し、Lambda 設定で更新してください。 IdP の OKTADomain を取得する Oktaドメイン名を検索する には、次の手順を実行します。 管理者アカウントで Okta 組織にサインインします。 ダッシュボードの右上にあるグローバルヘッダで Okta ドメインを探します。 ドメイン URL 全体をコピーし、後のステップで使用するためにこれを保存します。 Okta に設定されている QuickSight アプリケーションの OKTAQuickSighAPPId を取得する アプリケーションIDを取得するには、以下の手順に従ってください。 管理者アカウントで Okta 組織にサインインします。 ナビゲーションペインの Applications で Applications を選択します。 QuickSight アプリケーションを選択します。 ブラウザの URL に表示されているアプリケーション ID をコピーし、後の手順で使用するために保存します。 QuickSightAdminUserName を取得し、アセットを管理ユーザーに転送する admin または author ロールを持つユーザをデプロビジョニングする際、アセットの所有権を移行するために、この admin ユーザを使用します。以下の手順を実行してください。 管理者権限で QuickSight アカウントにサインインします。 ユーザ・プロファイル・アイコンを選択し、 QuickSightを管理 を選択します。 ユーザーを管理 にある管理者ユーザー名（この記事では OktaSSOUser を使用）をコピーし、後のステップで使用するために、これをメモします。 QuickSight IAM ロールを作成する Amazon QuickSightへのアクセスをOktaでフェデレートする （ 日本語訳 ）ブログポストの手順に従って、IAMロールを設定します。 管理者 : QuickSightOktaAdminRole 作成者 : QuickSightOktaAuthorRole リーダー : QuickSightOktaReaderRole （訳者注ここから） 各ロールには以下のようなポリシーを設定してください。ポリシーの内容は適宜変更してもかまいません。 管理者 （ポリシー名は、必ず QuickSightOktaCreateAdminPolicy とし、 QuickSightOktaAdminRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateAdmin", "Resource": "*" } ] } 作成者 （ポリシー名は、必ず QuickSightOktaCreateAuthorPolicy とし、 QuickSightOktaAuthorRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateUser", "Resource": "*" } ] } リーダー （ポリシー名は、必ず QuickSightOktaCreateReaderPolicy とし、 QuickSightOktaReaderRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateReader", "Resource": "*" } ] } （訳者注ここまで） このソリューションでは、ユーザー登録のための AWS Lambda コードは上記の IAM ロールを使用します。IAM ロールの命名は正確に保つようにしてください。デプロイしたら、IAM ロールをカスタムロールで更新してください。 これで CloudFormation テンプレートに必要なパラメータが揃いました。 AWS CloudFormation でリソースを作成する Launch Stack を選択してリソースをプロビジョニングします （訳者注）CloudFormation を実行するリージョンは バージニア北部 (us-east-1) に設定してください。 スタックの作成 のページで、 次へ を選択します。 前のステップで取得したパラメータを入力し、 次へ 選択します。 入力項目を確認し、 送信 を選択します。 CloudFormation が正常にデプロイされると、すべてのリソースがそれぞれのアカウントにデプロイされます。 EventBridgeルールを有効にする デプロイされたリソースの一部として、EventBridge ルールが作成されます。スクリプトの偶発的な実行を避けるため、デフォルトでは無効になっています。このルールは、毎日 12:00 UTC にトリガされるように設定されています。 次の手順を実行して、ルールを有効にします。 EventBridge コンソールで、ナビゲーション ペインの バス の下にある ルール を選択します。 ルールリストで、CloudFormation テンプレートで作成したルール（ OktaQSSyncEventsRule ）を選択します。 UTC 12:00　からの既存のルール設定を編集して独自のスケジュールを設定するには、 イベントパターン セクションで 編集 を選択します。 ルールを有効にするには、 有効化 を選択します。 ルールを有効にすると、Step Functions ワークフローの実行がトリガーされ、Okta から QuickSight へのユーザーとグループの自動同期が開始されます。 留意点 Okta ドメイン、Okta アプリケーション ID、API キー、および Okta の QuickSight アプリケーションに割り当てられた QuickSight 専用の管理者、ユーザー、グループは、QuickSight で同期される唯一のグループです。Okta のすべてのユーザーとグループが同期されるわけではありません。 QuickSight からユーザーをデプロビジョニングまたは削除する場合、行き場のなくなったアセットの所有権は、QuickSight-Okta-User-Deprovisioning Lambda 関数の環境変数で設定された専用管理ユーザーに移行されます。 クリーンアップ クリーンアップするには、CloudFormation スタックを削除して、作成したすべてのリソースをデプロビジョニングします。これにより、3 つの Lambda 関数と関連するロールとポリシー、Step Functions ワークフローと関連するロール、EventBridge ルールと関連するロールが削除されます。 まとめ この投稿では、Okta と QuickSight 間のユーザーとグループの自動同期を設定する手順を説明しました。このソリューションにより、QuickSight からグループとそのメンバーシップを手動で管理する必要がなくなり、Okta からユーザが削除された際にQuickSight からユーザをデプロビジョニングする必要がなくなります。 ご質問やご意見がございましたら、コメントをお寄せください。 その他のディスカッションや質問への回答については、 QuickSight Community をご覧ください。

AWS Deadline Cloud は、Amazon Web Services (AWS) から提供されるフルマネージドサービスで、スケーラブルなフルマネージドのビジュアルコンピューティングファームを数分で起動できます。Blender、Houdini、Maya、Nuke などのデジタルコンテンツ制作 (DCC) アプリケーションのレンダリングジョブは、Deadline Cloud Service-Managed Fleets (SMF) を使用することで、迅速かつターンキーで実行できます。これらのアプリケーションは、SMF 環境のワーカー用に conda パッケージ としてサービスに含まれています。しかし、異なるバージョンの DCC を実行したり、サードパーティ製のプラグインを使用したり、パイプラインコードをカスタマイズしている場合はどうすればよいでしょうか。 このブログ記事では、独自の conda パッケージを作成し、 Amazon S3 バケットに conda チャネルをホストして、そのパッケージを Deadline Cloud のレンダーワーカーが利用できるようにする方法を説明します。アプリケーション全体をバンドルして依存関係なく実行可能なパッケージを作成したり、 conda-forge コミュニティによって維持・ホストされている数千のパッケージを元に作成することができます。カスタム conda パッケージとチャネルを利用できるので、Deadline Cloud のパイプラインを拡張し、事実上あらゆるクリエイティブ ツールをサポートすることができます。 このブログ記事の手順に従って、公式のアップストリームバイナリビルドから Blender 4.1 conda パッケージをビルドするために Deadline Cloud キューを使用し、新しいカスタム conda チャネルを使って Blender 4.1 を見つけるようにプロダクションキューを構成し、ファームで Blender のデモシーンをレンダリングします。 パッケージビルドのアーキテクチャ 図 1: 本記事で作成するパッケージビルドキューと通常 Deadline Cloud レンダリングジョブが実行されるプロダクションキューの関係を示しています。 このブログ記事で展開されるアーキテクチャは、conda パッケージビルドジョブ専用の新しいパッケージビルドキューをファームに追加します。 このアーキテクチャの主な特徴は次のとおりです: プロダクションキューは、S3 バケットの /Conda プレフィックスに対する読み取り権を持つため、カスタムの conda パッケージを使用することはできますが、変更することはできません。 パッケージビルドキューは、S3 バケットの /Conda プレフィックスに対する読み取り/書き込み権を持つため、新しくビルドされたパッケージをアップロードし、conda チャネルのインデックスを再作成することができます。 パッケージビルドキューは、S3 バケット内に別のジョブアタッチメントプレフィックスを持つため、そのデータはプロダクションデータから分離されています。 パッケージビルドジョブは、プロダクションキュー用に既に作成したフリートを使用するため、管理が必要な個別のインフラストラクチャコンポーネントの数を減らすことができます。 前提条件 このチュートリアルでは、以下が条件を満たしている必要があります。 AWS アカウント を持っていること Git がインストールされていること AWS Deadline Cloud 用に Deadline Cloud CLI がインストールされていること Deadline Cloud が AWS アカウントにセットアップされており、少なくとも 1 つのキューとフリートがあること 詳細については、 Deadline Cloud の開始方法 のドキュメントを参照してください。 カスタム conda パッケージ用のキューの権限設定 conda パッケージをローカルでビルドすることはできますが、このブログ記事では AWS Deadline Cloud でパッケージをビルドします。これにより、完成したパッケージを conda チャネルとして使用する Amazon S3 バケットに簡単に配信でき、自身のコンピューティングリソースでのビルドに必要な依存関係を減らすことができ、コンピュータをビルドプロセスで拘束することなく複数のパッケージをビルドできます。 AWS Deadline Cloud のカスタム conda チャネルには、Amazon S3 バケットが必要です。新しいバケットを作成するか、既存のキューの 1 つから S3 バケットを再利用できます。Deadline Cloud の目的のキューのキュー詳細ページのジョブアタッチメントファイルタブで、キューの S3 バケット情報を確認できます。 図2: “default-queue-s3-bucket” という名前のジョブアタッチメントバケットを持つ “Production Queue” のキュー詳細ページの例。   ジョブアタッチメントファイルタブには、現在設定されているバケットが表示されます。また、ジョブアタッチメントバケットの上にある “Awsdeadlinecloudqueuerole” というキューサービスロールにも注目してください。バケット名とキューのロール名は異なります。 プロダクションキューを設定するには、キューの詳細ページにあるバケット名とキューサービスロールの両方が必要です。ゴールは、プロダクションキューに S3 バケットの新しい /Conda プレフィックスへの読み取り権を与え、パッケージビルドキューには読み取り/書き込み権を与えることです。ロールのアクセス権を編集するには、このページのキューサービスロールをクリックします。これにより、そのロールの AWS Identity and Access Management (IAM) ページに直接移動します。 キューサービスロールを表示するときは、 [+] を選択してポリシー名が AWSDeadlineCloudQueuePolicy で始まるポリシーを展開し、[編集] を選択してください。 デフォルトでは、このキューロールは、 最小権限の原則 に従い、AWS アカウント内の 特定のリソースへのアクセスのみ に制限されているため、権限は限られた数しか表示されません。ビジュアルエディタまたは JSON エディタを使用して、次の例のような新しいセクションを追加できます。オレンジ色で強調されているバケット名とアカウント番号は、ご自身のものに置き換えてください。ポリシーへの新しい追加は、バケットと新しい /Conda プレフィックスの両方に対して、 s3:GetObject と s3:ListBucket の権限を許可する必要があります。 { "Effect": "Allow", "Sid": "CustomCondaChannelReadOnly", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3::: default-queue-s3-bucket ", "arn:aws:s3::: default-queue-s3-bucket /Conda/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": " 111122223333 " } } }, パッケージビルドキューの作成 次に、conda チャネル用の特定の conda パッケージをビルドするジョブを送信する、新しいパッケージビルドキューを作成します。Deadline Cloud コンソールのファームページから、キューの作成を選択します。 S3 バケットは、プロダクションキューと同じバケットを使用するか、新しいバケットを作成します。通常の Deadline Cloud のジョブアタッチメントファイルとは別に保管するため、 /DeadlineCloudPackageBuild などの新しいプレフィックスを作成することをお勧めします。フリートの関連付けについては、既存のフリートを使用することもできますし、現在のフリートが適さない場合は、完全に新しいフリートを作成することもできます。 キューサービスロールについては、新しいキューサービスロールを作成して使用することをお勧めします。このロールを設定すると、指定した S3 バケットとプレフィックスに対する読み取り/書き込み権が自動的に付与されます。 パッケージビルドキューの権限設定 先程プロダクションキューのロールを変更したのと同様に、パッケージビルドキューのロールを変更して、 /Conda プレフィックスへの読み取り/書き込み権を与える必要があります。 パッケージビルドキューの詳細ページから、キューサービスロールをクリックし、 [+] をクリックしてから [編集] をクリックします。この一連の権限は読み取り/書き込みする必要があるため、ポリシーの追加には、デフォルトのキュー宛先で使用される 4 つの権限 ( s3:GetObject 、 s3:PutObject 、 s3:ListBucket 、 s3:GetBucketLocation ) に加えて、 s3:DeleteObject によるオブジェクトの削除機能が含まれています。これらの権限は、パッケージビルドジョブが新しいパッケージをアップロードしてチャネルをインデックスを再作成するために必要です。オレンジ色で強調表示されているバケット名とアカウント番号は、ご自身のものに置き換えてください。 { "Effect": "Allow", "Sid": "CustomCondaChannelReadWrite", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3::: default-queue-s3-bucket ", "arn:aws:s3::: default-queue-s3-bucket /Conda/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": " 111122223333 " } } }, Blender 4.1 パッケージのビルド 以下の手順では、bash 互換のシェルから git を 使用して、 Deadline Cloud Samples GitHub から Open Job Description (OpenJD) パッケージのビルドジョブと、 conda レシピを取得します。Windows の git インストールには、 git BASH と呼ばれる bash のバージョンが含まれており、これを使用できます。また、 Deadline Cloud CLI をインストールし、 Deadline Cloud monitor にログインするか、別の AWS 認証方式を使用する必要があります。最後のステップは、Deadline Cloud CLI を使用してそれらの OpenJD ジョブバンドルをキューに送信することです。 bash 互換のシェルで deadline config gui を実行し、構成 GUI を開いて、デフォルトのファームとキューを作成したパッケージビルドキューに設定してください。 git clone で Deadline Cloud サンプル GitHub リポジトリをクローンし、 conda_recipes ディレクトリ に切り替えると、 submit-package-job というスクリプトが見つかります。このスクリプトを初めて実行すると、次の例のように Blender をダウンロードする手順が表示されます。手順に従ってダウンロードが完了したら、ジョブを再度実行してサブミッションを作成してください。 $> deadline config gui $> git clone https://github.com/aws-deadline/deadline-cloud-samples.git $> cd deadline-cloud-samples/conda_recipes $> ./submit-package-job --recipe blender-4.1/ No S3 channel provided, using job attachments bucket default ERROR: File blender-4.1/blender-4.1.1-linux-x64.tar.xz not found. To submit the blender-4.1 package build, you need the archive blender-4.1.1-linux-x64.tar.xz To acquire this archive, follow these instructions... $> ./submit-package-job --recipe blender-4.1/ No S3 channel provided, using job attachments bucket default Building package into conda channel s3://default-queue-s3-bucket/Conda/Default + deadline bundle submit build_linux_package -p RecipeName=blender-4.1 -p OverrideSourceArchive=blender-4.1/blender-4.1.1-linux-x64.tar.xz -p RecipeDir=blender-4 .1/blender-4.1 -p 'S3CondaChannel=s3://default-queue-s3-bucket/Conda/Default' -p CondaChannels= Submitting to Queue: Package Build Queue ... Job creation completed successfully Deadline Cloud monitor を使用して、ジョブの実行中の進行状況とステータスを確認します。デフォルトの 2 vCPU、8 GiB RAM のインスタンスサイズ仕様では、パッケージのビルド、S3 バケットへのアップロード、チャネルの再インデックスに 22 分かかりました。デフォルトのフリート設定は conda パッケージのビルドとレンダリングには比較的小さいため、設定を増やすことをお勧めします。 図3. パッケージビルドジョブがハイライトされた Deadline Cloud monitor Deadline Cloud monitor の左下には、ジョブの 2 つのステップ (パッケージのビルドとインデックスの再作成) が表示されています。右下には、各ステップの個々のタスクが表示されています。この例では、各ステップに 1 つのだけタスクがあります。 パッケージビルドのステップのタスクを右クリックし、[ログを表示] を選択します。右側に、セッション操作のリストが表示され、ワーカーホストでタスクがどのようにスケジュールされるかを示すます。セッション操作は次のとおりです。 アタッチメントファイルの同期 : この操作は、ジョブのアタッチメントファイルシステムの設定に応じて、入力ジョブのアタッチメントファイルデータをコピーするか、仮想ファイルシステムをマウントします。 Conda の起動 : この操作は、Deadline Cloud コンソールのオンボーディングフローがデフォルトで追加する OpenJD キュー環境 のものです。ジョブは conda パッケージを指定しないため、すぐに終了し、conda 仮想環境は作成されません。 CondaBuild 環境の起動 : この操作は、conda パッケージのビルドと conda チャネルのインデックスの再作成に必要なソフトウェアを含む、カスタマイズされた conda 仮想環境を作成します。 conda-forge チャネルからインストールします。 タスクの実行 : この操作は、Blender パッケージのビルドを実行し、作成されたパッケージを S3 にアップロードします。 図 4. Deadline Cloud monitor のログビューアー ログは構造化された形式で Amazon Cloudwatch 内に保存されています。ジョブが完了した後、「すべてのタスクのログを表示」をチェックすると、ジョブが実行された環境のセットアップとティアダウンに関する追加のログを表示できます。 パッケージビルドジョブがどのように実装されているのか気になる方は、 ソースコード をご確認ください。たとえば、チャネルのインデックスを再作成するステップには、一度に 1 つのパッケージビルドジョブのみがインデックスの再作成を実行できるようにする相互排他があります。これは OpenJD 環境として実装されており、 Amazon S3 の強い整合性 を使用して、追加のインフラストラクチャを必要とせずに正しい実装されています。 プロダクションキュー環境にconda チャネルを追加 S3 conda チャネルと Blender 4.1 パッケージを使用するには、Deadline Cloud に送信するジョブの CondaChannels パラメータに s3:///Conda/Default チャネル場所を追加する必要があります。構築済みの Deadline Cloud サブミッターには、カスタム conda チャネルと conda パッケージを指定できるフィールドが用意されています。 プロダクションキューの conda キュー環境を少し変更するだけで、すべてのジョブを変更する必要がなくなります。Deadline Cloud コンソールを開き、プロダクションキューのキュー環境タブに移動します。リストの「Conda」キュー環境のチェックボックスを有効にし、[編集] を選択します。Costomer-Managed Fleet の場合は、Deadline Cloud samples GitHub にある conda キュー環境サンプル のいずれかを使用して conda パッケージの使用を有効にできます。 CondaChannels パラメータを指定するセクションに、デフォルト値を以下のように設定する行があります: default: "deadline-cloud" この行を編集して、新しく作成した S3 conda チャネルで始めます: default: "s3:///Conda/Default deadline-cloud" Service-Managed Fleets では、デフォルトで conda の strict channel priority が有効になっているため、S3 チャネルに  blender をビルドすると、conda は deadline-cloud チャネルを全く考慮しなくなります。つまり、以前は deadline-cloud チャネルを使用して成功していた blender=3.6 を含むジョブが、Blender 4.1 をビルドした後は失敗するようになります。 Blender 4.1 ジョブをプロダクションキューに送信 パッケージがビルドされ、キューがそのチャネルを使用するように設定されたので、いよいよパッケージを使用してレンダリングします。まず、CLI コマンドの  deadline config gui を再度実行し、プロダクションキューを選択して、プロダクションキューに切り替えてください。 まだ Blender のシーンを持っていない場合は、 Blender のデモファイル ページに移動し、ダウンロードするファイルを選択します。私たちは、 Blender Splash Artwork セクション にある  Nicole Morena 氏が作成し、CC-BY-SA ライセンスの下でリリースされた Blender 3.5 – Cozy Kitchen シーンファイルを選択しました。ダウンロードすると  blender-3.5-splash.blend というファイルが含まれており、クイックスタートのオンボーディングフリートでも簡単にレンダリングできます。他のシーンをレンダリングする場合は、Deadline Cloud コンソールからフリート設定値を増やす必要があるかもしれません。 Deadline Cloud samples GitHub リポジトリには、次のコマンドを使用して Blender シーンをレンダリングできるサンプルジョブが含まれています。 $> deadline bundle submit blender_render \ -p CondaPackages=blender=4.1 \ -p BlenderSceneFile=/path/to/downloaded/blender-3.5-splash.blend \ -p Frames=1 Submitting to Queue: Production Queue ... Job creation completed successfully Deadline Cloud monitor で、送信したジョブのタスクを選択し、ログを表示するオプションを選択します。ログビューの右側で、「Launch Conda」と呼ばれるセッションアクションを選択します。キューの環境で設定された 2 つの conda チャネルで Blender 4.1 を検索し、S3 チャネルでパッケージを見つかったことがわかります。 ジョブが完了したら、 出力をダウンロード して結果を確認できます。 クリーンアップ キューからフリートの関連付けを解除したあと、キューを削除してください。 /Conda プレフィックスを削除するには、AWS コンソールで S3 バケットに移動し、バケットを開き、 /Conda プレフィックスを選択し、「削除」を選択して、指示に従ってください。 OS の通常の削除手順を実行して、ダウンロードしたファイルや git クローンしたファイルを削除してください。 IAM ポリシーに追加した権限を削除するには、前述の手順に従って各ポリシーに移動し、追加したセクションを削除してください。 まとめ このブログ記事では、キューロールのアクセス権を変更する方法、新しいバージョンのソフトウェア用にカスタム conda パッケージをビルドする方法、プロダクションレンダーキュー用の conda チャネルとして機能する S3 バケットを追加する方法を説明しました。Open Job Description と AWS Deadline Cloud は、さまざまな計算ジョブ、およびレンダリングジョブを処理できるように設計されており、組み込みの SMF サポートと私たちが提供するビルド済みのサブミッターをはるかに超えてパイプラインを拡張できます。提供されている例を参考に、小さなプラグインや Nuke gizmoなどの簡単なものから始めて、今日からあなたの Deadline Cloud ファームの機能をカスタマイズしてみてください。 著者について Mark Wiebe Mark Wiebe is a Principal Engineer at AWS Thinkbox, focused on solutions for creative content. Sean Wallitsch Sean is a Senior Solutions Architect, Visual Computing at AWS. 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの濵野が担当しました。原文は こちら です。

「AWS には興味があるが、何から学習したらいいかわからない」「新卒エンジニアとして、クラウドに関する知見を伸ばしたい」「フルスタックエンジニアを目指して AWS も身につけたい」というお悩みはありませんか？これらのお悩みの一助となるのが、今回紹介させていただくイベント AWS JumpStart 2025 です。 2022 年から始まり毎年開催されている AWS JumpStart ですが、本イベントの内容や 2025 年の開催方針について、このブログでは紹介させていただきます。 AWS JumpStart とは AWS JumpStart は、新卒を含む AWS 初学者のエンジニアを対象とした、クラウドネイティブなテックリード人材を育成するための第一歩となる実践的な研修プログラムです。事前学習用動画と 2 日間の集中的なオンラインワークショップを通して、皆様の AWS に対する理解度を一気に引き上げることを目的としています。 AWS について話を聞いたことはあるが使ったことはない EC2 等の単体サービスは触ったことあるが、システム全体の設計経験はない クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい といった方々には短期間で一気にレベルアップできる内容となっているので、AWS を学びはじめるのにもってこいのプログラムとなっています。 AWS JumpStart 2025 のご案内 今年 2024 年にも開催した JumpStart ですが、1,000 人を超えるエンジニアの皆さまにご参加いただき大変好評でした。翌年の開催要望も多くいただいており、2025 年も全 4 回、各回 2 日間での開催を決定しました！ AWS JumpStart 2025（全てオンラインでの開催です） 開催日時（各回 2 日間：9 – 18 時） 2025 年 3 月 13 日（木）~ 3 月 14 日（金） 2025 年 5 月 27日（火）~ 5 月 28 日（水） 2025 年 8 月 27日（水）~ 8 月 28 日（木） 2025 年 10 月 23日（木）~ 10 月 24 日（金） 参加費 無料 参加登録ページ Coming Soon 2024 年の JumpStartは、新卒 1 年目向けとそれ以外の初学者向けで開催回を分けておりましたが、2025 年は同一イベントとして開催させていただきます。ついていけるか心配という新卒の方もいるかもしれませんが、グループワークはできるだけ近い属性の方と組んでいただけるように計画しております。両参加者にとって今まで以上にスキルアップを実感いただけるような枠組みを目指していきます！ 参加登録方法については、2025 年 1 – 2 月を目処にお知らせいたします。 こちらのブログ内にてアップデートさせていただきますので今しばらくお待ちください。AWS JumpStart 2025 も多くの方々のご参加を心よりお待ちしております！ 事前学習コンテンツ 一方で、AWS を学習するのは初めてで、イベントでついていけるか不安という方もいるかと思います。AWS JumpStart ではイベント開始前に無料の事前学習コンテンツを配布しており、参加者のレベル感の統一を図っております。 本イベントに申し込まれた方に別途ご連絡いたしますが、「早めに内容を確認したい」といった熱心なご意見をしばしばいただくため、以下に事前コンテンツの一例を掲載いたします。 Cloud for Beginners モジュール 0&1（ 動画 ） クラウドの前提となる、Web サービスの基礎や IT 基礎について解説している 40 分ほどの動画です。 AWS Technical Essentials（ URL ） クラウドを初めて学ぶ技術者に向けた、AWS の基本的な概念を包括的に学習できる 4 時間ほどのコンテンツです。 別途 AWS Builder ID アカウントを作成する必要があります。 2024 年開催の様子 AWS JumpStart 2024 も全 2 日、オンラインにて開催しました。受動的な講義コンテンツだけではなく、能動的に皆さんに手を動かしていただけるようなイベントを目指しました。 1 日目 1 日目は、講義形式の座学と実際に手を動かすハンズオンを交互に実施し、知識定着を図りました。座学では事前学習コンテンツの振り返りに加えて、実際に AWS でシステムを構築する際にアーキテクチャで気にするポイントについて解説しました。ハンズオンでは実際に仮想サーバーを起動していただく基礎的な内容からスタートし、最終的に簡単な Web アプリを動かすまでを目指しました。 2 日目における最終成果物 2 日目は、1 日目に学習した内容を踏まえて、実際に AWS アーキテクチャを設計いただきました。とある事業を立ち上げる会社の新入社員として、どのようなアーキテクチャを実装するべきか要件と照らし合わせながら検討しました。ワークは初め個人で検討したのち、5 名前後のチームで議論しました。 2024 年は最終的に以下のようなアーキテクチャ図が作成されました。このイベントを通して、AWS のアーキテクチャ図を読み書きできるようになるのが 1 つの目標です。 参加者からの感想 参加者の皆様からは大変ありがたいことにさまざまなポジティブな感想をいただきました。 自分たちの疑問に思うであろう点をあらかじめ説明してくれ、内容が耳にスッと入ってきた。このプログラムを通じて資格の取得に励んでいきたい。 2日間を通して、AWSのサービスについて少しですが理解することが出来ました。そして、自分の理解の足りなさが分かったので、それぞれのサービスの特徴や他のサービスとの関連などについて勉強をしたいと思いました。 事前学習を含めるとかなり多い時間のオンラインセミナーだったが終始楽しく、眠くなることもなく参加できてよかった。ありがとうございました。 今回で 4 年目の開催となりますが、新卒研修として取り組んでくださっている会社も増えてきております。新卒 1 年目のエンジニア、そして AWS 初学者のエンジニアの方にぜひ受講いただきたい内容を目指しております。 まとめ AWS JumpStart では、事前学習からハンズオン、チームでの検討と発表までのワークショップを通して、AWS の理解とアーキテクチャ設計力を向上できるプログラムを 2 日間のワークショップ形式で用意しています。 運営メンバー一同、より良い内容での JumpStart 2025 をお届けするべく準備を進めておりますので、是非とも参加ご検討ください。

こんにちは。ソリューションアーキテクトの徳永です。2024 年 11 月 15 日に「生成 AI が切り拓く、 今後のエンジニアリング環境」というというテーマで、セミナーをオンラインにて開催いたしました。本ブログでは、イベント内容を簡単にご紹介しつつ、アセット資料を紹介致します。このセミナーでは、生成 AI を活用して実際にエンジニアリング環境の改善を進めている3 社様の先進的な取り組みをご紹介させて頂きました。 リポジトリをまるごと AI でレビューする LongContext モデルを利用したレビューシステムの紹介 合同会社 EXNOA 技術統括本部 技術推進部 高嶋 俊作 様 技術統括本部 情報管理室 小野寺 崇 様 【 資料 】 【 動画 】 EXNOA 様には、 LongContext モデルを活用してソースコードを含むプロジェクトの改善提案を自動生成する取り組みについてご紹介頂きました。ソースコードを ZIP ファイルとして固めてアップロードすると、LLM が選択したレビュー観点に従って、どのファイルに、どのような問題があり、どのように改善すればよいのかをマークダウン形式でフィードバックしてくれます。また、改善のためのコードまで提案されていました。有効な改善提案まで AI が判定して出力するという形になっており、実践的な内容となっていました。例では、 JSON のデコードに関するエラー処理が不足しているなど、見落としやすい箇所に関しての指摘がなされていました。実際にすでに現場でのレビューに利用されており、レビューの初期コストの削減とレビューの精度向上に寄与しています。 LLM は Claude 3.5 Sonnet をメインとし、Gemini 1.5 Pro をサブとして採用されたとのことです。 AWS を採用した理由としては、すでに AWS を利用していたためノウハウがあったことが大きいとのことです。 コードレビューはひとつのプロンプトで行うのではなく、多段構成でレビューを実施していました。最初にレビューファイルのパスを展開し、レビュー対象に対して、レビュー観点ごとに調整したプロンプトを投げる形でレビューをする形です。プロンプトは英語で構成することで精度を高めている点や、 API による呼び出しに対して Exponential Backoff によるリトライ処理を行っている点など、 LLM を扱う上での工夫がみられました。 ペアーズにおける Amazon Bedrock を活用した障害対応支援生成 AI ツールの導入事例 株式会社エウレカ MLOps Engineer 成川 聖 様 【 資料 】 【 動画 】 エウレカ様での障害対応プロセスで LLM を使ったチャットボットを構築した事例をご紹介いただきました。 エウレカ様では、障害対応における属人性の高さや業務の複雑性など様々な課題を軽減するために障害対応報告の自動生成機能を開発されました。エウレカ様では、これまでも ChatOps による障害対応の円滑化を図られてきましたが、さらにコマンド操作だけで障害の内容を要約し、報告書やポストモーテムとしてまとめられるように拡張されています。 この機能は Amazon Bedrock と Claude 3.5 Sonnet を使って実現されており、Amazon Elastic Kubernetes Service (EKS) との統合や、Knowledge Bases for Amazon Bedrock などによる Managed RAG 機能が利用できることが採用理由として挙げられていました。 また、障害対応時に専用の Slack チャンネルを作成してコミュニケーションを集約させており、チャンネル作成時に自動的に Pairs Navi という Chat Bot が参加します。エウレカ様では Knowledge Bases for Amazon Bedrock を活用し 1,500 ページ以上のドキュメントから RAG を構築しており、対応メンバーは Pairs Navi を介して障害対応プロセスをキャッチアップすることができます。 実際に導入してみると、障害対応そのものよりもオンボーディングで利用される割合のほうが高いこと、緊急性の高い業務の中でわざわざ Chat Bot をメンションすることに敷居があることなどが分かったため、より自律的に振る舞う Agent 型への改良を進められているそうです。 生成 AI ソリューションとサイバーエージェントの変化 サイバーエージェント様 System Security 推進 Group (SSG) 開発チーム マネージャ 小笠原 清志 様 【 資料 】 【 動画 】 サイバーエージェント様では AI を活用し様々な生産性の改善に取り組まれており、今回はセキュリティにおける生成 AI 活用事例を紹介していただきました。まず紹介していただいたのが、サイバーエージェントのすべての社員が利用できる、セキュリティ相談ができるチャットツールです。プライバシーやセキュリティを意識した設計となっており、 AI により、いままでよりも気軽にセキュリティの相談ができるようになりました。過去に起票された社内のセキュリティチケットを参照しているため、社内の事情に精通した回答を返すことが可能になっております。ただの RAG アプリケーションではなく、専門性の高いエージェントを複数用意しており、個人情報の相談ができるエージェントなど、ユースケースに沿った形で使えるようになっています。課題解決までのリードタイムが短縮され、社内でも活用が進んでいます。 この取り組みは、サイバーエージェント様の Developers Blog – 生成AIでセキュリティの課題をどこまで改善できるか考える でも紹介されています。あわせてご参照ください。 また、生成 AI を使える人から、生成 AI アプリを作れる人へとステップアップをしてもらうという目的で、 Dify の環境を構築している事例を紹介していただきました。この事例に関しては builders.flash にて詳しく紹介されております。エンジニア不要な業務改善を狙っているとのことでした。 クロージング | 生成 AI が切り拓く、今後のエンジニアリング環境 アマゾンウェブサービス ジャパン 合同会社 ソリューションアーキテクト 徳永 貴大 【 資料 】 【 動画 】 最後に、クロージングとしてソリューションアーキテクトの徳永から Amazon Q Developer と Failure Analysis Assistant の紹介をさせていただきました。Amazon Q Developer ではソフトウェア開発ライフサイクル全般を統合支援するサービスです。コードの推薦や、セキュリティの問題のある箇所をスキャンして、改善提案を受けることができます。 Failure Analysis Assistant は障害対応時のログ解析を LLM にさせて一次対応をさせるためのサンプル実装です。 Slack 上でアラートを受信したのちに、 Slack 上に表示されるフォームに必要な情報をいれることで、自動的にログを収集し、 Bedrock の API を通じて LLM による解析処理を行った後に、障害の原因の分析結果を Slack 上で受け取ることができます。AWS Blog Failure Analysis Assistant – AIOps で障害分析を効率化してみよう – と aws-samples のリポジトリから詳しい情報をご覧いただけますのでご活用ください。 おわりに 本ブログでは 2024 年 11 月 15 日に開催された「 生成 AI が切り拓く、 今後のエンジニアリング環境 」の内容をご紹介させていただきました。本セミナーに参加いただいた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログはソリューションアーキテクト徳永が担当しました。 (Updated : 2024/12/04 日本時間) 12/4 の AWS re:Invent 2024 の Matt Garman の基調講演で、徳永のセッションでご紹介した Amazon Q Developer に関連する下記のアップデートが出ました。ぜひそれぞれの解説ブログもご参照ください。 New Amazon Q Developer agent capabilities include generating documentation, code reviews, and unit tests Investigate and remediate operational issues with Amazon Q Developer (in preview) Announcing Amazon Q Developer transformation capabilities for .NET, mainframe, and VMware workloads (preview) Introducing GitLab Duo with Amazon Q

本日、AWS は Invoice Configuration を発表しました。これにより、お客様固有のビジネスニーズに合わせて請求書をカスタマイズできます。Invoice Configuration を使用すると、同じ AWS Organization に属する子会社、コストセンター、法人、部署などの各事業体に属するメンバーアカウントについて、別々の AWS 請求書を受け取ることができます。 Invoice Configuration により、事業体レベルで AWS の料金を分割したり、別の “請求書の受取人” (Invoice Receiver) を指定したり、各事業体に属するメンバーアカウントごとに個別の請求書を受け取ったりすることができます。これにより、AWS 請求書をより迅速に処理できるようになるだけでなく、各事業体の資金を個別に追跡できるようにしたり、事業体全体で実施される独自の FinOps プロセスにあわせて AWS 請求書をカスタマイズしたりできるようになります。 AWS のディスカウントを最大化しつつ、費用と時間のかかる請求書の分割を軽減する 一括請求 が有効になっている AWS Organization をお持ちの場合、お客様は単一の AWS Organization 内の全メンバーアカウントの使用量に対する AWS 請求書を受け取ります。複数の事業体を持つお客様からは、AWS 請求書を管理するためには、事業体ごとに別々の AWS Organization を作成してそれぞれの使用量に対して個別の請求書を受け取るようにするか、請求書の料金を手動で分割して指定された事業体に割り当てるようにする必要がある、という話をよく伺うことがありました。別々の AWS Organization を作成するとボリュームディスカウントを受けられなくなりますが、(1 つの Organization に複数の事業体を収容すると) 料金の手動分割には時間がかかり AWS 請求書の処理のオーバーヘッドも増加します。Invoice Configuration を使用し、各事業体に属するメンバーアカウントのグループを管理して事業体ごとに個別の AWS 請求書を受け取るようにすることにより、AWS 請求書の処理を簡素化することができます。 ここでは、ある企業が AWS アカウントを様々な事業体にマッピングするという独自の要件を抱えているシナリオについて順を追って説明します。最初に Invoice Configuration UI を使って、事業体に属するメンバーアカウントを請求ユニット (Invoice Unit) に割り当てます。最後に、同じ操作をプログラムで行う方法についても説明します。 AWS Invoice Configuration のカスタマイズ 各事業体に属するメンバーアカウントの請求ユニットを 3 つのステップで作成することで、Invoice Configuration のカスタマイズを開始できます。まず、請求ユニットを作成して名前を付けます。次に、請求書の受取人となるアカウントである “請求書の受取人 (Invoice Receiver)” を割り当てます。どのメンバーアカウントをその請求ユニットに含めるかを選択できます。最後に、請求ユニットを作成したら、オプションで発注書 (Purchase Order) を 1 つ以上の請求ユニットに関連付けることができます。発注書を請求ユニットに関連付けることで、各事業体の資金を個別に追跡できるようになります。Invoice Configuration は、 ここ に記載されている SDK もサポートしています。また、 AWS CloudFormation を使ってリソースをデプロイし請求ユニットをプロビジョニングすることもできます。 シナリオ このシナリオでは、事業体の構造は AWS アカウント (A, B, C) で表される 3 つのコストセンターで構成されており、AWS Organization には管理アカウント (M) があります。その他に、アカウント (C) と同じコストセンター内にアカウント (D) とアカウント (E) の 2 つのアカウントがあります。組織の要件は、コストセンター (C) に対する請求書を別途受け取ることです。その請求書はアカウント (C), (D), (E) の使用量と共にアカウント (C) 宛に送付される必要があります。Invoice Configuration が登場するまでは、管理アカウント (M) がこの Organization 内のすべてのアカウントについての一括請求書を受け取っていました。しかし、請求ユニットを使うと、管理アカウント (M) は各コストセンターに対応する個別の請求書を受け取ることができます。各請求書には、その請求ユニットに含まれるアカウントに対する請求のみが含まれます。 図 1. AWS Organization 内の多層ビジネス構造の図 はじめに Invoice Configuration は、管理アカウントレベルで使用できる機能です。はじめに、すべてのアカウントに正しい税金設定が行われていることを確認してください。これを確認するには、“請求とコスト管理” コンソールにログインして “税金設定 (Tax Settings)“ を選択します。ここで、アカウントに正しい事業法人名、住所、納税登録情報が設定されていることを確認する必要があります。この例では、すべてのアカウントの税金設定が同じである想定としています。 注: AWS が納税情報を収集しない管轄区域については、支払い設定で正しい請求先住所と請求連絡先が設定されていることを確認してください。AWS は、お客様の所在地に基づいて AWS 請求書の税金を計算します。税金の計算方法の詳細については https://aws.amazon.com/tax-help/location/ をご覧ください。 ステップ 1：請求ユニットの作成 左側のナビゲーションバーで “請求書設定 (Invoice Configuration)” を選択します。コストセンター (C) およびコストセンター (C) 内アカウントの請求書を個別に受け取るには、 こちら の手順を参照してください。このシナリオでは、アカウント (C) を “請求書の受取人 (Invoice Receiver)” として指定します。アカウント (C) を “請求書の受取人” として選択すると、アカウント (C) は請求ユニットに関する請求書を受け取ります。請求書を分割する必要があるもののその配信先を管理アカウント (M) のままにしたい場合は、オプションで管理アカウントを “請求書の受取人” として選択することができます。アカウント (C), (D), (E) をこの請求ユニットのメンバーとします。 アカウント (A) とアカウント (B) が別々の請求書を受け取る必要がある場合には、オプションでそれらに対応する請求ユニットを設定することができます。アカウント (A) もしくはアカウント (B) に対する請求ユニットを設定しない場合、それらのアカウントに対する使用量は従来と同じ動作 (つまり、両方とも (SOR ごとに) 単一の請求書に統合され管理アカウント (M) に発行される) に従うことになります。 注: 管理アカウント (M) に使用量がない場合、AWS がこの請求書を受け取るアカウントを選択します。 図 2. コストセンター C の請求ユニットが設定された、更新済みのビジネス構造 ステップ 2：請求ユニットの更新 組織の変更があり、アカウント (B) がアカウント (D) および (E) と共にコストセンター (C) にマッピングされたものとします。 図 3. “コストセンター C とアカウント B“ の請求ユニットが設定された、更新済みのビジネス構造 AWS 請求書へのこの変更の反映は、前のステップで作成した請求ユニットを更新してアカウント (B) をその請求ユニットに追加するだけで行えます。請求ユニットの更新については こちら のドキュメントを参照してください。 注: 請求ユニットの変更は月内のいつでも行うことができます。例えば、月額請求書では、アカウント (B) がコストセンター (C) の請求ユニットへその月の 15 日に追加された場合、そのアカウントに対応する月全体の使用量が請求ユニットのアニバーサリー請求書に含まれる形となります。 ステップ 3：発注書 (PO) と請求ユニットの関連付け Invoice Configuration が登場するまでは、発注書を管理アカウントに関連付けることしかできませんでした。Invoice Configuration を使うと、PO を各請求ユニットに関連付けることができます。組織で事業体ごとに個別の資金調達プロセスがあり、その資金調達にかかるコストを追跡したいのであれば、請求ユニットを作成してその事業体の個別の請求書を受け取り、その請求ユニットに対して PO を割り当てるだけでそれを行うことができます。詳細な手順については 発注書のドキュメント を参照してください。 ステップ 4：請求書の取得 請求ユニットに対応する請求書には、請求コンソールの “請求書 (Bills)” ページからアクセスできます。請求書は管理アカウントおよび “請求書の受取人” アカウントのメールアドレスにも電子メールで送信されます。 請求ユニットのプログラムによる管理 事業体全体で数十もしくは数百のアカウントを作成・管理されていることもあるかもしれません。このユースケースでは、Invoice Configuration API を使い、プログラムで事業体を請求ユニットにマッピングしたり、請求ユニット内のアカウントの追加や更新を管理したりできます。Invoice Configuration API は AWS CLI、AWS SDK、AWS CloudFormation をサポートしています。開始するには、 API リファレンス をご覧ください。新しいアカウントを作成するときに、既に作成済みの請求ユニットにそれらのアカウントをプログラムから追加したり、事業体用の新しい請求ユニットをプログラムから作成したりできます。 まとめ Invoice Configuration は、各事業体に属するメンバーアカウントの AWS 請求書をカスタマイズしたり、事業体に対応する AWS 請求書ごとに個別の受取人や発注書を追加したりすることのできる機能です。この機能により、ボリュームディスカウントを最大化しながら、個別の AWS 請求書を受け取ることができます。Invoice Configuration を AWS 請求とコスト管理コンソール、もしくはプログラムから使用し、請求ユニットを作成・管理したり、事業体ごとに個別の請求書を受け取ったりすることができます。 TAGS: invoices Vinni Satija Sagar Vinni Satija は AWS AppConfig のプロダクトマネージャーで、ワシントン D.C. を拠点としています。彼女はお客様に対して “working backward” なアプローチをとることに情熱を注いでいます。彼女はテクノロジーを使ってお客様のニーズに応えるソリューションを作ることを楽しんでいます。 Micah Bowonthamachakr Micah は AWS Invoicing のソフトウェア開発エンジニアで、顧客体験を直接革新するための新機能の設計や実用的なソリューションの構築に注力しています。Micah は熱心なボディビルダーであり、神学や哲学の本を読むことを楽しみ、次の釣りやキャンプ旅行にいつもワクワクしています。 Nitin Nair Nitin は AWS Billing のソフトウェア開発マネージャーです。彼は顧客体験を活用してお客様がビジネス目標を達成できるよう支援する製品の構築に熱心に取り組んでいます。余暇には料理科学の探求や音楽制作を楽しんでいます。 Vijay Nattanmai Viswanathan Vijay は AWS Invoicing のソフトウェア開発エンジニアで、世界中の何百万もの AWS のお客様のための直感的な請求ソリューションの作成に注力しています。Vijay は平日はクラウドで過ごし、週末には岩壁を登ったり、街で一番おいしいものを探したり、かわいい子猫の面倒を見たり、お気に入りのビデオゲームで戦ったりしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。