AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2023 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4615 )。AWS ブースでは「Create. Deliver. Monetize.」をテーマに、「コンテンツ制作」、「放送」、「メディアサプライチェーン & アーカイブ」、「Direct-to-Consumer & ストリーミング」、「データサイエンス & AI/ML」におけるクラウドを利用した重要なワークロードの運用をサポートする技術とソリューションを、パートナー 9 社とともにご紹介します。本ブログでは、AWS ブースで行われるブースセミナーの中から 5 つのステージ特別プログラムをご紹介させていただきます。 Inter BEE とは Inter BEE とは、日本随一の音と映像と通信のプロフェッショナル展として、コンテンツビジネスに関わる最新のイノベーションが国内外から集まる国際展示会です。アフターコロナ時代におけるメディア産業の新たなユーザエクスペリエンスを提示する展示会として、「コンテンツ」を中核に位置づけ、コンテンツを「つくる (制作) 」「おくる (伝送) 」「うける (体験) 」の技術要素を網羅した「メディア総合イベント」に変容することを目指し、開催します。 開催期間は、幕張メッセで 2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) 、オンライン会場で 2023 年 11 月 6 日 ( 月 ) 〜 2023 年 12 月 15 日 ( 金 ) となっています。 下のリンクから登録を行うことで、無料で参加することができます。 登録はこちらから ステージ特別プログラムのご紹介 [Create.] バーチャルプロダクションにおける AWS 活用 – 制作から撮影まで 株式会社スタジオブロス 上津原一利 様 11 月 15 日 ( 水 ) 12:20-13:00 バーチャルプロダクションの制作、確認、撮影など、様々なシーンでクラウド活用することによって各作業を効率的に進めることができます。スタジオブロスで実際に行ったクラウド活用の事例や、活用によって広がる可能性などお伝えいたします。 Create. Deliver. Monetize. Trends & Customer stories in the M&E Industry Amazon Web Services Shad Hashmi 11 月 15 日 ( 水 ) 16:30-17:10 メディア・エンターテインメント業界は革新の波に直面しており、AWS はコンテンツ制作、メディアサプライチェーン & アーカイブ、放送、Direct-to-Consumer とストリーミング、データサイエンス & 分析、5 つの分野でお客様のイノベーションを支えています。Create. Deliver. Monetize. の視点から、海外のメディア&エンターテインメント業界のトレンドと AWS を用いたお客様事例を紹介します。 [Create.] 目指せ! 収録→編集→アーカイブまで素材一元管理 TBS テレビコンテンツ制作局のこれまでの取り組み 株式会社 TBS テレビ 吉橋 隆雄 様 11 月 16 日 ( 木 ) 15:40-16:20 大量の過去の収録テープ素材を前にした放送局の制作部門スタッフが「円滑に過去素材を再利用できる環境の構築」と「働き方改革にともなう諸業務の効率化」を目的に、社内各部署を巻き込んで説得し、映像のデータ化 ⇒ クラウド化 ⇒ クラウドオフライン編集に挑戦するまでの道のりと今後の課題と展望について、関係者一同と共にフランクにお話します。 [Monetize.] ABEMA ライブイベント配信におけるパーソナライズ広告挿入について 株式会社 AbemaTV 古川 俊太 様 11 月 16 日 ( 木 ) 16:30-17:10 ABEMA ではリニア配信とビデオ配信に加えて、スポーツなどの試合に対応できるように新しく「ライブイベント」という放送形態を導入しました。 ライブイベントという放送形態を新規で導入したことにより、広告の配信システムも新規で開発する必要がありました。 今回、AWS MediaTailor をパーソナライズ基盤として選定しましたが、その経緯と現状、展望についてお話しいたします。 [Deliver.] NeSTREAM LIVE AWS を活用した DOLBY ATMOS での高臨場感ライブ配信事例の紹介 メモリーテック株式会社 棟元 裕介 様、株式会社クープ 近藤 貴春 様、Dolby Japan 株式会社 萩谷 太郎 様 11 月 17 日 ( 金 ) 12:20-13:00 近年、音楽ライブにおいて、Dolby Atmos での劇場上映や、パッケージ販売・配信する事例が増えています。 Dolby Atmos はバーチャライザー技術と併用することで、ホームシアターやヘッドホンなどの様々な民生機器で使用することができます。 これまでの制作事例を踏まえ、今後増えていくことが予想される Dolby Atmos でライブ配信の仕組みなどについてご紹介します。 ブースセミナーのプログラム こちらは、AWS のブースで行うセミナーのプログラムです。今回ご紹介したステージ特別プログラムの他にも、パートナーセッションや AWS ブース紹介が行われます。 終わりに 今回は、Inter BEE 2023 の AWS ブースセミナーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2023 の 公式サイト からご確認ください。 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは Solutions Architect 濵野が担当しました。

はじめに 今日の組織は、地域・業界、またビジネスニーズによって異なる、プライバシーや規制の課題に直面しています。これらのプライバシー規制を遵守するために、コンタクトセンターの管理者は、コンタクトセンター内で使用される機密リソースに対する最小アクセス権限の実装を頻繁に求められます。 Amazon Connect の タグベースのアクセスコントロール により、Amazon Connect 管理コンソール内で Amazon Connect リソースに対するより細かいアクセスコントロールを有効にできるようになりました。タグは Key:Value のペアで、役割、チーム、事業部門、その他の基準によって、Amazon Connect リソースへのアクセスを管理、検索、フィルタリング、制御することができます。一例をあげると、タグベースのアクセスコントロールによって、ある管理者にすべてのエージェントを完全に管理するアクセス権を付与しつつ、別の管理者ロールでは管理者が所属するビジネスユニット内のエージェントの表示と管理のみに制限することができます。 この記事では、まず Amazon Connect 管理コンソールによるリソースタグ付けをサポートするようになった追加の Amazon Connect リソースについて説明します。その後、架空の会社 Octank 社の管理者が特定の Amazon Connect リソースにタグを設定し、タグベースのアクセスコントロールでそれらのリソースへの最小権限でのアクセスを設定する方法を示します。 このソリューションは、コンタクトセンターの管理者、マネージャー、コンプライアンス関係者、ビジネスプロセスアウトソーサー (BPO) などの第三者に以下のような利点をもたらします。 ビジネスニーズに基づいて、リソースを論理的にグループ分けした並べ替えやフィルタリング 機密情報 (PII など) の意図しない利害関係者への共有を防止 ソリューション概要 このソリューションを展開するため、以下の手順を実施します。 アクセスコントロールタグおよびリソースタグを特定のリソースに設定する リソースタグとアクセスコントロールタグを自動的に設定する リソースタグとタグベースのアクセスコントロールを設定する前に、Octank 社の社内情報ガバナンスと業務要件を以下に示します。 ユーザー、ルーティングプロファイル、キューへのアクセスを制限する、3つのコンタクトセンター管理者ロールを作成する Country:Argentina のタグだけが付いたリソースにアクセスできるコンタクトセンターロール BPO:Octank のタグだけが付いたリソースにアクセスできるコンタクトセンターロール Country:Argentina および BPO:Octank 両方のタグが付いたリソースにアクセスできるコンタクトセンターロール 前提条件 このチュートリアルは、以下のリソースを理解し、アクセスできることを前提としています。 Amazon Connect の管理者アクセス権を持つ AWS アカウント 作成 済みのAmazon Connect インスタンス 管理者権限 (Admin) の セキュリティプロファイル を持つ Amazon Connect ユーザー AWS リソースのタグ付け に関する基本的な知識 タグ付けをサポートする Amazon Connect のリソース Amazon Connect のリソースにタグを付ける 既存の機能に加えて、Amazon Connect 管理コンソール内で設定するリソースにもタグを付けることができるようになりました。次の表は、管理コンソール内でタグをサポートするようになったリソースと、 API/CLI レベル でタグをサポートしているリソースを示しています。 Amazon Connect リソース Amazon Connect 管理コンソール内でのタグ付け可否 API/CLI 経由のタグ付け可否 User Management 可 可 Security Profiles 可 可 Routing Profiles 可 可 Queues 可 可 Flows 不可 可 Hierarchy Groups 不可 可 Hours of Operation 不可 可 Quick Connects 不可 可 Prompts 不可 可 Instances 不可 可 Task Templates 不可 可 Phone Numbers 不可 可 Traffic Distribution Groups 不可 可 Agent Status 不可 可 アクセスコントロールタグとリソースタグを設定するチュートリアル 最初のセクションでは、最初に アクセスコントロールタグ と リソースタグ を使用してセキュリティプロファイルを設定することで、Amazon Connect 管理コンソール内でリソースタグを設定する方法について説明します。次のセクションでは、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定する手順について説明します。最後のセクションでは、サンプルユーザーを使用してアクセス制御されるさまざまなセキュリティプロファイルを変更およびテストして、より細かいアクセスコントロールを検証する方法について説明します。 アクセスコントロールタグとセキュリティープロファイルの設定 このセクションでは、より細かいアクセスコントロールを持つ 3 つのセキュリティプロファイルを作成して、Amazon Connect 管理コンソール内でセキュリティプロファイルに対してアクセスコントロールタグとリソースタグの両方を設定する方法について説明します。 Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から セキュリティプロファイル を選択します 新しいセキュリティプロファイルの追加 を選択します 名前 と 説明 を入力します。ここではセキュリティプロファイルの名前を tagsecurityprofile1 とします。 セキュリティプロファイルのアクセス権限を選択します。下記画像のようにルーティングプロファイル、キュー、ユーザー、セキュリティプロファイルの各行で「すべて」を選択します 詳細オプションの表示 をクリックし、展開します アクセスコントロール の項目で、 リソース にユーザー、ルーティングプロファイル、キューを選択、 タグ のキーに Country 、値に Argentina を入力し、追加をクリックします タグの項目で、任意のリソースタグを入力し、追加をクリックします（画像の例では Createdby:ABC と入力) 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります 同様の手順で、セキュリティプロファイル tagsecurityprofile2 と tagsecurityprofile3 を以下の表に記載のプロファイルの 名前 、アクセス権限、アクセスコントロール リソース 、アクセスコントロール タグ 、リソース タグ の通り作成します セキュリティプロファイルの名前 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ リソースタグ tagsecurityprofile1 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina Createdby: ABC tagsecurityprofile2 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー BPO:Octank Createdby: ABC tagsecurityprofile3 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina, BPO:Octank Createdby: ABC 以上が完了すると、次のアクセスコントロールタグが設定済みの 3 つのセキュリティプロファイルが作成されます。 アクセスコントロールタグ Country:Argentina が設定された tagsecurityprofile1 アクセスコントロールタグ BPO:Octank が設定された tagsecurityprofile2 アクセスコントロールタグ Country:Argentina と BPO:Octank が設定された tagsecurityprofile3 これらのセキュリティプロファイルを使用して、Octank のデータガバナンスとビジネス要件を適用できます。これについては、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定した後で説明します。 リソースタグとユーザーの設定 このセクションでは、Amazon Connect 管理コンソール内でユーザーを設定し、リソースタグを適用する方法について説明します。サブ管理者権限と詳細なアクセス制御を適用したユーザーを 1 人作成し、表示/管理する 3 つのエージェントを作成します。ログインに tagadmin 、 taguser1 、 taguser2 、 taguser3 という名前を付けます。最後に、ルーティングプロファイル、セキュリティプロファイル、リソースタグを以下のように設定します。 ログイン 名 姓 ルーティングプロファイル セキュリティプロファイル リソースタグ 1 リソースタグ 2 tagadmin Admin Tag Basic Routing Profile tagsecurityprofile1 taguser1 Test1 Tag Basic Routing Profile Agent Country:Argentina taguser2 Test2 Tag Basic Routing Profile Agent BPO:Octank taguser3 Test3 Tag Basic Routing Profile Agent Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ユーザー管理 を選択します 新しいユーザーの追加 を選択します ユーザーを手動で追加 を選択します 名 、 姓 、 ログイン 、 セキュリティプロファイル 、 ルーティングプロファイル を上記表のサンプルの通りに各ユーザーに設定します。別途、メールアドレスとパスワードを各ユーザーに設定する必要があります 管理者を作成する際はスキップできますが、エージェントを作成する際には次の手順が必要です。 詳細設定を表示 をクリックし、キーと値を上の表の例の通り入力、 追加 します 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります。 この手順を繰り返し、副管理者 ( tagadmin )および 3 つのエージェント( taguser1 , taguser2 , taguser3 )のアカウントを作成します 完了すると、tagadmin という名前の副管理者が 1 人と、次のリソースタグが設定された 3 人のエージェントが作成されます。 リソースタグ Country:Argentina が設定された taguser1 リソースタグ BPO:Octank が設定された taguser2 リソースタグ Country:Argentina と BPO:Octank が設定された taguser3 リソースタグとキューの設定 このセクションでは、Amazon Connect 管理コンソールでキューのリソースタグを設定する方法について説明します。 以下のように、稼働時間とリソースタグを含む tagqueue1 、 tagqueue2 、 tagqueue3 の 3 つのキューを作成します。 キューの名前 オペレーション時間 リソースタグ 1 リソースタグ 2 tagqueue1 Basic Hours Country:Argentina tagqueue2 Basic Hours BPO:Octank tagqueue3 Basic Hours Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ルーティング から キュー を選択します キューを追加 を選択します キューの 名前 (例: tagqueue1 ) 、 説明 を入力します。 オペレーション時間 は、Basic Hours を選択します 設定 から タグ の項目で、以下の画像のようにタグを入力し、 追加 します 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagqueue2 および tagqueue3 も作成します 上の手順が完了すると、以下の通りリソースタグが設定された 3 つのキューが作成されます。 リソースタグ Country:Argentina が設定された tagqueue1 リソースタグ BPO:Octank が設定された tagqueue2 リソースタグ Country:Argentina と BPO:Octank が設定された tagqueue3 ルーティングプロファイルとリソースタグの設定 このセクションでは、Amazon Connect 管理コンソールでルーティングプロファイルのリソースタグを設定する方法について説明します。 次に、以下に説明するように、 音声チャネル 、 デフォルトのアウトバウンドキュー 、およびリソース タグ を使用して、 tagroutingprofile1 、 tagroutingprofile2 、 tagroutingprofile3 という名前の 3 つのルーティングプロファイルを作成します。 ルーティングプロファイルの名前 選択するチャネル デフォルトのアウトバウンドキュー リソースタグ 1 リソースタグ 2 tagroutingprofile1 音声 BasicQueue Country:Argentina tagroutingprofile2 音声 BasicQueue BPO:Octank tagroutingprofile3 音声 BasicQueue Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ルーティングプロファイル を選択します ルーティングプロファイルを追加 を選択します ルーティングプロファイルの 名前 (例: tagroutingprofile1 )と 説明 を入力します 設定 セクション内の チャネルの設定 で音声を選択、 キュー のセクションは変更せず、 デフォルトのアウトバウンドキュー で BasicQueue を選択します タグについては、以下のようにキー、値の組み合わせを設定し、 追加 をクリックします 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagroutingprofile2 および tagroutingprofile3 も作成します 完了すると、次のリソースタグの付いた 3 つのルーティングプロファイルが作成されます。 リソースタグ Country:Argentina が設定された tagroutingprofile1 リソースタグ BPO:Octank が設定された tagroutingprofile2 リソースタグ Country:Argentina と BPO:Octank が設定された tagroutingprofile3 ここまででユーザー、キュー、ルーティングプロファイルのリソースタグを設定し、アクセス制御とリソースタグを使用してセキュリティプロファイルを設定しました。次のセクションで、サブ管理者の tagadmin が持つ詳細なアクセスを検証できます。 アクセスコントロールの確認 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した副管理者アカウント tagadmin でサインインします ユーザー から ユーザー管理 を選択します。キーがCountry、値がArgentinaのリソースタグを含んだユーザーだけが表示されます。具体的には、 taguser1 と taguser3 が表示されます ルーティング から キュー を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagqueue1 と tagqueue3 が表示されます ユーザー から ルーティングプロファイル を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagroutingprofile1 と tagroutingprofile3 が表示されます 補足 セキュリティプロファイルを作成、変更し、アクセス制御タグを追加すると、より制限が厳しくなります セキュリティプロファイルがユーザーに割り当てられるまで、アクセス制御タグは適用されません アクセスコントロールの変更と確認 次に、サブ管理者ユーザ ( tagadmin ) のセキュリティプロファイルを変更し、付与されたアクセス権を確認しましょう。手順は以下の通りです。 Amazon Connect 管理コンソールにサインインします ユーザー から ユーザー管理 を選択します ユーザー tagadmin を選択し、 編集 をクリックします ユーザー tagadmin のセキュリティプロファイル を、 tagsecurityprofile1 から tagsecurityprofile2 に変更します。ドロップダウンメニュー内に「アクセスコントロール: タグ」の表示を確認できます 保存 をクリックします 副管理者のアカウント(ユーザー tagadmin )でログインしているシークレットモードのウィンドウを再読み込みします。タグ BPO:Octank が含まれているユーザー、キュー、ルーティングプロファイルのみにアクセスできるはずです。つまり、ユーザー tagadmin から、ユーザー taguser2 と taguser3 、キュー tagqueue2 と tagqueue3 、ルーティングプロファイル tagrouringprofile2 と tagroutingprofile3 が確認できます 最後にユーザー tagadmin のセキュリティープロファイルを tagsecurityprofile2 から tagsecurityprofile3 に変更して、権限を確認します。タグ Country:Argentina と BPO:Octank の両方が付与されたユーザー、キュー、ルーティングプロファイルだけにアクセスできるはずです。ユーザー tagadmin からは、ユーザー taguser3 、キュー tagqueue3 とルーティングプロファイル tagroutingprofile3 のみが確認できます Amazon Connect API や SDK を利用したより詳細なアクセス制御の設定 Amazon Connect API を使用して、Amazon Connect リソースに対するより詳細なアクセス制御をプログラムで設定できます。 Create Security profile API によりリソースタグとアクセスコントロールタグを使用してセキュリティプロファイルを作成できます Create User API によりタグ付きのユーザーを作成できます Create Routing Profile API によりタグ付きのルーティングプロファイルを作成できます Create Queues API によりタグ付きのキューを作成できます クリーンアップ Amazon Connect 管理コンソールにログインし、このブログの手順で作成した ユーザーを削除 します このブログのハンズオンの為に Amazon Connect インスタンスをセットアップした場合は、Amazon Connect AWS コンソールにアクセスして Amazon Connect インスタンスを削除 できます 結論 このブログでは、Amazon Connect のリソースタグとアクセスコントロールタグを使用して Amazon Connect リソースへのきめ細かなアクセスコントロールを可能にする方法を説明しました。これにより Amazon Connect インスタンスの運用中に要件が変化したときに、チーム、ロール、またはその他の基準で複数のグループを作成し、さまざまな Amazon Connect リソースに対してより複雑なアクセスコントロール条件を表現することができます。 無料のオンラインイベント、AWS Contact Center Day もご覧ください。カスタマーサービスの未来、機械学習がどのように顧客とエージェントのエクスペリエンスを最適化できるかなどについて学ぶことができます。 今すぐ登録 ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 著者について Dilin Joy Dilin Joy は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Behrang KHAKISEDDIGH Behrang KHAKISEDDIGH は、 AWS のシニアパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Mike Cairns Mike Cairns は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Tommy Grahams Tommy Graham は、 AWS の技術担当のシニアプロダクトマネージャーです。彼は顧客と協力し課題の解決策を見極め、データ主導の意思決定で業務を楽しんで推進しています。 追加のリソース Amazon Connect 概要 Amazon Connect でセキュリティプロファイルのより詳細なアクセス制御 (リソースタグを使用) が可能に Amazon Connectのリリースノート Amazon Connect 管理者ガイド Amazon Connectのパートナー タグベースのアクセス制御 Amazon Connect API Reference (英文) 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

