AWS ニュースブログチームの全員が、ラスベガスで行われる毎年恒例のカスタマーカンファレンス、 AWS re:Invent の開催中に新しいサービスと機能を発表するための記事の執筆に全力で取り組んでいます! そして、私たちが皆さんに読んでいただくためのコンテンツを準備している間も、AWS のサービスチームは革新し続けています。以下は、10月16日週のリリースの概要です。 10月16日週のリリース 私が関心を持ったリリースをいくつかご紹介しましょう。 Amazon CodeCatalyst – CI/CD ワークフローをトリガーするための cron 式を追加できるようになりました。 これは、ワークフローを指定された時間に開始する手段を提供します。CodeCatalyst は、プロジェクトのコラボレーションツール、CI/CD パイプライン、および開発環境とデプロイ環境を統合する統合開発サービスです。 Amazon Route53 – お客様のトラフィックをお客様に最も近い AWS Local Zones にルーティング して、レイテンシーの影響を受けやすいワークロードのアプリケーションパフォーマンスを向上させることが可能になりました。詳細については、Route53 のドキュメントの「 Geoproximity routing 」を参照してください。 Amazon RDS – AWS がお客様のデータベースの TLS 証明書に署名するために使用するルート証明書は、2024 年に有効期限が切れます。データベース用の新しい証明書は、有効期限日の前に生成しておく必要があります。 このブログ記事には、そのステップバイステップ手順が詳しく説明されています 。AWS が生成した新しいルート証明書の有効期間は、 RSA2048 では今後 40 年、 RSA4098 および ECC384 では 100 年になります。AWS のデータベース証明書を更新する義務を負うのは、皆さんのプロとしてのキャリアの中でこれが最後になるでしょう。 Amazon MSK – Kafka クラスターを大規模に複製することは困難で、大抵の場合は、インフラストラクチャとレプリケーションソリューションを独自に管理しなければなりません。AWS は、同じ AWS リージョン内、または複数の AWS リージョンにまたがる Kafka クラスターのためのフルマネージドレプリケーションソリューション、 Amazon MSK Replicator の提供を開始しました。 Amazon CodeWhisperer – Amazon CodeWhisperer Professional の次なる機能のプレビューが開始されました。 これからは、プライベートコードベースで CodeWhisperer をトレーニングできるようになります 。この機能は、より適切な提案を組織の開発者に提供することによって、組織のプライベートライブラリやフレームワークに対する毎日のコーディングで開発者をよりよくサポートできるようにします。 Amazon EC2 – 第 7 世代のメモリ最適化 EC2 インスタンス (R7i) が利用可能になりました 。これらのインスタンスは、第 4 世代インテル Xeon スケーラブルプロセッサー ( Sapphire Rapids ) を使用しています。このインスタンスファミリーは、最大 192 個の vCPU と 1,536 GB のメモリを提供します。これらは、インメモリデータベースやキャッシュなどのメモリ集約型アプリケーションに最適です。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供が開始されました。 Amazon Bedrock が欧州 (フランクフルト) で利用可能になりました 。ヨーロッパのお客様は、そのデータが欧州連合内に維持されることを確実にしなければならない場合が多いため、この機能はこれらのお客様にとって重要です。これからは、プロンプトやカスタム設定がヨーロッパ内に維持されるという確信を持ったうえで、アプリケーションに生成系 AI 機能を組み込み、大規模言語モデルにアクセスすることができるようになります。 Amazon EC2 が、複数のインスタンスファミリーのフットプリントを拡大し、カナダ (中部) と南米 (サンパウロ) で m6gd インスタンス 、 カナダ (中部) で c6a インスタンス、カナダ (中部) と欧州 (ミラノ) で m6a インスタンス、そして米国西部 (北カリフォルニア) とアジアパシフィック (シンガポール) で r6a インスタンス の提供を開始しました。最後に、欧州 (チューリッヒ) では m6id インスタンスが利用できるようになりました 。 Amazon EMR Managed Scaling がアジアパシフィック (ジャカルタ) で利用可能になりました。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログが、 Java アプリケーションと Go アプリケーション内に Amazon Bedrock を統合する方法を説明する新しい記事を発表しました。また、私の同僚である Brooke も、 re:Invent に初めて参加する人のためのサバイバルガイド を書きました。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。このカンファレンスは、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、および ブラジル (11 月 4 日) で開催されます。 AWS Innovate: Every Application Edition – 無料のオンラインカンファレンスに参加して、 セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 26 日に開催される AWS Innovate Online アジアパシフィック & 日本 にぜひ登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – このカンファレンスに参加 して、AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent ハイライト を確認してください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 10月23日週のニュースは以上です。re: Invent ブログ記事の執筆に戻ろうと思います。 10月30日週の Weekly Roundup もお楽しみに! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) コンソールで [証明書の更新] を目にしても驚かないでください。 Amazon RDS for MySQL、MariaDB、SQL Server、Oracle、PostgreSQL、Amazon Aurora のデータベースインスタンスに接続するために、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を証明書の検証とともに使用しているか、または使用する予定がある場合、ルート証明書の有効期限が切れる前に、DB インスタンスとアプリケーションの両方で新しい認証機関 (CA) 証明書をローテーションする必要があります。 DB インスタンスのほとんどの SSL/TLS 証明書 ( rds-ca-2019 ) は、 2020 年の証明書の更新 後、2024 年に期限切れになります。2022 年 12 月に、40 年間有効な CA 証明書 ( rds-ca-rsa2048-g1 ) と 100 年間有効な CA 証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) を新しくリリースしました。これにより、CA 証明書をローテーションした後、長期にわたって、再度ローテーションする必要はありません。 影響を受けるリージョンと、それらの rds-ca-2019 の有効期限の一覧を次に示します。 有効期限 リージョン 2024 年 5 月 8 日 中東 (バーレーン) 2024 年 8 月 22 日 米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパウロ) 2024 年 9 月 9 日 中国 (北京)、中国 (寧夏) 2024 年 10 月 26 日 アフリカ (ケープタウン) 2024 年 10 月 28 日 欧州 (ミラノ) 2061 年まで影響なし アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、欧州 (スペイン)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (UAE)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) 次のステップでは、アプリケーションからデータベースインスタンスへの接続を維持するために証明書をローテーションする方法を示します。 ステップ 1 – 影響を受ける Amazon RDS リソースを特定する 前述したように、 Amazon RDS コンソール の [証明書の更新] ページで影響を受ける DB インスタンスの総数を確認し、影響を受けるすべての DB インスタンスを表示できます。注: このページには、現在のリージョンの DB インスタンスのみが表示されます。複数のリージョンに DB インスタンスがある場合は、各リージョンの証明書の更新のページを確認して、古い SSL/TLS 証明書を使用しているすべての DB インスタンスを表示します。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して describe-db-instances を呼び出し、期限切れの CA を使用するインスタンスを見つけることもできます。クエリにより、アカウントと us-east-1 リージョン内の RDS インスタンスのリストを表示できます。 $ aws rds describe-db-instances --region us-east-1 | jq -r '.DBInstances[] | select ((.CACertificateIdentifier != "rds-ca-rsa2048-g1") and (.CACertificateIdentifier != "rds-ca-rsa4096-g1") and (.CACertificateIdentifier != "rds-ca-ecc384-g1")) | "DBInstanceIdentifier: (.DBInstanceIdentifier), CACertificateIdentifier: (.CACertificateIdentifier)"' ステップ 2 – データベースクライアントとアプリケーションを更新する DB インスタンスに新しい証明書を適用する前に、接続するために SSL/TLS およびサーバー証明書を使用するクライアントとアプリケーションの信頼ストアを更新する必要があります。 現在、アプリケーションが接続するための前提条件として証明書の検証が必要かどうかを、DB インスタンス自体から簡単に判断する方法はありません。ここでの唯一のオプションは、アプリケーションのソースコードまたは設定ファイルを検査することです。 DB エンジン固有のドキュメント には、極めて一般的なデータベース接続インターフェイスで注意すべき点が概説されていますが、証明書の検証が使用されているかどうか、および特定のクライアントアプリケーションのためにアプリケーションの SSL/TLS 証明書を更新する正しい方法をアプリケーションデベロッパーに確認することを強くお勧めします。 アプリケーションの証明書を更新するために、古い CA と新しい CA の両方の証明書を含む 新しい証明書バンドル を使用できます。これにより、アプリケーションを安全にアップグレードし、移行期間中も接続を維持できます。 各 DB エンジンについての SSL/TLS 接続の確認とアプリケーションの更新については、次のトピックを参照してください。 新しい SSL/TLS 証明書を使用して MariaDB DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Microsoft SQL Server DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して MySQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Oracle DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Aurora MySQL DB クラスターに接続するようにアプリケーションを更新する 。 新しい SSL/TLS 証明書を使用して Aurora PostgreSQL DB クラスターに接続するようにアプリケーションを更新する 。 ステップ 3 – 非本番 RDS インスタンスで CA ローテーションをテストする すべての信頼ストアで新しい証明書を更新した場合は、非本番環境で RDS インスタンスを使用してテストする必要があります。この設定は、本番環境と同じデータベースエンジンとバージョンを備えた開発環境で実行します。また、このテスト環境は、本番と同じコードと設定を使用してデプロイする必要があります。 テストデータベースインスタンスで新しい証明書をローテーションするには、 Amazon RDS コンソール で、変更する DB インスタンスについて [変更] を選択します。 [接続] セクションで、 rds-ca-rsa2048-g1 を選択します。 [続行] を選択して、変更の概要を確認します。変更をすぐに適用する場合は、 [すぐに適用] を選択します。 AWS CLI を使用して DB インスタンスのために CA を rds-ca-2019 から rds-ca-rsa2048-g1 に変更するには、 modify-db-instance コマンドを呼び出し、 --ca-certificate-identifier オプションを使用して DB インスタンス識別子を指定します。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --apply-immediately これは、本番データベースインスタンスで新しい証明書を手動でローテーションする方法と同じです。参照した信頼ストアまたは CA 証明書バンドルを使用したローテーションの後、アプリケーションが SSL/TLS を使用して問題なく再接続することを確認します。 新しい DB インスタンスを作成する場合、デフォルトの CA は 2024 年 1 月 25 日までは rds-ca-2019 のままですが、その後は rds-ca-rsa2048-g1 に変更されます。新しい CA を設定して新しい DB インスタンスを作成する場合、CA オーバーライドを設定して、すべての新しいインスタンスの起動で任意の CA が使用されるようにできます。 $ aws rds modify-certificates \ --certificate-identifier rds-ca-rsa2048-g1 \ --region <region name> これは、RDS DB インスタンスが存在するすべてのリージョンで行う必要があります。 ステップ 4 – 本番 RDS インスタンスを安全に更新する 非本番環境でのテストが完了したら、本番環境で RDS データベース CA 証明書のローテーションを開始できます。ステップ 3 に示すように、DB インスタンスを手動でローテーションできます。今日のエンジンの多くは再起動を必要としませんが、メンテナンス期間に再起動をスケジュールすることが推奨されることにご留意ください。 ステップ 1 の [証明書の更新] ページで、ローテーションする DB インスタンスを選択します。 [スケジュール] を選択すると、次のメンテナンス期間に証明書のローテーションをスケジュールできます。 [今すぐ適用] を選択すると、ローテーションをすぐに適用できます。 [スケジュール] を選択すると、証明書のローテーションを確認するよう求めるプロンプトが表示されます。このプロンプトは、更新のスケジュールウィンドウも示します。 (すぐに、またはメンテナンス期間中に) 証明書が更新された後、データベースとアプリケーションが想定どおりに動作していることを確認する必要があります。 今日の DB エンジンのほとんどでは、証明書を更新するためにデータベースを再起動する必要はありません。CA 更新のためだけにデータベースを再起動したくない場合は、 modify-db-instance コマンドで --no-certificate-rotation-restart フラグを使用できます。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --no-certificate-rotation-restart エンジンの再起動が必要かどうかを確認するには、 describe-db-engine-versions コマンドの出力で SupportsCertificateRotationWithoutRestart フィールドを確認します。このコマンドを使用すると、再起動なしでのローテーションをサポートしているエンジンを確認できます。 $ aws rds describe-db-engine-versions \ --engine <engine> --include-all --region <region> | jq -r '.DBEngineVersions[] | "EngineName: (.Engine), EngineVersion: (.EngineVersion), SupportsCertificateRotationWithoutRestart: (.SupportsCertificateRotationWithoutRestart), SupportedCAs: ([.SupportedCACertificateIdentifiers | join(", ")])"' データベースインスタンスのために SSL/TLS を使用しない場合でも、CA をローテーションすることをお勧めします。将来的に SSL/TLS を使用する必要がある場合があります。その場合、JDBC コネクタや ODBC コネクタなどの一部のデータベースコネクタは、接続する前に有効な証明書をチェックします。その際、CA の期限が切れていると、SSL/TLS を使用できない可能性があります。 DB インスタンスを手動で変更することによる証明書の更新、サーバー証明書の自動ローテーション、信頼ストアに証明書をインポートするためのサンプルスクリプトの検索の詳細については、「 Amazon RDS ユーザーガイド 」または「 Amazon Aurora ユーザーガイド 」を参照してください。 留意点 知っておくべき重要な事項をいくつか次に示します。 Amazon RDS Proxy と Amazon Aurora Serverless は、 AWS Certificate Manager (ACM) からの証明書を使用します。SSL/TLS 証明書をローテーションする際に Amazon RDS Proxy を利用している場合は、Amazon RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。Aurora Serverless を利用している場合、SSL/TLS 証明書をローテーションする必要はありません。 現在から 2024 年 1 月 25 日 まで – 新しい RDS DB インスタンスには、 create-db-instance API の ca-certificate-identifier オプションで別の CA を指定しない限り、デフォルトで rds-ca-2919 証明書が含まれます。または、上記のセクションで言及したように、アカウントのためにデフォルトの CA オーバーライドを指定します。 2024 年 1 月 26 日 以降 – 新しいデータベースインスタンスは、 rds-ca-rsa2048-g1 証明書を使用するようデフォルト設定されます。新しいインスタンスのために別の証明書を使用することを希望する場合は、AWS コンソールまたは AWS CLI を使用して、どの証明書を使用するかを指定できます。詳細については、 create-db-instance API ドキュメント を参照してください。 Amazon RDS for SQL Server を除き、今日の RDS および Aurora エンジンのほとんどは、その最新バージョンにおいて、データベースの再起動なしでの証明書のローテーションをサポートしています。 describe-db-engine-versions を呼び出し、応答フィールド SupportsCertificateRotationWithoutRestart を確認します。このフィールドが true に設定されている場合、インスタンスでは CA 更新のためにデータベースを再起動する必要がありません。 false に設定すると、再起動が必要になります。詳細については、AWS ドキュメントの「 データベースのために CA を設定する 」を参照してください。 ローテーションされた CA は、各 DB インスタンスにインストールされる DB サーバー証明書に署名します。DB サーバー証明書は、信頼されたサーバーとして DB インスタンスを識別します。DB サーバー証明書の有効期間は、DB エンジンとバージョンによって異なり、1 年間または 3 年間です。CA がサーバー証明書の自動ローテーションをサポートしている場合、RDS は DB サーバー証明書のローテーションも自動的に処理します。DB サーバー証明書のローテーションの詳細については、AWS ドキュメントの「 サーバー証明書の自動ローテーション 」を参照してください。 40 年間有効な証明書 ( rds-ca-rsa2048-g1 ) または 100 年間有効な証明書を使用することを選択できます。RDS インスタンスによって使用される期限切れの CA は、RSA2048 鍵アルゴリズムと SHA256 署名アルゴリズムを使用します。 rds-ca-rsa2048-g1 はまったく同じ設定を使用するため、互換性の点で最適です。100 年間有効な証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) は、 rds-ca-rsa2048-g1 よりも安全な暗号化スキームを使用します。これらを使用する場合は、本番前環境で十分にテストし、データベースクライアントとサーバーがリージョンで必要な暗号化スキームをサポートしていることをダブルチェックする必要があります。 すぐに始めましょう! 証明書の有効期限が切れるまであと 1 年間ある場合でも、チームと連携して計画を開始すべきです。SSL/TLS 証明書を更新するには、有効期限が切れる前に DB インスタンスを再起動する必要がある場合があります。有効期限前にアプリケーションを更新するようにスケジュールし、本番環境でこれらのステップを完了する前に、ステージングまたは本番前のデータベース環境でテストを実行することを強くお勧めします。SSL/TLS 証明書の更新の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 SSL/TLS 接続を使用しない場合、データベースセキュリティのベストプラクティスは、SSL/TLS 接続を使用し、接続認証プロセスの一部として証明書の検証をリクエストすることです。SSL/TLS を使用して DB インスタンスへの接続を暗号化する方法の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 ご質問や問題がある場合は、ご利用のサポートプランに応じて、通常の AWS サポート までお問い合わせください。 – Channy 原文は こちら です。

