自動車業界では大変革が起きています。ソフトウェアのイノベーションに牽引され、自動車の概念は単なる移動手段としての役割を超えています。車両は、高度運転支援システム (ADAS)、高度なインフォテインメント、コネクティビティ機能を備えた知的なマシンに進化しています。 こうした高度な機能を実現するには、自動車メーカーは様々なソースからのデータを管理する必要があり、大規模にデータを収集するソリューションが求められています。このニーズに AWS IoT サービスが役立ちます。 クラウド上にデータがあれば、データ分析ツールの構築、予防保全の実現、またエンドユーザー向けの生成 AI サービスにデータを活用するなど、新しい可能性が広がります。 ソリューション概要 この記事では、図 1 に示されている様々なユースケースに対応するために、複数の車両からデータを収集する、スケーラブルで企業向けの環境を整えた構造を、Raspberry Pi で動作させた車のモデルを使って構築する方法を案内します。 図 1 – ユースケース 全体のアーキテクチャ 図 2 は、アーキテクチャの概要を示しています。 図 2 – 全体のアーキテクチャ ハードウェアとローカルコントローラ ハードウェアとしては、機械部品と電子部品をすべて提供する このシンプルなキット を使用します。また、Raspberry Pi も必要です。キットの組み立てとテストの手順は、メーカーの ウェブサイト に記載されていますので、このブログ記事では説明しません。 図 3 – Raspberry Pi 用スマートカーキット 車両は WebSocket を使った React で書かれた Web インターフェースで制御されます。 ローカル Web アプリでは、カメラの映像を見たり、速度を調整したり、移動方向を制御したり、ライトを制御することができます。 よりリアルな運転体験のために、ゲームコントローラを使うこともできます。 図 4 – ローカルカーコントローラー 物理的なプロトタイプを使うことで、上で説明したサービスの機能が実用的な方法でユースケースに適用できることを効果的にシミュレーションできます。 データの収集と可視化 車両が生成したデータは、 AWS IoT FleetWise を使用して仮想 CAN インターフェースを介してクラウドに送信されます。各データ指標は AWS IoT のルール で処理され、 Amazon Timestream に保存されます。 すべてのデータは Amazon Managed Grafana を使用したダッシュボードに表示されます。 図 5 – データ収集 ウォークスルー 詳細な手順と完全なコードはこの GitHub の リポジトリ で入手できます。 フルリポジトリをダウンロードし、Readme.md ファイルに記載されているステップバイステップのアプローチに従うことをお勧めします。 この記事では全体のアーキテクチャを説明し、主要なステップのコマンドを提供します。 前提条件 AWS アカウント インストール済みの AWS CLI Raspberry Pi 用の スマートカー キット Raspberry PI Python と JavaScript の基本的な知識 ハードウェアとローカルコントローラ Raspberry Pi に車両制御ソフトウェアと AWS IoT FleetWise 向けの Edge Agent をインストールするには、以下の手順を実行します。詳しい手順は、 リポジトリ の Readme.md ファイルの 6 番目の項目に記載されています。 仮想 CAN インターフェースを設定する AWS IoT FleetWise 用の Edge Agent をビルドしてインストールする 車両の運転と制御用のサーバーとアプリケーションをインストールする 図 6 – ステップ 1 後のアーキテクチャ 基本的なクラウドインフラストラクチャの構築 AWS CloudFormation は、Amazon Timestream と Amazon Managed Grafana に必要なすべてのリソースを展開するために使用されます。 テンプレートは、Cloud フォルダ内の付随する リポジトリ にあります。 図 7 – ステップ 2 後のアーキテクチャ Amazon Managed Grafana のデプロイ (AWS CLI) 最初にデプロイするコンポーネントは Amazon Managed Grafana で、AWS IoT FleetWise で収集されたデータを表示するダッシュボードをホストします。リポジトリの “Cloud/Infra” フォルダ内にある CloudFormation の 01-Grafana-Instance.yml テンプレートを使って、次のコマンドでリソースをデプロイします。 aws cloudformation create-stack \ --stack-name macchinetta-grafana-instance \ --template-body file://01-Grafana-Instance.yml \ --capabilities CAPABILITY_NAMED_IAM CloudFormation が CREATE_COMPLETE 状態に到達したら、新しい Grafana ワークスペースが表示されるはずです。 図 8 – Amazon Managed Grafana ワークスペース Amazon Timestream のデプロイ (AWS CLI) Amazon Timestream は、1 日に数兆ものタイムシリーズデータポイントを格納し分析できるフルマネージド型のタイムシリーズデータベースです。 このサービスは、AWS IoT FleetWise によって収集されたデータを格納する、デプロイする 2 番目のコンポーネントになります。リポジトリの「Cloud/Infra」フォルダーにある 02-Timestream-DB.yml テンプレートを使用して、次のコマンドでリソースをデプロイします。 aws cloudformation create-stack \ --stack-name macchinetta-timestream-database \ --template-body file://02-Timestream-DB.yml --capabilities CAPABILITY_NAMED_IAM CloudFormation が CREATE_COMPLETE 状態に達すると、AWS IoT FleetWise で使用される新しい Timestream テーブル、データベース、および関連するロールが表示されます。 AWS IoT Fleet の設定 AWS IoT FleetWise の基盤を設定し、収集するシグナルを定義し、データを受信するよう構成する時間が来ました。シグナルとは、車両データとそのメタデータを含む基本構造体を定義したものです。 例えば、車のバッテリー電圧を表す信号を作成することができます。 Signal definition - Type: Sensor - Data type: float32 - Name: Voltage - Min: 0 - Max: 8 - Unit: Volt - Full qualified name: Vehicle.Battery.Voltage この信号は、車両に関するセマンティックに定義された情報を通信するために、自動車アプリケーションで標準的に使用されています。 VSS 仕様に従ってプロトタイプ車をモデル化してください。これがプロトタイプで使用する構造です。この構造は、リポジトリの Cloud/Fleetwise フォルダにある signals.json ファイルに JSON でコード化されています。 図 9 – VSS 形式の車両モデル ステップ 1: シグナルカタログを作成する (AWS CLI) 次のコマンドを使って、上記のように signals.json に記述された構造を利用してください。 aws iotfleetwise create-signal-catalog --cli-input-json file://signals.json コマンドにより返された ARN をコピーします。 AWS コンソールで AWS IoT FleetWise のページを開き、ナビゲーションパネルから シグナルカタログ を選択すると、新しく作成したシグナルカタログが表示されるはずです。 図 10 – シグナルカタログ ステップ 2: 車両モデルを作成する 車両のフォーマットを標準化し、同じタイプの複数の車両で一貫した情報を実施する 車両モデル です。 json ファイルを開き、 変数を前のコマンドでコピーした <ARN> に置き換えてください。 次のコマンドを実行してください: aws iotfleetwise create-model-manifest --cli-input-json file://model.json コマンドが返した ARN をコピーしてください。 次のコマンドを実行してください: aws iotfleetwise update-model-manifest --name <モデル名> --status ACTIVE AWS コンソールの AWS IoT FleetWise ページを開き、ナビゲーションパネルから 車両モデル セクションを選択すると、新しく作成した車両モデルが表示されます。 図 11 – 車両モデル: シグナル ステップ 3: デコーダー マニフェストを作成する デコーダーマニフェスト は、車両からのバイナリデータを人間が読める形式にデコードすることを可能にします。私たちのプロトタイプでは CAN バスプロトコル を使用しています。これらの信号は、生の CAN バスデータをデコードするための情報を含むテキストファイルである CAN DBC (CAN Database) ファイルからデコードされる必要があります。 decoder.json ファイルを開き、 変数を前のコマンドでコピーした ARN に置き換えます。 次のコマンドを実行してモデルを作成します: aws iotfleetwise create-model-manifest --cli-input-json file://model.json 次のコマンドを実行してデコーダを有効にします: aws iotfleetwise update-decoder-manifest --name <デコーダ名> --status ACTIVE AWS コンソールの AWS IoT FleetWise ページを開き、ナビゲーションパネルから 車両モデル セクションを選択すれば、新しく作成したデコーダーマニフェストが表示されるはずです。 図 12 – 車両モデル: デコーダーマニフェスト ステップ 4: 車両を作成する AWS IoT FleetWise には独自の車両コンストラクトがありますが、その基盤となるリソースは AWS IoT Core のモノ で、デバイス (車両) の静的なメタデータを含む物理デバイスの表現です。 AWS コンソールを AWS IoT FleetWise ページ で開きます ナビゲーションパネルで 車両 を選択します 車両を作成 を選択します リストボックスから車両モデルと関連するマニフェストを選択します 図 13 – 車両のプロパティ ステップ 5: キャンペーンを作成してデプロイする キャンペーンとは、AWS IoT FleetWise Edge Agent ソフトウェアに対して、どのデータを選択して収集するか、およびクラウドのどこにデータを送信するかを指示するものです。 AWS コンソールで AWS IoT FleetWise のページを開きます ナビゲーションパネルから キャンペーン  を選択します キャンペーンを作成  を選択します スキーマタイプでは時間ベースを選択します キャンペーン期間 では一貫した期間を選択します 期間  には 10000 と入力します シグナル名 では Actual Vehicle Speed を選択します 最大サンプル数  count では 1 を選択します ステップ 7 と 8 を他のすべての信号に対して繰り返します 送信先 では Amazon Timestream を選択します Timestream データベース名  では macchinettaDB を選択します Timestream テーブル名  では macchinettaTable を選択します 次へ を選択します 車両名  では macchinetta を選択します 次へ  を選択します 確認して 作成 を選択します 図 14 – キャンペーンを作成してデプロイする デプロイ後、数秒で Amazon Timestream テーブル内のデータが表示されるはずです。 図 15 – Amazon Timestream テーブル Amazon Timestream にデータを保存すると、Amazon Managed Grafana を使ってデータを可視化できます。Amazon Managed Grafana は、メトリクスのクエリ、可視化、アラートを行える、人気のオープンソース分析プラットフォーム Grafana の完全マネージドサービスです。 ダッシュボードで、単一の車両からの関連する詳細なデータを表示するために使用します: 図 16 – Amazon Managed Grafana クリーンアップ 詳しい手順は、 Readme.md ファイルの最後に記載されているリポジトリを参照してください。 結論 このソリューションは、ビークル車両データの収集と管理のためのスケーラブルなアーキテクチャ構築において、AWS IoT の力を実証しています。Raspberry Pi 電源の車両プロトタイプから始まり、自動車業界の主要なユースケースにどのように対処できるかを示しました。しかし、これはほんの始まりにすぎません。プロトタイプはモジュール化されており、新しい機能を追加できるよう設計されています。ソリューションを拡張する魅力的な方法をいくつか紹介しましょう。 Fleet Management Web App : AWS Amplify を使用して、車両の全体フリートを監視する包括的な Web アプリケーションを開発します。 このアプリでは、各車両の健全性状態を大まかに把握し、個別の車両の詳細な分析を行えます。 ライブビデオストリーミング: Raspberry Pi アプリケーションに Amazon Kinesis Video Streams ライブラリを統合して、実時間で車両からビデオフィードを可能にします。 予知保全: AWS IoT FleetWise によって収集されたデータを活用し、予知保全モデルを構築することで、車両の信頼性を高め、ダウンタイムを削減することができます。 生成 AI の統合: Amazon Bedrock のような生成 AI サービスを使用して、収集したデータに基づいてパーソナライズされたコンテンツを生成したり、ユーザーの行動を予測したり、車両の性能を最適化することを検討します。 コネクテッド車両ソリューションを次のレベルに引き上げる準備はできましたか? 私たちは、次のことをお勧めします: さらに詳しく見る: AWS IoT サービスとその自動車業界での応用について深く掘り下げましょう。詳細は、 AWS IoT のドキュメント をご覧ください。 実際に試す: GitHub の リポジトリ にある詳細な手順を参考に、自身でこのプロトタイプを構築してみましょう。 専門家と接する: 質問があれば、弊社の AWS IoT の専門家にご相談ください。 コミュニティに参加: AWS IoT コミュニティフォーラムで、経験を共有し、他者から学びましょう。 著者について Leonardo Fenu はソリューションアーキテクトで、2018年から AWS の顧客が技術をビジネス目標に合わせるのを支援してきました。山でハイキングをしたり家族と過ごしたりしていない時は、ハードウェアやソフトウェアをいじくり回したり、最新のクラウド技術を探求したり、複雑な問題を解決する創造的な方法を見つけたりすることを楽しんでいます。 Edoardo Randazzo は DevOps とクラウドガバナンスを専門とするソリューションアーキテクトです。自由時間には、IoT デバイスを作ったりガジェットをいじったりすることが好きで、それが次の大きなブレークスルーにつながる可能性があるか、単に新しいレゴを買う口実になるかもしれません。 Luca Pallini は AWS のシニアパートナーソリューションアーキテクトで、パートナーが公共部門で優れた成果を上げるのを支援しています。AWS の技術フィールドコミュニティ(TFC)のメンバーとして、特に Oracle Database を中心としたデータベースを専門としています。AWS に入社する前は、データベース設計、アーキテクチャ、クラウド技術で22年以上の経験を積みました。余暇には家族と過ごしたり、ハイキングをしたり、読書をしたり、音楽を聴いたりすることを楽しんでいます。 この記事は Building a connected car physical prototype with AWS IoT services の日本語訳です。 この記事は シニアソリューションアーキテクト渡邊翼が翻訳しました。

Introduction 水道メーターは、住宅や大規模生産施設など、ほとんどの給水場所に設置されています。水不足が世界中で頻発するようになり、水の無駄使いを避けることがますます重要になっています。老朽化したインフラストラクチャのため、パイプを流れる水の 30 % が漏れによって無駄になってしまいます ( AWS announces 6 new projects to help address water scarcity challenges )。IoT 化された水道メーターによる計測ソリューションがこの課題解決に役立つ可能性があります。 従来の水道メーターやガスメーターはクラウドやインターネットに接続されていません。また、1979 年と 2003 年にそれぞれ発表された業界標準のプロトコルである Modbus や Profinet を利用しているケースが多いです。これらのプロトコルはクラウド接続を想定して設計されたものではありませんが、AWS と AWS パートナー が提供するソリューションにより、公益事業のデータをクラウドに転送することができます。 スマートメーターは従来のメーターに比べ、消費パターンのデータを活用することで水漏れや非効率な利用パターンの分析が可能となり、コストや資源の節約につながるなど多くの利点があります。 詳細な消費レポートを持つことで、企業は 環境に対する持続可能性目標 と企業の社会的責任への取り組みを支援できるようになります。 クラウドベースのサービスとスマートメーターを組み合わせることにより、予知保全の機能を活用し、障害が発生する前に新たな問題を自動的に分析して特定できます。 このような自動化により、分析プロセスを合理化し、手動での介入の必要性を低減可能です。 この投稿では、機械学習 (ML) の事前学習済みモデルを使用して漏れなどのデータの異常を検出する、広く適用可能なソリューションを紹介します。 このソリューションを実現するため、実際の水道メーターの例を使用し、既存の水道・ガスメーターを AWS IoT Greengrass と AWS IoT Core に統合する手順を説明します。 Solution Overview 実際のソリューションに入る前に、システムのアーキテクチャとそのコンポーネントを確認しましょう。 図 1: ソリューションアーキテクチャの概要 図 1 は、AWS のソリューションアーキテクチャを示しています。この例では、標準的な電磁水道メーターを使用しています。 このメーターは、アナログ信号を送信するか、 IO-Link マスターと通信するように設定できます。 簡単にするため、ここではアナログ出力を使用しています。 流量計からの測定値は、シングルボードコンピューター (この場合は手頃で軽量な Raspberry Pi Zero W ) によって処理されます。 お好みであれば、AWS IoT Greengrassを実行できる別のデバイスをRaspberry Piの代わりに使うこともできます。 同様に、メーターとの通信に別のプロトコルを使用することもできます。 1 つのオプションとして、AWS が提供する IoT Greengrass コンポーネントによる処理が可能な Modbus が考えられます。 こちらの IoT Greengrass コンポーネントの詳細は、 Modbus-RTU プロトコルアダプター を参照してください。 センサーから取得したデータはエッジデバイス上で処理され、その後 MQTT メッセージを使用して AWS IoT Core に送信されます。AWS IoT ルールエンジンは受信したメッセージを AWS Lambda 関数にルーティングします。この Lambda 関数はメッセージペイロードを解析し、個々の測定値を Amazon Timestream に保存します。(Amazon Timestream は時系列データベースで、Amazon Managed Grafana や Amazon SageMaker と密接に統合されているため、今回のユースケースに最適です。) 次に Lambda 関数は、受信したデータポイントの異常スコアを計算するために、複数の SageMaker エンドポイントを呼び出します。 図 2: AWS IoT Core へのデータフロー 図 2 は、水道メーターから AWS IoT Core にデータが流れる様子を示しています。 このプロジェクトでは、2 つの測定値 (温度と流量) を受け取るため、2 本の電線が使用されています。 特筆すべきは、送信される信号は、既知の下限値と上限値を持つ電圧に過ぎないことです。 Raspberry Pi Zero にはデジタル GPIO ヘッダしかなく、これらの信号を使えるようにするにはアナログデジタル変換器 (ADC) を使う必要があります。 Raspberry Pi 上のセンサーデータコンポーネントは、ADC の出力を使って与えられた電圧と既知の範囲に基づく線形補間によって、実際の値を計算します。(センサーデータコンポーネントはこのアーキテクチャ専用に書かれており、マネージド AWS IoT Greengrass コンポーネントではないことにご注意ください)。 最後に、計算された値と、デバイス名などのメタデータが AWS IoT Core に送信されます。 このアーキテクチャは、センサーデータコンポーネントを適応させるだけで、さまざまな種類の計測器に対応できる柔軟性があります。多数の計測器からデータを収集する使用事例の場合、それらに対応するためにいくつかの変更が必要になる可能性があります。関連するアーキテクチャの選択について詳しくは、 AWS IoT Core および/または Amazon Kinesis を使用してデバイスからデータを取り込むベストプラクティス (Best practices for ingesting data from devices using AWS IoT Core and/or Amazon Kinesis) をご覧ください。 次のセクションでは、このソリューションで使用する 3 つの主要コンポーネントについて説明します。 Data Ingestion and Processing メーターデータを取得するために、エッジデバイスは適切な間隔でセンサーにポーリングします。デバイス上でデータが処理された後、メッセージのペイロード (リスト 1) が AWS IoT Core に送信されます。具体的には、AWS IoT Greengrass コンポーネントは、組み込みの MQTT メッセージング IPC サービス を利用して、センサーデータをブローカーに通信します。 { "response": { "flow": "1.781", "temperature": "24.1", }, "status": "success", "device_id": "water_meter_42", } リスト 1: MQTT メッセージペイロードのサンプル メッセージがブローカーに到着すると、AWS IoT ルール がトリガーされ、受信データを Lambda 関数に中継します。 この Lambda 関数はデータを Timestream に保管し、異常スコアを取得します。 データを時系列データベースに保存することで、過去の測定値の履歴がデータとして蓄積されます。 これにより、過去のデータ分析、機械学習モデルのトレーニング、過去の測定値の可視化など、様々なデータ活用が可能となります。 Data Visualization 履歴データを可視化することで、データの探索やデータの整合性を手動で確認することができます。今回のソリューションでは、Amazon Managed Grafana を使用し、インタラクティブな可視化環境を提供します。 Amazon Managed Grafana は、提供されているデータソースプラグインにより Timestream と統合されています。(詳細は Amazon Timestream データソースに接続する を参照してください。) このプラグインを使うと、収集されたすべてのメトリクスを表示するダッシュボードをセットアップできます。 図 3 は Amazon Managed Grafana ダッシュボードのキャプチャです。 グラフは時間経過に伴う水の流量 (リットル/分) と温度 (摂氏) の測定値を表示しています。 図 3: Amazon Managed Grafana のモニタリングダッシュボード 図 3 の上のグラフは、約 11 時間の期間の流量計の測定値を示しています。水の流れのパターンを確認することで、水ポンプが何度もオン/オフを繰り返しているという特徴がわかります。 下のグラフは、同じく約 11 時間の時間枠において水温が約 20℃ から 40℃ の間で変化していることが読み取れます。 Advanced Use Cases 各センサーの過去の履歴データを活用することで、SageMaker を使用した機械学習モデルをトレーニングすることが可能となります。 今回のメーターデータの例では、オペレーターは異常や故障に迅速に気づき、重大な損害が発生する前に原因を調査できるようになることを目指し、リアルタイムで異常検知を行うモデルの構築を行います。 図 4: 水流量監視における 2 つの異常の例 図 4 には、水の流れの異常がどのようなものかを示す 2 つの例が含まれています。 このグラフは約 35 分間の水の流れの測定値を示しており、2 つの不規則性が見られます。 両方の異常は約 2 分間続き、赤い長方形で強調表示されています。 これらは、水道管の一時的な漏れが原因で発生したもので、特徴的な流れのパターンの変化から特定することができます。 SageMaker には、自動異常検出に使える 組み込みアルゴリズムと事前学習済みモデル がいくつか用意されています。 これらを活用することで、コーディングがほとんどなくすぐに実験を開始いただけます。 加えて、組み込みのアルゴリズムは、必要に応じて複数のインスタンス間での並列処理の最適化がされています。 Amazon の Random Cut Forest (RCF) アルゴリズム は、この アーキテクチャでテストされている組み込みアルゴリズムの 1 つです。 RCF は、各データポイントに対して異常スコアを関連付ける教師なし学習アルゴリズムです。 教師なしアルゴリズムは、ラベルなしデータを使って学習します。 詳細については、 ”教師あり学習と教師なし学習はどのように異なりますか?” のページを参照してください。 計算された異常スコアは、任意の次元数の入力において、規則的または規則的なパターンからはずれた異常な挙動を検出するのに役立ちます。 さらに、このアルゴリズムのプロセスは、特徴量の数、インスタンスの数、データセットサイズに応じてスケールします。 経験上、平均から標準偏差の 3 倍を超える高いスコアが異常と判断されます。 このアルゴリズムは教師なし学習なので、学習プロセスでラベルを提供する必要はなく、正確な異常ラベル付けができないセンサーデータにも特に適しています。 モデルがデータセットで学習された後、そのモデルを使用して全てのメーターのデータポイントに対して異常スコアを計算できます。この異常スコアは、後で参照するために別の Timestream データベースに保存されます。異常判定のための閾値も設定する必要があります。 Amazon Managed Grafana を使用すれば、分類された異常スコアを可視化できます (図 5 参照)。 図 5: Amazon Managed Grafana にて可視化した RCF による異常分類結果 図 5 は、時系列データと状態を示すウィジェットが表示されている Managed Grafana ダッシュボードの一部です。時系列データは水の流量を表しており、異常な流量となっている 1 分の区間が含まれています。状態を示しているウィジェットには、RCF アルゴリズムによる異常分類の結果が表示されます。緑は正常な状態を、赤は異常な状態を表しています。 アルゴリズムが異常を検出した場合、様々な自動化されたアクションを実行できます。 たとえば、 Amazon Simple Notification Service (Amazon SNS) を使用して、SMS やメールでユーザーへの通知が可能です。 スコア算出がリアルタイムに近い形で行われるため、大きな損害が発生する前に潜在的な問題を素早く検出することができます。 Conclusion このブログ記事では、既存の計測データを AWS に統合することで得られる付加価値と、その実装例について説明しました。 このソリューションは、アナログセンサからデータを収集し、AWS IoT Greengrass デバイスを使って AWS IoT Core に取り込み、Amazon Timestream にて計測値を処理・保存し、SageMaker で異常検知を行います。 この例ではメーターとしての水道メーターを取り上げていますが、利用したコンポーネントは任意のタイプのメーターデバイスで動作するように変更できます。 同様のシステムを実装したい場合は、上記の AWS サービスを活用することでメーター監視ソリューションを構築してみてください。 運用レディな本番アプリケーションを開発したい場合は、Raspberry Pi Zero を本番ワークロードに適したデバイスに置き換える必要があります。 デバイスについては、 AWS パートナーデバイスカタログ を参照してください。 水漏れの検出に関するさらなる議論については、 AWS IoT を使用してリアルタイムに近い水漏れを検出する (Detect water leaks in near real time using AWS IoT) をご覧ください。 農業での異常検出の活用にご興味があれば、 AWS IoT を使用したサーバーレス異常検知による農業業務の合理化 (Streamlining agriculture operations with serverless anomaly detection using AWS IoT) をご覧ください。 この記事は Tim Voigt と Christoph Schmitter によって書かれた Connected utility solutions for water and gas metering with AWS IoT の日本語訳です。この記事は Solutions Architect の西亀真之が翻訳しました。 著者について Tim Voigt Tim Voigt は、AWS の PACE チーム (プロトタイピングとクラウド エンジニアリングの略) のソリューション アーキテクトです。ドイツに拠点を置き、AWS で働きながらコンピューターサイエンスの大学院研究を続けています。Tim は、現実世界の問題を解決するための新しいソリューションを開発し、その根底にある技術的概念を深く掘り下げることに情熱を注いでいます。 Christoph Schmitter Christoph Schmitter は、デジタルネイティブのお客様を担当するドイツのソリューションアーキテクトです。Christoph はサステナビリティを専門とし、企業が持続可能な製品やソリューション構築のための変革をサポートしています。 AWS に入社する前は、ソフトウェア開発、アーキテクチャ、クラウド戦略の実装において幅広い経験を積んでいました。スケーラブルで復元力のあるシステムの構築から、子供たちのロボットのクラウドへの接続まで、あらゆるテクノロジーに情熱を注いでいます。仕事以外では、読書、家族との時間を過ごし、テクノロジーをいじることを楽しんでいます。

