このブログ記事は、トヨタ自動車 社会システム PF 開発部 坪田 沙弥香氏 とアマゾン ウェブ サービス ジャパン シニアソリューションアーキテクト 安藤 正祥、 同社 クラウドインフラアーキテクト 笹原 悠馬が共同で執筆し、トヨタ自動車が監修しています。 イントロダクション トヨタ自動車 (以下、トヨタ) は、大阪府堺市と共に現場状況が分かりにくい交通事故などの緊急を要する事案に対して、現場付近を走行する車両のドライブレコーダーの映像を活用する共同実証実験を行っています。 本記事では、トヨタがアマゾン ウェブ サービス (AWS) を活用し、「消防向けドラレコ映像活用システム（以下、消防ドラレコ）」を開発した事例についてご紹介します。 トヨタイムズニュース「人命救助へ1分1秒　交通死傷者ゼロへ堺市と協同 (toyotatimes.jp) 」 2024 年 3 月 18 日掲載 トヨタイムズニュース「堺市消防局とトヨタの新たな挑戦　火災や事故でドラレコ活用 (toyotatimes.jp) 」 クルマのデータ活用が示す可能性。お客様に安心・安全を贈るためのモビリティサービス｜トヨタ自動車株式会社｜就活・転職活動に役立つキャリア学習サイト (talent-book.jp) 背景 119 番通報は、災害現場に直面し心理的に余裕がない方からの通報も多く、現場状況を正しく把握できないことがあり、その結果として消防隊は現場に到着してから、緊急車両の追加出動や装備の見直しをすることもあります。消防ドラレコは、消防指令センターのオペレーターが 119 番通報だけで現場状況の把握が難しい場合、付近を走る車両のドラレコ映像を活用し、迅速かつ適切な消火、救急、救助活動に役立てるものです。 ソリューションの概要 119 番通報だけでは把握しきれない現場の状況をより正確につかむために、消防指令センターのオペレーターが消防ドラレコを通じて付近の車両の映像を閲覧します。現在、共同実証中の堺市では、協力企業と連携し、堺市消防局管内を走るバスやトラックなど約 400 台に搭載したドライブレコーダーからの映像を活用しております。 システムの特長（情報の流れイメージ） 出典：トヨタ 119 番の通報内容から消防指令センターのオペレーターが事故などの発生場所を特定 消防指令センターのオペレーターが現場の映像を必要とする事案か判断 2 で必要と判断した場合、システムにて事案発生地点を検索 GPS 情報を利用し、付近を走行するドライブレコーダー装着車両を選定 対象車両のドライブレコーダー映像を取得 消防指令センターでドライブレコーダー映像を確認し、迅速で適切な対応につなげる プライバシー尊重への取り組み 消防ドラレコではバスやトラック等の法人車両に約 400 台の専用ドライブレコーダーを設置し、その映像を活用しています。映像に対してプライバシーへの配慮を施した上で、データを暗号化し保管しています。また、映像には必然的に様々なものが映り込みますので、同じくプライバシーへの配慮に慎重に対応する必要があります。トヨタでは消防向けドラレコ映像活用システムについて、自社で定めるガイドラインに準拠するとともに、映像データに対してプライバシーに配慮した処置を施した上で、データを期限付きで保管するようにしています。これらの映像は、AWS のストレージサービス Amazon S3 に暗号化した状態で保管されていますが、S3 のライフサイクルのルールを活用して保管期限が過ぎたら自動的に削除されます。データベースでは Amazon DynamoDB を活用し、同じく保管期限が過ぎた項目を自動的に削除するように有効期限 (TTL: Time to Live) の機能を活用しています。 一方で人命救助に関わる状況ではより早く消防局に映像を安定的に提供することが期待されます。AWS のサーバーレスサービスを活用することで消防システムに配慮した可用性を実現しています。また、イベント駆動型アーキテクチャを採用することで、スケーラビリティを確保しながらも、プライバシーへの配慮に必要な処置を施しつつ、迅速な映像提供が可能になります。このように、AWS のサーバーレスサービスとイベント駆動型アーキテクチャの採用により、可用性と拡張性の両方が確保されています。 アーキテクチャ概略図 また、トヨタは有識者からのアドバイスのもと、市民への社会受容性調査を実施し、下記 3 点に配慮した上で映像を堺市消防局に提供しています。 堺市消防局で映像は保存せず、専用端末を介し、一時的な閲覧のみを可能にして提供 堺市消防局より閲覧要望のあった地点・時間のドラレコ映像のみを提供 映像に映り込んだ人や車両について個別に追跡したり、その行動特性や移動傾向等を分析したりすることを禁止 リーンな開発プロセス 消防ドラレコの開発は、まず短い期間で MVP (Minimum Viable Product) を開発した後、頻繁にシステムの改修を行いユーザーからのフィードバックを得る、リーン開発で進められています。MVP の開発において、 AWS プロフェッショナルサービス が主に AWS のアーキテクチャ構築への支援と、イテレーティブな開発プロセス習得の支援を行っています。 AWS のアーキテクチャ構築にあたり、AWS のアーキテクトはまず、トヨタの多岐にわたる技術課題を理解した後、それらの課題を解決する柔軟なアーキテクチャの検討を行いました。その結果、トヨタの消防ドラレコには、機能改修のリードタイムを短縮するために、コンピュートには AWS Lambda を、データベースには Amazon DynamoDB と、開発者がアプリケーション開発に注力できるようサーバーレスアーキテクチャが採用されています。また、インフラについては、AWS の各種マネージドサービスを活用することで、データの可用性や拡張性などの非機能要件を AWS で担保しながら、差別化につながらないシステムの維持運用の負荷をオフロードしています。例えば、データのバックアップは、マネージドサービスの機能を用いて行うことで、インフラを追加構築することなく設定のみで実現しています。さらに、エラーや障害の情報は、 Amazon CloudWatch と AWS Chatbot を組み合わせることで、アプリケーションを追加で開発することなく社内のチャットツールに通知をしています。 トヨタは、消防ドラレコの限られた検証期間を最大限活用するために、要件定義、設計、実装、テスト、リリース、ユーザーからのフィードバックをもとにした改善を素早く繰り返すイテレーティブな開発フレームワークとして、スクラムを取り入れています。 AWS プロフェッショナルサービス は、スクラムマスターに各セレモニーのファシリテーションやチーム内の課題管理などスクラムマスターとしての動き方についてコーチングを行うなど、トヨタの開発チームが、スクラムによるイテレーティブな開発プロセスを学び実践するためのトレーニングの提供などの支援を行っています。 このように AWS プロフェッショナルサービス の包括的な支援により、消防ドラレコの初期のシステム開発は迅速かつ短期間に進められ、加えて、トヨタの開発チームは、支援を受けている期間に獲得した AWS 活用に関するナレッジやスキルを継続してその後の開発にも生かし、実装に向けた取り組みを加速させています。 結び トヨタが大阪府堺市と共に取り組む消防向けドラレコ映像活用システムの AWS 活用事例は、車両のドラレコ映像を活用し、迅速かつ適切な消火、救急、救助活動に役立てることで社会に貢献していく願いが込められたものです。 AWS は、社会課題の解決とよりよい暮らしの実現に向け、モビリティ社会の究極の願いである「交通死傷者ゼロ」への取り組みを続けるトヨタへの支援を一層強化していきます。 シニアソリューションアーキテクト 安藤 正祥 クラウドインフラアーキテクト 笹原 悠馬

建築、エンジニアリング、建設 (AEC) や メディア & エンターテイメント (M&E) などの業界のお客様は、映画、テレビ、ゲーム、工業デザインのビジュアライゼーション、および 2D/3D デジタルコンテンツデータを取得して、画像や動画ファイルなどの出力を計算するレンダリングと呼ばれるプロセスを伴うデジタルメディア向けに最終フレームを生成します。また、特に映画やテレビ向けに 16K もの高解像度の 3D グラフィックスや視覚効果 (VFX) を生成するために、レンダリングにはかなり高いコンピューティング性能も必要です。これにより、お客様が一度に実行できるレンダリングプロジェクトの数が制限されます。 高解像度コンテンツのレンダリングに対する需要の高まりに対応するために、お客様は多くの場合、数百または数千のコンピューティングノードの性能を組み合わせてレンダリングジョブを処理する、いわゆる「レンダーファーム」を構築します。従来、レンダーファームの構築とデプロイには数週間、場合によっては数か月間かかる場合があり、ハードウェアを調達するために多大な計画と事前の取り組みが必要となります。 その結果、効率的な制作のために、お客様はますます、非常に高額な固定費が必要となる可能性のあるオンプレミスの専用レンダーファームではなく、スケーラブルなクラウドベースのレンダーファームに移行しています。しかし、クラウドでのレンダリングでは、依然としてお客様が独自のインフラストラクチャを管理し、プロジェクトごとにコストを管理するための特別なツールを構築するとともに、優先パートナーから提供されるソフトウェアライセンスのコストを自らモニタリングする必要があります。 4月2日、 AWS Deadline Cloud の一般提供の開始を発表しました。これは、クリエイティブチームが数分でレンダーファームを簡単に設定し、より多くのプロジェクトを並行して実行できるようにスケールしながら、使用したリソースについての料金のみを支払うことを可能にする、新しいフルマネージドサービスです。AWS Deadline Cloud は、レンダーファームの作成と管理、進行中のレンダーのプレビュー、レンダーログの表示と分析、およびこれらのコストの簡単な追跡を行う機能を備えたウェブベースのポータルを提供します。 Deadline Cloud を利用すると、デジタルコンテンツ作成 (DCC) ツールの統合とカスタマイズツールが組み込まれているため、ゼロからレンダリングを高速化できます。各ジョブのニーズに合わせてレンダリングパイプラインをカスタマイズするために必要な労力と開発時間を削減できます。また、既に所有しているライセンスを柔軟に使用することも、サードパーティーの DCC ソフトウェアやレンダラー ( Maya 、 Nuke 、 Houdini ) 用のサービスによって提供されるライセンスを使用することもできます。 AWS Deadline Cloud の概念 AWS Deadline Cloud を利用すると、DCC パイプラインやワークステーションから直接、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上でレンダリングプロジェクトやジョブを作成および管理できます。レンダーファーム、キューのコレクション、フリートを作成できます。キューは、送信されたジョブが配置され、レンダリングがスケジュールされる場所です。フリートは、複数のキューをサポートできるワーカーノードのグループです。キューは複数のフリートで処理できます。 プロジェクトに取り組む前に、必要なリソースにアクセスできる必要があります。また、ワークフォースの認証と認可を管理するには、関連付けられたファームを AWS IAM アイデンティティセンター と統合する必要があります。IT 管理者は、閲覧者、コントリビューター、マネージャー、所有者など、さまざまなレベルのユーザーやグループに対して、アクセス許可を作成したり、付与したりできます。 Deadline Cloud の 4 つの主要なコンポーネントは次のとおりです。 Deadline Cloud モニター – ジョブ、ステップ、タスクのステータス、ログ、他のトラブルシューティングメトリクスにアクセスできます。Deadline Cloud モニターは、ジョブの進行状況に対するリアルタイムのアクセスと更新を提供します。また、ログや他のトラブルシューティングメトリクスに対するアクセスも提供し、複数のファーム、フリート、キューのリストを閲覧してシステム使用率を確認することもできます。 Deadline Cloud サブミッター – AWS SDK または AWS コマンドラインインターフェイス (AWS CLI) を使用してレンダリングジョブを直接送信できます。Deadline Cloud サブミッターを使用して DCC ソフトウェアから送信することもできます。Deadline Cloud サブミッターは、オープンソースのテンプレート仕様である Open Job Description (OpenJD) をサポートする DCC 統合プラグインです。これを使用すると、アーティストは Maya や Nuke などの使い慣れたサードパーティーの DCC インターフェイスから Deadline Cloud にレンダリングジョブを送信でき、そこでプロジェクトリソースが管理され、ジョブが 1 か所でモニタリングされます。 Deadline Cloud 予算マネージャー – プロジェクトのコスト管理に役立てるために予算を作成および編集したり、使用されている AWS リソースの数とそれらのリソースの推定コストを表示したりできます。 Deadline Cloud 使用状況エクスプローラー – 使用状況エクスプローラーを使用すると、Amazon EC2 の公開料金レートと使用状況ベースのライセンス (UBL) に基づいて、おおよそのコンピューティングコストとライセンスコストを追跡できます。 AWS Deadline Cloud の利用を開始する AWS Deadline Cloud の利用を開始するには、Deadline Cloud モニターを使用してファームを定義および作成し、Deadline Cloud サブミッターをダウンロードして、お気に入りの DCC アプリケーション用のプラグインをわずか数回のクリックでインストールします。DCC アプリケーションでレンダリングジョブを定義し、プラグインのユーザーインターフェイス内で作成したファームにそれらのジョブを送信できます。 DCC プラグインは、必要な入力シーンデータを検出し、アカウント内の Amazon Simple Storage Service (Amazon S3) バケットにアップロードするジョブバンドルを構築して、ジョブをレンダリングするために Deadline Cloud に転送し、完成したフレームを S3 バケットに提供して、顧客がアクセスできるようにします。 1.Deadline Cloud モニターを使用してファームを定義する まず、Deadline Cloud モニターインフラストラクチャを作成し、ファームを定義しましょう。 Deadline Cloud コンソール で、 [Deadline Cloud を設定] を選択して、キューとフリート、グループとユーザーの追加、サービスロールの選択、タグのリソースへの追加など、ガイド付きエクスペリエンスを使用してファームを定義します。 このステップでは、Deadline Cloud リソースのすべてのデフォルト設定を選択するために、モニターの設定後のステップ 3 で [レビューにスキップ] を選択します。それ以外の場合は、 [次へ] を選択して、Deadline Cloud リソースをカスタマイズします。 モニターのインフラストラクチャを設定し、 [モニターの表示名] を入力します。この名前により、ファーム、キュー、フリート、使用状況を管理するためのウェブポータルである [モニター URL] が作成されます。設定完了後は、モニター URL を変更することはできません。 AWS リージョン はレンダーファームの物理的な場所であるため、レイテンシーを低減し、データ転送速度を向上させるには、スタジオに最も近いリージョンを選択する必要があります。 モニターにアクセスするために、新しいユーザーとグループを作成して、ユーザーを管理したり (グループ、許可、アプリケーションを割り当てるなど)、モニターからユーザーを削除したりできます。ユーザー、グループ、許可は IAM アイデンティティセンターで管理することもできます。そのため、リージョンで IAM アイデンティティセンターを設定していない場合は、最初にそれを有効にする必要があります。詳細については、AWS ドキュメントの「 Managing users in Deadline Cloud 」にアクセスしてください。 ステップ 2 では、ファームの名前や説明などのファームの詳細を定義できます。 [追加ファームの設定] では、 AWS Key Management Service (AWS KMS) キーを設定してデータとタグを暗号化し、リソースのフィルタリングや AWS コストの追跡のために AWS リソースを割り当てることができます。データはデフォルトで、AWS が所有および管理するキーを使用して暗号化されます。別のキーを選択するには、暗号化設定をカスタマイズします。 [レビューおよび作成にスキップ] を選択すると、デフォルト設定を使用してクイック設定プロセスを完了できます。 さらにオプションの設定を見てみましょう。 キューの詳細を定義するステップでは、キューのために S3 バケットを設定できます。ジョブアセットは、レンダリングプロセス中にジョブのアタッチメントとしてアップロードされます。ジョブのアタッチメントは、定義された S3 バケットに保存されます。さらに、キューのデフォルトの予算アクション、サービスアクセスロール、環境変数を設定できます。 フリートの詳細を定義するステップでは、フリート名、説明、 インスタンスオプション (スポットインスタンスまたはオンデマンドインスタンスのいずれか)、およびインスタンスの数とフリートワーカーの要件を定義するための 自動スケーリング 構成を設定します。デフォルトでは、保守的なワーカー要件が設定されています。これらの値は、レンダーファームを設定した後でいつでも更新できます。詳細については、AWS ドキュメントの「 Manage Deadline Cloud fleets 」にアクセスしてください。 ワーカーインスタンスは、vCPU とメモリサイズを使用して EC2 インスタンスタイプを定義します (例: c5.large 、 c5a.large 、 c6i.large )。ワーカーインスタンスのタイプを許可または除外することで、最大 100 個の EC2 インスタンスタイプをフィルタリングできます。 ファームを作成するために入力したすべての情報を確認し、 [ファームを作成] を選択します。 Deadline Cloud オンボーディングの進行状況が表示され、モニターとファームが使用できる状態になると成功メッセージが表示されます。プロセスの詳細については、AWS ドキュメントの「 Set up a Deadline Cloud monitor 」にアクセスしてください。 左側のペインの [ダッシュボード] で、作成したモニター、ファーム、ユーザー、グループの概要にアクセスできます。 [モニター] を選択してウェブポータルにアクセスし、ファーム、キュー、フリート、使用状況、予算を管理します。ユーザーアカウントにサインインした後、ウェブポータルにアクセスして、作成した Deadline Cloud リソースを探すことができます。 [ダウンロード] ページから、同じユーザーエクスペリエンスを備えた Deadline Cloud モニターデスクトップアプリケーションをダウンロードすることもできます。 モニターの使用方法の詳細については、AWS ドキュメントの「 Using the Deadline Cloud monitor 」にアクセスしてください。 2.ワークステーションを設定し、レンダリングジョブを Deadline Cloud に送信する アーティストが Maya、Nuke、Houdini 内からレンダリングジョブを簡単に送信できるように、Deadline Cloud サブミッターアプリケーションをインストールして、デスクトップでアーティストのためのワークステーションを設定しましょう。左側のメニューペインで [ダウンロード] を選択し、オペレーティングシステムに適したサブミッターインストーラーをダウンロードして、レンダーファームをテストします。 このプログラムは、Maya、Nuke、Houdini 用に Deadline Cloud サブミッター向けの最新の統合プラグインをインストールします。 例えば、デスクトップで Maya とアセットを開きます。テストするレンチファイルのサンプルがあります。メニューバーで [Windows] を選択し、サブメニューで [設定/詳細設定] を選択します。 [プラグインマネージャー] で、 DeadlineCloudSubmitter を検索します。 [ロード済み] を選択して、Deadline Cloud サブミッタープラグインをロードします。 Deadline Cloud サブミッターでまだ認証されていない場合は、 [Deadline Cloud ステータス] タブが表示されます。 [ログイン] を選択し、ブラウザのサインインウィンドウでユーザー認証情報を使用してサインインします。 次に、Deadline Cloud シェルフを選択し、「Deadline」シェルフにあるオレンジ色の Deadline Cloud のロゴを選択してサブミッターを起動します。サブミッターウィンドウから、レンダリングの送信先のファームとキューを選択します。必要に応じて、 [シーン設定] タブでフレーム範囲をオーバーライドしたり、 [出力パス] を変更したり、その両方を行ったりできます。 [送信] を選択すると、レンチターンテーブル Maya ファイルが、必要なすべてのテクスチャおよび Alembic キャッシュとともに Deadline Cloud にアップロードされ、ファームでレンダリングされます。Deadline Cloud モニターでレンダリングジョブをモニタリングできます。 レンダリングが完了したら (ジョブモニターの [成功] ステータスで示されます)、ジョブ、 [ジョブアクション] 、および [ダウンロード出力] を選択します。ジョブのスケジューリングとモニタリングの詳細については、AWS ドキュメントの「 Deadline Cloud jobs 」にアクセスしてください。 DJView などの画像表示アプリケーションを使用して、レンダリングされた画像を表示します。画像は次のようになります。 コマンドラインを使用したデベロッパー側の設定プロセスの詳細については、AWS ドキュメントの「 Setting up a developer workstation for Deadline Cloud 」にアクセスしてください。 3.Deadline Cloud の予算と使用状況の管理 Deadline Cloud のコスト管理をサポートするために、予算マネージャーを使用して予算を作成および編集できます。また、使用状況エクスプローラーを使用して、使用されている AWS リソースの数とそれらのリソースの推定コストを表示することもできます。 ファームの予算を作成するには、Deadline Cloud モニターページで [予算] を選択します。 予算の金額と制限を作成し、自動アクションを設定して、予算を超過する支出を削減または停止できます。 Deadline Cloud モニターページで [使用状況] を選択すると、各ファームで発生しているアクティビティに関するリアルタイムメトリクスが表示されます。ファームのコストをキュー、ジョブ、ユーザーなどのさまざまな変数ごとに確認できます。さまざまな時間枠を選択して、特定の期間中の使用状況を検索し、一定期間における使用状況の傾向を確認できます。 使用状況エクスプローラーに表示されるコストは概算です。リソースを管理するためのガイドとしてご利用ください。Amazon S3、 Amazon CloudWatch 、および使用状況エクスプローラーでは考慮されていない他のサービスなど、接続されている他の AWS リソースの使用により、他のコストが発生する可能性があります。 詳細については、AWS ドキュメントの「 Managing budgets and usage for Deadline Cloud 」にアクセスしてください。 今すぐご利用いただけます AWS Deadline Cloud は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、および欧州 (アイルランド) リージョンでご利用いただけます。 Deadline Cloud コンソール で AWS Deadline Cloud をぜひお試しください。詳細については、 Deadline Cloud の製品ページ や AWS ドキュメントの「 Deadline Cloud ユーザーガイド 」にアクセスしてください。また、 AWS Deadline Cloud の AWS re:Post 宛てに、または通常の AWS サポートの連絡先担当者を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

