本投稿は、Community Manager for the OpenSearch Project である Kris Freedain によって2024 年 9 月 16 日に投稿された 記事 の日本語訳です。 ポピュラーなオープンソース、Apache 2.0 ライセンスの検索・分析スイートである OpenSearch が、重要な節目を迎えました。OpenSearch を Linux Foundation 傘下のコミュニティ主導イニシアチブである OpenSearch Software Foundation に移管したのです。この発表は、今年初めに共有されたプロジェクトの リーダーシップ拡大 に続くもので、プロジェクトの将来を導く決定に AWS 外の利害関係者を含めることになりました。 プロジェクトのガバナンスを開放し、中立的な場所に移行することで、OpenSearch チームは、プロジェクトの創設理念である「コミュニティによる、コミュニティのため」をさらに推し進める具体的な措置を講じています。これには、包括的で透明性のある環境の育成、貢献者からの積極的な参加の奨励、コミュニティ主導の意思決定プロセスの優先が含まれます。 OpenSearch が 発表 された当初から、このプロジェクトは常に、オープンソースプロジェクトが顧客とより広範なコミュニティに高品質のソリューションとイノベーションを提供する方法の優れた例となるよう努めてきました。プロジェクトが発展するにつれて、多くの学習機会がありました。AWS は多くのオープンソースコミュニティの活発な一員ですが、プロジェクトをオープンソースに導くことで、多くの新しい経験がもたらされました。プロジェクトに携わる多くのエンジニアにとって、これがオープンソースプロジェクトに関与し貢献する初めての機会でした。 オープンな開発は、クローズドな開発とは大きく異なるため、速やかな立ち上げには独特の学習曲線がありました。AWS は、アップストリームに貢献し、ベストプラクティスを共有し、他者を支援するために時間とリソースを投資することで、オープンソースプロジェクトへの積極的なコミットメントを示しました。これは、私たちの貢献を次のレベルに引き上げ、オープンな環境で作業し、パブリックなトリアージ会議を開催し、プロジェクトのロードマップをオープンに公開することを意味しました。 Amazon OpenSearch Service のユーザーにとって、OpenSearch プロジェクトが Linux Foundation に移行しても、サービスの管理や運用方法に変更はありません。とはいえ、堅牢なオープンソースプロジェクトとコミュニティは、OpenSearch をベースにしたあらゆるオファリングと同様に、そのサービスのイノベーションを継続的に促進すると我々は考えています。 立ち上げ以来、OpenSearch プロジェクトは大きな注目と人気を獲得し、これまでのダウンロード数は 7 億回を超えています（月間ダウンロード数は前年比 56% 増）。コミュニティには、数千人ものコントリビューター、25 の異なる組織から 200 人を超えるメンテナーがプロジェクトに参加しています。プロジェクトは明確に定義されたリリースメカニズム、定期的なコミュニティおよびトリアージ会議、開発者とユーザーのコミュニティからの積極的な貢献を誇っています。 AWS による管理は、プロジェクトの成功に重要な役割を果たしてきましたが、プロジェクトの成長に伴い、より多様な追加のユーザー、貢献者、メンテナーのプールが必要になってきました。プロジェクトを Linux Foundation の下に移すことで、OpenSearch の歴史の次の章が開かれると我々は考えています。これにより、プロジェクトはオープンソースの旅をさらに進め、より開かれたガバナンスを可能にし、オープンソースコミュニティに長期的かつ持続的な利益をもたらすことが保証されるでしょう。 OpenSearch と、われわれが最近立ち上げを支援した最新のオープンソースプロジェクトである Valkey には多くの類似点があります。RedMonk の Stephen O’Grady は最近、 The Post Valkey world を執筆し、そこでこのプロジェクトを、多様な支持者を持つ十分に維持されたオープンソースプロジェクトが成功に向けて良好な位置にあることの証拠として挙げています。Valkey と OpenSearch の道筋と進捗は多くの重要な点で異なりますが、AWS はイノベーションを推進するオープンソースの力を固く信じているため、長期的に OpenSearch にコミットし続けています。 Valkey や OpenSearch、または私たちが貢献している多くのプロジェクトに関わらず、 AWS はオープンソースが顧客と世界にとって重要であることを知っています。私たちは、このプロジェクトの次の章とその継続的な成長の一部となることに興奮しています。この刺激的な発表についての OpenSearch コミュニティからの詳細は、 Building the future of OpenSearch together をお読みください。 著者について Kris Freedain は、OpenSearch プロジェクトのコミュニティ マネージャーです。彼はテクノロジー業界で数十年の経験がありますが、コミュニティの専門家として最もやりがいを感じられるのは、人々を結びつけることだと感じています。仕事以外のときは、妻や息子と時間を過ごし、庭でガーデニングをしたり、ガレージジムでパワーリフティングをしたり、瞑想を楽しんでいます。

本投稿は、head of open source strategy and marketing at AWS である David Nalley によって 2024 年 1 月 16 日に投稿された 記事 の日本語版です。 OpenSearch プロジェクトは 2023 年 12 月に初の OpenSearch リーダーシップ委員会 を立ち上げ、新たなマイルストーンを達成しました。この委員会は、オープンソースプロジェクトの方向性を決定する公開された可視的かつアクセス可能なプロセスに、幅広いユーザー、貢献者、コミッターのコミュニティを含めるオープンガバナンスに向けた新たな一歩です。オープンガバナンスは、リーダーシップへの明確に定義された道筋を作り出し、誰もが参加してプロジェクトにアイデアと変更をもたらすことができるようにします。プロジェクトの参加者が広範囲かつ多様であるほど、イノベーションは加速し、より安全で回復力が高くなり、特定の個人や組織への依存度が低くなるため、より持続可能になります。 OpenSearch と OpenSearch Dashboard は、当初 2021 年に AWS から Apache 2.0 ライセンスのプロジェクトとして始まり、以前オープンソースだった Elasticsearch と Kibana のバージョンに基づいていました。しかし、オープンソースソフトウェアは単なるライセンスではなく、 コミュニティ です。 OpenSearch の目標は常に、コミュニティ主導のオープンソース分析スイートを確立することでした。プロジェクトがこの段階に到達するまでの道のりは素晴らしいものでした。2023 年末時点で 3 億 2000 万回以上のダウンロード、70 以上のパートナー、115 のリポジトリ、227 人のメンテナーを擁しています。今や AWS を超えて、より多様なメンバーを代表するプロジェクトリーダーシップを含めるための準備が整いました。 新しいリーダーシップ委員会は、メンテナー、リポジトリオーナー、プロダクトデベロッパー、エンジニア、デベロッパーアドボケイト、および製品を使用している企業で構成されています。委員会のメンバーは以下の通りです：Anandhi Bumstead (AWS)、Mark Cohen (AWS)、Eli Fisher (AWS)、Kris Freedain (AWS)、Charlotte Henkle (AWS)、Samuel Herman (Oracle)、Grant Ingersoll (Develomentor)、Nicholas Knize (AWS)、Jonah Kowall (Aiven)、Andriy Redko (Aiven)、Nithya Ruff (Amazon)、Mehul A. Shah (Aryn.ai)、Amitai Stern (Logz.io)。オープンソースプロジェクトが長期的な存続を目指す中で、コミュニティ内で真の信頼関係を確立することが成功の鍵となります。 「OpenSearch プロジェクトは、機能が豊富で広く使用され、活気あるコミュニティによってサポートされる、成功したオープンソースの検索および分析ソフトウェアスイートを作ることを目指しています。OpenSearch の始まりから、プロジェクトは協力の最善の方法を見出し、全ての利害関係者に意思決定の場を与えることに努めてきました」と、AWS の OpenSearch エンジニアリングディレクターである Anandhi Bumstead は、オープンソースプロジェクトのコミュニティと将来について尋ねられた際に述べています。「ガバナンスは OpenSearch プロジェクトの重要な側面です。私たちは AWS のメンバーを超えてオープンソースコミュニティを成長させ、OpenSearch プロジェクトのためにオープンソースイノベーションの力を活用することを目指しています。」 AWS は OpenSearch プロジェクトの熱心な支持者です。私たちは、専任のエンジニアとマーケターのチームを含め、プロジェクトをサポートし貢献するために多大な投資を続けています。プロジェクトが透明性のある実践を構築し、コミュニティをつなげることに継続的に取り組んでいることを認識したいと思います。OpenSearch チームは、オープンソースプロジェクトがコミュニティのためであり、コミュニティによって作られているという意識を高めるための取り組みを積極的に行ってきました。プロジェクトはまだ道のりの初期段階にあり、次の段階を定義するためにはユーザーと貢献者に依存することになるでしょう。 OpenSearch について OpenSearch は、分散型で、コミュニティ主導の、完全にオープンソースの検索および分析スイートです。組み込みのセキュリティ、拡張可能な容量とパフォーマンス、高可用性のサポートにより、OpenSearch は検索、可観測性、セキュリティ分析などのエンタープライズグレードのアプリケーションにとって堅固な基盤となります。 OpenSearch は、 AWS オープンソースセキュリティウェブページ で強調されているように、より広範なコミュニティの基準を引き上げることに取り組んでおり、オープンリリースの透明性と最近のオープンガバナンスを実現しています。ガバナンスは、AWS のメンバーを超えてオープンソースコミュニティを拡大し、OpenSearch プロジェクトのためにオープンソースベースのフライホイールを推進するという目標において、OpenSearch プロジェクトの中心的な課題となっています。過去 2 年間で、透明性とオープンガバナンスを高めるためにいくつかの steps を実施しました。これには以下が含まれます：1) 2022 年 5 月に 外部メンテナーのサポートを追加 、2) コミュニティの誰もが参加できる 新しいコミュニティ Slack ワークスペースを開始 、3) 外部メンテナーとコミッターが参加できるよう リリースプロセスを公開 、4) セキュリティの基準を引き上げ、 事前開示リストを含むセキュリティ問題の報告と管理のプロセスを作成 、5) 設計の議論、ロードマップ項目のトリアージ、問題の優先順位付けなどを行うための 隔週のコミュニティミーティングを開催 。 著者について David Nalley は、20 年近くにわたってオープンソースに関わってきました。彼は AWS のオープンソース戦略およびマーケティングの責任者であり、現在は Apache Software Foundation の会長を務め、Internet Security Research Group の理事も務めています。 X (@ke4qqq) で彼をフォローしてください。

生成 AI の進化と共に、大規模言語モデル (LLM) を活用したアプリケーション開発が急速に広がっています。その中で、検索拡張生成 (Retrieval-Augmented Generation; RAG) は、LLM に対して最新の情報や特定のドメイン知識を組み込むための重要な技術として注目を集めています。 RAG は、その名の通り、外部知識ベースから関連情報を検索し、それを LLM の入力に組み込むことで、より正確で最新の情報に基づいた回答を生成する手法です。この手法には以下のような重要な利点があります。 最新情報の反映: LLM の学習データの制限を超えて、最新の情報を回答に反映させることができる。 ドメイン特化: 特定の分野や組織固有の情報を容易に組み込むことができ、専門的な質問にも対応可能になる。 根拠の明確化: 生成された回答の情報源を追跡しやすくなり、回答の信頼性が向上する。 ハルシネーション (幻覚) の低減: 外部知識に基づいて回答を生成するため、LLM が誤った情報を創作するリスクを軽減できる。 基本的な RAG システム (Naive RAG / Baseline RAG) でも多くの場合で十分な性能を発揮しますが、より複雑な質問や高度な応用では、さらなる改善が必要となります。 Advanced RAG は、この基本的な RAG を様々な手法で拡張し、以下のような課題に対応するために開発されています。 複雑なクエリへの対応: 多岐にわたる情報や複数の文書にまたがる知識を必要とする質問に適切に回答する。 検索精度の向上: より関連性の高い情報を正確に抽出し、回答の質を向上する。 コンテキストの理解: 質問の意図や背景をより深く理解し、適切な情報を検索・生成する。 前回の記事「 Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証 」では Amazon Bedrock を用いたクエリ拡張と検索結果の関連度評価という手法に絞って実装方法と検証結果を紹介しました。本記事では、AWS のサービスを活用したさまざまな Advanced RAG の実装方法や、精度を向上させるための様々なテクニックを紹介します。これらの手法を理解し適用することで、より高度で信頼性の高い AI アプリケーションの開発が可能になります。 RAG の基本構成 RAG の基本的な仕組みを理解することは、Advanced RAG の技術を効果的に適用するための第一歩です。ここでは、RAG のデータフローと、その中で特に重要となる検索精度の課題について説明します。 RAG システムは大きく分けて、データ準備 (データ取り込み) フェーズと利用 (検索 + テキスト生成) フェーズの 2 つのフェーズで構成されています。 データ準備 (データ取り込み) フェーズ ドキュメント収集: RAG で使用する知識ベースとなる文書を収集する。 テキスト分割: 長い文書を適切な長さのチャンク (断片) に分割する。 ベクトル化: 各チャンクを埋め込みモデルを使ってベクトル表現に変換する。 インデックス化: 変換されたベクトルをベクトルデータベースに格納する。 利用 (検索 + テキスト生成) フェーズ クエリベクトル化: ユーザーからの質問文を埋め込みモデルでベクトル化する。 類似度検索: ベクトルデータベースから質問に類似したチャンクを検索する。 コンテキスト構築: 検索結果を元に、LLM への入力コンテキストを構築する。 回答生成: LLM を使用して、構築されたコンテキストに基づいて回答を生成する。 RAG システムの性能は、大きく検索の精度に依存します。以下のような問題が検索精度に影響を与え、結果として生成される回答の質を左右します。 不適切なチャンク選択: 質問に関連性の低いチャンクが選択されると、的外れな回答が生成される可能性がある。 必要な情報が複数のチャンクに分散している場合、全ての関連情報を適切に取得できないことがある。 コンテキストの欠落: チャンクサイズが小さすぎると、重要なコンテキスト情報が失われる可能性がある。 逆に大きすぎると、ノイズとなる情報も含まれてしまい、回答の精度が下がる可能性がある。 意味的類似性の限界: 単純なベクトル類似度だけでは、文脈や意図を完全に捉えきれない場合がある。 例えば、否定表現や条件付きの文章の意味を正確に理解することが難しい場合がある。 多様な表現への対応: 同じ概念や事実が異なる表現で記述されている場合、適切に関連付けることが困難な場合がある。 これらの課題に対処するために、Advanced RAG ではさまざまな手法が提案されています。以降のセクションでは、これらの改善テクニックについて詳しく見ていきます。 Advanced RAG の概要 Advanced RAG は、基本的な RAG システムの性能を向上させるための一連の技術や手法の総称です。Advanced RAG の手法は、RAG のパイプライン内のどの部分を改善するかによって分類することができます。主な改善領域には、データ準備段階、クエリ処理、検索段階、検索結果の後処理、そして回答生成があります。 データ準備段階 では、チャンクサイズの最適化や高度なドキュメントパース技術、メタデータの抽出などが行われます。 クエリ処理の改善 には、クエリ拡張や分解、意図分類などの技術が含まれます。 検索段階 では、ハイブリッド検索やグラフベースの知識表現 (Graph RAG) などが活用されます。 検索結果の後処理 では、リランキングやフィルタリング、Small-to-Big Retrieval (階層チャンク) などの手法が用いられます。 回答生成の改善 には、プロンプトエンジニアリングや複数ステップの推論、自己一貫性チェックなどが活用されます。 これらのアプローチは、単独で使用することも、複数を組み合わせて使用することも可能です。実際の適用においては、タスクの性質、データの特性、要求される精度や応答時間などを考慮して、最適な手法を選択することが重要です。 他にも、エージェントとして RAG を実行したり、基盤モデルのファインチューニングを行うアプローチもありますが、相応のコストが発生します。まずはチャンクサイズ調整、ドキュメントパースの改善、メタデータによるフィルタ、ハイブリッド検索といった手軽に利用できる手法から試すのをおすすめします。 Advanced RAG の適用における重要な注意点 高度な技術を採用する前に、まず基本に立ち返ることが重要です。Advanced RAG や GraphRAG といった複雑な手法を闇雲に適用する前に、現在の RAG システムの性能を適切に評価し、具体的な問題点を特定することが必要です。 効果的な RAG 改善のアプローチとして、まず RAG システムの性能を正確に測定するための評価フレームワークを構築しましょう。この評価システムには、ユーザーのクエリ (質問)、検索結果、そして最終的な LLM の回答を含めるとよいでしょう。オフライン評価やユーザによるオンライン評価等の評価指標を測定するためには OSS の RAGAS や Amazon Science が公開している RAGChecker のようなライブラリがよく利用されます。 そして、この評価システムを用いて、回答の質が悪いパターンを収集し、分析します。各ステップでどこに問題があるのかを特定し、なぜそのような結果になったのかを深く掘り下げます。例えば、クエリの加工が適切でないのか、検索結果の関連性が低いのか、それとも LLM の回答生成に問題があるのかを見極めます。開発者は「有給休暇を取得する方法を教えてください。」のようなチャット形式で質問される想定でいても、ユーザーのクエリが「有休」のような単一のワードのみ入力されるかもしれません。この場合、「有給休暇」が「有休」と省略されており、類義語への対応が必要かもしれません。また、有休の取得なのか、取り消しなのか、ユーザーが何を知りたいのかが曖昧です。 問題の根本原因が特定できたら、それに基づいて最適な改善策を検討します。ここで重要なのは、必ずしも高度なテクニックを必要としない解決策も考慮に入れることです。プロンプトエンジニアリングやシンプルな手法で十分な場合も多々あります。 実装した改善策の効果を継続的に評価し、必要に応じて調整を加えていくことが大切です。この過程を繰り返すことで、システムの段階的な改善を図ることができます。 このアプローチを採用することで、不必要に複雑な解決策を避け、効率的かつ効果的に RAG システムの性能を向上させることができます。Advanced RAG の技術は確かに強力ですが、それらを適用する前に、まず基本的な評価と分析のプロセスを確立することが、長期的な成功への鍵となります。 基本的な RAG 改善テクニック: まずはここから RAG システムの性能を向上させるための基本的なテクニックには、チャンクサイズの調整、ドキュメントパースの改善、メタデータによるフィルタリング、ハイブリッド検索などがあります。これらのテクニックは比較的実装が容易で、多くの場合、大きな効果が期待できます。 チャンクサイズの調整 チャンクサイズはベクトル検索の基礎的な調整項目ですが、RAG システムの性能に大きな影響を与える重要な要素です。小さすぎるチャンクは検索の精度を上げる一方で、文脈の欠落を招く可能性があります。逆に、大きすぎるチャンクは関連性の低い情報を含んでしまう可能性があります。 最適なチャンクサイズは、扱うデータの性質や質問の種類によって異なります。一般的には、256 から 1024 トークン程度の範囲で調整することが多いですが、実際のタスクに応じて実験的に最適な値を見つけることが重要です。 チャンクサイズの調整によって、検索精度、回答の関連性、処理時間のバランスを取ることができます。例えば、 LlamaIndex のブログ記事 “ Evaluating the Ideal Chunk Size for a RAG System using LlamaIndex ” の実験では、チャンクサイズを 1024 程度に増やすことで、レスポンスタイムは若干増加するものの、回答の忠実性 (Faithfulness) や関連性 (Relevancy) が向上したと報告されています。 ドキュメントパースの改善 ドキュメントパースの改善は、特に PDF や複雑なフォーマットの文書を扱う際に重要です。単純なテキスト抽出では、レイアウト情報や図表の内容が失われてしまう可能性があります。 例えば PDF にはヘッダー、フッター、ページ番号などのノイズが含まれることがあるので、これを除去したり、本文としてではなくメタデータとして扱ったりすることで、本文の内容を正確に抽出することができます。また、表や図表の内容をテキスト形式に変換することで、検索可能な情報を増やすことができます。 例えば、 Amazon Bedrock Knowledge Bases の高度なパース機能 では、Anthropic の Claude 3 というマルチモーダルなモデルを使用して、図や表を Markdown などのテキスト形式に変換することができます。これにより、視覚的な情報も含めた総合的な検索が可能になります。 メタデータによるフィルタリング メタデータを活用したフィルタリングは、検索結果の精度を大幅に向上させる効果的な手法です。メタデータには、ドキュメントのタイトル、作成日時、著者、カテゴリなどが含まれます。 例えば、時系列データを扱う場合、ユーザーの質問に含まれる時間情報を元に、特定の期間のデータのみを検索対象とすることができます。これにより、不適切な時期の情報が回答に混入することを防ぎ、より正確な回答を生成することができます。 また、質問自体を LLM を使ってカテゴリ分類し、そのカテゴリに関連するドキュメントのみを検索対象とする方法も効果的です。これにより、検索空間を絞り込み、より関連性の高い情報を抽出することが可能になります。 Amazon Bedrock Knowledge Bases のメタデータフィルタリングの機能に関してはブログ記事「 Knowledge Bases for Amazon Bedrock がメタデータフィルタリングをサポートし検索精度向上 」を参照してください。 ハイブリッド検索 ハイブリッド検索は、キーワード検索とベクトル検索のそれぞれの長所を組み合わせた手法です。キーワード検索は特定の単語や句を含むドキュメントを正確に抽出できる一方、ベクトル検索は意味的な類似性を捉えることができます。ハイブリッド検索では、キーワード検索とベクトル検索の両方の検索を並行して行い、結果をスコアリングして統合します。 Amazon Bedrock Knowledge Bases に統合されている Amazon OpenSearch Serverless は、ネイティブにハイブリッド検索をサポートしており、簡単な設定で高度な検索機能を実現できます。これにより、キーワードの正確性とベクトル検索の柔軟性を両立させ、より適切な検索結果を得ることができます。詳しくはブログ記事「 Knowledge Bases for Amazon Bedrock がハイブリッド検索をサポート 」を参照してください。 これらの基本的な RAG 改善テクニックを適切に組み合わせることで、RAG システムの性能を大幅に向上させることが可能です。次のセクションでは、さらに高度な改善テクニックについて説明していきます。 高度な RAG 改善テクニック 基本的な改善テクニックを適用した後、さらなる性能向上を目指す場合、より高度な RAG 改善テクニックを検討することができます。ここでは、リランキング、クエリ書き換え、Small-to-Big Retrieval という3つの重要な手法について解説します。 リランキング リランキングは、初期の検索結果をさらに精緻化する手法です。通常の検索エンジンが返す結果の順序を、より高度なモデルを使用して再評価し、最も関連性の高い情報を上位に配置します。 この手法の利点は、初期検索の広範な結果を維持しつつ、最終的な順序をより洗練させることができる点です。例えば、ある質問に対して検索結果 A, B, C, D が得られたとすると、リランキングモデルはこれらの結果とクエリとの関連性を詳細に分析し、最も適切な順序に並べ替えます。 リランキングモデルには、Cohere が提供する多言語対応のモデルが広く使用されています。このモデルは、Amazon SageMaker JumpStart を通じて簡単にデプロイし、利用することができます。詳しくはブログ記事 “ Improve RAG performance using Cohere Rerank ” を参照してください。また、オープンソースのモデルを自前でホストしたり、LLM を使用してリランキングを行うこともできます。 クエリ書き換え クエリ書き換えは、ユーザーの入力した質問を、検索システムにとってより最適な形に変換する技術です。この手法は、ユーザーの意図をより正確に捉え、関連性の高い情報を効果的に検索するのに役立ちます。クエリ書き換えには、主に以下のようなアプローチがあります。 クエリの簡略化: 複雑な質問を核心的なキーワードに絞り込む。例えば、「RAG を使った検索で、検索の精度を上げるための方法をいくつか教えてください」というクエリを「RAG の精度向上」に簡略化する。 クエリの拡張: 元のクエリに関連する用語や同義語を追加し、検索範囲を広げる。例えば、「大規模言語モデル」というキーワードに対して「Large Language Model」、「LLM」、「生成 AI」といった関連用語を追加する。 クエリの分解: 複雑な質問を複数の簡単な質問に分解する。例えば、「クリーンエネルギーの世界的な普及における主要な障害と、それらを克服するための国際的な努力は何か？」という質問を、「クリーンエネルギーの定義は何か」「クリーンエネルギー普及の主な障害は何か」「どの国際組織がクリーンエネルギー普及を推進しているか」といった複数の質問に分解する。 Amazon Bedrock で提供されている Cohere Command R や Command R+ というモデルでは (1) のクエリ簡略化を行うことができます。モデルを利用する際に search_query_only オプションを True にすることで、検索クエリとして適したテキストが返ります。詳しくは開発者ドキュメント “ Cohere Command R and Command R+ models ” を参照してください。 Amazon Bedrock Knowledge Bases では、クエリ分解 (query decomposition) の機能が提供されており、複雑な質問を効果的に処理することができます。クエリ分解に関してはブログ記事 “ Amazon Bedrock Knowledge Bases now supports advanced parsing, chunking, and query reformulation giving greater control of accuracy in RAG based applications ” で説明されています。 Small-to-Big Retrieval (階層チャンク) Small-to-Big Retrieval (階層チャンク; hierarchical chunking) は、検索の精度と文脈の理解のバランスを取るための手法です。この方法では、初期検索には小さなチャンクを使用し、その後、選択されたチャンクの周辺情報も含めてLLMに提供します。具体的なプロセスは以下の通りです。 小さなチャンクを使用して初期検索を行い、最も関連性の高い部分を特定する。 選択されたチャンクの前後の文脈 (より大きなチャンク) を取得する。 LLM に対して、初期検索で見つかった小さなチャンクと、その周辺の大きなチャンクの両方を提供する。 この手法により、検索の精度を保ちつつ、より広い文脈情報を LLM に与えることができます。結果として、より正確で文脈に即した回答を生成することが可能になります。Amazon Bedrock Knowledge Bases では、この Small-to-Big Retrieval (階層チャンク) がネイティブにサポートされており、簡単に実装することができます。詳しくはブログ記事 “ Amazon Bedrock Knowledge Bases now supports advanced parsing, chunking, and query reformulation giving greater control of accuracy in RAG based applications ” を参照してください。 これらの高度な RAG 改善テクニックを適切に組み合わせることで、RAG システムの性能をさらに向上させ、より高品質な回答を生成することが可能になります。ただし、これらの手法を導入する際は、処理時間やリソース消費とのトレードオフを考慮し、適切なバランスを取ることが重要です。 GraphRAG RAG の技術は日々進化しており、その中でも特に注目を集めているのが GraphRAG です。この新しいアプローチは、従来の RAG の限界を克服し、より複雑な質問に対応することを目指しています。 GraphRAG の概要と利点 GraphRAG は、従来のベクトルデータベースの代わりに、ナレッジグラフを使用してドキュメントの知識を表現する手法です。ナレッジグラフは、情報をノードとエッジの形で構造化して表現し、データ間の関係性をより明確に捉えることができます。GraphRAG の主な利点は以下の通りです。 複雑な関係性の表現: ナレッジグラフを用いることで、文書間や概念間の複雑な関係性を明示的に表現できる。これにより、単純なキーワードマッチングやベクトル類似度では捉えきれない情報の関連性を考慮した検索が可能になる。 多段階の推論: グラフ構造を活用することで、直接的な関連がない情報同士をつなぎ合わせる多段階の推論が可能になる。これは、複数の文書にまたがる情報を必要とする複雑な質問に特に有効となる。 説明可能性の向上: 回答生成の過程で使用された情報の関係性を、グラフ上のパスとして視覚化できるため、回答の根拠をより明確に示すことができる。 コンテキストの保持: グラフ構造によって情報の階層性や文脈を保持できるため、より広い文脈を考慮した回答生成が可能になる。 複雑な質問や多岐にわたる情報を必要とするユースケースでは、GraphRAG は非常に強力なソリューションとなる可能性があります。特に、企業の内部文書や専門分野の文献など、深い文脈理解が必要な領域での活用が期待されています。 GraphRAG の実装には、大きく分けて 2 つのステップがあります。まず、入力文書からナレッジグラフを構築し、次にこのグラフを用いて質問に答えます。グラフの構築には最近では LLM を活用する手法が注目されており、質問応答の過程では、グラフ上での多段階の推論やグラフの階層 (コミュニティ) ごとの要約などの情報が用いられます。 AWS 上での GraphRAG 実装 AWS のサービスを活用して GraphRAG を実装する場合、以下のような構成が考えられます。 グラフデータベース: Amazon Neptune を使用してナレッジグラフを格納する。Neptune は高性能なグラフデータベースサービスで、大規模なグラフデータの管理と高速なクエリ処理が可能。 グラフ構築: AWS Lambda や Amazon SageMaker 上で LlamaIndex などのオープンソースライブラリを使用し、入力文書からナレッジグラフを構築する。この過程で Amazon Bedrock の LLM を活用して、テキストからエンティティや関係性を抽出する。 グラフ処理: Amazon Neptune の機能を活用して、グラフ上での検索や推論を行う。複雑なパターンマッチングやパス探索などの操作が可能。 回答生成: グラフからの検索結果を基に、Amazon Bedrock の LLM を使用して最終的な回答を生成する。この際、グラフの構造情報を活用して、より文脈に即した回答を生成することができる。 GraphRAG の実装には、従来の RAG と比べてより多くの計算リソースと複雑な処理が必要となります。そのため、性能とコストのバランスを慎重に検討する必要があります。また、グラフの構築と保守には専門知識が必要となる場合があります。 GraphRAG は比較的新しい技術であり、今後さらなる研究と改善が進むことが予想されます。AWS のサービスも継続的に進化しているため、最新の機能や事例を常にチェックし、自身のユースケースに最適な実装方法を検討することが重要です。 まとめ 本ブログでは、RAG の基本から、GraphRAG まで、Advanced RAG と呼ばれる手法を幅広く解説しました。チャンクサイズの調整、ドキュメントパースの改善、メタデータによるフィルタリング、ハイブリッド検索といった基本的な改善テクニックから、リランキング、クエリ書き換え、Small-to-Big Retrieval などの高度な手法、さらには GraphRAG のような最新のトレンドまで、様々なアプローチを紹介しました。 これらの手法を適用する際に最も重要なのは、RAG システムの評価の仕組みを確立することです。ユーザーの入力、検索結果、最終的な LLM の回答を含む評価システムを構築し、各改善策の効果を客観的に測定することが、効果的な RAG 改善の鍵となります。新しい技術を導入する際は、必ず評価システムを通じてその効果を検証し、段階的なアプローチを取りましょう。 著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習スペシャリストソリューションアーキテクトです。AWS の AI/ML サービスのお客様に対する技術的な支援を行いながら市場開拓を推進しています。好きなサービスは Amazon Bedrock と Amazon SageMaker です。週末は子供と屋内遊園地で遊ぶのが習慣になっています。博士 (理学)。

