勝負が紙一重で決まる Formula 1 (F1) の世界では、継続的な成功にはイノベーションが不可欠です。何十年もの間、チームは自動車技術の限界に挑戦し、常に変わりゆく環境のなかで優位に立つことを模索してきました。 Scuderia Ferrari HP 社と Amazon Web Services (AWS) のコラボレーションは、データ主導型の製造によって組立プロセスを再定義しています。 イノベーションを求める共通の取り組みにより、製造データクラウド移行のためにAWS は Scuderia Ferrari HP 社と協力しました。これには、あらゆる F1 カーの生命線である、個々のパワーユニットの準備と組み立て中に生成される膨大な量のデータが含まれていました。 Amazon SageMaker AI による機械学習 (ML) の機能を活用することで、チームは新しく作成したデータレイクの上に高度な処理パイプラインを構築しました。このアプローチにより、チームは詳細を調べ、結果を過去のデータと相関させることができ、分析能力が向上しました。チームは、以前の手動による方法と比較して、少なくとも 4 倍の量のデータを処理できるようになり、さらに半分の時間で分析結果を得ることができるようになりました。 レギュレーションとスピードに合わせたパワーユニットの調整 トラック上で最速で規制車が登場する F1 は、最高レベルのモータースポーツレースであり、国際自動車連盟 (FIA) によって厳しく規制されています。毎シーズン、ドライバーは、内燃エンジン、2つの電気モーター、ターボチャージャーのほか、エネルギー装置、電子制御機器、排気装置など、F1 カーに欠かせないパワーユニットに一定の要素を割り当てられます。 F1 はビッグデータのスポーツですが、ごく僅かなデータポイントによってチームの勝利を逃すことがあります。部品が制限を超えるたびにドライバーはペナルティを課せられるため、チームは厳しいテストを行い、シーズン前とシーズン中のパワーユニットの変更について非常に戦略的に取り組む必要があります。 2024 Formula One Sporting Regulations によりますと、一度制限を超える部品を使用されると、10 グリッドのペナルティが発生し、車が表彰台を獲得する可能性が大幅に低下します。 「パワーユニットは非常に複雑なため、当社の技術チームはレースで潜在的な問題を引き起こしうる欠陥に対処し先手を打っています」と Scuderia Ferrari HP Power Unit Assembly の責任者である Alessio Simi 氏が述べています。「AWS を導入したことで、他の方法では見逃してしまう可能性のある異常を検出でき、メインイベントのかなり前に調整を行う機会を得ることができました。」 図1 : 組み立てプロセスの一部 機械学習と生成 AI によるエンジニアリングの強化 2024 年のレースシーズンに向けて、チームはアプローチを改善し、エンジニアがより良いデータ分析結果をより迅速に入手するための方法を模索し始めました。モータースポーツシーズンは通常 3 月から 12 月にかけて行われるため、エンジニアがプレシーズンのデータ分析を行う時間は限られており、各レースの合間に最適化や調整を行う時間はさらに短くなります。AWS の強力なデータ基盤により、Scuderia Ferrari HP 社はアセンブリを一貫して監視できるようになり、コンポーネントを過度に交換しなくてもパワーユニットが F1 シーズン全体の厳しい状況に耐えられるようにします。 AWS は Scuderia Ferrari HP 社と協力して、Amazon Simple Storage Service ( Amazon S3 ) を使用してデータレイクを構築しました。その後、チームは Amazon SageMaker AI を使用して処理パイプラインを構築し、複数の異なるソースからのデータを統合しました。製造中の包括的なテストと測定は、潜在的な欠陥や早期摩耗が発生しやすい部分を特定するのに役立ち、チームはコンポーネントが使用される前にこれらの問題に対処できます。 以前は、データが複数のシステムに分散している状態で、データ分析と評価は個々のエンジニアが手動で行っていたため、長期的に発生する故障につながる可能性のある問題の原因を突き止めることは困難でした。たとえば、ボルトが常に締めすぎているような僅かな違いにより、時間の経過とともにエンジンが不安定になり、トラック上に問題を引き起こすリスクが高まる可能性があります。各車に 300 個のセンサーが搭載されており、膨大な量のデータを手動で確認することはほとんど不可能になりました。「当社のエンジニアの専門知識は不可欠ですが、人間がテラバイト単位のデータを分析するのは合理的ではありません。」と Simi 氏は言います。 データが統合されると、データ分析を専門とする Scuderia Ferrari HP 社のエンジニアリングチームが Amazon QuickSight で一元化されたダッシュボードビューを作成しました。これにより、あらゆる専門分野のエンジニアが組み立てを監視し、潜在的な偏差をほぼリアルタイムで観察できるようになりました。このアクセスと可視性の向上により、チームはインサイトを得るまでの時間を平均 50% 短縮しました。「この反応性のおかげで、プロセスやコンポーネントに直接介入できるため、間違ったフィッティングを完成させたり、材料を無駄に浪費したりすることがなくなります。」と Simi 氏は付け加えます。 チームが監視する要素の 1つがドリフトです。ドリフトとは、部品の重要な測定値や性能パラメータが時間の経過とともに徐々に意図せず変化することです。たとえば、電力や燃料効率が徐々に低下したり、シーズンを通してセンサーの精度が徐々に低下したりすることがあります。「すべての情報が単一のデータレイクにあるため、傾向とドリフトを評価して異常値との関係を確認したり、製造プロセスにおける形状の差異を特定したりすることできます。」 図 2 : Amazon QuickSight ダッシュボード Amazon Q in QuickSight の新機能により、レーシングエンジニアは Q&A 回答で重要な洞察やトレンドを発見したり、自然言語プロンプトで独自のダッシュボードを作成したりして、継続的なメンテナンスとレビューを行うこともできます。「このスポーツではスピードが不可欠です。すでに当社のデータとインフラはAWS上で良好な状態にあり、より迅速かつ正確に問題を発見し、調整を行うことができます。」 まとめ 自動化されたデータ収集と処理を ML に委任することで、Scuderia Ferrari HP 社は洞察をより迅速に収集、分析、行動に移すことが可能になりました。このプロジェクトがパワーユニット製造で最初に成功したことを踏まえ、同様の戦略が性能に関連する他の用途にも展開しようとしています。「シーズン中に大幅なアップグレードを導入することは規制によって制限されていますが、私たちのデータアーキテクチャは将来のイノベーションへの道を開いています。」と Simi 氏はまとめました。 Scuderia Ferrari HP チームは、メルボルンで開催されるオーストラリアグランプリで始まる 2025 年シーズンの準備に懸命に取り組んできました。あらゆるテスト、シミュレーション、および実際のパフォーマンスデータポイントを取得できると、改善の余地がある領域に関する貴重な洞察が得られます。「これにより、次世代のパワーユニット設計の主要な開発領域を特定し、優先順位を付けることができ、競争の激しい F1 の世界で大きく有利なスタートを切ることができました。」 お客様がどのようにデータ主導型の AWS ソリューションを活用して、スポーツの観戦、プレー、管理の方法を改革しているかをこちらで確認できます。 Keely O’Neill Keely O’Neill は、Amazon Web Services (AWS) でスポーツマーケティングのシニア統合マーケティングマネージャーで、Formula 1、Ferrari 社、Bundesliga とのパートナーシップの統合マーケティングを率いています。体験型マーケティング、コミュニティエンゲージメント、デジタルマーケティングで 12 年以上の経験を持つ Keely は、独自の専門知識を持ち、好奇心とデータインサイトに基づいた戦略的なキャンペーンを通じて、インパクトのある顧客体験を生み出します。現在の役職に就く前は、AWS スタートアップのグローバルマーケティングを担当し、Brooks Running Company 社と Tableau Software 社で役職を歴任しました。 このブログの翻訳はソリューションアーキテクトのシャルノ ミカエルが担当しました。原文は「 How AWS supports Scuderia Ferrari HP to optimize Formula 1® power unit assembly process 」です。

4 月 7 日週から AWS Summit のシーズンが始まります! これらの無料のイベントは世界中で開催されており、AWS のクラウドコンピューティングコミュニティが一堂に会してつながり、コラボレートし、学んでいます。オンライン参加か現地参加かにかかわらず、これらの会合は AWS の知識を深める貴重な機会を提供します。私は、今週開催される、フランスで最も大きいクラウドカンファレンスの Paris Summit 、そして月末に開催される London Summit に出席する予定です。小さなポッドキャスト録音スタジオを用意し、そこでフランスとイギリスのお客様にインタビューして、 AWS Developers Podcast と 語の AWS ポッドキャスト の新しいエピソードを制作します。 いますぐご登録ください! それでは、3 月 31 日週の新しいお知らせを見てみましょう。 3 月 31 日週のリリース KubeCon London では、 EKS コミュニティアドオンカタログ をご紹介しました。Kubernetes ユーザーは、強力なオープンソースツールを使用して簡単に Amazon EKS クラスターを強化できるようになります。このカタログは metrics-server 、 kube-state-metrics 、 prometheus-node-exporter 、 cert-manager 、 external-dns などの重要なアドオンのインストールを合理化します。これらのコミュニティ主導型アドオンを EKS コンソールと AWS CLI に直接統合することで、お客様は柔軟性とセキュリティを維持しながら、運用の複雑さを軽減し、デプロイを迅速に行うことができます。今回の発表は、Kubernetes コミュニティに対する AWS の取り組みを反映したもので、手動によるインストールやメンテナンスの手間をかけることなく、信頼できるオープンソースソリューションへのシームレスなアクセスを実現します。 Amazon Q Developer が Amazon OpenSearch Service と統合 され、自然言語による探索と AI 支援のデータ視覚化が可能になり、運用分析が強化されました。この統合により、運用データのクエリと視覚化のプロセスが簡素化され、従来のクエリ言語やツールに関連する学習曲線が短縮されます。インシデント対応中、Amazon Q Developer は状況に応じた要約とインサイトをアラートインターフェイス内で直接提供し、迅速な分析と解決をサポートします。この進歩により、エンジニアはトラブルシューティングプロセスを合理化し、監視インフラストラクチャを改善することで、イノベーションにより集中できるようになります。 Amazon API Gateway は、商用リージョンと AWS GovCloud (米国) リージョンの両方において、すべてのエンドポイントタイプ、カスタムドメイン、管理 API でデュアルスタック (IPv4 と IPv6) エンドポイントのサポートを開始 しました。この拡張機能により、REST、HTTP、WebSocket API、カスタムドメインが IPv4 クライアントと IPv6 クライアントの両方からの要求を処理できるようになり、IPv6 へのスムーズな移行が容易となり、IPv4 アドレスの不足に対処できます。さらに、AWS は、IPv4 と IPv6 を介したシームレスな接続を実現する デュアルスタックのパブリックエンドポイントを取り入れた AWS Identity and Access Management (IAM) 、 お客様が IPv6 アドレスを使用してリソース共有を管理できるようにする AWS Resource Access Manager (RAM) などの最近の更新により、IPv6 の採用への取り組みを継続しています。 Amazon Security Lake のお客様も、新しいデュアルスタックのエンドポイントを介して、インターネットプロトコルバージョン 6 (IPv6) アドレスを使用してサービスを設定および管理 できるようになりました。これらの進歩により、ネットワークインフラストラクチャの互換性と将来にわたる保証が、より広範囲に及ぶようになります。 Amazon Simple Email Service (SES) は、v2 API の E メール添付ファイルのサポートを開始しました。ユーザーは、手動で MIME メッセージを作成しなくても、PDF や画像などのファイルをメールに直接含められるようになります。この機能強化により、情報量の多いメールコンテンツを送信するプロセスが簡素化され、実装の複雑さが軽減されます。SES は、サービスが利用可能なすべての AWS リージョンの添付ファイルをサポートします。 Amazon Neptune はサービスレベル契約 (SLA) を更新し、マルチ AZ DB インスタンス、マルチ AZ DB クラスター、マルチ AZ グラフ構成の月間稼働率を以前の 99.9% から 99.99% に引き上げ ました。この強化は、ミッションクリティカルなアプリケーションに対して、可用性と信頼性の高いグラフデータベースサービスを提供するという AWS の取り組みを示しています。改善された SLA は、Amazon Neptune が提供されているすべての AWS リージョンで利用できるようになりました。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 4 月 7 日週のニュースは以上です。4 月 14 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

AWS Amplify Hosting では、より多くの Amplify アプリを 1 つのリポジトリに接続できるようになりました。この変更により、開発者が Git プロバイダーと統合する方法が改善され、特にモノレポアーキテクチャに有益です。 Amplify は、関連するすべてのアプリに対して 1 つのリポジトリにつき 1 つの Webhook を使用するようになり、開発ワークフローが効率化されました。具体的な制限の詳細については、 ドキュメント を参照してください。 以前は、Amplify ユーザーは Git プロバイダーが提供する Webhook の上限に制約されていました。Amplify はリポジトリに関連付けられた各アプリごとに新しい Webhook を作成したため、単一のリポジトリに複数の Amplify アプリをリンクしているユーザーは、その上限にすぐに達してしまい、アプリをさらに追加できませんでした。これは、複数のプロジェクト（複数のAmplifyアプリ）が単一のリポジトリ内に存在する、モノレポで作業しているチームにとっては特に難しいことでした。 Git プロバイダーによって許可される Webhook の具体的な数は異なりますが、これらの制限はプロジェクトを拡大したり、複雑なリポジトリ構造で作業を行ったりするチームにとって障害となっていました。 GitHub には 20 個の Webhook 制限 があります GitLab には 100 個の Webhook 制限 があります BitBucket には 50 個の Webhook 制限 があります 統合された Webhook Amplifyに関連するすべての Webhook を 1 つの統合された Webhook にまとめることで、この問題を解決します。これにより、リポジトリの管理が簡素化され、Webhook の制限に縛られることなく、すべての関連する Amplify アプリが更新とトリガーを受け取ることができます。 主な利点 Git プロバイダーの制限を克服: 現在の Webhook の制限を取り除き、必要な数の Amplify アプリを単一のリポジトリに接続できるようになります。 モノレポサポートの強化: 複数のプロジェクトが単一のリポジトリを共有するモノレポ構造で作業する際に、より柔軟性と効率性を得られます。 管理の簡素化: 単一のリポジトリの Webhook を利用して複数の Amplify アプリを管理でき、複雑さと潜在的な障害ポイントを減らすことができます。 ワークフロー統合の改善: 開発プロセスの他の重要なワークフローに Webhook スロットを解放できます。 統合された Webhook の概要 新しいアプリの場合 Amplify Hosting でウェブアプリをデプロイ します。Webhook 機能が組み込まれるので、リポジトリに自動的に実装されます。 既存の Amplify ユーザー向け この新機能を利用するには、リポジトリを Amplify アプリに再接続する必要があります。手順は次のとおりです。 AWS 管理コンソールで Amplify アプリに移動します。 アプリのリポジトリ設定を探します。 リポジトリ情報の横にある「再接続」ボタンをクリックします。 既存の Webhook を新しい統合された Webhook に置き換えるアクションを確認します。 手順 2 つの Amplify アプリ を含むリポジトリから、新しい統合された Webhook に切り替える例を示します。 各 Webhook は次のようになります。 次に Amplify Console に移動し、 App settings → Branch の Reconnect Repository ボタンを見つけてください。 Configure GitHub App と Complete installation をクリックしてください。 しばらくすると、リポジトリが統合された Webhook に切り替わったことがわかります。 これで準備は整いました。このリポジトリに接続された新しい Amplify アプリは、ここで同じ統合された Webhook を使用します。 重要な考慮事項 マイグレーション中の Webhook の制限: すでに Git プロバイダーが許可されている Webhook の最大数に達している場合、自動マイグレーションが機能しない可能性があります。この場合、事前に既存の Webhook 1 つ以上を手動で削除する必要な場合があります。 リージョン別の操作: Webhook の移行を含むすべての操作は、リージョン別に行われます。つまり、移行は Amplify アプリを再接続したリージョンの Webhook に対してのみ行われます。 まとめ AWS Amplify Hosting の統合された Webhook の導入により、リポジトリ管理が簡素化され、モノレポなどの複雑なプロジェクト構造のサポートが強化されました。 Webhook のオーバーヘッドを削減し、Git リポジトリと Amplify アプリの接続をストリーム化することで、開発者はインフラストラクチャの制限の管理よりも優れたアプリケーションの構築に集中できるようになりました。 私たちは、この機能が特に大規模で複雑なリポジトリを扱う際の開発ワークフローを改善することを心待ちにしています。 Amplify コンソール で Next.js、Nuxt、React、Angular、Vue、その他のフロントエンドアプリをデプロイし、 Discord の当社コミュニティに参加して、ご意見やご経験を共有してください。 本記事は、2025 年 3 月 10 日に公開された Simplifying Multi-App Management in AWS Amplify Hosting を翻訳したものです。翻訳は Solutions Architect の吉村が担当しました。 著者について Matt Auerbach, Senior Product Manager, Amplify Hosting 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 Twitter @mauerbac. He previously worked in Developer Relations at Twitch, Optimizely & Twilio. Linsong Wang, Software Development Engineer, Amplify Hosting Linsong 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, Linsong enjoys exploring cooking recipes, playing piano, and building life improvement prototype

本記事は 2025 年 4 月 9 日に公開された “ Speaking Your Language: Expanded language support in Amazon Q Developer ” を翻訳したものです。 ソフトウェア開発がますますグローバル化するなかで、多言語に対応したツールの必要性は最優先事項になっています。本日は、 Amazon Q Developer における言語サポートの拡張を発表できることを嬉しく思います。この投稿では、世界中の開発者が利用する強力なプラットフォームである Amazon Q Developer における、言語サポートの拡張についてご紹介します。Amazon Q Developer は、アーキテクチャの議論、ドキュメントの作成、インターフェイスのデザイン、アプリケーション開発など、さまざまな用途で活用されています。 プログラミングの共通言語として英語が使われているのは変わりませんが、現代のソフトウェア開発の実態はコードにとどまりません。世界中の開発者が Amazon Q Developer を活用して、アーキテクチャの意思決定を議論したり、ドキュメントを作成したり、ユーザーインターフェースを設計したり、世界中のユーザーを想定したアプリケーションを構築したりしています。言語サポートが拡張されたことにより、Amazon Q Developer は、システムアーキテクチャの設計、ドキュメントの生成、アプリケーションのローカライズ戦略の検討など、複雑な技術的概念についても、開発者がもっとも使いやすい言語で、より自然でスムーズに対話できるようになりました。 この言語サポートの拡張の効果は、以下の画像で示されています。私は「コンテナホスティングに関する質問」を英語・中国語・ヒンディー語・スペイン語で尋ねました。Amazon Q Developer は、それぞれの言語で正確かつ完全な回答を返すだけでなく、技術的な正確さを保ちつつ、言語ごとのニュアンスにも対応しています。さらに、Amazon Q Developer はユーザーが使用している言語に応じて、関連するフォローアップ質問を提案してくれるため、より直感的で自然な会話体験が可能になります。このように、どの言語でも自然にやり取りできることは、開発者の集中力を妨げず、言語の壁による精神的負荷を取り除く効果があります。 今回の言語サポート拡張は、 統合開発環境 (IDE) および コマンドラインインターフェース (CLI) ですでに利用可能で、 AWS マネジメントコンソール にも近日対応予定です。私の IDE では、 チャット 、 インラインチャット 、 インライン提案 、 エージェント などに対して、多言語をサポートしました。以下の例では、私はフランス語で Amazon Q Developer に「コードに TSDoc コメントを追加してほしい」とインラインチャットで依頼しました。 たとえば、韓国・ソウルで韓国語のドキュメントを書く開発者、スペイン・マドリードでスペイン語でアーキテクチャ設計を検討するスタートアップ、ポルトガル語でコラボレーションするブラジルのチームといったどなたに対しても、Amazon Q Developer は、あなたの開発の旅路と、あなたのお好きな言語をサポートできる準備が整いました。この言語サポートの拡張は、Free Tier と Pro Tier の両方のユーザーに本日より提供開始されます。ぜひ Amazon Q Developer の利用を開始し 、フィードバックをお寄せください。私たちは皆さんと共に、ソフトウェア開発の未来をより包括的でアクセスしやすいものにしていきます。 翻訳はApp Dev Consultantの宇賀神が担当しました。

はじめに AWS は、2024年12月13日に大阪リージョンに属する初のAWS Direct Connect ロケーションであるTelehouse OSAKA2(以後、OSAKA2)の開設を 発表 しました。これにより、 AWS Direct Connect を利用して関西地域に閉じたロケーション冗長を行うことが可能になり、AWS クラウドの大阪リージョンをメインリージョンとしたワークロードおよびハイブリッドネットワークをより最適化することができます。もちろん、東京や海外など他のリージョンへの接続にも利用できます。 関西地域のDirect Connect ロケーションは、Equinix OS1(以下、OS1)に続いて二つ目となります。しかし、ご存じでしょうか。 OS1 は古くからあるため、東京リージョンに属しています 。本記事では、この二つのDirect Connect ロケーションを活用したオンプレミスネットワークとAWS クラウドとの接続に関するアーキテクチャと、その考慮点について解説します。他のリージョンやDirect Connect ロケーションをお使いになる方も、参考となるよう記述しています。 なお、この記事はDirect Connect とeBGP の基礎知識を有した方を対象としています。 ロケーション冗長について Direct Connect では、お客様ネットワークとの接続点をDirect Connect ロケーションと呼称しています。これは、データセンター内で光ファイバーによる直接接続を行う物理的な場所を示しています。 こちらのページ を参照すると、そのリストを確認することができます。 ネットワークの物理レイヤーを検討する際、Direct Connect ロケーションの選定は重要です。WAN サービスなどのお客様ネットワークとAWS クラウドを接続する場合、地理的に近いほど高いパフォーマンスを期待できるためです。関西地域にデータセンターや本社機能を持つお客様や、大阪リージョンを主に利用しているお客様は、OSAKA2 の開設により、OS1と組み合わせてロケーション冗長を構成することが可能になりました。 Direct Connect では、お客様のルーターと、AWS のルーターとの間でeBGP を構成します。お客様のルーターは、ご利用の回線サービスにより、Direct Connect ロケーションと同一のデータセンターに設置することも、離れた別のデータセンターやオフィスなどに設置することもできます。この構成に関わる技術要件は、AWS ルーターとお客様ルーターをレイヤー2で接続し、eBGPピアを構成するためのPoint to Point の通信を行えることになります（eBGP マルチホップを利用することはできません）。 図1では、OS1 とOSAKA2 の二つのDirect Connect ロケーションと、4つのDirect Connect 接続を組み合わせて、データセンターレベルの障害にも対応できる可用性を実現する際の構成例を示しています。Direct Connect では、 回復性に関する推奨事項 や サービスレベルアグリーメント(SLA) にも示しているとおり、重要なワークロードに対しては複数のロケーションを活用することを推奨しています。 図1. 最大回復性を満たすアーキテクチャー例 シナリオ1 アクティブ /スタンバイ構成 複数のDirect Connect を活用して可用性を高めるには、きめ細かいトラフィックコントロールが必要になります。ここでは、理解しやすいよう4つのDirect Connect 接続にそれぞれ優先度を設定し、アクティブの接続が切断された場合、優先度順にフェイルオーバーを行うことを要件とします。つまり、4重の冗長をとる構成となります。図2は、その設計を示しています。なお、経路ごとに優先順位を制御することも可能です。 図2.アクティブ/スタンバイ構成の各接続の優先度設計 シナリオ1-1 AWSからお客様ネットワークに向かうトラフィックのコントロール AWS のBGP ルーターがお客様のBGPルーターから受信した経路情報は、図2の構成の場合Direct Connect Gateway やAWS Transit Gateway に伝搬されます。4つの回線のうちどの回線がベストパスとして採用されるかについては、受信した経路情報のBGP アトリビュートに依存します。なお、Direct Connect では、AWS ルーターのBGP アトリビュート値を明示的に設定をすることはできないことに注意してください。したがって、図2のような優先度になるようにBGP アトリビュートの設定をお客様ルーターで行う形になります。 では、具体的にどのようにアトリビュートを設定するべきでしょうか。ここで、BGP のベストパス選択アルゴリズムを振り返ります。このような構成の場合に考慮すべきは、ローカルプリファレンス、AS_PATH、Multi-Exit Discriminator (MED)の3つで、記載順で優先順位が高くなります。MED については優先度が低いことから、 ドキュメント に記載の通り、積極的な活用は推奨していません。 最もシンプルな方法は、お客様側のBGP ルーターで、AWS へ広告する経路にAS_PATH Prepend を使って優先度を操作することです。AWS側で暗黙に設定しているローカルプリファレンス値が同値であると仮定し、図3に示すようにAS_PATH 長によってベストパスを決定させる狙いです。このアプローチは、これまで多くのケースで採用されてきました。 図3 AS_PATHによる優先度設計のアプローチ ただし、注意してください。今回の構成例の場合、これだけではベストパス選択は期待通りに行われません。これは、 OS1が東京リージョンに属し、OSAKA2が大阪リージョンに属することに起因します 。 Direct Connect では、AWS からお客様ネットワークへのパスを最適化するため、ローカルプリファレンス 値が暗黙的に設定されます。これは、通信の発信元リージョンと、宛先のDirect Connect ロケーションがどのリージョンに属するかによって決定されます。例として、大阪リージョンから発信された通信は、大阪リージョンに属するOSAKA2を優先するようにローカルプリファレンス 値が設定されます。ローカルプリファレンス 値はAS_PATH 属性の前に評価されるため、OSAKA2がベストパスに採用されます。 では、OS1を優先したい場合どうするべきでしょうか。Direct Connect ではこのようなケースのため、暗黙的に設定されるローカルプリファレンス 値をお客様の意図通りに上書きするためのBGP Community タグ機能を提供しています。 お客様ルーターから受信した経路に、BGP Community アトリビュートの指定されたタグが設定されていると、AWS は以下のような優先順になるようローカルプリファレンスの値を上書きします。詳しくは、 ドキュメント をご参照ください。 7224:7100 : 優先設定: 低 7224:7200 : 優先設定: 中 7224:7300 : 優先設定: 高 上記の通り、3段階で設定することができます。今回の例では4回線あるため、3段階では不足です。しかしながら、AS_PATH Prepend を組み合わせることで、意図した制御を行うことができます。今回は、BGP Community タグを用いてローカルプリファレンス値を全て等コストになるよう上書きし、AS_PATH による評価で優先度1の接続をベストパスとして選択させるようにします。 図4は、その設定を図示しています。 図4. Community タグとAS PATH Prepend によるトラフィックコントロール このように、Community タグと AS PATH Prepend によってAWS からお客様ネットワークへのベストパスをコントロールできます。優先度1のBGPピアが切断された場合、優先度2にフェールオーバーします。優先2が切断されたら優先度3に・・という形で、順にフェールオーバーさせることができます。 シナリオ1-2 お客様ネットワークからAWS に向かうトラフィックのコントロール 続いて、お客様ネットワークからAWS に向かうトラフィックのコントロールについてです。優先度の要件は、前述の逆向きの通信と同様とします。 Direct Connect では、お客様のBGP ルーターに対して広告する経路のBGP アトリビュートをカスタマイズすることはできません。また、特別な設定があらかじめ行われていることもありません※1。したがって、AWS からの経路を受信するお客様のネットワークで自由にトラフィックコントロールを行うことができます。 どのように優先度を設定するかについては、お客様ネットワークの構成によってさまざまな方法が考えられます。例えば、お客様ネットワークはOSPF で構成され、Direct Connect のBGP 経路はOSPF ネットワークに再配布するようなケースも考えられます。お客様ネットワークが通信事業者のWAN サービス等である場合は、そのサービス仕様にも依存します。今回は、図に存在するCustomer WAN が、BGP アトリビュートによる制御に対応しているWAN サービスであると仮定し、AS_PATHにより制御する例をご紹介します。 図5では、AWSから受け取った経路をWANサービスに伝搬する様子を表現しています。 図5. お客様ネットワークからAWS 向けトラフィックのコントロール例 伝搬する際、AS_PATH により優先順位を設定しています。先ほどは、お客様ルーターがAWS に広告する経路に対して設定しましたが、今回はAWS から広告されてきた経路をWANサービスに伝搬する際にAS_PATH Prepend を設定しています。図5に示した表は、WAN サービスが持つBGPテーブルのイメージです。今回は特にローカルプリファレンスやMED は活用しませんでしたが、構成やご利用のWAN サービスによっては活用することもあります。 ※1 Public VIFについては、AWS が広告する経路にリージョン制御のためのCommunity タグがサポートされています。詳しくは ドキュメント をご参照ください。 シナリオ2 ロードバランス（ECMP）構成 Direct Connect は、Equal Cost Multi Path(ECMP) に対応しています。AWS がベストパス選択を行う際、最も優先度の高いパスが複数あった場合、それらはロードバランスされます。本シナリオは、すべてのDirect Connect 接続を等コストに設定し、トラフィックをロードバランスすることによって、突発的なトラフィック増に備えることを想定します。 Direct Connect 接続がすべて1Gbps だったとしましょう。その場合、シナリオ1では最大帯域幅は1Gbps になります。 4重の冗長構成が取られているため、障害に対して非常に堅牢な反面、スタンバイ側の回線は普段利用しないことになります。ECMP を利用すると、すべての回線を有効活用して最大4Gbps まで対応することができます。ただし、このような構成で普段から4Gbps のトラフィックを利用することは推奨しません。それは、以下のような理由によるものです。 ・ECMP によるロードバランスは各接続の最大帯域を考慮しない ・ECMP によるロードバランスはネットワーク機器に実装により、ある程度の偏りが生じることが想定される ・障害やメンテナンス時に最大帯域が減少し、重要なトラフィックが欠損する可能性がある 本構成を採用する場合、「突発的に1Gbps 以上のトラフィックが発生した場合」に対応できること、を要件とすることを推奨します。また、通信経路が行きと帰りで非対称になる可能性があるため、そのようなトラフィックをフィルタリングする機器が導入されていないかどうかも考慮する必要があります。 なお、有効帯域の増加を考える場合、Direct Connect はLink Aggregation Group (LAG) にも対応しています。 詳しくは ドキュメント をご参照ください。 さて、以下に示す図6は、ECMP の優先度設計の考え方を示しています。 図6 ECMPを行う際の優先度設計 全てを同じ優先度1としています。なお、例としてOS1 の二つの接続を優先度1、OSAKA2の二つの接続を優先度2として、最大帯域を 2Gbps としてロードバランスさせることもできます。要件により、さまざまな設計が可能です。 シナリオ2-1 AWSからお客様ネットワーク に向かうトラフィックのコントロール シナリオ1では、BGPのCommunity タグとAS_PATH 属性を組み合わせて優先度を決定しました。シナリオ2 では、等コストにすることを目的としますので、以下の通り、Commnunity タグのみ利用します。 図7 Community タグによる等コスト設定 この例では、Community タグによってAWS が暗黙に設定するローカルプリファレンス値を上書きし、すべて優先設定：中にすることによって等コストに設定しています。これにより、AWS からお客様ネットワークに向かうすべてのトラフィックは4 つの接続にロードバランスされます。シナリオ1で利用したAS_PATH Prepend を利用する必要はありません。 シナリオ2-2 お客様ネットワークからAWS に向かうトラフィックのコントロール 今回はWAN サービスを利用していることを想定しているため、ご利用のサービスがECMP に対応していれば、特に優先度をつけずにWAN サービスにAWS からの経路を伝搬させることでECMP を実現できます。ご利用の際は、必ずWAN サービスやルーターのサービス仕様をご確認ください。 まとめ 本記事では、大阪リージョンに属する初めてのDirect Connect ロケーションである Telehouse OSAKA2のご紹介と、これを活用した冗長構成とトラフィックコントロールの例をご紹介しました。今回ご紹介した内容は、例えば東京とアメリカであったり、異なるリージョンに属するロケーションが混在する際にも活用できます。また、例えばEquinix TY2とOS1など、同じリージョンに属するDirect Connect ロケーションのみ利用する際にも、今後の拡張に備えてBGP Community タグを利用することを推奨いたします。 本記事は、Network Specialist Solutions Architect の奥村が執筆しました。

