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 の深井 宣之が担当しました。

調査に参加した通信事業者の半数が今後2年以内の生成系AIの活用を計画し、生成系AIへの支出が現在の最大6倍に拡大すると予測 AWS通信およびエッジクラウド担当 チーフテクノロジストIshwar Parulkar（イシュワール・パルルカー） 生成系AIは、あらゆる場で活用され、すべての産業に大きなインパクトをもたらすとAWSは考えています。生成系AIは機械学習の普及に続く新たな波であり、通信業界を含む業界で、お客様体験や多様なビジネスアプリケーションを革新する可能性を秘めています。 AWSは、通信業界における生成系AIへの展望や論調、活用状況に対する理解を深めるため、戦略コンサルティング企業であるAltman Solonと協力し、北米、西欧、アジア太平洋地域の通信事業者の幹部100名以上を対象とした調査を実施しました。主な調査結果は以下のとおりです。 1.  生成系AIの活用は今後2年間で大きく拡大 通信事業者の4つの業務領域（製品・マーケティング、カスタマーサービス、ネットワーク、社内IT）をまたぐ17のユースケースについて調べたところ、生成系AIを既に活用しているか、活用に向けて取り組んでいるとした回答者は全体の19%でした。この数値は今後、さらに拡大する見込みで、調査結果によると1年以内に34%、2年以内に半数近く（48%）に達する見込みです。これに伴い、生成系AIへの支出も現在の最大6倍に急拡大する可能性があります。この急拡大を牽引するユースケースはチャットボットですが（詳細は後述）、通信事業者の64%は、検討している生成系AIのユースケースの多くが、既存のアプリケーションやプロセスではまだ実現されていない新たなアプリケーションだと述べています。 2. 北米の通信事業者が生成系AIの活用で他地域をわずかにリード 生成系AIの活用では、北米の通信事業者がわずかに先行しています（22%が活用、または活用に向けて既に取り組む）。欧州の通信事業者（同19%）は、EUの一般データ保護規則（GDPR）などのデータレジデンシーに関する域内規制のため、生成系AIの活用には、より慎重な姿勢を見せています。特に北米以外の通信事業者にとっては、AI活用やデータ規制、データレジデンシーに関する現行および今後の規制が重要な考慮点となります。中国やEUの多くでAI規制やAIへの監視が強化されているのに対し、米国やインドでは、規制や監視に関して、より消極的です。 アジア太平洋地域の通信事業者（同16%）は、他地域と比べ緩やかなデータ規制の環境にいますが、言語などのローカライゼーションの課題に面しています。生成系AIの多くは大規模言語モデル（LLM）をベースとしており、特定言語のデータコーパスによるトレーニングが必要です。現在の主要なLLMの多くは英語で構築・提供されており、AWSはこの溝を埋めるべく取り組んでいます。例えば、2023年7月に日本で発表した「 AWS LLM開発支援プログラム 」は、日本におけるLLM開発の加速を支援するもので、総額600万米ドル規模のAWSクレジットを提供するなど、LLMの多様性を推進する取組を進めています。 3.  顧客対応チャットボットが生成系AIのユースケースとして、いち早く普及 生成系AIがまずは顧客対応チャットボットに取り入れられていることは自然な流れであり、本調査でも広く活用される見込みであることが分かりました。回答者の92%が、導入の可能性の高いものとしてカスタマーサービスとチャットボットを挙げています。そのうち63%が、すでに開発を進めていると回答しました。 これは既存の基盤モデルを活用するものであり、最初の段階としては正しい方向である一方、将来的には生成系AIがネットワーク運用を支援すると、AWSは考えています。例えば、生成系AIは、通信事業者がネットワーク要素をインストールする際に参考とするマニュアルからデータを取り込むことができます。このデータをチャットボットと組み合わせることで、プロンプトに基づくインタラクティブなガイダンスを提供できるようになり、インストール作業のスピードアップや簡素化につながります。 他の主要なユースケースは、カスタマーサービス、ITにおけるガイド付き支援や文書作成など、社員の生産性向上を支援するものです。 活用ステージ別生成系AIユースケース （全回答者に占める割合。回答者数はユースケースごとに異なる） ※現在、取り組んでいる、または、高い可能性のもとで検証しているとした回答者の割合 4.   データセキュリティとガバナンスが生成系AI活用における最大のチャレンジであり、実現に向けた重要なイネーブラー 生成系AIの活用には、一方で課題があります。本調査に協力した通信事業者の約3分の2（61%）が、データセキュリティ、プライバシー、ガバナンスに関する懸念を表明しました。通信事業者が自社の業務に生成系AIを活用するには、各社が保有する膨大な量のデータが必要となります。広く利用可能なLLMはありますが、自社保有のデータがこうしたモデルそのものに組み込まれることには、知的財産権上の懸念があります。 ある通信事業者のIT部門責任者は、次のように話しています。「当社データのセキュリティを確保し、第3者に使用されないよう徹底する必要があります」 AWSはこうしたお客様の懸念を踏まえ、Amazon Bedrockではお客様のデータが利用する基盤モデルの学習に使用されないようにする機能が組み込まれています。お客様のデータはプライベートかつセキュアに保護されます。 この調査ではまた、アーリーアダプターのうち、データ習熟度上位30%の組織においては、生産性向上以外のユースケースでの生成系AIの活用が進んでいることが明らかになりました。例えば、製品・マーケティングなど、収益創出を目指したユースケースです。データ活用が進むこうした組織では、AIを専門とするセンターオブエクセレンスが設置されていること、高度なデータアナリティクスの活用が進んでいること、最新のデータ基盤（クラウドなど）が整備されていることなど、共通の特徴があります。 5.  通信事業者は、自社開発よりも、既存モデルの活用を想定 生成系AI活用における課題として技術的リソースの不足を挙げる通信事業者もありました。このような背景を考えると、社内で基盤モデルを構築したいと回答した通信事業者は15%にとどまり、その他は既存の基盤モデルの活用を想定していることも驚きではありません。回答者の約4分の3（65%）は既存の基盤モデルを社内の専有データで追加学習し、各社それぞれのニーズに対応させたいと考えています。私たちは、データ基盤のモダナイゼーションにおいて強固な基礎を保有するアーリーアダプターが独自の基盤モデルを構築する15%の層となり、マネタイゼーションに向けて新たな道を切り拓くものと考えています。 通信事業者はファインチューニングされた基盤モデルとともに、AWSのような大規模言語モデルへのアクセスを提供するベンダーに開発環境や専門的なサービスを提供してほしいと考えています。あるワイヤレス通信事業者の高度アナリティクス担当ゼネラルマネージャーが、「個人的には、これが通信業界における生成系AI活用において重要な促進剤になると思います」と述べているように、回答した通信事業者の44%は、フルマネージドサービス基盤を活用し、その基盤上で提供される基盤モデルを利用してアプリケーションを構築したいと考えています。 生成系AIはお客様のビジネスや顧客価値の提供を変革する大きな可能性を秘めています。私たちは、企業のニーズに合った柔軟なアプローチを提供することに注力しており、AWS InferentiaやAWS Traniumなど機械学習に最適化したAWS独自設計のクラウドインフラを活用して自社で基盤モデルを構築する、あるいは、Amazonの基盤モデル（Amazon Titan、Alexa）やサードパーティーの基盤モデルを活用してアプリケーションを開発する、Amazon BedrockやAmazon SageMaker Jumpstartといったサービスを活用して、基盤モデルにデータを追加してファインチューニングするの複数の選択肢をご用意しています。加えて、基盤モデルやAI、機械学習テクノロジーに関する専門知識なしにご利用いただける、Amazon CodeWhisperer、Amazon Quicksightなどの生成系AIアプリケーションもあります。 どのように生成系AIへの取り組みに着手するにせよ、通信事業者にとって最も重要なのは、今すぐ試行錯誤を開始することです。 生成系AIの現在、そして将来的な活用を展望した調査結果の詳細は、 調査レポート（英語） よりご覧ください。 このブログは、英文での 原文ブログ を参照し、アマゾン ウェブ サービス ジャパン合同会社　広報チームが翻訳・執筆しました。

