前回の記事 では、AWS クラウド移行後のアーキテクチャとして、店舗に留まらない、多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマースの取り組みと、段階的に組み立てていくコンポーザブルアプローチについて紹介しました。 今回の記事は、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末（エッジ）と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介します。 エッジの運用と AWS の連携をシンプルにする AWS IoT 店舗で利用する機器については以下を実現することが求められています。 状態監視やリモート管理により故障やその兆候を確認した際に迅速な対応を取る セキュリティ管理、ソフトウェアのアップデートにより安全な状態を保つ 機器とクラウドの間でデータを連携する 国内に多店舗展開している小売業では、多くの POS や各種端末を有しているので、実現にあたってのスケーラビリティは必要不可欠です。 AWS IoT は、何十億ものデバイスを接続、管理する IoT（モノのインターネット）サービスとソリューションを提供しているので、シンプルに実現することができます。 ディザスタリカバリ（DR）を実現するマルチリージョンアーキテクチャ 前々回の記事 でも取り上げましたが、災害対策におけるシステムの冗長化構成については、想定する災害と、システムの影響範囲について構成が決定されます。 AWS グローバルインフラストラクチャ は、あらゆるアプリケーションに対応し、最も安全で、拡張性の高いインフラストラクチャを提供しているので、要件に応じたシステム構成を実現できます。災害対策に限らない、システムに関する障害対策として、マルチアベイラビリティゾーン（マルチ AZ）構成から検討するのは良い出発点です。 想定する災害（例） 影響範囲 冗長化構成 落雷による停電 アベイラビリティーゾーン（AZ） マルチ AZ 構成 関東一帯が影響を受ける災害 リージョン マルチリージョン構成（東京 – 大阪など） 日本国内の大部分が影響を受ける災害 リージョン マルチリージョン構成（東京 – シンガポールなど） 表1：想定する災害と冗長化構成の例 国内でチェーン展開している小売業においては、災害発生時、災害の影響を受けている地域については店舗の営業は困難となりますが、それ以外の地域では営業を継続することが期待されます。例えば、今や生活に欠かすことのできないコンビニエンスストアや薬を扱うドラッグストアでは、災害発生時においても、生活インフラとして営業を継続することが期待されます。 図 1：大規模災害発生時における DR サイトへのフェイルオーバー この場合、システムについては、DR サイトを用意して災害発生時にフェイルオーバーすることによってシステムを稼働することが期待されますが、AWS グローバルインフラストラクチャにおいては、マルチリージョンアーキテクチャにより実現できます。 アーキテクチャの紹介 POS を例にしたアーキテクチャを図 2 に示します。AWS IoT Device SDK で構築された POS が AWS IoT Core と接続することで、機器の管理に加えて、データの利用用途に応じたクラウドサービスとの連携と、MQTT ベースでの双方向通信を実現します。AWS IoT Core は、業務アプリケーションとデバイス管理の用途に応じて、メッセージを振り分けてデータを管理します。 災害発生時のオペレーションをできる限りシンプルにするために、セカンダリリージョンの AWS IoT Core にも事前に機器登録をします。事前登録の例としては、AWS IoT のモノの登録や、プライマリとセカンダリで共通の証明書を発行してデバイスへの組み込み、があります。 プライマリリージョンの利用不能時は、 Amazon Route 53 により接続先をセカンダリリージョンに切り替えることで、デバイス側の設定を変更することなく切り替えができます。データについて、 Amazon DynamoDB グローバルテーブルにより、プライマリリージョンの更新がセカンダリリージョンに自動的にレプリケートされます。 図 2：アーキテクチャ ユースケース POS で想定される業務アプリケーションの以下ユースケースを例に、アーキテクチャを解説します。 POSのトランザクションを連携する モバイルオーダーからの注文により在庫がないことを通知する POSのトランザクションを連携する 顧客の会計時に取得した POS データは、各店舗で連続的に発生します。また、リアルタイムな購買動向の把握や在庫管理のためストリーミングデータとして扱うことが期待されます。 図 3：POS トランザクションの連携 処理の流れについては以下の通りです。 POS データは、POS から AWS IoT Core に暗号化された MQTT プロトコルを使用して AWS IoT Core に送信されます。 AWS IoT Core は AWS IoT ルールアクションにより、 Amazon Kinesis Data Streams に MQTT メッセージのデータを書き込みます。 AWS Lambda 関数は、Amazon Kinesis Data Stream のレコードを処理し、Amazon DynamoDB で管理する在庫情報を更新します。 モバイルオーダーからの注文により在庫がないことを通知する モバイルオーダーから店舗の商品が注文されるようになると、一見在庫があるように見えても既にモバイルオーダーで購入されている可能性が生じます。モバイルオーダーの在庫を別で管理するといったオペレーションも選択肢ですが、シンプルに一緒に管理するニーズもあります。このようなケースでは、最新の在庫情報はシステムで管理されているため、在庫がなくなったことを、システムから店舗に通知する必要があります。顧客体験として改善の余地はありますが、先に注文票を持っていくケースや先に注文する飲食のケースの場合、会計時に POS に通知されている情報を元に購入できないことを伝えることで、在庫以上に購入されることを防げます。 図 4：POS へのメッセージ送信 処理の流れについては以下の通りです。 在庫情報の変更情報は、DynamoDB Streams によりキャプチャされます。 AWS Lambda 関数は、ストリームレコードを処理します。在庫がなくなった（あるいはある閾値に達した）ことを検知すると、MQTT クライアントインスタンスを作成して、AWS IoT Core にリクエストを転送します。 AWS IoT Core は、POS に MQTT リクエストを転送します。 POS アプリケーションで、転送されたリクエストを処理します。 DR サイトへの切り替え 災害発生時における DR サイト切り替えの流れを説明する前に、通常の状態について補足します。 通常の状態 プライマリリージョンとスタンバイリージョンの切り替えを、デバイス側の設定を変更することなく実施するため、AWS IoT Core はカスタムドメインを作成します（図 5 における iot.example.com）。Amazon Route 53 は、プライマリとスタンバイリージョンの AWS IoT Core エンドポイントに対して、フェイルオーバールーティングを設定します。 その他、Amazon Kinesis Data Stream や AWS Lambda 関数、DynamoDB Streams もデプロイしておきます。 図 5：通常状態（図 2 と同じ） 災害発生時 災害発生時における DR サイトへの切り替えは、業務も含めた被害状況に基づく意思決定により行われます。DR サイト切り替えの意思決定が下されると、オペレーターは、 Amazon Route 53 Application Recovery Controller のルーティングコントロールを変更して POS からの接続先を DR サイトに切り替えます。 図 6：災害発生時における DR サイト切り替え 災害からの復旧（切り戻し） 基本的には、災害発生時のオペレーションと同じく、POS からの接続先の切り替えます。一例として、以下のような手順も考えられます。 Amazon Route 53 Application Recovery Controller のルーティングコントールを変更して POS からの接続先を DR サイトからプライマリサイトに切り替える AWS IoT Core から順次特定の POS にメッセージを送り再接続を指示する 該当の POS は再接続をしてプライマリーに戻る 閉域接続の場合 一貫性のある応答性能を実現するために、店舗とクラウドのネットワーク接続を広域通信網（WAN）と AWS Direct Connect を組み合わせている場合もあります。本記事で紹介しているアーキテクチャは、そのようなネットワーク構成においても実現できます。 図 7：閉域接続の場合におけるネットワーク構成 災害発生時における AWS Direct Connect の障害影響を考慮して、 AWS Direct ロケーション を複数用意します。本記事では詳しく取り上げませんが、AWS Direct Connect の高い回復性を実現するアーキテクチャについては、 AWS Direct Connect の回復性に関する推奨事項 で詳しく解説しています。 まとめ 本記事では、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介しました。AWS IoT により、多店舗展開する小売業で期待されるデバイス管理のスケーラビリティの実現と、AWS で稼働する店舗システムとシンプルに連携することができます。 実際のユースケースは、取り上げた 2 つのユースケース以外にもありますが、今回紹介したアーキテクチャをベースにアーキテクチャを検討することができます。例えば、POS データを分析したい場合は、 Amazon S3 に POS データを蓄積することが期待されますが、Amazon Kinesis Data Streams のストリームデータを Amazon Kinesis Data Firehose でキャプチャして、Amazon S3 に配信できます。また、POS がローカルに管理する商品マスタの配信については、AWS IoT Core から POS にデータ連携することにより実現できます。この他、災害対策に対する戦略として、DR サイトを用意する必要がなければ、プライマリリージョンを対象として紹介したアーキテクチャを活用していただけます。 本記事が、皆さまの店舗システムの将来アーキテクチャの検討に役立てられれば幸いです。 関連情報 店舗システムのクラウドに関する考察 店舗システムのクラウド化に向けた考察2 – クラウド移行後アーキテクチャと進め方   ソリューションアーキテクト　平井 健治  

AWS Gateway Load Balancer (GWLB) は、2020 年 11 月より一般提供を開始しました。これは、ファイアウォール、侵入検知および防止システム、分析、可視性などのサードパーティの仮想ネットワークアプライアンスのデプロイ、スケーリング、管理を支援する新しいサービスです。Elastic Load Balancer ファミリーに新たに加わった AWS Gateway Load Balancer (GWLB) は、透過的なネットワークゲートウェイ (つまり、すべてのトラフィックの単一の入口と出口点) と、トラフィックを分散し、需要に応じて仮想アプライアンスをスケーリングするロードバランサーを組み合わせたものです。 これは大きなマイルストーンでした。なぜなら、AWS Gateway Load Balancer は、ネットワーク、セキュリティ、分析、通信、モノのインターネット（IoT）などのカスタムロジックやサードパーティ機能をあらゆるネットワークパスに差し込むための新しいフロンティアを切り開いたからです。この機能は、スケール、可用性、サービス提供、フローのスティッキーなどの問題を軽減するとともに、パートナーが中核となる専門知識に集中し、より迅速にイノベーションを起こせるようにします。 この記事では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法について詳しく説明します。「アプライアンス」という言葉は、新しいカスタムロジック、または既存の仮想アプライアンスを意味します。基礎に興味がある場合は、 GWLB ページ または別のブログ投稿「 GWLB がサポートするアーキテクチャパターン 」を見てみるとい良いかもしれません。GWLB で公開したすべてのブログをご覧になりたい場合は、 こちらのページ をご確認ください。それでは、早速見ていきましょう。 どのような種類のネットワークアプライアンスが GWLB で動作しますか？ GWLB は各パケットをレイヤー 3 で処理し、アプライアンスの状態に依存しません。この動作により、アプライアンスが Geneve のカプセル化/カプセル化解除と GWLB メタデータをサポートしている限り、任意のカスタムロジック、またはサードパーティアプライアンスを GWLB の背後にあるフリートにデプロイできます。これについては後で詳しく説明します。 GWLB はどのように機能しますか? 下の図に示すように、GWLB は別の VPC のゲートウェイロードバランサーエンドポイント（GWLBE）に接続されています。GWLBE は VPC エンドポイント (VPCE) の一種です。1 つの GWLB を複数の GWLBE に接続できます。 GWLB には 2 つの側面があります。GWBLE に接続する側は、GWLB フロントエンドと呼ばれます。ターゲットアプライアンスに接続されている側は、GWLB バックエンドと呼ばれます。バックエンドでは、GWLB は、複数の同等のターゲットアプライアンスのうちの1つを介してトラフィックフローをルーティングするためのロードバランサーとして機能します。GWLB は、ターゲットアプライアンスへの両方向のフローのスティッキーを確保し、選択したアプライアンスに異常が発生した場合にフローを再ルーティングします。この記事は、バックエンド機能、特にGLWB とアプライアンス間の通信に焦点を当てています。 送信元から宛先に送信されるパケットには、宛先 IP アドレスとして GWLB IP が含まれていませんが、ルートテーブルの設定により GWLB にルーティングされます。透過的な転送動作を実現するため（つまり、元のパケットの内容をそのまま保持するため）、GWLB は Geneve カプセル化を使用して元のパケットをカプセル化し、アプライアンスに（/from）パケットを送信（/receives）します。また、アプライアンスは元のパケットを処理するために Geneve Type-Length-Value（TLV）ペアをカプセル化解除する必要があります。 ※訳者注記：TLVはフォーマット表現の一種です。 GWLB はパケットイン/パケットアウトサービスです。アプリケーションの状態は保持されず、TLS/SSL復号化/暗号化も実行されません。これらの機能はアプライアンス自体によって実行されます。 GWLB で動作させるには、アプライアンスにどのような変更を加える必要がありますか？ GWLB と連携するためには、アプライアンスは以下の条件を満たす必要があります。 GWLB とトラフィックを交換するための Geneve プロトコルをサポートしている。Geneve のカプセル化は、GWLB とアプライアンス間のパケットの透過的なルーティングや、追加情報（後述のメタデータ）の送信に必要です。 GWLB 関連の Geneve Type-Length-Value (TLV) ペアのエンコード/デコードをサポートしている。 GWLB からの TCP/HTTP/HTTPS ヘルスチェックに応答する。 プロトタイプのアプライアンスの場合、ユーザーが上記のタスクを1日で完了するのに対し、高度なアプライアンスはさまざまな要因に応じて数日/数週間かかるのを見てきました。上記のタスクを完了すると、アプライアンスとGWLB の相互運用性をテストできます。テストとトラブルシューティングの概要は、この記事の後半で説明します。 アプライアンスが Geneve カプセル化をサポートする必要があるのはなぜですか？ 元のパケットをそのまま保持する必要があることは、GWLB が提供する重要な機能である透過的な動作の基本的な要件です。元のパケットを新しいL3パケットにカプセル化することが、GWLB とアプライアンス間でパケットをルーティングするための唯一の実行可能なソリューションです。これは、このようなパケットの送信元/宛先 IP は GWLB またはアプライアンスの IP と同じではないため、これらの IP に基づく通常の VPC ルーティングでは、パケットが GWLB またはアプライアンスをバイパスしてしまうためです。 さらに、CIDR が重複するマルチテナントアプライアンスをサポートするには、アプライアンスがトラフィックのソースを知る必要があります。また、GWLB はフローを追跡し、ユーザートラフィックが混在しないようにする必要があります。GWLB は、パケットごとにType-Length-Value（TLV）トリプレットを使用して追加情報（GWLBE/VPCE ID、フロークッキー、添付ファイルIDなど）をアプライアンスに送信することでこれを実現できます。 Geneve プロトコル ( RFC 8926 ) は柔軟性があり、この追加情報を渡すことができます。この拡張可能でカスタマイズ可能なレイヤ 3 カプセル化メカニズムにより、送信元デバイスと宛先デバイスを変更する必要がないため、幅広いユースケースをサポートし、カスタマーエクスペリエンスを簡素化できます。このドキュメントで後述する Geneve TLV 形式を参照してください。Geneve カプセル化の代替として、VXLAN と GRE が評価されましたが、フィールドのサイズが固定されているため、上記の要件を満たすことができませんでした。 GWLBはフローの送信先となるアプライアンスをどのように選択しますか？ GWLBは新しいTCP/UDPフローを受信すると、5タプルのフローハッシュ（送信元IP、宛先IP、転送プロトコル、送信元ポート、宛先ポート）を使用してターゲットグループから正常なアプライアンスを選択します。その後、GWLBはそのフローのすべてのパケット（順方向と逆方向の両方）を同じアプライアンスにルーティングします（スティッキ性）。TCP/UDP以外のフローでも、GWLBは引き続き3タプル（送信元IP、宛先IP、トランスポートプロトコル）を使用して転送を決定します。 GWLB はアプライアンスのヘルスチェックをどのように実行しますか? GWLB は、ユーザーが定義した時間間隔に基づいて定期的にヘルスチェックを実行します。GWLB は、TCP/HTTP/HTTPSパケットをアプライアンスに送信することにより、これらのヘルスチェックを実行します。アプライアンスは、以下に説明するように TCP/HTTP/HTTPS パケットに応答する必要があります。 TCP : 接続の確立は成功とみなされます。 HTTP : GWLB は、ユーザーが指定したパスを使用して、新しい TCP 接続を介してアプライアンスに HTTP リクエストを送信します。アプライアンスは TCP 接続を確立し、200〜399 の範囲のステータスコードで応答する必要があります。TCP 接続の確立に失敗した場合、アプライアンスが他のステータスコードで応答した場合、またはアプライアンスが単に応答しない場合、ヘルスチェックは失敗します。 HTTPS : HTTP の動作と同じですが、TLS 経由です。GWLB は証明書のホスト名検証を行わないため、有効な証明書（有効期限が切れていない証明書または自己署名証明書）はすべて機能します。 アプライアンスは、GWLB のタイムアウト内にすべてのチェックを完了する必要があります。これらのチェックは、通常はコントロールプレーンからのTCP/HTTP/HTTPSパケットに正しく応答したアプライアンスが、データプレーンを介して宛先にパケットを転送することもできることを前提としています。ヘルスチェックパケットは Geneve カプセル化されていないことに注意してください。GWLB ヘルスチェックについては、 このドキュメント を参照してください。 GWLB とアプライアンス間で、パケットはどのように流れますか? 次の図は、送信元 (IP アドレス A.B.C.D) から宛先 (IP アドレス E.F.G.H) に移動するときのパケットのフローを示しています。送信元からのパケットは、ルートテーブルのネクストホップを使用して GWLBE に送信されます。 ステップ1 ：GWLBE は送信元からパケットを受信すると、基盤となる PrivateLink 技術を使用してパケットを GWLB に送信します。パケットは AWS ネットワーク上にとどまり、GWLB に到達します。 ステップ 2 : GWLB は、受信パケットの 5 タプル (Src IP、Dest IP、Src ポート、Dest ポート、プロトコル) を使用して、特定のアプライアンスをターゲットとして選択します。さらに、GWLB はフロークッキーを生成します (ステップ 4 で説明)。次に、GWLB はフローエントリとそれに対応するフロー Cookie をフローテーブルに保存します。次に、GWLB は Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、Type、Length、Valueのトリプレット（TLVとも呼ばれる / 緑色で表示）の形式でメタデータを埋め込みます。TLV はステップ 4 で説明されています。この例では、GWLB の IP アドレスは 10.1.4.10 で、アプライアンスの IP アドレスは 10.1.2.5 です。 ステップ 3 : GWLB はカプセル化されたパケットを特定のアプライアンスに転送します。GWLB は、そのフローが存続している間、その 5 タプルフローを両方向のトラフィックの特定のアプライアンスに固定します。 ステップ 4 : アプライアンスは、UDP/IP パケットを受け入れることができる IP インターフェースで構成する必要があります。アプライアンスに転送されるすべてのパケットは、その IP インターフェイスで転送されます。 アプライアンスは、TLV 内の情報を解析して意思決定に使用する必要があります。パケットには、次の Geneve TLV が 1 つ以上含まれます。 GWLBE/VPCE ID : これは、GWLBE に割り当てられた 64 ビットの ID です。GWLBE は VPC エンドポイントの一種なので、GWLBE ID は VPCE ID と同じです。たとえば、アプライアンスはこの識別子を使用してパケットを設定に関連付けることができます。この GWLBE/VPCE ID は、トラフィックのソース VPC を決定するために使用できます。各 GWLBE は 1 つの VPC にのみ属することができます。GWLBE から VPC へのマッピングをアプライアンスに提供するのは、アプライアンスパートナーの管理ソフトウェアです。 フロークッキー :フロークッキーは、GWLB が最初にフローテーブルにフローエントリを作成したときにフロー用に生成される 32 ビットの乱数です。フロークッキーはフローごとに固有であり、パケットの内容から生成されるものではありません。アプライアンスはこの Cookie を「現状のまま」返さなければなりません。GWLB がアプライアンスからパケットを受信すると、アプライアンスから受信したパケットのクッキーがそのフローに割り当てられたクッキーと一致する場合にのみ、パケットはさらに転送されます。Cookie が一致しない場合、または Cookie がない場合、パケットはドロップされます。 [未来使用予定] アタッチメント ID ：GWLB が TGW、VPNGW、または Direct Connect に直接接続する場合、64 ビットのアタッチメント ID TLV がアプライアンスに送信され、送信元の VPC ID が決定されます。これはオプションの TLV で、別の AWS ゲートウェイデバイスに接続されている場合にのみ表示されます。これは将来の TLV であり、現在は存在しません。 TLV を処理した後、アプライアンスはパケットをドロップするか、転送を許可するかを選択できます。 アプライアンスがパケットを転送する場合、次のことを行う必要があります。 元のパケットを Geneve ヘッダー内にカプセル化します 外部 IPv4 ヘッダーの送信元 IP アドレスと宛先 IP アドレスを交換します（送信元 IP = アプライアンス IP アドレス、宛先 IP = GWLB IP アドレス) 元のポートを保持し、外部 IPv4 ヘッダーの送信元ポートと宛先ポートを交換してはなりません 外側の IPv4 ヘッダーの IP チェックサムを更新します 元の内部パケットの指定された 5 タプルの TLV をそのままにして、パケットを GWLB に返します ステップ 5 : アプライアンスは Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、そのフローで最初に受信したのと同じメタデータ（緑色で表示）を埋め込みます。 ステップ 6 : アプライアンスからパケットを受信すると、GWLB は Geneve カプセル化を削除します。次に、GWLBは、着信（内部）パケットの5タプルとフロークッキーを、ステップ 2 で以前に保存したフローエントリとフロークッキーの組み合わせと比較することにより、着信パケットを検証します。着信パケットの 5 タプルとフロークッキーが GWLB キャッシュ内の対応するエントリと一致する場合のみ、GWLB はパケットを GWLBE に転送します。GWLB は、キャッシュに一致するものがない場合、または着信パケットの 5 タプルまたはフロークッキーが変更された場合、着信パケットをサイレントにドロップします。 ステップ 7 : パケットは、基盤となる PrivateLink 技術を使用して GWLBE に転送されます。パケットは AWS ネットワークに留まり、GWLBE に到達します。GWLBE は、ルートテーブルのネクストホップを使用して宛先にパケットを配信します。 GWLB とアプライアンスが交換するパケット形式はどのようなものですか？ 以下のパケット形式は、Geneve カプセル化を使用してアプライアンスで受信したパケットを示しています。Geneve ヘッダーの説明については、Geneve プロトコル ( RFC 8926) を参照してください。 Outer IPv4 Header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live |Protocol=17 UDP| Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = xxxx | Dest Port = 6081 Geneve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer Geneve Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|Opt Len = 8|O|C| Rsvd. | EtherType = 0x0800 or 0x86DD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Network Identifier (VNI) = 0 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer Geneve Options: AWS Gateway Load Balancer TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 1 |R|R|R| Len = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit GWLBE/VPCE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 2 |R|R|R| Len = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit Customer Visible Attachment ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 3 |R|R|R| Len = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flow Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Customer payload follows… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Customer payload identified by EtherType in Geneve header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ アプライアンス統合のテストとデバッグのプロセスはどのようなものですか? アプライアンスソフトウェアが Geneve プロトコル、GWLB TLV のエンコード/デコードをサポートし、ヘルスチェックに応答したら、テストを行います。 VPC と必要なコンポーネントを作成します。GWLB、GWLBE、およびターゲットグループにアプライアンスを追加します。最も単純なテストケースとして、単一のアプライアンスから始めることができます。アプライアンスがヘルスチェックに応答しているかどうかを確認します。アプライアンスのパケットキャプチャをオンにすると、パケットフローを確認できます。パケットが前のセクションで示した想定どおりの形式であることを確認します。ヘルスチェックが機能しているときは、アプライアンス VPC の GWLB サブネットで VPC フローログを有効にします。GWLB エンドポイントサブネットのカスタマー VPC で VPC フローログを有効にできます。フローログを使用して、各方向からの送受信パケットを確認します。 まとめ 私たちの目標は、お客様とパートナーが Gateway Load Balancer をあらゆるネットワークパスに簡単に追加する方法として使用できるようにすることです。スケール、可用性、サービス提供、フローのスティッキーといった問題を AWS に任せていただければ、コアとなる専門知識に集中してイノベーションを加速できます。セキュリティ、分析、テレコム、モノのインターネット (IoT) のユースケースや、まったく新しいアプリケーションの可能性を切り開くことを期待しています。 この投稿では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法に焦点を当てています。何ができるかについて読者の皆様の想像力を刺激できていましたら幸いです。 詳細を知りたい場合は、次のリンクをご活用ください。 GWLB の FQA 製品概要ページ テクニカル・ドキュメント Gateway Load Balancer のすべてのブログ ローンチのお知らせ スタートガイドビデオ (11:06) Github コードサンプル 著者について Milind Kulkarni Milind は、アマゾン ウェブ サービス (AWS) のシニアプロダクトマネージャーです。ネットワーキング、データセンター アーキテクチャ、SDN/NFV、クラウド コンピューティングの分野で 20 年以上の経験があります。彼は 9 つの米国特許の共同発明者であり、3 つの IETF 標準を共同執筆しています。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文は こちら です。