本記事は 2025 年 4 月 7 日に AWS Machine Learning Blog で公開された Effectively use prompt caching on Amazon Bedrock を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 Amazon Bedrock において、プロンプトキャッシュの一般提供が開始されました。Anthropic の Claude 3.5 Haiku と Claude 3.7 Sonnet に加え、 Nova Micro、 Nova Lite、 Nova Pro モデルで利用可能です。複数の API 呼び出しにおいて頻繁に使用されるプロンプトをキャッシュすることで、応答時間を最大 85% 短縮し、コストを最大 90% 削減します。 プロンプトキャッシュを使用すると、特定の連続したプロンプト部分 ( プロンプトプレフィックスと呼ばれます ) をキャッシュ対象として指定できます。指定されたプロンプトプレフィックスを含むリクエストが送信されると、モデルは入力を処理し、そのプレフィックスに関連する内部状態をキャッシュします。その後、同じプロンプトプレフィックスを含むリクエストがあると、モデルはキャッシュから読み取り、入力トークンの処理に必要な計算ステップをスキップします。これにより、最初のトークンが生成されるまでの時間 (time to first token, TTFT) が短縮され、ハードウェアがより効率的に利用されます。そのため、ユーザーはより安い価格でサービスを利用できます。 この記事では、Amazon Bedrock のプロンプトキャッシュに関する総合的な説明と、レイテンシー改善とコスト削減を実現するための効果的な活用方法を解説します。 プロンプトキャッシュの仕組み 大規模言語モデル (large language model, LLM) の処理は、主に 2 つの段階で構成されています。入力トークン処理と出力トークン生成です。 Amazon Bedrock のプロンプトキャッシュは、この入力トークン処理の段階を最適化します。 まず、プロンプトの関連部分にキャッシュチェックポイントを指定します。チェックポイントより前のプロンプト全体がキャッシュされるプロンプトプレフィックスになります。キャッシュチェックポイントで指定されたものと同じプロンプトプレフィックスを含むリクエストを送信すると、LLM はそのプレフィックスがキャッシュに既に保存されているかどうかを確認します。一致するプレフィックスが見つかった場合、LLM はキャッシュから読み取り、最後にキャッシュされたプレフィックスから入力処理を再開できます。これにより、プロンプトプレフィックスを再計算するために必要だった時間とコストを節約できます。 なお、モデルによってプロンプトキャッシュの対応状況が異なりますので、注意ください。対応しているモデル、サポートされているモデル、キャッシュチェックポイントあたりの最小トークン数とリクエストあたりの最大キャッシュチェックポイント数の詳細については、 関連ドキュメント を確認してください。 キャッシュヒットは、プレフィックスが完全に一致した場合にのみ発生します。プロンプトキャッシュのメリットを最大限に活用するには、指示や例などの静的コンテンツをプロンプトの先頭に配置することをお勧めします。ユーザー固有の情報などの動的コンテンツは、プロンプトの末尾に配置してください。この原則は画像やツールにも適用され、キャッシングを有効にするためにはリクエスト間で同一である必要があります。 次の図は、キャッシュヒットの仕組みを説明しています。 A、B、C、D はプロンプトの異なる部分を表しています。 A、B、C がプロンプトプレフィックスとして指定されています。後続のリクエストに同じ A、B、C のプロンプトプレフィックスが含まれている場合、キャッシュヒットが発生します。 プロンプトキャッシュを使うべき場面 Amazon Bedrock のプロンプトキャッシュは、複数の API 呼び出しで頻繁に再利用される長いコンテキストプロンプトを扱うワークロードに適しています。この機能を使うと、レスポンスのレイテンシーを最大 85% 短縮し、推論コストを最大 90% 削減できるため、繰り返し使用される長い入力コンテキストを持つアプリケーションに特に適しています。プロンプトキャッシュがユースケースに有益かどうかを判断するには、キャッシュするトークン数、再利用の頻度、リクエスト間の時間を見積もる必要があります。 プロンプトキャッシュに適したユースケースを以下に示します： ドキュメントを使ったチャット – 最初のリクエストでドキュメントを入力コンテキストとしてキャッシュすることで、各ユーザークエリの処理が効率化されます。これにより、ベクトルデータベースのような複雑なソリューションを使わなくても、よりシンプルなアーキテクチャが実現できます。 コーディングアシスタント – プロンプトで長いコードファイルを再利用することで、ほぼリアルタイムのインラインコード提案が可能になります。これにより、コードファイルを何度も再処理する時間を大幅に削減できます。 エージェントワークフロー – より長いシステムプロンプトを使用してエージェントの動作を洗練させても、エンドユーザーの体験を損なうことがありません。システムプロンプトや複雑なツール定義をキャッシュすることで、エージェントフローの各ステップの処理時間を短縮できます。 Few-shot 学習 – カスタマーサービスや技術的なトラブルシューティングなど、多数の高品質な例と複雑な指示を含める場合、プロンプトキャッシュが役立ちます。 プロンプトキャッシュの使用方法 プロンプトキャッシュを使用する際は、プロンプトの構成要素を「繰り返し使用される静的な部分」と「動的な部分」の 2 つのグループに分類することが重要です。プロンプトテンプレートは、次の図に示す構造に従う必要があります。 1 つのリクエスト内に複数のキャッシュチェックポイントを作成できます。ただし、モデルごとに制限があります。次の図に示すように、静的な部分、キャッシュチェックポイント、動的な部分という同じ構造に従う必要があります。 ユースケース例 プロンプトにドキュメントを含める「ドキュメントを使ったチャット」のユースケースは、プロンプトキャッシュに非常に適しています。この例では、プロンプトの静的な部分はレスポンスフォーマットに関する指示とドキュメント本文で構成されています。動的な部分はユーザーのクエリであり、これはリクエストごとに変わります。 このシナリオでは、プロンプトの静的な部分をプロンプトプレフィックスとして指定し、プロンプトキャッシュを有効にします。以下のコードスニペットは、 Invoke Model API を使用してこのアプローチを実装する方法を示しています。次の図に示すように、リクエスト内に 2 つのキャッシュチェックポイントを作成しています。1 つは指示用、もう 1 つはドキュメント本文用です。 以下のプロンプトを使用します： def chat_with_document(document, user_query): instructions = ( "I will provide you with a document, followed by a question about its content. " "Your task is to analyze the document, extract relevant information, and provide " "a comprehensive answer to the question. Please follow these detailed instructions:" "\n\n1. Identifying Relevant Quotes:" "\n - Carefully read through the entire document." "\n - Identify sections of the text that are directly relevant to answering the question." "\n - Select quotes that provide key information, context, or support for the answer." "\n - Quotes should be concise and to the point, typically no more than 2-3 sentences each." "\n - Choose a diverse range of quotes if multiple aspects of the question need to be addressed." "\n - Aim to select between 2 to 5 quotes, depending on the complexity of the question." "\n\n2. Presenting the Quotes:" "\n - List the selected quotes under the heading 'Relevant quotes:'" "\n - Number each quote sequentially, starting from [1]." "\n - Present each quote exactly as it appears in the original text, enclosed in quotation marks." "\n - If no relevant quotes can be found, write 'No relevant quotes' instead." "\n - Example format:" "\n Relevant quotes:" "\n [1] \"This is the first relevant quote from the document.\"" "\n [2] \"This is the second relevant quote from the document.\"" "\n\n3. Formulating the Answer:" "\n - Begin your answer with the heading 'Answer:' on a new line after the quotes." "\n - Provide a clear, concise, and accurate answer to the question based on the information in the document." "\n - Ensure your answer is comprehensive and addresses all aspects of the question." "\n - Use information from the quotes to support your answer, but do not repeat them verbatim." "\n - Maintain a logical flow and structure in your response." "\n - Use clear and simple language, avoiding jargon unless it's necessary and explained." "\n\n4. Referencing Quotes in the Answer:" "\n - Do not explicitly mention or introduce quotes in your answer (e.g., avoid phrases like 'According to quote [1]')." "\n - Instead, add the bracketed number of the relevant quote at the end of each sentence or point that uses information from that quote." "\n - If a sentence or point is supported by multiple quotes, include all relevant quote numbers." "\n - Example: 'The company's revenue grew by 15% last year. [1] This growth was primarily driven by increased sales in the Asian market. [2][3]'" "\n\n5. Handling Uncertainty or Lack of Information:" "\n - If the document does not contain enough information to fully answer the question, clearly state this in your answer." "\n - Provide any partial information that is available, and explain what additional information would be needed to give a complete answer." "\n - If there are multiple possible interpretations of the question or the document's content, explain this and provide answers for each interpretation if possible." "\n\n6. Maintaining Objectivity:" "\n - Stick to the facts presented in the document. Do not include personal opinions or external information not found in the text." "\n - If the document presents biased or controversial information, note this objectively in your answer without endorsing or refuting the claims." "\n\n7. Formatting and Style:" "\n - Use clear paragraph breaks to separate different points or aspects of your answer." "\n - Employ bullet points or numbered lists if it helps to organize information more clearly." "\n - Ensure proper grammar, punctuation, and spelling throughout your response." "\n - Maintain a professional and neutral tone throughout your answer." "\n\n8. Length and Depth:" "\n - Provide an answer that is sufficiently detailed to address the question comprehensively." "\n - However, avoid unnecessary verbosity. Aim for clarity and conciseness." "\n - The length of your answer should be proportional to the complexity of the question and the amount of relevant information in the document." "\n\n9. Dealing with Complex or Multi-part Questions:" "\n - For questions with multiple parts, address each part separately and clearly." "\n - Use subheadings or numbered points to break down your answer if necessary." "\n - Ensure that you've addressed all aspects of the question in your response." "\n\n10. Concluding the Answer:" "\n - If appropriate, provide a brief conclusion that summarizes the key points of your answer." "\n - If the question asks for recommendations or future implications, include these based strictly on the information provided in the document." "\n\nRemember, your goal is to provide a clear, accurate, and well-supported answer based solely on the content of the given document. " "Adhere to these instructions carefully to ensure a high-quality response that effectively addresses the user's query." ) document_content = f"Here is the document: <document> {document} </document>" messages_API_body = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [ { "role": "user", "content": [ { "type": "text", "text": instructions, "cache_control": { "type": "ephemeral" } }, { "type": "text", "text": document_content, "cache_control": { "type": "ephemeral" } }, { "type": "text", "text": user_query }, ] } ] } response = bedrock_runtime.invoke_model( body=json.dumps(messages_API_body), modelId="us.anthropic.claude-3-7-sonnet-20250219-v1:0", accept="application/json", contentType="application/json" ) response_body = json.loads(response.get("body").read()) print(json.dumps(response_body, indent=2)) response = requests.get("https://aws.amazon.com/blogs/aws/reduce-costs-and-latency-with-amazon-bedrock-intelligent-prompt-routing-and-prompt-caching-preview/") blog = response.text chat_with_document(blog, "What is the blog writing about?") 上記のコードスニペットに対するレスポンスには、キャッシュの読み取りと書き込みに関するメトリクスを示す usage セクションがあります。以下は、最初のモデル呼び出しからのレスポンスの例です： { "id": "msg_bdrk_01BwzJX6DBVVjUDeRqo3Z6GL", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219”, "content": [ { "type": "text", "text": "Relevant quotes:\n[1] \"Today, Amazon Bedrock has introduced in preview two capabilities that help reduce costs and latency for generative AI applications\"\n\n[2] \"Amazon Bedrock Intelligent Prompt Routing \u2013 When invoking a model, you can now use a combination of foundation models (FMs) from the same model family to help optimize for quality and cost... Intelligent Prompt Routing can reduce costs by up to 30 percent without compromising on accuracy.\"\n\n[3] \"Amazon Bedrock now supports prompt caching \u2013 You can now cache frequently used context in prompts across multiple model invocations... Prompt caching in Amazon Bedrock can reduce costs by up to 90% and latency by up to 85% for supported models.\"\n\nAnswer:\nThe article announces two new preview features for Amazon Bedrock that aim to improve cost efficiency and reduce latency in generative AI applications [1]:\n\n1. Intelligent Prompt Routing: This feature automatically routes requests between different models within the same model family based on the complexity of the prompt, choosing more cost-effective models for simpler queries while maintaining quality. This can reduce costs by up to 30% [2].\n\n2. Prompt Caching: This capability allows frequent reuse of cached context across multiple model invocations, which is particularly useful for applications that repeatedly use the same context (like document Q&A systems). This feature can reduce costs by up to 90% and improve latency by up to 85% [3].\n\nThese features are designed to help developers build more efficient and cost-effective generative AI applications while maintaining performance and quality standards." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 9, "cache_creation_input_tokens": 37209, "cache_read_input_tokens": 0, "output_tokens": 357 } } cache_creation_input_tokens の値が 37,209 であることから、キャッシュチェックポイントが正常に作成され、 37,209 トークンがキャッシュされたことがわかります。この状態を次の図に示します。 次回のリクエストでは、別の質問をすることができます： chat_with_document(blog, "what are the use cases?") プロンプトの動的な部分は変更されましたが、静的な部分とプロンプトプレフィックスは同じままです。このため、続くモデル呼び出しではキャッシュが活用されることが期待できます。以下のコードをご覧ください： { "id": "msg_bdrk_01HKoDMs4Bmm9mhzCdKoQ8bQ", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219", "content": [ { "type": "text", "text": "Relevant quotes:\n[1] \"This is particularly useful for applications such as customer service assistants, where uncomplicated queries can be handled by smaller, faster, and more cost-effective models, and complex queries are routed to more capable models.\"\n\n[2] \"This is especially valuable for applications that repeatedly use the same context, such as document Q&A systems where users ask multiple questions about the same document or coding assistants that need to maintain context about code files.\"\n\n[3] \"During the preview, you can use the default prompt routers for Anthropic's Claude and Meta Llama model families.\"\n\nAnswer:\nThe document describes two main features with different use cases:\n\n1. Intelligent Prompt Routing:\n- Customer service applications where query complexity varies\n- Applications needing to balance between cost and performance\n- Systems that can benefit from using different models from the same family (Claude or Llama) based on query complexity [1][3]\n\n2. Prompt Caching:\n- Document Q&A systems where users ask multiple questions about the same document\n- Coding assistants that need to maintain context about code files\n- Applications that frequently reuse the same context in prompts [2]\n\nBoth features are designed to optimize costs and reduce latency while maintaining response quality. Prompt routing can reduce costs by up to 30% without compromising accuracy, while prompt caching can reduce costs by up to 90% and latency by up to 85% for supported models." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 10, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 37209, "output_tokens": 324 } } 37,209 トークンはキャッシュから読み込まれたドキュメントと指示内容に対応し、ユーザークエリ部分は 10 トークンとなっています。この状態を次の図に示します。 別のブログ記事にドキュメントを変更してみましょう。ただし、指示内容は同じままにします。今回のリクエストの構造は指示部分がドキュメント本文よりも前に配置されているため、指示部分のプロンプトプレフィックスについてはキャッシュヒットが期待できます。以下のコードをご覧ください： response = requests.get(https://aws.amazon.com/blogs/machine-learning/enhance-conversational-ai-with-advanced-routing-techniques-with-amazon-bedrock/) blog = response.text chat_with_document(blog, "What is the blog writing about?") { "id": "msg_bdrk_011S8zqMXzoGHABHnXX9qSjq", "type": "message", "role": "assistant", "model": "claude-3-7-sonnet-20250219", "content": [ { "type": "text", "text": "Let me analyze this document and provide a comprehensive answer about its main topic and purpose.\n\nRelevant quotes:\n[1] \"When you're designing a security strategy for your organization, firewalls provide the first line of defense against threats. Amazon Web Services (AWS) offers AWS Network Firewall, a stateful, managed network firewall that includes intrusion detection and prevention (IDP) for your Amazon Virtual Private Cloud (VPC).\"\n\n[2] \"This blog post walks you through logging configuration best practices, discusses three common architectural patterns for Network Firewall logging, and provides guidelines for optimizing the cost of your logging solution.\"\n\n[3] \"Determining the optimal logging approach for your organization should be approached on a case-by-case basis. It involves striking a balance between your security and compliance requirements and the costs associated with implementing solutions to meet those requirements.\"\n\nAnswer:\nThis document is a technical blog post that focuses on cost considerations and logging options for AWS Network Firewall. The article aims to help organizations make informed decisions about implementing and managing their firewall logging solutions on AWS. Specifically, it:\n\n1. Explains different logging configuration practices for AWS Network Firewall [1]\n2. Discusses three main architectural patterns for handling firewall logs:\n - Amazon S3-based solution\n - Amazon CloudWatch-based solution\n - Amazon Kinesis Data Firehose with OpenSearch solution\n3. Provides detailed cost analysis and comparisons of different logging approaches [3]\n4. Offers guidance on balancing security requirements with cost considerations\n\nThe primary purpose is to help AWS users understand and optimize their firewall logging strategies while managing associated costs effectively. The article serves as a practical guide for organizations looking to implement or improve their network security logging while maintaining cost efficiency [2]." } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 9, "cache_creation_input_tokens": 37888, "cache_read_input_tokens": 1038, "output_tokens": 385 } } レスポンスを確認すると、指示部分は 1,038 トークンをキャッシュから読み取っており、新しいドキュメント本文については 37,888 トークンをキャッシュに書き込んでいるのがわかります。この状態を、次の図に示します。 コスト削減効果 キャッシュヒットが発生すると、Amazon Bedrock はコンピューティングの節約分をキャッシュされたコンテキストのトークンごとの割引としてお客様に還元します。潜在的なコスト削減効果を計算するには、まず Amazon Bedrock のレスポンスにあるキャッシュ書き込み / 読み取りメトリクスを使用して、プロンプトキャッシュの使用パターンを把握する必要があります。その後、1,000 入力トークンあたりの価格 (キャッシュ書き込み) と 1,000 入力トークンあたりの価格 (キャッシュ読み取り) を使って潜在的なコスト削減効果を計算できます。詳しい価格情報については、 Amazon Bedrock の料金 をご覧ください。 レイテンシーベンチマーク プロンプトキャッシュは、繰り返し使用されるプロンプトの TTFT パフォーマンスを向上させるために最適化されています。この機能は、チャットプレイグラウンドのような複数回のやり取りを伴う会話型アプリケーションに非常に適しています。また、大きなドキュメントを繰り返し参照する必要があるユースケースにも役立ちます。 ただし、2,000 トークンにも及ぶ長大なシステムプロンプトの後に、頻繁に内容が変わる長いテキストが続くようなワークロードでは、プロンプトキャッシュの効果があまり発揮されない場合があります。このような状況では、キャッシュによるメリットが限定的になってしまいます。 プロンプトキャッシュの使用方法とベンチマーク方法については、 GitHub リポジトリ にノートブックを公開しています。ベンチマーク結果は、入力トークン数、キャッシュされたトークン数、出力トークン数など、ユースケースによって異なります。 Amazon Bedrock クロスリージョン推論 プロンプトキャッシュは、 クロスリージョン推論 (CRIS) と組み合わせて使用できます。クロスリージョン推論は、推論リクエストを処理するために地理的に最適な AWS リージョンを自動的に選択し、リソースとモデルの可用性を最大化します。需要が高い時期には、これらの最適化によりキャッシュ書き込みが増加する可能性があります。 メトリクスとオブザーバビリティ プロンプトキャッシュのオブザーバビリティは、Amazon Bedrock を使用するアプリケーションのコスト削減とレイテンシー改善に不可欠です。主要なパフォーマンスメトリクスをモニタリングすることで、開発者は長いプロンプトの TTFT を最大 85% 削減し、コストを最大 90% カットするといった大幅な効率改善を達成できます。これらのメトリクスは、開発者がキャッシュパフォーマンスを正確に評価し、キャッシュ管理に関する戦略的な決定を行うために重要です。 Amazon Bedrock でのモニタリング Amazon Bedrock は API レスポンスの usage セクションでキャッシュパフォーマンスデータを提供しています。これにより開発者は、キャッシュヒット率、トークン消費量（読み取りと書き込みの両方）、レイテンシー改善などの重要なメトリクスを追跡できます。これらの情報を活用することで、チームはキャッシング戦略を効果的に管理し、アプリケーションの応答性を高め、運用コストを削減できます。 Amazon CloudWatch でのモニタリング Amazon CloudWatch は AWS サービスの健全性とパフォーマンスをモニタリングするための強力なプラットフォームです。 Amazon Bedrock モデル専用の新しい自動ダッシュボードも含まれています。これらのダッシュボードは主要なメトリクスに素早くアクセスし、モデルのパフォーマンスをより深く理解できるようになっています。 カスタムオブザーバビリティダッシュボードを作成するには、以下の手順を実行します： CloudWatch コンソールで新しいダッシュボードを作成します。詳しい手順については、 Improve visibility into Amazon Bedrock usage and performance with Amazon CloudWatch を参照ください。 データソースタイプ欄の CloudWatch を選択し、初期のウィジェットのタイプとして 円 を選択します ( これは後で調整可能です ) 。 メトリクスの時間範囲 ( 1 時間、 3 時間、 1 日など ) をモニタリングニーズに合わせて更新します AWS 名前空間で Bedrock を選択します 検索ボックスに「 cache 」と入力してキャッシュ関連のメトリクスをフィルタリングします モデルについては、 anthropic.claude-3-7-sonnet-20250219-v1:0 を見つけ、 CacheWriteInputTokenCount と CacheReadInputTokenCount の両方を選択します 「ウィジェットの作成」を選択し、その後「保存」を選んでダッシュボードを保存します 以下は、このウィジェットを作成するためのサンプル JSON 設定です： { "view": "pie", "metrics": [ [ "AWS/Bedrock", "CacheReadInputTokenCount" ], [ ".", "CacheWriteInputTokenCount" ] ], "region": "us-west-2", "setPeriodToTimeRange": true } キャッシュヒット率の把握 キャッシュヒット率を分析するには、 CacheReadInputTokens と CacheWriteInputTokens の両方のメトリクスを確認する必要があります。一定期間にわたってこれらのメトリクスを集計することで、キャッシング戦略の効率についての洞察を得ることができます。 Amazon Bedrock 料金ページ に掲載されているモデル固有の 1,000 入力トークンあたりの価格（キャッシュ書き込み）と 1,000 入力トークンあたりの価格（キャッシュ読み取り）を使用すれば、特定のユースケースの潜在的なコスト削減を見積もることができます。 まとめ この記事では、 Amazon Bedrock のプロンプトキャッシュについて、その仕組み、使用べき場面、効果的な活用方法を紹介しました。あなたのユースケースがこの機能の恩恵を受けるかどうかを慎重に評価することが重要です。プロンプトの構造を工夫すること、静的コンテンツと動的コンテンツの違いを理解すること、そして特定のニーズに合った適切なキャッシング戦略を選択することが重要です。CloudWatch メトリクスを使用してキャッシュパフォーマンスをモニタリングし、この記事で説明した実装パターンに従うことで、高いパフォーマンスを維持しながら、より効率的でコスト効果の高い AI アプリケーションを構築できます。 Amazon Bedrock のプロンプトキャッシュの使い方の詳細については、 Prompt caching for faster model inference を参照ください。 著者について Sharon Li は、マサチューセッツ州ボストンを拠点とする Amazon Web Services (AWS) の AI/ML スペシャリストソリューションアーキテクトです。最先端技術の活用に情熱を持ち、 AWS クラウドプラットフォームで革新的な生成 AI ソリューションの開発と導入に取り組んでいます。 Shreyas Subramanian は、プリンシパルデータサイエンティストとして、生成 AI とディープラーニングを活用して AWS サービスを使用したビジネス課題の解決を支援しています。大規模最適化と機械学習のバックグラウンドを持ち、最適化タスクの加速に機械学習と強化学習を使用しています。 Satveer Khurpa は、 Amazon Web Services のシニア WW スペシャリストソリューションアーキテクトであり、 Amazon Bedrock セキュリティを専門としています。クラウドベースのアーキテクチャに関する専門知識を活かし、さまざまな業界のクライアント向けに革新的な生成 AI ソリューションを開発しています。生成 AI 技術とセキュリティ原則への深い理解により、堅牢なセキュリティ体制を維持しながら、新たなビジネス機会を開拓し、実質的な価値を推進するスケーラブルで安全かつ責任あるアプリケーションの設計を行っています。 Kosta Belz は、 AWS Generative AI Innovation Center のシニア応用科学者として、お客様が主要なビジネス課題を解決するための生成 AI ソリューションの設計と構築を支援しています。 Sean Eichenberger は、 AWS のシニアプロダクトマネージャーです。

2025/3/31 – 4/4に世界最大規模の製造業展示会ハノーバーメッセが開催されました。AWS は「Built for Industrial AI」をテーマに、ものづくりの全プロセスにおける AI の活用を訴求しました。AWS ブースには、AWS のフォーカスエリアである「Smart Manufacturing」「Smart Products」「Engineering &amp; Design」「Supply Chain」「Sustainability」の５つのエリアに 13 の AWS キオスクと、39 のパートナーキオスクの計 52 のキオスクが設置されました。日本からも多くのお客様に来場頂き、私たち AWS Japan の製造業担当スペシャリスト、営業、ソリューションアーキテクトがブースツアーという形で AWS のブースをご紹介しました。 このブログでは AWS ブースの概要と展示ソリューションについてご紹介します。 AWSブース全体像 写真1：AWS ブース全景 こちらが AWS ブースの全景です。AWS 製造業向けにフォーカスエリアである「Smart Manufacturing」「Smart Products」「Engineering &amp; Design」「Supply Chain」「Sustainability」と生成 AI を活用したユースケースの実装例が入口近くに展示されていました。 昨年のハノーバーメッセでの AWS ブース からの変化点として大きく３つ挙げておきます。 ビジネスに貢献する生成 AI の実装 昨年までの生成 AI のコンセプト紹介やシンプルなチャットの展示からフェーズが進み、業務のユースケースにおける具体的な課題および「人手不足」「匠の技の伝承」などの業界課題を解決する手段として生成 AI の活用が進み、実装が進んでいます。AI エージェント形式での実装も進み、高度なタスクをこなせるようになってきています。 すぐに使える Vertical SaaS の増加 不確実で変化の早い市況に対応するためには新しい取り組みの PoC を早期に完了して業務活用に進める必要があります。産業機器接続、OT Security、データ基盤など製造業に特化した パートナー企業が提供する SaaS の増加によりすぐに価値検証や本番導入を進められる状況が整ってきています。 DataOps の加速 2 の SaaS の増加とも関連しますが、とりわけ Smart Factory は机上のコンセプトから実用フェーズに移り、単に機器からデータを吸い上げるだけではなく持続的な運用に必要なツールが増加しました。具体的にはデータの加工、統合、データモデリング、エッジ側での異常検知など高度な機能を持つソリューション（ HighByte 、 LITMUS 等）が増加しています。企業全体のデータ活用（Digital Thread）の実現も、生成 AI の登場により技術的な障壁は下がり始めています。 それでは、ここからは各ブースの注目展示についてご紹介していきます。 Smart Manufacturing 写真2：昨年に引き続き展示された e-Bike Smart Factory デモ 昨年のハノーバーメッセでは中央に鎮座していた e-Bike Smart Factory デモが今年も展示されていました。様々なベンダーの製品を組合せたリアルな工場ラインだけでなくエンジニアリングチェーンからサプライチェーンまで一気通貫で AWS 上で動かすというショーケース的なデモになっています。一方で今年は少し端の方に寄せられており、その代わりに中央に配置されていたのは、地元ドイツの企業である SYNAOS によるマルチベンダーの AMR/AGV コントローラーによるデモです。 写真3：SYNAOS によるマルチベンダーのAMR制御デモ KUKA と SHERPA のメーカーの異なる AMR を協調制御していました。既に VW 社において 40 メーカー 160 台を超える AGV / AMR / フォークリフトを制御していると紹介されていました。現在 45 メーカーに対応しており、日本のメーカーではオムロンに対応しているとのことで、テスト環境では最大 600 台まで制御可能とのことです。 写真4：AWS Industrial Data Fabric ブースと説明員の Scott 氏 DataOps に関連して数年前から AWS が提唱している Industrial Data Fabric ( 産業データファブリック ) に関しても様々なパートナーの参画によってパートナーソリューションを組み合わせたデモが行われていました。また、ハノーバーメッセ開催期間中には日立製作所様が 国内初の IDF パートナーとして登録 されました。産業データファブリックについては今年の 6 月に開催する AWS Summit Japan 2025 でも展示が行われますのでご期待下さい。 写真5：Process Manufacturing on AWS ブースと説明員の Mickael 氏と Miguel 氏 もう一つ、プロセス製造業における技術伝承や人材不足といった課題に対して、日々の口頭によるやり取りをノウハウとして蓄積し AI アシスタントとして業務に活用するデモを行いました。実はこちらは日本のソリューションアーキテクトが昨年の AWS Summit で作成して大好評だったデモ をベースに多言語化させたものになります。 Smart Products 写真6：Smart Products &amp; Service on AWS ブースと説明員の山本氏と新澤氏 Smart Products のブースでは製品の開発と運用の観点で２つの展示を行い、ソフトウェアの遠隔更新や、Amazon Q Developer, GitLab Duo といった生成 AI の活用により組み込みソフトウェア開発を加速する日本発のデモと、IoT の機能を組み込んだスマートプロダクトから得られた情報からアフターサービスをシームレスに行うデモを展示しました。このデモでは生成 AI エージェントを活用し、来場者の関心も高く、生成 AI の使い方が具体的でイメージが出来たと好評でした。 写真7：デバイスウォール 工場設備だけでなくスマートプロダクトを AWS に安全かつ簡単に繋ぐ方法として AWS IoT Greengrass 、 AWS IoT ExpressLink 、 FreeRTOS があります。これらに対応した認定デバイスがデバイスウォールとして展示されていました。開催場所がヨーロッパということもあり、日本ではあまり見かけることの少ないメーカーも多くありました。またデバイスウォールの左上にあるデバイスは既存の通信機能がない製品に組み込んで使って頂くようなデバイスとなっており、こんなものまで出しているんだと驚きの声が聞かれました。パートナーデバイスに興味のある方は是非 こちら からご覧ください。 Engineering &amp; Design 写真8：Engineering &amp; Design on AWS ブースと説明員の Patrice 氏 Engineering &amp; Design のブースで注目を浴びていたのは、生成 AI を活用し 2D の写真から 3D のモデルを生成してシミュレーションまで行うというデモです。 こちら はワークショップの形で公開されています。ご興味がある方は一度トライしてみては如何でしょうか？またシミュレーションの分野では今までインプット条件に対して大量のコンピューターリソースと時間を掛けてアウトプットとなるシミュレーション結果を生成していたものを、サロゲートモデルと呼ばれる機械学習を用いてシミュレーション結果を予測することで、従来のシミュレーションに比べて時間とコンピュータリソースの削減を行うデモも行っていました。大量のシミュレーション条件を微調整して頻繁に行うことが多いユースケースにおいては有効な手段となる可能性があります。日本のお客様でも取組みを始めていらしゃるようですが、まだまだ知られていないこれからの技術だと思います。 Supply Chain 写真9：AWS Supply Chain のブースと説明員の Pawel 氏 Supply Chain のブースは昨年に引き続き AWS Supply Chain を中心に e-Bike Smart Factory と連携した展示を行っていました。AWS Supply Chain は、AWS では珍しいビジネスアプリケーションとして提供されており、既存のシステムの外付けで在庫の可視化や分析及び最適化を行うことができるサービスとなっています。昨年との大きな違いとしては、 昨年末に reInvent で発表された BMW との協業 による Catena-X への対応です。2025 年中の正式リリースに向けて、今回は画面イメージを説明していました。 Build for Industrial AI 写真10：毎日盛況だった Build for Industrial AI のコーナー AWS ブースの入り口にあった 4 つのユースケースを想定した生成 AI の実装例が展示されていたコーナーには常に人だかりが出来ていました。 昨年末にリリース された AWS IoT SiteWise Assistant による設備から取得されたデータの内容を生成 AI が人が理解しやすく自然言語でサマリーしてくれるデモ。生成 AI アシスタントである Amazon Q Business を使った製造現場のドキュメントを使ったデモ。クラウド上でファインチューニングされた生成 AI モデルをエッジデバイスで動かし製造現場での利用を想定したアシスタントのデモ。などの展示を行いましたが、このブログでは最もお客様からの反響が大きかった生成 AI を使った外観検査のデモについてご紹介します。 写真11：Amazon Nova を使った外観検査のデモ これまでの機械学習モデルによる外観検査では、良品 / 不良品の画像を事前学習し、その物体専用の機械学習モデルを作成する必要がありました。最新の生成 AI のモデルでは、マルチモーダルと呼ばれるテキストだけでなくインプットされた画像を理解出来るようになってきているのはご存じの方も多いと思います。マルチモーダルに対応した Amazon Nova を使って事前学習無しで、様々な物体の外観検査をプロンプト（生成 AI への指示文章）だけで行うというデモです。検出精度やスピードに驚かれているお客様が多かったです。実際の現場でさっそく試してみたいという声も聞かれました。 まとめ このブログでは 2025 年のハノーバーメッセにおける AWS ブースの概要と注目の展示をポイントを絞ってお届けしました。熱気に満ちた 5 日間のハノーバーメッセの雰囲気が少しでも伝わったでしょうか？今回のブログは速報という形でお届けしましたので、パートナーブース含めて、まだまだお伝えしきれないことが沢山あります。そちらについては、4 月 24 日にハノーバーメッセに関する無料ウェビナーを開催致しますので、ぜひそちらも合わせてご覧ください（お申込みは こちら ）。我々日本のスタッフは、日本の製造業の皆さんの発展をサポートさせて頂きます。気になった内容があれば、担当営業もしくは、 こちら までお問い合わせ下さい。 来年のハノーバーメッセ（2026/4/20 – 4/24）では、日本の製造業の事例などが展示できることを期待しています。また今年の AWS Summit Japan（2025/6/25 – 6/26） でも製造業の皆さんに向けた展示や事例セッションなどが多数企画されています。こちらも是非早めの エントリー をお願いします。皆様にお会いできるのを楽しみにしています。 このブログは製造業担当のソリューションアーキテクト水野貴博が担当しました。 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。 <!-- '"` -->

AWS の生成 AI ワークロードのコスト最適化に関するシリーズの第 2 回目のブログへようこそ。 最初のブログ では、生成 AI を適用するためのさまざまな実装アプローチとクラウド財務管理の原則に関する概要を説明しました。今回は、Amazon Elastic Compute Cloud ( Amazon EC2 ) と Amazon SageMaker AI を使用し、カスタム AI モデルの構築とデプロイに関するコスト最適化戦略について詳しく説明します。大規模な言語モデルをトレーニングする場合、既存のモデルをファインチューニングする場合や推論エンドポイントをデプロイする場合いずれにも関連する、Amazon EC2 のインスタンスタイプの選定、キャパシティ管理やコミットメントプランニングなどの主要なコスト要因を説明します。また、Amazon SageMaker AI のモデル最適化、トレーニング効率やデプロイ戦略についても説明します。これらのプラクティスは、独自の AI インフラストラクチャーの管理に伴う柔軟性と制御を維持しながら、パフォーマンス要件とコスト効率のバランスを取るのに役立ちます。 Amazon EC2 と SageMaker AI は、生成 AI の基盤となる AWS サービスのうちの 2 つです。Amazon EC2 はトレーニングと推論に必要なスケーラブルなコンピューティングを提供し、SageMaker AI はモデル開発、デプロイや最適化のための組み込みツールを提供します。生成 AI ワークロードには高性能アクセラレーター (GPU、 Trainium や Inferentia ) と膨大な処理が必要であり、効率的なリソース管理がないとコストが高くなる可能性があるため、コスト最適化は非常に重要です。以下のコスト最適化戦略を活用することで、パフォーマンスとスケーラビリティを維持しながらコストを削減できます。 画像 1「Amazon EC2 と SageMaker AI のコスト最適化戦略:コスト削減 vs 労力」このグラフは説明のみを目的としています。実際に必要な労力と達成されるコスト削減は、実装規模、インフラストラクチャー、およびチームの専門知識に基づいて変わる場合があります。 Amazon EC2 1. 最適なインスタンスタイプの選択 Amazon EC2 インスタンスは自分でデプロイを管理する主要コンポーネントであり、適切なインスタンスタイプを選択することが重要です。 AWS Graviton 搭載のような CPU ベースのインスタンスタイプでは、 AWS Compute Optimizer を使用してインスタンスを簡単に分析し、適切なサイズを設定できます。生成 AI ソリューションには通常、NVIDIA GPU または Tranium や Inferentia などの AWS AI チップを搭載した高速インスタンスが必要です。AWS Trainium および Inferentia ベースのインスタンスは、トレーニングと推論のコストパフォーマンスが最大 30 – 50% 向上し、ワークロードにおいて費用対効果の高いオプションとなります。GPU ベースのインスタンスを適切なサイズにするには、 CloudWatch エージェントを使用した NVIDIA GPU の利用率の有効化 を参照してください。これにより、AWS Compute Optimizer は NVIDIA GPU の使用率を収集し、適切なサイズの推奨事項を提示できます。 データセット、ワークロードやモデルに対するインスタンスのパフォーマンスをより包括的に分析するには、コンテキストテストを使用する必要があります。 FM Bench などのツールは、さまざまなインスタンスタイプとサービングスタックのパフォーマンスを分析することで、このテストを合理化するのに役立ちます。推論レイテンシー、1 分あたりのトランザクション数、エラー率やトランザクションあたりのコストを示すマークダウンレポートを通じて、最も費用対効果の高い構成を特定するのに役立ちます。レポートには、説明文、表や図が含まれており、インスタンスを適切なサイズに設定し、必要な分だけを支払っていることを確認するのに必要な情報が記載されています。 2. スマートキャパシティ管理 使用するインスタンスタイプを理解したら、次のステップはキャパシティ管理戦略を理解することです。考えるべきよくある質問は次のとおりです。 インスタンスはいくつ必要ですか? どれくらいの頻度で実行する必要がありますか？ どれくらいの期間必要ですか？ オンデマンドキャパシティ予約 (ODCR) ODCR では、特定のアベイラビリティーゾーン (AZ) にある Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。機械学習 (ML) モデルのトレーニングとファインチューニングのために ODCR を使用することで、予約した高速インスタンス (GPU、Trainium や Inferentia) に中断されることなくアクセスできます。キャパシティ要件が厳しい場合や、ソリューションでキャパシティの確保が必要な場合は、ODCR の使用を検討してください。 ODCR は長期コミットメントを必要とせず、いつでも変更またはキャンセルできます。キャパシティー予約は、予約されているキャパシティーでインスタンスを実行するかどうかにかかわらず、同等のオンデマンド料金が請求されます。アカウントに ODCR がプロビジョニングされるとすぐに請求が開始され、キャパシティ予約がアカウントにプロビジョニングされている間も請求は継続されます。 ODCR を効率的に使用するには、使用率を監視することが重要です。これを実現する方法の 1 つは、Amazon CloudWatch を利用することです。CloudWatch では、「AvailableInstanceCount」などのメトリクスを監視するアラームを設定できます。このメトリクスは、ODCR 内の未使用のインスタンスの数を判断するのに役立ちます。ODCR を監視するもう 1 つの方法は、 AWS Cost Explorer または Cost and Usage Reports (CUR) を利用することです。これらのツールを使用すると、「UnusedBox」または「UnusedDed」を含む使用タイプをフィルタリングできます。これにより、キャパシティ予約したが使用されていないインスタンスの数が表示されます。さらに、アカウントの ODCR のキャパシティ使用率が 20% を下回ると、 AWS Health Dashboard から E メールが送信されます。 インスタンススケジューリング ワークロードを年中無休で実行する必要がない場合は、AWS Instance Scheduler の使用を検討する必要があります。 AWS Instance Scheduler は、Amazon Elastic Compute Cloud (EC2) と Amazon Relational Database Service (RDS) インスタンスの起動と停止を自動化するように設計されたソリューションです。この自動化は、必要なときにのみリソースを実行できるようにすることで、オペレーションコストの削減に役立ちます。Instance Scheduler は複数の AWS アカウントで動作するように設定できるため、大規模な組織での有用性が高まります。スケジューラーは AWS CloudFormation テンプレートを用いてインストールされ、スケジュール、サービス (Amazon EC2 または Amazon RDS) やタイムゾーン設定などのさまざまなパラメータをカスタマイズできます。この柔軟性により、スケジューラーを特定のニーズに合わせて調整できるため、効率的なリソース管理とコストの最適化が可能になります。 キャパシティ確保の目的でインスタンスをシャットダウンまたはリリースできない場合は、ODCR と共に Instance Scheduler を使用することを検討してください。そうすれば、予備のキャパシティを他のアカウント、チーム、またはワークロードに一時的にシフトできます。この方法ではコスト削減にはならないかもしれませんが、利用しているインスタンスからより多くの価値を引き出すことができます。 3. 戦略的コミットメント計画 AWS コミットメント戦略を策定する際には、ワークロードの存続期間 (1 年または 3 年)、インスタンスファミリーの要件やリージョンの柔軟性といった要素が節約効果を最大化するのに役立ちます。 Savings Plans Purchase Analyzer は、過去の利用パターンを調べるのに役立ち、これらの要因に基づいて最適なコミットメントを推奨してくれます。特定のリージョンで特定のインスタンスファミリーを必要とする場合には、 EC2 Instance Savings Plans (EC2SPs) が最も大きな割引を提供します。また、Compute Savings Plans (CSPs) では、割引率が下がりますが、インスタンスの世代やリージョンを問わない高い柔軟性を提供します。CSPs を使用すると、コミットされた割引特典を失うことなく、リージョン間でワークロードを移動したり、新しいインスタンスファミリーにアップグレードしたりできます。どちらを選択するかにもよりますが、オンデマンド料金と比較して最大 72% 節約できます。そのため、Savings Plans は AWS インフラストラクチャーにとってインパクトのあるコスト最適化プランとなっています。 4. リソース効率の最大化 アクセラレーター (GPU、Trainium や Inferentia) の使用率を追跡することで、リソースがどの程度効率的に利用されているかをより理解できます。GPU 使用率メトリクスは、インスタンス要件の検証、効率の最大化、またチームやプロジェクト間でのリソース共有の機会特定に役立ちます。CPU 使用率の監視は比較的簡単ですが、GPU 監視には独特の課題があります。前述したように、最適なインスタンスタイプを選択する際、GPU 使用率としてより詳細なメトリクスが必要になります。GPU の使用率を推定するために使用できる指標は、温度と消費電力の 2 つです。これらのメトリクスは CloudWatch エージェント から取得でき、このアプローチにより GPU 飽和度を推定できるため、リソースの使用パターンに関する重要な洞察が得られます。この見積もりにより、既存のインフラストラクチャーからより大きな効用を得ることができ、総所有コスト (TCO)の削減につながります。 （画像内訳：生成 AI の効率性を評価する上で最も難しい側面の 1 つは、リソースがどれだけうまく利用されているかを理解することです。特に GPU に関しては、従来のパフォーマンス指標だけでは必ずしもすべてを把握できるとは限りません。消費電力や熱出力などの要素を評価することで、スループットやレイテンシだけでなく、実際の効率をより深く把握できます。生成 AI ワークロードの最適化は、リソースをどれだけ長く使用しているかだけでなく、リソースの機能を最大限に活用しているかどうかも重要です。 Brent Segner, Distinguished Engineer, Capital One） Amazon SageMaker AI AI/ML の取り組みを加速させていると、戦略的な決定を迫られることになります。機械学習インフラストラクチャーの構築とメンテナンスにリソースを投資すべきか、それともビジネス成果の推進に向けて努力を振り向けるべきか、というものです。 Amazon SageMaker AI はこのジレンマに対する理想的なソリューションであり、必要な柔軟性を維持しながら、差別化されていない重い作業を排除するフルマネージドサービスを提供します。 SageMaker JumpStart は、構築済みのソリューション、すぐに導入できるモデルやサンプルノートブックを提供することで、すぐに使い始めるのに役立ちます。SageMaker AI への取り組みを始めたばかりでも、既存の実装の最適化を検討している場合でも、これらの戦略は、より効率的で費用対効果の高い AI および 機械学習ソリューションの構築に役立ちます。 1. 成功のためのライトサイジング SageMaker AI インスタンスのタイプとサイズを最適化すると、ソリューションのパフォーマンスとコスト効率の両方に効果がある場合があります。使用パターンを注意深く分析し、SageMaker AI インスタンスを戦略的に適切なサイズにすることで、機械学習インフラストラクチャーのコストを削減できます。ワークロードに適したインスタンスタイプとサイズを選択するには、テストが重要です。前述した FM Bench は、このプロセスを簡単にするための貴重なツールです。 2. モデルのキャパシティとコストバランス 機械学習ワークロードに適したモデルを選択することは、効果的な SageMaker AI プロジェクトを構築する上で最も重要な決定の 1 つです。慎重にモデル選択をすることで、パフォーマンスとコスト効率の両方を最大 45% 向上させることができます。次の 3 つの重要な要素を評価する体系的なアプローチをお勧めします。1) 特定のユースケース要件、2) 利用可能な計算リソース、3) 予算。たとえば、大規模言語モデル (LLM) は優れた機能を備えていますが、 単純なモデルで事足りる簡単なタスクでは必ずしも最も費用対効果の高いソリューションであるとは限りません。SageMaker Jumpstart のモデルから始めることで、最適な結果を得ることができます。SageMaker Jumpstart は、基盤モデル、組み込みアルゴリズムやビルド済みの機械学習ソリューションを備えたハブです。その後、より高度な (そして多くの場合より高価な) モデルによって得られるメリットが、追加の計算コストと財務コストを正当化するかどうかを評価できます。このような反復的なモデル選択アプローチは、多くの場合、技術的に優れ、より持続可能なソリューションにつながります。 3. SageMaker AI Savings Plans の活用 機械学習ソリューションを大規模に運用するには、運用の柔軟性を維持しながらコストを最適化することが重要です。 Machine Learning Savings Plans (MLSPs) は、従量制の価格設定モデルよりも、SageMaker AI の料金を最大 64% 節約できるコミットメントです。これらのプランでは、1 年または 3 年の期間にわたって一定量の使用量（1 時間あたりの金額で算出）のコミットメントが必要です。MLSPs を特に強力にしているのは、その柔軟性です。割引は、SageMaker Studio ノートブック、SageMaker オンデマンドノートブック、SageMaker Processing、SageMaker Data Wrangler、SageMaker トレーニング、SageMaker リアルタイム推論や SageMaker バッチ変換の対象となる SageMaker ML インスタンスの使用に自動的に適用されます。つまり、コミットメントによる削減効果を失うことを心配することなく、機械学習インフラストラクチャーを自由に革新して調整できるということです。MLSPs は、特に継続的な機械学習の運用において、手間をかけずに大幅なコスト最適化を実現できます。コスト効率を維持しながら機械学習の取り組みを拡大したいと考えている場合、MLSPs はシンプルかつ効果的であるため欠かせません。 4. スポットインスタンスによるトレーニングのコスト最適化 Amazon SageMaker AI のマネージドスポットトレーニング は、機械学習ワークロードのコスト最適化戦略を提供します。スポットインスタンス価格を活用することで、オンデマンドインスタンスと比較してトレーニングコストを最大 90% 削減できるため、予算が限られているプロジェクトにとって価値のあるオプションとなります。この費用対効果の高いアプローチは、時折中断しても許容できる、時間にセンシティブではないトレーニング作業に特に適しています。AWS Graviton プロセッサと組み合わせると、コストパフォーマンスの面でさらに大きなメリットが得られます。このプロセスを使いやすくするために、SageMaker AI ではスポットインスタンスのライフサイクルを自動的に管理できます。これは、インスタンスが再利用された場合でもトレーニングの進行状況が維持されるように、 チェックポイントを使用して、モデルの状態を保存する ことで実現されます。そのため、開発やテストの環境、およびトレーニング時間に柔軟性があるその他の環境に最適なソリューションになります。 5. 適切な推論戦略の選択 Amazon SageMaker AI は、様々なユースケースとコスト構造に合わせて設計された推論デプロイのオプションをいくつか提供しています。詳細については、 推論コスト最適化のベストプラクティス を参照してください。リアルタイム推論ではレイテンシーは低くなりますが、インスタンスが常時実行されるため、継続的なコストが発生します。リアルタイム推論は、即時対応が必要なアプリケーションに最適です。断続的なワークロードのコストを削減するために導入された Amazon SageMaker Serverless Inference は、使用していないときは自動的に エンドポイントをゼロまでスケールダウンさせ、呼び出し中に使用されたコンピューティング時間に対してのみ課金されます。バッチ処理の場合、 SageMaker AI バッチ変換 は、永続的なエンドポイントを維持せずに大規模なデータセットを一括処理することにより、最も費用対効果の高いソリューションを提供します。最後に、 非同期推論 は、リクエストを非同期で処理するため、ペイロードが大きく、処理時間が長く、またリアルタイムに近いレイテンシーが必要な場合に最適です。アイドル時にインスタンスを自動的に停止することでコストを削減できるため、リクエストが処理されているときにのみ支払いが発生します。 これらの最適化戦略を実装することで、高いパフォーマンスとスケーラビリティを維持しながら、インフラストラクチャーのコストを大幅に削減できます。成功の鍵は、これらの選択肢を特定のユースケースやビジネス要件に合わせて調整し、コストを削減するだけでなく、機械学習運用の長期的な成功に向けて最適化することです。 結論： この投稿では、Amazon EC2 と SageMaker AI を使用してカスタム AI モデルを開発するためのコスト最適化戦略について説明しました。次回のブログでは、スマートモデル選択、ナレッジベースの最適化やキャッシュ戦略など Amazon Bedrock のコスト最適化手法について詳しく説明します。コストを抑えながら基盤モデルの価値を最大化する方法について、次回のブログをお楽しみに。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスの主任プロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。

