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組織のアジャイル化を推進していました。

前回の記事 では、AWS クラウド移行後のアーキテクチャとして、店舗に留まらない、多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマースの取り組みと、段階的に組み立てていくコンポーザブルアプローチについて紹介しました。 今回の記事は、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末（エッジ）と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介します。 エッジの運用と AWS の連携をシンプルにする AWS IoT 店舗で利用する機器については以下を実現することが求められています。 状態監視やリモート管理により故障やその兆候を確認した際に迅速な対応を取る セキュリティ管理、ソフトウェアのアップデートにより安全な状態を保つ 機器とクラウドの間でデータを連携する 国内に多店舗展開している小売業では、多くの POS や各種端末を有しているので、実現にあたってのスケーラビリティは必要不可欠です。 AWS IoT は、何十億ものデバイスを接続、管理する IoT（モノのインターネット）サービスとソリューションを提供しているので、シンプルに実現することができます。 ディザスタリカバリ（DR）を実現するマルチリージョンアーキテクチャ 前々回の記事 でも取り上げましたが、災害対策におけるシステムの冗長化構成については、想定する災害と、システムの影響範囲について構成が決定されます。 AWS グローバルインフラストラクチャ は、あらゆるアプリケーションに対応し、最も安全で、拡張性の高いインフラストラクチャを提供しているので、要件に応じたシステム構成を実現できます。災害対策に限らない、システムに関する障害対策として、マルチアベイラビリティゾーン（マルチ AZ）構成から検討するのは良い出発点です。 想定する災害（例） 影響範囲 冗長化構成 落雷による停電 アベイラビリティーゾーン（AZ） マルチ AZ 構成 関東一帯が影響を受ける災害 リージョン マルチリージョン構成（東京 – 大阪など） 日本国内の大部分が影響を受ける災害 リージョン マルチリージョン構成（東京 – シンガポールなど） 表1：想定する災害と冗長化構成の例 国内でチェーン展開している小売業においては、災害発生時、災害の影響を受けている地域については店舗の営業は困難となりますが、それ以外の地域では営業を継続することが期待されます。例えば、今や生活に欠かすことのできないコンビニエンスストアや薬を扱うドラッグストアでは、災害発生時においても、生活インフラとして営業を継続することが期待されます。 図 1：大規模災害発生時における DR サイトへのフェイルオーバー この場合、システムについては、DR サイトを用意して災害発生時にフェイルオーバーすることによってシステムを稼働することが期待されますが、AWS グローバルインフラストラクチャにおいては、マルチリージョンアーキテクチャにより実現できます。 アーキテクチャの紹介 POS を例にしたアーキテクチャを図 2 に示します。AWS IoT Device SDK で構築された POS が AWS IoT Core と接続することで、機器の管理に加えて、データの利用用途に応じたクラウドサービスとの連携と、MQTT ベースでの双方向通信を実現します。AWS IoT Core は、業務アプリケーションとデバイス管理の用途に応じて、メッセージを振り分けてデータを管理します。 災害発生時のオペレーションをできる限りシンプルにするために、セカンダリリージョンの AWS IoT Core にも事前に機器登録をします。事前登録の例としては、AWS IoT のモノの登録や、プライマリとセカンダリで共通の証明書を発行してデバイスへの組み込み、があります。 プライマリリージョンの利用不能時は、 Amazon Route 53 により接続先をセカンダリリージョンに切り替えることで、デバイス側の設定を変更することなく切り替えができます。データについて、 Amazon DynamoDB グローバルテーブルにより、プライマリリージョンの更新がセカンダリリージョンに自動的にレプリケートされます。 図 2：アーキテクチャ ユースケース POS で想定される業務アプリケーションの以下ユースケースを例に、アーキテクチャを解説します。 POSのトランザクションを連携する モバイルオーダーからの注文により在庫がないことを通知する POSのトランザクションを連携する 顧客の会計時に取得した POS データは、各店舗で連続的に発生します。また、リアルタイムな購買動向の把握や在庫管理のためストリーミングデータとして扱うことが期待されます。 図 3：POS トランザクションの連携 処理の流れについては以下の通りです。 POS データは、POS から AWS IoT Core に暗号化された MQTT プロトコルを使用して AWS IoT Core に送信されます。 AWS IoT Core は AWS IoT ルールアクションにより、 Amazon Kinesis Data Streams に MQTT メッセージのデータを書き込みます。 AWS Lambda 関数は、Amazon Kinesis Data Stream のレコードを処理し、Amazon DynamoDB で管理する在庫情報を更新します。 モバイルオーダーからの注文により在庫がないことを通知する モバイルオーダーから店舗の商品が注文されるようになると、一見在庫があるように見えても既にモバイルオーダーで購入されている可能性が生じます。モバイルオーダーの在庫を別で管理するといったオペレーションも選択肢ですが、シンプルに一緒に管理するニーズもあります。このようなケースでは、最新の在庫情報はシステムで管理されているため、在庫がなくなったことを、システムから店舗に通知する必要があります。顧客体験として改善の余地はありますが、先に注文票を持っていくケースや先に注文する飲食のケースの場合、会計時に POS に通知されている情報を元に購入できないことを伝えることで、在庫以上に購入されることを防げます。 図 4：POS へのメッセージ送信 処理の流れについては以下の通りです。 在庫情報の変更情報は、DynamoDB Streams によりキャプチャされます。 AWS Lambda 関数は、ストリームレコードを処理します。在庫がなくなった（あるいはある閾値に達した）ことを検知すると、MQTT クライアントインスタンスを作成して、AWS IoT Core にリクエストを転送します。 AWS IoT Core は、POS に MQTT リクエストを転送します。 POS アプリケーションで、転送されたリクエストを処理します。 DR サイトへの切り替え 災害発生時における DR サイト切り替えの流れを説明する前に、通常の状態について補足します。 通常の状態 プライマリリージョンとスタンバイリージョンの切り替えを、デバイス側の設定を変更することなく実施するため、AWS IoT Core はカスタムドメインを作成します（図 5 における iot.example.com）。Amazon Route 53 は、プライマリとスタンバイリージョンの AWS IoT Core エンドポイントに対して、フェイルオーバールーティングを設定します。 その他、Amazon Kinesis Data Stream や AWS Lambda 関数、DynamoDB Streams もデプロイしておきます。 図 5：通常状態（図 2 と同じ） 災害発生時 災害発生時における DR サイトへの切り替えは、業務も含めた被害状況に基づく意思決定により行われます。DR サイト切り替えの意思決定が下されると、オペレーターは、 Amazon Route 53 Application Recovery Controller のルーティングコントロールを変更して POS からの接続先を DR サイトに切り替えます。 図 6：災害発生時における DR サイト切り替え 災害からの復旧（切り戻し） 基本的には、災害発生時のオペレーションと同じく、POS からの接続先の切り替えます。一例として、以下のような手順も考えられます。 Amazon Route 53 Application Recovery Controller のルーティングコントールを変更して POS からの接続先を DR サイトからプライマリサイトに切り替える AWS IoT Core から順次特定の POS にメッセージを送り再接続を指示する 該当の POS は再接続をしてプライマリーに戻る 閉域接続の場合 一貫性のある応答性能を実現するために、店舗とクラウドのネットワーク接続を広域通信網（WAN）と AWS Direct Connect を組み合わせている場合もあります。本記事で紹介しているアーキテクチャは、そのようなネットワーク構成においても実現できます。 図 7：閉域接続の場合におけるネットワーク構成 災害発生時における AWS Direct Connect の障害影響を考慮して、 AWS Direct ロケーション を複数用意します。本記事では詳しく取り上げませんが、AWS Direct Connect の高い回復性を実現するアーキテクチャについては、 AWS Direct Connect の回復性に関する推奨事項 で詳しく解説しています。 まとめ 本記事では、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介しました。AWS IoT により、多店舗展開する小売業で期待されるデバイス管理のスケーラビリティの実現と、AWS で稼働する店舗システムとシンプルに連携することができます。 実際のユースケースは、取り上げた 2 つのユースケース以外にもありますが、今回紹介したアーキテクチャをベースにアーキテクチャを検討することができます。例えば、POS データを分析したい場合は、 Amazon S3 に POS データを蓄積することが期待されますが、Amazon Kinesis Data Streams のストリームデータを Amazon Kinesis Data Firehose でキャプチャして、Amazon S3 に配信できます。また、POS がローカルに管理する商品マスタの配信については、AWS IoT Core から POS にデータ連携することにより実現できます。この他、災害対策に対する戦略として、DR サイトを用意する必要がなければ、プライマリリージョンを対象として紹介したアーキテクチャを活用していただけます。 本記事が、皆さまの店舗システムの将来アーキテクチャの検討に役立てられれば幸いです。 関連情報 店舗システムのクラウドに関する考察 店舗システムのクラウド化に向けた考察2 – クラウド移行後アーキテクチャと進め方   ソリューションアーキテクト　平井 健治  