モダンアプリケーションは、モジュール式かつ分散型のコンポーネントで構築されています。お客様は、特にハイブリッドクラウド環境において、サービスコンポーネント間のアプリケーションネットワーキングをシンプル化する柔軟な方法を求めています。 VMware Cloud on AWS を利用することで、お客様はオンプレミスの vSphere 環境からのワークロードとアプリケーションをシームレスなハイブリッドクラウド体験で Software Defined Data Center (SDDC) に簡単に移行できます。 ワークロードを VMware Cloud on AWS に移行するにつれ、SDDC 上で実行されている既存のアプリケーションと、ネイティブ AWS サービスを使用してデプロイされた新しいサービスとの接続要件に対処することが不可欠となってきます。 異なる AWS アカウントや Amazon Virtual Private Cloud (VPC) 間のサービス接続をサポートするには通常、 VPC ピアリング 、 AWS Transit Gateway 、 AWS PrivateLink 、 サービスメッシュ プロキシなど、追加のネットワーキングサービスとコンポーネントをプロビジョニングする必要があります。 さらに、複数の AWS アカウントと VPC を持つお客様は、重複する CIDR ブロックや環境分離の要件などの課題に直面することが多く、サービス間のアンダーレイとなる IP 接続性の構築をさらに複雑にします。 この記事では、 Amazon VPC Lattice が SDDC やクラウドネイティブ環境全体のサービス間通信を、アンダーレイネットワークの複雑さを抽象化しながらシンプル化する方法を見ていきます。また、VPC Lattice を活用して、VMware Cloud on AWS からクラウドネイティブサービスへアプリケーションをシームレスに変換、移行できることも説明します。 Amazon VPC Lattice 概要 2023 年 3 月、AWS はアプリケーションネットワーキングサービス「Amazon VPC Lattice」の 一般提供を発表 しました。VPC Lattice は、サービス間通信のディスカバリと接続を容易にするものです。 VPC Lattice は、論理的なアプリケーションレイヤーネットワークである サービスネットワーク を作成します。これにより、異なる AWS アカウントや Amazon VPC 間でのサービスネットワーク全体のクライアント (コンシューマー) とサービス (プロバイダー) 間のアプリケーション通信を、アンダーレイネットワークの複雑さを抽象化してシンプル化します。 以下の図を元に Amazon VPC Lattice の主なコンポーネントを確認しましょう。 図1 – Amazon VPC Lattice の主なコンポーネント サービス : VPC Lattice サービスは、特定のタスクや機能を提供するカスタマーアプリケーションを表します。サービスは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、サーバーレス関数など、さまざまなコンピュートオプションで実行できます。VPC Lattice サービスは、 AWS Resource Access Manager (RAM) を使用して他の AWS アカウントと共有できます。VPC Lattice サービスには、次の要素が含まれます。 ターゲットグループ – アプリケーションやサービスを提供するリソースの集まりです。ターゲットには、EC2 インスタンス、IP アドレス、 AWS Lambda 関数、 Application Load Balancer 、 Kubernetes Pod を指定できます。 リスナー – 定義されたプロトコル (HTTP/HTTPS) とポート番号に基づいて、ターゲットグループ内のターゲットに接続リクエストをルーティングするプロセスです。 ルール – 優先順位、条件、アクションが定義されたアプリケーションフローを制御するルーティングルールです。 サービスネットワーク : サービスの集合を論理的に区切る境界。VPC Lattice サービスと VPC をサービスネットワークに関連付けて、サービス接続を容易にすることができます。RAM を使用して、サービスネットワークを他のアカウントと共有することもできます。 サービスディレクトリ : 所有または RAM 経由で共有されているすべての VPC Lattice サービスの中央レジストリ。 認証ポリシー : サービスへのアクセスを制御するために、サービスネットワークまたはサービスに関連付けることができる AWS Identity and Access Management (IAM) ポリシー。 VPC がサービスネットワークと関連付けられると、VPC 内のクライアントは Domain Name System (DNS) を使用して、サービスネットワークに登録されたサービスを自動的に検出できるようになります。さらに、登録済みサービスのすべてのアプリケーション間トラフィックは VPC Lattice を通過するようになります。 VPC Lattice は、IAM ベースの認証ポリシーを使用したコンテキスト固有の認証によって、アプリケーション接続のセキュリティも強化します。これにより、顧客は細かいトラフィック制御とエンドツーエンドの可観測性が得られます。 VPC Lattice の詳細については、この ブログ記事 と Amazon VPC Lattice リファレンスアーキテクチャ を参照してください。 VMware Cloud on AWS と VPC Lattice の統合 SDDC ENI を介した Application Load Balancer の活用 VMware Cloud on AWS 上で実行されているアプリケーションを Amazon VPC Lattice と統合するには、Application Load Balancer が必要です。これは、VPC Lattice が一意のリンクローカルアドレスレンジの 169.254.171.0/24 を使用しているためです。このアドレスレンジは VPC 内でのみローカルにアクセス可能で、SDDC 外部にルーティングできません。 そこで、 Connected VPC 内に Application Load Balancer をデプロイすることで、 VPC Lattice からの着信リクエストを終端できます。これにより、広帯域かつ低レイテンシの SDDC Elastic Network Interface (ENI) を使用して、SDDC 上にホストされているワークロードにアプリケーションフローを IP ターゲット としてルーティングできます。サンプルアーキテクチャは以下の通りです。 図2 – Application Load Balancer を介した SDDC ENI 統合   SDDC と Connected VPC 間のデータ転送は、SDDC とネイティブサービスが同じ AWS アベイラビリティーゾーン (AZ) 内にデプロイされている限り、いかなる egress 通信コストも発生しません。 以下のスクリーンショットに示すように、Connected VPC 内に 内部 Application Load Balancer をプロビジョニングすると、 ユーザーガイド に従って、SDDC 上で実行されているアプリケーション向けの Lattice ターゲットグループ (およびサービス) を作成できます。 図3 – VPC Lattice ターゲットグループとして Application Load Balancer を登録  VMware Transit Connect を介した Application Load Balancer の活用 Application Load Balancer を Lattice サービスとは分けた VPC に展開し、 VMware Transit Connect を介してアプリケーショントラフィックを SDDC に渡すという選択肢もあります。以下の図のような構成です。 図4 – VMware Transit Connectを介した Application Load Balancer の統合 これは、Application Load Balancer がセキュリティ検査の要件のために Central Ingress VPC に展開されている場合に有効です。サービスネットワークは、別の AWS アカウントに存在し、AWS RAM を使用して ingress VPC と共有されることもあります。 VMware Transit Connect は、VMware が管理する AWS Transit Gateway ソリューションで、お客様のSDDC、クラウドネイティブサービス、オンプレミスリソース間の高速かつ回復性のある接続を提供します。SDDC と Amazon VPC を接続するために VMware Transit Connect をプロビジョニングする方法については、 VMware のブログ記事 を ( 日本語ブログはこちら ) 参照してください。 お客様の環境で AWS Transit Gateway をすでに利用している場合は、ingress Application Load Balancer で着信サービスリクエストを終端し、アプリケーションフローを リージョン内ピアリング を使用した AWS Transit Gateway とVMware Transit Connect 経由で SDDC に配信することが可能です。以下の図は、このサンプルアーキテクチャを示しています。 図 5 – リージョン内ピアリングによる Application Load Balancer 統合 SDDCとネイティブサービス間のアプリケーション接続のシンプル化 VMware Cloud on AWS のお客様が、アプリケーションネットワーキングをシンプル化し、変革を加速する VPC Latticeの活用例を見ていきましょう。 最初の例では、お客様はオンプレミスのアプリケーション群を VMware Cloud on AWS に移行しました。新しくSoftware-as-a-Service (SaaS) 製品のローンチを計画しており、これには SDDC-01 上のバックエンド APIサービス (Service 1) を、ネイティブ AWS 環境で最近構築された 2 つのマイクロサービス (Service2, Service3) と統合する必要があります。これらのマイクロサービスは、下の図に示すように、異なる AWS アカウントと VPC にまたがる AWS Lambda と Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされています。 図 6 – SDDC アプリケーションと複雑性のある AWS 環境の統合 お客様は以下のサービス統合の要件と課題があります: VPC-02 の CIDR と SDDC-01 の CIDR は一部重複しています。 VPC-03 は、外部のサービスプロバイダーが所有する別の AWS Organization の下にデプロイされているため、直接 IP 接続を確立することは許可されていません。 Service 2 と Service 3 は、Service 1 にアクセスする必要があります。 Service 2 と Service 3 は、双方向で通信する必要があります。 この場合、マルチアカウント環境における SDDC、コンテナ、サーバーレス関数全体で、セキュアかつプライベートなアプリケーション間接続を構築するために、VPC Lattice を活用できます。 VPC Lattice のユニークなリンクローカルアドレスレンジは、VPC や SDDC 間の潜在的なIPアドレスの競合問題も解消します。 まず、SDDC-01 にアタッチされた Connected VPC 内に、Service 1 の Application Load Balancer を作成する必要があります。これは、Lattice サービスはネイティブ VPC 内でのみアクセスできるため、Service 1 のすべての着信サービスリクエストを Connected VPC で終端するためです。 次に、VPC Lattice サービスネットワークを作成し、AWS RAM を介して 3 つのサービスアカウント (Account 1 ~3) と共有します。これにより、各アカウントで個別の VPC Lattice サービス (Service 1~3 向け) を作成し、サービスネットワークに関連付けることができます。 最後に、Service 2 と Service 3 が双方向通信を必要とするため、VPC-02 と VPC-03 をサービスネットワークに関連付ける必要があります。 ただし、Service 3 はバックエンドサービスであるため、Connected VPC をサービスネットワークに関連付ける必要はありません。 以下にアーキテクチャ、ソリューションの概要を示しています。 図 7 – VPC Lattice によるアプリケーション間ネットワーキングのシンプル化 VPC Lattice を使用すると、マルチアカウントおよびマルチ VPC 環境における VMware Cloud on AWS アプリケーションとクラウドネイティブサービス間の相互接続を素早く構築できます。また、AWS Transit Gateway、AWS PrivateLink、 Private NAT Gateway など、追加のネットワークインフラストラクチャサービスの構築による複雑さと管理オーバーヘッドを排除できます。 さらに、VPC Lattice には Lattice サービスごとに一意の DNS 名を自動的に割り当てる、組み込みの DNS ベースのサービスディスカバリーがあります。 Amazon Route 53 プライベートホストゾーンを利用することで、サービスの CNAME、またはエイリアスレコードをカスタマイズすることもできます。 VPC Lattice によるアプリケーション変革の加速 次の例では、VPC Lattice が VMware Cloud on AWS のお客様がアプリケーションをシームレスにクラウドネイティブサービスに変換・移行するのにどのように役立つかを探っていきます。 お客様は SDDC 上で実行されているレガシーアプリケーションのリファクタリングを進めており、それを AWS Lambda のサーバーレス関数に再構築しました。SDDC 内のレガシーアプリケーションから Lambda 関数へのサービストラフィックの切り替え前に、アップストリームの他のサービスへの潜在的な影響を調査するための一連のカナリアテストを実施したいと考えています。 Amazon VPC Lattice は、このシナリオのような ブルー/グリーン や カナリアスタイル のロールアウトなど、一般的なデプロイメントパターンをサポートしています。VPC-02 の Lambda 関数を使用する 1 つのターゲットグループと、Connected VPC 内の Application Load Balancer を公開して SDDC-01 上のレガシーアプリケーションに向けたもう 1 つのターゲットグループで VPC Lattice サービスを設定できます。 その後、以下の図に示すように、リクエスト条件 (パス、メソッド、ヘッダー) に基づいて、 2 つのターゲットグループ間でトラフィックを分散する重み付けルーティングを利用できます。 図 8 – VPC Lattice による SDDC と AWS Lambda を横断したカナリアロールアウト VPC Lattice は、サービス間の詳細なアクセスログを提供します。サポートされているログ配信ターゲットには、 Amazon Simple Storage Service (Amazon S3) バケット、 Amazon Kinesis Data Firehose 、 Amazon CloudWatch のロググループが含まれます。これにより、お客様は必要なログの詳細を迅速に取得し、特定のサービスまたはサービスネットワーク全体で発生し得る問題を特定および分析できます。 VPC Lattice は、アプリケーションの変革とモダナイゼーションを促進し、新しいアイデアを簡単に試すことができ、必要に応じて迅速にロールバックできるようにします。 これにより、サービス移行時のリスクを軽減し、最終的にエンドユーザーの体験を向上させます。 追加の考慮事項 サービスネットワーク全体でのネットワークレベルの保護を実施するため、VPC Lattice の AWS マネージドプレフィックスリスト をセキュリティグループで活用することをおすすめします。 さらに、個々のサービスまたはサービスネットワーク全体のいずれかに、強力な認証とコンテキスト固有の認可を適用するために、サービスレベルの認証ポリシーを使用できます。詳細は、こちらの AWS ブログ記事 を参照してください。 デフォルトでは、VPC Lattice のサービスはリンクローカルアドレスレンジがルーティング不可能なため、VPC 内からのみアクセスできます。 Lattice サービスへの外部接続性を提供するには、 Elastic Load Balancing とプロキシのフリートを使用した ingress VPC が必要です。サンプルアーキテクチャと実装ガイドは、この AWS ブログ記事 を参照してください。 AWS 責任共有モデル に従って、AWS インフラストラクチャ上にホストされるコンテンツの管理はお客様の責任となります。この ユーザーガイド に従って Amazon VPC Lattice を設定し、セキュリティとコンプライアンス目標を満たしてください。また、VMware Cloud on AWS の ネットワークとセキュリティの包括的なガイド も参照してください。 VMware Cloud on AWS 環境の強化に役立つ リソース があります。 価格については、Amazon VPC Lattice の 料金ページ をご確認ください。 AWS Transit Gateway や VMware Transit Connect の 料金 もご参照ください。 まとめ この投稿では、Amazon VPC Lattice が VMware Cloud on AWS のお客様にどのようにアプリケーションネットワーキングをシンプル化し、変革を加速できるかについて説明しました。一般的な統合アーキテクチャと使用例の概要についてもご紹介しました。 より詳細については、以下のリンクをご参考ください。 VMware Cloud on AWS ハイブリッドネットワークデザインパターン VPC Lattice のご紹介 – サービス間通信のためにネットワーキングを簡素化する Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 本稿は、ソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら です。