はじめに 本ブログでは、Ｓｋｙ株式会社様の更なるコスト意識向上を目指して実施したコスト最適化実践ワークショップである Experience-Based Acceleration（EBA）FinOps Party を通じ、ワークショップ参加チームにおいてAWS 利用料が年間 20% の最適化見込みとなった事例をご紹介します。幾つかのワークロードを AWS へ移行した直後にワークショップを実施したことで、早期に最適化されたコストに近付くことができています。EBA FinOps Party ワークショップは、オンプレミスから AWS への移行方式として Rehost を採用し、クラウド最適化の検討ができていない場合に最も効果が見込まれます。 ※ Ｓｋｙ株式会社様の状況において 20% の最適化見込みとなりましたが、すべてのお客様で同程度の効果が見込まれることを保証するものではございませんのでご留意ください。 Ｓｋｙ株式会社様について Ｓｋｙ株式会社様は、クライアント運用管理ソフトウェアの SKYSEA Client View、営業名刺管理サービスの SKYPCE といった自社パッケージ商品の開発・販売、協業・連携ソリューションの販売・導入などの SI ビジネスを手掛けています。AWS アドバンストティアサービスパートナーであり、日本初の AWS Service Catalog を含む複数のサービスデリバリープログラムを取得し、AWS Summit Japan 2024 にも出展いただきました。ユーザー企業の内製化を支援するためのソリューションを持った日本独自の AWS パートナーである「内製化支援推進 AWS パートナー」でもあります。営業名刺管理サービス SKYPCE のクラウド版は AWS で稼働しており、AWS ファンデーショナルテクニカルレビュー（FTR）の認定を受けています。 EBA FinOps Party 実施の背景 Ｓｋｙ株式会社様では、従業員のコスト意識向上とコスト最適化のスキルアップを継続して測っており、培ったノウハウを SI 事業におけるお客様に提供しておりますが、お客様へ最適なコストで提案が可能となるエンジニアを創出していくために社内で継続的にコスト意識を根付かせていきたいと考えていました。こちらに対して、コスト最適化を組織として取り組む FinOps 実践を目的としているワークショップ EBA FinOps Party の実施を AWS から提案しました。EBA FinOps Party では、単なるコスト「削減」ではなく、組織として無駄なコストを抑制するための継続的な「最適化」活動を実施するためのフレームワークである Cloud Financial Management（CFM）や、コスト可視化、最適化に利用できる AWS サービスを学べます。ワークショップの最後には、学んだことを活かしてコスト最適化施策報告をエグゼクティブに向けて行い、エグゼクティブにコスト最適化施策実施のスポンサーとなっていただくため、コスト意識が更に向上することが期待され開催に至りました。事前に CFM フレームワークに則ったアセスメントを行いアジェンダを検討し、Ｓｋｙ株式会社様では以下内容で 3 日間に分けて開催しました。 Day1: 基礎編（1 時間） コスト最適化フレームワーク紹介 CFM フレームワーク、コスト最適化に関する AWS サービス・ソリューションのご紹介 Day2: 実践編（2 時間 30 分） AWS Cost Explorer の概要・ハンズオン コスト配分タグ、RI/SPs の紹介、AWS Cost Explorer での推奨事項確認方法、報告会に向けたコスト最適化の確認ポイントの説明 Instance Scheduler on AWS 紹介 Instance Scheduler on AWS の概要、設定・実施のデモンストレーション スポットインスタンス紹介 スポットインスタンスの概要、ベストプラクティスの紹介 Day3: 報告会（1 時間） コスト最適化施策ご報告 検討したコスト最適化施策のエグゼクティブ向け発表 Day1：基礎編 1 日目の基礎編では、CFM フレームワークとコスト最適化に関する AWS サービスについてご紹介しました。CFM フレームワークは組織的に「可視化」、「最適化」、「計画・予測」のサイクルを回すこと、つまり「FinOps の実践」を行い、より効果的なコスト最適化を継続的に行うものです。 CFM フレームワークを AWS で実践する場合について簡単にご説明します。「可視化」では、AWS アカウントの分離、タグ付けにより分析の土台を整え、AWS Cost Explorer や Cost &amp; Usage Report を利用し分析を行います。「最適化」では、インスタンスサイズや購入オプション（RI/SPs、スポットインスタンス）の見直しなどを行うクイックウィン最適化と、サーバレスやマネージドサービスを利用したアーキテクチャへと変更するアーキテクチャ最適化を検討します。「計画・予測」では、AWS Cost Explorer の予測機能、AWS Budgets の予測アラート機能を利用し、クラウド利用の計画・予測を行います。CFM フレームワークの詳細に関しては、ブログ「 クラウド財務管理はコスト削減以上のメリットをもたらす 」または builders.flash 記事「 AWS でのコスト最適化の進め方 」をご参照ください。 Ｓｋｙ株式会社様では、「可視化」のアクションとして AWS Cost Explorer を毎日確認されているメンバーもいる一方で、コスト最適化に関する AWS サービスの概要を把握されていないメンバーもいらっしゃいました。このようにスキルが異なるメンバーを集い改めてコスト最適化について学ぶことで、全員が同じ知識を持ってコスト最適化に向かえる状態になることができました。 Day2：実践編 2 日目の実践編では、AWS からハンズオンをご提供するため、タイムリーにフォローができるように Ｓｋｙ株式会社様のオフィスでワークショップを実施しました。コンテンツは、AWS Cost Explorer を利用したコスト分析ハンズオン、 Instance Scheduler on AWS 、スポットインスタンスのご紹介です。AWS Cost Explorer のハンズオンは、3 日目のエグゼクティブへの報告に向けて、各 AWS アカウントのコストとコスト最適化のための推奨事項を各自で確認できるようになることが目的です。Instance Scheduler on AWS およびスポットインスタンスのご紹介に関しては、事前のアセスメントにおいて「弾力的なクラウド利用」と「スポットインスタンスの活用」という項目のスコアに改善余地が見受けられたので、重点的にご支援をするためにアジェンダに組み込んでいます。なお、ワークショップの内容に関しましては、例えば「AWS Budgets のデモンストレーションが見たい」などお客様のニーズに合ったコンテンツをリクエストしていただけます。 本ブログでは各 AWS サービス、ソリューションに関するご説明は割愛しておりますので、以下をご参照ください。 AWS Cost Explorer AWS Black Belt（ 動画 、 資料 ） Instance Scheduler on AWS builders.flash 記事「 サーバーを指定した期間で停止する「AWS Instance Scheduler」を試してみる 」 動画「 AWS ソリューションを動かしてみよう – Instance Scheduler on AWS 編 」 Amazon Elastic Compute Cloud (Amazon EC2) スポットインスタンス AWS Black Belt「Amazon EC2 スポットインスタンスの基礎」（ 動画 、 資料 ） AWS Black Belt「Amazon EC2 スポットインスタンス活用のための 6 つのベストプラクティスと実践例」（ 動画 、 資料 ） AWS Cost Explorer ハンズオンにおいては、「インスタンスタイプや Amazon Simple Storage Service (Amazon S3) ストレージクラスが AWS Cost Explorer で確認できることを初めて知った」、「コスト最適化の余地を幾つか見つけられた」といった声をいただきました。AWS Cost Explorer はコスト「可視化」の目的で利用されることが多いですが、「最適化」の観点でもご利用いただけます。Instance Scheduler on AWS は Amazon EC2 および Amazon Relational Database Service（Amazon RDS）の開始・停止スケジュールを組むことができるソリューションですが、ワークショップ中の時間内に停止するシナリオで実際に設定・停止する様子をご覧いただいたことで活用イメージを持っていただきました。スポットインスタンスについては、Ｓｋｙ株式会社様では利用されている部署が限定的であったため、他の部署においても Amazon EC2 インスタンス使用時の選択肢として挙がるように、Ｓｋｙ株式会社様が不安に感じられていた中断への備えやベストプラクティスのご説明を行いました。 Day1、Day2 の内容を踏まえて、Day 3 までの宿題として各チームが管理する AWS アカウントにおいてコスト最適化施策を検討します。RI/SPs のカバー率・利用率、Amazon EC2 インスタンスタイプ、ダウンサイジング可否、土日の稼働、Amazon Elastic Block Store (Amazon EBS) gp3 ボリュームの利用、Amazon S3 Glacier の利用状況などの調査により、今後のアクションと削減効果を検討いただきました。 Day3：コスト最適化施策報告会 3 日目は、Day2 の宿題を元に各チームよりコスト最適化施策をエグゼクティブへ発表いただきました。発表内容はいずれも素晴らしく、チーム毎にコストやリソースを精査し削減額を算出しており、クイックウィン最適化の施策のみで一部チームにおいて年間 20% のコスト最適化見込みとなりました。 特に最適化の効果が大きかったのは、ここ数ヶ月の間に社内システムを幾つかオンプレミスから AWS に移行されたチームでした。クラウドへ移行した当時の状態でコスト最適化が遅れてしまい、予算を超過し続けていることがビジネス課題になってしまっているお客様が多い中で、移行後すぐにコスト最適化に着手できたことは短期的にも長期的にも良い結果となります。 施策の例としては、インスタンスタイプの再選定後の RI/SPs の購入や AWS Graviton への移行検討、Instance Scheduler on AWS を利用した土日の稼働停止などが挙がり、具体的な実施スケジュールを記載いただいたチームもございました。スポットインスタンスに関しても本番での利用はまだためらいがあるが、検証時のみ利用するなど活用の余地が垣間見えていました。 各チームの発表後、エグゼクティブからは「円安の影響もあり AWS を利用することでコストが高くなる傾向にあるが、ワークショップの形でコストを細かく削減する方法を見せていただき勉強になった。クラウドとオンプレミスのコストの違いをデータとして蓄積していきたい。商品開発の原価にも影響するため、現場のメンバーにはコストをぜひ意識してほしい」というコメントを頂戴し、FinOps EBA Party は閉会となりました。 おわりに 本ブログでは、Ｓｋｙ株式会社様とワークショップを実施し、年間 20% のコスト最適化見込みとなるクイックウィン最適化施策を検討いただいた事例をお伝えしました。参加された方からは、「コストの意識を見直す良い機会でした」、「コスト削減できるポイントの洗い出しと対応方法検討を進めていきます」、「コスト最適化に利用できる AWS サービスの概要を知れて良かった」といったコメントをいただき、AWS との協業ビジネスを推進しているアライアンスチームからも、「既に最適化されているシステムだけでなく、AWS ビギナーのエンジニアを中心として立ち上げている部分にも、こういった EBA FinOps Party を適応することで、イノベーションだけではなく、コストの意識を根付かせることが可能になります。結果として、お客様にもコストを意識したご提案ができる、Ｓｋｙ のクラウドソリューションに繋がりますので、継続して活用していきたいです」というコメントをいただきました。 クラウドジャーニーのフェーズはお客様によって異なるためすべてのお客様で同等の効果が出るとは限りませんが、コスト最適化施策を会社全体で腰を据えて検討することは非常に効果があります。CFM フレームワークにあるとおり、コスト削減は 1 度実施すれば終わりではなく、継続的にコスト最適化を図る必要があるため、引き続き Ｓｋｙ株式会社様と検討した施策の遂行、効果測定およびコスト最適化施策の検討を行います。 改めて EBA FinOps Party にご参加いただいた Ｓｋｙ株式会社の皆様、ありがとうございました。 このブログはソリューションアーキテクト 北川 友稀 が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 新年度が始まりましたね。 MetaもLlama 4を発表 しましたし、新しいことに取り組むにはいいタイミングなのではないでしょうか？私もちょっと新しいことということで、AWSの認定試験である AWS Certified AI Practitioner を取得してみました。入門者向けの認定ではありますが、幅広く知識の再確認ができて新鮮な気持ちになりました。せっかくなので、ひとつ難易度が高い AWS Certified Machine Learning Engineer – Associate も受けてみようかなぁとおもう今日この頃です。 それでは、3 月 31 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース MetaのLlama 4モデルがAWSで利用可能に MetaがLlama 4モデルを発表 し、AWSでもご利用いただけるようになりました。現時点ではLlama 4 Scout 17BとLlama 4 Maverick 17Bの2種類を、Amazon SageMaker JumpStartでトレーニング済みのモデルをすぐに触っていただくことができます。Amazon Bedrockでのフルマネージドな形での利用も近日公開予定です。Llama 4 Scout 17Bは、コンテキストウィンドウが最大1,000万トークンに拡張されたことで、包括的な分析や推論を必要とするアプリケーションに対応可能です。またLlama 4 Maverick 17Bは12種類の言語に対応し、画像とテキストの理解に優れた汎用モデルで高度なアシスタントやチャットアプリケーションに最適です。ぜひAmazon SageMaker StudioのJumpStartでモデルを起動し、触ってみてください！なお、本記事執筆時点ではSageMaker AIのコンソールからは検索にひっかからないようですが、SageMaker StudioのJumpStartから起動できることを確認しました。 AWS生成AI国内事例ブログ「キヤノンITソリューションズ株式会社様：ローコード開発プラットフォームのコード生成機能を 3 ヶ月で構築。サービス利用者は開発工数を最大 50% 削減可能に」を公開 キヤノンITソリューションズ株式会社 様は、ローコード開発プラットフォーム「 WebPerformer-NX 」を提供しています。このプラットフォームでは基本的な機能はGUIで実装ができるものの、複雑な機能の実現や外部サービスとの連携には手動での開発が必要になり、それ相応のスキルが求められるということが課題でした。この課題の解決のために、Amazon Bedrockを利用したコード生成機能を導入し、より多くのビジネスユーザがスムーズなアプリケーション開発を実行できるようにする機能強化に取り組んでいらっしゃいます。現時点で生成されたコードの70-90%がそのまま利用可能で、複雑なロジックの開発工数を最大50%削減できるという結果がでています。また、自然言語による指示が可能になりより多くのビジネスユーザがアプリケーション開発に参加できるようになったそうです。 ブログ記事「Amazon EKS Hybrid Nodes を活用し、様々な環境にわたって生成 AI 推論を実行する」を公開 生成AIの推論ワークロードを様々な場所で実行したいというご相談をいただくことがあります。クラウドで実行するのはもちろん、当面の間はオンプレミスで保有する資産も活用したいというケースや、レイテンシの観点でどうしても現場に近い場所で推論したいというケースなどがあります。この記事では、Amazon EKS(Elastic Kubernetes Service) Hybrid Nodesを利用して、クラウドとオンプレミスの双方を統合的に管理しつつ、推論ワークロードを自在にデプロイする方法を解説しています。 ブログ記事「AWSによる生成AIのコスト最適化」を公開 実際の業務に対する生成AIの適用が進むにつれて、コストに関する課題が持ち上がることが増えてきました。実証実験(PoC)であればともかく、継続的に生成AIを活用するためには現実的なコスト感で維持できることが必要になります。この記事では、AWSで生成AIに取り組みにあたってコスト最適化を行うための方法をピックアップしてご紹介しています。実践的なヒントについては今後公開する一連のブログ記事で深掘りしていきますので、お楽しみに。 サービスアップデート Amazon Q DeveloperによるAmazon OpenSearch Serviceの支援機能が一般利用開始に Amazon Q DeveloperによるAmazon OpenSearch Serviceのサポート機能が一般利用開始になりました。自然言語によるデータの可視化や、ワンステップでのデータ探索によるインテリジェントなアラートの要約、クエリ結果の要約、異常検出、OpenSearchに特化した質問に対する回答といったAIによる支援機能が提供されています。 これに関するブログがあります ので、あわせてどうぞ。 Amazon QuickSightがAmazon Q in QuikSightの埋め込みに対応 Amazon QuickSightはWebページへのダッシュボード埋め込みに対応しています。今回、生成AIがデータからインサイトを得る作業を支援するAmazon Q in QuickSightの機能をもちいたダッシュボードについても、Webページへの埋め込みができるようになりました。これまで以上にインタラクティブなダッシュボードを構築することで、より幅広いユーザ層に対してデータ活用を可能にすることが期待できます。 全てのサブスクライバーがAmazon Q Business Browser Extensionを利用可能に Amazon Q BuisnessはGoogle Chrome, Mozilla Firefox, Microsoft Edgeの各種ブラウザー向けに、機能拡張を提供しておりWebページの要約やコンテンツに対する質問をシームレスにAmazon Q Businessに依頼することができます。Amazon Q Businessの画面に切り替える必要がなくなりますので、ユーザ体験の向上に寄与する機能ですね。 Amazon SageMakerのビジュアルETLで新たに9つの変換処理を提供 Amazon Q Developerを利用してグラフィカルにETLフローを構築するためのインタフェースが提供されており、これをビジュアルETL(Visual ETL)と呼んでいます。今回新たに、9つの組み込み変換処理が追加されました。例えば「派生列(Derived column)」を利用すると、ある列のデータを数式またはSQLで処理して、新しい列を定義することができます。他にもデータ処理において便利な組み込み処理が追加されています。 Amazon Kendra GenAI Indexが2リージョンで利用可能に RAGアプリケーションでの情報検索に最適化されたAmazon KendraのGenAI Indexが欧州(アイルランド)とアジアパシフィック(シドニー)のリージョンで利用可能になりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 今週から4月に入り、新しい組織に異動となったり、年度が変わるタイミングで今年こそはと気持ちを引き締めて業務に取りかかっている方も多いのではないでしょうか。そんな方々におすすめな、マイグレーションとデータ基盤に関するオンサイト限定イベントが開催されます。 4/15&nbsp;基幹システム移行によるビジネス変革 [ エントリ ] 4/17 経営の未来を左右するデータ基盤 – 最新技術の潮流に乗るステップ[ エントリ ] オンサイトですので、新たな交流の機会としてもご活用いただければと思います。私も現地でお客様のサポートをさせていただきますので、現場でお会いできるのを楽しみにしていいます。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年3月31日週の主要なアップデート 3/31(月) AWS IoT Device SDK for Swift の開発者プレビューを発表 AWS IoTデバイス開発者向けに、新しい Swift 言語用の SDKの開発者プレビュー版がリリースされました。この SDK を使用することで、開発者は Linux、macOS、iOS、tvOS といったプラットフォーム向けの IoT アプリケーションを構築できるようになります。特に iOS モバイルアプリケーション開発者にとって、最新の Swift 言語を使用して直感的なインターフェースでアプリケーションを開発できる利点があります。また、この SDK を通じて MQTT プロトコルを使用して AWS IoT サービスに接続することが可能です。 Amazon Connect Contact Lens でセンチメント分析の有効化/無効化が可能に Amazon Connect Contact Lens において、感情分析機能を有効/無効に切り替えられるようになりました。これは企業にとって感情分析の制御を可能にする重要な機能追加です。Contact Lens は通話内容の分析を行うサービスですが、コンプライアンス要件を満たす必要がある組織にとって、この柔軟な制御は特に有用です。この更新により、感情分析を無効にした場合でも、会話の文字起こし、生成 AI による要約、その他の会話分析機能は引き続き利用できます。具体的な使用例として、ブランドイメージの把握が必要な一般的な問い合わせ窓口では感情分析を有効にし、社内の苦情受付ラインでは感情分析を無効にするといった使い分けが可能になります。これにより、組織のニーズや規制要件に応じて、より細かな制御が可能になりました。 API Gateway がデュアルスタック (IPv4 および IPv6) エンドポイントのサポートを開始 Amazon API Gateway (APIGW) が、すべてのエンドポイントタイプ、カスタムドメイン、および管理用 API において、デュアルスタック (IPv4 と IPv6 の両方) に対応したことをお知らせします。これにより、REST API、HTTP API、WebSocket API、そしてカスタムドメインにおいて、既存の IPv4 に加えて IPv6 クライアントからのアクセスを受け付けることが可能になりました。また、APIGW の管理用 API もデュアルスタッククライアントからの呼び出しに対応します。この機能により、システム全体を一度に切り替える必要なく、IPv4 から IPv6 環境への段階的な移行が可能になります。これは、IPv6 対応が必要なコンプライアンス要件を満たしたり、IPv4 アドレスの制約を回避したりする際に役立ちます。さらに、この機能の利用に追加料金は発生しません。このアップデートは、将来的な IPv6 への移行を見据えている組織にとって、スムーズな移行パスを提供する重要な機能強化となります。 Amazon OpenSearch Service で Amazon Q Developer が一般提供開始 Amazon OpenSearch Service において、Amazon Q Developer が一般提供を開始しました。これは AI を活用して運用分析や調査プロセスを迅速化する機能セットです。今回のリリースでは、5つの重要な AI 支援機能が導入されました。自然言語を使用した可視化の生成、ワンステップでのデータ探索機能を備えたインテリジェントなアラート要約、Discover ページでのクエリ結果の要約、推奨される異常検知、そして OpenSearch に関する質問に対応する専用の Amazon Q Developer チャットインターフェースです。Amazon Q Developer を使用することで、チームは自然言語入力を可視化に変換し、アラートやクエリ結果から即座に洞察を得ることができ、推奨機能を通じて異常検知の作成をスムーズに行うことができます。 4/1(火) Amazon VPC Route Server の一般提供開始を発表 Amazon VPC Route Server が一般提供開始となりました。この新機能は、Amazon VPC 内の仮想アプライアンス間の動的なルーティングを簡素化するものです。Route Server を使用することで、Border Gateway Protocol (BGP) を通じて仮想アプライアンスからルーティング情報をアドバタイズし、サブネットやインターネットゲートウェイに関連付けられた VPC ルートテーブルを動的に更新することができます。この機能が登場する以前は、VPC ルートテーブルを動的に更新するために、カスタムスクリプトを作成するか、オーバーレイネットワークを使用する仮想ルーターを使用する必要がありました。VPC Route Server によって、オーバーレイネットワークやカスタムスクリプトの作成・維持にかかる運用の手間が解消され、ルートテーブルの動的更新のためのマネージドソリューションが提供されるようになりました。 Amazon QuickSight でハイライト機能がサポートされました Amazon QuickSight に新機能としてハイライト機能が追加されました。この機能により、分析やダッシュボード上で特定のデータポイントを強調して追跡できるようになります。これは、シート全体でデータ要素を比較し、より効果的にインサイトを探索することを容易にします。ハイライト機能の使い方は非常に直感的で、ビジュアル内のデータポイントを選択するか、マウスをホバーするだけで、他のビジュアルの関連データが強調表示され、関連のないデータは薄暗く表示されます。このシームレスな相互作用により、ユーザーは相関関係を理解し、パターン、トレンド、異常値を素早く発見することができ、より迅速で的確な分析が可能になります。 AWS Backup が Amazon Redshift Serverless のサポートを開始 AWS Backupで、Amazon Redshift Serverlessのサポートが開始されたことをお知らせします。これにより、Amazon Redshift Serverlessデータウェアハウスのデータ保護を一元的に管理することが容易になりました。AWS Backupを使用することで、Amazon Redshift Serverlessと Amazon Redshift プロビジョニングクラスターのスナップショットのバックアップと復元を自動化できるようになりました。これは、コンピューティング、ストレージ、データベースなどの他の AWS サービスと同様に管理できます。また、AWS Backup と AWS Organizations の連携により、組織全体のデータ保護を標準化し、すべてのアカウントで変更不可能なバックアップを一元的に作成・管理することが可能になりました。 4/2(水) Amazon SageMaker で 9 個の新しいビジュアル ETL 変換機能を追加 Amazon SageMaker の Visual ETL に 9 つの新しい変換機能が追加されました。Visual ETL は、データの抽出・変換・読み込み (ETL) 作業をドラッグアンドドロップで簡単に実行できるインターフェースを提供するサービスです。今回追加された機能は「Derived column (派生列の作成)」「Flatten (データの平坦化)」「Add current timestamp (現在のタイムスタンプ追加)」「Explode array or map into rows (配列やマップを行に展開)」「To timestamp (タイムスタンプへの変換)」「Array to columns (配列を列に変換)」「Intersect (交差)」「Limit (制限)」「Concatenate columns (列の連結)」の 9 つです。これらの新機能により、ETL 開発者はより高度なデータパイプラインを、カスタムコードを書くことなく構築できるようになりました。 AWS Clean Rooms の Spark SQL が集計とリスト分析ルールをサポート AWS Clean Roomsの新機能として、Spark SQLで集計とリストの分析ルールをサポートしました。この機能により、プライバシーを強化しながらデータ分析が可能になります。AWS Clean Rooms Spark SQLを使用することで、お客様とパートナー企業は集計分析、リスト分析、カスタム分析のルールを活用しながら、パフォーマンス、スケール、コストの要件に基づいて設定可能なリソースでSQLクエリを実行できます。 Amazon Connect でスーパーバイザーが進行中のチャットに対して追加のアクションを実行可能に Amazon Connect のスーパーバイザー向け機能が強化され、進行中のチャットに対してより多くのアクションが Amazon Connect の UI から直接実行できるようになりました。この機能強化により、問題解決のスピードが向上し、カスタマーサービスの品質向上が期待できます。具体的には、スーパーバイザーは応答のない顧客とのチャットを終了させたり、特定のエージェントやキューにチャットを再割り当てしたりすることが可能になりました。 Amazon CloudWatch Application Signals SLO を使用してサービスの依存関係を監視が可能に Amazon CloudWatch Application Signals で、サービスの依存関係を監視するための新機能が追加されました。この機能により、サービス間の依存関係のパフォーマンスを監視し、SLO (Service Level Objectives: サービスレベル目標) を設定して問題を事前に解決できるようになりました。Application Signals を使用することで、期間ベースまたはリクエストベースの SLO を作成し、サービスから依存先へのリクエストに関する重要な指標 (レイテンシーやエラーなど) を追跡できます。これにより、依存関係のパフォーマンスとそれがサービス全体の信頼性にどのような影響を与えているかを把握できます。 4/3(木) Amazon Q Business ブラウザ拡張機能が全サブスクライバーに利用可能に Amazon Q Business のブラウザ拡張機能が、Google Chrome、Mozilla Firefox、Microsoft Edge で一般提供開始されたことをお知らせします。この拡張機能は Amazon Q Business を契約している全てのユーザーが利用できます。Amazon Q Business は AWS が提供する生成系 AI アシスタントですが、この拡張機能によってウェブブラウザ上で直接 AI による支援を受けることができるようになります。具体的には、ブラウザで表示しているウェブページの要約や、ページの内容に関する質問への回答、さらには企業の情報へのアクセスなどが、ページを離れることなく実行できます。 SES メールマネージャーが PrivateLink を介したカスタマー VPC からの着信接続をサポート Amazon SES (Simple Email Service) のメール管理機能「Mail Manager」において、PrivateLink を介してお客様の VPC (Virtual Private Cloud) からの接続をサポートするようになりました。2024年半ばにリリースされた Mail Manager において、VPC 接続機能は最も要望の多かった機能でした。この機能により、AWS 内で大規模なアプリケーションを運用しているお客様は、それらのアプリケーションの送受信メールを Mail Manager を通じて安全にルーティングできるようになります。 Amazon Neptune が 99.99% の可用性を持つ SLA (Service Level Agreement) を発表 Amazon Neptune のサービスレベルアグリーメント (SLA) が更新され、マルチAZデータベースインスタンス、マルチAZデータベースクラスター、およびマルチAZグラフの月間稼働率が 99.90% から 99.99% に引き上げられました。これは AWS がミッションクリティカルなアプリケーションのためのグラフデータベースサービスとして、より高い可用性と信頼性を提供することへのコミットメントを示すものです。この新しい SLA では、AWS は商業的に合理的な努力を行い、Amazon Neptune のマルチAZ構成のサービスにおいて、毎月の請求サイクルで少なくとも 99.99% の月間稼働率を実現することを目指します。 Amazon Security Lake が IPv6 (Internet Protocol Version 6) に対応 Amazon Security Lake が IPv6 (Internet Protocol version 6) に対応したことをお知らせします。これにより、お客様は IPv6 アドレスを使用して Amazon Security Lake の設定と管理が可能になりました。インターネットの成長に伴い IPv4 アドレスが枯渇してきている中で、この IPv6 対応は重要な意味を持ちます。Amazon Security Lake は、AWS環境やSaaSプロバイダー、オンプレミス環境、クラウドソースからのセキュリティデータを自動的に集約し、お客様のアカウント内の専用データレイクに保存するサービスです。このサービスを使用することで、組織全体のセキュリティデータをより包括的に把握でき、ワークロードやアプリケーション、データの保護を強化することができます。 4/4(金) Amazon SES の送信 API で添付ファイルをサポート Amazon SES (Simple Email Service) において、メール送信 API で添付ファイルをサポートする機能が追加されました。この機能により、SES の簡易送信 v2 API を使用する際に、PDFドキュメントなどのファイルを添付したり、メール本文中にインライン画像を埋め込んだりすることが可能になりました。これまでは、SES の簡易送信 API でテキストやHTML形式のメール本文を送信することはできましたが、添付ファイルやインライン画像を含めるためには、より複雑な API を使用してメールのデータ構造を自分で構築する必要がありました。今回のアップデートにより、ユーザーは MIME メッセージの構造について詳しい知識がなくても、PDF、Word、GIF などの SES がサポートする MIME タイプのファイルを簡単に添付できるようになりました。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本記事は、 NetApp のソリューションアーキテクト 井上 耕平氏、テクニカルソリューションスペシャリスト 川端 卓氏、シニアクラウドソシューションアーキテクト 藤原 善基氏、AWS セールススペシャリスト 小寺 加奈子氏、アマゾン ウェブ サービス ジャパン合同会社のシニアプロトタイピングソリューションアーキテクト 小泉 秀徳、パートナーソリューションアーキテクト 山田 磨耶による共同執筆です。 データ活用のトレンド 生成 AI の発展により、データ活用の在り方は大きな転換期を迎えました。従来のデータ分析は主に構造化データを対象としていましたが、生成 AI 利用により画像や音声を含む非構造化データのデータ分析も可能となり、活用可能なデータの範囲が拡大しています。また、これまでデータの分析者には専門知識が求められていましたが、生成 AI を活用した自然言語によるデータ分析が実現され、誰もがデータを活用し、インサイトを引き出せるようになりました。 このように生成 AI を活用することで、分析対象となるデータの量や種類、分析プロセスが大きく変化している一方で、データ活用への生成 AI 導入にはいくつかの課題が存在します。 生成 AI × データ活用の課題 生成 AI を使ったデータ活用でまず考えられる課題として、組織の所有データに生成 AI がアクセスする環境を用意することが困難であることが挙げられます。現在多くの生成 AI の機能はクラウドサービスとして提供されており、最新の機能や性能を利用するためにはクラウドからのデータ活用が重要になります。一方で、多くのデータはオンプレミスに存在しており、これらのデータをクラウドに移行するためには、多くのコストと時間が必要となります。既にクラウドストレージを利用している企業であっても、生成 AI 機能を活用するためにデータ移行が必要となるケースも考えられます。 また、これからデータを収集する状況であっても、組織のセキュリティやコンプライアンスの要件により、データをクラウドに保管することが難しいケースも見受けられます。 このような課題に対し、データを既存のデータストレージに保持したまま、AWS が提供する生成 AI 機能によってデータを活用するためのソリューションを NetApp と AWS の 2 社で開発しました。本記事では、共同開発ソリューションを使った 国立大学法人広島大学 様による実証実験の概要と、共同開発ソリューションの特徴についてご紹介します。 広島大学様との実証実験 2024 年から 2025 年にかけて、広島大学様と共同で行った実証実験についてご紹介します。 広島大学様においても、上述の課題をお持ちでした。大学の情報インフラを管理する上で、学内で持つ機微な研究データをクラウドに保管することはデータの長期保管やセキュリティの観点から難しく、特にデータへのアクセス権の管理についてはこれまで以上に煩雑になることが推測されます。更に、教育や学習データを蓄積するシステムが増加し、これらを活用して教育の質の向上や個別学習支援の期待が高まっているものの、各部門が独立したシステムでデータを管理していること、個人情報保護法や General Data Protection Regulation (GDPR) などのコンプライアンス順守に向けた管理体制が未成熟であることなど、教育データを管理し利活用するためのスキルが不足しているという課題をお持ちでした。 図 1 広島大学様セッションスライドより、大学の情報インフラ課題の重要性 大学の情報インフラもオンプレミスのみの環境からクラウドと混在した環境に変化しており、今後求められるインフラは結局何が良いのかと検討されていた中で、スモールスタートで構築できるハイブリッド生成 AI インフラ環境を構築し実験することとなりました。 図 2 広島大学様セッションスライドより、AI 技術の導入と生成 AI の活用 ハイブリッド生成 AI 環境を考える上で特に考慮した点は、図 2 のとおり学内のストレージに格納されている機微なデータ、いわゆるクローズドデータの扱いについてでした。AWS にデータを保管する際には、一般的に Amazon Simple Storage Service (Amazon S3) というオブジェクトストレージサービスが利用されます。手元のクローズドデータを利用したハイブリッド生成 AI 環境を考えた際、 「Amazon S3 へデータをアップロードする構成」の課題として、以下の点が挙げられます。 一部の機微なデータはクラウドに持っていけない 大規模なデータの移動にコストと時間がかかる ２ 箇所以上 (オンプレミスの元データと Amazon S3) の重複したデータの管理が困難 オブジェクトストレージ である Amazon S3 にデータを移動すると権限情報などのメタデータが失われる データの移動後、セキュリティとデータ保護の再適用が必要 これらの課題に対し、NetApp のテクノロジーを利用した課題解決として NetApp ONTAP によるデータ連携を提案しました。具体的には、FlexCache によるキャッシュの活用、または SnapMirror による非同期複製の活用です。このデータ連携により、データの特性に応じて、生成 AI 機能を利用する環境をクラウドやオンプレミスなどから選択し、シームレスなデータ活用が可能となります。具体的には、Data Mobility と Data Infrastructure により、それぞれの課題の解決を実現します。 Data Mobility (データの可搬性) 生成 AI アプリケーションの近くにデータを配置 データ転送にかかる時間とコストを削減 データの二重管理不要 Data Infrastructure (データの管理) フォルダ構造をそのまま保持 設定済みのアクセス権をそのまま保持 データを保護し、セキュリティを確保 図 3 実証実験の技術的なポイント 実証実験は、以下３パターンの構成で実施しました。 パターン1 ：Amazon S3 を利用した構成 パターン2 ： NetApp BlueXP Workload Factory と Amazon FSx for NetApp ONTAP (FSx for ONTAP) を利用した構成 この構成について、詳細は AWS Solutions Library をご確認ください パターン3 ：AWS の標準サービス と FSx for ONTAP を利用した構成 特にパターン 3 では、NetApp ONTAP のキャッシュ機能である FlexCache を利用し、オンプレミスの NetApp ONTAP から FSx for ONTAP にデータ連携することにより、以下の 3 点のメリットを実現できます。 オンプレミスのデータがそのままキャッシュ側である FSx for ONTAP で参照できる キャッシュ側である FSx for ONTAP のデータの容量はオンプレミス NetApp ONTAP の 1/10 程度に抑えられる オンプレミスのファイルアクセス権情報をそのまま保持できる 図 4 ONTAP のキャッシュ機能のメリット パターンごとの想定利用シーンを吟味して、今回の実証実験ではパターン 3 にフォーカスし、 NetApp と AWS 両社でソリューションとして開発しました。 図 5 検証パターンごとのメリット パターン 3 の構成では、オンプレミス、AWS と環境を問わずエンド・ツー・エンドで NetApp ONTAP の強力なデータ保護機能である SnapLock 、Tamperproof Snapshot などをデータ保護の観点で活用できます。これらの活用により、OWASP Top10 for LLM Application (※1) で 4 番目のリスクに上がっている「LLM04: データとモデルのポイズニング」から保護することも可能です。具体的な機能のメリット、利用方法につきましては 参考ブログ をご覧ください。 ※1：出典 ” OWASP Top 10 for LLM Applications 2025”, OWASP,（2024/11） https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ AXIES ランチョンセッション発表 共同実証実験の内容について、 大学 ICT 推進協議会 (AXIES:Academic eXchange for Information Environment and Strategy) 2024 年度年次大会 のランチョンセッションにて、広島大学情報メディア教育研究センター 准教授 渡邉先生、NetApp 保村氏が発表しました。当日は 119 名の方にご参加いただき、事前に構築した生成 AI アプリケーションの動作についてもデモ動画にてご紹介しました。 ご参加いただいた皆様からは、「 来る AI 時代に向けて学内のデータをどのように活用すればいいか検討しており大変参考になった 」、また「 AI の活用ももちろんであるが、学内のデータをいかに守るかというセキュリティの観点からも話を聞けたのは良かった 」という声をいただきました。 クラウドサービス利用シンポジウム ハンズオン実施 広島大学様との 共同実証実験で開発したソリューションについて、構築・利用を体験するためのハンズオンコンテンツを NetApp、AWS 両社で作成しました。 作成したハンズオンコンテンツは、2025/3/13 (木) 開催「 大学等におけるクラウドサービス利用シンポジウム2025 」のハンズオンセミナー「こんなに簡単にできるハイブリッド生成AIインフラ！- 広島大学×NetApp×AWSが考える生成AI環境をつくって、さわってみよう」にて提供しました。当日は 14 名の方が参加し、ハンズオンを完走いただきました。参加者からは「 学内のオンプレ環境で実装する際の参考にさせて頂きます。ありがとうございました！ 」「 オンプレミス側のハンズオンが含まれているのが非常に良かったです。引き続きハイブリッド構成による生成 AI 利活用についてディスカッション及び協業させて頂きたいです。 」といった声をいただいています。 2 社共同でのソリューション開発・ハンズオンコンテンツ作成にあたって、AWS Prototyping Program と AWS CDK トレーニングを NetApp に提供しました。 ソリューション概要 実証実験で使用されたソリューションは、「 Amazon Bedrock と Amazon FSx for NetApp ONTAP を使用して AWS で RAG ベースの生成 AI アプリケーションを構築する 」で解説されているソリューションをベースとしています。このオリジナルのソリューションは、生成 AI を実現するための複数の 基盤モデル (FM) を提供する Amazon Bedrock や、ONTAP の一般的なデータアクセスおよび管理機能を AWS で提供する FSx for ONTAP から構成されます。また、多くの生成 AI アプリケーションで利用される Retrieval Augmented Generation (RAG) を実現する機能を埋め込んでおり、実践的な生成 AI の利用を支援します。オリジナルのソリューションについて、詳細は こちらの記事 をご参照ください。 実証実験では、より簡単にオンプレミスのデータを AWS と連携し、AWS 上に生成 AI を使ったデータ分析の機能を実装するために、オリジナルのソリューションに加えて以下のカスタマイズを行いました。 オンプレミスと AWS のデータ連携実装 AWS Cloud Development Kit (AWS CDK) による Infrastructure as a Code (IaC) 化 この 2 点について、それぞれご紹介します。 オンプレミスと AWS のデータ連携実装 実証実験、ハンズオン実施環境については、オンプレミス NetApp ONTAP と FSx for ONTAP を ONTAP のキャッシュ連携機能である FlexCache を利用して接続することにより、オンプレミスに格納しているデータを AWS 上の FSx for ONTAP、ナレッジ DB、生成 AI チャットボットアプリケーション から利用できるようにしています。 図 6 ハンズオン環境イメージ AWS CDK による Infrastructure as a Code (IaC) 化 Architecture 本ソリューションは、オリジナルのソリューションを基にセキュリティ、拡張性、UI 観点でアーキテクチャやコンポーネントを変更しています。なお、Embedding Container による、Vector Embeddings とメタデータ (SID など) を Vector Store に保存するといったコア機能は変更していません。Vector Embeddings に関するフローに関しては、 こちらの記事 をご確認ください。 図 7 RAG Chatbot with Amazon FSx for ONTAP Architecture diagram Terraform から AWS CDK へ変更 学習コストを抑え、使い慣れたプログラミング言語 (今回は TypeScript) で AWS のインフラを定義する観点で、AWS CDK in TypeScript で定義しています。 セキュリティ機能の追加 生成 AI チャットボットアプリケーションへのアクセス制限として、 AWS Web Application Firewall (AWS WAF) と Amazon CloudFront をフロントエンドの前段に配置しています。 Amazon Cognito を利用したユーザー認証と認証画面を追加実装しています。 生成 AI チャットボットアプリケーションの変更 フロントエンドの言語も AWS CDK と同じ TypeScript に統一する観点から、 React のフレームワークである Next.js でフロントエンドを実装しています。 オリジナルのソリューションではフロントエンドを Amazon Elastic Compute Cloud (Amazon EC2) 上で稼働していましたが、本ソリューションでは AWS Lambda Web Adaptor を利用して AWS Lambda 上で稼働させています。 RAG による回答に加え、回答生成に利用したドキュメントソースとコンテンツを チャット画面で確認できるよう変更しています。 Embedding Container と Chatbot Container の分離 オリジナルのソリューションでは、同一 Amazon EC2 上で両 Container が稼働していましたが、ビジネスロジック観点で稼働環境を分離しています。Embedding Container は Amazon EC2、Chatbot Container は前述のように AWS Lambda 上で稼働させています。 生成 AI モデルの追加 Claude モデルに加え、 Amazon Nova (Micro, Lite and Pro) を追加しました。コスト、レイテンシーなどの要件に応じてチャット画面からモデル選択が可能です。 Amazon Bedrock のスループット向上のため、 クロスリージョン推論 をサポートしました。 Vector Store の選択 オリジナルのソリューションでは Vector Store として Amazon OpenSearch Serverless がデプロイされますが、本ソリューションでは Amazon Aurora Serverless v2 も選択できます。ユースーケースに応じてコードベースで変更可能です。 まとめ データ保管は従来のまま、生成 AI を使ってデータを活用するためのソリューションについてご紹介しました。データの移動が困難な状況や、セキュリティや管理の観点でデータの保管場所を変更できない状況で、最先端の生成 AI 機能を利用する場合にご活用いただけます。 広島大学様との共同実証実験でもその有用性が期待され、オンプレミスの NetApp ONTAP と FSx for ONTAP の利用により、シームレスなデータ連携を実現するソリューションを NetApp と AWS の両社で開発しました。このソリューションは AWS CDK によってコードで定義されているため、 AWS アカウント があればどなたでも環境構築が可能です。コードは以下の GitHub リポジトリで公開されていますので、デプロイ方法などの詳細は以下をご確認ください。 NetAppJpTechTeam/Permission-aware-RAG-FSxN-CDK: https://github.com/NetAppJpTechTeam/Permission-aware-RAG-FSxN-CDK/ また、このソリューションの構築・利用を体験するためのハンズオンコンテンツも作成しています。ソリューションのデプロイに関するお問い合わせや、ハンズオンのご要望などがありましたら、以下のメールアドレスまでご連絡をお願いいたします。 本ソリューションに関するお問い合わせ (NetApp)： ng-genai-japan-awsteam@netapp.com 参考ブログ ランサムウェア被害から医療データの安全を守る サイバーレジリエンシーブログ： 【寄稿】サイバーレジリエンスとはなにか？ 【寄稿】Amazon FSx for NetApp ONTAP イミュータブルバックアップの利用でランサムウェア対策の強化 【寄稿】そのデータ復旧できますか？ 著者について 井上 耕平 (Kohei Inou) ネットアップ合同会社 ソリューション技術本部 ソリューションアーキテクト部 Solutions Architect 前職SIerにて、IoT/AIに関わるシステムの提案からデリバリーまで幅広く経験。現在は、AI/IoTシステムをストレージの観点から支援するソリューションを担当。趣味はサッカー観戦、登山、旅行 川端 卓 (Suguru Kawabata) ネットアップ合同会社 ソリューション技術本部 SE第4部 テクニカルソリューションスペシャリスト これまでにサーバー/ストレージのベンダーにてプリセールスからポストセールスまで経験。現在は西日本のお客様に向けてAI/生成AIやサイバーレジリエンスのソリューションを中心に提案活動・ハンズオンなどを担当。趣味は魚釣り、ゴルフ 藤原 善基 (Yoshiki Fujiwara) ネットアップ合同会社AWS SE Support / Sr. Cloud Solutions Architect 前職ではネットワークエンジニア、AWSエンジニアを経験。AWS Japanから2024 AWS Japan Top Engineerの認定を受けており、AWSのユーザコミュニティではCommunity Builderとして、全国各地で活動しています。趣味は、外食、旅行、ロックフェスティバルなど。 小寺 加奈子 (Kanako Kodera) ネットアップ合同会社AWSセールススペシャリスト 前職ではAWSクラウド事業の責任者を経験。現在は、ネットアップではSales SpecialistとしてAWSへのマイグレーションを中心に、導入支援やマーケティング活動等に従事。 趣味はお琴、読書。 小泉 秀徳 (Hidenori Koizumi) アマゾンウェブサービスジャパン合同会社 パブリックセクター技術統括本部 エマージングテクノロジー本部 シニアプロトタイピングソリューションアーキテクト 理学のバックグラウンド(生物学、化学など)を活かした研究領域でのソリューション作成を得意としています。フロントエンドからバックエンドまでの Web アプリケーション開発を行なっており、趣味は旅行と写真撮影です。 山田 磨耶 (Maya Yamada) アマゾンウェブサービスジャパン合同会社 パブリックセクター技術統括本部 パートナーアライアンス技術部 パートナーソリューションアーキテクト 公共領域における AWS パートナーの活動を技術面で支援しており、技術相談やトレーニング提供を行っています。 前職では AWS エンジニアとして金融業界のシステム開発に従事。趣味は謎解き、ボードゲーム