ゼロ ETL 統合では、複数のアプリケーションやデータソースにわたるデータを統合し、総体的なインサイトを取得してデータサイロを解消することができます。完全マネージド型でノーコードのほぼリアルタイムのソリューションが実現し、データが Amazon Relational Database Service (Amazon RDS) for MySQL に書き込まれてから数秒以内に Amazon Redshift でペタバイト規模のトランザクションデータを利用できるようになります。独自の ETL ジョブを作成する必要がなくなるのでデータインジェストが簡素化され、運用上のオーバーヘッドが削減されます。また、全体的なデータ処理コストが削減される可能性もあります。2023年、 Amazon Aurora MySQL 互換エディション と Amazon Redshift のゼロ ETL 統合の一般提供に加えて、Aurora PostgreSQL 互換エディション、 Amazon DynamoDB 、RDS for MySQL でのプレビュー機能が発表されました。 ここで Amazon Redshift と Amazon RDS for MySQL のゼロ ETL 統合の一般提供が開始されたことをお伝えできることを嬉しく思います。このリリースには、データフィルタリング、複数の統合のサポート、 AWS CloudFormation テンプレートでゼロ ETL 統合を設定する機能などの新機能も含まれています。 この投稿では、データフィルタリングと複数のデータベースとデータウェアハウスにわたるデータの統合を開始する方法を紹介します。ゼロ ETL 統合の設定のステップごとのウォークスルーについては、セットアップが非常に類似しているので、 このブログ投稿 で Aurora MySQL-Compatible Edition のセットアップ方法を参照してください。 データフィルタリング 規模に関係なく、ほとんどの企業では、ETL ジョブにフィルタリングを追加することでメリットが得られます。一般的なユースケースは、本番データベースから複製する必要のあるデータのサブセットのみを選択することで、データ処理とストレージのコストを削減することです。もう 1 つのユースケースは、レポートのデータセットから個人を特定できる情報 (PII) を除外することです。例えば、医療業界の企業では、最近の患者の症例を分析する集計レポートを作成するためにデータをレプリケートする際に、機密性の高い患者情報を除外することが望ましい場合があります。同様に、e コマースストアでは、顧客の支出パターンをマーケティング部門に公開する際に PII を除外する場合があります。逆に、推論を作成するためにほぼリアルタイムですべてのデータを必要とする不正検知チームがデータを利用できるようにする場合など、フィルタリングを使用することが望ましくない場合もあります。これはほんの一例に過ぎないので、自分の組織に当てはまる可能性のあるさまざまなユースケースを試してみることをお勧めします。 ゼロ ETL 統合でフィルタリングを有効にするには、統合を初めて作成するときに行うか、既存の統合を変更することによって行うという 2 つの方法があります。どちらの場合でも、このオプションはゼロ ETL 作成ウィザードの「ソース」ステップにあります。 フィルターを適用するには、データセットに対して database*.table* の形式でデータベースまたはテーブルの追加または除外を行うフィルター式を入力します。複数の式を追加することが可能です。式は左から右の順に評価されます。 既存の統合を変更する場合、変更を確認した時点から新しいフィルタリングルールが適用され、Amazon Redshift はフィルターに含まれなくなったテーブルを削除します。 さらに詳しく知りたい場合は、ステップと概念が非常に似ている Amazon Aurora ゼロ ETL 統合のデータフィルターをセットアップする方法 について解説したブログを参照することをお勧めします。 1 つのデータベースから複数のゼロ ETL 統合を作成する また、単一の RDS for MySQL データベースから最大 5 つの Amazon Redshift データウェアハウスへの統合を設定できるようになりました。唯一の要件は、最初の統合が正常にセットアップを完了するまで待ってから、他の統合を追加する必要があることです。 これにより、特定のユースケースに合わせて各チームに独自のデータウェアハウスの所有権を与えながら、トランザクションデータをさまざまなチームと共有することができます。例えば、これをデータフィルタリングと組み合わせて使用して、同じ Amazon RDS 本番データベースから開発、ステージング、本番環境の Amazon Redshift クラスターに別々のデータセットをファンアウトすることもできます。 これが本当に役立つもう 1 つの興味深いシナリオは、ゼロ ETL を使用してさまざまなウェアハウスにレプリケートすることで複数の Amazon Redshift クラスターを統合することです。また、Amazon Redshift のマテリアライズドビューを使用して、データの調査、 Amazon Quicksight ダッシュボードの強化、データの共有、Amazon SageMaker でのジョブのトレーニングなどを行うこともできます。 まとめ Amazon Redshift との RDS for MySQL ゼロ ETL 統合では、ほぼリアルタイムの分析を目的としたデータのレプリケートを行うことができます。複雑なデータパイプラインの構築や管理を行う必要はありません。現在、これは、レプリケートされたデータセットに対してデータベースとテーブルの追加や除外を行うフィルター式を追加する機能とともに一般提供されています。また、同じソース RDS for MySQL データベースから複数の異なる Amazon Redshift ウェアハウスへの複数の統合を設定することや、複数の異なるソースから統合を作成してデータを 1 つのデータウェアハウスに統合することができるようになりました。 このゼロ ETL 統合は、 サポートされている AWS リージョン の RDS for MySQL バージョン 8.0.32 以降、Amazon Redshift Serverless、Amazon Redshift RA3 インスタンスタイプで利用できます。 ゼロ ETL 統合のセットアップは、AWS マネジメントコンソールの使用に加えて、AWS コマンドラインインターフェイス (AWS CLI) から行うことや、公式 AWS SDK for Python である boto3 などの AWS SDK を使用して行うこともできます。 ゼロ ETL 統合の操作 の詳細については、該当するドキュメントを参照してください。 — Matheus Guimaraes 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 9 月 19 日 (木) に、AWS オンラインセミナーの「 RAG の困りごとは今日で一気に解決！ AWS 生成 AI Dive Deep 」を開催します。生成 AI の業務活用において、よく使われる RAG (Retrieval Augmented Generation) ですが、いざ業務で使おうとすると、精度や速度といったさまざまな課題に遭遇します。このセミナーは、RAG にまつわるお悩みを解消するための実践的なセミナーです。ぜひご登録の上ご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年9月9日週の主要なアップデート 9/9(月) Amazon Aurora で Graviton 3 ベースの R7g インスタンスを 15 リージョンでサポート Amazon Aurora PostgreSQL、Amazon Aurora MySQL で、Graviton 3 ベースの R7g インスタンスが、東京を含めた 15 リージョンでサポートしました。Amazon Aurora の Graviton2 インスタンスと比較して最大 30% のパフォーマンス向上と最大 20% のコストパフォーマンス向上を提供します。既存のインスタンスを Graviton 3 に変更したい場合は、 こちらのドキュメント を基に作業が可能です。なお、2024 年 09 月のタイミングでは、東京リージョンで R7g インスタンスのリザーブドインスタンスが提供されていないため、ご留意ください。 AWS Elasitc Beanstalk でインバウンドトラフィックの IPv6 をサポート AWS Elastic Beanstalk でコントロールプレーンのアクセスに利用する、パブリックエンドポイントと VPC エンドポイントの両方において、IPv4 と IPv6 を利用するデュアルスタックをサポートしました。AWS CLI または AWS SDK を使用する際に、デュアルスタックエンドポイントを指定して Elastic Beanstalk サービスにリクエストを送信できます。なお、Benstalk の配下で構成する ALB や EC2 などのデータプレーンについては、 デュアルスタックをサポートしていません 。詳細は こちらのドキュメント を参照ください。 EC2 Capacity Blocks で Amazon EC2 P5e インスタンスの一般提供開始 NVIDIA H200 Tensor Core GPU を搭載した Amazon EC2 P5e インスタンスの一般提供を発表しました。通常のオンデマンドではなく、EC2 Capacity Blocks というキャパシティを事前に予約する仕組みを通じて利用が可能です。P5e インスタンスは、ディープラーニングと生成 AI の推論において、EC2 で最高のパフォーマンスを提供します。8 個の H200 GPU を搭載しており、P5 インスタンスに搭載されている H100 GPU と比較して、GPU メモリサイズが 1.7 倍、GPU メモリ帯域幅が 1.5 倍になっています。P5e インスタンスは現在、オハイオリージョンで利用が可能です。 9/10(火) Amazon OpenSearch Service で OpenSearch 2.15 をサポート Amazon OpenSearch Service で OpenSearch 2.15 をサポートしました。OpenSearch 2.15 では、検索パフォーマンス、クエリ最適化などの改善が行われ、より柔軟に AI を活用したアプリケーションを構築しやすくする新機能が追加されました。新機能を一つ紹介すると、「 Radial search 」というベクトル検索機能が追加されました。生成 AI に関連したユースケースとして、Embedding でテキストをベクトル化して、意味的に近いものを検索することがあります。Radial search では、クエリポイントに指定された最大・最小スコアしきい値内にあるベクトル空間内のすべてのポイントを検索できます。k-NN では近似的な近い距離の Top 5 などを出すことができますが、Radial search ではより柔軟な検索が可能です SageMaker HyperPod で Amazon EKS の一般提供を開始 SageMaker HyperPod で Amazon EKS の一般提供を開始しました。これにより、お客様は SageMaker HyperPod 上で Kubernetes ワークロードを実行・管理できるようになります。HyperPod は基盤モデル開発のために特別に構築されたインフラストラクチャで、モデルのトレーニング時間を最大 40% 短縮します。多くのお客様が Kubernetes のエコシステムで提供されている様々なツールセットを利用しています。このアップデートで、引き続き Kubernetes ベースの体験を重視しながら、SageMaker HyperPod の利点を得やすくなりました。 9/11(水) Amazon Redshift で zero-ETL を利用したソートキーの変更をサポート Aurora MySQL 、Aurora PostgreSQL、RDS for MyQL から zero-ETL 統合を利用して Redshift にテーブルレプリケーションを行う際に、ソートキーの変更をサポートしました。ソートキーは、テーブル内で物理的な配置を制御する重要な要素となっており、範囲を指定したフィルタリングといったクエリーパフォーマンスの改善などに活用できます。また、ソートキーを AUTO にすることで、利用方法やデータパターンによって自動的にソートキーを設定することも可能です。 AWS IAM Identity Center のアクセスポータル画面で言語やダークモードなどの設定が可能に AWS IAM Identity Center のアクセスポータル画面で、表示言語やライトモード or ダークモードに関して、好みの設定を指定できるようになりました。アクセスポータル画面は、Identity Center と事前に連携設定している AWS アカウントや、アプリケーションなどへのシングルサインオン画面を提供するものです。12 個の言語や好みの表示方法の指定により、快適なアクセスを提供するアップデートです。 9/12(木) Amazon Q Developer がより自律的なコーディングをサポート Amazon Q Developer で、作業をしているプロジェクト全体に渡って、コーディングを支援してくれる Developing software 機能 があります。Q に実装したい内容をテキストで伝えることで、プロジェクト全体のファイルを見渡して、どんな変更をすると良いか計画立案をしてくれ、実際の変更後のコードをだしてくれます。今回のアップデートで、直接的な人間の介入をせずに、自律的に問題を解決する内部改善を行いました。生成されるコードの精度と品質が向上しています。なお、豆知識ですが、Amazon Q Developer の更新は、What’s new ではなく Changelog で紹介されることもありますので、興味があればチェックしてみてください。 AWS MGN で Trend Micro の post-launch 設定のサポート サーバーの移行ツールとして利用できる AWS Application Migration Service (AWS MGN) で、インスタンスの中に Trend Micro Vision One Server & Workload Protection Agent をインストールするアクションを提供しました。これは、Trend Vision One Endpoint Security の一部として提供されるサーバー向けセキュリティソリューションで、リアルタイムなウイルス検索、Web レピュテーション、セキュリティログ監視といった機能があります。組織のセキュリティニーズに合わせて、移行を行う際に、自動的にエージェントをインストールできるようになりました。 AWS Elemental MediaLive Anywhere の一般提供開始 AWS Elemental MediaLive Anywhere は、オンプレミスでライブビデオエンコーディングを実行しながら、クラウド上で管理できる MediaLive の機能です。従量課金制のサービスと AWS パートナーを通じて購入できるアプライアンスで構成されています。アプライアンス機器をオンプレミスに置き、オンプレミス側でライブビデオエンコーディングをしながら、AWS 上で MediaLive を利用した機器の管理や、それ以外の AWS サービスと連携したハイブリッドなソリューションを提供するものです。詳細は こちらのブログ をご覧ください。 9/13(金) Amazon QuickSight で Google BigQuery connector を利用したダイレクトクエリーのサポート Amazon QuickSight で、Google BigQuery をデータソースにしたダイレクトクエリーをサポートしました。このアップデートは、 2023 年 11 月に提供を開始した BigQuery コネクター の機能拡張です。従来のコネクターでは、BigQuery 上のデータを、QuickSight 上のインメモリエンジン SPICE に蓄積する方式でした。今回のアップデートで、直接 BigQuery にダイレクトクエリーが可能となり、ニアリアルタイムの可視化を実現しやすくなりました。 Amazon RDS for MySQL と Amazon Redshift 間で Zero-ETL 統合のサポート Amazon RDS for MySQL と Amazon Redshift 間で Zero-ETL 統合をサポートしました。元々、Aurora Postgre、Aurora MySQL との統合機能を提供していましたが、RDS for MySQL もできるように拡張した形です。Zero-ETL 統合により、データパイプラインを構築せず、Redshift に数秒以内にレプリケーションできます。機械学習環境や、事業の大事な指標の可視化など、さまざまなユースケースをご検討いただけます。RDS for MySQL のバージョン 8.0.32 以降で利用できる点にご留意ください。 Amazon Cognito で、新たにメールを利用した MFA 機能のサポート Amazon Cognito で MFA 認証を行う際に、従来の SMS とワンタイムパスワード (TOTP) に加えて、メールを利用する方法をサポートしました。MFA 用の電話番号、専用デバイス、アプリケーションを用意するのが難しい場合に、このアップデートでメールが利用できるようになり、多くの組織でセキュリティ向上をしやすくなった形です。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 そういえば、 builders.flash で最近公開された記事をご紹介するのを忘れていることに気づきました。9月も半ばになってしまいましたが、今回の週刊生成AI with AWSで取り上げることにします。 Amazon Bedrockを活用したWebページ作成をアシストする仕組みの構築 ~ 株式会社ペライチによるページ作成AI機能の実装解説(株式会社ペライチ様) DifyとAmazon Bedrockを使って、簡単にセキュリティオペレーション自動化 ~Amazon GuardDuty検知結果の自動解析を例に~(株式会社サイバーエージェント様) AWSトレーニングを活用して、ノーコード実装の生成AIチャットボットを設計する(トレノケート株式会社様) Amazon Bedrockで企業会計基準チャットボットを作ってみた！~金融機関における生成AIを使った業務効率化~(Trust Base株式会社様) そうだ！生成AIにシステム開発の面倒ごとを手伝ってもらおう！ ビジネス向け生成AIアシスタント Amazon Q Businessをグラレコで解説 今回も盛りだくさんですね。お客様からの寄稿記事が増えているのはとても有り難いことだなと感じました。私自身もたくさんのお客様と、AWSを活用して生成AIの利活用に取り組むためのアプローチについて議論させていただくことがかなり増えてきましたので、ビッグウェーブを感じます。そんなお客様をご支援する「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、9 月 9 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「LangChain と Amazon DocumentDB のベクトル検索を使用した生成 AI チャットボットの構築」を公開 AWSは生成AIアプリケーションで頻繁に利用されるベクトル検索機能を、様々なサービスで提供しています。この記事ではAmazon DocumentDB(with MongoDB compatibility)をベクトルデータベースとして利用し、LangChainによって大規模言語モデル(LLM)に問い合わせを行う構造のチャットボットを開発する方法をご紹介しています。 ブログ記事「【開催報告】AWS Summit Japan 2024 物流業界向けブース展示 「倉庫ｘ生成AIからの物流DX」」を公開 6月20日21日に開催されたAWS Summit Japanにて、AWSジャパンの物流業担当チームがブース展示を行った「生成AIによる倉庫の在庫管理の高度化」について解説するブログを公開しました。実務に適用するためには色々と考慮しなければいけないことがありますが、生成AIで課題解決を行うアイデアの一例として参考にして頂けるのではないでしょうか。 ブログ記事「Amazon Bedrock を用いた Deltek 社の政府調達文書の質疑応答システム」を公開 海外の事例記事の和訳バージョンですが、AWS Generative AI Innovation Center(GenAIIC)がDeltekというお客様を支援した事例として興味深い点があります。GenAIICはDeltekさんに向けては政府調達文書に対するQ&Aを実行するRAGソリューションを提供しました。この事例の興味深い点は時系列の関係にある2つの文書に関するQ&Aを実現している点です。実践的なテクニックとしてご覧頂ける記事ですので、おすすめです。 ブログ記事「Stability AI の最高の画像生成モデルが Amazon Bedrock で使用可能に」を公開 先週の週刊生成AI with AWS で、Amazon BedrockでStability AIが開発した最新の画像生成モデルが利用できるようになったとお知らせしました。このブログ記事では、その話題をさらに深掘りする記事の和訳バージョンです。それぞれのモデルが、業界ごとにどういったワークロードに適用されうるのかを解説しています。 サービスアップデート Amazon Q Developer Agentの機能強化を発表 Amazon Q Developer Agentに大幅なアップデートが行われ、コード記述に関するアシスタンス機能がより自律的に動作できるようになりました。これまでは開発者が、Amazon Q Developerが推奨するコード記述計画を確認し、その内容を承認する操作を行う必要がありました。今回のアップデートにより、より素早く自律的な問題の解決が可能になりました。 Amazon Bedrock Knowledge Basesがクロスリージョン推論に対応 先日発表したAmazon Bedrockのクロスリージョン推論機能に続いて、Kowledge Basesでもクロスリージョン推論が可能になりました。トラフィックが急増した場合に、他のリージョンに転送して処理を行うことでサービスの継続性を維持することができます。クロスリージョン推論機能の利用は無料で、ユーザリクエストを受け付けたリージョン(転送元のリージョン)の単価に基づいて料金が発生します。 Amazon EC2 P5eインスタンスがリリースされ、EC2 Capacity Blocksを介した利用が可能に NVIDIAのH200 Tensor Core GPUを搭載したAmazon EC2 P5eインスタンスがリリースされました。H100を搭載したP5インスタンスと比較して1.7倍のGPUメモリと1.5倍のGPUメモリ帯域幅を備え、最も高い計算能力を要するワークロードに最適です。このインスタンスタイプは、インスタンスを予約できる仕組みのEC2 Capacity Blockを介してご利用頂けます。 Amazon SageMaker Inferenceでスティッキーセッションによるルーティングが可能に Amazon SageMaker Inferenceは、モデルをデプロイしてユーザからの推論リクエストをマネージドで処理できるようにする機能です。今回、リクエストのルーティング時にスティッキーセッションを利用できるようになりました。これを有効にすると、同じセッションの全てのリクエストが同じインスタンスにルーティングされます。機械学習アプリケーションは、そのセッションにおいて過去に処理した内容を再利用することで、レイテンシの短縮やユーザエクスペリエンスの向上に繋げることが可能です。 Amazon SageMaker HyperPodがAmazon EKS上でのジョブ実行をサポート Amazon SageMaker HyperPodは基盤モデルの学習インフラストラクチャの構築と最適化を容易にするサービスです。今回、SageMaker HyperPodを利用してKubernetesベースのワークロードの実行・管理が可能になりました。MLワークフローのオーケストレーションにKubernetesを利用している場合に便利な機能です。 Container InsightsがEKSで稼働するSageMaker HyperPodノードの可視化に対応 Amazon CloudWatch Container Insightsを利用して、Amazon EKS(Elastic Kubernetes Service) で稼働するSageMaker HyperPodのノードの情報を可視化できるようになりました。分散トレーニングではノード異常への対応が重要です。この機能を利用すると異常が発生したノードを特定し、迅速な対応が可能になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本記事は、2024年8月16日に公開された ” New research shows AWS is the cloud provider of choice for SQL Server ” を翻訳したものです。 2024 年の IDC Infobrief – Running SQL Server Workloads in the Cloud によると、 Microsoft SQL Server ユーザーの大多数が、主要なクラウドプロバイダーとして AWS を選択したと報告されています 。実際、データによると AWS は最も選択されたクラウドプロバイダー (52%) で、次の 6 つのクラウドプロバイダーを合わせた数を上回っています。 Figure 1. IDC Infobrief – Running SQL Server in the cloud 組織がクラウドコンピューティングを継続的に取り入れるにつれ、SQL Server などのミッションクリティカルなワークロードをクラウドに移行し、実行する必要性が高まっています。SQL Server のユーザーは、より優れた拡張性、パフォーマンス、可用性を低コストで実現するため、クラウドへの移行を検討しています。SQL Server のユーザーがクラウドへの移行を進める際、クラウドプロバイダーの選択と、そのプロバイダーを使った SQL Server のデプロイ方法を選ぶ必要があります。 SQL Server ワークロードを運用し、最適化するための適切なクラウドプロバイダを選ぶ際、Amazon Web Services (AWS) が圧倒的なリーダーとして浮かび上がります。2008 年から他社に先駆けて、AWS は何十万もの顧客の SQL Server ワークロードをリホスト、リプラットフォーム、リファクタリングするのを支援してきました。顧客は以下の理由から、SQL Server ワークロードを AWS に移行、最適化、モダナイズし続けています。 総所有コスト (TCO) の削減 : ライセンスからインフラストラクチャまで、AWS は SQL Server ワークロードの実行コストを削減することに注力しています。たとえば、お客様は無料の AWS Optimization and Licensing Assessment (AWS OLA) を通じて、SQL Server ライセンスコストの平均 45% を節約できます。 AWS Compute Optimizer を使えば、適切なサイズ設定によりインフラストラクチャコストを最大 25% 削減でき、SQL Server エディションのダウングレード推奨により、ライセンスコストを最大 73% 削減できます。また、お客様は Amazon Relational Database Service (Amazon RDS) などの管理サービスを利用することで、年間データベースコストを 34% 削減できます。 柔軟なライセンスオプション : AWS はソフトウェアライセンスの販売ビジネスを行っていません。代わりに、柔軟なライセンスオプションを提供することで、お客様のライセンスニーズを削減しようとしています。お客様は、既存の投資を最大限に活用するために自身のライセンス (BYOL) を持ち込むか、AWS がライセンスコンプライアンスの管理を行いながら、従量課金制のライセンス込み (LI) オプションを選択して、ビジネスに専念することができます。 データベースのモダナイゼーションによるイノベーションの解放 : Microsoft の制約が多いライセンスモデルから解放されたいお客様向けに、AWS は 目的別のデータベース を幅広く提供し、アプリケーションアーキテクチャを再構築することを可能にしています。 Amazon Aurora などのサービスは、従来のデータベースの 1/10 のコストで商用レベルのパフォーマンスと可用性を提供します。 使いやすい体験 : AWS は、SQL Server ワークロードの実行と管理のための、シンプルで統合された一貫したエンドツーエンド体験を提供しています。たとえば、 AWS Launch Wizard for SQL Server などのサービスを使用すると、サイズ設定、構成、デプロイメントの手順をガイド付きで進めることができ、クラウド上での SQL Server 環境の構築がスムーズになります。データベースの自己管理にあまり時間を割きたくないお客様向けに、AWS は Amazon RDS for SQL Server を提供しており、差別化されないデータベースタスクをオフロードできるようにしています。つまり、AWS はお客様の利便性向上に向けて常に機能改善を重ねており、2023 年には SQL Server および Windows Server ワークロードを AWS 上で評価、移行、管理、モダナイズするための 108 の新機能 を発表しました。 最も高性能なインフラストラクチャ : AWS は、SQL Server ワークロードを実行、最適化、モダナイズするための、最も安全で広範囲に渡り、信頼性の高い グローバルクラウドインフラストラクチャ を提供しています。AWS クラウドは、34 の地理的リージョンに 108 のアベイラビリティーゾーンを備え、さらに 18 のアベイラビリティーゾーンと 6 つの AWS リージョンが発表されています（訳注 : この文章の数値は2024年9月17日時点で最新のものです。原文が書かれた時点からマレーシアリージョンが一般提供されたため、原文の数値とは異なっています）。AWS は、クラウド上での Microsoft アプリケーションをサポートする 16 年の実績があり、SQL Server ワークロードを実行するための実証済みのクラウドプロバイダーです。 セキュリティの強化 : AWS は、アプリケーションとワークロードを構築、移行、管理するための、最も安全なグローバルクラウドインフラストラクチャとして設計されています。これは、 300 を超えるセキュリティサービスと機能 、そして、政府、医療、金融サービスなどの極めてセキュリティ要件の高い組織を含む、数百万のお客様からの信頼に裏付けられています。 「AWS におけるユニークなセキュリティ文化がどのように違いを生み出しているか」 をご覧ください。 セルフマネージドまたはマネージドモデル AWS では、お客様を第一に考え、常にお客様の具体的なニーズから逆算して取り組んでいます。SQL Server のデプロイオプションとして、 Amazon Elastic Compute Cloud (Amazon EC2) 上のセフルマネージドモデルと、 Amazon RDS for SQL Server のマネージドモデルを提供しています。 Amazon EC2 上のセルフマネージド SQL Server 。Amazon EC2 上で SQL Server を実行すると、アプリケーションを変更することなく、既存の SQL Server ワークロードを AWS に移行できます。このレポートによると、オンプレミスからの移行が容易であること、ソフトウェアライセンスの移行ができること、また、オペレーティングシステム (OS) へアクセスして自己管理できることにより、Amazon EC2 上の SQL Server ユーザーは高い満足度を示しました。 Salesforce は、オンプレミスの SQL Server データベースを Amazon EC2 上にリホストすることで、AWS 上にデータ層をデプロイしました。Salesforce のソリューションで最も重要な部分は、Marketing Cloud のデータ層の中核を成す大規模な SQL Server のデプロイメントです。 Salesforce は、アベイラビリティーゾーンが堅牢で高可用性であることを確認し、AWS を使用して SQL Server をデプロイすることで、データレジデンシーの規制のある新しい地域にも迅速に展開できるようになりました。新しいデータセンターをローカルで設置するのに1年かかっていたところを、Salesforce は AWS を使用して 4 〜 6 週間で展開できるようになりました。Salesforce は現在、デジタル市場の変化する需要により適切に対応できるようになり、インフラストラクチャに多くの時間とリソースを費やすことなく、迅速に革新し続けることができるようになりました。 マネージド Amazon RDS for SQL Server 。Amazon RDS for SQL Server を使えば、プロビジョニング、構成、パッチ適用、バックアップ、高可用性のデプロイメントなど、データベース管理タスクの重労働を軽減できます。これにより、チームはインフラストラクチャよりもイノベーションに注力できるようになります。オペレーティングシステムとデータベースのカスタマイズが必要なアプリケーションの場合は、 Amazon RDS Custom を提供しており、データベースのカスタマイズ権限が増え、 Bring Your Own Media (BYOM) を利用してライセンスコストを節約できます。このレポートでは、Amazon RDS ユーザーから非常に高い満足度が報告されています。99% のユーザーが高性能、高可用性、高スケーラビリティの点で期待を満たした、または上回ったと回答しました。オンプレミスからの移行後、Amazon RDS の総所有コストの低さも、ユーザーから報告された主な利点の 1 つです。 NN Investment Partners は、スケーラビリティの問題と増加するコストに対処するため、自社で管理していた SQL Server データベースから Amazon RDS for SQL Server に移行しました。これにより、データベースコストが 50% 削減され、エンジニアリングチームはデータベース管理ではなくイノベーションに集中できるようになりました。さらに、Amazon RDS への移行により、柔軟性が向上し、コスト配分が改善され、セキュリティが強化されました。最終的に、NN Investment Partners は将来の成長と競争力の向上に向けた体制を整えることができました。 目的別データベースによる SQL Server のモダナイズ Microsoft SQL Server から Amazon Aurora のような目的別データベースにモダナイズすることで、高額な Microsoft SQL Server のライセンス料と厳しいライセンス条件を排除し、商用レベルのデータベースのパフォーマンスと可用性を 10 分の 1 のコストで実現できます。また、イノベーションのスピードを上げ、アジリティを高め、 SQL Server のサポート終了 を心配する必要がなくなります。 BMC Software  は、Microsoft SQL Server から Amazon Aurora に移行することでデータベースをモダナイズし、大幅なコスト削減と生産性の向上を実現しました。この移行により、AWS インフラストラクチャのコストが 42% 削減され、SQL Server のライセンス料が不要になり、データベースチームの生産性が 60 ～ 70% 向上しました。Amazon Aurora を使用することで、BMC のエンジニアリングチームはメンテナンスにかける時間が減少し、安定性、パフォーマンス、スケーラビリティの向上の恩恵を受けています。これらの変更により、BMC の Helix プラットフォームの顧客採用が促進され、収益が増加し、大幅な成長が見込まれています。 クラウド上での SQL Server の実行を開始する クラウドでの SQL Server ワークロードの実行に関する詳細については、こちらの IDC InfoBrief をご覧ください。また、今すぐ 無料の移行アセスメント を始めましょう。 AWS は他のクラウドプロバイダーよりも多くのサービスと、それらのサービス内の多くの機能を備えているため、既存のアプリケーションをクラウドに移行したり、想像できるほとんどすべてのものを構築したりするのが、より速く、簡単で、コスト効率が高くなります。Microsoft アプリケーションが目的のビジネス成果を実現するために必要なインフラストラクチャを提供します。Microsoft ワークロードの追加のガイダンスとオプションについては、 .NET on AWS と AWS Database ブログをご覧ください。移行とモダナイゼーションの取り組みをすぐに始めるには、 こちら からお問い合わせください。 TAGS: Amazon Aurora , Amazon RDS , RDS Custom , SQL Server , SQL Server Migration , SQL Server Modernization , SQL Server on AWS , SQL Server on EC2 Frank Wang Frank Wang は、カリフォルニアの Amazon Web Services (AWS) でエンタープライズ Microsoft ワークロードを支援するシニアプロダクトマーケティングマネージャーです。10 年以上の経験を持ち、プロダクトマーケティングとテクニカルライティングを専門としています。プライベートでは、航空愛好家であり、Real Madrid のサッカーファンです。 本記事は、 New research shows AWS is the cloud provider of choice for SQL Server を翻訳したものです。翻訳はソリューションアーキテクトの平良允俊が担当しました。