このブログは 2023 年 10 月 2 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 (原文はイベント開催前に掲載された為、イベント期間中のみの活動については省略しています) Unreal Engine (UE) の開発会社である Epic Games が主催する毎年恒例の開発者カンファレンスである Unreal Fest は、 10 月 3 日から 5 日までニューオリンズで開催され、 3 日間の講演セッション、ハンズオンワークショップ、業界に特化したトラックを開催します。このカンファレンスにはゲーム開発者、デザイナー、アーティスト、様々な業界の専門家が一堂に会し、最新テクノロジーについてより深い洞察を得たり、専門家から学んだり、 UE のクリエイターやゲーム開発者と交流したりします。このブログ記事では Unreal Fest 2023 での AWS for Games のプレゼンスについて取り上げます。 UE のゲーム開発者が AWS を使用してリアルタイム 3D 体験をどのようにスケーリングしているかについては、 AWS と Unreal Engine をご覧ください。 現地での活動 AWS は今年 Unreal Fest のプラチナスポンサーになったことを誇りに思います。これには、パートナーセッション、ブースプレゼント、 AWS 業界の専門家によるライブ製品デモが含まれます。 AWS で Unreal Engine のゲームを構築しているお客様 高度な 3D ゲーム開発テクノロジーと専用のグローバルインフラストラクチャ機能を組み合わせることで、ゲームスタジオがどのようにゲームを構築、運営、成長させているかをご紹介します。 Epic Games は 2018 年にアマゾンウェブサービス （AWS） を全面的に採用し、ビジネスに不可欠なストレージ、分析、スケーリング機能を提供しました。これは毎日約 1,500 万人のアクティブユーザーがいるオンラインゲーム「フォートナイト」のリリースで爆発的に増加しました。フォートナイトは、世界中のゲームサーバー、バックエンドサービス、ウェブサイトを含め、ほぼすべて AWS 上で運営されています。詳細は こちら をご覧ください。 Odyssey Interactive は 2020 年に設立されたウォータールーを拠点とするゲームスタジオで、最初のゲームであるオメガストライカーズの発売と拡大のための費用対効果の高いソリューションを求めていました。オメガストライカーズは UE をベースに構築された 3 対 3 のエキサイティングなフットボールバトルゲームです。実績のある AWS と UE によるソリューションにより、 Odyssey Interactive はバックエンドのインフラストラクチャではなく優れたゲームの制作に集中できるようになりました。こちらの お客様のビデオ をご覧ください。 QXR Studios の共同創設者である Graeme Devine 氏は次のように語っています。「これまでは 100人 以上のチームがこのレベルで成果を出すのに 5 年の期間と 2500 万ドルがかかっていました。業界としては AWS や UE のようなツールにより、テクノロジーの基盤となるサービスに加えて、世界中のアーティストやモデラーにアクセスできるようになりました。これにより小規模なゲーム会社でも AAA のゲームコンテンツを制作できるようになり、ワクワクしています」。こちらの お客様のブログ をご覧ください。 Red Barrels はモントリオールに拠点を置く独立系ゲームスタジオで、スタジオの設立当初から UE をベースに開発を続けています。同社は最初のマルチプレイヤータイトルである「 Outlast Trials 」のゲームサーバーを管理するソリューションを必要としていました。 Red Barrels は UE と AWS の両方を選択しました。これはこれらのテクノロジーがゲーム開発プロセスにパワーと柔軟性をもたらすためです。こちらの お客様のビデオ をご覧ください。 Behaviour Interactive はカナダ最大のゲームスタジオの 1 つで、受賞歴のある非対称型マルチプレイヤーホラーゲーム「 Dead by Daylight 」は 2016 年の発売以来 5,000 万人を超えるプレイヤー数を獲得しています。 UE と AWS により、スタジオは忠実度の高いゲーム体験を制作し、何 100 万人ものプレイヤーに自信を持ってスケールできるようになりました。こちらの お客様のビデオ をご覧ください。 AWS での Unreal Engine 利用例 AWS for Games には、UE ゲーム開発者がコストを削減し、反復作業を迅速に行い、より良いプレイヤー体験を世界規模で提供できるよう支援する、用途別のポートフォリオが用意されています。 仮想ワークステーション – AWS 上の Epic Unreal Engine 5 ワークステーションは、 3D データをホストしてレンダリングするための高価なハードウェアや物理ワークステーションを必要とせずに、忠実度が高く没入感のある 3D 体験を世界中にシームレスに提供します。この Amazon Machine Image (AMI) には UE 5.2 とその動作に必要なものが予め用意されているため、ダウンロードやインストールなしでクラウドで直接制作作業を行う事ができます。詳細は こちら をご覧ください。 ビルドパイプライン – AWS 上の Incredibuild は、 UE の開発者と DevOps の管理者に、ゲームを継続的にビルド、改善、予定通りリリースするためのスケーラブルなプラットフォームを提供する強力なソリューションです。詳細は こちら をご覧ください。 バージョン管理 – AWS 上の Perforce Helix Core は、グローバルな規模と優れたパフォーマンスを実現するエンタープライズ向けのバージョン管理システムです。これは信頼できる単一のソースを UE のデジタルアセットに提供することで、グローバルなチームや大規模なバイナリアセットを管理できるようにします。詳細は こちら をご覧ください。 ゲーム QA とテスト – Amazon GameLift Anywhere は、環境内のハードウェアを統合する事で、ローカルワークステーションでリアルタイムにゲームプレイのモニタリングとデバッグが行える様高速化します。詳細は こちら をご覧ください。 ゲームサーバーホスティング – AWS Graviton3 プロセッサを搭載した Amazon GameLift の専用ゲームサーバー管理サービスは、計算集約型の UE ゲームに最適なコストパフォーマンスを実現します。 Unreal Engine 用 Amazon GameLift Plugin は、 Windows および Mac OS 用の UE 5、 UE 5.1、 UE 5.2、 UE 5.3 をサポートしており、最新の Amazon GameLift SDK 5 以上の API が含まれているため、お客様はUnreal Engine Editor でゲームをビルド、テスト、デプロイできます。詳細は こちら をご覧ください。 ゲーム分析 – AWS のゲーム分析パイプラインは、ゲーム開発者がスケーラブルなサーバーレスデータパイプラインを立ち上げ、 UE で作られたゲームクライアントのアクティブユーザーとビルドから生成されたプレイヤーデータを取り込み、保存、分析するのに役立ちます。詳細は こちら をご覧ください。 カスタムゲームバックエンドホスティング – AWS でのカスタムゲームバックエンドホスティングのガイダンスでは、 UE 5 のサンプルコードとともに、カスタマイズされた軽量でスケーラブルなクロスプラットフォーム向けのID認証機能をデプロイする方法を示しています。詳細は こちら をご覧ください。 ゲーム開発者が AWS 上で UE のゲームを構築、実行、成長させるのに役立つ、 7 つの専用機能 終わりに Unreal Fest はさまざまな業界のデベロッパーやクリエイターが一堂に会し、新しいプロジェクトについて学び、最新テクノロジーのハンズオントレーニングを受け、他のクリエイターと出会い、ネットワークを築くための今年のプレミアイベントです。 UE のゲームの開発者が、 AWS でゲームのワークロードと体験をどのように変革しているかについての詳細は AWS と Unreal Engine のホームページをご覧ください。 翻訳はソリューションアーキテクトの長田が担当しました。