2024 年 12 月をもって Jeff Barr が AWS ニュースブログを離れましたが 、AWS News Blog チームは、極めて重要で影響力のある AWS 製品のリリースが利用可能になり次第、関連情報を引き続き共有していきます。ニュースブログの将来に関する Jeff の最後のコメントをあらためて引用します: 今後もチームは成長を続けますが、最新かつ極めて有意義な AWS のリリースについて、厳選された質の高い情報をお客様に提供するという目標は変わりません。このブログは、優れた人々に引き継がれます。AWS のイノベーションのペースが加速し続けている中、このチームは引き続き皆さんに情報を提供してまいります。 2016 年以来、Jeff はチームの一員として AWS ニュースブログの発展に貢献してきました。私たちは現在、北米、南米、アジア、欧州、アフリカで活動する 11 人のブロガーのグループです。私たちは AWS の製品チームと協力し、お客様に代わって新機能を直接テストしたり、Jeff がこれまで行ってきたようにニュースブログで重要な詳細を伝えたりしています。 Jeff が LinkedIn で共有した「 Leadership Principles for AWS News Bloggers 」は、テクノロジー企業のお客様向けにブログを書いている人にとっては教科書のような内容です。これらは、ブログ作成を理解してすぐに開始するのに役立つ基本的な事項であり、私たちはチームとしてこれらの原則を守り続けます。これが、AWS ニュースブログが他のテクノロジー企業の製品ニュースチャンネルとは一味違う理由です。 ブログの作成者の声 ニュースブログの作成者の名前はご存知かもしれませんが、その人物像について知る機会はなかったかもしれません。メンバーの自己紹介をぜひご覧ください! Channy Yun (윤석찬) ニュースブログチームの新しいリードブロガーとして Jeff の功績を継承できることを光栄に思います。Jeff は私のロールモデルです。2014 年に AWS に入社したとき、最初に取り組んだのは、 AWS Korea Blog を作成し、Jeff のブログ記事を韓国語に翻訳することでした。その過程で、私は、お客様が新しい AWS 製品や機能の使用を開始するのに役立つ、正確かつ誠実で強力なガイドの書き方を学びました。 Danilo Poccia 私は、 2018 年に初めてニュースブログを投稿して以来 、このチームの一員として多くのことを学んできました。製品マネージャーやサービスチームと協力することは、いつもすばらしい経験です。私は、サーバーレス、イベント駆動型アーキテクチャ、AI/ML に関心があります。生成 AI などのテクノロジーが、(AI 対応の開発ツールを通じて) 暗黙的に、また、(コードでモデルを使用することによって) 明示的に、ソフトウェア開発の一部になりつつあるのは驚くべきことです。 Sébastien Stormacq 私は 2019 年からこのチームの一員であり、これはとても幸運なことです。記事を作成していないときには、 AWS Developers Podcast と le podcast AWS en français のエピソードを制作しています。私はまた、 Amazon EC2 Mac 、 AWS SDK for Swift 、 CodeBuild および CodeArtifact のチームと協力して、Apple デベロッパーにとって AWS クラウドをより利用しやすくすることにも取り組んでいます。私のお気に入りのプロジェクトは、 Swift Runtime for AWS Lambda です。 Veliswa Boya Amazon リーダーシッププリンシプル (LP) は、ニュースブログの著者としての取り組みを含め、AWS における私たちのあらゆる活動の指針となっています。私は Developer Advocate として、LP のガイダンスを採り入れるとともに、LP のガイダンスを参照しながら、技術的なコンテンツの作成を目指す AWS コミュニティのメンバー、特に技術的なコンテンツ作成のジャーニーに初めて参加するメンバーをガイドしてきました。 Donnie Prakoso コーヒーを淹れるのと同じように、ブログの作成では、楽しさ、挑戦、やりがいを感じることができます。私は、「Customer Obsession」(お客様中心主義) が AWS のチームにどのように組み込まれているのかを観察できるという、大きな幸運に恵まれました。これらのチームがどのように目的から逆算して取り組みを進め、お客様のフィードバックをサービスや機能に変えていくのかを目にしてきました。私たちの記事をお楽しみいただき、News Blog チームの次の章を心待ちにしていただければ幸いです。 Esra Kayabali 私は著者として、ビルダー、デベロッパー、テクノロジーに情熱を注ぐ人々から成る世界中のオーディエンスに、AWS の最新のイノベーションとリリースに関する適時な情報をお届けすることに尽力しています。AWS サービスを効果的に利用するのに役立つ、明確かつ正確で実用的なコンテンツを提供することの重要性を理解しています。皆さん、ぜひお読みください! Matheus Guimaraes 私の専門は .NET 開発とマイクロサービスですが、常に何でも屋でもあります。このブログのために記事を書くことは、最新のテクノロジーのあらゆる側面で鋭い感覚を発揮するのに役立ちますし、他のユーザーにとっても同じように役立つでしょう。何千もの人々が AWS ニュースブログを読んでおり、最新情報を把握して、意思決定に役立てるための頼りになる情報源として利用しています。そのため、私たちが行っていることは大きな影響力をもたらす、有意義な仕事であると確信しています。 Prasad Rao 私は、自分のブログを通じて、新しいサービスの「内容」だけでなく、ビジネスおよびユーザーエクスペリエンスを変革できる「理由」と「方法」にも光を当てるよう心がけています。 Microsoft Workloads on AWS を専門とする Solutions Architect として、お客様がワークロードを移行およびモダナイズし、AWS でスケーラブルなアーキテクチャを構築するのをサポートしています。また、多様な人々がクラウドキャリアで優れた結果を生み出せるよう指導しています。 Elizabeth Fuentes 新しいブログを書き始めるたびに、このチームの一員であること、リリース前に新しいサービスを実験できること、そして、私の経験を読者と共有できることを光栄に思います。このチームは、複数の国から集まったあらゆるレベルのスペシャリストで構成されており、多文化かつ多専門のチームです。読者の皆様、ご関心をお持ちいただき、ありがとうございます。 Betty Zheng (郑予彬) News Blog チームに参加したことで、テクノロジーに関するコミュニケーションの方法が変わりました。常に好奇心を持ち、革新的なサービスを利用しやすくし、より多くの魅力をお伝えできるように、新しい発表に取り組んでいます。デベロッパーが心から楽しみながら当社の最新テクノロジーの詳細を学ぶのに役立つよう、私の独自かつ多様な視点を技術的なコンテンツに取り入れようと努めています。 Micah Walter 私は、Senior Solutions Architect として、ニューヨーク市周辺およびそれ以外の地域の企業のお客様をサポートしています。持続可能性と実用的な設計に重点を置き、エグゼクティブ、エンジニア、アーキテクトに、クラウドジャーニーのあらゆる段階でアドバイスを提供しています。 また、舞台裏で活躍する Editor-in-Chief である Jane Watson と Program Manager である Jane Scolieri もご紹介します。この 2 人は、 re:Invent 2024 において、1 週間で発表した 60 件のリリース など、製品リリースのニュースをできるだけ早くお客様にお届けする上で重要な役割を果たしています。 フィードバックをお寄せください AWS はお客様中心主義です。私たちは常に、カスタマーエクスペリエンスの改善および提供に注力しており、そのためにはお客様のフィードバックが必要です。 アンケート にご回答いただき、AWS ニュースブログでのお客様のエクスペリエンスに関するインサイトや、さらに優れたサービスを提供するためのご提案をぜひお聞かせください。 このアンケート は、外部の企業によって実施されます。AWS は、 AWS プライバシー通知 に記載されているところに従って、お客様の情報を取り扱います。AWS はこのアンケートを通じて収集されたデータを所有します。また、収集された情報をアンケートの回答者と共有することはありません。 – Channy 原文は こちら です。