この記事は、2024 年 7 月 22 日に Alex Kassidis によって執筆された「 AWS Certification: Addition of new exam question types 」を翻訳したものです。 このたび、AWS 認定に 3 つの新しい種類の試験問題 (並べ替え、内容一致、導入事例) が導入されることをお知らせします。新しい種類の試験問題は、既存の択一選択問題や複数選択問題と組み合わせることで設問を読む時間を短縮し、重要な概念についての知識の検証を強化するよう作られています。このような新しい種類の問題は、まず AWS Certified AI Practitioner (AIF) と AWS Certified Machine Learning Engineer – Associate (MLA) に導入されます。このブログ投稿では新しい種類の問題についてのインサイトを共有し、受験準備に役立つ情報を提供します。 新しい種類の問題を追加する理由 並べ替え問題と内容一致問題を使用することで、択一選択問題や複数選択問題よりも、手順や組み合わせに関する知識を効率的に検証できます。導入事例問題では、あるシナリオについて複数の設問が提示されるため、設問ごとに新しいシナリオを読む必要はありません。並べ替え、内容一致、導入事例の各設問の点数は、択一選択問題や複数選択問題と同じです。試験では、新しい種類の問題が択一選択問題や複数選択問題と組み合わされて提示されます。 新しい質問の作成にご協力いただいた、Blackbook.ai の AI/ML コンサルタントの Sean Jude Lyons 氏は、次のように述べています。「並べ替え問題、内容一致問題、導入事例問題では、丸暗記では確認できないような知識を検証できます。受験者は現実世界の問題を解決するためにクリティカルシンキングを行い、自身の知識を応用する作業を行っていることに気付くでしょう。試験に使用される導入事例は、現実の課題をシミュレートするものです。受験者は複雑な問題に取り組み、クリティカルシンキングを適用し、効果的なソリューションを生み出す必要があります」 新しい種類の問題が追加されても、試験に大きな変更はありません。試験問題の総数と標準的な制限時間についての変更点はありません。スコアレポートには、合格または不合格の結果、ブループリント分野別のパーセンテージスコア、分野別のコンピテンシー評価が引き続き記載されます。問題種類別のパフォーマンスに関する情報は提供されません。 これらの新しい種類の問題の受験に関するデモは、試験配信プロバイダーの Pearson VUE を通じて体験できます。AWS 試験デモにアクセスするには、Pearson VUE の Amazon Web Services (AWS) 試験プログラムのページ をご覧ください。ページの [関連リンク] セクションに移動し、[AWS 試験デモ] を選択します。 新しい種類の問題に関するフィードバックは、試験中に各試験問題の左上隅に表示される [コメント] フィールドで提供できます。また、試験終了時のアンケートで全般的なフィードバックを提供することもできます。 予定される内容: 新しい種類の問題 並べ替え問題 並べ替え問題では、一連のステップまたは選択肢のリストを論理的な順序で並べる必要があります。指定されたタスクを完了するための手順について、3～6 個の選択肢の中から、ドロップダウンリストを使用して正しい順序で選択します。 設問によっては、すべての選択肢を使用します。一部の選択肢のみを使用する設問もあります。設問の指示には、選択して並べ替える必要がある選択肢の数が記載されます。設問に対する点数を得るには、正しい選択肢をすべて選び、正しい順序に並べる必要があります。 並べ替え問題のサンプルについてお客様からいただいたフィードバックをいくつかご紹介します。 「並べ替え問題では、択一選択問題の各選択肢の違いを見つける手間が省けると思いました。読解力よりも技術的な知識に重点が置かれています」 「並べ替え問題の場合、トピックに関する十分な知識が必要です。択一選択問題の場合、トピックに関して十分な知識がなくても、不正解の選択肢を消去法で排除し、残った選択肢を選ぶことで正解を導き出せます」 「並べ替え問題の場合、効果は択一選択問題と同じかと思いますが、読まなければならないテキストの量が少なくなります。そのため問題が明確になり、答えやすくなります」 並べ替え問題の例は、次のとおりです。 ＜画像 1＞ 内容一致問題 内容一致問題では、3～6 個のプロンプトのリストと、そのプロンプトに対応する選択肢のリストが提示されます。ドロップダウンリストを使用して、各プロンプトに対する正しい選択肢を選びます。 設問によっては、各選択肢を使用するのは 1 回のみです。同じ選択肢を複数回使用する設問や、まったく使用しない選択肢がある設問もあります。設問の指示には、選択肢を使用する回数が記載されます。該当する設問に対する点数を得るには、各プロンプトの正しい選択肢を選ぶ必要があります。 内容一致問題のサンプルについてお客様からいただいたフィードバックをいくつかご紹介します。 「内容一致問題により、標準的な択一選択問題に少し多様性が加わります。読みながら解答を選択できる問題でした」 「内容一致問題は素晴らしいと思います。選択肢を比較する方法として優れています」 内容一致問題の例は、次のとおりです。 ＜画像 2＞ 導入事例問題 受験者は、シナリオを読んで、シナリオに関する複数の設問に解答します。導入事例の各設問は、同じシナリオに関するものです。導入事例の各設問は個別に採点されます。導入事例では正解した設問ごとに点数が得られます。 導入事例問題の例は、次のとおりです。 ＜画像 3＞ ＜画像 4＞ 試験の準備 新しい種類の問題への準備に役立つよう、AWS 公式 Exam Prep リソースで並べ替え、内容一致、導入事例の練習問題を提供しています。AWS Skill Builder の 4 ステップの試験準備プラン に沿って準備すると、試験準備で自信をつけることができます。すべてのプランに登録するか、ニーズに応じて特定のコースを選択して、受験当日に向けた準備ができます。 AWS 認定 に関するページを参照してください。

