Background : 背景 現在、放送、ライブストリーミングそしてビデオ配信をオンプレミスの素材またはローカルネットワークの送信先に行うお客様には、ライブビデオワークフローを構築する際にさまざまな選択肢があります。これらのオプションにはすべてトレードオフがあり、オンプレミスとクラウドの両方でのハイブリッド展開が必要な場合に理想的なものはありません。 お客様は、アマゾンウェブサービス (AWS) から AWS Elemental Live などのオンプレミスのエンコーディングアプライアンスおよびソフトウェアを購入してデプロイできます。ただし、アプライアンスを維持し、ソフトウェアを最新の状態に保つための運用コストは、新機能の導入やビデオ品質の向上を妨げる可能性があります。お客様がオンプレミスとクラウドの両方のライブビデオワークフローをハイブリッドに導入している場合、管理と監視の複雑さは増すばかりです。また、クラウドへの移行を希望するお客様は、すでにデータセンターにハードウェアを導入しているか、長期リース契約を結んでいる場合があります。 多くのお客様が AWS Elemental MediaLive ( MediaLive ) のフルマネージド機能の使用を希望しますが、serial digital interface (SDI) などのビデオ素材はオンプレミスに固定されています。これを解決する 1 つの方法は、 AWS Elemental Link などのクラウド制御デバイスを使用することですが、これらのデバイスはマルチチャネル環境のニーズや、エンコード設定を正確に制御したい場合のニーズを満たさない可能性があります。また、お客様によっては、ローカルで管理されたコンテンツ配信ネットワーク (CDN) またはパッケージャーでのラストマイル配信のエンコーディングを必要とし、この処理のためにクラウドへのストリームの往復を行うと、不必要な複雑さとコストが増えます。 Introducing AWS Elemental MediaLive Anywhere : AWS Elemental MediaLive Anywhere のご紹介 AWS Elemental MediaLive Anywhere は MediaLive の機能で、管理にクラウドを利用しながら、オンプレミスでライブ動画エンコードを実行できます。その名の通り、MediaLive を使用してほぼどこからでも動画をエンコードできるようになりました。MediaLive Anywhere はお客様のハードウェアにデプロイされ、ビデオ処理はオンプレミスで実行され、構成、制御、監視、および管理タスクはクラウドで実行されます。MediaLive Anywhere を使用すると、ハイブリッドワークフローの運用を改善し、ビデオの転送を最小限に抑え、オンプレミスのビデオ素材と送信先に接続できます。 AWS Elemental の GM である Manish Rao 氏は次のように述べています。「ライブ動画素材をクラウドに移行できない場合、MediaLive Anywhere がクラウドをあなたの元に運んでくれます。動画素材や送信先がオンプレミスで固定されている場合や、引き続き使用したいコンピューティングリソースがある場合、MediaLive Anywhere は MediaLive と同じ優れた機能、API、監視ツール、コンソール、従量課金制の価格設定を提供して、あらゆる場所でのエンコーディングを可能にします。」 Streamline live video operations and simplify on-premises encoding : ライブビデオの運用効率化とオンプレミスのエンコーディングの簡素化 MediaLive Anywhere を使用すると、一貫性のある API、チャンネルプロファイル、ログ、およびメトリックを使用して、ハイブリッドまたはオンプレミスのビデオエンコーディングを管理できます。オンプレミスの場所が複数ある場合でも、全てのチャネルを 1 か所で設定、制御、監視できます。MediaLive Anywhere でチャンネルを開始するたびに、最新の機能やアップデートが提供されます。ソフトウェアアップデートを心配することなく、新しいコーデックやエンコーディング品質などの最新のビデオ処理機能を利用できます。 Netflix のライブ エンコーディング テクノロジーのシニア エンジニアリング マネージャーである Flavio Ribeiro 氏は以下のように述べています。「 AWS Elemental MediaLive Anywhere は、加入者にライブ動画を配信する方法を変革する能力を持っています。オンプレミスとクラウドのワークフロー間の一貫性のあるエクスペリエンス、自動化されたソフトウェアアップデート、統合サポートにより、新しいビデオワークロードをどこにでも簡単に展開して制御できるようになります。」 SDI などのオンプレミスに固定されたビデオ素材や、マネージド CDN やパッケージャーのようなローカルネットワークの送出先がある場合は、接続性が重要です。MediaLive Anywhere を使用すると、オンプレミスのビデオ素材をエンコードすることで複雑さを軽減できます。同様に、ライブビデオをローカルネットワークの宛先に送信する必要がある場合に、オーバーヘッドを削減し、クラウドへの不要なストリームの往復を回避できます。 TV 2 Danmark のライブテクノロジー担当スタッフエンジニア、Loke Dupont 氏は次のように述べています。「 MediaLive Anywhere は、オンプレミスとクラウドのライブエンコーディングの運用を大幅に簡素化します。クラウド内の単一ポイントからすべてを制御でき、ソフトウェアのアップグレードを自動的かつ透過的に行うことができるため、運用ではなくユーザーエクスペリエンスに集中する時間が得られます。」 Ease migration and improve streaming efficiency : 容易なマイグレーションとストリーミング効率の向上 特にライブ動画のワークフローがほとんどオンプレミスにある場合は、AWS Elemental Live アプライアンスとソフトウェアが依然として適切な選択である場合があります。AWS とこれらのアプライアンスを再販する AWS パートナーは、2024 年 4 月にリリースされた AWS Elemental Live L900 シリーズアプライアンスの新ラインナップを含め、お客様が自社のデータセンターで使用できる最も汎用性が高く、機能が充実した物理エンコーディングアプライアンスの提供に取り組んでいます。 オンプレミスとクラウドをハイブリッドに導入している場合は、MediaLive Anywhere の方が適しています。加えて、既存設備のリースの期限が切れるのを待っていたり、長期的な設備投資を行っていてクラウドへの移行が遅れたりすることがあります。MediaLive Anywhere は、オンプレミスハードウェアの管理からフルマネージドクラウドエンコーディングへの移行を容易にするように設計されています。ハードウェアによっては、データセンターに導入されたハードウェアをクラウド制御のエンコーダーとして再利用できます。既存の AWS Elemental Live L800 および L900 シリーズのアプライアンスをお持ちのお客様は、数ステップで MediaLive Anywhere に移行できます。 MediaLive Anywhere を使用し従量課金制に移行することで、リニアストリーミングの経済性も向上させることができます。運営しているチャンネルの料金だけを、実行する必要がある時間のみ支払うことで、24 時間 365 日のチャンネルやライブイベントをストリーミングする費用対効果を高めることができます。また、各ハードウェアデバイスで実行するチャネル数を柔軟に選択でき、十分に活用できない可能性のあるソフトウェアライセンスの購入に縛られることもありません。 PBS とその 330 を超える加盟局は、米国民に対する重要な使命を果たすため、商業放送とは一線を画した信頼できる番組を提供し、視聴者を単なる消費者ではなく市民として扱っています。MediaLive Anywhere により、PBS はローカル番組の取り込みと放送局のオンライン視聴者への配信を効率化すると同時に、リニアビデオストリームカタログ全体の運用管理をクラウドに統合できます。 Get started : MediaLive Anywhereを開始する AWS Elemental MediaLive Anywhere は、 AWS パートナー を通じて購入できる従量課金制のサービスとアプライアンスで構成されています。AWS では、お客様がすぐに利用できるよう、ハードウェアの組み立て、統合、テストを行うパートナーから MediaLive Anywhere のハードウェアを購入することを推奨しています。ハードウェアと AWS サービスの両方をパートナーを通じて購入することも、お客様の AWS アカウントを使用してサービスの支払いを行うこともできます。既存の AWS Elemental Live アプライアンスの変更や、代替ハードウェアのオプションを検討するには、 営業担当者 にお問い合わせください。 Bridge Digital Inc. の創設者兼 CEO である Richie Murray 氏は、「 MediaLive Anywhere の販売、統合、優先サポートを提供できることを嬉しく思います」と述べています。「 COTS ハードウェアと MediaLive を組み合わせることで、従量課金制のシーズンイベントに最適な堅牢なハイブリッドソリューションを実現します。AWS Elemental アプライアンスの販売経験が豊富なBridge Digital Inc. は、MediaLive Anywhere をお客様に提供できることを誇りに思っています。」 Insys Video Technologies の CEO、Krzysztof Bartkowski 氏は次のように述べています。「 Insys Video Technologies は、MediaLive Anywhere のローンチパートナーとしてハードウェアを提供し、お客様が Cloud Video Kit を通じてクラウドとオンプレミスのライブエンコーディングワークフローを管理できるようになることを嬉しく思います。当社のインテグレーションにより、お客様は複数のツールや個別のワークフローを実行する必要がなくなります。 drm.cloud サービスによるコンテンツ保護を含む単一のツールを使用して、最適なリソース使用量を選択するだけです。」 LOGIC media solutions GmbH のマネージングディレクターである Jens Gnad 氏は、次のように述べています。「当社のソフトウェア ポータル で AWS Elemental Live Anywhere を使用して AWS が導入した革新的なアプローチに貢献できることを光栄に思います。このハイブリッドソリューションは、クラウドへの移行を進めるお客様に当社が提供している推奨事項と完全に一致しています。ポータル は、アクセスが容易なブラウザベースのフロントエンドを提供しており、お客様のローカルインフラストラクチャ上で MediaLive Anywhere を導入、制御、監視できます。」 Now available : 今すぐご利用いただけます AWS Elemental MediaLive Anywhere は、AWS Elemental MediaLive が利用できるすべての AWS リージョン で利用できます。 詳細については、 AWS パートナーリセラーにお問い合わせ いただくか、AWS ドキュメントの MediaLive Anywhere ユーザーガイド をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はメディアエッジスペシャリストソリューションアーキテクトの長澤、加藤、メディアソリューションアーキテクトの金目が担当しました。原文は こちら をご覧ください。