2023 年 9 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Batch 入門編 HPC や機械学習などのバッチ処理を AWS 上で実現できる AWS Batch ついて入門編の内容をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 HPC や機械学習などのバッチ処理をクラウド上で実行することについ て興味のある方。 Amazon VPC / Amazon EC2 / Amazon S3 などの概要知識がある方。 本 BlackBelt で学習できること AWS Batch の概要と、キーコンポーネント、ワークロードごとのデザインパターンについて学習することができます。 スピーカー 小林広志 ソリューションアーキテクト Amazon EMR 基礎編 Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR について、サービスの基礎的な内容を解説します。 資料（ PDF ） 対象者 ビッグデータを扱うシステムのインフラエンジニア、データエンジニア、および、機械学習エンジニア 本 BlackBelt で学習できること Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR を利用するために必要となるサービスの基礎的な内容を理解することができます。 スピーカー 川村誠 ソリューションアーキテクト AWS Secrets Manager AWS Secrets Manager はシークレットのライフサイクルを一元的に管理し、保存・取得・更新・アクセス制限・監査・モニタリングを行うことができます。 本セミナーでは、AWS Secrets Manager の機能について詳細に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境におけるデータベース認証情報や API キーなどのシークレット管理に関心をお持ちの方 これから AWS Secrets Manager をご利用予定の方や、理解を深めたい方 本 BlackBelt で学習できること 本セミナーをご覧になることで、AWS Secrets Manager の機能と、どのようにセキュリティ要件を満たすように構築されているかを理解していただき、安心して AWS 上のシークレットを管理していただくことができるようになります。 スピーカー 押川令 ソリューションアーキテクト Amazon Kinesis Video Streams 基礎編 Amazon Kinesis Video Streams は、メディアデータのストリーミングや分析、保存、再生のためのサービスです。 本セミナーでは、Amazon Kinesis Video Streams 基礎編として、サービスの特徴や基本的な機能、開発のための SDK などを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 見守りカメラや監視カメラなど、コネクテッドカメラからのメディアデータのクラウド活用を検討されている方 コネクテッドカメラからの動画のストリーミングや保存、分析、再生のアプリケーションを検討されている方 Amazon Kinesis Video Streams の初めてのご利用を検討されている方 本 BlackBelt で学習できること Amazon Kinesis Video Streams の特徴や機能 アプリケーションやデバイスを開発するために利用できる SDK やライブラリ、デモアプリケーション デバイスの認証方法 Amazon Kinesis Video Streams の利用を素早く開始するための、パートナーデバイスと入門用コンテンツ 2022 〜 2023 年に公開された Amazon Kinesis Video Streams の新機能 素早く利用を開始するためのパートナーデバイスと入門用コンテンツ スピーカー 宇佐美雅紀 ソリューションアーキテクト Amazon Kinesis Video Streams 応用編 Amazon Kinesis Video Streams を活用する上で知っておくべき Tips について紹介します。パフォーマンスやコストの最適化、よくある問題とトラブルシューティング方法など、サービスをよりよく利用するためのアドバンストな内容を扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Kinesis Video Streams を利用中もしくは利用を検討しており、サービスへの理解を深めたい方 サービスの基本的な知識をお持ちでない方は、同月に公開される Amazon Kinesis Video Streams 基礎編を先にご視聴ください 本 BlackBelt で学習できること 遅延の削減方法 注意すべきサービスの仕様や上限 コストの考え方 WebRTC のトラブルシューティング GStreamer のよくある問題 スピーカー 三平悠磨 IoT スペシャリストソリューションアーキテクト Amazon EventBridge Scheduler サーバーレスのスケジューラーである Amazon EventBridge Scheduler の基本的な機能や使い方について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 クラウドに適したジョブスケジューラーをお探しの方 ノーコードで定期的なタスクの実行を管理したい方 本 BlackBelt で学習できること EventBridge Scheduler を使って定期的に AWS サービスの API を実行する方法 スピーカー 櫻谷 広人 パートナーソリューションアーキテクト FreeRTOS Kernel 編 FreeRTOS はリアルタイム OS の一つで、マイクロコントローラ上で動作する組込み機器向け OS です。 多機能な IoT デバイスを開発する上で、FreeRTOS は欠かせません。 この動画では、FreeRTOS のコアである Kernel が提供する機能について詳しく説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから IoT デバイスを開発されようとするエンジニアの方 これから FreeRTOS の利用を検討しているエンジニアの方 FreeRTOS 上でソフトウェアを開発するエンジニアの方 本 BlackBelt で学習できること AWS が提供する FreeRTOS のサポート内容 FreeRTOS のコアである Kernel が提供する機能の詳細 FreeRTOS のはじめかた スピーカー 山岡卓紀夫 ソリューションアーキテクト AWS Clean Rooms お客様とそのパートナーが、Raw データを共有したり互いにコピーしたりすることなく、集合データセットをより簡単かつ安全に分析、およびコラボレーションする為の独自のクリーンルームを作成できるサービス AWS Clean Rooms について機能の詳細や利用パターンをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データクリーンルームの技術要素をキャッチアップしたい方 機密性の高いデータのグループ間、企業間共有に課題を抱えている方 AWS を利用したデータコラボレーションを運用設計を検討されている方 AWS を利用したデータ活用に興味がある方 本 BlackBelt で学習できること AWS Clean Rooms のサービス概要や機能詳細 安全にデータをコラボレーションする為の利用方法 具体的な利用パターンや他 AWS サービスとの連携方法 スピーカー 鈴木康士郎 ソリューションアーキテクト AWS Systems Manager Maintenance Windows AWS Systems Manager は統合的な AWS 環境の運用をするためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Maintenance Windows についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方、AWS Systems Manager に興味のある方を対象者として想定しています。 本 BlackBelt で学習できること AWS Systems Manager Maintenance Windows のユースケースと機能概要、AWS Systems Manager State Manager との使い分けについて学習いただけます。 スピーカー 小野卓人 シニアソリューションアーキテクト AWS Systems Manager Distributor 編 AWS Systems Manager (SSM) は統合的な AWS 環境を運用するためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Distributor についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方 本 BlackBelt で学習できること AWS Systems Manager Distributor の機能とユースケースをご理解いただくことができます。 スピーカー 村田京介 ソリューションアーキテクト Amazon Monitron Part 1（基本編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 本 BlackBelt で学習できること Amazon Monitron セミナーはシリーズ開催予定です。このセミナーでは Amazon Monitron シリーズ Part 1 として、産業設備のメンテナンスにおける課題と Amazon Monitron によるソリューション、そして Amazon Monitron のしくみを解説します。 スピーカー 吉川晃平 シニア ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 入門編 クラウドサポートエンジニア 高橋尚久 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 クラウドサポートエンジニア 古野俊広 2023-10 Amazon EC2 Auto Scaling スケーリングポリシー編 シニアソリューションアーキテクト EC2 フレキシブルコンピュートスペシャリスト 滝口開資 2023-10 アクセラレータ搭載インスタンスの選択肢 シニアソリューションアーキテクト 赤澤智信 2023-10 AWS ML アクセラレータ入門 Annapurna Labs 常世大史 2023-10 AWS Application Discovery Service の概要（AWS 移行準備シリーズ） マイグレーションパートナーソリューションアーキテクト 鈴木槙将 2023-10 Amazon CodeCatalyst Overview 編 ソリューションアーキテクト 三尾泰士 2023-10 AWS Budgets シニアテクニカルアカウントマネージャー 岡本迅人 2023-10 AWS Cost and Usage Reports シニアテクニカルアカウントマネージャー 石王　愛 2023-10 AWS CloudFormation ユースケースとよくある質問編 ソリューションアーキテクト 木村友則 2023-10 AWS CloudFormation DeepDive 編 クラウドサポートエンジニア 山本一生 2023-10 AWS CloudFormation CloudFormation レジストリ編 クラウドサポートエンジニア 山本一生 2023-10 Amazon Monitron #2 設定編 ソリューションアーキテクト 伊藤ジャッジ向子 2023-11 Amazon Linux 最新情報 ソリューションアーキテクト 寺部祐菜 2023-11 Karpenter Basic ソリューションアーキテクト 多田慎也 2023-11 AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 クラウドサポートエンジニア 中村佑希 2023-11 AWS CloudFormation#2 基礎編 クラウドサポートエンジニア 上原優樹 2023-11 AWS CloudFormation 開発・テスト・デプロイ編 ソリューションアーキテクト 山川達也 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service (Amazon EKS) 編 クラウドサポートエンジニア 坂元龍太 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud – Windows 編 クラウドサポートエンジニア 和田智優 2023-11 Amazon CloudWatch Evidently テクニカルアカウントマネージャー 日平大樹 2023-11 AWS SAW – Nitro システムへの移行を支援する SAW ランブックのご紹介（EC2 Linux 編） クラウドサポートエンジニア 渡邉亮藏 2023-11 AWS SAW – セルフサービスなトラブルシューティング Amazon S3 + AWS Lambda 編 クラウドサポートエンジニア 石川直哉 2023-11 Amazon Pinpoint 再入門 マルチチャネル・コミュニケーションサービス ソリューションアーキテクト 清水幸典 2023-11 Amazon Connect カスタム CCP による従業員体験の向上 ソリューションアーキテクト 清水幸典

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS の生成系 AI サービス・ Amazon Bedrock  が GA (General Availability) になりました。 本ブログでは、Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用する方法について解説します。 今回は製造業で設計開発業務に取り組まれている R&D (Research and Development：研究開発) エンジニアの方を想定ユーザーとして設定させていただきました。本サービスを活用して、どのように設計開発業務改善を実現できるかについてのイメージを持っていただけるような構成になっています。 なお、本ブログの内容は2023年10月12日時点の内容に基づいて実行しています。執筆段階では東京リージョンにおいては Claude v1.3 モデルしか利用できません。 現時点で最も新しいバージョンは v2 になりますので、ここでは v2 モデルが利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、ブログ作成段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 設計開発プロセスの大きなマイルストーンの一つに、 DR （デザインレビュー：設計審査）があります。 DR では設計仕様書や設計計算書など、たくさんの設計ドキュメントを用意する必要があります。本ブログではその中から、 FMEA （ Failure Mode and Effects Analysis ：故障モード影響解析）に着目し、 Amazon Bedrock を活用して FMEA のドキュメントを効率的に作成するイメージをお見せしたいと思います。 FMEA の狙いは、製品や製造プロセスに潜在する故障モードを事前に洗い出し、影響を分析評価したうえで対策を講じることです。なるべく広く故障モードを想定できたほうが設計品質が高くなりますが、それには熟練の知識や経験が必要になります。また、洗い出す項目が多いほど、ドキュメント作成に時間を要します。このような FMEA のドラフトを、 Amazon Bedrock を活用して作成することで、 基盤モデル の特性を活かした広い観点での項目抽出を素早く行うことができるようになります。 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に Playgrounds という項目が表示されます。今回は Chat 機能にアクセスして、生成系 AI と対話形式でやり取りを行います。 Amazon Bedrock では、主要な AI スタートアップ企業や Amazon から提供される幅広い基盤モデルの中からユースケースに適したものを選択して使用することができます。詳細については Amazon Bedrock の製品ページをご参照ください。初期状態ではモデルアクセスへの権限が与えられていない状態のため、以下画像のように Base Models の中から選べるものが存在しません。そこで、まずモデルアクセスへの権限付与設定を行います。 画面左の Base Models をクリックし、 Claude v2 にカーソルを当てると、画面の黄色部分のような枠が表示されますので、 Model access ボタンをクリックします。 すると、以下画面に遷移しますので、 Claude にチェックマークをつけます。現状 Available が灰色になっていますが、このチェックを入れた状態で画面最下部でオレンジ色の Save changes ボタンをクリックすると、利用可能な状態に変わります。 以下画面のように、 Claude が Access granted の状態になれば利用可能です。 画面左の Chat ボタンを押すと、以下画面のように、 Base Models として Anthropic が選択可能な状態になっています。その右では Claude v2 を選択します。 この状態で、Add InstructionsのHuman : と記載されている箇所からチャット文章を書き込むことが可能になっていますが、書き込む文章が長い場合などに備えて、 Update inference configurations をクリックして、 Maximum Length （出力トークン数の最大値）を上げましょう。（トークン数はおおまかに文字数に相当するものと捉えてください） Maximum Length をデフォルトの300から上限の2048に上げます。 事前の設定が済めば、いよいよチャット文章を打ち込みます。以下画面の赤枠で、Human : と記載されている箇所に続いてこのような文章を打ち込みました。 「冷却ファンのFMEA（故障モードと影響解析）を作成してください。表形式で、列には、機能、故障モード、故障影響、故障原因、重要度（影響の重大度）、重要度（発生頻度）、重要度（検知難易度）、致命度（影響の重大度＊発生頻度＊検知難易度）、対策内容を入れてください。重要度はそれぞれ、1,2,3点のいずれかで表してください。多様な機能の観点で合計10個の故障原因について、対策内容は50文字程度を目安に具体的に記述してください。」 Run ボタンを押すと、紫色の箇所に Anthropic Claude v2 から回答文章が返ってきました。この状態では表形式で表示されていませんが、右上のほうにあるコピーボタンを押して、Excel などの表計算ソフトに貼り付けていただくと、表形式で表示されます。 必要に応じて罫線や色を追加するなどして見やすく編集しましょう。こちらが Anthropic Claude v2 によって数秒で作成された冷却ファンの FMEA になります。（※注意点として、生成系 AI ではランダムな要素が含まれるため、同じ質問をしても異なる回答が返ってくることがあります） このFMEAの良い点、改善が求められる点としては主に以下が挙げられます。 良い点 機能ごとに故障モード、影響、原因を網羅的に洗い出されている 致命度が指示された定義通りに算出されており、リスクの大きさが定量化されている 対策内容が適度な文字数である程度具体的に記載されている 改善が求められる点 重要度（影響、頻度、検知）の評価根拠が不明確（例えば、異音発生の重要度（影響）は本当に1点が相応しいのか、まだ動く状態だが騒音不快感を考慮すると影響はもっと大きいのではないか、など） 対策内容が要件に合うかが不明（例えば、定期的に確認する対策項目が多いが、要件に即時性が求められていた場合常時監視などの対策が必要となる、など） このように、生成系 AI を活用してドキュメントを作成する際には大事なポイントがあります。 ポイント1：質問段階で希望する出力形式を具体的に指定すると、それに沿ったドキュメント作成が行える ポイント2：項目の洗い出しや、ドキュメントのドラフト作成をまず生成系 AI に任せて、取捨選択判断や仕上げは人間が行うことで、品質向上や工数短縮が実現できる 生成系 AI は便利である一方、タスクを任せきりにしてしまうと思わぬ誤りがコンテンツに含まれてしまったりすることがあります。適材適所で生成系 AI に任せる部分、人間が責任を持って判断する部分を切り分けるようにして、設計開発業務を進化させましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングに必要なインフラストラクチャの機能および SDK (Software Development Kit) を提供するマネージドサービスです。前回の記事「 AWS SimSpace Weaver で実現する大規模空間シミュレーション: Part 1 」では、空間シミュレーションの分類や AWS での実現方法、そして AWS SimSpace Weaver が提供する機能と解決する課題について概要を紹介しました。本記事は Part 2 となり、AWS SimSpace Weaver が提供する機能と解決する課題についてのより詳細な解説を行い、AWS SimSpace Weaver を実際に導入するにあたってのステップを紹介します。 なお、本記事の内容は 2023 年 10 月時点の情報であるため、最新の情報は AWS SimSpace Weaver の Documentation を参照ください。 AWS SimSpace Weaver のコンセプト 本記事ではオンライン空間シミュレーションの具体例として、状況の可視化やインタラクティブなシナリオ操作を伴う人流・物流シミュレーションを例にして AWS SimSpace Weaver の使いどころを考えていきます。 大規模な人流シミュレーションとはどんなものでしょうか。ある施設で火事が発生し 100 人ほどが避難するシミュレーションはそれほど大規模ではないことはイメージできるかと思います。では大きなイベントホールから 50000 人が避難する場合はどうでしょうか。あるいは何らかの警報をきっかけに一都市全体で住民が一斉に避難を始めた場合のシミュレーションはどうでしょうか。他にも、数万台の車両が走行している一都市全体の交通状況を考慮した物流や緊急車両の走行シミュレーションではどうでしょうか。これらのシミュレーションの計算には大きなコンピュート処理能力が必要となります。従来のアプローチでは、CPU やメモリの能力を最大限に引き出すためにコーディング技術を駆使したり、チューニングを限界まで行ったりする必要がありました。そしてシミュレーションアプリケーションが単一プロセスや単一インスタンスの性能では処理しきれなくなったとき、スケールアップの限界を迎えます。よりスケールさせるには、スケールアウトのアプローチが必要となります。 空間シミュレーションをスケールアウト、つまり複数のインスタンスやプロセスにまたがって一つの空間シミュレーションを実行する典型的な方法は、空間分割です。シミュレーションで扱う空間を二次元 (または三次元) 座標のグリッドに分割し、各領域 (パーティション) の処理を異なるプロセスで実行するというアプローチです。 空間分割のイメージ このアプローチはシンプルですが、課題も存在します。1: 各パーティションを担当するプロセス間でシミュレーション対象の物体 (以降エンティティと呼びます) の情報を共有・同期する仕組みが必要なこと、2: 各パーティションの時刻を同期する仕組みが必要なこと、です。例えば避難経路の計算において近くの人との位置関係を考慮して次の移動方向を決めるとしたら、隣接したパーティションにいる人の位置も知る必要があります。また、各パーティションで時刻ずれが発生してしまうと、シミュレーション全体の結果が破綻してしまうので、パーティション間で足並みをそろえて処理を進める必要があります。単一インスタンス内の複数プロセスにおいてこれらの課題に対処するのも重労働ですが、異なるインスタンス上のプロセスまでスケールアウトする場合、これらの課題は更に複雑になります。AWS SimSpace Weaver はこれらの課題を解決するためのインフラストラクチャと SDK を提供します。 AWS SimSpace Weaver が提供する機能 1 点目はエンティティの情報の共有の仕組みです。AWS SimSpace Weaver は内部的に EC2 インスタンスを使用しますが、EC2 インスタンス上の複数のプロセス間や EC2 インスタンス間でエンティティ情報を共有するために、独自の共有メモリの仕組みを持っています。これは State Fabric と呼ばれ、各エンティティの座標位置に加え、ユーザーが自由に定義可能な属性情報を保持できます。また、分割された各パーティションにて他のパーティション内のエンティティ情報にアクセスするために、 Subscription の仕組みを提供しています。この仕組みにより、隣接したパーティションのエンティティ情報をもとにシミュレーションを実行したり、複数のパーティションにまたがった可視化を行ったり、シミュレーション全体にわたるメトリクスを計算したりできます。 Subscription の仕組みにより他のパーティション内のエンティティの情報を取得できる 2 点目は時刻同期の仕組みです。AWS SimSpace Weaver には、シミュレーションロジックを実行する各プロセスにおける時刻を制御する Simulation clock の仕組みがあります。Simulation clock で刻まれる時刻単位は tick と呼ばれ、その進むレート (clock rate) は 10 Hz, 15 Hz, 30 Hz, および unlimited (SimSpace Weaver app SDK 1.14.0 以降) から指定できます。Simulation clock により、複数インスタンス間でも単一の時間軸においてシミュレーションを実行できるようになります。 加えてシミュレーションの可視化が必要な場合、クライアントアプリケーションを独自で構築し、AWS SimSpace Weaver で動作しているシミュレーションアプリケーションにネットワーク経由で接続して可視化に必要な情報を得たり、ユーザー操作をシミュレーションに反映させることができます。 2023 年 10 月時点で AWS SimSpace Weaver が提供しない機能 本記事執筆時点では、AWS SimSpace Weaver が主に提供するのはシミュレーションを実行するインフラストラクチャのスケーリングを助ける機能です。AWS SimSpace Weaver はクライアントアプリケーションの作りやネットワークプロトコルには基本的に関与しないことに注意してください。SimSpace Weaver はクライアントアプリケーションが接続するためのエンドポイントを提供するため、お客様はエンドポイントに接続するアプリケーションやプロトコルを自由にデザイン・実装できます。 ただしスクラッチで実装するのが困難な場合には、SimSpace Weaver app SDK に同梱されている クライアントアプリケーションのサンプルコード、および Demo Framework が利用できます。Demo Framework にはシンプルなネットワークプロトコルのコードが含まれており、お客様の実装のスタートポイントとして活用できます。 SimSpace Weaver app SDK は本記事執筆時点で C++ および Python をサポートしています。また 3D エンジンのサポートとして Unity Plugin/Unreal Engine Plugin も提供しています。ただしこれらは可視化のためのクライアントアプリケーションで利用するものではなく、サーバーサイドアプリケーションにおけるシミュレーションロジックを各エンジンで実装する場合に利用するものであることに注意してください。 AWS SimSpace Weaver を導入するまでのステップ 最も AWS SimSpace Weaver の恩恵を受けられるお客様は、既に空間シミュレーションのワークロードを運用しており、その性能限界に課題を持っているお客様です。上述の AWS SimSpace Weaver の提供する機能を活用して既存のシミュレーションワークロードをスケールアウトし、大規模に拡張できます。もし現在利用しているサードパーティ製のシミュレーション用アプリケーションがあれば、それを AWS SimSpace Weaver 上でスケールさせることが可能かについて 是非 AWS へご相談ください 。 現在のシミュレーションがスタンドアロンアプリケーションで構築されている場合は、性能限界はそのアプリケーションを動かす端末、多くの場合はユーザーのクライアント PC のスペックの制約を受けます。よりパフォーマンスを高めたい場合、かつパフォーマンスのボトルネックがレンダリングではなくシミュレーションロジックにある場合、最終的には AWS SimSpace Weaver により大規模なシミュレーションへと進化できる可能性があります。ステップとしては、まずスタンドアロンアプリケーション内の処理をシミュレーションロジック部分と可視化部分に分離し、それらの間の情報をネットワーク経由でやり取りするように変更することで、それぞれを独立したアプリケーションとして実行できるようにします。次に、シミュレーションロジック部分のアプリケーションをサーバーサイドで、可視化部分のアプリケーションをクライアントサイドで実行する構成に変更します。結果としてクライアントサーバー構成のシミュレーション環境となります。シミュレーションロジックは独自実装でも構いませんし、3D エンジンを利用して実装する場合は Unreal Engine Dedicated Server 等の機能を利用するのが典型的な方法となります。ネットワークプロトコルについても、TCP や UDP をベースとした独自実装、または websocket や gRPC、MQTT 等の双方向通信が可能なプロトコルなど自由に利用できます。クライアントサーバー構成のシミュレーションはサーバーをスケールアップさせることで一定レベルまでパフォーマンスを高められます。スケールアップでの性能限界を超える必要が生じたら、是非 AWS SimSpace Weaver の導入をご検討ください。 既存のシミュレーションアプリケーションがなくこれから取り組む場合には、まずシミュレーションアプリケーションをクライアントサーバー構成で構築されることをおすすめします。スタンドアロンアプリケーションで可視化部分とシミュレーションロジック部分が密結合なアプリケーションを構築してからそれを分離するよりも、あらかじめ分離された構成で実装する方が容易な傾向があるためです。クライアントサーバー構成のシミュレーションアプリケーションを実装出来たら、先述の流れで最終的に AWS SimSpace Weaver の恩恵を受けることができます。 AWS SimSpace Weaver の始め方 本記事にて AWS SimSpace Weaver の特徴をつかんだら、AWS SimSpace Weaver の Product Manager によるサービス紹介動画 や、AWS re:Invent 2022 における AWS SimSpace Weaver ローンチ時のセッション を確認ください。AWS SimSpace Weaver の概念の詳細については 公式ドキュメントのユーザーガイド を参照ください。また、AWS SimSpace Weaver で動くアプリケーションを手軽に触ってみたい場合、 AWS SimSpace Weaver workshop を活用ください。 まとめ 本記事では AWS SimSpace Weaver が提供する機能とマッチするユースケース、および始め方について概念的な内容を中心に紹介しました。これまで技術的制約により一定規模で頭打ちとなっていた空間シミュレーションを大規模に拡張できるのが AWS SimSpace Weaver の最大の特徴です。開発者の皆様がインフラ構築の手間に煩わされることなく、すばらしいシミュレーションを構築されることを楽しみにしています。AWS SimSpace Weaver がマッチするユースケースを持つお客様や、今後そのようなワークロードに取り組む予定のあるお客様は、 是非 AWS へご相談ください 。 DNBソリューション本部 Game Techグループ ソリューションアーキテクト 西坂 信哉

AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングに必要なインフラストラクチャの機能および SDK (Software Development Kit) を提供するマネージドサービスです。しかしこの一文で AWS SimSpace Weaver が解決する課題やマッチするユースケースをイメージするのは簡単ではないと思います。Part 1 となる本記事ではそれらについて理解を深めるために、AWS SimSpace Weaver の概念を中心に説明します。（Part 2 は こちら ） なお、本記事の内容は 2023 年 10 月時点の情報であるため、最新の情報は AWS SimSpace Weaver の Documentation を参照ください。 空間シミュレーションとは AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングにまつわる課題を解決します。この点を理解するために、まずは空間シミュレーションとは何かを確認しましょう。 空間シミュレーションを大きく分類すると、座標系に基づいたシミュレーションとネットワークベースのシミュレーションがあります。座標系に基づいたシミュレーションでは、シミュレーション対象の要素は各々 2 次元や 3 次元の座標を持ちますが、ネットワークベースのシミュレーションでは、要素間の関係をネットワーク構造で表現し、各要素の状態と情報の伝達をシミュレートします。また別の分類として、 Agent ベースのシミュレーション と離散的なイベントベースのシミュレーションがあります。Agent ベースのシミュレーションでは様々な相互作用のもとで時刻と共に変化する物体の状態を逐次計算しますが、離散的なイベントベースのシミュレーションは、個々の物体よりも発生するイベントに注目し、各イベント発生時の状態を計算します。 この分類に基づくと、AWS SimSpace Weaver が適しているのは、座標系に基づいた Agent ベースの空間シミュレーションになります。このモデルは座標系上に存在する物体 (Agent) を扱います。各 Agent は周囲環境と外部入力に基づいて行動するアルゴリズムを持ち、Agent 同士も相互作用し、単一の連続的な時間軸に沿って変化する状態を逐次計算するモデルです。例えば、人流や物流のシミュレーションでは、歩行者や配達車両を Agent とし、他の Agent や周囲の障害物との位置関係や交通ルール等の規制を考慮し、衝突を回避したり目的地へ到達したりするように各 Agent の状態を計算します。このモデルでは、ネットワークベースや離散的イベントベースのシミュレーションと異なり、任意の時刻における全 Agent の位置を計算できるため、火事や河川氾濫等の災害時の避難やイベント開催時の人流シミュレーションにおいて、特に混雑するエリアや危険地帯の予測などに利用できます。 AWS で空間シミュレーションを実現する方法 空間シミュレーションには複数の種類があり、それぞれ AWS 上での最適な実現方法は異なります。例えば流体解析 (Computational Fluid Dynamics: CFD) によるシミュレーションや天候予測といったものは、最適な計算手法や分散処理手法が確立しているため、 ハイパフォーマンスコンピューティング (HPC) 最適化インスタンス を利用するのがコストパフォーマンスの高い方法です。一方で AWS SimSpace Weaver は、独自のアルゴリズムで行うシミュレーションや、インタラクティブにトライアンドエラーを繰り返すようなシミュレーションをスケールアウトするのに適しています。 次に、空間シミュレーションをオフラインシミュレーションとオンラインシミュレーションの二つに分類します。オフラインシミュレーションとは、シミュレーション実行中の外的な入力を許さず、初期パラメータとシナリオに沿って進むものとします。このようなシミュレーションはできる限り速く処理できることが重要です。AWS SimSpace Weaver はこのようなユースケースにも対応できますが、シミュレーションのアルゴリズムによってはやはり HPC 最適化インスタンスを利用する方がよい場合もあります。 一方、オンラインシミュレーションは、外部からの入力によるシミュレーションへの干渉を許します。外部からの入力とは、例えば災害時避難の人流シミュレーションにおいて、避難中に障害物を置いたり建物を壊したりなどの操作を行うことです。決められたシナリオではなく、インタラクティブにシミュレーションに手を入れることで複雑な仮説検証を実現できます。エンターテインメント分野においても、MMO (Massively Multiplayer Online) ゲームのようなオンラインゲームや、広い空間に多数のユーザーがアバターとして参加して交流するサービスなどは、オンラインシミュレーションの一種と言えるでしょう。AWS SimSpace Weaver はこのようなオンラインシミュレーションを大規模にスケールアウトするようなユースケースに特に適しています。 オフラインおよびオンラインシミュレーションのどちらのユースケースにおいても、AWS SimSpace Weaver がマッチするのは「単一の空間シミュレーションを（単一プロセスや単一インスタンスでは処理できないほど）大規模にスケールしたい」場合です。単一インスタンスで扱える規模の空間シミュレーションであれば、シンプルに単一インスタンスで実行するべきです。またそのような単一インスタンスで実行できる規模のシミュレーションを大量に並列実行して早く結果を得たいようなユースケースでは、AWS Batch 等の他の HPC 関連サービスが活用できます。 AWS SimSpace Weaver が解決する課題とは 空間シミュレーションを大規模に実行する際に問題となるのは、シミュレーション内で扱う物体の数が増えることで計算リソースが不足することです。シンプルな対策はシミュレーションロジックの最適化とインスタンスのスケールアップですが、それにも限界があります。更なる対策として空間シミュレーションを複数のインスタンスにスケールアウトする方法があります。例えば各インスタンスが扱う空間上の領域を分割して分散処理する方法です。この時の主な課題は、各インスタンス間での情報のやり取りの仕組みと、時刻同期の仕組みです。特にオンラインシミュレーションにおいてはリアルタイム性が重要なため、これらの課題が顕著となります。 AWS SimSpace Weaver はこれらの課題を解決するためのインフラストラクチャと機能をマネージドに提供します。お客様は AWS SimSpace Weaver により提供される Software Development Kit (SDK) を利用してシミュレーションロジックを実装することで、シミュレーションをスケールアウトできます。また AWS SimSpace Weaver はシミュレーションを実行するサーバーへネットワーク接続するためのエンドポイントを提供できるため、外部からの入力やシミュレーションの可視化を行うアプリケーションと情報のやり取りが可能です。 まとめ AWS SimSpace Weaver は、座標系に基づいた Agent ベースの空間シミュレーション、特にオンラインシミュレーションのユースケースにおいて、単一のプロセスやインスタンスでは処理しきれないほど大規模にスケールしたい場合に適したサービスです。AWS SimSpace Weaver は、スケールに伴って生じる課題である、各インスタンス間での情報のやり取りの仕組みや時刻同期の仕組みなどをマネージドに提供します。AWS SimSpace Weaver で、大規模な空間シミュレーションを実現しましょう。 Part 2 の記事 では、AWS SimSpace Weaver のコンセプトと機能の概要を紹介します。 DNBソリューション本部 Game Techグループ ソリューションアーキテクト 西坂 信哉 リソース AWS SimSpace Weaver User Guide and API Reference AWS SimSpace Weaver launch at re:Invent 2022 in AWS CEO’s keynote AWS CTO’s re:Invent 2022 keynote discussing AWS SimSpace Weaver in detail Demo – Large City Crowds Simulation Demo – Emergency Response Simulation Case Study by Duality Robotics – Building City-scale Simulations