エグゼクティブやそのチームに実用的で客観的なインサイトを提供する Gartner は、 2023 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) を発表しました。AWS は、柔軟で AI を活用したクラウドコンタクトセンターである Amazon Connect を 2017 年に提供開始して以来、初めてリーダーに選ばれました。私たちはこのリーダーへの選出は、あらゆる規模の企業が優れた顧客体験を低コストで提供可能にする私たちのイノベーションのペースの速さを反映していると考えています。 AWS の実行能力とビジョンの完全性が、AWS が CCaaS 分野のリーダーに選ばれた理由です。Gartner の Critical Capabilities の調査では、AWS はアジャイルコンタクトセンターで 1 位、グローバルコンタクトセンターでは 2 位、デジタルカスタマーサービスセンターとカスタマーエンゲージメントセンターのユースケースでは 3 位となっています。 Amazon Connect は 2017 年に提供開始されて以来、オムニチャネルのカスタマーエクスペリエンス、エージェントの生産性、分析、洞察、最適化のための新機能を継続的に発表してきました。 Amazon Connect 担当のバイスプレジデントである Pasquale DeMaio は、次のように語っています。「お客様やエージェントに、これまでにない体験を提供できるようになったことを大変嬉しく思います。過去 1 年間に多額の投資を行い、エージェントへのステップバイステップのガイダンス、ケース管理、予測、キャパシティプランニング、スケジューリング、画面録画などの 重要な新機能 をリリースしました。私たちはこの勢いを維持しており、このような一連の機能拡張が私たちをリーダーとして認める重要な要因になったと考えています。」 現在、Priceline、Deliveroo、Unum、Capital One、富士通、Intuit、John Hancock、 New York Times、National Australia Bank などの Amazon Connect のお客様 は、Amazon Connect を利用してより良い顧客体験を提供しています。 Gartner のレポートは、お客様のビジネスに適したクラウドコンタクトセンターソリューションを評価する際の、洞察に富んだガイダンスを提供しています。 2023 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) の無償版は、こちらからご覧いただけます 。 この図は、Gartner, Inc. が発行したより大きな調査文書の一部であり、文書全体の文脈で評価されるべきものです。 Gartner の文書は、 AWS にリクエストすることで入手可能です。 GARTNER および Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。すべての権利は留保されています。All rights reserved. Gartner は、その調査出版物に記載されているいかなるベンダー、製品またはサービスも推奨するものではなく、また、テクノロジーユーザーに対して、最高の格付けまたはその他の指定を受けたベンダーのみを選択するよう助言するものでもありません。Gartner の調査出版物は、 Gartner の調査組織の見解で構成されており、事実の記述として解釈されるべきものではありません。ガートナーは、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

データベースリソースの使用率を把握すると、データベースワークロードの特性と使用傾向を理解するのに役立ちます。このデータは参照点として役立ち、後の測定値と比較することでパフォーマンスの問題を特定して調査できます。偏差は、パフォーマンスのチューニング、データベースのメンテナンス、または構成の変更を必要とする懸念事項を示している可能性があります。 リソース使用率は通常、オペレーティングシステムとデータベースの使用状況、データベースの待機イベント、クエリ処理時間など、データベースのパフォーマンスに影響を与えるメトリクスを取得します。通常の業務中にこのデータを定期的に収集することで、データベースインスタンスの状態に関する洞察を得ることができます。 Amazon Relational Database Service (Amazon RDS) は、1 分間隔でメトリクスデータを Amazon CloudWatch に自動的に送信します。期間が 1 分のデータポイントは 15 日間使用できます。つまり、開始点となるインスタンスの履歴情報があるということです。収集したメトリクスを使用して、CPU、メモリ、ディスク、ネットワーク、クライアント接続など、データベースインスタンスのリソース使用率を左右するアプリケーションのワークロードパターンを大まかに把握できます。 Amazon RDS には、RDS インスタンスのリソース使用状況を把握するのに役立つ以下のモニタリングツールが用意されています。 Amazon RDS 拡張モニタリング Amazon RDS Performance Insights この投稿では、 Amazon RDS for SQL Server でリソース使用率メトリクスをキャプチャしてチューニングする方法を示します。 Amazon RDS 拡張モニタリング 拡張モニタリングは、DB インスタンスが実行されているオペレーティングシステムのメトリクスをリアルタイムで提供します。これらのメトリクスには 1 秒単位で細かく設定することができ、Amazon RDS コンソールまたは API からアクセスできます。拡張モニタリングは DB インスタンス上のエージェントからメトリクスを収集するのに対し、CloudWatch はハイパーバイザーレイヤーでメトリクスを収集します。詳細については、「 拡張モニタリング 」をクリックしてください。 主なメトリクスは次のとおりです。 CPU Utilization – CPU 使用率を監視すると、パフォーマンスの問題の原因が CPU 負荷によるものかどうかを特定するのに役立ちます。たとえば、パフォーマンスの問題が発生した時点で CPU 使用率が 80% で、先週の同じ時間帯の CPU 使用率が同様で問題が報告されなかった場合、CPU がボトルネックではない可能性があります。 Disk – 読み取り/書き込み IOPS などのメトリクスを使用して I/O とストレージの使用パターンを追跡し、傾向を把握できます。また、ストレージのキャパシティプランニングにおいて、 gp2 や io1 ディスクなどの使用可能なボリュームタイプから選択するのにも役立ちます Memory – パフォーマンス問題はメモリのボトルネックが関係していることが多くあります。拡張モニタリングでは、システム (合計メモリと使用可能なメモリ) と SQL Server (SQL Server の合計メモリ) のメモリ使用量とパターンを追跡して、ボトルネックを特定できます。 Network – 拡張モニタリングによって収集されるネットワークパフォーマンスメトリクス (ネットワーク読み取り KB/秒、ネットワーク書き込み KB/秒) は、ネットワーク経由で転送されるデータ量を追跡するのに役立ちます。 これらのメトリクスを使用すると、ビジネスプロセスの重要な日時におけるリソースの使用状況を的確に把握できます。これらの値はリソース使用率の全体像を把握できるため、比較して潜在的なボトルネックを特定する必要がある場合に役立ちます。 CloudWatch でダッシュボードを作成すると、説明されているこれらのパフォーマンスメトリクスを一元的に表示できます。次のスクリーンショットは、CloudWatch と拡張モニタリングのデータを含む統合ダッシュボードを示しています。 Amazon RDS Performance Insights Performance Insightsは、RDS データベースのパフォーマンスに関する洞察を提供する監視ツールです。Performance Insights の無料利用枠では、RDS データベースから毎秒データを収集し、7 日間保持します。長期的なパフォーマンストレンドについては、パフォーマンスデータの履歴を最大 2 年間まで延長できます。Performance Insights で表示される情報は ネイティブパフォーマンスメトリクスに基づくため、RDS データベースエンジンごとに若干異なります。Performance Insights を使用すると、一定期間のデータベース負荷、上位の待機タイプ、上位 SQL クエリの傾向を収集できます。この情報を使用して現在のデータと比較し、潜在的な根本原因を特定できます。 ほとんどの SQL Server データベース管理者は、SQL Server の問題を診断およびデバッグするための動的管理ビュー (DMV) に精通しています。DMV ではデータは収集されたままであるため、使用傾向を把握するメカニズムを開発する必要があります。そこで、データの収集と保存を自動化することで Performance Insights が役に立ちます。 主なメトリクスは次のとおりです。 Access Methods – ページ分割 – これにより I/O のボトルネックが発生する可能性があり、数値が大きい場合は、インデックスの再構築や フィルファクター 設定の再検討などのメンテナンス作業が必要であることを示している可能性があります。 Blocks and Locks – ロックの競合は SQL Server のパフォーマンス上の問題を引き起こす可能性があります。傾向分析のためだけでなく、データベースのパフォーマンスを向上させるためにチューニングが必要な SQL を特定するためにも、この情報を追跡することが重要です。ブロックされたプロセスとデッドロックの数を追跡できます。 Memory Manager – 保留中のメモリ許可は、一定期間のメモリボトルネックを追跡するのに役立ちます。 SQL Stats – Performance Insights には、バッチリクエスト、SQL コンパイル、SQL 再コンパイルなど、通常のデータベース負荷の原因となるタスクを理解するのに役立つさまざまな SQL 統計があります。 Buffer Manager – ページ寿命とバッファキャッシュヒット率は、メモリ不足の検出に役立ちます。ページ読み取りとページ書き込みは、インデックス作成の見直しが必要な場合など、最適化方法に関するガイダンスを提供します。 これらのメトリクスは、SQL Server のパフォーマンスに関するインサイトを提供します。パフォーマンスメトリクスを含む OS とデータベースのメトリクスを詳しく調べて、問題の根本原因を理解することができます。次のスクリーンショットは、これらのメトリクスの例を示しています。 動的管理ビューとクエリストア 異常を特定したら、動的管理ビューを使用してさらに深く調査し、パフォーマンスの問題をデバッグできます。詳細については、「 システム動的管理ビュー 」を参照してください。 SQL Server 2016 以降、Amazon RDS for SQL Server はクエリストアもサポートします。これを使用して SQL ステートメントのクエリプランを追跡および管理できます。詳細については、「 Amazon RDS for SQL Server が Microsoft SQL Server 2016 をサポートするようになりました 」を参照してください。 問題の診断とデバッグ: CPU 使用率 アプリケーションが昨日まで最適なパフォーマンスを発揮していたのに、現在はパフォーマンスが低下しているという一般的なシナリオを見てみましょう。このユースケースでは、CloudWatch アラートまたはユーザーからの苦情を通じてこのことを知りました。 メトリクスを調べることから問題の診断を開始します。CloudWatch では、CPU 使用率メトリクスが高く、おそらく 90% を超えていることがわかります。SQL Server プロセスがこの高いパーセンテージに寄与しているかどうかを知りたいと思うでしょう。Amazon RDS コンソールの モニタリング タブの プロセスリスト から確認できます。 このような場合は、RDS インスタンスのリソース使用状況を追跡することが役立ちます。データがキャプチャされれば、時間の経過に伴う CPU 使用率の傾向を効率的に特定できます。拡張モニタリングでは、過去 30 日間のインスタンスの CPU 使用率の傾向をグラフ化できます。これにより、この挙動が正常かどうかがわかります。 次のステップは、Performance Insights でキャプチャされたデータを使用して、CPU 負荷の原因となっているクエリを特定することです。次のスクリーンショットは、時間の経過と共に蓄積されたデータを含むグラフを示しています。 このグラフから、このインスタンスでは CPU の待ち時間が大部分であり、一定期間にわたって増加していることがわかります。この傾向から、キャパシティプランニングに必要なデータも得られます。 関心のある時間に絞り込むと、CPU 使用率別の上位 T-SQL クエリのリストを表示できます。動的管理ビューから実行プランやクエリに関する詳細情報を取得できます。 高い CPU 負荷の原因となっている上位 3 つのクエリをとうとう特定しました。クエリ自体に加えて、クエリを実行している上位のホストと上位ユーザーを特定して、トラブルシューティングの取り組みをさらに絞り込むことができます。 最初のクエリを例として使用します。SQL Server Management Studio (SSMS) を使用してクエリの実行統計と実行プランを取得するには、まずクエリのフィンガープリントを知る必要があります。この情報は、パフォーマンスインサイトから取得できます。 SQL ID は、統計と実行プランを取得するために動的管理ビューに入力する値です。次のスクリーンショットに示すように、SQL ID の前に 0x を付ける必要があります。 クエリプランを作成したら、次のステップは、既知の クエリ最適化方法 を使用してクエリを最適化することです。 結論 この投稿では、インスタンスの状態と使用パターンをキャプチャして分析するための優れた方法を提供する、Amazon RDS for SQL Server の拡張モニタリングと Performance Insights について学びました。この情報があると、パフォーマンス問題の最適化とトラブルシューティングに役立ちます。この記事で説明する方法を使用すると、インスタンスのパフォーマンスを向上させることができます。 著者について Barry Ooi は、AWSのシニアデータベーススペシャリストソリューションアーキテクトです。彼の専門分野は、お客様が AWS を利用する一環としてクラウドネイティブサービスを使用してデータプラットフォームを設計、構築、実装することです。彼の関心分野には、データ分析と視覚化が含まれます。休暇では、音楽と野外活動を楽しみます。 LRita Ladda は、アマゾンウェブサービスのマイクロソフトスペシャリストシニアソリューションアーキテクトで、さまざまなマイクロソフトテクノロジーで 20 年以上の経験があります。SQL Server やその他のデータベースにおけるデータベースソリューションの設計を専門としています。Microsoft ワークロードの AWS への移行とモダナイゼーションに関するアーキテクチャに関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

Amazon CodeWhisperer などの AI コーディング支援ツールは、デベロッパーがコードを迅速かつ安全に記述できるようにサポートすることで、デベロッパーの生産性を向上させることを目的としています。しかし、特定のケースでは、デベロッパーは、毎日多用する内部ライブラリと API に基づくコードのレコメンデーションが必要です。 既存の AI コーディング支援ツールのほとんどはオープンソースコードでのみトレーニングされているため、プライベートコードリポジトリを使用してコードのレコメンデーションをカスタマイズすることができません。この制限により、デベロッパーにはさまざまな課題が生じます。デベロッパーが内部ライブラリを正しく使用し、セキュリティ上の問題を回避する方法を学習するのは困難です。大規模なコードベースの場合、該当のタスクを完了するためにどのようなコードを記述する必要があるかを理解するために何時間もドキュメントを読む必要があります。 現在プレビュー版を提供中 – Amazon CodeWhisperer のカスタマイズ機能 10月7日、組織が CodeWhisperer をカスタマイズして、プライベートコードリポジトリからコードに関する特定のレコメンデーションを生成できるようにする Amazon CodeWhisperer のカスタマイズ機能 (プレビュー版) を発表しました。この機能により、 Amazon CodeWhisperer Professional 階層をご利用のデベロッパーは、内部ライブラリ、API、パッケージ、クラス、メソッドを含む、コードに関するリアルタイムのレコメンデーションを受け取ることができるようになりました。 自分が AnyCompany という架空の食品配送会社に勤務するデベロッパーであると想像してみてください。ドライバーの現在地周辺で割り当てられていない食品配送のリストを処理するタスクが与えられました。以前の CodeWhisperer では、未割り当ての食品配送を処理したり、ドライバーの現在地を取得したりするための正しい内部 API を認識できませんでした。その理由は、この情報が公開情報ではないからです。 カスタマイズ機能を使用することで、会社の内部サービスに関連する特定のコードを含むレコメンデーションを提供するよう CodeWhisperer に指示することができます。次のスクリーンショットは、一連のコメントを記述するだけで CodeWhisperer が内部コードベースに基づいてコードを生成する様子を示しています。 内部コードベースを利用するカスタマイズ機能により、CodeWhisperer は意図を理解し、タスクに最適な内部 API とパブリック API を判断して、コードに関するレコメンデーションを生成するようになりました。 仕組み 上記の説明では、デベロッパーとして CodeWhisperer のカスタマイズ機能を使用する方法を示しました。次に、その仕組みと開始方法について見ていきましょう。 カスタマイズを作成するには、CodeWhisperer の管理者として次のステップを完了する必要があります。 CodeWhisperer の管理者 としてエンドユーザーを管理します。 既存のリポジトリに接続します。 AWS CodeStar 接続を使用して、GitHub、GitLab、または BitBucket アカウント内の 1 つ以上のコードリポジトリに接続するか、またはすべてのコードを Amazon Simple Storage Service (Amazon S3) バケットに手動でアップロードできます。 カスタマイズを作成します。CodeWhisperer はコードベースに基づいてモデルをカスタマイズします。 チームメンバーのためにカスタマイズをアクティブ化します。カスタマイズが作成されたら、カスタマイズを確認して、チームメンバーの IDE で自動的に使用可能になるように手動でアクティブ化できます。 この機能は、組織に固有のカスタマイズされたコードに関するレコメンデーションをリアルタイムで提供し、貴重な知的財産を確実に保護するという 2 つの主な利点を提供します。組織は、既存のリポジトリ内のコードに基づいて、品質およびセキュリティ基準を満たすコードの使用を推進できるようになりました。 さらに、CodeWhisperer は、 AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用してカスタマイズデータを暗号化するオプションを提供することで、コードのセキュリティを確実に維持します。このカスタマイズデータは、カスタマイズジョブが完了すると削除されます。 使用を開始しましょう ここからは、Amazon CodeWhisperer のカスタマイズ機能を使用する方法を説明します。 使用を開始するには、カスタマイズを作成する必要があります。Amazon CodeWhisperer ダッシュボードの [カスタマイズを作成] ページに移動するには、管理者アクセスが必要です。 [カスタマイズを作成] ページで、CodeWhisperer にトレーニングさせたいプライベートコードリポジトリに接続できます。現在、CodeWhisperer のカスタマイズ機能は、 AWS CodeStar 接続を介した GitHub、GitLab、Bitbucket への接続をサポートしています。使用するコードがいずれのコードリポジトリにもない場合は、コードを手動で S3 バケットにアップロードし、Amazon S3 URI を定義することもできます。 次のスクリーンショットは、自分のコードリポジトリとの間に AWS CodeStar 接続を使用した既存の接続があることを示しています。 [新しい接続を作成] を選択して、新しい接続を作成することもできます。 その後、 [カスタマイズを作成] を選択すると、接続で使用可能なコードに基づいて、CodeWhisperer がモデルのトレーニングを開始できるようになります。このプロセスが完了するのにかかる時間は、コードリポジトリのサイズによって異なります。 カスタマイズの準備ができても、CodeWhisperer は、そのカスタマイズを自動的にアクティブ化しません。これにより、必要なときにそのカスタマイズをアクティブ化できる柔軟性が得られます。しかし、そのデモンストレーションを行う前に、 [評価] スコアについてご説明します。 簡単にお伝えすると、評価スコアは、コードリポジトリ内のコードに基づいて、コードに関するレコメンデーションを予測および提供する際のカスタマイズの精度を測定するのに役立ちます。スコアは、1) [非常に良い] (スコア: 7～10)、2) [普通] (スコア: 4～7)、3) [悪い] (スコア: 0～4) という 3 つのカテゴリのいずれかで提供されます。評価スコアが 6 以上の場合は、カスタマイズをアクティブ化することをお勧めします。評価スコアが希望するスコアよりも低い場合は、カスタマイズのために十分なコードが確実に提供されているようにして、内部 API への参照を広範囲に含む新しいコードデータセットを提供する必要があります。 ここでは、カスタマイズの [評価スコア] は 8 であるため、私はこの結果に満足しています。その後、 [アクティブ化] を選択して、このカスタマイズの使用を開始できます。 カスタマイズをアクティブ化したら、 [ユーザーを追加] を選択して、選択したカスタマイズへのアクセスを定義できます。これで、Amazon CodeWhisperer Professional 階層のユーザーとして追加された、選択したチームメンバーのために、カスタマイズへのアクセスを付与できるようになりました。これを行うには、「 Administering end users 」ページのガイドに従います。 その後、チームメンバーが IDE で AWS Toolkit 経由でサインインすると、使用可能なカスタマイズが表示され、使用を開始できるようになります。 Amazon CodeWhisperer を利用すると、さまざまなコードリポジトリを提供することで複数のカスタマイズを作成できます。この機能は、特定のチームのために、コードに関するレコメンデーションのカスタマイズを構築する場合に役立ちます。 管理者は、CodeWhisperer ダッシュボードページに移動して、各カスタマイズのパフォーマンスをモニタリングすることもできます。このページでは、ユーザーアクティビティ、CodeWhisperer によって提案され、チームメンバーによって受け入れられたコードの行数、IDE から正常に実行されたセキュリティスキャンの数などの有用なデータの要約を確認できます。 また、Amazon CodeWhisperer のカスタマイズ機能は、Visual Studio Code、IntelliJ JetBrains、Visual Studio、AWS Cloud9 など、AWS Toolkit by Amazon CodeWhisperer の一部としてサポートされている IDE に従います。この機能は、Python、Java、JavaScript、TypeScript、C# などの極めて一般的なプログラミング言語のサポートも提供します。 パブリックプレビューにぜひご参加ください Amazon CodeWhisperer は、お客様の内部コードベースを安全に活用することで、独自の要件に合わせてカスタマイズされた、生成系 AI を活用したコーディングの可能性を最大限に引き出します。 今すぐパブリックプレビューに参加し、 Amazon CodeWhisperer のカスタマイズ のページで開始方法の詳細をご覧ください。 コーディングをお楽しみください! –  Donnie 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 皆さんの中にはAWS PrivateLinkをお使いの方も多いのではないでしょうか？ 実は、PrivateLinkのリージョン対応はWhat’s newが出ないことが多く、気づかれてないことも多いです。 最近だと大阪リージョンのAPI Gatewayで private API が利用できるようになっています。もし、対応を待っているサービス、リージョンがある場合定期的にチェックしてみてください。お近くにSAにお声がけいただくのもOKです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月16日週の主要なアップデート 10/16(月) Introducing Amazon EC2 R7i instances Amazon EC2 R7i インスタンスがGAしました。第4世代 Xeon スケーラブル・プロセッサー(Sapphire Rapids)を搭載したR7iは最大48xlargeという大きなインスタンスサイズと、DDR5メモリを備えており、SAPのほかSQL、NoSQLのデータベース、SAP HANAなどのインメモリデータベース、HadoopやSparkなどのビックデータ分析などメモリを大量に必要とするワークロードに最適です。R7iインスタンスはバージニア北部、オハイオ、オレゴン、アイルランド、ストックホルム、スペインのリージョンでご利用いただけます。 AWS Client VPN extends availability to three additional AWS Regions AWS Client VPNの提供リージョンが３つ追加され、大阪リージョンでもご利用いただけるようになりました。大阪リージョンにないことで代替で東京リージョンでご利用だった、または大阪リージョンのEC2でVPNアプライアンスをご利用だった皆様はぜひご活用ください！ Introducing Recover into Existing Instance for AWS Elastic Disaster Recovery AWS Elastic Disaster Recovery (AWS DRS) が既存のインスタンスへの復元をサポートしました。これまでDRSでAWS上のインスタンスを復元する際は新しいインスタンスを起動する必要がありました。今回のアップデートにより元のインスタンスまたは事前に設定した既存インスタンスへの復元に対応しました。この機能追加はDRSが利用可能なすべてのリージョンで利用可能です。 10/17(火) Announcing Regional Expansion of ml.p4d instances on SageMaker Inference SageMakerでml.p4dを利用できるリージョンに東京とフランクフルトが追加されました。ml.p4dインスタンスはNVIDIA A100を搭載したインスタンスでリアルタイム・非同期推論のためのMLモデルに向いています。同時に” Preview of Regional Expansion for ml.p4d, ml.trn1, and ml.g5 instances on SageMaker Inference “で、ml.p4d.24xlargeが東京リージョンを含む新たに４リージョンでプレビュー利用できるようになったこともアナウンスされています。 Amazon OpenSearch Service adds support for four new language analyzers Amazon OpenSearch Serviceに日本語のSudachiを含む４つの言語アナライザープラグインが追加されました。日本語のプラグインとしてはこれまでもKuromojiがサポートされていましたが、新たな選択肢が追加された形です。これらの新しいプラグインは‘TXT-DICTIONARY’に加えて‘ZIP-PLUGIN’として提供されています。これらの追加プラグインはAmazon OpenSearch Serviceが利用可能なすべてのAWSリージョンで利用できます。 Amazon Relational Database Service announces Dedicated Log Volume Amazon RDSがPostgreSQL、MySQL、及びMariaDBでDedicated Log Volumeをサポートしました。Dedicated Log Volumeはトランザクションログを専用ボリュームに保存する設定です。データベースで最もレイテンシー変動の影響を受けやすいトランザクションログを個別のボリュームに書き込むため、クエリやデータ更新との衝突が減りコミット待ちやIPOS要求が軽減されます。詳細については ドキュメント をご確認ください。 10/18(水) Amazon Redshift announces integration with AWS Secrets Manager Amazon RedshiftがAWS Secrets Managerとの統合をサポートしました。データベースの作成、変更、復元など管理者権限が必要な作業の職務権限分離が容易になるほか、KMSと連携してのシークレットの暗号化も簡単になります。この機能はRedshiftが利用可能なすべてのAWSリージョンで、プロビジョニングされたクラスターとサーバレス両方で利用可能です。 AWS IoT TwinMaker is now available in Tokyo, Seoul, and Mumbai デジタルツインを簡単に構築できるようにするマネージドサービスであるAWS IoT TwinMakerが新たに東京を含む3リージョンで利用できるようになりました。 Share Amazon Route 53 Application Recovery Controller clusters across multiple AWS accounts AWS Resource Access Manager (AWS RAM)を使用してAmazon Route 53 Application Recovery Controller (Route 53 ARC)のクラスターをAWS Organizationsの組織、もしくはOU内で共有できるようになりました。クラスターを共有できることで、クラスター数が減り、総コストの抑制につながります。また、AWS RAMを使用してRoute 53 ARCクラスターを共有するための追加料金は発生しません。 Amazon OpenSearch Service announces new administrative options Amazon OpenSearch Serviceでより詳細な制御ができるようになりました。OpenSearchはノードに異常がないか監視し、クラスターの安定性を維持するための是正を行ってくれるマネージドサービスです。一方で、エキスパートなユーザーがより綿密な管理を行うためにプロセスや、データノードの再起動などのオペレーションが追加されました。これらの管理オプションはOpenSearchの利用もしくはElasticsearch バージョン 7.0以上を実行しているすべてのクラスターでサポートされます。新しい管理オプションの詳細は ドキュメント をご確認ください。 10/19(木) AWS announces member account level credit sharing preferences AWS Organizationsの組織内で柔軟なクレジットのシェアが可能になりました。これまでクレジットの共有は組織全体に対して有効化または無効化しかできませんでした。今回のアップデートによりアカウント単位での選択・除外ができるようになったためより細かく管理することが可能です。詳細は ドキュメント をご確認ください。 Amazon OpenSearch Service now offers Amazon EC2 Im4gn instances Amazon OpenSearch ServiceにAWS Graviton2 プロセッサを搭載したAmazon EC2 Im4gn インスタンスが追加されました。Im4gn インスタンスは最大30TBのローカルNVMEストレージを搭載しており、非常に低いI/Oレイテンシーを要求されるリアルタイムログ分析等に向いています。このAmazon OpenSearch Service Im4gn インスタンスは東京を含む11のリージョンですぐにご利用いただけます。 AWS Glue for Apache Spark announces native connectivity for Google BigQuery AWS Glue for Apache SparkがGoogle BigQueryへのネイティブ接続をサポートしました。これまでもBigQueryとの接続はサポートされていましたが、コネクタのインストールが必要でした。今回のアップデートで事前の準備作業不要にBigQueryからのデータ読み込みやBigQuery SQLを使用しての操作等が可能になります。この機能はGlueが利用可能なすべての商用リージョンで利用できます。詳細については ドキュメント をご確認ください。 Amazon WorkSpaces now supports Windows Server 2022 bundles Amazon WorkSpacesにWindows Server 2022を搭載した新しいバンドルが追加されました。この追加はAmazon WorkSpacesが利用可能なすべてのリージョンで利用できます。なおWindows Server 2016/2019搭載のバンドルは引き続き利用可能です。 10/20(金) Amazon Kendra releases connectors for 11 JDBC data sources to enable structured data search 機械学習を利用した検索サービスのAmazon Kendraが11のデータベースに対して、コネクタ経由でコンテンツのインデックスを作成し、コンテンツ全体の情報を検索できるようになりました。対象のデータベースはAurora(MySQL互換、PostgreSQL互換)、RDS（MySQL、PostgreSQL、Oracle、Microsoft SQL Server）、MySQL、PostgreSQL、Oracle、Microsoft SQL Server、DB2です。これらの11のDBコネクタは、AmazonKendraが利用化の王なすべてのAWS リージョンでご利用いただけます。 AWS Service Catalog announces support for additional Infrastructure as Code (IaC) provisioning tools AWS Service CatalogでAnsible、Chef、Pulumi、Puppetなどがサポートされました。これまでサポートされていたCloudFormationやHashiCorp Terraform Clud configurationに加え、これらのツールをご利用のお客様はService Catalogを使うためにIaCツールの移行や変更をせずとも各種機能を利用することができます。この機能はAWS GovCloudを含めたAWS Service Catalogが利用できるすべてのAWSリージョンで利用できます。 AMI Block Public Access now enabled for all new accounts and existing accounts with no public AMIs Amazon Machine Image Block Public Access (AMI BPA)がすべての新しいAWSアカウント、及び2023年7月15日以降パブリックAMIを所有していないすべての既存AWSアカウントでデフォルトで有効になりました。これまではAMI BPAはデフォルトでは無効でした。この変更により誤ってAMIをパブリックに共有することが制限されるので、お客様のセキュリティの向上につながります。AMI BPAについての詳細は ドキュメント をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

