こんにちは。 AWS パブリックセクター技術統括本部の押川です。 本ブログは、「詳細解説」シリーズの一つとして、標準準拠システムの AWS 上でのデータ連携について解説いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 庁内データ連携機能とは 2つの連携方式とデータ連携の要件 認証認可について AWS 上での実現方法 認証認可サーバーが必要な場合 認証認可サーバーが必要でない場合 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ まとめ ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 庁内データ連携機能とは 標準準拠システムが、他の標準準拠システムにデータを送信又は他の標準準拠システムからデータを受信すること、庁内データ連携機能と言います。例えば、住民記録システムから介護保険システムに対して、住民基本情報を連携する場合などが該当します。 2つの連携方式とデータ連携の要件 連携方式としては、「RESTによる公開用API連携」（以降、「API連携」という。）と「ファイル連携」の２つの方式を規定しています。 API連携 API連携は、RESTful APIを使用してシステム間でデータをやり取りする方式です。提供側業務システムは REST による API を利用側業務システムへ公開し、利用側業務システムはその API を呼び出します。 ファイル連携 詳しい仕様についてはデジタル庁が提供している「 ファイル連携に関する詳細技術仕様書 」などをご覧ください。 重要な点についてまとめると、以下のようになります。 ストレージを使用してシステム間でデータをやり取りする方式です。 オブジェクトストレージを利用し CSV ファイルよる連携を行います。基本的に、提供側業務システムは、オブジェクトストレージが提供するツール（API等）を利用して、オブジェクトストレージ上の所定の格納先に CSV ファイルを格納します。それが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上で CSV ファイルを格納することができます。 共通機能を提供する事業者はオブジェクトストレージ上に業務の組み合わせごとのバケットを作成し、そのバケットを利用してシステム間でのデータのやり取りを行います。バケットが業務の組み合わせごとに分かれているため、提供側業務システムは、利用側業務システム単位に別々の連携ファイルを作成します。 例えば、北海道札幌市において(市区町村コード=011002)、住民基本台帳(システム区分＋業務ID=0001)と印鑑登録(システム区分＋業務ID=0002)の業務の組み合わせのバケットを作成する場合、バケット名は「011002-0001-0002」とします。 異なるCSP間又はCSPとオンプレミス環境間でファイル連携を行う場合、API 連携で利用する認証認可サーバをIDプロバイダーとし、 CSPの認証認可機能と連携 (フェデレーション) させ、IDプロバイダーでオブジェクトストレージの認証を行う必要があります。 AWS 上では、オブジェクトストレージには Amazon S3 を用います。上述したように、Amazon S3 のバケットを業務の組み合わせごとに作成し、その中でフォルダ分けします。 認証認可について 詳しい仕様についてはデジタル庁が公開している「 地方公共団体情報システム　共通機能標準仕様書 」や「 「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス 」などをご覧ください。 重要な点についてまとめると、以下のようになります client_secret_jwt による JWT を用いた認証を行います。それが難しい時のみ、API Key の利用を当面認めますが、ガバメントクラウドでは原則認められていません。 API 認可サーバーは自治体内で原則 1 つ用意します。ただし、以下に当てはまる場合などは必要ありません。 ファイル連携において連携元/連携先の業務システムがどちらもAWS上で稼働する場合 ファイル連携で認可サーバーを利用しない方法を使う場合 利用側業務システムが複数の提供側業務システムにアクセスする場合にも、提供側業務システムごとにアクセストークンを発行し、複数の提供側業務システムへアクセス可能なアクセストークンの発行は行いません。 AWS 上での実現方法 認証認可サーバーが必要な場合 API 連携を行う場合 API 連携における RESTful API は、 Amazon API Gateway などを用いて実現します。また、API 連携において必要になる認証認可機能については、Amazon Elastic Container Service (Amazon ECS) や Amazon Aurora を利用してサーバーを構築します。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者 認証認可サーバーの実装 データの要求元・データの要求先にそれぞれクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセ ストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など ファイル連携で認証認可サーバーを構築する場合 ここでは、ファイル連携で認証認可サーバーを構築する場合について図を用いて説明します。 それぞれの事業者には、以下の業務が発生します。 共通機能の構築業者 IAM Role の作成 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者（共通機能の構築業者が兼任することも多い） 認証認可サーバーの実装 データ利用側にクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など 認証認可サーバーが必要でない場合 AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、認証認可サーバーを構築しない方法として以下の 2 つの方法があります。 AWS Transfer Family を用いて SFTP で暗号化して通信する オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする（SSM Agent, IAM Role Anywhere） AWS Transfer Family を用いて SFTP で暗号化して通信する場合 上述のように、API によるファイルのアップロードやダウンロードが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上でファイルを格納することができます。AWS Transfer Family というサービスによって、SFTP を用いて Amazon S3 にオブジェクトを格納・取り出せます。 データ提供側の業務システム構築業者 対象の S3 バケットをバックエンドにした Transfer Family のセットアップ データ要求元が作成した SSH キーを利用したユーザーの作成 ユーザーに対応する S3 へアクセス可能な IAM ロールの作成 データ利用側の業務システム構築業者 認証に利用する SSH キーの作成 オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする場合 AWS の機能を利用し、オンプレミスや他CSPのサーバーへ IAM の権限を付与することができます。 SSM Agent を使う方法や、 IAM Role Anywhere を用いる方法があります。 ここでは、 SSM Agent を用いて、オンプレミスにあるデータ利用側の業務システムが、AWS 上にあるデータ提供側の業務システムのデータを利用する方法について図を用いて説明します。 まず、 AWSマネジメントコンソールのAWS Systems Managerのページにて、SSM Agentをインストールする際の有効化に必要なコードとIDを発行します。そして、作成した SSM Agent 用ロールをデータ利用側システム（オンプレミス）のサーバーが引き受けます。次に、 IAM STS を利用して、Amazon S3 にアクセスできるタスク実行用ロールの一時認証情報を取得します。最後に、取得した一時認証情報で Amazon S3 にアクセスします。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 データ利用側の事業者の IAM ロールが引き受けることのできる、S3 へアクセスできる IAM ロールを作成 データ利用側の業務システム構築業者 オンプレミスのサーバが利用する IAM ロールの作成 データ提供側の事業者へS3 へのアクセスに利用する IAM ロールを通知 オンプレミスのサーバでIAMロールが利用できるよう SSM Agent の設定 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ ここまででにあげた 3 つの方法について、表にまとめました。方法を選択する際の参考になさってください。   SSM Agent Transfer Family 認証認可サーバー 特徴 導入手順がシンプル SFTP の利用が可能 ID/Password認証が可能 標準仕様に記載された方法 API認可や職員認証で利用する認証認可サーバーがある場合は新規構築が不要 別CSPでも同様の方法が可能 考慮点 SSM Agent の導入やアップデートの工数 1000 台以上利用の場合は追加料金が発生 一時的な認証情報の利用はできない 200USD/月程度のコスト 認証認可サーバーの運用保守コスト OAuth 2.0 に準拠した API の実装コスト ユースケース コストを安く済ませたい場合 データ利用側・提供側のサーバーで SFTP を用いたい場合 API 認可や職員認証で認証認可サーバーを構築する場合 まとめ 本ブログでは、ガバメントクラウド上での標準準拠システムデータ連携について詳細をご紹介しました。重要なポイントとしては、AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、複数の認可方法があるため、どのような業務が発生するかを把握して選択することが挙げられます。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

こんにちは。 AWS パブリックセクター技術統括本部の押川です。 ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 本ブログは、「ガバメントクラウド活用のヒント」シリーズの一つとして、ガバメントクラウド上に構築したシステムに対する運用保守経路についてご説明いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 運用保守経路としての Transit Gateway の利用 運用保守経路としての PrivateLink の利用 運用保守経路としての Systems Manager Session Manager の利用 補足: 複数のアカウントの EC2 で一度に同じコマンドを実行する 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守経路としてのTransit Gateway の利用 ガバメントクラウドの道案内『ASP＆運用管理補助者編』 の(4) 運用保守経路を確保する にもありますが、ガバメントクラウド上で構築した業務システムへの運用保守経路を構築する必要があります。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、閉域経由での運用保守経路を構築する必要がありますが、ここではベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築する場合について記載します。 以下のように、事業者運用拠点から閉域を経由してガバメントクラウド上の本番アカウントに接続できるようにして、EC2 への SSH 接続やデータベースへのクエリの実行などの運用管理を行うことを可能にします。 この接続形式では、本番アカウントと事業者運用拠点は IP リーチャブルであり、双方向に通信が可能です。 この方法のメリットは、構築が簡単で、後述する AWS PrivateLink などのコストがかからないという点があります。 この方法のデメリットは、本番アカウントと事業者運用拠点が IP リーチャブルであることから、両者の IP アドレス範囲が重複しないように設計する必要があったり、ルートテーブルを管理する必要があるなどの点です。 一般的に、事業者運用拠点から複数の自治体の本番アカウントを保守しなければならず、そのすべての IP アドレス範囲と重複しないように事業者運用拠点を設計することは難しいため、後述するように AWS PrivateLink などで接続する方式が取られています。 運用保守経路としての PrivateLink の利用 先ほど述べた、事業者運用拠点と本番アカウントの IP アドレスが重複してしまうなどの問題を解決するために、AWS PrivateLink で本番アカウントの EC2 や RDS に接続することがあります。 事業者運用拠点から AWS PrivateLink の VPC エンドポイントに直接接続できますが、運用管理アカウントに踏み台サーバー (Amazon EC2) を設置する場合もあります。 AWS PrivateLink を利用すると、VPC エンドポイントの費用がかかります。接続したい対象の数だけ用意する必要があります。 参考として、 「AWS PrivateLink ワークショップ」 もご活用ください。 決まった数個の VPC エンドポイントのみで Amazon EC2 に接続することができるようになるのが、次の方法です。 踏み台サーバーを Systems Manager に代替する AWS Systems Manager には、Session Manager という機能があり、SSH のポートを解放しなくても Amazon EC2 にログインして操作を行うことができます。 マネジメントコンソールからの利用が一般的ですが、ガバメントクラウドでは、マネジメントコンソールへアクセスするために払い出されるユーザーからは Session Manager を利用することができません。しかし、運用管理アカウント経由など、本番アカウントのマネジメントコンソールを介さなければ Session Manager を利用することができます。 閉域から Session Manager を利用するには、AWS CLI の以下のようなコマンドを実行します。 aws ssm start-session --target instance-id この場合、運用管理アカウントと本番アカウントに、 Session Manager を利用するために必要な数個のエンドポイントを設置するだけで本番 EC2 へのログインが可能になります。 Session Manager を利用するために必要な VPC エンドポイントについては、 こちらのドキュメント をご覧ください。 AWS Systems Manager Session Manager では EC2 にしかアクセスできないので、例えば RDS に SSH ログインをしてクエリを実行するなどの保守作業を行いたいといったようなケースでは、踏み台サーバーが必要になります。 補足:複数のアカウントの EC2 で一度に同じコマンドを実行する メンテナンスなどで、複数の EC2 で同時にコマンドを実行したい場合、 AWS Systems Manager Automation を使えます。 各本番アカウントで定義された実行権限のあるロールに運用管理アカウントから AssumeRole してアクションを実行します。この場合、どのようなコマンドを実行するかなどのアクションを管理する Runbook は運用管理アカウント内で一括管理できます。 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守作業とは少し違いますが、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合のインターネットへの経路の設定についても補足しておきます。 ガバメントクラウド上では、ネットワーク分離の考え方から インターネットゲートウェイを設置することが制限されています。そのため、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合は、運用保守アカウントに NAT ゲートウェイ・インターネットゲートウェイを設置し、そこへの経路を設置する必要があります。 この場合、本番アカウントからインターネットゲートウェイが IP リーチャブルではない方がセキュアですので、途中に AWS PrivateLink を挟みます。そして、その到達先として Amazon EC2 を設置し、そのサーバーを経由して NAT ゲートウェイ・インターネットゲートウェイにアクセスするようにします。 まとめ 本ブログでは、ガバメントクラウド上での運用保守経路について詳細をご紹介しました。複数のパターンのメリットとデメリットを把握し、適切な運用保守経路を構築することが必要です。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

本ブログは、三協立山株式会社と Amazon Web Services Japan が共同で執筆しました。 三協立山株式会社 は ビル・住宅・エクステリア建材の開発・生産・販売までを一貫して手がけるほか、アルミやマグネシウム合金の鋳造・押出・加工や販売を行っています。商業施設向けの陳列棚やショーケース、屋外看板などを提供し、メンテナンスも担っています。本ブログでは三協立山が開発した社内向けサービス 「AI ふたば」 の概要とその中でどのように Amazon Bedrock が活用されているかを紹介します。 　 課題と背景 三協立山では 2023 年 6 月に社長より生成 AI の積極的活用方針が示され、特に生産性向上を目指した取り組みを優先的に始めることになりました。 生成 AI の導入に向けて、社内ルールやガイドラインの整備、E-ラーニングの作成など、社員限定での利用環境の整備を進めていき初期バージョンの「AI ふたば」をリリースしました。この時点では Amazon Bedrock は 採用しておらず、他社の LLM を使って実装していました。しかし、実際の運用においていくつかの課題が浮き彫りとなってきました。 主な課題として以下が挙げられます： 文字数制限による議事録の自動作成への活用の難しさ 業務での具体的な活用シーンの不明確さ 自社情報の活用ニーズ（過去の資料検索の非効率性）への対応 また、プログラミングや文書作成業務に従事する一部のヘビーユーザーを除き、全社的な活用は進んでいない状況でした。社内情報を活用した RAG（Retrieval-Augmented Generation）の自社開発も試みましたが、実装の困難さに直面していました。これらの課題に対し、より実用的で効果的な生成 AI 活用の仕組みづくりが求められていました。 ソリューションの概要 そのような課題がある状況で AWS より Generative AI Use cases JP (以下、GenU) をご提案しました。CDK や React の経験が全くなく不安もあったそうですが、開発メンバーの川崎さんは「AWS はほぼ初心者で CDK も今回初めて存在を知ったくらいですが、Readme ファイルなども充実しており、想像以上に簡単に始めることが出来ました。」さらに「コーディングで分からないところは AI ふたば自身で確認をしながら進められ、ローカル環境で動かして画面を確認しながら修正ができるので敷居が低かった。議事録の文字起こし機能のバックエンド部分を非同期処理で実装することもできました。」と語っています。 また、GenU が元々持っていたプロンプトテンプレートを自社向けにカスタマイズし、業務での具体的な活用シーンに即して 50 パターンほど用意しています。 図 1 : AI ふたばの画面イメージ 自社データの活用については、GenU に含まれている Amazon Kendra を活用した RAG を採用しました。商品情報では「X.スタイル」と「クロス.スタイル」など言葉の揺らぎに対してはプロンプトやファイルの置き方を工夫したり、メタデータを活用して、検索精度を高めることに成功しました。また Amazon Bedrock にはない外部の LLM も利用できるようにカスタマイズを行っており、エンドユーザーに多くの選択肢を提供するように工夫しています。 以下の図 2 がAI ふたばのアーキテクチャーの概要になります。 図 2 : AI ふたばのシステム構成 導入効果と今後の展開 GenU をベースとしてカスタマイズをしたことで、AI ふたば Ver2 はたった１か月でリリースすることができました。Ver2 での議事録作成機能の追加やプロンプトテンプレートでユースケースを提示したことで社内の利用者は 1.5 ～ 2 倍程度拡大しました。また当初から要望の多かった議事録作成機能をリリース出来たことで年間で 1 万 5000 時間の業務時間削減効果が見込まれています。 川崎さんは「AWS は初心者で、しかも OSS として公開されている GenU をベースにして開発するという体験は、今までの既存アプリのバージョンアップ中心だった業務から、世の中の動きを知るきっかけになりました。IaC である CDK も初めて使いましたが、あまりの便利さにこれから他の開発でも CDK を使ってみようと思います。」と語っています。同じく開発メンバーの船場さんは「生成 AI も Amazon Bedrock を利用することで非常に簡単に実装できるということが 分かりました。」と語っています。 GenU はアプリケーションのソースコードはもちろん、AWS の各種サービスもビルディングブロックで組み合わされたものを CDK　の形で OSS として公開しています。そのままお使い頂くこともできますが、今回の事例のようにカスタマイズして使う事もできるようになっているのが特徴です。 情報システム統括室システム企画開発部の高畑部長は、「若手のメンバーが面白がって取り組んでくれた。GenU をベースにしながらも、Ver1 の見た目に寄せるようカスタマイズしたことでエンドユーザにとっても違和感なく展開することができました。」と語っています。 　 今後の展開としては以下のようなことを検討しています。 議事録機能の更なる改善 エージェント機能の追加 Amazon Kendra へのファイル連携機能の効率化 まとめ 本ブログでは 三協立山で導入した AI アシスタントサービスの紹介とその中で Amazon Bedrock や GenU がどのように活用されているかを紹介しました。 Amazon Bedrock を利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。 本ブログは、三協立山 株式会社と AWS のソリューションアーキテクトの水野が共同で執筆いたしました。 三協立山ショールームにて撮影 左から 情報システム統括室システム企画開発部 高畑 裕紀 部長 情報システム統括室システム企画開発部企画開発一課 船場 和馬 改革推進統括室デジタル改革推進部デジタル改革推進グループ 川上 貞昭 グループ長 情報システム統括室システム企画開発部企画開発一課 川崎 翔平 副主任 情報システム統括室システム企画開発部企画開発一課 阿閉 清紀 課長 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

ビジネス上の重要な処理に SAP システムを利用している企業は、高い可用性とパフォーマンスを求められるため、オブザーバビリティ戦略は運用の効率化に欠かせない重要な要素となります。 SAP HANA、SAP Business Suite on HANA、または SAP S/4HANA などのソリューションを実行する大規模な SAP 環境を持つ企業は、これらの環境に複数のモニタリングオプションがあります。SAP Solution Manager、Amazon CloudWatch Application Insights などのソリューションは、一般的にシステムの正常性とパフォーマンスを監視するために使用されます。しかし、エンタープライズのモニタリング戦略を見ると、SAP と非 SAP ソリューションを組み合わせ、さらにマルチクラウド構成にすることで、可視化やアラートを単一の画面上で表示するダッシュボードを実現し、長期的なアーキテクチャを最適化します。Prometheus や Grafana などのツールは、SAP と非 SAP 環境を組み合わせたシステム監視のセットアップを実現するため、SAP と Amazon のマネージドオファリング (Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG)) を使用する組織でも既に使用されており、クラウドネイティブ技術を提供します。 SAP のお客様も、RISE with SAP で AWS を選択することが増えています。RISE に移行していないお客様のために、この解決策により、SAP ワークロードの監視能力が向上します。このブログでは、 AWS Well-Architected Framework の SAP Lens のベストプラクティスに従って AMP と AMG を構成することで、SLES (SUSE Linux Enterprise Server) OS と SAP S/4HANA の監視ダッシュボードのセットアップ方法を学びます。 セットアップが完了すると、オペレーティングシステム、SAP アプリケーションサーバー、SAP 高可用性クラスターの各コンポーネントについて、複数のダッシュボードにまたがって SAP 環境全体の正常性を確認できます。 定義 このブログで使用する用語を定義しましょう。 オブザーバビリティ : オブザーバビリティ（可観測性）とは、システムの状態や性能を把握するための仕組みを指します。具体的には、システムの状態を示すメトリクス（指標）、ログ、トレースを用いて分析します。システムのパフォーマンスを理解することは、運用の優秀性を達成し、ビジネス目標を満たすための鍵となります。 「監視」という用語は時にオブザーバビリティとは異なると定義されますが、しかし監視はトレースやログ収集などの活動と並んで、システムを観測可能にする活動です。 Amazon Managed Prometheus (AMP) : AMP はメトリクスのためのサーバーレス、Prometheus 互換のモニタリングサービスで、大規模なコンテナ環境をセキュアに監視することを簡単にします。AMP を使えば、お客様は今日使っているオープンソースの Prometheus データモデルとクエリ言語を使って、ワークロードのパフォーマンスを監視できます。また、基盤となるインフラストラクチャを管理する必要がなく、スケーラビリティ、可用性、セキュリティの向上もあります。 Amazon Managed Grafana (AMG) : AMG は、完全にマネージドされ、セキュリティが確保されたデータ可視化サービスで、顧客はさまざまなデータソースから運用状況のデータを素早く照会、関連付け、視覚化できます。AMG は、拡張可能なデータサポートで広く利用されているデータ可視化ツール Grafana を簡単にデプロイ、運用、スケーリングできるようにしています。 前提条件 前提条件として、高可用性の有無にかかわらず、AWS アカウント内に SAP システムをセットアップする必要があります。設定を行うユーザーアカウントには、AWS IAM でロールを割り当てる権限が必要です。このブログでは、SAP S/4HANA システム (ASCS/ERS と SAP HANA DB クラスターおよび 2 つのアプリケーションサーバー) を、SLES for SAP 15 SP4 オペレーティングシステム上で動作させています。 アーキテクチャ まずはこのソリューションの基本的なアーキテクチャを理解しましょう。図 1 は AWS 上で SAP S/4HANA を高可用性 (HA) 構成にした典型的なアーキテクチャを、図 2 はオブザーバビリティのアーキテクチャを示しています。 すべての SAP システムは SAP 認定 Amazon EC2 インスタンス上にインストールされ、データの移動は全て VPC エンドポイントを経由します。 図 1: AWS 上の SAP S/4HANA 高可用性 (HA) アーキテクチャの表現 図 2: Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG) を使用した SAP の可観測性アーキテクチャ 設定と構成 図 3 の下に示すように、ソリューションを構成する手順は以下の通りです。 図 3: AMP を使用した SAP の監視構成と AMG での可視化のためのステップ AMP ワークスペースの作成と設定 データは AMP Workspace に「リモートライト」方式で取り込まれ、AMG のダッシュボードのデータソースとして使用されます。 ユーザー ID に Amazon Managed Service for Prometheus (AMP) コンソールから「Create workspace (ワークスペースの作成)」を選択する権限があることを確認し、図 4 に示すようにしてください。 図 4: AMP ワークスペースの作成 AMP でワークスペースが作成されると、サービスがリモート書き込み URL (図 5 に示されている) を提供します。後のセクションの構成手順でこの URL が必要になるので、 リモート書き込み URL を控えておいてください。 図 5: AMP ワークスペースエンドポイントの詳細例 EC2 IAM から AMP にメトリクスをストリーミングする AmazonPrometheusRemoteWriteAccess AWS 管理ポリシー を使用して、Amazon EC2 インスタンスの IAM ロールを作成します。このロールを EC2 インスタンスに割り当てるか、この新しく作成したロールで EC2 インスタンスを起動するか、または既存のロール ( AWS ドキュメント の図 6 のように) に AmazonPrometheusRemoteWriteAccess ポリシーを割り当てることができます。 図 6: AMP ポリシー名 VPC エンドポイント EC2 インスタンスから AWS バックボーンネットワークを経由して AMP にメトリクスをプライベートに送信するために、AMP 用の VPC エンドポイントを設定する必要があります。 VPC エンドポイントにより、VPC 内のリソース (この場合は EC2 インスタンス) から管理型サービスに安全にアクセスできるようになります。 次に、以下の手順で AMP の VPC インターフェイスエンドポイントを作成します: AWS コンソールから、VPC サービスの「Endpoints」を選択し、図 7 のように「Amazon WorkSpaces」サービスを選択します。 図 7: AMP 用の AWS VPC エンドポイントサービス名 VPC 内のリソースがこれらのインターフェイスエンドポイントに HTTPS で通信を行えるように、VPC 内のセキュリティグループを変更する必要がある場合もあります。インターフェイスエンドポイントの作成方法の詳しい手順は、 AWS ドキュメント で確認できます。 さらに、VPC から直接インターネットにアクセスできない場合は、図 8 に示すように、sigv4 がエンドポイントを介して機能できるよう、AWS Security Token Service 用のインターフェイス VPC エンドポイントも作成する必要があります。 図 8: AWS Security Token Service の VPC エンドポイントサービス名 Metrics Exporters と Prometheus の EC2 インスタンスへのインストールと設定 この手順では、EC2 インスタンス上に必要なエクスポーターと Prometheus エージェントをインストールする方法を学びます。 Prometheus のエクスポーターは、システムからメトリクスを収集し、Prometheus で読み取り可能にする役割を果たします。 Prometheus のエージェントは、メトリクスをエンドポイントに転送する役割を果たします。 各 SAP アーキテクチャコンポーネントのエクスポーターのリストは表 1 にまとめられています。 さらに、すべての EC2 インスタンスで Prometheus エージェントのインストールが必要で、そのことでデータを AMP に転送できるようになります。 SAP システムロール エクスポーター名 詳細情報の URL SAP ASCS/ERS クラスター ClusterLabs ha_cluster_exporter Prometheus node_exporter https://github.com/ClusterLabs/ha_cluster_exporter https://github.com/prometheus/node_exporter SAP アプリケーションサーバー SUSE sap_host_exporter Prometheus node_exporter https://github.com/SUSE/sap_host_exporter https://github.com/prometheus/node_exporter 表 1: SAP 各コンポーネントで EC2 にインストールするエクスポーターのリスト 2.1 Node Exporter Prometheus Node Exporter は、ハードウェアやカーネルに関する様々なメトリクスを公開し、それらのメトリクスを使って EC2 のヘルスステータスをダッシュボードで表示できます。 EC2 インスタンス上で node exporter をインストールして実行する手順は次のとおりです。( Prometheus のウェブサイト にも記載があります)。 Linux (SLES) オペレーティングシステムを実行している EC2 インスタンスで node exporter をインストール、展開、実行するには、以下のコマンドを実行してください。は node exporter のバージョン、-は OS のアーキテクチャに置き換えてください。 ダウンロードできる Node exporter パッケージは Prometheus のウェブサイト で確認できます。 wget https://github.com/prometheus/node_exporter/releases/download/v/node_exporter-.-.tar.gz tar xvfz node_exporter-*.*-amd64.tar.gz cd node_exporter-*.*-amd64 ./node_exporter Node Exporter はお好みのディレクトリ(例: /usr/local/bin)にインストールできます。実行すると、Node Exporter はローカルサーバーの 9100 番ポートの /metrics エンドポイントでメトリクスを公開します。 次の curl コマンドを実行して、9100 /metrics エンドポイントでメトリクスがエクスポートされていることを確認できます。 curl http://localhost:9100/metrics コマンドの出力は次のようになります: # HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total { cpu ="0",mode ="idle"} 6.8382833e + 06 node_cpu_seconds_total { cpu ="0",mode ="iowait"} 824.38 node_cpu_seconds_total { cpu ="0",mode ="irq"} 0 # その他の設定など この手順を完了すると、SAP の役割に関係なく、すべての SAP EC2 インスタンスに node exporter がインストールされます。 2.2 ASCS/ERS EC2 インスタンスでの HA クラスターエクスポーター Clusterlabs HA Cluster Exporter はステートレス HTTP エンドポイントです。 各 HTTP リクエストで、さまざまなクラスタコンポーネントのツールによって提供される既存の分散データを解析することで、クラスタの状況をローカルで検査します。 エクスポートされるデータには、次のような情報が含まれます。 ペースメーカークラスタの概要、ノードとリソースの統計情報 Corosync の通信リングのエラーとクォーラム投票 DRBD リソースなど 高可用性 SAP システムの設定では、corosync、pacemaker、フェイルオーバーの状態などのサービスの状況を把握することで、システムをよりよく理解し、障害の根本原因を特定するのに役立ちます。 ASCS と ERS の両方の EC2 インスタンスで、root ユーザーまたは sudo 権限を持つユーザーとしてエクスポーターパッケージをインストールして実行してください。 zypper install prometheus-ha_cluster_exporter ./ha_cluster_exporter HA Cluster Exporter を実行すると、デフォルトでポート 9664 の /metrics パスの下にメトリクスがエクスポートされます。 ホスト上で実行中の /usr/bin/ha_cluster_exporter プロセスを確認すれば、HA クラスタのプロセスの状態を確認できます。 2.3 アプリケーションサーバーインスタンス上の SAP ホストエクスポーター SAP Host Exporter はステートレスの HTTP エンドポイントです。 各 HTTP リクエストでは、SAPControl Web インターフェイスを介して SAP システムからランタイムデータを取得します。 エクスポートされたデータには、以下のような情報が含まれます: サービスプロセスを起動する サーバー統計を (統計情報を)キューに登録する SAP アプリケーションサーバー ディスパッチャーのワークプロセスキュー統計 sap_host_exporter をインストールするには、以下のコマンドを使用してください。 export DISTRO = SLE_15_SP4 # 自身の OS のバージョンに合わせて変更してください zypper addrepo https://download.opensuse.org/repositories/server:/monitoring/$ DISTRO/server:monitoring.repo zypper install prometheus-sap_host_exporter インストール後は、次のように exporter を実行し、図 9 に示されているように、Unix ドメインソケットを経由して SAPControl Web サービスに接続できます。 ./sap_host_exporter — sap-control-uds /tmp/.sapstream51213 図 9: SLES でプロセスとして実行されている sap_host_exporter サービス これにより、デフォルトでポート 9680 の /metrics パスでメトリクスを公開します。 SAP アプリケーションサーバーが実行中の SAP EC2 インスタンスで SAP ホストエクスポーターをインストールするには、これらの手順を実行してください。 2.4 Prometheus エージェント Prometheus は EC2 インスタンスからデータを収集し、AMP に保存します。したがって、このステップでは、リソースの使用量が少ない Prometheus のエージェントモードをインストールします。Prometheus に同梱されている UI 機能やアラート機能は必要ありません。また、AMP へのリモートライトを設定します。 Prometheus サーバーは任意のディレクトリにインストールできます。例えば /usr/bin です。この例では、以下のコマンドで示したように、SLES for SAP 15 SP4 オペレーティングシステムに Prometheus v2.49.1 をインストールします。 Prometheus がインストールされたディレクトリに移動します。 wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* Prometheus のインストールディレクトリ内に、YAML 形式で記述された設定ファイル prometheus.yml があります。ファイルの中身は次のようになっています。 # グローバル設定 global: scrape_interval: 15s # スクレイプ間隔を 15 秒に設定します。デフォルトは 1 分です。 evaluation_interval: 15s # 15 秒ごとにルールを評価します。デフォルトは 1 分です。 # scrape_timeout はグローバルのデフォルト (10 秒) が設定されています。 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # 1 つのエンドポイントのみをスクレイピングする構成: # ここでは Prometheus そのものです。 scrape_configs: # ジョブ名がラベル `job =` として、この構成からスクレイピングされた全てのタイムシリーズに追加されます。 - job_name: "EC1-CS" # metrics_path はデフォルトで '/metrics' に設定されます # scheme はデフォルトで 'http' に設定されます。 static_configs: - targets: ['localhost:9664','localhost:9100'] remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces//api/v1/remote_write sigv4: region: queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 私たちのユースケースに合わせるために、 prometheus.yml ファイルで次の変更を行う必要があります: job_name を、観測性ダッシュボード上でこのシステムを識別できるような名前に変更してください。例えば、SAP Application Server EC2 インスタンスについては「SAP S41 App Server」、SAP 中央サービス EC2 インスタンスについては「S41 ASCS/ERS」などです。 targets の : 設定を変更します。ホストは Exporter が実行されているホストを、ポートは Exporter がメトリクスを公開しているポートを指定します (例: localhost:9100)。上記のように、複数のターゲットを設定できます。例えば、SAP Application Server EC2 インスタンスの yml ファイルの設定では、SAP Host Exporter と Node Exporter からメトリクスをスクレイピングするために、’localhost:9680′ と ‘localhost:9100’ の 2 つのターゲットエントリがあります。 yml ファイルの最後に remote_write URL セクションを追加します。remote_write URL は、ステップ 1 で AMP 作成時に控えた URL に、AWS リージョン (例: us-east-1) を指定して変更してください。 prometheus.yml ファイルを更新したら、以下のコマンドを実行してエージェントモードで Prometheus を実行します。 ./prometheus --config.file =./prometheus.yml --enable-feature = agent & 各 SAP コンポーネントの正しいポートを特定し、すべての EC2 インスタンスでこれらの手順を実行してください。 このタイミングで、データが AMP に送信されており、Amazon Managed Grafana の構成が可能になりました。 Prometheus Agent Mode エージェントモードでは、リモートライトユースケースに最適化されています。クエリ、アラーティング、ローカルストレージが無効化され、カスタマイズされたタイムシリーズデータベースのライトアヘッドログに置き換えられます。その他の機能(スクレイピングロジック、サービスディスカバリ、関連設定) は同じままです。 エクスポーターを systemd サービスとして有効化する これらのエクスポーターやエージェントを起動時に自動起動するように設定することをお勧めします。これは systemctl を使って行うことができます。以下が HA クラスターの例です。 systemctl --now enable prometheus-ha_cluster_exporters 他のサービスについても同じように設定できます。 systemctl についての詳細は、 SUSE のドキュメント を参照してください。 AMG の設定と監視ダッシュボードのセットアップ AMG は、可視化ツールの人気製品である Grafana のフルマネージドサービスで、Amazon Managed Prometheus と連携することで、メトリクス、ログ、トレースに対するクエリ、可視化、アラートを行えるようになります。 この項では、Amazon Managed Grafana (AMG) の構成方法と SAP S/4HANA の監視ダッシュボードのセットアップ方法について説明します。 この項に記載されている手順は、Amazon Managed Service for Prometheus (AMP) サービスで収集された SAP のメトリクスに対する監視ダッシュボードをセットアップするために必要な AMG サービスの構成手順を示しています。 3.1 Amazon Grafana でワークスペースを作成する Amazon Managed Grafana において Amazon Managed Prometheus をデータソースとして、新しいワークスペースを作成しましょう。Amazon Managed Grafana におけるワークスペースは、Grafana サーバーの論理的なユニットです。 AWS コンソールから Amazon Grafana サービスを開き、図 10 のように希望のエイリアスでワークスペースを作成します AWS IAM Identity Center(ID センター) と SAML の間から、好みの認証アクセス方法を選んでください オプションですが、推奨されるのは、SAP VPC 内のデータソースに接続する場合、ワークスペースから SAP VPC への VPC 接続を選択すること (これにより、パブリックインターネット経由のリクエストを回避できます) Service Managed と Customer Managed の間から、権限管理方式を選んでください 最後に、図 11 に示されているように、Data Sources のリストから Amazon Managed Prometheus をデータソース名として選択します 図 10: AMG ワークスペースエイリアス 図 11: AMG のデータソース名 数分かかりますが、この段階で Grafana ワークスペースの準備が整いました。 3.2 Amazon Grafana ワークスペースを構成する AMG でワークスペースの作成が完了したら、次は Amazon Managed Service for Prometheus (AMP) との統合です。ステップには Grafana ワークスペースコンソールでの管理者権限によるユーザー作成、Grafana ワークスペースコンソールでの AMP データソースの構成、Grafana ワークスペースコンソールへの監視用ダッシュボードのインポートが含まれます。 AMG では、Grafana コンソールへのアクセスの認証基盤として、AWS IAM Identity Center と SAML を認証基盤として利用できます。AMG ワークスペースのアクセスと Grafana ワークスペースコンソールの設定には、管理者ユーザーを設定する必要があります。ユーザーは AWS IAM Identity Center または外部の ID プロバイダに設定できます。この記事では、AWS IAM Identity Center にユーザーを設定しました。AWS IAM Identity Center に設定されたユーザーには、 AWSGrafanaAccountAdministrator と AWSSSODirectoryAdministrator のポリシーが必要です ( こちら を参照)。オプションのロールを確認し、必要に応じて割り当ててください。ワークスペースへのアクセスの認証方式として SAML を選択した場合は、記載された手順に従ってください。 ユーザーの作成後、Amazon Managed Grafana (AMG) ワークスペースにユーザーを割り当て、Grafana コンソールを設定するユーザーに対して「管理者権限を付与する」アクションを実行します。実行するには、AWS コンソールから AMG を開き、「すべてのワークスペース」をクリックし、新しく作成したワークスペースをクリックします。認証タブ内で、AWS Identity Center でユーザーまたはグループを追加するか、SAML 設定を行います。ユーザーが追加されたら、そのユーザーを選択し、アクションロップダウンから「管理者権限を付与する」を選択します (図 12 参照)。この手順を完了すると、管理者権限を付与したユーザーは、このワークスペースの Grafana コンソールを管理者として利用できるようになります。 図 12: AMG 用の AWS IAM Identity Center ユーザー Grafana ビューアユーザー ダッシュボードの作成には Admin ユーザーのみを使用し、ダッシュボードの表示にはセキュリティおよびコスト最適化の観点から「ビューア」ユーザーの使用を推奨します。 Grafana ワークスペースコンソールの URL を取得します。これを行うには、AWS コンソール内の Amazon Grafana サービスを開き、 全てのワークスペース をクリックし、新しく作成したワークスペースに関連付けられているワークスペース URL を見つけてください。図 13 のように表示されます。 図 13: Grafana ワークスペース URL の例 前のステップで管理者として構成したユーザー認証情報を使って、ワークスペース URL にアクセスし、AMG ワークスペースコンソールにログインします Grafana ワークスペースコンソールにログインした後、「アプリ」->「AWS データソース」->「データソース」の順に選択し、Amazon Managed Service for Prometheus の中からステップ 1 で作成した Amazon Managed Prometheus ワークスペースをメトリクス収集用に選択します (図 14 の通り)。 図 14: Grafana ワークスペースのデータソース設定 Amazon Managed Prometheus ワークスペースをデータソースとして正常に追加できると、Administration -> Data sources タブに設定済みのデータソースとして表示されます (図 15 参照)。 図 15: AMG のデータソースとして AMP 3.3 SAP レポートをインポート Grafana のダッシュボードは JSON 形式のレポートを使って作成できます。独自のレポートを作成するか、Grafana で提供されているレポートをインポートすることができます。このブログでは、インポートオプションを使用しており、使用するレポートは以下の通りです。 Node Exporter を使用した OS レベルのデータ (ID 1860) ASCS/ERS 上で Pacemaker を実行している HA クラスター (ID 12229) SAP Application Server (ID 12761) AMG ワークスペースコンソールにログインし、ダッシュボードタブに移動します。図 16 のように、JSON レポートをアップロードするか、Grafana.com のレポート ID でインポートして、レポートをインポートしてください。 図 16: JSON アップロードまたは Grafana.com のダッシュボード ID を使用してダッシュボードをインポートする すべてのレポートを追加した後、次のような画面が表示されます: 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターダッシュボード 図 19: ノードがダウンしたときのマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP アプリケーションサーバーディスパッチャーキューダッシュボード 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターのダッシュボード 図 19: ノードがダウンしている場合のマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP Application Server ディスパッチャーキュー ダッシュボード AMG データソースとマルチクラウドダッシュボード 設定手順と図 22 に示されているように、Amazon CloudWatch、Amazon Athena などの他のデータソースを指定できます。これにより、SAP 以外のシステムだけでなく、ハイブリッドおよびマルチクラウド環境のダッシュボード化が可能になります。 図 22: AMG のデータソース 結論 Prometheus と Grafana は、SAP ランドスケープを監視・可視化するための強力なオープンソースツールです。 AWS での AMP と AMG の利用により、組織はよりよい自動化とセキュリティポスチャを得ることができます。 SAP の可観測性ダッシュボードを構築するための AMP と AMG を使用することで、Prometheus と Grafana のデプロイやインフラストラクチャの管理、定期的なソフトウェアアップデートの実施などの負担なく、一元的に可観測性ダッシュボードを確認できます。 この記事では、Amazon Managed Prometheus と Amazon Managed Grafana を使用して、SAP S/4HANA システムの SAP 監視ダッシュボードをセットアップする方法について説明しました。 また、Grafana の他のデータソースを使用して、非 SAP システムを組み込む方法についても説明しました。 AMG、ダッシュボードの種類、セキュリティ機能の詳細については、 AWS ドキュメンテーション を確認してください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 あけましておめでとうございます。本年も週刊生成AI with AWSと、週刊AWSをよろしくお願いいたします。今年も最新情報をギュッとまとめてお届けしますので、引き続きご期待くださいね。 それでは、12 月 23 日週と 30 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: アオラナウ株式会社、AWSのGenUを活用した社内RAGシステムで技術調査業務の効率化を実現 アオラナウ株式会社様はServiceNowの価値を最大化することに取り組んでいます。50名を超える従業員には、技術的な熟練度が高いメンバーと未経験のメンバーが混在しており、それぞれ情報検索や個人が抱える課題の解決に時間を要する、同僚への質問を躊躇してしまうという課題がありました。これを解決するために Generative AI Use Cases JP(GenU) を活用し、高度なRAGシステムを短期間・低コストで構築することに成功しました。これによってドキュメント検索時間が1/5に、未経験メンバーから熟練メンバーへの質問件数の減少、質問自体の質の向上という成果を上げています。 ブログ記事「個性的なモデルに出会える Amazon Bedrock Marketplace で基盤モデルの選択肢を増やそう」を公開 世の中には様々な生成AIモデルがあります。AWS re:Invent 2024ではAmazon Bedrock Marketplaceが発表され、100以上のモデルをAmazon SageMakerにデプロイし、BedrockのAPIでアクセスすることが可能になりました。これによってBedrockで選択できるモデルではカバーできない、特徴をもったモデルを利用したくなった場合にも、アプリケーションの変更を最小限に抑えて最適なモデルを活用しやすくなります。この記事では、Amazon Bedrock Marketplaceの使い方や、日本発のモデルについて紹介しています。 ブログ記事「Stable Diffusion 3.5 Large が Amazon Bedrock でご利用いただけるようになりました」を公開 Amazon BedrockでStable Diffusion 3.5 Largeが利用できるようになりましたので、その深掘り記事を公開しました。 ブログ記事「Amazon Bedrock アプリケーションで責任ある AI のコアディメンションに対応するための考慮事項」を公開 責任あるAI活用の考え方は、生成AIの活用において重要度が高いテーマです。この記事は英語版の翻訳ですが、「責任あるAI」に含まれる概念を整理し、Amazon Bedrockでどのようにそれを実現していくかを説明しています。安全なAI活用のために、なにから始めればいいのか悩んでいる方におすすめの記事です。（大作なので徐々に読み進めるのも良いアイデアです） サービスアップデート Amazon Bedrock Agents, Flows, Knowledge Basesがレイテンシ最適化モデルに対応 AWS re:Invent 2024で発表された推論時のレイテンシーを最適化する機能に、Amazon Bedrock Agents, Flows, Knowledge Basesが対応しました。この最適化機能はAnthropic Claude 3.5 Sonnetと、Meta Llama 3.1 70B/405Bに対応しており、これらのモデルを利用する際に精度を損なうことなく推論時の遅延時間を短縮することでユーザ体験の向上につながります。ちなみにオレゴンリージョンでクロスリージョン推論を介して利用することが可能です。 AWS NeuronがTrainium2とNxD Inferenceに対応 Neuron 2.21 が発表され、AWS Trainium 2 チップを搭載したAmazon EC2 Trn2インスタンスと、Trn2 UltraServersがサポートされました。同時に、PyTorch 2.5がサポートされ、 NxD Inference (ベータ)とNeuron Profiler 2.0(ベータ)が利用可能になっています。NxD InferenceはvLLMと統合されたPyTorchベースのライブラリで、大規模言語モデルやマルチモーダルモデルのデプロイを簡素化します。 Amazon SageMaker JumpStartでMeta Llama 3.3 70Bが利用可能に Amazon SageMaker JumpStartを利用してMeta Llama 3.3 70Bモデルを利用できるようになりました。SageMaker JumpStartは数クリックで事前構築済みの機械学習ソリューションを数回のクリックで起動できる機械学習ハブで、最新のモデルを簡単に利用できます。詳細については ブログ記事 が出ていますので、そちらもご覧ください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