この記事は、 Geospatial generative AI with Amazon Bedrock and Amazon Location Service を翻訳したのものです。 通常、地理空間ワークフローは、データを読み込んで変換し、地図、テキスト、グラフなどに可視化します。生成系 AI、自律型 エージェント を利用すると、これらのタスクを自動化できます。このブログでは、 Amazon Bedrock の基盤モデルからパワーエージェントまで、地理空間タスクを完了する方法について説明します。 これらのエージェントは、 Amazon Location Service を通じて利用できるジオコーディングなどのロケーションベースのサービスを使用して、さまざまなタスクを実行し、質問に答えることができます。エージェントを使用して Amazon Bedrock と Amazon Location Service の機能を橋渡しするサンプルコードを示し、構築時の設計における考慮事項について説明します。 Amazon Bedrockは、テキスト、画像、Embedding のための基礎モデルにアクセスするための使いやすい API を提供するフルマネージドサービスです。Amazon Locationは、Esri、HERE、Grab、OpenStreetMap などの信頼できるサードパーティから提供されたデータを使用して、地図、場所、ルーティング用の API を提供しています。 インフラストラクチャを完全に制御する必要がある場合は、 Amazon SageMaker JumpStart を使用することで、基盤モデルをデプロイでき、何百ものモデルにアクセスできます。 ソリューション概要 大規模言語モデル (LLM) の領域では、エージェントは LLM の助けを借りて自律的に推論してタスクを完了できるエンティティです。LLM はテキスト生成だけにとどまらず、会話を行ったり、ドメイン固有のタスクを完了できます。この動作を導くために推論パターンを採用しています。 研究論文「 Large Language Models are Zero-Shot Reasoners 」によると、LLM は知識の限界があるにもかかわらず、高レベルの推論に優れていることが分かります。 私たちは地理空間タスクを処理できるエージェントを作成するために、Amazon Bedrock の基盤モデルである Claude 2 を選択しました。全体的なコンセプトは単純明快で「地理空間データサイエンティストのように考えること」です。 このタスクには、データを読み取って変換し、関心を引くマップに視覚化する Python コードを書く必要があります。そのために Plan-and-Solve Prompting と呼ばれるプロンプトパターンを利用しました。 Plan-and-Solve 戦略を使用すると、最初のタスクとして複数のステップで推論し大まかな計画を立てることができます。これは、エージェントが使用する大まかな計画で、読み込み、変換、視覚化のワークフローに適しています。これらのサブタスクはそれぞれ Claude 2 に送られ、それぞれ解決されます。 ニューヨークにおける Inside Airbnb のリストプライスヒートマップを作成するサンプルタスクを考えてみます。タスクを完了するためのパスを計画するには、エージェントはデータセットを理解する必要があります。エージェントは、データセットの列とデータ型を知る必要があります。データセットからサマリーを生成して、エージェントがユーザーから指示されたタスク (ヒートマップの生成) を計画できるようにします。 前提条件 デモをデプロイするには、いくつかの前提条件があります。 アクセスキー のある AWS アカウント、または、Amazon Bedrock と Amazon Location Service へのアクセス権限のある AWS Identity and Access Management (IAM) ロール が必要になります。Amazon Location Service コンソールを使用して、 マップ 、 プレースインデックス 、および、 Amazon Location Service API キー を作成する必要があります。 また、Docker がインストールされているローカル環境か仮想環境が必要です。今回のデモンストレーションでは、Docker がインストールされた Amazon Linux の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用します。 データを読み込み要約する データセットに関するコンテキストをエージェントに渡すために、データを読み取り、タスクに関連する要約を提供できる Python コードを Claude 2 に生成させます。以下は、プロンプトの一部です。 全プロンプトはプロジェクトの prompts.py ファイルにあります。 Your Role: You are a geospatial data analyzer designed to analyze data schema from arbitrary geospatial datasets. Your Task: You are provided a set of file URLs. You need to generate a Python function that meets the following: Read each file using geopandas. Each file could be CSV, shape file, or GeoJSON. Use built-in function resolved_file_url = get_data_file_url ( file_url, session_id ) to get downloadable URLs. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import geopandas as gpd import pandas as pd import numpy as np def analyze_geospatial_data ( file_urls ) : dataframes = [ ] for file_url in file_urls : resolved_file_url = get_data_file_url ( file_url , 'a5b188fe-91f7-4f92-92fe-c4030721a427' , 'local' ) if file_url . endswith ( '.csv' ) : df = pd . read_csv ( resolved_file_url ) elif file_url . endswith ( '.shp' ) : df = gpd . read_file ( resolved_file_url ) elif file_url . endswith ( '.parquet' ) : df = pd . read_parquet ( resolved_file_url ) elif file_url . endswith ( '.geojson' ) : df = gpd . read_file ( resolved_file_url ) else : raise ValueError ( 'Unsupported file format' ) df = df . sample ( n = 3 , random_state = 42 ) dataframes . append ( { 'file_url' : file_url , 'resolved_file_url' : resolved_file_url , 'data_frame' : df , 'column_names' : list ( df . columns ) } ) return dataframes file_urls = [ 'agent://airbnb_listings_price.csv' ] dataframes = analyze_geospatial_data ( file_urls ) Python agent:// プレフィックスは、このファイルがセッションストレージフォルダー内に保存されていることを CLI に指示します。CLI が実行されると、ローカルデータを保存するための geospatial-agent-session-storage フォルダーが作成されます。エージェントは、アップロードされた Airbnb のデータとその列名を認識します。次に、Claude へ依頼するため、これらのインプットを使用してヒートマップを生成するためのヒントをプロンプトに渡します。 Your Role: You are a geospatial data analyzer designed to analyze data schema from arbitrary geospatial data sets. Your Task: You are provided with a table with some rows data. Your task is to generate a summary that describes the data in the table following the requirements below. The first sentence should be summary of the data in the table from the aspect of the user action. If there is no geometry column in the table, the second sentence should note column names that can be used to generate a geometry column in geopandas. Bash Claude 2 は以下のヒントを返します。 Summary: The table contains columns for listing id, name, host id, host name, location details like neighborhood, latitude, and longitude that can be used to generate a geometry column for plotting. Price column contains listing price that can be used to generate a heatmap of listing prices. Bash ソリューションを計画する Claude 2 に大まかな計画を生成してもらいます。Python の NetworkX というグラフライブラリを使うと、問題解決の手順を計画できます。 前回のプロンプトと同様に、Claude 2 のガイドとなるいくつかの条件を渡します。 Your Role: You are a geospatial data scientist and an expert Python developer. Your Task: A series of consecutive steps. Your Reply needs to meet these requirements: Create a single NetworkX graph. No disconnected components allowed. First operations are data loading. Use geopandas for spatial data. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import networkx as nx G = nx . DiGraph ( ) # Load the data G . add_node ( "airbnb_data_url" , node_type = "data" , data_path = "agent://airbnb_listings_price.csv" , description = "URL for Airbnb listing price data" ) G . add_node ( "load_data" , node_type = "operation" , operation_type = "load" , description = "Load the Airbnb listing price data" ) G . add_edge ( "airbnb_data_url" , "load_data" ) G . add_node ( "airbnb_df" , node_type = "data" , description = "Pandas DataFrame containing Airbnb listing prices" ) G . add_edge ( "load_data" , "airbnb_df" ) # Transform the data G . add_node ( "add_geometry" , node_type = "operation" , operation_type = "transform" , description = "Create a geometry column using latitude and longitude" ) G . add_edge ( "airbnb_df" , "add_geometry" ) G . add_node ( "airbnb_gdf" , node_type = "data" , description = "GeoDataFrame with geometry column added" ) G . add_edge ( "add_geometry" , "airbnb_gdf" ) # Visualize the data G . add_node ( "plot_heatmap" , node_type = "operation" , operation_type = "visualization" , description = "Generate a heatmap of listing prices" ) G . add_edge ( "airbnb_gdf" , "plot_heatmap" ) G . add_node ( "price_heatmap" , node_type = "data" , description = "The heatmap plot showing Airbnb listing prices" ) G . add_edge ( "plot_heatmap" , "price_heatmap" ) Python この NetworkX グラフでは、Claude 2 がプロセスを主に 3 つのセグメントに分解します。 データの読み込み — Airbnb のリストプライスを特定の URL から Pandas データフレームにインポートする データの変換 — 緯度と経度の座標に基づいたジオメトリ列の作成 データの視覚化 — Airbnb のリストプライスを表示するヒートマップの生成 このアプローチにより、地理空間タスクを明確かつ簡単に実装できます。 GraphViz を使用すると、以下のワークフローを視覚化できます。 計画を実行する Claude 2 から生成された計画を実行します。各ステップで Claude 2 に対応するコードを記述します。Claude 2 に焦点を絞るために、各タスクに大まかな条件を設けています。Claude 2 がそれぞれのフェーズで生成したコードについて詳細を説明します。 データの読み込む Airbnb のリストプライスのデータを Pandas DataFrame にロードするには、プロンプトを作成しいくつかのパラメーターを渡します。 Operation_task の「Load Airbnb data」は、上のグラフの load_data ノードを指しています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Load Airbnb data. Your Reply needs to meet these requirements: The function definition is: load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) . When doing spatial joins, retain at least 1 geometry column. Point function requires importing shapely library. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import pandas as pd def load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) : """ Load Airbnb listing price data """ file_url = get_data_file_url ( airbnb_data_url , session_id , storage_mode ) airbnb_df = pd . read_csv ( file_url ) return airbnb_df Python データの変換 次に、Claude 2 は、 latitude と longitude を使用して DataFrame に geometry 列を追加するコードを生成します。このプロンプトでは、以下の条件を設けています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Add geometry column from latitude/longitude. Your Reply needs to meet these requirements: The function definition is: add_geometry ( filtered_df ) . The function return line is: return airbnb_gdf. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import geopandas as gpd from shapely . geometry import Point def add_geometry ( airbnb_df ) : """ Add geometry column from latitude and longitude """ airbnb_df [ 'geometry' ] = airbnb_df . apply ( lambda row : Point ( row [ 'longitude' ] , row [ 'latitude' ] ) , axis = 1 ) airbnb_gdf = gpd . GeoDataFrame ( airbnb_df , geometry = 'geometry' ) return airbnb_gdf Python データの視覚化 最後に、Claude 2 は空間レンダリング用の Python ライブラリである pydeck を使用してヒートマップを生成します。このプロンプトでは、以下の条件を設けています。 Your Role: You are a geospatial data scientist and an expert Python developer. Operation_task: You need to generate a Python function to do: Generate heatmap from price. Your Reply needs to meet these requirements: The function definition is: generate_heatmap ( airbnb_gdf ) . The function return line is: return airbnb_heatmap. Bash これらのプロンプトから Claude 2 は以下の Python コードを生成します。 import pandas as pd import geopandas as gpd import pydeck as pdk def plot_heatmap ( airbnb_gdf ) : """ Plot heatmap of listing prices """ price_heatmap = pdk . Deck ( map_style = location_map_style ( ) , initial_view_state = pdk . ViewState ( latitude = airbnb_gdf [ 'latitude' ] . mean ( ) , longitude = airbnb_gdf [ 'longitude' ] . mean ( ) , zoom = 11 , pitch = 50 , ) , layers = [ pdk . Layer ( 'HexagonLayer' , data = airbnb_gdf , get_position = [ 'longitude' , 'latitude' ] , radius = 100 , elevation_scale = 4 , elevation_range = [ 0 , 1000 ] , pickable = True , extruded = True , ) , pdk . Layer ( 'ScatterplotLayer' , data = airbnb_gdf , get_position = [ 'longitude' , 'latitude' ] , get_color = '[200, 30, 0, 160]' , get_radius = 200 , ) , ] , ) # Save heatmap HTML price_heatmap . to_html ( get_local_file_path ( 'airbnb_heatmap.html' , session_id , task_name ) ) return price_heatmap Python Claude 2 の応答には、各関数が指定された条件をどのように満たすかを説明する役立つメモも含まれています。たとえば、ヒートマップの視覚化では Claude 2 は次の点に注目しました。 "This function generates a heatmap of Airbnb listing prices using pydeck and saves the resulting HTML locally. It fulfills the requirements specified in the prompt." 生成されたコードを組み立てる Claude 2 がそれぞれの構成要素を生成したのでまとめます。エージェントは、これらすべてのスニペットを自動的に 1 つの Python ファイルにまとめます。このスクリプトは、各関数を順番に呼び出し、プロセス全体を効率化します。 最終的には、以下のようなコードになります。 session_id = "a5b188fe-91f7-4f92-92fe-c4030721a427" task_name = "1694813661_airbnb_listings_price_heatmap" storage_mode = "local" # Sequentially invoke the functions airbnb_df = load_data ( airbnb_data_url = 'agent://airbnb_listings_price.csv' ) airbnb_gdf = add_geometry ( airbnb_df ) price_heatmap = plot_heatmap ( airbnb_gdf ) Python スクリプトが実行されると、Claude 2 がヒートマップを生成するコードを含む HTML ファイルを作成します。以下の画像は、Amazon Location Service ベースマップのニューヨークに Airbnb のリストプライスヒートマップを表示しています。 Amazon Bedrock で Amazon Location Service を使う Plan-and-Solve エージェントは地理空間タスクを処理できますが、住所のジオコーディングなどのタスクには少し異なるアプローチをとる必要があります。そのためには、LLM を使って推論と実行を組み合わせる ReACT 戦略が使えます。 ReACT パターンでは、エージェントが顧客のインプットと自由に利用できる ツール に基づいて推論し実行します。Claude 2 搭載エージェントにジオコーディング機能を持たせるためのツールを開発しました。このツールは、Amazon Location Service の Places API で SearchPlaceIndexForText メソッドを使用して住所を地理座標に変換します。 Agent: Hi ! I'm Agent Smith, your conversational geospatial assistant. How can I assist you today? You: > ? Hello, can you give me the coordinates for 112 E 11th St, Austin, TX 78701 ? Agent: The coordinates for 112 E 11th St, Austin, TX 78701 are longitude -97.740590981087 and latitude 30.274118017533 . Bash この短いやり取りで、エージェントは住所のジオコーディングを解読し、ジオコーディングツールを起動して、緯度と経度を返します。 ヒートマップのプロット、住所のジオコーディングを行う場合でも、Claude 2 を React や Plan and Solve などのエージェントと組み合わせることで地理空間のワークフローを簡素化できます。 デモをデプロイする デプロイするには、以下の手順をご覧ください。 以下のリポジトリをローカルマシンまたは EC2 インスタンスに複製します。 aws configure --profile <profilename> を実行してデフォルトのリージョンの設定が必要になる場合があります。このアプリケーションは us-east-1 を使用してテストしました。 git clone https://github.com/aws-samples/amazon-location-geospatial-agent/ Bash リポジトリのクローンを作成されたら環境変数を設定します。 ディレクトリを複製されたプロジェクトフォルダーに変更します。 cd amazon-location-geospatial-agent Bash お好みのテキストエディタを使って .env ファイルを編集します。 vim .env Bash API キー、マップ名、プレースインデックス名を追加します。 API_KEY_NAME = AgentAPIKey MAP_NAME = AgentMap PLACE_INDEX_NAME = AgentPlaceIndex Bash 以下のコマンドを実行してコンテナを構築します。 docker build -t agent . Bash 以下のコマンドを実行して Docker コンテナを実行し接続します。 docker run --rm -it -v ~/.aws:/root/.aws --entrypoint bash agent Bash Airbnb のデータセットを取得します。 apt install -y wget wget http://data.insideairbnb.com/united-states/ny/new-york-city/2023-10-01/visualisations/listings.csv cp listings.csv data/listings.csv Bash 以下のコマンドを実行してセッションを作成します。 セッションを使用して独自のチャット環境を分離します。 SESSION_ID = "3c18d48c-9c9b-488f-8229-e2e8016fa851" FILE_NAME = "listings.csv" make create-session Bash これで、アプリケーションを起動する準備ができます。 以下のコマンドを実行してチャットアプリケーションを起動します。 poetry run agent --session-id 3c18d48c-9c9b-488f-8229-e2e8016fa851 --profile < profilename > Bash チャットプロンプトが表示されます。 以下の質問をしてみてください。 I've uploaded the file listings.csv. Draw a heatmap of Airbnb listing price. Bash エージェントは Airbnb_listings_price.csv を取得、CSV ファイルを /data フォルダーにダウンロード、解析して地理空間データフレームに変換します。次に、データを変換するコードと視覚化用のコードを生成します。 最後に、 /data フォルダーに書き込まれる HTML ファイルを作成します。HTML ファイルをブラウザーで開くとヒートマップを確認できます。 別の例では、Amazon Location Service の Places API を使用して住所をジオコーディングしています。エージェントに 112 E 11th St, Austin, TX 78701 の住所をジオコーディングするように依頼すると、以下のような回答が得られます。 まとめ この記事では、Amazon Bedrock と Amazon Location Service の概要と、これらを組み合わせて地理空間データを分析および視覚化する方法について説明しました。 また、Plan-and-Solve と ReACT、エージェントによる使用方法についても説明しました。 私たちのサンプルは入門に過ぎません。サンプルコードをダウンロードして、地理空間タスク用の独自のエージェントとツールを追加してみてください。 著者 Jeff Demuth は 2016 年に Amazon Web Services (AWS) に入社したソリューションアーキテクトです。 彼は地理空間コミュニティに焦点を当てており、地理情報システム（GIS）とテクノロジーに情熱を注いでいます。 仕事以外では、旅行、 Internet of Things (IoT) アプリケーションの構築、最新のガジェットに触れ楽しんでいます。 Swagata Prateek は、Amazon Web Services (AWS) の Amazon Location Service で働いているシニアソフトウェアエンジニアで生成系 AI と地理空間について重点的に取り組んでいます。

AWS  の最高情報セキュリティ責任者 (CISO) として、私は個人的にあらゆるスキルレベルと規模のセキュリティチームが生成AI のセキュリティをナビゲートできるよう支援することに全力を注いでいます。以前は AWS  のお客様であった私は、実践的にセキュリティを学び、AWS  セキュリティを構築し運用する人々と直接話すことの価値を知っています。だからこそ、毎年恒例のクラウドセキュリティイベント AWS re:Inforce 2024 にぜひご参加ください。このイベントでは、生成 AI 時代のセキュリティの未来を牽引する専門家、パートナー、ビルダーと協力することができます。 深い技術的専門知識、セキュリティ投資の優先順位付け方法の理解、または基本的なセキュリティのベストプラクティスの適用方法を学びたいかどうかにかかわらず、re:InforceはセキュリティとAIの融合について深く掘り下げる絶好の機会です。AI と機械学習 (ML) は、25 年以上にわたって Amazon が重点的に取り組んできました。生成AI が世界に与えている影響を活用し、それに適応することは刺激的です。 AWS re:Inforce は単なるカンファレンスではありません。クラウドセキュリティの分野におけるイノベーションとコラボレーションを促進する役割を果たします。今年は 6 月 10 日から 12 日まで、ペンシルバニア州 で、お客様のビジネスイニシアチブの推進に役立つように設計された 2.5 日間の没入型クラウドセキュリティ学習を開催します。AWS では、セキュリティはビジネスを促進する要素であると常に信じてきました。セキュリティはリスクを軽減し、回復力を強化し、自信に満ちたイノベーションを促進します。セキュリティは、組織が生成AIなどの新しいテクノロジーを迅速かつ安全に使用し、顧客、パートナー、従業員により良い体験を提供するのに役立ちます。 本イベントに期待できることは以下のとおりです。 現在のAWSのセキュリティ対策と未来 AWS re:Inforce 2024 は、2024年6月11日火曜日の午前9時 (東部標準時) の基調講演から始まります。 re:Inforceの頃には、私は 1 年近くにわたって AWS の CISO を務めていることになります。その間に AWS セキュリティで起こったすべてのイノベーションについて考えると信じられないほどです。これらのイノベーション、そこから学んだこと、そしてそれらを使用して AWS を保護する方法について聞くことができます。また、AWS セキュリティの将来についての私のビジョンについてもお話しします。Amazon の CSO である Steve Schmidt が登壇し、強固なセキュリティ文化が生成 AI の安全な使用をどのように支えているかについての考えを語ります。 生成 AI やその他の新しいトレンドに向けてセキュリティをナビゲート 今こそセキュリティチームがビルダーが生成 AI で自信を持ってイノベーションを起こせるようにする時です。生成 AI に関する AWS セキュリティの最新の進歩をいち早く聞くことができます。インタラクティブなセッションでは、AI ワークロードを安全に実装する方法を学んだり、他のお客様のユースケースを調べたり、AWS やパートナーによる AI 主導型セキュリティのデモを見たりできます。AWS のセキュリティ専門家が、暗号化、ジェネレーティブ AI、セキュリティ文化の構築など、重要なトピックについて掘り下げた講演を行う イノベーショントーク をぜひご覧ください。 今年は、より多くの学習機会を提供するために、イベントを半日延長しました。re:Inforce では、データ保護、IDとアクセス管理、脅威の検出とインシデント対応、ネットワークとインフラストラクチャのセキュリティ、ガバナンス、リスクとコンプライアンス、アプリケーションセキュリティなど、250を超えるさまざまなセッションから選択して、アジェンダをカスタマイズできます。今年は、AWS で安全にイノベーションを進めた直接の経験を共有していただくお客様の登壇者のラインナップが揃っています。90 社以上の信頼できるセキュリティパートナーが、お客様のセキュリティポートフォリオの簡素化と統合を支援します。セキュリティに関する専門知識を深めたいとお考えの方は、re:Inforce セッションの 70% 以上が上級レベルまたは専門家レベルであることがわかります。 AWS のセキュリティにおける最新のイノベーションを活用 100 を超えるインタラクティブ形式のセッションで、当社の最新の発表やプロダクト開始について聞き、これらのセキュリティイノベーションを運用する方法を学びます。 お客様からのフィードバックに応えて、チョークトーク、コードトーク、ワークショップ、ビルダーズセッションなど、よりインタラクティブなセッション形式を追加しました。 既にお持ちのセキュリティツールをさらに活用する方法を学ぶために、AWS の専門家と直接つながるこの機会をお見逃しなく。 AWS の専門家、パートナー同僚とつながる セキュリティコミュニティの他のメンバーと集まる機会は私にとって本当に活力を与えてくれます。 直接会うことで、仲間とつながり、メンターを見つけ、お互いから学ぶ機会がすべて得られます。 参加者マッチングツールを使ってキャリア開発の目標を前進させたり、Expo を探索して信頼できるパートナーとつながったり、セキュリティコミュニティの特定の関心グループ向けに設計されたラウンジやアクティビティに参加したりできます。 サイバーセキュリティとデジタル ID の実践と専門分野における卓越性を育むという共通の使命を持つ AWS Security Heroes 、セキュリティ専門家、IT リーダー、教育者、開発者に会いましょう。 あるいは、知識の共有やセキュリティコミュニティとのつながりに情熱を傾けている AWS Community Builders Program のメンバー、AWS の技術愛好家、新進気鋭のオピニオンリーダーと交流することもできます。 多様な AWS セキュリティコミュニティと新しいつながりを築くのにこれ以上の機会はありません。 SecBlofNakB というコードで今すぐ登録すると、期間限定で 150 米ドルの割引を受けられます。ただし、在庫がなくなり次第終了します。 クラウドセキュリティ業界でのキャリアを始めてから 5 年以内であれば、 All Builders Welcome Grant の対象となる可能性があります（訳者注。登録期限がありますのでご確認ください）。 この助成金は、包摂的、多様かつ公平なサイバーセキュリティコミュニティを構築するという当社の取り組みの一環として、少数精鋭の技術者が AWS re:Inforce  に参加するための経済的障壁を取り除いてくれます。 今後数週間にわたって、 AWS re: Inforce のウェブサイト 、 @awscloud 、 @AWSSecurityInfo で追加の詳細を共有する予定です。 今年の 6 月に AWS re:Inforce  に皆さんをお迎えできることを嬉しく思います。 ぜひ注目してください。 Chris 本Blogは、AWSのCISOであるChris Betzによる 原文 を松本照吾が翻訳しました。 なお、 日本からご参加のお客様のために学習に集中できるための公認ツアーを用意しています。 日本語のAWS re:Inforce ご紹介ページ からツアーのご案内をご確認いただけますので是非ご覧いただければ幸いです。