Amazon Bedrock は、基盤モデル (FM) を使用して生成系AI アプリケーションを構築およびスケーリングする簡単な方法です。フルマネージドサービスとして、AI21 Labs、Anthropic、Cohere、Meta、Stabability AI、Amazon などの主要な AI 企業が提供する高性能な FM を選択できます。また、生成系 AI アプリケーションの構築に必要な幅広い機能も備えているため、プライバシーとセキュリティを維持しながら開発を簡略化できます。 BedrockはAmazon CloudWatchと統合されているため、使用状況のメトリクスを追跡し、監査目的でカスタマイズされたダッシュボードを構築できます。これらのメトリックスを使用して、単一アカウントの 1 つのファンデーションモデルから、複数のアカウントにわたるすべての基盤モデルへのモデル呼び出しやトークン数などの使用状況を把握できます。また、Bedrockではmodel invocation loggingと呼ばれる、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスを収集できる機能を顧客に提供しています。デフォルトではこれらの機能は無効になっているため、model invication loggingを開始するにはユーザが有効にする必要があります。 このブログ記事では、CloudWatch を使用して Bedrock をほぼリアルタイムで監視する方法について詳しく説明します。メトリクスとログを使用して、値が事前定義されたしきい値を超えたときにアラームをトリガーしたり、アクションを実行したりできます。CloudWatch には、クロスアカウントでのオブザーバビリティ、ログとメトリクスの相関関係、複合アラーム、ログ分析、アプリケーションパフォーマンスモニタリングなど、他にも活用できる豊富な機能が備わっています。 Model Invocation Loggingの設定 Model Invocation Loggingは現在プレビュー段階であるため、この機能に変更が加えられる可能性があることに注意してください。ロギングを有効にすると、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスが収集されます。 ロギングを設定するには、左側のナビゲーションバーからBedrockコンソールの設定ページに移動します。次に、Model Invocation loggingボタンを切り替えます。ロギングを有効にする前に入力する必要のあるフィールドがいくつか表示されます。 図 1: ログ (テキスト、画像、埋め込み) に含めるデータタイプの複数選択制御 次に、ロギング先を選択します。オプションは3つあります。1 つ目のオプションは S3 only で、選択した S3 バケットにのみログを送信するように Bedrock を設定します。2 つ目のオプションは CloudWatch Logs only で、ログを CloudWatch に送信し、モデルの入出力データが 100 KBを超える場合、 またはバイナリ形式の場合は、オプションで S3 に送信できます。最後のオプションは S3 と CloudWatch のログの両方 で、ログは S3 と CloudWatch の両方に送信され、モデルの入出力データのどちらかが 100 KB を超える場合やバイナリ形式のデータの場合は S3 にのみ送信されます。どのオプションを選択しても、KMS による暗号化や保存期間など、モデルの入力と出力を制御できます。このブログの場合は、 CloudWatch Logs のみ のオプションを選択しました。 CloudWatch ログ設定セクションで、ロググループ名を指定します (この場合は /aws/bedrock を選択しました)。最初にこのロググループを CloudWatch で作成する必要があることに注意してください。 次に、 Create and use a new role オプションを選択し、ロールの名前を指定します。今回は BedrockCloudWatchLogs を選びました。 最後に S3 に移動して S3 バケットを作成します。私の場合は、バケット名に bedrock-logging-[ACCOUNTID]-[REGION] という形式を選択しました。次に BedrockのSettingsメニュー に戻り、”S3 location for large data delivery“ フィールドで新しく作成したバケットを選択し、「設定を保存」をクリックして設定を完了します。 Bedrock からのログデータの生成 Bedrockでのロギングの設定が完了したので、AWSコンソールからBedrockのモデルを試せるプレイグラウンドを使用してログデータを生成してみましょう。 Bedrockのチャットプレイグラウンドに移動し、モデルを選択してプロンプトを表示します。このケースでは、Amazon CloudWatch の概要について簡単に説明してもらうようお願いしています。 図 2: BedrockのChat プレイグラウンド。Claude Instant V1.2 モデルを選択し、Amazon CloudWatch の概要を簡単に説明させている Logs Insights からロググループにクエリを実行すると、ほぼリアルタイムで新しく作成されたロググループのログが表示されるようになります。 図 3: CloudWatch ログインサイトクエリ。Bedrock のModel Invocation Logging用に新しく作成されたロググループからのログイベントを示している モデル呼び出しログが配信されたら、CloudWatch の 2 つの機能を使用してログを調べることができます。1 つは Live Tail で、もう 1 つは Log Insights です。 Live Tail を使用したストリーミングログ CloudWatch Logs の Live Tail は、ログが取り込まれるとほぼリアルタイムでインタラクティブに表示できる、インタラクティブなログ分析エクスペリエンスを提供する機能です。Live Tail は、受信したログの問題をすぐに確認して検出できる豊富なエクスペリエンスを顧客に提供します。さらに、問題のトラブルシューティング中に、フィルタリング、関心のある属性の強調表示、ログの一時停止/再生をきめ細かく制御できます。 図 4: CloudWatch LogsのLive TailBedrock。Chat Playground によって生成された Bedrock モデル呼び出しログからのログイベントを表示する Log Insightsによるログ分析 CloudWatch Log Insightsを使用すると、CloudWatch ログのログデータをインタラクティブに検索して分析できます。クエリを実行することで、運用上の問題により効率的かつ効果的に対応できます。 Bedrockの場合、Log Insightsを使用してモデル呼び出しログを検索および分析し、特定のキーワードまたは単に最新の呼び出しログを検索できます。コマンドの全リストは、 こちら でご覧いただけます。 図 5: Log Insights クエリ。ModelID、操作、入出力トークンの数、プロンプトを含む最新のログイベントを 100 件表示している Log Insightsは最近、MLベースのパターンクエリコマンドも導入しました。これにより、顧客はログの傾向やパターンをより簡単に識別できます。パターンコマンドは AWS Machine Learning アルゴリズムを使用して、ログデータ内のパターンを自動的に認識し、関連するログを集約し、数千のログ行を視覚化しやすいグループにまとめます。 以下の例では、この新しいパターンコマンドをモデル呼び出しログのプロンプトフィールドに使用して、Bedrockへのプロンプトのパターンを認識しています。 図 6: 1時間にわたるLog Insightクエリ。pattern コマンドを使用してプロンプトテキストを要約している。 機械学習によるCloudWatch ログのデータ保護 CloudWatch には、パターンマッチングと機械学習 (ML) を活用して転送中の機密データを検出して保護する一連の機能もあります。まず、ロググループのデータ保護ポリシーを有効にします。ポリシーを作成するときは、保護するデータを指定します。その際、100 を超えるマネージド なData identifiers (下図) から選択できます。 図 7: データ保護ロググループポリシーの設定 上の例では、ロググループ内の IP アドレスを検索するようにデータ保護ポリシーを設定しました。Bedrockに「192.168.0.1とは」と尋ねると、モデルの入出力ログイベントで検出されたIPアドレスをマスクします。 図 8: プロンプトフィールドで IP アドレスをマスクした JSON での単一モデル呼び出しのログイベント Bedrock ランタイムメトリクス BedrockはほぼリアルタイムのメトリクスをCloudWatchに送信します。これを使用して、特定のしきい値を監視するアラームを設定し、値がそのしきい値を超えたときに通知を送信したり、アクションを実行したりできます。また、 CloudWatch でメトリクスの異常検出 を有効にすることもできます。これにより、統計アルゴリズムと機械学習アルゴリズムを適用して、メトリクスを継続的に分析し、通常のベースラインを決定し、最小限のユーザー操作で異常を検知します。 図 9: CloudWatch の Anthropic Claude v1 メトリックと Anthropic Claude v2 メトリクスを含む積み上げ型面グラフで 15 分間の呼び出し数を示すビジュアライゼーション。 Bedrockが提供するランタイムメトリクスを以下に示します。 こちら でも確認できます。 メトリクス名 単位 説明 Invocations SampleCount InvokeModelもしくはInvokeModelWithResponseStreamのAPI操作によるリクエストの数 InvocationLatency MilliSeconds モデル実行のレイテンシー InvocationClientErrors SampleCount クライアントサイドのエラーに至ったモデル実行の数 InvocationServerErrors SampleCount サーバサイドのエラーに至ったモデル実行の数 InvocationThrottles SampleCount システムがスロットリングしたモデル実行の数 InputTokenCount SampleCount 入力テキストのトークン数 OutputTokenCount SampleCount 出力テキストのトークン数 ContentFilteredCount SampleCount 出力テキストコンテントがフィルターされた数 OutputImageCount SampleCount 出力画像の数 これらの指標は、次のようなさまざまなユースケースに使用できます。 InvocationLatency メトリクスと ModelID ディメンションを使用して、異なるモデル間のレイテンシーを比較します。 InputTokenCount と OutputTokenCount を分析してトークン数 (入力と出力) を測定し、プロビジョニングされたスループットの購入に役立てます InvocationThrottles メトリクスを使ってスロットリングを検出し、 CloudWatch アラームによってアラートを発信します 表示をシンプルにするために、BedrockがCloudWatchに送信するログとメトリクスは、CloudWatchダッシュボードを使用して単一のビューとして表示できます。複数の AWS アカウントをお持ちの場合は、CloudWatch のクロスアカウントオブザーバビリティを設定して、モニタリングアカウントに豊富なクロスアカウントダッシュボードを作成できます。 図 10: CloudWatch Dashboard には、モデル別の呼び出し数、モデル別の呼び出しレイテンシー、入出力別のトークン数、モデル呼び出しログからの最新のプロンプトが表示されます。 上のダッシュボードには、以下の情報が表示されています。 モデル別の呼び出し回数の推移 モデル別の呼び出しレイテンシー 入力トークンと出力トークン別のトークン数 モデル、操作、入出力トークンの数を示す呼び出しログの最新のプロンプト 結論 このブログでは、CloudWatch で Bedrock を監視し、基盤モデルと生成系 AI アプリケーションの使用状況に関する洞察を得る方法を示しました。Bedrock は、主要な AI プロバイダーの基盤モデルを使用して、生成系 AI アプリケーションの開発とスケーリングを簡単に行えるフルマネージド型サービスです。CloudWatch と統合して、メトリクスとログによるほぼリアルタイムの監視、監査、使用状況分析機能を提供します。Bedrock は CloudWatch との統合により透明性と制御を実現しつつ、大規模な生成系AI アプリケーションの構築を簡素化します。 原文は こちら をご覧ください このブログ記事は機械学習ソリューションアーキテクトの卜部が翻訳しました。

Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、ストリーミングデータの処理方法を簡素化する、完全に管理された可用性の高い Apache Kafka サービスを提供します。Apache Kafka を使用するときの一般的なアーキテクチャパターンは、あるクラスターから別のクラスターにデータを複製することです。 クロスクラスターレプリケーションは、事業継続とディザスタリカバリ計画を実施し、 AWS リージョン 全体でアプリケーションの回復力を高めるためによく使用されます。マルチリージョンアプリケーションを構築する際のもう一つのユースケースは、より低遅延なアクセスのために、複数の地域にあるストリーミングデータのコピーをエンドコンシューマーにより近い場所に保存させることです。また、分析のために、複数のクラスターのデータを 1 つの一元化されたクラスターに集約する必要がある場合もあります。 これらのニーズに対応するには、カスタムコードを書くか、バージョン 2.4 から Apache Kafka の一部として利用できる MirrorMaker 2.0 のようなオープンソースのツールをインストールして管理する 必要があります。しかし、これらのツールは、信頼性の高いレプリケーションのためのセットアップが複雑で時間がかかる場合があり、継続的な監視とスケーリングが必要です。 10月18日、 MSK レプリケータ をご紹介します。Amazon MSK のこの新しい機能は、MSK クラスター間の クロスリージョン および 同一リージョン のレプリケーションを確実にセットアップすることを容易にし、ワークロードを処理するために自動的にスケーリングします。MSK レプリケータは、 階層型ストレージ を使用するものを含め、プロビジョニングされた MSK クラスタータイプと サーバーレス MSK クラスタータイプの両方で使用できます。 MSK レプリケータを使用すると、アクティブパッシブとアクティブアクティブの両方のクラスタートポロジをセットアップして、リージョン間の Kafka アプリケーションの回復力を高めることができます。 アクティブ・アクティブ 設定では、両方の MSK クラスターがアクティブに読み取りと書き込みを処理しています。 アクティブ・パッシブ 設定では、一度に 1 つの MSK クラスターだけがストリーミングデータをアクティブに処理し、もう一方のクラスターはスタンバイ状態です。 ここで、実際にどのように機能するか見てみましょう。 AWS リージョン間での MSK レプリケータの作成 2 つの MSK クラスターを異なるリージョンにデプロイしています。MSK レプリケータでは、クラスターで IAM 認証が有効になっている必要があります。他のクライアントでは、mTLS や SASL などの他の認証方法を引き続き使用できます。ソースクラスターでは、マルチ VPC プライベート接続も有効にする必要があります。 ネットワークの観点から、クラスターのセキュリティグループは、クラスターとレプリケータが使用するセキュリティグループ間のトラフィックを許可します。例えば、同じセキュリティグループからのトラフィックと同じセキュリティグループへのトラフィックを許可する自己参照のインバウンドルールとアウトバウンドルールを追加できます。簡単にするために、両方のクラスターで デフォルトの VPC とその デフォルトのセキュリティグループ を使用します。 レプリケータを作成する前に、ソースクラスターの クラスターポリシー を更新して、MSK サービス (レプリケータを含む) がクラスターを見つけて到達できるようにします。 Amazon MSK コンソールで 、ソースリージョンを選択します。ナビゲーションペインから [ クラスター ] を選択し、次にソースクラスターを選択します。まず、一番上にあるソースクラスター ARN をコピーします。次に、[ プロパティ ] タブで、[ セキュリティ設定 ] の [ クラスターポリシーの編集 ] を選択します。そこで、次の JSON ポリシー (ソースクラスター ARN を置き換える) を使用して変更を保存します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "kafka.amazonaws.com" }, "Action": [ "kafka:CreateVpcConnection", "kafka:GetBootstrapBrokers", "kafka:DescribeClusterV2" ], "Resource": "<SOURCE_CLUSTER_ARN>" } ] } コンソールでターゲットリージョンを選択します。ナビゲーションペインから「 レプリケータ 」を選択し、「 リプリケータの作成 」を選択します。ここに、レプリケータの名前と説明を入力します。 ソースクラスターセクションで 、ソース MSK クラスターのリージョンを選択します。次に、[ ブラウズ ] を選択して、リストからソース MSK クラスターを選択します 。レプリケータは、クラスターポリシーが設定されているクラスターに対してのみ作成できることに注意してください。 デフォルトの VPC とそのデフォルトのセキュリティグループを使用するために、 サブネット と セキュリティグループ をデフォルト値のままにしています。このネットワーク設定を使用して、クラスターとの通信を円滑にするエラスティックネットワークインターフェイス (EIN) を配置できます。 ソースクラスターのアクセス制御方法 は IAM ロールベース認証 に設定されています。オプションで、複数の認証方式を同時にオンにして、リプリケータが IAM を使用している間も、mTLS や SASL などの他の認証方式を必要とするクライアントを引き続き使用できます。クロスリージョンレプリケーションでは、ソースクラスターへのアクセスに複数の VPC を使用するため、ソースクラスターは認証なしアクセスを有効にすることはできません。 ターゲットクラスターセクション では、 クラスターリージョン がコンソールを使用しているリージョンに設定されています。[ ブラウズ ] を選択して、リストからターゲット MSK クラスター を選択します。 ソースクラスターで行ったことと同様に、 サブネット と セキュリティグループ はデフォルト値のままにしておきます。このネットワーク設定を使用して、ターゲットクラスターとの通信に必要な ENI を配置します。 ターゲットクラスターのアクセス制御方法 も IAM ロールベース認証 に設定されています。 レプリケータ設定セクション では、デフォルトの トピックレプリケーション 構成を使用して、すべてのトピックがレプリケートされるようにします。オプションで、複製するトピックまたは複製から除外するトピックの名前を示す正規表現のカンマ区切りリストを指定できます。 追加設定 では、トピック設定、 アクセスコントロールリスト (ACL) のコピー、および新しいトピックの検出とコピーを選択できます。 コンシューマー・グループ・レプリケーション では、コンシューマーグループのオフセットをレプリケートするかどうかを指定できます。これにより、スイッチオーバー後、コンシューマーアプリケーションは、プライマリクラスター内で処理を中断した場所の近くで処理を再開することができます。複製する、または複製から除外するコンシューマーグループの名前を示す正規表現のカンマ区切りリストを指定できます。また、新しいコンシューマーグループを検出してコピーすることもできます。すべてのコンシューマーグループを複製するデフォルト設定を使用しています。 [ 圧縮 ] では、複製されるデータに使用できる圧縮タイプのリストから [ なし ] を選択します。 Amazon MSK コンソールは、レプリケータが機能するために必要な権限を持つサービス実行ロールを自動的に作成できます。この役割は、MSK サービスがソースおよびターゲットクラスターに接続し、ソースクラスターから読み取り、ターゲットクラスターに書き込むために使用されます。ただし、自分でロールを作成して提供することもできます。[ アクセス権 ] では、「 IAM ロールを作成または更新 」を選択します。 最後に、レプリケータにタグを追加します。タグを使用して、リソースを検索してフィルタリングしたり、コストを追跡したりできます。[ レプリケータタグ ] セクションでは、キーとして [ 環境 ]、値として [ AWS ニュースブログ ] と入力します。[ 作成 ] を選択します。 数分後には、レプリケータが実行されています。使ってみましょう! AWS リージョン間での MSK レプリケータのテスト ソースクラスターとターゲットクラスターに接続するために、2 つのリージョンに既に 2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをセットアップしました。 MSK ドキュメントの指示に従って Apache Kafka クライアントツールをインストールしました。IAM 認証を使用しているため、2 つのインスタンスには、クラスターの接続、送受信を可能にする IAM ロールがアタッチされています。ネットワークを簡素化するために、EC2 インスタンスと MSK クラスターには デフォルトのセキュリティグループ を使用しました。 まず、ソースクラスターに新しいトピックを作成し、いくつかのメッセージを送信します。 Amazon EC2 Instance Connect を使用して、ソースリージョンの EC2 インスタンスにログインします。ディレクトリを Kafka クライアント実行ファイルがインストールされているパスに変更します (パスは使用するバージョンによって異なります)。 cd /home/ec2-user/kafka_2.12-2.8.1/bin ソースクラスターに接続するには、そのブートストラップサーバーを知る必要があります。ソースリージョンの MSK コンソールを使用して、ナビゲーションページから [ クラスター ] を選択し、リストからソースクラスターを選択します。[ クラスターの概要 ] セクションで、[ クライアント情報の表示 ] を選択します。そこで、 ブートストラップサーバー のリストをコピーします。EC2 インスタンスはクラスターと同じ VPC にあるため、 プライベートエンドポイント (シングル VPC) 列のリストをコピーします。 EC2 インスタンスに戻り、ブートストラップサーバーのリストを SOURCE_BOOTSTRAP_SERVERS 環境変数に入れました。 export SOURCE_BOOTSTRAP_SERVERS=b-2.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-3.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-1.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098 次に、ソースクラスターにトピックを作成します。 ./kafka-topics.sh --bootstrap-server $SOURCE_BOOTSTRAP_SERVERS --command-config client.properties --create --topic my-topic --partitions 6 新しいトピックを使用して、ソースクラスターにいくつかのメッセージを送信します。 ./kafka-console-producer.sh --broker-list $SOURCE_BOOTSTRAP_SERVERS --producer.config client.properties --topic my-topic >アメリカからこんにちは >これらは私のメッセージである ターゲットクラスターで何が起こるか見てみましょう。ターゲットリージョンの EC2 インスタンスに接続します。他のインスタンスで行ったのと同様に、ターゲットクラスターのブートストラップサーバーのリストを取得し、 TARGET_BOOTSTRAP_SERVERS 環境変数に入力します。 ターゲットクラスターでは、ソースクラスターエイリアスがレプリケートされたトピック名のプレフィックスとして追加されます。ソースクラスターエイリアスを見つけるには、MSK コンソールのナビゲーションペインで [ レプリケータ ] を選択します。そこで、先ほど作成したレプリケータを選択します。[ プロパティ ] タブの [ ソースクラスター ] セクションで クラスターエイリアス を検索します。 ターゲットクラスター内のトピックのリスト (出力リストの最後のもの) を見て、複製されたトピックの名前を確認します。 ./kafka-topics.sh --list --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --command-config client.properties . . . us-cluster-c78ec6d63588.my-topic ターゲットクラスターで複製されたトピックの名前がわかったので、最初は送信元クラスターに送信されたメッセージを受信するためにコンシューマーを起動します。 ./kafka-console-consumer.sh --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --consumer.config client.properties --topic us-cluster-c78ec6d63588.my-topic --from-beginning アメリカからこんにちは これらは私のメッセージである プレフィックスを自動的に処理し、ソースクラスターとターゲットクラスターで同じ構成を持つために、トピックサブスクリプションでワイルドカード (例えば、 .*my-topic ) を使用できることに注意してください。 予想どおり、ソースクラスターに送信したすべてのメッセージは、ターゲットクラスターに接続しているコンシューマーによって複製および受信されました。 [ 監視 ] タブを使用して、MSK レプリケータのレイテンシー、スループット、エラー、およびラグのメトリックを監視できます。これは Amazon CloudWatch を通じて機能するため、独自の アラーム を簡単に作成し、これらのメトリックスを ダッシュボード に含めることができます。 構成をアクティブアクティブなセットアップに更新するために、同様の手順でもう一方のリージョンにレプリケータを作成し、もう一方の方向のクラスター間でストリーミングデータをレプリケートします。フェイルオーバーとフェイルバックの管理方法の詳細については、 MSK レプリケータのドキュメント を参照してください。 利用可能なリージョンと料金 MSK レプリケータ は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、欧州 (フランクフルト)、欧州 (アイルランド) の各 AWS リージョンでご利用いただけます。 MSK レプリケータでは、複製されたデータの GB 単位と、各レプリケータの時間単位の料金を支払います。また、ソースとターゲットの MSK クラスターに対する Amazon MSK の通常料金と、リージョンをまたぐデータ転送に対する標準的な AWS 料金を支払います。詳しくは、 MSK の料金表 をご覧ください。 MSK レプリケータを使用すれば、クロスリージョンや同一リージョンのレプリケーションを迅速に実装して、アーキテクチャの耐障害性を向上させ、パートナーやエンドユーザーの近くにデータを保存できます。また、この新機能を使用して、分析を実行しやすい単一の集中型クラスターにストリーミングデータを複製することで、より優れた洞察を得ることもできます。 Amazon MSK レプリケータを使用してデータストリームアーキテクチャを簡素化します。 — Danilo 原文は こちら です。