AWS Architectural Resilience Day は、AWS のお客様がワークロードの回復力の向上に役立つアーキテクチャのベストプラクティス、AWS サービスについて学べる無料の対面でのイベントです。レジリエンスについて学ぶ座学と、ハンズオンを含む実践的なワークショップに参加して、 災害復旧、高可用性ワークロードの設計、エラー修正プロセスの実装について学んで頂けます。重要なアプリケーションの回復力を IT 運用のライフサイクルの中で継続的に改善したいと考えておられる開発者様、運用者様に特に役に立つ内容となっております。 また、 AWS Resilience Hub や AWS Fault Injection Service のハンズオンを通してアプリケーションの回復力の評価、改善の自動化も体験頂けます。 2024年10月には東京で開催（開催報告は こちら ）させて頂き、今回大阪での初開催となりました。 まだ寒さの残る早朝より、52名のお客様に中之島オフィスにお越し頂きました。関西からの参加だけでなく、九州からご参加頂いた方も！たくさんの方に参加頂き誠にありがとうございました！！ アジェンダ このセミナーでは、座学と ハンズオン を交互に織り交ぜながら進めていきます。 形式 タイトル スピーカー 資料 – オープニング 三好 史隆 ※1 – 座学 AWSにおけるレジリエンス入門 猪又 赳彦 ※4 Download 座学 レジリエンスの目標を設定する 猪又 赳彦 Download ハンズオン AWS Resilience Hubを活用したRPO/RTOの設定 三好 史隆 – 座学 レジリエンスの設計と実装 新谷 歩生 ※2 Download ハンズオン 高可用性のための設計と実装 三好 史隆 – ハンズオン ディザスタリカバリに備えた設計と実装 三木 康次 ※3 – 座学 レジリエンスの評価とテスト 安藤 麻衣 ※1 Download 座学 レジリエンスの運用 長倉 隆浩 ※5 Download ハンズオン AWS Fault Injection Serviceを用いたレジリエンス評価とテスト 三木 康次 – 座学 インシデントへの対応と学習 森 啓 ※2 Download ハンズオン インシデント対応からの学習 三木 康次 – ※1. Solutions Architect, ※2. Sr. Solutions Architect, ※3. Technical Account Manager, ※4. Sr. Technical Account Manager, ※5. Customer Solutions Manager オープニング 本セミナーは、AWS レジリエンスライフサイクルフレームワークの 5 つの主要なステージに沿って進められます。みなさまにレジリエンスの向上に役立つさまざまな戦略、サービス、ツールについての学びを持ち帰って頂きたいという思いを総合司会の三好よりお伝えしました。 三好 史隆 Solutions Architect AWSにおけるレジリエンス入門 AWS のシステムレジリエンスにおいて、システム障害は避けられない前提で対策を講じることが重要です。このセッションでは、レジリエンスを確保するための取り組みとして、テクノロジーだけでなく、人・プロセスの重要性、さらに AWS の責任共有モデルに基づいて、AWS によるクラウドのレジリエンスを確保するための取り組みと、継続的なレジリエンス活動の重要性を説く AWS レジリエンスライフサイクルフレームワークを紹介しました。 &nbsp; &nbsp; &nbsp; 猪又 赳彦 Sr. Technical Account Manager レジリエンスの目標を設定する 前のセッションから引き続き、猪又よりシステム障害による経済的影響の大きさを改めて共有したうえで、ビジネス目標を設定し、必要なレジリエンスのレベルの定義の必要性について紹介しました。目標設定では、RPO と RTO を指標として使用しますが、システム全体で一律の目標を設定するのではなく、コンポーネントごとに重要度を考慮した現実的な目標設定が推奨されます。これらの目標設定と評価を支援するサービスとして AWS Resilience Hub の活用をご紹介しています。レジリエンスのレベルを定義するには、ビジネス目標の明確化と、それに対する経営陣の理解と関与を得ながら、継続的な改善を進めることが重要であることをお伝えしました。 &nbsp;AWS Resilience Hubを活用したRPO/RTOの設定 ハンズオンの開始です。このセクションでは、AWS 上のアプリケーションの回復力を分析、管理、改善できるサービス AWS Resilience Hub を使って、レジリエンシーポリシーへの準拠状況を確認します。AWS Resilience Hub へアプリケーションの目標 RTO / RPO を入力して準拠状況を確認します。下の図では、現状はレジリエンシーを満たしていないことが確認できます。 AWS Resilience Hub – 目標 RTO / RPO に対する評価結果の出力 レジリエンスの設計と実装 このセッションでは、回復力のあるデザインパターンについて、例と共にご紹介しました。レジリエンスに関してはトレードオフが存在することをお伝えした上で、設計をする上で考慮すべき点として、リソース管理を担うコントロールプレーンと実行処理を担うデータプレーンの理解、変更なしで安定稼働を維持する静的安定性、そして AZ やリージョンでの障害分離境界の考え方、セルアーキテクチャ、グレースフルデグラデーション、バイモーダル動作などを例にデザインパターンのベストプラクティスをご紹介しました。 新谷 歩生 Sr. Solutions Architect &nbsp;高可用性のための設計と実装 再びハンズオンです。このセクションでは、AWS Resilience Hub を使って、レコメンデーションを適用した後に再評価を実行して、レジリエンシーポリシーを満たしているかを確認します。AWS Resilience Hub が推奨する改善案に沿ってアプリケーションを修正した結果、目標 RTO / RPO に準拠していることが確認できました。 AWS Resilience Hub – レジリエンシーの評価結果 (改善後) &nbsp;ディザスタリカバリに備えた設計と実装 午後最初のセッションは三木へリードをバトンタッチして、ハンズオンからスタートです。リージョン障害に対する復元力目標が達成できていないことを確認して、評価の理由を確認したうえでアプリケーションを修正し再評価して、復元力目標を達成していることを確認します。 AWS Resilience Hub – リージョン障害に対するレジリエンシーの評価結果 (改善前) AWS Resilience Hub – リージョン障害に対するレジリエンシーの評価結果 (改善後) 三木 康次 Technical Account Manager レジリエンスの評価とテスト このセッションではレジリエンスの評価とテストとして、予期せぬシステム障害への対応力を高めるための手法としてのカオスエンジニアリングと、実施するためのプロセスについてご紹介しました。また、実環境での障害実験を実施するためのサービスとして、AWS Fault Injection Service の活用を具体例とともに示し、予期せぬシステム障害、潜在的な問題を発見するためのアプローチとその重要性についてご紹介しました。 安藤 麻衣 Solutions Architect レジリエンスの運用 このセッションでは、レジリエントなシステムを維持していくための運用の重要性についてご紹介しました。システムの健全性を担保するためにはメトリクスの監視が不可欠ですが、過剰なデータ収集は障害検知・回復の遅延をまねき、RPO / RTO の目標達成にも影響してしまいます。メトリクスの監視においては、システムのステータスだけでなく、ユーザー体験への影響を測定することが重要です。これらを踏まえ、ビジネス目標に基づいて適切なメトリクスを特定し、監視を実施することの重要性をお伝えしました。 長倉隆浩 Customer Solutions Manager &nbsp;AWS Fault Injection Serviceを用いたレジリエンス評価とテスト AWS Resilience Hub はレジリエンシーの目標 RTO / RPO を満たすアーキテクチャを提案するだけでなく、障害注入実験を行うための AWS CloudFormation テンプレートも提供します。これには AWS Resilience Hub の一機能である AWS Fault Injection Service (FIS) が利用されます。ハンズオンでは、FISを用いてAmazon Relational Database Service (Amazon RDS)をフェイルオーバーさせ、その際にアプリケーションが目標RTOを満たしているかをテストしました。 AWS Resilience Hub – 障害注入実験のテンプレート AWS CloudWatch Dashboard – バックエンドの応答状況 インシデントへの対応と学習 最後の座学セッションとなるインシデントへの対応と学習では、インシデント検知時の分析の重要性と、インシデント発生後の分析と学びを共有することの重要性について学びました。システム問題の検知においては、単一指標だけでなく複数の観点からの分析の重要性、CloudWatch Contributor Insights の活用をご紹介しました。またインシデント発生後は、技術的観点だけでなく人とプロセスも含めた障害原因の分析を行い、得られた学びについて組織内で共有し、そしてこれらの取り組みのサイクルを継続して実践することの重要性をお伝えしました。 森 啓 Sr. Solutions Architect インシデント対応からの学習 最後のセッションでは、AWS Resilience Hub でアプリケーションの全体的なレジリエンススコアを確認しました。レジリエンススコアは、アプリケーションのレジリエンスポリシーを満たし、アラーム、標準運用手順（SOP）、障害注入実験を実装するための推奨事項にどれだけ近いかを反映しています。このスコアの内訳を確認し、継続的に評価・改善する方法を学びました。 AWS Resilience Hub – 耐障害性スコア おわりに 今回は大阪での初開催となる AWS Resilience Day in Osaka についてレポートしました。レジリエンスライフサイクルフレームワークに基づいて学ぶ座学と、ハンズオンを通して、レジリエントなシステムを構築する重要性とアーキテクチャのベストプラクティスについて理解を深めて頂いたかと思います。 ご参加頂いたみなさま、本当にありがとうございました。頂いたフィードバックをもとにこれからも改善を重ねて参ります。本日の内容が少しでも皆様の業務のお役に立てば幸いです。 2025年4月17日には、東京で2回目の開催となる AWS Resilience Day in Tokyo も予定されていますので、ご興味ある方は担当営業にご相談ください。 &nbsp; 著者 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネジャー 長倉隆浩