AWS Gateway Load Balancer (GWLB) は、2020 年 11 月より一般提供を開始しました。これは、ファイアウォール、侵入検知および防止システム、分析、可視性などのサードパーティの仮想ネットワークアプライアンスのデプロイ、スケーリング、管理を支援する新しいサービスです。Elastic Load Balancer ファミリーに新たに加わった AWS Gateway Load Balancer (GWLB) は、透過的なネットワークゲートウェイ (つまり、すべてのトラフィックの単一の入口と出口点) と、トラフィックを分散し、需要に応じて仮想アプライアンスをスケーリングするロードバランサーを組み合わせたものです。 これは大きなマイルストーンでした。なぜなら、AWS Gateway Load Balancer は、ネットワーク、セキュリティ、分析、通信、モノのインターネット（IoT）などのカスタムロジックやサードパーティ機能をあらゆるネットワークパスに差し込むための新しいフロンティアを切り開いたからです。この機能は、スケール、可用性、サービス提供、フローのスティッキーなどの問題を軽減するとともに、パートナーが中核となる専門知識に集中し、より迅速にイノベーションを起こせるようにします。 この記事では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法について詳しく説明します。「アプライアンス」という言葉は、新しいカスタムロジック、または既存の仮想アプライアンスを意味します。基礎に興味がある場合は、 GWLB ページ または別のブログ投稿「 GWLB がサポートするアーキテクチャパターン 」を見てみるとい良いかもしれません。GWLB で公開したすべてのブログをご覧になりたい場合は、 こちらのページ をご確認ください。それでは、早速見ていきましょう。 どのような種類のネットワークアプライアンスが GWLB で動作しますか？ GWLB は各パケットをレイヤー 3 で処理し、アプライアンスの状態に依存しません。この動作により、アプライアンスが Geneve のカプセル化/カプセル化解除と GWLB メタデータをサポートしている限り、任意のカスタムロジック、またはサードパーティアプライアンスを GWLB の背後にあるフリートにデプロイできます。これについては後で詳しく説明します。 GWLB はどのように機能しますか? 下の図に示すように、GWLB は別の VPC のゲートウェイロードバランサーエンドポイント（GWLBE）に接続されています。GWLBE は VPC エンドポイント (VPCE) の一種です。1 つの GWLB を複数の GWLBE に接続できます。 GWLB には 2 つの側面があります。GWBLE に接続する側は、GWLB フロントエンドと呼ばれます。ターゲットアプライアンスに接続されている側は、GWLB バックエンドと呼ばれます。バックエンドでは、GWLB は、複数の同等のターゲットアプライアンスのうちの1つを介してトラフィックフローをルーティングするためのロードバランサーとして機能します。GWLB は、ターゲットアプライアンスへの両方向のフローのスティッキーを確保し、選択したアプライアンスに異常が発生した場合にフローを再ルーティングします。この記事は、バックエンド機能、特にGLWB とアプライアンス間の通信に焦点を当てています。 送信元から宛先に送信されるパケットには、宛先 IP アドレスとして GWLB IP が含まれていませんが、ルートテーブルの設定により GWLB にルーティングされます。透過的な転送動作を実現するため（つまり、元のパケットの内容をそのまま保持するため）、GWLB は Geneve カプセル化を使用して元のパケットをカプセル化し、アプライアンスに（/from）パケットを送信（/receives）します。また、アプライアンスは元のパケットを処理するために Geneve Type-Length-Value（TLV）ペアをカプセル化解除する必要があります。 ※訳者注記：TLVはフォーマット表現の一種です。 GWLB はパケットイン/パケットアウトサービスです。アプリケーションの状態は保持されず、TLS/SSL復号化/暗号化も実行されません。これらの機能はアプライアンス自体によって実行されます。 GWLB で動作させるには、アプライアンスにどのような変更を加える必要がありますか？ GWLB と連携するためには、アプライアンスは以下の条件を満たす必要があります。 GWLB とトラフィックを交換するための Geneve プロトコルをサポートしている。Geneve のカプセル化は、GWLB とアプライアンス間のパケットの透過的なルーティングや、追加情報（後述のメタデータ）の送信に必要です。 GWLB 関連の Geneve Type-Length-Value (TLV) ペアのエンコード/デコードをサポートしている。 GWLB からの TCP/HTTP/HTTPS ヘルスチェックに応答する。 プロトタイプのアプライアンスの場合、ユーザーが上記のタスクを1日で完了するのに対し、高度なアプライアンスはさまざまな要因に応じて数日/数週間かかるのを見てきました。上記のタスクを完了すると、アプライアンスとGWLB の相互運用性をテストできます。テストとトラブルシューティングの概要は、この記事の後半で説明します。 アプライアンスが Geneve カプセル化をサポートする必要があるのはなぜですか？ 元のパケットをそのまま保持する必要があることは、GWLB が提供する重要な機能である透過的な動作の基本的な要件です。元のパケットを新しいL3パケットにカプセル化することが、GWLB とアプライアンス間でパケットをルーティングするための唯一の実行可能なソリューションです。これは、このようなパケットの送信元/宛先 IP は GWLB またはアプライアンスの IP と同じではないため、これらの IP に基づく通常の VPC ルーティングでは、パケットが GWLB またはアプライアンスをバイパスしてしまうためです。 さらに、CIDR が重複するマルチテナントアプライアンスをサポートするには、アプライアンスがトラフィックのソースを知る必要があります。また、GWLB はフローを追跡し、ユーザートラフィックが混在しないようにする必要があります。GWLB は、パケットごとにType-Length-Value（TLV）トリプレットを使用して追加情報（GWLBE/VPCE ID、フロークッキー、添付ファイルIDなど）をアプライアンスに送信することでこれを実現できます。 Geneve プロトコル ( RFC 8926 ) は柔軟性があり、この追加情報を渡すことができます。この拡張可能でカスタマイズ可能なレイヤ 3 カプセル化メカニズムにより、送信元デバイスと宛先デバイスを変更する必要がないため、幅広いユースケースをサポートし、カスタマーエクスペリエンスを簡素化できます。このドキュメントで後述する Geneve TLV 形式を参照してください。Geneve カプセル化の代替として、VXLAN と GRE が評価されましたが、フィールドのサイズが固定されているため、上記の要件を満たすことができませんでした。 GWLBはフローの送信先となるアプライアンスをどのように選択しますか？ GWLBは新しいTCP/UDPフローを受信すると、5タプルのフローハッシュ（送信元IP、宛先IP、転送プロトコル、送信元ポート、宛先ポート）を使用してターゲットグループから正常なアプライアンスを選択します。その後、GWLBはそのフローのすべてのパケット（順方向と逆方向の両方）を同じアプライアンスにルーティングします（スティッキ性）。TCP/UDP以外のフローでも、GWLBは引き続き3タプル（送信元IP、宛先IP、トランスポートプロトコル）を使用して転送を決定します。 GWLB はアプライアンスのヘルスチェックをどのように実行しますか? GWLB は、ユーザーが定義した時間間隔に基づいて定期的にヘルスチェックを実行します。GWLB は、TCP/HTTP/HTTPSパケットをアプライアンスに送信することにより、これらのヘルスチェックを実行します。アプライアンスは、以下に説明するように TCP/HTTP/HTTPS パケットに応答する必要があります。 TCP : 接続の確立は成功とみなされます。 HTTP : GWLB は、ユーザーが指定したパスを使用して、新しい TCP 接続を介してアプライアンスに HTTP リクエストを送信します。アプライアンスは TCP 接続を確立し、200〜399 の範囲のステータスコードで応答する必要があります。TCP 接続の確立に失敗した場合、アプライアンスが他のステータスコードで応答した場合、またはアプライアンスが単に応答しない場合、ヘルスチェックは失敗します。 HTTPS : HTTP の動作と同じですが、TLS 経由です。GWLB は証明書のホスト名検証を行わないため、有効な証明書（有効期限が切れていない証明書または自己署名証明書）はすべて機能します。 アプライアンスは、GWLB のタイムアウト内にすべてのチェックを完了する必要があります。これらのチェックは、通常はコントロールプレーンからのTCP/HTTP/HTTPSパケットに正しく応答したアプライアンスが、データプレーンを介して宛先にパケットを転送することもできることを前提としています。ヘルスチェックパケットは Geneve カプセル化されていないことに注意してください。GWLB ヘルスチェックについては、 このドキュメント を参照してください。 GWLB とアプライアンス間で、パケットはどのように流れますか? 次の図は、送信元 (IP アドレス A.B.C.D) から宛先 (IP アドレス E.F.G.H) に移動するときのパケットのフローを示しています。送信元からのパケットは、ルートテーブルのネクストホップを使用して GWLBE に送信されます。 ステップ1 ：GWLBE は送信元からパケットを受信すると、基盤となる PrivateLink 技術を使用してパケットを GWLB に送信します。パケットは AWS ネットワーク上にとどまり、GWLB に到達します。 ステップ 2 : GWLB は、受信パケットの 5 タプル (Src IP、Dest IP、Src ポート、Dest ポート、プロトコル) を使用して、特定のアプライアンスをターゲットとして選択します。さらに、GWLB はフロークッキーを生成します (ステップ 4 で説明)。次に、GWLB はフローエントリとそれに対応するフロー Cookie をフローテーブルに保存します。次に、GWLB は Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、Type、Length、Valueのトリプレット（TLVとも呼ばれる / 緑色で表示）の形式でメタデータを埋め込みます。TLV はステップ 4 で説明されています。この例では、GWLB の IP アドレスは 10.1.4.10 で、アプライアンスの IP アドレスは 10.1.2.5 です。 ステップ 3 : GWLB はカプセル化されたパケットを特定のアプライアンスに転送します。GWLB は、そのフローが存続している間、その 5 タプルフローを両方向のトラフィックの特定のアプライアンスに固定します。 ステップ 4 : アプライアンスは、UDP/IP パケットを受け入れることができる IP インターフェースで構成する必要があります。アプライアンスに転送されるすべてのパケットは、その IP インターフェイスで転送されます。 アプライアンスは、TLV 内の情報を解析して意思決定に使用する必要があります。パケットには、次の Geneve TLV が 1 つ以上含まれます。 GWLBE/VPCE ID : これは、GWLBE に割り当てられた 64 ビットの ID です。GWLBE は VPC エンドポイントの一種なので、GWLBE ID は VPCE ID と同じです。たとえば、アプライアンスはこの識別子を使用してパケットを設定に関連付けることができます。この GWLBE/VPCE ID は、トラフィックのソース VPC を決定するために使用できます。各 GWLBE は 1 つの VPC にのみ属することができます。GWLBE から VPC へのマッピングをアプライアンスに提供するのは、アプライアンスパートナーの管理ソフトウェアです。 フロークッキー :フロークッキーは、GWLB が最初にフローテーブルにフローエントリを作成したときにフロー用に生成される 32 ビットの乱数です。フロークッキーはフローごとに固有であり、パケットの内容から生成されるものではありません。アプライアンスはこの Cookie を「現状のまま」返さなければなりません。GWLB がアプライアンスからパケットを受信すると、アプライアンスから受信したパケットのクッキーがそのフローに割り当てられたクッキーと一致する場合にのみ、パケットはさらに転送されます。Cookie が一致しない場合、または Cookie がない場合、パケットはドロップされます。 [未来使用予定] アタッチメント ID ：GWLB が TGW、VPNGW、または Direct Connect に直接接続する場合、64 ビットのアタッチメント ID TLV がアプライアンスに送信され、送信元の VPC ID が決定されます。これはオプションの TLV で、別の AWS ゲートウェイデバイスに接続されている場合にのみ表示されます。これは将来の TLV であり、現在は存在しません。 TLV を処理した後、アプライアンスはパケットをドロップするか、転送を許可するかを選択できます。 アプライアンスがパケットを転送する場合、次のことを行う必要があります。 元のパケットを Geneve ヘッダー内にカプセル化します 外部 IPv4 ヘッダーの送信元 IP アドレスと宛先 IP アドレスを交換します（送信元 IP = アプライアンス IP アドレス、宛先 IP = GWLB IP アドレス) 元のポートを保持し、外部 IPv4 ヘッダーの送信元ポートと宛先ポートを交換してはなりません 外側の IPv4 ヘッダーの IP チェックサムを更新します 元の内部パケットの指定された 5 タプルの TLV をそのままにして、パケットを GWLB に返します ステップ 5 : アプライアンスは Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、そのフローで最初に受信したのと同じメタデータ（緑色で表示）を埋め込みます。 ステップ 6 : アプライアンスからパケットを受信すると、GWLB は Geneve カプセル化を削除します。次に、GWLBは、着信（内部）パケットの5タプルとフロークッキーを、ステップ 2 で以前に保存したフローエントリとフロークッキーの組み合わせと比較することにより、着信パケットを検証します。着信パケットの 5 タプルとフロークッキーが GWLB キャッシュ内の対応するエントリと一致する場合のみ、GWLB はパケットを GWLBE に転送します。GWLB は、キャッシュに一致するものがない場合、または着信パケットの 5 タプルまたはフロークッキーが変更された場合、着信パケットをサイレントにドロップします。 ステップ 7 : パケットは、基盤となる PrivateLink 技術を使用して GWLBE に転送されます。パケットは AWS ネットワークに留まり、GWLBE に到達します。GWLBE は、ルートテーブルのネクストホップを使用して宛先にパケットを配信します。 GWLB とアプライアンスが交換するパケット形式はどのようなものですか？ 以下のパケット形式は、Geneve カプセル化を使用してアプライアンスで受信したパケットを示しています。Geneve ヘッダーの説明については、Geneve プロトコル ( RFC 8926) を参照してください。 Outer IPv4 Header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live |Protocol=17 UDP| Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = xxxx | Dest Port = 6081 Geneve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer Geneve Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|Opt Len = 8|O|C| Rsvd. | EtherType = 0x0800 or 0x86DD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Network Identifier (VNI) = 0 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer Geneve Options: AWS Gateway Load Balancer TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 1 |R|R|R| Len = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit GWLBE/VPCE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 2 |R|R|R| Len = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit Customer Visible Attachment ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class = 0x0108 (AWS)| Type = 3 |R|R|R| Len = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flow Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Customer payload follows… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Customer payload identified by EtherType in Geneve header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ アプライアンス統合のテストとデバッグのプロセスはどのようなものですか? アプライアンスソフトウェアが Geneve プロトコル、GWLB TLV のエンコード/デコードをサポートし、ヘルスチェックに応答したら、テストを行います。 VPC と必要なコンポーネントを作成します。GWLB、GWLBE、およびターゲットグループにアプライアンスを追加します。最も単純なテストケースとして、単一のアプライアンスから始めることができます。アプライアンスがヘルスチェックに応答しているかどうかを確認します。アプライアンスのパケットキャプチャをオンにすると、パケットフローを確認できます。パケットが前のセクションで示した想定どおりの形式であることを確認します。ヘルスチェックが機能しているときは、アプライアンス VPC の GWLB サブネットで VPC フローログを有効にします。GWLB エンドポイントサブネットのカスタマー VPC で VPC フローログを有効にできます。フローログを使用して、各方向からの送受信パケットを確認します。 まとめ 私たちの目標は、お客様とパートナーが Gateway Load Balancer をあらゆるネットワークパスに簡単に追加する方法として使用できるようにすることです。スケール、可用性、サービス提供、フローのスティッキーといった問題を AWS に任せていただければ、コアとなる専門知識に集中してイノベーションを加速できます。セキュリティ、分析、テレコム、モノのインターネット (IoT) のユースケースや、まったく新しいアプリケーションの可能性を切り開くことを期待しています。 この投稿では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法に焦点を当てています。何ができるかについて読者の皆様の想像力を刺激できていましたら幸いです。 詳細を知りたい場合は、次のリンクをご活用ください。 GWLB の FQA 製品概要ページ テクニカル・ドキュメント Gateway Load Balancer のすべてのブログ ローンチのお知らせ スタートガイドビデオ (11:06) Github コードサンプル 著者について Milind Kulkarni Milind は、アマゾン ウェブ サービス (AWS) のシニアプロダクトマネージャーです。ネットワーキング、データセンター アーキテクチャ、SDN/NFV、クラウド コンピューティングの分野で 20 年以上の経験があります。彼は 9 つの米国特許の共同発明者であり、3 つの IETF 標準を共同執筆しています。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文は こちら です。

エグゼクティブやそのチームに実用的で客観的なインサイトを提供する Gartner は、 2023 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) を発表しました。AWS は、柔軟で AI を活用したクラウドコンタクトセンターである Amazon Connect を 2017 年に提供開始して以来、初めてリーダーに選ばれました。私たちはこのリーダーへの選出は、あらゆる規模の企業が優れた顧客体験を低コストで提供可能にする私たちのイノベーションのペースの速さを反映していると考えています。 AWS の実行能力とビジョンの完全性が、AWS が CCaaS 分野のリーダーに選ばれた理由です。Gartner の Critical Capabilities の調査では、AWS はアジャイルコンタクトセンターで 1 位、グローバルコンタクトセンターでは 2 位、デジタルカスタマーサービスセンターとカスタマーエンゲージメントセンターのユースケースでは 3 位となっています。 Amazon Connect は 2017 年に提供開始されて以来、オムニチャネルのカスタマーエクスペリエンス、エージェントの生産性、分析、洞察、最適化のための新機能を継続的に発表してきました。 Amazon Connect 担当のバイスプレジデントである Pasquale DeMaio は、次のように語っています。「お客様やエージェントに、これまでにない体験を提供できるようになったことを大変嬉しく思います。過去 1 年間に多額の投資を行い、エージェントへのステップバイステップのガイダンス、ケース管理、予測、キャパシティプランニング、スケジューリング、画面録画などの 重要な新機能 をリリースしました。私たちはこの勢いを維持しており、このような一連の機能拡張が私たちをリーダーとして認める重要な要因になったと考えています。」 現在、Priceline、Deliveroo、Unum、Capital One、富士通、Intuit、John Hancock、 New York Times、National Australia Bank などの Amazon Connect のお客様 は、Amazon Connect を利用してより良い顧客体験を提供しています。 Gartner のレポートは、お客様のビジネスに適したクラウドコンタクトセンターソリューションを評価する際の、洞察に富んだガイダンスを提供しています。 2023 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) の無償版は、こちらからご覧いただけます 。 この図は、Gartner, Inc. が発行したより大きな調査文書の一部であり、文書全体の文脈で評価されるべきものです。 Gartner の文書は、 AWS にリクエストすることで入手可能です。 GARTNER および Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。すべての権利は留保されています。All rights reserved. Gartner は、その調査出版物に記載されているいかなるベンダー、製品またはサービスも推奨するものではなく、また、テクノロジーユーザーに対して、最高の格付けまたはその他の指定を受けたベンダーのみを選択するよう助言するものでもありません。Gartner の調査出版物は、 Gartner の調査組織の見解で構成されており、事実の記述として解釈されるべきものではありません。ガートナーは、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

