TECH PLAY

AWS

AWS の技術ブログ

3139

生成 AI は企業の業務効率化やイノベーション創出の鍵として注目を集めています。生成 AI は単体で利用することも可能ですが、企業が保有する多様なデータと組み合わせることで生成 AI の真価が発揮されます。このため、企業内の重要文書やデータを適切に管理し、AI 環境と連携させることが重要となっています。 日本において、クラウドストレージサービスとして Box が広く利用されています。 株式会社アイ・ティ・アール の調査によると、Box は国内コンテンツ・コラボレーション市場のベンダー別売上金額シェアで2年連続1位を獲得しています。さらに2023年度の業種別市場シェア予測では、製造、金融、通信、サービス、建設、公共・公益という主要6業種でシェア1位を達成しています。 企業データと生成 AI を組み合わせるにはいくつかアプローチがありますが、代表的な手法として RAG (Retrieval Augmented Generation; 検索拡張生成) があります。実際、筆者がお客様とお話しする中でも、Box 内のドキュメントを RAG で活用したいという相談をいただくことがあります。 AWS のインテリジェントエンタープライズサーチサービスの Amazon Kendra や、生成 AI アシスタントアプリケーションの Amazon Q Business はさまざまなデータソースに接続できるコネクターを用意しており、それぞれ Box コネクターを準備しています。一方、Box 内のドキュメントを RAG のために利用可能な形で AWS に取り込むことに特化したソリューションとして、 アクロクエストテクノロジー株式会社 が開発した DocCollector が注目されています。DocCollector は、Box に保存されているドキュメントを、そのアクセス権限を保持したまま AWS 環境に同期することができます。 本記事では、Box 内のデータを DocCollector を利用して AWS に取り込み、生成 AI アプリケーション開発のためのサービスである Amazon Bedrock を活用した RAG システムを構築する具体的な方法について解説します。なお、本記事の執筆に当たってアクロクエストテクノロジーの鈴木貴典様と古賀匠様のご協力もいただいています。 DocCollector とは 「DocCollector」とは、外部クラウドストレージのドキュメントを AWS に連携させ、生成 AI と組み合わせた RAG 構成をすばやく構築させるためのドキュメント同期ソリューションです。 Amazon Kendra と同期させた場合の構成 Amazon Bedrock Knowledge Basesと同期させた場合の構成 現在 Box に対応しており、RAG の検索エンジンとしての Amazon Kendra や、RAG システム構築のマネージドサービスである Amazon Bedrock Knowledge Bases との連携が可能です。Box とのドキュメント同期を、効率よく実施できるようにするため、以下のような機能を備えています。 同期対象のファイル一覧出力 ファイル全体同期 ファイル差分同期 ユーザー指定での同期 同期対象のフィルタリング 外部共有ファイルの同期有無の指定 ユーザー権限同期 グループ権限同期 これらの機能により、Box に大量のドキュメントが登録されている場合でも、必要なファイルのみに絞って効率的に同期することが可能です。また、アクセス権限を同期させることも可能なため、RAG で検索処理が行われた際に、Box 上のアクセス権限を元に、表示させるドキュメントを制限することも可能です。 加えて、お客様の AWS アカウント内に本ソリューションを構築して動作するため、ドキュメントが外部の環境を経由したり、保持されたりすることがないため、セキュアに運用することができます。 DocCollector はアクロクエストテクノロジーが支援した 大阪市高速電気軌道株式会社 (Osaka Metro) 様の事例 でも活用されています。 DocCollector と Amazon Bedrock を利用した RAG システムの構築 DocCollector を利用して Box のドキュメントを Amazon Kendra に同期させ、さらに、Amazon Bedrock を利用した RAG システムの構築例を説明します。 今回は、単にドキュメントを同期するだけではなく、Box のアクセス権限 (Access Control List; ACL) も同期し、RAG で利用されるドキュメントを、ユーザー毎にアクセス制御できるようにします。RAG でのドキュメントのアクセス制御は、企業内ではニーズが多い内容であり、DocCollector を利用することで、そのようなことも実現可能となります。 前提条件 Boxからドキュメント同期を行うには、以下の内容が必要となります。 Box Enterprise 以上のプラン Box の開発者コンソールにおける Box アプリの作成、および、その JWT 認証ファイル RAG システム構築の流れ 以下のような流れで、DocCollector でドキュメントを同期し、Amazon Kendra と Amazon Bedrock を組み合わせた RAG システムの構築を行います。 Box のファイル準備 Amazon Kendra のインデックス作成/カスタムデータソースの登録 DocCollector の構築 DocCollector での Box ドキュメント同期 Amazon Kendra でのドキュメント同期結果の確認 Amazon Bedrock を利用した RAG 処理の実現 1. Box のファイル準備 最初に、サンプルとして、以下のような構成で Box にドキュメントが登録されているとします。アクセス権限の確認をするために、フォルダによってアクセスできるユーザーを設定しています。 Box 内のファイル構成 Box 内のファイル構成 (DX 推進部門) Box 内のファイル構成 (開発部門) 2. Amazon Kendra のインデックス作成/カスタムデータソースの登録 Amazon Kendra のインデックスを作成し、それに対して、カスタムデータソースを登録します。DocCollector の構築の際に、このカスタムデータソースに DocCollector を紐づけることで、Box 内のドキュメントを Amazon Kendra に同期できるようになります。 Amazon Kendra インデックス作成 Amazon Kendra カスタムデータソース登録 3. DocCollector の構築 まず、DocCollector を自社の AWS アカウントにセットアップします。DocCollector は、アクロクエストテクノロジーから提供されます。DocCollector の AWS Batch の構成は、 AWS Cloud Development Kit (CDK) で自動構築されます。 DocCollector の構築 AWS Batch のジョブとして DocCollector を登録した様子は以下の通りです。 DocCollector の AWS Batch ジョブ登録 ※ Box への接続情報は、AWS Batch のパラメータとして指定します。 4. DocCollector での Box ドキュメント同期 DocCollector を用いて Box 上のドキュメントを AWS に同期させます。 同期処理は、先ほど構築した AWS Batch のジョブを実行するだけです。ジョブが正常に終了したら、ドキュメントの同期が完了しています。同期処理の詳細については、 Amazon CloudWatch Logs から確認できます。 DocCollector の AWS Batch ジョブ実行の結果 5. Amazon Kendraでのドキュメント同期結果の確認 Amazon Kendra のインデックスやデータソースの詳細を見ると、正常に同期が完了し、9個のファイルがすべて同期できたことが確認できます。 Amazon Kendra インデックス (同期後) Amazon Kendra データソース (同期後) また、Amazon Kendra の検索コンソールから、検索を行ってみます。ここでは、それぞれのドキュメントが適切に同期されているかを確認するため、管理者権限のもとで検索します。ユーザーのアクセス権限による影響の差分は次のセクションで確認します。 Amazon Kendra 検索コンソール (開発部門のドキュメント) Amazon Kendra 検索コンソール (DX 推進部門のドキュメント) アクセス権限が指定されている、「開発部門」フォルダ内のドキュメントも、「DX推進部門」フォルダ内のドキュメントも、どちらの内容も検索できていることが確認できました。 定期的に、DocCollector のバッチジョブを実行することで、ドキュメントの内容は最新化されます。 Amazon EventBridge Scheduler などを利用して、定期実行されるようにしておくと良いでしょう。 6. Amazon Bedrock を利用した RAG 処理の実現 Amazon Bedrock と Amazon Kendra を組み合わせた RAG システムの場合、以下のような処理の流れになります。 RAG の処理の流れ AWS が OSS として公開している「 Generative AI Use Cases JP (GenU) 」でも、上記の構成で RAG システムを構築できますが、今回、Box のアクセス権限に基づいたドキュメント検索を確認するため、アクロクエストテクノロジー社が提供している、エンタープライズ向け生成 AI アシスタントである「 AcroChatAI 」を利用して、動作確認を行います。ここでは、以下のような制御が正常に行われているかを確認します。 userA に対しては、「DX 推進部門」のドキュメントだけが検索に利用され、「開発部門」のドキュメントは検索に利用されない。 userB に対しては、「開発部門」のドキュメントだけが検索に利用され、「DX 推進部門」のドキュメントは検索に利用されない。 userC に対しては、「DX 推進部門」のドキュメントも「開発部門」のドキュメントも検索に利用される。 まずは (1) の「userA」での操作を確認します。「DX 推進部門」のドキュメントを元にした情報は問合せできていますが、「開発部門」のドキュメントを元にした情報は問合せ結果が出力されません。 DX 推進部門所属の userA の検索結果 (1) DX 推進部門所属の userA の検索結果 (2) 次に (2) の「userB」での操作を確認します。「開発部門」のドキュメントを元にした情報は問合せできていますが、「DX 推進部門」のドキュメントを元にした情報は問合せ結果が出力されません。 開発部門所属の userB の検索結果 (1) 開発部門所属の userB の検索結果 (2) 最後に (3) の「userC」での操作を確認します。今度は、どちらのドキュメントの内容も問合せできています。 両方のフォルダにアクセスできる userC の検索結果 (1) 両方のフォルダにアクセスできる userC の検索結果 (2) このように、DocCollector を利用すると、Boxのドキュメントを同期させるだけではなく、Amazon Kendra のアクセス制御機能とも連携し、RAG で利用されるドキュメントを、ユーザー毎に制御することが可能になることが確認できました。 今回は、シンプルな Box の構成でしたが、一部のドキュメントに限定して同期したり、ファイル差分で同期したりと、DocCollector には、効率よく Box のドキュメントを同期できる機能が備わっています。 まとめ 本記事では、アクロクエストテクノロジーが提供する DocCollector を利用して、Box のドキュメントとアクセス権限を Amazon Kendra に同期させ、そこから Amazon Bedrock を利用した RAG システムを実現しました。 これにより、企業は、クラウドストレージサービスとして Box を利用しつつ、その内容を、AWS 上で RAG システムとして活用することができるようになります。 また、今回は Amazon Kendra との連携でしたが、DocCollector は、Amazon Bedrock Knowledge Bases との連携にも対応しています。また、生成 AI アシスタントの Amazon Q Business にも今後対応する予定です。DocCollector を活用することで、Box と連携可能な RAG システムを簡単に構築できるようになります。 参考情報 RAG 向けドキュメント同期ソリューション 「DocCollector」 エンタープライズ向け生成 AI アシスタント「AcroChatAI」   著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習スペシャリストソリューションアーキテクトです。AWS の AI/ML サービスのお客様に対する技術的な支援を行いながら市場開拓を推進しています。好きなサービスは Amazon Bedrock と Amazon SageMaker です。週末は子供と屋内遊園地で遊ぶのが習慣になっています。博士 (理学)。 鈴木貴典 (Takanori Suzuki / @takanorig ) は、アクロクエストテクノロジー株式会社のシニアテクニカルアーキテクトです。お客様へのクラウドを活用したシステムのご提案や、開発・構築などのコンサルティングを実施しています。サーバーレス・アーキテクチャ推しなので、Amazon Bedrock はもちろん、AWS Lambda 他、サーバーレス系サービスを多用しています。こう見えて (?)、甘党なんですが、最近は健康を意識して控えめにしています。 古賀匠 (Takumi Koga) は、アクロクエストテクノロジー株式会社のクラウド開発エンジニアです。主に、AI/ML サービスを活用したクラウドシステムの開発・構築を得意としています。特に最近は LLMOps に興味があり、生成 AI をどう活用/運用するかを考えています。趣味はサッカープレミアリーグ観戦で、応援しているチームが勝つと、週明けはテンションが高くなります。
2023 年 12 月 22 日、Amazon CloudWatch Network Monitor の提供を発表しました。これは AWS 上のハイブリッドネットワーク接続の可視化を容易にする CloudWatch の機能です。CloudWatch Network Monitor は現在、AWS Direct Connect と AWS Site-to-Site VPN で構築されたネットワーク用のハイブリッドモニターをサポートしています。Amazon CloudWatch Network Monitor は Amazon CloudWatch のコンソール上で利用することが可能です。 この記事では、CloudWatch Network Monitor (CWNM) を使用してハイブリッドネットワークのパフォーマンスを測定し、MTTR ( 平均復旧時間 ) を短縮する方法について説明します。 ハイブリッド接続とグレー障害 Advanced Multi-AZ Resilience Patterns Whitepaper では、グレー障害を異なるエンティティが異なる視点で障害を検知することと定義しております。グレー障害は、原因特定と解決が難しい場合があります。ネットワークドメインでのグレー障害の例としては、特定のネットワークリンクでの断続的なパケットロスやレイテンシーの変動などがあります。 このような状況が発生すると、あるエンティティ ( ルーティングコントロールプレーン ) では低下による影響は見られないのに対して、別のエンティティ ( お客様 ) ではスループットの低下やレイテンシーの増加のような形で影響が見られます。 Border Gateway Protocol (BGP) は、AWS Direct Connect と AWS Site-to-Site VPN で使用されるダイナミックルーティングプロトコルで、TCP のトランスポートプロトコルで動作しています。TCP は、再送信やスライディングウィンドウなどのメカニズムによって、ある程度のネットワーク低下を許容することができます。さらに、TCP セッションは、お客様のルーターと AWS Direct Connect ルーターとの間で確立されます。そのため、VPC とオンプレミスネットワーク間のどこかでネットワーク障害が発生しても、BGP では必ずしも低下の兆候に気づけないかもしれません。 Direct Connect (DX) または Site-to-Site VPN によるハイブリッド接続を必要とする AWS のお客様は、グレー障害が発生したら直ちに検知し、問題が起きている経路からトラフィックを回避するオプションを用意する必要があります。これまでの経験から、ネットワークに問題が発生すると、ネットワークエンジニアは問題の特定に相当な時間を費やすことがわかっています。パフォーマンス低下がお客様管理のネットワーク部分で発生したのか、それとも AWS 責任範囲内のネットワーク部分で発生したのかを迅速に把握することは、MTTR の短縮に役立ちます。 野村総合研究所は Direct Connect のパートナーです。当社にとって、ネットワークのグレー障害を検出・特定し、その影響を軽減するまでの時間を短縮することは長年の課題でした。 CloudWatch Network Monitor のおかげで、エンドツーエンドのパフォーマンスの低下や停止が発生と同時に検知できるようになりました。CloudWatch アラームでしきい値を設定し、CloudWatch Network Monitor を Lambda や SNS などの他の AWS サービスと統合するのは簡単でした。 上記により、ネットワークイベントが検出された際に事前に定義したアクションを実行することで、これまで以上に多くのネットワーク障害の影響を自動的に軽減できると期待しています。 株式会社野村総合研究所 シニア・アソシエイト 藤原 和樹 氏 Amazon CloudWatch Network Monitor の紹介 Network Monitor を使用する以前は、ハイブリッドアーキテクチャを採用しているお客様は、既製のソリューションを使用するか、独自のツールを開発したアクティブ監視手法を実装することで、ネットワークのグレー障害の問題に対処してきました。 CloudWatch Network Monitor は、フルマネージド型のエージェントレスソリューションで簡単に実現します。 モニター は、Direct Connect または Site-to-Site VPN 経由で到達可能な IPv4 または IPv6 宛先への ICMP または TCP トラフィックをテストするために使用できます。送信元サブネット、宛先 IP、 パケットサイズ、およびプロトコル/ポートの各組み合わせは、 プローブ と呼ばれます。 Amazon VPC で モニター を作成すると、AWS はバックグラウンドで RTT (Round-Trip Time) とパケットロスの測定を実行するために必要なすべてのインフラストラクチャを作成します。 プローブ で設定されたポートとプロトコルでモニタリングトラフィックに応答するように監視ターゲット (プローブの宛先) を設定するだけで済みます。 Direct Connect と併用する場合、 モニター はモニターがデプロイされた VPC から DX 接続を終端する Direct Connect ロケーションまでの、AWS が管理するネットワーク経路の状態を可視化します。これは Network Health Indicator (NHI) と呼ばれ、問題が AWS のネットワークにあるのか、お客様が管理するネットワークにあるのか原因特定のスピードアップに役立ちます。 モニター によって生成されたメトリクスは Amazon CloudWatch に公開され、ダッシュボードとアラームを設定して、通知や軽減アクションを実施することができます。 シナリオ Direct Connect High Resiliency モデルを実装する一般的なお客様のシナリオを以下に説明します。この設計に焦点を当てて、Network Monitor の設定と使用方法を示します。Network Monitor は他のシナリオでも使用することができます。 図 1. Direct Connect High Resiliency 構成を利用のお客様 こちらのお客様では各 Direct Connect ロケーションにルーターを設置しています。各ルーターは、DX 専用接続を介して AWS ルーターに接続されます。 2 つの Transit VIF (T-VIF) が、Direct Connect Gateway (DXGW) に関連付けられた AWS Transit Gateway との間でトラフィックを転送するように設定されています。お客様のルーターは、両方の T-VIF 上で eBGP を介して DXGW とルーティング情報を交換します。これは、AWS の ドキュメント 、ブログ記事、および ハイブリッド接続ホワイトペーパー などのリソースで扱われている一般的なアーキテクチャです。 お客様は、複数のプライベートサブネットにワークロードを所持しており、アプリケーションの可用性を最大化するために、異なるアベイラビリティゾーン (AZ) に分散しています。図を見やすくするために、ここでは 2 つだけ表示することにします。これらのワークロードには、オンプレミス LAN 上のクライアントがアクセスします。 お客様は、等コストマルチパス (ECMP) を使用して、両方の DX 接続間でネットワークフローの負荷分散を行っています。LAN( 172.16.0.0/24 - 2001:DB8::/48 ) には、AWS から両方の T-VIF 経由で到達が可能です。同様に下の図が示すように VPC にも、LAN から両方の T-VIF を経由して到達可能です。 図 2. 両方のトランジット VIF から LAN に到達可能 プライベートサブネット内のワークロードはレイテンシーにセンシティブです。お客様は、どちらかの経路に障害が発生した場合にも対処できるように、両方の経路のネットワークパフォーマンスを可視化したいと考えています。 AWS リージョン内のアベイラビリティーゾーンは独立した障害ドメインとして設計されている ため、異なる AZ の異なるサブネットからの可視性を提供する必要があります。 モニタリング アーキテクチャ ユーザーのペルソナによって、モニタリングの目的は異なる可能性があります。例えば、アプリケーションオーナーは、ネットワークがアプリケーショントラフィックをどのようにルーティングするかに関係なく、エンドツーエンドのレイテンシーとパケットロスがエンドユーザーのエクスペリエンスに影響を与えないことを確認したいと考えるかもしれません。 アプリケーション開発者は、ワークロードと同じサブネットに モニター を設定し、オンプレミスの LAN に対してプローブを送信します。いずれかのワークロードのサブネットからのモニタリングトラフィックは、オンプレミスのモニタリング宛先に到達するために、利用可能なすべての経路を使用します。 図 3. モニタリングアーキテクチャ (アプリケーションオーナー) 一方、ネットワーク・エンジニアは各ネットワーク経路を重視するため、各 プローブ のトラフィックが特定の経路をたどって宛先に到達するようにモニターを構成します。 図 4 に示す 2 つ目のアーキテクチャでは、ネットワークエンジニアが各モニタリングサブネットにプローブを作成しました。各プローブは、緑色または赤色の DX 接続を経由してのみ到達可能な宛先に設定されています。同様に、モニターの宛先は、緑色または赤色の DX 接続を経由してのみ、図の左側にある対応するプローブに到達できます。例としては VRF-Lite をお客様のルーター上で構成することで実現できます。 図 4. モニタリングアーキテクチャ (ネットワークエンジニア) 執筆時点では、同一 モニター 内に IPv4 と IPv6 の両方の宛先に対する プローブ を作成することはできません。IPv6 宛先への プローブ を設定したい場合は、別の IPv6 モニター を作成してください。 次に、2 つ目のアーキテクチャについて説明し、AWS コンソール内での設定方法を示します。CloudWatch Network Monitor は、サービス API、AWS SDK、AWS CloudFormation、CDK を使用して設定することもできます。ここでは IPv4 のみのモニターを作成する方法を示しております。IPv6 のみのモニターを作成したい場合も同じ手順に従ってください。 Amazon CloudWatch Network Monitor のセットアップ 2 つ目のリファレンスアーキテクチャを実装するために、 monitor-us-east-1-ipv4 という名前の モニター を作成します。これを行うには、Network Monitor コンソールを開き、 モニターを作成 を選択します。 図 5. Network Monitor コンソールでのモニター作成 集計期間 は、 Network Monitor のプローブが生成したメトリクスを CloudWatch に送信する間隔を表します。 この値は 30 秒(デフォルト)のままにします。これは Network Monitor によって生成されるメトリクスに依存しており、自動化されたアクションを使用して障害のあるネットワークパスを迅速に回避するためです。 図 6. 新しいモニターの作成 次に、 プローブ をデプロイするソースとして、 monitor-subnet-us-east-1a と monitor-subnet-us-east-1b のサブネットを選択します。最後に、 172.16.100.1 と 172.16.200.1 を宛先として設定します。コンソールを使用して作成された プローブ は、デフォルトで 56 バイトサイズの ICMP エコーパケットを送信します。これを図 7 に示します。 図 7. モニターの送信元サブネットと宛先IPを指定 ステップ順に従うと、すべてのリソースがデプロイされ、 プローブ が先ほど設定した集計間隔ごとに CloudWatch にメトリクスを送信開始するまで、 モニター と プローブ は Pending 状態になります。 Network Monitor ダッシュボード CloudWatch Network Monitor は モニター 毎にダッシュボードを作成します。これは、Network Monitor ダッシュボードで モニター 名をクリックすることでアクセスできます。 左上には、 モニター がデプロイされているリージョンの AWS ネットワークのステータスが表示されます。 この情報は接続が複数のネットワーク ( 例:AWS ネットワーク、Direct Connect Partner バックボーン、オンプレミスデータセンターネットワークなど ) を経由する場合に、モニターされたパケットロスや増加したレイテンシーの原因を調査するのに役立ちます。 右上には、アラーム状態の プローブ 数、平均パケットロス、選択した時間範囲の RTT など プローブ のステータスの概要が表示されます。 図 8 では、AWS Network Health Indicator メトリクスの履歴と、各 プローブ のパケットロスと RTT を示す折れ線グラフが表示されます ( 図 9)。この情報を使用して、AWS Network Health Indicator とモニターされたパケットロス/レイテンシーを相関することで、ネットワークの問題をさらにトラブルシューティングできます。 図 8. モニターのサマリー表示 図 9. Network Monitor メトリクスのサマリー表示 CloudWatch メトリクス AWS Network Monitor は、CloudWatch メトリクスを名前空間内に “AWS/NetworkMonitor” として公開しています。各プローブには 3 つのメトリクスがあります。 HealthIndicator: 測定時に AWS ネットワークが正常であれば 0、低下している場合は 100 です。 PacketLoss: パケットロスをパーセント値で表します。 RTT: ラウンドトリップ時間をマイクロ秒単位で表します。 図 10. NetworkMonitor CloudWatch メトリクス (RTT) Metrics math 複数のメトリクスを数式と組み合わせると便利な場合があります。 例えば、複数の プローブ が物理リンクを共有している場合、集約期間中 ( この場合は 30 秒)にすべての プローブ のパケットロスの平均を取得することができます。取得するには、関連するメトリクスを選択し、「数式を追加」オプションを使用してください。次に、図 11 と図 12 に示すように、適切な関数  ( 平均を表す “AVG” など ) を選択します。 図 11. CloudWatch メトリクスの数式追加 図 12. CloudWatch メトリクスに数式を追加した結果 (RTT) アラームの作成 シナリオに最も適したメトリクスを特定したら、アクションセクションの小さなベルのリンクアイコンをクリックして、必要なアラームと アクション を設定できます。 最もシンプルなタイプのアラームとして、静的なしきい値を使用します。例えば、パケットロスの平均値が 1% を超えた場合に通知するアラームを作成できます。ほとんどのアプリケーションでは、1% のパケットロスは許容範囲内と考えられます。 図 13. パケットロスに関する CloudWatch アラームの設定 事前に妥当なメトリクス値が分からない、または日中に何らかの変動が予想されるため ( ラウンドトリップタイムなど ) 静的なしきい値を設定したくない場合は、 CloudWatch 異常検出 を使用してアラーム設定ができます。 異常検出 は予想される帯域の値を計算し、実際の値がその帯域より大きい場合や低い場合、または帯域外である場合にアラートを発します。プローブが失敗した場合 ( パケットロス = 100%)、RTT は 0 ミリ秒と報告されるため、予想よりも低い値や高い値を検出するように異常検出を設定することは合理的です。 図 14. CloudWatch 異常検出の設定 フェイルオーバーの自動化 Amazon Simple Notification Service (SNS) を使用してアラートを送信する以外に、障害検出時の際に Direct Connect リンクのフェールオーバーを自動化することも可能です。そのためには、 Amazon EventBridge によって呼び出される Lambda 関数を使用します。サンプルの Lambda 関数は AWS Samples GitHub リポジトリ で提供されています。詳細とベストプラクティスについては、ブログ記事「 AWS Direct Connect monitoring and failover with Anomaly Detection 」 を参照してください。 また、実際の障害シナリオが発生した際に期待通りに機能することを確認するため、フェイルオーバーの自動化を定期的にテストすることもベストプラクティスです。 リソースの削除 Network Monitor をテスト後は、想定していない料金の発生を避けるため、すべてのモニターとプローブ、この機能をテストするために作成したその他のリソースを削除して、テスト環境をクリーンアップしてください。 まとめ この投稿では、ハイブリッドネットワークのモニタリングを容易にするフルマネージド型でエージェントレス機能である Amazon CloudWatch Network Monitor を紹介しました。Network Monitor を使用することで、ネットワークの問題をより迅速にトラブルシューティングと修復を行うことができるため、カスタマーエクスペリエンスへの影響を最小限に抑えることができます。 Network Monitor の料金の詳細については、 こちら の CloudWatch 料金表ページをご覧ください。この機能の設定方法と使用方法に関する技術的なガイダンスについては、 AWS Documentation をご覧ください。 本稿は、2023 年 12 月 22 日に Networking & Content Delivery で公開された “ Monitor hybrid connectivity with Amazon CloudWatch Network Monitor ” を翻訳したものです。翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。
本記事は、2024 年 7 ⽉ 3 ⽇に公開された ” Does Your People Strategy Match Your Transformation Objectives? “を翻訳したものです。 なぜ多くの企業のイノベーションプログラムは失敗するのでしょうか。 その答えは、組織の複雑さと同じぐらい複雑です。厳格すぎるガバナンスモデル、縦割りのチーム、厳しい規制環境、官僚的な意思決定などが主な原因として指摘されることがありますが、見過ごされがちな領域が 1 つあります。それは人材戦略です。 人材プロセスは、イノベーションを支援するか、それとも阻害するかのどちらかです。中間地点はありません。 私は最近、同僚の Mark Schwartz が書いた「 Adaptive Ethics for Digital Transformation 」という本を読みました。この思考を刺激する挑戦的な本の内容を要約しようとは思いません ( 特に帽子、食べ物、神話上の怪物の例え話に惹かれる方には )。その代わりに、本の中の1つの引用について考えを述べたいと思います。これは本の主要なテーマではないので、 Mark の著作権を侵害しているわけではありません (ぜひその本を読んでみてください。素晴らしい本です)。 エンロンの崩壊の話の途中で、Mark は次のような言葉を述べています: 「文化は、従業員を成功に導くものを中心に形成される」 Mark は、エンロンの掲げた価値観が、組織内での個人の成功や昇進につながるものとは全く異なっていたことを示しています。価値観自体が問題だったのではなく、現実との乖離が問題だったのです。 私はアマゾンでの 11年間 ( AWSとAmazon.comの両方 ) において、人材と企業文化に焦点を当ててきました。私は企業文化の専門家で、常に「文化が最も重要なもの」という視点で世界を見ています。そして、地球上で最も顧客中心主義の企業になるというミッションを果たすために、意図的に企業文化を進化させてきた組織で働いています。しかし、Mark の言葉は他の組織にも当てはまるのでしょうか ? 私はそう考えており、多くの組織変革が頓挫するのは、組織が掲げる文化的価値観を従業員の育成、業績評価、そして報酬にまで反映させることに失敗した時だと強く思います。 過去 5 年間で、私はほぼすべての業界にわたる世界中の 1,000 人以上の組織リーダーたちと対話を重ねてきました。その中で、ある会話が特に印象に残っています。それは、組織変革を追求する際には 人材戦略も見直す必要性 を示すものでした。 数年前、私はある世界的な大手石油・ガス会社のイノベーション責任者 (仮にザビエルと呼びます) と時間を過ごす機会がありました。エネルギー業界の多くの既存組織と同様に、ザビエルの会社も自社を変革し、よりイノベーティブになる緊急の必要性を感じていました。その従来の持続可能で収益性の高いビジネスモデルでは、枯渇する天然資源と高まるエネルギー需要への対応ができなくなっていたのです。 会話の中で、ザビエルは会社全体で イノベーションを推進するための方法 について話してくれました。それには、経営陣からの高水準なイノベーション目標、各組織へのイノベーション予算、特定の課題に取り組む小規模チーム、ハッカソン、表彰や賞与など、あらゆる手段でした。 彼は言いました。「このプログラムを1年半実施しています。そして、社内にはうまくいっている部署もあります。しかし、私達が期待していたほどには浸透していません。私たちは実験をしているわけではありません。私たちは依然として官僚的で、意思決定が遅いのです。人々は革新的なプロジェクトに参加しようとしません。私の何が間違っているのでしょうか ? 」 ザビエルの計画は、組織のイノベーションを推進するための教科書的なアプローチとほぼ一致していました。正直なところ、彼が何を見落としているのか思い当たりませんでした。1 時間後、私たちは昼食を取りながら、 アマゾンのリーダーシップ原則 とその報酬哲学へ話題を移しました。アマゾンは長年にわたり、各従業員の全体的な報酬の重要な一部として会社の株式を含めてきました。この方法は、私たちのリーダーシップ原則のオーナーシップと一致しています。 リーダーはオーナーです。リーダーは長期的視点で考え、短期的な結果のために、長期的な価値を犠牲にしません。リーダーは自分のチームだけでなく、会社全体のために行動します。リーダーは「それは私の仕事ではありません」とは決して口にしません。 ここで言う「リーダー」とは、肩書や役職に関わらず組織内のすべての従業員を指します。誰もが周囲の人々の行動に影響を与える事ができるので、責任あるリーダーの心構えで仕事に取り組む必要があります。そしてAWSでは、「リーダーはオーナーです」というのは文字通りの意味があります。役割と結果に対する責任を持つことに加えて、各従業員がそれぞれ会社の一部を所有し、組織の長期的な成功から利益を得られます。株式を全従業員に付与することで、個人の動機づけと組織の目標を一致させているのです。 このオーナーシップの考え方は、私がザビエルと会話していたイノベーションの課題とどのように関連しているのでしょうか? 私が報酬哲学の詳細を共有すると、ザビエルは私を遮って言いました。「待ってください、全員に株が支給されているのですか ? 」 「そうです。もちろん、ジョブレベルや仕事のパフォーマンスに基づいて付与される量は異なります。パフォーマンスが良くない人は株を受け取れないこともあります。ただ、それ以外の従業員全員に、毎年の報酬の一部として株が支給されるのです」 「へぇ」と彼は言いました。「うちの経営陣は成果主義を信じています。私たちも株を与えていますが、10人いるチームのうち上位2人しか対象にしていません。それは大きな報酬で、年俸の30%にもなることがあります。」 経営陣が株式報酬を厳しく審査し、それを受け取った人々は通常、その年の完璧な結果を出していました。全ての目標と目的を達成していたのです。そのような環境で、わずかでも失敗のリスクのあるプロジェクトに手を挙げる人がいるでしょうか? 私にも共感できる部分があります。私は大学生の子供が 3 人います。アメリカでは、それは子供たちの教育に多額のお金をかけているということです。私なら、ザビエルの会社のモデルに従って 30% の昇給を得られれば、確実に達成可能な目標を設定し、それらの目標を他の何よりも綿密かつ容赦なく追及するでしょう。すべての人がお金に動機づけられるわけではありませんが、完璧な実行を報酬とする文化は、実験とイノベーションに逆行するものです。経営陣は「素早く失敗せよ!」と言うかもしれませんが、報酬と是正のシステムは逆のことを伝えています。 私がザビエルと話した1年後、彼の会社はAWSのデジタルイノベーションチームと提携し、5 つの重要な実験に取り組み、従来の 3 分の 1 の期間で実行しました。それらの実験のうち 2 つは現在も本番環境で稼働しています。私たちの会話がザビエルの会話の変化どの程度関係していたかは分かりませんが、昨年、同じ組織のリーダーシップの方々とも会話する機会がありました。彼らは会社の報酬アプローチを改訂し、すべての従業員に対して株式を提供するようになっていたのです。 ここでの変革の教訓は「ただ従業員への報酬の与え方を変えればいい」というわけではありません。どんな大規模な組織の変革にも、それによって生じる課題を解決する万能薬はありません。しかし、自分の組織のあらゆる側面、特に人材に関する実践、を見直す意思のあるリーダーは、より持続的な変革を導く可能性が高いのです。 私からいくつかのアイデアを提案しましたが、より良いアイデアがあればお聞かせください。 – Stephen 本記事は、カスタマーソリューションマネージャーの宮本雅勝が翻訳を担当しました。
みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 12月2日からの AWS re:Invent 関連の情報が少しづつ出てきますね。去年同様、色々なセッションがオンライン中継もされる予定ですので、視聴したい方は こちらのレジストレーション をお忘れなく。 時差の関係で、日本から視聴するのは難しいものも多いのですが、録画も公開される予定ですし、最初の キーノート である現地月曜夜のPeter DeSantisキーノートは、日本時間だと火曜のお昼12時半ごろ開始予定なので、ライブで見やすいかと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。今週はいつもに増して新発表が多かったので、各項目の説明はできるだけシンプルにしています。詳細はリンク先のWhat’s new等でご確認ください。 2024年11月11日週の主要なアップデート 11/11(月) Amazon OpenSearch Ingestion adds support for ingesting data from Amazon Kinesis Data Streams – AWS Amazon OpenSearch Ingestion では、Amazon Kinesis Data Streams から直接レコードを取り込むことができるようになりました。これにより、追加の工数が不要で、KinesisからのストリーミングデータをOpenSearch Serviceでインデックスできるようになりました。 Get x-ray vision into AWS CloudFormation deployments with a timeline view – AWS AWS CloudFormation で Deploy timeline view (デプロイタイムラインビュー)が提供されるようになりました。この機能は、CloudFormationのスタックで実行する一連のアクションを視覚化してくれるため、スタックでのリソースプロビジョニングアクションの順序やかかった時間を把握しやすくなります。 11/12(火) Amazon SageMaker Model Registry now supports defining machine learning model lifecycle stages – AWS Amazon SageMaker Model Registry でカスタムの機械学習モデルのライフサイクルステージがサポートされました。この機能により、トレーニングから推論まで、モデルライフサイクルのさまざまな段階でのトラックと管理が容易になります。また、承認待ち、承認済み、却下などの段階承認ステータスをトラックして、モデルが次の段階に進む準備ができているかどうかを確認することもできます。 Amazon Managed Service for Apache Flink now supports Amazon DynamoDB Streams as a source – AWS Amazon DynamoDB 用の新しい Apache Flink コネクタが利用可能になりました。これは AWS が Apache Flink プロジェクトにコントリビューションした 新しいコネクタ であり、Apache Flink のソースとして Amazon DynamoDB ストリームを追加し、変更データを順次 Flink に流すことが容易になります。 Amazon EC2 Capacity Blocks expands to new regions – AWS アジアパシフィック (東京)、米国西部 (オレゴン) の2つのリージョンにおいて、 P5 インスタンスで Amazon EC2 の機械学習用キャパシティブロックが利用可能になりました。キャパシティブロックを使用すると、1 ~ 64 インスタンス (512 GPU) のクラスターサイズで、最大 8 週間前まで GPU 容量を最大 28 日間予約できるため、機械学習ワークロードをより確実に実行できるようインフラを準備することが可能になります。 Amazon EventBridge announces up to 94% improvement in end-to-end latency for Event Buses – AWS Amazon EventBridgeで、2023年1月以降の改善によりイベントバスのエンドツーエンドのレイテンシーが最大 94% 改善されたことを発表しました。2023年1月時点では、2235.23ms (P99)であったレイテンシが、2024年8月には129.33ms (P99)まで短縮しています。これにより、よりミッションクリティカルな領域でも利用が可能になります。 Amazon EBS now supports detailed performance statistics on EBS volume health – AWS Amazon Elastic Block Store (EBS) ボリュームで、詳細なパフォーマンス統計が利用可能になりました。この新機能により、1秒未満の精度で 11 のメトリックスにアクセスし、 EBS ボリュームの入出力 (I/O) 統計をリアルタイムにモニタリングできます。 11/13(水) Amazon OpenSearch Service now supports 4th generation Intel (C7i, M7i, R7i) instances – AWS Amazon OpenSearch Service で、第4世代インテル Xeon スケーラブルプロセッサーベースのコンピューティング最適化インスタンス (C7i)、汎用 (M7i) インスタンス、およびメモリ最適化インスタンス (R7i) を利用可能になりました。これらはC6i、M6i、R6i の各インスタンスよりもそれぞれ最大 15% 価格性能比を実現します。 Introducing resource control policies (RCPs) to centrally restrict access to AWS resources – AWS AWS Organizations で Resource Control Policy (RCP) が利用可能になりました。これは、組織内のAWSリソースへのアクセスを一元的に制御できる機能で、外部IDによる内部リソースへのアクセス防止や、通信のTLS強制といった用途に利用が可能です。現時点では、Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager に適用が可能です。 Amazon DynamoDB introduces warm throughput for tables and indexes – AWS Amazon DynamoDB では、新しく warm throughput (ウォームスループット)値と、DynamoDB テーブルとインデックスを簡単にPre warming (事前ウォーミング)できる機能が追加されました。ウォームスループット値を参照すると、テーブルが処理できる読み取り/書き込みオペレーションの数が可視化されます。今後のイベントにおける性能不足に気付いた場合には、事前ウォーミングにより性能値を増やすことができます。詳細は こちらのブログ をご覧ください。 AWS Glue Data Catalog now supports scheduled generation of column level statistics – AWS AWS Glue Data Catalog で、Apache Iceberg 表と Parquet、JSON、CSV、XML、ORC、ION などのファイル形式のデータにおいて、列レベルの統計のスケジュール生成がサポートされました。これにより、統計の生成を簡略化および自動化できます。統計情報は Amazon Redshift Spectrum および Amazon Athena のコストベースオプティマイザー (CBO) と統合されているため、クエリのパフォーマンスが向上し、コスト削減が期待できます。 11/14(木) AWS Backup now supports Amazon Neptune in three new Regions – AWS AWS Backup による、 Amazon Neptuneのバックアップが利用可能なリージョンが拡張され、新たに大阪、ジャカルタ、ケープタウン)リージョンで利用可能になりました。 Amazon DynamoDB reduces prices for on-demand throughput and global tables – AWS Amazon DynamoDB の料金改定がアナウンスされました。オンデマンドスループットの価格は最大50%、グローバルテーブルの価格は最大67%引き下げます。この料金は11月1日からの利用分に適用されます。詳細は こちらのブログをご覧ください 。 Amazon Keyspaces (for Apache Cassandra) reduces prices by up to 75% – AWS Amazon Keyspaces for Apache Cassandra は、スケーラブルでサーバーレスの Apache Cassandra 互換データベースサービスです。今回オンデマンドモードの料金を単一リージョンで最大56%、マルチリージョンで最大65%引き下げました。また、プロビジョニングモードの料金は、単一リージョンで最大13%、マルチリージョンで最大20%引き下げられました。また、Keyspacesは有効期限(TTL)の削除料金を75%引き下げました。この変更により、以前のようにスパイクがあるワークロードだけでなく、大半のワークロードでオンデマンドモードの利用が推奨されます。 AWS Transit Gateway and AWS Cloud WAN enhance visibility metrics and Path MTU support – AWS AWS Transit Gateway と AWS Cloud WAN enhance において、アベイラビリティーゾーン (AZ) 単位のメトリクスをCloudWatchに送信可能になりました。AZ単位のメトリクスにより、AZ単位で詳細可視化できるようになり、AZ単位の障害を迅速にトラブルシューティングできるようになります。あわせて、パス最大伝送ユニット検出(PMTUD)をサポートするようになりました。 Amazon RDS for PostgreSQL now supports major version 17 – AWS Amazon RDS for PostgreSQL において PostgreSQL バージョン 17.1 が利用可能になりました。あわせて、最新のマイナーバージョンである、16.5、15.9、14.14、13.17、12.21の利用も可能になっています。 Amazon S3 now supports up to 1 million buckets per AWS account – AWS Amazon S3 で、AWS アカウントあたりのデフォルトバケット数のクォータ(上限値)を 100 から 10,000 に引き上げました。また、最大100万バケットまでクォータの増加をリクエスト可能になりました。この変更は自動的に適用されるため、ユーザー側のよる操作は必要ありません。最初の 2,000 バケットは無料で作成できますが、2,000 バケットを超えると、少額の月額料金がかかる点に注意してください。詳細は S3の料金ページ をご覧ください。 Amazon RDS for Oracle now M7i and R7i instances types – AWS Amazon RDS for Oracle で、M7iおよびR7iデータベースインスタンスタイプが利用可能になりました。新しい最大インスタンスサイズは 48xlarge になり、M6iやR6iインスタンスと比較して50%多い最大vCPUとメモリを利用可能になりました。M7i および R7i インスタンスは、Oracle Database エンタープライズエディション(EE)とスタンダードエディション 2(SE2)の両方のエディションで、Bring Your Own ライセンスモデルで利用できます。 11/15(金) Introducing Amazon Route 53 Resolver DNS Firewall Advanced – AWS Amazon Route 53 Resolver DNS Firewall Advanced がリリースされました。これは Route 53 Resolver DNS ファイアウォールの新しい機能で、DNS トンネリングやドメイン生成アルゴリズム (DGA) などの高度な DNS 脅威に関連する、疑わしいDNSトラフィックを監視およびブロックできます。詳細は こちらのドキュメンテーション をご覧ください。 Amazon Data Firehose supports continuous replication of database changes to Apache Iceberg Tables in Amazon S3 – AWS Amazon Data Firehose で RDS、Aurora、もしくはEC2上で稼働する MySQL もしくは PostgreSQL のトランザクションログから更新データを読み取り、Amazon S3上のApache Iceberg表に差分反映させる機能がPreview提供開始になりました。サーバーレスのサービスを利用して、より容易に、RDBからS3への差分レプリケーションが実現可能になります。東京・大阪リージョンでもPreviewが利用可能です。詳細は こちらのブログ をご覧ください。 Centrally manage root access in AWS Identity and Access Management (IAM) – AWS AWS Identity and Access Management (IAM) に、AWS Organizations 管理化のAWSメンバーアカウントにルート(root)権限でアクセス可能な機能が追加されました。これまで個々のメンバーアカウントごとにrootユーザーが必要で、これをセキュアに管理していく必要がありましたが、この機能により集中的にroot権限を管理できるようになります。 詳細はこちらのブログ をご覧ください。 先週もご案内しましたが、恒例の「1時間でre:Inventの発表まとめをしゃべりきる日本語Webinar」が 12 月 6 日 (金) 12:00~13:00 に開催されます。新発表内容をいっきに振り返る内容なので、ぜひこちらもご覧ください。今回はYoutube Liveでの放送予定ですので、事前に「通知を受け取る」ボタンをクリックしておいてください。 – AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 それでは、また来週! 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。
お客様は通常、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行するために AWS Database Migration Service (AWS DMS) を選択します。AWS DMS は、フルロードの移行は、すべてのエディションの SQL Server をサポートしています。ただし、継続的なレプリケーションと進行中の変更の場合、ソースとなる SQL Server は トランザクションレプリケーション または 変更データキャプチャ (CDC) を有効にする必要があります。これにより、AWS DMS はデータベースのトランザクションログファイルまたはトランザクションログバックアップから変更を読み取り、ターゲットデータベースにレプリケートすることができます。 Enterprise、Standard、Developer などの SQL Server エディションには、トランザクションレプリケーションと CDC 機能が付属しています。したがって、これらのエディションでは Babelfish for Aurora PostgreSQL への継続的なレプリケーションを実装できます。ただし、SQL Server Web エディションを使用している場合や Azure SQL 上で SQL Server ワークロードを実行している場合は、トランザクションレプリケーションと CDC のいずれもサポートされていません。そのような場合は、継続的なレプリケーションなしでフルロードのみを実行できます。 この制限を回避するには、 リンクサーバー と併せて 変更トラッキング を使用するワークアラウンドがあります。このアプローチでは、Azure SQL または SQL Server Web Edition での変更をトラッキングし、対象データベースに効果的にレプリケーションできます。 この投稿では、SQL Server Web Edition (ソース) の変更トラッキング機能と、Babelfish for Aurora PostgreSQL (ターゲット) のリンクサーバー機能を使用して、進行中の変更をレプリケーションする手順を提供します。 ソリューション概要 変更トラッキングはデータベース内のデータ変更をトラッキングするメカニズムです。テーブルで変更トラッキングが有効になると、SQL Server は内部的に別の内部テーブルで変更(挿入、更新、または削除)をトラッキングします。この内部テーブルにはテーブルの主キー列が含まれています。 トラッキングが有効になってからの変更はすべて、CHANGETABLE という関数を使用して取得できます。変更トラッキングの詳細については、「 変更トラッキングの操作 (SQL Server) 」を参照してください。 次の図は、ソリューションアーキテクチャを示しています。 このソリューションを実装するには、次の設定手順を完了してください。 ソースサーバーでデータベースとテーブルレベルの変更トラッキングを有効にします。 AWS DMS を使用して、ソースデータベースの初期フルロードをターゲットに対して行います。 ターゲットにソース SQL サーバーへのリンクサーバーを作成します。 ターゲットにアンカーテーブルを作成します。 ソースから変更されたデータを抽出し、ターゲットテーブルにロードします。 前提条件 このソリューションを試すには、次の前提条件が必要です。 ソースとなる SQL Server または Azure SQL インスタンス SQL Server 上の Northwind データベース バージョン 4.0 または以降の Babelfish for Aurora PostgreSQL インスタンス SQL Server と PostgreSQL のファンクションに関する知識 SQL Server に接続するための SQL Server Management Studio (SSMS) または他のクライアントツール このソリューションには、新しい AWS リソースの作成と利用が伴います。したがって、アカウントに料金が発生します。詳細については、 AWS 料金ぺージ をご確認ください。本番環境にこのソリューションを実装する前に、非本番インスタンスでセットアップを行い、エンドツーエンドの検証を実行することを強くお勧めします。 ソースデータベスでの変更トラッキング有効化 ソースサーバーで変更トラッキングを有効にするには、次の手順に従ってください。 SSMS を使用して SQLServer インスタンスに接続します。 Northwind データベースを選択し、[新しいクエリ] を選択します。 次のコマンドを使用してデータベースレベルで変更トラッキングを有効にします。 ALTER DATABASE NORTHWIND SET CHANGE_TRACKING = ON ( CHANGE_RETENTION = 5 DAYS , AUTO_CLEANUP = OFF ) SQL 継続的レプリケーションのターゲットの一部として含めたいテーブルで変更トラッキングを有効にします。ここでは、次のコマンドを使用して顧客テーブルで変更トラッキングを有効にします。 ALTER TABLE DBO . CUSTOMERS ENABLE CHANGE_TRACKING SQL 次のコマンドを実行して、テーブルで変更トラッキングが有効になっていることを確認してください。 SELECT schema_name ( T . schema_id ) as SCH_NAME , T . NAME , CT . min_valid_version , ct . * FROM northwind . sys . tables T LEFT OUTER JOIN sys . change_tracking_tables CT on T . object_id = CT . object_id WHERE min_valid_version is not null SQL 変更トラッキングが更新された行をどのように取得するかをテストするには、次のコマンドを実行します。 関数 CHANGE_TRACKING_CURRENT_VERSION() を使用して、現在の変更トラッキングバージョンを確認します。この値が 26 であると仮定しましょう。 customers テーブルの行を更新します。 customers テーブルのどの行が更新されたかを確認するには、バージョン番号 (この例では 26) をパラメーターとして CHANGETABLE 関数を使用します。 DECLARE @CTCV INT ; SELECT @CTCV = CHANGE_TRACKING_CURRENT_VERSION ( ) ; -- In this example , the current value is 26 SELECT @CTCV -- update a record in customer table UPDATE dbo . CUSTOMERS SET CompanyName = 'camilo2' where CUSTOMERID = 'ALFKI' -- Get all the changes that are made after version 26 in this example. SELECT P . * , '--' , CT . * FROM customers AS P JOIN CHANGETABLE ( CHANGES northwind . dbo . customers , @CTCV ) AS CT ON P . customerid = CT . customerid ; SQL AWS DMS を使ってフルロードを開始する前に、継続的なレプリケーションが必要なテーブルで変更トラッキングを有効にすることが不可欠です。これにより、システムはフルロードの開始時点から指定されたテーブルに対するすべてのデータ変更操作 (DML) を追跡できるようになります。 AWS DMS を使用して初回のフルロードでソースデータベースをターゲットデータベースに移行 ターゲットにフルロードを使用してソースデータベースを AWS DMS で移行するには、次の手順を実行します。「 Compass ツールと AWS DMS を使用した SQL Server の Babelfish for Aurora PostgreSQL への移行 」を参照し、Babelfish for Aurora PostgreSQL クラスターを作成して接続します。投稿では、AWS DMS を使用して SQL Server から Babelfish にデータを移行する手順も概説されています。 ターゲットサーバーで、Northwind データベースのスキーマを作成してください。Northwind サンプルスキーマは、 GitHub リポジトリ からダウンロードできます。 AWS DMSのフルロード設定を使用して、ソースからターゲットにデータを移行します。手順については、「 AWS Database Migration Service のターゲットとしての Babelfish for Aurora PostgreSQL の使用 」を参照してください。 ソース SQL Server に対するリンクサーバーをターゲットに作成 Babelfish for Aurora PostgreSQL でリンクサーバーを構成するには、「 Babelfish は、リンクサーバーをサポートしています 」を参照してください。次の手順を完了してください。 SSMS または SQLCMD を使用してターゲットのデータベースインスタンスに接続し、次のコマンドを実行します。ここでは、SQLCMD を使用して Babelfish for Aurora PostgreSQL インスタンスに接続します。適切な値でパラメーターを置き換えてください。 sqlcmd - S your - DB - instance . aws - region . rds . amazonaws . com - U test - P password SQL tds_fdw 拡張機能をインストールします。 EXEC sp_execute_postgresql N 'CREATE EXTENSION tds_fdw' ; SQL ターゲットインスタンスで次のコマンドを使用してリンクサーバーを作成します。@datasrc、@rmtuser、および @rmtpassword パラメーターを適切な値に置き換えてください。 Use Northwind ; GO EXEC master . dbo . sp_addlinkedserver @server = N 'ls_northwind' , @srvproduct = N '' , @provider = N 'SQLNCLI' , @datasrc = N 'myserver.xxxxx.US-WEST-2.RDS.AMAZONAWS.COM' , @catalog = 'northwind' ; GO EXEC master . dbo . sp_addlinkedsrvlogin @rmtsrvname = N ' ls_northwind' , @useself = N 'False' , @locallogin = NULL , @rmtuser = N 'username' , @rmtpassword = 'password' ; SQL リモートサーバー上のテーブル、ビュー、またはその他のサポートされているオブジェクトを参照するには、次のコードに示されているように OPENQUERY() T-SQL を使用するか、標準の 4 部構成の名前付け規則を使用します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT * FROM customers' ) ; SQL 初期の変更トラッキングバージョン (この例では 0 を使用) に基づいて customers テーブルの変更されたレコードを取得するには、次のコマンドを実行します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT C.* FROM customers AS C JOIN CHANGETABLE(CHANGES northwind.dbo.customers,0 ) AS CT ON C.customerid = CT.customerid' ) ; SQL 次のスクリーンショットは私たちの出力結果です。 変更トラッキングバージョンに基づいて、ソースの変更済みレコードを正常にクエリしました。ソリューションを自動化するには、変更トラッキングバージョンを保存する必要があります。変更トラッキングバージョンをアンカーテーブルと呼ばれる別のテーブルに保存できます。これにより、前回の同期以降の変更のみを取得できます。 ターゲットにアンカーテーブルを作成 リンクサーバーを使用してソースのレコードを照会した後、ターゲットにアンカーテーブルを作成します。ここでは、次のコマンドを使用して Northwind データベース内に CT_ANCHOR_NORTHWIND という名前のテーブルを作成します。このテーブルはアンカーとして機能し、データがレプリケーションされるたびに変更トラッキングバージョン番号を保持します。 CREATE TABLE ct_anchor_northwind ( sch_name varchar ( 256 ) , tbl_name varchar ( 256 ) , ct_fetched_ver int , -- 0 during first execution ct_next_ver int -- current version at the source database , to fetch next version of the records ) SQL アンカーテーブルを作成した後、追跡する各テーブルの行を挿入します。ここでは、Northwind データベースの customers テーブルのスキーマ名、顧客名、取得した変更追跡バージョン、次の変更トラッキングバージョンの値を挿入します。 insert into ct_anchor_northwind ( sch_name , tbl_name , ct_fetched_ver , ct_next_ver ) values ( 'dbo' , 'customers' , 0 , 0 ) SQL 次のスクリーンショットは私たちの出力結果です。 各レプリケーションでは、CT_NEXT_VER カラムを手動またはスクリプトを使用して変更トラッキングテーブルの現在のバージョン ID で更新する必要があります。この値を使用して、次の変更されたレコードのセットを取得できます。 次の図は、各同期中にバージョン番号を維持する方法を説明しています。 ソースからデータの変更部分を抽出してターゲットテーブルにロード ソースの SQL Server とターゲットの Babelfish for Aurora PostgreSQL 間でデータを同期するには、次の手順を実行します。これらの手順はスケジュールに従って実行することもできます。 ターゲットデータベースに接続し、アンカーテーブル (ct_northwind_anchor) から ct_next_ver( 次にレコードを取得するバージョン ) の値を @ct_next_ver という変数に取得します。 declare @ct_next_ver varchar ( 9 ) SELECT @ct_next_ver = ct_next_ver FROM ct_anchor_northwind WHERE sch_name = 'dbo' and tbl_name = 'customers' print @ct_next_ver -- result: 0 SQL 変数 @ct_src_current_ver にソースからの現在の変更トラッキングバージョンを取得します。ターゲットでリンクサーバーのクエリを使用して値を取得できます。 declare @ct_src_current_ver varchar ( 9 ) SELECT @ct_src_current_ver = src_current_ver FROM OPENQUERY ( ls_northwind , 'select change_tracking_current_version () as src_current_ver from northwind.sys.change_tracking_tables' ) print @ct_src_current_ver -- result: 10 SQL ソーステーブルの変更された行の主キー値に一致するターゲットのレコードを、特定の変更トラッキングバージョン (@ct_next_ver) に基づいて削除します。 DELETE FROM [dbo].[customers] from [dbo].[customers] x JOIN ( SELECT * from openquery(ls_northwind,'select x.[customerid] FROM [northwind].[dbo].[customers] x JOIN changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ')) y on x.[customerid]=y.[customerid] ; -- result : 2 rows affected SQL 特定の変更トラッキングバージョン (@ct_next_ver) に基づいて、ソースから新しいレコードを抽出し、それらの宛先に配置します。 INSERT INTO [dbo].[customers]([customerid],[companyname],[contactname],[contacttitle],[address],[city],[region],[postalcode],[country],[phone],[fax]) SELECT * FROM OPENQUERY(ls_northwind,'select x.[customerid], x.[companyname], x.[contactname], x.[contacttitle], x.[address], x.[city], x.[region], x.[postalcode], x.[country], x.[phone], x.[fax] from [northwind].[dbo].[customers] x join changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ') -- result: 2 rows affected SQL アンカーテーブルの列の値を適切な値で更新してください。これらの値は次の実行時に次のセットを取得するために使用されます。 UPDATE ct_anchor_northwind SET ct_fetched_ver = @ct_next_ver , ct_next_ver = @ct_src_current_ver WHERE sch_name = 'dbo' and tbl_name = 'customers' SQL ターゲットテーブルの値をソースと照合して、同期を確認してください。 SELECT * FROM customers WHERE customerid = 'alfki' SQL クリーンアップ 今後の課金を避け、このユースケースのテスト中に作成されたコンポーネントを削除するには、以下の手順を実行してください。 SSMS を使用して、ソースの SQL Server インスタンスに接続します。 マスターデータベースを選択し、[新しいクエリ] を選択します。 次のコマンドを実行してください。 Drop database Northwind GO SQL まとめ この投稿では、リンクサーバーを使用した変更トラッキングによって、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行する方法を示しました。この構成により、最小のダウンタイムで SQL Server ワークロードを Babelfish for Aurora PostgreSQL に移行できます。このソリューションは、スクリプトをスケジュールされたジョブとして実行することで自動化できます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Chandra Pathivada は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオープンソースデータベースエンジンを中心に Amazon RDS チームで働いています。AWS 上でリレーショナルデータベースワークロードを設計、デプロイ、最適化するお客様をサポートすることを楽しんでいます。 Minesh Chande は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。彼は様々な業界のお客様が SQL Server のワークロードを Amazon RDS、Amazon RDS Custom、Babelfish for Aurora PostgreSQL などのマネージドデータベースプラットフォームに設計、移行、最適化するのを支援しています。
AWS Database Migration Service (AWS DMS) は、データベースと分析ワークロードを AWS に迅速かつ安全に移行するためのマネージド型のマイグレーションおよびレプリケーションサービスです。移行中もソースデータベースは完全に稼働し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。AWS DMS は、最も広く使用されている商用およびオープンソースの ソースデータベース と ターゲットデータベース の間でデータを移行できます。 SQL Server は Microsoft が開発した リレーショナルデータベース です。 Amazon Relational Database Service (Amazon RDS) for SQL Server を使用すると、 クラウド 上で SQL Server の展開を簡単に設定、運用、スケーリングできます。Amazon RDS はデータ レプリケーションをサポートしており、 変更データキャプチャ (CDC) を有効にすることが、AWS DMS と Amazon RDS for SQL Server を使用するための 前提条件 の 1 つとなっています。CDC はテーブルのデータに加えられた変更をキャプチャします。それぞれの変更に関するメタデータを格納し、後で参照できます。 この投稿では、CDC パラメータについて深く掘り下げ、AWS DMS の設定時の影響について説明するとともに、いくつかのベストプラクティスについても説明します。 前提条件 この投稿に沿って進めるには、次の AWS サービスに精通している必要があります。 AWS DMS Amazon RDS for SQL Server さらに、このソリューションに必要なリソースを起動するのに十分な権限を持つ AWS アカウントが必要です。 AWS DMS は Amazon RDS for SQL Server とどのように連携するのか Amazon RDS for SQL Server の場合、AWS DMS は Microsoft の関数を使用してトランザクションログを読み取り、デフォルトで上位 50,000 イベントを取得します。AWS DMS は、 AWS DMS タスク で定義されたテーブルに関連する特定のパーティション ID のデータベースログを照会することから始まります。パーティション ID は、フルロードと CDC の両方で、各テーブルの再ロード、タスクの再起動、タスクの再開時に読み取られます。AWS DMS はオブジェクト ID を取得し、それらのオブジェクト ID に対応するデータパーティション ID を取得します。パーティション ID を取得した後、関連するパーティションをトランザクションログからフェッチします。このサイクルは 1 秒ごとに実行されます。 次の図は、アーキテクチャを示しています。この例では、Amazon RDS for SQL Server をソースとして使用しています。AWS DMS タスクのターゲットは、 サポートされている任意のエンドポイント になります。 AWS DMS は、Microsoft の関数を使ってトランザクションログを読み取り、AWS の DMS タスクの対象となるテーブルとソースデータベースで CDC が有効になっている必要があります。 なぜ AWS DMS で CDC が必要なのか ? テーブルで CDC が有効になると、SQL Server は cdc スキーマにテーブルを作成します。作成されたテーブル (変更テーブル) には変更データが格納され、トラッキングされているスキーマとテーブルに基づいて名前が付けられます。たとえば、 dbo スキーマに customer という名前のテーブルがある場合、 dbo.customer テーブルに対するすべての変更を記録するために cdc.customer_CT という名前のテーブルが cdc スキーマに作成されます。 AWS DMS は変更テーブルを読み取りません。AWS DMS は、変更がトランザクションログに確実に記録されるように CDC を有効にする必要があります。前のセクションで説明したように、AWS DMS は Microsoft の関数を使ってトランザクションログから変更を読み取ります。ソース側の次のテーブルを考えてみましょう。 CREATE TABLE [ dbo ] . [ dmstest ] ( [ id ] [ int ] NOT NULL , [ name ] [ varchar ] ( 50 ) NULL , CONSTRAINT [ PK_dmstest ] PRIMARY KEY CLUSTERED ( [ id ] ASC ) WITH ( PAD_INDEX = OFF , STATISTICS_NORECOMPUTE = OFF , IGNORE_DUP_KEY = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON , OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF ) ON [ PRIMARY ] ) ON [ PRIMARY ] SQL このテーブルに UPDATE ステートメントを発行して [name] 列を更新すると、 [RowLog Contents 0] と [RowLog Contents 1] に変更情報が更新されます。AWS DMS がソース上で実行する次のクエリの一部を示します。 select top 50000 [ Current LSN ] , [ operation ] , [ RowLog Contents 0 ] , [ RowLog Contents 1 ] -- After Image SQL クエリの結果を見ると、2 番目のレコードに CDC を有効にした後に発行した UPDATE ステートメントの状態がトランザクションログにキャプチャされていることが分かります。 Current LSN operation RowLog Contents 0 RowLog Contents 1 0000014f:0000c16d:0002 LOP_MODIFY_ROW 0x1800 746573747573657267 0x1900 74657374757365726162 0000014f:0000c9ba:0016 LOP_MODIFY_ROW 0x300008000200000002000001001900 74657374757365726162 0x300008000200000002000001001800 746573747573657267 CDC パラメータの理解 CDC では、2 つのジョブが作成されます。 キャプチャジョブ – トランザクションログファイルを読み取り、変更をトラッキングするテーブルにプッシュします。 クリーンアップジョブ – 保持期間を過ぎた変更トラッキングテーブルのレコードを削除します。 以下は、AWS DMS に関連する CDC パラメータ です。 max_trans – 各スキャンサイクルで処理するトランザクションの最大数 max_scans – ログからすべての行を抽出するために実行するスキャンサイクルの最大数 continuous – キャプチャジョブを継続的に実行するか (1)、1回だけ実行するか (0) を示します polling_interval – ログスキャンサイクル間の秒数 retention – 変更行がテーブルに保持される分数 AWS DMS は変更テーブルを読み取らないので、トランザクションログの変更の保持を制御するために CDC パラメータを調整する必要があります。 次のセクションでは、 max_trans 、 max_scans 、 polling_interval パラメータがトランザクションログ内のレコードの保持にどのように役立つのか、AWS DMS が変更をキャプチャするのに十分な期間変更が保持されるように調整する方法について説明します。 CDC パラメータの実行 これらのパラメーターを説明するために、次の手順を踏みます。 dmscdc データベースとその中の dmstestcdc テーブルを作成してください。 create database dmscdc ; use dmscdc ; CREATE TABLE dbo . dmstestcdc ( n INT NOT NULL PRIMARY KEY ) ; SQL データベース dmscdc およびテーブル dmstestcdc で CDC を有効にします。 exec msdb . dbo . rds_cdc_enable_db 'dmscdc' ; use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'dmstestcdc' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL CDC パラメータを調整して、ログレコードが十分な期間保持されるようにする必要があります。そうすることで、AWS DMS がトランザクションレコード、つまり、ソースデータベースのトランザクションログファイルで探している特定のログシーケンス番号 (LSN) を照会できるようになります。これらは次の要因に左右されます。 ターゲットがソースに比べてどれくらいトランザクションが遅れているか CDC ジョブの実行頻度、つまり特定のポーリング間隔はどのくらいか Maxtrans と Maxscans の値は何か。これらのパラメータは、CDC が各実行でどれくらいのトランザクションを処理するかを決定します。 次のように取り込みジョブを構成してください。取り込みジョブのパラメーターを変更する場合は、毎回 CDC ジョブを停止して再起動する必要があります。この場合、 pollinginterval を変更する必要があります。 EXECUTE sys . sp_cdc_change_job @job_type = N 'capture' , @pollinginterval = 3599 ; --Setting the polling interval for 1 hour EXEC sys . sp_cdc_stop_job @job_type = N 'capture' ; EXEC sys . sp_cdc_start_job @job_type = N 'capture' ; SQL 次のコマンドを実行して CDC パラメータを確認してください。 exec sys . sp_cdc_help_jobs ; SQL job_id job_type job_name maxtrans maxscans continuous pollinginterval retention threshold A49487C5-BF3C-4A8C-9385-6AFA7A3541B9 capture cdc.dmscdc_capture 500 10 1 3599 0 0 17511020-59D2-4C9E-BEA9-0578C0D23B11 cleanup cdc.dmscdc_cleanup 0 0 0 0 4320 5000 前述の設定では、キャプチャジョブは 1 時間の周期で 5,000 レコード ( maxtrans * maxscans ) を処理します。 テーブル dmstestcdc にレコードをいくつか挿入して確認してください。 DECLARE @max AS INT , @min AS INT ; SET @max = 100000 ; SET @min = 1 ; WHILE @min <= @max BEGIN INSERT INTO dbo . dmstestcdc VALUES ( @min ) ; SET @min = @min + 1 ; END SQL キャプチャジョブは、トランザクションログから前の取引を読み取り、それらを replicated されたものとしてマークします。この場合は 100,001 レコードです。CDC ジョブが実行されると、キャプチャジョブはそれらの取引を完了としてマークします。 次のクエリを実行して CDC セッションを確認してください。これにより 10 行が取得されるはずです。このクエリにより、CDC が処理したレコード数が分かります。今回の場合は 5,000 件です。 SELECT tran_count , start_time , end_time , scan_phase from sys . dm_cdc_log_scan_sessions where scan_phase <> 'Aggregate' order by end_time desc SQL tran_count start_time end_time scan_phase 500 2023-12-07 20:34:15.100 2023-12-07 20:34:15.123 Done 500 2023-12-07 20:34:15.067 2023-12-07 20:34:15.083 Done 500 2023-12-07 20:34:15.037 2023-12-07 20:34:15.053 Done 500 2023-12-07 20:34:15.003 2023-12-07 20:34:15.023 Done 500 2023-12-07 20:34:14.963 2023-12-07 20:34:14.990 Done 500 2023-12-07 20:34:14.927 2023-12-07 20:34:14.950 Done 500 2023-12-07 20:34:14.883 2023-12-07 20:34:14.910 Done 500 2023-12-07 20:34:14.840 2023-12-07 20:34:14.870 Done 500 2023-12-07 20:34:14.797 2023-12-07 20:34:14.827 Done 500 2023-12-07 20:34:14.540 2023-12-07 20:34:14.773 Done 前述のレコードは、通常 5 分ごとに行われる Amazon RDS for SQL Server のトランザクションログのバックアップ時にトランザクションログから削除されます。これにより、トランザクションログのサイズを維持し、LSN を進めることができます。残りのレコード (95,001件) は、次のキャプチャジョブの実行時に取り込まれます。 SQL Server は CDC によってトランザクションが読み取られた後でしか トランザクションログをフラッシュしません。トランザクションログに保持するレコード数と AWS DMS のレプリケーションラグのバランスを取る必要があります。この場合、ポーリング間隔を短くすることで、キャプチャジョブのパラメータを積極的に設定します。その結果、トランザクションログから LSN が欠落するシナリオが発生する可能性があります。トランザクションログの切り捨てを回避して、変更が十分な期間トランザクションログに保持されるようにするには、次のコマンドを実行してポーリング間隔を 1 日に設定することをお勧めします。 use dbname EXEC sys . sp_cdc_change_job @job_type = 'capture' , @pollinginterval = 86399 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' SQL CDC の履歴情報のキャプチャ キャプチャジョブの履歴情報を監視するには、 sys.dm_cdc_log_scan_sessions テーブルを照会できます。このテーブルには、現在のデータベース内の各ログスキャンセッションに対して 1 行が含まれています。最大 32 のスキャンセッションが含まれます。次のクエリを実行して、最新の 10 レコードを取得します。 SELECT session_id , start_time , end_time , duration , scan_phase , error_count , tran_count , command_count , last_commit_cdc_time , latency , empty_scan_count , failed_sessions_count FROM sys . dm_cdc_log_scan_sessions order by end_time desc OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY ; SQL 以下はサンプル出力です。 session_id start_time end_time duration scan_phase error_count tran_count command_count last_commit_cdc_time latency empty_scan_count failed_sessions_count 0 2023-12-07 19:21:27.283 2023-12-08 00:34:12.837 6 Aggregate 0 125001 125001 2023-12-07 19:50:32.657 17020 0 0 651 2023-12-08 00:34:12.820 2023-12-08 00:34:12.837 0 Done 0 500 500 2023-12-07 19:50:32.657 17020 0 0 650 2023-12-08 00:34:12.790 2023-12-08 00:34:12.810 0 Done 0 500 500 2023-12-07 19:50:31.700 17021 0 0 649 2023-12-08 00:34:12.760 2023-12-08 00:34:12.780 0 Done 0 500 500 2023-12-07 19:50:30.707 17022 0 0 648 2023-12-08 00:34:12.703 2023-12-08 00:34:12.723 0 Done 0 500 500 2023-12-07 19:50:29.757 17023 0 0 647 2023-12-08 00:34:12.670 2023-12-08 00:34:12.693 0 Done 0 500 500 2023-12-07 19:50:28.620 17024 0 0 646 2023-12-08 00:34:12.633 2023-12-08 00:34:12.660 0 Done 0 500 500 2023-12-07 19:50:27.523 17025 0 0 645 2023-12-08 00:34:12.587 2023-12-08 00:34:12.620 0 Done 0 500 500 2023-12-07 19:50:26.527 17026 0 0 644 2023-12-08 00:34:12.530 2023-12-08 00:34:12.573 0 Done 0 500 500 2023-12-07 19:50:25.490 17027 0 0 643 2023-12-08 00:34:12.500 2023-12-08 00:34:12.520 0 Done 0 500 500 2023-12-07 19:50:24.450 17028 0 0 ベストプラクティスと既知の問題 このセクションでは、CDC パラメーターに関するベストプラクティスと考慮事項をいくつか説明します。 Multi-AZ インスタンスでのフェイルオーバー時にトランザクションログレコードが切り捨てられる プライマリインスタンスで CDC パラメータを変更した場合は、必ず rds_set_configuration コマンドを実行して、フェイルオーバー時にも変更内容が保持されるようにしてください。 例えば、 dms_test データベース上で次のサンプルコマンドを実行して、 maxtrans と pollinginterval パラメータを設定できます。 USE dms_test ; EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 10000 , @pollinginterval = 6000 ; SQL フェイルオーバー後もこれらの値が保持されるように、次のコマンドを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 10000 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_pollinginterval' , 6000 ; SQL AWS DMS レプリケーションインスタンスの計画的フェイルオーバーまたはメンテナンス Amazon RDS for SQL Server の場合、ソースでメンテナンス作業を行う際、あるいは関連する AWS DMS レプリケーションインスタンスの計画的なスケーリングを行う際に、AWS DMS タスクが停止する度にキャプチャジョブが実行されないようにする必要があります。キャプチャジョブが実行されると、スキャンされたイベントは Amazon Simple Storage Service (Amazon S3) で 5 分ごとにトランザクションログバックアップが行われるときにトランザクションログから削除されます。 次のコマンドを実行してキャプチャジョブを停止してください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止します。 必要なメンテナンスを完了します。 AWS DMS タスクを再開します。 ソースの遅延 が 0 になるのを待ちます。 次のコマンドを実行してキャプチャジョブを開始します。 exec sp_cdc_start_job 'capture' SQL AWS DMS タスクは、上記の手順に従わない場合、次のエラーメッセージで失敗します。 2023-10-06T15:02:05 [SOURCE_CAPTURE ]E: Failed to access LSN '0000019f:00007fff:0008' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:813) JSON ソースでキャプチャジョブを停止した後に LSN が切り捨てられているのを確認した場合、アクティブなトランザクションログ内に切り捨てを防ぐ CDC イベントがない可能性があります。これはデータベースがアイドル状態にあるか、トランザクション数が少ない場合に発生する可能性があります。この場合、手順は次のとおりです。 次のコマンドを実行してキャプチャジョブを停止してください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止する前に、CDC 対応のデータベースにいくつかのトランザクションまたは変更があることを確認してください。毎秒 DML ステートメントを実行するスクリプトを実行できます。テストスクリプトを作成する場合は、このセクションの後半に記載されている手順に従ってください。 AWS DMS タスクを停止します。 必要なメンテナンスを完了させます。 AWS DMS タスクを再開します。 ソースレイテンシを監視して同期を待ちます。 ステップ 2 で設定したスクリプトを停止します。 次のコマンドを実行してキャプチャジョブを開始します。 exec sp_cdc_start_job 'capture' SQL ステップ 2 で言及されたテストスクリプトを実行するためのスクリプトを設定するには、以下の手順に従ってください。以下のスクリプトでは、dbo スキーマの下に test_table という名前のテーブルを作成し、その test_table テーブルで CDC を有効にします。次に、SQL Server エージェントジョブを設定し、上記のテーブルにレコードを挿入してから削除します。これにより、CDC ジョブによってピックアップされる必要のあるトランザクションログに変更があり、トランザクションログの切り捨てを防ぐことができます。 テストテーブルを作成します。 create table dbo . test_table ( id int not null PRIMARY KEY ) ; SQL 新しいテーブルを CDC に追加してください。 use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'test_table' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL Amazon RDS で SQL Server エージェントジョブを作成し、1 分ごとにレコードを挿入または削除します。エージェントジョブで適切な owner_login_name と database_name の値を使用してください。 USE [ msdb ] GO /****** Object: Job [aws_dms_traffic_to_test_table] Script Date: 10/9/2023 4:17:28 PM ******/ BEGIN TRANSACTION DECLARE @ReturnCode INT SELECT @ReturnCode = 0 /****** Object: JobCategory [[Uncategorized (Local)]] Script Date: 10/9/2023 4:17:28 PM ******/ IF NOT EXISTS ( SELECT name FROM msdb . dbo . syscategories WHERE name = N '[Uncategorized (Local)]' AND category_class = 1 ) BEGIN EXEC @ReturnCode = msdb . dbo . sp_add_category @class = N 'JOB' , @type = N 'LOCAL' , @name = N '[Uncategorized (Local)]' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback END DECLARE @jobId BINARY ( 16 ) EXEC @ReturnCode = msdb . dbo . sp_add_job @job_name = N 'aws_dms_traffic_to_test_table' , @enabled = 1 , @notify_level_eventlog = 0 , @notify_level_email = 0 , @notify_level_netsend = 0 , @notify_level_page = 0 , @delete_level = 0 , @description = N 'No description available.' , @category_name = N '[Uncategorized (Local)]' , @owner_login_name = N 'admin' , @job_id = @jobId OUTPUT IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback /****** Object: Step [generate_traffic] Script Date: 10/9/2023 4:17:28 PM ******/ EXEC @ReturnCode = msdb . dbo . sp_add_jobstep @job_id = @jobId , @step_name = N 'generate_traffic' , @step_id = 1 , @cmdexec_success_code = 0 , @on_success_action = 1 , @on_success_step_id = 0 , @on_fail_action = 2 , @on_fail_step_id = 0 , @retry_attempts = 0 , @retry_interval = 0 , @os_run_priority = 0 , @subsystem = N 'TSQL' , @command = N 'insert into dbo.test_table values (30); delete from dbo.test_table where id = 30; ' , @database_name = N 'dmscdc' , @flags = 0 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_update_job @job_id = @jobId , @start_step_id = 1 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobschedule @job_id = @jobId , @name = N 'schedule for running DML statements for generating user_traffic' , @enabled = 1 , @freq_type = 4 , @freq_interval = 1 , @freq_subday_type = 4 , @freq_subday_interval = 1 , @freq_relative_interval = 0 , @freq_recurrence_factor = 0 , @active_start_date = 20231006 , @active_end_date = 99991231 , @active_start_time = 0 , @active_end_time = 235959 , @schedule_uid = N '84a2b2ab-4234-40a3-add4-c04d561ad88f' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobserver @job_id = @jobId , @server_name = N '(local)' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback COMMIT TRANSACTION GOTO EndSave QuitWithRollback: IF ( @ @TRANCOUNT > 0 ) ROLLBACK TRANSACTION EndSave: GO SQL AWS DMS コンソールで、AWS DMS タスクのテーブル選択ルールにワイルドカード (%) を使用してこのテーブルを複製する場合は、 マッピング ルールを使用してこのテーブルを AWS DMS タスクから除外してください。 { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "dbo", "table-name": "test_table" }, "rule-action": "exclude", "filters": [] }, JSON SQL Server インスタンスの RDS の計画的な再起動またはフェイルオーバー RDS for SQL Server エージェントサービスは、RDS for SQL Server インスタンスの再起動やフェイルオーバーが発生するたびに再起動し、これにより再起動またはフェイルオーバー後に CDC ジョブが再実行されます。トランザクションログの切り捨てを回避するには、次の手順に従ってください。 AWS DMS タスクを停止します。 フェイルオーバー後に元に戻すため、現在の maxtrans と maxscans の値を取得します。 sys . sp_cdc_help_jobs ; SQL CDC の設定を変更して、 maxtrans と maxscans を 1 に設定します。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 1 , @maxscans = 1 exec sp_cdc_stop_job 'capture' GO SQL フェイルオーバー後も CDC パラメーターを保持するため、次のステートメントを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 1 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 1 ; SQL RDS for SQL Server インスタンスを再起動します。 AWS DMS タスクを再開します。 キャプチャされた構成で、キャプチャされたジョブを再起動します。次のスクリプトでは、 maxtrans を 500、 maxscans を 10 と想定していますが、ステップ 2 でキャプチャした値を使用する必要があります。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 500 , @maxscans = 10 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' GO SQL フェイルオーバー後も CDC パラメータを保持するために、次のステートメントを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 500 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 10 ; SQL 後片付け 定期的な課金を避けるために、リソースをクリーンアップしてください。 AWS DMS コンソールで、設定したすべての AWS DMS タスクを削除します。 次のコマンドを実行してデータベースを削除します。 EXECUTE msdb . dbo . rds_drop_database N 'dmscdc' SQL 結論 この投稿では、Amazon RDS for SQL Server をソースとして AWS DMS タスクを構成する際の CDC パラメーターの設定の重要性を説明し、さらにベストプラクティスについても説明しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Suchindranath Hegde は、Amazon Web Services のデータマイグレーションスペシャリストソリューションアーキテクトです。AWS DMS を使用して AWS クラウドへのデータ移行に関するガイダンスと技術支援をお客様に提供しています。 Abhishek Chaturvedi は、Amazon Web Services の DMS チームのシニアデータベースエンジニアです。 Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発およびエンジニアリングチームと密接に協力し、移行およびレプリケーションサービスの改善に取り組んでいます。また、お客様と協力し、さまざまなデータベースおよび分析プロジェクトに関するリードとテクニカルサポートを提供し、AWS を使用する際のソリューションの価値向上をサポートしています。 Junu Thankappan は、Amazon Web Services のシニアデータベースエンジニアです。彼は AWS RDS チームに所属し、商用データベースエンジンと SQL Server に注力しています。
このブログは、 “Boost sales team productivity and effectiveness with Sales Concierge on AWS” の翻訳です。 急速に進化する製薬業界において、営業チームは医療従事者 (HCP) との効果的なエンゲージメントという大きな課題に直面しています。薬剤の複雑さや、革新的なGo-to-Marketモデル、そして激しい競争といったチャレンジの中で、営業チームに求められているのは、重要なデータへのアクセス、HCPとのコミュニケーションに関するガイダンス、そして事務作業の自動化などです。これらのニーズに応えることで、企業は営業チームを強化し、適切な顧客エンゲージメントを実現し、事業目標を達成することができます。このブログでは、Amazon Web Services (AWS) のAIを活用したアーキテクチャーガイダンス「Sales Concierge」を紹介します。これは、データ、インサイト、ツールを統合し、営業チームの生産性と効率を高めるものです。最近の マッキンゼーの記事 によると、営業チームのパフォーマンスは生成AIツールを利用することにより、生産性と効率を10~15%改善し、売上を1~2%押し上げる可能性があると述べられています。 現在の課題 現在、製薬企業の営業チームは、コールプランニング、コール後の報告、社内の事務作業など、日々の責任を果たすために、様々なツールやシステムを使い分けなければなりません。この断片化されたアプローチでは、生産性の課題が生じがちです。 HCPの好み、治療パターン、市場動向といった重要な情報へのアクセスの遅れ さまざまな情報源からのデータとインサイトを統合する時間の増加 HCPとのエンゲージメントを最適化するための有益な推奨を見逃すリスク これらの個別のシステムを操作する時間は、HCPや他の主要な関係者との対話といった、より価値のあるアクティビティを阻害しています。さらに、システムの手動更新の遅れや、管理業務に費やされる時間の無駄も、営業チームが本来の使命に集中できなくなる原因になっています。 これらの課題に加えて、現在の活動推奨エンジンはルールベースが主流で、個々のHCPシナリオや好みに合わせた賢明なコンテクスト化された推奨を提供できていません。このようなパーソナライズやインテリジェンスの欠如が、営業担当者 (MR) による利用率の低さにつながっており、HCPとの優れたエンゲージメントを実現し、ひいては業務目標の達成につなげることができずにいます。 これらの生産性課題から、データ、インサイト、ツールを統合したプラットフォームが切実に必要とされるようになりました。これにより、製薬企業の営業チームは戦略的な営業に集中し、HCPとのやり取りを強化することができるようになります。 ソリューションの概要 生成AIを活用したパーソナルアシスタントがすぐ手元にあることを想像してみてください。このソリューションでは、MRがHCPエンゲージメントのためのインサイトとガイダンスを受けられるだけでなく、企業レポート、ノウハウ、メトリクスへの簡単なアクセスも可能になります。加えて、事務作業、データ入力、その他の問い合わせにも対応します。 このブログでは、製薬企業が独自のカスタマイズされたSales Conciergeソリューションを構築し、営業チームを強化する方法を包括的にご案内します。このガイダンスには、自然言語インターフェース、重要データとインサイトの統合、事務作業の自動化を可能にする直感的な生成AIソリューションを構築するための主要な機能、サービス、ベストプラクティスが含まれています。 図1: Sales Concierge アプリケーションの例。1つ目の画像ではチャットなどのモジュールへのリンクがあるナビゲーションページ、2つ目の画像ではHCPとのやり取りについてのメトリクスがわかるインサイトページが示されている 。 この Sales Concierge ガイダンスの目的は、生成AIと自動化機能を活用し、営業の生産性、顧客エンゲージメント、業務目標達成を促進するためのフレームワークを提供することです。このガイダンスを検討する際は、これらの原則と技術を活用して、組織と営業チームの独自のニーズに合ったソリューションを構築する方法を検討してください。 Sales Concierge ガイダンスは、Veeva Vault CRM、Salesforce Marketing Cloud、データ製品、データ資産、製薬業界で広く使用されている他の営業・マーケティングツールとシームレスに統合されるよう設計されています。強力な統合機能を活用することで、このソリューションはこれらのシステムからデータにアクセスし、統合することができます。これにより、MRは顧客情報、エンゲージメント履歴、市場インサイトを包括的に把握できるようになり、Sales Concierge 内でそれらにアクセスできるようになります。 Sales Concierge ガイダンスを成功させるには、下記のようなデータへの統一されたアクセスを可能にすることが重要です。組織は Sales Concierge を使って、さまざまなデータドメインからデータとコンテンツを取得できます。これには、事前処理されたデータ製品、生のデータセット、非構造化ナレッジベース、さまざまなデータドメインのアプリケーションやAPIが含まれます。 図2: Sales Concierge アプリケーションを通じて営業チームの質問に答えるためのデータソース、API、アプリケーションの一覧。 この Sales Concierge ガイダンスには、生産性、効率性、優れた顧客エンゲージメントを促進する主要なビジネス機能を提供するチャットインターフェイスも含まれます。 マルチモーダルチャット: 生成AIによって動作し、音声とテキストの両方の入力を使って、データ、インサイト、システムと自然言語でやり取りできるようになります。オーケストレーションエンジンがこれらのやり取りを処理し、ユーザーの意図を検出し、質問を適切なデータソースに振り分けます。 プロセスは意図の検出から始まり、オーケストレーションエンジンがユーザーの質問を解釈し、エージェント、ナレッジベース、プロンプトなどの適切なツールを特定します。これらのツールは、SQLクエリの生成 (Text to SQL)、APIコールの作成 (Test to API)、非構造化データソースからのコンテンツ取得など、さまざまなタスクを実行します。これにより、MRはHCPインサイト、市場情報、アカウント詳細、競合情報、テリトリーデータ、業界トレンド、Next Best Action 推奨など、さまざまなデータやインサイトにクエリを投げることができます。 図3: ユーザーが生成AIオーケストレーションエンジンによって動作するSales Concierge アプリケーションとやり取りする方法。このエンジンはエージェントとナレッジベースを使ってユーザーの質問に応答する。 デジタルエージェント: 生成AI エージェントを活用することで、Sales Concierge ソリューションは、コールサマリの作成やコールノートの記録などのタスクを管理できます。関連するユースケース (サポートチケットの作成、CRMへのコールノートの更新、会議予定の更新など) のためにシステムを更新することもできます。同時に、さまざまなアプリケーションやデータ資産にアクセスするための一元的なデジタル窓口機能を提供します。 Sales Concierge は、さまざまなアプリ、ポータル、システムを起動するための入り口として機能し、営業チームがリソースにアクセスする際の中心的で効率的な方法を提供します。この革新的なアプローチは、営業チームが機能する方法に変革をもたらすものであり、生成AIと自動化機能を活用して、生産性を高め、顧客とのやり取りを向上させ、全体的な目標達成を実現します。 実行可能なインサイト: 複数のデータソースと統合することで、Sales Concierge ソリューションは、HCPとのより効果的なエンゲージを可能にするさまざまな重要な質問に答えることができます。これには、HCPインサイトとエンゲージメント、販売実績と市場シェア、日々の計画、トレーニングとパフォーマンス追跡に関する包括的な詳細が含まれます。 図4: Sales Concierge アプリケーション内のチャットモジュールの例を示す図。1つ目の画像にはサンプル質問付きのチャットインターフェースが、2つ目の画像には、自然言語の質問がSQLに変換され、データベースからデータを取得し、自然言語で出力される様子が示されている。 Sales Concierge が答えられるサンプル質問は次のとおりです。 HCPインサイトとエンゲージメント このHCPには新規および継続中の患者がどれくらいいますか? このHCPに最後に送信されたメッセージは何ですか? このHCPの処方傾向や情報収集活動はどうですか? このHCPとの過去のやりとり (メール、サンプル提供、競合他社訪問など) は何がありましたか? このHCPとの今後の訪問、カンファレンス、イベントは予定されていますか? コールプランニング このHCPへの未対応のフォローアップ、未解決のリクエスト、アクション項目はありますか? 今日はどのHCPを訪問すべきですか? このHCPの好みに基づいて、Next Best Actionやおすすめは何ですか? 売上・ブランドパフォーマンス 当社製品の最近の市場シェアと販売量の変化はどうですか? このテリトリーにおいて、当社の製品と主要競合製品を比べるとどうですか? 関連するデータソースと統合することで、Sales Concierge はMRに包括的なインサイトと実行可能な情報を提供します。これにより、営業チームは より情報に基づいた意思決定ができ、パーソナライズされたエンゲージメントを提供し、医療従事者とのやり取りでより大きな成功を収めることができます。 アーキテクチャの概要 このアーキテクチャは、AWSの幅広い機能とサービスを活用し、Sales Concierge ソリューションを効率的かつ効果的に実装するためのガイダンスを作成しています。この包括的で、モジュール化された、拡張性と柔軟性のあるアーキテクチャは、導入、スケーラビリティ、コスト効率の重要な成功要因に対応するよう設計されており、さまざまな機能を無理なく統合しています。 Sales Concierge の主な機能には、自然言語と音声インタラクション、構造化データ (Text to SQL) へのアクセス、APIと非構造化データへのアクセス、最適化された待ち時間とコストがあります。また、モジュール化と柔軟なデザイン、プライバシーと責任あるAIコントロール、強力なデータセキュリティとガバナンスコントロールも備えています。 このソリューションのインテリジェンスを支えているのが、AIエージェントです。これらは、システムや接続されたアプリケーションとのやり取りに必要なツール、API、アクションを適切に選択できます。これにより、MRの日常的なタスクを合理化し、ワークフローのオーケストレーションを効率化することができます。 図5: このアーキテクチャ図は、Sales Concierge ソリューションを支える包括的なAWSサービスを示している。アプリケーション、オーケストレーション、生成AIツール、データ管理の必要なサービスが含まれている 。 フロントエンドでは、 AWS Amplify を利用して、シームレスで軽快なユーザーインターフェースを提供しています。AWS Amplify は Amazon Lex と Amazon Polly とシームレスに統合し、マルチモーダルのインタラクションを実現しています。MRは音声とテキストの両方の入力でシステムとやり取りでき、ニーズに最適な形式で応答を受け取ることができます。 このフロントエンドは、 Amazon API Gateway を通してバックエンドに接続されています。API Gateway は、APIレイヤーを管理および保護し、ユーザーのリクエストを適切なサービスにルーティングします。バックエンドの中核処理は AWS Lambda が行い、さまざまなユーザーリクエストを処理します。 動的なコンテンツ生成、データ処理、生成AIを活用したインサイトを実現するため、このアーキテクチャは Amazon Bedrock と統合しています。Amazon Bedrock は、主要なAI企業による高性能な基盤モデル (FM) を選択できる、フルマネージドサービスです。 Amazon Bedrock Prompt Flows コンポーネントは、ユーザー入力をオーケストレーションし、その意図を検出し、ユーザーのニーズに基づいて複数のターゲットにクエリを振り分けます。 構造化データに対しては、 Amazon Bedrock Agents が Text to SQL のアプローチを使ってデータベースからデータにアクセスします。リアルタイムに近い情報に対しては、Text to API のアプローチを使用します。Text to API のアプローチを使うと、Amazon Bedrock Agent はユーザーに代わってアクションを実行することもできます。 Amazon Bedrock Knowledge Bases は、フルマネージド機能で、Retrieval Augmented Generation (RAG) ワークフロー全体を実装できます。これは、非構造化データリポジトリに基づいて質問に答えるために使用されます。Amazon Bedrock モデルは、 Amazon Bedrock Prompt Management 機能で管理されるプロンプトカタログから最適なプロンプトを選択し、カスタマイズされた応答を生成します。これらの応答は、その後 Amazon Polly または音声機能の Amazon Lex を使ってテキストから音声に変換され、ユーザーエクスペリエンスが向上します。 データの保存と取得には、このアーキテクチャは Amazon DynamoDB を使ってユーザーインタラクションのコンテキストとパーソナライゼーションを保持しています。大きなデータは Amazon Simple Storage Service (Amazon S3) に保存され、Amazon Bedrock Knowledge Bases と同期して、生成AIによるインサイトを強化しています。構造化データは Amazon Redshift のようなサービスに保存され、Amazon Bedrock Agents はText to SQL のアプローチを使ってこのデータに直接クエリを投げることができます。 システムのセキュリティを確保するため、このアーキテクチャには認証のための Amazon Cognito 、データガバナンスのための AWS Lake Formation 、コンテキストを踏まえたグラウンディングチェックとセーフガードデータのための Amazon Bedrock Guardrails といったAWSサービスを組み込んでいます。さらに、アクセス管理のための AWS Identity and Access Management (IAM) 、監査のための AWS CloudTrail 、モニタリングのための Amazon CloudWatch も利用されています。これらのサービスにより、Sales Concierge ソリューションは関連する規制 (医療保険の相互運用性と説明責任に関する法律 (HIPAA) や一般データ保護規則 (GDPR) など) を順守し、厳格なデータプライバシーとセキュリティ基準を維持できるよう保護されています。 さまざまなAWSサービスを統合したこの包括的なアーキテクチャにより、製薬業界の固有なニーズに対応した強力で、スケーラブルな、極めて効率的な Sales Concierge ソリューションが実現します。このガイダンスを採用することで、企業はHCPとのエンゲージメント向上を実現しながら、厳格なコンプライアンス要件にも準拠した上で、営業チームを強化することができます。 ベネフィット 包括的な Sales Concierge ソリューションの導入により、製薬企業の営業チームの生産性、顧客エンゲージメント、そして業務実績を大幅に向上させることができます。事務作業を自動化し、重要なデータ、市場インサイト、パーソナライズされたHCPプロファイルへのシームレスなアクセスを提供することで、MRは戦略的な販売活動に集中できるようになり、より高い成約率と有意義な顧客エンゲージメントにつながります。 統合されたデジタルツール、バーチャルエージェントサポート、継続的な学習リソースにより、営業チームは情報に基づいた意思決定ができ、顧客のニーズにより迅速に対応でき、ノウハウと能力を継続的に向上させることができます。さらに、スケーラブルで適応力のあるアーキテクチャにより、顧客関係管理 (CRM) やエンタープライズリソースプランニング (ERP) プラットフォームなど、既存のシステムとの統合が可能になります。これにより、このソリューションは急速に進化する製薬業界の環境に合わせて俊敏かつ対応力を維持し、市場シェア、収益の拡大、そして総合的な事業の成功をもたらすことができます。 Sales Conciergeの導入初期段階でお客様からは励ましの声が寄せられています。バイオ医薬品業界の有力企業のあるMRは「Sales Conciergeは情報への単一のアクセスポイントを提供してくれるので時間が節約できる」と述べています。他の担当者からも「事前の販売計画のためのきめ細かなコンテキストを提供してくれるので時間が節約できる」、「HCPとのより良いエンゲージメントにつながっている」といった前向きな声が聞かれました。 まとめ このガイダンスに基づいてSales Conciergeを実装することにより、ますます複雑化する製薬業界の状況の中でも営業チームを強化し、革新的なアプローチを取り入れることができます。データ、インサイト、生成AIによる機能を単一のソリューションに統合することで、業務を合理化し、負荷を軽減し、重要な情報へのアクセスを容易にします。包括的なプロファイルとインサイトに基づいてHCPとパーソナライズされたデータドリブンなやり取りができるようになれば、営業チームは卓越した成果を収め、顧客との強固な関係を構築できるようになります。 企業がSales Conciergeを導入すれば、効率性と生産性の新たな基準に到達し、より大きな成功に向けてスタートを切ることができます。このAWSからの革新的なアプローチは、営業の未来を切り開くものであり、顧客とのやり取り方を変革し、成長の機会を生み出します。生産性の向上、エンゲージメントの強化、継続的な学習、商業的成果の改善など、包括的なベネフィットを考えると、製薬企業にとってSales Conciergeは戦略的な投資対象となるでしょう。 Sales Conciergeアプリケーションが、営業チームの生産性向上と、医療従事者とのよりデータに基づいた有意義な関与をどのようにサポートできるかを確認してください。営業チームを強化し、顧客とのやり取りを向上させ、より大きなビジネスインパクトを生み出すための第一歩を踏み出しましょう。 AWSライフサイエンス担当者 に連絡して、ビジネスの加速化にどのようにお役立てできるかご相談ください。 参考情報 AWSのソリューション支援について、さらに学習を深めるためのリソースをご覧ください。 AWSのQnABot – 複数のチャネル(コンタクトセンターやソーシャルメディアなど)で、より高度で魅力的な会話型AIエクスペリエンスを素早く作成 React ネイティブアプリに Amazon Bedrock チャット機能を追加する Amazon Bedrock Knowledge Basesを使用してスケーラブル、セキュア、信頼性の高いRAGアプリケーションを構築する Amazon Bedrock Agents Amazon Bedrock Prompt Flows TAGS: customer engagement , life sciences Chris Kaspar Chris Kaspar は AWS のプリンシパルソリューションアーキテクトであり、ヘルスケアとライフサイエンスのお客様が安全でスケーラブルで革新的なソリューションを構築できるよう支援する責任があります。Chrisは、情報技術分野で20以上の資格を持つ電気・電子エンジニアです。20年以上ITに携わってきた彼は、そのうち18年間をヘルスケア部門で過ごし、世界的に認められたメイヨークリニックで16年間という長い在職期間を過ごしました。AWS では、Chris はグローバルヘルスケアおよびライフサイエンスイニシアチブを率いており、デジタルヘルス、創薬、臨床開発、ヘルスケア IT、ケア管理、ガバナンス、クラウド運用など、さまざまな分野でテクニカルアドバイザーおよびアーキテクトの役割を果たしています。 Aman Chhina Aman Chhina は、AWS のヘルスケアおよびライフサイエンス分野のグローバルアカウントマネージャーです。ライフサイエンス業界で15年以上にわたり、戦略、事業開発、コンサルティングに携わってきました。彼は、ライフサイエンスのクライアントチームが、利害関係者、そしてさらに重要なのは患者にとって有意義なビジネス成果をもたらすために、デジタル対応の変革を構想して実現するのを支援しています。 Atul Tannan Atul Tannan は AWS のグローバルアカウントマネージャーで、ライフサイエンス全体のデジタルトランスフォーメーションを専門としています。ライフサイエンス企業やCPG企業と提携して、テクノロジーを通じて企業の最大の課題を解決してきた15年以上の経験があります。彼の専門分野は、デジタルトランスフォーメーション戦略、オムニチャネルエンゲージメント、データ分析、AIの運用、サプライチェーンの近代化に及びます。 Somdeb Bhattacharjee Somdeb Bhattacharjeeは、データと分析を専門とするシニアソリューションアーキテクトです。彼は AWS のグローバルなヘルスケアおよびライフサイエンス業界の一員であり、顧客がデータプラットフォームソリューションをモダナイズしてビジネス成果を達成できるよう支援しています。 Subrato Majumdar Subrato は、AWS のヘルスケアおよびライフサイエンス事業部門の商用ソリューションと戦略を率いています。ライフサイエンス業界で20年以上コンサルティングを行ってきた彼は、臨床、医療、商業の各部門で顧客を支援してきました。彼が現在注力しているのは、オムニチャネル市場戦略を通じて、AIを適用して医療従事者と患者の顧客体験を変革することです。 このブログは、Senior Solutions Architectの松永が翻訳しました。
2024 年 11 月 8 日、 Amazon Location Service  は、 Routes 、 Places 、 Maps  機能の拡張と改善を可能にする 17 の新しい API と強化された API をリリースしました。これにより、開発者はより一貫性のある効率的な体験を得ることができます。これらの更新により、機能が強化され、移行が簡単になり、Amazon Location Service は、幅広いアプリケーションでより利用しやすく、便利なものになりました。 高度なルート最適化、通行料金の計算、GPSトレースのスナップ、静的および動的レンダリングオプションを備えたさまざまなマップスタイルにアクセスでき、また、興味のある場所に関する豊富な詳細情報を利用して、近接検索や予測提案ができるようになりました。 Amazon では、ロードマップの大部分はお客様からのフィードバックによって決定されています。Amazon Location Service を使用してアプリケーションを構築している多くのお客様から、位置情報データを使用する際に、専用に設計された API や、連絡先情報や営業時間などのより詳細な情報が必要であると意見が寄せられています。現行の API セットは多くのお客様にとって貴重なツールを提供してきましたが、開発者からは、詳細なルート計画、近傍検索、追加の場所の詳細情報、静的な地図画像などの追加機能に対する要望が寄せられています。これらの新しい API は、要望に応え、より包括的で、すぐに使える位置情報ソリューションを提供します。 新しい機能と強化された機能 本日発表されたのは、お客様のフィードバックに直接応える 10 の更新された API と 7 つのまったく新しい API です。 Routes、Places、Maps の各サービスは、より幅広い用途に対応できるよう、特定の機能強化が施されています。 Routes Amazon Location Routes API は、高度なルート計画とカスタマイズオプションをサポートするようになりました。これにより、ユーザーは以下を行うことができます。 CalculateIsolines  を利用することで、指定した移動時間または距離のエリアを特定可能 OptimizeWaypoints  を利用することで、最も効率的な経由地の順序を決定し、移動時間または距離を最小化 有料道路を含むルートについて、正確な料金を算出できます SnapToRoads  を使用して、道路ネットワークにポイントをスナップすることで、GPSトレースを正確に一致させることが可能 これらの機能により、より正確でダイナミックなルート体験をユーザーに提供できるようになります。例えば、物流会社は、リアルタイムの交通状況を考慮して配送ドライバーのルートを最適化し、配送にかかる移動コストを最小限に抑えることができます。 Maps 更新された Amazon Location Maps API には、熟練した地図製作者が作成した、より用途に特化した地図スタイルが追加されています。これらの地図スタイルは、市場投入までの時間を短縮し、カスタム地図の作成を不要にするプロフェッショナルなデザインを提供します。さらに、Static Map Image 機能により、開発者は静的地図をアプリケーションに統合することができ、継続的なデータストリーミングの必要性を減らし、インタラクティブ性が不要な使用事例におけるパフォーマンスを向上させます。 Maps API の主な機能には、以下のものがあります。 GetTile : 指定した X、Y、Z 座標の値を使用し、タイルセットからタイルをダウンロードする GetStyleDescriptor : スタイルに関する情報を取得する GetStaticMap : レポートや視覚化を目的とした非インタラクティブなマップのレンダリングを可能にする Places Amazon Location Places API の機能強化により、より詳細な検索機能が可能になり、位置データの精度向上に関する要望に対応できるようになりました。 新機能には、以下のものが含まれます。 SearchNearby  および  Autocomplete  近傍検索クエリをサポートし、予測テキスト機能によりユーザーエクスペリエンスを向上 営業時間、連絡先情報、その他の興味のある場所の属性などのカテゴリーによるビジネス詳細情報の強化 これらの機能は、ユーザーが近隣の場所に関する詳細な情報を必要とするアプリケーション、例えばフードデリバリーサービスや小売アプリケーションなどに特に役立ちます。お客様がフードデリバリーアプリケーションを開き、 SearchNearby  を使用して近くのレストランを検索し、営業時間や連絡先などのレストランの詳細情報を取得して利用可能かどうかを確認するとします。 複数のデリバリー注文がドライバーに割り当てられると、アプリケーションは OptimizeWaypoints を使用して、ピックアップと配送に最も効率的なルートを提案します。 ドライバーがルートに従うと、 SnaptoRoads  がドライバーの位置を正確に視覚化し、お客様のリアルタイムの追跡体験を向上させます。 拡張ロケーションサービスの利用例 API の呼び出しは簡単です。 AWS コマンドラインインターフェイス(AWS CLI) 、 AWS SDK  の、またはシンプルな REST API を使用できます。ただし、ウェブアプリやモバイルアプリでマップ上に情報を表示するには、追加の設定が必要です。このプロセスはドキュメントに記載があるので、今回は詳細には触れず、API の使用に焦点を当てます。 Amazon Location Serviceでは、2 つの方法による API コールの認証方法が提供されています。AWS API 認証( AWS Sigv4 認証 )または API キーを使用する方法です。エンドユーザーが認証されていないモバイルアプリケーションの開発や、 Amazon Cognito  との統合が不可能な場合、API キーの方が便利な場合があります。これは、フロントエンドアプリケーション向けの推奨される認証方法です。 API の汎用性と、アプリケーションへの統合がどれほど簡単かをお見せするために、デモの各ステップでは AWS CLI、cURL、グラフィカルな REST API クライアントを組み合わせて使用します。 ステップ1:APIキーの作成 まず、AWS CLI を使用してアプリケーション用の API キーを作成します。API キーは、 AWS マネジメントコンソール でも管理できます。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドにより API キーが生成され、これで Amazon Location API を呼び出すことができるようになりました。 ステップ2:地理座標の取得 次に、 curl コマンド  を使用して  GeoCode  を呼び出し、 QueryText  パラメータに住所を渡すことで、フランスのリール市の中心部の地理座標( 経度 および 緯度 )を取得します。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これは、市街地の GPS 座標 ([3.06361, 50.63706]) を含む複数のデータポイントを返します。 ステップ3:近隣の場所を検索 取得した座標を使用して、REST API クライアントツールで  SearchNearby  APIを呼び出し、リール市街地の近隣の観光スポットを検索します。 画面の右側には、API レスポンスとして、レストラン、銀行、駐車場など、近隣の場所のリストが表示されます。さらに、カテゴリーを指定したり、検索するエリアを制限したりして、検索を絞り込むことができます。 SearchNearby API では、オプションの  Filter  パラメータを受け付け、このパラメータを使用すると、検索を境界ボックス内に制限したり、企業グループ、カテゴリー、国、または食品の種類を含めたり除外したりすることができます。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近隣の観光スポットを検索したところ、検索結果の 1 つとして、国際的に有名なマクドナルド が返されました。 ステップ4: 運転ルートを取得 最後に、AWS CLI を使用して、ベルギーの ブリュッセル とフランスの リール という 2  つの都市の中心地間の運転ルートを計算します。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" 応答には、地図上に経路を表示するための ポリライン と、段階的な運転指示のリストが含まれています。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ5:地図上にルートを表示する 地図上にルートを表示するために、私は  MapLibre  ライブラリを使用しています。これは、ウェブやモバイルアプリケーションで地図を表示するためのレンダリングエンジンです。 Amazon Location Service Developer Guide  に従って、ルートを表示する基本的なアプリを作成しました。 MapLibre  に加えて、 AWS Amplify  を使用してAmazon Location データをアプリケーションに統合し、表示することもできます。 開始方法 これらの新しい API および更新された API により、Amazon Location Service はお客様のビジネスニーズに合わせたより包括的なマッピングおよび位置情報データスイートを提供します。これらの機能は、開発者の機敏性と拡張性を高めることで、お客様の開発ライフサイクルを加速します。 まずは、更新された Amazon Location Service 開発者ガイド を参照し、これらの機能の統合を今日から開始してください。また、 Amazon Location Service ページ にアクセスして詳細を確認したり、お好みの  AWS SDK  で API を試用して、アプリケーションの強化方法を確認することもできます。 — seb 本記事は「 Announcing new APIs for Amazon Location Service Routes, Places, and Maps 」を翻訳したものです。 著者について Sébastien Stormacq セバスチャンは、1980年代半ばに初めてコモドール64に触れて以来、コードを書き続けている。情熱、熱意、お客様擁護、好奇心、創造性を秘伝のブレンドで駆使し、AWSクラウドの価値を引き出すよう開発者を鼓舞している。関心のある分野は、ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティング。彼に何かを売り込みたい場合は、API 付きであることを確認すること。X で @sebstoでフォローしましょう。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
このブログは 2024 年 10 月 21 日に Durga Prasad Katrapally によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 データレイク、機械学習 (ML)、分析を使用する企業には、スケーラブルなデータストレージが必要です。ただし、保存されているすべてのデータに同じようにアクセスするわけではありません。データの中には頻繁にアクセスされる部分もあれば、ほとんどアクセスされないデータ部分もあります。最新のクラウドストレージでは、使用頻度の低いコールドデータを低コストのストレージクラスに移動できます。これにより、ユーザーは頻繁にアクセスされないデータのストレージにかかる費用を節約できます。データ量が増えるにつれて、アクセスパターンを追跡し、データを適切なストレージクラスに移動してコストメリットを最大限に引き出すことが難しくなります。企業はストレージ階層を活用したコスト削減を最大化するために、データ使用量とストレージコストを注視する必要があります。 Amazon S3 は、パフォーマンス、アクセス、耐障害性、コストなどの異なるニーズを満たすさまざまなストレージクラスを提供するオブジェクトストレージサービスです。 S3 ライフサイクル および Amazon S3 Intelligent-Tiering ストレージクラスを使用すると、異なるストレージクラスまたは階層間でデータを自動的に移行してコストを最適化できます。ただし、完全なコスト削減を実現するには、まず実際のアクセスパターンを理解する必要があります。S3 Standard ストレージクラスにデータを保存すると、頻繁にアクセスされるデータとあまりアクセスされないデータで同じストレージコストが発生するため、節約できる可能性は限定的です。アクセスパターンの予測が可能か不可能かを考慮せずに S3 ライフサイクルポリシーや S3 Intelligent-Tiering を使用すると、オブジェクトが最小期間より前に削除された場合に取り出し料金や早期削除料金が高くなったり、より安価なストレージへの移行が遅れて、節約の機会を逃したりする可能性があります。 この記事では、 S3 ストレージクラス分析 を使用してアクセスパターンを分析し、データを別のストレージクラスに移行するタイミングを決定するのに役立つ情報を提供します。S3 ストレージクラス分析では、一定期間にわたってフィルタリングされたデータセットのアクセスパターンを観察し、その結果に基づいて、予測可能なデータアクセスパターンには S3 ライフサイクルポリシー、予測不可能なアクセスパターンには S3 Intelligent-Tiering ストレージクラスというように、適切な選択を行うことができます。このソリューションでは、ストレージアクセスパターンを分析し、異なるストレージクラスと階層を最大限に活用することで、ストレージコストを最適化することができます。 ソリューションの説明 このアプローチは 3 つのフェーズに分かれています。 有効化 : 特定のバケットで S3 ストレージクラス分析レポートを有効にします。このフェーズが終了すると、S3 ストレージクラス分析レポートが、設定時に指定した Amazon S3 のパスに配信されます。 分析 : 毎日更新される S3 ストレージクラスの分析レポートを分析します。このフェーズの終了時には、バケットのワークロードパターンが予測可能または予測不可能のいずれかで描画されます。 アクション : アクセスパターンの明確な指標を基に、分析フェーズの結果に基づいてアクションをします。 注意 : S3 ストレージクラスの分析は、 Amazon S3 の料金ページ に記載されているように、有料機能であり、オブジェクトごとに課金されます。 1. 有効化 このフェーズに進む前に、この ブログ記事 では、 S3 Storage Lens を使用してコスト最適化に適した大きなバケットを特定し、ターゲットにする方法を説明します。この記事のポイントは、S3 Storage Lens を使用して特定したバケットで S3 ストレージクラスの分析レポートを有効にすることです。 S3 Storage Lens は、お客様のすべての S3 バケットにわたる S3 の使用状況とアクティビティのメトリクスを組織全体で高レベルに表示します。最適化の機会を見つけ出し、ベストプラクティスを導入するのに役立ちます。ストレージクラス分析では、通常はペタバイトレベルの特定の大規模 S3 バケットのストレージアクセスパターン、オブジェクトの保存期間分布、移行の機会をモニタリングすることができます。これにより、個々の高いインパクトがあるバケットの正確なライフサイクル管理とコスト最適化が可能になります。 S3ストレージクラス分析レポートは、2つの形式で利用できます。S3バケットのメトリクスタブの分析機能として直接表示する方法と、カンマ区切り(CSV)形式で別のS3バケットにエクスポートする方法です。 この記事では、後者の形式、つまりCSV形式での分析に関する推奨事項に焦点を当てます。CSV形式のレポートでは、日付をドリルダウンして詳細に分析できるのに対し、メトリクスタブでは一定期間のメトリクスを適切に表示できます。 S3 ストレージクラスの分析レポートを有効にする Amazon S3 コンソール で、バケットを選択し、分析するバケットを選択し、メトリクスタブを選択します( 図 1 参照)。 図 1:S3ストレージクラスの分析レポートの作成 ストレージクラス分析 に移動し、Create configurationをクリックします。 図 2:ストレージクラス分析レポートの設定を作成 Create Configuration をクリックした後、設定の詳細を入力します。 名前 にある S3 Storage Class Analysis レポートの 設定名 を入力します。 設定スコープ では、レポートの適用範囲を指定します。特定のプレフィックスに対しては 1 つ以上のフィルターを使用してこのルールのスコープを制限する を、バケット全体に対しては バケット内のすべてのオブジェクトに適用 を選択します。 CSV をエクスポート では、レポートのフォーマットを選択し、CSV をエクスポートの下で 有効にする にチェックを入れます。 送信先バケット のアカウント選択では、 このアカウント または 別のアカウント を選択します。 送信先 で、 図 3 のようにレポートをリダイレクトする 宛先バケット を選択します。 図 3:S3ストレージクラスの分析レポート有効化 S3ストレージクラス分析レポートの設定が完了したら、S3コンソールでフィルタに基づくデータ分析の監視を 24-48 時間後に開始します。ただし、S3 ストレージクラス分析では、結果を出す前に分析用の情報を収集するために、フィルタリングされたデータセットのアクセスパターンを30 日以上モニタリングします。アクセスパターンが変化するにつれて、最初の推奨事項が出された後も分析は継続され、更新されます。 S3 ストレージクラス分析レポートからの推奨事項は、 S3 Standard-Infrequent Access (S3 Standard-IA) への移行のみ を示します。しかし、検出されたパターンを使用して、既知または未知のパターンを導き出すことができます。既知および未知のパターンの例については、次のフェーズで説明します。 このフェーズの終了時には、設定を作成した際に指定した Amazon S3 バケットに S3 ストレージクラス分析レポートが送信されているはずです。 2. 分析 このフェーズでは、毎日更新される S3 ストレージクラスの分析レポートの分析に重点を置きます。有効化すると、各日付に対して複数のエントリが作成されます。 以下はサンプルレポートの例です。 図 4:複数のエントリーを含む S3 ストレージクラス分析レポートのサンプル S3 ユーザーガイド には、分析に使用される ObjectAge、Storage_MB、DataRetrieved_MB、GetRequestCount など、各カラムの説明が記載されています。 分析の開始点として、 図 5 に示されているように、レポートの最新の日付でフィルタリングすることが有効です。 図 5:日付を 1 つ指定してフィルタリングした S3 ストレージクラス分析レポートのサンプル パターンを導き出すために注目すると良い列には、Object Age、Storage_MB、DataRetrieved_MB、GetRequestCountなどがあります。 予測可能なワークロードの例 このセクションでは、 図 6 に示されているような予測可能な作業負荷パターンに関する S3 ストレージクラス分析レポートの例を紹介します。 図6:予測可能なパターンを持つ S3 ストレージクラス分析レポートのサンプル ObjectAge 列にはバケットに配置された経過時間のリストが表示され、例えば 000-014 は 0 日から 14 日の間のオブジェクト、015-029 は 15 日から 29 日の間のオブジェクトであることを意味します。 Storage_MB はバケットに配置された ObjectAge における総ストレージ容量を示します。例えば、000-014 日経過のオブジェクトの総使用ストレージ容量は 277847 MB、015-029 日経過のオブジェクトの総使用ストレージ容量は 290350 MB などです。 GetRequestCount は、バケットに配置された経過時間のグループ (ObjectAge のグループ) に送信された API コールの総数です。この例では、000-014 日のオブジェクトには約 12369 件の API コールがあり、その他の ObjectAge グループには API コールはありません。 DataRetrieved_MB Data は、ObjectAge グループにおけるその日の GET リクエストによるストレージクラスごとの転送データ量(MB)です。ObjectAge=’ALL’ の場合、その日のすべての ObjectAge グループに対する GET リクエストによる転送データ量(MB)の合計値となります。 分析をすると、前掲のレポート( 図 6 )からパターンが予測できることが分かります。0-14 日経過したオブジェクトは活発に使用されていますが、それ以降は他の経過日数のオブジェクトに対する API リクエストはありません。したがって、S3 ライフサイクルポリシーを使用して、ほとんどアクセスされないデータを 15日 経過後に S3 Glacier ストレージクラス に移動することができます。 予測不可能なワークロードの例 ここでは、予測不可能なパターンに関する S3 ストレージクラス分析レポートの例を見てみましょう。 次の S3 ストレージクラス分析レポート( 図 7 )は、最初の 30 日間にアクティブなアクセスがあります。次の 30 日間(つまり 30 日から 59 日まで)はアクティブなアクセスがなく、60 日から 119 日まで再びアクセスされ、120 日から 179 日まではアクセスリクエストがありません。ここには予測性はありません。古いデータの一部は依然としてアクセスされている一方で、まったくアクセスされない部分もあります。このシナリオでは、アクティブにアクセスされる部分と、アクセス頻度が低い部分の両方に対して、S3 Standard の料金を支払うことになるでしょう。 このバケットは、S3 Intelligent-Tiering に適しています。アクセスされないコールドな部分を、30日または90日後に自動的に低頻度アクセス階層またはアーカイブインスタントアクセス階層に移動させるからです。 図 7:予測不可能なパターンを含むS3ストレージクラス分析レポートのサンプル この分析では、特定の日のパターンを確認しました。一般的には、例えば 1 か月間といった一定期間のパターンを観察し、アクセス・パターンに関する結論を出します。このフェーズの終了時には、バケットワークロードのパターンは、予測可能なものと予測不可能なもののどちらかとして分類されます。 3. アクション 最後のフェーズでは、アクセスパターンを明確に示しながら、分析フェーズの結果に基づいてアクションをします。 予測可能なパターンに対するアクション 予測可能なパターンについては、S3 ライフサイクルポリシーを有効にして、アクセス頻度の低いデータを S3 Glacierストレージクラスに移動することで、最大限のコスト削減を実現できます。 S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive のどれを選択するのかは、バケットのビジネス上のユースケースにより異なります。 データがミリ秒単位の検索パフォーマンスで利用可能であり、四半期に 1 回アクセスされる必要がある場合は、S3 Glacier Instant Retrieval が適しています。 データが非同期で数分から数時間でアクセス可能であり、半年に 1 回アクセスされる場合は、S3 Glacier Flexible Retrieval が適しています。24-48時間以内にデータが利用可能になり、毎年定時にアクセスされるというユースケースであれば、S3 Glacier Deep Archive が適しています。 S3 ライフサイクルポリシーを通じてデータを移動する際には、一時的な移行料金が発生し、アクセス時にはデータ取り出し料金が発生します。以下の表は、米国東部(バージニア北部) AWSリージョン の料金をまとめたものです。 移行先 S3 ライフサイクルでの移行リクエスト数 (1,000 リクエストあたり) データ取り出しリクエスト (1,000 リクエストあたり) データ取り出し(GB あたり) S3 Intelligent-Tiering $0.01 n/a n/a S3 Standard-IA $0.01 n/a $0.01 S3 Glacier Instant Retrieval $0.02 n/a $0.03 S3 Glacier Flexible Retrieval $0.03 $10.00 Expedited $0.03 $0.05 Standard $0.01 n/a Bulk n/a S3 Glacier Deep Archive $0.05 $0.10 Standard $0.02 $0.025 Bulk $0.0025 表 1:米国東部(バージニア北部)リージョンの移行費用 一時的な料金を計算するには、移行するコールドオブジェクトの総数が必要です。移行料金は1000オブジェクト単位であり、サイズによる料金設定ではないからです。 一時的な料金の計算 ここでは、パターンが予測可能な 図 6 と同じ例を使用します。現在のストレージでは、データのコールド部分(バケットに配置されて15日を越えるグループの合計)は約 6.31 TB です。これは、約 6.31 TB が 100 万のオブジェクトであり、ユーザーは 24-48 時間データ取得を待つことができると仮定しています。コールド部分は、S3 Glacier Deep Archive に移動できます。 S3 Standard から S3 Glacier Deep Archive にデータを移行する際には、1000 オブジェクトあたり $0.05 の一時的な移行料金が発生します( 表 1 )。 100 万個のオブジェクトの場合、移行料金は(1,000,000/1000)*0.05、つまり $50 となります。 この移行について考慮すべき重要な要素は、オブジェクトのサイズです。移行料金はオブジェクトの数に基づいており、サイズに基づいていないため、オブジェクトが大きければ大きいほど、ストレージの GB あたりの移行コストは低くなります。 例えば、10 TB のデータがあるとします。1 MB の小さなオブジェクトが 1000 万個ある場合、S3 Glacier Deep Archive への移行費用は $500 かかります。一方、10 MB のオブジェクトが 100 万個ある場合、移行費用は $50 です。 節約の効果 例えば、一時的な費用を差し引いた実質的な節約額を計算することができます。 図 6 から、15 日以上経過したオブジェクトのデータはほとんどアクセスされていないことが分かります。 15 日以上経過したオブジェクトを移動する S3 ライフサイクルポリシーにより、合計約 6.40 TB のオブジェクトがより安価なストレージクラスに移動されます。この例では、前述のとおり、S3 Glacier Deep Archive を移行先のストレージクラスとします。 現在のコールドストレージサイズ 現在の S3 Standard 料金 S3 Glacier Deep Archive へ移行する際の一時的な料金 S3 Glacier Deep Archive へ移行後の料金 * 節約効果 節約効果 % 6471 GB $323.55 $50 $6.40 (0.00099*5620) =323.55-$50 =$273.55 84.54% 表 2 : 予測可能なアクセスパターンの節約計算 *$0.00099 は、米国東部(バージニア北部)リージョンにおける S3 Glacier Deep Archive の GB あたりの料金です。 予測不可能なパターンに対するアクション 予測不可能なパターンに対しては、S3 Intelligent-Tiering が費用対効果に優れており、S3 ライフサイクルを使用してデータをS3 Standard ストレージクラスからS3 Intelligent-Tiering ストレージクラスに移行することができます。 S3 Intelligent-Tiering では、オブジェクトのモニタリングに少額の料金がかかります。さらに、128 KB を超えるオブジェクトのみがモニタリングの対象となり、最後にアクセスされた時間に基づいてストレージクラス間で移動されます。128 KB 未満のオブジェクトにはモニタリング料金はかかりません。また、S3 ライフサイクルでは、128 KB 未満のオブジェクトは S3 Intelligent-Tiering に移行されません。 一時的な料金の計算 まず、バケット全体で予測不可能なワークロードがあります。そのため、S3 Standard ストレージクラスのオブジェクトは S3 Intelligent-Tiering ストレージクラスに移行する必要があります。 S3 Standard から S3 Intelligent-Tiering への移行には、1000 オブジェクトあたり $0.01 の移行料金がかかります(表1)。 バケット内に 128 KB 以上のオブジェクトが合計 1000 万個あると仮定すると、 移行料金 は(10,000,000/1000)*$0.01 、つまり $100 となります。 S3 Intelligent-Tieringのモニタリング料金 次に、オブジェクトが S3 Standard ストレージクラスから S3 Intelligent-Tiering ストレージクラスに移動された場合、モニタリング料金が適用されます。 128 KB を超えるサイズのバケットに合計 1000 万のオブジェクトがある場合、そのバケットのモニタリング料金は次のようになります。(10,000,000/1000)*0.0025 = 1 か月あたり $25。 * 米国東部(バージニア北部)リージョンでは、モニタリング料金は 1 か月あたり 1,000 オブジェクトあたり $0.0025 です。 節約の効果 例えば、1 回限りの料金の支払い後にどれほど効果的な節約ができるかを見てみましょう。 図 7 から、30-44 日間、45-59日間、120-149日間、150-179日間の経過時間層のデータはアクセスされていません。 30日後 S3 Intelligent-Tiering がバケット上で有効になっている場合、S3 Intelligent-Tiering に移行してから 30 日後には、合計約5.82 TB がコールドとして識別されます。さらに、30 日後には低頻度アクセス階層に、90 日後にはアーカイブインスタントアクセス階層に移行します。 現在のコールドストレージサイズ 現在のコールドデータ部分に適用された S3 Standard 料金 S3 Intelligent-Tiering ストレージクラスへの移行に伴う一時的な費用 S3 Intelligent-Tieringストレージクラス(低頻度アクセス階層)のコールド部分の30日経過後の課金 節約 節約 % 5820 GB $137 $100 $0.0125*5820 = $72.8 $137-$72.8 = $64.25 46% 表3 : 30 日後の予測不能なパターンの節約額の計算 * $0.0125は、米国東部(バージニア北部)リージョンにおける 1 GB あたりの低頻度アクセス階層ストレージクラス料金です。 90日後 オブジェクトが低頻度アクセス階層に移動されてから 60 日後、S3 Intelligent-Tiering は移行コストなしで自動的にアクセスがない場合、現在の低頻度アクセス部分をアーカイブインスタントアクセスに移動します。これにより、コールドデータ部分がさらに節約できます。 わかりやすくするために、この例では、 アーカイブインスタントアクセスクラスに移動した低頻度アクセスデータの総量は 5820 GB のみとします。しかし、一般的に S3 Intelligent-Tiering は、新たにインポートされたオブジェクトで 30 日間アクセスがないものをモニタリングし S3 Standard-IA へ、90 日後にアーカイブインスタントアクセスクラスに移動します。 現在の 低頻度アクセス データ 現在の 低頻度アクセス 料金 他のストレージクラスへ移行する一時的な料金 S3 Intelligent-Tieringストレージクラス(アーカイブインスタントアクセス)によるコールドストレージの120日以降の料金 節約 節約 % 5820 GB $64.2 $0 $0.004*5820 = $23.8 $64.2-23.8 = $40.2 62% 表4:90日後の予測不能パターンの節約額計算 考慮すべきその他のツール 予測可能なアクセスパターンまたは予測不可能なアクセスパターンのいずれかで、他のストレージクラスへの移行対象となるオブジェクトの正確な数を把握するには、 Amazon S3 Inventory と Amazon Athena という 2 つの主要なツールが役立ちます。 Amazon S3 Inventory は、S3 バケット内のオブジェクトとそれに対応するメタデータを、日次または週次でリスト化したレポートを、CSV、Apache最適化行列形式(ORC)、またはApache Parquet出力ファイルのいずれかで提供します。Athena は、オープンテーブルおよびファイル形式をサポートするオープンソースフレームワークを基盤としたサーバーレスのインタラクティブな分析サービスです。Athena は Amazon S3 と緊密に統合されており、Amazon S3 インベントリレポートの分析が可能です。 ブログ「 Manage and analyze your data at scale using Amazon S3 Inventory and Amazon Athena 」では、Athena と Amazon S3 インベントリレポートの統合、および Amazon S3 インベントリメタデータに対するクエリについて説明しています。Amazon S3 インベントリレポートにクエリを実行することで、移行対象となる 128 KB を超えるオブジェクトや、一定期間以上経過したオブジェクトなどの洞察を得ることができます。これにより、S3 ライフサイクルアクションの初期費用や、S3 Intelligent-Tiering のモニタリング料金をより正確に算出することができます。 クリーンアップ アクセスパターンが分かったら、Amazon S3 ストレージクラス分析レポートを停止して、課金を停止できます。レポートを停止するには、以下の手順に従います。 Amazon S3 コンソールで、 バケット を選択します。S3 ストレージクラス分析レポートを無効にする必要がある バケット を選択します。 メトリクス タブに移動し、 ストレージクラス分析 を選択します。 図 8 : S3 ストレージクラス分析レポートのクリーンアップ方法 削除するレポートを選択し、 削除 を選択します。 図 9 : ストレージクラス分析レポートの削除 まとめ この記事では、S3 ストレージクラス分析レポートの設定方法と、コストを最適化するために大規模な Amazon S3 バケット全体のアクセスパターンの分析の重要性について説明しました。また、アクセス頻度の低いデータを、S3 ライフサイクルルールや Amazon S3 Intelligent-Tiering を使用して、よりコスト効率の高い Amazon S3 の ストレージクラス に移動することで、大幅なコスト削減を実現できるシナリオも確認しました。さらに、S3 Storage Lens やストレージクラス分析レポートなどのツールを使用して、S3 ライフサイクルポリシーと S3 Intelligent-Tiering のユースケースを紹介しました。また、コスト削減額と移行時の一時的な費用を計算することで、意思決定プロセスを導くこともできました。 Amazon S3 は、ストレージクラスと Intelligent-Tiering のオプションを提供しており、お客様のワークロードとビジネスニーズに基づいてコストを最適化することができます。S3 バケットのアクセスパターンを理解することは、最適化の機会を活用するために極めて重要です。S3 ストレージクラス分析レポートは、お客様のバケットを分析することでアクセスパターンを特定し、データを最も最適なストレージクラスに配置できるようにします。 この記事をお読みいただきありがとうございました。 追加のリソースについては、この 動画「Amazon S3 Storage Class Analysis」 や、その他の関連ストレージブログを参照してください。 Amazon S3 cost optimization for predictable and dynamic access patterns Dialog Axiata saves significantly on storage using Amazon S3 Intelligent-Tiering and S3 Storage Lens How Toyota Connected North America reduced storage costs by optimizing its growing data on Amazon S3 Durga Prasad Katrapally Durga Prasad Katrapally は、AWS のテクニカルアカウントマネージャーであり、多様な領域にわたる 14 年の IT 経験を持つ。戦略的コラボレーションを通じて、お客様の課題解決とクラウドの成功を推進することにやりがいを感じている。AWS プラットフォーム上のソリューション開発に携わり、お客様のニーズを主張し、長期的な成功に向けて積極的に導くことを使命としている。特に生成 AI、データ、ストレージの分野における新興技術の最新情報を入手することに熱心に取り組んでいる。
本稿では、AWS PrivateLink の User Datagram Protocol (UDP) サービスサポートを活用し、デュアルスタック Network Load Balancer (NLB) の UDP サポートにより Internet Protocol version 6 (IPv6) への移行を加速する方法について解説します。2つの新機能の設定手順やユースケース、既存環境に統合するためのベストプラクティスを解説します。 PrivateLink の UDP サポートが追加されたことで、AWS PrivateLink を使用して Amazon Virtual Private Cloud (VPC) を、PrivateLink エンドポイントを通じて公開される UDP ベースのサービスへプライベートに接続できるようになりました。サービスは、複数の VPC に跨る AWS 環境にデプロイでき、またはパートナーや Software as a Service (SaaS) プロバイダーがお客様の AWS アカウントと共有することができます。Transmission Control Protocol (TCP) ベースのサービスにアクセスする際と同様に、UDP ベースの VPC エンドポイントサービスにアクセスするための VPC エンドポイントを作成できるようになりました。 IPv6 導入の加速を支援するため、AWS では現在デュアルスタック NLB の UDP リスナーをサポートしています。これにより、リアルタイムゲームや Voice over IP (VoIP)、メディアストリーミングなどの UDP ベースのアプリケーションへの着信トラフィックを自動的に分散し、高可用性とスケーラビリティを確保することができます。デュアルスタック NLB は、IPv4 / IPv6 両方のクライアントがアプリケーションのエンドポイントにアクセスできるようにし、AWS 上での IPv6 の導入を加速させます。デュアルスタック NLB の UDP サポートにより、TCP リスナーで利用可能な機能 (ヘルスチェック、自動スケーリング、透過的アップグレードなど) を、カスタムロードバランシングソリューションを維持する必要なく利用できます。 前提条件 本稿では、 Amazon VPC や Elastic Load Balancing 、 NLB 、 AWS PrivateLink 、 Amazon CloudWatch など、AWS の基本的なネットワーキング構成に精通していることを前提としています。また、IPv4 や IPv6、TCP、UDP にも精通していることを想定しています。これらのサービスや概念の定義に焦点を当てるのではなく、2つの新機能のユースケースと設定手順を示すために使用します。AWS 上での IPv6 導入リソースの詳細は、AWS re:Postの記事「 Get started with IPv6 on AWS – Resources & Content 」を参照してください。 デュアルスタック NLB と AWS PrivateLink の UDP サポート デュアルスタック NLB の UDP サポートにより、クライアントは IPv4 / IPv6 の両方を使用して UDP サービスに接続できます。この機能を使用するには、デュアルスタック NLB の UDP リスナーに対して IPv6 タイプのターゲットグループを作成する必要があります。NLB は IPv6 を使用して UDP トラフィックをターゲットに送信します。 クライアントは、関連する Fully Qualified Domain Name (FQDN) を解決することで、UDP リスナーを持つデュアルスタック NLB に直接アクセスできます。また、UDP リスナーを持つデュアルスタック NLB を使用して AWS PrivateLink サービス (VPC エンドポイントサービス) を構成することもできます。クライアントは IPv4 または IPv6 を使用して、UDP ベースのサービスにアクセスするために、VPC 内に AWS PrivateLink エンドポイント (VPC エンドポイント) を作成することができます。 図1 は、クライアントが IPv4 または IPv6 を使用して UDP 経由で VPC エンドポイントサービスに接続するアーキテクチャです。NLB はデュアルスタックで、サービス用の UDP リスナーを持っています。サービスプロバイダーのサービスのターゲットグループは、IPv6 を使用する必要があります。クライアントには、IPv4、IPv6、またはデュアルスタック VPC エンドポイントをデプロイし、トラフィックを送信するオプションがあります。クライアントは、VPC エンドポイントに接続することで、UDP ベースのサービスを利用できます。 図1. デュアルスタック UDP NLB クライアントとターゲットの IP 互換性を示すネットワークトポロジー図 デュアルスタック NLB の 送信元 IP アドレスの保持 TCP および TLS リスナー IPv4 クライアントが IPv6 ターゲットを持つデュアルスタック NLB に直接接続する場合、NLB はクライアントの IPv4 アドレスを保持できません。IPv6 が IPv4 との下位互換性を持たないためです。IPv6 ターゲットはクライアントの IPv4 アドレスを処理できないため、NLB はクライアントの IPv4 送信元アドレスを自身の IPv6 アドレスに変換し、ターゲットの IP バージョンに合わせます。 同様に、IPv4 および IPv6 クライアントが VPC エンドポイントに接続する場合、NLB はプロトコルバージョンに関係なく、クライアントの IP アドレスを保持しません。NLB では IP NAT が行われるため、クライアント VPC とサービスプロバイダー VPC 間で IP アドレスが重複していても AWS PrivateLink を使用できます。NAT の結果、ターゲットアプリケーションはクライアントの IP アドレスを認識しません。ターゲットアプリケーションにクライアント IP アドレスを知らせるために、ターゲットグループで Proxy Protocol version 2 (PPv2) を有効にすることができます。これにより、NLB はクライアント IP アドレスを Type-Length-Value (TLV) としてパケットヘッダーに追加できます。この機能は、IPv4 および IPv6 の両方のタイプのターゲットグループで有効にできます。 UDP および TCP_UDP リスナー UDP はコネクションレスプロトコルであるため、デュアルスタック NLB の UDP サポートにおいて送信元 NAT には異なる実装が必要です。TCP と比較して2つの主要な違いがあります。 UDP は TCP と異なりコネクションの概念がないため、ポートを使用して NLB を通過するセッションを追跡することができません。そのため、NLB は IPv6 アドレスを使用して UDP リスナーの各クライアントを一意に識別します。 TCP トラフィックの場合、NLB はコネクションが確立されたときに最初のパケットにのみ PPv2 ヘッダーを追加します。UDP では、コネクションが確立されることはなく、各パケットが独立したものとして扱われます。その結果、UDP ターゲットグループで PPv2 が有効になっている場合、NLB はすべてのパケットに PPv2 ヘッダーを追加します。 デュアルスタック NLB の UDP リスナーと、UDP ベースの VPC エンドポイントサービスの設定手順を見ていきましょう。 デュアルスタック Network Load Balancers の UDP リスナーの設定 始める前に、以下の前提条件を満たしていることを確認してください。 VPC IP 設定の確認 :VPC に IPv6 プレフィックスが関連付けられていることを確認してください。VPC における IPv6 の設定に関する詳細については、 Amazon VPC ユーザーガイド の「 VPC の IPv6 サポートを追加する 」を参照してください。 サブネット IP 設定の確認 :NLB のサブネットはデュアルスタックである必要があります。ターゲットグループのサブネットはデュアルスタックまたは IPv6 のみのいずれかです。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス設定の確認 :各インスタンスにはプライマリ IPv6 アドレスが設定されている必要があります。プライマリ IPv6 アドレスの設定に関する詳細については、 Amazon EC2 ユーザーガイド の「 ネットワークインターフェイスの IP アドレスを管理する 」を参照してください。 NLB と ターゲットのセキュリティグループインバウンドルールの作成 :セキュリティグループのインバウンドルールで、NLB の UDP リスナーとターゲットがトラフィックを受信するように、設定されているポートで UDP を許可する必要があります。 アプリケーションが IPv6 トラフィックを許可していることの確認 :アプリケーションが IPv6 トラフィックを処理でき、IPv6 をサポートするソケットライブラリを使用していることを確認してください。 次の手順は、新規および既存のデュアルスタック NLB に対して UDP リスナーを構成する方法を示しています。 ステップ1 (任意):既存の NLB を変更してデュアルスタックとソース NATを使用する IP アドレスタイプをデュアルスタックに変更するには、既存の UDP および TCP_UDP リスナーを削除し、 図 2 に示すように NLB サブネットがデュアルスタックであることを確認する必要があります。 図2. NLB の IP アドレスタイプを変更する前の要件 既存の NLB の IP アドレスタイプを更新する場合、Amazon EC2 コンソールの ロードバランサー に移動し、対象の NLB を選択します。 図3 のように、 アクション を選択し、 IP アドレスタイプの編集 を選択します。 図3. NLB の IP アドレスタイプを編集 NLB を変更し、 ロードバランサーの IP アドレスタイプ を デュアルスタック に変更する際、 IPv6 ソース NATのプレフィックスを有効にする を オン (サブネットごとのソース NAT プレフィックス) に設定し、 サブネット を選択し、ソース NAT IPv6 アドレスを割り当てます。 図4 に例を示しています。 図4. デュアルスタックに変更し、IPv6 ソース NAT のプレフィックスを有効にし、IPv6 アドレス範囲を設定 ステップ2:新しいデュアルスタック UDP NLB を作成する UDP リスナーを持つ新しいデュアルスタック NLB を作成するには、Amazon EC2 コンソールの ロードバランサー に移動し、 ロードバランサーの作成 を選択します。 Network Load Balancer を選択し、 作成 を選択します。 基本的な設定 で、NLB に一意の名前を付け、スキーム ( 内部 または インターネット向け ) を選択します。 ロードバランサーの IP アドレスタイプ では、 デュアルスタック を選択します。 図5 に例を示しています。 図5. NLB の基本的な設定 ステップ3:NLB サブネットとソース NAT 設定を構成する 図6 に示されているように、NLB をデプロイする VPC を選択してください。 図6. NLB の VPC を選択 図7 に示すように、 IPv6 ソース NATのプレフィックスを有効にする を オン に設定します。 図7. IPv6 ソース NATのプレフィックスを有効化 図8 に示すように、ソース NAT IPv6 プレフィックスの割り当て方法を選択してください。 図8. ソース NAT IPv6 プレフィックスオプション NLB の アベイラビリティゾーンのマッピング 、 サブネット 、 セキュリティグループ を選択し、設定を確認して ロードバランサーの作成 を選択してください。 ステップ4:Amazon EC2 インスタンスをターゲットとして登録する 前提条件にて、プライマリ IPv6 アドレスを持つように IPv6 ターゲットを登録することを言及しました。 図9 に示すように、IPv6 ターゲットをターゲットグループに登録するために必要となります。 図9. ターゲットグループへのターゲットの登録 ステップ5:UDP リスナーを設定する リスナーの プロトコル を UDP または TCP_UDP に設定し、リスナーの ポート を選択する必要があります。図の例では、UDP とポート 53 を選択しています。ターゲットグループの IP アドレスタイプ の値は IPv6 に設定する必要があります。ターゲットグループの IP アドレスタイプ を確認するには、Amazon EC2 コンソールの ターゲットグループ を参照してください。ターゲットグループの IP アドレスタイプは作成後に変更できません。 図10 は、上記例における IPv6 ターゲットグループの UDP リスナー設定を示しています。 図10. NLB のリスナーとルーティング AWS PrivateLink を使用している場合は、以下の手順に進んでください。 デュアルスタック UDP の AWS PrivateLink サービスを作成する AWS PrivateLink サービスを作成する (サービスプロバイダー側) サービスプロバイダーであれば、AWS PrivateLink を使用して UDP サービスをクライアントと共有できるようになりました。サービスプロバイダーには、組織内のチームや Independent Software Vendors (ISV) などのパートナー、規制当局などの関連組織が含まれます。 1 つの手順だけで、VPC エンドポイントサービスを作成できます。Amazon VPC コンソールの エンドポイントサービス に移動し、 図11 に示すように エンドポイントサービスの作成 を選択します。 図11. VPC エンドポイントサービスの作成 図12 に示すように、以下のオプションを設定してください。 (任意) エンドポイントサービスに 名前 を付けます。 ロードバランサーの種類 を ネットワーク に選択します。 前もって設定した UDP リスナーを持つ NLB を選択します。 (任意) 承認が必要 を選択します。この設定の詳細については、 AWS PrivateLink ユーザーガイド の 接続リクエストを承諾または拒否する を参照してください。 (任意) プライベート DNS 名を有効化 を有効にします。エンドポイントサービスのプライベート DNS 名の詳細については、AWS PrivateLink ユーザーガイドの VPC エンドポイントサービス DNS の名前を管理する を参照してください。 VPC エンドポイントサービスが提供する IP アドレスタイプ を選択します。今回の例では、クライアントが IPv4 や IPv6、またはデュアルスタックの VPC エンドポイントを作成できるように、IPv4 と IPv6 の両方を選択します。 (任意) エンドポイントサービスに タグ を設定します。 図12. VPC エンドポイントサービスの設定オプション UDP の AWS PrivateLink エンドポイントを作成する (クライアント側) AWS PrivateLink サービスにアクセスするには、クライアント VPC に VPC エンドポイントを作成する必要があります。このセクションでは、本記事の構成前提条件セクションでネットワーク構成手順に従ったことを前提としています。 ステップ1:サービスプロバイダーがサポートしている IP バージョンを特定する VPC エンドポイントで IPv6 を有効にするには、サービスが SupportedIpAddressType として IPv6 を持っている必要があります。サービスが IPv6 をサポートしているかどうかは、以下のコマンドを実行して確認できます。レスポンスの中で、 SupportedIpAddressTypes が VPC エンドポイントサービスで有効になっている IP バージョンを示します。 aws ec2 describe-vpc-endpoint-services \ --service-names < service-name > Bash ステップ2:AWS PrivateLink エンドポイントを作成する VPC エンドポイントを作成するには、 図13 に示すように、以下の設定を行います。 (任意) VPC エンドポイントに 名前タグ を付けます。 適切な VPC エンドポイントサービスを サービス名 として選択します。 VPC エンドポイントをデプロイする VPC を選択します。IPv4、IPv6、またはデュアルスタックのエンドポイントを設定することができます。この設定は VPC エンドポイントサービスの SupportedIpAddressTypes 値とクライアントの機能に依存します。 (任意) 追加設定 で、 DNS 名を有効化 を有効にすることができます。この設定の詳細については、AWS PrivateLink ユーザーガイドの プライベートDNS名を有効にする を参照してください。 VPC エンドポイントの サブネット と セキュリティグループ を選択します。 図13. VPC エンドポイントを作成 新しく作成されたエンドポイント接続は、VPC エンドポイントサービスに対して承認が必要な場合、AWS PrivateLink サービスプロバイダーによって承認される必要があります。 Amazon CloudWatch を使用して UDP ベースのサービスを監視する この設定を完了すると、カスタマーは UDP ベースのサービスにトラフィックを送信できるようになります。サービスプロバイダーは、以下のような Amazon CloudWatch メトリクスを使用して、健全性とパフォーマンスを監視できます。 NewConnectionCount:NLB を通過する新しい UDP フローの数を測定します。 PacketsOutToTarget:NLB から登録されたターゲットに送信された UDP パケットの数を測定します。 HealthyHostCount:ターゲットグループ内の健全なターゲット数を測定します。 これらの CloudWatch メトリクスは、UDP ベースのサービスが期待通りにトラフィックを処理していることを確認し、潜在的な問題を特定するのに役立ちます。詳細については、AWS PrivateLink ユーザーガイド AWS PrivateLink の CloudWatch メトリクス を参照してください。 考慮事項 デュアルスタック UDP NLB は既存の機能を維持します。多数の NLB を持つ 1 つの VPC エンドポイントサービスをサポートします。これにはオンプレミスのターゲットにトラフィックを送信する機能も含まれます。UDP リスナーを持つデュアルスタック NLB を提供する VPC エンドポイントサービスは、エンドポイントポリシー、プライベート DNS 名、セキュリティグループをサポートします。UDP サポートのリリースでも、AWS PrivateLink のスループット、サービスクォータ、送信元 IP の保持は変更ありません。 まとめ 本稿では、UDP サービスで AWS PrivateLink のサポートを活用する方法と、デュアルスタック NLB の UDP サポートを使用して IPv6 への移行を加速する方法について説明しました。2つの新機能の設定手順、ユースケース、既存の環境に2つの新機能を統合するためのベストプラクティスを概説しました。これらの機能は、IPv6 の採用と UDP ベースのサービスの AWS への移行を加速し、リアルタイムゲーム、Voice over IP (VoIP)、メディアストリーミングなどの UDP ベースのアプリケーションへのインバウンドトラフィックを自動的に分散するのに役立ちます。デュアルスタック NLB の UDP サポートにより、カスタムロードバランシングソリューションを維持する必要なく、ヘルスチェック、自動スケーリング、透過的なアップグレードなど、TCP リスナーで利用可能な同じ機能の恩恵を受けることができます。 VPC コンソール のエンドポイントサービスとエンドポイントのオプションを使用して、AWS PrivateLink の使用を開始してください。詳細については、 AWS PrivateLink および VPC エンドポイント のユーザーガイドを参照してください。 本稿は、2024年10月31日に Networking & Content Delivery で公開された “ Accelerate IPv6 application migration with AWS PrivateLink and dual stack Network Load Balancers UDP support ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。
本ブログは 株式会社アーベルソフト様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの文珠です。 昨今、様々なお客様と会話している中で、今まで 自社開発で提供していた機械学習モデルから、サードパーティ製の生成 AI モデルに置き換えるケース が増えてきていると感じています。生成 AI モデルへの置き換えにより、精度向上やコスト削減だけではなく、新しいユースケースへの対応も可能となります。実際に AWS の生成 AI サービスを活用して、自社プロダクトのユースケースを拡大されているお客様は多くおられます。 本記事で紹介させていただく 株式会社アーベルソフト 様も、画像認識を行う機械学習モデルを開発し、自社サービスに組み込んでいました。アーベルソフト様はこちらの機械学習モデルを AWS の生成 AI サービスである Amazon Bedrock に置き換えることで、 精度を上げながらコストも削減し、自社プロダクトを新たなユースケースに対応させる検討 もすることができました。 アーベルソフト様の状況と経緯 アーベルソフト様は、災害写真情報サービス「 ビューちゃんねる(防災 DX) 」を開発しており、複数の自治体に向けてサービスを提供しております。 本サービスは、ほぼリアルタイムに地域の道路状況や河川状況を把握するソリューションとなっており、地域・自治体の方々に有益な情報を日々提供しております。例えば、大雨の日などに水害情報を遠隔で確認し、災害対策に用いることができます。 (出展: 株式会社アーベルソフト) サービスで提供される画像は電柱に取り付けられた IP カメラで取得され、数分おきに LTE 回線経由でイメージサーバーに送られています。イメージサーバーでは、プライバシーに配慮するための画像加工を行っており、保存した画像は後から閲覧することが可能です。 自社で開発した画像認識モデルを用いて、冠水を自動判定する Web サービスも提供しております。増水によって、水位があらかじめ設定した閾値を超えたと判断された場合には、通知を受け取ることができます。 (出展: 株式会社アーベルソフト) 本サービスを運用している中で、機械学習モデルの作成に必要な「 学習用のデータ収集 」や「 専門知識の獲得 」にかかる時間は大きな課題でした。本ユースケースの学習用データは災害時の画像データであり、データ収集に時間がかかりました。また、集めた画像データを用いてモデルの精度を上げるためにも、機械学習に関する専門的な知識が必要であり、独学での習得には時間がかかりました。機械学習モデルは一度作成したら終わりではなく、モデルの精度改善を行うために繰り返し学習を行う必要があるので、これらの作業が日々の開発工数を圧迫している状況でした。 ソリューション/構成内容 アーベルソフト様は上記の課題に対して、生成 AI サービスを用いた解決の検討を行いました。様々な生成 AI サービスがある中で「 複数のモデルを簡単に切り替られること 」や「 本番環境にすぐ活用できること 」を評価して、Amazon Bedrock を採用いたしました。本ユースケースでは、画像を入力値とするために Anthropic 社のマルチモーダルモデルである Claude 3.5 Sonnet (検証時の最新モデル) を選択して、検証を行いました。検証当初、工夫をせずに生成 AI を利用すると誤検知が頻繁に発生することがわかり、IP カメラの設置箇所ごとに生成 AI に対する命令(プロンプト)を作成することを考えました。具体的にはカメラの画角や写っているオブジェクトを見て、増水の判断をする材料だけ抽出するようなプロンプトを作成しました。生成 AI からのレスポンスも状況の説明をする文章を返すのではなく、結果ごとに比較が可能なスコアを JSON 形式で返すことで、より微細に現在の災害状況のトレンドを把握できるようにしました。 プロンプトの工夫以外にも、前段のイメージサーバーにて、画像から増水の判断に不要な部分を削除するプログラムを実装しました。また、誤検知への対策として、生成 AI が複数回連続で閾値を超えたと判断した際に、ユーザーへ通知を行うように実装しております。この判断に使う回数は増水の深刻度にあわせて可変な値とすることで、緊急度にあわせた対応ができるようになっています。通知機能は既存のサービスから利用できていたメールの他に、LINE のインターフェイスからも利用できるように再設計を行い、ユーザーエクスペリエンスの向上にも努めました。 自社開発モデルの代わりとして Amazon Bedrock を活用することで、精度を向上させることは勿論のこと、自社モデル開発の必要性がなくなり、開発・運用コストを大幅に削減できました。さらに、本対応で培った経験を生かして、水害以外の「交通事故」や「火災」などのユースケースにも対応できるように、現在検証・開発を進めております。 (出展: 株式会社アーベルソフト) 導入効果 Amazon Bedrock を導入することで、下記の3つの効果を得ることができました。 災害の状況を正しく判定する精度が従来から 約 45 %向上 自社モデル開発の必要性がなくなり、開発・運用コストが 年間約 260 時間削減 今まで行っていた水害監視以外に、交通事故や火災などの 幅広い災害を監視したいお客様のニーズに対応すること が可能に 精度の向上やコストの削減の他に、既存のユースケース以外の様々なニーズに対応することができるようになりました。削減できたコストはお客様に還元することを検討しており、最終的には約 40 %低減させた価格で提供できる見込みとなっております。その後も新たなお客様のニーズに応えるための機能検討や検証を継続して行っております。 本取り組みは、アマゾンウェブサービスジャパン合同会社 広域事業統括本部主催の生成 AI コンテストにてアイデアの革新性、ビジネスインパクト、実現性を含めた技術力が総合的に評価され、26 社の取り組みの中で 「生成AIコンテスト 開発実績部門」にて 1 位を獲得 されました。また、 10 月 31 日(木) に開催された「 AWS AI Day 」でもユースケース展示が行われました。 まとめ 今回は災害写真情報サービスで、独自開発の機械学習モデルを AWS の生成 AI サービスである Amazon Bedrock に置き換える事例を紹介させていただきました。Amazon Bedrock を用いることで「 精度向上 」、「 コスト削減 」、「 既存ユースケース以外のニーズに対応 」といった幅広いメリットを享受していただきました。生成 AI モデルへの切り替えは、単純な置き換えだけではなく、プロンプトの検討やデータの最適化など工夫する部分がありますが、比較的少ない工数で大きなメリットを享受することができます。今まで自社開発で提供していた機械学習モデルから、サードパーティ製の生成 AI モデルに置き換えることで、精度の向上やコストの削減をすることにご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社アーベルソフト : 代表取締役社長 西岡 和也 様 (中央右)、第3システム部第2システム課 課長 高橋 圭太郎 様 (中央左) Amazon Web Services Japan : アカウントマネージャー 瀧澤 栞 (左端)、ソリューションアーキテクト 文珠 啓介 (右端) ソリューションアーキテクト 文珠 啓介
みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本(かじもと)です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也 アマゾン ウェブ サービス シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉 大樹 様 ソニー・ホンダモビリティ株式会社 ネットワークサービス開発部 General Manager -柄澤 優子 アマゾンウェブサービス プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田 広章 様 名古屋大学 教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化(モビリティDX)やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ0、OTAにより機能向上し継続的に収益が上げられるステップ1、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ2と3段階の進化仮説に触れ、このステップ3を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木 英彦 様 トヨタ自動車株式会社 デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点(CX)の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®(ネット・プロモーター:スコア)を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川 忠文 様 本田技研工業株式会社 ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の2グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション: In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木 英彦 様 トヨタ自動車株式会社 デジタル変革推進室 CX CENTER担当主査 担当部長 –野川 忠文 様 本田技研工業株式会社 ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫 アマゾン ウェブ サービス プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也 アマゾン ウェブ サービス シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の6点でした。 – Elektrobit Automotive GmbH様: Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様: IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様: 自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様: 運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①  AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ② 生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫(Kazuo Kajimoto) Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP( Our Leadership Principles )はBias for Actionです。
みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本(かじもと)です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也 アマゾン ウェブ サービス シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉 大樹 様 ソニー・ホンダモビリティ株式会社 ネットワークサービス開発部 General Manager -柄澤 優子 アマゾンウェブサービス プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田 広章 様 名古屋大学 教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化(モビリティDX)やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ0、OTAにより機能向上し継続的に収益が上げられるステップ1、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ2と3段階の進化仮説に触れ、このステップ3を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木 英彦 様 トヨタ自動車株式会社 デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点(CX)の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®(ネット・プロモーター:スコア)を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川 忠文 様 本田技研工業株式会社 ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の2グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション: In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木 英彦 様 トヨタ自動車株式会社 デジタル変革推進室 CX CENTER担当主査 担当部長 –野川 忠文 様 本田技研工業株式会社 ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫 アマゾン ウェブ サービス プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也 アマゾン ウェブ サービス シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の6点でした。 – Elektrobit Automotive GmbH様: Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様: IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様: 自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様: 運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①  AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ② 生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫(Kazuo Kajimoto) Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP( Our Leadership Principles )はBias for Actionです。
本記事は 2023年10月17日に公開された”Announcing the AWS Well-Architected Framework DevOps Guidance”を翻訳したものです。 2024年3月26日 AWS Well-Architected Tool の Lens Catalog に DevOps Lens として DevOps Guidance が追加されました。 このアップデートにより、ユーザはクラウドベースのワークロードをこれらのベストプラクティスに照らして自己評価し、ツールのレポートを通じて改善計画を確認可能です。 Amazon Web Services (AWS) は、 AWS Well-Architected Framework DevOps Guidance を発表しました。AWS DevOps Guidance では、AWS DevOps Saga (訳注 Saga は冒険談や大河小説などを意味する単語です。DevOps を持続的に実践するには時間がかかり、継続的かつ相互に結びついた一連の能力が必要となることを反映し、「Saga」という言葉を用いています)について紹介しています。AWS DevOps Saga は、クラウドの規模でソフトウェア設計や開発、セキュリティ保護及び、効率的な運用を行っていくために、包括的なアプローチを形成していく最新の機能を集めたコレクションです。AWS DevOps Guidance は、Amazon 自身の変革の旅路から得た学びと、世界中に提供しているクラウドサービスを管理してきた経験を基に、あらゆる規模の組織にベストプラクティス、プロセス、技術的な能力を提供することで、ビジネス価値の向上とアプリケーションのより安全かつ高速な提供を促進するために作成されました。 Amazon の DevOps 変革の概要 2000 年代初頭、 Amazon は 独自の DevOps の変革を経験しました。この経験がオンライン書店から AWS クラウドコンピューティング部門の設立へと繋がっています。今日、 AWS は Amazon の経験した独自の DevOps のアプローチと同様の革新的な DevOps アプローチを採用した幅広いプロダクトとサービスを世界中のお客様へ提供しています。この変革のポジティブな効果により、AWS は DevOps の重要性を認識し、その採用と実装の最前線に立っています。 Amazon は自身の変遷と、クラウドへのマイグレーションやモダナイゼーションをお客様に支援してきた経験から DevOps の導入を成功させるための重要な能力についての洞察を得ました。これらの知見を活かし、お客様が DevOps を継続的に導入し実践できるよう、相互に関連する一連の能力を組み込んだ「DevOps Saga」を作成しました。各 DevOps Saga には、成功の指標となる能力、測定する指標、および避けるべき一般的なアンチパターンに対する規範的ガイダンスが含まれています。 DevOps Saga のご紹介 DevOps Saga は 5つの要素から構成され、AWS の DevOps のベストプラクティスを構成するソフトウェア開発プロセスにおける中核的な領域です。 DevOps Sagaを総合的に活用することでクラウド規模でのソフトウェアの設計や開発、セキュリティの確保、効率的な運用を包括的に行うための最新の機能を網羅できます。 DevOps Saga は、組織内での理解の共通化を促進し、DevOps という言葉に対する組織内の定義の統一に役立ちます。また、 DevOps の導入状況を長期間にわたり継続的に測定可能です。DevOps Saga を構成する要素は次の 5 つになります: 組織導入の Saga : お客様中心の適応力のある文化の形成を促進し、人間中心のプロセスの最適化、個人とプロフェッショナルとしての成長、開発者体験の改善に焦点を当てることで、DevOps 導入の基盤を築きます。 開発ライフサイクルの Saga : 組織のワークロードを迅速かつ安全に開発、レビュー、デプロイする能力を高めることを目指しています。フィードバックループ、一貫したデプロイ手法、「すべてをコード化する」アプローチを活用することで、デプロイの効率化を図ります。 品質保証の Saga : 開発プロセスに統合されたテストファーストな手法を提唱することにより、設計観点で well-architected であり、安全で、コストが最適化され、持続可能で、自動化を通じて俊敏性が向上したアプリケーションの提供を保証していきます。また、自動化によるアジリティが向上するように推進します。 自動化ガバナンスの Saga :開発プロセス全体で指令、検出、予防、対応措置の実施を容易にします。自動化されたプロセス、ポリシー、ガードレールを通じて、リスク管理、ビジネスプロセス遵守、アプリケーションおよびインフラストラクチャのコンプライアンスを様々な規模で実現することを重視しています。 可観測性(オブザーバビリティ)の Saga: 環境やワークロードに可観測性を組み込むアプローチを提示します。これによってチームが問題の検知や対処、パフォーマンスの改善、コストの削減およびビジネス目標と顧客ニーズとの整合性を確保できるようにします。 AWS DevOps Guidance は誰が利用すべきか? 私たちは、すべての組織がユニークであり、 DevOps を実践するための万能なアプローチはないと認識しています。本記事で提示した推奨事項と例は、お客様の組織の環境、品質、セキュリティのニーズに合わせたカスタマイズして活用いただけます。AWS DevOps Guidance は、幅広いプロフェッショナルや組織を対象に設計されています。初めて DevOps に取り組むスタートアップ企業、プロセスの改善を図る企業、公的機関、クラウドネイティブな企業、AWS クラウドへの移行を検討する企業など、さまざまな組織に適しています。最高技術責任者 ( CTO ) や最高情報セキュリティ責任者 ( CISO ) として戦略的方向性を示す立場の方、ワークロードの設計や展開に携わる開発者やアーキテクト、品質保証、監査、ガバナンスを監督するコンプライアンス担当者など、どのような役割の方々にとっても、このガイダンスは役立つものとなっています。 ネクストステップ AWS DevOps Guidance のリリースを受け、お客様には本書をダウンロードし一読いただき、推奨事項に従ってワークロードの実装とテストを実施いただくことをお勧めします。AWS Well-Architected Framework と併せて AWS DevOps Guidance を活用することで、お客様の組織や個々のワークロードが DevOps のベストプラクティスに準拠しているかを評価し、強みと改善の余地がある領域を特定してください。開発者、運用担当者、意思決定者など、さまざまな役割のメンバーでチームを結成し、評価結果を共有しましょう。AWS DevOps Guidance から得られた洞察を活かして改善領域の優先順位を決め、DevOps 能力を継続的に向上してください。 AWS DevOps Guidance は、 AWS Well-Architected サイト からダウンロードできます。詳細については、AWS アカウントチームまでお問い合わせください。アーキテクチャやサービスの設計を検討する際や、Well-Architected レビューを実施する際には、AWS Well-Architected Framework やその他のガイダンスと同様に、AWS DevOps Guidance を早期から積極的に活用することをお勧めします。AWS DevOps Guidance をご利用の際には、ベストプラクティスやテクノロジーの進化に合わせて改善できるよう、ご意見やご感想をお寄せください。一般的なユースケースや新しい指標、ベストプラクティスが出てくる度に、内容は継続的に更新されます。 本記事はアマゾンウェブサービスジャパン合同会社の畠泰三が翻訳を担当しました。 原文はこちら
11 月 13 日は、 リソースコントロールポリシー (RCP) をご紹介します。これは、AWS Organizations で管理される新しい認可ポリシーで、組織全体のリソースに対する使用可能な最大の許可を設定するために使用できます。これは、AWS 環境に データ境界 を確立し、リソースに対する外部アクセスを大規模に制限するのに役立つ予防的コントロールの一種です。Organizations 内で一元的に強制適用される RCP により、中心的なガバナンスチームとセキュリティチームは、AWS アカウント内のリソースに対するアクセスが、組織のアクセスコントロールガイドラインに準拠していることに自信をもつことができます。 RCP はすべての商用 AWS リージョンで利用可能で、リリース時には次のサービスがサポートされています: Amazon Simple Storage Service (Amazon S3) 、 AWS Security Token Service (AWS STS) 、 AWS Key Management Service (AWS KMS) 、 Amazon Simple Queue Service (Amazon SQS) 、 AWS Secrets Manager 。 RCP を有効にして使用しても追加料金はかかりません。 サービスコントロールポリシー (SCP) との違い 本質的には似ている一方で、RCP は サービスコントロールポリシー (SCP) を補完しますが、独立して機能します。 サービスコントロールポリシー (SCP) を使用すると、AWS Identity and Access Management (IAM) ロールなどの組織内のプリンシパルに付与される許可を制限できます。これらの許可を Organizations 内で一元的に制限することで、AWS サービス、特定のリソース、さらにはプリンシパルが複数の AWS アカウントにまたがってリクエストを実行するために満たさなければならない条件に対するアクセスを制限できます。 一方、RCP を使用すると、組織内のリソースに付与される許可を制限できます。RCP は Organizations 内で一元的に実装するため、複数の AWS アカウントにまたがって、リソースに対する、一貫性のあるアクセスコントロールを強制適用できます。例えば、アカウント内の S3 バケットに対するアクセスを制限して、組織に属するプリンシパルのみがアクセスできるようにすることができます。RCP は、誰が API リクエストを実行しているのかにかかわらず、リソースがアクセスされたときに評価されます。 SCP と RCP のいずれも許可を付与するものではないことに留意してください。これらは、組織内のプリンシパルとリソースに使用可能な最大の許可を設定するだけです。許可を付与するには、適切な IAM ポリシー (ID ベースのポリシーやリソースベースのポリシーなど) を使用する必要があります。 SCP と RCP のクォータは、互いに完全に独立しています。各 RCP は最大 5,120 文字です。組織のルート、各 OU、およびアカウントに最大 5 個の RCP をアタッチでき、組織で最大 1,000 個の RCP を作成して保存できます。 開始方法 RCP の使用を開始するには、まず RCP を有効にする必要があります。これは、Organizations コンソール、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して行うことができます。ポリシータイプを有効または無効にできるのは、Organizations 管理アカウントまたは委任された管理者のみであるため、必ずそれらを使用してください。 [すべての機能] オプションで Organizations を使用していることを確認してください。 [一括請求 (コンソリデーティッドビリング) 機能] モードを使用している場合は、RCP を有効にする前に、 すべての機能を使用するように移行 する必要があります。 コンソールユーザーは、まず Organizations コンソールに移動します。 [ポリシー] を選択すると、 [リソースコントロールポリシー] を有効にするオプションが表示されます。 RCP を有効にすると、 [リソースコントロールポリシー] ページで、 RCPFullAWSAccess という新しいポリシーが使用可能になっていることがわかります。これは、自動的に作成され、ルート、各 OU、AWS アカウントなど、組織内のすべてのエンティティにアタッチされる AWS マネージドポリシーです。 このポリシーにより、すべてのプリンシパルが組織のリソースに対して任意のアクションを実行できるようになります。つまり、独自の RCP を作成してアタッチするまで、既存の IAM 許可はすべてこれまでどおりに動作します。 これは、次のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } RCP の作成 これで、最初の RCP を作成する準備が整いました。 例を見てみましょう。 デフォルトでは、AWS リソースは外部プリンシパルに対するアクセスを許可しません。リソース所有者は、ポリシーを設定することで、そのようなアクセスを明示的に付与する必要があります。デベロッパーはアプリケーションのニーズに応じてリソースベースのポリシーを柔軟に設定できますが、RCP を使用すると、中心的な IT チームは組織内のリソース全体で、有効な許可に対するコントロールを維持できます。これにより、デベロッパーが広範なアクセスを付与した場合でも、外部 ID によるアクセスは組織のセキュリティ要件に従って制限されます。 組織内のプリンシパルのみがアクセスできるように、S3 バケットに対するアクセスを制限する RCP を作成してみましょう。 [リソースコントロールポリシー] ページで、 [ポリシーを作成] を選択すると、新しいポリシーを作成できるページが表示されます。 このポリシーを EnforceOrgIdentities と呼びます。このポリシーがどのような効果を有するのかを一目で理解しやすくし、適切にタグ付けできるよう、明確な説明を入力することをお勧めします。 次のセクションでは、ポリシーステートメントを編集できます。事前入力済みのポリシーテンプレートを独自のものに置き換えます。 完全な JSON ポリシードキュメントは次のとおりです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] } 詳しく見てみましょう。 Version – これは IAM ポリシーの標準かつ必須の要素です。AWS は下位互換性を維持しているため、最新バージョン (現在は 2012-10-17) を使用しても既存のポリシーが壊れることはなく、新しい機能を使用できます。 Statement – 1 つ以上のステートメントオブジェクトを含めることができる配列。これらの各ステートメントオブジェクトは、単一の許可または許可セットを定義します。 Sid – これはオプションのフィールドで、ポリシー管理とトラブルシューティングに役立ちます。この JSON ポリシードキュメントの範囲内で一意である必要があります。 Effect – 前述のとおり、デフォルトでは、組織内のあらゆるエンティティにアタッチされているすべての AWS プリンシパル、アクション、およびリソースに対するアクセスを許可する RCP があります。そのため、制限を適用するには、 Deny を使用する必要があります。 Principal – RCP では、このフィールドは常に "*" に設定する必要があります。このポリシーを特定のプリンシパルにのみ適用する場合は、Condition フィールドを使用します。 Action – このポリシーが適用される AWS サービスとアクションを指定します。この場合、アクセスコントロールガイドラインを満たしていない場合は、Amazon S3 とのすべてのインタラクションを拒否します。 Resource – RCP が適用されるリソースを指定します。 Condition – 各リクエストについてポリシーを適用すべきかどうかを決定するために評価される条件のコレクション。 RCP を適用するには、すべての条件が true と評価される必要がある ことを覚えておいてください。ここでは、2 つの条件を適用しています。 1.リクエストは外部プリンシパルによって実行されたか? "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" } この条件は、まず、キー aws:PrincipalOrgID がリクエスト内に存在するかどうかをチェックします。存在しない場合、この条件はそれ以上評価せずに true と評価します。 存在する場合、値を組織 ID と比較します。値が同じ場合は false と評価され、RCP は適用されません。なぜなら、すべての条件が true と評価される必要があるからです。組織内のプリンシパルに対するアクセスを拒否したくないため、これは意図された動作です。 ただし、値が組織 ID と一致しない場合は、リクエストが組織外のプリンシパルによって実行されたことを意味します。条件は true と評価されます。これは、2 つ目の条件も true と評価されれば、RCP が適用される可能性がまだあることを意味します。 2.リクエストは AWS サービスからのものか? "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } この条件は、 aws:PrincipalIsAWSService という特別なキーがリクエストに含まれているかどうかをテストします。このキーは、署名されたすべての API リクエストのリクエストコンテキストに自動的に挿入され、S3 バケットにイベントを書き込む AWS CloudTrail などの AWS サービスからのものである場合は true に設定されます。このキーが存在しない場合、この条件は true と評価されます。 存在する場合は、ステートメントで宣言した値と比較されます。ここでは、値が false と等しいかどうかをテストしています。等しい場合は、リクエストが AWS サービスによって実行されたものではなく、組織外の誰かによって実行された可能性があることを意味するため、 true を返します。それ以外の場合は、 false を返します。 つまり、リクエストが組織内のプリンシパルからのものではなく、AWS サービスからのものでもない場合、S3 バケットに対するアクセスは拒否されます。 このポリシーは単なるサンプルであり、独自のビジネス目標とセキュリティ目標に合わせてカスタマイズすべきです。例えば、このポリシーをカスタマイズして、ビジネスパートナーによるアクセスを許可したり、AWS サービスに対するアクセスを制限して、パートナーがお客様に代わってのみリソースにアクセスできるようにしたりすることができます。詳細については、「 Establishing a data perimeter on AWS: Allow only trusted identities to access company data 」をご覧ください。 RCP のアタッチ RCP をアタッチするプロセスは SCP に似ています。前述のように、組織のルート、OU、または組織内の特定の AWS アカウントに RCP をアタッチできます。 RCP をアタッチした後、影響を受ける AWS リソースに対するアクセスリクエストは RCP 制限に準拠する必要があります。大規模に強制適用する前に、アカウント内のリソースに対する RCP の影響を徹底的にテストすることをお勧めします。個々のテストアカウントまたはテスト OU に RCP をアタッチすることから始めることができます。 実際の動作 これで RCP を作成してアタッチしたので、実際に機能している様子を確認する準備ができました。 デベロッパーがリソースベースのポリシーを組織内の S3 バケットにアタッチし、外部アカウントの ID に対してアクセスを明示的に付与したと仮定します。 RCP は、ユーザーが RCP で許可されているよりも許容度が高いリソースベースのポリシーを保存することを妨げません。ただし、前述のとおり、RCP は認可プロセスの一環として評価されるため、外部 ID によるリクエストはいずれにしても拒否されます。 この外部アカウントを使用してバケットにアクセスを試みることで、これを証明できます。今回は AWS CLI から実行します。 $ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \ --key sensitivefile.txt \ --region us-east-1 local_file An error occurred (AccessDenied) when calling the GetObject operation: Access Denied 環境内での RCP のデプロイのスケール これまで、コンソールを使用して RCP を管理する方法について見てきました。ただし、大規模なコントロール管理の場合は、それらを Infrastructure as Code として設定することを検討し、既存の継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとプロセスに統合されることを確認すべきです。 AWS Control Tower を使用する場合は、SCP ベースのコントロールに加えて RCP ベースのコントロールをデプロイできます。例えば、AWS Control Tower を使用して、前述の例で作成したものと同様の RCP をデプロイし、外部プリンシパルが組織内の S3 バケットにアクセスできないようにすることができます。これにより、マネージドアカウントのリソースに RCP が一貫して適用され、アクセスコントロールガバナンスが大規模に合理化および一元化されます。 さらに、SCP と同様に、AWS Control Tower は RCP のためにドリフト検出もサポートしています。AWS Control Tower の外部で RCP が変更または削除された場合、ドリフトについて通知され、是正のステップが提供されます。 まとめ リソースコントロールポリシー (RCP) は、組織内の AWS リソースに使用可能な最大の許可に対する一元管理を提供します。SCP とともに、RCP は AWS 環境全体で データ境界 を一元的に確立し、意図しないアクセスを大規模に防ぐのに役立ちます。SCP と RCP は独立したコントロールであり、異なる一連のセキュリティ目標を達成することを可能にします。SCP または RCP のみを有効にするか、または両方のポリシータイプを併用して、多層防御セキュリティモデルの一部として包括的なセキュリティベースラインを確立するかを選択できます。 詳細については、「 AWS Organizations ユーザーガイド 」の「Resource control policies (RCPs)」をご覧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。
私は数年前から AWS BuilderCards の進歩を見てきました。あらゆるスキルレベルのプレイヤーがこのカードを使用して、楽しく興味をそそる方法で AWS について学び、カードを組み合わせてアーキテクチャを形成しようと (友好的に) 競い合い、プレイしながら知識を得てポイントを獲得しています。 これまでに 15,000 セット以上の BuilderCards が印刷され、3 回の re:Invent、15 回の AWS Summit、複数のコミュニティイベントで使用されています。例えば、 JAWS Days 2024 の期間中、東京で楽しい時間を過ごしている AWS 愛好家グループの写真をご覧ください。 プレイヤーからのフィードバックは非常に好意的で、1,500 件以上の返信において星 4.8 の顧客満足度スコア (CSAT) を獲得しています。 第 2 エディションの発売開始 AWS BuilderCards の第 2 エディションが re:Invent 2024 で配布され、まもなくオンラインでも購入できるようになるとお知らせできることを嬉しく思います。第 1 エディションへのフィードバックに応えて、第 2 エディションに多くの変更を加えました。概要は次のとおりです。 デザイン – 変更後のデザインでは、カードの内容に重点を置き、カードをより魅力的で遊び心のあるものにするために、グラデーションやパターンが追加されています。フォントサイズが大きくなり、ゲームエフェクトがアイコンとして表示されるようになり、QR コードが BuilderCards サイトを指すようになりました。 ゲームの仕組み – 仕組みが見直され、バランスの改善、プレイの簡素化、一部のバイアスの排除が行われました。一般的なオンプレミスデータセンター環境を表すスターターカードもいくつかあります。 生成 AI アドオンパック – この新しいデッキには、生成 AI と AWS アーキテクチャが連携する方法を示すために設計された、50 枚の BuilderCards が追加されています。このアドオンパックには、ミッションカードのセットも含まれています。これらのカードは、公開されているベストプラクティスやソリューションにリンクする QR コードを使用して、コンテキストを追加します。カードはより大きくなり、テキストとアーキテクチャ図が追加されました。使用は任意で、プレイヤーはミッションを完了すると追加ポイントを獲得できます。各デッキには、カスタマイズに役立つ空白の BuilderCards が 5 枚と空白のミッションカードが 2 枚含まれています。 BuilderCards を入手 re:Invent 2024 に参加する予定なら、Caesar’s Forum の 1 階にある PeerTalk エリアの隣の BuilderCards プレイエリアを訪れてください。 日曜日 – 午前 10 時~午後 6 時 月曜日 – 午前 9 時~午後 5 時 火曜日 – 午前 9 時~午後 5 時 水曜日 – 午前 9 時~午後 5 時 木曜日 – 午前 9 時~午後 4 時 re:Invent の他の参加者と対戦したり、自分のゲームパックやアドオンパックを入手して持ち帰ったりすることができます (1 日あたり 1,000 個をプレゼントいたします)。 山口正徳 氏 (AWS ヒーロー) と 榎本航介 氏 (AWS コミュニティビルダー) の努力のおかげで、その場でプレイできる日本語の BuilderCards もご用意します。翻訳プロセスの詳細については、榎本氏のブログ記事 ( AWS BuilderCards Japanese Edition for JAWS DAYS ) をご覧ください。 re:Invent に参加できない場合でも、すぐに自分のデッキを購入できるようになります。詳細については、ここに戻ってご確認ください! ご期待ください BuilderCards チームは、拡張パックや追加の言語パックなど、その他の特典の開発に取り組んでいます。 – Jeff ; 原文は こちら です。
AWS ニュースブログは 20 周年を迎えました ! 2004 年 11 月 9 日、Jeff Barr は 初めてのブログ記事 を公開しました。当初、彼は TypePad を使用して個人のブログサイトを開設しました。会社やチームではなく、自分の個人的な声を読者に届けたかったのです。 2014 年 4 月 29 日、当社は 新しい AWS ブログサイト を作成し、すべての投稿をそのページに移行しました。現在、AWS ニュースブログには 4,300 件を超える投稿があり、そのうちの 3,200 件以上が Jeff による投稿です。 2016 年 12 月以降、AWS ニュースブログには新しいライターが追加されましたが、引き続き、初日に打ち立てられた AWS ニュースブロガー向けの Jeff のリーダーシップ・プリンシプル に沿って活動しています。AWS ニュースブログのユニークな点は、ブログ作成者が Customer Obsession (顧客第一主義) のリーダーシップ・プリンシプルに沿って製品チームの機能を事前に利用していること、そして Frugality (倹約) のプリンシパルに従って、お客様がそれらをすばやく使用して時間を節約する方法のウォークスルーに焦点を当てていることです。 過去 20 年間、Jeff が果たしてきた基本的かつ極めて重要な役割にとても感謝しています。また、これからの 20 年を楽しみにしています! 11 月 4 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon MSK 向けの新しい Express ブローカー – Express ブローカーは Amazon MSK Provisioned の新しいブローカータイプで、標準の Apache Kafka ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、回復時間が 90% 短縮されるように設計されています。Express ブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、すべての Kafka API をサポートし、同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 新しい Amazon Kinesis Client Library 3.0 – Kinesis Client Library (KCL) 3.0 では、ストリーミングデータを処理するためのコンピューティングコストを、以前の KCL バージョンと比較して最大 33% 削減できるようになりました。KCL 3.0 では、ストリーム処理ワーカーのリソース使用率を継続的にモニタリングし、過度に使用しているワーカーから十分に使用されていない他のワーカーにロードを自動的に再配分する、強化されたロードバランシングアルゴリズムが導入されています。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 Amazon EC2 での Microsoft Windows Server 2025 イメージ – License Included (LI) Amazon マシンイメージ (AMI) で Microsoft Windows Server 2025 のサポートを開始しました。これにより、Windows Server の最新バージョンを簡単かつ柔軟に起動する方法をお客様に提供できるようになりました。 Amazon EC2 で Windows Server 2025 を実行することにより、お客様は Windows Server の最新機能を使用して AWS のセキュリティ、パフォーマンス、信頼性を活用できます。Amazon EC2 で Windows Server 2025 を実行する方法の詳細については、「 AWS での Windows ワークロード 」を参照してください。 Amazon Bedrock での Anthropic の Claude 3.5 Haiku モデル – Claude 3.5 Haiku は、Anthropic の最速モデルの次世代であり 、 迅速な応答時間と改善された推論機能を兼ね備えているため、スピードとインテリジェンスの両方を必要とするタスクに適しています。Claude 3.5 Haiku はあらゆるスキルセットで向上しており、コーディングを含む多くのインテリジェンスベンチマークで、Anthropic の前世代かつ最大のモデルである Claude 3 Opus をも上回っています。詳細については、 AWS ニュースブログの記事 をお読みください。 Amazon Bedrock Prompt Management GA – Amazon Bedrock Prompt Management で、プロンプトの作成、テスト、バージョニング、共有を簡素化できます。一般公開時に、プロンプトを設定し、生成 AI アプリケーションでそれらを呼び出すための拡張オプションを提供する新機能を追加しました。これには構造化プロンプトや、Converse と InvokeModel API の統合などが含まれます。詳細については、 AWS 機械学習のブログ記事 をご覧ください。 Amazon Polly 向けの 6 つの新しい合成型生成音声 – 生成エンジンは、生成 AI テクノロジーを活用した Amazon Polly の最も高度な音声合成 (TTS) モデルです。Ayanda (南アフリカ英語)、Léa (フランス語)、Lucia (ヨーロッパスペイン語)、Lupe (アメリカスペイン語)、Mía (メキシコスペイン語)、Vicki (ドイツ語) の 6 つの合成型生成音声 (女性) を新たに追加しました。これにより、13 の声と 9 つのロケールが拡張され、表現力豊かで魅力的な声の選択肢が増えました。 Amazon OpenSearch Service 延長サポート – 従来の Elasticsearch バージョンと OpenSearch バージョンの標準サポートおよび延長サポートのタイムラインの終了をお知らせします。6.7 までのレガシー Elasticsearch バージョン、7.1〜7.8 までの Elasticsearch バージョン、1.0〜1.2 までの OpenSearch バージョン、2.3〜2.9 までの OpenSearch バージョンの標準サポートは、2025 年 11 月 7 日に終了します。延長サポートでは、通常のインスタンス料金に重ねて段階的な定額料金を支払うことで、標準サポートの終了後も重要なセキュリティアップデートを引き続き受けることができます。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 CEO の AWS データセンター訪問 – AWS の CEO である Matt Garman は先日、弊社の AWS データセンターの 1 つを訪問して素晴らしい時間を過ごし、チームによってもたらされる継続的なイノベーションを確認することができました。もちろん、Amazon の上級幹部がフルフィルメントセンター、コンタクトセンター、データセンターを訪れ、お客様のために作業を行うのは当然のことです。AWS データセンターは、あらゆる面でお客様向けに設計されており、最大の回復力、パフォーマンス、エネルギー効率を実現します。 AWS は、AWS データセンターの近くで中小企業の支援、雇用の創出、持続可能性に関する取り組みの立ち上げ、教育プログラムの開発を行っています。最新情報を入手 – コミュニティでの AWS: About Amazon News では、米国中のデータセンターの近くで起きていることをご紹介します 。 Amazon での Amazon Q Business – 以前、とある Amazon ストーリーをご紹介 しました。 Amazon Q Developer のコード変換を使用して、 30,000 件以上の古い Java アプリケーションを Java 17 バージョンに移行 したというものです。最新バージョンの Java に移行したことで、以前の手動作業に比べて 4,500 年分以上もの開発者の労力が削減され、同社は年間 2 億 6,000 万 USD を節約しました。 今日ご紹介するのは、 Amazon での Amazon Q Business のもう 1 つのドッグフーディングのストーリー です。Amazon は Amazon Q Business と共同で社内チャットボットを構築し、Amazon の開発者から寄せられた 100 万件を超える質問を解決しました。これにより、手作業による技術調査に費やす時間を 45 万時間以上削減できました。 私たちのチームは、何百万もの内部文書を使って Amazon Q Business をオンボーディングし、チームが毎日使用するツールに Q Business を統合しました。開発者は、Q&A 掲示板や Slack チャンネルで、複雑な技術的質問への回答を何時間も待つのではなく、数秒で得られるようになりました。 PGA TOUR の TOURCast – ゴルフがお好きなら、このニュースに興味があるはずです。 PGA TOUR は、 TOURCast を日本の 2024 ZOZO CHAMPIONSHIP でデビューさせました。これは、 CDW を利用した ShotLink と呼ばれる新しいスコアリングシステムに基づいて、より良い統計データを収集して広め、ファンとゲームとの距離を近づけるためです。PGA TOUR がこのテクノロジーをアジアに持ち込み、AWS の柔軟性とスケーラビリティを活用して独自の課題を克服したのはこれが初めてです。 PGA TOUR のボランティアが ZOZO CHAMPIONSHIP のフェアウェイに、特定のショットデータを入力して Shotlink Select Plus にフィードバックする GPS 機器を設置しているところ。[画像: PGA TOUR] 同社は過去 2 年間で、新しいクラウドスタックにスコアリングシステムを完全に再構築しました。AWS クラウドでは、ハイテクレーダーシステム、カメラ、手動入力のいずれから送信されるデータであっても、システムがすべてシームレスに処理します。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS GenAI Lofts – AWS GenAI Lofts は、テクノロジーを紹介するだけに留まらず、スタートアップ、開発者、投資者、業界エキスパートが一堂に集まって交流する場も提供します。深いインサイトを得たい、または 生成 AI の専門家から質問の回答を得たいと考えているかにかかわらず、GenAI Loft は皆さんのニーズに対応し、次のイノベーションの構築を開始するために必要な事柄のすべてを提供します。 サンパウロ (11 月 20 日まで) と パリ (11 月 25 日まで) のイベントに参加しましょう。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 インドネシア、ジャカルタ (11 月 23 日)、 インド、コーチ (11 月 14 日) です。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される毎年恒例の学習イベントに、引き続き ご登録 いただけます。驚くことに、Amazon の CEO である Andy Jassy は、 今年も戻ってきて AWS re:Invent に参加すると発言しました。彼はこう語っています。「いつものように、このイベントを学習イベントにすることが最優先事項です。そうすれば、お客様は大きな成果を取り戻し、自身の顧客体験やビジネスを変えることができます。また、皆様に気に入っていただけると考えているさまざまなことを発表する予定です」 お会いできるのを楽しみにしています! 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 11 月 11 日週はここまでです。11 月 18 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。
AWS CloudFormation を利用することで、クラウドアプリケーションのインフラストラクチャをコードとしてモデル化してプロビジョニングすることが容易になります。 CloudFormation テンプレートは直接 JSON または YAML で記述できるだけでなく、 AWS Cloud Development Kit (CDK) などのツールで生成することもできます。これらのテンプレートが CloudFormation サービスにサブミットされると、リソースはスタックという単位でまとめられ、依存関係を反映した順序でデプロイされます。スタックイベントの詳細は コンソール 上で表形式で確認できます。 そしてこの度、より視覚的で直感的なイベントのビューを提供する deployment timeline view という新機能が登場しました。この機能はスタック操作で CloudFormation が実行した一連のアクションを視覚化します。この機能が提供する視覚的なタイムラインは、リソースがプロビジョニングされた正確な順序、リソース間の依存関係、プロビジョニングにかかった時間を示します。デプロイが失敗した際は根本原因と考えられる箇所を示します。デプロイの舞台裏で起きていることについての追加コンテキストと可視性を提供することで既存の表形式のビューを補完します。 図 1: CloudFormation deployment timeline view の機能の概要 どのように動作するか 新機能の deployment timeline view を利用するために必要なのは、スタックの作成、更新、削除の操作だけです。AWS CloudFormation コンソールで Events タブを選択し、Table view の横にある Timeline view タブをクリックします。 CloudFormation がテンプレートで定義されたリソースのプロビジョニングを開始すると、各リソース操作がタイムラインビューで棒線として表示されます。 リソースは、最新の操作があったリソースが一番上になるように時系列順に垂直に積み上げらます。各リソースアクションは、それぞれのアクションに応じて色分けされた水平の棒で視覚化されます。 ダークモードではロールバック中とロールバック完了のスイッチの色が切り替わる バーの上にカーソルを移動させると、完全なリソース名やリソース操作の開始/終了時刻など詳細な情報が表示されます。 デプロイが失敗した場合は、CloudFormation は失敗の原因と考えられるリソース操作のバーを赤白の縞模様で強調表示します。このバーにカーソルを移動すると、具体的な失敗理由が表示されます。 シンプルなスタックを作成する CloudFormation コンソールを使用してシンプルなスタックを作成します。デプロイを開始して視覚的なタイムラインビューを確認します。 1. CloudFormation コンソールから、 Create stack をクリックし、 with new resources を選択します。 図 2: CloudFormation コンソールの create stack ボタン 2. スタック作成ウィザードで Choose an existing template をクリックし Upload a template file を選択します。 Choose file をクリックしデプロイするスタックのテンプレートファイルを選択してアップロードします。この記事では、 こちら で提供されているテンプレートを使用します。このテンプレートをダウンロードして使用するほかに、独自のテンプレートを使用することもできます。独自のテンプレートを使用した場合はタイムラインビューの内容がこの記事とは異なるものになります。 (翻訳者補足: ここで紹介されているテンプレートはオレゴンリージョンでのみデプロイに成功します) 図 3: CloudFormation コンソールの スタック作成ウィザード アプリケーションスタックには、Amazon EC2 インスタンス ( AWS::EC2::Instance )、Amazon VPC ( AWS::EC2::VPC )、およびサブネット ( AWS::EC2::Subnet ) やインターネットゲートウェイ ( AWS::EC2::InternetGateway ) などの VPC リソースが含まれています。 3. テンプレートをアップロードしたら Next をクリックし、必要に応じてスタック名とパラメータを入力します。 スタックデプロイの後続の手順を完了させ、スタックの作成を開始します。 4. スタックイベントページで、 Table view の横の Timeline view タブをクリックします。 CloudFormation が最初に VPC、その後でサブネット、最後に EC2 インスタンスをプロビジョニングしていく間の進捗状況をリアルタイムで確認できます。 図 4: CloudFormation が実行中のデプロイのタイムラインビュー 5. タイムラインは 5 秒ごとに表示をリフレッシュし、デプロイの進捗状況を更新します。5 秒後、次のようなタイムラインビューが表示されます。 図 5: 5 秒後に更新されたタイムライン 図 6: 完了したデプロイのタイムラインビュー 上のタイムラインでは、CloudFormation によってプロビジョニングされたリソースを表すバーが下から上に向かって並び、それぞれのリソース操作が発生した順序やリソース間の依存関係を読み取ることができます。 バーは操作の進行にともなって青 (進行中)、黄 (整合性チェック中)、緑 (成功)または赤 (失敗) に変化します。 図 7: リソース詳細ポップオーバー いずれかのバーにカーソルを置くと、各デプロイフェーズの開始/終了時間や完全なリソース名などの詳細が表示されます。グラフのポップオーバーに表示される詳細情報から、CloudFormation が InternetGateway リソースを 2 秒で作成し、その後 15 秒待機してリソースが完全に動作しているかどうかを確認してから完了としてマークしたことを読み取ることができます。このフェーズをリソース整合性チェックフェーズ (resource consistency check phase)、またはリソース安定化フェーズ (resource stabilization phase) と呼びます。これによって CloudFormation をはじめとする Infrastructure as Code (IaC) ツールは復元力のあるデプロイメントを確かなものにすることができます。詳しくは CloudFormation optimistic stabilization strategy の記事 (日本語翻訳版は こちら ) をお読みください。 ロールバック完了状態のスタック スタックのデプロイが失敗した場合、CloudFormation は現在のスタック操作の前の安定した状態にロールバックします。 以下のタイムラインビューでは、失敗したスタック操作が完全にロールバックされた状態で表示されています。 赤と白の縞模様で強調表示されているリソースが根本原因である可能性が高いので、すぐにトラブルシューティングを開始できます。 図 8: ロールバック完了状態のスタックのタイムラインビュー まとめ 新機能の CloudFormation deployment timeline view では、CloudFormation が Infrastructure as Code のテンプレートで定義されたリソースをプロビジョニングする際のオーケストレーションフローと依存関係を可視化できるようになりました。 この視覚的なタイムラインビューを活用することで、デプロイメントの失敗の根本原因を素早く特定したり、プロビジョニングプロセスの理解を深めることができます。 この機能は、現在 CloudFormation がサポートされているすべての AWS リージョンで利用可能です。 ぜひ CloudFormation コンソールにアクセスし deployment timeline view を使ってみてください。 著者紹介: Idriss Laouali Abdou Idriss は AWS のシニアプロダクトマネージャーであり、AWS IaC のお客様に最高の体験を提供することに尽力しています。仕事以外では、何千人もの学生を支援する教育コンテンツを作成したり、料理をしたり、ダンスをしたりしています。 Jamie To Jamie はフロントエンドエンジニアであり、過去 3 年間 AWS IaC のお客様にコンソール機能を提供してきました。仕事以外では、絵を描いたり、フーズボールをしたりするのが好きです。 Puran Zhang Puran は 過去 4 年間フロントエンドエンジニアとして IaC コンソールに貢献してきました。仕事以外では、キッチンやコーヒーバーにいるところ、または次のレストランへ急いでいるところをよく見かけます。 本記事は 2024/11/11 に投稿された  Peek inside your AWS CloudFormation Deployments with timeline view を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。
11 月 8 日、 Amazon Location Service は、 Routes 、 Places 、 Maps 機能の能力を拡張および改善する 17 個の強化された新たな API をリリースしました。これにより、開発者にとって総合的かつ効率的なエクスペリエンスが実現します。機能を強化し、移行を簡素化するこれらの更新により、Amazon Location Service は幅広いアプリケーションでさらに利用しやすく、便利になりました。 静的および動的レンダリングオプションを使用して、高度なルート最適化、通行料計算、GPS トレーススナップ、さまざまなマップスタイルにアクセスできるようになりました。また、関心のある地点に関する豊富で詳細な情報を利用して、近接度ベースの検索と予測提案を実行できるようになりました。 Amazon のロードマップの大部分は、お客様からのフィードバックに基づいています。Amazon Location Service を使用してアプリケーションを構築している多くのお客様から、位置情報ベースのデータを扱う際には、専用の API と、連絡先情報や営業時間などのより詳細な情報が必要であるとのご意見が寄せられています。現在の API セットは多くのお客様に貴重なツールを提供してきましたが、開発者は詳細なルートプランニング、近接度ベースの検索、追加の場所の詳細、静的マップ画像などの追加機能を望んでいると表明しています。これらの新しい API は開発者の要求に応え、すぐに使用できるより包括的な位置情報ソリューションを提供します。 新機能と拡張機能 11 月 8 日のリリースでは、お客様のフィードバックに直接応える、10 個の更新された API と 7 個のまったく新しい API を紹介します。Routes、Places、Maps の各サービスには、より幅広いユースケースをサポートできるように設計された、特定の機能強化が施されています。 Routes Amazon Location Routes API は、高度なルートプランニングとカスタマイズオプションをサポートするようになり、ユーザーは次のことができるようになりました。 CalculateIsolines で、特定の移動時間または距離内のサービスエリアを特定する OptimizeWaypoints で最も効率的なウェイポイントの順序を決定し、移動時間または距離を最小限に抑える 通行料を計算して、有料道路を含むルートの正確なコスト見積もりを提供する SnapToRoads で地点を道路網にスナップすることで、GPS トレースを正確に照合する これらの機能により、ユーザーのためにより正確かつ動的なルートエクスペリエンスを設計できます。例えば、物流会社では、ライブ交通量を考慮して配達にかかる交通費を最小限に抑えながら、ドライバーのルートをリアルタイムで最適化できます。 Maps 更新された Amazon Location Maps API には、熟練した地図製作者によって作成された、用途に合ったマップスタイルが含まれています。これらのマップスタイルは、市場投入までの時間を短縮し、カスタムマップ作成の必要性を排除するプロフェッショナルなデザインを提供します。さらに、Static Map Image 機能により、開発者は静的マップをアプリケーション内で統合できるため、継続的なデータストリーミングの必要性が削減され、やりとりが不要なユースケースでのパフォーマンスが向上します。 Maps API の主な機能は次のとおりです。 GetTile で X、Y、Z 軸の値を指定して、タイルセットからタイルをダウンロードする GetStyleDescriptor でスタイルに関する情報を返す GetStaticMap で、レポートや視覚化を目的とした非インタラクティブなマップのレンダリングを可能にする Places Amazon Location Places API の強化によって、より詳細な検索機能が実現され、位置情報データをよりきめ細かいものにしてほしいというリクエストに対応できるようになりました。この新機能には以下のものが含まれます。 SearchNearby と Autocomplete が近接度ベースのクエリをサポートし、予測変換機能を有効にしたことによる、ユーザーエクスペリエンスの向上 関心のある地点の営業時間、連絡先情報、追加属性などのカテゴリを使用したビジネス詳細の強化 これらの機能は、フードデリバリーサービスや小売アプリケーションなど、ユーザーが近くの場所に関する詳細情報を必要とするアプリケーションで特に役立ちます。例えば、顧客がフードデリバリーアプリケーションを開き、 SearchNearby を使用して近くのレストランを検索し、営業時間や連絡先情報などのレストランの詳細を取得して空き状況を確認するとします。複数の配達注文がドライバーに割り当てられると、アプリケーションは OptimizeWaypoints を使用して、最も効率的な集荷および配達のルートを提案します。ドライバーがルートをたどると、 SnaptoRoads がドライバーの位置を正確に視覚化し、顧客によるリアルタイムの追跡体験を向上します。 Enhanced Location Service の実行 API の呼び出しは簡単です。 AWS コマンドラインインターフェイス (AWS CLI) 、当社の AWS SDK のいずれか、またはプレーンな REST API を使用できます。ただし、ウェブアプリまたはモバイルアプリのマップに情報を表示するには、追加の設定が必要です。このプロセスは詳しく説明されていますが、非常に詳細であるため、ここにすべて記載することはできません。このデモでは、API の使用に焦点を当てます。 Amazon Location Service では、API コールを AWS API 認証 ( AWS Sigv4 認証 ) または API キーを介する方法の 2 つの方法で認証できます。API キーは、エンドユーザーが認証されていないモバイルアプリケーションの開発者にとって、または Amazon Cognito との統合が不可能な場合に便利です。これはフロントエンドアプリケーションに推奨される認証方法です。 API の多様性と、アプリケーション内での統合がいかに簡単かを示すために、デモの各ステップで AWS CLI、cURL、グラフィカル REST API クライアントを組み合わせて使用します。 ステップ 1: API キーの作成 まず、AWS CLI を使用してアプリケーションの API キーを作成します。 AWS マネジメントコンソール で API キーを管理することもできます。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドによって API キーが生成され、これを使用して Amazon Location API を呼び出すことができます。 ステップ 2: 地理座標の取得 次に、 cURL を使用して GeoCode を呼び出し、 QueryText パラメータに住所を渡すことで、フランスのリール中心部の地理座標 ( 経度 と 緯度 ) を取得します。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これにより、市内中心部の GPS 座標 [3.06361, 50.63706] を含む複数のデータポイントが返されます。 ステップ 3: 近くの場所の検索 取得した座標を使用しながら、REST API クライアントツールを利用して SearchNearby API を呼び出し、リール中心部周辺の興味深い場所を見つけます。 画面の右側に、API レスポンスが表示されます。レストラン、銀行、駐車場などの近くの場所のリストです。カテゴリを指定したり、検索範囲を制限したりすることで、さらに検索を絞り込めます。 SearchNearby API では、バウンディングボックス内の検索を制限したり、ビジネスチェーン、カテゴリ、国、食品の種類を含めたり除外したりするのに役立つ、オプションの Filter パラメータを使用できます。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近くの関心のある場所を検索したところ、返された結果の 1 つは、国際的に有名なマクドナルドでした 。 ステップ 4: 道順の取得 最後に、AWS CLI を使用して 2 つの市内中心部 (ベルギーの ブリュッセル とフランスの リール ) 間のルートを計算します。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" レスポンスには、マップ上にパスをレンダリングするための ポリライン と、ルート案内のステップバイステップリストが含まれます。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ 5: マップでの道順の表示 マップ上のルートを視覚化するには、ウェブアプリケーションやモバイルアプリケーションでマップを表示するためのレンダリングエンジンである MapLibre ライブラリを使用します。 Amazon Location Service デベロッパーガイド の手順に沿って、ルートを表示する基本的なアプリを作成しました。 MapLibre に加えて、 AWS Amplify を使用してアプリケーションに Amazon Location データを統合して表示することもできます。 開始方法 これらの新規および更新された API を使用して、Amazon Location Service はお客様のビジネスニーズに応える、より包括的なマッピングおよびロケーションデータのスイートを提供します。これにより、開発者の俊敏性とスケーラビリティが向上し、開発ライフサイクルが加速されます。 はじめに、更新された Amazon Location Service デベロッパーガイド を確認し、今すぐこれらの機能の統合を開始してください。 Amazon Location Service ページ にアクセスして詳細を確認したり、お気に入りの AWS SDK で API を試して、アプリケーションをどのように強化できるかを確認したりすることもできます。 — seb 原文は こちら です。
11 月 7 日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新しいブローカータイプであるエクスプレスブローカーの一般提供について発表します。Apache Kafka を実行している標準ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、復旧時間が 90% 短縮されるように設計されています。エクスプレスブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、Kafka API をサポートし、Amazon MSK のお客様が期待するのと同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 エクスプレスブローカーを使用すると、Amazon MSK でプロビジョニングされたクラスターを使用する際に、Kafka アプリケーションのコンピューティングとストレージの伸縮性が向上します。Amazon MSK は、Apache Kafka をベースにした可用性が高くスケーラブルなアプリケーションを簡単に構築して実行できる、フルマネージド型の AWS サービスです。 エクスプレスブローカーが持つ主な機能と、享受できる利点について詳しく見ていきましょう。 ハンズフリーストレージ管理による運用の簡略化 – エクスプレスブローカーは、事前プロビジョニングなしで無制限のストレージを提供し、ディスク関連のボトルネックを解消します。クラスターのサイズ設定はより単純で、必要なのは入力と出力のスループットをブローカーごとの推奨スループットで割ったものです。これにより、プロアクティブなディスク容量の監視とスケーリングが不要になり、クラスター管理が簡素化され、潜在的な障害の原因が排除されることで耐障害性が向上します。 ブローカーの数が少なく、ブローカーあたりのスループットは最大 3 倍 – ブローカーあたりのスループットが高いほど、同じワークロードでクラスターを小さくできます。標準ブローカーのスループットはクライアントトラフィックとバックグラウンド操作を考慮に入れる必要があります。 m7g.16xl の標準ブローカーは 154 MBps の入力を安全に処理します。エクスプレスブローカーは独自の設定とリソース分離を採用しているため、 m7g.16xl サイズのインスタンスでは、クラスターイベント中にパフォーマンスや可用性を損なうことなく、最大 500 MBps の入力を安全に管理できます。 20 倍の高速スケーリングによる高い使用率 – エクスプレスブローカーはスケーリング中のデータ移動を減らし、標準ブローカーの最大 20 倍の速度を実現します。これにより、より迅速で信頼性の高いクラスターサイズ設定が可能になります。各ブローカーの入力スループットキャパシティを監視し、数分以内にブローカーを追加できるため、トラフィックの急増を見越してオーバープロビジョニングを行う必要がなくなります。 耐障害性が高く、復旧速度が 90% 向上 – エクスプレスブローカーは、高い耐障害性を必要とするミッションクリティカルなアプリケーション向けに設計されています。設定ミスによる障害を減らす 3 つの方法のレプリケーション (RF=3) など、ベストプラクティスがデフォルトであらかじめ設定されています。また、エクスプレスブローカーは、標準の Apache Kafka ブローカーと比較して、一時的な障害からの復旧が 90% 速くなります。エクスプレスブローカーの再調整と復旧は、最小限のクラスターリソースしか使用しないため、キャパシティプランニングが簡素化されます。これにより、リソース使用率が高まるリスクがなくなり、クラスターのサイズを適正化する際に継続的に監視する必要がなくなります。 Amazon MSK では、次のように、ワークロードと好みに応じてオプションを選択できます。 MSK プロビジョンド MSK Serverless 標準ブローカー エクスプレスブローカー 設定範囲 柔軟性が最も高い 柔軟 柔軟性が最も低い クラスターの再調整 カスタマーマネージド カスタマーマネージド ただし、最大で 20 倍速く MSK マネージド 容量管理 はい はい (コンピューティングのみ) なし ストレージ管理 はい なし なし エクスプレスブローカーは、コストを削減し、耐障害性を高め、運用上のオーバーヘッドを抑えることができるため、すべての Kafka ワークロードに最適な選択肢となっています。容量、設定、スケール方法の側面を一切管理せずに Kafka を使用したい場合は、 Amazon MSK Serverless を選択できます。これにより、完全に抽象化された Apache Kafka エクスペリエンスが提供され、インフラストラクチャの管理が不要になり、自動的にスケールされ、リソース利用を最適化する必要のない従量制料金の消費モデルで請求されます。 Amazon MSK のエクスプレスブローカーの開始方法 エクスプレスブローカーを使い始めるには、Amazon MSK が提供する サイズ設定と料金のワークシート を使用できます。このワークシートは、ワークロードに対応するために必要なクラスターサイズを見積もるのに役立ちます。また、発生する月次総コストのおおよその見積もりも得られます。 ワークロードのスループット要件は、クラスターのサイズを決定する主な要因です。クラスターに必要なブローカーのサイズと数を決定するには、パーティションや接続数などの他の要素も考慮する必要があります。例えば、ストリーミングアプリケーションで 30 MBps のデータ入力 (書き込み) と 80 MBps のデータ出力 (読み取り) の容量が必要な場合は、3 つの express.m7g.large ブローカーを使用してスループットのニーズを満たすことができます (ワークロードのパーティション数が、Amazon MSK が m7g.large インスタンスに推奨するパーティションの最大数以内であることを前提とします)。 次の表は、持続可能で安全な運用のための、インスタンスサイズあたりの推奨最大入力数、出力数、およびパーティション数を示しています。これらの推奨事項の詳細については、Amazon MSK デベロッパーガイドの ベストプラクティス セクションをご覧ください。 インスタンスサイズ 入力 (MBps) 出力 (MBps) express.m7g.large 15.6 31.2 express.m7g.4xlarge 124.9 249.8 express.m7g.16xlarge 500.0 1000.0 ワークロードに必要なエクスプレスブローカーの数とサイズを決定したら、 AWS マネジメントコンソール に移動するか、 CreateCluster API を使用して Amazon MSK でプロビジョニングされたクラスターを作成します。 Amazon MSK コンソール で新しいクラスターを作成するときに、 [Broker type] (ブローカータイプ) オプションで [Express brokers] (エクスプレスブローカー) を選択し、そのブローカーに対してプロビジョニングするコンピューティング容量の量を選択します。スクリーンショットでわかるように、エクスプレスブローカーには Apache Kafka 3.6.0 バージョンと Graviton ベースのインスタンスを使用できます。エクスプレスブローカーのストレージを事前にプロビジョニングする必要はありません。 また、これらの設定の一部をカスタマイズして、好みに応じてクラスターのパフォーマンスをさらにファインチューニングすることもできます。詳細については、Amazon MSK デベロッパーガイドの「 エクスプレスブローカーの設定 」を参照してください。 AWS コマンドラインインターフェイス (AWS CLI) で MSK クラスターを作成するには、 create-cluster コマンドを使用します。 aws kafka create-cluster \ --cluster-name "channy-express-cluster" \ --kafka-version "3.6.0" \ --number-of-broker-nodes 3 \ --broker-node-group-info file://brokernodegroupinfo.json brokernodegroupinfo.json という名前の JSON ファイルには、Amazon MSK にブローカーノードを分散させたい 3 つのサブネットを指定します。 { "InstanceType": "express.m7g.large", "BrokerAZDistribution": "DEFAULT", "ClientSubnets": [ "subnet-0123456789111abcd", "subnet-0123456789222abcd", "subnet-0123456789333abcd" ] } クラスターが作成されると、ブートストラップ接続文字列を使用してクライアントをクラスターエンドポイントに接続できます。 エクスプレスブローカーを使用すると、垂直方向にスケール (インスタンスサイズを変更) または水平方向にスケール (ブローカーを追加) できます。垂直スケーリングにより、パーティションを再割り当てしなくてもスループットが 2 倍になります。水平スケーリングではブローカーが 3 つセットで追加され、さらに多くのパーティションを作成できますが、新しいブローカーがトラフィックを処理するにはパーティションを再割り当てする必要があります。 エクスプレスブローカーの主な利点は、数分以内にブローカーを追加してパーティションを再調整できることです。一方、標準ブローカーを追加した後のパーティションの再調整には数時間かかることがあります。以下のグラフは、クラスターに 3 つのエクスプレスブローカーを追加し、各新しいブローカーに 2000 個のパーティションを再割り当てした後に、パーティションの再調整にかかった時間を示しています。 ご覧のように、これらのパーティションを再割り当てして新しいブローカーの追加容量を活用するのに約 10 分かかりました。標準ブローカーで構成される同等のクラスターで同じ実験を行ったところ、パーティションの再割り当てには 24 時間以上かかりました。 パーティションの再割り当ての詳細については、Apache Kafka ドキュメントの「 クラスターの拡張 」を参照してください。 知っておくべきこと エクスプレスブローカーについて知っておくべきことは次のとおりです。 データ移行 – Amazon MSK Replicator を使用して、既存の Kafka または MSK クラスターのデータをエクスプレスブローカーで構成されるクラスターに移行できます。これにより、クラスターのデータとメタデータの両方が新しいクラスターにコピーされます。 モニタリング – クラスター内のエクスプレスブローカーで構成されるクラスターを Amazon CloudWatch メトリクスを使用してブローカーレベルでモニタリングできます。また、Prometheus によるオープンモニタリングを有効にして、JMX エクスポーターとノードエクスポーターを使用してメトリクスを公開できます。 セキュリティ – 他のブローカータイプと同様に、Amazon MSK は AWS Key Management Service (AWS KMS) と統合して、エクスプレスブローカーのストレージを透過的にサーバー側で暗号化します。エクスプレスブローカーを使用して MSK クラスターを作成するときに、Amazon MSK が保管中のデータの暗号化に使用する AWS KMS キーを指定できます。KMS キーを指定しない場合、Amazon MSK が AWS マネージドキーを作成し、ユーザーに代わって使用します。 今すぐご利用いただけます エクスプレスブローカータイプは、11 月 7 日より米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の各リージョンでご利用いただけます。 エクスプレスブローカーの Apache Kafka ブローカーインスタンスの使用に対して時間単位の料金 (1 秒単位で請求) が発生します。手数料は、MSK クラスター内のブローカーインスタンスとアクティブなブローカーの規模によって異なります。また、エクスプレスブローカーに書き込まれるデータの GB 単位の料金 (バイト単位の解像度で請求) もお支払いいただきます。詳細については、「 Amazon MSK の料金 」ページにアクセスしてください。 Amazon MSK コンソール で Amazon MSK のエクスプレスブローカーをお試しください。詳細については、 Amazon MSK デベロッパーガイド をご覧ください。また、 AWS re:Post for Amazon MSK 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。