このブログは Sudhir Amin（Sr. Solutions Architect）と Mehmet Gunes（Senior Technical Account Manager）と Nishanth Charlakola（Associate Director at S&P）によって執筆された内容を日本語化したものです。。原文は こちら を参照して下さい。 組織は複雑な SQL サーバーインフラストラクチャにおいて、データ損失を防ぐために、可用性が高く災害復旧が可能なソリューション（HADR）を構築する必要があります。クラウドの急速な普及に伴い、様々な業種の企業が、既存の環境をクラウドに移行する技術的なプロジェクトにおいての概念実証（Proof of Concept）の重要性に気づきつつあります。どのような規模の企業にとっても、導入を成功させるためには、スピードを維持しながら、基準を設定し、リスクを最小限に抑え、多角的に検証を行うことが重要です。 S&P Global Market Intelligence は世界の金融市場およびそれらの市場を構成する企業や業界に関する実用的なインテリジェンスを提供するリーディング・プロバイダーであり、160 年以上の歴史があります。主に ESG ソリューション、ディープデータ、重要な経済・市場・ビジネス要因に関する洞察を提供し、ビジネスの進歩を加速させます。このブログでは、S&P Global Market Intelligence が、マルチリージョン Amazon FSx for NetApp ONTAP （FSx for ONTAP）アーキテクチャを実装し概念実証を成功させることで、Microsoft SQL Server ワークロードの事業継続性と災害復旧（DR）の目標を達成するための技術評価を行った方法について説明します。 ビジネスにおける問題点と現状のアーキテクチャ S&P Global のマーケット・インテリジェンス部門のデータサービスエンジニアリングチームは、大規模な Microsoft SQL Server を管理しており、その上で稼働するバックエンド処理を AWS で運用・保護するための、コスト最適化されたクラウドネイティブソリューションを必要としていました。このデータ処理インスタンスには 100 以上の SQL Server データベースがあり、総ストレージ容量は 100 TB を超え、年間約 10 % 増加しています。バックエンド処理システムは、すべてのデータの取り込みと、さまざまな外部クライアント向け製品へのデータ配信を行うためのソースデータベースサーバーとして機能しています。データの取り込みは、コンテンツ取り込み UI ツールを使用したプロセスで自動化されており、これらのコンテンツで作業するユーザーは世界中に散らばっています。データ配信の観点からは、このシステムは SQL Server のパブリッシャーとして機能し、何千ものテーブルを持つ数百のデータベースを公開しています。 インフラストラクチャのレベルでは、プライマリ環境と DR 環境の両方に SQL データベースをホストするための 2 ノードの Windows フェールオーバークラスター（WSFC）があり、共有ストレージサービスを提供する高速な SAN ストレージシステムに接続されています。次の図に示すように、各データセンターの 2 つのストレージシステム間で構成された SAN レプリケーションは、フェールオーバークラスタリングソリューションに地理的冗長性を提供します。 図 1: オンプレミス上の SQL Server HADR アーキテクチャの論理コンポーネント プライマリサイトでフェールオーバーが発生した場合、WSFC サービスはプライマリインスタンスのリソースの所有権をサイト内の指定されたフェールオーバーノードに移動します。 プライマリデータセンターに壊滅的な災害が発生した場合、クライアントアプリケーションのトラフィックは DR サイトに誘導され、レプリケーションされたデータベースインスタンスにアクセスします。DR サイトのストレージシステムは 2 つの Windows フェールオーバークラスターノードに接続され、レプリケーションされたストレージボリューム上のデータベースへのアクセスを提供し、2 つのデータセンター間の 4 つのノードすべてで可用性を実現します。データベース管理者（DBAs）が手動でフェールオーバーを行い、2 つのストレージボリューム間のミラー関係を解除することで、DR サイトのデータベースをオンラインにすることができます。 加えて、多数の社内外アプリケーションにデータサービスを提供するために、SQL Server インスタンス上に数百のパブリケーションデータベースと数千のアーティクルを持つ MS トランザクションレプリケーションが構成されています。クライアントアプリケーションは、 Windows フェールオーバークラスター内の SQL Server ネットワーク名を使用してデータベースサービスにアクセスします。したがって、RPO 10 分、RTO 1 時間という目標でシームレスなフェールオーバーを実現するには、構成された 2 つのサイト間におけるドメインの名前解決とネットワーク構成が非常に重要でした。 技術的要件 以下の必要条件が定義されていました： 多数のデータベースが存在する環境をサポートするために、ストレージベースのレプリケーション機能を備えた共有ストレージソリューションを活用して、マルチリージョン SQL Server フェールオーバークラスターインスタンスを実装します。 RPO 10 分、RTO 1 時間を達成するために、両方のサイトに配置されたストレージソリューションは、継続的、非同期、そして双方向のレプリケーションをサポートする必要があります。 ストレージソリューションは 100 TB を超えるストレージ容量をサポートし、SQL Server クラスター用に高い IOPS とスループットを実現できる必要があります。 SQL Server をサポートする 非対称共有ストレージ を使用し、異なる AWS リージョン にまたがった単一で可用性の高い Windows フェールオーバークラスターインスタンスを実装します。 Active Directory（AD）と信頼性の高い DNS サービスを備えた耐障害性の高い Windows インフラストラクチャを実装し、クライアントアプリケーションのシームレスなフェールオーバーをサポートしています。 ソリューション概要 マルチリージョンアーキテクチャで SQL Server AlwaysOn FCI を導入するには、共有ストレージオプションと、リージョン間のデータレプリケーション機能が不可欠でした。そこで、クロスリージョン DR にて利用可能な SnapMirror レプリケーションを備えた、高い可用性と耐久性を誇るストレージ、FSx for ONTAP を使用することで、厳しい RPO と RTO の要件を満たします。FSx for ONTAP はフルマネージドサービスであり、自社管理ストレージと比較して、高い信頼性とパフォーマンス、かつセキュアな共有ファイルストレージを、クラウドにてコスト効率良く簡単に導入・拡張することができます。 図 2: マルチリージョン FSx for ONTAP と SnapMirror レプリケーションによる DR ソリューション導入の手順 チームはこの概念実証のために、バージニア北部リージョン（us-east-1）とオハイオリージョン（us-east-2）にまたがる、Windows フェールオーバークラスターを構築しました。手順は以下の通りです。 リージョン間の VPC ピアリング を設定する 2 つのアベイラビリティ・ゾーン（AZ）にまたがった、2 つのプライベートサブネットを含む VPC をプライマリサイトとなる us-east-1 にデプロイします。 DR 用 SQL Server ノードをホストするための、単一の AZ で 1 つのプライベートサブネットを含む VPC を DR サイトとなる us-east-2 にデプロイします。 リージョン間で AD サービス をサポートするための ネットワーク通信 を有効にする 両方のリージョンで Windows フェールオーバークラスターと SQL デプロイメントをサポートするためのネットワークアクセスを持つ AD をデプロイします。 SQL Server の通信用に、ノード間およびクライアントアクセスを許可したセキュリティグループを設定します。 各リージョンに SQL Server を配置する プライマリサイトと DR サイトの両方に、SQL Server インスタンスをデプロイします。最初のテストでは 2 つのサイトで独立した SQL Server を使用しましたが、その後プライマリサイトの 2 ノード SQL FCI クラスタへ移行し、DR サイトの 1 ノードを同クラスタに参加させました。 Windows フェールオーバークラスターを作成するための適切な権限を持つ SQL Server サービスアカウントの資格情報と、SQL Server フェールオーバークラスターインスタンスを作成します。 3 つの SQL Server はすべて共通の AD ドメインに参加し、SQL Server 用の共通サービスアカウントを使用します。 クラスターのクォーラムは、DR サイトが投票に参加せず、プライマリサイトの投票数が奇数になるように構成します。 このアーキテクチャでは、プライマリサイトに 2 つのノードがあるため、ファイル共有監視を構成し、クォーラムのモードを「Node and File Share Majority」とする必要があります。詳細については、 クォーラム構成 と ディザスタリカバリ構成におけるクォーラムの考慮事項 を参照してください。 各リージョンに FSx for ONTAP ファイルシステムを実装する プライマリサイト（us-east-1）に、要件に従って適切な SSD 容量を持つ FSx for ONTAP ファイルシステムを作成します。 DR サイト（us-east-2）に、プライマリサイトで作成された SSD 容量と同量以上の、セカンダリ FSx for ONTAP ファイルシステムを単一 AZ に作成します。 プライマリサイトの 2 つのノードは、プライマリ FSx for ONTAP ファイルシステムからデータを取得し、ストレージはプライマリサイトのノードにのみ表示され、DR サイトのノードには表示されません。これは非対称ストレージ構成と呼ばれます。 同様に、DR サイトのノードは、セカンダリ FSx for ONTAP ファイルシステムからデータを取得し、ストレージは DR サイトのノードからのみアクセスできます。 DR サイトのストレージは Windows ノードにはマッピングされません。通常 DR サイトのストレージは読み取り専用状態で、フェールオーバー時に読み書き可能に変更されます。 2 つの FSx for ONTAP 間で SnapMirror の非同期レプリケーションが確立され、DR サイトにフェールオーバーが発生すると、レプリケーション関係において送信元と送信先の関係がセカンダリとプライマリで逆になります。 注：データ損失を完全に防ぐには、同期型のレプリケーションでのみ実現可能なことが重要です。同期レプリケーションを実装するには、ラウンドトリップタイム（RTT）が 10 ms 以下（物理距離約 150 km 以内）である必要があります。災害対策の用途では、物理距離の制限がなく、データ損失を最小限に抑えて DR サイトにレプリケートする必要があるため、非同期レプリケーションが有効です。 SnapMirror の同期型と非同期型の詳細については、ネットアップのブログ記事を参照してください。 How to Devise an Effective Data Protection and Disaster Recovery Approach. 技術的検証 データの一貫性と可用性を確認するため、チームは SnapMirror 関係を解除した後にデータベースをオンラインにし、セカンダリファイルシステムをクリーンアップできることを検証しました。また、巨大なトランザクションの途中で SQL Server インスタンスをフェールオーバーし、セカンダリファイルシステム上で処理中のトランザクションが正常にロールバックされることも検証しました。テストフェーズで実施された各 DR 訓練では、MS トランザクションのレプリケーションステータスとアプリケーションの接続性が監視され、エンドユーザーがデータにアクセスできることを確認しました。実装とデータ検証の手順は、 Amazon FSx for NetApp ONTAP を使用した SQL Server Always On Failover Cluster インスタンスの HA と DR の実装 という投稿で説明されています。これは、マルチリージョン FSx for ONTAP ファイルシステムアーキテクチャを SnapMirror を用いて実現し、SQL Server の HA および DR アーキテクチャを設計する際に役立ちます。 結果 社内のコンテンツとデータ処理アプリケーションは、社外顧客向け製品にデータを配信するための基礎になります。S&P Global Market Intelligence は、FSx for ONTAP の SnapMirror を使用して、SQL Server フェールオーバークラスターインスタンスを 2 つのリージョン間で実装し、HADR 構成を実現しました。SnapMirror レプリケーションによって、HADR の目標である RPO 10 分、RTO 1 時間という厳しい目標を簡単に達成できました。これにより、アプリケーションの信頼性と耐障害性が向上しました。また、ネイティブのネットワーク圧縮機能によって帯域幅の使用率も低下し、FSx for ONTAP システム間のデータ転送が高速化されました。 まとめ このブログでは、S&P Global がビジネスクリティカルなコンテンツとデータを処理するアプリケーションのために、FSx for ONTAP を使用して、シームレスなクロスリージョン HADR 構成を AWS に導入・検証するためのソリューションを紹介しました。FSx for ONTAP を使用することで、ストレージ部門における運用保守の管理工数を削減し、データの一貫性や信頼性のテストと検証などユーザー目線での改善業務に集中することができます。その他にも、FlexClone などの機能を活用して開発環境やレポーティングおよび分析用の ETL 環境を構築、 SnapCenter プラグインを実装して容量効率の高いデータベースのバックアップとリストアの実行、スナップショットやアクセス頻度の低いストレージブロックをキャパシティプール階層に可能な限り移動しコスト削減を実施、といったことも可能です。 この記事をお読みいただきありがとうございました！ 翻訳はネットアップ合同会社の岩井様、監修は Solutions Architect 吉澤が担当しました。 Sudhir Amin Sudhir Amin は、Amazon Web Services の Sr. Solutions Architect です。ニューヨークを拠点に、さまざまな業種の企業にアーキテクチャのガイダンスと技術支援を提供し、クラウド導入を加速しています。彼はボクシングや UFC といった格闘技の大ファンであり、野生動物保護区のある国を旅行して、世界で最も雄大な動物を間近に見るのが大好きです。 Mehmet Gunes Mehmet Gunes は Amazon Web Services の Senior Technical Account Manager です。TAM として、クラウドコンピューティングの導入とビジネスの変革を成功させるためのパートナーとして顧客をサポートしています。ツール、技術的な専門知識、技術に特化したスペシャリストを駆使して、顧客のビジネスや運用の成果、技術的な課題を理解し、AWS から最大の価値を得られるよう支援しています。彼は余暇に旅行し世界中の新しい場所を探索することを愛しています。 Nishanth Charlakola Nishanth Charlakola は、S&P Global Market Intelligence データサービスエンジニアリングチームの Associate Director です。大規模な SQL Server システムの設計、管理、保守において 14 年以上の業界経験を有し、5 年以上のクラウド経験があります。S&P Global Market Intelligence では、主に SQL Server ワークロードのクラウドへの移行を担当しています。彼はインドのハイデラバード在住で、余暇はイングランドプレミアリーグの Chelsea FC を応援しています。