こんにちわ、ソリューションアーキテクトのザビオ( @zabbiozabbio )です！ 2/20日に 開催しましたWeb3@Startup Loft #6  の開催報告になります。 Web3@Loftとは Web3@Loft は AWS 上でブロックチェーンを始めようとしている、または、開発/運用しているデベロッパー、事業開発者のための、有志によるコミュニティイベントで、定期的に AWS Loft Tokyo で開催しております。 今回は「Web3 Gaming」にフォーカスし、実際に開発/運用されている各企業様にご登壇いただきました。 会場の雰囲気はこちら。今回も多くのお客様に聴講いただきました Amazon Web Services Japan G.K. Sr. Blockchain Specialist SA 中武 Amazon Managed Blockchain Web3 Update 2024 昨年のre:inventで紹介された、 AMB Access Polygon (Public Preview) を中心に、AMB AccessとQueryの概要、またセルフホスティングを柔軟に設定できる AWS Blockchain Node Runners を紹介いたしました。 AMB Access & AMB Queryに関しては こちら をご参照ください。 パネルディスカッション「Web3 Gaming 2024 Initiatives Tech Advancements & Strategic」 株式会社スクウェア・エニックス ブロックチェーン・エンタテインメント事業部 事業部長 畑 圭輔 様 株式会社スクウェア・エニックス ブロックチェーン・エンタテインメント事業部 テクニカルディレクター ディロロ マルタン 様 Polygon Labs Head of Business Development Japan ビール 依子 様 double jump.tokyo株式会社 代表取締役/CTO 満足 亮 様 株式会社ディー・エヌ・エー 島岡 秀知 様 株式会社GALLUSYS CTO 吉田 健一 様 ブロックチェーンゲームに関わりのある企業様をお呼びして、Tech/Bizの観点でパネルディスカッションを行いました。 2024年最新の取り組みから、実装におけるよくある課題、UI/UXはどこを意識してるの、Gameに関わるプレイヤーやステークホルダーとの関わり方、コミュニティ活性化の施策など、 様々なテーマに関して皆様のご意見や知見を共有いただけました。 (スポンサー枠) 株式会社SARAH様 (スポンサー枠) 株式会社HashPalette様 (スポンサー枠) 株式会社クリプトリエ様 (スポンサー枠) CryproGames株式会社 前回からの試みでスポンサーを募集したとこと4社からエントリーいただきました。 各社が独自の色を出し、サービスやプロダクトを紹介。 参加者も各ブースに立ち寄りながら、楽しくお話頂いてるようでした。 まとめ ブロックチェーンゲームに関わりのある企業様の具体的な課題や施策を共有いただきました。 次回も Web3@StartupLoft を開催予定です。日程確定したらアナウンスいたします！ このブログの著者 中武 優樹（Yuki Nakatake） Blockchain/Web3、Database、Zabbix が好きなソリューションアーキテクトです。

お客様がオンプレミス VMware 仮想環境のアプリケーションをリファクタリングせずに移行するために VMware Cloud on AWS を選択されることがますます増えてきました。将来的なクラウドネイティブ化を目指す場合にも、最初のステップとして VMware Cloud on AWS が選ばれるケースも増えてきています。今回は次のステップとして、VMware Cloud on AWS を起点としたデータベースの移行手法についてご紹介します。 AWS Database Migration Service (DMS) を使用して、VMware Cloud on AWS で実行されているデータベースを Amazon Relational Database Service (Amazon RDS) や Amazon Aurora に移行することもできます。ビジネスへの影響やリスクを最小限に抑えると同時に VMware Cloud on AWS 上のアプリケーションを維持しながら、 モダナイゼーション に向けたクラウドジャーニーの次のステップへ進むことができます。 それでは、VMware Cloud on AWS 上で実行されているデータベースを AWS DMS を活用して Amazon Aurora に移行する方法について説明していきます。 AWS Database Migraiton Service (DMS) について AWS DMS はこれまでに最小限のダウンタイムで 100 万以上のデータベースを安全に移行してきており、世界中のお客様からご利用いただいています。 図 1. AWS Database Migraiton Service (DMS) の概要 VMware Cloud on AWS と AWS DMS この投稿では、AWS DMS を使用して、VMware Cloud on AWS で実行されている MySQL を Amazon Aurora に移行する方法を紹介します。Amazon Aurora は、大規模環境でのパフォーマンスと高可用性を提供する最新の リレーショナルデータベース サービスであり、オープンソースの MySQL および PostgreSQL 互換エディションを提供し、サーバーレスならびに機械学習 (Machine Learning) 駆動型アプリケーションを構築するためのさまざまな開発者ツールをサポートしています。 アーキテクチャ概要 次のアーキテクチャの概要図は、AWS DMS が VMware Cloud on AWS 上で実行されている MySQL データベース仮想マシン (DB VM) を Elastic Network Interface (ENI)  を介して Connected VPC にデプロイされた Amazon Aurora に移行する方法を示しています。 図 2. AWS DMS を活用した VMware Cloud on AWS 上のデータベース移行の概要図 VMware Cloud on AWS と Connected VPC 間の通信は ENI を介して内部的に接続されているため、上図の通信はすべて AWS クラウド内にプライベートに保たれていることにもご留意ください。 前提条件 一般的な前提条件 WordPress アプリケーション仮想マシン (App VM) と MySQL データベース仮想マシン (DB VM) は、VMware Cloud on AWS 上で稼働しています。この例では、以下の環境を使用しました。 * VMware Cloud on AWS: SDDC バージョン 1.22 * App VM: Cent OS Linux 7、WordPress 6.2 * DB VM: Cent OS Linux 7、MySQL 8.0 * AWS DMS: Engine version 3.4.7 * Amazon Aurora: version 3 compatible with MySQL 8.0 VMware Cloud on AWS と Connected VPC との間で必要なすべての通信は確立しており、Connected VPC のセキュリティグループおよび VMware Cloud on AWS のファイアウォールルール で許可している。 AWS DMS の AWS Identity and Access Management (IAM) ポリシーで必要なアクションはすべて許可されている。AWS DMS のアクセス要件の詳細については、 AWS Database Migration Service のセキュリティ を参照ください。 Amazon Aurora は MySQL へのバージョン互換性があるエディションである。 Amazon Aurora と MySQL の両方が AWS DMS でサポートされているバージョンである。 データベースの詳細 ターゲットのデータベース Amazon Aurora (MySQL 互換) を Connected VPC 内でデプロイ済みです。 図 3. Connected VPC 内で稼働している Amazon Aurora (MySQL 互換) ソースのデータベース MySQL を WordPress のデータベースとして設定済みです。 図 4. WordPress のデータベースとして設定されている データベース仮想マシン (MySQL) セットアップ手順 この例では、次のセクションにわたって AWS DMS の設定について説明します。 1. Connected VPC にレプリケーションインスタンスを作成 2. ソースとターゲットのエンドポイントの作成 3. データベース移行タスクを作成して実行 4. WordPress の DB アクセスを MySQL から Amazon Aurora に切り替え、アプリケーション側の接続テストを実施 ステップ 1. AWS DMS レプリケーションインスタンスを作成 AWS DMS は、 VPC 内の Amazon EC2 インスタンスとして AWS DMS レプリケーションインスタンスを作成します。このレプリケーションインスタンスを使用し、データベースを移行します。もし高可用性とフェイルオーバーサポートが必要な場合は、マルチ AZ オプションを選択することもできます。 この例では、シングル AZ オプションを選択し、Connected VPC にレプリケーションインスタンスをデプロイしました。 Connected VPC に AWS DMS レプリケーションインスタンスを作成 Connected VPC にレプリケーションインスタンスを作成します。 図 5. AWS DMS レプリケーションインスタンスを作成 パラメータチェック 要件と環境に応じてパラメータを選択できます。 図 6. AWS DMS レプリケーションインスタンスの設定 ステップ 2. ソースとターゲットのエンドポイントの作成 エンドポイントの作成 ソース (移行元: MySQL 側) とターゲット (移行先: Amazon Aurora 側) の両方にエンドポイントを作成します。 エンドポイントは、データストアに関する接続、データストアのタイプ、およびロケーションの情報を提供します。AWS DMS はこの情報を使用してデータストアに接続し、ソースエンドポイントからターゲットエンドポイントにデータを移行します。またエンドポイントに対して追加で接続オプションも設定できます。 図 7. AWS DMS のエンドポイント ソースエンドポイントの作成 まず、ソースエンドポイントを作成します。VMware Cloud on AWS 上で稼働している DB VM (MySQL) のアクセス情報を登録します。 図 8. AWS DMS のソースエンドポイント ターゲットエンドポイントの作成 次に、ターゲットエンドポイントを作成します。Connected VPC 上で稼働する Amazon Aurora へのアクセス情報を登録します。 図 9. AWS DMS のターゲットエンドポイント (オプション) ターゲットエンドポイント接続テスト ターゲットエンドポイントを作成する前に、レプリケーションインスタンスへの接続をテストすることが可能です。 図 10. AWS DMS のターゲットエンドポイントへの接続テスト これで、AWS DMS での移行前のセットアップは完了です。 ステップ 3. データベース移行タスクを作成して実行する AWS DMS タスクはすべての作業が行われる場所です。移行や、ロギング要件、制御テーブルデータ、エラー処理などの特別な処理に使用するテーブル (またはビュー) とデータベースを指定します。 タスクは次の 3 つの主要なフェーズで構成されます。 * 既存データの移行 (フルロード) * キャッシュされた変更の適用 * 継続的なレプリケーション (変更データキャプチャ) AWS DMS 移行タスクがデータを移行する方法の詳細と概要については、 AWS DMS の概要 を参照してください。 既存データの移行 この例では、VMware Cloud on AWS 上の MySQL から Connected VPC 内の Amazon Aurora にデータを移行するために「Migration of existing data」を選択しています。 図 11. タスクの作成 Amazon Aurora に移行するために MySQL データベース「wordpress」を選択しています。 図 12. WordPress のデータベース指定 実行状況は「Status」で確認できます。 図 13. タスクのステータス確認 ステータスが 「Load complete 」となっています。これで、MySQL 内のデータが Amazon Aurora へ移行されたことが確認できました。 次に、WordPress アプリケーション側からもデータ移行が成功していることを確認します。 ステップ 4. WordPress のデータベースアクセスを MySQL から Amazon Aurora に切り替えてテスト データベースを移行したら、WordPress アプリケーションでテストしてみます。 「wp-config.php」設定ファイルを更新して WordPress (App VM) の DB アクセスを切り替えると、WordPress は Amazon Aurora にアクセスします。 図 14. WordPress の参照先データベースの変更 マイグレーション完了の確認 下図の通り、すべての WordPress のコンテンツが正常に移行されたことがわかりました。 図 15. WordPress のコンテンツ確認 その他の考慮事項 本番環境で AWS DMS を使用して同様のデータベース移行を行う場合は、以下のセキュリティガイドラインに従ってください。 * Amazon Aurora のセキュリティ * AWS Database Migration Service のセキュリティ * VMware Cloud on AWS のネットワークとセキュリティについて 各サービス利用コストも考慮する必要があります。この例では、AWS DMS をオンデマンドの Amazon EC2 インスタンスで使用してレプリケーションインスタンスとして実行したため、オンデマンド使用分が課金されます。一方、VMware Cloud on AWS SDDC と Connected VPC 間のデータ転送では、SDDC と送信先の Amazon EC2 インスタンスは同じ AWS アベイラビリティーゾーン (AZ) にあるために通信コストは発生しません。利用コストの詳細については、 AWS Database Migration Service の料金 をご参照ください。 Connected VPC ではなく他の VPC をデータベースの移行先として使用する場合は、ネットワーク接続に AWS Transit Gateway (TGW)  や  VMware Transit Connect (VTGW) を活用できます。 AWS DMS は、一般的なデータストアの多くをソース (移行元) として使用できます。Amazon EC2 インスタンスで実行されるセルフマネージドのデータベースでも、オンプレミスのデータベースでもかまいません。また、Amazon RDS や Amazon S3 などの AWS サービス上のデータストアをソースにすることもできます。対象となるデータストアの包括的なリストについては、 AWS DMS のソース をご参考ください。AWS DMS の詳細な前提条件については、 AWS Database Migration Service の前提条件 をご参照ください。 まとめ 一般的にデータベース移行は容易ではありませんが、AWS DMS を活用することでそのハードルを大幅に下げることができます。この記事をきっかけに、VMware Cloud on AWS を起点としたさらなるモダナイゼーションを検討していただけますと幸いです。 AWS DMS および VMware Cloud on AWS には多くの参考資料があります。以下に概要を示しますので、ぜひチェックしてみてください。 その他のリソース VMware Cloud on AWS のデータウェアハウスとビジネスインテリジェンス VMware Cloud on AWS のアカウントと VPC に関する考慮事項 VMware Cloud on AWS ハイブリッドネットワークデザインパターン AWS SCT と AWS DMS を使用して MySQL から Amazon Aurora に移行する方法 原文は こちら です。

組織には、データの価値を最大限に引き出すための強力な基盤が必要です。この基盤の目的は、データを整理し、品質を確保し、メタデータを管理して、組織のデータを照会できる集約されたカタログを作成することです。組織は、「データ基盤」と呼ばれるこの基盤によって、クリーンで整理され簡単にアクセスできるデータを活用して、より良い意思決定やビジネスインサイトを得ることができます。 データは新しい石油である — クライヴ・ロバート・ハンビー OBE, 数学者 ハンビーは、ビッグデータを「新しい石油」と宣言することで、ビッグデータへの関心を高めました。この比喩は、データドリブン・イノベーション、AI/ML 、および、生成 AI の土台となりました。多くの組織が、構造化データと非構造化データを大規模に、時には取り憑かれたように保存し始めました。「いつかこれが必要になるかもしれない」は、よく繰り返されるマントラでした ( そして今もそうです )。組織は、ファイルシステム、データベース、データウェアハウス、データレイクに保存されるデータを、無差別に収集しました。 データは新しい牛乳である：素早く使用しなければ傷んでしまう — エミリー・ゴルセンスキー, データサイエンティスト 残念ながら、データストアはフリーマーケットによく似たものです。自分が探しているものが分かっていれば、そこに多くの宝物を見つけることができますが、価値のないものに多額のお金を費やすこともあります。目的や特定のユースケースなしに収集されたデータは、それを二流の製品とみなす消費者から、すぐに懐疑的な見方をされます。出所が不明で、品質が不明で、説明が不十分だからです。この問題は多くの場合、本来のデータ作成者ではなく、データの出所、品質、意味に関する十分な知識がない、別のチームがデータを管理していることが原因です。 このような場合、データ基盤は技術的および組織的な観点から見ると、本来あるべきほど強力ではありません。これは問題です。 これにより、余分な作業が増えます。私の経験では ( 少なくとも私が働いたことのある会社では ) 、データサイエンティストの時間の最大 60％ は、ビジネス上の問題を解決する代わりに、データの整理、クリーニング、再フォーマットに費やされています。 加えて、保存されたデータが国のデータ保護規制に準拠している場合としていない場合があります。組織はこれらの規制を知り、その遵守を証明できなければなりません。私は IT 管理者として、データ保護当局から 7 桁の罰金通知を受けたことがあります。その理由は、ある従業員からの、私たちが規制に違反しているという告発からでしたが、ありがたいことに事実ではありませんでした。罰金が科されたのは、我々が特定のデータを、なぜ、またどのくらいの期間に渡って保存するのかを明確に文書化していないことが、データ保護当局によって発見されたためです。幸いなことに、私たちはその主張に反論することができましたが、そもそもこうした対処は不必要で避けられる仕事でした。 特に 生成 AI では、データ品質が重要です。これらの基盤モデルは一般的なデータを生成しますが、競合他社が同じモデルを使用して同じ結果を生み出している可能性が高いため、競争上の優位を生み出すことはできません。独自のデータを使用してモデルをトレーニングまたはカスタマイズする必要がありますが、低品質のデータでこれを行うと、結果が不十分になったり、モデルが内包する既存のバイアスが強まったりする可能性があります。 これらのデータ基盤の問題は、いくつかの理由でマネジメント層によって過小評価され、見過ごされがちです。 まず、ほとんどのマネージャーと従業員にはデータリテラシーが不足しています。 ガートナー社 は、データリテラシーを「文脈に沿って適切にデータを読み、書き、伝える能力。これは、データソースとその構造、および適用された分析手法と技法の理解を含む。また、ユースケース、アプリケーション、そして結果の価値を表現する能力も含む」と定義しています。ガートナー社の CDO ( Chief Data Officer ) サーベイによると、データリテラシーの低さは、CDO の成功を阻む 2 番目に大きい内部障害とされています。 第二に、データストレージとそれを使用するリスクの確度と影響を定期的に評価し監視するプロセスが導入されていることは、ほとんどありません。 第三に、マネジメント層が理解できるデータインベントリの概要は、めったにありません。データインベントリがある場合、非常に詳細な技術情報を使用するデータサイエンティスト向けに作成されたものです。 御社のデータの状態、リスク、および価値はご存知ですか？もしご存知なければ、ボタンを押して評価を提供できるのは誰ですか？ 強固なデータ基盤は以下の4つの側面で構成されます： 戦略 : ビジネス戦略に従い、戦略的取り組みをサポートする明確な データ戦略 を定義します。 技術に寄りすぎることは避けてください。これは方向性を提供することを目的としたものであり、詳細な手順を示すものではありません。効果的なデータ戦略は、データが技術的および組織的にどのように扱われるかを説明する明確かつ簡潔な原則で構成されます。 ドイツの不動産ウェブサイト Scout24 などの一部の組織は、これを データマニフェスト と呼んでいます。 カルチャー : かなりの数 ( 69 % ) の CDO が、データドリブンカルチャーの取り組みに大半の時間を費やしており、55 % がデータドリブンカルチャーの欠如が、ビジネス目標を達成するための最大の課題であると考えています。 私の同僚の Ishit Vachhrajani は、このトピックに関して強くお勧めできる 電子書籍 を執筆しています。 組織 : 分析データに対する、ビジネスドメイン観点での責任を明確に定義します。中央に集約されたデータチームでは、この責任があまり明確に定義されていないことがよくあります。 こうしたチームは、データを生成しません。彼らはトランザクション処理を行うアプリケーションからデータを抽出し、社内の他部門のためにそれを管理するのに最善を尽くします。分析データに対する統制を、中央に集約されたデータチームから、アプリケーションを使ってこのデータを生成している部門に移管することをお勧めします。 このやり方は、組織的データメッシュと呼ばれます。これらのチームは、社内外の顧客のニーズに合わせた特定のユースケースとビジネス上の問題に基づいてデータを保存します。 したがって、データに対する責任は、分散アプローチで組織的にプロデューサー ( 訳註: データ生成元 ) に移管されます。 技術的には、データを一つの データレイク に一元的に保存することも、 データメッシュ に分散して保存することもできます。 AWS は、これらの モダンデータアーキテクチャ の両方を構築するためのサービスを提供しています。能力と制御は密接に関連しているため、スタッフのデータリテラシーに投資する必要があります。 データプロデューサーは多くの場合、トランザクションデータを処理する能力はありますが、分析スキルが不足しています。これに対して AWS は、 データ分析トレーニング をご提供することにより、ご支援が可能です。さらに、適切なアクセス ポリシーを導入します。 デフォルトで誰もがすべてのデータにアクセスする必要があるわけではありませんが、誰もがデータ カタログで利用可能なデータを見つけ、必要に応じて API 経由でアクセスできるべきです。 AWS Lake Formation は安全なデータレイクを簡単に作成し、幅広い分析にデータを利用できるようにします。 Amazon DataZone を使用すると、ガバナンスとアクセス制御を備えた状態で、組織の境界を越えて大規模にデータを発見して共有できます。 テクノロジー ：さまざまな分析ユースケースをサポートする必要がある強固なデータ基盤にとって、全てのケースに画一的に対応するソリューションは、最適な選択ではないかもしれません。特に、それらのユースケースが異なる組織のものである場合は、なおさらです。Best-of-breed ( 訳註：各分野で最良のものを組み合わせる ) のアプローチを適用して、それぞれの状況やユースケースに最適なツールを使用することをおすすめします。これらのツールは、アーキテクチャの観点から見て、全体的な技術戦略とうまく統合され、整合している必要があります。AWS は、データの保存、クエリー、統合、カタログ化、ガバナンス、および処理を行うための、包括的な サービス を提供しています。これらのサービスにより、組織は集中型または分散型のデータアーキテクチャを大規模に構築できます。一般的には、クラウドトランスフォーメーションを加速し、AWS クラウドの可能性を最大限に引き出すことをお勧めします。データ分析システムの開発と運用には、バージョン管理、 CI / CD 、テスト自動化など、モダンで実績のあるソフトウェア開発手法を適用することが重要です。これにより、生産性と品質が向上すると同時に、開発時間が短縮され、変更の追跡可能性が向上します。 生成 AI は、将来を見据えたデータ基盤に貴重な貢献をすることができます。 Amazon Titan モデルのような大規模言語モデル ( LLM ) は、データのプロファイリング、メタデータの抽出とエンリッチメント、データカタログの管理、自然言語を用いた検索の強化に役立ちます。ただし、すべての生成 AI アプリケーションと同様に、AI が出力する結果と提案（例：生成されたメタデータは正しいか？ ) を批判的に確認する必要があります。 データおよびデータ基盤は複雑で分かりにくいように思えるかもしれませんが、明確かつ安全に使用することが可能です。あなたの組織のデータは多くのビジネスチャンスを作り出します。必要なのはそれらを利用することだけです。 データは新しいワインである データを適切に処理、保存、調整すれば、時間の経過とともにさらに向上する、驚くべき結果を得ることができます。注意深く取り扱わないと、すぐに品質が低下し、役に立たなくなります。 データ基盤に関してどのような経験をお持ちですか?　それらについて是非お聞きしたいです。 How to Build Data Capabilities , Ishit Vachhrajani How to Create a Data-Driven Culture , Ishit Vachhrajani Unmasking Your Organization’s Data Problem , Joe Chung Matthias Patzak Matthias は AWS ソリューションアーキテクチャのプリンシパルアドバイザーを務めた後、2023 年初頭にエンタープライズストラテジストチームに加わりました。この役職では、マティアスは経営陣と協力して、クラウドがイノベーションのスピードやITの効率を高め、自社のテクノロジーが生み出すビジネス価値を高めるのにどのように役立つかについて、人、プロセス、テクノロジーの観点から検討しています。AWS に入社する前は、マティアスは AutoScout24 で IT 担当副社長を務め、Home Shopping Europe でマネージングディレクターを務めていました。両社とも、リーン・アジャイルのオペレーションモデルを大規模に導入し、クラウドトランスフォーメーションを成功させた結果、納期の短縮、ビジネス価値の向上、企業価値の向上を実現しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