想像力豊かなクリエイティブを大手広告代理店やグローバルブランド、エンターテイメント企業向けに制作するには、限りない想像力が必要です。そのためには、 Hornet が 25 年以上にわたって実写映像、ビジュアルエフェクト（VFX）、ストップモーション、モーションデザイン、3D、セルアニメーション、ブランド戦略の仕事で発揮してきたような創造性が求められます。 こちらのスタジオでは継続的な成長と進化のため、作品の需要に応えるためにインフラストラクチャをレベルアップする必要があり、必要に応じたスケーラビリティ確保のため、Hornet はクラウドを活用する計画を立てました。SI 企業の インテグレーテッド・メディア・テクノロジーズ（IMT） と協力して、スタジオは最終的に Amazon Web Services (AWS) とのインテグレーションを選択し、効率的なクラウドベースのレンダーファームをデプロイしました。 「私たちの業界では、プロジェクトの増減にともなうリソースキャパシティーが常に課題となっていました。クラウドはそのための完璧なソリューションです。制作量の急増や特殊なマシン要件に対応するために必要な機材をすべて購入またはレンタルすることは、楽しくも経済的でもありません。そのため、必要に応じてリソースを増減できることは、私たちにとって大きなメリットとなります。」と、Hornet のマネージングパートナー Greg Bedard 氏 は語ります。 また、Hornet のパイプラインテクニカルディレクター Kevin Poli 氏は次のように付け加えています。「さまざまなクラウドオプションを検討しましたが、AWS は他とは比較にならないほど優れていました。これは間違いなく最も成熟したテクノロジーです。」「AWS のトレーニングを受けるための素晴らしい教育リソースがたくさんあり、とても利用しやすかったです。」 画像提供: Hornet 将来を見据えた構築 長年にわたってレンダリング管理ソフトウェア AWS Thinkbox Deadline を使用していた Hornet によるクラウドプロバイダーの決定の背景には、AWS とのネイティブ統合の影響もありました。スタジオは当初、2021 年にオンプレミスと AWS でハイブリッドレンダリングソリューションを開発していましたが、新しいクラウドベースの AWS 実装をゼロから構築したいと考えていました。この戦略は、2023 年にニューヨーク市のソーホー地区にある新しい場所へのスタジオ移転において、オンプレミスのデータセンター構築に多額の投資をせずに規模を拡大するための基盤となりました。人口密度の高い地域に移転すると、物理的な拡張はほとんど不可能になるため、機械をレンタルまたは購入するという物流上の問題を回避したいと考えていたためです。 クラウドベースのレンダリングに最適化することがパズルの最初のピースでした。セキュリティの強化も優先事項でした。Hornet のパイプライン責任者である Gareth Porter 氏は、「ファイルアクセスをより適切に制御できるようにしたかったのです。」と述べています。「IMT チームは、セキュリティのナビゲートに特に役立ちました。さらに、リソースの効率化のためにワークフローを最適化しました。」 Hornet は IMT チームと AWS サポートと協力して、オンプレミスインフラストラクチャに接続された AWS クラウドスタジオ環境を構築しました。デプロイには Amazon Elastic Compute Cloud ( Amazon EC2 ) スポットインスタンス によるレンダリングが含まれ、現在は GPU ベースのバーチャルアーティストワークステーションを含むように拡張されています。これにより、スタジオのリモートアーティストは、デジタルコンテンツ制作（DCC）ソフトウェアをクラウド上でローカルワークステーションと同じ応答性で実行するために必要となる高いパフォーマンスを得ることができます。 「私たちは AWS を使うには十分な知識がありましたが、クラウド上で複雑なプロダクションワークフローを構築するには十分ではありませんでした。IMT のおかげで、機能的なシステムを管理しているインフラストラクチャの中核要素に置き換えることができました。」と Poli 氏は説明しました。 「私たちのワークフローは今ではずっと安定しています。このプロセスと経験を積むことで、クラウドを最も効率的に使用する方法と、より多く成功するために管理する方法を理解し始めています。」と Porter 氏は付け加えました。 画像提供: Hornet クラウドへの接続 Hornet のオンプレミスファームは、アイドル状態または利用可能なコンピューティングを備えたアーティストワークステーションと専用のレンダリングノードが混在しています。マシンのスペックはさまざまで、チームは可用性と要件に基づいてレンダリングジョブを割り当てます。 「もし締め切りが間近に迫っていて、1 時間分のレンダリングをこなす必要がある場合は、できるだけ多くのノードを立ち上げてそれを実行します。」と Porter 氏は説明します。「私たちは、このシナリオで最も費用対効果の高いマシンを選択することを目指しています。時間があれば、より少ないノードを選択するかもしれませんが、そうでない場合は、状況に応じて必要なリソースを手に入れます。」 スタジオは AWS Thinkbox Deadline 10 を使用してハイブリッドレンダリングファームを管理し、 スポットイベントプラグイン を活用して Amazon EC2 スポットフリート でレンダリングリソースをスケーリングしています。Hornet の主要な制作ツールには、Autodesk Maya、Foundary Nuke、Maxxon Cinema 4D、SideFX Houdini などがあります。また、Blender と Epic Games の Unreal Engine についても研究しています。 「Thinkbox Deadline のスポットイベントプラグインは素晴らしいです。このおかげで、逼迫した時間帯にレンダリング担当者にとって大変なストレスになりかねない多くのタスクが自動化されます」と Poli 氏は語ります。「使用量ベースのライセンス（UBL）も、私たちにとって非常に大きな意味があります。すべてのコンピューティング環境が揃っていますが、サードパーティのリソースにも依存しています。Thinkbox Deadline を使用すると、それらを簡単に導入できます。AWS は究極の追加機能です。」 「業界標準ツールのレンダリングライセンスを個別に購入すると、それぞれ数百ドルかかり、一度に 1 台のマシンでしか使用できませんが、使用量ベースのライセンスでは、同じレートで 1 時間に 100 台のマシンを起動したり、10 台のマシンを 10 時間利用したりできるので、柔軟なソリューションとして有効です。」と Porter 氏は説明しました。 Hornet チームは、ジョブのタグ付けを通じてより多くのクラウド使用状況データを収集するようになったおかげで、レンダリング予算をより正確に見積もり、プロジェクトごとの支出を予測できるようになり、より自信を持って利用できるようになりました。 画像提供: Hornet プロダクションでのAWS利用 クラウドの導入によって、Hornet はクライアントからのフィードバックをもとに、アーティスティックな戦略をたて、技術的な実現を最短の工程で実行できるようになりました。柔軟性の高いスケーラビリティにより、スタジオはより大規模で複雑な作業を引き受けられるようになりました。この能力は、仮想ワークステーションの利用が開始されるとさらに強化されます。アーティストの観点から見ると、クラウドで強化されたワークフローでは、ユーザー体験に影響を与えることなくレスポンスがすぐに返ってくるため、試行錯誤の時間を短縮し制作を加速することができます。 「私たちは主にコマーシャル分野に携わり、制作期間は通常 1 〜 2 か月なので、時間の余裕はありません。AWS は、すぐに立ち上げたり止めたりができるので、当社のようなスタジオにとってゲームチェンジャーとなります。」と Bedard 氏は言います。「ビジネスの観点から見ると、クラウドは非常に強力です。これまでクラウド制作を見てきましたが、他にこのような方法ははありません。」 「クラウドの外では、アーティストが数千フレームのシーケンスをレンダリングし、修正指示を受け取り、新しいバージョンを同じ日にサブミットすることは現実的ではありません。AWS といくつかの技術的な魔法でこれを実現できました。」と Poli 氏は言います。「予算とニーズに基づいてパラメータを調整できるので、レンダリング時間自体はあまり心配されません。アーティストは、限られたリソースの中で作業する代わりに、たくさんのテストをサブミットできます。また、ショットを仕上げるのに十分な計算能力があることを知っているので、より安心できます。」 Bedard 氏はこう締めくくりました。「当社の AWS ワークフローは、1 つの施設内でさまざまなクリエイティブ分野をサポートできるようにするための最善の道筋を示してくれます。特にレンダリングにおける使用量ベースのライセンス（UBL）は、私たちにとって大きなものでした。そして今、次のステップは仮想ワークステーションです。これらの基本的な要素は、パイプラインの成長と進化を続けるのに役立ち、IMT や AWS との関係により、はるかに早く開発面で達成したい場所にたどり着くことができました。」   クラウドベースのクリエイティブワークフローに AWS を使用する方法の 詳細を確認 するか、AWS for Media and Entertainment の担当者に お問い合わせ ください。 著者について Ellen Grogan Ellen Grogan は、AWS のメディアおよびエンターテイメント部門のシニアプロダクトマーケティングマネージャーです。 この記事は Hornet supercharges render capacity with AWS を翻訳したものです。翻訳はVisual Compute ソリューションアーキテクトの森が担当しました。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は、2024 年 11 月 22 日に公開された “ Simplifying developer experience with variables and JSONata in AWS Ste… ”を翻訳したものです。 この投稿は、Uma Ramadoss (サーバーレス担当 Principal Specialist SA) と Dhiraj Mahapatro ( Amazon Bedrock 担当 Principal Specialist SA) によって執筆されたものです。 AWS Step Functions において、変数と JSONata データ変換が導入されました。変数により、開発者は 1 つのステートでデータを割り当て、その後のステップで参照できるようになり、複数の中間ステートを経由してデータを受け渡す必要がなくなったため、ステートのペイロード管理が簡素になります。オープンソースのクエリおよび変換言語である JSONata により、日付と時刻の書式設定や数学的演算などの高度なデータ操作と変換できるようになりました。 この記事では、これらの新機能の強力な機能について詳しく説明します。具体的には、変数を使用したステート間のデータ共有を簡素にする方法と、高度な JSONata 式によるデータ操作の複雑さを軽減する方法について深く掘り下げていきます。 概要 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、HTTP API 統合など、複数のサービスを含む複雑なワークフローを構築するために Step Functions を利用します。 これらのワークフローの中で、さまざまなサービスとやり取りするためのステートを構築し、入力データを渡し、出力としてレスポンスを受け取ります。 Step Functions 自体の機能を超えた、日付、時刻、数値の操作には Lambda 関数を使用できますが、この方法では複雑になるにつれて、ペイロードの制限、データ変換の手間、さらなるステート変更などの課題が生じます。 これは、ソリューション全体のコストに影響を与えます。 この問題に対処するために、変数と JSONata を使用します。 これらの新機能を説明するために、 JSONPath ブログ で取り上げた保険業界の顧客オンボーディングプロセスのユースケースを考えてみましょう。 潜在顧客は、サインアップ時に名前、住所、保険への関心事項などの基本情報を提供します。 この Know-Your-Customer (KYC) プロセスでは、これらの詳細な情報を含むペイロードとともに Step Functions ワークフローが開始されます。 ワークフローでは、顧客の承認または拒否を判断し、通知します。 { "data": { "firstname": "Jane", "lastname": "Doe", "identity": { "email": "jdoe@example.com", "ssn": "123-45-6789" }, "address": { "street": "123 Main St", "city": "Columbus", "state": "OH", "zip": "43219" }, "interests": [ {"category": "home", "type": "own", "yearBuilt": 2004, "estimatedValue": 800000}, {"category": "auto", "type": "car", "yearBuilt": 2012, "estimatedValue": 8000}, {"category": "boat", "type": "snowmobile", "yearBuilt": 2020, "estimatedValue": 15000}, {"category": "auto", "type": "motorcycle", "yearBuilt": 2018, "estimatedValue": 25000}, {"category": "auto", "type": "RV", "yearBuilt": 2015, "estimatedValue": 102000}, {"category": "home", "type": "business", "yearBuilt": 2009, "estimatedValue": 500000} ] } } 従来のワークフロー図は新機能を適用する前のワークフローを示しており、新しいワークフロー図は変数と JSONata を適用して構築されたワークフローを示しています。 このワークフローは、 GitHub リポジトリ の main ブランチ (従来のワークフロー) と jsonata-variables ブランチ (新しいワークフロー) からアクセスできます。 図 1 : 従来のワークフロー 図 2: 新しいワークフロー セットアップ README の手順に従ってこのステートマシンを作成し、テストが完了したら後片付けを行ってください。 変数によるデータ共有の簡素化 変数を使用することで、後続のステートで参照される変数に、ステートの結果を宣言または代入することができます。1 つのステートで、静的データ、ステートの結果、JSONPath や JSONata 式、組み込み関数など、さまざまな値を持つ複数の変数を割り当てることができます。次の図は、ステートマシン内で変数がどのように割り当てられ、使用されるかを示しています。 図 3: 変数の割り当てとスコープ 変数のスコープ Step Functions における変数は、プログラミング言語と同様のスコープを持ちます。内部スコープと外部スコープがあり、それぞれのレベルで変数を定義します。内部スコープの変数は map、parallel、ネストされたワークフロー内で定義され、その特定のスコープ内でのみアクセス可能です。一方、外部スコープの変数はトップレベルで設定されます。一度変数が割り当てられると、実行順序に関係なく、後続のどのステートからでもこれらの変数にアクセスできます。しかし、このブログのリリース時点では、Distributed Map は外部スコープの変数を参照できません。 変数のスコープに関するユーザーガイド では、このようなエッジケースについて詳しく説明されています。 変数の割り当てと使用 変数の値を設定するには、特別なフィールドである Assign を使用します。このブログの後半にある JSONata の部分で、 {%%} の目的について説明しています。 "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" } 変数を使用するには、変数名の前にドル記号 ($) を付けて記述します。 { "TableName": "AccountTable", "Item": { "email": { "S": "{% $inputPayload.data.email %}" }, "firstname": { "S": "{% $inputPayload.data.firstname %}" },.... } JSONata によるデータ操作の簡素化 JSONata は、Json データ用の軽量なクエリおよび変換言語です。JSONata は、Step Functions 内の JSONPath と比較してより多くの機能を提供します。 QueryLanguage を "JSONata" に設定し、JSONata 式に {%%} タグを使用することで、ステートマシン内で JSONata を利用できます。 この設定 はステートマシンのトップレベルまたは各タスクレベルで適用できます。タスクレベルの JSONata を利用することで、JSONata と JSONPath の選択を細かく制御できます。この方法は、一部のステートを JSONata で簡素化し、残りのステートでは JSONPath を使い続けたい複雑なワークフローに有用です。JSONata は、JSONPath や Step Functions の組み込み関数よりも多くの関数と演算子を提供します。 ステートマシンレベルで QueryLanguage 属性を JSONata に設定 すると、JSONPath が無効になり、 InputPath 、 Parameters 、 ResultPath 、 ResultSelector 、 OutputPath の使用が制限されます。代わりに JSONata では Arguments と Output を使用します。 シンプルなステートの最適化 新しいステートマシンで最初に気づく点の 1 つは、以下の比較で示されるように、 Verification プロセスが Lambda 関数を使用していないことです。 図 4: Pass ステートに置き換えられた Lambda 関数 従来のアプローチでは、正規表現を使用してメールアドレスとソーシャルセキュリティナンバー (SSN) を検証する Lambda 関数が使用されていました。 const ssnRegex = /^\d{3}-?\d{2}-?\d{4}$/; const emailRegex = /^[a-zA-Z0-9._-] +@[a-zA-Z0-9.-] + \.[a-zA-Z]{2,4}$/; exports.lambdaHandler = async event => { const { ssn, email } = event ; const approved = ssnRegex.test(ssn) && emailRegex.test(email); return { statusCode: 200, body: JSON.stringify({ approved, message: `identity validation ${approved ? 'passed' : 'failed'}` }) } }; JSONata を使用すると、ステートマシンの Amazon States Language (ASL) を利用して正規表現を直接定義できます。 Pass ステートと JSONata の $match() を使用して、メールアドレスと SSN を検証します。 { "StartAt": "Check Identity", "States": { "Check Identity": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isIdentityValid": "{% $match($states.input.data.identity.email, /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/) and $match($states.input.data.identity.ssn, /^(\d{3}-?\d{2}-?\d{4}|XXX-XX-XXXX)$/) %}" } } } } 同様に、JSONata の高度な文字列関数 $length 、 $trim 、 $each 、 $not を使って、 Pass ステートの中で住所を検証できます。 { "StartAt": "Check Address", "States": { "Check Address": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isAddressValid": "{% $not(null in $each($states.input.data.address, function($v) { $length($trim($v)) > 0 ? $v : null })) %}" } } } } JSONata を使用する場合、 $states は 予約変数 になります。 結果の集計 以前は JSONPath では、 Choice ステート以外で式は使用できませんでした。しかし JSONata ではそのような制限はありません。この例では、 parallel ステートで各サブステップからの本人確認と住所確認の結果を収集しています。それらの結果を boolean 変数 isCustomerValid に集約しています。 "Verification": { "Type": "Parallel", "QueryLanguage": "JSONata", ... "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" }, "Next": "Approve or Deny?" } ここで重要な点は、 $states.result を介した結果へのアクセスと、{%%} 内での AND ブール演算子 の使用です。これにより、この変数を使用する後の Choice ステートがシンプルになります。 JSONata の Operators を使用することで、可能な限りこのような式を柔軟に記述でき、単純なデータ変換するをためのコンピュート層を削減できます。 さらに、 {%%} 内の式が true または false の値を返す限り、柔軟な JSONata 演算子および式を利用することで、 Choice ステートが簡単に使えるようになります。 JSONata 関数としての組み込み関数 Step Functions は、 Step Functions の組み込み関数 と同等の機能を提供するために、JSONata の組み込み関数が提供されています。 DynamoDB の putItem ステップでは、 States.UUID() 組み込み関数と同じ機能を持つ $uuid() の使用方法を示しています。 また、日付と時刻に関する JSONata 固有の関数も利用できます。 以下のステートは、DynamoDB テーブルにアイテムを挿入する前に、 $now() を使用して現在のタイムスタンプを ISO-8601 形式の文字列として取得する例を示しています。 "Add Account": { "Type": "Task", "QueryLanguage": "JSONata", "Resource": "arn:aws:states:::dynamodb:putItem", "Arguments": { "TableName": "AccountTable", "Item": { "PK": { "S": "{% $uuid() %}" }, "email": { "S": "{% $inputPayload.data.identity.email %}" }, "name": { "S": "{% $inputPayload.data.firstname & ' ' & $inputPayload.data.lastname %}" }, "address": { "S": "{% $join($each($inputPayload.data.address, function($v) { $v }), ', ') %}" }, "timestamp": { "S": "{% $now() %}" } } }, "Next": "Interests" } JSONata 式が ASL を利用してステートマシンを定義する際の開発者の負担を軽減するため、 S.$ 内で .$ 表記が不要になったことに注目してください。Step Functions 内で利用可能な 追加の JSONata 関数 についても調べてみてください。 高度な JSONata JSONata の柔軟性は、組み込み関数、 高階関数 のサポート、 関数型プログラミング構文 に由来します。JSONPath では、高度な式 "InputPath": "$..interests[?(@.category ==home) ]" を使用して、配列 interests から住宅保険関連の興味関心をフィルタリングしていました。JSONata は フィルタリング 以上の機能を提供します。たとえば、住宅保険の関心事を探し、カテゴリタイプが home の totalAssetValue を参照し、name や email などの既存のフィールドを JSONata 変数として参照できます。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests[category='home']{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果の JSON は次のようになります。 `{ "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1400000, "home": { "own": 2004, "business": 2009 } }` これらのステップに従うことで、すべての保険に関する関心事とその集約結果を収集し、1 つ上のレベルに進みます。カテゴリフィルターがもう存在しないことに注目してください。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果は次のようになります。 { "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1549000, "home": { "own": 2004, "business": 2009 }, "auto": { "car": 2012, "motorcycle": 2018, "RV": 2015 }, "boat": { "snowmobile": 2020 } } 複雑な式の探索 サンプルデータと JSONata プレイグラウンドを利用 して、要件に合った詳細で複雑な式を見つけてください。以下は JSONata プレイグラウンドの使用例です。 図 5: JSONata プレイグラウンド 考慮事項 変数のサイズ 1 つの変数の最大のサイズは 256KiB です。 この制限は、ステート出力を別々の変数に格納することで、Step Functions のペイロードサイズ制限を回避するのに役立ちます。 個々の変数のサイズは最大 256KiB ですが、単一の Assign フィールド内のすべての変数の合計サイズは 256KiB を超えることはできません。 この制限を回避するには Pass ステートを使用できますが、格納されたすべての変数の合計サイズは、1 回の実行につき 10MiB を超えることはできません。 変数の可視性 変数は、ステート間でデータを共有するのを簡単にする強力な仕組みです。使いやすく柔軟であるため、 ResultPath 、 OutputPath 、JSONata の Output フィールドよりも変数を優先してください。ただし、 Output を使う可能性のある場面が 2 つあります。1 つ目は、外側のスコープから内側のスコープの変数にアクセスできない場合です。この場合、 Output フィールドを使うと、ワークフローの異なるレベル間でデータを共有できます。2 つ目は、ワークフローの最終ステートからレスポンスを送信する際に、 Output フィールドを使う必要がある場合です。以下の JSONPath から JSONata への移行図に、その詳細を示しています。 図 6: JSONPath から JSONata への移行 さらに、特定のステートに割り当てられた変数は、同じステートからはアクセスできません。 "Assign Variables": { "Type": "Pass", "Next": "Reassign Variables", "Assign": { "x": 1, "y": 2 } }, "Reassign Variables": { "Type": "Pass", "Assign": { "x": 5, "y": 10, ## The assignment will fail unless you define x and y in a prior state. ## otherwise, the value of z will be 3 instead of 15. "z": "{% $x+$y %}" }, "Next": "Pass" } ベストプラクティス Step Functions の 検証 API は、ワークフローのセマンティックチェックを提供し、早期の問題発見を可能にします。 ワークフローの安全な更新を確実するために、検証 API と バージョニングとエイリアス を組み合わせて、段階的にデプロイすることをお勧めします。 JSONata の複数行の式は有効な JSON ではありません。したがって、セミコロン “;” で区切られた文字列として 1 行 を使用し、最後の行で式を返すようにしてください。 相互排他 QueryLanguage タイプの使用は相互に排他的です。変数の割り当て時に JSONPath/組み込み関数と JSONata を混在させないでください。たとえば、以下のタスクは失敗します。変数 b は JSONata を使用していますが、 c は組み込み関数を使用しているためです。 "Store Inputs": { "Type": "Pass", "QueryLanguage": "JSONata" "Assign": { "inputs": { "a": 123, "b": "{% $states.input.randomInput %}", "c.$": "States.MathRandom($.start, $.end)" } }, "Next": "Average" } JSONPath で変数を使用するには 、 QueryLanguage を JSONPath に設定するか、タスク定義からこの属性を削除してください。 結論 変数と JSONata により、AWS Step Functions は開発者が Amazon States Language (ASL) で通常のプログラミングパラダイムに合わせた簡潔なコードでエレガントなワークフローを記述できるようになり、開発者体験が向上しました。 開発者は、余分なデータ変換のステップを省略することで、より高速に、クリーンなコードを記述できるようになりました。 これらの機能は、新規および既存のワークフローの両方で使用できるため、JSONPath から JSONata と変数への移行を柔軟に行うことができます。 変数と JSONata は、AWS Step Functions が利用可能なすべての AWS リージョンで追加料金なしでお客様にご利用いただけます。 JSONata と 変数 のユーザーガイド、および jsonata-variables ブランチの サンプルアプリケーション を参照してください。 サーバーレスに関する知識を深めるには、 Serverless Land をご覧ください。

みなさん、明けましておめでとうございます。ソリューションアーキテクトの杉山です。年末年始で 1 週 Skip させていただいたため、2 週まとめて 週刊AWS をお届けします。 年末年始に SNS でバズっていた (?) レシピを使って、自宅で豚骨ラーメンを作りました。まるで外出先のお店でいただけるような味にできて、ちょっとした充実があり、リフレッシュできました。 それでは、主なアップデートについて振り返っていきましょう。 2024年12月23日 – 30日 週の主要なアップデート 12/23(月) Amazon SES Mail Manager でログ機能に対応 Amazon SES の Mail Manager でログ機能を提供開始しました。Mail Manager は組織内でメールを送受信する際に、コンプライアンスを一元的に管理できる機能セットです。例えば、DKIM が Pass になったメールのみ受信する、Trend Micro Virus Scanning と連携しウイルススキャン後にメールを受信する、といったルール管理が可能です。この Mail Manager に CloudWatch Logs、S3、Firehose へログを出力する機能が追加され、詳細なトラブルシュートなどがやりやすくなりました。詳細は こちらの Document を参照ください。 Amazon Lightsail API エンドポイントが IPv6 での接続をサポート Amazon Lightsail API エンドポイントが IPv6 プロトコルをサポートし、IPv6 での接続が可能になりました。従来のエンドポイントは IPv4 専用でしたが、新たに IPv6 接続が可能な dual-stack エンドポイント（例 : lightsail.ap-northeast-1.api.aws）が追加されました。詳細は こちらの Document を参照ください。 AWS CloudTrail が Internet Protocol Version 6 (IPv6) をサポート AWS CloudTrail は CloudTrail API エンドポイントでデュアルスタックを導入し、IPv6 での接続が可能になりました。また、AWS PrivateLink を使用して VPC から CloudTrail API エンドポイントにプライベートにアクセスする場合でも、デュアルスタックが利用可能です。 12/26(火) Amazon EKS が Kubernetes バージョンのサポートステータスなどを取得する API を追加 Amazon EKS で Kubernetes バージョンのサポートステータスなどを取得する API を追加しました。 DescribeClusterVersions API を AWS CLI や SDK などから利用でき、各 Cluster Version のリリース日、Standard Support の期限、Extended Support の期限などを確認できます。また、各バージョンについて、現状 Standard Support なのか、Extended Support なのか、サポート期限切れかどうかを確認できます。従来 AWS Document から確認 できましたが、これをプログラムから取得できるようになった形です。 12/27(水) Amazon EC2 I7ie インスタンスが AWS US East (Ohio)、US West (Oregon) リージョンで利用可能 Amazon EC2 で、I7ie インスタンスがオハイオ、オレゴンリージョンで利用可能になりました。I7ie は高密度ストレージ最適化インスタンスで、大規模なデータセットにアクセスする際に、非常に低いレイテンシーで、高いランダム読み取り/書き込み性能が必要なワークロードに最適です。最大 120 TB のローカル NVMe ストレージを提供し、前世代インスタンスと比較して最大 2 倍の vCPU とメモリを提供します。 1/2(木) AWS Application Discovery Service で IPv6 エンドポイントをサポート AWS Application Discovery Service (ADS) で、IPv6 エンドポイントをサポートしました。Application Discovery Service は、クラウド移行の一環で、移行元のサーバーやアプリケーションを自動的に発見し、それらのシステム構成、使用状況、パフォーマンスデータ、などの詳細な情報を収集します。リソースのサイジング、アプリケーション間の依存関係の把握などに利用できます。IPv6 をサポートするようになり、より幅広いネットワーク環境でご利用しやすくなりました。 1/3(金) AWS WAF コンソールに新しいトップインサイトのダッシュボード機能を追加 AWS WAF のコンソールダッシュボードに、トラフィックに関するインサイトを提供する、より充実したダッシュボード機能を追加しました。CloudWatch Logs に蓄積しているデータを活用し、URI Path、HTTP Method、接続元 IP、User agent などの属性ごとにトラフィックデータを確認できるダッシュボードを提供するものです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに 生成 AI の活用が企業の競争力を左右する時代となっています。しかし、 PwC 社の 生成AIに関する実態調査2024 春 米国との比較 によると、「必要なスキルを持った人材がいない」や「ノウハウがなく、どのように進めれば良いか、進め方がわからない」、「意義やメリット、費用対効果を感じない」といった課題があるなど、多くの企業では、生成 AI の導入にあたって、技術的なハードルや、コスト面での課題を抱えています。 アオラナウ株式会社 （以下、アオラナウ）は、AWS が提供する Generative AI Use Cases JP （通称: GenU）を活用することで、わずか 2 週間という短期間で社内 RAG システムを構築し、ドキュメント検索時間が従来の 1/5 程度に短縮するなど、大幅な業務効率化を実現しました。本ブログは、アオラナウがどのように GenU を活用したか、アオラナウの AI プロダクト開発部の金山 陽希氏から寄稿いただいたものです。 課題：ベンチャー企業における業務効率化の必要性 アオラナウは、従業員数 50 名を超えるベンチャー企業です。技術的な熟練度が高いメンバー（高度技術者）と、未経験メンバーが入り混じっており、プロジェクト運営の際に以下のような課題が生じていました。 高度技術者は、膨大な技術ドキュメントの効率的な探索に時間がかかる 未経験メンバーは、高度技術者への問い合わせに時間を使っており、双方の時間を使われる 未経験メンバーは、忙しい高度技術者への質問を躊躇してしまう これらの課題を解決するために、最新の生成 AI 技術である RAG を利用したいと思いましたが、AI 導入においては、限られた予算内で実施できるよう工夫する必要がありました。 ソリューション：GenU を活用した社内 RAG システムの構築 AWS の AI/ML ソリューションアーキテクトである呉 和仁氏（ @kazuneet ）に相談したところ、AWS が提供する Generative AI Use Cases JP （通称: GenU、以降 GenU と略す）をご紹介いただき、私たちは GenU を基盤とした社内 RAG システムの構築を決定しました。 ＜GenU を採用したポイント＞ すぐにデプロイできる AWS の技術者が構築した質の高いコードがすぐデプロイできる状態で用意されており、自社での開発工数を大幅に削減できることが魅力でした。導入手順も丁寧に解説されており、AWS 未経験者でも容易に導入することが出来そうでしたし、結果として容易でした。 カスタマイズの柔軟性 最新の LLM モデルを設定ファイルの変更のみで導入できたりと、カスタマイズが柔軟にできるように設計されておりました。また、GenU の利用状況のモニタリングや、ユーザーからのハルシネーション報告などをもとにデータを修正するシステムを簡単に連結することが出来ました。 コスト最適化 サーバーレスアーキテクチャが最大限活用されており、ほぼ利用分のみの安価な運用コストも大変魅力的でした。ベクトル DBに Pinecone などのサードパーティー製品を利用するためのガイドもあり、さらなるコスト最適化の検討が容易なように設計されていました。 アーキテクチャ システムは以下のように、GenU をベースとして、弊社独自に GenU を管理するためのシステムを構築しています。 ServiceNow の技術ドキュメント（日本語/英語）60,000 ページと、600,000 件の QA データを元にした社内 RAG システムを、2 週間で構築することができました。 アオラナウでの GenU 構成 ユーザーは、GenU の画面から、RAG チャットを利用して技術的な質問をすることが出来ます。 アオラナウでの GenU 利用イメージ GenU管理システムでは、ユーザーの利用状況のモニタリングや、ユーザーからのハルシネーション報告を元にデータの修正作業を行えるようにしています。 アオラナウでの GenU ダッシュボード GenU の導入効果 GenU を導入することで、以下のような効果を月々数万円程度のコストで実現することが出来ました。 高度技術者は、ドキュメント検索時間が従来の 1/5 程度に短縮 未経験者の高度技術者への問い合わせ件数が削減 未経験者はまず GenU で調査した後、高度技術者に深い内容を聞くという質問の質の向上 結果として、プロジェクトを効率的に進めることができるようになったと体感しています。 今後、プロジェクトの成果物まで生成 AI が作成サポート出来るか、検証していく予定です。 まとめ GenU の活用により、私たちは短期間かつ低コストで高度な RAG システムを構築することができました。特筆すべきは、AWS の MLSA である呉氏による手厚いサポートです。技術的な課題に直面した際も、迅速な解決策の提案をいただき、スムーズな導入を実現できました。 ベンチャー企業にとって、効率的なリソース活用は重要な課題です。GenU は、その解決策として非常に有効なツールとなりました。今後も、AWS の提供するサービスを活用しながら、さらなる業務改善を進めていきたいと考えています。 執筆者について アオラナウ株式会社の AI プロダクト開発チームです。 金山 陽希 フルスタックエンジニア。ソリューションの設計、実装を担当しています。 新しいAI技術と前職でのWebアプリケーション開発の経験を活かし、なにかを実現することを楽しんでいます。 近頃足回りを囲むパネルヒーターを手に入れたので、今冬はこれだけで乗り切ろうかと画策中。 宍戸 凌雅 オペレーションエンジニア。本プロジェクトで運用設計を主に担当しています。 前職で培った経験を活かし、効率的で効果的な運用フローの構築に努めています。 生成AIを仕事やプライベートで積極的に活用しており、その可能性を追求することで世の中に貢献したいと考えています。 趣味は散歩や筋トレで、体力づくりを楽しみながらリフレッシュしています。 鄭 巽 AIエンジニア兼開発リードとして、チーム管理作業と実装作業を担当しています。 前職で培った統計知識と開発経験を活かし、適切な解決策を考えて事業価値を創出しています。 画像認識や生成モデルの分野に興味を持ち、実務の中で実践できることを楽しんでいます。 人と技術の橋渡し役として、チームのモチベーションを高めつつ、成果を引き出せるよう努めています。 保田 駿介 ServiceNowコンサルタント。お客様とのPoC実施、プリセールス活動を実施。生成AIを含むAI/ML技術の支援を担当しています。 様々な業界のServiceNowやSalesforceの導入を支援していた経験を生かし、ビジネス上の課題や業務課題解決するためのAI/MLソリューションの提案や導入支援に努めています。 BizDevの役割ではありますが、技術面もキャッチアップを怠らず進めていこうと思ってます。 李 溶基 ServiceNowアーキテクト。AWSとServiceNowの連携部分の開発を担当。REST API開発経験を生かし、ビジネス上の課題を解決するためのAI/MLソリューションの提案や導入支援に努めています。 プライベートではランニングやジム通いを通じてストレスを発散しています 伊藤 芳幸 エンジニア。前職の経験を活かし、AI/ML技術とServiceNowを融合させ、企業の生産性向上の新しい可能性を模索しています。 新しい技術に触れることは楽しみの一つで、積極的に手を動かしています。プライベートでは育児に忙しい日々を送っていますが、フットサルやジム通いを通じてストレスを発散しています。 参考情報 Generative AI Use Cases JP Amazon Bedrock ユーザーガイド AWS Lambda 開発者ガイド Meta knowledge for retrieval augmented large language models (amazon science)

今日の データ主導の世界 では、企業は データレイク や ウェアハウス にまたがる 膨大な量の情報 を処理および分析する効率的な方法を常に模索しています。 Amazon SageMaker Lakehouse を使用すると、 Amazon Simple Storage Service ( Amazon S3 ) 上のデータレイクと Amazon Redshift データウェアハウスにまたがるすべてのデータを統合することができ、強力なアナリティクスと AI / ML アプリケーションを一元化されたデータで構築できます。SageMaker Lakehouse は、データを動かさずに Apache Iceberg と互換性のあるすべてのツールとエンジンでクエリを実行できる柔軟性を提供します。これは、SageMaker Lakehouse の機能を使用したい オープンソースの Apache Spark ユーザーにとって、エキサイティングな可能性を開きます。さらに、 SageMaker Lakehouse では、すべてのアナリティクスおよび ML ツールやエンジンに適用されるきめ細かい権限を定義することで、データを保護することができます。 この投稿では、オープンソースの Apache Spark のパワーを利用し、 AWS Glue Iceberg REST Catalog で動作するようサードパーティのエンジンを設定する方法を探ります。 この投稿には、 AWS Lake Formation が一時的なクレデンシャルを提供する機能を使用してメタデータと実データへのアクセスを管理し、 Amazon S3 テーブルに対してデータを読み取り/書き込みする操作を実行する方法の詳細が含まれます。 ソリューション概要 この投稿では、お客様が Data Catalog を使用して組織内の構造化および半構造化データセットのテクニカルメタデータを一元管理し、データチームが Apache Spark を使用してデータ処理を行えるようにしたいと考えています。 お客様は、 AWS Glue データベースを作成します。そして、Lake Formation の権限コントロールを使用してAmazon S3 上の Iceberg データを読み書きするために、Iceberg Rest API を使用して Glue Data Catalog と対話できるよう Apache Spark を設定します。 まず、 Apache Spark を使用して ETL ( 抽出・変換・ロード ) スクリプトを実行することから始めます。 Amazon S3 上に Iceberg テーブルを作成し、 Glue Iceberg REST Catalog を使用してそのテーブルにアクセスします。 ETL スクリプトは Iceberg テーブルにデータを追加し、 その後 Spark SQL を使用してデータを読み取ります。 この投稿では、他のデータチームが Amazon Athena を使用して、このデータをクエリする方法についても紹介します。 前提条件 Data Catalog を持つアカウントの、 Lake Formation データレイク管理者である AWS Identity and Access Management (IAM) ロール にアクセスできる必要があります。 手順については、 データレイク管理者を作成する を参照してください。 Python バージョン 3.7 以降がインストールされていることを確認します。 pip3 のバージョンが 22.2.2 以上であることを確認してください。 最新の AWS Command Line Interface ( AWS CLI ) をインストールまたは更新します。 手順については、 最新バージョンの AWS CLI のインストールまたはアップデート を参照してください。 AWS CLI を使用して aws configure を実行し、 AWS アカウントを指定します。 お客様の Iceberg テーブルを格納する S3 バケットを作成 します。 今回は、 us-east-2 の AWS リージョンを使用し、バケット名を ossblog-customer-datalake とします。 AWS Glue Iceberg REST Catalog エンドポイントを使用したデータアクセスに使用する、 OSS Spark 用の IAM ロールを作成します。作成した IAM ロールが Data engineer permissions で定義されている AWS Glue と Lake Formation のポリシーを持っていることを確認してください。 この投稿では、 spark_role という名前の IAM ロールを使用します。 Lake Formation のサードパーティからのアクセス権限を有効にする このセクションでは、 Lake Formation に S3 バケットを登録 します。 このステップにより、Lake Formation は Amazon S3 に保存されたメタデータとデータの一元的な権限管理システムとして機能し、データレイク環境においてより効率的でセキュアなデータガバナンスを可能にします。 ロケーションの登録に使用するロールの要件 に従って、ユーザー定義の IAM ロールを作成します。 この投稿では、IAMロール : LFRegisterRole を使用します。 以下のコマンドを実行し、 IAM ロール LFRegisterRole を使用して、S3バケット ossblog-customer-datalake を登録します。 aws lakeformation register-resource \ --resource-arn ' < S3 bucket ARN for amzn-s3-demo-bucket> ' \ --role-arn ' < IAM Role ARN for LFRegisterRole > ' \ --region <aws_region> または、Lake Formation の AWS マネジメントコンソールを使用することもできます。 Lake Formation コンソールに移動し、ナビゲーションペインから Administration を選択し、次に Data lake locations を選択して、以下の値を入力します。 Amazon S3 path では、 s3://ossblog-customer-datalake を選択します。 IAM role では、 LFRegisterRole を選択します。 Permission mode では、 Lake Formation を選択します。 Register location を選択します。 Lake Formationで、外部エンジンがデータにアクセスできるように full table access を有効にします。 管理者ユーザーとしてサインインし、ナビゲーション ペインで Administration を選択します。 Application integration settings を選択し、 Allow external engines to access data in Amazon S3 locations with full table access を選択します。 Save を選択します。 OSS Spark ロールのリソースアクセスを設定 Lake Formation コンソールに移動し、ナビゲーションペインで Databases を選択して、デフォルトカタログに ossblogdb という AWS Glue データベース を作成します。 データベースを選択し、 Edit を選択して Use only IAM access control for new tables in this database のチェックボックスをオフにします。 OSS Spark ロールにリソース権限を付与 OSS Spark が ossblogdb データベースの上でデータセットを作成し、データを投入できるようにするには、前提条件のステップ 4 で作成した Apache Spark インスタンスの IAM ロール（ spark_role ） を使用します。 Apache Spark はこのロールを使用して、Iceberg テーブルを作成し、レコードを追加し、読み込みます。 この機能を有効にするには、 spark_role にフルテーブルアクセスを付与し、テーブルデータを保存できる S3 バケットにデータロケーション権限を付与します。 spark_role にテーブル作成権限を付与 データレイク管理者としてサインインし、AWS CLIで以下のコマンドを実行します。 aws lakeformation grant-permissions \ --principal '{"DataLakePrincipalIdentifier":"arn:aws:iam:: <aws_account_id> :role/ <iam_role_name> "}' \ --permissions '["CREATE_TABLE","DESCRIBE"]'\ --resource '{"Database":{"CatalogId":" <aws_account_id> ","Name":"ossblogdb"}}' \ --region <aws_region> またはコンソール上で以下を実施します Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクション の IAM users and roles で、 spark_role を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Database permissions で、 DESCRIBE と CREATE TABLE を選択します。 Grant を選択します。 spark_role にデータロケーション許可を付与 データレイク管理者としてサインインし、AWS CLI を使用して以下のコマンドを実行します。 aws lakeformation grant-permissions --principal '{"DataLakePrincipalIdentifier":" <Principal> "}' --permissions DATA_LOCATION_ACCESS --resource '{"DataLocation":{"CatalogId":" <Catalog ID> ","ResourceArn":" <S3 bucket ARN> "}}' --region <aws_region> またはコンソール上で以下を実施します。 Lake Formation コンソールのナビゲーションペインで、 Data Locations を選択し、 Grant を選択します。 IAM users and roles では、 spark_role を選択します。 Storage locations では、 バケット名 を選択します。 Grant を選択します。 AWS Glue Iceberg REST catalog エンドポイントを使用する Spark スクリプトのセットアップ 以下の内容で、 oss_spark_customer_etl.py という名前のファイルをあなたの環境に作成します。 import sys import os import time from pyspark.sql import SparkSession #Replace <aws_region> with AWS region name. #Replace <aws_account_id> with AWS account ID. spark = SparkSession.builder.appName('osspark') \ .config('spark.jars.packages', 'org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160') \ .config('spark.sql.extensions', 'org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions') \ .config('spark.sql.defaultCatalog', 'spark_catalog') \ .config('spark.sql.catalog.spark_catalog', 'org.apache.iceberg.spark.SparkCatalog') \ .config('spark.sql.catalog.spark_catalog.type', 'rest') \ .config('spark.sql.catalog.spark_catalog.uri','https://glue. <aws_region> .amazonaws.com/iceberg') \ .config('spark.sql.catalog.spark_catalog.warehouse',' <aws_account_id> ') \ .config('spark.sql.catalog.spark_catalog.rest.sigv4-enabled','true') \ .config('spark.sql.catalog.spark_catalog.rest.signing-name','glue') \ .config('spark.sql.catalog.spark_catalog.rest.signing-region', <aws_region> ) \ .config('spark.sql.catalog.spark_catalog.io-impl','org.apache.iceberg.aws.s3.S3FileIO') \ .config('spark.hadoop.fs.s3a.aws.credentials.provider','org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider') \ .config('spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled','false') \ .getOrCreate() spark.sql("use ossblogdb").show() spark.sql("""CREATE TABLE ossblogdb.customer (name string) USING iceberg location 's3://<3_bucket_name>/customer'""") time.sleep(120) spark.sql("insert into ossblogdb.customer values('Alice') ").show() spark.sql("select * from ossblogdb.customer").show() Pyspark をローカルで起動し、 Amazon S3 上の Iceberg テーブルへの読み書き を検証する pip install pyspark を実行します。 スクリプトをローカルに保存し、環境変数（ AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , AWS_SESSION_TOKEN ）に spark_role の一時的な認証情報を設定します。 python /path/to/oss_spark_customer_etl.py を実行します。 Athena を使用して Iceberg テーブルのデータを表示することもできます。 他のデータチームがコンテンツを閲覧できるようにするには、Lake Formation コンソールを使用してデータチームの IAM ロールに読み取りアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクションの IAM users and roles で、 <iam_role> を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Tables では customer を選択します。 DESCRIBE と SELECT を テーブル権限 に選択します。 Grant を選択します。 IAM ロールでサインインし、以下のコマンドを実行します。 SELECT * FROM "ossblogdb"."customer" limit 10; クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。 Data Catalog で作成したリソース（データベース/テーブル）を削除します。 S3バケットを 空にして 、 削除します 。 結論 この投稿では、Amazon S3 の Iceberg テーブルにアクセスするための Apache Spark と AWS Glue Iceberg Rest Catalog のシームレスな統合について説明し、Iceberg REST API を使用して読み取りと書き込みの操作を効果的に実行する方法を示しました。 このソリューションの素晴らしいところは、その柔軟性にあります。データセンターのベアメタルサーバーで Spark を実行している場合でも、 Kubernetes クラスタで実行している場合でも、その他の環境であっても、このアーキテクチャはニーズに合わせて適応させることができます。 著者について Raj Ramasubbu は、Amazon Web Servicesのビッグデータおよびアナリティクス、AI / MLに特化したシニアアナリティクススペシャリストソリューションアーキテクトです。 AWS 上で拡張性、パフォーマンス、安全性の高いクラウドベースのソリューションを設計、構築するお客様を支援しています。 AWS 入社以前 20 年以上にわたり、データエンジニアリング、ビッグデータ分析、ビジネスインテリジェンス、データサイエンスソリューションの構築における技術的専門知識とリーダーシップを発揮してきました。 彼は、ヘルスケア、医療機器、ライフサイエンス、小売、資産管理、自動車保険、住宅用不動産投資信託、農業、タイトル保険、サプライチェーン、文書管理、不動産など、さまざまな業種のお客様を支援しました。 Srividya Parthasarathy は、 AWS Lake Formation チームのシニアビッグデータアーキテクトです。 プロダクトチームやお客様と協力して、分析データプラットフォーム向けの堅牢な機能とソリューションを構築しています。彼女は、データメッシュソリューションを構築し、コミュニティと共有することを楽しんでいます。 Pratik Das は、 AWS Lake Formation のシニアプロダクトマネージャーです。 データに関するあらゆることに情熱を持っており、お客様の要件を理解し、楽しいエクスペリエンスを構築するためにお客様と協力しています。 彼は、データドリブンソリューションと機械学習システムの構築経験があります。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

この記事は Amazon EKS now supports Amazon Application Recovery Controller (記事公開日: 2024 年 11 月 8 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) が Amazon Application Recovery Controller ( ARC ) のサポートを開始しました。ARC は AWS リージョン またはアベイラビリティゾーン (AZ) の障害に対する準備と復旧を可能にする AWS サービスです。 ARC には、ゾーンシフトとゾーンオートシフトを含む マルチ AZ リカバリ と、ルーティングコントロールと準備状況チェックを含む マルチリージョンリカバリ の 2 つの機能があります。今回のリリースにより、以前は Application Load Balancer (ALB) と Network Load Balancer (NLB) でのみ利用可能だったゾーンシフトとゾーンオートシフトが Amazon EKS をサポートしました。 ARC のゾーンシフトとゾーンオートシフトは、障害のある AZ から他の正常な AZ に ingress トラフィックをシフトすることで、サポートされている AWS リソースのマルチ AZ リカバリを実現します。シフトが終了すると、ARC は ingress トラフィックを再び受信できるように以前に影響を受けた AZ を戻します。 Amazon EKS コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、または eksctl を使用して、EKS クラスターのゾーンシフトを有効にできます。有効にすると、ARC コンソール、AWS CLI、またはゾーンシフトとゾーンオートシフト API を使用して、EKS クラスターのゾーンシフトを開始したり、ゾーンオートシフトを有効にしたりできます。 EKS クラスターでゾーンシフトをトリガーするには、まず AZ を選択し、次に EKS クラスター (バージョン 1.28 以降) を選択し、ゾーンシフトを有効にする有効期限を指定します。すると、ARC はゾーンシフトを開始し、選択した AZ からトラフィックを切り離します。ARC は、有効期限が切れるか、ユーザーがキャンセルした場合にゾーンシフトを終了します。ゾーンシフトが終了すると、トラフィックは EKS クラスターに接続されているすべての正常な AZ に戻ります。 EKS クラスターのゾーンオートシフトを有効にすると、AZ が異常であることを ARC が検出したときに、AWS がユーザーに代わってトラフィックを切り離すことを許可することになります。ARC は内部テレメトリを使用して、AWS ネットワーク、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Elastic Load Balancing (ELB) サービスなど、さまざまなソースからの重要なヘルスメトリクスを監視しています。ARC は、影響を受けた AZ が再び正常状態になったことがテレメトリで示されると、ゾーンオートシフトを終了します。これにより、EKS クラスターに接続されているすべての正常な AZ にトラフィックが返されます。 ARC ゾーンシフトとゾーンオートシフトを利用する理由 AWS グローバルクラウドインフラストラクチャ は、各 AWS リージョンが完全に分離された複数の AZ で構成されているため、耐障害性とレジリエンスを提供します。このマルチ AZ アーキテクチャを活用することは、リージョンに高可用性アプリケーションを実装するために不可欠です。Amazon EKS では、複数の AZ にデプロイすることで可用性の高いアプリケーションを迅速に開発できますが、スケーラブルでパフォーマンスが高く、信頼性の高い方法で AZ の障害に対処するには、構築と保守に多大な労力を要するカスタムソリューションを実装する必要があります。 もう 1 つの課題は、シミュレーションが難しいことが多い AZ 障害シナリオのテストです。テストが不十分だと、環境内の AZ で異常が生じたとき、予期せぬワークロードの動作に陥る可能性があります。 ARC ゾーンシフトまたはゾーンオートシフトを用いると、障害のある AZ で実行されているクラスターワーカーノードと Pod を一時的に隔離し、クラスター内のネットワークトラフィックをそれらから自動的に切り離して、ワークロードの耐障害性と可用性を向上させることができます。 さらに、ゾーンシフトとゾーンオートシフト機能を使用することで、AZ 障害の計画と対応に伴うチームのオペレーションオーバーヘッドを削減できます。 仕組み EKS クラスターを ARC リソースとして登録すると、ARC を使用してクラスターのゾーンシフトをトリガーしたり、もしくはクラスターのゾーンオートシフトを有効にしたりできます。ARC がゾーンシフトを実行すると、クラスターは次のような変更を受けます。 Kubernetes スケジューラ が異常な AZ のノードに新しい Pod をスケジュールできないように、影響を受けた AZ のノードは cordon (スケジュール対象外としてマーク) されます。 マネージドノードグループ (MNG) を使用している場合、 アベイラビリティゾーンの再調整 は一時停止され、 Auto Scaling グループ (ASG) が更新されて、新しい Amazon EKS のデータプレーンノードが正常な AZ でのみ起動されるようになります。Karpenter と Kubernetes の Cluster Autoscaler は、ARC ゾーンシフトとゾーンオートシフトをネイティブでサポートしていません。正常に動作している AZ のみに新しいノードをプロビジョニングするよう自動スケーリングツールを再構成する必要があります。新しいノードの起動に特定の AZ のみを使用するように Karpenter と Cluster Autoscaler を設定する方法については、 Amazon EKS ベストプラクティスガイド を参照してください。 異常な AZ のノードは終了されません。したがって、影響を受けた AZ の Pod は削除されません。これは、ゾーンシフトの期限が切れたりキャンセルされたときに、トラフィックがフルキャパシティーの状態の AZ に安全に戻るようにするためです。 EndpointSlice controller は、障害のある AZ 内のPod の Endpoint を検出し、それらを関連するEndpointSlice リソースから削除します。これにより、ネットワークトラフィックが正常な AZ の Pod の Endpoint のみを対象とすることが保証されます。Endpoint slice controller は、ゾーンシフトがキャンセルまたは期限切れになると、復元された AZ の Endpoint を含むように Endpoint slice を更新します。 次の図は、Amazon EKS 環境における AZ の異常が生じた場合の east-to-west (クラスター内部) のトラフィックフローを示しています。このようなシナリオでは、ネットワークパケットのドロップやネットワーク遅延が発生する可能性があります。 次の図は、障害のある AZ からトラフィックを切り離した場合の Amazon EKS 環境を示しています。 ゾーンシフトとゾーンオートシフトのための EKS クラスターとワークロードの準備 Amazon EKS でゾーンシフトとゾーンオートシフトが正常に動作するようにするには、事前に AZ 障害に強いクラスター環境を準備する必要があります。以下は、 EKS クラスターに実装する必要がある重要なステップのリストです。これらのステップについては、 Amazon EKS のドキュメント で詳しく説明されています。 クラスター内のワーカーノードを複数の AZ に分散します。 単一の AZ の削除に耐えられるだけの十分なコンピューティングキャパシティをプロビジョニングしてください。AZ 障害に耐えられるアプリケーションの構築方法の詳細については、 静的安定性 に関する AWS のドキュメントを参照してください。 すべての AZ で、Pod を事前にスケーリングしてください。これらの Pod には、アプリケーション Pod と、CoreDNS、Cluster Autoscaler、 AWS Load Balancer Controller などのコントローラー Pod が含まれます。これを実現する方法の詳細については、 Amazon EKS のドキュメント を参照してください。 Pod レプリカを複数の AZ をまたいで分散させて、単一の AZ を切り離しても十分な容量が残るようにします。これを実現するには、Topology spread constraints が役立ちます。 クラスターで実行されているコントローラーやその他のアプリケーションの高可用性 (HA) をサポートするためにリーダーの選出が必要な場合は、ポッドの数が奇数であるか、ポッドが 2 つ以上であるなどの基準が、AZ 障害イベント中および発生後に一貫して満たされていることを確認してください。 ロードバランサーを使用して外部トラフィックを Kubernetes の Service にルーティングする場合は、ALB と NLB のみを使用することをお勧めします。 AWS Load Balancer Controller を使用してロードバランサーを管理することもお勧めします。AWS Load Balancer Controller はインスタンスと IP トラフィックモードをサポートしていますが、そのうちの IP モードが推奨されます。インスタンスと IP モードの詳細については、 AWS Load Balancer Controller のドキュメント を参照してください。 Amazon EKS のゾーンシフトによってアプリケーションとクラスター環境が正常に回復するには、前述のステップが不可欠です。さらに、AZ 障害を効果的に管理するには、以下のベストプラクティスをお勧めします。 Topology Aware Routing などの Kubernetes 機能を使用するか、 サービスメッシュ と統合することで、Pod 間の通信を同じ AZ 内に限定します。 同じ AZ 内に、相互に依存するアプリケーションとサービスを配置します。これは Pod Affinity rule で実現できます。 マルチ AZ オブザーバビリティ を実装します。 アプリケーションでは、データベース、サービスなどの外部依存関係に対するタイムアウト値を適切に設定し、再試行を実装してください。障害を正常に処理するには、エクスポネンシャルバックオフパターンを備えたサーキットブレーカーを実装してください。 ゾーンシフトとゾーンオートシフトをサポートするようにクラスターとワークロードを準備する方法、およびゾーンシフトとゾーンオートシフトに関するその他のベストプラクティスの詳細については、 Amazon EKS ドキュメント を参照してください。 さらに、ワークロードが AZ 障害を処理できることを定期的にテストして検証することを強くお勧めします。ゾーンシフトを手動でトリガーするか、ゾーンオートシフトを有効にして、クラスター環境の AZ を 1 つ減らしてワークロードが期待どおりに機能することを確認することで、AZ 障害をテストできます。 始めてみよう ARC ゾーンシフト機能の説明に使用するサンプルアプリケーションを準備しました。このウォークスルーでは、既存の EKS クラスターを使用するか、 新しいクラスターを作成 できます。クラスターとそのクラスターに設定されているノードグループは、3 つの AZ にまたがり、各 AZ に少なくとも 1 つのノードが必要です。 1. サンプルアプリケーションをデプロイする a. まず、EKS クラスターにサンプルアプリケーションをデプロイします。Kubernetes Secret を作成するときは、必ず有効なユーザー名とパスワードを指定してください。この Secret は、MySQL データベースとそれに接続するアプリケーションの両方で使用されます。 kubectl create secret generic catalog-db --from-literal=username=<<有効なユーザー名で置換>> --from-literal=password=<<有効なパスワードで置換>> cat << EOF > catalog_deploy.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: catalog data: DB_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_READ_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_NAME: catalog --- apiVersion: v1 kind: Service metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: clusterIP: None ports: - port: 3306 targetPort: mysql protocol: TCP name: mysql selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql --- apiVersion: v1 kind: ServiceAccount metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm --- apiVersion: v1 kind: Service metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: type: ClusterIP ports: - port: 80 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample --- apiVersion: apps/v1 kind: Deployment metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: replicas: 3 strategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" prometheus.io/scrape: "true" labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog serviceAccountName: catalog securityContext: fsGroup: 1000 containers: - name: catalog env: - name: DB_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password envFrom: - configMapRef: name: catalog securityContext: capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 image: public.ecr.aws/aws-containers/retail-store-sample-catalog:0.8.1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 8080 protocol: TCP livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 3 resources: limits: memory: 256Mi requests: cpu: 128m memory: 256Mi volumeMounts: - mountPath: /tmp name: tmp-volume volumes: - name: tmp-volume emptyDir: medium: Memory --- apiVersion: apps/v1 kind: StatefulSet metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql app.kubernetes.io/managed-by: Helm spec: replicas: 3 serviceName: catalog-mysql selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql template: metadata: labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/component: mysql containers: - name: mysql image: public.ecr.aws/docker/library/mysql:8.0 imagePullPolicy: IfNotPresent env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password - name: MYSQL_DATABASE value: catalog - name: MYSQL_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password volumeMounts: - name: data mountPath: /var/lib/mysql ports: - name: mysql containerPort: 3306 protocol: TCP volumes: - name: data emptyDir: {} --- EOF kubectl apply -f catalog_deploy.yaml b. Kubernetes マニフェストファイルをクラスターに適用すると、それぞれ catalog と catalog-mysql という名前の 2 つのアプリケーションが作成され、 catalog-mysql は MySQL データベースになります。次のステップに進む前に、Pod が実行状態であることを確認します (これには数分かかる場合があります)。 2. クラスターのゾーンシフトを有効にする a. Amazon EKS コンソールを開いてクラスターを選択し、次の図に示すように、 概要 (Overview) の ゾーンシフト (Zonal Shift) セクションに移動します。 b. 管理 (Manage) を選択し、 有効化 (Enabled) を選択し、変更を保存します。 3. アプリケーションを検証する a) default Namespace で利用可能な Service を一覧表示します。 kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE catalog LoadBalancer XX.XXX.XXX.XXX <pending> 80:31932/TCP 41m catalog-mysql ClusterIP None <none> 3306/TCP 41m b) catalog Service への kubectl port-forward をバックグラウンドモードで実行します。プロセスのプロセス ID を書き留めておきます。 kubectl port-forward svc/catalog 8090:80 > /dev/null & [1] 42306 c) curl を使用して catalog Service を呼び出すと、以下に示すように、いくつかのアイテム ID を返すことを確認します。 curl -s localhost:8090/catalogue | jq -r '.[0,1].id' 510a0d7e-8e83-4193-b483-e27e09ddc34d 6d62d909-f957-430e-8689-b5129c0bb75e # port-forward プロセスを終了 (42306) kill -9 <<kubectl port-forward プロセスのプロセスID>> 4. クラスター・トポロジーを理解する アプリケーションが正常に動作していることを確認できたので、ゾーンシフトを実行する準備が整いました。ただし、ゾーンシフトをトリガーする前に、クラスターのトポロジーを理解する必要があります。これには、Pod が稼働している AZ を特定することが含まれます。 a. リージョンの AZ ID を一覧表示します。この例では、リージョンは us-west-2 なので、us-west-2 の AZ ID を確認できます。 aws ec2 describe-availability-zones --query 'AvailabilityZones[*].[ZoneName, ZoneId]' --output text us-west-2a usw2-az2 us-west-2b usw2-az1 us-west-2c usw2-az3 us-west-2d usw2-az4 b. 次のコマンドを使用して、クラスター内の各ノードとそれが動作している AZ を特定する必要があります。次のコマンドを入力すると、ノード名とノードが実行されている AZ のリストが出力されるはずです。この例では、3 つのノードが 3 つの AZ (us-west-2b、us-west-2b、us-west-2c) に分散しています。 kubectl get nodes -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.metadata.labels.topology\.kubernetes\.io/zone}"{"\n"}{end}' | sort -k 1 > nodes-info.txt cat nodes-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2a" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2b" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2c" c. 次のコマンドを使用して、各 Pod が現在実行されているノードと AZ を特定する必要があります。コマンドを入力すると、Pod 名、AZ、および Pod が実行されているノードを示す出力が生成されます。この場合、3 つの AZ の 3 つのノードに分散されたカタログアプリケーションポッドがあります。 kubectl get pods -l "app.kubernetes.io/component"=service -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.spec.nodeName}"{"\n"}{end}' | sort -k 2 > pods-info.txt join -1 1 -2 2 nodes-info.txt pods-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2b" "catalog-74957c74ff-xxxxx" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2c" "catalog-74957c74ff-yyyyy" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2a" "catalog-74957c74ff-zzzzz" 5. ゾーンシフトをトリガーする これで、クラスター・トポロジーを十分に理解できたはずです。次に、ゾーンシフトをトリガーしてトラフィックを AZ から切り離し、ゾーンシフト機能をテストします。 a. 次の図に示すように、ARC コンソールを開き、 ゾーンレベルの移行 (Zonal Shift) を選択します。 b. 次の図に示すように、ゾーンシフトを開始するために、トラフィックを切り離す AZ (us-west-2b)、ゾーンシフトを実行する EKS クラスタ、有効期限 (10 分) を選択して、そして 開始 (Start) を選択します。 ゾーンシフトは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 c. アプリケーションの Endpoint へのトラフィックを生成してアプリケーションを検証し、トラフィックを切り離した AZ で実行されている Pod に対して呼び出しが行われていないことを確認します。そのためには、まず Kubernetes Job を実行してアプリケーションへのトラフィックを生成し、次にトラフィックを処理する Pod とそれらが属する AZ をログから特定します。次のコマンドを入力すると、catalog Service へのトラフィックが 2 つの Pod に分散されていることがわかります。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 5 catalog-78679df9c4-xxxx 6 catalog-78679df9c4-zzzz d. Pod の位置を確認すると、どの Pod も AZ us-west-2b (ゾーンシフトによってトラフィックが迂回された AZ) で稼働していないことがわかります。 join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 5 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 6 e. 先に進む前に、トラフィックを生成するために作成した Kubernetes Job を削除します。 kubectl delete job curl-job 6. ゾーンシフトをキャンセルする a. 次の図に示すように、以前に作成したゾーンシフトを選択し、 ゾーンシフトをキャンセル (Cancel zonal shift) を選択して、ゾーンシフトのキャンセルをテストします。 ゾーンシフトのキャンセルは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 b. アプリケーションへのトラフィックを生成し、AZ で動作している Pod がトラフィックを受信していることを確認できます。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 9 catalog-78679df9c4-xxxx 7 catalog-78679df9c4-yyyy 5 catalog-78679df9c4-zzzz join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 9 catalog-74957c74ff-yyyy ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal us-west-2b 7 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 5 # kubernetes job を削除する kubectl delete job curl-job 7. クラスターのゾーンオートシフトを設定します a. ゾーンオートシフトを設定する前に、ARC が練習実行が成功のうちに完了したかどうかを検査するために用いる Amazon CloudWatch アラームを設定する必要があります。ARC ゾーンオートシフトの練習実行の詳細については、この ドキュメント を参照してください。 b. 次の図に示すように、ARC コンソールを開き、 ゾーンオートシフトを設定 (Configure zonal autoshift) を選択します。 c. ゾーンオートシフトの設定するリソース (Resource to configure) として EKS クラスターを選択し、ゾーンオートシフトのステータス (Zonal autoshift status) で 有効化 (Enable) を選択し、CloudWatch アラーム ARN を入力して 作成 (Create) を選択します。次の図に示すように、コンソールのオプションセクションはそのままにしておきます。 d. ARCは、練習実行の一環として、週に1回、ゾーンオートシフトを実施します。Amazon EventBridge との統合を用いて、ゾーンオートシフトと練習実行の通知を受け取ることができます。練習実行中に、ゾーンシフトの検証に使用したのと同じ検証手順をゾーンオートシフトに適用できます。 ゾーンシフトとオートシフトにより、AZ 障害からの迅速な回復と Amazon EKS ワークロードの信頼性の向上が可能になります。AZ 障害に対して真に回復力を発揮するには、ワークロードがゾーンシフトやゾーンオートシフト機能を使用するだけでなく、「クラスターとワークロードの準備」セクションで概説されているプラクティスを遵守して AZ 障害からの回復も行う必要があります。 後片付け 今後のコストを避けるため、この演習用に作成された EKS クラスターなどのリソースをすべて削除してください。次のコマンドは、ゾーンシフトをテストするために以前にインストールしたアプリケーションを削除します。 kubectl delete -f catalog_deploy.yaml kubectl detelet secret catalog-db rm nodes-info.txt pods-info.txt pod-logs.txt pods-nodes-az.txt 価格と提供リージョン Amazon EKS の ARC ゾーンシフトおよびゾーンオートシフト機能の対応は、中国と GovCloud リージョンを除くすべての AWS リージョンで利用できます。EKS クラスターでゾーンシフトを有効にしてゾーンシフトをトリガーしても、追加のコストは発生しません。ただし、Pod やクラスターノードの事前スケーリングなど、ワークロードが AZ 障害を確実に処理できるようにするために、追加のコストがかかる場合があります。 まとめ この投稿では、ARC ゾーンシフトおよびゾーンオートシフト機能を使用して、単一の AZ 障害から回復する方法を説明しました。入念な計画と実装を行うことで、ゾーンシフトとゾーンオートシフトの可能性を最大限に活用して、単一の AZ 障害から Amazon EKS クラスターで実行されているアプリケーションとデータソースを保護できます。 Amazon EKS のゾーンシフトとゾーンオートシフトの詳細については、 Amazon EKS のドキュメント を参照してください。 GitHub でホストされている AWS Containers Roadmap にコメントを残したり、Issue を投稿したりすることで、EKS クラスターの ARC ゾーンシフト機能に関するフィードバックを提供できます。今後も機能を進化させ、ユーザーがクラスターの耐障害性と可用性を向上させるのに役立つさまざまな方法を模索していきますので、ご期待ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

この記事は Getting started with Amazon EKS Auto Mode (記事公開日: 2024 年 12 月 3 日) を翻訳したものです。 この記事は、Alex Kestner (Amazon EKS シニアプロダクトマネージャー) 、Ashley Ansari (シニアプロダクトマーケティングマネージャー) 、Robert Northard (コンテナプリンシパル GTM SSA) 、Sheetal Joshi (コンテナプリンシパルソリューションアーキテクト) の共著です。 はじめに Kubernetes クラスターにおけるコンピューティング、ストレージ、ネットワーキングを効率的に管理する新機能、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の一般提供を発表しました。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、管理の手間を減らすことができます。クラスター管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進に注力いただけます。 Amazon EKS Auto Mode は、インフラストラクチャの自動プロビジョニング、最適なコンピューティングインスタンスの選択、リソースの動的スケーリング、コスト最適化のために継続的なコンピューティングの最適化、オペレーティングシステム (OS) のパッチ適用、AWS セキュリティサービスとの統合により、Kubernetes クラスター管理を効率化します。有効にすると、EKS Auto Mode は AWS のベストプラクティスに基づいてクラスター機能を設定し、アプリケーションのデプロイに最適な状態でクラスターを準備します。 この記事では、EKS Auto Mode の高レベルアーキテクチャを紹介し、EKS Auto Mode を使用して高可用性かつ自動スケーリング機能を備えたサンプルアプリケーションをデプロイする手順を紹介します。 新機能の紹介 Amazon EKS は長らく、Kubernetes を実行するための安全な方法として信頼されてきました。EKS Auto Mode 以前は、マネージドのコントロールプレーンがあるにもかかわらず、本番環境相当の Kubernetes アプリケーションを実行するために必要なインフラストラクチャを管理するには、専門的な知識と継続的な労力が求められていました。具体的には、ユーザーはリソース効率とコストを最適化するための適切な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの選択とプロビジョニングから、プラグインのインストールとメンテナンスまで、継続的なメンテナンス活動を行わなければなりませんでした。以下の図に示すように、インフラのセキュリティと最新性を維持するため、クラスターのアップグレードや OS のパッチ適用も並行して管理しなければなりませんでした。 Before Auto Mode EKS Auto Mode によるクラスター運用の完全自動化は、本番環境レベルの Kubernetes インフラ管理に必要な専門知識の依存度を大幅に低減し、ユーザーの時間と労力を大きく節約します。EC2 インスタンスの選定やプロビジョニング、リソースとコストの最適化、プラグインのメンテナンスといった作業にユーザーが時間とリソースを費やす必要がなくなりました。 EKS Auto Mode を有効にして新規に EKS クラスターを作成するか、既存のクラスターを更新すると、Amazon EKS は自動的に必要な処理を行います。具体的には、コンピューティング、ネットワーキング、ストレージ機能に必要なコントローラーを、Amazon EKS 専用の AWS アカウントと VPC 内にデプロイします。これはマネージドな Kubernetes コントロールプレーンと併せて実施されます。 アプリケーションのデプロイ時には、EKS Auto Mode が自動的に Bottlerocket OS ベースの EC2 インスタンスと Elastic Load Balancing (ELB) を起動し、ユーザーの AWSアカウントと指定された VPC 内に Amazon EBS ボリュームをプロビジョニングします。さらに、これらの EC2 インスタンスのライフサイクル管理、実行時のアプリケーション要件に応じたデータプレーンのスケーリングと最適化、不健全なノードの自動置換を行います。下図が示すように、EKS Auto Mode は、Amazon EC2 の豊富な機能や柔軟性を損なうことなく、管理されたインフラストラクチャを提供します。 After Auto Mode EKS Auto Mode の導入により、これまで Kubernetes DaemonSet として動作していたノード管理機能が、AWS が管理するシステムプロセスとして実行できるようになりました。具体的には、サービスディスカバリー、ロードバランシング、Pod ネットワーキング、ブロックストレージ、認証情報の提供などの機能が含まれます。AWS がこれらのコンポーネントのライフサイクル管理を担当し、セキュリティ更新を行い、最新のコンポーネントを組み込んだ EKS Auto Mode 用の Amazon Machine Image (AMI) を定期的にリリースします。 また、EKS Auto Mode はクラスターのアップグレードと OS の更新を自動的に行います。この際、ユーザーが定義した Kubernetes のスケジューリング制約を考慮しながら、ノードを段階的に置き換えることで、インフラのセキュリティと最新性を維持します。これにより運用の負担が大幅に軽減され、開発チームはインフラ管理ではなく、アプリケーション開発に注力できるようになります。 はじめ方 EKS Auto Mode は、Kubernetes バージョン 1.29 以降を実行している新規および既存の EKS クラスターで利用可能になりました。EKS Auto Mode を始めるには、新しいコンソール機能 [Quick Configuration (クイック設定) ]が便利です。この機能を使えば、最適なデフォルト設定が予め構成されたクラスターをワンクリックで迅速に立ち上げることができます。あるいは、Amazon EKS API、 AWS マネジメントコンソールのカスタム設定 、 eksctl、お好みの Infrastructure as code (IaC) ツールを使用することも可能です。 このセクションでは、EKS Auto Mode が Amazon EKS 上でのアプリケーションデプロイをいかに簡素化するかを実際に示します。まず、EKS Auto Mode を有効にして EKS クラスターを作成し、その後サンプルの小売店アプリケーションをデプロイします。EKS Auto Mode が新しいノードを自動的に起動し、AWS Load Balancer をセットアップし、永続的なストレージ要件を管理し、アプリケーションの自動スケーリングニーズを処理する様子をご覧いただけます。 事前準備 本記事で紹介する手順を実行するには、以下の準備が必要です： AWSアカウント：管理者権限を持つAWSアカウントをお持ちであることを前提としています。 以下のツールをインストールしてください： Helm 3.9+ 、 kubectl 、 eksctl 、 AWS Command Line Interface (AWS CLI) クラスターの作成 本記事では、EKS クラスターを簡単に作成できるコマンドラインツールである eksctl を使用します。以下に示す設定例では、eksctl を使ってクラスターインフラストラクチャとアプリケーションデプロイ用のサブネットを自動生成します。もしこのサンプル設定を使用しない場合は、 Amazon EKS ユーザーガイド に記載されている前提条件を全て確認してください。特に、クラスター IAM ロールとノード IAM ロールの変更が必要となります。これらの変更により、EKS Auto Mode がユーザーのアカウント内で EC2 インスタンスを管理するための新しい権限が付与されます。 今回のセットアップでは、あらかじめ用意されている general-purpose (汎用) ワークロードとsystem (システム) ワークロード用のマネージドな NodePool を使用して EKS Auto Mode を有効化します。general-purpose NodePool は汎用的なワークロードの起動をサポートし、system NodePool はアドオンを処理します。両方とも、C、M、R ファミリーの amd64 アーキテクチャを持つオンデマンド EC2 インスタンス (第5世代以降) を使用します。マネージドな NodePool の詳細については、 EKS Auto Mode ユーザーガイド を参照してください。 cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-auto-mode-demo region: us-west-2 version: "1.31" addonsConfig: disableDefaultAddons: true autoModeConfig: enabled: true nodePools: ["general-purpose", "system"] EOF eksctl create cluster -f cluster.yaml クラスターの状態が Active  になるまでお待ちください。 aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status' これでクラスターの準備が整い、アプリケーションをデプロイできる状態になりました。次のセクションでは、EKS Auto Mode を使用することで、アプリケーションのデプロイがいかに簡素化されるかを実際に見ていきましょう。 アプリケーションのデプロイ 今回使用する サンプルアプリケーション は、オンラインショッピングの機能を模しています。ユーザーは商品カタログを閲覧し、商品をカートに追加し、チェックアウトプロセスを経て注文を完了することができます。このアプリケーションは、UI、カタログサービス、注文サービス、カートサービス、チェックアウトサービスなど、複数のコンポーネントで構成されています。また、永続的なストレージを必要とするバックエンドデータベースも含まれています。これらのコンポーネントは、Kubernetes の Deployment と StatefulSet を用いて実装されています。アプリケーションへのアクセスには、Kubernetes Ingress を使用してクラスター外からのアクセスを可能にします。また、カタログアプリケーションにはAmazon EBS 永続ストレージを使用するよう設定します。 EKS Auto Mode のパフォーマンス向上、スケーラビリティ、可用性の強化を実証するため、UI アプリケーションには特別な設定を行います。具体的には、 Horizonal pod Autoscaling (HPA) 、 Pod Topology Spread Constraints 、 Pod Disruption Budgets (PDB) をサポートするよう構成します。これらの設定により、EKS Auto Mode がもたらす利点を具体的に示すことができます。 アプリケーションのデプロイに進む前に、まずはクラスターの状態を確認しておきましょう。 kubectl get nodes kubectl get pods 現時点では、ノードと Pod のリストが空であることが確認できました。 アプリケーションのデプロイに進む前に、StorageClass とIngressClass を作成します。これらの設定は、後ほどデプロイするアプリケーションが必要とするストレージと Ingress の要件を満たすための基盤となります。一般的に、この作業はクラスター作成直後にプラットフォームチームが一度だけ実施するものです。この設定を行うことで、アプリケーションのデプロイがスムーズに進み、必要なリソースがすぐに利用可能になります。 cat >ingress.yaml <<EOF --- apiVersion: eks.amazonaws.com/v1 kind: IngressClassParams metadata: name: eks-auto-alb spec: scheme: internet-facing --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: eks-auto-alb spec: controller: eks.amazonaws.com/alb parameters: apiGroup: eks.amazonaws.com kind: IngressClassParams name: eks-auto-alb EOF kubectl apply -f ingress.yaml cat >ebs-sc.yaml <<EOF --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: eks-auto-ebs-csi-sc annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 EOF kubectl apply -f ebs-sc.yaml アプリケーションのデプロイには Helm を使用します。まず、先ほど説明したアプリケーションの要件を指定するための values.yaml ファイルを作成しましょう。 cat >values.yaml <<EOF catalog: mysql: secret: create: true name: catalog-db username: catalog persistentVolume: enabled: true accessMode: - ReadWriteOnce size: 30Gi storageClass: eks-auto-ebs-csi-sc ui: endpoints: catalog: http://retail-store-app-catalog:80 carts: http://retail-store-app-carts:80 checkout: http://retail-store-app-checkout:80 orders: http://retail-store-app-orders:80 assets: http://retail-store-app-assets:80 autoscaling: enabled: true minReplicas: 5 maxReplicas: 10 targetCPUUtilizationPercentage: 80 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui ingress: enabled: true className: eks-auto-alb EOF それでは、小売店アプリケーションのデプロイを行いましょう。デプロイを進める際は、values.yaml ファイルの設定内容に注意を払ってください。特に重要なのは、UI のエンドポイントの設定です。もし、デフォルトの retail-store-app とは異なるチャート名を使用している場合は、必ずエンドポイントの設定を適切に更新してください。 helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3 EKS Auto Mode は、デプロイされた Pod のリソース要求を分析し、アプリケーションの実行に最適なコンピューティングリソースを判断します。この過程で、ユーザーが設定したスケジューリング制約 (トポロジー分散制約を含む) が考慮されます。EKS Auto Mode は general-purpose のマネージド NodePool を利用してノードを起動します。ノードが Ready になるまで待ちます。 kubectl wait --for=condition=Ready nodes --all 別のターミナルで、アプリケーションが使用可能な状態になるのを監視します。 kubectl wait --for=condition=available deployments --all 小売店アプリケーションのコンポーネントは実行中の状態になっているはずです。 catalog-mysql-ebs StatefulSetを調べると、EKS Auto Mode が 30 GiB の PersistentVolumeClaim を作成し、 storageClassName が eks-auto-ebs-csi-sc であることがわかります。 kubectl get statefulset retail-store-app-catalog-mysql \ -o jsonpath='{.spec.volumeClaimTemplates}' | jq . Output: [ { "apiVersion": "v1", "kind": "PersistentVolumeClaim", "metadata": { "creationTimestamp": null, "name": "data" }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "30Gi" } }, "storageClassName": "eks-auto-ebs-csi-sc", "volumeMode": "Filesystem" } } ] EKS Auto Mode は UI アプリケーション用に Application Load Balancer (ALB) を自動的に作成しました。以下のコマンドで ALB 名を確認できます。ALB の準備ができたら、ウェブブラウザでそのリンクにアクセスできます。小売店のホームページが表示されるはずです。 kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}" Output: k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com アプリケーションのスケーリング アプリケーションのデプロイが完了したので、次は EKS Auto Mode によるスケーリング機能を見ていきましょう。EKS Auto Mode は HorizontalPodAutoscaler(HPA) と metrics-server を活用して、アプリケーションの需要に応じてクラスターのリソースを自動的に調整します。Kubernetes では、HPA は観測されたメトリクスに基づいて Deployment のレプリカ数を自動的に調整します。Metrics server は kubelet から CPU とメモリ使用量を収集し、Kubernetes API サーバーを通じて HPA に公開します。HPA はこれらのメトリクスを継続的に監視し、指定されたターゲットに一致するようにレプリカ数を調整します。 まず、Kubernetes metrics-server をデプロイします。 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml この例では、UI サービスを使用し、CPU 使用率 (80 %) に基づいてスケーリングし、maxReplicas を 10 に設定します。なお、HPA の設定はアプリケーションのインストール時にすでに適用されています。具体的な設定内容は、 values.yaml ファイルの AutoScaling セクションで確認できます。現在の AutoScaling ポリシーは、以下のコマンドで確認することができます。 kubectl get hpa retail-store-app-ui 次に、設定した AutoScaling ポリシーがどのように機能するかを確認するため、負荷をかけてみましょう。これにより、EKS Auto Mode がクラスターのインフラストラクチャをどのようにスケールアウトするかを実際に観察できます。 kubectl run load-generator \ --image=public.ecr.aws/amazonlinux/amazonlinux:2023 \ --restart=Never — /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done" アプリケーションに対してリクエストが発生しているので、この負荷に応じて EKS Auto Mode がどのように対応するか観察しましょう。新しいノードが起動し、UI Pod の数が増加する様子を確認できるはずです。 kubectl get nodes --watch Output: NAME STATUS ROLES AGE VERSION i-00018eaec7a3d5370 Ready <none> 155m v1.31.0-eks-672e808 i-043c71a371a8514a1 Ready <none> 155m v1.31.0-eks-672e808 HPA リソースを監視して、その進行状況を追跡できます。 kubectl get hpa retail-store-app-ui --watch Output: NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE retail-store-app-ui Deployment/retail-store-app-ui cpu: 158%/80% 3 10 5 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 161%/80% 3 10 6 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 148%/80% 3 10 9 16m ご覧の通り、EKS Auto Mode はアプリケーションの需要に基づいてクラスターインフラストラクチャを完全に管理し、動的にスケーリングします。Pod を終了させることで、負荷テストを停止できます。負荷生成の Pod が終了すると、HPAは設定に基づいてレプリカ数を徐々に最小数まで減らしていきます。 kubectl delete pod load-generator 主要な考慮事項 Amazon EKS Auto Mode でワークロードを展開する際に考慮すべき主なポイントは以下の通りです： Pod Disruption Budgets を設定し、自発的な中断からワークロードを保護する ：EKS Auto Mode が使用率の低いノードを停止させるような自発的な中断時に、Pod Disruption Budgets は Deployment のレプリカが中断される割合を制御し、一定のワークロード容量を維持してサービスの継続性を確保します。 高可用性を実現するため、レプリカをノードとアベイラビリティーゾーン間に分散させる ：Pod トポロジー分散制約を使用してワークロードをノード間に分散させ、同じノード上で Deployment の複数のレプリカが実行される可能性を最小限に抑えます。 適切なリソース要求と制限を設定する ：EKS Auto Mode はワークロードの vCPU とメモリ要求に基づいて EC2 インスタンスを起動します。リソースの過剰プロビジョニングを避けるため、リソース要求は慎重に設定する必要があります。EKS Auto Mode は リソース制限 や実際の使用量を考慮しないことに注意してください。 アプリケーションは正常なシャットダウン処理を実装する ：自発的な中断の間に作業の損失やユーザー体験の中断を防ぐため、アプリケーションは SIGTERM シグナルを適切に処理して正常にシャットダウンできる必要があります。Kubernetesが Pod の退避を決定すると、退避対象 Pod の各コンテナのメインプロセスに SIGTERM シグナルが送信されます。その後、SIGKILL が送信されるまでの猶予期間 (デフォルトは 30 秒) が設けられます。この猶予期間は Pod 仕様の terminationGracePeriodSeconds で変更可能です。 コンピューティングリソースの選択に過度な制約を設けない ：general-purpose の NodePool は、c、m、r 系の EC2 インスタンスを様々なサイズで利用し、ワークロードに最適なインスタンスを選択する柔軟性を確保しています。特定のコンピューティング要件がある場合は、 Kubernetes の well-known Label を使用して、特定のインスタンスタイプやアーキテクチャなどの属性を指定できます。 アプリケーションのベストプラクティスについて詳しく知りたい場合は、Amazon EKS ベストプラクティスガイドの 信頼性セクション を参照してください。 リソースの削除 不要な料金が発生しないよう、この記事で作成したリソースを以下の手順で削除してください： kubectl delete deploy -n kube-system metrics-server helm uninstall retail-store-app kubectl delete pvc/data-retail-store-app-catalog-mysql-0 eksctl delete cluster —name eks-auto-mode-demo 結論 Amazon EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングの機能をすぐに利用できる形で提供し、アプリケーションデプロイの複雑さを大幅に軽減します。新規クラスターの作成時でも既存クラスターの更新時でも、EKS Auto Mode は効率的な体験を提供します。クラスターインフラの管理だけでなく、Kubernetes の標準に準拠しながら、核となるクラスター機能も提供します。 EKS Auto Mode は、既存の Amazon EKS サービスを補完し、多様なワークロードに対応する柔軟性を提供します。特定の要件がある場合、ユーザーは従来の Amazon EKS コンピューティングオプションを引き続き利用できます。これにより、Kubernetes クラスターのカスタム設定、クラスターインフラの手動プロビジョニングと管理、Kubernetes 環境の詳細な制御が可能です。Auto Mode と従来のオプションの両方をサポートすることで、Amazon EKS は幅広いニーズに対応します。簡素化と運用負荷の軽減を求めるユースケースから、Kubernetes 環境のカスタマイズや詳細な制御が必要なケースまで、様々な要求に応えることができます。 EKS Auto Mode の機能について詳しくは、 Amazon EKS のドキュメント をご覧ください。EKS Auto Mode の実際の動作を確認し、AWS の専門家に質問する機会を得るには、今後のウェビナーシリーズ「 Simplifying Kubernetes operations with Amazon EKS Auto Mode 」にご登録ください。 翻訳はクラウドサポートエンジニアの桐生が担当しました。原文は こちら です。

日進月歩の世界において、世界 20 カ国以上で事業を展開する多国籍消費財（ CPG ）企業は、どのようにしてイノベーションの最先端を走り続けているのでしょうか。 それが、世界最大級の飲料会社であるペルーの CPG 多国籍企業 AJE Group （ AJE ） が、本格的なデジタル変革に乗り出すことを決めたときに直面した課題でした。 2019 年まで、同社はタスクごとに分断されたオンプレミスのインフラ環境を使用しており、世界の多くの地域に分散していました。 AJE は、目標を達成するためには、プロセスを合理化し、リソースをより効率的に管理するために、一元化されたクラウドベースの企業データプラットフォームを構築する必要があると判断しました。 1 万人以上の従業員を抱え、グローバルに事業を展開する同社は、組織全体でデータドリブンな意思決定を強化するため、データソリューションのモダナイズも必要としていました。 「デジタルトランスフォーメーション戦略の一環として、より多くのイノベーションにつながるデータドリブンな文化を社内にもたらしたいと考えていました」と、AJE グループのグローバルデータ＆アナリティクス責任者である Wilmer Rodriguez Ruiz 氏は言います。 AJE は、Amazon Web Services （ AWS ）がこの 2 つの分野で最も適した候補であると判断しました。 「 AWS のソリューションを使うことで、ビジネスの成長戦略を促進し、組織内のパラダイムを変えることができます」と Rodriguez Ruiz 氏は言います。 Amazon Redshift を利用した企業データプラットフォームの構築 AJE は、組織全体のデータを保存、処理、分析するためのデータ分析ソリューションを AWS 上に構築しました。 同社は、 AWS Database Migration Service （ AWS DMS ）を使用して、複数の SQL データベースを AWS に移行しました。 DMS はデータ移行とレプリケーションのためのマネージドサービスで、これを使うことでデータベースと分析ワークロードを素早く安全に、かつ最小限のダウンタイムで、そして実質データロスなしに AWS に移行することができます。 同社はデータウェアハウスとして、 Amazon Redshift を使用しており、 SQL を使用してデータウェアハウス、オペレーショナルデータベース、データレイク全体の構造化データおよび半構造化データを分析しています。 Amazon Redshift は現在、同社のデータの単一かつ真のデータソースとなっています。 さらに、 Amazon Redshift はマネージドサービスであるため、AJE は SQL サーバーのために行わなければならなかった差別化につながらない重労働を減らすことができました。 「私たちのチームは、一般的なデータセンターを管理する必要がなくなり、生産性が向上しました。 当社のソリューションは、キャパシティニーズを満たすために、機能を拡張したり、新しいインスタンスを作成したりするだけです。」 AJE Group は、データ抽出のために AWS Glue を使用しています。これは、複数のソースからデータの発見、準備、移動、統合を簡単にするサーバーレスデータ統合サービスです。 AWS Glue は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスである Amazon Simple Storage Service ( Amazon S3 ) からデータを取得し、Amazon Redshift での分析のためにデータを変換します。 AWS 上に新しい企業データプラットフォームを実装して以来、同社は抽出、変換、ロード（ ETL ）にかかる時間を 35% 短縮しました。 イノベーションのためのデータ可視性の拡大 AJE グループは現在、データレイクを構築するために AWS を利用しており、データソリューションとアナリティクスの両方の拡張を支えています。 グローバル市場に広がる多くの膨大な従業員を抱える組織にとって、中央データソースは職場文化におけるデータ中心の考え方を促進するために不可欠です。「私たちは、データドリブンの戦略を社内に定着させたいと考えています。 データレイクは、すべての意思決定がデータに基づいて行われるように、すべての組織のすべてのレベルに到達するのに役立ちます。」 と Rodriguez Ruiz 氏は言います。 使えるデータがあったとしても、そのデータから洞察や分析を引き出せる従業員がいて初めて生産性に繋がります。 AJE は、AWS を使ってデータプラットフォームを構築すると同時に、従業員にデータリテラシーを身につけさせ、定量的なツールをビジネス戦略に適用できるようにすることにも注力してきました。 「現在、データの分析と取扱に精通した 600 人以上の従業員の育成に成功しています。今後 1 年半のうちに、この数を 3 倍に増やし、組織内のあらゆる階層に行き渡らせたいと考えています」と Rodriguez Ruiz 氏は言います。 AJE のデジタルトランスフォーメーションは、日常業務、特に全部門にわたるデータの可視化において、すでに成果を上げています。 以前は、社内チームが必要なデータにアクセスするのに 4 ～ 5 時間待たなければなりませんでした。 今では、そのデータがほぼリアルタイムで届くため、社内チームはデータに基づいた迅速な意思決定を行えるようになりました。 また、AJE のビジネスアナリストは、コンサルテーションや費用対効果分析をより迅速に完了できるようになりました。 「私たちは、組織全体が自立するために必要なデータの可用性を実現しました。すべての部門が、会社のビジョンを達成するために最適な意思決定をするための情報を持っています。」と Rodriguez Ruiz 氏は言います。 AWS を使うことで、AJE は新しい市場に進出するためのスケーラビリティも向上しました。「クラウドを利用することで、プロセスの拡張が格段に速くなりました。これにより、ビジネスニーズに応じて他の国でも成長できるチャンスが広がりました。」と Rodriguez Ruiz 氏は言います。 データドリブンな未来への投資 デジタルトランスフォーメーションが進む中、AJE グループはビジネスを拡大するための革新的な方法を模索し続けています。 同社は現在も、従業員にデータ中心の文化を浸透させ、新たな機会を探るための分析ツールの使用を推進しています。 AI / ML の普及に伴い、AJE グループは独自のアナリティクスサービスソリューションの構築を計画しています。 「AWS を利用することで、データ分析における従業員の能力を向上させることができました。セルフサービスで予測分析や情報を提供できるようになるチャンスがあります。」と Rodriguez Ruiz 氏は言います。 詳しくは、 AJE グループのお客様事例 をご覧ください。 Kate Wiley Kate Wiley は、AWS の小売業界マーケティング責任者。 AWS 入社以前は、Dick’s Sporting Goods 、 Reebok 、 Drybar 、 Jenny Craig などの小売企業でマーケティングを担当。 Kate は、小売業界のマーケティング責任者として、クラウドを活用してブランドと消費者の緊密な関係を築き、オペレーションを最適化し、AWS を活用してデジタルトランスフォーメーションを加速させる方法について、小売業者のサポートと教育を担当しています。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

AWS re:Invent 2024 は、世界中から集まった参加者にとってイベント盛りだくさんの1週間となりました。カンファレンスの期間中、様々な業界のお客様が中心となり、自社の変革の道のりを共有しました。これらのストーリーは、組織がどのようにクラウドとAIを活用してカスタマーエクスペリエンス戦略を変革し、大きなビジネス成果を達成しているかを浮き彫りにしています。 Amazon Connect はまた、AI のパワーを活用し、オムニチャネル機能を強化する新機能の数々を発表しました。 注目のビジネスインパクト State Farm, Toyota, Air Canada, Coinbase, Amazon Customer Service, Frontdoor, Fujitsu, Pearson, NatWest などのお客様がステージに上がり、ストーリーを共有しました。これらのストーリーは、世界をリードする組織のいくつかが Amazon Connect を活用してビジネスを加速している様子を示しています。プレゼンテーションの動画を視聴するには、以下の各企業のリンクをクリックしてください。 イノベーショントーク: カスタマーサービスのための生成 AI State Farm は、イノベーションの文化に基づいたアプローチでコンタクトセンターを近代化する取り組みに乗り出しました。それぞれの段階から学び最適化した結果、セルフサービスの解決率が 0.5% から 30% 以上に向上し、転送率が大幅に低下した一方で、一次解決率 (FCR) と顧客満足度スコアが向上しました。State Farm は、常にお客様が最善の事態に備え、最悪の事態から立ち直れるよう支援するという使命のもと、生成 AI と予測機能を模索しながら革新を続けています。 オムニチャネル体験とセルフサービスの提供 Air Canada は、旅客や貨物を含む事業分野全体で セルフサービス体験 をどのように革新しているかを紹介しました。 Coinbase は、Amazon Connect を使用してコンタクトセンター業務を迅速に変革し、それまで別々だった電話ベンダーとチャットベンダーを単一の統合 オムニチャネル ソリューションに統合したことを概説しました。 エージェントの生産性向上 Frontdoor はAmazon Connect に迅速に移行し、顧客待ち時間を半分に短縮し、さらにエージェントがよりパーソナライズされたサービスを提供するため生成 AI によって 生産性を向上させている 事について説明しました。 NatWest は、Amazon Q in Connect を使用することで顧客の意図の検出が改善され、エージェントがあらゆるやり取りにおいてよりパーソナライズされたカスタマーサービスを提供できるようになったことを強調しました。 分析、インサイト、最適化の活用 トヨタ は、Amazon Connect Contact Lens の 分析および最適化機能 を活用して、新たなテーマを検出し企業のリーダーが活用するインサイトを引き出す方法を紹介しました。 Fujitsu は、AI を活用した最適化機能を活用して、労働力と品質管理の効率化とコスト削減をどのように行っているかを明らかにしました。 Amazon から学ぶ Amazon Customer Service では、便利でパーソナライズされたカスタマーエクスペリエンスを提供するために、Amazon Connect を使用して年間数十億件もの顧客とのやり取りをサポートする方法について説明しました。また、生成 AI への投資によって世界中のカスタマーサービスがどのように強化されているかも紹介しました。 AWS パートナーとのイノベーション Pearson Clinical Assessments は、Amazon Connect と Salesforce Service Cloud Voice を使用して、音声、チャット、その他のデジタルチャネルにわたる対話を統合する統合ワークスペースをエージェントに提供している事を明らかにしました。 Amazon Connect の新しいイノベーション 効率化された設定と生成 AI でセルフサービス体験を強化 セルフサービスオプション は現代のカスタマーサービス戦略の重要な要素であり、顧客が自分で解決策を見つけられるようにすると同時に、サポートコストを削減し、全体的な満足度を高めます。Amazon Connect は、コンタクトセンターにおける セルフサービス体験 の簡素化と強化を目的とした一連の新機能を発表しました。生成 AI、合理化されたセルフサービス設定、改善された分析を活用して、より効率的で効果的な顧客インタラクションを実現します。 Amazon Connect が Amazon Q in Connect で生成 AI を活用したセルフサービスを開始 Amazon Connect がシンプルな会話型 AI ボットの作成を提供 Amazon Connect Contact Lens が会話型 AI ボットのパフォーマンスを分析するための組み込みダッシュボードをリリース Amazon Connect で IVR およびその他の自動対話中の音声が録音可能に プロアクティブなアプローチをパーソナライズし、チャネルサポートを拡大 現代の顧客は、好みのチャネルでのシームレスなやり取りを期待しています。先進的な企業は顧客のニーズを予測し、パーソナライズされたアプローチを通じて関係性を築く方法を模索しています。同時に、これらのソリューションは複数のコミュニケーションチャネルを統一されたワークスペースに統合し、エージェントがさまざまなアプリケーション間を行き来する必要性をなくし、合理的かつ効率的なワークフローを提供することでエージェントエクスペリエンスを変革しています。 Amazon Connect が顧客セグメントとトリガーベースのキャンペーン向けの AI アシスタントをリリース Amazon Connect が WhatsApp Business メッセージングのサポートを開始 Amazon Connect では、チャット内で重要な顧客データを簡単に収集できるようになりました AWS が Amazon Connect での Salesforce Contact Center を発表 (プレビュー) AI を活用した分析と予測でコンタクトセンターのパフォーマンスを最適化 コンタクトセンターは 分析 を活用して、カスタマーエクスペリエンスとオペレーション効率に革命をもたらしています。今や、顧客の行動を理解し、エージェントのパフォーマンスを最適化し、業務をリアルタイムで合理化するには、高度な分析が不可欠です。AI を使用することで、企業は顧客とのやり取りから深いインサイトを引き出し、将来の傾向を予測し、進化する顧客ニーズに合わせてプロアクティブに対策することができます。Amazon Connect は、現代のコンタクトセンターにおける分析の重要な役割を認識し、カスタマーサービス組織がデータからより多くのインサイトを引き出し、予測の精度を向上させ、カスタマーサービス業務のあらゆる面で継続的な改善を推進しやすくなる機能を導入しました。 Amazon Connect Contact Lens がエージェントのパフォーマンス評価を生成 AI を使用して自動化 Amazon Connect Contact Lens が生成 AI を使用してコンタクトを自動的に分類 Amazon Connect が新しい日中予測ダッシュボードを発表 将来を見据えた取り組み 企業はクラウド、AI、分析を活用してカスタマーサービスを向上させる絶好の機会を迎えています。私たちは、これらの最新機能によって、企業がカスタマーサービス体験とコンタクトセンター運営をどのように再構築し、改革していくかを目の当たりにできることを嬉しく思います。Amazon Connect の詳細については、 ウェブページ をご覧ください。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。

今日のデジタルファースト社会において、企業は効率的かつコスト効果の高い顧客サービスを提供するため、チャットによるコミュニケーションへの依存度を高めています。一般的なカスタマーサービスのシナリオの多くでは、支払い処理や配送先住所の更新、本人確認、アカウント詳細へのアクセスなど、機密情報の収集が必要となります。しかし、 PCI DSS 、GDPR、 CCPA などの規制に準拠しながら、このようなデータを安全に収集することは、特にチャットチャネルにおいて課題となってきました。なぜなら、機密情報が会話記録、コンタクト記録、またはログに露出する可能性があるためです。 例えば、顧客がオンライン小売店の自動応答アシスタントと、近日中の配送に関する住所変更について会話するケースを考えてみましょう。自動応答アシスタントは、顧客に対して別のウェブページにログインして変更を行うよう指示する必要があり、これは会話の流れを中断し、断片的な体験を生み出してしまいます。あるいは、顧客がチャットでの対応中に月々の請求書の支払いを希望するケースを想像してください。チャット上でクレジットカード情報を安全に収集する方法がない場合、音声通話や支払いポータルへの転送が必要となり、対応時間の長期化や顧客の不満につながる可能性があります。 Amazon Connect は、チャットのやり取りにおける機密データ収集機能により、これらの課題に対するソリューションを提供します。ノーコード UI ビルダーを使用して、企業はチャット内で直接顧客の機密情報を収集するフォームを作成できます。このソリューションは、機密データがチャットトランスクリプトや問い合わせ記録に記録されないようにしながら、支払いの処理、顧客プロフィールの更新、その他の重要な取引のためにバックエンドシステムへの安全な送信を可能にします。 このシームレスなアプローチにより、顧客体験を損なうことなく、セキュリティを維持し、PCI に準拠したアーキテクチャを構築することが可能になります。フォームは会話中に文脈に応じて起動でき、機密データは通常のチャットログや保存から除外されながら、目的のシステムに直接送信されます。以下のような一般的なユースケースへの統合を考えてみましょう： 購入や請求書支払いのための支払い情報収集 アカウント更新のための配送先/請求先住所収集 検索のためのアカウント番号や識別子の取得 機密性の高い個人情報収集による本人確認 このブログでは、 Amazon Connect Chat での機密データ収集の実装方法を探り、機密情報のコンプライアンスに準拠した取り扱いを可能にするアーキテクチャを検証し、一般的なユースケースの実装例を順を追って説明します。ノーコードの UI ビルダーを使用してフォームを作成し、それらをチャットフローに統合して、シームレスかつ安全な顧客体験を実現する方法を学んでいただけます。 アーキテクチャの概要 Amazon Connect Chat のセキュアなデータ収集機能は、セキュリティとユーザー体験の両方を重視したアーキテクチャを採用しています。このソリューションの核心部分では、機密データ処理に特化したセキュリティ制御を強化した Amazon Connect のステップバイステップガイドを使用しています。 チャット内でセキュアなデータ収集を有効にするには、以下の2つのフェーズがあります： 1. フォームの作成と設定 フォームは Amazon Connect のノーコード UI ビルダーを使用して作成 フォームは「ビューを表示」ブロックを使用してコンタクトフロー内で設定 「このビューには機密データがあります」オプションを有効にして、安全な処理を開始 2. ランタイムフロー セルフサービスチャットがビューを使用する際、フォームやその他の設定済みガイドコンポーネントが顧客のチャットインターフェースに表示 顧客が入力したデータは転送中に暗号化 機密情報は通常のチャット処理をバイパス AWS Lambda 関数がバックエンド統合のためにデータを安全に処理 セキュリティ責任に関する注意事項 Amazon Connect は機密データを保護するための安全なインフラストラクチャとツールを提供していますが、お客様はセキュリティ要件に従ってこれらの機能を適切に設定し実装する責任を引き続き負っています。これは AWS の 責任共有モデル に従っています – AWS はクラウドインフラストラクチャのセキュリティを確保しますが、安全なフォームの適切な設定、ログ管理、データ処理手順を含む、クラウド「内」のセキュリティはお客様の責任となります。機密データを扱うソリューションを実装する際は、常にセキュリティチームとコンプライアンスチームに相談してください。 Amazon Connect のステップバイステップガイドとフローを活用することで、以下のことが可能になります： ノーコード UI ビルダーで安全なフォームを構築： 簡単にフォームを作成できるドラッグ＆ドロップインターフェース 様々なデータタイプ（クレジットカード番号、社会保障番号、住所など）に対応したカスタマイズ可能なフィールド データの正確性を確保する組み込みの検証ルール カスタムブランディングとスタイリングの追加が可能 機密データの安全な取り扱い： 機密データの保存やログ記録を行わない データはアクティブセッション中のメモリ内でのみ利用可能 必要に応じて AWS Lambda と連携して安全な処理を実行 各チャットセッション終了時に自動的にデータを消去 コンプライアンスの維持： データの分離により不正アクセスを防止 データの暗号化と安全な送信 データ収集に関する詳細な制御 データ処理とセキュリティ この機能は、機密データを保護するために複数のセキュリティレイヤーを実装しています： ゼロ永続化 ：デフォルトでは、機密データはログ、トランスクリプト、またはコンタクト記録に一切書き込まれません 安全な転送 ：すべてのデータは TLS 1.2 以上を使用して転送中に暗号化されます アクセス制御 ：認可された Lambda 関数のみが機密データにアクセスできます 自動クリーンアップ ：データは処理後またはセッション終了時に自動的に削除されます この機能はコンプライアンスに必要な技術的な管理を提供しますが、組織は常にコンプライアンスチームと法務チームに相談し、特定の実装が適用されるすべての要件を満たしていることを確認することが望ましいです。 このセキュアなデータ収集アーキテクチャにより、企業はセキュリティとコンプライアンスを維持しながら、自信を持って機密情報を収集することができます。次のセクションでは、一般的なシナリオにおける具体的なユースケースと実装例を探っていきます。 セキュアなデータ収集の主要なユースケース 一般的なカスタマーサービスのシナリオにおけるセキュアなデータ収集の実装方法を探ってみましょう。各ユースケースには、セキュリティとコンプライアンスを維持しながら、素早く開始できるようにするためのサンプル設定とベストプラクティスが含まれています。 セキュアな支払い処理 最も一般的なニーズの1つは、チャットでのやり取り中にクレジットカード情報を安全に収集することです。これにより、顧客はチャネルを切り替えることなく、支払いの実行、返金の処理、または支払い方法の更新を行うことができます。 プロファイル情報の更新 チャットでのやり取り中に顧客が個人情報を安全に更新できるようにすることで、プライバシーを維持しながらデータの正確性を向上させることができます。この情報は、 Amazon Connect Customer Profiles の更新や、他のバックエンドシステムに保存されている情報の更新に使用できます。 アカウント検索と本人確認 アカウント番号を安全に収集することで、機密性の高い識別子を保護しながら、効率的な顧客確認とアカウント管理が可能になります。本人確認のための機密性の高い個人情報の収集には、使いやすさを維持しながら追加のセキュリティ対策が必要です。 ユースケースに応じて、必要なセキュリティとコンプライアンスを維持しながら、類似または異なるビューを作成することができます。フォームは顧客の意図に基づいて文脈に応じてトリガーされ、チャットでのやり取りの中でシームレスな体験を提供します。 これらの実装は、スムーズな顧客体験を維持しながら、セキュアなデータ収集の基盤を提供します。次のセクションでは、これらのソリューションを Amazon Connect インスタンスにデプロイするためのプロセスを説明します。 ノーコード U I ビルダーを使用したセキュアなフォームの作成 Amazon Connect のノーコード UI ビルダーを使用すると、セキュアなデータ収集フォームを簡単に作成できます。以下が機密情報を保護するフォームの作成方法です： 1. UI ビルダーへのアクセス ルーティング → フロー → ビューに移動 既存のビューを開くか、 ビューを作成 を選択してステップバイステップガイドのノーコード UI ビルダーにアクセス 2. フォームフィールドの設定 Payment テンプレートを選択すると、クレジットカードや住所情報の収集方法の例をすぐに確認できます または、コンポーネントライブラリから必要なデータ（クレジットカードフィールド、住所フィールドなど）の入力フィールドを追加できます ビューの設定が完了したら、フロー内で使用できるように 公開 を選択します 3. フローモジュールの作成 すでに顧客向けのチャットガイドフローが設定されている場合は、それを活用して新しく作成したビューを連携することができます それ以外の場合は、ルーティング → フロー → モジュールに移動し、 フローモジュールを作成 を選択します モジュールの開始時に 「ログ記録動作の設定」 ブロックを追加し、ログ記録を 無効化 します 「ビューを表示」 ブロックを追加し、先ほど作成したビューを選択します 4. 機密データ処理の有効化 「ビューを表示」ブロックの設定で、 このビューには機密データがあります を有効化します エラー処理とタイムアウトの動作を設定します 5. Lambda 統合のセットアップ Amazon Connect 外でデータを処理する必要がある場合は、新しい AWS Lambda 関数を作成します Lambda 関数をインスタンスに関連付け、使用中のコンタクトフローに追加します 「ビューを表示」ブロックの出力を、収集したデータを処理する Lambda 関数に接続します 6. フロー設定の完了 Lambda 関数の処理が完了したら、 「ログ記録の動作の設定」 ブロックでログ記録を再度有効化します モジュールの最後に 「戻る」ブロックを追加して、元々のフロー体験を続けます モジュールに関する注意事項 安全なデータ処理のために再利用可能なフローモジュールを作成してください。モジュールに安全なデータ収集パターンをカプセル化することで、一貫したセキュリティ対策を維持し、複数のコンタクトフロー間で開発時間を節約することができます。 実際の動作を見る Amazon Connect Chat でのセキュアなデータ収集の仕組みをデモンストレーションでご覧ください。このビデオでは、顧客がチャットでのやり取り中に支払い情報を更新する必要がある実際のシナリオをご紹介します。安全なフォームがチャット体験にシームレスに統合され、顧客が安全にクレジットカード情報を入力できる様子をご覧いただけます。 このデモンストレーションは、企業がスムーズで中断のない顧客体験を提供しながら、セキュリティとコンプライアンスを維持できる方法を強調しています。機密データがチャット記録やエージェントのビューに表示されることはありませんが、チャットチャネル内で効率的に取引を完了できることに注目してください。 結論 企業が機密データを保護しながらシームレスな顧客体験の提供を目指す中、Amazon Connect Chat のセキュアなデータ収集機能は、セキュリティ、コンプライアンス、およびユーザー体験のバランスを取る強力なソリューションを提供します。チャットでのやり取り中に直接安全なフォーム収集を可能にすることで、組織は以前は断片的だったプロセスを、顧客の信頼を構築し運用効率を向上させる、スムーズで安全な会話に変えることができます。 シームレスなデジタル体験に対する顧客の期待が高まり続ける中、チャットでのやり取りの中で機密データをセキュアに扱う能力がますます重要になっています。Amazon Connect のセキュアなデータ収集機能は、現代のビジネスに必要なセキュリティとコンプライアンスの管理を維持しながら、信頼できる顧客体験を構築するための基盤を提供します。 これらの機能を実装することで、組織は以下のことが可能になります： デジタルカスタマーサービス業務を自信を持って拡大 セキュリティ要件の変化に迅速に適応 セキュリティを損なうことなく顧客体験を革新 サービス品質を向上させながらコストを削減 カスタマーサービスの未来には、セキュリティとシームレスさの両方が求められます – Amazon Connect のセキュアなデータ収集機能により、その未来は今日、手の届くところにあります。 入門リソース ステップバイステップガイドについてもっと学びたいですか？ ステップバイステップガイドの YouTube プレイリスト の動画をご覧いただき、始め方をご確認ください。 Amazon Connect で最初のステップバイステップガイドの構築を始めたいですか？ この ステップバイステップガイドワークショップ に従って、パーソナライズされた、動的で文脈に応じた体験を提供するためにAmazon Connect 属性と連携するサンプルガイドの構築、デプロイ、テスト方法について詳しく学んでください。 ステップバイステップガイドについて深く掘り下げたいですか？ Amazon Connect 管理者ガイドで詳細をご確認ください。 翻訳はソリューションアーキテクト 新谷 が担当しました。原文は こちら です。

イントロダクション マイクロサービスアーキテクチャをクラウドで実行することは、すぐに複雑な運用になる可能性があります。個々のワークロードにおける複数のインスタンスのような増え続ける変動要素を、インフラストラクチャの依存関係と合わせて考慮する必要があります。その上、これらの要素は、複数の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや、 アベイラビリティーゾーン (AZ) 、AWS リージョンなど、さまざまなトポロジードメインに分散されている場合があります。Kubernetes は、前述のトポロジーに基づいてコンテナのワークロードとインフラストラクチャを自動的にデプロイすることで、これらの環境の構築と管理に伴う運用上の負担をいくらか軽減します。ただし、これらの環境は規模、複雑さ、ネットワークへの依存性があるため、ある時点でアーキテクチャ全体の一部分が機能低下した状態または障害状態になることは避けられません。そのため、チームは実行時の Kubernetes アプリケーションとインフラストラクチャーの状態を把握することで Design for Failure を実践し、ワークロードの可用性を危険にさらす予期しないイベントに迅速に適応して回復できるように構築する必要があります。 アプリケーションとインフラストラクチャの両方におけるベストプラクティスであり共通的なアプローチは、冗長性を確保し、単一障害点を防ぐことです。単一障害点をなくすために、複数のアベイラビリティーゾーンにまたがる Amazon Elastic Kubernetes Service (Amazon EKS) に高可用性アプリケーションをデプロイするお客様が増えています。ただし、アプリケーションとインフラストラクチャの冗長性は、最良の結果を得るために 適用すべき複数ある戦略 の ひとつにすぎません。特定の耐障害性あるいは障害の設計メカニズムを適用するかどうか、またそれらをどのように適用するかは、アプリケーションの目標復旧時間目標 (RTO) と目標復旧時点 (RPO) によって異なります。アプリケーションによっては、ダウンタイム要件が最小限またはゼロのクリティカルな性質のものもあれば、この型にはまらないものもあります。 障害または劣化の範囲は、さまざまなレベルで発生する可能性があります。Amazon EKS 環境では、1 つのワーカーノード、一部のワーカーノード、または AZ 全体に問題が発生することがあります。AZ の障害が発生した場合は、回復力と復旧戦略の一環として Amazon Application Recovery Controller (ARC) のゾーンシフト を使用できます。ARC ゾーンシフトを使用すると、クラスター内のネットワークトラフィックを、影響を受けた AZ から一時的にリダイレクトできます。ただし、ゾーンシフトのプロセスを適切に管理するには、AZ 障害を検出するための十分なモニタリングを実施する必要があります。 あるいは、 ゾーンオートシフト を使用してこれを管理することを AWS に許可することもできます。ゾーンオートシフトでは、AWS がお客様の AZ の全体的な状態を監視し、潜在的な障害が発生した場合は、お客様に代わってクラスター環境内の障害が発生した AZ からトラフィックを自動的に移動させることで対応します。また、その AZ が正常な状態に戻ったときに、その AZ へのクラスター内トラフィックの復元も AWS が管理します。 現在、多くのお客様が Istio などのサービスメッシュ実装を使用して、アプリケーション環境におけるネットワークインフラストラクチャを管理しています。Istio はシステムのネットワークオブザーバビリティの向上に役立ちます。そのデータプレーンプロキシは、特定の AZ の問題など、さまざまな問題を示すネットワークリクエストやマイクロサービスインタラクションに関連する主要なメトリクスを公開するためです。この投稿では、ゾーンシフトを管理するためのシグナルとして Istio のメトリクスを利用し、AZ における異常または劣化が発生した際に、アプリケーションの迅速な復旧を監視および自動化する方法に焦点を当てています。この記事で紹介するソリューションは、すでに Istio を Amazon EKS 環境に導入しているチームにとって最適です。別の方法として、チームはカスタムメトリクスをログデータに埋め込むことができる Amazon CloudWatch とその 埋め込みメトリクス形式 (EMF) の使用を検討することもできます。 ソリューション概要 このチュートリアルでは、EKS で複数の AZ にサンプルアプリケーションをデプロイします。このアプリケーションは サイドカーモード で動作する Istio サービスメッシュの一部です。つまり、各 Pod にはコンテナアプリケーションと Istio サイドカープロキシ (Envoy) の両方が含まれます。サイドカープロキシは、アプリケーションへのインバウンド通信とアウトバウンド通信を仲介します。すべての AZ の状態を判断するには、これらのアプリケーションサイドカープロキシによってキャプチャされたリクエストに対するネットワーク応答 (2xx や 5xx など) を AZ レベルで継続的に評価します。そのために、Prometheus を使用してこれらのサイドカープロキシの Envoy クラスターを監視します。ここで使用するメトリクスは envoy_cluster_zone_availability_zone__upstream_rq です。わかりやすく言うと、Envoy クラスター (EKS クラスターと混同しないでください) とは、特定のアプリケーションのトラフィックを受け入れる類似したアップストリームホストのグループを指します。さらに、Grafana は各 AZ のデータを可視化し、問題が発生した場合には Slack チャンネルにアラートを送信するためにも使用されます。最後に、Amazon EKS で ARC ゾーンシフトを作動させて、アプリケーションの復旧をテストします。この例では 、AZ ヘルスモニタリング用の 1 つのシグナルに焦点を当てていますが、本番環境で マルチ AZ 環境を監視する 場合、環境全体と AZ の健全性と状態をよりよく把握するために、レイテンシー、(トラフィックを受信していない) サイレント障害、 グレー障害 、定期的な障害など、さまざまなタイプの問題や障害も考慮する必要があります。 Envoy が公開しているクラスター統計のリスト を参照できます。 以下の図は、この記事で説明するアプリケーション環境を示しています。 前述したように、このソリューションでは、AZ 内の Pod からの全体的なネットワーク応答を一定の間隔で使用して、AZ が正常かどうかを示します。次の図は、AZ が正常と見なされるクラスターを示しています。 次の図は、一定期間において、AZ ごとの Pod ネットワークにおけるリクエストで発生したサーバー側のエラーの数に基づいて、異常と見なされる AZ (af-south-1c) を示しています。 次の図は、ARC ゾーンシフトを開始して迅速に回復し、Amazon EKS 環境の変化に適応することで、影響を受けた AZ を一時的に隔離し、east-to-west または north-to-southトラフィックを受信しないようにする方法を示しています。Amazon EKS で ARC ゾーンシフトを開始すると、 EndpointSlice コントローラー は正常でない AZ の Pod エンドポイントを EndpointSlice から削除します。しかし、これを Istio のサービスディスカバリーにどう結び付けるのでしょうか。 Istioのサイドカープロキシは、 xDS API と呼ばれるサービスディスカバリーAPIのセットを使用します。xDS API の 1 つが エンドポイント検出サービス (EDS) API です。これにより、上流の Envoy クラスターのメンバー (エンドポイント) を自動的に検出できます。ゾーンシフト中、検出可能なエンドポイント (上流の Envoy クラスターのメンバー) のリストは、クラスターの正常な AZ で実行されているものだけです。ゾーンシフト中も、 宛先ルール を使用して Istio ネットワークポリシーを適用できます。 準備 このサンプルを実行するには、以下の前提条件を満たす必要があります。 AWS アカウント 複数の AZ にプロビジョニングされた EKS クラスター (v 1.28 以上) EKS クラスターでの ARC ゾーンシフト有効化 Istio (サイドカーモード) のインストール オブザーバビリティのため kube-prometheus を用いた Prometheus と Grafana のインストール（または、 このガイド を使用して Amazon Managed Prometheus と Amazon Managed Grafana をセットアップすることもできます） Slack での 受信ウェブフックの設定 （このステップでは、無料の Slack アカウントを使用できます） デモンストレーション 以下の手順で、このソリューションについて説明していきます。 サンプルアプリケーション用の Istio ネットワークの設定 まず、関連する Istio リソースを設定してデプロイし、サンプルアプリケーションが外部からのネットワークリクエストを受信できるようにします。そのためには、まず Istio Ingress ゲートウェイを設定する必要があります。Ingress ゲートウェイはサービスメッシュへのエントリポイントであり、メッシュ内のワークロードを保護し、メッシュに流入するトラフィックを制御する役割を果たします。Istio Ingress ゲートウェイは、開くポートとそれに関連する仮想ホストを指定するゲートウェイリソースを作成することで設定できます。 ゲートウェイ apiVersion: networking.istio.io/v1 kind: Gateway metadata: name: ecommerce-gateway namespace: ecommerce spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"   ネットワークトラフィックが Ingress ゲートウェイを経由してサービスメッシュに入ったら、正しい宛先にルーティングする必要があります。このルーティングプロセスの管理は VirtualService リソースが行います。 Virtual Service apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: payments-virtualservice namespace: ecommerce spec: hosts: - "*" gateways: - ecommerce-gateway http: - match: - uri: prefix: /v1/payments route: - destination: host: payments-service port: number: 3005 retries: attempts: 3 perTryTimeout: 2s 次のステップでは、サンプルアプリケーションをデプロイします。 複数の Pod レプリカを実行して AZ 間に分散させる アプリケーションの複数のインスタンスを実行し、それを複数の AZ に分散させると、耐障害性と可用性の両方が向上します。 トポロジー分散の制約 を使用すると、アプリケーションが事前に静的安定性を持つように設定できます。これにより、AZ に障害が発生した場合でも、トラフィックの急増や急増が発生しても直ちに対処できる十分な数のレプリカが正常な AZ に保持されます。 最初のステップとして、アプリケーションインスタンスを配置する ecommerce 名前空間を作成します。その後、名前空間に適切なラベルを付けて、その名前空間内で実行されるすべてのアプリケーションにサイドカープロキシを挿入することを Istio が認識できるようにする必要があります。 kubectl create ns ecommerce kubectl label namespace ecommerce istio-injection=enabled これらのステップを完了すると、次のコードを使用してサンプルの支払いアプリケーションをデプロイできます。最適に分散 (またはレプリカを分布) させるには、他のレプリカがすでに起動して実行されてからアプリケーションを段階的にスケーリングする必要があります。これにより、スケジューラは特定の AZ のワーカーノードで実行されているレプリカを確認して、ユーザーが定義したスケジューリング制約に従うようにすることができます。 apiVersion: v1 kind: ServiceAccount metadata: name: payments-service-account namespace: ecommerce --- apiVersion: v1 kind: Service metadata: name: payments-service namespace: ecommerce spec: selector: app: payments type: ClusterIP ports: - protocol: TCP port: 3005 targetPort: 3005 --- apiVersion: apps/v1 kind: Deployment metadata: name: payments namespace: ecommerce labels: app.kubernetes.io/version: "0.0.1" spec: replicas: 6 selector: matchLabels: app: payments workload: ecommerce template: metadata: labels: app: payments workload: ecommerce version: "0.0.1" spec: serviceAccountName: payments-service-account topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: payments containers: - name: payments-container image: "lukondefmwila/ecommerce-payments:0.0.1" readinessProbe: httpGet: path: /v1/payments port: 3005 initialDelaySeconds: 5 periodSeconds: 10 ports: - containerPort: 3005 resources: requests: cpu: "1" memory: "64Mi" 前述のリソースを適用すると、Pod がクラスターで期待どおりに実行されていることを確認できます。次のスクリーンショットは、 K9s を使用したビューを示しています。 アプリケーションをデプロイしたら、次のコマンドを入力して Istio Ingress ゲートウェイが認識している payments アップストリームクラスターを一覧表示することで、さまざまな AZ 間でのアプリケーションの分布を確認できます。結果には、Pod エンドポイントと、それらが存在する各 AZ が表示されます。 kubectl exec -it deploy/istio-ingressgateway -n istio-system -c istio-proxy \ -- curl localhost:15000/clusters | grep payments | grep zone 次に、アプリケーションが期待どおりに動作していることをテストします。 まず、Istio Ingress ゲートウェイのホスト名を取得し、そのホスト名に /v1/payments というパスを追加し、ターミナル、ブラウザ、または API クライアントツールで GET リクエストを実行します。 ISTIO_IGW_HOST=$(kubectl get svc --namespace istio-system istio-ingressgateway -o json | jq -r ".status.loadBalancer.ingress | .[].hostname") curl "http://$ISTIO_IGW_HOST/v1/payments" 次のスクリーンショットのような結果が表示されます。 Istio サイドカープロキシを監視するための Prometheus のセットアップ ソリューション概要で詳しく説明されているように、各ゾーンのアプリケーションサイドカープロキシによって処理されるアップストリームリクエストへの応答を評価することで、AZ の状態を判断します。そのためには、まず Istio サイドカープロキシを持つ Pod からメトリクスを取得するように Prometheus を設定する必要があります。 apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: envoy-stats-monitor namespace: prometheus labels: monitoring: istio-proxies release: prom spec: selector: matchExpressions: - {key: istio-prometheus-ignore, operator: DoesNotExist} namespaceSelector: any: true jobLabel: envoy-stats podMetricsEndpoints: - path: /stats/prometheus interval: 15s relabelings: - action: keep sourceLabels: [__meta_kubernetes_pod_container_name] regex: "istio-proxy" - action: keep sourceLabels: [ __meta_kubernetes_pod_annotationpresent_prometheus_io_scrape] - sourceLabels: [ __address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 targetLabel: __address__ - action: labeldrop regex: "__meta_kubernetes_pod_label_(.+)" - sourceLabels: [__meta_kubernetes_namespace] action: replace targetLabel: namespace - sourceLabels: [__meta_kubernetes_pod_name] action: replace targetLabel: pod_name --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: istio-component-monitor namespace: prometheus labels: monitoring: istio-components release: prom spec: jobLabel: istio targetLabels: [app] selector: matchExpressions: - {key: istio, operator: In, values: [pilot]} namespaceSelector: any: true endpoints: - port: http-monitoring interval: 15s 前述のリソースを適用したら、次のコマンドを実行して Prometheus ダッシュボードにアクセスできます。 kubectl -n prometheus port-forward statefulset/prometheus-prom-kube-prometheus-stack-prometheus 9090 次に、Prometheus でメトリクスを確認できるように、サンプルアプリケーションのトラフィックを生成する必要があります。そのためには、ターミナルで以下のコマンドを実行します。これにより、支払いアプリケーションに 150 回の GET リクエストが入力されます。クエリの総数は必要に応じて調整できます。 for i in {1..150}; do curl <insert-your-instio-ingressgateway-hostname>/v1/payments; sleep .5s; done その後、Prometheusダッシュボードを再度開き、次のスクリーンショットに示すように、特定のAZのEnvoyクラスターのメトリクス結果を検索できます。 af-south-1a –  envoy_cluster_zone_af_south_1a__upstream_rq af-south-1b –  envoy_cluster_zone_af_south_1b__upstream_rq af-south-1c –  envoy_cluster_zone_af_south_1c__upstream_rq Grafana ダッシュボードの作成 次に、Grafana でダッシュボードを作成し、関連データをより整理された形式で視覚化します。作成される Grafana パネルのデータソースとして Prometheus を使用します。 ブラウザで Grafana にアクセスするには、次のコマンドを実行します。 kubectl -n prometheus port-forward svc/prom-grafana 3000:80 kube-prometheus でオブザーバビリティスタックをインストールしてから初めて Grafana を起動する場合は、admin ユーザーを使用し、次のコマンドを使用してパスワードを取得できます。 kubectl get secret prom-grafana -n prometheus -o jsonpath="{.data.admin-password}" | base64 --decode ; echo 認証情報を取得したら、Grafana にログインします。デフォルトでは、kube-prometheus には Grafana インストールのデータソースとして Prometheus と Alertmanager があらかじめ設定されています。ただし、Prometheus をデータソースとして設定する必要がある場合は、以下の手順に従うことができます。 左側のメニューで [接続] を選択 [接続] で [新しい接続を追加] を選択 検索バーに「プロメテウス」と入力 表示されたものを選択 右上の [新しいデータソースを追加] を選択 データソースを設定するには、次のスクリーンショットに示すように、接続の名前を入力し、Prometheus サーバーの URL を入力する必要があります。 kube-prometheus の Prometheus サーバー URL は ” http://prom-kube-prometheus-stack-prometheus.prometheus:9090/ ” です。 Prometheus データソースへ正常に接続できたら、Grafana でダッシュボードを作成できます。ダッシュボードに追加する各パネルは、前のセクションと同じメトリクス (envoy_cluster_zone_af_south_1a__upstream_rq など) を使用する EKS クラスターの AZ を表しています。次のスクリーンショットのように、クラスター内の AZ ごとにこのステップを繰り返します。 このプロセスを完了すると、パネル構成によっては、次のスクリーンショットのようなものが表示されるはずです。 EKS クラスター内の AZ 用に Grafana アラートを設定する このセクションでは、Grafana アラートの設定に焦点を当てます。ここまでの手順により、ある AZ における Pod からのネットワーク応答に基づいて対象の AZ の状態を監視できるように EKS クラスター環境が設定されました。ただし、アラートのルールを定義する際には、次の点を考慮する必要があります。 何をもって AZ で問題が発生していると見なすか？ 問題が発生した場合、誰に通知すべきか？ 通知はどのように行われるか？ この例では、特定の AZ 内でサーバー側のエラーが急増している場合、その AZ に何か問題が起きているという兆候であるとします。レイテンシーや、リクエストのタイムアウト、接続障害など、他の指標を使用することもできます。ダッシュボードパネルで行ったように、AZ ごとにアラートルールを作成する必要があります。 まず、 Alert Rules の欄で、次のスクリーンショットのように、直近の 30 分（30分前から現在まで）のデータを使用するようにアラートルールを設定します。次に、各 AZ のサーバー側のエラー (5xx) を追跡できるルールを設定できます。 envoy_cluster_zone_af_south_1a__upstream_rq{response_code_class=”5xx”} その後、設定した条件を Grafana に評価させる頻度を設定し、通知ポリシーのアラートにラベルを割り当てます。 次に、 Contact Point の欄でアラート通知を受け取るSlackチャンネルの連絡先を設定し、次のスクリーンショットのように期待どおりに機能することをテストします。 最後に、 Notification Policy の欄で、次のスクリーンショットに示すように、各ルールに追加したラベルに基づいてGrafanaがアラートを適切な連絡先と照合できるようにポリシーを作成します。 アラート通知システムが期待どおりに機能していることをテストするには、いずれかの AZ (この例では af-south-1c) のアラート条件を変更して、リクエストが正常に送信されたとき (response_code_class= ”2xx” ) に Grafana が代わりに通知できるようにします。さらに、結果を確認するために長時間待たなくても済むように、評価間隔を短くすることもできます。 そのためには、アラートルールのメトリックスとラベルフィルターを更新して、アラートをテストしたい AZ の条件を以下のように設定します。 envoy_cluster_zone_af_south_1c__upstream_rq{response_code_class=”2xx”} その後、テスト目的でカウントのしきい値を減らし、アラートルールの評価間隔を更新できます。Grafana でプレビューを選択すると、どの値がアラートを発するか確認できます。次のスクリーンショットは、アラートルールのプレビュー例を示しています。 アラートルール設定を保存したら、次のスクリーンショットに示すように、アプリケーションに多数のクエリを入力してアラートルールのしきい値を超えるようにすることで、通知システムをテストできます。 Amazon EKS でのゾーンシフトを実行する EKS クラスター内の AZ に異常または障害があるというアラートを受け取った場合は、ARC ゾーンシフトを使用して影響を受ける AZ からネットワークトラフィックを遠ざけることで対応できます。Amazon EKS でゾーンシフトをトリガーすると、次のステップが自動的に適用されます。 影響を受けた AZ のノードは封鎖されます。これにより、Kubernetes スケジューラが異常な AZ のノードに新しい Podをスケジューリングすることを防ぎます。 マネージドノードグループ を使用している場合、 AZ のリバランシング は中断され、Auto Scaling グループ (ASG) が更新されて、新しい EKS データプレーンノードが正常な AZ でのみ起動されるようになります。 異常な AZ のノードは終了されず、Pod もこれらのノードから削除されません。これは、ゾーンシフトの期限が切れたりキャンセルされたりしたときに、まだ十分なキャパシティのある AZ にトラフィックを安全に戻せるようにするためです。 EndpointSlice コントローラーは、障害のある AZ 内の Pod エンドポイントを見つけ、関連する EndpointSlice から削除します。これにより、正常な AZ 内の Pod エンドポイントのみがネットワークトラフィックの受信対象になるようになります。ゾーンシフトがキャンセルされるか期限が切れると、EndpointSlice コントローラーは EndpointSlice を更新して、復元された AZ のエンドポイントを追加します。 次のコマンドを使用して、クラスターのゾーンシフトを開始できます。 export AWS_REGION="af-south-1" export CLUSTER_NAME="beta" export ACCOUNT_ID="your-account-id" export AVAILABILITY_ZONES=("afs1-az1" "afs1-az2" "afs1-az3") aws arc-zonal-shift start-zonal-shift \ --resource-identifier arn:aws:eks:$AWS_REGION:$ACCOUNT_ID:cluster/$CLUSTER_NAME \ --endpoint https://arc-zonal-shift.$AWS_REGION.amazonaws.com/ \ --region $AWS_REGION \ --away-from ${AVAILABILITY_ZONES[2]} --comment "af-south-1c is unhealthy" --expires-in 1h 次のスクリーンショットに示すように、リソースがデプロイされているリージョンに存在する AZ の情報で前述のスクリプトを更新することを忘れないでください。 影響を受けたエンドポイントがトラフィックを受信できなくなったことを確認するには、次のコマンドを実行して、支払いアプリケーションに関連付けられた Envoy クラスターを取得します。 kubectl exec -it deploy/istio-ingressgateway -n istio-system -c istio-proxy \ -- curl localhost:15000/clusters | grep payments | grep zone 前のスクリーンショットでわかるように、支払いアプリケーションに使用できるアップストリームクラスターは af-south-1a と af-south-1b のクラスターだけです。 次に、支払いアプリケーションにクエリを実行して、他の AZ (af-south-1a と af-south-1b) で実行されている Pod からのネットワーク応答に基づいて、そのアプリケーションが引き続き利用可能で期待どおりに機能していることを確認できます。 クリーンアップ これ以上のコストが発生しないように、この記事で詳しく説明した例に関連してプロビジョニングしたインフラストラクチャを必ず削除してください。チュートリアルで Kubernetes マニフェストファイルの保存に使用したファイル名を忘れずに使用してください。 アプリケーションのリソース削除 kubectl delete -f sample-application-manifest.yaml Envoy サイドカー監視用の Prometheus カスタムリソースの削除 kubectl delete -f pod-monitoring-manifest.yaml,service-monitoring-manifest.yaml Prometheus のアンインストール helm uninstall <release-name> -n <namespace> -f values.yaml Istio のアンインストール istioctl uninstall --purge おわりに この投稿では、Istio、Prometheus、Grafana、ARC ゾーンシフトを使用して Amazon EKS クラスター内の AZ 障害を監視し、回復を自動化するための実践的なアプローチについて説明しました。Amazon EKS の ARC ゾーンシフトとゾーンオートシフトの詳細については、 ドキュメント をご覧ください。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

AWS の年次イベント re:Invent 2024 にて、 Amazon Bedrock Marketplace の機能が公開されました！Anthropic Claude や Meta Llama といったサーバーレスモデルに加えて、100 以上の企業または Hugging Face 等でオープンに公開されているモデルを Amazon SageMaker 側にデプロイし Bedrock の API を通じて利用することが出来ます。そして、本サービスがローンチする段階ですでに日本企業が開発したモデルも利用できます。ブログ執筆時点はビジネス知識に特化した Stockmark LLM 、パラメーターにより出力のカスタマイズが容易な Karakuri LM 、日本語のベンチマーク Jaster 等で GPT4 を超える性能を記録した Preferred Networks (PFN) の PLaMo 、22B と軽量ながら日本語ベンチマークで Llama-3-70B-Instruct と同等性能である CyberAgent の CyberAgentLM3 が利用できます。 本ブログでは Apache2 ライセンスによりインフラ費用のみで使用ができる CyberAgentLM3 を中心に、Amazon Bedrock Marketplace で購入できる Stockmark 、Karakuri 、PFN のモデルの特色もご紹介します。 Amazon Bedrock Marketplace でモデルを探し、デプロイする では、さっそく Amazon Bedrock Marketplace でモデルを検索しましょう。AWS Console から Amazon Bedrock のページにアクセスし、“Foundation models” 配下にある “Model catalog” を選択します。医療に特化した John Snow Labs や、音声合成の Cambi.ai のモデルなどもあり目移りしますがはじめに CyberAgentLM3 のモデルを使ってみます。 モデルカードをクリックすると、モデルの詳細画面に遷移します。商用モデルの場合は価格などが記載されています。価格は、モデルを動かすインスタンスの料金に加えモデルの料金が時間単位でかかります。 公開モデルについてはモデルの料金がかかりません。 事前にライセンス、商用モデルの場合は “View subscription options” で表示される Legal のセクションをよく読んでからモデルの Deploy をクリックします。 Deploy すると SageMaker Endpoint にモデルがデプロイされ、利用時は Bedrock の API から呼び出す形になります。SageMaker Endpoint にモデルがデプロイされる仕組み上、サーバーレスではないので料金にはご注意ください。 なお、立ち上げる GPU インスタンスの Quota が足りない場合、 Service Quotas の引き上げをリクエストします 。Quota の設定はリージョンごとに異なるので、モデルを使うリージョンに合わせて申請ください。引き上げる Quota は、Amazon SageMaker の endpoint usage です。endpoint 以外にも training や cluster など種類がたくさんあるので、Quota が endpoint のものかどうか確認をしてください、今回は ml.g5.48xlarge for endpoint usage の Quota が足りなかったので引き上げました。 Deploy を実行すると “Marketplace deployments” からデプロイの状況を確認できます。 “Endpoint ARN” を Amazon Bedrock の model-id として指定すると API から接続することが出来ます。 デプロイが完成すると Endpoint status が “In Service” になります。 CyberAgentLM3 のモデルは Chat のプレイグラウンドから選択することが出来ます。 CyberAgentLM3 は Nejumi LLM リーダーボード のスコアを見ると MT Bench の roleplay, humanities, writing で評価される “GLP_表現“ が前世代の GPT4 / Claude 3.5 Sonnet 並みあり、創作性に強そうだったので作文をお願いしてみます。「犬が海に行き、飼い主を思って吠えるシーンの短い脚本を書いてください」とお願いしました。CyberAgentLM3 と Claude 3.5 Sonnet v2 を比較しており、パラメーターは Temperature 1 でそろえています。 Claude 3.5 Sonnet v2 の結果 タイトル: 『海辺の想い』 場所: 夕暮れの海岸 時間: 夕方 （波の音が静かに響く） 柴犬のポチ、ゆっくりと波打ち際を歩く。 時折立ち止まっては、遠くを見つめる。 ポチ （小さく鳴く） クゥーン… （海風が優しく吹く） ポチ、砂浜に座り込む。 空には夕陽が沈みかけている。 飼い主との思い出の場所を見つめる。 ポチ （徐々に大きな声で） ワン！ワン！ （空を見上げて） ワンワンワーン！ （波の音が少し大きくなる） ポチ、もう一度遠くを見つめ、 ゆっくりと立ち上がる。 ポチ （静かに） クゥーン… （夕陽が海に沈んでいく） ポチ、ゆっくりと来た道を戻り始める。 後ろ髪を引かれるように、 もう一度海を振り返る。 （フェードアウト） 終 続いて CyberAgentLM3 の結果 タイトル: 海辺の約束 シーン: 海辺、穏やかな午後。海風が吹き、波が静かに寄せては引いている。 カメラ: 犬（マックス）が砂浜で遊ぶ姿。遠くには波打ち際にいる飼い主（エミリー）が見える。 ナレーション（マックスの声）: （鼻で鳴きながら）「エミリー、君と一緒にいるといつも楽しかった。」 エミリーが砂浜を歩いている。彼女は波音に耳を傾け、時折遠くを見る。 エミリー: （独り言）「本当に、もうここにはいないんだね。」 マックスが海の方を向き、吠える。その声は大きく、哀愁を帯びている。 エミリー: （驚いて）「マックス、どうしたの？」 マックスはエミリーの方に駆け寄る。 ナレーション（マックスの声）: 「僕が何かを感じてるんじゃない、君がここにいないことを感じるんだ。」 エミリーがマックスの頭を撫でる。 エミリー: 「ごめんね、マックス。君を置いて行かざるをえなかったの。」 マックス: （鼻で鳴く）「でも、約束したじゃないか。また一緒にここに来ようって。」 エミリーの目から涙がこぼれる。 エミリー: 「その約束、まだ覚えてるんだね。必ず戻ってくるから、それまで待っててね。」 マックスがもう一度大きく吠え、それから寄り添うようにエミリーの足元で丸くなる。 ナレーション（マックスの声）: 「約束だよ、エミリー。君が戻ってくるまで、僕はここで君を待ち続ける。」 エミリーがマックスを抱きしめる。海風が二人の周りを優しく包み込む。 カメラがゆっくりと引いていき、海の広がりが広がる。 エンドロール この脚本は犬と飼い主の絆を描きながら、約束の大切さとそれを守ることの意味を表現しています。シンプルな設定の中で、感情の深さを強調しています。 マックス (犬) がいるのかいないのか少し謎ですが、会話劇、心情描写ともにうまくストーリーテリングしてくれている印象です。オープンなモデルの特性として、シチュエーションやアクションシーンの関係で荒くなってしまう行動・言動についてもある程度出力させることが出来ます。CyberAgentLM3 の出力は読むとゲームの状況設定が浮かんできます。 今回は CyberAgentLM3 をそのまま使用していますが、必要に応じ Fine Tuning したのちに Custom model import を使用しモデルを Bedrock のインフラに載せることが出来ます。 Custom model import はモデルのストレージコストがかかりますが 5 分間アクティブでなければ自動的に落ちてくれるため経済的です。詳細は Amazon Bedrock の Pricing のページ をご参照ください。 検証が済んだら忘れずにモデルを削除しておきましょう。 “Marketplace deployments” からモデルが削除できます。現時点では、Endpoint はすぐに削除されますが SageMaker 側の Endpoint Configuration と Model は残るので気になる場合削除してください。 個性的なモデルを試す GPT-4 に匹敵する精度の PFN のモデル PFN の PLaMo は日本語ベンチマークのデータセット Jaster 、また MT-Bench のベンチマークで GPT-4 (0125 Preview)に匹敵する精度を誇ります 。公開されている論文によると MT-Bench では releplay / humanities に優位性があるようで、Appendix でも例が表示されていたことから CyberAgentLM3 と同様小説家になり切り文章を書いてみてもらいます。 PLaMo は執筆時点ではまだプレイグラウンドに対応していないので、API 経由で実行します。 aws bedrock-runtime invoke-model \ --cli-binary-format raw-in-base64-out \ --model-id "(model endpoint arn)" \ --body '{"messages":[{"role": "system", "content": "あなたは優秀な小説家です。"},{"role": "user", "content": "犬が海に行き、飼い主を思って吠えるシーンの短い脚本を書いてください"}], "model": "plamo-prime"}' \ --content-type application/json \ --region us-east-1 \ result.txt 出力は JSON で帰ってくるので jq で取り出します。 cat result.txt | jq .body.choices.[0].message.content PLaMo の出力は次の通りです。 タイトル: 海辺の再会 シーン: 犬のマックスと飼い主のサムが海辺の砂浜を散歩しています。マックスはリードから解放され、興奮しながら海の中に走っていきます。 マックス (吠え声): ワンワンワン! サム: マックス、どうしたの? 海の向こうに行っちゃだめよ。 マックスは海に向かっ て吠え続けます。遠くに船が通り過ぎていきます。 マックス (吠え声): ワワワン! ワワワン! サム (心配そうに): マックス、誰かを呼んでいるの? もしかして、寂しくなっちゃったのかな? 突然、一隻のボートが岸に戻ってきて、マックスはそのボートに向かって走り出します。 マックス (吠 え声): ワンワンワン! ワンワンワン! ボートから降りてきたのは、サムの友人のアレックスでした。アレックスはマックスを見ると、喜びのあまり抱きしめます。 アレックス: マックス! 会いたかったよ。今までどこに行ってたの? マックス (吠え声): ワンワンワン! サム: マックスはあなたを呼んでいたのよ。寂しかったのね。 マックスとアレックスは抱き合って再会を喜び合います。サムは微笑みながら、マックスを見守ります。 サム: マックス、私がいつもそばにいるからね。 マックスはサムに向かって吠え、サムはマックスを抱きかかえ、二人は海辺を後にします。 マックス ( 吠え声): ワンワンワン! (うれしそうに) サム (微笑んで): マックス、大好きだよ。 フェードアウト。 マックス (犬) が離れていた友人と出会い喜ぶシーンがきっちり書かれています。私は何も操作をしていないのですが、犬の名前が CyberAgentLM3 と同じマックスになるのは驚きました。 Claude の出力と同様、犬のセリフはすべてワンワンで表現されています。 PLaMo では英語の MT-Bench で評価された結果も掲載されており、humanities/roleplay/writing のスコアは日本語学習後もスコアをほぼ落としていなかったことから、翻訳がうまくできると思いやってみてもらいました。 翻訳の性能をテストするために、Claude で翻訳が難しい日本語を作ってもらいました。なんとなく、もの悲しい、しみじみといったあいまいな表現を含む情緒的な文書です。 夕暮れ時、なんとなく寂しげな様子で庭先に佇む捨て犬を見かけた少年は、思わずその場に立ち止まってしまった。もの悲しい目をした犬は、少年の方をじっと見つめ返してきた。その瞬間、少年はしみじみと胸に染み渡るような温かい気持ちに包まれた。 英訳してもらった結果がこちらです。 As the sun began to set, a young boy happened upon a forlorn-looking stray dog in the backyard. The sight of the sad-eyed canine, standing alone, caused the boy to pause and approach, his heart swelling with an unexpected surge of compassion. The dog, in turn, seemed to gaze back with a mixture of curiosity and melancholy, as if searching for something or someone to fill the void. The scene stirred an emotional response in the boy, a profound sense of warmth and tenderness that he felt, knowing that he had discovered a kindred spirit in the abandoned animal. 素朴に非常に良い文章と感じましたが、Anthropic Claude / Cohere Command R+/ AI21 Labs Jamba 1.5 / ChatGPT (free) などで評価してもらったところ 85~95 点とやはり高得点でした。創作だけでなくトーンを維持した翻訳にも活用できそうです。 ビジネスに特化した Stockmark のモデル Amazon Bedrock Marketplace の使い方を理解したところで、固有の性質を持つモデルを試してみましょう。はじめに、ビジネスに特化した Stockmark のモデルを試してみましょう。Model catalog で検索します。 商用モデルの場合は “View subscription options” で契約内容を確認してから Deploy を行います。 Stockmark のモデルは Instruction Tuning されていないため、Single prompt から検証します。Instruction Tuning されていないとはいえ普通に質問に対し応答してくれます。 では、「日本の人工知能のスタートアップ企業を 1 社教えてください」に対する Stockmark 、Claude 3.5 v2 、Amazon Nova Pro の回答を並べて比較してみます。Stockmark のモデルは 13B でしかも RAG を行わない状況で設立年月日を答えてきて驚きました。 少し専門的な質問としてペロブスカイト太陽電池のスタートアップについて聞いてみましたが、こちらは Stockmark のみが正解でした。 他いくつか聞いてみましたが、箇条書きにしがちな Claude 、構造化された文章にしやすい Nova に比べて文章が日本語として自然だと感じました。 推論時のパラメーターで挙動を変更できる Karakuri のモデル Karakuri のモデルも試してみましょう。こちらはパラメーターで挙動がコントロールできる面白い特性を持っています。 Sample notebook を参考に、パラメーター付きのプロンプトを入力します。「この書類を明日までに完成させておいてくれませんか?」とお願いをしてみました。 <|START_OF_TURN_TOKEN|><|SYSTEM_TOKEN|>あなたは、人間をサポートするアシスタントです。<|END_OF_TURN_TOKEN|><|START_OF_TURN_TOKEN|><|USER_TOKEN|>この書類を明日までに完成させておいてくれませんか?<|END_OF_TURN_TOKEN|><|START_OF_TURN_TOKEN|><|CHATBOT_TOKEN|><attributes>helpfulness: 4 correctness: 4 coherence: 4 complexity: 4 verbosity: 4 quality: 4 toxicity: 0 humor: 0 creativity: 0</attributes 返答は次の通りです。AI らしい献身的な応答です。 もちろん、その書類を明日までに完成させておきます。どのような書類で、どのような内容を必要としていますか? また、どのフォーマットで、どのようなスタイルで作成すべきか教えていただけますか? 具体的な指示と要望があると、より正確に作業ができます。ご指示をお待ちしております。 プロンプトで指示している パラメーター は次のような意味があります。 helpfulness (デフォルト: 4): プロンプトに対する回答の全体的な有用性 correctness (デフォルト: 4): 誤りのない関連事実の包含度 coherence (デフォルト: 4): 表現の一貫性と明確さ complexity (デフォルト: 4): 回答を書くために必要な専門知識の度合い verbosity (デフォルト: 4): プロンプトで求められている内容に対する、回答に含まれる詳細の量 quality (デフォルト: 4): 回答の認識される良さ toxicity (デフォルト: 0): 下品、有害、または潜在的な偏見を含む望ましくない要素 humor (デフォルト: 0): 回答に含まれるユーモアの度合い creativity (デフォルト: 0): 非従来的な回答を生成する意欲 ここで、toxicity を 4 、有害な応答をあえてしてもらいます。すると・・・「 いいえ 」と一言。ことわってきました。helpfulness を下げても同様の挙動が得られます。塩対応の AI を作るには最適です。 別のパラメーターとして、humor / creativity を 4 に上げて金曜日に出かける相談をしたところ、「かもしれません」というアイデアを多く出してくれました。ブレインストーミングなどをするときはこのモードがいいかもしれません。 標準の応答 金曜日は週末で、多くの場所がにぎわっています。どのようなジャンルの場所をご希望か、また何を目的としているかによっておすすめの場所が変わってきます。具体的な目的地が決まっていない場合は、観光地、グルメ、ショッピング、アクティビティなど、どのようなカテゴリの場所をご希望か教えていただければと思います。または、「金曜日に○○をしたい」というご要望からおすすめの場所をご提案することも可能です。 humor / creativity を 4 に上げた応答 今日は金曜日ですね。どこかお出かけしましょうか ? お出かけの場所をいくつかご提案します。 新しくできたカフェ : 都内を中心に新店舗が続々オープンしているので、新しい空間を求めて足を運んでみるのも良いかもしれません。 最近話題の書店 : 知的好奇心をくすぐる書籍に出会えるチャンスかもしれません。 公園 : 自然の中でリフレッシュすることで、リラックス効果が得られるでしょう。 ショッピングモール : セールを行っている店舗が多いので、お得に買い物ができるかもしれません。 映画館 : 最新の映画を鑑賞することで、新たな発見や感動が得られるでしょう。 どこに行かれるか決まりましたか? おわりに 最終的に一人一人が AI エージェントを持つとき、エージェントは各国の文化や言語の理解はもちろん、主要なドメイン知識を持つ必要があると思います。 これまでの基盤モデルの特性から、単一のモデルであらゆる個性を表現することは可能かもしれませんが、機械学習の国際学会である NeurIPS で元 OpenAI の Ilya Sutskever 氏が指摘したように 学習に使えるデータは限界に達しつつあり 、学習から推論の回数を重ねる工夫も試みられています。この場合、推論にコストがかかるようになり大規模なモデルを何回も推論すると多額のコストがかかり身近なエージェントの実現は困難になります。Amazon Bedrock Marketplace には比較的小型でありながら特化したドメインでは高精度のモデルに匹敵する精度があったり、固有の言語に堪能だったり、Fine Tuning なしにパラメーターで挙動のカスタマイズといった興味深い特性を持つモデルがあることを紹介しました。今回ご紹介した PLaMo の開発を担う Preferred Elements 、また Stockmark 、カラクリはいずれも経済産業省 GENIAC 基盤モデル開発支援事業 (第2期) で採択されており、さらなる性能や使い勝手をもつモデルの開発に取り組んでおり AWS は計算リソースの提供を通じ開発を支援しています 。こうしたバリエーションを持つモデルの可能性がより探索されることで、よりユースケースに適合した生成 AI の活用が実現されると考えています。ぜひあなたのユースケースや好みに合うモデルを Amazon Bedrock Marketplace で探してみてください！

AWS re:Invent 2024 で事前発表した通り、 Amazon Bedrock の Stable Diffusion 3.5 Large を使用することで、様々なスタイルのテキスト記述から高品質な画像を生成し、メディア、ゲーム、広告、小売のお客様向けに、コンセプトアート、ビジュアルエフェクト、詳細な商品画像の作成を加速することができます。 2024 年 10 月、 Stability AI は Stable Diffusion 3.5 Large を発表しました。これは、 Amazon SageMaker HyperPod で学習させた 81 億のパラメータを持つ Stable Diffusion シリーズの中で最も強力なモデルで、優れた品質と迅速なアドヒアランスを備えています。Stable Diffusion 3.5 Large は、ストーリーボード作成、コンセプトアートの作成、視覚効果のラピッドプロトタイピングを加速します。キャンペーン、ソーシャルメディアの投稿、広告用に高品質の 1 メガピクセルの画像をすばやく生成できるため、クリエイティブなコントロールを維持しながら時間とリソースを節約できます。 Stable Diffusion 3.5 Large は、次のようなほぼ無限のクリエイティブな可能性をユーザーに提供します。 多彩なスタイル – 3 次元、写真、絵画、ラインアートなど、想像できるほぼすべてのビジュアルスタイルなど、さまざまなスタイルや美学の画像を生成できます。 プロンプトの順守 – Stable Diffusion 3.5 Large の高度なプロンプトアドヒアランスを使用すると、テキストのプロンプトに厳密に従うことができるため、効率的で高品質なパフォーマンスを得るのに最適な選択肢となります。 多様なアウトプット – 大々的なプロンプトを必要とせずに、異なる肌色や特徴を持つ人々をフィーチャーし、周りの多様な世界を代表する画像を作成することができます。 12 月 19 日、Amazon Bedrock の Stable Image Ultra が更新され、モデルの基盤となるアーキテクチャに Stable Diffusion 3.5 Large が含まれるようになりました。Stable Image Ultra は、Stable Diffusion 3.5 を含む Stability AI の最先端モデルを搭載し、画像生成の新しい基準を打ち立てました。タイポグラフィー、複雑な構図、ダイナミックな照明、鮮やかな色彩、芸術的なまとまりに優れています。 Amazon Bedrock の Stable Diffusion モデルの最新アップデートにより、創造性を高め、画像生成ワークフローを加速するための幅広いソリューションが手に入ります。 Amazon Bedrock の Stable Diffusion 3.5 Large から始めましょう Stability AI モデルを初めて使用する場合は、使用を開始する前に Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択してください。Stability AI の最新モデルにアクセスするには、Stability AI の Stable Diffusion 3.5 Large へのアクセスをリクエストしてください。 Amazon Bedrock で Stability AI モデルをテストするには、左側のメニューペインの [ プレイグラウンド ] で [ 画像/動画 ] を選択します。次に、 [ デルを選択 ] を選択し、カテゴリとして Stability AI を選択し、モデルとして Stable Diffusion 3.5 Large を選択します。 プロンプトで画像を生成できます。画像を生成するためのサンプルプロンプトは次のとおりです。 夜のネオンに照らされた東京の路地でのエネルギッシュなストリートシーン。屋台から湯気が立ち上り、雨に濡れた歩道をカラフルなネオンサインが照らします。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK . でコードサンプルを使用してモデルにアクセスすることもできます。 stability.sd3-5-large-v1:0 をモデル ID として使用できます。 1 つのコマンドで画像を取得するために、出力 JSON ファイルを標準出力に書き込み、 jq ツールを使用してエンコードされた画像を抽出し、その場でデコードできるようにします。出力は img.png ファイルに書き込まれます。 AWS CLI コマンドのサンプルを次に示します。 $ aws bedrock-runtime invoke-model \ --model-id stability.sd3-5-large-v1:0 \ --body "{\"text_prompts\":[{\"text\":\"High-energy street scene in a neon-lit Tokyo alley at night, where steam rises from food carts, and colorful neon signs illuminate the rain-slicked pavement.\",\"weight\":1}],\"cfg_scale\":0,\"steps\":10,\"seed\":0,\"width\":1024,\"height\":1024,\"samples\":1}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ /dev/stdout | jq -r '.images[0]' | base64 --decode > img.jpg Stable Image Ultra 1.1 を使用して、 AWS SDK for Python (Boto3) のモデルの基盤となるアーキテクチャに Stable Diffusion 3.5 Large を組み込む方法は次のとおりです。このシンプルなアプリケーションは、テキストから画像へのプロンプトをインタラクティブに要求し、Amazon Bedrock を呼び出して、モデル ID として stability.stable-image-ultra-v1:1 を使用して画像を生成します。 import base64 import boto3 import json import os MODEL_ID = "stability.stable-image-ultra-v1:1" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-west-2") print("Enter a prompt for the text-to-image model:") prompt = input() body = { "prompt": prompt, "mode": "text-to-image" } response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(body)) model_response = json.loads(response["body"].read()) base64_image_data = model_response["images"][0] i, output_dir = 1, "output" if not os.path.exists(output_dir): os.makedirs(output_dir) while os.path.exists(os.path.join(output_dir, f"img_{i}.png")): i += 1 image_data = base64.b64decode(base64_image_data) image_path = os.path.join(output_dir, f"img_{i}.png") with open(image_path, "wb") as file: file.write(image_data) print(f"The generated image has been saved to {image_path}") アプリケーションは、結果として得られる画像を output ディレクトリ (存在しない場合は作成されます) に書き込みます。既存のファイルを上書きしないように、コードは既存のファイルをチェックして、 img_<number>.png 形式で使用可能な最初のファイル名を見つけます。 詳細については、AWS SDK を使用する Invoke API の例 を参照して、さまざまなプログラミング言語を使用してイメージを生成するアプリケーションを構築してください。 興味深い例 Stable Diffusion 3.5 Large で作成された画像をいくつかご紹介します。 プロンプト: Amazon Bedrock の Stable Diffusion 3.5 という単語を前面に出した陽気な筆記体のタイポグラフィフォントで、テックプロジェクトに取り組んでいる全身の大学生。 プロンプト: 3 つのポーションの写真: 最初のポーションは「MANA」のラベルが付いた青、2 番目のポーションは「HEALTH」のラベルの付いた赤色、3 番目のポーションは「POISON」というラベルの付いた緑です。旧薬屋。 プロンプト: 写真、夕暮れのピンクのバラの花、輝く背景、タイル張りの家。 プロンプト: 愛犬と一緒に世界を旅する冒険家の 3D アニメーションシーン。 今すぐご利用いただけます Stable Diffusion 3.5 Large モデルは、本日、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で一般販売されています。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、 Amazon Bedrock での Stability AI 製品ページと Amazon Bedrock の料金 ページをご覧ください。 Amazon Bedrock コンソール で Stable Diffusion 3.5 Large を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2024 年 11 月 15 日に公開された「 Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications 」を翻訳したものとなります。 生成 AI の急速な進歩は革新的なイノベーションを約束する一方で、重大な課題も提示しています。法的影響、AI が生成した出力の正確性、データプライバシー、そして広範な社会的影響に関する懸念が、責任ある AI の開発の重要性を浮き彫りにしています。責任ある AI とは、利益を最大化し、潜在的なリスクや意図しない害を最小限に抑えることを目標として、一連のディメンションに導かれた AI システムの設計、開発、運用の実践です。私たちのお客様は使用しているテクノロジーが責任を持って開発されたことを知りたいと考えています。また、自社組織内でそのテクノロジーを責任を持って実装するためのリソースとガイダンスを求めています。最も重要なことは、お客様は、展開するテクノロジーがエンドユーザーを含むすべての人の利益になることを確実にしたいということです。AWS では、責任ある方法で AI を開発することに取り組んでおり、教育、科学、そしてお客様を優先する人間中心のアプローチを採用し、AI のライフサイクル全体にわたって責任ある AI を統合しています。 責任ある AI を構成するものは、常に進化し続けています。現時点では、責任ある AI の 8 つの重要なディメンションを考慮しています。公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、そして透明性です。これらディメンションは、責任を持って安全に AI アプリケーションを開発し展開するための基礎を構成します。 AWS では、 Amazon Bedrock ガードレール のような目的に特化したサービスや機能を使い始めるためにツール、ガイダンス、リソースを提供することで、お客様が責任ある AI を理論から実践へと変換できるよう支援しています。本ブログでは、責任ある AI のコアディメンションを紹介し、Amazon Bedrock アプリケーションでこれらのディメンションに対処するための考慮事項と戦略を探ります。 Amazon Bedrock はフルマネージド型サービスで、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要な AI 企業が提供する高性能な基盤モデル（FM）を単一の API を通じて選択できます。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための幅広い機能セットも提供しています。 安全性 責任ある AI における安全性のディメンションは、有害なシステム出力や悪用を防ぐことに焦点を当てています。これは、AI システムがユーザーと社会の幸福を優先するよう導くことに重点を置いています。 Amazon Bedrock は、様々な安全対策を組み込むことで、安全で信頼性の高い AI アプリケーションの開発を促進するように設計されています。以下のセクションでは、これらの安全対策を実装するための異なる側面を探り、それぞれについてガイダンスを提供します。 Amazon Bedrock ガードレールによりモデルの有害性に対処する Amazon Bedrock ガードレールは、アプリケーションが安全でない、または望ましくないとみなされるコンテンツを生成したり、そのコンテンツに関与しないようにすることで、AI の安全性をサポートします。これらの安全対策は、複数のユースケースに対して作成でき、アプリケーションと責任ある AI の要件に応じて、複数の FM にわたって実装できます。例えば、Amazon Bedrock ガードレールを使用して、有害なユーザー入力やモデル出力をフィルタリングしたり、ユーザー入力やモデル出力から機微情報をブロックまたはマスクしたり、アプリケーションが安全でないまたは望ましくないトピックに応答するのを防ぐことができます。 （訳者注）ガードレールは 2024 年 12 月 20 日時点で 英語のみをサポート しており、他の言語でテキストコンテンツを評価すると、信頼できない結果になる可能性があります。以後、本ブログで扱っているガードレールの機能についても同様です。 コンテンツフィルター は、有害または不適切なユーザー入力やモデルが生成した出力を検出してフィルタリングするために使用できます。コンテンツフィルターを実装することで、AI アプリケーションが不適切なユーザーの振る舞いに反応するのを防ぎ、安全な出力のみを提供することができます。これは、特定のユーザーの振る舞いが望ましくない状況では、まったく出力を提供しないことも意味します。コンテンツフィルターは、増悪、侮辱、性的、暴力、不正行為、プロンプト攻撃の 6 つのカテゴリーをサポートしています。フィルタリングは、ユーザーの入力と FM の応答を各カテゴリーにわたって信頼度分類に基づいて行われます。フィルターの強度を調整することで、有害なコンテンツのフィルタリングの感度を決定できます。フィルターを強くすると、望ましくないコンテンツをフィルタリングする確率が高くなります。 拒否トピック は、アプリケーションのコンテキストで望ましくないトピックのセットです。これらのトピックは、ユーザーのクエリやモデルの応答で検出された場合にブロックされます。拒否トピックは、そのトピックの自然言語による定義と、いくつかのオプションの例文を提供することで定義します。例えば、医療機関が AI アプリケーションで薬や治療に関するアドバイスを避けたい場合、拒否トピックを「病状、治療、または投薬に関連して顧客に提供される情報、ガイダンス、アドバイス、または診断」と定義し、オプションの入力例として「投薬 A の代わりに投薬 B を使用できますか」、「病気 Y の治療に投薬 A を使用できますか」、「このほくろは皮膚がんに見えますか」などを設定できます。開発者は、拒否トピックが検出された際にユーザーに表示されるメッセージを指定する必要があります。例えば、「私は AI ボットであり、この問題についてお手伝いすることはできません。カスタマーサービス/診療所にお問い合わせください」などです。本質的に有害ではないものの、エンドユーザーに潜在的に害を及ぼす可能性のある特定のトピックを避けることは、安全な AI アプリケーションを作成する上で極めて重要です。 単語フィルター は、望ましくない単語、フレーズ、および不適切な表現をブロックするためのフィルターを設定するために使用されます。そのような単語には、攻撃的な用語や、製品や競合他社の情報などの望ましくない出力が含まれる可能性があります。カスタム単語フィルターには最大 10,000 項目を追加でき、AI アプリケーションが生成したり関与したりしたくないトピックをフィルタリングすることができます。 機密情報フィルター は、ユーザー入力やモデル出力に含まれる個人を特定できる情報（personally identifiable information: PII）や、指定されたコンテキスト依存の機微情報などをブロックまたは編集するために使用されます。これは、機微データの取り扱いやユーザーのプライバシーに関する要件がある場合に役立ちます。AI アプリケーションが PII 情報を処理しない場合、ユーザーと組織は、PII の偶発的または意図的な誤用や不適切な取り扱いからより安全になります。フィルターは機微情報の要求をブロックするように設定されており、そのような検出時にはガードレールがコンテンツをブロックし、事前に設定されたメッセージを表示します。また、機微情報の編集またはマスクを選択することもでき、その場合はデータを識別子に置き換えるか完全に削除するかを選択できます。 Amazon Bedrock モデル評価によりモデルの有害性を測定する Amazon Bedrock では、 モデル評価 のための組み込み機能が提供されています。モデル評価は、異なるモデルの出力を比較し、ユースケースに最も適したモデルを選択するために使用されます。モデル評価ジョブは、テキスト生成、テキスト分類、質問への回答、テキスト要約など、大規模言語モデル（large language model: LLM）の一般的なユースケースをサポートしています。自動モデル評価ジョブを作成するか、人間の作業者を使用するモデル評価ジョブを作成するかを選択できます。自動モデル評価ジョブの場合、3 つの事前定義された指標（正確性、堅牢性、有害性）にわたる組み込みデータセットを使用するか、独自のデータセットを持ち込むことができます。AWS が管理するチームまたはお客様が管理するチームのいずれかで実施できる human-in-the-loop 評価の場合は、独自のデータセットを持ち込む必要があります。 有害なコンテンツに対する自動モデル評価の使用を計画している場合、まずはあなたの特定のアプリケーションにおいて何が有害なコンテンツを構成するかを定義することから始めてください。これには、攻撃的な言葉、ヘイトスピーチ、その他の有害なコミュニケーション形態が含まれる可能性があります。自動評価には、選択可能な厳選されたデータセットが付属しています。有害性については、RealToxicityPrompts または BOLD データセット、あるいはその両方を使用できます。カスタムモデルを Amazon Bedrock に持ち込む場合、主要なアップデートや再トレーニングの後など、モデル開発の重要な段階で定期的な有害性評価を開発パイプラインに組み込むことで、スケジュールされた評価を実装できます。早期発見のために、新しいデータやモデル出力に対して継続的に有害性評価を実行するカスタムテストスクリプトを実装してください。 Amazon Bedrock とその安全機能は、開発者が安全性と信頼性を優先する AI アプリケーションを作成するのを支援し、それによって AI 技術の信頼性を高め、倫理的な使用を促進します。選択した安全性アプローチを実験し、反復して望ましいパフォーマンスを達成する必要があります。多様なフィードバックも重要なので、安全性と公平さのためにモデルの応答を評価する human-in-the-loop テストの実施を検討してください。 制御性 制御性は、AI システムの振る舞いをモニタリングおよび制御するメカニズムを持つことに焦点を当てています。これは、AI システムが望ましいパラメータ内で動作することを確実にするために、管理、ガイド、制約する能力を指します。 Amazon Bedrock ガードレールを使用して AI の振る舞いをガイドする AI アプリケーションが生成または関与できるコンテンツを直接コントロールするために、安全性のディメンションで議論した Amazon Bedrock ガードレールを使用できます。これにより、システムの出力を効果的に誘導し管理することができます。 コンテンツフィルターを使用して、有害なコンテンツを検出する感度のレベルを設定することで、AI の出力を管理できます。コンテンツのフィルタリングの厳密さを制御することで、望ましくない応答を避けるように AI の振る舞いを制御できます。これにより、システムの相互作用と出力を要件に合わせてガイドすることができます。拒否トピックを定義し管理することで、AI の特定の主題への関与を制御するのに役立ちます。定義されたトピックに関連する応答をブロックすることで、AI システムが設定された境界内の動作に留まるのに役立ちます。 Amazon Bedrock ガードレールは、コンテンツポリシーとプライバシー基準への準拠のためにシステムの振る舞いをガイドすることもできます。カスタム単語フィルターを使用すると、特定の単語、フレーズ、および不適切な表現をブロックでき、AI が使用する言語を直接制御できます。また、機微情報の扱い方（ブロックまたは編集）を管理し、AI のデータプライバシーとセキュリティへのアプローチを制御できます。 Amazon Bedrock のモデル評価を用いて AI のパフォーマンスをモニタリングし調整する AI のパフォーマンスを評価し調整するために、Amazon Bedrock のモデル評価を確認することができます。これにより、システムが望ましいパラメータ内で動作し、安全性と倫理的基準を満たすことを支援します。自動評価と human-in-the-loop 評価の両方を試すことができます。これらの評価方法は、モデルが安全性と倫理的基準をどの程度満たしているかを評価することで、モデルのパフォーマンスをモニタリングしガイドするのに役立ちます。定期的な評価により、フィードバックとパフォーマンス指標に基づいて AI の振る舞いを調整し制御することができます。 開発パイプラインに定期的な有害性評価とカスタムテストスクリプトを組み込むことで、モデルの振る舞いを継続的にモニタリングし調整することができます。このような継続的な制御により、AI システムが望ましいパラメータに沿って維持され、新しいデータやシナリオに効果的に適応することを支援します。 公平さ 責任ある AI における公平さのディメンションは、AI が異なるステークホルダーグループに与える影響を考慮します。公平さを達成するには、継続的なモニタリング、バイアスの検出、そして AI システムの調整を行い、公平さと正義を維持する必要があります。 Amazon Bedrock 上に構築された AI アプリケーションの公平さを支援するため、アプリケーション開発者は機械学習（ML）ライフサイクルの異なる段階でモデル評価とヒューマンインザループのバリデーションを検討すべきです。モデルのトレーニング前後、そしてモデルの推論時にバイアスの存在を測定することが、バイアスを緩和する最初のステップです。AI アプリケーションを開発するときは、公平さの目標、メトリクス、および潜在的に許容可能な最小のしきい値を設定して、ユースケースに該当するさまざまな品質と人口統計にわたってパフォーマンスを測定する必要があります。これらに加えて、潜在的な不正確さやバイアスを緩和する計画を作成すべきです。これには、データセットの修正、バイアスの根本原因の特定と削除、新しいデータの導入、そして場合によってはモデルの再トレーニングが含まれる可能性があります。 Amazon Bedrock は、安全性のディメンションで記載したように、モデル評価のための組み込み機能を提供しています。モデルの堅牢性と有害性を測定するための一般的なテキスト生成の評価には、職業、性別、人種、宗教的イデオロギー、政治的イデオロギーの 5 つの領域に焦点を当てた組み込みの公平性データセットである Bias in Open-ended Language Generation Dataset（BOLD）を使用できます。他の領域やタスクの公平さを評価するには、独自のカスタムプロンプトデータセットを持ち込む必要があります。 透明性 生成 AI における透明性のディメンションは、AI システムがどのように決定を下すのか、なぜ特定の結果を生み出すのか、そしてどのようなデータを使用しているのかを理解することに焦点を当てています。透明性を維持することは、AI システムへの信頼を構築し、責任ある AI の実践を促進するために重要です。 透明性への高まる需要に応えるため、AWS は AWS AI サービスカード を導入しました。これは、AWS の AI サービスに関するお客様の理解を深めることを目的とした専用リソースです。AI サービスカードは、責任ある AI ドキュメンテーションの要となるもので、重要な情報を一箇所に集約しています。これらは、AWS の AI サービスの想定される使用事例、制限事項、責任ある AI 設計原則、そして展開とパフォーマンス最適化のためのベストプラクティスについて、包括的な洞察を提供します。これらは、サービスを責任ある方法で構築するために行う包括的な開発プロセスの一部です。 2024 年 11 月 23 日現在、Amazon Bedrock モデル向けに次の AI サービスカードが提供されています。 Amazon Titan Text Lite and Titan Text Express Amazon Titan Text Premier （訳者注：2024 年 12 月 20 日現在、以下の AI サービスカードもご利用いただけます） Amazon Nova Micro, Lite, Pro Amazon Nova Canvas Amazon Nova Reel Amazon Titan Image Generator Amazon Titan Text Embeddings 他の Amazon Bedrock モデルのサービスカードは、プロバイダーのウェブサイトで直接見つけることができます。各カードには、サービスの具体的な使用例、採用されている ML 技術、そして責任ある展開と使用のための重要な考慮事項が詳細に記載されています。これらのカードは、顧客のフィードバックと継続的なサービス改善に基づいて反復的に進化し、常に関連性と情報性を保っています。 透明性を提供するもう一つの取り組みは、Amazon Titan Image Generator の目に見えないウォーターマーク（透かし）です。Amazon Titan によって生成された画像には、デフォルトでこの目には見えないウォーターマークが付いています。このウォーターマークの検出メカニズムにより、Amazon Titan Image Generator によって生成された画像を識別することができます。これは、自然言語プロンプトを使用して、大量かつ低コストで現実のスタジオで製作されたような品質の画像を作成するように設計された FM です。ウォーターマーク検出を使用することで、生成 AI コンテンツに関する透明性を高め、有害なコンテンツ生成のリスクを緩和し、誤情報の拡散を減らすことができます。 コンテンツクリエイター、報道機関、リスク分析者、不正検出チームなどは、この機能を使用してAmazon Titan Image Generator によって作成された画像を識別し、認証することができます。検出システムは信頼性スコアも提供するため、元の画像が変更されていても、検出の信頼性を評価することができます。Amazon Bedrock コンソールに画像をアップロードするだけで、API は Amazon Titan モデルによって生成された画像に埋め込まれたウォーターマークを検出します。これには、ベースモデルとカスタマイズされたバージョンの両方が含まれます。このツールは責任ある AI の実践をサポートするだけでなく、生成 AI によって作成されたコンテンツの使用における信頼性を促進します。 正確性と堅牢性 責任ある AI における正確性と堅牢性のディメンションは、予期せぬ入力や敵対的な入力があっても、正確なシステム出力を達成することに焦点を当てています。このディメンションの主な焦点は、モデルのハルシネーション（幻覚）の可能性に対処することです。モデルのハルシネーションは、AI システムが妥当に思える虚偽や誤解を招く情報を生成する時に発生します。AI システムの堅牢性は、様々な条件下で、予期せぬ状況や不利な状況を含めて、モデルの出力が一貫性があり信頼できるものであることを確実にします。堅牢な AI モデルは、不完全または不正確な入力データに直面しても、その機能を維持し、一貫性のある正確な出力を提供し続けます。 Amazon Bedrock のモデル評価で精度と堅牢性を測定する AI の安全性と制御性のディメンションで紹介されたように、Amazon Bedrock は有害性、堅牢性、精度の観点からAI モデルを評価するためのツールを提供しています。これにより、モデルが有害、攻撃的、または不適切なコンテンツを生成しないようにし、予期せぬ入力や敵対的なシナリオを含む様々な入力に耐えられるようにします。 精度評価は、AI モデルが様々なタスクやデータセットにわたって信頼性の高い正確な出力を生成するのに役立ちます。組み込みの評価では、TREX データセットに対して精度が測定され、アルゴリズムはモデルの予測が実際の結果とどの程度一致するかを計算します。精度の実際の指標は選択されたユースケースによって異なります。例えば、テキスト生成では、組み込みの評価は実世界の知識スコアを計算し、これはモデルが実世界に関する事実的知識をエンコードする能力を調べます。この評価は、AI アプリケーションの完全性、信頼性、有効性を維持するために不可欠です。 堅牢性評価は、モデルが多様で潜在的に困難な条件下でも一貫したパフォーマンスを維持することを確認します。これには、予期せぬ入力、敵対的な操作、データ品質の変動に対して、パフォーマンスの大幅な低下なしに対処することが含まれます。 Amazon Bedrock アプリケーションにおける正確性と堅牢性を実現するための方法 LLM をアプリケーションで使用する際に、正確性と堅牢性を最大化するために検討できるいくつかの手法があります。 プロンプトエンジニアリング – モデルに対して、モデルが知っていることについてのみ対話を行い、新しい情報を生成しないよう指示することができます。 Chain-of-thought（CoT: 思考の連鎖） – CoT はモデルが最終的な答えに至る中間的な推論ステップを生成する技術です。これにより、モデルの思考プロセスを透明で論理的にすることで、複雑な問題を解決する能力が向上します。例えば、モデルに対してなぜ特定の情報を使用し、特定の出力を作成したのかを説明するよう求めることができます。これはハルシネーションを減らすための強力な方法です。モデルに出力を生成するために使用したプロセスを説明するよう求めると、モデルは実行したステップや使用された情報を識別しなければならないため、それによってハルシネーション自体が減少します。CoT や Amazon Bedrock で提供される LLM のその他のプロンプトエンジニアリング技術についてさらに学ぶには、 Amazon Bedrock のプロンプトエンジニアリングの概念 をご確認ください。 Retrieval Augmented Generation（RAG） – RAG は適切なコンテキストを提供し内部データでモデルが生成する出力を拡張することで、ハルシネーションを軽減するのに役立ちます。RAG を使用すると、モデルにコンテキストを提供し、提供されたコンテキストのみに基づいて応答するようモデルに指示することができ、これによりハルシネーションが少なくなります。 Amazon Bedrock ナレッジベース を使用すると、データの取り込みから検索、プロンプトの拡張までの RAG のワークフローを実装できます。ナレッジベースから取得された情報には、AI アプリケーションの透明性を向上させ、ハルシネーションを最小限に抑えるために、出典が含まれます。 ファインチューニングと事前トレーニング – これらは、特定のコンテキストに対するモデルの精度を向上させるための異なる技術です。RAG を通じて内部データを提供する代わりに、これらの技術では、データセットの一部としてデータをモデルに直接追加します。 Amazon Simple Storage Service （Amazon S3）バケットに保存されたデータセットを指定することで、 複数の Amazon Bedrock FM をカスタマイズできます。ファインチューニングでは、数十から数百のラベル付きサンプルを使用して、特定のタスクのパフォーマンスを向上させるためにモデルをトレーニングできます。モデルは特定の種類の入力に対して特定の種類の出力を関連付けることをトレーニングします。また、継続的な事前トレーニングを使用することもでき、これによりモデルにラベルなしデータを提供し、モデルが特定の入力に慣れ、パターンをトレーニングするようにします。これには、例えば、モデルが十分なドメイン知識を持っていない特定のトピックからのデータが含まれ、それによりその領域の精度が向上します。これらのカスタマイズオプションはどちらも、大量のアノテーションされたデータを収集することなく、正確なカスタマイズされたモデルを作成することを可能にし、結果としてハルシネーションを減少させます。 推論パラメータ – 推論パラメータ についても検討することができます。これらは、モデルの応答を修正するために調整可能な値です。設定できる推論パラメータは複数あり、それぞれモデルの異なる能力に影響を与えます。例えば、モデルの応答をより創造的にしたり、物語の文脈のように完全に新しい情報を生成したりしたい場合、temperature パラメータを調整することができます。これにより、モデルが確率分布全体から単語を探し、その空間でより離れた単語を選択する方法に影響を与えます。 コンテキストグラウンディング – 最後に、Amazon Bedrock ガードレールの コンテキストグラウンディング チェックを使用することができます。Amazon Bedrock ガードレールは、開発者がコンテンツフィルターを設定し、拒否トピックを指定することで、許可されたテキストベースのユーザー入力とモデル出力を制御できるメカニズムを Amazon Bedrock サービス内で提供します。モデルの応答がソースの情報に根拠がない（事実に反している、または新しい情報を追加している）場合や、ユーザーのクエリに関連がない場合、それらのハルシネーションを検出してフィルタリングすることができます。例えば、RAG アプリケーションにおいて、モデルの応答が取得された文章中の情報から逸脱している場合や、ユーザーの質問に答えていない場合、その応答をブロックまたはフラグ付けすることができます。 モデルプロバイダーやチューナーはこれらのハルシネーションを緩和できない可能性がありますが、ユーザーにハルシネーションが発生する可能性があることを知らせることはできます。これは、AI アプリケーションの使用はユーザー自身の責任で行うという免責事項を追加することで実現できます。現在、複数の出力間の変動（エントロピーとして測定）に基づいて不確実性を推定する方法の 研究 にも進展が見られます。これらの新しい方法は、質問が誤って回答される可能性が高い場合を特定することにおいて、以前の方法よりもはるかに優れていることが証明されています。 説明可能性 責任ある AI における説明可能性のディメンションは、システム出力の理解と評価に焦点を当てています。説明可能な AI フレームワークを使用することで、人間はモデルを調べ、どのように出力を生成しているかをより良く理解することができます。生成 AI モデルの出力の説明可能性については、正確性と堅牢性のディメンションで議論したように、トレーニングに使われたデータの出所を確認したり CoT プロンプティングなどの技術を使用できます。 出力された情報の出所を確認したいお客様には、Amazon Bedrock ナレッジベースを使用した RAG をお勧めします。RAG では可能性のある情報源がプロンプト自体に含まれているため、情報の出所を確認できます。ナレッジベースから取得された情報には情報源が含まれており、透明性を向上させハルシネーションを最小限に抑えることができます。Amazon Bedrock ナレッジベースは、エンドツーエンドの RAG ワークフローを管理します。RetrieveAndGenerate API を使用する際、出力には生成された応答、情報源、および取得されたテキストチャンクが含まれます。 セキュリティとプライバシー 生成 AI 技術を利用するすべての組織にとって、絶対に重要なことが一つあるとすれば、それはあなたの行うすべてのことがプライベートであり続けること、そしてあなたのデータが常に確実に保護されることです。責任ある AI におけるセキュリティとプライバシーのディメンションは、データとモデルが適切に取得され、使用され、保護されることに焦点を当てています。 Amazon Bedrock の組み込みセキュリティとプライバシー Amazon Bedrock では、データプライバシーとローカライゼーションの観点から、AWS はお客様のデータを保存しません。保存しないため、漏洩することも、モデルベンダーに見られることも、AWS が他の目的で使用することもありません。私たちが保存する唯一のデータは運用メトリクスです。例えば、正確な請求のために、AWS は特定の Amazon Bedrock モデルに送信したトークン数と、モデル出力で受け取ったトークン数に関するメトリクスを収集します。もちろん、ファインチューニングされたモデルを作成する場合、AWS がそれをホストするためにそのモデルを保存する必要があります。API リクエストで使用されるデータは、お客様が選択した AWS リージョン内に留まります。特定のリージョンの Amazon Bedrock API へのリクエストは、完全にそのリージョン内に留まります。 データセキュリティについて、よく言われることは「データが移動するのであれば暗号化する」ということです。Amazon Bedrock への、からの、そして内部での通信は、すべて転送中に暗号化されます。Amazon Bedrock には TLS を使用しないエンドポイントはありません。もう一つよく言われることは「動かないデータも暗号化する」ということです。デフォルトでは、ファインチューニングに用いるデータとモデルは AWSが管理する AWS Key Management Service （AWS KMS）キーを使用して暗号化されますが、お客様独自の KMS キーを使用するオプションもあります。 Amazon Bedrock リソースを使用する権限を持つユーザーを制御するのは、 AWS Identity and Access Management （IAM）です。各モデルに対して、アクションへのアクセスを明示的に許可または拒否することができます。例えば、あるチームやアカウントに Amazon Titan Text のキャパシティをプロビジョニングする権限を与えるけれども Anthropic モデルへのアクセスは許可しない、といったことが可能です。必要に応じて、広範囲または詳細な設定を行うことができます。 Amazon Bedrock API へのアクセスのためのネットワークデータフローを見る際、トラフィックが常に暗号化されていることを覚えておくことが重要です。 Amazon Virtual Private Cloud （Amazon VPC）を使用している場合、 AWS PrivateLink を利用して　Amazon Bedrock のフロントエンドフリートへリージョナルネットワークを通じたプライベート接続を提供し、インターネットゲートウェイを介したインターネットトラフィックへの露出を緩和することができます。同様に、企業のデータセンターの観点では、VPN または AWS Direct Connect を設定して VPC にプライベート接続し、そこから PrivateLink を介して Amazon Bedrock にトラフィックを送信することができます。これにより、オンプレミスシステムがインターネット経由で Amazon Bedrock 関連のトラフィックを送信する必要がなくなるはずです。AWS のベストプラクティスに従い、ゼロトラストの原則に基づいてセキュリティグループとエンドポイントポリシーを使用して PrivateLink エンドポイントへのアクセスを制御し保護します。 Amazon Bedrock のモデルカスタマイズにおけるネットワークとデータセキュリティについても見てみましょう。カスタマイズのプロセスでは、まずリクエストされたベースラインモデルを読み込み、その後お客様のアカウント内の S3 バケットからカスタマイズのためのトレーニングデータとバリデーションデータを安全に読み取ります。データへの接続は、 Amazon S3 用のゲートウェイエンドポイント を使用して VPC を通じて行うことができます。つまり、バケットポリシーを適用することができ、S3 バケットへのより広範なアクセスを開放する必要がありません。新しいモデルが構築されたら、暗号化されてカスタマイズされたモデルバケットに配信されます。モデルベンダーがお客様のトレーニングデータやカスタマイズされたモデルにアクセスしたり、可視化したりすることは一切ありません。トレーニングジョブの終了時には、元の API リクエストで指定した S3 バケットにトレーニングジョブに関する出力メトリクスも配信されます。前述のとおり、トレーニングデータとカスタマイズされたモデルの両方を、お客様が管理する KMS キーを使用して暗号化することができます。 プライバシー保護のベストプラクティス 生成 AI アプリケーションを実装する際に最初に念頭に置くべきことは、データの暗号化です。先ほど述べたように、Amazon Bedrock は転送中および保管時の暗号化を使用しています。保管時の暗号化については、デフォルトの AWS 管理の KMS キーの代わりに、お客様が管理する KMS キーを選択することができます。企業の要件によっては、お客様が管理する KMS キーを使用したい場合があるでしょう。転送中の暗号化については、Amazon Bedrock API に接続する際に TLS 1.3 を使用することをお勧めします。 モデルの利用規約とデータプライバシーについては、利用規約（End User License Agreement: EULA）を読むことが重要です。モデルプロバイダーはこれらの利用規約を設定する責任があり、お客様はこれらを評価し、アプリケーションに適しているかどうかを判断する責任があります。Amazon Bedrock でモデルアクセスをリクエストする場合も含め、常に利用規約を読み、理解してから同意するようにしてください。利用規約の内容に納得していることを確認してください。またテストデータが法務チームによって承認されていることを確認してください。 プライバシーと著作権に関して、トレーニングやファインチューニングに使用するデータが法的に利用可能で、実際にそれらのモデルのトレーニングやファインチューニングに使用できることを確認するのは、プロバイダーとモデルをチューニングする人の責任です。また、使用しているデータがモデルに適切であることを確認するのもモデルプロバイダーの責任です。公開されているデータは自動的に商業利用のための公開を意味するわけではありません。つまり、このようなデータを使用して何かをチューニングし、顧客に見せることはできません。 ユーザーのプライバシーを保護するために、安全性と制御性のディメンションで議論した Amazon Bedrock ガードレールの機密情報フィルターを使用することができます。 最後に、生成 AI を用いた自動化を行う際（例えば、 Amazon Bedrock のエージェント を使用する場合）、モデルが自動的に決定を下すことに問題がないか確認し、アプリケーションが誤った情報や行動を提供した場合の結果を考慮してください。したがって、ここではリスク管理を検討することが重要です。 ガバナンス AI システムが倫理基準、法的要件、社会的価値観に沿って開発、展開、管理されることを確実にするのがガバナンスのディメンションです。ガバナンスには、AI の開発と使用を安全で公正、かつアカウンタビリティを持つ方法で導く枠組み、方針、規則が含まれます。AI のガバナンスを設定し維持することで、ステークホルダーは AI アプリケーションの使用に関する情報に基づいた決定を下すことができます。これには、データの使用方法、AI の意思決定プロセス、ユーザーへの潜在的な影響についての透明性が含まれます。 堅牢なガバナンスは、責任ある AI アプリケーションを構築するための基盤です。AWS は、AI ガバナンスの実践を確立し運用するための様々なサービスとツールを提供しています。また、AWS は AI ガバナンスフレームワーク を開発し、データとモデルのガバナンス、AI アプリケーションのモニタリング、監査、リスク管理などの重要な分野におけるベストプラクティスに関する包括的なガイダンスを提供しています。 監査可能性について見ると、Amazon Bedrock は AWS Audit Manager から提供される AWS 生成 AI ベストプラクティスフレームワーク v2 と統合されています。このフレームワークを使用することで、エビデンスの収集を自動化し、Amazon Bedrock 内での生成 AI 使用の監査を開始できます。これにより、AI モデルの使用と権限の追跡、機密データのフラグ付け、問題のアラート通知に一貫したアプローチを提供します。収集されたエビデンスを使用して、責任、安全性、公平さ、持続可能性、レジリエンス、プライバシー、セキュリティ、正確性という 8 つの原則にわたって AI アプリケーションを評価できます。 モニタリングと監査の目的で、Amazon Bedrock は ビルトインで統合されている Amazon CloudWatch と AWS CloudTrail を利用できます。CloudWatch を使用してAmazon Bedrock をモニタリングできます。CloudWatch は生データを収集し、読みやすいリアルタイムに近いメトリクスに処理します。CloudWatch はモデル呼び出しやトークン数などの使用メトリクスを追跡するのに役立ち、1 つまたは複数の AWS アカウントの 1 つまたは複数の FM にわたって監査目的のカスタマイズされたダッシュボードを構築するのに役立ちます。CloudTrail は、Amazon Bedrock に対するユーザーと API アクティビティの記録を提供するログサービスです。CloudTrail は API データを証跡に収集します（証跡はCloudTrail サービス内で作成する必要があります）。証跡により、CloudTrail はログファイルを S3 バケットに配信できるようになります。 Amazon Bedrock は、モデル呼び出しのログ記録も提供しています。これは、Amazon Bedrock で使用される AWS アカウント内のすべての呼び出しについて、モデルに入力されたデータ、プロンプト、モデルの応答、リクエスト ID を収集するために使用されます。この機能により、モデルがどのように使用されているか、どのようなパフォーマンスを示しているかについての洞察が得られ、お客様とステークホルダーが AI アプリケーションの使用に関して、データに基づいた責任ある決定を下すことができます。モデル呼び出しログは有効にする必要があり、ログデータを S3 バケットと CloudWatch ログのどちらに保存するかを選択できます。 コンプライアンスの観点から、Amazon Bedrock は ISO、SOC、FedRAMP moderate、PCI、ISMAP、CSA STAR Level 2 などの一般的なコンプライアンス基準の対象となっており、Health Insurance Portability and Accountability Act（HIPAA）の対象にもなっています。また、General Data Protection Regulation（GDPR）に準拠して Amazon Bedrock を使用することもできます。Amazon Bedrock は Cloud Infrastructure Service Providers in Europe Data Protection Code of Conduct（ CISPE CODE ）の Public Register に含まれています。これは、Amazon Bedrock が GDPR に準拠して使用できることを独立して検証されたことを意味します。Amazon Bedrock が特定のコンプライアンスプログラムの対象範囲内にあるかどうかについての最新情報は、 コンプライアンスプログラムによる対象範囲内の AWS のサービス を参照し、関心のあるコンプライアンスプログラムを選択してください。 Amazon Bedrock アプリケーションにおける責任ある AI の実装 Amazon Bedrock でアプリケーションを構築する際は、アプリケーションのコンテキスト、ニーズ、エンドユーザーの振る舞いを考慮してください。また、組織のニーズ、法的および規制上の要件、責任ある AI を実装する際に収集したいまたは必要なメトリクスについても検討してください。利用可能な管理機能や組み込み機能を活用してください。以下の図は、責任ある AI の主要なディメンションに対応するために実装できる様々な対策を概説しています。これは網羅的なリストではありませんが、本ブログで言及された対策をどのように組み合わせることができるかの提案です。これらの対策には以下が含まれます。 モデル評価 – モデル評価を使用して、公平さ、正確性、有害性、堅牢性、その他のメトリクスを評価し、選択したFMとその性能を評価します。 Amazon Bedrock ガードレール – Amazon Bedrock ガードレールを使用して、コンテンツフィルター、禁止トピック、単語フィルター、機密情報フィルター、コンテキストグラウンディングの実装を確立します。ガードレールを使用することで、安全でない、または有害なトピックや単語を拒否し、エンドユーザーの安全を保護することでモデルの振る舞いをガイドすることができます。 プロンプトエンジニアリング – CoT などのプロンプトエンジニアリング技術を活用して、AI アプリケーションの説明可能性、正確性と堅牢性、安全性と制御可能性を向上させます。プロンプトエンジニアリングを使用することで、トーン、スコープ、応答の長さを含む、モデル応答の望ましい構造を設定できます。プロンプトテンプレートに禁止トピックを追加することで、安全性と制御可能性を強調できます。 Amazon Bedrock ナレッジベース – Amazon Bedrock ナレッジベースを使用して、エンドツーエンドの RAG 実装を行い、ハルシネーションを減少させ、内部データを使用するケースにおけるモデルの正確性を向上させます。RAG を使用することで、AI アプリケーションの正確性と堅牢性、安全性と制御可能性、説明可能性が向上します。 ロギングとモニタリング – 効果的なガバナンスを実施するために、包括的なロギングとモニタリングを維持します。 責任ある AI のコアディメンションに対応するために実施できる様々な対策の概要図 まとめ 責任ある AI アプリケーションの構築には、計画的で構造化されたアプローチ、反復的な開発、そして継続的な努力が必要です。Amazon Bedrock は、責任ある AI アプリケーションの開発と展開をサポートする堅牢な組み込み機能スイートを提供しています。カスタマイズ可能な機能と独自のデータセットを統合する能力を提供することで、Amazon Bedrock は開発者が特定のアプリケーションコンテキストに AI ソリューションを調整し、責任ある AI に関する組織の要件に合わせることを可能にします。この柔軟性により、AI アプリケーションが効果的であるだけでなく、倫理的で、公平さ、安全性、透明性、アカウンタビリティに関するベストプラクティスに沿ったものであることを確実にします。 責任ある AI のディメンションに従って AI を実装することは、AI ソリューションを透明性を持って、バイアス無く開発し使用するための鍵となります。AI の責任ある開発は、組織全体での AI 採用を促進し、エンドカスタマーとの信頼関係を構築するのにも役立ちます。アプリケーションの使用範囲と影響が広がるほど、責任ある AI のフレームワークに従うことがより重要になります。したがって、 AI の責任ある使用 について、AI の取り組みの早い段階からそのライフサイクル全体を通じて考慮し、対処することが重要です。 機械学習の責任ある使用のためのフレームワークについてさらに学ぶには、以下のリソースを参照してください。 機械学習の責任ある利用（英語） AWS 生成 AI ベストプラクティスフレームワーク v2 ヒューマンインザループを用いた生成 AI プロンプトのチェーン化のワークフロー（英語） 基盤モデル評価のライブラリ（英語） 著者について Laura Verghote は、EMEA の公共部門のお客様向けのシニアソリューションアーキテクトです。複雑なビジネス要件と技術的ソリューションの橋渡しをしながら、AWS クラウドでソリューションの設計と構築をお客様と共に行っています。彼女は AWS に技術トレーナーとして入社し、EMEA 全域の開発者、管理者、アーキテクト、パートナーにトレーニングコンテンツを提供した幅広い経験を持っています。 Maria Lehtinen  は、北欧の公共部門のお客様向けのソリューションアーキテクトです。彼女は信頼できるクラウドアドバイザーとしてお客様と協力し、AI/ML ワークロードに重点を置いたクラウドシステムの開発と実装をサポートしています。彼女は AWS の早期キャリア専門家プログラムを通じて入社し、以前は AWS Advanced Consulting Partner の 1 社でクラウドコンサルタントとして勤務していました。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