データベースリソースの使用率を把握すると、データベースワークロードの特性と使用傾向を理解するのに役立ちます。このデータは参照点として役立ち、後の測定値と比較することでパフォーマンスの問題を特定して調査できます。偏差は、パフォーマンスのチューニング、データベースのメンテナンス、または構成の変更を必要とする懸念事項を示している可能性があります。 リソース使用率は通常、オペレーティングシステムとデータベースの使用状況、データベースの待機イベント、クエリ処理時間など、データベースのパフォーマンスに影響を与えるメトリクスを取得します。通常の業務中にこのデータを定期的に収集することで、データベースインスタンスの状態に関する洞察を得ることができます。 Amazon Relational Database Service (Amazon RDS) は、1 分間隔でメトリクスデータを Amazon CloudWatch に自動的に送信します。期間が 1 分のデータポイントは 15 日間使用できます。つまり、開始点となるインスタンスの履歴情報があるということです。収集したメトリクスを使用して、CPU、メモリ、ディスク、ネットワーク、クライアント接続など、データベースインスタンスのリソース使用率を左右するアプリケーションのワークロードパターンを大まかに把握できます。 Amazon RDS には、RDS インスタンスのリソース使用状況を把握するのに役立つ以下のモニタリングツールが用意されています。 Amazon RDS 拡張モニタリング Amazon RDS Performance Insights この投稿では、 Amazon RDS for SQL Server でリソース使用率メトリクスをキャプチャしてチューニングする方法を示します。 Amazon RDS 拡張モニタリング 拡張モニタリングは、DB インスタンスが実行されているオペレーティングシステムのメトリクスをリアルタイムで提供します。これらのメトリクスには 1 秒単位で細かく設定することができ、Amazon RDS コンソールまたは API からアクセスできます。拡張モニタリングは DB インスタンス上のエージェントからメトリクスを収集するのに対し、CloudWatch はハイパーバイザーレイヤーでメトリクスを収集します。詳細については、「 拡張モニタリング 」をクリックしてください。 主なメトリクスは次のとおりです。 CPU Utilization – CPU 使用率を監視すると、パフォーマンスの問題の原因が CPU 負荷によるものかどうかを特定するのに役立ちます。たとえば、パフォーマンスの問題が発生した時点で CPU 使用率が 80% で、先週の同じ時間帯の CPU 使用率が同様で問題が報告されなかった場合、CPU がボトルネックではない可能性があります。 Disk – 読み取り/書き込み IOPS などのメトリクスを使用して I/O とストレージの使用パターンを追跡し、傾向を把握できます。また、ストレージのキャパシティプランニングにおいて、 gp2 や io1 ディスクなどの使用可能なボリュームタイプから選択するのにも役立ちます Memory – パフォーマンス問題はメモリのボトルネックが関係していることが多くあります。拡張モニタリングでは、システム (合計メモリと使用可能なメモリ) と SQL Server (SQL Server の合計メモリ) のメモリ使用量とパターンを追跡して、ボトルネックを特定できます。 Network – 拡張モニタリングによって収集されるネットワークパフォーマンスメトリクス (ネットワーク読み取り KB/秒、ネットワーク書き込み KB/秒) は、ネットワーク経由で転送されるデータ量を追跡するのに役立ちます。 これらのメトリクスを使用すると、ビジネスプロセスの重要な日時におけるリソースの使用状況を的確に把握できます。これらの値はリソース使用率の全体像を把握できるため、比較して潜在的なボトルネックを特定する必要がある場合に役立ちます。 CloudWatch でダッシュボードを作成すると、説明されているこれらのパフォーマンスメトリクスを一元的に表示できます。次のスクリーンショットは、CloudWatch と拡張モニタリングのデータを含む統合ダッシュボードを示しています。 Amazon RDS Performance Insights Performance Insightsは、RDS データベースのパフォーマンスに関する洞察を提供する監視ツールです。Performance Insights の無料利用枠では、RDS データベースから毎秒データを収集し、7 日間保持します。長期的なパフォーマンストレンドについては、パフォーマンスデータの履歴を最大 2 年間まで延長できます。Performance Insights で表示される情報は ネイティブパフォーマンスメトリクスに基づくため、RDS データベースエンジンごとに若干異なります。Performance Insights を使用すると、一定期間のデータベース負荷、上位の待機タイプ、上位 SQL クエリの傾向を収集できます。この情報を使用して現在のデータと比較し、潜在的な根本原因を特定できます。 ほとんどの SQL Server データベース管理者は、SQL Server の問題を診断およびデバッグするための動的管理ビュー (DMV) に精通しています。DMV ではデータは収集されたままであるため、使用傾向を把握するメカニズムを開発する必要があります。そこで、データの収集と保存を自動化することで Performance Insights が役に立ちます。 主なメトリクスは次のとおりです。 Access Methods – ページ分割 – これにより I/O のボトルネックが発生する可能性があり、数値が大きい場合は、インデックスの再構築や フィルファクター 設定の再検討などのメンテナンス作業が必要であることを示している可能性があります。 Blocks and Locks – ロックの競合は SQL Server のパフォーマンス上の問題を引き起こす可能性があります。傾向分析のためだけでなく、データベースのパフォーマンスを向上させるためにチューニングが必要な SQL を特定するためにも、この情報を追跡することが重要です。ブロックされたプロセスとデッドロックの数を追跡できます。 Memory Manager – 保留中のメモリ許可は、一定期間のメモリボトルネックを追跡するのに役立ちます。 SQL Stats – Performance Insights には、バッチリクエスト、SQL コンパイル、SQL 再コンパイルなど、通常のデータベース負荷の原因となるタスクを理解するのに役立つさまざまな SQL 統計があります。 Buffer Manager – ページ寿命とバッファキャッシュヒット率は、メモリ不足の検出に役立ちます。ページ読み取りとページ書き込みは、インデックス作成の見直しが必要な場合など、最適化方法に関するガイダンスを提供します。 これらのメトリクスは、SQL Server のパフォーマンスに関するインサイトを提供します。パフォーマンスメトリクスを含む OS とデータベースのメトリクスを詳しく調べて、問題の根本原因を理解することができます。次のスクリーンショットは、これらのメトリクスの例を示しています。 動的管理ビューとクエリストア 異常を特定したら、動的管理ビューを使用してさらに深く調査し、パフォーマンスの問題をデバッグできます。詳細については、「 システム動的管理ビュー 」を参照してください。 SQL Server 2016 以降、Amazon RDS for SQL Server はクエリストアもサポートします。これを使用して SQL ステートメントのクエリプランを追跡および管理できます。詳細については、「 Amazon RDS for SQL Server が Microsoft SQL Server 2016 をサポートするようになりました 」を参照してください。 問題の診断とデバッグ: CPU 使用率 アプリケーションが昨日まで最適なパフォーマンスを発揮していたのに、現在はパフォーマンスが低下しているという一般的なシナリオを見てみましょう。このユースケースでは、CloudWatch アラートまたはユーザーからの苦情を通じてこのことを知りました。 メトリクスを調べることから問題の診断を開始します。CloudWatch では、CPU 使用率メトリクスが高く、おそらく 90% を超えていることがわかります。SQL Server プロセスがこの高いパーセンテージに寄与しているかどうかを知りたいと思うでしょう。Amazon RDS コンソールの モニタリング タブの プロセスリスト から確認できます。 このような場合は、RDS インスタンスのリソース使用状況を追跡することが役立ちます。データがキャプチャされれば、時間の経過に伴う CPU 使用率の傾向を効率的に特定できます。拡張モニタリングでは、過去 30 日間のインスタンスの CPU 使用率の傾向をグラフ化できます。これにより、この挙動が正常かどうかがわかります。 次のステップは、Performance Insights でキャプチャされたデータを使用して、CPU 負荷の原因となっているクエリを特定することです。次のスクリーンショットは、時間の経過と共に蓄積されたデータを含むグラフを示しています。 このグラフから、このインスタンスでは CPU の待ち時間が大部分であり、一定期間にわたって増加していることがわかります。この傾向から、キャパシティプランニングに必要なデータも得られます。 関心のある時間に絞り込むと、CPU 使用率別の上位 T-SQL クエリのリストを表示できます。動的管理ビューから実行プランやクエリに関する詳細情報を取得できます。 高い CPU 負荷の原因となっている上位 3 つのクエリをとうとう特定しました。クエリ自体に加えて、クエリを実行している上位のホストと上位ユーザーを特定して、トラブルシューティングの取り組みをさらに絞り込むことができます。 最初のクエリを例として使用します。SQL Server Management Studio (SSMS) を使用してクエリの実行統計と実行プランを取得するには、まずクエリのフィンガープリントを知る必要があります。この情報は、パフォーマンスインサイトから取得できます。 SQL ID は、統計と実行プランを取得するために動的管理ビューに入力する値です。次のスクリーンショットに示すように、SQL ID の前に 0x を付ける必要があります。 クエリプランを作成したら、次のステップは、既知の クエリ最適化方法 を使用してクエリを最適化することです。 結論 この投稿では、インスタンスの状態と使用パターンをキャプチャして分析するための優れた方法を提供する、Amazon RDS for SQL Server の拡張モニタリングと Performance Insights について学びました。この情報があると、パフォーマンス問題の最適化とトラブルシューティングに役立ちます。この記事で説明する方法を使用すると、インスタンスのパフォーマンスを向上させることができます。 著者について Barry Ooi は、AWSのシニアデータベーススペシャリストソリューションアーキテクトです。彼の専門分野は、お客様が AWS を利用する一環としてクラウドネイティブサービスを使用してデータプラットフォームを設計、構築、実装することです。彼の関心分野には、データ分析と視覚化が含まれます。休暇では、音楽と野外活動を楽しみます。 LRita Ladda は、アマゾンウェブサービスのマイクロソフトスペシャリストシニアソリューションアーキテクトで、さまざまなマイクロソフトテクノロジーで 20 年以上の経験があります。SQL Server やその他のデータベースにおけるデータベースソリューションの設計を専門としています。Microsoft ワークロードの AWS への移行とモダナイゼーションに関するアーキテクチャに関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

Amazon CodeWhisperer などの AI コーディング支援ツールは、デベロッパーがコードを迅速かつ安全に記述できるようにサポートすることで、デベロッパーの生産性を向上させることを目的としています。しかし、特定のケースでは、デベロッパーは、毎日多用する内部ライブラリと API に基づくコードのレコメンデーションが必要です。 既存の AI コーディング支援ツールのほとんどはオープンソースコードでのみトレーニングされているため、プライベートコードリポジトリを使用してコードのレコメンデーションをカスタマイズすることができません。この制限により、デベロッパーにはさまざまな課題が生じます。デベロッパーが内部ライブラリを正しく使用し、セキュリティ上の問題を回避する方法を学習するのは困難です。大規模なコードベースの場合、該当のタスクを完了するためにどのようなコードを記述する必要があるかを理解するために何時間もドキュメントを読む必要があります。 現在プレビュー版を提供中 – Amazon CodeWhisperer のカスタマイズ機能 10月7日、組織が CodeWhisperer をカスタマイズして、プライベートコードリポジトリからコードに関する特定のレコメンデーションを生成できるようにする Amazon CodeWhisperer のカスタマイズ機能 (プレビュー版) を発表しました。この機能により、 Amazon CodeWhisperer Professional 階層をご利用のデベロッパーは、内部ライブラリ、API、パッケージ、クラス、メソッドを含む、コードに関するリアルタイムのレコメンデーションを受け取ることができるようになりました。 自分が AnyCompany という架空の食品配送会社に勤務するデベロッパーであると想像してみてください。ドライバーの現在地周辺で割り当てられていない食品配送のリストを処理するタスクが与えられました。以前の CodeWhisperer では、未割り当ての食品配送を処理したり、ドライバーの現在地を取得したりするための正しい内部 API を認識できませんでした。その理由は、この情報が公開情報ではないからです。 カスタマイズ機能を使用することで、会社の内部サービスに関連する特定のコードを含むレコメンデーションを提供するよう CodeWhisperer に指示することができます。次のスクリーンショットは、一連のコメントを記述するだけで CodeWhisperer が内部コードベースに基づいてコードを生成する様子を示しています。 内部コードベースを利用するカスタマイズ機能により、CodeWhisperer は意図を理解し、タスクに最適な内部 API とパブリック API を判断して、コードに関するレコメンデーションを生成するようになりました。 仕組み 上記の説明では、デベロッパーとして CodeWhisperer のカスタマイズ機能を使用する方法を示しました。次に、その仕組みと開始方法について見ていきましょう。 カスタマイズを作成するには、CodeWhisperer の管理者として次のステップを完了する必要があります。 CodeWhisperer の管理者 としてエンドユーザーを管理します。 既存のリポジトリに接続します。 AWS CodeStar 接続を使用して、GitHub、GitLab、または BitBucket アカウント内の 1 つ以上のコードリポジトリに接続するか、またはすべてのコードを Amazon Simple Storage Service (Amazon S3) バケットに手動でアップロードできます。 カスタマイズを作成します。CodeWhisperer はコードベースに基づいてモデルをカスタマイズします。 チームメンバーのためにカスタマイズをアクティブ化します。カスタマイズが作成されたら、カスタマイズを確認して、チームメンバーの IDE で自動的に使用可能になるように手動でアクティブ化できます。 この機能は、組織に固有のカスタマイズされたコードに関するレコメンデーションをリアルタイムで提供し、貴重な知的財産を確実に保護するという 2 つの主な利点を提供します。組織は、既存のリポジトリ内のコードに基づいて、品質およびセキュリティ基準を満たすコードの使用を推進できるようになりました。 さらに、CodeWhisperer は、 AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用してカスタマイズデータを暗号化するオプションを提供することで、コードのセキュリティを確実に維持します。このカスタマイズデータは、カスタマイズジョブが完了すると削除されます。 使用を開始しましょう ここからは、Amazon CodeWhisperer のカスタマイズ機能を使用する方法を説明します。 使用を開始するには、カスタマイズを作成する必要があります。Amazon CodeWhisperer ダッシュボードの [カスタマイズを作成] ページに移動するには、管理者アクセスが必要です。 [カスタマイズを作成] ページで、CodeWhisperer にトレーニングさせたいプライベートコードリポジトリに接続できます。現在、CodeWhisperer のカスタマイズ機能は、 AWS CodeStar 接続を介した GitHub、GitLab、Bitbucket への接続をサポートしています。使用するコードがいずれのコードリポジトリにもない場合は、コードを手動で S3 バケットにアップロードし、Amazon S3 URI を定義することもできます。 次のスクリーンショットは、自分のコードリポジトリとの間に AWS CodeStar 接続を使用した既存の接続があることを示しています。 [新しい接続を作成] を選択して、新しい接続を作成することもできます。 その後、 [カスタマイズを作成] を選択すると、接続で使用可能なコードに基づいて、CodeWhisperer がモデルのトレーニングを開始できるようになります。このプロセスが完了するのにかかる時間は、コードリポジトリのサイズによって異なります。 カスタマイズの準備ができても、CodeWhisperer は、そのカスタマイズを自動的にアクティブ化しません。これにより、必要なときにそのカスタマイズをアクティブ化できる柔軟性が得られます。しかし、そのデモンストレーションを行う前に、 [評価] スコアについてご説明します。 簡単にお伝えすると、評価スコアは、コードリポジトリ内のコードに基づいて、コードに関するレコメンデーションを予測および提供する際のカスタマイズの精度を測定するのに役立ちます。スコアは、1) [非常に良い] (スコア: 7～10)、2) [普通] (スコア: 4～7)、3) [悪い] (スコア: 0～4) という 3 つのカテゴリのいずれかで提供されます。評価スコアが 6 以上の場合は、カスタマイズをアクティブ化することをお勧めします。評価スコアが希望するスコアよりも低い場合は、カスタマイズのために十分なコードが確実に提供されているようにして、内部 API への参照を広範囲に含む新しいコードデータセットを提供する必要があります。 ここでは、カスタマイズの [評価スコア] は 8 であるため、私はこの結果に満足しています。その後、 [アクティブ化] を選択して、このカスタマイズの使用を開始できます。 カスタマイズをアクティブ化したら、 [ユーザーを追加] を選択して、選択したカスタマイズへのアクセスを定義できます。これで、Amazon CodeWhisperer Professional 階層のユーザーとして追加された、選択したチームメンバーのために、カスタマイズへのアクセスを付与できるようになりました。これを行うには、「 Administering end users 」ページのガイドに従います。 その後、チームメンバーが IDE で AWS Toolkit 経由でサインインすると、使用可能なカスタマイズが表示され、使用を開始できるようになります。 Amazon CodeWhisperer を利用すると、さまざまなコードリポジトリを提供することで複数のカスタマイズを作成できます。この機能は、特定のチームのために、コードに関するレコメンデーションのカスタマイズを構築する場合に役立ちます。 管理者は、CodeWhisperer ダッシュボードページに移動して、各カスタマイズのパフォーマンスをモニタリングすることもできます。このページでは、ユーザーアクティビティ、CodeWhisperer によって提案され、チームメンバーによって受け入れられたコードの行数、IDE から正常に実行されたセキュリティスキャンの数などの有用なデータの要約を確認できます。 また、Amazon CodeWhisperer のカスタマイズ機能は、Visual Studio Code、IntelliJ JetBrains、Visual Studio、AWS Cloud9 など、AWS Toolkit by Amazon CodeWhisperer の一部としてサポートされている IDE に従います。この機能は、Python、Java、JavaScript、TypeScript、C# などの極めて一般的なプログラミング言語のサポートも提供します。 パブリックプレビューにぜひご参加ください Amazon CodeWhisperer は、お客様の内部コードベースを安全に活用することで、独自の要件に合わせてカスタマイズされた、生成系 AI を活用したコーディングの可能性を最大限に引き出します。 今すぐパブリックプレビューに参加し、 Amazon CodeWhisperer のカスタマイズ のページで開始方法の詳細をご覧ください。 コーディングをお楽しみください! –  Donnie 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 皆さんの中にはAWS PrivateLinkをお使いの方も多いのではないでしょうか？ 実は、PrivateLinkのリージョン対応はWhat’s newが出ないことが多く、気づかれてないことも多いです。 最近だと大阪リージョンのAPI Gatewayで private API が利用できるようになっています。もし、対応を待っているサービス、リージョンがある場合定期的にチェックしてみてください。お近くにSAにお声がけいただくのもOKです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月16日週の主要なアップデート 10/16(月) Introducing Amazon EC2 R7i instances Amazon EC2 R7i インスタンスがGAしました。第4世代 Xeon スケーラブル・プロセッサー(Sapphire Rapids)を搭載したR7iは最大48xlargeという大きなインスタンスサイズと、DDR5メモリを備えており、SAPのほかSQL、NoSQLのデータベース、SAP HANAなどのインメモリデータベース、HadoopやSparkなどのビックデータ分析などメモリを大量に必要とするワークロードに最適です。R7iインスタンスはバージニア北部、オハイオ、オレゴン、アイルランド、ストックホルム、スペインのリージョンでご利用いただけます。 AWS Client VPN extends availability to three additional AWS Regions AWS Client VPNの提供リージョンが３つ追加され、大阪リージョンでもご利用いただけるようになりました。大阪リージョンにないことで代替で東京リージョンでご利用だった、または大阪リージョンのEC2でVPNアプライアンスをご利用だった皆様はぜひご活用ください！ Introducing Recover into Existing Instance for AWS Elastic Disaster Recovery AWS Elastic Disaster Recovery (AWS DRS) が既存のインスタンスへの復元をサポートしました。これまでDRSでAWS上のインスタンスを復元する際は新しいインスタンスを起動する必要がありました。今回のアップデートにより元のインスタンスまたは事前に設定した既存インスタンスへの復元に対応しました。この機能追加はDRSが利用可能なすべてのリージョンで利用可能です。 10/17(火) Announcing Regional Expansion of ml.p4d instances on SageMaker Inference SageMakerでml.p4dを利用できるリージョンに東京とフランクフルトが追加されました。ml.p4dインスタンスはNVIDIA A100を搭載したインスタンスでリアルタイム・非同期推論のためのMLモデルに向いています。同時に” Preview of Regional Expansion for ml.p4d, ml.trn1, and ml.g5 instances on SageMaker Inference “で、ml.p4d.24xlargeが東京リージョンを含む新たに４リージョンでプレビュー利用できるようになったこともアナウンスされています。 Amazon OpenSearch Service adds support for four new language analyzers Amazon OpenSearch Serviceに日本語のSudachiを含む４つの言語アナライザープラグインが追加されました。日本語のプラグインとしてはこれまでもKuromojiがサポートされていましたが、新たな選択肢が追加された形です。これらの新しいプラグインは‘TXT-DICTIONARY’に加えて‘ZIP-PLUGIN’として提供されています。これらの追加プラグインはAmazon OpenSearch Serviceが利用可能なすべてのAWSリージョンで利用できます。 Amazon Relational Database Service announces Dedicated Log Volume Amazon RDSがPostgreSQL、MySQL、及びMariaDBでDedicated Log Volumeをサポートしました。Dedicated Log Volumeはトランザクションログを専用ボリュームに保存する設定です。データベースで最もレイテンシー変動の影響を受けやすいトランザクションログを個別のボリュームに書き込むため、クエリやデータ更新との衝突が減りコミット待ちやIPOS要求が軽減されます。詳細については ドキュメント をご確認ください。 10/18(水) Amazon Redshift announces integration with AWS Secrets Manager Amazon RedshiftがAWS Secrets Managerとの統合をサポートしました。データベースの作成、変更、復元など管理者権限が必要な作業の職務権限分離が容易になるほか、KMSと連携してのシークレットの暗号化も簡単になります。この機能はRedshiftが利用可能なすべてのAWSリージョンで、プロビジョニングされたクラスターとサーバレス両方で利用可能です。 AWS IoT TwinMaker is now available in Tokyo, Seoul, and Mumbai デジタルツインを簡単に構築できるようにするマネージドサービスであるAWS IoT TwinMakerが新たに東京を含む3リージョンで利用できるようになりました。 Share Amazon Route 53 Application Recovery Controller clusters across multiple AWS accounts AWS Resource Access Manager (AWS RAM)を使用してAmazon Route 53 Application Recovery Controller (Route 53 ARC)のクラスターをAWS Organizationsの組織、もしくはOU内で共有できるようになりました。クラスターを共有できることで、クラスター数が減り、総コストの抑制につながります。また、AWS RAMを使用してRoute 53 ARCクラスターを共有するための追加料金は発生しません。 Amazon OpenSearch Service announces new administrative options Amazon OpenSearch Serviceでより詳細な制御ができるようになりました。OpenSearchはノードに異常がないか監視し、クラスターの安定性を維持するための是正を行ってくれるマネージドサービスです。一方で、エキスパートなユーザーがより綿密な管理を行うためにプロセスや、データノードの再起動などのオペレーションが追加されました。これらの管理オプションはOpenSearchの利用もしくはElasticsearch バージョン 7.0以上を実行しているすべてのクラスターでサポートされます。新しい管理オプションの詳細は ドキュメント をご確認ください。 10/19(木) AWS announces member account level credit sharing preferences AWS Organizationsの組織内で柔軟なクレジットのシェアが可能になりました。これまでクレジットの共有は組織全体に対して有効化または無効化しかできませんでした。今回のアップデートによりアカウント単位での選択・除外ができるようになったためより細かく管理することが可能です。詳細は ドキュメント をご確認ください。 Amazon OpenSearch Service now offers Amazon EC2 Im4gn instances Amazon OpenSearch ServiceにAWS Graviton2 プロセッサを搭載したAmazon EC2 Im4gn インスタンスが追加されました。Im4gn インスタンスは最大30TBのローカルNVMEストレージを搭載しており、非常に低いI/Oレイテンシーを要求されるリアルタイムログ分析等に向いています。このAmazon OpenSearch Service Im4gn インスタンスは東京を含む11のリージョンですぐにご利用いただけます。 AWS Glue for Apache Spark announces native connectivity for Google BigQuery AWS Glue for Apache SparkがGoogle BigQueryへのネイティブ接続をサポートしました。これまでもBigQueryとの接続はサポートされていましたが、コネクタのインストールが必要でした。今回のアップデートで事前の準備作業不要にBigQueryからのデータ読み込みやBigQuery SQLを使用しての操作等が可能になります。この機能はGlueが利用可能なすべての商用リージョンで利用できます。詳細については ドキュメント をご確認ください。 Amazon WorkSpaces now supports Windows Server 2022 bundles Amazon WorkSpacesにWindows Server 2022を搭載した新しいバンドルが追加されました。この追加はAmazon WorkSpacesが利用可能なすべてのリージョンで利用できます。なおWindows Server 2016/2019搭載のバンドルは引き続き利用可能です。 10/20(金) Amazon Kendra releases connectors for 11 JDBC data sources to enable structured data search 機械学習を利用した検索サービスのAmazon Kendraが11のデータベースに対して、コネクタ経由でコンテンツのインデックスを作成し、コンテンツ全体の情報を検索できるようになりました。対象のデータベースはAurora(MySQL互換、PostgreSQL互換)、RDS（MySQL、PostgreSQL、Oracle、Microsoft SQL Server）、MySQL、PostgreSQL、Oracle、Microsoft SQL Server、DB2です。これらの11のDBコネクタは、AmazonKendraが利用化の王なすべてのAWS リージョンでご利用いただけます。 AWS Service Catalog announces support for additional Infrastructure as Code (IaC) provisioning tools AWS Service CatalogでAnsible、Chef、Pulumi、Puppetなどがサポートされました。これまでサポートされていたCloudFormationやHashiCorp Terraform Clud configurationに加え、これらのツールをご利用のお客様はService Catalogを使うためにIaCツールの移行や変更をせずとも各種機能を利用することができます。この機能はAWS GovCloudを含めたAWS Service Catalogが利用できるすべてのAWSリージョンで利用できます。 AMI Block Public Access now enabled for all new accounts and existing accounts with no public AMIs Amazon Machine Image Block Public Access (AMI BPA)がすべての新しいAWSアカウント、及び2023年7月15日以降パブリックAMIを所有していないすべての既存AWSアカウントでデフォルトで有効になりました。これまではAMI BPAはデフォルトでは無効でした。この変更により誤ってAMIをパブリックに共有することが制限されるので、お客様のセキュリティの向上につながります。AMI BPAについての詳細は ドキュメント をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