4月1日は エイプリルフール です。約 10 年前、一部のテクノロジー企業は、読者を喜ばせるために、面白いが、実行不可能だと考えられていたアイデアについて 4 月 1 日に冗談を言っていました。Jeff Barr も過去にこのブログに一見突飛なアイデアを投稿しましたが、驚くことにそのうちのいくつかは実現しました。 例を次に示します。 年 冗談 現実 2010 年 Introducing QC2 – the Quantum Compute Cloud 。特定の種類の数学および論理の問題を驚くべき速度で解決する、本番対応の量子コンピュータ。 2019 年に、科学者、研究者、デベロッパーが 1 か所で、複数の量子ハードウェアプロバイダーから提供されるコンピュータを使用して実験を開始することを可能にするフルマネージドサービスである Amazon Braket をリリースしました。 2011 年 Announcing AWS $NAME 。クラウド、オンプレミス、さらには自宅や部屋上のシステムを見つけて自動的に統合する、スケーラブルなイベントサービス。 2019 年に、独自の AWS アプリケーションとサードパーティーアプリケーションを簡単に統合できるようにするために、 Amazon EventBridge を導入しました。 AWS IoT Events を利用すると、自宅の IoT デバイスからイベントを大規模にモニタリングして対応できます。 2012 年 New Amazon EC2 Fresh Servers 。空間移動的な提供と衛星フリートからの通信を使用して、新しい (物理) EC2 サーバーを 15 分で配信します。 2021 年に、AWS サービスが組み込まれた 1U/2U 物理サーバーである AWS Outposts サーバー をリリースしました。2023 年、 Project Kuiper は、低軌道における光メッシュネットワークのテストを成功裏に完了しました。現在必要なのは、 Amazon PrimeAir のドローン配送 に続く衛星倉庫と大気圏再突入テクノロジーを開発することだけです。 2013 年 PC2 – The New Punched Card Cloud 。新しい mf (メインフレーム) インスタンスファミリー、メインフレームマシンイメージ (MMI)、テープストレージ、1970 年代から 80 年代に使用されたメインフレームコンピュータ用のパンチカードインターフェイス。 2022 年に、メインフレームアプリケーションをモダナイズし、AWS フルマネージドランタイム環境にデプロイするのに役立つよう、 AWS Mainframe Modernization をリリースしました。 Jeff が戻ってきました! 今年は、チップのフレーバーとシリコンのイノベーションの間にユニークな類似点を描き、Jeff が満喫できるように AWS “Chips” Taste Test を用意しました。Jeff は、「Golden Nacho Cheese」、「Al Chili Lime」、「BBQ Training Wheels」を、 AWS Graviton 、 AWS Inferentia 、および AWS Trainium チップと比較しながら味見しました。 皆さんのお気に入りはどれですか? AWS のソーシャルメディアチャネルの LinkedIn や X での投稿 で楽しい動画をぜひご視聴ください。 3月25日週のリリース 私たちが好奇心を持ち、学び続け、高い水準にこだわれば、今後もさらに多くのアイデアが現実になるのを目にすることができるでしょう。同じことが、 生成人工知能 (生成 AI) の世界にも当てはまります。今週は、生成 AI テクノロジーを活用したいくつかのリリースをご紹介します。 Knowledge Bases for Amazon Bedrock – Anthropic の Claude 3 Sonnet 基盤モデル (FM) が、 検索拡張生成 (RAG) 用に内部データソースに接続するために Knowledge Bases for Amazon Bedrock で一般公開されました。 Knowledge Bases for Amazon Bedrock は、 メタデータフィルタリング をサポートしています。これにより、ドキュメントがクエリに確実に関連しているようにできるため、検索の精度が高くなります。クエリに含めるドキュメントまたはクエリから除外するドキュメントを指定することで検索結果を絞り込むことができ、その結果、Claude 3 Sonnet などの FM によってより関連性の高い応答が生成されます。 最後に、Knowledge Bases for Amazon Bedrock で、 プロンプトと検索結果の数をカスタマイズ できます。カスタムプロンプトを使用すると、コンテキスト、ユーザー入力、または出力インジケーターを追加することでプロンプトの指示をカスタマイズできます。これにより、モデルはユースケースのニーズにより良く合致する応答を生成できます。取得するパッセージの数を調整することで、最終的な応答を生成するために必要な情報の量を制御できるようになりました。これらの新機能の詳細については、AWS ドキュメントの「 Knowledge Bases for Amazon Bedrock 」をご覧ください。 Amazon Connect Contact Lens – AWS re:Invent 2023 では、問い合わせの質を高め、エージェントのパフォーマンスを改善するのに役立つよう、顧客との長い会話を簡潔で一貫性のあるコンテキストが豊富なコンタクトの概要に要約するために、 生成 AI 機能のプレビューを発表しました 。これらの 生成 AI を活用した問い合わせ後の概要 は現在、Amazon Connect Contact Lens でご利用いただけます。 Amazon DataZone – AWS re:Invent 2023 では、 包括的なビジネスデータの説明とコンテキストを生成する、生成 AI ベースの機能のプレビューも発表 し、分析のユースケースに関するレコメンデーションについてもご紹介しました。これらの 生成 AI を活用した説明に関するレコメンデーション は現在、Amazon DataZone でご利用いただけます。 他にも見逃せない重要なリリースがあります。 フロリダ州マイアミの新しい Local Zone – AWS Local Zones は、AWS リージョンが存在しない場所による多数の人々、産業、IT センターが、コンピューティング、ストレージ、データベース、他の選択されたサービスを近くで利用できるようにする AWS インフラストラクチャのデプロイです。 フロリダ州マイアミの新しい Local Zone を使用して、リアルタイムゲーム、ハイブリッド移行、ライブ動画ストリーミングなど、1 桁ミリ秒のレイテンシーを必要とするアプリケーションを実行できるようになりました。 Amazon EC2 コンソール設定 の [ゾーン] タブから、マイアミの新しい Local Zone (use1-mia2-az1) を有効にして開始できます。 新しい Amazon EC2 C7gn メタルインスタンス – AWS Graviton ベースの新しい C7gn ベアメタルインスタンス を使用して、詳細なパフォーマンス分析ツール、ベアメタルインフラストラクチャへの直接アクセスを必要とする特殊なワークロード、仮想環境でサポートされていないレガシーワークロード、ライセンスに制限のあるビジネスクリティカルなアプリケーションから恩恵を受けるアプリケーションを実行できます。EC2 C7gn メタルサイズには、64 vCPU と 128 GiB のメモリが搭載されています。 AWS Batch マルチコンテナジョブ – AWS Batch でマルチコンテナジョブ を使用できるため、自動運転車やロボット工学などの分野で大規模なシミュレーションをより簡単かつ迅速に実行できます。ジョブごとに複数のコンテナを実行できるため、AWS Batch が提供する高度なスケーリング、スケジューリング、コスト最適化を利用できるほか、3D 環境、ロボットセンサー、モニタリングサイドカーなどのさまざまなコンポーネントを表すモジュール式コンテナを使用できます。 Amazon Guardduty EC2 Runtime Monitoring – Amazon GuardDuty EC2 Runtime Monitoring の一般提供の開始 をお知らせします。これは、VPC フローログ、DNS クエリログ、AWS CloudTrail 管理イベントを継続的にモニタリングすることによって、実行時の EC2 インスタンスの脅威検出範囲を拡大し、GuardDuty が既に提供している異常検出を補完します。ホスト上の OS レベルのアクティビティと、検出された脅威に対するコンテナレベルのコンテキストを可視化できるようになりました。 AWS CodeBuild 向けの GitLab サポート – CodeBuild プロジェクトのソースプロバイダーとして GitLab および GitLab セルフマネージド を使用できるようになりました。GitLab リポジトリでホストされているソースコードの変更からビルドを開始できます。CodeBuild の新しいソースプロバイダーの使用を開始するには、「 AWS CodeBuild ユーザーガイド 」にアクセスしてください。 AWS コスト割り当てタグの遡及サポート – AWS コスト割り当てタグを 最大 12 か月間遡って有効にすることができます 。以前は、コスト割り当ての目的でリソースタグをアクティブ化した場合、タグは将来に向けてのみ有効になりました。コスト配分タグをバックフィルする期間を指定して、 バックフィルリクエストを送信します 。バックフィルが完了すると、前月のコストと使用量データに現在のコスト割り当てタグが付けられます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 生成 AI に関する他の注目の最新情報とニュース: Amazon と Anthropic による AI への投資 – Anthropic との戦略的なコラボレーションと投資における 最新のマイルストーン をお読みください。現在、Anthropic は AWS を主要クラウドプロバイダーとして利用しており、安全性の研究や将来の FM 開発などのミッションクリティカルなワークロードのために AWS Trainium および Inferentia チップを使用する予定です。3月初め、 Amazon Bedrock で Anthropic の最も強力な FM である Claude 3 へのアクセスを発表しました。 Sonnet は 3 月 4 日に、 Haiku は 3 月 13 日に利用可能になる旨をお知らせしました。詳細については、Claude on Amazon Bedrock の紹介動画をご視聴ください。 Amazon Bedrock 上に構築された仮想構築アシスタント – BrainBox AI は、Amazon Bedrock を利用した ARIA (Artificial Responsive Intelligent Assistant) のリリースを発表しました。ARIA は、建物管理に関連する日常のプロセスにシームレスに統合することで、建物の効率を高めるように設計されています。詳細については、 お客様事例を全文 お読みいただき、ARIA を使用して建物の CO2 排出量を削減する方法に関する動画をご視聴ください。 Amazon SageMaker JumpStart でソーラーモデルが利用可能に – Upstage Solar は、 Amazon SageMaker を利用して 100% 事前トレーニングされた大規模言語モデル (LLM) であり、そのコンパクトなサイズと強力な実績を使用して優れたパフォーマンスを発揮し、特定の目的のためのトレーニングに特化しています。そのため、このモデルはさまざまな言語、領域、タスクで多様な目的のために使用できます。現在、 Solar Mini は Amazon SageMaker JumpStart でご利用いただけます 。詳細については、SageMaker JumpStart でソーラーモデルをデプロイする方法をご覧ください。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。先週のハイライトは、 Linux Foundation が、Redis インメモリ NoSQL データストアに代わるオープンソースである Valkey コミュニティを立ち上げた というニュースでした。 AWS の今後のイベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティが一堂に会して、つながり、コラボレーションし、AWS について学ぶための無料のオンラインおよび対面イベントにご参加ください。最寄りの都市でぜひご登録ください: パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15～16 日)、 ソウル (5 月 16～17 日)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ドバイ (5 月 29 日)、 ストックホルム (6 月 4 日)、 マドリード (6 月 5 日)。 AWS re:Inforce – AWS re:Inforce で生成 AI 時代のクラウドセキュリティについて詳しく学びましょう。これは、ビジネスイニシアティブの推進に役立つように設計された、没入型クラウドセキュリティ学習であり、6 月 10～12 日にペンシルバニア州で 2 日半の日程で開催されます。re:Inforce で予定されている内容については、 AWS の Chief Information Security Officer (CISO) である Chris Betz の記事 をお読みください。 AWS Community Days – 世界中の AWS のエキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、実践ラボを特徴とするコミュニティが主体となって開催するカンファレンスに参加しましょう: ムンバイ (4 月 6 日)、 ポーランド (4 月 11 日)、 ベイエリア (4 月 12 日)、 ケニア (4 月 20 日)、 トルコ (5 月 18 日)。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの デベロッパー向けイベント のすべてを閲覧できます。 4月1日週はここまでです。4月8日週に再びアクセスして、新たな Week in Review をぜひお読みください! – Channy この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

Amazon GuardDuty は、機械学習 (ML) ベースのセキュリティモニタリングおよびインテリジェントな脅威検出サービスであり、 さまざまな AWS データソース を分析および処理し、AWS アカウントとワークロードを継続的にモニタリングして悪意のあるアクティビティがないかを確認するとともに、可視性を高め、是正するための詳細なセキュリティに関する検出結果を提供します。 私は、オペレーティングシステム (OS) レベル、ネットワーク、ファイルイベントを分析して、環境内の特定の AWS ワークロードについての潜在的なランタイム脅威を検出する GuardDuty Runtime Monitoring の機能が気に入っています。私は 2023 年 3 月に、 Amazon Elastic Kubernetes Service (Amazon EKS) リソース向けにこの機能の一般提供が開始されることを 初めてご紹介 しました。Seb は 2023 年 11 月に、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate 向けに脅威検出を提供する Runtime Monitoring 機能の 拡張 と、 Amazon Elastic Compute Cloud (Amazon EC2) ワークロードの プレビュー についての記事を投稿しました。 3月29日は、 Amazon GuardDuty EC2 Runtime Monitoring の一般提供の開始をお知らせします。これは、実行時における EC2 インスタンスの脅威検出の対象範囲を拡大し、VPC フローログ、DNS クエリログ、および AWS CloudTrail 管理イベントを継続的にモニタリングすることで GuardDuty が既に提供している異常検出を補完するものです。ホスト上の OS レベルのアクティビティと、検出された脅威に対するコンテナレベルのコンテキストを可視化できるようになりました。 GuardDuty EC2 Runtime Monitoring を使用すると、EC2 ワークロード内のコンピューティングリソースをターゲットとしている可能性のある潜在的な脅威を特定して対応できます。EC2 ワークロードに対する脅威には、多くの場合、マルウェアのダウンロードや実行につながるリモートコード実行が含まれます。これには、暗号通貨関連のアクティビティに関連付けられた IP アドレス、またはマルウェアのコマンドアンドコントロール関連の IP アドレスに接続している、AWS 環境内のインスタンスまたはセルフマネージドコンテナが含まれる可能性があります。 GuardDuty Runtime Monitoring は、悪意のあるファイルのダウンロードと実行を伴う疑わしいコマンドを各ステップにわたって可視化するため、最初の侵害時や、ビジネスに悪影響を及ぼすイベントになる前に脅威を検出するのに役立ちます。また、 AWS Organizations を利用して、組織全体のアカウントやワークロードについてのランタイム脅威検出の対象範囲を一元的に有効にし、セキュリティの対象範囲を簡素化することもできます。 GuardDuty で EC2 Runtime Monitoring を設定する 数回クリックするだけで、 GuardDuty コンソール で GuardDuty EC2 Runtime Monitoring を有効にすることができます。初めて使用する場合は、Runtime Monitoring を有効にする必要があります。 EC2 Runtime Monitoring 機能を初めて使用するお客様は、 30 日間無料 でこの機能を試して、すべての機能と検出結果にアクセスできます。GuardDuty コンソールには、無料トライアルの残り日数が表示されます。 これで、実行時の動作をモニタリングする個々の EC2 インスタンスのために GuardDuty セキュリティエージェントを設定できるようになりました。GuardDuty セキュリティエージェントを自動または手動でデプロイすることを選択できます。GA では、 [自動エージェント設定] を有効にすることができます。これは、GuardDuty がお客様に代わってセキュリティエージェントを管理できるようにする機能であり、ほとんどのお客様に推奨されるオプションです。 エージェントは、 AWS Systems Manager を利用して EC2 インスタンスにデプロイされ、 Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを使用して、リソースに関連付けられたランタイムイベントを受信します。GuardDuty セキュリティエージェントを手動で管理する場合は、AWS ドキュメントの「 Managing the security agent Amazon EC2 instance manually 」にアクセスしてください。複数アカウント環境では、委任された GuardDuty 管理者アカウントが AWS Organizations を利用してメンバーアカウントを管理します。詳細については、AWS ドキュメントの「 Managing multiple accounts 」にアクセスしてください。 EC2 Runtime Monitoring を有効にすると、対象の EC2 インスタンスのリスト、アカウント ID、カバレッジステータス、および対応するリソースからランタイムイベントをエージェントが受信できるかどうかを [EC2 インスタンスランタイムカバレッジ] タブで確認できます。 カバレッジステータスが [異常] の場合、すなわち、現在実行時の検出結果を受信できない場合でも、EC2 インスタンスのための多層防御は提供されています。GuardDuty は、CloudTrail、VPC フロー、およびそれに関連付けられた DNS ログをモニタリングすることで、EC2 インスタンスに対する脅威を検出し続けます。 GuardDuty EC2 Runtime のセキュリティに関する検出結果を確認する GuardDuty が潜在的な脅威を検出し、セキュリティに関する検出結果を生成すると、正常な情報の詳細を表示できます。 Amazon EC2 リソースに固有のセキュリティに関する検出結果を検索する場合は、左側のペインで [検出結果] を選択します。フィルターバーを使用して、 [リソースタイプ] を [インスタンス] にするなど、特定の条件で検出結果のテーブルをフィルタリングできます。検出結果の重大度と詳細は、EC2 リソースが疑わしいアクティビティのターゲットであるか、またはアクティビティを実行するアクターであるかを示すリソースのロールに基づいて異なります。 3月29日のリリースにより、悪用されたドメイン、バックドア、暗号通貨関連のアクティビティ、不正な通信の検出など、EC2 インスタンスのために 30 を超える実行時のセキュリティに関する検出結果がサポートされます。詳細なリストについては、AWS ドキュメントの「 Runtime Monitoring finding types 」にアクセスしてください。 EC2 のセキュリティに関する検出結果を解決する EC2 のセキュリティに関する各検出結果を選択すると、詳細が表示されます。検出結果に関連付けられたすべての情報を検索し、問題のリソースを調査して、想定どおりに動作しているかどうかを確認できます。 アクティビティが承認されている場合は、 抑制ルール または 信頼されている IP リスト を使用して、そのリソースについての誤検知による通知を防ぐことができます。アクティビティが想定されないものである場合、セキュリティに関するベストプラクティスは、インスタンスが侵害されたと想定し、AWS ドキュメントの「 Remediating a potentially compromised Amazon EC2 instance 」で詳述されているアクションを実行することです。 GuardDuty EC2 Runtime Monitoring は、 AWS Security Hub や Amazon Detective などの他の AWS セキュリティサービスと統合できます。あるいは、 Amazon EventBridge を利用して、Splunk、Jira、ServiceNow などのセキュリティイベント管理またはワークフローシステムとの統合を使用したり、調査のためにワークロードを分離するなどの自動および半自動の応答をトリガーしたりすることもできます。 [Detective で調査] を選択すると、Detective が作成した AWS リソースのビジュアライゼーションを見つけて、セキュリティに関する問題を迅速かつ簡単に調査できます。詳細については、AWS ドキュメントの「 Integration with Amazon Detective 」にアクセスしてください。 知っておくべきこと GuardDuty EC2 Runtime Monitoring サポートは、 Amazon Linux 2 または Amazon Linux 2023 を実行している EC2 インスタンスで利用できるようになりました。エージェントの最大 CPU およびメモリ制限を設定するオプションがあります。詳細および今後の更新については、AWS ドキュメントの「 Prerequisites for Amazon EC2 instance support 」にアクセスしてください。 GuardDuty の 1 日の平均使用コストを見積もるには、左側のペインで [使用状況] を選択します。30 日間の無料トライアル期間中に、トライアル期間後のコストを見積もることができます。トライアル期間の終了後、モニタリングエージェントについて追跡された vCPU 時間ごとに料金が毎月請求されます。詳細については、「 Amazon GuardDuty の料金 」ページにアクセスしてください。 EC2 Runtime Monitoring を有効にすると、GuardDuty のコストを節約することもできます。この機能が有効になっている場合、セキュリティエージェントを実行している EC2 インスタンスから取得された GuardDuty の基本的な保護 VPC フローログについての料金は発生しません。これは、セキュリティエージェントから入手可能な、類似しているが、よりコンテキストを踏まえたネットワークデータによります。さらに、GuardDuty は引き続き VPC フローログを処理し、関連する検出結果を生成するため、エージェントにダウンタイムが発生した場合でも、ネットワークレベルのセキュリティカバレッジを引き続き実現できます。 今すぐご利用いただけます Amazon GuardDuty EC2 Runtime Monitoring は、AWS GovCloud (米国) リージョンと AWS 中国リージョンを除く、GuardDuty が利用可能なすべての AWS リージョンで使用できるようになりました。EC2 Runtime Monitoring を使用できるリージョンの詳細なリストについては、「 Region-specific feature availability 」にアクセスしてください。 GuardDuty コンソール で GuardDuty EC2 Runtime Monitoring をぜひお試しください。詳細については、「 Amazon GuardDuty ユーザーガイド 」にアクセスしてください。また、 AWS re:Post for Amazon GuardDuty 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