本稿は、2024 年 9 月 17 日に IBM &amp; Red Hat on AWS Blog で公開された “ Unlocking Transformative Benefits of Modernizing VMware workloads to Red Hat OpenShift on AWS ” を翻訳したものです。 今日の急速に進化する技術の環境において、企業は VMware のワークロードと仮想マシン (VM) をクラウドに移行・モダナイゼーションする方法を求めています。注目を集めているアプローチの 1 つは、従来の VM を Red Hat OpenShift on Amazon Web Services (AWS) などのコンテナ化された環境に移行するか、 OpenShift Virtualization on AWS に直接移行することです。 VMware ワークロードを移行してモダナイゼーションする方法を多くのお客様が探しています。お客様にとってスピードは最も重要な要素の 1 つですが、実際の VM をクラウドに移行するスピードはあくまで考慮すべき 1 つの要素に過ぎません。可観測性や VM へのトラフィック公開方法など、VM を本番環境で使用できるようにする前に実装しなければならない追加の要件があります。 本稿では、VMware の VM とワークロードを Red Hat OpenShift Service on AWS (ROSA) に移行する際の「何を」「なぜ」「どのように」について説明し、移行プロセスの理解と、さらに深く掘り下げるための追加リソースを提供します。 Red Hat OpenShift Service on AWS とは Red Hat OpenShift Service on AWS (ROSA) は、クラウドネイティブのアプリケーションプラットフォームで、組織が AWS 上でコンテナ化されたアプリケーションのビルド、デプロイ、管理をシームレスに行えるようにします。Kubernetes の上に構築されたサービスのスタックを提供し、アプリケーションのデプロイ、スケーリング、管理を自動化するための一連の機能を提供します。 ROSA は、OpenShift の機能と AWS のスケーラビリティと柔軟性を組み合わせた、Red Hat Site Reliability Engineer (SRE) によるフルマネージドなサービスです。この統合により、組織はクラウドネイティブプラットフォームのメリットを活用しながら、サーバーレスコンピューティング、マネージドデータベース、高度な分析などの AWS が提供する幅広いサービスの利点も享受できます。 VMware VM を OpenShift Virtualization on ROSA に移行する理由 OpenShift Virtualization on ROSA を使用すると、VM を クラウドに移行するスピードを満たし、運用要件を簡素化することで VM を本番環境に移行するまでの時間を短縮できます。Red Hat Migration Toolkit for Virtualization (MTV) を使えば、既存の VMware クラスターを ROSA に接続し、移行したい VM を選択して ROSA にインポートできます。お客様は VM 自体を変更する必要なく、ROSA の Infrastructure as Code (IaC) 用の組み込みツール、メトリクス、ダッシュボード、ロードバランシング、アラートを活用できます。 このアプローチにより、お客様は AWS への移行を加速し、VMware vSphere または VMware Cloud Foundation (VCF) から AWS へのリプラットフォームにかかる総時間を短縮できます。 VMware ワークロードを Red Hat OpenShift Service on AWS (ROSA) に移行すると、さまざまな利点があります。特にアプリケーションのモダナイゼーション、クラウドネイティブ機能の活用、運用の簡素化を目指す組織にとって有益です。ROSA に VMware ワークロードを移行する主な理由を以下に示します。 OpenShift Virtualization on ROSA の利点 クラウドネイティブアプローチ : 組織はリソース使用率の改善、より高速なデプロイメントサイクル、アプリケーション管理の合理化など、クラウドネイティブアーキテクチャの利点を活用できます。 アジリティとスケーラビリティの向上 : 従来の仮想マシンはリソースを大量に消費し、アプリケーションのスケーリングや更新に関して俊敏性が低下する可能性があります。ROSA は自動スケーリング機能を提供し、アプリケーションがワークロードの変化に動的に対応できるようになるため、最適なパフォーマンスと効率的なリソース活用が可能になります。 ライセンスコストの削減 : 組み込みの無制限の RHEL エンタイトルメントにより実現します。OpenShift Virtualization には、すべての RHEL ゲスト VM に対する無制限の RHEL サブスクリプションが含まれています。 セキュリティとコンプライアンスの強化 : ROSA は業界をリードするセキュリティ標準に準拠し、さまざまな規制要件に準拠しています。組み込みのセキュリティ制御、自動化された脆弱性管理、セキュアなマルチテナンシーなどの機能を備えており、アプリケーションとデータを保護します。 運用オーバーヘッドの削減 : ROSA を活用することで、組織はインフラストラクチャのプロビジョニング、スケーリング、メンテナンスなどの多くの運用タスクをマネージドサービスにオフロードできます。この運用オーバーヘッドの削減により、チームは複雑なインフラストラクチャの管理ではなく、ビジネス価値の提供に集中できます。 従量課金制 (Pay-As-You-Go) : 使用したリソースに対してのみ支払うことができます。ROSA に移行することで、従来のデータセンターモデルにありがちな多額の先行投資の必要性が軽減されます。 VM ワークロードの高可用性 : OpenShift および AWS アベイラビリティーゾーンの組み込み機能により実現します。アベイラビリティーゾーン間の VM への接続を簡素化するために、Elastic Load Balancing (ELB) を活用できます。 ディザスターリカバリー機能 : AWS のグローバルインフラストラクチャとサービスを活用して、地理的に分散した AWS リージョン間で環境やアプリケーションをレプリケートすることができます。 ROSA を活用したモダナイゼーション：変革をもたらすメリットを解き放つ 従来、VM ベースのアプリケーションをクラウドに移行し、コンテナ化したいお客様は、進め方の選択肢が限られていました。たとえば、VMware のワークロードを Amazon Elastic Compute Cloud (Amazon EC2) 上で実行するように変換するなど、同様のコンピューティングプラットフォームへのリフト＆シフトによる移行を行うことができます。この段階でお客様はクラウドに移行し、 AWS クラウドの利点 を得られますが、アプリケーション自体はメリットを得られません。 コンテナを利用するには、お客様はモダナイゼーションの取り組みに着手し、VM ベースのアプリケーションをマイクロサービスに分解し、コンテナとしてデプロイし、最終的に新しくコンテナ化されたアプリケーションを選択したコンテナプラットフォームに移行する必要があります。 お客様に別の簡単な選択肢、つまり VM をクラウドとコンテナプラットフォームに直接移行できる選択肢があったらどうでしょうか。 ここで OpenShift Virtualization と ROSA が役立ちます。OpenShift Virtualization は、アップストリームプロジェクトの KubeVirt に基づいており、これによりお客様は Kubernetes 内でネイティブリソースとして VM を実行できます。コンテナに利用可能なすべての機能や特徴が VM に拡張されるようになりました。コンテナ化されたアプリケーションがサービスメッシュを使用している場合、VM をそこに追加できます。サービスオブジェクトを定義してコンテナを公開する方法と同様に、VM へのトラフィックを公開して負荷分散します。さらに、オンデマンドで VM リソース (CPU/MEM) の垂直スケーリングや VM のライブマイグレーション機能などの追加機能もあります。 ROSA は、同じプラットフォーム上で VM とコンテナの両方を管理できる機能を提供します。これにより、VM ベースのアプリケーションをマイクロサービスに分解し、移行の手順を減らすことができます。 変換できない VM の場合、またはライセンスなどの理由でVM として残す必要がある場合でも、ROSA からアプリケーション中心のメリットをすべて享受できます。コンテナと VM の両方に単一画面と共通のツールセットを使用することで、運用オーバーヘッドを削減できます。 ROSA 上の VM をモダナイゼーションする手順 移行プロセス全体を通して、アプリケーション開発者、オペレーション担当者、セキュリティ専門家など、さまざまな部門の関係者を関与させることが重要です。このような協業的なアプローチにより、移行が効率的に実行され、結果として得られる環境が組織の目標と要件に沿ったものになります。 さらに、クラウド移行とモダナイゼーションプロジェクトに特化した Red Hat と AWS パートナーの専門知識を活用することをお勧めします。これらのパートナーは、移行プロセスを円滑化し、成功を確実にするための貴重なガイダンス、ベストプラクティス、実践的な支援を提供できます。 VMware VM を ROSA に移行およびモダナイズする際の高レベルの手順を次に示します。 計画と評価 : 移行対象のアプリケーションまたはワークロードを特定し、優先順位付けをします。アプリケーションのアーキテクチャ、依存関係、リソース要件を評価します。移行に伴う潜在的な課題やリスクを評価します。 アプリケーションのコンテナ化 &nbsp;: アプリケーションをコンテナ化の原則とベストプラクティスに従うようにリファクタリングまたは再構築します。アプリケーションとその依存関係をコンテナイメージにパッケージ化します。コンテナ化されたアプリケーションが十分にテストおよび検証されていることを確認します。 インフラストラクチャのセットアップ : Amazon Virtual Private Cloud (Amazon VPC)、サブネット、セキュリティグループなど、AWS 上に必要なインフラストラクチャをプロビジョニングします。 AWS Marketplace の Red Hat OpenShift Service リストを通じてサブスクライブしデプロイすることで、ROSA クラスターをデプロイおよび構成します。アプリケーションで必要な追加の AWS サービス (データベース、キャッシュ、メッセージングシステムなど) をセットアップします。 アプリケーションのデプロイメント : コンテナイメージを OpenShift クラスターからアクセス可能なコンテナレジストリにプッシュすることで行います。必要な Kubernetes リソース (Deployment、Service、ConfigMap など) を定義して適用し、OpenShift にアプリケーションをデプロイします。必要に応じてネットワーキング、ストレージ、その他のリソースを構成します。VMware VM を ROSA Virtualization にシームレスに移行するには、 OpenShift Virtualization on AWS ブログ の情報に従ってください。 テストと検証 : デプロイされたアプリケーションを徹底的にテストし、新しい環境で期待どおりに機能することを確認します。さまざまな負荷条件下でのパフォーマンス、スケーラビリティ、および復元力を検証します。セキュリティとコンプライアンスのチェックを行い、組織のポリシーと規制要件を遵守していることを確認します。 モニタリングとメンテナンス &nbsp;: アプリケーションとインフラストラクチャのパフォーマンスを可視化するため、モニタリングとロギングソリューションを実装します。OpenShift 上のアプリケーションの継続的なメンテナンス、更新、スケーリングのためのプロセスを確立します。ローリングアップデート、ロールバック、自動スケーリングなどの OpenShift 組み込み機能を活用し、アプリケーションライフサイクル管理を合理化します。 まとめ 企業は、コンテナ化によってもたらされるメリットやその影響力、および ROSA のクラウドネイティブ機能を活用することで、デジタルトランスフォーメーションの取り組みを加速し、イノベーションを促進し、ますます競争が激しくなる市場で優位に立つことができます。慎重に計画し、ベストプラクティスを遵守し、経験豊富なパートナーと協力することで、移行における課題と複雑さを最小限に抑えることができます。 さらに詳しく知りたい場合は、AWS または Red Hat のアカウントチームにご連絡いただくか、AWS Red Hat パートナーチームに電子メールをお送りいただくか、近くで開催される OpenShift Virtualization ロードショー の日程をご確認ください。（訳註：日本ではエンドユーザー様を対象に 2024 年 11 月 15 日 14:00-16:00 に 開催 が予定されています。） 関連コンテンツ AWS Marketplace から Red Hat OpenShift on AWS をサブスクライブする OpenShift Virtualization on ROSA に関するブログ Red Hat OpenShift Virtualization について学ぶ <!-- '"` --> Elvis Pappachen Elvis Pappachen は、クラウドと IT 分野でお客様をサポートしてきた 20 年以上の経験があります。Amazon Web Services, Inc (AWS) のソリューション アーキテクトであり、AWS でのパフォーマンス、スケーラビリティ、コスト効率を最適化するための複雑なクラウド移行および変革プロジェクトを通じてお客様とパートナーを支援しています。自宅のオートメーション化をさらに進める方法を考えていない時間には、家族と過ごしたり、旅行したり、新しい料理を楽しんだりして自由時間を過ごしています。 Anupama Padmanabhan Anupama は IT 業界で 24 年以上の経験があります。彼女は、革新的なクラウド ジャーニーを通じてクライアントを導く最前線に立ってきました。彼女の専門知識は、移行、モダナイゼーション、クラウド ターゲット オペレーティング モデル、堅牢なビジネス ケース開発のためのクラウド戦略に重点を置き、大規模クライアントとの数多くのクラウド アドバイザリー業務に携わっています。 Trey Hoehne Trey Hoehne は、Amazon Web Services (AWS) の AWS Go To Market Container スペシャリストであり、お客様が AWS でコンテナを導入できるよう支援することに重点を置いています。 本稿の翻訳は Partner SA の豊田が担当しました。

本ブログは、株式会社エウレカと Amazon Web Services Japan が共同で執筆しました。 背景と概要 Pairs（ペアーズ）は、株式会社エウレカが運営する恋活・婚活のマッチングアプリです。大規模なユーザーベースを持つマッチングサービスであり、システムの安定稼働が非常に重要です。 多くのユーザーにとって、マッチングした後、ペアーズが実際に会うときの唯一の連絡手段となっています。そのため、障害が発生するとユーザー同士の連絡が取れなくなるので、迅速に対応を行い、再発防止のためのナレッジを貯める必要があります。過去には、障害発生時の対応に多大な時間とリソースを費やしてきました。特に、障害対応の指揮を取るコマンダーの責務が多すぎることで、新任のコマンダーが対応に苦労する場面が多々ありました。 そこで、Amazon Bedrock を活用して障害対応の一部を自動化・効率化し、コマンダーの負担を軽減することで、誰でも対応しやすい環境を整えるプロジェクトを開始しました。具体的には、社内チャットツールのメッセージを活用して中間報告書とポストモーテム文書を自動作成する機能を提供しています。 Amazon Bedrock を活用した障害対応の自動化 技術選定 Amazon Bedrock 選定の理由 他の LLM サービスではなく、Amazon Bedrock を選定した理由は以下の通りです。 Amazon Elastic Kubernetes Service (Amazon EKS)との統合が容易: ペアーズのアプリケーションをホスティングしている環境が Amazon EKS で構築されているため、IAM Roles for Service Accounts (IRSA) などを活用してきめ細かい権限設計が可能。 Managed RAG 機能が利用可能: Knowledge base for Amazon Bedrock などの Managed RAG 機能が利用可能であり、ペアーズの LLM チャットボットでの利用にも活用できる。 LLMOps のサポート: モデル評価やプロンプトマネジメントなど、LLMOps で必要な要素が網羅的に提供されている。 モデル選定 Amazon Bedrock のモデル選定に関して、今回の社内利用のユースケースではコストやレスポンス速度はあまり問題にはならないため、性能を重視して Claude 3 Haiku ではなく Claude 3.5 Sonnet を選びました。 Claude 3.5 Sonnet は、Anthropic 社が開発した大規模言語モデル(LLM)であり、自然言語処理タスクにおいて高い性能を発揮します。特に、日本語の処理能力が高く評価されています。ペアーズでは、障害対応の自動化において、高い言語処理能力が求められるため、Claude 3.5 Sonnet を採用しました。 報告書作成シーケンス ペアーズの報告書作成シーケンスは、以下のようになっています(ポストモーテム文書作成も同様)。 従業員が社内チャットツールにて報告書作成依頼コマンドを実行し、それを Incident Bot が受け付ける Incident Bot が LLM API を呼び出す LLM AP Iが Amazon Bedrock を利用して、報告テンプレートと社内チャットツールのメッセージ・障害情報から障害の要約を生成する 。 生成された要約を駆使して報告書が作成され、社内のドキュメント、チャットツールに投稿される このシーケンスでは、従業員が手動で報告書を作成する必要がなくなり、効率的な障害対応が可能になります。また、LLM を活用することで、報告書の品質も向上します。 （※実際の報告書ではありません） システムアーキテクチャ 従業員からの報告書作成依頼コマンドを受け付け、ハンドリングする Incident Bot Server が、Amazon API Gateway と AWS Lambda で構築されています。そこからリクエストを受け付ける LLM API が Amazon EKS 上に構築されており、Amazon Bedrock を用いた障害情報の要約処理が行われております。 このアーキテクチャにより、スケーラビリティの高いシステムを構築することができます。 LLMを利用したAPI処理の工夫点 データ前処理 社内チャットツールのメッセージデータから Bot の発言などを取り除き、必要なメッセージに絞る処理をしています。また、メッセージデータに含まれるタイムスタンプは、対応時系列の項目などで使用したい形式にあらかじめ変換しています。 このように、LLM に任せる必要のない単純なデータ処理は事前に済ませておくことで、LLM を本質的なタスクに集中させ、生成の精度を上げることにつながります。 また、Claude のモデルは命令プロンプトをXML形式で記述すると生成の精度が上がる傾向にあるため、メッセージデータを XML 形式に変換して Amazon Bedrock への命令プロンプトの一部として埋め込んでいます。 リトライ機構 使用しているドキュメントツールの制約により、Amazon Bedrock を用いて XHTML 形式のデータを生成する必要があります。そのため、プロンプトで XHTML 形式のデータ生成を指示します。その際、プロンプトの最後にアウトプットが有効な XHTML かどうかを LLM 自身に再度バリデーションさせるとより効果的です。さらに、有効な XHTML であることを後処理でもバリデーションし、もし有効な XHTML でない場合は生成処理をリトライするように実装しています。LLM の出力はどんなにプロンプトを工夫しても必ずしも命令を守ってくれるとは限らないので、このようなリトライ機構は非常に重要です。 リトライ機構の導入により、出力の品質が大幅に向上しました。初期の試行では、約30%の出力が XHTML の要件を満たしていませんでしたが、リトライ機構の導入後は99%以上の出力が要件を満たすようになりました。 LLM に全てを生成させない 状態が遷移しがちでハルシネーションや処理ミスが起こりやすいテンプレート項目(障害深刻度など)は、別で保存されているデータを取得しテンプレートに埋め込み、LLM に生成させないようにしています。また、静的なテンプレート部分(注意事項など)は、生成データに後処理で結合するようにしています。LLM が生成する必要がない/不得意な部分は、LLM に生成させないという考え方はどのタスクでも有効です。 この工夫により、LLM に適したタスクに特化させることができ、出力の品質が向上しました。また、処理の効率化にもつながりました。 導入効果 Amazon Bedrock を導入した結果、以下の成果を得ることができました。 対応時間/コストの短縮 障害対応報告書とポストモーテム文書の自動生成により、報告や振り返りにかかる工数が約60%削減され、対応時間/コストが大幅に短縮されました。 具体的には、従来は報告書作成に1人当たり平均3時間を要していましたが、自動化後は1時間程度に短縮されました。また、ポストモーテム文書作成に関しても、従来は1人当たり4時間を要していましたが、1.5時間程度に短縮されました。 このように、自動化による大幅な工数削減が実現でき、障害対応にかかるコストを大きく削減することができました。 障害対応の心理的負担軽減 従来は、コマンダーが報告書やポストモーテム文書の作成を含む多くの業務を担っていたため、特に重大な障害発生時には過度の負荷がかかっていました。しかし、自動化により、これらの業務の一部が軽減されたことで、コマンダーの負担が大きく軽減されました。 また、報告書やポストモーテム文書の品質も向上したことで、コマンダーが内容を確認し修正する手間も削減されました。 このように、自動化による業務の効率化と品質向上により、コマンダーの心理的負担が軽減され、障害対応体制の強化につながりました。

はじめに 全日本空輸株式会社 整備センター 機体事業室 機体計画部 航空機売却・リースチームでは航空機のリース返却業務を行っております。 本ブログでは、業務における膨大なドキュメントの転記作業を AWS 上の OCR 技術と AI による画像分析技術を活用し生産性向上を実現された事例について、同チームの九冨様に寄稿いただいたものです。 PDF 化した整備記録から整備タグ情報を読み取る手間 AWS 三宅： 整備タグの読み取り業務において AWS サービスを活用するに至った背景を教えてください。 ANA 九冨様： ANA では、自社で保有する航空機だけでなく、外部の会社からリースしている機体も運航しております。私達のチームでは、リース返却時、機体に装着されている部品の識別を特定するため、過去の全整備記録の中から取り付けられた部品情報の記載がある整備タグ*の内容を抽出しリスト化する業務を行っております。これまで人力で調査を実施しておりましたが、1 機あたり約 1.5 万 – 3 万件もの整備記録からデータを抽出する必要があり大変な負担となっておりました。この作業の負荷低減のためソリューションを模索していたところ、社内 IT チームと AWS 主催の AWS 勉強会にて AWS に OCR を実現する AI サービス「Amazon Textract」があることを知り、活用できないかと考えました。 *整備タグ：航空整備作業で部品交換発生時に使用する部品の品質保証書がシール化されたもの。取り付けられた部品のタグが対象の整備記録に貼り付け、または、添付され保管される。 整備タグ OCR システム AWS 三宅： Amazon Textract を中心にどのような整備タグ OCR システムを開発されたのでしょうか。 ANA 九冨様： 全体アーキテクチャは下記の通りです。PDF 化された整備記録を指定の Amazon S3 に格納することで、OCR 結果が CSV ファイルとして出力されるように構成しました。事前に社内 IT 部門によるセキュリティー審査を行い、AWS 上へのファイルのアップロードやダウンロードは、社内のセキュリティポリシーに則して最小権限を持つユーザのみが実施可能になっています。 Amazon Textract ANA 九冨様： 本システムは AWS のサーバレスサービスを使ったアーキテクチャで構成されています。 Amazon Textract によって、タグ内の表形式の内容を Key と Value の形式で文字データを抽出しています。 抽出した文字データは一時的に Amazon DynamoDB に格納し、全体処理の完了後、Amazon S3 に CSV 形式で結果を出力しています。 Amazon Rekognition ANA九冨様： 当初、整備記録の PDF をそのまま Amazon Textract に処理させようとしていましたが、下記のような課題が発生しました。 &nbsp;数十ページある PDF ファイルの中に、整備タグは数ページにしか存在せず、それ以外のページに対しては不必要な Amazon Textract の処理（ページ数毎の課金）が発生してしまう 1 枚に複数の整備タグが貼付されている場合、抽出した文字を分類することができない そこで、Amazon Textract による処理の前段に Amazon Rekognition のカスタムラベルを用いて、整備記録の中にある整備タグの部分のみの画像を切り抜き、その画像を Amazon Textract にて OCR 処理させるように工夫しました。 具体的な処理手順は下記になります。 数種類ある整備タグを横向き、タテ向きでそれぞれ 100 枚ずつ学習を行い、正解率 92% のカスタムラベルのモデルにて、整備タグの有無を判定 タグ有の判定の場合は、カスタムラベルの推論結果をもとに、AWS Lambda にて OpenCV（画像処理ライブラリ） を用いてタグ部分の切り抜きを実施 Amazon Rekognition カスタムラベルを導入することで、Amazon Textract で処理する枚数を削減することができ、Amazon Textract 単体の場合と比較して、コストの削減を実現しました。 また Amazon Textract は検証で 89% の精度でした。手書きの文字や、罫線に重なった文字は上手く認識しないこともあり、Key となる項目の名前のゆらぎは AWS Lambda 側にて訂正対応する処理を行っています。 スロットリング対策 Amazon Textract や Amazon Rekognition に一度に大量にデータを入力するとスロットリングエラーが発生することから、Amazon SQS や Amazon DynamoDB を用いて、適切に入出力が制御できるよう調整を行いました。 導入効果 AWS 三宅： OCR システムの導入効果と今後の展望についてお聞かせください。 ANA九冨様： １ 機分のデータ約 1.5 万件の中からサンプリングで約 5600 件の整備記録を用いて検証を行い、下記の結果となりました。 Amazon Rekognition カスタムラベルの正解率 ： 99.7% Amazon Textract のOCR の正解率： 89%（癖字や薄い印字は読み取り困難） 5600 ファイル（27,000 ページ）の中から、約 2000 枚の整備タグを抽出し転記する作業の工数削減 作業者の負担を大幅に低減できると判断できたため、今後は、本構成を使って実運用を開始していくとともに、更なる精度向上や保守体制を構築、誰でも使えるよう手順書を作成し汎用性を高めていきたいと考えております。 著者/協力者について 左側から 作山　直臣　マネジャ 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 田中　誉之密　マネジャ 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 九冨　佑輔 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 向　晃弘　リーダー 整備センター　プロセス変革推進部　ＩＴチーム 森　俊介　マネジャ 整備センター　プロセス変革推進部　ＩＴチーム AWS ソリューションアーキテクト 三宅 穂波