AWS Resilience Hub は AWS マネジメントコンソール上でアプリケーションの回復力（レジリエンス）を一元的に管理し改善できるツールです。AWS Resilience Hub ではレジリエンスの目標を定義して目標に対する耐障害性体制を評価し、AWS Well-Architected フレームワークに基づいた改善のための推奨事項を実装することができます。 AWS Resilience Hub は 耐障害性 と オペレーション の両方に関する推奨事項を提供します。オペレーションに関する推奨事項には、 Amazon CloudWatch Alarms 、 AWS Systems Manager Documents を利用した 標準作業手順 (SOPs) 、 AWS Fault Injection Service (FIS) を使用したカオス実験が含まれます。 SOP（標準作業手順）とはサービスの中断やアラームが発生した際に、アプリケーションを効率的に復旧させるために設計された具体的な手順のことです。AWS Well-Architected Framework の「 信頼性の柱 」で定義されている一般的なアンチパターンの1つは、アラート通知を受け取ったときにオペレーターが従うべき SOP がないことです。アラームが発生した際の処理の自動化は、自動的な是正措置、定義済みSOPの実行、エラーを起こしやすい手動作業の削減によってシステムのレジリエンスを向上させることができます。AWS Resilience Hub は 独自の SOP を定義できるカスタマイズ可能なテンプレートを提供 します。 このブログ記事では AWS Resilience Hub のオペレーションに関する推奨事項のテンプレート に基づいてイベントやインシデントに対する SOP の実行を自動化およびテストする方法について説明します。これを CI/CD パイプラインに組み込むことで、障害の検出や復旧が可能かどうかを継続的にテストすることもできます。 SOP の実行を必要とする状況を再現するには、AWS FIS のカオスエンジニアリング手法を使用できます。AWS FIS ではスコープが明確に定義されており、予期しない挙動が発生した場合にはロールバックが可能な安全メカニズムを備えた実験を行うことができます。 前提条件 このブログ記事で使用している例には、いくつかの前提条件があります。 AWS Auto Scaling Group の EC2 インスタンスを含むワークロードアーキテクチャ (Figure 1 を参照) AWS Cloud Development Kit (AWS CDK) については、 AWS CDK の開始方法 を参照してください AWS Resilience Hub を使用して AWS アカウントにデプロイしたワークロードアーキテクチャを定義し、評価します。AWS Resilience Hub を有効にする方法の詳細については、こちらの ブログ を参照してください アーキテクチャ Figure 1 – このブログで実験対象とするサンプルアーキテクチャ ワークフロー Figure 2 – ユーザーが実験を開始してから SOP が自動実行されてアラームが修正されるまでのワークフロー 自動化ソリューション AWS Resilience Hub は、アラーム、SOP、および FIS 実験に関する推奨事項を提供します。これらオペレーションに関する推奨事項が正常に実装されているかどうかは、お客様の責任においてテストします。AWS Resilience Hub における責任共有モデルの詳細については、ブログ Shared Responsibility with AWS Resilience Hub を参照してください。 重要なリソースの回復を自動化することをお勧めします。このブログでは、特定のアラーム状態に達したときに実装済みの SOP を実行する Amazon EventBridge の自動化について説明します。FIS 実験を使用してこの自動化をテストします。 カオスエンジニアリングはレジリエンス実験の高度なモードで、継続的なレジリエンスパイプラインでの自動実験を含みます。重要な原則は “早く失敗する” ことです。つまりレジリエンスの問題が本番環境で起こる前に、できるだけ早く発見して対処することです。カオス実験を継続的なレジリエンスワークフローに統合することで、レジリエンス実験に対するプロアクティブかつ反復的なアプローチが可能になり、レジリエンスが開発プロセスの不可欠な部分であることを確かにします。 アーキテクチャは Figure 1 に示すように、 Relational Database Service (RDS) をバックエンドに持つ Auto Scaling Group (ASG) 内の Amazon Elastic Compute Cloud (Amazon EC2) で実行されるアプリケーションを持ちます。 この例では CPU 使用率が高くなった場合の応答を自動化します。これが役に立つユースケースを考えてみましょう : e コマース Web アプリケーションは Web サーバーの ASG を min(最小)/desired(希望) = 1、max(最大) = 2 に設定しており、スケーリングポリシーは平均 CPU 使用率によって構成されています。例えばハイシーズンのイベントのようにユーザーからのリクエストが急増した場合、ASG は最大キャパシティである 2 に達しますが、新しいユーザーがまだアプリケーションに接続できないままだとすると、これは十分ではありません。 お客様のオンコールチームが問題を調査し、ASG の最大値を変更するという決定を下すまでには時間的なギャップがあります。この間に新しいユーザーからの接続は途絶え、ビジネスの財務や評判に影響が生じます。SOP を用いてこのメカニズムを自動化することにより、この時間的なギャップを埋めることができます。アラームがトリガーされることでカスタマーチームが追加調査の必要性に気づくことができるからです。 オペレーションに関する推奨事項の実装 AWS Resilience Hub のオペレーションに関する推奨事項の3つの領域 全てについて自動化を実装します。 2 つのアラーム AWSResilienceHub-SyntheticCanaryInRegionAlarm_2021-04-01 AWSResilienceHub-AsgHighCpuUtilizationAlarm_2020-07-13 1 つの SOP AWSResilienceHub-ScaleOutAsgSOP_2020-07-01 1 つの FIS 実験 AWSResilienceHub-InjectCpuLoadInAsgTest_2021-09-22 オペレーションに関する推奨事項の実装の詳細については、ブログ Measure and Improve Your Application Resilience with AWS Resilience Hub を参照してください。 Amazon EventBridge を使用して自動化を行うために、以下の AWS CloudFormation テンプレートを作成してこのリソースをプロビジョニングしました。この自動化により、複合アラーム ”AsgMaxCapacityReachedAndAsgHighCPUAlarm” がトリガーされて “アラーム中” 状態になったときに、SOP “AWSResilienceHub-ScaleOutAsgSOP_2020-07-01”が開始されます。 AWSTemplateFormatVersion: '2010-09-09' Description: CloudFormation template for EventBridge rule 'arh-alarm-asg-cpu-triggered' Parameters: AlarmTriggerArn: Type: String Description: Arn of the Alarm that will trigger this Event SSMTemplateAssumeRole: Type: String Description: An ARN of the role that SSM is going to assume SSMTemplateASGName: Type: String Description: Auto scaling group name (for the SSM Template) Resources: AmazonEventBridgeInvokeStartAutomationExecutionPolicy: Type: AWS::IAM::ManagedPolicy Properties: Description: Policy for the Amazon EventBridge Invoke Start Automation Execution ManagedPolicyName: !Join ['-', ['AWSResilienceHub-EventBridge_Automation_Policy', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref "AWS::StackId"]]]]]] Path: '/service-role/' PolicyDocument: !Sub '{ "Version": "2012-10-17", "Statement": [ { "Action": "ssm:StartAutomationExecution", "Effect": "Allow", "Resource": [ "arn:${AWS::Partition}:ssm:${AWS::Region}:*:automation-definition/AWSResilienceHub-ScaleOutAsgSOP_2020-07-01:$DEFAULT" ] }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "${SSMTemplateAssumeRole}", "Condition": { "StringLikeIfExists": { "iam:PassedToService": "ssm.amazonaws.com" } } } ] }' AmazonEventBridgeInvokeStartAutomationExecution: Type: AWS::IAM::Role Properties: RoleName: !Join ['-', ['AWSResilienceHub-EventBridge_Automation', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref "AWS::StackId"]]]]]] Description: Amazon EventBridge Invoke Start Automation Execution Role AssumeRolePolicyDocument: Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: events.amazonaws.com Version: "2012-10-17" MaxSessionDuration: 3600 Path: '/service-role/' ManagedPolicyArns: - !Ref AmazonEventBridgeInvokeStartAutomationExecutionPolicy EventRuleArhSop: Type: AWS::Events::Rule Properties: EventBusName: default EventPattern: source: - aws.cloudwatch detail-type: - CloudWatch Alarm State Change detail: alarmName: - !Ref CloudWatchCompositeAlarmAsgMaxCapacityReachedAndAsgHighCPUAlarm state: value: - ALARM Name: !Join ['-', ['arh-alarm-asg-cpu-automation', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref "AWS::StackId"]]]]]] State: ENABLED Targets: - Id: Id5b81de31-a5ef-42e2-90de-1fc8348b3229 Arn: !Sub "arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:automation-definition/AWSResilienceHub-ScaleOutAsgSOP_2020-07-01" RoleArn: !GetAtt AmazonEventBridgeInvokeStartAutomationExecution.Arn Input: !Sub '{"Dryrun":["false"],"AutoScalingGroupName":["${SSMTemplateASGName}"],"AutomationAssumeRole":["${SSMTemplateAssumeRole}"]}' CloudWatchAlarmAsgMaxCapacityReached: UpdateReplacePolicy: "Retain" Type: "AWS::CloudWatch::Alarm" Properties: ComparisonOperator: "GreaterThanThreshold" TreatMissingData: "missing" ActionsEnabled: true Metrics: - Label: "AsgMaxCapacityReached" Id: "e1" ReturnData: true Expression: "IF(m1 >= m2, 1, 0)" - ReturnData: false MetricStat: Period: 120 Metric: MetricName: "GroupInServiceInstances" Dimensions: - Value: !Ref SSMTemplateASGName Name: "AutoScalingGroupName" Namespace: "AWS/AutoScaling" Stat: "Average" Id: "m1" - ReturnData: false MetricStat: Period: 120 Metric: MetricName: "GroupMaxSize" Dimensions: - Value: !Ref SSMTemplateASGName Name: "AutoScalingGroupName" Namespace: "AWS/AutoScaling" Stat: "Average" Id: "m2" AlarmName: !Join ['-', ['ARH-AsgMaxCapacityReached', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref "AWS::StackId"]]]]]] EvaluationPeriods: 1 DatapointsToAlarm: 1 Threshold: 0 CloudWatchCompositeAlarmAsgMaxCapacityReachedAndAsgHighCPUAlarm: UpdateReplacePolicy: "Retain" Type: "AWS::CloudWatch::CompositeAlarm" Properties: ActionsEnabled: true AlarmName: !Join ['-', ['ARH-AsgMaxCapacityReachedAndAsgHighCPUAlarm', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref "AWS::StackId"]]]]]] AlarmRule: !Sub 'ALARM("${CloudWatchAlarmAsgMaxCapacityReached}") AND ALARM("${AlarmTriggerArn}")' CodeBlock 1 – Amazon EventBridge で自動化をセットアップするための AWS CloudFormation スタック オペレーションが停止した場合にすぐに復旧できるように、事前に SOP を準備、テスト、評価する必要があります。これには FIS 実験が役立ちます。このシナリオでは AWS Resilience Hub が推奨する SOP を使用しています。また AWS Resilience Hub が推奨する FIS 実験を使用することで、この SOP を実行した場合の仮説検証を行うこともできます。このユースケースでは Auto Scaling キャパシティが最大値に達したときに、Amazon EventBridge rule を通して呼び出される SOP の自動実行もテストします。 仮説 EC2 Auto Scaling と SOP の自動化のおかげで、EC2 インスタンスの CPU 使用率が全体的に高くなった場合でもアプリケーションのパフォーマンスに悪影響をおよぼすことはないと予想します。Web アプリケーションは継続してアクセス可能で、顧客はサービスの利用を中断されることはほとんどありません。 アラーム、SOP、FIS 実験、Amazon EventBridge rule がすべて実装されたら、自動化されていることを実験により確認します。仮説に基づくと、この実験では次のことが確認できるはずです。 FIS 実験では Auto Scaling Group に CPU 負荷を注入します CloudWatch Alarm “AWSResilienceHub-AsgHighCpuUtilizationAlarm” は “アラーム中” に変わるはずです Auto Scaling は 負荷を管理するために新しいインスタンスを起動して開始します FIS 実験は Auto Scaling Group にもう一度 CPU 負荷を注入します Amazon EventBridge がこのイベントを処理し SOP “AWSResilienceHub-ScaleOutAsgSOP_2020-07-01” を起動します SOP は Auto Scaling Groupをスケールアウトして EC2 インスタンスを追加します 実験とSOPの両方が正常に完了します 事前チェック まず最初に AWS マネジメントコンソールの EC2 セクションで Auto Scaling Group の値とアプリケーションで実行しているインスタンスの数を確認しましょう。 Figure 3 – 元の Auto Scaling Group のキャパシティの値 Figure 4 – 元の 実行中 EC2 インスタンスの数は 1 つ 実験する ここで上記の仮説をテストするために、AWS Resilienc Hub が推奨する AWS Fault Injection Service (FIS) 実験 “AWSResilienceHub-InjectCpuLoadInAsgTest_2021-09-22” を開始します。 Figure 5 – FIS 実験の実行 CloudWatch コンソールでアラーム “AWSResilienceHub-AsgHighCpuUtilizationAlarm” が “アラーム中” 状態に遷移したことがわかります。これは CPU 使用率が設定されたしきい値を超えたことを示しています。これにより Auto Scaling Group の動的スケーリングがトリガーされ、Auto Scaling Group で 2 つのインスタンスが実行されていることがわかります。 Figure 6 – CloudWatch Alarm の状態が変化 Figure 7 – 2 つの実行中 EC2 インスタンス Figure 8 – Auto Scaling Group (ASG) の新しい値 実験が終了し、2 つのインスタンスが実行され、アラームが “OK” 状態になりました。 再び同じ実験を実行すると、CloudWatch コンソール画面で CloudWatch Alarm が “アラーム中” 状態に遷移していることがわかります。これは CPU 使用率が設定されたしきい値を超えていることを示しています。さらに、2 番目のアラーム “ARH-AsgMaxCapacityReached” も “アラーム中” 状態になっていることがわかります。これは Auto Scaling Group の最大キャパシティに達したことを示しています。これにより Amazon EventBridge rule が正しく実行されているかどうかを確認できます。このルールは前述のアラームを組み合わせた複合アラームに基づいています（Figure 9 にも表示）。 Figure 9 – CloudWatch Alarm の状態変化 (2 回目の実験) Figure 10 – Amazon Eventbridge rule が正しくトリガーされている 結果の検証 Amazon EventBridge コンソールのモニタリング タブから、Amazon EventBridge rule がトリガーされ呼び出しが成功していることを確認できます。これにより AWSResilienceHub-ScaleOutAsgSOP_2020-07-01 SOP がターゲットとして自動実行されるはずです。 Systems Manager (SSM) Automations 機能から SOP が正常に完了したことがわかります。Amazon Eventbridge による自動化がなければ、FIS HighCPU 実験からの復旧にはこの SOP を手動で実行することになります。 Figure 11 – 2回目の FIS 実験の後、SOP が正常に実行されている Auto Scaling Group 自体に新しい値が設定されているか、また現在実行中の EC2 インスタンスの数を確認してみましょう。 Figure 12 – 新しい ASG キャパシティの値 Figure 13 – EC2 インスタンスが追加され合計 3 つになっている ご覧のとおり、Auto Scaling Group の Desired capacity (希望するキャパシティ) と Maximum capacity (最大キャパシティ) の値が増加しています。これによって期待通り Auto Scaling Group はアプリケーションへインスタンスを追加しました。これは Auto Scaling Group のイベントでも確認できます。Auto Scaling Group アラームと SOP によってそれぞれ追加が行われています。 Figure 14 – Auto Scaling Group イベント CloudWatch Alarm の履歴を見てどのようなアクションや状態の変化が発生したかを確認することもできます。期待通りに状態が “OK” から “アラーム中” に移行したこと、SOP の実行によりアラームが “OK” に戻ったことを確認することが重要です。 Figure 15 – 実験において CloudWatch Alarm 状態が “OK” から “アラーム中” に変わって “OK” に戻る様子 (左図) と、インスタンスと最大キャパシティの数 (右図) FIS 実験に戻って、実験が正常に完了したことを確認しましょう。実験を終了し、仮説が完全に立証されたことを確認できます。 Figure 16 – AWS Resilience Hub に完了した実験が表示される 検証 これで当初の仮説と照らし合わせて検証できます。 FIS 実験で ASG に CPU 負荷を注入する FIS 実験が正常に実行されていることがわかります (Figure 11)。 Amazon CloudWatch Alarm がトリガーされてアラームの状態が変化したことを確認できます (Figure 15)。 CloudWatch Alarm “ASGHighCPUUtilization” が “アラーム中” に変わる Amazon CloudWatch Alarm がトリガーされてアラーム状態が変化したことを確認できます (Figure 15)。 Amazon EventBridge がこのイベントを処理し、SOP “ScaleOutAsg” を開始する Amazon EventBridge rule が実行されます (Figure 10)。 最大キャパシティに達した場合に SOP は Auto Scaling Group を スケールアウトしてEC2インスタンスを追加する Amazon EventBridge rule を実装する AWS CloudFormation スタックを使用して実現した自動化と、必要な変更が SOP で正常に行われたことの両方を仮説に沿って確認します。 SOP 実行の自動化は、手動操作なしで完了した SSM Document で確認できます (Figure 11)。 Auto Scaling Group と EC2 インスタンスの数は期待通りの結果になっています (Figure 12、13、14)。 実験とSOPの両方が正常に完了します SOP と FIS 実験の完了を確認できます（Figure 16 と Figure 11)。 CI/CD パイプラインでの実行 これを CI/CD パイプラインで実行したい場合は、これらすべてをオーケストレーションする AWS Step Functions を作成できます。ステートマシン図を以下に示します。 Figure 17 – ステートマシン まず、上記のオートメーションを作成します。 次に、オートメーションがデプロイされるまで待ちます。 デプロイが成功したら、FIS 実験を開始します。 Amazon EventBridge による自動化によりアラーム発生とAuto Scaling Group の最大キャパシティに基づいて SOP が開始され、問題を軽減します。 エラーが発生すると、Simple Notification Service (SNS) メッセージが送信され、ワークフローは失敗します。 テストがエラーなしで終了すると、成功が報告されます。 この AWS Step Functions を作成する AWS Cloud Development Kit (AWS CDK) のコード。 import * as cdk from 'aws-cdk-lib'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as stepfunctions from 'aws-cdk-lib/aws-stepfunctions'; export interface ArhBlogTestImportStackProps extends cdk.StackProps { } export class ArhBlogTestImportStack extends cdk.Stack { public constructor(scope: cdk.App, id: string, props: ArhBlogTestImportStackProps = {}) { super(scope, id, props); const iamRoleStepFunctionsRole = new iam.CfnRole(this, 'StepFunctionsRole', { path: '/service-role/', maxSessionDuration: 3600, roleName: 'arh-blog-StepFunctions-role-' + id, policies: [ { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: [ 'cloudformation:CreateStack', 'cloudformation:DeleteStack', 'cloudformation:DescribeStacks', ], Effect: 'Allow', }, ], }, policyName: 'cloudformation-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: [ 'cloudformation:CreateStack', 'cloudformation:DeleteStack', 'cloudformation:DescribeStacks', "cloudwatch:DescribeAlarms" ], Effect: 'Allow', }, ], }, policyName: 'cloudwatch-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: [ 'events:DescribeRule', 'events:DeleteRule', 'events:PutRule', 'events:PutTargets', 'events:RemoveTargets', ], Effect: 'Allow', }, ], }, policyName: 'eventbridge-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: [ 'fis:StartExperiment', 'fis:GetExperiment', ], Effect: 'Allow' }, ], }, policyName: 'fis-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: [ 'iam:CreatePolicy', 'iam:GetRole', 'iam:DetachRolePolicy', 'iam:GetPolicy', 'iam:CreateRole', 'iam:DeleteRole', 'iam:AttachRolePolicy', 'iam:PutRolePolicy', 'iam:PassRole', 'iam:ListPolicyVersions', 'iam:DeletePolicy', ], Effect: 'Allow' }, ], }, policyName: 'iam-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: 's3:GetObject', Effect: 'Allow', }, ], }, policyName: 's3-permissions', }, { policyDocument: { Version: '2012-10-17', Statement: [ { Resource: '*', Action: "sns:Publish", Effect: "Allow", }, ], }, policyName: 'sns-permissions', }, ], assumeRolePolicyDocument: { Version: '2012-10-17', Statement: [ { Action: 'sts:AssumeRole', Effect: 'Allow', Principal: { Service: 'states.amazonaws.com', }, }, ], }, }); iamRoleStepFunctionsRole.cfnOptions.deletionPolicy = cdk.CfnDeletionPolicy.RETAIN; const stateMachine = new stepfunctions.CfnStateMachine(this, 'StepFunctionsStateMachine', { definitionString: '{ \"Comment\": \"A description of my state machine\", \"StartAt\": \"CreateAutomationStack\", \"States\": { \"CreateAutomationStack\": { \"Type\": \"Task\", \"Parameters\": { \"StackName\": \"arh-blog-automation\", \"TemplateURL.$\": \"$.input.S3UrlToCloudformationStack\", \"Capabilities\": [ \"CAPABILITY_NAMED_IAM\", \"CAPABILITY_AUTO_EXPAND\" ], \"Parameters\": [ { \"ParameterKey\": \"AlarmTriggerArn\", \"ParameterValue.$\": \"$.input.AlarmTriggerArn\" }, { \"ParameterKey\": \"SSMTemplateAssumeRole\", \"ParameterValue.$\": \"$.input.SSMTemplateAssumeRole\" }, { \"ParameterKey\": \"SSMTemplateASGName\", \"ParameterValue.$\": \"$.input.SSMTemplateASGName\" } ] }, \"Resource\": \"arn:aws:states:::aws-sdk:cloudformation:createStack\", \"Next\": \"WaitForStackToBeReady\", \"Catch\": [ { \"ErrorEquals\": [ \"States.ALL\" ], \"Next\": \"DeleteAutomationStackOnFail\" } ] }, \"WaitForStackToBeReady\": { \"Type\": \"Wait\", \"Seconds\": 5, \"Next\": \"DescribeStacks\" }, \"DescribeStacks\": { \"Type\": \"Task\", \"Next\": \"StackDeploymentStatus\", \"Parameters\": { \"StackName.$\": \"States.ArrayGetItem(States.StringSplit($.StackId, \'/\'), 1)\" }, \"Resource\": \"arn:aws:states:::aws-sdk:cloudformation:describeStacks\", \"OutputPath\": \"$.Stacks[0]\", \"Catch\": [ { \"ErrorEquals\": [ \"States.ALL\" ], \"Next\": \"DeleteAutomationStackOnFail\" } ] }, \"StackDeploymentStatus\": { \"Type\": \"Choice\", \"Choices\": [ { \"Or\": [ { \"Variable\": \"$.StackStatus\", \"StringEquals\": \"REVIEW_IN_PROGRESS\" }, { \"Variable\": \"$.StackStatus\", \"StringEquals\": \"CREATE_IN_PROGRESS\" } ], \"Next\": \"WaitForStackToBeReady\" }, { \"Variable\": \"$.StackStatus\", \"StringEquals\": \"CREATE_COMPLETE\", \"Next\": \"StartExperiment\" } ], \"Default\": \"DeleteAutomationStackOnFail\" }, \"StartExperiment\": { \"Type\": \"Task\", \"Next\": \"WaitForExperimentToFinish\", \"Parameters\": { \"ClientToken.$\": \"States.UUID()\", \"ExperimentTemplateId.$\": \"$$.Execution.Input.input.ExperimentTemplateId\" }, \"Resource\": \"arn:aws:states:::aws-sdk:fis:startExperiment\", \"ResultPath\": \"$.Result\" }, \"WaitForExperimentToFinish\": { \"Type\": \"Wait\", \"Seconds\": 5, \"Next\": \"GetExperiment\" }, \"GetExperiment\": { \"Type\": \"Task\", \"Next\": \"ExperimentStatus\", \"Parameters\": { \"Id.$\": \"$.Result.Experiment.Id\" }, \"Resource\": \"arn:aws:states:::aws-sdk:fis:getExperiment\", \"ResultPath\": \"$.Result\" }, \"ExperimentStatus\": { \"Type\": \"Choice\", \"Choices\": [ { \"Or\": [ { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"pending\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"initiating\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"running\" } ], \"Next\": \"WaitForExperimentToFinish\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"completed\", \"Next\": \"Wait\" } ], \"Default\": \"SNSPublishOnError\" }, \"Wait\": { \"Type\": \"Wait\", \"Seconds\": 20, \"Next\": \"StartExperimentAgain\" }, \"StartExperimentAgain\": { \"Type\": \"Task\", \"Next\": \"WaitForExperimentToFinishAgain\", \"Parameters\": { \"ClientToken.$\": \"States.UUID()\", \"ExperimentTemplateId.$\": \"$$.Execution.Input.input.ExperimentTemplateId\" }, \"Resource\": \"arn:aws:states:::aws-sdk:fis:startExperiment\", \"ResultPath\": \"$.Result\" }, \"WaitForExperimentToFinishAgain\": { \"Type\": \"Wait\", \"Seconds\": 5, \"Next\": \"GetExperimentAgain\" }, \"GetExperimentAgain\": { \"Type\": \"Task\", \"Next\": \"ExperimentStatusAgain\", \"Parameters\": { \"Id.$\": \"$.Result.Experiment.Id\" }, \"Resource\": \"arn:aws:states:::aws-sdk:fis:getExperiment\", \"ResultPath\": \"$.Result\" }, \"ExperimentStatusAgain\": { \"Type\": \"Choice\", \"Choices\": [ { \"Or\": [ { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"pending\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"initiating\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"running\" } ], \"Next\": \"WaitForExperimentToFinishAgain\" }, { \"Variable\": \"$.Result.Experiment.State.Status\", \"StringEquals\": \"completed\", \"Next\": \"DeleteAutomationStack\" } ], \"Default\": \"SNSPublishOnError\" }, \"SNSPublishOnError\": { \"Type\": \"Task\", \"Resource\": \"arn:aws:states:::sns:publish\", \"Parameters\": { \"TopicArn.$\": \"$$.Execution.Input.input.SnsTopic\", \"Message.$\": \"$\" }, \"Next\": \"DeleteAutomationStackOnFail\" }, \"DeleteAutomationStackOnFail\": { \"Type\": \"Task\", \"Parameters\": { \"StackName\": \"arh-blog-automation\" }, \"Resource\": \"arn:aws:states:::aws-sdk:cloudformation:deleteStack\", \"Next\": \"Fail\" }, \"Fail\": { \"Type\": \"Fail\" }, \"DeleteAutomationStack\": { \"Type\": \"Task\", \"Parameters\": { \"StackName.$\": \"States.ArrayGetItem(States.StringSplit($.StackId, \'/\'), 1)\" }, \"Resource\": \"arn:aws:states:::aws-sdk:cloudformation:deleteStack\", \"Next\": \"Success\" }, \"Success\": { \"Type\": \"Succeed\" } } }', loggingConfiguration: { includeExecutionData: false, level: 'OFF', }, stateMachineName: 'arh-blog-statemachine-' + id, roleArn: iamRoleStepFunctionsRole.attrArn, tags: [ ], stateMachineType: 'STANDARD', tracingConfiguration: { enabled: false, }, }); stateMachine.cfnOptions.deletionPolicy = cdk.CfnDeletionPolicy.RETAIN; } } CodeBlock 2 – AWS Step Functions を 作成する AWS CDK スタック 上記の AWS CDK コードで作成されるステートマシンを実行するには、いくつかの入力を定義する必要があります。 AlarmTriggerArn — Resilience Hub が推奨したアラーム “AsgHighCpuUtilizationAlarm” の ARN SSMTemplateAssumeRole — SOP で作成された “AWSResilienceHubAsgScaleOutAssumeRole” の ARN SSMTemplateASGName — Auto Scaling Group の名前 (ARNではない) ExperimentTemplateId — 実行する FIS 実験の ID (この場合は AsgScaleOut) SnsTopic — 実験が失敗した場合にメッセージを送信する SNS トピック S3UrlToCloudformationStack — Amazon Simple Storage Service (S3) バケット内の CloudFormation ファイルの URL。上記の CodeBlock1 の AWS CloudFormation テンプレートは S3 のフォルダに保存する必要があります 例として、入力は以下のようになります。CDK コードを環境内で正しく機能させるにはこれを更新する必要があります。 { "input": { "AlarmTriggerArn": "arn:aws:cloudwatch:<region>:<accountid>:alarm:AWSResilienceHub-AsgHighCpuUtilizationAlarm-2020-07-13_arh-demo_arh-lab-workload-AutoScalingGroup-oYSKLDR6Vg21", "SSMTemplateAssumeRole": "arn:aws:iam::<accountid>:role/arh-sop-AWSResilienceHubAsgScaleOutAssumeRole-qWqL13hCgexP", "SSMTemplateASGName": "arh-lab-workload-AutoScalingGroup-oYSKLDR6Vg21", "ExperimentTemplateId": "EXT9Au6P89tSQXa", "SnsTopic": "arn of the topics", "S3UrlToCloudformationStack": "https://<bucketname>.s3.<region>.amazonaws.com/arh-eventbridge.yml" } } CodeBlock 3 – AWS CDK 入力（更新が必要） これで AWS Step Functions が作成されたので、パイプラインに統合できます。こちらのブログ “ Continually assessing application resilience with AWS Resilience Hub and AWS CodePipeline ” では、AWS Code Pipeline から StepFunctions をトリガーする方法について説明しています。 結論 よく理解され定義されたイベントへの対応を自動化することで、エンジニアはより生産的なタスクに集中できます。これにより例えば平均復旧時間 (MTTR) を改善したり、オンコール対応によるエンジニアリングリソースの疲弊を防ぐことによって、回復力の目標を達成することにもつながります。 リリースの頻度と CI/CD パイプラインのデプロイメント間隔に応じて、カオスパイプラインの範囲と期間を評価する必要があります。一般に Fault Injection Service 実験ではワークロードにおいて十分なインタラクション、データ、および実験条件を確保するために、実行時間を長くする必要があります。開発者の作業が遅くなるのを避けるため、これらの実験は CI/CD パイプラインの後段で、あるいは独自の専用パイプラインで実行する必要があります。通常のデプロイ用 CI/CD パイプラインを使用するか、専用の “カオスパイプライン” を使用するかに関係なく、AWS Resilience Hub の推奨事項は出発点として役立ちます。 本記事は 2024年8月22日に “ AWS Cloud Operations & Migrations Blog ” で公開された “ Automate Standard Operating Procedures (SOPs) execution with AWS Resilience Hub ” を翻訳したものです。翻訳はソリューションアーキテクトの三好史隆が担当しました。

こんにちは。カスタマーソリューションマネージャー( CSM )の髙木です。この記事はクラウド移行戦略で必要な移行パスを策定する移行パス策定ワークショップご紹介の続編となります。前回のブログ” 移行パス（クラウド移行戦略）をワークショップで策定する ” では、クラウド移行戦略における移行パス策定ワークショップの位置付けや、ワークショップの実施方法、効果をご紹介いたしました。これまで様々なお客様へ移行パス策定ワークショップ（Migration Path Workshop（MPW））をご提供させていただきましたので、今回はその中からお客様実施事例をいくつかご紹介させていただきます。 本ブログでは、「移行先」、「移行戦略」、「移行パス」はそれぞれ以下の定義で使用しています。 　移行先： パブリッククラウド、プライベートクラウド、SaaSといったシステムの移動先となる場所や環境のこと。 　移行戦略： システムを移行する際の具体的な手法のこと。AWSでは「Relocate」「Rehost」「Replatform」「Repurchase」「Refactor」「Retire」「Retain」の頭文字を取った 「7R」を移行戦略 として提唱しています。 　移行パス： 分岐条件を経て到着点に至るまでの経路のこと。自社固有の移行条件であったり、到達点として選択可能な移行先を定義するもの。 実際にワークショップで移行パスを策定されたお客様の事例を３つご紹介します。 　事例#１ ：移行先アーキテクチャの選定基準が曖昧で移行先選定方法に課題をお持ちのお客様 　事例#２ ：移行計画段階で移行パスを整理しようとされていたお客様 　事例#３ ：クラウド移行プロジェクトをどのように進めていけばよいか模索されているお客様 下図のお客様のお悩みの①～③が今回ご紹介するお客様のケースに当てはまるかと思います。 移行パスの選定基準はお客様個社の条件や制約があり、標準化された基準をそのまま当てることが難しいため、関係メンバーに集まっていただきワークショップ形式でのディスカッションを行うことで各社の環境に合った移行パスを策定できます。 移行パス策定事例 それでは本ワークショップを利用して移行パスを策定したお客様の事例を見ていきましょう。 [事例#１] 最初の事例はすでにクラウド移行を進められていたお客様の事例になります。 クラウド移行を進めているものの移行先選定基準が曖昧であったためいくつかの課題を抱えられており、社内で統一した基準として移行パスを策定することを目標にワークショップを実施しました。 お客様が抱えていた課題は以下になります。 ・業務部門がそれぞれ移行先を決めているため、移行先が全体最適化されていない ・リホストが最終ゴールとなっており、クラウドのメリットを十分に享受できていない ・可能性のあるすべての移行先の見積もりを行う必要があり、見積もり作業工数が大きい AWS側からご提供したサンプルの移行パスと分岐条件例を参考に、あらかじめ自社での分岐条件のアイデアを考えておいていただいた上でワークショップにご参加いただきました。 当日は、自社で選択可能な移行先の整理から始めて、各々持ち寄っていただいた分岐条件アイデアを最終移行先に至る分岐条件として取捨選択をしながら移行パスを整理していきました。 ワークショップを実施した結果、移行先選定のディシジョンツリーが可視化され、移行コスト以外の判断基準も組み込まれたことで移行先の選定基準の曖昧さがなくなり、統一された基準での選定が可能となりました。 また、選定基準が明確になったことで選定した移行先の見積もりのみとすることができ、見積もり作業工数の軽減につながった事もワークショップ実施効果の一つとなりました。 [事例#２] ２つ目の事例は、移行については既に知識をお持ちでこれから移行を行っていく計画段階のお客様の事例になります。 既存システムのクラウド移行計画を進めていらっしゃるお客様から、移行先選定のための社内標準となる移行パスを作成したいというご相談をいただき、本ワークショップをご提案させていただきました。 お客様自身で移行パスの作成を検討され始めているタイミングでしたので、メンバーが集まって集中して移行パスを作成する良い機会と捉えていただき、ワークショップ実施に至りました。ワークショップはオンライン形式での開催でしたが、事前に、自社で選択可能な移行先とそこに至る分岐条件を記載した移行パスのドラフト案を作成しておいていただき、当日はその資料をオンラインツールで画面共有しながら分岐条件の追加・修正、選定順序の見直し、自社特有の条件の取り込みを行い、移行パスの品質を上げていきました。 ワークショップを実施した結果、移行対象システムのオーナーである各システム担当者が移行先を選定する際に利用可能なレベルまで移行パスを向上させることができました。 曖昧な基準のまま移行先が選定されないようこの移行パスをガードレールとして使用することをお客様は想定されており、この移行パスで移行先が選定できないようなシステムが今後出てきた際には、システムの特性を確認し、条件の緩和や分岐の追加といった対応を行く運用とすることも決定しました。 ワークショップにメンバーが集まり、集中してディスカッションすることで、短時間で移行パスの品質を上げることができ、社内展開までの時間も短縮できました。 [事例#３] ３つ目の事例は、AWS及び、移行についての知識をそれほどお持ちでなく、どのようにクラウド移行を進めていくかを模索されていたお客様の事例になります。 オンプレ環境の社内システム更改のタイミングでクラウド移行を検討されていましたが、担当メンバーの方々はクラウド移行の経験が少なく、各サーバーをどのように移行したらよいかの検討段階からなかなか前に進められない状況でした。そこで、移行プロジェクトの基準とする移行パスを策定することを目的に、社内システムのマイグレーション担当リーダとメンバーの方々と本ワークショップを実施しました。1つ目の事例と同様に、自社での分岐条件のアイデアを事前に考えておいた上でワークショップにご参加いただきました。 この事例は上記２つの事例とは異なり、AWS、Azureといった具体的な移行先ではなく、リホストやリアーキといった移行戦略（7R) を選定するためのパスを作成しました。 ワークショップでは、各人に持ち寄っていただいた分岐条件のアイディアが本当に移行戦略(7R)選定に関係する条件かということディスカッションしながら、取捨選択し移行パスを整理していきました。ワークショップを通じて策定した移行パスを移行対象サーバーのリストと突き合わせることで、各サーバーでどの移行戦略(7R)を採用し移行を進めていくかを決めることが可能となり、プロジェクトを移行の検討段階から一歩前に進めることができました。 まとめ 本ワークショップは、基本的にはクラウドジャーニーのAssesmentフェーズでご利用いただくプログラムに位置付けていますが、その他のフェーズおいてでも、移行先選定の基準が曖昧だったり、移行を手探りで行っている状況で本ワークショップを実施していただくことで、お客様の状況に応じた移行先や移行戦略(7R)、特有の分岐条件も考慮した移行パスの策定もしくは策定の見直しをしていただいています。 クラウド移行に際して状況の異なるお客様の事例を３つご紹介させていただきましたがいかがでしたでしょうか。 移行パスが整理されていない状況のままクラウド移行を進めてしまうと様々な問題が発生するリスクが高まります。 事前に関係者の認識を合わせた形で移行パスを作成し、共通のルールで移行作業を進めていくことが大切です。 また、これまでのワークショップを通して、直面している課題に対して特定の人が考えた解決策よりも、関係者が一同に集まってディスカッションした解決策の方が共通認識を持って進められるという点で次のアクションにつながりやすいと感じています。今回ご紹介した事例に当てはまらないケースでもご支援が可能ですので、本ワークショップにご興味をお持ちのお客様は、担当営業へご相談ください。 ワークショップで移行パスを策定してクラウド移行を加速させていきましょう。 参考リンク 移行パス（クラウド移行戦略）をワークショップで策定する AWS ITトランスフォーメーションパッケージ ファミリー（ITX） マイグレーションを実現するために – 第 2 回 : 移行戦略と移行パスとは ? 著者プロフィール アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 髙木 昇 アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 服部 昌克

この記事は Introducing configurable TCP idle timeout for Gateway Load Balancer を翻訳したものです。 Amazon Web Service (AWS) Gateway Load Balancer (GWLB) は、サードパーティのファイアウォールアプライアンスをデータ経路に挿入できるマネージドな AWS サービスです。 GWLB は、サードパーティアプライアンスのデプロイ、スケーリング、管理を支援し、「Bump-in-the-Wire」デバイスとしてトラフィックをターゲットに透過的に渡します。顧客は、トラフィック検査のユースケースにおいて、GWLBターゲットとしてサードパーティのファイアウォールアプライアンスをデプロイします。詳細については、 GWLB ドキュメント を参照してください。 GWLBの設定可能なTCPアイドルタイムアウト機能を紹介します。この機能により、GWLB の Transmission Control Protocol (TCP) アイドルタイムアウトを60秒から6000秒の範囲で設定できるようになります。 この投稿では、この機能の基本と利用のベストプラクティス、および AWSマネジメントコンソール  と API を使用してセットアップする方法について説明します。 前提条件 以下のセクションでは、仮想プライベートクラウド ( VPC ) 、サブネット、 VPC ルーティングテーブルなどの基本的な AWS のネットワーキングサービスを理解していることを前提としています。また、 GWLB のターゲットとしてサードパーティのファイアウォールをセットアップする方法を理解していることも前提とします。 GWLB アーキテクチャの詳細については、 GWLB の投稿 を参照してください。 GWLB の TCP アイドルタイムアウトとは？ GWLB は、フローの最初のパケットを確認するとフローテーブルにフローエントリを作成します。 GWLB は、2 タプル、3 タプル、または 5 タプルのハッシュを使ってフローを定義し、フローのすべてのパケットをバックエンドターゲットの1つにルーティングします。 GWLBは、各フローエントリを1つのバックエンドターゲットアプライアンスに結びつけることで、トラフィックの対称性を維持します。このトラフィックの対称性は、トラフィック検査やファイアウォールのユースケースにおいて必要不可欠です。 GWLB は、そのフローのパケットが GWLB を通過する限り、フローをアクティブと見なします。フローのパケットが停止すると、そのフローはアイドルと見なされ、アイドルタイマーが開始されます。所定のアイドル時間が経過すると GWLB はフローテーブルからフローエントリを削除します。 なぜ GWLB に設定可能な TCP タイムアウトが必要か？ これまで、GWLB は固定のTCPアイドルタイムアウト値 (350秒) をサポートしていました。アイドルタイムアウト後に GWLB に到着するパケットは新しいフローと見なされ、別のターゲットに転送される可能性がありました。 しかし、多くのファイアウォールやレガシーデータベースなどのアプリケーションは、デフォルトの TCP アイドルタイムアウト値としてより長い時間が設定されています。 GWLB とアプリケーションのタイムアウト値の不一致により、アプリケーション側で長時間アイドル状態だったフローが GWLB のタイムアウトによって異なるターゲットに転送され、トラフィックフローの中断を引き起こす可能性があります。 GWLBの設定可能なTCPアイドルタイムアウト機能を使用すると、ファイアウォールやアプリケーションの TCP アイドルタイムアウト値を GWLB と合わせることができ、トラフィックフローの継続性を確保し、トラフィックの中断を減らすことができます。 Palo Alto Networks 、 Fortinet 、 Cisco 、 Check Point などのサードパーティのファイアウォールは、350 秒を超える TCP アイドルタイムアウト値をサポートしており、デフォルトの TCP アイドルタイムアウト値が 3600 秒に設定されていることもよくあります。このGWLB とターゲットアプライアンスの TCP アイドルタイムアウト値の不一致により、トラフィックが中断する可能性があります。図1a、図1b にて、トラフィック中断につながる構成例と一連の動作を示します。このシナリオでは、バックエンドのファイアウォールアプライアンスのTCPアイドルタイムアウト値はデフォルトの60分を使用している想定です。 図1a は、フローが最初に確立されたときの GWLB とバックエンドファイアウォールアプライアンスのフローテーブルを示しています。 図1a: 新規フロー確立時の GWLB とファイアウォールのフローテーブル [1] VPC – 1 にデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが、TCP フローを開始し、Availability Zone (AZ) – b の GWLB エンドポイント (GWLB-EP B) にデータを送信します。 [2] GWLB – EP Bはトラフィックをファイアウォール VPC にデプロイされた GWLB に送信します。 [3] GWLB はこのフローをフローテーブルに見つけられないため、新しいフローエントリを作成します。TCP アイドルタイムアウト値は 350 秒に設定されます。GWLB はこのフローのバックエンドターゲットとして T2 を選択します。 [4] GWLB は元のトラフィックを GENEVE トンネルにカプセル化し、このデータを T2 に送信します。 [5] T2はテーブル内に新しいフローエントリを作成し、TCP アイドルタイムアウト値を 3600 秒に設定します。 データフローが停止すると、GWLB の TCP アイドルタイムアウトがトリガーされます。図1bは、データフローが停止してから350秒後の GWLB とバックエンドファイアウォールのフローテーブルを示しています。 [6] Flow-1 の GWLB TCP アイドルタイムアウトが期限切れになります。この時点で、GWLB はフローテーブルからこのフローエントリを削除します。 [7] バックエンドのファイアウォールアプライアンスは、フローエントリをテーブルに保持します。アイドルタイマーは 3250 秒になります。 図1bは、送信元のEC2インスタンスが同じフローの他のパケットを送信したときの一連の動作を示しています。 図1b: トラフィックフローが再びアクティブになったときのGWLBとファイアウォールのフローテーブル [8] 350秒以上アイドル状態が続いた後、ソースのEC2インスタンスが同じフローの他のパケットを GWLB-EP B に送信します。 [9] GWLB-EP B はトラフィックを GWLB に送信します。 [10] GWLB はこのフローをフローテーブルに見つけられないため、GWLB はこのフローを新規のフローと見なし、新しいフローエントリ (Flow-2) を作成します。アイドルタイムアウトは 350 秒に設定されます。今回は GWLB のハッシュアルゴリズムによって T1 がこのフローのバックエンドターゲットとして選択されます。 [11、12] T1 はパケットを受信しますが、 TCP フローであるためパケットをドロップします。これは、ステートフルファイアウォールでは、TCP フローのトラフィックを同じファイアウォールアプライアンスに対称的にルーティングする必要があるためです。この場合、T1 はこのフローの TCP ハンドシェイクを見ていないため、このフローを拒否します。これにより、トラフィックが中断します。 ステップ [10] は、GWLB がクロスゾーンロードバランシングを有効にしていることを前提としています。ただし、クロスゾーンロードバランシングが無効で、同じAZに複数のファイアウォールアプライアンスがデプロイされている場合でも、ステップ [11] と [12] で説明した問題が発生する可能性があります。 設定可能なTCPアイドルタイムアウトをどのように使用するか? GWLB の IP リスナーに対して TCP アイドルタイムアウトを設定できます。この設定は IPv4 トラフィックと IPv6 トラフィックの両方に適用されます。 ステップ 1: GWLB リスナーの詳細を編集する GWLB の詳細ページで、 [Actions] を選択し、 [View listener details] を選択します (図 2 参照)。 図 2: GWLB リスナーの詳細 ステップ 2: TCP アイドルタイムアウト値を編集する GWLB の [Attributes] タブで、TCP アイドルタイムアウトの詳細を編集 [Edit] します (図 3 参照)。 図 3: TCP アイドルタイムアウトを編集する 希望の TCP アイドルタイムアウト値を入力し、変更を保存します (図 4 参照)。 図 4: TCP アイドルタイムアウト値を入力する 新しく導入された modify-listener-attributes アプリケーションプログラムインターフェイス (API) 呼び出しを使用して、TCP アイドルタイムアウト値を編集できます。 aws elbv2 modify-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:<Region>:<AWS Account ID>:listener/gwy/<GWLB name>/<GWLB ID>/<Listener ID> \ --attributes \ Key=tcp.idle_timeout.seconds,Value=3700 modify-listener-attributes API 呼び出しを使用する際は、TCP アイドルタイムアウト値をキーと値のペアとして指定する必要があります。 elbv2 CLI ドキュメントを参照して、サポートされているコマンドの完全なリストを確認してください。 ステップ 3: 新しい構成を確認する 図 5: GWLB IP リスナーの新しい TCP アイドルタイムアウトを確認する ステップ 4: Amazon CloudWatch メトリクスを使用して監視する GWLB は、タイムアウトしたフローの総数を監視できる新しい Amazon CloudWatch メトリクスをサポートするようになりました。 RejectedFlowCount と RejectedFlowCount_TCP メトリクスを使用して、拒否されたフローの総数と拒否された TCP フローの総数を監視できます (図 6 参照)。これらのメトリクスは、GWLB のフローテーブルが上限に達し、 GWLB がフローを拒否した場合にのみ増加します。GWLB の TCP アイドルタイムアウトは徐々に増やすことをお勧めします。 図 6: RejectedFlowCount メトリクスを使用した CloudWatch アラーム GWLB TCP アイドルタイムアウト値の設定に関する推奨事項 GWLB の TCP アイドルタイムアウトに非常に高い値に設定すると、GWLB はフローエントリをフローテーブル内でより長い期間アクティブに保ちます。そのため、GWLB のフローテーブルが大きくなります。これにより、GWLB のフローテーブルサイズを使い果たすリスクが生じます。このリスクを軽減するために、GWLB のフローテーブル内の使用可能なフロー数を示す AvailableFlowCount CloudWatch メトリクスを監視することをお勧めします。 長期実行フローのあるアプリケーションに関する推奨事項 このセクションでは、インライントラフィック検査のユースケースでトラフィックの中断を回避するために、GWLB の設定可能な TCP アイドルタイムアウト機能を使用する 3 つの推奨事項について説明します。 推奨事項 1: GWLB の TCP アイドルタイムアウト値を、ファイアウォールアプライアンスの TCP アイドルタイムアウト値よりわずかに高い値に設定することで、トラフィックの中断を回避できます。また、ファイアウォールアプライアンスが TCP セッションがタイムアウトしたときに TCP RST を送信するように設定することをお勧めします (サポートについてはファイアウォールベンダーに確認してください)。長期間アイドル状態が続く TCP フローにおいて、この設定より、バックエンドのファイアウォールターゲットがフローをタイムアウトさせることができます。バックエンドファイアウォールからの TCP RST により、クライアントの TCP セッションが適切に閉じられます。この構成により、クライアントデバイスやアプリケーションのコードを変更せずに、検査アーキテクチャを展開できます。 この構成は、TCP キープアライブをアプリケーションコード内に実装できない従来のアプリケーション、および Red Hat Enterprise Linux などの基盤となる OS のデフォルト設定を継承するアプリケーションに対して推奨されます。大規模なレガシーアプリケーションを抱えており、すべてのアプリケーション/クライアント/サーバーをアップグレードするためには長期間のメンテナンスウインドウが必要となる場合、この方法は実用的なアプローチです。 推奨事項 2: クライアント/サーバーの TCP アイドルタイムアウト値を、GWLB またはファイアウォールアプライアンスよりも低い値に設定します。これにより、クライアントまたはサーバーが、 GWLB またはファイアウォールアプライアンスでタイムアウトする前に、接続を適切に更新できるようになります。このアプローチでは、すべてのクライアント/サーバーを更新する必要があります。詳細については、 Implementing long-running TCP connections within VPC networking を参照してください。この方法は優れた解決策ですが、すべてのクライアント/サーバー/アプリケーションを更新する必要があります。 推奨事項 3: アプリケーション内で TCP キープアライブを実装します。これにより、クライアント/サーバーが TCP キープアライブを送信して TCP セッションを維持できるようになります。このオプションでも、アプリケーションを変更する必要があります。 表 1 にこれらの推奨事項の概要を示します。   必要な構成変更 作業量 推奨事項 1 GWLB タイムアウト値 > ファイアウォールのタイムアウト値に設定 低 GWLB のみ構成する必要あり。 推奨事項 2 クライアント/サーバーのタイムアウトを GWLB/ファイアウォールのタイムアウトより短く設定 高 すべてのクライアントまたはサーバーを更新する必要あり 推奨事項 3 アプリケーション内で TCP キープアライブを設定 高 すべてのアプリケーションを更新する必要があり 表 1 :推奨事項の概要 短期間のフローに関する推奨事項 アクティブなフローの総数は、GWLB の使用コストを決定する要素の 1 つです。TCP セッションが短期間で終了すると予想されるアプリケーションの場合、GWLB の TCP アイドルタイムアウト値を減らすことで、GWLB の使用量を最適化できます。このようなユースケースでは、GWLB の TCP アイドルタイムアウト値を予想されるセッション期間よりわずかに長い値に設定することをお勧めします。 このような要件は、一般的に、パトロールカー、救急車、軍用車両などのデバイスが、複数のセルラーネットワークやモバイルネットワーク事業者（MNOs）を使用して AWS にデータをストリーミングする場合に見られます。デバイスのセッションは、異なる MNOs 間を切り替えるたびに途切れ、アプリケーションコードが新しい TCP セッションを作成します。 留意事項 GWLB の既存のフローは、TCP アイドルタイムアウト値を変更しても影響を受けません。それらのフローのトラフィックは中断されずに続行されます。新しい TCP アイドルタイムアウトは、GWLB の新しいフローエントリにのみ適用されます。 TCP キープアライブは、GWLB の TCP アイドルタイムアウト値を更新します。 アイドルタイムアウト値は、IPv4 と IPv6 の両方に適用されます。 RejectedFlowCount_TCP メトリクスは、その値がゼロ以外の場合にのみ CloudWatch で利用可能になります。つまり、GWLB のフローテーブルがいっぱいになり、GWLB が TCP フローを拒否し始めた後にこのメトリクスを使用できるようになります。 結論 この投稿では、GWLB の TCP アイドルタイムアウト値を 60 秒から 6000 秒の範囲で設定できる新機能を紹介しました。コンソールと API を使用してこの機能を使用する方法を説明しました。さらに、長期間のフローと短期間のフローの両方に対するこの機能の使用に関するベストプラクティスと、環境に適した値を設定するために特定の CloudWatch メトリクスを監視する推奨事項についても説明しました。 この機能の詳細については、 ドキュメント をご覧ください。 この記事の著者は Milind Kulkarni と Ankit Chadha です。

6 月 20 日と 21 日の 2 日間にわたり、幕張メッセにおいて 13 回目となる AWS Summit Japan が開催され、会場では 3 万人以上、オンラインも合わせると過去最高となる 5 万人超の方の参加者を記録しました。本イベントでは 150 以上のセッションと 250 以上のブース展示が行われ、AWS の最新情報が共有されました。 物流業担当チームでは「倉庫ｘ生成AIからの物流DX」と題しまして、Amazon Bedrock をはじめ Amazon QuickSight、Amazon Location Service 等 を活用した高度な在庫管理に関するデモを行いました。多くのお客様にお立ち寄りいただき会話させていただく中で、生成AIに対する期待値の高さと倉庫の在庫管理に関する課題の大きさを感じました。本ブログではデモの内容とそれに使われたサービスやアーキテクチャについて解説いたします。 本デモは「生成AIってQAツール的な使い方では浸透してきているけど、基幹システムのような既存の仕組みとの連携という観点ではまだ進んでいないよね」、「生成AIを活用して業務改善しろ、と言われているけど具体的に何をやったら良いかわからない」という現状に対する一つの提案として企画がスタートしました。企画を進めるにあたり「こういった課題もあるんじゃないか」という形で発想が広がり、最終的なデモの形となりました。以下がデモの全体像となります。シナリオとしてドラッグストアの在庫倉庫をイメージしています。 以下がデモのアーキテクチャ図になります。倉庫在庫データを管理するため、ダミーの Warehouse Management System (WMS) を Amazon Aurora 上に構築し、WMSに対する操作を Amazon API Gateway で API として提供しています。WMS は、入出庫、在庫、ピッキング、棚卸などの倉庫業務を効率化・最適化するためのソフトウェアシステムで倉庫を扱う企業で広く利用されています。また、今回のシナリオでは倉庫在庫だけではなく店舗在庫も管理しています。店舗在庫の管理システムとしては Amazon Dynamo DB を利用しています。 デモのシナリオを順を追って説明します。 ① 入庫 工場で生産した製品を物流拠点となる在庫倉庫に入庫します。従来の倉庫では、それぞれの製品を在庫管理するために、バーコードやQRコード、RFID（Radio Frequency Identification）タグなどを貼り付けてあります。デモでは、RFIDの一種であるNFC（Near Field Communication）タグを使用して在庫管理を実現し、Android 端末のChromeブラウザに搭載されたWebNFC APIを利用したWebアプリケーションをNFCタグを読み取ることで、倉庫管理システムへの入庫登録処理が完了します。NFC は導入コストの関係から採用しましたが、読み取り速度や複数読み取りの要件があるケースでは少し使いづらいかもしれません。 こういった要件があるケースではカメラによるバーコード（QR含む）の一括読み込みや、RFIDタグの一種であるUHF帯タグが選択されます。読み取りのWebアプリケーションは Amazon CloudFront + Amazon S3 の静的ホスティングを利用しています。 入庫処理用の画面 ② 在庫確認（倉庫側） 倉庫側の在庫確認する仕組みとして Amazon QuickSight を利用しています。Amazon QuickSight は様々な業界やユースケースで利用可能なビジネスインテリジェンスツールです。デモは在庫数の割合や各拠点の在庫数の分布等をダッシュボードで表現しました。Amazon QuickSight はマルチデバイスに対応しているため、常設のモニタに KPI を投影したり、倉庫内を頻繁に移動する社員がモバイルデバイスで状況を確認したりと、幅広い活用が可能です。このようにダッシュボードを利用し、在庫切れリスクの早期発見、適正在庫数の維持、需要予測と備蓄計画の立案に活用いただけます。 また、Amazon QuickSight の大きな魅力はデータソースの選択肢が豊富なことです。AWS サービスである Amazon S3 や Amazon Redshift はもちろん、リレーショナルデータベースの Oracle や PostgreSQL、SaaS のデータプラットフォームである Snowflake など、様々なデータソースをサポートしています。今回は WMS の リレーショナルデータベースである Amazon Aurora をデータソースとして参照し、データベース内の入庫情報と出庫情報を基に、リアルタイムで在庫状況をダッシュボード上に表示しています。 ③在庫確認、発注指示（店舗側） 店舗のスタッフが店舗内の在庫状況を確認したり、倉庫に対して店舗への発注指示をするための仕組みとして Agents for Amazon Bedrock を活用したチャット用のWebアプリケーションを開発しました。今回はわかりやすくデモをお見せするために、簡略化して発注完了＝出荷完了としています。 この機能の実装にあたっては Agents for Amazon Bedrock を活用しています。Agents for Amazon Bedrock では「アクショングループ」という形で機能を定義しておくことで、Agent 経由で定義された機能を呼び出すことができます。 今回は事前に Agent が質問に応じて適切にアクションができるようアクショングループに以下5つの処理を登録しました。 倉庫に対する発注リクエストは、WMS の Amazon Aurora に アクセスして、発注希望数＜在庫数の場合は満たす場合は発注と倉庫在庫数の更新を行い、発注完了のメッセージと、発注番号を返す。発注希望数＞在庫数となる場合は、在庫が足りていないため発注不可を返す。 商品の情報確認リクエストは、WMS の Amazon Aurora にアクセスして商品情報を返す。 店舗在庫の確認リクエストは、店舗用の Amazon DynamoDB にアクセスして在庫情報を返す。 過去の発注履歴リクエストは、店舗用の Amazon DynamoDB にアクセスして発注履歴情報を返す。 発注番号をもとにした配送状況確認リクエストは、配送状況マップの URL を返す。 それぞれのアクションは各 AWS Lambda で実行されています。 自然言語で質問をすると、Agent が質問内容を解釈して、どのアクションを実行するのが適切か判断し、そのアクションの実行結果を返してくれます。 もし、アクションを実行するのに足りない情報がある場合(例えば、発注に関するリクエストが来た際に、商品名または、発注希望数の値が不足している場合)、必要な情報をユーザから収集します。 この仕組みにより、これまで店舗のスタッフが業務ごとに複数のインターフェースを使って作業を行っていたことが、1 つのインターフェースだけで完結することができます。 現在は発注処理を行うには、人が発注内容を確認して出荷処理を行うことが一般的ですが、Agents for Amazon Bedrock をうまく活用することで生成 AI によって発注内容の確認から出荷処理まで自動化することで省人化、出荷までのリードタイムの短縮化を実現できます。 また、発注完了後は、地理空間情報に関する処理を提供する Amazon Location Service によって、輸送状況をリアルタイムで確認することができます。AWS Summit Japan の会場である幕張メッセを倉庫とし、ドラッグストアである AWS 目黒オフィスまでの輸送をデモとして紹介しました。 輸送車のデジタコやモバイル端末から位置情報を取得し、Amazon Location Service のマップ上に表示させることで、渋滞など交通状況を踏まえた最適ルートを案内させることで輸送業務の最適化に繋げることができます。 まとめ このブログでは、AWS Summit Japan 2024 物流業界向けブースのデモ 「倉庫ｘ生成AIからの物流DX」の内容をご紹介しました。物流業界は2024年問題を始め解決すべき課題が山積しています。これら課題を解決する有力な手段が生成AIと考えます。今回のデモでお示したように、生成AIを活用した自然言語によるインターフェースで、デジタルに詳しくない作業員でも、簡単に在庫管理システム等を操作できるようになり、生産性の向上が期待できます。さらに生成AIは、使い方によってはレガシーシステムの刷新やシステム開発の効率化にも貢献できます。物流が抱える課題の解決に向けて、生成AIの活用を検討してみてはいかがでしょうか。 このブログは、デモを開発したソリューションアーキテクト （横山、宇加治、稲田、駒野、三宅、山本） が執筆しました。

Amazon DocumentDB (with MongoDB compatibility) は、 ヘルスケア 、 ゲーム 、 金融 など、さまざまな分野でモダンアプリケーションを構築するお客様にメリットをもたらします。フルマネージド型のドキュメントデータベースであり、柔軟性、スケーラビリティ、高パフォーマンス、高度な機能によってユーザー体験を向上できます。Amazon DocumentDB がサポートする JSON データモデルを利用する企業は、半構造化データへの対応により、 アプリケーション開発の高速化 とデータの 読み取り速度の向上 を実現できます。 ある推計によると、 非構造化データは企業の新規データの 80 ～ 90% を占める 可能性があり、構造化データをはるかに上回る速度で増加しています。この傾向は、 生成 AI の新しい機会によって加速されています。AWS のお客様は、この技術をどのように活用し、自社の豊富なデータに適用できるかについて、ますます関心を寄せています。多くのお客様は、ベクトルデータベースエンジンを使用して、レコメンデーションエンジンを実装したり、リッチメディアを検索したり、クエリのコンテキストと意味に合わせてより関連性の高い文書を取得したりすることを検討しています。 最近の Amazon DocumentDB でのベクトル検索サポート などの機能リリースまでは、ワークロードにベクトル検索機能を実現するには、企業はデータをマネージドデータベースサービスから別のベクトルデータベースエンジンやサービスに連携させる必要があり、アーキテクチャのコストと複雑さが増加していました。このようなアーキテクチャの変更により、アプリケーションがドキュメントとは別の場所にエンベディングを格納および取得する必要があるため、さらにコード変更が必要になります。 既存の Amazon DocumentDB クラスターでセマンティック検索機能を有効にすると、最新の機械学習 ( ML ) および生成 AI ( AI ) アプリケーションを容易に構築できます。Amazon DocumentDB でベクトル検索を使用し、Amazon Bedrock や Amazon SageMaker などの AWS ML サービス、OpenAI、Hugging Face、LangChain などのサードパーティサービスと連携できます。また、ベクトルを元のドキュメントに格納できるようになりました。この機能は、HNSW インデックスのサポートによってさらに強化され、低レイテンシーでベクトル類似度検索を実行し、高い関連性の結果を生成できるようになりました。 この記事では、エンベディングを Amazon DocumentDB に正しくロードした後、LangChain を使用して大規模言語モデル (LLM) にクエリを行うチャットボットを作成する例を示します。 LLM による検索補助生成 Retrieval Augmented Generation (RAG) を使用すると、基盤モデルの外部からデータを取得し、取得された関連データをコンテキストとしてプロンプトに追加することで、プロンプトを強化できます。これは、エンドユーザーに対話型の体験を提供できるチャットボットを構築する際に有用です。企業のナレッジベースやコンテンツから、ユーザーのリクエストに最も関連する情報を取得し、ユーザーのリクエストとともにコンテキストとしてバンドルし、LLM に送信して生成 AI レスポンスを取得するため、直感的なインターフェースを提供します。 この例では、LangChain の PyPDFDirectoryLoader を使用して、 Amazon DocumentDB Developer Guide の PDF バージョンを取り込みました。これを使用して、サービスの機能、使用法、ベストプラクティスについて質問できるチャットボットを作成しました。完全なソリューションは、 amazon-documentdb-samples GitHub リポジトリにあります。 Amazon DocumentDB にデータをロードする前に、コレクションに HNSW インデックスを作成します: collection.create_index([("vectorContent","vector")], vectorOptions= { "type": "hnsw", "similarity": "euclidean", "dimensions": 1536, "m": 16, "efConstruction": 64}, name="hnsw") IVFFlat とは異なり、HNSW にはトレーニングステップが関与しないため、初期データロードなしでインデックスを生成できます。 開発者ガイドを LangChain の RecursiveCharacterTextSplitter を使用して分割した後、 Amazon Titan Embeddings G1 Text model (amazon.titan-embed-text-v1) を使用してエンベディングを作成します。 embeddings = BedrockEmbeddings(model_id= "amazon.titan-embed-text-v1", client=bedrock_client) INDEX_NAME = "hnsw" vector_store = DocumentDBVectorSearch.from_documents( documents=docs, embedding=embeddings, collection=collection, index_name=INDEX_NAME, ) 最後に、 Anthropic Claude for Amazon Bedrock  を 推論エージェント として初期化し、ユーザーが要求したタスクを複数のステップに分割します。 llm = BedrockChat(model_id="anthropic.claude-3-sonnet-20240229-v1:0", client=bedrock_client) ソリューションをテストするために、 PromptTemplate を作成し、 RetrievalQA チェーンを使用して、HNSW インデックスから質問に関連するドキュメントを収集します。これらのドキュメントを使用して、次のスクリーンショットに示すように、質問に対する一意の回答を作成します。 クエリ、チャット履歴、コンテキストを引数として受け取る RAG の使用例、および Amazon DocumentDB での集約パイプラインを使用したベクトル検索 の方法については、完全なノートブックを確認できます。 サマリー Amazon DocumentDB のベクトル検索は、JSON ベースのドキュメントデータベースの柔軟性と豊富なクエリ機能と、ベクトル検索の強力な機能を組み合わせたものです。 LangChain のような強力なフレームワークと、 Amazon Titan Text Embeddings のようなテキストエンベディング、そして Amazon Bedrock 経由でアクセスできる Anthropic の Claude 3 のような基盤モデルを使うことで、セマンティック検索体験、商品レコメンデーション、パーソナライゼーション、チャットボット、不正検知、異常検知などの ML と生成 AI ソリューションを構築できます。 既存のワークロードでベクトル検索を使い始めるには、 amazon-documentdb-samples GitHub リポジトリを参照し、この記事で説明した例をダウンロードしてください。 著者について この記事は、Andrew Chen, Cody Allen, Inderpreet Singh によって投稿された記事を翻訳したものです。 原文は こちら です。

生成 AI の普及が進む中で、活用方法に関する相談が増えています。 AWS のソリューションアーキテクトは、自分の能力を補完することを目的に、お客様に生成AIの活用を提案することがあります。本ブログでは、デザインの専門知識がないソリューションアーキテクトの私が、生成 AI を活用してデザインの能力を補い、ダッシュボードのデザインを改善した事例とその方法をご紹介します。対象のダッシュボードは AWS Summit 2024 Japan で展示した Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ です。 利用した生成 AI ソリューション AWS Japan のソリューションアーキテクトが利用した生成 AI ソリューションは aws-samples に公開している generative-ai-use-cases-jp (略称: GenU ) のチャット機能です。今回、生成 AI サービスは Amazon Bedrock、大規模言語モデル（ LLM : Large language Models ）は Claude-3-Sonnet を利用しました。 (図：generative-ai-use-cases-jp のチャット機能のユーザーインターフェース) generative-ai-use-cases-jp のソリューションは、 AWS アカウントに無料でデプロイできます。発生するコストは GenU で使用する AWS サービス料金のみです。 生成 AI を活用した UI デザイン改善の背景 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモにおいて、私の担当は、 Amazon Managed Grafana でダッシュボードを作り、 Amazon Monitron のデータを可視化することでした。AWS Summit 2024 Japan の開催2日前で残されたのは作業は、一部のデザイン改良です。さらにデザインを良くして、ご来場者の方々に関心を持っていただけるダッシュボードにしたいと考えていました。しかし、デザインの専門知識がない私が短期間で自力で改良することは困難だったので、生成AIの活用を試みました。 要件 今回のデザインの 要件は 3 つでした。 要件 1 (必須要件)：プロジェクトビューの 4 つの円グラフの項目数の合計が 36 。しかし、それぞれに相関関係がなく、異なる36色を設定する。 要件 2 (必須要件)：プロジェクトビューの 4 つの円グラフでは、多くの暗い色が設定されており、明るい色に変更して視認性を高める。 要件 3 (推奨要件)：遠くからでも見えるように、フォントサイズや背景色を見直し、タイトルやサブタイトルの可読性を高める。 生成 AI を活用したダッシュボードデザイン変更 Before / After 約 2 時間の作業で、生成 AI の活用により要件を満たすデザインに変更できました。 結果 要件 1 ：要件を満たす。 要件 2：プロンプト実行で重ねることで、要件をほぼ満たす。 要件 3：要件を満たす。 ダッシュボードのデザインは以下のように変わりました。 (図：ダッシュボード Before ) (図：ダッシュボード After ) 要件 1 : 4 つの円グラフで異なる 36 の色を設定する 要件 1 を実現するため、以下の手順を踏みました。改善前は、右上から時計回りで配置している「障害の原因」、「実施結果」、「障害モード」の 3 つの円グラフに同じ青色が設定されていました。さらに、「障害の原因」と「障害モード」には濃い緑色が使われていました。そこで、まず左上の「ステータス」円グラフの 5 色を手動で設定後、時計回りで「障害の原因」、「実施結果」、「障害モード」の 3 つの円グラフの配色を GenU で異なる色に変更しました。 (図: 要件 1 の実行順（オレンジの矢印） ) 右上の円グラフ「障害の原因」の色を変更するため、 GenU に以下のプロンプトを実行しました。ポイントは、生成 AI にグラフィカルデザイナーという明確な役割を与えたことです。また、「障害の原因」円グラフは最大 9 つの値を表示します。そこで、左上の円グラフ「ステータス」の色と被らない 9 色を提示するよう生成 AI に求めました。 あなたはグラフィカルデザイナーです。円グラフで9つの値を表示します。以下の条件を踏まえて、各値を見えやすい配色をRGBで考えてください。 ・背景色：黒（#000000） ・左隣に円グラフがあり、表示カラーはRGB(115, 191, 105)、RGB(255, 120, 10)、RGB(234, 234, 234)、RGB(250, 222, 42)、RGB(242, 73, 92)の5色で、これらの色と被らないこと。 ・円グラフ内に％表示する文字は白文字で、各値の配所により埋没しないこと。 その結果、 GenU から次のように円グラフ「ステータス」と異なる 9 つの RGB 値が提示されました。 (図：円グラフ「障害の原因」のプロンプトと実行結果 ) 時計回りに、各円グラフの配色提案のプロンプトを実行しました。 1 つ目の学びは、 Claude-3-Sonnet は、複数のプロンプト間の表現のゆらぎを吸収してくれることです。前回は、円グラフ「ステータス」を「左隣の円グラフ」と表現していましたが、今回は「円グラフ A 」と違う表現を使いました。このように表現が異なっていても、Claude-3-Sonnet は内容を正しく理解し、適切なプロンプトを返してくれました。 (図：円グラフ「実施結果」のプロンプトと実行結果 ) 円グラフ「障害モード」の配色についても、同様のプロンプトを実行しました。その結果、各円グラフの配色がユニークになり、要件 1 を実現することができました。 (図：要件 1 プロンプト実行後の円フラフの配色 ) 要件 2 : 明るい配色の円グラフにする 要件 1 の実現でユニークな色に設定はできましたが、一部の色の間に視認性に大きな差はありませんでした。また、暗めの色が多く採用されていたため、要件 2 (明るい配色) が未達です。そこで、円グラフの配色を明るい色を中心に変更することにしました。円グラフ「障害の原因」から時計回りに進み、同様の手順で実施しました。 (図：要件 2 の実行順 ) 下記のように要件 1 の実現で得られた配色において、明るい色は残しつつ、暗い色を変更するプロンプトを実行しました。 円グラフBは以下の4色を残して、再提案をしてください。 RGB(27, 156, 152) – 涼しげなターコイズブルー RGB(115, 194, 251) – 明るいスカイブルー RGB(226, 153, 186)- ライトピンク RGB(175, 175, 247) – 薄いラベンダー 2 つ目の学びは、 Claude-3-Sonnet が各円グラフのデータ項目数を把握しており、指定なしでも適切な色数を提案してくれたことです。 Claude-3-Sonnet は過去のプロンプトの内容を記憶しており、「円グラフ B 」と主語を明記することで、円グラフの構成を正確に判断しています。具体的には、円グラフ「障害の原因」は 8 つのデータ項目で、 4 色を残して 残りの色の変更をリクエストしました。各円グラフのデータ項目数は異なりますが、プロンプトには残す 4 色しか明記していません。しかし、 Claude-3-Sonnet は適切に 4 色の提案をしてくれました。 (図：円グラフ「障害の原因」のプロンプトと実行結果 2 ) 提案された色を確認し、目的の配色を得られるよう、繰り返しプロンプトを実行しました。要件 2 の実現には、プロンプトを何度も繰り返す必要があったため、 3 つの要件の中で最も時間がかかりました。また、 3 つ目の学びは、人間が異なる色と識別できる 36 色を設定することは、生成AIを使っても難しいことが分かりました。 (図：要件 2 プロンプト実行後の円フラフの配色 ) 要件 3：タイトルやサブタイトルの可読性を高める タイトルやサブタイトルの可読性を高めるために、ダッシュボードタイトルの白ラベルとプロジェクトビューなどのグレーラベルの配色について GenU に意見を求めました。ダッシュボード画像を GeuU に添付して、以下のプロンプトを実行しました。ポイントは要件 1 と同様に役割を与えたことです。次に画像からラベルの色が識別できるか不明だったので、ラベルで設定している背景色を明記したことです。 あなたはグラフィカルデザイナーで、ダッシュボードの最終確認をします。 部下が設備予知保全ダッシュボードの背景色とプロジェクトビューの背景色の考えてきました。画像を参考に2つの背景色が妥当か確認してください。 もっと良くなる背景色があれば提案をしてください。 ダッシュボード背景色：#000000 設備予知保全ダッシュボード背景色：#FFFFFF プロジェクトビュー背景色：#898989 GenU からの応答には、ラベルの背景色に加えて、円グラフの配色とフォントサイズについての改善案が含まれており、想定以上の回答を得ることができました。 この設備予知保全ダッシュボードのデザインは全体的にシックで落ち着いた印象があり、良いバランスだと思います。ただし、いくつか改善点があります。 ダッシュボード背景色の#000000(黒)は適切ですが、設備予知保全ダッシュボードの背景色の#FFFFFF(白)は、グラフやデータと対比が強すぎて目が疲れる可能性があります。代わりに#F5F5F5(薄いグレー)などの落ち着いた色を使うことをお勧めします。 プロジェクトビューの背景色の#898989(灰色)は少し暗すぎます。代わりに#BDBDBD(明るい灰色)などの明るめの色を使うと、より見やすくなると思います。 グラフの色使いは適切ですが、もう少しアクセントカラーを効果的に使うとよりインパクトがでるでしょう。例えば、重要な指標の円グラフに鮮やかな色(赤や青など)を使うなどです。 フォントの色とサイズにも気をつける必要があります。現在のデザインでは、一部のテキストが背景に埋もれて見づらい部分があります。 全体として落ち着いた色使いでまとまっていますが、適度なアクセントと対比を加えることで、より見やすく分かりやすいダッシュボードになると思います。必要に応じて調整をお願いします。 ( 図：要件3のプロンプトと実行結果 ) そこで、フォントカラーとサイズの適切な設定についても GenU にアドバイスを求めました。 フォントの色とサイズで良くする点がありましたら、提案をしてください。 その結果、フォントの色と最適なサイズの提案が返ってきました。 フォントの色とサイズについて、以下のように提案します。 【フォントの色】 メインタイトル(「設備予知保全ダッシュボード」) 現在の白は背景の黒に埋もれて見づらいので、より明るい色の方が良いでしょう。 提案: RGB(220,220,220)の明るいグレー サブタイトル(「プロジェクトビュー」など) 現在の灰色は大丈夫ですが、もう少し明るめの色の方が見やすくなります。 提案: RGB(160,160,160) データラベル(グラフ内の値など) 現在の白は問題ありませんが、アクセントになる色を使うとより見やすくなります。 提案: RGB(255,200,0)の黄色を使う 【フォントのサイズ】 メインタイトル: 現在の24ptはちょうど良いサイズ サブタイトル: 現在の18ptは小さ過ぎます。20ptが適切でしょう。 データラベル: グラフによって最適なサイズは異なりますが、 概ね12pt~14ptが見やすいサイズになると思われます。 その他の補助テキスト: 10ptが最小サイズとして適切です。 このようにフォントの色とサイズを最適化することで、データが一目で視認でき、より分かりやすいダッシュボードになると考えられます。必要に応じて更なる調整をお願いします。 (図：フォントカラーとフォントサイズのプロンプト結果 ) ※画像ではメインタイトルのフォント色の提案が切れています。 内容を確認すると、フォントカラーは 10 進法表記での提案でした。 しかし、 AWS Managed Grafana ではラベルのフォントカラーを HEX 表記で設定するため、 HEX 表記の提案を求めました。 色はHEXで教えてください。 HEX表記での提案が返ってきました。 分かりました。フォントの色をHEX表記で提案します。 【フォントの色】 メインタイトル(「設備予知保全ダッシュボード」) 提案: #DCDCDC (明るいグレー) サブタイトル(「プロジェクトビュー」など) 提案: #A0A0A0 データラベル(グラフ内の値など) 提案: #FFCC00 (黄色) (図：フォントカラーHEXのプロンプトと実行結果 ) GenU の提案に基づき、ラベルの背景色とフォントサイズを設定したところ、メインタイトルとサブタイトルのラベルの色が同色化しました。 そこで、 GenU の提案を一部採用することにしました。具体的には、メインタイトルの白色は変更せず、プロジェクトビューなどのサブタイトルについては、 GenU の提案に従って背景色とフォントサイズを変更しました。 (図：ラベル Before ) (図：ラベル GenU 提案 ) (図：ラベル After（最終）) 以上により、 AWS Summit 2024 Japan で展示するダッシュボードデザインの設定が終わりました。プロジェクトビューの 4 つの円グラフの配色は、ユニークかつ以前より鮮やかなものになりました。さらに、プロジェクトビューなどのサブタイトルの文字色を黒に変更したことで、可読性が高まりました。 (図：要件 3 プロンプト実行後のダッシュボード画面) おわりに このブログでは、 生成 AI ソリューション generative-ai-use-cases-jp (略称: GenU )を利用し、 AWS Summit 2024 Japan で展示した「Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ」のデザインを改善した事例とその手法を紹介しました。 最後に、Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードを紹介している AWS ブログを紹介します。こららのブログには、デモの目的や構成を紹介しています。デモに関心にある方は、ぜひご覧ください。 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモを AWS Summit 2024 Japan で展示します (Part 1) Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモを AWS Summit 2024 Japan で展示しました(Part 2:サービス解説編 ) AWS Summit Japan 製造業向け展示の見どころ紹介！ このブログについて AWS Summit 2024 Japan で展示した 「 Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモ 」は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発しました。 ブログ執筆者 梶山　政伸 (Masanobu Kajiyama) ソリューションアーキテクトとして、製造業のお客様と共にクラウドジャーニーをしています。趣味は旅行で、欧州・中東・アジアの19ヶ国を訪れました。

9月10日、レジリエンスを中核として基盤モデル (FM) 開発向けに設計された専用インフラストラクチャである Amazon SageMaker HyperPod での Amazon Elastic Kubernetes Service (EKS) のサポート が発表されました。お客様が EKS を使用して HyperPod クラスターをオーケストレーションすることを可能するこの新しい機能は、 Kubernetes の力と、大規模モデルのトレーニング用に設計された Amazon SageMaker HyperPod のレジリエントな環境を組み合わせます。Amazon SageMaker HyperPod は、1,000 個を超える AI アクセラレータ全体での効率的なスケーリングに役立つため、トレーニング時間が最大 40% 短縮されます。 Amazon SageMaker HyperPod では、お客様が Kubernetes ベースのインターフェイスを使用してクラスターを管理できるようになりました。この統合により、トレーニング、微調整、実験、推論などのさまざまなワークロードを最適化するために、Slurm と Amazon EKS をシームレスに切り替えることが可能になります。包括的な監視機能を実現する CloudWatch Observability EKS アドオンは、統合されたダッシュボードで CPU、ネットワーク、ディスク、およびその他の低レベルのノードメトリクスに関するインサイトを提供します。この強化されたオブザーバビリティは、クラスター全体でのリソースの活用、ノードレベルのメトリクス、ポッドレベルのパフォーマンス、コンテナ固有の使用率データに拡張されるため、効率的なトラブルシューティングと最適化の促進につながります。 re:Invent 2023 でリリースされた Amazon SageMaker HyperPod は、大規模なモデルを効率的にトレーニングし、デプロイしようとしている AI スタートアップと企業にとっての主力ソリューションになりました。これには、トレーニング時間を最大 20% 短縮するために役立つ モデル並列 および データ並列 ソフトウェア最適化を提供する、 SageMaker の分散型トレーニングライブラリ との互換性があります。SageMaker HyperPod は、障害のあるインスタンスを自動的に検出して修復または交換するため、データサイエンティストはモデルのトレーニングを数週間または数か月間、中断することなく実行できます。これは、データサイエンティストがインフラストラクチャの管理ではなく、モデル開発に集中することを可能にします。 Amazon EKS と Amazon SageMaker HyperPod の統合は、スケーラビリティと豊富なオープンソースツールを備えていることから機械学習 (ML) ワークロードで人気を集めている Kubernetes の利点を活用します。多くの場合、組織は生成 AI ユースケースに必要なものを含めたアプリケーションを構築するために、Kubernetes で標準化を行っています。Kubernetes では、コンプライアンスやガバナンスの標準を満たしながら、環境全体で機能を再利用できるからです。本日の発表により、お客様は 1000 個を超える AI アクセラレータ全体でリソースの活用をスケールし、最適化できるようになります。この柔軟性は、開発者エクスペリエンス、コンテナ化されたアプリケーションの管理、FM トレーニングと推論ワークロードのための動的なスケーリングを向上させます。 Amazon SageMaker HyperPod での Amazon EKS サポートは、詳細なヘルスチェック、自動化されたノードリカバリ、ジョブの自動再開機能を通じてレジリエンスを強化して、大規模なジョブや長時間実行されるジョブのトレーニングが中断されないことを確実にします。ジョブ管理は、Kubernetes 環境用に設計されたオプションの HyperPod CLI を用いて合理化できますが、お客様は独自の CLI ツールを使用することも可能です。 Amazon CloudWatch Container Insights との統合は、高度なオブザーバビリティを提供するので、クラスターのパフォーマンス、正常性、および使用率に関するより深いインサイトを得ることができます。さらに、データサイエンティストは、自動化された ML ワークフローのために Kubeflow といったツールを使用することもできます。この統合には Amazon SageMaker のマネージド MLflow も含まれており、実験追跡とモデル管理のための堅牢なソリューションを提供します。 大まかに説明すると、Amazon SageMaker HyperPod クラスターはクラウド管理者が HyperPod クラスター API を使用して作成するものであり、HyperPod によって完全に管理されるため、ML インフラストラクチャの構築と最適化に関わる差別化につながらない重労働が排除されます。これらの HyperPod ノードのオーケストレーションには Amazon EKS が使用され (Slurm が HyperPod ノードをオーケストレーションする方法と似ています)、お客様に使い慣れた Kubernetes ベースの管理者エクスペリエンスを提供します。 Amazon SageMaker HyperPod での Amazon EKS サポートの使用を開始する方法を見ていきましょう シナリオを準備することから初めて、 前提条件 を確認し、Amazon SageMaker HyperPod EKS ワークショップの手順に従って、VPC とストレージリソースで設定されている単一の AWS CloudFormation スタックで Amazon EKS クラスターを作成します。 Amazon SageMaker HyperPod クラスターを作成して管理するには、 AWS マネジメントコンソール  か  AWS コマンドラインインターフェイス (AWS CLI) を使用できます。AWS CLI を使用して、クラスター構成を JSON ファイルで指定します。SageMaker HyperPod クラスターのオーケストレーターには、以前に作成された Amazon EKS クラスターを選択します。次に、プライベート Subnet があり、自動ノードリカバリを有効にするために NodeRecovery  が Automatic   に設定されている、「worker-group-1」という名前のクラスターワーカーノードを作成します。 OnStartDeepHealthChecks  には InstanceStress と InstanceConnectivity を追加して、詳細なヘルスチェックを有効にします。 cat > eli-cluster-config.json << EOL { "ClusterName": "example-hp-cluster", "Orchestrator": { "Eks": { "ClusterArn": "${EKS_CLUSTER_ARN}" } }, "InstanceGroups": [ { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.p5.48xlarge", "InstanceCount": 32, "LifeCycleConfig": { "SourceS3Uri": "s3://${BUCKET_NAME}", "OnCreate": "on_create.sh" }, "ExecutionRole": "${EXECUTION_ROLE}", "ThreadsPerCore": 1, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ], }, .... ], "VpcConfig": { "SecurityGroupIds": [ "$SECURITY_GROUP" ], "Subnets": [ "$SUBNET_ID" ] }, "ResilienceConfig": { "NodeRecovery": "Automatic" } } EOL InstanceStorageConfigs を追加して、追加の Amazon EBS ボリューム をプロビジョニングし、HyperPod ノードにマウントすることができます。 SageMaker HyperPod API を使用してクラスターを作成するため、以下の AWS CLI コマンドを実行します。 aws sagemaker create-cluster \ --cli-input-json file://eli-cluster-config.json この AWS コマンドは、新しい HyperPod クラスターの ARN を返します。 { "ClusterArn": "arn:aws:sagemaker:us-east-2:ACCOUNT-ID:cluster/wccy5z4n4m49" } 次に、 SageMaker コンソール で HyperPod クラスターのステータスを確認し、ステータスが InService に変わるまで待ちます。 または、AWS CLI を使用して describe-cluster コマンドを実行することで、クラスターのステータスを確認することも可能です。 aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster クラスターの準備が整ったら、SageMaker HyperPod クラスターノードにアクセスできるようになります。ほとんどの運用では、開発環境からリソースとジョブを管理するために kubectl コマンドを使用して、SageMaker HyperPod のマネージドインフラストラクチャのメリットを得ながら Kubernetesオーケストレーションを最大限に利用することができます。今回は、高度なトラブルシューティングや直接的なノードアクセスのために、「 Access your SageMaker HyperPod cluster nodes 」ページにある手順に従って、個々のノードへのログインに AWS Systems Manager (SSM) を使用します。 EKS がオーケストレーションする SageMaker HyperPod クラスターでジョブを実行するには、「 Run jobs on SageMaker HyperPod cluster through Amazon EKS 」ページに概説されている手順に従います。HyperPod CLI とネイティブ kubectl コマンドを使用して、利用可能な HyperPod クラスターを検索し、トレーニングジョブ (ポッド) を送信できます。ML 実験とトレーニング実行の管理には、 Kubeflow Training Operator 、 Kueue 、および Amazon SageMaker のマネージド MLflow を使用できます。 最後に、SageMaker コンソールで最近追加された EKS クラスターの ステータス と Kubernetes バージョン を表示して、SageMaker HyperPod 環境の包括的な概要を把握できます。 クラスターのパフォーマンスと正常性のインサイトは、 Amazon CloudWatch Container Insights を使用して監視できます。 知っておくべきこと 以下に、Amazon SageMaker HyperPod での Amazon EKS サポートについて知っておく必要のある重要点をいくつか紹介します。 レジリエントな環境 – この統合は、詳細なヘルスチェック、自動化されたノードリカバリ、およびジョブの自動再開機能を備えた、よりレジリエントなトレーニング環境を提供します。SageMaker HyperPod は障害を自動的に検出および診断して回復させるため、基盤モデルのトレーニングを中断することなく数週間または数か月間継続させることができます。これは、トレーニング時間を最大 40% 短縮できます。 強化された GPU オブザーバビリティ – Amazon CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスに関する詳細なメトリクスとログを提供します。これは、クラスターのパフォーマンスと正常性の包括的な監視を可能にします。 サイエンティストが簡単に使用できるツール – このリリースには、ジョブ管理のためのカスタム HyperPod CLI 、分散型トレーニングのための Kubeflow Training Operator、スケジューリングのための Kueue、および実験追跡のための SageMaker のマネージド MLflow が含まれています。また、モデル並列およびデータ並列最適化を提供する SageMaker の分散トレーニングライブラリとも連動して、トレーニング時間を大幅に短縮します。これらのライブラリとジョブの自動再開機能を組み合わせることで、大規模モデルの効率的で中断のないトレーニングが可能になります。 柔軟なリソース活用 – この統合により、開発者エクスペリエンスと FM ワークロードのスケーラビリティが向上します。データサイエンティストは、トレーニングタスクや推論タスク全体でコンピューティングキャパシティを効率的に共有できます。既存の Amazon EKS クラスターを使用したり、新しい EKS クラスターを作成して HyperPod コンピューティングにアタッチしたりすることや、ジョブの送信、キュー登録、監視のために独自のツールを使用することができます。 Amazon EKS で Amazon SageMaker HyperPod の使用を開始するには、SageMaker HyperPod EKS ワークショップ、 aws-do-hyperpod プロジェクト 、および awsome-distributed-training プロジェクト などのリソースを活用できます。このリリースは、Amazon SageMaker HyperPod を利用できる AWS リージョン (欧州 (ロンドン) リージョンを除く) で一般提供されています。料金の情報については、 Amazon SageMaker の料金ページ をご覧ください。 このブログ記事は共同で作成されました。この記事で紹介した情報の収集と絞り込みに大きく貢献してくれた、Manoj Ravi、Adhesh Garg、Tomonori Shimomura、Alex Iankoulski、Anoop Saha、そしてチーム全員に感謝しています。この包括的な記事の作成には、彼らの集合的な専門知識がきわめて重要な役割を果たしました。 – Eli. 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半に渡ってご講演いただきました。 前回 に引き続きこのブログではイベントの最後に行われたパネルディスカッションの内容をレポートします。 パネルディスカッション：AWS と紡いできたデジタル変革の歴史 株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （インフラストラクチャ） 堀川 茂 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （SCM・インテグレーションエンジニアリング） 北口 泰大 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 （コアエンジニアリング） 村田 雄一 氏 アマゾン ウェブ サービス ジャパン合同会社 流通小売・消費財・サービスビジネスグループ 本部長 五十嵐 建平 皆様のキャリア、ご担当領域 まず、パネリストの皆様にご自身の経歴をお話しいただきました。 大谷氏は 2016 年にファーストリテイリングに入社し、主にエンジニアリングの内製化やテクノロジーの事業への根付かせることをミッションとしています。現在は技術の最高責任者であり、同時にセキュリティも担当されています。AWS との関わりとしては、ファーストリテイリングのサービスのほとんどが AWS 稼働しており、足掛け 12 年以上にわたり AWS を活用しています。実は前職が AWS のソリューションアーキテクトです。AWS 時代にファーストリテイリングを顧客訪問した経験もあるといったエピソードもご紹介いただきました。 堀川氏は 2012 年の入社以来、オンプレミスからクラウドシフトを進められた経験を持ち、AWS との関わりも 12 年前から続いています。ファーストリテイリングという事業会社に入ったことで、エンジニアとしての目標がシステムを入れることではなく業務成果そのものになったことは大きな転換でした。 北口氏は 2018 年の入社以来、共通基盤の開発やデータ連携基盤などを担当されています。現在は物流領域の業務改革とデジタルツール整備が注力ポイントです。AWS との関わりはファーストリテイリング入社後からで、新しいシステムを作る際には AWS のプロダクトチームとも協議しながら、最適なシステムの形を探りながら構築にあたっているとのことです。 村田氏は 2017 年の入社以来、有明プロジェクトをその立ち上げから経験されました。最初は e コマース（EC）の機能を提供するバックエンドシステムの開発からスタートし、インフラチームや品質保証などを経験したのち、現在は内製開発を統括する部長を務められています。EC の領域では AWS を徹底的に活用しており、AWS から継続的な支援を受けています。コールセンターの業務改革として Amazon Connect を活用する新しい取り組みについてもご紹介いただきました。 黎明期 – カルチャーの醸成 「黎明期 – カルチャーの醸成」というテーマからディスカッションが行われました。 最も在籍年数の長い堀川氏に入社当初のエピソードを振り返っていただきました。堀川氏はセミナーに参加したり、ベンダーの支援を受けながら AWS の使い方を学ばれたそうです。AWS の活用を決めるより前から、AWS のソリューションアーキテクト等の力を借りて経験を積まれました。当初はアーキテクチャレビューの仕組みなどはありませんでしたが、品質が担保できずにシステム障害が発生するなどの失敗も経験されました。アーキテクチャレビューの仕組みはそうした失敗から学んで生まれたものだったのです。 大谷氏からは有明の自動倉庫のプロジェクトについてお話を伺うことができました。IT プロジェクトとは違い、倉庫の設置やハードウェアの設置などの物理的な制約があり、事業会社ならではの痛みを感じたとのことでした。当時はまだ混沌の中にあり、整理された話ではなかったそうですが、優秀な人材を次々と採用することで知恵を出し合える環境が生まれてきました。重大な課題に対して連携して話し合う中で、自然と今のようなカルチャーが醸成されていったそうです。 堀川氏からは、SAP の導入で AWS と 4TB のインスタンス利用を交渉した経緯も紹介されました。当時はオンプレミスでしかできないという思い込みがあったとのことですが、将来の成長を見据えて AWS と交渉し、実現に至ったそうです。この経験から、できないことでもきちんと交渉すれば実現できるということを学びました。 このように、ファーストリテイリングの皆様は AWSの活用を決めた黎明期からさまざまな失敗や課題を乗り越えながら、現在のカルチャーを醸成してこられました。失敗を恐れずにチャレンジし、課題解決に向けて連携することが、ファーストリテイリングのカルチャーの基盤となっていることがよくわかります。 AWS との緊密な協力関係のもと、こうした新しいカルチャーを育んでいったことが、ファーストリテイリングのデジタル変革を可能にした大きな要因だったのです。 移行期 – アーキテクチャの変更 次のテーマはアーキテクチャの変更が起こった移行期についてです。村田氏は従来のモノリシックな EC パッケージからヘッドレスアーキテクチャのプラットフォーム化を進め、マイクロサービス化や Immutable Infrastructure の採用、マルチリージョン展開、オープンソースやマネージドサービスの活用、技術の標準化などを実現されたことを紹介しました。ビジネスロジックの複雑さとパフォーマンスやスケーラビリティの課題があったことも振り返られました。 北口氏は、当初はオンプレミスのアプリをクラウド上に載せただけの状態からスタートし、グローバル展開を見据えてコンテナ化や CI/CD の仕組み作りを進めた経緯を説明してくださいました。コストを意識したツール提供や、業務部門との密な連携によるコスト意識の共有なども行われていることが分かりました。大谷氏からアーキテクチャ標準化の取り組みも語られました。 Amazon Aurora や Amazon ElastiCache の標準採用、プログラミング言語やフレームワークの選定基準策定が行われた経緯が紹介されました。ツールが乱立して苦労した経験から、ある程度の標準化は必要不可欠と考えられていることがうかがえます。 一方で、大谷氏は技術選定に適度な幅を持たせることの重要性も指摘します。標準化を徹底しすぎると柔軟性を失うため、エンジニアにとって適切な選択の幅を残すことも重要です。これらの標準化は大規模な並行開発が進んでいた時期に行われました。グローバル展開を見据えてアーキテクチャ変革を段階的に実施し、プラットフォーム化、マイクロサービス化、標準化などが行われていったのです。 拡張期 – グローバル化 グローバル化におけるチャレンジという観点で、村田氏よりローカル対応についてご説明いただきました。約 30 の地域で複数のブランドでビジネスを展開しており、グローバルワンのプラットフォームを作る一方で、各国からの要望にも対応する必要があります。適切なプライオリティ付けと効率化が重要ですが、グローバルで作ったものが必ずしも全世界で当てはまるわけではなく、配送の仕組みやデータプライバシーの取り扱いなど、国ごとに対応が必要な部分も出てきます。加えて大谷氏は、技術の問題を必ずしも技術者だけで決められないケースがあり、地政学的リスクなどでは経営判断が必要になることがあると補足しました。 堀川氏はネットワークの最適化の観点で起こった変化をご説明くださいました。AWS への移行当初はすべての店舗からの通信を東京に集約していましたが、現在は AWS のネットワークをフル活用し、各国から最寄りの AWS リージョンに直結することで AWS のバックボーンネットワークを利用することでスピードとアベイラビリティを向上しました。 北口氏は、拠点系のシステムでは特にカスタマイズや要件のバリエーションが多いことを踏まえ、在庫の一貫性を持った管理や入出荷業務の効率化などの根本的な部分をグローバルワンとして構築した上で、ラッパー層としてローカルカスタマイズを行うアプローチをとっていると述べられました。 多国籍なチームを運営する上でのカルチャーの共有も重要です。多国籍なチーム構成だからこそ、ミッションステートメントに代表される価値観の共有が意思決定や一体感につながると説明がありました。クラウドジャーニーを推進するどのような組織においても、このミッションステートメントの共有によるインクルーシブな環境の構築は学ぶところがあります。 セキュリティ CSO を兼務する大谷氏より、セキュリティについてもコメントをいただきました。現代社会における情報システムでは特にセキュリティの重要性が高まっており、企業全体でセキュリティ水準を上げることが求められています。セキュリティは単なるテクノロジーの問題ではなく、経営層の意識や物理的なセキュリティ対策など、さまざまな側面から取り組む必要があるものです。 IT セキュリティだけでなく、お客様の情報を守るためには運用面での対策も欠かせません。ファーストリテイリングでは、IT セキュリティの基準を満たすだけでなく、さらにその水準を上げていくことが課題となっています。そのためには、セキュリティを俯瞰的に捉え、企業のミッションに照らし合わせて適切な基準を設定し、組織文化として根付かせることが重要だと述べられました。 一方で、セキュリティを過度に厳格化すれば、IT の創造性や付加価値が失われてしまう恐れがあります。セキュリティと IT の柔軟性のバランスを取ることが肝心であり、そのバランスを失わないようにすることがセキュリティチームの重要な役割だと大谷氏は述べられました。 まとめ 最後に皆様からクロージングコメントをいただきました。クラウドやプラットフォームの製品選定においては、現在の機能だけでなく、その組織のカルチャーを踏まえて今後の進化を見据えることが重要です。AWSはもともと、小売業である Amazon のビジネス課題を解決するために生まれており、お客様へのこだわりという点でファーストリテイリングと共通点の多い文化を持ち、お客様のための課題解決に向けた進化を続けていると評価いただきました。AWS との 12 年に渡る協業関係を振り返り、今後もグローバル展開に向けて AWS との戦略的な連携を強化していく考えを示されました。 最後に、さまざまなバックグランドを持ったエンジニアの皆さんにジョインしていただき、仲間を増やしていきたいという熱意のこもったメッセージをいただき、ご講演を締めくくっていただきました。 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半にわたってご講演いただきました。 前回 に引き続きこのブログでは講演内容をレポートします。 ファーストリテイリングの IT を支える AWS インフラストラクチャ 株式会社ファーストリテイリング デジタル業務改革サービス部 部長 堀川 茂氏 堀川氏より、同社の AWS クラウド活用の歴史と現状、そして大規模クラウド環境を少人数で運用するための工夫についてお話しいただきました。 ファーストリテイリングがクラウドを必要とした背景には、グローバルで 3,500 以上の店舗、約20 の国と地域での e コマース（EC） 事業、世界中の倉庫や工場といったサプライチェーン全体をつなぐ必要性がありました。ビジネスの急速な拡大に追随するため、データセンターを各事業ごとに構えるのではなく、グローバルにスケール可能で迅速にインフラを調達できるクラウドが不可欠でした。クラウド化の大きなきっかけとなったのは、2017 年 の EC サイトダウンでした。3 日間のダウンタイムを経験し、オンプレミス環境での容量増強の難しさや流量制御の課題に直面したことで、クラウド化の必要性を強く認識されました。 ファーストリテイリングのクラウドジャーニーは、2012 年頃から一部のキャンペーンサイトで AWS の利用を開始したことに始まります。2013年には既存の基幹システムの老朽化に伴い、クラウド化プロジェクトが始動しました。2016年から2017年にかけて開始された「有明プロジェクト」を通じて、オンプレミスからクラウドへの移行（リフト & シフト）が大規模に進められました。2021 年頃からはグローバル展開が加速し、AWS の利用も更に拡大しました。 クラウド活用の成果として、以下の 5 点が挙げられました。 スケーラビリティとキャパシティの確保：需要に応じて簡単にスケールアップやキャパシティ拡張が可能になった アーキテクチャのモダナイゼーション：マイクロサービス化など、レガシーシステムから現代的なアーキテクチャへの移行が実現した エンジニアの確保：クラウドエンジニアの採用が容易になり、パートナーや開発者の確保が改善された アベイラビリティの確保：コスト効率の良い方法で、災害対策用のバックアップサイトを別のアベイラビリティゾーンや地域に構築できるようになった インフラコストの最適化：繁忙期と閑散期でリソースを調整し、インフラコストを最適化できるようになった 現在の AWS 利用状況としては、60 以上のアカウント、15 以上のリージョン、13,000 以上の仮想マシン、3,000 以上のデータベース、12 万以上のコンテナを運用しています。これらの大規模インフラを 20 人程度の少数チームで管理するために、さまざまな工夫を行っています。主な取り組みとして以下が紹介されました。 アーキテクチャーレビュー：コマース、エンタープライズ、CTO の 3 つのレビューボードを設置し、プロジェクトの計画から運用要件、セキュリティまで多角的な観点でチェックを行っています。 自動化・コード化：Infrastructure as Code (IaC) の活用、コスト管理の自動化、標準化された AWS アカウント作成の自動化などを導入しています。 セルフサービス化：アプリケーションチームが自身で責任を持ってコードのビルド、テスト、デプロイできる仕組みを構築しています。 コスト管理：タグベースでシステムごとのコストの推移を可視化し、アプリケーションチームが自ら責任を持ってコストを管理できるようにしています。 システム監視基盤の統一：散在していた監視基盤を統合し、全担当者がメトリクスやアプリケーションの振る舞いを一元的に把握できるようにしました。これにより、トラブルシューティングの時間短縮を実現しています。 セキュリティ対策：AWS が提供する様々なセキュリティソリューションを活用し、マルチアカウントでの統合的なセキュリティ管理を実現。セキュリティアカウントに情報を集約し、SIEM 基盤と連携させることで、脆弱性の早期検知と対策を可能にしています。 今後の取り組みとして、ECS コンテナタスクよりも幅広く、粒度の細かいパラメータ制御もセルフサービスで行えるための Kubernetes の活用や、グローバル展開をさらに加速させるために各地域のインフラチームを強化し、follow the sun の運用の実現を目指しています。また、グローバルでのプロジェクト推進体制の構築も進めています。 自動化やセルフサービス化、統一監視基盤の導入など、さまざまな工夫により少人数での大規模クラウド運用を実現しています。グローバル展開を加速させる企業が AWS を活用して大規模なクラウド環境を効率的に運用する方法をご紹介いただきました。 ユニクロ・ジーユーのECアプリの裏側をご紹介 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 秋元 俊祐 氏 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 佐野 大輔 氏 続いて、コアエンジニアリングチームの方々よりユニクロ・ジーユーの EC アプリの裏側をご紹介いただきました。まず、秋元氏より e コマース（EC）サイトのカート機能における大幅な性能改善とコスト削減の事例についてご紹介いただきました。 カート機能は、ユニクロやジーユーのアプリやウェブサービスで商品を選び、購入手続きを行う際に重要な役割を果たします。従来のアーキテクチャでは、 Application Load Balancer の下に Amazon Elastic Container Service (Amazon ECS) があり、Amazon ECS の API Service が Amazon Aurora からデータを読み取る構成でした。しかし、この構成では人気商品のセール時などにトラフィックが急増すると、データベースがボトルネックとなり、レスポンスタイムが大幅に悪化する問題がありました。また、データベースのインスタンスを上位のものに変更することでインフラコストが圧迫されるという課題もありました。 これらの課題を解決するため、NoSQL の一つである Redis をメインデータベースとして採用することを決定しました。 Amazon ElastiCache を利用することで、高いスケーラビリティを確保しつつ、性能を大幅に向上させることができました。 新しいアーキテクチャでは、API Service から直接 Amazon ElastiCache にデータの読み書きを行い、Amazon ElastiCache と Amazon Aurora の間で非同期のデータ同期を行うようにしました。これにより、Redis の性能を最大限に引き出すことができました。 実装上の工夫として、Lua スクリプトを用いた自前のロック機能の実装や、Redis の Sorted Set による更新されたカートの効率的な抽出などが行われました。また、データマイグレーションはゼロダウンタイムで実施され、運用を継続しながら徐々に Redis にデータを移行することができました。 結果として、以前問題が発生したセールの 2 倍以上のトラフィックがあった際も、まったく性能劣化が見られませんでした。レスポンスタイムは p95 で10秒超から 160ms と大幅に改善され、さらに大きなトラフィック増加にも対応できる見込みが立ちました。コスト面でも大きな削減が実現し、Amazon ElastiCache for Redis の Data Tiering 機能を利用することで、さらなるコスト最適化が図られています。 最終的に、データベースのコストが 60 %以上削減され、将来 10 年に渡るスケーラビリティを確保することができました。クラウドサービスを効果的に活用することで、性能向上とコスト削減を同時に実現できることを示していただきました。 続いて、サーチプラットフォームについて、佐野氏よりご紹介いただきました。ファーストリテイリングのシステムは、各業務のマイクロサービスが相互に接続されており、データ連携基盤や API 連携で構成されています。サーチプラットフォームは、商品検索機能を提供するマイクロサービスで、在庫情報や価格情報、商品情報などを他のプラットフォームから取得して利用しています。主な機能には、キーワード検索、カテゴリーページの商品リスト作成、キーワードサジェスト、類似商品リスト作成、店舗在庫検索などがあります。 Amazon OpenSearch Service は現在サーチプラットフォームを含む一部のプラットフォームで利用されています。Amazon OpenSearch Service の特徴として、以下の 3 点が挙げられました。 柔軟な構造を持つデータを大量に登録可能 キーワード検索や柔軟なクエリの実現 フルマネージドサービスで、リクエスト量に応じたスケールイン/アウトが容易 Amazon OpenSearch Service の長所として、参照用途のアプリケーションに高い性能と拡張性を発揮すること、EC における商品検索のような典型的な機能を既に持っているため開発量を削減できることが挙げられました。 グローバルデジタルコマースの検索に求められる要件として、複数のブランド、多くの国・地域への展開、多言語サポートを効率的にサポートすることが重要です。サーチプラットフォームの実装におけるポイントとして、以下の 4 点が挙げられました。 機能性：言語特有の解析機能を自作するのは困難で非効率であり、構文解析や正規化などの機能が最初からサービスに組み込まれていることが重要 展開容易性：自動的にデータが Amazon OpenSearch Service に流れ込むアーキテクチャーの採用 拡張性：スケールイン/アウトの容易な実行 運用性：単語・シノニム登録のための効率的なツールの開発 今後の課題として、単語・シノニム登録の業務運用コスト削減が挙げられました。これに対して、機械学習由来の技術（大規模言語モデル、ベクターサーチ、セマンティックサーチなど）の活用が検討されています。また、キーワード検索以外にも、ユーザー体験を向上させる機能の開発や、サーチプラットフォームの改善と並行して新しい地域への展開を進めていくことが課題として挙げられました。 データ連携基盤の実行制御を実現する Amazon ECS を活用したアプリケーション開発 株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 阪本 圭 氏 株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 吉元 裕人 氏 続いて、インテグレーションエンジニアリングチームによる、データ連携基盤の取り組みについて阪本氏より紹介がありました。 まず、チームの主な役割として、システム開発の効率化とデータ連携基盤の開発・管理・運用が挙げられました。情報製造小売業として、End-to-End のプロセスに投資を行ってきた結果、データ連携やバッチ処理が複雑化・大規模化していました。そのため、データの整流化とデータ利活用のためのツール整備、そして多ブランド・多国展開後のデータ量に対応した高速な処理の実現が必要とされました。 これらの課題に対して、2 つの主要なコンセプトで取り組んでいます。1 つ目はバッチ処理基盤の整備です。処理依存性や並列分散を制御できるフレームワークを準備し、複雑な依存関係を管理しやすい形に整理しました。2 つ目はデータ連携基盤の整備です。ハブアンドスポーク型のクラウドネイティブな基盤を構築し、あらゆる情報を一元管理してデータの整流化を図っています。特徴として、定義ベースで簡単にルーティング制御ができること、ビジネス領域ごとの特性に合わせて分散配置できること、さまざまなプロトコルやデータフォーマットをカバーできることがあります。 この基盤に求められる中心的な要件として、以下の 4 点が挙げられました。 安定性：ビジネスの中核を担うため、高い安定性が必要であること パフォーマンス：ビジネスの変動に耐えられる性能とキャパシティをプランニングできること 可搬性：簡易に分散展開できること 多様なアプリケーションとの連携：さまざまなアプリケーションとのシームレスな連携が可能であること 続いて、データ連携基盤の具体的なアーキテクチャや、開発していく中での課題や工夫について吉元氏よりご紹介いただきました。 データ連携基盤は、各業務領域間でデータを効率的に連携させるためのハブアンドスポーク型のシステムとして設計されており、現在 10 のサービスとして 2 つのクラウド、6 つのリージョンで運用されています。システムの開発経緯としては、2015 年にバッチ処理基盤として始まり、徐々に機能を拡張してデータ連携基盤へと進化してきました。2019 年にはコンテナ化やインフラのコード化を実施し、2021 年にはマルチクラウドのサポートを強化しています。 開発・運用において重視している点として、環境の再現性、拡張性、カスタマイズの容易さ、スケーラビリティ、クラウド非依存性などが挙げられました。特に、Amazon ECS を利用したタスク実行の管理に関しては、API 呼び出しに単位時間当たりの回数制限があったり同期的なタスクの状態管理が困難であったりという課題に対して、解決策を独自に実装しています。 具体的には、ワーカーアプリケーションをラッパーでくるむことで、フレームワーク全体の一部として動作させ、ハートビートやコールバックを通じてタスクの状態を同期的に把握する仕組みを実装しています。これにより、ECS クラスターへの状態確認のための頻繁なポーリングによる問い合わせを回避し、アプリケーションの実行状況をよりタイムリーに把握・管理できるようになりました。 今後のチャレンジとしては、以下の 3 点が挙げられました。 導入の更なる省力化・セルフサービス化の推進：業務アプリケーションチームが容易にデータ連携の仕組みを構築できるようにする 新しいサービスとの連携強化：デジタル改革に伴う新サービスとの安定した連携を実現する データ活用の促進：データの蓄積・分析プロセスとの一層の統合を図り、ビジネス価値の創出につなげる 最後に、この取り組みを通じて、複雑化していたデータ連携やバッチ処理の整理統合を図り、クラウドサービスを適切に活用しながら独自のソリューションとしてパッケージ化することで、ビジネスへの貢献を目指していることをご紹介いただきました。 （ Part 3 に続く） 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

アマゾン ウェブ サービス ジャパン合同会社は 2024 年 7 月 24 日に株式会社ファーストリテイリングをお招きし、「エンジニアが紡ぐ ファーストリテイリングの デジタル変革」というテーマで、4 時間半にわたってご講演いただきました。本ブログでは、3 回に分けてその内容をレポートします。 オープニング ：ファーストリテイリングにおけるビジネスの変革とデジタルの取り組みについて 株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏 はじめに、大谷氏よりファーストリテイリングのビジネスコンセプトと、デジタル変革に向けた「有明プロジェクト」についてご説明いただきました。 ファーストリテイリングでは、「服を変え、常識を変え、世界を変えていく」というミッションステートメントのもと、ユニクロ、ジーユー、プラステ、セオリー、コントワー・デ・コトニエ、プリンセス タム・タムなど 8 つのブランドを展開しています。現在 約 30 の 国・地域で約 3,600 店舗を構え、世界のアパレル製造小売りでは第 3 位の規模となる売上収益 2.7 兆円（2023 年 8 月期）の企業グループです。特にユニクロが海外事業の牽引役となり、売上の 6 割が海外からのものです。お客様一人ひとりの毎日の生活を良くするための「究極の普段着」としての「LifeWear」の提供を目指しており、高品質の服を手に取りやすい価格で届けることをコンセプトとしています。また、「PEACE FOR ALL」の活動を通じて、平和を願う著名人とコラボレーションした T シャツの利益を紛争や差別など、戦争で被害を受けた人々に還元するなど、社会貢献にも力を入れています。 ファーストリテイリングはデジタル変革の取り組みとして有明プロジェクトを推進しています。これは製造小売業から「情報製造小売業」への転換を目指すもので、お客様の本当に欲しいものだけを届けるための変革です。お客様の声を起点に、商品企画、生産・物流、販売までをデジタルでつなげ、必要な分だけ、必要なタイミングで商品を届けることを目指しています。約 11 万人の従業員が世界中でワンチームとなり、データを駆使してお客様のニーズを的確に捉え、そのニーズにスピーディーに応えられるよう業務改革に取り組んでいます。 企画から販売までの一連のプロセスをデータで可視化し最適化することで、無駄を排除しお客様満足度向上とコスト削減を両立させようとしています。エンジニアはこの中心に位置し、デジタル業務改革サービス部という名前のとおり IT の中だけに閉じずに、業務のやり方を変革することが根幹にあるとご説明いただきました。 具体的な取り組みとしては、店舗と e コマース（EC）でシームレスな買い物体験を実現すべく、RFID を活用したセルフレジの導入も進めています。また、自動走行ロボットの導入による物流の自動化・効率化の推進も行なっており、ソフトウェア・ハードウェアの双方において幅広い取り組みがあります。 有明プロジェクトは、デジタルの力を最大限活用してビジネストランスフォーメーションを実現し、「情報製造小売業」への変革を成し遂げることを目的としています。先端技術を取り入れながら AWS 上に最適なプラットフォームを構築し、お客様への付加価値提供を実現する大規模な挑戦です。デジタル変革を通じて、ファーストリテイリングは「服を変え、常識を変え、世界を変えていく」ミッションを実現していこうとしているのです。 ファーストリテイリングの内製化の進化 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 部長 村田 雄一 氏 続いて、ファーストリテイリングの内製開発を推進するコアエンジニアリングチームの村田氏より、同社のデジタル変革の歴史と内製化の取り組みについてご紹介いただきました。 同社は早くから業務にデジタル技術を取り入れることの重要性を認識しており、1988 年の POS システム導入に始まり、1990 年代から自社で商品情報や販売情報のデジタル処理を行うようになりました。2000 年代にはオンラインストアを開設し、2010 年代の店舗スタッフによるデジタルデバイスの活用など各種のデジタル変革を進めてきました。そして 2016 年から始まった全社改革プロジェクトである有明プロジェクトの中で、本格的にエンジニアリングの内製化を開始しました。この内製化の取り組みにより、RFID を活用したセルフレジや在庫管理の改革、グローバル展開のための EC プラットフォームの構築などが実現されています。 内製化の背景には、情報の力を活用して製造小売業から本格的な情報小売業へ転身するという戦略があり、そのためにはプラットフォームを自社で作る必要があったことが挙げられます。また、「業務 = システム」という考え方に基づき、現場を深く理解し、単純明快なトータルシステムを組み、将来の方向性と矛盾しないシステムを構築することが重要視されていました。内製化の推進にあたっては、まず EC の領域から着手し、会員基盤の構築、カタログサイト開設、オンラインストア機能の拡張など、段階的に機能を拡張していきました。新規事業国から始め、日本、そしてグローバルへと展開範囲を広げていった点も特徴的です。 組織面では、グローバル人材を積極的に登用し英語を公用語とするなど国際化を進めています。また、正社員とパートナー企業が一つのスクラムチームを組むハイブリッド体制を採用しています。エンジニア人材の育成においては、ビジネスを理解し技術的な意思決定に反映できるシニアエンジニアを戦略的に育成することに注力しています。具体的には、アーキテクチャレビューボードを設置し、さまざまな業務要件を理解してアーキテクチャに落とし込む訓練を行っています。ボードメンバーをローテーションすることで、継続的な人材育成を図っています。 内製化による主な成果としては、トラブル発生時の解決スピードの向上とシステムに対するコントロール力の獲得が挙げられます。自社で作った仕組みなので問題の所在がわかりやすく、迅速な対応が可能です。技術の選定やビジネスロジックの理解など、重要な意思決定を迅速に行えるようになったことも大きな成果です。一方で、もともと持っていた服屋としてのカルチャーと IT エンジニアリングのカルチャー、日本的なカルチャーとグローバルのカルチャーの橋渡しや、グローバル展開に伴うスケール対応が課題となっています。今後は年間売上高 10 兆円を目指し、世界最高水準のグローバルエンジニアリング組織を日本発で作ることを目標としています。そのためには、ビジネスを理解し技術的な意思決定ができるシニアエンジニアの継続的な育成が不可欠であり、エンジニアにとって世界で最もやりがいのある職場を提供していく考えです。世界レベルのビジネスにチャレンジできる貴重な機会を提供し、困難に立ち向かうことでエンジニアが最も成長できる環境を整備していきたいとのことでした。 グローバル展開×店舗と EC の融合×売上 10 兆円への事業成長を支えるマイクロサービスプラットフォーム 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム リーダー 佘 嘯 氏 株式会社ファーストリテイリング デジタル業務改革 サービス部 コアエンジニアリングチーム 井上 夏樹 氏 続いて、ファーストリテイリング コアエンジニアリングチームの方々より、グローバル展開を支えるマイクロサービスプラットフォームと、EC・店舗を融合するための取り組みについてご紹介いただきました。まず佘氏よりこれまでの取り組みの概要をご説明いただきました。 従来は各ブランドや地域ごとに異なる EC システムを使用していたため、機能開発や運用にかかるコストが高く、非効率な部分がありました。そこで 2017 年から世界で一つの EC ソリューションを提供すべく EC の刷新に着手し、2020 年には日本で、2021 年にはアメリカで、そして 2024 年に韓国でもグローバル EC パッケージをリリースしました。新しい EC プラットフォームでは、デザインだけでなく機能面でも統一されています。グローバル EC プラットフォームの展開に際しては、マルチブランド対応や各国の言語・支払方法・法制度への配慮、グローバル標準化とローカライズの両立が基本方針とされています。今後もファーストリテイリングの事業拡大にあわせて、世界各地域への継続的な導入を進めていく計画です。 ファーストリテイリングの EC は、実店舗と連動する点に特徴があります。EC には一般的な購入履歴や通知、チャットボットなどに加え、実店舗と EC の融合のための O2O (Online to Offline、Offline to Online)の機能が搭載されています。O2O サービスには EC で購入した商品を店舗に配送して受け取る「店舗受取り」、EC から元々店舗にある在庫を受け取る申し込みができる「ORDER & PICK」、店舗在庫から自宅への直接配送「店舗発送」の 3 つのモデルがあります。これにより配送料の無料化や配送時間の短縮、店舗への顧客誘導、倉庫キャパシティの最適化が実現できます。 続いて、井上氏より EC システムの構成やアーキテクチャについてご紹介いただきました。ファーストリテイリングでは EC システムをグローバルなプラットフォームとして開発・運用しています。そしてフロントエンドとバックエンドの責務を明確に分離し、バックエンドはブランド横断的なマイクロサービス群を構築し、フロントエンドはブランド別に作られています。 リクエストフローで見るとユーザー端末→フロントエンドクライアント→ BFF (Backend for Frontend) →バックエンドマイクロサービスという構成になっています。 BFF の役割は、複数のマイクロサービスを呼び出してデータを集約し、クライアントが使いやすい形式でレスポンスを返すことです。合わせてデータキャッシュや認証・認可の処理も行います。バックエンドは特定のビジネスドメインを担うマイクロサービスが独立した API として提供さ れています。具体的な例を挙げると、ユーザーが商品を購入する場合には、買い物かご、商品情報、金額計算、クーポン、在庫、決済、注文管理などのマイクロサービスが呼び出されます。フロントエンドはウェブのレスポンシブな SPA (Single Page Application) とモバイルネイティブアプリから構成されます。SPA は共通のデザインシステムと国際化の仕組みを活用することで、仕組みは整えつつ各国にローカライズできるようにしています。モバイルアプリは Flutter で共通のコードベースを作りつつ、一部 Android/iOS のネイティブコードも使用します。 技術スタックとしては、インフラストラクチャ、ミドルウェア、プログラミング言語、フレームワークのすべてにおいて標準化を重視しています。バックエンドに Go や Java Spring Boot、フロントエンドに TypeScript や React、モバイルに Kotlin や Swift などを採用しています。 今後はグローバル展開を加速させる予定です。現地の言語、決済方法、物流、法制度などさまざまな要件をクリアしながら、段階的にロールアウトを進めていきます。また、年間売上高 10 兆円を目指すにあたり、トラフィック増加への対応が課題となっています。End to End での性能計測と改善に注力し、スケーラビリティの確保を図ります。 EC と実店舗を融合した O2O の取り組みも重要です。店舗と EC がシームレスに連携し、いつでもどこでも欲しい商品を購入できる体験を実現することが目標です。システムの高度化と店舗網の強みを生かし、お客様の利便性向上を追求していきます。 ( Part 2 に続く) 本ブログは、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 阿南、三好が執筆しました。

9月2日週、 最新の AWS ヒーロー が発表されました! AWS ヒーローは、インサイト、ベストプラクティス、革新的なソリューションを惜しみなく共有し、他のユーザーを支援する、素晴らしい技術エキスパートです。 AWS GenAI Loft は大盛況で、現在 サンフランシスコ と サンパウロ にて開催中です。また、今後数か月の間に ロンドン 、 パリ 、 ソウル で開催される予定です。9月2日週、サンフランシスコで開催されたワークショップの様子をご紹介します。 9月2日週のリリース 私が注目したいくつかのリリースをご紹介します。 Storage Browser for Amazon S3 (アルファリリース) – オープンソースの Amplify UI React コンポーネントです。 ウェブアプリケーションに追加すると、S3 に保存されているデータ用のシンプルなインターフェイスをエンドユーザーに提供 できます。このコンポーネントは、新しい ListCallerAccessGrants API を使用して、S3 アクセス権限の定義に従い、アクセスできるすべての S3 バケット、プレフィックス、オブジェクトを一覧表示します。 AWS Network Load Balancer – 設定可能な TCP アイドルタイムアウトのサポート を開始しました。詳細については、この ネットワーキングとコンテンツ配信のブログ記事 を参照してください。 AWS Gateway Load Balancer – こちらも 設定可能な TCP アイドルタイムアウトをサポート しています。詳細については、この ブログ記事 をご覧ください。 Amazon ECS – AWS Fargate を使用した AWS Graviton ベースの Spot コンピューティングのサポート を開始しました。これにより、耐障害性を備えた ARM ベースのアプリケーションを、オンデマンドと比較して最大 70% 低いコストで実行できます。 AWS リージョンのアベイラビリティーゾーンのゾーングループ – すべての AWS リージョンで一貫した命名形式を使用して、 ゾーングループコンストラクトをアベイラビリティーゾーン (AZ) まで拡張 できるよう取り組んでいます。 Amazon Managed Service for Apache Flink – Apache Flink 1.20 のサポート を開始しました。アップグレードすると、バグ修正、パフォーマンスの向上、Flink コミュニティによって追加された新機能といった利点をご活用、ご体験いただけます。 AWS Glue – ジョブキューイングの提供 を開始しました。Glue ジョブを開始するにあたってクォータまたは制限が不十分な場合、AWS Glue は自動的にジョブをキューに入れ、制限が解放されるのを待つようになりました。 Amazon DynamoDB – テーブルとインデックスの属性ベースのアクセス制御 (ABAC) のサポート を開始しました (限定プレビュー)。ABAC は、ユーザー、ロール、AWS リソースにアタッチされたタグに基づいてアクセス権限を定義する承認戦略です。詳細については、この データベースのブログ記事 をご覧ください。 Amazon Bedrock – Stability AI の上位テキスト画像変換モデル (Stable Image Ultra、Stable Diffusion 3 Large、Stable Image Core) が利用可能 になり、高品質のビジュアルを迅速かつ正確に生成できるようになりました。 Amazon Bedrock Agents – Anthropic Claude 3.5 Sonnet のサポート を開始しました。これには、開発者とエンドユーザーのエクスペリエンスを向上させる、関数呼び出しでの Anthropic 推奨 ツールの使用 も含まれます。 Amazon Sagemaker Studio – Studio ノートブックから直接 Amazon EMR Serverless を使用 して、インタラクティブにクエリ、検索、視覚化を行い、 Apache Spark ジョブを実行できるようになりました。 Amazon SageMaker – トレーニングジョブ、モデル、エンドポイントのリソースクラスなどの SageMaker リソースを操作するためのオブジェクト指向インターフェイスを提供する、新しい Python SDK である sagemaker-core をご紹介 します。 AWS AppSync – GraphQL API に DEBUG ログレベルと INFO ログレベルを含める ことで、モニタリングを改善しました。ログの冗長性をより細かく制御できるようになったため、API のトラブルシューティングが容易になると同時に、読みやすさとコストが最適化されます。 Amazon WorkSpaces Pools – Windows 10 または 11 のライセンスを持ち込む ことで、オンプレミスデスクトップと仮想デスクトップを切り替えても、一貫したデスクトップエクスペリエンスを提供できるようになりました。 Amazon SES – 最適なセットアップの推奨事項や、 Virtual Deliverability Manager による E メールの配信性を強化するオプションなど、SES の主要な機能を発見して有効化するのに役立つ、新しい 強化オンボーディングエクスペリエンス です。 Amazon Redshift – Amazon Redshift Data API がセッションの再利用のサポート を開始しました。これにより、あるクエリ実行から別のクエリ実行までセッションのコンテキストが保持され、同じデータウェアハウスへのクエリを繰り返す際の接続セットアップレイテンシーが短縮されます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Amazon Q Developer コードチャレンジ – シドニーで開催された 2024 年の AWS Summit では、2 つのチーム (片方のチームは Amazon Q Developer を使用し、もう片方のチームは使用しない) がコーディングの腕前を競いました。基本的な計算と文字列の操作から始めて、複雑なアルゴリズムや難解な暗号のコーディングまで行いました。 結果をご覧ください 。 AWS、Gartner 初の Magic Quadrant for AI Code Assistants でリーダーに選出 – 新しいテクノロジーが、ソフトウェア開発ライフサイクル全体を容易にし、開発者の生産性を向上させているのを見るのは素晴らしいことです。 LlamaIndex と Amazon Bedrock で強力な RAG パイプラインを構築 – シンプルなユースケースも高度なユースケースも含む、詳細なチュートリアルです。 Amazon Bedrock のプロンプト管理とプロンプトフローを使用したプロンプトの大規模な評価 – 自動プロンプト評価システムを実装して、プロンプト開発を合理化し、AI 生成コンテンツの全体的な品質を向上させています。 Amazon Redshift データインジェストオプション – 利用可能なインジェスト方法の概要と、さまざまなユースケースでの動作について説明します。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今年の AWS Summit は終了間近です。まだご登録いただけるのは、 トロント (9 月 11 日) と オタワ (10 月 9 日) の 2 つです。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。今後開催される AWS Community Day は、Antje Barth が基調講演を行うサンフランシスコベイエリア (9 月 13 日)、 アルゼンチン (9 月 14 日)、 アルメニア (9 月 14 日)、 DACH (ミュンヘン、9 月 17 日) です。 AWS GenAI Loft – クラウドと AI に関する AWS の専門知識を示すコラボレーションスペースと没入型体験です。また、スタートアップや開発者に、AI 製品やサービスへの実践的なアクセス、業界のリーダーとの限定セッション、投資家や仲間との貴重なネットワーキングの機会を提供します。 お近くの GenAI Loft の開催地を見つけて 、ご登録ください。 近日中に開催されるすべての AWS による対面およびバーチャルイベント は、こちらで閲覧することができます。 9月9日週はここまでです。9月16日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。 この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします!

2024 年 7 月と 8 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Cost Anomaly Detection AWS Cost Anomaly Detection は、機械学習モデルを使用して、AWS サービスの異常な支出パターンを検出して警告する機能です。本セッションでは、AWS Cost Anomaly Detection の概要、基本的な利用方法およびよくある質問について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS サービスのコスト異常を検出したい方 想定外のコスト発生時に迅速に対応したい方 AWS Cost Anomaly Detection の概要・基本的な利用方法を知りたい方 本 BlackBelt で学習できること AWS Cost Anomaly Detection の概要、基本的な利用方法について学んでいただけます コストモニターやしきい値などの設定例などについても学んでいただけます スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon ECS 入門 AWS の提供する、フルマネージド型のコンテナオーケストレーションサービスである、Amazon Elastic Container Service (Amazon ECS) をご存じでしょうか？本セッションでは、Amazon ECS の概要やその構成要素、振る舞いについて解説し、今から Amazon ECS を始めるために役立つ様々なリソースをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用予定のアプリケーションまたはインフラ担当者 Amazon ECS の概要や始め方を知りたい方 クラウドの既存ワークロードのコンテナ化を検討中の方 オンプレミスのコンテナワークロードのクラウド移行を検討中の方 本 BlackBelt で学習できること Amazon ECS とはどんなサービスなのか Amazon ECS の構成や動作概要 Amazon ECS の始め方 スピーカー 吉田 英史 ソリューションアーキテクト Amazon MemoryDB Amazon MemoryDB は耐久性をもったインメモリデータベースという新しいデータベースです。本セッションでは、Amazon MemoryDB の特徴と機能、ユースケースといった基礎的な部分から、バックエンドの動きやどのように耐久性を担保しているのかという技術的背景をまとめて解説致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon MemoryDB とは何かを知りたい方 Amazon MemoryDB をご利用予定の方 Amazon ElastiCache や Redis をご利用中で、より耐久性を高めたい方 本 BlackBelt で学習できること Amazon MemoryDB の特徴と機能 Amazon MemoryDB のユースケース どのように耐久性を担保しているのか 他のサービスとの使い分け、有効な活用方法 スピーカー 堤 勇人 ソリューションアーキテクト AWS MGN プライベートネットワーク経由でサーバを Amazon EC2 へ移行する方法 AWS Application Migration Service(AWS MGN) は、お客様のアプリケーションを AWS に移行するために推奨される主要なサービスです。本セッションでは「プライベートなネットワークを利用した AWS MGN による移行」を実施する方法を学習することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インターネット経由の経路が用意できない場合などに、プライベートなネットワークを用いた移行方法について理解したい方 AWS MGN の機能についてより詳しく理解したい方 本 BlackBelt で学習できること AWS MGN による移行に必要な通信要件 AWS MGN のプライベートなネットワーク経由での移行を実現する追加作業 スピーカー 鈴木　槙将 ソリューションアーキテクト Amazon CloudFront EdgeComputing 編 Amazon CloudFront の EdgeComputing に関するセミナーです。EdgeComputing の種類、実装方法、ユースケース等について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 CloudFront の利用を検討される方またはご利用中の方 EdgeComputing の CloudFront Functions / Lambda@Edge に興味がある方 本 BlackBelt で学習できること CloudFront Functions / Lambda@Edge の実装、使い所、ユースケース スピーカー 小林 謙介 パートナーセールスソリューションアーキテクト Amazon Connect のユーザー管理（Amazon Connect 再入門シリーズ） 本セッションでは Amazon Connect のユーザー管理の全体像についてご紹介します。Amazon Connect で利用できる ID 管理方式や、ユーザー管理に関連した各種機能、セキュリティ面からの注意点について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect を導入検討されていて、 Amazon Connect のユーザー管理方式やセキュリティについて全体的に理解したい方 Amazon Connect を既に導入済みで、 現行の Amazon Connect 環境のユーザー管理方式やセキュリティについてレビューを実施したい方 本 BlackBelt で学習できること Amazon Connect における ID 管理の全般的な機能について Amazon Connect のユーザー管理においてセキュリティ面から注意すべき点について スピーカー 遠藤 亘 ソリューションアーキテクト SaaS 成功のための基礎戦略と AWS 活用法　〜 SaaS 入門編〜 SaaS サービスを開発する際に必要な知識を解説するシリーズが登場しました。今回は、これから SaaS ビジネスを立ち上げる方や、既存のパッケージサービスを SaaS 化する際に必要な知識をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 SaaS についての基礎知識をつけたい方 自社サービスの SaaS 化を検討されている方 顧客向けに SaaS サービスの構築を提案されたい方 本 BlackBelt で学習できること SaaS を構築する際の基礎的な考え方 スピーカー 前田 進吾 ソリューションアーキテクト SaaS 成功のための基礎戦略と AWS 活用法 〜 SaaS Business 基礎編 〜 SaaS サービスを開発する際に必要な知識を解説するシリーズです。今回は、これから SaaS ビジネスを立ち上げる方や、既存のパッケージサービスを SaaS 化する際に必要な知識をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 SaaS についての知識が不安な方 SaaS プロダクトの開発を始める方 パッケージの SaaS 化を検討している方 本 BlackBelt で学習できること SaaS プロダクトを作るときのフェーズについて説明します。特に AWS がお勧めしている SaaS Journey Framework について解説し、自社の企業タイプに合った SaaS Journey の進み方について学ぶことができます。 スピーカー 遠藤 宣嗣 ソリューションアーキテクト SaaS Builder Toolkit for AWS (SBT) の紹介 AWS がオープンソースで開発する SaaS Builder Toolkit for AWS (SBT) の概要と使い方について紹介します。SBT は、SaaS 開発・運用のベストプラクティスが実装された再利用可能なツールキットです。SBT を活用することで、開発工数を抑えながら、ベストプラクティスに準拠した SaaS のコントロールプレーンを構築することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS で SaaS の構築を検討中の方 SaaS のベストプラクティスについて深く学びたい方 SaaS の開発、運用に携わっている方 本 BlackBelt で学習できること SaaS 開発/運用のベストプラクティス SaaS コントロールプレーンの構築方法 SaaS on AWS のリファレンスアーキテクチャ スピーカー 櫻谷広人 パートナーソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2024-09 AWS IoT Greengrass 開発運用編 ソリューションアーキテクト 宇佐美雅紀 2024-09 AWS Shield Advanced ソリューションアーキテクト 岡 豊 2024-09 AWS Fargate 入門 ソリューションアーキテクト 吉田 英史 2024-09 AWS Payment Cryptography ソリューションアーキテクト 松原 武司 2024-10 Amazon EKS 入門 ソリューションアーキテクト 鈴木 祥太