イントロダクション ヘルスケア領域は、生成系AIの活用が最も期待される領域の一つです。今年5月に報告されたボストンコンサルティンググループ（ BCG, 2023 ）の調査では、ヘルスケア領域における生成系AI市場は2027年までに年平均成長率（CAGR）85％で拡大する見通しと報告されています。 この領域の中でも特に、製薬企業の生成系AIに対する関心度は非常に高く、PwCコンサルティングが日本で実施した「 生成系AIに関する実態調査2023 」では、製薬企業の医療情報担当者（MR）を含む医療系専門職の58％が将来的に生成系AIに業務代替される可能性があると回答しており、今後のビジネスモデルや働き方改革に大きな影響をもたらすことを示唆しています。 生成系AIは、そのベースに基盤モデルというAIモデルを活用しています。基盤モデルは、テキスト、メディア（ビデオ、画像、音声）、プログラミングコードなど膨大、かつ、多様なラベルなしの非構造データをもとに訓練された大規模AIモデルです。 生成系AIの特徴は、この基盤モデルを利用し、様々なAIアプリケーションを開発することができることです。生成系AIの一つであるChatGPTは、膨大なテキストデータを学習したLLMであり基盤モデルの応用の一つです。このようなLLMを利用した生成系AIは、分類、編集、要約、質問への回答、新しいコンテンツの下書きなどの作業を行うことができるため、特にビジネス利用での期待が高いと考えられています。この寄稿では3回に分けて、製薬企業でLLMの効果が大きく期待できる業務部門を四つに分け、情報の検索・抽出、チャットボット、SOP（Standard Operating Procedure）ほか各種文書などドラフト作成、社内ガイダンスとの検証といった様々なユースケースについて整理し、AWSが提供する生成系AIサービスと共に解説していきます。 ユースケース＃1：臨床開発 膨大な申請資料の作成、検証、データクリーニングを効率化し、文書管理プロセスをモダナイズする 研究開発にかかる長大な期間のうち半分近くは、実際に医薬品を人に投与し、その安全性や効果を検証していく臨床試験のプロセスに割かれています。臨床開発業務は、医薬品医療機器等法に基づき厳密な規制やガイドラインに準じて行われ、常に詳細な情報と正確性が求められています。そのため、試験実施期間中に臨床データについて医師から提供される症例報告書（CRF）は、データの信頼性を担保するため、記載されたデータに誤りや不整合がないかを確かめるデータクリーニングという作業が実施されています。 通常、この作業には1カ月程度の時間が必要とすることが多いのですが、データクリーニング作業にAI・機械学習（ML）を活用することで、作業期間が22時間に短縮されたという事例が報告されています（ Pfizer, 2020 ）臨床試験が終了すると今度は試験の目的、方法、成績等をまとめた治験総括報告書（CSR）など当局申請に用いる大量の文書作成が必要となります。メディカルライティングという業務で文書作成には大変な費用と労力がかかります。 そこで、この作業に生成系AIを活用し、ドラフト初期の段階で文書作成を一定程度、自動生成に任せることで、大幅な作業時間短縮を図る検証が実施されています。海外では既に複数の企業からCSRの作成を生成系AIで支援するサービスが提供されており、メディカルライターの業務時間を60％以上短縮できるという内容も報告されています（ Narrative ） 臨床開発業務のもう一つの特徴は、各種関連法規制において、業務手順などの過程を示した文書の整備が義務付けられていることです。臨床開発部門では、ポリシー、マニュアル、SOP、テンプレートといった文書があるべき文書階層構造（ヒエラルキー）に基づき作成され、管理されています。しかし、近年の製薬業界ではグローバルの規制内容統一に向けた法規改正、パイプライン確保のためのM＆A（合併・買収）、自社製造拠点の統廃合や売却、製造工程が複雑なバイオ医薬品の増加など様々な要因から、SOPの新規作成、更新の作業が増えています。さらに、文書作成の前段階となるヒエラルキー内で影響を受ける文書の分析、評価についても多くの負担が発生していることが想像できます。しかし、このような文書業務の多くは、担当者自身のライティング、幾重もの部門内レビュー、チェックを経て完了されています。 これらのアナログな文書作成プロセスに対して生成系AIを利用することで、新規に作成した文書のロジックエラーを自動的に判別し、不整合箇所を解説ガイダンスと共に提示するソリューションを開発することも可能になります。生成系AIを利用した文書アプリケーションを開発することで、社内ガイダンス、文書ヒエラルキーに適合した文書を素早く作成し、大きく業務プロセスを改善できる可能性があります。 ユースケース＃2：ファーマコビジランス AIアプリケーションがSNS上の有害事象を検知する 製薬企業は、自社薬剤の投与結果（特に安全性）に関する情報を日々収集、分析、評価し、当局に速やかに報告することが義務付けられています。加えて、新型コロナウイルス感染症の拡大以降、患者や医療関係者を含む一般消費者のSNSが利用拡大したことで、医薬品医療機器総合機構（PMDA）は安全対策を充実するため情報の入手経路の多様化の推進を検討しており、製薬企業もSNS、インターネット情報を医薬品の品質不良、有害事象のモニタリング対象として積極的に考えるようになっています。（ PMDA, 2022 ）このような状況で、製薬企業の報告件数、1件当たりの作業負荷は急激に増加しており、業務を担当するファーマコビジランス部門は、さらなる業務の効率化、コスト管理が求められています。 この課題に対して、AWSを活用する顧客の1社であるノバルティスファーマでは、自然言語処理（NLP：Natural Language Processing）を使用したプログラムを開発することで有害事象（AE）の検出能力を上げることに取り組んでいます。AI・MLを利用した検知プログラムによってSNS内の潜在的なAEの記載をモニタリングし、AEと疑わしい文章が自動的に検知された場合には、さらに感情分析を用いて内容を評価しています。該当したメッセージ部分にはフラグを付けて分析の結果を表示し、社内での効率的なレビューを可能にしています。 この検知プログラムを用いることで、現在では約1万5000件／週のメッセージを処理することができており、これまで人の手によって確認していたそれよりもはるかに多くのデータを収集し、製薬企業が果たすべきAEモニタリング全体の質を高めています。（ AWS, 2021 ） 次号、Part.2では「マーケティング、メディカルアフェアーズ部門」のユースケースについて考察します。 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で20年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブとBBQ。

AWS re:Invent 2023 の開催まで残すところ 41 日となった今、私は AWS News Blog チームと連携して、皆さんに楽しく読んでいただける新しい最高の記事をたくさん作成することに集中すべく、全力投入しています。 今朝はひと休みして、先週の最もエキサイティングなリリースや、その他のニュースを共有したいと思います。では始めましょう! 10月9日週のリリース 以下は、私が関心を持ったリリースの一部です。 Amazon EBS – 新しい CloudWatch メトリクスである Attached EBS Status Check では、特定の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされたすべての Amazon Elastic Block Store (Amazon EBS) ボリュームのステータスを監視して、それらのボリュームが到達可能であり、I/O 操作を完了できることを確認することができます。 AWS Systems Manager – 組織内のすべての EC2 インスタンスに対して、 AWS Systems Manager をデフォルトで有効化 できるようになりました。これにより、すべての新規および既存インスタンスに Systems Manager のコア機能が存在することを確認できるようになります。 Amazon EC2 – 未使用または古くなった AMI を無効化状態に設定 できるようになりました。これは、AMI が以前共有されていた場合にその AMI をプライベートにし、デフォルトで DescribeImages の対象外として、そこから新しいインスタンスが起動されないようにします。 Amazon Textract – ビジネス固有のドキュメントの抽出精度を向上させるために、 カスタムクエリ を使用して Textract のクエリ機能を適合させることができるようになりました。サンプルドキュメントをアップロードし、データにラベルを付け、アダプターを生成してから、それを AnalyzeDocument 関数の呼び出しで使用します。 Amazon OpenSearch Service – クエリと結果の処理を容易にする 検索パイプラインを作成 できるようになりました。各 検索パイプライン には、クエリリライター、自然言語プロセッサ、結果リランカー、およびフィルターといった複数の処理ステップを含めることができ、いくつかの 標準プロセッサ も含まれています。 Amazon Linux 2 – Amazon Linux 2 の最新四半期リリース (AL2023.2) には、 Ansible のコア機能セットと、キュレーションされた一連のコミュニティコレクションが含まれています。また、 Amazon Corretto 21 と、 その他多くの新機能 も含まれています。 Amazon Rekognition – カスタムアダプタを訓練 して Amazon Rekognition がフラグする偽陽性と偽陰性の数を減らすことが可能になり、特定のユースケースに対するパフォーマンスを向上させるために深層学習モデルをカスタマイズすることができるようになりました。 Amazon RDS – Amazon Relational Database Service (RDS) が、M6in、M6idn、R6in、および R6idn の各データベースインスタンスで PostgreSQL、MySQL、および MariaDB データベースを サポートするようになりました 。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 M6in および M6idn インスタンス : アジアパシフィック (シドニー) および欧州 (ストックホルム)。 C7gd、M7gd、および R7gd インスタンス : アジアパシフィック (シンガポール、東京)。 C7gd インスタンス : アジアパシフィック (シドニー)。 AWS マネジメントコンソールの統一設定 : AWS GovCloud (米国) リージョン。 AWS Direct Connect : 韓国、ソウル。 AWS Global Accelerator : ベトナム、ハノイ (2 番目のロケーション)。 Amazon FSx for NetApp ONTAP : アジアパシフィック (大阪)。 AWS Organizations サービスコントロールポリシー : AWS 中国リージョン。 AWS Verified Access : アジアパシフィック (シンガポール、東京)。 AWS マネジメントコンソールへのプライベートアクセス : イスラエル (テルアビブ)。 Amazon RDS Custom for Oracle : アジアパシフィック (ジャカルタ)。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログでは、Seth Eliot が AWS re:Invent で見逃したくない 12 のレジリエンスセッション をリストアップし、Brooke Jamieson が 生成系 AI をゼロから学ぶ方法 を説明して、Daniel Wirjo が Amazon Bedrock で生成系 AI アプリケーションを構築するためのパターン をいくつか紹介しました。 AWS インサイトブログでは、同僚のニュースブロガーである Irshad Buchh が、 20 億の Terraform AWS Provider ダウンロード数がインフラストラクチャ管理のための IaC の価値を証明する 理由を説明しました。 AWS IoT ブログは、 マルチアカウント戦略を使用して AWS でスケーラブルなマルチテナント IoT SaaS プラットフォームを構築する方法 を説明しました。 Amazon SES ブログは、 Amazon Pinpoint を使用して、リアルタイムのカスタマーデータでマーケティングキャンペーンを自動化する 方法を紹介しました。 AWS ビッグデータブログは、 AWS Step functions を使用して Amazon EMR Serverless ジョブをオーケストレーションする 方法を紹介しました。 AWS コンピューティングブログでは、 ワイルドカードパターンマッチングを使用した Amazon EventBridge でのイベントのフィルタリング について説明しました。 AWS ストレージブログでは、 Amazon EBS Snapshots Archive を使用した、コンプライアンスのための Amazon EC2 AMI スナップショットの保持 について説明しました。 AWS アーキテクチャブログでは、インターネット旅行サービスである ITS が、飛行機旅行検索エンジンを改善するためにマイクロサービスアーキテクチャを取り入れている 方法について説明しました。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Day – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。 イタリア (10 月 18 日)、 UAE  (10 月 21 日)、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)。 AWS Innovate: Every Application Edition  – 無料のオンラインカンファレンスに参加して、セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 19 日の AWS Innovate Online アメリカ地区 と EMEA 、および 10 月 26 日の AWS Innovate Online アジアパシフィックと日本 に登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください 。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent のハイライト をチェックしてください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 今日はこれでおしまいです。10月23日週の Weekly Roundup もお楽しみに! – Jeff ; この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS は10月15日、 汎用 Amazon EC2 M7i インスタンス と コンピューティング最適化 Amazon EC2 C7i インスタンス の 2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをラインアップに導入しました。 今日は、メモリ最適化 Amazon EC2 R7i インスタンスを追加するために x86 ベースの第 7 世代製品が拡大されることをお知らせしたいと思います。これらのインスタンスには、AWS 限定のカスタム第 4 世代 Intel Xeon スケーラブルプロセッサ (Sapphire Rapids) が搭載されており、クラウド内にある同等の第 4 世代 Intel プロセッサの中でも最も優れたコンピューティングパフォーマンスを提供します。R7i インスタンスは、2 つのベアメタルサイズ (近日提供予定) を含めた 11 サイズで利用でき、Amazon EC2 R6i インスタンスよりも 15% 高い価格パフォーマンスを提供します。 Amazon EC2 R7i インスタンスは SAP 認定を受けており、ハイパフォーマンスデータベース (SQL および NoSQL データベース)、分散型ウェブスケールインメモリキャッシュ (Memcached および Redis)、インメモリデータベース (SAP HANA)、リアルタイムのビッグデータ分析 (Apache Hadoop および Spark クラスター)、その他エンタープライズアプリケーションなどのメモリ集約型ワークロードに最適です。Amazon EC2 R7i は、仮想インスタンスとベアメタルインスタンスの両方を含めた、最大 192 個の vCPU と 1,536 GiB のメモリを搭載するより大規模なインスタンスサイズ (48xlarge) を提供することで、ワークロードの統合とアプリケーションのスケールアップを可能にします。 各 R7i インスタンスには最大 128 個の EBS ボリュームをアタッチできます。これに対し、R6i インスタンスにアタッチできるボリュームの最大数は 28 個です。 以下は、R7i インスタンスの仕様です。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7i.large 2 16 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.xlarge 4 32 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.2xlarge 8 64 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.4xlarge 16 128 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.8xlarge 32 256 GiB 12.5 Gbps 10 Gbps r7i.12xlarge 48 384 GiB 18.75 Gbps 15 Gbps r7i.16xlarge 64 512 GiB 25 Gbps 20 Gbps r7i.24xlarge 96 768 GiB 37.5 Gbps 30 Gbps r7i.48xlarge 192 1,536 GiB 50 Gbps 40 Gbps AWS では、2 つのサイズのベアメタル R7i インスタンスを近日リリースする準備も進めています。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7i.metal-24xl 96 768 GiB 最大 37.5 Gbps 最大 30 Gbps r7i.metal-48xl 192 1,536 GiB 最大 50.0 Gbps 最大 40 Gbps 内蔵アクセラレータ Sapphire Rapids プロセッサには 4 つの内蔵アクセラレータが搭載されており、それぞれが特定のワークロードのためのハードウェアアクセラレーションを提供します。 アドバンストマトリックスエクステンション (AMX) – AMX エクステンションは、マトリックス演算を伴う機械学習やその他のコンピューティング集約型ワークロードを加速化するように設計されています。これは、マトリックス計算のためにカスタマイズされた特殊なハードウェア命令とレジスタを提供することで、マトリックス演算の効率性を向上させます。積と畳み込みなどのマトリックス演算は、さまざまな計算タスク、特に機械学習アルゴリズムにおける基本的な構成要素です。 インテルデータストリーミングアクセラレータ (DSA) – DSA は、さまざまなアプリケーションのデータ処理および分析機能を強化し、デベロッパーがデータ主導型ワークロードの可能性を最大限に活用できるようにします。DSA を使用することで、データ集約型タスクに対して並外れたパフォーマンスを提供する、最適化されたハードウェアアクセラレーションを利用できるようになります。 インテル In-Memory Analytics Accelerator (IAA) – このアクセラレータは、データベースと分析ワークロードをより高速に実行し、電力効率を向上させる可能性を秘めています。非常に高いスループットでのインメモリ圧縮、解凍、暗号化と、一連の分析プリミティブは、インメモリデータベース、オープンソースデータベース、および RocksDB や ClickHouse などのデータストアをサポートします。 インテル QuickAssist テクノロジー (QAT) – このアクセラレータは、暗号化、復号、圧縮をオフロードすることで、プロセッサコアを解放し、電力消費量を削減します。また、単一のデータフローでの圧縮と暗号化のマージもサポートします。詳細については、まず「 Intel QuickAssist Technology (Intel QAT) Overview 」をご覧ください。 アドバンストマトリックスエクステンションは、すべての R7i インスタンスサイズでご利用いただけます。インテル QAT、インテル IAA、およびインテル DSA アクセラレータは、r7i.metal-24xl および r7i.metal-48xl インスタンスで利用可能になる予定です。 今すぐご利用いただけます 新しいインスタンスは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (スペイン)、欧州 (ストックホルム)、および欧州 (アイルランド) の各 AWS リージョンでご利用いただけます。 購入オプション R7i インスタンスは、オンデマンドインスタンス、リザーブドインスタンス、Savings Plan、スポットインスタンスの形式で提供されています。R7i インスタンスは、専有ホストおよび専有インスタンスの形式での利用も可能です。 – Irshad 原文は こちら です。