Babelfish for Aurora PostgreSQL には、SQL Server ワイヤプロトコルと、Microsoft SQL Server で使用されるクエリ言語である T-SQL のサポートが含まれています。つまり、開発者は Babelfish を使用して、データベースドライバーを切り替えたり、クエリを完全に書き直したりすることなく、 Amazon Aurora PostgreSQL Compatible エディション で既存の SQL Server アプリケーションを実行できます。 SQL Server から Babelfish for Aurora PostgreSQL に移行する場合、次のようなさまざまなデータ移行オプションがあります。 AWS Database Migration Service (AWS DMS) を使用する。詳細については、「 AWS Database Migration Service で Babelfish for Aurora PostgreSQL をターゲットとして指定可能に 」を参照してください。 SQL Server Integration Services (SSIS) を使用する。詳細については、「 SSIS と Babelfish を使用した SQL Server から Aurora PostgreSQL への移行 」を参照してください。 T-SQL insert コマンドの生成 (SQL Server Management Studio によるスクリプトの生成)。 一括コピープログラム (bcp) ユーティリティを使用する。 この投稿では、データ移行に bcp を使用する場合の詳細と制限について説明します。 ソリューション概要 SQL Server の開発者や管理者であれば、 bcp ユーティリティ について聞いたことがあるでしょう。bcp ユーティリティは、SQL Server データベースとの間で大量のデータをインポートまたはエクスポートできるコマンドラインツールです。 bcp を使用すると、ある SQL Server のテーブルから Babelfish for Aurora PostgreSQL にデータをすばやく転送できます。さらに、Insert メカニズムは行ごとではなく行のバッチを使用して最適化されるため、bcp は効率的です。また、ロギング操作を最小限に抑えることもできます。 Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL の使用 」を参照してください。 前提条件 以下の前提条件を満たしていることを確認してください。 SQL Server Management Studio (SSMS) または bcp ユーティリティ をインストールする必要があります。 SQL Server ネイティブクライアント を端末にインストールする必要があります。 bcp の制約 このデータ移行オプションには、次の制限があることに注意してください。 bcp はテーブルスキーマを移行しません。 bcp は SQL Server データベースと Babelfish を連携しますが、いくつかの制限があります。特定のオプション ( -C 、 -T 、 -G 、 -K 、 -R 、 -V 、 -h ) はサポートされていません。 Babelfish v2.1 (Aurora PostgreSQL 14.3) 以降でサポートされています。 フィールド / 行ターミネータがデータに含まれる場合、既知の問題があります。デフォルトのフィールドターミネータは \t (タブ文字) で、デフォルトの行ターミネータは \n (改行文字) です。使用しているフィールドターミネータがデータに含まれていて ( Major, Mary など) 、 , をフィールドターミネータとして使用している場合、このレコードをインポートする際に問題が発生します (無効な文字値のエラーメッセージ)。 たとえば、次の列があるテーブルを想像してみてください。 ID Name Date 1 Major,Mary 1981-01-01 2 John 1980-02-02 bcp をターミネーターフィールド ( -t ) として使用すると、次の出力が得られます。 1 ,Major,Mary,1981-01-01 2 ,John,1980-02-02 Bash 最初の行には、データに含まれていた追加項目があることに注意してください。このレコードのデータインポートは失敗する可能性があります。または、データをエクスポートおよびインポートするときに -t | パラメータやその他のカスタムターミネータ文字を使用することもできます。フィールドターミネータ -t | を使用すると、次のような出力が得られるはずです。 1|Major,Mary|1981-01-01 2|John|1980-02-02 Code 同じことが行ターミネータにも当てはまります。カスタマイズしたフィールド / 行ターミネータの使用方法の詳細については、「 フィールドターミネータと行ターミネータの指定 」を参照してください。 BCP を使用した SQL Server からのデータエクスポート 次の構文を参考にして、bcp を使用して SQL Server データベースからデータをエクスポートできます。 bcp [ schema.table_name ] out [ output_file ] -c -d [ database_name ] -S [ server_name ] -U [ username ] -P [ password ] Bash ソーステーブルの名前、出力ファイルの名前、およびデータベースアクセス認証情報を指定する必要があります。bcp は、テーブルの全てのデータを指定されたファイルにエクスポートします。 テーブルが数百ある場合は、次の T-SQL コマンドを使用して、データをエクスポートする bcp コマンドを生成できます。 USE MyDBName GO DECLARE @Folder VARCHAR ( 100 ) = 'c:\temp\', @dbName VARCHAR(100) = ' MyDBName ', @sqlInstance VARCHAR(50) = ' SQLServer Instance Name ', @user VARCHAR(50) = ' SQL Login ', @pwd VARCHAR(100) = ' MyPWD #123' SELECT CONCAT ( 'bcp ' , SCHEMA_NAME ( schema_id ) , '.' , name , ' out "' , @Folder , name , '.dat' , '" -c -d ' , @dbName , ' -S ' , @sqlInstance , ' -U ' , @user , ' -P ' , @pwd ) FROM sys . tables WHERE is_ms_shipped = 0 GO SQL bcp を使用した Babelfish for Aurora PostgreSQL へのデータインポート 次の構文を参考にして、bcp を使用して Babelfish にデータをインポートできます。 bcp [ schema.table_name ] in [ input_file ] -c -S [ server_name ] -d [ database_name ] -U [ username ] -P [ password ] Bash 保存先テーブルの名前、入力ファイルの名前、およびデータベースアクセス認証情報を指定する必要があります。bcp は、ファイルからすべてのデータを指定されたテーブルにインポートします。 データをインポートする場合、文字データ型 ( -c ) またはネイティブ形式 (データのエクスポート時に使用したバイナリ ( -n ) など) を使用してデータをエクスポートしたときと同じパラメータを使用することが非常に重要であることに注意してください。これはプラットフォーム間のデータ移行であるため、 -c パラメータを使用する必要があります。 テーブルが数百ある場合は、次の T-SQL コマンドを使用して、データをインポートする bcp コマンドを生成できます。 USE MyDBName GO DECLARE @Folder VARCHAR ( 100 ) = 'c:\temp\', @dbName VARCHAR(100) = ' MyDBName ', @sqlInstance VARCHAR(100) = ' Mybbf_instance . cluster - cxxxxxxxxxbpc . us - east - 1. rds . amazonaws . com ', @user VARCHAR(50) = ' postgreslogin ', @pwd VARCHAR(100) = ' MyPWD #123' SELECT CONCAT ( 'bcp ' , SCHEMA_NAME ( schema_id ) , '.' , name , ' in "' , @Folder , name , '.dat' , '" -e "' , @Folder , name , '.err' , '" -c -d ' , @dbName , ' -S ' , @sqlInstance , ' -U ' , @user , ' -P ' , @pwd ) FROM sys . tables WHERE is_ms_shipped = 0 SQL bcp パラメータ bcp には、データの形式や文字エンコーディングを指定する機能など、 多くの便利なパラメータ があります。 次の表は、bcp ユーティリティを使用して Babelfish for Aurora PostgreSQL にデータをインポートするときにサポートされる、一般的に使用されるパラメータをまとめたものです。 Parameter Description Default -b バッチごとの行数を指定します。各バッチは個別のトランザクションとしてインポートされ、記録されます。 All rows -c すべてのデータをテキストとしてフォーマットする操作を実行します。 -d 接続するデータベース名。 -e bcp が転送できなかった行を格納するエラーファイル。 このオプションは、インポートできなかった行とそれに対応するエラーメッセージを含むエラーファイルを生成します。 -m bcp が操作をキャンセルするまでに許容される最大エラー数。 デフォルトでは、bcp は操作がキャンセルされるまでに最大 10 件のエラーを考慮します。最初のエラーで操作をキャンセルするには、 -m 1 パラメータを使用します。 10 -P Babelfish for Aurora PostgreSQL または SQL Server に接続するためのログインパスワードを指定します。 -S Aurora PostgreSQL エンドポイント用の SQL Server または Babelfish を指定します。 -t フィールドターミネータに通知します。詳細については、「 フィールドターミネータと行ターミネータの指定 (SQL Server) 」を参照してください。 \t -U Babelfish for Aurora PostgreSQL または SQL Server に接続するためのログインユーザー。 bcp のエラーハンドリング このセクションでは、bcp を使用してデータをエクスポートおよびインポートするときに直面する可能性のあるいくつかの課題と、その処理方法について説明します。 テキストファイルを作成しているだけなので、通常、bcp エクスポートを実行しても問題はありません。ただし、このデータをインポートする場合、データの品質によっては問題が発生する可能性があります。最も一般的な問題は以下のとおりです。 主キー違反 区切りフィールドの間違い 無効なデータ bcp はデフォルトで、操作をキャンセルする前にエラーの数が 10 個に制限されていることを覚えておくことが重要です。bcp に最初のエラーで操作をキャンセルさせたい場合は、パラメータ -m 1 を渡すことでこの動作を変更できます。 -e パラメータを使用して、詳細なエラーを含むファイルを生成することもできます。 次のスクリーンショットは、データをインポートする際のエラーの例を示しています。 この例は、エラーが発生し、エラーが発生したにもかかわらずインポート処理が続行されたことを示しています。エラーメッセージには無効なデータがあったことが示されていますが、どのレコードがこの問題の原因になっているのか正確にはわかりません。最初のエラーでプロセスを停止させたい場合は、パラメータ m 1 を渡してください。 コマンドを繰り返し、 -e パラメータを追加してエラーファイルを生成してみましょう。bcp コマンドの出力は似ていますが、今度はエラーファイル SalesOrderDetail.err があることに注意してください。 エラーファイルを開くと、エラーの詳細と、問題の原因となっているレコードが表示されます。 最初のエラーは、8 行目に無効な文字が含まれていることを示しています。次の行には、bcp がインポートしようとしているレコードも表示されます。3 番目の列が分割されていることがわかります。これはターミネータフィールドにエラーがある可能性があります。bcp で生成されたファイルを開いて 8 行目を調べると、問題のあるレコードと行が表示されます。 エラーファイルの次のエラーは 41,079 行目にあります。エラーメッセージには、無効な日付形式があると表示されます。エラーファイルにはエラーのあるレコードも表示され、日付 213-06-30 のフィールドに入力ミスがあることがわかります。 3 番目のエラーは 88,898 行目にあります。エラーメッセージに Invalid character と表示され、日付フィールドに 2014-0i-29 という無効な文字が表示されます。 これらは、bcp でエラー処理を行う方法の例です。 -e パラメータを使用すると、エラーとエラーのあるレコードを検索する時間を大幅に節約できます。 ベストプラクティス bcp を使用して SQL Server データベースからデータを移行する場合、次のベストプラクティスを考慮する必要があります。 データ移行後に外部キーを作成することを検討してください。これにより、データの整合性が確保されます。外部キーを削除せずにデータをインポートする場合は、テーブルを正しい順序でロードするようにしてください。そうしないと、外部キー違反があることを知らせるエラーメッセージが表示され、操作が失敗します。 大きなテーブルや大量のデータをインポートする場合は、インデックスを削除し、bcp を使用してデータをロードしてから、インデックスを再作成することを検討してください。テーブルを読み込む前にインデックスを削除すると、データロード処理が速くなり、その後、必要に応じてインデックスを再作成します。 SQL Server を Aurora PostgreSQL に移行するので、文字データ型を使用してデータをエクスポートおよびインポートするには -c パラメータが必要です。 フィールドターミネータと行ターミネータがデータに含まれている場合は注意してください。 大量のレコードをインポートする場合、 -e パラメータを使用してエラーファイルを生成します。 まとめ この投稿では、AWS DMS、SSIS、またはカスタマイズされたスクリプトを使用する従来のアプローチを越えて、データ移行の代替オプションを検討しました。その過程で、bcp ユーティリティがサポートするさまざまなパラメータを示しました。これにより、データ移行プロセスを微調整できるようになりました。また、問題のあるデータや誤ったデータを扱う際に発生する可能性のある問題を調査するのに役立つ、エラーを効果的に処理する手法についても検討しました。 学習の締めくくりとして、bcp ユーティリティを使用して Babelfish へのデータ移行をスムーズかつ成功させるためのベストプラクティスを掘り下げました。 この機能と Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL の使用 」を参照してください。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Marcelo Fernandes は、AWS プロフェッショナルサービスチームのシニアデータベースアーキテクトです。データベースソリューションをオンプレミスのデータセンターから AWS に移行してモダナイズする過程で、お客様を支援してきました。 David Carvalho Queiroz は、データベースエンジニアリングマネージャーとして Amazon Games のライブオペレーションデータベースチームを率いています。Amazon Games 内の複数のタイトルのデータベースアーキテクチャの AWS への移行、データパイプライン開発、キャパシティプランニング、最適化/チューニング、自動化戦略、GDPR コンプライアンスを担当しています。 Eduardo Valentim は AWS プロフェッショナルサービスチームのシニアデータベースコンサルタントで、データベース分野で 17 年以上の経験があります。Eduardo はキャリアを通じて、移行、設計、パフォーマンスの最適化など、データベース関連の課題を抱えるお客様の支援をしてきました。Eduardo は、パフォーマンスとセキュリティに関する最新のベストプラクティスを常に把握することで、クライアントの環境が成功に向けて最適化されていることを確認しています。

SQL Server データベースを Babelfish for Aurora PostgreSQL に移行するには、通常、自動タスクと手動タスクの両方を実行する必要があります。自動化タスクには、 -rewrite フラグの付いた Babelfish Compass ツール を使用した自動コード変換と、 AWS Database Migration Service (AWS DMS) を使用したデータ移行が含まれます。手動タスクには、Babelfish Compass ツールを使用したデータベース互換性チェック、Babelfish でサポートされていない特定のデータベースオブジェクトの移行回避策、および結果の手動検証が含まれます。 この投稿では、SQL Server の MERGE ステートメントを Babelfish 互換の T-SQL コードに自動的に変換する Babelfish Compass ツールの -rewrite フラグ機能に焦点を当てます。この記事で紹介した一例が MERGE ステートメントですが、 -rewrite は他の機能にも使用できます。また、結果を手動で検証するベストプラクティスについても説明します。 Babelfish Compass を使用すると、ソースである SQL Server データベースがターゲットの Babelfish データベースと互換性があるかどうか、および Babelfish で現在サポートされていない機能や移行できない機能を確認できます。 PostgreSQL 15 は MERGE をサポートしていますが、 Babelfish はまだサポートしていません 。また、PostgreSQL の MERGE は SQL Server の MERGE と完全には同じではありません。たとえば、「RETURNING」や「NOT MATCHED BY SOURCE」という句はサポートされていません。 Babelfish Compass の -rewrite フラグの概要 -rewrite フラグを使用すると、Babelfish Compass 評価レポートの「unsupported」セクションに含まれている MERGE ステートメントを変換することができます。 コマンドプロンプトで Babelfish Compass ツールを実行します。 Mac および Linux でコンパスを実行するための手順はこちら。 BabelfishCompass.bat MyFirstReport C: \ work \ merge_example.sql -rewrite -reportoption xref Bash -rewrite フラグは、Babelfish Compass 評価レポートで、Babelfish ターゲットとの互換性を確保するために SQL コードを手動で書き直すよう提案されている場合に役立ちます。 Babelfish-compatible の T-SQL コードに変換する手作業の一部を取り除くことができます。ただし、対応する書き換えられた SQL コードを注意深く確認する必要もあります。 SQL Server の MERGE ステートメントの理解 SQL Server の MERGE は、挿入、更新、削除を 1 つのステートメントとトランザクションにまとめます。MERGE ステートメントは、ソーステーブルから行を選択し、1 回のトランザクションでターゲットテーブルに対して複数の DML 操作を実行します。 SQL Server MERGE のシナリオを示すために、SQL Server データベースと Babelfish に次のテストテーブルを作成します。 Person_Target はターゲットテーブルで Person_Source はソースで、その行はマージ条件に基づいて Person_Target テーブルにマージされます。 CREATE TABLE dbo . Person_Target ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) CREATE TABLE dbo . Person_Source ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) SQL 次の INSERT ステートメントは、 Person_Source テーブルと Person_Target テーブルにサンプルデータを挿入します。 INSERT INTO Person_Source values ( 1 , 'Ana Carolina Silva' ) , ( 3 , 'Carlos Salazar' ) , ( 4 , 'John Doe' ) INSERT INTO Person_Target values ( 1 , 'Ana Carolina ' ) , ( 2 , 'Diego Ramirez' ) , ( 3 , 'Carlos Salazar' ) SQL 次のコードは、 Person_Source テーブルのデータを Person_Target テーブルにマージします。MERGE の後のセミコロンは実際には必須です。 MERGE Person_Target T USING Person_Source S ON T . PersonID = S . PersonID WHEN MATCHED THEN UPDATE SET PersonName = S . PersonName WHEN NOT MATCHED BY TARGET THEN INSERT ( PersonID , PersonName ) VALUES ( S . PersonID , S . PersonName ) WHEN NOT MATCHED BY SOURCE THEN DELETE ; SQL Person_Target テーブルの各行について、SQL Server はマージ条件と呼ばれる検索条件を評価します。条件が一致すると、結果が true になり、SQL Server は Person_Source テーブルの対応するデータでターゲットテーブルの行を更新します。どの行でも条件に一致しない場合、結果は false となり、SQL Server は対応する行をソーステーブルからターゲットテーブルに挿入します。ソーステーブルのどの行でも条件が一致しない場合、その行はターゲットから削除されます。次の図は、このワークフローを示しています。 ターゲットテーブルを検証し、 Person_Target テーブル内のデータが前の図と一致するかどうかを確認できます。 Babelfish での SQL Server MERGE ステートメントの書き換え PostgreSQL の場合、MERGE ステートメントのような構造はありません。ただし、Compass ツールは MERGE を Babelfish の個々の挿入、更新、削除ステートメントとして書き換えることができます。 次のステートメントは、Babelfish に Person_Source テーブルと Person_Target テーブルを作成し、データを挿入します。 CREATE TABLE dbo . Person_Target ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) ; CREATE TABLE dbo . Person_Source ( PersonID int NULL , PersonName varchar ( 100 ) NULL ) ; INSERT INTO Person_Source values ( 1 , 'Ana Carolina Silva' ) , ( 3 , 'Carlos Salazar' ) , ( 4 , 'John Doe' ) ; INSERT INTO Person_Target values ( 1 , 'Ana Carolina ' ) , ( 2 , 'Diego Ramirez' ) , ( 3 , 'Carlos Salazar' ) ; SQL 次のコードは、レポートフォルダー内の rewrite というフォルダー内に自動的に生成されます。 /* original MERGE statement -- MERGE Person_Target T USING Person_Source S ON T.PersonID=S.PersonID WHEN MATCHED THEN UPDATE SET PersonName=S.PersonName WHEN NOT MATCHED BY TARGET THEN INSERT (PersonID,PersonName) VALUES (S.PersonID,S.PersonName) WHEN NOT MATCHED BY SOURCE THEN DELETE; -- end original MERGE statement */ /*REWRITTEN*/ /* --- start rewritten MERGE statement #1 --- */ /* Note: please review/modify the rewritten SQL code below, especially for handling of ROLLBACK */ BEGIN TRANSACTION SAVE TRANSACTION savept_merge_rewritten_1 DECLARE @MERGE_REWRITTEN_ROWCOUNT_1 INT = 0 /* use instead of original @@ROWCOUNT */ DECLARE @MERGE_REWRITTEN_ERROR_1 INT /* temporary variable */ DECLARE @MERGE_REWRITTEN_RCTMP_1 INT /* temporary variable */ /* WHEN MATCHED THEN UPDATE */ UPDATE T SET PersonName = S . PersonName FROM Person_Target T , Person_Source S WHERE T . PersonID = S . PersonID SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 /* WHEN NOT MATCHED BY SOURCE THEN DELETE */ DELETE T FROM Person_Target T WHERE NOT EXISTS ( SELECT * FROM Person_Source S WHERE T . PersonID = S . PersonID ) SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 /* WHEN NOT MATCHED BY TARGET THEN INSERT */ INSERT INTO Person_Target ( PersonID , PersonName ) SELECT S . PersonID , S . PersonName FROM Person_Source S WHERE NOT EXISTS ( SELECT * FROM Person_Target T WHERE T . PersonID = S . PersonID ) SELECT @MERGE_REWRITTEN_ERROR_1 = @ @ERROR , @MERGE_REWRITTEN_RCTMP_1 = @ @ROWCOUNT IF @MERGE_REWRITTEN_ERROR_1 <> 0 GOTO lbl_rollback_merge_rewritten_1 SET @MERGE_REWRITTEN_ROWCOUNT_1 + = @MERGE_REWRITTEN_RCTMP_1 GOTO lbl_commit_merge_rewritten_1 /* in case of an error, roll back to savepoint at the start but do no abort the transaction: there may be an outermost transaction active*/ lbl_rollback_merge_rewritten_1: ROLLBACK TRANSACTION savept_merge_rewritten_1 lbl_commit_merge_rewritten_1: COMMIT ; /* --- end rewritten MERGE statement #1 --- */ END GO SQL 違いの1つは、 @@rowcount は SQL Server と異なるということです。これが、書き直されたコードに @MERGE_RWRITTEN_ROWCOUNT_n が含まれている理由です。 コードをプロシージャ用に変換した後で、SQL Server テーブルと Babelfish PostgreSQL の person_target テーブル内のデータが一致していることを確認できます。 考慮事項 MERGE ステートメントが文字列変数で動的に作成される場合、Babelfish Compass ツールを使用して書き換えることはありません。このようなシナリオでは、手動で変換する必要があります。 -rewrite フラグは Babelfish がサポートしていないかぎり MERGE に影響します。いったん機能がサポートされると、 -rewrite はそれ以上書き換えを試みません。 結論 この投稿では、SQL Server で使用される MERGE ステートメントの例を1つ取り上げて、Babelfish Compass ツールの -rewrite フラグを使用してそれらを同等の Babelfish T-SQL コードに変換する方法を説明しました。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Shyam Sunder Rakhecha は、インドのハイデラバードを拠点とする AWS のプロフェッショナルサービスチームのリードコンサルタントで、データベースの移行とモダナイゼーションを専門としています。AWS クラウドの移行と最適化においてお客様を支援しています。彼はデータベースという観点から新しいテクノロジーを探求することと、 RDBMS とビッグデータに興味を持っています。また、チームビルディングのイベントを開催したり、チームで集まったりするのも大好きです。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2024 年 1 月 24 日に、「自治体ｘスタートアップ・ISV マッチング・交流会」を AWS Startup Loft Tokyo にて開催しました。本イベントでは、スタートアップとの協業に関心を持つ自治体の方々と、実証実験先を探すスタートアップ・ISV の方々をお招きし、マッチングと交流会を行いました。今回はそのレポートをお届けします。 各自治体によるプレゼンテーション イベント前半では、各自治体の関係者の方々がプレゼンテーションを行いました。 北海道札幌市（左）、栃木県宇都宮市（中央）、静岡県浜松市（右） 北海道札幌市 2023 年 9 月に、北海道と札幌市、北海道経済産業局がスタートアップの支援事業を一元化して、「STARTUP HOKKAIDO実行委員会」を設立したことを発表しました。北海道のスタートアップがグローバルで活躍することを目指しています。 栃木県宇都宮市 宇都宮市は、「HELLO,NEW CITY.」というスローガンのもと、次世代型路面電車「ライトライン」や宇都宮駅に直結するコンベンション施設「ライトキューブ」が開業するなど、まちが大きく変化する中で、スタートアップ・エコシステムの構築にも力を入れており、スタートアップ等とのオープンイベーションによる“共創”のまちづくりを進めています。 静岡県浜松市 スズキ、ホンダ、ヤマハ、河合楽器、浜松ホトニクスなどのグローバル企業が生まれている都市・浜松市。日本のシリコンバレーになることを目指し、「ものづくり企業✕スタートアップ」の融合によるイノベーション創出を推進しています。また、令和 2 年には愛知県・名古屋市および浜松市が連携して「スタートアップ・エコシステムグローバル拠点都市」に認定されました。 京都府京都市（左）、大阪府堺市（中央）、宮崎県宮崎市（右） 京都府京都市 観光都市のイメージが強い京都市ですが、スタートアップ支援のための取り組みも行っています。現在、京都市内には約500社ほどのスタートアップがありますが、スタートアップの創出・成長を加速させていき、これを大幅に増やすことを目指しています。その一環として、京都市の行政課題をオープンにし、それらを解決できる技術やノウハウを持った事業者を募っています。 大阪府堺市 堺市は西日本最大のニュータウンのある自治体。新しい技術やサービスを積極的に導入し、地域の課題を解決しながら、住民の暮らしの質を向上させる取り組みを推進してきました。また、社会的な課題や地球環境の問題への挑戦も積極的に進めています。中百舌鳥エリアをイノベーション創出拠点と位置づけています。 宮崎県宮崎市 民間と宮崎市がつながり、パートナーシップのもと、政策や価値を創造して成長を目指すための公民連携総合窓口「みやざき CITY PORT」を開設しています。また、宮崎市域の社会課題解消に向けた事業創出の場を提供するため、民間企業や起業家が中心となり「宮崎オープンシティ推進協議会」を立ち上げる予定です。 イベントには、他にも以下の自治体の方々が参加されました。 北海道釧路市、栃木県栃木市、静岡県静岡市、兵庫県神戸市、香川県高松市、大分県大分市 スタートアップ各社によるプレゼンテーション イベント後半では、各スタートアップがプレゼンテーションを行いました。 polyfit株式会社（左上）、株式会社ナイルワークス（右上）、株式会社インサイトテクノロジー（左下）、WisHealth株式会社（右下） polyfit株式会社 地域と学校をつなぐ領域で事業展開する GovTech スタートアップ。PTA 活動のデジタル化を目指すプロダクト「polyfit for PTA」や、教育委員会・行政機関と連携し学校業務を地域に移行するためのアルゴリズム学習型人材バンク「polyfit for CS」を展開しています。自治体向け事業は実証実績があり、今後さらに多くの分野で実施していく予定です。 株式会社ナイルワークス 農業分野のスタートアップです。作物の形状解析技術と生育シミュレーションを活かし、地域の気候・特性に合った栽培・管理方法の整備に取り組んでいます。作物の収穫予測による栽培・流通の効率化や、肥料・農薬の適正使用などに寄与。農業に関わる経済性と環境負荷の改善を支援し、持続可能な農業の実現を目指しています。 株式会社インサイトテクノロジー データやデータベース関連のソリューションを展開しています。文書内に含まれる個人情報の検知と匿名化する機能で、自治体における「個人情報を含む文書のメール送信防止」や「情報公開時の文書の墨消し作業」「ガバメントクラウド移行用テストデータ作成」などをサポートしています。 WisHealth株式会社 患者の主体性の向上や医療現場の業務効率化、自治体における医療政策や医療サービスの改善という 3 つを両立するサービス「Patient Success」を展開しています。自治体住民のプライマリーケアを担うクリニックでの導入により、自治体健診の受診率向上やスムーズな医療体験の提供などの事例があります。貴重なデータを自治体の政策へ活かすことも始まっています。 FRAIM株式会社（左上）、株式会社Mikulak（右上）、CoinEZ株式会社（左下）、株式会社Alumnote（右下） FRAIM株式会社 「文書作成を、再発明する。」を企業ビジョンとし、次なる文書体験の提供による新たな働き方の実現のために、企業や官公庁向けの文書作成支援ツールの開発・提供、および保有する技術要素（エディタ・AI 関連）の提供をしています。徳島県、兵庫県尼崎市など複数の自治体での導入実績があり、経済産業省・防衛省での実証事業も実施。公的機関における文書業務の改善・効率化に貢献しています。 株式会社Mikulak 小中学校向けの教育事業を提供するスタートアップ。世界でも類を見ない、AI を組み込んだ授業・校務支援アプリ「ClassCloud」で子どもたち一人ひとりの最適な学びや協働学習を支援します。また、AI による子どもの投稿の分析や交友関係の可視化、通知表の所見の自動生成機能などで授業・校務をサポート。教員の業務を削減して働き方改革を進めます。自治体との連携のほか、上場企業との提携や大学との共同研究も行っています。 CoinEZ株式会社 キャッシュレス社会へ移行するうえで、次なる段階はコインレス決済です。お釣りを電子マネーで受け取り可能にすることで、「小銭」という社会課題を発生源から根本的に解決します。従来ではあり得ない店舗での後払いを実現させ、将来的にユーザーは受け取った釣り銭を他社の提供する地域通貨や〇〇ペイへ自動移行可能になります。 株式会社Alumnote 「次世代の教育に資本をまわす」をミッションに大学・教育機関の資金調達手段のアップデートを目指している東京大学発スタートアップ。寄付金を元本とした大学基金の運用益を大学の新しい財源とするために、大学コミュニティの活性化と大学のファンドレイジング業務をサポートし、デジタルツールの提供と寄付獲得の実行支援を提供しています。 株式会社トルビズオン（左上）、Soteria8 co. ltd（右上）、株式会社ぐるり（左下）、BellaDati合同会社（右下） 株式会社トルビズオン ドローン空路整備サービスである「S:ROAD」を開発・運用しています。「S:ROAD」は定期航路となるドローンの飛行空域を可視化し、ドローン産業の社会実装を推進。ドローン事業者は「S:ROAD」を利用し、地域代理店であるスカイディベロッパーが開拓した空路を利用することができます。「S:ROAD」には、空に「住所」を作り、空域に関する情報データベースとひも付ける特許技術「スカイドメイン®︎」が用いられています。 Soteria8 co. ltd ロボットと AI を活用して老朽化したインフラのレジリエンスと安全状態を診断するスタートアップです。探査ロボットで老朽化インフラの外観イメージデータを収集し、コンピュータービジョンのディープラーニング技術を活用して国土交通省の安全診断基準に適合しないポイントを診断します。自治体の老朽化インフラのメンテナンス状況、地理的位置、災害・事故のタイプなどに応じて、迅速かつ正確に診断するためのカスタマイズされたロボティクスと AI モデルをクラウドで実装します。 株式会社ぐるり オーバーツーリズムなどの「観光」の課題に対し、寺社仏閣や史跡といった「歴史資源」を活用した周遊・分散を目指しています。同社が提供するサービス「GURURI」ではイラストマップ上に歴史コンテンツを表示します。ユーザーはそこで美術館のような音声ガイドや投稿機能、訪れた史跡のログも取得できます。歴史上の人物のようなテーマ型のコンテンツをプラットフォームに集約することで、ユーザーはどこでもそのコンテンツを利用可能。また、訪れたユーザーの属性や位置情報などのデータ分析も行っています。 BellaDati合同会社 2022 年 4 月より日本法人を立ち上げました。国内大手自動車会社を筆頭に、日本市場における製造、物流、建設関係の企業へ、データドリブンな業務改革の支援や、新規ビジネス開発の共創を推進しています。グローバルでの約 20,000 件の導入実績に基づいた IoT プラットフォーム導入テンプレートにより、データ収集から蓄積・分析・可視化・サービス化までを実現。新規ビジネス開発を早期に立ち上げたい顧客に向けて、最適なフレームワークを超短納期で提供します。 株式会社Singular Perturbations（左）、株式会社Mamawell（中央）、株式会社ゼネックコミュニケーション（右） 株式会社Singular Perturbations 独自アルゴリズムによる犯罪予測結果を用いた防犯パトロール支援アプリ「Patrol Community」を提供しています。パトロール業務を効率化するほか、アプリによる市民通報の仕組みで地域の安全活動における DX を実現します。 株式会社Mamawell 妊娠・育児期の女性を対象に、専属助産師が健康支援を行います。専用アプリとウェアラブルデバイスで取得した健康データから妊婦の活動状況をモニタリングし、専属助産師が適切な活動量を達成するための生活改善支援をします。導入企業には、妊婦社員の健康状態をフィードバックし、過度な業務負担の予防や職場内のコミュニケーションギャップを解消。企業全体のエンゲージメントや生産性の向上を提供します。 株式会社ゼネックコミュニケーション IoT プラットフォームサービス「IoT Station」の開発、およびサービス展開を行っている企業です。「IoT Station」は、通信回線やゲートウェイ、IoT センサーの種類を問わず、多種多様なデータを Web ブラウザ上で可視化するサービス。収集データをひとつの画面に集約し一元管理することで、業務の効率化や省人化など、さまざまな課題を解決へと導きます。 Networking イベント終盤では、自治体の方々やスタートアップ・ISV で働く方々が参加しての Networking が実施されました。他のイベントやコミュニティなどではなかなか実現できないような、貴重な出会いが数多くあったようです。参加者同士の名刺交換や活発な議論が行われました。こうした交流が新たな協業やプロジェクトの始まりにつながる可能性もあるため、有益な Networking となったようでした。 AWS パブリックセクターは今後も、公共分野でのイノベーションを加速させるため、自治体やスタートアップの皆様をご支援してまいります。ご関心を持たれた方は、ぜひお気軽に こちら までお問い合わせください。