3 月 31 日、運用データの調査と視覚化を支援する AI 支援機能を提供する Amazon Q Developer のサポートが Amazon OpenSearch Service 向けに提供されることを発表しました。Amazon Q Developer は、クエリ言語、視覚化ツール、アラート機能の学習曲線を短縮することで、OpenSearch Service のエクスペリエンスを強化します。この新機能によって自然言語探索とパターン検出が有効になり、既存のダッシュボードと視覚化が補完されます。インシデントが発生した後、追加の視覚化をすばやく作成して、モニタリングインフラストラクチャを強化できます。この強化されたワークフローによってインシデントの解決が加速され、エンジニアリングリソースの使用が最適化されるため、お客様は、トラブルシューティングではなくイノベーションに集中できるようになります。 Amazon OpenSearch Service 内の Amazon Q Developer は、自然言語探索と生成 AI 機能を OpenSearch ワークフローに直接統合することで、運用分析を改善します。インシデント対応中、アラートとログデータのコンテキストをすばやく把握できるようになったので、分析と解決にかかる時間が短縮されます。アラートモニターがトリガーされると、Amazon Q Developer のアラートインターフェイスに概要とインサイトが直接提供されるので状況をすばやく理解できます。専門家に依頼したり資料を調べたりする必要はありません。そこから Amazon Q Developer を使用して、基礎データの確認、自然言語を使用した視覚化の構築、パターンの特定による根本原因の特定を行うことができます。例えば、リージョン、データセンター、エンドポイントなどのディメンションごとにエラーを分類する視覚化を作成できます。さらに、Amazon Q Developer はプロアクティブなアラート向けのダッシュボード設定を支援し、異常検知機能を推奨するので、初期モニタリングの設定とトラブルシューティングの効率性の両方が向上します。 OpenSearch Service での Amazon Q Developer の使用を開始する 開始するには、 OpenSearch のユーザーインターフェース にアクセスしてサインインします。ホームページから、OpenSearch Service で Amazon Q Developer をテストするワークスペースを選択します。このデモでは、ユーザーインターフェイスで利用できるサンプルログデータセットを含む事前構成済みの環境を使用します。 この機能は、 Amazon Q Developer 無料利用枠 でデフォルトで有効になっています (この無料利用枠もデフォルトで有効化されています)。この機能を無効にするには、ドメインの作成時に [人工知能と機械学習] セクションの [自然言語クエリの生成を有効にする] チェックボックスの選択を解除するか、コンソールでクラスター設定を編集します。 OpenSearch ダッシュボードで、左側のナビゲーションペインから [検出] に移動します。自然言語を使用してデータを調べるには、 PPL 言語に切り替えてプロンプトボックスを表示します。 メインナビゲーションバーの Amazon Q アイコンを選択して Amazon Q パネルを開きます。このパネルを使用して、アラートを生成するために推奨される異常検出機能を作成することや、自然言語を使用して視覚化することができます。 [Ask a natural language question] テキストボックスに次のプロンプトを入力します。 Show me a breakdown of HTTP response codes for the last 24 hours 結果が表示されると、これらの結果の概要が Amazon Q によって自動的に生成されます。Amazon Q パネルの [Show result summarization] オプションを使用して要約の表示を制御し、要約を表示または非表示にすることができます。「いいね」ボタンまたは「あんまり」ボタンを使用してフィードバックを提供することや、コピーボタンを使用して概要をクリップボードにコピーすることができます。 OpenSearch Service 内の Amazon Q Developer のその他の機能には、自然言語による記述からの視覚化の直接生成、会話形式での OpenSearch 関連のクエリの支援、OpenSearch アラート用に AI が生成した要約とインサイトの提供、データの分析、そして適切な異常検出機能の提案があります。 自然言語による記述から視覚化を直接生成する方法を見てみましょう。 Amazon Q パネルから [Generate visualization] を選択します。入力フィールドに「 Create a bar chart showing the number of requests by HTTP status code 」と入力し、[Generate] を選択します。 視覚化を調整するには、 [ビジュアルの編集] を選択し、「 Show me a pie chart 」や「 Use a light gray background with a white grid 」などのスタイルの説明を追加します。 今すぐご利用いただけます OpenSearch Service で Amazon Q Developer を使用して解決までの平均時間を短縮し、セルフサービスのトラブルシューティングを有効にして、チームがオブザーバビリティデータからより大きな価値を引き出すことができるようになりました。 このサービスは、現時点で米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ) の AWS リージョンでご利用いただけます。 Amazon Q Developer のドキュメント で詳細を参照して、今すぐ OpenSearch Service ドメインで Amazon Q Developer の使用を開始してください。 – Esra ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

この記事は Run GenAI inference across environments with Amazon EKS Hybrid Nodes (記事公開日: 2024 年 3 月 19 日) を翻訳したものです。 この記事は、Principal Container Specialist SA である Robert Northard、EKS の Senior Product Manager である Eric Chapman、Senior Specialist Partner SA である Elamaran Shanmugam が執筆しました。 イントロダクション Amazon Elastic Kubernetes Service ( Amazon EKS ) Hybrid Nodes は、クラウドとオンプレミスにわたって生成 AI 推論ワークロードを実行する方法を変革します。EKS クラスターをオンプレミスのインフラストラクチャに拡張することで、管理の一貫性と運用の複雑さの軽減を実現しながら AI アプリケーションをデプロイできます。Amazon EKS はマネージドな Kubernetes コントロールプレーンを提供し、EKS Hybrid Nodes を使用すると、オンプレミスのインフラストラクチャをワーカーノードとして Amazon EKS コントロールプレーンに参加させることができます。これにより、オンプレミスで Kubernetes コントロールプレーンを管理する必要がなくなります。EKS Hybrid Nodes を使用すると、単一の EKS クラスター内でクラウドとオンプレミスの両方のキャパシティを活用できます。 EKS Hybrid Nodes は、次に挙げるような多くの AI/ML のユースケースとアーキテクチャを実現できます。 レイテンシーの影響を受けやすいワークロードをサポートするための、エッジでのリアルタイム推論を含むユーザに近い場所でのサービス実行 データレジデンシーに関する要件のためにオンプレミスに留まらなければならないデータを使用したモデルのトレーニング ナレッジベースを使用した RAG アプリケーションのような、ソースとなるデータに近い場所での推論ワークロードの実行 ピーク需要時に多くのコンピュートリソースを利用するために AWS クラウドの弾力性を利用 既存のオンプレミスハードウェアの利用 本記事では、単一の EKS クラスターを使用し、EKS Hybrid Nodes を活用してオンプレミスで AI 推論を実行し、さらには Amazon EKS Auto Mode を活用して AWS クラウドでも実行する概念実証 (PoC) について説明します。EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングなどの Kubernetes クラスターの管理を自動化します。EKS Auto Mode の詳細については、 Amazon EKS ユーザーガイド をご覧ください。 ソリューション概要 本記事の例における推論ワークロードのため、 NVIDIA NIM を通じてモデルをデプロイします。NVIDIA NIM は、GPU を使って AI モデルを実行するために NVIDIA によって最適化されたマイクロサービスです。EKS Hybrid Nodes と EKS Auto Mode の両方を有効化した EKS クラスターを作成し、オンプレミスのマシンをハイブリッドノードとしてクラスターに参加させます。オンプレミスへのデプロイでは、モデルを EKS Hybrid Nodes にデプロイする前に、NVIDIA ドライバーと Kubernetes 用の NVIDIA デバイスプラグインをインストールします。最後に、NVIDIA GPU と AWS Neuron インスタンスに必要なドライバーが事前構成されている EKS Auto Mode のノードにモデルをデプロイします。このウォークスルーには、EKS Hybrid Nodes を実行するためのハイブリッドネットワークと認証の前提条件を確立する手順は含まれていません。これらは Amazon EKS ユーザーガイド に記載されています。 図 1: EKS Hybrid Nodes と AWS リージョンにおける EKS ノードの両方を含む EKS クラスターの概要 上記は、このウォークスルーで使用するアーキテクチャのハイレベルな図を示しています。 Amazon Virtual Private Cloud (VPC) には、EKS Auto Mode のワーカーノードをホストする 2 つのパブリックサブネットと 2 つのプライベートサブネットがあります。コントロールプレーンとハイブリッドノード間の通信は、VPC を経由してトランジットゲートウェイまたは仮想プライベートゲートウェイの出入り口を通過し、プライベートなネットワーク接続経由でルーティングされます。EKS Hybrid Nodes は、オンプレミス環境と AWS リージョン 間の 信頼できるネットワーク接続 を必要とします。これは、 AWS Site-to-Site VPN 、 AWS Direct Connect 、またはユーザー管理の VPN ソリューションを使用して確立できます。 ルーティングテーブル、セキュリティグループ、ファイアウォールルールを設定して、各環境間の双方向通信を可能にする必要があります。 前提条件 このソリューションを完了するために必要な前提条件は以下のとおりです。 インターネットへのルートを持つ 2 つのプライベートサブネットと 2 つのパブリックサブネットを備えた Amazon VPC オンプレミスネットワークと Amazon VPC 間の AWS Site-to-Site VPN オンプレミスノードの場合、VPC CIDR レンジや Kubernetes Service の IPv4 CIDR と重複しない IPv4 RFC-1918 に準拠した CIDR ブロック Amazon EKS ユーザーガイド に詳細が記載されている、ファイアウォールルール、ルーティングテーブル、セキュリティグループといった Hybrid Nodes のネットワーキング要件 マシンイメージに含まれる NVIDIA ドライバー と NVIDIA Container Toolkit と EKS Hybrid Nodes に対応するオペレーティングシステム を実行するオンプレミスのマシン NIM へのアクセスに必要な NVIDIA NGC アカウントとAPI キー (NVIDIA の ドキュメント を参照してください) 以下のツール Helm 3.9+ kubectl eksctl v0.205.0+ AWS Command Line Interface (AWS CLI ) ウォークスルー 次のステップでは、このソリューションの概要を説明します。 EKS Hybrid Nodes と EKS Auto Mode を有効化したEKS クラスターの作成 Amazon EKS クラスターの作成および管理のための CLI ツールである eksctl を使用して、EKS Hybrid Nodes と EKS Auto Mode が有効化された EKS クラスターを作成します。 ClusterConfig ファイルとして cluster-configuration.yaml を作成します。このファイルには EKS Auto Mode を有効にする autoModeConfig と EKS Hybrid Nodes を有効にする remoteNetworkConfig が含まれています。有効な remoteNetworkConfig の値については、 EKS Hybrid Nodes のドキュメント を参照してください。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: hybrid-eks-cluster region: us-west-2 version: "KUBERNETES_VERSION" # Disable default networking add-ons as EKS Auto Mode # comes integrated VPC CNI, kube-proxy, and CoreDNS addonsConfig: disableDefaultAddons: true vpc: subnets: public: public-one: { id: "PUBLIC_SUBNET_ID_1" } public-two: { id: "PUBLIC_SUBNET_ID_2" } private: private-one: { id: "PRIVATE_SUBNET_ID_1" } private-two: { id: "PRIVATE_SUBNET_ID_2" } controlPlaneSubnetIDs: [ "PRIVATE_SUBNET_ID_1" , "PRIVATE_SUBNET_ID_2" ] controlPlaneSecurityGroupIDs: [ "ADDITIONAL_CONTROL_PLANE_SECURITY_GROUP_ID" ] autoModeConfig: enabled: true nodePools: [ "system" ] remoteNetworkConfig: # Either ssm or ira iam: provider: ssm # Required remoteNodeNetworks: - cidrs: [ "172.18.0.0/16" ] # Optional remotePodNetworks: - cidrs: [ "172.17.0.0/16" ] Bash ClusterConfig ファイルを作成した後、以下のコマンドを実行して EKS クラスターを作成します。 eksctl create cluster -f cluster-configuration.yaml Bash クラスターの状態が Active になるのを待ちます。 aws eks describe-cluster \ --name hybrid-eks-cluster \ --output json \ --query 'cluster.status' Bash ハイブリッドノードの準備 EKS Hybrid Nodes は kube-proxy と CoreDNS を必要とします。以下の eksctl コマンドを実行してアドオンをインストールしてください。ハイブリッドノードには自動的に 「eks.amazonaws.com/compute-type: hybrid」というラベルが付与されます。このラベルを使用してハイブリッドノード向け、あるいは別のノードをワークロードのデプロイ対象にすることができます。EKS Hybrid Nodes で Amazon EKS アドオンをデプロイする方法の詳細は「 ハイブリッドノードのアドオンを構成する 」をご覧ください。 aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name kube-proxy aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name coredns Bash AWS クラウドで少なくとも 1 つの CoreDNS レプリカを実行する場合は、CoreDNS が実行されている VPC およびノードへの DNS トラフィックを許可する必要があります。さらには、オンプレミスのリモート Pod CIDR へは、Amazon VPC のノードからルーティング可能でなければなりません。mixed モードの EKS クラスターの実行に関するガイダンスについては、 EKS Hybrid Nodes ユーザーガイド を参照してください。 オンプレミスのノードを Amazon EKS コントロールプレーンに EKS ハイブリッドノードとして登録できます。そのためには、 nodeadm という EKS Hybrid Nodes CLI をインストールします。nodeadm によって、マシンを EKS ワーカーノードに変換するために必要なコンポーネントをインストールできます。これらのコンポーネントには kubelet、containerd、 aws-iam-authenticator が含まれます。マシンに nodeadm をインストールしてノードをクラスタに接続するには、EKS Hybrid Nodes のドキュメント「 ハイブリッドノードを接続する 」にある手順に従ってください。 ハイブリッドノードでワークロードを実行する前に、互換性のある Container Network Interface (CNI)ドライバーをインストールしてください。EKS ハイブリッドノードで CNI を設定する手順は「 ハイブリッドノードの CNI を設定する 」を参照してください。 ノード登録時に、ハイブリッドノードが属するゾーンを指定するために、たとえば topology.kubernetes.io/zone のようなノードのラベルや Taints を追加するように kubelet の設定を変更できます。ワークロードのスケジューリングのために、接続されている GPU のさまざまな機能を表すラベルを追加することもできます。 GPU と非 GPU のキャパシティが混在する場合、GPU ノードに --register-with-taints=nvidia.com/gpu=Exists:NoSchedule という Taints を追加することをお勧めします。これにより、GPU ノード上に非 GPU ワークロード (CoreDNS など) がスケジュールされなくなります。 nodeadm を使用する場合の kubelet 構成の変更方法については、EKS Hybrid Nodes の ドキュメント をご確認ください。 以下の kubectl コマンドを実行して、ノードが接続され Ready 状態にあることを検証してください。 ハイブリッドノードが Ready になるには、CNI をインストールする必要があります。 ❯ kubectl get nodes -o wide -l eks.amazonaws.com/compute-type = hybrid NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-1111111111111111 Ready &lt; none &gt; 5d v1.xx.x. 10.80 .146.76 &lt; none &gt; Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 mi-2222222222222222 Ready &lt; none &gt; 5d v1.xx.x. 10.80 .146.28 &lt; none &gt; Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 Bash Kubernetes 用 NVIDIA デバイスプラグインのインストール 本セクションでは、オンプレミスの EKS ハイブリッドノードに必要な NVIDIA ドライバーと NVIDIA Container Toolkit が設定されていることを前提としています。 Kubernetes デバイスプラグイン を使用すると、GPU などのシステムハードウェアを kubelet に通信できます。このウォークスルーでは NVIDIA GPU を使用するため、Kubernetes スケジューラーが GPU デバイスを公開できるように、NVIDIA デバイスプラグインをインストールする必要があります。NVIDIA ドライバと NVIDIA Container Toolkit がマシンイメージに含まれておらず、containerd が NVIDIA Container ランタイムを使用できるように設定されていない場合は、代わりに NVIDIA GPU Operator をデプロイできます。この Operator は、NVIDIA デバイスプラグインとともに、これらのコンポーネントを実行時にインストールします。 kubectl を使用して NVIDIAデバイスプラグインをインストールするには、まずデプロイメントマニフェストをダウンロードします。 https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.1/deployments/static/nvidia-device-plugin.yml Bash 最新バージョンについては、NVIDIA デバイスプラグインの GitHub リポジトリ を確認してください。 EKS Auto Mode では、NVIDIA デバイスプラグインをインストールする必要はありません。デバイスプラグインの DaemonSet は、GPU を搭載したハイブリッドノードでのみ実行する必要があります。ラベル eks.amazonaws.com/compute-type: hybrid を使用して、 .spec.template.spec.nodeSelector の一部として NVIDIA デバイスプラグインをハイブリッドノードを対象に更新するとともに、GPU ワーカーノードと非 GPU ワーカーノードの混在している場合は、必要に応じて追加のラベルを追加してください。 nodeSelector: eks.amazonaws.com/compute-type: hybrid Bash マニフェストを適用して NVIDIA デバイスプラグインをインストールします。 kubectl apply -f nvidia-device-plugin.yml Bash 以下のコマンドを使用して、NVIDIA デバイスプラグインの Pod が実行されていることを確認します。 kubectl get pods -n kube-system Bash NVIDIA デバイスプラグインの確認のため kube-system 内の Pod を一覧表示したとき、以下の出力が期待されます。DaemonSet は GPU を搭載したノード上でのみスケジュールされる必要があります。 NAMESPACE NAME READY STATUS kube-system nvidia-device-plugin-daemonset-mb8hw 1 /1 Running kube-system nvidia-device-plugin-daemonset-vtz8h 1 /1 Running Bash GPU ステータスが 割り当て可能なノード に表示されているかどうか検証することで、GPU が kubelet に公開されているかどうかを確認できます。 kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu" -l eks.amazonaws.com/compute-type = hybrid Bash GPU が接続されたノードをリスト表示した場合に予想される割り当て可能なノードの出力以下に示します。 NAME GPU mi-11111111111111111 1 mi-22222222222222222 1 Bash EKS Hybrid Nodes 上での推論のために NVIDIA NIM をデプロイ NVIDIA NIM をデプロイする前に、 前提条件 としてコンテナレジストリと NVIDIA API キーを設定する必要があります。 NGC_API_KEY をご自身の API キーに置き換えてください。 kubectl create secret docker-registry nvcrio-cred --docker-server = nvcr.io --docker-username = '$oauthtoken' --docker-password = $NGC_API_KEY kubectl create secret generic ngc-api --from-literal = NGC_API_KEY = $NGC_API_KEY Bash 以下のコマンドを実行して NIM Helm チャートをクローンします。 git clone https://github.com/NVIDIA/nim-deploy.git cd nim-deploy/helm Bash Helm チャートのオーバーライドを作成します。nodeSelector でハイブリッドノードにデプロイするように設定します。 cat &gt; nim.values.yaml &lt;&lt; EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: hybrid resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" EOF Bash values.yaml ファイルのイメージリポジトリを変更することで、異なるモデルをデプロイできます。 helm install nim nim-llm/ -f ./nim.values.yaml Bash このデプロイではモデルキャッシュは使用されていません。スケーリングイベント中のアプリケーションの初期化を高速化するために、モデルキャッシュの使用を検討することをおすすめします。モデルキャッシュを実装するには、適切な CSI ドライバーの構成とストレージインフラストラクチャが必要になります。 サンプルプロンプトを使用したNIM のテスト NIM マイクロサービスをテストするには、NIM の Sercice への Kubernetes ポートフォワーディングを構成します。 kubectl port-forward service/nim-nim-llm 8000 :8000 Bash 以下の curl コマンドを実行し、出力を確認してください。 curl -X 'POST' \ "http://localhost:8000/v1/completions" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "model": "mistralai/mistral-7b-instruct-v0.3", "prompt": "What is a Kubernetes Pod", "max_tokens": 30 }' Bash 期待される応答は以下です。 { "id" : "cmpl-b50fb31c13e4420bac5243047ef5e404" , "object" : "text_completion" , "created" : 1741976435 , "model" : "mistralai/mistral-7b-instruct-v0.3" , "choices" : [ { "index" : 0 , "text" : "? \n \n A Kubernetes Pod is the smallest unit of computation in the Kubernetes API object model that represents a portion of a running application. Each" , "logprobs" : null, "finish_reason" : "length" , "stop_reason" : null, "prompt_logprobs" : null } ] , "usage" : { "prompt_tokens" : 7 , "total_tokens" : 37 , "completion_tokens" : 30 } } Bash EKS Hybrid Nodes へのモデルのデプロイが成功しました。 次に、同じ EKS クラスターで実行されている EKS Auto Mode のノードでモデルをデプロイします。 EKS Auto Mode へのデプロイ EKS ハイブリッドノードで実行する必要のないワークロードをデプロイできます。EKS Auto Mode の 組み込み NodePool には GPU ベースのインスタンスが設定されていないため、GPU を持つ NodePool を定義する必要があります。EKS Auto Mode は、NVIDIA GPU と Neuron デバイスとの 統合 を提供するので、ドライバやデバイスプラグインをインストールする必要がありません。 次のコマンドを実行して、 g6 インスタンスファミリーを使用した NodePool を作成します。 cat &gt; nodepool-gpu.yaml &lt;&lt; EOF apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6 taints: - key: nvidia.com/gpu effect: NoSchedule terminationGracePeriod: 24h0m0s EOF kubectl apply -f nodepool-gpu.yaml Bash ワークロードに特定のネットワーク帯域幅やインスタンス GPU 要件がある場合は、 EKS Auto Mode でサポートされている他の Well-Known ラベル を設定することを検討してください。 以下のファイルを作成することで、EKS Auto Mode へのデプロイ用に NVIDIA NIM の値を更新します。 cat &gt; nim.values.yaml &lt;&lt; EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: auto resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists EOF Bash 以下のコマンドを実行して、NIM Helm リリースを新しいバージョンにアップグレードします。 helm upgrade nim nim-llm/ -f ./nim.values.yaml Bash NodeClaims をリスト表示して、EKS Auto Mode が NVIDIA NIM を提供するために g6.xlarge をそのリージョンに起動したことを確認します。 &gt; kubectl get nodeclaims NAME TYPE CAPACITY ZONE NODE READY gpu-wq9qr g6.xlarge on-demand us-west-2b i-33333333333333333 True Bash テストするには、前のステップを繰り返し、サンプルのプロンプトで NIM をテストします。 クリーンアップ 本記事で作成したすべての AWS リソースをクリーンアップして長期的なコストを発生させないようにするには、以下のコマンドを実行してください。 helm delete nim kubectl delete -f nodepool-gpu.yaml kubectl delete -f nvidia-device-plugin.yml eksctl delete cluster -f cluster-configuration.yaml Bash 前提条件の一部として作成したその他のリソースが不要になった場合は、それらについてもクリーンアップしてください。 結論 本記事では、Amazon EKS Hybrid Nodes が AI ワークロードを実行する方法の例を紹介しました。Amazon EKS Hybrid Nodes は Kubernetes フットプリントを Amazon EKS に統合し、Kubernetes コントロールプレーンの管理の必要性をなくし、運用オーバーヘッドを削減します。 EKS Hybrid Nodes の詳細と使用方法については、 EKS Hybrid Nodes ユーザーガイド を参照してください。また、ハイブリッドノードの仕組み、機能、ベストプラクティスについて説明している re:Invent 2024 のセッション (KUB205) もご覧ください。Amazon EKS での AI/ML ワークロードの実行に関するその他のガイダンスは、 Data on EKS プロジェクト も参考にできます。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