メインフレームとAWSを統合する共存アーキテクチャ 本記事は 2024 年 9 月 3 日に Migration &amp; Modernization Blog &nbsp;で公開された Integration architectures between mainframe and AWS for coexistence を翻訳したものです。 ブログでは、移行期におけるハイブリッド アーキテクチャの統合パターンとソリューションの設計方法を説明します。 メインフレーム環境のアプリケーションは、コードやデータもしくはその両方を共有することで、複雑に絡み合い密結合している場合があります。大規模なメインフレームアプリケーションを AWS に移行する際は、 Strangler Fig パターン を使用した段階的アプローチが推奨されます。段階的アプローチにより、移行 (マイグレーション) または変革 (モダナイゼーション) の過渡期の間、メインフレームと AWS 間のハイブリッドアーキテクチャが構築され、その統合が実現されます。 概要 メインフレームのワークロードは通常、一連のビジネス機能を実行する一連のプログラム、ミドルウェア、データストア、依存関係、およびリソースとして定義されます。AWS は、お客様のビジネスおよび技術戦略の目標に応じて、メインフレームのワークロードをモダナイズするための複数のパターンを提案します。これらのオプションは大きく 2 つのグループに分類できます。 マイグレーション &amp; モダナイゼーション (図 1.1 – 左) 拡張 &amp; 統合 (図 1.2 – 右) 図 1: AWS Mainframe Modernization パターン アプリケーションと移行の目的に合わせて、リプラットフォーム、リファクタリング、リライト、リパーチェスなどの各種手法を用い、メインフレームからコンポーネントを切り離して AWS クラウドに移行することを目指します。 ワークロードの拡張と統合は、メインフレームのデータを活用して、AWS 上に新しいビジネス機能を構築することを目的としています。 どちらのアプローチでも、メインフレームと AWS 環境を統合する共存アーキテクチャーが必要です。これには、移行フェーズ中または永続的にメインフレーム上に残るワークロードと、AWS クラウドに作成または移行されたワークロード間の相互作用の管理が含まれます。 アプローチ 通常、大規模なメインフレームのワークロードは並行して実行され、相互に密結合しています。Strangler Fig パターンの場合、各ワークロードは個別に移行されます。全体的に見れば、ワークロードを 1 つずつ順番に移行します。ビジネス価値、アプリケーションの複雑さ、統合ポイント、ビジネスの重要性に基づいてワークロードの移行に優先順位を付けます。時間の経過とともに、メインフレームのワークロードを 1 つずつ分離していきます。 図 2: ワークロードの絞り込みによるメインフレームアプリケーションの移行 メインフレームワークロードの移行に際しては、それらと強く結び付いた別のワークロードが存在しています。それらのワークロードにはアプリケーション間、データ間、またはアプリケーションとデータ間の統合機能が組み込まれています。図 2 は、一部のワークロードが AWS&nbsp; に移行され、他のワークロードがメインフレームに残るシナリオを示しています。 図 3 は、3 つの異なるタイプの統合を説明しています。 アプリケーション間 アプリケーションからデータへ データ間 図 3: 共存のためのハイブリッドアーキテクチャの必要性 さまざまな統合タイプは相互に排他的ではなく、むしろ互いに補完し合うことができます。統合タイプの選択は、主に、ワークロード間のメインフレーム上の既存の統合設定に影響されます。たとえば、ワークロードがアプリケーションコンポーネント (CICS、COBOL、MQ コールなど) を介してワークロード 2 とやり取りする場合は、アプリケーション間のパターンを確立する必要があります。逆に、ワークロードがワークロード 2 のデータにアクセスする必要がある場合は、データからデータへ、またはアプリケーションからアプリケーションへのパターンのいずれかを実装する必要があります。これらのパターンと関連する技術的実装のどちらを選択するかは、主に、スループット、パフォーマンス、プライマリデータの場所という 3 つの重要な基準に基づいて決定されます。 統合パターン 以下のパターンは、共存シナリオでのアプリケーション統合とその利用可能なソリューションについて理解するのに役立ちます。市場には多数の製品がありますが、ここでは数種類について説明します。 パターン 1 – アプリケーション間の統合パターン アプリケーション間統合パターンとは、2 つのソフトウェアアプリケーションやシステムを接続し、それらが協調して動作できるようにするプロセスを指します。用途や要件に応じて、さまざまなタイプのアーキテクチャと統合方式があります。 アーキテクチャ的には、アプリケーションを統合するための手法として、ハブアンドスポーク、エンタープライズサービスバス (ESB)、API マネジメントなど、複数のパターンが存在します。これらのアーキテクチャパターンでは、メインフレームと他の環境の間で仲介役を果たす、中央統合ハブやミドルウェアプラットフォームが関わります。各アプリケーションはハブ、ESB、またはAPIマネジメントレイヤーにのみ接続すれば良く、それらが接続システム間のデータのルーティングと変換を管理します。このアプローチにより、統合の管理と保守が簡素化されます。中央ハブ、ESB、または API マネジメントレイヤーとメインフレーム間の接続は、図 4 で説明されているポイントツーポイント統合パターンに依存します。 図 4: アプリケーション間の統合パターン AWS クラウドとメインフレーム間の最も一般的な統合タイプは以下のとおりです。 JCA コネクタを使用したポイントツーポイント このタイプの統合では、2 つのアプリケーションを相互に直接接続してデータを交換します。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合では、Java EE アプリケーションと CICS、IMS TM、Db2 ストアドプロシージャなどのメインフレームサブシステムとの直接接続を確立する必要があります。JCA コネクタとのポイントツーポイント統合には、Java アプリケーションとメインフレームを直接接続できるため、パフォーマンス、スケーラビリティ、トランザクション性のサポート、セキュリティが向上するなどのメリットがあります。一方、統合システム間の緊密な結合が生じるため、メッセージングや API のように疎結合された統合アプローチに比べて、柔軟性が低下し、保守が困難になります。 CICS、IMS、Db2 との統合に使用される主な 3 つのポイントツーポイントソリューションは次の 3 つです。 CICS との統合には CICS Transaction Gateway (CTG) を使用します。CTG は z/OS またはオープンシステム上にデプロイできます。 IMS との統合には IMS Connect を使用します。IMS Connect は z/OS 上にデプロイする必要があります。 外部アプリケーションから直接 JDBC 接続して Db2 for z/OS ストアドプロシージャを呼び出す。 JCA コネクタを使用したポイントツーポイント統合の注目すべき点は、その単方向性です。つまり、双方向通信をサポートする IMS Connect の場合を除き、 AWS クラウドからメインフレームに流れ、その逆は行われないということです。 API ベースの統合 RESTful API ベースの統合は、ソフトウェアシステムを統合するための柔軟で標準化されたアプローチを提供します。これにより、相互運用性、スケーラビリティ、および開発の容易さが可能になります。RESTful API は、Web 開発、モバイルアプリ、クラウドコンピューティング、Internet of Things (IoT) など、さまざまな分野で広く使用されています。RESTful API ベースの統合を使用するアプリケーションは、2 つの環境間でのトランザクションコンテキストの伝播が軽減されるように設計する必要があります 。(例えば、 SAGA パターンや補償メカニズムを使う) そうしないと、一貫性の問題や同期の問題が発生する可能性があります。 IBM の z/OS Connect や OpenLegacy などのソリューションを使用することで、メインフレームのサブシステムをAPI化することができます。z/OS Connect を使用すると、プログラム、データ、トランザクションなどのメインフレームの資産を RESTful API として公開することができます。これにより、クラウド上の幅広い最新アプリケーションやサービスからこれらの資産にアクセスし、利用することができるようになります。z/OS Connect の大きな利点の 1 つは、双方向の統合機能を持っていることです。これにより、最新のアプリケーションとメインフレームシステムの間で、双方向の通信が可能になります。つまり、最新のアプリケーションがメインフレームからサービスやデータを利用できるだけでなく、メインフレームのトランザクションやアプリケーションが AWS からアプリケーションやサービスを利用することもできるのです。 メッセージ指向とイベント駆動型の統合 アプリケーションは、メッセージを介して非同期に通信します。メッセージはキューに入れられ、システム間で確実に配信されます。メッセージ指向とイベント駆動型の統合は、パブリッシュサブスクライブやリクエストリプライなど、様々なメッセージングパターンをサポートできます。IBM MQ は、メインフレームと AWS 間の通信とデータ交換を促進する主要なメッセージングミドルウェアの 1 つです。パブリッシュサブスクライブパターンやリクエストリプライパターンを活用することで、メインフレームとの統合に使用できます。 もう1つのオプションは、IBM MQ を介して Kafka をメインフレームと統合することです。これには、適切なコネクターを使用してKafkaとMQの間の通信を確立するために、Kafka Connect を使用することが含まれます。Kafka Connect は、メインフレームまたはクラウド上で実行できます。Kafka Connect は、Kafka とメインフレームアプリケーションとのデータストリーミングのためのコネクター構築とデプロイのフレームワークを提供することで、統合プロセスを簡素化します。Kafka を使用すると、メインフレームと AWS の間で追加の統合作業を行うことなく、関連するトピックに追加のコンシューマーがサブスクライブできます。 パターン 2 – データ間の統合パターン ワークロードが AWS クラウドに移行され、他のワークロードがまだメインフレームにある場合、メインフレームとの間でデータを送信する頻度に応じてさまざまな方法があります。図 5 は、データ転送のニーズと頻度に対応するために構築する必要がある、さまざまな統合パターンを示しています。 図 5 : データ間の統合パターン ニアリアルタイムのデータ転送 ニアリアルタイムのデータ転送とは、あるプラットフォームから別のプラットフォームへ、ニアリアルタイムにデータの更新を複製できるプロセスです。関連するツールは、変更ログに基づいてニアリアルタイムでデータを移行するために、変更データキャプチャ (CDC) を使用します。データ転送の要件は、単方向、両方向、または双方向である可能性があります。 単方向とは、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向のいずれかに、データを複製する必要があることを意味します。両方向とは、データのレプリケーションが両方向で行われる必要があるものの、異なる関連性のないテーブルに対して行われることを意味します。一方、双方向は、レプリケーションが両方向で行われる必要があるが、関連するテーブルに対して行われることを意味します。関連するテーブルへの更新によるデータの競合という追加の課題があるため、双方向レプリケーションは最後の手段とすべきです。メインフレームから AWS にアプリケーションを移行する際、一方のプラットフォームのアプリケーションからの更新を、もう一方ですぐに利用できるようになります。 AWS Mainframe Modernization サービスは、Precisely 社の CDC テクノロジーを採用した AWS Mainframe Modernization Data Replication を使用して、メインフレームと AWS 間のデータレプリケーションを実現します。これにより、Db2、IMS、VSAM などのメインフレームや&nbsp; IBM i データソースから、幅広い AWS クラウドデータベースの宛先へ、およびその逆方向に、異種データをニアリアルタイムで複製することができます。AWS のデータレプリケーションは、レイテンシーの低い CDC テクノロジーを活用しており、ソースデータベースに加えられた変更がニアリアルタイムでターゲットデータベースに伝播されると同時に、データの一貫性、正確性、鮮度、および有効性も確保されます。この機能により、共存シナリオ、分析、新しいチャネルの作成など、さまざまなユースケースが可能になります。 ファイルベースの転送 ほとんどの企業では、メインフレームからデータを移動するためのファイルベースの転送メカニズムが存在します。IBM Sterling Connect:Direct または SFTP のようなメカニズムを使用して、ファイル転送をサポートすることができます。メインフレームとオープンシステム間のファイル転送における課題の1つは、データ形式の違いです。メインフレームの COMP、COMP-3、その他のバイナリフィールドを持たないファイルの場合、SFTP と IBM Sterling Connect:Direct は、そのままデータ転送に使用できます。（EBCDIC を ASCII ベースまたは選択した文字セットに変換）。バイナリフィールドを持つファイルの場合は、特別な変換ソフトウェアが必要です。AWS Mainframe Modernization サービスは、さまざまな共存、拡張、移行のユースケースをサポートするためのファイル転送機能を提供しています。 AWS Mainframe Modernization File Transfer を使用すると、完全に管理されたサービスでデータセットとファイルを転送および変換し、AWS Mainframe Modernization サービスと Amazon S3 へのモダナイズ、移行、拡張のユースケースを加速および簡素化できます。 抽出、転送、ロード (ETL)ベースの転送 ETL ベースの転送は、メインフレームから AWS にデータを移動するためのデータ統合および転送メカニズムです。メインフレームのソース (VSAM、Db2 など) のデータは、変換プロセスの一部として抽出、整理、クレンジングされ、AWS にアップロードされます。ETL プロセスのすべてにおいて、ソースとターゲットへの JDBC 接続が使用されます。この方法は、 AWS Glue のような ETL 専用ツールや IBM data stage、Informatica、Precisely ETL connect&nbsp; などの ISV 製品によってサポートされており、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向にデータを移行することができます。 アーカイブデータ転送 仮想テープライブラリ (VTL) のようなメインフレーム独自のストレージソリューションは、複雑なツールを備えたプラットフォームに貴重なデータが保持しています。これにより、それらのデータ検索タスクのためのメインフレームでのコンピューティングおよびストレージのコストが高くなる可能性があります。アーカイブデータ転送のパターンは、メインフレームテープから Amazon S3 にデータを移動するのに役立ちます。 BMC AMI Cloud は、顧客がメインフレームのテープを Amazon S3 に移動することを可能にします。 パターン 3 – アプリケーションとデータの統合パターン このオプションは、プラットフォーム間でアプリケーションとデータの統合を実装することです (図6) 。アプリケーションとデータの統合とは、AWS またはメインフレーム上で実行されているアプリケーションが、AWSまたはメインフレーム上にリモートでホストされているデータにアクセスすることを意味します。 図 6: アプリケーションとデータの統合パターン 一般的に、ローカルデータへのアクセスを可能にし、リモートデータアクセスに伴う遅延の影響を回避するためには、データ間の統合が望ましいです。データが非常に密接に結合されている場合、データ間の統合パターンを実装することは困難になります。このような場合、アプリケーションとデータの統合の方が適している可能性があります。 アプリケーションとデータの統合パターンの2つのバリエーション データの単一コピーを使用するアプリケーションとデータの統合 デュアル書き込みを活用したアプリケーションとデータの統合 データの単一コピーパターン このパターンのバリエーションでは、AWS またはメインフレームのいずれかに存在する、データの単一の情報源があります。データがローカルにないアプリケーションは、JDBC やゲートウェイなどの技術を使用してリモートアクセスを実行する必要があります。このパターンは、単一のデータコピーを維持することでデータ管理を簡素化しますが、データにアクセスするリモートアプリケーションにレイテンシが発生し、アプリケーション全体のパフォーマンスに影響を与えます。 AWS にアプリケーション、メインフレームにデータベース – このタイプの統合では、クラウド上のアプリケーションがメインフレームデータベースに直接接続されています。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合は、標準化されたインターフェース、パフォーマンスの向上、移植性、スケーラビリティ、クラウド上の Java アプリケーションとメインフレーム上のデータベース間の直接接続を確立することによるトランザクション性とセキュリティのサポートなどの利点を提供します。一方で、JCA や JDBC を使った統合では、統合されるシステム間に密結合をもたらし、その結果、システムの柔軟性が低下しメンテナンスが困難になる傾向があります。JCA コネクタまたは JDBC を使用したポイントツーポイント統合は、本質的に一方向であり、統合はクラウド上のアプリケーションからメインフレームデータベースにのみ流れることを意味します。 メインフレーム上のアプリケーションと AWS 上のデータベース、またはその逆の組み合わせには、様々な統合方法があります。 メインフレーム上のアプリケーションは、Db2 フェデレーテッドサーバーを使用して、AWS 内のデータベースにアクセスすることができ、その逆もまた同様です。これにより、あいまいさを減らすことができ、データのコピーを 1 つだけ保存すればよいため、運用の複雑さを軽減できます。 フェデレーションは、機能ごとにデータベースを分割するスケーリング手法です。メインフレームデータのフェデレーションは、異種データへのリアルタイムアクセスを統一的な方法で提供し、最小限の設定オーバーヘッドで、AWS またはその逆の分散アプリケーションやデータベースでの利用を可能にします。ただし、フェデレーテッドサーバーは、異なるデータストアからのデータ結合に関して、ある程度の複雑さの層を導入するため、クエリのパフォーマンスとアプリケーションのスケーラビリティに影響を与える可能性があります。 仮想化もデータ管理技術のひとつで、アプリケーションはデータのフォーマットや所在に関する技術的な詳細を知らなくても、データにアクセスしたり変更したりすることができます。IBM Data Virtualization Manager for z/OS(IBMz DVM) は、データをコピーまたは移動する必要なく、複数のソースからのデータの単一表現を作成します。このため、AWS 上の分散アプリケーションとデータベースは、メインフレーム上のさまざまなデータストア (IMS、IDMS、または Db2) とファイルシステム (シーケンシャル、VSAM、VSAM CICS、ADABAS、または MQ) にアクセスできます。 仮想化により、アプリケーション開発者からデータ実装を隠蔽し、メインフレーム資産を API として AWS アプリケーションやデータベース上の分散チャネルに安全に公開します。 データ仮想化はデータ連携とは対照的に、データベースの結合や初歩的なデータ処理を使用した単純なデータ処理に限定されています。 デュアル書き込みパターン このパターンのバリエーションでは、データのコピーが 2 つあり、1 つは AWS 上に、もう 1 つはメインフレーム上にあります。レプリケーションメカニズムを使用する代わりに、アプリケーションは両方のロケーションに対して二重の書き込み ( 挿入/更新 ) を実行します。このパターンでは、読み込み操作はローカルで行われ、書き込み操作はローカルとリモートの両方で行われるため、レイテンシの影響を減らすことができます。 書き込み頻度が低く、読み出し頻度が高いアプリケーションに適しています。大きな欠点は、1 つのトランザクション内で 2 つの書き込みを実行し、データの整合性と一貫性を確保するために、アプリケーションレベルで複雑さが生じることである。 このパターンは、ニアリアルタイムの同期を提供するデータ間統合とは異なり、両方の場所でリアルタイムのデータコピーを提供します。 AWS 上のアプリケーションとメインフレーム上のデータベース – このタイプの統合では、AWS 上とメインフレーム上の両方でデータの同期コピーを保持します。 AWS 上のアプリケーションは、AWS データベースとメインフレームデータベースに同時に直接接続されます。 この統合は、AWS 上の Java EE アプリケーション、AWS 上のデータベース、JDBC を介したメインフレームデータベース間の直接接続を確立する JCA (Java Connector Architecture) コネクタを使用して実現されます。 デュアル書き込みの選択は、アーキテクチャにデータの弾力性を追加しますが、アプリケーションにパフォーマンスの問題をもたらす可能性があります。統合の特性と性質は、AWS 上のアプリケーションとメインフレーム上のデータベースによるデータの単一コピーパターンに似ています。 メインフレーム上のアプリケーションとメインフレームと AWS 上のデータベース – メインフレーム上のアプリケーションをメインフレーム上のデータベースと AWS 上のデータベースに直接統合する様々なチャネルは、メインフレームと AWS 上に同期的にコピーされたデータを保存するという唯一の違いで、データの単一コピーパターンに似ています。 まとめ 大規模な顧客がメインフレームアプリケーションを AWS に移行する際、一部の顧客は、ビッグバン移行に伴うリスクを最小限に抑えるために、Strangler Fig パターンを使用した段階的なアプローチを採用します。このアプローチでは、メインフレームと AWS 間の相互運用性が必要です。この記事では、この相互運用性を促進するさまざまな統合パターンについてまとめました。すべての統合シナリオに対して、万能のソリューションはありません。各パターンには、それぞれ長所と短所があります。これらの統合パターンを選択する際は、慎重な検討が必要です。決定のための主な要因には、スループット、パフォーマンス、トランザクションコンテキストの伝播、整合性、および主要データの場所が含まれます。 AWS Mainframe Modernization に関するご相談は、担当営業にご連絡頂くか、もしくは公式サイトの&nbsp; Web フォーム &nbsp;でお問い合わせください。 本記事は、Yann Kindelberger, Chiranjeev Mukherjee, Saikat Chatterjee による “ Integration architectures between mainframe and AWS for coexistence ” を翻訳したものです。翻訳はソリューションアーキテクトの萩野谷聡が担当しました。