Amazon Bedrock は、基盤モデル (FM) を使用して生成系AI アプリケーションを構築およびスケーリングする簡単な方法です。フルマネージドサービスとして、AI21 Labs、Anthropic、Cohere、Meta、Stabability AI、Amazon などの主要な AI 企業が提供する高性能な FM を選択できます。また、生成系 AI アプリケーションの構築に必要な幅広い機能も備えているため、プライバシーとセキュリティを維持しながら開発を簡略化できます。 BedrockはAmazon CloudWatchと統合されているため、使用状況のメトリクスを追跡し、監査目的でカスタマイズされたダッシュボードを構築できます。これらのメトリックスを使用して、単一アカウントの 1 つのファンデーションモデルから、複数のアカウントにわたるすべての基盤モデルへのモデル呼び出しやトークン数などの使用状況を把握できます。また、Bedrockではmodel invocation loggingと呼ばれる、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスを収集できる機能を顧客に提供しています。デフォルトではこれらの機能は無効になっているため、model invication loggingを開始するにはユーザが有効にする必要があります。 このブログ記事では、CloudWatch を使用して Bedrock をほぼリアルタイムで監視する方法について詳しく説明します。メトリクスとログを使用して、値が事前定義されたしきい値を超えたときにアラームをトリガーしたり、アクションを実行したりできます。CloudWatch には、クロスアカウントでのオブザーバビリティ、ログとメトリクスの相関関係、複合アラーム、ログ分析、アプリケーションパフォーマンスモニタリングなど、他にも活用できる豊富な機能が備わっています。 Model Invocation Loggingの設定 Model Invocation Loggingは現在プレビュー段階であるため、この機能に変更が加えられる可能性があることに注意してください。ロギングを有効にすると、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスが収集されます。 ロギングを設定するには、左側のナビゲーションバーからBedrockコンソールの設定ページに移動します。次に、Model Invocation loggingボタンを切り替えます。ロギングを有効にする前に入力する必要のあるフィールドがいくつか表示されます。 図 1: ログ (テキスト、画像、埋め込み) に含めるデータタイプの複数選択制御 次に、ロギング先を選択します。オプションは3つあります。1 つ目のオプションは S3 only で、選択した S3 バケットにのみログを送信するように Bedrock を設定します。2 つ目のオプションは CloudWatch Logs only で、ログを CloudWatch に送信し、モデルの入出力データが 100 KBを超える場合、 またはバイナリ形式の場合は、オプションで S3 に送信できます。最後のオプションは S3 と CloudWatch のログの両方 で、ログは S3 と CloudWatch の両方に送信され、モデルの入出力データのどちらかが 100 KB を超える場合やバイナリ形式のデータの場合は S3 にのみ送信されます。どのオプションを選択しても、KMS による暗号化や保存期間など、モデルの入力と出力を制御できます。このブログの場合は、 CloudWatch Logs のみ のオプションを選択しました。 CloudWatch ログ設定セクションで、ロググループ名を指定します (この場合は /aws/bedrock を選択しました)。最初にこのロググループを CloudWatch で作成する必要があることに注意してください。 次に、 Create and use a new role オプションを選択し、ロールの名前を指定します。今回は BedrockCloudWatchLogs を選びました。 最後に S3 に移動して S3 バケットを作成します。私の場合は、バケット名に bedrock-logging-[ACCOUNTID]-[REGION] という形式を選択しました。次に BedrockのSettingsメニュー に戻り、”S3 location for large data delivery“ フィールドで新しく作成したバケットを選択し、「設定を保存」をクリックして設定を完了します。 Bedrock からのログデータの生成 Bedrockでのロギングの設定が完了したので、AWSコンソールからBedrockのモデルを試せるプレイグラウンドを使用してログデータを生成してみましょう。 Bedrockのチャットプレイグラウンドに移動し、モデルを選択してプロンプトを表示します。このケースでは、Amazon CloudWatch の概要について簡単に説明してもらうようお願いしています。 図 2: BedrockのChat プレイグラウンド。Claude Instant V1.2 モデルを選択し、Amazon CloudWatch の概要を簡単に説明させている Logs Insights からロググループにクエリを実行すると、ほぼリアルタイムで新しく作成されたロググループのログが表示されるようになります。 図 3: CloudWatch ログインサイトクエリ。Bedrock のModel Invocation Logging用に新しく作成されたロググループからのログイベントを示している モデル呼び出しログが配信されたら、CloudWatch の 2 つの機能を使用してログを調べることができます。1 つは Live Tail で、もう 1 つは Log Insights です。 Live Tail を使用したストリーミングログ CloudWatch Logs の Live Tail は、ログが取り込まれるとほぼリアルタイムでインタラクティブに表示できる、インタラクティブなログ分析エクスペリエンスを提供する機能です。Live Tail は、受信したログの問題をすぐに確認して検出できる豊富なエクスペリエンスを顧客に提供します。さらに、問題のトラブルシューティング中に、フィルタリング、関心のある属性の強調表示、ログの一時停止/再生をきめ細かく制御できます。 図 4: CloudWatch LogsのLive TailBedrock。Chat Playground によって生成された Bedrock モデル呼び出しログからのログイベントを表示する Log Insightsによるログ分析 CloudWatch Log Insightsを使用すると、CloudWatch ログのログデータをインタラクティブに検索して分析できます。クエリを実行することで、運用上の問題により効率的かつ効果的に対応できます。 Bedrockの場合、Log Insightsを使用してモデル呼び出しログを検索および分析し、特定のキーワードまたは単に最新の呼び出しログを検索できます。コマンドの全リストは、 こちら でご覧いただけます。 図 5: Log Insights クエリ。ModelID、操作、入出力トークンの数、プロンプトを含む最新のログイベントを 100 件表示している Log Insightsは最近、MLベースのパターンクエリコマンドも導入しました。これにより、顧客はログの傾向やパターンをより簡単に識別できます。パターンコマンドは AWS Machine Learning アルゴリズムを使用して、ログデータ内のパターンを自動的に認識し、関連するログを集約し、数千のログ行を視覚化しやすいグループにまとめます。 以下の例では、この新しいパターンコマンドをモデル呼び出しログのプロンプトフィールドに使用して、Bedrockへのプロンプトのパターンを認識しています。 図 6: 1時間にわたるLog Insightクエリ。pattern コマンドを使用してプロンプトテキストを要約している。 機械学習によるCloudWatch ログのデータ保護 CloudWatch には、パターンマッチングと機械学習 (ML) を活用して転送中の機密データを検出して保護する一連の機能もあります。まず、ロググループのデータ保護ポリシーを有効にします。ポリシーを作成するときは、保護するデータを指定します。その際、100 を超えるマネージド なData identifiers (下図) から選択できます。 図 7: データ保護ロググループポリシーの設定 上の例では、ロググループ内の IP アドレスを検索するようにデータ保護ポリシーを設定しました。Bedrockに「192.168.0.1とは」と尋ねると、モデルの入出力ログイベントで検出されたIPアドレスをマスクします。 図 8: プロンプトフィールドで IP アドレスをマスクした JSON での単一モデル呼び出しのログイベント Bedrock ランタイムメトリクス BedrockはほぼリアルタイムのメトリクスをCloudWatchに送信します。これを使用して、特定のしきい値を監視するアラームを設定し、値がそのしきい値を超えたときに通知を送信したり、アクションを実行したりできます。また、 CloudWatch でメトリクスの異常検出 を有効にすることもできます。これにより、統計アルゴリズムと機械学習アルゴリズムを適用して、メトリクスを継続的に分析し、通常のベースラインを決定し、最小限のユーザー操作で異常を検知します。 図 9: CloudWatch の Anthropic Claude v1 メトリックと Anthropic Claude v2 メトリクスを含む積み上げ型面グラフで 15 分間の呼び出し数を示すビジュアライゼーション。 Bedrockが提供するランタイムメトリクスを以下に示します。 こちら でも確認できます。 メトリクス名 単位 説明 Invocations SampleCount InvokeModelもしくはInvokeModelWithResponseStreamのAPI操作によるリクエストの数 InvocationLatency MilliSeconds モデル実行のレイテンシー InvocationClientErrors SampleCount クライアントサイドのエラーに至ったモデル実行の数 InvocationServerErrors SampleCount サーバサイドのエラーに至ったモデル実行の数 InvocationThrottles SampleCount システムがスロットリングしたモデル実行の数 InputTokenCount SampleCount 入力テキストのトークン数 OutputTokenCount SampleCount 出力テキストのトークン数 ContentFilteredCount SampleCount 出力テキストコンテントがフィルターされた数 OutputImageCount SampleCount 出力画像の数 これらの指標は、次のようなさまざまなユースケースに使用できます。 InvocationLatency メトリクスと ModelID ディメンションを使用して、異なるモデル間のレイテンシーを比較します。 InputTokenCount と OutputTokenCount を分析してトークン数 (入力と出力) を測定し、プロビジョニングされたスループットの購入に役立てます InvocationThrottles メトリクスを使ってスロットリングを検出し、 CloudWatch アラームによってアラートを発信します 表示をシンプルにするために、BedrockがCloudWatchに送信するログとメトリクスは、CloudWatchダッシュボードを使用して単一のビューとして表示できます。複数の AWS アカウントをお持ちの場合は、CloudWatch のクロスアカウントオブザーバビリティを設定して、モニタリングアカウントに豊富なクロスアカウントダッシュボードを作成できます。 図 10: CloudWatch Dashboard には、モデル別の呼び出し数、モデル別の呼び出しレイテンシー、入出力別のトークン数、モデル呼び出しログからの最新のプロンプトが表示されます。 上のダッシュボードには、以下の情報が表示されています。 モデル別の呼び出し回数の推移 モデル別の呼び出しレイテンシー 入力トークンと出力トークン別のトークン数 モデル、操作、入出力トークンの数を示す呼び出しログの最新のプロンプト 結論 このブログでは、CloudWatch で Bedrock を監視し、基盤モデルと生成系 AI アプリケーションの使用状況に関する洞察を得る方法を示しました。Bedrock は、主要な AI プロバイダーの基盤モデルを使用して、生成系 AI アプリケーションの開発とスケーリングを簡単に行えるフルマネージド型サービスです。CloudWatch と統合して、メトリクスとログによるほぼリアルタイムの監視、監査、使用状況分析機能を提供します。Bedrock は CloudWatch との統合により透明性と制御を実現しつつ、大規模な生成系AI アプリケーションの構築を簡素化します。 原文は こちら をご覧ください このブログ記事は機械学習ソリューションアーキテクトの卜部が翻訳しました。

Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、ストリーミングデータの処理方法を簡素化する、完全に管理された可用性の高い Apache Kafka サービスを提供します。Apache Kafka を使用するときの一般的なアーキテクチャパターンは、あるクラスターから別のクラスターにデータを複製することです。 クロスクラスターレプリケーションは、事業継続とディザスタリカバリ計画を実施し、 AWS リージョン 全体でアプリケーションの回復力を高めるためによく使用されます。マルチリージョンアプリケーションを構築する際のもう一つのユースケースは、より低遅延なアクセスのために、複数の地域にあるストリーミングデータのコピーをエンドコンシューマーにより近い場所に保存させることです。また、分析のために、複数のクラスターのデータを 1 つの一元化されたクラスターに集約する必要がある場合もあります。 これらのニーズに対応するには、カスタムコードを書くか、バージョン 2.4 から Apache Kafka の一部として利用できる MirrorMaker 2.0 のようなオープンソースのツールをインストールして管理する 必要があります。しかし、これらのツールは、信頼性の高いレプリケーションのためのセットアップが複雑で時間がかかる場合があり、継続的な監視とスケーリングが必要です。 10月18日、 MSK レプリケータ をご紹介します。Amazon MSK のこの新しい機能は、MSK クラスター間の クロスリージョン および 同一リージョン のレプリケーションを確実にセットアップすることを容易にし、ワークロードを処理するために自動的にスケーリングします。MSK レプリケータは、 階層型ストレージ を使用するものを含め、プロビジョニングされた MSK クラスタータイプと サーバーレス MSK クラスタータイプの両方で使用できます。 MSK レプリケータを使用すると、アクティブパッシブとアクティブアクティブの両方のクラスタートポロジをセットアップして、リージョン間の Kafka アプリケーションの回復力を高めることができます。 アクティブ・アクティブ 設定では、両方の MSK クラスターがアクティブに読み取りと書き込みを処理しています。 アクティブ・パッシブ 設定では、一度に 1 つの MSK クラスターだけがストリーミングデータをアクティブに処理し、もう一方のクラスターはスタンバイ状態です。 ここで、実際にどのように機能するか見てみましょう。 AWS リージョン間での MSK レプリケータの作成 2 つの MSK クラスターを異なるリージョンにデプロイしています。MSK レプリケータでは、クラスターで IAM 認証が有効になっている必要があります。他のクライアントでは、mTLS や SASL などの他の認証方法を引き続き使用できます。ソースクラスターでは、マルチ VPC プライベート接続も有効にする必要があります。 ネットワークの観点から、クラスターのセキュリティグループは、クラスターとレプリケータが使用するセキュリティグループ間のトラフィックを許可します。例えば、同じセキュリティグループからのトラフィックと同じセキュリティグループへのトラフィックを許可する自己参照のインバウンドルールとアウトバウンドルールを追加できます。簡単にするために、両方のクラスターで デフォルトの VPC とその デフォルトのセキュリティグループ を使用します。 レプリケータを作成する前に、ソースクラスターの クラスターポリシー を更新して、MSK サービス (レプリケータを含む) がクラスターを見つけて到達できるようにします。 Amazon MSK コンソールで 、ソースリージョンを選択します。ナビゲーションペインから [ クラスター ] を選択し、次にソースクラスターを選択します。まず、一番上にあるソースクラスター ARN をコピーします。次に、[ プロパティ ] タブで、[ セキュリティ設定 ] の [ クラスターポリシーの編集 ] を選択します。そこで、次の JSON ポリシー (ソースクラスター ARN を置き換える) を使用して変更を保存します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "kafka.amazonaws.com" }, "Action": [ "kafka:CreateVpcConnection", "kafka:GetBootstrapBrokers", "kafka:DescribeClusterV2" ], "Resource": "<SOURCE_CLUSTER_ARN>" } ] } コンソールでターゲットリージョンを選択します。ナビゲーションペインから「 レプリケータ 」を選択し、「 リプリケータの作成 」を選択します。ここに、レプリケータの名前と説明を入力します。 ソースクラスターセクションで 、ソース MSK クラスターのリージョンを選択します。次に、[ ブラウズ ] を選択して、リストからソース MSK クラスターを選択します 。レプリケータは、クラスターポリシーが設定されているクラスターに対してのみ作成できることに注意してください。 デフォルトの VPC とそのデフォルトのセキュリティグループを使用するために、 サブネット と セキュリティグループ をデフォルト値のままにしています。このネットワーク設定を使用して、クラスターとの通信を円滑にするエラスティックネットワークインターフェイス (EIN) を配置できます。 ソースクラスターのアクセス制御方法 は IAM ロールベース認証 に設定されています。オプションで、複数の認証方式を同時にオンにして、リプリケータが IAM を使用している間も、mTLS や SASL などの他の認証方式を必要とするクライアントを引き続き使用できます。クロスリージョンレプリケーションでは、ソースクラスターへのアクセスに複数の VPC を使用するため、ソースクラスターは認証なしアクセスを有効にすることはできません。 ターゲットクラスターセクション では、 クラスターリージョン がコンソールを使用しているリージョンに設定されています。[ ブラウズ ] を選択して、リストからターゲット MSK クラスター を選択します。 ソースクラスターで行ったことと同様に、 サブネット と セキュリティグループ はデフォルト値のままにしておきます。このネットワーク設定を使用して、ターゲットクラスターとの通信に必要な ENI を配置します。 ターゲットクラスターのアクセス制御方法 も IAM ロールベース認証 に設定されています。 レプリケータ設定セクション では、デフォルトの トピックレプリケーション 構成を使用して、すべてのトピックがレプリケートされるようにします。オプションで、複製するトピックまたは複製から除外するトピックの名前を示す正規表現のカンマ区切りリストを指定できます。 追加設定 では、トピック設定、 アクセスコントロールリスト (ACL) のコピー、および新しいトピックの検出とコピーを選択できます。 コンシューマー・グループ・レプリケーション では、コンシューマーグループのオフセットをレプリケートするかどうかを指定できます。これにより、スイッチオーバー後、コンシューマーアプリケーションは、プライマリクラスター内で処理を中断した場所の近くで処理を再開することができます。複製する、または複製から除外するコンシューマーグループの名前を示す正規表現のカンマ区切りリストを指定できます。また、新しいコンシューマーグループを検出してコピーすることもできます。すべてのコンシューマーグループを複製するデフォルト設定を使用しています。 [ 圧縮 ] では、複製されるデータに使用できる圧縮タイプのリストから [ なし ] を選択します。 Amazon MSK コンソールは、レプリケータが機能するために必要な権限を持つサービス実行ロールを自動的に作成できます。この役割は、MSK サービスがソースおよびターゲットクラスターに接続し、ソースクラスターから読み取り、ターゲットクラスターに書き込むために使用されます。ただし、自分でロールを作成して提供することもできます。[ アクセス権 ] では、「 IAM ロールを作成または更新 」を選択します。 最後に、レプリケータにタグを追加します。タグを使用して、リソースを検索してフィルタリングしたり、コストを追跡したりできます。[ レプリケータタグ ] セクションでは、キーとして [ 環境 ]、値として [ AWS ニュースブログ ] と入力します。[ 作成 ] を選択します。 数分後には、レプリケータが実行されています。使ってみましょう! AWS リージョン間での MSK レプリケータのテスト ソースクラスターとターゲットクラスターに接続するために、2 つのリージョンに既に 2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをセットアップしました。 MSK ドキュメントの指示に従って Apache Kafka クライアントツールをインストールしました。IAM 認証を使用しているため、2 つのインスタンスには、クラスターの接続、送受信を可能にする IAM ロールがアタッチされています。ネットワークを簡素化するために、EC2 インスタンスと MSK クラスターには デフォルトのセキュリティグループ を使用しました。 まず、ソースクラスターに新しいトピックを作成し、いくつかのメッセージを送信します。 Amazon EC2 Instance Connect を使用して、ソースリージョンの EC2 インスタンスにログインします。ディレクトリを Kafka クライアント実行ファイルがインストールされているパスに変更します (パスは使用するバージョンによって異なります)。 cd /home/ec2-user/kafka_2.12-2.8.1/bin ソースクラスターに接続するには、そのブートストラップサーバーを知る必要があります。ソースリージョンの MSK コンソールを使用して、ナビゲーションページから [ クラスター ] を選択し、リストからソースクラスターを選択します。[ クラスターの概要 ] セクションで、[ クライアント情報の表示 ] を選択します。そこで、 ブートストラップサーバー のリストをコピーします。EC2 インスタンスはクラスターと同じ VPC にあるため、 プライベートエンドポイント (シングル VPC) 列のリストをコピーします。 EC2 インスタンスに戻り、ブートストラップサーバーのリストを SOURCE_BOOTSTRAP_SERVERS 環境変数に入れました。 export SOURCE_BOOTSTRAP_SERVERS=b-2.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-3.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-1.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098 次に、ソースクラスターにトピックを作成します。 ./kafka-topics.sh --bootstrap-server $SOURCE_BOOTSTRAP_SERVERS --command-config client.properties --create --topic my-topic --partitions 6 新しいトピックを使用して、ソースクラスターにいくつかのメッセージを送信します。 ./kafka-console-producer.sh --broker-list $SOURCE_BOOTSTRAP_SERVERS --producer.config client.properties --topic my-topic >アメリカからこんにちは >これらは私のメッセージである ターゲットクラスターで何が起こるか見てみましょう。ターゲットリージョンの EC2 インスタンスに接続します。他のインスタンスで行ったのと同様に、ターゲットクラスターのブートストラップサーバーのリストを取得し、 TARGET_BOOTSTRAP_SERVERS 環境変数に入力します。 ターゲットクラスターでは、ソースクラスターエイリアスがレプリケートされたトピック名のプレフィックスとして追加されます。ソースクラスターエイリアスを見つけるには、MSK コンソールのナビゲーションペインで [ レプリケータ ] を選択します。そこで、先ほど作成したレプリケータを選択します。[ プロパティ ] タブの [ ソースクラスター ] セクションで クラスターエイリアス を検索します。 ターゲットクラスター内のトピックのリスト (出力リストの最後のもの) を見て、複製されたトピックの名前を確認します。 ./kafka-topics.sh --list --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --command-config client.properties . . . us-cluster-c78ec6d63588.my-topic ターゲットクラスターで複製されたトピックの名前がわかったので、最初は送信元クラスターに送信されたメッセージを受信するためにコンシューマーを起動します。 ./kafka-console-consumer.sh --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --consumer.config client.properties --topic us-cluster-c78ec6d63588.my-topic --from-beginning アメリカからこんにちは これらは私のメッセージである プレフィックスを自動的に処理し、ソースクラスターとターゲットクラスターで同じ構成を持つために、トピックサブスクリプションでワイルドカード (例えば、 .*my-topic ) を使用できることに注意してください。 予想どおり、ソースクラスターに送信したすべてのメッセージは、ターゲットクラスターに接続しているコンシューマーによって複製および受信されました。 [ 監視 ] タブを使用して、MSK レプリケータのレイテンシー、スループット、エラー、およびラグのメトリックを監視できます。これは Amazon CloudWatch を通じて機能するため、独自の アラーム を簡単に作成し、これらのメトリックスを ダッシュボード に含めることができます。 構成をアクティブアクティブなセットアップに更新するために、同様の手順でもう一方のリージョンにレプリケータを作成し、もう一方の方向のクラスター間でストリーミングデータをレプリケートします。フェイルオーバーとフェイルバックの管理方法の詳細については、 MSK レプリケータのドキュメント を参照してください。 利用可能なリージョンと料金 MSK レプリケータ は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、欧州 (フランクフルト)、欧州 (アイルランド) の各 AWS リージョンでご利用いただけます。 MSK レプリケータでは、複製されたデータの GB 単位と、各レプリケータの時間単位の料金を支払います。また、ソースとターゲットの MSK クラスターに対する Amazon MSK の通常料金と、リージョンをまたぐデータ転送に対する標準的な AWS 料金を支払います。詳しくは、 MSK の料金表 をご覧ください。 MSK レプリケータを使用すれば、クロスリージョンや同一リージョンのレプリケーションを迅速に実装して、アーキテクチャの耐障害性を向上させ、パートナーやエンドユーザーの近くにデータを保存できます。また、この新機能を使用して、分析を実行しやすい単一の集中型クラスターにストリーミングデータを複製することで、より優れた洞察を得ることもできます。 Amazon MSK レプリケータを使用してデータストリームアーキテクチャを簡素化します。 — Danilo 原文は こちら です。