Amazon Redshift は、クラウドにおけるフルマネージド型のペタバイト規模のデータウェアハウスサービスであり、他のどのクラウドデータウェアハウスよりも 最大 5 倍優れたコストパフォーマンス を実現し、追加費用なしですぐにパフォーマンスの革新的な向上を実現できます。 何万ものお客様が Amazon Redshift を使用して毎日エクサバイト単位のデータを処理し、分析ワークロードを強化しています。 この記事では、Amazon Redshift SYS モニタリングビューについて説明し、Amazon Redshift のワークロードとリソース使用量のモニタリングを簡素化する方法について説明します。 SYS モニタリングビューの概要 SYS モニタリングビューは Amazon Redshift のシステムビューで、プロビジョニングされたクラスターやサーバーレスワークグループのクエリとワークロードのリソース使用状況をモニタリングするために使用できます。 これらには次の利点があります: クエリの状態、パフォーマンス指標、クエリの種類を考慮して、機能の整合性に基づいて分類されています パフォーマンスのトラブルシューティングに役立つように、 planning_time 、 lock_wait_time 、 remote_read_io 、 local_read_io などの新しいパフォーマンスメトリクスを導入しました Redshift の オプティマイザで書き直されたクエリの代わりに、ユーザーが送信したクエリをログに記録することで、モニタリングビューの使いやすさが向上しています 少ないビューでより多くのトラブルシューティングメトリクスを提供できます プロビジョニングされたクラスターでもサーバーレスワークグループでも同じクエリを使用できるため、Amazon Redshift の統合的なモニタリングが可能になります では、いくつかのSYS モニタリングビューの機能と、それらをモニタリングにどのように使用できるかを見ていきましょう。 さまざまなクエリレベルのモニタリングメトリクスを統合 次の表は、複数のシステムテーブルとビューをクエリすることで得られるさまざまなメトリクスと情報を、一つのSYSモニタリングビューにどのように統合できているかを示しています STL/SVL/STV 得られる情報 SYS モニタリングビュー ビューのカラム STL_QUERY クエリの消費合計時間, クエリ名の短縮系, ユーザーID, トランザクションID, セッションID,クエリのステータス, データベース名 SYS_QUERY_HISTORY user_id query_id query_label transaction_id session_id database_name query_type status result_cache_hit start_time end_time elapsed_time queue_time execution_time error_message returned_rows returned_bytes query_text redshift_version usage_limit compute_type compile_time planning_time lock_wait_time STL_WLM_QUERY キュー滞在時間, 実行合計時間 SVL_QLOG キャッシュの使用 STL_ERROR エラーコード、エラーメッセージ STL_UTILITYTEXT SELECT以外のSQL STL_DDLTEXT DDLステートメント SVL_STATEMENTEXT 全てのタイプのSQLステートメント STL_RETURN 結果の行数とバイト STL_USAGE_CONTROL クエリによって到達した使用制限 ID のリスト STV_WLM_QUERY_STATE WLMの現在の状態 STV_RECENTS 現在実行中であるか完了しているクエリ STV_INFLIGHT 実行中のクエリ SVL_COMPILE コンパイル SYS から STL/SVL/STV へのマッピングに関する追加情報については、 SYS モニタリングビューへの移行 を参照してください。 ユーザークエリレベルのロギング クエリのパフォーマンスを向上させるために、Redshift クエリエンジンはユーザーが送信したクエリを書き換えることができます。 ユーザーが送信したクエリの ID は、書き換えられたクエリの ID とは異なります。 この記事では、ユーザーが送信したクエリを 親クエリ 、書き直したクエリを 子クエリ と呼びます。 次の図は、親クエリレベルと子クエリレベルでのロギングを示しています。 親クエリのIDは 1000 で、子クエリのIDは 1001、1002、1003 です。 クエリのライフサイクルのタイミング SYS_QUERY_HISTORY では、さまざまなクエリライフサイクルフェーズに関連する詳細な時間メトリクスを提供するために、カラムが拡張されています。 すべての時間はマイクロ秒単位で記録されることに注意してください。 次の表は、これらのメトリクスをまとめたものです。 タイムメトリクス 詳細 planning_time クエリを実行する前にクエリが費やした時間。通常、パース、分析、計画、書き換えなどのクエリライフサイクルフェーズが含まれます。 lock_wait_time 参照されている必要なデータベースオブジェクトのロックの取得にクエリが費やした時間。 queue_time リソースが実行可能になるまで、クエリがキュー内で待機していた時間。 compile_time クエリのコンパイルにかかった時間。 execution_time クエリの実行にかかった時間。 SELECT クエリの場合、これには結果が返ってくるまでの時間も含まれます。 elapsed_time クエリ実行の開始から終了までの時間。 ソリューションの概要 SYS モニタリングビューに慣れるために、以下のシナリオについて説明します: ワークロードとクエリのライフサイクルのモニタリング データ取り込みモニタリング 外部クエリのモニタリング クエリのパフォーマンスが遅い場合のトラブルシューティング 前提条件 この投稿の例に従うには、以下を事前に準備する必要があります: AWS アカウント プロビジョニングされた Redshift クラスター (現在のトラック) または Amazon Redshift Serverless エンドポイント 加えて、この記事で参照されているすべての SQL クエリを Redshift クエリエディタ v2 SQL ノートブックとして ダウンロード してください。 ワークロードとクエリのライフサイクルのモニタリング このセクションでは、ワークロードとクエリのライフサイクルをモニタリングする方法について説明します。 実行中のクエリを識別 SYS_QUERY_HISTORY では、実行中のすべてのクエリと実行履歴を一元的に確認できます。 次のクエリの例を参照してください: SELECT * FROM sys_query_history WHERE status IN ( 'planning' , 'queued' , 'running' , 'returning' ) ORDER BY start_time ; SQL 次の結果になります。 実行時間の長い上位クエリを特定 次のクエリは、実行に最も時間がかかる上位 100 件のクエリを取得するのに役立ちます。 これらのクエリを分析 (可能であれば最適化) することで、全体的なパフォーマンスを向上させることができます。 これらのメトリクスは、すべての実行されたクエリを累積した統計値です。 時間の値はすべてマイクロ秒単位であることに注意してください。 --top long running query by elapsed_time SELECT user_id , transaction_id , query_id , database_name , query_type , query_text:: VARCHAR ( 100 ) , lock_wait_time , planning_time , compile_time , execution_time , elapsed_time FROM sys_query_history ORDER BY elapsed_time DESC LIMIT 100 ; SQL 次の結果になります。 クエリの種類、期間、ステータス別に毎日のクエリ数を収集 次のクエリは、さまざまなタイプのクエリが各日にどのように分布しているかを把握し、ワークロードの変化を評価して追跡するのに役立ちます: --daily breakdown of workload by query types and status SELECT DATE_TRUNC ( 'day' , start_time ) period_daily , query_type , status , COUNT ( * ) FROM sys_query_history GROUP BY period_daily , query_type , status ORDER BY period_daily , query_type , status ; SQL   次の結果になります。 実行中のクエリの実行詳細を収集する 実行中のクエリの実行レベルの詳細を確認するには、 SYS_QUERY_DETAIL テーブルをクエリするときに is_active = 't' フィルタを使用できます。 次の例を参照してください: SELECT query_id , child_query_sequence , stream_id , segment_id , step_id , step_name , table_id , coalesce ( table_name , '' ) || coalesce ( source , '' ) as table_name , start_time , end_time , duration , blocks_read , local_read_io , remote_read_io FROM sys_query_detail WHERE is_active = 't' ORDER BY query_id , child_query_sequence , stream_id , segment_id , step_id ; SQL 実行された最新の 100 個の COPY クエリを表示するには、次のコードを使用します: SELECT session_id , transaction_id , query_id , database_name , table_name , data_source , loaded_rows , loaded_bytes , duration / 1000.00 duration_ms FROM sys_load_history ORDER BY start_time DESC LIMIT 100 ; SQL 次の結果になります。 コミットとその取り消しに対するトランザクションレベルの詳細の収集 SYS_TRANSACTION_HISTORY は、コミットされたブロック、ステータス、分離レベル ( SERIALIZABLE または SNAPSHOT ISOLATION ) などの詳細とともに、コミットされたトランザクションに関するインサイトを提供することにより、トランザクションレベルのロギングを提供します。 また、ロールバックまたは取り消しトランザクションの詳細も記録されます。 次のスクリーンショットは、正常にコミットされたトランザクションについての詳細情報を取得する方法を示しています。 次のスクリーンショットは、ロールバックされたトランザクションについての詳細情報を取得する方法を示しています。 統計情報とバキューム SYS_ANALYZE_HISTORY モニタリングビューには、分析クエリの最終タイムスタンプ、特定の分析クエリの実行時間、テーブル内の行数、変更された行数などの詳細が表示されます。 次のクエリ例は、すべての永続テーブルに対して実行された最新の分析クエリのリストを提供します: SELECT TRIM ( schema_name ) schema_name , TRIM ( table_name ) table_name , table_id , status , COUNT ( * ) times_analyze_was_triggered , MAX ( last_analyze_time ) last_analyze_time , MAX ( end_time ) end_time , AVG ( ROWS ) "rows" , AVG ( modified_rows ) modified_rows FROM sys_analyze_history WHERE status != 'Skipped' GROUP BY schema_name , table_name , table_id , status ORDER BY schema_name , table_name , table_id , status , end_time ; SQL 次の結果になります。 SYS_VACUUM_HISTORY モニタリングビューでは、バキュームに関するすべての詳細が 1 つのビューに表示されます。 たとえば、次のコードを参照してください: SELECT user_id , transaction_id , query_id , TRIM ( database_name ) as database_name , TRIM ( schema_name ) as schema_name , TRIM ( table_name ) table_name , table_id , vacuum_type , is_automatic as is_auto , duration , rows_before_vacuum , size_before_vacuum , reclaimable_rows , reclaimed_rows , reclaimed_blocks , sortedrows_before_vacuum , sortedrows_after_vacuum FROM sys_vacuum_history WHERE status LIKE '%Finished%' ORDER BY start_time ; SQL 次の結果になります。 データ取り込みのモニタリング このセクションでは、データ取り込みをモニタリングする方法について説明します。 取り込みの概要 SYS_LOAD_HISTORY は、COPY コマンドの統計に関する詳細を提供します。 このビューを使用すると、取り込みワークロードに関するインサイトをまとめることができます。 次のクエリ例は、データ取り込みが行われたテーブルごとに分類された、取り込みの概要を 1 時間ごとに示しています。 SELECT date_trunc ( 'hour' , start_time ) period_hourly , database_name , table_name , status , file_format , SUM ( loaded_rows ) total_rows_ingested , SUM ( loaded_bytes ) total_bytes_ingested , SUM ( source_file_count ) num_of_files_to_process , SUM ( file_count_scanned ) num_of_files_processed , SUM ( error_count ) total_errors FROM sys_load_history GROUP BY period_hourly , database_name , table_name , status , file_format ORDER BY table_name , period_hourly , status ; SQL 次の結果になります。 ファイルレベルの取り込みログ SYS_LOAD_DETAIL は、ファイルレベルでの取り込み処理に関するより詳細なインサイトを提供します。 例としては、 sys_load_history を使用した次のクエリを参照してください: SELECT * FROM sys_load_history WHERE table_name = 'catalog_sales' ORDER BY start_time ; SQL 次の結果になります。 次の例は、詳細なファイルレベルのモニタリングがどのようなものかを示しています。 SELECT user_id , query_id , TRIM ( file_name ) file_name , bytes_scanned , lines_scanned , splits_scanned , record_time , start_time , end_time FROM sys_load_detail WHERE query_id = 1824870 ORDER BY start_time ; SQL     取り込みプロセス中のエラーをチェック SYS_LOAD_ERROR_DETAIL を使用すると、取り込みプロセス中に発生した可能性のあるエラーを追跡してトラブルシューティングできます。 このビューには、取り込み処理中にエラーが発生したファイルの詳細と、エラーが発生した行番号、およびその行内のカラムの詳細が記録されます。 次のコードを参照してください。 select * from sys_load_error_detail order by start_time limit 100 ; SQL 次の結果になります。 外部クエリのモニタリング SYS_EXTERNAL_QUERY_DETAIL は、 Amazon Redshift Spectrum やフェデレーテッドクエリを含む外部クエリの実行詳細を提供します。 このビューは、詳細をセグメントレベルで記録し、単一のモニタリングビューで外部クエリのトラブルシューティングとパフォーマンスのモニタリングに役立つインサイトを提供します。 このモニタリングビューが提供する有用なメトリクスとデータポイントは次のとおりです。 スキャンされた外部ファイル ( scanned_files ) の数と、Parquetやテキストファイルなどの外部ファイルのフォーマット ( file_format ) スキャンされたデータの行数 ( returned_rows ) とバイト数 ( returned_bytes ) 外部クエリとテーブルによるパーティショニング ( total_partitions と qualified_partitions ) の使用 特定の外部オブジェクトの一覧表示 ( s3list_time ) とパーティションスキャン ( get_partition_time ) にかかった時間の詳細なインサイト 外部ファイルの場所 ( file_location ) と外部テーブル名 ( table_name ) Redshift Spectrum 用の Amazon Simple Storage Service (Amazon S3) やフェデレーテッドクエリといった外部ソースのタイプ( source_type ) サブディレクトリの再帰スキャン ( is_recursive ) またはネストされた列データ型へのアクセス ( is_nested ) たとえば、次のクエリは、実行された外部クエリ数とスキャンされたデータ数の日次での概要を示しています。 SELECT DATE_TRUNC ( 'hour' , start_time ) period_hourly , user_id , TRIM ( source_type ) source_type , COUNT ( DISTINCT query_id ) query_counts , SUM ( returned_rows ) returned_rows , ROUND ( SUM ( returned_bytes ) / 1024 ^ 3 , 2 ) returned_gb FROM sys_external_query_detail GROUP BY period_hourly , user_id , source_type ORDER BY period_hourly , user_id , source_type ; SQL 次の結果になります。 パーティションの使用 大量のデータやファイルをスキャンする外部クエリがパーティション化されているかどうかを確認できます。 パーティションを使用する場合、パーティションキーに基づいて絞り込むことによって、外部クエリがスキャンする必要があるデータの量を制限できます。 次のコードを参照してください。 SELECT file_location , CASE WHEN NVL ( total_partitions , 0 ) = 0 THEN 'No' ELSE 'Yes' END is_partitioned , SUM ( scanned_files ) total_scanned_files , COUNT ( DISTINCT query_id ) query_count FROM sys_external_query_detail GROUP BY file_location , is_partitioned ORDER BY total_scanned_files DESC ; SQL 次の結果になります。 外部クエリでエラーが発生した場合は、 SYS_EXTERNAL_QUERY_ERROR を調べてください。 SYS_EXTERNAL_QUERY_ERROR には、そのファイル内の file_location 、 column 、および rowid のレベルで詳細が記録されます。 クエリのパフォーマンスが遅い場合のトラブルシューティング SYS モニタリングビューを使用したクエリレベルのトラブルシューティングを行うための、ステップバイステップのガイドとして、前提条件のセクションでダウンロードした sysview_slow_query_performance_troubleshooting SQL ノートブックがあります。これを参照して、次の質問に対する回答を探してください。 比較対象のクエリと、実行したクエリのクエリテキストは似ていますか ? クエリは結果キャッシュを使用していますか ? クエリのライフサイクル (キューイング、コンパイル、プランニング、ロック待機) のどの部分がクエリの実行時間に最も影響を与えていますか ? クエリプランは変更されましたか ? クエリは多くのデータブロックを読み込んでいますか ? クエリがディスク領域を使っていませんか？もしそうであればそれはローカルストレージですか、リモートストレージですか? データ (分散) と時間 (実行時間) の点で、大きく偏っているクエリですか ? ジョインまたはネストループで処理される行が増えていますか ? 統計情報が古くなっていることを示すアラートはありますか ? クエリに関係するテーブルに対して最後に VACUUM と ANALYZE が実行されたのはいつですか ? クリーンアップ Redshift のプロビジョニングされたクラスターまたは Redshift サーバーレスワークグループをこの記事のために作成し、ワークロードに対して必要なくなった場合は、それらを削除して追加コストの発生を防ぐことができます。 まとめ この記事では、Redshift SYS モニタリングビューを使用して、プロビジョニングされたクラスターとサーバーレスワークグループのワークロードをモニタリングする方法について説明しました。 SYSモニタリングビューでは、ワークロードのモニタリングが簡素化され、統一されたビューからさまざまなクエリレベルのモニタリング用のメトリクスにアクセスできます。また、プロビジョニングされたクラスターとサーバーレスワークグループの両方で、同じ SYS モニタリングビュークエリを使用できます。 また、SYS モニタリングビューを使用した主要なモニタリングおよびトラブルシューティングシナリオについても説明しました。 Redshift のワークロードには、新しい SYS モニタリングビューを使い始めることをお勧めします。 著者について Urvish Shah は Amazon Redshift のシニアデータベースエンジニアです。 彼はデータベース、データウェアハウス、アナリティクス分野で10年以上働いてきました。 仕事以外では、料理、旅行、娘との時間を楽しんでいます。 Ranjan Burman は AWS のアナリティクススペシャリストソリューションアーキテクトです。 Amazon Redshift を専門とし、お客様がスケーラブルなアナリティクスソリューションを構築できるよう支援しています。 彼はさまざまなデータベースおよびデータウェアハウステクノロジーで 16 年以上の経験があります。 クラウドソリューションによる顧客の問題の自動化と解決に情熱を注いでいます。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

11月27日(月)に無料ウェビナー AWS Purpose Built Database Webinar 「Amazon Aurora/RDS のコスト最適化」 を開催します。 本セッションでは、Amazon Aurora/RDS を長期間運用するにあたってのコスト最適化のポイントや、安定運用のコツについてご紹介します。本セッションは、以下の2部から構成されます。 「Amazon Aurora/RDS でのコストの最適化」のセッションでは、これまでのウェビナーで移行→コスト削減の話が多かったため、RDS長期・安定利用中のお客様向けのコスト削減をこのセッションで紹介し、それ以外にAurora Serverless v2やIO-Cost Optimization（New price model導入)の話も案内します。 「移行のベスト プラクティスとコストの最適化」のセッションでは、移行案件など、必要スペックが想定できているお客様へのコスト削減案を案内し、Tooling&Programもここで紹介します(DBFW/DMS・SCT/OLA)。 AWSマネージドデータベースサービスの運用とコスト削減に興味がある方は是非ご参加ください。 アジェンダ ※当日の進行により、時間割が若干変更となる場合がございます。 時間 プログラム 講師 14:00-14:30 Amazon Aurora/RDS でのコストの最適化 木村 達也 14:30-15:00 移行のベスト プラクティスとコストの最適化 小沢 亮太 開催場所 当日は下記のZoomにアクセスし、Meeting IDを入力してウェビナーにご参加ください。 https://zoom.us/join Meeting ID: 81462473492 Passcode: 357768 講師プロフィール 木村 達也 データ事業本部 ポートフォリオスペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 製造、通信、メディア業界のお客様に対するデータベースの課題解決支援に従事しています。 小沢 亮太 パブリックセクター技術統括本部 パートナーソリューションアーキテクト 前職では外資系データベースベンダーにて、データベースのサポート・プリセールスを行なってきました。AWSでは、パートナーソリューションアーキテクトとして、パートナー様が悩まれているデータベースの移行について、勉強会やソリューションをご案内しています。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 10月もまもなく終わりですね。11月にさしかかると、常に意識に上がってくるのはAWSの世界最大の学習型カンファレンス、 AWS re:invent 2023 ですね。たくさんのサービスアップデートや先進的な事例が発表されますイベントですので、是非チェックしてください。キーノートと一部のコンテンツはオンラインで無料で視聴いただくこともできます。 そして毎年恒例のAWS BlackBelt Online Seminarのre:Inventまとめ回ですが、今年も配信いたします。日本時間で12/1のお昼休み、12:00-13:00に可能な限り全てのサービスアップデートをざっくりとご紹介します。無料でご参加いただけますが、こちらもお申し込みが必要になります。（10/30 17時頃追記： 申込みページ できました！） それでは、10 月 23 日週のアップデートを振り返ってみましょう。 2023 年 10 月 23 日週の主要なアップデート 10/23(月) Amazon ECSで予期できない負荷が発生した際の挙動を改善 Amazon ECSのタスクスケジューリング機能が強化され、予測できない負荷が発生した場合にもより回復力を高めるように動作するようになりました。ECSで稼働するタスク(コンテナ)はヘルスチェックが行われ、応答がない場合はそれが終了され代わりのタスクが起動されます。今回のアップデートで、新たにタスクを起動しサービスに組み込んだ後に、応答がないタスクを終了するような動作をするようになります。突発的な負荷が発生すると過負荷によってタスクがヘルスチェックに応答できず終了され、一時的に全体のキャパシティが低下してしまう、といったケースの回避につながることが期待できます。 Amazon RDS for SQL ServerがSQL Server 2019の新しいマイナーバージョンをサポート Amazon RDS for SQL ServerでSQL Server 2019 CU22 – 15.0.4322.2をサポートしました。Express, Web, Standard, Enterpriseの各エディションでご利用いただけます。 10/24(火) Amazon OpenSearch Serverlessで時刻ベースのデータ削除に対応 Amazon OpenSearch Serverlessで時刻に基づいた自動データ削除が可能になりました。この機能はインデックスライフサイクルポリシーを設定することで有効化できます。不必要になったデータを削除するといった、ハウスキーピング処理を容易に実現できます。 Amazon Aurora PostgreSQLでpgvector v0.5.0を利用可能に PostgreSQL互換のAmazon Auroraでpgvector v0.5.0を利用できるようになりました。機械学習モデルで利用されるエンベディング(埋め込み)データを格納し、効率的に類似するデータを検索することが可能です。HNSWによる近傍探索のためのインデクシングもサポートされており、特に生成系AIの分野で利用されるデータストアとしての利用が容易になります。pgvector v0.5.0はPostgreSQL 15.4, 14.9, 13.12, 12.16互換のAurora PostgreSQLでご利用いただけます。 Amazon Aurora PostgreSQLで新しマイナーバージョンをサポート PostgreSQL互換のAmazon AuroraでPostgreSQL 15.4, 14.9, 13.12, 12.16, 11.21がサポートされました。このアップデートにはBabelfish for Aurora PostgreSQL 3.3のようなアップデートも含まれています。 Amazon EKSでクラスタのサブネットとセキュリティグループの設定変更が可能に Amazon Elastic Kubernetes Service(EKS)で、クラスタに紐付けられたサブネットとセキュリティグループを変更できるようになりました。VPCの設定を変更する必要が発生した場合も、クラスタを作り直すことなしに変更内容に柔軟に追従させることができます。 Amazon EKSがカスタマーマネージドIAMポリシーをサポート Amazon EKSでユーザが作成した独自のIAMポリシー(カスタマーマネージドIAMポリシー)を利用できるようになりました。Kubernetesクラスタが引き受けることができるIAMの権限をきめ細かく制御することが可能になり、コンプライアンスやガバナンス要件を満たすことが容易になります。 Amazon SQSのFIFOキューの高スループットモードにおける上限を引き上げ Amazon SQLにおいて、順序と同じデータが重複して取り出されない事を保証するFIFOキューのスループット上限が引き上げられました。リージョンによって異なりますが、東京リージョンでは高スループットモードで最大9,000トランザクション毎秒まで対応可能です。リージョン毎の上限値については ドキュメント を確認してください。 10/25(水) Amazon RDS for PostgreSQL, MySQL, MariaDBでM7g/R7gインスタンスを利用できるリージョンを拡大 東京リージョンを始め5つのリージョンにおいて、RDS for PostgreSQL, MySQL, MariaDBをGraviton 3プロセッサベースのM7g/R7gインスタンスでご利用いただけるようになりました。 Amazon Aurora MySQL 3.04がLong term support(LTS)対象に MySQL 8.0.28と互換のAurora MySQL 3.04がLTS(Long term support)対象になりました。LTSリリースが動作するクラスタでは、最低3年間は同じマイナーバージョンにとどまり続けることが可能です。この期間はセキュリティ問題の修正などが提供されますが、新機能は含まれません。 Amazon Aurora MySQLのバージョン3.05が利用可能に Amazon Aurora MySQLのバージョン3.05が一般利用開始になりました。このバージョンはMySQL 8.0.32と互換性を持っています。 Amazon Aurora MySQLでデータベースの再起動時間を最大65%短縮 Amazon Aurora MySQLでバッファプールの初期化と検証の一部をデータベースがオンラインになった後に実行するよう最適化することで、予期しない再起動や計画的な再起動の双方について起動時間が最大65%短縮されました。この最適化はAurora MySQL 3.05以降でデフォルト有効になっています。 Amazon EC2 M2 Macインスタンスが一般利用開始に Amazon EC2で、M2プロセッサを搭載したMacインスタンスが利用可能になりました。iOS, macOS, iPadOSをはじめとするApple社のプラットフォーム向けの開発やテストにご利用いただけます。 10/26(木) Amazon OpenSearch ServiceがIPv6をサポート Amazon OpenSearch ServiceでIPv4に加えてIPv6による通信を利用できるようになりました。 Amazon EC2のI4iインスタンスで新たに2つのサイズが利用可能に 高いパフォーマンスを発揮するローカルストレージが利用できるI4iインスタンスで、新たにI4i.12xlargeとI4i.24xlargeというサイズをご利用いただけるようになりました。東京・大阪のリージョンでもご利用いただけます。 Amazon AppStream 2.0のMicrosoft Windows環境がマルチセッション接続に対応 Amazon AppStream 2.0でWindows環境のマルチセッション接続をサポートしました。複数のユーザセッションを単一のインスタンスで処理できるようになり、コスト効率が向上します。 Amazon EC2インスタンスに対して異なるVPCのENIをアタッチ可能に Amazon EC2で、EC2インスタンスにアタッチされたプライマリのENIが所属するVPCと異なるVPCに所属するENIを、同じインスタンスにアタッチできるようになりました。コントロールプレーンとデータプレーンの分離や、異なるVPCに集約されたアプライアンスへのアクセスが必要な場合に便利な機能です。 10/27(金) AWS NeuronがLlama-2 70bモデルとPyTorch 2.0をサポート AWS Neuronは機械学習用のアクセラレータであるInferentiaとTraniumを搭載したEC2インスタンス向けのSDKです。今回バージョン2.15がリリースされ、Llama-2 70bモデルのトレーニングへの対応と、PyTorch 2.0のサポートが行われました。 Amazon OpenSearch Serviceがk-NN FAISSエンジンによる効率的なクエリフィルタリングに対応 Amazon OpenSearch ServiceのOpenSearch 2.9を利用することで、k-NN FAISSエンジンを利用した効率的なクエリフィルタリングを活用可能になります。これを利用すると従来よりも低遅延で正確な結果を期待できるため、ベクトル検索を必要とするアプリケーションで便利にご利用いただけます。 Amazon Security Lakeが大阪リージョンで利用可能に セキュリティデータの分析を容易にするAmazon Security Lakeが大阪リージョンをはじめ、4つのリージョンでご利用いただけるようになりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