お客様は、クラウドベースのソリューションを導入する際に、システムが円滑に稼働していることを確認し、問題が発生したときに迅速に修正できるようにする必要があります。しかし、オブザーバビリティを特に企業間をまたがって数十から数百のサービスが関わるような大規模に展開することは、簡単にはいかない場合があります。そのため、お客様はベストプラクティスの推奨事項、ツールの選択に関するガイダンス、そして最も重要な、オブザーバビリティを開始するための段階的なプロセスを求めています。AWS での堅牢なオブザーバビリティ戦略を実装するプロセスを簡素化するために、 ベストプラクティスガイド をまとめました。この記事では、ガイドで取り上げられているトピック、ガイドの活用方法、およびガイドへ貢献する方法について説明します。このベストプラクティスガイドは、お客様がオブザーバビリティ戦略を開始し、より複雑なシナリオに対応できるように進化させるためのロードマップを提供します。 ベストプラクティスガイドで取り上げられているトピック このベストプラクティスガイドは、AWS サービス、データタイプ、および特定のオブザーバビリティツールごとにまとめられています。さらに、このガイドには実際のお客様へのエンゲージメントとお客様のフィードバックから導き出された 厳選されたレシピ も含まれています。厳選されたレシピは、ユーザーがニーズとオブザーバビリティの獲得によって得られる効果や成果に基づいて、オブザーバビリティを始めるのに役立つテンプレート化されたソリューションです。モニタリングとオブザーバビリティを始めたばかりの場合は、 一般的なベストプラクティス から始めて、選択したツールとデータタイプに基づいて、他のセクションに進むことができます。オブザーバビリティ戦略を成熟させたいと考えている場合は、関心のある特定のセクションから直接始めることができます。どのようなアプローチをとるにせよ、ベストプラクティスガイドに記載されているように、オブザーバビリティを後から付け加えるのではなく、初めから積極的にオブザーバビリティを計画する必要があります。 ベストプラクティスガイドは、プロセスを始める際に 適切なツール を選択するといったシナリオから、ハイブリッドまたはマルチクラウド環境での 追加の考慮事項 、 機械学習 を使用してベースラインを管理し異常を特定するシナリオまで、幅広い範囲をカバーしています。 このガイドでは、データを可能な限り収集したくなる誘惑があるものの、システムの劣化、面倒な分析、コストの膨張につながる可能性があると述べています。そこで、 重要なメトリクス に焦点を当てることを推奨しています。これらのメトリクスは業界や企業によって異なります。例えば、決済処理会社は取引処理時間を追跡したいと考えるかもしれません。また、大学は学生の出席状況を追跡したいと考えるかもしれません。次に、これらのメトリクスへの影響に基づいて、収集するテレメトリデータを決める必要があります。このガイドでは、ワークロードのすべての層でテレメトリデータを収集することもアドバイスしています。多くの場合、エンドユーザーの環境で問題の特定が必要になるため、すべての層のデータからインサイトを得ることができるように、 単一な一意の識別子 を持つことが重要です。さらに、このガイドでは、 適切なトレーシングエージェント を選択する方法についての有用な情報も提供しています。 このガイドには、 Amazon Elastic Compute Cloud (Amazon EC2) と データベース のモニタリングに関するベストプラクティスをまとめた個別のセクションがあります。また、Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Kubernetes Service (Amazon EKS) について、AWS やマネージドオープンソースソリューションを使ってシステムおよびサービスのメトリクスを収集する方法を重点的に説明したセクションも用意されています。 このガイドでは、 オブザーバビリティツールのコスト のベストプラクティスも紹介し、そのコストを可視化するための選択についても推奨しています。このガイドには、サービスレベル指標（SLI）、サービスレベル目標（SLO）、サービス品質保証（SLA）を計算してモニタリングするためのベストプラクティスが簡潔な例と共に説明されています。一部のお客様は、特定のユースケースに対処するために、 Databricks on AWS などのパートナーソリューションにワークロードをデプロイしています。このガイドでは、AWS ネイティブサービスや AWS マネージドオープンソースサービスを使用して、このようなワークロードを監視するためのベストプラクティスも説明しています。パートナーソリューションのセクションでは今後も他のパートナーソリューションを追加し、拡張していく予定です。 オブザーバビリティは ログ 、 メトリクス 、 トレース の 3 つの柱に基づいており、それぞれに焦点を当てる必要があります。そのため、ベストプラクティスガイドでは、データタイプセクションでそれらを個別のサブセクションとして扱っています。 現在、アーキテクチャのほとんどが イベント ドリブンであり、オブザーバビリティには特別な考慮が必要です。データタイプのセクションでは、イベントをオブザーバビリティと統合し、実行可能なインサイトを得るためのベストプラクティスを確認できます。このセクションの最後では、 アラーム に関するトピックと、アラーム疲れや「すべて問題なしアラーム」のような一般的な課題を避けるためのベストプラクティスを説明しています。 また、ツールのセクションでは、オブザーバビリティツールのベストプラクティスについても確認できます。このセクションには、Amazon CloudWatch エージェント、アラーム、ダッシュボード、Amazon CloudWatch Internet Monitor、Amazon CloudWatch Logs、メトリクス、Real User Monitoring、Syntheticテスト、AWS X-Ray によるトレーシングのベストプラクティスが含まれています。最後に、 厳選されたレシピ を確認して、他の AWSのお客様の経験を学ぶことをおすすめします。厳選されたレシピでは、オブザーバビリティ、テレメトリ（発信元と宛先別のシグナル）、タスクの6つのディメンションで構成されています。ワークロードに合ったディメンションに基づいて、厳選されたレシピを見つけることができます。例えば、AWS Lambda と Amazon RDS で構成されたアプリケーションがある場合は、そのディメンションにまとめられたレシピを見つけることができます。また、ワークロードで達成したいタスクに基づいてまとめられたレシピを見つけることもできます。例えば、Amazon RDS アプリケーションをプロアクティブに監視したい場合は、タスクセクションのアラートのサブセクションにあるレシピを参照できます。 ベストプラクティスガイドへの寄稿 このベストプラクティスガイドは推奨事項を提供するだけでなく、経験、提案、およびアプリケーションの強化を共有するための場を、コミュニティに提供することも目指しています。そのため、ガイドのコンテンツへの寄稿、またはコミュニティからの提案を求めたい場合は、ガイドの ディスカッション セクションをご利用ください。 まとめ ベストプラクティスガイド は、監視とオブザーバビリティの実践を最適化したいユーザーにとって貴重なリソースです。 このガイドは包括的なガイダンスを提供することで、皆様が賢明な意思決定を下し、一般的な落とし穴を回避し、ワークロードのオブザーバビリティの全ての可能性を引き出すことを可能にします。 AWS は、このガイドを通じてモニタリングと監視の優れた文化を育み、AWS ユーザーが、投資した価値を最大限に引き出せることを願っています。また、ガイドへの貢献により、皆さまは集合知の共有と継続的な改善プロセスに積極的に参加できます。ぜひ、一緒に強力で、スケーラブルで、効率的な AWS デプロイメントを構築し、優れたパフォーマンスと信頼性を実現しましょう。 AWS オブザーバビリティのための追加リソースが必要な場合は、 One Observability Workshop を試して、AWS オブザーバビリティの経験を得てください。また、 Terraform AWS Observability Accelerator と CDK AWS Observability Accelerator を参照すると、AWS 環境にオブザーバビリティをセットアップする方法を学べます。 著者について Deepak Jha Deepak Jha は AWS の Customer Solutions Manager で、現在はゲーム業界の顧客のクラウドジャーニー加速に注力しており、AWS の Cloud Operations Technical Field Community メンバーを目指しています。彼はテクノロジーを使って顧客のビジネス上の問題を解決することに 23 年以上、情熱を注いでいます。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 実は、AWSジャパンでは様々なセミナーを頻繁に開催していることはご存じでしょうか？どんなセミナーやイベントが予定されているかを知りたい方は イベントスケジュール のWebページをチェックしてみてください。 直近では「 IBM Db2の資産をAWSで活用する 」「 生成AIの新展開-マルチモーダル生成AIの活用方法 」「 VMware仮想化基盤、次の一手はどうする？ 」といったソリューションカットのイベントが予定されていますし、業界特化のセミナーとしては「 テレコム業界向け：Mobile World Congress(MWC) 2024 Recap 」といったものもあります。もし興味のあるテーマに関するイベントが見当たらなければ、ぜひ私たちにフィードバックをお願いします。 それでは、3 月 25 日週のアップデートを振り返ってみましょう。 2024 年 3 月 25 日週の主要なアップデート 3/25(月) AL2023.4とEKS Optimized AMIをリリース Amazon Linuxでは四半期毎にアップデートが提供されます。今回、新たにAL2023.4がリリースされました( リリースノートはこちら )。また、AL2023ベースのEKSに最適化されたAMIもご利用いただけるようになっています。 新規インスタンスでIMDSv2をデフォルトで利用する設定が可能に 新たに起動したAmazon EC2インスタンスで、メタデータアクセスへの防御を強化することができるIMDSv2(Instance Metadata Service Version 2)をデフォルトで利用するように設定可能になりました。同時にIMDSv1が無効な状況で、IMDSv1呼び出しが行われ拒否された回数を示すCloudWatchメトリクスが利用できるようになり、IMDSv1を利用するアプリケーション等が存在しないことを確認するために活用できます。 3/26(火) Knowledge Bases for Amazon BedrockがClaude 3 Sonnetに対応 基盤モデルを社内のデータソースと接続して、正確な応答を可能にする拡張検索生成(RAG)を実現するひとつの仕組みがKnowledge Bases for Amazon Bedrockです。今回、この用途にAnthropicのClaude 3 Sonnetをご利用いただけるようになりました。現時点で、バージニアとオレゴンのリージョンでご利用可能です。 Amazon Aurora PostgreSQL Optimized Reads向けのリザーブドインスタンスを発表 PostgreSQL互換のAmazon Auroraで、Amazon Aurora Optimized Readsのリザーブドインスタンスをご利用いただけるようになりました。これはDBインスタンスのメモリ容量を超える大規模なデータセットを扱うアプリケーションについて、クエリレイテンシを最大8倍改善する仕組みです。リザーブドインスタンスをご利用頂くと1年間の利用期間で最大27%の割引、3年間の利用期間であれば最大47%の割引が適用されます。 3/27(水) Amazon DataZoneのAI recommendations機能が一般利用開始に Amazon DataZoneはデータをカタログ化し組織内で活用することを容易にするサービスです。今回、AI recommendation機能が一般利用開始になりました。生成AIの技術により、データ作成者がデータに対する説明を生成するため、データ利用者がその活用を開始する際のヒントを提供することが可能です。 Amazon ElastiCache Serverlessでスケーリング設定がより柔軟に Amazon ElastiCache Serverlessでデータストレージとリクエストレートについて、最小限の値を設定可能になりました。あらかじめトラフィックの増大が予見されるケースへの対応として、事前に必要なリソースを確保できます。 AWS Systems ManagerがRed Hat Enterprise Linux 8.9と9.3をサポート AWS Systems ManagerがRed Hat Enterprise Linux(RHEL) 8.9/9.3をサポートしました。AWS Systems Managerはパッチ管理やインベントリ管理などをはじめとする管理機能を提供しますが、RHEL 8.9/9.3でも全ての機能をご利用頂くことが可能になりました。 3/28(木) Knowledge Bases for Amazon Bedrockがメタデータのフィルタリングに対応 Amazon BedrockのKnowledge Basesで、メタデータのフィルタリングが可能になり、検索精度の向上に活用できるようになりました。拡張検索生成(RAG)では大量のドキュメントに対する検索を行いますが、多くのユースケースでは「こういう属性のドキュメントを検索する」といった作業が必要になります。メタデータフィルタイングを利用すると、クエリの対象として含めるドキュメントや除外するドキュメントを指定できるようになり、より関連性の高い応答を実現できます。 3/29(金) Amazon GuardDuty EC2 Runtime Monitoringが一般利用開始に Amazon EC2インスタンスにおけるOSレベルのアクティビティを可視化し、検出された脅威に対するコンテナレベルのコンテキスト情報を提供する機能がGuardDuty EC2 Runtime Monitoringです。悪意のあるファイルのダウンロードや、それを実行しようとするコマンドを可視化し、脅威を素早く検知することが可能です。 Knowledge Bases for Amazon Bedrockがプロンプトと取得されるパッセージ数をカスタマイズ可能に 拡張検索生成(RAG)を容易に実現できるKnowledge Bases for Amazon Bedrockがカスタムプロンプトに対応しました。また、取得されるパッセージ数をカスタマイズすることで基盤モデルに追加情報を渡すせるようになり、精度向上のために活用することが可能です。 AWS Amplify Hostingが大阪リージョンで一般利用開始に フロントエンドの開発者が、AWS上に素早くフルスタックのアプリケーションを開発できるようにするAWS Amplify Hostingが、大阪リージョンでもご利用いただけるようになりました。 AWS CodeConnections(旧AWS CodeStar Connections)を発表 GitHub, GitLab, BitbucketなどのサードパーティのGitベースのリポジトリとAWSのサービスを統合し、リポジトリのイベントに関する通知を受け取りビルドすべきソースコードをダウンロード・テスト・デプロイするためのサービスがAWS CodeConnectionsです。旧来はAWS CodeStar Connectionsという名称でしたが、今回のアップデートで名称が変更になりました。 AWS Wickrが東京とシンガポールのリージョンに対応 セキュリティを最優先に位置づけたメッセージング・コラボレーションのサービスがAWS Wickrです。今回、AWS Wickrが東京・シンガポールのリージョンに対応しました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

2024 年 2 月 29 日に開催したウェビナーでは、AWS のメディア＆エンターテインメント（M&E）業界におけるクラウド取り組みと、コンテンツの「Create」「Deliver」「Monetize」の 3 つの視点から業界のビジネス変革に焦点を当て、初心者から中級者まで、幅広い参加者を対象に、業界の最先端技術とAWSの最新ソリューションを紹介しました。セミナーの録画映像と資料を本 Blog で公開いたします。 セミナーのアジェンダ: AWSメディア & エンターテインメント (M&E) 業界の最新トレンドと挑戦 コンテンツ制作を支える AWS クラウド技術とその活用 コンテンツ配信・デリバリーを支える AWS クラウド技術とその活用 コンテンツ収益化を支える AWS クラウド技術とその活用 AWSメディア & エンターテインメント (M&E) 業界の最新トレンドと挑戦 アマゾン ウェブ サービス ジャパン合同会社 インダストリー事業開発マネージャー 山口 賢人 [ 資料 ] コンテンツの「Create」「Deliver」「Monetize」の 3 つの視点から、AWS のメディア＆エンターテインメント（M&E）業界におけるクラウド取り組みと、業界のビジネス変革を行われている国内外のお客様の取り組みを紹介しました。 コンテンツ制作を支える AWS クラウド技術とその活用 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 小南 英司 [ 資料 ] 高品質なコンテンツをこれまで以上に速いサイクルで送り届けるために、コンテンツ制作やその保管にクラウドを活用する事例が増えています。AWS を用いることで可能となる急な需要への対応、リモート制作、AI/ML の活用による省力化などについて、よくあるシステム構成例を交えながらご紹介しました。 コンテンツ配信・デリバリーを支える AWS クラウド技術とその活用 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 金目 健二 [ 資料 ] 昨今、映像や記事などのコンテンツをインターネットを通じてユーザーが消費する事は一般的になりました。そのため、コンテンツ配信をするためのプラットフォームには大量のトラフィックに対応できる事に加え、多様な配信・放送に対応するための柔軟で効率的なアーキテクチャが求められます。このセッションでは、「Deliver」の視点で AWS の代表的なサービスと、お客様の事例を効果的なアーキテクチャパターンを交えてご説明しました。 コンテンツ収益化を支える AWS クラウド技術とその活用 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 前川 泰毅 [ 資料 ] プラットフォームが多様化する中、メディア企業はマネタイズ方法の変革が求められています。複数の媒体を横断した戦略を策定することでユーザー体験と利益を最大化することが可能です。このセッションでは、「Monetize」の視点でこれからのメディア企業において重要となる顧客基点のカスタマー 360 データ戦略や広告配信戦略の具体的な事例とソリューションについて解説しました。 おわりに 本ブログでは、2024 年 2 月 29 日に開催されたメディアセミナーについて紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 —- 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 山口が担当いたしました。