Amazon SageMaker Data Wrangler には、機械学習 (ML) プロジェクトで最も時間と手間のかかる作業であることが多い機械学習のデータ準備を効率化および加速するためのビジュアルインターフェイスが用意されています。 Amazon SageMaker Canvas は、コードを書かなくても ML モデルを構築してデプロイできる、ローコードのビジュアルインターフェイスです。お客様からのフィードバックに基づいて、我々はSageMaker Data Wrangler の高度な ML 特有のデータ準備機能を SageMaker Canvas に統合しました。これにより、データの準備、 ML モデルの構築、デプロイのための、エンドツーエンドでコード不要のワークスペースがユーザーに提供されます。 SageMaker Canvasでは、MLワークフローの複雑な部分を抽象化することで、コードを記述しなくてもデータを準備し、モデルを構築または使用して、非常に正確なビジネスインサイトを生成できます。さらに、SageMaker Canvasでデータを準備すると、ページの読み込みが最大で10倍速くなり、データ準備のための自然言語インターフェイス、各ステップでデータのサイズと形式を表示する機能、データフローを繰り返し処理するために改善された 置換処理 や 順序変更 など、多くの拡張機能が提供されます。最後に、同じインターフェイスでワンクリックでモデルを作成することも、SageMaker Canvas データセットを作成して基礎モデル (FM) を微調整することもできます。 この投稿では、既存の SageMaker Data Wrangler flows (データ変換処理の一連の流れを定義したもの) を SageMaker Studio Classic から SageMaker Canvas に移行する方法 を示します。SageMaker Canvas にファイルをインポートする前の中間ステップとして、SageMaker Studio Classic から Amazon Simple Storage Service (Amazon S3) にファイルを移動する例を紹介します。 ソリューション概要 大まかな手順は次のとおりです。 SageMaker Studio でターミナルを開き、フローファイルを Amazon S3 にコピーします。 Amazon S3 から SageMaker Canvas にフローファイルをインポートします。 前提条件 この例では、フローファイルを Amazon S3 に移行するためのステージングフォルダとして data-wrangler-classic-flows というフォルダを使用します。移行フォルダを作成する必要はありませんが、この例では SageMaker Studio Classic のファイルシステムブラウザ部分を使用してフォルダが作成されています。フォルダーを作成したら、関連する SageMaker Data Wrangler フローファイルを慎重に移動して統合してください。次のスクリーンショットでは、左側のペインに表示されているように、移行に必要な 3 つのフローファイルが data-wrangler-classic-flows フォルダーに移動されています。これらのファイルの 1 つである titanic.flow が開き、右側のペインに表示されます。 フローファイルを Amazon S3 にコピーする フローファイルを Amazon S3 にコピーするには、次の手順を実行します。 SageMaker Studio Classic で新しいターミナルを開きます。「ファイル」メニューで「ターミナル」を選択します。 新しいターミナルを開いたら、次のコマンドを入力して、選択した Amazon S3 の場所にフローファイルをコピーします (NNNNNNNNN は AWS アカウント番号に置き換えてください)。 cd data-wrangler-classic-flows target="s3://sagemaker-us-west-2-NNNNNNNNNNNN/data-wrangler-classic-flows/" aws s3 sync . $target --exclude "*.*" --include "*.flow" 次のスクリーンショットは、Amazon S3 同期プロセスの例を示しています。すべてのファイルがアップロードされると、確認メッセージが表示されます。上記のコードは、お客様固有の入力フォルダと Amazon S3 ロケーションのニーズに合わせて調整できます。フォルダを作成したくない場合は、ターミナルに入るときにディレクトリ変更 (cd) コマンドをスキップするだけで、元のフォルダに関係なく、SageMaker Studio Classic ファイルシステム全体のすべてのフローファイルが Amazon S3 にコピーされます。 ファイルを Amazon S3 にアップロードしたら、Amazon S3 コンソールを使用してファイルがコピーされたことを確認できます。次のスクリーンショットでは、元の 3 つのフローファイルが S3 バケットに入っていることを確認しています。 Data Wrangler フローファイルを SageMaker Canvas にインポートする フローファイルを SageMaker Canvas にインポートするには、次の手順を実行します。 SageMaker Canvas アプリケーションのナビゲーションペインで「 Data Wrangler 」を選択します。 [ Import data flows ] を選択します。 [ Select a data source ] で [ Amazon S3 ] を選択します。 [ Input S3 endpoint ] に、先ほど SageMaker Studio から Amazon S3 にファイルをコピーするために使用した Amazon S3 ロケーションを入力し、[ Go ] を選択します。下のブラウザを使用して Amazon S3 ロケーションに移動することもできます。 インポートするフローファイルを選択し、[ Import ] を選択します。 ファイルをインポートすると、次のスクリーンショットに示すように、SageMaker Data Wrangler ページが更新され、新しくインポートされたファイルが表示されます。 SageMaker Canvas にて SageMaker Data Wrangler のデータ変換を使う いずれかのフロー (この例では titanic.flow を選択) を選択して SageMaker Data Wranglerのトランスフォーメーションを起動します。 現在ビジュアルインターフェイス ( Amazon SageMaker Canvas の ML データ準備を高速化 ) または自然言語インターフェイス ( Amazon SageMaker Canvas の新機能で自然言語を使用してデータを探索および準備する ) を使用して、データフローに分析と変換を追加できるようになりました。 データに問題がなければ、プラス記号を選択して [ Create model ] を選択するか、[ Export ] を選択して データセットをエクスポート して ML モデルを構築して使用します。   別の移行方法 このブログでは、Amazon S3 を使用して SageMaker Data Wrangler フローファイルを Amazon SageMaker Studio Classic 環境から移行する方法についてのガイダンスを提供しました。 AWS ドキュメント には、Data Wrangler フローファイルをインポートする他の方法が記載されています。Studio Classic と Canvas アプリケーションが同じ Amazon EFS ストレージボリュームを共有している場合、データフローを Studio Classic の Data Wrangler から SageMaker Canvas の Data Wrangler に移行するためのワンクリックインポートオプションが表示されます。 または、ローカルマシンを使用してフローファイルを転送することもできます。最後に、SageMaker Studio ツリーコントロールからローカルマシンに単一のフローファイルをダウンロードし、Canvas に手動でインポートすることもできます。正解も不正解もありません。使い慣れた方法を自由に選択してください。 Clean up 移行作業が完了したら、SageMaker Studio Classic で実行中の SageMaker Data Wrangler アプリケーションをすべてシャットダウン します。コストを節約するために、 Amazon Elastic File System (Amazon EFS) ボリュームである SageMaker Studio Classic ファイルブラウザからすべてのフローファイルを削除することもできます。Amazon S3 の中間ファイルはどれでも削除できます。フローファイルが SageMaker Canvas にインポートされると、Amazon S3 にコピーされたファイルは不要になります。 完了したら SageMaker Canvas からログアウトし、再び使用する準備ができたら再起動できます。   まとめ 既存の SageMaker Data Wrangler flows を SageMaker Canvas に移行するのは簡単です。これにより、SageMaker Canvas のエンドツーエンドでコード不要の機械学習ワークフローを活用しながら、すでに開発したデータ準備のフローを使用できます。この記事で解説した手順に従うことで、データセットを変換する処理を SageMaker Canvas 環境にシームレスに移行できます。これにより、MLプロジェクトが合理化され、ビジネスアナリストや技術者以外のユーザーがより効率的にモデルを構築してデプロイできるようになります。 今すぐ SageMaker Canvas の活用を始めて、データ準備、モデル構築、デプロイのための統合プラットフォームの力を体験してください！ 著者について Charles Laughlin は、アマゾンウェブサービス（AWS）の主任AIスペシャリストです。Charles はサプライチェーン管理の修士号とデータサイエンスの博士号を取得しています。Charles は Amazon SageMaker サービスチームで働いており、リサーチやお客様の声をサービスロードマップの参考にしています。仕事では毎日、さまざまな AWS のお客様と協力して、最先端の AWS テクノロジーとソートリーダーシップでお客様のビジネスの変革を支援しています。   Dan Sinnreich は Amazon SageMaker のシニアプロダクトマネージャーで、ノーコード/ローコードサービスの拡大に注力しています。彼は ML とジェネレーティブ AI をより身近なものにし、それらを応用して困難な問題を解決することに専念しています。仕事以外では、ホッケー、スキューバダイビング、サイエンスフィクションを読んだりしています。   Huong Nguyen は AWS のシニアプロダクトマネージャーです。SageMaker Canvas と SageMaker データラングラーの機械学習データ準備を率いており、15 年にわたり顧客中心のデータ主導型の製品を構築してきた経験があります。   Davide Gallitelli は、EMEA地域のAI/MLのスペシャリストソリューションアーキテクトです。ブリュッセルを拠点とし、ベネルクス全域のお客様と緊密に連携しています。彼は幼い頃からデベロッパーとして活躍し、7 歳でコーディングを始めました。彼は大学卒業後にAI/MLを学び始め、それ以来ずっとAI/MLに夢中になっています。   翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です

