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 をフォローできます。 翻訳はテクニカルアカウントマネージャーの河野が担当しました。原文は こちら です。

このブログは 2024 年 3 月 13 日に Brad Beaulieu（Booz Allen 社）、Christopher Smith（Principal Solutions Architect）、Dru Grote（Booz Allen Hamilton 社）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2015 年の AWS Snowball デバイスの発表以来、ユーザーは Amazon Web Services（AWS）Snow Family を用いて、オンプレミスと AWS リージョン 間でペタバイトのデータを転送することに成功しています。ユーザーは、AWS Snow Family を用いてデータを移行するだけではありません。AWS Snowball Edge Compute Optimized デバイスを使用して、ネットワーク接続が拒否される、中断する、断続的になる、制限される環境（DDIL = Denied, Disrupted, Intermittent or Limited）でデータの処理が必要なアプリケーションをホストすることが増えています。エッジでのデータ処理により、より迅速にインサイトを得ることができますが、長期保存のためにユーザーはエッジで取得したデータをアーカイブしてエンタープライズデータレイクに保存することがよくあります。データを AWS に送る最も簡単な方法は、インポート ジョブ プロセスの一部として AWS Snowball デバイスを返却することです。しかし、インポートジョブはオンプレミスから AWS への 1 回限りのデータ移動ソリューションであり、返送、集荷、データ取り込みに関する時間の遅れが発生します。 インポートジョブは、事業継続計画やレガシーデータの移行に関連する大規模なオフラインデータのクラウドへのバックアップには最適です。しかし、一回のインポートジョブでは、継続的にデータを選別し転送することが必要な 機械学習（ML）モデルの再トレーニング や 企業データに対するビジネスインテリジェンスレポーティング などのユースケースが求めるニアリアルタイムのデータ転送パイプラインの要件を満たすことはできません。 2023 年の AWS Snowball Edge Compute Optimized デバイス上の Amazon Simle Storage Service (S3) 互換ストレージ と、 AWS Snowball デバイス上の Amazon S3 互換ストレージ向け AWS DataSync の提供開始により、データのライフサイクル要件を満たしながら、 エッジ を含めたあらゆる場所でデータを処理し保存することができます。 この記事では、 AWS DataSync エージェントを Amazon Elastic Compute Cloud（Amazon EC2）互換のコンピュートインスタンス として AWS Snowball Edge デバイスにロードする手順を説明します。また、AWS Snowball Edge の Amazon S3 互換ストレージバケットと AWS リージョンの Amazon S3 バケット間でオブジェクトを比較して転送するように AWS DataSync を設定します。この方法では、ネットワークが断続的な場合に組み込みのリトライとネットワーク回復メカニズムが機能します。さらに、AWS DataSync タスクはネットワーク接続が制限される場面でも最大帯域幅を指定することができます。どちらの機能も遠隔の通信環境や過酷な通信環境では必要とされるものです。 ソリューションの概要 このシナリオでは、カメラを用いて高解像度の非圧縮ビデオを AWS Snowball Edge デバイス上の Amazon S3 バケットに保存します。AWS Snowball Edge 上の Amazon EC2 互換のコンピュートインスタンス上で人工知能（AI）アプリケーションがビデオを処理して興味のある物体を特定します。分析後、生の映像はダウンサンプリングされ、人が確認できるようにアーカイブされる必要があります。 このソリューションには、以下の AWS サービスと機能が含まれています: AWS Snowball Edge Compute Optimized デバイスは、ローカルコンピューティングとストレージのみのジョブから作成します。 データ用と Amazon Machine Images (AMI) 用の 2 つのバケットを用意した AWS Snowball Edge デバイス上の Amazon S3 互換ストレージ AWS リージョンの Amazon S3 バケットへオブジェクトをレプリケートするように設定された Amazon EC2 上で稼動する AWS DataSync エージェント AWS リージョンの Amazon S3 バケット AWS DataSync 図 1. AWS Snowball Edge、Amazon S3、AWS DataSync のアーキテクチャ 前提条件 この記事に従うには、以下の前提条件が必要です: 少なくとも 1 つの AWS リージョン（この例では、us-east-1 リージョンを使用）の管理者権限を持つ AWS アカウントが必要です。 スタンドアロンの AWS アカウントを作成 します。 Amazon S3 互換のストレージがある AWS Snowball Edge、ロック解除コードとマニフェストファイルへのアクセス、インターネットへの接続環境が必要です。詳細については、「 AWS Snowball Edge の開始方法 」を参照してください。 電源とネットワークケーブル、および AWS Snowball Edge デバイスとワークステーションとインターネットを相互接続するためのネットワークデバイスなどの、AWS Snowball Edge およびワークステーションに関する追加の機材が必要です。 90 ギガバイト（GB）の空きストレージと AWS Snowball Edge へのネットワーク接続、および以下のソフトウェアがインストールされた Windows または Mac のワークステーションが必要です: AWS Command Line Interface (AWS CLI ) &gt;= 2.11.15 AWS Snowball Edge Client (SBE CLI) &gt;= 1.2.0 AWS OpsHub for Snow Family &gt;= 1.15.11 Terraform &gt;= 1.5.0 ウォークスルー AWS Snowball Edge デバイス上の Amazon S3 互換ストレージから AWS リージョンの Amazon S3 バケットにオブジェクトをレプリケートするには、以下の手順を実行します: AWS Snowball Edge デバイスで Amazon S3 互換ストレージサービスを開始 AWS Snowball Edge 上の Amazon S3 Control（バケット）と Amazon S3 API（オブジェクト）のエンドポイントと通信するように AWS CLI を設定 AWS Snowball Edge 上に、2 つの Amazon S3 互換ストレージのバケットを作成 AWS Snowball Edge デバイス上で VM Import/Export (VMIE) サービスを有効にするために、 AWS Identity and Access Management (IAM) ロールとポリシーを作成 Amazon EC2 インスタンスから AWS DataSync AMI を作成し、オンプレミス環境にエクスポート AWS Snowball Edge デバイス上に Amazon EC2 互換のコンピュートインスタンスとして AWS DataSync エージェントをインポートして起動 Infrastructure-as-Code (IaC) をデプロイしてエージェントをアクティベートし、AWS DataSync タスクとロケーションを作成して、ユーザー定義のスケジュールで AWS Snowball Edge デバイスから AWS リージョンの Amazon S3 バケットにレプリケート AWS DataSync レプリケーションタスクを検証し実行 Step 1: AWS Snowball Edge デバイスで Amazon S3 互換ストレージサービスを開始 AWS Snowball Edge デバイスの注文、受け取り、インストール、ネットワーク接続の確立が完了した後、このステップではデバイスへの接続、設定、Amazon S3 互換サービスの起動を行います。デバイス上では S3-snow サービスと表現され、以下では S3-snow として参照します。 SBE CLI を使用して S3-snow サービスのロックを解除し、起動してください。または、AWS OpsHub for Snow Family を使用して、GUI でのワークフローを使用することもできます。 AWS Snow Family Management Console からマニフェストファイルをダウンロードし、ロック解除コードをメモします。AWS Snowball Edge デバイスがお客様の施設にある間、不正アクセスを防ぐために、ロック解除コードとマニフェストファイルを別々の場所に保管することをお勧めします。 ワークステーションで SBE CLI を使用して、AWS Snowball Edge の認証情報を持つプロファイルとして “snowsbe” を設定します: snowballEdge configure --profile snowsbe マニフェストファイルへのパス、ロック解除コード、および AWS Snowball Edge のエンドポイントを https://&lt;IP ADDRESS&gt; という形式で入力するよう求められます。 次のコマンドを使用して、AWS Snowball Edge デバイスのロックを解除します: snowballEdge unlock-device --profile snowsbe 次のコマンドを実行して、デバイスのロックを解除したことを確認します: snowballEdge describe-device --profile snowsbe デバイスのロックが解除されたら、AWS Snowball Edge 上で Amazon S3 互換ストレージを設定する必要があります。このサービスには 2 つの Virtual Network Interfaces (VNI) が必要です。1 つは Amazon S3 API（オブジェクト）エンドポイント用で、もう 1 つは Amazon S3 Control（バケット）エンドポイント用です。エッジデバイスと AWS リージョン間でバケットを同期するタスクを実行するために、AWS DataSync エージェントが通信する Amazon S3 エンドポイントのホスト名またはインターネットプロトコル（IP）アドレスを指す Terraform 変数値を後で設定します。2 つの異なるエンドポイントを区別する最も簡単な方法は、バケットとオブジェクトのどちらに対してアクションを実行しているかを確認することです。Amazon S3 Control エンドポイントはバケット操作用で、Amazon S3 API エンドポイントはオブジェクト操作用です。 次のコマンドを実行して、デバイスの物理ネットワークインターフェース ID を取得します: snowballEdge describe-device --profile snowsbe AWS Snowball Edge デバイスと同じサブネット上で利用可能な IP アドレスを 2 つ特定します。次のコマンドを実行して VNI を作成し、“VirtualNetworkingInterfaceArn” の値を取得します。これを 2 回 — Amazon S3 エンドポイントごとに 1 回ずつ（各 IP アドレスは別々に入力する必要があります）実行する必要があります: snowballEdge create-virtual-network-interface --ip-address-assignment static --physical-network-interface-id "&lt;PHYSICAL_INT_ID&gt;" --static-ip-address-configuration IpAddress=&lt;IP_ADDRESS&gt;,NetMask=&lt;NETMASK&gt; --profile snowsbe S3-snow サービスを開始し、先程作成した IP アドレスの VNI Amazon Resource Names (ARN) を指定します（指定する順番によって、 Control か オブジェクト エンドポイントかが決まります）: snowballEdge start-service --service-id s3-snow --device-ip-addresses &lt;SNOWBALL_IP&gt; --virtual-network-interface-arns &lt;S3_CONTROL_VNI_ARN&gt; &lt;S3_OBJECT_VNI_ARN&gt; --profile snowsbe オプション: 次のコマンドを実行して、サービスがアクティブであることを確認します: snowballEdge describe-service --service-id s3-snow --profile snowsbe Step 2: AWS Snowball Edge 上の Amazon S3 Control（バケット）と Amazon S3 API（オブジェクト）のエンドポイントと通信するように AWS CLI を設定 AWS Snowball Edge 上で Amazon S3 互換のストレージサービスが有効になったので、 Amazon S3 Control と Amazon S3 API コマンドを使用 するために AWS CLI の認証情報を設定する必要があります。 1. 次のコマンドを実行して、SBE CLI からアクセスキーを取得します: snowballEdge list-access-keys --profile snowsbe 2. アクセスキーを使って、対応するシークレットアクセスキーを取得します: snowballEdge get-secret-access-key --access-key-id &lt;ACCESS_KEY_ID&gt; --profile snowsbe 3. AWS Snowball Edge の証明書とそれぞれの ARN をリストします: snowballEdge list-certificates --profile snowsbe 4. 前述の証明書の ARN 値を使用して、AWS Snowball Edge の証明書をダウンロードしてローカルに保存します。出力された証明書を拡張子「.pem」のファイルに保存します: snowballEdge get-certificate --certificate-arn &lt;CERT_ARN&gt; --profile snowsbe &gt; ~/.aws/snowsbe_cert.pem 5. .pem ファイルの権限を読み取り専用に設定し、システム上の他のユーザーがアクセスできないようにします: a. Linux の場合: chmod 400 ~/.aws/snowsbe_cert.pem b. Windows の場合: ファイルを右クリック &gt; プロパティ &gt; 読み取り専用に切り替える 6. ~/.aws/config ファイルを編集し、この AWS Snowball Edge デバイス用のプロファイルを作成します: Step 3: AWS Snowball Edge 上に、2 つの Amazon S3 互換ストレージのバケットを作成 AWS Snowball Edge デバイスの AWS CLI プロファイルを設定した後、AWS CLI から Amazon S3 Control API にアクセスして Amazon S3 バケットを作成できます。 ダウンサンプリングした動画を保存するバケットを AWS Snowball Edge 上に作成します: aws s3control create-bucket --bucket &lt;downsampled-bucket-video&gt; --profile snowsbe --endpoint-url https://&lt;S3_CONTROL_IP&gt; 次に、AWS DataSync エージェントを AMI として保存するバケットを作成します: aws s3control create-bucket --bucket &lt;ami-bucket&gt; --profile snowsbe --endpoint-url https://&lt;S3_CONTROL_IP&gt; Step 4: AWS Snowball Edge デバイス上で VM Import/Export (VMIE) サービスを有効にするために、AWS Identity and Access Management (IAM) ロールとポリシーを作成 AWS DataSync エージェントを AWS Snowball Edge 上の Amazon EC2 互換のコンピュートインスタンスとしてインポートするには、VMIE サービスを使用します。AWS Snowball Edge へと VMIE サービスを適用するには、インポート処理に必要な権限を与えられた AWS IAM ロールと AWS IAM ポリシーが必要です。 この例では、AWS CLI を使用して AWS IAM ポリシーと AWS IAM ロールを作成し、AWS IAM ポリシーを AWS IAM ロールにアタッチして、AWS Snowball Edge 上の VMIE サービスが AWS IAM ロールを引き受けるための AWS IAM 信頼ポリシーを作成します。AWS OpsHub の GUI を使用した AWS IAM ポリシーの設定に関するウォークスルーは、 この Amazon Storage Blog の Step 3 を参照してください。 AWS IAM 信頼ポリシーファイル をローカルにダウンロードし、”trust-policy.json” と名付けます: 参照した trust-policy.json を使用して AWS IAM ロールを作成します: aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 AWS IAM ポリシーファイル をローカルにダウンロードし、”iam-policy.json” と名前を付けます。AWS アカウント ID、AWS Snowball Edge のジョブ ID、Step 3.2 で作成した &lt;ami-bucket&gt; を反映するようにファイルを編集します。 iam-policy.json ファイルを使用して、AWS Snowball Edge で AWS IAM ポリシーを作成します: aws iam create-policy --policy-name vmimport-resource-policy --policy-document file://iam-policy.json --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 前のステップの AWS IAM ポリシーの ARN を使用して、AWS IAM ポリシーの vmimport-resource-policy を AWS IAM ロールである vmimport にアタッチします: aws iam attach-role-policy --role-name vmimport --policy-arn arn:aws:iam::&lt;ACCOUNT-ID&gt;:policy/vmimport-resource-policy --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:6089 Step 5: Amazon EC2 インスタンスから AWS DataSync AMI を作成し、オンプレミス環境にエクスポート AWS DataSync を設定する最初のステップは、 AWS DataSync エージェントをデプロイ することです。AWS DataSync エージェントをデプロイする場所を選択する場合は、できるだけ AWS Snowball Edge に近い場所にデプロイしレイテンシを削減し、AWS DataSync のインライン圧縮を使用し転送時間とネットワーク転送コストを削減します。この例では、AWS DataSync エージェントを AWS SnowBall Edge 上に直接デプロイし、Amazon S3 互換ストレージサービスへのレイテンシを低減すると同時に、ローカルコンピューティング機能を使用します。 Amazon EC2 インスタンスに最新の AWS DataSync エージェントをデプロイして、AWS リージョンにプライベートの AWS DataSync エージェント AMI を作成します。この方法では、以下の手順で AWS Snowball Edge 上で AWS DataSync エージェントを実行する際に、SSH 経由でローカルコンソールにアクセスすることができます: 1. AWS Snowball Edge 上の VMIE サービスに関する Step 4 のガイダンスと同様に、AWS リージョンタイプの VMIE サービスに必要な前準備を完了して、AWS DataSync エージェントのイメージを Amazon S3 にエクスポートする準備をします: a. AWS DataSync サービスと同じ AWS リージョンに、イメージを保存するための Amazon S3 バケットを作成 します。 b. 適切な権限を持つ VMIE サービス用の AWS IAM ロールを作成 します。 2. 以下のガイダンスに従って、 AWS DataSync エージェントを Amazon EC2 インスタンスとしてデプロイ します: a. AWS DataSync AMI には、AWS DataSync サービスおよび Amazon S3 バケットと同じ AWS リージョンを使用します。 b. 以下の設定でインスタンスを起動します: i. c4.xl インスタンスを使用します。これは前世代の xen ハイパーバイザーで実行され、AWS Snowball Edge にインポートする前に、必要なネットワークとストレージのドライバーがインストールされていることを確認します。 ii. 後でローカルにおいて AWS Snowball Edge デバイス上でキーペアを作成 できるため、ログイン用のキーペアを作成せずに進めます。 iii.リージョンのデフォルト Amazon VPC サブネットを選択します。 iv. パブリック接続は不要なので、パブリック IP の自動割り当てを無効にします。 v. 既存のデフォルトセキュリティグループを選択して、インバウンド接続を制限します。 vi. ブロックデバイスマッピングで、暗号化された Amazon Elastic Block Store（Amazon EBS）スナップショットを含むイメージをエクスポートできない ため、 Amazon EBS ボリュームは暗号化しません。AWS リージョンが デフォルトで Amazon EBS ボリュームを暗号化 しないことを確認します。 3. インスタンスを数分間実行後、 インスタンスを停止 して AMI を作成する準備をします。 4. 停止した AWS DataSync 用の Amazon EC2 インスタンスから AMI を作成 します。 5. VMIE サービスを使用して AMI をエクスポート します。 a. Step 5.4 の ami-id を使用します。 b. RAW の disk-image-format を使用します。 c. Step 5.1 の Amazon S3 バケット名 “S3Bucket= &lt;name&gt; ” を使用します。 d. デフォルトの Amazon S3 プレフィックス値 “S3Prefix=export/” を使用します。 6. AWS DataSync エージェント用の Amazon EC2 インスタンスを終了 します。 7. Step 5.5 で作成した Amazon S3 バケットから、.raw イメージファイルをローカルマシンにダウンロードします。 AWS Management Console を使用することもできますが、AWS CLI は大きなデータの転送に最適化されています。ファイルサイズが ~80 GB あるので、高速なインターネット接続の使用を推奨します: aws s3 cp s3://&lt;export bucket name&gt;/export/&lt;image-name&gt;.raw &lt;path for local object storage&gt;/datasync-agent.raw Step 6: AWS Snowball Edge デバイス上に Amazon EC2 互換のコンピュートインスタンスとして AWS DataSync エージェントをインポートして起動 AWS DataSync エージェントイメージを AWS Snowball Edge に サイドロード する準備ができました。エージェント登録キーの取得やトラブルシューティング時のサポートのために AWS DataSync エージェントのローカルコンソールにアクセスする 必要がある場合は、必ず ローカルの AWS SnowBall Edge キーペアを作成 し、そのキーを関連付けた Amazon EC2 互換のコンピュートインスタンスを起動してください。 この例では、以下の手順で Terraform を使用して AWS DataSync エージェントをアクティベートしたため、関連する SSH キーペアなしで AWS DataSync エージェントを AWS Snowball Edge デバイスにデプロイしました: 1. AWS DataSync エージェントのイメージをアップロードして、AWS SnowBall Edge 上で Amazon EC2 互換のコンピュートインスタンスとして実行します: a. datasync-agent.raw イメージファイルを S3-snow における ami-bucket（Step 3.2 で作成）へとアップロードします。.raw ファイルは約 85 GB なので、デバイスにローカル接続されていない場合は、高帯域幅のネットワークを介してアップロードすることをお勧めします。 aws s3 cp datasync-agent.raw s3://&lt;ami-bucket&gt;/datasync-agent --profile snowsbe --endpoint-url https://&lt;S3_OBJECT_IP&gt; b. アップロードされた datasync-agent.raw イメージをスナップショット &lt;SNAPSHOT_ID&gt; としてインポートします: aws ec2 import-snapshot --disk-container "Format=RAW,UserBucket={S3Bucket=&lt;ami-bucket&gt;,S3Key=datasync-agent}" --description "DataSync Image" --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. .raw ファイルからスナップショットへのインポートが完了したことを判断するには、ステータスが “ Pending ” から “ Completed ” に変わったことを確認します: aws ec2 describe-import-snapshot-tasks --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 d. スナップショットを AMI として登録します。前のステップで SnapshotID をキャプチャし、 Mac または Windows ターミナル を使用して以下を更新してください: aws ec2 register-image --name DataSync --description "DataSync agent" --block-device-mappings "[{\"DeviceName\": \"/dev/sda1\",\"Ebs\":{\"Encrypted\":false,\"DeleteOnTermination\":false,\"SnapshotId\":\"&lt;SNAPSHOTID&gt;\",\"VolumeSize\":80}}]" --root-device-name /dev/sda1 --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 2. AWS DataSync エージェントのセキュリティグループを作成します。 デフォルトの AWS Snowball Edge セキュリティグループ は、インバウンドとアウトバウンドのすべてのトラフィックを許可します。AWS Snow Family でのセキュリティグループの詳細については、「 AWS Snowball Edge デバイスでのセキュリティグループの使用と管理 」を参照してください。ユースケースの要件に合わせて AWS DataSync ネットワーク要件 を確認します。以下の手順に従って、AWS DataSync エージェントのテストとアクティベーションのために、インバウンドのネットワーク接続を制限しました: a. ‘datasync-agent’ という新しいセキュリティグループを作成します: aws ec2 create-security-group --group-name datasync-agent --description "Security group for the DataSync agent operating as EC2-compatible compute instance" --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 b. 前のコマンドの group-ID 値と LAN のサブネットを使用して、接続テスト用に ICMP を許可するインバウンドルールエントリーを作成します: aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --ip-permissions '[{"IpProtocol": "icmp", "FromPort": -1, "ToPort": -1, "IpRanges": [{"CidrIp": "&lt;Local Area Network Subnet/CIDR &gt;", "Description": "ICMP inbound from local area network"}]}]' --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. Terraform ワークステーション（例えばローカルワークステーション）から Amazon EC2 DataSync エージェントをアクティベートするために、HTTP (TCP/80) を許可するインバウンドルールエントリーを作成します。このルールは、Amazon EC2 互換のコンピュートインスタンスのローカルコンソールから SSH 経由で AWS DataSync エージェントのアクティベーションキーを取得しない場合に必要です: aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --protocol tcp --port 80 --cidr &lt;Terraform Host IP/32&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 オプション: ワークステーションの IP から AWS DataSync エージェントへのローカルコンソールアクセス用に SSH 接続を許可するインバウンドルールエントリーを作成します。 aws ec2 authorize-security-group-ingress --group-id &lt;s.sg-id&gt; --protocol tcp --port 22 --cidr &lt;local workstation IP/32&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 d. セキュリティグループルールの構成を検証します: aws ec2 describe-security-groups --group-id &lt;s.sg-id&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 3. AWS DataSync エージェントを AWS Snowball Edge 上の Amazon EC2 互換コンピュートインスタンスとして起動します: a. AWS DataSync エージェント AMI を起動します: aws ec2 run-instances --image-id &lt;IMAGE_ID&gt; --instance-type sbe-c.2xlarge --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 b. 状態の “Name” が Running に変わるまで状態を確認します: aws ec2 describe-instances --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 c. インスタンスが Running 状態になったら、SBE CLI を使用して AWS DataSync エージェント用の Amazon EC2 互換のコンピュートインスタンスに IP アドレスを割り当てます。物理インターフェース ID は、前の Step 1.5 で確認できます。インスタンスの LAN サブネットで使用可能な IP を選択します: snowballEdge create-virtual-network-interface --physical-network-interface-id &lt;PHYSICAL_INT_ID&gt; --ip-address-assignment STATIC --static-ip-address-configuration IpAddress=&lt;IP_ADDRESS&gt;,Netmask=&lt;NETMASK&gt; --profile snowsbe d. VNI をインスタンスに関連付けます: aws ec2 associate-address --public-ip &lt;IP_ADDRESS&gt; --instance-id &lt;DATASYNC_INSTANCE_ID&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 e. 新しいセキュリティグループ datasync-agent をインスタンスに割り当て、デフォルトのセキュリティグループを置き換えます: aws ec2 modify-instance-attribute --instance-id &lt;datasync instance ID&gt; --groups &lt;s.sg-id&gt; --profile snowsbe --endpoint https://&lt;SNOWBALL_IP&gt;:8243 f. 以下の 2 つのステップのいずれかで、AWS DataSync エージェントをアクティベートします: i. Terraform ワークステーションから AWS DataSync エージェントにアクセスできる場合は、Terraform の datasync_agent_ip_address 変数に AWS DataSync エージェントの IP アドレスを入力します。以下の Terraform を適用すると、エージェントは自動的にアクティベートします。 ii. Terraform から AWS DataSync エージェントにアクセスできない場合（AWS Management Console にアクセスするワークステーションが http://&lt;AGENT_ADDRESS&gt; の AWS DataSync エージェントにアクセスできることを確認してください）、AWS Management Console からアクティベーションキーを取得します: 1. AWS Management Console で AWS DataSync サービス を開き、 エージェント を選択します。リージョンが AWS Snowball Edge と同じであることを確認します。 2. エージェントの作成 を選択します。 3. Activation key セクションで、 エージェントのアドレス 欄に AWS DataSync エージェントの IP アドレスを入力し、 キーを取得する を選択します。 4. アクティベーションキー をコピーし、Terraform の datasync_agent_activation_key 変数に入力します: Step 7: Infrastructure-as-Code (IaC) をデプロイしてエージェントをアクティベートし、AWS DataSync タスクとロケーションを作成して、ユーザー定義のスケジュールで AWS Snowball Edge デバイスから AWS リージョンの Amazon S3 バケットにレプリケート AWS DataSync エージェントがデプロイされたので、Terraform を使ってこれらのタスクを実行します: エージェントをアクティベートします。 Amazon S3 バケットと Amazon CloudWatch ロググループを暗号化するために、2 つの AWS Key Management Service (AWS KMS) キーを作成します。 暗号化された Amazon S3 バケットを作成し、AWS DataSync タスクからダウンサンプリングされた動画を受け取ります。 AWS DataSync タスクの実行ログを保存するために、暗号化された Amazon CloudWatch ロググループを作成します。 エージェントが実行する AWS DataSync タスクを作成します。AWS Management Console の代わりに、 このチュートリアルガイド を使用することができます。 AWS DataSync タスクのソースバケットと宛先バケットを設定します。 AWS DataSync タスクを毎晩実行するようにスケジュールします。 設定した AWS DataSync タスク構成では、ソースバケットと宛先バケット間で変更されたデータまたは異なるデータのみを転送することで、時間とコストを節約しています。S3-snow バケット内のダウンサンプリングされた動画ファイルは、外部アプリケーションによって定期的に自動的に削除されるため、宛先バケットからも削除されないように、削除されたファイルを保持する設定（デフォルト）を適用しています。 また、 Amazon S3 バケットライフサイクルルール を用いて、一定期間が経過したファイルを自動的に削除することもできます。 Amazon CloudWatch Logs 上の AWS DataSync 実行ログは、コスト最適化のため 30 日間しか保持しないことに注意してください。ログ保持のニーズに合わせて更新してください。 a. provider.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 b. variables.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 c. main.tf ファイルをローカルにダウンロードし、Terraform の作業ディレクトリにロードします。 erraform.tfvars のようなファイル内の変数は環境に応じて設定してください。また、使用する前に以下の variables.tf の変数も修正してください: local_storage_hostname -クォーテーションで囲まれた文字列である &lt;S3_OBJECT_IP&gt; local_storage_bucket -クォーテーションで囲まれた文字列である &lt;downsampled-bucket-video&gt; local_storage_certificate -Step 2.6 で設定したパスとオブジェクト名 aws_region -us-east-1 を使用していない場合は変更 datasync_agent_ip_address または datasync_agent_activation_key -Step 6.3 f で選択したアクティベート方法に対して null をクォーテーションで囲んだ文字列型に置き換えて設定 さらに、以下のシェル変数をそれぞれ AWS SnowballEdge デバイスのアクセスキーとシークレットアクセスキーに設定します: export TF_VAR_local_storage_ak="SNOWBALLEDGE_ACCESS_KEY_ID" export TF_VAR_local_storage_sk="SNOWBALLEDGE_SECRET_ACCESS_KEY" または、Terraform の適用中にプロンプトが表示されたら、キー情報を入力することもできます。 Terraform ファイルを含む作業ディレクトリに移動し、マニフェストを適用します: terraform init terraform apply Step 8: AWS DataSync レプリケーションタスクを検証し実行 全ての設定が適切であることを確認するには、S3-snow バケット &lt;downsampled-bucket-video&gt; にファイルをアップロードし、手動で AWS DataSync タスクを実行します: テストファイルを S3-snow バケットにアップロードします: aws s3 cp &lt;testvideo.mpg&gt; s3://&lt;downsampled-bucket-video&gt;/&lt;testfile.mpg&gt; --profile snowsbe --endpoint-url https://&lt;S3_OBJECT_IP&gt; AWS DataSync タスクを実行します。&lt;DATASYNC_TASK_ARN&gt; は terraform apply の出力の最終行、またはコンソールの AWS DataSync サービスページの タスク にあります: aws datasync start-task-execution --task-arn &lt;DATASYNC_TASK_ARN&gt; 前のステップの出力で表示されたタスク実行 ARN から、タスクのステータスをチェックします: aws datasync describe-task-execution --task-execution-arn &lt;TASK_EXECUTION_ARN&gt; タスクが “Success” を返した場合、テストファイル ( testvideo.mpg ) は Amazon S3 の宛先バケットで利用可能になっているはずです。タスクが “Success” 以外のステータスで終了した場合、Amazon CloudWatch 上のタスク実行に関するログを確認することでトラブルシュートできます。“/aws/datasync/” に続くランダムな 12 文字のプレフィックスを持った Amazon CloudWatch のロググループをチェックしてください。 タスクのステータスを監視し、失敗した際に通知を作成するために、 Amazon EventBridge ルール を設定することもできます。また、監査目的で Amazon CloudWatch 上のログの保持期間を 30 日以上に設定したり、コスト最適化のために Amazon S3 バケットキー を有効にすることもできます。 2,000 万以上のファイル、オブジェクト、およびディレクトリをレプリケートするには、AWS DataSync エージェントに用いるインスタンスタイプを sbe-c.2xlarge から sbe-c.4xlarge に変更 し、 必要要件である 64 GB のメモリ を確保してください。 最後に、AWS DataSync がこれらのリクエストをどのように使用し、Amazon S3 のコストにどのような影響を与えるかをよりよく理解するために、AWS DataSync を使用する際の Amazon S3 のリクエストコスト を調べることをお勧めします。 クリーンアップ Terraform でデプロイしたインフラストラクチャを破棄するには、まず AWS リージョンの Amazon S3 バケットに保存されているオブジェクトをすべて完全に削除 します。また、新しく作成した Amazon S3 バケットの削除防止を解除するために、main.tfコードの 77 行目をコメントアウトまたは削除する必要があります。 最後に、ターミナルウィンドウから以下を実行します: terraform destroy まとめ この記事では、AWS DataSync を設定してエッジから AWS リージョンにデータを自動的かつ効率的に移行する方法を紹介しました。AWS Snowball Edge デバイス上の Amazon S3 互換ストレージを設定するために必要な手順を詳しく説明し、AMI とアプリケーションデータ用に 2 つのバケットを作成しました。AWS Snowball Edge に AWS DataSync エージェントをデプロイし、AWS Snowball Edge の Amazon S3 互換バケットから Amazon S3 バケットに変更されたデータを定期的に自動移行する AWS DataSync タスクをプログラムで構成する方法を説明しました。 このソリューションの全部または一部を使用することで、現場の AWS Snowball Edge デバイスとお客様のご希望の AWS リージョン間のあらゆるメディアデータの同期に関連するタイムラグを簡素化および削減し、機械学習の運用パイプラインやエンタープライズデータレイクへの保存などのユースケースを実現することができます。 <!-- '"` --> TAGS: Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage , AWS DataSync , AWS Snow Family Brad Beaulieu Brad Beaulieu は、Booz Allen 社の CTO (Chief Technology Office) である BrightLabs チームのプリンシパルとして、米国連邦政府および民間クライアント向けのエッジクラウド投資を主導しています。2009 年から Booz Allen 社に勤務し、クラウドセキュリティやマネージドサービスに関するさまざまな取り組みを行っています。裏庭でのガーデニングや山でのハイキングなど、アウトドアが趣味です。 Christopher Smith Christopher Smith は Amazon Web Services (AWS) の米国連邦政府パートナーチームの Principal Solutions Architect です。2003 年に民間企業に入って以来、米国連邦政府をサポートしています。自由な時間を家族のために使うことでワークライフバランスを管理し、可能な限りトリビアやアウトドアを楽しんでいます。 Dru Grote Dru Grote は Booz Allen Hamilton 社の Senior Lead Technologist です。クラウドにおける自動化および監視ソリューションのセキュアな実装に情熱を注いでいます。キーボードから離れているときは、写真を撮ったり、サイクリングをしています。