オープンで、仮想化された、インテリジェントな 5G の推進における重要なステップにおいて、オープン無線アクセスネットワーク (O-RAN) の普及が挙げられます。O-RAN は、無線アクセスネットワーク (RAN) の柔軟性と導入速度の向上を目指し、同時にクラウドアーキテクチャの採用による資本コスト及び運用コストの削減を目指しています。 O-RAN は、RANを O-RU (O-RAN Radio Unit) 、 O-DU (O-RAN Distributed Unit) 、 O-CU (O-RAN Central Unit) 、 RIC (RAN Intelligent Controller) などの複数のコンポーネントに分解することでこれを実現します。 これらのコンポーネントは、必要に応じてプログラム可能な Acceleration Abstraction Layer (AAL) を追加して、汎用サーバー上でコンテナ化されたソフトウェアとして実行できます。コンテナ化された RAN ネットワーク機能のホスティングを可能にする、基盤となるクラウドコンピューティング層は、O-RAN 標準では O-Cloud とも呼ばれます。 このアーキテクチャは、下の 図1 に示すように、3つのオープンレイヤとして表せます。汎用ハードウェアサーバーは、コンテナ化された RAN 機能を実行するためのコンテナランタイムをホストします。最も一般的に使用されているコンテナランタイムは Kubernetes で、このブログでも使用しています。分かり易くするために、O-CU と O-DU のソフトウェアアプリケーションのみを紹介します。 図1. O-RAN 拠点のレイヤ O-RAN テクノロジーは本質的に分解された構成 (disaggregation) となっており、通信サービスプロバイダが各レイヤに複数のサプライヤを持つことを可能とします。一方でその為、様々なタイプのハードウェア及びソフトウェアの監視とオブザーバビリティ (可観測性) に課題が生じ得ます。通常、全てのベンダが独自の要素管理システム (EMS: Element Management System) を提供しますが、異なるシステムを使用して発生した問題を相互に関連付けるのは不便です。 このブログでは、 Amazon Managed Grafana を Prometheus や OpenTelemetry などの一般的に使用されているオブザーバビリティソリューションと併用して、O-RAN 拠点の 3 つのレイヤ (サーバー、Kubernetes クラスタ、O-RAN アプリケーション) 全てをサプライヤ間で一律に監視する方法について説明します。このオブザーバビリティを AWS リージョン に集約することで、通信サービスプロバイダはクラウドの信頼性と運用のし易さを享受できます。これにより、通信サービスプロバイダは O-RAN が提供できるよう設計された柔軟性に方向転換できるようになります。 ここでは Prometheus サーバーの例として Amazon Managed Service for Prometheus 、OpenTelemetry コレクターの例として AWS Distro for OpenTelemetry (ADOT) 、汎用 (COTS) サーバーで使用可能な Kubernetes ランタイムの例として Amazon EKS Anywhere を使用しています。 ただし、このブログのほとんどの概念は、選択したハードウェアと Kubernetes ディストリビューションに適用できます。AWS で O-RAN を構築する方法に関する一般的なガイダンスについては、この ホワイトペーパー を参照ください。 エッジサーバー可用性の監視 サーバー層については、重要な監視の例と、サーバーが到達可能/利用可能かどうかを示します。サーバーの可用性について示した手法は、詳細なサーバーオブザーバビリティにも使用できます。 オプション 1: Redfish REST API を使用してサーバー状態を監視する Redfish は、ユーザーがスタンドアロンサーバーなど様々なデバイスや環境を管理できるようにする、使いやすく実装が簡単な RESTful インターフェイスを定義するベンダ間の業界標準です。多くの場合、Baseboard Management Controller (BMC) は Redfish プロトコル、リソース、および機能を実装して、システムのリモート管理機能を提供します。O-RAN エッジの主要なサーバーサプライヤのほとんどは、Redfish 標準をサポートしています。 HPE サーバーは Redfish 対応の iLO インターフェースを使用します 。 同様に Dell の iDRAC と Supermicro も Redfish のサポートを提供しています。サーバーサプライヤの Redfish 準拠については、 こちら で確認できます。 特定のサーバーで Redfish が有効になっている (または追加のソフトウェアやライセンスを使用して Redfish を有効にできる) 限り、次の図に示すように、Redfish REST 仕様を使用して監視が行えます。 図2. Redfish API を使用したサーバー監視 Redfish 対応サーバーは、 /redfish/v1/EventService/Subscriptions でイベントサブスクリプションサービスを定義します。ここで、監視サービスなどのクライアントは次の情報を使用してサブスクライブできます。 イベント受信側クライアントがイベント送信を予期するリスナー URI。Redfish サービス内でイベントがトリガされると、そのサービスはリスナー URI にイベントを送信する 送信するイベントのタイプ 詳細については、 Redfish 仕様 の「Eventing」章を参照してください。 例を使用して、Redfish 対応の iLO インターフェースを備えた HPE サーバーを監視してみましょう。 1. Amazon API Gateway のこの  ドキュメント に記載されている手順を使用して、API Gateway でリスナー REST API を作成します。 2. 次のようにサーバーの Redfish サービスで必要なイベントをサブスクライブします。 POST /redfish/v1/EventService/Subscriptions/ Request Body: { "Destination": "https://{restapi-id}.execute-api.{region}.amazonaws.com/{stage}", "Context": "Some context", "RegistryPrefixes": [ "StorageDevice", "NetworkDevice", "iLOEvents", "ResourceEvent" ], "HttpHeaders": { "Content-Type": "Application/JSON", "Odata-Version": "4.0" }, } ここで Destination はステップ 1 で作成したリスナー API。 Context には、拠点の詳細など、提供したい任意の静的情報を使用できます。 RegistryPrefix は、サブスクライブしているサーバーイベントのリストです。 HttpHeaders は、イベント POST 操作に必要な任意の HTTP ヘッダーです。 3. サブスクライブしているイベント (この例では ILOEvent ‘ServerPoweredOff’) が発生すると、Refish は次のような POST イベントをリスナー API に送信します。 { "EventID": "myEventId", "EventTimestamp": "2023-02-13T14:49:20Z", "Severity": "Critical", "Message": "This is a test event message", "MessageId": "iLOEvents.2.1.ServerPoweredOff", "MessageArgs": [ "NoAMS", "Busy", "Cached" ], "OriginOfCondition": "/redfish/v1/Systems/1/" } 4. リスナー API の POST バックエンド を AWS Lambda の Python 関数 として設定し、サーバーイベントを処理して Amazon Timestream に書き込みます。 5. Amazon Managed Grafana のデータソースとして Amazon Timestream を追加します。 6. Amazon Timestream データを使用してアラートを作成する ように Amazon Managed Grafana を設定します。 オプション2: Prometheusの「up」メトリクスを使用してサーバー状態を監視する 監視対象のサーバーが Kubernetes クラスタの一部である場合は、 Prometheus を使用して監視できます。Prometheus は各 インスタンス のスクレイピングに対して、次のように稼働時系列 (up time series) の サンプル を保存します。 up {job=」<job-name>「, instance=」<instance-id>「}: 1 インスタンスが正常でアクセス可能な場合は 1、スクレイプが失敗した場合は 0。 次の図に示すように、 up  メトリクスはサーバーの健全性監視に使用できます。 図3.　Node Exporter 「up」メトリクスを使用したサーバー監視 1. Node Exporter などのノードを監視できるユーティリティを Kubernetes クラスタ内のデーモンセットとしてインストールします。例として、Node Exporterは、全てのノードの up メトリクスを次の形式で収集します。 up{instance="192.168.1.50:9100",job="node-exporter",nodename="hostname-121"} 2. OpenTelemetry コレクターの「 Prometheus Receiver 」コンポーネントを使用して、Node Exporter のメトリクスをスクレイピングします。以下の ADOT のサンプル構成を使用して、Node Exporter からスクレイピングが可能です。 ADOT コレクターは EKS Anywhere の キューレーションパッケージ として提供されている点を留意下さい。キューレーションパッケージは EKS Anywhere をコンテナランタイムとしてより便利にするソフトウェアのパッケージです。 receivers: prometheus: config: global: scrape_interval: 30s scrape_timeout: 10s scrape_configs: - job_name: 'node-exporter' kubernetes_sd_configs: - role: endpoints ec2_sd_configs: relabel_configs: - source_labels: [ __address__ ] action: keep regex: '.*:9100$' - action: replace source_labels: [__meta_kubernetes_endpoint_node_name] target_label: nodename 3. OpenTelemetry コレクター の「 Prometheus Remote Write Exporter 」コンポーネントを使用して、Prometheus リモート書き込み対応のバックエンド (Amazon Managed Service for Prometheus など) にメトリクスを送信します。 exporters: prometheusremotewrite: endpoint: {{ prometheusRemoteWriteUrl }} 4. Prometheus バックエンドに アラートルール を作成します。 { "alert": "NodeTargetMissing", "expr": "up{instance=~\".*9100.*\", job=\"node-exporter\", nodename!=\"\"} == 0", "labels": { "severity": "critical" }, "annotations": { "summary": "Node target with name {{ $labels.nodename }} is missing", "description": "A Node target has disappeared.\n LABELS = {{ $labels }} for more then 30 seconds" } } 5. この ドキュメント で説明されているように、Amazon Managed Service for Prometheus (または任意の Prometheus) をデータソースとして使用するように Amazon Managed Grafana を設定します。 6. この ドキュメント の手順に従って Amazon Managed Grafana のアラートを視覚化し、Prometheus アラートマネージャーをデータソースとして使用します。 Kubernetes コンテナランタイムの監視 オプション 2 と同様の設定を使用して、 kube-state-metrics 、 Node Exporter 、 Container Advisor などのユーティリティをクラスタにインストールします。 これらのユーティリティはクラスタを監視し、アラートや有益なダッシュボードの作成に使用できるメトリクスを生成します。 オプション 2 のステップ 2 ～ 6 に従って、メトリクスをスクレイピングし、アラートを作成し、Amazon Managed Grafana でアラートを視覚化します。Amazon EKS Anywhere のサンプルアラートルールについては、 この GitHub の投稿 を参照してください。 Kubernetes メトリクスが Amazon Managed Grafana で利用できるようになると、広大なマーケットプレイス上で、 Amazon Managed Grafana にインポート できる 事前設定された Grafana Kubernetes ダッシュボード にアクセスできるようになります。 O-RAN アプリケーションの監視 vDU、vCU、AAL などの O-RAN アプリケーションは、Kubernetes コンテナランタイム上でマイクロサービスとして実行され、メトリクスを生成してエクスポートできる必要があります。この機能を作成するかどうかはアプリケーションベンダ次第です。ここでは、下図が示すように、一般的に使用される次の 2 つの方法のいずれかを使用してアプリケーション監視が可能です。 図4. メトリクスを使用した O-RAN アプリケーション監視 オプション 1: O-RAN アプリケーションが Prometheus でスクレイピングできるメトリクスを公開する Prometheus は、装備されたアプリケーションからメトリクスを「スクレイピング」することによって機能します。O-RAN アプリケーションは Prometheus 準拠のメトリクスを生成し、HTTP 経由で利用できるようにすることが可能です。 この機能を提供するかどうかは、O-RAN アプリケーションベンダ次第です。 OpenTelemetry コレクターの「 Prometheus Receiver 」コンポーネントを使用して、O-RAN アプリケーションから公開されているメトリクスをスクレイピングし、次の例のように Prometheus バックエンドにエクスポートします。それから、前の Kubernetes コンテナランタイム章で説明したように、O-RAN アプリケーションメトリクスを Amazon Managed Grafana で視覚化できます。 receivers: prometheus: config: global: scrape_interval: 30s scrape_configs: - job_name: oran_app_metrics static_configs: - targets: ["1.2.3.4:9091"] exporters: prometheusremotewrite: endpoint: {{ prometheusRemoteWriteUrl }} ここで、 1.2.3.4:9091 は、O-RANアプリケーション上のメトリクスサーバーのIPアドレスとポート番号です。 オプション 2: O-RAN アプリケーションが OpenTelemetry プロトコルを使用してメトリクスを転送する O-RANアプリケーションは、 例 で挙げられているように、 OpenTelemetry Protocol （OTLP）を使用して Prometheus 準拠のメトリクスを OpenTelemetry コレクター（ADOT コレクターなど）に送信することもできます。この機能を提供するかどうかは、アプリケーションベンダ次第です。 OpenTelemetry コレクター の「 OTLP Receiver 」コンポーネントを使用してメトリクスを受信し、次の例のように Prometheus バックエンドにエクスポートします。それから、前の Kubernetes コンテナランタイム章で説明したように、O-RAN アプリケーションメトリクスを Amazon Managed Grafana で視覚化できます。 receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 exporters: prometheusremotewrite: endpoint: {{ prometheusRemoteWriteUrl }} 結論 このブログでは、Amazon Managed Grafana を使用して O-RAN エッジ拠点 (O-Cloud) のすべてのレイヤを監視する複数の方法を学びました。これにより、ハードウェア/ソフトウェアのサプライヤに関係なく、地理的に分散した O-RAN 拠点のオブザーバビリティが一元化され、ひいては O-RAN ビジョンの達成に役立ちます。 AWS リージョンにオブザーバビリティ機能を持たせることで、AWS のマネージドサービスに付属する組み込みの耐障害性が得られます。さらに、補足的な AWS での 人工知能/機械学習 (AI/ML) と データ分析 サービスを使用して、メトリクスを処理することもできます (例えば、 メトリクスをインサイトに変換する など)。その過程で、Amazon EKS Anywhere や ADOT など、O-RAN の導入に役立つ他の AWS サービスについても学びました。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) 著者 Prateek Shahane Prateek Shahane は、Amazon Web Services (AWS) のシニアインダストリースペシャリストで、5G および通信デジタルテクノロジーを専門としています。AWS プロフェッショナルサービスの一員として、テレコムのお客様向けに革新的なクラウドソリューションと自動化フレームワークの設計と提供を主導しています。 また、ネットワークプログラマビリティやテレコムの IT 近代化にも取り組んでいます。Prateek は 20 年以上にわたり、グローバル規模の通信サービスプロバイダと緊密に協業しています。 Luis Lopez Luis Lopezは、Amazon Web Services (AWS) のプロフェッショナルサービス (テレコム) のシニアクラウドアーキテクトで、スペインを拠点としています。Luis はクラウドインフラストラクチャとネットワーキングを専門とし、テクノロジーに情熱を注いでおり、お客様が AWS で可能な技術を導入するためのソリューションを構築するのを支援しています。仕事以外では、家族や友人と過ごす時間を楽しんでいます。 Rajneesh Tyagi Rajneesh Tyagi は、Amazon Web Services (AWS) のリードコンサルタントです。Rajneesh は高度なテクノロジーのオーケストレーション、自動化、コンテナ化、クラウドネイティブアーキテクチャ、CI/CD を専門としています。プラットフォームエンジニアリングのバックグラウンドを持つ Rajneesh は、特にテレコムと銀行の業界において、回復力がありスケーラブルな DevOps プラクティスの実装に注力しています。仕事以外でも、DevOps 環境の最新動向を探求することに熱心に取り組んでいます。

By Zach Elliott, Sr. Specialist Solutions Architect – AWS By Erwin Soekianto, Developer Evangelist – HERE Technologies HERE Technologies 輸送と物流のダイナミックな世界において、大型車両の安全かつ効率的な走行を確保することは、大きな課題を提示します。 橋の高さ、通行制限、トラック固有の規制への準拠は、運輸ロジスティクス企業が日々直面する障害のほんの一部です。これらの複雑さを乗り越えることは遅延、コスト上昇、潜在的な安全リスクを招く可能性があります。 以前の AWS ブログの記事 で、 Amazon Location Service と HERE Technologies を使用した効率的なトラックルーティングについて説明しました。この新しい記事では、Amazon Location Service でリアルタイムのルートをより視覚的に表示するのに役立つ、 HERE Explore Truck マップスタイル を探索します。 HERE Technologies は、自動車ソフトウェア、サプライチェーン、公共安全のコンピテンシーを持つ AWS スペシャライゼーションパートナー であり、 AWS Marketplace の販売者 です。HERE Technologies は、世界をリードする位置情報データとテクノロジーの企業の一つであり、プライバシーを核としたオープンでセキュアなロケーションセントリックなプラットフォームを提供しています。 Amazon Location HERE Explore Truck マップスタイル HERE Explore Truck スタイルは、詳細で中立的な世界のベースマップです。この道路マップは、 HERE Explore スタイル の上に構築されており、トラックの制限や属性 (幅、高さ、危険物を含む) をシンボルとアイコンで強調表示して、輸送や物流分野のユースケースをサポートしています。 HERE Explore Truck マップタイプは、橋の高さや走行制限など、大型車両を運転する際の課題に対応したアプリケーションの要件を満たすように特別に設計されています。橋の高さや危険物輸送制限道路などの重要な情報を提供することで、HERE Explore Truck マップは、ユーザーが大型車両での安全かつ安心な走行のために必要なすべてのデータを持っていることを確認します。 トラックの制限と属性 HERE Explore マップスタイルには、車両制限の種類を示すアイコンと、道路に沿った車両制限の範囲を示すマップ上の紫の線が含まれます。制限アイコンには次のものがあります。 一般的なトラックの制限 トレーラーの制限 危険物 水に対する危険物 危険物許可証が必要 速度制限 加えて、トラックの属性も考慮されており、マップ上でも確認できます: 高さ 幅 長さ 重量 車軸あたり重量 車軸数   図 1 – HERE Explore Truck マップの制限アイコン ローカライゼーション 国ごとの要件により、地域の規則に基づいてトラックの制限アイコンの特定の外観が求められます。複数の国で事業を展開する運輸ロジスティクス企業にとって、正確でローカライズされた情報を維持することは、効率的なフリート管理と運用可視性のために不可欠です。 マッピングシステム上にローカライズされたトラックアイコン機能を実装することで、シームレスな追跡、効果的なコミュニケーション、運用管理の強化といった多くのメリットをもたらすことができます。 HERE  Explore Truck マップ上のトラックアイコンの正確なローカライズは、輸送と物流企業がそのフリートのリアルタイム可視化と正確な追跡を可能にし、効率的な意思決定、最適化されたルーティング、効果的なリソース割り当てを可能にするために不可欠です。 例えば、日本のローカライズマップには、その国に固有のシンボル、たとえば危険物が含まれます。 図 2 – 日本向け HERE Explore Truck マップのローカライゼーション 米国では、身長、車軸数、幅などの属性は異なるシンボルで表されます。HERE Explore マップスタイルは、これらの属性を現地の表記にローカライズします。 図 3 – 米国向け HERE Explore Truck マップのローカライゼーション Amazon Location Service 上の HERE Explore トラックマップの表示 Amazon Location Service を使用して HERE Explore Truck マップを見る最も簡単な方法は、 location.aws.com/demo にあるデモサイトを訪問することです。右上の Data Selector Menu から、 Explore Truck スタイルを選択します。 図 4 – Amazon Location Service のマップスタイル選択 デモアプリで特定の場所を検索すると、存在するトラックの制限を確認できます。 例えば、ニューヨーク市では複数の制限されたルートや高架道路やトンネルによる高さの制限を確認できます。 図 5 – Amazon Location Service のデモ Amazon Location Service を使用してジオスパシャルアプリケーションに HERE Explore Truck スタイルを含める場合は、 デベロッパーガイド にリストされているステップに従って、HERE Explore Truck スタイルを使用して マップリソース を作成してください。 まとめ HERE Explore Truck Style と Amazon Location Service は、輸送や物流のアプリケーションや運用に不可欠な、トラック固有の豊富な情報セットを提供します。 Amazon Location Service を通じて利用できる HERE の豊富なトラックルーティング機能と Explore Truck マップスタイルを組み合わせることで、運輸ロジスティクス企業は、世界中で安全で効率的かつコンプライアンスに準拠した輸送を活用できます。 . . HERE Technologies – AWS パートナー スポットライト HERE Technologies は AWS スペシャライゼーションパートナー であり、プライバシーを中核としたオープンでセキュアなロケーション中心のプラットフォームを提供する、世界をリードするロケーションデータとテクノロジー企業の 1 つです。 HERE お問い合わせ | パートナー概要 | AWS Marketplace 本記事は「 Harnessing HERE Explore Truck Map Style and Amazon Location Service for Large Vehicle Transportation 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