イントロダクション ヘルスケア領域は、生成系AIの活用が最も期待される領域の一つです。今年5月に報告されたボストンコンサルティンググループ（ BCG, 2023 ）の調査では、ヘルスケア領域における生成系AI市場は2027年までに年平均成長率（CAGR）85％で拡大する見通しと報告されています。 この領域の中でも特に、製薬企業の生成系AIに対する関心度は非常に高く、PwCコンサルティングが日本で実施した「 生成系AIに関する実態調査2023 」では、製薬企業の医療情報担当者（MR）を含む医療系専門職の58％が将来的に生成系AIに業務代替される可能性があると回答しており、今後のビジネスモデルや働き方改革に大きな影響をもたらすことを示唆しています。 生成系AIは、そのベースに基盤モデルというAIモデルを活用しています。基盤モデルは、テキスト、メディア（ビデオ、画像、音声）、プログラミングコードなど膨大、かつ、多様なラベルなしの非構造データをもとに訓練された大規模AIモデルです。 生成系AIの特徴は、この基盤モデルを利用し、様々なAIアプリケーションを開発することができることです。生成系AIの一つであるChatGPTは、膨大なテキストデータを学習したLLMであり基盤モデルの応用の一つです。このようなLLMを利用した生成系AIは、分類、編集、要約、質問への回答、新しいコンテンツの下書きなどの作業を行うことができるため、特にビジネス利用での期待が高いと考えられています。この寄稿では3回に分けて、製薬企業でLLMの効果が大きく期待できる業務部門を四つに分け、情報の検索・抽出、チャットボット、SOP（Standard Operating Procedure）ほか各種文書などドラフト作成、社内ガイダンスとの検証といった様々なユースケースについて整理し、AWSが提供する生成系AIサービスと共に解説していきます。 ユースケース＃1：臨床開発 膨大な申請資料の作成、検証、データクリーニングを効率化し、文書管理プロセスをモダナイズする 研究開発にかかる長大な期間のうち半分近くは、実際に医薬品を人に投与し、その安全性や効果を検証していく臨床試験のプロセスに割かれています。臨床開発業務は、医薬品医療機器等法に基づき厳密な規制やガイドラインに準じて行われ、常に詳細な情報と正確性が求められています。そのため、試験実施期間中に臨床データについて医師から提供される症例報告書（CRF）は、データの信頼性を担保するため、記載されたデータに誤りや不整合がないかを確かめるデータクリーニングという作業が実施されています。 通常、この作業には1カ月程度の時間が必要とすることが多いのですが、データクリーニング作業にAI・機械学習（ML）を活用することで、作業期間が22時間に短縮されたという事例が報告されています（ Pfizer, 2020 ）臨床試験が終了すると今度は試験の目的、方法、成績等をまとめた治験総括報告書（CSR）など当局申請に用いる大量の文書作成が必要となります。メディカルライティングという業務で文書作成には大変な費用と労力がかかります。 そこで、この作業に生成系AIを活用し、ドラフト初期の段階で文書作成を一定程度、自動生成に任せることで、大幅な作業時間短縮を図る検証が実施されています。海外では既に複数の企業からCSRの作成を生成系AIで支援するサービスが提供されており、メディカルライターの業務時間を60％以上短縮できるという内容も報告されています（ Narrative ） 臨床開発業務のもう一つの特徴は、各種関連法規制において、業務手順などの過程を示した文書の整備が義務付けられていることです。臨床開発部門では、ポリシー、マニュアル、SOP、テンプレートといった文書があるべき文書階層構造（ヒエラルキー）に基づき作成され、管理されています。しかし、近年の製薬業界ではグローバルの規制内容統一に向けた法規改正、パイプライン確保のためのM＆A（合併・買収）、自社製造拠点の統廃合や売却、製造工程が複雑なバイオ医薬品の増加など様々な要因から、SOPの新規作成、更新の作業が増えています。さらに、文書作成の前段階となるヒエラルキー内で影響を受ける文書の分析、評価についても多くの負担が発生していることが想像できます。しかし、このような文書業務の多くは、担当者自身のライティング、幾重もの部門内レビュー、チェックを経て完了されています。 これらのアナログな文書作成プロセスに対して生成系AIを利用することで、新規に作成した文書のロジックエラーを自動的に判別し、不整合箇所を解説ガイダンスと共に提示するソリューションを開発することも可能になります。生成系AIを利用した文書アプリケーションを開発することで、社内ガイダンス、文書ヒエラルキーに適合した文書を素早く作成し、大きく業務プロセスを改善できる可能性があります。 ユースケース＃2：ファーマコビジランス AIアプリケーションがSNS上の有害事象を検知する 製薬企業は、自社薬剤の投与結果（特に安全性）に関する情報を日々収集、分析、評価し、当局に速やかに報告することが義務付けられています。加えて、新型コロナウイルス感染症の拡大以降、患者や医療関係者を含む一般消費者のSNSが利用拡大したことで、医薬品医療機器総合機構（PMDA）は安全対策を充実するため情報の入手経路の多様化の推進を検討しており、製薬企業もSNS、インターネット情報を医薬品の品質不良、有害事象のモニタリング対象として積極的に考えるようになっています。（ PMDA, 2022 ）このような状況で、製薬企業の報告件数、1件当たりの作業負荷は急激に増加しており、業務を担当するファーマコビジランス部門は、さらなる業務の効率化、コスト管理が求められています。 この課題に対して、AWSを活用する顧客の1社であるノバルティスファーマでは、自然言語処理（NLP：Natural Language Processing）を使用したプログラムを開発することで有害事象（AE）の検出能力を上げることに取り組んでいます。AI・MLを利用した検知プログラムによってSNS内の潜在的なAEの記載をモニタリングし、AEと疑わしい文章が自動的に検知された場合には、さらに感情分析を用いて内容を評価しています。該当したメッセージ部分にはフラグを付けて分析の結果を表示し、社内での効率的なレビューを可能にしています。 この検知プログラムを用いることで、現在では約1万5000件／週のメッセージを処理することができており、これまで人の手によって確認していたそれよりもはるかに多くのデータを収集し、製薬企業が果たすべきAEモニタリング全体の質を高めています。（ AWS, 2021 ） 次号、Part.2では「マーケティング、メディカルアフェアーズ部門」のユースケースについて考察します。 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で20年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブとBBQ。