自動車、ロボット工学、金融などの業界では、製品を改善するために、シミュレーション、機械学習 (ML) モデルのトレーニング、ビッグデータ分析などの計算ワークロードの実装が増加の一途をたどっています。例えば、自動車メーカーはシミュレーションに依拠して自動運転機能をテストし、ロボット工学分野の企業は ML アルゴリズムをトレーニングしてロボットの認識機能を強化しているほか、金融業界の企業は詳細な分析を実行して、リスク管理、取引処理、不正行為の検出を改善しています。 シミュレーションを含むこれらのワークロードの一部は、コンポーネントの多様性と厳しい計算要件により、実行が特に複雑です。例えば、運転シミュレーションには、3D 仮想環境、車両センサーデータ、車両の挙動を制御する車両ダイナミクスなどの生成が伴います。ロボット工学シミュレーションでは、大規模な倉庫環境で、相互に、および他のシステムとインタラクションする何百もの自律型配送ロボットをテストする可能性があります。 AWS Batch は、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Fargate 、および Amazon EC2 スポット または オンデマンド インスタンスなど、さまざまな AWS コンピューティングサービスにわたってバッチワークロードを実行するのに役立つフルマネージドサービスです。従来、AWS Batch では単一コンテナのジョブのみが許可されており、すべてのコンポーネントをモノリシックコンテナにマージするには追加のステップが必要でした。また、データログ記録などの追加サービスを提供することでメインアプリケーションを補完する補助コンテナである、別個の「サイドカー」コンテナも使用できませんでした。コードの変更はコンテナ全体の再構築を意味するため、この追加の作業には、ソフトウェア開発、IT 運用、品質保証 (QA) などの複数のチームにわたる調整が必要でした。 AWS Batch はマルチコンテナジョブを提供するようになりました。これにより、自動運転車やロボット工学などの分野で大規模なシミュレーションをより簡単かつ迅速に実行できます。これらのワークロードは通常、シミュレーション自体と、シミュレーションとインタラクションするテスト対象のシステム (エージェントとも呼ばれます) に分割されます。これらの 2 つのコンポーネントは、多くの場合、異なるチームによって開発および最適化されます。ジョブごとに複数のコンテナを実行できるため、AWS Batch が提供する高度なスケーリング、スケジューリング、コストの最適化を利用できるほか、3D 環境、ロボットセンサー、モニタリングサイドカーなどのさまざまなコンポーネントを表すモジュール式コンテナを使用できます。実際、 IPG Automotive 、 MORAI 、 Robotec.ai などのお客様は既に AWS Batch マルチコンテナジョブを使用してクラウドでシミュレーションソフトウェアを実行しています。 簡単な例を使用して実際にこれがどのように機能するかを見て、迷路を解くのを楽しんでみましょう。 コンテナ上で実行されるシミュレーションの構築 本番環境では、おそらく既存のシミュレーションソフトウェアを使用することになります。この記事では、エージェント/モデルシミュレーションの簡易バージョンを構築しました。コードの詳細に興味がない場合は、このセクションを飛ばして、AWS Batch の設定方法にお進みください。 このシミュレーションでは、探索する世界はランダムに生成された 2D の迷路です。エージェントには、迷路を探索して鍵を見つけ、出口に到達するというタスクが課されています。ある意味、これは 3 つの場所がある経路探索問題の典型的な例です。 これは、開始 ( S )、終了 ( E )、およびキー ( K ) の位置を示した迷路のサンプルマップです。 エージェントとモデルを 2 つの別々のコンテナに分離することで、異なるチームがそれぞれを個別に作業できるようになります。各チームは、シミュレーションに詳細を追加したり、エージェントが迷路を探索する方法についてより優れた戦略を見つけたりするなど、自分の担当部分の改善に集中できます。 迷路モデルのコードは次のとおりです ( app.py )。どちらの例でも Python を使用しました。このモデルは、エージェントが迷路内を移動したり、鍵を見つけて出口に到達したかどうかを把握したりするために使用できる REST API を公開します。迷路モデルは REST API に Flask を使用します。 import json import random from flask import Flask, request, Response ready = False # マップデータを迷路内に保存する方法 # サイズ指定あり (幅 x 高さ) = (4 x 3) # # 012345678 # 0: +-+-+ +-+ # 1: | | | | # 2: +-+ +-+-+ # 3: | | | | # 4: +-+-+ +-+ # 5: | | | | | # 6: +-+-+-+-+ # 7: 未使用 class WrongDirection(Exception): pass class Maze: UP, RIGHT, DOWN, LEFT = 0, 1, 2, 3 OPEN, WALL = 0, 1 @staticmethod def distance(p1, p2): (x1, y1) = p1 (x2, y2) = p2 return abs(y2-y1) + abs(x2-x1) @staticmethod def random_dir(): return random.randrange(4) @staticmethod def go_dir(x, y, d): if d == Maze.UP: return (x, y - 1) elif d == Maze.RIGHT: return (x + 1, y) elif d == Maze.DOWN: return (x, y + 1) elif d == Maze.LEFT: return (x - 1, y) else: raise WrongDirection(f"Direction: {d}") def __init__(self, width, height): self.width = width self.height = height self.generate() def area(self): return self.width * self.height def min_lenght(self): return self.area() / 5 def min_distance(self): return (self.width + self.height) / 5 def get_pos_dir(self, x, y, d): if d == Maze.UP: return self.maze[y][2 * x + 1] elif d == Maze.RIGHT: return self.maze[y][2 * x + 2] elif d == Maze.DOWN: return self.maze[y + 1][2 * x + 1] elif d == Maze.LEFT: return self.maze[y][2 * x] else: raise WrongDirection(f"Direction: {d}") def set_pos_dir(self, x, y, d, v): if d == Maze.UP: self.maze[y][2 * x + 1] = v elif d == Maze.RIGHT: self.maze[y][2 * x + 2] = v elif d == Maze.DOWN: self.maze[y + 1][2 * x + 1] = v elif d == Maze.LEFT: self.maze[y][2 * x] = v else: WrongDirection(f"Direction: {d} Value: {v}") def is_inside(self, x, y): return 0 &lt;= y &lt; self.height and 0 &lt;= x &lt; self.width def generate(self): self.maze = [] # すべての境界を閉じます for y in range(0, self.height + 1): self.maze.append([Maze.WALL] * (2 * self.width + 1)) # いずれかの境界線でランダムな開始点を取得します if random.random() &lt; 0.5: sx = random.randrange(self.width) if random.random() &lt; 0.5: sy = 0 self.set_pos_dir(sx, sy, Maze.UP, Maze.OPEN) else: sy = self.height - 1 self.set_pos_dir(sx, sy, Maze.DOWN, Maze.OPEN) else: sy = random.randrange(self.height) if random.random() &lt; 0.5: sx = 0 self.set_pos_dir(sx, sy, Maze.LEFT, Maze.OPEN) else: sx = self.width - 1 self.set_pos_dir(sx, sy, Maze.RIGHT, Maze.OPEN) self.start = (sx, sy) been = [self.start] pos = -1 solved = False generate_status = 0 old_generate_status = 0 while len(been) &lt; self.area(): (x, y) = been[pos] sd = Maze.random_dir() for nd in range(4): d = (sd + nd) % 4 if self.get_pos_dir(x, y, d) != Maze.WALL: continue (nx, ny) = Maze.go_dir(x, y, d) if (nx, ny) in been: continue if self.is_inside(nx, ny): self.set_pos_dir(x, y, d, Maze.OPEN) been.append((nx, ny)) pos = -1 generate_status = len(been) / self.area() if generate_status - old_generate_status &gt; 0.1: old_generate_status = generate_status print(f"{generate_status * 100:.2f}%") break elif solved or len(been) &lt; self.min_lenght(): continue else: self.set_pos_dir(x, y, d, Maze.OPEN) self.end = (x, y) solved = True pos = -1 - random.randrange(len(been)) break else: pos -= 1 if pos &lt; -len(been): pos = -1 self.key = None while(self.key == None): kx = random.randrange(self.width) ky = random.randrange(self.height) if (Maze.distance(self.start, (kx,ky)) &gt; self.min_distance() and Maze.distance(self.end, (kx,ky)) &gt; self.min_distance()): self.key = (kx, ky) def get_label(self, x, y): if (x, y) == self.start: c = 'S' elif (x, y) == self.end: c = 'E' elif (x, y) == self.key: c = 'K' else: c = ' ' return c def map(self, moves=[]): map = '' for py in range(self.height * 2 + 1): row = '' for px in range(self.width * 2 + 1): x = int(px / 2) y = int(py / 2) if py % 2 == 0: # 偶数行 if px % 2 == 0: c = '+' else: v = self.get_pos_dir(x, y, self.UP) if v == Maze.OPEN: c = ' ' elif v == Maze.WALL: c = '-' else: # 奇数行 if px % 2 == 0: v = self.get_pos_dir(x, y, self.LEFT) if v == Maze.OPEN: c = ' ' elif v == Maze.WALL: c = '|' else: c = self.get_label(x, y) if c == ' ' and [x, y] in moves: c = '*' row += c map += row + '\n' return map app = Flask(__name__) @app.route('/') def hello_maze(): return "&lt;p&gt;Hello, Maze!&lt;/p&gt;" @app.route('/maze/map', methods=['GET', 'POST']) def maze_map(): if not ready: return Response(status=503, retry_after=10) if request.method == 'GET': return '&lt;pre&gt;' + maze.map() + '&lt;/pre&gt;' else: moves = request.get_json() return maze.map(moves) @app.route('/maze/start') def maze_start(): if not ready: return Response(status=503, retry_after=10) start = { 'x': maze.start[0], 'y': maze.start[1] } return json.dumps(start) @app.route('/maze/size') def maze_size(): if not ready: return Response(status=503, retry_after=10) size = { 'width': maze.width, 'height': maze.height } return json.dumps(size) @app.route('/maze/pos/&lt;int:y&gt;/&lt;int:x&gt;') def maze_pos(y, x): if not ready: return Response(status=503, retry_after=10) pos = { 'here': maze.get_label(x, y), 'up': maze.get_pos_dir(x, y, Maze.UP), 'down': maze.get_pos_dir(x, y, Maze.DOWN), 'left': maze.get_pos_dir(x, y, Maze.LEFT), 'right': maze.get_pos_dir(x, y, Maze.RIGHT), } return json.dumps(pos) WIDTH = 80 HEIGHT = 20 maze = Maze(WIDTH, HEIGHT) ready = True 迷路モデル ( requirements.txt 内) の唯一の要件は、 Flask モジュールです。 迷路モデルを実行するコンテナイメージを作成するには、この Dockerfile を使用します。 FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-alpine WORKDIR /app COPY requirements.txt requirements.txt RUN pip3 install -r requirements.txt COPY . . CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0", "--port=5555"] エージェントのコードは次のとおりです ( agent.py )。まず、エージェントはモデルに迷路のサイズと開始位置をたずねます。その後、独自の戦略を適用して迷路を探索し、解決します。この実装では、エージェントはルートをランダムに選択し、同じパスを複数回たどることを避けようとします。 import random import requests from requests.adapters import HTTPAdapter, Retry HOST = '127.0.0.1' PORT = 5555 BASE_URL = f"http://{HOST}:{PORT}/maze" UP, RIGHT, DOWN, LEFT = 0, 1, 2, 3 OPEN, WALL = 0, 1 s = requests.Session() retries = Retry(total=10, backoff_factor=1) s.mount('http://', HTTPAdapter(max_retries=retries)) r = s.get(f"{BASE_URL}/size") size = r.json() print('SIZE', size) r = s.get(f"{BASE_URL}/start") start = r.json() print('START', start) y = start['y'] x = start['x'] found_key = False been = set((x, y)) moves = [(x, y)] moves_stack = [(x, y)] while True: r = s.get(f"{BASE_URL}/pos/{y}/{x}") pos = r.json() if pos['here'] == 'K' and not found_key: print(f"({x}, {y}) key found") found_key = True been = set((x, y)) moves_stack = [(x, y)] if pos['here'] == 'E' and found_key: print(f"({x}, {y}) exit") break dirs = list(range(4)) random.shuffle(dirs) for d in dirs: nx, ny = x, y if d == UP and pos['up'] == 0: ny -= 1 if d == RIGHT and pos['right'] == 0: nx += 1 if d == DOWN and pos['down'] == 0: ny += 1 if d == LEFT and pos['left'] == 0: nx -= 1 if nx &lt; 0 or nx &gt;= size['width'] or ny &lt; 0 or ny &gt;= size['height']: continue if (nx, ny) in been: continue x, y = nx, ny been.add((x, y)) moves.append((x, y)) moves_stack.append((x, y)) break else: if len(moves_stack) &gt; 0: x, y = moves_stack.pop() else: print("No moves left") break print(f"Solution length: {len(moves)}") print(moves) r = s.post(f'{BASE_URL}/map', json=moves) print(r.text) s.close() エージェントの唯一の依存関係 ( requirements.txt 内) は、 requests モジュールです。 これは、エージェントのコンテナイメージを作成するために使用する Dockerfile です。 FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-alpine WORKDIR /app COPY requirements.txt requirements.txt RUN pip3 install -r requirements.txt COPY . . CMD [ "python3", "agent.py"] この簡略化されたバージョンのシミュレーションはローカルで簡単に実行できますが、クラウドを利用すると、より大規模に実行し (より大規模で詳細な迷路で実行するなど)、複数のエージェントをテストして使用する最適な戦略を見つけることができます。現実のシナリオでは、エージェントの改善はその後、自動運転車やロボット掃除機などの物理デバイスに実装されます。 マルチコンテナジョブを使用したシミュレーションの実行 AWS Batch を利用してジョブを実行するには、次の 3 つのリソースを設定する必要があります: ジョブを実行する コンピューティング環境 ジョブを送信する ジョブキュー 使用するコンテナイメージなど、ジョブの実行方法を記述する ジョブ定義 AWS Batch コンソール で、ナビゲーションペインから [コンピューティング環境] を選択し、次に [作成] を選択します。現在、Fargate、Amazon EC2、または Amazon EKS を利用する選択肢があります。Fargate を利用すると、ジョブ定義で指定したリソース要件に厳密に一致させることができます。ただし、シミュレーションでは通常、大量ではあるものの静的な量のリソースにアクセスする必要があり、計算を高速化するために GPU が使用されます。そのため、ここでは [Amazon EC2] を選択します。 AWS Batch が EC2 インスタンスをスケールおよび設定できるように、 [マネージド] オーケストレーションタイプを選択します。その後、コンピューティング環境の名前を入力し、サービスにリンクされたロール (AWS Batch が以前に作成したもの) と、(EC2 インスタンス上で実行されている) ECS コンテナエージェントが私に代わって AWS API に対して呼び出しを実行するために使用するインスタンスロールを選択します。 [次へ] を選択します。 [インスタンス構成] 設定で、EC2 インスタンスのサイズとタイプを選択します。例えば、GPU を備えたインスタンスタイプや Graviton プロセッサを使用するインスタンスタイプを選択できます。特別な要件はなく、すべての設定をデフォルト値のままにします。 [ネットワーク構成] で、コンソールでは既に [デフォルト VPC] と [デフォルトセキュリティグループ] が選択されています。最後のステップでは、すべての設定を確認し、コンピューティング環境の作成を完了します。 ここで、ナビゲーションペインから [ジョブキュー] を選択し、次に [作成] を選択します。その後、コンピューティング環境に使用したのと同じオーケストレーションタイプ ( Amazon EC2 ) を選択します。 [ジョブキューの設定] で、ジョブキューの名前を入力します。 [接続されたコンピューティング環境] ドロップダウンで、作成したばかりのコンピューティング環境を選択し、キューの作成を完了します。 ナビゲーションペインから [ジョブ定義] を選択し、次に [作成] を選択します。前と同様に、オーケストレーションタイプとして [Amazon EC2] を選択します。 複数のコンテナを使用するには、 [従来の containerProperties 構造を使用] オプションを無効にして、次のステップに進みます。デフォルトでは、アカウントに従来のジョブ定義が既に存在する場合、コンソールは従来の単一コンテナジョブ定義を作成します。私の場合はそのようになります。従来のジョブ定義を持たないアカウントの場合、コンソールではこのオプションが無効になっています。 ジョブ定義の名前を入力します。その後、このジョブにどの許可が必要かを考える必要があります。このジョブに使用するコンテナイメージは、 Amazon ECR プライベートリポジトリに保存されています。AWS Batch がこれらのイメージをコンピューティング環境にダウンロードできるようにするには、 [タスクプロパティ] セクションで、ECR リポジトリに対する読み取り専用アクセスを付与する [実行ロール] を選択します。シミュレーションコードは AWS API を呼び出していないため、 [タスクロール] を設定する必要はありません。例えば、コードが結果を Amazon Simple Storage Service (Amazon S3) バケットにアップロードする場合、そのための許可を付与するロールをここで選択できます。 次のステップでは、このジョブで使用される 2 つのコンテナを設定します。1 つ目は maze-model です。名前と画像の場所を入力します。ここでは、vCPU、メモリ、GPU の観点からコンテナのリソース要件を指定できます。これは、 ECS タスク のコンテナの設定に似ています。 エージェント用の 2 番目のコンテナを追加し、以前と同様に名前、イメージの場所、リソース要件を入力します。エージェントは迷路の開始直後に迷路にアクセスする必要があるため、 [依存関係] セクションを使用してコンテナの依存関係を追加します。コンテナ名として maze-model を選択し、条件として START を選択します。この依存関係を追加しない場合、 maze-model コンテナが実行されて応答できるようになる前に、 agent コンテナが失敗する可能性があります。このジョブ定義では両方のコンテナに必須のフラグが設定されているため、ジョブ全体が失敗して終了します。 すべての設定を確認し、ジョブ定義を完了します。これで、仕事を始めることができます。 ナビゲーションペインの [ジョブ] セクションで、新しいジョブを送信します。名前を入力し、ジョブキューと作成したばかりのジョブ定義を選択します。 次のステップでは、設定を上書きしてジョブを作成する必要はありません。数分後、ジョブは成功し、2 つのコンテナのログにアクセスできるようになりました。 エージェントは迷路を解決したので、ログからすべての詳細を取得できます。エージェントがどのように開始され、キーを取得し、出口を見つけたかを示すジョブの出力を次に示します。 SIZE {'width': 80, 'height': 20} START {'x': 0, 'y': 18} (32, 2) key found (79, 16) exit Solution length: 437 [(0, 18), (1, 18), (0, 18), ..., (79, 14), (79, 15), (79, 16)] マップでは、赤いアスタリスク ( * ) は、開始 ( S )、キー ( K )、および終了 ( E ) の場所間でエージェントがたどるパスを示しています。 サイドカーコンテナによるオブザーバビリティの向上 複数のコンポーネントを使用して複雑なジョブを実行する場合、これらのコンポーネントが何を行っているかをより明確に把握することができます。例えば、エラーやパフォーマンスの問題が発生した場合、この情報は問題が発生した場所とその内容を見つけるのに役立ちます。 アプリケーションをインストルメント化するには、 AWS Distro for OpenTelemetry を使用します。 まず、 agent コンテナと maze-model コンテナを更新して、 この記事で説明されている Python 自動インストルメンテーションを使用します 。Go、Java、JavaScript など、他のプラットフォームにも同様のチュートリアルがあります。自分のアプリケーションに固有の情報を取得するために、 コードを手動でインストルメント化する というオプションがあります。 その後、 Amazon ECR Public Gallery の AWS Distro for OpenTelemetry Collector を使用してサイドカーコンテナを追加します。 collector コンテナは、他のコンテナからテレメトリデータを受信し、トレースを AWS X-Ray に送信して、メトリクスを Amazon CloudWatch 、 Amazon Managed Service for Prometheus 、またはセルフマネージド Prometheus に送信します。OpenTelemetry を使用すると、 複数のモニタリングおよびオブザーバビリティプラットフォーム とのデータの共有が容易になります。 この方法で収集されたテレメトリデータを使用すると、何が起こっているかをより良く理解し、問題を解決するための時間を短縮するのに役立つダッシュボード (例えば、CloudWatch または Amazon Managed Grafana を利用) やアラーム (CloudWatch または Prometheus を利用) を設定できます。より一般的には、サイドカーコンテナは、AWS Batch ジョブからのテレメトリデータをモニタリングおよびオブザーバビリティプラットフォームに統合するのに役立ちます。 知っておくべきこと AWS Batch によるマルチコンテナジョブのサポートは現在、Batch が提供されているすべての AWS リージョン において、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK でご利用いただけます。詳細については、 AWS サービス (リージョン別) をご覧ください。 AWS Batch でマルチコンテナジョブを使用する場合、追加料金はかかりません。実際、AWS Batch の利用には追加料金はかかりません。お支払いいただくのは、EC2 インスタンスや Fargate コンテナなど、アプリケーションを保存および実行するために作成した AWS リソースの料金のみです。コストを最適化するために、コンピューティング環境で リザーブドインスタンス 、 Savings Plan 、EC2 スポットインスタンス、Fargate を使用できます。 マルチコンテナジョブを使用すると、ジョブの準備作業が減ることで開発時間が短縮されるほか、複数のチームの作業を 1 つのコンテナにマージするカスタムツールの必要性がなくなります。また、コンポーネントの責任を明確に定義することで DevOps を簡素化し、チームが他の作業に煩わされることなく自分の専門分野の問題を迅速に特定して修正できるようにします。 詳細については、「 AWS Batch ユーザーガイド 」でマルチコンテナジョブを設定する方法をご覧ください。 – Danilo 原文は こちら です。