こんにちは。ソリューションアーキテクトの沢田です。 パイオニア株式会社 (以下、パイオニア) は、「より多くの人と、感動を」 をミッションに掲げ、モノ×コト（プロダクト ＆ ソリューションサービス）の両輪で、新しい移動体験の価値を創造しています。本ブログでは、ビジネスの意思決定のためのデータの可視化に関わる課題解決のために、AWS のデータカタログサービスである Amazon DataZone を使って組織内のデータをカタログ化し、データを共有、アクセスする方法をパイオニア Piomatix 情報サービス部 櫛引 翔太 氏よりご紹介します。また、組織のデータ間でのやりとりにおけるコミュニケーションコストを削減できるビジネスデータカタログ、ビジネス用語集についてもご紹介します。 はじめに データカタログとは何でしょうか。なぜ必要なのでしょうか。データカタログは、組織が収集して処理するすべてのデータのインベントリです。データカタログにはデータ資産のインベントリを説明し、データに含まれる内容に関する追加情報を提供するメタデータが含まれています。 ビッグデータを用いて、データ駆動型でビジネスの意思決定をすることは現在ではスタンダードとなってきていますが、これを実行するには、データがどこにあって、どのようなものなのかをすぐ把握できる状態になってないと、非効率で時間がかかってしまいます。この非効率さを日常で例えるならば、図書館でスポーツジャンルの本を読みたいと思ったときに、配置場所を検索できるコンピュータや館内の案内図がないようなものです。 ビッグデータにおいて、本を検索するコンピュータや館内の案内図の役割を果たすのがデータカタログだと考えています。つまり、データカタログによって組織内のデータが容易に把握できるようになり、データ分析やマーケティングへのデータの利用が活発となることで、迅速なビジネスの意思決定を行うことができるようになります。 パイオニアのデータカタログと現状の課題 パイオニアでもデータカタログは重要であると考えており、2022 年に社内向けのデータカタログサイトをAWS上に構築しました (開発の経緯や開発内容の詳細は こちら の記事をご参照ください)。 パイオニアでは、カーナビやドライブレコーダーといった車載機器で走行速度や自車位置など様々なプローブ情報を収集しているほか、ナビ機能に使われる全国各地の地図データを保有しています。これらは年々膨大となっており、1 つ 1 つのデータの把握はより複雑になっています。データカタログサイトはそんなパイオニアの膨大なデータの把握に貢献しており、例えばユーザーの行動分析のための活用が進んでいます。 一方で、データカタログサイトには以下のような課題もあります。 データカタログへのデータの公開に時間と労力が浪費されてしまう 一般的なビジネス用語がない データの構造やジャンル、商品の偏りといったデータの特性がわかりにくい これらの課題から、データを公開するユーザーが増加しにくいこと、データの一覧を閲覧するにも不透明な情報が多いこと、非技術者が理解できない要素が多いことで、パイオニアが保有するデータに対する「データカタログの可視化」というデータカタログの目的を果たせていませんでした。 そこで、これらの課題を解決するために着目したのが Amazon DataZone です。Amazon DataZone の利用を検討するにあたり、使ってみた感想や活用例をご紹介します。 Amazon DataZone のデータポータルへの公開 ステップ 1 : 既存の AWS Glue データベースの Amazon DataZone ポータルへの取り込み このステップでは、既存の AWS Glue データベースを Amzon DataZone に取り込みます。 Amazon DataZone では一番最初にドメインを作成します。ドメインを作成すると、データポータルというデータカタログサイトのようなものが自動で作成されます。 Amazon DataZone ではこのデータポータル上にデータをインプットすることでデータカタログを管理できるようになります。 アクセス管理はプロジェクトという単位で行われています。そのため、データを公開するためのプロジェクトを作成します。 作成したプロジェクトで、環境を作成します。 環境とは、プロジェクト内で利用する AWS リソースを定義するもので、Amazon DataZone では現在、環境をつくるための以下のブループリントが 2 種類用意されています。 DefaultDataLake ( AWS Glue データカタログでデータを管理し、 Amazon Athena でデータ利用できるもの) DefaultDataWarehouse ( Amazon Redshift でデータの公開、利用ができるもの) 今回は AWS Glue で作成したデータを公開したいので DefaultDataLake を選択し、環境を作成しました。(以下、この環境を sample_ev とします) 環境の作成後、データソース作成より、環境内に既存の AWS Glue データベースを接続します。 作成した環境 ( sample_ev ) からデータ選択より、データベース名に既存の AWS Glue のデータベース名を選択し、作成します。 (以下、このデータソースを glue_data_source とします) データソース一覧から glue_data_source を選択し、「実行」をクリックすると glue_data_source の メタデータを AWS Glue から収集してデータアセットが作成されます。(以下、 sample_dataset とします) これで既存の AWS Glue データベースを Amzon DataZone に取り込むことができました。 ステップ 2 : データアセットのキュレーションと公開 このステップでは、ステップ 1 で作成したデータアセット ( sample_dataset ) を公開する準備をし、データポータルに公開します。 データアセットの詳細を確認すると、ビジネスメタデータ、スキーマという項目があるのがわかります。スキーマはそのままでデータアセットのカラムに関する名前、型といった情報が確認できます。ビジネスメタデータは、名の通りビジネス目的で閲覧するユーザー向けにデータの概要や README を記載する部分になります。 これにより、パイオニアで抱えていた「一般的なビジネス用語がない」という課題を解決できます。これをマニュアルですべて整備するとなると、データアセットの数だけ説明文を書かないといけなくなりとても大変です。Amazon DataZone はそんな悩みを解決してくれます。データアセット作成時に自動でビジネスメタデータの概要、スキーマの名前、説明文を 生成 AI の機能によって自動で生成 してくれます ! ( ブログ執筆中はプレビューでしたが、 2024 年 3月 27日 に GA されました ) 生成された概要文や説明文に問題がなければ、「承認」をクリックするだけで適用されます。 編集したい場合は、生成された説明文を書き換えることも可能です。この機能を体験したときは思わず声がでるほど感動しました。生成された文章は精度が高く、手直しもさほど必要ありません。 データアセットを公開するまでの準備ができました。あとは「アセットを公開」をクリックするだけで、データポータルに公開することができます。 とても簡単な手順で、既存の AWS Glue のデータアセットをデータポータルに公開することができました。特に操作に迷うことなく、数分で作業を完了することができました。 データポータルで公開されたデータアセットを閲覧 / 分析 データアセットの閲覧 データポータルでは「カタログ」からいつでも公開されたデータアセットを確認することができます。また、ビジネス用語集も確認することができます。 ビジネス用語集は、データを発見して分析する際に組織全体で同じ定義が使用されるように、ビジネス用語とその定義を一覧表示する組織の辞書のようなものです。 また、ビジネス用語はデータアセットと関連付けることが可能です。製品に関連するもののデータや、データのジャンルなどを関連づけることで一目でデータのジャンルやどの製品から収集されたものかわかるようにできます。 参考に今回生成されたデータアセットの概要文とスキーマを日本語に翻訳し、関連するデータジャンルや製品をビジネス用語集で関連付けしてみました。 これらにより、カタログの利用者はこのビジネス用語集に加え、前章のステップ 2 で紹介したビジネスメタデータ、スキーマを参照することで、非技術者であっても、データ構造や社内の製品データの偏りなどといったデータの特性も理解しやすくなっています。 分析 データを分析するためには、プロジェクトが必要となります。予めステップ 1 と同じ手順でプロジェクトと環境を作成します。 プロジェクト内でカタログからデータアセットを選択し、「サブスクライブ」からデータアセットの公開しているプロジェクトについて利用したいというリクエストを送ることができます。 データアセットを公開したプロジェクトにはサブスクリプションのリクエストがあったことが通知され、リクエストしたプロジェクトや、アクセスする理由などを確認することができます。ここでリクエストに対し、承認するかどうかを判断します。 承認後、「Analytics tools」より Amazon Athena を使用し、データベースにサブスクション用の DB を選択すると、承認されたデータアセットが表示され、クエリを実行できるようになります。 このように見やすい UI で構成されたカタログからビジネス面、分析面どちらのユーザーにとってもデータが理解しやすく、簡単な操作でクエリの実行まで行うことができます。 結論と今後の展望 Amazon DataZone によって、簡単に既存の AWS Glue データカタログのデータを公開することができ、公開されたデータはビジネス目的、データ分析目的どちらのユーザーにも理解しやすいように自動でデータの説明文などを生成してくれることがわかりました。以前に構築したデータカタログサイトで抱えていた 3 つの課題を Amazon DataZone を利用することで簡単に解消することが可能になりました。 使ってみた感想としては、データポータルという UI が非常に見やすく、操作もしやすいと感じました。また、データアセットのビジネスメタデータやスキーマが自動で生成されたことに感動しました。データカタログはデータ公開者に作業負担を強いてしまうことも課題の 1 つだったので、このような細かい作業を自動で行ってくれることは時間と労力の浪費を大きく減らしてくれるのに貢献してくれました。 一方で、以下のような機能が追加されるとより多くのユースケースに活用できると感じました。 公開されたデータアセットをサブスクライブして分析できるサービスとして Amazon EMR や Amazon SageMaker といった 他の分析サービスとの連携 プロジェクトのメンバーの権限として用意されているロールにサブスクライブの承認のみができる権限、分析だけができる権限など権限の細分化 (2024 年 3 月現在、付与できるのは Owner と Contributor のみで、Contributor の権限が強すぎると感じました ) データポータル内の通知を E メールなどでユーザーに知らせる機能 ( Amazon EventBridge と Amazon SNS を利用して実現できる が、データポータルの UI から設定できた方が AWS に詳しくないユーザーには優しい) Amazon DataZone は昨年の 10 月に GA されたばかりのサービスで、これからも多くのアップデートが用意されていると思います。AWS サービスを利用するメリットは、運用と保守が簡単になることに加え、サービスのアップデートを以後受けられることにあると思ってます。現在の Amazon DataZone をさらに活用し、組織内のデータ活用を進めながら期待して待ってみたいと思っています。 参考リンク Amazon DataZone Getting started Amazon DataZone ハンズオン(ベーシック)

コンタクトセンターでは、既存の顧客の電話番号を使用して他人になりすますような、不正な電話を受けることがあります。Web サイトであれば適切な資格情報のチェックに失敗するだけかもしれません。しかし、コンタクトセンターのエージェントは何かがおかしいと思っても、礼儀正しく対応するようにトレーニングされており、特に自動番号識別 (ANI) を使用して顧客を特定・顧客データを提供している場合、ソーシャルエンジニアリングの対象になる可能性があります。顧客に被害をもたらすだけでなく、エージェントの手を煩わせ、通話の待ち時間が長くなり、潜在的な収益が失われる可能性もあります。 このブログ記事では、 Amazon Connect やその他の AWS サービスによって、そのようなスパム通話を特定し、阻止するワークフローを紹介します。このソリューションは、ランダムに生成された番号を発信者に入力させ、自動的に発信されるスパム通話を防ぎます。 ソリューション概要 このソリューションは以下のような流れで動作します。 発信者がカスタマーサービスに電話します 通話は電話網 (PSTN) を通じて Amazon Connect の IVR に到達します Amazon Connect の IVR は AWS Lambda 関数を呼び出し、Lambda 関数が 4 桁のランダムな番号を発行します Amazon Connect はランダムな番号を発信者に再生し、電話のキーパッドでこの番号を入力するように要求します 番号の入力が正しい場合、 Amazon Connect のフローはコンタクトセンターの業務に合わせて継続、もし番号の入力が誤っている場合、通話は終了されます 上記のフローを以下の通り図示します。 ソリューションのデプロイ このサンプルのほとんどは、 AWS CloudFormation テンプレートを使用してアカウントにデプロイできます。CloudFormation テンプレートは、 IAM ロール・ポリシー、サンプル問い合わせフロー、および Lambda 関数で構成される新しいスタックを作成します。残りの設定は Amazon Connect と Amazon Connect コンソールで行います。 大まかな設定手順は以下の通りです。 このソリューション向けリソースのパッケージをダウンロード CloudFormation テンプレートのデプロイ サンプルコンタクトフローに電話番号を設定 テスト通話を行い検証 前提条件 この手順を実行する前提条件は以下の通りです。 作成済みの AWS アカウント 作成済みの Amazon Connect インスタンス AWS CloudFormation 、 Amazon Connect 、 AWS Lambda に関する基本的な理解 ステップバイステップの手順 手順の実施には一般的な Amazon Connect と AWS CloudFormation の操作に関する知識が必要です。一般的な管理操作方法の詳細については以下の資料を参考にしてください。 Amazon Connect 管理者ガイド AWS CloudFormation ユーザーガイド CloudFormation テンプレートのデプロイ AWS マネジメントコンソール に ログイン し、AWS CloudFormation コンソールを 開きます ドロップダウンメニューの スタックの作成 を選択し、 新しいリソースを使用 (標準) を選択します。CloudFormation コンソールのリージョンが Amazon Connect インスタンスのリージョンと同一か注意してください。リージョンの選択については、ドキュメントの「 リージョンを選択する 」や「 Amazon Connect の使用を開始する 」を確認してください CloudFormation の設定で利用する Amazon Connect インスタンスの ARN を取得します 前提条件 – テンプレートの準備 から、 テンプレートの準備完了 を選択します テンプレートの指定で、Amazon S3 URLを選択し、 このURL を入力し、次へをクリックします 訳注: 上記 URL はテンプレート (YAML ファイル ) の URL です。リンク先のアドレスをコピーして利用してください。 テンプレートに任意の名前を設定し、手順 3 で取得した Amazon Connect インスタンスの ARN をパラメータに設定します。「次へ」をクリックし、「スタックの失敗オプション」はデフォルトのままで設定を確認したら「次へ」をクリックします 設定内容を確認し、ページの下部の「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」にチェックを入れます 「送信」をクリックします。CloudFormation テンプレートが呼び出され、必要なリソースが作成されます。作成には数分の時間が必要です スタックが作成されると、ステータスが CREATE_COMPLETE になります 電話番号をサンプルコンタクトフローにアタッチ コンタクトセンターのアクセス URL からログインします 電話番号を取得します CloudFormation テンプレートが「<テンプレート名>-FLOWDETERSPAMS」という名前のコンタクトフローを作成しています ステップ 2 で取得した番号を このコンタクトフローにアタッチします 電話番号を書き留めておきます。機能を検証するため、この番号を後ほど使います ソリューションの検証 スパムではない通話のケース: Amazon Connect で設定した番号に架電します IVR が次のようなメッセージを再生します。「Thank you for calling, please use your phone keypad to enter 7665 to continue」(お電話ありがとうございます。続けるにはキーパッドで7665を入力してください) ※訳注: 4桁の数字部分は毎回ランダムな数字が読み上げられます。 7665 を入力します 正しい番号を入力すると、 IVR が次のようなメッセージを再生します。「Thank you. In real world, this call would proceed as normal. Thank you for calling, goodbye.」(ありがとうございます。実業務の場合、この電話は通常の電話として継続します。架電ありがとうございました。) スパムの通話のケース: Amazon Connect で設定した番号に架電します 前回と同様に IVR がメッセージを再生し、4 桁の番号の入力を求めます（例: 7634 を入力してください） 誤った数字を入力します（例: 2323 など） 誤った番号を入力すると、 IVR が次のようなメッセージを再生します。「Thank you your entry did not match. In real world, this would be treated as a spam call. Thank you for calling, goodbye.」(ありがとうございます。入力された番号は一致しません。実業務の場合、この電話はスパムとして取り扱われます。架電ありがとうございました。) ユースケースへの適用 このソリューションの設定は簡単に実ユースケースに適用することができます。このコンタクトフローを認証フローとして、実業務向けのワークフローの一部として取り入れることができます。 クリーンアップ 今後の料金発生を防ぐ為、コンタクトフローから電話番号の関連付けを外し、CloudFormation テンプレートも削除します。今回の検証の為、電話番号を新規に取得された場合は番号もリリースする必要があります。CloudFromation テンプレートを削除すると、このサンプルで使用した Lambda 関数や IAM のリソース、コンタクトフローが削除されます。 結論 このブログ記事では、スパムの発信者を阻止する方法を紹介しました。さらにレポート機能を追加して、スパム通話と判定され、接続が切断された通話の数を示すこともできます。レポートの方法については、今後のブログ記事で取り上げる予定です。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

AWS Trusted Advisor は、コスト最適化、パフォーマンス、耐障害性、セキュリティ、サービスの制限、運用上の優秀性のカテゴリーのベストプラクティスチェックを使用して継続的に AWS 環境を評価し、AWS Well-Architected Framework の AWS ベストプラクティスからの逸脱を修正するアクションを推奨します。AWS Well-Architected Framework は、お客様がクラウドワークロードを効果的に設計、構築するためのアーキテクチャのベストプラクティスとガイダンスを集めたものです。 2023 年 10 月 26 日、Trusted Advisor は新しく運用上の優秀性のチェックカテゴリーを追加し、 AWS Config と統合したことで、すべてのカテゴリーで合わせて 64 の新しいベストプラクティスチェックを提供しました。このローンチにより、AWS 環境の運用準備状況が改善され、Trusted Advisor チェックの適用範囲が広がり、AWS Well-Architected Framework のベストプラクティスとの整合性を高めることができます。 本ブログ投稿では、新しい 運用上の優秀性 カテゴリーについて詳しく説明し、Trusted Advisor が運用リスクと最適化の機会の特定にどのように役立つかをサンプルシナリオを通して説明します。 AWS Well-Architected ベストプラクティスと整合した AWS Trusted Advisor ビジネスと AWS 環境が進化するにつれ、競合環境で優位に立つために必要な拡張性や継続的な変化への対応力には、適切な運用能力を確保することが重要です。このため、AWS Well-Architected Framework では、 運用上の優秀性の柱 に文書化されている運用関連のベストプラクティスに特に重点を置いています。 運用上の優秀性 の柱の重点分野の 1 つには、ワークロード環境を運用するにあたって十分な 準備 が整っているかどうかの確認に必要なベストプラクティスが含まれています。例えば、「 OPS05-BP05 パッチ管理を実行する 」では、エラーと運用のオーバーヘッドを削減するために、パッチ管理を大規模に実行できる適切な機能群を備えたクラウド環境を準備するようアドバイスしています。EC2 インスタンスの場合は、AWS Systems Manager Patch Manager や Change Manager などの自動化されたサービス機能と統合するのがベストプラクティスです。 Systems Manager の自動化機能を使用するための前提条件として、EC2 インスタンスに AWS Systems Manager エージェント パッケージがインストールされ、AWS Systems Manager サービスに正しく登録されていることを確認する必要があります。 ブログの次のセクションでは、EC2 インスタンスが Systems Manager によって管理されているかどうかを検出するために、 AWS Config データソースの Trusted Advisor チェックを使用する 方法を紹介します。 AWS Trusted Advisor による運用上の優秀性 この例では、最近導入された運用上の優秀性 チェック が、AWS Config ルールを使用して AWS 環境を調査するのにどのように役立ち、その後、ワークロードの運用効率を向上させる機会が生じた際にレコメンデーションをどのように提供するかを学びます。 以下は、Trusted Advisor と AWS Config の統合を通して、 AWS Systems Manager によって管理されていない Amazon EC2 インスタンスを特定する詳細な手順です。 AWS Config ルール名を抽出するには (コンソール) Trusted Advisor の 運用上の優秀性 タブで、[ Amazon EC2 インスタンスは AWS Systems Manager によって管理されていません ] のチェックを展開します。 ソース セクションで、AWS Config マネージドルール名 [ ec2-instance-managed-by-systems-manager ] をコピーします。 図 1 – AWS Trusted Advisor での運用上の優秀性チェックの例 対応する AWS Config マネージドルールを有効化する (コンソール) AWS コンソールで AWS Config に移動します。 AWS Config をまだ有効にしていない場合は、 開始方法のドキュメント を参照して AWS Config を有効にしてください。 AWS Config の使用量に基づいて料金が請求されることに注意してください。 詳細については、 AWS Config の料金 を参照してください。 ルール ページで、 ルールを追加 を選択します。 図 2 – AWS Config のルール追加例 AWS によって管理されるルールの追加 を選択します。 検索バーで AWS マネージドルール名 [ ec2-instance-managed-by-systems-manager ] を検索すると、関連する説明とともに対象のルールが表示されます。 [ ec2-instance-managed-by-systems-manager ] ルール名の左側のラジオボタンをクリックします。 次へ を選択します。 図 3 – [ec2-instance-managed-by-systems-manager] という名前の AWS Config マネージドルールの追加例 ルールの設定 ページで、デフォルト設定のまま 次へ を選択します。 図 4 – ルールの設定ページの AWS Config マネージドルールの詳細の例 確認と作成 ページで、AWS Config マネージドルールが必要なものであることを確認します。確認してルールを保存すると、ルールの概要ページに表示されます。 図 5 – [ec2-instance-maned-by-systems-manager] ルールが AWS Config に正常に追加される これで、この特定のチェックに対して Trusted Advisor の運用上の優秀性のレコメンデーションを生成するための前提条件が満たされました。 AWS Config ルールが評価結果を生成すると、ほぼリアルタイムで Trusted Advisor に結果が表示されます。 Systems Manager によって管理されていない EC2 インスタンスを特定する (コンソール) Trusted Advisor の 運用上の優秀性 タブで [ 調査が推奨されます ] の項目を確認します。 図 6 – Trusted Advisor の運用上の優秀性で調査が推奨される項目の例 [ Amazon EC2 インスタンスは AWS Systems Manager によって管理されていません ] のチェックを展開して、結果を確認します。 この例では、Systems Manager によって管理されていない 4 つの EC2 インスタンスが強調表示されています。 これらの EC2 インスタンスのリソース、AWS Config ルール、および入力パラメータを確認します。 図 7 – Trusted Advisor で検出されたソース、アラート基準、推奨されるアクション、その他のリソースの詳細の例 運用上の優秀性の [ AWS Systems Manager によって管理されていない Amazon EC2 インスタンス ] チェックでは、集中管理、自動化、インベントリ、パッチ管理、変更管理、OS 設定の一貫性を提供することで、Amazon EC2 インスタンスを効率的に管理する方法を説明しています。 Trusted Advisor は組織が運用のオーバーヘッドを削減して Amazon EC2 インスタンスのフリートを管理するために、運用のベストプラクティスの実装をガイドする 推奨されるアクション も提供します。 この例では、Trusted Advisor が Systems Manager の EC2 インスタンス のセットアップ 手順をガイドし、 EC2 インスタンスが Systems Manager に表示されない 場合のトラブルシューティングを行います。 このチェックは、AWS Well-Architected Framework のベストプラクティス「 OPS05-BP03 構成管理システムを使用する 」と「 OPS05-BP05 パッチ管理を実行する 」に沿ったもので、これにより、運用チームは反復可能で監査可能な構成変更を行い、労力を低減することができます。AWS Systems Manager によって EC2 インスタンスが管理されると、運用チームは Systems Manager Patch Manager と Change Manager を使用した自動パッチ管理の活用や一貫した変更管理プロセスの確立によって、運用効率を向上させることができます。 上記のシナリオと同様に、チェックに対応する AWS Config マネージドルールをデプロイすることで、他の Trusted Advisor の運用上の優秀性のチェックを有効化することもできます。 AWS Config マネージドルールが有効化されると、Trusted Advisor は AWS リソースを継続的に評価し、運用のベストプラクティスから逸脱するリソース設定がある場合にフラグを立てます。 各チェックの 推奨されるアクション に基づいて、AWS 環境の運用上の優秀性の達成に役立つ修正アクションを実行できます。 結論 運用上の優秀性は、規模を拡大し、継続的なビジネス変化のスピードに対応するために不可欠です。 このブログ投稿では、Trusted Advisor の新しい運用上の優秀性カテゴリを紹介しました。 また、AWS Config データソースからの新しいチェックも共有しました。これらのチェックは、AWS Well-Architected の運用上の優秀性のベストプラクティスに沿っており、お客様環境の運用態勢を改善できるように設計されています。 Trusted Advisor の新しい運用上の優秀性のチェックの詳細については、 Trusted Advisor チェックリファレンス をご覧ください。 著者について: Jang Whan Han Jang Whan は AWS Well-Architected GEO ソリューションアーキテクトであり、AWS クラウドにワークロードをデプロイするための AWS ベストプラクティスを実証するサンプルシナリオとハンズオンラボを構築しています。彼は特に AWS パートナーネットワーク (APN) パートナーや AWS のお客様を対象に AWS ベストプラクティスを推進することに専念してきました。 Jerry Chen Jerry Chen は現在、Amazon Web Service (AWS) のシニア AWS Well-Architected GEO ソリューションアーキテクトです。彼は AWS のお客様とパートナー向けのクラウドセキュリティと運用アーキテクチャの設計に注力してきました。 LinkedIn で Jerry をフォローできます。 翻訳はテクニカルアカウントマネージャーの河野が担当しました。原文は こちら です。