アマゾン ウェブ サービス ジャパン合同会社とつくば市は、2022 年9 月に 研究開発型スタートアップの成長加速に向けた 連携協定を締結 いたしました。つくばの研究開発スタートアップの創出・育成に向けつくばのスタートアップへの AWS Activate を通したご支援や、イベントの共催等を行っています。 今回は 2023年 10月 18日に、 つくばスタートアップパーク でつくば市と AWS が開催したイベント 「イノベーションの最前線vol.6 ー防災テックを活かしたレジリエンス社会の実現に向けてー」 の開催報告を、当日の内容から一部抜粋してお送りします。 本イベントのご登壇者は以下の通りです。 I－レジリエンス株式会社 （以下、I－レジリエンス） 代表取締役社長　小林 誠 氏 防災科学技術研究所 （以下、防災科研） 防災情報研究部門/総合防災情報センター  吉森 和城 氏 モデレーター： アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 まずは小林 氏より、I－レジリエンスのお取り組み紹介をお話しいただきました。 防災科研の研究成果の社会実装のために生まれた、I－レジリエンスの挑戦 I－レジリエンス は、災害が多い日本で、防災の研究成果をきちんと社会で使える状態にしないといけない背景がありまして、防災科研の研究成果の社会実装を促進するために 2021 年 11 月設立されました。もうすぐ設立 2 年の、まだまだスタートアップです。産学官連携で行うために、民間企業 4 社にも出資いただいています。 I－レジリエンス株式会社 代表取締役社長　小林 誠 氏 I－レジリエンスの目的は大きく2つあります。 1 つ目は研究成果を活用したレジリエンス向上 です。防災科研のような研究者の方々が、研究成果を商品化して、運用して社会実装していくまでやるのは大変なので、社会実装を会社でやるのが私たちです。 2 つ目は、 民間企業主体のレジリエンス向上 です。行政だけではなく、企業や生活者にも情報を使った新しいサービスが必要なので、ここをI－レジリエンスとしてやっています。企業が使える防災情報サービスプラットフォームなどを運営し、その中で AWS も活用しています。大きく 3 つ DX・教育・ライフと 3 つの事業領域を持っています。 レジリエンスを高めることでより生活を豊かにする「レジリエントライフ」 レジリエンスとは、災害が起こった時、回復・復旧を早くしようというコンセプトですが、I－レジリエンスでは少し違う定義をしています。私たちは、 社会や個人に降りかかる自然災害だけではない困難に、適応、回復し、その後教訓をもとに成長し、次の被害を予防する、このサイクルを繰り返して困難を乗り越えるチカラ 、と定義しています。 レジリエントライフプロジェクト は、今年関東大震災100年に合わせて、防災科研と民間企業各社と一緒にスタートしました。各社が持っている強みを生かして、個人を起点にあらゆる困難に適応・回復・成長・予防できる生活の豊かさの実現を目指して活動しています。 防災という言葉はネガティブなイメージですが、レジリエンスを高めることでより豊かな生活を目指す、 「レジリエンスっていいよね」、というポジティブなイメージを広げていきたい という想いで取り組んでいます。 私たちは、困難な領域である防災分野のビジネスに挑戦し、これまた困難と言われている、研究成果の社会実装をするという、非常に難しいミッションを二つ負ったスタートアップです。やっていくべきことは主に 3 つあって、1 つ目はニーズとシーズのブリッジです。まだまだマッチングしていない防災に関するニーズと、シーズはたくさんあり、目利きをして橋渡しできる人が増えていく必要があります。 2 つ目は、1 つのソリューションでは解決できない生活者の課題を、色々な企業の色々なサービスを組み合わせて解決していく「コレクティブ・インパクト」を実現してくことです。3 つ目に、レジリエンス市場を新しく創出していくことです。 まだまだ防災分野の課題解決のためには、より多くの企業と共創していく必要があると思っています。私たちは、企業同士が防災分野で連携していくための基盤となるサービスとして、レジリエンスに関するすべてのニーズにこたえる総合プラットフォーム IRIN (I-Resilience Information Network）の開発を進めています。このようなサービスによってレジリエンス社会の実現を目指していきます。 分散した防災情報を集約・一元化し、防災効果の最大化を目指す 続いて、 防災科研 の吉森 氏より、防災科研の取り組みのご紹介と AWS の活用についてお話いただきました。 防災科研では、あらゆる自然災害を対象に、予測・予防、応急対応、復旧・復興という災害のすべての段階についての、基礎研究及び基盤的研究開発に取り組んでいます。例えば、全国各地にある地震計の観測震度をリアルタイムで公開( 強震モニタ )していたり、災害の現象実物大で再現し実験する施設( 大型降雨実験施設 、 E-ディフェンスなど )があったりします。 防災科学技術研究所 防災情報研究部門/総合防災情報センター  吉森 和城 氏 私が所属する防災情報研究部門では、色んな機関に分散している防災情報をきちんと活用し、社会実装していくために活動しています。その中で、 SIP4D （基盤的防災情報流通ネットワーク）というシステムを研究開発しています。こちらは分散したデータを繋ぎ相互に共有していく「パイプライン」を実現し、国全体としての災害対応の効果最大化を目指しています。その SIP4D で集約した情報を公開する 防災クロスビュー というウェブサイトも運用しています。 AWSとの出会いは北海道胆振東部地震。いつどこで地震や災害起きても、気づける仕組みが必要だった AWS と出会ったきっかけは、平成 30 年に発生した北海道胆振東部地震です。私のチームは、防災クロスビューを速やかに開設し、様々な情報発信を行いました。 しかし、深夜3時7分という、メンバー全員が寝ている時に深夜に発生したので、すぐに地震に気づくことができず、初動の対応に課題が残りました。 いつどこで地震が発生しても、対応者が気づける仕組みが必要 だという課題が浮き彫りになりました。 そのころ丁度スマートスピーカーが普及してきた頃だったので、Amazon Echo の Alexa スキルで地震情報を教えてくれるシステムを開発している開発者に問い合わせ、地震が起きたら強制的にアラートを出してくれる Alexa スキルを開発できないかと聞きました。 Alexa スキルは制約が多いので難しいと言われましたが、 Amazon Connect というサービスを使えば強制的に電話通知できると教えてもらいました。また、AWS の色々なサービスを組み合わせることで、電話通知だけではなく他の通知にも拡張できるとのことでした。 当初はコスト面が懸念でしたが、 AWS は従量課金で、災害発生時に電話をかけた時のみコストが発生するため、低コストで運用できるのでは と考え、AWS 導入の検討に踏み切りました。 開発者の方に相談して 10 日後にはサンプルを構築してくださり、このスピード感でサンプルシステムが実現できたので AWS は本当にすごいなと思いました。 突発的な災害にも、俊敏かつ柔軟に対応可能な災害通知システムを、2.5 か月で構築 サンプルシステムを踏まえ、実際に災害が起きた時に電話がかける仕組みを実現しようと、考案から2.5 か月で、初回の災害情報通知システムが構築されています。気象庁や J-アラートをトリガーに、AWS 上の処理を経て職員にチャットや電話等のツールで通知する仕組みです。 あくまで個人の見解とはなりますが、AWSを活用する上でプラスに感じていることは、まず 従量課金のため頻度が高くない利用に関しては、コストメリットが大きい ことです。そして システム構築のスピード感、スモールスタートで開発できその後の拡張が容易であること もメリットです。 最初は私も災害情報通知システムだけを作り始めましたが、2018 年の導入から業務の自動化・簡便化にも活用するようになり、5 年間でこれまで9 種類のシステムで AWS を活用しています。 一方で、少し困っていることとしては、従量課金のため費用感が確実に予想できないことです。ここ数年特に為替変動が大きく予測が難しいこともあり、この点は何かしらの改善を期待しているところです。 必要な時に、必要なだけ使うことができるクラウドは、防災テックと相性がよい 続いて、AWS の田代より、 AWS の概要についてお話しました。AWS クラウドの価値は、まさしく吉森 氏は話されたような、スモールスタートで必要な時に必要なだけ使えること、アイデアから実装までの時間を短縮できることで、防災分野はクラウドと大変相性がよいことを強調しました。 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 防災分野でテクノロジーを活用する余地はまだまだある。必要な時に必要なだけ防災データを活用できる仕組みの構築に向けて 最後に、登壇者でクロストークを行いました。ここではその一部を抜粋してお伝えします。 ―まずお伺いしたいのは、防災の領域でのテクノロジー活用はどのくらい進んでいるか、お二人のお考えを率直にお聞かせください。 小林 氏：まだまだこの領域で新しいテクノロジーの活用は進んでいないと考えています。例えば、災害の被害状況はリアルタイムで把握することができません。IoT や衛星データによって身の回りの情報、よりきめこまかやかに取得できると、防災対策も大きく変わってくると思います。 現状では、行政は市全体に対して防災サービス提供という形になっていますが、 一人ひとりに合わせて必要なサービスを提供していくには、テクノロジーをより活用していくことが重要 だと思いますし、さらに技術が進化していく必要があります。 「必要な時に、必要なだけ使えるようにする」というのは防災において重要です。平時から防災情報が活用できるようにするのは、コスト面では結構しんどい。 必要な時だけ使えるようにしておき、使った分だけ課金される仕組みができると、もっと防災情報は普及する と思います。そういったところで今後 AWS ともご一緒したいと思います。 田代：防災レジリエンスではテクノロジーによって情報がパーソナライズされていく、 個々人が最適な行動をとるうえで、クラウドがビジネスモデルに組み込まれていくことが必要 なのだということ理解しました。 吉森 氏：私もこの領域でテクノロジー活用の余地はまだまだあると考えています。 現在、やっと解析に使えるデータがそろい始めている段階 。集まったデータをより価値のある情報に変えていくために、新しいテクノロジーの活用がもっと必要です。 災害は毎回規模も大きさも違い、今まで準備していたデータの扱い方がガラッと変わったりします。それぞれにうまく対応していくのはテクノロジーで解決していかなければいけないと考えています。 スタートアップ企業の革新的ソリューションがもとめられている防災分野 田代：テクノロジーが解決していくために、スタートアップのような企業の革新的なソリューションが必要とされている市場だと思います。ぜひこの分野に取り組むスタートアップを増やしていきたいですね。 小林 氏： スタートアップのような方が情報を使いやすく、より防災サービスを作りやすくしていく環境作りを、私たちI－レジリエンスとしてやっていきたい と思っています。防災情報を一から集めるのは、各自がやらなくても、誰かがやってくれればよいんです。 田代：I-レジリエンスはご自身もスタートアップでありながら、スタートアップのためのプラットフォームにもなられようとされていますね。こういった状況も踏まえて、この領域で起業する方が増えることを期待しています。 ―I－レジリエンスは防災科研が出資をされて設立された、今までになかったベンチャーです。防災科研が出資までしてスタートアップを設立した目的についても、改めて教えていただけますでしょうか。 小林 氏：防災科研の素晴らしい研究成果をしっかり社会に広めていきたいというときに、研究者が社会実装まで担うのは難しいことがあります。研究者にはしっかり研究に専念していただきたいですし、私たちが会社として、社会に技術を実装していくために設立されました。I－レジリエンスは、研究所発ベンチャーではありながら、私のような技術者でも研究者でもない者が代表ですし、その技術が社会の何の役に立つのか、をうまく翻訳し、社会実装に繋げていきたいです。 田代： 防災科研とI－レジリエンスの関係は、研究の社会実装の形としては、先進的なモデルとなるような形 だと思っています。他の研究機関も真似するところがでてくると考えています。 ―最後に、今後テクノロジーを使ってどういったことをしていきたいか、将来の展望を教えてください。 吉森 氏：研究者の立場としては、研究のロジックや要件は定義しますが、それを支えるシステムやテクノロジーを作っていくために、 技術者が関わってくださることがもっと必要 です。 田代：そうですね。AWS を使えるようなエンジニアの方はぜひ防災科研にコンタクトしていただいて、防災の研究者と技術者の協業が増えるといいなと思います。 小林 氏：吉森さんのおっしゃる通り、研究を「実装」するためにも、研究開発において、研究にきちんとテクノロジーを入れていくことが重要だと思います。 防災は一つの分野ではなく、理学、工学、社会科学、医療、通信など様々な分野の色々なテクノロジーがないとできない特殊な領域です。現在では今バラバラに個別の機関がデータを抱えている状況です。なぜそのような対応をしたのか、等情報が集まっていくと、世の中は変わっていくと思っています。そういう バラバラのデータが、分野を超えてクラウドの同じ場所に集めて解析され、新しい価値を生み出して社会を変えていくことが求められています 。 私たちは、日々の生活の色々な部分にテクノロジーが組み込まれ、日常的にレジリエンスを意識するような社会を目指していきたいです。I－レジリエンス自身もスタートアップですが、他のスタートアップと協業して、そのような新しい社会を作ることを目指しています。 田代： システムのサイロを打破して、きちっとナレッジをシェアできるコミュニティを作っていく、そしてみんなで災害に備えていくことで、レジリエントな社会に繋がっていく と思います。 今日お話しされたアイデアがどんどん社会実装されていくのは一生活者としても非常に楽しみですし、AWS のテクノロジーがその社会の実現に貢献できればとても嬉しいです。 イベントレポートはいかがでしたでしょうか？AWS パブリックセクターは今後も、自治体、大学、研究機関、スタートアップの皆様と共創し、地域発イノベーションを加速させるためのさまざまなセッションや Meetup を実施予定です。ご関心を持たれた方は、ぜひお気軽に こちら までお問い合わせください。 このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター  シニア事業開発マネージャー（ Startup ）である 岩瀬 霞 が執筆しました。

この記事は Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。 はじめに 調査によると、モノのインターネット（IoT）ソリューションの実装には、通常、市場に出て運用準備が整うまでに 平均18〜24か月 かかります。IoT ソリューション開発に関連する一般的なシナリオには、デバイスプロビジョニング、テレメトリ収集、リモートコマンドアンドコントロールなどがあります。ユースケースにもよりますが、 well-architected IoT solution のプロトタイプを作成するには、それぞれのシナリオに適した設計原則とベストプラクティスを検討する必要があります。この投稿では、 AWS Cloud Development Kit (AWS CDK)、 AWS IoT Greengrass 、 Docker を組み合わせたプロトタイピングデザインパターンを採用して、AWS での IoT ソリューションのプロトタイピングを加速する方法を説明します。 AWS CDK は、一般的なプログラミング言語の表現力を利用して、AWS 上のクラウドリソースをモデル化することで、クラウド開発を加速します。AWS IoT Greengrass は、デバイスソフトウェアを構築、デプロイ、管理するためのオープンソースのエッジランタイムおよびマネージドクラウドサービスです。AWS IoT Greengrass を使用することで、ワークロードのエッジでの実行、IoT デバイスフリート全体に新規アプリケーションやレガシーアプリケーションをデプロイ、デバイスフリートをリモートで管理および操作を行うことができます。AWS IoT Greengrass には、カスタムコードを記述することなくエッジデバイスの機能を拡張できる 30 種類以上の AWS提供コンポーネント もあります。 AWS IoT Greengrass は、 Docker コンテナ内での実行や、Docker コンテナとしての実行 など、 さまざまなデプロイ方法 をサポートしています。AWS CDK を使用して作成された体系化されたインフラストラクチャパターンを、コンテナ化および自動化と組み合わせて、IoT デバイスの機能をテストまたは調査するための一貫したアプローチを作成できます。このアプローチは、プロトタイピングの繰り返し中に重要ではない暫定的なアーティファクトを残すことなく、IoT ソリューションの迅速なプロトタイピングをサポートします。 ソリューションの概要 本投稿では、このアプローチが一般的な IoT ソリューションシナリオをサポートする方法を説明します。一般的な IoT ソリューションシナリオは、デバイスプロビジョニング、デバイスコマンドアンドコントロール、テレメトリ収集です。 デバイスプロビジョニング 安全な IoT デバイスのプロビジョニング では、 固有の アイデンティティ を使用してデバイスを設定し、これらの ID を AWS IoT サービスに登録し、必要な権限を関連付ける必要があります。これにより、デバイスが AWS IoT やその他の必要な AWS サービスに安全に接続して通信できるようになります。この要件は AWS IoT Greengrass コアデバイスのセットアップ に適用されます。以下の手順は、AWS IoT Greengrass コアデバイスをプロビジョニングする方法を示しています。 AWS IoT Coreポリシーを作成します。 AWS IoT のモノ、グループ、証明書、プライベートキーを作成します。 AWS IoT ロールエイリアスと AWS Identity and Access Management (IAM) ロールを作成します。 AWS IoT Greengrass コアデバイスをセットアップします。 プロトタイピングとテスト用に AWS IoT Greengrass コンポーネントをデプロイします。 上記の手順を効率化するために、図 1 に示すパターンの採用を検討してください。このパターンでは、AWS CDK と Docker を使用して関連するリソースの作成を簡素化および効率化できます。そのため、ユーザーは 自身の IoT  ソリューションにおける機能の差別化実現に集中できます。本パターンには以下の要素が含まれます。 必要な AWS リソースを再利用可能な構成として表す AWS CDK スタック 。AWS リソースは、 AWS CloudFormation を使用して AWS CDK CLI を通じてデプロイされます。 新しく作成された AWS IoT クライアント証明書をダウンロードし、 Docker Compose ファイルと AWS IoT Greengrass セットアップスクリプトを設定することができる ヘルパースクリプト  があります。 AWS IoT Greengrass Core デバイスをセットアップし、AWS が提供するコンポーネントとオプションのカスタムコンポーネントを デプロイ する Docker コンテナです。 図 1.AWS CDK と Docker を使用して自動化された AWS IoT Greengrass Core デバイスプロビジョニングの基本プロトタイピングパターン 図 1.の詳細については、このセクションを開いて確認してください。 この図は、AWS IoT Greengrass コアデバイスのリソースの作成とデプロイを自動化する手順を示しています。AWS CDK (1) と CloudFormation (2) を使用して、必要な AWS IoT リソースと IAM リソースを作成します。付属のヘルパースクリプト (3) を使用してローカル設定を完了し、ローカルの Docker コンテナ (4) で AWS IoT Greengrass を起動します。 AWS IoT サービス、インフラストラクチャデプロイ、Docker を組み合わせて機能的な AWS IoT Greengrass コアデプロイを作成できます。その後、ソリューションに必要な 特化した コンポーネント開発 を進めます。 リモート管理/コマンドとコントロール IoT ソリューションを構築する際に遭遇する可能性のあるもう 1 つの一般的なシナリオは、IoT デバイスとリモートでやり取りできることです。たとえば、産業機器から特定のテレメトリデータを要求したり、ホームオートメーションイベントのスケジュールを設定したりします。AWS のベストプラクティスに従い、 MQTT プロトコル の双方向機能を使用してください。AWS では MQTT のコマンドとコントロールを実装するための  Device Shadow  と AWS IoT Jobs を提供しています。 図 1 で説明したパターンをベースにすると、このアプローチを拡張して MQTT 経由でデバイスのコマンドとコントロール機能をすばやく有効にすることができます。このパターンの例を図2に示します。このパターンには以下が含まれます。 AWS CDK スタックの内容: 追加の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 デバイスのコマンドとコントロールのカスタム AWS IoT Greengrass コンポーネントをデプロイします。 AWS CDK CLIを利用してCloudFormathionを実行し、リソースをデプロイします。 このパターンでは、AWS CDK ランタイムコンテキスト を使用して、以前に作成されたベースとなる CloudFormation スタックからサポートしている AWS CDK リソースを参照します。本パターンは、リソースの再実装や再デプロイすることなく、新しい機能を作成してテストすることに重点を置いています。 スタックが正常にデプロイされると、カスタムコンポーネントは指定された MQTT トピックをサブスクライブし、コマンドリクエスト到達を待機します。このトピックを通じてデバイスにコマンドを発行し、MQTT トピックのレスポンス内で完了ステータスメッセージを受信します。 このアプローチを採用すると、利用用途に合致した AWS IoT ソリューションの一部として、カスタムデバイスのコマンドとコントロール機能のプロトタイプを迅速に作成できます。 図 2.MQTT を使用した IoT デバイスのコマンドとコントロールのプロトタイピングパターンの例 図 2 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、すでにデプロイされた CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。MQTT ベースのコマンドとコントロールのコンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 テレメトリの収集 最後に、一般的な IoT ソリューションには、物理デバイス、センサー、または産業機器からテレメトリデータを収集する機能が必要です。収集されたデータは、ストリーミング分析、デジタルツイン、予知保全、プロセスのシミュレーションと最適化など、多くの IoT アプリケーションをサポートできます。詳細については、「  IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」を参照してください。 基本的なデバイスプロビジョニングパターン (図 1) を基盤として、ユースケースの要件を満たすために IoT データを AWS に取り込むオプションを検討できます。たとえば、AWS IoT Greengrass コア デバイス上で実行されている AWS IoT SiteWise を使用すると、産業機器からのデータを大規模に収集、整理、分析できます。具体的には、 OPC-UA プロトコルを使用して産業用テレメトリデータを取り込むソリューションを作成してください。取り込んだデータを 視覚化 して 分析し 、異常に対応したり、産業施設間の違いを特定したりできます。 このソリューションを実装するには、図 3 に示すパターンを採用してください。以前のパターンと同様に、このパターンには以下が含まれます。 AWS CDK スタックの内容: 専用の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 D必要な AWS IoT Greengrass コンポーネント ( AWS IoT SiteWise OPC-UA コレクター 、 AWS IoT SiteWise パブリッシャー 、および AWS IoT Greengrass ストリームマネージャー ) をデプロイします。 クラウドフォーメーションを使用して AWS CDK CLI を使用してリソースをデプロイします。 また、このパターンでは、AWS CDK ランタイムコンテキスト を使用して、作成済みのベースとなる AWS CloudFormation スタックがサポートする AWS CDK リソースを参照します。 デプロイすると、IoT Greengrass コア デバイスは既存の OPC-UA エンドポイントからテレメトリを収集し、このテレメトリを AWS IoT SiteWise に発行できるようになります。詳細については、「 AWS IoT SiteWise へのデータの取り込み 」を参照してください。 図 3.OPC-UA と AWS IoT SiteWise を使用してテレメトリを取り込むプロトタイピングパターンの例 図 3 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、以前にデプロイされたベースの CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。テレメトリの収集と公開に必要な AWS IoT SiteWise コンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 このアプローチを使用すると、必要なテレメトリの取り込み機能を迅速に構築してテストできます。自動化とコンテナ化という利点も加わり、プロトタイピングにかかるコストを全体的に削減できます。 この記事で紹介するパターンとソリューションはすべて、以下の概要に従ってお客様の AWS アカウントで使用できます。 前提条件 AWS アカウント へのアクセス。 ローカルにインストールされた Docker ランタイム 、または AWS Cloud9 クラウドベースの統合開発環境。 AWS IoT Greengrass accelerators の GitHub リポジトリへのアクセス。 ソリューションウォークスルー 今回紹介しているパターンは、 AWS IoT Greengrass accelerators  の GitHub リポジトリから入手できます。これらのパターンやその他の利用可能なパターンを調べるには、このリポジトリを開発環境にクローンし確認してください。クローンを作成したら、表示される手順に従って環境に AWS IoT Greengrass Core デバイスをセットアップし、説明されているシナリオを調べることができます。 例 説明 Base Implementation IoT Greengrass コアデバイスのプロビジョニングの基本パターンです。 Operating System Command Component 基本パターンを拡張したもので、デバイスのコマンドと制御機能の実装例を紹介しています。 AWS IoT SiteWise Deployment 基本パターンを拡張したもので、AWS IoT SiteWise を使用した OPC-UA による産業用テレメトリの取り込みを紹介しています。 各列のリンク先に記載されているデプロイ手順に従うと、すぐに使い始めることができます。これらのソリューション例をカスタマイズして、さまざまなユースケースに適応させることができます。また、既存のパターンを基盤として新しい AWS CDK スタックを作成し、独自のユースケースに合わせてカスタムコンポーネントを作成してテストすることもできます。すべてのサンプルを AWS Cloud9 にデプロイして、アーティファクトをローカルにインストールまたはデプロイしなくても、迅速に検証することができます。 クリーンアップ 追加料金が発生しないように、この記事で作成したリソースを削除してください。 作成した CloudFormation スタックを削除するには: https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。 削除するスタックを選択すると、その詳細が表示されます。 Delete  を選択し、最新のスタックから例を実行して作成された各スタックの削除を確認します。スタックが順番に削除されるのを待ちます。 まとめ この投稿では、AWS CDK、AWS IoT Greengrass、Docker を組み合わせて AWS で迅速な IoT ソリューションのプロトタイピングを実現する方法を説明しました。宣言型インフラストラクチャをコードとして使用し、コンテナ化と自動化を行うことで、パターンベースのプロトタイピングアプローチを採用して、一般的な IoT ソリューションシナリオを迅速に構築できます。コア機能の構築に費やす時間を短縮することで、IoT ソリューションの差別化と革新的な機能の実現に集中できます。これにより、市場投入までの全体的な時間も短縮されます。 詳細については、他のプロトタイプパターンの作成に役立つ AWS クラウド開発キット (AWS CDK) 、 AWS IoT Greengrass 、および AWS IoT Greengrass accelerators  を参照してください。 著者について Maxim Chernyshev Maxim Chernyshev は、AWS で鉱業、エネルギー、産業分野の顧客を担当するシニアソリューションアーキテクトです。西オーストラリア州パースに拠点を置く Maxim は、適用可能な幅広いAWSのサービスと機能を使用して、お客様が複雑で斬新な問題に対するソリューションを考案できるよう支援しています。Maxim は、産業用IoT、スケーラブルな IT/OT コンバージェンス、サイバーセキュリティに情熱を注いでいます。 この記事は Maxim Chernyshev によって書かれた  Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。ソリューションアーキテクトの川﨑 裕希が翻訳しました。

本記事は、製薬企業における大規模言語モデル ( LLM ) の効果が大きく期待できる様々なユースケースについて業務部門毎に整理し、AWS が提供する生成系 AI サービスと共に解説する 3 部構成のシリーズの 2 つ目のブログ記事です。 パート1 では、臨床開発でのデータクリーニング作業、メディカルライティングを始めとした文書業務の効率化について、ファーマコビジランス部門での AI アプリケーションを利用した SNS 上の有害事象を検知について説明しました。パート 2 では、メディカルアフェアーズ部門での社内レビュー業務の効率改善、マーケティング部門における医療関係者向け、患者さん向けの生成系 AI チャットボットの有用性ついて説明します。 ユースケース＃3：メディカルアフェアーズ 社内のメディカルエキスパートをアナログなレビュープロセス、文書管理から解放する 製薬企業が医療関係者向けに行うプロモーション活動には、適正使用などの観点から薬機法、医療用医薬品プロモーションコードなど様々なルールが設けられており、確実な順守が求められています。このルールは年々厳格化しており、製薬企業が医療関係者向けに開催する講演会等で使用される発表スライドは、事前に社内レビューが実施されています。これらのレビュー業務は、メディカルアフェアーズ部門のメディカルエキスパート（医師、または医学系学位保持者）を中心に医科学的な妥当性、正確性、コンプライアンスなど複数の観点から行われています。特にコロナ禍に伴う企業主催のオンラインセミナーの増加を背景に、レビュー業務の負担が急激に増加しています。 この課題に対し、AI と機械学習を用いることで効率的なレビューを実施できる可能性があります。具体的には、スライドに記載された情報を AI が解析し、適正使用の観点から予め設定した注視すべきポイントが含まれるスライドにアラームを発し、レビューワーの確実な検証と適切な資料作成を支援するサービスが国内で展開されています。レビュー業務の生産性を大幅に改善し、社内のメディカルエキスパートがより医科学的、戦略的な活動にフォーカスできるようになります。 製薬企業が医療関係者に提供する情報の特徴の一つは、透明性が高く、説明可能な情報、参照元が明確であることです。医師や薬剤師に提供される情報は、常に医科学的に検証された“出処が明らかな内容”で回答する必要があります。一方で、外部からの問い合わせは、製品情報から疾患情報、最新論文まで非常に多岐に渡ります。そのため、担当部門では、社内外の何千もの医療情報ソースを分析し、大量の Q＆A を準備する必要があります。この準備プロセスには、膨大な裏付け調査、評価、データ統合が必要になり、正確な回答を効率的に導き出す環境の構築には非常に多くの労力を要しています。この課題に対する一つの解決策として、生成系 AI を活用したチャットボットの可能性を紹介したいと思います。 医療関係者向けのチャットボットは、24 時間 365 日の問い合わせ対応を可能にし、医療従事者や患者さんなど利用者の利便性向上を図る目的として、様々な製薬企業から提供されています。厚生労働省の調べによると、平均1社当たりの問い合わせ件数は、1カ月に約 2026 件で、その 97 ％以上が医療関係者からの問い合わせです。問い合わせの多い製薬企業では 1 カ月に 6000 件以上と報告されており、チャットボットは、お客様からの大量の問い合わせに対応するためには欠かせないツールと言っても過言ではないでしょう（ 厚生労働省, 2022 ）（ 第一三共, 2022 ）問い合わせに対しては、社内で承認、確認された内容から正確な情報をお伝えすることが重要となります。 その観点において、AWS の生成系 AI を活用したチャットボットでは、企業規模で正確な回答を合成することができます。予め準備した信頼できるデータレポジトリ（社内の参照元）に接続し、自然言語クエリを実行して、これらの信頼できるデータソースの内容に応じた回答を数秒で生成することができます。加えて、回答生成に使用されたデータ参照元をリファレンスとして表示することで、情報の正確性を検証することも可能になります。なお詳細は、後述の「責任ある AI のためのアプローチ」で記載しています。 ユースケース＃4：マーケティング 生成系 AI チャットボットは、患者さんと製薬企業をつなぐエンゲージメントチャネルになるのか？ 昨今、製薬企業では患者サポートプログラム( PSP : Patient Support Program )への取り組みが盛んになっています。その理由の一つとして、癌や難病といったスペシャリティ医薬品の増大に伴い、抗癌剤など外来治療（通院注射）が一般化されたことで、患者支援、副作用マネジメントの重要性が高まっているからと考えられます。加えて、新型コロナウイルス感染症による受診控えや治療中断を防ぐ手段として、PSP を通じて直接、患者にコミュニケーションを取ることで、患者の QOL やアドヒアランス改善、治療アウトカムの向上につなげたいという企業の意識変化、患者中心の企業活動が強化されている影響と考えられます。 PSP では、自社の医薬品を使用する患者さんに対し、疾患や治療に関する情報提供、注射手技の解説などの資材提供だけにとどまらず、疾患に特化した治療管理アプリ、服薬管理用のデバイスやオンライン診療など様々なデジタルサービスを組み合わせた患者支援プラットフォームとして提供されることも少なくありません。患者向けチャットボットは、これらの患者支援プラットフォーム上で、患者さんが日常生活に抱える疑問や不安を気軽に相談できるツールとして提供されるケースが増えています。 一方で、従来の AI チャットボットのコミュニケーションはまだ機械的な感じがする、あるいは質問の意図とは違った回答が表示されて回答が的を射ていないと思われる人もいるかもしれません。このような疑問に対して、カリフォルニア大学サンディエゴ校（ UCSD ）が、2023 年に患者向け生成系 AI チャットボットを利用した医師と患者のエンゲージメントについて、非常に興味深い研究結果を報告しています（ John W. Ayers, 2023 ） 図表： Boston Consulting Group Article, July 2023 この研究では、医療系 SNS に患者から寄せられた質問 195 件をランダムに抽出し、医師の回答と生成系 AIの回答を「回答された情報の質」「文章から受ける思いやり」の二つの観点から評価し、比較検討しています。評価は 5 段階で（ 1 が最も悪く、5 が最も良い）医療専門家が行っています。 その結果、「情報の質」については、良い／非常に良い以上（≧ 4 ）の割合が、チャットボット：78.5 ％、医師：22.1 ％で、チャットボットの割合が 3.6 倍有意に高いことが分かりました。 また、「思いやり」についても、ある／とてもある以上（≧ 4 ）の割合が、チャットボット：45.1 ％、医師：4.6 ％で、チャットボットの割合が 9.8 倍高かったと報告されました。 この非常に興味深い結果は、生成系 AI がチャットボットを、知りたい情報を得るという単なる検索ツールから、製薬企業と患者のより良いエンゲージメントチャネルへ進化させる日も近いという可能性と示唆を与えてくれています。 次号、Part.3 では「責任ある AI 開発のためのアプローチ」について考察し、AWS が提供する生成系AIサービスについてご紹介します。 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（ DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

こんにちは、アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクトの川島です。2023 年 10 月 19 日に AWS for Games Live を開催いたしました。 AWS for Games Live とは？ AWS for Games Live は、AWS 公式ウェブマガジン builders.flash の記事と連動したイベントで、AWS for Games の 3 つの柱「Build」「Run」「Grow」の柱のうち 1 つにフォーカスを当てて、その内容を掘り下げるものです。参加者の方々には、ゲーム業界のトレンドを知ったりネットワーキングを楽しんだりする時間として活用していただいています。今回は、「これからのゲームデータ分析環境を考える」と題して、AWS でのゲーム分析について 4 つのセッションを設けました。 AWS でこれから始めるゲーム分析 はじめに、ソリューションアーキテクト渡邉 真太郎から、ゲームを改善するための分析を予算や工数が限られたなかで進めていくために、サーバーレスな分析サービスを組み合わせた AWS でのゲーム分析の導入例をご紹介しました。資料は こちらのリンク からご覧いただけます。 本セッションでは最初に、Amazon Aurora にある基本 KPI データをエンジニアが SQL でアドホックに集計して制作チームに共有している状況を仮定しました。このとき、集計の処理時間の長期化や集計対応の工数が課題として想定されます。そこで第一に、Amazon Redshift Serverless というクラスター管理不要のクラウドデータウェアハウスを導入し、Amazon Aurora との Zero-ETL 統合をセットアップします。Amazon Aurora と Amazon Redshift の Zero-ETL 統合は現在 機能の制限 がある Public Preview のものであり、後段のセッションで詳しく紹介します。第二に、幅広いメンバーが定常的にデータを確認・分析するための可視化に、サーバーレスな BI サービスである Amazon QuickSight を導入します。 しかしこれでもなお、基本 KPI データだけではゲーム内のユーザーの動向を定量的に確認することができず、この課題を解消するためにはユーザー行動ログも出力し分析する必要があります。そこで第三に、Amazon Kinesis Data Firehose によりゲームサーバーやクライアントからユーザー行動ログを吸い出して Amazon Redshift Serverless に格納します。これにより、分析に必要な基本 KPI データとユーザー行動ログの双方を分析・可視化できるようになります。 このようにAWSのサーバーレスな分析サービスを組み合わせていくことで分析要件の変化に応じてゲーム分析環境を発展させられることをお話ししました。 Amazon Aurora と Amazon Redshift の Zero-ETL 統合のご紹介 次に、同じくソリューションアーキテクトの佐藤 祥多から、Amazon Aurora と Amazon Redshift の Zero-ETL 統合 (以下単に「Zero-ETL 統合」) についてご紹介しました。資料は こちらのリンク からご確認ください。 Zero-ETL 統合は、ETL パイプライン不要で複数の Amazon Aurora データベースから Amazon Redshift に対して数秒以内にデータを複製できる、現在 Public Preview 中の機能です。現在は Amazon Aurora MySQL の一部バージョンのみをサポートしています。内部では Amazon Aurora の拡張 Binlog を利用してデータ複製をしているため、MySQL クラスタへの負荷を最小限に抑えられることや Crash recovery の時間が大幅に改善していることも特徴です。本機能は、ETL の運用軽減・データベースへの負荷軽減・リアルタイムでの可視化といった用途でお使いいただけます。 本セッションでは、ゲーム内の仮想通貨の動きをリアルタイムで可視化するデモもお見せしました。クライアントから送られた情報が、Amazon Aurora から Amazon Redshift に同期され、Amazon Managed Grafana で可視化されるという一連の流れをお見せし、設定の簡単さやリアルタイム性を実感していただける内容でした。 Amazon Aurora MySQL と Amazon Redshift の Zero-ETL 統合について使い所を考えてみた！ 続いて、面白法人カヤックの池田 将士氏から、Zero-ETL 統合の具体的な使い道やメリットについてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 池田氏が Zero-ETL 統合のメリットを論じるにあたって挙げたキーワードは「VPC 超え」でした。 Amazon Aurora と Amazon Redshift が異なる VPC にある場合、VPC を跨いだデータ搬送が必要になります。この「VPC 超え」の状況は、複数ゲームタイトルの統合的な分析のための分析用アカウントを用いるクロスアカウント分析の場合などに発生します。そして、そのときに Zero-ETL 統合のメリットが大きいというのが池田氏の着目する点です。「VPC 超え」のデータ搬送においては、これまで、Amazon S3 のスナップショットを経由する方法や VPC Peering で Federated Query もしくは変更データキャプチャ (CDC) を用いる方法、パブリックアクセスで AWS IAM を用いて権限を付与する方法といったものがありました。しかし、それぞれの方法で、リアルタイム性や管理の手間といった課題はありました。一方で Zero-ETL 統合なら、AWS マネージドかつニアリアルタイムで、VPC やアカウントが異なっていても CDC ができるという旨味があります。 一方で、Amazon Aurora と Amazon Redshift が同一 VPC 内に存在するときは、Federated Query で十分な場合もあります。しかしながら、それでも Zero-ETL 統合により享受できるメリットもあります。第一に、大量のデータを扱うときには Federated Query では Amazon Aurora 側の読み込み負荷が気になるため、Zero-ETL 統合によりその負荷を軽減できます。第二に、Amazon Aurora MySQL は行指向のデータベース、Amazon Redshift は列指向のデータベースなので、Zefo-ETL 統合を導入して両者を使い分けながらクエリを操作することで、効率的に分析できるようになります。これにより、HTAP (Hybrid Transactionla/Analytical Processing) と呼ばれる、トランザクション処理と分析処理の両方が行えるデータベースと同じような使い方が実現できるのです。 モンストシリーズでのデータ分析戦略 最後に、株式会社 MIXI の白川 裕介氏から、モンストシリーズにおけるデータ分析戦略についてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 モンストシリーズは 1 年弱で 6 個と多くのタイトルが出ており、内製開発と他社による開発のいずれもが共存しておりました。当初は各デベロッパーが個別最適化しながらゲーム開発していたのですが、その点に課題を感じた MIXI では統一されたルールを定義しました。そのなかで、今回は KPI などのデータ分析の方針のルールを取り上げてご紹介いただきました。 第一に、ログイン・課金・ゲームプレイといった全タイトルで共通の KPI ログを定義し、ログフォーマットも共通化して同じクエリで分析できるようにしています。加えて、それ以外の各タイトル固有の KPI ログは個別に取得しています。ログの取得は MIXI で検証して開発社にサンプルの実装を提供しました。 第二に、KPI ログの転送では、Amazon Kinesis Agent・Amazon Kinesis Data Streams・Amazon Kinesis Data Firehose を用いたデータ転送フローの標準仕様を策定しました。なお、Amazon Kinesis Data Streams がなくても構成は可能ですが、Amazon Kinesis Data Firehose の仕様上 PutRecord 時のデータごとの改行が必要だったり、恒常的な大量の流量を捌けないことがあったりする点に注意が必要です。なお、開発社によっては Fluent Bit や CloudWatch を用いたカスタマイズもしています。 第三に、Aurora MySQL スナップショットの方法にも 2 通りの方法を決めています。 1 つ目が SELECT INTO OUTFILE の SQL ステートメントを実行する方法です。ここでは、インスタンスへの負荷を考慮してリードレプリカを用いることや AWS Lambda でのタイムアウトを避けるため AWS Glue ジョブの Python Shell で実行することを推奨しています。2 つ目が Amazon S3 のエクスポート機能を用いる方法です。こちらは制約が多い代わりに簡単に実行できるものです。 以上に挙げた内容は、後から決めるのではなく最初に決めておくことが大事だと白川氏は強調しました。MIXI では、一定のルールを設けつつも後から柔軟に変更しています。そしてデータ形式やインフラの共通化により、リソースの最適化や横断的な同様のクエリでの分析の実現といったメリットがありました。 最後に 今回ご紹介したものをはじめとして、AWS 上には効率的に分析するための様々なサービスや機能があります。ゲームを発展させるのに分析は一つの重要な要素ですので、ご自身のゲームにおいてもぜひ活用をご検討ください。また、AWS for Games Live は AWS 公式ウェブマガジン builders.flash と連動して、定期的に開催しております。今回複数のセッションで紹介された現在 Public Preview 中の Zero-ETL 統合機能も、 builders.flash 内の記事 で取り上げていますので、ご興味があればぜひご覧ください。 ※この記事はTakumi Kawashimaが作成し、Hiroshi Sumiが代理で投稿しています。

AWS European Sovereign Cloud により、政府機関、規制が厳しい業界、およびそれらをサポートする独立系ソフトウェアベンダー (ISV) は、欧州連合 (EU) に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされる AWS インフラストラクチャ上で、機密データを保存したり、重要なワークロードを実行したりできるようになります。最初のリージョンはドイツ国内に設けられることになります。 背景 2022年末、当社は AWS Digital Sovereignty Pledge を発表し、クラウドで利用できる最先端の主権コントロールと機能のセットをお客様 (およびすべての AWS をご利用のお客様) に提供することをお約束しました。そのお知らせ以降、当社は、その誓約を守るためにいくつかの重要な一歩を踏み出しました。 2023 年 5 月 – AWS Nitro System が独立したサードパーティーによって検証され、AWS の誰かが AWS ホスト上のお客様のデータにアクセスすることを許可するいかなるメカニズムも含まれていないことが確認されたことを お知らせ しました。同時に、 AWS Key Management Service (KMS) 外部キーストア を利用することで、AWS の外部にキーを保存し、そのキーを使用して AWS に保存されているデータを暗号化できることをお知らせしました。 2023 年 8 月 – AWS 専有ローカルゾーン を 発表しました 。これは、AWS が完全に管理し、特定のお客様またはコミュニティ専用に構築され、お客様が指定する場所またはデータセンターに設けられるインフラストラクチャです。 AWS European Sovereign Cloud 今後の AWS European Sovereign Cloud は、フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム、スペイン、チューリッヒで既にオープンしている 8 つの既存の AWS リージョンとは別個であり、これらから独立したものとなります。これにより、既に使い慣れた AWS サービス、API、ツールが提供されると同時に、デプロイのための追加のオプションが提供されます。この設計は、データレジデンシー、運用上の自律性、回復力のニーズを満たすのに役立ちます。 このクラウドと既存の AWS グローバルクラウドの間の分離を維持するには、新しい AWS アカウントを作成する必要があります。作成するメタデータ (データラベル、カテゴリ、許可、設定など) は EU 内に保存されます。これは、支出データや請求データなどの AWS アカウント情報には適用されません。これらの情報は、一定量の使用と引き換えに適用される該当階層内で、有利な料金が確実に適用されるようにするために集計および使用されます。 前述のとおり、このクラウドは、EU に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされ、サポートは 24 時間年中無休で利用可能となる予定です。 AWS European Sovereign Cloud は、運用上、他のリージョンから独立し、別個のリージョン内の請求システムおよび使用量測定システムが使用されることになります。 初期のリージョン 初期のリージョンはドイツ国内に設けられることになります。これは、複数のアベイラビリティーゾーンを利用して立ち上げられます。これらの各アベイラビリティーゾーンは個別の異なる地理的位置に所在し、これらの間には十分な距離が確保されるため、単一のイベントがビジネスの継続性に影響を及ぼすリスクを大幅に軽減できます。 立ち上げが近づくにつれて、利用可能なサービスやインスタンスタイプなどに関するさらなる詳細が判明する予定です。 将来的には、このクラウド内のこのリージョンと他のリージョンは、 AWS Outposts および専有ローカルゾーン用の親リージョンとしても機能するようになる予定です。これらのオプションにより、分離と国内のデータレジデンシーに関してさらに柔軟な対応が可能になります。ご自身の所在国の 専有ローカルゾーン にご関心がおありの場合は、担当の AWS アカウントマネージャーにお問い合わせください。 準備を整えましょう 既存のリージョンのいずれかで今すぐアプリケーションの構築を開始し、リージョンの立ち上げ時にそれらを AWS European Sovereign Cloud に移行できます。特定のリージョンに固有の問題をより深く理解するために、現地の規制当局との対話を開始することもできます。 – Jeff ; 原文は こちら です。

AWS ニュースブログチームの全員が、ラスベガスで行われる毎年恒例のカスタマーカンファレンス、 AWS re:Invent の開催中に新しいサービスと機能を発表するための記事の執筆に全力で取り組んでいます! そして、私たちが皆さんに読んでいただくためのコンテンツを準備している間も、AWS のサービスチームは革新し続けています。以下は、10月16日週のリリースの概要です。 10月16日週のリリース 私が関心を持ったリリースをいくつかご紹介しましょう。 Amazon CodeCatalyst – CI/CD ワークフローをトリガーするための cron 式を追加できるようになりました。 これは、ワークフローを指定された時間に開始する手段を提供します。CodeCatalyst は、プロジェクトのコラボレーションツール、CI/CD パイプライン、および開発環境とデプロイ環境を統合する統合開発サービスです。 Amazon Route53 – お客様のトラフィックをお客様に最も近い AWS Local Zones にルーティング して、レイテンシーの影響を受けやすいワークロードのアプリケーションパフォーマンスを向上させることが可能になりました。詳細については、Route53 のドキュメントの「 Geoproximity routing 」を参照してください。 Amazon RDS – AWS がお客様のデータベースの TLS 証明書に署名するために使用するルート証明書は、2024 年に有効期限が切れます。データベース用の新しい証明書は、有効期限日の前に生成しておく必要があります。 このブログ記事には、そのステップバイステップ手順が詳しく説明されています 。AWS が生成した新しいルート証明書の有効期間は、 RSA2048 では今後 40 年、 RSA4098 および ECC384 では 100 年になります。AWS のデータベース証明書を更新する義務を負うのは、皆さんのプロとしてのキャリアの中でこれが最後になるでしょう。 Amazon MSK – Kafka クラスターを大規模に複製することは困難で、大抵の場合は、インフラストラクチャとレプリケーションソリューションを独自に管理しなければなりません。AWS は、同じ AWS リージョン内、または複数の AWS リージョンにまたがる Kafka クラスターのためのフルマネージドレプリケーションソリューション、 Amazon MSK Replicator の提供を開始しました。 Amazon CodeWhisperer – Amazon CodeWhisperer Professional の次なる機能のプレビューが開始されました。 これからは、プライベートコードベースで CodeWhisperer をトレーニングできるようになります 。この機能は、より適切な提案を組織の開発者に提供することによって、組織のプライベートライブラリやフレームワークに対する毎日のコーディングで開発者をよりよくサポートできるようにします。 Amazon EC2 – 第 7 世代のメモリ最適化 EC2 インスタンス (R7i) が利用可能になりました 。これらのインスタンスは、第 4 世代インテル Xeon スケーラブルプロセッサー ( Sapphire Rapids ) を使用しています。このインスタンスファミリーは、最大 192 個の vCPU と 1,536 GB のメモリを提供します。これらは、インメモリデータベースやキャッシュなどのメモリ集約型アプリケーションに最適です。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供が開始されました。 Amazon Bedrock が欧州 (フランクフルト) で利用可能になりました 。ヨーロッパのお客様は、そのデータが欧州連合内に維持されることを確実にしなければならない場合が多いため、この機能はこれらのお客様にとって重要です。これからは、プロンプトやカスタム設定がヨーロッパ内に維持されるという確信を持ったうえで、アプリケーションに生成系 AI 機能を組み込み、大規模言語モデルにアクセスすることができるようになります。 Amazon EC2 が、複数のインスタンスファミリーのフットプリントを拡大し、カナダ (中部) と南米 (サンパウロ) で m6gd インスタンス 、 カナダ (中部) で c6a インスタンス、カナダ (中部) と欧州 (ミラノ) で m6a インスタンス、そして米国西部 (北カリフォルニア) とアジアパシフィック (シンガポール) で r6a インスタンス の提供を開始しました。最後に、欧州 (チューリッヒ) では m6id インスタンスが利用できるようになりました 。 Amazon EMR Managed Scaling がアジアパシフィック (ジャカルタ) で利用可能になりました。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログが、 Java アプリケーションと Go アプリケーション内に Amazon Bedrock を統合する方法を説明する新しい記事を発表しました。また、私の同僚である Brooke も、 re:Invent に初めて参加する人のためのサバイバルガイド を書きました。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。このカンファレンスは、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、および ブラジル (11 月 4 日) で開催されます。 AWS Innovate: Every Application Edition – 無料のオンラインカンファレンスに参加して、 セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 26 日に開催される AWS Innovate Online アジアパシフィック & 日本 にぜひ登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – このカンファレンスに参加 して、AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent ハイライト を確認してください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 10月23日週のニュースは以上です。re: Invent ブログ記事の執筆に戻ろうと思います。 10月30日週の Weekly Roundup もお楽しみに! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) コンソールで [証明書の更新] を目にしても驚かないでください。 Amazon RDS for MySQL、MariaDB、SQL Server、Oracle、PostgreSQL、Amazon Aurora のデータベースインスタンスに接続するために、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を証明書の検証とともに使用しているか、または使用する予定がある場合、ルート証明書の有効期限が切れる前に、DB インスタンスとアプリケーションの両方で新しい認証機関 (CA) 証明書をローテーションする必要があります。 DB インスタンスのほとんどの SSL/TLS 証明書 ( rds-ca-2019 ) は、 2020 年の証明書の更新 後、2024 年に期限切れになります。2022 年 12 月に、40 年間有効な CA 証明書 ( rds-ca-rsa2048-g1 ) と 100 年間有効な CA 証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) を新しくリリースしました。これにより、CA 証明書をローテーションした後、長期にわたって、再度ローテーションする必要はありません。 影響を受けるリージョンと、それらの rds-ca-2019 の有効期限の一覧を次に示します。 有効期限 リージョン 2024 年 5 月 8 日 中東 (バーレーン) 2024 年 8 月 22 日 米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパウロ) 2024 年 9 月 9 日 中国 (北京)、中国 (寧夏) 2024 年 10 月 26 日 アフリカ (ケープタウン) 2024 年 10 月 28 日 欧州 (ミラノ) 2061 年まで影響なし アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、欧州 (スペイン)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (UAE)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) 次のステップでは、アプリケーションからデータベースインスタンスへの接続を維持するために証明書をローテーションする方法を示します。 ステップ 1 – 影響を受ける Amazon RDS リソースを特定する 前述したように、 Amazon RDS コンソール の [証明書の更新] ページで影響を受ける DB インスタンスの総数を確認し、影響を受けるすべての DB インスタンスを表示できます。注: このページには、現在のリージョンの DB インスタンスのみが表示されます。複数のリージョンに DB インスタンスがある場合は、各リージョンの証明書の更新のページを確認して、古い SSL/TLS 証明書を使用しているすべての DB インスタンスを表示します。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して describe-db-instances を呼び出し、期限切れの CA を使用するインスタンスを見つけることもできます。クエリにより、アカウントと us-east-1 リージョン内の RDS インスタンスのリストを表示できます。 $ aws rds describe-db-instances --region us-east-1 | jq -r '.DBInstances[] | select ((.CACertificateIdentifier != "rds-ca-rsa2048-g1") and (.CACertificateIdentifier != "rds-ca-rsa4096-g1") and (.CACertificateIdentifier != "rds-ca-ecc384-g1")) | "DBInstanceIdentifier: (.DBInstanceIdentifier), CACertificateIdentifier: (.CACertificateIdentifier)"' ステップ 2 – データベースクライアントとアプリケーションを更新する DB インスタンスに新しい証明書を適用する前に、接続するために SSL/TLS およびサーバー証明書を使用するクライアントとアプリケーションの信頼ストアを更新する必要があります。 現在、アプリケーションが接続するための前提条件として証明書の検証が必要かどうかを、DB インスタンス自体から簡単に判断する方法はありません。ここでの唯一のオプションは、アプリケーションのソースコードまたは設定ファイルを検査することです。 DB エンジン固有のドキュメント には、極めて一般的なデータベース接続インターフェイスで注意すべき点が概説されていますが、証明書の検証が使用されているかどうか、および特定のクライアントアプリケーションのためにアプリケーションの SSL/TLS 証明書を更新する正しい方法をアプリケーションデベロッパーに確認することを強くお勧めします。 アプリケーションの証明書を更新するために、古い CA と新しい CA の両方の証明書を含む 新しい証明書バンドル を使用できます。これにより、アプリケーションを安全にアップグレードし、移行期間中も接続を維持できます。 各 DB エンジンについての SSL/TLS 接続の確認とアプリケーションの更新については、次のトピックを参照してください。 新しい SSL/TLS 証明書を使用して MariaDB DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Microsoft SQL Server DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して MySQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Oracle DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Aurora MySQL DB クラスターに接続するようにアプリケーションを更新する 。 新しい SSL/TLS 証明書を使用して Aurora PostgreSQL DB クラスターに接続するようにアプリケーションを更新する 。 ステップ 3 – 非本番 RDS インスタンスで CA ローテーションをテストする すべての信頼ストアで新しい証明書を更新した場合は、非本番環境で RDS インスタンスを使用してテストする必要があります。この設定は、本番環境と同じデータベースエンジンとバージョンを備えた開発環境で実行します。また、このテスト環境は、本番と同じコードと設定を使用してデプロイする必要があります。 テストデータベースインスタンスで新しい証明書をローテーションするには、 Amazon RDS コンソール で、変更する DB インスタンスについて [変更] を選択します。 [接続] セクションで、 rds-ca-rsa2048-g1 を選択します。 [続行] を選択して、変更の概要を確認します。変更をすぐに適用する場合は、 [すぐに適用] を選択します。 AWS CLI を使用して DB インスタンスのために CA を rds-ca-2019 から rds-ca-rsa2048-g1 に変更するには、 modify-db-instance コマンドを呼び出し、 --ca-certificate-identifier オプションを使用して DB インスタンス識別子を指定します。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --apply-immediately これは、本番データベースインスタンスで新しい証明書を手動でローテーションする方法と同じです。参照した信頼ストアまたは CA 証明書バンドルを使用したローテーションの後、アプリケーションが SSL/TLS を使用して問題なく再接続することを確認します。 新しい DB インスタンスを作成する場合、デフォルトの CA は 2024 年 1 月 25 日までは rds-ca-2019 のままですが、その後は rds-ca-rsa2048-g1 に変更されます。新しい CA を設定して新しい DB インスタンスを作成する場合、CA オーバーライドを設定して、すべての新しいインスタンスの起動で任意の CA が使用されるようにできます。 $ aws rds modify-certificates \ --certificate-identifier rds-ca-rsa2048-g1 \ --region <region name> これは、RDS DB インスタンスが存在するすべてのリージョンで行う必要があります。 ステップ 4 – 本番 RDS インスタンスを安全に更新する 非本番環境でのテストが完了したら、本番環境で RDS データベース CA 証明書のローテーションを開始できます。ステップ 3 に示すように、DB インスタンスを手動でローテーションできます。今日のエンジンの多くは再起動を必要としませんが、メンテナンス期間に再起動をスケジュールすることが推奨されることにご留意ください。 ステップ 1 の [証明書の更新] ページで、ローテーションする DB インスタンスを選択します。 [スケジュール] を選択すると、次のメンテナンス期間に証明書のローテーションをスケジュールできます。 [今すぐ適用] を選択すると、ローテーションをすぐに適用できます。 [スケジュール] を選択すると、証明書のローテーションを確認するよう求めるプロンプトが表示されます。このプロンプトは、更新のスケジュールウィンドウも示します。 (すぐに、またはメンテナンス期間中に) 証明書が更新された後、データベースとアプリケーションが想定どおりに動作していることを確認する必要があります。 今日の DB エンジンのほとんどでは、証明書を更新するためにデータベースを再起動する必要はありません。CA 更新のためだけにデータベースを再起動したくない場合は、 modify-db-instance コマンドで --no-certificate-rotation-restart フラグを使用できます。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --no-certificate-rotation-restart エンジンの再起動が必要かどうかを確認するには、 describe-db-engine-versions コマンドの出力で SupportsCertificateRotationWithoutRestart フィールドを確認します。このコマンドを使用すると、再起動なしでのローテーションをサポートしているエンジンを確認できます。 $ aws rds describe-db-engine-versions \ --engine <engine> --include-all --region <region> | jq -r '.DBEngineVersions[] | "EngineName: (.Engine), EngineVersion: (.EngineVersion), SupportsCertificateRotationWithoutRestart: (.SupportsCertificateRotationWithoutRestart), SupportedCAs: ([.SupportedCACertificateIdentifiers | join(", ")])"' データベースインスタンスのために SSL/TLS を使用しない場合でも、CA をローテーションすることをお勧めします。将来的に SSL/TLS を使用する必要がある場合があります。その場合、JDBC コネクタや ODBC コネクタなどの一部のデータベースコネクタは、接続する前に有効な証明書をチェックします。その際、CA の期限が切れていると、SSL/TLS を使用できない可能性があります。 DB インスタンスを手動で変更することによる証明書の更新、サーバー証明書の自動ローテーション、信頼ストアに証明書をインポートするためのサンプルスクリプトの検索の詳細については、「 Amazon RDS ユーザーガイド 」または「 Amazon Aurora ユーザーガイド 」を参照してください。 留意点 知っておくべき重要な事項をいくつか次に示します。 Amazon RDS Proxy と Amazon Aurora Serverless は、 AWS Certificate Manager (ACM) からの証明書を使用します。SSL/TLS 証明書をローテーションする際に Amazon RDS Proxy を利用している場合は、Amazon RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。Aurora Serverless を利用している場合、SSL/TLS 証明書をローテーションする必要はありません。 現在から 2024 年 1 月 25 日 まで – 新しい RDS DB インスタンスには、 create-db-instance API の ca-certificate-identifier オプションで別の CA を指定しない限り、デフォルトで rds-ca-2919 証明書が含まれます。または、上記のセクションで言及したように、アカウントのためにデフォルトの CA オーバーライドを指定します。 2024 年 1 月 26 日 以降 – 新しいデータベースインスタンスは、 rds-ca-rsa2048-g1 証明書を使用するようデフォルト設定されます。新しいインスタンスのために別の証明書を使用することを希望する場合は、AWS コンソールまたは AWS CLI を使用して、どの証明書を使用するかを指定できます。詳細については、 create-db-instance API ドキュメント を参照してください。 Amazon RDS for SQL Server を除き、今日の RDS および Aurora エンジンのほとんどは、その最新バージョンにおいて、データベースの再起動なしでの証明書のローテーションをサポートしています。 describe-db-engine-versions を呼び出し、応答フィールド SupportsCertificateRotationWithoutRestart を確認します。このフィールドが true に設定されている場合、インスタンスでは CA 更新のためにデータベースを再起動する必要がありません。 false に設定すると、再起動が必要になります。詳細については、AWS ドキュメントの「 データベースのために CA を設定する 」を参照してください。 ローテーションされた CA は、各 DB インスタンスにインストールされる DB サーバー証明書に署名します。DB サーバー証明書は、信頼されたサーバーとして DB インスタンスを識別します。DB サーバー証明書の有効期間は、DB エンジンとバージョンによって異なり、1 年間または 3 年間です。CA がサーバー証明書の自動ローテーションをサポートしている場合、RDS は DB サーバー証明書のローテーションも自動的に処理します。DB サーバー証明書のローテーションの詳細については、AWS ドキュメントの「 サーバー証明書の自動ローテーション 」を参照してください。 40 年間有効な証明書 ( rds-ca-rsa2048-g1 ) または 100 年間有効な証明書を使用することを選択できます。RDS インスタンスによって使用される期限切れの CA は、RSA2048 鍵アルゴリズムと SHA256 署名アルゴリズムを使用します。 rds-ca-rsa2048-g1 はまったく同じ設定を使用するため、互換性の点で最適です。100 年間有効な証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) は、 rds-ca-rsa2048-g1 よりも安全な暗号化スキームを使用します。これらを使用する場合は、本番前環境で十分にテストし、データベースクライアントとサーバーがリージョンで必要な暗号化スキームをサポートしていることをダブルチェックする必要があります。 すぐに始めましょう! 証明書の有効期限が切れるまであと 1 年間ある場合でも、チームと連携して計画を開始すべきです。SSL/TLS 証明書を更新するには、有効期限が切れる前に DB インスタンスを再起動する必要がある場合があります。有効期限前にアプリケーションを更新するようにスケジュールし、本番環境でこれらのステップを完了する前に、ステージングまたは本番前のデータベース環境でテストを実行することを強くお勧めします。SSL/TLS 証明書の更新の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 SSL/TLS 接続を使用しない場合、データベースセキュリティのベストプラクティスは、SSL/TLS 接続を使用し、接続認証プロセスの一部として証明書の検証をリクエストすることです。SSL/TLS を使用して DB インスタンスへの接続を暗号化する方法の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 ご質問や問題がある場合は、ご利用のサポートプランに応じて、通常の AWS サポート までお問い合わせください。 – Channy 原文は こちら です。