AWS Backup は、AWS サービス全体のデータのバックアップを一元化し、自動化するフルマネージドバックアップサービスです。一元管理された AWS クラウドネイティブのソリューションは、ディザスタリカバリやコンプライアンス要件を満たすのに役立つグローバルなバックアップ機能を提供します。 AWS Backup は、Amazon EC2 上で動作する SAP HANA データベース向けに、シンプルでコスト効率が高く、アプリケーションに一貫性のあるバックアップとリストアのソリューションを提供します。前回の AWS Backup for SAP HANA データベースでは、Amazon EC2 上の SAP HANA High Availability データベースをサポートしました。私たちはお客様のニーズに応えるために革新を続け、AWS Backup for SAP HANA データベースが クロスリージョン と クロスアカウント バックアップ をサポートし、AWS のお客様が SAP HANA データベースのバックアップを異なるリージョンやアカウントにコピーできるようになったことを発表できることをうれしく思います。この新機能により、コピーしたバックアップをリストアしたり、必要に応じて クロスリージョン コピーや クロスアカウント コピーを作成したりすることができ、ディザスタリカバリや事業継続の要件を満たすことができます。スナップショットコピーは、ソースアカウントが偶発的または悪意のある削除、災害、ランサムウェアによって中断された場合に、追加の保護レイヤーを提供します。 はじめに このブログでは、オンデマンドバックアップをトリガーとして AWS Backup を使用して SAP HANA データベースのクロスリージョンおよびクロスアカウント バックアップ コピーを実行する方法を示します。 ここに 記載されているすべての手順に従って、すべての 前提条件 と AWS Backup 設定プロセスを完了します。次のステップに進む前に、SAP HANA リソースの保護を オプトイン します。前述の手順が完了したら、以下の手順に従って、ソースリージョンの SAP HANA データベースのオンデマンド バックアップを取ります。 1.  AWS Backup コンソールにアクセスします。 2. Dashboard をクリックし、 Create on-demand Backup を選択します。　 3. Resource type として SAP HANA on Amazon EC2 を選択し、SAP HANA database ID を選択します。　 Backup window 、 Cold Storage 、および Total retention period はデフォルト値のままにしておくか、要件に応じて調整します。 Backup vault は、デフォルトのものを選ぶか、すでにあれば専用のものを使います。 IAM ロールには、AWS Backup がお客様に代わってバックアップを作成・管理する際に想定する IAM ロールを指定し、ページ下部の Create on-demand backup をクリックします。 4. ジョブのステータスを示す画面が自動的に開きます。 ジョブが Completed ステータスになる前に、 Pending と Running のステータスを通過します。ジョブのステータスが Completed になるまで待ちます。 2～4 の手順を繰り返し、TenantDB のバックアップを取ります。 クロスリージョン コピー 5. Backup vaults を選択し、コピーするリカバリ ポイントが含まれるボールトを選択します。 6. Recovery points で、コピーするリカバリポイントを選択します。 7. Action のドロップダウンボタンを使用して、 Copy を選択します。 8. Copy Configuration でコピー先の AWS リージョンを選択し、 Destination Backup vault でコピー先のバックアップボールトを選択します。 (このデモでは、コピー先の AWS リージョンとして Sydney を使用します。） Cold storage と Total retention period はデフォルト値のままにしておくか、要件に応じて調整してください。 IAM ロールについては、AWS Backup がお客様に代わってバックアップを作成・管理する際に想定する IAM ロールを指定し、ページ下部の Create on-demand backup  をクリックします。 9. 一番下の Copy をクリック 10. ジョブ ステータスの画面が自動的に開くので、ステータスが Completed になるまで待ちます。 ステップ#6-9を繰り返して、TenantDB のリカバリポイントを宛先リージョンにコピーします。 また、AWS のドキュメント Scheduling Cross-Region backup で説明されているように、スケジュールされたバックアッププランを使用して、AWS リージョン間でバックアップをコピーすることもできます。 11. コピー先リージョンの AWS Backup コンソールにアクセスします。 12. Backup vaults  を選択し、ソースリージョンからコピーしたリカバリポイントを含むデータボールトを選択します。 13. ソースリージョンからコピーしたリカバリポイントがここにあることを確認します。 HANA データベースのリストア 以下のステップでは、コピー元リージョンからコピーしたリカバリポイントを使用して、コピー先リージョンで既存の HANA データベースのリストアを実行します。 14. SystemDB のリカバリポイント ID を 選択し 、Actions ドロップダウンから Restore を選択します。 15. 次の画面の Target database restore location で 、ソースリージョンからのコピーで上書きする SAP HANA データベースの SystemDB を選択します。 また、次のような警告も表示されます。システムコピーを実行しているときに、ターゲットデータベースに復元するソースデータベースを許可リストに追加するリソースポリシーをアタッチするように求められます。 16. Copy をクリックし、AWS CLI を使用してターゲットの SAP HANA データベースでコマンドを実行します。 17. Advanced restore settings で Don’t restore the catalog を選択し、 Restore backup をクリックします 。 . 18. 次の画面で、ボックスに overwrite と入力します。 19.ジョブステータスの画面が自動的に開くので、ステータスが Completed になるまで待ちます。 手順 #14～18 を繰り返し、TenantDB のリストアを実行します。 注：リソースポリシーをアタッチして、ターゲットデータベースに復元するソースデータベースを許可リストに追加するコマンドは、TenantDB の復元によって異なります。 クロスアカウントのバックアップとリストア このセクションでは、 AWS Backup を使用して SAP HANA データベースのクロスアカウントバックアップとリストアを実行する方法について説明します。ソースアカウントは、AWSリソースとプライマリバックアップが存在するアカウントです。宛先アカウントは、バックアップのコピーを保存するアカウントです。 SAP HANA バックアップのクロスアカウント コピーを有効にする手順 以下の手順に従って、SAP HANA バックアップのクロスアカウント コピーを有効にします。詳細なドキュメントについては、 Setting up Cross-Account backup を参照してください。 1.Management Account in AWS Organizations の管理アカウント 管理アカウントは、AWS Organizations で定義されている組織内のプライマリアカウントで、AWS アカウント全体のクロスアカウント バックアップを管理するために使用します。 a.   AWS Organizations にアクセスし、AWS 組織で管理アカウントを作成します。 b. ソースアカウントとデスティネーションアカウントを AWS Organizations の一部として追加します。このシナリオでは、ソースアカウントが管理アカウントになります。 c. ソースアカウントとデスティネーションアカウントが結合されていることを確認します。 2. AWS Backup コンソールでクロスアカウント バックアップを有効にする 以下の手順に従って、クロスアカウント バックアップを使用するには、ソースアカウントでクロスアカウント バックアップ機能を有効にする必要があります。 a. AWS Organizations 管理アカウントの認証情報を使用してログインします。クロスアカウント バックアップは、これらの資格情報を使用してのみ有効または無効にできます。 b.  AWS Backup console でクロスアカウントバックアップを有効にします。 c. My account で Settings を選択します。 d.  Cross-Account management の Cross-Account backup で、 Enable を選択します。Cross-Account backup Status が On になっていることを確認します。 3. デスティネーションボールト アクセスポリシーを有効にする a. デスティネーションアカウントで AWS Backup console に移動します。 b. Backup vaults で、宛先データボールトを選択します。 c. Access policy セクションで、  Add permissions を選択して  Allow access to a Backup vault from organization を選択します。 backup:CopyIntoBackupVault 以外のクロスアカウント アクションは拒否されます。 d. 次の画面 “Add permissions: Allow access to a Backup vault from organization”  で、 Save policy を選択し ます。 バックアップとリストアのクロスアカウントコピーのために実行するステップ この例では、すでにソースアカウントで  HANA SystemDB と TenantDB の両方のオンデマンドバックアップが成功しています。また、AWS ドキュメントの Scheduling Cross-Account backup にあるように、スケジュールされたバックアッププランを使用して、AWS アカウント間でバックアップをコピーすることもできます。以下の手順に従って、ソースアカウントから宛先アカウントへのオンデマンド HANA データベースバックアップのクロスアカウント コピーを実行します 1. ソースアカウントで、 AWS Backup console にコンソールに移動します。 2. Backup vaults でバックアップ元のバックアップボールトを選択します。SAP HANA データベース SystemDB バックアップの Recovery point ID を選択します。 Actions で Copy をクリックします。 3. 次の画面で、 Copy Configuration の下に、宛先アカウントの リージョン を 指定します。 4. Copy to another account’s vault オプシ ョ ンを設定し、 移動先ア カ ウ ン ト のデー タ ボールトの ARN を指定し ます。 ま た、 Allow Backup vault access で  Allow を ク リ ッ ク し てセカンダ リ ア カ ウ ン ト にバ ッ ク ア ッ プボールトへのバ ッ ク ア ッ プの コ ピーを許可 し ます。 5. Allow Backup vault access? の下にある新しいポップアップ画面で、 Allow をクリックして、バックアップ データをバックアップ データボールトにコピーするために必要なアクセス許可をアクセス ポリシーに与えます。 6. “Backup recovery has been enabled in your corresponding backup vault” というメッセージが表示されます。 7. IAMロールの下で Choose an IAM role を選択します。お客様に代わってバックアップを作成および管理する際に AWS Backup が引き受ける IAM ロールを指定します。 8. Backup details を確認します 。Copy をクリックします。 9. ジョブのステータスが表示される画面が自動的に開き、SystemDB のコピージョブが In-progress で、statusが Running に変わっていることがわかります。status が Completed になるまで待ちます。 上記のステップ#4-12 を繰り返して、TenantDB のコピーを実行します。以下のように、両方のコピージョブが正常に完了したことがわかります。 10. 保存先アカウントに切り替え、 AWS Backup console に移動します。 11. Backup vaults で、 宛先データボールト選択します。バックアップのリカバリポイント ID がソースアカウントから宛先アカウントにコピーされていることがわかります。 12. リストア手順を続行する前に、宛先アカウントの HANA データベースが HDB stop コマンドで停止していることを確認します。  sapcontrol コマンドで SAP プロセスのステータスを確認し、  hdbdaemon のステータスが  ‘GRAY’ および  ‘Stopped’ であることに注意してください。 注： AWS Systems Manager for SAP の新しくリリースされた Start/Stop 機能を使用して、HANA データベースシステムを開始/停止することもできます。 13. コピー先アカウントの AWS Backup console で、コピーした HANA データベースの SystemDB バックアップの Recovery point ID を選択します。 Actions で Restore を選択します。 14. 次の画面 Restore SAP HANA backup で Target database restore location のドロップダウンで、ターゲットの HANA SystemDB をリストア先として選択します。 15. また、ターゲットデータベースにリストアするソースデータベースを許可するために、必要なリソースポリシーを追加する必要があります。 Copy を クリックして CLI コマンドをコピーし、添付します。 16. セカンダリアカウントの AWS CLI から、以下のようにコピーしたコマンドを実行し、必要なポリシーをアタッチします。 17. Restore SAP HANA バックアップ コンソールに戻り、 Restore 権限 を確認します。 18. Advanced restore settings で、 Don’t restore the catalog を選択し、 Restore backup をクリックします 。 19. Restore backup and overwrite database の下に overwrite と入力します。 Restore backup を選択します。 20. 以下のようにリストア作業が進行中であることがわかります。 21. SystemDB のリストアジョブの status が Completed と表示されたら、TenantDB のリストアを実行します。手順#14-21を繰り返して、TenantDB のリストアを実行します。TenantDB のリストアジョブの status が Completed になっていることを確認します。 注：リソースポリシーをアタッチして、ターゲットデータベースに復元するソースデータベースを許可リストに追加するコマンドは、TenantDB の復元によって異なります。 22.  EC2 コンソールに 移動し、 AWS Session manager を使用して、デスティネーションアカウントのHANAデータベースにログインします。 <sid>adm ユーザーでログインし、 sapcontrol  コマンドで SAP プロセスのステータスを確認します。HANA SystemDB と TenantDB データベースが正常にリストアされ、すべてのプロセスが以下のように GREEN ステータスを表示していることを確認します。 まとめ このブログでは、AWS Backup サービスを使用して、クロスリージョンおよびクロスアカウントデータベースのバックアップとリストアを実行する方法を学びました。AWS Backup を使用して SAP HANA データベースのクロスリージョンおよびクロスアカウント バックアップ機能を使用すると、運用上またはセキュリティ上の理由から、組織内の 1 つまたは複数のリージョンまたはクロスアカウントにバックアップを安全にコピーすることができます。 月に請求されるクロスリージョンの金額は、2 つのリージョン間で転送されたデータ量であり、単一の AWSア カウント内または 2 つの AWS アカウントにまたがって転送されたデータ量です。AWS リージョンからデータを転送する場合にのみデータ転送料金が発生し、同じ AWS リージョン内での転送には料金は発生しません。データ転送料金は、データを転送するAWS アカウントに請求されます。バックアップストレージの料金は、データを受け取る AWS アカウントに請求されます。バックアップボールトからのデータ転送の料金は同じです。 AWS Backup サービスを始めるには、以下のドキュメントとブログを確認することをお勧めします。 SAP HANA databases on Amazon EC2 instances backup Automate and Simplify SAP HANA Backups with AWS Backup Simplify SAP Backups with AWS Services SAP ワークロードの移行、モダナイゼーション、革新において AWS が何千ものお客様から信頼されている理由については、 SAP for AWS のページをご覧ください。 翻訳は SAP Specialist SA 菅谷が担当しました。原文は こちら です。