はじめに みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 2024年9月5日に「 AI 時代に技術を活かす！人材と組織、そして活用プロセス構築のポイントを解説！ ～進化し続ける技術を活用するために効果的な組織と人材育成のあり方、そしてそれらを導入する際の課題と対策について学ぶ～ 」を開催しました。 このブログでは、当日参加できなかった方や、参加したけれども内容を振り返りたい方に向けて、ご自身の取り組みの参考としていただくために当日のセッション内容のまとめを紹介します。 セッション内容の紹介 ビジネスを加速させる組織（xCoE）にこれから求められること – 河口 由美子、アマゾン ウェブ サービス ジャパン合同会社 AWS プロフェッショナルサービス本部 プラクティスマネージャー CS&O Advisory – 山泉 亘、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージメント統括本部 シニアカスタマーソリューションマネージャー 本セッションでは、最新の CCoE ストラクチャーの解説を通じて、CCoE が単なるクラウド技術の適用だけではなくビジネスを加速させるため必要であること、サーバント・リーダーシップとも呼ばれる行動特性、そして CCoE にこれから求められることを紹介しました。加えて、AI CoE を例に他専門領域における xCoE の考え方を紹介しました。 エンタープライズのお客様でクラウドを効果的に推進するためには、CCoE（もしくは、クラウドに限定しない xCoE）の立ち上げが必要だという認識は既に多くの方々が持たれていると思います。一方で、そのストラクチャーは汎化が困難であり、他社事例の流用が必ずしも最短経路ではないという認識を持つお客さまもいらっしゃいます。その存在意義や、効果的な立ち振る舞いはどこにあるのか、各社にとって効果的な CCoE はどうやって定義するのかに悩む方々は少なくありません。 本セッションで紹介した本質的な行動特性や考え方は、組織の成長を考え続けるチームである限り変わることがありません。それが、CCoE であっても xCoE であっても、はたまた「CoE」という単語を組織名称に使っているかに関わらず、変わることがありません。技術発展の著しい世の中にあって、その変化を受け入れ、順応し、活用しようとする組織的なメカニズムをぜひ追求してください。 AWSではクラウドであってもAIであっても強化すべきCapabilityを定義しており、これらはテクノロジーの導入をどうビジネス成果に結びつけていくか、ジャーニーのガイド役となります。推進のやり方に悩まれたり、相談する先が必要なときには、ぜひAWSへご相談ください。 参考リンク： 今から始める CCoE、3 つの環境条件と 3 つの心構えとは AI/ML CoE (Center of Excellence) の設立 その他、CCoE に関連するブログ記事（今後随時追加） 資料のダウンロードは こちら から 知識だけでは不足する？！実践力と経験値を磨く体験型学習イベントのすゝめ – 鈴木 宏昌、アマゾン ウェブ サービス ジャパン合同会社 トレーニングサービス本部 シニアラーニングコンサルタント 本セッションではDX推進する際に「クラウドスキル人材育成のために研修を提供したのに、実践力が足りなくて活躍できない」という課題に対して、研修と実践のギャップ構造を埋めるための体験型学習メソッドをご紹介しました。組織横断でクラウド推進を担っているCCoEや、ペーパードライバーではなくプロジェクトに寄与する人材育成方法を模索されるリーダーの皆様に、「なにを学べばよいか」ではなく「成果に繋げるためには、どうやって学べばよいか」という具体的な方法論を持ち帰っていただけたと思います。 ビッグデータ、IoT、コンテナ、サーバレス、生成AIなど様々な技術が次々に生まれ、新たな技術やスキルを使える人材のニーズは日々大きくなっています。そして、それらを学ぶための研修コンテンツも多くの選択肢がありますが、教科書的なInputに終始するため実際のプロジェクトで遭遇するようなシチュエーションや課題を学ぶ機会がありません。そのため現場に入っても時間をかけながら失敗しにくい環境で教科書的な知識を少しづつアップデートするしかないのです。これが「習熟の空白地帯」の正体であり、失敗しにくいからこそ責任範囲を広げにくく、結果としてペーパードライバー化します。 AWS Jamを用いた体験型学習はAWSに関する「習熟の空白地帯」を解消できる１つの方法論です。様々なお客様の現場で発生したトラブル、インシデントや、シチュエーションに応じたベストプラクティスやソリューションを「手順のないハンズオン」として数百ものシナリオにしています。つまり、Inputされた教科書的な知識を使ってAWS Jamのシナリオ解くことで、失敗できる環境のなかで実践味のあるシチュエーションで自分のスキルを試すことができるのです。手順がないハンズオンのため、状況の把握・解決策の調査・仮説検証を繰り返すことになり、知識だけではなく課題解決能力が求められます。さらに、AWS Jamを経て気付いた知識不足や新たな知見を調査・復習してチームにプレゼンテーションすることで、浅い気付きから詳細な理解へ知見を深めつつチーム全体の底上げを行うことができます。 体験型学習の方法論とサイクルはAWS以外の技術にも応用ができます。ぜひ、みなさまの現場でお試しください。 参考リンク： AWS Jam AWS Skill Builder AWS 初学者向けの勉強方法 6 ステップ！2024 年版！ 資料のダウンロードは こちら から AWSへの大規模移行を包括的にご支援 ～ITトランスフォーメーションパッケージの全貌～ – 今井 宏樹、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター統括本部 マイグレーションアドバイザー 本セッションでは、クラウドジャーニーにおけるお客様の課題や懸念を題材に、技術的観点、セキュリティやシステム運用にフォーカスをしがちな移行プロジェクトを、最も重要な要素である「人(People)」「プロセス(Process) 」に向けてどのようにフォーカスするべきか、AWSからのご支援を提供できる包括的支援パッケージ、 IT トランスフォーメーションパッケージ（ITX）と共にご紹介いたしました。 お客様がオンプレミス環境等からクラウドへ移行をご検討される際、AWSの専門チームがお客様へのコンサルティングに利用するフレームワークであるCloud Adoption Framework（CAF）にお客様課題を当てはめた場合、技術的観点の課題が全体の30％程度、各組織毎に状況が異なり主体的に解決が必要である人やプロセスなどの非技術的観点の課題が70％を占めておりました。お客様が最終的なITシステムの稼働を目標にするあまり、どうしても技術的観点から移行プロジェクトの推進（クラウド移行）にフォーカスしてしまいますが、実際はクラウド移行を順調に進める事が出来ているプロジェクトというのは、移行検討、プロジェクトの立上げという前段のステップを確実に実施されているという結果が出ています。そのためAWSでは、このクラウドジャーニーを評価（Assess）・準備（Mobilize）・移行（Migration & Modernization）の「3つのフェーズ」で捉え、それぞれのフェーズでお客様課題に対応する形で必要な支援策をご用意したものがITXになります。 AWSはお客様の移行プロジェクトを成功に導くために、ITXの活用を推奨しています。移行検討のステップ、評価のフェーズでは、オンプレミス環境の経済的現状評価と分析、またクラウド化した場合の経済的評価へのご支援策であるクラウドエコノミクスを利用し、TCO観点の評価を実施するだけではなく、ITに関わる労働生産性の改善やビジネス影響の重要性の評価をきっかけにしたクラウド移行への決断へ繋げる事を推奨しています。またそこからプロジェクトの立上げのステップを視野に入れ、準備フェーズではCAFを利用した組織全体としてのクラウド準備状況評価であるマイグレーションレディネスアセスメントを活用し、組織的な課題、特に人やプロセスの課題を明確にいたします。更にそこから、クラウド推進組織であるCCoE立ち上げ・運用をAWSがご支援する事で、実際のクラウド移行のプロジェクトを成功に導く事ができると考えております。 ITXをご活用頂く事で、クラウドジャーニーにおいてお客様の現状を分析、より重要な人・プロセスに関した課題解決にフォーカスする形で、AWSはお客様のAWSはお客様のクラウドジャーニーを成功へ向けて伴走いたします。 参考リンク： AWS ITトランスフォーメーションパッケージ ファミリー（ITX） クラウド移行を成功させるための設計：5つの落とし穴と停滞の防ぎ方 クラウドジャーニーの歩み方 資料のダウンロードは こちら から おわりに AWSへの大規模なシステムの移行をサポートするITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。これから小林と共に週刊生成AI with AWS を書いていきます。よろしくお願いします！ 「 AWS Innovate 」 が今週の木曜 (9 月 26 日) にオンラインで開催されます。 ”Migrate. Modernize. Build.” をテーマに、生成AI 活用を含むモダナイゼーションの実践方法を学ぶイベントとなっています。インフラ、アプリ、データの各領域で、どう生成AI を活用してモダナイズするかを、エキスパートが分かりやすく解説するセッションを用意しています。ぜひ奮ってご参加ください。 引き続き「 AWSジャパン生成AI実用化推進プログラム 」も募集中です。こちらの方もよろしくお願いいたします。 それでは、9 月 16 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ゼネット様、Amazon Bedrock を活用した e ラーニング向け AI 自動回答システムで講師の工数を削減 株式会社ゼネット様は、 e ラーニング学習用コンテンツ登録プラットフォーム「 Xlabo 」を提供しています。多くの受講生が利用する一方で、受講生からの質問対応やソースコードレビュー対応に講師の時間の半分が取られる、繁忙期には講師の順番待ちで受講生の満足度が低下する、といった課題を抱えていました。そこで、Amazon Bedrock の Claude 3.5 Sonnet を活用した、自動質問回答機能と自動ソースコードレビュー機能を実装しました。Claude 3.5 Sonnet 採用の決め手は、受講生が添付する画像の文字抽出能力とコード理解力の高さでした。システムが24 時間 365 日高い精度で質疑応答できるようになった結果、講師陣が研修の実習時間中に行うサポート工数が半分以下に削減され、受講生の学習効率が大幅に向上するといった効果を得られています。 ブログ記事「RAG の精度を向上させる Advanced RAG on AWS の道標」を公開 RAG (検索拡張生成) は、より高い精度の回答やより高度な応用を実現しようとすると、追加の工夫が必要になるケースがあります。この記事では、RAG を拡張する Advanced RAG の様々な手法や AWS での実装方法を紹介しています。Advanced RAG の各手法の難易度にも触れていますので、RAG の改善を目指している方は是非この記事を道標として参考にされてはいかがでしょうか。 サービスアップデート Amazon Q generative SQL for Amazon Redshift の一般提供を開始 Amazon Redshift では、Redshift Query Editor V2 というウェブベースの Query Editor 機能が提供されています。Amazon Q generative SQL for Amazon Redshift は、Redshift Query Editor V2 上で自然言語で質問を入力すると、生成AI によって推奨の SQLコードが生成される機能です。クエリの作成が簡単になり、生産性向上が期待できます。昨年11月にプレビュー版が出ていましたが、今回一般提供開始となりました。東京リージョンでもご利用いただけます。 AWS Chatbot で、Microsoft Teams と Slack から Amazon Bedrock Agents にアクセスが可能に AWS Chatbot は、Microsoft Teams や Slack を通じた AWS リソースの操作や、これらのチャットツールへの通知転送を実現する ChatOps サービスです。今回、AWS Chatbot を利用して、 Microsoft Teams や Slack のチャットから Bedrock Agents を直接呼び出すことができるようになりました。これまでチャットツールと Bedrock Agents の統合には独自実装が必要でしたが、AWS Chatbot と Bedrock Agents の接続設定のみで統合が可能になっています。 AWS Neuron が、Neuron Kernel Interface（NKI）、NxD Training、JAXサポートをトレーニング向けに導入 AWS Neuron は、生成AI に特化して構築された AWS Inferentia と Trainium インスタンス用の SDK です。このリリースでは、AWS Neuron に Neuron Kernel Interface (NKI) (ベータ版) が導入され、開発者は最適化されたコンピュートカーネルを独自に構築できるようになりました。また、効率的な分散トレーニングを可能にするライブラリである NxD Training と JAX フレームワーク (共にベータ版) も導入されています。詳細については Neuronリリースノート をご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 今週木曜(9/26)は AWS Innovate がオンラインで開催されます。テーマは、”Migrate. Modernize. Build.”で、多くの事例セッション、AWS サービスを利用したモダナイズ手法、生成AIを含む最新のテクノロジー等を学ぶことができます。ご興味ある方はぜひ以下を参照してください。 – AWS Innovate – 2024 年 9 月 26 日 (木) オンライン開催 それでは、先週の主なアップデートについて振り返っていきましょう。この週もかなり発表が多かったため、説明はできるだけシンプルにしています。詳細は原文のWhat’s newや説明中に記載したリンク等を参照してください。 2024年9月16日週の主要なアップデート 9/16(月) Announcing general availability (GA) of Amazon Q generative SQL for Amazon Redshift – AWS Amazon Redshift Query Editor v2 で Amazon Q による生成AIアシスト機能が一般提供開始（GA）になりました。自然言語で表現した内容からSQLを生成させるなど、クエリ作成時にアシストを受けることが可能になっています。 9/17(火) AWS Chatbot now allows you to interact with Amazon Bedrock agents from Microsoft Teams and Slack – AWS AWS Chatbot で Slack および Microsoft Teams のチャネルから Amazon Bedrock Agent とやり取りする機能が追加されました。これまではこういったカスタムチャットの実現にはLambda等で連携コードを作成する必要があったのですが、この機能によりコーディングなしでSlackやTeamsのチャネルからBedrockエージェントを呼び出す仕組みを構築することが可能になります。 AWS Amplify now supports long-running tasks with asynchronous server-side function calls – AWS AWS Amplify は、AWS AppSync API からの非同期の AWS Lambda 呼び出しをサポートするようになりました。この機能により、APIはクライアントへの応答をブロックすることなく、より複雑で長時間実行されるプロセス（長い実行時間を要するGraphQLクエリ等）を処理することが可能です。 AWS Transfer Family increases throughput and file sizes supported by SFTP connectors – AWS AWS Transfer Family で SFTP コネクタが改善され、サポートされる最大ファイルサイズは 150 GB 、最大スループットは 100 Files/秒に増加しました。Transfer for SFTPの機能については、 こちらのドキュメント 、もしくは こちらのハンズオン 資料をご確認ください。 Amazon Keyspaces (for Apache Cassandra) now supports add-column for multi-Region tables – AWS Amazon Keyspaces (for Apache Cassandra) に、既存のマルチリージョンテーブルに列を追加する機能が追加されました。レプリカリージョンの1つでマルチリージョンテーブルのスキーマを変更するだけで、テーブルが存在する他のリージョンにもレプリケーションされます。Amazon Keyspaces (for Apache Cassandra) はサーバーレスで提供される Apache Cassandra 互換データベースサービスです。 Announcing general availability of AWS SDK for Swift – AWS AWS SDK for Swift の一般提供開始（GA）が発表されました。AWS SDK for Swift は、Apple プラットフォーム、AWS Lambda、および Linux ベースの Swift on Server アプリケーションからAWSにアクセスするための、モダンで使いやすいネイティブ Swift インターフェイスを提供するSDKです。詳細は こちらのブログ をご覧ください。 AWS CodeBuild now supports managed GitLab runners – AWS AWS CodeBuild で、 Managed GitLab self-hosted runner がサポートされました。GitLabの CI/CD ジョブイベントを(Webhook経由で)受信したことをトリガーに CodeBuild で一時的にホストして実行するようプロジェクトを構成できます。詳細は こちらのドキュメント をご覧ください。 Amazon S3 Express One Zone now supports AWS-KMS with customer managed keys – AWS Amazon S3 Express One Zone で、AWS Key Management Service による、ユーザー管理するキーを使用したサーバーサイド暗号化 (SSE-KMS) がサポートされました。デフォルトでは、S3 Express One Zone は S3 Managed Key (SSE-S3) を使用してすべてのオブジェクトをサーバーサイドで暗号化しています。詳細は こちらのブログ をご覧ください。 9/18(水) Amazon Corretto 23 is now generally available – AWS AWS が提供する、無料で商用利用可能な OpenJDK ディストリビューション、 Amazon Corretto 23 が利用可能になりました。 こちらのページからダウンロード可能 です。Corretto 23 のサポート期間は2025年4月までです（LTSではありません）。 Amazon OpenSearch Service now supports i4g and i4i instances – AWS Amazon OpenSearch Service で、i4g (Gravitonベース) と i4i (INTELベース）のインスタンスが選択可能になりました。それぞれの特徴はこちらのブログをご覧ください（ EC2 I4g 、 EC2 I4i ) 。東京・大阪を含む多くのリージョンで利用可能です。 Introducing Amazon EC2 X8g Instances – AWS Amazon EC2 X8g インスタンスが一般提供開始（GA）になりました。現在、 US East (N. Virginia)、 US West (Oregon)、 Europe (Frankfurt)リージョンで利用可能です。X8g は AWS Graviton4 プロセッサを搭載しており、前世代の X2gd インスタンスと比較して、最大3倍のvCPU数(48vCPU)、最大3倍のメモリ(3TiB)を搭載可能であり、最大60%高いパフォーマンスを提供します。詳細は こちらのホームページ をご覧ください。 9/19(木) AWS Database Migration Service now includes enhanced monitoring – AWS AWS Database Migration Service (AWS DMS) に Enhanced Monitoring Dashbord が追加されました。これにより、複数の DMS タスクの全体、およびカスタマイズされたメトリックを監視したり、特定のレプリケーションインスタンス上のタスクの使用率を視覚化する等、問題の根本原因を特定しやすくなります。本機能は AWS DMS が利用可能なすべての AWS リージョンで利用可能になっています。詳細は こちらのドキュメント をご覧ください。 Amazon SES now offers automated complaint rate recommendations – AWS Amazon Simple Email Service (SES) に Virtual Deliverability Manager (VDM) Advisor が追加されました。VDM Advisor は、メールのcomplaint rate (苦情率)がベストプラクティスで許容されるレベルに近づいたり、それを超えたりした場合にアドバイスを提供するものです。詳細は こちらのドキュメント をご覧ください。 Amazon RDS Performance Insights supports Aurora cluster-level configuration – AWS Amazon RDS Performance Insights が Aurora クラスターレベルでの設定をサポートするようになりました。これにより簡単な操作もしくはAPIコールで Aurora クラスター内のすべてのインスタンスにパフォーマンスインサイトまたは拡張モニタリングを設定できます。 9/20(金) AWS CloudFormation Git sync now supports pull request workflows to review your stack changes – AWS AWS CloudFormation Git sync で、CloudFormation に変更をデプロイする前に、プルリクエストコメントを使用してスタックの変更を確認できるようになりました。CloudFormation は Git リポジトリを監視し、デプロイファイルの変更を検出するたびに、変更セットのデプロイをトリガーします。今回の新機能でこの際に PR レビューが出来るようになり、望ましくない変更を検出しやすくなります。詳細は こちらのドキュメント もしくは ブログ をご覧ください。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

