はじめに Amazon Monitron は機械学習を用いて産業機器の異常な状態を検出し、予知保全を可能にするエンドツーエンドのシステムです。簡単に設置できるハードウェアと機械学習の力で、コストのかかる修理を省き、工場やプラントの機器のダウンタイムを防ぎます。Amazon Monitron の特徴は 製品紹介 をご覧ください。 Amazon Monitron は提供範囲を広げるとともに、お客様からの声を受け止めてたくさんのアップデートを行いました。 このブログでは2023年から2024年初頭までの間に提供された Amazon Monitron のアップデートをまとめて紹介します。 Amazon Monitron デバイスが日本とオーストラリアで販売開始 2023年8月に日本とオーストラリアで Amazon Monitron デバイス (センサー、イーサネットゲートウェイ、Wi-Fi ゲートウェイ) の使用が認定されました。これらのデバイスは、 オーストラリア では Amazon リテール (豪州) 経由で、 日本 では Amazon.co.jp (日本) および Amazon Business (日本) 経由で購入できるようになりました。現在、Amazon Monitron は、米国、カナダ、英国、ドイツ、スペイン、イタリア、オーストラリア、日本で購入いただけます。最新の購入可能地域は Amazon Monitron のよくある質問 をご覧ください。 なお、2024年3月現在、日本の東京リージョン・大阪リージョンでは Amazon Monitron サービスはサポートされていません。 日本国内で Amazon Monitron を利用するには Amazon Monitron をサポートしているリージョン を用いてください。 Amazon Monitron がアジアパシフィック (シドニー) リージョンで利用可能に 2023年8月にAmazon Monitron サービスがアジアパシフィック (シドニー) リージョンでも利用可能になりました。今回のリージョン拡大に伴い、Amazon Monitron は、米国東部 (バージニア北部)、欧州 (アイルランド)、アジアパシフィック (シドニー) の各 AWS リージョンで利用できるようになりました。アジアパシフィックリージョンのお客様は、地理的により近いリージョンで Amazon Monitron サービスを使用できるようになります。このアップデートについての詳細は リリースノート をご覧ください。最新のAmazon Monitron を可能なリージョンは Amazon Monitron のよくある質問 をご覧ください。 ソラコム社 が Amazon Monitron と IoT用LTEルーター、通信プランをセットにした「SORACOM セルラーパック for Amazon Monitron」 を販売開始 「SORACOM セルラーパック for Amazon Monitron」(2024年3月現在の名称) は、Amazon MonitronとSORACOM IoT SIM、その他 Amazon Monitron の導入にあたって必要となる部材一式をセットにしており、設置現場の既設ネットワークに干渉せずに、 Amazon Monitron のスムーズな導入を可能にします。このセットには plan-K2 K2-300MB SIM （サイズ：マルチ・データ通信のみ）と、SORACOM サービス利用料 1,000 円分のクーポン（6ヶ月有効）が付属します。このセットの詳細は ソラコム社へお問合せ ください。 Amazon Monitron が異なるリージョンの IAM Identity Center との連携に対応 2023年11月に Amazon Monitron は異なるリージョンのIAM Identity Center (IIC) との連携に対応しました。Amazon MonitronはMonitronアプリケーションのユーザー管理を行うために IIC を用いる必要があります。 従来、Amazon Monitron はAmazon Monitron を利用するリージョンと同じリージョンで稼働するIICとの連携のみをサポートしていましたが、このアップデートにより、Amazon Monitron が稼働するリージョンと異なるリージョンで稼働する IICと連携することができます。 このアップデートにより、例えば日本のような Amazon Monitron サービスがまだサポートしていないリージョンで既に IIC を利用しているお客様が Amazon Monitron を利用することが容易になりました。 詳細は Amazon Monitron ユーザーガイド をご覧ください。 振動に関するISO 20816規格に基づいた Class 1~4 のデフォルトクラスに加えて、「カスタムクラス」としてしきい値を独自に設定可能に 2023年12月にアセットクラスに「カスタムクラス」が追加されました。従来、振動に関する閾値ベースの判定は ISO 20816規格に基づいた Class 1 – 4 の4段階のアセットクラスから選択いただくことができました。各アセットクラスに応じてしきい値が固定に設定されており、しきい値に応じて Warning やアラームを発生させます。今回カスタムクラスが追加されたことにより、アセットタイプが Amazon Monitron が提供するデフォルトのアセットクラスと一致しない場合には、カスタムクラスを作成することができます。これにより、Warning やアラームを発生させる条件となるしきい値をカスタマイズすることが可能となりました。 詳細は A mazon Monitron のドキュメント をご覧ください。なお、ISO 20816 規格の詳細は、builders.flashの記事「 機械振動の測定と評価規格「ISO 20816」とは ? 」をご覧ください。 Amazon Monitron が他のAWSサービスと連携するためのデータストリーミング仕様が Ver.2 に更新 2023年4月にAmazon Monitron の Kinesis 2.0 データストリームがリリースされました。これはスキーマを更新したものであり、Monitron センサーとゲートウェイを使用する新しいインサイトを含みます。また、ユーザーによってトリガーされるアセット状態の移行イベントも含みます。この新しいスキーマは、今後追加されるデータタイプを受け取れます。Amazon Monitron が自動的に データを Kinesis ストリームに追加する ように設定すると、そのデータを Amazon S3 や Lambda など、さまざまな宛先に送信できます。 今回のローンチにより、センサーとゲートウェイデバイス、接続ステータス、ユーザークロージャコードを、ライブストリームから収集できるようになりました。Monitron サービスがいずれかのセンサーまたはゲートウェイがオフラインになったことを検出すると、接続ステータスによってお客様は Kinesis の更新情報を受け取れます。ユーザークロージャコードを使用すると、お客様は Monitron の通知に対するユーザーの応答を追跡できます。これにより、障害モードや実行したアクション全体にわたる共通事項のレポートが可能になります。この機能により、自社のエンタープライズ設備管理 (EAM) システムで保守チームの作業指示書を作成することもできます。 この機能の詳細については、 こちらのドキュメント を参照してください。 Amazon Monitron、防爆構造の Ex 規格センサーを発売 2023年11月に Ex 規格の Amazon Monitron センサーの発売を発表いたしました。これらの Ex 規格のセンサーは、米国、カナダ、英国、EU での使用が認定されており、 Amazon.com (米国) および Amazon Business (米国) で購入できます。 お客様は、これらの Ex 定格のセンサーを設置することで、Monitron を使用して危険な場所 (ガス、クラス 1 / ゾーン 2) にある資産を監視できるようになりました。2024年3月現在、上記以外の国ではEx 規格センサーを購入・利用はできません。詳細は リリースノート と データシート をご覧ください。 Amazon Monitron で、プロジェクトレベルとサイトレベルでのコスト可視化のサポートを開始 2023年12月に Amazon Monitron のお客様が、使い慣れた AWS Cost Explorer コンソールを使用して、プロジェクトレベルおよびサイトレベルでソフトウェアの請求を視覚化する機能をリリースしました。こののリリースにより、センサーの使用コストを、プロジェクトやサイトなど、Monitron の管理する階層内のリソースに正確に割り当てることができます。お客様は、プロジェクトレベルの請求を活用して、組織ごとにコストを配分できるようになりました。また、サイトレベルできめ細かな使用状況をよりよく把握できます。全体として、これらの機能により、組織ごとに Monitron ソフトウェアのコストをさまざまな業務にわたってより適切に最適化し、配分することができます。このアップデートの詳細は リリースノート をご覧ください。 Amazon Monitron でゲートウェイのネットワーク設定に静的 IP が使用可能に 2024年2月に、新たに設定するゲートウェイで静的 IP を使用できるようになりました。これにより、お客様はファイアウォールにきめ細かなルールを設定して、ドメイン名ではなく特定の IP アドレスをフィルタリングできます。これらのアドレス ( このドキュメントページ を参照) は静的で、Amazon Monitron を使用するリージョンのみに従属するため、ファイアウォールルールで IP アドレスを最大 3 つまで簡単に許可リストに追加できます。 従来、ファイアウォールによる保護を利用しているお客様は、工場に設置されたセンサーと AWS クラウドとの間でこの通信ができるようにするために、 amazonaws.com のサブドメイン全体を許可リストに登録する必要がありました。セキュリティ上の理由から、全ドメイン/サブドメインを許可リストに登録したくないお客様やファイアウォールの設定機能に制限があるために難しいと感じるお客様はAmazon Monitronの導入が容易になりました。詳しくは リリースノート をご覧ください。 Amazon Monitron を使い始めるには これから Amazon Monitron を使い始める日本のお客様のために、日本のソリューションアーキテクトが解説する短いオンラインセミナーを用意しました。このオンラインセミナーを視聴して、お客様の設備での検証を初めてください。 Amazon Monitron Part 1（基本編）【AWS Black Belt】 Amazon Monitron Part 2（設定編）【AWS Black Belt】 Amazon Monitron Part 3（サービス連携編）【AWS Black Belt】 おわりに Amazon Monitron は機械学習を用いて産業機器の異常な状態を検出し、予知保全を可能にするエンドツーエンドのシステムです。Amazon Monitron は2023年から2024年初頭までの間にお客様からの声を受け止めてたくさんのアップデートを行いました。 このブログでは提供された Amazon Monitron のアップデートをまとめて紹介しました。 このブログは Amazon Web Services Japan のソリューションアーキテクト 吉川晃平 が執筆しました。

Azure SQL Managed Instance から Amazon Web Services (AWS) の SQL Server へ、Azure SQL Managed Instance のコピーのみのバックアップを使用して Microsoft SQL Server データベースを移行できることをご存知ですか？この方法を使用すると、データベース内のすべてのオブジェクトをコピー/移動するため、手順は簡単で、すべてのエディションをサポートします。ただし、この方法はフルバックアップとリストアのみをサポートし、差分バックアップやトランザクションログのバックアップはサポートしていないことに注意してください。移行中の変更差分をキャプチャするために使用できる方法は他にもあります。 このブログ記事では、Azure SQL Managed Instance の最新機能である SQL Server 2022 への バックアップの移植性 も含め、SQL Server データベースを Azure SQL Managed Instance から AWS の SQL Server に移行するさまざまな方法について説明します。 Azure SQL Managed Instance から AWS への移行の理由 Azure SQL Managed Instance は最新の SQL Server 2022 データベースエンジンと互換性のあるフルマネージドプラットフォームですが、SQL Server 2022 のコピーのみのバックアップを使用して AWS に移行する利点があります。まず、インフラストラクチャのより高い柔軟性と管理を提供します。ニーズに最適なインスタンスタイプ、ストレージオプション、ネットワーク構成を選択できます。追加のソフトウェアをインストールしたり、特定のパフォーマンス最適化を適用したり、環境全体をより細かく制御できます。もう一つの重要な側面はコスト削減です。 Amazon Elastic Compute Cloud (Amazon EC2) 上の SQL Server に移行することで、ライセンスコストを節約し、Amazon EC2 の高可用性オプションを活用できる可能性があります。 Azure SQL Server Managed Instance から AWS への移行には、以下の 3 つの異なる方法があります。 SQL Server のバックアップと復元 (COPY_ONLY) AWS Database Migration Service  (AWS DMS) SQL Server インポートおよびエクスポートウィザード ソリューション概要 図 1 のソリューションアーキテクチャ図は、SQL Server データベースを AWS に移行する 3 つの方法を示しています。 図 1 : Azure SQL Managed Instance から AWS 上の SQL Server への移行オプション Azure SQL Managed Instance から AWS への移行には、複数のオプションがあります。Amazon EC2 上の SQL Server または Amazon Relational Database Service (Amazon RDS) for SQL Server に移行できます。表 1 は、このブログ記事で説明している 3 つの移行オプションの機能を比較したものです。課題と利点を理解することで、ニーズに適した方法を判断し、全体的な移行目標と整合させることができます。 表 1 : Azure SQL Managed Instanceと AWS オプションの比較 * 詳細は AWS DMS のドキュメントを参照してください。 前提条件 Azure ストレージアカウント Azure SQL Managed Instanceでホストされている SQL Server ソースデータベース Amazon EC2 上の SQL Server 2022 があるアクティブな AWS アカウント AWS と Azure 間のネットワーク接続 (VPN、プライベートネットワーク、インターネット) SQL Server Management Studio (バージョン 19.0.1 以降) 方法 1. SQL Server のコピーのみのバックアップを使用した移行 Azure SQL Managed Instance から Amazon EC2 上の SQL Server へのデータベースの移行は、Azure SQL Managed Instance の コピーのみのバックアップ を使用して実行できます。この方法を利用すると、Azure のマネージドインスタンス から SQL Server 2022 インスタンス (Enterprise、Developer、Standard エディション) へ、データベースオブジェクトを含むすべてのデータベースを簡単にコピーまたは移動できます。この移行方法では、フルバックアップとリストアのみをサポートしており、差分バックアップやトランザクションログバックアップはサポートしていません。ソース SQL Server から AWS 上のターゲット SQL Server へ、SQL Server の ログイン を転送する必要があります。 注 : Azure SQL Managed Instance のコピーのみのバックアップ方法は Transparent Data Encryption (TDE) をサポートしていません 。移行前に、ソースの SQL Server データベースと証明書をバックアップし、TDE を無効にします。TDE を無効にすると、リソースを大量に消費する操作になる可能性があります。このアクティビティはピーク時以外に計画してください。移行後に Amazon EC2 上の SQL Server データベースで TDE を有効にすることができます。 ソースとターゲットの SQL Server データベースが接続されていることを確認してください。Amazon EC2 からソースの Azure SQL Server Managed Instance に接続してバックアップを実行できます。 移行を実行する手順は次のとおりです。 1.1. Azure portal にログインし、Azure ストレージアカウントに移動します。 1.2. 図 2 に示すように、Azure ストレージアカウントに Azure BLOB ストレージコンテナーを作成します。 図 2 : Azure BLOB ストレージでのコンテナーの作成 1.3. 図 3 に示すように、Azure ストレージコンテナー用の Shared Access Signature (SAS) トークン を作成する必要があります。 図 3 : ストレージコンテナの共有アクセストークンの作成 1.4. 次に、SQL Server Management Studio (SSMS) を使用して、 Azure SQL Server Managed Instance に接続します。手順 1.3 の SAS トークンを使用して、図 4 のスクリプトを使用して Azure BLOB Storage へのアクセスを許可する認証情報を作成します。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 4 : 認証情報の作成 1.5. 認証情報を作成したら、図 5 のスクリプトを使用して、COPY_ONLY バックアップコマンドを実行し、 Azure BLOB Storage にデータベースの完全バックアップを実行する必要があります。Azure SQL Managed Instanceでは、バックアップコマンドの COPY_ONLY オプションのみが提供されています。 BACKUP DATABASE [AzureSQLMIBackuptest] TO URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfulll.bak' WITH COPY_ONLY 図 5 : COPY_ONLY を使用したデータベースのバックアップ 1.6. SSMS を使用して Amazon EC2 上の移行先 SQL Server 2022 に接続し、Azure SQL Blob ストレージ用の図 6 のスクリプト (手順 1.3 で作成した共有アクセストークンを使用する) を使用して認証情報を作成できます。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 6 : Amazon EC2 上のターゲット SQL Serverで認証情報を作成 1.7. 認証情報が作成されたら、Amazon EC2 上の SQL Server の宛先で、図 7 のスクリプトを使用して restore database コマンドを実行する必要があります。 RESTORE DATABASE AzureSQLMIBackuptest FROM URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfull.bak' WITH MOVE 'data_0' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_data_0.mdf', MOVE 'log' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptestlog.ldf', MOVE 'XTP' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_xtp.xtp' 図 7 : Amazon EC2 上のターゲット SQL Server へのデータベースのリストア 1.8. 次に、図8に示すように、Amazon EC2上のターゲット SQL Server で SSMS を使用して、リストアされたデータベースが利用可能であることを検証します。 図 8 : EC2 上の SQL Server にリストアされた Azure SQL Managed Instance SQL Server のバックアップとリストアの方法はフルバックアップのみを提供するため、この方法ではデータベースのサイズに応じてダウンタイムが必要になります。 方法2. AWS DMS を使用した移行 Azure SQL Server Managed Instance データベース上でミッションクリティカルなワークロードを実行していて、ダウンタイムを最小限に抑えて AWS に移行する必要がある場合は、 AWS Database Migration Service (AWS DMS) を使用できます。AWS DMS は、 SQL Server のバックアップとリストア 方法と組み合わせて、Azure SQL Managed Instance から Amazon EC2 上の SQL Server へ SQL Server データベースを移行できます。 AWS DMS を使用することで、Azure SQL Managed Instance から Amazon RDS for SQL Server へのダウンタイムを最小限に抑えたフルロードや変更データキャプチャ (Change Data Capture、CDC) によるマイグレーションができます。 AWS DMS は変更の追跡に MS-Replication または MS-CDC を使用します。 詳細は AWS DMS の ドキュメント を確認してください。 AWS DMS を使用した移行の手順は以下のとおりです。 2.1. まず、図 9に示すように、ソースの Azure SQL Server Managed Instance データベースとテーブルで CDC を有効にします。 図 9 : Azure SQL Server Managed Instance ソースデータベースの CDC の有効化 2.2. 次に、図 10に示すように、 AWS DMS レプリケーションインスタンス を作成します。 図 10 : AWS DMS でレプリケーションインスタンスの作成 2.3. ソースエンドポイントとして Azure SQL Managed Instance を作成する必要があります。「エンドポイント設定」コンソール画面で「接続のテスト」を選択することで、ソースエンドポイントからレプリケーションインスタンスへの 接続性をテスト できます。接続性が正しく設定されていることを確認してください。詳細は AWS DMS のドキュメントを参照してください。 図 11 : Azure SQL Managed Instance をソースとした AWS DMS エンドポイント設定 2.4. ソースエンドポイントが作成された後、ターゲットの SQL Server エンドポイントを作成します。 次に、図12に示すように、「エンドポイント設定」コンソール画面の「接続テスト」を選択することで、ターゲットエンドポイントからレプリケーションインスタンスへの 接続性をテスト します。 接続性が正しく設定されていることを確認してください。 図 12 : EC2 上の SQL Server をターゲットとした AWS DMS エンドポイント設定 2.5. AWS DMS タスクを作成するには、手順 2.3 と 2.4 で設定したソースからターゲットへのエンドポイントを選択します。図 13 に示すように、継続的なレプリケーションのために「既存のデータを移行して、継続的な変更をレプリケートする」移行タイプを選択します。 図 13 : AWS DMS マイグレーションタスクの設定 2.6. 次のステップはレプリケーションタスクをモニタリングすることです。図 14 は AWS DMS タスクの進捗を示しています。両方のデータベースが同期されたら、Amazon EC2 上のターゲット SQL Server への切り替え作業を実施し、ダウンタイムを最小限に抑えて移行を完了することができます。 図 14 : DMS レプリケーション概要ページからの AWS DMS 移行タスクのステータス進捗レポート この移行方法の詳細については、このブログ記事 AWS DMS を使用した SQL Server データベースの移行 をお読みください。 方法3. SQL Server インポートおよびエクスポートウィザードを使用した移行方法 Azure SQL Managed Instance から Amazon EC2 上の SQL Server への移行に、SQL Server のインポートおよびエクスポートウィザードを使用できます。これは、小規模なデータベースを使用している場合や、部分的なデータ移行を実行したい場合、移行中にデータ変換を必要とする場合に適しています。 ソースとターゲットの SQL Server データベース間の接続性を確保する必要があります。 Amazon EC2 からソースの Azure SQL Server Managed Instance に接続して、手順を実行できます。 SQL Server インポートおよびエクスポート ウィザードを使用して移行する手順は次のとおりです。 3.1. SQL Server Management Studio(SSMS)を使用して、Azure SQL Managed Instanceに接続します。 3.2. ソースデータベースを右クリックし、[タスク] – [データのエクスポート] を選択します。 図 15 に示すように、Microsoft OLE DB Driver for SQL Server を使用して、Azure SQL Managed Instance の接続詳細を指定します。 図 15: SQL Server インポートおよびエクスポート ウィザードのソースの選択 3.3. 次に、図16 に示すように、ターゲットサーバーとして Amazon EC2 上の SQL Server 2022 の接続情報を指定します。 図 16 : SQL Server インポートおよびエクスポート ウィザードのターゲットの選択 3.4. ソース接続とターゲット接続の両方をテストし、接続が機能していることを確認してください。 3.5. 移行するソーステーブルとビューを選択し、マッピングが期待どおりであることを確認して、データを移行するためにOKをクリックしてください。 図 17 : SQL Server インポートおよびエクスポート ウィザードの進捗レポート 3.6. SSMSを介してターゲットのSQL Serverに接続することで、インポート後のデータを検証してください。アプリケーションをテストおよび検証し、期待どおりに機能していることを確認してください。 この移行方法の詳細については、 他の方法による SQL Server データのインポートとエクスポート の一括コピーのセクションをご確認ください。 まとめ このブログ記事では、Azure SQL Server Managed Instance から Amazon EC2 上の SQL Server への移行について、3つの異なるオプションを紹介しました。 SQL Server 2022 のネイティブなバックアップとリストア機能を利用して、AWS 上の SQL Server 2022 へ移行することができます。 ダウンタイムを最小限に抑えたニアリアルタイムの移行を実現したい場合は、AWS DMS の利用を検討してください。 小規模なデータベースや、テーブル、ビューなどの特定のオブジェクトの部分的な移行を実行したい場合は、SQL Server インポートおよびエクスポートウィザードの利用を検討してください。 Azure SQL Managed Instance から AWS への SQL Server データベースの移行でダウンタイムを最小限に抑えるには、 AWS Marketplace の CloudBasic を利用 することもできます。 その他の方法を使用した SQL Server の移行に関する詳細は、 オンプレミスのMicrosoft SQL Server データベースを Amazon RDS for SQL Server に移行する(英文) をご覧ください。 SQL Server ワークロードの移行およびモダナイゼーションのオプションを現在評価している場合、SQL Server 2022 を含め、お問い合わせください。SQL Server の計画と活動を支援させていただきます。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 TAGS: SQL Server , SQL Server 2022 Yogi Barot Yogi はプリンシパルソリューションアーキテクトであり、さまざまなマイクロソフトテクノロジーを扱った 22 年の経験があります。彼女の専門は SQL Server とさまざまなデータベーステクノロジーです。Yogi には AWS でのマイクロソフトワークロードの実行に関する深い知識と専門知識があります。 Rita Ladda Rita Ladda は、アマゾン ウェブ サービスのマイクロソフト スペシャリスト シニアソリューション アーキテクトであり、多くのマイクロソフトテクノロジーで 20 年以上の経験があります。 彼女は、SQL Server およびその他のデータベースのデータベース ソリューションの設計を専門としています。 彼女は、Microsoft ワークロードの AWS への移行とモダナイゼーションにおけるアーキテクチャに関するガイダンスを顧客に提供しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 2024 年 3 月 21 日に、 AWSome Day Online Conference が開催されます。時間は、 10:00~13:00、14:00~17:00 の 2 パターンから参加しやすい方を選択いただけます。クラウドジャーニーのはじめの一歩として、AWS クラウドに関する基礎知識を 3 時間で学ぶ無償の初心者向けオンラインイベントです。クラウドに関する事前知識は必要ありません。クラウドそのものの解説からはじまり、EC2、Lambda、RDS、IoT など多くの AWS サービスを幅広く学習いただけます。是非ご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024 年 3 月 4 日週の主要なアップデート 3/4(月) Anthropic’s Claude 3 Sonnet model now available on Amazon Bedrock Amazon Bedrock で新たなモデルの Claude 3 を提供する旨がアナウンスされました。Claude 3 には 3 つのモデルがあり、3 つの中で最速の出力を行い軽量な利用向けの Claude 3 Haiku、スキルとスピードのバランスのとれた Claude 3 Sonnet、トップレベル向けの最もインテリジェントな Claude 3 Opus です。既に Sonnet は、オレゴンと北部バージニアリージョンで利用可能で、残り 2 つは Coming Soon です。パフォーマンス・精度・信頼性の向上、ハルシネーションの軽減、ビジョン機能の追加などの特徴があります。ビジョン機能は画像を与えることで、画像の内容を読み取り出力を得られます。個人的に面白いと感じたのが、AWS のアーキテクチャ画像を与えて、レビューを依頼する使い方です。「可用性、拡張性、コスト最適化、セキュリティの 4 つの柱をより強く意識してアーキテクチャレビューをしてください」といったプロンプトを与えると、100 点満点ではないですが、比較的妥当な結果が得られました。一部、誤った結果が出る可能性は 0 ではないので、その点も留意して試してみてください。Claude 3 についての詳細は こちらのブログ をご確認ください。 AWS WAF enhances rate-based rules to support configurable time windows AWS WAF のレートベース機能でリクエストを集計する期間を変更できるようになりました。レートベースでは、受信リクエストをカウントし、レートが高い場合にはリクエストを制限します。例えば、特定の IP アドレスからのアクセスが、一定期間に 10,000 回以上のものを対象にブロックできます。これまでは集計期間が 5 分固定でしたが、1 分、2 分、10 分を指定できるようになりました。 Amazon FSx for NetApp ONTAP doubles maximum throughput capacity to 72 GBps Amazon FSx for NetApp ONTAP でファイルシステムあたりの最大スループット容量が 2 倍に増加しました。以前は、最大 36 GB/秒の読み取りスループットと 6 GB/秒の書き込みスループットを実現する最大 6 つの HA ペアを使用してファイルシステムを作成できました。現在では、最大 12 HA ペアでファイルシステムを作成でき、最大 72 GB/秒の読み取りスループットと 12 GB/秒の書き込みスループットを実現できるようになり、より高性能な ONTAP ワークロードを AWS に移行できるようになりました。 3/5(火) Free data transfer out to internet when moving out of AWS AWS のサービスをご利用のお客様にご満足いただけるよう努めています。しかし、何らかの事情により他のプラットフォームへ移行しなければいけない場合もあります。このような状況に対応するため、他のプラットフォームへ移行時にアウトバウンドデータ転送を無料にするようリクエストできる仕組みを提供しました。この仕組みを利用するには、担当の営業にご連絡いただくか、担当がいない場合は AWS サポートまでお問い合わせください。詳細は こちらの FAQ をご覧ください。 Amazon ECS adds gMSA authentication for Linux containers for AWS Fargate Amazon ECS on Fargate で動かしている Linux コンテナで、グループマネージドサービスアカウント (gMSA) がサポートされ、Windows 認証を使用しているアプリケーションを動かしやすくなりました。gMSA は Windows 認証周りを支援する機能です。一例を挙げると、アプリケーションから SQL Server や Windows ファイルサーバーへアクセスする際に、Active Directory と連携して、アクセスがしやすくなります。アップデート以前は Linux コンテナで gMSA を利用するために、ECS on EC2 を利用する必要がありましたが、今回のアップデートで ECS on Fargate で利用ができます。 3/6(水) Amazon RDS now supports io2 Block Express for consistent sub-millisecond latency and 99.999% durability Amazon RDS で高性能ストレージ io2 Block Express ボリュームの提供を開始しました。ミッションクリティカルなワークロードに対して一貫したサブミリ秒単位のレイテンシーを提供します。io2 Block Express は 99.999% の耐久性、最大 64 TiB ボリューム、4,000 MB/秒のスループットをサポートします。また、ModifyDBInstance APIを使用して、ダウンタイムなしで io1 ボリュームから io2 Block Express ボリュームにアップグレードできます。 Amazon EC2 C7gd, M7gd, and R7gd metal instances are now available Amazon EC2 で、最大 3.8 TB のローカル NVMe SSD ストレージを搭載した C7gd、M7gd、R7gd ベアメタルインスタンスの一般提供を発表しました。これらのインスタンスは、同等の Graviton2 ベースのインスタンスと比較して、NVMe ストレージ性能が最大 45 % 向上しています。AWS Nitro System 上に構築されており、一時ファイル、キャッシュなどのデータの一時的な保存を必要とするアプリケーションを含め、高速で低レイテンシーのローカルストレージへのアクセスを必要とするアプリケーションに最適です。東京含め 13 リージョンで提供されています。 Introducing the AWS Generative AI Competency Partners AWS パートナー関連のアップデートです。AWS Generative AI コンピテンシーの開始を発表しました。これは、AWS で生成 AI を実装する際の技術的な習熟度を示しており、お客様との継続的な成功を収めてきた実績がある AWS パートナーが対象として選ばれています。これらのパートナーは、Amazon Bedrock、Amazon SageMaker Jumpstart、Amazon CodeWhisperer、AWS Trainium、AWS Inferentia などの生成 AI 関連テクノロジーを活用する実績があります。 詳細はこちら からご覧ください。 3/7(木) Amazon Managed Grafana launches Enterprise plugins upgrade Amazon Managed Grafana で Grafana Enterprise へ直接アップグレードを行う機能が提供されました。これにより、Grafana Enterprise で提供されているプラグイン (ServiceNow、Splunk、New Relic など) にアクセスできるだけではなく、Grafana Labs からのサポートとトレーニングも可能になります。アップデート以前は、AWS Marketplace から Grafana Enterprise をサブスクライブすることで Enterprise Plugin にアクセスできましたが、今回のアップデートで、AWS マネジメントコンソールから直接サブスクライブできるようになりました。前払い料金や最低契約は不要で、アップグレードされたワークスペースあたりのアクティブユーザー数に基づいて使用した分のみ料金が発生します。 プラグインの一覧はこちら をご確認ください。 Announcing new Amazon VPC DHCPv6 setting to adjust IPv6 preferred lease time Amazon VPCの DHCP オプションセットに「IPv6 preferred lease time」と呼ばれる機能が追加され、IPv6 アドレスを DHCP で配布 (リース) する際に、リースの更新期間を調整できるようになりました。Amazon EC2 インスタンスは DHCP リース更新を定期的に行い、IPv6 アドレス割り当てを行います。デフォルトで、「IPv6 preferred lease time」は 140 秒となっており、DHCP リース更新処理は、140 秒の半分である 70 秒ごとに実行されます。この期間を長く調整することで、IPv6 リースの更新回数を最小限に抑え、万が一の更新に失敗する可能性を低減できます。 3/8(金) AWS announces Aurora MySQL integration with Amazon Bedrock for Generative AI Aurora MySQL 3.06 バージョンの Amazon Aurora ML 機能で、SQL で直接 Amazon Bedrock にアクセスできるようになりました。Amazon Aurora MLはモデルを SQL 関数として公開し、標準 SQL を使用してモデルにデータを渡したり、クエリ結果としてモデルの出力を返すことができます。データベース内で Bedrock へのアクセスがシンプルに実現でき、独自のインテグレーションなどのカスタマイズの負担を軽減できます。例えば、 SELECT invoke_titan(request) FROM prompts; といった SQL クエリーを投げることで、Bedrock から出力されたテキストを SELECT で取得できます。詳細は こちらの Document をご覧ください。 AWS WAF now supports larger request body inspections for regional resources AWS WAF でリージョナルリソース (API Gateway、Cognito User Pool、App Runner、Verified Access) に紐づけて検査する際、受信リクエストのサイズ上限が 64 KB に緩和されました。 元々 AWS WAF は、最大検査サイズの上限が 8 KB でした。CloudFront は 2023 年に 64 KB まで上限が緩和されていますが、それにリージョナルリソースが追いついた形です。一方、留意点として、ALB と AppSync はこのアップデートの対象外となっています。また 16 KB を越えて上限を緩和する設定を実施した際に、追加の料金が発生するようになります。 料金の詳細 はこちらをご覧ください。 Application Load Balancer now supports Resource Map in AWS Management Console Application Load Balancer (ALB) でリソースマップをサポートし、AWS マネジメントコンソール上で、ALB とそれに紐づくターゲットグループや EC2 インスタンスなどの関連リソースを視覚的に確認ができるようになりました。ALB の詳細画面に「Resource map 」タブが新規に追加され、簡単に確認ができます。 最後に、週刊AWS のサムネイルの写真を更新しました。今までは小林さん、下佐粉さんの写真でしたが、2023 年の夏頃に新たに参加した根本さんと杉山も含め、4 人の写真にアップデートしました (少し恥ずかしいですが・・・)。これからもよろしくお願いします。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