AWS re:Invent 2023 の開催まで残すところ 41 日となった今、私は AWS News Blog チームと連携して、皆さんに楽しく読んでいただける新しい最高の記事をたくさん作成することに集中すべく、全力投入しています。 今朝はひと休みして、先週の最もエキサイティングなリリースや、その他のニュースを共有したいと思います。では始めましょう! 10月9日週のリリース 以下は、私が関心を持ったリリースの一部です。 Amazon EBS – 新しい CloudWatch メトリクスである Attached EBS Status Check では、特定の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされたすべての Amazon Elastic Block Store (Amazon EBS) ボリュームのステータスを監視して、それらのボリュームが到達可能であり、I/O 操作を完了できることを確認することができます。 AWS Systems Manager – 組織内のすべての EC2 インスタンスに対して、 AWS Systems Manager をデフォルトで有効化 できるようになりました。これにより、すべての新規および既存インスタンスに Systems Manager のコア機能が存在することを確認できるようになります。 Amazon EC2 – 未使用または古くなった AMI を無効化状態に設定 できるようになりました。これは、AMI が以前共有されていた場合にその AMI をプライベートにし、デフォルトで DescribeImages の対象外として、そこから新しいインスタンスが起動されないようにします。 Amazon Textract – ビジネス固有のドキュメントの抽出精度を向上させるために、 カスタムクエリ を使用して Textract のクエリ機能を適合させることができるようになりました。サンプルドキュメントをアップロードし、データにラベルを付け、アダプターを生成してから、それを AnalyzeDocument 関数の呼び出しで使用します。 Amazon OpenSearch Service – クエリと結果の処理を容易にする 検索パイプラインを作成 できるようになりました。各 検索パイプライン には、クエリリライター、自然言語プロセッサ、結果リランカー、およびフィルターといった複数の処理ステップを含めることができ、いくつかの 標準プロセッサ も含まれています。 Amazon Linux 2 – Amazon Linux 2 の最新四半期リリース (AL2023.2) には、 Ansible のコア機能セットと、キュレーションされた一連のコミュニティコレクションが含まれています。また、 Amazon Corretto 21 と、 その他多くの新機能 も含まれています。 Amazon Rekognition – カスタムアダプタを訓練 して Amazon Rekognition がフラグする偽陽性と偽陰性の数を減らすことが可能になり、特定のユースケースに対するパフォーマンスを向上させるために深層学習モデルをカスタマイズすることができるようになりました。 Amazon RDS – Amazon Relational Database Service (RDS) が、M6in、M6idn、R6in、および R6idn の各データベースインスタンスで PostgreSQL、MySQL、および MariaDB データベースを サポートするようになりました 。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 M6in および M6idn インスタンス : アジアパシフィック (シドニー) および欧州 (ストックホルム)。 C7gd、M7gd、および R7gd インスタンス : アジアパシフィック (シンガポール、東京)。 C7gd インスタンス : アジアパシフィック (シドニー)。 AWS マネジメントコンソールの統一設定 : AWS GovCloud (米国) リージョン。 AWS Direct Connect : 韓国、ソウル。 AWS Global Accelerator : ベトナム、ハノイ (2 番目のロケーション)。 Amazon FSx for NetApp ONTAP : アジアパシフィック (大阪)。 AWS Organizations サービスコントロールポリシー : AWS 中国リージョン。 AWS Verified Access : アジアパシフィック (シンガポール、東京)。 AWS マネジメントコンソールへのプライベートアクセス : イスラエル (テルアビブ)。 Amazon RDS Custom for Oracle : アジアパシフィック (ジャカルタ)。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログでは、Seth Eliot が AWS re:Invent で見逃したくない 12 のレジリエンスセッション をリストアップし、Brooke Jamieson が 生成系 AI をゼロから学ぶ方法 を説明して、Daniel Wirjo が Amazon Bedrock で生成系 AI アプリケーションを構築するためのパターン をいくつか紹介しました。 AWS インサイトブログでは、同僚のニュースブロガーである Irshad Buchh が、 20 億の Terraform AWS Provider ダウンロード数がインフラストラクチャ管理のための IaC の価値を証明する 理由を説明しました。 AWS IoT ブログは、 マルチアカウント戦略を使用して AWS でスケーラブルなマルチテナント IoT SaaS プラットフォームを構築する方法 を説明しました。 Amazon SES ブログは、 Amazon Pinpoint を使用して、リアルタイムのカスタマーデータでマーケティングキャンペーンを自動化する 方法を紹介しました。 AWS ビッグデータブログは、 AWS Step functions を使用して Amazon EMR Serverless ジョブをオーケストレーションする 方法を紹介しました。 AWS コンピューティングブログでは、 ワイルドカードパターンマッチングを使用した Amazon EventBridge でのイベントのフィルタリング について説明しました。 AWS ストレージブログでは、 Amazon EBS Snapshots Archive を使用した、コンプライアンスのための Amazon EC2 AMI スナップショットの保持 について説明しました。 AWS アーキテクチャブログでは、インターネット旅行サービスである ITS が、飛行機旅行検索エンジンを改善するためにマイクロサービスアーキテクチャを取り入れている 方法について説明しました。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Day – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。 イタリア (10 月 18 日)、 UAE  (10 月 21 日)、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)。 AWS Innovate: Every Application Edition  – 無料のオンラインカンファレンスに参加して、セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 19 日の AWS Innovate Online アメリカ地区 と EMEA 、および 10 月 26 日の AWS Innovate Online アジアパシフィックと日本 に登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください 。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent のハイライト をチェックしてください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 今日はこれでおしまいです。10月23日週の Weekly Roundup もお楽しみに! – Jeff ; この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS は10月15日、 汎用 Amazon EC2 M7i インスタンス と コンピューティング最適化 Amazon EC2 C7i インスタンス の 2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをラインアップに導入しました。 今日は、メモリ最適化 Amazon EC2 R7i インスタンスを追加するために x86 ベースの第 7 世代製品が拡大されることをお知らせしたいと思います。これらのインスタンスには、AWS 限定のカスタム第 4 世代 Intel Xeon スケーラブルプロセッサ (Sapphire Rapids) が搭載されており、クラウド内にある同等の第 4 世代 Intel プロセッサの中でも最も優れたコンピューティングパフォーマンスを提供します。R7i インスタンスは、2 つのベアメタルサイズ (近日提供予定) を含めた 11 サイズで利用でき、Amazon EC2 R6i インスタンスよりも 15% 高い価格パフォーマンスを提供します。 Amazon EC2 R7i インスタンスは SAP 認定を受けており、ハイパフォーマンスデータベース (SQL および NoSQL データベース)、分散型ウェブスケールインメモリキャッシュ (Memcached および Redis)、インメモリデータベース (SAP HANA)、リアルタイムのビッグデータ分析 (Apache Hadoop および Spark クラスター)、その他エンタープライズアプリケーションなどのメモリ集約型ワークロードに最適です。Amazon EC2 R7i は、仮想インスタンスとベアメタルインスタンスの両方を含めた、最大 192 個の vCPU と 1,536 GiB のメモリを搭載するより大規模なインスタンスサイズ (48xlarge) を提供することで、ワークロードの統合とアプリケーションのスケールアップを可能にします。 各 R7i インスタンスには最大 128 個の EBS ボリュームをアタッチできます。これに対し、R6i インスタンスにアタッチできるボリュームの最大数は 28 個です。 以下は、R7i インスタンスの仕様です。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7i.large 2 16 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.xlarge 4 32 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.2xlarge 8 64 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.4xlarge 16 128 GiB 最大 12.5 Gbps 最大 10 Gbps r7i.8xlarge 32 256 GiB 12.5 Gbps 10 Gbps r7i.12xlarge 48 384 GiB 18.75 Gbps 15 Gbps r7i.16xlarge 64 512 GiB 25 Gbps 20 Gbps r7i.24xlarge 96 768 GiB 37.5 Gbps 30 Gbps r7i.48xlarge 192 1,536 GiB 50 Gbps 40 Gbps AWS では、2 つのサイズのベアメタル R7i インスタンスを近日リリースする準備も進めています。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7i.metal-24xl 96 768 GiB 最大 37.5 Gbps 最大 30 Gbps r7i.metal-48xl 192 1,536 GiB 最大 50.0 Gbps 最大 40 Gbps 内蔵アクセラレータ Sapphire Rapids プロセッサには 4 つの内蔵アクセラレータが搭載されており、それぞれが特定のワークロードのためのハードウェアアクセラレーションを提供します。 アドバンストマトリックスエクステンション (AMX) – AMX エクステンションは、マトリックス演算を伴う機械学習やその他のコンピューティング集約型ワークロードを加速化するように設計されています。これは、マトリックス計算のためにカスタマイズされた特殊なハードウェア命令とレジスタを提供することで、マトリックス演算の効率性を向上させます。積と畳み込みなどのマトリックス演算は、さまざまな計算タスク、特に機械学習アルゴリズムにおける基本的な構成要素です。 インテルデータストリーミングアクセラレータ (DSA) – DSA は、さまざまなアプリケーションのデータ処理および分析機能を強化し、デベロッパーがデータ主導型ワークロードの可能性を最大限に活用できるようにします。DSA を使用することで、データ集約型タスクに対して並外れたパフォーマンスを提供する、最適化されたハードウェアアクセラレーションを利用できるようになります。 インテル In-Memory Analytics Accelerator (IAA) – このアクセラレータは、データベースと分析ワークロードをより高速に実行し、電力効率を向上させる可能性を秘めています。非常に高いスループットでのインメモリ圧縮、解凍、暗号化と、一連の分析プリミティブは、インメモリデータベース、オープンソースデータベース、および RocksDB や ClickHouse などのデータストアをサポートします。 インテル QuickAssist テクノロジー (QAT) – このアクセラレータは、暗号化、復号、圧縮をオフロードすることで、プロセッサコアを解放し、電力消費量を削減します。また、単一のデータフローでの圧縮と暗号化のマージもサポートします。詳細については、まず「 Intel QuickAssist Technology (Intel QAT) Overview 」をご覧ください。 アドバンストマトリックスエクステンションは、すべての R7i インスタンスサイズでご利用いただけます。インテル QAT、インテル IAA、およびインテル DSA アクセラレータは、r7i.metal-24xl および r7i.metal-48xl インスタンスで利用可能になる予定です。 今すぐご利用いただけます 新しいインスタンスは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (スペイン)、欧州 (ストックホルム)、および欧州 (アイルランド) の各 AWS リージョンでご利用いただけます。 購入オプション R7i インスタンスは、オンデマンドインスタンス、リザーブドインスタンス、Savings Plan、スポットインスタンスの形式で提供されています。R7i インスタンスは、専有ホストおよび専有インスタンスの形式での利用も可能です。 – Irshad 原文は こちら です。