モダンアプリケーションは、モジュール式かつ分散型のコンポーネントで構築されています。お客様は、特にハイブリッドクラウド環境において、サービスコンポーネント間のアプリケーションネットワーキングをシンプル化する柔軟な方法を求めています。 VMware Cloud on AWS を利用することで、お客様はオンプレミスの vSphere 環境からのワークロードとアプリケーションをシームレスなハイブリッドクラウド体験で Software Defined Data Center (SDDC) に簡単に移行できます。 ワークロードを VMware Cloud on AWS に移行するにつれ、SDDC 上で実行されている既存のアプリケーションと、ネイティブ AWS サービスを使用してデプロイされた新しいサービスとの接続要件に対処することが不可欠となってきます。 異なる AWS アカウントや Amazon Virtual Private Cloud (VPC) 間のサービス接続をサポートするには通常、 VPC ピアリング 、 AWS Transit Gateway 、 AWS PrivateLink 、 サービスメッシュ プロキシなど、追加のネットワーキングサービスとコンポーネントをプロビジョニングする必要があります。 さらに、複数の AWS アカウントと VPC を持つお客様は、重複する CIDR ブロックや環境分離の要件などの課題に直面することが多く、サービス間のアンダーレイとなる IP 接続性の構築をさらに複雑にします。 この記事では、 Amazon VPC Lattice が SDDC やクラウドネイティブ環境全体のサービス間通信を、アンダーレイネットワークの複雑さを抽象化しながらシンプル化する方法を見ていきます。また、VPC Lattice を活用して、VMware Cloud on AWS からクラウドネイティブサービスへアプリケーションをシームレスに変換、移行できることも説明します。 Amazon VPC Lattice 概要 2023 年 3 月、AWS はアプリケーションネットワーキングサービス「Amazon VPC Lattice」の 一般提供を発表 しました。VPC Lattice は、サービス間通信のディスカバリと接続を容易にするものです。 VPC Lattice は、論理的なアプリケーションレイヤーネットワークである サービスネットワーク を作成します。これにより、異なる AWS アカウントや Amazon VPC 間でのサービスネットワーク全体のクライアント (コンシューマー) とサービス (プロバイダー) 間のアプリケーション通信を、アンダーレイネットワークの複雑さを抽象化してシンプル化します。 以下の図を元に Amazon VPC Lattice の主なコンポーネントを確認しましょう。 図1 – Amazon VPC Lattice の主なコンポーネント サービス : VPC Lattice サービスは、特定のタスクや機能を提供するカスタマーアプリケーションを表します。サービスは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、サーバーレス関数など、さまざまなコンピュートオプションで実行できます。VPC Lattice サービスは、 AWS Resource Access Manager (RAM) を使用して他の AWS アカウントと共有できます。VPC Lattice サービスには、次の要素が含まれます。 ターゲットグループ – アプリケーションやサービスを提供するリソースの集まりです。ターゲットには、EC2 インスタンス、IP アドレス、 AWS Lambda 関数、 Application Load Balancer 、 Kubernetes Pod を指定できます。 リスナー – 定義されたプロトコル (HTTP/HTTPS) とポート番号に基づいて、ターゲットグループ内のターゲットに接続リクエストをルーティングするプロセスです。 ルール – 優先順位、条件、アクションが定義されたアプリケーションフローを制御するルーティングルールです。 サービスネットワーク : サービスの集合を論理的に区切る境界。VPC Lattice サービスと VPC をサービスネットワークに関連付けて、サービス接続を容易にすることができます。RAM を使用して、サービスネットワークを他のアカウントと共有することもできます。 サービスディレクトリ : 所有または RAM 経由で共有されているすべての VPC Lattice サービスの中央レジストリ。 認証ポリシー : サービスへのアクセスを制御するために、サービスネットワークまたはサービスに関連付けることができる AWS Identity and Access Management (IAM) ポリシー。 VPC がサービスネットワークと関連付けられると、VPC 内のクライアントは Domain Name System (DNS) を使用して、サービスネットワークに登録されたサービスを自動的に検出できるようになります。さらに、登録済みサービスのすべてのアプリケーション間トラフィックは VPC Lattice を通過するようになります。 VPC Lattice は、IAM ベースの認証ポリシーを使用したコンテキスト固有の認証によって、アプリケーション接続のセキュリティも強化します。これにより、顧客は細かいトラフィック制御とエンドツーエンドの可観測性が得られます。 VPC Lattice の詳細については、この ブログ記事 と Amazon VPC Lattice リファレンスアーキテクチャ を参照してください。 VMware Cloud on AWS と VPC Lattice の統合 SDDC ENI を介した Application Load Balancer の活用 VMware Cloud on AWS 上で実行されているアプリケーションを Amazon VPC Lattice と統合するには、Application Load Balancer が必要です。これは、VPC Lattice が一意のリンクローカルアドレスレンジの 169.254.171.0/24 を使用しているためです。このアドレスレンジは VPC 内でのみローカルにアクセス可能で、SDDC 外部にルーティングできません。 そこで、 Connected VPC 内に Application Load Balancer をデプロイすることで、 VPC Lattice からの着信リクエストを終端できます。これにより、広帯域かつ低レイテンシの SDDC Elastic Network Interface (ENI) を使用して、SDDC 上にホストされているワークロードにアプリケーションフローを IP ターゲット としてルーティングできます。サンプルアーキテクチャは以下の通りです。 図2 – Application Load Balancer を介した SDDC ENI 統合   SDDC と Connected VPC 間のデータ転送は、SDDC とネイティブサービスが同じ AWS アベイラビリティーゾーン (AZ) 内にデプロイされている限り、いかなる egress 通信コストも発生しません。 以下のスクリーンショットに示すように、Connected VPC 内に 内部 Application Load Balancer をプロビジョニングすると、 ユーザーガイド に従って、SDDC 上で実行されているアプリケーション向けの Lattice ターゲットグループ (およびサービス) を作成できます。 図3 – VPC Lattice ターゲットグループとして Application Load Balancer を登録  VMware Transit Connect を介した Application Load Balancer の活用 Application Load Balancer を Lattice サービスとは分けた VPC に展開し、 VMware Transit Connect を介してアプリケーショントラフィックを SDDC に渡すという選択肢もあります。以下の図のような構成です。 図4 – VMware Transit Connectを介した Application Load Balancer の統合 これは、Application Load Balancer がセキュリティ検査の要件のために Central Ingress VPC に展開されている場合に有効です。サービスネットワークは、別の AWS アカウントに存在し、AWS RAM を使用して ingress VPC と共有されることもあります。 VMware Transit Connect は、VMware が管理する AWS Transit Gateway ソリューションで、お客様のSDDC、クラウドネイティブサービス、オンプレミスリソース間の高速かつ回復性のある接続を提供します。SDDC と Amazon VPC を接続するために VMware Transit Connect をプロビジョニングする方法については、 VMware のブログ記事 を ( 日本語ブログはこちら ) 参照してください。 お客様の環境で AWS Transit Gateway をすでに利用している場合は、ingress Application Load Balancer で着信サービスリクエストを終端し、アプリケーションフローを リージョン内ピアリング を使用した AWS Transit Gateway とVMware Transit Connect 経由で SDDC に配信することが可能です。以下の図は、このサンプルアーキテクチャを示しています。 図 5 – リージョン内ピアリングによる Application Load Balancer 統合 SDDCとネイティブサービス間のアプリケーション接続のシンプル化 VMware Cloud on AWS のお客様が、アプリケーションネットワーキングをシンプル化し、変革を加速する VPC Latticeの活用例を見ていきましょう。 最初の例では、お客様はオンプレミスのアプリケーション群を VMware Cloud on AWS に移行しました。新しくSoftware-as-a-Service (SaaS) 製品のローンチを計画しており、これには SDDC-01 上のバックエンド APIサービス (Service 1) を、ネイティブ AWS 環境で最近構築された 2 つのマイクロサービス (Service2, Service3) と統合する必要があります。これらのマイクロサービスは、下の図に示すように、異なる AWS アカウントと VPC にまたがる AWS Lambda と Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされています。 図 6 – SDDC アプリケーションと複雑性のある AWS 環境の統合 お客様は以下のサービス統合の要件と課題があります: VPC-02 の CIDR と SDDC-01 の CIDR は一部重複しています。 VPC-03 は、外部のサービスプロバイダーが所有する別の AWS Organization の下にデプロイされているため、直接 IP 接続を確立することは許可されていません。 Service 2 と Service 3 は、Service 1 にアクセスする必要があります。 Service 2 と Service 3 は、双方向で通信する必要があります。 この場合、マルチアカウント環境における SDDC、コンテナ、サーバーレス関数全体で、セキュアかつプライベートなアプリケーション間接続を構築するために、VPC Lattice を活用できます。 VPC Lattice のユニークなリンクローカルアドレスレンジは、VPC や SDDC 間の潜在的なIPアドレスの競合問題も解消します。 まず、SDDC-01 にアタッチされた Connected VPC 内に、Service 1 の Application Load Balancer を作成する必要があります。これは、Lattice サービスはネイティブ VPC 内でのみアクセスできるため、Service 1 のすべての着信サービスリクエストを Connected VPC で終端するためです。 次に、VPC Lattice サービスネットワークを作成し、AWS RAM を介して 3 つのサービスアカウント (Account 1 ~3) と共有します。これにより、各アカウントで個別の VPC Lattice サービス (Service 1~3 向け) を作成し、サービスネットワークに関連付けることができます。 最後に、Service 2 と Service 3 が双方向通信を必要とするため、VPC-02 と VPC-03 をサービスネットワークに関連付ける必要があります。 ただし、Service 3 はバックエンドサービスであるため、Connected VPC をサービスネットワークに関連付ける必要はありません。 以下にアーキテクチャ、ソリューションの概要を示しています。 図 7 – VPC Lattice によるアプリケーション間ネットワーキングのシンプル化 VPC Lattice を使用すると、マルチアカウントおよびマルチ VPC 環境における VMware Cloud on AWS アプリケーションとクラウドネイティブサービス間の相互接続を素早く構築できます。また、AWS Transit Gateway、AWS PrivateLink、 Private NAT Gateway など、追加のネットワークインフラストラクチャサービスの構築による複雑さと管理オーバーヘッドを排除できます。 さらに、VPC Lattice には Lattice サービスごとに一意の DNS 名を自動的に割り当てる、組み込みの DNS ベースのサービスディスカバリーがあります。 Amazon Route 53 プライベートホストゾーンを利用することで、サービスの CNAME、またはエイリアスレコードをカスタマイズすることもできます。 VPC Lattice によるアプリケーション変革の加速 次の例では、VPC Lattice が VMware Cloud on AWS のお客様がアプリケーションをシームレスにクラウドネイティブサービスに変換・移行するのにどのように役立つかを探っていきます。 お客様は SDDC 上で実行されているレガシーアプリケーションのリファクタリングを進めており、それを AWS Lambda のサーバーレス関数に再構築しました。SDDC 内のレガシーアプリケーションから Lambda 関数へのサービストラフィックの切り替え前に、アップストリームの他のサービスへの潜在的な影響を調査するための一連のカナリアテストを実施したいと考えています。 Amazon VPC Lattice は、このシナリオのような ブルー/グリーン や カナリアスタイル のロールアウトなど、一般的なデプロイメントパターンをサポートしています。VPC-02 の Lambda 関数を使用する 1 つのターゲットグループと、Connected VPC 内の Application Load Balancer を公開して SDDC-01 上のレガシーアプリケーションに向けたもう 1 つのターゲットグループで VPC Lattice サービスを設定できます。 その後、以下の図に示すように、リクエスト条件 (パス、メソッド、ヘッダー) に基づいて、 2 つのターゲットグループ間でトラフィックを分散する重み付けルーティングを利用できます。 図 8 – VPC Lattice による SDDC と AWS Lambda を横断したカナリアロールアウト VPC Lattice は、サービス間の詳細なアクセスログを提供します。サポートされているログ配信ターゲットには、 Amazon Simple Storage Service (Amazon S3) バケット、 Amazon Kinesis Data Firehose 、 Amazon CloudWatch のロググループが含まれます。これにより、お客様は必要なログの詳細を迅速に取得し、特定のサービスまたはサービスネットワーク全体で発生し得る問題を特定および分析できます。 VPC Lattice は、アプリケーションの変革とモダナイゼーションを促進し、新しいアイデアを簡単に試すことができ、必要に応じて迅速にロールバックできるようにします。 これにより、サービス移行時のリスクを軽減し、最終的にエンドユーザーの体験を向上させます。 追加の考慮事項 サービスネットワーク全体でのネットワークレベルの保護を実施するため、VPC Lattice の AWS マネージドプレフィックスリスト をセキュリティグループで活用することをおすすめします。 さらに、個々のサービスまたはサービスネットワーク全体のいずれかに、強力な認証とコンテキスト固有の認可を適用するために、サービスレベルの認証ポリシーを使用できます。詳細は、こちらの AWS ブログ記事 を参照してください。 デフォルトでは、VPC Lattice のサービスはリンクローカルアドレスレンジがルーティング不可能なため、VPC 内からのみアクセスできます。 Lattice サービスへの外部接続性を提供するには、 Elastic Load Balancing とプロキシのフリートを使用した ingress VPC が必要です。サンプルアーキテクチャと実装ガイドは、この AWS ブログ記事 を参照してください。 AWS 責任共有モデル に従って、AWS インフラストラクチャ上にホストされるコンテンツの管理はお客様の責任となります。この ユーザーガイド に従って Amazon VPC Lattice を設定し、セキュリティとコンプライアンス目標を満たしてください。また、VMware Cloud on AWS の ネットワークとセキュリティの包括的なガイド も参照してください。 VMware Cloud on AWS 環境の強化に役立つ リソース があります。 価格については、Amazon VPC Lattice の 料金ページ をご確認ください。 AWS Transit Gateway や VMware Transit Connect の 料金 もご参照ください。 まとめ この投稿では、Amazon VPC Lattice が VMware Cloud on AWS のお客様にどのようにアプリケーションネットワーキングをシンプル化し、変革を加速できるかについて説明しました。一般的な統合アーキテクチャと使用例の概要についてもご紹介しました。 より詳細については、以下のリンクをご参考ください。 VMware Cloud on AWS ハイブリッドネットワークデザインパターン VPC Lattice のご紹介 – サービス間通信のためにネットワーキングを簡素化する Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 本稿は、ソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら です。