3 月 31 日、すべての商用リージョンと AWS GovCloud (米国) リージョンのすべてのエンドポイントタイプ、カスタムドメイン、管理 API で、 Amazon API Gateway の IPv6 サポートを開始しました。REST、HTTP、WebSocket API、カスタムドメインを設定して、既存の IPv4 サポートに加えて IPv6 クライアントからの呼び出しを受け入れることができるようになりました。デュアルスタック (IPv6 と IPv4) クライアントから API Gateway 管理 API を呼び出すこともできます。世界中の組織が IPv4 アドレスの不足とコスト増加に直面する中、IPv6 の実装は、将来を見据えたネットワークインフラストラクチャの構築において必要不可欠になっています。このデュアルスタックのアプローチは、組織が将来的なネットワーク互換性を維持し、グローバルなリーチを拡大するのに役立ちます。 Amazon Web Services (AWS) 環境のデュアルスタックの詳細については、 IPv6 on AWS のドキュメントをご覧ください。 新しいデュアルスタックリソースの作成 この投稿では、デュアルスタック IP アドレスタイプを使用して API またはドメイン名を作成する方法として、 AWS マネジメントコンソール と AWS Cloud Development Kit (CDK) という 2 つの方法に焦点を当てています。 AWS コンソール コンソールで新しい API またはドメイン名を作成する場合、IP アドレスタイプとして [IPv4 のみ] または [デュアルスタック (IPv4 と IPv6)] を選択します。 次の図に示すように、新しい REST API を作成するときにデュアルスタックオプションを選択できます。 カスタムドメイン名についても、次の図に示すように、同様にデュアルスタックを設定できます。 何らかの理由で IPv4 のみに戻す必要がある場合は、IP アドレスタイプ設定を変更できます。更新を有効にするために API を再デプロイする必要はありません。 すべてのエンドポイントタイプ (EDGE、REGIONAL、PRIVATE) の REST API がデュアルスタックをサポートします。プライベート REST API はデュアルスタック設定のみをサポートします。 AWS CDK AWS CDK では、まずデュアルスタック REST API とドメイン名を設定します。 const api = new apigateway.RestApi(this, "Api", { restApiName: "MyDualStackAPI", endpointConfiguration: {ipAddressType: "dualstack"} }); const domain_name = new apigateway.DomainName(this, "DomainName", { regionalCertificateArn: 'arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab', domainName: 'dualstack.example.com', endpointConfiguration: { types: ['Regional'], ipAddressType: 'dualstack' }, securityPolicy: 'TLS_1_2' }); const basepathmapping = new apigateway.BasePathMapping(this, "BasePathMapping", { domainName: domain_name, restApi: api }); IPv6 ソース IP と認可 API が IPv6 トラフィックの受信を開始すると、クライアントソース IP は IPv6 形式になります。ソース IP アドレスを参照するリソースポリシー、Lambda オーソライザー、または AWS Identity and Access Management (IAM) ポリシーを使用する場合は、それらが IPv6 アドレス形式に対応するように更新されていることを確認してください。 例えば、リソースポリシーの特定の IPv6 範囲からのトラフィックを許可する場合などです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "execute-api:stage-name/*", "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "2001:db8:1234::/48" ] } } } ] } まとめ API Gateway のデュアルスタックサポートは、IPv4 アドレスの不足とコストの管理、政府や業界の指示への準拠、ネットワークの将来への準備に役立ちます。デュアルスタックの実装は、IPv4 クライアントと IPv6 クライアントの両方を同時にサポートすることにより、スムーズな移行パスを提供します。 API Gateway のデュアルスタックのサポートを開始するには、 Amazon API Gateway のドキュメントをご覧ください。新しい API 用にデュアルスタックを設定したり、最小限の設定変更で既存の API を更新したりできます。 – Betty 執筆プロセス中にリソースを提供し、質問に答え、貴重なフィードバックを提供してくれた Ellie Frank (elliesf)、Anjali Gola (anjaligl)、Pranika Kakkar (pranika) に特に感謝します。このブログ記事は、Service チームと Product Management チームの共同サポートによって実現しました。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

AWS Summit のシーズンがやってきました! 現在、無料のイベントが世界中で開催されており、AWS のクラウドコンピューティングコミュニティが一堂に会してつながり、コラボレートし、学んでいます。オンライン参加か現地参加かにかかわらず、これらの会合は AWS の知識を深める貴重な機会を提供します。私は AWS Amsterdam Summit に参加するので、ぜひ皆さんにお会いしたいと思っています。参加される予定の場合は、声をかけに来てください! 今すぐ AWS Summit ウェブサイト にアクセスしてお住まいの地域のイベントを検索し、登録アラートにサインアップして、お近くの AWS Summit への参加を予約しましょう。 AWS のニュースと言えば、先週も新しい発表がありました。ではそれらを見ていきましょう。 3 月 24 日週のリリース 私が注目したリリースはこちらです。 AWS Amplify ホスティングとの AWS WAF 統合の一般提供開始 – Amplify コンソールでのワンクリック統合、または Infrastructure as Code (IaC) を使用して、 AWS Amplify アプリケーションに AWS WAF を直接アタッチできるようになりました。この統合は、SQL インジェクションやクロスサイトスクリプティング (XSS) といった一般的なウェブエクスプロイトを防ぐマネージドルールなど、AWS WAF のすべての機能へのアクセスを提供します。アプリケーションのニーズに基づいたカスタムルールを作成する、IP アドレスからのリクエストレートを制限することで分散型サービス拒否 (DDoS) 攻撃を防ぐレートベースのルールを実装する、そして特定の国からのアクセスを制限するためのジオブロッキングを設定することも可能です。ファイアウォールサポートは、Amplify ホスティングが稼働しているすべての AWS リージョン でご利用いただけます。 Amazon Bedrock のカスタムモデルインポートがリアルタイムのコスト透明性を導入 – Amazon Bedrock のカスタムモデルインポート を使用してカスタマイズされた 基盤モデル (FM) を実行している場合は、コンピューティングリソースに対する完全な透明性を実現し、推論コストをリアルタイムで計算できるようになります。モデルを呼び出す前に、 Amazon Bedrock コンソールと Amazon Bedrock API の両方を使用して、必要最小限のコンピューティングリソース (カスタムモデルユニット、つまり CMU) を確認できます。トラフィックの増加に対処するためにモデルがスケールするときは、使用された CMU の合計数を Amazon CloudWatch メトリクスでリアルタイムに把握できるため、ほぼ瞬時の可視化によるコストコントロールの改善が可能になります。これは、モデル構成をその場で変更してコストを最適化するために役立ちます。この機能は、Amazon Bedrock のカスタムモデルインポートがサポートされているすべてのリージョンでご利用いただけます。詳細については、Amazon Bedrock ユーザーガイドの「 Calculate the cost of running a custom model 」を参照してください。 Amazon Bedrock ナレッジベースがベクトルストレージ用の Amazon OpenSearch マネージドクラスターのサポートを開始 – Amazon Bedrock ナレッジベース は、 検索拡張生成 (RAG) 用の企業データソースに FM をセキュアに接続することで、関連性と正確性の高い応答を提供します。今回のリリースにより、Amazon Bedrock ナレッジベースの全機能を使用しながら、 Amazon OpenSearch マネージドクラスター をベクトルデータベースとして使用できるようになります。この統合により、既に Amazon OpenSearch Serverless 、 Amazon Aurora 、 Amazon Neptune Analytics 、Pinecone、MongoDB Atlas、および Redis が含まれるサポート対象ベクトルデータベースのリストがさらに拡大されます。ベクトルデータベースとのネイティブな統合は、カスタムデータソース統合を構築する必要性の軽減に役立ちます。この機能は、Amazon Bedrock ナレッジベースと OpenSearch サービスのすべての既存リージョンで一般提供されます。 Amazon Bedrock ガードレールが業界トップクラスの画像コンテンツフィルターの一般提供を発表 – この新機能は、業界トップクラスのテキストおよび画像コンテンツセーフガードを提供する機能で、カスタムセーフガードを構築したり、エラーが発生しやすい手動によるコンテンツ管理に頼ったりすることなく、有害なマルチモーダルコンテンツを最大 88% ブロックするために役立ちます。画像コンテンツフィルターは、コンテンツフィルターポリシー内のすべてのカテゴリー (憎悪、侮辱、性的、暴力、不正行為、プロンプト攻撃など) 全体に適用できます。 Amazon Bedrock ガードレール は、有害なコンテンツやプロンプト攻撃の検出とブロック、特定のトピックを拒否して禁止するためのトピックの定義、個人データなどの個人を特定できる情報 (PII) の削除、特定の単語のブロックを実行するための設定可能なセーフガードを提供します。また、自動推論チェックを使用することで、モデルハルシネーションを検出してブロックし、モデルの応答や主張の関連性を特定して、モデルの応答に含まれる事実に基づく主張を識別、修正、説明するためのコンテキストグラウンディングチェックも提供します。この機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、およびアジアパシフィック (東京) の各リージョンで一般提供されます。詳細については、AWS 機械学習ブログの「 Amazon Bedrock Guardrails image content filters provide industry-leading safeguards 」、および Amazon Bedrock ユーザーガイドの「 Stop harmful content in models using Amazon Bedrock Guardrails 」を参照してください。 Amazon Q in QuickSight のシナリオ機能の一般提供開始 – 隠れた傾向を明らかにすることでデータ分析をガイドするこの機能は、自然言語でのやり取りを通じてビジネスに関する推奨事項を提供し、より詳しく調査するための次のステップをインテリジェントに提案します。この機能を使用することで、専門的なスキルやアナリストのサポート、またはスプレッドシート内のデータの手動での操作を必要とすることなく、過去の傾向の調査、将来のシナリオの予測、ソリューションのモデル化を実行できるようになります。直感的なインターフェイスとステップバイステップのガイダンスを提供する Amazon Q in QuickSight のシナリオ機能は、複雑なデータ分析をスプレッドシートよりも最大 10 倍速く実行できるようにします。行っているのがマーケティング予算の最適化、サプライチェーンの合理化、または投資の分析であるかにかかわらず、Amazon Q は高度なデータ分析を実行しやすくすることで、組織全体でのデータ主導の意思決定を可能にします。この機能はどの Amazon QuickSight ダッシュボードからでもアクセスできるため、データの視覚化から what-if 質問や代替案の比較へとシームレスに移行できます。以前に行った分析の変更、拡張、再利用も簡単に実行できるため、変化するビジネスニーズへの迅速な適応に役立ちます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 アジアパシフィック (ムンバイ) および欧州 (パリ) AWS リージョンで Amazon DataZone の提供を開始 – Amazon DataZone は、組織内のデータプロデューサーとコンシューマー間でデータをカタログ化、検出、分析、共有、制御するための、完全マネージド型のデータ管理サービスです。 アジアパシフィック (ムンバイ) および欧州 (パリ) AWS リージョンで次世代 Amazon SageMaker の提供を開始 – Amazon SageMaker は、あらゆるデータ、分析、AI のための拠点です。SageMaker Unified Studio は、AWS の分析ツールと AI/ML ツールを統合する単一の開発環境を提供します。 メキシコ (中部) およびアジアパシフィック (タイ) AWS リージョンで Amazon Redshift Query Editor V2 の提供を開始 – Amazon Redshift Query Editor V2 は、データアナリスト、データサイエンティスト、データベース開発者などの SQL ユーザー向けのウェブベースのツールを使用して、 Amazon Redshift データウェアハウスとデータレイク内のデータへのアクセス性を向上させます。 Amazon Keyspaces がすべての AWS リージョンをサポートするためにマルチリージョンレプリケーションを拡張 – Amazon Keyspaces (Apache Cassandra 向け) は拡張性と可用性に優れたマネージド型の Cassandra 互換データベースで、既存のアプリケーションコードと開発者ツールを使用した AWS での Cassandra ワークロードの実行に役立ちます。 アジアパシフィック (タイ) およびメキシコ (中部) AWS リージョンで AWS Network Firewall の提供を開始 – AWS Network Firewall は、トラフィックに合わせて自動的にスケールするマネージド型ファイアウォールサービスで、インフラストラクチャのメンテナンスを一切必要とせず、複数の AWS アカウント全体での一元化されたポリシーコントロールのために AWS Firewall Manager と統合します。 イスラエル (テルアビブ) およびアジアパシフィック (香港) AWS リージョンで Amazon CloudWatch RUM の一般提供を開始 – CloudWatch RUM は、クライアント側のパフォーマンスデータをリアルタイムで収集し、エンドユーザーエクスペリエンスメトリクス (異なるジオロケーション、ブラウザ、デバイス全体でのページ読み込み異常、コアウェブバイタル、エラーなど) を表示するダッシュボードを提供することで、ウェブアプリケーションを監視します。 アジアパシフィック (タイ) およびメキシコ (中部) AWS リージョンで Amazon VPC IP Address Manager の提供を開始 – AWS ワークロードの IP アドレスを簡単に計画、追跡、監視できるようにする Amazon Virtual Private Cloud (Amazon VPC) IP Address Manager (Amazon VPC IPAM) は、ルーティングとセキュリティのニーズに基づいたアドレスの分類や、IP アドレスの割り当てを規定するシンプルなビジネスルールの設定に役立ちます。 アジアパシフィック (シドニー) AWS リージョンで Amazon Q Business の提供を開始 – Amazon Q Business は、情報を探し出し、インサイトを獲得して、職場でアクションの実行するための、最も高度な能力を備えた生成 AI 駆動のアシスタントで、エンタープライズシステム内のデータと情報に基づいて質問に答え、要約を提供し、コンテンツを生成して、タスクをセキュアに完了することができます。 米国東部 (バージニア北部) とアジアパシフィック (ジャカルタ) AWS リージョンで Amazon EC2 P5en インスタンスの提供を開始 – P5en インスタンスには、メモリサイズが 1.7 倍の H200 GPU が 8 個搭載されており、第 4 世代 Intel Xeon プロセッサと Gen5 PCIe との組み合わせで 4 倍の CPU-GPU 帯域幅を実現します。これは、深層学習、生成 AI、リアルタイムのデータ処理、ハイパフォーマンスコンピューティング (HPC) などの用途における分散型トレーニングワークロードの集団通信パフォーマンスの向上に役立ちます。 米国西部 (北カリフォルニア) AWS リージョンで Amazon EC2 R8g インスタンスの提供を開始 – より大きなインスタンスサイズを提供するこれらのインスタンスは、AWS Graviton3 ベースの R7g インスタンスよりも最大 3 倍多い vCPU (最大 48xlarge) とメモリ (最大 1.5 TB) を備えています。Graviton3 ベースの R7g インスタンスと比較した場合、これらのインスタンスはウェブアプリケーションで最大 30%、データベースで最大 40%、大規模な Java アプリケーションで最大 45% 高速になります。 アジアパシフィック (東京) AWS リージョンで Amazon EC2 C8g インスタンスの提供を開始 – これらのインスタンスは、Graviton3 ベースの Amazon C7g インスタンスよりも最大 3 倍多い vCPU とメモリを使用する、より大きなインスタンスサイズを提供します。AWS Graviton3 プロセッサと比較した場合、AWS Graviton4 プロセッサは、データベースで最大 40%、ウェブアプリケーションで最大 30%、大規模な Java アプリケーションで最大 45% 高速になります。 メキシコ (中部) および アジアパシフィック (タイ) AWS リージョンで Amazon SageMaker AI の提供を開始 – Amazon SageMaker AI は、より迅速に機械学習 (ML) モデルを構築、トレーニング、デプロイする能力をすべての開発者とデータサイエンティストに提供する、完全マネージド型のプラットフォームです。 Amazon ElastiCache がアジアパシフィック (ジャカルタ) およびアジアパシフィック (ハイデラバード) AWS リージョンで AWS PrivateLink のサポートを開始 – AWS PrivateLink は、トラフィックをパブリックインターネットに公開したり、ネットワークトラフィックをセキュア化したりすることなく、VPC、AWS サービス、およびオンプレミスネットワーク間のプライベート接続を提供します。 Amazon ElastiCache で AWS PrivateLink を使用するには、 Amazon VPC コンソール 、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して、VPC 内にある Amazon ElastiCache 用の インターフェイス VPC エンドポイント を作成します。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts &nbsp;は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。&nbsp; お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日中に開催されるすべての AWS 主催の対面およびバーチャルイベント は、こちらで閲覧できます。 3 月 31 日週のニュースは以上です。4 月 7 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