Amazon Pinpoint でマルチテナンシーを実現するアプローチ ビジネスは常に進化しており、複数の製品ライン、顧客セグメント、あるいは地理的なロケーションを管理することも少なくありません。さらに、独立系ソフトウェアベンダー (ISV) である企業間取引 (B2B) 企業の多くは、顧客のマーケティングオートメーション環境を管理する必要があります。このような複雑性から、効率的に適応・拡張できる強固な顧客エンゲージメント戦略が必要になります。しかし、テナントごとにバラバラのシステムを管理は手間なだけでなく、リソースを大量に消費し、運用コストの増加や潜在的なデータのサイロ化につながります。Amazon Pinpoint のマルチテナント設定は、これらの課題に取り組み、企業が統一されたアーキテクチャの下で顧客エンゲージメント活動を効率的に実現します。 実現のポイントは、マルチテナントを採用するかどうかだけではなく、お客様固有のビジネス要件に合わせてどのように実装するかです。 Amazon Pinpoint では、これを実現するために複数のアプローチを用意しています。 このブログでは次の 3 つについて説明します。 Single Account / Single Pinpoint Project (SA/SP) : 1 つのアカウントで、1 つのPinpoint Project を用意する方法になり、シンプルに実現できます。ただし慎重な権限管理が必要です。 Single Account / Multiple Projects (SA/MP) : 1 つのアカウントで複数の Pinpoint Project を用意する方法になり、きめ細かな管理が可能です。ただしクォータによる制限が存在します。 Multiple Accounts / Multiple Projects (MA/MP) : マルチアカウントで複数の Pinpoint Project を用意する方法になり、拡張性が非常に高くなります。ただし包括的な監視が必要になります。 それぞれの長所、短所、最適なユースケースを掘り下げ、配信チャネルの要件に応じて異なるマルチテナンシー構成を選択する方法についても掘り下げることで、アーキテクチャの判断ができます。 このブログを通して、検討の複雑さを解消し、ビジネス目標に合わせて Amazon Pinpoint のアーキテクチャ設計に役立てることができます。 Single Account / Single Pinpoint Project (SA/SP) 概要 Single Pinpoint Project のセットアップでは、すべてのカスタマーのアクテビティが 1 つのプロジェクト内に存在します。この場合のマルチテナントの実装方法は、顧客の エンドポイント属性 が活用できます。これを活かすことで、Amazon Pinpoint を初めて使用する人でも簡単に管理ができます。この場合の設定例を以下に示します。 1つの Pinpoint Project を用意し、複数のテナントの情報を管理する場合、エンドポイントの カスタムユーザー属性 を利用してテナント情報を管理することができます。また、キャンペーン情報の タグ機能 を利用することで、テナントごとにキャンペーン情報を管理することができます。この設定を行うために必要な要素を以下に示します。 顧客データを保持する S3 バケット Pinpoint にインポートする顧客情報リストを保存する S3 バケットを用意します。Amazon Pinpoint では S3 に配置した CSV ファイルをセグメントとして インポート することができます。Amazon Pinpoint でテナントごとの設定を行うため、テナント情報を カスタムユーザー属性 として CSV ファイルに記載します。 1 つの Amazon Pinpoint プロジェクト Amazon Pinpoint Project を 1 つ 作成 します。 配信するチャネルごとの 設定 をします。 テナント情報には タグ機能 でキャンペーン情報を割り当てることができます。 Amazon Kinesis Amazon Pinpoint の イベントストリームの設定 を利用することで、Amazon Kinesis 経由で S3 に保存することができます。 イベントデータを分析するための Amazon Athena と S3 バケット Amazon Pinpoint のイベントデータを S3 に保存し、Athena 経由で分析します。 このソリューション を活用できます。 この構成を採用する際の注意点として、顧客のエンドポイント情報が同じ Pinpoint Project 内に存在することが挙げられます。カスタム属性など各テナントを識別できる値を指定し、 AWS Identity and Access Management(IAM) ポリシー で解決することも可能ですが、アクセス権や属性の管理は各自で行う必要があります。 また、 エンドポイントを追加する には、Channel と Address を指定する必要があります。1 つのプロジェクトで、異なるエンドポイントに同じ Channel と Address を指定することはできないため、注意が必要です。以上のことから、エンドポイントの Channel と Address がテナント間で重複しなければ、独自のアクセス許可制御を構築することが可能であるため、このパターンを検討することができます。 他のパターンに比べて必要なコンポーネントが少ないため、構成が容易になります。Pinpoint API を使い、Pinpoint 側の設定をできるだけ簡略化したいというお客様は、この方法を選択できます。しかし、この方法は、後にテナントが増えるにつれて管理が複雑になる可能性があります。例えば、テナントの詳細なレポートを作成したい場合に課題になる場合があります。Amazon Pinpoint プロジェクトで詳細なレポートを作成するには、各キャンペーンやジャーニーに専用のタグを設定する必要があります。 最後に、Amazon Pinpoint Project と AWS アカウントごとの サービスクォータ に注意し、ユースケースに応じて拡張性を持たせるようにしてください。 Single Account / Multiple Projects (SA/MP) 概要 このアーキテクチャでは、Amazon Pinpoint 環境を構築するために単一の AWS アカウントで、顧客またはテナントごとに複数のプロジェクトを作成します。この場合の構成例を図に示します。 この例では、複数の Amazon Pinpoint プロジェクトを作成します。 SA/SP の場合と大きく異なる点は、顧客のエンドポイント情報を完全に分離できることです。顧客データのセグメントをインポートする場合、S3 から対象の Pinpoint Project にインポートするだけで、各テナントを別々の状態で管理することが可能です。これにより、IAM ポリシーによる権限管理が容易になります。 また、Amazon Pinpoint では、該当アカウントで取得した送信用のメールアドレスや SMS 番号、メッセージテンプレートなどを全プロジェクト共通で利用することができ、プロジェクトごとのイベントデータを Amazon Kinesis 経由で集約することができます。このような構成をとることで、基本的な設定情報の管理やオペレーターの操作はそのままに、プロジェクトごとにエンドポイント情報を分離できるメリットが得られます。 この構成を設定するために必要な要素は下記になります。 顧客データを保持する S3 バケット SA/SPと同様に、Pinpoint にインポートする顧客情報のリストを格納する S3 バケットを用意します。インポートする CSV はプロジェクトごとに用意します。 Amazon DynamoDB テーブル Pinpoint のプロジェクト情報を管理するための DynamoDB（またはその他のキーバリューデータベース）テーブルを用意します。テナント情報などをメタデータとして DynamoDB テーブルに格納できます。 AWS Lambda Lambda を使用して Pinpoint のプロジェクトを 作成 します。Amazon Pinpoint では、 Amazon Pinpoint API 、 AWS SDK 、または AWS Command Line Interface (AWS CLI) を使用してプロジェクトを作成および設定することもできます。そのため、Pinpoint のプロジェクトと関連するキャンペーン/ジャーニーの作成を自動化することが可能です。テナント情報も作成時に DynamoDB に登録します。 複数の Amazon Pinpoint プロジェクト 上記の Lambda で作成した Project です。テナントごとに Pinpoint Project が存在することになり、エンドポイント情報が完全に分離されます。また、 IAM 機能 を利用することで、プロジェクトごとにアクセス権を制御することも容易です。 メッセージテンプレート ：テンプレートを作成し、プロジェクト間で共有することができます。 Amazon Pinpoint の イベントストリーム設定 を使うことで、キャンペーン、ジャーニー、アプリ、チャンネルのイベントを Amazon Kinesis にストリーミングできます。複数の Amazon Pinpoint プロジェクトを 1 つの Amazon Kinesis にストリームすることができます。正しくセットアップすると、イベントデータには関連するテナント情報がタグ付けされ、分析ソリューションでストリームを解析できるようになります。 イベントデータを分析するための Amazon Athena と S3 バケット Amazon Pinpoint のイベントデータは Amazon S3 に保存され、Amazon Athena を介して分析します。この場合、分析ソリューションである Amazon Athena を使うことで、テナントに応じたイベントデータのフィルタリングを行うことができます。詳細については、 このソリューション を参照してください。 注意点として、Pinpoint は、AWS アカウントあたり 100 プロジェクトというソフトリミット があります (サポートチケットで増やすことは可能です）。その他の クォータ も、プロジェクトとアカウントレベルで適用されるため、考慮する必要があります。 以上のことから、 SA/MP を使用する場合、アカウントごとのクォータに制限があること、個々のテナントのプロジェクト作成プロセスを自動化するには、より多くの初期設定が必要になることに注意する必要があります。しかし、 SA/SP アーキテクチャーと比較すると、より多様な顧客データをより安全に管理し、効率的に運用できることが期待できます。 Multiple Accounts / Multiple Projects (MA/MP) 概要 MA/MP のアプローチに入る前に、この構成における AWS Organizations の役割を理解することが重要です。AWS Organizations は、複数の AWS アカウントを 1 つの組織に統合し、ガバナンスとコストの一元化を実現できます。この機能は、単一の中央管理 AWS アカウントから複数の AWS アカウントと Amazon Pinpoint プロジェクトを効果的に管理できるため、 MA/MP セットアップで特に有用です。AWS Organizations の詳細については、AWS Organizations の 公式ドキュメント を参照してください。 MA/MP セットアップでは、顧客またはテナントごとにそれぞれの AWS アカウントを利用します。この場合の構成例を以下に示します。 この例では、Management アカウントを作成し、その下に複数の AWS アカウントを用意しています。Management アカウントでは AWS Account ID と Pinpoint Project ID を管理し、プロジェクトを Lambda で作成します。顧客データやイベントストリームデータは Management アカウントで管理し、各プロジェクトの情報を集約しています。この構成の大きなメリットは、個々のテナントのアクションを分離できることで、ノイジーネイバーなどのアンチパターンを防ぐことができます。また、単一の AWS アカウントでは処理できないクォータの制約からも解放されます。さらに、Amazon Pinpoint は CloudFormation のカバレッジに優れており、再現性の高いアーキテクチャを自動的にデプロイすることも可能です。 この設定の設定に必要な要素を以下に示します。 AWS Organizations 複数のアカウントを管理するために Organizations を設定します。複数のアカウントを設定するための ベストプラクティス を参照してください。 Management アカウント 複数のアカウント情報を管理するためのアカウントを作成します。アカウント間でリソースを操作する場合は、IAM ロールと サービスコントロールポリシー（SCP） を使用します。これにより、アカウントをまたいだアクセスが可能になります。必要な要素は前述の SA/MPと同じです。 顧客データを保持する S3 バケット : AWS では、アカウントをまたいで S3 データを利用できます。 クロスアカウント設定 を行い、顧客データを各アカウントにセキュアに紐付けられます。 Dynamo DB テーブル : AWS Account ID、Pinpoint Project ID、それに紐づく管理情報を保持します。 AWS Lambda : Lambda を使用して Pinpoint Project を作成します。 イベントデータを分析するための Athena と S3 バケット : 複数のアカウントや Pinpoint Project のイベント情報を集約して分析します。 テナントごとの AWS Account と Pinpoint Project テナントの分け方に応じて、AWS Account と Pinpoint Project を用意します。 AWS CloudFormation を利用したアカウント作成の自動化も検討できます。 アカウント毎に配信チャネルのメールアドレスや SMS 番号等を設定する必要がある場合があります。(詳細は次のセクションを参照) Amazon Kinesis はアカウント毎に用意されますが、俯瞰してレポーティングしやすいように全て Management アカウントの同じ S3 に保存させます。 注意点としては、アカウントが分かれているため、それぞれを管理する必要が出てくることです。例えば、新規作成したAWS アカウントはサンドボックス状態になり、サポートチケットによる本番利用申請がアカウントごとに必要になります。また、レピュテーションはすべて1つのAWS アカウントで行われるため、アカウントごとにレピュテーションを監視する必要もあります。 Amazon Pinpoint のチャネルごとのアプローチ : 提供サービスとアーキテクチャの整合性 マルチテナントのための Pinpoint アーキテクチャを選択するだけでなく、どのチャネルでサービスを提供するのが最適かを決定し、その決定がマルチテナンシーアーキテクチャの選択にどのように影響されるかを決定することが極めて重要です。以下に、マルチチャネル、マルチテナント構成に役立つ Amazon Pinpoint の機能と、各チャネルで注意すべき潜在的な課題について列挙します。 E メール E メールは、Amazon SES の 設定セット と E メールサプレッションリスト 機能と統合でき、最も汎用性の高いチャネルの 1 つです。3 つのマルチテナンシーモデルのいずれにも簡単に適応できます。 設定セット : 設定セットを使用すると、異なる IP プールや異なるイベント送信先を使用して、メール送信アクティビティを分離することができます。 設定セットは Amazon Pinpoint と Amazon SES の両方で使用できます。Amazon SES で設定した設定セットのルールは、Amazon Pinpoint を使用して送信するメールメッセージにも適用されます。 SA/SP および SA/MP : メールテンプレートと送信 IP アドレスは、Pinpoint プロジェクト内の各テナントの構成セットを使用してタグ付けする必要があります。 MA/MP : E メールテンプレートと送信 IP アドレスは、アカウントのデフォルトを使用して送信するか、設定セットを使用してきめ細かくタグ付けすることができます。 E メールサプレッションリスト : サプレッションリストはアカウントレベルで自動的に管理されます。または、特定の設定がアカウントレベルのサプレッションリストを 上書き できるかどうかを指定できます。 SA/SP および SA/MP すべてのテナントも同じ アカウントのサプレッションリスト に従います いずれかのテナントがハードバウンスまたは苦情を受けたEメールアドレスに E メールを送信すると、他のすべてのテナントも同じアドレスに E メールを送信できなくなります。 アカウントレベルのサプレッションリストは、 設定セットレベル で上書きできます。 MA/MP テナントの 1 人がハードバウンスされた E メールアドレスや苦情のある E メールアドレスに E メールを送信した場合、そのテナントが所属する AWS アカウントのみがサプレッションリストに従います。つまり他のAWSアカウントのテナントは、そのメールアドレスにメールを送信できます。 ノイジー・ネイバーの脅威 : 一般的に、あるテナントのパフォーマンスが他のテナントのアクティビティによって低下することを指します。このアンチパターンを E メールで検討する場合、1つの悪質なテナントが環境全体のメール送信アクティビティに影響を与えることを防ぐための対処が必要になります。ある顧客がバウンス率や苦情率の制限を超えた場合、その顧客への送信は一時停止されます。これは、違反の自動レビューのためにリージョンレベルで行われます。 SA/SP および SA/MP E メールのバウンス率やクレーム率はリージョンレベルで追跡されるため、1つの悪質なテナントからのバウンスや苦情が多い場合、アカウント全体のメール送信ドメインがブロックされる可能性があります。 このような事態を避けるためには、個々のテナントが高いバウンス、苦情率を示した場合に警告を発するよう、専用の設定セットとアラームを設定するのがベストプラクティスです。 MA/MP 最も隔離性が高く、E メール ID、ドメインが1つのテナント、アカウントによってのみ使用可能であることを保証します。 重要 : AWSのTrust and Safetyチームでは、手動でアカウントレベル、ドメインレベル、または複数のアカウントに跨いで確認することができ、メール送信の一時停止をすることができます。どのアーキテクチャを採用するかにかかわらず、すべてのテナントの送信アクティビティを責任を持って管理することがベストプラクティスとして推奨されます。 メール送信クォータ E メール日次送信クォータと E メール送信レート がアカウントレベルで表示されます。 SA/SP および SA/MP AWS アカウント内の全テナントの 1 日の送信クォータと送信レートの合計を予測し、それに応じてサービス制限を引き上げる必要があります。そのため、サービス制限のしきい値を正しく見積もるには、より多くの計画が必要になります。 MA/MP 各テナントが個別の AWS アカウントを使用するため、個々のテナントのニーズに応じてサービス制限を引き上げることができます。 個々のテナントが事前にメール送信クォータリクエストを通知し、それに応じてAWSアカウントでクォータリクエストが発生するように、ビジネスプロセスを整備することがベストプラクティスになります。 マルチテナント環境でのメール送信に関する詳細は、SES のマルチテナントに関する AWS ブログ を参照してください。 SMS 送信元アイデンティティの取得 : OID（電話番号）は AWS アカウントとリージョンに関連付けられています。 OID はアカウントやリージョンをまたいで利用することができないため、新しい AWS アカウントやリージョンごとに取得プロセスを繰り返す必要があります。 番号のプール : 電話番号や送信者 ID をグループ化する機能です。特に Single Project モデルで、テナントごとに通信をセグメント化するのに便利です。 設定セット : V2 SMS and Voice API のリリースにより、設定セットを使用して、マルチテナント環境の SMS オプトアウトリスト、OID、イベントストリーミング先を管理できるようになりました。 この方法の詳細については、 Amazon Pinpoint で設定セットを使用して SMS を送信する方法についてのブログ を参照してください。 ノイジー・ネイバーの脅威 SA/SP および SA/MP API 呼び出しで OID を指定しない場合、Amazon Pinpoint は (スループットと配信可能性の観点から) 最も適切な OID を使用して SMS を送信しようとすることに注意してください。 E メールと同様に、番号プールと設定セットを活用して、SMS 送信アクティビティを 1 つのアカウントに分離できます。 新しい OID をリクエストするにはコストと時間がかかるため、これによって SMS OID のレピュテーションを守ることができます。 MA/MP 最も分離され、1つのテナント、アカウントでのみ使用可能な番号を確保します。 SMS オプトアウト: メールチャネルのサプレッションリストと同様に、オプトアウトはアカウントと設定セットごとに管理されます。 そのため、 MA/MP 設定では、あるアカウントで配信をオプトアウトした顧客は、他のアカウントからの配信を引き続き受信することできます。 プッシュ通知 Amazon Pinpointは、FCM、APNS、Baidu Cloud Push、ADM などの様々なプッシュサービスと統合しています。 プロジェクトレベルの認証： 認証情報は Pinpoint のプロジェクトレベルで設定されるため、個別の管理が必要です。 異なるアプリケーションを使用する複数のテナントでは、 SA/SP アーキテクチャを使用することはできません。 詳細については、 モバイルプッシュガイド を参照してください。 アプリ内メッセージ Pinpoint のプロジェクトごとの設定：プッシュ通知と同様に、各 Pinpoint プロジェクトに設定できるアプリ内メッセージは 1 つだけです。 アプリ内メッセージを必要とするアプリケーションが複数ある場合は、 SA/SP アーキテクチャを採用できません。 詳細については、 アプリ内チャネルのドキュメント を参照してください。 カスタムチャネル Amazon Pinpoint のカスタムチャネルでは、サードパーティのサービスを含め、API を持つあらゆるサービスを通じてメッセージを送信できます。Amazon Pinpoint からカスタムチャネルを広範囲に使用する場合は、 AWS Lambda のサービス制限 、特に SA/SP または SA/MP アーキテクチャを検討している場合に注意する必要があります。 まとめ このブログでは、Amazon Pinpoint でマルチテナントを実装するための複雑な仕組みを紐解いてきました。今回のディープダイブでは、3つのアーキテクチャパターンを取り上げました。 Single Account/Single Project (SA/SP) : シンプルな管理を提供する初心者に優しいアプローですが、異なるテナント間で送信アクティビティを分離するためには、細心の注意を払って権限の管理が必要です。 Single Account/Multiple Projects (SA/MP) : 顧客データをきめ細かく管理できますが、管理の複雑さは若干増します。注意点として、クォータと潜在的な「ノイジーネイバー」問題になる可能性があります。 Multiple Accounts/Multiple Projects (MA/MP) : 管理の複雑さは増すものの、最も柔軟性と独立性が高い方法になります。 各アプローチには、管理・レポートの容易さ、拡張性、顧客データの管理に関するトレードオフがあります。また、マルチテナントの決定が Amazon Pinpoint のチャネル構成にどのような影響を与えるかについても検討しました。E メールや SMS からプッシュ通知まで、アーキテクチャの選択は、これらの配信チャネルをいかに効率的に管理できるかに直接影響します。これらの情報を活用することで、ビジネス目標に沿った意思決定を行うことができます。 次のステップ Amazon Pinpoint 環境のアーキテクティングと実装をします。このブログ記事で説明したベストプラクティスとアーキテクチャのガイドラインを指針として使用してください。今後、選択するアーキテクチャ構成は、ユーザー数、企業規模、または販売チャネルなど、特定のニーズに合わせて調整する必要があります。初期設定だけでなく、それぞれのサービス制限やクォータを含む長期的な管理面も考慮に入れてください。 関連リンク Amazon SES のマルチテナントに関する詳細: https://aws.amazon.com/blogs/messaging-and-targeting/how-to-manage-email-sending-for-multiple-end-customers-using-amazon-ses/ Amazon Pinpoint API ドキュメント: https://docs.aws.amazon.com/pinpoint/latest/apireference/welcome.html Amazon Pinpoint 開発者ガイド: https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html この記事は、 How to implement multi-tenancy with Amazon Pinpoint を翻訳したものです。翻訳は Solution Architect の 中村 達也 が担当しました。 著者について Tristan (Tri) Nguyen AWS の Amazon Pinpoint および Amazon Simple Email Service スペシャリスト・ソリューションアーキテクト。仕事では、企業システムにおける通信サービスの技術的実装とアーキテクチャ/ソリューション設計を専門とする。趣味はチェス、ロッククライミング、ハイキング、トライアスロン。     中村 達也（Nakamura Tatsuya） AWS でエンタープライズ企業を担当するソリューションアーキテクト。主に商社業界、流通・小売業界を担当し、日本のお客様向けに Amazon Pinpoint の導入支援も行っている。ERP 導入支援や複数の新規 Web サービス立ち上げなど、これまでのキャリアは多岐にわたる。

こんにちは！アマゾンウェブサービスジャパン合同会社  ソリューションアーキテクト の塚本です。 2023 年 10 月 10 日と 11 日の 2 日間にわたり、対面式とオンライン配信のハイブリッドで、SaaS on AWS 2023 セミナーイベント を開催しました。開催報告としてセミナーでの発表内容や、会場で行われた各種コンテンツ、懇親会での様子をご紹介します。 開催当日の様子と概要 開催の概要 SaaS on AWS は、SaaS 事業を行う皆様や今後 SaaS 事業を展開しようと考えているソフトウェア事業会社（ ISV ）の皆様が、 AWS を利用してビジネス成長していくにあたっての情報収集やネットワーキングに利用できる機会となっています。今押さえておくべき SaaS に関係するテクノロジーやビジネス拡大の手法について、ユーザー事例をはじめとする 28 の セッションを通じて網羅的に学ぶことができます。 10 月 10 日に開催された  Day 1 は、ISV/SaaS のビジネス面を中心とした内容で、SaaS 事業のトレンドや事例など多数のセッションがありました。お客様の事例セッションの他、近年盛り上がりを見せる 生成系AI の活用についてのセッションもあり、皆様のビジネスの成長に向けて様々な角度で情報を得ることができる内容でした。 10 月 11 日に開催された  Day 2 は、設計・開発・実装・運用などの技術面を中心とした内容で、AWS で利用できる AI/MLサービス の活用についてや、SaaS における目的別データベースの利用、分析系サービスの活用といった内容をソリューションアーキテクト が紹介しました。また、Day 2 でも多くのお客様セッションがあり実際に利用されている技術について聞くことができました。 Day 1 、Day 2 とも一部オンライン配信となっており、動画と資料を公開予定です。 セミナーアジェンダ 開催概要については こちら もご確認ください。 Day1 の様子 Day 1 では SaaS ビジネスに関する内容について、お客様セッションを中心に 10 のセッションが実施されました。Day 1 の様子を一部抜粋してお伝えします。 セッション 『X-point』のクラウド版へ一本化を決断！ワークフローのリーディングカンパニーが選択した方針とは？ お客様からのセッションの中では、株式会社エイトレッド 青木 健一様より、パッケージ製品として販売されていたX-point をクラウド版での販売に一本化されたご決断の背景について発表いただきました。クラウド版への一本化を進める際には、製品のアーキテクチャなどの技術的な変更だけでなく、既存ユーザーからの理解、販売パートナーからの理解、社内の体制の変更と様々な課題を抱えていました。その中で株式会社エイトレッドではどういった対応をされてきたかを知ることができるセッションでした。 AWS のデータ活用と生成系 AI 成功につながるベストプラクティス AWS からのセッションとして、AI/ML 事業開発マネジャー 浅倉 靖之より「 AWS のデータ活用と生成系 AI 成功につながるベストプラクティス」をお伝えしました。このセッションの中では、生成系 AI を SaaS の中でどう使うのかや、10 月に東京リージョンで一般利用開始となった Amazon Bedrock について用例を解説しました。 Amazon Bedrock の名前の由来など、興味深い小話も楽しめるセッションとなっていました。 Day 2 の様子 Day 2 では SaaS 製品を実装し改善していくための技術について知ることができるセッションが数多く開催されました。会場ではセッションの他、AWS のソリューションアーキテクトに直接相談のできる Ask The Expert や SaaS 構築に役立つ Workshop も実施しました。 Day 2 の様子を一部抜粋してお伝えします。 セッション SaaS 事業立ち上げの為の Day1 からのデータ基盤拡張戦略 お客様からのセッションの中では、マネーフォワードｉ株式会社 村上 勝俊様より、SaaS 事業者がビジネスの分析を行い、データをもとにした正しい戦略を立てるために必要なデータ分析基盤の構築を始める方法をご共有いただきました。4 つのステップに分けて無理なく機能を拡張していく手法を、アーキテクチャのサンプルも交えて解説されており、すぐにでも活用できそうな内容となっています。その中では ゼロETL  を使うことで Amazon Aurora と Amazon Redshift を 複雑な ETL の仕組みを作ることなくつなぐ手法も紹介されていました。 Amazon QuickSight で実現するマルチテナント BI AWS からのセッションとして、ソリューションアーキテクトの 高橋 佑里子 より、Amazon QuickSight をマルチテナント SaaS  製品の中で利用する方法を共有しました。Amazon QuickSight のダッシュボードを SaaS 製品に組み込む際に、閲覧するユーザーが属するテナント以外のデータが見れないような制限をかけるための方法を実際の設定についてのデモも交えながらの解説しました。 Amazon CodeCatalyst で実現する SaaS 開発の加速 AWS からのセッションをもう一つご紹介します。ソリューションアーキテクトの 遠藤 宣嗣 より、SaaS 開発を加速させるために使える統合ツール、Amazon CodeCatalyst を紹介しました。SaaS の開発の中では、市場の変化により早く対応するため、開発もスピード感を持って進めなければいけません。より頻繁にデプロイを行なえるような自動化された環境構築を行い、ビルド履歴や Issue 管理も一つのプラットフォームで行えるのが Amazon CodeCatalyst で、このセッションの中では導入のメリットについてより詳しく触れられています。 SaaS 企業  CTO  の パネルディスカッション テーマ「開発組織のカルチャー」 セッションの中では、SaaS 企業の CTO にお話を伺うパネルディスカッションも開催されました。  SaaS への変革はビジネスモデルの変革であり、組織自体も大きく変更していかなければなりません。そこで、開発組織のカルチャーを変更した方法を株式会社アルファドライブ 赤澤 剛様、株式会社カオナビ 松下 雅和様、パイオニア株式会社 岩田 和宏様、弥生株式会社 佐々木 淳志様をパネラーに迎え、AWS ソリューションアーキテクト 上原 誠 をモデレーターとしてパネラーの皆様のご経験やお考えをお話しいただきました。 Ask The Expert AWS のソリューションアーキテクトとセッションで発表してくださった登壇者の方々が参加者の疑問に回答する部屋も用意されていました。AI/ML 、データベースとアナリティクス、SaaS 全般などのトピックにごとに相談を受け付けており、普段 AWS との技術相談を行っていない方でも、気軽に相談いただける機会となりました。 Workshop SaaS アーキテクチャを体験するワークショップも開催されました。SaaS アーキテクチャの重要な要素であるコントロールプレーンについて学べる SaaS Boost Workshop 、サーバーレスなサービスを使って SaaS アーキテクチャを構築する Serverless SaaS Workshop 、マルチテナントの認証認可について学ぶことのできる SaaS AuthN/Z Workshop ( GitHub )の3種類のワークショップが提供され、多くの方にご参加いただきました。 ネットワーキング Day 1 、Day 2 ともセッションの合間にコーヒーブレイクがありました。この時間は SaaS on AWS に参加する他社との交流や、AWS の技術者、発表者とのコネクションづくりに利用していただくことができました。また、Day 2 の最後に行われた懇親会では AWS に関するクイズを出題するウルトラクイズが開催され、クイズの正解者には書籍の贈呈もありました。 収録動画 / 資料 セッションの動画及び資料はダウンロード可能になり次第公開いたします。 おわりに 本イベントでは、ISV/SaaS 事業会社に所属するビジネスリーダー層と技術者の方向けに、 SaaS に特化したソリューションや事例紹介をお届けしました。お忙しい中ご参加いただいた皆様に感謝申し上げます。今回ご紹介した内容が、みなさまの今後のビジネス成長にお役に立てれば幸いです。

企業は、コスト構造、市場投入のスピード、提供する商品の質を改善するために研究開発（ R&D ）に投資しています。研究開発費は、ヘルスケア、製薬、テクノロジー業界のように、研究活動が製品ロードマップと連動している業界で最も高くなります。これらの業界では、通常、売上の 10% から 15% をイノベーションに充てています。しかし、その他の業界では、売上の 0.5% から 3% しか研究開発に割り当てられず、短期的な技術インフラのニーズや業界のトレンドによって増減する裁量的支出となっています。これらの企業は、プロセスからサプライチェーン、オペレーションに至るまで、ビジネスの一部をデジタル化し始めています。イノベーション能力は企業の成功に不可欠であり、クラウドはそれを実現する最良の手段です。 なぜクラウドがイノベーションにとって重要なのかを理解するために、1982年に Harvard Business Review （ HBR ） に掲載された論文 に話を戻しましょう。この 論文 は、テクノロジーを使って永続的な競争優位を築けるかどうかという議論を始めたものです。著者https://aws-blogs-prod.amazon.com/news/move-over-it-here-comes-innovation-2/?preview=trueは、企業が成功するために技術の進歩だけに頼る必要はない、と結論づけています。なぜなら、テクノロジーへの投資は、しばしば企業戦略や乗り越えなければならないさまざまな課題や障害から切り離されているからです。 その20年後、ドットコムブーム （訳者注:　dot-com bubbleのこと） によって、「競争優位としてのテクノロジー」派にバランスが傾きました。しかし、少数の成功したオンライン企業には概ね当てはまることでも、レガシーシステムや実店舗 (訳者注:　brick and mortar　) を持つビジネスには適用できないことが判明しました。 それからさらに20年が経ち、この議論はすっかり影を潜めました。今では、より速く、より効果的にイノベーションを起こす方法を見つけることについて焦点が当てられています。それはなぜでしょうか？　テクノロジーとイノベーションは、もはや競合する2つの独立した企業イニシアチブではないからです。クラウドコンピューティングは、無限の柔軟性と拡張性を提供する新しい技術です。これにより、企業は、顧客のニーズに焦点を当て、そこから逆算して、望ましい結果を導き出すことができます。そして、既存のクラウドサービスを活用して、特定した問題を解決したり、新しい機会を獲得したりすることができます。ハードウェアとソフトウェアのレイヤーを構築してから、その上に載せるアプリケーションを開発する心配はありません。IT とビジネスが抱えるベンダーとクライアントの関係を排除することで、イノベーションを簡素化することができます。ビジネスチームは開発プロセスへの積極的な参加者となり、彼らの焦点はそれらを実現する技術についてではなく、イノベーションに置かれたままとなります。 元デジタルトランスフォーメーション担当役員で、現在は AWS カナダのイノベーションリードとして、私が関わるほとんどの企業がイノベーションの課題を持っています。成功する企業の共通点は、クラウドを採用し、関連するベストプラクティスを導入していることです。私は、クラウドコンピューティングがイノベーションを可能にする理由を、4つの柱に集約しました。すべての組織のクラウド戦略は、この4つの柱を考慮する必要があります。 1- 資金調達 クラウドは、企業が必要な時に必要なテクノロジーサービスを利用することを可能にします。企業は、テクノロジー・プログラムを実行するためにインフラを購入し、維持する必要がありましたが、今ではより多くのリソースをこれらのプログラムに向けることができます。家を建てるとき、既存の電力網やきれいな水、下水道に頼りますよね。もし、これらのインフラをすべて自分で構築し、費用を負担しなければならないとしたら、家を買うことができないか、あるいはもっと小さいものになってしまうかもしれません。クラウドコンピューティングも同じです。インフラや保護、メンテナンスの費用が不要になれば、研究開発やイノベーションに多くの資金を割くことができるようになります。 2- スピード アマゾンの社長兼 CEO であるアンディ・ジャシーは、”発明には2つのことが必要です。1つは、たくさんの実験を試す能力、2つは、失敗した実験の巻き添えを食って生きていく必要がないことです。” オンデマンドでコンピューティングサービスを利用できるようになったことで、テストが可能になり、はるかに安くなりました。アイデアはすぐにプロトタイプ化され、試験的に使用することができます。この記事の時点では、AWS には 200 以上のフルサービスがあり、新しいサービスもどんどん追加されています。ユーザーは、他の方法では手が出せないような技術を試すことができるようになった。量子コンピューティング、衛星サービス、強力なデータ処理エンジン、ブロックチェーンと IoT サービス、コンタクトセンターシステム、機械学習（ML）プラットフォーム、特殊なデータベースなど、例を挙げればきりがありません。ある中堅企業では、5つの新規構想の同時進行という目標がありました。2つを停止して新しいものに置き換え、1つを大幅に変更し、2つを開発するという前提です。既存のクラウドサービスを活用することで、大規模な投資をせずにアイデアをテストし、失敗したものは評価損を出さずにシャットダウンすることが可能になったのです。 3- アジリティ 長い導入期間や調達スケジュールはもはや邪魔にならず、高価な技術専門家も電気を点けるのに精一杯で、ビジネスの要求に素早く対応することはできません。その代わりに、クラウドサービスはビジネスのゴールと目標を実現します。これにより、「シャドー IT」の必要性がなくなるだけでなく、イニシアチブの成功のために連携する多職種のメンバーで構成されるプロダクトチームの創設が促進されます。国際的な取引所である Deutsche Börse Group は、 AWS を使用して 、新しいクラウドベースのデータ分析プラットフォームである A7 をわずか 4ヶ月で構築し立ち上げました。 4- 顧客志向 クラウドは、顧客に焦点を当てた新しいイノベーションの方法を可能にしています。しかし、インフラをクラウドに移行したからといって、組織が顧客中心主義になることを保証するものではありません。組織の障壁を取り除くことから、顧客から逆算することまで、未開拓の市場の可能性を引き出すために必要な文化的変革を生み出し、または加速させるための新しい手法を開発しました。AWS が開拓したこれらの手法は、今やあらゆる業界のあらゆる企業が利用可能であり、一般に 公開 されています。そのためには、ビジネスのスポンサーシップと現状に挑戦する意志が必要なだけです。 まとめ テクノロジーと研究開発の間で行わなければならなかったトレードオフがなくなり、それとともにイノベーションを遅らせる制限要因もなくなりました。クラウドの恩恵を最も受けるのは、クラウドを活用するために自社の能力（ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、オペレーション）を変革できる企業でしょう。イノベーションの実現は、クラウド移行戦略と変更管理計画から始まります。クラウドコンピューティングは、1982年の HBR の議論をついに陳腐化させました。イノベーションこそが永続的な競争優位をもたらすものであり、テクノロジーがそれを可能にするのです。 クラウドへの移行を開始する方法については こちら をご覧ください。また、社内でイノベーションの境界を押し広げたいとお考えなら、 世界中の AWS のお客様の経験に興味を持たれるかもしれません 。 Francois Chevallier Francois は、カナダのアドバイザリー部門でイノベーションのプラクティスリードを務めています。大企業がクラウド機能を活用し、近代化、イノベーション、業務効率化の道を切り開くのを支援する。エグゼクティブコーチ、AWS クラウドプラクティショナー、講演者としても活躍中。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。