9 月が到来し、 AWS re:Invent 2024 の開催まであと 3 か月となりました。カンファレンスで発表される新しいサービスやお知らせが、とても楽しみです。新型コロナウイルス感染症のパンデミックの直前、re: Invent 2019 に参加したことを思い出します。60,000 人以上の参加者を集めた最大の対面式 re:Invent で、私がこのイベントに参加するのは 2 回目でした。熱い雰囲気を感じることができ、すばらしい体験となりました! 現在、AWS re:Invent 2024 の 登録 を受け付けています。ラスベガスで、5 日間のエキサイティングな基調講演、ブレイクアウトセッション、チョークトーク、インタラクティブな学習の機会、キャリアを変えるようなつながりを楽しみましょう! では、8月26日週の新しい発表を見てみましょう。 8月26日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS Parallel Computing Service の発表 – AWS Parallel Computing Service (AWS PCS) は、ハイパフォーマンスコンピューティング (HPC) ワークロードを AWS で実行およびスケールできる、新しいマネージドサービスです。テクニカルサポートと豊富なカスタマイズオプションが組み込まれたフルマネージドの Slurm スケジューラを使用して、科学モデルやエンジニアリングモデルを構築し、シミュレーションを実行できます。HPC 環境を特定のニーズに合わせてカスタマイズし、お好みのソフトウェアスタックと統合することも可能です。また、コンピューティング、ストレージ、ネットワーク、視覚化リソースを統合する完全な HPC クラスターを構築し、インスタンスを 0 個から数千個までシームレスにスケールできます。詳細については、 AWS Parallel Computing Service と Channy のブログ投稿 をご覧ください。 Amazon EC2 ステータスチェックで、アタッチされた EBS ボリュームの到達可能性状態のサポートを開始 – Amazon EC2 ステータスチェックを使用して、インスタンスにアタッチされている Amazon EBS ボリュームが到達可能で、入出力操作を完了できるかどうかを直接モニタリングできるようになりました。この新しいステータスチェックでは、Amazon EC2 インスタンスで実行されているアプリケーションのパフォーマンスに影響を与える可能性のある、添付ファイルの問題やボリュームの障害をすばやく検出できます。さらに、これらのステータスチェックを Auto Scaling グループ内で統合して、EC2 インスタンスの状態をモニタリングし、影響を受けたインスタンスを置き換えて、アプリケーションの高可用性と信頼性を確保できます。アタッチされた EBS ステータスチェックを、インスタンスステータスチェックおよびシステムステータスチェックと併用して、インスタンスの状態をモニタリングすることもできます。詳細については、「 Amazon EC2 インスタンスのステータスチェック 」ドキュメントを参照してください。 Amazon QuickSight で埋め込みダッシュボードのビュー共有のサポートを開始 – Amazon QuickSight で、埋め込みダッシュボードのビューを共有できるようになりました。この機能では、組み込みの QuickSight ダッシュボードを使用して、より多くのコラボレーション機能をアプリケーションで有効にできます。さらに、匿名ユーザーのブックマークなどのパーソナライズ機能も有効にできます。アプリケーションから離れずに、変更のみを表示する一意のリンクを共有したり、ダッシュボードまたはコンソールの埋め込みを使用して、 QuickSight Embedding SDK を利用するカプセル化された QuickSight のリファレンスを含むアプリケーションページへの共有可能なリンクを生成したりできます。さらに、QuickSight の読者は、この共有可能なリンクをピアに送信することが可能です。ピアが共有リンクにアクセスすると、埋め込まれた QuickSight ダッシュボードを含むアプリケーションのページに移動します。詳細については、 埋め込みビューのドキュメント を参照してください。 Amazon Q Business がユーザー ID 認証のための IAM フェデレーションをリリース – Amazon Q Business は、エンタープライズデータ向けに生成 AI ビジネスエキスパートをデプロイする、フルマネージドサービスです。Amazon Q Business IAM フェデレーション機能を使用すると、アプリケーションを直接 ID プロバイダーに接続し、これらのアプリケーションのユーザー ID とユーザー属性を取得できます。以前は、ID プロバイダーからのユーザー ID 情報を AWS IAM アイデンティティセンター に同期し、Amazon Q Business アプリケーションを IAM アイデンティティセンターに接続して、ユーザー認証を行う必要がありました。リリース時点で、Amazon Q Business IAM フェデレーションは ID プロバイダー接続用の OpenID Connect (OIDC) プロトコルと SAML2.0 プロトコルをサポートする予定です。詳細については、 Amazon Q Business のドキュメント をご覧ください。 Amazon Bedrock がクロスリージョン推論のサポートを開始 – Amazon Bedrock は、異なる AWS リージョンのコンピューティングを利用して、トラフィックバーストをシームレスに管理できるオプション機能である、クロスリージョン推論のサポートを発表しました。オンデマンドモードを使用している場合、クロスリージョン推論を使用することにより、より高いスループット制限 (リージョン内で割り当てられたクォータの最大 2 倍) を実現し、ピーク需要時のレジリエンスを強化できます。オプトインすると、需要の変動を予測するために時間と手間を費やす必要がなくなります。クロスリージョン推論は、トラフィックを複数のリージョンに動的にルーティングし、各リクエストの可用性を最適化して、使用率の高い期間でもスムーズなパフォーマンスを実現します。事前定義済みのリージョンのセットから選択することで、推論データのフロー先を管理できるため、適用されるデータレジデンシー要件や主権法への準拠が容易になります。リストについては、「 サポートされているリージョンとクロスリージョン推論のモデル 」を参照してください。開始するには、 Amazon Bedrock のドキュメント またはこの 機械学習ブログ を参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon EC2 の C6gd インスタンスと R6gd インスタンスが AWS 欧州 (スペイン) リージョンで利用できるようになりました。 C6gd インスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、CPU ベースの機械学習推論などの計算集約型ワークロードに適しています。R6gd インスタンスは、オープンソースデータベース、インメモリキャッシュ、リアルタイムのビッグデータ分析などの、メモリ集約型ワークロードを実行するために構築されています。 Amazon OpenSearch Serverless が AWS GovCloud (米国西部) リージョンで利用できるようになりました。 OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションです。複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 AWS Global Accelerator は、エジプトのカイロに新しいエッジロケーションを開設します。 AWS Global Accelerator は、グローバルユーザーに提供するアプリケーションの可用性とパフォーマンスの向上をサポートする、ネットワーキングサービスです。 Amazon Redshift Serverless が AWS アジアパシフィック (ジャカルタ) リージョンで利用できるようになりました。 Amazon Redshift Serverless は Amazon Redshift のサーバーレスオプションで、データウェアハウスインフラストラクチャをセットアップして管理することなく、分析をほんの数秒でより効率的に実行およびスケールすることができます。 Amazon OpenSearch Service が Graviton3 (C7g、M7g、R7g、R7gd) インスタンスのサポートを開始しました。 Amazon OpenSearch Service が AWS Graviton3 インスタンスのサポートを開始しました。これにより、Graviton2 ベースのインスタンスと比較して、パフォーマンスが最大 25% 向上します。 AWS Config 適合パックが、新たに 12 の AWS リージョンで利用できるようになりました。 適合パックを使用すると、 AWS Config ルールとそれらに関連付けられた修復アクションを 1 つのパッケージにまとめることができるため、大規模なデプロイが簡素化されます。これらの機能は、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、中東 (UAE)、アジアパシフィック (ハイデラバード)、アジアパシフィック (大阪)、欧州 (ミラノ)、イスラエル (テルアビブ)、カナダ西部 (カルガリー)、欧州 (スペイン)、欧州 (チューリッヒ)、AWS GovCloud (米国東部)、AWS GovCloud (米国西部) に追加されました。 その他の AWS イベント AWS GenAI Loft は、クラウドと AI に関する AWS の専門知識を示すコラボレーションスペースと没入型体験です。また、スタートアップや開発者に、AI 製品やサービスへの実践的なアクセス、業界のリーダーとの限定セッション、投資家や仲間との貴重なネットワーキングの機会を提供します。 お近くの GenAI Loft の開催地を見つけて 、ご登録ください。 提供: Antje Barth 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。今年の AWS Summit は終了間近です。まだご登録いただけるのは、 ジャカルタ (9 月 5 日)、 トロント (9 月 11 日)、 オタワ (10 月 9 日) の 3 つです。 AWS Community Day では、世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されます。AWS Summit 2024 は間もなく終了しますが、AWS Community Day は大いに盛り上がっています。今後開催される AWS Community Day は、 ベルファスト (9 月 6 日)、Antje Barth が基調講演を行う サンフランシスコベイエリア (9 月 13 日)、 アルゼンチン (9 月 14 日)、 アルメニア (9 月 14 日) です。 近日中に開催されるすべての AWS による対面およびバーチャルイベント は、こちらで閲覧することができます。 9月2日週はここまでです。9月9日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS Amplify Hosting は、キャッシュの効率性の大幅な改善を発表することを喜ばしく思います。最適化されたキャッシュルールと、キャッシュキーからクッキーを削除することによる高いキャッシュヒット率をお客様に提供します。また、Next.js の国際化 (i18n) サポートなどのユースケースを可能にする、追加のヘッダーへのアクセスも提供しています。この変更により、エンドユーザーはコンテンツを高速かつ効率的に受け取れ、より優れたユーザーエクスペリエンスが実現できるようになります。 改善ハイライト 最適化されたキャッシュポリシー キャッシュキーから Cookie を削除する機能 追加の CloudFront ヘッダーの転送 Next.js 国際化 (i18n) をサポート Brotli 圧縮を有効化 パフォーマンス改善 追加のキャッシュポリシー Amplify Hosting は、世界中のエッジロケーションのネットワークを利用して、低レイテンシーでコンテンツを配信する Amazon CloudFront Global Edge Network を活用しています。 Amazon CloudFront は、エンドユーザーのリクエストが最も近いエッジロケーションから返されるようにします。その結果、Web リクエストが短い距離を移動するため、パフォーマンスが向上します。エッジロケーションにキャッシュされていないファイルの場合、Amazon CloudFront はオリジンサーバーからファイルを可能な限り速く取得できるロジックを維持しています。キャッシュポリシーによってキャッシュキーが決まり、キャッシュされたコンテンツがサービスされるかどうかが判断されます。一方、オリジンリクエストポリシーは、キャッシュミスの際にどの Cookie、クエリ文字列、ヘッダーをオリジンサーバーに転送するかを指定します。 特定の種類のコンテンツに最適な キャッシュ戦略と Time To Live (TTL) の延長により、キャッシュヒット率が高くなり、エンドユーザーにより早い応答時間を提供できるようになります。現在、Amplify Hosting は、静的コンテンツ、サーバーサイドレンダリングされたコンテンツ、画像の最適化コンテンツに対して、次のキャッシュ戦略を実装しています。 これらの変更が以前のバージョンとどのように比較されるかについては、 ドキュメントの詳細な表 を参照してください。 コンテンツ タイプ キャッシュ期間 キャッシュキーに含まれるもの 静的コンテンツ 最大 1 年 Authorization および Host ヘッダー Cookie – なし クエリ文字列 – なし SSR コンテンツおよびリバースプロキシ 最大 1 年 Accept 、 Authorization 、 CloudFront-Viewer-Country 、および Host ヘッダー Cookie – すべて クエリ文字列 – すべて 画像最適化コンテンツ 最大 1 年 Accept 、 Authorization 、および Host ヘッダー Cookie – なし クエリ文字列: すべて ( 詳細 ) キャッシュは、デプロイ後や、カスタムヘッダーまたは Basic 認証設定が更新されるたびに無効化されます。これらのキャッシュ戦略の詳細については、キャッシュに関するドキュメントを参照してください。 キャッシュキーから Cookie を削除 キャッシュキーから Cookie を削除することができるようになりました。キャッシュキーは、コンテンツデリバリーネットワーク（CDN）がキャッシュされたコンテンツを効率的に保存および取得するために使用する固有の識別子で、ユーザーがアプリケーションの正しいバージョンを迅速に受け取れるようにします。キャッシュキーからCookieを削除する機能は非常に重要です。なぜなら、Google Analytics などのサービスからのウェブリクエストに含まれる Cookie は、各 Cookie に固有のハッシュが含まれているため、キャッシング戦略を妨げる可能性があるからです。 例えば、URL リクエストが次のように構築される場合は以下のようになります。 www.amplify.com Cookie: ga-session-id=abcdef キャッシュキーから Cookie を削除することで、ユーザーごとの固有のハッシュが排除され、キャッシュヒット率が大幅に向上します。この最適化により、キャッシュヒット率が高まり、より多くのコンテンツをエッジロケーションから直接配信できるようになります。その結果、パフォーマンスが向上し、コンテンツの配信が高速化され、ユーザーの待ち時間が短縮されます。 既存のアプリと新しいアプリは、本日からこの改善を活用できます。既存のアプリでは、概要ペインから Hosting を選択し、次に Custom headers and cache → Cache key settings を選んでキャッシュキーに Cookie を保持するかどうかを有効または無効にしてください。新しいアプリの場合は、 Advanced settings でこの設定を構成できます。この構成は API からも利用できます。 ベンチマーキング これらのパフォーマンス改善を評価するために、静的および SSR ルートの両方を含む Next.js 14 hello world アプリをベンチマークしました。SSR ルートは通常キャッシュされないため、静的アセットに関連する改善点にフォーカスしました。実際のお客様の動作をシミュレートするため、Google Analytics からリクエストごとにユニークな Cookie を導入しました。これらの CDN の改善を有効にすると、応答時間の 95 % タイルと平均の両方で約 98 %の改善と、99.99 %のキャッシュヒット率の大幅な改善を確認しました。アプリの複雑さとフレームワークによってはさまざまですが、このベーシックな hello world アプリでは、特に静的アセットに対してこれらの CDN キャッシュの最適化を有効にすることで、大幅なパフォーマンス向上が得られる可能性があることを強く示しています。 実際の例として、Next.js の SSG を使用し、GitHub でオープンソース化されている Amplify フレームワークのドキュメントサイト https://docs.amplify.aws/ のパフォーマンスを分析しました。静的サイトでありながら、著しく低いレイテンシと 90 % を超えるキャッシュヒット率という劇的な改善がみられました。 追加機能 CloudFront ヘッダー Amplify Hosting は、CloudFront が提供する追加のヘッダーを転送するようになりました。ヘッダーの詳細なリストは CloudFront のドキュメント でご確認いただけます。これらのヘッダーを利用可能にすることで、以下のようなさまざまなユースケースが可能になります。 user-agent ヘッダーは、コンテンツの最適化やパーソナライズのために、エンドユーザーのデバイス情報を把握することをユーザーに許可します。 referer ヘッダーは、リクエストの発信元を示すため、ウェブサイトはトラフィックソースを追跡できます。 エンドユーザーの地理情報を取得するための cloudfront-viewer-* ヘッダー (例: cloudfront-viewer-city) これらのヘッダーの一部にアクセスするには、サーバー側からのアクセスが必要になる可能性があります。たとえば、Next.js Amplify アプリの User-Agent ヘッダーは、Next.js の headers() 関数を使用して取得できます。これにより、開発者はサーバー側でヘッダー情報を取得し、クライアントのデバイスやブラウザに基づいてカスタムロジックを実装することができます。以下のコードスニペットは、このヘッダーを取得する方法を示しています。 import { headers } from 'next/headers' export default function Page() { const headersList = headers() const userAgent = headersList.get('user-agent') return <div>User Agent: {userAgent}</div> } Next.js の国際化 (i18n) Next.js の国際化 (i18n) が現在ネイティブにサポートされています。accept-language ヘッダをオリジンサーバに転送することで、Next.js アプリケーションは、ブラウザリクエストから直接ユーザの言語設定を検出できます。この機能強化により、多言語サイトのユーザーエクスペリエンスが大幅に向上しました。 Brotli 圧縮の有効化 このリリースにより、 Brotli 圧縮 が Amplify Hosting アプリで有効化され、アプリケーションのパフォーマンスが大幅に向上します。Brotli 圧縮は、非常に効率的なアルゴリズムで、ファイルサイズを縮小し、データ転送用に優れた圧縮を提供します。これにより、Web ページの読み込み時間が短縮され、データ使用量が削減されます。この機能強化により、特にモバイルユーザーや低速回線の接続環境でユーザー体験が改善され、帯域幅コストも削減できます。高速な読み込みにより、検索エンジンに優先されるため、SEO 順位も向上します。さらに、最新のブラウザーが Brotli をサポートしているため、互換性が確保され、パフォーマンス改善が最大化されます。この機能は、すべてのアプリで自動的に有効になります。 結論 新しいアプリではこれらの変更がすぐに適用されます。既存のアプリでは、これらのキャッシングの改善を適用するために新しいビルドをトリガーする必要があります。 適用されるキャッシュの変更に関する情報は、アプリのビルドログに表示されます。これらの改善点の詳細は、 ドキュメントを参照 してください。 本記事は「 CDN Caching Improvements for Better App Performance with AWS Amplify Hosting 」を翻訳したものです。 著者について Zachary Goldberg Zach Goldberg is a Software Development Engineer at AWS Amplify Hosting. Zach builds features that make it easier for customers to host front-end web applications backed by the reliability and convenience of AWS. In his free time, Zach enjoys running, snowboarding, and baking bread. Jay Raval Jay Raval is a Solutions Architect on the AWS Amplify team. He ’ s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @ _Jay_Raval_ Matt Auerbach Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people ’ s lives easier. B night, however … well he does pretty much the same thing. You can find Matt on X @ mauerbac . He previously worked at Twitch, Optimizely & Twilio. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

クラスターから直接ロードバランサーをプロビジョニングすることは、サービスを公開するための Kubernetes ネイティブの方法でしたが、場合によってはアプリケーションのアーキテクチャと合わないプロビジョニングプロセスになることがあります。そのため、別のメカニズムが必要とされます。この投稿で説明するユースケースでは、新しいロードバランサーをプロビジョニングせず、既存の Application Load Balancer (ALB)/ Network Load Balancer (NLB) のトラフィックを直接 service にルーティングする機能を提供します。 TargetGroupBinding と呼ばれるこの機能は、 カスタムリソース (CR) で、既存の ALB TargetGroup または NLB TargetGroup を使用して pod を公開できます。AWS Load Balancer Controller は、ingress および service リソースのサポート機能としても内部的に TargetGroupBinding を使用しています。TargetGroupBinding を使用すると、ユーザーはロードバランサーの作成と削除を service と ingress のライフサイクルから切り離すことができます。その結果、ユーザーは AWS インフラストラクチャのロードバランサーをネイティブの Kubernetes リソースから抽象化し、分離することができます。 図1 – TargetGroupBindingを使ってロードバランサーからEKSワークロードに接続 TargetGroupBinding は、インスタンスまたは IP の ターゲットタイプ のターゲットグループをサポートしています。ターゲットタイプが明示的に指定されていない場合、mutating webhook が自動的にターゲットグループのターゲットタイプを検出して正しい値に設定します。 明示的にロードバランサーのインフラストラクチャをプロビジョニングおよび管理するユースケースでは、Kubernetes ingress との分離が必要です。そして、TargetGroupBinding を使用すると、それぞれの service へのトラフィックをルーティングするための完全にダイナミックなソリューションを実現できます。 TargetGroupBinding パターン この記事では、Kubernetes ネイティブリソースでロードバランサーのライフサイクルを管理することが理想的でない使用例とアーキテクチャパターンを探ります。そのような場合、Kubernetes ネイティブリソース外でロードバランサーインフラストラクチャを管理する必要があり、TargetGroupBinding を使用して構成を動的に保つことができます。ハンズオンガイドについては、 このコンテナ記事 を参照してください。この記事では、AWS Load Balancer Controller における TargetGroupBinding と ingress リソース共有について詳しく説明しています。 グローバルトラフィックの分散 Kubernetes ワークロードに対するグローバルロードバランシングソリューションを探しているユーザーは、 AWS Global Accelerator と統合したロードバランサーの管理方法を必要としています。AWS Global Accelerator は、グローバルユーザーに提供するアプリケーションの可用性とパフォーマンスを向上させるネットワークサービスです。 次に、ユーザーは AWS Global Accelerator とロードバランサーを Kubernetes リソースプロビジョニングサイクルの外で作成および管理する必要があり、Kubernetes ワークロードにトラフィックをルーティングする方法が必要です。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用すると、外部で管理される AWS Global Acceleratorとロードバランサーを Kubernetes service に連携させることができます。ユーザーは、選択した Infrastructure-as-Code (IaC) ツールで AWS Global Accelerator、ロードバランサー、 Amazon Elastic Kubernetes Service (Amazon EKS) インフラストラクチャをプロビジョニングし、TargetGroupBinding を使用してロードバランサーのターゲットグループを Amazon EKS に動的に関連付けることができます。 図 2 – AWS Global Accelerator と TargetGroupBinding を使用した Load Balancer を経由して EKS ワークロードへ Amazon EKS と AWS Global Accelerator を使用してマルチリージョンのグローバルアプリケーションを運用する詳細については、 こちらの投稿 を参照してください。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用できます。 L4 および L7 リクエストの単一エンドポイント ユーザーは、この ネットワーキングとコンテンツ配信の投稿 で説明されているように、ALB の前に NLB を設定する必要がさまざまな理由で生じる場合があります。このような設定では、アプリケーションが L4 と L7 の両方で単一のエンドポイントを共有する必要がある場合や、アプリケーションの静的 IP アドレスを公開する場合や、ALB 用のエンドポイントを提供する必要がある場合があります。つまり、Kubernetes service の管理ライフサイクル (NLB から ALB へのルーティングの構成など) に関係なく、NLB と ALB の両方がプロビジョニングされ、構成されていることを確認する必要があります。この場合、TargetGroupBinding は、静的または事前定義された負荷分散構成を持つための機能を提供し、pod をターゲットとして動的に登録できるようになります。 図 3 – TargetGroupBinding を使用した EKS ワークロードへのレイヤー 7 とレイヤー 4 のトラフィックルーティング クラスターの blue/green アップグレード 多くの場合、ローリングアップデートを使用して EKS クラスターを直接アップグレードできます。ただし、ダウンタイムを減らし、前の状態に素早くロールバックできるようにするために、ユーザーは blue/green のアップグレードを好む場合があります。ユーザーは、新しい EKS クラスターを作成し、新旧クラスターで同一のロードバランサーを利用することで、blue/green のアップグレード戦略を実現できます。ユーザーは、各 EKS クラスター用に 1 つずつターゲットグループを作成したロードバランサーを使用できます。次に、TargetGroupBinding CRD を使用すると、Amazon EKS を作成されたターゲットグループに動的に関連付けることができます。ロードバランサーの ルール 内で、各ターゲットグループに送信するリクエストの重みを設定して、クラスター間のリクエストの移行を制御します。このソリューションの利点は、ユーザーがドメインネームサーバー (DNS)、存続可能時間 (TTL)、またはクライアントマシン上のキャッシュに依存しないことです。 図 4 – TargetGroupBinding を用いた EKS ワークロードへの blue/green トラフィックルーティング ハイブリッドデプロイ blue/green デプロイメントの場合と同様に、Amazon EKS ベースのアプリケーションと Amazon EKS ベースでないアプリケーション ( Amazon Elastic Compute Cloud (Amazon EC2 ) ベースのアプリケーションや AWS 外のアプリケーション) を並行して実行する必要がある場合、このパターンが役立ちます。TargetGroupBinding を使用すると、同じロードバランサーを使って並列の EKS クラスターにユーザートラフィックをルーティングできます。このパターンでは、TargetGroupBinding ユーザーは新しいターゲットグループを追加することで、同一のロードバランサーを使って新しい Amazon EKS ワークロードにトラフィックをルーティングできます。CR は、作成されたターゲットグループに service を動的にバインドする処理を行います。 図 5 – TargetGroupBinding を使用したハイブリッド (EKS と非 EKS) ワークロードへのトラフィックルーティング この同じ戦略は、コンテナ化されていない環境、オンプレミス環境、または他のコンテナプラットフォームから Amazon EKS へのワークロードトラフィックの移行を計画する際にも適用できます。 まとめ この投稿では、ALB と Kubernetes service のライフサイクルを分離することが最適な一般的なユースケースについて説明しました。これにより、AWS Load Balancer Controller で TargetGroupBinding 機能を使用するタイミングを選択できます。アプリケーションに最適なアーキテクチャを設計することをお勧めします。Kubernetes service/ingress 構成のライフサイクルに合わせて「無理に」設計する必要はありません。ただし、アプリケーションのルーティング構成を実装する場合は、すべての構成にメリットとデメリットがあることに注意してください。TargetGroupBinding を使用すると、Kubernetes 外で作成される ALB/NLB に Kubernetes service をバインドする明示的な手段の恩恵を受けられる一方で、Kubernetes インストールに付属していないカスタム CRD 実装 (ローカル開発クラスターなど) を使用する必要があります。ALB と TargetGroupBinding のすべての潜在的な構成の詳細については、 ドキュメント を参照してください。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