この投稿は、IMSA (International Motor Sports Association) のシステムテクノロジーシニアディレクターである David McSpadden と共同で執筆されました。 図 1: デイトナ 24 時間レースに出場した 10 台の GTP クラスの 1 台 はじめに モータースポーツの世界では、トラック上での車のスピードに合わせてデータも追従する必要があります。IMSA (国際モータースポーツ協会) は、AWS と協力してファンにリアルタイムで車両テレメトリを提供しました。 北米で最高の権威をもつスポーツカーレース団体である IMSA のレースは、4 つの車両クラスが同時にコース走行するという独自の特徴があります。フェラーリ、ランボルギーニ、ポルシェなど多くのメーカーが並走し、最長で 24 時間に及ぶレースで競います。Grand Touring Daytona (GTD) および GTD PRO クラスは一般道を走る車両が選ばれますが、Le Mans Prototype 2 (LMP2) と Grand Touring Prototype (GTP) クラスは最高速度を実現するためのハイパーカーデザインが採用されています。本記事では新たに設けられた GTP クラスの車両、テレメトリ、そして IMSA や AWS がリアルタイムデータを配信する仕組みについて説明します。 GTP クラスの車両 – 自動車の限界を押し広げる GTP クラスの車両は 2023 年に IMSA に導入されました (図 1)。最新のクラスで、ハイブリッドパワートレインを特徴としています。これは従来型の内燃機関 (ICE) と電気モーターとバッテリーの組み合わせです。GTP クラスの車両はグリッド上で最速で、ピットではエンジンの音はなく電気モーターで無音で発進し、ピットロードを進んだ先で内燃機関がバンプスタートし轟音を上げます。この電気駆動からガソリンエンジン始動への移行が、レースファンにとって独特で満足感のある音の調べを生み出します。 毎シーズン、WeatherTech スポーツカー選手権は、最大レースのひとつであるロレックス 24 時間デイトナレース (24 時間のマルチクラスレース) (図 2) から始まります。このロレックス 24 時間レースはマシンとチームの耐久性を試し、限界に挑みます。GTP クラスのハイブリッドシステムの導入により、新しい戦略的課題が生じ、生データへのより速いアクセスが必要となりました。そうです、トラック上の車の速さがが目を引くかもしれませんが、その車から送られるデータの方がさらに速いのです。 図 2: Porsche Penske #7 GTP マシン。2024 年ロレックス デイトナ 24 時間レースの GTP クラスで優勝 ソリューションの概要 テレメトリデータの取得の第一歩は、ソースからです。GTP クラスの車両には 180 を超えるセンサーが装備されており、車両のパフォーマンスのあらゆる側面をカバーするデータを収集しています。これには、エンジン回転数、ハイブリッド車の残り電力、車速、トランスミッションギアなどの指標が含まれます。このデータは、4G LTE 無線モデムを使ってリアルタイムで Amazon Kinesis Data Streams に送信されます (図 3)。 図 3: IMSA レーシングライブテレメトリアーキテクチャ Kinesis Data Streams は、高可用性でフルマネージドの、データ量に応じてスケーリングするサーバーレスのストリーミングデータサービスです。 この場合、データプロデューサーである GTP クラス車両からのデータ量にも対応できます。車両からのテレメトリデータは AWS Fargate 上で実行されるアプリケーションによって Data Stream から取り出されます。Fargate はサーバーレスコンピューティングエンジンで、コンテナイメージをコンピューティングインフラストラクチャを管理する必要なく、スケーリング可能です。 この構成では、Fargate がインバウンドのデータレコードを解析、処理、および補強するためのアプリケーションロジックを提供します。結果として得られるのは、テレメトリデータだけでなく、タイミング、スコア、エントリデータを含む、単一の使いやすいデータストリームです。この処理が完了すると、 AWS AppSync を利用して、データストリームをすべてのコンシューマに向けてファンアウトします。 AWS AppSync は、サーバーレスの GraphQL と Pub/Sub API で、アプリケーションはリアルタイムでデータを照会、更新、発行できます。AWS AppSync は、以前にテレメトリデータを補強した Fargate アプリケーションから更新を受け取ります。加えて、AWS AppSync は、車/レースの過去のメトリクスをいくつか Amazon DynamoDB テーブルに保存します。DynamoDB テーブルには、各周回のリーダーボードのポイントインタイムスナップショットなど、過去のチェックポイントが保管されています。これはライブダッシュボードを補完します。 最後に、Angular アプリケーションは AWS AppSync からアップデートを購読し、ファンがサーキットからでも世界中のどこからでも、リアルタイムでデータを閲覧できるようにします。このウェブページとコードは、 Amazon Simple Storage Service (Amazon S3) バケットにホスティングされ、 Amazon CloudFront でフロントエンドが構成されています。これにより、ダッシュボードページを堅牢で高い可用性を持った静的ウェブホスティングで提供でき、アプリの利用者を数万人単位までスケールすることができます。さらに、Amazon CloudFront がユーザからアプリケーションバックエンドまでの全体的な地理的パスを短縮することで、ライブダッシュボードの待ち時間を削減します。静的サイトが CloudFront ディストリビューションを通して提供されるだけでなく、AWS AppSync API も別の管理された CloudFront ディストリビューションを通して提供され同じ利点を活用します。 車からファンへのデータの流れ全体は 1 秒以内で完了します。ロレックス 24 時間レースでは、650 万件のメッセージが正常に処理され、配信されました。その結果、車のパフォーマンスを把握でき、またファンとのエンゲージメントを深めることができました。 図 4: ロレックス 24 時間レースの観客席から見た、モバイルデバイス上のテレメトリダッシュボード 図 4 はデイトナ国際スピードウェイでモバイル端末に表示されているダッシュボードの実際の様子です。LTE 接続を介して、1秒未満のレイテンシーでファンにリアルタイムの車両テレメトリデータが提供されていました。これにより、レースに非常に没入できるファン体験が提供されました。サイドラインに立つファンは、アプリを使ってリアルタイムでピットストップを監視し、エネルギーの補給状況、タイヤ交換の指示、車両のジャッキアップ状況を確認できました。 図 5: ロレックス 24 で Web ブラウザで表示されたライブテレメトリダッシュボード 会場外の観客は、IMSA.com を訪れると同様の画面を見ることができました (図 5)。今年の ロレックス 24 時間レースでは、このダッシュボードに対する反応は非常に良好でした。レース開始直後にこのアプリケーションが一般に公開されると、数時間のうちにテレメトリダッシュボードには 11,500 人のユニークユーザーから 28,000 件を超えるページビューがありました。レース中に 106 カ国からユーザーがデータを確認したことで、IMSA の国際的な広がりを裏付けることができました。 テレメトリダッシュボードはテレビやラジオの放送室でも大好評でした。リリース直後から、放送スタッフがテレメトリのストリームを分析し、実況に取り入れ始めました。 このようにリアルタイムでデータを利用できると、世界中のレーシングファンに対してより詳しい状況説明ができ、すでにスリリングなストーリーラインに一層の彩りを添えることができます。ロレックス 24 時間レースでデビューして以来、IMSA のレース中継に定着しています。 今後の展望 IMSA と AWS がともに取り組んだ結果、構想から実現まで 4 か月足らずで完了しました。これにより、AWS サービスと既存のワークフローがお互いにいかに簡単に補完し合えるかが証明されました。AWS AppSync と Kinesis Data Streams を活用したこのようなアーキテクチャは、他のスポーツリーグでも簡単に取り入れられ、チームとファンにできるだけ早くデータを届けられるようになるでしょう。2024 年シーズンが進むにつれて、このソリューションのさらなる更新とアップグレードが予想されます。追加のデータソースからの情報や、サステナビリティに関するより深い分析が期待できます。お楽しみに! 本記事は「 Enduring Race Pace: How IMSA delivers real-time GTP telemetry to the fans 」を翻訳したものです。 著者について Ryan Kiel Ryan Kiel is a Senior Solutions Architect for AWS based out of Virginia. As part of AWS Sports, he helps leagues and franchises with their cloud journey on AWS by leveraging best practices and the newest technology. Outside of work, Ryan is a hockey, golf, and motorsports enthusiast. Carlos Valdes Carlos is a Senior Technical Account Manager for AWS based out of Florida. As part of AWS Enterprise Support, he is a technical advocate for his customers, helping to enable them in their cloud journey and accelerate their outcomes. Edmund Chute Edmund is a Specialist Solutions Architect for AWS based in San Francisco, California. As a member of the AWS Worldwide Specialist Organization ’ s Solution Builders team, he collaborates closely with customers to drive innovation through rapid prototyping development. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