みなさん、こんにちは、カスタマーソリューションマネージャー (CSM) の西口です。このブログ記事では、CSM としてお客様のクラウド活用やクラウド移行の加速をご支援している経験を踏まえ、クラウドの体験型ワークショップ (Experience-Based Acceleration(EBA)) の Party の一つである EBA FinOps Party をご紹介します。 FinOps という用語を皆さまご存じでしょうか。もしかするとあまり馴染みのない用語かもしれません。同じような用語でより耳にすることの多い DevOps が Development (開発) と Operations (運用) が密に連携して、高い品質を確保しつつ開発速度の向上と運用の効率化を目的とした取り組みを指しますが、それと同じように、FinOps は Financial (財務) と DevOps (開発および運用) が密に連携して、クラウドの費用予測や計画をより精微化しコストを最適化することで、財務の面でもクラウドリソースの効率的な利用を進めることを意味しています。 お客様はこの FinOps の一部の取り組みを EBA による実践的なアプローチで体験することが可能です。 EBA ではクラウド利用や移行におけるお客様課題に対して 5 つの Party と呼ばれるワークショップを提供しています。EBA FinOps Party はそのうちの一つです。この EBA FinOps Party を通じて、お客様ご自身で自らの部門やシステムを対象に FinOps を実践します。 EBA の詳細は こちら の記事をご確認ください。 EBA FinOps Party は、移行を行った後などでクラウドの支出が増えており組織として最適化したい、オンプレミスとクラウドの財務の考え方の違いが整理できておらず適切にクラウドを活用できているか自信がない、クラウドの費用計画では財務部門と IT 部門の連携が必要であることは理解しているが連携の一歩が踏み出せない、といったお客様に特におすすめします。 EBA FinOps Partyを実践する効果 EBA FinOps Party を実践する効果として、お客様内のコスト管理を担当する組織 (財務部門、業務部門、IT 部門) が「コストを最適化し続ける」意識を持つための契機を作ることができます。 昨今、IT システムのクラウド化をお客様クラウド推進組織 (Cloud Center of Excellence) が推進していただいている成果として、大変多くのお客様に AWS をご利用いただいています。しかし、それと並行して、景気の低迷や急激な円安によりクラウドの利用料が想定していたよりも高騰し、ビジネス課題として「コスト『削減』」が挙げられることも多くなってきました。これらに対し、AWS では単純な「削減」作業を実施するのではなく、定常的に無駄なコストを減らし適切なコスト状態とするための「最適化」活動として FinOps の実施および活動の定着を推奨をしています。この活動を実践するためのフレームワークが Cloud Financial Management  (CFM) です。 EBA FinOps Party は、このフレームワークと最適化手法をお客様が理解し、定常的な活動計画の立案までを体験するプログラムです。 EBA FinOps Partyでのアジェンダ例 今回のブログでは、日本のお客様向けアジェンダ例をご紹介します。日本では、お客様環境を変更するためのプロセスとして変更作業前に財務部門やアプリケーションチームとの協議、承諾といったプロセスが存在していたり、事前に手順検証を実施しリスクを軽減しておくといったプロセスが存在していることが多く、ワークショップ中に環境を変更するにはとてもハードルが高いと推測します。 そのため、日本のお客様向け EBA FinOps Party ではまず FinOps を始める契機を作ることを目的とし、以下 3 つに焦点を当てています。 CFM フレームワークを理解、認識する コスト最適化が可能な箇所の確認および最適化の手法を理解する エグゼクティブスポンサーからコスト最適化活動に対する支援を獲得する 標準的なアジェンダ例として、Day1 : 基礎編、Day2 : 実践編、Day3 : 報告会の 3 日間です。特に Day2 ではハンズオンやデモを取り入れ、活動施策を Day3 に向けた宿題として検討します。そして Day3 で施策を発表することで定量的な最適化成果を明示的に意識する内容となっています。これにより参加者に「コスト最適化活動し続ける」意識を高める体験を得ることができます。 Day1 (基礎編) ： CFM フレームワーク (座学) AWS の提唱する CFM フレームワークに関して、コストを最適化し続ける重要性と4つの柱「可視化」、「最適化」、「計画・予測」、「 FinOps の実践」を実現するための取組をセミナー形式で実施します。 Day2 (実践編) ：コスト最適化⼿法についての AWS サービスのハンズオンやデモ Day2 では、お客様課題に合ったコスト最適化手法について AWS サービスのハンズオンやデモをご提供します。 ※一例　 AWS Cost Explorer を用いたお客様のご利用状況確認手順ハンズオン、 AWS Budgets や AWS Instance Scheduler 、 Amazon QuickSight のデモまた、このハンズオンやデモの内容を踏まえ、参加メンバーには Day3 へ向けてご自身が関係するシステムやプロジェクトにおける最適化活動施策をご検討いただくことを宿題としてお渡しします。 Day3 (報告会) ：施策報告 Day2 で宿題として検討した最適化活動施策を、エグゼクティブに向けに発表します。エグゼクティブ向けに発表を行うことで、エクゼクティブには今後この施策を後押ししていただけるスポンサーになっていただくことを目的としています。 FinOps ベストプラクティス CFM フレームワークにもあるとおり、 4 つの柱のうち「可視化」、「最適化」、「計画・予測」の 3 つアクションを定常的に「 FinOps の実践」として実施することが非常に重要です。  可視化 AWS コスト配分タグ や AWS Cost Categories を用いたタグ付け戦略の策定、 AWS Cost Explorer や Amazon QuickSight を利用しお客様のクラウド利用料をグラフ化することで、「最適化」を行う対象リソースの可視化を行います。 最適化 「可視化」により確認した対象に対し、AWS の提唱する最適化手法である「クイックウィン最適化」あるいは「アーキテクチャ最適化」を計画、実施します。 クイックウィン最適化 適切なインスタンスサイズの選定、未使用リソースの停止等ご利用環境にて、オペレーションすることで最適化を実践できる手法です。 アーキテクチャ最適化 IaC による運用の自動化やサーバレス、マネージメントサービスの利用といったクラウドネイティブ化することで最適化を実践できる手法です。 計画・予測 新しいシステムの導入やサービスへの機能追加などによりクラウド環境が拡大する等、ビジネス状況を鑑みたクラウド利用料の計画、予測を行い、 AWS Budgets や Amazon Forecast 、 AWS Cost Anomaly Detection を利用しモニタリングします。 AWS Budgets 設定した予算に対し、閾値を設定することでその閾値を超過した場合、E メールまたは SNS 通知によるアラート通知が可能です。 Amazon Forecast AWS Cost Explorer では過去 12 か月分のデータを基にした予測となりますが、Amazon Forecast は AWS Cost and Usage Reports の請求情報データから機械学習を用いて、クラウド利用料の予測を行います。 AWS Cost Anomaly Detection AWS サービスの利用状況を機械学習モデルにより学習し、ベースラインを設け、このベースラインから大きく逸脱した値を「異常」として検知し、E メールまたは SNS 通知によるアラート通知が可能です。 コスト最適化を実践しているお客様事例 FinOps として CFM フレームワークの可視化、最適化、計画・予測を実践することで、コストの最適化がより身近になり、定常的なコスト最適化活動に一歩近づくでしょう。ここではコスト最適化活動を実践しているお客様の例を紹介します。 ナビタイムジャパン様 では、CFM による包括的なコスト最適化の診断の結果、ストレージコストを約 10% 削減しました。また EC2 のダウンサイジングなど 段階的なアプローチを行い、インフラコストはオンプレミス比で 30% の削減を達成できています。加えて、次世代プロセッサーを具備した最新世代のインスタンスへ変更したことにより、さらなるコスト削減とパフォーマンス向上を見込んでいます。 また、 NTT ドコモ様 では、IT 部門と利用部門に対して意識改革を促すため、CFM ワークショップを実施し、コストの最適化を進めた結果、過去の最大利用料より 30% のコストを削減しました。他のお客様においても、EBA FinOps Party を実施した結果、金融業界のお客様で約 120,000 USD、通信業界のお客様で約 500,000 USD、製造業のお客様で約 190,000 USD のコスト最適化を見込んでいます。 EBA FinOps Partyの始め方 EBA FinOps Party は、AWS のクラウド移行トータル支援プログラムである「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー 」の準備・移行フェーズにおける継続的なコスト最適化支援の無償プログラムの一つです。 EBA FinOps Party または AWS IT トランスフォーメーションパッケージにご興味ある方のご利用に向けた入り口は 2 つあり、 1) Web フォーム からお問い合わせ、 2) 担当営業までご連絡、どちらからでも可能です。 AWS へのコンタクトをお待ちしております。 参考情報 AWS によるクラウド財務管理 コスト最適化のためのアーキテクチャベストプラクティス コスト最適化の柱 – AWS Well-Architected フレームワーク AWS コスト最適化フレームワーク– AWS へ移行前後のコスト最適化を通してイノベーションを加速させる クラウド財務管理はコスト削減以上のメリットをもたらす アプリケーションのモダナイゼーションを加速する EBA Level up your Cloud Transformation with Experience-Based Acceleration (EBA) AWS ITトランスフォーメーションパッケージ 2023 ファミリー(ITX 2023) Vega Cloud brings FinOps solutions to their customers faster by embedding Amazon QuickSight AWS 導入事例：株式会社ナビタイムジャパン | AWS AWS 導入事例: NTTドコモ | AWS