〜 第２回 デュアル・システム 〜 このブログでは、クラウドの価値を最⼤限に活⽤するための組織のビジネスアジリティの高め方についてご紹介します。第２回では、ジョン・Ｐ・コッターの「デュアル・システム」の紹介と、AWSが「デュアル・システム」の仕組みをどのように実現しているのかについて解説します。 「デュアル・システム」とは 「デュアル・システム」とは、ハーバードビジネススクールのジョン・Ｐ・コッター教授が著書「ジョン・Ｐ・コッター　実行する組織」で提唱している大企業がビジネスアジリティを高めるための組織のあり方のことです。詳細はぜひ書籍を読んで頂きたいと思いますが、ここでは簡単に紹介します。デュアルという名のとおり、「デュアル・システム」とは企業の中に2つの組織体が存在し機能している状態を意味しています。ひとつは、企業が発展していく段階でマネージメントの効率化を求めた結果構成される組織形態で、どの企業にも存在する階層型組織です。皆さんもよくご存知のとおり、階層のトップには社長がいて、配下には複数の事業部やバックオフィス系部署が配置され、それぞれの部署には責任者がいて、その配下に従業員が所属しています。各階層組織の責任者は人事上のマネージャーでもあり、その階層の組織を運営しています。もうひとつは、ネットワーク型組織と呼ばれるもので、階層型組織のさまざまな階層や部署から結集した意欲的な人たちによる組織です。この組織には、人事上のマネージャーは存在せず上下関係もありません。階層型組織には全ての社員が所属しますが、ネットワーク型組織への所属は任意です。そして最も重要な点は、このネットワーク型組織は有志社員による非公式な団体ではなく、階層型組織から認知された公式な組織であるということです。この２つの組織体のイメージと特徴は、以下の図のとおりです。 出典：「ジョン・Ｐ・コッター　実行する組織」 p.34, p.49 AWSにおけるデュアル・システム 当然ですが、AWSにも階層型組織が存在しています。他の企業と同様、その階層は非常に深く、組織はサイロ化されているため、普通に働いているだけでは別の組織や階層に所属している社員と一緒に働く機会は多くありません。一方、AWSにはネットワーク型組織も存在しています。AWSのネットワーク型組織は、いくつかありますが、その中でも最も巨大かつ成果を上げているのが、SA(Solutions Architect)を中心に組織されているTFCと呼ばれる組織体です。TFCとは、Technical Field Communitiesと呼ばれるもので、階層型組織の様々な部署やチームの社員がこのネットワーク型組織に参加しています。したがって、ネットワーク型組織に参加するということは、他部署の人間や他チームのメンバーと一緒に働くことを意味します。コミュニティーというと、有志社員による業務時間外に活動する組織のように想像される方もいるかも知れませんが、AWSにおけるTFCは階層型組織から公式に認知されたネットワーク型組織なので、その活動は業務の一環として業務時間内に行われており、活動内容は社外のパブリック・スピーキングや社外向けのテクニカルコンテンツの作成、社内へのトレーニング提供など多岐にわたります。活動量の割合は個人差がありますが、階層型組織での業務が７割から８割、ネットワーク型組織での業務が２割から３割です。階層型組織は社員のTFCへの参加を推奨していますが、TFCへの参加は義務ではない為、全ての社員が参加している訳ではありません。参加するかどうかは、社員の自主性に任されています。TFCの運営自体も、管理職やマネージャーが行なっているわけではなく、参加している社員が自律的に必要な役割を担って運営しています。ここでは、ネットワーク型組織のひとつの例としてTFCを紹介しましたが、AWSには他にも様々なネットワーク型組織が存在しています。それら全てに共通している点は、社員による自律的な活動でありつつも、その活動は階層型組織から公式に認知された業務の一環となっていることです。 組織のライフサイクル ここで、書籍「ジョン・Ｐ・コッター　実行する組織」の中からもうひとつ、「多くの企業がたどる、組織のライフサイクル」について紹介します。 出典：「ジョン・Ｐ・コッター　実行する組織」 p.82 この図は、企業の成長とともに組織が変化して遷移してゆく状況を表現しています。図の上段左側は、創業期の企業がネットワーク型組織から始まっていることを表しています。企業の成長とともにネットワーク型組織は大きくなってゆき、ある段階で信頼性と効率性を求めて、図の中段左側の状態のように階層型組織が生まれます。その後、階層型組織がどんどん大きくなる一方で、ネットワーク型組織は少しずつ小さくなり、最後は図の下段右側のように階層型組織だけになります。この図とともに、「ジョン・Ｐ・コッター　実行する組織」p.81-83には、以下のように記述されています。 “こうした道のりの果てに階層組織が体系化され整備されるが、その間も企業は成長を続け、シェアを拡大し、規模の経済を確立し、強力なブランドを打ち立て、顧客と良好な関係を築く。だが、成長と繁栄の影で、大切なものが失われていることが多い。巧みに生き延び高収益を挙げていても、イノベーションを次々に生み出していたかつてのスピードやキレはもうない。ゆえに成長は勢いを失い、徐々に減速していく。機を見るに敏な新参企業が、顧客やシェアを奪い取るのはこんなときだ。その結果として価格競争が起き、利益率を押し下げるかも知れない。” 「デュアル・システム」の再構築 大企業や老舗企業が俊敏性とスピードを取り戻すには、かつて経験したであろう、図表4-4の中段右側の状態、すなわち階層型組織とネットワーク型組織が共存している状態を再び作りだす必要があります。しかし、消滅して忘れ去られたネットワーク型組織を復活させるには、どこからどのように開始したら良いのでしょうか？ AWSにおけるネットワーク型組織の例としてTFCという組織体を紹介しましたが、TFC(Technical Field Communities)はその名のとおりテクノロジーをテーマに活動している組織です。テクノロジーをテーマにした組織がネットワーク型組織として活躍しているのは、AWS がテクノロジーの会社であるからに他なりません。AWSがテクノロジーの会社であるが故にテクノロジーをテーマにしたネットワーク型組織が階層型組織から公式な業務の一環として認知されているのです。つまり、ネットワーク型組織が業務の一環として、階層型組織から公式に認知される為には、どのような企業であれ、ネットワーク型組織は企業のビジネスと密接に関連している必要があるということです。そこで、ネットワーク型組織を復活させる際には、階層型組織のビジネス課題に取り組む小さな組織として始めることをお勧めします。その際の注意点として、ネットワーク型組織に参加する社員は自主的かつ自律的に活動する必要がある為、やる気のある社員を社内から募集するようにします。まずは、図表4-4の下段左側の状態を作り出し、そこから徐々に中段目右側の状態に持っていくことになります。その際、「ジョン・Ｐ・コッター 実行する組織」p.41に示されいる以下の「八つのアクセラレータ」を参考に進めると良いでしょう。 出典：「ジョン・Ｐ・コッター 実行する組織」 p.41 まとめ 今回は、ジョン・Ｐ・コッターの「デュアル・システム」の紹介と、AWSが「デュアル・システム」の仕組みをどのように実現しているのかについて解説しました。また、ネットワーク型組織が消滅して階層型組織だけになっている企業において、ネットワーク型組織を再構築し、「デュアル・システム」として機能させる為の指針も示しました。第１回でお伝えしたとおり、「デュアル・システム」は、アジャイルの要素「人々」に相当する部分です。アジャイルの要素「人々」は、他の要素「プロセス」や「ツール」よりも変革に時間がかかります。時間がかかるからこそ先送りせず早い段階から着手する必要があります。そして、アクセラレータの⑥「早めに成果を上げて祝う」を実施することをお勧めします。AWSで提供している Experience-Based Acceleration (EBA) というプログラムにおいても、「チームで成果を称賛する」ことを推奨しています。称賛することがチームの「内発的動機づけ」に繋がるからです。是非お試しください。 〜 第１回 アジャイルの動向 2023年 〜 【参考文献】 ジョン・Ｐ・コッタ― (著), 村井 章子 (翻訳)「 ジョン・Ｐ・コッタ― 実行する組織―――大組織がベンチャーのスピードで動く 」ダイヤモンド社 (2015/7/2) ジョン・P・コッター (著), バネッサ・アクタル (著), ガウラブ・グプタ (著), 池村千秋 (翻訳)「 CHANGE 組織はなぜ変われないのか 」 ダイヤモンド社 (2022/9/20) 河野洋一郎 カスタマーソリューションズマネージャーとして2020年にAWSに入社して以来、「クラウドジャーニーとアジャイルジャーニーを同時進行してビジネスアジリティを最大化せよ！」をモットーとして、クラウド時代におけるお客様のビジネス価値実現のお手伝いをしています。AWS以前は、CA TechnologiesにてDirector of ITとしてIT組織のアジャイル化を推進していました。

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

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

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

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

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

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

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

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

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

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