Amazon Web Services (AWS) 上で実行されるお客様のアプリケーションでは、個人を特定できる情報 (PII) や保護された健康情報 (PHI) などの機密データを扱う必要がある場合があります。その結果、機密ログデータがアプリケーションの Observability データの一部として意図的または意図せずに記録される可能性があります。包括的なログ記録はアプリケーションのトラブルシューティング、モニタリング、(原因)分析に重要ですが、記録された機密情報はデータセキュリティとコンプライアンスの観点から重大なリスクとなります。 高度に規制された業界の顧客は通常、GDPR、CCPA、HIPAA、SOX、GLBA、PCI DSS、ISO/IEC 27001、SEC サイバーセキュリティガイダンス、州のプライバシー法、FTC 消費者保護法など、多数の厳格なデータ保護規制を遵守する必要があります。データ漏えいや非準拠は、莫大な罰金、訴訟、評判の失墜、事業の中断、システムのダウンタイム、顧客離れにつながる可能性があります。 このブログでは、 Amazon CloudWatch Logs Data Protection を使用してログ内の機密データを検出および保護する方法、データ保護を検証する方法、非準拠の結果を収集および報告する方法を学びます。また、 Amazon CloudWatch アラーム 、通知、さらなる是正アクションを作成する方法についても学び、コンプライアンス要件を満たすために活用できます。 ソリューションの概要 Amazon CloudWatch Logs には、ログ記録されるデータから機密情報を自動的にマスクする CloudWatch Logs Data Protection があります。有効にすると、パターンマッチングと機械学習(ML)ベースのマスクが適用され、クレジットカード番号、社会保障番号などの機密データ種別が「*(アスタリスク)」で置き換えられます。現在、すぐに利用できる多くの マネージドデータ識別子 があり、簡単に、そして大規模に適用できます。さらに、CloudWatch Logs Data Protection では、ビジネスの特定のニーズに合わせて カスタムデータ識別子 を定義する機能もあります。マネージドデータ識別子は、資格情報、金融情報、PII（個人を特定できる情報）、PHI（保護された医療情報）、デバイス識別子を検出できます。この機能は、より細かい制御のためにロググループレベルで有効にしたり、アカウント内のすべてのログに大規模に適用するためにアカウントレベルで有効にしたりできます。 CloudWatch Logs Data Protection を有効にすると、データ保護規制に関する顧客のコンプライアンス要件を次の 3 つの重要な点で満たすのに役立ちます。 機密顧客データは、ロギングシステムに到達する前に匿名化されます。これにより、プレーンテキストデータの漏洩や不正アクセスのリスクを軽減し、以下の機密データを保護することができます。 社内の一般従業員で機密情報を閲覧する権限のない者(内部の脅威に備えるため、信頼できるアクセスのみを許可する考え方に沿った対応) ベンダーやサードパーティシステムが所有するダウンストリームシステム マスキングにより、コンプライアンス監査が簡素化されます。ログには機密データが保護されていることが証明され、元の値をマスキングせずに保存・保護する必要はありません。 マスクは一度定義すれば、簡単にスケールして適用できます。 実現 CloudWatch Logs で データ保護ポリシー を作成する際、アカウントレベルまたは特定のロググループレベルで作成できます。アカウントレベルのデータ保護ポリシーは、アカウント内のすべての既存および将来のロググループに適用されますが、ロググループレベルのデータ保護ポリシーは特定のロググループにのみ適用されます。アカウントレベルとロググループレベルのログデータ保護ポリシーは組み合わせて機能し、特定のユースケースのデータ識別子をサポートします。 CloudWatch Logs Data Protection をロググループレベルで有効化 ビジネスニーズやアプリケーションの設計方法によっては、より詳細な制御のためにロググループレベルでデータ保護を有効にしたい場合があります。 CloudWatch コンソール を開き、Logs > Log Groups 画面に移動します。 対象のロググループを選択し、メニューまたは「データ保護」タブから、データ保護ポリシーを作成します。 図 1. CloudWatch コンソールでデータ保護ポリシーを作成する ビジネスニーズに応じて、マネージドデータ識別子（例えば顧客や商品など、お客様の企業固有のデータ）を選択してください。 監査結果を送信するためのロググループを新規に作成するか、既存のものを選択してください。 監査先の選択は任意ですが、監査とレポーティングのために強く推奨されます。 図 2. データ保護ポリシー構成を保存 CloudWatch Logs Data Protection をアカウントレベルで有効化 アカウントレベルでデータ保護ポリシーを有効にすると、アカウント内のすべてのロググループに適用されるので便利です。これは現在のロググループと、このアカウントの下で今後作成されるロググループに適用されます。 左下の 設定 に移動し、 ログ タブを選択して 設定 を選択します 図 3. データ保護アカウントポリシーの作成 ビジネスニーズに関連するすべての マネージドデータ識別子 を選択し、監査結果の 監査先 を選んで、 データ保護をアクティブ化 します。 図 4. データ保護アカウントポリシーを保存 カスタムデータ識別子の構成 独自のデータ識別子を使用して、独自のカスタム正規表現を定義し、マネージドデータ識別子が利用できない場合のユースケースに対応できます。金融機関の一般的な例は、 SWIFT コード(ビジネス識別コード: BIC)です。SWIFT コードは、ビジネストランザクションのルーティングとビジネス関係者の識別のための国際標準です。SWIFT コードは、金融機関の名称、国、所在地、支店を識別する 8 桁から 11 桁のコードです。SWIFT コードそのものは機密情報ではありませんが、ビジネスニーズに応じてトランザクションログ内で保護することを選択できます。独自のデータ識別子は、マネージドデータ識別子と組み合わせて使用することもできます。また、長期保持のニーズに応じて監査結果を Amazon Simple Storage Service (Amazon S3) バケットに送信したり、リアルタイムストリーミングのために Amazon Data Firehose に送信することもできます。 図 5. カスタムデータ識別子構成を定義する ログ内の機密データのマスク化の検証 ロググループのログを確認することで、機密データがマスクされていることを確認できます。これは CloudWatch Live Tail でリアルタイムに近い形で実行できます。または、 CloudWatch Logs Insights を使用してログデータを照会することもできます。 図 6. ログ内の機密データのマスキングを確認する 図 7. Live Tail で機密データのマスキングを確認する 図 8. Logs Insights での機密データマスキングの検証する 特権アクセスを持つユーザーで非マスク化されたデータを表示する マスクされていないデータを表示する には、 logs:Unmask の権限が必要です。次の CloudWatch Logs Insights クエリの例を使用すると、マスクされていないログを確認できます。 fields @timestamp, @message, unmask(@message) | sort @timestamp desc | limit 20 図 9. 特権を昇格して非マスク化されたデータを表示する 検出結果に対するアラームと通知の定義 CloudWatch は、デフォルトで LogEventsWithFindings という名前のメトリクスを作成し、特定のロググループに機密データが含まれるログイベントの数をカウントします。このメトリクスに基づいて CloudWatch アラームを定義すれば、機密データが検出されたときに通知を受け取り、その後対処アクションを行うことができます。 図 10. 検出結果のデフォルトメトリックによるログイベントのアラームの定義 以下は アラームの定義の例です。期間中のデータポイントの数を集計するために、サンプル数統計を選択します。これは、発生するたびにカウンタが 1 増えます。静的しきい値タイプ、以上条件と、しきい値を 1 に設定します。通知を送信するために、新しい Amazon Simple Notification Service (Amazon SNS) トピックを作成するか、既存のトピックを選択します。通知を受け取るメールアドレスをそのトピックに登録します。 図 11. アラームのメトリクス設定を指定する 図 12. アラームのメトリクス条件を指定する 図 13. アラームに対して SNS トピックへの通知を設定する 機密データ監査の結果と報告 各ロググループの機密データイベント数は、ロググループページで素早く確認できます。 図 14. ロググループページで機密データ件数を確認する コンプライアンスのニーズに従って、機密データの監査結果を CloudWatch Logs に送信することを選択した場合、各ログイベントに対して次の通り監査結果が生成されます。ロググループのリソース ARN とどのデータ識別子を確認することで、機密データが検出されたイベントソースを簡単に特定できます。これらの監査結果を Amazon S3 または Amazon Data Firehose に送信することも選択できます。 図 15. 機密データ監査の検出結果のログイベント構造を表示する まとめ このブログでは、機密データを扱うアプリケーションを持つお客様が、Amazon CloudWatch Logs Data Protection を活用して、ログ内の機密データを検出・保護し、データプライバシー規制の準拠要件を満たす方法をご紹介しました。また、CloudWatch Logs Data Protection を有効にする方法、機密データのマスキングを検証する方法、特権を持つユーザーが非マスク化されたデータを表示する方法、機密データの監査結果を収集して報告する方法、結果に対してアラームと通知を定義し、さらに修復アクションを行う方法についても説明しました。CloudWatch Logs 全体のセキュリティについて詳しくは、 Amazon CloudWatch Logs のセキュリテ ィ をご覧ください。 著者について Sasi Kiran Malladi Sasi Kiran Malladi は AWS の Principal Technical Account Manager です。AWS の最も大規模で戦略的な エンタープライズ企業が AWS をどのように利用するかに直接影響を与えています。Sasi は、経営陣がアジリティを取り入れ、高い影響力のあるクラウド変革を実現し、クラウド ソリューションが高い拡張性、柔軟性、および回復力を持つようにサポートしています。彼は金融サービス業界に深い専門知識を持ち、最大規模の銀行、決済、資本市場、保険会社の顧客と協力してきました。AWS に入社する前は、ソリューション アーキテクト ディレクターとして、お客様のデジタル/クラウド変革とアプリケーション現代化の取り組みをサポートしていました。LinkedIn: linkedin.com/in/sasikiranm David Myers David Myers は、AWS Enterprise Support の Sr. Technical Account Manager です。20 年以上の技術経験があり、キャリアの始まりからObservability が含まれていました。David Myers は Amazon Web Services でお客様が Observability の経験を改善することを愛しています。 本記事は、 How Amazon CloudWatch Logs Data Protection can help detect and protect sensitive log data を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