本記事は2024年9月16日に公開された Enable cloud operations workflows with generative AI using Agents for Amazon Bedrock and Amazon CloudWatch Logs を翻訳したものです。翻訳はソリューションアーキテクトの濱野谷(@yoshiehm)が担当しました。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要 AI 企業の高性能な基盤モデル（ FM ）を単一の API を通じて提供するフルマネージドサービスです。また、生成 AI アプリケーションを構築するために必要な幅広い機能も提供し、セキュリティ、プライバシー、責任ある AI といった特徴を備えています。 Amazon Bedrock Agents は、複数ステップのタスクを自動的にオーケストレーションすることで、生成 AI アプリケーション開発を加速するのに役立ちます。Amazon Bedrock Agents は、Bedrock の FM を拡張して、旅行の予約や保険金請求の処理から広告キャンペーンの作成や在庫管理まで、複雑なビジネスタスクを実行します。これらはすべてコードを書くことなく実行できます。 Amazon CloudWatch Logs を使用すると、すべてのシステム、アプリケーション、使用している AWS サービスからのログを、高度にスケーラブルな単一のサービスに一元化できます。CloudWatch Logs では、ログデータを使用してアプリケーションとシステムを監視したり、特定のエラーコードやパターンを検索したり、特定のフィールドに基づいてフィルタリングしたり、将来の分析のために安全にアーカイブしたりすることができます。 このブログ記事では、AWS のクラウド運用シナリオにおいて、アプリケーションログファイルで観察されたエラーに基づいて問題を分類し、その後解決するために、Amazon Bedrock Agents と Bedrock の FM を使用した 生成 AI の使用例を紹介します。 我々のソリューションでは、Amazon Bedrock Agents は基盤モデル (FM) の推論機能を使用して、CloudWatch Logs に公開されたアプリケーションログについてのエラー解決を要求するユーザー指示を複数のステップに分解します。開発者/アナリストが提供した自然言語の指示を使用してオーケストレーション計画を作成し、その後、関連する API を呼び出し、 Amazon Bedrock Knowledge Base にアクセスすることで計画を実行します。これには、大規模言語モデル (LLM) によって生成された応答を補強するために、ベクトルデータストア ( Amazon OpenSearch Serverless ) から情報を引き出す処理が含まれます。 また、Amazon Bedrock Agents が自動的に計画を作成し、サポートアナリストが提起した自然言語の質問からリクエストを満たすための実行ステップを推論する思考の連鎖を示すトレースも紹介します。 前提条件 AWS SAM をインストールします。 このソリューションのリポジトリをクローンします。: sudo yum install -y unzip git clone https://github.com/aws-samples/genai-bedrock-serverless.git cd genai-bedrock-serverless/cloudops cloudops フォルダから、ソリューションの SAM テンプレートをデプロイします。： sam build -t template.yaml sam deploy --resolve-s3 --stack-name &lt;anyname&gt; --capabilities CAPABILITY_NAMED_IAM テンプレートは 2 つの Amazon S3 バケットを作成します。 AWS CloudFormation コンソールで、デプロイされた SAM テンプレートの出力セクションに移動して、これら 2 つの S3 バケット（ProductDocsBucket と CloudOpsSupportBucket）の名前を取得し、S3 コンソールで探すことができるようにします。 ソリューションの data フォルダにある ProductErrorCodes.xlsx ファイルを S3 コンソールの ProductDocsBucket バケットにアップロードします。 ソリューションの data フォルダにある cloudopsupport.json と applogs.csv ファイルを S3 コンソールの CloudOpsSupportBucket バケットにアップロードします。 Amazon Bedrock knowledge base を作成します。 この手順に従ってナレッジベースを作成します。 ステップ 7 で Amazon OpenSearch Serverless ベクトル検索コレクションをナレッジベースとして作成する 新しいベクトルストアをクイック作成 オプションを含むすべてのデフォルトを受け入れます。ソリューションのユースケースに特有の以下の領域を設定します。： ステップ 4a で、ナレッジベースのオプションの説明を提供します。例えば「エラーの説明に基づいてエラー解決方法を提供する」など。 ステップ 5c で、ナレッジベースのデータソースのS3 URI を提供する必要がある場合、ProductDocsBucket の S3 URI を選択します。 ソリューション概要 このソリューションは、 Amazon EC2 インスタンスまたは AWS 外部（オンプレミスまたはハイブリッドクラウド）のインスタンスで実行されているカスタムアプリケーションから始まります。インスタンスにインストールされた Amazon CloudWatch Agent がアプリケーションのログファイルを Amazon CloudWatch Logs にストリーミングします。Windows または Linux システムに統合 CloudWatch Logs エージェントをインストールする詳細なドキュメントは こちら です。また、 こちら の方法でAWS Systems Manager を使用して EC2 またはハイブリッドインスタンスに CloudWatch エージェントをインストールおよび更新することもできます。CloudWatch Logs にアプリケーションログをストリーミングしたら、 こちら に記載されている手順に従ってログファイルを Amazon S3 にエクスポートできます。このソリューションでは、カスタムアプリケーションの CloudWatch セットアップが完了していることを前提としており、前提条件セクションで S3 にアップロードしたサンプルアプリケーションログファイル（.csv 形式）を提供しています。 このシナリオでは、サポートアナリストはアプリケーションが提供する HTTP エラーコードとエラーのタイムスタンプに基づいてエラーを解決しようとしています。Amazon Bedrock Agents がユーザーリクエストを満たすために、エージェントを次の２つで構成します。エージェントは、エージェントへの指示と、エージェントに提供された API スキーマとナレッジベースに基づいてプロンプトを作成し、適切なタスクのシーケンスを決定します。 （１） アクショングループ – アクションの API スキーマを定義し、エージェントが実行できるアクションを実装する AWS Lambda 関数と紐づく （２）ナレッジベース – 基本的に AWS 管理のベクトルデータベース（この場合は Amazon OpenSearch Serverless）であり、エージェントが顧客のクエリに答え、生成された応答を改善するためにクエリできる情報のリポジトリを提供する 図 1 に示すハイレベルアーキテクチャ図は、ソリューションのさまざまなコンポーネントが連携して動作する様子を示しています。CloudWatch Logs ファイルが Amazon S3 にエクスポートされ、エージェントには API スキーマとスキーマのメソッドを実装する Lambda 関数が提供されます。また、エージェントはアーキテクチャ図に示すように ナレッジベースに関連付けられ、図 2 に示すフローを実行します。 図 1:エンドツーエンドのフローを示すソリューションアーキテクチャ 図 2: エンドツーエンドのフローを説明したフローチャート セットアップ Amazon Bedrock Agents を作成します。Amazon Bedrock Agents コンソールから こちら の手順に従って エージェントを作成してください。以下の、ソリューションの構成に特有の部分を除いて、すべてデフォルトのままで構いません。 エージェントを設定するには のセクションで以下を実施します。: ステップ 2c で モデルを選択 する際、Anthropic Claude 3 以降のモデルを選択します。ステップ 2d の エージェント向けの指示 では、以下の図のように次の指示を提供します: “あなたは、HTTPエラーコードとエラーのタイムスタンプに基づいて、エラー解決と影響を受けるアプリケーションコンポーネント情報を提供するエージェントです” 図 3: エージェントの作成 ステップ 2g の IAM 権限 の エージェント リソースロール のセクションで、 既存のサービスロールを使用 を選択し、ソリューションの SAM テンプレートによってプロビジョニングされたIAM サービスロールの ‘AmazonBedrockExecutionRoleForAgents_CloudOps’ を選択します。 ステップ 3 でエージェントにアクショングループを追加するには、 こちら の手順に従ってコンソールからアクショングループを追加します。” Provide error description for this error based on HTTP error code and timestamp of the error（HTTP エラーコードとエラーのタイムスタンプに基づいてこのエラーのエラー説明を提供する）” のような任意の説明をアクショングループに提供します。（図 4 参照） ステップ 6 の アクショングループタイプ セクションで、 Define with API schemas を選択します。（図 4 参照） 図 4: アクショングループの作成 ステップ 7 の Action group invocation セクションで、既存の Lambda 関数を選択し、既にプロビジョニングされている &lt;stackname&gt;-CloudOpsSupportLambda というプレフィックスの Lambda 関数を選択します（図 5 参照） 図 5: アクショングループに Lambda 関数を関連付ける ステップ 8 の Action group schema セクションで、 Select an existing API schema を選択し、 S3 を参照 ボタンを選択して、アカウントにプロビジョニングされた CloudOpsSupportBucket S3 バケットから cloudsopssupport.json ファイルを選択します（図 6 参照） 図 6: API スキーマをアクショングループに関連付ける ステップ 4 のナレッジベースセクションで 追加 を選択して、前提条件セクションで作成したナレッジグループをエージェントに関連付けます。”このエラーのエラー説明に基づいて、エラー解決と影響を受けるアプリケーションコンポーネントを提供してください” のようなナレッジベース指示をエージェントに提供します。（図 7 参照） 図 7: エージェントへのナレッジベースの追加 テストと検証 Amazon Bedrock コンソールは、エージェントをテストするための UI を提供します。 こちら の手順に従ってエージェントをテストし、デプロイの準備をしてください。 こちら の手順に従って、以下に示すようにエージェントのエイリアスを作成し、そのエイリアスに関連付けられたエージェントバージョンを作成してエージェントをデプロイします: 図 8: エージェントのエイリアスとバージョンを作成する これでエージェントのテストの準備が整いました。Amazon Bedrock Agents UI でサンプルプロンプトを提供します。サポートアナリストとして、アプリケーションが提供する HTTP エラーコードとエラーのタイムスタンプに基づいてエラーを解決しようとしています。ソリューションで提供したサンプルアプリケーションログファイルのサンプルエラーコードと関連するタイムスタンプに基づいて、”HTTP エラーコード 500、タイムスタンプ 202404219:00 のエラー解決方法を提供してください。応答は日本語で表示してください。” のような単純なプロンプトを使用できます。エージェントがエラーを解決するための情報を取得した詳細なエラー解決策を提供します。（図 9 参照） 図 9: プロンプトを提供し、エージェントから最終的な応答を取得する 各応答の トレースを表示 を選択すると、ダイアログボックスにエージェントが使用した推論手法と FM が生成した最終的な応答が表示されます。 図 10: エージェントからの思考の連鎖と推論を表示する クリーンアップ このポストで説明したソリューションを試した後、継続的な料金を避け、アカウントをクリーンアップするには、次の手順を実行してください: agentsforbedrock-cloudops フォルダから、ソリューションの SAM テンプレートを削除します: sam delete --stack-name &lt;yourstackname&gt; --capabilities CAPABILITY_NAMED_IAM Amazon Bedrock Agents を削除します。Amazon Bedrock コンソールから、このソリューションで作成したエージェントを選択し、削除を選択して、 エージェントを削除する手順 に従います。 Amazon Bedrock knowledge base を削除します。Amazon Bedrock コンソールから、このソリューションで作成したナレッジベースを選択し、削除を選択して ナレッジベースを削除する手順 に従います。 結論 このブログ投稿では、AWS のクラウド運用シナリオにおいて、Amazon Bedrock Agents と Bedrock の FM、および Amazon CloudWatch Logs を使用した 生成 AI の使用を実証しました。このソリューションをカスタマイズおよび拡張して、複数のログソースを持つアプリケーションログファイルで観察されたエラーに基づいて問題をトリアージし、その後解決するシナリオに適応させることができます。アクショングループの Lambda に追加のロジックを組み込んだり、ナレッジベースに関連情報リポジトリを追加したりすることも可能です。 著者について Kanishk Mahajan は AWS のプリンシパル ソリューションアーキテクトです。AWS の ISV 顧客とパートナーのクラウド変革とソリューションアーキテクチャをリードしています。Kanishk はコンテナ、クラウド運用、移行とモダナイゼーション、AI/ML、レジリエンス、セキュリティとコンプライアンスを専門としています。彼は AWS でこれらの各ドメインの Technical Field Community (TFC) メンバーです。 Praveen Gudipudi は、テクノロジーと機械学習に強い情熱を持つ Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。複雑な課題を解決し、AWS 顧客のクラウド運用をシームレスに行うことに長けています。仕事以外では、Praveen は本を読むことを楽しみ、熱心な旅行者として常に新しい目的地を探索することを楽しんでいます。