このブログは 2023 年 10 月 2 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 (原文はイベント開催前に掲載された為、イベント期間中のみの活動については省略しています) Unreal Engine (UE) の開発会社である Epic Games が主催する毎年恒例の開発者カンファレンスである Unreal Fest は、 10 月 3 日から 5 日までニューオリンズで開催され、 3 日間の講演セッション、ハンズオンワークショップ、業界に特化したトラックを開催します。このカンファレンスにはゲーム開発者、デザイナー、アーティスト、様々な業界の専門家が一堂に会し、最新テクノロジーについてより深い洞察を得たり、専門家から学んだり、 UE のクリエイターやゲーム開発者と交流したりします。このブログ記事では Unreal Fest 2023 での AWS for Games のプレゼンスについて取り上げます。 UE のゲーム開発者が AWS を使用してリアルタイム 3D 体験をどのようにスケーリングしているかについては、 AWS と Unreal Engine をご覧ください。 現地での活動 AWS は今年 Unreal Fest のプラチナスポンサーになったことを誇りに思います。これには、パートナーセッション、ブースプレゼント、 AWS 業界の専門家によるライブ製品デモが含まれます。 AWS で Unreal Engine のゲームを構築しているお客様 高度な 3D ゲーム開発テクノロジーと専用のグローバルインフラストラクチャ機能を組み合わせることで、ゲームスタジオがどのようにゲームを構築、運営、成長させているかをご紹介します。 Epic Games は 2018 年にアマゾンウェブサービス （AWS） を全面的に採用し、ビジネスに不可欠なストレージ、分析、スケーリング機能を提供しました。これは毎日約 1,500 万人のアクティブユーザーがいるオンラインゲーム「フォートナイト」のリリースで爆発的に増加しました。フォートナイトは、世界中のゲームサーバー、バックエンドサービス、ウェブサイトを含め、ほぼすべて AWS 上で運営されています。詳細は こちら をご覧ください。 Odyssey Interactive は 2020 年に設立されたウォータールーを拠点とするゲームスタジオで、最初のゲームであるオメガストライカーズの発売と拡大のための費用対効果の高いソリューションを求めていました。オメガストライカーズは UE をベースに構築された 3 対 3 のエキサイティングなフットボールバトルゲームです。実績のある AWS と UE によるソリューションにより、 Odyssey Interactive はバックエンドのインフラストラクチャではなく優れたゲームの制作に集中できるようになりました。こちらの お客様のビデオ をご覧ください。 QXR Studios の共同創設者である Graeme Devine 氏は次のように語っています。「これまでは 100人 以上のチームがこのレベルで成果を出すのに 5 年の期間と 2500 万ドルがかかっていました。業界としては AWS や UE のようなツールにより、テクノロジーの基盤となるサービスに加えて、世界中のアーティストやモデラーにアクセスできるようになりました。これにより小規模なゲーム会社でも AAA のゲームコンテンツを制作できるようになり、ワクワクしています」。こちらの お客様のブログ をご覧ください。 Red Barrels はモントリオールに拠点を置く独立系ゲームスタジオで、スタジオの設立当初から UE をベースに開発を続けています。同社は最初のマルチプレイヤータイトルである「 Outlast Trials 」のゲームサーバーを管理するソリューションを必要としていました。 Red Barrels は UE と AWS の両方を選択しました。これはこれらのテクノロジーがゲーム開発プロセスにパワーと柔軟性をもたらすためです。こちらの お客様のビデオ をご覧ください。 Behaviour Interactive はカナダ最大のゲームスタジオの 1 つで、受賞歴のある非対称型マルチプレイヤーホラーゲーム「 Dead by Daylight 」は 2016 年の発売以来 5,000 万人を超えるプレイヤー数を獲得しています。 UE と AWS により、スタジオは忠実度の高いゲーム体験を制作し、何 100 万人ものプレイヤーに自信を持ってスケールできるようになりました。こちらの お客様のビデオ をご覧ください。 AWS での Unreal Engine 利用例 AWS for Games には、UE ゲーム開発者がコストを削減し、反復作業を迅速に行い、より良いプレイヤー体験を世界規模で提供できるよう支援する、用途別のポートフォリオが用意されています。 仮想ワークステーション – AWS 上の Epic Unreal Engine 5 ワークステーションは、 3D データをホストしてレンダリングするための高価なハードウェアや物理ワークステーションを必要とせずに、忠実度が高く没入感のある 3D 体験を世界中にシームレスに提供します。この Amazon Machine Image (AMI) には UE 5.2 とその動作に必要なものが予め用意されているため、ダウンロードやインストールなしでクラウドで直接制作作業を行う事ができます。詳細は こちら をご覧ください。 ビルドパイプライン – AWS 上の Incredibuild は、 UE の開発者と DevOps の管理者に、ゲームを継続的にビルド、改善、予定通りリリースするためのスケーラブルなプラットフォームを提供する強力なソリューションです。詳細は こちら をご覧ください。 バージョン管理 – AWS 上の Perforce Helix Core は、グローバルな規模と優れたパフォーマンスを実現するエンタープライズ向けのバージョン管理システムです。これは信頼できる単一のソースを UE のデジタルアセットに提供することで、グローバルなチームや大規模なバイナリアセットを管理できるようにします。詳細は こちら をご覧ください。 ゲーム QA とテスト – Amazon GameLift Anywhere は、環境内のハードウェアを統合する事で、ローカルワークステーションでリアルタイムにゲームプレイのモニタリングとデバッグが行える様高速化します。詳細は こちら をご覧ください。 ゲームサーバーホスティング – AWS Graviton3 プロセッサを搭載した Amazon GameLift の専用ゲームサーバー管理サービスは、計算集約型の UE ゲームに最適なコストパフォーマンスを実現します。 Unreal Engine 用 Amazon GameLift Plugin は、 Windows および Mac OS 用の UE 5、 UE 5.1、 UE 5.2、 UE 5.3 をサポートしており、最新の Amazon GameLift SDK 5 以上の API が含まれているため、お客様はUnreal Engine Editor でゲームをビルド、テスト、デプロイできます。詳細は こちら をご覧ください。 ゲーム分析 – AWS のゲーム分析パイプラインは、ゲーム開発者がスケーラブルなサーバーレスデータパイプラインを立ち上げ、 UE で作られたゲームクライアントのアクティブユーザーとビルドから生成されたプレイヤーデータを取り込み、保存、分析するのに役立ちます。詳細は こちら をご覧ください。 カスタムゲームバックエンドホスティング – AWS でのカスタムゲームバックエンドホスティングのガイダンスでは、 UE 5 のサンプルコードとともに、カスタマイズされた軽量でスケーラブルなクロスプラットフォーム向けのID認証機能をデプロイする方法を示しています。詳細は こちら をご覧ください。 ゲーム開発者が AWS 上で UE のゲームを構築、実行、成長させるのに役立つ、 7 つの専用機能 終わりに Unreal Fest はさまざまな業界のデベロッパーやクリエイターが一堂に会し、新しいプロジェクトについて学び、最新テクノロジーのハンズオントレーニングを受け、他のクリエイターと出会い、ネットワークを築くための今年のプレミアイベントです。 UE のゲームの開発者が、 AWS でゲームのワークロードと体験をどのように変革しているかについての詳細は AWS と Unreal Engine のホームページをご覧ください。 翻訳はソリューションアーキテクトの長田が担当しました。