この記事は Cordial’s journey implementing Bottlerocket and Karpenter in Amazon EKS (記事公開日: 2024 年 8 月 8 日) を翻訳したものです。 概要 Cordial は、マーケティング戦略を完全に自動化するためのツールを提供するクロスチャネルマーケティングプラットフォームです。マーケティングの遂行を自動化することで、Cordial はテクノロジーチームが本来の強みである構築と創造性に集中できるようにします。Cordial の堅牢なプラットフォームを使用して、マーケターにデータアクセスと管理を委任することで、テクノロジーチームを支援します。顧客中心のアプローチで設計された Cordial は、データを活用して創造性を高め、効率を向上させ、コストを削減し、収益性の高い成長を促進する AI (人工知能) 搭載の高速、柔軟、相互接続された一連のツールとサービスを提供します。 2014 年の発足以来、大手企業ブランドは Cordial を選び、メール、SMS、モバイルアプリ、ソーシャルメディア、ダイレクトメールなどを横断して高い転換率のメッセージを自動化し、スケーラブルな収益の促進と長期的な顧客との関係を実現しています。Cordial は 2022 年と 2023 年の Deloitte Technology Fast 500TM で最も成長が早い企業に選ばれ、テクノロジー、成長、企業文化に関する 複数の賞 を受賞しています。 この指数関数的な成長を維持し、将来の拡大に備えるため、Cordial は次世代のインフラストラクチャプラットフォームを構築する旅に出ました。その中核となるコンピューティングプラットフォームは Amazon Elastic Kubernetes Service (Amazon EKS) で、以前のプラットフォームは Amazon Elastic Compute Cloud (Amazon EC2) 上にありました。この記事では、Cordial が Amazon EKS 環境内で Bottlerocket をオペレーティングシステム (OS)、 Karpenter をノードライフサイクルマネージャーとして実装した旅路に迫り、運用効率の向上とセキュリティ体制の改善を目指しました。 セキュリティ体制と運用効率の改善 Amazon EKS を利用する前は、アプリケーションを Amazon EC2 上で実行し、複数の Auto Scaling グループがスケーリングプロセスを容易にしていました。クロスチャネルマーケティングプラットフォームとして、アプリケーションの動作には次の 2 つの重要な原則がありました。 クライアントからのメッセージは即座に送信される必要 クライアントがメッセージ配信をトリガーするたびに、遅延なく即座に送信する必要があります。 クライアントからのメッセージは常に送信される可能性 このサービスのリアルタイム性から、メッセージは予測可能なパターンなしに常に送信される可能性があります クライアントが増えるにつれ、以下のような運用効率と セキュリティ体制の制限に直面しました。 アプリケーションの起動の遅延 コンピューティングのスケーリングの課題 スポットインスタンスなどのコスト効率の良いインスタンス購入オプションが利用できない課題 デバッグのワークフローが非効率的 チャレンジ-1: 起動時間の遅延とコンピューティングのスケーリングの課題 最初の大きな課題は、ノードの起動とアプリケーションの起動にかかる時間でした。インスタンスのユーザーデータスクリプトを使用して、起動時にアプリケーション環境をインストールおよび構成しました。ユーザーデータのシェルスクリプト内で実行された自動タスクには、 Amazon Elastic Block Store (EBS) ボリュームのフォーマットなどの一般的な構成要件、アプリケーションレベルの依存関係のインストール、特定のランタイムパラメータを使用したアプリケーション環境のブートストラップなどがありました。 そのため、アプリケーションがクライアントリクエストを受け付けられるようになるまでに、標準の Amazon EC2 Auto Scaling プロビジョニングプロセスから最大 5 分の遅延が発生していました。この起動の遅さにより、ワークロードの需要に基づいてリアルタイムにキャパシティを追加することができず、これがインスタントメッセージ配信の目標に直接影響を与えていました。 クライアントのリクエストをすぐに処理できるようにするため、一部の容量がアイドル状態になっていたにもかかわらず、常に最大容量を維持する必要がありました。これにより、運用が非効率的なデザインになってしまいました。 チャレンジ-2: スポットインスタンスが利用できない課題 ノードの起動プロセスが 5～10 分かかるため、残念ながらサービス品質を維持しながら Spot Instance の中断 の 2 分間の警告に安全に対応することができませんでした。これにより、Spot Compute の使用が不可能になり、コスト効率が悪くなりました。 チャレンジ-3: セキュリティ強化の課題 当社のソリューションでは、コンプライアンス目標を維持するために、Center for Internet Security (CIS) ベンチマークチェックを備えた汎用 OS を使用していました。将来の成長に向けたソリューションを計画する必要があったため、セキュリティ対策を強化するために、最小限のパッケージ、攻撃対象領域の縮小、そして既定の強化機能を備えたコンテナに最適化された OS を検討する必要がありました。 チャレンジ-4: デバッグワークフローの改善 デバッグのワークフローでは、ワーカーノードにログを記録し、基盤となるノード上のプロセスを監視およびデバッグするために strace ユーティリティをインストールする必要がありました。これはアクセスの観点からセキュリティーリスクとなります。そのため、デバッグパッケージがブートアップ時に既定でインストールされないようにすることが、セキュリティの観点から要件となりました。これにより運用オーバーヘッドも増加し、継続的な監視が必要となりました。 ソリューションの概要 上記の課題に対処するため、私たちは複数フェーズからなる取り組みを開始しました。。 フェーズ-1 では、メッセージングコンポーネントをコンテナ化し始めました。これにより、依存関係が減り、スケーラビリティの問題に対処できるようになります。 フェーズ-2 では、コンテナ化されたアプリケーションの管理、スケーリング、デプロイに必要なコアコンピューティングプラットフォームとして Amazon EKS に焦点を当てました。最初は、マネージド型ノードグループを使用してワーカー ノードをプロビジョニングし、Cluster Autoscaler を使用して必要なスケーリングプロセスを処理する標準的なセットアップから始めました。この結果、ユーザーデータスクリプトの削除に伴う起動時間の短縮など、すぐに成果が得られました。これは、ほとんどの構成が Kubelet レベルまたはコンテナレベルで構成可能だったためです。これにより、アプリケーションの起動プロセスは、当初の 5 〜 10 分の待ち時間から大幅に短縮されました。起動プロセスが高速化したことから、ワークロードの一部のプロセスでスポットインスタンスの実装も開始しました。 このセットアップを迅速に行うには、予想していたよりも複雑で時間がかかりました。さまざまな顧客をオンボーディングし始めると、クラスターには、ユニークな要件とスポットプールの多様性に対応するために、複数のインスタンスタイプ、サイズ、アーキテクチャが必要になりました。Cluster Autoscaler には、いくつかの課題がありました。ノードグループ内で使用されるインスタンスタイプは、正確なスケーリング計算のために同じ RAM と CPU コア数を持つ必要があったためです。これにより、Compute Optimized と General Purpose インスタンスタイプなど、混在したキャパシティのノードグループを作成することができませんでした。さらに、同じ Auto Scaling グループ内で、さまざまなインスタンスサイズやアーキテクチャ (x86 と ARM) のノードグループを作成することもできませんでした。Cluster Autoscaler にはスポット容量を優先し、オンデマンドをフォールバックオプションとして定義するための優先スケーリングの機能がありますが、コントローラーの処理に時間がかかりすぎました。 フェーズ-3 では、スケーラビリティの課題に対処するため、Kubernetes 向けに構築されたオープンソースのノードライフサイクル管理プロジェクト Karpenter を採用しました。Karpenter 内の NodePool カスタムリソース定義 により、複数のインスタンスタイプ、サイズ、アーキテクチャに関する要件を解決できました。Karpenter が “instant” タイプの EC2 Fleet API と連携してノードをプロビジョニングしたことで、ノードの起動時間を 30 秒以下に抑えることができました。また、Karpenter 固有の 中断制御フロー と中断予算を組み合わせることで、未使用の容量を統合し、コスト効率の良い設計を実現できました。 フェーズ-4 では、セキュリティ体制を強化するため、AWS がコンテナ実行用に設計したオープンソースの Linux ベースの OS である Bottlerocket の実装を開始しました。 一般的な Linux ディストリビューションでデフォルトでインストールされているパッケージ、ツール、インタープリター、依存関係の多くは、コンテナをホストするだけでは必要ありません。Bottlerocket はこれらの余分なソフトウェアを除外することでセキュリティオーバーヘッドを改善しました。 Bottlerocket は API 中心の設計を採用しており、Report API を備えています。これにより、OS レベルのレポーティングを自動化するメカニズムが提供されました。 Bottlerocket Report API を使用して、Bottlerocket と Kubernetes CIS ベンチマークに対してレポートを実行できました。 Phase-3 までのソリューションでは、sed (ストリームエディター) を使用して Kubelet の JSON 設定ファイルを直接変更する必要があり、エラーが発生しやすいワークフローでした。しかし、Bottlerocket は Kubernetes 設定を行うための宣言型の TOML 設定フォーマット を提供してくれたため、より簡単に設定ができ、複雑さが低減されました。 Bottlerocket には SELinux の強制モードの設定が組み込まれており、すべての非特権コンテナに制限の厳しい container_t ラベルが付与されます。また、セキュアシェルアクセスを提供しないことで、Bottlerocket は既存のメカニズムと併せて、開発者のデバッグ環境周りに必要なモニタリングフレームワークを安全な方法で実現するのに役立ちました。 図 1: Cordial の Amazon EKS アーキテクチャ 達成された成果と次のステップ 上記の設計を実装した後、次の図に示すように、Horizontal Pod Autoscaler が Custom Metrics を使用するようにすることで、Pod のスケーリングプロセスの改善も開始しました。 Pod Count Tasks in Queue per Pod Amazon EKS、Karpenter、Bottlerocket を使用することで、クラスターのサイズをその時点で必要な作業に合わせて調整し、必要に応じて拡大縮小できます。Karpenter の高速なノードプロビジョニング時間、多様な計算オプション、ノード統合機能により、常にピーク容量で実行する必要がなくなり、運用効率が向上し、ソリューションのコンピューティング部分だけで約 18% のコスト削減と 80% の起動時間改善が実現しました。Bottlerocket の目的別設計と API 中心の設計により、セキュリティが強化され、Karpenter と組み合わせることで、将来のスケーリングに適した設計のソリューションが実現しました。 結論 この記事では、Cordial チームが Amazon EKS、Karpenter、Bottlerocket を実装することでユーザーエクスペリエンスを改善した方法について説明しました。AWS と Cordial の協力により、Cordial のアプリケーション環境のモダナイゼーションが成功しました。また、Cordial がビジネス価値を高めるために、環境をさらに最適化することに注力していることも説明しました。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