Amazon Pinpoint でマルチテナンシーを実現するアプローチ ビジネスは常に進化しており、複数の製品ライン、顧客セグメント、あるいは地理的なロケーションを管理することも少なくありません。さらに、独立系ソフトウェアベンダー (ISV) である企業間取引 (B2B) 企業の多くは、顧客のマーケティングオートメーション環境を管理する必要があります。このような複雑性から、効率的に適応・拡張できる強固な顧客エンゲージメント戦略が必要になります。しかし、テナントごとにバラバラのシステムを管理は手間なだけでなく、リソースを大量に消費し、運用コストの増加や潜在的なデータのサイロ化につながります。Amazon Pinpoint のマルチテナント設定は、これらの課題に取り組み、企業が統一されたアーキテクチャの下で顧客エンゲージメント活動を効率的に実現します。 実現のポイントは、マルチテナントを採用するかどうかだけではなく、お客様固有のビジネス要件に合わせてどのように実装するかです。 Amazon Pinpoint では、これを実現するために複数のアプローチを用意しています。 このブログでは次の 3 つについて説明します。 Single Account / Single Pinpoint Project (SA/SP) : 1 つのアカウントで、1 つのPinpoint Project を用意する方法になり、シンプルに実現できます。ただし慎重な権限管理が必要です。 Single Account / Multiple Projects (SA/MP) : 1 つのアカウントで複数の Pinpoint Project を用意する方法になり、きめ細かな管理が可能です。ただしクォータによる制限が存在します。 Multiple Accounts / Multiple Projects (MA/MP) : マルチアカウントで複数の Pinpoint Project を用意する方法になり、拡張性が非常に高くなります。ただし包括的な監視が必要になります。 それぞれの長所、短所、最適なユースケースを掘り下げ、配信チャネルの要件に応じて異なるマルチテナンシー構成を選択する方法についても掘り下げることで、アーキテクチャの判断ができます。 このブログを通して、検討の複雑さを解消し、ビジネス目標に合わせて Amazon Pinpoint のアーキテクチャ設計に役立てることができます。 Single Account / Single Pinpoint Project (SA/SP) 概要 Single Pinpoint Project のセットアップでは、すべてのカスタマーのアクテビティが 1 つのプロジェクト内に存在します。この場合のマルチテナントの実装方法は、顧客の エンドポイント属性 が活用できます。これを活かすことで、Amazon Pinpoint を初めて使用する人でも簡単に管理ができます。この場合の設定例を以下に示します。 1つの Pinpoint Project を用意し、複数のテナントの情報を管理する場合、エンドポイントの カスタムユーザー属性 を利用してテナント情報を管理することができます。また、キャンペーン情報の タグ機能 を利用することで、テナントごとにキャンペーン情報を管理することができます。この設定を行うために必要な要素を以下に示します。 顧客データを保持する S3 バケット Pinpoint にインポートする顧客情報リストを保存する S3 バケットを用意します。Amazon Pinpoint では S3 に配置した CSV ファイルをセグメントとして インポート することができます。Amazon Pinpoint でテナントごとの設定を行うため、テナント情報を カスタムユーザー属性 として CSV ファイルに記載します。 1 つの Amazon Pinpoint プロジェクト Amazon Pinpoint Project を 1 つ 作成 します。 配信するチャネルごとの 設定 をします。 テナント情報には タグ機能 でキャンペーン情報を割り当てることができます。 Amazon Kinesis Amazon Pinpoint の イベントストリームの設定 を利用することで、Amazon Kinesis 経由で S3 に保存することができます。 イベントデータを分析するための Amazon Athena と S3 バケット Amazon Pinpoint のイベントデータを S3 に保存し、Athena 経由で分析します。 このソリューション を活用できます。 この構成を採用する際の注意点として、顧客のエンドポイント情報が同じ Pinpoint Project 内に存在することが挙げられます。カスタム属性など各テナントを識別できる値を指定し、 AWS Identity and Access Management(IAM) ポリシー で解決することも可能ですが、アクセス権や属性の管理は各自で行う必要があります。 また、 エンドポイントを追加する には、Channel と Address を指定する必要があります。1 つのプロジェクトで、異なるエンドポイントに同じ Channel と Address を指定することはできないため、注意が必要です。以上のことから、エンドポイントの Channel と Address がテナント間で重複しなければ、独自のアクセス許可制御を構築することが可能であるため、このパターンを検討することができます。 他のパターンに比べて必要なコンポーネントが少ないため、構成が容易になります。Pinpoint API を使い、Pinpoint 側の設定をできるだけ簡略化したいというお客様は、この方法を選択できます。しかし、この方法は、後にテナントが増えるにつれて管理が複雑になる可能性があります。例えば、テナントの詳細なレポートを作成したい場合に課題になる場合があります。Amazon Pinpoint プロジェクトで詳細なレポートを作成するには、各キャンペーンやジャーニーに専用のタグを設定する必要があります。 最後に、Amazon Pinpoint Project と AWS アカウントごとの サービスクォータ に注意し、ユースケースに応じて拡張性を持たせるようにしてください。 Single Account / Multiple Projects (SA/MP) 概要 このアーキテクチャでは、Amazon Pinpoint 環境を構築するために単一の AWS アカウントで、顧客またはテナントごとに複数のプロジェクトを作成します。この場合の構成例を図に示します。 この例では、複数の Amazon Pinpoint プロジェクトを作成します。 SA/SP の場合と大きく異なる点は、顧客のエンドポイント情報を完全に分離できることです。顧客データのセグメントをインポートする場合、S3 から対象の Pinpoint Project にインポートするだけで、各テナントを別々の状態で管理することが可能です。これにより、IAM ポリシーによる権限管理が容易になります。 また、Amazon Pinpoint では、該当アカウントで取得した送信用のメールアドレスや SMS 番号、メッセージテンプレートなどを全プロジェクト共通で利用することができ、プロジェクトごとのイベントデータを Amazon Kinesis 経由で集約することができます。このような構成をとることで、基本的な設定情報の管理やオペレーターの操作はそのままに、プロジェクトごとにエンドポイント情報を分離できるメリットが得られます。 この構成を設定するために必要な要素は下記になります。 顧客データを保持する S3 バケット SA/SPと同様に、Pinpoint にインポートする顧客情報のリストを格納する S3 バケットを用意します。インポートする CSV はプロジェクトごとに用意します。 Amazon DynamoDB テーブル Pinpoint のプロジェクト情報を管理するための DynamoDB（またはその他のキーバリューデータベース）テーブルを用意します。テナント情報などをメタデータとして DynamoDB テーブルに格納できます。 AWS Lambda Lambda を使用して Pinpoint のプロジェクトを 作成 します。Amazon Pinpoint では、 Amazon Pinpoint API 、 AWS SDK 、または AWS Command Line Interface (AWS CLI) を使用してプロジェクトを作成および設定することもできます。そのため、Pinpoint のプロジェクトと関連するキャンペーン/ジャーニーの作成を自動化することが可能です。テナント情報も作成時に DynamoDB に登録します。 複数の Amazon Pinpoint プロジェクト 上記の Lambda で作成した Project です。テナントごとに Pinpoint Project が存在することになり、エンドポイント情報が完全に分離されます。また、 IAM 機能 を利用することで、プロジェクトごとにアクセス権を制御することも容易です。 メッセージテンプレート ：テンプレートを作成し、プロジェクト間で共有することができます。 Amazon Pinpoint の イベントストリーム設定 を使うことで、キャンペーン、ジャーニー、アプリ、チャンネルのイベントを Amazon Kinesis にストリーミングできます。複数の Amazon Pinpoint プロジェクトを 1 つの Amazon Kinesis にストリームすることができます。正しくセットアップすると、イベントデータには関連するテナント情報がタグ付けされ、分析ソリューションでストリームを解析できるようになります。 イベントデータを分析するための Amazon Athena と S3 バケット Amazon Pinpoint のイベントデータは Amazon S3 に保存され、Amazon Athena を介して分析します。この場合、分析ソリューションである Amazon Athena を使うことで、テナントに応じたイベントデータのフィルタリングを行うことができます。詳細については、 このソリューション を参照してください。 注意点として、Pinpoint は、AWS アカウントあたり 100 プロジェクトというソフトリミット があります (サポートチケットで増やすことは可能です）。その他の クォータ も、プロジェクトとアカウントレベルで適用されるため、考慮する必要があります。 以上のことから、 SA/MP を使用する場合、アカウントごとのクォータに制限があること、個々のテナントのプロジェクト作成プロセスを自動化するには、より多くの初期設定が必要になることに注意する必要があります。しかし、 SA/SP アーキテクチャーと比較すると、より多様な顧客データをより安全に管理し、効率的に運用できることが期待できます。 Multiple Accounts / Multiple Projects (MA/MP) 概要 MA/MP のアプローチに入る前に、この構成における AWS Organizations の役割を理解することが重要です。AWS Organizations は、複数の AWS アカウントを 1 つの組織に統合し、ガバナンスとコストの一元化を実現できます。この機能は、単一の中央管理 AWS アカウントから複数の AWS アカウントと Amazon Pinpoint プロジェクトを効果的に管理できるため、 MA/MP セットアップで特に有用です。AWS Organizations の詳細については、AWS Organizations の 公式ドキュメント を参照してください。 MA/MP セットアップでは、顧客またはテナントごとにそれぞれの AWS アカウントを利用します。この場合の構成例を以下に示します。 この例では、Management アカウントを作成し、その下に複数の AWS アカウントを用意しています。Management アカウントでは AWS Account ID と Pinpoint Project ID を管理し、プロジェクトを Lambda で作成します。顧客データやイベントストリームデータは Management アカウントで管理し、各プロジェクトの情報を集約しています。この構成の大きなメリットは、個々のテナントのアクションを分離できることで、ノイジーネイバーなどのアンチパターンを防ぐことができます。また、単一の AWS アカウントでは処理できないクォータの制約からも解放されます。さらに、Amazon Pinpoint は CloudFormation のカバレッジに優れており、再現性の高いアーキテクチャを自動的にデプロイすることも可能です。 この設定の設定に必要な要素を以下に示します。 AWS Organizations 複数のアカウントを管理するために Organizations を設定します。複数のアカウントを設定するための ベストプラクティス を参照してください。 Management アカウント 複数のアカウント情報を管理するためのアカウントを作成します。アカウント間でリソースを操作する場合は、IAM ロールと サービスコントロールポリシー（SCP） を使用します。これにより、アカウントをまたいだアクセスが可能になります。必要な要素は前述の SA/MPと同じです。 顧客データを保持する S3 バケット : AWS では、アカウントをまたいで S3 データを利用できます。 クロスアカウント設定 を行い、顧客データを各アカウントにセキュアに紐付けられます。 Dynamo DB テーブル : AWS Account ID、Pinpoint Project ID、それに紐づく管理情報を保持します。 AWS Lambda : Lambda を使用して Pinpoint Project を作成します。 イベントデータを分析するための Athena と S3 バケット : 複数のアカウントや Pinpoint Project のイベント情報を集約して分析します。 テナントごとの AWS Account と Pinpoint Project テナントの分け方に応じて、AWS Account と Pinpoint Project を用意します。 AWS CloudFormation を利用したアカウント作成の自動化も検討できます。 アカウント毎に配信チャネルのメールアドレスや SMS 番号等を設定する必要がある場合があります。(詳細は次のセクションを参照) Amazon Kinesis はアカウント毎に用意されますが、俯瞰してレポーティングしやすいように全て Management アカウントの同じ S3 に保存させます。 注意点としては、アカウントが分かれているため、それぞれを管理する必要が出てくることです。例えば、新規作成したAWS アカウントはサンドボックス状態になり、サポートチケットによる本番利用申請がアカウントごとに必要になります。また、レピュテーションはすべて1つのAWS アカウントで行われるため、アカウントごとにレピュテーションを監視する必要もあります。 Amazon Pinpoint のチャネルごとのアプローチ : 提供サービスとアーキテクチャの整合性 マルチテナントのための Pinpoint アーキテクチャを選択するだけでなく、どのチャネルでサービスを提供するのが最適かを決定し、その決定がマルチテナンシーアーキテクチャの選択にどのように影響されるかを決定することが極めて重要です。以下に、マルチチャネル、マルチテナント構成に役立つ Amazon Pinpoint の機能と、各チャネルで注意すべき潜在的な課題について列挙します。 E メール E メールは、Amazon SES の 設定セット と E メールサプレッションリスト 機能と統合でき、最も汎用性の高いチャネルの 1 つです。3 つのマルチテナンシーモデルのいずれにも簡単に適応できます。 設定セット : 設定セットを使用すると、異なる IP プールや異なるイベント送信先を使用して、メール送信アクティビティを分離することができます。 設定セットは Amazon Pinpoint と Amazon SES の両方で使用できます。Amazon SES で設定した設定セットのルールは、Amazon Pinpoint を使用して送信するメールメッセージにも適用されます。 SA/SP および SA/MP : メールテンプレートと送信 IP アドレスは、Pinpoint プロジェクト内の各テナントの構成セットを使用してタグ付けする必要があります。 MA/MP : E メールテンプレートと送信 IP アドレスは、アカウントのデフォルトを使用して送信するか、設定セットを使用してきめ細かくタグ付けすることができます。 E メールサプレッションリスト : サプレッションリストはアカウントレベルで自動的に管理されます。または、特定の設定がアカウントレベルのサプレッションリストを 上書き できるかどうかを指定できます。 SA/SP および SA/MP すべてのテナントも同じ アカウントのサプレッションリスト に従います いずれかのテナントがハードバウンスまたは苦情を受けたEメールアドレスに E メールを送信すると、他のすべてのテナントも同じアドレスに E メールを送信できなくなります。 アカウントレベルのサプレッションリストは、 設定セットレベル で上書きできます。 MA/MP テナントの 1 人がハードバウンスされた E メールアドレスや苦情のある E メールアドレスに E メールを送信した場合、そのテナントが所属する AWS アカウントのみがサプレッションリストに従います。つまり他のAWSアカウントのテナントは、そのメールアドレスにメールを送信できます。 ノイジー・ネイバーの脅威 : 一般的に、あるテナントのパフォーマンスが他のテナントのアクティビティによって低下することを指します。このアンチパターンを E メールで検討する場合、1つの悪質なテナントが環境全体のメール送信アクティビティに影響を与えることを防ぐための対処が必要になります。ある顧客がバウンス率や苦情率の制限を超えた場合、その顧客への送信は一時停止されます。これは、違反の自動レビューのためにリージョンレベルで行われます。 SA/SP および SA/MP E メールのバウンス率やクレーム率はリージョンレベルで追跡されるため、1つの悪質なテナントからのバウンスや苦情が多い場合、アカウント全体のメール送信ドメインがブロックされる可能性があります。 このような事態を避けるためには、個々のテナントが高いバウンス、苦情率を示した場合に警告を発するよう、専用の設定セットとアラームを設定するのがベストプラクティスです。 MA/MP 最も隔離性が高く、E メール ID、ドメインが1つのテナント、アカウントによってのみ使用可能であることを保証します。 重要 : AWSのTrust and Safetyチームでは、手動でアカウントレベル、ドメインレベル、または複数のアカウントに跨いで確認することができ、メール送信の一時停止をすることができます。どのアーキテクチャを採用するかにかかわらず、すべてのテナントの送信アクティビティを責任を持って管理することがベストプラクティスとして推奨されます。 メール送信クォータ E メール日次送信クォータと E メール送信レート がアカウントレベルで表示されます。 SA/SP および SA/MP AWS アカウント内の全テナントの 1 日の送信クォータと送信レートの合計を予測し、それに応じてサービス制限を引き上げる必要があります。そのため、サービス制限のしきい値を正しく見積もるには、より多くの計画が必要になります。 MA/MP 各テナントが個別の AWS アカウントを使用するため、個々のテナントのニーズに応じてサービス制限を引き上げることができます。 個々のテナントが事前にメール送信クォータリクエストを通知し、それに応じてAWSアカウントでクォータリクエストが発生するように、ビジネスプロセスを整備することがベストプラクティスになります。 マルチテナント環境でのメール送信に関する詳細は、SES のマルチテナントに関する AWS ブログ を参照してください。 SMS 送信元アイデンティティの取得 : OID（電話番号）は AWS アカウントとリージョンに関連付けられています。 OID はアカウントやリージョンをまたいで利用することができないため、新しい AWS アカウントやリージョンごとに取得プロセスを繰り返す必要があります。 番号のプール : 電話番号や送信者 ID をグループ化する機能です。特に Single Project モデルで、テナントごとに通信をセグメント化するのに便利です。 設定セット : V2 SMS and Voice API のリリースにより、設定セットを使用して、マルチテナント環境の SMS オプトアウトリスト、OID、イベントストリーミング先を管理できるようになりました。 この方法の詳細については、 Amazon Pinpoint で設定セットを使用して SMS を送信する方法についてのブログ を参照してください。 ノイジー・ネイバーの脅威 SA/SP および SA/MP API 呼び出しで OID を指定しない場合、Amazon Pinpoint は (スループットと配信可能性の観点から) 最も適切な OID を使用して SMS を送信しようとすることに注意してください。 E メールと同様に、番号プールと設定セットを活用して、SMS 送信アクティビティを 1 つのアカウントに分離できます。 新しい OID をリクエストするにはコストと時間がかかるため、これによって SMS OID のレピュテーションを守ることができます。 MA/MP 最も分離され、1つのテナント、アカウントでのみ使用可能な番号を確保します。 SMS オプトアウト: メールチャネルのサプレッションリストと同様に、オプトアウトはアカウントと設定セットごとに管理されます。 そのため、 MA/MP 設定では、あるアカウントで配信をオプトアウトした顧客は、他のアカウントからの配信を引き続き受信することできます。 プッシュ通知 Amazon Pinpointは、FCM、APNS、Baidu Cloud Push、ADM などの様々なプッシュサービスと統合しています。 プロジェクトレベルの認証： 認証情報は Pinpoint のプロジェクトレベルで設定されるため、個別の管理が必要です。 異なるアプリケーションを使用する複数のテナントでは、 SA/SP アーキテクチャを使用することはできません。 詳細については、 モバイルプッシュガイド を参照してください。 アプリ内メッセージ Pinpoint のプロジェクトごとの設定：プッシュ通知と同様に、各 Pinpoint プロジェクトに設定できるアプリ内メッセージは 1 つだけです。 アプリ内メッセージを必要とするアプリケーションが複数ある場合は、 SA/SP アーキテクチャを採用できません。 詳細については、 アプリ内チャネルのドキュメント を参照してください。 カスタムチャネル Amazon Pinpoint のカスタムチャネルでは、サードパーティのサービスを含め、API を持つあらゆるサービスを通じてメッセージを送信できます。Amazon Pinpoint からカスタムチャネルを広範囲に使用する場合は、 AWS Lambda のサービス制限 、特に SA/SP または SA/MP アーキテクチャを検討している場合に注意する必要があります。 まとめ このブログでは、Amazon Pinpoint でマルチテナントを実装するための複雑な仕組みを紐解いてきました。今回のディープダイブでは、3つのアーキテクチャパターンを取り上げました。 Single Account/Single Project (SA/SP) : シンプルな管理を提供する初心者に優しいアプローですが、異なるテナント間で送信アクティビティを分離するためには、細心の注意を払って権限の管理が必要です。 Single Account/Multiple Projects (SA/MP) : 顧客データをきめ細かく管理できますが、管理の複雑さは若干増します。注意点として、クォータと潜在的な「ノイジーネイバー」問題になる可能性があります。 Multiple Accounts/Multiple Projects (MA/MP) : 管理の複雑さは増すものの、最も柔軟性と独立性が高い方法になります。 各アプローチには、管理・レポートの容易さ、拡張性、顧客データの管理に関するトレードオフがあります。また、マルチテナントの決定が Amazon Pinpoint のチャネル構成にどのような影響を与えるかについても検討しました。E メールや SMS からプッシュ通知まで、アーキテクチャの選択は、これらの配信チャネルをいかに効率的に管理できるかに直接影響します。これらの情報を活用することで、ビジネス目標に沿った意思決定を行うことができます。 次のステップ Amazon Pinpoint 環境のアーキテクティングと実装をします。このブログ記事で説明したベストプラクティスとアーキテクチャのガイドラインを指針として使用してください。今後、選択するアーキテクチャ構成は、ユーザー数、企業規模、または販売チャネルなど、特定のニーズに合わせて調整する必要があります。初期設定だけでなく、それぞれのサービス制限やクォータを含む長期的な管理面も考慮に入れてください。 関連リンク Amazon SES のマルチテナントに関する詳細: https://aws.amazon.com/blogs/messaging-and-targeting/how-to-manage-email-sending-for-multiple-end-customers-using-amazon-ses/ Amazon Pinpoint API ドキュメント: https://docs.aws.amazon.com/pinpoint/latest/apireference/welcome.html Amazon Pinpoint 開発者ガイド: https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html この記事は、 How to implement multi-tenancy with Amazon Pinpoint を翻訳したものです。翻訳は Solution Architect の 中村 達也 が担当しました。 著者について Tristan (Tri) Nguyen AWS の Amazon Pinpoint および Amazon Simple Email Service スペシャリスト・ソリューションアーキテクト。仕事では、企業システムにおける通信サービスの技術的実装とアーキテクチャ/ソリューション設計を専門とする。趣味はチェス、ロッククライミング、ハイキング、トライアスロン。     中村 達也（Nakamura Tatsuya） AWS でエンタープライズ企業を担当するソリューションアーキテクト。主に商社業界、流通・小売業界を担当し、日本のお客様向けに Amazon Pinpoint の導入支援も行っている。ERP 導入支援や複数の新規 Web サービス立ち上げなど、これまでのキャリアは多岐にわたる。

こんにちは！アマゾンウェブサービスジャパン合同会社  ソリューションアーキテクト の塚本です。 2023 年 10 月 10 日と 11 日の 2 日間にわたり、対面式とオンライン配信のハイブリッドで、SaaS on AWS 2023 セミナーイベント を開催しました。開催報告としてセミナーでの発表内容や、会場で行われた各種コンテンツ、懇親会での様子をご紹介します。 開催当日の様子と概要 開催の概要 SaaS on AWS は、SaaS 事業を行う皆様や今後 SaaS 事業を展開しようと考えているソフトウェア事業会社（ ISV ）の皆様が、 AWS を利用してビジネス成長していくにあたっての情報収集やネットワーキングに利用できる機会となっています。今押さえておくべき SaaS に関係するテクノロジーやビジネス拡大の手法について、ユーザー事例をはじめとする 28 の セッションを通じて網羅的に学ぶことができます。 10 月 10 日に開催された  Day 1 は、ISV/SaaS のビジネス面を中心とした内容で、SaaS 事業のトレンドや事例など多数のセッションがありました。お客様の事例セッションの他、近年盛り上がりを見せる 生成系AI の活用についてのセッションもあり、皆様のビジネスの成長に向けて様々な角度で情報を得ることができる内容でした。 10 月 11 日に開催された  Day 2 は、設計・開発・実装・運用などの技術面を中心とした内容で、AWS で利用できる AI/MLサービス の活用についてや、SaaS における目的別データベースの利用、分析系サービスの活用といった内容をソリューションアーキテクト が紹介しました。また、Day 2 でも多くのお客様セッションがあり実際に利用されている技術について聞くことができました。 Day 1 、Day 2 とも一部オンライン配信となっており、動画と資料を公開予定です。 セミナーアジェンダ 開催概要については こちら もご確認ください。 Day1 の様子 Day 1 では SaaS ビジネスに関する内容について、お客様セッションを中心に 10 のセッションが実施されました。Day 1 の様子を一部抜粋してお伝えします。 セッション 『X-point』のクラウド版へ一本化を決断！ワークフローのリーディングカンパニーが選択した方針とは？ お客様からのセッションの中では、株式会社エイトレッド 青木 健一様より、パッケージ製品として販売されていたX-point をクラウド版での販売に一本化されたご決断の背景について発表いただきました。クラウド版への一本化を進める際には、製品のアーキテクチャなどの技術的な変更だけでなく、既存ユーザーからの理解、販売パートナーからの理解、社内の体制の変更と様々な課題を抱えていました。その中で株式会社エイトレッドではどういった対応をされてきたかを知ることができるセッションでした。 AWS のデータ活用と生成系 AI 成功につながるベストプラクティス AWS からのセッションとして、AI/ML 事業開発マネジャー 浅倉 靖之より「 AWS のデータ活用と生成系 AI 成功につながるベストプラクティス」をお伝えしました。このセッションの中では、生成系 AI を SaaS の中でどう使うのかや、10 月に東京リージョンで一般利用開始となった Amazon Bedrock について用例を解説しました。 Amazon Bedrock の名前の由来など、興味深い小話も楽しめるセッションとなっていました。 Day 2 の様子 Day 2 では SaaS 製品を実装し改善していくための技術について知ることができるセッションが数多く開催されました。会場ではセッションの他、AWS のソリューションアーキテクトに直接相談のできる Ask The Expert や SaaS 構築に役立つ Workshop も実施しました。 Day 2 の様子を一部抜粋してお伝えします。 セッション SaaS 事業立ち上げの為の Day1 からのデータ基盤拡張戦略 お客様からのセッションの中では、マネーフォワードｉ株式会社 村上 勝俊様より、SaaS 事業者がビジネスの分析を行い、データをもとにした正しい戦略を立てるために必要なデータ分析基盤の構築を始める方法をご共有いただきました。4 つのステップに分けて無理なく機能を拡張していく手法を、アーキテクチャのサンプルも交えて解説されており、すぐにでも活用できそうな内容となっています。その中では ゼロETL  を使うことで Amazon Aurora と Amazon Redshift を 複雑な ETL の仕組みを作ることなくつなぐ手法も紹介されていました。 Amazon QuickSight で実現するマルチテナント BI AWS からのセッションとして、ソリューションアーキテクトの 高橋 佑里子 より、Amazon QuickSight をマルチテナント SaaS  製品の中で利用する方法を共有しました。Amazon QuickSight のダッシュボードを SaaS 製品に組み込む際に、閲覧するユーザーが属するテナント以外のデータが見れないような制限をかけるための方法を実際の設定についてのデモも交えながらの解説しました。 Amazon CodeCatalyst で実現する SaaS 開発の加速 AWS からのセッションをもう一つご紹介します。ソリューションアーキテクトの 遠藤 宣嗣 より、SaaS 開発を加速させるために使える統合ツール、Amazon CodeCatalyst を紹介しました。SaaS の開発の中では、市場の変化により早く対応するため、開発もスピード感を持って進めなければいけません。より頻繁にデプロイを行なえるような自動化された環境構築を行い、ビルド履歴や Issue 管理も一つのプラットフォームで行えるのが Amazon CodeCatalyst で、このセッションの中では導入のメリットについてより詳しく触れられています。 SaaS 企業  CTO  の パネルディスカッション テーマ「開発組織のカルチャー」 セッションの中では、SaaS 企業の CTO にお話を伺うパネルディスカッションも開催されました。  SaaS への変革はビジネスモデルの変革であり、組織自体も大きく変更していかなければなりません。そこで、開発組織のカルチャーを変更した方法を株式会社アルファドライブ 赤澤 剛様、株式会社カオナビ 松下 雅和様、パイオニア株式会社 岩田 和宏様、弥生株式会社 佐々木 淳志様をパネラーに迎え、AWS ソリューションアーキテクト 上原 誠 をモデレーターとしてパネラーの皆様のご経験やお考えをお話しいただきました。 Ask The Expert AWS のソリューションアーキテクトとセッションで発表してくださった登壇者の方々が参加者の疑問に回答する部屋も用意されていました。AI/ML 、データベースとアナリティクス、SaaS 全般などのトピックにごとに相談を受け付けており、普段 AWS との技術相談を行っていない方でも、気軽に相談いただける機会となりました。 Workshop SaaS アーキテクチャを体験するワークショップも開催されました。SaaS アーキテクチャの重要な要素であるコントロールプレーンについて学べる SaaS Boost Workshop 、サーバーレスなサービスを使って SaaS アーキテクチャを構築する Serverless SaaS Workshop 、マルチテナントの認証認可について学ぶことのできる SaaS AuthN/Z Workshop ( GitHub )の3種類のワークショップが提供され、多くの方にご参加いただきました。 ネットワーキング Day 1 、Day 2 ともセッションの合間にコーヒーブレイクがありました。この時間は SaaS on AWS に参加する他社との交流や、AWS の技術者、発表者とのコネクションづくりに利用していただくことができました。また、Day 2 の最後に行われた懇親会では AWS に関するクイズを出題するウルトラクイズが開催され、クイズの正解者には書籍の贈呈もありました。 収録動画 / 資料 セッションの動画及び資料はダウンロード可能になり次第公開いたします。 おわりに 本イベントでは、ISV/SaaS 事業会社に所属するビジネスリーダー層と技術者の方向けに、 SaaS に特化したソリューションや事例紹介をお届けしました。お忙しい中ご参加いただいた皆様に感謝申し上げます。今回ご紹介した内容が、みなさまの今後のビジネス成長にお役に立てれば幸いです。

企業は、コスト構造、市場投入のスピード、提供する商品の質を改善するために研究開発（ R&D ）に投資しています。研究開発費は、ヘルスケア、製薬、テクノロジー業界のように、研究活動が製品ロードマップと連動している業界で最も高くなります。これらの業界では、通常、売上の 10% から 15% をイノベーションに充てています。しかし、その他の業界では、売上の 0.5% から 3% しか研究開発に割り当てられず、短期的な技術インフラのニーズや業界のトレンドによって増減する裁量的支出となっています。これらの企業は、プロセスからサプライチェーン、オペレーションに至るまで、ビジネスの一部をデジタル化し始めています。イノベーション能力は企業の成功に不可欠であり、クラウドはそれを実現する最良の手段です。 なぜクラウドがイノベーションにとって重要なのかを理解するために、1982年に Harvard Business Review （ HBR ） に掲載された論文 に話を戻しましょう。この 論文 は、テクノロジーを使って永続的な競争優位を築けるかどうかという議論を始めたものです。著者https://aws-blogs-prod.amazon.com/news/move-over-it-here-comes-innovation-2/?preview=trueは、企業が成功するために技術の進歩だけに頼る必要はない、と結論づけています。なぜなら、テクノロジーへの投資は、しばしば企業戦略や乗り越えなければならないさまざまな課題や障害から切り離されているからです。 その20年後、ドットコムブーム （訳者注:　dot-com bubbleのこと） によって、「競争優位としてのテクノロジー」派にバランスが傾きました。しかし、少数の成功したオンライン企業には概ね当てはまることでも、レガシーシステムや実店舗 (訳者注:　brick and mortar　) を持つビジネスには適用できないことが判明しました。 それからさらに20年が経ち、この議論はすっかり影を潜めました。今では、より速く、より効果的にイノベーションを起こす方法を見つけることについて焦点が当てられています。それはなぜでしょうか？　テクノロジーとイノベーションは、もはや競合する2つの独立した企業イニシアチブではないからです。クラウドコンピューティングは、無限の柔軟性と拡張性を提供する新しい技術です。これにより、企業は、顧客のニーズに焦点を当て、そこから逆算して、望ましい結果を導き出すことができます。そして、既存のクラウドサービスを活用して、特定した問題を解決したり、新しい機会を獲得したりすることができます。ハードウェアとソフトウェアのレイヤーを構築してから、その上に載せるアプリケーションを開発する心配はありません。IT とビジネスが抱えるベンダーとクライアントの関係を排除することで、イノベーションを簡素化することができます。ビジネスチームは開発プロセスへの積極的な参加者となり、彼らの焦点はそれらを実現する技術についてではなく、イノベーションに置かれたままとなります。 元デジタルトランスフォーメーション担当役員で、現在は AWS カナダのイノベーションリードとして、私が関わるほとんどの企業がイノベーションの課題を持っています。成功する企業の共通点は、クラウドを採用し、関連するベストプラクティスを導入していることです。私は、クラウドコンピューティングがイノベーションを可能にする理由を、4つの柱に集約しました。すべての組織のクラウド戦略は、この4つの柱を考慮する必要があります。 1- 資金調達 クラウドは、企業が必要な時に必要なテクノロジーサービスを利用することを可能にします。企業は、テクノロジー・プログラムを実行するためにインフラを購入し、維持する必要がありましたが、今ではより多くのリソースをこれらのプログラムに向けることができます。家を建てるとき、既存の電力網やきれいな水、下水道に頼りますよね。もし、これらのインフラをすべて自分で構築し、費用を負担しなければならないとしたら、家を買うことができないか、あるいはもっと小さいものになってしまうかもしれません。クラウドコンピューティングも同じです。インフラや保護、メンテナンスの費用が不要になれば、研究開発やイノベーションに多くの資金を割くことができるようになります。 2- スピード アマゾンの社長兼 CEO であるアンディ・ジャシーは、”発明には2つのことが必要です。1つは、たくさんの実験を試す能力、2つは、失敗した実験の巻き添えを食って生きていく必要がないことです。” オンデマンドでコンピューティングサービスを利用できるようになったことで、テストが可能になり、はるかに安くなりました。アイデアはすぐにプロトタイプ化され、試験的に使用することができます。この記事の時点では、AWS には 200 以上のフルサービスがあり、新しいサービスもどんどん追加されています。ユーザーは、他の方法では手が出せないような技術を試すことができるようになった。量子コンピューティング、衛星サービス、強力なデータ処理エンジン、ブロックチェーンと IoT サービス、コンタクトセンターシステム、機械学習（ML）プラットフォーム、特殊なデータベースなど、例を挙げればきりがありません。ある中堅企業では、5つの新規構想の同時進行という目標がありました。2つを停止して新しいものに置き換え、1つを大幅に変更し、2つを開発するという前提です。既存のクラウドサービスを活用することで、大規模な投資をせずにアイデアをテストし、失敗したものは評価損を出さずにシャットダウンすることが可能になったのです。 3- アジリティ 長い導入期間や調達スケジュールはもはや邪魔にならず、高価な技術専門家も電気を点けるのに精一杯で、ビジネスの要求に素早く対応することはできません。その代わりに、クラウドサービスはビジネスのゴールと目標を実現します。これにより、「シャドー IT」の必要性がなくなるだけでなく、イニシアチブの成功のために連携する多職種のメンバーで構成されるプロダクトチームの創設が促進されます。国際的な取引所である Deutsche Börse Group は、 AWS を使用して 、新しいクラウドベースのデータ分析プラットフォームである A7 をわずか 4ヶ月で構築し立ち上げました。 4- 顧客志向 クラウドは、顧客に焦点を当てた新しいイノベーションの方法を可能にしています。しかし、インフラをクラウドに移行したからといって、組織が顧客中心主義になることを保証するものではありません。組織の障壁を取り除くことから、顧客から逆算することまで、未開拓の市場の可能性を引き出すために必要な文化的変革を生み出し、または加速させるための新しい手法を開発しました。AWS が開拓したこれらの手法は、今やあらゆる業界のあらゆる企業が利用可能であり、一般に 公開 されています。そのためには、ビジネスのスポンサーシップと現状に挑戦する意志が必要なだけです。 まとめ テクノロジーと研究開発の間で行わなければならなかったトレードオフがなくなり、それとともにイノベーションを遅らせる制限要因もなくなりました。クラウドの恩恵を最も受けるのは、クラウドを活用するために自社の能力（ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、オペレーション）を変革できる企業でしょう。イノベーションの実現は、クラウド移行戦略と変更管理計画から始まります。クラウドコンピューティングは、1982年の HBR の議論をついに陳腐化させました。イノベーションこそが永続的な競争優位をもたらすものであり、テクノロジーがそれを可能にするのです。 クラウドへの移行を開始する方法については こちら をご覧ください。また、社内でイノベーションの境界を押し広げたいとお考えなら、 世界中の AWS のお客様の経験に興味を持たれるかもしれません 。 Francois Chevallier Francois は、カナダのアドバイザリー部門でイノベーションのプラクティスリードを務めています。大企業がクラウド機能を活用し、近代化、イノベーション、業務効率化の道を切り開くのを支援する。エグゼクティブコーチ、AWS クラウドプラクティショナー、講演者としても活躍中。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。

はじめに アマゾン ウェブ サービス (以下、AWS) は、 2023年9月28日に 基盤モデルを API 経由で利用できるようにするフルマネージド型のサービスである Amazon Bedrock を一般公開しました 。本記事では Amazon Bedrock で提供されるモデルのうち、日本語にも対応した Anthropic 社の Claude を利用し、コンタクトセンター業務を支援するサンプルソリューションである Live Call Analytics with Agent Assist（以下、LCA）を日本語化し、お客様とエージェントの通話に合わせた回答生成、通話内容の自動要約等に活用するための手順をご紹介します。なお、LCA の詳細については、 Amazon言語系AIサービスによるコンタクトセンターのライブ通話分析とエージェントアシスト をご参照ください。 Amazon Connect 環境の概要 LCA ではコールセンターのソリューションとして、Asterisk、Genesys Cloud、Amazon Chime SDK 等、複数の音声源をサポートしています。今回は Amazon Connect の利用を前提とし、環境の構築を進めます。 アーキテクチャやコードは GitHub で公開 されています。 Amazon Connect 環境の構築 LCA ではコールセンターのソリューションとして、Asterisk、Genesys Cloud、Amazon Chime SDK 等、複数の音声源をサポートしています。今回は Amazon Connect の利用を前提とし、環境の構築を進めます。 Amazon Connect で日本の電話番号を使用するためにはAWS サポートへの問い合わせの上、手続きが必要です。以下の手順では日本の電話番号を使用していますが、US 等の電話番号等でも実施可能です。 1. Amazon Connect のコンソールで「インスタンスを追加する」をクリックします。 2. アクセス URL を設定して、「次へ」をクリックします。 3. 管理者を指定して、「次へ」をクリックします。 4. 残りの項目はデフォルトのまま変更せず進み、「インスタンスの作成」をクリックします。 5. 作成した環境の Instance ARN をメモします。 6. 「Log in for emergency access」を選択して、Amazon Connectの管理コンソールにログインします。 7. 上部の地球儀アイコンから、言語設定を変更します。 8. 電話番号を取得するために、「開始」をクリックします。 9. 電話番号を選択して、「次へ」をクリックします。 10. 「Continue」をクリックします。 11. 「ルーティング」メニューの「フロー」を選択します。 12. 「フローを作成」をクリックします。 13. サンプルのフローを こちら からダウンロードします。右上のドロップダウンから「インポート（ベータ）」をクリックします。 14. 前の手順でダウンロードしたファイルを選択して、「インポート」をクリックします。 15. 「記録と分析の動作を設定」ブロックを選択し、言語設定で「日本語（日本）」を選択して「保存」をクリックします。 16. 右上の「保存」をクリックします。「公開」をクリックし、表示されるダイアログで「公開」をクリックします。 17. 「チャンネル」メニューの「電話番号」をクリックします。 18. 電話番号をクリックします。 19. 「問い合わせフロー/IVR」で「LCA-EXAMPLE」を選択して、「保存」をクリックします。 AWS Cloud9 環境の作成 LCA をデプロイするために必要な構成ファイル等を生成するために、AWS Cloud9（以下、Cloud9） の環境を作成します。 1. Cloud9のコンソールから「環境を作成」をクリックします。 2. 「名前」を入力し、インスタンスタイプで「m5.xlarge」を選択して「作成」をクリックします。 3. 「開く」をクリックします。 4. 環境で使用されている Amazon EBS ボリュームのサイズ変更 の手順にしたがってボリュームサイズを 20GB に変更します。 LCA のデプロイ AWS CloudFormation（以下、CloudFormation）で LCA をデプロイします。ブログ執筆時点の最新である LCA v0.8.8 の使用を前提とします。 1. Github から LCA のコードを Cloneします。 git clone https://github.com/aws-samples/amazon-transcribe-live-call-analytics.git cd amazon-transcribe-live-call-analytics/ 2. publish.sh を以下のように実行します。（S3バケット名は日付を入れる等、一意になるように変更する必要があります。） ./publish.sh lca-demo-env-bucket lca-artifacts ap-northeast-1 各引数の意味は以下のとおりです。 ./publish.sh <cfn_bucket_basename> <cfn_prefix> <region> [public] - <cfn_bucket_basename>: CloudFormation テンプレートやコードを保存する S3バケットを指定します。 - <cfn_prefix>:作成されるコードはこの prefix 下に置かれます。 - <region>: 使用するAWSリージョンをしています。 - public: (optional) "public" を指定するとコード類がパブリックに公開され、他のアカウントでも使用可能となります。 3. 正常に実行が完了すると以下のように結果が出力されるので、Template URLをコピーします。 OUTPUTS Template URL: https://s3.ap-northeast-1.amazonaws.com/lca-demo-env-bucket-ap-northeast-1/lca-artifacts/lca-main.yaml CF Launch URL: https://ap-northeast-1.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/create/review?templateURL=https://s3.ap-northeast-1.amazonaws.com/lca-demo-env-bucket-ap-northeast-1/lca-artifacts/lca-main.yaml&stackName=LCA CLI Deploy: aws cloudformation deploy --region ap-northeast-1 --template-file /tmp/lca/lca-main.yaml --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND --stack-name LCA --parameter-overrides AdminEmail=jdoe@example.com CallAudioSource=Demo Asterisk PBX Server demoSoftphoneAllowedCidr=CIDRBLOCK siprecAllowedCidrList="" S3BucketName="" Done 4. CloudFormationのコンソールを開き、「スタックの作成」をクリックします。 5. テンプレートの「Amazon S3 URL」に先ほどコピーしたTemplate URLを入力し、「次へ」をクリックします。 6. スタック名、パラメーターを以下のように入力します。（以下に記載以外のパラメーターはデフォルトの値を使用します） 項目 設定値 スタック名 lca-demo-env パラメーター Web UI Authentication Admin Email Address 自分の E メールアドレス Telephony Ingestion Options Call Audio Source Amazon Connect Contact Lens Call Audio Processor Call Transcriber Lambda Amazon Connect instance ARN (existing) 前の手順で確認した Amazon Connect環境のARN Agent Assist Options Agent Assist QnABot Bedrock ModelId anthropic.claude-instant-v1（デフォルト） Amazon Transcribe Configuration Transcribe API mode standard Language for Transcription ja-JP Transcript Event Processing Configuration BedrockModelId anthropic.claude-instant-v1（デフォルト） 7. 以降の設定はデフォルトのまま「次へ」をクリックして進みます。 8. 以下のようにチェックボックスを有効にして、「送信」をクリックします。 9. 45分程でデプロイが完了します。 Claude のアクセス申請 Amazon Bedrock が提供する Claude を利用するためにアクセス申請を行います。 ブログ執筆時点、Amazon Bedrock は東京リージョン（ap-northeast-1）で一部のモデルがリリースされていないため、実際の画面とは異なります。本記事では東京リージョンでリリース済みの Claude Instant を使用します。 1. Amazon Bedrock のコンソールに移動します。 2. 左側のメニューの「Model access」を選択し、「Edit」をクリックします。 3. Anthropic の横にある「Request」をクリックします。 4. 必要事項を入力して、「Request」をクリックします。 5. しばらくすると Claude の「Access status」が「Available」になるので、チェックボックスにチェックを入れて、「Save changes」をクリックします。 6. 「Access status」が「Access granted」になります。 LCA のWeb コンソールにログイン LCA の Web コンソールにログインします。コンソールはコールセンターのエージェントがお客様との通話中に使用します。 1. スタックの作成が完了すると「Welcome to Live Call Analytics with Agent Assist!」というメールが届くので、メールに記載のURLを開き、メールアドレス、メールに記載のパスワードでログインします。 2. パスワードの変更を求められるので、パスワードを変更します。 3. 「Email」にチェックを入れて、「VERITY」をクリックします。 4. 受信したEメールに記載の Confirmation Code を入力して「SUBMIT」をクリックします。 5. LCAのWebコンソールが開きます。 QnABot Content Designer にログイン QnABot Content Designer は LCA に含まれる Agent Assist Bot の各種動作を設定することができます。ここでは必要最低限の修正を行います。各項目の説明は QnABot on AWS のドキュメント を参照してください。 1. 「QnABot Signup Verification Code」というメールが届くので、メールに記載のURLを開き、ユーザー名（Admin）、メールに記載のパスワードでログインします。 2. 新しいパスワードを入力して「Send」をクリックします。 3. QnABot Content Desigerが開きます。 4. 左上のメニューを開き、「Settings」を選択します。 5. 以下の項目を変更します。 項目 値 備考 ALT_SEARCH_KENDRA_FALLBACK＿CONFIDENCE_SCORE LOW Kendra の 検索結果でSCOREが低いものも対象にする LLM_GENERATE_QUERY_PROMPT_TEMPLATE Human: <chatHistory> タグの中にチャット履歴の記載があります:<br><chatHistory><br>{history}<br></chatHistory><br>Human: <followUpMessage> タグの中に Human からの質問があります:<br><followUpMessage><br>{input}<br></followUpMessage><br>Human: 質問の内容を、チャット履歴を読まなくても理解できるような独立した質問として言い換えてください<br><br>Assistant: 6. 「SAVE」をクリックします。 日本語対応 LCA を日本語対応するための設定変更を行います。 Kendra LCA のデフォルトの構成では Kendra に英語のドキュメントが投入されています。ここでは検索対象を日本語のドキュメントに変更します。 1. Kendraのコンソールで、作成されたインデックスを選択します。 2. データソースを選択し、Action メニューの「Edit」を選択します。 3. Default Languageで「Japanese (ja)」を選択して「Next」をクリックします。 4. 設定済みの Source URL を削除して、以下のURLを追加します。 https://ja.wikipedia.org/wiki/損害保険 https://ja.wikipedia.org/wiki/自動車損害賠償責任保険 5. 最後まで進み、「Update」をクリックします。 6. データソースを選択して、「Sync now」をクリックします。 Lambda 1. Lambda のコンソールを開きます。 2. 関数名に「FulfillmentLambda」を含む Lambda 関数を開きます。 3. lib/middleware/3_query.js に以下の行を追加して、「Deploy」をクリックします。 req['kendraQueryArgs'] = ['"AttributeFilter" : {"EqualsTo":{"Key":"_language_code","Value":{"StringValue": "ja"}}}'] 4. 「エイリアス」タブで「live」をチェックして、「編集」をクリックします。「バージョン」で $LATEST を選択して「保存」をクリックします。 5. AWS Systems Manager のパラメータストアの値を修正します。Systems Manager のコンソールで「パラメータストア」を選択し、「LLMPromptSummaryTemplate」を含むパラメータを開きます。 6. 「編集」をクリックします。 7. 「値」を以下のように設定し、「変更を保存」をクリックします。 { "Summary":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>記載された内容の要約は？</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:", "Topic":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>通話のトピックは何ですか？例えば、iphoneの問題、請求の問題、キャンセルなど。トピックだけを答えてください。</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:", "Follow-Up Actions":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>AGENTはこれからどのようなアクションが必要ですか？</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:" } 動作確認 ここまでの設定で LCA を日本語対応するための最低限の設定ができましたので、実際に電話をかけて動作を確認します。 1. エージェント(Agent)側で「問い合わせコントロールパネル」を開きます。 2. ステータスを「Available」にします。 3. お客様側(Caller)から電話をかけます（通話料が発生しますのでご注意ください）。 4. Webコンソールにレコードが作成されるので、Call IDをクリックします。 5. 以下のようにLCAの詳細ページが開きます。 「Call Transcript」には通話の文字起こしの結果が表示されます。エージェントとお客様の会話内容に基づき、リアルタイムに関連ドキュメントが提示され、エージェントは適切な回答を即座に行うことができます。「Agent Assist Bot」の画面ではエージェントが質問内容を入力し、関連ドキュメントを検索することが可能です。「Call Summary」には通話終了後に、会話内容の要約、トピック、フォローアップ内容が表示されます。 まとめ 本記事ではコンタクトセンター業務を支援する LCA を Amazon Connect と共に構築し、 Amazon Bedrock の Claude 2 を利用して日本語化する手順をご紹介しました。ご自身のアカウントでも構築可能ですので、ぜひトライしていただき、Amazon Bedrock が提供する生成系 AI の可能性を体感してください。本ソリューションは 生成系 AI を利用したユースケースの一例に過ぎませんので、ご自身の業務での適用できそうなアイディアをふくらませていただき、ビジネスの革新に Amazon Bedrock を活用いただければと思います。 著者について 千代田 真吾は、アマゾンウェブサービスのソリューションアーキテクトです。現在は、エンタープライズの小売・消費財業界のお客様が AWS を用いてビジネスを拡大するのを支援しています。

アプリケーション層は多くのクラウドアーキテクチャで世界中がアクセスする部分ですが、使用しているデータベースに合わせてアプリケーションを最適化する方法を検討することはほとんどないようです。リレーショナルデータベースエンジンを使用するときは、スキーマの設計だけでなく、アプリケーションが管理可能で、スケーラブルで、パフォーマンスが高いことを保証するために、データベースがストレージシステムに対してデータを読み書きする方法を理解することが重要です。シリーズのパート 1 となるこの投稿では、PostgreSQL の主要な用語について説明し、次に、 Amazon Aurora PostgreSQL 互換エディション または Amazon Relational Database Service (Amazon RDS) for PostgreSQL を使用する場合の自動コミット処理、自動バキューム処理、およびトランザクション中のアイドル状態についてもう少し詳しく説明します。 PostgreSQL パラメータの変更: どこで、いつ、なぜ パラメータは、データベースと PostgreSQL でその要素プロパティを定義するために使用されます。PostgreSQL では、新しいデータベースを作成するときにデフォルトのパラメータが設定されており、多くのシステムでは、通常はデフォルトパラメータのパフォーマンスが良く、チューニングは必要ありません。システムが成長し、規模が拡大し、負荷が高まるにつれて、最適なパフォーマンスを得るために一部のパラメータを調整する必要があります。 セルフマネージドデータベースと AWS マネージドデータベースのどちらを使用しているかによって、異なるパラメータ値を変更する必要があります。セルフマネージドデータベースの場合、パラメータの変更は postgresql.conf ファイルで行われます。AWS マネージドデータベースでは、postgresql.conf ファイルへのアクセスは制限されているため、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、SDK、または AWS CloudFormation を介してのみ、基礎となるデータベースまたはクラスターパラメータグループに対して変更を行うことができます。 postgresql.conf (セルフマネージド) セルフマネージドデータベースでは、PostgreSQL クラスター全体にパラメータを設定する場合、このファイル (PostgreSQL データディレクトリ内) に変更を加えます。詳細については、PostgreSQL コミュニティドキュメントの パラメータ設定 を参照してください。 RDS DB パラメータグループ (AWS マネージド) Amazon RDS のクラスターレベルとデータベースレベルのパラメータグループには、インスタンスクラスとサイズに応じたデフォルト設定があります。パフォーマンスを向上させるために他の値に変更が必要な場合は、 コンソール 、 AWS CLI 、SDK、または AWS CloudFormation を使用して新しいパラメータグループを作成できます。詳細については、 DB パラメータグループの作成 を参照してください。 セッションレベル (セルフマネージドまたは AWS マネージド) PostgreSQL のパラメータの多くは、セッションレベル (1つ以上のトランザクションで構成される) で変更できます。これらのパラメータは、そのワークロードの中で実行されたクエリにのみ適用され、データベース全体には適用されません。これらのパラメータは、 SET コマンドを使用して変更できます。詳細については、PostgreSQL コミュニティドキュメントの SET を参照してください。 PostgreSQL のコンセプト このセクションでは、PostgreSQL データベースの運用に不可欠な PostgreSQL のコアコンセプトについて説明します。 トランザクション PostgreSQL では、トランザクションは単一の操作として実行される一連の SQL ステートメントです。このトランザクションモデルは、トランザクション内の全てのステートメントがデータベースに正常にコミットされるか、ステートメントが失敗した (もしくはエラーが発生した) 場合にロールバックされることを保証します。 PostgreSQL は ACID に準拠しています。ACID とは、データベース操作において原子性、一貫性、独立性、永続性が常に維持されることを保証する一連のデータベース特性です。 Atomicity (原子性) – データベースの原子性により、トランザクションが完了するまでオープントランザクションは他のトランザクションから見えなくなり、その後、すべての変更が単一のユニットとして同時に表示されます。 Consistency (一貫性) – 一貫性により、データにコミットされた変更があった場合、その変更が数日前、数時間前、または数秒前にコミットされたかどうかにかかわらず、新しいトランザクションでその変更を確認できます。また、サーバーがクラッシュした後でも、データをエラーなく回復できます。 Isolation (独立性) – PostgreSQL は、他の同時実行中のトランザクションへのデータ変更の可視性を制御するためのさまざまな分離レベルを提供します。デフォルトでは、read commited の分離レベルが使用されます。これにより、トランザクションは、他のトランザクションによってコミットされた後にのみ変更を確認できます。 Durability (永続性) – 永続性は、コミットされたすべての変更をデータベースが追跡することを保証します。そのため、異常なキャンセルが発生した場合、データベースは元の状態にロールバックするか、トランザクションログを再生して中断したところから続行できます。 トランザクションの詳細については、 トランザクション を参照してください。ACID コンプライアンスの詳細については、PostgreSQL コミュニティドキュメントの 用語集 を参照してください。 ロッキング PostgreSQLは、複数のトランザクション間の競合を防ぐために、ロッキングメカニズムを使用してデータへの同時アクセスを管理します。PostgreSQL には次の 2 種類のロックがあります。 共有ロック – これにより、複数のトランザクションが特定のデータオブジェクトを同時に読み取ることができます。 排他ロック – ロックが解除されるまで、他のトランザクションがデータオブジェクトにアクセスできないようにします。 PostgreSQLはロックプロトコルを利用しており、ロックは特定の順序で取得および解除されます。これにより、データベースをデッドロックから保護できます。デッドロックとは、2 つ以上のトランザクションが互いにリソースアクセスのロックの解放を待っている間にブロックされる状況です。 PostgreSQL は行レベルのロックもサポートしています。これにより、テーブル全体ではなく個々の行をロックできるため、同時アクセスをきめ細かく制御できます。最後に、 PostgreSQL はロックエスカレーションを実装しています。これにより、 1 つのオブジェクトに対する多数のロックを、 1 つの高レベルのロックに置き換えて、全体的なロックオーバーヘッドを削減できます。 ロックの詳細については、 明示的ロック を参照してください。 VACUUM PostgreSQL は、データの行をタプルと呼ばれる構造に格納します。タプルが論理的に更新または削除されても、データベースには目に見えないバージョンが残っています。削除または更新コマンドと同時に実行されているトランザクションが、トランザクションが開始された時点からのデータベースのスナップショットで終了できるように、タプルが保持されます。 PostgreSQL は VACUUM プロセスを使用して、古い不可視タプルのバージョンで使用されていたスペースを解放し、ストレージを再利用します。更新および削除された行はデッドタプルとしてマークされ、後で VACUUM プロセスによってクリーンアップされます。異なるトランザクションが同じタプルで同時に処理される可能性があるため、これらはすぐにはクリーンアップされません。マルチバージョン同時実行制御 (MVCC) によって精度が保証されます。たとえば、元のバージョンをすぐに削除すると、同時に実行されているトランザクションは正確にロールバックされません。VACUUM を実行するだけでもデッドタプルは削除されますが、VACUUM コマンドには他にも理解しておかなければならないバリエーションがあります。これについてはこのセクションで説明します。 VACUUM ANALYZE このコマンドは、デッドタプルを削除し、そのテーブルの内容に関するデータベース統計を収集します (これらの統計は pg_statistic システムカタログに保存されます) 。このデータは PostgreSQL クエリオプティマイザによって使用され、クエリ実行時に最も効率的なクエリ実行プランを決定するのに役立ちます。 VACUUM FREEZE このオプションは、デッドタプルをクリーンアップするだけでなく、VACUUM が古い行をフリーズしてすべてのユーザーに表示するか、削除するかを決定するために使用するカットオフ期間 (トランザクション XID 単位) を指定して、タプルを積極的にフリーズします。これにより、VACUUM プロセス中に古いアクティブなタプルのデータが失われたり、トランザクションのラップアラウンドによる破壊を防ぐことができます。トランザクションは固有の XID で追跡され、固定番号であるため使い果たされる可能性があります。適切に監視しないと、運用データベースの XID 番号が登録可能な上限に達し、過去の XID 番号が現在になって再利用できるというラップアラウンドが発生する可能性があります。このラップアラウンド破損により、データの整合性を保護するためにデータベースがシャットダウンする可能性があります。 VACUUM FULL このオプションは、内容を完全に書き換えることにより、テーブル (またはデータベース) からデッドタプルを削除します。データを物理的に再配置してより徹底的なクリーンアップを行うことで、削除および更新されたタプルからディスク容量を再利用します。その結果、ストレージがより圧縮され、クエリパフォーマンスが向上します。このオプションは、テーブルに対して排他ロックを作成し、操作が完了するまで他のすべてのアクセスを防止するため、通常の運用環境では使用しないでください。 PostgreSQL のタイムアウト関連のパラメータ ベンチマーク中にワークロードがどのように動作するかを見積もることはできますが、本番環境のワークロードが予期しない動作をすることがあるため、タイムアウト設定は必要です。タイムアウト設定を適切に設定することは、ワークロードの実行中の異常からクラスターを保護するためのセーフガードとして機能します。これらの設定は、データベースのライフサイクルを通じて調整可能であり、また、調整する必要があります。グッドプラクティスはコネクションとリクエストのタイムアウトを設定することです。RDS for PostgreSQL データベースには便利なデフォルト設定がありますが、異なる設定でパフォーマンスが向上すると判断した場合は、本番環境に適用する前に、設定を 1 つずつ変更してテストしてください。 PostgreSQL データベースタイムアウト設定は、ステートメント、ユーザ、またはデータベースレベルで設定できます。アプリケーション開発者は、これらのタイムアウトパラメータと、それらがタイムアウトエラーを防ぐためにどのように機能するかを理解しておくと役に立ちます。アプリケーションのパフォーマンスとユーザーエクスペリエンスがタイムアウトエラーによって悪影響を受けないように調整できるタイムアウトに関するパラメーターは次のとおりです。 statement_timeout – クエリ内のステートメントがタイムアウトするまでのミリ秒数。デフォルトはタイムアウトなしです。 idle_in_transaction_session_timeout – このパラメータは、指定された期間を超えてアイドル状態が続いているオープントランザクションのあるセッションをすべて閉じます。これにより、そのセッションで保持されていたロックがすべて解放され、コネクションスロットを再利用できます。また、このトランザクションでのみ表示されるタプルをバキュームされ、肥大化を抑えることができます。デフォルト値は (0) で無効です。 idle_session_timeout – PostgreSQL バージョン 14 以降では、 idle_session_timeout パラメーターを使用できます。アイドル状態であるが、指定された時間を超えてオープントランザクションの外にあったセッションはすべて閉じられます。デフォルト値は (0ms) で無効です。バージョン 13 以前では、 idle_in_transaction_session_timeout パラメーターが使用されていましたが、開いているセッションのすべてのトランザクションが停止させるものでした。 client_connection_check_interval – PostgreSQL バージョン 14 以降では、 client_connection_check_interval パラメーターを使用できます。このパラメータを使用すると、クエリ実行時にクライアントコネクションをオプションでチェックする間隔を設定できます。このチェックにより、カーネルからコネクションが閉じられたと報告された場合に、長時間実行されるクエリをより早く終了させることができます。デフォルト値は (0ms) で無効です。バージョン 13 以前では、サーバーはクエリが完了するまでコネクションの切断を検出しなかったため、コネクションが予期せず終了した場合、結果をクライアントに送り返すことができませんでした。 データベースの動作に関するPostgreSQLの機能とそのベストプラクティス PostgreSQL は、実証済みのデータ整合性、信頼性、拡張性を備えた強力なオブジェクトリレーショナルデータベースシステムです。高性能で革新的なデータベースソリューションを提供できる強力なアーキテクチャを備えています。 PostgreSQL には、アプリケーション開発者がフリーのオープンソースの拡張可能な環境で運用可能なフォールトトレラントアプリケーションを構築するのに役立つ多くの機能があります。開発者は、データベースを再コンパイルしなくても、カスタム関数を構築し、さまざまなプログラミング言語のコードを使用できます。このセクションでは、データベースの動作に関するいくつかの機能とベストプラクティスについて説明します。 AUTOCOMMIT PostgreSQLはACIDに準拠しているため、トランザクションを明示的にコミットする必要があります。これに役立つ機能の 1 つが、トランザクションをデータベースに自動的に保存する AUTOCOMMIT です。 AUTOCOMMIT では、各ステートメントがトランザクション内で実行され、各ステートメントが自動的にコミットされます。デフォルト値は ON です。つまり、実行するために BEGIN または COMMIT コマンドを特別に発行する必要はありません。トランザクションは BEGIN で始まり、 COMMIT コマンドで終わります。コミットはユーザーの変更を保存します。 AUTOCOMMIT が OFF に設定されている場合、 BEGIN コマンドは不要ですが、変更がデータベースに反映されるようにするには、ステートメントの最後に明示的に COMMIT コマンドを記述する必要があります。 AUTOCOMMIT のデフォルト設定はほとんどの環境で役に立ち、変更する必要はありません。たとえば、 \COPY コマンドを使用して行を一括ロードする場合、 AUTOCOMMIT を無効にする必要はありません。100 行の AUTOCOMMIT の一括挿入 (たとえば、 INSERT … VALUES (...), (...), (...), (...) のほうが、100 行の INSERT ステートメント ( BEGIN; INSERT … INSERT … INSERT … ) からなる単一の COMMIT よりもパフォーマンスが向上します。これは、個々の BEGIN コマンドと COMMIT コマンドが大量のディスクアクティビティと CPU を消費するためです。ただし、特定の状況下では、設定をオフにした方が作業しやすい場合があります。1 回の挿入に失敗すると、すべての行がロールバックされます。これは、ビジネスニーズによっては問題となる可能性のある不要な部分的データロードを回避するためです。 この機能は、 WHERE 句なしで DELETE ステートメントを誤って実行してしまったなどの間違いからすばやく回復できるため、アプリケーション開発者にとって有益な場合があります。 AUTOCOMMIT をオフのままにしておきたい場合は、ワークロードの特定の側面に合わせてセッションレベルでこの設定を変更するのが最善です。 AUTOCOMMIT をオフにしてステートメントを発行し、 COMMIT コマンドを指定しなかった場合、PostgreSQL はこの投稿で前述したように COMMIT が指定されるまでロックを保持するため、次のステートメントはロック状態になります。 AUTOCOMMIT を使用する際のベストプラクティスを次に示します。 AUTOCOMMIT はグローバルにオンのままにしておき、ビジネス上の理由がある場合にのみ無効にします。次の点に注意してください。 AUTOCOMMIT をオンにすると、クエリはグループ化されません。 AUTOCOMMIT は暗黙的に発行されるため、どのクエリがコミットまたはロールバックされるかが不確実になることはありません。 PostgreSQL のオートコミットには暗黙的な BEGIN と COMMIT があり、しばしば トランザクションブロック と呼ばれ、 COMMIT コマンドは不要です。 AUTOCOMMIT をオンにすると、すべての SQL ステートメントが自動的にコミットされることが保証され、 AUTOCOMMIT が off でない限りロールバックはできません。 AUTOCOMMIT を無効にする場合は、セッションレベルでのみ無効にしてください。次の点に注意してください。 無効にすると、データベースは常にトランザクションモードになり、 COMMIT または ROLLBACK コマンドで明示的に終了する必要があります。 AUTOCOMMIT がオフの場合、間違いがあった時に、ロールバックを実行するのは簡単で、すべてが元に戻されます。これにより、変更がデータベースに保持されていないため、間違いから迅速かつ簡単に回復できます。 AUTOVACUUM VACUUM はデッドタプルをクリーンアップする手動プロセスですが、 AUTOVACUUM は削除されたタプルや更新された古いタプルの削除を自動化する定期的なバックグラウンドユーティリティデーモンです。AUTOVACUUM はデフォルトで有効になっており、データベースに多数の UPDATE コマンドと DELETE コマンドが発行されている場合は、そのパラメータをテストして調整する必要があります。PostgreSQL は MVCC モデルを使用しており、同時読み取り要求を完了できるように古い行バージョンを保持します。これらのステートメントの間、行は削除されず、古いバージョンはトランザクションが完了するまで保持されます。COMMIT コマンドが指定されていない場合、トランザクションは技術的にはまだ実行中であり、その行がまだ必要である可能性があるため、AUTOVACUUM はこれらの行を削除できません。オートコミットを無効にすることで発生する問題の例としては、データベースのロックや AUTOVACUUM メンテナンスの障害があります。 AUTOVACUUM を無効にすると、デッドタプルが削除されず、テーブルが肥大化します。データベースの肥大化はテーブルとインデックスの全体的なディスク使用量の増加につながり、クエリの実行時間が増加し、クエリを実行するためにテーブルやインデックスからデッドタプルやアクティブな可視行が読み取られることになるため、これは望ましくありません。AUTOVACUUM が自動的にデッドタプルを削除する代わりに、 VACUUM FULL コマンドを明示的に呼び出して物理的に削除しなければならない場合があります。 AUTOVACUUM のベストプラクティスは次のとおりです。 タプルレベルの統計用の pgstattuple 拡張機能で、肥大化を評価できる情報を定期的に取得して、AUTOVACUUM が実行されていることを確認します。次の点に注意してください。 肥大化によってディスク消費量が増加し、パフォーマンスが低下します。その結果、管理されず、定期的に削除されていないと、関連するデータを取得するクエリは、 2 倍 (またはそれ以上) かかります。AUTOVACUUM は、適切に設定されていれば、時間の経過に伴うデータベースの肥大化を最小限に抑えるのに役立ちます。 autovacuum_naptime パラメーターを適切に調整して、AUTOVACUUUM が十分な頻度で実行されるようにします。これにより、データベースの肥大化を防ぐことができます。 書き込みの多いワークロードの裏で実行される、長時間実行されるクエリは避けてください。AUTOVACUUM はテーブルに弱いロックをかけるため、サーバーで実行されているワークロードを完全に把握するようにしてください。 INSERT 、 UPDATE 、 DELETE などの通常のデータベース操作は続行できますが、インデックスやテーブルの切り詰めには影響します。 テーブルの使用状況とアクセスパターンに基づいて AUTOVACUUM 設定を調整します。次の点に注意してください。 DELETE ステートメントや INSERT ステートメントが多いテーブルで、前述の VACUUM パラメータに基づいてテーブル の AUTOVACUUM のしきい値をテストして設定します。 データベースへの影響を小さくするために、ビジーでない時間帯に AUTOVACUUUM をいつどのように実行するかについての最善の戦略を計画してテストしてください。また、ロックによって本番システムのワークロードが中断されないように、ビジー時に実行する方法も決定してください。 AUTOVACUUM を頻繁に使われないように注意してください。バキューム処理の間、ビジー状態になって回復するのを待つか、 VACUUM FULL を使わなければならないようなリスクがシステムに発生するかもしれません。 トランザクション中のアイドル状態 コネクション状態の変化はエラーのトラブルシューティングの出発点になる可能性があるため、 PostgreSQL コネクションの監視は重要なタスクです。 PostgreSQL には、トランザクションまたはステートメントの4つの主な状態があります。 active – オープンでクエリを実行しているコネクション idle – アイドル状態でクエリを実行していないが、メモリや CPU などのサーバーリソースを消費し、パフォーマンスの低下の一般的な原因となっているコネクション idle_in_transaction – バックエンドがトランザクション中であるが、アイドル状態で現在入力を待っているコネクション idle_in_transaction (aborted) – idle_in_transaction に似ていますが、トランザクション内のステートメントが原因でエラーが起こった状態 トランザクション処理中は、ロックを保持したり、他のクエリをブロックしたり、AUTOVACUUM や VACUUM のパフォーマンスを妨げてテーブルが肥大化したりする可能性があります。特定が難しい場合が多く、パフォーマンスの問題の原因となっている重要な状態が idle_in_transaction です。データベースが BEGIN コマンドを発行し、1 つまたは複数のテーブルをロックし、ユーザー入力を待っているが、何らかの理由で COMMIT または ROLLBACK コマンドを発行していない場合、クエリは idle_in_transaction になります。トランザクション中のアイドル状態のコネクションはハングアップし、この状態がずっと続く可能性があります。PostgreSQL はなぜ待っているのかわからず、トランザクションスレッドを消費している間はトランザクションを自動的に停止しないからです。プロセスが待機しているのはビジネス上の理由がある可能性があるため、この状態は自動的には解決されません。たとえば、ドキュメントが読まれるまでに時間がかかったり、電子メールの送受信に何営業日も待たされたりします。 idle_in_transaction をなくすには、データベースロックを理解してそのロックが発行された理由を判断する必要があります。また、アプリケーションがロックに遭遇したときの処理方法を知っておく必要があります。 idle_in_transaction は簡単に再現できます。まず、テーブルを作成してデータを追加します。次に、 BEGIN と入力してステートメントを開始します。ステートメントの開始後、コミットやロールバックで終了せずに別の列を追加してテーブルを変更します。このアクションにより、2 番目のステートメントが最初のステートメントを終了せずに開始されたため、トランザクションロックでアイドル状態になります。 psql セッションで idle_in_transaction を再現するには、次のコードを実行します。 CREATE TABLE mydbtable ( id int GENERATED BY DEFAULT AS IDENTITY, username varchar (50), password varchar (50)); BEGIN; alter table mytable add column last_update timestamp; 別の psql タブを開き、次のコードを実行します。 SELECT `*` `FROM` mydbtable`;` テーブルにロックがかかっているので何も起こりません。ロックを解除するには、最初のセッションに戻り、コミットまたはロールバックを実行します。 COMMIT`;` コマンドが実行されると、2 番目のセッションはただちに終了します。ロックは、コミットまたはロールバックが行われるまで常に保持されます。 idle_in_transaction セッションを管理するためのベストプラクティスを次に示します。 pg_stat_activity テーブルにクエリを実行して、現在 idle_in_transaction になっているクエリを見つけます。このテーブルとその使用方法の詳細については、 pg_stat_activity を参照してください。 idle_in_transaction を回避するために、トランザクションをより小さくて扱いやすい部分に分割してください。次の点に注意してください。 セッションごとまたはデータベースごとの設定で、指定した時間より長く実行されないようにクエリを準備します。 タイムアウトログを定期的にチェックして、実行時間の長いトランザクションを検出します。 長時間実行されているトランザクションをキャンセルできるように、 idle_in_transaction_session_timeout パラメータを設定することを検討してください。デフォルトは 0 で、タイムアウトがないことを意味します。 pg_stat_activity を使用して、実行時間の長いクエリと、クエリがその状態であった時間をチェックします。 長時間実行されるストアドプロシージャまたは関数をデータベース層からアプリケーション層に移動します。次の点に注意してください。 エラーは、アプリケーションにコーディングされたエラー処理ロジックによって処理できます。 クエリ結果を処理する前にトランザクションを終了するようにアプリケーションをコーディングします。 不要なエラーを避けるため、アプリケーション層とデータベース層で AUTOCOMMIT がオンになっていることを確認してください。 idle_in_transaction トランザクションの pg_stat_activity パラメータを使用してテーブルを監視し、 idle_in_transaction セッションが VACUUM やその他のクエリによるテーブルへのアクセスを妨げていないことを確認してください。これにより、すべてのオープントランザクションとその状態が一覧表示されます。 まとめ この投稿では、PostgreSQL の主要な機能と、 PostgreSQL エンジンの具体的な機能と、アプリケーションアーキテクチャの指針となるベストプラクティスを詳しく説明しました。Amazon RDS for PostgreSQL と Aurora PostgreSQL を使ったアプリケーションを設計する時にデータベース設計とパラメータ設定を検討することは、ダウンタイムを削減できると同時に、データベースパフォーマンスのコストと不便な中断を回避できます。この投稿はこれらのトピックに関する網羅的なリソースではありませんが、アプリケーション開発者向けの追加の PostgreSQL アーキテクチャとチューニングの考慮事項について説明するフォローアップ投稿の入門書となることを意図しています。 コメント欄でコメントやフィードバックをお待ちしています。 この記事のトルコ語翻訳版は こちら からご覧ください。 この記事の翻訳はソリューションアーキテクトの鈴木 大樹が担当しました。原文は こちら です。 著者について Peter Celentano は、アマゾン ウェブ サービスのスペシャリストソリューションアーキテクトで、マネージド PostgreSQL を専門としています。彼は AWS のお客様と協力して、スケーラブルで、安全で、パフォーマンスが高く、堅牢なデータベースアーキテクチャをクラウド上で設計しています。 Tracy Jenkins は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼女はデータベースを扱い、信頼性、コスト、セキュリティに関する推奨事項を提示しながら、パフォーマンスが高く、可用性が高く、スケーラブルなソリューションを顧客が設計できるよう支援することを楽しんでいます。

Amazon SageMaker Canvas でより高速でより直感的に、時系列予測の機械学習モデルを作成できるようになりました。SageMaker Canvas は、ビジネスアナリストが機械学習の経験やコードを記述することなくマウス操作だけで、高精度な機械学習 (ML) モデルを生成できるサービスです。 SageMaker Canvasは、小売業における在庫管理のための時系列予測、製造業における需要計画、旅行やホスピタリティにおける人員計画および顧客計画、財務における収益予測、その他、正確な予測が必要となる多くのビジネス・クリティカルなユースケースをサポートしています。例えば、小売業者は需要予測によって保持する在庫量、物流、マーケティングキャンペーンの計画を立てています。SageMaker Canvas の時系列予測モデルは、高度な技術を使用して統計アルゴリズムと機械学習アルゴリズムを組み合わせ、非常に高精度な時系列予測を作成します。 本記事では、SageMaker Canvas の予測機能の強化について説明し、ユーザーインターフェイス (UI) と AutoML API を使用して時系列予測を行う方法を説明します。SageMaker Canvas UI にはコーディング不要のビジュアルインターフェイスがありますが、API を使用すると開発者はこれらの機能をプログラムから操作できます。どちらも SageMaker コンソール からアクセスできます。 時系列予測の改善 今回のリリースにより、SageMaker CanvasはAutoMLを使用して予測機能をアップグレードし、以前のバージョンと比較して、モデルの構築が最大50％、予測が最大45％高速になりました。これにより、データサイズが最大 100 MB の 750 時系列の一般的なバッチでは、モデルトレーニングの平均時間が 186 分から 73 分に、平均予測時間が 33 分から 18 分に短縮されます。また、ユーザーは Amazon SageMaker Autopilot API を通じてモデル構築関数と予測関数にプログラムでアクセスできるようになりました。同時に構築されたモデルの説明とパフォーマンス・レポートも取得できます。 以前は増分データを導入するにはモデル全体を再トレーニングする必要がありました。これは時間がかかり、オペレーション遅延の原因となっていました。SageMaker Canvas ではモデル全体を再トレーニングしなくても、最新のデータを追加して将来の予測を生成できるようになりました。モデルに増分データを入力するだけで、最新の洞察を今後の予測に使用できます。再トレーニングをなくすことで予測プロセスが加速し、その結果をビジネスプロセスにすばやく適用できるようになります。 SageMaker Canvas が予測に AutoML を使用するようになったことで、SageMaker Autopilot API を通じたモデル構築および予測が可能になり、UI と API の一貫性が確保されるようになりました。例えば、UI でモデルを構築し、次に API を使用して予測を生成するように切り替えることができます。この最新のモデリング手法により、モデルの透明性もいくつかの点で向上しています。 ユーザーは、予測に影響を与える要因について説明可能性レポートで明確に知ることができます。これは、リスク/コンプライアンスチーム、外部規制当局にとって有益です。このレポートは、データセットのどの属性が時系列予測にどのように影響するかを解明します。インパクトスコアを使用して各属性の相対的な効果を測定し、それらが予測値を増幅するか減少させるかを示します。 トレーニング済みのモデルにアクセスし、SageMaker エンドポイントまたは任意のインフラストラクチャにデプロイできます。 AutoMLが選択した予測モデルや、トレーニングで使用されるハイパーパラメータについて、パフォーマンスレポートから確認できるようになります。 SageMaker Canvas UIを使った時系列予測の生成 SageMaker Canvas UI を使えば、クラウドやオンプレミスのデータソースをシームレスに統合、これらを簡単にデータセットにマージ、高精度なモデルのトレーニング、追加データを使った予測、これらをコーディングすることなく実行できます。この UI を使用して時系列予測を生成する方法を見てみましょう。 まず、SageMaker Canvas にデータを取り込みましょう。データは、PC上のファイルや、 Amazon Simple Storage Servide (Amazon S3) のバケット、 Amazon Athena 、 Snowflake など 40以上のソース から取り込み可能です。データを取り込んだら、散布図や棒グラフを使って、それらを探索的に確認することができます。そして、予測対象となる目的変数や予測期間などの必須項目を設定し、すぐにモデルを作ることができます。以下は、複数店舗における売上実績データに基づいた需要予測のビジュアライゼーションの例です。 以下は特定の商品の需要予測の結果です。 SageMaker Canvas UI での時系列予測の包括的なガイドについては、こちらの ブログ記事 をご覧ください。 ワークフローの自動化や アプリケーションへの直接統合が必要な場合は、 API を通じて予測機能にアクセスできます。次のセクションでは、API 使用して予測を自動化する方法を説明したサンプルソリューションを紹介します。 APIを使った時系列予測の作成 API を使用してモデルをトレーニングし、予測を生成する方法について詳しく見ていきましょう。このデモンストレーションでは、企業が顧客の需要を満たすために各店舗の商品在庫量を予測する状況を考えてみましょう。API による時系列予測は、大まかに言うと以下のステップに分かれます。 データセットを準備します。 SageMaker Autopilot ジョブを作成します。 Autopilot ジョブを評価します。 モデルの精度メトリクスとバックテストの結果を確認します。 モデルの説明レポートを確認します。 モデルから予測を生成します。 Autopilotジョブで生成された real-time inference エンドポイントを利用する、または batch transform ジョブを使用します。 Amazon SageMaker Studio ノートブックでの API による予測のサンプル ビジネスでAPIを使ったプログラムで予測システムを手早く本番利用したいという皆さんのために、 GitHub で SageMaker Studio ノートブックのサンプルを提供しています。このノートブックは、パブリックな S3 バケットでサンプルデータを提供し、上記で説明した一連の予測の流れを実行します。ノートブックでは基本的な予測APIの使い方を学習できますが、ご自身のユースケースに合わせてカスタマイズすることもできます。例えば、データスキーマや予測単位（日ごと・週ごとなど）、予測期間など、その他必要なパラメータを必要に応じて変更してください。 まとめ SageMaker Canvasは、ユーザーフレンドリーでコーディング不要のインターフェースを提供することで、時系列予測を民主化します。これにより、ビジネスアナリストでも精度の高い機械学習モデルを作成できます。AutoMLのアップグレードにより、モデル構築が最大50パーセント、予測が最大45パーセント速くなり、モデル構築と予測機能の両方にAPIアクセスが導入され、透明性と一貫性が向上しました。再トレーニングなしで増分データをシームレスに処理できる SageMaker Canvas 独自の機能により、絶え間なく変化するビジネス要求に迅速に適応できます。 SageMaker Canvasは、直感的なUI・汎用性の高いAPIのいずれにおいても、データ統合、モデルトレーニング、予測を簡素化し、データ主導の意思決定と業界全体のイノベーションにとって極めて重要なツールとなっています。 詳細については、 ドキュメント を確認するか GitHub リポジトリにある ノートブック をご覧ください。SageMaker Canvas を使用した時系列予測の利用料金は、 SageMaker Canvas 料金ページ でご覧いただけます。SageMaker Autopilot API を使用する場合の SageMaker トレーニングおよび推論の料金については、 SageMaker 料金ページ を参照してください。 これらの機能は、SageMaker Canvas と SageMaker Autopilot が一般公開されているすべての AWS リージョンで利用できます。リージョンの可用性の詳細については、「 リージョン別の AWS サービス 」を参照してください。 著者について Nirmal Kumar は Amazon SageMaker サービスのシニアプロダクトマネージャーです。AI/MLへのアクセスを拡大することに尽力し、ノーコードおよびローコードのMLソリューションの開発を主導しています。仕事以外では、旅行やノンフィクションの読書を楽しんでいます。 Charles Laughlin は、AWS の Amazon SageMaker サービスチームで働くプリンシパル AI/ML スペシャリストソリューションアーキテクトです。サービスロードマップの策定を支援し、さまざまな AWS のお客様と日々協力して、最先端の AWS テクノロジーとソートリーダーシップを発揮してビジネスの変革を支援しています。チャールズはサプライチェーン管理の修士号とデータサイエンスの博士号を取得しています。 Ridhim Rastogi は、AWS の Amazon SageMaker サービスチームで働くソフトウェア開発エンジニアです。彼は、AI/ML を通じて現実世界の問題を解決することに重点を置いた、スケーラブルな分散システムの構築に情熱を注いでいます。余暇には、パズルを解いたり、フィクションを読んだり、周囲を探索したりするのが好きです。 Ahmed Raafat は AWS のプリンシパルソリューションアーキテクトで、20 年のフィールド経験を持ち、5 年間は AWS エコシステムに携わってきました。彼はAI/MLソリューションを専門としています。彼はさまざまな業界で豊富な経験を持っており、多くの企業顧客の信頼できるアドバイザーとなって、クラウドへの移行のシームレスなナビゲーションと加速を促進しています。 John Oshodi は、英国ロンドンを拠点とするアマゾンウェブサービスのシニアソリューションアーキテクトです。彼はデータと分析を専門としており、多数の AWS 企業顧客のテクニカルアドバイザーを務め、クラウドへの移行をサポートし、加速させています。仕事以外では、新しい場所に旅行したり、家族と一緒に新しい文化を体験したりすることを楽しんでいます。     この記事の翻訳はソリューションアーキテクトの横山誠が担当しました。原文は こちら です。

バーチャルリアリティ (VR) ストーリーテリングの技術を進歩させることは、「Population One」、「Onward VR」、「Beat Saber」などの人気のマルチプレイヤーゲームを提供する Meta の Oculus Studios の主な目的の 1 つです。 Meta の Oculus Studios が進化し続ける中、信頼性が高くスケーラブルなゲーム開発と、VR ストーリーテラーが利用できるホスティングバックエンドを確立することが重要です。Meta の Oculus Studios コアエンジニアリングチームは、マルチプレイヤー VR ゲームのホスティングとマッチメイキングサービスを Amazon GameLift で標準化することにしました。 課題に正面から向き合う Meta の Oculus Studios 部門は複数の VR スタジオで構成されており、それぞれが独自の作業方法を持っています。これによりユニークなプレイヤー体験の提供が保証できる一方で、ゲーム開発やホスティングが複雑になる可能性もあります。エンジニアリングチームは、Unity から Unreal Engine まで、さらにはカスタマイズされたゲームエンジンやプラットフォームまで、幅広いゲームエンジンをサポートする必要があります。各スタジオでカスタマイズされたマルチプレイヤーシステムを理解して使いこなせるようにするには、十分な準備期間も必要です。その他にも、ライブサービスの構築、クロスプラットフォームのサポート、チャットなどの機能開発、各スタジオのリリースプロセスの統合などの考慮事項があります。 エンジニアリングチームは、品質保証、テストとリリースの手法、オフィスのセットアップといった事項の調査と統合も担当しています。サイロ化された進め方を維持するのは不可能であると認識したエンジニアリングチームは、ゲームホスティングとマッチメイキングのソリューション検討に取り組み始めました。 共通の目標を持つように調整する エンジニアリングチームは、将来のスタジオも一貫してサポートできるよう、シンプルで再現性のある戦略を実現したいと考えていました。目標は、開発者の作業速度を高め、新しいマルチプレイヤー体験の作成や機能の追加を効率化することでした。各スタジオがタイトル間のサポート、拡張、メンテナンスを管理する方法を進化させることも、このビジョンの一部でした。チームは、新しいゲームや機能の開発を加速させるなど、共通の目標を設定しました。 しかし、このビジョンを現実に変えるには、すべてのスタジオの信頼が必要です。チームは、開発中のソリューションがオーバーヘッドの削減にどのように役立つかを実証し、すべてのスタジオが連携できるようにする方法を見つける必要がありました。そして彼らは共通の目標を持つことができました。短期的には、チームは将来のスタジオ向けに Meta のOculus Studiosエコシステムへの統合を加速し、すべてのスタジオでのサポートを増やし、よりスケーラブルなソリューションを提供し、すべてのゲームタイトルの回復力と信頼性を向上させることを目指しました。将来を見据えて、チームは一般的なインテグレーション、共有パターン、コードをより簡単に再利用できるようにすることで、新しいゲームや機能の開発を加速させています。 最適なテクノロジーを見つける Meta の Oculus Studios は、明確な目標、それに伴う課題の理解、VR スタジオとの連携を踏まえて、利用可能なマルチプレイヤーゲームホスティングとマッチメイキングソリューションの検討を開始しました。計画としては、「Beat Saber」でエンドツーエンドのハイブリッドソリューションを試験運用し、そのマルチプレイヤーゲームをピアツーピア (P2P) ホスティングモデルではなく専用ゲームサーバーに標準化することでした。サービスレベルアグリーメント (SLA)、マッチメイキングの柔軟性、グローバルリージョンでの可用性、機能、サポートはすべて、技術要素の意思決定プロセスにおいて重要な役割を果たしました。 その後、研究開発 (R&D) が行われ、チームは最終的に Amazon GameLift の導入を決定しました。Amazon GameLift は完全マネージド型のサービスで、マルチプレイヤーゲーム専用のゲームサーバーを簡単にホストおよびスケーリングできます。Meta の Oculus Studios Core Engineering である Mick Afaneh 氏は、この戦略について次のように語っています。「私たちは、大規模サービスに付随する固有の課題を理解しているだけでなく、場所に関係なく最適なプレイヤー体験を確保し、世界規模での規模拡大とスタジオ間の開発コストの削減に役立つテクノロジーを提供してくれるサービスプロバイダーと提携したいと考えていました。 Amazon Web Services for Games と Amazon GameLift は理想的にフィットしました。」 舞台裏のテクノロジー Amazon GameLift により、Meta の Oculus Studios はゲームサーバーのビルドをサービスにアップロードし、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサイズを選択できるようになりました。その後、このテクノロジーはゲームセッションを作成し、複数の AWS リージョンにまたがる EC2 インスタンスのフリートを構築します。オートスケーリングなどの統合機能により、Meta の Oculus Studios はアクティブなゲームセッションの数に基づいて EC2 フリートを簡単にスケールアップおよびスケールダウンできるため、コスト削減に役立ちます。Meta の Oculus Studios の基盤となるゲームホスティングとマッチメイキングのインフラストラクチャを Amazon GameLift が管理するため、VR スタジオは魅力的な VR コンテンツを作成するために使える時間を増やすことができています。AWS のインフラストラクチャはグローバルで、かつレイテンシーの影響を受けやすいアプリケーションをエンドユーザーの近くで実行できる AWS Local Zones もあるため、Meta の Oculus Studios は地理的に離れたプレーヤーにもレイテンシーを最小限に抑えた VR ゲーム体験を提供できます。 1 年以上前に AWS とのコラボレーションを開始して以来、Meta の Oculus Studios はゲームホスティングとマッチメイキングの標準化された手法を開発し、すべてのマルチプレイヤータイトルを Amazon GameLift に移行してきました。Afaneh 氏は次のように締めくくりました。「AWS とのコラボレーションと Amazon GameLift の活用により、当社のスタジオが体験を提供する方法が合理化され、常に進化し続けている信頼性が高くスケーラブルなソリューションのメリットが得られました。同時に、スタジオが素晴らしいゲームの制作に集中するための時間を増やすことができました。今では、スタジオの内外でいくつものサポートを受けていますが、それはかけがえのないものです。」 Amazon GameLift サービスとスタンドアロンのマルチプレイヤー機能の詳細については、 Amazon GameLift のページ をご覧ください。 この記事の翻訳はソリューションアーキテクトの西坂 信哉が担当しました。原文は こちら です。

はじめに 本日、Amazon Elastic Kubernetes Service (EKS) の Kubernetes バージョンに対する延長サポートのプレビューを発表します。これにより、特定の Kubernetes バージョンが Amazon EKS で一般提供されてから最大 26 か月間、Amazon EKS クラスターでご利用頂けるようになります。延長サポートは、本日から Kubernetes 1.23 バージョンを対象に、すべての Amazon EKS ユーザーに対して無料でプレビューされます。 Kubernetes のようなオープンソースソフトウェアにおいて、コラボレーションを可能にし、エコシステムを横断して互換性を確保するために、バージョンは重要な構成要素です。Amazon EKS の責任共有モデルの一環として、ユーザーはクラスターを最新の状態に保つ必要がありますが、Kubernetes の新規バージョンのリリースペースや複雑さは、 企業にとって追従が難しい場合があります。我々は、Kubernetes のバージョンアップグレードをより簡単にするためのサポートを提供したいと考えています。 Amazon EKS の延長サポートは、クラスターのセキュリティ体制を損なうことなく、Kubernetes のバージョンアップグレードを計画する柔軟性をユーザーに提供します。延長サポートが役立つと思われる一般的なシナリオは次のとおりです。 コードフリーズへの対応 : 商業上重要なイベント(年末商戦、会計年度末の財務報告、新製品発売など)に備えて、環境を凍結する必要がある場合があります。Kubernetes バージョンの廃止に向けて急いで計画を立てるのではなく、延長サポートによりビジネスを優先させ、アップグレードを自分にとって最も都合のよいタイミングで実施できます。 サードパーティの依存関係の管理 : クラスター内で、セキュリティコントロールやインフラ管理機能などを実現するために、カスタムまたはサードパーティ製のソフトウェアを利用している場合があるでしょう。ベンダーが、Kubernetes の特定バージョン用のコントローラやその他のソフトウェアのリリースと認定に遅れることがあります。この場合、延長サポートにより、ユーザーとベンダーは、ソフトウェアの認定バージョンをテストしてリリースするための時間を確保できます。 延長サポートの機能 Kubernetes プロジェクトは、最新の 3 つのマイナーバージョンに対してリリースブランチを 維持 しています。各バージョンは、安定版のリリース (dot 0) から 14 か月の間、Kubernetes コミュニティからサポートを受けます。このサポートが終了すると、アップストリームのプロジェクトはそのバージョンに対するバグ報告やパッチのリリースを受け付けなくなります。Amazon EKS の標準的なバージョンサポート期間は、このアップストリームのサポート期間に合わせています。延長サポートにより、Amazon EKS のクラスターは、当初の 14 か月のサポート期間後、最大 12 か月間そのバージョンで稼働し続けることができます。Kubernetes のバージョンに対する 14 か月の標準サポートが終了すると、そのバージョンで稼働しているクラスターは自動的に延長サポートに入ります。アクションや設定変更は必要ありません。延長サポート期間の終了時に、非推奨バージョンを使用しているすべてのクラスターは、自動的に次に古いバージョンにアップグレードされます。クラスターで Kuberentes バージョンの延長サポートを利用しない場合は、標準サポートの期間内にアップグレードが可能です。 延長サポートの対象 延長サポート期間中の Amazon EKS クラスターは、 Kubernetes のコントロールプレーンに対する継続的なセキュリティパッチを受け取ります。加えて、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、AWS が公開した Amazon Linux と Bottlerocket 向けの EKS Optimized Amazon Michine Images(AMI)、EKS Fargate ノードに対して重要なパッチが提供されます。また、延長サポート期間中のすべてのクラスターは、AWS からテクニカルサポートを受けることができます。 延長サポートは、AWS から提供される Kubernetes 固有のコンポーネントをすべてカバーしますが、AWS が公開した Amazon Linux および Bottlerocket 向けの EKS Optimized AMI に対してのみサポートを提供します。つまり、延長サポートを利用している間、AWS が公開した EKS Optimized AMI 上にオペレーティングシステム (OS)、カーネルなど、新しいコンポーネントが含まれる可能性を意味しています。例えば、 Amazon Linux 2 は 2025 年に EoL を迎えますが、AWS が公開する EKS Optimized Amazon Linux AMI は、新しい Amazon Linux OS を使用してビルドされるでしょう。Amazon EKS は、Kubernetes バージョンごとに重要なサポートライフサイクルとの不一致を発表し、ドキュメント化します。 本日時点では、Amazon EBS CSI ドライバーや Amazon EFS CSI ドライバー、 AWS Distro for OpenTelemetry (ADOT), Amazon GuardDuty エージェント、AWS Marketplace add-ons for EKS、Windows AMI、Amazon EKS Distro など、その他の Amazon EKS アドオン は延長サポートの対象外です。 プレビューで利用可能 Kubernetes バージョンの延長サポートは、Kubernetes バージョン 1.23 以上で動作する Amazon EKS クラスターを対象にプレビューとして提供されます。追加のアクションや設定の変更は必要ありません。バージョン 1.23 で動作するクラスターは、2024 年 10 月にバージョン 1.23 の延長サポート期間が終了した時点で、自動的にバージョン 1.24 にアップグレードされます。 プレビュー期間中は、延長サポートに対して追加コストはかかりません。延長サポートは 2024 年初旬の利用可能を予定しており、延長サポートを利用するクラスターごとに追加料金が発生する予定です。もちろん、ユーザーは標準サポート期間内にアップグレードできます。この場合、既存の Amazon EKS の利用料金 が適用されます。 Kubernetes バージョンの延長サポートは、Amazon EKS のユーザーがクラスターをアップグレードする際の選択肢を提供します。 Amazon EKS バージョン 1.28 で発表されたコントロールプレーン/ノードのスキューポリシーの変更 に加えて、AWS からの完全なセキュリティパッチ、バグ修正、サポートを受けながら、クラスターのアップグレード頻度を減らすことができます。サポートされている Amazon EKS のバージョンと重要なリリース日を確認するには、 リリースカレンダー をブックマークすることをお勧めします。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

この記事では、 Lambda@Edge , Amazon DynamoDB , AWS Lambda , および AWS StepFunctoins を使用して Amazon CloudFront のタグベースでのキャッシュ削除を実装する方法について説明します。また、タグベースのキャッシュ削除をデプロイしてテストするのに役立つリファレンスアーキテクチャとサンプルコードを提供します。 まず、ページをまとめてタグ付けすると便利なユースケースをいくつか紹介します。 ブランドページ – 直販企業(D2C)は、お客様や検索エンジンのボットが発見し易いように、ブランドや製品に関する情報をウェブサイトやモバイルアプリケーションにまとめています。一般的に、ブランドページ、製品リストページ、製品仕様ページと階層的にまとめています。これらは、カテゴリーページやあらかじめ用意された検索語ページなどの補助的なページに結び付けられることもあります。これらはすべてつながっており、ブランドや製品仕様の更新に影響されます。例えば、自動車メーカーが、ブランド、モデルリスト、詳細仕様のページを、ブランドと製品コードを使ってグループ化したい場合があります。 ニュースポータル – ニュース速報やスポーツイベント、記者発表などのイベントをライブ中継する Web サイトでは、写真、ビデオ、スコアティッカー、スコアボード、統計情報などの豊富なマルチメディアコンテンツを含むページを頻繁に更新する必要があります。イベントに関連するすべてのアセットを無効にすることで、視聴者は新しいコンテンツにいち早くアクセスすることができます。 複数のレンディションを持つ画像サイト – 画像などのリッチメディアコンテンツは、デバイスの特性に基づいて最適化されるため、同じコンテンツが複数表示されることになります。例えば、レスポンシブデザインでは、画像はサムネイルと異なるサイズで表示されることがあります。元の画像を更新するとそのすべての表示が更新されるはずですが、それらがグループ化されていれば、より簡単になります。 これらすべてのシナリオで、1 つ以上のタグに基づいてコンテンツをグループ化し、個々のファイルではなくタグに基づいてキャッシュを削除することができます。キャッシュ削除ワークフローにインテリジェンスを追加することで、コンテンツの更新時に複数のファイルを更新する必要がある際のオペレーション効率を向上させることができます。 CloudFront には、ビューワーがアプリケーションのバックエンドを操作するときに (リクエストまたはレスポンスの) 情報を処理する 4 つのイベントトリガーが用意されています。この機能といくつかの AWS サービスを利用して、タグベースのキャッシュ削除ワークフローを実装します。CloudFront イベントトリガーの詳細については ここ を参照してください。 ソリューションの概要 このソリューションは、2 つのコンポーネントで構成されています： タグの取り込みワークフロー ：タグとコンテンツのマッピングの取り込みと、永続化を担当します。各コンテンツURLは、あらかじめ定義されたレスポンスヘッダーに1つ以上のタグを指定することができます。 タグベースのキャッシュ削除ワークフロー ：1 つまたは複数のタグに基づくキャッシュ削除を担当します。このシステムは、タグとコンテンツのマッピングを読み取り、重複を排除し、CloudFront の 無効化のクォータ 内に収まるように制御された方法でキャッシュ削除を実行する役割を担っています。 それでは、各コンポーネントの実装の詳細を見ていきましょう。 タグの取り込みワークフロー 図1: タグの取り込みワークフロー タグの取り込みワークフローの一環として、アプリケーションのバックエンドから来るレスポンスヘッダーを捕まえるためのリスナーを設定します。アプリケーションは、事前に定義されたレスポンスヘッダーに 1 つ以上のタグを送信します。この追加メタデータは、URL と 1 つ以上のタグ間のマッピングを維持するために使用されます。 Chrome デベロッパーツールから見たレスポンスヘッダーの例を以下に示します。’Edge-Cache-Tag ’ は、3 つのタグレベルの情報を保持し、カンマで区切られていることに注意してください。検索する特定のレスポンスヘッダーをカスタマイズしたり、タグをカンマまたはスペースで区切ったりできます。これらはオリジンレスポンスのヘッダーであるため、Lambda@Edge 関数は処理後にこれらのヘッダーを削除することに注意してください。 図2: キャッシュタグを含むオリジンレスポンスヘッダーの例 タグ取り込みワークフロー : Lambda@Edge 関数を、ビヘイビアの ’Origin-Response (オリジンレスポンス)’ に関連付けます。この関数は、キャッシュミス時と、CloudFront がオリジンからレスポンスを受信する直前にのみ実行されます。そのため、冗長な情報でダウンストリームのタグ取り込みシステムに負荷をかけすぎることなく、タグとコンテンツ間のマッピングをキャプチャできる理想的なイベントトリガーになります。 Amazon Simple Notification Service ( Amazon SNS ) トピックは、Lambda@Edge が実行される Regional Edge Cache ( REC ) 毎に作成されます。これは、タグと関連する URL を取得し、永続化するための情報を中継する際の待ち時間を最小化するために行われます。 選択した AWS リージョンにデプロイされた Amazon Simple Queue Service ( Amazon SQS ) は、前述の各リージョンにある Amazon SNS トピックをサブスクライブしています。これにより、異なるリージョンからタグ情報を中央のロケーションに集めることができます。 スケジュールで起動するリージョンのLambda関数：Amazon SQSキューからメッセージを取得し、 DynamoDB テーブルに保存します。 なお、Lambda@Edge 関数は、リクエストされた URL に対してオリジンからエラーが返された場合でも実行されることに注意してください。HTTP 200 OK のみをフィルタリングして動作させたい場合は、HTTP ステータスコードのソースコードに追加のチェックを組み込むことができます。 タグベースのキャッシュ削除ワークフロー 図 3: タグベースのキャッシュ削除ワークフロー タグベースのキャッシュ削除ワークフローを起動するために特権ユーザが下記のアクションを行います。 CloudFront ディストリビューション ID からキャッシュ削除する 1 つ以上のタグを含むJSONペイロードを送信します。 Step Functionsワークフローは、最初に DynamoDBテーブルからマッピングされたURLを取得し、パージキューにポストします。 スケジュールベースの Purge Lambda 関数は、CloudFront に送信されたアクティブなキャッシュ削除の数を監視し、パージキューにメッセージを送ります。この Lambda 関数は、キャッシュ削除 API で許可された制限内に収まるように、CloudFront のキャッシュ削除 API に新しい URL を送ります。 リファレンスソリューション リファレンスソリューションの GitHubリポジトリ はこちらです。 前提条件 リファレンス・ソリューションを展開するために下記が必要です。 あらかじめ定義されたレスポンスヘッダー (デフォルトは ‘Edge-Cache-Tag’) でタグを送信するバックエンドアプリケーション(オリジン) AWS Cloud Development Kit (AWS CDK) を使用してリソースを作成する権限のある AWS クレデンシャル テストするための CloudFrontディストリビューション ソリューションのテスト リファレンスソリューションの導入とテストには、主に次の 5 つのステップが必要です。 GitHubリポジトリ の指示に従いソリューションをデプロイします。 Lambda@Edge のオリジンレスポンス関数を CloudFront のディストリビューションに関連付けてテストします。 新しく作成された DynamoDB テーブルにアクセスし、タグが取り込まれていることを確認します。 Step Functions ワークフローを使用して、タグを指定したキャッシュ削除リクエストを送信します。 CloudFront コンソールからタグ付き URL のキャッシュが削除されたことを確認します。 ステップ 1 : GitHub リポジトリに従ってソリューションをデプロイする プロジェクトのビルド方法に関する説明とともに、GitHub リポジトリ からリファレンスソリューションを見つけることができます。ソリューションをデプロイするために設定できるパラメータについては、’Steps to build’ セクションを参照してください。このソリューションでは、オリジンレスポンスからタグを受信するための Lambda@Edge 関数をデプロイします。ソリューションは一度デプロイするだけでよく、オリジンレスポンストリガーを使用して Lambda@Edge 関数をさまざまな CloudFront のビヘイビアに関連付けることができます。 env.sh ファイルのキャッシュタグヘッダーやタグ区切り文字など、ソリューションのパラメーターを指定できます。デフォルトでは、ソリューションでは “Edge-Cache-Tag” レスポンスヘッダーを使用してオリジンからキャッシュタグを受け取ります。複数のタグをカンマで区切って指定することが出来ます。 オプションとして、前述のパラメーターに加えて、DynamoDB のテーブルに古いレコードが蓄積されるのを防ぐために、各タグに Time-To-Live (TTL) を指定することができます。“TAG_TTL_NAME” は、TTL を含むオリジンレスポンスヘッダーを秒単位で指定します。デフォルトのヘッダー名は “tag-ttl “で、オリジンがレスポンスを返す際にヘッダー値を指定する必要があります。env.sh ファイルの “TAG_TTL_DEFINED_BY ” は、TTL 計算においてどのレスポンスヘッダーを優先するかを指定します。例えば、”TAG_TTL_DEFINED_BY=tag-ttl” を指定した場合、”tag-ttl” ヘッダーに設定された値が最初に優先され、次に ‘Cache-Control’ ヘッダーに設定されている値が優先され、逆も同様です。TTLを完全に無効にしたい場合は、”TAG_TTL_DEFINED_BY” に空の値を指定してください。 Lambda@Edge 関数は us-east-1 リージョンにデプロイされ、他のアーティファクトは複数のリージョンにデプロイされることに注意してください。DynamoDB テーブル と Step Functions ワークフロー は、設定ファイルのプライマリーリージョンとして指定されたリージョンにデプロイされます。リージョナルスタックがデプロイされる他のリージョンは us-east-2 , us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1, eu-west-2, sa-east-1 になります。 Amazon CloudFront のリージョン別エッジキャッシュの詳細については、 こちら を参照してください。 ステップ 2 : Lambda@Edge オリジンレスポンス関数を CloudFront ディストリビューションに関連付けてテストする デプロイが完了すると、AWS CDK はタグを取り込むための Lambda@Edge 関数の ARN を出力します。ARN をコピーして、関数を CloudFront のビヘイビアに関連付けます。 図 4: タグ埋め込み用 Lambda@Edge 関数のARNの出力 Amazon CloudFront コンソールに移動し、オリジンレスポンスでタグを返すオリジンを含む CloudFront ディストリビューションを選択または作成します。“Behaviors (ビヘイビア)” タブで、タグ取り込み Lambda@Edge 関数に関連付けるキャッシュビヘイビアを選択し、“Edit (編集)” を選択します。 図 5: タグベースのキャッシュ削除のためのビヘイビアを選択 ビヘイビア設定で、“Function associations (関数の関連付け)” セクションまでスクロールします。オリジンレスポンストリガーにLambda@Edge を選択し、AWS CDK の出力にある Function ARN を貼り付け、Save changes (変更を保存)します。 図6: タグ取り込み Lambda@Edge 関数の関連付け テストする前にキャッシュを削除します。ディストリビューションドメイン名を確認し、CloudFront からコンテンツをダウンロードして、キャッシュにデータを入力し、オリジンからタグを取り込みます。“x-cache” レスポンスヘッダーの値は、最初のリクエストでは “Miss from cloudfront”、それ以降のリクエストでは “Hit from cloudfront” でなければなりません。 図 7: CloudFront レスポンスヘッダーのキャッシュ(x-cache)を確認する ステップ 3 : 新しく作成した DynamoDB テーブルに移動して、タグの取り込みを確認する ソリューションをデプロイするために選択したリージョンの DynamoDB コンソールに移動します。“ Table (テーブル)” から ” Explore items (項目を探索)“ に移動すると、” TagPrimaryStack-{distributionID} “ という名前で作成された新しいテーブルが見つかります。 {DistributionId} は、前のステップで使用した CloudFront ディストリビューションのディストリビューション ID です。 CloudFront 継続的デプロイ機能 を使用してステージングディストリビューションでテストする場合は、ステップ 2 で説明されているようにステージングディストリビューションも設定する必要があることに注意してください。これにより、ステージング CloudFront ディストリビューション ID を使用して別の DynamoDB テーブルが作成されます。 CloudFront にキャッシュされたコンテンツのキャッシュタグとタグ付き URI を含むエントリがテーブルに入力されていることを確認できます。次の図の例は、さまざまな車の年式、モデル、色をタグ付けした例を示しています。 図 8: DynamoDBに登録された tag/URL を確認 テーブルエントリから、次のステップでキャッシュ削除に使用するタグを選択し、そのタグに関連付けられた URI を書き留めます。 ステップ 4 : Step Functions ワークフローを使用してタグによるキャッシュ削除リクエストを送信する ソリューションをデプロイするために選択したリージョンの Step Functions コンソールに移動して、ステートマシンのリストからステートマシン “ TagPrimarystackPurgeWorkflow ” を探します。ステートマシンを選択し、“View details (詳細を表示)” を選択します。 詳細画面の “ Executions (実行) “ タブで ” Start execution (実行を開始) “ を 選択 し、タグによるキャッシュ削除を作成します。 ”Start execution (実行を開始)“ 画面で、CloudFront ディストリビューション ID とキャッシュ削除に使用したいタグを指定した後、”Input (入力)“ セクションに次の文字列を入力します。次に、”Start execution (実行を開始)“ を選択します。複数のタグは OR ステートメントのように個別に評価されることに注意してください。 { "distributionId": "CLOUDFRONT_DISTRIBUTION_ID", "tags": ["TAG1","TAG2"] } この例では “ year-2021 ” と “ model-suv ” というタグを使用してキャッシュを削除をします。 図 9: タグベースによるキャッシュ削除の実行例 実行の詳細タブで、“Execution Status (実行ステータス)” が “Succeeded (成功)” になっていることを確認します。 図 10: 実行ステータスを確認 ステップ 5 : CloudFront コンソールからタグ付き URL のキャッシュ削除を確認する CloudFront コンソール に移動し、使用している CloudFront ディストリビューションを選択します。次に、“Invalidations (キャッシュ削除)” タブに移動して、キャッシュ削除のリストを表示します。 キャッシュ削除 ID のリストから、送信されたキャッシュ削除リクエストを見つけて選択し、“View details (詳細を表示)” を選択します。 “Invalidation details (キャッシュ削除の詳細)” 画面で、ステータスが “Completed (完了済み)” であることと、“Object paths (オブジェクトパス)” に、キャッシュ削除リクエストで送信したタグ値でタグ付けされたURIが含まれていることを確認します。 図11: タグ付き URI のキャッシュ削除を確認 ソリューションの実行にかかる見積もり費用と、異なるAWSサービスコンポーネントによる内訳は、リポジトリの ’ Pricing Calculation ’ セクションで確認できます。 トラブルシューティングについては、リポジトリの ‘ Troubleshooting ’ セクションを参照してください。 クリーンアップ テストが完了したら、“cdk” ディレクトリで destroy.sh スクリプトを実行することで、ソリューションを削除し AWS CDK プロジェクトによって作成されたリソースに関連するコストを回避できます。スクリプトを実行する前に、Lambda@Edge 関数がすべての CloudFront ビヘイビアと関連付けられていないこと、および AWS CDK によって作成された CloudFormation スタックの削除保護が 無効 になっていることを確認してください。AWS CDK プロジェクトが破棄されたら、DynamoDB テーブルも手動で削除する必要があります。このスクリプトでは、他の AWS CDK プロジェクトに使用できる AWS CDK ブートストラップ CloudFormation スタックと Amazon Simple Storage Service (Amazon S3) バケットは削除されません。スタックとバケットを使用する予定がない場合は、手動で削除することが出来ます。 まとめ 今回のまとめとして、タグベースのキャッシュ削除を使用できるシナリオを学んだ後、 AWS Lambda , Lambda@Edge , Amazon DynamoDB , AWS Step Functions , Amazon Simple Notification Service(SNS) , Amazon Simple Queue Service(SQS) などのサービスを使用して Amazon CloudFront のタグベースのキャッシュ削除ソリューションを実装する方法を説明しました。このソリューションでは、1つまたは複数のタグに基づいてキャッシュされたコンテンツをグループ化し、パスやファイルではなくタグに基づいてキャッシュを削除することができます。キャッシュ削除ワークフローにさらなるインテリジェンスを加えることで、コンテンツの更新時に複数のキャッシュファイルをリフレッシュする必要があるユースケースにおいて、運用効率を向上させることができます。 この記事は、 Tag-based invalidation in Amazon CloudFront を翻訳したものです。 このブログの翻訳は Solutions Architect の深井 宣之が担当しました。