2023 年 9 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Batch 入門編 HPC や機械学習などのバッチ処理を AWS 上で実現できる AWS Batch ついて入門編の内容をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 HPC や機械学習などのバッチ処理をクラウド上で実行することについ て興味のある方。 Amazon VPC / Amazon EC2 / Amazon S3 などの概要知識がある方。 本 BlackBelt で学習できること AWS Batch の概要と、キーコンポーネント、ワークロードごとのデザインパターンについて学習することができます。 スピーカー 小林広志 ソリューションアーキテクト Amazon EMR 基礎編 Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR について、サービスの基礎的な内容を解説します。 資料（ PDF ） 対象者 ビッグデータを扱うシステムのインフラエンジニア、データエンジニア、および、機械学習エンジニア 本 BlackBelt で学習できること Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR を利用するために必要となるサービスの基礎的な内容を理解することができます。 スピーカー 川村誠 ソリューションアーキテクト AWS Secrets Manager AWS Secrets Manager はシークレットのライフサイクルを一元的に管理し、保存・取得・更新・アクセス制限・監査・モニタリングを行うことができます。 本セミナーでは、AWS Secrets Manager の機能について詳細に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境におけるデータベース認証情報や API キーなどのシークレット管理に関心をお持ちの方 これから AWS Secrets Manager をご利用予定の方や、理解を深めたい方 本 BlackBelt で学習できること 本セミナーをご覧になることで、AWS Secrets Manager の機能と、どのようにセキュリティ要件を満たすように構築されているかを理解していただき、安心して AWS 上のシークレットを管理していただくことができるようになります。 スピーカー 押川令 ソリューションアーキテクト Amazon Kinesis Video Streams 基礎編 Amazon Kinesis Video Streams は、メディアデータのストリーミングや分析、保存、再生のためのサービスです。 本セミナーでは、Amazon Kinesis Video Streams 基礎編として、サービスの特徴や基本的な機能、開発のための SDK などを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 見守りカメラや監視カメラなど、コネクテッドカメラからのメディアデータのクラウド活用を検討されている方 コネクテッドカメラからの動画のストリーミングや保存、分析、再生のアプリケーションを検討されている方 Amazon Kinesis Video Streams の初めてのご利用を検討されている方 本 BlackBelt で学習できること Amazon Kinesis Video Streams の特徴や機能 アプリケーションやデバイスを開発するために利用できる SDK やライブラリ、デモアプリケーション デバイスの認証方法 Amazon Kinesis Video Streams の利用を素早く開始するための、パートナーデバイスと入門用コンテンツ 2022 〜 2023 年に公開された Amazon Kinesis Video Streams の新機能 素早く利用を開始するためのパートナーデバイスと入門用コンテンツ スピーカー 宇佐美雅紀 ソリューションアーキテクト Amazon Kinesis Video Streams 応用編 Amazon Kinesis Video Streams を活用する上で知っておくべき Tips について紹介します。パフォーマンスやコストの最適化、よくある問題とトラブルシューティング方法など、サービスをよりよく利用するためのアドバンストな内容を扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Kinesis Video Streams を利用中もしくは利用を検討しており、サービスへの理解を深めたい方 サービスの基本的な知識をお持ちでない方は、同月に公開される Amazon Kinesis Video Streams 基礎編を先にご視聴ください 本 BlackBelt で学習できること 遅延の削減方法 注意すべきサービスの仕様や上限 コストの考え方 WebRTC のトラブルシューティング GStreamer のよくある問題 スピーカー 三平悠磨 IoT スペシャリストソリューションアーキテクト Amazon EventBridge Scheduler サーバーレスのスケジューラーである Amazon EventBridge Scheduler の基本的な機能や使い方について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 クラウドに適したジョブスケジューラーをお探しの方 ノーコードで定期的なタスクの実行を管理したい方 本 BlackBelt で学習できること EventBridge Scheduler を使って定期的に AWS サービスの API を実行する方法 スピーカー 櫻谷 広人 パートナーソリューションアーキテクト FreeRTOS Kernel 編 FreeRTOS はリアルタイム OS の一つで、マイクロコントローラ上で動作する組込み機器向け OS です。 多機能な IoT デバイスを開発する上で、FreeRTOS は欠かせません。 この動画では、FreeRTOS のコアである Kernel が提供する機能について詳しく説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから IoT デバイスを開発されようとするエンジニアの方 これから FreeRTOS の利用を検討しているエンジニアの方 FreeRTOS 上でソフトウェアを開発するエンジニアの方 本 BlackBelt で学習できること AWS が提供する FreeRTOS のサポート内容 FreeRTOS のコアである Kernel が提供する機能の詳細 FreeRTOS のはじめかた スピーカー 山岡卓紀夫 ソリューションアーキテクト AWS Clean Rooms お客様とそのパートナーが、Raw データを共有したり互いにコピーしたりすることなく、集合データセットをより簡単かつ安全に分析、およびコラボレーションする為の独自のクリーンルームを作成できるサービス AWS Clean Rooms について機能の詳細や利用パターンをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データクリーンルームの技術要素をキャッチアップしたい方 機密性の高いデータのグループ間、企業間共有に課題を抱えている方 AWS を利用したデータコラボレーションを運用設計を検討されている方 AWS を利用したデータ活用に興味がある方 本 BlackBelt で学習できること AWS Clean Rooms のサービス概要や機能詳細 安全にデータをコラボレーションする為の利用方法 具体的な利用パターンや他 AWS サービスとの連携方法 スピーカー 鈴木康士郎 ソリューションアーキテクト AWS Systems Manager Maintenance Windows AWS Systems Manager は統合的な AWS 環境の運用をするためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Maintenance Windows についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方、AWS Systems Manager に興味のある方を対象者として想定しています。 本 BlackBelt で学習できること AWS Systems Manager Maintenance Windows のユースケースと機能概要、AWS Systems Manager State Manager との使い分けについて学習いただけます。 スピーカー 小野卓人 シニアソリューションアーキテクト AWS Systems Manager Distributor 編 AWS Systems Manager (SSM) は統合的な AWS 環境を運用するためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Distributor についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方 本 BlackBelt で学習できること AWS Systems Manager Distributor の機能とユースケースをご理解いただくことができます。 スピーカー 村田京介 ソリューションアーキテクト Amazon Monitron Part 1（基本編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 本 BlackBelt で学習できること Amazon Monitron セミナーはシリーズ開催予定です。このセミナーでは Amazon Monitron シリーズ Part 1 として、産業設備のメンテナンスにおける課題と Amazon Monitron によるソリューション、そして Amazon Monitron のしくみを解説します。 スピーカー 吉川晃平 シニア ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 入門編 クラウドサポートエンジニア 高橋尚久 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 クラウドサポートエンジニア 古野俊広 2023-10 Amazon EC2 Auto Scaling スケーリングポリシー編 シニアソリューションアーキテクト EC2 フレキシブルコンピュートスペシャリスト 滝口開資 2023-10 アクセラレータ搭載インスタンスの選択肢 シニアソリューションアーキテクト 赤澤智信 2023-10 AWS ML アクセラレータ入門 Annapurna Labs 常世大史 2023-10 AWS Application Discovery Service の概要（AWS 移行準備シリーズ） マイグレーションパートナーソリューションアーキテクト 鈴木槙将 2023-10 Amazon CodeCatalyst Overview 編 ソリューションアーキテクト 三尾泰士 2023-10 AWS Budgets シニアテクニカルアカウントマネージャー 岡本迅人 2023-10 AWS Cost and Usage Reports シニアテクニカルアカウントマネージャー 石王　愛 2023-10 AWS CloudFormation ユースケースとよくある質問編 ソリューションアーキテクト 木村友則 2023-10 AWS CloudFormation DeepDive 編 クラウドサポートエンジニア 山本一生 2023-10 AWS CloudFormation CloudFormation レジストリ編 クラウドサポートエンジニア 山本一生 2023-10 Amazon Monitron #2 設定編 ソリューションアーキテクト 伊藤ジャッジ向子 2023-11 Amazon Linux 最新情報 ソリューションアーキテクト 寺部祐菜 2023-11 Karpenter Basic ソリューションアーキテクト 多田慎也 2023-11 AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 クラウドサポートエンジニア 中村佑希 2023-11 AWS CloudFormation#2 基礎編 クラウドサポートエンジニア 上原優樹 2023-11 AWS CloudFormation 開発・テスト・デプロイ編 ソリューションアーキテクト 山川達也 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service (Amazon EKS) 編 クラウドサポートエンジニア 坂元龍太 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud – Windows 編 クラウドサポートエンジニア 和田智優 2023-11 Amazon CloudWatch Evidently テクニカルアカウントマネージャー 日平大樹 2023-11 AWS SAW – Nitro システムへの移行を支援する SAW ランブックのご紹介（EC2 Linux 編） クラウドサポートエンジニア 渡邉亮藏 2023-11 AWS SAW – セルフサービスなトラブルシューティング Amazon S3 + AWS Lambda 編 クラウドサポートエンジニア 石川直哉 2023-11 Amazon Pinpoint 再入門 マルチチャネル・コミュニケーションサービス ソリューションアーキテクト 清水幸典 2023-11 Amazon Connect カスタム CCP による従業員体験の向上 ソリューションアーキテクト 清水幸典

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS の生成系 AI サービス・ Amazon Bedrock  が GA (General Availability) になりました。 本ブログでは、Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用する方法について解説します。 今回は製造業で設計開発業務に取り組まれている R&D (Research and Development：研究開発) エンジニアの方を想定ユーザーとして設定させていただきました。本サービスを活用して、どのように設計開発業務改善を実現できるかについてのイメージを持っていただけるような構成になっています。 なお、本ブログの内容は2023年10月12日時点の内容に基づいて実行しています。執筆段階では東京リージョンにおいては Claude v1.3 モデルしか利用できません。 現時点で最も新しいバージョンは v2 になりますので、ここでは v2 モデルが利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、ブログ作成段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 設計開発プロセスの大きなマイルストーンの一つに、 DR （デザインレビュー：設計審査）があります。 DR では設計仕様書や設計計算書など、たくさんの設計ドキュメントを用意する必要があります。本ブログではその中から、 FMEA （ Failure Mode and Effects Analysis ：故障モード影響解析）に着目し、 Amazon Bedrock を活用して FMEA のドキュメントを効率的に作成するイメージをお見せしたいと思います。 FMEA の狙いは、製品や製造プロセスに潜在する故障モードを事前に洗い出し、影響を分析評価したうえで対策を講じることです。なるべく広く故障モードを想定できたほうが設計品質が高くなりますが、それには熟練の知識や経験が必要になります。また、洗い出す項目が多いほど、ドキュメント作成に時間を要します。このような FMEA のドラフトを、 Amazon Bedrock を活用して作成することで、 基盤モデル の特性を活かした広い観点での項目抽出を素早く行うことができるようになります。 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に Playgrounds という項目が表示されます。今回は Chat 機能にアクセスして、生成系 AI と対話形式でやり取りを行います。 Amazon Bedrock では、主要な AI スタートアップ企業や Amazon から提供される幅広い基盤モデルの中からユースケースに適したものを選択して使用することができます。詳細については Amazon Bedrock の製品ページをご参照ください。初期状態ではモデルアクセスへの権限が与えられていない状態のため、以下画像のように Base Models の中から選べるものが存在しません。そこで、まずモデルアクセスへの権限付与設定を行います。 画面左の Base Models をクリックし、 Claude v2 にカーソルを当てると、画面の黄色部分のような枠が表示されますので、 Model access ボタンをクリックします。 すると、以下画面に遷移しますので、 Claude にチェックマークをつけます。現状 Available が灰色になっていますが、このチェックを入れた状態で画面最下部でオレンジ色の Save changes ボタンをクリックすると、利用可能な状態に変わります。 以下画面のように、 Claude が Access granted の状態になれば利用可能です。 画面左の Chat ボタンを押すと、以下画面のように、 Base Models として Anthropic が選択可能な状態になっています。その右では Claude v2 を選択します。 この状態で、Add InstructionsのHuman : と記載されている箇所からチャット文章を書き込むことが可能になっていますが、書き込む文章が長い場合などに備えて、 Update inference configurations をクリックして、 Maximum Length （出力トークン数の最大値）を上げましょう。（トークン数はおおまかに文字数に相当するものと捉えてください） Maximum Length をデフォルトの300から上限の2048に上げます。 事前の設定が済めば、いよいよチャット文章を打ち込みます。以下画面の赤枠で、Human : と記載されている箇所に続いてこのような文章を打ち込みました。 「冷却ファンのFMEA（故障モードと影響解析）を作成してください。表形式で、列には、機能、故障モード、故障影響、故障原因、重要度（影響の重大度）、重要度（発生頻度）、重要度（検知難易度）、致命度（影響の重大度＊発生頻度＊検知難易度）、対策内容を入れてください。重要度はそれぞれ、1,2,3点のいずれかで表してください。多様な機能の観点で合計10個の故障原因について、対策内容は50文字程度を目安に具体的に記述してください。」 Run ボタンを押すと、紫色の箇所に Anthropic Claude v2 から回答文章が返ってきました。この状態では表形式で表示されていませんが、右上のほうにあるコピーボタンを押して、Excel などの表計算ソフトに貼り付けていただくと、表形式で表示されます。 必要に応じて罫線や色を追加するなどして見やすく編集しましょう。こちらが Anthropic Claude v2 によって数秒で作成された冷却ファンの FMEA になります。（※注意点として、生成系 AI ではランダムな要素が含まれるため、同じ質問をしても異なる回答が返ってくることがあります） このFMEAの良い点、改善が求められる点としては主に以下が挙げられます。 良い点 機能ごとに故障モード、影響、原因を網羅的に洗い出されている 致命度が指示された定義通りに算出されており、リスクの大きさが定量化されている 対策内容が適度な文字数である程度具体的に記載されている 改善が求められる点 重要度（影響、頻度、検知）の評価根拠が不明確（例えば、異音発生の重要度（影響）は本当に1点が相応しいのか、まだ動く状態だが騒音不快感を考慮すると影響はもっと大きいのではないか、など） 対策内容が要件に合うかが不明（例えば、定期的に確認する対策項目が多いが、要件に即時性が求められていた場合常時監視などの対策が必要となる、など） このように、生成系 AI を活用してドキュメントを作成する際には大事なポイントがあります。 ポイント1：質問段階で希望する出力形式を具体的に指定すると、それに沿ったドキュメント作成が行える ポイント2：項目の洗い出しや、ドキュメントのドラフト作成をまず生成系 AI に任せて、取捨選択判断や仕上げは人間が行うことで、品質向上や工数短縮が実現できる 生成系 AI は便利である一方、タスクを任せきりにしてしまうと思わぬ誤りがコンテンツに含まれてしまったりすることがあります。適材適所で生成系 AI に任せる部分、人間が責任を持って判断する部分を切り分けるようにして、設計開発業務を進化させましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングに必要なインフラストラクチャの機能および SDK (Software Development Kit) を提供するマネージドサービスです。前回の記事「 AWS SimSpace Weaver で実現する大規模空間シミュレーション: Part 1 」では、空間シミュレーションの分類や AWS での実現方法、そして AWS SimSpace Weaver が提供する機能と解決する課題について概要を紹介しました。本記事は Part 2 となり、AWS SimSpace Weaver が提供する機能と解決する課題についてのより詳細な解説を行い、AWS SimSpace Weaver を実際に導入するにあたってのステップを紹介します。 なお、本記事の内容は 2023 年 10 月時点の情報であるため、最新の情報は AWS SimSpace Weaver の Documentation を参照ください。 AWS SimSpace Weaver のコンセプト 本記事ではオンライン空間シミュレーションの具体例として、状況の可視化やインタラクティブなシナリオ操作を伴う人流・物流シミュレーションを例にして AWS SimSpace Weaver の使いどころを考えていきます。 大規模な人流シミュレーションとはどんなものでしょうか。ある施設で火事が発生し 100 人ほどが避難するシミュレーションはそれほど大規模ではないことはイメージできるかと思います。では大きなイベントホールから 50000 人が避難する場合はどうでしょうか。あるいは何らかの警報をきっかけに一都市全体で住民が一斉に避難を始めた場合のシミュレーションはどうでしょうか。他にも、数万台の車両が走行している一都市全体の交通状況を考慮した物流や緊急車両の走行シミュレーションではどうでしょうか。これらのシミュレーションの計算には大きなコンピュート処理能力が必要となります。従来のアプローチでは、CPU やメモリの能力を最大限に引き出すためにコーディング技術を駆使したり、チューニングを限界まで行ったりする必要がありました。そしてシミュレーションアプリケーションが単一プロセスや単一インスタンスの性能では処理しきれなくなったとき、スケールアップの限界を迎えます。よりスケールさせるには、スケールアウトのアプローチが必要となります。 空間シミュレーションをスケールアウト、つまり複数のインスタンスやプロセスにまたがって一つの空間シミュレーションを実行する典型的な方法は、空間分割です。シミュレーションで扱う空間を二次元 (または三次元) 座標のグリッドに分割し、各領域 (パーティション) の処理を異なるプロセスで実行するというアプローチです。 空間分割のイメージ このアプローチはシンプルですが、課題も存在します。1: 各パーティションを担当するプロセス間でシミュレーション対象の物体 (以降エンティティと呼びます) の情報を共有・同期する仕組みが必要なこと、2: 各パーティションの時刻を同期する仕組みが必要なこと、です。例えば避難経路の計算において近くの人との位置関係を考慮して次の移動方向を決めるとしたら、隣接したパーティションにいる人の位置も知る必要があります。また、各パーティションで時刻ずれが発生してしまうと、シミュレーション全体の結果が破綻してしまうので、パーティション間で足並みをそろえて処理を進める必要があります。単一インスタンス内の複数プロセスにおいてこれらの課題に対処するのも重労働ですが、異なるインスタンス上のプロセスまでスケールアウトする場合、これらの課題は更に複雑になります。AWS SimSpace Weaver はこれらの課題を解決するためのインフラストラクチャと SDK を提供します。 AWS SimSpace Weaver が提供する機能 1 点目はエンティティの情報の共有の仕組みです。AWS SimSpace Weaver は内部的に EC2 インスタンスを使用しますが、EC2 インスタンス上の複数のプロセス間や EC2 インスタンス間でエンティティ情報を共有するために、独自の共有メモリの仕組みを持っています。これは State Fabric と呼ばれ、各エンティティの座標位置に加え、ユーザーが自由に定義可能な属性情報を保持できます。また、分割された各パーティションにて他のパーティション内のエンティティ情報にアクセスするために、 Subscription の仕組みを提供しています。この仕組みにより、隣接したパーティションのエンティティ情報をもとにシミュレーションを実行したり、複数のパーティションにまたがった可視化を行ったり、シミュレーション全体にわたるメトリクスを計算したりできます。 Subscription の仕組みにより他のパーティション内のエンティティの情報を取得できる 2 点目は時刻同期の仕組みです。AWS SimSpace Weaver には、シミュレーションロジックを実行する各プロセスにおける時刻を制御する Simulation clock の仕組みがあります。Simulation clock で刻まれる時刻単位は tick と呼ばれ、その進むレート (clock rate) は 10 Hz, 15 Hz, 30 Hz, および unlimited (SimSpace Weaver app SDK 1.14.0 以降) から指定できます。Simulation clock により、複数インスタンス間でも単一の時間軸においてシミュレーションを実行できるようになります。 加えてシミュレーションの可視化が必要な場合、クライアントアプリケーションを独自で構築し、AWS SimSpace Weaver で動作しているシミュレーションアプリケーションにネットワーク経由で接続して可視化に必要な情報を得たり、ユーザー操作をシミュレーションに反映させることができます。 2023 年 10 月時点で AWS SimSpace Weaver が提供しない機能 本記事執筆時点では、AWS SimSpace Weaver が主に提供するのはシミュレーションを実行するインフラストラクチャのスケーリングを助ける機能です。AWS SimSpace Weaver はクライアントアプリケーションの作りやネットワークプロトコルには基本的に関与しないことに注意してください。SimSpace Weaver はクライアントアプリケーションが接続するためのエンドポイントを提供するため、お客様はエンドポイントに接続するアプリケーションやプロトコルを自由にデザイン・実装できます。 ただしスクラッチで実装するのが困難な場合には、SimSpace Weaver app SDK に同梱されている クライアントアプリケーションのサンプルコード、および Demo Framework が利用できます。Demo Framework にはシンプルなネットワークプロトコルのコードが含まれており、お客様の実装のスタートポイントとして活用できます。 SimSpace Weaver app SDK は本記事執筆時点で C++ および Python をサポートしています。また 3D エンジンのサポートとして Unity Plugin/Unreal Engine Plugin も提供しています。ただしこれらは可視化のためのクライアントアプリケーションで利用するものではなく、サーバーサイドアプリケーションにおけるシミュレーションロジックを各エンジンで実装する場合に利用するものであることに注意してください。 AWS SimSpace Weaver を導入するまでのステップ 最も AWS SimSpace Weaver の恩恵を受けられるお客様は、既に空間シミュレーションのワークロードを運用しており、その性能限界に課題を持っているお客様です。上述の AWS SimSpace Weaver の提供する機能を活用して既存のシミュレーションワークロードをスケールアウトし、大規模に拡張できます。もし現在利用しているサードパーティ製のシミュレーション用アプリケーションがあれば、それを AWS SimSpace Weaver 上でスケールさせることが可能かについて 是非 AWS へご相談ください 。 現在のシミュレーションがスタンドアロンアプリケーションで構築されている場合は、性能限界はそのアプリケーションを動かす端末、多くの場合はユーザーのクライアント PC のスペックの制約を受けます。よりパフォーマンスを高めたい場合、かつパフォーマンスのボトルネックがレンダリングではなくシミュレーションロジックにある場合、最終的には AWS SimSpace Weaver により大規模なシミュレーションへと進化できる可能性があります。ステップとしては、まずスタンドアロンアプリケーション内の処理をシミュレーションロジック部分と可視化部分に分離し、それらの間の情報をネットワーク経由でやり取りするように変更することで、それぞれを独立したアプリケーションとして実行できるようにします。次に、シミュレーションロジック部分のアプリケーションをサーバーサイドで、可視化部分のアプリケーションをクライアントサイドで実行する構成に変更します。結果としてクライアントサーバー構成のシミュレーション環境となります。シミュレーションロジックは独自実装でも構いませんし、3D エンジンを利用して実装する場合は Unreal Engine Dedicated Server 等の機能を利用するのが典型的な方法となります。ネットワークプロトコルについても、TCP や UDP をベースとした独自実装、または websocket や gRPC、MQTT 等の双方向通信が可能なプロトコルなど自由に利用できます。クライアントサーバー構成のシミュレーションはサーバーをスケールアップさせることで一定レベルまでパフォーマンスを高められます。スケールアップでの性能限界を超える必要が生じたら、是非 AWS SimSpace Weaver の導入をご検討ください。 既存のシミュレーションアプリケーションがなくこれから取り組む場合には、まずシミュレーションアプリケーションをクライアントサーバー構成で構築されることをおすすめします。スタンドアロンアプリケーションで可視化部分とシミュレーションロジック部分が密結合なアプリケーションを構築してからそれを分離するよりも、あらかじめ分離された構成で実装する方が容易な傾向があるためです。クライアントサーバー構成のシミュレーションアプリケーションを実装出来たら、先述の流れで最終的に AWS SimSpace Weaver の恩恵を受けることができます。 AWS SimSpace Weaver の始め方 本記事にて AWS SimSpace Weaver の特徴をつかんだら、AWS SimSpace Weaver の Product Manager によるサービス紹介動画 や、AWS re:Invent 2022 における AWS SimSpace Weaver ローンチ時のセッション を確認ください。AWS SimSpace Weaver の概念の詳細については 公式ドキュメントのユーザーガイド を参照ください。また、AWS SimSpace Weaver で動くアプリケーションを手軽に触ってみたい場合、 AWS SimSpace Weaver workshop を活用ください。 まとめ 本記事では AWS SimSpace Weaver が提供する機能とマッチするユースケース、および始め方について概念的な内容を中心に紹介しました。これまで技術的制約により一定規模で頭打ちとなっていた空間シミュレーションを大規模に拡張できるのが AWS SimSpace Weaver の最大の特徴です。開発者の皆様がインフラ構築の手間に煩わされることなく、すばらしいシミュレーションを構築されることを楽しみにしています。AWS SimSpace Weaver がマッチするユースケースを持つお客様や、今後そのようなワークロードに取り組む予定のあるお客様は、 是非 AWS へご相談ください 。 DNBソリューション本部 Game Techグループ ソリューションアーキテクト 西坂 信哉

AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングに必要なインフラストラクチャの機能および SDK (Software Development Kit) を提供するマネージドサービスです。しかしこの一文で AWS SimSpace Weaver が解決する課題やマッチするユースケースをイメージするのは簡単ではないと思います。Part 1 となる本記事ではそれらについて理解を深めるために、AWS SimSpace Weaver の概念を中心に説明します。（Part 2 は こちら ） なお、本記事の内容は 2023 年 10 月時点の情報であるため、最新の情報は AWS SimSpace Weaver の Documentation を参照ください。 空間シミュレーションとは AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングにまつわる課題を解決します。この点を理解するために、まずは空間シミュレーションとは何かを確認しましょう。 空間シミュレーションを大きく分類すると、座標系に基づいたシミュレーションとネットワークベースのシミュレーションがあります。座標系に基づいたシミュレーションでは、シミュレーション対象の要素は各々 2 次元や 3 次元の座標を持ちますが、ネットワークベースのシミュレーションでは、要素間の関係をネットワーク構造で表現し、各要素の状態と情報の伝達をシミュレートします。また別の分類として、 Agent ベースのシミュレーション と離散的なイベントベースのシミュレーションがあります。Agent ベースのシミュレーションでは様々な相互作用のもとで時刻と共に変化する物体の状態を逐次計算しますが、離散的なイベントベースのシミュレーションは、個々の物体よりも発生するイベントに注目し、各イベント発生時の状態を計算します。 この分類に基づくと、AWS SimSpace Weaver が適しているのは、座標系に基づいた Agent ベースの空間シミュレーションになります。このモデルは座標系上に存在する物体 (Agent) を扱います。各 Agent は周囲環境と外部入力に基づいて行動するアルゴリズムを持ち、Agent 同士も相互作用し、単一の連続的な時間軸に沿って変化する状態を逐次計算するモデルです。例えば、人流や物流のシミュレーションでは、歩行者や配達車両を Agent とし、他の Agent や周囲の障害物との位置関係や交通ルール等の規制を考慮し、衝突を回避したり目的地へ到達したりするように各 Agent の状態を計算します。このモデルでは、ネットワークベースや離散的イベントベースのシミュレーションと異なり、任意の時刻における全 Agent の位置を計算できるため、火事や河川氾濫等の災害時の避難やイベント開催時の人流シミュレーションにおいて、特に混雑するエリアや危険地帯の予測などに利用できます。 AWS で空間シミュレーションを実現する方法 空間シミュレーションには複数の種類があり、それぞれ AWS 上での最適な実現方法は異なります。例えば流体解析 (Computational Fluid Dynamics: CFD) によるシミュレーションや天候予測といったものは、最適な計算手法や分散処理手法が確立しているため、 ハイパフォーマンスコンピューティング (HPC) 最適化インスタンス を利用するのがコストパフォーマンスの高い方法です。一方で AWS SimSpace Weaver は、独自のアルゴリズムで行うシミュレーションや、インタラクティブにトライアンドエラーを繰り返すようなシミュレーションをスケールアウトするのに適しています。 次に、空間シミュレーションをオフラインシミュレーションとオンラインシミュレーションの二つに分類します。オフラインシミュレーションとは、シミュレーション実行中の外的な入力を許さず、初期パラメータとシナリオに沿って進むものとします。このようなシミュレーションはできる限り速く処理できることが重要です。AWS SimSpace Weaver はこのようなユースケースにも対応できますが、シミュレーションのアルゴリズムによってはやはり HPC 最適化インスタンスを利用する方がよい場合もあります。 一方、オンラインシミュレーションは、外部からの入力によるシミュレーションへの干渉を許します。外部からの入力とは、例えば災害時避難の人流シミュレーションにおいて、避難中に障害物を置いたり建物を壊したりなどの操作を行うことです。決められたシナリオではなく、インタラクティブにシミュレーションに手を入れることで複雑な仮説検証を実現できます。エンターテインメント分野においても、MMO (Massively Multiplayer Online) ゲームのようなオンラインゲームや、広い空間に多数のユーザーがアバターとして参加して交流するサービスなどは、オンラインシミュレーションの一種と言えるでしょう。AWS SimSpace Weaver はこのようなオンラインシミュレーションを大規模にスケールアウトするようなユースケースに特に適しています。 オフラインおよびオンラインシミュレーションのどちらのユースケースにおいても、AWS SimSpace Weaver がマッチするのは「単一の空間シミュレーションを（単一プロセスや単一インスタンスでは処理できないほど）大規模にスケールしたい」場合です。単一インスタンスで扱える規模の空間シミュレーションであれば、シンプルに単一インスタンスで実行するべきです。またそのような単一インスタンスで実行できる規模のシミュレーションを大量に並列実行して早く結果を得たいようなユースケースでは、AWS Batch 等の他の HPC 関連サービスが活用できます。 AWS SimSpace Weaver が解決する課題とは 空間シミュレーションを大規模に実行する際に問題となるのは、シミュレーション内で扱う物体の数が増えることで計算リソースが不足することです。シンプルな対策はシミュレーションロジックの最適化とインスタンスのスケールアップですが、それにも限界があります。更なる対策として空間シミュレーションを複数のインスタンスにスケールアウトする方法があります。例えば各インスタンスが扱う空間上の領域を分割して分散処理する方法です。この時の主な課題は、各インスタンス間での情報のやり取りの仕組みと、時刻同期の仕組みです。特にオンラインシミュレーションにおいてはリアルタイム性が重要なため、これらの課題が顕著となります。 AWS SimSpace Weaver はこれらの課題を解決するためのインフラストラクチャと機能をマネージドに提供します。お客様は AWS SimSpace Weaver により提供される Software Development Kit (SDK) を利用してシミュレーションロジックを実装することで、シミュレーションをスケールアウトできます。また AWS SimSpace Weaver はシミュレーションを実行するサーバーへネットワーク接続するためのエンドポイントを提供できるため、外部からの入力やシミュレーションの可視化を行うアプリケーションと情報のやり取りが可能です。 まとめ AWS SimSpace Weaver は、座標系に基づいた Agent ベースの空間シミュレーション、特にオンラインシミュレーションのユースケースにおいて、単一のプロセスやインスタンスでは処理しきれないほど大規模にスケールしたい場合に適したサービスです。AWS SimSpace Weaver は、スケールに伴って生じる課題である、各インスタンス間での情報のやり取りの仕組みや時刻同期の仕組みなどをマネージドに提供します。AWS SimSpace Weaver で、大規模な空間シミュレーションを実現しましょう。 Part 2 の記事 では、AWS SimSpace Weaver のコンセプトと機能の概要を紹介します。 DNBソリューション本部 Game Techグループ ソリューションアーキテクト 西坂 信哉 リソース AWS SimSpace Weaver User Guide and API Reference AWS SimSpace Weaver launch at re:Invent 2022 in AWS CEO’s keynote AWS CTO’s re:Invent 2022 keynote discussing AWS SimSpace Weaver in detail Demo – Large City Crowds Simulation Demo – Emergency Response Simulation Case Study by Duality Robotics – Building City-scale Simulations