AWS Glue Studio は AWS Glue DataBrew と統合されました。 AWS Glue Studio は、 AWS Glue で抽出、変換、ロード (ETL) ジョブを簡単に作成、実行、監視できるようにするグラフィカルインターフェイスです。 DataBrew は、コードを書かずにデータをクレンジングおよび正規化できる可視的なデータプレパレーションツールです。DataBrewで提供されている 200 を超える変換ステップを、AWS Glue Studio ビジュアルジョブで使用できるようになりました。 DataBrew において、レシピは、直感的なビジュアルインターフェイスで対話的に作成できる一連のデータ変換ステップです。このブログでは、DataBrew でレシピを作成し、それを AWS Glue Studio ビジュアル ETL ジョブの一部として適用する方法を説明します。 既存の DataBrew ユーザーもこの統合の恩恵を受けることができます。高度なジョブ設定と最新の AWS Glue エンジンバージョンを使用できることに加えて、AWS Glue Studio が提供している他のすべてのコンポーネントを使用して、より大規模なビジュアルワークフローの一部としてレシピを実行できるようになります。 この統合により、両方のツールの既存ユーザーに明確なメリットがもたらされます。 AWS Glue Studio では、全体的な ETL ダイアグラムをエンドツーエンドで一元的に表示できます。 DataBrew コンソール上で、値・統計・分布を確認しながらレシピをインタラクティブに定義し、テストおよびバージョン管理された処理ロジックを AWS Glue Studio ビジュアル ジョブで再利用できます。 AWS Glue ETL ジョブで複数の DataBrew レシピを統合でき、AWS Glue ワークフローを使用して複数のジョブを統合できます。 DataBrew レシピでは、増分データ処理のためのブックマーク、自動再試行、自動スケール、小さなファイルのグループ化などの AWS Glue ジョブ機能を使用して効率化を図ることができるようになります。 ソリューション概要 今回のユースケース例では、このブログ用に作成された医療請求データセットをクレンジングすることが要件となります。サンプルデータには、データプレパレーションにおける DataBrew の機能を実践するために意図的にいくつかのデータ品質の問題を組み込んでいます。次に、別のデータソースから取得した医療事業者に関する関連情報を追加して、請求データをデータカタログに取り込みます。 (そうすることでアナリストが可視化できるようになります)。 このソリューションは、請求データと医療事業者データの 2 つの CSV ファイルを読み取る AWS Glue Studio ビジュアルジョブで構成されます。このジョブは、データの品質問題に対処するために、請求データにレシピを適用させて、医療事業者データから必要な列を選択した上で、両方のデータセットを結合して、最後に結果を Amazon Simple Storage Service (Amazon S3) に保存して、データカタログ上にテーブルを作成します。出力データは、 Amazon Athena などの他のツールで使用できます。 DataBrew レシピの作成 まず、サンプルデータとして、請求データをデータストアに登録します。そうすることで、実際のデータを使用してインタラクティブエディターでレシピを作成できるようになり、変換を定義する際にその結果をレビューできるようになります。 次のリンクから請求データの CSV ファイルをダウンロードします: alabama_claims_data_Jun2023.csv 。 DataBrew コンソールのナビゲーション ペインで [データセット] を選択し、[新しいデータセットの接続] を選択します。 [ファイルをアップロード] オプションを選択します。 [データセット名] に Alabama Claims と入力します。 [アップロードするファイルを選択します] で、ローカル PC にダウンロードしたファイルを選択します。 [S3 送信先を入力] で、使用しているAWSアカウントとリージョンにあるバケット名を入力または参照します。 残りのオプションはデフォルトのままにし (CSV はカンマとヘッダーで区切られます)、データセットの作成を完了します。 ナビゲーションペインで [プロジェクト] を選択し、[プロジェクトの作成] を選択します。 プロジェクト名として、 ClaimsCleanup と入力します。 [レシピの詳細] の [アタッチされたレシピ] で、[新しいレシピを作成] を選択し、名前を ClaimsCleanup-recipe とし、 Alabama Claims データセットを選択します。 DataBrew に 適切な既存の IAM ロール を選択するか、新しい IAM ロールを作成します。これで、プロジェクトの作成は完了です。 以上で、構成可能なデータのサブセットを使用してセッションが作成されます。セッションの初期化が完了すると、一部のセルに無効な値または欠落した値が含まれていることがわかります。 Diagnosis Code 、 Claim Amount 、および Claim Date の列の値が欠落しており、データの一部の値には余分な文字が含まれています。 Diagnosis Code の値には「code 」(スペースが含まれる) という接頭辞が付く場合があり、 Procedure Code の値には、末尾に一重引用符が付いています。 Claim Amount の値は一部の計算に使用される可能性があるため、数値型に変換し、 Claim Date は Data 型に変換する必要があります。 対処すべきデータ品質の問題を特定したので、各問題をどのように対処するかを決定する必要があります。 レシピステップを追加するには、列のコンテキストメニュー、上部のツールバー、またはレシピの概要からなど、複数の方法があります。最後の方法を使用すると、指定されたステップタイプを検索して、このブログで作成したレシピを複製できます。 今回のユースケースでは Claim Amount は不可欠な値であるため、欠損のある行を削除することにします。 [欠損した値を削除] のステップを追加します。 ソース列で、[Claim Amount] を選択します。 デフォルトのアクション [欠落した値がある行を削除する]のままにし、[適用] を選択して保存します。 ステップの適用を反映してビューが更新され、 Claim Amount が欠損している行はなくなりました。 Diagnosis Code は空でもよいですが、 Claim Date には合理的に推測された値が必要です。データ内の行は時系列で並べ替えられるため、プレビューの前の行の有効な値を使用して、欠落している日付を代入できます。毎日請求が発生していると仮定すると、最大の問題は、その日の最初の請求データの日付が欠落している場合に、プレビューの日付が割り当てられてしまうことです。今回は説明のために、潜在的なエラーは許容できると考えてみましょう。 まず、列を string 型から date 型に変換します。 [型の変更] のステップを追加します。 ソース列として [Claim Date] を選択し、型として[date] を選択し、[適用] を選択します。 次に、欠落した日付を代入するために、[欠落した値を埋める/帰属] ステップを追加します。 ソース列に [Claim Date]、アクションとして [最後の有効な値で埋める] を選択します。 [変更のプレビュー] を選択して検証し、[適用] を選択してステップを保存します。 下記の画像のように、ここまででレシピには 3 つのステップが存在しているはずです。 次に、[引用符の削除] ステップを追加します。 ソース列に [Procedure Code]、削除する値に [先頭と末尾の引用符] を選択します。 プレビューにてステップが反映されていることを確認し、新しいステップとして適用します。 [特殊文字を削除] のステップを追加します。 ソース列に [Claim Amount] 選択し、[カスタム特殊文字] の [カスタム特殊文字を入力] に $ を入力します。 [型を変更] ステップを追加し、ソース列 [Claim Amount] 、タイプを [double] とします。 最後のステップとして、余分な “code ” プレフィックスを削除するために、[値またはパターンの置き換え] ステップを追加します。 ソース列で [Diagnosis Code] を選択し、[カスタム値を入力] に code と入力します (末尾にスペースを入れます)。 サンプルで特定したすべてのデータ品質の問題に対処したので、プロジェクトをレシピとして公開します。 レシピペインで [発行] を選択し、オプションでバージョンの説明を入力してレシピの発行を完了します。 発行するたびに、異なるバージョンのレシピが作成され、使用するレシピのバージョンを選択できるようになります。 AWS Glue Studio でビジュアル ETL ジョブを作成 次に、レシピを使用するジョブを作成します。次の手順を実行します。 AWS Glue Studio コンソールのナビゲーションペインで [Visual ETL] を選択します。 [Visual with a blank canvas] を選択し、ビジュアル ジョブを作成します。 ジョブの上部の “Untitled job” を任意の名前に置き換えます。 [Job Details] タブで、ジョブが使用するロールを指定します。 これは、Amazon S3 および AWS Glue データカタログへのアクセス許可を持つ、 AWS Glue に適した AWS Identity and Access Management (IAM) ロールである必要があります。先ほど DataBrew で使用したロールはジョブの実行には使用できないため、ここでは [IAM ロール] ドロップダウン メニューにはリストされないことに注意してください。 DataBrew ジョブとは違い、AWS Glue Studio では、ワーカー サイズ、自動スケーリング、 柔軟な実行 などのパフォーマンスとコストの設定を選択できるほか、最新の AWS Glue 4.0 ランタイムを使用することで大幅なパフォーマンスの改善を受けることができることに注目してください。このジョブでは、デフォルトの設定を使用できますが、節約のためにワーカーの数を減らします。この例では、2 Wokers で十分です。 [Visual] タブで、S3 ソースを追加し、 Providers という名前を付けます。 S3 URL には、 s3://awsglue-datasets/examples/medicare/Medicare_Hospital_Provider.csv と入力します。 データフォーマットとして [CSV] を選択し、[Infer schema] を選択します。 これで、ファイルヘッダーを使用してスキーマが [Output schema] タブにリストされます。 このユースケースでは、providers データセット内のすべての列を必要としないため、残りは削除できます。 Providers ノードを選択した状態で、Transforms で [Drop Fields] を追加します (Node parents を選択しなかった場合は、Node parents を手動で割り当てます)。 Provider Zip Code 以降のフィールドをすべて選択します。 その後、この Providers データを、Alabama 州の 請求データと結合します。ただし、2 番目のデータセットには州の情報がありません。Providers データから、必要なデータをフィルタリングすることで結合を最適化できます。 [Drop Fields] の子としてTransforms から[Filter] 追加します。 Alabama providers と名前を付け、Provider State が AL と一致するという条件を追加します。 2番目のソース (新しい S3 ソース) を追加し、 Alabama claims という名前を付けます。 S3 URL を入力するには、別のブラウザ タブで DataBrew を開き、ナビゲーションペインで [データセット] を選択し、表に表示されている Alabama claims の場所をコピーします (http リンクではなく、s3:// で始まるテキストをコピーします)。次に、ビジュアルジョブに戻り、S3 URL 欄に貼り付けます。正しい場合は、[Output schema] タブにデータフィールドがリストされていることがわかります。 CSV 形式を選択し、他のソースの場合と同様に [infer schema] します。 このソースの子として、ノードの追加メニューで recipe と検索し、[Data Preparation Recipe] を選択します。 新しいノードのプロパティで、 Claim cleanup Recipe という名前を付け、先ほど発行したレシピとバージョンを選択します。 ここでレシピの手順を確認し、必要に応じて DataBrew へのリンクを使用して変更を加えることができます。 結合ノードを追加し、 Alabama providers と Claim cleanup recipes の両方を親として選択します。 両方のソースの provider ID を結合条件として追加します。 最後のステップとして、S3 ノードをターゲットとして追加します (検索時に表示される最初のノードはソースであることに注意してください。ターゲットとして表示されるものを必ず選択してください)。 ノード設定では、デフォルト形式の JSON のままにし、ジョブの IAM ロールが書き込み権限を持つ S3 URL を入力します。 さらに、データ出力をカタログ内のテーブルとして利用できるようにします。 [データ カタログの更新オプション] セクションで、上から 2 番目のオプション [データ カタログにテーブルを作成し、その後の実行でスキーマを更新し、新しいパーティションを追加する] を選択し、テーブルを作成する権限があるデータベースを選択します。 名前を alabama_claims とし、partition key として Claim Date を選択します (これは説明のためであり、今回のような小さなテーブルでは、後でデータを追加しない場合、実際にはパーティションを必要としません)。 ジョブを保存してジョブを実行します。 [Run] タブでは、ジョブ ID リンクを使用してプロセスを追跡し、詳細なジョブメトリクスを確認できます。 ジョブが完了するまでに数分かかります。 ジョブが完了したら、Athena コンソールに移動します。 選択したデータベースでテーブル alabama_claims を検索し、コンテキスト メニューを使用して [テーブルのプレビュー] を選択します。これにより、テーブルに対して単純な SELECT * SQL ステートメントが実行されます。 ジョブの結果から、データが DataBrew レシピによってクレンジングされ、AWS Glue Studio の結合処理によって強化されたことがわかります。 Apache Spark は、AWS Glue Studio で作成されたジョブを実行するエンジンです。生成されるイベント ログ上で Spark UI を使用すると、ジョブの計画と実行に関するインサイトを表示でき、ジョブのパフォーマンスと潜在的なパフォーマンスのボトルネックを理解するのに役立ちます。たとえば、大規模なデータセットに対するこのジョブの場合、これを使用して、結合処理を実行する前にプロバイダーの状態を明示的にフィルタリングすることの影響を比較したり、自動バランス変換を追加して並列処理を改善することでメリットが得られるかどうかを確認できます。 デフォルトでは、ジョブは Apache Spark イベント ログを s3://aws-glue-assets-<アカウント ID>-<リージョン名>/sparkHistoryLogs/ のパスに保存します。ジョブを表示するには、 いずれかの方法 を使用して History server をインストールする必要があります。 後片付け このソリューションが不要になった際は、Amazon S3 に格納された生成ファイル、ジョブによって作成されたテーブル、DataBrew レシピ、および AWS Glue ジョブを削除してください。 まとめ このブログでは、AWS DataBrew のインタラクティブエディターを使用してレシピを作成し、発行されたレシピを AWS Glue Studio ビジュアル ETL ジョブの一部として使用する方法を説明しました。データプレパテレーションを実施して、AWS Glue Catalog のテーブルにデータを取り込む際に必要な一般的なタスクの例をいくつか含めました。 この例ではビジュアルジョブで 1 つのレシピを使用しましたが、ETL プロセス内で複数のレシピを使用したり、複数のジョブで同じレシピを再利用することも可能です。 これらの AWS Glue ソリューションを使用すると、コードを記述することなく、構築と運用が簡単な高度な ETL パイプラインを効果的に作成できます。両方のツールを組み合わせたソリューションをすぐに開始できます。 この記事は、Sr. Software Dev Engineer の Mikhail Smirnov とSr. Big Data Architect の Gonzalo Herreros が執筆しています。日本語訳はソリューションアーキテクトの三宅が翻訳しました。原文は こちら です。 執筆者について Mikhail Smirnov is a Sr. Software Dev Engineer on the AWS Glue team and part of the AWS Glue DataBrew development team. Outside of work, his interests include learning to play guitar and traveling with his family.   Gonzalo Herreros  is a Sr. Big Data Architect on the AWS Glue team. Based on Dublin, Ireland, he helps customers succeed with big data solutions based on AWS Glue. On his spare time, he enjoys board games and cycling.

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週、東京リージョンで利用開始になったことが話題になった Amazon Bedrock をはじめとして、AWSでは多様な生成系AI（Generative AI）サービスが用意されていますが、その生成系AIに関するイベントが今週17日（火）から3日間の日程で開催されます。生成系AIやLLMの基本が学べる初日、ユーザー事例多数の2日目、BedrockをはじめとするAWSサービスの高度な使い方を解説する3日目と充実した内容になっています。オンライン開催でどこからでも参加できますので、ご興味がある方はぜひ以下より登録してご参加ください。 – 生成系 AI を中心とした AI 最前線がここに AWS AI Week For Developers それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月9日週の主要なアップデート 10/9(月) AWS Glue now supports GitLab, BitBucket in its Git integration feature AWS Glue はETL処理のためのソースコードをGitサービスで管理することが可能です。これまではAWS CodeCommitおよびGitHubに対応していましたが、今回の発表でGitLabとBitBucketに対応し、より多様なコード管理環境に対応可能になりました。 AWS Verified Access is now available in two additional AWS regions AWS Verified Access が利用可能なリージョンとして、東京リージョンおよびシンガポールリージョンが追加されました。Verified Access はゼロトラストの基本原則に基づいて社内リソースにアクセス可能にするための環境を提供するサービスです。 10/10(火) Amazon Linux announces support for Ansible and Corretto 21 with AL2023.2 Amazon Linux 2023 の四半期アップデートの2回目、AL2023.2がリリースされました。これには無料のOpenJDKディストリビューションである Amazon Corretto 21 とAnsibleが含まれています。Amazon Linux 2023のリリースの考え方は こちらのブログ をご覧ください。 Announcing pgactive: Active-active Replication Extension for PostgreSQL on Amazon RDS pgactive が Amazon RDS for PostgreSQL で利用可能になりました。PostgreSQL 15.4-R2以降で利用可能です。pgactiveは複数のPostgreSQLデータベース間でactive-activeのレプリケーションを実現するextensionです。詳細は こちらのブログ をご覧ください。 10/11(水) Amazon FSx for NetApp ONTAP is now available in the AWS Asia Pacific (Osaka) Region Amazon FSx for NetApp ONTAP が大阪リージョンで利用可能になりました。Amazon FSx for NetApp ONTAP はフルマネージドの共有ストレージであり、 ONTAP のデータアクセスおよび管理機能が利用可能なサービスです。東京リージョンのFSx for Netapp ONTAPと SnapMirror によるレプリケーションを利用することも可能です。 New Amazon CloudWatch metric monitors EC2 instance reachability to EBS volumes Amazon CloudWatch にAttached EBS Status Check (StatusCheckFailed_AttachedEBSメトリクス)が追加されました。EBSボリュームとEC2間で通信が可能か、IO操作が可能かをチェックするメトリクスで、これを監視することでEBSボリュームで異常が発生した際に素早く問題に気づくことができます。 10/12(木) Amazon SageMaker Canvas expands content summarization and information extraction capabilities コードの記述なしで、機械学習モデルの学習や利用ができる Amazon SageMaker Canvas では、すぐに利用できる(ready-to-use)モデルとして、生成系AIのFM（Anthropic Claude 2 や Amazon Titan など）を利用した、コンテンツの要約と情報抽出(content summarization and information extraction)が用意されています。今回追加機能として、ユーザーが提供するドキュメント（インデックス）を指定可能になりました。現時点ではAmazon Kendraがドキュメントソースとして利用可能です。これによりKendraに格納した情報を知識源としたチャットベースの分析環境をコーディング不要で実現可能です。 AWS Step Functions launches Optimized Integration for Amazon EMR Serverless AWS Step Functions が Amazon EMR Serverless をネイティブにサポートし、EMR Serverless の API Actionとして CreateApplication, StartApplication, StopApplication, DeleteApplication, StartJobRun, CancelJobRun が呼び出せるようになりました。 Announcing new AWS Network Load Balancer (NLB) availability and performance capabilities AWS Network Load Balancer (NLB)で新たに3つの機能が追加されました。1つ目は Availability Zone DNS affinity で、DNSで同一AZ内でのターゲットを返す機能、2つ目は disable connection termination for unhealthy targets　でヘルスチェックに失敗した接続の切断をしないようにする機能、3つ目は UDP connection termination by default で、UDP接続にデフォルトでタイムアウトが設定されるようになったというものです。 Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC AWS Lambda で dual-stack構成のVPC内のリソースにIPv6でアクセスすることが可能になりました。これにより、VPC内のIPv4アドレスの残量を気にすることなくLambda関数を並列実行できるようになり、より大規模な利用がしやすくなりました。 10/13(金) Amazon EC2 C7gd, M7gd, and R7gd instances now available in additional regions Amazon EC2 の C7gd, M7gd, R7gd インスタンスが新たに東京リージョンとシンガポールリージョンで利用可能になりました。AWS Graviton3プロセッサに加え、ローカルストレージを搭載したインスタンスです。また、合わせて C7gd がシドニーリージョンで利用可能になったことがアナウンスされています。 Deploy ML models built in SageMaker Canvas to SageMaker real-time endpoints Amazon SageMaker Canvas では作成したMLモデルにデータを与えることでバルクで予想を出力させることが可能ですが、今回、これに加えてリアルタイム予測エンドポイントをデプロイすることが可能になりました。アプリケーションからAPIで呼び出すことで、リアルタイムに予測値を得ることが可能です。 Amazon EC2 now supports setting AMIs to a disabled state EC2のAmazon Machine Images (AMIs) でAMIをdisable（無効）に設定可能になりました。以前にパブリックに公開したAMIであっても、disableするとそこからEC2を起動することはできなくなります。 余談ですが、最後に紹介したAMIのアップデートの文中で、”Amazon Machine Images (AMIs; pronounced ah-mee)”という珍しい注記が含まれていました。AMI＝アーミィと発音しますということなのですが、良く質問があったのでしょうか？ちなみに筆者（下佐粉）は、エーエムアイ派です：） それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