はじめに 自動車業界がコネクティッドカーと自動運転の未来を目指して急ピッチで進む中、サイバーセキュリティは重要な課題となっています。車両がソフトウェア、センサー、接続性に依存するようになるにつれ、サイバー攻撃の標的にもなりかねません。この課題を認識して、国際連合欧州経済委員会 (UNECE) は、自動車に関する法的調和のための世界フォーラム (WP.29) を導入し、コネクティッドカーのサイバーセキュリティとソフトウェアアップデートに関する画期的な規制を策定しました。 UNECE WP.29 の概要 国際連合欧州経済委員会 (UNECE) の車両規則統一世界フォーラム ( WP.29 ) は、国家間の車両規制の統一化を目指すグローバルなフォーラムです。自動車業界向けにサイバーセキュリティの規制とガイドラインである UNECE WP.29 を策定しています。 これらの規制は、以下のようなネットワーク接続された車両のサイバーセキュリティの様々な側面をカバーしています。 リスク管理 安全なソフトウェアアップデート セキュアな通信 インシデント対応 テストとアセスメント 具体的には、サイバーセキュリティに関する UN 規則第 155 号と、ソフトウェアアップデートに関する UN 規則第 156 号は、自動車業界の姿を変えるものとなるでしょう。 これらの規則により、メーカーには、車両のライフサイクル全体を通してサイバーセキュリティ管理システム (CSMS) とソフトウェアアップデート管理システム (SUMS) を確実に実装することが義務付けられます。 この変化に対応するには、堅牢で拡張性とセキュリティを備えた IoT インフラストラクチャが必要不可欠です。この要求に Amazon Web Services (AWS) IoT がうまく対応できるよう整備されています。 なぜ重要なのか: 自動車のサイバーセキュリティ に関する UNECE 規則第 155 号により、2024 年 7 月以降、EU 加盟国、英国、日本、韓国を含む 54 カ国の OEM によって生産するすべての車両は、WP.29 国連車両規則調和世界フォーラムが定めた厳しいサイバーセキュリティ要件を満たす必要があります。この規制は、コネクティッドカーのサイバーセキュリティを確保し、運用の混乱、データ漏えい、安全リスクなど、深刻な結果を招くサイバー脅威から守ることを目的としています。 AWS IoT の概要 AWS IoT は、自動車メーカーが UNECE WP.29 の要件を満たし、それを超えることを支援する一連のサービスを提供します。 これらの機能は、WP.29 の安全な通信チャネルおよび「セキュリティ・バイ・デザイン」の原則に重点を置いたものです。 デバイス接続とメッセージング: AWS IoT Core は MQTTなどのプロトコルをサポートし、x.509証明書による安全なデバイス認証を実現します。 デバイス管理: AWS IoT Device Management は、オンボーディング、組織化、監視、リモート管理、および OTA 更新を提供し、UN 規則第 156 号に従ったソフトウェアセキュリティの維持に不可欠です。 セキュリティ監視: AWS IoT Device Defender は、車両の異常な挙動を監視し、逸脱があった場合に警告を発し、 UN 規則第 155 号で義務付けられているリスク評価とインシデント対応をサポートします。 データ処理と分析: Amazon Kinesis Data Analytics ストリームは、車両の挙動とユーザーパターンを理解するのを支援し、車両全体のセキュリティ脅威と脆弱性を特定するのに役立ちます。 アーキテクチャの概要 このアーキテクチャでは、 AWS IoT Core を使用してコネクティッドカーへの接続と認証を行います。 AWS IoT Device Management の一部である AWS IoT Jobs により、スケジューリング、リトライやステータスレポートなどを含む、ソフトウェアアップデートの展開やリモート操作を管理できます。 AWS IoT Device Defender は車両の異常を監査および監視し、 AWS IoT Rules によりデータを Amazon Kinesis Data Streams に送信し、リアルタイム分析を行います。 図 1.0 : AWS サービスを使用して WP.29 準拠するコネクティッドカー 前提条件 AWS IoT ワークショップ の開始に従って AWS 開発環境のセットアップ を実施するか、あるいは独自の EC2 開発環境をセットアップして、手順をすすめることができます。 バージョン管理が有効になっている Amazon Simple Storage Service (Amazon S3) のアーティファクトバケットに、テストアプリケーションを格納します。 AWS IoT Core の モノ としてのへコネクティッドカー。この記事では、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上に AWS IoT Device Client ソフトウェアをインストールすることで、仮想のコネクティッドカーをシミュレートします。 AWS IoT ワークショップの開始 では、シュミレートした仮想 IoT デバイスの設定について詳しい手順が示されています。 手順 この手順では、シミュレートされたコネクティッドカーをセットアップし、OTA を実行し、車両の動作を積極的に監視し、車両のデータに分析を適用します。 AWS IoT やその他の AWS サービスを利用して、WP.29 要件を満たす機能を実演します。 前提条件を満たしていれば、AWS Cloud9 の環境が用意できています。これを使用して、仮想のコネクティッドカーをセットアップし、AWS IoT に接続します。 AWS IoT コネクティッドカーの作成 (AWS コンソール) ステップ 1: シミュレートされたコネクティッドカーを作成 (AWS IoT Thing) AWS IoT Core コンソール を開きます ナビゲーションペインの 管理 の下にある すべてのデバイス を選択します モノ を選択します モノを作成 を選択し、 1 つのモノを作成 を選択します モノの名前に SimulatedConnectedVehicle を入力します 図 1.1 : AWS IoT Thing の作成 デバイス証明書については、推奨オプションを使用します。（図 1.2 参照） 図 1.2: デバイス証明書の選択 ステップ 2: ポリシーを作成して AWS IoT のモノに割り当て ポリシーをアタッチのセクションで、 ポリシーを作成 を選択します ポリシー名に wp29TestPolicy を入力し、 JSON を選択します 以下の JSON コンテンツに置き換えます region、your-account-id を適宜更新します 作成 を選択し、ポリシー作成を完了します { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Subscribe", "iot:Receive", "iot:Publish" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:client/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:topic/*", "arn:aws:iot:eu-west-1:your-account-id:topicfilter/*" ] }, { "Effect": "Allow", "Action": [ "iot:DescribeJob", "iot:CreateJob", "iot:UpdateJob", "iot:DeleteJob", "iot:CancelJob", "iot:StartNextPendingJobExecution", "iot:DescribeJobExecution", "iot:UpdateJobExecution", "iot:DeleteJobExecution" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:job/*", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:jobexecution/*" ] } ] } JSON ステップ 3: コネクティッドカーのモノへポリシーを割り当て 前のステップでポリシーの作成が完了したら、このポリシーをモノに割り当て、モノを作成します。 (図 1.3 参照) 図 1.3 :ポリシーをモノに割り当て ステップ 4: デバイス証明書と鍵をダウンロード ダウンロードプロンプトからダウンロードします。 (図 1.4 参照) デバイス証明書 パブリックキーファイル プライベートキーファイル Amazon ルート CA 図 1.4 :証明書とキーをダウンロード これらの認証情報は、 SimulatedConnectedVehicle を AWS IoT に接続し、AWS 開発環境 (上で作成) にアップロードするために使用するので、安全に保存します。 ステップ 5: AWS IoT Device Client をインストール AWS IoT デバイスクライアントワークショップのセクションに従い、 ここに記載されている 手順に従ってデバイスクライアントをインストールします。 このブログの前のステップで作成した認証情報を使用し、 Specify thing name (Also used as Client ID) が出力されたら、前に作成した SimulatedConnectedVehicle というモノの名前を使用します。 Over-the-air(OTA) アップデートのリモート操作 デバイスが相互に接続された現代の世界では、ファームウェアを最新の状態に保つことがセキュリティ、パフォーマンス、機能面で極めて重要です。 Over-the-Air (OTA) アップデートは、デバイスを遠隔でアップデートするシームレスな方法を提供し、物理的なアクセスを必要とせずに、常に最新のソフトウェアを常に実行できるようにします。 AWS IoT Device Management Jobs を使用して、コネクティッドカーのファームウェアを更新する OTA アップデートを行う方法を見ていきましょう。 このワークショップ で説明されている手順を実行し、Jobs が AWS 管理のテンプレートを提供していることにより、AWS IoT Core に接続されたデバイスへのリモート操作がとても簡単で効率的かを見てみましょう。 ここ に記載されている手順にしたがって、独自カスタム Jobs の手順とウォークスルーを作成することもできます。 積極的なセキュリティ監視 ： コネクテッドカーの安全性とコンプライアンスを確保 AWS IoT Device Defender を使用すると、継続的なセキュリティ監視を確立でき、全体的なセキュリティを強化できます。 このサービスは、送受信するメッセージの増加 (「おしゃべり」なデバイスであることを示す) 、車両からの頻繁な接続試行、または急速かつ頻繁な切断などの異常を検出することができます。これらの異常がトリガーを促し、潜在的な安全保障上の脅威に対する積極的な対応を可能にします。このアプローチは、継続的なリスク評価をサポートするだけでなく、UN 規則第 155 号の厳格な基準にも沿っています。 このワークショップ で説明されている手順に従って、AWS IoT Device Defender を使用して積極的なセキュリティ監視と監査を実現する方法を確認します。 ストリーミングデータ分析: Amazon Kinesis Data Analytics (Apache Flink) の使用 Amazon Kinesis Data Analytics の ストリームを使ったデータ分析は、車両の動作とユーザーの行動パターンを理解する上で非常に重要です。 このデータを分析することで、車両全体の新たな傾向とパターンを特定することができ、より多くの情報に基づいた意思決定と全体的なパフォーマンス向上が可能になります。 Amazon Kinesis Data AnalyticsにデータをファンアウトするためにAWS IoT Rulesをセットアップしましょう ステップ 1: AWS IoT デバイスクライアントの設定を変更 AWS IoT デバイス クライアント設定を変更して、 publish-on-change を含めるようにします。この機能は、指定されたパブリッシュファイル ( /home/ubuntu/workshop_dc/pubfile.txt ) にデータを書き込むたびにパブリッシュアクションがトリガーされます。 AWS IoT デバイスクライアントはこの変更を検知し、 /topic/workshop/dc/pub トピックとして AWS IoT Core に送信します。 次のコマンドを実行して、設定ファイルを編集します: sudo vim /etc/.aws-iot-device-client/aws-iot-device-client.conf 以下を追加します: “publish-on-change”: true サンプルセクションの設定は、” Publish-on-change ” を追加すると次のようになります: 図 1.5: AWS IoT デバイスクライアントの設定変更 ステップ 2: AWS IoT デバイスクライアントを再起動 前のステップで publish-on-change を追加して設定を変更したら、AWS IoT デバイスクライアントを再起動します。 次のコマンドを実行して再起動します: sudo systemctl restart aws-iot-device-client Bash ステップ 3: 車両データのシミュレーション コネクテッドカーのシミュレーションデータジェネレーターを設定し、AWS IoT Core にストリーミングします。ファイル ( vehicle_data_generator.py ) を作成し、これを実行すると、車両の状態、DTC (故障診断コード)、位置情報、ドライバーの行動、バッテリー状態を含むランダムデータが常にストリーミングされます。 ファイルを設定するために次のコマンドを実行し、コードをダウンロードします: cd /home/ubuntu/workshop_dc vim vehicle_data_generator.py Bash ファイル ( vehicle_data_generator.py ) に次のコードを入力します: import json import time import random import logging from datetime import datetime , timezone from pathlib import Path # Set up logging logging . basicConfig ( level = logging . INFO , format = '%(asctime)s - %(levelname)s - %(message)s' ) logger = logging . getLogger ( __name__ ) # File path FILE_PATH = Path ( "/home/ubuntu/workshop_dc/pubfile.txt" ) def generate_vehicle_status ( ) : return { "vehicleId" : "VIN123456789" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "status" : { "ignition" : random . choice ( [ "ON" , "OFF" ] ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) , "fuelLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "batteryLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "odometer" : round ( random . uniform ( 0 , 100000 ) , 1 ) , "engineTemp" : round ( random . uniform ( 70 , 110 ) , 1 ) , "tirePressure" : { "frontLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "frontRight" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearRight" : round ( random . uniform ( 30 , 35 ) , 1 ) } } } def generate_dtcs ( ) : return { "vehicleId" : "VIN987654321" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "dtcs" : [ { "code" : "P0" + str ( random . randint ( 100 , 999 ) ) , "description" : "Random DTC Description" , "severity" : random . choice ( [ "WARNING" , "CRITICAL" , "INFO" ] ) } ] } def generate_location ( ) : return { "vehicleId" : "VIN246813579" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "location" : { "latitude" : round ( random . uniform ( 30 , 45 ) , 4 ) , "longitude" : round ( random . uniform ( - 125 , - 70 ) , 4 ) , "altitude" : round ( random . uniform ( 0 , 1000 ) , 1 ) , "heading" : round ( random . uniform ( 0 , 359 ) , 1 ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) } } def generate_driver_behavior ( ) : return { "vehicleId" : "VIN135792468" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "driverBehavior" : { "harshAccelerations" : random . randint ( 0 , 5 ) , "harshBraking" : random . randint ( 0 , 5 ) , "speedingEvents" : random . randint ( 0 , 10 ) , "averageSpeed" : round ( random . uniform ( 40 , 80 ) , 1 ) , "idlingTime" : random . randint ( 0 , 600 ) , "fuelEfficiency" : round ( random . uniform ( 20 , 40 ) , 1 ) } } def generate_battery_status ( ) : return { "vehicleId" : "VIN753951456" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "batteryStatus" : { "stateOfCharge" : round ( random . uniform ( 0 , 100 ) , 1 ) , "range" : round ( random . uniform ( 0 , 300 ) , 1 ) , "chargingStatus" : random . choice ( [ "CHARGING" , "NOT_CHARGING" ] ) , "voltage" : round ( random . uniform ( 350 , 400 ) , 1 ) , "current" : round ( random . uniform ( - 200 , 200 ) , 1 ) , "temperature" : round ( random . uniform ( 20 , 40 ) , 1 ) , "healthStatus" : random . choice ( [ "GOOD" , "FAIR" , "POOR" ] ) } } def write_to_file ( data ) : try : # Ensure the directory exists FILE_PATH . parent . mkdir ( parents = True , exist_ok = True ) # Write the data to the file with FILE_PATH . open ( 'w' ) as f : json . dump ( data , f ) logger . info ( f"Successfully wrote data to { FILE_PATH } " ) except PermissionError : logger . error ( f"Permission denied when trying to write to { FILE_PATH } " ) except IOError as e : logger . error ( f"I/O error occurred when writing to { FILE_PATH } : { e } " ) except Exception as e : logger . error ( f"Unexpected error occurred when writing to { FILE_PATH } : { e } " ) def main ( ) : generators = [ generate_vehicle_status , generate_dtcs , generate_location , generate_driver_behavior , generate_battery_status ] while True : try : data = random . choice ( generators ) ( ) write_to_file ( data ) time . sleep ( 10 ) except KeyboardInterrupt : logger . info ( "Script terminated by user" ) break except Exception as e : logger . error ( f"An unexpected error occurred: { e } " ) time . sleep ( 10 ) # Wait before retrying if __name__ == "__main__" : try : main ( ) except Exception as e : logger . critical ( f"Critical error occurred: { e } " ) Python コード (またはファイル) をコピーしたら、次のコマンドでコードを実行します。 python3 vehicle_data_generator.py 実行に成功すると、以下のように表示されます: INFO – Successfully wrote data to /home/ubuntu/workshop_dc/pubfile.txt AWS IoT Core コンソールで以下に移動します: テスト MQTT テストクライアント トピックをサブスクライブする: /topic/workshop/dc/pub 到着しているデータのストリームが確認できるはずです; このデータは分析に使用するものと同じです。 図 1.6: AWS IoT Core に到着するデータを示す MQTT トピック ステップ 4: AWS IoT Rule を作成 AWS IoT Core にデータが到着することが分かれば、BI 目的で AWS 分析サービスにデータをルーティングするための AWS IoT Rules をセットアップできます。 AWS IoT Core コンソール に移動します ナビゲーションペインの 管理 の下にある メッセージのルーティング を選択します ルール を選択します ルールを作成 を選択します 適切なルール名とルールの説明を入力し、「次へ」を選択します 。(図 1.7 参照) 図 1.7: AWS IoT Rule を作成 SQL ステートメントを設定 セクションで、以下の SQL ステートメントを入力し、 次へ を選択します: SELECT * FROM '/topic/workshop/dc/pub' ルールアクションをアタッチ セクションで、Kinesis Data Stream を選択し、以下を作成します: アクション 1 名前を指定してストリームを作成: simulatedVehicleData パーティションキー: ${newuuid()} IAMロールの選択と作成: simulatedVehicleRole エラーアクション AWS IoTトピックへのリパブリッシュを選択: /topic/workshop/dc/streamError IAM ロールを選択: simulatedVehicleRole 完了したら進んで 作成 を選択します。 図 1.8: AWS IoT Rules アクション ステップ 5: Apache Flink と Apache Zeppelin を使って Amazon Kinesis Data Streams のストリーミングデータを確認 この段階では、Amazon Kinesis Data Streams ( simulatedVehicleData ) にデータがストリーミングされます。 コンソールで Amazon Kinesis Data Streams に移動し、ストリームを選択します。 (図 1.9 参照) 図 1.9: シミュレーションされた車両データのストリーム データ分析タブを選択し、 I agree を選択した後、 Create notebook を選択します。 (図 2.0 参照) 図 2.0: Apache Flink Studio ノートブックの作成 Studio ノートブックが作成されたら、ストリーミングデータを選択して表示できるはずです。 (図 2.1 参照) 図 2.1: ストリーミングデータビュー これで、ストリーミングデータの可視化を作成できるはずです。 クリーンアップ 不要な請求を避けるために、メインの CloudFormation テンプレート (ネストされたスタックではない)、Amazon EC2 インスタンス (開発用に作成した場合)、Amazon S3 バケット (このブログ用に新しく作成した場合)、IoT のモノと関連するポリシー、Kinesis Data Stream (AWS 管理の Apache Flink と Apache Zeppelin を含む) を削除します。 まとめ UNECE WP.29 規制は、コネクティッドカーのサイバーセキュリティを確保する上で重要なステップを示しています。この規制は、自動車業界に対し、車両の設計、製造、運用のあらゆる側面にセキュリティを組み込むよう要求しています。AWS IoT サービスは、これらの課題に対処するための包括的でスケーラブル、かつセキュアな基盤を提供します。 コネクティッドかつ自動運転の未来には、UNECE WP.29 などの厳格な規制を革新的なテクノロジーとシームレスに統合することを要求します。 AWS IoT では、この連携を効果的に実現するサービスを提供しています。 この統合は単なる規制への準拠を超えたものです; 消費者の信頼を気づき、相互接続が進む世界における安全性を確保するものです。 サイバーセキュリティの懸念に積極的に取り組むことで、個々の車両の安全性を確保するだけでなく、将来のモビリティ基盤そのものを守ることができるのです。 関連するリンク Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system AWS IoT Zero Trust workshop 著者について Syed Rehan Sysed Rehan は、Amazon Web Services(AWS)のIoTセキュリティ組織内で活動するシニアサイバーセキュリティ製品マネージャーです。AWS IoT 、機械学習、サイバーセキュリティに関する書籍の著者として、グローバルな役割に幅広い専門知識をもたらしています。サイードは、セキュリティ専門家、CISO、開発者、セキュリティ意思決定者と協力し、AWS セキュリティサービスとソリューションの採用を促進するために、多様な顧客層を抱えています。サイバーセキュリティ、機械学習、人工知能、IoT 、クラウド技術に関する深い知識を持ち、新興企業から大企業まで幅広い顧客を支援しています。AWS 環境内で安全な IoT 、ML 、AI ベースのソリューションを構築できるようにしています。 この記事は Sysed Rehan によって書かれた Securing the future of mobility: UNECE WP.29 and AWS IoT for connected vehicle cybersecurity の日本語訳です。この記事は 広域事業統括本部 ソリューションアーキテクト 久次米が翻訳しました。

デジタルカスタマーエンゲージメントを実現し、ユーザーを満足させ、新たな収益源を生み出すような、スマートでコネクテッド製品・装置を開発することは大変な挑戦です。これには、セキュアなアプリケーションを構築し、機器のデータを取り込み、必要に応じてスケールアップやダウンができる必要があります。また、製品や装置の使用状況や動作状態を可視化する必要があります。機械学習、アナリティクス、IoT (Internet of Things) などの先進技術を活用し、クラウド上にデータを取り込み、分析し、管理することで、これらの課題に対応できます。 製造業がデジタル化の新時代に入る中、テクノロジーの進化に先駆けて対応することが重要です。この進化の最前線にあるのが、アメリカ最大規模の製造テクノロジーの展示会「 IMTS (International Manufacturing Technology Show) 」です。2024年9月9日から14日まで、シカゴで開催される今年の IMTS は、装置メーカーや製造業の企業が生産性と収益性を向上させるための革新的なテクノロジーに触れられる展示会となることをお約束します。 この展示会に Amazon Web Services(AWS)も出展し、最新の産業データフレームワークがいかにスマートで高品質な製品につながるかをご紹介します。 North Building, Level 3 – Booth 236217 にご来訪ください。 IMTS 2024でAWSブースにご来訪いただく理由 AWS の IMTS 2024 での出展の中心は、革新性とテクノロジーを実演するインタラクティブなデモブースです。来場者は、e-bike のスマート工場デモ( こちら でプレビューをご覧になれます)、AWS サービスやソリューションを紹介するインタラクティブなキオスク、パートナーのキオスク、IoT デバイスウォール、 ブース内の講演会場など を体験できます。製品やマシンのデータを、生成 AI、機械学習、コンピュータービジョン、IoT などの技術と組み合わせて活用し、製品設計プロセスの改善、スマートな製品の創造、スマート製造の推進方法を学んでいただけます。 あらゆるデジタルトランスフォーメーションの取り組みにおいて、一つの重要なテーマが浮かび上がります。堅牢で現代的なデータ戦略の必要性です。AWS の産業データファブリックソリューションは、スケーラブルで、一元化され、統合された仕組みでデータを活用できるデータ管理アーキテクチャを実現します。高品質なデータセットに対し、経済的で、安全、簡単なアクセスを提供することで、ビジネスリーダーがデジタル産業トランスフォーメーションの基盤を構築し、保全、資材管理、プロセス最適化、スマート製品の導入などの幅広いユースケースで業務を最適化することを可能にします。 カンファレンスセッション AWS の IMTS 2024 での活動の目玉の1つが、IMTS カンファレンスの木曜日午前9時の「生成 AI が製造業のスキルギャップ解消に貢献する方法 (“ How Generative AI Can Help Close the Manufacturing Skills Gap ”) 」セッションです。このセッションでは、生成 AI がどのように製造業の深刻なスキルギャップに対処できるかを探ります。ブースではその他の生成 AI のユースケースも紹介しますので、ぜひお立ち寄りください。 また、AWS は北ホールのオートメーションステージでも2つのセッションを行います。水曜日午後2時に、AWS と Siemens が共同で「エッジからクラウドへの統合によるスマート製造の再構築:持続可能で知的な工場への Siemens の取り組み (“Reimagining Manufacturing with Edge-to-Cloud Integration: Siemens’ Journey to Sustainable, Intelligent Factories”) 」を発表します。同日午後2時には、AWS のお客様である INVISTA が「生成 AI のパワーでマシンオペレーターの体験を向上 (“Elevated machine operator experience with the power of generative AI.”)」と題して発表します。 パートナーエコシステム AWS は、イノベーションを推進する上でのコラボレーションの重要性を認識しており、AWS のパートナーは製造業界への先端ソリューションを提供する上で不可欠な役割を果たしています。IMTS 2024 では、AWS のブースやステージセッションでパートナーソリューションを紹介し、これらのコラボレーションがいかに迅速な成果を生み出し、製造業の未来を形作るかについて洞察を得ることができます。 イノベーションを直接体験下さい 製造業がデジタルトランスフォーメーションを受け入れる中、AWS は、製造業のお客様が最新の動向をリードできるようなソリューションとサービスを提供し続けています。生成 AI、機械学習、クラウドコンピューティングの力によって、装置メーカーや製造業の企業は、これまでにないレベルの効率性、品質、イノベーションを実現できるようになります。 IMTS 2024 は、製造業のお客様が AWS の変革力を直接体験する絶好の機会です。AWS のブースを訪れ、講演セッションに参加し、幅広いサービスやパートナーの提案を探求することで、AWS がいかにイノベーションを推進し、製造業の未来を形作っているかについての貴重な洞察が得られます。 e-bike のデモを実際に体験したり、 AWS for Industrial について詳しく学んだりするため、IMTS 会場の AWS ブース( North Building, Level 3 – 236217 – Automation ) にぜひお立ち寄りください。そして、あなたの事業とプロセスのデジタルトランスフォーメーションを始めましょう。 本ブログは、 Experience manufacturing innovation with AWS at IMTS 2024 を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。 Tiffany Pfremmer Tiffany は、Amazon Web Services のシニアマーケティングマネージャーで、製造業およびインダストリー分野を担当しています。Rockwell Automation で15年以上の経験を持ち、マーケティング、品質、サービスの様々な役割を経験しています。Tiffany は、製造業者のバリューチェーンのあらゆる側面にわたって、マーケティングとカスタマーフォーカスのソリューション提供に注力してきました。

はじめに サプライチェーンの俊敏性は、組織が競争力を維持するために不可欠です。消費者の需要、新しい技術、経済の状況によって、需要と供給のバランスが崩れる可能性があります。需要計画、つまり顧客需要を満たすために必要な製品、原材料、部品の数量を正確に見積もることは、サプライチェーンの主要な課題の 1 つです。効果的な需要計画を立てることで、組織が在庫切れを回避し、過剰在庫を最小限に抑え、リソースの活用を最適化するのに役立ちます。この課題は幅広い業界に影響します。医療分野では、クリニック、病院、医療流通網全体にわたる分断されたデータと制限された可視性により、消費量と在庫レベルを正確に把握することが問題となっています。これにより、倉庫スペースへの過剰な投資や、在庫管理の不備による回収対象商品や期限切れ製品を使用してしまうなどのコストがかかる可能性があります。小売業界でも、動的な消費者行動と需要のシフトに対する準備不足もあり、実際の顧客需要の規格化されたエンドツーエンドの可視性を実現し、適切な製品在庫を適切な場所に配置することが困難です。製造業や自動車産業では、さまざまなパートナーが運営する多様ななシステムにまたがった部品・完成品のグローバルサプライチェーンネットワークにより、時間の遅れ、データの断片化、データ形式の不一致が生じます。これにより、正確な在庫の見通しが曖昧になり、最適な在庫レベルと配置を決定することが非常に困難になります。その影響は深刻で、出荷の遅れ、部品不足、輸送の混乱が損失を発生させ、混乱を引き起こす可能性があります。 ある医療技術企業は、供給計画で使用されていた不正確な契約ベンダーのリードタイムデータが在庫水準、供給計画の精度、および顧客注文の充足率に悪影響を及ぼすという事業上の課題に直面していました。ベンダーのリードタイム検出を改善するための社内イニシアチブが進行中でしたが、これらの手作業の取り組みには多大な時間と投資が必要で検証されていませんでした。AI 活用のビジネス戦略に沿って、同社は AWS Supply Chain の Vendor Lead Time Insights を導入しました。これにより、機械学習 (ML) モデルを活用して、運用に影響を与えるベンダーのリードタイム問題を特定する検証済みで実証された迅速なソリューションが提供されました。 この企業は、サプライチェーン運営の可視性を向上させるために、AWS Supply Chain の Vendor Lead Time Insights を選択しました。明確な ML ベースの洞察により、最も問題のあるベンダーが明らかにされ、供給計画の改善に向けた集中的な対策が可能になりました。調達した製品の平均で、契約上の予定リードタイムを大幅に超過し、予定よりも遅れて納品されていることが判明しました。この貴重な洞察により、企業は契約リードタイムを大幅に超過したケースの大部分を占めるベンダーを特定することができました。このデータ主導のインテリジェンスを活用し、この企業は計画システムのマスターデータの更新や、より大きな影響力をもってベンダーと交渉するなど、対象を絞った対策を講じることができます。 この企業は、供給計画プロセスのための正確で最新の情報を維持するため、最新の取引データを四半期ごとに追加して、Vendor Lead Time Insights を継続的に更新します。さらに、同社は自社内のリードタイムにも同様の可視性を提供するために AWS Supply Chain の拡張を検討しており、これによりサプライチェーンの回復力がさらに強化されます。 このブログ記事では、AWS Supply Chain の Vendor Lead Time Insights がベンダーのリードタイムの可視性を向上させ、供給計画の精度を高め、サプライチェーン運用を合理化する方法について説明しています。また、Vendor Lead Time Insights の概要を簡単に紹介し、この機能が在庫管理の最適化と顧客満足度の向上につながる役割を果たすことを明らかにしています。 Vendor Lead Time Insights を活用した供給計画の改善 AWS Supply Chain は、サプライチェーン全体でのリードタイム変動を検出することで、計画の精度を向上させるクラウドベースのアプリケーションです。これにより企業は顧客満足度を損なうことなく、より良いコスト管理戦略を実施できるようになります。AWS Supply Chain の Vendor Lead Time Insights は、過去の受注データ、出荷、在庫移動、季節性パターンなどの関連要因を分析することで、実際のベンダーリードタイムに関する洞察をデータに基づいて作り出します。ML モデルはこのデータから継続的に学習し、予想リードタイムからの逸脱を検出し、特定のサイト、製品、輸送方法に合わせて契約書面上の大まかな見積りに頼らず、データに基づく最新の予測を提供します。 従来、プランナーは供給業者からの平均リードタイムと需要予測を使用して、必要在庫レベルを決定してきました。しかし、この方法では、輸送の遅延、港湾の混雑、または供給業者の活動停止による実際の変動を考慮できません。これを補うため、プランナーは多くの場合、任意の安全在庫バッファを追加しますが、これは企業に過剰在庫を抱えさせることになり、非効率的で費用がかかるアプローチとなっています。平均値に依存すると、リードタイムが予想より長くても短くても、正確な計画を立てることができません。ベンダーリードタイムインサイトの ML 対応機能により、企業の担当者は詳細な洞察を得て、的確な意思決定を行い、計画プロセスを改善できるようになります。例えば、過去のデータから特定の配送センターへの出荷で、ベンダーが常に見積もりより 5 日遅れて納品していることがわかれば、ML モデルはリードタイム見積もりを適宜調整することを推奨します。組織は、製品 – サイト – ロケーションの組み合わせすべてについて、ワンクリックでベンダーリードタイム推奨値を生成およびエクスポートできるため、データに基づいたサプライチェーン計画と実行が可能になります。 以前の ブログ をご覧いただき、AWS Supply Chain インスタンスの作成前提条件と初期設定手順についてご確認ください。また、モジュールの詳細な設定情報については、Insights の ユーザガイド を参照してください。次のスクリーンショットは、Lead Time Insights のダッシュボードを示しており、ベンダーの輸送方法や発注元の位置など、重要な要因に着目して、製品のリードタイム逸脱をお知らせします。このアプリケーションでは、特定の洞察ウォッチリストで設定されたすべての製品 – サイト – ベンダーのリードタイム推奨事項を可視化し、エクスポート可能なファイルも提供されます。ダッシュボード上の任意の行を選択すると、詳細情報を確認できます。 行をダブルクリックすると、部品やサプライヤーの購買発注納品実績の詳細が表示される画面に移動します。また、アプリケーションには、製品、サイト、ベンダーに合わせて、過去の実績に基づいて ML で生成されたリードタイム推奨値が提供されます。 AWS Supply Chain の Lead Time Insights を使用すると、より正確にリードタイムの変動を検出できるようになります。&nbsp; まとめ 今日の絶え間なく進化するビジネス環境において、効果的なサプライチェーン管理は重要な差別化要因となっています。企業は、急速に変化する消費者の需要、技術の進歩、経済の変動、そして激しい競争に適応しなければなりません。平均リードタイムに依存する従来の供給計画手法では、これらの動的な課題に対処することが困難です。しかし、機械学習 (ML) を供給計画プロセスに統合することで、運用効率を向上させる AWS Supply Chain の Vendor Lead Time Insights の恩恵を受けることで企業はデータ主導の意思決定を可能になります。 前述の医療技術企業は、AWS Supply Chain の Vendor Lead Time Insights から大きな成果を上げており、サプライヤーとの効果的な交渉と計画システムにおける正確なリードタイム データの実現に注力できました。また、以下の分野で継続的な改善が期待されています。 在庫の最適化と運転資金の効率化: リードタイムの変動を正確に把握することで、在庫水準の改善と過剰在庫を削減し、運転資金を他の戦略的投資に振り向けることができます。 サプライヤーの契約遵守とパフォーマンス管理: データに基づくベンダーのリードタイム実績の分析により、遵守違反の問題を積極的に特定し対処することで、サプライヤーとの良好な関係と説明責任を育むことができます。 計画の信頼性向上による顧客サービスレベルの向上: ML によるリードタイム予測の精度と信頼性が高まることで、顧客サービスレベルが向上します。 AWS Supply Chain の Vendor Lead Time Insights は、供給計画に変革をもたらすアプローチです。強力な機械学習アルゴリズムを利用可能なデータに適用することで、組織がリードタイム平均に基づく計画に依存しないようにします。そして組織はリードタイム予測に関して、より正確なデータ主導のアプローチを採用できます。このアプローチは在庫水準を最適化し、可視性と説明可能性の向上を通じてベンダーとの強固な関係を育みます。組織は過剰在庫と関連コストを削減することで収益性を高めることができます。最終的に、AWS Supply Chain の Vendor Lead Time Insights によって可能になるサプライチェーン能力の向上は、顧客満足度の向上につながります。 AWS Supply Chain を始めるのは簡単で、前払いのライセンス料や長期契約は必要ありません。以下の 3 ステップで始められます。 AWS Supply Chain について学ぶ: AWS Supply Chain の ウェブサイト を訪れ、製品の機能と能力を理解する。 技術的な概要を知る: AWS Workshop Studio で自分のペースで進められる技術的なウォークスルーを探索する。インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成方法を学ぶ。 AWS Supply Chain を使い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導の管理ツールを使って、サプライチェーンの運用を合理化する。詳細な設定手順と追加のガイダンスについては ユーザーガイド にアクセスしてください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン 500 企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。 <!-- '"` -->

はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS へのシステム移行は、単純なシステム変更に留まらずプロセス変革やチームの役割の変更を伴うため、これらに最適化した組織体制の構築が重要です。システムが AWS に移行したとしても、組織が旧来型のオンプレミス前提のままでは、AWS のメリットを最大限享受できません。本ブログでは、AWS への組織体系の変更における考慮点を具体的な例を交えて 前編 ／後編に分けて提示します 後編では、AWS 活用に伴い発足する新たな組織の位置づけと組織文化の変化について記載していきます。 5．横断組織 (CCoE)の必要性 AWS の活用を通して、従来必要だった工数やタスクの負担が軽減されるものの、新たな役割も必要となります。まず重要なのが、ユーザー管理、権限管理、コスト管理を一元的に行う役割です。AWS アカウントの一元的な管理できず各事業部が自由に利用している場合、セキュリティ上のリスクや想定外のコストが発生する可能性があります。AWS では、これらの課題を解決するためのサービスが提供されています。例えば複数のアカウントの管理には AWS Control Tower などが活用できます。 また、AWS の従量課金モデルに伴い、利用コストの見える化と管理も重要になります。オンプレミスでは一度購買すればコストの変化は小さいですが、AWS では利用料に応じた課金となるため、コストの消費状況を監視・最適化する必要があります。AWS では AWS Cost Explorer や AWS Budgets など、コスト状況を可視化するサービスを提供しています。コストが想定以上に上振れている場合には、最適なインスタンスサイズの選択や不要なリソースの削除、起動時間の調整、Savings Plans の活用などを検討します。 さらに、AWS サービスが絶えず更新されていくため、自社のサービスもタイムリーにアップデートする役割が求められます。サービスの更新情報を把握し、利用者への周知・啓発を行うことで、最新のサービスを活用できるようになります。 ( 参考： AWS サービスアップデートまとめ ) これらの役割を組み込んだ組織を組成することで、AWS を安全かつ効果的に活用することができます。CCoE ( Cloud Center of Excellence ) の設立は有効な選択肢の1つです。CCoE は従来のインフラ部門の立ち位置とは異なり、AWS を活用してビジネス価値をもたらすために、利用者のよき相談役として機能することが理想です。CCoE は最初から正式組織として立ち上げる必要はなく、まずはバーチャル組織で展開し、次のステップで正式組織化する、といったステップも考えられます。組織の現状に合わせ、必要な役割を認識した上で、CCoE の立ち上げ方を検討するのが良いでしょう。CCoE についてはこちらのBlog も参照ください。( 参考： CCoE 活動検討のはじめの一歩 ） 6．組織変化を支える文化 組織体系の変化は、単なる構造の変更にとどまらず、組織の文化やメンバーの行動に深く影響を与えます。新しい価値観やプロセスが導入されることで、従来のやり方や考え方が見直され、組織全体に変革がもたらされます。この変化は、組織の一体感を強化し、より柔軟で効率的な業務運営を可能にするものです。本章では、組織文化への考慮すべきポイントについて記述します。 エグゼクティブのスポンサーシップ: エグゼクティブがクリアなビジョンと具体的な目標を示し、達成状況の追跡とリソース提供を行うことで、組織全体が変化に協力する文化が醸成されます。スポンサーシップが欠けると、変化への推進力が低下し、組織の目標達成が困難になります。 権限委譲と説明責任: メンバーに明確な所有権と説明責任を与えることで、意思決定が迅速化され、組織全体での改善が進みます。これにより、メンバーは組織の目標に向けて主体的に行動し、リスクを取ることが奨励され、継続的な改善が促進されます。一方で、権限や責任が不明確だと、対応の遅れや改善の停滞を引き起こします。権限委譲と説明責任の明確化は、組織の柔軟性と生産性を高める鍵となります。 オープンなエスカレーション: 組織内でエスカレーションが円滑に行われる文化を育むことが重要です。問題が早期に報告されることで、リスク管理が強化され、重大な問題に迅速に対処できるようになります。エスカレーションを奨励し、問題解決に真摯に取り組む姿勢を示すことで、健全な組織文化が構築され、メンバーは問題を隠さずに積極的に報告するようになります。 タイムリーで明確、かつ実用的なコミュニケーション: 組織全体に適時かつ明確なコミュニケーションを行うことで、変化に対する適応力を高めることができます。メンバーは変化の目的や意義を理解し、必要な情報をタイムリーに受け取ることで、業務をスムーズに遂行できます。コミュニケーションが不足すると、変化が遅れたり、メンバー間の理解が不十分になり、組織の目標達成に悪影響を及ぼす可能性があります。 実験の奨励: 組織がイノベーションを推進するためには、メンバーが新しいアイデアを試し、失敗から学ぶ文化を奨励することが重要です。適切な実験環境や機会を提供し、メンバーが安心して挑戦できるようにすることで、学習が加速し、組織の進化が促進されます。これにより、ビジネスの成果が向上し、組織全体でのイノベーションが進展します。 継続的な学習: 組織全体でスキル向上と知識の深化を支援する文化を構築することは、長期的な競争力の強化に不可欠です。体系的な教育プログラムや業界認証の取得を支援することで、メンバーのスキルが維持・向上し、組織のイノベーション力が高まります。継続的な学習を奨励することで、組織は変化に迅速に対応し、持続的な成長を遂げることができます。 適切なリソース配分: 効率的な運用を実現するためには、メンバーに適切なリソースを提供し、負担を適切に管理する文化が重要です。必要な人材やツールを適切に配置することで、チームの生産性と満足度が向上し、組織全体の運営が効率化されます。一方で、リソースが適切に配分されない場合、ヒューマンエラーや士気低下が発生し、組織の運営に悪影響を与える可能性があります。 これらの要素を組織文化に取り入れることで、AWS 移行に伴う組織変化と AWS のメリットを最大限に活用することが可能になります。 Well-Architected Frameworkの運用の優秀性の柱 (組織カルチャー) に上記ポイントにおけるメリットや実装ガイダンスも記載していますのでご活用ください。 7．まとめ オンプレミスから AWS へのシステム移行は、単なるシステム変更にとどまらず、組織プロセスやチームの役割変更を伴います。オンプレミスの組織文化とAWS での文化は大きく異なるため、これに最適化した組織体制の構築が重要です。 オンプレミスではIT 部門のインフラ担当がハードウェアの調達から運用管理を担当していましたが、AWS ではマネージドサービスの活用で運用負荷が軽減されます。アプリケーション部門がインフラ設定を自律的に推進し、DevOps の導入で開発と運用が一体化し、高速なアプリケーションリリースが可能になります。 さらに、AWS 移行に伴い新たな役割も必要となります。AWS アカウントの一元管理、コストの最適化、サービスアップデートへの追従など、AWS 活用を最大化する CCoE の設立が重要です。 また、AWS を最大限に活用するためには、 組織体系の変化だけでなく、組織文化も考慮する必要があります。エスカレーションの容認や実験の推奨などの要素を組織文化に取り入れるには、エグゼクティブによる強力なリーダーシップと組織全体の意識改革が不可欠となります。 ファーストステップとしては、組織として達成したいビジネス目標を定義し、組織として取り組むニーズの優先順位を明確することを推奨します。その際、 Well-Architected Framework の運用の優秀性の柱 (組織の優先順位) の活用も有効です。AWS の経験とベストプラクティスを活用できるため、合わせてご検討ください。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 甲斐 裕之、山崎 徹 参考 Well-Architected Framework 運用上の優秀性の柱 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/welcome.html CCoE 活動検討のはじめの一歩 https://aws.amazon.com/jp/blogs/news/how-to-define-your-own-ccoe-tasks/ 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ 責任共有モデルとは何か、を改めて考える https://aws.amazon.com/jp/blogs/news/rethinksharedresponsibility/ AWS Control Tower でコントロールを適用する際のベストプラクティス https://aws.amazon.com/jp/blogs/news/best-practices-for-applying-controls-with-aws-control-tower/

１．はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS へのシステム移行は、単純なシステム変更に留まらず、プロセスやチームの役割の変更を伴うため、これらに最適化した組織体制の構築が重要です。組織体制が旧来型のオンプレミス前提のままでもシステムをAWSに移行できますが、移行後の運用フェーズでAWSのメリットを最大限享受することはできません。本ブログでは、AWS への組織体系の変更における考慮点を具体的な例を交えて前編／ 後編 に分けて提示します。前編では従来の組織における変化点についてご説明していきます。 ２．オンプレミスと AWS の違い 従来のオンプレミスでは、ハードウェアの調達から設定、運用までを自力で行う必要がありました。これらを担うIT部門のインフラ担当は、見積や調達・設置・運用保守など、広範な知識と複雑なプロセスが必要でした。AWS を利用する場合、数クリック、数分間でリソースを増減できるため、オンプレミスのような購買調達プロセスが簡略化されます。ハードウェアは AWS のサービスをインターネット経由で利用するため、自前での調達・設置、数年先を見据えた計画立案などが不要になります。さらに、マネージドサービスやサーバーレスなどのサービスを活用することで OS、ミドルウェアの設定・運用保守の運用負荷も軽減できます。 セキュリティについても、従来のオンプレミス環境とは異なる視点が必要です。AWS では、AWS 側とお客様側で責任範囲が分かれる「責任共有モデル」を理解する必要があります。AWS がクラウド環境自体の責任を、お客様にはクラウド内のセキュリティに対する責任と管理を担っていただきます。この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。 ３．IT 部門の変化 ３－１．アプリケーション部門・インフラ部門の変化 IT 部門では、アプリケーション担当とインフラ担当の役割が明確に分かれているのが一般的です。システム開発においてはアプリケーション担当とインフラ担当の調整が発生し、開発スピードを低下させる要因となっていました。例えば、アプリケーション部門が新たな開発環境を調達する際、インフラ部門による構築・検証の完了を待つ必要があり、依頼からリードタイムが発生します。一方、AWS ではサーバーレス、マネージドサービス、IaC ( Infrastructure as Code )による環境の複製など、操作が容易で開発スピードを向上させるサービスが提供されています。アプリケーション部門がこれらの AWS サービスを有効活用することにより、インフラ部門の対応を待つことなく自力で環境を作ることができ、開発スピードの加速が可能となります。つまり、AWS の活用によって、従来の IT 部門組織における開発スピードの課題を解決することができるのです。アプリケーション部門が AWS サービスを活用することで、開発プロセスの効率化と迅速化が期待できます。 ３－２．運用部門の変化 開発スピードを向上するためには、開発と運用が一体となった DevOps 組織の編成が効果的です。DevOps は、従来の開発部門と運用部門の垣根を取り払い、両者が協力して素早くアプリケーションの改善を行うアプローチであり、クラウドの特性と適合しています。両者が分かれている場合、開発部門は目標としてリリース頻度や変更容易性を重視しますが、運用部門はシステムの安定性と効率化を重視する傾向があるため、部門間の対立・調整が課題となっていました。DevOps では開発と運用に取り組むメンバーが、同一の組織としてアプリケーションのライフサイクル全体を推進することで、目標が対立することなく開発を進めることができます。DevOps では自動化が重要な役割を果たします。アプリケーションのビルド、テスト、デプロイなどの工程を自動化することで、ヒューマンエラーを排除し、高速かつ安定したリリースサイクルを実現できます。 ３－３．組織の運用モデル AWSの Well-Architected Frameworkの運用の優秀性の柱 では、運用モデル 2 x 2 が表現されており、チーム間の関係を理解するのに役立ちます。また、モデルごとのガバナンスや意思決定プロセスについても提示しています。現在各チームがモデルの中でどの位置にいるか、チームの関係と責任がどのように変わるか、変更が組織への影響に見合っているかどうかを確認します。いずれのモデルにもメリット・デメリットがあるため、組織として達成したいビジネスゴールを設計・共有したうえで、優先度を判断し、選択することが重要です。 ４．セキュリティ部門の変化 オンプレミスの環境におけるセキュリティ部門の主な業務は、システムやネットワークの監視・管理、ファイアウォールやエンドポイントセキュリティなどのソフトウェア設定と運用、物理的なアクセスの管理などです。さらに、社内の基盤システムに関わるセキュリティ対策として、データバックアップ、侵入検知や脆弱性管理、ID・アクセス管理なども行います。つまり、オンプレミスの環境ではシステム基盤自体のセキュリティ管理が重要な役割となります。 一方、AWS では、AWS が大部分のセキュリティ機能を提供するため、セキュリティ部門の役割が大きく変わってきます。AWS 環境では「責任共有モデル」が適用され、AWS 側とお客様側で適切にセキュリティの責任を共有する必要があります。具体的には、AWS がネットワーク、ストレージ、データセンターなどのインフラストラクチャのセキュリティを担当し、お客様側が AWS 上のデータやアプリケーション、ID・アクセス管理などを担当することになります。 責任共有モデル このため、AWS 環境でのセキュリティ部門の役割は、AWS 上のデータやアプリケーションの保護、ID 管理やアクセス管理、脆弱性管理やモニタリングなど、AWS 上のリソース管理が中心となります。具体的な AWS のセキュリティサービスには、 AWS Shield 、 AWS WAF 、 Amazon GuardDuty などがあり、DDoS 攻撃の防御や Web アプリケーションファイアウォール、高度な脅威検知などを提供しています。また、 AWS Control Tower のガードレール機能を活用すれば、ベストプラクティスに沿った自動的なリソース設定の維持管理も可能です。 このような 変化に対応するため、セキュリティポリシーの見直しが必要になる場合があります。 オンプレミスのセキュリティポリシーは、社内ネットワークや物理的リソースへのアクセス管理を前提としていますが、AWS ではインターネット経由でのアクセスが前提となり、外部からの脅威にも対応できるようなポリシーへの変更が求められます。例えば、アクセス制御においては、多要素認証（MFA）の導入や最小限のアクセス権限の付与といった、 AWS のベストプラクティス を考慮することが重要です。 この責任共有モデルを組織に適切に組み込むためには、まず AWS セキュリティチームを設置し、AWS とお客様側の責任分界線を明確にする必要があります。そして、セキュリティポリシーの見直しや利用部門や開発部門への教育、定期的な監査とコンプライアンスの確認に取り組みます。 このように、オンプレミスと AWS では、セキュリティ部門の役割やセキュリティポリシーが大きく異なります。特に AWS 環境では、AWS のセキュリティ機能を最大限活用しつつ、お客様側の責任範囲におけるセキュリティ管理を適切に行うことが重要となります。 まとめ 前編では、従来のオンプレミスとAWS の違いから、IT 部門、セキュリティ部門の変化について整理しました。 後編 では、AWS によって新たに組成する組織や、組織文化の変更についてご紹介していきます。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 甲斐 裕之、山崎 徹

はじめに みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 2024年8月8日に「 ベストプラクティスから学ぶクラウド移行の勘所セミナー ～何千もの顧客をクラウドに移行した AWS の経験に基づく、包括的で実績のあるベストプラクティス～ 」を開催しました。 このブログでは、当日参加できなかった方や、参加したけれども内容を振り返りたい方に向けて、ご自身の取り組みの参考としていただくために当日のセッション内容のまとめを紹介します。 セッション内容の紹介 クラウドジャーニーを成功へ導く移行プロジェクトのベストプラクティス – 松尾 康博、アマゾン ウェブ サービス ジャパン合同会社 アジアパシフィックジャパン マイグレーション アンド モダナイゼーション技術統括本部 プリンシパルソリューションアーキテクト 本セッションでは、 これまで長年にわたって多くのお客様のクラウドジャーニーをご支援してきた中から、ほとんどのお客様がお悩みになるポイントをピックアップし、それらについて普段AWSがご案内している「考え方」や「心構え」について紹介しました。 クラウドジャーニーでは、クラウド移行完了までに大きく「移行検討」「プロジェクト立ち上げ」」「プロジェクト推進」の3つのフェーズに分解できます。それぞれのフェーズでよくあるお悩みとしては以下があります。 移行検討フェーズ：何から考えれば良いか？ プロジェクト立ち上げフェーズ：どう始めれば良いか？ プロジェクト推進フェーズ：うまく進めるために何をすれば良いか？ 本セッションの冒頭でこの課題定義をした後、各フェーズでの考え方や心構えを提示しています。 移行検討フェーズでは、3つの指標「戦略(Why?)」「スコープ(What?)」「タイムライン(When?)」を、ビジネス価値から考えて関係者全員で共有することの重要性を説明しました。クラウドへ移行することのビジネス価値を考えるための補助線としてクラウドバリューフレームワークを紹介し、その具体的な作成例としてKPIによる定量的な定義をご紹介しました。 プロジェクト立ち上げフェーズでは、「人」「プロセス」「技術」の3つの観点で並行して準備を進めることをベストプラクティスとしてご紹介しました。中でも、人はCCoE (Cloud Center of Excelense)の立ち上げと人材育成といった組織開発が重要であることと、移行プロセスの準備のためにやるべき事前作業や検討内容についてご紹介しています。 プロジェクト推進フェーズでは、一括移行ではなく立ち上げフェーズで定義した段階的移行（ウェーブ）の中でも特に移行リハーサルの重要性を説明しました。 移行完了後も継続的に改善することでクラウドのメリットを最大化できます。継続的改善の考え方は、本セッションでここまで説明した戦略策定や立ち上げフェーズの考え方を短く早いサイクルで回し続けることで可能であることを最後にご紹介しました。 資料のダウンロードは こちら から VMware 仮想環境、次の一手はどうする？ 〜仮想マシン (VM) と仮想デスクトップ環境 (VDI) の AWS への移行方式〜 – 武田 紘一、アマゾン ウェブ サービス ジャパン合同会社 エンタープライズアプリケーション本部 シニアスペシャリストソリューションアーキテクト 本セッションでは、昨今の VMware ワークロードを取り巻く状況変化に伴い「次の一手」を検討しているお客様に向けて AWS が推奨する移行オプションについてお伝えしました。VMware への対応のみならず、Windows Server 2016 の EoS が迫っている現状は、視点を変えると新しいプラットフォームに目を向けるチャンスでもあります。 Amazon EC2 は AWS Nitro System という独自のハードウェア、ハイパーバイザーで最適化された仮想マシンサービスです。物理層がハイパーバイザーで抽象化されているため、OS の目線で考えると実はオンプレミスの VMware 仮想マシンもクラウド上の Amazon EC2 も多くの共通点があります。Amazon EC2 に移行する手法を検討する際には AWS Application Migration Service (MGN) が第一に候補に挙がります。最近では、クラウドバックアップの応用系として AWS Backup を利用してオンプレミスの VMware 仮想マシンから Amazon EC2 に変換する手法も注目されています。 仮想デスクトップ環境 (VDI) のクラウド移行に目を向けると、すでに数十万のアクティブユーザーにご利用いただいている Amazon WorkSpaces が候補となります。オンプレミスの Horizon 環境など既存の VDI ソリューションを活かしつつクラウドに拡張する際には、Amazon WorkSpaces Core も選択肢となりえます。2024 年 6 月には非永続デスクトップ型の Amazon WorkSpaces Pools をリリースし、さらに多くのお客様のご要望に応えています。 AWS はこれからもみなさまの「次の一手」に伴走していきます。 資料のダウンロードは こちら から データドリブン経営を実現し生成AIの価値を最大化するためのデータプラットフォームの実現に向けて – 大塚 信男、アマゾン ウェブ サービス ジャパン合同会社 アジアパシフィックジャパン マイグレーション アンド モダナイゼーション技術統括本部 シニアソリューションアーキテクト 本セッションでは、まず、データドリブン経営を実現するためのデータプラットフォームのテクノロジー要件をご説明し、AWS上でクラウドネイティブなサービスを活用してモダンなデータプラットフォームを構築することにより、これらの要件を高いレベルで満たすことができることをお伝えしました。また、価値の高い生成 AI アプリケーションを作成するには、自社が保有するデータを最大限活用するためのバックエンドの仕組みが必要であり、データプラットフォームがモダナイズされていることが重要であることもお伝えしました。 これからクラウド上でデータプラットフォームの強化や刷新をお考えのお客様に対しては、最初のステップとして、AWSから無償のDPMODA (Data Platform Modernization Assessment) による現状評価支援をご提供させていただくことが可能です。（※実施には条件がございます。）DPMODAはAWSモダンデータアーキテクチャをベンチマークとすることで、お客様の現行環境のハイレベルな課題を抽出し、モダナイズによる改善策をご提案するアプローチです。質問シートへの事前の回答記入後にAWS技術者からのヒアリングを行わせていただき、約2週間後に報告会を開催いたします。DPMODAを通して現状の課題を可視化し、改善の一歩を踏み出していただくことができれば幸いです。 資料のダウンロードは こちら から AWSへの大規模移行を包括的にご支援 ～ITトランスフォーメーションパッケージの全貌～ – 諏佐 嘉之、アマゾン ウェブ サービス ジャパン合同会社 サービス＆テクノロジー統括本部 マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 本セッションでは、お客様がクラウドへの移行をスムーズに遂行できるよう、AWSから提供できるご支援内容について説明いたしました。 AWSでは、従来から様々なプログラムやソリューションでお客様のクラウド活用をご支援してまいりました。それらのプログラムやソリューションをクラウド移行やクラウドネイティブ化という文脈でまとめ、「ITトランスフォーメーションパッケージ (ITX)」として提供しています。ITXは、移行の方式やお客様の特性などに応じて、ITX for Cloud First、ITX for Cloud Native、ITX for MCP Parter、ITX Lite、ITX for PSという5つのパッケージを提供しています。この中から、お客様の移行の要件に応じてご選択頂けます。 このセッションの中では、クラウド移行においてお客様がどのような立ち位置にいらっしゃるのか、どのようなポイントで悩まれているのかなどのケースに応じたITXの活用方法をご紹介いたしました。ITXで提供しているプログラムの多くは無償でご利用頂けます。 ITXが、お客様のスムーズなクラウド移行の一助となれば幸いです。 資料のダウンロードは こちら から おわりに AWSへの大規模なシステムの移行をサポートするITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

AppsFlyer は、モバイルアトリビューションとマーケティング分析のグローバルリーダーです。AppsFlyer は、包括的な計測プラットフォームとプライバシークラウドを通じて、顧客のプライバシーを守りながらエコシステムの協調を促進することで、企業がすべてのチャネルとデバイスにわたるマーケティング活動の影響を理解することを支援します。 AppsFlyer 内では、データがコアであり、詳細な分析を公開し、顧客がキャンペーン活動のどこに焦点を置くか 正しい決定を下せるようになります。データのバックボーンは Apache Kafka の助けを借りて管理されており、1000 を超えるマイクロサービスのタイムフローを処理し、最大 50 を超えるクラスターに分散し、最大 800TB のデータを保持しています。 従来の Kafka インフラストラクチャでは、伝統的なセットアップを採用しており、各 Kafka ブローカーが専用の Amazon Elastic Compute Cloud (Amazon EC2) ノードにデプロイされていました。このシステムは、Chef、Terraform、サードパーティのサービスなど、さまざまなツールによって管理されており、それらは複数のGitプロジェクトに分かれていました。 この状況は、インフラストラクチャの変更のたびに複雑な依存関係の考慮が伴うため、、管理が複雑になりました。各コンポーネントは、Kafka のアップグレードなどの些細なタスクでさえ、慎重な検討、テスト、承認が必要でした。この複雑さにより、チームの作業負荷と複雑さが大幅に増え、その結果、AppsFlyer の内部研究開発 (R&amp;D) に投資できるリソースが減少しました。 そのため、AppsFlyer Platform グループが、従来の Kafka インフラストラクチャを Kubernetes に再設計する課題を受けた際、我々はさまざまな側面で Kafka システムを成長・改善する機会と捉えました。主な目標は、クラスターをより高度で自動化された高性能かつ管理が容易なインフラストラクチャに移行することでした。これにより、クライアントとチームの日々の運用の両方に恩恵がもたらされます。 この投稿では、Kafka アプリケーションを Kubernetes に移行したことで私たちの組織が実現した主な利点と、直面した課題、そしてその課題を克服するために採用した AWS のソリューションについて共有します。 Amazon Elastic Kubernetes Service による効率化 レガシーインフラストラクチャを再設計する際には、過去のインフラストラクチャと一致するソリューションを実装し、パフォーマンスを向上させ、簡単な管理と保守可能な自動化システムを提供する機会があります。加えて、コスト削減の余地も見込まれます。 幸いにも、Kubernetes に移行する際、AWS Cloud には複数のソリューションが用意されていました。 Kubernetes はコンテナ化されたワークロードを管理するための多目的なツールで、サービス検出、オーケストレーション、ストレージ、シークレット管理、自己修復機能など、さまざまな機能を提供します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、AWS 上で Kubernetes クラスターを構築・維持を簡素化する完全マネージド型の Kubernetes サービスです。AWS の主要サービスと統合されているため、ステートフルアプリケーションに関する様々な AWS クラウドコンポーネントとの接続や対話が容易になります。 私たちのデプロイでは、 Strimzi Kafka Operator を使用しています。これは、Kubernetes クラスター内で Apache Kafka を実行するプロセスを簡素化するプロジェクトです。これを選択したのは、Kubernetes 上で Kafka を効果的に管理するために専用に構築されたコンテナイメージとオペレーターを備えているためです。 AWS が提供する実装とツール (例えば External DNS 、 AWS Load Balancer Controller ) とオープンソースのツールを利用することで、私たちのニーズにあったデプロイメントを構築できました。大規模な Kafka の実行とクラスターの簡単なリバランス機構を提供する Cruise Control などのオープンソースツールを使用しました。さらに、リアルタイムでトピックのメッセージを観察できるユーザーインターフェース (UI) ツールである Redpanda-Console も使用しました。これらのツール群により、ストレージ、ネットワーク、アプリケーションなど、多層のインフラストラクチャを単一の Kubernetes サービスの下で管理できるようになりました。 異なる Git プロジェクトで個別のコンポーネントを管理する必要があった従来のインフラストラクチャとは異なり、1 つの中央集権化された Git プロジェクトの下で、すべてを 1 か所で管理しました。これにより、コラボレーションを改善し、関連リソースの可視性とトラッキングを向上させることができました。 Graviton による最適なパフォーマンス コンテナオーケストレーターを決めた後、Kafka pod を実行する AWS インスタンスの種類を選択する必要がありました。 当初、コストパフォーマンスと強化されたローカル SSD ストレージを考慮して、従来の i3 インスタンスから改良された i3en インスタンスへの移行を計画していました。しかし、ベンチマークの際に、AWS から私たちにメリットをもたらす可能性のある別のインスタンスタイプが紹介されました。 AWS Graviton です。 Graviton インスタンスは、さまざまなシステム利用シーンに合わせた多様なインスタンスタイプを備え、パフォーマンスと機能が向上しています。Graviton インスタンスは、ARM ベースのプロセッサを搭載していますが、我々のユースケースにとって最も重要なのは、IOPS とスループットが向上したローカル NVMe ストレージです。 従来のインフラストラクチャでは、Kafka ブローカーにインスタンスローカルストレージを使用することにしました。これは、入出力操作/秒 (IOPS) やフェッチ時間などのパフォーマンス要因を最大化するためです。外部ストレージでは、100 万以上の IOPS とミリ秒単位のレイテンシーという要件を満たすことができませんでした。 Kubernetes でローカルストレージを使用するのは比較的新しい概念です。このようなシステムでは、ノードを失うと、そのノード上のデータも失われるため、失われたデータを複製するための復旧時間が長くなります。 そのため、従来のインフラストラクチャと新しい Kubernetes インフラストラクチャの両方で、オンデマンドインスタンスを使用しています。これにより、ノードの終了と中断のインシデントを減らすことができ、Kafka が他のブローカーからデータを復元する必要がある回数を効果的に減らすことができます。これにより、複数のノードが終了することによる完全なデータ損失のリスクを回避できます。 しかし、高速なデータ復旧に関して、Graviton インスタンスはローカル NVMe SSD ストレージを提供しており、リアルタイムのバスデータベースやステートフルアプリケーションにとって大きな恩恵があります。 従来の i3.2xlarge インスタンス上で実行されている Kafka クラスターと、新しい im4gn.2xlarge Graviton インスタンス上で実行されている Kafka クラスターを比較すると、スループットが 75% 向上 、CPU 消費が 10% 低下 、そして特に注目すべきは、書き込み I/O のパフォーマンスが 58% 向上 、読み取り I/O のパフォーマンスが 92% 向上 するという驚くべき結果が得られました。 今に至るまでの経緯を振り返ると、im4gn Graviton インスタンス上の新しい Kubernetes アーキテクチャで Kafka を実行しているわけですが、CPU コア数を半減させ、 コストを 50% 削減 できたと自信を持って言えます。さらに、カーボンフットプリントも低減できるという利点もあります。 Kubernetes、Kafka、ローカルストレージの力 Graviton インスタンスを選択した後、Graviton の Local SSD ストレージの利点を活用したいと考えました。ベンチマークでは、書き込み I/O パフォーマンスが 58% 向上し、読み取り I/O パフォーマンスが 92% も大幅に向上したことが確認できました。これは無視できない事実でした。 ローカルストレージには、ノードの障害ごとに新しいブローカーが起動してデータを復元する必要があるため、復旧時間が遅くなるという課題がありますが、私たちはその課題に取り組むことにしました。単一の Kafka pod が存在するノードと同じ場所にストレージを配置することで (外部ストレージを使用するのとは対照的に)、プロデューサーとコンシューマーにパフォーマンス向上の恩恵をもたらすことができます。 まず、Kafka の &nbsp; Persistent Volume Claims (PVC) を対応する &nbsp;Persistent Volume (PV) に割り当てる管理を行うプロビジョナーを選択する必要がありました。そして、これらの PV は Graviton インスタンスによって提供されるローカル SSD ストレージにマッピングされます。 最終的に、Rancher の Local Path Provisioner オープンソースプロジェクトを使用することにしました。このプロビジョナーは、ローカルタイプのストレージの PVC を監視し、ノード上に PV を自動的に作成するとともに、PVC と PV のバインディングもします。 次に、ノードの障害シナリオについて考える必要がありました。つまり、基盤となるノードが障害を起こすと、そのノードがホストしていたローカルストレージが削除されます。これにより、新しい Kafka pod は、ストレージが再度利用可能になるのを待つため、ステータスが Pending になります。。 この状況に対処するため、私たちは Local PVC Releaser という独自の社内オープンソースコントローラーを開発しました。このコントローラーは、計画的または計画外のノード終了に関する Kubernetes イベントを監視します。ノードの終了を検出すると、コントローラーは自動的に終了したノードにバインドされていた PVC (ローカルストレージタイプ) を削除します。これにより、Strimzi Operator が PVC を再作成し、pod を新しいノードに安全に割り当てられます。そして、データの複製を開始されます。 Persistent Volumes の図 各 Kafka pod を単一ノードで実行するように設定し、ノードの障害が単一のブローカーにのみ影響するようにすることで、ノイジーネイバー問題を回避し、Kafka クラスターの可用性を高めることができます。 ステートフルアプリケーション向け Karpenter による Amazon EKS 自動化の最適化 最終的な構成を決定した後、次のステップはオートスケーラーを導入して、このソリューションのポテンシャルを最大限引き出す自動化をすることでした。当初、私たちは Kubernetes Autoscaler ソリューションを試し、EKS クラスターでのオートスケーリングイベントを処理しようとしました。 しかし、Kafka pod でインスタンスローカルデータストレージを使用したり、大規模な障害から保護するためにKafka pod を異なる アベイラビリティーゾーン (AZ) に分散させることで、複雑さが増したため、プロダクションではスケーリングイベントや障害イベントインシデントに即座に対応する必要がありました。 そのとき、AWS は 我々に Karpenter を紹介してくれました。 Karpenter は AWS が立ち上げ、支援するオープンソースプロジェクトで、Kubernetes ノードのオートスケーリングソリューションとして機能します。Kubernetes pod の要件と制約を考慮して、コストとリソース効率を最適化するように動作します。Karpenter は、より柔軟性のあるスケーリングを目指しています。 Karpenter は主に 3 つの点で私たちを助けてくれました。 1. スピード Kafka と Kubernetes には多くの自己修復機能がありますが、新しい AWS インスタンスを起動して EKS クラスターに追加できる速度は、私たちとユーザーにとって非常に重要です。 Karpenter は、スピーディな応答時間で、pod が新しいリソースを要求したことを自動的に認識します。Karpenter は、設定 (私のチームがプログラミングしたもの) で要求されたとおりにインスタンスをデプロイしますが、この時 Karpenter は pod の要件も考慮します。この様なロジックを通して、我々はインスタンスのデプロイ時間と復旧時間を Kubernetes autoscaler では 9 分程度を想定していましたが、Karpenter を使用することで 1 分未満 に短縮できました。 2. ローカルストレージの認識 この大幅な削減は、Karpenter のローカルストレージ認識機能によるものです。Karpenter には、ストレージスケジューリング要件を自動検出し、トポロジースプレッドとハードウェア仕様と組み合わせてノードの起動判断に統合する機能があります。 ローカルストレージの認識は、Kubernetes autoscaler が提供していない機能でした。Kubernetes autoscaler は、pod のローカルストレージをどこに配置すべきかを直接認識していないためです。一方で、Karpenter は自動的にローカルストレージを認識し、正しい AZ にインスタンスをデプロイします。 3. 大幅なコスト削減 Karpenter の最適化により、大幅なコスト削減が実現されます。Karpenter は、EKS クラスター上で実行されているデプロイアプリケーションをサポートするために必要なインスタンス数だけでなく、コスト効率を最適化するための特定のインスタンスファミリーとサイズを計算できるためです。 この機能は、Kafka クラスターと並行して動作するサードパーティツールの pod に役立ちます。これらの pod はステートレスなので、Karpenter が便利です。Karpenter は、インスタンスタイプとサイズでサポートできる pod の数を自由に決定できます。これは、使用頻度が低い別のインスタンスをデプロイする必要がないよう、同じインスタンス上に戦略的に pod を配置することで実現されます。 これらすべての結果から、ステートフルアプリケーションを Amazon EKS 上で実行する際のニーズを満たしたため、Karpenter を主要な自動スケーリングソリューションとして完全に利用することを決定しました。 Kafka の Kubernetes への移行 この投稿で説明した AWS ツールと、この投稿では説明しきれないその他多くのツールを使って、新しいアーキテクチャを確立した上で、AppsFlyer チームは 従来の Kafka クラスターを新しく改善された Kubernetes 上の Kafka インフラストラクチャに 2 か月足らずで移行することに成功しました。 この移行により、「Produce」リクエストと「Consume」リクエストの時間の大幅な性能向上、ディスク I/O 書き込み性能の強化、ノード障害発生時の高速かつ柔軟な復旧が実現し、ユーザーにメリットをもたらしました。さらに、これらの要素は Terraform でラップされているため、簡単に管理でき、AppsFlyer チームはクラスターを最新で健全な状態に保つことができます。 これにより、今日では、この基盤を使って 50 を超える本番 Kafka クラスターを管理しています。 以前の設定と比べて CPU コア数が半分になり、驚くべき 30% のコスト削減 が実現しました。 新しく得た知識と既に確立されたビルディングブロックを武器に、私たちは今や Kubernetes 上でより多くの種類のステートフルなアプリケーションを、はるかに短い時間で構築できるようになりました。 EKS 上の Kafka とローカル NVME の図 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

「金融リファレンスアーキテクチャ日本版」 は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして 2022 年 10 月に正式版として発表し、多くのお客様にご利用いただいております。 この度、皆様からいただいたご意見を踏まえ、レジリエンス関連の機能強化を行ったv1.3を公開しました。変更点の概要は以下の通りです。 [v1.3での主な変更点] 勘定系ワークロード: マルチリージョン・デモ用サンプルアプリケーションの強化 1-1. Step Functionsによるリージョンの自動フェールオーバー 1-2. Synthetics Canaryによるアプリケーションの外形監視 1-3. OpenTelemetryの導入 (AWS X-Ray) 勘定系ワークロード: ランサムウェア対策の追加 これらのアップデートについて解説していきます。 1. マルチリージョンアプリケーションのレジリエンス強化 1-1. Step Functionsによるリージョンの自動フェールオーバー 金融リファレンスアーキテクチャ勘定系ワークロードでのマルチリージョンの構成 金融リファレンスアーキテクチャの勘定系ワークロードは、銀行の各種業務とその元帳のDBを管理する勘定系業務に対するリファレンスアーキテクチャーです。このアーキテクチャにあわせたオンライントランザクション処理のサンプルアプリケーションが含まれています。銀行勘定系をターゲットとしていますが、汎用的なトランザクション処理に向けたものとなりますので、他の同様なワークロードにも適用可能です。 勘定系ワークロードのリファレンスアーキテクチャ このアーキテクチャではアプリケーションをマルチAZ構成にすることで通常故障から保護しています。さらに、東京と大阪のマルチリージョンで Active – Standby 構成としています。東京リージョン全体が影響を受けるような何等かの障害が発生しても、大阪リージョンへフェイルオーバーすることで、サービスを提供し続けることが出来るようになっています。 このワークロードの上で稼働するアプリケーションとしては、トランザクション管理、アトミック性、排他制御などが求められるため、メイン DB としてRDBMSであるAurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しています。また、アプリケーションはECS上で東京、大阪の両リージョンで常時起動しており、 Route 53 ARC を利用して利用リージョンのアプリケーションへトラフィック制御を行っています。 リージョン切り替えのフローと自動化 東京リージョンの障害を想定してのフェイルオーバーと収束後の切り戻しを想定したフェイルバック、２つの切り替えフローを準備しています。 フェイルオーバーの流れを示したのが以下の図です。元帳にあたるAuroraDBのデータ不整合を避けるため、まずStep1として東京リージョンのアプリケーションを閉塞しデータベースの更新を停止します。これはDynamDB Global Tablesに持つ閉塞フラグを利用します。その後Step2としてクライアントのリクエストをDNSにより大阪リージョンへルーティングします。これはTTLを加味してAurora Global Databaseの切り替え中に東京へのルーティング情報が残らない状態にするため、また障害によるエラーではなく大阪リージョンで稼動するアプリケーションにルーティングすることで適切に閉塞のステータスを返却するためです。その後Step3としてAurora Global Databaseを使ってレプリケーションされている大阪リージョンのBDに切り替えます。切り替えが完了したのち、最後にStep4として大阪リージョンのアプリケーション閉塞を解除します。この一連のフェイルオーバーは約５分間で完了します。 Step Functionsによるリージョン切り替え作業の自動化 フェイルオーバとフェイルバックのフローは Step Functions を使って以下のようなステートマシンのフローで自動化しています。自動化においては各々のStepの間に、適切な切り替えのための待ち時間や確認処理を入れることが重要です。詳細は以下の図で示しています。 Step Functionsのステートマシン実行 1-2. Synthetics Canaryによるアプリケーションの外形監視 ミッションクリティカルなアプリケーションにおいて、外形監視はユーザー体験を直接反映し、システム全体の健全性を把握するために重要です。システム視点での内部監視では検出が難しい複雑な障害やネットワーク遅延を早期に発見し、迅速な対応を可能にします。また、サービスレベル契約（SLA）の遵守確認や、ビジネスインパクトの最小化にも寄与します。 今回のアップデートでは、 AWS CloudWatch Synthetics Canary を活用して、アプリケーションの外形監視のサンプル実装を提供します。このアプリケーションは残高照会、入金処理、出金処理のAPIを通じてトランザクションを処理します。大阪リージョンに設定したCanaryを用いて東京リージョンで稼働するアプリケーションに対して継続的に疑似トランザクションを実行させて、APIの応答メッセージの正常性と応答遅延を継続的にチェックしています。このサンプルによって、問題が発生した際に迅速に対応でき、サービスの信頼性を高めることができます。 Synthetic Canaryの実行 疑似トランザクション生成のためのHTTPリクエスト 1-3. OpenTelemetryの導入 (AWS X-Ray) サンプルアプリケーションの外形監視に加え、 AWS X-Ray を利用して、マイクロサービス間の遅延やエラー、失敗をトレースする仕組みを導入しました。このアプリケーションは残高照会、入金処理、出金処理のAPIを提供し、それぞれがマイクロサービスで構成されています。X-Rayを用いることで、各リクエストのフローを詳細に可視化し、特定のサービスでのパフォーマンス低下やエラー箇所を迅速に特定可能です。このトレース機能により、問題発生時の迅速なトラブルシューティングと、サービス全体の信頼性向上が実現されます。 X-Rayによるトレース 2. ランサムウェア対策の追加 ランサムウェアとは ランサムウェアとは「身代金（ransom、ランサム）を支払わないと被害者のデータを公開したり、ビジネスに不可欠な情報へのアクセスを遮断するマルウェアの一種のこと」です。ランサムウェアによる被害は、IPA (情報セキュリティ推進機構) が公表している 情報セキュリティ10大脅威 2024 の組織向け脅威の１位として挙げられており、組織にとって重大なセキュリティ上の脅威となっています。 ランサムウェアとは？ ランサムウェアによる被害を防ぐには、マルウェアの侵入防止や攻撃者によるデータへのアクセス防止、データアクセスの失敗を攻撃の予兆として検知するなどの対策が考えられますが、ここでは実際に被害を受けてしまった場合の復旧に備えたバックアップ取得に関する対策についてご紹介します。 ランサムウェアに対する主な対策 金融リファレンスアーキテクチャ勘定系ワークロードでの対策 勘定系ワークロードは永続化データに、メイン DB として Aurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しており、これらのデータベースを対象にランサムウェア攻撃を受けた際に復旧可能なように AWS Backup でバックアップを取得します。 AWS Backupは、取得したバックアップをバックアップボールトとして管理します。バックアップボールトには、取得したバックアップを保護するためにボールトロックをオプションで指定することができ、２種類のロックモードを提供しています。ガバナンスモードでは、ボールトに格納されたリカバリポイントは特定の IAM 権限でのみ削除可能なロックモードとなっており、コンプライアンスモードはデータ保持期間が終了するまでボールトとリカバリポイントをルートユーザー（アカウント所有者）や AWS を含めていかなるユーザーも変更、削除することができなくなります。詳しくは こちら をご覧ください。 AWS Backup Vault Lock ボールトロックはこのようにリカバリポイントを保護する機能を提供するため、ランサムウェア対策として利用することができます。金融リファレンスアーキテクチャ勘定系ワークロードでは、Aurora Global Database と DynamoDB テーブルを対象に AWS Backup でバックアップを取得し、ボールトロックを指定したバックアップボールトへと保管しています。ただしサンプルアプリケーションであることから、十分な IAM 権限を持つユーザーであればデータ削除が可能であるガバナンスモードでの実装としています。コンプライアンスモードに変更することで、バックアップボールトに格納されたリカバリポイントを一定期間、特権ユーザーでも削除できない状態とすることが可能です。 まとめ 金融リファレンスアーキテクチャ日本版の全てのコンテンツとコードは、パブリックの&nbsp; GitHub リポジトリ から参照でき、Git リポジトリとしてローカル環境にクローンすることもできます。フィードバックや質問については Issue として GitHub サイト上に登録いただけます。また、執筆者に直接ご連絡頂いても構いません。ご利用される皆様からのニーズや意見に基づいて今後の改善方針を決めていきたいと考えておりますので、ご質問やフィードバックをお待ちしております。 金融リファレンスアーキテクチャ日本版v1.3での変更点の詳細については こちら を参照下さい。 なお、本ブログ記事は AWSのソリューションアーキテクトである根本裕規、疋田洋一、深森広英で執筆いたしました。 謝辞 アマゾン ウェブ サービス ジャパン合同会社 金融グループ/グローバルフィナンシャルサービス/プロトタイピングチームの下記メンバーで今回の開発を行いました。 根本裕規、疋田洋一、吉澤稔、深森広英、友岡雅志

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 9月に入り2024年もあと4ヶ月になりました。時間の流れの速さに驚いている今日この頃ですが、AWSでは年末に向けて様々なイベントを企画しています。随時情報をお知らせしていきますので楽しみにお待ち頂ければと思いますが、新しい知識を仕入れて頂いたり、実際に手を動かして頂いて実感を得て頂いたり、様々な体験をお届けしたいと思っていますので、是非ご期待ください。 「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、8 月 19 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ファミリーマート様、生成AIによりシステム運用業務を効率化 株式会社ファミリーマート様は、大規模で複雑なものになりがちなシステム開発において、今までの教訓や担当者の知見を効率的に活用したいという課題を感じており、生成AIを使った解決にチャレンジすることとしました。既存のシステムとの連携やセキュリティ向上のために様々なルールが設けられていますが、効率的に情報を検索するためのチャットボットがその第一歩です。着目すべきはPoCの実施に当たって定量的な評価手法を定義し、成功の度合いを測定できる用にしている点です。これによって生成AIで課題解決ができるテーマ、さらなる改善が必要なテーマを明確に判断することができているそうです。今後の展開として、このチャットボットの本格展開を検討しています。 AWS生成AI国内事例ブログ: 株式会社JDSC様、Bedrockによる横断検索システムで専門的な工数を97%削減 株式会社JDSC様は日本の産業のアップデートを使命とする、東京大学発のAI企業です。この事例は、JDSC様が海運事業に取り組むお客様に検索拡張生成(RAG)を構築し、専門的な知識を要する問い合わせ対応の時間を約97%削減、従来のシステムと比較して回答の精度を30%向上させるという結果を得ることに成功しています。また、問い合わせ対応にあたって属人的な知識や専門知識の必要性を軽減することで、対応可能な人材の幅を広げることができています。当初はClaude 3 Sonnetの利用を検討していたところ、Amazon Titan Text V2やClaude 3.5 Sonnetを比較し、用途に対してより良い結果が得られるClaude 3.5 Sonnetを採用することとしたエピソードは、Bedrockらしい事例だなと感じます。 ブログ記事「生成 AI のためのネットワーク境界でのセキュリティ保護」を公開 生成AIを組み込んだアプリケーションにおいても、セキュリティは重要な考慮事項です。このブログ記事では、ネットワーク境界保護の観点を説明し、生成AIアプリケーションにおいてどのように適用されるべきか、具体的なアーキテクチャ例はどういったものかを解説しています。ネットワーク境界保護を適用するとこで、不正使用やコスト超過、DDoS攻撃などへの耐性を獲得するためのアイデアが詰まっている記事です。 ブログ記事「Amazon Bedrock を活用した RAG チャットボットアーキテクチャのハードニング : セキュアデザインのためのブループリントとアンチパターンへの緩和戦略」を公開 この記事はセキュリティ計画を立案しそれに適合するようにAmazon Bedrockを利用することで、安全で責任あるチャットボットアプリケーションをデプロイする方法を解説しています。また、大規模言語モデル(LLM)を利用する際に課題に成り得る一般的なセキュリティリスクと、アンチパターンについても提示します。LLMを組み込んだアプリケーションの信頼性を高めるための手法を知ることができますので、ぜひご一読ください。 サービスアップデート Amazon Q Businessがユーザ認証のフェデレーションに対応 Amazon Q BusinessでIAMフェデレーション機能が公開されました。この機能を利用するとAmazon Q BusinessでOIDC(OpenID Connect)とSAML2.0プロトコルをサポートするアイデンティティプロバイダーと連携し、これらで管理するユーザIDとユーザの属性を利用してユーザの認証・認可が可能になります。従来は一旦AWS IAM Identity Centerに同期する必要がありましたが、この手間が不要になるのがポイントです。 Amazon Bedrockがクロスリージョン推論をサポート Amazon Bedrockでクロスリージョン推論機能が利用できるようになりました。この機能は、複数のリージョンでトラフィックを動的にルーティングすることで、ユーザトラフィックの増加時にも、より高いスループットやサービスの可用性を高めることが可能になります。利用できるリージョンをあらかじめ定義できるので、推論データが処理される場所を制御することもできます。現時点ではAnthropicのClaudeが対象になっています。 ブログ も出ていますのでこちらもどうぞ。 Amazon Bedrock Knowledge BasesでMetaのLlama 3.1を利用可能に Amazon Bedrock Knowledge Basesは検索拡張生成(RAG)を容易に実現するサービスです。今回、Amazon Bedrock Knowledge BasesでMeta社のLlama 3.1 405B, 70B, 8Bのモデルを利用できるようになりました。RAGワークロードにおいても、用途に応じて最適なモデルの選択肢の幅が広がっています。 Amazon SageMaker Projectsで過去に削除したプロジェクト名の再利用が可能に Amazon SageMaker Projectsは開発者環境とMLOpsのためのCI/CDシステムの設定や標準化を支援する機能です。今回、過去に使用していて削除したプロジェクトと同じ名前を、新しいプロジェクトに再利用できるようになり、命名規則を柔軟に考える事が可能になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週も書きましたが、AWS Innovate – Migrate. Modernize. Build. が 9 月 26 日 (木)にオンラインで開催されます。先日実施した AWS Builders Online (現在オンデマンド視聴可能) はAWS入門のイベントでしたが、こちらはすでに活用されているユーザー企業の事例発表や、最新技術の情報が6トラックで実施されます。今回のテーマはモダナイズですので、クラウドテクノロジーを活用したモダナイズに関するセッションが多数提供されます。ぜひご参加ください。 – AWS Innovate – Migrate. Modernize. Build. それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月26日週の主要なアップデート 8/26(月) Amazon Braket は、ゲート方式の超電導デバイスである Rigetti の 84 量子ビット Ankaa -2 システムのサポートの追加を発表 – AWS AWS の量子コンピューティングサービスである Amazon Braket で Rigetti Computingの最新の84量子ビット Ankaa-2 システムが利用可能になりました。現在、北カリフォルニアリージョンで利用可能です。Ankaa-2 は、Amazon Braket で使用できる中で量子ビット数が最も多いゲート方式の量子デバイスです。 Amazon QuickSight で、組み込みダッシュボードにおいてビューの共有がサポートされるようになりました – AWS Amazon QuickSight で、組み込みダッシュボードにおいてビューの共有がサポートされるようになりました。ビューの共有は、ダッシュボードにフィルタなどを設定した状態を他ユーザーに共有するための機能ですが、これが今回の機能追加で埋め込みダッシュボードでも利用可能になりました。 8/27(火) Amazon Q Business launches IAM federation for user identity authentication – AWS Amazon Q Business は 生成AIのアシスタントで、顧客の企業データに基づいて質問への回答や情報のサマリなどを提供するサービスです。今回の機能追加で、IDプロバイダー (IdP)に直接連携できるようになりました（以前はいったん AWS IAM Identity Center に同期する必要がありました）。OpenID Connect (OIDC) プロトコルと SAML2.0 プロトコルをサポートします。 AWS announces support for Microsoft Entra ID and Microsoft Intune on Amazon WorkSpaces Personal – AWS Amazon WorkSpaces Personal は Microsoft Entra ID と Intune をサポートするようになりました。これにより Microsoft Active Directory を必要とせずに、Entra ID と連携し、Intune に登録されている仮想デスクトップをプロビジョニングできます。引き続き Active Directory との連携も利用することが可能です。 Amazon EC2 status checks now support reachability health of attached EBS volumes – AWS Amazon EC2 ステータスチェックで、アタッチされている EBS ボリュームがアクセス可能か、I/O操作を完了できるかといった状況を監視できるようになりました。この新しいステータスチェックを使用すると、EBSの障害をすばやく検出できます。 Amazon Bedrock now supports cross-region inference – AWS 単一のAPIで複数の基盤モデルを選択できる、生成AIアプリケーションのためのフルマネージドサービス Amazon Bedrock にクロスリージョン推論が追加されました。複事前に定義されているリージョンセットを利用することで、プライマリリージョンのキャパシティーが不足している際にセカンダリリージョンにリクエストをルーティングする機能です。注意点もあるので詳細は こちらのブログ をご確認ください 8/28(水) Announcing AWS Parallel Computing Service – AWS 新しいサービス AWS Parallel Computing Service (AWS PCS) が利用可能になりました。これはHPC(ハイパフォーマンスコンピューティン)領域のサービスで、多くのコンピュートノードを使った並列演算を支援します。これまでOSSで AWS ParallelCluster というHPC支援のソフトウェアを提供していましたが、これにより運用管理が楽な選択肢が追加されました。東京リージョンでも利用可能です。詳細は こちらのブログ をご覧ください。 AWS Network Firewall introduces GeoIP Filtering to inspect traffic based on geographic location – AWS AWS Network Firewall で、VPCへのトラフィックの GeoIP フィルタリングをサポートしました。この機能を使うと、特定の国から送受信されるトラフィックをブロックすることが容易に実現可能になります。 AWS announces Amazon-provided contiguous IPv4 blocks – AWS Amazon VPC IP Address Manager (IPAM) を使用して Amazon が提供する連続した IPv4 ブロック (Amazon-provided contiguous IPv4 Block)をプロビジョニングできるようになりました。パブリックIPアドレスを連続したブロックで確保することで、ネットワークの管理が容易になります。費用については、 VPCの料金ページ を確認してください。 8/29(木) Amazon Bedrock Knowledge Bases now supports Llama 3.1 405B, 70B, and 8B – AWS Amazon Bedrock Knowledge Bases は基盤モデル (FM) を社内のデータソースに安全に接続してRAGを実現することができます。今回の発表で新たに、MetaのLlama 3.1 ファミリーの基盤モデル（405B、70B、8B）が利用可能になりました。Llama 3.1はMetaの次世代最先端モデルで、128,000トークン（約96,000語、192ページの資料）のコンテキスト長をサポートしています。 Amazon OpenSearch Service now supports Graviton3 (C7g, M7g, R7g, R7gd) instances – AWS Amazon OpenSearch Service で AWS Graviton3 インスタンスがサポートされました。これにより、Graviton2 ベースのインスタンスよりも最大で25%パフォーマンスが向上します。コンピューティング最適化インスタンス (C7g)、汎用インスタンス (M7g)、およびメモリ最適化インスタンス (R7g、R7gd) から選択が可能です。詳細は こちらのブログ をご覧ください。 Announcing Validation API for AWS Step Functions – AWS AWS Step Functions でワークフロー用の新しい Validation (検証) API が利用可能になりました。Validation APIを利用することで、ワークフローのチェックを実行でき、構文エラーをより早く発見できるようになります。 8/30(金) Organizational Units in AWS Control Tower can now contain up to 1,000 accounts – AWS AWS Control Tower で、最大 1,000 のアカウントを含む組織単位 (OU) を登録できるようになりました。これまでは300が最大でした。 Amazon Redshift Serverless now supports AWS PrivateLink – AWS Amazon Redshift Serverless が AWS PrivateLink経由のアクセスをサポートしました。PrivateLinkを利用すると、クライアントからRedshift ServerlessもしくはRedshift ServerlessのAPIへのアクセスがAWSネットワーク内の経路で行われるようになり、コンプライアンス要件への対応などが可能になります。 AWS Amplify introduces new function capabilities with scheduled cron jobs and streaming logs – AWS AWS Amplify に Cron ジョブとストリーミングログが追加されました。Cron Jobs を設定することで、サーバーレス関数を特定の間隔で実行するように構成できます。一方、ストリーミングログを使用すると、関数の実行ログをリアルタイムで可視化できるためより効果的に監視およびデバッグが可能になります。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

はじめに COVID – 19 のパンデミックにより、企業は急速に変化する顧客ニーズに対応できるよう、サプライチェーン戦略を再評価する必要に迫られました。従来の一方向的なプッシュ型やプル型在庫アプローチから、顧客需要に柔軟に対応できる、より複雑で動的なモデルへと移行しています。この急速に進化する環境下で、新しい技術を迅速に実験・検証する能力が、企業が競争に勝ち抜くための必須条件となっています。 企業は、需要計画プロセスを強化し、動的な顧客ニーズに生産を合わせるため、大規模言語モデル (LLM) と機械学習 (ML) に多額の投資を行っています。AWS Supply Chain の 需要予測機能 を活用すれば、高度な ML アルゴリズムを利用して 正確な予測 行うことができます。特に、 無料利用枠 を活用することで、本格的な導入前に、ビジネスプロセスへの適用可能性と価値実証実験 (PoV) を行うことができます。 新しいサプライチェーン技術の導入や大規模な変更を行う際の一般的なアプローチは、価値実証実験 (PoV) を実施することです。PoV では、本格導入に先立ち、ソリューションの機能的実現可能性、価値、投資対効果 (ROI) を実証することができます。これには、実際の利用体験、ユーザーフィードバックの収集、潜在的な課題の特定と是正、定義された目標に対する実測、データ主導の意思決定に促進する洞察の提供が含まれます。PoV はリスク軽減、投資の正当化、ビジネス目標との整合性確保に役立ち、戦略的な意思決定と継続的な改善を可能にする際の重要な役割を果たします。 このブログ投稿では、実際の PoV に基づいた 3 つのステップのプロセスを概説し、AWS Supply Chain Demand Planning の有効なスコープ設定と PoV の実施をサポートします。以下のような一般的な質問に対応しています。 PoV (価値実証実験) とは何で、何を提供するのか? サプライチェーン管理の PoV テンプレートやフレームワークはあるのか? サプライチェーン PoV の具体例はどのようなものか? 規範的なアプローチを記述することで、他の AWS Supply Chain 機能やそれを用いたプロセスを評価するために適用できる堅牢なフレームワークを提供し、あらゆるタイプの PoV を効果的に実施するための貴重な指針となります。 PoV のスコープを適切に設定する ソリューションの機能とパフォーマンスを正確に評価できるように、PoV のスコープを適切に設定することが不可欠です。このセクションでは、PoV のスコープを設定する際の推奨手順を概説し、AWS Supply Chain Demand Planning に関する PoV を実施する食品・消費財流通業者の例を示します。 ステップ 1 : PoV の成功基準を設定する 最初のステップは、PoV の成功をどのように測定するかを決めることです。これには、評価したいプロセスとパフォーマンス指標を特定することが含まれます。例えば、食品・消費財の流通業者は需要計画を評価したいと考えていたため、業界標準の需要計画精度指標である WAPE (加重絶対パーセンテージ誤差) や MAPE (平均絶対パーセント誤差) を使用しました。 MAPE は、予測手法の精度を評価するのに広く使われる統計的な指標です。予測値と実際の値との間の絶対パーセント誤差の平均を計算し、パーセンテージで表します。MAPE が低いほど予測精度が高いことを示します。需要計画や在庫管理では、MAPE が主要業績評価指標 (KPI) として一般的に使われ、さまざまな予測モデルや手法の精度を評価・比較したり、許容できる予測誤差の目標 (業界標準は通常 10% 以下) を設定したり、時間の経過に伴う予測精度を監視して改善が必要な分野を特定するのに役立ちます。MAPE の詳細については、AWS Supply Chain が予測精度をどのように改善したかについての Amazon Pharmacy の 事例 をご覧ください。 流通業者は、全体的なユーザー体験と、プロセスが簡素化され、処理時間と運用時間が短縮されたかどうかも評価しました。 ステップ 2 : 最適な製品ミックスを特定する 次に、PoV に含めたい製品または製品グループを特定します。これにより、さまざまな製品タイプと需要パターンにわたってソリューションの機能をうまく検証できます。価値の実証実験 (PoV) でテストする製品の選択は、解決しようとしている問題と、PoV の限界をテストする最も効果的な方法によって異なります。理想的には、PoV ですべての製品をカバーし、さまざまな製品と製品の組み合わせに全体の需要計画の有効性をテストできます。ただし、この方法では時間がかかり、多くのリソースを必要とし、複雑さが増します。より実用的で実現可能なアプローチは、製品をより小さなサブセットにグループ化することです。このサブセットは、利益率への寄与度、販売/消費率、またはこれらの要因の組み合わせなどの要因に基づくことができます。より大きなデータセットをテストするよりも、より小さなデータセットをテストする方が効果的で素早く実施できます。 この食品・消費財流通業者のお客様は、利益率と在庫回転率に基づいて製品を区分しました。彼らは以下の製品グループから PoV テストのサブセットを作成しました。 利益の 60 – 75% を占める高利益率の高回転商品 利益の 10 – 15% を占める中回転の低利益率商品 低回転または低速度の商品 ステップ 3 : 正しい在庫ロケーションを特定する PoV に含めたい在庫ロケーション、例えば配送センター、倉庫、流通拠点、店舗を決定します。ビジネスボリューム (高、中、低) 、オペレーショナルな重要性 (ティア A の顧客、ティア B の顧客をカバーするなど)、ステップ 2 で特定された製品ミックスなどの要因に基づいて、1～3 か所のロケーションを選ぶことをお勧めします。別の検討すべき変数は、顧客層の階層構造で、ボリュームやビジネスの重要性に基づいて広範な顧客層 (例えばティア A、ティア B) を分類している場合に有用です。お勧めのアプローチは、現在のビジネスプロセスの管理方法に基づいて PoV をモデル化することです。例えば、需要計画担当者が顧客クラスターごとに予測数値を調整している場合は、そのレベルでモデル化するのが適切でしょう。 これらの手順に従えば、ビジネスニーズに基づいて機能とパフォーマンスを正確に評価できるよう、PoV の範囲を効果的に設定できます。 結論と次のステップ 適切な範囲の PoV を実施することは、組織が新しいサプライチェーン技術やプロセスを本格的に導入する前に、その実現可能性と価値を検証するために不可欠です。本ブログ投稿で概説した 3 ステップのプロセスは、実際の顧客の PoV に基づいた規範的なアプローチを提供し、企業が AWS Supply Chain Demand Planning の機能とパフォーマンスを自社の特定の要件に照らして正確に評価できるようにしています。明確な成功基準を設定し、最適な製品ミックスを特定し、適切な在庫拠点を選択することで、組織はリスクを軽減し、投資を正当化し、ビジネス目標との整合性を確保することができます。この体系的なアプローチは、情報に基づいた意思決定を促進するだけでなく、急速に進化するサプライチェーン環境において競争優位性を確保し、継続的な改善への道を開くことにもなります。 AWS Supply Chain を始めるのは簡単で、事前のライセンス料や長期契約は必要ありません。以下の 3 ステップで始められます。 AWS Supply Chain について学ぶ: AWS Supply Chain の ウェブサイト を訪れ、製品の機能と能力を理解する。 技術的な概要を知る: AWS Workshop Studio でセルフペースの技術的なウォークスルーを探索する。インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成方法を学ぶ。 AWS Supply Chain を使い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導の管理ツールを使って、サプライチェーン運用を合理化する。詳細な設定手順と追加のガイダンスについては、 ユーザーガイド にアクセスできる。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は 17 年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン 500 企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。Vikram はノースダラス地域を拠点としています。 <!-- '"` -->

みなさん、こんにちは。アマゾン ウェブ サービス ジャパンのソリューションアーキテクト志村です。今回は 9 月 26 日 (木) に開催する AWS Innovate の情報をお届けします！ 2021 年以降、年に数回テーマを設けて開催している AWS Innovate 。2024 年 9 月 26 日に、モダナイゼーションにフォーカスした、 AWS Innovate – Migrate. Modernize. Build . を開催します。今話題の生成 AI をはじめとする最新テクノロジーを活用して組織やシステムをモダナイズしていくことは、ビジネス価値を生み出す前提条件です。今回は、モダナイゼーションの重要な側面である、「インフラ」「アプリ」「データと組織」の 3 つの切り口で、「最新のモダナイズ手法とそれを支えるテクノロジーを学ぶ」をテーマに、全 29 セッションをお届けします。これには、昨今、多くのお客様の課題となっている メインフレームや Db2、SAP、VMware といった既存の環境からのモダナイゼーションに関するベストプラクティス、コンテナ・サーバーレス・開発支援機能を活用したモダンアプリケーションの開発・運用プロセス、またデータの民主化を実現してビジネス価値につなげるためのやり方などが含まれます。AWS エキスパートのセッションに加え、実際にモダナイゼーションに取り組まれているお客様による事例紹介、またモダナイゼーションを加速するための生成 AI の活用方法についてもご紹介します。 モダナイゼーションで目指すべきもの DX (デジタルトランスフォーメーション) をはじめとしたモダナイゼーションに関わるキーワードが、一般的になってきています。この記事を読まれている皆さまも、デジタル技術を活用して自社の業務を変革したい、既存のシステムをより良いものにしたいと考えていらっしゃるのではないかと思います。こうした文脈において「モダナイゼーション」という言葉は非常に幅広い意味で使われていますが、モダナイゼーションの定義とその目的についてはどのようにお考えでしょうか？ これに対して単一の回答はおそらく存在しないと思いますが、「社会の変化に合わせてすばやく価値を提供し続けるために、組織やシステムを常に新しくしていく」ことが、間違いなく答えの一つとして挙げられます。昨今、社会の動きは非常に目まぐるしくなっていますし、生成 AI をはじめとした新しい技術によって人々の生活も大きく変わってきています。こうした変化へどのように迅速に適応していくかについて、重要性が増してきている状況です。ここでいう変化は単に IT システムだけの話にとどまらず、組織の構成やビジネスプロセスなども含まれます。 一つ例を挙げましょう。カメラにおけるアナログからデジタルへの変化です。従来のアナログカメラは、たとえば 100 枚のショットを現場で撮って、現像して、うまく撮れていなければ再度準備をし、もう一度現場で撮り直す必要がありました。しかしデジタルカメラの登場により、フィルム交換の必要なく、それこそ 10000 枚以上のショットを連続で撮ることができるようになりました。また現像の必要なく、撮った写真をその場で確認してベストショットを選び、さらに生成 AI を用いた加工処理で品質を高めることもできます。単にアナログからデジタルにテクノロジーが変わっただけでなく、その裏側には業務プロセスそのものの変化があり、それらが総合的に意思決定の加速化といったビジネス成果をもたらしているわけです。私たちは、こうした変化への適応を「モダナイゼーション」になぞらえることができると考えます。 モダナイゼーションの実践における課題 さてモダナイゼーションによって変化への適応を進めていこうといったところで、いざ実践となると、さまざまな壁があると思います。先ほどの例でみたように、変化への適応には新たなテクノロジーの活用だけでなく、組織のあり方やビジネスプロセスの見直しまでが含まれます。 たとえば以下のような点でお困りではないでしょうか？ オンプレミスの古い IT 環境で多くのシステムが塩漬けになっているままの状態が続いており、最新のインフラ環境を活用するといったことがまったくできていない。またこれらをどう移行していけばいいのかがわからない アプリケーションチームと IT 基盤チームが分断されており、アプリケーション側の要件を IT 基盤に反映させること、また逆に IT 基盤側の変更にアプリケーション側が対応することに時間を要する データが各部署に散在しており、サイロ化されている。部署ごとに取り組みをしていても、部署横断でのデータ活用ができておらず、仕組みもない こうした課題に対応していくためには、既存の仕組みをモダナイズするためのベストプラクティスを知ることが非常に大事です。AWS をご活用いただいている多くのお客さまがモダナイゼーションにすでに取り組まれており、具体的なツールの活用や実践方法などの知見が蓄積されています。またマネージドサービスや生成 AI を含む AWS の包括的なテクノロジーを活用することで、モダナイズを加速することも可能です。 AWS Innovate – Migrate. Modernize. Build. では、こうしたモダナイゼーションにおけるさまざまなベストプラクティスを、テーマごとにまとめました。次に見どころをご紹介します。 セッションと見どころの紹介 オープニングセッション まずオープニングセッションでは、ビジネスの差別化につなげていくためのモダナイズの目指すべき姿についてお話しします。さらにそのために必要な要素を整理してご説明した上で、それらを支える AWS のテクノロジーについてご紹介します。モダナイゼーションの全体像を知りたい方におすすめの内容となっています。 ブレイクアウトセッション ブレイクアウトセッションでは 3 つのトラックをご用意しました。 1 つ目は「インフラモダナイズ」をテーマに、メインフレームや Db2、SAP、VMware といった既存の環境からのモダナイゼーションに関するベストプラクティスを、生成 AI を含む具体的なテクノロジーの活用や進め方、コスト削減効果などとあわせてご紹介します。また、近鉄情報システム様によるメインフレームからクラウドへの移行、三菱電機様による IoT ソリューション開発組織での生成 AI 活用、リクルート様によるプラットフォームエンジニアリングに関するセッションをお届けします。 2 つ目は「アプリモダナイズ」というテーマで、モダンな開発プロセス・環境を目指している方に、次の日からすぐに活かしていただける内容をご紹介します。具体的には Web / モバイル領域からバックエンドサービス領域までのアプリケーションのモダンな開発プロセス・環境に寄与するテクノロジー群として、コンテナサービス、サーバーレス、開発支援機能を中心としたセッションをお届けします。また、山梨中央銀行様の内製化のお取り組み、ソフトバンク様のサーバーレスを活用したオンラインストアサービス向上のための施策、MonotaRO 様によるマイクロサービス化に向けたドメインモデリングといった実践例も必見です。 3 つ目は「データと組織のモダナイズ」というテーマで、生成 AI やさまざまな分析テクノロジーを活用して、データからインサイトを得てビジネス価値に繋げていくためのセッション、データの民主化に向けたデータガバナンスや、データパイプラインのような堅牢かつスケーラブルな基盤の構築にフォーカスしたセッションをご用意しました。さらに、カシオ計算機様によるデータドリブンでのビジネス変革の推進、マクロミル様によるCRM/CX 支援事業の課題解決方法、ビットバンク様による意思決定を高度化するためのモダンデータ基盤構築事例のご紹介も行います。 以上のように、テクノロジーのみならず人・組織やプロセスを含む幅広い観点からの、さまざまなベストプラクティスやお客さまによるお取り組みの事例をお届けします。皆さまの多くが困っていらっしゃるポイントや、モダナイゼーションを加速するための具体的な手法をお伝えし、持ち帰って実践いただけるコンテンツを取り揃えてお待ちしています。 当日のアジェンダはこちらです。 タイムテーブルを PDF で見る AWS Innovate – Migrate. Modernize. Build. をより楽しむために 最後になりますが、このブログを読んで興味を持っていただいた方は、ぜひ イベントページ からご登録ください。もちろん当日に視聴していただくことでも十分に楽しんでいただける内容ですが、興味のあるセッションがすでにある場合は、ぜひ実際に AWS のコンソール からサービスを立ち上げて触ってみていただけると、当日の理解が深まると思います。 さらに当日はライブ Q&amp;Aを実施し、みなさんからの質問をお待ちしています。この機会を活用して AWS への質問、不明点の解消などにお役立てください。 詳細・お申込みは こちら から みなさまのご参加をお待ちしています。 – ソリューションアーキテクト 志村

本ブログは「 Hardening the RAG chatbot architecture powered by Amazon Bedrock: Blueprint for secure design and anti-pattern mitigation 」を翻訳したものとなります。 本ブログでは、 Amazon Bedrock を詳細なセキュリティ計画とともに使用して、安全で責任あるチャットボットアプリケーションをデプロイする方法を示しています。また、アプリケーションで大規模言語モデル (LLM) を公開する際に発生する可能性のある一般的なセキュリティリスクとアンチパターンを特定します。Amazon Bedrock には、脆弱性を軽減し、安全な設計の原則を取り入れるために使用できる機能が組み込まれています。本ブログでは、LLM ベースのアプリケーションの信頼性を高めるためのアーキテクチャ上の考慮事項とベストプラクティス戦略に焦点を当てています。 Amazon Bedrock は生成 AI (人工知能) と LLM の融合を実現し、インパクトのあるチャットボットアプリケーションを作成できるようにします。機密データや知的財産を扱うテクノロジーと同様に、セキュリティを優先し、強固なセキュリティ態勢を採用することが重要です。適切な対策を講じないと、これらのアプリケーションはプロンプトインジェクション、情報の開示、モデルの悪用、規制違反などのリスクにさらされる可能性があります。これらのセキュリティ上の考慮事項に積極的に対処することで、 Amazon Bedrock 基盤モデル と生成 AI 機能を責任を持って使用できます。 チャットボットアプリケーションのユースケースは、組織が生成 AI 基盤モデル (FM) の力を利用して独自のアプリケーションを構築したいと考えているエンタープライズ環境によく見られるパターンです。これは、 生成 AI セキュリティスコーピングマトリックス の事前学習済みのモデルのカテゴリに分類されます。このスコープでは、組織は Amazon Bedrock API を介して Anthropic 社の Claude などの FM と直接統合し、カスタマーサポート、検索拡張生成 (RAG) チャットボット、コンテンツ生成ツール、意思決定支援システムなどのカスタムアプリケーションを作成します。 本ブログでは、Amazon Bedrock と統合するチャットボットアプリケーションをデプロイするための包括的なセキュリティブループリントを紹介します。これにより、エンタープライズ環境で LLM と生成 AI を責任を持って運用できるようになります。LLM と生成 AI 機能を統合する際の課題に合わせた安全な設計の原則、アーキテクチャ上の考慮事項、ベストプラクティスを通じて、緩和戦略の概要を説明します。 本ブログのガイダンスに従うことで、Amazon Bedrock と統合され、生成 AI モデルを使用するチャットボットアプリケーションのデプロイと運用に関連するリスクを積極的に特定して軽減できます。このガイダンスは、セキュリティ態勢の強化、機密データや知的財産の保護、規制コンプライアンスの維持、エンタープライズ環境への生成 AI 機能を責任を持ってデプロイするのに役立ちます。 本ブログには、次の大まかなセクションが含まれています。 チャットボットアプリケーションアーキテクチャの概要 包括的なロギングおよびモニタリング戦略 セキュリティアンチパターンと緩和戦略 アンチパターン 1: 安全な認証とアクセス制御の欠如 アンチパターン 2: 不十分な入力のサニタイズとバリデーション アンチパターン 3: 安全でない通信チャネル アンチパターン 4: 不適切なロギング、監査、否認防止 アンチパターン 5: 安全でないデータストレージとアクセス制御 アンチパターン 6: FM と生成 AIコンポーネントの安全性の欠如 アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如 アンチパターン 8: 包括的なテストと検証の欠如 アンチパターンの一般的な緩和戦略 安全で責任あるアーキテクチャブループリント チャットボットアプリケーションアーキテクチャの概要 本ブログで説明するチャットボットのアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock および Anthropic 社の Claude 3 Sonnet LLM と統合する実装例を示しています。このベースラインアーキテクチャは、コアコンポーネントとその相互作用を理解するための基礎となります。ただし、お客様が Amazon Bedrock と統合するチャットボットアーキテクチャを設計および実装するには、お客様固有の要件や制約に応じて複数の方法があることに注意してください。実装のアプローチにかかわらず、生成 AI アプリケーションの安全な設計とデプロイには、適切なセキュリティコントロールを組み込み、ベストプラクティスに従うことが重要です。 チャットボットアプリケーションを使用すると、ユーザーはフロントエンドインターフェースを介して対話し、プロンプトやクエリを送信できます。これらのプロンプトは、Amazon Bedrock と統合することで処理され、Anthropic 社の Claude 3 Sonnet LLM と取り込まれたデータから構築されたナレッジベースを使用します。LLM は、プロンプトとナレッジベースから取得したコンテキストに基づいて、関連する応答を生成します。このベースライン実装では中核となる機能を概説していますが、生成 AI アプリケーションの導入に関連する潜在的なリスクを軽減するには、セキュリティコントロールを組み込み、ベストプラクティスに従う必要があります。以降のセクションでは、このようなアプリケーションで発生する可能性のあるセキュリティアンチパターンと、それに対応する緩和戦略について説明します。さらに、Amazon Bedrock を搭載したチャットボットアプリケーションの安全で責任あるアーキテクチャブループリントも提示します。 図 1: AWS サービスと Amazon Bedrock を使用したベースラインチャットボットアプリケーションアーキテクチャ チャットボットアプリケーションベースラインアーキテクチャのコンポーネント チャットボットアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock サービスおよび Anthropic 社の Claude 3 Sonnet LLM と統合して、インタラクティブでインテリジェントなチャットボット体験を提供します。このアーキテクチャの主なコンポーネント (図 1 参照) は次のとおりです。 ユーザーインタラクションレイヤー: ユーザーは、 Streamlit フロントエンド(3)を通してチャットボットアプリケーションとやり取りします。Streamlitは、Python ベースのオープンソースライブラリで、ユーザーフレンドリーでインタラクティブなインターフェースを構築するために使用されています Amazon Elastic Container Service (Amazon ECS) on AWS Fargate : フルマネージドでスケーラブルなコンテナオーケストレーションサービスで、サーバーのプロビジョニングと管理が不要になり、基盤となるコンピューティングインフラストラクチャを管理しなくてもコンテナ化されたアプリケーションを実行できます アプリケーションのホスティングとデプロイ: Streamlit アプリケーション (3) のコンポーネントは AWS Fargate (2) 上の Amazon ECS にホストおよびデプロイされ、スケーラビリティと高可用性を維持しています。このアーキテクチャは、独立した仮想プライベートクラウド (VPC) 内のアプリケーションとホスティング環境を表し、疎結合アーキテクチャを促進します。Streamlit フロントエンドは組織固有のフロントエンドに置き換えることができ、VPC のバックエンド Amazon API Gateway とすばやく統合できます。アプリケーションロードバランサーは、Streamlit アプリケーションインスタンスにトラフィックを分散するために使用されます API Gateway 駆動での Lambda との統合: このサンプルアーキテクチャでは、フロントエンドから Amazon Bedrock サービスを直接呼び出す代わりに、 AWS Lambda 関数 (5) をバックエンドとした API Gateway が中間レイヤーとして使用されます。このアプローチは、フロントエンドからの直接的な露出を制限することで、懸念事項を分離し、スケーラビリティ、Amazon Bedrock への安全なアクセスを促進します Lambda: Lambda は、拡張性の高い短期的なサーバーレスコンピューティングを提供します。ここで、Streamlit からのリクエストが処理されます。まず、ユーザーのセッションの履歴が Amazon DynamoDB (6) から取得されます。次に、ユーザーの質問、履歴、コンテキストがプロンプトテンプレートにフォーマットされ、検索拡張生成 (RAG) を使用してナレッジベースで Amazon Bedrock に対してクエリされます DynamoDB: DynamoDB は、Lambda 関数を使用してチャット履歴、会話履歴、推奨事項、およびその他の関連データを保存および取得します Amazon S3: Amazon Simple Storage Services (Amazon S3) はデータストレージサービスで、ここではナレッジベースに取り込まれたデータアーティファクトを保存するために使用されます Amazon Bedrock: Amazon Bedrock はアーキテクチャにおいて中心的な役割を果たしています。Anthropic 社の Claude 3 Sonnet LLM (9) と、顧客の組織固有のデータから事前に生成された ナレッジベース (10) を組み合わせてユーザーから寄せられた質問を処理します Anthropic 社の Claude 3 Sonnet: Anthropic 社の Claude 3 Sonnet は、ユーザーの入力とナレッジベースから取得したコンテキストに基づいて、カスタマイズされた推奨事項と回答を生成するために使用される LLM です。これは Amazon Bedrock のテキスト分析および生成モジュールの一部です ナレッジベースとデータの取り込み: パブリックとして分類された関連ドキュメントは、Amazon S3 (9) から Amazon Bedrock ナレッジベースに取り込まれます。ナレッジベースは Amazon OpenSearch Service がバックエンドになっています。 Amazon Titan Embeddings (10) を使用して、ドキュメントのベクトルエンベディングデータベースが生成されます。データをベクトルエンベディングとして保存すると、ドキュメントの セマンティック検索や類似検索 が可能になり、ユーザーが提起した質問のコンテキストを取得できます (RAG)。質問に加えてコンテキストを LLM に提供することで、LLM から有用な回答を得る可能性がはるかに高くなります。 包括的なロギングおよびモニタリング戦略 このセクションでは、Amazon Bedrock を搭載したチャットボットアプリケーションの包括的なロギングおよびモニタリング戦略の概要を説明します。さまざまな AWS サービスを使用して、セキュリティイベント、パフォーマンスメトリックス、および潜在的な脅威の一元的なロギング、監査、およびプロアクティブなモニタリングを可能にします。 ロギングと監査: AWS CloudTrail : InvokeModel リクエストを含む Amazon Bedrock に対して行われた API 呼び出しと、リクエストを行ったユーザーまたはサービスに関する情報を記録します AWS CloudWatch&nbsp;Logs : Amazon Bedrock の呼び出しログ、ユーザープロンプト、生成されたレスポンス、呼び出しプロセス中に発生したエラーまたは警告をキャプチャして分析します Amazon OpenSearch Service : OpenSearch の統合、コンテキストデータの取得、ナレッジベースのオペレーションに関連するデータをログ記録し、またインデックス化します AWS Config : IAM ポリシー、VPC 設定、暗号化キー管理、その他のリソース設定を含む、チャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの設定をモニタリングおよび監査します モニタリングとアラート: AWS CloudWatch: モデル呼び出しの数、呼び出しのレイテンシー、エラーメトリクス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングします。Bedrock の呼び出しとパフォーマンスに関連する異常や問題を事前に検出して対応できるように、対象を絞った CloudWatch アラームを設定します AWS GuardDuty : CloudTrail のログを継続的にモニタリングして、AWS 環境内の潜在的な脅威や不正なアクティビティがないかどうかを確認します AWS Security Hub : セキュリティポスチャ管理とコンプライアンスチェックを一元化します Amazon Security Lake : ログ分析のための一元化されたデータレイクを提供します。CloudTrail およびSecurity Hub と統合されています セキュリティ情報とイベント管理の統合: セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合することで、ログの一元管理、セキュリティイベントのリアルタイムモニタリング、複数のソース (CloudTrail、CloudWatch Logs、OpenSearch Service など) からのロギングデータの関連付けを行うことができます 継続的な改善: 新たな脅威、アプリケーション要件の変化、または進化するベストプラクティスに対処するために、ロギングとモニタリングの設定、アラートの閾値、セキュリティソリューションとの統合を定期的に見直して更新します セキュリティアンチパターンと緩和戦略 このセクションでは、Amazon Bedrock チャットボットアプリケーションアーキテクチャに関連する一般的なセキュリティ上のアンチパターンを特定して説明します。開発段階とデプロイ段階の早い段階でこれらのアンチパターンを認識することで、効果的な緩和戦略を実施し、セキュリティ態勢を強化することができます。 Amazon Bedrock チャットボットアプリケーションアーキテクチャのセキュリティアンチパターンに対処することが重要である理由はいくつかあります。 データ保護とプライバシー: チャットボットアプリケーションは、個人情報、知的財産、ビジネス上の機密データなどのセンシティブなデータを処理して生成します。セキュリティアンチパターンに対処しないと、データ侵害、不正アクセス、および潜在的な規制違反につながる可能性があります モデルの完全性と信頼性: チャットボットアプリケーションの脆弱性により、不正なアクターが基盤となる生成 AI モデルを操作または悪用できるようになり、生成された出力の完全性と信頼性が損なわれる可能性があります。これは、特に意思決定の支援や重要なアプリケーションにおいて、深刻な結果をもたらす可能性があります 責任ある AI の導入: 生成 AI モデルの運用が増え続ける中、責任ある倫理的な導入のプラクティスを維持することが不可欠です。AI モデルを利用したチャットボットアプリケーションの信頼性、透明性、説明責任を維持するには、セキュリティアンチパターンに対処することが不可欠です コンプライアンスおよび規制要件: 多くの業界や地域には、AI 技術の使用、データプライバシー、情報セキュリティに関する特定の規制やガイドラインがあります。セキュリティアンチパターンに対処することは、チャットボットアプリケーションのコンプライアンスを順守し維持するための重要なステップです 本ブログで取り上げるセキュリティアンチパターンには次のものがあります。 安全な認証とアクセス制御の欠如 不十分な入力のサニタイズとバリデーション 安全でない通信チャネル 不適切なロギング、監査、否認防止 安全でないデータストレージとアクセス制御 FM と生成 AIコンポーネントの安全性の欠如 責任ある AI ガバナンスと倫理の欠如 包括的なテストと検証の欠如 アンチパターン 1: 安全な認証とアクセス制御の欠如 Amazon Bedrock を使用する生成 AI チャットボットアプリケーションでは、安全な認証とアクセス制御がないと、システムの機密性、完全性、可用性に重大なリスクが生じます。ID スプーフィングや不正アクセスにより、脅威アクターが正当なユーザーやシステムになりすましたり、チャットボットアプリケーションで処理された機密データに不正にアクセスしたり、アプリケーションで使用される顧客のデータや知的財産の完全性と機密性を侵害したりする可能性があります。 チャットボットアプリケーションは、機密情報や知的財産を含む可能性のあるユーザーのプロンプトや応答を処理するため、ID スプーフィングと不正アクセスはこのアーキテクチャで対処すべき重要な領域です。脅威アクターが正当なユーザーまたはシステムになりすますことができれば、悪意のあるプロンプトを挿入したり、ナレッジベースから機密データを取得したり、Amazon Bedrock と統合された Anthropic Claude 3 LLM によって生成された応答を操作したりする可能性があります。 アンチパターンの例 Streamlit のフロントエンドインターフェースまたは API Gateway エンドポイントを適切な認証メカニズムなしで公開すると、認証されていないユーザーがチャットボットアプリケーションと対話し、悪意のあるプロンプトを挿入できる可能性があります AWS アクセスキーまたは API 認証情報をアプリケーションコードまたは設定ファイルに保存またはハードコーディングすると、認証情報が公開されたり、Amazon Bedrock や DynamoDB などの AWS サービスへの不正アクセスのリスクが高まります Amazon Bedrock サービスやその他の重要なコンポーネントにアクセスするための上位権限を持つ管理者アカウントまたはサービスアカウントに、弱い、または推測しやすいパスワードを実装します AWS Identity and Access Management (IAM) ユーザーまたは権限のあるロールには多要素認証 (MFA) がないため、認証情報が漏洩した場合に Amazon Bedrock サービスを含む AWS リソースへの不正アクセスのリスクが高まります 緩和戦略 安全な認証とアクセス制御の欠如に関連するリスクを軽減するには、堅牢な IAM コントロールのほか、継続的なロギング、モニタリング、脅威検出メカニズムを実装してください。 IAM コントロール: OAuth 2.0 や OpenID Connect などの業界標準のプロトコルを使用し、 AWS IAM Identity Center やその他のアイデンティティプロバイダーと統合することで、Streamlit フロントエンドインターフェースと AWS API Gateway エンドポイントの認証と認可を一元的に行うことができます AWS IAM ポリシーとリソースベースのポリシー を使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、Lambda 関数、およびチャットボットアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限します Amazon Bedrock、DynamoDB、Streamlit アプリケーションなどの重要なコンポーネントにアクセスできるすべての IAM ユーザー、ロール、およびサービスアカウントに MFA の使用を強制します 継続的なロギングとモニタリング、脅威の検出: 一元的なロギングおよびモニタリングソリューションの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。またチャットボットアプリケーションコンポーネントと Amazon Bedrock サービス全体にわたる認証イベント、アクセス試行、潜在的な不正アクセスまたは認証情報の不正使用を追跡および監査するとともに、CloudWatch、Lambda、GuardDuty を使用して異常な動作や潜在的な脅威を検出して対応します アンチパターン 2: 不十分な入力のサニタイズとバリデーション 生成 AI チャットボットアプリケーションの入力バリデーションとサニタイズが不十分だと、インジェクションイベント、データ改ざん、敵対的イベント、データ汚染イベントなど、さまざまな脅威にシステムがさらされる可能性があります。これらの脆弱性は、不正アクセス、データ改ざん、モデル出力の侵害につながる可能性があります。 インジェクションイベント: ユーザーのプロンプトや入力が適切にサニタイズおよびバリデーションされていない場合、脅威アクターは SQL コードなどの悪意のあるコードを注入して、DynamoDB チャット履歴データへの不正アクセスや操作を引き起こす可能性があります。さらに、チャットボットアプリケーションまたはコンポーネントが適切なバリデーションなしにユーザー入力を処理すると、脅威アクターがバックエンドシステムに任意のコードを注入して実行し、アプリケーション全体を危険にさらす可能性があります データ改ざん: 脅威アクターは、チャットボットインターフェースと Amazon Bedrock サービスの間で送信されるユーザープロンプトやペイロードを変更し、意図しないモデル応答やアクションを引き起こす可能性があります。データの完全性チェックを行わないと、脅威アクターが Amazon Bedrock と OpenSearch の間で交換されるコンテキストデータを改ざんし、LLM の応答に影響する誤った検索結果や悪意のある検索結果につながる可能性があります データ汚染イベント: LLM またはチャットボットアプリケーションで使用されるトレーニングデータまたはコンテキストデータが適切にバリデーションおよびサニタイズされていない場合、不正なアクターが悪意のあるデータや誤解を招くデータを導入し、偏ったモデル出力や侵害されたモデル出力につながる可能性があります アンチパターンの例 Amazon Bedrock に送信する前にユーザープロンプトのバリデーションとサニタイズに失敗すると、インジェクションイベントが発生したり、意図しないデータ漏洩が発生したりする可能性があります OpenSearch から取得したコンテキストデータの入力バリデーションとサニタイズが行われていないため、不正なデータや悪意のあるデータが LLM の応答に影響を与える可能性があります LLM が生成した応答をユーザーに表示する前にサニタイズが不十分なため、コードインジェクションや有害なコンテンツのレンダリングが発生する可能性があります Streamlit アプリケーションまたは Lambda 関数でのユーザー入力の不適切なサニタイズにより、特殊文字、コードスニペット、または潜在的に悪意のあるパターンを削除またはエスケープできず、コードインジェクションイベントが発生する可能性があります LLM またはチャットボットアプリケーションで使用されるトレーニングデータやその他のデータソースの検証とサニタイズが不十分なため、データ汚染イベントが発生し、悪意のあるデータや誤解を招くデータが取り込まれ、偏ったモデル出力や侵害されたモデル出力につながる可能性があります ユーザープロンプトやデータ入力に無制限の文字セット、入力長、特殊文字を使用できるようにすることで、攻撃者が入力バリデーションやサニタイズのメカニズムを迂回する入力を作成できるようになり、望ましくない出力や悪意のある出力が発生する可能性があります 入力のバリデーションは拒否リストのみに頼っているため、攻撃者はこれをすばやく回避できるため、インジェクションイベント、データ改ざん、その他の悪用シナリオにつながる可能性があります 緩和戦略 不十分な入力のサニタイズとバリデーションに関連するリスクを軽減するには、チャットボットアプリケーションとそのコンポーネント全体に堅牢な入力バリデーションとサニタイズのメカニズムを実装してください。 入力のバリデーションとサニタイズ: チャットボットインターフェースと Amazon Bedrock サービスの境界でユーザープロンプトの厳格な入力バリデーションルールを実装し、許可される文字セットと最大入力長を定義し、特殊文字やコードスニペットを禁止します。 Amazon Bedrock のガードレール 機能を使用すると、拒否トピックとコンテンツフィルタを定義して、アプリケーションとのユーザー操作から望ましくない有害なコンテンツを削除できます より堅牢で包括的なアプローチを維持するには、入力バリデーションに拒否リストの代わりに許可リストを使用してください 特殊文字、コードスニペット、または潜在的に悪質なパターンを削除またはエスケープすることで、ユーザー入力をサニタイズします データフロー検証: 以下を含むコンポーネント間のデータフローの検証とサニタイズを行います FM に送信されたユーザープロンプトと、FM によって生成されてチャットボットインターフェースに返された応答 FM またはチャットボットアプリケーションで使用されるトレーニングデータ、コンテキストデータ、およびその他のデータソース 保護コントロール: AWS WAF を使用して、入力のバリデーションと一般的なウェブエクスプロイトから保護します AWS Shield を使用して、分散型サービス拒否 (DDoS) イベントから保護します CloudTrail を使用して、InvokeModel リクエストを含む Amazon Bedrock への API 呼び出しをモニタリングできます CloudTrail ログを分析し、アプリケーションログ、ユーザープロンプト、応答を取り込み、インシデントレスポンスや SIEM ソリューションとの統合を行うための Lambda 関数、 Amazon EventBridge ルール、CloudWatch Logs の実装に関するガイダンスについては、包括的なロギングおよびモニタリング戦略のセクションをご覧ください。入力のバリデーションとサニタイズ、ジェイルブレイクの試行や異常な動作に関連するセキュリティインシデントの検出、調査、緩和に役立ちます アンチパターン 3: 安全でない通信チャネル チャットボットアプリケーションコンポーネント間の安全でない通信チャネルは、機密データを傍受、改ざん、不正アクセスのリスクにさらす可能性があります。セキュリティで保護されていないチャネルでは、攻撃者が送信中のデータ (ユーザープロンプト、応答、コンテキストデータなど) を傍受して変更する中間者イベントが発生し、データの改ざん、悪意のあるペイロードの注入、不正な情報アクセスにつながります。 アンチパターンの例 VPC 内の安全なサービス間通信のために AWS PrivateLink を使用しないと、HTTPS を使用している場合でも、Amazon Bedrock と他の AWS サービスとの間の通信がパブリックインターネットを介した潜在的なリスクにさらされます コンポーネント間の転送中のデータ改ざんを検出および防止するためのデータ完全性チェックまたはメカニズムがない 新たな脅威に対処し、セキュリティのベストプラクティスに準拠していることを確認するために、通信チャネルの構成、プロトコル、および暗号化メカニズムを定期的に見直して更新していない 緩和戦略 安全でない通信チャネルに関連するリスクを軽減するには、安全な通信メカニズムを実装し、チャットボットアプリケーションのコンポーネントとその相互作用全体でデータの完全性を強化する必要があります。転送中の機密データを保護し、不正アクセス、データ改ざん、中間者攻撃を防ぐために、適切な暗号化、認証、および完全性チェックを実施する必要があります。 安全な通信チャネル: PrivateLink を使用すると、Amazon Bedrock とチャットボットアプリケーションアーキテクチャで使用される他の AWS サービスとの間の安全なサービス間通信が可能になります。PrivateLink は、Amazon VPC 内にプライベートで分離された通信チャネルを提供するため、パブリックインターネットを経由する必要がありません。これにより、HTTPS を使用している場合でも、サービス間で送信される機密データへの傍受、改ざん、または不正アクセスの可能性が軽減されます AWS Certificate Manager (ACM) を使用して、チャットボットのフロントエンドインターフェース (Streamlit アプリケーション) と API Gateway エンドポイント間の安全な通信に使用される SSL/TLS 証明書のデプロイを管理および自動化します。ACM は SSL/TLS 証明書のプロビジョニング、更新、デプロイを簡素化し、ユーザー向けコンポーネントとバックエンド API 間の通信チャネルが、業界標準のプロトコルと最新の証明書を使用して安全に暗号化されるようにします 継続的なロギングとモニタリング: 潜在的な通信チャネルの異常やセキュリティインシデントを検出して対応するための一元的なロギングおよびモニタリングメカニズムの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには CloudWatch、CloudTrail、AWS WAF などの AWS サービスを使用して、通信チャネルメトリクス、API 呼び出しパターン、リクエストペイロード、およびレスポンスデータをモニタリングすることも含まれます ネットワークのセグメンテーションと分離のコントロール: 専用の VPC とサブネット内に Amazon ECS クラスターをデプロイし、他のコンポーネントから分離し、最小権限の原則に基づいて通信を制限することにより、ネットワークセグメンテーションを実装します パブリック向けのフロントエンド層とバックエンドアプリケーション層用に VPC 内に個別のサブネットを作成し、コンポーネントをさらに分離します AWS セキュリティグループとネットワークアクセスコントロールリスト (NACL) を使用して、ECS クラスターとフロントエンドインスタンスのインバウンドトラフィックとアウトバウンドトラフィックをそれぞれインスタンスレベルとサブネットレベルで制御します アンチパターン 4: 不適切なロギング、監査、否認防止 生成 AI チャットボットアプリケーションのロギング、監査、否認防止のメカニズムが不十分だと、説明責任の欠如、フォレンジック分析の課題、コンプライアンス上の懸念など、さまざまなリスクにつながる可能性があります。適切なロギングと監査がなければ、ユーザーアクティビティの追跡、問題の診断、セキュリティインシデントの際のフォレンジック分析の実施、規制や内部ポリシーの遵守の証明が困難になります。 アンチパターンの例 Amazon Bedrock に送信されたユーザープロンプト、OpenSearch と交換されるコンテキストデータ、LLM からの応答など、コンポーネント間のデータフローのログ記録が不足しているため、セキュリティインシデントやデータ侵害が発生した場合の調査が妨げられます チャットボットアプリケーション内のユーザーアクティビティ(ログイン試行、セッション時間、実行されたアクションなど) のロギングが不十分なため、特定のユーザーを追跡してアクションを関連付ける機能が制限されます ログに記録されたデータの完全性と信頼性を保証するメカニズムがないため、記録されたイベントが改ざんされたり否認されたりする可能性があります ログデータを安全に保管し、不正アクセスや改ざんから保護できないため、ログ情報の信頼性と機密性が損なわれます 緩和戦略 不適切なロギング、監査、否認防止に関連するリスクを軽減するには、包括的なロギングおよび監査メカニズムを実装して、チャットボットアプリケーションコンポーネント全体の重大なイベント、ユーザーアクティビティ、およびデータフローをキャプチャします。さらに、ログデータの完全性と信頼性を維持し、改ざんや否認を防止し、ログ情報を安全に保管して不正アクセスから保護するための対策を講じる必要があります。 包括的なロギングと監査: CloudTrail、CloudWatch Logs、OpenSearch Service を使用してロギングメカニズムを実装するための詳細なガイダンスについては、「包括的なロギングとモニタリングの戦略」セクションを参照してください。また、CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API の呼び出しや AWS 環境内のその他の API アクティビティのロギングとモニタリングを行います。CloudWatch を使用して Amazon Bedrock 固有のメトリックスをモニタリングします。また、CloudTrail ログファイルの整合性検証機能と Amazon S3 に保存されているログデータの S3 オブジェクトロックと S3 バージョニングの実装により、ログデータの完全性と否認防止を確保します 保存中の暗号化には AWS Key Management Service (AWS KMS) を使用し、ログデータへのアクセスを制御するための制限的な IAM ポリシーとリソースベースのポリシーを実装することで、ログデータが安全に保存され、不正アクセスから保護されていることを確認してください CloudTrail ログファイルの整合性検証と CloudWatch Logs の保持期間とデータアーカイブ機能を使用して、コンプライアンス要件に基づいて適切な期間ログデータを保持します ユーザーアクティビティのモニタリングと追跡: CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API 呼び出しや AWS 環境内のその他の API アクティビティ (API Gateway、Lambda、DynamoDB など) のロギングとモニタリングを行います。さらに、CloudWatch を使用して、モデル呼び出しの数、レイテンシー、エラーメトリックス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングできます セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合して、一元的なログ管理とセキュリティイベントのリアルタイムモニタリングを行います データの完全性と否認防止: デジタル署名または否認防止メカニズムを実装して、記録されたデータの完全性と信頼性を検証し、記録されたイベントの改ざんや否認を最小限に抑えます。CloudTrail ログファイルの整合性検証機能を使用すると、業界標準のアルゴリズム (ハッシュには SHA-256、デジタル署名には SHA-256、デジタル署名には SHA-256 と RSA) を使用して否認防止を行い、ログデータの整合性を検証できます。Amazon S3 に保存されているログデータについては、S3 オブジェクトロックと S3 バージョニングを有効にし、変更不可能な Write Once Read Many (WORM) データストレージモデルを実現することで、オブジェクトの削除や変更を防ぎ、データの完全性と否認防止を維持できます。さらに、S3 バケットポリシーと IAM ポリシーを実装して、S3 に保存されているログデータへのアクセスを制限することで、ログに記録されたイベントのセキュリティと否認防止をさらに強化します アンチパターン 5: 安全でないデータストレージとアクセス制御 生成 AI チャットボットアプリケーションにおける安全でないデータストレージとアクセス制御は、情報開示、データ改ざん、不正アクセスなどの重大なリスクにつながる可能性があります。チャット履歴などの機密データを暗号化されていない、または安全でない方法で保存すると、データストアが侵害されたり、権限のないエンティティによってアクセスされた場合に情報漏えいが発生する可能性があります。さらに、適切なアクセス制御が行われていないと、権限のない第三者がデータにアクセス、変更、または削除できるようになり、データが改ざんされたり、不正アクセスされたりする可能性があります。 アンチパターンの例 AWS KMS カスタマー管理キー (CMK) を使用してチャット履歴データを暗号化せずに DynamoDB に保存します OpenSearch、Amazon S3、または機密データを処理するその他のコンポーネントのデータに対する、AWS KMS の CMK を使用した保存時の暗号化の不足 DynamoDB のチャット履歴、OpenSearch、Amazon S3、またはその他のデータストアに対する過度に寛容なアクセス制御や、きめ細かなアクセス制御メカニズムの欠如により、不正アクセスやデータ侵害のリスクが高まります 機密データをクリアテキストで保存するか、安全でない暗号化アルゴリズムや鍵管理手法を使用する 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化キーを定期的に確認してローテーションしたり、アクセス制御ポリシーを更新したりしていない 緩和戦略 安全でないデータストレージとアクセス制御に関連するリスクを軽減するには、強固な暗号化メカニズム、安全な鍵管理手法、きめ細かなアクセス制御ポリシーを実装してください。保存中および転送中の機密データを暗号化し、AWS KMS のお客様が管理する暗号化キーを使用し、IAM ポリシーとリソースベースのポリシーに基づいて最小権限のアクセス制御を実装することで、チャットボットアプリケーションアーキテクチャ内のデータのセキュリティと保護を大幅に強化できます。 保存時の鍵管理と暗号化: AWS KMS を実装して、DynamoDB、OpenSearch、Amazon S3 などのコンポーネント間のデータ暗号化のための CMK へのアクセスを管理および制御します CMK を使用して、保存中のチャット履歴データを自動的に暗号化するように DynamoDB を設定します OpenSearch と Amazon S3 が、これらのサービスに保存されているデータについて AWS KMS CMK で保存時に暗号化を使用するように設定します CMK ではセキュリティと制御が強化され、暗号化キーの作成、ローテーション、無効化、取り消しが可能になり、キーの分離と職務の分離が容易になります CMK を使用すると、キーポリシーを適用したり、キーの使用状況を監査したり、顧客による暗号化キーの管理を義務付ける規制要件や組織のポリシーを順守したりできます CMK は移植性が高く、特定のサービスから独立しているため、暗号化キーの管理を維持しながら、複数のサービス間でデータを移行または統合できます AWS KMS は、一元化された安全なキー管理ソリューションを提供し、さまざまなコンポーネントやサービスにわたる暗号化キーの管理と監査を簡素化します 以下を含む安全な鍵管理手法を実装します 暗号化されたデータのセキュリティを維持するための定期的なキーローテーション 特定の個人が主要な管理業務を完全に制御できないようにするための職務分離 キー管理操作の厳格なアクセス制御。IAM ポリシーとロールを使用して最小権限の原則を適用します きめ細かなアクセス制御: IAM ポリシーとロールを使用して、DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、およびその他のデータストアへのきめ細かなアクセス制御を実装します DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、その他のデータストアやサービスなど、機密データを処理するすべてのリソースに対して、きめ細かなアクセス制御を実装し、最小権限のアクセスポリシーを定義します。たとえば、IAM ポリシーとリソースベースのポリシーを使用して、特定の DynamoDB テーブル、OpenSearch ドメイン、S3 バケットへのアクセスを制限し、最小権限の原則に基づいて必要なアクション (読み取り、書き込み、一覧表示など) のみへのアクセスを制限します。このアプローチをチャットボットアプリケーションアーキテクチャ内の機密データを処理するすべてのリソースに拡張し、各コンポーネントまたはユーザーロールに最低限必要なリソースとアクションにのみアクセスが付与されるようにします 継続的な改善: 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化構成、アクセス制御ポリシー、およびキー管理方法を定期的に見直して更新してください アンチパターン 6: FM と生成 AI コンポーネントの安全性の欠如 チャットボットアプリケーションの FM や生成 AI コンポーネントに対するセキュリティ対策が不十分だと、モデルの改ざん、意図しない情報開示、サービス拒否などの深刻なリスクにつながる可能性があります。脅威アクターは、セキュリティで保護されていない FM や生成 AI モデルを操作して、偏った、有害な、または悪意のある応答を生成し、重大な損害や評判の低下を引き起こす可能性があります。 適切なアクセス制御や入力バリデーションを行わないと、意図しない情報漏えいが発生し、機密データが誤ってモデル応答に含まれてしまう可能性があります。さらに、安全でない FM または生成 AI コンポーネントは、サービス拒否イベントに対して脆弱であり、チャットボットアプリケーションの可用性を妨げ、その機能に影響を与える可能性があります。 アンチパターンの例 信頼できないデータソースや侵害されたデータソースを使用するなど、安全でないモデルのファインチューニング手法は、偏ったモデルや悪意のあるモデルにつながる可能性があります FM および生成 AI コンポーネントを継続的にモニタリングできないため、新たな脅威や既知の脆弱性に対して脆弱なままになっています FM や生成 AI コンポーネントの出力を制御およびフィルタリングするためのガードレールや安全対策がないため、有害な、偏った、または望ましくないコンテンツが生成される可能性があります FM コンポーネントに送信されるプロンプトやコンテキストデータのアクセス制御や入力バリデーションが不十分なため、インジェクションイベントや意図しない情報開示のリスクが高まります 安全な通信チャネル、モデルアーティファクトの暗号化、アクセス制御など、FM および生成 AI コンポーネントの安全なデプロイプラクティスの実装の欠如 緩和戦略 保護が不十分な FM と生成 AI コンポーネントに関連するリスクを軽減するには、安全な統合メカニズム、堅牢なモデルのファインチューニングとデプロイ手法、継続的なモニタリング、効果的なガードレールと安全対策を実施する必要があります。これらの緩和戦略は、チャットボットアプリケーションの生成 AI 機能のセキュリティ、信頼性、倫理的な整合性を確保しながら、モデルの改ざん、意図しない情報開示、サービス拒否イベント、有害または望ましくないコンテンツの生成を防ぐのに役立ちます。 LLM とナレッジベースとの安全な統合: Amazon Bedrock、OpenSearch、および FM コンポーネント間に安全な通信チャネル (HTTPS や PrivateLink など) を実装して、不正アクセスやデータ改ざんを防止してください インジェクションイベントや意図しない情報漏洩を防ぐために、FM コンポーネントに送信されるプロンプトとコンテキストデータには厳格な入力バリデーションとサニタイズを実装してください OpenSearch と統合するためにアクセス制御と最小権限の原則を実装して、LLM コンポーネントがアクセスできるデータを制限します 安全なモデルのファインチューニング、デプロイ、モニタリング: 信頼できる検証済みのデータソースを使用して、安全で監査可能なファインチューニングパイプラインを確立し、改ざんやバイアスの導入を防止します アクセス制御、安全な通信チャネル、モデルアーティファクトの暗号化など、FM および生成 AI コンポーネントの安全なデプロイプラクティスを実装します FM および生成 AI コンポーネントを継続的にモニタリングして、セキュリティの脆弱性、パフォーマンスの問題、意図しない動作がないかどうかを確認します レート制限、スロットリング、および負荷分散メカニズムを実装して、FM および生成 AI コンポーネントでのサービス拒否イベントを防止します セキュリティポリシー、業界のベストプラクティス、規制要件への準拠について、FM と生成 AI コンポーネントを定期的に見直し、監査します ガードレールと安全対策 ガードレールを導入しましょう。ガードレールとは、有害なアウトプットを減らし、FM や生成 AI コンポーネントの動作を人間の価値と調和させることを目的とした安全対策です キーワードベースのフィルタリング、メトリックベースのしきい値、人的モニタリング、各アプリケーションドメインの特定のリスクと文化的および倫理的規範に合わせたカスタマイズされたガードレールを使用してください パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングします ジェイルブレイクに対する堅牢性テスト ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如 これまでのアンチパターンは技術的なセキュリティ面に焦点を当てていましたが、生成 AI システムの倫理的かつ責任あるガバナンスに取り組むことも同様に重要です。強力なガバナンスの枠組み、倫理的ガイドライン、アカウンタビリティ対策がなければ、チャットボットアプリケーションは意図しない結果や偏った結果、透明性と信頼性の欠如につながる可能性があります。 アンチパターンの例 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導く原則、ポリシー、プロセスを含む、確立された倫理的なAI ガバナンスフレームワークの欠如 LLM と生成 AI コンポーネントの透明性、説明可能性、解釈可能性を確保するための対策が不十分なため、意思決定プロセスの理解と監査が困難になっています 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムがないため、チャットボットアプリケーションに対する信頼が失われ受け入れられなくなる可能性があります 生成 AI システムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処できない チャットボットアプリケーションの倫理的行動や組織の価値観や社会規範との整合性をテスト、検証、継続的なモニタリングを行うためのプロセスが不十分 緩和戦略 責任ある AI ガバナンスと倫理の欠如を最小限に抑えるために、包括的な倫理的 AI ガバナンスの枠組みを確立し、透明性と解釈可能性を促進し、利害関係者を関与させて社会的影響を考慮し、潜在的なバイアスや公平性の問題に対処し、継続的な改善とモニタリングプロセスを実施し、ガードレールと安全対策を講じます。これらの緩和戦略は、生成 AI チャットボットアプリケーションの開発と導入における信頼、説明責任、倫理的連携を促進するのに役立ち、意図しない結果、偏った結果、透明性の欠如などのリスクを軽減します。 倫理的な AI ガバナンスの枠組み: 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導くための原則、ポリシー、プロセスを含む、倫理的な AI ガバナンスの枠組みを確立します 潜在的な倫理的ジレンマ、バイアス、または意図しない結果に対処するための明確な倫理ガイドラインと意思決定の枠組みを定義します チャットボットアプリケーションの倫理的な開発とデプロイを監督するために、指定された倫理委員会、倫理責任者、外部諮問委員会などのアカウンタビリティ措置を実施します 透明性と解釈可能性: LLM と生成 AI コンポーネントの透明性と解釈可能性を促進するための対策を実施し、意思決定プロセスの監査と理解を可能にする。 チャットボットアプリケーションの機能、制限、潜在的なバイアスや倫理的考慮事項について、利害関係者やユーザーに明確でアクセスしやすい情報を提供します 利害関係者の関与と社会的影響: 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムを確立し、チャットボットアプリケーションの信頼と受け入れを促進します 影響評価を実施して、個人、地域社会、または社会に対する潜在的な悪影響またはリスクを特定し、軽減する バイアスと公平性: 厳格なテスト、バイアスの軽減手法、継続的なモニタリングを通じて、生成 AIシステムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処します 潜在的なバイアスや盲点を減らすために、開発、テスト、ガバナンスのプロセスにおいて多様性と包括性のある表現を促進します 継続的な改善とモニタリング: チャットボットアプリケーションの動作と組織の価値観や社会規範との整合性を継続的にテスト、検証、モニタリングするためのプロセスを実装します 新たな倫理的課題、社会的期待、規制の進展に対応するために、AI ガバナンスの枠組み、ポリシー、プロセスを定期的に見直し、更新します ガードレールと安全対策: (訳者注: 日本語でアプリケーションを利用される場合、ユーザーガイドを参照の上日本語がサポートされているか事前にご確認下さい) Guardrails for Amazon Bedrock などのガードレールを導入します。これは、有害なアウトプットを減らし、LLM や生成 AI コンポーネントの動作を人間の価値観や責任ある AI ポリシーと一致させることを目的とした安全対策です Guardrails for Amazon Bedrock を使用して拒否トピックを定義し、コンテンツフィルターを使用してユーザーとアプリケーション間のやり取りから望ましくない有害なコンテンツを削除します 自然言語による説明を使用して拒否トピックを定義し、アプリケーションのコンテキストでは望ましくないトピックや主題分野を指定します コンテンツフィルターを設定して、ユースケースと責任ある AI ポリシーに基づいて、ヘイト、侮辱、セクシャリティ、暴力などのカテゴリーにわたって有害なコンテンツをフィルタリングするための閾値を設定します 個人識別情報 (PII) リダクション機能を使用して、LLM が生成した応答から名前、電子メールアドレス、電話番号などの情報をリダクションしたり、PII を含むユーザー入力をブロックします Guardrails for Amazon Bedrock を CloudWatch と統合して、定義されたポリシーに違反するユーザー入力と LLM レスポンスをモニタリングおよび分析することで、潜在的な問題を事前に検出して対応できるようになります パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングし、実際の使用状況や新たな倫理的考慮事項に基づいてガードレールの改良と更新を継続的に行います ジェイルブレイクに対する堅牢性テスト: ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます アンチパターン 8: 包括的なテストと検証の欠如 LLM システムと生成 AI チャットボットアプリケーションのテストと検証プロセスが不十分だと、未確認の脆弱性、パフォーマンスのボトルネック、可用性の問題が発生する可能性があります。包括的なテストと検証を行わないと、組織はアプリケーションを本番環境にデプロイする前に、潜在的なセキュリティリスク、機能上のギャップ、スケーラビリティとパフォーマンスの制限を検出できない可能性があります。 アンチパターンの例 LLM の応答の正確性と完全性、およびチャットボットアプリケーションの特徴と機能を検証するための機能テストが不足しています さまざまな負荷条件下でのボトルネック、リソースの制約、またはスケーラビリティの制限を特定するためのパフォーマンステストが不十分です 潜在的なセキュリティの脆弱性やモデルの悪用を発見するための侵入テスト、脆弱性スキャン、敵対的テストなどのセキュリティテストが行われていません 自動化されたテストと検証のプロセスを継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインに組み込めないと、手動で 1 回限りのテスト作業が行われ、重大な問題を見落とす可能性があります Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスやコンポーネントとのチャットボットアプリケーションの統合のテストが不十分であると、互換性の問題やデータ完全性の問題が発生する可能性があります 緩和戦略 包括的なテストと検証の欠如に対処するには、機能テスト、パフォーマンステスト、セキュリティテスト、および統合テストを含む強固なテスト戦略を実装する必要があります。自動テストを CI/CD パイプラインに統合し、脅威モデリングや侵入テストなどのセキュリティテストを実施し、敵対的検証手法を使用します。テストプロセスを継続的に改善して、生成 AI チャットボットアプリケーションの信頼性、セキュリティ、スケーラビリティを検証します。 包括的なテスト戦略: LLM システムとチャットボットアプリケーション全体の機能テスト、パフォーマンステスト、負荷テスト、セキュリティテスト、統合テストを含む包括的なテスト戦略を確立します アプリケーションの機能要件と非機能要件、およびセキュリティとコンプライアンス基準に基づいて、明確なテスト要件、テストケース、および承認基準を定義します 自動化されたテストと CI/CD 統合: 自動化されたテストと検証プロセスを CI/CD パイプラインに組み込むことで、LLM のパフォーマンス、セキュリティ、信頼性をライフサイクル全体にわたって継続的にモニタリングおよび評価できます 自動化されたテストツールとフレームワークを使用して、テストプロセスを合理化し、テストカバレッジを向上させ、回帰テストを容易にします セキュリティテストと敵対的検証: 潜在的なセキュリティリスクと脆弱性を事前に特定するために、設計プロセスの早い段階で、チャットボットアプリケーションアーキテクチャの設計が完成したらすぐに脅威モデリング演習を実施してください。その後、侵入テスト、脆弱性スキャン、敵対的テストを含む定期的なセキュリティテストを実施して、特定されたセキュリティの脆弱性やモデルエクスプロイトを発見して検証します 敵対的な検証手法を実装し、モデルの堅牢制とセキュリティを向上させます。これには、LLM に対して弱点や脆弱性を明らかにするように慎重に作成された入力をプロンプトとして与えることが含まれます パフォーマンスと負荷テスト: パフォーマンスと負荷を包括的にテストして、さまざまな負荷条件下で発生する可能性のあるボトルネック、リソースの制約、またはスケーラビリティの制限を特定します 負荷の生成、ストレステスト、キャパシティプランニングのためのツールとテクニックを使用して、チャットボットアプリケーションが予想されるユーザートラフィックとワークロードを処理できることを確認します 統合テスト: 徹底的な統合テストを実施して、チャットボットアプリケーションと Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスおよびコンポーネントとの統合を検証し、シームレスな通信とデータの完全性を維持します 継続的な改善: 新たな脅威、新たな脆弱性、またはアプリケーション要件の変化に対処するために、テストと検証のプロセスを定期的に見直し、更新してください テストの知見と結果を利用して、LLM システム、チャットボットアプリケーション、および全体的なセキュリティ態勢を継続的に改善してください すべてのアンチパターンに共通の緩和戦略 LLM と生成 AI コンポーネントのセキュリティ対策、アクセス制御、モニタリングメカニズム、ガードレールを定期的に見直し、更新して、新たな脅威、脆弱性、進化する責任ある AI のベストプラクティスに対処します 定期的なセキュリティ評価、侵入テスト、およびコードレビューを実施して、ロギング、監査、および否認防止メカニズムに関連する脆弱性または設定ミスを特定して修正します 生成 AI アプリケーションのロギング、監査、否認防止に関するセキュリティのベストプラクティス、ガイダンス、および AWS や業界団体からの最新情報を常に把握してください 安全で責任あるアーキテクチャブループリント ベースラインとなるチャットボットアプリケーションアーキテクチャについて説明し、Amazon Bedrock を使用して構築された生成 AI アプリケーションに関連する重要なセキュリティアンチパターンを特定したので、安全で責任あるアーキテクチャブループリントを紹介します。このブループリント (図 2) には、アンチパターン分析全体を通して説明した推奨される緩和戦略とセキュリティコントロールが組み込まれています。 図 2: 安全で責任ある生成 AI チャットボットのアーキテクチャブループリント このターゲットステートアーキテクチャでは、認証されていないユーザーがフロントエンドインターフェース (1) を介してチャットボットアプリケーションと対話します。この場合、安全なコーディングプラクティスと入力バリデーションを実装することで、不十分な入力バリデーションとサニタイズというアンチパターンを軽減することが重要です。その後、ユーザー入力は、それぞれ DDoS 対策、Web アプリケーションファイアウォール機能、コンテンツ配信ネットワークを提供する AWS Shield、AWS WAF、CloudFront (2) を介して処理されます。これらのサービスは、入力バリデーションに AWS WAF を使用し、定期的なセキュリティテストを実施することで、不十分な入力バリデーション、ウェブエクスプロイト、および包括的なテストの欠如を軽減するのに役立ちます。 その後、ユーザーのリクエストは API Gateway (3) を介してルーティングされます。API Gateway (3) は、チャットボットアプリケーションのエントリポイントとして機能し、Streamlit フロントエンドへの API 接続を容易にします。認証、安全でない通信、LLM セキュリティに関連するアンチパターンに対処するには、API Gateway 内に安全な認証プロトコル、HTTPS/TLS、アクセス制御、入力バリデーションを実装することが不可欠です。VPC 内のリソースと API Gateway 間の通信は、VPC エンドポイント (4) を介して保護されます。PrivateLink を使用して安全なプライベート通信を行い、エンドポイントポリシーをアタッチしてどの AWS プリンシパルが API Gateway サービスにアクセスできるかを制御し (8)、安全でない通信チャネルのアンチパターンを軽減します。 Streamlit アプリケーション (5) は、VPC 内のプライベートサブネットにある Amazon ECS でホストされています。フロントエンドインターフェースをホストし、入力の検証とサニタイズが不十分にならないように、安全なコーディング手法と入力バリデーションを実装する必要があります。その後、ユーザー入力は VPC 内でホストされるサーバーレスコンピューティングサービスである Lambda (6) によって処理され、VPC エンドポイント (7) を介して Amazon Bedrock、OpenSearch、および DynamoDB に接続します。これらの VPC エンドポイントには、アクセスを制御するエンドポイントポリシーがアタッチされているため、Lambda 関数とサービス間の安全なプライベート通信が可能になり、安全でない通信チャネルのアンチパターンが軽減されます。Lambda では、入力バリデーションのアンチパターンに対処するために、厳格な入力バリデーションルール、許可リスト、ユーザー入力のサニタイズを実装しています。 ユーザーからのチャットボットアプリケーションのリクエストは、生成 AI ソリューションの Amazon Bedrock (12) に送信され、LLM の機能を提供します。FM と生成 AI コンポーネントの安全性を確保できないアンチパターンを緩和するために、Amazon Bedrock とのやり取りの際には、安全な通信チャンネル、入力のバリデーション、プロンプトとコンテキストデータのサニタイズを実装する必要があります。 Amazon Bedrock は、Amazon Bedrock ナレッジベースを使用して OpenSearch Service (9) とやり取りし、ユーザーの質問に関連するコンテキストデータを取得します。ナレッジベースは Amazon S3 (10) から公開ドキュメントを取り込むことによって作成されます。安全でないデータストレージとアクセス制御のアンチパターンを軽減するには、AWS KMS と OpenSearch Service 内のアクセス制御用のきめ細かい IAM ポリシーとロールを使用して保管時の暗号化を実装してください。Titan エンベディング (11) は、ベクトルエンベディング形式で Amazon S3 に保存されているドキュメントを表します。ベクトル形式により、類似度の計算と関連情報の検索が可能になります (12)。FM および生成 AI コンポーネントのセキュリティ対策が不十分なアンチパターンに対処するため、Titan エンベディングとの安全な統合と入力データのバリデーションを実装する必要があります。 ナレッジベースデータ、ユーザープロンプト、およびコンテキストデータは、Amazon Bedrock (13) と Claude 3 LLM(14) によって処理されます。生成 AI コンポーネントの安全性の欠如、責任ある AI ガバナンスと倫理の欠如といったアンチパターンに対処するため、安全な通信チャンネル、入力バリデーション、倫理的な AI ガバナンスフレームワーク、透明性と解釈可能性の対策、ステークホルダーの関与、バイアスの緩和戦略、および Guardrails for Amazon Bedrock のようなガードレールを実装する必要があります。 生成された応答と推奨事項は、Lambda 関数によって Amazon DynamoDB (15) に保存および取得されます。安全でないデータストレージとアクセスを軽減するには、保存中のデータを AWS KMS (16) で暗号化し、IAM ポリシーとロールによるきめ細かなアクセス制御を実装します。 ロギング、監査、モニタリングの包括的なメカニズムが CloudTrail (17)、CloudWatch (18)、AWS Config (19) により提供され、不適切なロギング、監査、および否認防止のアンチパターンに対処します。包括的なロギング、監査、およびモニタリングメカニズムの実装の詳細なガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには、Amazon Bedrock サービスに対して行われた API 呼び出しのロギング、Amazon Bedrock 固有のメトリクスのモニタリング、Bedrock 呼び出しログの記録と分析、およびチャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの構成のモニタリングと監査が含まれます。 IAM (20) は、アーキテクチャ全体において、また認証や安全でないデータの保存とアクセスに関連するアンチパターンの緩和において重要な役割を果たします。IAM ロールや IAM ポリシーは、チャットボットアプリケーションのさまざまなコンポーネントにわたる安全な認証メカニズム、最小権限によるアクセス、多要素認証、および堅牢な認証情報の管理を実施する上で重要です。さらに、Amazon Bedrock 内の特定のモデルやナレッジベースへのアクセスを制限するようにサービスコントロールポリシー (SCP) を設定して、機密性の高い知的財産への不正アクセスや使用を防ぐことができます。 最後に、チャットボットアプリケーションのセキュリティ態勢をさらに強化するための推奨サービスとして、GuardDuty (21)、 Amazon Inspector (22)、Security Hub (23)、および Security Lake (24) が追加されています。GuardDuty (21) はコントロールプレーンとデータプレーン全体で脅威を検出し、Amazon Inspector (22) は Amazon ECS および Lambda ワークロードの脆弱性評価と継続的なモニタリングを可能にします。Security Hub (23) はセキュリティポスチャ管理とコンプライアンスチェックを一元化し、Security Lake (24) はログ分析のための一元化されたデータレイクとして機能し、CloudTrail および Security Hub と統合されています。 結論 重要なアンチパターンを特定し、包括的な緩和戦略を提供することで、企業環境に生成 AIテクノロジーを安全かつ責任を持って導入するための強固な基盤が得られます。 本ブログで紹介する安全で責任あるアーキテクチャブループリントは、強固なセキュリティ、データ保護、倫理的ガバナンスを確保しながら、生成 AI の力を活用したい組織向けの包括的なガイドとなります。このブループリントは、安全な認証メカニズム、暗号化されたデータストレージ、きめ細かなアクセス制御、安全な通信チャネル、入力のバリデーションとサニタイズ、包括的なロギングと監査、安全な FM の統合とモニタリング、責任ある AI ガードレールなど、業界をリードするセキュリティコントロールを組み込むことで、生成 AI アプリケーションに関連する固有の課題と脆弱性に対処します。 さらに、包括的なテストと検証プロセスに重点を置き、倫理的な AI ガバナンスの原則を組み込むことで、潜在的なリスクを軽減できるだけでなく、潜在的なバイアスに対処し、組織の価値観や社会規範との整合性を確保しながら、LLM コンポーネントの透明性、説明可能性、解釈可能性を高めることができます。 本ブログで概説され、アーキテクチャブループリントに示されているガイダンスに従うことで、潜在的なリスクを積極的に特定して軽減し、生成 AI ベースのチャットボットソリューションのセキュリティ態勢を強化し、機密データや知的財産を保護し、規制コンプライアンスを維持し、責任を持って企業環境に LLM と生成 AI テクノロジーを導入することができます。 本ブログについて質問がある場合は、 AWS サポートにお問い合わせください 。 Magesh Dhanasekaran Magesh は AWS のセキュリティアーキテクトです。オーストラリアと米国の金融機関や政府機関に情報セキュリティコンサルティングサービスを提供した実績があります。Magesh は、クラウドセキュリティアーキテクチャ、デジタルトランスフォーメーション、安全なアプリケーション開発の実践における経験を活かして、AWS 製品とサービスに関するセキュリティアドバイスを提供しています。彼は現在、複数の業界認定資格を取得しています。 Amy Tipple Amy はプロフェッショナルサービスのデータ・機械学習チームのシニアデータサイエンティストで、AWS に約 4 年間在籍しています。エイミーは、生成 AI に関するいくつかの取り組みに携わっており、生成 AI 関連のセキュリティを AWS ユーザーが利用しやすく理解しやすいものにすることを推進しています。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

8月28日、 AWS Parallel Computing Service (AWS PCS) が発表されました。これは、お客様による ハイパフォーマンスコンピューティング (HPC) クラスターのセットアップおよび管理をサポートし、AWS で事実上あらゆるスケールでシームレスにシミュレーションを実行できるようにする、新しいマネージドサービスです。 Slurm スケジューラを使用すると、使い慣れた HPC 環境で作業できるため、インフラストラクチャについて心配することなく、結果が出るまでの時間を短縮できます。 2018 年 11 月、弊社は AWS がサポートするオープンソースクラスター管理ツール、 AWS ParallelCluster を発表しました。これは、AWS クラウドでの HPC クラスターのデプロイと管理に役立つツールです。AWS ParallelCluster を使用すると、お客様は概念実証や本稼働の HPC コンピューティング環境を迅速に構築およびデプロイすることもできます。また、 AWS ParallelCluster コマンドラインインターフェイス 、 API 、 Python ライブラリ 、オープンソースパッケージからインストールされたユーザーインターフェイスを使用できます。これらは、クラスターの解体や再デプロイを含む更新の責任を負います。しかし、多くのお客様は、HPC 環境の構築と運用における作業を削減したいと考え、フルマネージド型の AWS サービスを求めていました。 AWS PCS は、AWS が管理する HPC 環境を簡素化します。また、 AWS マネジメントコンソール 、AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) からアクセスすることが可能です。システム管理者は、コンピューティングとストレージの設定、ID、ジョブ割り当て設定を使用するマネージド Slurm クラスターを作成できます。AWS PCS は、シミュレーションのスケジューリングとオーケストレーションに、さまざまな HPC のお客様に使用されている拡張性と耐障害性に優れたジョブスケジューラ、Slurm を使用しています。科学者、研究者、エンジニアなどのエンドユーザーは、AWS PCS クラスターにログインして、HPC ジョブの実行と管理、仮想デスクトップでのインタラクティブソフトウェアの使用、データへのアクセスを行うことができます。コードの移植に多大な労力を費やすことなく、ワークロードをすばやく AWS PCS に持ち込めます。 フルマネージドの NICE DCV リモートデスクトップを使用してリモートで視覚化したり、ジョブテレメトリやアプリケーションログにアクセスしてスペシャリストが HPC ワークフローを 1 か所で管理できるようにしたりできます。 AWS PCS は、シミュレーションと計算を準備、実行、分析するための使い慣れた方法を使用して、数値流体力学、気象モデリング、有限要素解析、電子設計自動化、貯留層シミュレーションなどの分野にわたり、従来型と新型、コンピューティング集約型またはデータ集約型の幅広いエンジニアリングおよび科学ワークロードに対処できるよう設計されています。 AWS Parallel Computing Service の開始方法 AWS PCS を試すには、AWS ドキュメントの「 簡単なクラスターの作成に関するチュートリアル 」をご確認ください。まず、AWS PCS を試す AWS リージョンにあるアカウント内の Amazon Elastic File System (Amazon EFS) で、AWS CloudFormation テンプレートと共有ストレージを使用して、仮想プライベートクラウド (VPC) を作成します。詳細については、AWS ドキュメントの「 VPC の作成 」と「 共有ストレージの作成 」を参照してください。 1.クラスターの作成 AWS PCS コンソール で、リソースを管理しワークロードを実行するための永続的リソースである [Create cluster (クラスターを作成)] を選択します。 次にクラスター名を入力し、Slurm スケジューラのコントローラーサイズを選択します。クラスターワークロードの上限として、 [Small (小規模)] (最大 32 ノード、256 ジョブ)、 [Medium (中規模)] (最大 512 ノード、8,192 ジョブ)、または [Large (大規模)] (最大 2,048 ノード、16,384 ジョブ) を選択できます。 ネットワーキング セクションで、作成した VPC、クラスターを起動するサブネット、クラスターに適用するセキュリティグループを選択します。 オプションで、コンピューティングノードがスケールダウンするまでのアイドル時間、起動したコンピューティングノード上の Prolog および Epilog スクリプトディレクトリ、Slurm が使用するリソース選択アルゴリズムパラメータなどの Slurm 設定を設定できます。 [Create cluster (クラスターを作成)] を選択します。クラスターがプロビジョニングされるまでにはしばらく時間がかかります。 2.コンピューティングノードグループの作成 クラスターを作成した後、コンピューティングノードグループを作成できます。これは、AWS PCS がクラスターへのインタラクティブなアクセスを提供したり、クラスターでジョブを実行したりするために使用する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの仮想コレクションです。コンピューティングノードグループを定義するときは、EC2 インスタンスタイプ、最小インスタンス数と最大インスタンス数、ターゲット VPC サブネット、 Amazon マシンイメージ (AMI) 、購入オプション、カスタム起動設定などの共通特性を指定します。コンピューティングノードグループでは、 AWS Identity and Access Management (IAM) ロールを EC2 インスタンスに渡すインスタンスプロファイルと、AWS PCS が起動する EC2 インスタンスの設定に使用する EC2 起動テンプレートが必要です。詳細については、AWS ドキュメントの「 起動テンプレートの作成 」と「 インスタンスプロファイルの作成 」を参照してください。 コンソールでコンピューティングノードグループを作成するには、クラスターに移動し、 [Compute node groups (コンピューティングノードグループ)] タブと [Create compute node group (コンピューティングノードグループを作成)] ボタンを選択します。 2 種類のコンピューティングノードグループを作成できます。1 つはエンドユーザーがアクセスするログインノードグループ、もう 1 つは HPC ジョブを実行するジョブノードグループです。 HPC ジョブを実行するコンピューティングノードグループを作成するには、コンピューティングノード名を入力し、以前作成した EC2 起動テンプレート、IAM インスタンスプロファイル、クラスター VPC でコンピューティングノードを起動するサブネットを選択します。 次に、コンピューティングノードを起動するときに使用したい EC2 インスタンスタイプと、スケーリング用の最小インスタンス数および最大インスタンス数を選択します。ここでは hpc6a.48xlarge インスタンスタイプを選択し、スケールの上限を 8 インスタンスに設定しました。ログインノードでは、1 つの c6i.xlarge インスタンスなど、より小さいインスタンスを選択できます。インスタンスタイプがサポートしている場合は、 オンデマンド または スポット EC2 購入オプションを選択することも可能です。オプションで、特定の AMI を選択できます。 [Create (作成)] をクリックします。コンピューティングノードグループがプロビジョニングされるまでにはしばらく時間がかかります。詳細については、AWS ドキュメントの「 ジョブを実行するためのコンピューティングノードグループの作成 」と「ログインノード用のコンピューティングノードグループの作成 」を参照してください。 3.HPC ジョブの作成と実行 コンピューティングノードグループを作成したら、ジョブをキューに送信して実行します。利用可能なプロビジョニング済み容量に基づきコンピューティングノードグループで実行されるように AWS PCS がスケジュールするまで、ジョブはキューに残ります。各キューは、処理を行うために必要な EC2 インスタンスを提供する、1 つ以上のコンピューティングノードグループに関連付けられています。 コンソールでキューを作成するには、クラスターに移動し、 [Queues (キュー)] タブと [Create queue (キューを作成)] ボタンを選択します。 キュー名を入力し、キューに割り当てられたコンピューティングノードグループを選択します。 [Create (作成)] を選択し、キューが作成されるまで待ちます。 ログインコンピューティングノードグループがアクティブな場合、 AWS Systems Manager を使用して、作成された EC2 インスタンスに接続できます。 Amazon EC2 コンソール に移動し、ログインコンピューティングノードグループの EC2 インスタンスを選択します。詳細については、AWS ドキュメントの「 ジョブを送信および管理するためのキューの作成 」と「 クラスターへの接続 」を参照してください。 Slurm を使用してジョブを実行するには、ジョブ要件を指定する送信スクリプトを用意し、 sbatch コマンドを使用してキューに送信します。通常、これは共有ディレクトリから行われるため、ログインノードとコンピューティングノードには、ファイルにアクセスするための共通のスペースがあります。 Slurm を使用して AWS PCS でメッセージパッシングインターフェイス (MPI) ジョブを実行することもできます。詳細については、AWS ドキュメントの「 Slurm を使用した単一ノードジョブの実行 」または「 Slurm を使用したマルチノードの MPI ジョブの実行 」を参照してください。 フルマネージドの NICE DCV リモートデスクトップを接続して視覚化できます。開始するには、 AWS GitHub リポジトリの HPC レシピ にある CloudFormation テンプレートを使用してください。 この例では、 OpenFOAM MotorBike シミュレーション を使用して、オートバイとライダーの周りの定常流を計算しました。このシミュレーションは、3 つの hpc6a インスタンスの 288 コアを使用して実行されました。DCV インスタンスのウェブインターフェイスにログインした後、 ParaView セッションで出力を視覚化できます。 作成したクラスターとノードグループで HPC ジョブを実行した後、不必要な課金を避けるために、作成したリソースを削除する必要があります。詳細については、AWS ドキュメントの「 AWS リソースの削除 」を参照してください。 知っておくべきこと この機能について知っておきたい事柄には、次のようなものがあります。 Slurm バージョン – AWS PCS はもともと Slurm 23.11 をサポートしており、新しいバージョンが追加された際にお客様が Slurm のメジャーバージョンをアップグレードできるよう設計されたメカニズムを提供しています。さらに、AWS PCS はパッチバージョンを使用して Slurm コントローラーを自動的に更新するよう設計されています。詳細については、AWS ドキュメントの「 Slurm バージョン 」を参照してください。 キャパシティ予約 – オンデマンドキャパシティ予約を使用して、特定のアベイラビリティーゾーンおよび特定期間の EC2 キャパシティを予約し、必要なときに必要なコンピューティングキャパシティを確保できます。詳細については、AWS ドキュメントの「 キャパシティ予約 」を参照してください。 ネットワークファイルシステム – Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon File Cache 、Amazon EFS、Amazon FSx for Lustre など、データやファイルを書き込んだりアクセスしたりするネットワークストレージボリュームをアタッチできます。NFS サーバーなどのセルフマネージドのボリュームを使用することもできます。詳細については、AWS ドキュメントの「 ネットワークファイルシステム 」を参照してください。 今すぐご利用いただけます AWS Parallel Computing Service は、現時点で米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の各リージョンで使用可能です。 AWS PCS は AWS アカウントのすべてのリソースを起動します。また、これらのリソースに対して適切な料金が請求されます。詳細については、 AWS PCS の料金ページ を参照してください。 ぜひお試しいただき、 AWS re:Post for AWS PCS 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy P.S.HPC テスト環境の作成に寄与してくれた AWS の Principal Developer Advocate である Matthew Vaughn に感謝します。 原文は こちら です。

本ブログは株式会社 JDSC 様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。 AWS ソリューションアーキテクトの瀬高です。 日々のお客様との相談会を通して、生成 AI への注目度が高まっているのを感じる今日このごろです。その中でも、生成 AI に対して信頼できる知識ベースへの検索機能をかけ合わせた検索拡張生成、いわゆる RAG (Retrieval Augmented Generation) が業務効率化やデータの利活用方法の出口としてイメージしやすいところから人気があるように感じています。 今回ご紹介する事例は、 株式会社 JDSC 様が海運事業を取り組んでいるお客様に対し RAG を構築した事例となっています。RAG を構築するだけでなく、 Amazon Bedrock の特徴を活かしたモデルの使い分けや、専門用語に対する Claude の強さを活かし、専門的な工数の 97% を削減し、従来システムに対して 30% の精度向上を実現しています。 本取り組みは JDSC 様の NEWS にも掲載されています。合わせて御覧いただければと思います。 お客様の状況と経緯 JDSC 様は日本の産業をアップデートすることを使命とした、東京大学発の AI 企業で、機械学習などを活用した開発、運用やデータサイエンスに関するコンサルティング事業などを行っている企業となります。 エンドユーザーの社内では契約書や技術情報などの専門的なドキュメントがおよそ 1 万部ほどあり、業務に携わるメンバーはこの中やメールなどのタイムリーな情報も含めて横断的に質問に対する答えを探す必要がありました。ドキュメントの数やサイズも大きく目的の情報を探し出すまでの時間がかかる点や、属人的なノウハウが必要になっている点が課題となっており、数十秒で質問に対する答えを出せるようにしたいというニーズをお持ちでした。 また、お客様からのお問い合わせへの対応も進めていきたいという要望もあり、あらゆる情報を一元的に早く調べようとすると検索時間が多くかかる点に、ビジネス的な課題を感じられているとのことでした。 JDSC 様は RAG を構築することで、上記課題の解決を図ろうと検証を進めていました。 その中で、以下のような課題が出ていました。 ファイルサイズの大きさに伴う入出力のトークンサイズ 入力意図の誤認識や専門的な単語の認識率 禁止ワードへの過剰反応 金銭的なコストの高さ そこで、当時発表されたばかりの Anthropic 社の生成 AI モデルである Claude 3 やデータストアとなる Amazon Kendra 、 Amazon OpenSearch Service 、 Amazon RDS for PostgreSQL を Generative AI Use Case JP を参考に検証していただくことになりました。 ソリューション / 構成内容 検証の結果、下記のように Claude 3 とデータストアとして Amazon RDS for PostgreSQL を利用する構成を取ることに決定しました。 今回使用しているモデルは Claude 3.5 Sonnet と Claude 3 Haiku を利用しています。ベクトル検索の結果に含まれるドキュメントの一部が返却された際に Haiku でそれぞれ結果が役に立つかのチェックを行い精度の向上を図り、最終的なユーザーが触れるレスポンス文生成のところでは処理性能に優れる Claude 3.5 Sonnet を活用することで優れた文章表現を実現しています。 Amazon Bedrock + Claude を採用したポイントとして、プロンプトへの追従性や使い勝手、大きなトークンが扱える点、運用管理が AWS で完結する点、AWS のサポート体制などに魅力を感じてご採用いただきました。 開発当初は Claude 3 Sonnet を利用する予定でしたが、Bedrock が持つ特徴でもあるモデルの切り替えやすさを活かして Claude 3.5 Sonnet や Amazon Titan Text V2 などの当時の最新モデルを更に検証し Claude 3.5 Sonnet へスムーズにアップデートしてローンチしました。3.5 へのアップデートを行ったことで、利用者の質問に対して意図の汲み取りがよりスムーズにできるようになり顧客満足度の向上につながったと伺っています。 また、Generative AI Use Case JP についても「何から手をつけていいかわからない状態からのスタートだったが、動作するイメージがわかりやすくドキュメントも充実しているためスムーズにカスタマイズしていけた」とのコメントをいただいています。 導入効果 実際にエンドユーザーの方々に使っていただいた結果、下記のような良い結果が得られ AI の活用を更に推し進めていきたいとのご評価をいただいています。 お問い合わせの対応時間が約 97% 短縮 的確な回答を行う回答精度が 30％ 向上 回答作成をする属人的なノウハウや専門知識の必要性が下がり人材の幅が拡大 また ソリューション / 構成要素でも触れた Bedrock の持つ特徴の一つである、モデルの切り替えやすさを活かしたアーキテクチャを組んでいることで、今後出てくる新しいモデルの導入もスムーズにできる状態になっており、さらなる精度向上やコストダウンも見込まれています。 まとめ 今回は海運事業を取り組まれているエンドユーザー様向けに専門的な RAG を構築された事例をご紹介いたしました。Amazon Bedrock や Claude の特徴を活かしお客様のビジネスを加速させる取り組みをなされています。 また、移り変わりの激しい、新たにでたモデルに対しても Amazon Bedrock の特徴を活かしながらスピーディに検証していただいております。生成 AI 活用の幅が更に広がる取り組みになっているので是非ご参考いただければと思います。 構築方法など、ご不明な点があればお問い合わせいただければと思います。ぜひお試しください。 株式会社 JDSC : Technical Co-Founder 橋本 圭輔 様 (中央) Amazon Web Services Japan : アカウントマネージャー 菊地 晋哉 (左)、ソリューションアーキテクト 瀬高 拓也 (右) ソリューションアーキテクト 瀬高 拓也 (X – @stktky )

本ブログは「 Optimize data validation using AWS DMS validation-only tasks 」を翻訳したものとなります。 AWS Database Migration Service (AWS DMS) は、データを Amazon Web Services (AWS) に効率的かつセキュアに移行するのに役立ちます。Oracle や SQL Server などの広く使用されている商用データベースから、MySQL や PostgreSQL などのオープンソースデータベースにデータを移行できます。また、 AWS DMS は、 さまざまなサポートされているソース から AWS に移行する際にデータを検証する機能を提供します。データの整合性と正確性は、移行プロジェクトが成功するかどうかを左右する重要な要件の1つであり、お客様から頻繁にお伺いするポイントです。この記事では、 AWS DMS のデータ検証機能 について詳しく説明します。その利点、設定、およびユースケースを探ります。 AWS DMS によるデータ検証 AWS DMS のデータ検証機能は、ソースからターゲットへのデータ移行が正確に行われていることを確認するのに役立ちます。 AWS DMS の移行タスクで 全ロードのみ (既存データの移行) の移行タイプを選択した場合、完全ロードが完了した直後にデータ検証が開始されます。 完全ロード + CDC (既存データの移行と継続的な変更のレプリケーション) &nbsp;の移行では、完全ロードが完了した直後に検証が開始され、その後、変更データキャプチャ (CDC) による増分変更を継続的に比較します。CDC のみのタスクで検証が有効になっている場合、新しいデータの検証を開始する前に、テーブル内の既存のすべてのデータが検証されます。 データ検証中、 AWS DMS はソースの各行とターゲットの対応する行を比較し、行が同じデータを含んでいるかを確認し、不一致があればレポートします。列の値の比較方法はデータ型によって異なります。たとえば、大きなバイナリオブジェクト (LOB) 列の比較にチェックサム関数が使用されますが、他のデータ型の場合は実際の値が使用されます。 AWS DMS コンソールまたは AWS Command Line Interface (AWS CLI) を使用して、移行タスクでデータ検証機能を有効にできます。詳細については、 Migration Validation (Part 2) – Introducing Data Validation in AWS Database Migration Service を参照してください。また、移行やデータレプリケーションを実行せずに、データのプレビューと検証のみを行う 検証のみのタスク を作成できます。この検証では、ソースとターゲットの両方で追加のリソースが消費され、ネットワークリソースも追加で必要となります。また、ソースとターゲットのテーブルに主キーまたは一意のインデックスが必要です。AWS DMS 検証を使用する前に、その 制限事項 を確認することをお勧めします。 ソリューション概要 この投稿では、以下のトピックについて説明します。 AWS DMS 検証のみのタスクのユースケース(リレーショナルデータベース) AWS DMS 検証のみのタスク の構成と監視方法 検証のみのタスク: フルロードと CDC の比較 検証のみのタスクの最適化方法 検証が失敗するケースの対処方法 AWS DMS 検証のみのタスクのユースケース(リレーショナルデータベース) AWS DMS で検証のみのタスクを使用するいくつかの一般的なユースケースは次のとおりです。 データを移行せずに検証を実行する – 検証のみのタスクを使用すると、データを複製することなく、ソースとターゲットのデータを検証できます。これは、検証ルールと設定をテストするのに役立ちます。 検証を移行タスクから分離する – 個別の検証のみのタスクを作成することで、既存の移行タスクに影響を与えることなく、データを独立して検証できます。これにより、検証失敗が移行をブロックするのを防ぎ、また別のレプリケーションインスタンス (RI) で検証のみのタスクを実行することもできます。さらに、この別の RI では新機能を利用するために異なる DMS バージョンを使うこともできます。 検証失敗のトラブルシューティング – 移行タスクで検証が失敗した場合、進行中の移行タスクと分離されている検証のみのタスクを使用することで、特定の失敗を調査してトラブルシューティングしやすくなります。 スケジュールされた検証 – 検証のみのタスクを定期的に実行することで、変更されるソースとターゲットのデータを検証できます。これにより、継続的に実行されるタスクと比較してソースとターゲットデータベースインスタンスの負荷を軽減できます。 特定の時点でデータ行が一致しないことを迅速に確認する – 本番稼働切り替えを行う前または切り替えの最中にフルロードの検証のみのタスクを実行することで、新しいターゲットエンドポイントにアプリケーションを切り替える前にデータを検証できます。 データ修復スクリプト – 検証が失敗したテーブル向けのデータ修復スクリプトを作成した場合、フルロードのバリデーションのみのタスクを実行すると、スクリプトが対処可能な問題を迅速に検知できます。 AWS DMS 検証のみのタスクをどのように構成して監視するか AWS DMS コンソールを使用して検証専用のタスクを作成するには、AWS DMS タスクを作成する際に以下の設定を行います。 TargetTablePrepMode を DO_NOTHING (検証専用タスクのデフォルト) に設定します。 マイグレーションタイプを「 既存のデータを移行する 」または「 データ変更のみをレプリケートする 」に設定します。 データ検証で「 検証(データ移行なし) 」を選択します。 または、 JSON エディタを使ってタスク設定を変更することができます: "EnableValidation": true, "ValidationOnly": true, データ検証が有効になっている場合、AWS DMS コンソールまたは Amazon CloudWatch で 検証の状態 を監視できます。 テーブル内の一部のレコードがソースとターゲットで一致しない場合、検証状態は Mismatched records となり、ターゲットデータベースの awsdms_validation_failures_v1 テーブルで詳細を確認できます。このテーブルは、 ControlSchema で定義したスキーマまたはデータベースエンジンの デフォルトの場所 に作成されます。レコードが ValidationSuspended または ValidationFailed 状態になった場合、 AWS DMS は同じテーブルに診断情報を書き込みます。 次のスクリーンショットは、 PostgreSQL の例(ターゲット)を示しています。 AWS DMS データ検証の監視の詳細については、 Insights into AWS DMS resiliency and recovery scenarios with mitigations – Part 2 をご参照ください。 フルロードの検証のみ・ CDC の検証のみのタスク 前述のとおり、移行タイプには2種類あり、フルロードの検証のみのタスクと CDC の検証のみのタスクを作成できます。これら 2 種類のデータ検証プロセスと、主要なチューニング可能なパラメータについて、次のセクションで説明します。 フルロードの検証のみ AWS DMS バージョン 3.4.6 以降では、フルロードの検証のみのタスクを使用すると、ソーステーブルとターゲットテーブルのすべての行を高速に比較し、検証エラーがあればすぐに報告し、検証が完了した後にタスクを停止します。 AWS DMS はデータを論理的にパーティション(デフォルトは 1 パーティションあたり 10,000 レコード)に分割し、複数の AWS DMS データ検証スレッド(デフォルトは 5 つ)を使用して対応するパーティション間のデータを比較します。データ検証エラーがある場合、ターゲットデータベースの制御テーブル ( awsdms_control.awsdms_validation_failures_v1 ) にログが記録されます。次の図では、 Row n の列 coln の値が一致しないため、不一致レコードが報告されています。 次の表は、フルロードの検証タスクのみに関する重要なタスクパラメータを示しています。 AWS DMS のデータ検証タスクでサポートされているすべてのパラメータについては、「 データ検証タスクの設定 」を参照してください。 CDC の検証のみ CDC の検証のみのタスクが開始されると、既存のデータを最初に検証し、次に CDC によって変更されたデータを検証し、不一致があれば報告します。また、継続的にレプリケーションされた変更を再検証します。 CDC の検証では、誤検出を防ぐために、失敗する前に不一致の行を再試行します。再試行を待つ時間は、タスク設定の RecordFailureDelayLimitInMinutes および RecordSuspendDelayInMinutes パラメータで設定された失敗再試行期間(分単位)に依存します。次の図では、時刻 T1 で、 AWS DMS 検証スレッドが Row n のデータ不一致を発見します。すぐに失敗を報告するのではなく、再試行し、進行中のデータ複製タスクが問題を修正することを期待します。 次の図の時間 T2 では、まだ障害再試行期間内ですが、 AWS DMS の検証スレッドが Row n のデータを再度比較し、データが一致していることを確認したためデータ検証の失敗は報告されません。 AWS DMS の検証タスクでは、新しいデータが見つかるとそれらをパーティションに分割し、データ検証スレッドを割り当てて、データを検証します。 次の表は、CDC 検証のみのタスクの重要なタスクパラメータを示しています。これは、前述の完全ロード検証のみのタスクで説明されたパラメータに加えて考慮する必要があります。 AWS DMS データ検証タスクでサポートされているすべてのパラメータについては、「 データ検証タスクの設定 」を参照してください。 どのように AWS DMS 検証のみのタスクを最適化するか このセクションでは、 AWS DMS の検証のみのタスクのパフォーマンスを最適化できる複数の検証タスク設定について説明します。これらの設定は、本番環境で実装する前に検証環境でテストする必要があります。各検証タスクは独立しており、タスクごとに最適化が必要です。 ThreadCount : このパラメータは、 AWS DMS がデータ検証を実行する際に使用するスレッド数を指定します。デフォルトは 5 で、各スレッドは未検証のデータを処理して比較と検証を行います。より多くのスレッド数を設定すると、検証タスク全体のパフォーマンスが向上しますが、より多くのリソースがソースとターゲットのエンドポイントで消費されます。 PartitionSize : この設定は、各スレッドがソースとターゲットのインスタンスから読み取るレコード数を指定します。デフォルト値の 10,000 を増やすと、 AWS DMS が検証のためにより多くのレコードを読み取ることができますが、移行コンポーネントへの負荷が増加します。 RecordFailureDelayLimitInMinutes : このパラメータを使用すると、 AWS DMS が検証失敗を報告するまでの遅延を指定できます。通常、 AWS DMS はデータ変更がターゲットに複製されるまでの実際の遅延を許容するために、タスク待機時間の値を使用し、誤検出を防ぎます。この設定では、より高い値を定義できます。 ValidationQueryCdcDelaySeconds : これは、ソースとターゲットで最初の検証クエリが遅延する時間です。検証のみのタスクでは、デフォルト値は 180 秒です。ソースでの大量の更新により高い待機時間が発生する場合は、この値を大きくしてソースインスタンスへの再検証を減らすことができます。 FailureMaxCount : この設定は、タスクが中断される前の検証失敗の最大数を指定します。デフォルト値は 10,000 です。すべてのレコードを検証し続けたい場合は、この値をソーステーブルのレコード数より大きな値に設定します。一方、データの不一致を許容できない場合は、失敗が発生したときにタスクが迅速に中断されるように、より小さな値を使用できます。これにより、より厳格なデータ整合性チェックが行われます。 HandleCollationDiff : このオプションは、列の照合順序 (Collation) の違いがどのように処理されるかを制御します。デフォルトでは値は false で、列の照合順序の違いを無視します。これにより、データ検証で誤検出が発生する可能性があります。照合順序は、レコードの並び順やデータの比較方法を決定するため、データ検証の重要な側面です。たとえば、次の例は、文字列「 abcABC 」の ASCII 表現における大文字と小文字の区別のある並び替え順序と区別のない並び替え順序を示しています。 検証の失敗をどのように対処するか このセクションでは、 AWS DMS の検証タスクで発生しうる、データ検証の失敗に関するいくつかの一般的なシナリオと、それらを修正する方法について説明します。 LOB が切り捨てられる場合 データベースをターゲットインスタンスに移行する際、 AWS DMS の移行タスク内で設定されている場合、 LOB データを含むデータをレプリケーションできます。 LOB データの移行のために、いくつかの 構成可能な設定 があります。デフォルトでは、 AWS DMS は制限付き LOB モードを使用し、それぞれの LOB の最大サイズは 32 KB です。デフォルトの構成を使用する場合、最大 LOB サイズを超えるデータはすべて切り捨てられます。 切り捨てられた LOB 列は、ソースとターゲットの値が異なるため、データ検証に失敗します。 CloudWatch ログで切り捨てられたログを検索することで、 LOB の切り捨てが発生していることを確認できます。切り捨てを回避するには、ソースデータベースの LOB サイズに合わせて最大 LOB サイズを設定します。 LOB サイズがわからない場合は、 inline LOB モード(エンドポイントがサポートしている場合)を選択して、小さな LOB と大きな LOB の両方を複製できます。検証専用タスクの ValidationPartialLobSize の値は、データ移行タスクの最大 LOB サイズと同じ値に設定することをお勧めします。 数値・タイムスタンプが切り捨てられる場合 数値とタイムスタンプのデータは、通常データベースエンジンによって異なるスケールと精度を持っており、明示的に定義されていない場合、それぞれのデフォルト値は異なります。以下では、数値とタイムスタンプに関する潜在的な問題と、それらを修正する方法を示す一般的な例をいくつか説明します。 Oracle データベースがソースの場合 Oracle データベースの移行において、数値データ型である NUMBER 型の移行でスケールと精度が明示的に指定されていない場合、 AWS DMS はデフォルトでデータを小数点 10 桁で切り捨てます。そのため、小数点 10 桁を超える既存のデータが移行される場合、ターゲットで数値が切り捨てられます。例えば、データ 123456.123456789012 は 123456.1234567890 に切り捨てられます。データが切り捨てられるのを避けるためには、 移行タスクのエンドポイントの追加接続属性 (ECA) パラメータ NumberDataTypeScale に適切な値を設定します。デフォルト値は 10 ですが、この例では 12 に設定してデータ切り捨てを回避します。これらのパラメータ設定の詳細については、 AWS DMS のドキュメント を参照してください。 PostgreSQL がソース・ターゲットの場合 PostgreSQL から PostgreSQL への移行において、精度やスケールが定義されていない数値データ型の列にデータが格納されている場合、AWS DMS は全体で 28 桁、小数点 6 桁でデータを切り捨てます。切り捨てを回避するには、移行時に数値データを文字列型としてマッピングするために、ソースとターゲットの両エンドポイントの ECA に MapUnboundedNumericAsString=true を定義します。 タイムスタンプデータについて Oracle は、 TIMESTAMP 型のデータ型で 1 秒あたり最大 9 桁の小数部 (= ナノ秒単位 ) をサポートしています。 SQL Server は、 TIME 型のデータ型で1秒あたり最大 7 桁の小数部をサポートしています。このデータが MySQL や PostgreSQL などのターゲットにマップされる場合、両方とも TIMESTAMP 型のデータ型で 1 秒あたり最大 6 桁の小数部をサポートします。その場合、ソースデータベース ( 例えば Oracle) で TIMESTAMP(7) から TIMESTAMP(9) と定義されたデータ型に対して、 AWS DMS のデータ検証タスクが不一致レコードを報告します。同じ問題が、 Oracle の TIMESTAMP WITH TIME ZONE や TIMESTAMP WITH LOCAL TIME ZONE など TIMESTAMP 型の別種、または SQL Server の DATEIME2 や DATETIMEOFFSET にも当てはまる可能性があります。データの切り捨てがビジネス上許容できる場合は、後で示すようにカスタム関数を使ってオーバーライドの検証ルールを設定できます。 トリガーやスケジューラによってターゲットのデータが更新される場合 AWS DMSはソースからターゲットデータベースにデータを移行し、レプリケーションによってデータを同期させます。 AWS DMS 以外で発生する変更は、データの不整合のリスクを高め、データ検証エラーの原因となる可能性があります。これらの変更の一部は、意図せずに発生します。例えば: ターゲットでデータベーストリガーが有効になっている場合、 AWS DMS タスクがターゲットテーブルに DML による変更を加えるとデータが更新される可能性があります。ベストプラクティスとして、データ移行フェーズではトリガーを無効にし、カットオーバー移行のみ有効にすることが推奨されます。ターゲットが PostgreSQL の場合、パラメータ session_replication_role=replica を使ってトリガーと外部キー制約を無効にできます。 ターゲットデータベース上で実行されるスケジューラジョブがデータを変更する可能性があります。初期の スキーマ変換 時に、スケジューラジョブもターゲットに移行できます。しかしながら、これらのジョブが有効になっていると、ターゲットのデータが変更されてデータ検証に影響を与え、複雑なトラブルシューティングが必要になる可能性があります。ベストプラクティスとして、ターゲットデータを変更する可能性のあるスケジューラジョブ(内部データベースのスケジューラジョブまたはアプリケーションの一部として予定されている外部ジョブ)を移行中は無効にすることが推奨されます。 文字セットと照合順序 (collation) の設定について データ移行中、データは複数回デコードとエンコードされます。ソースデータベースからデータを読み取り、レプリケーションインスタンスでデータを処理し、最終的にターゲットデータベースのロケール設定に基づいてデータをターゲットデータベースに書き込みます。変換の際に、 Unicode から Latin 文字セットなどの不適切な構成が設定されている場合、データ検証タスクは欠損の可能性がある変換を記録するために、これらを ValidationFailed として報告する可能性があります。 また、アクセント・ケースセンシティブは、移行タスクでデータエラーの原因となる可能性があります。例えば、ソースデータベースがアクセント・ケースセンシティブを持つように構成されており(これはデフォルトの動作です)、 NAME 列を主キーとするテーブルに AAAA 、 aaaa 、 áááá の 3 つのレコードがあるとします。これらのレコードがアクセントとケースを区別しない MySQL データベース ( utf8mb4_0900_ai_ci の照合順序など) のようなターゲットデータベースに書き込まれると、重複キーエラーが発生します。これは、アクセントとケースの違いを無視して同じレコードとして扱われるためです。これらのレコードは、一意制約違反エラーにより、 awsdms_validation_failures_v1 コントロールテーブルに FAILURE_TYPE を MISSING_TARGET として表示されます。 変換ルールとフィルタールールの影響 AWS DMS には、データ移行の一環で既存のスキーマとデータを変換するための強力な 変換ルール があり、フィルター条件が満たされた場合にのみターゲットデータベースにデータを移行するための フィルタールール もサポートされています。データ移行タスクで使用されるこれらのルールは、意図せずにターゲットデータベースでデータの不整合を引き起こす可能性があります。データ検証のみのタスクを作成する場合、これらのルールの副作用としてデータ検証の問題が発生しないように、同じ変換とフィルターのルールを使用することが重要です。データ検証のみのタスクに変換またはフィルターのルールを含める場合、 AWS DMS はまず規則を適用し、次にデータを検証し、不一致のレコードについて失敗を報告します。 例えば、移行タスクで、ソースの COL1 をターゲットの col2 に変更する変換ルールを設定したとします。しかし、同じ変換ルールがないデータ検証のみのタスクを作成した場合、 TargetTablePrepMode が DO_NOTHING であるため、 AWS DMS は必要なテーブルメタデータを認識できません。このシナリオでは、 AWS DMS は COL1 と col2 を検証の対象から除外します。別のシナリオでは、データ移行にフィルターのルールを適用するが、データ検証のみのタスクではフィルターのルールを省略すると、レコードはソースデータベースに存在するが、フィルターのルールのために AWS DMS によってターゲットに移行されません。その結果、検証エラーが発生します。 データ検証でオーバーライドルールを活用する方法 データ検証中に、この投稿で説明されているようなさまざまな検証エラーが発生する可能性があります。たとえば、ソースとターゲットのエンジン間で文字セットが異なるため、同じデータが移行されているにもかかわらず、 RECORD_DIFF とともに Mismatched records エラーが発生する可能性があります。または、AWS DMS のデータ検証で使用される組み込み関数がソースデータベースのバージョンでサポートされていないことにより、 ValidationFailed として CloudWatchLogs に &lt;No authorized routine named ‘HASH’ of type ‘FUNCTION’ having compatible arguments was found&gt; や &lt;pg_catalog.timezone(unknown, json)&gt; などのエラーが表示される可能性があります。このような場合に備え、 AWS DMS のデータ検証では、マッピングルールの validation ルールタイプに オーバーライド検証関数 を提供しています。この機能により、ソースとターゲットのエンジンでサポートされているデータベース関数を使用して、独自の検証ルールを追加できます。 たとえば、前述の Oracle から MySQL への移行におけるタイムスタンプデータの切り捨てケースでは、次のオーバーライドルールがカスタム関数を使用してデータを比較します。このルールは、 Oracleの to_char 関数を使用してソース列のタイムスタンプ値を YYYY-MM-DD HH:MM:SS.ffffff 形式に変換し、MySQLの date_format 関数を使用してターゲット列の値を同じ形式に変換します。 { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "to_char(cast(${column-name} as timestamp(6)), 'YYYY-MM-DD HH24:MI:SS.FF6')” "target-function": "date_format(${column-name}, '%Y-%m-%d %H:%i%:%s.%f')" } 以下は、 IBM Db2 から PostgreSQL への移行時に特定の列のデータ長を比較する例です。 { "rule-type": "validation", "rule-id": "2", "rule-name": "2", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "length(${column-name})", "target-function": "length(${column-name})" } 次の検証ルールは、ソースとターゲットの列をテキストに変換し、 UTF8 でエンコーディングし、 MD5 ハッシュを計算し、ハッシュを大文字に変換し、最終的な出力型を VARCHAR(64) に設定した後、比較します。これは、 PostgreSQL から PostgreSQL への移行など、可変のデータベース間で一貫性のある一意の識別子として比較するのに役立つ可能性があります。 { "rule-type": "validation", "rule-id": "3", "rule-name": "3", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))", "target-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))" } AWS DMS は MD5 暗号化ハッシュを使用して、 SYS.DBMS_CRYPTO.HASH(TO_CLOB("COLUMN_NAME"), 2) などのLOBを検証します。ソースの Oracle で Federal Information Processing Standards (FIPS) (DPFIPS_140 = true) を有効にすると、バージョンによっては HASH_MD5 が機能しない可能性があります。この場合、 PostgreSQL 移行のために次のオーバーライドルールを検討できます。 { "rule-type": "validation", "rule-id": "4", "rule-name": "4", "rule-target": "column", "object-locator": { "schema-name": "SCHEMA_NAME", "table-name": "TABLE_NAME", "column-name": "COLUMN_NAME" }, "rule-action": "override-validation-function", "source-function": "dbms_lob.getlength(${column-name})" "target-function": "coalesce(char_length(${column-name}),0)" } クリーンアップ この投稿に沿ってテスト環境を作成した場合は、 AWS DMS リソースのクリーンアップ に記載された情報を使用して、この投稿で提案されたソリューションのテストに使用した環境を削除してください。 まとめ この投稿では、 AWS DMS のデータ検証のみのタスクの活用、監視、最適化、および一般的なユースケースの処理方法を示しました。ソースとターゲットのデータベースとデータ移行の要件によっては、 AWS DMS のデータ検証のみのタスクを検討し、移行に高い信頼性を持つことができます。 本ブログについてご質問がある場合は、 AWS サポートにお問い合わせください 。 投稿者について Jay Shin / Database Migration Specialist in DMA (Database Migration Accelerator) シンガポールを拠点として、クラウドネイティブのデータベースサービスを活用してお客様のデータベース移行とモダナイゼーションの加速を支援しています。 Donghua Luo / Senior RDS Specialist Solutions Architect AWSクラウドのデータベースサービスを活用して、AWSのお客様がより高い柔軟性、スケーラビリティ、および回復力を実現できるよう支援しています。 Barry Ooi / Senior Database Specialist Solution Architect AWSでのお客様のジャーニーの一環として、クラウドネイティブサービスを使用してデータプラットフォームを設計、構築、実装することが専門です。データ分析とデータの可視化に興味を持っています。 &nbsp; &nbsp; &nbsp;

はじめに 従来、高品質な 3D コンテンツの制作は複雑で時間がかかり、リソースを大量に消費するプロセスでした。3D モデリングやテクスチャリングから、最終的なシーンの組み立てやレンダリングまで、企業は専門的なスキルセットを必要としていました。特に現実世界の要素をデジタルで再現することが目的の場合、リアルな仮想環境、アセット、キャラクターを作り上げるには多大な労力を要しました。 例えば、この AWS ブログ では、 LiDAR スキャン 、 フォトグラメトリ 、 Neural Radiance Fields (NeRFs) などの技術を用いて、現実世界のオブジェクトや環境をデジタル化するプロセスを簡素化するリアリティキャプチャ技術について詳しく説明しています。その核となるアイデアは、シーンの複数の視点を捉え、それらの視点間の類似点と相違点を分析することで、シーンの深度と形状を推定するというものです。この自動化されたアプローチにより、手動での 3D モデリングの必要性がなくなり、従来の手法と比較して短時間で高品質なアウトプットを得ることができます。しかし、これらの技術には高価で特殊なハードウェアが必要であり、計算負荷が高く、通常はリアルタイムレンダリングのパフォーマンスが低いという課題があります。 最近、 3D Gaussian Splatting と呼ばれる新しい 3D Reconstruction およびラスタライゼーション技術が、このワークフローを加速させながら高品質なアウトプットを提供する可能性を示しています。この記事では、3D Gaussian Splatting とは何か、従来の 3D Reconstruction やリアリティキャプチャのアプローチに比べてどのような利点があるのか、3D コンテンツ制作にとってどのような意味を持つのか、そして組織が AWS を活用して 3D Gaussian Splatting を利用し、実世界の 3D アセットを大規模に再構成する方法について探っていきます。 3D Reconstruction とは？ 図 1. 3D Reconstruction は、2 次元の画像からコンピュータビジョン技術を用いて被写体の立体的な表現を生成し 3D 深度を推定します。 3D Gaussian Splatting について詳しく説明する前に、3D Reconstruction の概念を理解することが重要です。このプロセスは、写真やビデオフレームなどの 2D 入力を使用して、3D シーンやオブジェクトを再現し再構成(Reconstruction)することを含みます。例えば、カメラでシーンを撮影し、それをインタラクティブな 3D 環境に変換することなどが挙げられます。LiDAR のような 3D スキャン技術とは異なり、3D Reconstruction 技術は深度データを明示的な入力として提供するのではなく、2D 画像からカメラポーズを推定し、深度情報を推論して 3D 空間でシーンを再構成する必要があります。さらに、3D Reconstruction は multi-view stereo 、 structure from motion 、 shape from shading/texture/focus などの技術を活用して 2D から 3D を再現する複雑なコンピュータビジョンの問題として捉えることができます。 フォトグラメトリは 3D Reconstruction の最も古い例として、1980 年代から航空写真、測量、地図作成などの様々な用途で広く使用されてきました。 以前の AWS ブログ で説明されているように、フォトグラメトリは Structure from Motion と Multi-View Stereo を活用してシーンのポイントクラウドを生成します。そして、 Poisson や Ball-pivoting などの様々な手法を用いて、ポイントクラウドからテクスチャを重ねたポリゴンベースの 3D メッシュを作成することができます。より最近の 2020 年には、Neural Radiance Fields（「 NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis 」）が新しい 3D Reconstruction 技術として導入され、再構成されたシーンをメッシュではなくボリュームとして表現しました。これは、ニューラルネットワークを使用して光の放射特性を推定し、被写体周りの人工的な新しい視点を作成することで実現されました。フォトグラメトリと比較して、この新しいアプローチは一般的により効率的で、より速く出力を生成しますが、細部のレベルは時に劣ることがあります。 3D Gaussian Splatting とは？ 図2. 3D Gaussian Splats は 3D 空間のボリュメトリックな表現であり、従来のポリゴンベースのメッシュとは異なります。 2023 年、 SIGGRAPH で発表された論文「 3D Gaussian Splatting for Real-Time Radiance Field Rendering 」で、3D Gaussian Splatting が NeRF の概念を基に新しい 3D Reconstruction 手法として紹介されました。主な違いは、NeRF のように光の放射輝度を推定するためにニューラルネットワークを使用して新しい視点を作成するのではなく、3D Gaussian Splatting は視点依存の「ガウス分布」で 3D 空間を埋めることで新しい視点を生成するという点です。これらは、光の振る舞いを模倣するように色、密度、位置が調整された、ぼやけた 3D プリミティブとして現れます。 従来の手法がポリゴンメッシュの三角形を描画するのに対し、3D Gaussian Splatting はガウス分布を描画（または splat）します。これにより、数十億のガウス分布を使用して複雑な実世界の環境を再現する立体的な表現が可能になります。さらに重要なのは、3D Gaussian Splatting は NeRF とは異なり、ニューラルネットワークを使用せず、代わりに 確率的勾配降下法 などの従来の機械学習最適化手法を活用している点です。この手法は NeRF と類似していますが、ニューラルネットワークのレイヤーを使用しないため、計算効率が大幅に向上しています。 3D Gaussian Splatting 技術は、従来の技術と比較して一般的に視覚品質が向上し、生成時間が短縮されたフォトリアルな 3D Reconstruction を提供します。さらに、他の利点もあり、3D Reconstruction の新しい最先端技術として位置付けられています。 フォトリアルな 3D Reconstruction の最適化 図 3. 3D Gaussian Splats は、デジタルコンテンツ制作（DCC）ツールやゲームエンジンで使用して、リアルでインタラクティブな環境を構築できます。 3D Gaussian Splatting には、フォトグラメトリや NeRF などの従来の 3D Reconstruction 技術に比べていくつかの重要な利点があります： 生成時間の短縮 : 3D Gaussian Splatting は、3D 空間を明示的にモデル化するためのニューラルネットワークを使用せず、視点依存のガウス分布を直接描画します。これにより、3D シーンの再構成に必要な計算労力が大幅に削減され、処理能力と時間の両方が節約されます。 優れたリアルタイムパフォーマンス : 3D Gaussian Splats のボリュメトリックでポイントクラウドベースの性質により、ポリゴンベースのメッシュと比較してリアルタイムでのレンダリングが容易になります。また、3D Gaussian Splat 出力は NeRF よりもコンパクトであるため、Web やデバイス上でもパフォーマンスの高いリアルタイムアプリケーションが可能になります。 より安定したアウトプット : 3D Gaussian Splatting のアプローチは、ノイズに対してより高い耐性を示します。視覚的なアーティファクトが少なく、透過、反射、空白スペースなど、従来の 3D Reconstruction で課題になりやすい表現を適切に処理します。 これらの利点により、3D Gaussian Splatting は実世界を 3D で捉えて再現する際の障壁を大幅に低下させました。これは以下のことを意味します： 3D アセット作成の参入障壁の低下と市場投入までの時間短縮 : 従来の専門的な役割や使用例を超えて、3D の採用が加速し、使用範囲が拡大しました。複雑な 3D オブジェクトをモデリングするための専門知識はもはや必要ありません。必要なのはスマートフォンのカメラと、3D Gaussian Splatting を利用した 3D Reconstruction パイプラインのエンドポイントだけです。 インタラクティブでリアルタイムな3Dコンテンツ体験がより身近に : レンダリングに必要なハードウェア要件が軽減され、リアルタイムでの利用パフォーマンスが向上したことで、ライブ 3D コンテンツがあらゆるメディアで一般化されつつあります。特に一般消費者向けのコンピューティング、モバイル、AR/VR 分野で顕著です。高価な高性能コンピューティング環境がなくても、フォトリアルな 3D アセットを使用したインタラクティブな体験を大規模に提供できるようになりました。 3D Reconstruction 技術としての 3D Gaussian Splatting は、バーチャルプロダクションからデジタルツイン、E コマースの製品可視化に至るまで、複数の産業分野で 3D アセット作成へのアプローチを変革する可能性を秘めています。これらの体験は、インタラクティブで高忠実度な 3D アセットの性質から恩恵を受けます。そのすべてがクラウドを活用することで、よりスケーラブルで配信可能、そしてパフォーマンスの高いものとなります。 AWS を使用した大規模な 3D Gaussian Splatting 3D Gaussian Splatting は、他の 3D Reconstruction 技術と同様に、アセットの生成、管理、そしてグローバルなエンドユーザーへの配信において、クラウドのスケール、パフォーマンス、コンテンツ配信機能を活用するのに適しています。このようなワークフローを構築する方法は多数あります。 以下は、AWS での 3D Gaussian Splatting ワークフローの例で、全体的なプロセスを高レベルで図示しています： 図4. AWS における 3D Gaussian Splatting ワークフローの例。 このワークフローは以下のコンポーネントで構成されています： 入力 : 2D の動画や画像メディアが取り込まれ、ワークフローへの入力として使用されます。 ワークフロー : ワークフローは複数のパイプラインで構成され、それぞれが独立して直列に処理されます。 パイプライン : 各パイプラインは、標準化された入出力を持つ自己完結型のタスクです。パイプラインの使用により、スコープを区画化し、互いに独立して実行できる個別のプロセスを分離できます。このモジュール性により、各パイプラインのコードベースを最適化し、これらのプロセスを他のワークフローで再利用することができます。この例では、画像処理、Structure from Motion、3D Gaussian Splatting のトレーニングと初期化、3D Gaussian Splatting ビューワーのパイプラインがあります。 出力 : 3D Gaussian Splatting の生成では、ユーザーが Web ブラウザで適切なビューワーを使用して閲覧できる 3D オブジェクトが出力されます。 次の図は、前述の 3D Gaussian Splatting ワークフローがどのように AWS サービスを使用して実装できるかを示しています: 図5. 3D Gaussian Splatting のワークロードは、プロセスのオーケストレーションと処理に AWS サービスをビルディングブロックとして活用することで大きな恩恵を受けます。 この図は以下の主要コンポーネントを示しています: 開発者は AWS Cloud Development Kit (CDK) を使用して、使用前に一度だけインフラストラクチャを作成およびデプロイします。 AWS CDK は、デプロイ中に必要なインフラストラクチャの情報（URI、ARN）を AWS Systems Manager Parameter Store に保存します。 デプロイ後、ユーザーはインターネットに接続されたローカルブラウザでウェブサイトの URL を起動します。 ウェブサイトは Amazon Simple Storage Service (S3) でホストされ、 Amazon CloudFront を使用してグローバルに配信されます。 ユーザーは Amazon Cognito ユーザープールを使用して認証情報を入力してログインします。 ユーザーは UI で新しいアセット（動画または一連の画像）をアップロードし、API コマンドを発行して 3D Gaussian Splatting ワークフローを開始します。 ワークフローの状態とアセットの詳細は Amazon DynamoDB に保存されます。 AWS Step Functions ワークフローは、パイプラインを実行するプロセスハンドラーとして Amazon Elastic Container Service (ECS) を呼び出します。 Amazon ECS は、コンテナ用の Amazon Elastic Container Registry (ECR) 内のイメージを使用します。 Amazon ECS は、3D Gaussian Splatting パイプラインを実行するためのコンピューティングリソースを動的に確保し、コンテナをホストします。 生成されたアセットは Amazon S3 からパイプラインにロード/保存されます。 プロセスハンドラーが完了すると、ワークフローも完了します。 データベースは状態とワークフローの詳細で更新されます。 Amazon Simple Notification Service (SNS) を使用して、アセット作成完了時にユーザーに通知できます。 ユーザーは Web ブラウザで splat を表示できます。 Amazon CloudWatch を使用してログにアクセスできます。 AWS での 3D Gaussian Splatting を含むワークロードは、AWS のマネージドサービスと共にオープンソースソフトウェアやサードパーティツールを統合できます。例えば、画像の前処理にオープンソースツールを使用し、AWS のマネージドサービスを活用して再構成ジョブを実行することができます。 このワークフローに統合できる AWS サービスの例は他にもたくさんあります。AWS で 3D Gaussian Splatting のワークロードを実行することで、顧客は以下のようにアプリケーション機能を拡張できます: 弾力的な分散処理 : Amazon ECS、 Amazon Elastic Kubernetes Service (EKS) と AWS Batch を使用して、3D Reconstruction ジョブをパッケージ化し、複数のコンピュートノードに並列化および分散させることで、生成時間を短縮し、必要に応じてスケールアップ・ダウンできます。 AWS Deadline Cloud のようなコンピュートファームマネージャーを使用して Open Job Description (OpenJD) の互換性を活かして再構成パイプラインの実行を効率的に制御します。 コンテンツの保存と管理 ：AWS のオープンソース Visual Asset Management System (VAMS) ソリューションを利用して、Amazon S3 と Amazon DynamoDB を活用し、スキャンした 3D アセットを保存、管理、取得して内部コラボレーションを行います。 グラフィックスコンピューティング ： Amazon Elastic Compute Cloud (EC2) と、NVIDIA L4 Tensor Core GPUを搭載した最新世代の Amazon EC2 G6 インスタンス を活用することで、グラフィックスアプリケーションで 3D アセットを効率的に処理し、活用することができます。 コンテンツ配信とストリーミング ：Amazon CloudFront を使用して、再構成されたインタラクティブな 3D コンテンツを、低レイテンシーでエッジから、Web やモバイルでグローバルにストリーミングおよび配信します。 分析とインサイト ： Amazon Kinesis 、 Amazon Athena 、 Amazon QuickSight などの AWS 分析サービスを活用して、3D Reconstruction パイプラインからインサイトを得ます。パイプラインのパフォーマンスを追跡し、ボトルネックを特定し、大規模にコンピューティング効率を最適化します。 AI/ML 統合 ： Amazon SageMaker や Amazon Bedrock などのマシンラーニングおよび生成 AI サービスを統合して、例えば画像セグメンテーションやセマンティックラベリングなどのコンピュータビジョンを通じて、3D Reconstruction をさらに強化します。 デジタルツイン ： AWS IoT TwinMaker でスキャンした 3D アセットを使用して、実世界のシステムや操作を表現するデジタルツインアプリケーションを強化します。 AWSは、3D Gaussian Splatting ワークロードのライフサイクル全体をサポートする幅広いサービスを提供しています。これには、データ取り込み、分散処理、ストレージ、配信、レンダリング、分析、AI/ML、デジタルツインが含まれます。 まとめ 昨年、論文が発表されて以降、3D Gaussian Splatting は 3D アセットおよびコンテンツ制作の分野に革新をもたらし、3D Reconstruction リアリティキャプチャ技術のアクセシビリティと効果を大幅に向上させました。 3D Gaussian Splatting の分野は急速に進化を続けており、AWS パートナーからの継続的なイノベーションが行われています。NVIDIA は「 Text-to-4D with Dynamic 3D Gaussians and Composed Diffusion Models 」というアプローチを探求し、3D Gaussian Splatting と AI 拡散モデルを統合して、テキスト入力を通じてダイナミックなアセットを生成することを目指しています。また、Meta は「 Robust Gaussian Splatting 」に取り組んでおり、視覚的な不整合を減らすことで、スマートフォンでの撮影から得られる 3D Reconstruction 出力の堅牢性を向上させることに焦点を当てています。 AWS では、スケーラブルな 3D Gaussian Splatting パイプラインを実現するためのクラウドインフラストラクチャ、サービス、およびパートナーエコシステムを提供しています。これには、動画データの取り込み、モデル生成のためのコンピューティング、3D アセットの保存と管理、そしてあらゆるデバイスへのリアルタイムレンダリングと配信が含まれます。これにより、メディア、小売業、製造業などの様々な産業分野のアプリケーションにフォトリアルな 3D 機能を組み込むプロセスが簡素化されます。 私たちは、皆さんが 3D Gaussian Splatting や 3D Reconstruction 技術を自ら試すことを推奨します。GitHub 上の 「3D Gaussian Splatting for Real-Time Radiance Field Rendering」リポジトリ を参照して実装手順を確認し、今すぐ AWS 上でデプロイしてみてください。 注) 上記リポジトリで公開されているソースコードの利用にあたっては事前に ライセンス を確認し、その範囲内でご利用ください。 著者について Stanford Lee Stanford Lee は、Amazon Web Services のテクニカルアカウントマネージャーであり、Spatial Computing 領域の技術コミュニティメンバーです。大企業の上級技術リーダーシップに技術的なガイダンスを提供しています。この役割において、顧客とのエンゲージメントをリードし、技術的なプロトタイプを構築し、没入型3Dコンピューティングおよび拡張現実、仮想現実、複合現実（AR/VR/XR）技術に関する思想的リーダーシップを提供しています。オーストラリアのシドニーを拠点とし、以前は日本とシンガポールで勤務した経験があります。 Dario Macagnano Dario は、AWS のビジュアルコンピューティング部門のシニアソリューションアーキテクトです。 Eric Cornwell Eric Cornwell は、AWS の OSET(Open Source and Emerging Technologies）チームのシニア空間ソリューションアーキテクトです。様々な工学の学位を持ち、出版物を通じて貢献し、拡張現実に関する特許を保有しています。Eric は、最先端の没入型技術を活用してスケーラブルでインテリジェントな3Dソリューションを開発することに専念する熟練したビルダーとして知られています。新興技術における専門知識を活かし、AWS の顧客に価値をもたらす革新的な空間コンピューティングおよび3Dアプリケーションの創造において重要な役割を果たしています。 この記事は 3D Gaussian Splatting: Performant 3D Scene Reconstruction at Scale を翻訳したものです。翻訳はソリューションアーキテクトの小森谷が担当しました。