はじめに 昨今、多くのお客様はインフラストラクチャのデプロイとメンテナンスに関する手動運用を減らしたいと考えています。 AWS でインフラストラクチャをデプロイしたり運用したりするためには、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 Terraform のようなツールを利用した Infrastructure-As-Code (IaC) モデルを採用することが推奨されます。 Terraform を利用する上では、インフラストラクチャの設定やリソースを追跡するための State ファイルの管理がとても重要な要素となります。 AWS 上の CI/CD パイプライン で Terraform を実行する場合、State ファイルはパイプラインからアクセスできる共通の安全なパスに保存する必要があります。 チームの複数の開発者が同時にアクセスしようとすることを想定して、State ファイルをロックするメカニズムも必要です。 このブログ記事では、AWS で Terraform の State ファイルを管理する方法とその設定のベストプラクティス、および AWS CodeCommit や AWS CodeBuild などの AWS デベロッパーツールを利用した継続的インテグレーションパイプラインにおける効率的な管理の例について説明します。このブログ記事は、Terraform、AWS デベロッパーツール、AWS 上での CI/CD パイプラインに関する基本的な知識のある読者を想定しています。では始めましょう! State ファイルの取り扱いにおける課題 デフォルトでは、State ファイルは Terraform を実行するローカル環境に保存されます。これは、デプロイメントの作業をする開発者が 1 人だけの場合は大きな問題とはならないでしょう。しかしそうでない場合は、次のような問題が発生する可能性があるため、State ファイルをローカルに保存することは推奨されません。 チームで協力して作業する場合、複数の人が State ファイルにアクセスする必要がある State ファイル内のデータはプレーンテキストで保存されるが、そこには機密情報やセンシティブな情報が含まれる可能性がある ローカルファイルは紛失したり、破損または削除される可能性がある State ファイルの取り扱いにおけるベストプラクティス Terraform の組み込み機能としてサポートされているリモートバックエンド機能を利用して State ファイルをリモート管理することが推奨されます。 Amazon Simple Storage Service(Amazon S3) 上のリモートバックエンド: 耐久性とスケーラビリティに優れたストレージである Amazon S3 バケットに State ファイルを保存するように Terraform を設定できます。Amazon S3 に保存することで、State ファイルを他のユーザーと共有してコラボレーションすることも可能になります。 Amazon S3 上のリモートバックエンドと Amazon DynamoDB の利用 : Amazon S3 バケットを利用してファイルを管理することに加え、 Amazon DynamoDB テーブルを利用してState ファイルのロックを管理することもできます。特定の State ファイルを変更できる人を常に 1 人だけに限定してコンフリクトを回避し、State ファイルへの同時アクセスを安全に制御できます。 他にも Terraform Cloud 上のリモートバックエンドやサードパーティのバックエンドなどの選択肢があります。 AWS 上で Terraform State ファイルを管理するためにどんな方法が最適かは、固有の要件によって異なるといえるでしょう。 AWS 上で Terraform を利用してデプロイする際に、State を管理するために Amazon S3 と Amazon DynamoDB を使用する方法はお勧めの選択肢です。 State ファイルの管理のための AWS 設定 Terraform を利用して Amazon S3 バケットを作成します。 AWS Identity and Access Management (AWS IAM) ポリシー や Amazon S3 バケットポリシー を設定して Amazon S3 バケットのセキュリティ対策を実装します。アクセスを制限したり、データの保護やリカバリーのためにオブジェクトのバージョニングを設定したり、SSE-KMS を利用した AES256 暗号化を有効にしたりできます。 次に、Terraform を利用して、パーティションキーを LockID に設定した Amazon DynamoDB テーブルを作成します。読み取りキャパシティユニット/書き込みキャパシティユニットなどの追加の構成オプションも設定できます。テーブルが作成されたら、設定ファイルの中の terraform ブロックでテーブル名を指定して、State ロックでそのテーブル使用するように Terraform バックエンドを構成します。 単一の AWS アカウントの中に複数の環境やプロジェクトが存在している場合、単一の Amazon S3 バケットでそれらの State の管理ができます。 複数の AWS アカウントにまたがって環境やアプリケーションが存在するような場合は、アカウントごとに Amazon S3 バケットを作成して State の管理ができます。 この Amazon S3 バケット内で環境ごとに適切なフォルダを作成し、個別にプレフィックスを付加して State ファイルを格納できます。 AWS で Terraform の State ファイルを扱う方法がわかったので、次は AWS 上の 継続的インテグレーション パイプラインでこれらを設定する例を見ていきましょう。 アーキテクチャ 図1: AWS 上の CI パイプラインで Terraform を使用するサンプルアーキテクチャ この図は、このブログで実装されるワークフローの概要を示しています。 AWS CodeCommit リポジトリでコードを管理する (ここには Lambda などのアプリケーションのコードも含まれる) AWS CodeBuild ジョブは どの buildspec ファイルを使うかの設定を保持しており、AWS CodeCommit のソースコードを参照して動作する terraform apply の実行によって作成された AWS Lambda 関数には、同じリポジトリで管理されたアプリケーションコードが実装される Amazon S3 には terraform apply の実行で作成された State ファイルが保存される Amazon DynamoDB は Amazon S3 にある State ファイルのロックを管理する 実装 前提条件 始める前に、次の前提条件を満たしている必要があります。 AWS Command Line Interface(AWS CLI) の最新バージョンが インストール されている Terraform の最新バージョンが インストール されている Git の最新バージョンが インストール されており git-remote-codecommit がセットアップ されている 使用するAWS アカウントの準備ができている (既存の AWS アカウント、もしくは 新規作成 ) ローカルターミナルから AWS アカウントにアクセスできるように AWS IAM や AWS CLI の設定 がされている 環境の設定 AWS CLI を設定するには、AWS アクセスキー ID とシークレットアクセスキーが必要です。AWS CLI の設定の詳細については、 こちらの説明 を参照してください。 次のコマンドで、サンプルコード全体を含むリポジトリをクローンしてください。 git clone https://github.com/aws-samples/manage-terraform-statefiles-in-aws-pipeline クローンすると、次のようなフォルダ構成が確認できます。 図2: AWS CodeCommit リポジトリ構成 Terraform のコードを 2 つのパートに分けてみましょう。1 つはインフラストラクチャの準備用、もう 1 つはアプリケーションの準備用です。 インフラストラクチャの準備 main.tf ファイルは以下を行うコアコンポーネントです。 State ファイルを保存するための Amazon S3 バケットを作成します。バケットの ACL、バージョニング、暗号化を設定することで、 State ファイルをセキュアに管理することができます。 State ファイルをロックするために使用する Amazon DynamoDB テーブルを作成します。 2 つの AWS CodeBuild プロジェクトを作成します。1 つは terraform plan を実行するもので、もう1 つは terraform apply を実行するものです。 注記: 後で使用する AWS Lambda を作成するコードブロック(デフォルトではコメントアウトされている)も含まれています。 AWS CodeBuild プロジェクトは、Amazon S3、Amazon DynamoDB、AWS CodeCommit、AWS Lambda にアクセスできる必要があります。 これらのリソースにアクセスするために必要な権限を持つ AWS IAM ロールを iam.tf ファイルで作成します。 terraform コマンド terraform plan と terraform apply をそれぞれ実行する buildspec-plan.yaml と buildspec-apply.yaml という 2 つの buildspec ファイルがあります。 provider.tf ファイル内の AWS リージョンの設定を変更します。 (翻訳者補足: 作業中のAWS 環境に合わせて、必要であれば変更してください。) variable.tf ファイルで、Amazon S3 バケット名、Amazon DynamoDB テーブル名、AWS CodeBuild コンピュートタイプ、AWS Lambda ロールとポリシー名を必要な値に更新します。このファイルを使って、さまざまな環境に合わせてパラメーターを簡単にカスタマイズすることができます。 これでインフラストラクチャの設定は完了です。 (翻訳者補足: この時点では、 backend.tf には local バックエンド が設定されている必要があります。念のため、設定をご確認ください。) ローカルターミナルを使用して以下のコマンドを順番に実行すると、上記のリソースを AWS アカウントにデプロイできます。 terraform init terraform validate terraform plan terraform apply terraform apply が成功してAWS アカウントに上記のすべてのリソースが正常にデプロイできたら、アプリケーションのデプロイに進みましょう。 アプリケーションの準備 クローンしたリポジトリで、 backend.tf ファイルを使用して、 State ファイルを保存するための独自の Amazon S3 バックエンドを作成します。デフォルトでは以下の値が設定されます。必要に応じてこれらの値を更新します。 (翻訳者補足: ここでは「インフラストラクチャの準備」のセクションで作成した s3 バケットを指定してください。リージョンも同セクションにて provider.tf ファイルで変更している場合は同じ設定にしてください。) bucket = "tfbackend-bucket" key     = "terraform.tfstate" region = "eu-central-1" このリポジトリにある main.py ファイルには、呼び出されたときにシンプルなメッセージを返す Python コードのサンプルがあります。 main.tf ファイルには、 main.py ファイルのコードを使用して Lambda 関数を作成およびデプロイするための、以下のコードブロックがあります (これらのコードブロックのコメントを解除してください)。 data "archive_file" "lambda_archive_file" { …… } resource "aws_lambda_function" "lambda" { …… } これで、AWS CodeBuild を利用してアプリケーションをデプロイできるようになりました。もう terraform コマンドをローカルで実行する必要はありません。これが AWS CodeBuild を利用することの最大の利点です。 terraform plan と terraform apply を再度実行するために、それぞれの AWS CodeBuild プロジェクトを起動します。 (翻訳者補足: AWS CodeBuild プロジェクトを起動する前に terraform init -migrate-state コマンドをローカルで実行することで、ローカルに保存されている State を Amazon S3 バックエンド に引き継ぐことができます。コマンドの仕様については ドキュメント を参照してください。) (翻訳者補足: AWS CodeBuild プロジェクトを起動する前に、「インフラストラクチャの準備」で作成した AWS CodeCommit リポジトリにソースコードを Push しておく必要があります。CodeBuild プロジェクトはこのソースコードを参照して動作します。) デプロイが成功したら、作成した AWS Lambda 関数でコードをテストしてみましょう。Lambda 関数をテストする手順は以下のとおりです。(コンソールでの作業になります) AWS Lambda コンソールを開き、関数「tf-codebuild」を選択します。 ナビゲーションペインの Code セクションで、 Test をクリックしてテストイベントを作成します。 イベント名 (例えば「test-lambda」) を指定します。 他はデフォルト値のまま Save をクリックします。 Test を再度クリックして、テストイベント「test-lambda」を起動します。 Lambda 関数は、main.py ファイルに記述してあるサンプルメッセージを返すはずです。 デフォルトでは以下に示すように「Hello from AWS Lambda !」のメッセージが表示されます。 図3: サンプル Lambda 関数のレスポンス State ファイルを確認するには、Amazon S3 コンソールに移動し、作成されたバックエンドバケット ( tfbackend-bucket ) を選択してください。 State ファイルが含まれているはずです。 (翻訳者補足: ここでは「インフラストラクチャの準備」のセクションで作成した s3 バケットを選択してください。) 図4: Terraform の State ファイルが保存された Amazon S3 バケット Amazon DynamoDB コンソールを開き、テーブル tfstate-lock を確認してみてください。LockID を持つエントリがあるはずです。 図5: LockID を持つエントリが登録された Amazon DynamoDB テーブル このように、継続的インテグレーションパイプラインから Terraform のリモートバックエンドを利用して、 Terraform State ファイルを安全に保存しロックすることができました。 クリーンアップ リポジトリから作成されたすべてのリソースを削除するには、ターミナルから以下のコマンドを実行してください。 terraform destroy まとめ このブログ記事では、Terraform の State ファイルの基本を掘り下げ、AWS 環境内での安全な保存のためのベストプラクティスと、ファイルをロックして不適切な同時アクセスを防ぐメカニズムについて説明しました。そして最後に、AWS 上の継続的インテグレーションパイプラインで、それらをいかに効率的に管理できるかの例を示しました。 AWS 上の 継続的デリバリー パイプラインでも、State ファイルを管理するために同じ方法が適用できます。 より詳細を知りたい場合は、 AWS での CI/CD パイプライン 、 Terraform バックエンドの種類 、 Terraform State の目的 をご覧ください。 著者について Arun Kumar Selvaraj Arun Kumar Selvaraj は AWS Professional Services の Cloud Infrastructure Architect です。彼は thought leadership、運用基準、プラットフォームを提供する世界クラスの能力を開発し、お客様に迅速な移行と成長パスを提供することに情熱を注いでいます。Migration, CCoE, IaC, Python, DevOps, Containers and Networking などの分野に興味があります。 Manasi Bhutada Manasi Bhutada はオランダを拠点とする ISV Solutions Architect です。お客様のビジネス上の課題に対処するために、AWS での Well-Architected なソリューションの設計と実装を支援しています。Data Analytics と Networking の分野に情熱を注いでいます。仕事以外では、さまざまな食べ物を試してみたり、ピックルボールやボードゲームをプレイすることを楽しんでいます。 本記事は 2024/02/19 に投稿された Best practices for managing Terraform State files in AWS CI/CD Pipeline を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

はじめに 組織がクラウド上でワークロードのモダナイゼーションを進めるにあたり、その ジャーニー を成功に導くためには重要となる「能力」の習得を必要とします。その能力には、組織構造、モダナイゼーション戦略、自動化、チームの成熟度合い、利害関係者のスポンサーシップなどが含まれます。このなかで、自動化は、特にアジリティ、スケーラビリティ、運用効率といったモダナイゼーションのメリットを実現する上での非常に大きな役割を果たします。 しかし、「自動化」は人によってさまざまな解釈があるでしょう。この記事における自動化とは、特定の成果を達成するために手作業に代わってコードと構成を用いて作業を行うツールとプロセスを指すということを、はじめにあわせておきましょう。 この記事では、特定の問題に対する早急な解決策ではなく、戦略的な実現手段としてクラウドの自動化を認識し、活用する効率的なデリバリー・モデルを構築するためのガイダンスをIT リーダーに提供していきます。 導入フェーズにおける自動化の目標 一般的に、モダナイゼーションプログラムの導入フェーズでは、ビジネス目標、スコープ、予算、組織構造、テスト戦略の定義に重点が置かれます。自動化戦略は、戦略的な計画の要素というよりは戦術的な活動とみなされるため、導入フェーズでは見落とされがちであり、含まれないことが頻繁にあります。その結果、モダナイゼーション戦略の大きな文脈において、自動化を推進するのに必要な注意が払われず、それにより、自動化が、計画や実装の段階で後回しにされることになります。自動化戦略は、モダナイゼーションプログラムの導入フェーズにおける重要なアウトプットであるべきであり、明確な自動化の目標が定義され、モダナイゼーションプログラムの目標に対して合致しているべきです。計画フェーズでは、自動化戦略からもっと拡げ、自動化のアプローチ、予算、および実装計画（設計、開発、テスト、デプロイメント、および運用を含む）を含めます。自動化計画は、重要なマイルストーンに対する主要な相互依存関係を組み込んだ上で、モダナイゼーションプログラム（図1 参照）と並行して進めるべきです。 図1：計画フェーズのアウトプット 運用モデル アプリケーション開発チームのミッションは、ビジネス機能を迅速に提供することに集中することであり、自動化は必ずしも優先事項ではありません。開発ライフサイクルを加速させるため、自動化機能を構築することを最優先する、別のチームの創設を検討しましょう。自動化チームと開発チームは、共通のビジネス目標を達成するために、プログラム全体のタイムラインと整合する相互依存の機能として運営されます。 組織のアジャイルと DevOps の実践は、図2 に示すように、開発ライフサイクル全体を通じて、モダナイゼーションの成果に対して共有オーナーシップを持つ開発チームと自動化アジャイルチーム間の機能横断的なコラボレーションを促進する必要があります。このアプローチは、より迅速なフィードバック・ループと継続的なインテグレーションを促し、チーム・メンバー間で共有の責務として、モダナイゼーションの成果を重視することになります。 図2：チーム構造 開発チームと自動化チームの間で職務を分離することで、利害の衝突を防ぎ、チームが定義された自動化プロセス以外のタスクを実行する可能性を減らすことができます。明確なポリシーを確立し、期待事項を伝え、定期的にアクセス制御を見直し、更新することが極めて重要になります。一般的なガイドラインとして、すべての環境構築、デプロイメント、コンフィギュレーション、データロードは、自動化プロセスによって実行されるべきでしょう。 自動化チームを編成するには、2 つの方法があります。1 /共通チーム： このアプローチでは、一元化された自動化チームが、組織全体の自動化ニーズに対応します。このアプローチは、組織が集中型DevOps 戦略をとっている場合に採用されます。これには、統一された自動化ツールとプロセスによる集中化したデプロイメントパイプラインが含まれます。2 /専任チーム： このアプローチでは、特定のモダナイゼーションのイニシアチブまたはプログラムの自動化を構築するために、専任の自動化チームが編成されます。このチームは、イニシアチブないしプログラムのための自動化の実装が完了後、最終的に集中型DevOps チームに統合されます。 自動化戦略 – エンド・ツー・エンドの自動化 組織は、開発ライフサイクル全体にわたるエンド・ツー・エンドの視点から自動化戦略を定義する必要があります。自動化ツールチェーン（ツールとプロセスを含む）をソフトウェアライフサイクル全体で構築します。ツールチェーンには、環境構築、開発、バージョン管理、継続的インテグレーション、コード品質、継続的デプロイメント、コンテナ化、モニタリング、コラボレーション、テストを含めます。 クラウド・セキュリティの自動化は、クラウド環境の動的な性質がもたらす課題に対処するために非常に重要です。自動化は、セキュリティ・ギャップのプロアクティブな特定と解決、パッチ管理、脅威の検出、インシデント対応によって、セキュリティとコンプライアンスを迅速かつ大規模に維持するのに役立ちます。 高度なアクセスを必要とせずに、アプリケーションとインフラストラクチャのパフォーマンス、信頼性、セキュリティを監視し、最適化するための自動化された可観測性ソリューションを構築します。これにより、チームは各環境を可視化し、プロアクティブな監視によって問題を軽減し、運用効率を向上させることができます。 効率的かつ効果的なワークフローを構築するには、適切なツールの組み合わせを選択することが重要です。ツールチェーンに選択するツールは、相互運用性に優れ、ライフサイクルを通じて統合されたユニットとして機能する必要があります。図3 は、統合されたエンド・ツー・エンドのツールを提供するAWS サービスを利用したツールチェーンのサンプルを示しています。 図3：AWSサービスを活用したサンプルのツールチェーン 自動化の効果測定 自動化の目的は多様であり、主要な指標を測定することが可能であるため、自動化の効果を測定することは複雑な作業になります。しかし、自動化の成果を測定することは不可欠といえます。適切な測定基準を追跡し、データに基づいた意思決定を行うことで、組織は自動化の効果を改善し、望ましい結果を得ることができます。以下は、自動化の効果を測定するために使用される一般的な測定基準です： コスト削減： 手動オペレーションの削減、生産性の向上、リソース利用の最適化によるコスト削減を測定します。人件費、インフラストラクチャー費用、運用経費などの要素を含めます。 時間の削減： 環境のプロビジョニング、コード開発、テスト、デプロイメントなど、特定のタスクやプロセスを完了するために、短縮できた時間を測定します。 欠陥率： 人的介入の最小化による精度の向上を指します。 手作業によるプロセスで発生していた不具合の削減を測定します。 生産性： 自動化により改善した生産性の向上を測定します。特定の時間内に完了したタスク、トランザクション、オペレーション数を評価します。 品質： 自動化によって達成されたアウトプットの品質向上を評価します。標準への準拠、コンプライアンス、顧客満足度などの要素を測定します。 プロセス・サイクル・タイム：自動化によるプロセス・サイクル・タイムの短縮を測定します。特定のプロセスやワークフローの開始から終了までにかかる時間を計算します。 投資利益率（ROI）： 発生したコストと得られた利益を比較することにより、自動化の取り組みにおけるROI を計算します。コスト削減、生産性の向上、効率性の向上、市場投入までの時間などの要素を考慮します。 さらに、 DevOps メトリクス を使用して自動化の有効性を測定することができます。 成熟度モデル 多くの組織では、成熟度モデルを用いて自動化の現状を評価するのが一般的です。成熟度モデルは、自動化のゴールを設定し、自動化に向けたロードマップを策定し、自動化における投資の優先順位を決めるための良いガイドとなります。一般的に、組織は、それぞれのニーズに合わせて成熟度モデルをカスタマイズするのが良いでしょう。 以下は、クラウドにおける自動化の成熟度を評価するために使用できるモデル（図4 ）になります。 図4：成熟度モデル 自動化メトリクスと成熟度モデルは、互いに連携して使用されます。成熟度レベルごとに、定量的なしきい値の範囲とともに、使用する具体的なメトリクスを定義します。自動化の成熟度レベルを検証するために、定期的な監査を実施します。これにより、チームは自動化の全体的な有効性を測定することができ、その結果、改善点を特定し、自動化のゴールの優先順位を決定することができます。 自動化におけるAI AI とML ツールが成熟し、生成AI が登場したことで、自動化に関するあらゆる可能性が広がりました。AI 機能は、インテリジェントな洞察、予知保全、自動インシデント対応、自己修復を提供する自動化システムの提供を可能にします。 生成AI により、意思決定にインテリジェンスと柔軟性を加えることで、自動化を次のレベルに引き上げ、以前は自動化には複雑すぎると考えられていたプロセスを変革することができます。生成AI が自動化に適用される例としては、文書化、スクリプトとコードの生成、コンプライアンス・レポート、セキュリティ・ギャップの特定と修正、自動化されたインシデント対応などがあります。 自動化におけるAI は進化する能力であり、新しいユースケースやチャンスが定期的に発見されます。AI を使用することで、組織は成熟度モデルを加速度的に通過し、ビジネス価値をより迅速に推進することができるようになるでしょう。 リスクと課題 自動化には多大なメリットがある一方で、リスクや課題もあります。自動化に過度に依存すると、人による監視が低下し、障害や意図しない結果を引き起こす可能性があります。複雑な自動化の実装は、保守が困難でIT 予算を浪費する扱いにくいソリューションの原因ともなります。 これらのリスクを軽減するために、組織は、計画的かつ十分に考え抜かれたアプローチに基づいて、自動化戦略を定義する必要があります。モニタリングやテストなど、自動化プロセスの定期的な監査を実施します。状況の変化に基づき、自動化プロセスを常に最新に保ちます。最後に、自動化に失敗した場合は、手動プロセスを導入します。自動化から必要な利益を得るためには、自動化とそれに伴うリスクのバランスを保つことが重要となります。 最後に 自動化は、開発ライフサイクルの生産性、効率性、信頼性を大幅に向上させ、それにより、チームはイノベーションと価値提供に集中することができます。自動化は、重要なマイルストーンを定義し、成熟度モデルに照らして測定することで、戦略的なアウトプットとして考えることができます。自動化は、プロジェクトの導入フェーズから実装まで注意を払う必要があるジャーニーです。自動化はそれ自体がアウトプットであり、重要なイネーブラー（成功要因）であることを念頭におき、モダナイゼーションに取り組みましょう。 参考文献 AWS CaseStudy – Botprise Reduces Time to Remediation by 86% on Average Using Automation and AWS Security Hub https://aws.amazon.com/solutions/case-studies/botprise-case-study/?did=cr_card&trk=cr_card Customer CaseStudy – On-Demand Infrastructure on AWS Helps Capital One DevOps Teams Move Faster Than Ever https://aws.amazon.com/solutions/case-studies/capital-one-devops/ AWS. DevOps practices and tool and use cases. https://aws.amazon.com/devops/ AWS. (10 Jul 2023 ) Automated Code Review on Pull Requests using AWS CodeCommit and AWS CodeBuild   https://aws.amazon.com/blogs/devops/automated-code-review-on-pull-requests-using-aws-codecommit-and-aws-codebuild/ AWS. (30 May 2023) Optimize software development with Amazon CodeWhisperer https://aws.amazon.com/blogs/devops/optimize-software-development-with-amazon-codewhisperer/ AWS. (04 May 2023) The history and future roadmap of the AWS CloudFormation Registry https://aws.amazon.com/blogs/devops/cloudformation-coverage/ AWS. (22 Dec 2022) Multi-branch pipeline management and infrastructure deployment using AWS CDK Pipelines https://aws.amazon.com/blogs/devops/multi-branch-pipeline-management-and-infrastructure-deployment-using-aws-cdk-pipelines/ AWS. (13 Dec 2022) Using Workflows to Build, Test, and Deploy with Amazon CodeCatalyst https://aws.amazon.com/blogs/devops/using-workflows-to-build-test-and-deploy-with-amazon-codecatalyst/ 著者について Swaroop Prabhakaran クラウド導入とデジタルトランスフォーメーションにフォーカスした結果重視型のリーダーです。ビジネスリーダーやIT リーダーと協力してイノベーションを加速させ、ビジネス成果を上げることに情熱を注ぎます。ビジネスおよびIT 組織全体で高いパフォーマンスを発揮するチームを率いながら、収益拡大を推進するためのプログラムマネジメントに豊富な経験を持ちます。 Nishant Singh 流通、消費財メーカー、デジタルバンキングを専門とするAWS のシニアカスタマーソリューションマネージャー（CSM）です。AWS を活用し、顧客のビジネス成果につながる新たな価値主導型ソリューションの構築を支援することに情熱を注ぎます。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

はじめに クラウドへのマイグレーションは、IT 環境をモダナイゼーションするための第一歩です。マイグレーションを完了することで、企業はよりモダンで、俊敏かつセキュアなIT 環境の基盤を築くことができます。しかし、多くの企業では、マイグレーション中に築かれた最初の勢いが減速し、行き詰まることが多々あります。クラウド導入の真の価値は、その後のアプリケーションと開発手法のモダナイゼーションにあり、魅力的なメリットを引き出すことにあります。組織は、モダナイゼーションの顧客への提供価値を明確にし、それを明確なビジネス成果に結びつけるのに苦労することが多いと言えます。 この記事では、当初のマイグレーションの勢いを維持しながら、クラウド導入のメリットを最大化するため、モダナイゼーションフェーズに進化するためのベストプラクティスを紹介します。 モダナイゼーションのメリット モダナイゼーションは、最新のテクノロジー、 クラウドネイティブ なアーキテクチャ、ソフトウェアデリバリーの実践、および運用プロセスを組み合わせることで、ビジネス目標をより迅速かつ一貫性を持って実現します。モダナイゼーションは、リフト＆ シフトのマイグレーションにとどまらない、さらに多くのメリットを引き出します。 スケーラビリティ ：モダナイズされたアプリケーションは、変化する需要に合わせて動的に拡張できるため、従来のモノリシックなアプリケーションに比べてパフォーマンスと可用性が向上します。さらに重要な点として、アプリケーションをホストするプラットフォーム全体ではなく、追加容量を必要とする特定のコンポーネントのみを拡張する能力を備えます。 コスト効率性 ：クラウドネイティブなテクノロジーとマネージドインスタンスを活用することで、インフラストラクチャとライセンスに関連するコストを削減できます。きめ細やかなレベルでリソースを効率的に活用できるため、全体的な費用の削減が可能です。 信頼性 ：モダナイズされたアプリケーションは、本質的にクラウド ネイティブ なテクノロジーを使用して設計されています。そのため、回復力があり、地理的に分散され、自己修復するように設計されており、ダウンタイムが削減され、全体的な信頼性が向上します。 イノベーションのスピード ：新機能の市場投入スピードが早くなり、新しいアイデアのテストや新機能の迅速な導入が容易になります。これにより、市場の変化に迅速に対応し、顧客からのフィードバックループを減らし、競争優位性を維持することができます。 インテグテーション ：クラウドネイティブなアプリケーションは、他のクラウドサービスと容易に統合できるため、より複雑で高度なシステムをシームレスに構築できます。 運用の効率化： クラウドネイティブなアプリケーションは、サーバーレスまたはマネージドインスタンスで管理・監視できるように設計されているため、バージョンアップ、パッチ適用、セキュリティ管理のために必要な複雑な作業と労力が軽減されます。生産性が向上し、組織は顧客への価値提供に集中できます。 モダナイゼーションを成功させるためのベストプラクティス 組織がモダナイゼーションジャーニーに取り組む際、モダナイゼーションプロジェクトを成功させるために推奨されるベストプラクティスがいくつかあります。これらの対策は、モダナイゼーションに向けた一貫性のある協調的な取り組みを確実に実施し、全体的な戦略とビジネス上の利益が途中で失われないようにするために重要です。 ステークホルダーの関与 ：すべてのモダナイゼーションの取り組みにおいて、ビジネス部門のステークホルダーだけでなくIT 部門のステークホルダーを持つことが重要です。ステークホルダーは、顧客の期待値の管理、ビジネス目標との整合、チェンジマネジメント、およびビジネスプロセスの変更への影響において重要な役割を果たします。ステークホルダーの関与は、モダナイゼーションの目標を達成するために不可欠です。 「大きく考え、小さく始める」 ：これは、組織がより多くのことを達成するために、限界を超えて挑戦的な目標を設定することを可能にする強力なマインドセットです。目標をより小さく、管理しやすいマイルストーンに分割することで目標を達成し、プロセス、リソーススキル、およびモダナイゼーションのアプローチ全体の強みを効果的に評価することができます。 組織の構造 ：マイグレーションフェーズで定義されたクラウド運用モデルは、IT 組織をクラウドに移行させるという非常に具体的な目的を果たすものでした。組織がモダナイゼーションフェーズに移行する際には、運用モデルを評価し、全体的なビジネス目標とモダナイゼーションの目的に基づいて調整することが重要です。クラウド運用モデルの有効性を定期的に測定し、組織の特定のニーズを満たすことを目的として、必要に応じて調整する必要があります。 自動化 ：自動化は、組織がモダナイゼーションのメリットをフルに享受するのに役立ちます。自動化により、新しいサービスの市場投入までのスピードが向上し、手動による介入を最小限に抑えた迅速な展開が可能になります。自動化によって手作業によるミスが減り、運用に関わる作業から解放されます。 自動化は、Infrastructure as Code（IaC）によるプロビジョニング、アプリケーション開発、テスト、デプロイメント活動など、開発ライフサイクルのあらゆる側面を包含する必要があります。 センター・オブ・エクセレンス ：クラウド・センター・オブ・エクセレンス（CCoE）は、顧客がクラウドモダナイゼーションのためのプロセスを標準化し、パターンを構築するために重要な役割を果たします。CCoE は、クラウドプラットフォームチームだけでなく、ビジネス部門を横断し、アプリケーション開発チームにも拡大する必要があります。CCoE チームは、再利用可能なリファレンス・アーキテクチャを構築し、適用先と使用方法に関するドキュメントを提供します。また、誤使用を防止するために自動化されたガードレールを組み込み、ガバナンスを利かせます。 スキルトレーニング ：社員がモダナイゼーションの準備をすることは、クラウドのトランスフォーメーションジャーニーにおいて重要な側面となります。社員が適切なクラウドネイティブツールに関する必要なスキルセットを習得していない場合、アプリケーションのモダナイゼーションに時間がかかり、品質が低下することにつながります。スキルはピアツーピアモデル（個々人が直接コミュニケーションできること）で習得できることが最善であり、組織内のコミュニティ構築が、成功のための重要な要素となります。 モダナイゼーション戦略 適切なモダナイゼーション戦略を定義することは、ビジネス成果を達成し、クラウドのメリットを最大化し、技術的負債を回避するために不可欠です。アプリケーションのワークロードを評価し、依存関係、インテグレーションパターン、パフォーマンス要件、およびビジネス価値などを考慮しながら、モダナイゼーションの候補を特定します。モダナイゼーション戦略は、図1 に示すモダナイゼーションのへ移行パスの1 つないし複数を選択することで実現できます。これらの移行パスは、単発のモダナイゼーションプロジェクトとして、またはクラウド移行の一部として実装することができます。 図1：モダナイゼーションへの移行パス 組織にとって適切なモダナイゼーションの移行パスは、アプリケーションの古さや複雑さ、予算、ビジネス目標など、さまざまな要因によって異なってきます。モダナイゼーションの目標を達成するには、以下のパターンの1 つ以上を選択することができます。 マイクロサービス ：アプリケーションがモノリシックで大規模かつ複雑な場合は、マイクロサービスの候補になります。マイクロサービスは、モノリシックなアプリケーションを独立したコンポーネントに分解するアーキテクチャです。マイクロサービスは、各コンポーネントを独立して拡張・管理できる柔軟性を提供します。 サーバーレスコンピューティング ：イベントドリブンであったり、変化しやすいワークロードを含んでいたり、短期間のプロセスがあるアプリケーションは、サーバーレスコンピューティングの良い候補となります。これにより、チームはサーバーのプロビジョニングや管理を行うことなくアプリケーションを構築できます。また、運用コストを削減しながら俊敏性を高めることができます。 マネージドサービス ： 目的別データベース などのマネージドサービスは、クラウドプロバイダーが最適化、スケーリング、信頼性などのインフラストラクチャを管理します。このアプローチにより、チームは基盤となるクラウドインフラストラクチャを管理することなく、効率性の向上、運用コストの削減、セキュリティの向上を実現できます。 コンテナ化 ：このアプローチでは、アプリケーションとその依存関係が、それぞれ独立したコンテナにパッケージ化され、ポータビリティ性と拡張性が向上します。コンテナ化の主なユースケースは、既存製品として販売されているアプリケーション、IoT デバイス、マイクロサービスコンポーネントです。 IT 環境内のアプリケーションが上記のパターンのいずれか、または組み合わせに当てはまらない場合は、レガシーな状態のままにしておきます。モダナイゼーションは、コスト削減、俊敏性、回復力の向上により、ビジネス価値を高める手段です。アプリケーションをモダナイゼーションすることに真のビジネス価値がない場合は、レガシーのままにしておいても問題ありません。 ビジネスケースの構築 ビジネスケースを、モダナイゼーション全般のビジョンと企業のビジネス目標に合致させておくことが重要です。モダナイゼーション戦略は組織レベルで定義され、実装はアプリケーションレベルで実現されますが、モダナイゼーションの完了には一般的に時間がかかるため、ビジネスケースは各ビジネス部門またはアプリケーショングループに合わせて調整する必要があります。 ビジネスケースを作成する際の主な考慮事項を以下に示します： アジリティとイノベーションの実現 ：モダナイゼーションによってビジネスの俊敏性がどのように向上し、イノベーションがどのように可能になるかを明確にします。開発・デプロイメント時間、拡張性、弾力性、市場投入までの時間、信頼性の向上に基づいてアジリティを評価します。 リスクの評価 ：モダナイゼーションプロジェクトに関連する潜在的なリスクおよび課題を特定するリスク評価を含めます。リスクは、技術の成熟度、ビジネスへの対応、ステークホルダーのコミットメント（ビジネスと IT）、チェンジマネジメントといった側面から評価します。 成功の測定 ：モダナイゼーションの取り組みに期待される成果を要約し、成功を測定するための明確なKPI を設定します。KPI は、レガシーシステムとの比較に使用できる明確な測定基準を持つ定量的なものとします。 所有コストの削減 ：コスト削減は、顧客がモダナイゼーションに向かうための重要な要素です。アプリケーションの各側面の ユニットメトリックコスト と、モダナイズされたソリューションの推定ユニットコストを比較します。ユニットメトリックコストの比較には、コンピュート、ストレージ、ネットワーク帯域幅、API とトランザクション、ライセンス料金、回復力、バージョンアップとバグ修正、および市場投入までの時間を含める必要があります。 最後に モダナイゼーションは終わりのないジャーニーであり、マイグレーションでとどまるべきではありません。クラウドは、データセンターの代替として扱うのではなく、企業が競争優位性を獲得するために活用すべき機能です。モダナイゼーションは、人・組織、プロセス、テクノロジーを横断する熟考戦略であるべきです。モダナイゼーションの最終的な目標は、イノベーションを起こしながらビジネスの成長を推進し、機敏でかつコスト効率に優れた組織へと変革することにあります。 参考文献 AWS. (2021, November 22). An Overview of the AWS Cloud Adoption Framework.  https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf AWS. (2022, Jul 14). Tracking the Effectiveness of Cloud Adoption https://aws.amazon.com/blogs/enterprise-strategy/tracking-effectiveness-of-cloud-adoption/ AWS. (2023, Jun 19). Navigating the Cloud Migration Bubble: Turning Your Bubble into a Blip https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-migration-bubble-turning-your-bubble-into-a-blip/ AWS. (2023, May 09). What is a cloud center of excellence and why should your organization create one? https://aws.amazon.com/blogs/publicsector/what-is-cloud-center-excellence-why-should-your-organization-create-one/ AWS. (2023, Apr 21). Business Value is IT’s Primary Measure of Progress https://aws.amazon.com/blogs/enterprise-strategy/business-value-is-its-primary-measure-of-progress/ AWS. (2021, Feb 23). What is a unit metric? https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/ 著者について Swaroop Prabhakaran クラウド導入とデジタルトランスフォーメーションにフォーカスした結果重視型のリーダーです。ビジネスリーダーやIT リーダーと協力してイノベーションを加速させ、ビジネス成果を上げることに情熱を注ぎます。ビジネスおよびIT 組織全体で高いパフォーマンスを発揮するチームを率いながら、収益拡大を推進するためのプログラムマネジメントに豊富な経験を持ちます。 Nishant Singh 流通、消費財メーカー、デジタルバンキングを専門とするAWS のシニアカスタマーソリューションマネージャー（CSM）です。AWS を活用し、顧客のビジネス成果につながる新たな価値主導型ソリューションの構築を支援することに情熱を注ぎます。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

