TECH PLAY

AWS

AWS の技術ブログ

3302

アマゾン ウェブ サービス ジャパン(以下、AWS)は 2024 年 1 月 24 日に、「自治体xスタートアップ・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)のワークフロー ソリューションフロー ソリューションの動作フローは次のとおりです。 1 Amazon EventBridge スケジューラルールは、新しいリソースが作成されたかどうかを検出するために30分ごとに実行されるように設定されています。 2 スケジューラルールはLambda関数をトリガーします。 3 Lambda関数は、Amazon S3バケットに保存されたマッピングファイルをスキャンして、リソースタイプのリストとそのマッピングされたCloudTrailのイベント名とイベントソースを取得します。このデモでは、リソースタイプの一覧には、Amazon EC2、S3バケット、Lambda、Amazon ECS が含まれています。 4 マッピングファイルからのすべてのリソースタイプについて、Lambda関数はAWS Resource Explorerを使用して、適切なタグ付けがされていないリソースを検索します。 5 Resource Explorerから返されたリソース識別子ごとに、Lambda関数はステップ4のマッピングファイルを使用して、リソース識別子、CloudTrailイベントソース、CloudTrailイベント名を使用してCloudTrailイベントを参照し、リソースを作成したプリンシパル情報を見つけます。 6 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 のテクノロジーとサービスの採用を支援し、ビジネス目標の達成を支援しています。
AWS Summit のシーズンが始まります! 4月1日週は AWS Summit Paris 、4月8日週には AWS Summit Amsterdam で、お客様、パートナー、報道関係者の皆様にお会いできるのを楽しみにしています。私はモバイルアプリデベロッパーが生成人工知能 (AI) を使用して生産性を高める方法を説明する予定です。見かけたらぜひお声がけください。 Summit での講演の準備が終わったので、3月18日週の AWS のリリースを振り返り、この要約を書きました。 3月18日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS License Manager を利用することで、 Amazon Relational Database Service (Amazon RDS) で IBM Db2 ライセンスを追跡可能に – 2023 年 12 月に IBM Db2 をリリースしたとき 、私は Amazon RDS についての記事を書き、自分の Db2 ライセンスを使用する必要がある旨をお伝えしました。3月25日より、 AWS License Manager を利用して Amazon RDS for Db2 の使用状況を追跡できるようになりました。 License Manager を利用すると、ライセンスをより良く管理でき、その可視性が高まるため、ライセンスの超過を制限したり、コンプライアンス違反や誤報のリスクを軽減したりするのに役立ちます。 AWS CodeBuild で AWS Lambda のカスタムイメージのサポートを開始 – Lambda コンピューティングで実行するように設定されたプロジェクトのために Amazon Elastic Container Registry (Amazon ECR) リポジトリに保存されている コンピューティングコンテナイメージを使用 できるようになりました。以前は、 AWS CodeBuild によって提供されるマネージドコンテナイメージの 1 つを使用する必要がありました。AWS マネージドコンテナイメージには、 AWS コマンドラインインターフェイス (AWS CLI) 、 サーバーレスアプリケーションモデル 、およびさまざまなプログラミング言語ランタイムのサポートが含まれています。 AWS CodeArtifact パッケージグループ設定 – パッケージリポジトリの管理者は、 複数のパッケージの設定を 1 か所で管理 できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 詳細については、私のブログ記事をお読みください 。 Savings Plans のキャンセル – Savings Plans の購入後 7 日以内であればキャンセルできる機能 を発表しました。 Savings Plans は柔軟な料金モデルで、1 年間または 3 年間の時間単位の一定の支出を確約する代わりに、オンデマンド料金と比較して請求額を最大 72% 削減できます。購入してから間もない Savings Plan がニーズに最適ではないことがわかった場合は、それをキャンセルし、必要に応じて、ニーズにより合った別の Savings Plan を再購入できます。 Amazon EC2 Mac 専有ホストで、サポートされている macOS バージョンの表示が可能に – EC2 Mac 専有ホストでサポートされている 最新の macOS バージョンを表示できるようになりました 。これにより、専有ホストが希望の macOS バージョンのインスタンスをサポートできるかどうかを事前に検証できます。 Amazon Corretto 22 の一般公開を開始 – OpenJDK の機能リリースである Corretto 22 では、デベロッパー向けにさまざまな新機能と機能強化が導入されています。ストリームギャザラーや名前のない変数などの新機能は、より明確でメンテナンスしやすいコードを記述するのに役立ちます。さらに、ガベージコレクションアルゴリズムの最適化により、パフォーマンスが改善されます。同時実行性、クラスファイル、外部関数用の既存のライブラリも更新され、堅牢で効率的な Java アプリケーションを構築するためのより強力なツールキットが提供されます。 Amazon DynamoDB でリソースベースのポリシーと AWS PrivateLink のサポートを開始 – AWS PrivateLink を利用すると、 Amazon Virtual Private Cloud (Amazon VPC) 、 Amazon DynamoDB 、およびインターフェイス VPC エンドポイントとプライベート IP アドレスを使用するオンプレミスデータセンター間のプライベートネットワーク接続を簡素化できます。一方、 リソースベースのポリシー は、 DynamoDB リソースのアクセスコントロールを簡素化するのに役立ちます。リソースベースのポリシーを使用すると、リソースにアクセスできる AWS Identity and Access Management (IAM) プリンシパルと、そのリソースに対して実行できるアクションを指定できます。リソースベースのポリシーを DynamoDB テーブルまたはストリームにアタッチできます。また、リソースベースのポリシーにより、異なる AWS アカウントの IAM プリンシパルとリソースを共有するためのクロスアカウントアクセスコントロールも簡素化されます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加のニュース項目、オープンソースプロジェクト、Twitch の番組をいくつかご紹介します。 British Broadcasting Corporation (BBC) が 25 PB のアーカイブを Amazon S3 Glacier に移行 – BBC Archives Technology and Services チームは、100 年前の重要なアーカイブを一元化、デジタル化、移行する最新のソリューションを必要としていました。同社は Amazon Simple Storage Service (Amazon S3) Glacier Instant Retrieval の利用を開始しました。これは、ほとんどアクセスされず、ミリ秒単位での取得が必要な長期データ用に、極めて低コストのストレージを提供するアーカイブストレージクラスです。計算してみたところ、25 PB のデータを保存するには 2,788,555 枚の DVD ディスクが必要です。DVD の山が高さ 41.8 キロメートル (25.9 マイル) に達するところを想像してみてください! ぜひ全文をお読みください 。 Build On Generative AI – 生成 AI のあらゆるトピックを取り上げる人気の 毎週の Twitch 番組 のシーズン 3 が盛り上がりを見せています。 毎週月曜日、午前 9 時 (米国太平洋時間) にストリーミング配信されます。私の同僚の Tiffany と Darko が生成 AI のさまざまな側面について話し合い、ゲストスピーカーをお招きして、そのデモをご紹介します。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – 冒頭でお伝えしたように、今年も AWS Summit のシーズンがやってきました。 最初のイベントは来週 パリ で開催されます (4 月 3 日)。その後は、 アムステルダム (4 月 9 日)、 シドニー (4 月 10~11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15~16 日)、 ソウル (5 月 16~17 日) と続きます。AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、つながり、コラボレーションし、AWS について学ぶための一連の無料のオンラインおよび対面イベントです。 AWS re:Inforce – ペンシルベニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10~12 日) にぜひご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 3月25日週はここまでです。4月1日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。
ソリューションアーキテクトの池田です。2024 年 3 月 12 日に「 AWS Compute Performance and Efficiency 」を目黒で開催しました。本セミナーでは、Amazon Elastic Compute Cloud (Amazon EC2) をコスト効率よく活用する方法について、海外のスペシャリストも交えて解説しました。インスタンスの選び方や AWS Graviton の活用、Kubernetes 環境での最適化、そして最新事例もご紹介をしました。 本記事では、発表内容の概要と発表資料を掲載しています。 セミナー概要 タイトル: 「 AWS Compute Performance and Efficiency 」 日時: 2024 年 3 月 12 日(火) セッション詳細 9:40 -10:10 「AWS における効率的なコンピュートサービス活用入門」 講師: Senior Specialist Solutions Architect, Compute 宮本大輔 概要: AWS で、Amazon EC2 を中心としたコンピュートサービスを効率的に活用するにはどうしたらよいでしょうか。本セッションでは、スポットインスタンスや AWS 独自の CPU である Graviton の活用を中心に、インスタンスサイズの最適化や Compute Optimizer 、Auto Scaling など、コンピュートサービスのコストを最適化するための幅広い戦略やツールについてご紹介します。 資料 10:10-10:30 「 Graviton Migration Story 」 講師: ASEAN Principal EC2 Specialist, Abhishek Singh 概要: Grab は配車や配送、決済など様々なサービスを東南アジアを中心に展開している企業です。本セッションでは、Grab がいかにして AWS Graviton に移行し、コスト最適化を成功させたかについてご紹介いたします。 本セッションの資料については非公開のため、参考情報を紹介いたします。 過去の関連動画 10:50-11:40 「 Deep Dive AWS Graviton パフォーマンス」 講師: Sr Mgr, Solutions Architecture, Arthur Petitpierre, Solutions Architect 石神 靖弘 概要: Graviton で最大の性能を引き出すにはどうしたらよいでしょうか。本セッションでは Graviton のアーキテクチャ詳細に加え、パフォーマンスを最大化し、コストを最小化するためのポイントについて紹介します。 資料 11:40-12:30 「 Karpenter をもちいた Kubernetes 環境でのコンテナ活用最適化」 講師: Sr. Specialist SA, EC2 Graviton, Wayne Toh, コンテナスペシャリストソリューションアーキテクト 落水 恭介 概要: Kubernetes におけるオープンソースの autoscaler である Karpenter を用いることで、x86 だけでなく、arm アーキテクチャである Graviton を組み合わせたマルチアーキテクチャ環境を構築し、最適化されたコンピュート環境を構築することが可能です。本セッションでは、Karpenter やマルチアーキテクチャコンテナイメージを作成するためのデプロイパイプラインについて、デモンストレーションを交えてご紹介します。 資料 まとめ 本セミナーでは、 Amazon EC2 をコスト効率よく活用するために、インスタンスの選び方、 AWS Gravitonの活用、Kubernetes 環境での最適化、そして最新事例のご紹介もしました。 セミナーにご参加いただいた皆様ありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき今後の AWS 活用の参考になりましたら幸いです。
こんにちは。カスタマーソリューションマネージャーの長倉です。 カスタマーソリューションマネージャーとしてお客様の CCoE をご支援する中で、クラウド人材、 IT 人材の育成に関するご相談を多くいただきます。 このブログでは、ビジネス成果を実現する人材育成計画を立案するためのポイントとして、人材育成計画のゴール設定、現状分析の重要性、実際のラーニングパス作成する上で活用できる AWS のプログラムを、一部お客様の事例とともにご紹介していきます。 人材育成のゴールの設定 人材育成において、ゴール設定はきわめて重要です。人材育成計画を立案する際は、知識やスキルの底上げだけを目的とするのではなく、育成した人材によってどのようなビジネス価値を実現したいのかを明確にすることが肝要です。例えば、「内製要員を中心とした体制で次期システムの AWS 上での構築と運用を実現し、ビジネスアジリティ向上を実現する体制を構築する」というゴールを設定し、ゴールを達成するための目標を「 AWS の運用業務をこなせる人材を現在の5名から15名に増やす」「次期システムの設計ができるアーキテクトを10名育成する」と数値を含めた指標として設定することで、具体的な計画の作成が容易となり、ゴールから逆算しての計画立案が可能となります。また、トレーニング完了後も、目的を達成したかの評価が容易となります。 ゴール設定に当たっては、教育のスポンサーとなる経営陣と十分に協議し、合意形成を図る事が重要です。人材育成計画を立案する部門/担当(例えば CCoE )が、現状の課題を踏まえた人材育成のゴール、それによって実現するビジネス価値について経営陣との合意形成を図ってください。また、ゴールに設定したビジネス価値実現のために育成した人材の実業務やプロジェクトへのアサインが必要となる場合は、計画時点で育成した人材のアサイン計画を経営陣と合意してください。育成した人材を実務にアサインすることで、設定したビジネス価値の実現に初めてつなげる事ができます。 人材育成計画で設定したゴールの達成と学習する文化の醸成には、人材育成への投資やアサイン計画の後押しといった経営陣のバックアップが必要不可欠となります。 現状分析の実施 具体的な計画を立てる前に、人材育成の対象者に対する現状分析を実施し、ゴールとのギャップを特定する必要があります。人材育成対象者の所属部門や役割が異なる場合、習熟度も異なります。個別の状況を考慮した人材育成計画を立てるために現状分析は不可欠です。現状分析の実施にあたって、対象者が少ない場合は有識者によるヒアリングが効果的ですが、対象の人数が多くなるとヒアリングによる把握は困難になるため、アンケートを元にスキルマップを作成する方法が有効です。 AWS では、Web アンケート形式で対象者の AWS に関するスキルや学習状況を収集し、結果をレポートとして提供するツールとして LNA(Learning Needs Analysis) を提供しています。この情報をゴールの検討や組織内のクラウドに関するスキルギャップ特定に活用することができます。教育の定着状況を把握するために、定期的に年次で実施するといった活用も有用です。ご興味のある方は担当の AWS 営業にご相談ください。また、 LNA に関しては AWS ブログ「 LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 」で説明されていますのでぜひご参照ください。 ラーニングパスの設定 設定したゴールと現状分析の結果を元に、どういったギャップがあるかを確認し、それを埋めるラーニングパスを作成します。具体的には、ゴール達成のためにどういったロールの人材が必要になるのか、そのロールにはどういったスキルレベルが必要になるかをブレイクダウンします。ロールと求めるスキルレベルを具体化することで、現状とのギャップがより明確になります。具体化したギャップを埋めるために、どういった研修や学習コンテンツが必要かを検討し、それを組み合わせてラーニングパスを作成していきますが、ロールやスキルレベル別にラーニングパスを検討するのは骨が折れる作業です。 AWS ではロール別/ソリューション別/業種別のラーニングパスを AWS Ramp-Up Guides として公開しています。AWS Ramp-Up Guides では、 AWS Skill Builder のコンテンツや クラスルームトレーニング 、動画やドキュメントを組み合わせ、スキルを習得するためのラーニングパスがまとめられています。それ以外にも、 クラスルームトレーニングのデータシート ではロール別/ソリューション別のスキル習得に必要なクラスルームトレーニング が確認でき、 AWS Skill Builder でも Learning Plan として、ロール別のスキル習得に必要なオンラインコンテンツを活用したラーニングパスがまとめられています。これらの情報を参考にカスタマイズしていくことでラーニングパスを作成ください。 ラーニングパスの作成に加えて、効果的な学習を実施するためには、学習時間の確保/チームとして学びを進める体制/学習のためのコンテンツの用意/学習の途中経過の確認とフィードバック といった点に留意する必要があります。以下で留意いただきたいポイントをご紹介します。 業務時間中に学習時間を確保する 学習のための時間を自主的に確保するのは難しく、また、育成対象者のスキルレベルや学習意欲の違いにより、コンテンツのみを用意して実施を自主性に任せた形式とすると、進捗や習熟度にばらつきが出てしまいます。人材育成のゴールを達成するため、組織全体として人材育成を支援している姿勢を明確に示すためにも、人材育成計画をリードする部門が主体となり、経営層に対して業務時間内に一定の学習時間を確保するよう調整してください。 一緒に学んでいくチーム/コミュニティを作る IPAによる デジタル時代のスキル変革などに関する調査(2022年度)全体報告書 の中で、 IT 人材の学びを阻む障壁として、「共に学ぶ仲間や相談相手がいないために挫折してしまう」という課題が挙げられています。学習時に相談できる仲間がいる事によって、モチベーションを維持して継続的な学習の実施が期待できるだけでなく、学習した内容をアウトプットする機会を持つ事につながり、知識の定着・学習効率のアップが期待できます。また、一緒に学ぶチーム/コミュニティを組成し、その中に講師やメンターを設定することで、習熟度に応じた学び合いが実現できます。育成対象者に加えてメンターや講師をアサインするのが難しい場合もあると思いますが、あるお客様の事例で、学びの各テーマごとに人材育成の対象者どうしで講師を分担するという取り組みをされていました。自分が講師となった領域についてはみなさん積極的に学習されたそうです。その結果、入社歴2,3年の若いメンバーが特定のテーマに詳しくなり、ベテラン社員が若いメンバーの詳しいテーマについて、日常的に質問するようになったそうです。一緒に学んでいくチーム/コミュニティを作ることで、効率的で継続的な学習の実現に加えて、組織全体で人材育成に取り組む文化の醸成につなげる事が期待できますのでぜひご検討ください。 学習のためのコンテンツの用意 人によって最適な学習環境は異なります。効果的な人材育成のためには多様なコンテンツ、学習者の特徴に合わせた環境を用意する事が重要です。知識を体系的に学ぶ学び方を好む方もいれば、手を動かして学びたいという方もいるでしょう。学習者に合わせた様々な学習機会提供の重要性については「 日本におけるデジタル人材育成の現状と推進する上での勘所(後編) 」でも詳しく紹介しているので、ぜひご参照ください。 AWS では学習者の特徴にあわせることが可能な、多様なコンテンツ、トレーニングを用意しています。 クラスルームトレーニング では、短期集中で集合研修形式による AWS の学習が可能です。会社ごとで実施するプライベートトレーニングも提供しておりますので、ご興味のある方は担当の AWS 営業にご相談ください。また、 AWS Skill Builder ではオンラインのコンテンツを提供しており、学習者が自由な時間に好きなコンテンツを選んで学習が可能です。座学でのデジタルトレーニングに加えて、学習者が楽しんで学べる「 AWS Cloud Quest 」「 AWS Industry Quest 」といったゲームベースで学習ができるコンテンツや、演習用の AWS アカウントが払い出され、 AWS サービスに触れてみることができるハンズオンラボである AWS Builder Labs 、個人またはチーム単位で発生する様々な課題(セキュリティ、インフラ、 DevOps 、 ML 、サーバレスなど)を解決してスコアを競う実践的な演習の「 AWS Jam 」といったコンテンツがあります。「 AWS Jam 」は、チーム対抗で課題解決を目指す「 AWS Jam イベント」と、個人で解決を目指す「 AWS Jam Journey 」が用意されており、実際の AWS 環境で発生する障害や課題の解決に取り組んでいくコンテンツとなっています。詳細な説明や、解決策が提示されない中、個人・チームで試行錯誤しながら課題を解決していきます。課題には難易度ごとにスコアが設定されており、スコアを競いながら実際の業務で発生する障害対応や、各種課題の解決を手を動かしながら体験できる事で、実践力を強化するとともに、 AWS スキルの可視化が可能となります。同様のコンテンツとして、「AWS Jam」がクラスルームトレーニングの一環としても提供されております。ご興味のある方は クラスルームトレーニングのデータシート から全コースのデータシートをダウンロードすることでご確認いただけますので、ぜひご確認ください。 演習の実施が難しい場合は、メンターの十分なフォローの元、実務の実施を人材育成計画に組み込むのも効果的です。学習者に合った多様な学習コンテンツの提供とチームで学ぶ機会を適切に組み合わせていくことが、人材育成の成功につながります。 学習の途中経過の確認とフィードバック 人材育成の進捗と効果を測るために、第三者が客観的に評価できる基準を設定することが重要です。学習過程で定期的に理解度やスキル習得度を確認していき、基準を満たしていない場合は計画を見直し、目標達成に向けた改善を図ります。評価基準の例として、認定資格の取得や有識者によるスキルレベルのチェックが挙げられます。 AWSでは 認定資格/認定試験 を用意しています。認定資格の取得をラーニングパスに組み込む事で、人材育成の進捗を測れるようになるだけでなく、社内のクラウド知識とスキルの見える化を実現できます。また、認定資格/認定試験の内容は定期的にアップデートされるため、テクノロジーの進化へも対応が可能となるため、活用をご検討ください。 業務へのアサイン/経営陣との合意 ラーニングパスに基づいた学習の完了後、計画段階で合意した育成した人材の実案件やプロジェクトへのアサインを実施してください。人材育成が計画通りに進まなかったり、プロジェクトが予定通りに始まらないといったケースもあると思います。こういったケースで育成した人材のスキルが活かされない状況が発生しないように、学習の途中経過とあわせて、定期的に経営陣と人材育成の状況を報告・共有し、実案件へのアサイン計画についても状況に変化に対応できるよう調整を続けてください。人材育成をビジネス価値の向上につなげている事例として、 オムロンソフトウェア様のクラウド人財育成の取り組み があります。オムロンソフトウェア様では、トレーニングで獲得した知識をすぐに試せるように、事業部の壁を超えてクラウド案件に人財をアサインされています。スキルを高めるためのサポートは、独自の能力開発制度体系を用意し、職種別に必要な知識・スキルの習得を可能にする支援を行っており、特に重視されているのが、実践をとおして現場で使える技術を早期に身に付ける事と考えておられます。その他のお客様によるトレーニング実施の事例も、 お客様インタビュー – クラウド人材育成 でご確認いただけますのでぜひご参照ください。 学習する文化の醸成 継続して学習を実施していくため、学びによって得られた成果を業務評価につなげる事が大切です。評価につながる事により、各自の学習意欲が高まるという好循環につながります。ただし、その実現は簡単ではありません。人材育成計画検討部門(人事部や CCoE )が中心となり、人材育成の計画段階から、経営陣と密に連携を取りながら、学習によって発揮できる成果とその評価方法を明確化することが重要です。 学習の成果が適正に評価されることで、自律的なスキルアップの文化が生まれます。組織全体で学びを推進するための仕組みづくり(例えば人材育成の成功体験を共有会やイントラネットを活用して社内で共有)ができれば、自律的にスキルアップしていく文化を組織として醸成できるようになります。 現場主導での学習 ここまで、人材育成のゴールを設定し、教育の成果としてビジネスバリューを発揮するために経営陣と合意して実際の業務にアサインすることの重要性をご紹介させていただきました。一方で、経営陣と合意して大規模に教育を推進するのは難しいが、現場の取り組みとして教育を推進していく必要がある、というケースもあると思います。こういったケースでも、人材育成のゴールを設定し、現状分析を行ったうえでラーニングパスを設定するというプロセスは同様に有効です。ゴールの設定や、現状分析、ラーニングパスの設定は社内の有識者や既にスキルを保有している方の歩んできた道のりを参考としたうえで検討してください。また、学習にあたっては、チーム単位で勉強会を開催し、先に紹介させていただいたように相互に講師を務めるといった取り組みを実施し、各人が積極的に参加できる仕組みをぜひご検討ください。 まとめ 人材育成計画を実現するうえでのゴール設定と学習していくための仕組みづくりの重要性についてご理解いただけたと思います。経営層を含む関係者とゴールを共有し、現状とのギャップを洗い出すことができれば、そのギャップを埋める手段としてのコンテンツは AWS から多数提供されていますので積極的に活用ください。 IT 技術、特にクラウドサービスの技術の進歩は早いため、最新の動向を把握し、より効果的にクラウドを活用してビジネス価値を最大化するには、計画した期間の学習が終わったら完了ではなく、継続して学び続ける必要があります。継続して学び続けるための仕組みづくりを人材育成計画検討部門が推進していってください。 参考リンク LNA(Learning Needs Analysis) LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 AWS Ramp-up Guides AWS Skill Builder クラスルームトレーニング クラスルームトレーニングのデータシート Learning Plan デジタル時代のスキル変革などに関する調査(2022年度)全体報告書 日本におけるデジタル人材育成の現状と推進する上での勘所(後編)AWSトレーニングデータシート AWS Cloud Quest AWS Industry Quest AWS Jam AWS 認定 オムロン ソフトウェア株式会社:グループのデジタル戦略実現に向けて AWS 人財を育成。半年間のトレーニングで 7 名が AWS 認定 5 冠を取得 お客様インタビュー – クラウド人材育成 今から始める CCoE、3 つの環境条件と 3 つの心構えとは CCoEブログ 著者 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネジャー 長倉隆浩
イントロダクション 今日のデジタル時代において、クラウドへの移行は「なぜやるのか」ではなく、「いつやるのか」というトピックになりました。インフラコストの削減以外にも、クラウドには柔軟性、機動性、信頼性の向上など多くの利点があります。しかし、クラウド移行には多くの利点がある一方で、進捗を妨げる予期せぬ費用が発生する可能性もあります。移行コストは、組織の規模、アプリケーションの複雑さ、移行プロセスの期間によって大きく異なります。さらに、現在の経済状況下では、限られたIT予算と効率性の必要性がクラウド移行の取り組みをさらに複雑にしています。 このブログでは、大規模な企業のクラウド移行におけるコスト削減戦略について考えていきます。 クラウド移行を開始する前に クラウド移行を成功させるためには、組織全体の利害関係者を結集させるビジネスドライバーを特定することが不可欠です。これには、移行プロジェクトの範囲、利点、およびタイムラインを概説したデータドリブンなビジネスケースを作成する必要があります。移行タイムラインをデータセンター退去などの具体的なビジネス成果と合わせることで、進捗状況を評価する具体的な基準が得られます。 AWS Migration Evaluator などのツールを活用して、コスト効率の良い移行のための説得力のあるビジネスケースを作成してください。 クラウド移行の複雑さに立ち向かうことは大変な作業ですが、適切なパートナーがそばにいれば、その旅路は容易で報われるものになります。AWSは、顧客の移行コストを軽減するために、 AWS Migration Acceleration Program (MAP)を提供しています。AWS MAPは、ツール、ベストプラクティス、 AWS パートナーネットワーク (APN)へのアクセス、および移行への投資を提供します。プログラムの早期段階からAWSに相談することで、クラウドマイグレーションジャーニーの各ステップを確認し、最適化されたアプローチを確保することができます。 MAPでは、移行に3ステップのアプローチ(図1参照)を推奨しています。Assess(評価)、Mobilize(準備)、Migrate &amp; Modernaize (移行とモダナイズ)です。 図1 – AWS MAPの3ステップアプローチ 評価フェーズ このフェーズの目標は、クラウドで運用する組織の準備状況を評価することです。 現在のオンプレミスのIT資産(Assets)を理解することは、移行作業とクラウドコストを見積もるために不可欠です。移行を検討する際に組織が直面する一般的な問題の1つが「ダブルバブルコスト」であることを覚えておいてください。このバブルは、組織が現在のオンプレミスインフラの費用を負担しながら、新しくクラウド移行のコストが発生することで形成されます。 インフラストラクチャの組み合わせに基づいて適切なディスカバリーツールを選択するには、 AWS規範的ガイダンス を参照してください。ディスカバリーには、移行計画時に見落とされがちな、サードパーティのライセンスコストの評価を含める必要があります。AWS MAPには、ライセンスコストを理解するための実証済みのフレームワーク「 Optimization and Licensing Assessment (OLA)」が含まれており(図2参照)、クラウドネイティブで費用対効果の高い代替案を提供します。多くのAWSの顧客がOLAを活用することで、大幅なコスト削減を実現しています。この包括的な発見は、(1)コミットメント支出に基づいた割引価格を提供するAWSホスティングプラン(Savings plansとリザーブドインスタンス)の選択、(2)移行の加速と「ダブルバブルコスト」の削減のための移行計画に役立ちます。 古い機器の保守コストを削減することで、ダブルバブルコストを軽減する別の選択肢は、ReluTechなどのAWSパートナーが提供するIT売却のアプローチです。このアプローチには、ITメンテナンスの外部委託、高額なITリフレッシュの回避、オンプレミスアセットの購入とリースバックなどのコスト削減戦略が組み込まれており、顧客がクラウドへの移行を迅速かつ費用対効果の高い方法で行えるようサポートします。 &nbsp; 図2 – ライセンス: 移行コスト削減の大きな要因 次のステップは、クラウドへの移行と運用の準備状況を評価することです。 AWS Migration Readiness Assessment (MRA) は、ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、運用の6つの AWS Cloud Adoption Framework (CAF) の柱に沿って組織を評価する無料のワークショップです。MRAの出力には、特定された課題に対処するための計画と、 AWS Learning Needs Analysis (LNA) などの追加ワークショップの推奨事項が含まれます。LNAはAWSスキルの準備状況を評価し、カスタマイズされた学習計画を推奨します。AWS Immersion Daysは、移行イニシアチブに参加する従業員にクラウドサービスのハンズオントレーニングを提供します。 詳細なポートフォリオの発見、ホスティング計画、およびMRAの出力により、プログラムはモビライズフェーズに移行する準備ができます。 モビライズフェーズ このフェーズの目標は、移行のためのベースラインとなるクラウド環境を構築し、再現可能な移行パターンを持ったアプリケーションの移行戦略を策定することです。 これには、(1)クロスファンクショナルチームであるCCoE(Cloud Center of Excellence)を設立し、クラウド移行におけるガバナンスとベストプラクティスを標準化する。(2)適切に設計された基礎となるクラウド環境(ランディングゾーン)を構築する。(3)評価フェーズで実施したMRAから特定されたギャップに対処する ことが含まれます。 組織はこの段階で、初期のワークロードの選択と移行の順序付け、移行戦略の曖昧さ、セキュリティとコンプライアンスのフレームワーク、有識者や専門家の有無など、潜在的な障害に気づく必要があります。これらの懸念に早期に対処することで、分析の停滞を防ぎ、移行の期限を守ることができます。 AWS Experience Based Acceleration (EBA)は、アジャイルでハンズオンのアプローチで、摩擦点と障害を解決することを目指しています。EBAでは、お客様の主要な意思決定者とAWSの専門家が集中的なワークショップ環境に集まり、「実際にやってみて証明する(do it to prove it approach)」アプローチで障害を解決するのを支援します。プラットフォームEBAと移行EBAを組み合わせると、モビライズフェーズの目標を達成するのに最適です。プラットフォームEBAでは適切に設計されたランディングゾーンを作成し、移行EBAではいくつかのアプリケーションを素早く移行してランディングゾーンをテストします。CCoEは引き続きガードレールを見直し、繰り返し可能なパターンを確立し、コスト最適化の管理を実装します。 社員の余力や専門知識が限られている場合は、AWS MAP パートナー資金調達プロセスを活用して、適切に設計されたランディングゾーンと繰り返し可能な移行アプローチの構築に関連するコストを、AWS Professional Services またはAWSパートナーを起用して補填することができます。 この段階で最も重要な活動の1つが移行のwaveの計画です。事前に移行のwaveを計画しておくと、チームが移行プロセスに慣れるにつれ、プロジェクトがスムーズに進むようになります。 適切に設計されたランディングゾーン、テスト済みの移行アプローチ、移行のwaveの計画ができれば、移行を加速させる時が来ます! 移行フェーズ このフェーズの目標は、ダブルバブルコストを抑え、ビジネスケースで概説されているクラウド導入の利点を実現するために、ワークロードをクラウドに迅速に移行することです。 AWS Cloud Migration Factory は、ワークロードをAWSに大規模に移行するための移行ガバナンスと自動化レイヤーです。Maydenは、AWS Cloud Migration Factoryを活用して、6週間でAWSに300台のサーバーを移行しました。 AWS Application Migration Service や AWS Database Migration Service (DMS)などのAWSツールを活用して、ビジネス運用を中断することなく移行を迅速化し、コストを削減します。これらのツールは幅広いアプリケーションをサポートしており、追加の投資は必要ありません。また、段階的な価格設定オプションが用意されています。 最初は小さく始め、その後の各waveで移行の速度を上げていくことを計画します。最初のwaveでは、単一のアプリケーションまたは依存関係の少ないアプリケーションから始めます。複雑なアプリケーションは後続のwaveに加えることで、チームが学習し調整する時間を確保できます。さらに、チームはプロセスの改善を特定し実施して、後続のwaveの速度を上げることができます。 移行が進行中は、AWS Cost Optimization の専門家と定期的に打ち合わせを行い、コスト削減の機会を確認することが重要です。 また、この時点で次の大きなステップである「モダナイゼーション」を開始することも重要です。 移行とモダナイゼーションの両方が、継続的なコスト最適化と、クラウドの利点を完全に実現するためのキーです。(図3参照)。 図3 – マイグレーションとモダナイゼーションは、クラウドの恩恵を完全に実現するために重要 まとめ 企業のクラウド移行を主導することは難しい課題ですが、実証されているコスト削減戦略を活用することで、成功の可能性を最大化できます。 このブログで参照されているAWSクラウドサービスの詳細については、以下のリンクを参照してください。 ・ Cloud Migrations Services on AWS ・ AWS Migration Evaluator ・ AWS Migration Acceleration Planning (MAP) ・ AWS Migration Readiness Assessment (MRA) ・ AWS Optimization and Licensing Assessment (OLA) ・ AWS Learning Needs Analysis (LNA) ・ AWS Cloud Adoption Framework (CAF) ・ AWS Experience Based Acceleration (EBA) ・ AWS Application Migration Service ・ AWS Prescriptive Guidance Strategy and best practices for AWS large migrations 翻訳はソリューションアーキテクトの柳 嘉起が担当しました。原文は こちら です。 著者について Sai S Jeedigunta Sai S Jeedigunta Sai Jeediguntaは、AWSのシニアカスタマーソリューションマネージャーです。クラウド変革の取り組みを推進し、クラウドの恩恵を実現するために、経営陣や部門横断的なチームとパートナーシップを組むことに情熱を注いでいます。20年以上にわたり、大手企業向けのIT インフラストラクチャ関連の業務を主導してきました。 Joe Rader Joe Rader Joe RaderはAWSのシニアカスタマーソリューションマネージャーで、2020年から在職しています。Joeは、お客様がクラウドで成功を収められるよう支援し、長期的な成功に焦点を当て、常にコスト削減を意識しています。Joeには30年以上のIT経験があります。
強烈なインパクトを残したイベント Amazon Web Services (AWS) re:Invent 2023 を振り返ってみると、今年の会議がネバダ州ラスベガスで開催されたことは、自動車および製造業界にとっては特に革新と先進思考の中心であったことが明らかです。このダイジェストでは、イベント中に発表された豊富な情報と発表を詳細に確認しつつ、特に自動車産業を前進させることができるコンテンツについて整理しています。 AWS の自動車および製造業界ビジネスユニット (IBU) チームの洞察に富んだブレイクアウトセッションから、ワークショップやチョークトークで実証された実用的なアプリケーションに至るまで、 re:Invent 2023 で提供されたリソースは、自動車分野の進化する課題に対処するためのものです。このダイジェストは、業界が安全で持続可能でお客様中心のモビリティの未来に向かって加速するために、変革のナビゲートについて考え、今後お客様にとっての優れたモビリティ体験を保証します。 AWS では、独自のコラボレーションとイノベーションを通じて、持続可能で安全なモビリティ、製品、サービス、ソリューションの提供を加速し、お客様が変革の課題を解決するのを支援することに尽力しています。 AWS 内の自動車および製造業界ビジネスユニット (IBU) は、複数の大手 OEM 、 Tier1 、お客様、パートナーと協力し、 8 つの戦略的ワークロードに焦点を当てています。このブログ投稿では、 re:Invent で発表された自動車および製造業界に関連する発表を 8 つの戦略的ワークロードに分けて紹介しています。各セクションの中で re:Invent セッションで録画があった場合はそのリンクを記しています。 ソフトウェア定義車両 (SDV) ソフトウェア定義車両 (SDV) の分野は、車両のソフトウェアを再構築し新しいモビリティソリューションに不可欠なサービスへのアクセス、理解、使用、更新を改善するユースケースに触れています。 AWS の次世代クラウドファーストのインテリジェントなコードパイプラインに対するビジョンを概観する AUT102 ブレイクアウトセッションでは、 Traton と Volvo が製品化までの時間を短縮し、車両からクラウドへの連続性を維持することで開発コストを削減している方法について学ぶことができました。この連続性は、異なるコンテキストに車両の機能を分割し、開発ワークフロー内で Amazon Elastic Cloud Compute (Amazon EC2) インスタンス用の BlackBerry QNX AMI を利用しています。これらの革新により、チームはバグを早期に特定し、コード品質を向上させ、ハードウェア・イン・ザ・ループ (HIL) システムへの依存を減らすことができます。これは業界におけるシフトレフトアプローチへの証です。 チョークトークセッション AUT203 では、クラウドネイティブなツールと仮想化されたターゲットを使用した加速とスケールアップについて、車両へのデプロイ前にクラウドでコードを構築しテストするための、 SDV アーキテクチャ向けの最新クラウドネイティブ革新が紹介されました。ディスカッションの焦点は、仮想エンジニアリングワークベンチ、仮想電子制御ユニット、 CI/CD パイプラインであり、 Amazon CodeWhisperer を使用した生成型人工知能(生成 AI )が生産性向上にどのように役立てられるかを示すユースケースについて深く掘り下げました。オリジナル機器メーカー (OEM) と様々な階層のサプライヤーは、 SDV の現在の採用状況を議論し、チョークトーク中に今後の取り組みを概説しました。 AUT301 ワークショップ 「 Automotive software development with Virtual Engineering Workbench (VEW) 」には、 100 人以上の開発者とアーキテクトが参加しました。このワークショップでは、 AWS 上で車載グレード評価機能を構築しテストする方法を実演しました。参加者が事前に設定された AUTOSAR &QNX ランタイム環境を作成し、 AWS Service Catalog に公開しました。 VEW セルフサービスポータルから、ユーザーは事前に設定された AUTOSAR & QNX 環境を選択し、ログインしてデモ車両機能アプリケーションを開発しました。参加者はその後、仮想ターゲット(仮想 ECU )上で車両アプリケーションを統合・実行し、 Amazon EC2 インスタンス上で機能を検証しテストしました。さらに、 VEW のエンドツーエンドのビジョンについて議論し、 OEM の特定の要件とワークフローに合わせて拡張・カスタマイズする方法を提供しました。 ライトニングトーク AUT103 「 Accelerate automotive cockpit development with Panasonic SkipGen on AWS 」では、 Panasonic SkipGen on AWS Graviton が自動車コックピットドメインコントローラーの開発を革命的に進化させる方法について深掘りしました。これにより SkipGen は業界に変革をもたらし、 AWS 上で完全な現代のコックピットソフトウェア開発、コンピューティングオフロードおよび 大規模なテストを可能にしました。 AWS は、クラウドネイティブな Software Developer Workbench がどのように拡張し、 SDV 時代の車両ソフトウェア開発を加速しているかについてのデモを示しました。自動車業界のパビリオンでの体験では、 BMW i7 車両の開発に関する情報を含む 8 つのデモを AWS が展示しました。 自動運転モビリティ 自動運転モビリティ分野では、 AWS は Amazon が長年にわたり自律システム、ロボティクス、機械学習において蓄積した経験を活用し、自動運転車の開発を加速していることについて触れました。 ブレイクアウトセッション AUT202 では、 BMW が Qualcomm と協力してクラウド上で次世代の高度自動運転開発プラットフォームを開発する方法についての事例が講演されました。 ブレイクアウトセッション AUT206 では、 Torc Robotics が AWS 上でデジタルテストプラットフォームを作成し、シミュレーションで何百万マイルものテストを実行し、レベル 4 の自動運転機能のテストカバレッジを最大化する方法について掘り下げられました。このセッションでは、 AWS の管理サービスを使用してプラットフォームを設定する方法について話されました。講演者は、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Simple Storage Service (Amazon S3) を使用してプラットフォームを設定する方法、直面した技術的な課題、学んだ教訓、および実装されたソリューションの結果としての利点について詳しく説明しました。 次世代トラッキングに関するブレイクアウトセッション PRO301 では、「 Iveco が AWS を使用して自動運転のための生成 AI を活用し、安全性と効率性の新たな高みを実現する方法」について紹介しました。このビジョンを実現するため、 Iveco は AWS 上で構築された生成 AI 技術を利用して、ドライバーと車両の関係を再定義しています。 AWS プロフェッショナルサービスの協力のもと、 Iveco はプライバシーに準拠したフリートデータにカスタマイズされた生成モデルをトレーニングし、ドライバー体験を向上させています。 チョークトークセッション AUT302 では、自動運転開発における生成 AI と 自然言語処理 (NLP) に基づくシーン検索に焦点を当てました。このディスカッションでは、自動運転機能の開発において直面する最も重要な課題について詳しく議論しました。ペタバイト規模のデータから、トレーニングやテストに関連するシーンを特定するために、生成 AI を使用する方法についてのインサイトが説明されました。またこのチョークトークでは、参加者は生成 AI がシーン選択を加速し、低頻度なイベントや意味的に類似したシーンを特定する方法を学びました。これらは、 ML トレーニング、テスト、検証などの下流タスクで使用されます。 ビルダーセッション AUT303 では、 ADDF ソリューションにおいて、モデルトレーニングのためのシナリオ内にオブジェクトを追加するために生成AIを使用しました。自動車メーカーは通常、自動運転や高度自動運転機能の開発のために車両テストフリートから何百ペタバイトものドライブデータを収集しますが、 ML エンジニアがコーナーケースに対してモデルをトレーニングするために必要になる正確なシナリオを記録していないことがあります。このビルダーセッションでは、生成 AI を使用して、停止標識などのイメージやオブジェクトを既存のシーンに追加する方法を実演しました。 デモブースでは、 お客様がクラウドで高度に自動化された運転機能を開発する際にサポートするための様々なツールを展示しました。他にもデータの取り込み、データの前処理、シーン生成、シーン検索、大規模な再シミュレーションのサポートに使用される AWS サービスが紹介されました。 接続モビリティ 接続モビリティ分野では、 AWS のお客様は、データの力を活用して、インテリジェントでパーソナライズされた機能や収益を生み出すモビリティサービスを構築しています。 AWS IoT FleetWise チームは、車両ビジョンシステムデータの収集をサポートすることを 発表 し、お客様がカメラ、 LiDAR 、 Radar などのビジョンサブシステムからメタデータ、オブジェクトリストと検出データ、画像やビデオを収集できるようにしました。 特に好評だったブレイクアウトセッション ALX201 は、車内ボイスエクスペリエンスをコンセプトから現実に変えることに焦点を当てました。参加者は、 BMW が独自の次世代 AI ボイスアシスタントを構築し、車内ボイスエクスペリエンスを新たな高みに引き上げる方法を学びました。インターネット接続に関係なく、埋め込み型ニューラルテキストトゥスピーチ SDK を展開することで、 BMW のクラウド環境を強化し、お客様に途切れのない自然なボイスエクスペリエンスを提供したことについて学びました。 別のブレイクアウトセッション IOT 204 では、 AWS IoT Connected Vehicle (CV) プラットフォームを使用した接続車両プラットフォームの革新と近代化について掘り下げました。このセッションでは、 AI による保証と修理通知、ライブビデオストリーミングと再生、 EV バッテリーの健康監視などの革新的なアプリケーションの可能性を強調しました。 American Honda Motor Company は、 AWS IoT Core への移行についてを共有し将来の革新に向けた計画を概説しました。 ANT 317 セッション「電気自動車からのリアルタイムアナリティクス構築」では、 Rivian が AWS 上での接続モビリティユースケースを共有しました。 Rivian の車両データプラットフォームは、デジタルコマース、保険、先進運転支援システム、車両の信頼性、スマート診断、充電、車両サービスなど、様々なドメインをサポートする基盤サービスとして機能しています。 ブレイクアウトセッション IOT 309 「 AWS IoT Core を使用してアプリケーションを革新する – MQTT 5 」では、 MQTT 5 の概要を説明した後、接続された車両のユースケースを探求しました。参加者は、 MQTT のパブリッシュおよびサブスクライブメッセージ機能を使用して、潜在的に断続的なネットワーク接続で通信する方法を学びました。またライブデモでは、共有サブスクリプションを使用してフリートとアプリケーションをスケールする方法を紹介しました。 デモエリアでは AWS Connected Mobility Solution 2.0 (CMS) を展示しており、大規模な接続モビリティインフラの開発、展開、管理がどのように容易になるかについて触れていました。 デジタルカスタマーエンゲージメント デジタルカスタマーエンゲージメント (DCE) の分野では、 AWS はお客様がパーソナライズされたマーケティングコンテンツ、没入型デジタル体験、リアルタイムデータ分析を通じてお客様エンゲージメントを増加させるのを支援しています。これには、広告、ファイナンス、アフターサービス、リピート購入体験など、所有のライフサイクル全体とお客様の旅にわたる様々な側面が含まれます。 AIM 206 ブレイクアウトセッション「 Generative AI で価値とビジネス成果を実現する」では、 AI と人間の心の融合、技術進歩によって駆動される急激なイノベーションについて発表しました。このセッションでは、 Ferrari が DXC Technology と AWS と共に生成 AI を探求している方法、生成 AI の導入における主な障害、メインストリームの導入に焦点を当てるべき分野、内部および外部の消費者の両方に対する価値ストリームマッピングを構築する方法を学びました。 チョークトークセッション AUT 204 「 Generative AI で未来へと進む」では、 AWS Generative AI Innovation Center の専門家によって提示されたように、 Amazon Bedrock と Amazon CodeWhisperer がプレセールスからポストセールスまでのお客様旅行全体のデジタル体験を強化するためにどのように採用されているかについて議論しました。 デモエリアでは、コールセンターから予測保守に至るまで生成 AI がデジタルお客様体験をどのように強化しているかが披露されました。 製造 製造 業界では、 AWS はショップフロアからのデータをキャプチャ、分析、視覚化することにより、製造業務と全体的な設備効率を最適化しています。 AIM 216 ブレイクアウトセッション「大規模な予測保守」では、 Amazon Monitron を用いた Koch Ag &amp; Energy Solutions (KAES) のジャーニーが共有されました。予期しない機器の故障は産業施設にとってコストがかかる一方、保守を頻繁にスケジュールすることは資源の無駄遣いです。このセッションでは、 Koch AG から、彼らが Amazon Monitron を活用して産業用機械に予測保守を実装する方法について聞くことができました。 チョークトークセッション AIM240 「 Amazon Q で従業員に生成 AI の力を提供する」では、 Amazon Q が従業員に生成 AI の力への安全かつ迅速なアクセスを提供する方法を実演しました。 Amazon Q は自然言語を理解し、接続されたデータソースを使用して文脈に沿った回答を提供し、ドキュメントを要約し、コンテンツを生成し、企業アプリケーションやドキュメントリポジトリ全体でアクションを自動化することができます。これはショップフロアアプリケーションでの作業者ガイダンスの実装に特に有用です。 サプライチェーン AWS は、 re:Invent 2022 で AWS Supply Chain サービスを発表しました。このサービスは、機械学習 (ML) を活用したサプライチェーンアプリケーションによりリスクを軽減し、コストを削減します。お客様は、生産プロセス全体を追跡し追跡するために必要なエンドツーエンドのサプライチェーンの可視性を得ることができ、前例のない効率性を実現します。 AUT207-INT インダストリアルイノベーションセッションでは、自動車、航空宇宙、消費者電子機器を含むさまざまな産業分野のクラウドインダストリアル企業が、ビジネスを再創造し、運用を最適化し、市場投入までの時間を短縮し、新しい収益ストリームを生成するために、データとクラウドテクノロジーをどのように活用しているかが紹介されました。 Siemens 社は、 AWS を活用した Xcelerator インダストリアルソフトウェアポートフォリオや新しい工場自動化の提供を行い、 Industrial Metaverse 内で仮想工場を構築した方法について発表しました。 Honda は、日本と北米で AWS との協業について議論しつつ製品開発、サプライチェーン、製造全体での革新を加速する計画を語りました。 製品エンジニアリング AWS は、製品開発者やエンジニアが AWS 上の ハイパフォーマンスコンピューティング (HPC) 、モデルベースの設計、大規模並列シミュレーションを使用して複雑な問題を解決することを支援しています。 MFG 106 ブレイクアウトセッションでは、 トヨタモーターノースアメリカ と Autodesk の登壇者が、人工知能がどのように計算集約的なシミュレーションとモデリングを迅速化し、製品設計とデジタルエンジニアリングを加速させ、最終的に市場投入までの時間を短縮するかについて議論しました。 持続可能性と EV (電気自動車) 電気自動車 (EV) では、バッテリーが持続可能性とコストにおける最大の要因です。チョークトークセッション AUT 201 「バッテリーデジタルツインの力を解き放つ」では、物理的なバッテリーシステムの仮想表現であるバッテリーデジタルツインモデルが紹介されました。このセッションでは、 Mahindra と Our Next Energy がリアルタイムの車両バッテリーデータを機械学習アルゴリズムやデータ分析と組み合わせて、バッテリー性能の最適化、バッテリー寿命の延長、故障の検出、安全性の向上を図る方法を追求しました。 ワークショップ IOT 305 「 AWS IoT を使用した EV バッテリーの異常検出」では、電気自動車 (EV) バッテリーの異常を早期に検出するソリューションがデモンストレーションされ、参加者は車両のフリートの管理、プロビジョニング認証、車両モデリング、キャンペーン作成、データの取り込み、および洞察のためのダッシュボードの設定において実践的体験ができました。 デモエリアでは、 お客様が AWS 上で高度にスケーラブルで低遅延の OCPP EV 充電 CPO ソリューション を構築するのに AWS のサービスがどのように使用されているかを示しました。別のデモでは、 AWS がバッテリーサーキュラーエコノミー内のステークホルダー間の透明性と信頼性にどのように貢献しているかを示しました。さらに、 AWS はバッテリーデジタルツインを使用してバッテリー性能の最適化、バッテリー寿命の延長、 EV 効率の向上を実現する方法をデモンストレーションしました。 結論 AWS は、 re:Invent 2023 で 8 つの戦略的ワークロード領域における革新とお客様の成功事例を発表しました。 AWS は、中国リージョンで展開する OEM (オリジナル機器メーカー)にとってのプリファードクラウドプロバイダーとなり、対象として SAIC や BYD を含むといった発表がありました。 AWS for Automotive チームは、お客様と共に、またお客様のために革新を続けています。他の re:Invent 2023 の発表 に最新の情報については、 AWS for Automotive のページを探索するか、今すぐ担当の AWS チームにご 連絡 ください。 このブログは「 Recap of AWS re:Invent 2023 for the Automotive Industry 」と題された記事の翻訳となります。 翻訳は Solutions Architect Leader のショーン・セーヒーと Solutions Architect の佐藤高士が担当しました。
現代の車は単なる交通手段を超えて、つながったモノのインターネット (IoT) デバイスに進化しており、従来の車における所有と使用のあり方を再定義しています。 このビジョンの変化は、移動に関連する課題の解決方法を変えています。自動車産業は、スマート充電、バッテリーの状態監視、予知保全、フリート管理、循環型経 済などの課題に対処するために、人工知能 (AI) による「デジタルツイン」を活用しています。 デジタルツインとは、物理的なシステムを仮想的に表現することであり、データを動的に更新して物理システムの構造、状態、振る舞いを模擬します。 Amazon Web Services (AWS) は、デジタルツインの使用事例の幅広さを考慮して、顧客が使用事例を分類しデジタルツインを大規模に構築および展開するために必要なサービス、技術、データ、モデルを理解するのを支援するために、 4-level index を提案しています。 2022 年、Management- und IT-Beratung GmbH ( MHP ) は AWS との戦略的協業契約 を発表し、モビリティと製造業におけるクラウドの変革をさらに支援することになりました。MHP は、モビリティと製造環境における長年の専門知識をもつ AWS のアドバンスドティアサービスパートナー であり、クラウド戦略、アーキテクチャ、開発、移行、運用の課題に焦点を当てて協力しています。 この記事では、MHP が AWS と協力して電気自動車のレベル 4 デジタルツインを構築し展開する取り組みをご紹介します。具体的にはライブデータ、フリートの知識、AI を活用して電気自動車 (EV) のバッテリーを監視および分析する手段についてです。 フリートからドライバーの振る舞い(ドライバーツイン)とバッテリーの特性(バッテリーツイン)を学ぶことによってバッテリーの健康状態とパフォーマンスの管理を行う事例をご紹介します。また、業界における課題についても触れ、AWS 上で構築および展開された技術的なソリューションとリファレンスアーキテクチャについて深掘りします。 電気自動車のバッテリーに関する課題 電気自動車のバッテリーの管理と最適化は、バッテリー製造業者、自動車メーカー (OEM) 、および利用者の全てにとって重要です。 電気自動車のバッテリーに関して、最適な長期健康状態と残存価値に向けてどのように充電するかの最適解を導き出すのは難しいです。なぜなら、それぞれの電気自動車は異なる環境条件や使用パターンに晒されているからです。 結果として、各バッテリーそれぞれの具体的なサービス履歴に基づいて個別に運用性能を計算する必要があります。バッテリーの状態 (SoH) や充電状態 (SoC) などの特性をモニタリングし予測することで、航続距離の懸念や予知保全、残存価値、および再利用などの課題に対処できます。 現在、バッテリーのこれらのパラメータを計算するために開発された物理ベースのモデルには、2 つの主な問題があります。精度が低いことと、計算コストが高いということです。これらのモデルは、ドライバーの振る舞いなどの重要な要素を過度に単純化(または無視)するか、逆に詳細なバッテリー電気化学を数値的に解くことを試みて過度に複雑化してしまっていることが課題です。 物理ベースとデータドリブンのハイブリットアプローチを使用したデジタルツインによって、現実世界の要素の影響を考慮しながら、リアルタイムに実行可能な運用モデルを作成することができるようになります。 ソリューションのショーケース この記事で詳細に説明されているソリューションは、いくつかの課題に対処する必要があります。以下の要件を満たす必要があります。 大規模な車両台数に対してスケーラブルであること。 デジタルツインがより複雑になるにつれて、コンポーネントを追加できるようにモジュール化されていること。 個々の電気自動車のモデルを自動的に再キャリブレーションし、正確な予測を続けるためのスケーラブルなメカニズムを提供できること。 以下の 図 1 に示されているスクリーンショットは、4 台の車両フリートにおける展開ソリューションです。また以下のビデオも、MHP のデジタルツインのプラットフォームを理解するのに役立ちます。 バッテリーの健康状態は、電気自動車の残存価値の直接的な指標です。SoH の劣化は、使用パターンや環境条件、そしてバッテリーの管理に強く依存しています。 ショーケースでは、運転パターンに基づいて EV のバッテリーの SoH を予測することに焦点を当てています。私たちは、2 つのデジタルツインを使用して電気自動車をモデル化しています。1 つ目はドライバーをモデル化し、2 つ目はバッテリーをモデル化します。両方のデジタルツインには、人工的なドライバーの振る舞いデータおよびバッテリーの劣化データを使用した合成データが利用されます。 ドライバーのデジタルツインは、次のトリップがいつ発生するか、トリップの所要時間はどれくらいか、そして他のドライバーに関連する情報を、カーネル密度推定を用いた振る舞いモデルに基づくサンプリングベースのアプローチで予測します。バッテリーのデジタルツインは、ドライバーのデジタルツインからのデータを使用して、バッテリーの将来の健康状態を予測し、バッテリーの劣化をモデリングします。 図 1 – 4 台の車両フリートにおける展開ソリューションのスクリーンショット サービスアーキテクチャ ここに示されているアーキテクチャでは、 AWS IoT FleetWise を使用してシミュレートされた車両データを Amazon Timestream データベースに取り込みます。データは、カスタムビルトの MHP デジタルツインサービスによって受信され、予測メタデータは Amazon DynamoDB に保存され、予測結果は再び Amazon Timestream に格納されます。 予測結果は AWS IoT TwinMaker にフィードされた後に、 Amazon Managed Service for Grafana を介してフリートオペレーターが簡単に使用できるダッシュボードで健康状態や他の車両情報を監視できるようになります。 図 2 – 全体的なサービスのアーキテクチャ MHP のデジタルツインサービスは、レベル4のデジタルツインソリューションの中心的な役割を果たします。運用データをデジタルツインモデルに渡し、モデルを実行し、モデルエラーを計算し、必要に応じてデジタルツインモデルを再キャリブレーションします。 このサービスは、 aws-do-pm のオープンソースフレームワークの一部として開発されたモデルキャリブレーション技術を活用しています。図 3 は MHP のデジタルツインサービスのアーキテクチャを示しています。 MHP のデジタルツインサービスには、新しいコンポーネントが追加されるにつれて成長する、いわばモジュラー型デジタルツインを可能にする 2 つの主要な機能があります。 まずデジタルツインは、各々が独自のデジタルツインで表されるサブモジュールに分割されます。それぞれの子デジタルツインは相互作用することで、親ツインの振る舞いを合成することができます。例えば、バッテリーは、セルのデジタルツインを使用してモデリングすることができますし、異なるコンポーネントのデジタルツインを使用して車をモデリングすることができます。モデリングの深さは、ユースケースと利用可能なモデリング技術に依存します。 次に、図3に示されるように、各デジタルツインは3つのモジュールに分割されます。新しいデータが利用可能になる度にモデルを更新して予測を改善するために、これらのモジュールはレベル4のリビングデジタルツインの基本的な要件を反映しています。これを可能にするために、すべてのデジタルツインにはデータサービス、更新サービス、予測サービスの 3 つのモジュールが含まれています。 図 3 – デジタルツインサービスのアーキテクチャ データサービスは、モデルへのデータの取り込みを処理します。また、予測結果をデータベースに書き込み、モデルパラメータをシリアライズする責任も持ちます。 更新サービスは、初期トレーニングを実行したり、モデル全体を更新したり、予測エラーが大きくなった場合にモデルにベイジアンキャリブレーションを実行することができます。 このベイジアン更新は、非線形システムのパラメータ推定に使用される Unscented Kalman Filter (UKF) に基づいています。UKF は、ガイダンス、ナビゲーション、車両の制御からロボットの動作計画や軌跡最適化まで、さまざまなフィールドで適用される手法です。UKF は、予測モデリングのための aws-do-pm フレームワークでも中心的な役割を果たしています。 これらの 3 つのモジュールは、個々のタスクとして開発され、 AWS Fargate 上に展開されます。各サービスは、スケーラビリティを確保するために Application Load Balancer を使用します。AWS Fargate 上のそれぞれのツインサービスとモジュール間メッセージのやり取りは、リモートプロシージャコール (RPC) フレームワークである gRPC を介して処理されます。 新しい外部データは、 Amazon Simple Notification Service (SNS) トピックで収集され、 AWS Lambda 関数に受信されます。Lambda 関数は gRPC リクエストを使用して、新しいデータを対応するデジタルツインに転送します。 結論 この記事では、MHP が AWS と協力して電気自動車の課題、特に EV バッテリーのパフォーマンスに対応するためにモジュラー型でスケーラブルなデジタルツインソリューションの構築に取り組んでいることに触れました。 このソリューションは、AWS が提案する 4-level のインデックス に基づく レベル 4 のリビングデジタルツイン です。詳細については、 MHP の ホワイトペーパー や ウェビナー をご覧ください。 上記は自動車産業の例ですが、デジタルツインには無限の可能性があります。 MHP – AWS パートナースポットライト MHP は、 1996 年に Porche AG の子会社として設立された AWS のアドバンストティアサービスパートナーです。 MHP のアプローチは、自動車業界をはじめとするさまざまな業界に対するマネジメントおよび IT コンサルティング、および深いプロセスノウハウの提供を含んでおり、顧客が自社のビジネスの将来をより良いものにすることができるよう支援しています。 MHPにお問い合わせ | パートナー概要 本ブログは、 Using Digital Twins to Drive Electric Vehicle Battery Insights with MHP and AWS を翻訳したものです。 翻訳は Solutions Architect Leader ショーン・セーヒーと Solutions Architect 佐藤高士が担当しました。
Apache Flink は、ストリームおよびバッチ処理向けの、パワフルなプログラミングインターフェースを提供するオープンソースの分散処理エンジンです。ステートフルな処理やイベントタイムセマンティクスをサポートしています。Apache Flink は、複数のプログラミング言語、Java、Python、Scala、SQL、および異なる抽象化レベルの複数の API をサポートしています。これらを単一のアプリケーション内で組み合わせて使用することも可能です。 Amazon Managed Service for Apache Flink は、Apache Flink アプリケーションをフルマネージド、サーバーレスで実行可能なサービスです。このたび、 Apache Flink 1.18.1 がサポートされたことをお知らせします。 本投稿では、直近のメジャーリリース 1.16、1.17、1.18 で導入され、かつ Managed Service for Apache Flink でサポートされた、Apache Flink の興味深い機能の一部について説明していきます。 新しいコネクタ Apache Flink バージョン 1.18.1 で利用可能な新機能を詳しくみていく前に、新しいオープンソースコネクタについて説明させてください。 OpenSearch 専用の OpenSearch コネクタが利用可能になりました。本コネクタにより、Apache Flink アプリケーションは Elasticsearch の互換モードに頼らずに、直接 OpenSearch にデータを書き込むことができます。本コネクタは Amazon OpenSearch Service のプロビジョンドクラスター、および OpenSearch Service Serverless と互換性があります。 新しいコネクタは SQL と Table API をサポートし、Java と Python の両方で動作します。また、Java については DataStream API もサポートされています。本コネクタは Flink のチェックポインティングと同期して書き込みを行うため、追加設定なしで at-least-once を保証しています。一意の ID とアップサート方式を組み合わせることで、exactly-once を達成することも可能です。 デフォルトでは、コネクタは OpenSearch バージョン 1.x のクライアントライブラリを使用します。 適切な依存関係を追加することで 、バージョン 2.x に切り替えることができます。 Amazon DynamoDB Apache Flink アプリケーション開発者は、 Amazon DynamoDB にデータを書き込むための専用のコネクタを利用できるようになりました。 本コネクタは、AWS によって開発され、今や Apache Flink プロジェクトの不可欠なコンポーネントである Apache Flink AsyncSink をベースとしています。Apache Flink AsyncSink を活用することで、ノンブロッキングな書き込みリクエストとアダプティブバッチングにより、効率のよい出力コネクタを簡単に実装できます。 本コネクタは SQL と Table API (Java と Python)、および DataStream API (Java のみ) の両方をサポートします。デフォルトでは、スループットを最適化するためにバッチ書き込みを行います。SQL バージョンにおける注目すべき機能は、PARTITIONED BY 句のサポートです。1 つ以上のキーを指定することで、クライアント側の重複排除を実現でき、各バッチ書き込み時に最新のレコードのみを指定されたキーごとに送信することができます。DataStream API でも、各バッチ内で上書きするパーティションキーのリストを指定することで、同等の処理を実現できます。 このコネクタはシンクとしてのみ動作します。DynamoDB からのデータ読み取りには使用できません。DynamoDB のデータを検索するには、 Flink Async I/O API を使って参照処理を実装するか、SQL の場合はカスタムユーザー定義関数 (UDF) を実装する必要があります。 MongoDB 興味深い別のコネクタとして、 MongoDB 向けのものがあります。本コネクタはソースとシンクの両方で、 SQL と Table API と DataStream API が利用可能です。新しいコネクタは、公式な Apache Flink プロジェクトの一部であり、コミュニティによってサポートされています。本コネクタは、MongoDB 自身が提供していた以前のコネクタに置き換わるものです。以前のコネクタでは、Flink の Sink および Source API のみをサポートしていました。 他のデータストアコネクタと同様に、ソースコネクタはバッチモードで bounded source として、または参照用として使用できます。シンクコネクタはバッチモードとストリーミングの両方で利用可能で、upsert および append の両モードをサポートします。 本コネクタには多くの注目すべき機能がありますが、その中でも言及しておきたいのは、ソースにおける参照時のキャッシュ有効化と、シンクにおける追加設定なしでの at-least-once 保証の二点です。プライマリキーが定義されている場合、シンクは idempotent upserts により、exactly-once をサポートすることもできます。 コネクタのバージョニング 新機能ではありませんが、コネクタのバージョン管理が新しくなった点は、以前の Apache Flink アプリケーションを更新する際に考慮すべき重要な要素となります。 Apache Flink バージョン 1.17 以降、ほとんどのコネクタがメインの Apache Flink ディストリビューションから外部化され、独立したバージョン管理に従うようになりました。 依存関係を正しく含めるためには、 - の形式でアーティファクトバージョンを指定する必要があります。 例えば、本投稿の執筆時点で最新の Kafka コネクタは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) とも連携する、バージョン 3.1.0 です。Apache Flink 1.18 で本コネクタを使用する場合は、次の依存関係を使用する必要があります。 &lt;dependency&gt; &lt;groupId&gt;org.apache.flink&lt;/groupId&gt; &lt;artifactId&gt;flink-connector-kafka&lt;/artifactId&gt; &lt;version&gt;3.1.0-1.18&lt;/version&gt; &lt;/dependency&gt; Amazon Kinesis の新しいコネクタバージョンは 4.2.0 です。Apache Flink 1.18 における依存関係は以下のとおりです。 &lt;dependency&gt; &lt;groupId&gt;org.apache.flink&lt;/groupId&gt; &lt;artifactId&gt;flink-connector-kinesis&lt;/artifactId&gt; &lt;version&gt;4.2.0-1.18&lt;/version&gt; &lt;/dependency&gt; 次のセクションでは、Apache Flink 1.18 から利用可能となった強力な新機能の中で、Amazon Managed Service for Apache Flink でサポートされているものについて、さらに説明していきます。 SQL Apache Flink SQL において、オプティマイザに効果的なクエリプランを提案するために、 hints を結合クエリに付与可能となりました。特にストリーミングアプリケーションでは、外部システム (一般的にはデータベース) からクエリされたデータを使用して、ストリーミングデータを表すテーブルのエンリッチのために、 lookup joins が使用されます。バージョン 1.16 以降、lookup joins にいくつかの改善が導入され、結合の動作を調整してパフォーマンスを向上できるようになりました。 ルックアップキャッシュ は、最も頻繁に使用されるレコードをメモリにキャッシュすることで、データベースの負荷を軽減する強力な機能です。以前は、ルックアップキャッシュはいくつかのコネクタのみの専用機能でした。Apache Flink 1.16 以降、このオプションはルックアップをサポートしているすべてのコネクタで利用可能になりました ( FLIP-221 )。執筆時点では、 JDBC 、 Hive 、および HBase コネクタがルックアップキャッシュをサポートしています。ルックアップキャッシュには 3 つのモードがあります。メモリ上にすべて保持できる小さなデータセットの場合は FULL 、大きなデータセットの場合は最新のレコードのみをキャッシュする PARTIAL 、キャッシュを完全に無効にする NONE です。 PARTIAL キャッシュでは、バッファ行数と有効期限を設定可能です。 非同期ルックアップ はパフォーマンスを大幅に改善するための異なるアプローチです。非同期ルックアップは、Apache Flink SQL における DataStream API で利用可能な非同期 I/O と同様の機能を提供します。これにより、Apache Flink は、前のルックアップへの応答を受信するまでスレッドをブロックすることなく、データベースに新しい要求を送信できます。非同期 I/O と同様に、結果の順序付けを強制や、順不同な結果の許容、バッファ容量やタイムアウトの調整が可能です。 PARTIAL または NONE ルックアップキャッシュと組み合わせて、外部データベースのルックアップ失敗時の動作を設定する lookup retry strategy を設定することもできます。 これらの動作はすべて LOOKUP ヒントを使用して制御できます。以下に非同期ルックアップを使用したルックアップ結合を示します。 SELECT /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ O.order_id, O.total, C.address FROM Orders AS O JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C ON O.customer_id = O.customer_id PyFlink このセクションでは、PyFlink の新機能と改善点について説明します。 Python 3.10 のサポート Apache Flink 1.18 では、PyFlink ユーザー向けのいくつかの改善が導入されました。 最も重要なのは、Python 3.10 がサポートされ、Python 3.6 のサポートが完全に削除されたことです ( FLINK-29421 )。 Managed Service for Apache Flink も、Python 3.10 ランタイムを使用して PyFlink アプリケーションを実行します。 機能差異の解消 プログラミング API の観点から見ると、PyFlink は、バージョンを重ねるごとに Java に近づいています。DataStream API では、サイド出力やブロードキャスト状態などの機能がサポートされるようになり、ウィンドウ API における不足も解消されました。また PyFlink は DataStream API から直接 Amazon Kinesis Data Streams などの新しいコネクタをサポートするようになりました。 スレッドモードの改善 PyFlink は非常に効率的です。PyFlink で Flink API オペレータを実行するオーバーヘッドは、Java や Scala に比べて最小限に抑えられています。これは、アプリケーションの言語に関係なく、ランタイムが実際にオペレータの実装を JVM で直接実行するためです。しかし、ユーザー定義関数の場合は少し異なります。 lambda x: x + 1 のような単純な Python コードでも、複雑な Pandas 関数でも、Python ランタイムで実行する必要があるためです。 デフォルトでは、Apache Flink は JVM の外部で、各 Task Manager 上で Python ランタイムを実行します。各レコードはシリアライズされ、プロセス間通信を介して Python ランタイムに渡され、デシリアライズされて処理されます。その結果は再度シリアライズされ、JVM に戻され、デシリアライズされます。これが PyFlink の PROCESS モード です。非常に安定していますが、オーバーヘッドが発生し、場合によってはパフォーマンスのボトルネックになる可能性があります。 Apache Flink バージョン 1.15 以降では、PyFlink 向けに THREAD モード もサポートしています。このモードでは、Python のユーザー定義関数が JVM 内で実行されるため、シリアライズ/デシリアライズおよび、プロセス間通信のオーバーヘッドが取り除かれます。THREAD モードには いくつかの制限 があります。たとえば、Pandas や UDAF (多数の入力レコードから 1 つの出力レコードを生成するユーザー定義集約関数) では使用できません。しかしながら、PyFlink アプリケーションのパフォーマンスを大幅に向上させることができます。 バージョン 1.16 では、THREAD モードのサポートが大幅に拡張され、Python DataStream API もカバーされるようになりました。 Managed Service for Apache Flink は THREAD モードをサポートしており、 PyFlink アプリケーションから直接有効化が可能です 。 Apple Silicon サポート Apple Silicon ベースのマシンで PyFlink アプリケーションの開発をする際に、PyFlink 1.15 においては、Apple Silicon における既知の Python 依存関係の問題に遭遇したかもしれません。これらの問題はついに解決されました ( FLINK-25188 )。これらの制限は、Apache Flink の Managed Service 上で実行される PyFlink アプリケーションには影響しませんでした。バージョン 1.16 より前は、M1、M2、M3 チップセットを使用するマシン上で PyFlink アプリケーションを開発する場合、PyFlink 1.15 以前をマシン上に直接インストールすることができないため、 回避策 を適用する必要がありました。 アンアラインドチェックポイントの改善 Apache Flink 1.15 ではすでに Incremental Checkpoint と Buffer Debloating がサポートされています。特にこれらの機能を組み合わせて使用することで、チェックポイントのパフォーマンスを改善し、バックプレッシャーが発生している場合でもチェックポインティングの期間をより予測可能とすることができます。これらの機能の詳細については、 Amazon Managed Streaming for Apache Flink アプリケーション向けのバッファデブロートとアンアラインドチェックポイント をご覧ください。 バージョン 1.16 および 1.17 では、安定性とパフォーマンスを向上させるためにいくつかの変更が導入されました。 データスキューの処理 Apache Flink は ウォーターマークによるイベントタイムのセマンティクスをサポートしています 。ウォーターマークは、通常はソースオペレーターからフローに挿入される特別なレコードで、イベントタイムウィンドウ集計などのオペレーターのイベントタイムの進行をマークします。一般的な手法は、最新の観測されたイベントタイムからウォーターマークを遅延させ、ある程度の範囲でイベントが順不同になることを許容することです。 しかし、ウォーターマークの使用には課題があります。アプリケーションが複数のソースを持つ場合、例えば Kafka トピックの複数のパーティションからイベントを受信する場合、ウォーターマークは各パーティションごとに独立して生成されます。内部的には、各オペレーターは常に、すべての入力パーティションで同じウォーターマークを待機します。これは実質的に最も遅いパーティションに合わせることを意味します。これがネックとなり、あるパーティションがデータを受信していない場合は、ウォーターマークが進まず、エンドツーエンドのレイテンシが増加します。このため、多くのストリーミングソースに オプションとしてアイドルタイムアウト が導入されています。設定したタイムアウト後は、レコードを受信していないパーティションを無視してウォーターマークの生成を行い、ウォーターマークを進めることができます。 1 つのソースがほかよりもイベントを大幅に早く受信している場合、逆の課題に直面する可能性があります。ウォーターマークはもっとも遅いパーティションに揃えられるため、ウィンドウ集約のためにウォーターマークを待つ必要が生じます。高速なソースからのレコードは、バッファリングされながら待たされることになります。オペレータ状態が制御できない程に、バッファリングされたデータが肥大化する恐れがあります。 より高速なソースの問題に対処するため、Apache Flink 1.17 以降では、ソース分割におけるウォーターマークアライメントを有効化できます ( FLINK-28853 )。デフォルトでは無効になっているこのメカニズムにより、特定のパーティションが他のパーティションと比べてウォーターマークを速く進めすぎないようになります。複数のソース (複数の入力トピックなど) を 1 つのアライメントグループ ID に割り当て、現在のウォーターマークからの最大ドリフト期間を指定することで、これらを束ねることができます。特定のパーティションがイベントを高速で受信する場合、ソースオペレーターはドリフトが指定されたしきい値を下回るまで、そのパーティションの消費を一時停止します。それぞれのソースごとに有効化できます。必要なのは、同じ ID を持つすべてのソースを結びつける整列グループ ID と、現在の最小ウォーターマークからの最大ドリフト時間を指定することです。これにより、あまりにも速く進んでいるソースサブタスクの消費が一時停止し、ドリフトが指定された閾値を下回るまで待機します。 以下のコードスニペットは、Kafka ソースから協会のない順序性のウォーターマークを出力するために、ソース分割のウォーターマークアラインメントを設定する方法を示しています。 KafkaSource kafkaSource = ... DataStream stream = env.fromSource( kafkaSource, WatermarkStrategy.forBoundedOutOfOrderness( Duration.ofSeconds(20)) .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)), "Kafka source")); この機能は、 FLIP-217 に準拠した、ソース分割のウォーターマークアラインメントをサポートしているソースでのみ利用可能です。執筆時点では、主要なストリーミングソースコネクタのうち、Kafka ソースのみがこの機能をサポートしています。 Protobuf フォーマットの直接サポート 現在、SQL と Table API は、 Protobuf 形式 を直接サポートしています。この形式を利用するには、 .proto スキーマ定義ファイルから Protobuf の Java クラスを生成し、アプリケーションの依存関係に含める必要があります。 Protobuf フォーマットは SQL およびテーブル API でのみ利用可能で、Protobuf でシリアルライズされたデータをソースまたはシンクから読み書きする場合にのみ機能します。現在、Flink はステートを直接シリアルライザブルする Protobuf を直接サポートしておらず、Avro などのように schema evolution もサポートしていません。アプリケーション用に カスタムシリアライザー を登録する必要がありますが、オーバーヘッドを伴います。 Apache Flink をオープンソースのまま維持 Apache Flink は、サブタスク間のデータ送信を、内部的に Akka に依存してきました。 2022 年、Akka を開発している企業である Lightbend は、 今後の Akka バージョンのライセンスを Apache 2.0 からより制限的なライセンスに変更し、Apache Flink で使用されているバージョンである Akka 2.6 にはこれ以上のセキュリティアップデートや修正が提供されないこと を発表しました。 Akka は従来から非常に安定しており、頻繁な更新は必要ありませんでしたが、このライセンスの変更は Apache Flink プロジェクトにとってリスクとなりました。Apache Flink コミュニティの決定は、Akka 2.6 のフォークである Apache Pekko ( FLINK-32468 ) に置き換えることでした。このフォークは Apache 2.0 ライセンスを維持し、コミュニティによって必要な更新が加えられます。それまでの間、Apache Flink コミュニティは、Akka ならびに Pekko への依存関係を完全に削除するかどうかを検討しています。 ステート圧縮 Apache Flink は、すべてのチェックポイントとセーブポイントに対してオプションの圧縮 (デフォルト: オフ) を提供します。 Apache Flink は、スナップショット圧縮が有効になっている場合にオペレーターの状態を適切に復元できないという Flink 1.18.1 の バグ を特定しました。これにより、データが失われるか、チェックポイントから復元できなくなる可能性があります。これを解決するために、Managed Service for Apache Flink は、Apache Flink の将来のバージョンに含まれる 修正 をバックポートしました。 Managed Service for Apache Flink におけるインプレースバージョンアップグレード Apache Flink 1.15 以前のバージョンを使用して Managed Service for Apache Flink で現在アプリケーションを実行している場合、 AWS コマンドラインインターフェース (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) または AWS API を使用するツールのいずれかを使用して、ステートを失うことなくバージョン 1.18 にインプレースアップグレードが可能です。 UpdateApplication API アクションによって、既存の Managed Service for Apache Flink アプリケーションの Apache Flink ランタイムバージョンを更新できるようになりました。実行中のアプリケーションに直接 UpdateApplication を使用できます。 インプレースアップグレードを続行する前に、アプリケーションに含まれる依存関係を検証したうえで更新し、新しい Apache Flink バージョンと互換性があることを確認する必要があります。特に、Apache Flink ライブラリ、コネクタ、場合によっては Scala バージョンを更新する必要があります。 また、更新を続行する前に、更新されたアプリケーションをテストすることをお勧めします。リグレッションが発生していないことを確認するために、ターゲットの Apache Flink ランタイムバージョンを使用して、ローカルもしくは本番以外の環境でテストすることをお勧めします。 最後に、アプリケーションがステートフルである場合は、実行中のアプリケーションの状態の スナップショット を取得することをお勧めします。これにより、以前のアプリケーションバージョンにロールバック可能となります。 準備ができたら、 UpdateApplication API アクションまたは update-application AWS CLI コマンドを使用して、アプリケーションのランタイムバージョンを更新し、更新された依存関係を含む新しいアプリケーションアーティファクト、JAR、または zip ファイルをポイントできるようになります。 プロセスと API の詳細については、 Apache Flink のインプレース バージョン アップグレード を参照してください。ドキュメントには、ステップバイステップの手順とアップグレードプロセスを説明する動画が含まれています。 まとめ この投稿では、Apache Flink の Amazon マネージドサービスでサポートされている Apache Flink の新機能のいくつかを調べました。このリストは包括的なものではありません。 Apache Flink は、SQL およびテーブル API のオペレーターレベル TTL [FLIP-292] やタイムトラベル [FLIP-308] など、非常に有望な機能もいくつか導入しましたが、これらは API ではまだサポートされておらず、ユーザーが実際にアクセスできる状態にありません。そのため、本投稿で取り上げる対象から外しました。 Apache Flink 1.18 で利用できる興味深い新機能と新しいコネクタのいくつかと、Apache Flink のマネージド サービスが既存のアプリケーションのアップグレードにどのように役立つかを見てきました。 最近のリリースの詳細については、Apache Flink ブログとリリースノートをご覧ください。 Amazon Managed Service for Apache Flink のリリースノート Apache Flink 1.16 リリース記事 および リリースノート Apache Flink 1.17 リリース記事 および リリースノート Apache Flink 1.18 リリース記事 および リリースノート Apache Flink を初めて使用する場合は、 適切な API と言語を選択するガイド を参照し、 スタートガイド に従って Apache Flink のマネージド サービスの使用を開始することをお勧めします。 著者について Lorenzo Nicora は AWS でシニア ストリーミング ソリューション アーキテクトとして働いており、EMEA 全体の顧客をサポートしています。彼は 25 年以上にわたってクラウドネイティブでデータ集約型のシステムを構築しており、コンサルティング会社や FinTech 製品会社の両方を通じて金融業界で働いています。彼はオープンソース テクノロジーを幅広く活用し、Apache Flink などのいくつかのプロジェクトに貢献してきました。 Francisco Morillo は AWS のストリーミング ソリューション アーキテクトです。 Francisco は AWS の顧客と協力し、AWS のサービスを使用したリアルタイム分析アーキテクチャの設計を支援し、Amazon MSK および Amazon Managed Service for Apache Flink をサポートしています。 本記事は、 Amazon Managed Service for Apache Flink now supports Apache Flink version 1.18 を翻訳したものです。翻訳は Solutions Architect の榎本が担当しました。
本記事は、 Announcing data filtering for Amazon Aurora MySQL zero-ETL integration with Amazon Redshift を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 組織がよりデータドリブンになり、データを競争力向上の源として利用するようになると、売上の成長、コスト削減、ビジネスの最適化のために、データ分析を実行し主要なビジネス上の課題をより深く理解しようとします。 稼働中のサービスにまつわるデータで分析を実行するために、データベース、データウェアハウス、ETL(extract, transform, and load) パイプラインの組み合わせで構成されるソリューションを構築する場合があります。 ETL とは、データエンジニアが異なるソースからのデータを組み合わせるために使用するプロセスです。 ETL パイプラインの構築と保守の労力を軽減するために、AWS は Amazon Redshift との Amazon Aurora ゼロ ETL 統合 を AWS re:Invent 2022 で発表しました。この機能は現在、 Amazon Aurora MySQL 互換エディション 3.05.0 以降で一般提供されています。 AWS は本日、ゼロ ETL 統合のデータフィルタリングを発表しました。これにより、Amazon Aurora MySQL と Amazon Redshift 間のゼロ ETL 統合においてデータを選択して取り込むことができます。この機能により、分析ユースケースにおいて、データウェアハウスである Redshift にレプリケートする個々のデータベースとテーブルを選択できます。 この投稿では、この機能を使用できるユースケースの概要を示し、この機能を使用してニアリアルタイムの運用分析を開始する方法について段階的に説明します。 データフィルタリングの使用例 データフィルタリングを使用すると、Amazon Aurora MySQL から Amazon Redshift へレプリケートするデータベースとテーブルを選択できます。 複数のフィルターをゼロ ETL 統合に適用できるため、レプリケーションを特定のニーズに合わせて調整できます。 データフィルタリングは、 exclude フィルターまたは include フィルターのいずれかのルールを適用し、正規表現を使用して複数のデータベースとテーブルを照合できます。 このセクションでは、データフィルタリングの一般的なユースケースについて説明します。 PII データを含むテーブルをレプリケーションから除外することによるデータセキュリティの向上 サービス内で運用されているデータベースには、個人を特定できる情報(PII)が含まれていることがよくあります。これは性質上センシティブな情報であり、郵送先住所、顧客確認書類、クレジットカード情報などが含まれます。 厳格なセキュリティコンプライアンス規制のため、分析ユースケースに個人を特定できる情報(PII)を使用したくない場合があります。データフィルタリングを使用すると、PII データを含むデータベースやテーブルをフィルタリングして、Amazon Redshift へのレプリケーションから除外できます。これにより、分析ワークロードのデータセキュリティとコンプライアンスが向上します。 特定のユースケースに必要なテーブルをレプリケートすることで、ストレージコストを節約し、分析ワークロードを管理 サービス内で運用されているデータベースには、分析に役立たない様々なデータセットが含まれていることがよくあります。これには補助データ、特定のアプリケーションデータ、異なるアプリケーションのための同じデータセットの複数のコピーが含まれます。 さらに、Redshift を利用したデータウェアハウスはそれぞれの異なるユースケースごとに構築することが一般的です。そういったアーキテクチャでは、個々のエンドポイントで異なるデータセットを利用できる必要があります。 データフィルタリングを使用すると、ユースケースで必要なデータセットのみをレプリケートできます。 これにより、使用されていないデータを保存する必要性をなくすことでコストを節約できます。 既存のゼロ ETL 統合を変更して、必要に応じてより制限的なデータレプリケーションを適用することもできます。 既存の統合にデータフィルターを追加すると、Aurora は新しいフィルターを使用してレプリケートされるデータを完全に再評価します。 これにより、対象の Redshift エンドポイントから新しくフィルタリングされたデータが削除されます。 Aurora の Amazon Redshift とのゼロ ETL 統合のクォータの詳細については、 クォータ を参照してください。 小規模なデータレプリケーションから開始し、必要に応じてテーブルを段階的に追加する Amazon Redshift 上でより多くの分析ユースケースが開発されるにつれ、個々のゼロ ETL レプリケーションにさらにテーブルを追加したいと考えるかもしれません。 将来的に使用する可能性に備えて、Aurora データベースのすべてのテーブルを Amazon Redshift にレプリケートするのではなく、データフィルタリングを使用することで、Aurora データベースの一部のテーブルのサブセットから小規模に開始し、必要に応じてフィルターにさらにテーブルを増分的に追加できます。 ゼロ ETL 統合のデータフィルターが更新されレプリケーションの対象にテーブルが追加された際には、Aurora はフィルター全体を評価しなおします。これにより、以前にレプリケートされたテーブルを使用しているワークロードは、新しいテーブルを追加しても影響を受けることはありません。 レプリケーションプロセスの負荷分散によるワークロードごとのパフォーマンスを向上する 大規模なトランザクションデータベースの場合、レプリケーションとその下流の処理を複数の Redshift クラスタにロードバランスする必要があるかもしれません。これにより、個々の Redshift エンドポイントのコンピューティング要件を削減し、ワークロードを複数のエンドポイントに分割することができます。複数の Redshift エンドポイントにわたってワークロードをロードバランスすることで、エンドポイントが個々のワークロードに適切にサイズ設定されたデータメッシュアーキテクチャを効果的に作成できます。これによりパフォーマンスが向上し、全体的なコストが低減できます。 データフィルタリングを使用すると、異なるデータベースとテーブルを個別の Redshift エンドポイントにレプリケートできます。 次の図は、ゼロ ETL 統合でデータフィルターを使用して、Aurora の異なるデータベースを Redshift エンドポイントに分割する方法を示しています。 使用例 TICKIT データベースを考えてみましょう。TICKIT サンプルデータベースには、ユーザーが各種イベントのチケットを売買する架空の会社のデータが含まれています。この会社のビジネスアナリストは、Aurora MySQL データベースに保存されているデータを使用して、さまざまなメトリックを生成したいと考えており、この分析をニアリアルタイムで実行したいと考えています。そこで、この会社はゼロ ETL がソリューションになりうるのではないかと考えました。 会社のアナリストが必要なデータセットを調査している間に、users テーブルには顧客ユーザー情報に関する個人情報が含まれているが、その情報は分析要件にとって有用ではないことがわかりました。 したがって、users テーブルを除くすべてのデータをレプリケートしたいと考えており、ゼロ ETL のデータフィルタリングを使用して それを実現したいと考えています。 セットアップ まず、 Amazon Aurora と Amazon Redshift のゼロ ETL 統合を使用したニアリアルタイム運用分析のためのスタートガイド に従って、新しい Aurora MySQL データベース、 Amazon Redshift Serverless エンドポイント、ゼロ ETL 統合を作成します。 次に Redshift クエリエディター v2 を開き、users テーブルからのデータが正常にレプリケートされていることを確認するために、次のクエリを実行します。 select * from aurora_zeroetl.demodb.users ; データフィルター データフィルターは、 Amazon Relational Database Service (Amazon RDS) のゼロ ETL 統合に直接適用されます。 単一の統合に対して複数のフィルターを定義でき、各フィルターは Include フィルター型または Exclude フィルター型のいずれかとして定義されます。 データフィルターは、既存および将来のデータベーステーブルにパターンを適用して、適用するフィルターを決定します。 データフィルタの適用 ゼロ ETL 統合から users テーブルを削除するフィルターを適用するには、次のステップを行います。 Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 フィルターを追加するゼロ ETL 統合を選択します。 デフォルトのフィルターは、 include:*.* というフィルターで表され、すべてのデータベースとテーブルを含めます。 変更 を選択します。 ソース セクションで フィルターを追加する を選択します。 フィルタータイプを選択する で 除外する を選択します。 フィルター式 に demodb.users と入力します。 フィルター式の順序が重要になります。フィルターは左から右、上から下に評価され、後続のフィルターが前のフィルターをオーバーライドします。この例では、Aurora はすべてのテーブルを含める必要があると評価し(フィルター 1)、次に demodb.users テーブルを除外する必要があると評価します(フィルター 2)。exclusion フィルターは inclusion フィルターの後にあるため、inclusion フィルターをオーバーライドします。 続行 を選択します。 変更内容をレビューし、フィルターの並び順が正しいことを確認したら、  変更内容を保存 を選択します。 統合が追加され、変更が適用されるまで 変更中 の状態になります。これには最大 30 分かかる場合があります。変更の適用が完了したかどうかを確認するには、ゼロ ETL 統合を選択し、そのステータスを確認してください。 アクティブ と表示されていれば、変更が適用されたことを意味します。 変更の確認 ゼロ ETL 統合が更新されたことを確認するには、次のステップを完了してください: Redshift クエリエディター v2 で、Redshift クラスターに接続します。 作成した aurora-zeroetl データベースを右クリックで選択し、 更新 を選択します。 demodb と Tables を展開します。 users テーブルはレプリケーションから削除されたため、もう利用することができなくなっています。 他のすべてのテーブルは引き続き利用可能です。 以前と同じ SELECT ステートメントを実行すると、オブジェクトがデータベースに存在しないというエラーが発生します: select * from aurora_zeroetl.demodb.users ; AWS CLI を使用したデータフィルタの適用 会社のビジネスアナリストは、Aurora MySQL データベースにさらに多くのデータベースが追加されていることを理解し、 demodb データベースのみが Redshift クラスタにレプリケートされるようにしたいと考えています。 このため、 AWS Command Line Interface (AWS CLI) を使用して、ゼロ ETL 統合のフィルタを更新したいと考えています。 AWS CLI を使用したゼロ ETL 統合にデータフィルターを追加するには、 modify-integration コマンドを呼び出すことができます。 統合識別子に加えて、 include フィルターと exclude フィルターをコンマ区切りでならべたリストを使用して、 --data-filter パラメータを指定します。 ゼロ ETL 統合のフィルターを変更するには、次のステップを完了します: AWS CLI がインストールされたターミナルを開きます。 利用可能なすべての統合を表示して確認するには、次のコマンドを入力します。 aws rds describe-integrations 更新したい統合を見つけ、統合識別子をコピーします。 統合識別子は、統合の ARN の末尾にある英数字の文字列です。 前のステップでコピーした識別子で &lt;integration identifier&gt; を更新し、次のコマンドを実行します: aws rds modify-integration --integration-identifier " &lt;integration identifier&gt; " --data-filter 'exclude: *.*, include: demodb.*, exclude: demodb.users' Aurora がこのフィルターを評価するとき、デフォルトですべてを除外し、 demodb データベースのみを含めますが、 demodb.users テーブルは除外します。 データフィルターは、データベースとテーブルに対して正規表現を利用したフィルタリングが可能です。 たとえば、 user で始まるテーブルをすべてフィルタリングしたい場合は、次のように実行できます: aws rds modify-integration --integration-identifier " " --data-filter 'exclude: *.*, include: demodb.*, exclude *./^user/' 前のフィルターの変更と同様に、変更が適用されるまで統合が追加され 変更中 の状態になります。これには最大 30 分かかる場合があります。 アクティブ と表示されたら、変更が適用されたことを意味します。 クリーンアップ ゼロ ETL 統合に追加されたフィルターを削除するには、次のステップを完了してください: Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 該当のゼロ ETL 統合を選択します。 変更 を選択します。 削除したいフィルターのとなりにある 削除 を選択します。 exclusion フィルターを inclusion フィルターに変更することもできます。 あるいは、AWS CLI を使用して次のコマンドを実行することもできます: aws rds modify-integration --integration-identifier " " --data-filter 'include: *.*' 「 続行 」を選択します。 「 変更を保存 」を選択します。 データフィルターの変更を適用するには、最大 30 分かかります。 データフィルターを削除すると、Aurora は、削除されたフィルターが存在しなかったかのように、残りのフィルターを再評価します。 以前はフィルタリング基準に一致しなかったが、変更によって一致するようになったデータは、ターゲットの Redshift データウェアハウスにレプリケートされます。 結論 この投稿では、Amazon Aurora MySQL から Amazon Redshift へのゼロ ETL 統合にデータフィルタリングを設定する方法を示しました。これにより、必要なデータのみをレプリケートしながら、トランザクションデータや運用データでニアリアルタイムな分析を行うことができます。 データフィルタリングを使用すると、ワークロードを個別の Redshift エンドポイントに分割したり、プライベートまたは機密データセットのレプリケーションを制限したり、必要なデータセットのみをレプリケートすることでワークロードのパフォーマンスを向上させたりすることができます。 Amazon Redshift との Aurora ゼロ ETL 統合の詳細については、 Amazon Redshift との Aurora ゼロ ETL 統合の利用 および ゼロ ETL 統合の利用 を参照してください。 著者について Jyoti Aggarwal は、AWS ゼロ ETL の製品管理リードです。彼女は、パフォーマンス、顧客エクスペリエンス、セキュリティに関する取り組みの推進など、製品およびビジネス戦略を主導しています。彼女は、クラウド コンピューティング、データ パイプライン、分析、人工知能 (AI)、およびデータベース、データ ウェアハウス、データ レイクなどのデータ サービスに関する専門知識をもたらします。 Sean Beath は、アマゾン ウェブ サービスのAnalytics Solutions Architect です。彼は、AWS のサービスを使用したデータ プラットフォームの最新化の配信ライフサイクル全体の経験があり、顧客と協力して AWS での分析価値の向上を支援しています。 Gokul Soundararajan AWS の主任エンジニアであり、トロント大学で博士号を取得し、ストレージ、データベース、分析の分野で働いてきました。