(本記事は 2024/11/03に投稿された Pre-warming Amazon DynamoDB tables with warm throughput を翻訳した記事です。翻訳は SA の嶋田朱里が担当しました。) Amazon DynamoDB は需要に応じて自動的にスケーリングできることで有名な NoSQL データベースです。しかし、ユースケースによっては、テーブルを作成した瞬間から大量のトラフィックを処理する必要がある、または今後のイベントに備えて突発的なトラフィックの増加に対応する必要がある場合があります。このような場合に対応するために、新機能として ウォームスループット が導入されました。この機能により、DynamoDB テーブルとインデックスが即座にサポート可能なスループットを把握し、パフォーマンスを最適化するための事前ウォーミングを行うことが可能になります。 この記事では、ウォームスループットについて、その仕組みを説明し、高トラフィックシナリオを処理する際のメリットを紹介します。また、この機能を DynamoDB テーブルとインデックスで最大限活用するためのベストプラクティスと実践的なユースケースについても説明します。 DynamoDB のキャパシティモード ウォームスループットについて説明する前に、 DynamoDB のキャパシティモードとスループットについて復習しましょう。 プロビジョンドキャパシティモードでは、予測可能なワークロードに対して、特定のスループットを設定できます。一方、オンデマンドモードは需要に合わせて自動的にスケーリングするため、予測不可能なワークロードに適しています。スループットは、Read Capacity Unit (RCU) と Write Capacity Unit (WCU) で測定されます。RCU は 1 秒あたり 4 KB の読み取りを、WCU は 1 秒あたり 1 KB の書き込みを可能にします。 詳細については、開発者ガイドの DynamoDB スループットキャパシティ を参照してください。 ウォームスループットとは ウォームスループットは、テーブルまたはインデックスがすぐにサポートできる読み取りおよび書き込み操作について、インサイトを提供します。これらの値は使用量が増加するにつれて大きくなります。また、より高いウォームスループット値を積極的に設定することで、テーブルまたはインデックスをあらかじめ事前ウォーミングすることもできます。この方法は、商品の発売、フラッシュセール、大規模なオンラインイベントなど、瞬間的なトラフィックの急増が予想されるシナリオで特に有益です。次のビデオでは、ウォームスループットを使用して、テーブルとインデックスをあらかじめ事前ウォーミングしておくことで、商品の発売やフラッシュセールなどの重要なイベント中に生じる、大量のトラフィックの急増を効果的に処理し、レイテンシーの削減とアプリケーションの応答性向上を実現する方法を紹介しています。 ウォームスループットの理解 ウォームスループット値は、DynamoDB テーブルのスループットキャパシティの最大値を示すものではありません。むしろ、テーブルが即座に処理できる最小スループットを表しています。テーブルをあらかじめ事前ウォーミングすることで、テーブルが即座にサポートできる読み取りと書き込みの数を設定し、特定レベルのトラフィックに処理開始時から対応できるようにします。 テーブルの事前ウォーミングは非同期で行われ、他の操作を妨げることはありません。そのため、事前ウォーミング処理と同時に、他のテーブルへの更新を実行することができます。この柔軟性により、アクティブな事前ウォーミング操作中でも、更新された値を含む新しいリクエストを送信することで、いつでも簡単にウォームスループット値を調整できます。事前ウォーミング処理の完了に要する時間は、要求されたウォームスループット値とテーブルまたはインデックスのストレージサイズによって異なります。 DynamoDB のスケーリング機能は最初の事前ウォーミングだけでなく、アプリケーションの成長に合わせて動的に調整されます。時間の経過とともにワークロードが増加すると、DynamoDB は自動的にウォームスループット値を高めて、より多くのトラフィックに対応できるようになり、手動の介入なしに一貫したパフォーマンスを確保できるようになります。 例えば 1 秒あたり 10 万件の書き込みリクエストに対応するようにテーブルを事前ウォーミングした場合、そのテーブルはすぐにそのトラフィックを処理できるようになります。例えばアプリケーションのトラフィックが増加し、1 秒あたり 15 万件の書き込みリクエストに達した場合、DynamoDB はこの追加の負荷に対応するために自動的にスケーリングを行います。アプリケーションの成長ニーズに応じて、シームレスにテーブルを対応できるようにします。ウォームスループット値はテーブルの現在のキャパシティとパフォーマンス能力を正確に反映するように調整されます。 ウォームスループット値を追跡し、時間の経過とともにどのように変化するかを確認するには、 DescribeTable API を使用します。この API は、テーブルとグローバルセカンダリインデックスの両方について、現在のウォームスループット値に関する詳細情報を提供します。そのため、トラフィックパターンと将来の要件に基づいた積極的な調整に役立てることができます。 事前ウォーミングの一般的なユースケース DynamoDB テーブルの事前ウォーミングが必要かどうかを判断する前に、アプリケーションが必要とするピークスループットを理解することが重要です。ピークスループットを見積もることで、予想される負荷を DynamoDB テーブルで処理できるように準備することができ、スロットリングやパフォーマンスの問題を回避できます。以下はアプリケーションのピークスループットを計算し、事前ウォーミングが必要かどうかを判断するためのガイドです。これらのステップはオンデマンドキャパシティモードとプロビジョンドキャパシティモードのどちらのテーブルにも適用されます。 Step1：ワークロードパターンの理解 ピークスループットを計算する最初のステップは、ワークロードのトラフィックパターンを明確に理解することです。以下を考慮してください: 操作の種類 : 主に読み取りリクエストと書き込みリクエストのどちらを処理しますか、それとも両方のリクエストを処理しますか？ トラフィックの性質 : 予測可能なピーク時間帯 (例えば、日次や週次のパターン) はありますか、それとも不定期な急増 (例えば、フラッシュセール、商品の発売、主要なイベントなど) がありますか？ Step2：秒間のピークリクエスト数の見積もり ワークロードを理解したら次のステップは、アプリケーションがピーク時に処理する必要がある 1 秒あたりの読み取りリクエストと書き込みリクエストの数を見積もることです。これには 2 つの方法があります。 過去のデータ : アプリケーションがすでに本番環境で稼働している場合は、トラフィックログやモニタリングデータを確認して、ピーク時の 1 秒あたりの最大読み取りリクエスト数と書き込みリクエスト数を特定します。これらの値をピークスループットの計算の基準として使用します。 予測 : 将来のイベントやリリースに備える場合は、想定されるトラフィックの増加を予想し、ピークスループットを見積もります。ユーザー数、ユーザーあたりの予想アクション数 (商品の閲覧回数や取引回数など)、ピーク時間の長さを考慮します。 Step3：読み取りと書き込みのキャパシティユニットの計算 リクエスト数の推定値を取得したら、DynamoDB テーブルに必要な読み取りリクエストユニット (RRU) と書き込みリクエストユニット (WRU) を計算できます。この例では、オンデマンドキャパシティモードの値を使用していますが、プロビジョンドキャパシティモードのテーブルでも同様のプロセスになります。 RRU : 強い整合性の読み取りの場合、 1つのアイテム (最大 4 KB) を読むために 1 RRU が消費されます。結果整合性の読み取りの場合、 1 つの RRU で 2 つの読み取りリクエスト (最大 4 KB) が可能です。RRU を計算するには: アイテムの平均サイズを KB で計算する アイテムの平均サイズを 4 で割る 1 秒あたりの読み取りリクエスト数を掛ける 結果整合性の読み取りか強い整合性の読み取りかに基づいて調整する 注: 小さいアイテムを扱う場合、強い整合性の読み取りリクエストでは 1 RRU、結果整合性の読み取りリクエストでは 0.5 RRU を消費する WRU : 1 つのアイテム (最大 1 KB) を書き込むために 1 つの WRU が消費されます。WRU を計算するには: アイテムの平均サイズを KB で計算する 1 秒あたりの書き込みリクエスト数を掛ける キャパシティユニットの詳細については、 開発者ガイド を参照してください。 Step4：変動性を考慮する 大抵の場合、トラフィックは一定ではないため、最初の見積もりを超えるトラフィックの急増に備えることも重要です。予期しないスパイクに対応できるよう、ピークスループットの計算にはバッファを追加することを検討してください。 例えばピーク時に 80,000 WRU/秒と見積もった場合、需要の急増に対応するために 100,000 WRU/秒で事前ウォーミングを行うことを検討してください。ただし、余裕を持って事前ウォーミングを行うと、追加コストが発生する可能性があります。 Step5：事前ウォーミングの必要性の判断 ピーク時の RRU と WRU を計算したら、これらの値をテーブルの現在のウォームスループット値と比較します。計算されたピークスループットが現在のウォームスループット値を大幅に上回る場合、または即時のトラフィックの急増 (商品の発売時やフラッシュセールなど) が予想される場合は、事前ウォーミングをお勧めします。これにより、テーブルがピークトラフィックに対応でき、パーティションの容量制限を超えた場合に発生する可能性のあるスロットリングを回避できます。システムが需要を満たすために対応する過程で、スロットリングやパーティション分割が発生すると、クライアントのレイテンシーが上昇することがあります。 ユースケース例 ウォームスループットの概念を紹介したので、次にこの機能が特に有益となる実際のユースケースを見ていきましょう。 高トラフィックに備えた新しいオンデマンドテーブルの準備 新しい DynamoDB オンデマンドテーブルは、初期のウォームスループットとして、毎秒 4,000 件の書き込みリクエストと 12,000 件の読み取りリクエストで開始します。新しいアプリケーションの起動時など、トラフィックが突然増加した場合、増加する需要を満たすために、DynamoDB は容量を徐々に拡張します。ただし、テーブルの書き込み要求が瞬時に 1 秒あたり 4,000 件を超えた場合、スケーリング処理中に一部のリクエストが スロットリング する可能性があります。このスロットリングにより、レイテンシーが増加したり、障害が発生したりして、ユーザー体験に影響が生じ、結果として収益が失われる可能性があります。 これらの問題を防ぐため、リリース時に高トラフィックが予想される場合は、テーブルを事前ウォーミングしておくことが推奨されます。事前ウォーミングにより、想定される負荷をテーブルが即座に処理できるようになり、スロットリングのリスクが低減します。DynamoDB のリアクティブなスケーリングするのを待つことなく、シームレスなユーザー体験を提供できます。 次のグラフは、新しいオンデマンドテーブルに対して実施された負荷テストを示しています。テーブルが予想以上のスループット(青線)に対応するためにスケールされるまで 、過剰なスロットリング(オレンジ線)が発生しました。 あらかじめ事前ウォーミングをすると、1 秒あたり 100,000 件の書き込みリクエストのベースラインを設定できます。DynamoDB はこのレベルのトラフィックを即座に処理できるようにテーブルをスケーリングするため、スケーリングの遅延がなくなり、スロットリングのリスクを軽減できます。 この事前準備により、ピーク時の需要でも顧客が迅速に取引を完了できるスムーズなユーザー体験を実現できます。リクエストの失敗、パフォーマンスの低下、スケーリングの遅延を心配する必要はなく、システムがイベントに備えられているという確信を得ることができます。 次のグラフは、前回と同じ負荷テストを実施したものですが、今回はテーブルを 100,000 WRU で事前ウォーミングしています。テーブルはすでにスケールアウトされ、スループットを処理する準備ができていたため、スロットリングは発生しませんでした。 大規模イベントへの準備 あなたは E コマース企業で、1 年の中で最もトラフィックが多いイベントの 1 つであるスーパーボウルの期間中に、フラッシュセールを準備しているとします。 すでに DynamoDB テーブルを用意しており、リクエストを処理できる状態にしていますが、予想されるトラフィックの急増を考えると、テーブルがその負荷に耐えられるかを確認することが重要です。推定に基づき、このイベントの最大トラフィックは 10% のバッファを含めて、100,000 件/秒の書き込みリクエストに達する可能性があると計算しました。 準備として、まず上記のように予想される負荷を計算し、現在のテーブルのウォームスループット値と比較します。推定されるピーク値が既存のウォームスループット値を上回る場合は、テーブルの事前ウォーミングが推奨されます。これにより、テーブルがトラフィックを即座に処理できるよう準備され、このような需要の高いイベント中にスロットリングや遅延が発生するリスクを軽減できます。 DynamoDB への移行の準備 既存のアプリケーションを DynamoDB に移行する際、移行開始時からテーブルが予想されるトラフィックに対応できるよう準備しておくことが、スムーズな移行のために重要です。従来のリレーショナルデータベースや他の NoSQL ソリューションから移行する場合、抽出、変換、ロード (ETL) ジョブが DynamoDB に書き込む際に、大量のデータとトラフィックの急増に対処する必要があります。 必要なキャパシティを DynamoDB テーブルにあらかじめ事前ウォーミングしておくことで、すぐに予想されるトラフィックを処理できるようになり、移行時に発生するかもしれない読み取りおよび書き込みリクエストの急増にもすぐに対応できるようになります。特にダウンタイムやパフォーマンス低下への余裕がほとんどない場合には、事前ウォーミングによって移行に伴う不確実性を排除できます。データを移行する際、DynamoDB は予想されるスループットのレベルまでスケーリングできるため、アプリケーションは高トラフィックを即座に処理することができます。 高トラフィックの E コマースプラットフォームや重要なエンタープライズワークロードを移行する場合でも、テーブルのウォームスループットの値を増やしておくことで、アプリケーションに必要なパフォーマンスのベースラインが保証され、ユーザがシステムとやり取りを開始する際の潜在的なスロットリングや遅延の問題を回避することができます。ウォームスループットのメリットとユースケースについて説明したので、続いて設定方法を説明します。 ウォームスループットの設定方法 AWS マネジメントコンソール、 AWS Command Line Interface (AWS CLI)、または Software Development Kit を利用することで、事前に大量のトラフィックに備えるための設定を行うことができます。 AWS マネジメントコンソールを使用した、ウォームスループット値の設定 DynamoDB コンソールに移動し、 Create table を選択します。 テーブルの主キー属性を指定します。 Table settings の下で、 Customize settings を選択します。 Read/write capacity settings で、 On-demand を選択します。 Warm Throughput に予想される最大の読み取りリクエスト数と書き込みリクエスト数を入力します。 テーブル作成を完了させます。 既存のテーブルまたはインデックスにウォームスループット値を適用する方法については、 開発者ガイド を参照してください。 AWS Command Line Interface (AWS CLI) を使用した、ウォームスループット値の設定 aws dynamodb create-table \ &nbsp;&nbsp;&nbsp; --table-name FlashSaleTable \ &nbsp;&nbsp;&nbsp; --attribute-definitions AttributeName=ProductID,AttributeType=S \ &nbsp;&nbsp;&nbsp; --key-schema AttributeName=ProductID,KeyType=HASH \ &nbsp;&nbsp;&nbsp; --billing-mode PAY_PER_REQUEST \ &nbsp;&nbsp;&nbsp; --warm-throughput ReadUnitsPerSecond=50000,WriteUnitsPerSecond=100000 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ... &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "WarmThroughput": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ReadUnitsPerSecond": 50000, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "WriteUnitsPerSecond": 100000, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Status": "UPDATING" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ... ベストプラクティス 事前ウォーミングのベストプラクティスは次のとおりです。 正確に見積もる : 過去のトラフィックパターンを分析したり、予測ツールを使用したりして、ピークスループットを正確に見積もります。 重要なテーブルに適用する : 注目度が高く、即時のトラフィックスパイクが予想されるイベントやアプリケーションをサポートするテーブルに焦点を当てます。 必要に応じて調整する : ワークロードの要件に対する理解を深めながら、テーブルの事前ウォーミングを調整します。 ウォームスループット値の監視 DynamoDB テーブルの現在の機能を理解し管理することは、大規模なイベントの前に特に重要です。DescribeTable API を使用すると、オンデマンドモードとプロビジョンドモードのすべてのテーブルで、ウォームスループットの値を監視できます。この呼び出しにより、現在のテーブルのウォームスループット値が提供されるため、大きなトラフィックイベントの前にすべてが適切に設定されているかを確認できます。 aws dynamodb describe-table --table-name FlashSaleTable &nbsp;&nbsp;&nbsp;&nbsp; ... &nbsp;&nbsp;&nbsp;&nbsp; "WarmThroughput": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ReadUnitsPerSecond": 50000, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "WriteUnitsPerSecond": 100000, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Status": "ACTIVE" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp; ... これらの設定を定期的に確認することで、大規模な処理に対して自信を持って備えることができ、DynamoDB テーブルは常に最高のパフォーマンスを発揮できるようになります。 ウォームスループットの互換性 ウォームスループットは、グローバルセカンダリインデックスやグローバルテーブルなどの DynamoDB の重要な機能と完全に統合されており、システム全体で一貫したパフォーマンスを確保するのに役立ちます。 セカンダリインデックス グローバルセカンダリインデックス (GSI) の場合、ウォームスループットの値を個別に指定できるため、ワークロードの要件に合わせてパフォーマンスを細かく調整できます。ベーステーブルから GSI への書き込みレプリケーションでボトルネックを回避するには、GSI の WriteUnitsPerSecond をベーステーブルと同等以上の値に設定することをお勧めします。ただし、インデックスのパーティションキーまたはソートキーのいずれか、あるいは両方を頻繁に更新する場合は、書き込み競合を防いで最適なパフォーマンスを実現するために、 WriteUnitsPerSecond をベーステーブルの値の 1.5 倍に増やすことをお勧めします。 次のコード例は、GSI に事前ウォーミングを設定する方法を示しています。 aws dynamodb update-table \ --table-name FlashSaleTable \ --attribute-definitions AttributeName=GSI1PK,AttributeType=S \ --global-secondary-index-updates '[ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Create": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "WarmThroughput": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ReadUnitsPerSecond": "12000", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "WriteUnitsPerSecond": "100000", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "IndexName": "GSI1", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "KeySchema": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "AttributeName": "GSI1PK", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "KeyType": "HASH" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Projection": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ProjectionType": "ALL" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } ]' グローバルセカンダリインデックスを更新する手順については 開発者ガイド を参照してください。 DynamoDB グローバルテーブル ウォームスループットは DynamoDB Global Tables v2019.11.21 (現行) と完全に互換性があり、一貫したパフォーマンスでグローバルワークロードを効率的に管理できます。レプリカがあるすべての AWS リージョンでテーブルを事前ウォーミングできます。そのため、ユーザーの地理的位置に関係なく、高トラフィックを同時に処理できるようになります。 デフォルトでは、ウォームスループット値を更新するリクエストは、読み取りと書き込みのどちらの操作においても、すべてのレプリカ間で自動的に同期されます。そのため、すべてのリージョンで一貫したパフォーマンスが実現されます。 Infrastructure as Code (IaC) ウォームスループットの主なメリットの 1 つとして AWS CloudFormation などのインフラストラクチャーコード (IaC) ツールとの統合があります。以前はオンデマンドの DynamoDB テーブルを事前ウォーミングするには、複数のステップが必要でした。テーブルをプロビジョンドモードに切り替え、手動でキャパシティを増やし、一定期間後にオンデマンドモードに戻す必要がありました。この方法で目的は達成できますが、複数回のデプロイと調整が必要でした。 ウォームスループットを使えば IaC を利用した DynamoDB テーブルの管理が大幅に簡単になります。テーブル作成時にウォームスループットの値を渡すことで、テーブルをあらかじめ事前ウォーミングできるようになりました。これにより手動の介入や複雑なワークフローが不要になり、IaC テンプレート内で直接、テーブルのパフォーマンスベースラインを定義できるようになります。 次の CloudFormation テンプレートは、オンデマンド ( PAY_PER_REQUEST ) モードで FlashSaleTable という名前の DynamoDB テーブルを定義しています。このテーブルには String 型の ProductID という主キーがあります。 WarmThroughput は、最初の ReadUnitsPerSecond を 50,000 RCU、 WriteUnitsPerSecond を 100,000 WCU に設定しています。 AWSTemplateFormatVersion: 2010-09-09 Resources: &nbsp; TestTableTemplate: &nbsp;&nbsp;&nbsp; Type: 'AWS::DynamoDB::Table' &nbsp;&nbsp;&nbsp; Properties: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TableName: FlashSaleTable &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BillingMode: PAY_PER_REQUEST &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AttributeDefinitions: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - AttributeName: ProductID &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AttributeType: S &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KeySchema: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - AttributeName: ProductID &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KeyType: HASH &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WarmThroughput: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - ReadUnitsPerSecond: 50000 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WriteUnitsPerSecond: 100000 次のテンプレートでは、eu-west-1 と eu-west-2 リージョンにレプリケートされた、FlashSaleTable という名前の DynamoDB グローバルテーブルを作成します。単一リージョンの例と同様に、 WarmThroughput を 50,000 RCU、100,000 WCU に設定しています。 AWSTemplateFormatVersion: 2010-09-09 Resources: &nbsp; TestTableTemplateGlobal: &nbsp;&nbsp;&nbsp; Type: 'AWS::DynamoDB::GlobalTable' &nbsp;&nbsp;&nbsp; Properties: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TableName: FlashSaleTable &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AttributeDefinitions: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - AttributeName: ProductID &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AttributeType: S &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BillingMode: PAY_PER_REQUEST &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KeySchema: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - AttributeName: ProductID &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KeyType: HASH &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WarmThroughput: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ReadUnitsPerSecond: 50000 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WriteUnitsPerSecond: 100000 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Replicas: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Region: eu-west-1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Region: eu-west-2 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; StreamSpecification: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; StreamViewType: NEW_AND_OLD_IMAGES ウォームスループットの料金 ウォームスループットの料金は、テーブルが配置されている特定のリージョンでプロビジョニングされた WCU と RCU のコストに基づきます。テーブルを事前ウォーミングする場合、コストは新しい値と現在のテーブルまたはインデックスがサポートしているウォームスループットの差に基づいた 1 回限りの料金として計算されます。 デフォルトでは、オンデマンドテーブルのウォームスループットのベースラインは 4,000 WCU と 12,000 RCU です。新しく作成したオンデマンドテーブルを事前ウォーミングする場合、指定した値とこれらのベースライン値の差分のみが課金されます。 例えば既存のテーブルを 40,000 WCU と 40,000 RCU で事前ウォーミングする場合、テーブルにすでに 10,000 WCU と 12,000 RCU が設定されていれば、追加で必要な 30,000 WCU と 28,000 RCU に対して 1 回限りの課金が発生します。事前ウォーミングでは、テーブルが現在使用しているテーブルクラスやキャパシティモードに関係なく、Standard テーブルクラスのプロビジョンドキャパシティが使用されます。 バージニアリージョン (us-east-1) のコストは次のとおりです。 - $0.00065 per WCU - $0.00013 per RCU 計算式: - 30,000 write units * $0.00065 = $19.50 - 28,000 read units * $0.00013 = $3.64 合計金額: $23.14 これにより、テーブルはスケーリングの遅延なしに即座に大量のトラフィックを処理できるようになります。また、課金は設定したキャパシティに対してにのみ生じます。コストを適切に管理するには、予想されるスループットの需要を正確に見積もり、それに応じてあらかじめ事前ウォーミングを実施することが重要です。詳細については、 DynamoDB 料金ガイド を参照してください。 まとめ ウォームスループットは DynamoDB テーブルを作成した瞬間から、または既存のテーブルに対して、高トラフィックに備えるために使用できる新機能です。新商品の発売やスーパーボウルなどの大規模なオンラインイベントに備える際、ウォームスループットは信頼性の高い、一貫したパフォーマンスを提供するテーブルの用意を確実に支援します。 ウォームスループットの詳細については Amazon DynamoDB 開発者ガイド を参照してください。 著者について Lee Hannigan は、アイルランドのドネゴールに拠点を置く Sr. DynamoDB Specialist Solutions Architect です。分散システムに関する豊富な専門知識を持ち、ビッグデータと分析技術の強固な基盤を備えています。Sr. DynamoDB Specialist Solutions Architect として、 DynamoDB の機能を活用したワークロードの設計、評価、最適化を支援することが得意です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 4 月 3 日 (木) 14:00-16:00 に、 流通小売/消費財/EC 企業向けのオンラインセミナー を開催します。 リテールテック JAPAN は、開催 41 回目を迎える国内最大の流通業向け情報システム総合展示会（日本経済新聞社主催）です。こちらの展示会に AWS が 8 年ぶりに出展しました。オンラインセミナーでは、AWS ブースの展示テーマ、展示デモのバーチャル・ブースツアー、ミニシアターで行われたライトニングトークなど改めてご紹介します。ご登録の上、ぜひご視聴ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年3月24日週の主要なアップデート 3/24(月) Amazon Q in QuickSight のシナリオ機能が一般提供開始 Amazon Q in QuickSight のシナリオ機能が一般提供開始になりました。アシスタント生成 AI が搭載されたシナリオ機能では、自然言語でビジネス上の課題などを与えることで、それに対するデータ活用やインサイトなどを得ることが出来ます。例えば「売上を上げるための施策はどういったことが考えられますか？」といった抽象的なテキストを投げると、QuickSight で作成したダッシュボードを基に、地域別、製品カテゴリ別、ディスカウントの傾向分析などをアシスタント生成 AI が自動的に行ってくれ、インサイトを出してくれます。100 % 正しいものではないですが、気が付かなかったインサイトを発見することができ、その後のアクションのきっかけにしていただけると思います。手元で触った範囲ですが、「日本語で出力してください」とテキストで依頼すると、日本語で出力することを確認できました。リージョンは、バージニア北部、オレゴン、フランクフルト、アイルランドで利用可能です。 AWS Elemental MediaConnect が NDI® 出力のサポートを追加 AWS Elemental MediaConnect で、NDI® (Network Device Interface) の出力をサポートしました。NDI は高品質かつ低遅延のビデオ接続技術であり、ライブプロダクションアプリケーションで広く使用され、500 以上のハードウェア製品と 300 以上のソフトウェアアプリケーションでサポートされています。カメラなどのオンプレミスソースをクラウドでのライブプロダクションに接続するプロセスが、従量課金制の価格モデルを使用することで、より簡単に展開できます。 AWS DMS Schema Conversion が IBM Db2 for z/OS から Amazon RDS for Db2 の変換をサポート AWS DMS Schema Converison は、データベースの移行を行う際に、移行元のデータベースを自動的に評価し、移行先のデータベースサービスと互換性のある形式に変換して、移行に伴う負担を軽減できます。今回のアップデートで、IBM Db2 for z/OS から Amazon Relational Database Service (RDS) for Db2 への変換をサポートしました。ストアドプロシージャ、関数、ビューなどのデータベースオブジェクトを自動的に変換できます。特に、環境間の構文の違いや互換性の違いを解決でき、メインフレーム移行に便利に利用できます。 3/25(火) Amazon OpenSearch Service で OR2 と OM2 のインスタンスタイプをサポート Amazon OpenSearch Service で 2 つの新しいインスタンス、OR2 と OM2 をサポートしました。新世代の OpenSearch 最適化インスタンスは OR1 インスタンスと同じアーキテクチャを使用し、より良い価格性能を提供するものです。OR2 インスタンスは、以前の OR1 インスタンスと比較して最大 26% 高いインデックス作成スループットを提供し、R7g インスタンスと比較して 70% 向上しています。OM2 インスタンスは、内部ベンチマークにおいて OR1 インスタンスと比較して最大 15% 高いインデックス作成スループットを提供し、M7g インスタンスと比較して 66% 向上しています。 Amazon RDS for SQL Server が Teradata データベースへのリンクサーバをサポート Amazon RDS for SQL Server が、Teradata データベースへのリンクサーバをサポートするようになりました。リンクサーバは、外部のリモートデータベースサーバーからデータを読み取り、コマンドを実行できるようにする SQL Server の機能です。この発表により、RDS for SQL Server インスタンスを AWS 上または社内で実行されている Teradata データベースにリンクできるようになります。 3/26(水) AWS Amplify Hosting が AWS WAF の提供開始 AWS Amplify Hosting が AWS WAF の統合を提供開始しました。マネージドルールを使用して SQL インジェクションやクロスサイトスクリプティング (XSS) などの一般的な web 攻撃や脆弱性から保護することができます。さらに、特定のアプリケーションニーズに基づいてカスタムルールを作成したり、DDoS 攻撃から保護するためのレートベースのルールを実装したり、特定の国からのアクセスを制限するためのジオブロッキングを使用したりすることができます。この統合により、お客様は web アプリケーションのセキュリティを向上し、脅威からの保護をしやすくなります。 Amazon SageMaker HyperPod クラスターにおける Slurm のマルチヘッドノードをサポート Amazon SageMaker HyperPod クラスターで、マルチヘッドノードをサポートしました。これにより、大規模の生成 AI モデル開発ワークロードの障害耐性と可用性を向上させます。単一のヘッドノードがジョブスケジューリングとリソース割り当てを管理する場合、ヘッドノードの障害が生成 AI モデル開発の業務に影響を与えてしまいます。これに対応するため、HyperPod Slurm クラスター内に複数のヘッドノードを設定できるようになりました。プライマリヘッドノードに障害が発生した場合、Slurm は自動的にクラスター操作をバックアップノードに移行し、ダウンタイムを最小限に抑え、ワークロードの継続的な可用性を提供します。 AWS サンプルアプリケーションで Amazon S3 用 Storage Browser を素早くデプロイが可能に GitHub Repository で公開しているサンプルアプリケーションを利用 して、利用者が簡単に S3 に接続してファイルのアップロード、ダウンロード、管理を行うためのアプリケーションを簡単にデプロイできるようになりました。このサンプルアプリケーションには、Storage Browser for Amazon S3 が利用されています。Amplify Hosting または任意のホスティングプロバイダーでホストできます。 3/27(木) AWS CloudFormation が IaC ジェネレーターでターゲットリソーススキャンをサポート開始 IaC ジェネレーターはアップデート以前から存在していた機能で、AWS 上のリソースをスキャンし、IaC 対象リソースを選択することで、既存のリソースから CloudFormation テンプレートを生成できるものです。今回のアップデートで、リソーススキャンのステップで IaC ジェネレーターがスキャンする対象のリソースタイプを指定できるようになりました。デフォルトですべてのリソースをスキャンする代わりに、ワークロードに関連するリソースにのみを対象にすることで、スキャン時間の削減と、選択のしやすさが向上するメリットがあります。 Amazon EKS が、クラスターアップグレードの際にアップグレードインサイトチェックを適用 Amazon EKS で Kubernetes クラスターアップグレードの際に、互換性に影響を与える可能性のある問題が既に検出されている場合、誤ったクラスターアップグレードを防止する新しい仕組みを提供開始しました。この機能は EKS アップグレードインサイトを活用しており、非推奨の Kubernetes API 使用などの、Kubernetes バージョンアップグレードに影響を与える可能性のある問題を自動的にスキャンします。このアップデートにより、問題が発見されている場合、クラスターアップグレードを停止するようになります。また、アップグレード時にチェックを無効化するオーバーライドフラグも導入しました。 Amazon Bedrock Knowledge Bases がベクトルストレージに Amazon OpenSearch マネージドクラスターをサポート Amazon Bedrock Knowledge Bases で Amazon OpenSearch マネージドクラスターをベクトルストアとしてサポートしました。これまで、OpenSearch Serverless, Aurora, Neptune, Pinecone などをサポートしていたところに、新たに追加された形です。OpenSearch マネージドクラスターを利用することで、カスタムシノニムや カスタムプラグインを通じた日本語形態素解析器の Sudachi などが利用できるようになり、RAG における精度向上のメリットを得やすくなります。また、OpenSearch マネージドクラスターでは、考慮点は必要ですが、コスト効率の高い 1 台のインスタンス構成をご検討いただけます。 OR1/OR2 のインスタンス を利用した場合、EBS にデータを書き込む際に、Amazon S3 にデータが同期的にコピーされます。インスタンスに障害が発生した場合、Amazon S3 から自動的にデータの復旧を行う仕組みがあります。障害発生時にはアクセスができなくなりますが、一時的な停止を許容できるユースケースの場合はご検討いただけます。 3/28(金) Amazon EC2 C8g インスタンスが AWS アジアパシフィック (東京) で利用可能 EC2 で、C8g インスタンスが、新たに東京リージョンで利用可能になりました。AWS Graviton4 プロセッサを搭載し、AWS Graviton3 ベースのインスタンスと比較して最大 30% 優れたパフォーマンスを提供します。C8g インスタンスは、高性能コンピューティング (HPC)、バッチ処理、ゲーム、ビデオエンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習 (ML) 推論、広告配信などの計算集約型ワークロード向けに構築されています。 Amazon EC2 が特定の宛先へのより多くの帯域幅とジャンボフレームをサポート Amazon EC2 でリージョン間 VPC ピアリングや、Direct Connect を利用する際に、EC2 インスタンス帯域幅を最大限利用できるようになりました。これまで、EC2 インスタンスからリージョン間または AWS Direct Connect に向けて通信する際に、32 以上の vCPU を持つインスタンスでは帯域幅制限の 50%、小規模なインスタンスでは 5 Gbps に制限されていました。このアップデートで、インスタンスのベースライン仕様の全帯域幅または 5Gbps のいずれか大きい方で帯域幅を送信できるようになりました。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です