By Kazuki Motohashi, Ph.D., Partner Solutions Architect, AI/ML – AWS Japan  By Yuji Arakawa, Sr. Enterprise Architect, Partner Core Tech – AWS Japan 本稿では、スケーラブルでありながらもコスト効率に優れる Pinecone serverless ベクトルデータベースを Amzon Bedrock のナレッジベースとして利用することでビジネスが生成 AI による新しい体験を迅速にユーザーへ届けることができることを紹介します。RAG (Retrieval Augmented Generation; 検索拡張生成) やベクトルデータベースを活用するアイデアを持ちながらもコストへの懸念やシステム構築の手間から次の一歩をためらっている企業・政府機関などの組織にとって生成 AI ジャーニーへの船出の一助となることを願っています。 はじめに 生成 AI は、人々の生活を豊かにする新しい体験を提供したり、ビジネスの生産性向上と新たな事業機会を生み出すテクノロジーとして期待されています。既存のアプリケーションやサービスに組み込んでユーザー体験を改善したり、全く新しいアプリケーションやサービスの実装など様々な取り組みが進んでいます。生成 AI を活用する際には、最新で正確な情報に基づいたユーザー体験を提供することが求められます。企業や政府機関などの組織においてはセキュリティや知的財産権と並んで重要なテーマとなっています。 RAG・検索拡張生成とは RAG を使用すると、エンタープライズ検索、データベース、API などの外部知識ソースからデータを取得して、それを元に大規模言語モデル (LLM) により質問への回答生成のようなテキスト生成を行うことができます。質問応答のために生成 AI を使用する場合、RAG の仕組みにより、質問のクエリと最も関連性の高い最新の情報で回答を行います。さらに、その回答が正しいかユーザーが検証できるよう、データソースを引用として表示することもできます。 RAG では、外部の知識ソースとして企業・組織の内外のリレーショナル・データベースや API などを活用することに加えて、蓄積された文書などの膨大な非構造データから知識を検索したり洞察を得るために自然言語を使ったセマンティックサーチができるベクトルデータベースが注目されています。 ベクトルデータベースを使った RAG ソリューションでは、一般に次のようなプロセスが取られます。まず事前の準備として知識ソースのデータを元にベクトルデータベース上にナレッジベースを構築します。最初のステップでは、元のデータを検索に適した小さなセグメントに分割します。このセグメントはチャンクと呼ばれ、このステップはチャンキングと呼ばれます。次に、チャンクをセマンティックサーチが可能なベクトルデータへ変換します。この変換は埋め込み (embedding) モデルを使って行われます。埋め込みモデルは、単語や文章などのテキストデータを、高次元のベクトル空間内の点として表現します。この空間内では、意味的に類似したテキストデータは近くに位置するように学習されます。つまり、似た意味を持つ文章は、ベクトル空間内で近くに位置することになります。このようにして得られたベクトル表現を使うことで、2 つの文章の類似度を計算することができます。次に、このベクトル表現をベクトルデータベースの索引 (index) に登録することでナレッジベースが構築されます。 ナレッジベースから知識を検索したり洞察を得るためにユーザーが質問をすると、その質問文も同じ埋め込みモデルでベクトル化されます。そして、索引の中のベクトル化された文書群から、この質問のベクトルと最も近い文書 (単一、もしくは、複数) が検索されます。次に、検索された関連文書とユーザーの質問を組み合わせたプロンプト (指示文) を用いて LLM に最終的な回答を生成させます。つまり、この RAG システムには埋め込みモデルと LLM の 2 つのモデルが組み合わさっており、埋め込みモデルが関連文書の検索のために利用され、LLM が回答文を生成するという役割分担がなされています。 本稿では、 Knowledge base for Amazon Bedrock と、 AWS Marketplace からサブスクライブして利用できるベクトルデータベースの Pinecone を利用してナレッジベースを構築する手順について紹介します。 Knowledge base for Amazon Bedrock Knowledge base for Amazon Bedrock は、Amazon Bedrock で提供される大規模言語モデルと組み合わせてシンプルな手順で迅速にマネージドな RAG システムを構築することができる Amazon Bedrock の機能です。 Amazon Simple Storage Service (Amazon S3) にアップロードされたデータソースから情報を取得し、その情報をベクトル化してベクトルデータベース上にナレッジベースを構築します。データを検索に適した小さなセグメントへ分割する操作であるチャンキングや、埋め込みモデルを使ったベクトル化はマネージドサービスとして提供されます。お客様はこれらの仕組みを実装・運用する煩わしさから解放されます。 また、ナレッジベースは、 Agents for Amazon Bedrock と容易に統合することができます。これにより、企業や組織内に蓄積されたデータを元に精度の高い情報を回答できる RAG システムや、企業・組織の内外の API とも連携した生成 AI エージェントアプリケーションを迅速に構築することができます。 本稿執筆時点では、Knowledge base for Amazon Bedrock は、 US East (N. Virginia) と US West (Oregon) の 2 つのリージョンで提供されています。また、ベクトルデータベースとして Amazon OpenSearch Serverless 用ベクトルエンジン、 Amazon Aurora 、Pinecone、 Redis Enterprise Cloud をサポートしています。 Pinecone Pinecone は、高次元のベクトルデータを扱うための、クラウドネイティブでスケーラブルなベクトルデータベースです。 ベクトルデータベースの索引の中のからクエリに最も近い文書を検索する際、総当たりのアルゴリズムを用いることもできますが、非常に多くのコンピューティング資源を消費してしまい、大規模なベクトルデータベースではスケーラビリティに問題があります。Pinecone の基本的なアプローチは、ANN (Approximate Nearest Neighbor; 近似最近傍) 検索に基づいており、大規模なデータセット内でより高速にマッチする文書を効率的に見つけ、ランク付けすることができます。 Pinecone は AWS の ソフトウェアパートナー でもあります。 AWS re:Invent 2023 のパートナーキーノートにおいて、アメリカの大手投資ファンド会社である Blackstone と Pinecone の協業に関して取り上げられました。 Pinecone のプライシングプラン 本稿執筆時点では、Pinecone には、フリートライアルの Starter プランと、pod と呼ばれるクラウドリソース (vCPU、RAM、disk) をあらかじめ用意する pod ベースの Standard プラン、Enterprise プラン、そして、あらかじめクラウドリソースを用意せず使用量に基づいて課金される Serverless プラン (プレビュー) があります。Starter、Standard、Enterprise プランについては こちら のドキュメントをご参照ください。Serverless プランについては、 こちら をご参照ください。 Serverless プランでは、あらかじめコンピュート資源やストレージ資源を確保しておく必要がなく、課金は実際に消費した Read units (RUs) 、Write units (WUs)、Storage (GB 単位) に基づいて計算されます。そのため、トラフィックが少ないユースケースにおいても固定費を抑えてコスト効率の良いナレッジベースを構築することができます。例えば、Pinecone 社のホームページに掲載されている RAG ユースケースでは、初期アップロードされたベクトルデータのレコード数が 100 万レコード、月間のクエリ回数、書き込み回数がいずれも 1 万回でメタデータのサイズが 500 バイトである場合の月間コストは、 3.82 ドルと試算されています。詳しくは こちら の Estimate your costs をご参照ください。 本稿では、Pinecone serverless を利用する手順を解説します。 AWS Marketplace で Pinecone serverless をサブスクライブする AWS Marketplace は、AWS 上で動作するサードパーティ製のソフトウェア、データ、サービスを調達し、一元的に管理できるプラットフォームです。AWS Marketplace のカタログには何千ものソフトウェアが掲載されています。イメージとしては、 Amazon.com で Kindle の本を買うような手軽さでソフトウェアの調達を行うことができます。しかも、ソフトウェアの料金は AWS の請求と一元化されます。 多くの企業・組織では、ソフトウェアやサービスを購入する際には、調査、見積もり、稟議、承認、予算確保、サプライヤー選定、口座確認、契約、予算執行 (購入)、納期管理、ライセンス管理などの煩雑な作業が発生します。AWS Marketplace では Marketplace で素早く適切なソフトウェア、サービスを見つけることができる上、既に AWS を利用されていて予算が確保されている場合には、新たな予算確保等のプロセスが不要となり迅速な調達が可能となる場合もあります。また、請求の一元化やソフトウェア資産の管理機能等もあり、調達後にもメリットのあるものとなっています。 はじめに AWS マネジメントコンソール を開いて、上部の検索バーに “marketplace” などと入力し、”AWS Marketplace Subscriptions” を開きます。 図1: AWS マネージメントコンソールから AWS Marketplace Subscriptions へ 左ペインの “製品を検出” を開くと、下図のようなカタログの UI が表示されます。右上の検索バーに “Pinecone serverless” などと入力して、”AWS Marketplace: Pinecone Vector Database – Pay As You Go Pricing” をクリックすると Pinecone の製品ページが開きます 図2: AWS Marketplace で Pinecone serverless を探す 右上の “View purchase options” ボタンを押します。 図3: Pinecone serverless の製品概要 表示される確認画面の “Subscribe” ボタンをクリックします。 図4: Pinecone Vector Database – Pay As You Go Pricing へのサブスクライブ 画面右上に “Set up your account” というボタンが表示されます。このボタンを押すと、ブラウザの新しいタブに Pinecone のユーザー登録画面が表示されます。 図5: AWS Marketplace から Pinecone アカウントセットアップへのリンク 図6: Pinecone サインナップ画面 ユーザー登録が完了すると Pinecone のダッシュボードが表示されます。本稿の執筆時点 (2024年3月5日) では、Pinecone serverless の試用に関して 100 ドルのクレジットが提供されており、その旨を知らせるウィンドウが表示されます。 “Get Started” をクリックします。 図7: Pinecone serverless 試用の 100ドル分の無料クレジットの案内 Project serverless の作成に成功した旨が一瞬表示された後、画面下部に Pinecone の API Key が表示されているのが見えます。“Up to 50x” と表示されているウィンドウの右上の “X” をクリックして閉じます。 AWS Marketplace が表示されているタブに戻ります。“Offer” の下段に “You are currently subscribed to this offer.” と表示されます。表示されていない場合は、ブラウザのリロードを行います。 図8: AWS Marketplace で Pinecone へのサブスクライブが完了し、AWS Marketplace との連携が完了したことを確認 Pinecone の Index を作成する Knowledge base for Amazon Bedrock のセットアップの前に Pinecone の Index を作成します。これは Pinecone のコンソールで行います。Pinecone のダッシュボードが表示されたタブへ戻り “Create Index” をクリックします。 図9: Pinecone の Index 作成 “Create a new Index” 画面で “Name” と “Dimension” を入力します。Dimension は、使用する埋め込みモデル毎に異なります。本稿では、埋め込みモデルとして “Titan G1 Embeddings – Text” を使用するため、Dimension には “1536” を入力します。Knowledge base for Amazon Bedrock の Vector Store の前提条件については、 ドキュメント をご参照ください。 画面中央の “Capacity Mode” が“Serverless (Public Preview)” であることを確認します。また、画面下部には Pinecone Index を作成する AWS リージョンが表示されているので、意図するリージョンであることを確認します (Pinecone serverless はプレビュー中であり、現在は us-west-2 オレゴンリージョンのみに対応しています)。そして、右下の “Create Index” をクリックします。 図10: Pinecone の Index のパラメータ設定 Pinecone Index の作成が完了すると下図のような画面が表示されます。通常、数秒から数十秒程度で完了します。 図11: Pinecone の Index 作成完了の確認とHOST (エンドポイント URL) の確認 Pinecone Index の作成はこれで完了です。Pinecone コンソールに表示されている “HOST” をメモします。Knowledge base for Amazon Bedrock のナレッジベースが参照するベクトルデータベースを指定する際に必要となります。 Pinecone API Key を AWS Secrets Manager へ登録する Pinecone のコンソールの左側ナビゲーションペインで “API Keys” をクリックします。右側の “Actions” にあるコピーアイコンをクリックして、API Key をクリップボードにコピーします。 図12: Pinecone の API Key の確認 AWS マネジメントコンソール を開いているタブに戻り、上部の検索バーに “Secrets Manager” などと入力して AWS Secrets Manager のコンソールを開き、“新しいシークレットを保存する” をクリックします。 図13: AWS Secrets Manager コンソール “シークレットのタイプ” として “その他のシークレットのタイプ” を選択し、“キー“ には apiKey を、”値“ には先程クリップボードにコピーした ”Value“ をペーストします。下図のスクリーンショットではアスタリスクとなっていますが、実際のコンソール上では API Key の値がそのまま表示されます。なお、”キー“ の apiKey は、大文字小文字が区別されるので注意してください。画面右下の ”次“ をクリックします。 図14: AWS Secrets Manager で新しいシークレットを保存する (シークレットのタイプとキー／値のペア) “シークレットの名前” ( pinecone-kb-test など) と“オプションの説明” を入力して、右下の “次” をクリックします。次に表示される “ローテーションを設定 – オプション” は必要に応じて適切に設定し、右下の “次” をクリックします。“レビュー” 画面の内容を確認し “保存” をクリックします。 図15: AWS Secrets Manager で新しいシークレットの設定 下図のような画面が表示されれば、シークレットが正常に登録されています。 図16: AWS Secrets Manager で新しいシークレットの作成完了の確認 作成したシークレットをクリックして、“シークレットの詳細” を表示し、 “シークレットの ARN” をメモします。ナレッジベースが参照するベクトルデータベースを指定する際に必要となります。 図17: AWS Secrets Manager で新しいシークレットの ARN の確認 データソースを準備する Knowledge base for Amazon Bedrock では、Amazon S3 をデータソースとして、S3 バケットにアップロードされたファイルをベクトルデータベースへ取り込みます。ナレッジベースを作成する前にデータソースとなる S3 バケットを作成し、ファイルをアップロードします。 AWS マネジメントコンソール の上部の検索バーに “S3” などと入力して S3 のコンソールを開きます。右側の “バケットを作成” をクリックします。“バケットを作成”の画面が表示されたら “AWS リージョン” を選択 (本稿では、us-west-2 オレゴン) し、“バケット名” を入力して、右下の “バケットを作成” をクリックします。 図18: Amazon S3 にバケットを作成 バケットの作成が完了したら作成したバケット名をクリックすると下図のような画面が表示されます。右側の “アップロード” をクリックします。 図19: Amazon S3 バケットへのファイルアップロード (1) “ファイルを追加” をクリックして、ナレッジベースに登録するファイルを指定します。本稿では、 Amazon Bedrock のユーザーガイドの PDF ファイル をアップロードします。 図20: Amazon S3 バケットへのファイルアップロード (2) – ファイルの追加 右下の “アップロード” をクリックします。アップロードに成功すると、下図のような画面が表示されます。概要欄に表示されている “送信先” (s3://...) をメモしておきます。右上の “閉じる” をクリックします。 図21: Amazon S3 バケットへのファイルアップロード (3) – アップロード完了の確認 ナレッジベースを作成する AWS マネジメントコンソール の上部の検索バーに “Bedrock” などと入力して、Amazon Bedrock のコンソールを開きます。左上のハンバーガーメニューをクリックしてナビゲーションペインを開き、“▼オーケストレーション” の下の “ナレッジベース” をクリックします。 図22: Amazon Bedrock コンソール 右側の “ナレッジベースを作成” をクリックします。 図23: Amazon Bedrock でナレッジベースの作成 (1) ステップ 1 の “ナレッジベースの詳細を入力” 画面で “ナレッジベース名” ( knowledge-base-pinecone-test など) を入力して、右下の “次へ” をクリックします。 図24: Amazon Bedrock でナレッジベースの作成 (2) – 詳細入力 ステップ 2 の “データソースを設定” 画面で “データソース名” ( knowledge-base-pincone-test-data-source など) と “S3 URI” を入力します。“S3 URI” には先ほどの “データソースを準備する” のセクションでメモした S3 URI を指定します (もしくは、 “S3 を参照” をクリックして選択します)。“次へ” をクリックします。 図25: Amazon Bedrock でナレッジベースの作成 (3) – データソースを設定 ステップ 3 では “埋め込みモデル” を選択します。本稿では、“Titan Embeddings G1 – Text” を使用します。他の埋め込みモデルを使用する際には、埋め込みモデルの “ベクトルの次元” と Pinecone Index の “Dimension” が一致している必要があることに注意してください。 なお、使用する埋め込みモデルは、Amazon Bedrock サービスでアクセス権が付与されている必要があります。Bedrock コンソールのハンバーガーメニューからナビゲーションメニューを開き、“モデルアクセス” 画面を開きます。ここで、“アクセスが付与されました” となっていない場合 (“リクエスト可能” となっている場合) は、右上の “モデルアクセスを管理“ をクリックして、モデルアクセスをリクエストします。 図26: Amazon Bedrock でナレッジベースの作成 (4) – 埋め込みモデルを選択 スクロールダウンして、“ベクトルデータベース” を選択します。Pinecone を使用する場合は、 “作成したベクトルストアを選択” を選択し、“既存のデータベースを選択” 欄で “Pinecone” を選択します。また、“Pinecone を選択することにより、….” の条項に同意いただく必要があります。同意される場合は、チェックボックスにチェックマークを入れます。 図27: Amazon Bedrock でナレッジベースの作成 (5) – ベクトルデータベースを選択 さらにスクロールダウンし、“エンドポイント URL” に “Pinecone の Index を作成する” のセクションの最後にメモした “HOST” の URL を入力します。また、“認証情報シークレット ARN” には、“Pinecone API Key を AWS Secrets Manager へ登録する” でメモした “シークレットの ARN” を入力します。“テキストフィールド” には、チャンクに分割されたテキストデータを保存する Pinecone のフィールド名 ( text など) を入力します。“Bedrock マネージドメタデータフィールド” には、Bedrock がメタデータを保存する Pinecone のフィールド名 ( metadata など) を入力します。“次へ” をクリックします。“確認して作成” 画面で入力内容を確認して、右下の “ナレッジベースを作成” をクリックします。 図28: Amazon Bedrock でナレッジベースの作成 (6) – ベクトルデータベースの詳細を設定 通常、1分程度でナレッジベースが作成されます。この時点ではナレッジベースの枠だけが作成されています。 ナレッジベースをデータストアと同期する ナレッジベースを作成した直後の場合は下図のような画面が表示されています。“同期” もしくは “データソースを同期“ をクリックして、データソースをナレッジベースへ取り込みます。同期に必要な時間はデータストアのデータ量に依存します。”データソースの同期が完了しました“ と表示されればデータソースのナレッジベースへの取り込みが完了しています。今回の、Amazon Bedrock ユーザーガイドの PDF ファイルひとつの場合には 1 分程度で完了しました。 なお、この画面から移動してしまった場合は、Amazon Bedrock コンソールの左側ハンバーガーメニュー → ナビゲーションメニュー → オーケストレーション → ナレッジベースの順に辿り、テストしたいナレッジベースの名前を選択すると、同様の画面に遷移します。データストアに変更 (データの追加、更新、削除) があった場合には改めて ”同期“ を行う必要があります。API を使って同期する方法については ドキュメント をご参照ください。 図29: Amazon Bedrock でナレッジベースのデータストアとの同期 ナレッジベースをテストする ナレッジベースを作成して同期が完了すると、下図のような画面が表示されます。画面右側の “モデルを選択” をクリックして、クエリへの回答を生成する基盤モデルを選択します。 図30: Amazon Bedrock でナレッジベースのテスト (1) “モデルを選択“ 画面で、回答生成に使用したい基盤モデルを選択します。本稿では、Anthropic 社の ”Claude 2.1 v.2.1“ を選択します。Amazon Bedrock では Claude 3 が既に利用可能となっていますが、本稿執筆時点では Knowledge base for Amazon Bedrock で利用可能な基盤モデルは下図の 3 モデルとなっています。”適用“ をクリックします。 図31: Amazon Bedrock でナレッジベースのテスト (2) – 回答を生成する大規模言語モデル (LLM) の選択 “ナレッジベースをテスト” の下部にある “ここにメッセージを入力” 欄に質問を入力します。“実行” をクリックします。 図32: Amazon Bedrock でナレッジベースのテスト (3) – テストクエリの入力と実行 ナレッジベースの検索結果を元に、基盤モデルによる回答が生成されました。 図33: Amazon Bedrock でナレッジベースのテスト (4) – テスト結果 回答の元となった情報の出典も確認することができます。 図34: Amazon Bedrock でナレッジベースのテスト (5) – 回答の根拠となる出典を確認 ナレッジベースに API でアクセスする ナレッジベースに API 経由で質問を送信し回答を得るには、Agents for Amazon Bedrock Runtime の RetrieveAndGenerate API を使用することができます。詳細は ドキュメント をご参照ください。 API でアクセスするには、ナレッジベースの ID (図 29 などの “ナレッジベース ID”)と、回答を生成する基盤モデルのモデル ID が必要となります。基盤モデルのモデル ID は、Bedrock コンソール → 左上のハンバーガーメニュー → ナビゲーションメニュー → 基盤モデル → ベースモデルと辿って表示される “ベースモデル” 画面で、基盤モデル名 (このブログの例では Claude v2.1) をクリックして表示される画面の API リクエスト欄で確認することができます ( ListFoundationModels API で確認することもできます)。 下記のコードサンプルの modelId と knowledgebaseId を、確認した値に修正し、必要に応じて query を修正します。 import boto3 region = "us-west-2" modelId = "anthropic.claude-v2:1" knowledgebaseId = "XXXXXXXXXX" query = "Bedrockのセキュリティ上のメリットは何ですか？" modelArn = f'arn:aws:bedrock:{region}::foundation-model/{modelId}' session = boto3.Session(region_name=region) client = session.client(service_name='bedrock-agent-runtime') response = client.retrieve_and_generate( input={ 'text': query }, retrieveAndGenerateConfiguration={ 'type': 'KNOWLEDGE_BASE', 'knowledgeBaseConfiguration': { 'knowledgeBaseId': knowledgebaseId, 'modelArn': modelArn, }, }, ) print(response['output']['text']) 下図は実行例となります。 図35: ナレッジベースへの API アクセスの実行結果 ハイブリッドサーチに関する補足 本稿では Knowledge base for Amazon Bedrock と Pinecone serverless を用いてセマンティックサーチを行う方法について取り上げました。ユースケースによっては、セマンティックサーチだけでなく、テキストサーチも組み合わせたハイブリッドサーチが適している場合もあります。Pinecone 自体はハイブリッドサーチをサポートしていますが、本稿執筆時点では、Knowledge base for Amazon Bedrock と Pinecone との組み合わせでは、ハイブリッドサーチはサポートされていません。ハイブリッドサーチを使いたい場合には、Amazon OpenSearch Serverless との組み合わせをご検討ください。また、Pinecone のハイブリッドサーチを使いたい場合には、Knowledge base for Amazon Bedrock を使わずに、Amazon Bedrock の基盤モデルと Pinecone serverless を LangChain などのフレームワークで統合することができます。 まとめ Knowledge base for Amazon Bedrock と Pinecone serverless を組み合わせることでシステムの担当者は、RAG システムや生成 AI エージェントアプリケーションの構築の手間を大幅に軽減することが可能です。また、ビジネスの担当者はアイデアを迅速に検証し、素早く市場にリーチすることができます。そして、新しいサービスは利用者数や利用頻度を予測することが難しく固定費が大きなアーキテクチャーではプロダクションへの移行の決断が困難となりますが、Pinecone serverless のコンサンプションベースの料金体系により、リスクを最小限に抑えながら新サービスの事業化が可能となります。さらに、事業活動が大きく成長した際にも Pinecone serverless のスケーラビリティが役に立つでしょう。 著者について 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。 荒川裕二 (Yuji Arakawa) は、APJ (Asia Pacific Japan) Partner Core Tech のシニアエンタープライズアーキテクトです。主に日本のパートナー企業の技術支援を担当しながら Machine Learning TFC (Technical Field Community) の AoD (Area of Depth) としても活動しています。好きなサービスは Amazon Bedrock と Amazon SageMaker Jumpstart です。自由時間のすべてをアニメーション産業の発展のために捧げています。

本記事は、AWSブログ Experience the Future of Smart Manufacturing at Hannover Messe 2024 を日本語に翻訳し、日本のお客様向けに 補足情報 を追加したものです。 ハノーバーメッセ2024は、今年最大の世界的な産業技術イベントになるでしょう。4月22日から26日までドイツのハノーバーで開催され、製造業や産業界をリードする企業、パートナー、さらに13万人以上の参加者が集い、製造業の未来を形作る新しいソリューションが披露されます。 Amazon Web Services(AWS) も出展し、工場における生成 AI を含む最新の産業ソリューションを紹介します。 こちらの動画で 概要をご覧いただけます。インダストリー4.0、生成 AI/人工知能、カーボンニュートラルな生産といったテーマのもと、製造業の企業が最新のイノベーションを活用して、スマートで効率的かつ持続可能な事業運営を実現する方法を体験できるでしょう。 ハノーバーメッセ 2024 へ来場する理由 世界有数の産業技術見本市であるハノーバーメッセは、見逃せないイベントです。来場すべき主な理由は以下のとおりです。 産業界における重要な課題を克服するための興味深いシアターセッションに参加し、新たな技術を活用して競争優位を得ようとする製造業の業界リーダーの洞察に触れることができます。 自動車、輸送、電力、石油・ガス、鉱業、化学などの関連業界の製造業の企業や参加者とのネットワーキングの機会があります。 生成AIや機械学習など、世界の産業を急速に変革しつつある最新の産業イノベーションや最新のソリューションにいち早くアクセスできる特別な機会があります。 2024 年ハノーバーメッセにおけるAWSの展示 Hall 15、Booth D76の AWS ブースにお越しいただき、AWS の専門家と交流したり、エンジニアリング/設計、スマート生産、スマート製品、サステナビリティ、サプライチェーンなどの最新のユースケースを支える AWS のテクノロジーや AWS パートナーソリューションのインタラクティブな展示をご覧ください。データがなぜあらゆるデジタルトランスフォーメーションの基礎であるのか、また、組織全体の様々なユースケースに対処するためには、産業データ戦略を持つことがビジネスチームのデータ活用のために極めて重要であることがご理解いただけるでしょう。 AWS は、データの資産活用のためのスケーラブルで統合されたメカニズムを実現するデータ管理アーキテクチャの作成をご支援します。 AWS のチームと会話し、製造業のお客様がコネクテッドなソフトウェア定義 (Software Defined) 製品とサービスを立ち上げる方法を学ぶことができます。 どのように製品に新しい機能を統合して顧客体験を向上させ、製品を改善し差別化するかを学ぶことができます。 AWS サービスを使用してアプリケーションを構築することにより、製造業のお客様は、スマートなコネクテッド製品・装置を革新することができます。新たな収益成長機会を創出するために、 製品・装置のデータを収集・処理・保存・分析・活用できる IoT、ML、AI、データ基盤を AWS サービスが提供します。 生成 AI 、データ分析、コンピュータビジョン、モノのインターネット (IoT)、デジタルツインなどを活用したライブ製品デモをご覧いただけます。電動バイクのスマートな生産ラインを題材にした新しいデモにより、AWS クラウドソリューションがどのように運用効率や品質を改善し、製品の設計からスマートコネクテッド製品の使用までの製造業のプロセス全体でビジネスイノベーションを推進するかをお見逃しなく。 ブースシアターでは、AWS のリーダー、AWS パートナー、そしてお客様による生成 AI 、機械学習、産業用IoTといった新しいテクノロジーの産業での活用についての講演をお聞きください。月曜日から木曜日まで 50 を超えるセッションを予定しており、生成 AI からデジタルツイン、サステナビリティまで、シアターはさまざまな話題でいっぱいです。 ブースでは、プラチナスポンサーの Siemens、MHP、Snowflake を含む30社以上の製造業に注力しているパートナーが展示を行っています。これらのAWSパートナーは製造業で強固な足場を築いており、クラウドトランスフォーメーションジャーニーを簡単にするためのソリューションを AWSと協力して構築しています。 業界を変革する最新の AWS 機能に重点を置いたガイド付きのブースツアーで、AWS の製造業の専門家とネットワークを築くことができます。また、月曜日から木曜日の午後5時30分から7時まで、AWS ブースで毎夕開催されるネットワーキングレセプションにもお立ち寄りください。 AWS ブースの生成 AI 生成 AI は、製造業の企業が業務を最適化したり、価値実現までの時間(Time to Value)を加速する方法を急速に変えつつあります。ブースに立ち寄りいただき、製造業のお客様のイノベーションと意思決定を加速するために、AWS がどのように生成 AI ベースのアプリケーション構築や大規模展開を容易になものにしているかをご覧ください。Amazon Bedrock、Amazon CodeWhisperer、Amazon Q などの AWS の生成 AI サービスは、製品の設計を革新し、生産を強化し、製造サプライチェーンを最適化するのに役立ちます。 生成 AI は、産業イノベーションの次の大きな波を表しています。ハノーバーメッセでは、未来を垣間見ることができるでしょう。 AWS のクラウドテクノロジーにより製造業の企業が業務全体で生成 AI を活用できるようになることをご自分の目で確認ください。 生成 AI が技能者、技術者に専門的なガイダンスをすぐに提供することで、スキルギャップをどのように解消するかを学んでいただけます。 生成 AI が製造品質管理、トラブルシューティング、メンテナンス、作業指示などをどのように最適化するかをデモでご覧いただけます。 コスト効率よく合成データセットを作成するため、どのように生成 AI を使用してコンピュータビジョンモデルをトレーニングするかをご確認ください。 デジタルツインと統合された生成 AI が装置のトラブルシューティングをどう効率化するかを体験してください。 産業における生産効率の進化と、生成 AI によって実現されるイノベーションを探るセッションにご参加ください。 生成 AI アプリケーションを自分で作成したり、使ったりすることを、ハンズオンで体験してください。 ご来場をお待ちしています ハノーバーメッセ 2024 へのご来場を通じて、今後の製造業を形作る最新のイノベーションを体験いただき、未来を、より速く、一緒に切り拓いていきましょう。 今すぐ登録して 、競争力、サステナビリティの実現、そして成長の原動力となる先進的なソリューションの数々を、ぜひ直接ご体験ください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノーバー現地において、AWS の日本メンバーによる日本語でのブースのご案内や、個別ミーティング等を実施しています。上記リンクまたは担当の営業経由でお申し込みください。また、現地でも日本人スタッフにお気軽にお声がけください。 Tiffany Pfremmer Tiffany は、Amazon Web Services の製造・産業分野に注力する上級マーケティングマネージャーです。 ロックウェル・オートメーションに15年以上在籍し、マーケティング、品質、サービスなど、様々な役割を果たした経験を生かし、製造業のサプライチェーン全体を支えるソリューションのマーケティングと提供に注力しています。  

1. はじめに AWS はワークロードを AWS へ移行する方針を決定するビジネスケースを、データに基づいて作成するのに役立つ無料の移行評価サービスとして Migration Evaluator を提供しています。これには、オンプレミスで実行されているサーバーワークロードと、その使用パターンを検出するデータ収集ツールが含まれています。 Migration Evaluator Collector で収集したデータを AWS Migration Evaluator チームが受け取ることで、ワークロードの適切なサイズの分析、Amazon EC2 へのマッピングを作成することができます。これには次の 2 つの方法があります: Migration Evaluator Collector は毎日 Migration Evaluator チームにデータを自動的に送信するよう設定することができます Migration Evaluator Collector はデータをファイルにエクスポートし、Migration Evaluator チームに向けて安全にアップロードすることができます 最初のオプションは、Migration Evaluator が評価の範囲を検証し、対象範囲のサーバーからの収集が成功していることを確認できるため、ほとんどのお客様に適しています。 Migration Evaluator が収集するインベントリデータには、サーバー名と IP アドレスが含まれます。お客様によっては、サーバー名と IP アドレスを社外に開示できないようにセキュリティ要件を設けている場合があります。これに対処するためには、データを AWS に送信する前に匿名化する必要があります。セキュリティ要件を満たすための最も適切なアプローチは、手動による匿名化ではなく、スクリプト化されたソリューションを使用することです。前者の場合、時間がかかりエラーも起こりやすいためです。 このブログでは、Migration Evaluator によって収集された機密データを匿名化するために、Python スクリプトを使用したソリューションを紹介します。 データが AWS で利用可能になったら、評価収集期間の終了時に分析され ( こちら を参照) 、次の 2 つの成果物が提供されます: Quick Insights: 使用量パターンに基づき、AWS でリホストした場合の想定コスト削減額をインフラストラクチャとソフトウェアライセンスで分割した 1 ページの要約です。 オンプレミスの検出データ (サーバーハードウェアのプロビジョニング、Microsoft SQL Serverの設定、およびリソースの使用状況) と、Amazon Elastic Compute Cloud (Amazon EC2) および Amazon Elastic Block Storage (Amazon EBS) へのリホストに関する推奨事項を組み合わせた、詳細な CSV エクスポートも可能です。 Directional Business Case にはいくつかのセクションがあります: Microsoft Windows と Microsoft SQL Server のライセンス最適化分析による最適化とライセンス評価 (OLA) に加えて、ワークロードが適切なサイズにして Amazon EC2 に移行した場合のコストを示す、カスタマイズされた複数のコストモデルシナリオ 予想される CO2 削減量を示すサステナビリティ分析 オプションで、検出の範囲に応じて、VMware Cloud on AWS、Amazon Relational Database Service (RDS)、Amazon WorkSpaces、AWS Elastic Disaster Recoveryなどの追加の AWS サービスの詳細も確認できます 2. ソリューション概要 サーバー名、ハイパーバイザーのホスト名、IP アドレスを匿名化するスクリプトについて説明します。このスクリプトには次の 2 つの機能があります: Migration Evaluator Collector のエクスポートファイルをインプットとして受け取り、匿名化されたバージョンをアウトプットとして生成します。出力ファイルには以下が含まれます: 匿名化されたサーバー名 匿名化されたハイパーバイザーホスト名 IP アドレスなし Migration Evaluator Quick Insights の結果の ZIP ファイルをインプットとして受け取り、匿名化されていない結果をアウトプットとして生成します。 注: 匿名化されたデータと匿名化されていないデータのマッピングは、ランダムに生成された識別子を使用し、スクリプトを実行するシステムに保持されるため、AWS に送信されることはありません。 2.1 前提条件 Python 3 (現行バージョン) openpyxl ライブラリがインストールされていること。openpyxl ライブラリをインストールするには、以下のコマンドを使用します: pip install openpyxl お好みのテキストエディタを使用して、”collector-anonymizer.py “というファイルを作成し、このブログの「3. ME-Collector のエクスポートファイルを匿名化する Python コード」をこのファイルにコピーします 2.2 Migration Evaluator Collector のエクスポートファイルのデータ匿名化 エクスポートファイルをダウンロードし、 (必要な場合は) 注釈を付けます (詳細については、 Installation Guide の Section 10 を参照してください) 。この例では、ファイル名「Inventory_And_Usage_Workbook-2023-03-24.xlsx」を使用します サーバー名 (B列) とハイパーバイザー名 (H列) 示す仮想プロビジョニングシートの例 先ほど保存したpythonスクリプトを実行します python collector-anonymizer.py an Inventory_And_Usage_Workbook-2023-03-24.xlsx 出力されるファイル名は、Inventory_And_Usage_Workbook Anonymized.xlsx になります。ファイルを開き、匿名化の要件に従っていることを確認します。その後、Installation Guide の Section 10 で説明されているように、匿名化されたエクスポートを ME コンソール にアップロードすることができます。 匿名化されたサーバー名 (B列) とハイパーバイザー名 (H列) を示す仮想プロビジョニングシートの例 2.3 Migration Evaluator Quick Insights の非匿名化 Quick Insights の準備が整うと、メールで通知が届きます: ME コンソールに移動し、Quick Insights 標準フォーマットの zip ファイルをダウンロードして、元のエクスポートファイルと同じフォルダに配置します 以下のコマンドを実行して結果の匿名化を解除します。 python collector-anonymizer.py de Inventory_And_Usage_Workbook-2023-03-24.xlsx standard-customernamemas-12345-mas-12345_2023-03-30-11-26-00.zip この例では、元のエクスポートファイルの名前は Inventory_And_Usage_Workbook-2023-03-24.xlsx で、Quick Insights の zip ファイルの名前は standard-customernamemas-12345-mas-12345_2023-03-30-11-26-00.zip です。 注: サンプルコマンドは、読みやすくするために 2 行に分割されています。コマンドは 1 行にする必要があります。 このスクリプトは、実際のサーバー名を含む Quick Insights の結果を含むファイルを出力し、収集した情報から Microsoft SQL Server が検出された場合は、Microsoft SQL Server 情報を含む 2 番目のファイルを出力します。 3. ME-Collector のエクスポートファイルを匿名化する Python コード #Beginning of Script #!/usr/bin/env python3 import csv import zipfile import argparse import openpyxl def get_column_indexes(sheets): """提供されているすべてのシートのシート名 -> 列名-> インデックス番号を含む dict を作成する""" headers = {} for sheet in sheets: headers[sheet.title] = {} for idx, column in enumerate(sheet.columns): headers[sheet.title][column[0].value] = idx + 1 return headers def anonymize(filename): """指定された Excel ファイルを匿名化し、アウトプットをを新しいファイルとして保存する""" wb = openpyxl.load_workbook(filename) # シート名の読み込み uti = wb["Utilization"] asset = wb["Asset Ownership"] virt = wb["Virtual Provisioning"] phys = wb["Physical Provisioning"] column_indexes = get_column_indexes([uti, asset, virt, phys]) # 仮想プロビジョニングシートの Hypervisor Name をハイパーバイザーの固有識別子に置き換える for cell in list(virt.columns)[ column_indexes["Virtual Provisioning"]["Hypervisor Name"] - 1 ]: for b_cell in list(phys.columns)[ column_indexes["Physical Provisioning"]["Human Name"] - 1 ]: if b_cell.value == cell.value: virt.cell( row=cell.row, column=column_indexes["Virtual Provisioning"]["Hypervisor Name"], ).value = phys.cell( row=b_cell.row, column=column_indexes["Physical Provisioning"]["Unique Identifier"], ).value # すべてのシートで「人間の名前」を「一意の識別子」に置き換える for sheet in [uti, asset, virt, phys]: for row in range(2, sheet.max_row + 1): sheet.cell( row=row, column=column_indexes[sheet.title]["Human Name"] ).value = sheet.cell( row=row, column=column_indexes[sheet.title]["Unique Identifier"] ).value # 物理、仮想プロビジョニングシートの IP アドレスを削除 for sheet in [phys, virt]: for cell in list(sheet.columns)[column_indexes[sheet.title]["Address"] - 1][1:]: cell.value = None wb.save("Inventory_And_Usage_Workbook Anonymized.xlsx") print( "Anonymization successful, Inventory_And_Usage_Workbook Anonymized has been created" ) def deanonymize(filename, qi): """元の Collector エクスポートファイルを使用して、指定された Quick Insights の zip ファイルの匿名化を解除する""" # Quick Insights の zip ファイルからファイル名を取得 with zipfile.ZipFile(qi, "r") as z: zip_filenames = z.namelist() # 元の匿名化済みスクリプトの Asset Ownership と Physical Provisioning を取得 wb = openpyxl.load_workbook(filename) asset = wb["Asset Ownership"] phys = wb["Physical Provisioning"] column_indexes = get_column_indexes([asset, phys]) unique_id_to_hostname = {} for row in asset.rows: unique_id_to_hostname[ row[ column_indexes["Asset Ownership"]["Unique Identifier"] - 1 ].value.upper() ] = row[column_indexes["Asset Ownership"]["Human Name"] - 1].value for row in phys.rows: unique_id_to_hostname[ row[ column_indexes["Physical Provisioning"]["Unique Identifier"] - 1 ].value.upper() ] = row[column_indexes["Physical Provisioning"]["Human Name"] - 1].value # 匿名化されていないサーバーおよび SQL QI ファイルの作成 for zip_file in zip_filenames: with z.open(zip_file) as f: file_string = f.read().decode("utf-8") reader = csv.reader(file_string.splitlines()) headers = next(reader) csv_col_indexes = {} for idx, column in enumerate(headers): csv_col_indexes[column] = idx # 非匿名化ファイルの作成 output_filename = "deanonymized_" + zip_file print(f"Creating output file: {output_filename}") with open(output_filename, "w", newline="") as g: writer = csv.writer(g) writer.writerow(headers) for row in reader: # 「Server Name」列の値を元のホスト名に戻す row[csv_col_indexes["Server Name"]] = unique_id_to_hostname[ row[csv_col_indexes["Server Id"]].upper() ] # 「Virtualization | Host Name」列の値を元のホスト名に戻す (列が存在し、値がある場合) if ( "Virtualization | Host Name" in csv_col_indexes and row[csv_col_indexes["Virtualization | Host Name"]] ): row[ csv_col_indexes["Virtualization | Host Name"] ] = unique_id_to_hostname[ row[csv_col_indexes["Virtualization | Host Name"]].upper() ] # 変更された行を CSV に書き込む writer.writerow(row) if __name__ == "__main__": # 引数処理 parser = argparse.ArgumentParser() parser.add_argument( "method", help="The method to use, 'an' for anonymization or 'de' for de-anonymization", ) parser.add_argument("filename", help="Inventory and Utilization Export file") parser.add_argument("QI", help="QI .zip file", nargs="?", default=None) args = parser.parse_args() if args.method == "an": anonymize(args.filename) elif args.method == "de": if args.QI is None: parser.error("QI is required for de-anonymization") deanonymize(args.filename, args.QI) else: parser.error("Invalid input. Please enter either 'an' or 'de'.") #End of script 4. おわりに この投稿では、Migration Evaluator を使用するお客様が、サーバーのメタデータ (ホスト名、IPアドレス、サーバー名) を匿名化および非匿名化する簡単な方法を紹介しました。コードの最適化を手伝ってくれた Roger Trevor に感謝します。 著者について Benoit Lotfallah Benoit は、ドイツのアマゾンウェブサービスのシニアソリューションアーキテクトです。過去数年間、彼はお客様の AWS への移行を支援してきました。 翻訳は Amazon Web Services Japan ソリューションアーキテクト 堀田直美 が担当しました。原文は こちら です。

はじめに Amazon Elastic Kubernetes Service (Amazon EKS) の「Elastic」とは、 「必要なときにリソースを確保し、不要になったときにリソースを解放する」 機能を指します。Amazon EKS はほとんどすべてのワークロードを処理できるように拡張できますが、Amazon EKS のお客様から「1 つの Amazon EKS クラスターでサポートされる Pod やノードの最大数はいくつですか」というような質問をよく耳にします。 Kubernetes は複雑なシステムであり、Kubernetes クラスターのパフォーマンス特性はワークロードの特性によって異なる場合があるため、これらの質問に対する答えはさまざまです。 Kubernetes コミュニティは Kubernetes コンポーネントのサービスレベル指標 (SLI) とサービスレベル目標 (SLO) を定義しており 、これらをスケーラビリティに関する議論の出発点として使用できます。この投稿では、これらの SLI と SLO について説明し、Amazon EKS チームがどのようにスケーラビリティテストを実施しているのか説明します。 SLI は私たちがシステムを測定する方法です。例えばリクエストのレイテンシーやカウントのように、システムの稼働状況を判断するために使用できる指標があります。SLO は、例えば、リクエストのレイテンシーが 3 秒未満というように、システムが正常に稼働しているときに期待される値を定義します。Kubernetes SLO と SLI は Kubernetes コンポーネントのパフォーマンスに重点を置いており、Amazon EKS クラスターの Kubernetes API エンドポイントの可用性に重点を置いた Amazon EKS サービス SLA とは無関係です。 Kubernetes アップストリームの SLO Amazon EKS はアップストリームの Kubernetes リリースに準拠しており、Amazon EKS クラスターが Kubernetes コミュニティによって定義された SLO の範囲内で動作することを保証しています。 Scalability Special Interest Group (SIG) は Kubernetes のスケーラビリティ目標を定義し、SLI と SLO を通じてパフォーマンスのボトルネックを調査しています。 Kubernetes には、Container Storage Interface (CSI) ドライバー、Admission Webhook、Autoscaler など、ユーザーがカスタムのアドオンやドライバーを使用してシステムを拡張できる機能が数多くあります。これらの拡張は、Kubernetes クラスターのパフォーマンスにさまざまな形で影響を与える可能性があります。例えば、 failurePolicy=Ignore の Admission Webhook は、Webhook ターゲットが利用できない場合、Kubernetes API リクエストのレイテンシーを増加させる可能性があります。Kubernetes Scalability SIG は、 「you promise, we promise」フレームワーク を使用してスケーラビリティを定義しています。 次のことを約束していただければ: クラスターを正しく構成する 拡張機能を「合理的に」使用する クラスターの負荷を 推奨制限 内に抑える クラスターがスケールすることをお約束します: すべての SLO が満たされます Kubernetes SLO は、ワーカーノードのスケーリングや Admission Webhook など、クラスターに影響を与える可能性のあるプラグインや外部要因をすべて考慮しているわけではありません。これらの SLO は Kubernetes コンポーネント に重点を置いており、Kubernetes のアクションとリソースが期待どおりに動作することを保証します。SLO は、Kubernetes 開発者が Kubernetes コードの変更によってシステム全体のパフォーマンスをデグレードさせない役割を担っています。 Kubernetes Scalability SIG では、以下の公式 SLO/SLI を定義 しており、Amazon EKS チームはこれらの SLO や SLI について Amazon EKS クラスターで定期的にスケーラビリティテストを実施して、変更が行われたり新しいバージョンがリリースされたりしたときのパフォーマンスのデグレードを監視しています。 Objective Definition SLO API request latency (mutating) Latency of processing mutating API calls for single objects for every (resource, verb) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day <= 1 second API request latency (read-only) Latency of processing non-streaming read-only API calls for every (resource, scope) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day: (a) <= 1 second if scope=resource (b) <= 30 seconds otherwise (if scope=namespace or scope=cluster) Pod startup latency Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, 99 th percentile per cluster-day <= 5 seconds API リクエストのレイテンシー kube-apiserver では、 --request-timeout がデフォルトで 1m0s と定義されています。つまり、リクエストがタイムアウトしてキャンセルされるまでに最大 1 分（60 秒）実行できます。Latency に定義された SLO は、送信されるリクエストのタイプによって分類されます。リクエストのタイプは、変更可能な場合もあれば、読み取り専用の場合もあります。 変更 Kubernetes のリソース変更リクエストは、作成、削除、更新などを行います。これらのリクエストは、変更されたオブジェクトが返される前に etcd バックエンド に書き込まれます。etcd はすべての Kubernetes クラスターデータに使用される分散型のキーバリューストアです。 このレイテンシーは、Kubernetes リソースの (resource, verb) ペアに対して 5 分間の 99 パーセンタイルとして測定されます。例えば、Pod 作成リクエストやノード更新リクエストのレイテンシーが測定されます。SLO を満たすには、リクエストのレイテンシーが 1 秒未満である必要があります。 読み取り専用 読み取り専用リクエストは、「Get Pod X」など単一のリソース、または「Get all Pod from Namespace X」などコレクションを取得します。kube-apiserver はオブジェクトのキャッシュを保持するので、要求されたリソースをキャッシュから返すこともあれば、etcd から取得する必要がある場合もあります。 また、これらのレイテンシーは 5 分間にわたって 99 パーセンタイルで測定されますが、読み取り専用リクエストではスコープが異なっていてもかまいません。SLO には 2 つの異なる目標が定義されています。 kubectl get pod -n mynamespace my-controller-xxx など単一のリソースに対して行われるリクエストの場合、リクエストのレイテンシーは 1 秒未満にとどまる必要があります。 kubectl get pods -A など名前空間またはクラスター内の複数のリソースに対して行われるリクエストの場合、レイテンシーは 30 秒未満にとどまる必要があります。 Kubernetes リソースのリストに対するリクエストでは、リクエストに含まれるすべてのオブジェクトの詳細が SLO 内で返されることを前提としているため、SLO はリクエストスコープごとにターゲット値が異なります。クラスター上の Kubernetes オブジェクトなどリソースの大きな集合では、応答サイズが大きくなり返されるまでに時間がかかることがあります。例えば、数万の Pod を実行しているクラスターで、JSON でエンコードした各 Pod が約 1KiB の場合、クラスター内のすべての Pod を返そうとすると 10MB 以上になります。Kubernetes クライアントは、 ApiListChunking を使用して大量のリソースコレクションを取得する ことで、このレスポンスサイズを減らしています。 Pod 起動時のレイテンシー この SLO は主に、Pod の作成から Pod 内のコンテナが実際に実行を開始するまでにかかる時間に関係します。これを測定するために、Pod に記録された作成タイムスタンプと、その Pod の WATCH がコンテナの起動を報告した時刻の差が計算されます (コンテナイメージのプルとコンテナの初期化にかかる時間は除く)。この SLO を満たすには、Pod 起動レイテンシーの 1 クラスター稼働日あたりの 99 パーセンタイルを 5 秒未満にする必要があります。 Kubernetes SLI メトリクス Kubernetes では、これらの SLI を経時的に追跡する Kubernetes コンポーネントに Prometheus メトリクス を追加することで、SLI に関するオブザーバビリティも向上させています。 Prometheus Query Language (PromQL) を使って、Prometheus や Grafana ダッシュボードなどのツールで SLI のパフォーマンスを経時的に表示するクエリを作成できます。以下は先述の SLO の例です。 API サーバーのリクエストレイテンシー メトリクス 定義 apiserver_request_sli_duration_seconds verb、group、version、resource、subresource、scope、および component ごとの秒単位の応答レイテンシー分布 (Webhook の持続時間、優先度、公平性キューの待機時間はカウントされません)。 apiserver_request_duration_seconds verb、dry run value、group、version、resource、subresource、scope、および component ごとの秒単位の応答レイテンシー分布。 注 : apiserver_request_sli_duration_seconds メトリクスは Kubernetes 1.27 から利用可能になりました。 これらのメトリクスを使用して API サーバーの応答時間を調査 したり、Kubernetes コンポーネントや他のプラグイン/コンポーネントにボトルネックがないかを調べたりすることができます。これらのメトリクスを比較することで、リクエスト処理の遅延がどこで発生しているのかを把握できます。 API リクエストレイテンシー SLI — Kubernetes コンポーネントがリクエストを処理して応答するのにかかった時間です。SLI メトリクスは、リクエストが API 優先度や公平性のキュー で待機している時間、および Admission Webhook やその他の Kubernetes 拡張機能での処理に費やされる時間を除外することで、Kubernetes コンポーネントのパフォーマンスに関するインサイトを提供します。 API リクエスト合計レイテンシー — 合計時間メトリクスは、アプリケーションが API サーバーからの応答を待つ時間を反映しているため、より包括的な見方ができます。リクエストが受信されてからレスポンスが送信されるまでの時間が計算されます。これには、すべての Webhook 実行時間と、優先度と公平性のキューに費やされた時間が含まれます。 Pod 起動のレイテンシー メトリクス 定義 kubelet_pod_start_sli_duration_seconds イメージのプルと init コンテナーを実行する時間を除く、Pod を起動するまでの秒数。 Pod の作成タイムスタンプから、すべてのコンテナーが起動済みとして報告され、監視されるまでの時間を測定します。 kubelet_pod_start_duration_seconds kubelet が初めて Pod を確認してから Pod の実行が開始されるまでの秒数。これには、Pod をスケジュールする時間やワーカーノードのキャパシティをスケールアウトする時間は含まれていません。 注 : kubelet_pod_start_sli_duration_seconds メトリクスは Kubernetes 1.27 から利用可能になりました。 前のクエリと同様に、これらのメトリクスを使用すると、kubelet アクションと比較して、ノードのスケーリング、イメージのプル、および init コンテナが Pod の起動を遅延させている時間の長さを把握できます。 Pod 起動レイテンシー SLI – Pod が作成されてから、アプリケーションコンテナが実行中と報告されるまでの時間です。これには、ワーカーノードのキャパシティが利用可能になり、Pod がスケジュールされるまでにかかる時間が含まれますが、イメージをプルしたり、init コンテナを実行したりするのにかかる時間は含まれません。 Pod 起動合計レイテンシー – kubelet が初めて Pod を起動するまでにかかる時間です。これは、kubelet が WATCH 経由で Pod を受信した時点から測定したもので、ワーカーノードのスケーリングやスケジューリングにかかる時間は含まれていません。これには、イメージをプルし、 init コンテナ を起動して実行する時間も含まれます。 Amazon EKS がスケーラビリティにアプローチする方法 Amazon EKS は Kubernetes コントロールプレーンコンポーネントを管理し、そのセキュリティ、可用性、スケーラビリティを確保しますが、アプリケーション、拡張機能、およびデータプレーンインフラストラクチャ ( AWS Fargate を使用していない場合) の可用性とスケーラビリティについてはお客様の責任となります。Amazon EKS チームは定期的に一連の内部負荷テストを実施して、変更や新しいリリースによって改善されるか、同じパフォーマンスレベルが維持されるかを検証しています。 EKS ベストプラクティスガイドの「スケーラビリティ」セクション には、クラスターのスケーラビリティを向上させるために実装できる推奨事項とパターンが記載されています。 アップストリームの Kubernetes SLO および SLI 定義との一貫性を確保するために、Amazon EKS チームは SIG スケーラビリティで定義されているアップストリームのスケーラビリティテストに使用されているものと同じ基準を適用して Amazon EKS クラスターのスケーラビリティを測定しています。さまざまなユースケースや構成をすべてテストすることはできないため、これらのテストは、より高度なワークロードを評価または比較する際に使用できるスケーラビリティのベースラインとなります。 Amazon EKS でスケーラビリティテストを実行する方法 Amazon EKS チームは、Kubernetes の公式スケーラビリティおよびパフォーマンステストフレームワーク ClusterLoader2 を使用しています。Cluster Loader は宣言型スタイルのテストを使用して、指定された規模と速度で Kubernetes オブジェクトを作成します (例えば「5,000 ノードでノードあたり 30 Pod を実行し、1 秒あたり 50 Pod の速度でリソースを作成したい」など)。詳細については、 ClusterLoader2 の GitHub リポジトリ を参照してください。 Amazon EKS スケーラビリティテストは、 kubernetes/perf-tests リポジトリで定義されている汎用負荷テスト設定 に基づいています。Amazon EKS コントロールプレーンが大規模な場合でも SLO を維持できるように、5,000 ノードでテストを実行するように設定しています。Kubernetes コミュニティでは、これをクラスターあたり 5,000 ノードを超えると Kubernetes のパフォーマンスが低下する可能性があるという しきい値として定義しています 。ノード数は、ClusterLoader2 でテストを実行する際の追加パラメータ (名前空間の合計数など) の計算に使用されます。負荷テストを開始する前に、クラスター内のノードを 5,000 にスケールアウトしておきます。 負荷テストでは、Pod、(ReplicaSet と Pod を作成する) Deployment、Service、Secret などのさまざまな Kubernetes リソースが 1 秒あたり 50 Pod で作成され、Kubernetes コントロールプレーンのコンポーネントに持続的な負荷がかかります。Prometheus メトリクスは、リソースが作成されても SLO が満たされていることを確認するために、追加の詳細とともにテスト中に収集されます。 AWS のサービスクォータと考慮事項 クラスターを 5,000 ノードにスケールアウトするには、AWS アカウントの サービスクォータ を増やす必要がありました。テストに必要な制限項目を以下の表に示します。これらはテストクラスターのスケールとチャーンに合わせて増やす必要があったクォータです。 EKS ベストプラクティスガイド には、ワークロードに影響する可能性のあるその他の AWS サービスクォータが掲載されています。 AWS サービスクォータコンソール または AWS コマンドラインインターフェイス (AWS CLI) から、名前またはクォータコードを使用して、これらの制限の引き上げをリクエストできます。 サービス クォータ名 クォータコード デフォルト 増加後の値 Amazon Elastic Compute Cloud (Amazon EC2) Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances (最大 vCPU 数) L-1216C47A 5 32,000 Amazon Elastic Kubernetes Service (Amazon EKS) Nodes per managed node group L-BD136A63 450 1,000 Amazon Virtual Private Cloud (Amazon VPC) Security groups per network interface L-2AFB9258 5 16 Amazon VPC IPv4 CIDR blocks per VPC L-83CA0A9D 5 20 Amazon Elastic Block Store (Amazon EBS) Storage for General Purpose SSD (gp3) volumes, in TiB L-7A658B76 50 1,100 Amazon EBS Storage for General Purpose SSD (gp2) volumes, in TiB L-D18FCD1D 50 1,100 また、次の表に示すアクションに対する Amazon Elastic Compute Cloud (Amazon EC2) へのリクエストに対応するため、AWS アカウントのレート制限を引き上げています。Amazon EC2 のレートスロットリングの計算方法、アカウントでのレートスロットリングのモニタリング方法、および引き上げのリクエスト方法の詳細は、 EC2 ドキュメント に記載されています。 変更アクション 読み取り専用アクション AssignPrivateIpAddresses DescribeDhcpOptions AttachNetworkInterface DescribeInstances CreateNetworkInterface DescribeNetworkInterfaces DeleteNetworkInterface DescribeSecurityGroups DeleteTags DescribeTags DetachNetworkInterface DescribeVpcs ModifyNetworkInterfaceAttribute DescribeVolumes Amazon EKS クラスター ClusterLoader2 テストを実行するには、事前に合計 5,000 のワーカーノードにスケールアップされた マネージド型ノードグループ を含む Amazon EKS クラスターを使用します。Amazon EKS は、クラスターからの多数のシグナルに応じて Kubernetes コントロールプレーンを自動的にスケーリング します。そのスケーリングの一環として、Amazon EKS は 1 秒あたりのクエリ数 (QPS) や処理中リクエストの制限など、Kubernetes コントロールプレーンコンポーネントの一部のパラメータもスケーリングします。Amazon EKS クラスターは Kubernetes アップストリームのこれらのパラメータのデフォルト値を使用して作成され、Amazon EKS サービスはコントロールプレーンのスケールアップに合わせて自動的に値を増加させます。 Kubernetes コンポーネントは、起動時に設定された値をログに出力します。Kubernetes コンポーネントで Amazon EKS コントロールプレーンのログ が有効になっている場合は、 FLAG: で始まるログメッセージを検索してこれらのメッセージを確認できます。Amazon EKS が特定のクラスタースケールに設定する正確な値は、Kubernetes が変更されたり、より適切な値が見つかったりすると変わる可能性があります。 テスト用の Amazon VPC Container Networking Interface (CNI) プラグイン は、Pod の集約率と IP アドレス割り当てのパフォーマンスを向上させるために、IP アドレス割り当てに プレフィックス委任 を使用するように設定されています。クラスターはマネージド型ノードグループを幅広いインスタンスファミリーで使用しています。インスタンスタイプ間でインスタンスを多様化することで、複数のキャパシティプールからキャパシティを調達しやすくなります。テスト構成では、c5.large、m5.large、r5.large、t3.large、t3a.large、c5a.large、m5a.large、r5a.large のインスタンスを使用できます。 クラスターから Prometheus メトリクスを収集し、 Amazon Managed Service for Prometheus と Amazon Managed Grafana を使用して確認します。 テストの結果 負荷テスト中、ClusterLoader2 はクラスターのパフォーマンスを監視します。上記の SLO が満たされていない (つまり、1 つの Pod を取得する API リクエストのレイテンシーの 99 パーセンタイル [p99] が 1 秒以上かかっている) 場合、テストは失敗とみなされます。Amazon EKS チームはこれらの結果をレビューし、失敗したテストを調査して失敗の原因を把握し、リグレッションが対処されていることを確認します。 負荷テスト中に作成されるリソースの総数は ClusterLoader の設定 によって決まります。負荷テストでは、ノードあたり 30 Pod 、名前空間あたり 100 ノードで 計 5,000 ノードを想定しています。次に、テスト構成として、Pod の総数 (ノードあたり 30Pod に 5,000 ノードを掛けたもの)、名前空間 (5,000 ノードを名前空間あたり 100 ノードで割ったもの)、および名前空間あたりの Pod 数を計算します。 テストのピーク時には、クラスター内の SLO と予想されるチャーンを維持しながら、クラスター内のリソースの数を確認しています。 リソースタイプ テスト中に達した最大値 #Nodes 5,000 #Namespaces 50 #Pods 170,000* #Pods per node 30* #Deployments 16,000 #Services 8,000 #Endpoints 8,000 #Endpoints slice count 8,000 #Secrets 16,000 #ConfigMaps 16,000 #CRDs 4 #Jobs 150 * 負荷テストでは、ノードあたり 30 個のアプリケーション Pod を実行します。 Pod の総数には、プラグインと DaemonSet の Pod が含まれます。 SLO はアクションまたはリクエストを完了するまでの時間の閾値を定義するため、Kubernetes リソースの総数は実際にはこれらのテストの成功の決定要因ではないことに注意してください。例えば、Pod が起動するまでの時間のほうが、Pod の総数よりもクラスターのパフォーマンスをより深く把握できます。 クラスターの SLO Kubernetes が SLO をどのように定義しているか、Amazon EKS がクラスターのパフォーマンスをどのように測定するかを見てきました。Amazon EKS クラスターが、設定、プラグイン拡張機能、およびワークロードでどのように機能しているかを知りたいと思うかもしれません。既存の Amazon EKS クラスターで同じパフォーマンスベンチマークを確認するのに、5,000 ノードの負荷テストを全部実行する必要はありません。Amazon EKS クラスターの Kubernetes リソースから Prometheus メトリクスを収集すると、Kubernetes コントロールプレーンコンポーネントのパフォーマンスについてより深い洞察を得ることができます。使用できるメトリクスと Prometheus クエリの詳細については、 EKS ベストプラクティスガイドの「スケーラビリティ」セクション を参照してください。 SLO はクラスター内の Kubernetes コンポーネントのパフォーマンスに重点を置いていますが、他にも確認できるメトリクスが存在し、クラスターについて異なる視点が得られることを考慮してください。 kube-state-metrics のような Kubernetes コミュニティプロジェクトは、クラスター内の傾向をすばやく分析するのに役立ちます。Kubernetes コミュニティのコミュニティプラグインやドライバーは Prometheus メトリクスを出力することが多く、オートスケーラーやカスタムスケジューラーなどを調べることができます。 Observability Best Practices ガイド には、さらなる洞察を得るために使用できるその他の Kubernetes メトリクスの例が掲載されています。 Kubernetes コミュニティとの連携について Amazon EKS は Kubernetes コミュニティに貢献しています。Amazon EKS チームは Scalability SIG と協力して、 ネットワークプログラミングレイテンシー SLO のスケーラビリティテスト を実施しました。また、Amazon EKS チームは Kubernetes コミュニティと協力して、Kubernetes クラスターをプロビジョニングするためのコミュニティツールである kOps を使用して、AWS で 5,000 ノードのテストを実施しました。このテストは、Kubernetes のコード変更がパフォーマンスに悪影響を及ぼさないことを確認するために定期的に実施され、その結果は コミュニティのパフォーマンスダッシュボード で確認できます。これらのスケーラビリティテストの 1 つが失敗すると、Amazon EKS チームに通知され、調査を手伝ってもらえます。これらのテストの結果は、Kubernetes コミュニティのパフォーマンスダッシュボード で確認できます。 Amazon EKS チームは、アップストリームの Kubernetes コミュニティと同じパフォーマンスメトリクスをモニタリングするために、社内で 5,000 ノードで同じ負荷テストを実施しています。同じテストを同じ規模で使用することで、Amazon EKS 固有のコンポーネントがアップストリームの Kubernetes テストと同じレベルのパフォーマンスを維持できることを確認できます。 この作業は出発点に過ぎません。Kubernetes コントロールプレーンをスケーリングするに従って QPS や処理中リクエストのオプションを増やすなど、お客様が実際の使用で遭遇するボトルネックや問題に基づいて Amazon EKS クラスターのスケーラビリティを常に向上させています。Amazon EKS では、こうした改善がクラスターに自動的にデプロイされるため、スケーラビリティの問題が発生する前に回避できます。 まとめ この投稿では、Kubernetes コミュニティによって定義された SLO と、Amazon EKS がスケーラビリティをテストする方法について説明しました。1 つのクラスターを 1,000 ノードまたは 50,000 Pod を超えてスケーリングする場合は、ぜひご相談ください。Amazon EKS には大規模なクラスターを実行しているお客様がいます。可能な限り最高のパフォーマンスを提供するために、クラスターのスケーラビリティの向上に常に取り組んでいます。スケーリングについては、AWS アカウントチーム(ソリューションアーキテクトまたはテクニカルアカウントマネージャー)、AWS サポートチーム、または AWS Containers Roadmap に問い合わせてください。Kubernetes ワークロードを大規模に実行する方法の詳細については、 EKS ベストプラクティスガイドのスケーラビリティセクション をご覧ください。 本記事は Deep dive into Amazon EKS scalability testing (2024 年 1 月 31 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの馬渕です。 2024 年 1 月 30 日、AWS re:Invent 2023 のアップデートから建設・不動産・物流・交通業向けのアップデートや事例をご紹介する Recap (振り返り) ウェビナーを開催しました。今回のウェビナーでは、AWS ジャパンで業界特化でお客様の AWS 活用を支援するソリューションアーキテクトが、re:Invent での AWS からのアップデートやお客様事例をピックアップし、業界の最新動向も交えてご紹介しました。 今回のウェビナーでは、① re:Invent 2023キーノートおよび技術アップデート、② 物流業界事例と関連サービス紹介、③ 建設・不動産業界事例と関連サービス紹介、④ 交通ソリューション 事例と関連サービス紹介、の 4 つのセッションを配信しました。本ブログ記事では、セッション内容のサマリーと、セッションの資料・動画へのリンクをまとめてお届けします。 re:Invent 2023キーノートおよび技術アップデート ( 資料 ) – 馬渕 俊介 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 ソリューションアーキテクト このセッションでは、re:Invent 2023 の概要と、AWS のリーダーが目玉機能の発表とメッセージをお伝えする基調講演のご紹介を行いました。加えて、今年の発表の中で特に注目を集めた生成 AI についてもご紹介しました。「生成 AI とは何か？」という基本に始まり、AWS の主要な生成 AI サービスである Amazon Q ・ Amazon Bedrock のご紹介や、最新の交通・物流等の事例からみる生成 AI の最新動向、生成 AI 活用を成功させるためのコツについてお話しました。また、生成 AI をビジネスで活用するには自社のデータとの融合が必要となることから、データ関連のアップデートについてもご紹介しました。生成 AI サービスのご紹介では、活用イメージを持ちやすいようにデモ動画なども交えてご説明していますので、「AWS の生成 AI サービスが具体的にどう役立つのか？」という疑問の解消にもお役立ていただけます。 物流業界事例と関連サービス紹介 ( 資料 ) – 横山 誠 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 シニアソリューションアーキテクト さまざまな課題に直面している物流業界は、グローバルでビジネスを展開する多くの事業者にとって大きな関心ごとになっています。本セッションでは、データ活用による効率化とIoTによる自動化というテクノロジートレンドがどのように活用されているのかを紹介します。2022年に発表されたAWS Supply Chainは、2023年4月に一般公開されてからお客様のフィードバックを受けてより実用的な機能改善・追加が行われています。またAmazon RedshiftやAmazon QuickSightなどのAWSデータ分析サービスを組み合わせて、従来の売上や在庫ばかりでなく、作業員の行動のような情報もデータ化・可視化が進んでいます。物流倉庫ではマテリアル・ハンドリング機器のIoT化が注目されており、世界的な労働力の減少を受けて検証・導入が加速しています。なお、近年の生成AIの発展は音声アシスタントなどで利用されており、今後現場作業のデジタル化を大きく促進させる可能性があります。 建設・不動産業界事例と関連サービス紹介 ( 資料 ) – 岩野 洋平 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 建設不動産 シニアソリューションアーキテクト 建設と不動産業界では、建物やインフラ設備といった重要な都市機能を作り維持する中で老朽化や次世代の担い手不足、長時間労働など様々な課題があります。一方で、これらを改善する一つの手段として IoT や AI をクラウドと共に活用したデジタル化や業務改革が注目を浴びています。本セッションでは、AWS re:Invent 2023 で発表された事例セッションの中から IoT を活用したスマートホーム事例、デジタルツインとシミュレーションの融合やロボットを活用したインスペクション事例について紹介いたします。建物やインフラといったライフサイクルの長いハードウェア中心の世界にデジタルというライフサイクルが比較的短いソフトウェアを融合し、どういった改善や取り組みを進めているか参考にしてもらえればと思います。 交通ソリューション 事例と関連サービス紹介 ( 資料 ) – 矢形 拓也 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 シニアソリューションアーキテクト 多くの方が旅行やビジネスで公共交通機関を利用し、業界としての活気を取り戻しつつあると感じています。交通業界もインバウンドや生活サービスを拡充させることにより、新たなお客様のニーズをつかむべく様々な施策に取り組まれていると認識しています。re:Invent2023の振り返りとして、「AIを活用し働く人の負荷を軽減」、「お客様からの難しい問い合わせに挑むために」と「生活サービスを拡充するためのデータ活用」では発表された新サービスを中心にテーマに沿った利用方法についてお話をさせていただいています。セッション後半ではモダナイゼーションを推進されている United Airlines の事例や、現地で参加された日本のお客様が現地で感じられた事をご紹介させていただきました。航空会社、鉄道会社をはじめとした交通業界で働く皆様の取り組みにお役立ていただければ幸いです。 まとめ 2024 年 1 月 30 日に開催した AWS re:Invent Recap の振り返りとして、各セッションの概要をご紹介いたしました。セミナーにご参加いただいた方、誠にありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考になりましたら幸いです。内容に関して、ご質問やご要望がございましたら、お問い合わせページ、もしくは担当営業までご連絡をお願いします。 馬渕 俊介 (Mabuchi, Shunsuke) 交通業界のお客様を支援するソリューションアーキテクト。前職では性能のスペシャリストとして従事していたため、負荷テストや性能問題分析の知見を持っています。好きな AWS サービスは Amazon CloudWatch、好きな AWS ソリューションは AWS での分散負荷テスト ソリューションです。

AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方法は、単一責任 と Lambda-lith (Monolith な Lambda という意味の造語) です。しかし、このブログでは、これらのアプローチに代わる、両方の長所を提供できる方法を探ります。 単一責任の Lambda 関数 単一責任の Lambda 関数は、サーバーレスアーキテクチャ内で特定のタスクを実行したり、イベントによってトリガーされた特定の操作を処理したりするように設計されています: このアプローチにより、ビジネスロジックと機能の関心が強力に分離されます。特定の機能を分離してテストし、Lambda 関数を個別にデプロイし、バグが発生する可能性を減らし、 Amazon CloudWatch でのデバッグが容易になります。 さらに、単一目的の関数は、Lambda が需要に応じて自動的にスケールするため、効率的なリソース割り当てが可能になり、リソースの消費を最適化し、コストを最小限に抑えることができます。つまり、メモリサイズやアーキテクチャなど、関数ごとに利用可能な設定を変更できます。さらに、すべてのリクエストを処理する単一の Lambda 関数にトラフィックを集約するのではなく、単一のタスクのトラフィックに基づいて上限緩和を要求できるため、サポートチケットを介して関数の同時実行数の上限緩和を要求することが容易になります。 もう 1 つの利点は、実行時間の速さです。単一のタスクのために設計された単一目的の Lambda 関数のビジネスロジックでは、他のアプローチで必要な追加ライブラリを必要とせず、関数のサイズをより簡単に最適化できます。これにより、バンドルサイズが小さくなり、コールドスタートの時間を短縮できます。 このような利点がある一方で、単一目的の Lambda 関数だけに依存する場合、いくつかの問題が存在します。コールドスタートの時間は短縮されますが、特に散発的な、または呼び出し頻度が低い関数では、コールドスタートの回数が増える可能性があります。例えば、 Amazon DynamoDB テーブルのユーザーを削除する関数は、ユーザーデータを読み込む関数ほど頻繁にトリガーされることはないでしょう。また、単一目的の Lambda 関数に大きく依存することは、関数の数が増えるにつれて、システムの複雑さを増大させる可能性があります。 関心をうまく分離すると、コードベースを保守し易くなりますが、コードの凝縮度が失われます。API の書き込み操作 (POST, PUT, DELETE) など、似たようなタスクを持つ関数では、複数の関数にまたがってコードや動作が重複する可能性があります。さらに、Lambda Layer やその他の依存関係管理の仕組みを介して共有される共通ライブラリを更新する場合、単一のファイルに対するアトミックな変更ではなく、すべての関数にわたって複数の変更が必要になります。これは、ランタイムバージョンの更新など、複数の関数にまたがる他の変更にも当てはまります。 Lambda-lith: 1 つの Lambda 関数を使う 多くのワークロードで単一目的の Lambda 関数を使用すると、開発者の AWS アカウント全体で Lambda 関数が増殖してしまいます。開発者が直面する主な課題の 1 つは、共通の依存関係や関数の設定を更新することです。この問題に対処するための明確なガバナンス戦略 (依存関係の更新を強制するための Dependabot や、プロビジョニング時に取得されるパラメータ化されたパラメータの使用など) が実装されていない限り、開発者は別の戦略を選ぶかもしれません。 その結果、多くの開発チームは逆の方向に進み、API に関連するすべてのコードを同じ Lambda 関数内に集約します。 このアプローチは、API を構成するすべての HTTP メソッド、場合によっては複数の API を同じ関数にまとめるため、しばしば Lambda-lith と呼ばれます。 これにより、アプリケーションのさまざまな部分にわたって、より高いコードの凝縮度とコロケーションを実現できます。この場合のモジュール性はコードレベルで表現され、単一責任、依存性の注入、ファサードというようなパターンがコードを構造化するために適用されます。開発チームが適用する規律とコードのベストプラクティスは、大規模なコードベースを維持するために極めて重要です。 Lambda 関数の数が減ることを考慮すると、単一責任のアプローチに比べ、設定の更新や複数の API にまたがる新規格の実装がより簡単に実現できます。 さらに、すべてのリクエストはすべての HTTP メソッドに対して同じ Lambda 関数を呼び出すので、リクエストに対応する実行環境が利用できる可能性が高くなるため、呼び出し頻度の高くないコードのレスポンスタイムが向上する可能性が高くなります。 考慮すべき点をもう一箇所挙げるとすると、関数のサイズです。これは、API のすべての依存関係とビジネスロジックを持つメソッドを同じ関数内に配置すると増加します。これは、ワークロードが急増する Lambda 関数のコールドスタートに影響するかもしれません。特に、コールドスタートによって影響を受けるような厳しい SLA を持つアプリケーションの場合、顧客はこのアプローチの利点が欠点を上回っているか評価する必要があります。開発者は、使用されている依存関係に注意を払い、tree-shaking、minification、デッドコード除去などのテクニックを実装することで、この問題を軽減することができます。 このような粗いアプローチでは、関数設定を個別に調整することはできません。しかし、より高いメモリサイズや、セキュリティチームが設計した仕様に合わないほど緩いセキュリティ権限で、すべてのコードが機能するような設定を探し出さないといけなくなります 読み取り関数と書き込み関数 今までの 2 つのアプローチにはトレードオフがありますが、それぞれの利点を併せ持つ第 3 の選択肢があります。 多くの場合、API のトラフィックは読み込みと書き込みのどちらかに偏っているため、開発者はコードや構成をどちらか一方に最適化せざるを得ません。 例えば、利用者がユーザーを作成、更新、削除できるだけでなく、ユーザーやユーザーのリストを検索することもできるユーザー API を構築することを考えてみましょう。このシナリオでは、1 度に 1 人のユーザーを変更でき、一括操作は利用できませんが、API リクエストごとに 複数のユーザーを取得できます。API の設計を読み取り操作と書き込み操作に分けると、このようなアーキテクチャになります: 書き込み操作 (create, update, delete) をコードでまとめることは、多くの理由で有益です。たとえば、リクエストボディを検証し、必須パラメータがすべて含まれていることを確認する必要があるかもしれません。ワークロードが書き込みに集中している場合、あまり使用されない操作 (例えば、Delete 操作) は、ウォームスタートの恩恵を受けます。コードのコロケーションは、似たようなアクションのコードの再利用を可能にし、例えば共有ライブラリや Lambda Layer でプロジェクトを構成する際の認知負荷を軽減します。 読み取り操作の側面を見ると、この関数にバンドルされるコードを減らし、コールドスタートを高速化し、書き込み操作に比べてパフォーマンスを大幅に最適化することができます。また、Lambda 関数の実行時間を改善するために、実行環境のメモリ内にクエリ結果の一部または全部を保存することもできます。 このアプローチは、進化的なアーキテクチャではさらに効果を発揮します。プラットフォームがもっと普及した場合を想像してみてください。 ElastiCache と Redis を使った キャッシュアサイドパターン を追加することで、読み取り性能を改善し、API をさらに最適化しなければなりません。さらに、キャッシュミスの場合に読み取り機能を最適化した 2 つ目のデータベースを使用して、読み取りクエリを最適化することにしました。 書き込み側では、API のコンシューマがユーザー作成指示や削除指示の受付通知だけを受け取ることで、分散システムにおける結果整合性の恩恵を得れるかもしれません。 そこで、Lambda 関数の前に SQS キューを追加することで、書き込み操作のレスポンスタイムを改善できます。書き込みデータベースをバッチで更新することで、すべてのリクエストを個別に処理する代わりに、書き込み操作の処理に必要な呼び出し回数を減らすことができます。 コマンドクエリ責任分離 (CQRS) パターン は、データ変更、つまりシステムのコマンド部分をクエリ部分から分離する、よく知られたパターンです。スループット、遅延、または一貫性に関する要件が異なる場合は、CQRS パターンを使用して更新とクエリを分離できます。 完全な CQRS パターンから始めることは必須ではありませんが、API を大規模にリファクタリングすることなく、最初の読み書きの実装で強調されたインフラをより簡単に発展させることができます。 3 つのアプローチの比較 ここで 3 つのアプローチを比較してみましょう:   単一責任 Lambda-lith 読み込みと書き込みの分離 メリット 強い関心の分離 きめ細かな設定 デバッグのしやすさ 実行時間の速さ コールドスタートの回数が減る コードの凝縮度の向上 メンテナンスの簡素化 必要に応じたコードの凝縮度 進化的なアーキテクチャ 読み書き操作の最適化 課題 コードの重複 メンテナンスが複雑 コールドスタートの回数が多い 設定が粗い コールドスタートの時間が長い 2 つのデータモデルで CQRS パターンを利用する CQRS パターンにより、システムが結果整合性を持つようになる まとめ アーキテクチャが進化するにつれて、単一責任の Lambda 関数から Lambda-lith に移行することがよくありますが、どちらのアプローチにも相対的なトレードオフがあります。このブログでは、読み取りと書き込みの操作ごとにワークロードを分離することで、両方のアプローチの長所を活かす方法を紹介しました。 この 3 つのアプローチはいずれもサーバーレス API を設計する上で有効であり、何のために最適化するのかを理解することが、最適な決断を下すための鍵となります。アプリケーションで表現すべきコンテキストとビジネス要件を理解することが、特定のワークロード内で考慮すべきトレードオフにつながることを忘れないでください。広い視野を持ち、問題を解決し、セキュリティ、開発体験、コスト、保守性のバランスをとるソリューションを見つけましょう。 その他のサーバーレス学習リソースについては、 Serverless Land をご覧ください。 この記事は、テクニカルインストラクターの青木克臣が翻訳しました。 原文は こちら です。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の生成 AI 基盤モデル・大規模言語モデル（以下、LLM）の開発を支援する AWS LLM 開発支援プログラム を発表しました。 本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。 そして 2024 年 1 月 31 日に、本プログラムにおける支援対象の企業・団体が集まり成果を共有する、AWS LLM 開発支援プログラム 成果発表会が開催されました。ここではそのレポートをダイジェスト形式でお届けします。 ご挨拶 AWS ジャパン 執行役員 デジタルサービス事業統括本部 統括本部長 佐藤 有紀子 イベント冒頭では、AWS ジャパン 執行役員 デジタルサービス事業統括本部 統括本部長 佐藤 有紀子より開会のご挨拶をしました。AWS LLM 開発支援プログラムは 2023 年 7 月に開始し、これまで中間報告会や AWS ジャパンと各企業・団体とのさまざまなコミュニケーションを経たうえで今回のイベントに至りました。佐藤は本プログラムのエグゼクティブスポンサーとして、企画の段階から関わっております。 「私たちが企業・団体のみなさまとともに目指したのは、日本の生成 AI のイノベーションの加速です。日本のビジネスや言語環境、企業の状況に合った LLM が求められていると考えて、AWS LLM 開発支援プログラムを立ち上げました」と佐藤は語りました。 日本における生成 AI の利活用が本格的になっていく中で、LLM はより重要な位置付けになっていくと考えます。「プログラム実行委員から、本プログラムに関する学びをみなさまに共有させていただきたく存じます」と結びました。 AWS LLM 開発支援プログラム Program Results AWS LLM 開発支援プログラム 実行委員 宇都宮 聖子 次に、AWS LLM 開発支援プログラム 実行委員の宇都宮 聖子が登壇。本プログラムで得られた成果について、ショートサマリーをお話ししました。本プログラムでは 2023 年 7 月のプログラムローンチ以降、成果発表会まで約半年の期間で 17 社という多くの企業・団体にご参画いただきました。 セッション内で、宇都宮は多くの開発者の方々にご利用いただいた AI アクセラレーター AWS Trainium をタイムリーにサポートする AWS Neuron SDK の変遷についても言及。本支援プログラムの開始以降、AWS Neuron SDK はこのプログラムでの LLM 開発を強力にサポートすべく、2023 年 12 月までの間に多くのソフトウエアアップデートが行われたことを解説しました。 また、サービスの利用方法について実践形式で学ぶ Prototyping Camp を開催するなど、AWS ジャパンでは企業・団体の方々に効率良く開発を進めていただくための技術支援も行ってきました。2023 年 11 月には、プログラムの中間報告会にて、LLM 開発を国内でリードする技術者同士で、LLM開発の技術的な難しさやビジネス化への課題について、パネルディスカッション等を通じて技術交流を行いました。そして、2023 年 9 月以降にはプログラム参画企業合計 9 社より報道発表がリリースされました。 成果発表 Part1 ここからは、各社による成果発表がスタート。Part1 では、NTT人間情報研究所とストックマーク株式会社、株式会社リコーの 3 社が登壇しました。 NTT人間情報研究所 NTT人間情報研究所 上席研究員 西田 京介 氏 まずは NTT人間情報研究所 上席研究員 西田 京介 氏による発表。NTT グループは IOWN（Innovative Optical and Wireless Network）技術を中心として、サステナブルな社会の実現に取り組んでいます。大量の計算機資源を必要とする大きな AI ではなく、専門性や個性を持った小さな AI の集合知による社会課題解決を目指し、小型で性能の良い LLM「tsuzumi」の研究開発を行っています。 メディカル領域やソフトウエア開発といった、ドキュメント内に専門用語や業界特有の表現が多く含まれる領域においては、既存の汎用 AI では十分な性能を発揮しないケースがあります。「tsuzumi-7B」は Rakuda ベンチマークにおいて、こうした業界特有のデータに対してもカスタマイズが可能であるため、AI を活用する領域を広げることができます。 また、顧客サポート領域では顧客体験向上のために、図表などのマニュアル類の読解と顧客情報の解析によるパーソナライズが不可欠です。「tsuzumi」は世界トップクラスの日本語処理能力を有しており、かつ図表読解も可能なため、コンタクトセンターや相談チャットボットといった顧客サポート領域での活用に向いています。 プログラムの中で得られたベネフィットとして、 Amazon EC2 P5 インスタンスの利用により最新の NVIDIA H100 Tensor Core GPU 96基を迅速に調達できたこと、Elastic Fabric Adapter (EFA) の高速なノード間通信による高速・高効率な学習が行えたこと、LLM 学習ライブラリを AWS 上で技術検証することによりスムーズな環境移行を行えたこと、GPU クラスタ構築・運用のための技術支援を受けられたこと、などを紹介されていました。 ストックマーク株式会社 ストックマーク株式会社 共同創業者 CTO 有馬 幸介 氏（写真左）、VP of Research 近江 崇宏 氏（写真右） 次に登壇したのはストックマーク株式会社 共同創業者 CTO 有馬 幸介 氏とVP of Research 近江 崇宏 氏。有馬 氏は同社が LLM の自社開発を行う理由として「産業界では、ChatGPT よりもさらにハルシネーション（誤情報の出力）が抑止された信頼性の高い LLM が求められている」というモチベーションを語りました。 ハルシネーション抑止は LLM の知識量にも大きく依存します。グローバルでよく利用される LLM では学習データの 0.1% 程度しか日本語が含まれておらず、とりわけ日本国内のビジネス系知識に不足があるといいます。ストックマーク社はその品質ではエンタープライズサーチや素材・技術用途探索などのアプリケーションで顧客のニーズに応えきれないと判断し、自社開発を決意しました。 近江 氏は AWS LLM 開発支援プログラムにおける具体的な検証内容や成果などを発表。実用的なビジネス領域に対応するため、公開データだけでなくビジネスドメインの独自 Web コーパスや特許のデータを含めた、合計 2,200 億トークン日本語テキストデータを使用し、130 億パラメータ LLM をゼロから学習させたことなどを説明しました。 今回ストックマーク社は AWS Trainium を搭載した EC2 Trn1 インスタンスを用いて独自 LLM の開発を行いました。その際、trn1.32xlarge を 16 インスタンス用いることで、約 30 日といった短期間で迅速に開発が行えたといいます。また、開発した Stockmark-13b を自社サービスへ導入するため、AWS Inferentia2 による推論も検証を進めています。 株式会社リコー 株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長 鈴木 剛 氏 次に株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長 鈴木 剛 氏が登壇。セッション冒頭で、英語 LLM に比べて日本語 LLM の開発が遅れているという見方について触れ、産業で使い倒せる LLM を作る、すなわち、ビジネスで使える十分な品質の文章を生成できる LLM を作ることを目指して日英バイリンガル LLM を開発したことを説明しました。 リコーが重視したのは、データの質と量、そして学習戦略をいかに組み上げるかという観点です。モデルのアーキテクチャは日進月歩で新しいものが出ていますが、学習戦略やデータは企業の開発技術として注力すべきであるとし、カリキュラム学習戦略の例をご紹介頂きました。英語で学習された Llama 2 13B Chat の初期重みに、はじめから難易度の高い日本語データを多く入れても、忘却効果が出てしまいうまく学習が進みません。そのため、初期段階では英語を多く混ぜ、続いて多量低品質な英語・日本語データを投入し、最後は頑健な推論性能の底上げを狙うために高品質な日本語データを学習させるという戦略をとりました。 計算環境は Amazon EC2 Trn1 インスタンスを利用。プログラムの支援により調達した 64 インスタンスの trn1.32xlarge (1,024 Trainium チップ、2,048 Neuron コア) により、大規模な分散学習を行いました。これだけ大規模な学習になるとノード不良が避けられませんが、AWS の技術メンバーが密に並走することにより迅速な復旧が可能だったといいます。また、復旧のため実装されたノード不良検知・自動ジョブ再投入などの機能を SDK として公開するといった改善プロセスに関しても信頼と感謝の言葉を頂きました。 日本語ベンチマークツール llm-jp-eval を用いた130億パラメータ LLM との性能比較では、産業応用で重要となる論理的な推論性能に関して良好な結果を得られたといいます。今後も、本プログラムで開発した130億パラメータモデルのカスタマイズや、700億パラメータ規模のさらなる大規模モデルの開発に取り組んでいく展望を述べました。 成果発表 Part2 プログラムの後半パートでは、以下の企業が成果発表を行いました。 株式会社サイバーエージェント（左上）、Sparticle株式会社（右上）、カラクリ株式会社（左下）、株式会社Poetics（右下） 株式会社サイバーエージェント AI事業本部 極LP/基盤モデル事業部 石上 亮介 氏 ●  AWS Trainium による LLM 開発の技術・次世代アーキテクチャ検証。学習データに含まれる日本語・英語の割合を変えた性能や、Grouped Query Attention (GQA) への拡張。RetNet や Sparse Mixture of Experts (MoE) などのアーキテクチャ検証。 Sparticle株式会社 執行役員 藤井 秀樹 氏 ●  音声認識に加えて視覚情報を含めたマルチモーダル AI 開発を目指す。本プログラムでは独自 LLM により高い日本語性能を達成。自律型エージェントの実現も視野に入れる。 カラクリ株式会社 取締役 CPO 中山 智文 氏 ●  カスタマーサポート領域での AI Chat 提供。Llama 2 70B をベースとした事前学習とファインチューニングを、独自収集カスタマーサポートコーパスを含むデータで実施。Japanese MT-Bench において日本語モデルの中で最高性能。 株式会社Poetics AIエンジニア・NLPリサーチャー 河東 宗祐 氏 ●  オンライン商談解析サービス Jamroll を提供。自動音声書き起こし (Automatic Speech Recognition; ASR) 話し言葉データを用いた、対話に特化した LLM の開発。4台の trn1.32xlarge を用いて、NeuronX Distributed による分散学習で Llama 2 7B を継続事前学習。 株式会社松尾研究所（左上）、株式会社リクルート（右上）、株式会社わたしは（左下）、株式会社Lightblue（右下） 株式会社松尾研究所 リサーチエンジニア　松島 創一郎 氏 ●  東京大学大学院工学系研究科松尾研究室とビジョンを共有しながら先端技術の社会実装を行なっており、本プログラムではリテール業界や旅行業界などに向けた LLM を用いた推薦システムに取り組んだ。推薦候補をユーザーに提示する前にリランキングを行う LLM を開発。旅行・予約サイトのデータを用いて、ELYZA-japanese-Llama-2-7b をベースに学習。 株式会社リクルート データ推進室 桐生 佳介 氏 ●  リクルートが提供する顧客・クライアントの接点を作るプロダクトにおいて、労働人口減少に伴うスケーラビリティに課題があり、ビジネスドメイン特化の LLM でユーザー体験の向上を見込む。ELYZA-japanese-Llama-2-7b-fast と Llama-2-13b-chat-hf に対して、オープンデータと自社コーパスを用いて継続学習と Instruction Turing を実施し、継続事前学習を施した自社モデルで QA 回答と文章要約の性能向上を確認。AWS Trainium の使用感として良かった点で、インスタンス確保が柔軟であったことと AWS ParallelCluster による分散学習環境構築の容易さが挙げられた。 株式会社わたしは CTO 小橋 洋平 氏 ●  ユーモアを志向し、ズレた会話を扱える基盤モデルの開発と、大喜利 AI など目的に応じたチューニングを実施。EC2 trn1.32xlarge を 4 インスタンス用いた分散学習で Llama 2 13B に対して継続事前学習を行い、ファインチューニングと DPO により大喜利 AI を構築。このモデルによる日本語・英語での大喜利性能について、いくつか例が紹介された。 株式会社Lightblue 取締役 谷口 俊一 氏 ●  特定業務・タスク特化の LLM を志向し、推論コストにおける優位性も期待できる小規模軽量 LLM を開発。TinyLlama-1.1B をベースモデルとし、独自日本語コーパスを用いた AWS Trainium での継続事前学習により Karasu-1.1B を開発。AWS VPN や AWS Direct Connect (専用線接続) などの閉域網での提供を検討。 Turing株式会社（左上）、株式会社ユビタス（右上）、rinna株式会社（左下）、株式会社Preferred Networks（右下） Turing株式会社 Director of AI 山口 祐 氏 ●  完全自動運転を目指し、運転時の外部情報として LLM に視覚を与える学習フレームワーク Heron を開発。NVIDIA H100 GPU を搭載した EC2 p5.48xlarge インスタンスにより、画像 + LLM の 70.3B マルチモーダル基盤モデルのフルパラメータファインチューニングを実施。また、自動運転用データセットの生成・評価にも p5.48xlarge インスタンスを活用。 株式会社ユビタス 大畑 浩司 氏 ●  エンターテイメント (ゲーム・アニメ・映画) や観光・レジャーに特化した LLM や Graph Diffusion Model を開発。国立台湾大学との共同研究による台湾 LLM 13B (Taiwan-LLM-13B-v2.0-base) の開発・公開や、ユビちゃん (ゲーム攻略アシスタントなどに使われる AI キャラクター) の開発で AWS を活用。 rinna株式会社 Research and Data Manager 沢田 慶 氏 ●  中国語・英語を主データとして学習された Qwen モデルをベースに継続事前学習。Nekomata 14B は Qwen 14B に対して 66B トークンの日本語データで継続事前学習、EC2 trn1.32xlarge で 16インスタンス約6.5日、オンデマンド価格で800万円ほど、LLM プログラムの支援をうけ実施。SFT による対話応答や 4bit 量子化版も含め 7B, 14B モデルを公開。 株式会社Preferred Networks Karim Hamzaoui 氏 ●  本プログラムでは画像のモダリティを扱える汎用的な視覚基盤モデルを開発。画像タスクの学習には大容量メモリを必要とするため、NVIDIA H100 Tensor Core GPU (80 GB GPU メモリ) を搭載した EC2 p5.48xlarge インスタンスを活用し複数タスクの表現方法、タスクの学習順番・バランス、言語と画像のアラインメントの効率化などに取り組んだ。今後も本プログラムで確立した開発手法を踏まえ、100B/1T パラメータからなる PLaMo をベースとしたマルチモーダル基盤モデルの開発を推進。 ご講評 経済産業省 商務情報政策局 情報産業課 ソフトウエア・情報サービス戦略室長 渡辺 琢也 氏（写真左） 経済産業省 商務情報政策局 情報産業課企画官 小川 宏高 氏（写真右） 各社による成果発表の後、経済産業省 商務情報政策局 情報産業課 ソフトウエア・情報サービス戦略室長の渡辺 琢也 氏がコメントをしました。近年、LLM は大きな注目を集めています。渡辺 氏は、これまでの人類の歴史のなかで自動車やパソコン、スマホといった人間の能力をエンパワーメントするような技術がイノベーションを起こしてきたことについて触れ「間違いなく、LLM は次のイノベーションを起こす可能性を秘めた技術です。だからこそ世界中で注目されているのでしょう」と述べました。 そして、今後の日本で発生する労働者不足の課題を解決するうえでも、LLM を活用して生産性を向上させることが重要であると言及。「計算資源をはじめとしたインフラの確保や、開発者同士やユーザーとのネットワーキング構築の機会の創出、イノベーションを阻害しないルールの創設は政府の責務だと思っております」と語りました。 続いて、経済産業省 商務情報政策局 情報産業課企画官 小川 宏高 氏は登壇した各社のプレゼンテーションを講評。スクラッチでのモデル開発や継続事前学習、ファインチューニング、各種の技術検証など、各社がそれぞれの強みを活かして研究・開発を行っていることに対して「みなさまの技術力の高さに、大変心強い思いをしております」と総括しました。 ご挨拶 AWS ジャパン 代表執行役員社長 長崎 忠雄 イベント最終盤では、AWS ジャパン 代表執行役員社長 長崎 忠雄がご挨拶をしました。お集まりいただいた関係者の方々に感謝の言葉を伝えたうえで「本日で AWS LLM 開発支援プログラムは終了しますが、LLM の開発はこれで終わりではありません。技術の社会実装が肝であるため、私たち AWS は引き続き各企業・団体を支援していきます」と述べました。 そのうえで、「LLM の社会実装ができるようになれば、それがひいては日本の国力の向上につながります。私たち AWS が、日本そのものの進歩に貢献できればと思っております」と結びました。

この記事は、James Eastham、Norm Johanson、Ulili Nhaga が寄稿しました。日本語訳はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 はじめに .NET 8 は、2023 年 11 月にリリースされたクロスプラットフォーム .NET の最新の長期サポート (LTS) バージョンです。.NET 8 にはパフォーマンスの改善、コンテナの拡張機能、C# 言語の簡略化された構文、フルスタック Web アプリケーションのための Blazor サポート、ネイティブ Ahead of Time コンパイル  (Native AOT) の ASP.NET Core での部分サポートが含まれています。この記事では、.NET 8 をサポートする AWS コンピューティングサービスとツールを確認し、開発者向けのリソースを紹介します。 .NET の古いバージョンを実行している場合、.NET 7 と .NET 6 の両方が 2024 年にサポート終了となることに注意してください。 Microsoft の .NET サポートポリシー によると、.NET 7 のサポートは 2024 年 5 月 14 日に、.NET 6 のサポートは 2024 年 11 月 12 日に終了します。.NET 8 のサポートは 2026 年 11 月 10 日までです。 コンピューティング サービス ワークロードがセルフマネージド型のもの、マネージドサービス上で実行されるもの、コンテナを使用するもの、サーバレスなものに関わらず、AWS 上で .NET 8 を使用できます。.NET 8 は現在、 Amazon Elastic Compute Cloud (Amazon EC2)、 AWS Elastic Beanstalk 、 Amazon Elastic Container Service (Amazon ECS)、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS App Runner 、 AWS Lambda 上で実行できます。 Amazon EC2 Amazon EC2 は、プロセッサ、ストレージ、ネットワーキングの選択してインフラストラクチャを細かく管理できる、広範囲で高度なコンピューティング機能を提供します。お客様は 400 を超える インスタンスタイプ で .NET 8 をインストールできます。 EC2 インスタンスに .NET 8 をインストールするには、インスタンスの起動時に ユーザーデータ コマンドを指定します。 次の例は、Amazon Linux 2023 インスタンスに .NET 8 をインストールする方法を示しています。 #!/bin/bash sudo rpm  --import   https://packages.microsoft.com/keys/microsoft.asc sudo wget  -O  /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/37/prod.repo sudo dnf install  -y dotnet-sdk-8.0 dotnet  --version  > /tmp/dotnet-version Linux への.NET のインストール方法は、 https://learn.microsoft.com/ja-jp/dotnet/core/install/linux#packages で確認できます。.NET のインストールスクリプトは、 https://learn.microsoft.com/ja-jp/dotnet/core/install/linux-scripted-manual#scripted-install で入手できます。 AWS Systems Manager サービスの自動化機能を使用して、オートメーションドキュメントを使って .NET ランタイムを自動的にインストールできます。また、 EC2 Image Builder サービスを使用して、.NET ランタイムがプリインストールされた EC2 イメージを事前に作成できます。 AWS Elastic Beanstalk Elastic Beanstalk は、アプリケーションを実行するインフラストラクチャーを意識することなく、AWS クラウドでアプリケーションをすばやくデプロイおよび管理できるマネージドサービスです。EC2 リソースは AWS アカウントですべて表示され、それらにアクセスできます。 2023/12/05 のプラットフォームアップデート より、Elastic Beanstalk Windows が .NET 8 をサポートするようになりました。 Elastic Beanstalk Linux はこの記事を書いている時点で .NET 6 ランタイムをサポートしていますが、次のいずれかのオプションを使用して .NET 8 をデプロイできます: .NET Core on Linux プラットフォーム用のアプリケーションのバンドル  (AWS) および .NET アプリケーションの発行の概要 (Microsoft) で説明されている自己完結型アプリケーションを提供できます。Elastic Beanstalk Linux で .NET 8 を使用するもう 1 つの方法は、 Docker コンテナからのデプロイ です。 AWS Lambda AWS Lambda は .NET 8 ランタイムをサポートしています。AWS Lambda コンソールには、図 1 に示すように、.NET 8 (C#/F#/PowerShell) のランタイムオプションがあります。.NET 8 の Lambda 関数の作成と更新、およびネイティブ AOT の使用の詳細については、 AWS Lambda の .NET 8 ランタイムのご紹介（英文） を参照してください。 AWS Lambda で .NET 8 アプリケーションを実行するその他の方法もあります。 カスタムランタイム を作成したり、 コンテナーをデプロイ したり、.NET 8 のネイティブ AOT コンパイルを使用してネイティブコードを Lambda に公開することができます。 図1: AWS Lambda コンソールの .NET 8 オプション ビデオ: .NET 8 ネイティブ AOT Lambda 関数を構築する最もシンプルな方法 ブログ: .NET 7 を使用して AWS Lambda でサーバーレスの .NET アプリケーションを構築する AWS .NET Lambda パッケージ が .NET 8 をターゲットに更新され、ネイティブ AOT の警告に対処するようになりました。これにより、ネイティブ AOT Lambda 関数でそれらをより簡単かつ安全に使用できるようになります。 .NET Lambda アノテーション フレームワークは、プログラミング モデルを簡素化し、C# でより自然に .NET Lambda 関数を記述できるようにします。カスタム ランタイムやネイティブ Ahead of Time コンパイル (Native AOT) を使用する場合、このフレームワークにより、 Lambda ランタイムを手動でブートストラップする必要がなくなり、Main メソッドを自動生成できます。詳細は、 .NET Lambda アノテーション設計 – Main の自動生成 を参照してください。 コンテナ Windows または Linux コンテナ上で実行される .NET アプリケーションを、 Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) にデプロイできます。 AWS Fargate は、コンテナインフラストラクチャを自分で管理する必要なく、ECS および EKS コンテナのライフサイクルを実行および管理するために使用できるサービスです。 AWS App Runner は、コンテナ化された Web アプリケーションや API をすぐにデプロイできる、フルマネージドなサービスです。トラフィックのニーズに応じて自動的にスケールアップ/ダウンします。.NET 8 アプリケーションで使用するには、.NET 8 アプリケーションのイメージを Amazon Elastic Container Registry (ECR) にアップロードし、 ソースイメージ のサポートを利用して、AWS App Runner がアプリケーションの起動、実行、スケール、ロードバランシングを設定します。 .NET 8 アプリケーションをコンテナ内に Elastic Beanstalk にデプロイできます。詳細は、 Docker コンテナからの Elastic Beanstalk アプリケーションのデプロイ を参照してください。 セキュリティと診断 AWS X-Ray AWS X-Ray は、マイクロサービスアーキテクチャを使用して構築された分散アプリケーションなどを分析およびデバッグするのに役立ちます。.NET 8 アプリケーションは、 .NET 用 AWS X-Ray SDK と OpenTelemetry .NET 用 AWS ディストリビューション を使用して、AWS X-Ray と統合できます。 現時点では、ネイティブ AOT .NET アプリケーションで AWS X-Ray を使用することはおすすめしません。 ツール、ライブラリ、SDK AWS で古いバージョンの .NET を使用していた場合は、開発マシンにインストールされている AWS ツールを更新することをおすすめします。 .NET 用 AWS SDK AWS SDK for .NET を使用すると、.NET 開発者は AWS サービスをアプリケーションコードに親しみやすく一貫した方法で統合できます。バージョン 3.7.300 から、SDK に .NET 8 ターゲットフレームワークが追加され、すべてのトリミング警告に対処することでネイティブ AOT との互換性が実現しました。このライブラリは NuGet から利用できます。 開発者ーガイド の AWS SDK for .NET の使用方法をご覧ください。 AWS CodeBuild AWS CodeBuild は、開発者がソースコードから自動的にアプリケーションをビルドできるように支援する、フルマネージドなサービスです。CodeBuild サービスでは、ビルドしているアプリケーションのニーズに合わせて、ビルド環境をカスタマイズできます。これには、追加の .NET ランタイムをインストールする機能が含まれます。アプリケーションの buildspec.yml ファイルに次のスニペットを追加することで、.NET 8 アプリケーションのビルドをサポートできます。 install: commands: - curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --channel 8.0 これにより、CodeBuild のインストールフェーズの一部として、.NET 8 SDK が自動的にダウンロードおよびインストールされます。 AWS Deploy Tool for .NET AWS Deploy Tool for .NET コマンドラインインターフェース (CLI) は、.NET アプリケーションのコンピューティング推奨事項を提供し、数ステップで AWS にデプロイする対話型アシスタントです。Deploy Tool は、Amazon ECS や AWS App Runner などのコンテナベースのサービス用にコンテナイメージを作成したり、Elastic Beanstalk で .NET の自己完結型パブリッシングを使用することにより、.NET 8 アプリケーションをサポートします。 AWS Toolkit for Visual Studio AWS Toolkit for Visual Studio は、Windows の Microsoft Visual Studio 向けの拡張機能で、開発者が Amazon Web Services を使用して .NET アプリケーションをより簡単に開発、デバッグ、デプロイできるようにします。Visual Studio 2022 は .NET 8 開発をサポートしています。 図2: Visual Studio の .NET 8プロジェクト Toolkit の Publish to AWS 機能は、.NET 用の AWS Deploy Tool と統合されており、Visual Studio からさまざまな AWS サービスに .NET 8 プロジェクトをデプロイできます。ASP.NET Core プロジェクトを Amazon ECS、AWS App Runner、Elastic Beanstalk Windows、Elastic Beanstalk Linux、または Amazon Elastic Container Registry (Amazon ECR) にデプロイできます。 図3: Toolkit for Visual Studio を使用した .NET 8 ASP.NET Core プロジェクトの AWS への公開 Visual Studio 2022 用の AWS Toolkit は、 Visual Studio Marketplace からダウンロードできます。 すでに Visual Studio 用の AWS Toolkit を使用している場合は、Visual Studio の 拡張機能の管理 > 更新の確認 から最新バージョンにアップグレードすることをおすすめします。 .NET モダナイゼーションツール AWS は、アーキテクト、開発者、IT プロフェッショナルが .NET ワークロードをモダナイズするのに役立つ支援ツールを提供しています。現在、次の AWS モダナイゼーションツールが .NET 8 をサポートしています: AWS App2Container (A2C) は、アプリケーションをコンテナ化するコマンドラインツールです。 正しい依存関係、ネットワーク構成、Amazon ECS または Amazon EKS のデプロイ手順を使用して構成されたコンテナイメージを自動的に生成します。 A2C は現在 .NET 8 ランタイムバージョンを検出できるようになり、対応するランタイムベースイメージを使用してアプリケーションをコンテナ化できます。 AWS Microservice Extractor for .NET は、人工知能とヒューリスティックを使用してモノリシックコードを評価、可視化し、マイクロサービスの候補を推奨するアドバイザーとして機能する支援ツールです。また、マイクロサービスの抽出を簡素化するロボットビルダーとしても機能します。Microservice Extractor は現在、.NET 8 アプリケーションの解析、グルーピング、抽出をサポートしています。統合されたストラングラーフィグポーティング機能により、数百のプロジェクトと数千のクラスで構成される大規模な .NET Framework ベースのアプリケーションを管理可能なグループに分割し、それらを直接 .NET 8 に移植することもできます。 Migration Hub Strategy Recommendations (MHSR) は、アプリケーションの実行可能なトランスフォーメーションパスの戦略的な推奨を提供することで、移行とモダナイゼーションの取り組みの計画を支援します。MHSR は現在 .NET 8 アプリケーションを検出し、推奨を提供できるようになりました。 AWS Toolkit for .NET Refactoring は、レガシーな .NET アプリケーションを AWS 上のクラウドベースの代替手段にリファクタリングするのに役立つ Visual Studio 拡張機能です。 互換性アセスメントレポートを提供し、コードの移植を支援します。.NET Refactoring Toolkit は現在、アセスメント、移植、テストデプロイの対象として .NET 8 をターゲットにできます。 AWS で .NET ワークロードの計画、移行、モダナイゼーションを行う際、これらの支援ツールを使用することで .NET 8 を最大限活用できます。.NET のモダナイゼーションのユースケースとツールの詳細は、AWS 上の .NET 開発者センターの「 AWS で .NET ワークロードをモダナイズ 」をご覧ください。 まとめ AWS のさまざまなコンピューティングサービス上で、今すぐ .NET 8 ワークロードを実行できます。.NET 用 SDK、複数の開発者向けツール、複数の .NET モダナイゼーションツールも .NET 8 をサポートしています。.NET 6 または .NET 7 上で既存の AWS ワークロードがある場合は、サポート終了に至る前に .NET 8 へのアップグレードを積極的に行うことをおすすめします。AWS の .NET 関連の最新情報については、AWS の .NET デベロッパーセンター をご覧ください。 投稿者について David Pallmann AWS の EC2 チームのシニアプロダクトマネージャーです。彼のミッションは、AWS を .NET 開発者にとってワールドクラスのエクスペリエンスにすることです。David は以前、エンジニアリング、コンサルティング、プロダクト、テクニカルマネージャの役割を担っていました。彼は WCF に取り組み、後に最初の .NET ベースのエンタープライズサービスバスである Neuron ESB を開発しました。X では @davidpallmann でフォローしてください。

3月7日は、 Amazon Relational Database Service (Amazon RDS) のすべてのデータベースエンジンに使用できるプロビジョンド IOPS (PIOPS) io2 Block Express ストレージボリュームの提供が開始されたことを皆さんにお知らせしたいと思います。Amazon RDS は、データベースワークロードのパフォーマンス要件に応じてさまざまなストレージタイプから選択する柔軟性を提供します。io2 Block Express ボリュームは、低レイテンシーで優れたパフォーマンスとスループットを必要とするミッションクリティカルなデータベースワークロード向けに設計されています。 I/O 集約型ワークロードのための低レイテンシーと高可用性 io2 Block Express ボリュームを使用することで、データベースワークロードは安定したミリ秒未満のレイテンシーと、io1 ボリュームよりも優れた 99.999 パーセントの耐久性からメリットを得るだけでなく、プロビジョニングされたストレージからは、io1 と同じ価格で 20 倍の IOPS (1 GBあたり最大1,000 IOPS) も実現できます。io1 ボリュームから io2 Block Express ボリュームへのアップグレードはダウンタイムなしで実行できるため、アプリケーションのパフォーマンスと信頼性が大幅に向上する一方で、ストレージコストは増加しません。 デジタル製品を設計して構築するチームのための主要プラットフォームである Figma のエンジニアリングディレクターを務める Samir Goel 氏は、このように語っています。「2 週間以内で主な Amazon RDS インスタンスのすべてを io2 Block Express に移行しました。 Io2 Block Express は、Figma のデータベースレイヤーの可用性に大きな影響をもたらしています。私たちは io2 Block Express によるパフォーマンスの一貫性を高く評価しており、当社の観測によると、レイテンシーの変動は 0.1 ミリ秒未満です」。 io2 Block Express ボリュームは、最大 64 TiB のストレージ、最大 256,000 のプロビジョンド IOPS、4,000 MiB/秒の最大スループットをサポートします。io2 Block Express ボリュームのスループットは、プロビジョンド IOPS の量とボリュームストレージのサイズに応じて異なります。各データベースエンジンとストレージサイズの対応範囲は以下のとおりです。 データベースエンジン ストレージサイズ プロビジョンド IOPS 最大スループット Db2、MariaDB、MySQL、PostgreSQL 100 GiB から 65,536 GiB まで 1,000～256,000 IOPS 4,000 MiB/秒 Oracle 100 GiB から 199 GiB まで 1,000～199,000 IOPS 4,000 MiB/秒 Oracle 200 GiB から 65,536 GiB まで 1,000～256,000 IOPS 4,000 MiB/秒 SQL Server 20 GiB から16,384 GiB まで 1,000～64,000 IOPS 4,000 MiB/秒 io2 Block Express ボリュームの使用開始方法 Amazon RDS コンソール を使用して、io2 Block Express ボリュームを使用して設定された新しい RDS インスタンスを作成するか、io1、gp2、または gp3 ボリュームを使用する既存のインスタンスを変更することができます。 以下は、io2 Block Express ボリュームを使用して Amazon RDS for PostgreSQL インスタンスを作成する方法です。 まず、エンジンやバージョンなどの基本情報から始めます。次に、 [ストレージタイプ] オプションから [プロビジョンド IOPS SDD (io2)] を選択します。 以下の AWS CLI コマンドを使用して、io2 Block Express ボリュームを使用する新しい RDS インスタンスを作成します。 aws rds create-db-instance --storage-type io2 --db-instance-identifier new-db-instance --db-instance-class db.t4g.large --engine mysql --master-username masteruser --master-user-password <enter password> --allocated-storage 400 --iops 3000 同様に、io2 Block Express ボリュームを使用するように既存の RDS インスタンスを変更するには、以下のコマンドを実行します。 aws rds modify-db-instance --db-instance-identifier existing-db-instance --storage-type io2 --allocated-storage 500 --iops 3000 --apply-immediately 知っておくべきこと io2 Block Express ボリュームは、 AWS Nitro System インスタンスを使用するすべての RDS データベースで利用できます。 io2 Block Express ボリュームがサポートする、IOPS と割り当てられたストレージとの比率は 1000:1 です。例を挙げると、RDS for PostgreSQL インスタンスでは、256 GiB 以上のボリューム で最大 IOPS をプロビジョニングできます(1,000 IOPS × 256 GiB = 256,000 IOPS)。 AWS Nitro System を基盤としない DB インスタンスでは、IOPS と割り当てられたストレージとの比率は 500:1 です。この場合は、512 GiB のボリュームで最大 IOPS を実現できます (500 IOPS x 512 GiB = 256,000 IOPS)。 今すぐご利用いただけます Amazon RDS io2 Block Express ストレージボリュームは、すべての RDS データベースエンジンでサポートされており、米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ストックホルム)、および中東 (バーレーン) の各リージョンで利用できます。 io1 ボリュームと io2 Block Express ストレージボリュームの料金と請求に関しては、どちらも同じ料金で請求されます。詳細については、 Amazon EBS の料金 ページを参照してください。 プロビジョンド IOPS SSD ストレージの詳細については、「 Amazon RDS ユーザーガイド 」をお読みください。 — Abhishek 原文は こちら です。