このブログは Sudhir Amin（Sr. Solutions Architect）と Mehmet Gunes（Senior Technical Account Manager）と Nishanth Charlakola（Associate Director at S&P）によって執筆された内容を日本語化したものです。。原文は こちら を参照して下さい。 組織は複雑な SQL サーバーインフラストラクチャにおいて、データ損失を防ぐために、可用性が高く災害復旧が可能なソリューション（HADR）を構築する必要があります。クラウドの急速な普及に伴い、様々な業種の企業が、既存の環境をクラウドに移行する技術的なプロジェクトにおいての概念実証（Proof of Concept）の重要性に気づきつつあります。どのような規模の企業にとっても、導入を成功させるためには、スピードを維持しながら、基準を設定し、リスクを最小限に抑え、多角的に検証を行うことが重要です。 S&P Global Market Intelligence は世界の金融市場およびそれらの市場を構成する企業や業界に関する実用的なインテリジェンスを提供するリーディング・プロバイダーであり、160 年以上の歴史があります。主に ESG ソリューション、ディープデータ、重要な経済・市場・ビジネス要因に関する洞察を提供し、ビジネスの進歩を加速させます。このブログでは、S&P Global Market Intelligence が、マルチリージョン Amazon FSx for NetApp ONTAP （FSx for ONTAP）アーキテクチャを実装し概念実証を成功させることで、Microsoft SQL Server ワークロードの事業継続性と災害復旧（DR）の目標を達成するための技術評価を行った方法について説明します。 ビジネスにおける問題点と現状のアーキテクチャ S&P Global のマーケット・インテリジェンス部門のデータサービスエンジニアリングチームは、大規模な Microsoft SQL Server を管理しており、その上で稼働するバックエンド処理を AWS で運用・保護するための、コスト最適化されたクラウドネイティブソリューションを必要としていました。このデータ処理インスタンスには 100 以上の SQL Server データベースがあり、総ストレージ容量は 100 TB を超え、年間約 10 % 増加しています。バックエンド処理システムは、すべてのデータの取り込みと、さまざまな外部クライアント向け製品へのデータ配信を行うためのソースデータベースサーバーとして機能しています。データの取り込みは、コンテンツ取り込み UI ツールを使用したプロセスで自動化されており、これらのコンテンツで作業するユーザーは世界中に散らばっています。データ配信の観点からは、このシステムは SQL Server のパブリッシャーとして機能し、何千ものテーブルを持つ数百のデータベースを公開しています。 インフラストラクチャのレベルでは、プライマリ環境と DR 環境の両方に SQL データベースをホストするための 2 ノードの Windows フェールオーバークラスター（WSFC）があり、共有ストレージサービスを提供する高速な SAN ストレージシステムに接続されています。次の図に示すように、各データセンターの 2 つのストレージシステム間で構成された SAN レプリケーションは、フェールオーバークラスタリングソリューションに地理的冗長性を提供します。 図 1: オンプレミス上の SQL Server HADR アーキテクチャの論理コンポーネント プライマリサイトでフェールオーバーが発生した場合、WSFC サービスはプライマリインスタンスのリソースの所有権をサイト内の指定されたフェールオーバーノードに移動します。 プライマリデータセンターに壊滅的な災害が発生した場合、クライアントアプリケーションのトラフィックは DR サイトに誘導され、レプリケーションされたデータベースインスタンスにアクセスします。DR サイトのストレージシステムは 2 つの Windows フェールオーバークラスターノードに接続され、レプリケーションされたストレージボリューム上のデータベースへのアクセスを提供し、2 つのデータセンター間の 4 つのノードすべてで可用性を実現します。データベース管理者（DBAs）が手動でフェールオーバーを行い、2 つのストレージボリューム間のミラー関係を解除することで、DR サイトのデータベースをオンラインにすることができます。 加えて、多数の社内外アプリケーションにデータサービスを提供するために、SQL Server インスタンス上に数百のパブリケーションデータベースと数千のアーティクルを持つ MS トランザクションレプリケーションが構成されています。クライアントアプリケーションは、 Windows フェールオーバークラスター内の SQL Server ネットワーク名を使用してデータベースサービスにアクセスします。したがって、RPO 10 分、RTO 1 時間という目標でシームレスなフェールオーバーを実現するには、構成された 2 つのサイト間におけるドメインの名前解決とネットワーク構成が非常に重要でした。 技術的要件 以下の必要条件が定義されていました： 多数のデータベースが存在する環境をサポートするために、ストレージベースのレプリケーション機能を備えた共有ストレージソリューションを活用して、マルチリージョン SQL Server フェールオーバークラスターインスタンスを実装します。 RPO 10 分、RTO 1 時間を達成するために、両方のサイトに配置されたストレージソリューションは、継続的、非同期、そして双方向のレプリケーションをサポートする必要があります。 ストレージソリューションは 100 TB を超えるストレージ容量をサポートし、SQL Server クラスター用に高い IOPS とスループットを実現できる必要があります。 SQL Server をサポートする 非対称共有ストレージ を使用し、異なる AWS リージョン にまたがった単一で可用性の高い Windows フェールオーバークラスターインスタンスを実装します。 Active Directory（AD）と信頼性の高い DNS サービスを備えた耐障害性の高い Windows インフラストラクチャを実装し、クライアントアプリケーションのシームレスなフェールオーバーをサポートしています。 ソリューション概要 マルチリージョンアーキテクチャで SQL Server AlwaysOn FCI を導入するには、共有ストレージオプションと、リージョン間のデータレプリケーション機能が不可欠でした。そこで、クロスリージョン DR にて利用可能な SnapMirror レプリケーションを備えた、高い可用性と耐久性を誇るストレージ、FSx for ONTAP を使用することで、厳しい RPO と RTO の要件を満たします。FSx for ONTAP はフルマネージドサービスであり、自社管理ストレージと比較して、高い信頼性とパフォーマンス、かつセキュアな共有ファイルストレージを、クラウドにてコスト効率良く簡単に導入・拡張することができます。 図 2: マルチリージョン FSx for ONTAP と SnapMirror レプリケーションによる DR ソリューション導入の手順 チームはこの概念実証のために、バージニア北部リージョン（us-east-1）とオハイオリージョン（us-east-2）にまたがる、Windows フェールオーバークラスターを構築しました。手順は以下の通りです。 リージョン間の VPC ピアリング を設定する 2 つのアベイラビリティ・ゾーン（AZ）にまたがった、2 つのプライベートサブネットを含む VPC をプライマリサイトとなる us-east-1 にデプロイします。 DR 用 SQL Server ノードをホストするための、単一の AZ で 1 つのプライベートサブネットを含む VPC を DR サイトとなる us-east-2 にデプロイします。 リージョン間で AD サービス をサポートするための ネットワーク通信 を有効にする 両方のリージョンで Windows フェールオーバークラスターと SQL デプロイメントをサポートするためのネットワークアクセスを持つ AD をデプロイします。 SQL Server の通信用に、ノード間およびクライアントアクセスを許可したセキュリティグループを設定します。 各リージョンに SQL Server を配置する プライマリサイトと DR サイトの両方に、SQL Server インスタンスをデプロイします。最初のテストでは 2 つのサイトで独立した SQL Server を使用しましたが、その後プライマリサイトの 2 ノード SQL FCI クラスタへ移行し、DR サイトの 1 ノードを同クラスタに参加させました。 Windows フェールオーバークラスターを作成するための適切な権限を持つ SQL Server サービスアカウントの資格情報と、SQL Server フェールオーバークラスターインスタンスを作成します。 3 つの SQL Server はすべて共通の AD ドメインに参加し、SQL Server 用の共通サービスアカウントを使用します。 クラスターのクォーラムは、DR サイトが投票に参加せず、プライマリサイトの投票数が奇数になるように構成します。 このアーキテクチャでは、プライマリサイトに 2 つのノードがあるため、ファイル共有監視を構成し、クォーラムのモードを「Node and File Share Majority」とする必要があります。詳細については、 クォーラム構成 と ディザスタリカバリ構成におけるクォーラムの考慮事項 を参照してください。 各リージョンに FSx for ONTAP ファイルシステムを実装する プライマリサイト（us-east-1）に、要件に従って適切な SSD 容量を持つ FSx for ONTAP ファイルシステムを作成します。 DR サイト（us-east-2）に、プライマリサイトで作成された SSD 容量と同量以上の、セカンダリ FSx for ONTAP ファイルシステムを単一 AZ に作成します。 プライマリサイトの 2 つのノードは、プライマリ FSx for ONTAP ファイルシステムからデータを取得し、ストレージはプライマリサイトのノードにのみ表示され、DR サイトのノードには表示されません。これは非対称ストレージ構成と呼ばれます。 同様に、DR サイトのノードは、セカンダリ FSx for ONTAP ファイルシステムからデータを取得し、ストレージは DR サイトのノードからのみアクセスできます。 DR サイトのストレージは Windows ノードにはマッピングされません。通常 DR サイトのストレージは読み取り専用状態で、フェールオーバー時に読み書き可能に変更されます。 2 つの FSx for ONTAP 間で SnapMirror の非同期レプリケーションが確立され、DR サイトにフェールオーバーが発生すると、レプリケーション関係において送信元と送信先の関係がセカンダリとプライマリで逆になります。 注：データ損失を完全に防ぐには、同期型のレプリケーションでのみ実現可能なことが重要です。同期レプリケーションを実装するには、ラウンドトリップタイム（RTT）が 10 ms 以下（物理距離約 150 km 以内）である必要があります。災害対策の用途では、物理距離の制限がなく、データ損失を最小限に抑えて DR サイトにレプリケートする必要があるため、非同期レプリケーションが有効です。 SnapMirror の同期型と非同期型の詳細については、ネットアップのブログ記事を参照してください。 How to Devise an Effective Data Protection and Disaster Recovery Approach. 技術的検証 データの一貫性と可用性を確認するため、チームは SnapMirror 関係を解除した後にデータベースをオンラインにし、セカンダリファイルシステムをクリーンアップできることを検証しました。また、巨大なトランザクションの途中で SQL Server インスタンスをフェールオーバーし、セカンダリファイルシステム上で処理中のトランザクションが正常にロールバックされることも検証しました。テストフェーズで実施された各 DR 訓練では、MS トランザクションのレプリケーションステータスとアプリケーションの接続性が監視され、エンドユーザーがデータにアクセスできることを確認しました。実装とデータ検証の手順は、 Amazon FSx for NetApp ONTAP を使用した SQL Server Always On Failover Cluster インスタンスの HA と DR の実装 という投稿で説明されています。これは、マルチリージョン FSx for ONTAP ファイルシステムアーキテクチャを SnapMirror を用いて実現し、SQL Server の HA および DR アーキテクチャを設計する際に役立ちます。 結果 社内のコンテンツとデータ処理アプリケーションは、社外顧客向け製品にデータを配信するための基礎になります。S&P Global Market Intelligence は、FSx for ONTAP の SnapMirror を使用して、SQL Server フェールオーバークラスターインスタンスを 2 つのリージョン間で実装し、HADR 構成を実現しました。SnapMirror レプリケーションによって、HADR の目標である RPO 10 分、RTO 1 時間という厳しい目標を簡単に達成できました。これにより、アプリケーションの信頼性と耐障害性が向上しました。また、ネイティブのネットワーク圧縮機能によって帯域幅の使用率も低下し、FSx for ONTAP システム間のデータ転送が高速化されました。 まとめ このブログでは、S&P Global がビジネスクリティカルなコンテンツとデータを処理するアプリケーションのために、FSx for ONTAP を使用して、シームレスなクロスリージョン HADR 構成を AWS に導入・検証するためのソリューションを紹介しました。FSx for ONTAP を使用することで、ストレージ部門における運用保守の管理工数を削減し、データの一貫性や信頼性のテストと検証などユーザー目線での改善業務に集中することができます。その他にも、FlexClone などの機能を活用して開発環境やレポーティングおよび分析用の ETL 環境を構築、 SnapCenter プラグインを実装して容量効率の高いデータベースのバックアップとリストアの実行、スナップショットやアクセス頻度の低いストレージブロックをキャパシティプール階層に可能な限り移動しコスト削減を実施、といったことも可能です。 この記事をお読みいただきありがとうございました！ 翻訳はネットアップ合同会社の岩井様、監修は Solutions Architect 吉澤が担当しました。 Sudhir Amin Sudhir Amin は、Amazon Web Services の Sr. Solutions Architect です。ニューヨークを拠点に、さまざまな業種の企業にアーキテクチャのガイダンスと技術支援を提供し、クラウド導入を加速しています。彼はボクシングや UFC といった格闘技の大ファンであり、野生動物保護区のある国を旅行して、世界で最も雄大な動物を間近に見るのが大好きです。 Mehmet Gunes Mehmet Gunes は Amazon Web Services の Senior Technical Account Manager です。TAM として、クラウドコンピューティングの導入とビジネスの変革を成功させるためのパートナーとして顧客をサポートしています。ツール、技術的な専門知識、技術に特化したスペシャリストを駆使して、顧客のビジネスや運用の成果、技術的な課題を理解し、AWS から最大の価値を得られるよう支援しています。彼は余暇に旅行し世界中の新しい場所を探索することを愛しています。 Nishanth Charlakola Nishanth Charlakola は、S&P Global Market Intelligence データサービスエンジニアリングチームの Associate Director です。大規模な SQL Server システムの設計、管理、保守において 14 年以上の業界経験を有し、5 年以上のクラウド経験があります。S&P Global Market Intelligence では、主に SQL Server ワークロードのクラウドへの移行を担当しています。彼はインドのハイデラバード在住で、余暇はイングランドプレミアリーグの Chelsea FC を応援しています。

〜 第２回 デュアル・システム 〜 このブログでは、クラウドの価値を最⼤限に活⽤するための組織のビジネスアジリティの高め方についてご紹介します。第２回では、ジョン・Ｐ・コッターの「デュアル・システム」の紹介と、AWSが「デュアル・システム」の仕組みをどのように実現しているのかについて解説します。 「デュアル・システム」とは 「デュアル・システム」とは、ハーバードビジネススクールのジョン・Ｐ・コッター教授が著書「ジョン・Ｐ・コッター　実行する組織」で提唱している大企業がビジネスアジリティを高めるための組織のあり方のことです。詳細はぜひ書籍を読んで頂きたいと思いますが、ここでは簡単に紹介します。デュアルという名のとおり、「デュアル・システム」とは企業の中に2つの組織体が存在し機能している状態を意味しています。ひとつは、企業が発展していく段階でマネージメントの効率化を求めた結果構成される組織形態で、どの企業にも存在する階層型組織です。皆さんもよくご存知のとおり、階層のトップには社長がいて、配下には複数の事業部やバックオフィス系部署が配置され、それぞれの部署には責任者がいて、その配下に従業員が所属しています。各階層組織の責任者は人事上のマネージャーでもあり、その階層の組織を運営しています。もうひとつは、ネットワーク型組織と呼ばれるもので、階層型組織のさまざまな階層や部署から結集した意欲的な人たちによる組織です。この組織には、人事上のマネージャーは存在せず上下関係もありません。階層型組織には全ての社員が所属しますが、ネットワーク型組織への所属は任意です。そして最も重要な点は、このネットワーク型組織は有志社員による非公式な団体ではなく、階層型組織から認知された公式な組織であるということです。この２つの組織体のイメージと特徴は、以下の図のとおりです。 出典：「ジョン・Ｐ・コッター　実行する組織」 p.34, p.49 AWSにおけるデュアル・システム 当然ですが、AWSにも階層型組織が存在しています。他の企業と同様、その階層は非常に深く、組織はサイロ化されているため、普通に働いているだけでは別の組織や階層に所属している社員と一緒に働く機会は多くありません。一方、AWSにはネットワーク型組織も存在しています。AWSのネットワーク型組織は、いくつかありますが、その中でも最も巨大かつ成果を上げているのが、SA(Solutions Architect)を中心に組織されているTFCと呼ばれる組織体です。TFCとは、Technical Field Communitiesと呼ばれるもので、階層型組織の様々な部署やチームの社員がこのネットワーク型組織に参加しています。したがって、ネットワーク型組織に参加するということは、他部署の人間や他チームのメンバーと一緒に働くことを意味します。コミュニティーというと、有志社員による業務時間外に活動する組織のように想像される方もいるかも知れませんが、AWSにおけるTFCは階層型組織から公式に認知されたネットワーク型組織なので、その活動は業務の一環として業務時間内に行われており、活動内容は社外のパブリック・スピーキングや社外向けのテクニカルコンテンツの作成、社内へのトレーニング提供など多岐にわたります。活動量の割合は個人差がありますが、階層型組織での業務が７割から８割、ネットワーク型組織での業務が２割から３割です。階層型組織は社員のTFCへの参加を推奨していますが、TFCへの参加は義務ではない為、全ての社員が参加している訳ではありません。参加するかどうかは、社員の自主性に任されています。TFCの運営自体も、管理職やマネージャーが行なっているわけではなく、参加している社員が自律的に必要な役割を担って運営しています。ここでは、ネットワーク型組織のひとつの例としてTFCを紹介しましたが、AWSには他にも様々なネットワーク型組織が存在しています。それら全てに共通している点は、社員による自律的な活動でありつつも、その活動は階層型組織から公式に認知された業務の一環となっていることです。 組織のライフサイクル ここで、書籍「ジョン・Ｐ・コッター　実行する組織」の中からもうひとつ、「多くの企業がたどる、組織のライフサイクル」について紹介します。 出典：「ジョン・Ｐ・コッター　実行する組織」 p.82 この図は、企業の成長とともに組織が変化して遷移してゆく状況を表現しています。図の上段左側は、創業期の企業がネットワーク型組織から始まっていることを表しています。企業の成長とともにネットワーク型組織は大きくなってゆき、ある段階で信頼性と効率性を求めて、図の中段左側の状態のように階層型組織が生まれます。その後、階層型組織がどんどん大きくなる一方で、ネットワーク型組織は少しずつ小さくなり、最後は図の下段右側のように階層型組織だけになります。この図とともに、「ジョン・Ｐ・コッター　実行する組織」p.81-83には、以下のように記述されています。 “こうした道のりの果てに階層組織が体系化され整備されるが、その間も企業は成長を続け、シェアを拡大し、規模の経済を確立し、強力なブランドを打ち立て、顧客と良好な関係を築く。だが、成長と繁栄の影で、大切なものが失われていることが多い。巧みに生き延び高収益を挙げていても、イノベーションを次々に生み出していたかつてのスピードやキレはもうない。ゆえに成長は勢いを失い、徐々に減速していく。機を見るに敏な新参企業が、顧客やシェアを奪い取るのはこんなときだ。その結果として価格競争が起き、利益率を押し下げるかも知れない。” 「デュアル・システム」の再構築 大企業や老舗企業が俊敏性とスピードを取り戻すには、かつて経験したであろう、図表4-4の中段右側の状態、すなわち階層型組織とネットワーク型組織が共存している状態を再び作りだす必要があります。しかし、消滅して忘れ去られたネットワーク型組織を復活させるには、どこからどのように開始したら良いのでしょうか？ AWSにおけるネットワーク型組織の例としてTFCという組織体を紹介しましたが、TFC(Technical Field Communities)はその名のとおりテクノロジーをテーマに活動している組織です。テクノロジーをテーマにした組織がネットワーク型組織として活躍しているのは、AWS がテクノロジーの会社であるからに他なりません。AWSがテクノロジーの会社であるが故にテクノロジーをテーマにしたネットワーク型組織が階層型組織から公式な業務の一環として認知されているのです。つまり、ネットワーク型組織が業務の一環として、階層型組織から公式に認知される為には、どのような企業であれ、ネットワーク型組織は企業のビジネスと密接に関連している必要があるということです。そこで、ネットワーク型組織を復活させる際には、階層型組織のビジネス課題に取り組む小さな組織として始めることをお勧めします。その際の注意点として、ネットワーク型組織に参加する社員は自主的かつ自律的に活動する必要がある為、やる気のある社員を社内から募集するようにします。まずは、図表4-4の下段左側の状態を作り出し、そこから徐々に中段目右側の状態に持っていくことになります。その際、「ジョン・Ｐ・コッター 実行する組織」p.41に示されいる以下の「八つのアクセラレータ」を参考に進めると良いでしょう。 出典：「ジョン・Ｐ・コッター 実行する組織」 p.41 まとめ 今回は、ジョン・Ｐ・コッターの「デュアル・システム」の紹介と、AWSが「デュアル・システム」の仕組みをどのように実現しているのかについて解説しました。また、ネットワーク型組織が消滅して階層型組織だけになっている企業において、ネットワーク型組織を再構築し、「デュアル・システム」として機能させる為の指針も示しました。第１回でお伝えしたとおり、「デュアル・システム」は、アジャイルの要素「人々」に相当する部分です。アジャイルの要素「人々」は、他の要素「プロセス」や「ツール」よりも変革に時間がかかります。時間がかかるからこそ先送りせず早い段階から着手する必要があります。そして、アクセラレータの⑥「早めに成果を上げて祝う」を実施することをお勧めします。AWSで提供している Experience-Based Acceleration (EBA) というプログラムにおいても、「チームで成果を称賛する」ことを推奨しています。称賛することがチームの「内発的動機づけ」に繋がるからです。是非お試しください。 〜 第１回 アジャイルの動向 2023年 〜 【参考文献】 ジョン・Ｐ・コッタ― (著), 村井 章子 (翻訳)「 ジョン・Ｐ・コッタ― 実行する組織―――大組織がベンチャーのスピードで動く 」ダイヤモンド社 (2015/7/2) ジョン・P・コッター (著), バネッサ・アクタル (著), ガウラブ・グプタ (著), 池村千秋 (翻訳)「 CHANGE 組織はなぜ変われないのか 」 ダイヤモンド社 (2022/9/20) 河野洋一郎 カスタマーソリューションズマネージャーとして2020年にAWSに入社して以来、「クラウドジャーニーとアジャイルジャーニーを同時進行してビジネスアジリティを最大化せよ！」をモットーとして、クラウド時代におけるお客様のビジネス価値実現のお手伝いをしています。AWS以前は、CA TechnologiesにてDirector of ITとしてIT組織のアジャイル化を推進していました。