Amazon S3 Express One Zone は、高性能のシングルアベイラビリティーゾーン (AZ) S3 ストレージ クラスで、 AWS Key Management Service (KMS) キー (SSE-KMS) によるサーバー側の暗号化をサポートするようになりました。 S3 Express One Zone では、 S3 ディレクトリバケット に保存されているすべてのオブジェクトが Amazon S3 マネージドキー (SSE-S3) を使用してデフォルトで既に暗号化されています。9 月 17 日より、 AWS KMS のカスタマーマネージドキー を使用して、パフォーマンスに影響を与えずに保管中のデータを暗号化できます。この新しい暗号化機能により、S3 Express One Zone を使用する際に、コンプライアンスおよび規制要件を満たすための追加のオプションがもたらされます。S3 Express One Zone は、最も頻繁にアクセスされるデータやレイテンシーの影響を受けやすいアプリケーションに、1 桁ミリ秒単位のデータアクセスを一貫して提供するように設計されています。 S3 ディレクトリバケットでは、SSE-KMS 暗号化用にバケットごとに 1 つのカスタマーマネージドキーのみを指定できます。カスタマーマネージドキーを追加すると、それを編集して新しいキーを使用することはできません。一方、S3 汎用バケットでは、バケットのデフォルトの暗号化設定を変更することで、または S3 PUT リクエスト中に複数の KMS キーを使用できます。SSE-KMS を S3 Express One Zone で使用する場合、 S3 バケットキー は常に有効になっています。S3 バケットキーは無料で、AWS KMS へのリクエスト数を最大 99% 削減し、パフォーマンスとコストの両方を最適化します。 SSE-KMS と Amazon S3 Express One Zone の併用 この新機能の実際の動作を説明するために、最初にその手順に従って Amazon S3 コンソール で S3 ディレクトリバケットを作成 し、 アベイラビリティーゾーン として apne1-az4 を使用します。 ベース名 に「 s3express-kms 」と入力すると、アベイラビリティーゾーン ID を含むサフィックスが自動的に追加され、最終的な名前が作成されます。次に、 [Data is stored in a single Availability Zone] (データは単一のアベイラビリティーゾーンに保存されます) のチェックボックスをオンにして同意してから、 [Create bucket] (バケットを作成) をクリックします。 次に、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、作成したバケットに暗号化を設定する手順を説明します。 SSE-KMS を AWS CLI 経由で S3 Express One Zone で使用するには、以下の ポリシー に基づく AWS Identity and Access Management (IAM) ユーザー または ロール が必要です。このポリシーでは、暗号化されたファイルを S3 ディレクトリバケットに正常にアップロードおよびダウンロードするために必要な CreateSession API 操作を行えます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3express:CreateSession" ], "Resource": [ "arn:aws:s3express:*:&lt;account&gt;:bucket/s3express-kms--apne1-az4--x-s3" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:*:&lt;account&gt;:key/&lt;keyId&gt;" ] } ] } PutBucketEncryption API を使用して、 デフォルトのバケット暗号化 を SSE-KMS に設定します。&nbsp;以下は AWS CLI の例です。 aws s3api put-bucket-encryption \ --bucket s3express-kms--apne1-az4--x-s3 \ --server-side-encryption-configuration \ '{"Rules": [{"ApplyServerSideEncryptionByDefault":\ {"SSEAlgorithm": "aws:kms", \ "KMSMasterKeyID": "1234abcd-12ab-34cd-56ef-1234567890ab"\ },\ "BucketKeyEnabled":true}]}' この S3 ディレクトリバケットにアップロードした新しいオブジェクトは、AWS KMS キーを使用して自動的に暗号化されます。 PutObject コマンドを使用して、 confidential-doc.txt という名前の新しいファイルを S3 ディレクトリバケットにアップロードします。 aws s3api put-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt \ --body confidential-doc.txt 前のコマンドが成功すると、次の出力が表示されます。 { "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ChecksumCRC32": "0duteA==", "ServerSideEncryption": "aws:kms", "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true } HeadObject コマンドでオブジェクトのプロパティを確認すると、以前に作成したキーで SSE-KMS を使用して暗号化されていることがわかります。 aws s3api head-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt すると、以下の出力が得られます。 &nbsp; { "AcceptRanges": "bytes", "LastModified": "2024-08-21T15:29:22+00:00", "ContentLength": 5, "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ContentType": "binary/octet-stream", "ServerSideEncryption": "aws:kms", "Metadata": {}, "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true, "StorageClass": "EXPRESS_ONEZONE" } I download the encrypted object with GetObject : aws s3api get-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt output-confidential-doc.txt 私のセッションには必要なアクセス許可があるため、オブジェクトは自動的にダウンロードされ、復号化されます。 { "AcceptRanges": "bytes", "LastModified": "2024-08-21T15:29:22+00:00", "ContentLength": 5, "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ContentType": "binary/octet-stream", "ServerSideEncryption": "aws:kms", "Metadata": {}, "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true, "StorageClass": "EXPRESS_ONEZONE" } この 2 番目のテストでは、オブジェクトをダウンロードするために必要な KMS キーアクセス許可が付与されていないポリシーを持つ別の IAM ユーザーを使用します。この試みは AccessDenied エラーが発生して失敗します。これは、SSE-KMS 暗号化が意図したとおりに機能していることを示します。 CreateSession オペレーションの呼び出し中にエラーが発生しました (AccessDenied): アクセスが拒否されました このデモンストレーションでは、SSE-KMS がどのように S3 Express One Zone とシームレスに連携し、権限のあるユーザーの使いやすさを維持しながらセキュリティをさらに強化するかを示します。 知っておくべきこと はじめに – AWS CLI または AWS SDK を使用して S3 Express One Zone の SSE-KMS を有効にできます。S3 ディレクトリバケットのデフォルトの暗号化設定を SSE-KMS に設定し、AWS KMS キーを指定します。存続期間中、S3 ディレクトリバケットごとに 1 つのカスタマーマネージドキーしか使用できないことに注意してください。 リージョン – カスタマーマネージドキーを使用した SSE-KMS の S3 Express One Zone サポートは、 S3 Express One Zone が現在利用可能なすべての AWS リージョン で利用できます。 パフォーマンス – S3 Express One Zone で SSE-KMS を使用しても、リクエストのレイテンシーには影響しません。これまでと同じ 1 桁のミリ秒単位のデータアクセスが引き続き行えます。 料金 – 暗号化と復号化に使用されるデータキーを生成および取得するには、AWS KMS の料金をお支払いいただきます。詳細については、 AWS KMS の料金ページ をご覧ください。さらに、SSE-KMS と S3 Express One Zone を併用する場合、 CopyObject と UploadPartCopy を除くすべてのデータプレーンオペレーションで S3 バケットキーがデフォルトで有効になり、無効にすることはできません。これにより、AWS KMS へのリクエスト数が最大 99% 削減され、パフォーマンスとコストの両方が最適化されます。 AWS CloudTrail 統合 – AWS CloudTrail を使用して S3 Express One Zone オブジェクトの SSE-KMS アクションを監査できます。これについては、 以前のブログ投稿 で詳しく説明しています。 – Eli. 2024 年 9 月 19 日に更新 – CLI の例を更新して、コンソールではなく既存のバケットのデフォルト暗号化を設定しました。 原文は こちら です。

本稿は 2024 年 7 月 2 日に公開された “ Enhance data security with fine-grained access controls in Amazon DataZone ” を翻訳したものです。 アクセス制御を細かな粒度で行うというのは、現代のデータレイクやデータウェアハウスに求められるデータセキュリティの重要な要素となっています。組織が複数のデータソースにまたがる膨大な量のデータを扱う中で、機密情報を管理する必要性が高まっています。データプライバシー、コンプライアンス、そしてセキュリティを維持する上では、適切な人に適切なデータへのアクセス権を与えつつ、機密情報を不正アクセスから守ることが重要になります。 本日、 Amazon DataZone は細かな粒度のアクセス制御機能を導入しました。Amazon DataZone のビジネスデータカタログで管理されているデータレイクやデータウェアハウス上のデータアセットに対して、細かな粒度のアクセス制御が可能になります。この新機能により、データ所有者はデータアセットの単位でアクセス権を付与するのではなく、行や列の単位でアクセスを制限できるようになります。例えば、データに個人を特定できる情報 (PII) などの機密情報が含まれる列がある場合、必要な列へのアクセスだけを許可することで、機密情報を保護しつつ、機密性の低いデータへのアクセスが可能になります。同様に、行単位でのアクセス制御も可能です。ユーザーの役割やタスクに関連する行のみが表示されるようになります。 この記事では、Amazon DataZone の新機能を使用し、行と列のアセットフィルターによって、細かな粒度のアクセス制御を実現する方法について説明します。 行フィルターと列フィルター 行フィルターを使用すると、定義した条件に基づいて特定の行へのアクセスを制限できます。例えば、テーブルにアメリカとヨーロッパのデータが含まれる場合に、ヨーロッパの従業員がその地域に関連するデータにのみアクセスできるようにするには、地域がヨーロッパ以外の行を除外する行フィルター (例: region != 'Europe' ) を作成できます。同様に、アメリカの従業員がヨーロッパのデータにアクセスできないようにすることも可能です。 列フィルターを使用すると、データアセット内の特定の列へのアクセスを制限できます。例えば、テーブルに個人を特定できる情報 (PII) などの機密情報が含まれている場合、列フィルターを作成して PII に該当する列を除外できます。これにより、データアセットをサブスクライブしたユーザーは、機密情報以外のデータにしかアクセスできなくなります。 Amazon DataZone の行フィルターや列フィルターを使用すると、AWS のデータレイクとデータウェアハウス全体のデータに対して、ビジネスユーザーにとって使いやすいメカニズムを使用しながら、誰がどのデータにアクセスできるかを制御できるようになります。Amazon DataZone で細かな粒度のアクセス制御を使用するには、Amazon DataZone のビジネスデータカタログ上のデータアセットに対して、行フィルターや列フィルターを作成します。ユーザーがデータアセットの利用を希望すると、適切な行フィルターや列フィルターを適用した上でアクセスを許可できます。Amazon DataZone は、 AWS Lake Formation と Amazon Redshift を使用してこれらのフィルターを実現し、利用者が許可された行と列にのみアクセスできるようにします。 ソリューションの概要 この新機能を説明するにあたって、電子機器の e コマースプラットフォームを例として用います。このプラットフォームで、Amazon DataZone を使用して細かな粒度のアクセス制御を実装しようとしているサンプルのユースケースを検討します。この企業は複数のカテゴリの製品を取り扱っており、それぞれこの企業の各担当部門が管理しています。プラットフォーム管理チームは、各部門が自身のカテゴリに属するデータのみを参照できるようにしたいと考えています。加えて、価格関連のデータを参照できるのは財務チームのみに制限するという財務チームの要件に従う必要があります。 営業チームは、データプロデューサーとして AWS Glue の Product Sales (製品販売) テーブルを Amazon DataZone のビジネスデータカタログにパブリッシュ (公開) しました。このテーブルは Product-Sales プロジェクトに属しており、 Laptops (ラップトップ) と Servers (サーバー) の両方のカテゴリのデータが含まれています。ラップトップ部門とサーバー部門の両方の分析チームは、それぞれの分析プロジェクトのためにこのデータへのアクセス権が必要です。データ所有者の目標は、データコンシューマーに対して所属する部門に応じたデータアクセスを許可することです。つまり、ラップトップ部門の販売分析チームにはラップトップの販売データの行に対してのみ、そしてサーバー部門の販売分析チームにはサーバーの販売データの行に対してのみアクセスを許可することです。さらに、データ所有者は両チームが価格関連のデータにアクセスできないようにしたいと考えています。この記事では、Amazon DataZone でこのユースケースを実現するための手順を示します。 この解決策を構成する手順は次のとおりです。 データを公開するパブリッシャーは、アクセスを制限するためのアセットフィルターを作成します: ラップトップの販売データの行のみにアクセスを制限する Laptops only 行フィルターと、サーバーの販売データの行のみにアクセスを制限する Servers only 行フィルターの 2 つの行フィルターを作成します。 また、 Product Sales から価格関連の列を除外する exclude-price-columns という列フィルターも作成します。 データを利用するコンシューマーは、データアセットを検出した後、サブスクリプションをリクエストします: ラップトップ部門の販売分析チームのアナリストが Product Sales データアセットのサブスクリプションをリクエストします。 サーバー部門の販売分析チームのアナリストも Product Sales データアセットのサブスクリプションをリクエストします。 承認をもらうために、両方のサブスクリプションリクエストがパブリッシャーに送られます。 パブリッシャーは、サブスクリプションを承認し、適切なフィルターを適用します: パブリッシャーはラップトップ部門のアナリストからのリクエストを承認し、 Laptops only 行フィルターと exclude-price-columns 列フィルターを適用します。 パブリッシャーはサーバー部門のコンシューマーからのリクエストを承認し、 Servers only 行フィルターと exclude-price-columns 列フィルターを適用します。 コンシューマーは、 Amazon Athena を使用して承認されたデータにアクセスします: サブスクリプションが承認された後、Amazon Athena でデータを参照し、ラップトップ部門のアナリストが Laptop の製品販売データのみにアクセスできます。 同様に、サーバー部門のアナリストは Server の製品販売データのみにアクセスできます。 両方のコンシューマーは、適用された列フィルターに従って、価格関連の列を除くすべての列を参照できます。 次の図は、ソリューションのアーキテクチャとプロセスフローを示しています。 前提条件 この記事に沿って進めるには、 Product Sales データアセットのパブリッシャーが、 Amazon DataZone でこのデータセットを公開している必要があります。 パブリッシャーによるアクセス制限用のアセットフィルターの作成 このセクションでは、パブリッシャーがアセットフィルターを作成するための手順を詳しく説明します。 行フィルターの作成 このデータセットには Laptops と Servers の製品カテゴリのデータが含まれています。したがって、製品カテゴリに応じてデータセットへのアクセスを制限することが必要です。この目的を達成するために、Amazon DataZone の行フィルター機能を使用します。 Amazon DataZone では、サブスクリプションを承認する際に適用できる行フィルターを作成できます。これにより、サブスクライバーがアクセスできるデータの行が、行フィルターで定義された範囲に制限されます。行フィルターを作成するには以下の手順を実行します。 Amazon DataZone コンソールで、 product-sales プロジェクト (アセットが所属するプロジェクト) に移動します。 プロジェクトの Data タブに移動します。 ナビゲーションペインで Inventory data を選択し、次に行フィルターを作成する Product Sales アセットを選択します。 AWS Glue テーブルまたは Amazon Redshift テーブルのタイプのアセットに対して行フィルターを追加できます。 アセットの詳細ページで、 Asset filters タブを選択し、 Add asset filter &nbsp;を選んでください。 Laptops カテゴリと Servers カテゴリの 2 つのカテゴリに対して、それぞれの行フィルターを作成します。 ラップトップのみのアセット行フィルターを作成するには、次の手順を完了してください。 このフィルターの名前を入力します ( Laptops only )。 このフィルターの説明を入力します ( Laptops only )。 フィルターの種類として Row filter を選択します。 行フィルター式として、1 つ以上の式を入力します。 column ドロップダウンメニューから Product Category を選択します。 operator ドロップダウンメニューから演算子 = を選択します。 Value フィールドに Laptops と入力します。 この例では 1 つの条件だけでフィルターを作成していますが、フィルター式に別の条件を追加する必要がある場合は、 Add condition を選択します。 行フィルター式に複数の条件がある場合は、 And または Or を選んで、それらの条件を組み合わせます。 サブスクライバーに対する値の可視性も設定できます。この記事では、デフォルト値 ( No, show values to subscriber ) のままにします。 Create asset filter を選択します。 同様の手順で Servers only という名前の行フィルターを作成します。 Value フィールドには&nbsp; Servers と入力します。 列フィルターの作成 次に、価格関連データを含む列へのアクセスを制限するための列フィルターを作成します。以下の手順を実行してください。 同じアセットに対して column filter タイプの別のアセットフィルターを追加します。 Asset filters タブで、 Add asset filter を選択します。 Name には、フィルターの名前 ( exclude-price-columns ) を入力します。 Description には、フィルターの説明 ( Exclude Price Columns ) を入力します。 フィルターのタイプとして Column を選択し、列フィルターを作成します。これにより、このデータアセットのすべての利用可能なものから適用する列を選択できます。 価格関連の列を除くすべての列を選択します。 Create asset filter を選択します。 コンシューマーによるデータ検出とサブスクリプションリクエスト このセクションでは、ラップトップ部門のアナリストの役割に切り替え、プロジェクト Sales Analytics - Laptop 内で作業します。データコンシューマーとして、データカタログを検索し、 Product Sales data アセットをサブスクライブしてデータを利用します。 プロジェクトにユーザーとしてログインし、 Product Sales データアセットを検索します。 Product Sales データアセットの詳細ページで、 Subscribe を選択します。 Project では、 Sales Analytics – Laptops を選択します。 Reason for request には、サブスクリプションを要求する理由を入力します。 Subscribe を選択して、サブスクリプションリクエストを送信します。 パブリッシャーがサブスクリプションフィルターを承認する サブスクリプションリクエストが送信されると、パブリッシャーはそのリクエストを受け取り、次の手順に従って承認できます。 パブリッシャーとしてプロジェクト Product-Sales を開きます。 Data タブで、左側のナビゲーションペインから Incoming requests を選択します。 リクエストを探し、 View request を選択します。 Pending でフィルタリングすると、まだ対応されていないリクエストのみを表示できます。 リクエストの詳細が表示され、誰が、どのプロジェクトのために、どういう理由でリクエストしたかなどの情報の詳細を確認できます。 リクエストを承認する際には 2 つのオプションがあります。 Full access – このオプションでサブスクリプションを承認すると、サブスクライバーはデータアセット全体にアクセスできるようになります。 Approve with row and column filters – 特定の行と列のみにアクセスを制限するには、このオプションを選択した上で、行と列のフィルターを適用して承認します。この記事では、前に作成した両方のフィルターを使用します。 Choose filter を選び、ドロップダウンメニューから Laptops only と exclude-price-columns &nbsp;を選択します。 Approve を選んでリクエストを承認します。 アクセスが許可され有効になると、サブスクリプションは次のスクリーンショットのように表示されます。 次に、サーバー部門のコンシューマーとしてログインします。 同じ手順を繰り返しますが、今回はサブスクリプションを承認する際に、 Choose filter では Servers only と exclude-price-columns を選択します。その他のステップは同じです。 コンシューマーが Amazon Athena を使用して認可されたデータにアクセスする ここまでの手順で、Amazon DataZone のデータカタログにアセットをパブリッシュし、サブスクライブできました。これを分析するために、ラップトップ担当のコンシューマーとしてログインします。 Amazon DataZone データポータルで、コンシューマープロジェクト Sales Analytics - Laptops を選択します。 Schema タブで、登録済みのアセットを確認できます。 プロジェクト Sales Analytics - Laptops を選択し、 Overview を選択します。 右側のペインで Amazon Athena を開きます。 サブスクライブしたテーブルに対してクエリを実行できるようになりました。 Tables and views の下にあるテーブルを選択し、 Preview を選んでクエリエディターで SELECT ステートメントを確認します。 このクエリを実行すると、 Sales Analytics - Laptops のコンシューマーが参照するデータには、プロダクトカテゴリが Laptops のデータしか含まれていないことが分かります。 Tables and views の中でテーブル product_sales を展開できます。この中に価格関連の列は表示されていません。 次に、サーバー部門のアナリストの視点で見てみましょう。同様の方法でデータセットを分析できます。 product_category では、 Servers のみが確認できます。 まとめ Amazon DataZone では、データアセットに対して細かな粒度のアクセス制御を簡単に設定できます。この機能を使えば、データコンシューマーにデータが提供される前に、行単位と列単位のフィルターを定義し、データプライバシーを強制できます。Amazon DataZone の細かな粒度のアクセス制御機能は、Amazon DataZone をサポートするすべての AWS リージョンで一般提供されています。 この機能を自身のユースケースで試した方は、コメント欄でフィードバックをお知らせください。 著者について Deepmala Agarwal は、AWS のデータ スペシャリスト ソリューションアーキテクトとして働いています。彼女は、お客様が AWS 上でスケーラブルかつ分散型のデータ駆動型ソリューションを構築するのを手助けすることに情熱を注いでいます。 仕事以外では、家族と過ごしたり、散歩をしたり、音楽を聴いたり、映画を観たり、料理をしたりすることが好きです！ Leonardo Gomez は、AWS のプリンシパル アナリティクス スペシャリスト ソリューションアーキテクトです。 10 年以上にわたるデータマネジメントの経験があり、世界中の顧客のビジネスおよび技術的ニーズに対応してきました。 LinkedIn &nbsp;で彼とつながることができます。 Utkarsh Mittal は、Amazon DataZone のシニア テクニカル プロダクトマネージャーを務めています。 顧客のアナリティクスジャーニー全体を簡素化するイノベーティブなプロダクトを作ることに情熱を注いでいます。 仕事を離れれば Utkarsh は音楽を演奏するのが趣味で、最近はドラムを始めたところです。 翻訳はパートナーソリューションアーキテクトの丸山 大輔が担当しました。原文は こちら です。

みなさん、こんにちは! いつものように AWS のニュースが満載の興味深い一週間でした。9 月に開催されたさまざまなイベントは満場で活気に満ちた方々にご参加いただきました。 まず、9 月16 日週に注目のリリースをいくつか取り上げてみましょう。 9 月16 日週の AWS ニュースの発表トップ 3 Amazon RDS for MySQL ゼロ ETL 統合が一般公開され、ワクワクするような新機能が追加されました。 &nbsp; これで、 AWS CloudFormation テンプレートでゼロ ETL 統合を設定できるようになりました。また、最大 5 つの Amazon Redshift ウェアハウスを備えたソースの Amazon RDS for MySQL データベースから複数の統合をセットアップできるようになりました。最後に、どのデータベースとテーブルが自動的にレプリケートされるかを決定するデータフィルターを適用できるようになりました。さらに詳しく知りたい場合は、 このリリースの特徴をレビューし、データフィルタリングを始める方法を紹介しているこちらのブログ記事 をご覧ください。ちなみに、このリリースは今週の別のリリースとの相性が良好です。 Amazon Redshift では、ゼロ ETL 統合を介してレプリケートされたテーブルのソートキーを変更できるようになりました 。 Oracle Database@AWS は、 Amazon Web Services (AWS) と Oracle の戦略的パートナーシップの一環として発表されました。このサービスにより、お客様は AWS 内で Oracle Autonomous Database と Oracle Exadata Database Service に直接アクセスできるようになり、エンタープライズワークロードのクラウド移行が簡単になります。主な機能には、リアルタイムのデータ分析のための Oracle と AWS サービス間のゼロ ETL 統合、セキュリティの強化、ハイブリッドクラウド環境のパフォーマンスの最適化などがあります。このコラボレーションは、マルチクラウドの柔軟性と効率性に対する高まる需要に対応します。年内にプレビュー版が提供され、2025 年には新しいリージョンへの展開に伴い、より幅広く利用できるようになります。 Amazon OpenSearch Service がバージョン 2.15 をサポートするようになり 、検索パフォーマンス、クエリの最適化、AI を活用したアプリケーション機能が向上しました。主なアップデートには、ベクトル空間クエリの放射状検索、ニューラルスパース検索とハイブリッド検索の最適化、既存のインデックスでベクトル検索とハイブリッド検索を有効にする機能が含まれます。さらに、毒性検出ガードレールや、取り込みパイプラインを強化するための ML 推論プロセッサなどの新機能も導入されています。このガイドを読んで、 Amazon OpenSearch Service ドメインをアップグレード する方法をご確認ください。 とてもシンプルだけどとても良い これらのリリースは本質的にシンプルですが、大きなインパクトがあります。 AWS Resource Access Manager (RAM) が AWS PrivateLink のサポートを開始 – 今回のリリースでは、トラフィックをパブリックインターネットに公開することなく、プライベート接続を使用して AWS アカウント間でリソースを安全に共有できるようになりました。この統合により、VPC エンドポイントを介した共有サービスへのより安全で効率的なアクセスが可能になり、ネットワークセキュリティが向上し、組織間でのリソース共有が簡素化されます。 AWS Network Firewall が AWS PrivateLink のサポートを開始 – セキュリティを素早く向上させられ、トラフィックをパブリックインターネットに公開することなく、ネットワークファイアウォールのリソースに安全にアクセスして管理できるようになりました。 AWS IAM アイデンティティセンターでは、ユーザーがエクスペリエンスをカスタマイズできるようになりました – 読みやすさを向上させ、目の疲れを軽減するダークモードなど、言語やビジュアルモードのプリファレンスを設定できます。今回の更新では 12 種類の言語がサポートされ、ユーザーはポータルから AWS リソースにアクセスする際に、よりパーソナライズされたエクスペリエンスが得られるように設定を調整できます。 その他 Amazon EventBridge Pipes がカスタマーマネージドの KMS キーのサポートを開始 – Amazon EventBridge Pipes では、サーバー側の暗号化用にカスタマーマネージドキーがサポートされるようになりました。今回の更新により、お客様は独自の AWS Key Management Service (KMS) キーを使用してソースとターゲット間の転送時にデータを暗号化できるようになり、機密イベントデータの制御とセキュリティが強化されます。この機能により、カスタム統合コードを必要とせずにポイントツーポイント統合のセキュリティが強化されます。 これを設定する方法については 、更新されたドキュメントを参照してください。 AWS Glue データカタログは、Apache Iceberg テーブルの拡張ストレージ最適化をサポートするようになりました – これには、不要なデータファイルの自動削除、孤立ファイル管理、スナップショットの保持が含まれます。これらの最適化により、テーブルを継続的に監視および圧縮することで、ストレージコストの削減とクエリのパフォーマンスの向上に役立ち、Amazon S3 に保存されている大規模なデータセットの管理が容易になります。 この新機能の詳細については 、このビッグデータブログ記事をご覧ください。 Amazon MSK Replicator では、同一のトピック名を維持したまま、クラスター間の Kafka トピックのレプリケーションがサポートされるように – これにより、クラスター間のレプリケーションプロセスが簡略化され、ユーザーはクライアントアプリケーションを再設定しなくてもリージョン間でデータをレプリケートできます。これにより、セットアップの複雑さが軽減され、マルチクラスターストリーミングアーキテクチャにおけるよりシームレスなフェイルオーバーが可能になります。。詳細については、この Amazon MSK Replicator デベロッパーガイド を参照してください。 Amazon SageMaker、推論用のスティッキーセッションルーティングを導入 – これにより、セッションの間、同じクライアントからのリクエストを同じモデルインスタンスに送信できるため、特にセッションベースのやり取りが重要なチャットボットやレコメンデーションシステムなどのリアルタイム推論シナリオで、一貫性が向上し、レイテンシーが削減されます。 設定方法については 、このドキュメントガイドをご覧ください。 イベント AWS GenAI Lofts は世界中で次々と登場しています。 今週、サンフランシスコのデベロッパーは、 サンフランシスコの AWS Gen AI Loft で開催された 2 つの非常にエキサイティングなイベントに参加する機会を得ました。その中には、先週の火曜日の「Generative AI on AWS」ミートアップがあり、拡張現実、将来の AI ツールなどについての議論が行われました。その後、木曜日には Amazon Bedrock で駆動する MineCraft ボットのデモンストレーションと AI ビデオゲームのバトルで盛り上がりました。 10 月 19 日より前にサンフランシスコ周辺にいる場合は、 スケジュールをチェックして 、参加できるイベントのリストに目を通しましょう。 最近オープンした ブラジルのサンパウロ AWS GenAI Loft と、 9 月 30 日にオープンするロンドンの AWS GenAI Loft をぜひチェックしてください。イベントの席がなくなる前に登録を始めることができます。例えば、「 The future of development 」と呼ばれるイベントでは、デベロッパーがスキルを向上させることにターゲットを絞った内容を 1 日中学ぶことができます。 AWS コミュニティも、素晴らしいイベントの開催に大忙しです。 AWS Community Day ベルファストで講演者になれたことを光栄に思います。そこで、北アイルランドで盛り上がっているこの素晴らしいコミュニティの主催者の皆様にようやく会うことができました。Community Day に行ったことがない方は、ぜひチェックしてみることをおすすめします。 周りの笑顔は言うまでもなく、Matt Coulter、Kristi Perreault、Matthew Wilson、Chloe McAteer などのコミュニティリーダーとそのコミュニティメンバーからの献身と情熱に元気づけられるはずです。 認定資格 AWS 認定試験の受験を延期しているなら、今が絶好の機会です。 2024 年 12 月 12 日までに AWS 認定: Associate Challenge に無料で登録すると、AWS 認定ソリューションアーキテクト – アソシエイト、AWS 認定デベロッパー – アソシエイト、AWS 認定システムオペレーションアドミニストレーター – アソシエイト、または AWS 認定データエンジニア – アソシエイトのいずれかの試験を受験できる 50% 割引バウチャーを獲得できます。同僚の Jenna Seybold が、 各試験の学習教材のコレクションを投稿しています。 興味があればチェックしてみてください。 また、新しい AWS 認定 AI プラクティショナー試験 が受験できるようになりました。ベータ段階ですが、すでに受験できます。2025 年 2 月 15 日までに合格すると、 アーリーアダプターバッジ がもらえ、コレクションに追加できます。 まとめ 今週のニュースを楽しんでいただけたら幸いです。 これからもがんばってください! 原文は こちら です。

本ブログは、鴻池運輸株式会社と Amazon Web Services Japan が共同で執筆しました。 鴻池運輸株式会社 (以下、鴻池運輸 )は、物流、製造、医療、空港業務など幅広いサービスを提供しています。グループ全体で約24,000名の従業員が所属し、国内外に多数の拠点を持っています。主な業務には製造業・サービス業の請負業務、国際・国内物流、定温物流、エンジニアリング業務などがあり、さらに最新技術の導入や労働負荷軽減の取り組みも積極的に行っています。 課題： 鴻池運輸では各拠点ごとに業種や業務内容が大きく異なっており、拠点別に課題解決のために用いた考え方や新しいソリューション、また自動化・省力化機器などの検証結果、費用対効果などの社内ナレッジが各拠点ごとに蓄積されていました。 2022年9月にそうした個別のナレッジを全社データベース化したものの、社内ナレッジは自然言語で記載された非構造化データとなっており、類似する業務に対する社内ナレッジへのアクセスが、通常の検索機能ではマッチングしづらく、ナレッジの共通知化がなかなか進まないという課題がありました。 具体的には、拠点ごとに得たい情報目的が少しずつ異なっていたり、同じ作業でも作業の名称や作業機器、作業場所の呼び方が違ったり、拠点名自体の表記ゆれが発生するいうこともありました。加えてナレッジデータは拠点の担当者ごとに記載するため、粒度やフォーマットがばらばらになってしまうという問題もありました 取り組み： このような課題を解決するため、鴻池運輸ではAWSのサービスを活用したRAGチャットアプリケーションを開発しました。アーキテクチャ図を以下に掲載します。 RAGアプリケーション アーキテクチャ図 主な処理は以下のようになります。 前処理： 社内ナレッジデータの記載粒度を整える 記載粒度を整えた社内ナレッジデータを Amazon Simple Storage Service (S3) にアップロード S3 に保存されたデータを Amazon Aurora (Aurora) に項目ごとに保管 検索処理： RAGチャットアプリケーションから検索を実行 Amazon Bedrock (Bedrock)を利用して検索クエリを補正 Amazon Kendra (Kendra) で対象ファイルを自然言語で検索 Kendra から返却された DocumentID を抽出 抽出された DocumentID を元に、Aurora から該当する&nbsp;DocumentID の全項目を返却 ( Kendra からの返却情報では粒度が不足するため、全項目を別途取得する ) フォーマット処理： Aurora から返却された情報をコンテキストに追加 Bedrock を利用して指定したフォーマット文章を返却 (&nbsp;データソースのリンクを含む ) 検証方法と結果： 結果の検証については、手動で確認しました。比較内容としては出力表記とソースリンクを確認し、ソースと出力内容の内容が一致しているかを確認するという方法を用いました。比較対象としては、 「返却された文章」および「データソースのリンク」と「S3 内に保管された文章」の 3 点としました。 そして合格条件として、以下の 1. が90%以上の確率で返却されることとしました。 データソースが正しく、文章の記載内容も正しい データソースが正しいが、文章の記載内容に不備がある データソースが誤っているが、文章の記載内容が正しい どちらにも不備がある 検証結果として対象100件のうち、95件が合格。つまり「ハルシネーションが発生しない返答」という良好な結果を得られました。 その結果を踏まえてシステムの社内リリースを実施、直近 7 月のデータベースへの検索アクセス実績は従来の8倍近くに及んでいます。 数件のハルシネーションが発生したものの、ユーザー側の自然言語による検索の工夫でカバーてきていると考えており、利便性は大幅に向上したと考えています。 鴻池運輸の技術革新本部長である菅沼常務からは 「 今回のアップデートにより、アクセスし易さや検索機能が向上し、利用者の評価もアップしています 。また AWS 様のサービスを活用することでセキュリティも強化され、安心して利用できるシステムになりました。今後はグループ全体でこのシステムを利用してもらい、社内にある技術を活用して新たな価値を産み出せるような組織に変革していきたいと考えています。」 というコメントをいただきました。 今回の開発チームの構成として、WEB アプリケーションのフロントエンド / バックエンド開発者数名とプロンプトエンジニアリングを含む Bedrock の開発者 1 名になります 。少人数のチームではありましたが、エンジニアチームと現場ナレッジ側のデータ記載粒度の統一作業も並行してスムーズに実施できたため、着手から僅か4 か月で本番実装することができました。社内初となる生成 AI を用いたサービスを展開した結果、生成 AI そのものが社内でも広く認知されるようになり、また早くも別の生成AI アイデアが挙がってくるという副次的な効果も発生しています。 今後の展望： 目指す部分 : 今回の生成 AI を用いた RAG チャットアプリケーションの導入では多くの反応がありました。例えば別々の拠点間での導入サービス横展開の案件などです 。これらの対応を通じて社内ナレッジの活用を推進、課題解決のための効率化を図り、本業においてもより高品質なサービスをお客様へ提供してまいります。 具体的な対応 : そのための直近の展開としては、以下のような対応を予定しています。 ユーザーの入力内容 (ユーザープロンプト) の分析 : &nbsp;ユーザープロンプトの内容からユーザーが抱える課題や要望を分析し、業務改善部門から該当拠点へのアプローチを容易にしていきます 。分析方法に関してはクラスタリング分析を想定しており、 Amazon SageMaker を利用することで効率的に実施できると考えています。 RAG アプリケーションの応用展開 : &nbsp;今回の RAG チャットアプリケーションを他業務へ展開することによって業務効率向上を図ります 。対象としては「社内ヘルプデスク」や「各部門の FAQ」、「安全品質にかかわる社内周知」といった業務を検討しています。 まとめ： 今回の開発では、Amazon Bedrock と AWS Kendra を活用した RAG ソリューションによって社内情報の暗黙知を共通知化することができました。鴻池運輸では今後も AWS の先進的なテクノロジーを活用し、こうした活動を通じてより高品質なサービスをお客様に提供していく考えです。 ソリューションアーキテクト 伊藤 一成

2024 年 7 月 11 日（木）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #5（2024 年 7 月 11 日開催） AWS Media Services を用いて クラウドマスターの現状・未来について検討してみた 朝日放送テレビ株式会社 技術局 放送技術センター 放送実施グループ 渡辺 雄介 氏　宮川 陸 氏 放送局には、放送番組及びＣＭ等を放送時間に合わせて順番どおりに誤りなく送信設備へ送出する「マスターシステム」と呼ばれるシステムが存在します。経営および BCP の観点から、クラウドを用いたマスターシステムの構築を検討する動きが一部の放送局で始まっていることを受け、朝日放送テレビ（ABCTV）でもクラウドに関する知見を高めるべく定期的に社内勉強会を実施しています。メディア/配信サービスが充実している AWS を用いて簡易的なマスターシステムを実装することで、クラウドで実現できることと課題、その双方の確認を行いました。 今回構築した検証環境では、&nbsp; AWS Elemental MediaLive が持つスケジュール機能や AWS Lambda など用いて、マスターシステムの中枢機能である、 APS 機能を実現しました。例えば、APS データの投入と差し替え、Q テイク/カットイン制御、局ロゴや速報スーパーの重畳などの機能です。また、AWS 上で処理されたこれらの映像信号が、オンプレミス上の OFDM 変調器を通してテレビ受像機で再生できることも確認しました。その一方で、主に Web 配信で用いられる AWS Media Services でシステムを構築した場合には、エンコード遅延や伝送遅延の影響を受けること、映像信号同士の同期方法を検討する必要があること、実現したい機能によっては AWS Media Services だけを利用するのではなく、 Amazon EC2 上で動くソリューションの検討も必要であることなどが課題として浮き彫りになりました。 この勉強会では、複数の放送局で1つのマスターシステムを持つ場合の検討も行いました。1つのリージョンに映像信号を集約、送出バンクなども複数局で共用化することで、運用効率やコスト効率を上げられるのでないか、また複数のリージョンを併用することで可用性を担保し、DR 構成を実現できるのではないか、などの意見が勉強会の中で挙がりました。また、マスターシステムをより効率化するという当初の目的を達成するためには、今あるマスターシステムをそのままクラウドに移行するのではなく、必要な場合のみ必要なリソースを使用できるようにしたり、共通化できる設備や運用を極力共通化するなど、従来の考え方の大幅なアップデートが必要であるとの意見も挙がりました。 ABCTV では、今年度もこの勉強会を継続しています。 AWS Deadline Cloud でクラウドレンダリングしてみた 株式会社毎日放送 総合技術局 制作技術センター 村井 亨 氏 CG レンダリング とは、3DCG ソフトで作成した CG 素材を、計算によって 2D の映像に描画する作業です。CG 素材の作成や修正を素早く行うためには、複数のサーバで構成されたレンダリングファームを活用するなどして、レンダリングスピードを向上させることが重要です。毎日放送（MBS）では従来のオンプレミス環境に代わって、2022年から AWS Thinkbox Deadline を用いた レンダリング環境を構築 しています。AWS Thinkbox Deadline を用いることで、必要なときに必要な分だけコンピュートリソースを確保できるようになり、 スポットインスタンス を用いた使用料の削減、ハードウェア更新の負荷軽減などの効果がありました。一方で、オンプレミスの管理サーバが依然必要であったこと、レンダリングサーバの起動や終了が作業負荷として残るなどの課題もありました。 そこで MBS では、2024年4月に提供が始まった AWS Deadline Cloud を用いたレンダリング環境のオールクラウド化にいち早くチャレンジしています。AWS Deadline Cloud は、クリエイティブチームが数分でレンダーファームを簡単に設定し、より多くのプロジェクトを並行して実行できるようにスケールしながら、使用したリソースについての料金のみを支払うことを可能にする 新しいフルマネージドサービス で、レンダーファームの作成と管理、進行中のレンダーのプレビュー、レンダーログの表示と分析、およびこれらのコストの簡単な追跡を行う機能を備えたウェブベースのポータルを提供します。管理サーバが不要、かつレンダリングサーバの管理も不要となるため、現在使用している AWS Thinkbox Deadline よりもさらに運用負荷を軽減できるのではないかと MBS では期待をしています。 実際に AWS 上に検証環境を構築しテスト運用を実施したところ、CG デザイナーからは「レンダリングサーバの管理から解放された」「操作感に問題はない」「費用を可視化できるようになり嬉しい」との感想が寄せられました。またシステム管理者からは「簡単に環境が構築できるようになった」「ライセンスの購入が AWS に一元化されて支払いが楽になった」「ポート番号の管理が簡単になった」などの感想がありました。 現状の AWS Thinkbox Deadline を用いたレンダリング環境と比べて費用削減効果も期待できることから、MBS では AWS Deadline Cloud への移行を今後進めていく予定です。 中京テレビ版「データ基盤」の構築について 中京テレビ放送株式会社 技術DX 推進局 ICT 推進グループ 山本 卓也 氏 中京テレビ（CTV）では、社内の全ての人が、必要なときに、必要なデータにアクセスできる環境を実現するため、これまで個別管理されていた社内のデータを一元管理すべく、AWS 上にデータ基盤を構築しました。 このデータ基盤は様々なデータを扱いますが、「データソース」は Amazon RDS &nbsp;など様々です。データ連携をすることが難しく、Web からダウンロードするしか手段が無いものや、PDF データなどは、RPA ツールやローコードツールを活用したり、名寄せ用の簡易アプリケーションを作成したりして、データ基盤にデータを取り込んでいます。例えば同じ番組であっても動画配信プラットフォームによって 番組 ID が異なるため、共通の ID を付与して名寄せを行う作業などが必要でした。 次に AWS に取り込まれたデータは、 AWS Glue 、 Amazon S3 、 AWS Step Functions &nbsp;などを介して ETL 処理が行われます。Amazon S3 にデータがアップロードされた場合には、Amazon S3 イベント通知をトリガーに複数のサービスを経由して、Amazon RDS がデータソースであった場合には、 AWS Database Migration Service（AWS DMS） を経由して&nbsp; Amazon Redshift &nbsp;にデータが登録されます。 「マート化・可視化」においては、 Amazon Redshift の肥大化を防ぐために一部のデータを Amazon Athena を用いて直接クエリしたり、生データではなく AWS Glue で集計したあとのデータを&nbsp;Amazon Redshift に入れるなどの工夫を行い、 Amazon QuickSight でデータの可視化を行いました。 また「データ品質管理」では、各テーブルの監視周期を登録し、最新のデータが取り込まれているかその周期ごとに確認する仕組みを入れたり、 Amazon CloudWatch で当該のメトリクスを監視することで、データソース監視者がすぐに異常に気づける仕組みを構築しました。 このデータ分析基盤は複数名でチーム開発しているため、適切な権限付与やアクセス管理が重要でした。 Control Tower 導入時 に有効化した &nbsp;IAM Identity Center を用いて、チームメンバーに対して適切な権限付与を行い、データソースとデータ基盤の AWS アカウントは分離しました。また Amazon QuickSight には社内の様々な部署の利用者がアクセスするため、複数作成したロールと共有フォルダとを紐づけて、必要なダッシュボードだけを利用者が見れるようにしました。 今後は Amazon QuickSight の社内利用の推進と Amazon Q in QuickSight の機能調査を行う予定です。 &nbsp;クラウド編集の取り組み 讀賣テレビ放送株式会社 技術局 技術開発部 西村 聡 氏 讀賣テレビ（ytv）では、場所に制限されずに作業が可能となるなどの利便性の向上、メンテナンス費や設備更新等に関するコストの削減、物理メディアの持ち運びをすることなく素材の受け渡しを実現するためなどの理由から、クラウド編集環境の構築に取り組んでいます。AWS が提供するコンピュートサービス内で任意の編集ソフトウェアを実行することでクラウド編集環境を実現することができ、ytv ではソフトウェアの実行環境として AWS のフルマネージド VDI サービスである Amazon Workspaces を採用しています。 従来のオンプレミス編集環境と AWS 上のクラウド編集環境との間は、ストレージサービスを介して常に素材の共有と同期が行われているため、オンプレミス上で行なった編集作業の続きを、例えばロケ先などから Amazon Workspaces に接続し、クラウド上で継続して行うことが可能です。ytv では実際に「鳥人間コンテスト2024」における VTR の準備や本編の編集でこのクラウド編集環境を活用しています。また Amazon Workspaces のスケジュールツールを自社で開発中で、社内の UI からクラウド編集環境を簡単に立ち上げられるだけでなく、将来的には社内の他のシステムと連動してクラウド編集環境の構築を自動化することも検討しています。 現在行なっているチャレンジはもう1つあります。AWS が提供するフルマネージド型のエンドユーザーコンピューティング (EUC) サービスである Amazon AppStream 2.0 を用いたクラウド編集環境の構築です。Amazon AppStream 2.0 は非永続的なストリーミングインスタンスであることから、ユーザが接続する度に新たな環境が立ち上がるという特徴があり、Amazon Workspaces で実現できていたライセンス認証などの処理に一工夫加える必要が生じます。その一方で&nbsp;Amazon Workspaces よりもインスタンスタイプが多く、かつ ytv の利用形態では料金が大幅（4分の1）に下がるというメリットもあります。現在、Amazon AppStream 2.0 上で EDIUS 9 が動作するところまでは実現できており、&nbsp;EDIUS X 以降のバージョンについてもソフトウェアの対応状況を見ながらチャレンジしたいと考えています。 なお、クラウド編集環境を簡単にデプロイ可能な Edit in the Cloud on AWS と呼ばれるソリューションを AWS では提供しています。ぜひこちらもお試しください。 &nbsp;まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

2024 年 10 月 28 日より、新規のお客様は新しい Amazon FSx File Gateway (FSx File Gateway) を作成できなくなります。このサービスを利用したい場合は、2024 年 10 月 28 日までに FSx File Gateway を作成してください。FSx File Gateway の使用を開始するには、AWS マネジメントコンソールの Storage Gateway コンソールに移動してください。 この変更は既存のお客様には影響しません。AWS は FSx File Gateway のセキュリティと可用性に引き続き投資しています。FSx File Gateway のセキュリティアップデートは引き続きリリースしていきます。また、FSx File Gateway に関するご質問については、AWS サポートに引き続きご相談ください。 FSx File Gateway は AWS Storage Gateway の一種で、ローカルキャッシュはオンプレミスに配置するように設計されています。FSx File Gateway は、 Amazon FSx for Windows File Server (FSx for Windows File Server) のフルマネージドファイル共有へのオンプレミスアクセスを最適化します。SMB ファイル共有にファイルデータがあるお客様は、低レイテンシーの要件を満たすためにオンプレミスでのアクセスを必要とすることがあります。最近は、ネットワーク帯域幅コストの削減と帯域幅の可用性の向上に伴い、多くのお客様が、ゲートウェイやローカルキャッシュを必要とせずに、オンプレミスからクラウドの FSx for Windows File Server を使用できるようになりました。それでもなお、より高速なアクセスを必要とするローカルキャッシュのニーズのある利用者は、 Amazon FSx for NetApp ONTAP (FSx for ONTAP) とその キャッシュ技術 を利用することが検討できます。 この記事では、既存のお客様が SMB ファイル共有アクセスを FSx File Gateway から FSx for Windows File Server に切り替える方法について説明します。また、接続の問題が発生した場合に考慮すべきネットワーク構成や、FSx for Windows File Server の使用が選択肢に入らない場合の代替ソリューションについても説明します。FSx for Windows File Server に切り替えることで、FSx File Gateway のコストを削減し、ファイルがすでに FSx for Windows File Server に保存されているためデータ移行の必要がなくなり、アーキテクチャと運用上のオーバーヘッドを簡素化することができます。 FSx File Gateway 共有を FSx for Windows File Server 共有に切り替える 推奨されるアプローチは、FSx File Gateway をアーキテクチャから削除し、FSx for Windows File Server を直接使用し続けるというものです。クライアントを FSx for Windows File Server に直接接続をすると、ほとんどのワークロードのニーズを満たすことができます。SMB がクライアントマシンでローカルキャッシュを提供するためです。これを行うには、クライアントをローカル FSx File Gateway から切断し、それらのクライアントを FSx for Windows File Server のファイル共有にマッピングします。 現在のセットアップを理解する 移行プロセスに着手する前に、FSx File Gateway の典型的なセットアップを簡単に確認しておきましょう。 オンプレミスに展開された FSx File Gateway アプライアンスが、AWS のFSx for Windows File Serverファイルシステムに接続します。 すべての Windows クライアントは、ローカルの FSx File Gateway アプライアンスに接続します。 FSx File Gateway アプライアンスと FSx for Windows File Server ファイルシステムは同じ Active Directory ドメインに属し、両者の間はプライベートネットワーク接続 (例えば、 AWS Direct Connect または AWS VPN ) で接続されています。 クライアントからファイル共有へのネットワーク経路が必要です。 これについては、この記事の「ネットワークに関する考慮事項」のセクションで詳しく説明します。 FSx File Gateway を環境から削除し、クライアントを FSx for Windows File Server に接続する手順 FSx File Gateway からクライアントを切断 : まず、すべての Windows クライアントをローカルの&nbsp;FSx File Gateway アプライアンスから切断します。 ゲートウェイのキャッシュをフラッシュ :&nbsp; FSx File Gateway がローカルキャッシュのすべてのデータを FSx for Windows File Server ファイルシステムにアップロードするまで待ちます。キャッシュが完全にフラッシュされたことを確認するには、CachePercentDirty メトリックが 0.0% に達するまで監視します。 FSx for Windows File Server ファイルシステムを切り離す (オプション) :&nbsp; キャッシュがフラッシュされたら、Storage Gateway コンソールで FSx for Windows File Server ファイルシステムを切り離します。 オンプレミス環境の FSx File Gateway の電源を切る :&nbsp; ファイルシステムを切り離した後、オンプレミス環境の FSx File Gateway アプライアンスの電源を切ります。 Windows クライアントを FSx for Windows File Server ファイル共有に接続 :&nbsp; Windows クライアントを FSx for Windows File Server のファイル共有に直接接続するように設定します。この移行中、すべてのデータ、権限、その他の設定は保持されます。オンプレミス環境から FSx for Windows File Server データにアクセスする方法の詳細については、 FSx for Windows File Server ユーザーガイド を参照してください。 AWS Storage Gateway コンソールで FSx File Gateway を削除 (オプション) :&nbsp; Gateway の削除手順については、 FSx File Gateway ユーザーガイド の手順に従います。 ネットワークに関する考慮事項 多くの場合、ネットワークファイアウォールルールを変更する必要はありません。ただし、FSx File Gateway VM から FSx for Windows File Server への接続を SMB (445 番ポート) トラフィックのみに制限している場合は例外です。この場合、クライアントが存在するローカルサブネットが FSx for Windows File Server ファイル共有にアクセスできるように、ファイアウォールルールを調整する必要があります。 AWS へのネットワーク接続の種類によって、クライアントを FSx for Windows File Server ファイルシステムに直接接続できるかどうかを判断できます。FSx File Gateway のローカルキャッシュは通常、クラウドからのダウンロードデータ量を削減しますが、FSx File Gateway を削除すると、AWS から外部へのデータ転送コストが増加する可能性があることに注意してください。一方で、AWS から外部へのデータ転送コストは、FSx File Gateway を削除することによるコスト削減によって相殺されることが期待できます。 代替案 FSx for Windows File Server のファイル共有にクライアントを直接マッピングすることができない場合、帯域幅の不足やユーザーエクスペリエンスへの悪影響など、さまざまな理由が考えられます。そのような場合には、別の選択肢があります。 FSx for ONTAPは、NetApp ONTAP の一般的なデータアクセスと管理機能を備えた、AWS で完全に管理されたスケーラブルで高性能な共有ファイルストレージを提供します。FSx for ONTAP は、標準の Windows SMB サポートとデータ保護に加え、マルチプロトコルアクセス (NFS、SMB、iSCSI、NVMe-over-TCP プロトコル)、自動ストレージ拡張、階層化などの追加機能も提供します。 お客様は FSx for ONTAP を活用して、ローカルキャッシュソリューションを提供できます。このソリューションには、オンプレミスの NetApp の設置と、FSx for Windows File Server から FSx for ONTAP へのデータ移行が必要です。FSx for ONTAP への移行には、 AWS DataSync の使用をお勧めします。このアプローチでも、追加の構成、計画、実装の手順が必要です。 まとめ このブログでは、2024 年 10 月 28 日より、新規のお客様は新しい&nbsp; Amazon FSx File Gateway を作成できなくなることをお知らせしました。また、既存の FSx File Gateway のお客様が、SMBファイル共有アクセスを FSx File Gateway から FSx for Windows File Server に切り替える際の推奨アプローチについて概説しました。さらに、問題が発生した場合に考慮すべきネットワーク構成や、ローカルキャッシュが必要な場合の代替ソリューションについても説明しました。FSx for Windows File Server に切り替えることで、高可用性が実現し、FSx File Gateway のコストが不要になり、データ移行の必要がなくなり、アーキテクチャと運用上のオーバーヘッドが簡素化されます。また、既存のお客様は FSx for ONTAP の方がニーズに適していると感じるかもしれません。 さらにご質問がある場合は、Amazon FSx for Windows File Server の よくある質問 (FAQ) をご覧ください。 このブログは 2024 年 9 月 26 日に Ed Laura (Senior Product Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 <!-- '"` --> Ed Laura Ed Laura は、AWS Storage Gateway や AWS DataSync を含む AWS Edge Data Services を担当するシニア・プロダクト・ソリューション・アーキテクトです。 彼は、AWS を活用してハイブリッドストレージの課題を克服するお客様を支援することに情熱を注いでいます。 ヘルスケア、ライフサイエンス、金融サービス、メディアおよびエンターテイメント、製造など、さまざまな業界におけるインフラソリューションアーキテクチャの分野で15年以上の経験があります。 余暇には、ホッケー、アウトドアでの冒険、自転車、2匹の愛犬とのハイキングを楽しんでいます。

本稿は、2024年7月31日に AWS DevOps Blog で公開された “ Balance deployment speed and stability with DORA metrics ” を翻訳したものです。 開発チームは、ソフトウェア配信の速度と品質を高めるため、DevOps 実践を導入しています。 DevOps Research and Assessment (DORA) メトリクスは、その目的の進捗状況を測る一般的な方法です。4 つの主要なメトリクスを使って、シニアリーダーはチームの成熟度の現状を評価し、最適化する領域に取り組むことができます。 このブログ記事では、Amazon Web Services (AWS) 環境で DORA メトリクスを活用する方法を説明します。 AWS アカウントでメトリクス収集を自動的に開始できるサンプルソリューションを共有します。 DORA メトリクスを収集する利点 DORA メトリクスは、デプロイの速度と安定性の定性的側面を測定することで、開発チームのパフォーマンスと能力を把握するのに役立ちます。また、障害からの平均復旧時間を測定することで、チームの適応能力を示します。これにより、プロダクトオーナーは作業の優先順位を決定し、チームの成熟度を透明化し、現実的な作業負荷のスケジュールを立てることができます。メトリクスは経営陣とのコミュニケーションにも適しています。経営陣の支援を得て、チームの満足度とユーザーエクスペリエンスを阻害している根本的な問題を解決することができます。 ユースケース このソリューションが適用できるユースケース: 開発チームは、CI/CD ツールがホストされている ツールアカウントと、ログの集約および可視化のためのオペレーションアカウントを含む、マルチアカウントの AWS セットアップがあります。 開発者は GitHub のコードリポジトリと AWS CodePipeline を使用して、コード変更をアプリケーション環境アカウントに適用しています。 ツール、オペレーション、アプリケーション環境アカウントは、AWS Control Tower の メンバーアカウント または、 Landing Zone Accelerator on AWS ソリューションのワークロードアカウントです。 システム変更に起因するサービスの障害は、 AWS Systems Manager OpsCenter の OpsItem としてログに記録されます。 ソリューションの概要 DORA の 4 つの主要メトリクス 「4 つのキー」は、チームの実績と問題への対応力を測定します: “デプロイ頻度” はプロダクション環境で変更リリースが成功する頻度を示します。 “変更リードタイム” はコミットされたコードがプロダクション環境に到達するまでの平均時間を示します。 “変更失敗率” はプロダクション環境における変更がサービスインシデント/障害につながる頻度を示し、平均故障間隔時間の補完的な指標です。 “平均復旧時間” はサービス中断からフル復旧までの平均時間を示します。 最初の 2 つのメトリクスはデプロイの速度に焦点を当てていますが、他の 2 つはデプロイの安定性を示しています (図 1)。組織がサービスの重要性と顧客のニーズに基づいて独自の目標 (つまり DORA メトリクスのターゲット) を設定することをお勧めします。従来の DORA ベンチマークデータと、それが開発チームのパフォーマンスについて何を示しているかの議論については、 DORA メトリクスが性能を測定および改善する方法 を参照してください。 図 1. DORA メトリクスの概要 デプロイ速度と安定性のバランスを取るための DORA メトリクスの計算ロジックの詳細については、GitHub コードリポジトリ Balance deployment speed and stability with DORA metrics を参照してください。このロジックに変更を加える場合は、十分に注意して行ってください。 たとえば、変更障害率はプロダクション環境を損なう変更に焦点を当てています。プルリクエストのタグ (ホットフィックスなど) に計算を限定すると、ビルドプロセスに関連する問題が除外されます。実際にプロダクション環境で障害が発生するようなシステム変更記録を一致させることが重要です。デプロイパイプラインから失敗したデプロイの数に計算を限定すると、プロダクション環境に到達しなかったデプロイだけが考慮されます。変更関連の障害については、CI/CD ツールからのデータに依存するのではなく、AWS Systems Manager OpsCenter を記録システムとして使用しています。 同様に 平均復旧時間 は、プロダクション環境でのサービス障害が発生してからパイプラインが正常に実行されるまでの期間を測定します。パイプラインの障害が頻発する場合、ローカルでのテストが不十分であったり、パイプライン自体に問題がある可能性があるため、チームではパイプラインのステータスと復旧時間の両方を追跡することをお勧めします。 DORA イベントの収集 メトリクスの計算プロセスは 4 つのステップで実行されます: ツールアカウントでは、CodePipeline からイベントを Amazon EventBridge のデフォルトのイベントバスに送信します。 イベントはカスタムイベントバスに転送され、定義されたメトリクスと設定したフィルタに従って処理されます。 カスタムイベントバスは、 AWS Lambda 関数をコールし、メトリクスデータを Amazon CloudWatch に転送します。CloudWatch では、各メトリクスの集約ビューが表示されます。Amazon CloudWatch からは、 Amazon Managed Grafana などの指定したダッシュボードにメトリクスを送信できます。 データ収集の一環として、Lambda 関数はリードタイム変更メトリクスを計算するための関連コミットを GitHub から照会します。変更失敗率とリカバリ平均時間のメトリクスについては、AWS Systems Manager から OpsItem データを照会します。変更管理プロセスの一部として OpsItem を手動で作成するか、 CloudWatch アラームを設定 して OpsItem を自動的に作成できます。 図 2 は、これらのステップを視覚化したものです。この設定は、1 つまたは複数のチームのアカウントグループに複製できます。 図 2. AWS CodePipeline デプロイ用の DORA メトリクス設定 構築手順 次の手順に従って、ご利用の AWS アカウントにこのソリューションをデプロイしてください。 前提条件 この構築手順を実行するには、以下の前提条件を満たす必要があります。 ツール、オペレーション、アプリケーション環境用の AWS アカウント Python バージョン 3.9 以降をインストール AWS Cloud Development Kit (AWS CDK) v2 を インストール AWS CDK パイプラインを設定 AWS CodePipeline、AWS Systems Manager OpsCenter、GitHub へのアクセス権がある ソリューションのデプロイ GitHub のコードリポジトリ Balance deployment speed and stability with DORA metrics を Clone してください。 この codebase をデプロイしたり作業する前に、cdk/ ディレクトリにある constants.py ファイルで設定する必要がある項目がいくつかあります。IDE でこのファイルを開き、次の定数を更新してください: TOOLING_ACCOUNT_ID と TOOLING_ACCOUNT_REGION : これらは、AWS CodePipeline (ツール) の AWS アカウント ID と AWS リージョンを表します。 OPS_ACCOUNT_ID と OPS_ACCOUNT_REGION : これらはオペレーションアカウント用です (一元化されたログ集約とダッシュボードに使用されます)。 TOOLING_CROSS_ACCOUNT_LAMBDA_ROLE : クロスアカウントアクセスを許可し、ツールアカウントからオペレーションアカウント/Amazon CloudWatch ダッシュボードへのメトリクス投稿を可能にする AWS Lambda の IAM ロールです。 DEFAULT_MAIN_BRANCH : これは、プロダクション環境へのデプロイに使用されるコードリポジトリのデフォルトブランチです。デフォルトでは “main” に設定されています。これは、メインブランチで機能駆動型開発 (GitFlow) を想定しているためです。別の命名規則を使用する場合は、更新してください。 APP_PROD_STAGE_NAME : これは、プロダクション環境の名前で、デフォルトでは “DeployPROD” に設定されています。トランクベースの開発を行うチームのために予約されています。 環境の設定 macOS と Linux で環境をセットアップするには: 仮想環境を作成します: $ python3 -m venv .venv 仮想環境を有効にします: macOS と Linux の場合: $ source .venv/bin/activate 代替案として、Windows 上で環境をセットアップするには: 仮想環境を作成します: % .venv\Scripts\activate.bat 必要な Python パッケージをインストールします: $ pip install -r requirements.txt AWS コマンドライン インターフェイス (AWS CLI) を設定するには: AWS CLI ユーザーガイド の設定手順に従ってください。 $ aws configure sso ユーザープロファイル (オペレーションアカウントの場合は Ops、ツールアカウントの場合は Tooling など) を設定します。ユーザープロファイル名は認証情報ファイルで確認できます。 CloudFormation スタックのデプロイ ディレクトリを切り替えます $ cd cdk CDK を Bootstrap します $ cdk bootstrap –-profile Ops このプロジェクトの AWS CloudFormation テンプレートを合成します: $ cdk synth 特定のスタックをデプロイするには (概要は図 3 を参照)、次のコマンドでスタック名と AWS アカウント番号を指定してください: $ cdk deploy --profile { Tooling, Ops } ツールアカウントで DoraToolingEventBridgeStack スタックを起動するには: $ cdk deploy DoraToolingEventBridgeStack --profile Tooling Operations アカウントで他のスタック (DoraOpsGitHubLogsStack、DoraOpsDeploymentFrequencyStack、DoraOpsLeadTimeForChangeStack、DoraOpsChangeFailureRateStack、DoraOpsMeanTimeToRestoreStack、DoraOpsMetricsDashboardStack を含む) を起動するには: $ cdk deploy DoraOps * --profile Ops 次の図は、各 CloudFormation スタックで起動するリソースを示しています。これにはオペレーション アカウントの 6 つの AWS CloudFormation スタック が含まれます。最初のスタックは GitHub のコミット活動のログ統合をセットアップします。4 つのスタックには、DORA メトリクスの 1 つを作成する Lambda 関数が含まれています。6 番目のスタックは、Amazon CloudWatch で統合ダッシュボードを作成します。 図 3. このソリューションでプロビジョニングされるリソース デプロイのテスト 以下の手順でテストを実行してください: $ pytest 構築したものの確認 ツールアカウントへデプロイされたリソース DoraToolingEventBridgeStack には、オペレーションアカウントの中央イベントバスをターゲットとしている Amazon EventBridge ルールと、オペレーションアカウントにイベントをプッシュするためのクロスアカウントアクセスを持つ AWS IAM ロールが含まれています。EventBridge ルールを起動するためのイベントパターンは、AWS CodePipeline におけるデプロイの状態変化を監視します。 { &nbsp; "detail-type": ["CodePipeline Pipeline Execution State Change"], &nbsp; "source": ["aws.codepipeline"] } オペレーションアカウントへデプロイされたリソース プロダクション環境へのデプロイ頻度を追跡する Lambda 関数は、成功したデプロイの回数をカウントし、その指標データを Amazon CloudWatch に投稿します。Amazon CloudWatch では、リポジトリ名の dimension を追加することで、特定のリポジトリやチームでフィルタリングすることができます。 リードタイムメトリクスの Lambda 関数は、最初のコミットからプロダクション環境への成功したデプロイまでの期間を計算します。このメトリクスには、コードレビュー、ビルド、テスト、そして実際のデプロイなど、変更に関わるすべての要因が含まれています。 変更失敗率メトリクスの Lambda 関数は、プロダクション環境での成功したデプロイの回数と、システムの障害記録（OpsItems）の回数を追跡しています。この関数は、両方のメトリクスデータを Amazon CloudWatch に公開し、その比率を計算することで変更失敗率を算出しています。 平均復旧時間メトリクスの Lambda 関数は、プロダクション環境における SUCCEEDED ステータスのデプロイのうち、リポジトリのブランチ名にOpsItemのIDが含まれているものを追跡しています。該当するデプロイイベントごとに、この関数はOpsItemの作成時刻を取得し、OpsItem作成からの成功した再デプロイまでの期間をCloudWatchダッシュボードに公開しています。 すべての Lambda 関数は、 PutMetricData API を使用して、メトリクスデータを Amazon CloudWatch に発行します。4 つのキーの最終計算は、CloudWatch ダッシュボードで実行されます。このソリューションには、エンドツーエンドのデータフローを検証し、正常にデプロイされたことを確認できる簡単な CloudWatch ダッシュボードが含まれています。 クリーンアップ 不要になったサンプルで作成したリソースは、将来的なコスト発生を避けるために削除を忘れないでください。これは CDK CLI から行えます: $ cdk destroy --profile { Tooling, Ops } 別の方法として、各 AWS アカウントの CloudFormation コンソールに移動し、DORA 関連のスタックを選択して 削除 をクリックしてください。すべての DORA スタックのステータスが DELETE_COMPLETE になっていることを確認してください。 まとめ DORA メトリクスは、デプロイの速度と安定性を測定する一般的な方法です。このブログ記事のソリューションは、AWS アカウントでメトリクスの自動収集を開始するのに役立ちます。4 つのキーは、チームのパフォーマンスに関するコンセンサスを得るのに役立ち、改善案のデータポイントとなります。チームの満足度とユーザーエクスペリエンスを阻害する体系的な問題に対して、リーダーシップからの支援を得るためにこのソリューションを使用することをお勧めします。開発者の生産性に関する研究の詳細を学ぶには、 DevEx および SPACE などの代替フレームワークをご覧ください。 参考リソース この記事が気に入ったら、以下の記事も読んでみてください: AWS での DevOps 監視ダッシュボード AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法 著者紹介 Rostislav Markov Rostislav is principal architect with AWS Professional Services. As technical leader in AWS Industries, he works with AWS customers and partners on their cloud transformation programs. Outside of work, he enjoys spending time with his family outdoors, playing tennis, and skiing. Ojesvi Kushwah Ojesvi works as a Cloud Infrastructure Architect with AWS Professional Services supporting global automotive customers. She is passionate about learning new technologies and building observability solutions. She likes to spend her free time with her family and animals.

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 猛暑を抜けて徐々に秋を感じてきましたが、みなさまいかがお過ごしでしょうか？ 毎年夏が終わると re:Invent の近付きを感じます。今年は12月2日から6日に開催されるので、現地参加予定の方は申し込みお忘れ無く。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年9月23日週の主要なアップデート 9/23(月) Jamba 1.5 family of models by AI21 Labs is now available in Amazon Bedrock AI21 LabsのJamba 1.5モデルファミリーが新たにAmazon Bedrockで利用可能になりました。Jamba 1.5 Largeは複雑な推論タスクに優れておりインプットの長さを問わず高品質な出力を必要とするケースに最適です。一方Jamba 1.5 Miniは長いプロンプトの低レイテンシー処理に最適化されています。これらのモデルは米国東部（バージニア北部）で利用可能です。詳細については ブログ や ドキュメント をご確認ください。 Amazon EC2 Instance Connect now supports IPv6 Amazon EC2 Instance ConnectがIPv6をサポートしました。EC2 Instance ConnectはSSHベースのインスタンスアクセスを簡単に実行できる機能です。これまではIPv4経由の接続のみをサポートしていましたが、今回IPv6をサポートし、IPv4、IPv6双方を利用可能になりました。詳細については ドキュメント をご確認ください。 Amazon SageMaker Studio now supports automatic shutdown of idle applications Amazon SageMaker Studioが一定期間非アクティブなアプリケーションの自動シャットダウンをサポートしました。この機能はAmazon SageMaker Distribution image version 2.0以降を利用するJupyterLabとCodeEditor アプリケーションで、コンソールもしくはAPI経由で設定可能です。管理者はSageMakerドメインまたはユーザープロファイルレベルでシャットダウンまでのアイドル時間を設定可能です。詳細については ドキュメント をご確認ください。 9/24(火) Amazon Redshift data sharing governed through AWS Lake Formation is now available in 11 additional regions Amazon Redshift データ共有のアクセスと権限を AWS Lake Formation で一元管理する機能が大阪を含む11のリージョンで新たに利用可能になりました。この機能を使うと、Lake Formationのデータレイク管理者が Redshift データ共有で共有されるテーブルやビューへのテーブルレベル、列レベル、または行レベルのアクセスなど、きめ細かい権限を管理できるようになります。また、AWS Lake Formation タグベースのアクセス制御を Redshift データ共有に適用することもできます。これにより、複数の AWS サービスおよびアカウントにわたるデータアクセスの管理が簡単になります。詳細については、 ドキュメント や ブログ 、 デモ をご確認ください。 AWS Resilience Hub extends support for Amazon ElastiCache AWS Resilience HubがAmazon ElastiCacheを含むアプリケーションを評価できるように拡張されました。Resilience Hubは、アプリケーションのレジリエンスを定義、検証、監視することができるサービスで、ソフトウェア、インフラストラクチャ、またはオペレーションの中断による不必要なダウンタイムを回避するのに役立ちます。この拡張はResilience HubがサポートされているすべてのAWS リージョンで利用可能です。 9/25(水) Llama 3.2 generative AI models now available in Amazon Bedrock Meta社のLlama 3.2がAmazon Bedrockで利用可能になりました。Llama 3.2モデルは、高解像度画像や高度な推論に対応するま中規模なマルチモーダルモデルである90Bと11Bに加え、エッジデバイスに適したテキストのみ扱う軽量な3B, 1Bモデルまでさまざまなサイズが展開されています。MetaのLlama 3.2 90Bおよび11Bモデルは、米国西部（オレゴン）リージョンのBedrockで利用できるのに加え、米国東部（オハイオ、バージニア北部）リージョンではクロスリージョン推論によりご利用いただけます。Llama 3.2 3Bおよび1Bモデルは、米国西部 (オレゴン) およびヨーロッパ (フランクフルト) リージョンのBedrockで利用できるのに加え、米国東部 (オハイオ、バージニア北部) およびヨーロッパ (アイルランド、パリ) リージョンではクロスリージョン推論によりご利用いただけます。詳細については、 ローンチブログ 、および ドキュメント をご確認ください。 Llama 3.2 generative AI models now available in Amazon SageMaker JumpStart Amazon Bedrockと同時に、Amazon SageMaker JumpStartでもLlama 3.2が利用可能になりました。90B,11B, 3B,1Bに加え責任あるイノベーションとシステムレベルの安全をサポートするように設計されたLlama Guard 3 11B VisionもSageMaker JumpStartで簡単に利用を開始出来ます。現時点では米国東部 (オハイオ)リージョンでご利用いただけます。詳細については ローンチブログ と ドキュメント をご確認ください。 Amazon EC2 G6 instances now available in additional regions NVIDIA L4 GPUを搭載したAmazon EC2 G6インスタンスが新たに東京を含む5つのリージョンで利用できるようになりました。G6インスタンスはGPUあたり24GBのメモリを搭載した最大8つのNVIDIA L4 Tensor コア GPUと、第3世代 AMD EPYC プロセッサが搭載されており自然言語処理、言語翻訳、ビデオと画像の分析、音声認識などのユースケースでご活用いただけます。 Introducing Amazon EC2 C8g and M8g Instances Amazon EC2 C8gインスタンスとM8gインスタンスの一般提供が発表されました。これらのインスタンスはAWS Graviton4 プロセッサを搭載しており、Graviton3 ベースのインスタンスよりも最大30%高速かつより大きなCPU, メモリを兼ね備えています。C8gインスタンスは、HPCやビデオエンコーディング、広告配信など、計算量の多いワークロード、M8gインスタンスは、アプリケーションサーバー、ゲームサーバーなどの汎用ワークロードに向いています。現時点では米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびヨーロッパ (フランクフルト)の4つのリージョンでご利用いただけます。ワークロードのGraviton ベースのインスタンスへの移行に興味のある方は「 AWS Graviton Fast Start program 」「 Porting Advisor for Graviton 」もご確認ください。 Amazon Kinesis Data Streams announces support for Attribute-Based Access Control (ABAC) Amazon Kinesis Data Streamsがストリームタグを使用した属性ベースのアクセス制御 (ABAC) をサポートしました。Kinesis Data Streamsは、あらゆる規模のデータストリームをキャプチャ、処理、保存できるようにするサーバーレスのデータストリーミングサービスです。ABACサポートにより、ユーザーまたはプロジェクトの追加、削除、または更新時にポリシーを更新しなくてもきめ細やかなアクセス制御が可能になりました。この機能はAWS GovCloud (米国)リージョンを含むすべてのAWSリージョンで利用可能です。詳細に関しては ドキュメント や「 Attribute-Based Access Control (ABAC) for AWS 」をご確認ください。 AWS CloudTrail launches network activity events for VPC endpoints (preview) VPC エンドポイント向けの AWS CloudTrail ネットワークアクティビティがプレビューとして公開されました。この機能を利用するとネットワーク内のリソースにアクセスしているユーザーの詳細を表示できるため、データ境界での悪意のあるアクションや不正なアクションを特定して対応しやすくなります。プレビューではAmazon EC2、AWS KMS、AWS Secrets Manager、AWS CloudTrailの4つサービスで有効に出来ます。詳細は ドキュメント をご確認ください。 AWS announces general availability for Security Group Referencing on AWS Transit Gateway AWS Transit Gateway(TGW)で接続されたVPC間でのセキュリティグループ参照が一般提供されました。これまではTGW経由で接続されたVPC間のトラフィックを制御するためにセキュリティグループを利用することが出来ませんでした。セキュリティグループ参照ができるようになったことで、TGWの設計時にセキュリティグループを参照先として指定したり、インバウンドセキュリティルールの一致基準を指定してインスタンス間のトラフィックを許可したりできます。この機能はTransit Gatewayが利用可能なすべてのAWSリージョンで利用可能です。詳細については ドキュメント をご確認ください。 9/26(木) Amazon MWAA now supports Apache Airflow version 2.10 Amazon Managed Workflows for Apache Airflow(MWAA)でApache Airflow version 2.10がサポートされました。Apache Airflow 2.10にはダークモードへの対応のほか、リソース使用率の可視化、動的なデータセットスケジューリングなどの機能強化のほかセキュリティアップデートやバグ修正が含まれています。詳細なApache Airflow 2.10の変更点に関しては 変更ログ をご確認ください。 Amazon Aurora MySQL now supports RDS Data API Amazon Aurora MySQL 互換エディションで、Aurora Serverless v2および Aurora インスタンス向けに再設計されたData APIがサポートされました。Data APIはHTTP エンドポイントを介してAuroraクラスターにアクセスし、ドライバーなしでSQLを実行できるAPIです。これまでは1 秒あたり 1,000 リクエスト (RPS) のレート制限があるAurora Serverless v1クラスターのみサポートしていましたが、再設計によりスケーラビリティが向上し、Aurora Serverless v2および Aurora インスタンスではリクエストにレート制限は課されません。この機能は14のリージョンで、Aurora MySQL 3.07以降のバージョンで利用可能です。現在Aurora Serverless v1でData APIを利用するお客様は再設計のメリットを享受するために移行をお勧めします。 Amazon RDS Performance Insights now supports queries run through Data API Amazon RDS Performance InsightsがAurora PostgreSQLクラスターの RDS Data API経由のクエリのモニタリングをサポートしました。RDS Performance Insightsはデータベースのパフォーマンスを可視化し、チューニングを支援するモニタリング機能です。これまではData APIを介して実行されたクエリはサポートされませんでした。機能の詳細に関してはAmazon RDSの ユーザーガイド をご確認ください。 AWS ParallelCluster 3.11 now available with login node enhancements AWS ParallelCluster 3.11一般公開されました。AWS ParallelClusterは研究者や研究機関のIT管理者がAWSでHPCクラスターを運用できるようにするためのオープンソースのクラスター管理ツールで、科学、工学、機械学習 (ML/AI)などさまざまな目的の大規模ワークロードで活用されています。3.11ではログインノードでのNICE DCVサポートとカスタムアクションスクリプトが追加されています。リリースの詳細については、AWS ParallelCluster 3.11.0の リリースノート を参照してください。 9/27(金) AWS CodePipeline introduces pipeline variable check rule for stage level condition CodePipeline V2のステージ条件で変数チェックを行うことができるようになりました。CodePipeline V2ではステージの開始時、もしくは終了時に任意の条件で成功、失敗の判断条件を設定可能です。今回、変数をサポートしたことで、例えばCodeBuildアクションの出力結果が特定のあたいの時に成功/失敗を判断するなどより柔軟な条件設定が可能になります。詳細はこちらの ドキュメント もご確認ください。この機能はCodePipelineがサポートされているすべてのリージョンで利用できます。 最後に一つ。 11月1日に「AWS 秋の Observability 祭り ~明日使えるアセット祭り~」と題してAWS Startup Loft Tokyoでイベントが予定されています。Observabilityにお悩みの方がいらっしゃればぜひご活用ください！ – 2024年11月1日 19:00-21:00 @ AWS Startup Loft Tokyo AWS 秋の Observability 祭り ~明日使えるアセット祭り~ 申し込みは こちら それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今年の秋は生成AI のイベントが盛りだくさんです。10 月にかけて「 AWS Japan 生成 AI ハッカソン～生成 AI で日々の仕事はもっと楽しくなる 」が開催されます。ナビゲーター、および審査員として QuizKnock 伊沢氏、鶴崎氏に発表会に登場いただきます。応募締め切りは、10 月 2 日 (水) です。楽しみながら生成AI 活用のアイデアを形にしてみたい、という方は是非ご参加ください。 10 月 3 日 (木) には「 RAG だけじゃない！生成 AI の価値を引き出す自社データ活用とプロンプトによる LLM 調整術 」というイベントをオンラインで開催します。AWS のセッションに加え、Oisix 様から Amazon Bedrock を使ったメルマガ最適化に関する登壇をしていただきます。データ活用やマーケティングというワードにピンときた方はぜひご覧ください。 引き続き「 AWSジャパン生成AI実用化推進プログラム 」も募集中です。こちらの方もよろしくお願いいたします。 それでは、9 月 23 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ケンブリッジ・テクノロジー・パートナーズ株式会社様、Amazon Bedrock を活用した社内研修のレコメンド機能により視聴数を 20% 向上 ケンブリッジ・テクノロジー・パートナーズ株式会社様は、コンサルティングファームとして質の高い業務改革を推進するために、 人材育成を重要視しています 。しかし、年間 250 以上提供されている社内研修の内容を各社員が把握し必要な研修を選択するのは困難であるといった課題を抱えていました。そこで、Amazon Bedrock を利用し、適切な社内研修を、受講すべき社員にレコメンドする仕組みを開発しました。 Bedrock により、研修概要の生成、受講をおすすめする社員の選定、レコメンド理由の生成などが行われ、研修動画の視聴を促す通知が送られます。こちらを導入した結果、従来よりも研修後の録画視聴数が約 20 %向上、そしてコンサルタント育成の精度向上を実現されました。研修概要とレコメンドの生成を分けて処理している工夫も参考になります。 AWS生成AI国内事例ブログ: 株式会社日立パワーソリューションズ、設備の保守知識の共有を目的としたRAGの構築を3ヶ月で実現 日立パワーソリューションズ様 は、風力発電設備から工場の生産ラインまで、多岐にわたる設備の保守を行う一方で、高齢化に伴ってベテラン保守作業員が減少しており、若手・中堅社員へ知識を継承することが重要課題になっています。そこで、報告書作成支援や、保守マニュアル検索などが可能な RAG サービス 「Power AI Ground（パワグラ）」を Amazon Bedrock や Amazon Kendra を活用して構築しました。報告書作成支援では、 帳票データを XML 形式に変換する工夫等を行い、回答精度を 40% から 90% に改善しました。ベテランエンジニアの知識共有という当初の課題についても解決できる見通しが得られたそうです。価格メリット、 サンプルコード 、技術支援の充実さ、がAWS採用のポイントだったと述べられています。 AWS生成AI国内事例ブログ: 株式会社 朝日新聞社、コンテンツ制作支援サービスの要約やキャプチャ生成に Amazon Bedrock を活用 株式会社 朝日新聞社様 は、 以前も取り組みを紹介 したコンテンツ制作支援サービス ALOFA を提供しています。ALOFA では、コンテンツ内容や重要な部分がすぐに把握できるように、要約やチャプターなどが生成される機能があり、こちらで Amazon Bedrock が活用されています。モデル選定の際は、単一の API を介すことで容易に複数のモデルを選択できる Amazon Bedrock の利点を活かして、複数の最新モデルの検証を行いました。また、複数リージョンの Bedrock エンドポイントを AWS Lambda から呼び出し、推論処理を分散するといった工夫を取り入れることで、安定した生成 AI の活用も実現されています。 ブログ記事「Amazon Q と Bedrock を使った SAP 生産性向上ユースケース」を公開 最近、 AWS と SAP は戦略的な協業を拡大 し、生成AI 領域の連携を深めています。このブログでは、まず SAP での生成AI 活用ユースケース例を 15 つ紹介しています。また、その中のいくつかのユースケースを実現するために、Amazon Q と Amazon Bedrock をどのように SAP と連携するかをアーキテクチャ図付きで解説しています。SAP ユーザーの方はぜひご一読を。 ブログ記事「【動画公開 &amp; 開催報告】AI 時代に技術を活かす！人材と組織、そして活用プロセス構築のポイントを解説！ ～進化し続ける技術を活用するために効果的な組織と人材育成のあり方、そしてそれらを導入する際の課題と対策について学ぶ～」を公開 2024 年 9 月 5 日に上記タイトルのイベントをオンラインで開催しました。このブログはそのイベントのレポートです。ビジネスを加速させる組織にこれから求められることや、実践力と経験値を磨く方法などを紹介しており、昨今注目されている AI CoE についても触れています。資料と動画が公開されていますので、是非ご覧ください。 サービスアップデート Amazon Bedrock で Meta Llama 3.2 が利用可能に Amazon Bedrock で Meta 社の Llama 3.2 をご利用頂けるようになりました。Llama 3.2 では4つのモデル (90B、11B、3B、1B) が用意されています。90B、11Bは、 Llama モデルで初めてマルチモーダルのユースケースをサポートし画像に対する推論タスクを行うことが可能です。3B、1Bは、エッジデバイスに適したテキストのみの軽量モデルです。詳細や対応リージョンは ブログ記事 をご参照ください。 Amazon Bedrock で AI21 Labs の Jamba 1.5 モデルファミリーが利用可能に Amazon Bedrock で AI21 Labs の Jamba 1.5 モデルファミリーが利用可能になりました。Jamba 1.5 モデルファミリーには、Jamba 1.5 Mini と Jamba 1.5 Large が含まれます。両モデルとも 256K トークンのコンテキストウィンドウを持っているのが特徴で、長い文書の要約や分析への活用が期待できます。現在バージニア北部のAmazon Bedrock で利用できます。詳細は ブログ記事 をどうぞ。 Amazon Titan Image Generator の Content Credentials機能を発表 Content Credentials とは、デジタルコンテンツの出所や真正性を証明するための技術標準です。 C2PA という業界横断組織が開発しており Amazon も参加しています。このリリースでは、Amazon Titan Image Generator で生成された画像に、C2PAメタデータがデフォルトで含まれるようになりました。これにより、生成された画像を Verify に upload することで、画像の発行元や利用モデル等が簡単に確認できるようになりました。 Amazon SageMaker JumpStart にて Meta Llama 3.2 が利用可能に 事前トレーニング済みのモデルを数回のクリックでデプロイできる Amazon SageMaker JumpStart でも Meta 社の Llama 3.2 をご利用頂けるようになりました。オハイオリージョンで利用可能です。 ブログ記事 はこちらです。 Amazon SageMaker with MLflow が AWS PrivateLink に対応 MLflow をフルマネージドな環境で利用できる Amazon SageMaker with MLflow が AWS PrivateLink に対応しました。これにより、VPC から MLflow トラッキングサーバーへの重要なデータをプライベートかつスケーラブルに転送できるようになりました。 Amazon SageMaker でモデルデプロイ時にソフトウェアとドライバーバージョンをカスタマイズ可能に SageMaker でモデルをデプロイする際、インスタンス上で使用するソフトウェアとドライバーのバージョンを選択できるようになりました。選択できるのは、例えば Nvidia ドライバーや CUDA バージョンなどです。これにより、ML アプリケーションのパフォーマンス、互換性、スケーラビリティ、運用要件に合ったホスティング環境を調整できます。 Amazon SageMaker Studio がアイドル状態のアプリケーションの自動シャットダウンに対応 Amazon SageMaker Studioが、一定期間非アクティブ状態のアプリケーションを、自動的にシャットダウンする機能に対応しました。アイドルシャットダウン時間を設定すると、SageMaker Studio はアプリケーションがアイドル状態になったことを自動的に検出し、指定された期間後にシャットダウンします。使用されていないインスタンスの料金発生を回避するのに役立ちます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’もり’です。

AWS Amplify を使えば、あなたのニーズに応じて複数のバケットを構成および管理できます。開発者は、Amplify Storage を活用して、単一または複数のストレージバケットにわたってコンテンツを編成・管理でき、各バケット内の個々のパス単位で詳細なアクセス ルールを適用できます。 今年の初めに、 Amazon Simple Storage Service (Amazon S3) と統合し、クラウドベースのファイルストレージを管理するための直感的なアプローチを提供する、新しく改良された Amplify Storage をアナウンスしました (「 Amplify Storage: Amplify のフルスタック TypeScript 開発体験から利用できる Amazon S3 」)。これに加えて、バックエンド構成と JavaScript Storage API を使って、複数のストレージバケットを構成して接続できるようになったことをお知らせできて嬉しく思います。 複数のストレージバケットを持つ一般的なユースケースは、データ転送速度の向上などの最適化が必要なアプリケーションデータと長期のバックオフィスデータを分離することです。例えば、Amazon S3 Transfer Acceleration を使用してユーザー生成コンテント (写真、動画など) の高速アップロード/ダウンロード用に最適化されたバケットと、レポート、ログ、バックアップなどあまりアクセス頻度が高くない長期アーカイブデータを保存する別のバケットを設定できます。 Amplify Storage では、アップロード、ダウンロード、リスト などの API を以下に対して呼び出すことができます。 Amplify バックエンドで構成されたバケット: これらは Amplify プロジェクトのバックエンド構成で定義、管理されるバケットです。 amplify/storage/resource.ts ファイル内で、これらのバケットのバケット名やアクセスルールなどの設定を指定できます。 既存の S3 バケット: Amazon S3 コンソールで直接作成された Amazon S3 バケットとも連携できます。 Amplify バックエンドで構成されたストレージとアプリを接続する 1. Amplify プロジェクトの初期化 この例では、新しい Next.js プロジェクトを作成します。 npx create-next-app@latest multi-bucket-app 設定手順に従い、「Would you like to use TypeScript?」と尋ねられたら「Yes」を選んでください。 現在のフォルダに「multi-bucket-app」という名前のアプリがあります。この新しいアプリに移動し、AWS Amplify を初期化してください。 &gt;cd multi-bucket-app &gt;npm create amplify@latest このコマンドにより、プロジェクトに以下の構造を持つ「amplify」フォルダが作成されます。 2. Amplify バックエンドでストレージバケットの定義 まず、ユーザープロフィール写真のようなユーザー生成コンテンツを保存するバケットを作成します。認証済みのユーザーが assets/photos/* パスに読み書きできるようにしつつ、ゲストユーザーにはこのパスから読み取りのみできるようにします。 amplify/storage/ の下に新しい resource.ts ファイルを作成します。このファイルで最初のストレージバケットの設定を定義できます。 import { defineStorage } from '@aws-amplify/backend'; export const userDataBucket = defineStorage({ name: 'user-data-bucket' access: (allow) =&gt; ({ 'assets/photos/*': [ allow.guest.to(['read']), allow.authenticated.to(['read','write']), ] }) }); 次に、 amplify/backend.ts ファイルで Amplify バックエンド定義にストレージバケットの設定を追加してください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket }); この例では、アプリがユーザー生成コンテンツバケットに対して頻繁に呼び出しを行い、エンドユーザーに関連する写真を表示します。これらの写真をクライアントに素早く配信できるよう、このバケットで Amazon S3 Transfer Acceleration を有効化します。 注 : Amazon S3 Transfer Acceleration は、大きなオブジェクトの長距離転送時に、Amazon S3 への転送と Amazon S3 からの転送の両方を最大 50～500 % 高速化できます。詳細については、 S3 Transfer Acceleration を参照してください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket }); const { cfnBucket } = backend.userDataBucket.resources.cfnResources ; cfnBucket.accelerateConfiguration = { accelerationStatus: "Enabled" } npx ampx sandbox コマンドを実行すると、Amplify バックエンドのローカルサンドボックス環境が起動するので、アプリをローカルでテストできます。同様に、より多くのストレージバケットを定義する場合は、 amplify/storage/resource.ts ファイル内で同じ defineStorage メソッドを使用できます。 import { defineStorage } from '@aws-amplify/backend'; export const userDataBucket = defineStorage({ name: 'user-data-bucket', isDefault: true, access: (allow) =&gt; ({ 'assets/photos/*': [ allow.guest.to(['read']), allow.authenticated.to(['read','write']), ] }) }); export const reportingDataBucket = defineStorage({ name: 'reporting-data-bucket', access: (allow) =&gt; ({ 'reportingData/logs/*': [ allow.groups(['admins']).to(['read','write']), ], 'reportingData/performance/*': [ allow.groups(['admins']).to(['read','write']), ] }) }); 複数のストレージバケットを扱う場合は、1 つをデフォルトのバケットに指定する必要があります。そのためには、 amplify/storage/resource.ts ファイル内のストレージバケット定義の 1 つで、 isDefault プロパティを true に設定します。この指定したデフォルトのバケットは、特定のバケットが提供されていない場合に、Amplify Storage API によって自動的に使用されます。 新しいリソースを amplify/backend.ts にあるバックエンド構成にインポートしてください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket, reportingDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket, reportingDataBucket }); const { cfnBucket } = backend.userDataBucket.resources.cfnResources ; cfnBucket.accelerateConfiguration = { accelerationStatus: "Enabled" } 3. Amplify Storage ライブラリを使用して特定のバケットにファイルをアップロード ストレージバケットにアップロードするには、既存の Amplify Storage API を引き続き使用できます。 amplify/storage/resource.ts ファイルで定義されたバケット名を渡してください。バケット名が指定されていない場合は、同じ resource.ts ファイルで構成された既定のバケットにファイルがアップロードされます。 import { uploadData } from 'aws-amplify/storage'; //Set the file variable to the file you want to upload const file: File const { result } = await uploadData({ path: 'reportingData/logs/08222024.txt', data: file, options: { bucket: 'reporting-data-bucket' } }); 他の API のようにダウンロードデータ、リスト、コピーなどで使う S3 バケットも bucket オプションで指定できます。その他の Amplify Storage API については、 Amplify Storage のドキュメンテーション を参照してください。 既存の S3 バケットへのアプリケーションの接続 別の方法として、バケット名とリージョンを指定して、既存の Amazon S3 バケットに直接ファイルをアップロードすることもできます。この方法を使えば、Amplify バックエンド構成で定義されていない、カスタム S3 バケットと Amplify Storage ライブラリを併用できます。 既存の S3 バケットにファイルをアップロードするには、Amplify Storage API のオプションとして、実際のバケット名 (Amazon S3 コンソールで確認できるもの) と対応する AWS リージョンを渡してください。 Amplify Storage API でカスタム Amazon S3 バケットを使用する手順 をご参照ください。 import { uploadData } from 'aws-amplify/storage'; //Set the file variable to the file you want to upload const file: File const { result } = await uploadData({ path: 'reportingData/logs/08222024.txt', data: file, options: { bucket:{ bucketName: 'bucket-name-from-s3-console', region: 'us-east-2' } } }); まとめ AWS Amplify を使えば、複数のストレージバケットを設定・管理することで、アプリのコンテンツをより適切に整理し分離できるようになりました。ストレージバケットの設定方法の詳細については、 Amplify Storage ドキュメント を参照してください。Amplify はオープンソースプロジェクトであり、私たちは常にコミュニティからのフィードバックを求めています。私たちのいずれかのチャネルで皆様からご意見をお聞かせください。 Discord で議論に参加するか、 GitHub プロジェクト に機能リクエストや不具合報告をお寄せください。 本記事は「 Add multiple storage buckets to your app using AWS Amplify – NEW 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify は、Amplify Functions に関数の実行ログストリーミングと cron および自然言語によるスケジューリングサポートの 2 つの新機能を発表します。Amplify では、開発者が TypeScript でサーバーレス関数を作成し、数秒でビジネスロジックをデプロイできるため、すばやくイテレーションできます。Amplify Functions の詳細については、 AWS Amplify の Functions ドキュメント を参照してください。 ストリーミング関数ログ Amplify の開発者ごとのクラウドサンドボックス では、開発者がライブリソースを使ってアプリケーションのバックエンドを設計、構築、イテレーションできる開発環境を提供されます。さらにイテレーションサイクルを減らすために、Amplify は開発者が関数の実行ログをターミナルに直接ストリームできるようになり、ローカルの開発環境から離れることなく関数実行のインサイトが得られるようになりました。 開始するには、 --stream-function-logs オプションを指定して、すべての関数ログのストリーミングをオプトインしてください。 npx ampx sandbox --stream-function-logs たとえば、認証リソースに Amazon Cognito Lambda トリガー としてアタッチされた関数の集合がある場合、フロントエンドフレームワークの開発サーバーを起動し、認証フローを通って、各関数の呼び出しからログを検査できます。これらはすべて AWS マネジメントコンソールに移動することなく行えます。 例えば、多数の関数があり、バックエンド機能の一部のデバッグだけに興味がある場合、 --logs-filter を指定して関数名に基づいてログ出力をフィルタリングできます。 npx ampx sandbox --stream-function-logs --logs-filter auth ログフィルターでは、関数名でフィルタリングできます。上記のコマンド例を使用する場合、トリガーのリソース名の規則は次のようになります。 // amplify/auth/post-confirmation/resource.ts import { defineFunction } from "@aws-amplify/backend" export const postConfirmation = defineFunction({ name: "auth-post-confirmation", }) ただし、複雑なフィルターの場合、 --logs-filter オプションは正規表現を受け入れます。上記と同じ例を用いて、関数名が “auth” で 始まる ものだけのログをフィルターする場合は次のようになります。 npx ampx sandbox --stream-function-logs --logs-filter "^auth" sandbox プロセスは、対応する正規表現と一致する関数のログのみを出力します。 [Sandbox] Watching for file changes... File written: amplify_outputs.json [auth-pre-sign-up] 3:36:34 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-pre-sign-up] 3:36:34 PM START RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 Version: $ LATEST [auth-pre-sign-up] 3:36:34 PM END RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 [auth-pre-sign-up] 3:36:34 PM REPORT RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 Duration: 4.12 ms Billed Duration: 5 ms Memory Size: 512 MB Max Memory Used: 67 MB Init Duration: 173.67 ms [auth-post-confirmation] 3:38:40 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-post-confirmation] 3:38:40 PM START RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 Version: $ LATEST [auth-post-confirmation] 3:38:41 PM 2024-07-19T22:38:41.209Z fce69b9f-b257-4af8-8a6e-821f84a39ce7 INFO processed 412f8911-acfa-41c7-9605-fa0c40891ea9 [auth-post-confirmation] 3:38:41 PM END RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 [auth-post-confirmation] 3:38:41 PM REPORT RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 Duration: 264.38 ms Billed Duration: 265 ms Memory Size: 512 MB Max Memory Used: 93 MB Init Duration: 562.19 ms [auth-pre-authentication] 3:38:41 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-pre-authentication] 3:38:41 PM START RequestId: 9210ca3a-1351-4826-8544-123684765710 Version: $ LATEST [auth-pre-authentication] 3:38:41 PM END RequestId: 9210ca3a-1351-4826-8544-123684765710 [auth-pre-authentication] 3:38:41 PM REPORT RequestId: 9210ca3a-1351-4826-8544-123684765710 Duration: 3.47 ms Billed Duration: 4 ms Memory Size: 512 MB Max Memory Used: 67 MB Init Duration: 180.24 ms [auth-post-authentication] 3:38:42 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-post-authentication] 3:38:42 PM START RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 Version: $ LATEST [auth-post-authentication] 3:38:42 PM END RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 [auth-post-authentication] 3:38:42 PM REPORT RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 Duration: 4.61 ms Billed Duration: 5 ms Memory Size: 512 MB Max Memory Used: 68 MB Init Duration: 172.66 ms Amplify ドキュメントを参照して、関数ログのストリーミングの詳細を確認してください 。 関数の予約実行 2 つ目の改善は、開発者が cron 式や自然言語を使って関数の実行間隔をスケジューリングできるようになったことです。開始するには、新しい schedule プロパティで間隔を指定します。 // amplify/jobs/drink-some-water/resource.ts import { defineFunction } from "@aws-amplify/backend" export const drinkSomeWater = defineFunction({ name: "drink-some-water", schedule: "every 1h", }) スケジュールは間隔として定義され、毎時間パフォーマンスの良い投稿の「トップページ」を生成したり、週次ダイジェストとしてパフォーマンスの良い投稿をまとめるなど、さまざまな用途に使用できます。新しい間隔を作成するには、自然言語を使用するだけです。 以下の例では、「 [リマインド ] 毎日水を飲む」関数のスケジューリングを定義しています。 // amplify/jobs/drink-some-water/resource.ts import { defineFunction } from "@ aws-amplify/backend" export const drinkSomeWater = defineFunction({ name: "drink-some-water", schedule: [ "every 5m", "every 1h", "every day", "every week", "every year", ], }) スケジューリングはさらに、強く型付けされたプロパティ値を提供することで簡素化されます。これにより、タブ補完が可能になり、スケジュールがシステムの期待に沿うことが保証されます。スケジュールは cron 式を使って複雑な要件を定義できます。たとえば、ゴミを出すリマインダーは、特定の時間に 2 日間だけ出る場合があります。 // amplify/jobs/remind-me-to-take-the-trash-out/resource.ts import { defineFunction } from "@aws-amplify/backend"; export const remindMe = defineFunction({ name: "remind-me-to-take-the-trash-out", schedule: [ // every tuesday at 9am "0 9 ? * 3 *", // every friday at 9am "0 9 ? * 6 *", ] }) 内部的には、スケジュールは Amazon EventBridge ルール によって実現されています。このルールは、EventBridge がイベントにどのように対応するかを記述する方法です。ここでは、これらのルールは関数が実行される間隔を示しています。 スケジューリング関数の詳細は、Amplify のドキュメントをご覧ください まとめ 2 つの新機能を Amplify Functions で体験していただけることを心よりお待ちしております。フィードバックがあれば、ぜひ GitHub リポジトリ までお寄せください。同じ志を持つ開発者コミュニティにご参加いただく場合は、 Discord コミュニティ にご参加ください。 本記事は「 New features for Amplify Functions: Scheduling and Log Streaming 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

本ブログはケンブリッジ・テクノロジー・パートナーズ株式会社様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの山澤です。 最近、 AI 技術がどんどん賢くなってきて、私たちの仕事や生活が今後どのように変わっていくのかを同僚と話す機会が増えた気がします。このように急激に変化している時代において、「これからどのようなスキルを磨くべきか悩む」という方も多いのではないでしょうか。特に、たくさんの研修プログラムを用意している会社では、社員が自分に合った研修を選ぶのに迷うことがあるかもしれません。 本記事では、ケンブリッジ・テクノロジー・パートナーズ株式会社様が、このような課題に対して Amazon Bedrock を活用し、生成 AI による社内研修の説明付きレコメンド機能を構築されましたので、その事例をご紹介します。 お客様の状況と検証に至る経緯 ケンブリッジ・テクノロジー・パートナーズ株式会社様は、コンサルティングファームとして質の高い業務改革を推進するため、人材育成を重要視しています。この人材育成を効果的に進めるために、LECO（ Learning ECO system ）という社内サービスを通じて、社内研修の「講師」と「受講者」を効果的にマッチングし、学習意欲のある社員に適切な研修機会を提供されています。 しかし、このような積極的な取り組みを行っているものの、人材育成の最適化には依然として以下のような課題を感じられていました。 コンサルタントの育成のために、年間 250 を超える社内研修を提供しているが、各研修で受講に適している社員に受講してもらえていない。 研修数が多いため、社員は各研修の内容を把握できておらず、自分に必要な研修を選択することが困難になっている。 そこで、基盤モデルの変更が容易な Amazon Bedrock を利用し、適切な社内研修を、受講すべき社員にレコメンドする仕組みを開発しました。 お客様が開発された生成 AI を活用した社内研修の説明付きレコメンド機能 ケンブリッジ・テクノロジー・パートナーズ株式会社様が開発された社内研修の説明付きレコメンド機能は、「アンケートコメント」、「社員一覧」、「職能別の期待値や評価基準」、「直近の研修受講履歴」など、多様な非定型データを活用しています。これらを Claude 3 Opus の入力データとして使用し、その出力結果を Slack に通知する仕組みを構築されました。 そして、実際に研修が実施された際に、研修の内容やレコメンドする社員を Slack にレポートとして通知しています。 こちらが Slack に通知されるレポートの例です。このレポートにより、研修を受講してほしい社員に対して、録画された研修の動画を視聴するように促しています。 また、Claude での処理は、図に示しているように、 2 回に分けて行われています。2 回に分けることで、ステップ 1 の出力結果をステップ 2 の入力として使用する工夫をされています。 ステップ 1 ：「研修情報」、「アンケート結果」の情報をもとに、「概要」、「参加者の感想」の要約を生成 ステップ 2：「ステップ 1 の要約結果」、「社員一覧」、「職能別の期待値や評価基準」、「直近の研修受講履歴」の情報をもとに、「研修受講をレコメンドする社員」「レコメンド理由」を生成 導入効果 社内研修の説明付きレコメンド機能を導入した結果、以下の効果が得られました。 従来よりも研修後の録画視聴数が約 20 %向上しました。 研修を受講してほしい社員に受講してもらえることで、本来狙っていたコンサルタントの育成の精度を上げることができました。 従来の AI によるレコメンドでは、予想結果は表示されるものの、その理由までは表示されないことが多かったが、今回のアプローチでは、生成 AI を用いて、レコメンド理由もあわせて表示されている点が特徴的です。この工夫によって、研修を受講するのに適している可能性のある社員の興味を惹くことができたと考えられています。 まとめ 今回は、ケンブリッジ・テクノロジー・パートナーズ株式会社様が開発された社内研修の説明付きレコメンド機能をご紹介いたしました。本検証を通じて、お客様から以下のコメントを頂いております。 「今回の取り組みを通じて、今まで活用しにくかった自然言語データが業務に利用可能になりました。その結果、様々な箇所でイノベーションの種があることが分かりました。」 最近、多くの企業が社内に蓄積されたデータの有効活用に高い関心を寄せているという話を耳にすることがあります。このような取り組みは、社内データを活用して、人材育成や組織の生産性向上を目指す企業にとって参考になるのではないでしょうか。 なお、ケンブリッジ・テクノロジー・パートナーズ株式会社様の人材育成に関する情報は、 こちら で公開されております。社員の成長が生命線であるコンサルティングファームが、育成の仕組みをどのように構築し運用しているか、ご興味のある方は是非ご確認ください。 ケンブリッジ・テクノロジー・パートナーズ株式会社様 : アソシエイトディレクター テクニカル・アーキテクト 広沢 元様（右端）、コンサルタント 吉村 勘太郎様（右から 2 番目） Amazon Web Services Japan : アカウントマネージャー 浜崎 佳子（左端）、ソリューションアーキテクト 山澤 良介（左から 2 番目） ソリューションアーキテクト 山澤 良介 (X – @ymzw230 )

本稿は、2024年5月21日に Networking &amp; Content Delivery で公開された “ Introducing mTLS for Application Load Balancer ” を翻訳したものです。 AWS は 2023年11月26日、 Application Load Balancer (ALB) で X509 証明書を使用したクライアントの相互認証機能をサポートすると発表しました。この記事では、この新機能を実装するためのオプションと、実装時に考慮すべき点について説明します。 ALB はアプリケーション層 ( OSI モデル の第7層) で動作し、バックエンドターゲットに着信する HTTP/HTTPS リクエストのロードバランシングを行います。ALB は一般的に、スケーラブルで安全な Web アプリケーションを作成するために使用され、ホスト名、完全パス、または HTTP ヘッダー条件に基づいてルーティングできる高度なルーティングルールをサポートしています。詳細については、 Application Load Balancer のドキュメント を参照してください。 セキュリティの観点から、ALB では HTTPS リスナーを作成できます。HTTPS リスナーを使用すると、ALB はクライアントとの TLS セッションを終端します。ALB には、AWS WAF とのネイティブ統合機能があり、Web アプリケーション用のルールを作成し、ALB の背後で実行されているアプリケーションを保護できます。 mTLS コンセプト 相互トランスポート層セキュリティ (mTLS) は、ネットワーク通信を保護するために使用される TLS プロトコルを拡張したものです。TLS は通常、インターネット上の安全な接続を確立するために使用され、認証、データの機密性、および整合性を確保します。ただし、従来の TLS では、認証は一方向であり、サーバーがクライアントに対して自身を認証しますが、クライアントの身元は検証されません。 これに対し、mTLS では、サーバーとクライアントの両方が相互に認証することが求められるため、「相互」または「双方向」TLS と呼ばれています。mTLS に関連する概念として以下のようなものがあります: 認証局 (CA): 企業にTLS証明書を提供する組織や団体のことです。認証局は、TLS 証明書を発行する前に、ドメイン名と所有者の詳細を確認します。 TLS 証明書: システム (Web クライアントなど) が別のシステム (Web サーバーなど) の身元を検証できるようにする、デジタルオブジェクトです。TLS 証明書に含まれる詳細情報により、クライアントはサーバーとの暗号化された接続を確立できます。 サーバー証明書: サーバーの身元を証明する TLS 証明書です。 クライアント証明書: クライアントの身元を証明する TLS 証明書です。 証明書 信頼チェーン: TLS 証明書の順序付きリストです。チェーンは (クライアント/サーバーの TLS 証明書である) リーフ証明書から始まり、ルート証明書で終わります。リーフ証明書とルート証明書の間の証明書は中間証明書と呼ばれます。チェーンの各証明書は、次の証明書で識別された組織/団体によって署名されています。これは図1に示されています。 図1 : 証明書信頼チェーン TLS ハンドシェイク: クライアントとサーバーが相互に TLS 証明書を使って認証を行い、暗号化の標準に合意し、データを安全に転送するための secure チャネルを作成するプロセスです。詳細については、 TLS のドキュメント を参照してください。クライアントは、TLS ハンドシェイク中に TLS 証明書をサーバーと共有します。これにより、サーバーはクライアントを認証できます。 証明書失効リスト (CRL): 信頼されるべきではないブロックリストに載せられた証明書のリストです。 mTLS プロセスは、スマートデバイス、API、マイクロサービス間の通信を保護したり、規制要件を満たすために相互の身元を確認する必要がある状況で一般的に使用されます。また、VPN (仮想プライベートネットワーク) や組織内部の通信を保護するためにも使用されています。 mTLS を実装するには、サーバーとクライアントの両方が信頼できる CA によって発行された電子証明書を持っている必要があります。これらの証明書は同じ CA または異なる CA によって生成することができ、ハンドシェイク過程で相手の信頼性を証明するために使用されます。 Application Load Balancerで mTLS クライアント認証を使用する Application Load Balancer は、クライアントの証明書チェーンの深さと大きさが一定の範囲内にある場合、mTLSをサポートしています。現在サポートされている最大サイズと深さについては、 Application Load Balancer のクォータ をご確認ください。ClientCertExceedsDepthLimit および ClientCertExceedsSizeLimit の各 Amazon CloudWatch メトリクスを使用すると、これらの制限を超えた要求を追跡できます。 Application Load Balancer は、mTLSで以下の2つの動作モードをサポートしています: mTLS 検証モード mTLS パススルーモード mTLS 検証モード Application Load Balancer で mTLS検証モードを使用するには、トラストストアを作成する必要があります。トラストストアには、クライアント証明書を検証するために使用される1つの CA 証明書バンドルがあります。自分の証明書を持参するか、 AWS Certificate Manager(ACM) を使用して証明書を生成できます。ALB の mTLS 検証モードには、AWS 管理の CA を使用できます。 AWS Private Certificate Authority は、高可用性の管理CA サービスで、組織がプライベート証明書を使用してアプリケーションとデバイスを保護するのに役立ちます。証明書の発行と管理の詳細については、 ACMのドキュメント を参照してください。 信頼しないクライアント証明書を指定するには、1つ以上の証明書失効リスト (CRL) をトラストストアに関連付けます。失効リストを S3 バケットにアップロードし、そのバケットをトラストストアで指定します。ALB は S3 から CRL をインポートし、CRL チェックは ALB によって行われるため、毎回 S3 から CRL をフェッチする必要がなくなります。これにより、ALB は CRL を使用したクライアント認証時に遅延を生じません。CRL 構成の詳細については、ドキュメントの「 Application Load BalancerでのTLSによる相互認証 」のページをご覧ください。 この検証モードでは、ALB がトラストストアを使用してクライアント証明書を検証します。これにより、有効な証明書で認証されたクライアントのみがバックエンドターゲットと通信できます。ALB は、認証されていないユーザーからのリクエストをブロックします。これにより、mTLS 認証に必要な計算負荷の大きな処理を ALB にオフロードし、バックエンドターゲットの処理リソースをアプリケーションサービスの提供に使用できます。図2は、検証モードのアーキテクチャを示しています。 ALB の mTLS 検証モードは以下のステップで検証されます。 [1] CA 証明書バンドルを Amazon S3 にアップロードし、必要に応じて CRL もアップロードします。 [2] トラストストアを作成し、CA 証明書バンドルの Amazon S3 パスを指定します。必要に応じて CRL の Amazon S3 パスも指定します。 [3] クライアントが ALB との TLS セッションを開始します。TLS ハンドシェイク中に、クライアントは TLS 証明書を提示します。 [4] TLS セッションが ALB で終了します。TLS ハンドシェイク中に、ALB はサーバー側の証明書を提示し、クライアントの証明書を受け取ります。 [5] ALB は トラストストアを参照し、証明書を検証します。信頼できない CA によって署名された証明書、証明書失効リスト (CRL) に記載された証明書、有効期限切れの証明書の場合、クライアント認証は失敗します。クライアント認証が失敗する可能性のあるシナリオの完全なリストについては、ドキュメントの「 Application Load BalancerでのTLSによる相互認証 」のページを参照してください。クライアント認証に失敗した場合、ALB は TLS 接続を拒否します。ただし、必要に応じて期限切れの証明書を許可するようALBを設定することができます。 [6] クライアントと ALB 間で TLS セッションが正常に確立されます。 [7] ALB はバックエンドのターゲットとは別のセッションを作成します。 ALB が TLS セッションを終端するため、バックエンドターゲットへのトラフィックの負荷分散には、 ALB のルーティングアルゴリズム を使用できます。例えば、重み付きラウンドロビンルールを使用して、Web アプリケーションのブルーグリーンデプロイメントを作成できます。 クライアント認証を実行するほか、ALB は次の証明書メタデータをバックエンドターゲットに送信します。 X-Amzn-Mtls-Clientcert-Serial-Number – リーフ証明書の16進数表記、クライアント証明書のシリアル番号。例: 0ABC1234。 X-Amzn-Mtls-Clientcert-Issuer – XN_FLAG_RFC2253 フラグを使って X509_NAME_print_ex で印刷された発行者の識別名(DN) X-Amzn-Mtls-Clientcert-Subject – XN_FLAG_RFC2253 フラグを使って X509_NAME_print_ex で印刷された件名 DN X-Amzn-Mtls-Clientcert-Validity – notBefore と notAfter 日付の ISO8601 形式、例: NotBefore=2023-09-21T01:50:17Z; NotAfter=2024-09-20T01:50:17Z X-Amzn-Mtls-Clientcert-Leaf – URLエンコーディングされたPEM形式のリーフ証明書 この情報を使用すると、バックエンドターゲットでこれらのメタデータフィールドに基づいてロジックを実装できます。例えば、X-Amzn-Mtls-Clientcert-Leaf フィールドを解析して証明書の有効期限を取得し、証明書の有効期限が近づいている場合にクライアントにカスタムメッセージを送信できます。 mTLS パススルーモード このモードでは、ALB はクライアント認証のために HTTP ヘッダー AMZN-MTLS-CLIENT-CERT でバックエンドターゲットに証明書チェーン全体を転送します。ALB は、リーフ証明書を含む証明書チェーン全体を、URL エンコーディングされた PEM 形式で、+、=、/ を安全な文字として挿入します。AMZN-MTLS-CLIENT-CERT ヘッダーの例を次に示します。 X-Amzn-Mtls-Clientcert: `-----BEGIN%20CERTIFICATE-----%0AMIID&amp;lt;...reduced&lt;br /&gt;...&amp;gt;do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICAT&lt;br /&gt;E-----%0AMIID1&amp;lt;...reduced...&amp;gt;3eZlyKA%3D%3D%0A-----END%20CERTIFICATE---&lt;br /&gt;--%0A` バックエンドのターゲットは、この HTTP ヘッダーを解析し、証明書を抽出して、クライアント認証を実行できる必要があります。クライアント認証プロセスを制御したい場合は、このモードを使用します。図3がパススルーモードのアーキテクチャです。 図3 : Application Load Balancer の mTLS パススルーモード ALB の mTLS パススルーモードは以下のステップで検証されます: [1] クライアントが ALB と TLS セッションを開始します。 TLS ハンドシェイク中に、クライアントは TLS 証明書を提示します。 [2] TLS セッションは ALB で終了します。 TLS ハンドシェイク中に、ALB はサーバー側の証明書を提示し、クライアントの証明書を受け取ります。 [3] ALB はバックエンドターゲットとの新しいセッションを作成します。このセッションは HTTP または HTTPS のいずれかになり、ユーザー構成に基づきます。 ALB は、AMZN-MTLS-CLIENT-CERT という HTTP ヘッダーに完全な証明書チェーンを含めます。 [4] バックエンドターゲットはクライアント証明書を受け取り、AMZN-MTLS-CLIENT-CERT HTTP ヘッダーからクライアント証明書チェーンを解析するロジックを実装する必要があります。また、ターゲットはクライアント認証を実行するロジックを実装する必要があります。 mTLS パススルーモードが有効な場合、クライアント証明書が存在しないと、ALB は HTTP ヘッダーを追加しません。バックエンドターゲットは、クライアント証明書のない要求を処理するロジックを実装する必要があります。 バックエンドターゲットでクライアント認証に失敗した場合、ターゲットは HTTP エラーコードを ALB に送り返す必要があります。ALB はこのエラーコードをクライアントに転送します。 HTTPS リスナーの場合、バックエンドターゲットはクライアントの証明書に基づいてクライアントを認証し、ALB はクライアントとの間の TLS 接続を終端し、ターゲットとの別の TLS セッションを開きます。ALB とバックエンドターゲットの間の TLS セッションは、 ターゲットにインストールした証明書を使って作成 されます。 ALB が TLS 接続を終端するため、バックエンドターゲットへのトラフィックの負荷分散には ALB のルーティングアルゴリズム を使用できます。 スマートカーが一時的にインターネット接続を失うなど、一部のスマートデバイスは長期間オフラインになる可能性があります。このような場合、バックエンドターゲットには期限切れの TLS 証明書を処理するロジックを実装する必要があります。 パススルーモードを実装するもう1つのユースケースは、アプリケーションベースのクッキー (Cookie) の実装です。この場合、バックエンドターゲットが認証済みクライアントにクッキーを発行し、クライアントはこのクッキーを通信に使用します。これにより、バックエンドターゲットが各要求の証明書チェーン全体を処理する必要がなくなります。オープンソースライブラリを使ってバックエンドターゲットにクッキーを実装し、クッキーに基づいてクライアントの認証ステータスを追跡するロジックを実装できます。 モニタリング ALB は、ロードバランサーに送信されたすべてのリクエストについて、接続ログを提供します。これらのログは Amazon Simple Storage Service(Amazon S3) バケットに送信され、クライアントの IP アドレス、TLS 暗号化の詳細、リクエストが拒否された場合のエラーコードなどの詳細が含まれます。詳細については、「 Application Load Balancer の接続ログ 」を参照してください。 ALB の mTLS サポートに関する CloudWatch メトリクスの完全なリストは、「 Application Load Balancer の CloudWatch メトリクス 」で確認できます。 ALB の mTLS モードと Network Load Balancer (NLB) の比較 HTTPS アプリケーションをお持ちの場合、アプリケーションレベルのルーティングを行いたい場合は、ALB の検討をお勧めします。例えば、HTTPS リクエストに対して重み付きラウンドロビンの負荷分散を実行することで、ブルー/グリーンのようなデプロイメントを作成できます。ALB を使用すると、TLS/mTLS 操作をオフロードすることもできます。ただし、ALB がクライアントの TLS セッションを終了するため、ALB 用の証明書をアップロードする必要があります。 一方、NLB はトランスポート層 (OSIモデルのレイヤー4) で動作し、TCP/UDP コネクションの低レイテンシー負荷分散を提供します。HTTPS アプリケーションの場合、特定のセキュリティコンプライアンスルールによりサーバーがクライアントのTLS 接続を終了する必要がある場合は、Network Load Balancer (NLB) の使用をお勧めします。 表1は、ALB と NLB のパススルーモードと検証モードのサポートを比較し、各オプションの考慮事項を示しています。 &nbsp; ALB + mTLS検証モード ALB + mTLS パススルーモード NLB クライアント認証 ALB で実行、AWS が管理 バックエンドターゲットで実行、お客様が管理 バックエンドターゲットで実行、お客様が管理 クライアントのSSL/TLSセッション終了 ALB で実行、AWS が管理 ALB で実行、AWS が管理 バックエンドターゲットで実行、お客様が管理 ルーティングルール機能 ALB のL7 ルーティングルール ALB のL7 ルーティングルール NLB のポートとプロトコルによるルーティングルール Conclusion この投稿では、Application Load Balancer (ALB) の mTLS 検証モードとパススルーモードについて説明し、各モードを使用する際の考慮事項を議論しました。クライアント認証に ALB を使用したい場合は、ALB で mTLS 検証モードを使用します。バックエンドターゲットでクライアント認証を制御したい場合は、mTLS パススルーモードが最適です。トラストストアを使用するには追加料金がかかり、mTLS を有効にする際には Application Load Balancer の価格を考慮する必要があります。詳細については、 Elastic Load Balancing の価格ページ をご覧ください。 この機能は 2023年11月26日にリリースされましたので、ぜひお試しいただき、ご質問やコメントがあれば、 AWS サポート までお問い合わせください。 本記事は、 Introducing mTLS for Application Load Balancer を翻訳したものです。翻訳は Solutions Architect の 中本 が担当しました。