組織の目的に応じたリソースタグを一貫して適用することは、簡単ではないケースがあります。例えば、正確な原価配分や細かなアクセス制御などを行いたい時です。また、開発者が開発やテストの初期段階で作成した別環境のリソースをクリーンアップする時に、問題に直面することもあるでしょう。適切なタグ付けがされていないと、組織から離れた開発者が作成したお試しリソースを特定したり、プロジェクトが終了した際にリソースをクリーンアップするのが難しくなります。 AWSリソースへのタグ付けは、ワークロード開発の初期段階で見落とされがちです。開発者にタグ付与ルールを守らせるのに苦労するユーザーもいます。AWS リソースに対して正確で意味のあるタグを一貫して付けることこそが、ベストプラクティスです。 AWS Organizations の全機能を有効にしているユーザーに人気の方法の1つは、すべてのリソースに特定のタグを付けることを要求するサービス制御ポリシー (SCP) を作成し、タグポリシーを使ってリソースに有効なタグが付けられるようにすることです。AWS Organizations は複数の AWS アカウントの管理をポリシーベースで行え、AWS リソースのスケーリングに伴う環境を一元管理できます。 あるいは、企業が現在 AWS Organizations を使用していないか、より柔軟なソリューションが必要な場合は、AWS Resource Explorer と AWS CloudTrail を使って適切なタグが自動的に付けられるようにできます。このブログで説明するソリューションでは、AWS リソースに適切なタグが非同期的に付けられるよう自動化する方法が示されています。これにより、AWS リソースをカテゴリ分けして追跡し、変動するコストを制御・監視できるようになります。 ソリューションの概要 自動タグ付けソリューション（resource-autotagger）は、自動化されたワークフローを使用して、新しく作成されたリソースに必要なタグを適用します。このソリューションでは、AWS Resource Explorer と AWS CloudTrail の 2 つのコアサービスを利用しています。Amazon CloudWatch Events で作成されたルールにより、タグ付けプロセスがスケジュールされます。AWS Lambda 関数と Amazon DynamoDB テーブルは、タグ付けされていないリソースを対応する CloudTrail 作成イベントにマッピングするために動作しています。 前提条件 このソリューションでは、自動タグ付けに AWS Resource Explorer と AWS CloudTrail を利用しています。そのため、これらのサービスをアカウントで有効にする必要があります。ソリューションを展開する前に、次の 2 つのアクションを完了する必要があります。 ・Resource Explorer のインデックス作成を有効にする ・CloudTrail を有効にし、証跡がない場合は作成する 図1: 自動タグ付けソリューション（resource-autotagger）のワークフロー ソリューションフロー ソリューションの動作フローは次のとおりです。 １　Amazon EventBridge スケジューラルールは、新しいリソースが作成されたかどうかを検出するために30分ごとに実行されるように設定されています。 ２　スケジューラルールはLambda関数をトリガーします。 ３　Lambda関数は、Amazon S3バケットに保存されたマッピングファイルをスキャンして、リソースタイプのリストとそのマッピングされたCloudTrailのイベント名とイベントソースを取得します。このデモでは、リソースタイプの一覧には、Amazon EC2、S3バケット、Lambda、Amazon ECS が含まれています。 ４　マッピングファイルからのすべてのリソースタイプについて、Lambda関数はAWS Resource Explorerを使用して、適切なタグ付けがされていないリソースを検索します。 ５　Resource Explorerから返されたリソース識別子ごとに、Lambda関数はステップ4のマッピングファイルを使用して、リソース識別子、CloudTrailイベントソース、CloudTrailイベント名を使用してCloudTrailイベントを参照し、リソースを作成したプリンシパル情報を見つけます。 ６　Lambda関数はCloudTrailイベントから作成されたリソースのプリンシパル情報に基づいてタグリストを生成し、 リソースグループタグ付けAPI を呼び出してリソースに自動的にタグを付けます。 ソリューションのデプロイ 今回初めて AWS Cloud Development Kit (CDK) を利用する場合は、CDKのインストールを行う必要があります。 アプリケーションをローカルマシンにクローンします。 git clone https://github.com/aws-samples/resource-autotagger.git プロジェクトディレクトリに移動します。 cd resource-autotagger AWS Cloud Development Kit (AWS CDK) と Lambda 関数のノード依存関係をインストールします。 npm install AWS アカウントで AWS CDK がまだセットアップされていない場合は、以下のコマンドを実行してブートストラップします。 cdk bootstrap AWS CDK でソリューションリソースをデプロイします。 cdk deploy ソリューションをデプロイした後、数分以内に「Created by」や「IAM Role name」などのユーザー識別タグがリソースに適用されていることがわかります。 他の AWS サービスへのソリューションの拡張 このデモソリューションでは、S3バケット内のマッピングファイルに格納されたマッピング情報に基づいて、Amazon EC2、S3バケット、Lambda、Amazon ECSのリソースに自動的にタグを付けることをカバーしています。このソリューションを他のAWSサービスに拡張するには、マッピングファイルを追加のリソースタイプとそれに対応するCloudTrailのイベント名、イベントソース、およびリソースエクスプローラーのリソースタイプ値で更新する必要があります。 追加のリソースタイプにタグを付けるために必要なAWS IAMの許可は、AWS Lambdaの実行ポリシーに追加する必要があることに注意してください。 例）Amazon API Gatewayリソースの作成タグ付けを追加する手順は次のとおりです。 1. API Gateway REST APIの作成とAPI Gateway REST APIクエリのCloudTrailイベント名、CloudTrailイベントソース、およびリソースエクスプローラーのリソースタイプを特定します。この情報はステップ2とステップ3でマッピングファイルを更新するために必要になります。Amazon API Gatewayの場合、CloudTrailの作成イベント名は “ CreateRestApi “、イベントソースは “amazonaws.com”、リソースエクスプローラーのリソースタイプは “apigateway:restapis” です。 2. Amazon S3コンソールに移動し、”resourceautotagcdkstack-resourceautotagbucket” で始まるS3バケット名を開きます。このバケットには “json” という名前のJSONファイルが含まれています。 3. ステップ1で特定した値を使用して、JSONファイルを次のJSONの構造で更新し、バケットにアップロードします。Globalプロパティは、グローバルに一意のリソース(S3バケットなど)にのみ適用されることに注意してください。”CT”で始まるプロパティはCloudTrailのプロパティを指し、”RE”はリソースエクスプローラーのプロパティを指します。 { "CTEventName": "CreateRestApi", "CTEventSource": "apigateway.amazonaws.com", "REResourceType": "apigateway:restapis", "Global": false } 4. IAM コンソールに移動します。左側のナビゲーションで [ロール] をクリックし、AWS CDK デプロイメントから作成された Lambda 実行用の IAM ロールを検索します。ロール名は ResourceAutoTagCdkStack- で始まります。 5. 許可ポリシーから[許可を追加] をクリックしてから [インラインポリシーを作成] をクリックします。[ポリシーエディタ] 画面でJSONを選択し、次のコードブロックに示されている IAM ステートメントを追加して、Lambda 関数が REST API にタグを追加できるようにします。&lt;region&gt; は、デプロイ先のリージョンに置き換えてください。 { "Sid": "ResourceAutoTaggerAPIGatewayTagging", "Effect": "Allow", "Action": ["apigateway:POST","apigateway:PUT","apigateway:PATCH"], "Resource": "arn:aws:apigateway:&lt;region&gt;::/*/*" } 図2:権限を追加した後のサンプルLambda関数の実行ポリシー 6. 次へをクリックして変更を保存します。 クリーンアップ 自動タグ付け機能をテストした後の課金を避けるために、次のコマンドを実行して、クローンされたリポジトリのルートディレクトリから AWD CDK スタックを削除してください。 cdk destroy 考慮事項 AWS リソースエクスプローラーには、1か月あたり10,000回の検索操作の制限があり、1回のクエリで最大1,000件の結果を返すことができます。これにより、アカウントごとに月間最大10,000,000の AWS リソースにタグを付けることができます。 さらに、AWS リソースには、リソースごとに最大50個のタグを付けることができます。このソリューションでは、既に50個のタグが付いているリソースには指定したタグを追加できません。 現在のソリューションは1つの AWS アカウントに限定されており、複数のアカウントにまたがってタグを付けることはできません。 まとめ このブログでは、AWS リソースエクスプローラーと Amazon CloudTrail を組み合わせて、リソースのタグ付けを自動化する方法を示しました。このソリューションは、既存のワークロードに影響を与えずに、必要なタグを AWS リソースに適用する柔軟で、カスタマイズ可能な代替方法です。サービスコントロールポリシーを有効にする必要はなく、バックグラウンドで非同期に実行されるため、AWS リソースにタグが付けられます。 関連リソース AWSリソースタグ付けの準備、方法と有効なAWSサービス AWS コスト配分タグの使用 属性ベースのアクセス制御 (ABAC) を使用した細かいアクセス制御 AWS リソースのタグ付けのベストプラクティス 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。 著者について Nikhil Enmudi Nikhilは AWS のシニアソリューションアーキテクトであり、サーバーレスソリューションにスペシャリティを持っています。彼は、グローバルな独立系ソフトウェアベンダー (ISV) 顧客のクラウド移行を支援し、ソフトウェア製品向けのソリューション構築を支援しています。 &nbsp; &nbsp; Yohan Supangat Yohanは AWS のソリューションアーキテクトであり、サーバーレスソリューションにスペシャリティを持っています。彼は、エンタープライズの新規顧客と協力し、AWS のテクノロジーとサービスの採用を支援し、ビジネス目標の達成を支援しています。