本ブログは株式会社ゼネット様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの山澤です。 最近、 IT 関連市場規模の拡大に伴い、年々 IT 人材のニーズが高まっているという話をよく耳にします。 このような状況において、講師の負担を最小限に抑えつつ、いかに効率的に IT エンジニアを育成するかは、非常に重要なテーマではないでしょうか。 本記事では、このような課題に対する取り組みとして、株式会社ゼネット様の事例をご紹介します。同社は IT エンジニア向けの e ラーニングシステムに、 Amazon Bedrock を活用した自動質問回答機能と自動ソースコードレビュー機能を導入しました。これにより、受講生からの質問やソースコードレビューに素早く対応できるようになり、同時に講師の生産性も大幅に向上しました。 お客様の状況と検証に至る経緯 株式会社ゼネット様は、 e ラーニング学習用コンテンツ登録プラットフォーム「 Xlabo 」を提供しております。新人向けの Java 研修、 Ruby 研修、 AWS 研修など、様々なプログラムを通じて、実務で活躍できる IT エンジニアの育成に力を入れてきました。現在では年間 100 名以上の受講生を受け入れるほどまで事業を拡大し、リピート率も高い研修となっておりますが、以下のような課題感がありました。 IT 技術者に向けた研修を実施している中で、受講生からの質問対応やソースコードレビュー対応に講師の時間の半分が取られている 繁忙期は受講生が 50 名を超えることもあり、講師の順番待ちなどで受講生自体の満足度が低下する そこで、Amazon Bedrock を利用し、生成 AI による自動での質問回答を行うことで、上記の課題解決に向けて、検証することになりました。 お客様が開発された生成 AI を活用した受講生向け機能 株式会社ゼネット様は、 Amazon Bedrock の Claude 3.5 Sonnet を活用し、 2 つの新しい機能を開発しました。お客様曰く、これらの機能は、実際の講師と同じくらい、あるいはそれ以上の精度で回答できるようになっているとのことです。 1. 自動質問回答機能 まずは、質問への回答の面で受講生をサポートする機能を公開されています。ただ、質問に答えるだけではなく、質問をより適切な質問にブラッシュアップするサポートもされている点が特徴的です。 例えば「エラーで躓いています。エラーのデバッグ方法を教えてほしいです。」という、ファジーな質問に対して、以下のような質問内容へのアドバイスと、より良い質問の提案をレコメンデーションすることで、期待する回答が返ってきやすい質問にするサポートをします。 また、画面キャプチャなど画像付きで質問されたい受講生も多くいらっしゃいます。そのため、テキストだけではなく、画像を質問の入力に加えていただき、「添付画像の問題が理解できませんでした。解説をお願いします。」のような質問を受け付けられるようにしているのも特徴的です。 このようなサポートは初めての技術を学ぶ受講生にとって、ありがたい機能なのではないでしょうか？ この機能は、図が示すとおり、2 つのフェーズで構成されています。 Phase 1 ：質問内容をチェックし、より良い質問の仕方を提案します。これにより、受講生の質問する能力を向上させます。 Phase 2 ：質問に対する回答を作成します。 2. 自動ソースコードレビュー機能 次に、受講生が提出したプログラムコードをレビューする機能も公開されています。 設問作成者があらかじめレビューの観点を登録しておくことで、 LLM （大規模言語モデル）によるレビューの範囲を制限しています。これにより、受講生がまだ学んでいない内容を含めた指摘がされないように実装されています。 また、プログラムの実行やレビュー観点でのチェックで問題がなかった場合には、プラスアルファで学ぶと良い知識を提供します。提出されたコードに対するアドバイスを LLM にさせると、学習者がまだ習得していない表現や文法を含めた内容を生成してしまう可能性があります。そのため、設問の条件などを考慮し、受講生の学習進度に合わせたアドバイスをされている点が特徴的です。 例えば、「プログラムの終了には “System.exit(0);” を使うこと」という指示のある Java 言語に関する設問に対して、指示に従ってコードを記述した場合、 LLM は「 System.exit(0) の使用は一般的にはメインメソッド内で避けるべきです。代わりに、エラー処理を行うメソッドを作成し、早期リターンを使用することで、コードの可読性と保守性が向上します。」といったアドバイスがされる可能性があります。このような設問条件に矛盾するアドバイスが提供されないように実装されています。 この機能は、図が示すとおり、3 つのフェーズで構成されています。 Phase 1 ： プログラムを実行します。実行の結果、エラーが発生した場合には、LLM を用いて、ユーザに対して、実行エラーの解説をします。 Phase 2 ：プログラムの実行でエラーが発生しなかった場合は、 LLM を用いて、設問作成者があらかじめ登録したレビュー観点を基にチェックをします。レビューで問題がある場合は、ユーザに対して、レビューの結果をお伝えします。 Phase 3 ：レビュー観点を基にチェックで問題がなかった場合は、LLM を用いて、ユーザーに対して、プラスアルファで学ぶと良い知識をお伝えします。ただし、学習者がまだ習得していない表現や文法を含む情報を LLM が生成する可能性があるため、 LLM を用いて出力内容が設問の範囲内であるかを確認し、未学習の表現や文法を含む知識が提供されないよう対策を講じています。 プロンプトの工夫に加えて、このようにステッププロンプト（一度きりの命令ではなく、複数のステップに分けて回答を生成する手法）を採用することで回答の精度を大きく向上させることに成功されたとのことです。 精度の検証と結果 また、お客様は、複数の LLM の性能評価を実施されました。以下 2 つの重要な観点において、Claude 3.5 Sonnet が優れた精度を確認されたため、システムへの採用を決定されました。 1. 画像認識と文字抽出能力 Claude 3.5 Sonnet は、画像内のテキストや数値を高精度で認識し、正確に抽出することができました。これにより、自動質問回答機能で、学習者が以下のような設問の画像を添付し、質問をすることが可能となりました。 2. コード構造の理解と再現能力 Claude 3.5 Sonnet はソースコードのインデントやスペースといった構造要素を高い精度で認識し、必要に応じて指摘することができました。これにより、自動ソースコードレビュー機能で、学習者が提出したコードの形式や構造の適切さを正確に評価し、より質の高いフィードバックを提供することが可能となりました。 導入効果 システムをリリースした結果、以下 2 つの効果を得ることができました。 24 時間 365 日の質疑応答が実現でき、かつ 1 分以内での回答が可能になった。これによって受講生の学習効率が大幅に向上した 質問応答をシステムに託したことで、講師陣が研修の実習時間中に行うサポートの工数が半分以下に削減された 今回のアプローチでは、LLM が出力する内容を受講者の習得範囲内に制限しています。このしくみにより、受講者の学習進捗状況に合わせた形で、プラスアルファの知識を提供することができました。このような機能は、教育関連のシステムを提供しているお客様にとって有用ではないかと考えています。 まとめ 今回は、 Amazon Bedrock を活用して、e ラーニング向けシステムに自動質問回答機能と自動ソースコードレビュー機能を追加したお客様事例をご紹介いたしました。LLM の進歩により、テキスト処理だけでなく画像認識も可能になり、AI をより幅広い場面で活用できるようになったと実感しています。AWS を使った生成AIの活用に興味をお持ちの方は、お気軽にご相談ください。 また、今回紹介した「Xlabo」は、 2025 年 1 月からプラットフォーム型のサービスとして販売を予定しています。現在、無料モニターを募集中ですのでご興味のある方は、 こちら からお問い合わせください。 株式会社ゼネット : システム事業部 西島 由祐様（右から 2 番目）、武内 潤一様（左から 2 番目） Amazon Web Services Japan : アカウントマネージャー 浜崎 佳子（左端）、ソリューションアーキテクト 山澤 良介（右端） [Appendix] アーキテクチャ 今回の記事では、お客様が力を入れて取り組まれた生成AIの活用についてご紹介することに重点を置いたため、アーキテクチャの細かい説明は割愛しますが、これらの機能は、インフラストラクチャの管理、運用負荷の少ないマネージドサービスで構成されています。 ソリューションアーキテクト 山澤 良介 (X – @ymzw230 )