AWS ヒーロー は、人々のインスピレーションとなるソートリーダーであり、努力を惜しむことなくさまざまな方法で知識を共有しています。地域のミートアップ、 AWS Community Day 、re: Invent のイベントでは、ヒーローたちが講演しているのを見ることができます。これらのテクニカルエキスパートたちは、学ぶことを決してやめず、問題の解決と、コミュニティが AWS でよりすばやく構築することを可能にするコンテンツの作成に情熱を注いでいます。3月6日は、2024 年最初のヒーローたちを発表したいと思います。 新しいヒーローに拍手を送りましょう! Awedis Keofteian 氏 – レバノン、ベイルート コミュニティヒーローである Awedis Keofteian 氏は、Anghami で DevOps エンジニアを務めています。DevOps で優れた実績を積んできた Keofteian 氏は、最新のテクノロジーを活用して Anghami のクラウドベースアーキテクチャのスケーラビリティ、信頼性、効率性を向上させています。Keofteian 氏 は AWS コミュニティビルダーとしてスタートしましたが、やがてベイルートで AWS User Group のリーダーとしての役割を担うようになりました。AWS コミュニティを育成し、成長をサポートすることに情熱を注いでおり、DevOps、自動化、サーバーレス、クラウドテクノロジーの全体におよぶ知識を共有しています。 Daniel Aniszkiewicz 氏 – ポーランド、ヴロツワフ セキュリティヒーローである Daniel Aniszkiewicz 氏 は、Algoteque International Hub でシニアソフトウェアエンジニアを務めています。Wrocław AWS User Group の共催者である Aniszkiewicz 氏は、地域の AWS コミュニティの成長とエンゲージメントへの貢献に情熱を注いでいます。Aniszkiewicz 氏 は経験豊富な講演者でもあり、re: Invent、AWS ミートアップ、AWS Community Day でのプレゼンテーションなど、知識を他の人と共有することが好きです。特に、ワークショップ、ブログ記事、IaC テンプレート、オープンソースプロジェクトを通じた Amazon Verified Permissions と Cedar の推薦に焦点を合わせています。 Hazel Sáenz 氏 – グアテマラ サーバーレスヒーローである Hazel Sáenz 氏 は、Cognits でソフトウェアアーキテクトを務めています。Sáenz 氏の主な焦点は、AWS を使用してオンプレミスアプリケーションをクラウド環境にモダナイズすることであり、主にサーバーレスフレームワークで高負荷アーキテクチャを設計しています。Sáenz 氏は、地域および国際イベントでのテックトーク、AWS Summit、AWS Community Day、ミートアップへの参加、英語とスペイン語両方での技術論文の執筆を通じてコミュニティと知識を共有することを楽しんでいます。また、Sáenz 氏は AWS User Group Guatemala のリーダーでもあり、インクルーシブなイベントの企画やコミュニティとの知識の共有で能力を発揮しています。 後藤健太氏 – 日本、東京 DevTools ヒーローである 後藤健太氏 は、バックエンドテクニカルリードを務めるだけでなく、AWS CDK の熱心なコントリビューターでもあります。後藤氏は、AWS CDK のトップコントリビューターおよび信頼の置けるレビュアーとして選出されており、コミュニティ主導の CDK Construct ライブラリのメンテナーとしての役割も果たしています。カンファレンス講演者でもあり、2022 年と 2023 年に日本で開催された AWS Dev Day でプレゼンテーションを行いました。後藤氏はさらに、自作の AWS ツールや AWS CDK Construct ライブラリを開発および公開することで、オープンソースコミュニティに積極的に貢献しており、これらは世界中で使用されています。 Martin Damovsky 氏 – チェコ共和国、プラハ コミュニティヒーローである Martin Damovsky 氏 は、UDM (Unified Data Management) ソリューションを提供する AWS パートナー、Ataccama.com でクラウドガバナンスリードを務めています。AWS Control Tower Account Factory for Terraform、Cloud Intelligence Dashboard の他、 AWS Security Hub 、 Amazon GuardDuty 、 AWS Config などのセキュリティツールやガバナンスツールに特に関心を持っています。Damovsky 氏は AWS User Group Prague のリーダーであり、ブログやミートアップ、ポッドキャスト、カンファレンスでの講演を通じて、より広範な AWS コミュニティと知識を共有することを楽しんでいます。 Rafał Mituła 氏 – ポーランド、ワルシャワ コミュニティヒーローである Rafał Mituła 氏 は、Chaos Gears の Data & AI 部門でクラウドエンジニア兼アーキテクトを務めています。Mituła 氏は AWS コミュニティに積極的に参加しており、AWS User Group Warsaw のミートアップや AWS Community Day Poland カンファレンスを共催しています。Mituła 氏は、技術的および組織的な役割以外にも、カンファレンスで講演したり、AWS Data Engineering Immersion Day などの AWS とデータ分析を新しいビルダーに紹介することを目的としたワークショップをリードしたりすることで、専門知識を共有しています。 Sena Yakut 氏 – トルコ、イズミル セキュリティヒーローである Sena Yakut 氏 は、Lyrebird Studio でシニアクラウドセキュリティエンジニアを務めています。クラウドセキュリティの修士号を修めた Yakut 氏は、アーキテクチャ設計のためのセキュリティ要件を策定することで、AWS を使用した脅威管理、セキュリティ概念、およびサービスを提供しています。Yakut 氏は、さまざまなプラットフォーム全体でのブログ記事を通じて知識を共有しており、AWS Community Day Türkiye や DevOps Days Istanbul などのイベントでクラウドセキュリティに関するディスカッションに参加しています。活発なブロガーであり講演者でもあるYakut 氏は、AWS の新しいセキュリティ機能について学び、それらを他の人に伝えることを楽しんでいます。 Tiago Rodrigues 氏 – ポルトガル、リスボン コミュニティヒーローである Tiago Rodrigues 氏 は、AWS プレミアパートナー兼 AWS アドバンストトレーニングパートナーである tecRacer.com でシニアクラウドコンサルタントを務めており、オンプレミス環境からクラウドへの移行、アーキテクチャのモダナイゼーション、およびサーバーレスソリューションの実装を専門としています。その役割以外にも、知識の共有に熱心に取り組んでおり、AWS User Group Lisbon、教育ワークショップ、大学でのゲスト講義などの活動を通じて AWS コミュニティに積極的に貢献しています。教育とイノベーションに情熱を注いでいる Rodrigues 氏は、オープンソースのモバイルアプリである AWSary を開発しました。これは、ソリューションアーキテクチャダイアグラムと、AWS サービスに関するわかりやすいインサイトを提供するために設計された AWS ディクショナリです。 詳細はこちら AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローウェブサイト をご覧ください。 — Taylor 原文は こちら です。