北半球は美しい初秋の季節です。米国では地元のファーマーズマーケットやコーヒーショップがパンプキンに占領されています。re: Invent 2023まで後 50 日です。 Pre:Invent の公式シーズンの前に、10月2日週のエキサイティングなニュースや発表をいくつか見てみましょう。 10月2日週のリリース 私が注目したリリースを以下に記載しました。 AWS Control Tower – AWS Control Tower は、お客様の規制要件を満たし、転送中のデータの暗号化、保管中のデータの暗号化、強力な認証の使用などの統制目標を満たすために役立つ 22 のプロアクティブコントロールと 10 の AWS Security Hub 発見的コントロールをリリースしました。コントロールの詳細とリストについては、 AWS Control Tower ユーザーガイド を参照してください。 Amazon Bedrock – 米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンで Amazon Bedrock の提供 が開始されてからわずか 1 週間後、Amazon Bedrock は アジアパシフィック (東京) の AWS リージョンで利用可能 になりました。基盤モデルで生成系 AI アプリケーションの構築とスケーリングを開始するには、 Amazon Bedrock ドキュメント を参照して、 community.aws の生成系 AI スペース を探索し、 Amazon Bedrock ワークショップ の演習を利用してください。 Amazon OpenSearch Service – 検索、オブザーバビリティ、セキュリティ分析、機械学習 (ML) 機能が強化された OpenSearch バージョン 2.9 を Amazon OpenSearch Service で実行できるようになりました。OpenSearch Service は、バージョン 2.9 で 地理空間集約サポートを拡張 し、傾向とパターンの高レベルの概要のインサイトを収集してデータ内の相関関係を確立できるようになりました。OpenSearch Service 2.9 には、OpenTelemetry などの新しいスキーマ標準を活用するための OpenSearch Service Integrations も付属 するようになりました。また、ダッシュボードでの アラートと異常の管理、および視覚化折れ線グラフへのオーバーレイ が可能になりました。 Amazon SageMaker – SageMaker 特徴量ストアが、完全マネージド型のインメモリオンラインストアをサポート するようになり、高スループットの ML アプリケーション用のモデル提供に必要な特徴量をリアルタイムで取得できます。新しいオンラインストアは、オープンソースの Redis 上に構築されたインメモリデータストアである ElastiCache for Redis を利用しています。詳細については、 SageMaker デベロッパーガイド を参照してください。 また、 SageMaker Model Registry はプライベートモデルリポジトリのサポートを追加 しました。プライベート Docker リポジトリに保存されているモデルを登録し、複数のプライベート AWS モデル リポジトリと AWS 以外のモデルリポジトリにわたるすべてのモデルを 1 つの中央のサービスで追跡できるようになったので、スケールでの ML 運用 (MLOps) と ML ガバナンスを簡素化できます。使用を開始する方法については、 SageMaker デベロッパーガイド を参照してください。 Amazon SageMaker Canvas – SageMaker Canvas のサポートが拡張され、すぐに使えるモデルに基盤モデル (FM) が含まれるようになりました 。ノーコードのチャットインターフェースから、Claude 2、Amazon Titan、Jurassic-2 (Amazon Bedrock 搭載) などの FM だけでなく、Falcon や MPT (SageMaker JumpStart 搭載) などの公開されているモデルにもアクセスできるようになりました。詳細については、 SageMaker デベロッパーガイド を参照してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 オープンソースデータベースへの AWS の貢献の舞台裏 – この投稿では、過去 2 年間に AWS がアップストリームのデータベースに対して行ってきた重要なオープンソースの貢献をいくつか紹介するとともに主要な貢献者を紹介し、AWS がデータベースサービスのアップストリーム作業にどのように取り組んでいるかを紹介します。 AWS Trainium による迅速で費用対効果の高い Llama 2 の微調整 – この記事では、LLM トレーニング専用のアクセラレータである AWS Trainium で Meta の Llama 2 モデルを微調整してトレーニング時間とコストを削減する方法を紹介します。 Meta の Code Llama コード生成モデルが Amazon SageMaker JumpStart で利用可能に – Meta が開発した Code Llama FM を ワンクリックで SageMaker JumpStart にデプロイできるようになりました。この投稿では、詳細が手順ごとに説明されています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 Build On Generative AI – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が盛り上がりを見せています。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 今日のエピソード では、Emily と Darko が非構造化ドキュメントを構造化データに変換する方法について解説しました。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーたちが主催するコミュニティ主導のカンファレンスにご参加ください: DMV (DC、メリーランド、バージニア) (10 月 13 日)、 イタリア (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月9日週はここまでです。10月16日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

コンピューティング最適化 Amazon EC2 C6a インスタンス は 2022 年 2 月にリリースされました。これは、第 3 世代 AMD EPYC (Milan) プロセッサを搭載しており、最大 3.6 GHz の周波数で動作します。 10月4日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しいコンピューティング最適化 Amazon EC2 C7a インスタンスの一般提供の開始をお知らせします。このインスタンスでは、C6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減を実現できます。 C7a インスタンスは、C6a インスタンスと比較して最大 50% 高いパフォーマンスを実現します。これらのインスタンスは、高性能ウェブサーバー、 バッチ処理 、 広告配信 、 機械学習 、 マルチプレイヤーゲーム 、 動画エンコーディング 、科学モデリングなどの ハイパフォーマンスコンピューティング (HPC) 、 機械学習 などのコンピューティングを多用するワークロードの実行に最適です。 C7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (brain floating point) をサポートします。これらのインスタンスは、メモリ内のデータへの高速アクセスを可能にする Double Data Rate 5 (DDR5) メモリを備えており、前世代のインスタンスと比較して 2.25 倍のメモリ帯域幅を提供してレイテンシーを低減します。 C7a インスタンスは、最大 192 個の vCPU と 384 GiB の RAM を備えています。これにより、新しい中サイズのインスタンスが利用して、ワークロードのサイズをより正確に調整できるようになりました (1 個の vCPU、2 GiB を提供します)。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c7a.medium 1 2 最大 12.5 最大 10 c7a.large 2 4 最大 12.5 最大 10 c7a.xlarge 4 8 最大 12.5 最大 10 c7a.2xlarge 8 16 最大 12.5 最大 10 c7a.4xlarge 16 32 最大 12.5 最大 10 c7a.8xlarge 32 64 12.5 10 c7a.12xlarge 48 96 18.75 15 c7a.16xlarge 64 128 25 20 c7a.24xlarge 96 192 37.5 30 c7a.32xlarge 128 256 50 40 c7a.48xlarge 192 384 50 40 c7a.metal-48xl 192 384 50 40 C7a インスタンスは最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅を備えており、最大 128 個の EBS ボリュームをインスタンスにアタッチできます (前世代のインスタンスの EBS ボリュームアタッチメントは最大 28 個)。 C7a インスタンスは、AMD セキュアメモリ暗号化 (SME) を使用した常時オンのメモリ暗号化と、暗号化および復号アルゴリズム、畳み込みニューラルネットワーク (CNN) ベースのアルゴリズム、財務分析、および動画エンコーディングワークロードを高速化するための新しい AVX-512 命令 をサポートします。また、C7a インスタンスは、セキュリティを強化するために AES-256 をサポートします (C6a インスタンスでは AES-128)。 これらのインスタンスは AWS Nitro System 上に構築されており、ハイパフォーマンスコンピューティングや動画処理など、ネットワークレイテンシーの低減や、高度にスケーラブルなノード間通信の恩恵を受けるワークロード向けに Elastic Fabric Adaptor (EFA) をサポートしています。 今すぐご利用いただけます Amazon EC2 C7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でのお支払いと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 C7a インスタンスページ と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

2023 年 10 月 5 日木曜日に開催される参加無料のオンラインイベントである Data and Generative AI Day にぜひご参加ください。AWS は、 LinkedIn Live や YouTube などの複数のプラットフォームでイベントを同時にストリーミングします。 生成系 AI の領域では、組織のデータに秘められた力と可能性がこれまで以上に大きくなっています。生成系 AI には、顧客とのやり取りを再構築し、従業員の生産性を向上させ、創造的なアイデア出しを刺激し、画期的なイノベーションを推進する力があります。しかし、先進的なリーダーとして、このデータ駆動型の可能性を最大限に活用し、それを目に見える成果に変えるには、どのようなステップが必要となるのでしょうか? この半日間のイベントでは、AWS のエキスパート、パートナー、お客様、主要なスタートアップが、今日の進化し続ける環境の中で、データと生成系 AI を使用してイノベーションを推進する取り組みについてのインサイトを提供します。この革新的なテクノロジーがもたらすさまざまな機会や課題にどのように対応すべきかについて、業界リーダーからの実践的なガイダンスを得ながら、同時に将来に何が待ち受けているかを感じ取ることができます。 このイベントで予定されているハイライトをいくつかご紹介します。 AWS の Database, Analytics, and ML 担当 VP である Swami Sivasubramanian がイベントの開始に際して基調講演を行い、ビジネスリーダー向けにデータと AI を民主化するための青写真を共有します。Swami は、リーダーが生成系 AI の可能性を実際のビジネス価値に変えるための正しい考え方、戦略、ツールをどのように採り入れることができるのかについて語ります。 AWS の Enterprise Strategy 担当 Director である Tom Godden は、生成系 AI を活用してビジネスの成果を推進するための実践的な戦略について詳しく説明します。Tom は、組織全体で生成系 AI を試験運用する機会を特定するためのフレームワークを共有するとともに、これらの強力な新機能の活用方法について、ビジネスリーダーが時宜にかなったかたちで理解できるように説明します。 Informatica の Strategic Cloud Ecosystems 担当 Vice President である Gopinath Sankaran 氏は、生成系 AI がデータ管理に及ぼす影響に関するインサイトを共有するとともに、Informatica の AI を活用した Intelligent Data Management Cloud と AWS の AI および分析サービスが、インサイトとエクスペリエンスの新しい波をどのように強化できるかを探ります。 Deloitte の Data & AI 担当 Managing Director である Diego Saenz 氏と、Deloitte の Global Financial Services Industry (GFSI) Data, Analytics, & AI 担当 Principal の Jojy Matthew 氏は、綿密に練られたデータ戦略が、生成系 AI の成功にとって何を意味するかを共有します。Diego は、生成系 AI を活用してビジネス成果を推進するためにデータ資産の準備が整っているかどうかを評価するための実践的なアドバイスを共有します。 AWS のリーダー、ならびに AWS のお客様である FOX、Salesforce、および Booking.com は、データと生成系 AI に関する取り組みを共有し、この革新的なテクノロジーを活用して顧客と従業員のエクスペリエンスを再考する方法について説明します。 イベントページ でご登録いただくと、カレンダーにイベントリマインダーを追加できます。 当日お会いできるのを楽しみにしています。 – Irshad 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、列レベルのデータ暗号化をサポートしています。列レベルの暗号化では、すべての列または選択した列に適用できるより詳細なレベルのデータを暗号化できます。列レベルの暗号化では、列ごとに異なる暗号化キーを定義できます。 SQL Server では、接続、データ、ストアドプロシージャに暗号化を使用できます。暗号化の詳細については、「 SQL Server 暗号化 」を参照してください。 この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を紹介します。 SQL Server の暗号化 Amazon RDS は、 データベースインスタンス 、 自動バックアップ 、 リードレプリカ 、 スナップショット の基盤となるストレージを保護するために、 AWS Key Management Service (AWS KMS) を使用して 保存時の暗号化 をネイティブに提供します。 Amazon RDS for SQL Server は、Microsoft SQL Server Enterprise Edition と Standard Edition でサポートされている透過的データ暗号化 (TDE) をサポートしています。 TDE はデータベース内の機密データを暗号化し、証明書を使用してデータを暗号化するキーを保護します。このソリューションでは、キーを持っていない人がデータを使用できないようにします。この種の保護は事前に計画しておく必要があります。TDE は、データおよびログファイルの I/O 暗号化と復号化をリアルタイムで行います。暗号化にはデータベース暗号化キー (DEK) を使用します。データベースブートレコードには、復旧時に使用できるようにキーが保存されます。DEK は対称キーです。サーバーのプライマリデータベースに保存される証明書または EKM モジュールが保護する非対称キーによって保護されます。 TDE は保存中のデータ、つまりデータファイルとログファイルを保護します。これにより、さまざまな業界で確立されている多くの法律、規制、ガイドラインに従うことができます。この機能により、ソフトウェア開発者は既存のアプリケーションを変更せずに AES および 3DES 暗号化アルゴリズムを使用してデータを暗号化し、データがストレージから読み取られるとデータを自動的に復号化できます。不正な復号化を防ぐために、TDE は暗号化キーをデータベース外部のセキュリティモジュールに保存します。データベースレベルの完全な暗号化を実装したいと考えているなら、TDE は良い選択肢です。 TDE はデータベース全体を暗号化しますが、列レベルの暗号化ではデータベース内の個々の列を暗号化できます。暗号化を行うと、対応する復号化キーやパスワードがないとデータが役に立たなくなります。暗号化を行ってもアクセス制御の問題は解決されません。ただし、一部のユースケースでは、アクセス制御がバイパスされてもデータ損失が制限され、セキュリティが強化されます。たとえば、データベースホストコンピューターの設定に誤りがあってハッカーが機密データを入手した場合、盗んだ情報が暗号化されていれば役に立ちません。 ソリューション概要 SQL Server の列レベルのデータ暗号化は、暗号化階層に基づいています。暗号化階層は、データと暗号化キーを保護するために使用されます。階層レベルは以下のとおりです。 Windows レベル – このレベルは、Windows データ保護 (DP) API を使用して次のレベルを暗号化して保護します。 SQL Server レベル – このレベルには Windows レベルで保護されているサービスマスターキー (SMK) が含まれています。SMK は次のレベルを保護するために使用されます。 データベースレベル – このレベルには、データベースマスターキー (DMK) と残りのキーと証明書が含まれます。DMK はデータベース内の証明書、対称キー、非対称キーを暗号化して保護します。 次の図は、完全な暗号化階層 ( Microsoft ドキュメント にあるアーキテクチャリファレンス) を示しています。 列レベルの暗号化は、対称キーまたは非対称キーをそれぞれ証明書またはパスワードと組み合わせて使用することで実現できます。次の図は、列レベルの対称暗号化と非対称暗号化の概要を示しています。 以下のセクションでは、両方の実装方法を示します。 方法 1: 対称キーによる列暗号化 対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、次のコマンドを使用して SMK が存在することを確認します。 Use Master go select * from sys.symmetric_keys go データベースの対称キーを作成するには、まず、対称キーストアの保護機能として機能するマスターキーと証明書を使用してユーザーデータベースを設定する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<password>’ 証明書を作成します。 use <dbname> CREATE CERTIFICATE <certificate-name> WITH SUBJECT = 'A label for this certificate' 対称キーを作成します。 use <dbname> CREATE SYMMETRIC KEY <key-name> WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE <certificate-name>; GO 列を暗号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE <certificate-name>; UPDATE <table-name> SET <encrypted-column-name> = EncryptByKey(Key_GUID('<key-name>’), <column-name>); 列を復号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE < certificate-name>; GO SELECT CONVERT(varchar, DecryptByKey(<encrypted-column-name>)) AS 'Decrypted-column’ FROM <table-name>; GO 方法 2: 非対称キーによる列暗号化 非対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、インスタンスの起動時に Amazon RDS ですでに作成されている SMK を確認します。 Use Master go select * from sys.symmetric_keys go ユーザーデータベースの非対称キーを作成するには、まずプライマリキーを使用してデータベースを設定し、次にパスワードで暗号化して非対称キーを作成する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<key-password>’ 非対称キーの作成します。 use <dbname> IF NOT EXISTS (SELECT * FROM sys.asymmetric_keys WHERE name = '<Asym-key-name>') BEGIN CREATE ASYMMETRIC KEY <Asym-key-name> WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = '<Asym-key-password>' ; END GO 列を暗号化します。 use <dbname> UPDATE <table-name> SET <encrypted-column-name> = ENCRYPTBYASYMKEY(ASYMKEY_ID('<Asym-key-name>'), <column-name>) GO 列を復号化します。 use <dbname> SELECT *, <Decrypted-column-name> = CONVERT(CHAR(11),DECRYPTBYASYMKEY(ASYMKEY_ID ('<Asym-key-name>'), <encrypted-column-name>, N'<Asym-key-password>’)) FROM <table-name>; GO まとめ この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を学びました。暗号化はセキュリティの確保に役立つ貴重な技術ですが、すべてのデータや接続に暗号化を考慮すべきではありません。暗号化を実装するかどうかを決めるときは、ユーザーがどのようにデータにアクセスするかを検討してください。ユーザーがパブリックネットワーク経由でデータにアクセスする場合は、セキュリティを強化するためにデータを暗号化することを強くお勧めします。ただし、すべてのアクセスがセキュアに設定されたイントラネットの中にある場合は、暗号化は必要ない場合があります。暗号化を使用する際には、パスワード、キー、証明書のメンテナンス方法も含める必要があります。 著者について Kiran Mulupuru は、アマゾンウェブサービスのデータベーススペシャリストテクニカルアカウントマネージャーです。Amazon RDS と Amazon Aurora データベースを専門としています。彼女はお客様と協力して、データベースの運用パフォーマンスに関する技術支援を提供し、データベースのベストプラクティスを共有しています。 Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、Microsoft SQL Server を実行している DB インスタンスに保存されているデータを暗号化するための 透過的データ暗号化 (TDE) をサポートしています。 TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージからデータを読み取るときにデータを復号化します。 TDE 証明書の有効期限は、証明書がいつ作成されて有効期限と関連付けられるかによって異なります。Amazon RDS for SQL Server の場合、TDE 証明書は、 オプショングループ を使用してインスタンスで TDE を有効にした日から1 年後に有効期限が切れます。この TDE 証明書の有効期限が切れると、監査の観点から RDS for SQL Server インスタンスがコンプライアンス違反になります。ただし、証明書の有効期限が切れても TDE の動作は停止しません。 TDE が有効になっている Amazon RDS for SQL Server で適切な監査とコンプライアンスを確保するためのベストプラクティスとして、TDE 証明書を RDS for SQL Server インスタンスで毎年ローテーションする必要があります。これには、新しい証明書を作成し、既存の証明書の有効期限が切れる前に新しい証明書を使用することが含まれます。 ソリューション概要 TDE 暗号化階層には、サービスマスターキー (SMK) を暗号化する Windows オペレーティングシステムレベルのデータ保護 API (DPAPI) をはじめとする複数の保護レベルが含まれます。この SMK はプライマリデータベースのデータベースマスターキー (DMK) を暗号化し、TDE 用に作成された証明書の秘密キーを保護します。この証明書はデータベース暗号化キー (DEK) を保護し、それによってデータが暗号化および復号化されます。 次の図は、完全な暗号化階層 ( Microsoft からのアーキテクチャリファレンス) を示しています。 DEK は対称キーであり、SMK や DMK のように変化しません。ただし、証明書は作成プロセスの一環として有効期限付きで生成されるため、ローテーションが必要になります。次の図は、Amazon RDS for SQL server に TDE をハイレベルに実装するためのリファレンスアーキテクチャを示しています。 実装 TDE 対応の Amazon RDS for SQL Server で TDE 証明書を定期的にローテーションするには、次のステップを実行します。このプロセスにはダウンタイムは発生しないことに注意してください。ただし、大規模なデータベースを使用する場合はインスタンスのパフォーマンスを監視する必要があります。 RDS for SQL Server インスタンスがマルチ AZ モードの場合は、シングル AZ モードに変更します。   TDE オプションは永続的なオプション であり、すべての DB インスタンスとバックアップがオプション グループから関連付け解除されない限り、オプション グループから削除できないからです。 TDE 証明書の詳細を確認します。 USE [master] GO SELECT name FROM sys.certificates WHERE name LIKE 'RDSTDECertificate%' GO 暗号化されたデータベースを確認します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO TDE を無効化します。 USE [DBNAME] ALTER DATABASE [DBNAME] SET ENCRYPTION OFF GO USE [DBNAME] DROP DATABASE ENCRYPTION KEY GO TDE を検証します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO 復旧モデルを SIMPLE に変更します。これにより、ログファイル内の暗号化された値をすべて消去できます。 注意 : 復旧モデルを変更すると、 DMS のような復旧モデルに依存しているサービス に影響がある可能性があります。Amazon RDS for SQL Server の復旧モデル変更に関しては こちら をご参照ください。 ALTER DATABASE [DBNAME] SET RECOVERY SIMPLE GO 復旧モデルを FULL に変更します。 ALTER DATABASE [DBNAME] SET RECOVERY FULL GO TDE が有効になっていないオプショングループに切り替えるようにインスタンスを変更します。   この結果、古い TDE 証明書は RDS for SQL Server インスタンスから完全に削除されます。オプショングループの詳細については、「 オプショングループを使用する 」と「 オプショングループにオプションを追加する 」を参照してください。 RDS インスタンスが使用可能になったら、オプショングループに TDE オプションを追加すると、新しい証明書が生成されます。   データベース復旧モデルが FULL – SIMPLE – FULL と変更すると、新しいスナップショットが作成されます。 スナップショットが完成したら、Amazon RDS コンソールを使用してインスタンスをマルチ AZ に戻します。 オプショングループをアタッチし、シングル AZ に変更してからマルチ AZ に変更し直しても、ダウンタイムは発生しません。ただし、データベース復旧モードとマルチ AZ が変更されるため、このプロセス中は高可用性とポイントインタイムリカバリ (PITR) に影響があります。 Amazon RDS for SQL Server での TDE の制限事項 このソリューションには以下の制限があります。 このソリューションは、SQL Server 2019 Standard Edition と Enterprise Edition、および SQL Server 2012-2017 Enterprise Edition でのみサポートされています。 Amazon RDS は TDE 証明書のインポートまたはエクスポートをサポートしていません。 TDE 対応データベースのネイティブバックアップは作成できますが、そのバックアップをオンプレミスデータベースに復元することはできません。TDE 対応のオンプレミスデータベースのネイティブバックアップは復元できません。 まとめ この投稿では、RDS for SQL Server インスタンスで TDE 証明書をローテーションする方法を学びました。この方法を使うと、証明書の有効期限が切れる前に TDE 証明書を適時にローテーションし、インスタンスが適切にコンプライアンスを守れるようにすることができます。 著者について Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 Saroj Kumar Das は、アマゾンウェブサービスのクラウドサポートエンジニアです。彼は AWS のお客様と仕事をしており、SQL Server に特化した Amazon RDS データベースプラットフォームに関する深い技術的専門知識を提供しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

生成系 AI (Generative AI) への関心が広まったことで、ビジネス上の課題、特に顧客サービスの課題を解決するために AI の利用に再び注目が集まっています。生成系 AI は、会話、ストーリー、画像、動画、音楽など、新しいコンテンツやアイデアを生み出すことができる AI の一種です。 マッキンゼー によると、カスタマーエクスペリエンス (CX) は生成系 AI のトップユースケースの 1 つです。同社は生成系 AI をカスタマーケア領域に適用することで、生産性コストが 30 ～ 45% 改善すると予測しています。 3 部構成のブログ投稿シリーズの第 1 部では、生成系 AI とは何か、生成系 AI が CX 環境をどのように変えているか、そして生成系 AI がもたらすビジネス成果について見ていきます。第 2 回と第 3 回では、生成系 AI を成功させるための重要な考慮事項と、CX 環境で大規模言語モデル (LLM) を使用する際のベストプラクティスについて詳しく説明します。 生成系 AI によるカスタマーエクスペリエンスの革新 生成系 AI は、大量のデータに対して事前にトレーニングされた非常に大規模な 機械学習 モデルによって実現されています。たとえば、 Amazon Bedrock で公開されている Anthropic の Claude 2 は、1370 億個のパラメータを使用してトレーニングされました。これらの事前トレーニング済みモデルは、一般に基盤モデル (FM) と呼ばれます。大規模言語モデル (LLM) は、人間のようなテキストの理解と生成に重点を置いた FM の一種です。 LLM は、コンタクトセンターが大量のデータを管理および処理する方法を改善し、リアルタイムで CX を強化できるため、CX のユースケースで素晴らしい可能性をもたらします。たとえば、LLM の備える人間並みのテキスト生成機能は、CX にとってすぐに活用できる分野です。テキスト生成により、会話の要約のようなテキストを生成したり、エージェントをリアルタイムで支援することに利用できます。 LLM はコンタクトセンターでの自動化を成功させるための基礎となる、音声やチャットボットの会話の自然言語処理も改善します。 LLM が会話のコンテキスト（通話履歴、以前の会話の記録、以前の取引など）として膨大な量のメタデータを活用できるためです。さらに、 LLM は複雑で非線形の文章構造をより簡単に理解できるため、連絡の意図を正確に判断できます。 発信者が自然言語理解 (NLU) 旅行ボットと対話する例を考えてみましょう。旅行者がこのボットに「ノルウェーの首都」へ旅行する意図を伝えたとします。従来の NLU ボットには、その意図を適切に解決するためのコンテキストがありません。 NLU ボットは、結果を得るためのデータセットがはるかに限られているため、通常、LLM ほどパラメータートレーニングの深さはありません。しかし、 LLM を統合すれば、ボットは顧客がオスロへの旅行を希望していることを「理解」するでしょう。これは、 LLM が膨大なパラメータ知識を使って顧客の意図を解決するという、非常に単純な例です。 LLM が生成する応答よりも予測性の高い結果を得るために、回答を特定の小さなデータセットに限定したいというユースケースがあるかもしれません。これらのユースケースとトレードオフについては、このシリーズの今後のブログ記事で詳しく説明します。 生成系AIでコンタクトセンタービジネスはどう改善できるか 私たちはカスタマーエクスペリエンスの向上は、生成系 AI のトップユースケースの1つだと考えています。それは、生成系 AI によって、エージェントへの支援、マネージャー向けの洞察、顧客向けのセルフサービス体験をさらに改善する機会があるからです。 生成系 AI がコンタクトセンターでどれほど役立つかを検討する際には、達成しようとしているビジネス成果から始めることが重要です。これにより、コンタクトセンターにおける生成系 AI の具体的なユースケースを絞り込むことができます。生成系 AI の次の 3 つのユースケースは、エージェントの効率を高め、データをより正確に処理し、顧客がより複雑なクエリへの回答を得られるようにすることで、すぐにビジネス価値をもたらします。 生成系 AI は、エージェントが顧客の問題に対応する際の効率性と正確性を向上させることで、 処理時間をさらに短縮し、初回解決率を高める ことに役立つ可能性があります。生成系 AI で企業のナレッジコンテンツから要約された回答やアクションをリアルタイムに生成することで、エージェントの能力を助け、エージェントが顧客の問題を迅速かつ正確に解決できるようにします。たとえば、顧客が自動車保険の請求について問い合わせるために電話をかけてきた場合、 LLM は顧客の請求と保険契約に関する情報、保険会社の Web サイトにある修理店の詳細、内部リポジトリの保険契約書を活用して、エージェントに包括的な対応と顧客の問題解決に役立つ次のアクションを提供できます。 また生成系 AI により、少量のサンプルではなくすべてのコンタクトを分析することで、 対応中のリアルタイムおよび対応後の分析と品質保証の取り組みを強化 することもできます。これにより、マネージャーは洞察をより迅速に特定し、エージェントがポリシーを順守していることを確認できます。生成系 AI を使用して会話を簡潔にまとめることができるため、エージェントやマネージャーが会話を引き継ぐ際にメモを取ったり確認したり、経緯を共有したりする時間を短縮できます。たとえば、生成系 AI は、回線契約の問い合わせに関する長い会話を「顧客がエージェントから提示された 10 ドルのリベートを拒否した後、回線契約をキャンセルした」と要約できます。また、 LLM は、エージェントの能力がビジネス成果をどのように左右するか、さらなる洞察をマネージャーに提供します。その後、コーチングポイントやエージェントトレーニングなどの推奨アクションを提供して、パフォーマンスをさらに向上させることができます。 さらに、セルフサービスエクスペリエンスを最適化して、 様々なチャネルを活用し、自動セルフサービスエクスペリエンスの開発コストを削減 したいと考えているかもしれません。生成系 AI はここでも、企業が顧客の意図の複雑なニュアンスを理解しやすくすることで役に立ちます。また、セルフサービス体験の設計、構築、更新を容易にするコンタクトセンターの構成を改善するための、 LLM を活用した推奨事項も提供できます。 Amazon Connect と生成系 AI の組み合わせによる可能性 2017 年に Amazon Connect の提供を開始したとき、統合された AI 機能をゼロから構築しました。これにより National Australia Bank 、 Traeger 、 Accor 、 Just Energy などのお客様が、処理時間の短縮や顧客満足度の向上などの成果を実現しています。私たちは Amazon Connect の既存の組み込み AI 機能を生成系 AI を使って強化することで、さらなるビジネス価値をもたらす機会があると考えています。 以下のデモでは、生成系 AI をコンタクトセンターの 3 つのユースケース (エージェントアシスタンス、マネージャーアシスタンス、カスタマーセルフサービス) にどのように使用できるかを紹介します。 効率的で効果的なサービスを顧客に提供しながら、コンタクトセンターの実際のビジネス成果を促進する生成系 AI のアプリケーションについて、皆様と協力できることを嬉しく思います。 より深く生成系 AI を理解するための関連記事 生成系 AI のビジネス価値を組織で実現 How Technology Leaders Can Prepare for Generative AI (英文) How Your Organization Can Prepare for Generative AI (英文) An introduction to generative AI with Swami Sivasubramanian (英文) 上のデモビデオで紹介されている生成系 AI を活用したカスタマーセルフサービスソリューションを試す方法の詳細については、以下をご覧ください Deploy self-service question answering with the QnABot on AWS solution powered by Amazon Lex with Amazon Kendra and large language models (英文) 著者について  Mike Wallace は AWS でアメリカのカスタマーエクスペリエンス分野のソリューションアーキテクトをリードしています。 Andrea Caldwell は AWS の Amazon Connect のプロダクトマーケティングマネージャーです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。