本投稿は、Director of Solutions Architecture for Search Services at Amazon Web Services である Jon Handler によって 2024 年 9 月 16 日に投稿された 記事 の日本語版です。 私は常に検索にまつわる課題を愛してきました。検索の本質は、質問を受け取り、その質問を理解し、そして最適な回答を取得することです。私は博士課程で AI ロボティクスのプロジェクトを主導し、計画フラグメントのライブラリを検索を通じて実世界の状況と結びつけました。以前の仕事では、商用検索エンジンを一から構築しました。そして AWS でのキャリアでは、ソリューションアーキテクトとして働き、顧客が様々な形態の検索サービスを採用するのを支援してきました。 多くの開発者と同様に、私もオープンソースに情熱を持っています。これは、学者が自分の分野での過去の業績を基礎にし、そこから恩恵を受けて、より大きな利益のために働くという私の学歴に部分的に由来するものです。私は、単一の目的を持つ小規模なプロジェクトから、熱心で積極的なコミュニティを持つ大規模なイニシアチブまで、数多くのオープンソース技術を使用し、貢献してきました。検索コミュニティは、独自の特別で学術的な趣があります。検索自体が情報検索、心理学、(象徴的な) AI といった長年の学術的な取り組みに関連しているからです。オープンソースソフトウェアはこのコミュニティで重要な役割を果たしてきました。検索技術は、特に過去 10-15 年の間に、Apache Lucene、Apache Solr、Apache ライセンス 2.0 バージョンの Elasticsearch、そして OpenSearch のようなオープンソースプロジェクトを通じて民主化されてきました。 本日、Linux Foundation が OpenSearch Software Foundation を 発表 したことに、私は非常に興奮しています。 OpenSearch Foundation 創設の一環として、AWS は OpenSearch の所有権を Linux Foundation に移管しました。 2021 年 4 月のプロジェクトの立ち上げ時に OpenSearch を紹介 するにあたって、私たちは「ユーザーが安全で高品質な、完全にオープンソースの検索および分析スイートを、新しい革新的な機能の豊富なロードマップとともに継続して利用できることを確実にする」という希望について話しました。私たちはその願いとコミットメントを維持しています。今回の移管によりそのコミットメントを深め、オープンなガバナンスを備えたより広範なコミュニティを取り込んで、その目標を支援します。 この発表に関して、 2 つの重要なポイントがあります。一つは、 Amazon OpenSearch Service の顧客にとっては、何ら変更がないという点です 。他方、オープンソース側では多くのことが変わり、それはサービスにとって純粋な利益となります。私たちは、コミュニティとのより深い協力と参加によって推進される、OpenSearch プロジェクトのイノベーションの加速を含む未来に向かって進んでいます。最終的には、それらがサービスに反映され、AWS の顧客に利益をもたらすことになります。 Amazon OpenSearch Service: これまでの取り組み Amazon は、当初よりオープンな環境で OpenSearch に取り組むことに焦点を当てていました。最初の課題は、コードのインポートと名前変更機能を備えた作業用コードベースをリリースすることでした。2021 年 7 月に OpenSearch 1.0 をローンチし、2021 年 9 月にマネージドサービスを Amazon OpenSearch Service に改名しました。Amazon OpenSearch Service のローンチに合わせて、エンジンの選択肢として OpenSearch 1.0 のサポートを発表しました。 Amazon のチームとコミュニティが OpenSearch プロジェクトで成長し、イノベーションを起こすにつれて、私たちはそれらの変更を対応するバージョンのサポートとともに Amazon OpenSearch Service にもたらしました。AWS では、コミュニティと共同でアイデア、RFC、機能リクエストを公開し議論することで、オープンソースを受け入れました。時間が経ち、プロジェクトが進むにつれて、コミュニティのメンテナーを採用し、AWS 内外の様々なソースからの貢献を受け入れました。 Amazon OpenSearch Service の顧客として、今後もオープンソースからマネージドサービスへの更新と新バージョンの流れを見ることができるでしょう。また、プロジェクト、そのコミュニティ、およびコードベースの成長に対する私たちの投資によって推進される継続的なイノベーションを体験することになります。 現在、OpenSearch プロジェクトは 7 億回以上のソフトウェアダウンロード、数千人のコントリビューター、200 人以上のプロジェクトメンテナーの参加により、大きな勢いを得ています。OpenSearch Software Foundation は、プレミアメンバーとして AWS、SAP、Uber、一般メンバーとして Aiven、Aryn、Atlassian、Canonical、Digital Ocean、Eliatra、Graylog、NetApp® Instaclustr、Portal26 の支援を受けてスタートします。 Amazon OpenSearch Service: 今後の展開 この発表は Amazon OpenSearch Service に何の変更ももたらしません。Amazon は引き続き、増加するコミッターとメンテナーとともに、OpenSearch プロジェクトのイノベーションと貢献にコミットしています。むしろ、より広範で深い参加によってグローバルコミュニティからより多様なアイデアがもたらされることで、このイノベーションは加速するでしょう。このコミットメントの核心には、「ユーザーが安全で高品質な、完全にオープンソースの検索および分析スイートを、新しい革新的な機能の豊富なロードマップとともに継続して利用できることを確実にする」という創設時からの継続的な願いがあります。私たちは、プロジェクトと密接に協力し続け、コードの改善に貢献し、それらの改善をマネージドサービスにもたらします。 この発表は、Amazon OpenSearch Service への接続や使用方法を変更するものでもありません。OpenSearch Service は引き続きフルマネージドサービスとして、サービスが提供するエンドポイントを通じて OpenSearch と OpenSearch Dashboards を提供します。また、既存のマネージドサービスが提供する各種機能も引き続きご利用いただけます。Amazon OpenSearch Service を使用している場合は、何も変更する必要がないということです。財団への移行によるライセンスの変更やコストの変更も生じません。 Amazon は引き続きプロジェクトに専門知識を提供し、クラウドネイティブな大規模分散システム、検索、分析、機械学習、AI など、顧客が最も必要とする新しいイノベーションに資金を提供します。Linux Foundation はまた、クラウドネイティブなオープンソースプロジェクトにとって重要な Cloud Native Computing Foundation (CNCF) などの他のオープンソース組織との協力を促進します。私たちの目標は、お客様の最もチャレンジングな課題をオープンソースファーストで解決し続けることです。最後に、オープンソースという製品の性質をふまえると、顧客と協力して問題をコードで一緒に解決する大きな機会があると考えています。私たちはその機会を楽しみにしています。 私たちは、常にお客様に OpenSearch プロジェクトへの参加をお奨めしてきました。現在、このプロジェクトには、Amazon 内外のさまざまな背景を持つメンバーが配置された運営委員会と技術運営委員会による、明確に定義された構造と管理が行われています。運営委員会はプロジェクトの資金調達と管理を担当し、技術運営委員会はプロジェクトの技術的な方向性を担当します。これにより、当社のマネージド サービスで使用しているテクノロジーの形成に直接参加できるようになる可能性が広がります。このプロジェクトは、問題の報告や機能リクエストから、RFC へのコメントやコードの貢献まで、大小を問わず、 Amazon OpenSearch Service をお使いの皆様の貢献を歓迎します。 まとめ プロジェクト、コミュニティ、そして Amazon OpenSearch Service にとって、今は素晴らしい時期です。AWS の顧客は、使用時に変更を加える必要はなく、Apache ライセンス 2.0 や価格にも変更はありません。しかし、Linux Foundation への移行は、オープンソースの世界からテクノロジーへ、そしてそこから Amazon OpenSearch Service への協力の精神をもたらすのに役立ちます。検索が成熟し続けるにつれて、私たちは共に質問をより良く理解し、関連性の高い結果を提供し続けることができるようになります。 OpenSearch Foundation の発表に関する詳細は、 AWS オープンソースブログ でご覧いただけます。 著者について Jon Handler は、カリフォルニア州パロアルトに拠点を置くアマゾン ウェブ サービスの検索サービスのソリューション アーキテクチャのディレクターです。 Jon は OpenSearch および Amazon OpenSearch Service と緊密に連携し、OpenSearch の検索およびログ分析ワークロードを抱える幅広い顧客にヘルプとガイダンスを提供します。 AWS に入社する前、Jon のソフトウェア開発者としてのキャリアには、大規模な e コマース検索エンジンのコーディングに 4 年間従事していました。 Jon は、ペンシルバニア大学で文学士号を取得し、ノースウェスタン大学でコンピュータ サイエンスと人工知能の理学修士号と博士号を取得しています。

本投稿は、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 回 : 移行戦略と移行パスとは ? 著者プロフィール アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 髙木 昇 アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 服部 昌克