このブログは 2023 年 11 月 24 日に Justin Leto (Sr. Solutions Architect) 、Emad Tawfik (Senior Solutions Architect) 、Juha Sarimaa (Senior Solutions Architect Storage Specialist) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 企業がクラウドガバナンスのプラクティスを進化させるにつれて、別のアカウントで作業する複数のチームがデータを共有する必要が生じる場合があります。 あるチームがあるアカウントでエンタープライズデータレイクを管理している一方で、データサイエンスチームが別のアカウントで高性能コンピューティング (HPC) のユースケースを開発している場合があります。お客様は低コストのオブジェクトストレージを活用し、追加でデータをコピーすることなく、高性能ファイルシステムから迅速にこのデータを利活用し、 HPC ユースケースをサポートしたいと考えています。 Amazon FSx for Lustre は、AWS 上の機械学習 (ML) と高性能コンピューティング (HPC) のユースケースを加速するための重要な構成要素となっています。Amazon FSx for Lustre は、サブミリ秒のレイテンシー、最大数百 GB / 秒のスループット、数百万 IOPS を提供する、完全に POSIX 準拠の高性能ファイルシステムです。 これは Amazon Simple Storage Service (Amazon S3) とシームレスに統合されており、クラウド利用者に S3 データセットへのシームレスなアクセス提供し、コールドデータセットのコスト効率性を向上させます。 本記事では、Amazon FSx ファイルシステムと Amazon S3 バケットが同一 AWS リージョン内の異なる AWS アカウントに存在する際の、Amazon FSx for Lustre ファイルシステムを Amazon S3 データレイクとシームレスに統合するプロセスを紹介します。このソリューションでは、中央のエンタープライズデータレイクから専門チームのアカウントにデータを共有し、ML や HPC のユースケースでそのデータを利活用することにより、 AWS 環境をスケールさせることができます。 ソリューションの概要 次のソリューションのアーキテクチャ図は、2 つのアクセス許可の問題への対処を表しています。1 つ目は、初期ロードのために別のアカウントの Amazon S3 バケットから読み取ることを Amazon FSx for Lustre に許可します。2 つ目は、データの同期を維持するために継続的な変更をレプリケートするためにファイルシステムがバケットに対する put の通知を受信することを許可します。 前提条件 本ソリューションをデプロイするには、次のものが必要です。 2 つの AWS アカウント。利用可能なアカウントを 2 つ持っていない場合は、 AWS アカウント作成の流れ より作成できます。 ソリューションの実装 本セクションでは、 Data Repository Association (DRA) を使用して、 ACCOUNT-A の Amazon FSx for Lustre ファイルシステムを ACCOUNT-B の Amazon S3 バケットと統合する方法について説明します。 ステップ 1: Amazon FSx ファイルシステムを作成する ステップ 2: ソースバケットを作成する ステップ 3: データリポジトリの関連付けを作成する ステップ 4: バケットポリシーを設定する ステップ 1: Amazon FSx ファイルシステムを作成する ACCOUNT-A で、US East (バージニア北部) リージョンにいることを確認し、Amazon FSx コンソールに移動してください。 1. ファイルシステムを作成 をクリックします。 次の画面で、さまざまなタイプの Amazon FSx ファイルシステムが表示されます。 Amazon FSx for Lustre を選択し、 次へ をクリックします。 2. 次の画像に示すように、 ファイルシステム名 、 ストレージキャパシティ を入力し、 データ圧縮タイプ を LZ4 に設定します。 3. ネットワークとセキュリティ のセクションで、新しいファイルシステムの Virtual Private Cloud (VPC) 、 VPC セキュリティグループ 、 サブネット を選択します。 選択したセキュリティグループは、同じ VPC 内の Amazon EC2 インスタンスが Amazon FSx ファイルシステムをマウントできるように、Amazon FSx for Lustre トラフィック(TCP ポート 988、1018-1023)へのインバウンドアクセスを許可する必要があります。詳細については、 FSx for Lustre ユーザーガイド の Amazon VPC を使用したファイルシステムアクセスコントロール のドキュメントを参照してください。 Amazon FSx は、Amazon S3 バケットにリンクされたファイルシステムのバックアップをサポートしていないので、新しいファイルシステムのバックアップを無効にする必要があります。 4. バックアップとメンテナンス セクションで, 無効 を選択し、 次へ をクリックします。 5. オプションが正確であることを確認し、 ファイルシステムを作成 をクリックしてください。初期化には数分かかります。ファイルシステムが利用可能になると、ステータスが 利用可能 と表示されます。 ステップ 2: ソース S3 バケットの作成 ACCOUNT-B に Amazon S3 バケットを作成します。バケットの作成の詳細な手順は、 Amazon S3 ユーザーガイド の バケットの作成 をご覧ください。 今回の例では、US East (バージニア北部)リージョンを選択し、バケットの名前を「new-lustre-file-system」とします。次のセクションでデータリポジトリの関連付けを作成した後、バケットポリシーを更新します。 ステップ 3: データリポジトリの関連付けの作成 次にデータリポジトリの関連付け (DRA) を作成して、Amazon FSx for Lustre ファイルシステムを Amazon S3 バケットにリンクします。 1. ACCOUNT-A で、Amazon FSx コンソールに移動し、作成したファイルシステムを選択します。 データリポジトリ のタブを選択して、 データリポジトリの関連付けを作成 を選択します。 2. ファイルシステムのパス と Amazon S3 バケットへのパスを入力します。今回の例ではバケット全体を使用しましたが、DRA を特定のプレフィックスに限定することもできます。 3. 作成 をクリックします。ステータスが 利用可能 になるまでに初期化に数分かかります。 4. DRA 作成時に、Amazon S3 アクセスのための Amazon FSx のサービスリンクロールが作成されました。 AWS Identity and Access Management (AWS IAM) コンソールに移動し、新しいファイルシステムのために作成されたサービスロールを検索してください。 5. Amazon FSx for Lustre のサービスリンクロールの Amazon Resource Name (ARN) を見つけて、手元に保存しておきます。次のセクションのバケットポリシーの設定で必要になります。 ステップ 4: S3 バケットポリシーの設定 先程のセクションの ARN を使用して、Amazon S3 バケットにバケットポリシーを適用します。 1. ACCOUNT-B で、Amazon S3 コンソールに移動し、作成したバケットを選択します。 アクセス許可 タブをクリックし、 バケットポリシー セクションで 編集 を選択します。現在のポリシーを下記のポリシーに置き換えます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Example permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT-A:role/aws-service-role/…/AWSServiceRoleForFSxS3Access_fs-XXXXXXX" }, "Action": [ "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:Get*", "s3:List*", "s3:PutBucketNotification" ], "Resource": [ "arn:aws:s3:::new-lustre-file-system", "arn:aws:s3:::new-lustre-file-system/*" ] } ] } 2. ステップ 3 で保存したサービスリンクロールの ARN を使用して、AWS プリンシパルの値を置き換えます。 3. 「new-lustre-file-system」を作成したバケット名に置き換えます。 変更の保存 を選択します。 Amazon FSx が S3 バケットにデータを書き込む際に暗号化する場合、S3 バケットのデフォルト暗号化を SSE-S3 または SSE-KMS に設定する必要があります。詳細は、 サーバー側で暗号化された Simple Storage Service (Amazon S3) バケットの使用 のドキュメントを参照してください。 ソリューションのテスト ここまでの作業で、別の AWS アカウントの Amazon S3 バケットと同期している Amazon FSx for Lustre ファイルシステムを作成しました。 ステップ 1. Amazon EC2 インスタンスの作成 同期のテストのために、ファイルシステムをマウントできる Amazon EC2 インスタンスが必要です。 ACCOUNT-A で、Amazon EC2 コンソールに移動します。Amazon FSx ファイルシステムと同じ VPC 内に Amazon Linux 2 AMI を使用してインスタンスを起動します。 インスタンスの起動方法については、 インスタンスの起動 のドキュメントを参照してください。 ステップ 2. ファイルシステムのマウント ドキュメントに記載されているいずれかの方法を使用して Linux インスタンスへの接続 を実施します。 ターミナルウィンドウから、Amazon FSx ファイルシステムをマウントします。Amazon FSx コンソールからファイルシステムのマウント方法を確認できます。ファイルシステムを選択し、 アタッチ を選択します。 ステップ 3. テストファイルの作成 ファイルシステムのマウントに成功したら、マウントされたディレクトリ /fsx/ns1/ にテストファイルを作成します。このファイルの名前は「 file1.txt 」とします。 ACCOUNT-B に切り替えて、作成した Amazon S3 バケットを確認してください。「 file1.txt 」を確認できます。 次に、別のファイルを直接 Amazon S3 バケットにアップロードしましょう。このファイルの名前を「 file2.txt 」とします。 EC2 ターミナルに戻り、 ls -l と入力してください。/fsx/ns1/ に「 file2.txt 」が表示されることが確認できます。 削除と更新でテストプロセスを繰り返すことができます。 クリーンアップ テストしたソリューションですが、不要な料金が発生しないようにするために、プロビジョニングしたリソースを削除する次の 4 つのステップを実行してください。 ファイルシステムのマウントとテストに使用した Amazon EC2 インスタンスを終了してください。 ACCOUNT-A で作成した Amazon FSx for Lustre ファイルシステムを削除してください。 ACCOUNT-B で作成したサンプルデータと Amazon S3 バケットを削除してください。 Amazon FSx for Lustre ファイルシステムへ Amazon S3 アクセスを提供するために作成した IAM サービスリンクロールを削除してください。 結論 Amazon FSx for Lustre の S3 とのネイティブ統合は、スケールアウト型 Lustre ファイルシステムの高パフォーマンスと Amazon S3 上に構築されたデータレイクのメリットを活用できる、実績のある簡単にデプロイできるソリューションを提供します。本記事では、異なる AWS アカウントの Amazon S3 バケット内のソースデータへの変更と同期を取る Amazon FSx ファイルシステムをデプロイする方法を紹介しました。このソリューションにより、企業は中央のエンタープライズデータレイクから ML や HPC のユースケースでそのデータを利活用する専門チームのアカウントにデータを共有することで、AWS 環境をスケールできます。 Justin Leto Justin Leto は、機械学習を専門とするアマゾンウェブサービスのシニアソリューションアーキテクトです。彼の情熱は、お客様が機械学習とAIの力を活用してビジネスの成長を促進できるよう支援することです。Justin はグローバルカンファレンスで発表したり、大学で講義を持っています。彼はニューヨーク市の機械学習とAIのミートアップをリードしています。休日には、オフショアセーリングやジャズ演奏を楽しんでいます。彼は妻と娘と一緒にニューヨーク市に住んでいます。 Emad Tawfik Emad Tawfik は、アマゾンウェブサービスの10 年以上の経験をもつ経験豊富なシニアソリューションアーキテクトです。彼の専門はストレージとクラウドソリューションの領域にあり、お客様向けの費用対効果が高くスケーラブルなアーキテクチャの構築が得意です。Emadは、仕事だけではなく、家族と時間を過ごすこととアウトドアを楽しんでいます。 Juha Sarimaa Juha Sarimaa は AWS のシニアソリューションアーキテクトストレージスペシャリストです。エンタープライズ規模のストレージシステムで28年の経験があります。お客様がビジネス課題を解決するためのペタバイト規模のストレージアーキテクチャを設計および構築できるよう支援することを楽しんでいます。Juha はフィンランド出身で、オーストラリアに住み、現在はコネチカット州に住んでいます。業務外では、Juha は外で家族や友人と森の中や水辺で時間を過ごしています。

大規模言語モデル (LLM) を中心に構成された生成 AI (人工知能) アプリケーションは、ビジネスに経済的価値を生み出し、さらに加速する可能性を示してきました。アプリケーションの例には、 会話型検索 、 カスタマーサポートエージェントアシスト 、 カスタマーサポート分析 、 セルフサービス仮想アシスタント 、 チャットボット 、 リッチメディア生成 、 コンテンツモデレーション 、 セキュアで高パフォーマンスなソフトウェア開発を加速するコーディングコンパニオン 、 マルチモーダルコンテンツソースからのより深いインサイト 、 組織のセキュリティ調査と緩和策の加速 などがあります。 多くのお客様が、生成 AI アプリケーションを開発する際に、セキュリティ、プライバシー、コンプライアンスの管理手法についてのガイダンスを求めています。 設計およびアーキテクティングのフェーズで LLM の脆弱性、脅威、リスクを理解し対処することで、チームは経済性および生産性のメリットを最大化することに集中できます。 リスクを認識することは、生成 AI アプリケーションの透明性と信頼性を高め、可観測性を向上させ、コンプライアンス要件を満たすのに役立ち、十分な情報に基づくリーダーの意思決定を促進します。 この記事の目的は、AI と機械学習 (ML) のエンジニア、データサイエンティスト、ソリューションアーキテクト、セキュリティチーム、その他のステークホルダーが、共通のメンタルモデルとフレームワークを持ち、セキュリティのベストプラクティスを適用できるようにすることです。これにより、AI/ML チームは、セキュリティを犠牲にすることなく、スピードを上げることができます。 具体的には、これまでセキュリティの原則について触れたことのない AI/ML およびデータサイエンティストが、LLM を使用した生成 AI アプリケーションの開発に関連する中核となるセキュリティとプライバシーのベストプラクティスを理解するのに役立つことを目的としています。 また、 Open Worldwide Application Security Project (OWASP) Top 10 for LLM Applications によって特定された、AI への信頼を損なう可能性のある一般的なセキュリティ上の懸念についても説明します。そして、生成 AI でイノベーションを起こしながら、AWSを使用してセキュリティ態勢と信頼性を高める方法を示します。 この記事では、LLM を使用して生成 AI アプリケーションを開発する際に、リスク管理戦略を構築するための 3 つの手順を紹介します。 まず、LLM ソリューションの実装、デプロイ、使用から生じる脆弱性、脅威、リスクについて掘り下げ、セキュリティを念頭に置いたイノベーションの始め方についてのガイダンスを提供します。 次に、安全な基盤の上に構築することが、生成 AI にとって不可欠である理由について説明します。 最後に、これらを LLM ワークロードの例と結び付けて、信頼境界を越えた多層防御のセキュリティを構築するためのアプローチを説明します。 この記事により、AI/ML エンジニア、データサイエンティスト、セキュリティ指向の技術者は、生成 AI アプリケーションのための多層防御を設計する戦略を特定し、OWASP Top 10 for LLM のセキュリティ上の懸念への対応策を理解できます。そして、お客様のアプリケーションに関する、次のようなよくある質問に答えるための基礎的な知識を構築できるようになります。 LLM ベースの生成 AI をアプリケーションで使用する際の、一般的なセキュリティとプライバシーのリスクのうち、この記事に示すガイダンスにより最も影響があるものは何ですか ? AWS 上の生成 AI アプリケーションの開発ライフサイクルにセキュリティとプライバシー制御を実装するにはどのような方法がありますか ? LLM を使用した生成 AI アプリケーションのリスクを管理し信頼性を高めるために、組織が生成 AI アプリケーションを構築する方法において、どのような運用面および技術面でのベストプラクティスを組み込むことができますか ? 生成 AI の開発をしながらセキュリティレベルを高める LLM を使用した生成 AI でイノベーションを起こすためには、セキュリティを念頭に置き、組織のレジリエンスを高め、安全な基盤の上に構築し、多層防御のセキュリティアプローチと統合する必要があります。 セキュリティは、AWS と AWS のお客様の間で 共有される責任 です。 AWS 責任共有モデルのすべての原則が、生成 AI ソリューションに適用されます。LLM ソリューションを構築する際に、インフラストラクチャ、サービス、データ適用される AWS 責任共有モデルを新たに理解しましょう。 セキュリティを念頭において組織のレジリエンスを構築する セキュリティを念頭に置き、セキュリティとコンプライアンスの目標を満たす生成 AI アプリケーション開発のための組織のレジリエンスを構築します。 組織のレジリエンスは、 AWS Well-Architected フレームワークのレジリエンシーの定義 を取り入れ拡張したもので、組織が混乱から回復する能力が含まれています。 LLM を使用した生成 AI を開発するための全体的な準備状況と、潜在的な影響に対する組織のレジリエンスを評価する際は、セキュリティ態勢、ガバナンス、およびオペレーショナルエクセレンスの優位性を考慮してください。 組織が生成 AI や LLM などの新興テクノロジーの利用を進めるにつれ、資産や事業部門を意図しない結果から保護するための多層防御の基礎として、組織全体のレジリエンスを考慮する必要があります。 組織のレジリエンスは LLM アプリケーションにとって極めて重要です すべてのリスク管理プログラムではレジリエンスから恩恵を受けることができますが、組織のレジリエンスは生成 AI にとって非常に重要です。LLM アプリケーションの上位 10 のリスクのうち OWASP が特定した 5 つは、リスクを管理するためにアーキテクチャおよび運用上のコントロールを定義し、組織規模でそれらを適用することに依存しています。これら 5 つのリスクは、安全が確認されていない出力ハンドリング、サプライチェーンの脆弱性、機密情報の漏えい、過剰な代理行為、過度の信頼です。アイデアの発案から研究、アプリケーションの開発、デプロイ、使用に至る製品のライフサイクル全体で、AI、ML、生成 AI のセキュリティを中心的なビジネス要件であり最優先事項であるとチームに認識させることで、組織のレジリエンスを高めることから始めてください。意識の向上に加えて、チームはガバナンス、保証、コンプライアンス検証の実践の中で生成 AI を考慮するための行動を取る必要があります。 生成 AI を中心に組織のレジリエンスを構築する 組織は、組織内での AI/ML および生成 AI セキュリティのための能力と機能を構築する方法を採用し始めることができます。 まずは既存のセキュリティ、保証、コンプライアンス、開発プログラムを拡張して、生成 AI を考慮することから始める必要があります。 組織の AI、ML、および生成 AI のセキュリティにおける 5 つの主要な関心領域は以下の通りです。 AI/ML のセキュリティの状況を理解する セキュリティ戦略に多様な視点を取り入れる 研究開発活動のセキュリティ対策に積極的に取り組む インセンティブを組織の成果と整合させる AI/ML と生成 AI における現実的なセキュリティシナリオに備える 生成 AI のライフサイクル全体を通じて脅威モデルを開発する 生成 AI を構築する組織は、リスクの排除ではなく、リスク管理に重点を置き、生成 AI ワークロードの計画、開発、運用において 脅威モデリング と 事業継続計画 を含める必要があります。生成 AI の本番利用から逆算して、従来のセキュリティリスクと生成 AI 特有のリスクの両方を用いて、各アプリケーションの脅威モデルを開発することから始めてください。あるリスクはビジネスにとって許容できる可能性があり、脅威モデリングの実施により許容できるリスク範囲を特定するのに役立ちます。例えば、生成 AI アプリケーションに 99.999% の稼働時間を要求しない場合、 AWS Backup と Amazon S3 Glacier を使用したリカバリに関連する追加のリカバリ時間は、許容できるリスクとなる可能性があります。反対に、モデル内のデータが極めて機密性が高く、規制対象である場合、 AWS Key Management Service (AWS KMS) の カスタマーマネージドキー (CMK) のローテーションからの逸脱や、データ漏えいから保護するために AWS Network Firewall を使用したり入出力トラフィックに Transport Layer Security (TLS) を適用することは、許容できないリスクとなる可能性があります。 生成 AI アプリケーションを本番環境で使用する際の固有リスクと残存リスクを評価し、基盤およびアプリケーションレベルの適切なコントロールを特定します。OWASP Top 10 for LLM で挙げられている、プロンプトインジェクション、訓練データの汚染、モデルの DoS 、モデルの盗難などの本番環境でのセキュリティイベントやサービス中断のロールバックと復旧を計画し、アプリケーション要件を定義する際に使用するリスク軽減策を早期に定義します。リスクとコントロールについて学ぶことは、生成 AI アプリケーション構築のための最適な実装アプローチを定義するのに役立ち、ステークホルダーや意思決定者がリスクに関する情報に基づいたビジネス上の意思決定を行うための情報を提供します。AI および ML の全体的なワークフローに不慣れな場合は、まず 機械学習ワークロードのセキュリティを改善する 7 つの方法 を確認して、従来の AI/ML システムに必要なセキュリティコントロールの理解を深めてください。 他の ML アプリケーションを構築するのと同様に、生成 AI アプリケーションを構築するには、一連の研究開発ライフサイクルの段階を経る必要があります。 選択した生成 AI ソリューションに応じて考慮すべき主要なセキュリティ領域を理解するためのメンタルモデルを構築するのに役立つ AWS 生成 AI セキュリティスコーピングマトリックス を確認することをおすすめします。 LLM を使用した生成 AI アプリケーションは、通常、次の順序立ったステップに従って開発および運用されます。 アプリケーションの要件 – ユースケースのビジネス目的、要件、成功基準を特定する モデルの選択 – ユースケースの要件と整合する基盤モデルを選択する モデルの適応とファインチューニング – データの準備、プロンプトの作成、モデルのファインチューニングを行う モデルの評価 – ユースケース固有のメトリクスで基盤モデルを評価し、最もパフォーマンスの高いモデルを選択する デプロイとインテグレーション – 選択した基盤モデルを最適化されたインフラストラクチャにデプロイし、生成 AI アプリケーションと統合する アプリケーションのモニタリング – アプリケーションとモデルのパフォーマンスをモニタリングして、根本原因の分析を可能にする ソフトウェア開発ライフサイクルの初日から、設計およびアーキテクチャフェーズの一部として、セキュリティが極めて重要であるとチームが理解していることを確認してください。これは、ソフトウェアの構成要素や開発サイクルの各レイヤーでセキュリティについて議論し、セキュリティとプライバシーをビジネス目標を達成するための手段として位置付けることを意味します。LLM アプリケーションのリリース前に脅威に対するコントロールを設計し、モデルの適応とファインチューニングに使用するデータと情報が、研究・開発・トレーニング環境でのコントロールの実装を必要とするかどうかを検討してください。品質保証テストの一環として、定期的に防御とセキュリティ態勢をテストするために、統合されたセキュリティ脅威 (訓練データを汚染したり、悪意のあるプロンプトエンジニアリングを通じた機密データを抽出することを試行するなど) を導入してください。 加えて、ステークホルダーは、本番の AI、ML、生成 AI ワークロードについて一貫したレビューの頻度を設定し、人間と機械の制御およびエラーのトレードオフを理解することを組織の優先事項として設定する必要があります。 デプロイされた LLM アプリケーションにおいて、これらのトレードオフが尊重されていることを検証および保証することで、リスク軽減が成功する可能性が高まります。 セキュアなクラウド基盤上で生成 AI アプリケーションを構築する AWS において、セキュリティは最優先事項です。 AWS は、アプリケーションとワークロードを構築、移行、管理するための、最もセキュアなグローバルクラウドインフラストラクチャとして設計されています。 これは、300 を超えるクラウドセキュリティツールの豊富なセットと、政府機関、ヘルスケア、金融サービスなどのセキュリティ要件の高い組織を含む、数百万のお客様からの信頼に支えられています。 AWS 上で LLM を使用して生成 AI アプリケーションを構築する場合、 セキュアで信頼性が高く、柔軟な AWS クラウドコンピューティング環境 からセキュリティ上のメリットを得ることができます。 セキュリティ、プライバシー、コンプライアンスのためにAWS グローバルインフラストラクチャを活用する AWS でデータ集約型アプリケーションを開発する際、AWS のグローバルリージョンインフラストラクチャを活用できます。このインフラストラクチャは、セキュリティとコンプライアンスに関する中核となる要件を満たす機能を提供するよう設計されています。これは、クラウドで利用できる最も高度な統制管理と機能のセットを提供するという、 AWS のデジタル統制に関するお客様との約束 によって強化されています。AWS は、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、お客様の デジタル主権 に関するニーズを満たすための機能を拡張することにコミットしています。セキュリティとプライバシーのベストプラクティスを簡単に実装するために、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) や AWS プライバシーリファレンスアーキテクチャ (AWS PRA) などのリファレンスデザインやインフラストラクチャコードリソースをご利用ください。 プライバシーソリューションの設計 、 設計による主権 、 AWS でのコンプライアンス の詳細をご確認ください。また、 AWS Config 、 AWS Artifact 、 AWS Audit Manager などのサービスを利用して、プライバシー、コンプライアンス、監査、可観測性のニーズをサポートします。 AWS Well-Architected フレームワークとクラウド導入フレームワークを使用したセキュリティ態勢を理解する AWS は、 AWS Well-Architected フレームワーク を使用してクラウド環境を設計したり、 AWS Cloud Adoption Framework (AWS CAF) を使用してクラウドテクノロジーからビジネス価値を実現したりと、お客様をサポートする長年の経験から得られたベストプラクティスのガイダンスを提供しています。 AI、ML、生成 AI ワークロードのセキュリティ態勢を理解するために、Well-Architected フレームワークのレビューを実施してください。 レビューは、 AWS Well-Architected Tool などのツールを使用して実施できます。または、 AWS エンタープライズサポート を通じて AWS チームの支援を受けることもできます。 AWS Well-Architected Tool は、 AWS Trusted Advisor からのインサイトを自動的に統合して、ベストプラクティスがどの程度実装されているか、機能とコスト最適化を改善するためにどのような機会があるか評価します。 また、AWS Well-Architected Tool には、 Machine Learning Lens などの特定のベストプラクティスを備えたカスタマイズされたレンズも用意されているため、アーキテクチャを定期的にベストプラクティスと比較して改善点を特定できます。 AWS のお客様が 人工知能、機械学習、生成 AI の AWS クラウド導入フレームワーク により組織的な能力を開発するための戦略をどのように採用しているかを理解してすることで、価値の実現とクラウドの成熟への道のりを歩むチェックポイントを設定します。 また、 AWS クラウドレディネスアセスメント に参加することで、全体的なクラウド準備状況を理解するメリットもあるかもしれません。 AWS では追加のエンゲージメントの機会も提供しています – Generative AI Innovation Center の利用を開始する方法についての詳細は、AWS アカウントチームにお問い合わせください。 セキュリティと AI/ML の学習をベストプラクティスのガイダンス、トレーニング、認定で加速させる AWS は、トレーニング、開発、テスト、運用環境を保護する方法を特定するのに役立つ、 セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス や AWS セキュリティドキュメント からの推奨事項をまとめています。 初めての方は、セキュリティトレーニングと認定資格についてさらに詳しく学習し、 AWS セキュリティの基礎 と AWS セキュリティラーニングプラン から始めることをおすすめします。 また、 AWS セキュリティ成熟度モデル を利用して、Quick Wins から基礎、効率化、最適化の各段階で、AWS 上の最適なアクティビティを見つけて優先順位付けすることもできます。 AWS 上のセキュリティの基本的な理解ができたら、 脅威モデリングのアプローチ方法 を確認し、チームと Threat Modeling For Builders ワークショップ トレーニングプログラムから始める脅威モデリング演習を主導することを強くおすすめします。 その他にも、利用可能な AWS セキュリティトレーニングと認定資格 が多数あります。 LLM アプリケーションを保護するための多層防御アプローチを適用する 生成 AI ワークロード、データ、情報に対して多層防御のセキュリティアプローチを適用することで、ビジネス目標の達成に最適な条件を整えるのに役立ちます。多層防御のセキュリティベストプラクティスは、あらゆるワークロードが直面する一般的なリスクの多くを軽減し、あなたのチームが生成 AI イノベーションを加速するのに役立ちます。 多層防御のセキュリティ戦略は、AWS アカウント、ワークロード、データ、資産を保護するために、複数の冗長な防御を使用します。 これにより、セキュリティコントロールの 1 つが侵害されたり失敗した場合でも、脅威を分離し、セキュリティイベントから防御、検知、対応、回復するのに役立つ追加のレイヤーが存在することを確認するのに役立ちます。 AWS サービスとソリューションを含む複数の戦略を組み合わせて、各レイヤーで使用することで、生成 AI ワークロードのセキュリティとレジリエンスを向上させることができます。 多くの AWS のお客様は、 NIST のサイバーセキュリティフレームワーク などの業界標準のフレームワークに準拠しています。このフレームワークは、識別、防御、検知、対応、復旧、最近追加されたガバナンスの柱にわたってセキュリティ防御を確実に保護するのに役立ちます。このフレームワークは、AWS のセキュリティサービスや統合されたサードパーティのサービスに簡単にマッピングできるため、組織が遭遇するあらゆるセキュリティイベントに対して、適切な対応範囲とポリシーを検証するのに役立ちます。 （訳者注：CloudEndure Disaster Recovery は一部リージョンを除いて廃止が予定されているため、代わりに AWS Elastic Disaster Recovery の利用をご検討ください） 多層防御 : 環境をセキュアにし、強化された AI/ML 固有のセキュリティとプライバシーの機能を追加する 多層防御の戦略は、最初にアカウントと組織を保護することから始め、その後 Amazon Bedrock や Amazon SageMaker などのサービスに組み込まれたセキュリティとプライバシーの機能を、階層的に追加していく必要があります。 Amazonは 30 を超えるセキュリティ、アイデンティティ、コンプライアンスのポートフォリオを持ち 、それらは AWS の AI/ML サービスと統合されており、ワークロード、アカウント、組織を保護するのに役立ちます。OWASP Top 10 for LLM の観点で適切に防御するには、これらのセキュリティサービスを AWS の AI/ML サービスと合わせて使用していく必要があります。 まず、最小権限のポリシーを実装し、 IAM Access Analyzer などのサービスを使用して、アクセス許可が広範囲に設定されたアカウント、ロール、リソースを見つけ、 一時的な認証情報を使用してアクセスを制限 します。次に、 AWS KMS を使用して、CMK の利用も考慮しつつ、保管中のすべてのデータが暗号化されていることを確認します。また、 Amazon S3 のバージョニングとオブジェクトレベルの不変性を適用するための Amazon S3 オブジェクトロック を使用して、すべてのデータとモデルをバージョン管理しバックアップします。サービス間を転送するすべてのデータは、 AWS Certificate Manager や AWS Private CA を使用して保護し、 AWS PrivateLink を使用して VPC 内にとどめておきます。 改ざんやデータ漏洩からの保護のために、 AWS Network Firewall ポリシーを使用した VPC を利用して、データの厳格な入出力ルールを定義します。 悪意のあるボット 、 SQL インジェクション攻撃、クロスサイトスクリプティング (XSS) から Web アプリケーションと API を保護 するために、 AWS WAF を前面に配置し、アカウントの乗っ取り防止のため Fraud Control を使用することも検討します。ログの記録に AWS CloudTrail 、 Amazon VPC フローログ、 Amazon EKS 監査ログを使用することにより、フォレンジックの際に Amazon Detective などのサービスで各トランザクションをレビューすることができます。 Amazon Inspector を使用して、 Amazon EC2 インスタンス、コンテナ、 AWS Lambda 関数の脆弱性の自動で発見し管理することができたり、 ワークロードのネットワーク到達可能性を特定 することもできます。データとモデルを疑わしいアクティビティから保護するために、 Amazon GuardDuty の ML を利用した脅威モデルと脅威インテリジェンスフィードを使用します。さらに EKS Protection、ECS Protection、S3 Protection、RDS Protection、Malware Protection、Lambda Protection など、追加の機能を有効にします。 AWS Security Hub のようなサービスを使用することで、セキュリティチェックを集中化および自動化し、セキュリティのベストプラクティスからの逸脱の検出や、調査の迅速化、プレイブックを使用した修復の自動化が可能となります。 さらに、 ゼロトラスト アーキテクチャを AWS 上で実装し、人間のユーザーまたはマシン間プロセスがリクエストごとにアクセスできるものに対し、きめ細かい認証認可の制御を強化することもできます。 また、 Amazon Security Lake を使用して、AWS 環境、SaaS プロバイダー、オンプレミス、クラウドソースからのセキュリティデータを自動的に集約し、アカウント内に構築された専用のデータレイクに保存することも検討します。Security Lake を使用することで、組織全体のセキュリティデータをより包括的に理解できます。 生成 AI ワークロード環境をセキュリティで保護した後は、 Amazon SageMaker Data Wrangler を使用してデータ準備における潜在的なバイアスを特定したり、 Amazon SageMaker Clarify を使用して ML データとモデルのバイアスを検出するなど、AI/ML 固有の機能を追加できます。 また、 Amazon SageMaker Model Monitor を使用して、本番環境の SageMaker ML モデルの品質を評価し、データ品質、モデル品質、Feature Attribution のドリフトが発生した場合に通知を受けることもできます。 これら AWS の AI/ML サービス (Amazon Bedrock と連携する Amazon SageMaker を含む) と AWS のセキュリティサービス が連携することで、バイアスの潜在的なソースを特定し、悪意のあるデータ改ざんから保護するのに役立ちます。 AWS サービスの価値を最大限に活用して、データとワークロードを保護するための多層防御を実装するために、OWASP Top 10 for LLM の各脆弱性についてこのプロセスを繰り返してください。 AWS Enterprise Strategist の Clarke Rodgers 氏がブログ記事「 CISO Insight: Every AWS Service Is A Security Service 」で次のように述べています。「AWS クラウド内のほぼすべてのサービスはセキュリティが単体で確保されており、お客様がセキュリティ、リスク、コンプライアンスの目的を達成するために、単体または 1 つ以上のサービスと組み合わせて使用できます」。 加えて、「お客様の最高情報セキュリティ責任者 (CISO)、またはそれらの関連チームは、すべての AWS サービスに精通しているかどうか確認する時間を取ることが望ましいです。なぜなら、サービスが『セキュリティ、アイデンティティ、コンプライアンス』のカテゴリに含まれていなくても、セキュリティ、リスク、コンプライアンスの目的を満たすことができるためです。」と述べています。 LLM アプリケーションの信頼境界における各レイヤーの防御 生成 AI ベースのシステムやアプリケーションを開発する際には、 MITRE ATLAS Machine Learning Threat Matrix で述べられているように、ソフトウェアおよびデータコンポーネントの出所 (オープンソースソフトウェア監査の実行、ソフトウェア部品表 (SBOM) のレビュー、データワークフローと API インテグレーションの分析など) に注意を払うことや、LLM サプライチェーンの脅威に対する必要な保護を実装することなど、他の ML アプリケーションと同様の懸念事項を考慮する必要があります。 業界のフレームワークからの洞察を取り入れ、脅威インテリジェンスやリスク情報といった複数のソースを使用し、従来のフレームワークには含まれていない AI、ML、および生成 AI の新たなセキュリティリスクに対応できるよう、セキュリティ対策を調整および拡張する方法を認識してください。この分野では定期的に新しい脅威が出現し、かつ進化しているため、フレームワークやガイドも頻繁に更新されています。 そのため、AI 固有のリスクに関する情報を、業界、国防、政府、国際機関、学術機関などのソースから探してください。たとえば、検索拡張生成 (RAG) モデルを使用する場合、モデルに必要なデータが含まれていないと、推論とファインチューニングの際に外部データソースへ要求する可能性があります。このようなクエリを実行するソースは管理外にある可能性があり、サプライチェーンでの潜在的な侵害源となり得ます。外部ソースに対しても多層防御アプローチを拡張し、アクセスしているデータの信頼性、認証、認可、アクセス、セキュリティ、プライバシー、正確性を確立する必要があります。 より深く掘り下げるには、「 Build a secure enterprise application with Generative AI and RAG using Amazon SageMaker JumpStart 」を確認してください。 LLM アプリケーションにおけるリスクを分析し軽減する このセクションでは、信頼境界とインタラクション、または同様の適切なコントロールの範囲とリスクプロファイルを持つワークロードの個別の領域に基づいて、いくつかのリスク軽減手法を分析して説明します。 以下のチャットボットアプリケーションのサンプルアーキテクチャでは、AWS のお客様が一般的な LLM アプリケーションを構築する方法に基づいて、コントロールが実証される 5 つの管理されている信頼境界があります。 実際の LLM アプリケーションには、より少ない、またはより多くの定義可能な信頼境界がありえます。 次のサンプルアーキテクチャでは、これらの信頼境界は次のように定義されています: ユーザーインターフェースのインタラクション (リクエストとレスポンス) アプリケーションのインタラクション モデルのインタラクション データのインタラクション 組織のインタラクションと利用 ユーザーインターフェースのインタラクション : リクエストとレスポンスのモニタリングの開発 生成 AI アプリケーションの入力と出力に関するリスク戦略を評価することにより、生成 AI に関連するサイバーインシデントをタイムリーに検知および対応します。 例えば、LLM アプリケーションの場合、ドメインまたは組織の外部への機密情報の漏洩を検知するために、挙動とデータ流出のための追加のモニタリングが必要となる場合があります。 生成 AI アプリケーションは、データを保護する際にも標準的なセキュリティのベストプラクティスを維持する必要があります。 セキュアなデータ境界 を確立し、 センシティブなデータストアを保護 します。 LLM アプリケーションで使用されるデータと情報は、保管時および転送時に暗号化します。 モデルの訓練データは、どのユーザー、プロセス、ロールがデータストアにアクセスできるかを理解し制御することにより、訓練データの汚染（Training Data Poisoning）から保護します。 また、アプリケーション内のデータフロー、バイアスの監視、Amazon S3などのストレージサービスでのバージョニングとイミュータブルストレージを使用することも重要です。 AWS Network Firewall や AWS VPC などのサービスを使用して、厳格なデータの入出力制御を確立し、疑わしい入力やデータ漏洩の可能性から保護します。 学習、再学習、ファインチューニングのプロセス中は、利用される個人情報に注意を払う必要があります。 これらのプロセスのいずれかでデータが利用された後、プロンプトインジェクション技術を用いて、ユーザーがデータや情報をモデルから抽出できるシナリオを想定する必要があります。 モデルと推論に個人情報を利用することのリスクと効果を理解します。 細かいアクセス許可を設定し管理するために、LLM アプリケーションロジックに依存しないロバストな認証認可メカニズムを実装します。 生成 AI アプリケーションへのユーザーが管理する入力は、一部の条件下において、モデルやユーザー管理外の入力から情報を抽出するベクトルを提供できることが実証されています。 これはプロンプトインジェクションを通じて発生する可能性があります。 LLM アプリケーションが想定するガードレールから逸脱した出力をするような入力がなされ、その出力の中には、モデル学習に使われたオリジナルのデータセットに関する情報も含まれることになります。 モデルへの入力やモデルからの出力を受け取るユーザーに対して、ユーザーレベルのアクセス制御を実装します。 トレーニングデータや情報の機密性が高い場合や、攻撃者によって入力とモデル出力に基づいてモデルを模倣されるリスクがある場合は、匿名アクセスを許可しないアプローチを検討する必要があります。 一般に、モデルへの入力の一部が任意のユーザー提供のテキストで構成されている場合、出力がプロンプトインジェクションに対して脆弱であると見なされます。そのため、安全が確認されていない出力ハンドリング（Insecure Output Handling）、過剰な代理行為（Excessive Agency）、過度の信頼（Overreliance）といったリスクに対して技術的および組織的な対策が実行されているか確認する必要があります。前述の AWS WAF を使用した悪意のある入力のフィルタリングの例では、プロンプトの誤用の可能性に対してアプリケーションの前にフィルターを構築し、モデルとデータが成長するにつれてそれらをどのように処理および進化させるかのポリシーを開発することを検討します。 また、品質、精度、コンテンツモデレーションの基準を満たしていることを確認するために、ユーザーに返される前に出力をフィルタリングするレビューを行うことも検討してください。 組織のニーズに合わせて、モデルの前に入力と出力の追加の制御レイヤーを追加することで、疑わしいトラフィックパターンを軽減できます。 アプリケーションのインタラクション : アプリケーションのセキュリティと可観測性 LLM アプリケーションをレビューする際は、ユーザーがモデルを利用して、本来はアクセスや使用の許可がない下流のツールやツールチェーンへの標準認可を回避しないか注意してください。このレイヤーでのもう 1 つの懸念は、緩和されていない技術的または組織的な LLM リスクを使用した攻撃メカニズムとしてモデルを利用して、外部データストアにアクセスすることです。 例えば、機密データを含む可能性のある特定のデータストアにアクセスするようモデルがトレーニングされている場合は、モデルとデータストアの間で適切に認可の確認がなされることを確認する必要があります。 認可チェックを実行する際には、モデルからではなく、ユーザーに関する不変の属性を使用します。 安全が確認されていない出力ハンドリング（Insecure Output Handling）、安全が確認されていないプラグイン設計（Insecure Plugin Design）、過剰な代理行為（Excessive Agency）などの対策が講じられていない場合は、攻撃者が認可システムを騙すためにモデルを使用し、実行権限をエスカレーションさせる状況を作り出す可能性があります。これにより下流コンポーネントが、ユーザーがデータの取得や特定のアクションの実行を認可されていると信じてしまうことにつながります。 生成 AI プラグインやツールを実装する際には、付与されるアクセスレベルを検証し、理解することが不可欠です。また、設定されたアクセス制御を精査することも重要です。対策の講じられておらず安全でない生成 AI プラグインを使用すると、サプライチェーンの脆弱性や脅威にシステムがさらされる可能性があり、リモートコードの実行などの悪意のあるアクションにつながる可能性があります。 モデルのインタラクション : モデル攻撃の防止 使用するモデル、プラグイン、ツール、データの出所を認識しておく必要があります。これにより、サプライチェーンの脆弱性を評価および軽減することができます。例えば、一部の一般的なモデルフォーマットでは、モデル自体に任意の実行可能コードを埋め込むことが許可されています。組織のセキュリティ目標に関連する場合は、パッケージをミラーしたり、スキャンや追加の検査を実行します。 モデルのトレーニングとファインチューニングを行うために使用するデータセットもレビューする必要があります。 ユーザーからのフィードバック (またはその他のエンドユーザーがコントロールできる情報) に基づいてモデルの自動ファインチューニングを行う場合は、悪意のある攻撃者がレスポンスを操作することでモデルを任意に変更し、訓練データの汚染（Training Data Poisoning）を引き起こす可能性があるかどうかを考慮する必要があります。 データのインタラクション : データ品質と利用状況のモニタリング 大規模言語モデル (LLM) のような生成 AI モデルは、一般的に大量のデータで訓練されているため、優れた性能を発揮します。このデータは LLM が複雑なタスクを遂行するのに役立ちますが、同時に訓練データの汚染 (Training Data Poisoning) のリスクにシステムをさらす可能性もあります。これは、不適切なデータが訓練データに含まれたり省かれたりすることで、モデルの振る舞いが変わることを指します。このリスクを軽減するには、モデルで使用する前に、システムのデータレビュープロセスとサプライチェーンを確認する必要があります。トレーニングパイプラインはデータ汚染攻撃の主な発生源ですが、他にも RAG モデルやデータレイクなど、モデルがデータを取得する方法も確認する必要があります。そのデータソースが信頼でき保護されているかどうかを確認します。 AWS Security Hub、Amazon GuardDuty、Amazon Inspector などの AWS セキュリティサービスを使用して、Amazon EC2、Amazon EKS、Amazon S3、 Amazon Relational Database Service (Amazon RDS)、ネットワークアクセスなどでの疑わしいアクティビティを継続的に監視し、新たな脅威の兆候を検知します。また Detective を使用してセキュリティ調査を視覚化することもできます。さらに、 Amazon Security Lake などのサービスを使用して、AI/ML ワークロードに貢献する AWS 環境、SaaS プロバイダー、オンプレミス、およびクラウドソースから、セキュリティデータを自動的に集約する専用データレイクを作成することで、セキュリティ調査を加速することも検討します。 組織のインタラクション : 生成 AI のためのエンタープライズガバナンスガードレールの実装 ビジネスにおける生成 AI の利用に関連するリスクを特定します。生成 AI ソリューションを展開する際には、組織のリスクを分類し、リスク評価を実施し、情報に基づく意思決定が必要です。AI/ML、生成 AI ワークロードを含めた 事業継続計画(BCP) を策定し、影響を受けたりオフラインになった LLM アプリケーションの機能を迅速に置き換えて、SLA を満たすことができるようにします。 プロセスとリソースのギャップ、非効率性、不整合性を特定し、ビジネス全体の認知とオーナーシップを向上させます。 すべての生成 AI ワークロードを 脅威モデリング し、データの不正アクセス、サービスの拒否、リソースの誤用など、ビジネスに影響を与える可能性のあるセキュリティ上の脅威を特定し軽減します。 脅威モデリングを実施する際には、新しい AWS Threat Composer モデリングツール が価値創出までの時間短縮に役立ちます。 開発サイクルの後半では、 セキュリティカオスエンジニアリング のフォールトインジェクションの試みを導入して、システムが未知の問題にどのように反応するかを理解し、システムの回復力とセキュリティに対する信頼性を高めるための実環境での条件を作成することを検討します。 すべての職種と機能にわたって AI/ML や生成 AI に関するセキュリティの遵守とカバレッジを確保するため、セキュリティ戦略とリスク管理メカニズムの開発に多様な視点を取り入れます。 生成 AI アプリケーションの初期やリサーチの段階から要件と整合させるためにセキュリティの考え方を取り入れます。 AWSからの追加のサポートが必要な場合は、AWS のアカウントマネージャーに相談し、AWS セキュリティと AI/ML のソリューションアーキテクトのサポートをリクエストし、協力して取り組みます。 セキュリティ組織は、プロダクトマネージャー、ソフトウェア開発者、データサイエンティスト、経営陣などの生成 AI のステークホルダー間で、リスクの認識とリスク管理の理解を促進するコミュニケーションを定期的に行うようにします。これにより、脅威インテリジェンスとコントロールのガイダンスが、影響を受ける可能性のあるチームに届くようになります。セキュリティ組織は、ディスカッションに参加し、ビジネス目標に関連する新しいアイデアや情報を生成 AI のステークホルダーに提供することで、責任ある情報開示と反復的な改善の文化を支援できます。より詳細については、 責任ある AI に関する私たちの取り組み や、お客様を支援する 責任ある AI のリソース をご確認ください。 組織の既存のセキュリティプロセスにおける時間対効果に対する障害を取り除くことにより、生成 AI のためのよりよい組織態勢に向けた優位性が得られます。 組織が生成 AI のセキュリティの状況下で過度に負担を強いられるプロセスがあるかを積極的に評価し、これらを改善して、適切なコントロールをもとにローンチする計画を開発者やデータサイエンティストに提供します。 インセンティブの調整や、リスクの低減、目標とする結果への明確な見通しを提供する機会があるかどうかを評価します。 AI/ML と生成 AI アプリケーション開発の進化するニーズを満たすように、コントロールのガイダンスと防御を更新することで、開発時間のコスト増加、リスクの増加、影響範囲の増加を招くような混乱と不確実性を軽減します。 セキュリティの専門家ではないステークホルダーが、組織のガバナンス、ポリシー、リスク管理のステップが自分のワークロードにどのように適用されるかを理解できるようにするとともに、リスク管理メカニズムを適用できるようにしてください。 組織が生成 AI アプリケーションで発生しうる現実的なイベントとシナリオに対応できるよう準備し、生成 AI ビルダーの役割と対応チームが、疑わしい活動について懸念がある場合のエスカレーションパスとアクションを認識していることを確認します。 結論 先進技術を活用して市場でのイノベーションを成功させるには、セキュリティを最優先に考え、セキュアなインフラストラクチャーの基盤上に構築していくことが必要です。また、多層防御のセキュリティアプローチをもとに、テクノロジースタックの各レイヤーでセキュリティをさらに統合できる方法を考えることが必要です。これには、組織のレジリエンシーを確保するための、テクノロジースタックの複数のレイヤー間のインタラクションと、デジタルサプライチェーン内の統合ポイント間のインタラクションが含まれます。 生成 AI はいくつかの新しいセキュリティとプライバシーの課題をもたらしますが、レイヤー化されたセキュリティサービスを使用した多層防御などの基本的なセキュリティのベストプラクティスに従えば、多くの共通的な問題や進化する脅威から組織を保護するのに役立ちます。 生成 AI ワークロード全体と組織全体にわたって、レイヤー化されたAWSセキュリティサービスを実装し、デジタルサプライチェーンの統合ポイントに焦点を当てて、クラウド環境を保護する必要があります。そして、Amazon SageMaker や Amazon Bedrock などの AWS AI/ML サービスで強化されたセキュリティとプライバシー機能を利用して、生成 AI アプリケーションにさらなるセキュリティとプライバシーコントロールのレイヤーを追加できます。 セキュリティを最初から組み込むことで、コンプライアンスを簡素化しながら、生成 AI でのイノベーションをより迅速かつ容易、そしてコスト効率よく実現できます。 これにより、従業員、顧客、パートナー、規制機関、その他の利害関係者のために、生成 AI アプリケーションのコントロール、信頼性、可観測性を高めることができます。 追加の参考資料 AI/ML 固有のリスク管理とセキュリティの業界標準フレームワーク: NIST AI Risk Management Framework (AI RMF) OWASP Top 10 for Large Language Model LLM Applications MITRE ATLAS Machine Learning Threat Matrix OWASP AI Security & Privacy Guide 著者について Christopher Rae は、AWS のセキュリティサービスの採用を加速および拡大する戦略的イニシアチブを開発および実行することに焦点を当てたプリンシパルワールドワイドセキュリティ GTM スペシャリストです。サイバーセキュリティと新興テクノロジーの交差点に情熱を注ぎ、20 年以上にわたってメディア、エンターテインメント、テレコムのお客様にセキュリティソリューションを提供するグローバルな戦略的リーダーシップの経験を持っています。読書、旅行、食べ物とワイン、新しい音楽の発見、初期段階のスタートアップへのアドバイスを通じてリフレッシュしています。 Elijah Winter は、サイバーセキュリティ工学の学士号を持ち、ハリー・ポッターへの愛に満ちたシニアセキュリティエンジニアです。 AI システムの脆弱性を特定し対処することに秀でており、技術的専門知識と魔法使いのような感覚を融合させています。 AI エコシステムのためのカスタマイズされたセキュリティプロトコルを設計し、デジタル防御に魔法のような魅力をもたらしています。 正直さを重んじる Elijah は、信頼を守ることに焦点を当てた公共および民間セクターの両方の組織でセキュリティのバックグラウンドを持っています。 Ram Vittal は、AWS のプリンシパル ML ソリューションアーキテクトです。 30 年以上にわたり、分散型、ハイブリッド、クラウドアプリケーションのアーキテクチャ設計と構築の経験があります。 セキュアでスケーラブルな AI/ML とビッグデータのソリューションを構築し、エンタープライズのお客様がクラウドへの移行と最適化の旅を支援し、ビジネス成果を向上させることに情熱を注いでいます。 余暇には、バイクに乗ったり、3 歳のシーパドゥードルと散歩したりしています! Navneet Tuteja  は、Amazon Web Services のデータスペシャリストです。AWS に加入する前は、データアーキテクチャの近代化と包括的な AI/ML ソリューションの実装を目指す組織のファシリテータとして働いていました。Thapar University で工学の学位を取得し、Texas A&M University で統計学の修士号を取得しています。 Emily Soward は、AWS プロフェッショナルサービスのデータサイエンティストです。スコットランドのエディンバラ大学で人工知能の理学修士号を取得しており、自然言語処理 (NLP) に重点を置いています。Emily は、公共および民間セクターの組織で実行されている AI ワークロードの運用効率とガバナンスに焦点を当てた、AI を活用した製品の研究開発に従事してきました。AWS シニアスピーカーとして顧客へのガイダンスに貢献するとともに、最近では機械学習レンズの AWS Well-Architected の著者としても活動しています。 翻訳はプロフェッショナルサービスの藤浦雄大、相川遼介が担当しました。原文は こちら です。 「AWS Security and Risk Management Forum ～レジリエントな未来：生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント～」 のご案内 2024 年 3 月 19 日に東京にて表題のイベントが開催されます。本イベントでは、生成 AI の活用やクラウドの活用の最新動向および生成 AI の押さえるべきポイント、AWS 内の取り組みについて米国セキュリティ部門のディレクターが直接解説します。また、有識者や外部ゲストを迎え、クラウドにおけるセキュリティ、リスクマネジメントに焦点を当てた各種対策を具体的に解説します。ご希望の方は、 こちら からご登録をお願いいたします。

re:Invent は、革新的なテクノロジーを深く理解し、新しいアイデアを探求する機会です。現在様々な業界においてサステナビリティ（持続可能性）が大きな課題となっています。AWS クラウドによって実現するサステナビリティには、「クラウドの」、「クラウド内」、「クラウドを通じて」の 3 つの要素があります。 クラウドのサステナビリティ (Sustainability of the cloud) : クラウドへのマイグレーション（移行）による IT システムのサステナビリティを向上する クラウド内のサステナビリティ (Sustainability in the cloud) : Well-Architected Framework のサステナビリティの柱や様々なサービスを利用した AWS のワークロードの最適化 クラウドを通じたサステナビリティ (Sustainability through the cloud) : クラウドベースのソリューションとアドバイザリーサポートの導入により、サステナビリティ目標を加速させる このブログでは、re:Invent 2023 での発表内容を中心に、サステナビリティのそれぞれの要素について、AWS の取り組みや事例をご紹介していきます。 クラウドのサステナビリティ Sustainability innovation in AWS Global Infrastructure (SUS101) では、AWS グローバルインフラストラクチャのサステナビリティに関する紹介を行いました。 調査会社 451 Research によると、AWS のような大規模なクラウドインフラストラクチャはオンプレミスのエンタープライズデータセンターを利用するよりもエネルギー効率がよく、一般的な平均的なオンプレミスデータセンターと比較して、 米国 で 3.6 倍、 ヨーロッパ や アジア太平洋地域 では約 5 倍エネルギー効率が高いことがわかりました。平均して、AWS ではお客様の二酸化炭素排出量を現在約 80% 近く削減でき、今後 100% 再生可能エネルギーで事業を運営するようになった場合は、最大 96% 二酸化炭素排出量を削減できます。 クラウドインフラストラクチャーでは、最新のサーバーをより高い稼働率で使用し、複数のお客様間でリソースを共有して動的に割り当てるとともに、施設レベルでは、冷却と配電の両方でエネルギー効率を高める設計により、データセンターのエネルギー効率を向上させています。 AWS は、グローバルな事業とサプライチェーン全体で二酸化炭素排出量を削減することにより、二酸化炭素排出量のネットゼロに向けて取り組んでいます。主な取り組みとして以下のようなものがあります: AWS Graviton プロセッサや、AI/ML に特化した AWS Trainium や AWS Inferentia など、独自設計のハードウェアによるエネルギー効率化 データセンター建設において、製造時に発生する二酸化炭素量を削減した低炭素コンクリートや低炭素鋼を使用 データセンターのバックアップ発電機で再生可能燃料の利用 サプライヤーと協力し半導体デバイスのライフサイクル全体で排出量を削減 Amazon は世界最大の再生可能エネルギー購入企業であり、AWS でもすでに 19 の AWS リージョンで 100% 再生可能エネルギーを利用 ハードウェアのライフサイクルにおけるサーキュラーエコノミー（循環型経済）の採用 水利用効率の向上と社会への水の還元 クラウド内のサステナビリティ Sustainable architecture: Past, present, and future (SUS302) では、「サステナブルなアーキテクチャー：過去、現在、未来」という講演が行われ、クラウド内のサステナビリティを向上させるための考え方や具体的なサービスについての紹介が行われました。 クラウドの登場により自由に計算リソースを増減して変化するワークロードに対応することが可能になり、またコストやサステナビリティの観点でアプリケーションをチューニングしてリソースを最適化する考え方が生まれました。 AWS の責任共有モデル の考え方では、AWS はクラウドインフラストラクチャのサステナビリティ（持続可能性）に責任を持つ一方で、お客様は、 クラウド内のサステナビリティに責任を持ち、ワークロードとリソース利用率を最適化する必要があります。 図1）AWS 責任共有モデル クラウド内のサステナビリティを最適化するためのガイドとして、2021 年の AWS re:Invent で Well-Architected Framework に 6 本目の柱、持続可能性（サステナビリティ） が追加されました。この中では、リージョン選択、需要に合わせた調整、ソフトウェアアーキテクチャ、ストレージの最適化やデータのライフサイクル管理、ハードウェアとサービスの選択、プロセスと文化、といった重点領域を定義し、それぞれの領域におけるベストプラクティスを紹介しています。 クラウド内のサステナビリティを改善するには、まず現状を把握する必要があります。AWS の請求コンソールから確認できる AWS カスタマーカーボンフットプリントツールでは AWS ワークロードから発生する二酸化炭素排出量を表示することができます。さらにプロキシメトリクスと呼ばれる手法を使うことにより、AWS リソースの利用量をプロキシ、つまり代替的な指標とすることで、よりリアルタイムに近い形で、自分のワークロードの排出量を把握することができます。 またこの講演では、 Cloud Intelligent Dashboard というオープンソースのダッシュボードも紹介しています。これは AWS リソースの使用状況を詳細に分析することができるツールで、 デプロイメントガイド や デモ が公開されています。 組織内に AWS アカウントが複数あって AWS リソースを大量に利用している場合、その全体像の把握は難しいものですが、このようなダッシュボードにより、AWS リソースの利用状況について正確に把握することができます。 図2） Cloud Intelligence Dashboard またその他にも、AWS ワークロードのサステナビリティを高めるために利用可能な、様々なツールが紹介されています。 クラウドを通じたサステナビリティ AWS クラウドを通じてサステナビリティ目標を実現するというテーマに関しては、複数の講演がありました。 AI を利用した ESG レポーティングとデータ主導の意思決定 (SUS204) Using AI for ESG reporting and data-driven decision-making (SUS204) では、 AI を利用した ESG レポーティングとデータ主導の意思決定 に関する発表が行われました。 ESG レポーティングというのは、いわゆる非財務情報に関する開示であり、日本でも ESG 情報開示が求められることが多くなってきていますが、海外でも規制による ESG 情報開示の義務化が進んでおり、同時に不正確な報告による訴訟リスクが増加しています。また、サプライチェーンの安全性、レジリエンス、透明性などの評価が重要になっています。 一方で、ESG レポーティングに関して様々な課題があり、データが社内の様々なシステムでバラバラに管理されサイロ化していること、手作業の集計による非効率性や誤りのリスクが指摘されています。また、年 1 回程度の特定の時点でのみの集計では実行可能なアクションに結びつけた改善を行うのには不十分です。 このような問題に対して、AI/ML を活用することで課題の解決が可能になります。例えばデータの収集を自動化したり、データのギャップを埋めて補完したり、コンプライアンス関係文書に対するクエリや要約を実行したり、生成 AI による ESG レポートの自動作成を行う、といったことです。このセッションでは、 (1) 生成 AI を利用したチャット bot によるサステナビリティ関係の様々なクエリの実施、(2) AI/ML を利用した排出係数の選択、(3) Amazon Textract による電力請求書からのデータ抽出、など、AWS の AI/ML を使用したデモを紹介しています。 AI/ML でエンド・ツー・エンドのサプライチェーン透明性を加速 (SUS203) Accelerating end-to-end supply chain transparency with AI/ML (SUS203) では、AI/ML によってサプライチェーンの透明性を加速させる技術に関する紹介がありました。 現在、様々な理由で製品のサプライチェーン透明性の向上が求められています。例えば特に消費財や衣服については、製品の安全性や真正性を確認するために製品のトレーサビリティを求める消費者の声が強く、またコンプライアンスや規制上の理由でサプライチェーン透明性が求められる場合もあります。また、二酸化炭素排出量の算定においては、Scope 3 と呼ばれる間接排出量では、製品の原材料や製造、輸送、最終的な利用から破棄に渡るライフサイクルを通じた排出量が対象となるため、サプライチェーンの透明性を高めることが非常に重要になってきます。 一方で、様々な製品のサプライチェーンは複雑化しており、特に、L2、L3 と呼ばれる、間接的な取引相手にまたがるサプライチェーン情報を取得するのは困難です。これはサプライヤーが情報提供に懸念を示すといったケースがあるだけでなく、データが様々な箇所に分散され、データフォーマットが統一されていないといった技術的な要因もあります。 AWS は PVH Europe というヨーロッパの大手のアパレル企業と協力して、サステナビリティのプラットフォームを開発し、サプライチェーン情報を分析・可視化するためのデータメッシュとダッシュボードを開発しました。この事例では “ Prouct Traceability on AWS ” という AWS ソリューションガイダンスにより、企業の購買履歴や NGO の発行した証明書などの情報を統合し、AI/ML によって足りない情報を推定することにより、サプライチェーン情報を分析・可視化するためのデータメッシュとダッシュボードを開発しています。 図3）サプライチェーン情報を可視化したダッシュボード例 AI, ML, オープンソースデータにより森林破壊を減速 Slowing down deforestation by using AI, ML, and open source data (SUS205) では、AI、ML、オープンデータを利用した森林破壊を減速させる取り組みを紹介しています。 森林は大量の二酸化炭素を吸収し固定化し、生物多様性や人間の営みを守るなど、気候変動やサプライチェーン安定性に大きな影響を持っています。 一方で、森林破壊が大きな問題となっています。例えば、ブラジルのアマゾン地域では 90% の森林破壊は違法に行われており、違法な農地で生産された農産物が問題となっています。 サンパウロの Minas Gerais 大学は、ブラジルの Para 州の自治体と協力して、 SeloVerde 2.1 というソリューションを開発しました。これは、トレーサビリティを向上し、違法な土地利用に基づく農産物を市場から排除することによって、森林破壊を減速させることを目的としています。 SeloVerde 2.1 は、 Amazon Sustainability Data Initiative (ASDI) や PlanetScope で公開されている衛星画像を利用し、他の公共データと統合し、AI/ML 技術によって分析することで、5m 四方の高解像度で土地の利用状況をトラッキングし、土地利用の変更を検知します。また、様々なデータソースを統合して分析することで、牛や大豆などの農産物のサプライチェーンを追跡し、透明性を高めています。 まとめ 以上、re:Invent 2023 のサステナビリティに関する発表をご紹介しました。本日ご紹介した内容を含む解説動画については、 Recap イベントのアーカイブ をご覧ください。 また、YouTube のプレイリスト re:Invent Sustainability Content 2023 には、本日ご紹介した講演を含め、サステナビリティ関係の講演がまとまっています。 AWS グローバルインフラストラクチャのサステナビリティ Sustainability innovation in AWS Global Infrastructure (SUS101) サステナブルなアーキテクチャー：過去、現在、未来 Sustainable architecture: Past, present, and future (SUS302) AWS でデータ主導のサーキュラーエコノミーを加速 Accelerate data-driven circular economy initiatives with AWS (SUS202) AI/ML でエンド・ツー・エンドのサプライチェーン透明性を加速 Accelerating end-to-end supply chain transparency with AI/ML (SUS203) AI を利用した ESG レポーティングとデータ主導の意思決定 Using AI for ESG reporting and data-driven decision-making (SUS204) AI, ML, オープンソースデータにより森林破壊を減速 Slowing down deforestation by using AI, ML, and open source data (SUS205) オープンデータによる次世代サステナビリティワークロードの構築 Building next-generation sustainability workloads with open data (SUS304) その他のサステナビリティ事例やお問い合わせ先については、 AWS のサステナビリティ のサイトをご覧ください。

はじめに 本ブログ記事は、 AWS Entity Resolution を利用することにより、ヘルスケア分野における記録のリンクと照合の課題にどのように取り組むことができるかを示し、継続的なエンティティ解決のワークフローにて患者の 360 度ビューを実現する方法の概要を説明します。また、 AWS HealthLake が、ヘルスケアのお客様のデータを安全に保存、変換、管理する上で、どのように役立つかも説明します。本ブログ記事を最後まで読めば、ヘルスケア業界におけるエンティティ解決のための準備が整うはずです。 医療機関は、それぞれが独自の形式とモダリティを持つ大量のデータと多様なデータソースを管理する必要がますます高まっています。ヘルスケアシステム全体において、データ入力と保存方法が異なるため、異なる患者や医療従事者の入力、研究対象、研究レポート、診断レポートと検査、請求と請求書情報など、エンティティの不整合が発生する可能性があります。誤った請求が誤った支払いにつながる可能性がある医療において、エンティティの全体像を把握することは、患者の顧客体験向上のために重要です。 たとえば、情報の統合が不十分で患者の記録に不整合がある場合、実際には受けていないサービスの請求を誤って患者にしてしまったり、実際に受けたサービスの請求がされていなかったり、といった請求ミスにつながる可能性があります。このようなミスは、患者の混乱や不満を引き起こし、負担を増やし、ヘルスケアシステム全体に悪影響を及ぼします。正確で徹底したデータ管理は、効果的な患者ケアが行えるだけでなく、正しい請求や明確なコミュニケーションが重要な医療において、良好な顧客体験実現のために重要です。 ヘルスケア分野において、様々なデータソース間で正確な患者記録の照合を行うために、記録のリンクと照合は重要です。エンティティ解決の実装は、患者照合の改善などのメリットを医療機関にもたらします。データの一貫性が向上し、請求プロセスが合理化されることにより、請求ミスが減少し、システム間の相互運用性が強化され、プライバシー規制への準拠が容易になります。患者データの正確性を維持することで、エンティティ解決は最終的に、ヘルスケアの保険者と医療従事者が、患者ケアの向上、運用コストの最適化、規制遵守の強化を、統一的なアプローチで実現できるようになります。 ヘルスデータの記録精度の課題 ヘルスケアとライフサイエンス (HCLS) の組織が、関連性のある異なる記録のリンクおよび照合を困難にしている、いくつかの課題は以下の通りです。 データの断片化: ヘルスケアには、患者、医療従事者、研究対象と研究レポート、診断レポートと検査、請求と請求書など、多数のエンティティが含まれます。これらのエンティティは、電子カルテ (EHR)、請求プラットフォーム、保険データベース、診断研究など、異なるシステムに分散された大量のデータを生成します。これらの多様なデータソースは、しばしば異なる識別方法や一貫性のないデータ入力を行なっているため、エンティティ記録の不一致や誤りが発生します。この断片化は、様々なエンティティの包括的かつ正確なプロファイルの作成を妨げます。 データ流動性: 現代のヘルスケアにおいて、患者は頻繁に異なる医療機関からケアを求めたり、新しい地域に移住したり、保険プランを変更したりします。これらの変化は、HCLS 組織がヘルスケアシステムとのやり取りにおいて、一貫性のある正確な患者記録を維持するうえでの課題となります。記録が古くなったり断片化したりすることで、患者ケアの質、データの一致、正確性に影響を与えます。 データ品質: データの不正確さは、様々な医療機関で広く共通の課題です。つづりの誤り、入力基準のバラつき、古い情報、不完全な記録などの問題があると、請求データの正確性に大きな影響を及ぼします。こうした不正確さは誤った請求や見落とされた請求などのエラーを引き起こし、患者の不満や医療機関の財務的な齟齬を招くことがあります。請求データの正確性を確保できるかどうかは、財務運営や患者満足度に直接影響するため、最も医療機関が直面する重要かつ困難な課題の 1 つです。 データの相互運用性: ヘルスケアシステムは多様な技術を使用することが多く、それぞれに独自の標準があるため、相互運用性を実現し、プライバシーを維持することは大きな課題です。これらの異なるシステムは、一意の識別子やコード化システムを使用する可能性があり、様々なヘルスケアプラットフォームや組織間において、情報を正確に相互参照するプロセスを複雑にしています。この複雑さは技術的な困難だけでなく、コンプライアンスとプライバシーの課題も発生させます。患者データのセキュリティを保ちつつ、異なるシステム間でアクセス可能かつ正確な状態を維持するためには、慎重にバランスをとる必要があります。医療機関は、米国 HIPAA のような厳格なデータ保護規制を順守する必要があり、これらは患者情報の保護を義務付けています。HIPAA 対応には、シームレスなデータ統合を保証する技術的ソリューションと、機密性を維持し法的基準を順守するための堅牢なプライバシーポリシーの両方が含まれます。 AWS Entity Resolution AWS Entity Resolution は、柔軟に設定できるワークフローを作成し、わずか数分でセットアップでき、企業が複数のアプリケーション、システム、データストアに存在する関連記録を容易に照合、リンク、強化できる HIPAA 適格サービスです。 柔軟なデータ準備: このサービスは、 Amazon Simple Storage Service (Amazon S3) に格納されたデータを AWS Glue テーブルとして読み込むなど、柔軟にカスタマイズ可能なデータプレパレーション (データ準備) を提供します。このサービスには、ソース間のデータをクレンジングおよび整合性の取れたものにできる、データ正規化機能が組み込まれています。ユーザーはデータ入力とスキーママッピングを指定できるので、照合ワークフローが特定の要件と整合性が取れていることを確認できます。 データ保護: AWS Entity Resolution は、すべてのデータ入力に対するハッシュ化や暗号化など、堅牢なデータ保護機能を提供します。これにより、ユーザーは照合プロセス中にデータが保護されたままであることを確認できます。 データの地域化: AWS Entity Resolution におけるデータの地域化サポートは、HLCS 組織にとって極めて重要です。たとえば、機密性の高い遺伝情報が、それが存在する同じ地域内で正確にリンクされ、照合されていることを確認できます。これによりデータの主権が守られ、地域の医療情報規制に準拠するとともに、データの整合性とプライバシーを保護しつつ、安全にグローバルな遺伝子共同研究を行うことが容易に可能となります。 高度で構成可能な照合技術: このサービスは、ルールベースの照合、機械学習 (ML) ベースの照合、データサービスプロバイダ主導の照合など、高度な照合技術を提供します。これにより、関連するヘルスケア情報、研究、検査、診断、プロシージャコード、施設データを正確にリンク、強化できます。この照合技術の柔軟性と選択肢により、医療機関は様々なデータシナリオに対応することが可能になります。 すぐに使えるルールベースの照合: この照合技術には、入力フィールドに基づく一致を見つけるために、 AWS Management Console や AWS Command Line Interface (AWS CLI) にて、すぐに使えるルールセットが含まれます。医療機関は、独自のニーズに合わせるためにこれらのルールを微調整し、入力フィールドに基づいて関連記録を見つけるプロセスを簡素化でき、照合精度がニーズを確実に満たすことが可能となります。 ML を活用した照合: 事前に学習された ML モデルを使用して、複数のデータ入力間で一致を見つけることが可能です。照合品質の信頼度スコアを提供し、それを使って患者記録を照合することができます。 データサービスプロバイダ主導の照合: このワークフローは、数回クリックするだけで、信頼できるデータサービスプロバイダのデータセットと ID に記録をリンク、強化するすることが可能です。 手動処理および自動処理: ユーザーは、新しいデータが時間とともに到着する際、エンティティを最新の状態に保つために、手動の一括処理または自動の増分処理を通じて、ルールベースの照合を開始することができます。 準リアルタイム検索: このサービスは、ルールベースの照合を準リアルタイムに行う検索機能を提供します。これにより、ユーザーは既存の一致IDを同期的に取得できるため、データ取得の効率が向上します。 ヘルスデータを用いたAWS Entity Resolutionの使用例 AWS Entity Resolution は、ヘルスケアおよびライフサイエンスのユーザが、次のような新しいユースケースを実現できるよう支援します。 患者記録の連携: AWS Entity Resolution を利用することで、医療機関は、診療予約、検査結果、保険請求などのイベントを一意の一致IDにリンクでき、患者とのやり取りを統一されたビューで確立できます。これにより、様々な医療機関、保険会社、調剤サービス間で患者データの追跡が容易になり、患者記録と医療業務の全体的な正確性が向上します。 正確かつ継続的な患者の治療過程: AWS Entity Resolution を使用することで、ヘルスケアの保険者と医療従事者は、患者のイベントと入力の360度継続マップを構築できます。目標は、異なるデータセットをリンクすることによって患者ケアを強化することです。たとえば、大学病院ネットワークのメンバー機関からデータが提供される場合、このサービスにより容易に照合技術を利用できます。その結果、大学病院ネットワークは、各患者の統合された包括的な記録を作成できます。この改善された保存記録により、より正確な診断、健康管理、患者ケアの調整を行うことができます。最終的には、全体的な患者の治療過程を改善します。 最適化された臨床開発と研究記録: 新しい医薬品やアウトカムベースの研究は、正確にリンクされたデータ記録が必要です。科学者はこれらのデータを利用して研究を設計し、分析を実行、洞察を引き出します。これにより、最終的には臨床研究のアプローチを改善したり、臨床試験の被験者募集のためのコホート全体に共通する傾向を特定したりすることが可能となります。AWS Entity Resolution は、異なるデータソースを正確にリンクするのに役立つ、様々な照合技術を提供します。これにより、研究データの統一的な照会が促進され、データの不一致や冗長性を最小限に抑えながら、研究結果の信頼性を高めるのに役立ちます。たとえば、研究者や臨床医は、患者の反応をより効果的に追跡、分析、予測できるため、個別化医療の開発や治療戦略の最適化に貢献できます。 リンクされた医薬品コード: 製薬研究所、バイオテクノロジー企業、臨床研究機関、およびそれぞれのサプライチェーンは、複数の異なる分類、識別子、コードを利用して、医薬品と有効成分を一意に識別します。これらは、地域、国、標準化組織 (ATC、NDC、SNOMED、DIN) によって異なります。AWS Entity Resolution を使用することで、組織は識別子を含むデータセットをマップしてリンク、一意なエンティティに変換することができ、分析と研究を実行、サプライチェーンを最適化することができます。 相互運用性に関する義務 米国のヘルスケアセクターは変革期を迎えており、EHR ベンダー、医療機関、医療保険制度を含む様々な関係者間で、Fast Healthcare Interoperability Resources (FHIR) データ形式を採用するルールが形成されています。メディケアおよびメディケイドサービスセンター (CMS) の相互運用と患者アクセスに関する最終規則や、今後の法律規制の枠組みは、より広範で包括的なヘルスデータ相互運用の標準化推進を後押ししています。 これは医療保険者だけでなく、各々の専門的な規制ガイドラインに対応している医療制度と EHR ベンダーにも影響が及びます。これらの規制は、氏名、電話番号、住所など、患者照合に不可欠な重要データ要素へのアクセス支援をますます推奨しています。この新たな状況は、FHIR の採用が技術的な移行だけでなく、多面的なヘルスケアエコシステム全体での合理化された、安全な標準化データへのアクセス性を確保するための包括的な移行であることも示しています。 AWS HealthLake AWS HealthLake などのサービスを使用することにより、ヘルスケアシステムが必要な相互運用性要件を満たすのに役立ちます。HealthLake の FHIR ベース API を使用することで、医療機関は、臨床記録や患者の記録などの大量のヘルスデータを、オンプレミスのシステムからセキュアかつコンプライアンスに準拠した、従量課金制のクラウドサービスに簡単にインポートできます。HealthLake を活用することで、医療システムは医療上の要求を満たすだけでなく、組み込まれた自然言語処理 (NLP) モデルを使用して、顧客が必要とする医療情報を理解して抽出します。そして、安全かつ効率的な方法でイノベーションを推進し、患者ケアを改善させることができます。 ヘルスデータの容易な取り込み: ヘルスケアシステムは、臨床ノート、検査報告書、保険請求、その他のヘルスデータを S3 バケットに効率的にインポートできます。一括インポート機能により、後続のアプリケーションとワークフローのデータ取得が簡素化されます。 FHIR REST API 操作: AWS HealthLake は FHIR REST API オペレーションをサポートしており、ヘルスケアシステムはデータストア上で CRUD オペレーションを実行できます。これには FHIR 検索を実行し、効率的なデータ取得を可能にする機能が含まれます。 安全な HIPAA 適格ストレージ: AWS HealthLake は、データが安全な HIPAA 適格手法にて AWS クラウドに保存されることを保証しています。FHIR R4 標準形式でデータの問い合わせ、および構造化できるよう、FHIR 形式に準拠しています。 非構造化データの変換: AWS HealthLake には、 Amazon Comprehend Medical を使用した統合医療自然言語処理 (NLP) 機能を備えています。これにより、生の医療テキストデータが構造化情報に変換され、医療テキストからエンティティ、エンティティ関係、エンティティ特性が抽出されます。次に、このデータは新しいリソースタイプに整理され、データへのアクセス性が向上します。 用例: FHIR 患者エンティティの解決 このセクションでは、AWS HealthLake に保存されている患者記録のエンティティ解決を実行するための AWS Entity Resolution を活用したソリューションを紹介します。AWS HealthLake 内のエンティティ解決の実装は、データストア全体にわたりデータ整合性を確保する上で重要な基盤として機能します。この文脈における「エンティティ」は、単一の患者、医療従事者、組織、医療施設を指します。エンティティ解決は、患者や医療従事者などの同じ実世界のオブジェクトに関連する AWS HealthLake 内の複数の記録を判断する重要なプロセスです。たとえば、ヘルスケアのお客様からは、複数の内部システムや複数の組織に由来するデータソース間で患者を照合することには課題があると聞いています。 このプロジェクトでは、AWS Entity Resolution を使用し、ML ベースの照合アルゴリズムを採用、異なる患者記録を正確に識別およびリンクし、信頼度スコアを備えた包括的な患者プロファイルを確立できる AWS HealthLake の機能を強化することにより、この課題に対処しています。これにより、正確かつ一貫性のあるヘルスケアデータ管理が可能になります。このプロセスは、 マスターデータ管理 (MDM) 、 エンタープライズマスター患者インデックス (EMPI) として知られる、より広範かつ必要なステップの 1 つです。 アーキテクチャ 次の図は、この患者エンティティ解決ソリューションのアーキテクチャを示しています。このソリューションは AWS ネイティブサービスを活用、 AWS Well-Architected フレームワークに準拠し、セキュリティ、信頼性、パフォーマンス効率、コスト最適化などの主要な側面にわたり堅牢なアーキテクチャを確保しています。 図1: アーキテクチャ図 このソリューションには、次のハイレベルなステップとAWS ネイティブサービスが含まれています: Amazon Athena の SQL クエリを使用して、AWS HealthLake データストアから患者識別情報を取得します。 Amazon Athena クエリは、HealthLake データストアが最初に起動されるときに自動的に作成される AWS Lake Formation リソースリンクデータベースに対して実行されます。 クエリの結果セットは、CSV ファイルとして S3 バケットに保存されます。クエリに使用される患者の FHIR リソースの識別子属性には、HealthLake 患者リソース ID、名前、住所、電話番号、生年月日、性別などの属性が含まれる可能性があります。 AWS Entity Resolution に患者データセットを指定します。 前のステップで患者データセットが作成されたら、 AWS Glue クローラー を使用してデータセットをクロールし、 AWS Glue Data Catalog テーブルを生成します。これにより、このテーブルを AWS Entity Resolution サービスへ取り込む準備が整います。 AWS Entity Resolution を使用して ML 主導の照合を生成します。 このソリューションでは、AWS Entity Resolution のスキーママッピングと照合ワークフローが作成され、入力患者データを照合する方法と照合結果を書き込む場所が定義されます。デフォルトでは、このソリューションは入力された患者データセット全体で一致を見つけるために、事前に構成された 機械学習ベースの照合 技術を使用します。 AWS Lambda 関数が照合ワークフローのジョブをトリガーし、AWS Entity Resolution により生成された一致 ID と信頼度スコアを含む結果を別の S3 バケットに書き込みます。照合ワークフローで、独自の照合ルールを定義し、エンティティ解決の要件を満たす完全一致を見つけるために、 ルールベースの照合 技術を使用することもできます。 AWS Entity Resolution の 一致ID を AWS HealthLake の患者 FHIR リソースに挿入します。 AWS Entity Resolution が一致する患者記録を特定すると、ソリューションは Lambda 関数を使用してAWS Entity Resolution の結果を読み取り、解析します。その後、信頼度スコアと関連付けられた AWS Entity Resolution で生成された一致IDを、患者の FHIR リソースの新しい識別子属性に挿入します。これにより、AWS HealthLake データストア全体の一致する患者記録を簡単に識別してリンクできるようになります。 前提条件 このソリューションをデプロイする前に、 AWS CloudFormation テンプレートの入力パラメータとして使用する次の情報が必要です。 患者エンティティ解決を実行する AWS HealthLake データストアのデータストアID 次の図に示すように、AWS HealthLake データストアにリンクされている AWS Lake Formation データベースのデータベース名と共有リソース所有者ID ( またはカタログ ID) 図2: Lake Formation データベース名と共有リソース所有者 ID を特定するスクリーンショット 導入 このソリューションを実装するには、この AWS CloudFormation テンプレート をデプロイします。 このテンプレートの出力には、 ahl-entity-resolution-state-machine という名前の AWS Step Functions が含まれます。このステートマシンをオンデマンドで実行することで、ソリューションを実行し、AWS HealthLake データストアの患者エンティティ解決を実行できます。このテンプレートは、毎夜 10 時のように、ステートマシンを定期的に自動トリガーする AWS EventBridge スケジューラー も作成します。このスケジューラーのスケジュールをビジネスニーズにあわせて変更することで、ソリューションの実行頻度を調整できます。 結果の検証 このソリューションによって識別された一致した患者記録を確認するには、次のいずれかを実行します: Step Function にリンクされた AWS CloudWatch ロググループ に移動してください。このロググループには、各ステップの入力と出力を含む、Step Function の実行に関する詳細な情報が含まれています。 Step Function の実行ページに移動し、ステートマシンの最後のステップの出力を確認してください。ステートマシンの最後のステップは、一致した患者リソース ID ( source_id ) と AWS Entity Resolution が返した match_id を含む一致結果を生成します。 図3: ステップ関数の実行出力のスクリーンショット AWS Entity Resolution の照合出力から患者リソース ID を特定したら、以前に特定した患者リソース ID を使用して AWS HealthLake データストアで患者リソースをクエリできます。match_id が識別子属性値として示されている AWS Entity Resolution から、患者に新しい識別子属性が作成されたことがわかります。 次の図に示すように、AWS Entity Resolution から返される一致 ID は、照合ワークフローの設定や患者記録が大幅に更新されない限り、複数のワークフロー実行にわたり、ソース患者記録に対して同じままです。これらの一致 IDは、HealthLake データストア内の内部患者記録を相互にリンク付けするためのものであり、HealthLake 外の後続システムまたは外部システムで識別子として使用しないでください。 図4: エンティティ解決の一致 ID を示す HealthLake クエリのスクリーンショット また、次の図に示すように、サンプルの Amazon QuickSight ダッシュボードを構築し、HealthLake データストアにある複数の患者記録が、このソリューションによって HealthLake に挿入された新しい識別子属性に基づき、AWS Entity Resolution によって返された同一の match_id に合致していることを確認しました。 図5: 同じAWS Entity Resolution 一致 ID によって照合された複数の患者記録を示す QuickSight ダッシュボードのサンプル このソリューションは、HealthLake における患者エンティティ解決のベースラインを提供します。これは柔軟で拡張性のあるフレームワークで、これをベースに独自のアプリケーションやワークロードを構築できます。このソリューションを拡張または変更して、固有のヘルスケアエンティティ解決の要件を満たすことができます。 クリーンアップ 本ブログ記事の例に関連する不要なインフラストラクチャコストを避けるために、CloudFormation スタックと、前提条件として追加した他のすべての手動リソースを必ず削除してください。 次のステップ この変革の旅に乗り出すには、 AWS Entity Resolution と AWS HealthLake に関するドキュメント、ウェビナー、ビデオ、その他のブログ記事などのリソースを探索してください。AWS HealthLake は、高度な小児科医療など、他のヘルスケア分析ニーズにも対応できます。その実現方法を説明したブログ記事「 Amazon HealthLake を使用したスケーラブルな FHIR ベースのデータ分析による小児科医療の進歩 」や「 AWS Entity Resolution: 複数のアプリケーションとデータストアからの関連記録を照合してリンクする 」を参照してください。実践的アプローチについては、 AWS Entity Resolution 、 AWS HealthLake 、 AWS HealthLake Patient Matching のワークショップを確認してください。 まとめ: AWS Entity Resolution および AWS HealthLake AWS Entity Resolution と AWS HealthLake は、シームレスに統合することで、ヘルスケアデータ内のエンティティの管理、構造化、正確な解決を包括的に実現するソリューションを医療機関に提供できます。この統合により、データの正確性が向上し、患者ケアの連携が改善され、規制へのコンプライアンスが確保され、ヘルスケア企業が研究、イノベーション、高品質な患者ケアの提供に効果的にデータを活用できるよう後押しします。 翻訳はソリューションアーキテクトの松浦が担当しました。原文は こちら です。 Tyler Replogle Tyler Replogle は、AWS で世界中の公共部門を担当するシニアソリューションアーキテクト兼テクニカルデータベースリーダーです。顧客やパートナーがエンドミッションソリューションを AWS で実行できるように支援しています。彼は建築が好きで、レゴ、マインクラフト、コーディングを使った建築を通じて、3 人の娘たちとつながる方法を見つけました。 Kai Xu Kai Xu – Kai は AWS のシニアソリューションアーキテクトで、学術医療センターのお客様をサポートしています。Kai はヘルスケア業界で 15 年以上の経験があり、情報セキュリティ、コンプライアンス、クラウド移行に情熱を注いでいます。自由時間には、読書、サッカーゲーム、そして子供たちとの楽しい時間を楽しんでいます。