みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 先週から AWS デジタル社会実現ツアー 2023 が開始されました。「地域創生を“さらに”一歩進めるには？」をテーマに全国13都市で開催されるリアルイベントです。10月4日まで各地域で開催されるので、ご興味のある方は是非チェックしてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年8月21日週の主要なアップデート 8/21(月) Amazon Aurora Global Database introduces Global Database Failover Amazon Aurora Global Databaseがリージョン停止等　計画外のイベントに対してのリージョン間のデータベースフェイルオーバーに対応しました。これまでも計画的なリージョン間のフェイルオーバーは実施することが可能でしたが、今回のアップデートにより計画外のイベントの場合も通常1分でセカンダリリージョンを新しいプライマリリージョンに変換することが可能となります。詳細については こちらのブログ も是非ご参考ください。 AWS Elemental MediaConvert now available in the Osaka and Melbourne regions ブロードキャストグレードの機能を備えた動画変換サービスであるAWS Elemental MediaConvertが新たに大阪リージョンととメルボルンリージョンで使えるようになりました。 AWS PrivateLink announces support for user defined IP on VPC endpoints AWS PrivateLink VPC endpointのIPアドレスを選択できるようになりました。AWS PrivateLinkはVPC・AWSサービス・およびお客様のオンプレミスネットワーク間のプライベート接続をトラフィックをインターネットに公開することなく接続するためのサービスです。これまでは作成時にランダムなIPアドレスが割り振られていましたが、この更新によりIPv4とIPv6のIPアドレスを選択することが可能になりました。 8/22(火) Amazon VPC Reachability Analyzer and Amazon VPC Network Access Analyzer are now available in an additional region ご要望頂いていた皆様お待たせいたしました。大阪リージョンでVPC Reachability AnalyzerとVPC Network Access Analyzerをご利用いただけるようになりました！ 8/23(水) AWS Certificate Manager introduces Enterprise Controls to help govern certificate issuance AWS Certificate Manager(ACM)でAWS IAMの条件コンテキストキーを使用できるようになりました。このアップデートによりユーザが組織の公開鍵基盤のガイドラインに準拠した証明書を発行していることを確認できます。例えば、特定の証明書の検証のみを許可することや、サブドメインやワイルドカード名などの特定ドメイン名の証明書をリクエストできるユーザを認証することができます。その他詳細については こちらのドキュメント をご参照ください。この機能は、ACM が利用可能なすべての AWS リージョンで利用できます。 Announcing AWS Dedicated Local Zones AWS Dedicated Local Zonesが発表されました。データレジデンシー等の規制要件を満たすのを目的としてお客様が指定した場所もしくはデータセンターに専用のインフラストラクチャを配置するサービスで、Amazon EC2, Amazon VPC, Amazon EBS, ELB, Amazon ECS, Amazon EKS, AWS Direct Connect等が利用可能です。想定する利用目的、AWS Outpostsとの違い等は　 FAQs もご参考にしてください！ 8/24(木) Amazon RDS for PostgreSQL supports minor versions 15.4, 14.9, 13.12, 12.16, and 11.21 Amazon RDS for PostgreSQLがPostgreSQL 15.4、14.9、13.12、12.16、11.21 のマイナーバージョンをサポートするようになりました。これらのバージョンでは既知のセキュリティ脆弱性の修正、およびバグ修正、パフォーマンスの向上に加え、地理的インデックスシステムの新しい拡張機能 h3-pg などの新機能もサポートされています。 Amazon SageMaker announces preview of GPU/CPU profiler tooling for deep learning model development Amazon SageMaker Profilerのプレビュー公開がアナウンスされました。ディープラーニングのモデル開発のためのオブザーバビリティツールであるAmazon SageMaker ProfilerはGPUとCPU の使用率メトリクス、高解像度の GPU/CPU トレースプロット、カスタムアノテーション 他を可視化しボトルネックの特定やオーバーヘッドの削減などの最適化を支援するツールです。プレビュー期間中、オハイオ、バージニア北部、オレゴン、フランクフルト、アイルランドリージョンにて無料で利用可能です。 8/25(金) Amazon Connect launches granular access controls for the agent activity audit report Amazon Connectのエージェントアクティビティ監査レポートのきめ細かい権限管理ができるようになりました。これにより特定のエージェントの過去のステータス等を付与したタグベースで制御可能になります。この機能は東京を含む９つのリージョンで利用可能です。 Amazon QuickSight adds scheduled and programmatic export to Excel format Amazon QuickSightでダッシュボードの任意のシートから複数のテーブルやピボットテーブルをExcel形式でスケジュール生成することができるようになりました。同時にプログラム経由の実行で使うSnapshot Export APIもPDF, CSVに加えてExcel形式をサポートしました。この機能を使うにはAmazon QuickSight Enterprise エディションとページ分割レポートのサブスクリプションが必要です。 皆さん AWS Workshops をご存知でしょうか？ AWSの様々なサービスのワークショップをこちらから利用可能です。日本語対応しているものは こちら にもまとまっていますので是非ご活用ください。最近日本語化されたものだと Redshift Immersion Labs などがございます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

2021年には、全国の16,000以上のコースで 2,500万人 以上がゴルフラウンドをプレーしました。これらの各ラウンドにおいて、ゴルフカートはプレイヤー体験において引き続き大きな役割を果たしています。ヤーデージやコースGPS、レザーバックシート、そして最も重要なゴルフクラブを運ぶための十分な収納スペースまで、ゴルフカートはプレイヤー体験の重要な要素です。一方で、ゴルフカート市場は、プレイヤー体験をはるかに超えて、 15億ドル規模の業界 を誇り、急成長を続けています。 お客様について : 全国のゴルファーにデジタル体験を提供 市場最大手のクラブカーにとって、パーソナライゼーションと臨場感あふれるメディア体験は、次の未開拓のイノベーション領域です。 快適なゴルフカートから、最新のサッカーの試合を聴いたり、ニュースやスポーツのハイライトを見たり、アプローチに使用するクラブを情報に基づいて決定したり、ホール間の昼食を注文したりできるとしたらどうでしょうか。 1958年に設立された Club Car は、個人用、ビジネス用、商業用のさまざまな用途に対応するゴルフカートとユーティリティビークル (スポーツ用多目的車両) の大手メーカーです。Club Car は、パーソナライズされたメディアやエンターテイメント機器を各車両に組み込むため、デンバーに本拠を置くデジタル屋外広告（DOOH）を専門とするインタラクティブ・ソフトウェア企業、Edison Interactive の支援を受けました。 現在、Edison Interactive のソフトウェアは、 Verizon が提供する Shark Experience を通じて、450のコースロケーションにある41,000台のゴルフカートで利用されています。各車両には、タッチスクリーンディスプレイ、内蔵スピーカー、Bluetooth接続、Yahoo Finance、スポーツ中継などのプレミアムエンターテイメント機能が搭載されています。 課題：統一された没入型体験を大規模に実現 ヤーデージ、ニュース、広告のデータをすべて配信するために、関連するゴルフコースデータをすべて 1 つのクラウドリージョンに集約しました。これにより、Edison チームは管理と運用を簡単化できましたが、地理的に分散されたコンピューティングとデータノードがないため、場所によっては非常に遅延が大きく、ユーザーエクスペリエンスが低下していました。そこで、Edison Interactive は、タッチスクリーンの応答時間を短縮して全体的にシームレスなゴルフ体験を実現できる、最も信頼性の高い接続ソリューションとクラウドソリューションを探し始めました。 さらに、Edison は、今後数か月でさらに数千台のゴルフカートへの搭載を見込んでいたため、コストを指数関数的に増加させずにキャパシティの増大に対応するための決定論的アプローチが必要でした。 また、Edison Interactive のゴルフカートの画面数が急速に拡大するにつれて、エンドユーザーにより効率的にコンテンツを提供するための費用対効果の高い方法も必要になりました。 3.5万 83億 1,643テラバイト 25.3万 Edison Interactive フリート内のゴルフカートの合計 月間リクエスト数合計 LTE 経由のスループット月間リクエストの合計 ゴルフカート 1 台あたりの月間累積リクエスト数 このワークフローを大規模に対応させるため、Edison Interactive は HarperDB クラウドを選択しました。 AWS Wavelength 上に構築される HarperDB の Database-as-a-Service (DaaS) プラットフォームにより、Edison Interactive は 19 の Wavelength Zone すべてを活用して大規模にエンドユーザーに対してデータノードを近接配置し、パフォーマンスを10倍以上向上させました。 「モバイルエッジコンピューティングにより、AI 主導の分析をユーザーに提供して、ユーザーのゴルフの試合を支援できるようになりました。データのリアルタイム転送により、最終的にはグリーングラスゴルフコースのデジタルキャディー向けの機能セットを提供できるようになります。」— Edison Interactive の CRO 兼共同創設者、ニック・スタニッツ・ハーパー アーキテクチャの概要 可用性が高く、レイテンシーの低いソリューションを提供するために、Edison はマルチリージョンアプローチを採用し、カスタム API キャッシュレイヤーを活用して全19の Wavelength Zone をローンチしました。各 Wavelength Zone では、HarperDB の カスタム関数 開発プラットフォームを使用して、レイテンシーを 5 秒以上から 20 ミリ秒以下に短縮する API キャッシュレイヤーを作成しました。各ゴルフカートのレイテンシーを最小限に抑えるため、エッジディスカバリーサービスを活用して、各 Wavelength Zone で最も近い AWS キャリア IP アドレスを特定します。 カスタム関数は HarperDB データレイヤーに直接アクセスできるユーザー定義の API エンドポイントです。これにより、スタンドアロン API からデータベースへの余分なホップが不要になります。その結果、レイテンシーを低減し、複雑さを軽減し、費用対効果の高い水平スケールにも柔軟に対応したアプリケーションとデータの完全なパッケージが完成します。従来モデルでは、モノリシックなデータストアの垂直スケーリングには指数関数的にコスト増加となる点が課題でしたが、この新しい仕組みによって Edison はプラットフォームに対してコースやカートを効率的に追加できるようになりました。 プロビジョニングと監視 19 の Wavelength Zone すべてに HarperDB ノードを効率的にプロビジョニングするために、 AWS Lambda と AWS CloudFormation を利用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Block Store (Amazon EBS) ボリューム、および Amazon Route53 DNS レコードを作成します。CloudFormation は、各 Wavelength Zone の作成の一貫性を担保しながらデプロイを加速させるために不可欠でした。さらにWavelength Zone の数は今後も増加することが見込まれるため、CloudFormation によって一貫性のあるスケーリングテンプレートを提供します。 ノードが構築されると、 Amazon CloudWatch は各ノードのオブザーバビリティとモニタリングを行い、システムの整合性を確認します。リソース使用率が高いなどの特定のシナリオでは、Amazon CloudWatch は HarperDB と Edison Interactive のカスタマーサポートチームにカスタム通知を送信する AWS Lambda 関数をトリガーします。AWS Lambda を使用してカスタムアラートを柔軟に作成できることは、HarperDB チームが Edison Interactive と共同でデプロイを管理するうえで非常に重要でした。 結論 クラブカーの全国各地の車両に低遅延の外出体験を提供するには、AWS Wavelength と HarperDB が必要です。AWS Wavelength を利用するゴルフカートは、低遅延のマルチリージョン接続の最先端にあります。AWS Wavelength はネットワーク遅延を低減しつつ、HarperDB はデータとアプリケーションの両方の配信を管理します。AWS Wavelength と HarperDB の併用は、家庭外（OOH）でのデジタル体験の可能性を再定義した洗練されたソリューションです。 高品質で臨場感あふれるスポーツ体験について詳しくは、こちらをご覧ください。 Verizon が提供する Shark Experience メディアとエンターテイメント向けの 5G と AWS Wavelength を探る HarperDB を使い始めましょう TAGS: telecom , Telecommunications , Wavelength Robert Belson Robert は、AWS エッジコンピューティングを専門とする AWS ワールドワイドテレコムビジネスユニットのデベロッパーアドボケイトです。開発者コミュニティや大企業のお客様と協力して、自動化、ハイブリッドネットワーキング、エッジクラウドを使用してビジネス上の課題を解決することに重点を置いています。 Stephen Goldberg HarperDB の CEO 兼共同創設者である Stephen Goldberg は、スタートアップ企業の CTO 兼 CEO として働き、Red Hat などの大規模組織で複数の役職を歴任し、さまざまな業種の多くのフォーチュン500企業でデジタル変革プロジェクトを主導してきました。データ管理とエッジコンピューティングの分野で定評のあるオピニオンリーダーであり、Tech Target などのサイトに掲載されたり、Forbes や ZDNet などの多くの記事や出版物で引用されたりしています。IoT World、SAP Sapphire、Salesforce.com の Dreamforce などで講演を行ってきました。Stephen は共同創設者の Kyle と Zach と共に 2 件の特許を保有しています。 原文は こちら です。 翻訳はソリューションアーキテクトの鈴木 浩之が担当しました。

DoGet App は、友人と直接会って時間を共有するためのモバイルアプリケーションです。 この投稿では、DoGet Appが彼らのユースケースに対応し、リアルタイムのアクティビティ提案とマッチメイキングを可能にする Amazon Neptune に支えられたグラフデータモデルをどのように採用したかについて紹介します。 この目的のために構築されたデータベースに対するアプローチにより、彼らのサーバーレスアーキテクチャは、AWS AppSync、AWS Amplify、AWS Lambda、 Amazon Simple Storage Service (Amazon S3)を使用し、ローンチ時のスケールと1日あたり数千の新規ユーザーをサービス利用可能にすることを可能にしました。AWSのマネージドサービス上に構築することで、DoGet Appは開発開始からローンチまでわずか6ヶ月と、市場投入までの時間を大幅に短縮することができ、同時にローンチ前の開発工数とローンチ後の運用オーバーヘッドを統合することができました。 上へスワイプすると、そのアクティビティに興味がないことを示し、下へスワイプすると、興味があることを示し、ユーザーがいつ参加できるか（明日や今週など）のフォローアップを促します。そして、DoGet Appは、同じ時間に同じ体験を共有することに興味がある友人をマッチングします。 アプリケーションの設計と立ち上げ時の課題 DoGet Appは、アプリケーションを設計する際にいくつかの課題に直面しました。 まず第一に、多くのマッチメイキング・アプリケーションは、リアルタイム性を考慮することなく、データの読み込み時間を短縮するために事前に提案を生成します。一方、DoGet Appは、過去の習慣や好みだけでなく、他にも多くの提案を生成します。コンテンツの要素は、ユーザーの現在地、天候、友人からの反応を取り入れるため、リアルタイムで提案を生成する必要がありました。 この課題に取り組むため、DoGet Appは自社のアルゴリズムに合わせたグラフデータモデルを持つAmazon Neptuneを使用しました。Amazon Neptuneのグラフデータベースには、ユーザーのすべての人間関係、興味、交流の全体的な状態が一貫してリアルタイム性の高い状態で表現することができ、それに基づいて提案やマッチングがリアルタイムで作成されます。 DoGet Appは、ユースケースに適したデータモデルを選択することに加え、ゼロからユーザーベースのアプリケーションを構築する必要があったため、予測不可能な負荷やトラフィックの増加に対応できるスケーラブルなソリューションが必要でした。また、ユーザーを増やしながら得られた新たな洞察に基づいて、グラフデータモデルと対応するアルゴリズムを迅速に反復構築できる運用モデルも必要でした。 ソリューションの概要 このセクションでは、アプリケーション・アーキテクチャのハイレベルな概要を説明します。 次の図は、アプリケーションのフロントエンドとバックエンド、およびデータ分析機能を含むアーキテクチャ図です。 モバイルアプリケーションのフロントエンドは、 AWS Amplify クライアントライブラリを使用して、AWSクラウドのバックエンドリソースに接続します。典型的なリクエストの流れは以下のようになります。 モバイルクライアントは、静的なフロントエンドアセットを Amazon S3 から取得します Amazon Cognito への認証後、 AWS AppSync が提供するバックエンドAPIにアクセスできるようになります リクエストはその後、 AWS Lambda 関数によって処理されます Amazon DynamoDB と Amazon Neptune から情報を照会し、APIリクエストに対するレスポンスを生成します これらのリクエストに対応する過程で、分析データはAmazon S3のデータレイクに保存されます そこから Amazon Athena で分析を行います グラフデータモデル DoGet Appの機能の中核は、フルマネージド・グラフデータベース・サービスであるAmazon Neptuneに支えられた専用グラフデータベースです。Neptuneを利用することで、DoGet Appは、メンテナンス、バックアップ、スケーリングなどの運用タスクをオフロードすることで、アプリケーションに関連する実際のデータモデルとアルゴリズム設計に集中することができます。 DoGet Appのユースケースにどのようなメリットがあるかを理解するために、グラフデータモデルを深く掘り下げてみましょう。基本的に、グラフのノードはアプリケーションのエンティティを表し、エッジはそれらの間の関係を表します。次の図は、アプリのデータモデルにおける一般的なエンティティを示しています。 この例では、ユーザー Lisa 、 Sophie 、 Benny を表す3つの人物ノードを示しています。人物ノード間のエッジは、それらの友好関係を表します。そして、3つのトピック・クラスタ・ノード（ Outdoor 、 Nature Lover 、 Hiking ）に関連する1つのアクティビティ・ノード（ Explore unknown paths in the surrounding by bike ）があります。 データモデルには、 ジオハッシュ の形で位置情報も組み込まれています（このアプローチでは正確な位置情報は必要ありません）。この情報は、以下の図に示すように、地域ノードによってグラフデータモデルで表現されます。 位置は、その地域に適したアクティビティや天候、また現在地や過去地 点のユーザーと関連しています。エッジの重みは、関係の強さをモデル化するために使用されます。DoGet Appはユーザーを直接つなぐことを目的としているため、位置情報は提案やマッチメイキングを生成する際に特に関連性が高く、特に天候情報を組み込むためにも使用できます。 リアルタイムで提案を生成 ユーザーがその日初めてDoGet Appを開くたびに、一連のアルゴリズムが30～50の活動提案を生成します。これらのアルゴリズムはすべて、Neptuneに保存されているリアルタイムのグラフ表現を直接または間接的に使用しています。バランスの取れた提案のために、さまざまなアルゴリズムを組み合わせて使用します。例えば、新しいアクティビティでユーザーの興味を引くことを目的とするアルゴリズムもあれば、最近友達に好かれたアクティビティを優先してマッチングの可能性を高めるアルゴリズムもあれば、グラフ内の他のエンティティに対するユーザーの最も強い関係を利用するアルゴリズムもあります。 後者に焦点を当てたアルゴリズムの例を探ってみましょう。このアルゴリズムは、ユーザーから出発して、ユーザーがグラフ内で（直接的あるいは間接的に）接続しているアクティビティへのさまざまなパスを探索します。接続の強さとそのタイプ（直接的か間接的か、たとえば友人経由かトピック・クラスタ経由か）に応じて、アルゴリズムはこれらのアクティビティに対するメトリクスを計算し、次の図に示すように、それに基づいて提案を生成します。 このアルゴリズムは、あらゆる種類のコネクションを組み込んでいますが、他のアルゴリズムでは、特定の側面、例えば、地域の活動やその地域で現在起こっているイベントの提案を提供するために、ユーザーの現在地を重視しています。 アルゴリズムに関係なく、グラフデータ構造はリアルタイムで提案を生成するDoGet Appに最適です。さらに、グラフはマッチメイキングにも適しています。ユーザーがアクティビティに興味を示すたびに、マッチング候補がグラフの近くに表示され、すでに友達が気に入っているすべてのアクティビティが含まれ、効率的にクエリできます。 新しいコンテンツを取り入れ、より深い洞察を得る グラフ内のほとんどの関係と対応するエッジの重みは、ユーザーの嗜好と過去の行動に従って時間の経過とともに確立されますが、他のものは明示的にモデル化されます。たとえば、ユーザーがアクティビティに「いいね！」を押して興味を示すと、そのアクティビティと関連するノードとの関係が強化され、接続エッジの重みが増加します。特にローンチ時には、新しいコンテンツ要素の提案を生成することは困難であることが判明しました。前のセクションで説明したように、新しいアクティビティを統合するための1つのアプローチは、アルゴリズムの組み合わせです。 DoGet Appが現在評価しているもう1つのアプローチは、 Amazon Neptune ML を使用することで、グラフ内の関係だけでなく、例えばアクティビティのテキスト記述の類似性などに基づいて提案を行うことです。 最後に、DoGet Appは、アクティビティ提案という点で、提供するコンテンツの改善を常に行っています。そのために、アプリの利用データはAmazon S3に保存され、Athenaで分析して洞察を得ることができます。しかし、グラフのエッジの重みは、嗜好や過去の利用状況を反映して動的に適用されるため、DoGet Appは、最も強いエッジを調べることで、グラフに基づいて分析クエリを実行することもできます。例えば、特定の地域で最も人気のある3つのアクティビティを見つけるには、以下のGremlinクエリを実行し、接続されたアクティビティのエッジの強さで順序付けることができます。 %% gremlin g.V('target-region') .outE().has(label,'goodFor') .order().by('strength',desc).limit(3) .inV().unfold().values('name') DoGet Appは、従来のアナリティクスと併用して、これらの洞察をサービスの改善に活用しています。 まとめ Amazon Neptuneによって、DoGet Appは独自のグラフデータベース管理システムの管理に伴う複雑さを伴うことなく、グラフデータモデルを中心にアプリケーションを構築することができました。このデータモデルと関連アルゴリズムは、DoGet Appが卓越したユーザー・エクスペリエンスを実現するのに役立ちました。グラフアルゴリズムに基づくサジェストは、約25パーセントの受け入れ率を実現しています。さらに、彼らのマッチメイキング・アルゴリズムは、アクティブな友達を持つユーザーとの毎日のマッチングを実現しています。AWSのマネージドサービスを利用することで、DoGet Appはアプリケーションデザインやコンテンツ作成といった差別化に集中することで、ビジネス価値を迅速に生み出すことができます。 この記事を読んで、あなたのユースケースに合ったグラフデータモデルを評価してみたくなりましたか？ それなら、 Amazon Neptune の ユーザーガイド をチェックし、 GitHubでNeptuneのサンプル をハンズオンしてみましょう。 著者について Michael Meidlinger は、AWSのシニア・ソリューション・アーキテクトで、規制産業のエンタープライズ顧客を担当しています。信号処理、統計、ネットワーキング、組み込みシステム開発、Linuxシステム管理のバックグラウンドを持ち、電気通信工学の博士号を取得しました。AWS入社以前は、ミッションクリティカルなコンピュートシステムと安全なクラウドコンピューティングコンセプトに従事しています。 Nils Müller は、オーストリアで生まれで、ウィーナー・ノイシュタットで経営工学を学びました。在学中の2000年に1000PS Internet GmbHを設立しました。1000PSというブランドで、同社はモーターサイクルをテーマとする世界有数のコンテンツプロバイダーとなりました。COVID-19の流行時に、DoGetアプリのアイデアを思いつきました。 本記事は 2023/06/03に投稿された Generate suggestions for leisure activities in real time with Amazon Neptune を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。

このブログは Manish Singh（シニアテクニカルアカウントマネージャー）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 急速に変化するデータ環境（例：大規模なデータが頻繁に作成、共有、複製される状況）により、データストレージの需要が高まっています。多くのお客様は、費用対効果の高いデータの保存方法や、費用をかけずにデータから必要となるすべての情報を入手できる最適な方法を探しています。 クラウドストレージは、「従量課金」モデルによる柔軟なオプションを提供しています。 Amazon Simple Storage Service（Amazon S3） は、業界をリードするレベルのスケーラビリティ、可用性、セキュリティ、そしてパフォーマンスを提供するオブジェクトストレージサービスです。Amazon S3 に移行することで、俊敏性を向上し、過剰なプロビジョニングが不要になることでコストが最適化され、無制限のスケールを享受することができます。 あらゆる規模のお客様が、さまざまなワークロードやユースケースで Amazon S3 を活用しています。そして多くのお客様は、ワークロードに適した ストレージクラス を特定し、 S3 ライフサイクル を設定してストレージコストを削減することを心地よく思います。一方でお客様は、アプリケーションパフォーマンスに影響を与えたり運用上のオーバーヘッドを発生させたりすることなく、Amazon S3 のコストを詳細に調査し、料金を最適化する新しい手段を知りたいと考えています。 このブログでは、適切なストレージクラスを使用するだけではなく、Amazon S3 の料金を最適化する方法についても紹介します。API リクエスト（オペレーション）に関連する Amazon S3 の料金 を可視化する方法、API リクエストが多く発生しているバケットを特定する方法、S3 バケットへの API コールを詳しく調査する方法、API リクエスト費用を最適化する一般的な手順について詳しく説明します。コストを最適化する際の多くに共通することですが、今回紹介する情報は特に Amazon S3 の料金モデルを理解するのに役立つはずです。そして、料金の監視と分析に利用可能なさまざまなツールを使用したり、詳細を確認することができるようになります。 Amazon S3 の料金体系 Amazon S3 に関連する料金 は以下の 6 つに分類できます。 ストレージクラスの GB 単価に基づいて課金される、保存されたデータ容量に対するストレージ料金。 API リクエスト料金とも呼ばれるリクエストとデータ取得料金。例えば、GET、PUT、LIST といった操作で、行われる API の呼び出し回数に基づきます。 インターネットや他リージョンにデータを転送する際のデータ転送料金。 アカウントのバケットに対して有効化する、ストレージ管理と分析機能（S3 インベントリ、S3 ストレージクラス分析、S3 Storage Lens、S3 オブジェクトタグ）の料金。 S3 クロスリージョンレプリケーション、同一リージョンのレプリケーション、および S3 バッチオペレーションに関連する料金。 S3 Object Lambda の料金。 ストレージ料金やデータ転送料金を別にすると、GET、PUT、LIST、HEAD やライフサイクル移行などの API リクエストは Amazon S3 における料金の特に大きな部分を占めています。現在の Amazon S3 コスト最適化手法のほとんどは、適切なストレージクラスの特定やデータ転送の最適化に重きを置いており、API リクエスト料金については考慮に漏れがちです。 リクエストとデータ取得（API リクエスト）の料金は、以下の 2 つの要素に基づきます。 S3 バケットやオブジェクトに対して行われる、GET、PUT、ライフサイクル移行などの API リクエストの種類。1000 リクエスト毎の料金については、 Amazon S3 料金ページ の「リクエストとデータ取り出し」セクションを参照してください。 S3 バケットに対して行われた API リクエスト数。API リクエストの料金はリクエスト数に基づき、データのサイズやリクエストがコンソールや CLI、SDK のいずれを介して実行されたかは関係ありません。例えば、コンソールからの GET リクエストと CLI からの GET リクエストの料金は同じになります。同様に、1 KB のファイルと 1 MB のファイルの GET リクエスト料金は同じになります。 API リクエストに関連する料金は、 AWS Cost Explorer や AWS コストと使用状況レポート （AWS CUR）において、PutObject や ListObject などの名前で確認することができます。 AWS Cost Explorer を使用し Amazon S3 の料金を可視化する AWS Cost Explorer は Amazon S3 の API リクエスト料金を可視化し、料金に大きく影響している API リクエストの絞り込みに役立ちます。 AWS Cost Management にサインインし、 Cost Explorer に移動します。 フィルターセクション の サービス から、 S3（Simple Storage Service） を選択します。 適用 をクリックします。 フィルターセクション の 使用タイプグループ から、 S3: API Requests – Glacier、S3: API Requests – Standard、S3: API Requests – Standard Infrequent Access、 S3: Data Retrieval – Standard Infrequent Access  などの状況に適したフィルターを選択します。 適用 をクリックします。 API リクエストの種類を分析するために、 グループ化の条件セクション にて API オペレーション を選択します。 分析したい 日付範囲 を選択し、 適用 をクリックします。 これにより、さまざまな API リクエストのコストと利用状況を示すグラフが表示されます。 CSV 形式でダウンロード を選択することで、API リクエスト数と関連料金をより自由に分析できます。 API リクエスト料金が発生しているバケットを特定する Amazon S3 の料金を大きく占める API を特定したら、 コストと使用状況レポート のデータを使用することで、バケットレベルの詳細を取得できます。以下は Amazon Athena を使用してコストと使用状況のデータを分析し、API リクエストが行われたバケットを特定する方法です。 コストと使用状況レポートの作成 に従って、コストと使用状況レポートを有効化します。この時、バケットの詳細を取得する必要があるので、 リソース ID を含める を選択します。 Amazon Athena を使用したコストと使用状況レポートのクエリ に従って、コストと使用状況レポートを Amazon Athena と統合します。 コストと使用状況レポートを有効化して Amazon Athena と統合できたら、次のクエリを実行し、バケット情報と関連する API リクエストとその料金の詳細を取得します。 SELECT "line_item_operation" as API , "line_item_resource_id" as Bucket , SUM ( "line_item_blended_cost" ) as Cost FROM << CUR_TABLE_NAME >> WHERE "product_product_name" = 'Amazon Simple Storage Service' AND "line_item_usage_type" not like '%Byte%' AND "line_item_resource_id" != '' AND line_item_usage_start_date >= CAST ( 'YYYY-MM-DD 00:00:00' AS TIMESTAMP ) AND line_item_usage_start_date < CAST ( 'YYYY-MM-DD 00:00:00' AS TIMESTAMP ) GROUP BY "line_item_operation" , "line_item_resource_id" ORDER BY SUM ( "line_item_blended_cost" ) DESC SQL CUR_TABLE_NAME と日付の範囲（ YYYY-MM-DD 00:00:00 ）を変更し、さまざまなバケットごとの API 料金を取得します。この情報は、バケットとそれに関連する API リクエスト料金の特定に役立ちます。 結果は次の表のようになります。 API Bucket Cost S3-GlacierTransition Bucket 1 $$$ ListBucket Bucket 2 $$$ PutObject Bucket 3 $$$ バケットに対して行われた API リクエストの分析 Amazon S3 サーバーアクセスログ は、バケットに行われたリクエストの詳細を記録します。サーバーアクセスログを有効化し、 Amazon Athena を使用して API リクエストを分析します。 サーバーアクセスログを有効化し、Amazon Athena と統合します。詳細は Amazon Athena を使用して Amazon S3 サーバーアクセスログを分析する を参照してください。 次のクエリを実行して、API リクエスト数の多い IP アドレスを特定します。 SELECT remoteip , requester , useragent , COUNT ( * ) AS remote_count FROM << access_log_bucket >> WHERE Operation = 'api_call_to_review' AND parse_datetime ( RequestDateTime , 'dd/MMM/yyyy:HH:mm:ss Z' ) BETWEEN parse_datetime ( '2021-08-08:00:00:00' , 'yyyy-MM-dd:HH:mm:ss' ) AND parse_datetime ( '2021-10-08:00:00:00' , 'yyyy-MM-dd:HH:mm:ss' ) GROUP BY remoteip , requester , useragent order by remote_count desc SQL ステップ 1 にて作成したテーブルを access_log_bucket  にて指定し、 REST.GET.BUCKET 、 REST.GET.LIFECYCLE 、 REST.GET.OBJECT 、 REST.PUT.OBJECT 、 REST.HEAD.OBJECT 等のトラックしたい要素を api_call_to_review にて指定します。また分析を行いたい時間の範囲も適宜指定してください。 API リクエストをさらに詳しく分析する際に使用できる他の列名について理解したい場合は、 サーバーアクセスログのフォーマット に関するドキュメントを参照してください。 API 料金を最適化するさまざまな方法 コスト最適化を行いたい API コールとバケットを特定したら、以下の一般的なコスト最適化手法を参照してください。 GetObject と PutObject GetObject と PutObject リクエストは、それぞれ S3 バケットからオブジェクトを取得、S3 バケットにオブジェクトを追加するために使用され、これらは頻繁に使用されます。GET および PUT API のコストは、追加および取得されるオブジェクト数に依存し、サイズは影響しないことを踏まえて戦略を検討します。 小さなオブジェクトが多数存在する場合、GET および PUT API のコストが高くなる可能性があります。アプリケーションのアーキテクチャを見直し、複数の小さなオブジェクトから、1 つの大きなオブジェクトに置き換えられないか検討してください。例えば、1 分ごとにファイルを作成する代わりに、過去 15 分間、もしくは 30 分間に加えられた変更データを使用するなど、より長い時間に基づいてファイルを作成しましょう。 .tar や .zip ファイルを作成して、オブジェクトを 1 つのファイルにまとめます。この時、まとめられたファイル内における個々のオブジェクトの識別や、アクセスのしやすさを考慮する必要があります。 S3 パブリックアクセスブロック を使用することで、バケットレベルもしくはアカウントレベルでオブジェクトへのパブリックアクセスをブロックし、不正アクセスや予期しない API 料金の発生を防ぐことができます。 静的オブジェクトが多数を占める場合、 Amazon CloudFront を使用した GET リクエスト数の削減を検討してください。この場合、費用対効果の分析を別途行い、Amazon CloudFront を導入することでコストが削減され期待に応えることができるか判断する必要があります。 コストと使用状況レポートを使用して、S3 バケットのストレージ料金と API リクエスト料金（GET、PUT、LIST）を比較します。S3 バケットの料金のうち API リクエストが多くを占める場合、最適なストレージクラスが選択できているのか、もしくは Amazon DynamoDB といった他の選択肢がワークロードに適しているのか検討する必要があります。 ListBucket ListBucket は特定のバケットにおけるオブジェクトの一覧を表示するために使用されます。特定の S3 バケットにおいて ListBucket の料金が高い場合は、アプリケーションの設計を再確認し、この操作を頻繁に利用する理由を確認してください。またその理由を基に、HEAD リクエストで代替できないか検討してください。 S3 ライフサイクル移行 S3 ライフサイクル移行ルールは、オブジェクトを別のストレージクラスへ移行する際や期限切れにする際に使用されます。ライフサイクルの移行ルールの内容に応じて、次の 2 種類の料金が発生します。 移行料金：あるストレージクラスから別のストレージクラスに移行されたオブジェクト数に基づきます。 早期削除料金：一部ストレージクラスに定められた最小ストレージ期間を満たさない場合、 削除料金 が発生します。 S3 ライフサイクル移行ルールをバケット全体に適用するだけではなく、プレフィックスやオブジェクトタグ、オブジェクトサイズに基づいたフィルタリングを設定することで、移行料金を削減することができます。S3 ライフサイクル移行に関連するコストを管理するには、以下の 4 つのオプションを参考にしてください。 移行するオブジェクト数を減らす ライフサイクル移行ルールを適用するためにアクセスパターンを分析し、適切な S3 バケットとプレフィックスの範囲、および適切なストレージクラスを特定します。ライフサイクル移行ルールを設定する前に、 S3 ストレージクラス分析 や S3 Storage Lens などのツールを使用してアクセスパターンを監視し、オブジェクトサイズや総オブジェクト数などのさまざまなメトリクスを確認します。 ライフサイクル移行する前に、小さなオブジェクトを大きなファイル（.tar、.zip）にまとめてください。移行コストは移行されるオブジェクト数に基づくため、小さなオブジェクトを大きなファイルにまとめることで料金を削減できます。複数のオブジェクトをまとめる際は、検索性の考慮が必要になります。 オブジェクトタグはオブジェクトに関連づけられるキーと値のペアです。プレフィックスや 1 つ以上のオブジェクトタグ、またはその両方を使ってライフサイクル移行ルールにフィルターを定義し、移行または期限切れになるオブジェクト数を制限します。詳細については、 S3 ライフサイクル移行ルールの設定 に関するブログも参照ください。例えば、key が transition、value が glacier のオブジェクトのみを、 Amazon S3 Glacier ストレージクラス のいずれかに移行するといったことができます。以下は詳細な手順となります。 Amazon S3 コンソールにアクセスし、設定したいバケットの 管理タブ に移動します。 ライフサイクルルールを作成する を選択します。 フィルターを指定するため、 ルールスコープを選択 にて 1 つ以上のフィルターを使用してこのルールのスコープを制限する を選択します。 フィルタータイプのセクションにて プレフィックス を指定し、ルールの適用範囲を絞り込みます。 同じくフィルタータイプのセクションにて、 オブジェクトタグ の下にある タグの追加 を選択します。各タグはキーと値（任意）の両方に一致する必要があります。また、指定されたすべてのタグを持つオブジェクトに対してのみ、ルールが適用されます。もしオブジェクトに他のタグが存在していても、ルールは適用されます。 ライフサイクル移行ルールの目的でタグを追加する前に、費用対効果の分析を行って、オブジェクトタグを含めた費用削減効果を見積もってください。オブジェクトタグに関連する費用の詳細については、 Amazon S3 の料金 を参照してください。 ライフサイクル移行ルールを適用する前に、最小オブジェクトサイズと請求要件を理解してください。S3 Standard-Infrequent Access（S3 Standard-IA）および S3 One Zone-IA ストレージクラスの課金対象最小オブジェクトサイズは 128 KB です。つまり、128 KB 未満のオブジェクトを S3 Standard-IA や S3 One Zone-IA に移行しても、期待通りのコスト削減は果たせません。ストレージクラスごとに定められた最小オブジェクトサイズを確認するには S3 ストレージクラスのパフォーマンスチャート を参照してください。 ライフサイクル移行ルールは、オブジェクトサイズを基にしてフィルターを定義できます。コストを節約するために小さいファイルを移行したくない場合は、最小、最大オブジェクトサイズに基づいたフィルターが活用できます。 オブジェクトを移行、または期限切れにする S3 ライフサイクルルールを作成する前に、アクセスパターンに加えて、データ保持要件と各ストレージクラスの最小ストレージ期間を確認してください。例えば、S3 Standard-IA や S3 One Zone-IA には 30 日間の最小ストレージ期間が、S3 Glacier Instant Retrieval や S3 Glacier Flexible Retrieval には 90 日間の最小ストレージ期間が設けられ課金されます。ストレージクラスごとの最小ストレージ期間を確認するには S3 ストレージクラスのパフォーマンスチャート を参照してください。最小ストレージ期間を経過せずにオブジェクトの移行や期限切れを行った場合、最小ストレージ期間に満たない日数分が日割りで DeleteObject 料金として発生します。 S3 Storage Lens を使用することで、オブジェクトストレージの使用状況とアクティビティの傾向を可視化できます。S3 Storage Lens は、オブジェクト数、平均オブジェクトサイズ、PUT リクエスト、GET リクエスト、LIST リクエストなど 30 を超えるメトリクスを提供しており、ライフサイクル移行ルールの微調整や API リクエスト料金の最適化に役立ちます。以下は S3 Storage Lens を活用する手順の一例です。 S3 Storage Lens に関するブログ を参考に、ダッシュボードを作成します。 ダッシュボードを開きタブの中から バケット を選択します。特定のプレフィックスを分析したい場合は、 プレフィックス を選択してください。 総ストレージ量 、 オブジェクト数 、 オブジェクトサイズの平均 等のメトリクスを確認し、移行コストを見積もってライフサイクル移行ルールを決定します。 メトリクスのカテゴリからアクティビティを選択し、 GET リクエスト 、 PUT リクエスト 、 HEAD リクエスト 、 LIST リクエスト などのメトリクスを確認して、API リクエストを分析します。 クリーンアップ 継続的に課金されないようにするには、このブログを基に作成したリソースを削除してください。 Amazon S3 の サーバーアクセスログ を停止してください。 S3 ストレージクラス分析や S3 Storage Lens などの Amazon S3 の管理および分析ツールを停止してください。 まとめ このブログでは、様々な Amazon S3 の API リクエストに関連する料金の可視化と分析について説明しました。そして、AWS Cost Explorer やコストと使用状況レポート、サーバーアクセスログをそれぞれ使用して、S3 バケットに関連する API リクエスト料金を特定する方法を示し、料金を最適化するための複数のアプローチを確認しました。 Amazon S3 を使用するお客様は、適切なストレージクラスの活用やデータ削除を行うことで、長年コストを最適化してきました。Amazon S3 へのリクエストや取り出し（API リクエスト）がどのように課金されるのか、また API リクエスト料金を削減するための一般的なアプローチを理解することで、さらなるコストの最適化が達成できます。API リクエストの料金体系を理解することで、管理者や開発チームは正しいアーキテクチャを設計でき、予想外の料金を回避することができます。 Amazon S3 のコストを削減するための、リクエスト料金とデータ取得料金の最適化に関するこのブログをお読みいただきありがとうございました。 Manish Singh Manish Singh は Amazon Web Service のインド、バンガロール拠点に所属する、シニアテクニカルアカウントマネージャーです。Manish は 19 年以上の業界経験を持ち、クラウドアーキテクチャと IT システム設計に関する専門知識を備えています。彼はクラウド財務管理ソリューションに強い関心を持っており、AWS エンタープライズサポートのお客様に向けてコスト最適化の提案を行っています。

今日のデジタルランドスケープでは、最適なアプリケーションパフォーマンスを確保することが非常に重要であり、Amazon CloudWatch Synthetics はウェブアプリケーションと API のプロアクティブなテストを可能にします。このブログでは、自己署名証明書を利用して監視機能を強化したい場合、エンドポイントの自己署名証明書をサポートするように Canary のソースコードを変更する方法を順を追って説明します。最大の利点は、この方法では認証プロセスを変更する必要がないことです。 Amazon CloudWatch Synthetics Canary をハートビートブループリントとともに使用して、自己署名証明書に依存するアプリケーションをモニタリングする方法を説明します。自己署名証明書とは、(公式機関に) 承認されていない信頼できる第三者認証局（CA）によって発行および署名された証明書です。 さらに、API を監視する他の方法について説明している以前のブログを確認することをお勧めします。 Multi-step API monitoring using Amazon CloudWatch Synthetics というタイトルのブログでは、Amazon CloudWatch Synthetics スクリプトを作成して、マルチステップ API 検証を実行し、API の機能性と安定性を確保するための詳細な手順を紹介しています。さらに、2 つ目のブログ How to validate authentication using Amazon CloudWatch Synthetics – Part 2 では、Synthetic ブループリントを更新して、サーバーとクライアントの両方が相互認証 (mTLS) のためにデジタル証明書の提示する必要のあるアプリケーションをモニタリングするための方法を順を追って説明しています。これらのリソースは理解を補完し、包括的な監視戦略を構築するのに役立ちます。 ソリューション概要 このソリューションでは、既存のブループリントに基づいてハートビートモニター Canary を作成し、提供されたブループリントに自己署名証明書を挿入する手順を示します。これにより、ブループリントが提供する機能を拡張できます。 Canary の作成 CloudWatch Synthetics では、すぐに使用できるブループリントスクリプトを利用できます。ただし、証明書で認証するには、コンソールのエディターを使用してコードスニペットを追加する必要があります。 CloudWatch Synthetics がどのように認証を処理するかをシミュレートするために、 self-signed.badssl.com ウェブサイトを使用します。独自の HTTP エンドポイントを使用して同じ出力をシミュレートすることもできます。証明書がまだ追加されていないため、最初の呼び出しでは失敗応答が返されます。ただし、このエラーは次の手順で修正されます。 ハートビートブループリントスクリプトに基づいて Canary を作成する手順 CloudWatch コンソール の 「Synthetics」メニューを開きます。 Canary を作成 を選択します。 設計図のリストから ハートビートのモニタリング  を選択します。 名前 に Canary の名前を入力します。たとえば、「https-selfsigned-test」と入力します。 アプリケーション または エンドポイント URL に 「 https://self-signed.badssl.com/ 」 を入力します。 その他の設定はすべてデフォルトのままにしてください。必要な権限を持つ IAM ロールが自動的に作成され、さらに「cw-syn-results-accountID-region」 という名前のバケットが作成されます。バケットがアカウントにすでに存在する場合は、「cw-syn-results」 という名前を検索するか、独自の名前を作成できます。詳細については、 Canary を作成する を参照してください。 「Canary を作成」を選択します。Canary が作成されると、図 1 に示すように、Canary のリストに表示されます。Canary のハートビートモニターブループリントの使用方法については、Amazon CloudWatch ユーザーガイド の ハートビートのモニターリング を参照してください。 図 1. CloudWatch コンソールの Canary ページ レポートの確認 Canary レポートには、すべてのステップと結果が表示されます。この場合、Canary は図 2 に示すように ERR_CERT_AUTHORITY_INVALID エラーを返しました。エンドポイントは信頼できる CA によって発行されていない証明書を使用しており、Canary は信頼された認証局に対して自己署名証明書の信頼性を検証できないため、このエラーは予想されるものです。 図 2. HTTP-steps-test レポートが ERR_CERT_AUTHORITY_INVALID というエラーで失敗 証明書の詳細をダウンロード 自己署名証明書に関する検証の問題に対処するために、badsslのWebサイトから必要な証明書をダウンロードできます。このダウンロードされた証明書は信頼を確立する目的で使用され、 self-signed.badssl.com エンドポイントに対して行われた API リクエストを認証するために Canary によって使用されます。以下のステップは、AWS CloudShell 上で CLI コマンドを使用して、これを実現する方法を示していますが、これらの証明書はブラウザを使用して badssl ウェブサイトから手動でダウンロードすることもできます。 Note: 発行元が信頼できることが確実でない限り、自己署名証明書はお勧めしません。 badssl.com からパブリック証明書をダウンロード この手順では、AWS リソースの安全な管理、探索、操作を容易にするブラウザベースのシェルである AWS CloudShell を使用します。以下のスクリプトを実行するには CloudShell をお勧めします。ただし、同じ出力には独自のコマンドラインを使用することもできます。 self-signed.badssl.com から.pem ファイルをダウンロードするには、以下の手順に従います。 CloudShell コンソールを開きます。 環境が作成されるのを待ちます。 以下のスクリプトをコピーして、AWS CloudShell によって作成された bash コンソールに貼り付けます。 # Install openssl if you don't have that installed # Ubuntu users -> sudo apt-get install openssl sudo yum install openssl -y # Download the self-signed.badssl.com certificate openssl s_client -showcerts -connect self-signed.badssl.com:443 -servername self-signed.badssl.com </dev/null | sed -n -e '/-.BEGIN/,/-.END/ p' | awk '{printf "%s%s", (NR>1 ? "\\n" : ""), $0} END {print ""}' > self-signed.pem # Get the certificate content to be pasted on the canary code cat self-signed.pem 「貼り付け」を選択します。 図 3. 複数行のテキストを貼り付けるための CloudShell ポップアップ 上記のスクリプトは証明書を含むテキストを生成します。次のステップで使用するため、 —–BEGIN CERTIFICATE—– で始まり —–END CERTIFICATE—– で終わる内容をコピーします。 Canary スクリプトを編集して証明書を追加 証明書をインポートするには、作成した Canary にアクセスし、先ほどコピーした証明書の出力を含む変数を追加する必要があります。 コードを編集するには、次の手順に従います。 CloudWatch コンソール の Synthetics メニューを開きます。 作成した Canary を選択してください。たとえば、 https-selfsigned-test です。 アクション  を選択し、 編集  を選択します。 スクリプトエディタ のボックスを使用して、スクリプトの上部で https パッケージをインポートします。このパッケージにより、スクリプトは証明書に利用するようにプロトコルの設定を調整できます。 const https = require('https'); ‘page.goto()’ 関数を使用してエンドポイントにアクセスする前に、以下のコードブロックを挿入してください。ブループリントの場合、これは 非同期関数 loadBlueprint の ‘const sanitizedUrl’ 行と ‘const response = await page.goto...’ 行の間にあります。 await page.setRequestInterception(true); const cert = '<YOUR_CERTIFICATE_HERE>' log.info("Injecting request with self-signed certificate."); page.on("request", (interceptedRequest) => { const options = { method: interceptedRequest.method(), headers: interceptedRequest.headers(), body: interceptedRequest.postData(), ca: cert, cert: cert, }; const request = https .request(interceptedRequest.url(), options, function (response) { response.on("data", function (data) { interceptedRequest.respond({ status: response.statusCode, contentType: response.headers["content-type"], headers: response.headers, body: data, }); }); }) .on("error", function (err) { console.error("Unable to call %s", options.uri, err); return interceptedRequest.abort("connectionrefused"); }); request.end(); }); Note: このコードは、Canary からエンドポイントへのリクエストをインターセプトし、アップロードした証明書を信頼できる認証局として含めるようにリクエストオプションを変更します。 例えば、コードの全文は以下のようになります。 const { URL } = require('url'); const synthetics = require('Synthetics'); const log = require('SyntheticsLogger'); const syntheticsConfiguration = synthetics.getConfiguration(); const syntheticsLogHelper = require('SyntheticsLogHelper'); const https = require('https'); const loadBlueprint = async function () { const urls = ['https://self-signed.badssl.com/']; // Set screenshot option const takeScreenshot = true; /* Disabling default step screen shots taken during Synthetics.executeStep() calls * Step will be used to publish metrics on time taken to load dom content but * Screenshots will be taken outside the executeStep to allow for page to completely load with domcontentloaded * You can change it to load, networkidle0, networkidle2 depending on what works best for you. */ syntheticsConfiguration.disableStepScreenshots(); syntheticsConfiguration.setConfig({ continueOnStepFailure: true, includeRequestHeaders: true, // Enable if headers should be displayed in HAR includeResponseHeaders: true, // Enable if headers should be displayed in HAR restrictedHeaders: [], // Value of these headers will be redacted from logs and reports restrictedUrlParameters: [] // Values of these url parameters will be redacted from logs and reports }); let page = await synthetics.getPage(); await certRequestIntercept(page) for (const url of urls) { await loadUrl(page, url, takeScreenshot); } }; const certRequestIntercept = async function(page) { await page.setRequestInterception(true); const cert = '<YOUR_CERTIFICATE_HERE>' log.info("Injecting request with self-signed certificate."); page.on("request", (interceptedRequest) => { const options = { method: interceptedRequest.method(), headers: interceptedRequest.headers(), body: interceptedRequest.postData(), ca: cert, cert: cert, }; const request = https.request(interceptedRequest.url(), options, function (response) { response.on("data", function (data) { interceptedRequest.respond({ status: response.statusCode, contentType: response.headers["content-type"], headers: response.headers, body: data, }); }); }).on("error", function (err) { console.error("Unable to call %s", options.uri, err); return interceptedRequest.abort("connectionrefused"); }); request.end(); }); } // Reset the page in-between const resetPage = async function(page) { try { await page.goto('about:blank',{waitUntil: ['load', 'networkidle0'], timeout: 30000} ); } catch (e) { synthetics.addExecutionError('Unable to open a blank page. ', e); } } const loadUrl = async function (page, url, takeScreenshot) { let stepName = null; let domcontentloaded = false; try { stepName = new URL(url).hostname; } catch (e) { const errorString = `Error parsing url: ${url}. ${e}`; log.error(errorString); /* If we fail to parse the URL, don't emit a metric with a stepName based on it. It may not be a legal CloudWatch metric dimension name and we may not have an alarms setup on the malformed URL stepName. Instead, fail this step which will show up in the logs and will fail the overall canary and alarm on the overall canary success rate. */ throw e; } await synthetics.executeStep(stepName, async function () { const sanitizedUrl = syntheticsLogHelper.getSanitizedUrl(url); /* You can customize the wait condition here. For instance, using 'networkidle2' or 'networkidle0' to load page completely. networkidle0: Navigation is successful when the page has had no network requests for half a second. This might never happen if page is constantly loading multiple resources. networkidle2: Navigation is successful when the page has no more then 2 network requests for half a second. domcontentloaded: It's fired as soon as the page DOM has been loaded, without waiting for resources to finish loading. If needed add explicit wait with await new Promise(r => setTimeout(r, milliseconds)) */ const response = await page.goto(url, { waitUntil: ['domcontentloaded'], timeout: 30000}); if (response) { domcontentloaded = true; const status = response.status(); const statusText = response.statusText(); logResponseString = `Response from url: ${sanitizedUrl} Status: ${status} Status Text: ${statusText}`; //If the response status code is not a 2xx success code if (response.status() < 200 || response.status() > 299) { throw new Error(`Failed to load url: ${sanitizedUrl} ${response.status()} ${response.statusText()}`); } } else { const logNoResponseString = `No response returned for url: ${sanitizedUrl}`; log.error(logNoResponseString); throw new Error(logNoResponseString); } }); // Wait for 15 seconds to let page load fully before taking screenshot. if (domcontentloaded && takeScreenshot) { await new Promise(r => setTimeout(r, 15000)); await synthetics.takeScreenshot(stepName, 'loaded'); await resetPage(page); } }; const urls = []; exports.handler = async () => { return await loadBlueprint(); }; 先ほど貼り付けたコードの <YOUR_CERTIFICATE_HERE> を置き換えて、証明書の内容を追加します。 const cert = '<YOUR_CERTIFICATE_HERE>' 保存 を選択します。 証明書のハードコーディングはベストプラクティスではありませんが、このブログでは手順を効率化するためにこのアプローチを採用しました。加えて、今回の証明書は公開されているため、リスクは低くなります。ベストプラクティスに従い、環境へデプロイする際のリスクを軽減には、 How to validate authentication using Amazon CloudWatch Synthetics – Part 2 の説明のように、AWS Secrets Manager を使用することで、シークレットを安全に保存できます。 コードを変更したら、保存して Canary が再び実行されるのを待ちます。Canary の実行 が 成功 し、ステップのタブでリクエストステータスが 成功 と表示されるはずです。 図 4: https-selfsigne-test のステータスが「成功」と表示される Synthetics の使用方法にすでに慣れているユーザー向けに、証明書を含む Canary スクリプトを ZIP ファイルにバンドルできる高度なオプションが用意されています。このアプローチについては、 Node.js Canary スクリプトの記述 と Python Canary スクリプトの記述 というドキュメントで説明されており、シームレスな実装のための包括的なガイダンスが提供されています。 クリーンアップ Canary を削除すると元に戻すことはできず、関連するデータと設定はすべて失われることに注意してください。削除を続行する前に、必要なバックアップをすべて作成するか、関連するデータをすべて抽出したことを確認してください。 CloudWatch Synthetics Canary を削除するには、以下の手順に従ってください。 CloudWatch コンソール の Synthetics メニューを開きます。 上記で作成した Canary を選択してください。たとえば、 https-selfsigned-test です。 アクション を選択し、 中止 を選択します。 Canary の状態が 停止 に変わるまで待ってください。 もう一度 アクション  を選択し、  削除 を選択します。 Canary が使用する ロール と ロールポリシー など、削除するリソースを選択します。 Canary によって作成されたリソースを削除するには、 削除 を選択します。 このワークショップで作成したリソースを削除することを確認するには、フィールドに Delete というフレーズを入力します。 確認 を選択します。 コンソール上で、選択したリソースが削除され、Canary が正常に削除されたことが表示されます。 図 5. Canary が削除されたことを示す Synthetics ページ 結論 このブログでは、CloudWatch Synthetics で自己署名証明書を利用する方法について説明しました。これにより、証明書が信頼できるサードパーティ CA によって署名されていなくても、ブループリントの機能を拡張して API に接続できるようになりました。これらの知見を武器に、自信を持って自己署名証明書を自分のプロジェクトに実装できます。 この機能やその他のすべての機能の使用方法の詳細については、 CloudWatch Synthetics のドキュメント をご覧ください。また、Synthetics の AWS Command Line Interface (CLI) ドキュメントは こちら にあります。 著者について Mario Jorge Salheb Leitao Mario Leitao は、シドニーを拠点とする AWS Managed Services (AMS) チームの Senior Cloud Architect です。技術ガイダンスを提供し、お客様が AWS で成功できるように、費用対効果が高く効率的なソリューションを設計および構築しています。Cloud Architect として働く前は、アイルランドのダブリンで Network Development Engineer として働いていました。 Matheus Canela Matheus は、Amazon Web Services の Solutions Architect として、デジタルネイティブ企業にテクノロジープラットフォームの変革について助言し、ベストプラクティスに従ってあらゆるレベルのエンジニアが目標を達成できるよう支援しています。AWS に入社する前、Matheus はシドニーを拠点とする Premier Consulting Partner である CMD Solutions で Senior DevOps Consultant を務めていました。Matheus は開発者およびセキュリティスペシャリストとしても働いてきました。コミュニティを支援することが彼のDNAであるため、.NET Meetups を開催し、IT.BR コミュニティを支援して、ブラジルからオーストラリアに移住するエンジニアを支援しています。 Edgar Yu Edgar は AWS の CloudWatch Synthetics チームの Software Development Engineer です。彼の現在の焦点は、顧客がより多くのパフォーマンスデータを収集し、ウェブアプリケーションをより適切に監視できるようにするソフトウェアの構築と改善にあります。AWS 以外では、彼は食事を楽しんでいます。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

このブログ記事は Chen Xiaoyu （BytePlus社 MLソリューションディレクター）と Hao Chen（Customer Success Engineer on the Amazon IVS team） および Tian Shi（Senior Solutions Architect at AWS）の共著によるものです。 Sandvine’s Global Internet Phenomena Report によると、2022 年の全インターネットトラフィックの 65 ％以上が動画コンテンツでした。この数字は 2021 年から 24 ％増加しており、クリエーターたちがストリーミング動画を通じて視聴者にリーチするために利用可能なプラットフォームの増加に伴い、さらに増えていく傾向にあります。 広大で、多様性に富み、更に成長していく市場に対し、あなたのユーザー生成コンテンツ (UGC) プラットフォームを際立たせるのは至難の業でしょう。いくつかのプラットフォームが成功を収めているひとつの方法として、拡張現実 (AR) のような機能を加えるというものがあります。 BytePlus Effects は、AR エンゲージメントツールの広範囲にわたるライブラリを有する SDK であり、デベロッパーがどのようにこれらの機能を素早く組み込むことができるかという一例です。SDK はオフラインで提供されますので、全てのエフェクトはユーザーのデバイス上で、クラウドに個人データを送信することなく作成されます。 このアプローチにはいくつか長所があるものの、ユーザーとの信頼を確立するポジティブな体験を創りあげるには高性能化とユーザーデータのプライバシーが最重要課題です。 BytePlus Effectsはあなたのライブストリーミング UGC プラットフォームとインテグレートすることもできます。このブログ記事では、 Amazon intaractive video service (Amazon IVS) へ配信する iOS アプリケーションをライブラリを使って生成する方法について紹介します。 必要なもの まず、必要なものをセットアップしてください: AWS アカウント （Amazon IVS Console を使います） Amazon IVS ストリーミングチャンネル （Amazon IVS Console から直接または Amazon IVS API を介して生成します） ストリーミングチャンネルを生成したら、Amazon IVSが提供する以下の情報を確認してください: インジェストサーバーのURL ストリームキー プレイバック URL Amazon IVS チャンネルに関する完全ガイドについては、 Getting Started with Amazon IVS ガイドを参照してください。 SDK のインストール SDKを簡単にインストールするには、CocoaPods を介して SDK をインテグレートするのをお勧めします。Amazon IVS も BytePlus も両方とも CocoaPods に対応しています。詳しくは Amazon IVS Broadcast SDK (iOS) Istallation Guide と BytePlus Effect SDK (iOS) Instration Guide をご覧ください。 インテグレートステップ デフォルトとして、Amazon IVS iOS broadcast SDK は、ストリーミングのためにデバイスカメラ画像を制御し撮像するための API を提供します。BytePlus Effect SDK をインテグレートするために、デバイスカメラを制御し、BytePlus Effect SDK を使って画像を処理し、処理した画像を CustomImageSource を介して IVS ブロードキャスト SDK に転送してストリーミングするアプリケーションロジックを作ります。このブログ記事では、Amazon IVS iOS broadcast SDK と BytePlus Effect SDK に対応する Object-C code を使ったインストールステップを紹介します。 ブロードキャストセッションをセットアップ CustomImageSource 設定をセットアップ 動画キャプチャーをセットアップ 本例では BytePlus Effect SDK に BEVideoCapture を介してカメラにアクセスさせますが、アプリケーションデベロッパーは他の入力ソースを選んで使用しても構いません。 撮像した画像を BytePlus Effect SDK を使って処理 CustomImageSource に処理した画像バッファを送信 配信をスタート 配信セッションのセットアップ 詳細なSDKマニュアルについては、GitHub 上にある Amazon IVS Documentation page と sample application をご覧ください。 CustomImageSource を配信設定でセットアップ CustomImageSource は Amazon IVS Broadcast SDK の 拡張機能 です。これによりアプリケーションデベロッパーはカスタム入力ソースから画像バッファを提出し、ストリーミングできます。 配信設定 CustomImageSource を配信セッションの入力ソースとして使用して、まず配信設定をセットアップする必要があります。本例では、プレセットした設定 standardPortrait を使います。 // Create Broadcast Configuration IVSBroadcastConfiguration *config = [[IVSPresets configurations] standardPortrait]; ミキサースロット設定 CustomImageSource を入力ソースとして使うために、Broadcast SDK のミキサー機能を使って、カスタムミキサー設定を生成します。 ミキサー とは、複数の入力ソース（スロット）を受け取り、インジェスト用のひとつの出力を生成する動画処理ユニットです。例示のために本例では使用するスロットはひとつです。 // Set up Mixer Slot Configuration IVSMixerSlotConfiguration *customSlot = [IVSMixerSlotConfiguration new]; customSlot.size = config.video.size; customSlot.position = CGPointMake(0.0, 0.0); customSlot.preferredAudioInput = IVSDeviceTypeUserAudio; customSlot.preferredVideoInput = IVSDeviceTypeUserImage; NSError *customSlotError = nil; NSString * const customSlotName = @"custom-slot"; [customSlot setName:customSlotName error:customSlotError]; // Set this slot to Broadcast configuration we have created above config.mixer.slots = @[customSlot]; 配信セッション 最後に上記の設定で配信セッションをセットアップします。 NSError *broadcastSessionError = nil; // providing nil to the camera descriptor parameter to let application logic to take control of the camera device IVSBroadcastSession *broadcastSession = [[IVSBroadcastSession alloc] initWithConfiguration:config descriptors:nil delegate:nil error:&amp;broadcastSessionError]; // Attach custom audio input source id customAudioSource = [broadcastSession createAudioSourceWithName:@"custom-audio"]; [broadcastSession attachDevice:customAudioSource toSlotWithName:customSlotName onComplete:nil]; // &lt;connect to your onComplete callback function&gt; self.customAudioSource = customAudioSource; // Attach custom image input source id customImageSource = [broadcastSession createImageSourceWithName:@"custom-image"]; [broadcastSession attachDevice:customImageSource toSlotWithName:customSlotName onComplete:nil]; // &lt;connect to your onComplete callback function&gt; self.customImageSource = customImageSource; self.broadcastSession = broadcastSession; 動画キャプチャーのセットアップ デモンストレーション目的では、BytePlus Effect SDKのAPI BEVideoCapture を使って、動画キャプチャーをセットアップします。 BytePlus Effect SDK の初期化 self.imageUtils = [[BEImageUtils alloc] init]; self.manager = [[BEEffectManager alloc] initWithResourceProvider:[BEEffectResourceHelper new] licenseProvider:[BELicenseHelper shareInstance]]; // SDK initialization int ret = [self.manager initTask]; デバイスカメラで動画を撮影 BEVideoCapture *capture = [[BEVideoCapture alloc] init]; capture.outputFormat = kCVPixelFormatType_32BGRA; // code that sets up initial configuration for BEVideoCapture removed for brevity [capture startRunning]; BytePlus Effect SDK を使って撮像画像を処理 BEVideoCapture が提供する以下の videoCapture プロキシ方法では、撮影した CMSampleBufferRef をデバイスカメラから転送して処理します。 // BEVideoCapture delegate callback - (void)videoCapture:(id&lt;BEVideoSourceProtocol&gt;)source didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer withRotation:(int)rotation { // code that provides GLContext check removed for brevity CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer); CMTime sampleTime = CMSampleBufferGetPresentationTimeStamp(sampleBuffer); double timeStamp = (double)sampleTime.value/sampleTime.timescale; // code that provides lock on BytePlus Effect SDK for thread safety removed for brevity e.g. NSRecursiveLock [self processWithCVPixelBuffer:pixelBuffer rotation:rotation timeStamp:timeStamp]; } BytePlus Effect SDK を使ってカメラからのバッファを処理 実際の画像処理は、次のprocessWithCVPixelBuffer機能で行われます。 出入力画像バッファのセットアップ - (void)processWithCVPixelBuffer:(CVPixelBufferRef)pixelBuffer rotation:(int)rotation timeStamp:(double)timeStamp { BEPixelBufferInfo *pixelBufferInfo = [self.imageUtils getCVPixelBufferInfo:pixelBuffer]; // The BytePlus Effect SDK requires BGRA format if (pixelBufferInfo.format != BE_BGRA) { pixelBuffer = [self.imageUtils transforCVPixelBufferToCVPixelBuffer:pixelBuffer outputFormat:BE_BGRA]; } if (rotation != 0) { // The texture received by the BytePlus Effect SDK must be positive, so before calling the SDK, you need to rotate it first pixelBuffer = [self.imageUtils rotateCVPixelBuffer:pixelBuffer rotation:rotation]; } // Set up input buffer id&lt;BEGLTexture&gt; texture = [self.imageUtils transforCVPixelBufferToTexture:pixelBuffer]; // Set up output buffer id&lt;BEGLTexture&gt; outTexture = nil; outTexture = [self.imageUtils getOutputPixelBufferGLTextureWithWidth:texture.width height:texture.height format:BE_BGRA]; 画像の処理 BytePlus Effect SDK 初期化で前にセットアップした BEEffectManager オブジェクトである self.manager を使います。 // self.manager is the BEEffectManager during the BytePlus Effect SDK Initialization // For demonstration purposes we will fix the rotation of the image. int ret = [self.manager processTexture:texture.texture outputTexture:outTexture.texture width:texture.width height:texture.height rotate:BEF_AI_CLOCKWISE_ROTATE_0 timeStamp:timeStamp]; if (ret != BEF_RESULT_SUC) { // Log successful image processing } else { // Log unsuccessful image processing } outTexture = texture; 処理した画像バッファを CustomImageSource に送信 処理済み画像バッファが準備出来たら、前のステップでセットアップした配信セッションの CustomImageSource に送信します。 if (self.broadcastSession != nil) { // obtain CVPixelBufferRef CVPixelBufferRef outputPixelBuffer = [(BEPixelBufferGLTexture *)outTexture pixelBuffer]; CMVideoFormatDescriptionRef formatDescription; CMVideoFormatDescriptionCreateForImageBuffer(kCFAllocatorDefault, outputPixelBuffer, &amp;formatDescription); CMSampleTimingInfo timing = { kCMTimeInvalid, kCMTimeInvalid, kCMTimeInvalid }; CMSampleBufferRef sampleBuffer; // Convert to CMSampleBufferRef CMSampleBufferCreateReadyWithImageBuffer(kCFAllocatorDefault, outputPixelBuffer, formatDescription, &amp;timing, &amp;sampleBuffer); // submitted CMSampleBufferRef to customImageSource [self.customImageSource onSampleBuffer:sampleBuffer]; } // code that sets up preview window in the UI removed for brevity } 動画配信を開始 if (self.broadcastSession != nil) { NSURL *myURL = [NSURL URLWithString:@"&lt;INGEST_URL&gt;"]; NSString *myKey = @"&lt;STREAM_KEY&gt;"; [self.broadcastSession startWithURL:myURL streamKey:myKey error:nil]; } インテグレーションの結果 フェイスシェイピングのデモ　左：ソースの iPhone アプリケーション、右： Amazon IVS チャンネルからの HLS 出力 画像フィルタリングのデモ　左：ソースの iPhone アプリケーション、右： Amazon IVS チャンネルからの HLS 出力 このインテグレーションはさらにカスタマイズすることができます。BytePlus Effect SDK は、 BEImageCapture や BELocalVideoCapture などの様々な画像ソースの処理をするために汎用型の インテグレーションオプション を提供しています。 アプリケーションアーキテクチャ Amazon IVS Broadcast SDK と BytePlus Effect SDK の両方を iOS モバイルアプリケーションにインテグレートしました。BytePlus Effect SDK を使って、デバイスカメラからの動画を処理し、IVS Broadcast SDK に送信して、ストリーミングしました。 BytePlus について ByteDance technologyから生まれたBytePlusは、クライアントが様々なインテリジェント技術ソリューションで成長の最大化をお手伝いします。スペシャリストの専門チームがお客様に協力して、より良い製品づくり、より良い体験、そしてビジネスの成長を実現するために、専門家集団がお客さまと手を携えてお手伝いします。 <!-- '"` --> Xiaoyu Chen BytePlus AI ソリューションのディレクター。BytePlus エフェクト、AR、ビデオ エディター、オーディオ、メディア処理サービス、その他の製品ラインを含む AI to B 製品の海外商業化と製品化を担当。彼女は南洋理工大学を卒業し、学士号を取得し、シンガポール国立大学で大学院の学位を取得しました。国内外の AI/ML 製品およびプロジェクトで豊富な経験を持っています。彼女は、東南アジア、日本、韓国、および海外市場において、相互エンターテイメント、文化観光、銀行、保険会社向けの数多くの AI/ML プロジェクトを指揮してきました。 Hao Chen Haoは、Amazon IVS　チームのカスタマーサクセスエンジニアです。AWS　のお客様が　Amazon IVS　を使った革新的なライブストリーミングソリューションの構築をお手伝いします。 Tian Shi Tian Shi　は、AWS　のシニアソリューションアーキテクトです。彼の専門分野はデータ分析、機械学習、サーバーレスです。クラウドにおける信頼性と拡張性の高いソリューションの設計と構築を支援することに情熱を注いでいます。余暇には、水泳や読書を楽しんでいます。

モノのインターネット (IoT) のデバイスは、クラウド上でトレンドの特定や意思決定に利用できるデータを生み出します。 スケーラブルなデータ取り込み機構を設計するのは複雑な作業であり、最初のステップはデバイスの期待動作を把握することです。つまりデバイスが、どうやってデータを送信しているか、どれくらいのデータ量か、データーフローのパターンは何か、その方向はどちらか、何の目的でどういったデータが行き交うのか、を把握します。これらの質問はデータ取り込みプロセスを定義する上で欠かせません。この記事では AWS IoT Core や Amazon Kinesis を使って、大規模にデータを取り込む際の各ユースケースにおけるベストプラクティスを確認していきます。 AWS に IoT データを取り込むために、AWS の 2 大サービスを確認していきます。 AWS IoT はフルマネージドサービスのスイートを提供しており、数 10 億の IoT デバイスとクラウド間の接続や、管理、そしてセキュアな通信を可能にします。また IoT アプリケーションのビルドやデプロイ、スケール化するのに役立つ機能も提供します。AWS IoT Core は数 10 億のデバイスとの接続と、数兆件のメッセージ処理をサポートします。 AWS IoT Core を使う事で、メッセージを AWS エンドポイントや他のデバイスへ安全にルーティングする事ができ、IoT ソリューションの管理と制御のレイヤーを確立する事が出来ます。 Amazon Kinesis はあらゆる規模でストリーミングデータをコスト効率良く処理および分析する事が出来ます。Amazon Kinesis を使う事で、ビデオやオーディオ、アプリケーションログ、ウェブサイトのクリックストリーム、IoT テレメトリデータといったリアルタイムデータを取り込む事が出来ます。 Amazon Kinesis Data Streams はスケーラブルかつコスト効率に優れたストリーミングデータサービスです。様々なデータソースからリアルタイムでデータを取り込み、ダッシュボードや異常検知、ダイナミックプライシングといったアプリケーションの即時分析を可能にします。 IoT デバイスを運用する際には、その環境やアクティビティ、シチュエーションを把握して、最適なデータ取り込みが行えるアーキテクチャを選択する必要があります。この記事では最も最適な取り込み戦略を定義するために、複数の観点とトレードオフを紹介していきます。 どういった環境か？ ここでの環境とは、利用されるデバイスや、デプロイされるソフトウェアスタック、運用目標、そしてデバイスが持つ接続性能を指します。 運用するデバイス数は？デバイスはどこで稼働するのか？どういった機能か？運用におけるデバイス上に必要な機能は？ 最初に考慮すべき要素は、運用するデバイスの数と、その場所と稼働目的です。様々な環境に配置されるデバイスを遠隔で運用するには、デバイスのライフサイクルをビルトインで管理し、現在の状態を可視化する必要があります。フィールドで稼働しリモートかつ制限のあるデバイスを大量に運用管理するには、AWS IoT Core を利用できます。AWS IoT Core は、デバイスとの暗号化された情報交換をサポートし、各種情報の取得や、リモートアクションの実行を可能にします。大量のデータを頻繁に送信するが、一方でデータは受信しない様なデバイスの場合は、Amazon Kinesis を使ってデータを取り込むのが良いでしょう。データ取り込み機能を組み込む場合は Amazon Kinesis Producder Library が利用できます。また Kinesis Agent を使う事でデータの収集と Kinesis Data Streams への送信を行えます。 利用するソフトウェアスタックは何か？ デバイスの選択と開発ツール、プログラミング言語の経験や好みによって、データ取り込みレイヤーを構築するために使用するソフトウェアが決まります。マイクロコントローラー (MCU) のようなリソースが限られたデバイスは、 FreeRTOS のような専用オペレーティングシステムや、データを送信するアプリケーションを構築するために AWS IoT Core でサポートされている MQTT のような軽量メッセージングプロトコルを採用するのが良いでしょう。 データ取り込みクライアントを既存のアプリケーションやエコシステムに統合する際に、汎用プロセッサ (MPU) の様なオペレーティングシステムやツールに幅広い選択肢がある場合は、Amazon Kinesis Producer Library と Kinesis Client Library を使用して、データプロデューサーとデータコンシューマーを構築できます。 何を目的としているのか？ データソース、ボリューム、フローを理解することで、最適なデータ取り込みアプローチが決まります。 取り込まれるデータ量とその頻度は？データフローのパターンは何か？ 高スループット (512KB/s 以上) でデータを生成するデバイスの場合、接続毎のスループットを意識する必要があります。Kinesis Data Streams は一方向データをリアルタイムに収集・処理するのに役立ち、サーバーレスとして提供されるためスケールも可能です。 メッセージングのペイロードサイズが 128KB まで場合、AWS IoT Core がサポートする軽量メッセージングプロトコル の MQTT を使ってデータを送受信できます。一方向通信から、デバイスをリモート管理するための双方向 / コマンド・アンド・コントロール・アプローチまで、幅広い通信アプローチをサポートしています。1MB までのペイロードサイズであれば、Kinesis Data Streams を使用して AWS にデータを取り込むことができ、シャードを必要に応じて追加削除することで、読み取りと書き込みのスループットをスケーリングできます。シャードとは、ストリーム内で一意に識別されるデータレコードのシーケンスであり、ストリームは 1 つ以上のシャードで構成されます。 取り込みプロトコルは何か？ 通信プロトコルの選択はデータフローやデータの性質に影響されます。双方向通信、特に断続的なデータ接続やオフラインモードをサポートする場合、AWS IoT Core が サポートする MQTT であれば HTTPS と比較してオーバヘッドが低いので要件を満たせます。データ集約型の IoT アプリケーションでは、AWS IoT Core の MQTT over WebSocket を検討できます。これはデータ送受信に TCP セッションを再利用する事でオーバーヘッドをさらに削減します。一方向通信の場合は、AWS IoT Core と Kinesis Data Streams は HTTPS をサポートしており、こちらもアプリケーションの目的に応じて選択します。 取り込むデータの用途は？ IoT デバイスによって生成されたデータは主に二つの用途、すなわちメトリクスと処理に使われます。メトリクスとは、デバイスまたはその動作を分析するコンポーネントによって生成される統計データのことです。処理とは、デバイスまたは連携するアプリケーションからのデータを取り込み、変換、クラウドに展開することです。デバイスフリートがアクションを実行するために、デバイス間でメトリクスを交換する必要があるかもしれません。このような場合、AWS IoT Core の MQTT を使用して通信チャネルを確立することが出来ます。デバイスの動作を分析し洞察を得るためのデータは、AWS IoT Core と AWS IoT Analytics を利用して、時間ベースのデータを変換、集計、照会する事ができます。データウェアハウスやデータレイクのような、データプロデューサー側から分離されて、他のデータソリューションに接続して処理されるデータは、永続化とデータ連携のために Kinesis Data Streams を使用する事が出来ます。 あなたのケースは？ 大量のデバイスを管理するには、リソースとデータへのアクセスを制御するセキュリティ定義が必要です。 アクセスや可視化のレベルをデバイス上で強制させることも出来ますが、まずはデプロイや運用の観点で定義すべきです。 必要なセキュリティは何か？デバイスはどのように AWS と通信する必要があるか？ デバイスが物理的正しく扱われる事が期待できない様な環境では、固有のデバイス証明書とロールに基づいて認証・認可を定義することができます。AWS IoT Core は各デバイスを一意に認証・認可するために、X.509 証明書をサポートしています。AWS IoT Core にはマネージドな認証局 (CA) があり、独自の CA をインポートする事も出来ます。 すべてのデバイスが正しく扱われ、ベースとなるプラットフォームに直接アクセスできる様な管理された環境では、AWS 認証情報に基づいて認証・認可を実装できます。Kinesis Data Streams は AWS 認証情報でアクセス出来るので、短時間の一時認証情報を使用する事で、セキュリティ制御を強化できます。 デバイスが必要とするアクセスレベルは？ デバイスは、クラウドまたは他のデバイスによって生成された、データの一部と連携する必要があるかもしれません。AWS IoT Core は、デバイスを識別し、特定の MQTT トピックへのアクセス制御を細かく設定が出来ます。単独でデータを生成して、大量にデータを送信する一方向通信の場合、Amazon Kinesis は複数のデータプロデューサーから書き込める単一のストリームを提供します。 この場合、どのデータプロデューサーも同じストリームにデータを書き込むことができ、どのデータコンシューマーもそのデータを読むことが出来ます。 一緒に確認してみましょう ここでは高頻度にデータを取り込みつつ可視化を行う、二つのアプローチが必要なユースケースを確認していきます。 ユースケース 1: 複数デバイスで生成されるデータの処理と可視化 何千台ものデバイスがフィールドに散らばっているとしましょう。各デバイスは少量の運用メトリクスを生成します。全体の稼働状況の把握、異常検知、予知保全、過去データの分析、これらを行うには全てのデバイスを制御し、データを集約してリアルタイムまたはバッチで洞察を得る必要があります。AWS IoT Core はデバイスの通信、管理、認可・認証を提供し、Kinesis Data Streams は高頻度データの取り込み機能を提供します。 Amazon Kinesis と連携した AWS IoT Core にデータをパブリッシュする事で、データ収集、データ処理、データ分析を広帯域でリアルタイムに行う事が出来ます。 Amazon Kinesis Data Analytics for Apache Flink を使用すると、Java、Scala、または SQL を使用してストリーミングデータを処理および分析できます。このサービスは、IoT データに対してコード実行、時系列分析、リアルタイムダッシュボードへのデータ連携や、リアルタイムメトリクスの作成を行うことができます。 レポート作成には、 Amazon QuickSight をバッチダッシュボードやスケジュールダッシュボードに使用できます。よりリアルタイムなダッシュボード機能が必要な場合は、 Amazon OpenSearch と OpenSearch Dashboards を使用できます。 ユースケース 2: IoT デバイスからの高スループットデータの制御とストリーミング AWS IoT と Amazon Kinesis の両サービスを組み合わせるもう一つのユースケースは、細かいデバイス制御が必要な高スループット要件です。 タービンや LiDAR データの様に、クラウドで処理するデータを大量に生成するデバイスを制御するために、デバイスとの通信と管理、認証・認可を提供する AWS IoT Core と、高スループットでデータを取り込める Amazon Kinesis Video Streams を利用できます。 上記の図では、ハードコードされた AWS アクセスキーペアを使う代わりに AWS IoT Core を利用する事で、X.509 証明書によってセキュアにデバイスをプロビジョニングし、 Amazon Kinesis Video Streams を利用する事で、ビデオデータをクラウドに送信しています。 まとめ IoT デバイスから大規模にデータを取り込むには、ユースケースやペイロードサイズ、目的、デバイスの制約に基づいて、使用するテクノロジーを選択する必要があります。以下のデシジョンマトリックスは、大規模にデータを取り込む際に適した、AWS サービスを選択するガイダンスを提供しています。特定のユースケースによっては、複数のサービスを組み合わせることもできます。 最適 AWS IoT Amazon Kinesis デバイスへのコマンドと制御 最適 &nbsp; リソースが限られたデバイス 最適 &nbsp; 高スループットデータ &nbsp; 最適 双方向通信 最適 &nbsp; 細かいアクセス制御 最適 &nbsp; IoT デバイスにおけるデプロイの一般的な観点を確認し、各々のケースに応じた質問とベストプラクティスを紹介しました。詳細については、 Amazon Kinesis Data Streams と Amazon IoT Core のドキュメントをご確認下さい。 Andreas Calvo Gómez AWS シニアソリューションアーキテクト。デジタル・ネイティブ・ビジネスに携わり、お客様が AWS 上でのソリューション構築を支援しています。クラウド技術と IoT に情熱を注いでいます。 この記事は Andreas Calvo Gómez によって書かれた “Best practices for ingesting data from devices using AWS IoT Core and/or Amazon Kinesis” の日本語訳です。この記事は ソリューションアーキテクトの山岡 卓紀夫が翻訳しました。

こんにちは。カスタマーソリューションマネージャー (CSM) の仁科です。昨今、クラウドがビジネスにもたらす経済的価値を追求し、会社や組織全体としてこれを享受するための施策を立案／推進するチームを立ち上げるお客さまが珍しいものではなくなりました。このチームは 「クラウド活用推進組織」 や 「クラウド CoE (Centre of Excellence)」、もしくは省略して 「CCoE」 と呼ばれています。 以前のブログ では、CCoE の活動に関して AWS Summit Online 2022 の事例を交えながら、CCoE の活動内容を検討する際の考え方についてご紹介しました。今回は AWS Summit Tokyo 2023 の CCoE に関する事例や関連の事例から、CCoE を取り巻く状況をご紹介したいと思います。前編では CCoE の活動事例や共通点をご紹介し、後編では少し視点を変えて、2023 年の事例から見えてくる CCoE の在り方を考察します。 この記事は、次のような方を読者として想定しています。 まだ CCoE を組成していないお客さまで、CCoE について知りたい、もしくは、CCoE を組成しようと考えている方 CCoE を組成しているお客さまで、業務の質を良くしたい もしくは 業務の幅を広げたいと考えている方 2023 年の CCoE に関する事例を知りたい方 クラウド活用推進に必要な観点 以前のブログ でもご紹介しましたが、重要な観点ですので改めて簡単にご説明します。クラウドを活用しビジネス成果を加速させるための活動を検討する際に観点として利用できるのが、 AWS クラウド導入フレームワーク (AWS CAF) というフレームワークです。AWS CAF では、クラウド活用推進のために必要な活動を 6 つの観点 (下記の図の左側に記載している非技術的な観点のビジネス、ピープル、ガバナンス、右側に記載している技術的な観点のプラットフォーム、セキュリティ、オペレーション) にグループ化しています。これら 6 つの観点すべてが CCoE の活動スコープと言えますが、すべてを CCoE 単独で実施する必要はありません。各企業の事業環境や事業戦略上の優先順位を踏まえ、CCoE がどの領域にどの程度入っていくのかを検討し、関係部署と役割を調整しながら、それぞれの企業にあった CCoE としての活動を決めて、実施していくことが重要です。 2023 年の CCoE の活動事例と共通点 AWS Summit Tokyo 2023 でも以下のセッションで CCoE の活動に関して触れられています。詳細に関しては、ぜひ動画や資料をご確認ください。 トヨタ CCoE が進める Developer eXperience のカイゼン(CUS-10) [ 動画 、 資料 ] 国でもできたスマートなクラウド利用 ～高速試行錯誤しながら進歩を続けるクラウド CoE～(CUS-16) [ 動画 、 資料 ] 2023 年の事例としては「カイゼン、改善」というキーワードが見られました。トヨタ自動車の事例では「開発者の仕事を楽にすること」を「DevEx (Developer eXperience) カイゼン」として取り組まれていました。デジタル庁／農林水産省の事例では「統制を改善し続けるプロセス」を高速回転させ、改善に継続的に取り組まれていました。 こちらの記事 でも記載している通り、「クラウドを使って、会社、組織をもっと良くしたい」という心構えが表れていることが分かります。クラウド自体が日々進化していることから、一度何かを実施して終わり、ではなく、CCoE として継続して改善を続けていくことでクラウド活用を推進していくことが重要です。 また、CCoE がクラウド利用のブロッカーにならないように、現場のために動く、現場の効率化を図るために活動しているという内容も見られました。トヨタ自動車では、ガードレール型セキュリティや最低限開発に必要な Git や CI/CD などを開発者に提供することで、開発開始までのリードタイムを約 96％ 削減したという事例をご紹介いただいています。CCoE の活動によって、開発者がより開発をしやすくなる環境を整えているという良い事例です。デジタル庁／農林水産省では、クラウド利用ガイドラインにおいて、「標準化・共有化・シンプル化によりムリ・ムダ・ムラを無くす」をコンセプトに、クラウド利用者が必要なルールをわかりやすくシンプルに記載し、持続的に更新いただいています。ガイドラインやルールを決めても、内容が複雑だったり、チェックする項目が多いと形骸化しがちです。ガイドラインを作るにあたって、利用者目線で本当に必要な内容は何かを検討して決定していくことが重要です。2 つの事例から、 こちらの記事 で記載している「利他的であること」という心構えも変わらず見られることが分かります。 2023 年は上記の事例のほかに、CCoE という単語は明確にはないものの、クラウドの人材育成や組織横断的なクラウド利用改善の取り組み、必要に応じて AWS パートナーを活用する事例も見られました。以下にその一部を抜粋します。 ベイシアが目指す「クラウド化」周回遅れからデジタル先進企業への挑戦(AP-16) [ 資料 ] クルマのサブスク「KINTO」のアジリティとガバナンスを両立する DBRE の取り組み(CUS-11) [ 動画 、 資料 ] 情シスの情シスによる情シスのための人材育成-リスキリングとそれに反する教育後回しジレンマ克服の具体策-(CUS-01) [ 動画 、 資料 ] 国の DX を支えるデジタル人材の育成(AWS-53) [ 動画 、 資料 ] 前述した通り、CCoE がクラウドに関するあらゆる改善、活動をすべて実施すべき、というわけではなく、あくまで CCoE も含めたいずれかの部署や横断型組織などでクラウド利用に関しての課題全体に取り組んでいくことが重要であると言えます。ぜひ、 AWS Summit Tokyo 2023 のその他の事例についても参照してみていただければと思います。 まとめ 前編では、 AWS Summit Tokyo 2023 から見る、2023 年の CCoE の活動事例や共通点をご紹介しました。 CCoE として必要な心構えである 「クラウドを使って、会社、組織をもっと良くしたい」 「利他的であること」 は引き続き重要であり、各会社、組織で取り組まれている 必ずしも CCoE 単独でクラウド推進におけるすべての課題解決を行う必要はなく、いずれかの部署や横断型組織も含めてクラウド推進における課題に取り組んでいくことが重要 後編では、2023 年の事例から見えてくる CCoE の在り方を考察します。 参考情報 CCoE 活動検討のはじめの一歩 今から始める CCoE、3 つの環境条件と 3 つの心構えとは クラウドマイグレーションの意外なつまづきポイントを解説！AWS移行セミナー～組織や人材、ガバナンスなど非技術的な領域の課題と対策～ AWSクラウド導入フレームワーク (AWS CAF) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (前編) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (後編) 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 仁科 みなみ

IBM MQは、世界の銀行、航空会社、医療機関、保険会社など、多くの企業組織で使用されているメッセージ指向ミドルウェア (MOM) 製品です。 AWS では、既存のオンプレミスにある MOM システムをクラウドで実行されている新しいアプリケーションと統合できる方法についてお客様からよくお問い合わせいただきます。お客様は、クラウドアプリケーションからこれらのメッセージングシステムにメッセージを送受信できる、費用対効果が高く、スケーラブルで手間のかからないソリューションを探しています。 このブログ記事では、オンプレミスの IBM MQ から Amazon MQ 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Notification Service (Amazon SNS) への双方向ブリッジをセットアップする方法を示しています。 これにより、フルマネージド型の AWS メッセージングサービスと Apache Camel を使用してプロデューサーアプリケーションとコンシューマーアプリケーションを統合できます。このブログでは前述のソリューションをデプロイする方法と、SNS、SQS、およびデモ用の IBM MQ クラスター環境（ AWS Fargate 上の Amazon Elastic Container Service (ECS) で実行）を使用して、実行中の統合をテストする方法を学びます。 このソリューションは、ブログ記事「 Migrating from IBM MQ to Amazon MQ using a phased approach 」で説明されているアプローチを使用して、段階的な移行の一部として使用することもできます。 ソリューション概要 Apache Camel ブローカークラスターを使用して、IBM MQ システムと、ターゲットシステム（ActiveMQ エンジンの Amazon MQ、SNS トピック、 SQS キューなど）を双方向に統合します。 次の例では、AWS サービス (この場合は AWS Lambda と SQS) が SNS トピック経由で IBM MQ に公開されたメッセージを受信します: クラウドメッセージコンシューマー (Lambda と SQS) は、ソリューション内のターゲット SNS トピックにサブスクライブします。 Apache Camel ブローカーは、 AWS Secrets Manager に保存されている認証情報で IBM MQ に接続し、IBM MQ’s Java Library を使用してキューから新しいメッセージを読み取ります。 IBM MQ’s Java Library を利用する場合、IBM MQ メッセージのみがソースとしてサポートされています。 Apache Camel ブローカーは、これらの新しいメッセージをターゲット SNS トピックに公開します。 Amazon SNS Extended Client Library for Java を使用して、256 KB を超えるメッセージを Amazon Simple Storage Service (Amazon S3) バケットに保存します。 Apache Camel は、2 回再試行しても SNS に配信できないメッセージを S3 のデッドレターキューバケットに保存します。 次の図は、ソリューション内で SQS キューから IBM MQ にメッセージを送り返す方法を示しています: Lambda を使ったサンプルメッセージプロデューサーは、SQS キューにメッセージを送信します。 Amazon SQS Extended Client Library for Java を使用して 256 KB を超えるメッセージを送信します。 Apache Camel ブローカーは、必要に応じて SQS Extended Client Libraryを使用して SQS に公開されたメッセージを受信します。 Apache Camel ブローカーは、メッセージを IBM MQ ターゲットキューに送信します。 同様に、ブローカーは IBM MQ に配信できないメッセージを S3 デッドレターキューバケットに保存します。 段階的なライブマイグレーションは、次の 2 つのステップで構成されます: ブローカーサービスをデプロイして、既存の IBM MQ キューへのメッセージの読み取りと書き込みを可能にします。 コンシューマーまたはプロデューサーが移行されたら、対応するサービスを新しく選択したサービス (SNS または SQS) に移行します。 次に、 AWS Cloud Development Kit (AWS CDK) を使用してソリューションをセットアップする方法を学習します。 ソリューションのデプロイ 必要条件 AWS CDK TypeScript Java Docker Git Yarn Step 1: リポジトリをクローンする git を使用してリポジトリをクローンします: git clone https://github.com/aws-samples/aws-ibm-mq-adapter Step 2: テスト用 IBM MQ 認証情報のセットアップ このデモでは、IBM MQ の相互 TLS 認証を使用します。そのためには、 app フォルダで以下のコマンドを実行して X.509 証明書を生成し、AWS Secrets Manager に保存する必要があります: X.509 証明書を生成します。 ./deploy.sh generate_secrets Apache Camel ブローカーに必要なシークレットを設定します ( &lt;integration-name &gt; は、たとえば dev と置き換えてみてください) : ./deploy.sh create_secrets broker &lt;integration-name &gt; 模擬用の IBM MQ システムのシークレットを設定します: ./deploy.sh create_secrets mock cdk.json ファイルを、ここまでのコマンドで出力されたシークレット ARN で更新します。（訳註：IBMMQ_TRUSTSTORE_… と IBMMQ_KEYSTORE_… はサンプルコード中の複数箇所で定義されていますが、全て更新が必要です）: IBM_MOCK_PUBLIC_CERT_ARN IBM_MOCK_PRIVATE_CERT_ARN IBM_MOCK_CLIENT_PUBLIC_CERT_ARN IBMMQ_TRUSTSTORE_ARN IBMMQ_TRUSTSTORE_PASSWORD_ARN IBMMQ_KEYSTORE_ARN IBMMQ_KEYSTORE_PASSWORD_ARN 独自の IBM MQ システムを使用していて、すでに X.509 証明書が利用可能になっている場合は、スクリプトを実行した後にスクリプトを使用してそれらの証明書を AWS Secrets Manager にアップロードできます。 Step 3: ブローカーの設定 このソリューションでは 2 つの Apache Camel ブローカーがデプロイされます。1 つはテスト用 IBM MQ システムからのメッセージを読み取るため、もう 1 つはメッセージを送り返すためのものです。送信用、受信用で異なるApache Camel ブローカーの使用は２つの目的があります。１つ目は、Auto Scaling 機能をより有効活用するためです。２つ目は、送信と受信のどちらかに問題発生しても、もう片方に影響を与えないためです。 cdk.json ファイルを次の値で更新します。: accountId : ソリューションをデプロイする AWS アカウント ID。 region : ソリューションをデプロイする AWS リージョンの名前。 defaultVPCId : ブローカーとモックがデプロイされている AWS アカウント内の既存の VPC ID を指定します。 allowedPrincipals : アカウント ARN (例： arn:aws:iam::123456789012:root を追加して、この AWS アカウントがブローカーとの間でメッセージを送受信できるようにします。このパラメーターを使用して、SQS と SNS の両方の統合にクロスアカウント関係を設定し、複数のコンシューマーとプロデューサーをサポートできます。（訳註：サンプルコード中の複数箇所で定義されていますが、全て更新が必要です。） Step 4: ソリューションのブートストラップとデプロイ 開発アカウントに正しい AWS_PROFILE と&nbsp; AWS_REGION 環境変数が設定されていることを確認してください。 yarn install を実行して CDK の依存関係をインストールします。 CDK をブートストラップする ために yarn cdk bootstrap –-qualifier mq &lt;aws://&lt;account-id &gt;/&lt;region &gt; コマンドを実行します。 最後に、 yarn cdk deploy '*-dev' –-qualifier mq --require-approval never を実行して、ソリューションを dev 環境にデプロイします。 Step 5: 統合のテスト AWS System Manager Session Manager とポートフォワーディングを利用してテスト用 IBM MQ インスタンスへのトンネルを確立し、ウェブコンソールにアクセスして手動でメッセージを送信します。ポートフォワーディングの詳細については、ブログ「 Amazon EC2 instance port forwarding with AWS Systems Manager 」を参照してください。（訳註：サンプルコードの README の「 How to test locally 」の項目も適宜ご参照ください） コマンドラインターミナルで、開発アカウントに正しい AWS_PROFILE と AWS_REGION 環境変数が設定されていることを確認します。 さらに、次の環境変数を設定します: IBM_ENDPOINT : IBM MQ のエンドポイント。例: IBM モック用のネットワークロードバランサー mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com （訳註：マネジメントコンソールでデプロイされたロードバランサーのDNS名をコピーすることで取得可能です） BASTION_ID : 踏み台ホストのインスタンス ID。この出力は、「ステップ 4: ソリューションをブートストラップとデプロイ」において、 mqBastionStack のデプロイ後のリストから取得できます。 以下のコマンドを使用して環境変数を設定します: export IBM_ENDPOINT=mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com export BASTION_ID=i-0a1b2c3d4e5f67890 スクリプト test/connect.sh を実行します デフォルトの IBM ユーザー ( admin ) と AWS Secrets Manager に mqAdapterIBMockAdminPassword として保存されているパスワードを使用して、 https://127.0.0.1:9443/admin から IBM ウェブコンソールにログインします。 IBM MQ からのデータの送信と SNS での受信: IBM MQ コンソールで、ローカルキューマネージャー QM1 → DEV.QUEUE.1 にアクセスします Hello AWS という内容のメッセージを送信してください。このメッセージは AWS Fargate によって処理され、SNS に公開されます。 SQS コンソールにアクセスし、 snsIntegrationStack-dev-2 プレフィックスキューを選択します。これは SNS トピックにサブスクライブされたテスト用の SQS キューです。 [メッセージの送受信] を選択します。 [メッセージをポーリング] を選択すると、前に IBM MQ に送信された Hello AWS メッセージが表示されます。 Amazon SQS から IBM MQ へのデータの返送: SQS コンソールにアクセスし、 sqsPublishIntegrationStack-dev-3-dev というプレフィックスの付いたキューを選択します。 [メッセージの送受信] を選択します。 [メッセージ本文] には、 Hello from AWS を追加してください。 [メッセージを送信] を選択します。 IBM MQ コンソールで、ローカルキューマネージャー QM1 → DEV.QUEUE.2 にアクセスして、このキューの下にリストされているメッセージを探します。 Step 6: クリーンアップ cdk destroy '*-dev' を実行して、このウォークスルーの一部としてデプロイされたリソースを削除します。 まとめ このブログでは、Amazon SQS と Amazon SNS を使用して IBM MQ とクラウドアプリケーション間でメッセージを交換する方法を学びました。 独自の統合を始めることに興味がある場合は、GitHub リポジトリの README ファイルを参照してください。JMS、NMS、AMQP 1.0 などの業界標準の API とプロトコルを使用して既存のアプリケーションを移行する場合は、リポジトリに用意されている手順を使用して Amazon MQ と統合することを検討してください。 Kubernetes で Apache Camel を実行することに興味がある場合は、代わりに Apache Camel K を使用するようにアーキテクチャを変更することもできます。 その他のサーバーレス学習リソースについては、 Serverless Land をご覧ください。 この記事は、Principal Security Consultant の Joaquin Rinaudo と DevOps Consultantのゲジム・ムスリアンが執筆したものを Solutions Architect の三厨が翻訳しました。原文は こちら （記事公開日：2023 年 8 月 15 日）。 <!-- '"` -->

あと数日したら飛行機で南に向かいます。ラテンアメリカツアーの始まりです。独りではありません。 Jeff や Seb といったニュースブログの執筆者たちも AWS Community Day、そして ペルー 、 アルゼンチン 、 チリ 、 ウルグアイ のイベントで講演します。私たちを見かけたら声をかけてください。皆さんにお会いできるのを心待ちにしています。 8月14日週のリリース 8月14日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS AppSync が GraphQL API のすべてのリゾルバーの JavaScript をサポート – 2022年 、AppSync が JavaScript パイプラインリゾルバーをサポートするようになったことが発表されました。そして、 先週 から、JavaScript を使用してユニットリゾルバー、パイプラインリゾルバー、および AppSync Javascript ランタイム上で実行する AppSync 関数を記述できるようになりました。 AWS CodePipeline が GitLab をサポート – AWS CodeCommit、Bitbucket、GitHub.com、GitHub Enterprise Server などのプロバイダーに加えて、 GitLab.com リソースリポジトリ で、AWS CodePipeline を使用してコード変更をビルド、テスト、デプロイできるようになりました。 Amazon CloudWatch Agent が OpenTelemetry トレースと AWS X-Ray のサポートを追加 – 新しいバージョンのエージェントでは、単一のエージェントで CloudWatch だけでなく OpenTelemetry と AWS X-Ray の メトリクス、ログ、トレースを収集 できるようになりました。テレメトリ収集のインストール、設定、管理が簡素化されます。 新しいインスタンスタイプ: Amazon EC2 M7a と Amazon EC2 Hpc7a – 新しい Amazon EC2 M7a は、第 4 世代 AMD EPYC プロセッサを搭載した汎用インスタンスです。このインスタンスタイプの詳細な仕様については、一般提供の発表に関する ブログ記事 を参照してください。新しい Amazon EC2 Hpc7a インスタンスには、第 4 世代 AMD EPYC プロセッサも搭載されています。これらのインスタンスタイプは、ハイパフォーマンスコンピューティング向けに最適化されています。各 Amazon EC2 Hpc7a インスタンスタイプの特性については、 Channy Yun のブログ記事 を参照してください。 AWS DeepRacer 教育者プレイブック – 先週、AWS DeepRacer 教育者プレイブックが発表 されました。このプレイブックは、基盤となる機械学習 (ML) カリキュラムとラボをクラスに統合することを目的とした教育者向けのツールです。教育者は、これらのプレイブックで自動運転車のシミュレーションを使って機械学習の基礎に関する学生のスキルを向上させることができます。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AWS Lambda を使用した Apache Kafka ストリーム処理のガイド – Julian Wood が Lambda と Apache Kafka を使用する方法に関する包括的なガイドを公開しました。Amazon Kinesis ユーザーでも問題ありません。類似のトピックを紹介しているこの ビデオシリーズ を活用してください。 AWS の公式ポッドキャスト &nbsp;– 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報 &nbsp;– 私の同僚である Ricardo &nbsp;が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Hybrid Cloud &amp; Edge Day (8 月 30 日) – 無料で参加できる 1 日のバーチャルイベントに参加して、ハイブリッドクラウドとエッジコンピューティングの最新のトレンドと新しいテクノロジーに関する講演を聴き、AWS リーダー、お客様、業界アナリストが紹介するベストプラクティスを学習してくだだい。詳細については、 詳細なアジェンダを参照して、今すぐ登録 してください。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ &nbsp;(8 月 30 日) と ヨハネスブルグ &nbsp;(9 月 26 日) の 2 回の対面イベントです。 AWS re:Invent &nbsp; (11 月 27 日～12 月 1 日) – re:Invent シーズンが間もなく始まります。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。&nbsp; 登録が開始されました 。 AWS Community Day &nbsp; – AWS ユーザーグループリーダーが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください 台湾 &nbsp;(8 月 26 日)、 ニュージーランド &nbsp;(9 月 6 日)、 レバノン &nbsp;(9 月 9 日)、 ミュンヘン &nbsp;(9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。すべての AWS Community Day のスケジュールについては、 こちら を参照してください。 CDK Day (9 月 29 日) – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントです (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 8月21日週はここまでです。8月28日週に再びアクセスして、新たな Week in Review をぜひお読みください! この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! –&nbsp; Marcia 原文は こちら です。

このブログは 2023 年 7 月 6 日に Gena Gizzi、Jake Wolf、Noor Fairoza、Chris Blackwell によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS 上での Unreal Engine 開発の民主化：エンドユーザコンピューティング（EUC）サービスと高性能な GPU ベースの EC2 インスタンスを用いて はじめに ゲーム業界は日々進化しており、中でもユーザ生成コンテンツ（user-generated content、略して UGC）が変革の先駆けとなっています。プレイヤーは自己表現や報酬（マネタリーリワードとソーシャルリワード）を得るためかつてないほど多くの UGC を作り出しています[1]。しかしゲーム開発とコンテンツ作りは複雑で困難です。学生から専門家まであらゆる人が参画できるようにするため、ゲーム業界では開発を民主化するツールを用意する必要があります。そしてそこから次のような新しい課題が生まれます。どうすればゲーム開発のハードルを下げながらもプレイヤーのクリエイティビティを担保できるでしょうか？どのようにして学習コストを下げ、ハードウェアの制約を取り払い、ゲーム開発のコストを下げることができるでしょうか？ これらの課題に対しゲーム業界では多くの新しい試みがなされました。中でも特筆すべきのは Epic Games と Unreal Engine （UE）です。Unreal Engine はフォトリアルなビジュアルと没入的体験を作り出す世界で最も高度な 3D 制作ツールです。UE が脚光を浴びたのはまずゲーム業界でのことでしたが、今では放送、アニメーション制作、シミュレーションなどの業界でも人気なツールとなっています。Epic Games のフォートナイトも Unreal Engine を利用しています。フォートナイトはプレイヤーに UGC やクリエイティブな体験を提供し、今や1つのソーシャルエクスペリエンスとなってきています。 Epic Games は GDC 2023 で Unreal Editor for Fortnite （UEFN）を発表しました。UEFN はゲームや体験を設計、開発し、フォートナイトに直接公開できる新しい PC アプリケーションです。これによりゲーム開発の学習コストが下がり、プレイヤーは今まで以上に簡単に Unreal Engine の機能を使って UGC の創作ができるようになりました。 一方ハードウェアやコスト面での課題はまだ残っています。ゲーム開発ツールを利用するには往々にして高価な GPU 付きハードウェアが必要です。これらのハードウェアは高価なだけでなく入手に時間がかかり、手軽にスケールアップ/スケールダウンもできません。例としては こちら の Unreal Engine 5 の推奨ハードウェア要件をご覧ください。従業員に最新のハードウェアを購入する予算のない小規模なゲームスタジオや、最新のゲーミング PC とハイエンドな GPU が手に入らないプレイヤーにとって、このようなハードウェア要件は制約になる可能性があります。そこでクラウドが助けになります。クラウド上で UE や UEFN を使う主なメリットはスケーラビリティと柔軟性の向上とコスト削減です。ゲーム開発者やクリエイターは高価な初期費用を心配することなくクラウド上で強力なハードウェアが備わったインスタンスを起動させたり、必要に応じスケールアップ/スケールダウンさせることができます。クラウドを使えば小規模なスタジオでも大きいスタジオと肩を並べることができるようになり、個人開発者もより手軽にコンテンツ制作を始められます。 AWS 上でクラウドベースのゲーム開発をする方法は多くあり、選定の際にはいくつか考慮すべき要素があります。例えば開発者の人数、予算、ユーザペルソナ、所在地、レイテンシ、プレゼンテーション層の要件、カスタマイズ性、セキュリティ要件や特定のユースケースなどが考えられます。Amazon AppStream 2.0、Amazon WorkSpaces、Amazon EC2 は主な選択肢です。本ブログではこれらの選択肢について取り上げ、ご利用のツールにかかわらず（UE、UEFN、またはその他の GPU 要件のあるゲーム開発ツール）、ユースケースに最適なクラウドベースのゲーム開発サービス選定をお手伝いします。 Amazon AppStream 2.0 Amazon AppStream 2.0 はクラウドベースのゲーム開発の選択肢の1つです。AppStream 2.0 はクラウド上でデスクトップライクなアプリケーションストリーミング体験を提供します。ゲーム開発チームはデバイスや場所の制限なしにグラフィック集約型や高性能アプリケーションを利用することができ、時間とコストを節約できます。特に高性能なコンピューティングリソースやグラフィックリソースが必要だが、高価なハードウェアを購入したくないゲーム開発者や 3D モデリングアーティストにとって Amazon AppStream 2.0 は有力な選択肢になるでしょう。そのほか学生や請負業者など特定のアプリケーションを一定期間内だけ利用したいユースケースにおいても AppStream 2.0 は良い選択肢の1つになります。 AppStream 2.0 が良い選択肢だと思いましたらまずはこちらの 入門ガイド または無料 オンラインコース を確認してみましょう。ゲーム開発で利用する場合「 Graphics design streaming instances for image builders 」と「 Graphics design streaming instances for fleets 」の サービスクォータ の上限緩和申請も必要になります。高性能な 4xlarge から始めることを推奨していますが、ユースケースに合ったインスタンスサイズを利用することが大切です。テストやモニタリングを通して適切なインスタンスサイズを見つけましょう。また、AWS 完全初心者の方は AppStream のプロビジョンニングを開始する前に AWS の基礎知識 を学ぶことをおすすめします。 AppStream 2.0 をご利用する上で注意していただきたいのは、AppStream 2.0 のローカルストレージは非永続なため、ユーザはセッションごとにデータを外部の永続化ストレージ（外部の永続化ストレージのオプションは こちら をご参照ください）に保存しないとデータを失うリスクがあるところです。また AppStream と WorkSpaces はどちらもレイトレーシングと Lumen/Nanite をまだサポートしていません。これらのサポートが必要な場合、本ブログで取り上げた選択肢の中で最もカスタマイズ性の高い EC2 の方がユースケースに合う可能性があります。EC2 についてはブログの後半からご確認ください。またブログの最後に AppStream 2.0、WorkSpaces と EC2 の機能比較一覧表もありますので、選定の際ぜひご参照ください。 Amazon WorkSpaces Amazon WorkSpaces はクラウドベースのゲーム開発のもう1つの選択肢です。仮想デスクトップにフルアクセスしたいグラフィックデベロッパーにとって WorkSpaces はいい選択肢になります。WorkSpaces はあらゆるロケーションからクライアント（Windows、MacOS、Linux、その他モバイルデバイスやタブレットなどに対応。詳細は こちら ）を通してアクセスできる仮想デスクトップを提供します。WorkSpaces は必要なツールや開発環境をインストールするようにカスタマイズできるため、特定のソフトウェアや IDE またはツールが必要な開発者にとって役立ちます。WorkSpaces にはデフォルトで永続ストレージが付属されています。また AlwaysOn と AutoStop といった実行モードがあり使っていない時のコスト削減につながります。このように開発者は慣れ親しんできた専用 VDI と似た感覚で WorkSpaces を利用できます。また WorkSpaces は追加の永続ストレージも利用でき、 追加料金なしで WorkDocs のストレージを 50GB 利用 できます。 Amazon WorkSpaces が良い選択肢だと思いましたら、こちらの 入門ガイド を確認して初めての WorkSpace を起動してみましょう。グラフィックスアプリケーションをご利用したい場合、インスタンスタイプは必ず Graphics.g4dn か GraphicsPro.g4dn のどちらかを選ぶようにしましょう。これらのインスタンスタイプは多精度 Turing Tensor Cores および RT Cores を備えた NVIDIA T4 Tensor Core GPU、AWS カスタム第2世代 Intel® Xeon ®スケーラブル （Cascade Lake）プロセッサ、およびローカルデータの高速アクセスが必要なアプリケーションに最適なローカル NVMe ストレージが付属しています。 WorkSpaces は AppStream と同様に AWS リージョンごとのグラフィックスインスタンスの種類とターゲット数の 上限緩和申請 が必要になります。Graphics と GraphicsPro インスタンスは vCPU の数、RAM と NVMe SSD ストレージの容量に違いがありますが GPU スペックは同等です。ご注意いただきたいのは上限緩和申請が通るまで1週間かかることもあるため、利用開始時や大規模なイベントを控えている際は余裕を持って申請するようにしましょう。 より詳しい情報やコストについては Amazon WorkSpaces のウェブサイト をご参照ください。また無料のオンライントレーニングとして WorkSpaces Primer と WorkSpaces Deep Dive も提供しています。WorkSpaces は AWS マネジメントコンソール からご利用いただけます。 Amazon EC2 Amazon EC2 はクラウド上のゲーム開発の選択肢の中で最もカスタマイズ性の高いものです。Amazon EC2 は事実上特殊要件のあるものも含むすべてのワークロードに対応できるセキュアでサイズ変更可能なコンピューティングリソースを提供します。ゲームスタジオは EC2 を使用して独自のクラウドベース仮想ワークステーションソリューションを構築することができます。これはインフラストラクチャをより細かく制御したい大きめの開発チームにとって特に有用です。また Amazon EC2 はゲームのワークロードに使用可能なインスタンスタイプを幅広く提供しています。例えば Amazon EC2 でクラウドベースのゲーム開発をする場合 G5 インスタンス がおすすめです。G5 は高性能な GPU ベースインスタンスでグラフィック集約型のワークロードに最適です。強力な GPU 以外にも EC2 のカスタマイズ性は非常に高く、高性能なネットワーキングとストレージもご利用可能です。これにより EC2 は 3D モデリング、アニメーション、レンダリングといったゲーム開発タスクにとっても理想的なソリューションになります。 Amazon EC2 を利用する場合、マネージドサービスである Amazon AppStream と Amazon WorkSpaces より多くのインフラストラクチャ管理作業が発生します。EC2 インスタンスのプロビジョニングとオーケストレーションを簡略化するために Amazon Machine Images（AMI）、AWS Marketplace、AWS CloudFormation と AWS Control Tower などのツールが存在します。例えば AWS Marketplace から Unreal Engine 5 AMI を起動させればすぐに開発に着手することができます。ただしチームの規模が小さく時間もあまりない場合、Amazon EC2 を使うとインスタンス、プレゼンテーションレイヤー、インフラストラクチャのスケーリング、パッチあてなどの管理作業が発生することを考慮に入れていただきたいです。 クラウドベースのゲーム開発において最大限の制御とカスタマイズ性が必要な場合、Amazon EC2 は最適な選択肢です。 Amazon EC2 の開始方法 を確認し初めてのインスタンスを立ち上げてみましょう。その後こちらの Game Production in the Cloud Pipeline を参照してみると良いかもしれません。こちらのリポジトリには仮想ワークステーションのデプロイとセットアップ手順が含まれています。 機能比較 ご自身のワークロードにとってどの選択肢が最適か決めかねていますか？それとも他に特別な要件があるでしょうか？こちらの詳細機能比較一覧表をぜひご参考にしてください（表の情報は 2023 年 7 月 6 日オリジナルのブログ記事公開時までの情報に基づいています）！ Appstream Workspaces EC2 永続デスクトップ &nbsp; X X 選択式永続性 X &nbsp; &nbsp; GPU インスタンス (G4) X X X GPU インスタンス (G5) &nbsp; &nbsp; X サポートされているリージョン数 15 13 全リージョン対応 ブラウザからのアクセス X X &nbsp; シッククライアントからのアクセス Windows のみ X 任意 タブレット入力サポート X X X – via NICE DCV ゲーミングコントローラサポート &nbsp; &nbsp; X – via NICE DCV Relative Offset X &nbsp; &nbsp; OS サポート Windows 2016, 2019 Windows 10 Windows, BYOL, Linux, Marketplace AMIs プロトコル NICE DCV PCOIP NICE DCV (推奨), Teradici, Parsec 休眠モード X X 手動 料金体系 時間単位で従量課金 時間単位、月単位で従量課金 時間単位のオンデマンド課金、セービングプラン、リザーブドインスタンス（RI） 認証方法 Microsoft Active Directory, AWS Managed Microsoft AD, AppStream 2.0 User Pools, SAML 2.0 Integration, Streaming URL Creation Microsoft Active Directory, AWS Managed Microsoft AD, SAML 2.0 Integration, AD Connector 任意 マルチモニターサポート 解像度4Kの場合最大2枚、2Kの場合最大4枚対応 GraphicsProの場合3840×2160解像度で最大2枚、1920×1200で最大4枚； Graphicsの場合2560×1600解像度で最大1枚 カスタム可能 まとめ UGC の出現によりゲーム業界は目まぐるしく変化し続けており、すべての人が参画できるようにゲーム開発を民主化することが重要です。Epic Games の Unreal Editor for Fortnite はゲーム開発の民主化への一歩です。UE、UEFN あるいはその他の開発ツールなどツールに関わらず、ゲーム開発ではハードウェア面とコスト面の課題が依然として存在します。これは小さいゲーム会社や個人クリエイターにとっては制約になる可能性があります。AWS は Amazon WorkSpaces、Amazon AppStream と Amazon EC2 などいくつかのクラウドベースのソリューションを提供しています。これらのソリューションは、ゲーム開発上のハードウェア面とコスト面の課題に対処しゲーム開発をよりユーザ重視にすることで、拡張性とコスト効率の向上をお手伝いします。 リソース こちらのリンクを辿ってもっと学習してみましょう！ AWS for Games https://aws.amazon.com/jp/gametech/?nc1=h_ls AWS クラウドゲーム開発 https://aws.amazon.com/jp/gametech/remote-game-production/ はじめての Unreal Engine 5 https://dev.epicgames.com/community/learning/courses/nE0/unreal-engine-5/4VqE/unreal-engine-5 はじめての UEFN https://dev.epicgames.com/community/learning/courses/9DG/fortnite-uefn/2bVB/fortnite-uefn AWS 入門ガイド – https://aws.amazon.com/appstream2/getting-started/ Setup sample applications – https://docs.aws.amazon.com/appstream2/latest/developerguide/getting-started.html Build multiplayer games on cloud – https://aws.amazon.com/blogs/gametech/online-multiplayer-amazon-gamelift-aws-serverless/ Unreal Engine 5 Marketplace AMI – https://aws.amazon.com/marketplace/pp/prodview-iu7szlwdt5clg [1] https://www.gamedeveloper.com/blogs/how-do-different-kinds-of-ugc-satisfy-players-#close-modal 翻訳はソリューションアーキテクトのBaixiao Linが担当しました。

ブルー/グリーンデプロイは、新しいコードの導入に伴うダウンタイムやリスクを最小限に抑えることを目的として、ソフトウェア開発において広く用いられているデプロイメント手法です。このデプロイ戦略は、2つの同一環境（ブルーおよびグリーン）を並行稼働させ、必要に応じてそれぞれの環境間でトラフィックを誘導します。この手法はエンドユーザーに悪影響を及ぼさず、途切れることなく新しい機能や更新をデリバリーできます。必要であれば簡単にロールバックできます。アジリティ、継続的デリバリー、信頼性のあるソフトウェアデリバリーを重視するチームにとって、ブルー/グリーンデプロイは重要なプラクティスです。 この記事では、 Amazon CloudFront の機能である継続的デプロイを活用できるさまざまなユースケースについて議論をします。この機能は、ブルー/グリーンや Canary のテクニックを用いて、動作中のコンテンツ配信ネットワーク（CDN）ディストリビューションをデプロイするためのマネージドな方法を提供しています。これにより、ドメイン全体に渡って変更を加える際のリスクを大幅に低減します。この機能を使用すると、全てのエッジロケーションに変更を展開する前に、本番トラフィックの一部を更新した構成に向けて誘導することで、変更の検証を行えます。 一般的なユースケース CloudFront の継続的デプロイは、ユーザーエクスペリエンスを妨げることなく、新機能、バグ修正、その他の変更をアプリケーションにリリースできる効果的な手法です。この記事では、いくつかの一般的なユースケースについて議論します。 クリティカルなシステムの更新 ビジネスクリティカルなアプリケーションとって、ダウンタイムやユーザーエクスペリエンスへの悪影響を最小限に抑えることは重要です。CloudFront の継続的デプロイを使用すると、既存のバージョンと並行して CDN コードの新しいバージョンをデプロイし、テストを行い、ダウンタイムなしで新しいバージョンに切り替えることができます。この機能により、ゼロダウンタイムでのデプロイや簡単なロールバックが可能となり、古い CloudFront ディストリビューションから新しいディストリビューションへのシームレスな移行を実現します。 A/B テスト CloudFront の継続的デプロイは、ソフトウェア開発における実験に利用することもできます。これは、CloudFront のお客様が自身のユーザーベースを用いて試行できる実験の数を増やし、ビジネスメトリクスを収集して情報に基づいた意思決定を行い、これを繰り返すことで、プロダクトの開発ライフサイクルを短縮できます。 速いロールバック 従来のデプロイメント手法では、変更のロールバックは困難で時間のかかるプロセスとなることがあります。しかし、CloudFront の継続的デプロイでは、もし他のディストリビューションの新しいコードに問題が発生した場合、プライマリディストリビューションのコードに簡単に切り戻すことができます。これにより、デプロイ中に発生しうる様々な問題やバグの影響をユーザーが受けることはありません。 新機能のロールアウト 新機能のローンチでは、CloudFront の継続的デプロイは間違った CDN コードをデプロイするリスクを最小化する手助けをしてくれます。ユーザーの少数のグループに対して更新をリリースすることで、全体のユーザーベースにリリースする前に、開発者はその更新が正しく機能しているかを確認できます。これは、問題の拡大を防ぎ、ユーザーエクスペリエンスへの悪影響を最小限に抑えることができます。 ステージング環境でのテスト コードベースへのあらゆる変更は、まずステージングディストリビューションにデプロイされます。これにより、テストチームは新しい変更に対して包括的なテストを行えます。テストが完了すると、変更内容をステージングディストリビューションから本番ディストリビューションにコピーできます。もしくは、アクティブな環境からアイドルな環境にトラフィックをリダイレクトして、アイドルな環境を新しい本番環境とすることもできます。このアプローチでは、本番環境に展開する前の新しいコードベースに対して、徹底的なテストや検証を実施できます。テスト中に発生したあらゆる問題は、アイドル環境で対処や解決がなされ、本番環境への影響を最小限に抑えることができます。 はじめに CloudFront の継続的デプロイをセットアップする ために、CloudFront マネジメントコンソール、 AWS CloudFormation 、 AWS SDK 、または AWS コマンドラインインターフェイス(AWS CLI) を使用して、既存のディストリビューションの新しいステージングディストリビューションの作成から始めることができます。新しいステージングディストリビューションが作成されると、希望する変更を適用できるようになり、重みベースやヘッダーベースのようなステージングポリシーを設定して、新しいディストリビューションに対するトラフィックを段階的に増やせます。 ステージングディストリビューションが期待通りに動作していることを検証した後、変更内容をメインのディストリビューションにコピーするか、このディストリビューションをプライマリディストリビューションへと昇格させることができます。このプロセスは変更のシームレスかつコントロールされたデプロイを可能とし、エンドユーザーへの影響を最小限に抑えることができます。 ソリューションの概要 サンプルソリューションは、１つの Amazon Simple Storage Service(Amazon S3) オリジンの CloudFront ディストリビューションをデプロイします。また、プライマリディストリビューションへ変更を安全にテストしリリースするために、ステージングディストリビューションを用いた昇格の設定を行えます。推奨されるソリューションとしては、 CloudFront ディストリビューションの設定変更のために、継続的デプロイを有効にした AWS Cloud Development Kit（AWS CDK）パイプライン を実装することです。 1. AWS CDK Pipeline は、プライマリディストリビューション、ステージングディストリビューション、Amazon S3 オリジン、およびデプロイメントポリシーの作成を手助けします。 2. AWS Step Functions ワークフローは、以下のアクションを実行する CloudFront API の呼び出しをオーケストレーションする責務があります。 a. 継続的デプロイポリシーを有効化し、プライマリディストリビューションに紐づける b. 最新のステージングの設定でプライマリディストリビューションを更新する このソリューションの一部では、Amazon S3 オリジンを持つ CloudFront ディストリビューションのデプロイと、変更のテストやプライマリディストリビューションへの昇格を目的としたステージングディストリビューションの設定を行います。 リファレンスソリューション リファレンスソリューションの GitHub リポジトリはこちら です。 実装の詳細 ステップバイステップで実装の詳細を示すと以下のようになります。 1. cdk deploy コマンドによるパイプラインスタックの作成 2. プライマリディストリビューションに対して変更をリリース a. プライマリディストリビューションのスタックを更新して、ディストリビューションの設定を変更します。変更内容をコードリポジトリにコミットします。 b. リポジトリへのコードのコミットがパイプラインをトリガーします。 c. パイプラインはプライマリディストリビューションに対して変更のデプロイを行う一連のステージを実行します。 3. CloudFront の継続的デプロイを使用した継続的デプロイのワークフロー a. プライマリディストリビューションがデプロイされて有効になると、パイプラインを継続的デプロイモードに更新することで、ディストリビューションへのあらゆる変更がブルー/グリーンデプロイもしくは Canary デプロイを使用してリリースされます。 b. 継続的デプロイはパイプラインコード内のフラグを更新することで有効化できます。これはステージングディストリビューションを使用して変更を昇格させます。 c. パイプラインでは SingleHeader トラフィック設定またはブルー/グリーンデプロイを使用します。パイプラインコード内のフラグを更新することで SingleWeight トラフィック設定を使用するように更新することもできます。 d. SingleWeight を選択した場合、リクエストを同じ CloudFront ディストリビューションで処理しながらユーザーに同じ体験を提供しつづけるための session stickiness の設定を選択できます。 e. ディストリビューションの設定に変更を加え、リポジトリにコミットします。 f. リポジトリへの変更のコミットがパイプラインをトリガーします。変更を反映したステージングディストリビューションと、ヘッダーベースまたはウェイトベースによるトラフィックの振り分けを含んだデプロイメントポリシーが作成されます。 g. Step Functions をパイプラインのステップとして実行することにより、継続的デプロイポリシーのプライマリディストリビューションへのアタッチまたはリンクが行われます。 ディストリビューションにデプロイメントポリシーをアタッチするため、Step Functions はデプロイメントポリシーを有効にし、プライマリディストリビューションを更新します。 h. パイプラインは、ステージングディストリビューションでの変更をプライマリディストリビューションに昇格する前に、手動での承認を待ちます。 i. 検証した後、パイプラインではステージングの変更を含んだプライマリディストリビューションへの更新を承認する必要があります。これにより、変更がリリースされます。変更をリリースするために、パイプラインは Step Functions を実行します。 CloudFront API を呼び出し、プライマリディストリビューションをステージングの設定で更新します。 まとめ CloudFront の継続的デプロイは、最小限のリスクと最大の効率性でソフトウェアの更新をリリースするための強力なツールです。CloudFront の継続的デプロイが利用可能になったことで、ソフトウェアリリースの速度と信頼性をさらに向上させることができます。CloudFront のエッジサーバーのグローバルネットワークを活用することで、デプロイメントが世界中のユーザーに素早くかつ簡単に展開され、一貫したユーザーエクスペリエンスを保ち、ダウンタイムを最小限に抑えるられるようになりました。 本記事は「 Achieving Zero-downtime deployments with Amazon CloudFront using blue/green continuous deployments 」の翻訳となります。 このブログの翻訳はプロフェッショナルサービスの 鈴木（隆） が担当しました。

小売業では常に、実店舗へのアクセスや人通りを増やすことを目指しています。そのためには、潜在顧客が最も便利な店舗を正確に特定できなければなりません。最もアクセスしやすい店舗に関する情報を、便利な Web/Mobile アプリケーションを通じて潜在顧客に提供することで、小売企業は来店を増やし、顧客体験を向上させることができます。何千もの店舗を持つ全国規模の小売業者も、数店舗しかない地元の小さな金物屋も、小売店舗を顧客にとってよりアクセスしやすくすることで、利益を得ることができます。 Amazon Location Service は、サーバーレスでフルマネージド位置情報サービスで、開発者は Esri 、 HERE Technologies 、 GrabMaps などの信頼できる商用プロバイダーやオープンデータからのデータを使用して、アプリケーションに位置情報機能をコスト効率よく追加することができます。Amazon Location を利用することで、オンラインストアでの体験を位置情報機能で簡単に補強し、顧客を店舗に誘導することができます。 本記事では、Amazon Location の Maps 、 Places 、および Routing API を使用して、営業時間や住所などの適切な店舗情報とともに、顧客にとって最もアクセスしやすい実店舗をリストアップするシンプルな店舗検索 Web ページを実装する方法を紹介します。 2 つのパターンを紹介します。1 つ目のパターンは、イギリスほどの大きさの地域に分散している 20 店舗未満のビジネスを想定しています。2 つ目のパターンは、米国サイズの地理的エリアに分布する 20 以上の店舗を持つビジネスを想定しています。 顧客体験 店舗検索サイトでは、2 つのオプションを提示するシンプルな Web ページが表示されます。 現在地を Web ブラウザと共有することに同意し、出発地点として使用します。これは、顧客が今すぐ店舗を訪れたい場合に便利です。 店舗検索サイトの検索したい場所を説明するテキスト（都市名など）を入力します。その後、顧客は出発地候補のドロップダウンから場所を選ぶことができます。場所が選択されると、この場所は出発位置に ジオコーディングされます 。これは、顧客が将来ある店舗を訪問する予定がある場合に便利です。 図 1 : 店舗検索のランディングページのナビゲーション 出発地が店舗検索サイトのバックエンドに送信された後、最も近い店舗が、顧客の体験を助ける以下の店舗情報とともに返されます。 推定所要時間と距離 営業時間 住所 図 2 : 最寄りの店舗リストの表示 店舗の位置は地図上のマーカーとして表示されます。 ソリューション概要 このソリューションでは、フロントエンドに Vue.js 3.0の シングルページアプリケーション (SPA) を使用します。この SPA は、 AWS Amplify Hosting を使用してホスティングされています。AWS Amplify Hosting は、フロントエンドのWeb および Mobile 開発者が AWS 上でフルスタックアプリケーションを簡単に構築、ホスティングできるフルマネージドサービスです。 バックエンドの AWS サービスは、データストアからストア情報を取得し、Amazon Location Service を使用してルーティングを実行し、関連する結果をフロントエンドに返すための API を提供します。このソリューションは、API をホストするために Amazon API Gateway 、ビジネスロジックを実装するために AWS Lambda 関数 、そして選択されたパターンに応じて店舗情報を保持するために Amazon DynamoDB または Amazon Aurora Serverless のいずれかを使用します。 コストを最適化するために、このソリューションを作成する際に 2 つのパターンを想定します。 ソリューションパターン タイプ 店舗数 国 1 小規模 &lt; 20 イギリス 2 中 ~ 大規模 ≥ 20 アメリカ アーキテクチャ図 以下に示すのは、両方のパターンのアーキテクチャ図です。 図 3 : ソリューションのアーキテクチャ図 2 つのパターンでソリューションが異なる部分には、青 (パターン 1) と赤 (パターン 2) の色を使い、違いを強調しています。 ソリューションの仕組み 以下がソリューションの仕組みです。 顧客は、Amplify Hosting がホスティングする店舗検索 Web サイトにアクセスします。この Web サイトは、Vue.js 3フレームワークを使用して構築されており、 aws-amplify 、 maplibre-gl-js-amplify 、 maplibre-gl JavaScript ライブラリを使用して、 Amazon Cognito 、Amazon Location Service、およびベクトルタイルやマーカーなどのインタラクティブなマップオブジェクトの実装を容易にします。 顧客は、Amazon Cognito ユーザープールを使用して認証します。aws-amplify ライブラリは、登録と認証のワークフローを処理し、Amazon Cognito ID プールから一時的にスコープダウンされた AWS 認証情報を取得します。認証されたアクセスに関連する AWS Identity and Access Management (IAM) ロールは、Amazon Location Service リソースにアクセスするのに必要な最小限の権限のみを含んでいます。 maplibre-gl JavaScript ライブラリを使用して、 Web ページは、Maps API を使用して Amazon Location からダウンロードされたベクトルタイルを使用してインタラクティブなマップを表示します。マーカーは、結果が返されたときに出発地と目的地の店舗の場所を表示するために使用されます。 顧客が検索フィールドにカスタムテキストを入力すると、Amazon Location の SearchPlacesIndexForSuggestions Places API が呼び出され、提案された場所のリストをドロップダウンとして返します。顧客が選択肢の 1 つを選択すると、ジオコーディングのための GetPlace Places API が、出発地の位置座標を返す選択された PlaceId に対して呼び出されます。オプションとして、顧客は Locate me ボタンを使用してブラウザに現在地を確認させることができます。 選択された出発地は、API Gateway を使用してホストされているソリューションのカスタム API に送信されます。リクエストのペイロードはハッシュ化され、API Gateway は一般的にリクエストされる出発地（例えば、ラスベガスやロンドン）のキャッシュからレスポンスを返すことができます。 このステップは使用するパターンによって異なります。 パターン1 – API Gateway API は、DynamoDB のテーブルからすべての店舗位置情報を返す Lambda関数を呼び出します。 パターン2 – Lambda 関数は、PostgreSQL の PostGIS 地理空間機能 ( ST_DistanceSphere ) を使用して、目的地の店舗の候補のサブセットを返すクエリします。この Aurora Serverless PostgreSQL データベースの認証情報は、 AWS Secrets Manager に安全に保存されます。 両方のパターンについて、返された目的地店舗のリストは、これらの目的地までの推定距離と時間を確認するために Amazon Location の CalculateRouteMatrix Routes API を使用します。 ターゲット店舗とそのメタデータの控えめなショートリストがフロントエンドに返され、この情報は店舗検索 Web ページ上で顧客に提示される。 店舗の位置情報の想定 このデモのために、以下のデータソースを使用します。 イギリス – Network Rail が管理する鉄道駅 （18 箇所） 米国 – 1639 年から 2000 年の間に米国で運営された郵便局 （112,000 箇所以上） 店舗データは、提供されたテンプレートによって自動的にデータストアにロードされます。データインポートの仕組みについては、 GitHub リポジトリ を参照してください。 なぜマトリックス・ルーティングを使うのか？ 顧客が訪問する最寄りの店舗を特定する場合、評価されるルートは、顧客が選択した交通手段と、位置情報データプロバイダーが収集した交通網の現在の可用性に基づいていなければなりません。顧客の出発位置と候補店舗との間の大円距離を計算するだけでは、非現実的な結果が得られる可能性があり、不十分です。 以下の例では、カーディフ空港は物理的にイギリスのマインヘッドに近い位置にあります。しかし、間に水域があるため、道路を使用した場合、マインヘッドからよりアクセスしやすい空港は、実際にはブリストル空港です。 図 4 : マトリックス・ルーティングを使用して最寄りを計算する このソリューションのパターン 2 では、目的地となり得る店舗数が多い場合、Amazon Location の Routing API の使用を最小限にするため、座標間の大円距離に基づいて候補店舗の暫定リストを生成します。マトリックス・ルーティング API を使用する場合、計算されるルート数に対する 価格 は、出発地の数に目的地の数を掛けた数によって決まるため、多数の店舗を運営するビジネスでは、この方が費用対効果が高くなります。このパターンは、クエリあたりのコストを一定に保ちながら、何十万もの店舗にスケールすることができます。 さらに、どちらのパターンでも、API Gateway 上で キャッシュを有効 にし、繰り返しクエリに対するレスポンスがキャッシュから直接返されるようにし、バックエンドのインフラを経由しないようにしてます。これにより、結果取得の待ち時間とコストが削減されます。 チュートリアル aws-samples の GitHub リポジトリ が用意されているので、このソリューションを自分で試すことができます。以下のステップに従うと、サーバーレス店舗検索サイトの両方のパターンについて、フロントエンドとバックエンドのリソースがデプロイされます。 ソリューションをカスタマイズする方法の詳細については、リポジトリを参照してください。 前提条件 このチュートリアルの前提条件は以下の通りです。 AWS アカウント AWS Serverless Application Model (AWS SAM) を使用して AWS リソースをデプロイするための IAM 権限 AWS SAM Command Line Interface (CLI) のインストール Vue js 3.0 のインストール コードのダウンロード AWS SAM のインストール 公式ドキュメント の手順に従って、オペレーティングシステム用の AWS SAM CLI の最新リリースをインストールします。 sam —version を実行して AWS SAM CLI が正常にインストールされたか確認します。 注: AWS SAM CLI には、選択した AWS アカウントでリソースをプロビジョニングするための適切な権限が必要です。IAM を使用して アクセスキーとシークレットアクセスキー が作成され、 aws configure を使用してマシンにローカルに登録されていることを確認する必要があります 両方の API パターンで必要なすべてのフロントエンドコード、バックエンドコード、AWS SAM テンプレートは、 serverless-store-finder GitHubリポジトリ に格納されています。 以下のコマンドを実行して、すべての必要なファイルをダウンロードします。 git clone https://github.com/aws-samples/serverless-store-finder ダウンロードしたリポジトリのルートに移動し、JavaScript の依存関係をインストールします。 cd serverless-store-finder npm install .env.local.template ファイルをコピーし、.env.local に名前を変えます。 cp .env.local.template .env.local env.local.template ファイルには、AWS SAM テンプレートのデプロイからの出力が入力されます。 これで AWS SAM テンプレートをデプロイする準備ができました。 SAM テンプレートのデプロイ 店舗検索サイト AWS SAM テンプレート Store Finder - Core は、両方のパターンで必要な共有インフラリソース、つまり Amazon Location Map、Place Index、Route Calculator、Amazon Cognito ユーザープールと ID プールをデプロイします。この AWS SAM テンプレートは、空の Amplify Hosting アプリも作成します。 SAM テンプレートのデプロイ sam/core ディレクトリに移動します。 cd sam/core アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されます。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、以下のように詳細を入力します。残りの項目はデフォルトのままでかまいません。 Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: &lt;Your Store Finder "Core" Amazon CloudFormation stack name&gt; AWS Region [eu-west-1]: &lt;Your AWS Region&gt; Parameter storeFinderAmplifySubdomain [demo]: &lt;Amplify environment subdomain name used in URL&gt; この例では、スタック名を myStoreFinder-Core-v1 とし、AWS リージョン eu-west-1 にデプロイしています。 パラメータ storeFinderAmplifySubdomain にどのような名前を選択したかをメモしておいてください。後でアプリケーションを Amplify Hosting にデプロイするときに使用します。今回は、 demo としました。 図 5 : AWS SAM テンプレート “Store Finder – Core” のデプロイ Successfully created/updated stack と表示されることを確認します。 図 6 : AWS SAM テンプレート “Store Finder – Core” のデプロイ成功の確認 .env.local ファイルに不足している Amazon Location と Amazon Cognito の詳細を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_AWS_REGION=&lt;Your AWS Region&gt; VITE_AMAZON_COGNITO_IDENTITY_POOL_NAME=&lt;storeFinderAmazonCognitoIdentityPoolName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_COGNITO_USER_POOL_NAME=&lt;storeFinderAmazonCognitoUserPoolName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_COGNITO_USER_POOL_CLIENT_NAME=&lt;storeFinderAmazonCognitoUserPoolClientName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_LOCATION_SERVICE_MAP=&lt;storeFinderAmazonLocationServiceMapName from the Store Finder "Core" Amazon CloudFormation stack output&gt; VITE_AMAZON_LOCATION_SERVICE_PLACES_INDEX=&lt;storeFinderAmazonLocationServicePlaceIndexName from the Store Finder "Core" Amazon CloudFormation stack output&gt; 店舗検索 – API パターン1 AWS SAM テンプレート Store Finder - API Pattern 1 は、API Gateway、Lambda 関数、DynamoDB テーブルなど、パターン 1 で必要なバックエンド API インフラストラクチャとコードをデプロイします。この API は独立して機能し、パターン 2 に依存しません。 SAM テンプレートのデプロイ sam/api-pattern1 ディレクトリに移動します。 cd ../api-pattern1 アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されていることを確認します。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、以下のように詳細を入力します。残りの項目はデフォルトのままでかまいません。 図 7 : AWS SAM テンプレート “Store Finder – API Pattern 1” のデプロイ この例では、スタック名を myStoreFinder-API-v1 としています。 Successfully created/updated stack と表示されることを確認します。 図 8 : AWS SAM テンプレート “Store Finder – API Pattern 1” のデプロイ成功の確認 .env.local ファイルに足りない API エンドポイントの値を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_APIGATEWAY_ENDPOINT_API1=&lt;storeFinderAPIGatewayEndpoint from the Store Finder "API1" Amazon CloudFormation stack output&gt; 注：AWS SAMテンプレート Store Finder - API Pattern 1 には、 stores.json ファイルからストアデータを自動的にロードする Lambda カスタムリソース が含まれています。API 1 の準備は完了です。 店舗検索 – API パターン 2 AWS SAM テンプレート Store Finder - API Pattern 2 は、API Gateway、Lambda 関数、Amazon Aurora Serverless V2 PostgreSQL データベース、Secrets Manager のシークレットなど、パターン 2 で必要なバックエンド API インフラストラクチャとコードをデプロイします。この API は独立して機能し、パターン 1 に依存しません。 SAM テンプレートのデプロイ sam/api-pattern2 ディレクトリに移動します。 cd ../api-pattern2 アプリケーションをビルドします。 sam build Build Succeeded メッセージが表示されていることを確認します。 アプリケーションをデプロイします。 sam deploy --guided プロンプトが表示されたら、お使いの環境で選択した詳細を入力します。残りはデフォルトのままでかまいません。 Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: &lt;Your Store Finder "API2" Amazon CloudFormation stack name&gt; AWS Region [eu-west-1]: &lt;Your AWS Region&gt; Parameter storeFinderCoreCloudFormationStackName []: &lt;Name of the Store Finder "Core" Amazon CloudFormation stack&gt; Parameter storeFinderAuroraDBMasterUserName [admin_user] &lt;Name of the PostgreSQL admin user account&gt; Parameter storeFinderDatabaseTableName [tbl_postoffices]: &lt;Name of table to be used in PostgreSQL database&gt; この例では、スタック名を myStoreFinder-API2-v1 としています。 図 9 : AWS SAM テンプレート “Store Finder – API Pattern 2” のデプロイ Successfully created/updated stack と表示されることを確認します。この SAM テンプレートの展開には、最大 20 分かかります。 図 10 : AWS SAM テンプレート “Store Finder – API Pattern 2” のデプロイ成功の確認 .env.local ファイルに不足している API エンドポイントの値を、デプロイされた CloudFormation スタックから出力された値で入力します。 VITE_APIGATEWAY_ENDPOINT_API2=&lt;storeFinderAPIGatewayEndpoint from Store Finder "API2" Amazon CloudFormation Stack output&gt; 注：AWS SAM テンプレート Store Finder – API Pattern 2 には、 us-post-offices.csv ファイルから店舗データを自動的にロードする Lambda カスタムリソース が含まれています。API 2 の準備は完了です。 Amplify Hosting を使って Vue.js アプリケーションをビルドしてデプロイ 注：このデモを簡単にするために、Amplify Hosting はソフトウェアのバージョン管理システムと統合せずに使用しています。実際のアプリケーションでは、Amplify を Git ベースのリポジトリと統合することを強くお勧めします。 Vue.js アプリケーションをビルドしてデプロイ .env.local ファイルに空欄がないことを確認します。 プロジェクトフォルダのルートディレクトリでフロントエンドアプリケーションをビルドします。 cd ../.. npm run build 図 11 : “npm run build” の正常終了の確認 Vue.js のデプロイファイルが /dist に正常に作成されていることを確認します。 cd dist ls 以下のコマンドを実行して、フォルダ内のすべてのファイルを圧縮します。 正確なコマンドは、お使いの OS によって異なる場合があります。 zip -r store-finder.zip . 注：zip 操作は、フォルダレベルではなく、 /dist ディレクトリ内で行う必要があることに注意してください。その後、 .env.local ファイルを変更した場合は、Vue.js アプリケーションを再度ビルドし、以下の手順を繰り返す必要があります。 Amplify コンソールを開き、AWS SAM テンプレート Store Finder - Core で作成された Amplify アプリを選択します。 Deploy without Git provider を選択し、 Connect branch を選択します。 図 12 : Git プロバイダーなしで Amplify アプリをデプロイ Environment name には、AWS SAM テンプレート Store Finder - Core のデプロイ時に、SAM テンプレートパラメータ storeFinderAmplifySubdomain に指定した名前 (例： demo ) と同じ名前を指定します。 Method では、 Drag and drop を選択し、先に作成した store-finder.zip ファイルをアップロードします。これで自動的にデプロイが開始され、サイトが公開されます。 図 13 : Vue.js デプロイ用 zip ファイルをドラッグ＆ドロップ Amplify コンソールに Deployment successfully completed のメッセージが表示されるまで待ちます。 これで、Amplify Hpsting のドメインが提供する URL を使って、サーバーレス店舗検索サイトにアクセスできるようになりました。 図 14 : Amplify アプリのドメイン URL を使った店舗検索サイトへのアクセス このサイトにアクセスすると、まず最初にアカウントの作成とメールアドレスの確認が求められます。 注：このステップは、認証を強制することによって、デモのフロントエンドとバックエンド AP Iを保護します。ユースケースによっては、店舗検索サイトのサイトを Web サイトの訪問者が一般にアクセスできるようにする必要があるかもしれません。 図 15 : Amazon Cognito を使ったアカウントの作成 Select a country ドロップダウンを United Kingdom と United States の間で切り替えて、2 つの API パターンを試すことができます。 図 16：サーバーレス店舗検索サイトのデプロイのテスト クリーンアップ 課金を避けるために、AWS アカウントにプロビジョニングされた CloudFormation スタックを削除しましょう。 まとめ 本記事では、Amazon Location Service を使用して、顧客が最寄りの実店舗を検索できるシンプルで費用対効果の高い Web サイトを作成する方法を紹介しました。Amazon Location の Maps、Places、Routes API を使用することで、店舗検索 Web ページへの訪問者は、現在地、または将来的な位置から最も近い場所を素早く特定することができます。この情報は、どの店舗を訪れるかについての情報に基づいた意思決定に使用することができ、顧客の来店を増やすことができます。 著者プロフィール Alan Peaty Alan はパートナーソリューションアーキテクトとして、グローバルシステムインテグレーター (GSI) とその顧客の AWS サービス導入を支援しています。AWS に入社する前は、IBM、Capita、CGI などのシステムインテグレーターでアーキテクトとして働いていました。仕事以外では、アランはイギリスの田舎のぬかるんだトレイルを走るのが好きな熱心なランナーであり、IoT 愛好家でもあります。 Matt Nightingale マットは Amazon Web Services のシニアスタートアップソリューションアーキテクトで、スタートアップ企業が AWS 上でコスト効率と拡張性の高いソリューションを構築、拡張できるように支援しています。スタートアップと仕事をしていないときは、位置情報サービスを含むソリューションを構築しています。マットは 2020 年に AWS に入社し、マサチューセッツ州ボストンを拠点としています。 この記事は Matthew Nightingale と Alan Peaty によって書かれた Build a serverless store finder site using Amazon Location Service の日本語訳です。翻訳は、ソリューションアーキテクトの 稲田大陸 が担当しました。

はじめに 2023 年 6 月 29 日、出版業界のお客様向けに生成 AI の活用というテーマでセミナーをオンラインにて開催しました。このセミナーの開催報告として当日ご紹介した内容や資料をご紹介いたします。 本セミナー開催の背景についてご説明します。ビジネスへの活用が期待されている生成 AI は日々発展を続けており、新しい基盤モデルや新サービスの発表が相次いでおります。その様な環境の中、出版業界のお客様向けに、生成 AI を使った業務効率化やコンテンツ・IP の活用に関して、AWS で実現できる事のご紹介をさせて頂きたいと考え、セミナーを開催させて頂きました。セミナーの中では、AWS で生成 AI を活用する方法や、出版業界のお客様向けのユースケースのご紹介を致しました。 全体の資料は こちら よりダウンロード可能です。 AWS の生成 AI に関する取り組み アマゾン ウェブ サービス ジャパン合同会社 メディアソリューション部 ソリューションアーキテクト 本多 和幸 アマゾン ウェブ サービス ジャパン 本多より、AWS の生成 AI に関する取り組みと、今すぐ AWS 上で生成 AI を使い始める方法についてご紹介しました。生成 AI をビジネスに活かすためには、3 つの点が重要であるとお伝えしました。1 つ目は、1 つのモデルに依存せず幅広い基盤モデルの中から用途に適したモデルを選択する事、2 つ目は最適なパフォーマンスとコストの両立、3 つ目はアプリケーションへの統合を迅速に行える開発の利便性です。AWS ではこの 3 点全てにおいて、お客様のご要望にお応えできる環境をご用意しております。また、AWS 上で生成 AI の基盤モデルを動かす事ができるサービスは主に次の 3 つがあり、 Amazon Bedrock 、 Amazon SageMaker 、 Amazon EC2 それぞれについてご紹介しました。 Amazon Bedrock は、複数の基盤モデルをサーバーレスでお使い頂ける 2023 年 4 月に発表された新サービスです。お客様のユースケースに沿って AI21 Labs, Anthropic, Cohere, Stability AI, Amazon の基盤モデルを選択して頂けます。Amazon SageMaker は、機械学習に特化したプラットフォームです。 Amazon SageMaker JumpStart では、事前に用意されている基盤モデルを数クリックでホスティングする事ができます。Amazon EC2 では生成 AI に必要な学習と推論に特化した最新インスタンスが先般発表されました。Amazon EC2 は基盤モデルを独自開発するためのリソースとしてお使い頂けますし、基盤モデルの推論のリソースとしてもお使い頂けます。 AWS を活用した出版業界での生成 AI のユースケース アマゾン ウェブ サービス ジャパン合同会社 メディアソリューション部 ソリューションアーキテクト 前川 泰毅 アマゾン ウェブ サービス ジャパン 前川より、出版業界で応用できる生成 AI のユースケースをご紹介いたしました。今回ご紹介したトピックは大きく分けて、大規模言語モデル、音声要約、画像素材の生成/編集です。これらを応用する事で以下のような業務効率化、クリエイティブなアウトプットの生成が期待できます。 大規模言語モデル: 社内の編集部ごとに分割管理された資料をソースにした社内専用チャットボット 間違った回答をする可能性がある大規模言語モデル の弱点を補う事ができるソリューションです。 音声要約: 取材、インタビューのサマリや、音声から記事草案の自動生成 音声をテキストに変換する Amazon Transcribe と大規模言語モデルを組み合わせる事で実現できます。 画像素材の生成/編集: 記事の挿絵や、背景画、広告クリエイティブの自動生成、古いコンテンツのリマスター 画像生成の基盤モデルである Stable Diffusion を GUI で扱う環境の構築方法もご紹介しました。 併せて、それぞれのユースケースで直ぐに生成 AI を試せるリソースとして、基盤モデルの学習に使えるサンプルコードや AWS CloudFormation のテンプレートファイルもセミナー内でご紹介致しました。本セミナー資料内でサンプルコードやテンプレートファイルや構築方法をガイダンスしたブログ記事もご紹介していますのでぜひご参照ください。 学習データに使うコンテンツのデータ保護について 続いて、前川から AWS 上で基盤モデルの学習を行う際のデータ保護についてご説明しました。 重要な知的財産を扱う出版各社様にとってコンテンツの保護は非常に重要な課題です。基盤モデルを利用すると入力した情報が AWS や大元の基盤モデルの改善に使われるのではないかというお問合せも多く頂きますが、AWS 上のお客様のデータもお客様専用にチューニングしたモデルも、お客様の AWS 環境内でセキュアに管理可能です。AWS が勝手にデータやモデルを利用することはなく、また基盤モデルの学習に使用されることもありません。 セミナー後の最新情報について 2023 年 7 月末に開催された AWS Summit New York において、Amazon Bedrock の拡張を発表しました。今回の拡張により、基盤モデルを提供する企業として知られる Cohere、Anthropic と Stability AI の最新の基盤モデル、さらには、専門知識がなくても数回クリックするだけで、フルマネージドエージェントを作成できる革新的な新機能が追加されることになりました。 詳細は、 こちらの記事 をご覧ください。 おわりに 本ブログでは、2023 年 6 月 29 日に開催された「AWS で始める！出版業界向け生成 AI 活用のご紹介～大規模言語モデルから画像生成まで～」の内容をご紹介させて頂きました。本セミナーにご参加頂いた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、ソリューションアーキテクト本多が担当しました。

2022 年 1 月、 Amazon EC2 Hpc6a インスタンスがリリースされました 。これにより、コンピューティング関連のハイパフォーマンスコンピューティング (HPC) ワークロードを AWS で効率的に実行することが可能になるだけでなく、コンピューティングに最適化された 同等の x86 ベースのインスタンスに比べてコストパフォーマンスが最大 65% 向上します。 ジョブが複雑になるにつれて、お客様は、ジョブを完了するまでの時間を短縮するために、より高いコンピューティングパフォーマンスを備えたコアと多くのメモリ、そしてネットワークパフォーマンスを求めるようになりました。さらに、お客様は、より多くの HPC ワークロードを EC2 に導入することを検討しているため、AWS でプロセスを簡単に分散させ、ワークロード要件に合わせてメモリとネットワーク帯域幅を最大限に活用する方法を求めています。 8月17日、緊密に結合された HPC ワークロード向けに設計された次世代のインスタンスタイプである Amazon EC2 Hpc7a インスタンス の一般提供が開始されたことをお知らせします。 第 4 世代 AMD EPYC プロセッサ (Genoa) を搭載した Hpc7a インスタンスは、Hpc6a インスタンスに比べて最大 2.5 倍のパフォーマンスを発揮します。Hpc7a インスタンスは、 AWS Nitro System による 300 Gbps の Elastic Fabric Adapter (EFA) 帯域幅を提供し、高速で低レイテンシーのノード間通信を実現します。 DDR4 メモリよりも 50% 高いメモリ帯域幅を提供する Double Data Rate 5 (DDR5) メモリを搭載している Hpc7a インスタンスでは、メモリ内のデータへの高速アクセスが可能です。Hpc7a インスタンスは、 数値流体力学 (CFD) や 数値予報 (NWP) など、コンピューティング集約型でレイテンシーに敏感なワークロードに理想的です。 Hpc6a で実行している場合、Hpc7a インスタンスを使用すれば、Hpc6a インスタンスの 2 倍のコア密度、2.1 倍の有効メモリ帯域幅、そして 3 倍のネットワーク帯域幅を活用して、ジョブの完了に必要な時間を短縮できます。 Hpc7a インスタンスと第 4 世代 AMD EPYC プロセッサ (Genoa) と以前のインスタンスおよびプロセッサの比較を示すインフォグラフィックを以下に示します。 Hpc7a インスタンスでは、最大 192 コアの AMD EPYC プロセッサ CPU と 768 GiB RAM を利用できます。詳細な仕様は次のとおりです。 インスタンス名 CPU RAM (Gib) EFA ネットワーク帯域幅 (Gbps) アタッチされたストレージ Hpc7a.12xlarge 24 768 最大 300 EBS のみ Hpc7a.24xlarge 48 768 最大 300 EBS のみ Hpc7a.48xlarge 96 768 最大 300 EBS のみ Hpc7a.96xlarge 192 768 最大 300 EBS のみ これらのインスタンスではコンピューティング、メモリ、ネットワークパフォーマンスが向上し、CFD、天気予報、分子動力学、計算化学など、コンピューティング集約が最も高いワークロードを AWS で実行できます。 今年の7月にリリースされた EC2 Hpc7g インスタンス と同様に、お客様は小さいインスタンスサイズを使用して、アクティブ化する CPU コアの数を抑えながら、他のすべてのリソースをワークロード要件に基づいて一定に保つことができます。HPC ワークロードの場合、CFD ワークロードのコアあたりのメモリ帯域幅の増加、ライセンス制限のあるシナリオでの割り当てコア数の削減、コアあたりのメモリの増加などのシナリオが考えられます。詳細については、AWS HPC ブログの「 Instance sizes in the Amazon EC2 Hpc7 family – a different experience 」を参照してください。 Hpc6a インスタンスと同様に、Hpc7a インスタンスを使用して EC2 上で最大かつ最も複雑な HPC シミュレーションを実行し、コストとパフォーマンスを最適化できます。新しい Hpc7a インスタンスを AWS Batch と AWS と AWS ParallelCluster とともに使用して、ワークロードの送信とクラスターの作成を簡素化することもできます。 Amazon FSx for Lustre を使用すると、レイテンシーをミリ秒以下に抑え、1 秒あたり最大数百ギガバイトのストレージのスループットを実現できます、 HPC ワークロードのパフォーマンスを最大限に高めるため、これらのインスタンスでは、 同時マルチスレッド (SMT) が無効化されています。また、これらのインスタンスは、単一のアベイラビリティーゾーンで使用でき、外部ネットワークと EBS 帯域幅は制限されています。 今すぐご利用いただけます Amazon EC2 Hpc7a インスタンス は、現在、米国東部 (オハイオ)、欧州 (アイルランド)、US GovCloud の 3 つの AWS リージョンにおいて、 オンデマンド 、 リザーブドインスタンス 、 Savings Plans で購入できます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 Hpc7a インスタンスのページ にアクセスし、 HPC チーム 、 AWS re:Post for EC2 、または通常の AWS サポート連絡先にお問合せください。 — Channy 原文は こちら です。

医療情報システムとは、医療に関する患者情報を扱うシステム全般を指し、安全かつ信頼性のあるアーキテクチャで構築、運用される必要があります。 具体的には、日本では 3 省 2 ガイドライン ( 厚生労働省が定めた「 医療情報システムの安全管理に関するガイドライン 」 、総務省・経済産業省が定めた「 医療情報を取り扱う情報システム・サービスの提供事業者に おける安全管理ガイドライン 」の総称 ) に対し、医療機関等と共に関連事業者や責任者が要求事項を整理検討し、必要に応じて対策を施す必要があります。 前回の 医療情報ガイドラインの改定から読み解くクラウド化 のブログでは、3 省 2 ガイドラインにおける医療情報を取り扱う情報システム・サービスの提供事業者と医療機関等の位置付けについて取り上げました。 厚生労働省のガイドラインは、医療情報システムのサービス提供事業者だけではなくサービスを委託する医療機関等が主体的に遵守する必要があります。医療機関等のシステム管理者および責任者は、ガイドラインの情報を整理し、サービス事業者との契約の際に、当該サービスを利用した運用形態がガイドラインに準拠していることを自ら確認する必要があります。下記の厚生労働省が公開している Q&amp;A では、クラウド型の電子カルテサービスを例に挙げ、サービスを委託する際に医療機関等がガイドラインに準拠しているかを確認する必要性が明記されています。 Ｑ－23 クラウド型の電子カルテサービスを行う業者に認定制度のようなものはあるのか。もしなければ、業者を選定する際に３省のガイドラインに準拠していることは、どうやって確認すればよいのか。 Ａ 認定制度は現在のところ存在しません。なお、厚生労働省のガイドラインは、サービス提供業者ではなく、サービスを委託する医療機関等が遵守すべきものです。 サービス業者の選定に当たっては、「「医療情報を取り扱う情報システム・サービスの 提供事業者における安全管理ガイドライン」に準拠している旨」をサービス業者に確認させるとともに、契約を結ぶ際に、その旨を条項に盛り込んでおくとよいでしょう。 また、サービスを委託する医療機関は、当該サービスを利用した運用形態が、厚生労働省のガイドラインに準拠していることを、自ら確認してください。 「医療情報システムの安全管理に関するガイドライン 第 6.0 版」 に関するＱ＆Ａ 企画管理編 Q-23 より 抜粋 従来のオンプレミス型の医療情報システムでは、サーバ室の管理からハードウェア機器の管理まで、医療情報システムの担当者や責任者が確認すべき点は膨大な範囲でした。AWS を活用することにより、これらの一部をオフロードし、運用上の負担の軽減に役立ちます。（参考： AWS の クラウドが選ばれる 10 の理由 ） 本ブログでは、はじめに AWS の責任共有モデル に触れ、どのように医療機関等のお客様が負担をオフロードできるかについて整理します。次に、クラウド環境で医療情報システムを構築・運用する際に、特にご質問をいただくことの多いネットワークの観点で、Part 1 では厚生労働省の医療情報ガイドラインに即した医療情報システム構築におけるポイントとして、専用線的接続や VPN を利用し医療機関等の拠点とクラウドを接続するハイブリッド構成に焦点を当ててご紹介します。 医療情報システムにおける責任共有モデル 従来のオンプレミス環境では、お客さま自身のデータやアプリケーションの運用に加え、物理的なハードウェア、ネットワークなどのインフラストラクチャの管理などを行う必要があり、お客様の責任範囲は膨大となっていました。AWS では 責任共有モデル に従って、セキュリティとコンプライアンスは AWS とお客様の間で共有される責任としています。 セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。 責任共有モデル より抜粋 この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。 また、お客様がクラウドサービス事業者を利用する際の多くは重層的な責任共有モデルとして考えられます。（参考： 責任共有モデルとは何か、を改めて考える ）。医療情報システムにおいても以下のように考えられます。 ここで、AWS は医療情報システムにおける 3 章 2 ガイドラインへ対応しているか？ という質問を多くのお客様よりいただきます。AWS では責任共有モデルに従って、お客様や AWS パートナーの皆様の固有のシステム要件やアプリケーションの要求事項に見合う形で、どのように各種 AWS サービスをご活用いただけるかということを検討するための AWS サービスに関する情報をご提供し お客様ご自身にご判断いただいております 。そのため AWS から一概に対応可否を回答しておりませんが、AWS パートナー各社作成の「 医療情報システム向け AWS 利用リファレンス 」を活用いただくことが可能です。 したがって、クラウドの利用においても医療機関等は仕組みを正しく理解した上で、ガイドラインを遵守した構築を医療情報を取り扱う情報システム・サービス提供事業者へ委託を行う必要があります。 ここまで責任共有モデルに従いクラウド ’の’ セキュリティ(Security ‘of’ the Cloud)をご紹介しましたが、AWS ではお客様が クラウド ’における’ セキュリティ(Security ‘in’ the cloud) を高めるためのマネージドサービスを提供しております。例として、マネージドサービスである、 Amazon GuardDuty ではマネージド型の脅威検知の仕組みを提供しており、お客様の AWS アカウント環境を保護するために役立つ機能を提供しております。AWS のセキュリティ、アイデンティティ、コンプライアンス関連のマネージドサービスは こちら よりご確認ください。また、これから AWS アカウントを取得される方向けに 最初にやるべき AWS セキュリティ設定 10 のこと のオンデマンドセミナーも開催しております。 その他にも、有償のコンサルティングサービスである、 AWS Professional Services ではガイドラインへの対応に向けた支援メニューも提供しています。ぜひ、クラウド導入に関する相談については、 お問合せ窓口 よりお気軽にお問合せいただければと思います。 医療機関等とクラウドを結ぶハイブリッド構成 ここからは、厚生労働省のガイドラインで触れられている医療機関等と外部の接続について整理し、お客様のクラウドにおけるセキュリティを高めていただくため、専用線的接続や VPN を利用し医療機関等と医療情報システムを結ぶハイブリッド構成について紹介します。 ガイドラインの 6.0 版では システム運用編 [Control] の「13. ネットワークに関する安全管理措置」にて、医療機関等を外部と接続する際の遵守事項と考え方が整理されています。特に考え方の部分では、接続先が限定された「セキュアなネットワーク」と、接続先や接続先への経路が管理されていない「オープンなネットワーク」について紹介されており、遵守事項の②では、原則としてセキュアなネットワークを利用することが述べられています。一方で、「13 . 1 . 2 選択すべきネットワークのセキュリティ」では、専用線や IP-VPN による接続は高コストであるために多目的な利用にはなじみにくい状況に触れ、IPsec 等の技術を用いてインンターネット VPN を利用し、オープンなネットワーク経由でセキュアなネットワークへ接続するパターンについても触れられています。 AWS では Amazon VPC (Virtual Private Cloud) を利用し、論理的に隔離されたお客さまの仮想ネットワークを構築可能です。VPC 内には仮想サーバーである Amazon EC2 インスタンス等の各種リソースを起動できます。VPC はガイドライン内で示されるセキュアなネットワークに該当します。デフォルトでは閉じたネットワーク空間ですが、 インターネットゲートウェイの関連付け を設定することで、インターネットとの接続も可能です *1。 それでは、医療機関等とクラウドを接続した構成 (ハイブリッド構成)を、 AWS Direct Connect を利用したセキュアなネットワーク上で接続する方法と、 AWS Site-to-Site VPN により IPsec VPN を利用してオープンなネットワーク上で実現する方法について紹介します。 *1 NAT ゲートウェイ を利用することで、VPC内へのインバウンドの通信を拒否しつつ、アウトバウンドの通信のみを許可することも可能です。IPv6 の場合は Egress-Only インターネットゲートウェイ を利用することで制御可能です。利用例としては OS やミドウルウェアのアップデートに外部への接続が必要なケースなどがあります。 a. セキュアなネットワークを用いた接続 セキュアなネットワークを利用した接続のユースケースとしては、クラウド型電子カルテなどのミッションクリティカルな医療情報システムが考えられます。セキュリティ観点では、患者のゲノム情報などを扱うケースも特に機密性の高い情報を扱う場合も一例として考えられます。また、データ量の観点では PACS (医用画像管理システム)のような高解像度の医用画像の転送等により大容量の通信が想定されます。 AWS Direct Connect は、クラウドとオンプレミスや拠点を専用線的接続するためのサービスです。プライベートなネットワーク接続を提供し、大量のデータの転送やリソースの共有を効率的に行います。AWS は世界中の多くの地域に Direct Connect ロケーション と呼ばれる接続拠点を有しており、日本国内では 2023 年 5 月に追加された印西データセンター を含め 4 箇所(記事執筆時点: 2023 年 8 月 22 日) の Diect Connect ロケーションが利用可能です。回線は専用接続を利用する場合、1 Gbps、10 Gbps、100 Gbpsの速度が選択できます。ホスト型接続の場合は、50 Mbps、100 Mbps、200 Mbps、300 Mbps、400 Mbps、500 Mbps、1 Gbps、2 Gbps、5 Gbps、10 Gbpsの速度が選択できます。また、オンプレミスや拠点等のお客様環境から Direct Connect ロケーションまでの接続について、 AWS Direct Connect デリバリーパートナー の支援が利用できます。その他の検討ポイントとして Direct Connect の料金 は、ポート使用料と物理回線費用が必要となりますが、アウトバウンド料金が通常のインターネット向けと比べてデータ量あたりの費用が低い（インバウンドの料金はどちらも無料です）ため、この点を考慮するのが良いでしょう。AWS Direct Connectに関する解説は、 [AWS BlackBelt Online Seminar] AWS Direct Connect (動画は こちら )から確認できます。 大学・研究機関において、国立情報学研究所 (NII) が構築、運用している学術情報ネットワーク (SINET:Science Information NETwork) を利用されている場合は、SINET 経由で AWS を利用する SINET クラウド接続サービス も選択肢として考えられます。 【大学・研究機関向け】学術情報ネットワークSINET経由でのAWS利用の基本情報とアップデート のウェビナーを開催しておりますのでぜひご確認ください。 b. オープンなネットワーク上で IPsec VPN を用いたセキュアな接続 オープンなネットワーク上で IPsec VPN を利用したセキュアな接続のユースケースとしては、医療情報の 2 次利用基盤としてクラウドを活用するケースなどが想定されます。スモールスタートでクラウドのスケール可能な計算リソースを活用する場合にも適していると考えられます。その他にも、Direct Connect のバックアップ回線を安価に用意する方法としても選択できます。 AWS Site-to-Site VPN は、AWS のマネージド VPN サービスの 1 つであり、クラウドとオンプレミスのネットワークを IPsec を用いて安全かつ暗号化された接続で結ぶためのサービスです。インターネット回線とIPsec 対応ルーター、固定 Public IP があれば、容易に環境構築ができスモールスタートで始められる点がメリットです ( プライベート証明書 による認証の場合、非固定 Public IP にも対応可能)。Site-to-Site VPN であれば、オンプレミスのネットワークと VPC 間でのセキュアな通信を確立し、プライベート IP アドレス同士で通信することも可能です。医療機関等のオンプレミス側でセットアップする必要のあるカスタマーゲートウェイデバイスの要件は ドキュメント から参照できます。AWS Site-to-Site VPN に関する解説は、 [AWS BlackBelt Online Seminar] AWS Site-to-Site VPN (動画は こちら )から確認できます。 c. 発展的なネットワーク構成 医療機関等におけるクラウドの活用が進むにつれて、いくつかの課題が出てくることも想定されます。 例として、本ブログでは 2 つケースを取り上げ、それらを解決する発展的なアーキテクチャを紹介します。 ケース 1 ）クラウドで稼働する医療情報システムの増加 クラウドで運用される医療情報システムが増えることに伴い各システムへの個々の VPN 接続を行う場合、接続数が増え VPN ルータの管理運用の負荷が高まることが想定されます。これらはクラウドに限らず、従来より医療機関と外部システムを繋ぐ際にルータの管理をされていた担当者の方は経験のある話かと思います。 ケース 2）マルチテナントの医療情報システムにおける、接続先の医療機関の増加 マルチテナント SaaS 型サービス事業者の視点からネットワークを考えると、複数の医療機関と VPN 接続が必要となるため、 セキュリティ観点の課題や IP アドレス範囲の重複の課題が考えられます。 ケース 1 に対しては、 AWS Transit Gateway を利用した複数 VPC への接続が、ケース 2 に対しては AWS PrivateLink を利用した閉域 SaaS アーキテクチャが役立ちます。 ケース 1 のように、医療機関等をクラウドで稼働する複数の医療情報システムに接続する場合は AWS Transit Gateway が利用できます。ルーティングは Transit Gateway のルートテーブルおよび、各 VPC に紐づくルートテーブルで制御が可能です。さらに、 AWS Network Firewall を利用することでオンプレミスとクラウド間の通信のセキュリティを高めることも可能です。 AWS Network Firewallのデプロイモデル のブログでは Transit Gateway と Network Firewall を組み合わせ、インターネットからの入口を集約しトラフィックを検査する構成なども紹介しています。 AWS PrivateLink を利用すると、インターネットを経由させることなく VPC と AWS のリソース間の通信が可能です。ケース 2 において SaaS 事業者の VPC 内にある NLB (Network Load Balancer) に対して VPC エンドポイントを用意することで、セキュアにアクセスすることが可能です。また、直接 VPC 間をピアリング接続しているわけではないため、IP アドレスが重複していたとしても問題なく動作します。エンドポイントの名前解決には Route53 Resolver の Inbound Endpoint が利用できます。 また、SaaS 型で医療情報システムを提供されている事業者は、 AWS PrivateLink Ready パートナー に認定に認定されると、AWS と共同で製品のマーケティングを推進することもできますので、こちらもぜひご検討ください。詳細は AWS PrivateLink を利用した SaaS アプリケーションへのセキュアな接続 のブログから確認できます。 まとめ 本ブログでは、はじめに AWS の責任共有モデルに触れ、どのように医療機関等のお客様が運用の負担を軽減できるかについて紹介しました。また、医療機関等とクラウドをセキュアに接続する方法として専用線的接続や VPN を利用したネットワーク構成について解説しました。ネットワーク編 Part 2 では医療機関等のクライアント端末やサーバーからオープンなネットワークを利用した接続について解説を行う予定です。本稿が、医療情報システムをクラウド上に構築する医療機関等および医療情報を取り扱う情報システム・サービス提供事業者のみなさまの参考になれば幸いです。今後もお客様をサポートし、課題解決に寄与できればと考えております。 本記事では 2023 年 8 月時点での AWS 環境上で医療情報ガイドラインに対応するための考え方や関連する AWS の情報を概説しました。最新状況は、ぜひ AWS コンプライアンス「 日本の医療情報ガイドライン 」のページをご確認ください。 著者について 片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。 &nbsp; &nbsp; 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。

現代のダイナミックな市場におけるサプライチェーンの管理には多くの課題があります。なぜなら、企業は急速に変化する消費者需要、技術の進歩、経済の不安定性、競争の激化に対処しなければならないからです。 これらの要因は需要と供給のバランスを崩し、業務の複雑さを増します。 供給計画、つまり顧客の需要を満たすために必要な製品（または原材料や部品）の数量を見積もるプロセスは、サプライチェーンの最も重要な分野の1つです。 従来、供給計画担当者は、需要予測とサプライヤーのリードタイムデータを元に平均値や固定値を使用してこれらの計算を行っていました。 その後、計画担当者は余剰在庫の割合を加算して安全在庫を確保します。 このアプローチでは、リードタイムの変動や物流の遅延が考慮から外され、一定の誤差が生じるため、過剰在庫や在庫不足が発生します。 マッキンゼー・アンド・カンパニーによると、 2022年小売業者は在庫不足を緩和するために在庫を過剰に購入し続けたため 、余剰在庫は 12% 増加して 740 億ドルになりました。こうした状況に対し機械学習（ ML ）を活用した供給計画プロセスを採用することで、変化する状況や傾向に合わせてダイナミックな対応を行うデータドリブンで予測的な供給計画モデルを使用できます。 ガートナーは、 2026年までに商用サプライチェーンソリューションの 75% 以上が、高度な分析 ( AA )、人工知能 ( AI )、データサイエンスまたは機械学習 ( ML ) ベースの機能を標準プロセスに組み込むと予測しています。 このブログ記事では、クラウドベースのアプリケーションである AWS Supply Chain が ML ベースのリードタイム変動検出を使用して計画の精度を向上させる方法について説明します。 これにより、企業は顧客満足度を犠牲にすることなく、より優れたコスト管理戦略を実現できます。 従来型と ML ベースの2 つの供給計画アプローチを使用する場合の違いと、ML 機能によって精度がどのように向上するかについて学びます。 ML ベースのリードタイム計算と従来の方法との比較 2つの供給計画手法の違いを理解するために、一般的な消費財企業のシナリオを元に作成した以下の数値例を考えてみましょう。 下記のグラフは、従来の供給計画手法と ML ベースの供給計画方法を使用した在庫計画を示しています。 黒い線は毎月の需要を表しており、これは受注数量によるものです。 オレンジ色の線は、固定リードタイムまたは平均リードタイムを使用して従来の方法で計算された在庫レベルを表しています。 需要ラインと在庫ラインの両方が前月比で変動します。 季節的な需要によって大きな変動が生じる可能性があるため、需要ラインの変動が予想されます。 オレンジ色の線の変動は、ある月では在庫過多を引き起こし、他の月では在庫不足を引き起こすことを表しています。 固定的なデータのみ利用して計画するとこの種の変動の一因となるため、供給計画担当者は、需要を逃さないように必要な在庫を過大に見積もりして供給計画を手動で調整します。 このアプローチは有効ですが、その結果として、計画担当者がモデルの調整に費やす時間が長くなったり、余剰在庫によりコストが増加したりします。 青い線は、ML ベースの方法で計算された月次在庫レベルを表します。 この方法では、過去と現在の取引（未処理注文や出荷など）の両方を使用して、10パーセンタイル（ P10 ）、50パーセンタイル（ P50 ）、90パーセンタイル（ P90 ）に基づいて確率的リードタイム予測を決定します。 ML アルゴリズムは、曜日 (配送タイムライン用)、出荷数量 (履歴量)、輸送レーン定義 (出荷元、出荷先、インコタームズ（貿易取引条件）などの特性を含む) などの主要な製品機能を使用して予測モデルを作成およびトレーニングします。 これらの特徴量は、注文リードタイムや予測に影響するデータポイントですが、平均値を用いるリードタイムの見積もり方法では無視されています。 ML アルゴリズムは、これらの変数の変化を学習に組み込んで調整するため、確率的なリードタイム予測が計算されます。 P50 は納期の推定値を示しますが、P10 と P90 は製品の配送シナリオの最良シナリオと最悪のシナリオを評価するのに役立ちます。 上のグラフでは、P50 を使用して供給量を計算しています。 2つの在庫レベルの計算アプローチの違いは、需要と供給のばらつきを使用して比較することもできます。 需要と供給のばらつきは、需要予測と計画在庫レベルの差であり、通常は毎月追跡されます。 以下のグラフは、前述の例の需要と供給のばらつきを計算し、各供給計画アプローチの分散値を示しています。 グラフの X 軸は、1 月から 12 月までの月を表します。 Y 軸は需要予測と計画在庫の差を表し、マイナス 15 からプラス 25 までの数値を一覧表示します。 需要と供給が完全に一致している理想的なシナリオでは、分散値は 0 になります。 これは黒い点線で示され、比較のベースラインです。 オレンジ色の線は、従来の計画方法と平均リードタイムを使用した分散値を表しています。 青い線は ML モデルを使った分散値を表します。 従来のアプローチ（オレンジ色の線）のばらつきは、プラス面とマイナス面の両方に顕著です。 正の分散値は、供給レベルが需要を上回っていることを意味し、過剰在庫の状況を示しています。 過剰在庫は過剰な運転資本を必要とし、在庫が傷みやすいものや季節限定のものである場合にはほかのリスクを招きます。 負の分散値は、供給レベルが需要よりも低いことを意味し、在庫切れの状況を示しています。 在庫切れは、顧客の喪失、収益の損失、顧客満足度の低下につながる可能性があります。 ML ベースのアプローチ（青い線）は、ばらつきが少なく、より正確な供給計画を実現します。 ML モデルは適応性もあるため、多くの情報を収集すればするほど正確になります。 AWS Supply Chain で ML ベースのリードタイム変動検出を使用する AWS Supply Chain は、ML ベースのアルゴリズムを使用してリードタイムの変動を検出するのに役立つビジネスアプリケーションです。 このアプリケーションでは、過去の処理済みトランザクションと、未出荷や未発送などの処理中のトランザクションが考慮されます。 ML アルゴリズムには、季節性、製q33品特性、ベンダーの特徴、配送先サイトなどの追加情報も組み込まれ、モデルをトレーニングします。 ユーザが運用パラメーターと条件を定義すると、アプリケーションがトランザクションを監視して、予測リードタイムと予想される配送日（信頼レベル付き）を算出します。 AWS Supply Chain は想定リードタイムとの差異を計算し、その差異がユーザー定義の許容範囲 (標準偏差) を超える場合は、リードタイムを見積もり直すことを推奨します。 この ML ガイドによるリードタイムの変動検出により、供給計画担当者は需要を満たす適切な在庫レベルを自信を持って維持できます。 ウォッチリストによるリードタイムの逸脱に関するインサイトの監視 AWS Supply Chain はお客様のサプライチェーンネットワークを監視し、注文、出荷、在庫移動などのトランザクションデータから学習します。 ユーザーは、製品、場所などの特定の監視対象のパラメーターを、追跡する過去の期間などの条件とともに定義できます。 監視する基準と対象のパラメーターを指定して、ウォッチリストを作成します。 AWS Supply Chain アプリケーションでは、 [インサイトウォッチリストを作成] を選択します。 次の画面が表示され、追跡する主要なパラメーターを入力します。 まず、製品、場所、またはこれら2つの組み合わせを選択します。 次に、リードタイム標準偏差 (リードタイム差異の許容範囲) と時間間隔を入力してリードタイムデータを追跡します。 このウォッチリストを他のユーザーと共有するには、 [ウォッチャー] ボックスに名前を追加します。 次のスクリーンショットは、指定した基準に違反している製品について警告するインサイトダッシュボード画面を示しています。 このダッシュボードは、ウォッチリストに追加したユーザーとも共有されます。 ダッシュボードには、赤いボックスで特定の製品に対する基準違反が警告表示されます。 たとえば、次のスクリーンショットのダッシュボードには、 Deluxe Styler のリードタイムが Dallas DC で逸脱していることが示されています。 次に、Deviation (偏差) ボックスを選択すると、偏差の詳細を示す次の画面が表示されます。 画面には、ユーザ設定の初期の情報に基づいて期待するリードタイムが表示され、それに対する推奨リードタイムが表示されます。推奨リードタイムは、機械学習を使用して計算され、過去の実績に基づいて行われます。 ML は、過去の実績と予想されるパフォーマンスをモデル化し、予測値、あるいは設定値の 5 日間の目標ではなく、19 日間の予想リードタイムを推奨しています。 また、このアプリケーションでは、過去の実績データに基づいて、この場所での Miss Frequently (目標逸脱の頻度) が 100% であることも報告されます。 インサイトでは、進行中の注文の期待される ( expected ) 納期を確認することもできます。 次のスクリーンショットは、未処理の発注書と、サプライヤー、製品、数量の一覧を示しています。 画面には、調整後のリードタイムに基づく受領予定日と、信頼度が低い日付と信頼度の高い日付が表示されます。 これらの日付では、過去のパフォーマンスに基づく統計的モデリングが考慮され、納品可能な日付の範囲がわかります。 これにより、実際のパフォーマンスに基づいた総合的なビューが得られるため、供給計画を調整できます。 他のチームメンバーとのコラボレーション コラボレーションはサプライチェーンにとって不可欠な機能です。 前のセクションで説明した供給計画の変更には、他のチームとの調整とコラボレーションが必要です。 従来、供給計画の調整に関する連絡は、電子メールまたは電話で行われていました。 この方法は有効ですが、解決に遅延が生じたり、会話中に同じ情報を共有していないことで問題が生じる可能性があります。 AWS Supply Chain にはコラボレーションツールが組み込まれているため、チームメンバーはアプリケーションを離れることなくチャットして問題について話し合い、解決できます。 ユーザーは同じ画面で同じ情報をチャット画面に表示できるため、コミュニケーションと解決をより迅速に行うことができます。 結論 現代の市場は活発に変動する性質を持っており、顧客はそれに対応して、供給計画戦略の進化が求められています。 静的データと平均リードタイムに依存する従来の方法では、誤差、過剰在庫、在庫不足、および不要な経費が発生する可能性があります。 供給計画に機械学習を導入すると、計画の精度が向上し、需要と供給のばらつきが減少します。 ML はサプライヤーのリードタイムの異常を検出して計画を修正し、効果的なリスク軽減措置を実施します。 異常の検知や、長期利用に対する適応もリアルタイムで行われているため、最適化された、効率的で機敏なサプライチェーンが継続的に維持されます。 サプライチェーンの可視性が継続的かつ向上することで、ボトルネックや潜在的な混乱を特定できるようになり、また、意思決定を迅速化することで、業務に影響を与えることなく潜在的な問題軽減を迅速に行うことができます。 これらの改善により、顧客の需要に効果的に対応し、市場や環境の変化に適応し、運用コストを削減できるようになるため、サプライチェーンのレジリエンスが向上します。 ML ベースのリードタイム偏差に関するインサイトを利用するには、 AWS Supply Chain &nbsp; にアクセスして詳細を確認してから始めましょう。 また、&nbsp; AWS Workshop Studio にアクセスして、ご自分のペースでインスタンスの作成、データの取り込み、ユーザーインターフェイスの操作、インサイトの作成、在庫リスクの軽減、他のユーザーとのコラボレーション、需要計画の生成についての概要をご確認ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 <!-- '"` -->

資材のインバウンドサプライチェーンの目的は、予備部品、補修可能部品、消耗品を予定されたメンテナンス作業に間に合うように工場に届けることです。 しかし、パフォーマンスの低さ、チーム間の信頼の欠如、資材調達における可視性の低さなどが原因で、頻繁に再計画が行われ、メンテナンス作業を確実に実行するために必要以上に慌ただしくなります。 主要な鉱業およびエネルギー企業は、クラウドコンピューティング技術を活用して以下のようにビジネス成果の向上とリスクの軽減を図るケースが増えています。 作業開始日より前に資材が確実に届くようにすることで、設備のダウンタイムを削減します。ビジネス機会の規模は、運用設備1件あたり年間 $3 ～ 6M と推定されています。 メンテナンス実施チームが作業の移動や資材を探す時間を減らし、より多くの時間をメンテナンス作業に費やすことで、メンテナンスの生産性が向上します。 ビジネス機会の規模は、生産性が 5 〜 8% 向上することです。 資材の状態が可視化され、ベースとなるデータへの信頼性が確保されれば、余剰在庫が少なくなります。ビジネス機会の規模としては、在庫レベルを 1 〜 5% 削減し、速達便と航空貨物の出荷を 2 〜 5% 減らすことです。 エンジニアが直接かつガイド付きで購入できるようにすることで、調達の間接コストを削減します。 これにより、調達プロセスが合理化され、調達の役割が取引からコンサルティング業務へとレベルアップします。 目下のビジネス機会は、調達支出を最大 5% 削減することです。 このブログでは、特に鉱業およびエネルギー業界向けの保守の注文を監視・管制するコントロールタワーのユースケースと、関連するビジネス成果を紹介します。 クラウド技術を活用した保守の注文を監視・管制するコントロールタワー 私たちのビジョンは、各利害関係者が資材の流れを維持するために主要なアクションを完全に可視化し、彼らの決定がビジネス総コストに与える影響を理解できるようにする保守の注文（ MO ）の監視・管制するコントロールタワーを実現することです。 特定の日に MO をスケジュールまたは再スケジュールすることが、資材の入手可能性、メンテナンスの生産性、移動、宿泊施設の利用率にどのような影響を与えるかを透明化できます。 このビジョンに向かって進むには、企業はメンテナンス計画の段階とMOの計画段階の両方でデジタル機能と機械学習 ( ML ) 機能を構築する必要があります。 メンテナンス計画の時点での考慮事項 データドリブンな機械学習を活用した需要予測とシミュレーションによる将来の需要の可視化 メンテナンス計画の時点で、チームは一般に、大まかな作業と実行日を計画してスケジュールを立てるときに、必要な資材が現場にあることが確実ではありません。 その結果、頻繁な再計画とそれに伴う移動作業の両立、資材の発送依頼、メンテナンス作業のための人員の調整、資材が確実に利用できるようにするための安全在庫レベルの設定といったやりくりが必要になります。 サプライヤーは、将来の資材需要がどうなるかを把握できていません。 将来の需要の可視化は、生産計画に役立ち、購入者との関係を改善することにもつながります。 メンテナンス作業の再計画を減らす、つまり、期日通りに実行されるメンテナンスの注文を増やす 、そしてバランスの取れた在庫管理を実現するために、大手企業はクラウドベースのテクノロジーを資材需要予測、安全在庫分析、および What-if シナリオに適用しています。 Amazon SageMaker を用いた機械学習( ML )により、以下の要素を組み合わせて資材需要計画プロセスをサポートします。 今後の活動における資材需要予測のための過去の資材消費量 エンタープライズリソースプランニング（ ERP ）ソフトウェアシステムにおける機器向けの資材の消費ベースのデータ、また機器の設置台数ベースのデータ 後者では、分析を行って機器と資材の故障率（平均故障間隔）を計算できます。 これにより、メンテナンスプランナーは、メンテナンス作業、資材需要、および過去の資材消費量の可視性を自動的に予測できます。 また、将来の MO に関連する作業リストや部品表を簡単に確認できるようになります。 AWS はパートナーの Deloitte とともにあるエネルギー企業を支援し、データ品質 (資材マスターデータや作業リスト BOM など) に制約があったにもかかわらず、全資材の 25% の需要予測をうまく自動化できました。 さらなる取り組みの強化により、データ品質の問題にデータ拡張技術で対処すれば、全資材の約 50% までカバー範囲が拡大する可能性があります。 これにより、メンテナンス計画作業の半自動化が可能になります。 さらに、資材需要予測に基づいて、安全在庫レベルは静的ではなく動的に計算されます。 この計算では、希望するサービスレベル、資材の重要度、手持ち在庫、納期、資材のリードタイムが考慮されます。 資材管理者は、積極的に在庫を管理して全体的な在庫レベルを下げることができるため、安全在庫レベルの動的な計算によるメリットがあります。 最後に、What-if シミュレーション（たとえば、開始日を1か月変更するなど）により、生産の可用性、コスト、MO のスケジュール変更に伴う安全性への影響を可視化し、さらにはメンテナンス活動全体を経時的に把握できます。 これにより、メンテナンスのスケジューラーとプランナーは、特定の日に MO をスケジュールするときに、必要な資材のオンサイト在庫状況への影響をすばやく確認できます。 さらに大きく考えてみましょう。 このビューは資材だけに限定されるべきではありません。 人件費、移動、宿泊施設の利用状況、そして最も重要なことですが、保守対象の設備の稼働時間に関する潜在的なリスクなどの関連情報を使用して、ビジネス全体でのコストを検討しましょう。 ビジネスの全体像を把握するために、企業は強固な基盤となるデータプラットフォームと、 Amazon S3 を搭載した Lake House Architecture などの構造を通じて提供される強固なデータ構造が必要です。これにより、関連する財務、運用、資材の情報をすべて保存して迅速に取得できます。 資材入手と計画精度向上のための、現実的なベンダーリードタイムと輸送リードタイム 資材が現場に到着するまでにかかる時間についての情報が不十分なため、メンテナンスプランナーは MO の開始日を自信を持ってスケジュールできないことがよくあります。 直接購入の場合、ベンダーのリードタイムはエンドツーエンドのリードタイム全体の 60% 以上を占めることがよくあります。 また、アウトライン契約（他の業界のフレーム契約と同様）が締結されていなかったり、最近更新されていなかったりすると、メンテナンスプランナーは信頼できる情報を得ることができません。 SageMaker を用いた機械学習( ML )は、過去の PO ( Purchase Order ) 情報を分析して実際のベンダーリードタイムを予測します。 設備や機器の標準化があまり行われていないため、資材購入は一回限りのものであることが多く、過去のデータが不十分な場合は常に、同様の資材を使用して、 XGBoost などの監視付き ML アルゴリズムを資材レベルまたは資材グループおよびベンダーレベルで実行する必要があります。 これらのモデルでは、決定係数が 0.7 を超えると強い相関関係であることが証明されています。 重要な課題は、モデルが予測する信頼水準 ( 95% の確率水準など) を定義することです。 実際には、これは予測到着日が、必要なオンサイト日付より大幅に前にならないように予測アルゴリズムがトレーニングされていることを意味し、その結果、大量のバッファーが使用され、MO 計画が非現実的になります。 これとは対照的に、モデルで予測されるリードタイムが短すぎると、メンテナンスプランナーは信頼を失い、MO のタイムリーな実行がリスクにさらされます。 以下のグラフは、予定納期、ベンダー名、インコタームズ（貿易取引条件）、PO 作成月など、ベンダーのリードタイム予測に影響する要因の例を示しています。 このチャートは、特定のベンダーに関する高水準または低水準の予測因子、つまりどの要因が資材の到着を遅らせる可能性があるかをユーザーに提供します。 さらに、過去のベンダーの実績と契約上の義務を比較することで、ユーザーはそれに応じてベンダーの実績を管理しやすくなります。 インコタームズ(貿易取引条件)が買い手に輸送の手配を要求する場合（工場出荷時など）には、輸送、特に国際海上貨物輸送のリードタイムを予測する2番目の ML モデルを構築する必要があります。 船舶到着時刻の予測に機械学習を使用すると 、業界で広く使用されている従来の手動見積もり方法と比較して、陸上業務の計画と実施の精度が大幅に向上します。 メンテナンスの注文が計画されている場合 購入した資材の可視性 鉱業・エネルギー企業が資材のサプライチェーンを運営する際の共通の課題は、メンテナンスの利害関係者が注文承認から現場での入手までの進捗状況に関して、資材の可視性が限られていることです。 これは特にベンダーからの直接購入に当てはまり、在庫からの供給にもある程度は当てはまります。 調達チームとロジスティクスチームは、どの資材がクリティカルパスにあるのか、あるいはすでに遅延しているのかを把握することがほとんどできません。 また、どの作業を優先すべきかについてのガイダンスも不足しています。 このような可視性の欠如は、重要な資材が必要なときに現場にない場合や、予定日に間に合うように届くかどうか確信が持てない場合に、メンテナンス作業をリスクにさらします。 資材のコントロールタワーは、必要な資材がプロセス全体にわたってどのように進んでいるかを可視化します。 MO の承認からオンサイトでの納品まで、進捗状況を追跡するための一連のマイルストーンが定義されています。 この可視性により、メンテナンスの実行、調達、物流などのユーザーは、計画された実行日より前に資材が届くという貴重な洞察と確信を得ることができます。 さらに、可視性は、資材の流れと資材サプライチェーンにおける信頼を確保するために必要なアクションの優先順位付けと調整に役立ちます。 たとえば、調達チームは月に何千件もの購買依頼を処理しているのに、どの資材要求や関連アクションが最も重要か、どの資材が重要なのか、どの資材が重要なのか、どの資材が重要なのか、あるいはすでに遅延しているのかを理解していないことがよくあります。 優先順位付けエンジンは、ユーザーにいくつかの重要な作業を指示し、資材や注文の重要度、アクションやエスカレーションなどのサプライチェーンのさまざまな参加者が制御できるコンテキスト情報を提供します。 資材調達の進行が妨げられたり、状況の可視性が悪かったりすると、要求の所有者にとって資材の状況や解決の責任者が不明瞭になることがあります。 たとえば、ベンダーが品目を製造・納品できなくなった場合、資材が旧型のものになる可能性があります。 こうした障害は、発注と配送のプロセスの複数の段階で発生し、例えば PR ( Purchase Requisition )時や見積依頼（ RFQ ）の作成時に検知しうるものです。ソリューションが提供する推奨事項は、これに基づいて非常に状況に応じたものでなければなりません。 資材のコントロールタワーは、こうした障害を検知するコグニティブ機能を備えているだけでなく、類似のサプライヤーを見つけたり、クラスタリング技術を使って代替可能な資材を特定したりするなど、重要な推奨事項を提示するコグニティブ機能を備えています。 資材のコントロールタワーは資材の流れに焦点を当てており、計画と実行の両方のプロセスにまたがる MO 実行を監視・管制するコントロールタワーという私たちのビジョンの重要な構成要素です。 MO 実行を監視・管制するコントロールタワーには、資材だけでなく、メンテナンス実行チームや、メンテナンス作業の実行に必要なその他の活動（航空機やキャンプの運用など）も含まれています。 業界をリードする AWS のお客様の中には、AWS のサービスである AWS Supply Chain を活用して、次の 4 つのコア機能に沿った資材の追跡と推奨事項の提供を検討しているところもあります。 システムをまたぐデータの容易な接続 : 関連するメンテナンス計画、調達、ロジスティクスのデータはサイロ化していることが多く、関連するチームやユーザーは、エンドツーエンドのサプライチェーン全体にわたる資材の状態に関する使いやすいビューを作成するのに苦労しています。 AWS Supply Chain は、このようなサイロ化されたデータへのアクセスを支援し、事前にトレーニングされた自然言語処理 ( NLP ) モデルである ML アルゴリズムを使用して、既存のデータをターゲットデータモデルに変換します。 ML を活用した洞察 : 次に、AWS Supply Chain はデータを地図上に関連付けて表示し、各倉庫とサイトにおける資材の進捗状況、現在の在庫選択と数量、在庫の状態を強調表示します。 ML を使用した資材到着時間の予測 : この ML モデルは、残りのすべてのマイルストーンにリードタイムを追加し、障害解決時間を考慮して現場での現実的な到着日を見積もることで拡張できます。 在庫についての推奨事項提供とコラボレーションの支援機能 : ユーザーは、推奨アクションや緊急の在庫問題に関するインサイトを自動的に得ることができます。 監視リストを設定して、潜在的なサプライチェーンのリスクがある場合にアラートを受け取ることができます。 また、コラボレーション機能も備えているため、ユーザーは互いに通信したり、システム内の関連情報を追跡したりできます。 コグニティブ調達により、ビジネスユーザーに迅速でデータドリブンで Amazon ライクな購入体験を提供 資材サプライチェーンの最適化において調達が重要な役割を果たす理由は2つあります。 第一に、鉱業会社やエネルギー会社の調達支出は数十億ドルに上る傾向があり、支出削減は会社の収益に直接つながります。 第二に、PR からベンダー側での PO 承認までの平均時間は、数週間ではないにしても、数日かかることがよくあります。 これは特に、時間のかかる承認プロセスが原因で、購入履歴の処理時間のばらつきが限られている品目に当てはまります。そのため、調達プロセスにかかる時間を自信を持って把握することが複雑になります。 調達変革の中核には、保守エンジニアなどのビジネスユーザーがベンダーから直接品目を購入できるようにすることで、調達チームを取引的で事後対応型の役割からコンサルティング型の役割に変えたいという強い要望があります。 こうした要望により コグニティブ調達エンジン ( COPE ) というオファリングが支持されており、COPE は次のような機能を提供しています。 設定された上限金額を下回る補修部品発注のセルフサービスを提供します。 資材の Amazon のような購入体験により、適切な製品をより迅速、簡単、効率的に調達するためのエンドツーエンドのプロセスを実現します。 製品、価格、サプライヤー、過去の支出、個人ユーザーエクスペリエンスに関する比較分析用のデータ。これにより、パンチアウト（企業購買システム内でのベンダー提供カタログによる購買)が強化され、補完されます。 推奨事項、購入パターン、代替製品、および機器のタイプ、役割、購入履歴に基づいた焦点を絞ったオプションセットにより、ビジネスユーザーのニーズにより的確に対応できます。 購買支出の完全な可視化による調達チームの継続的な管理と、必要に応じて例外発生時のエスカレーションプロセスを設ける。 あるエンジニアが COPE Web ポータルにログインすると、入力された検索語に対する製品の選択肢がいくつか表示されます。 購入画面には、商品がフィットする理由とそうでない理由が表示されます。 O リングの例では、アイテム1と2は使用目的に非常に適しています。 それでも購入者がアイテム3が適していると見なす場合は、最も安いこの製品を選択できます。 こうした場合でも、適切なプロセスに適した機器を用意することで、安全性と設備寿命が向上し、メンテナンスコストが削減されます。 COPE による Amazon のような購買体験は、今日の購買慣行を一新し、時間とリソースを消費する調達プロセスの大部分を自動化し、調達支出を 5〜8% 削減する機会を提供します。 特にガスケットなどの価値の低い品目の場合、組織は PR から納品までの時間を短縮し、ロングテール品目の調達にかかる人件費を、1取引あたり $200 —300 から $5 —25 に削減できます。 一括注文と調達プロセスの改善のための Amazon Business Chevron や Exxon Mobile などのいくつかの企業は、 Amazon Business を活用しさらに一歩進んでいます。 Amazon Business は、Amazon のユーザーフレンドリーなショッピング体験をベースに、マルチユーザービジネスアカウントにより、特定の権限を持つ購買グループの作成、ガイド付き購入、高度な検索機能といった強力な支出の可視化と分析を可能にする現代の調達に不可欠な機能と組み合わせて活用しています。 たとえば、Chevron は幅広い資材を調達しており、その多くは Chevron に代わってビジネスパートナーが管理していました。 マネージャーは月次の出荷日に向けて購買リストを作成していました。 リストの作成、見積もりの取得、見積もりの承認、注文、配送の受け付けには4〜6週間かかります。 メンテナンスチームなどの社内顧客は、必要なものを正確に手に入れるためのコントロールが限られていたため、多くの拠点が失望していました。 Chevron は、購買を Amazon Business に移行しました。これは、支出を集約し、ダイナミックな店舗環境で誰もが必要な商品を見つけることができ、なおかつ大量注文のメリットを享受できます。 Amazon Business は Chevron の SMART GEP システムである Punchout と統合され、シームレスなユーザーエクスペリエンスを実現しました。 各ユーザーが個別に実施した注文は、経費マスターの報告用に自動的に1つの購入カードにまとめられ、注文は週1回の配送（ Amazon Day ）にまとめられます。 資材カテゴリーが過去の取引に合わせて細分化されていたなど課題もあったものの、柔軟な支払い条件で発注するなどして、サプライヤーを集約しました。 結論 このブログでは、鉱業およびエネルギー企業がクラウドコンピューティング技術を使用して資材サプライチェーンを最適化するビジネス機会について説明しました。 ビジネス機会は、メンテナンス計画プロセス中と資材需要が確認されたときの両方に存在します。 メンテナンス計画と実行の安定性が向上すると、メンテナンス実施チームの生産性が 5～ 8% 向上し、費用のかかる速達便や航空貨物の輸送が 2 ～ 5% 削減され、設備ダウンタイムのリスクが軽減され、運用設備あたり年間 $3 ～ 6M になる可能性があります。 AWS では、エンドツーエンドのサプライチェーン全体で資材の状態を可視化し、必要な期日より前に資材が現場に届くという確度を高め、間接調達支出を最大 5% 削減し、サプライチェーンのパフォーマンスとコミットメントに対する信頼を高めるのに役立つサービスをいくつか提供しています。 資材サプライチェーン管理に関するあなたのアプローチを学び、議論したいと思っているので、コメントにあなたの意見を残してください。 複雑なサプライチェーンの課題解決に AWS がどのように役立つかを知りたい場合は、担当の AWS アカウントマネージャーに連絡して、鉱業、エネルギー、工業 ( MEI ) 業務の業界専門家や、サプライチェーンや物流の専門家によるディスカバリーワークショップを開催してください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Manuel Baeuml 博士は、アジア太平洋地域と日本の AWS ProServe サプライチェーンとロジスティクスの責任者です。Manuel と彼のチームは、主要なデジタルサプライチェーンの実践を共有し、AWS のクラウドテクノロジーとサービスを活用してお客様の喫緊のサプライチェーンの問題を解決する役割を持っています。過去 15 年間、彼は鉱業、エネルギー、小売/CPG、輸送、物流の分野で、アジア太平洋地域と ヨーロッパの業界リーダーと仕事をする機会に恵まれてきました。Manuel はシンガポールを拠点としています。 Ben van Vlietは、オーストラリアとニュージーランドの鉱業、エネルギー、産業分野の顧客を担当するシニア・カスタマー・デリバリー・アーキテクトです。Ben の仕事は、AWS ProServe のお客様がデジタル戦略と運用戦略を定義できるよう支援することから、サプライチェーン、産業用 IoT、グリーンフィールド製品開発における戦略的イニシアチブの策定と実施まで多岐にわたります。Ben は鉱業、 石油、ガスの分野で深い経歴を持ち、アウトバウンドのサプライチェーンの計画、メンテナンスの有効性、デジタルイノベーションの分野で実務担当やリーダーの役割を果たしてきました。Ben はオーストラリアのパースを拠点としています。 Brett Birkbeckは、オーストラリアとニュージーランドの鉱業、エネルギー、産業向けのソリューションアーキテクチャの責任者です。Brett は、お客様が AWS クラウドによる変革を実現できるよう支援する AWS プロフェッショナルチームを率いています。Brett は鉱業とエネルギーの分野で豊富な経験を持ち、デジタル戦略、テクノロジー主導の近代化、インダストリアル IoT、AI/ML、デジタルツインに関するアドバイスを提供しています。ブレットはオーストラリアのパースを拠点としています。 <!-- '"` -->

このブログは 2023 年 2 月 8 日に Luca Mezzalira (Principal Solutions Architect)、Federica Ciuffo (Sr. Containers Solutions Architect)、Laura Hyatt (Solutions Architect)、Vittorio Denti (Machine Learning Engineer)、Zamira Jaupaj (Enterprise Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 持続可能性 は、テクノロジー業界だけでなく社会全体にとっても重要なトピックであり、天然資源や環境を枯渇させることなく、長期間にわたってプロセスや機能を果たし続ける能力と定義されています。 持続可能なワークロードを設計するための重要な要素の 1 つは、ソフトウェアアーキテクチャです。イベント駆動型アーキテクチャがバッチ処理やキューなどのソリューションを活用して複数のマイクロサービスの負荷を軽減するのにどのように役立つかを考えてみてください。このような場合、多くのネットワークトラフィックはクラウドワークロードの入り口で処理され、システム内部への負荷の緩和に役立ちます。アーキテクチャに加えてデータパターン、ハードウェア最適化、マルチ環境戦略など、クラウドにおける持続可能な姿勢を促進するソフトウェア開発ライフサイクルの多くの側面について考えてみましょう。 重要なポイントは、持続可能性を念頭に置いて設計することで、耐久性があるだけでなく、ビジネスに必要な俊敏性を維持できる柔軟性を備えたアプリケーションを構築できるということです。 今回の投稿では、クラウドアプリケーションをより持続可能にするためのハンズオンアクティビティ、ケーススタディ、ヒントやコツを紹介します。 持続可能な設計と AWS の二酸化炭素排出量の削減 アマゾンウェブサービス (AWS) は、組織による AWS サービスの利用の評価と最適化を支援するために AWS Well-Architected Framework の 持続可能性の柱 を立ち上げ、組織が AWS フットプリントを監視、分析、削減できるように Customer Carbon Footprint Tool を構築しました。 このセッションでは、これらのプログラムの最新情報を提供し、AWS アーキテクチャを最適化するための最も効果的な手法に焦点を当てます。Amazon Prime Video がこれらのツールをどのように使用してベースラインを確立し、AWS 利用全体の効率を大幅に向上させたかをご覧ください。 この re:Invent 2022 の動画はこちら! 持続可能性を考慮してアーキテクチャを設計する方法を理解するための Prime Video のケーススタディ 持続可能性を実現するために最新のデータアーキテクチャを最適化 モダンなデータアーキテクチャは、ビジネスインテリジェンスを可能にする持続可能でスケーラブルなプラットフォームの基盤です。この AWS Architecture Blog シリーズでは、持続可能性を念頭に置いてモダンなデータアーキテクチャを開発する方法についてのヒントを紹介しています。 2 つの記事で構成されていて持続可能性を損なうことなく、現在のデータアーキテクチャを再検討して強化するのに役立ちます。 Part 1 はこちら! | Part 2 はこちら! AWS データ・アーキテクチャ：持続可能性を考慮する時です AWS Well-Architected Labs: Sustainability このワークショップでは、AWS Well-Architected Framework を参加者に紹介します。AWS Well-Architected Framework は、パフォーマンス、拡張性、コスト効率のよいアプリケーションを AWS 上で設計および運用するための一連のベストプラクティスです。ワークショップでは、ソフトウェアアーキテクチャにとって持続可能性がいかに重要であるか、また AWS Well-Architected Framework を使用してアプリケーションの持続可能性パフォーマンスを向上させる方法についても説明します。 ワークショップはこちら! 持続可能性導入のベストプラクティスとモニタリング Rust と AWS Graviton によるクラウド内の持続可能性 この動画では、 Rust と AWS Graviton がエネルギー消費量の削減とパフォーマンスの向上にもたらすメリットについて学ぶことができます。Rust は C などのプログラミング言語のリソース効率と Java などの言語のメモリ安全性を兼ね備えています。また、この動画では、パフォーマンスとコストが最適化されたクラウドワークロードを提供するように設計された AWS Graviton プロセッサから得られる利点についても説明しています。このリソースは、持続可能性がどのようにコスト最適化の原動力になり得るのかを理解するのに非常に役立ちます。 re:Invent 2022 動画はこちら！ Rust と AWS Graviton がワークロードの持続可能性とパフォーマンスを向上させるのにどのように役立つかをご覧ください また次回お会いしましょう！ クラウド内の持続可能性についてのディスカッションにご参加いただきありがとうございます。2 週間後にアーキテクト向けのツールについてお話ししますので、またお会いしましょう。 このシリーズのすべてのブログを検索するには、AWS Architecture Blog の Let’s Architect! のコンテンツのリストをチェックしてください。 翻訳はネットアップ合同会社の Yotaro,Iwai 氏、監修はソリューションアーキテクトの沢田 吉伯が担当しました。 TAGS: case study , data architecture , Let’s Architect , re:Invent , software , Sustainability , workshop Luca Mezzalira Luca Mezzalira はロンドンを拠点とするプリンシパル・ソリューション・アーキテクトです。複数の著書を持ち、国際的な講演者でもある彼は、主にソリューション・アーキテクトの分野で専門知識を発揮しています。ルカは、マイクロフロントエンドを使ったフロントエンドアーキテクチャのスケーラビリティに革命をもたらし、ワークフローの効率化から製品の品質向上に至るまで高い評価を得ています。 Federica Ciuffo Federica Ciuffo は、AWS のシニア コンテナ ソリューション アーキテクトです。彼女はネットワークとコンテナに情熱を持っています。オフィスの外では、読書や絵を描いたり、友人たちと時間を過ごしたり、レストランでさまざまな料理の新しい料理を試したりすることを楽しんでいます。 Laura Hyatt Laura Hyatt は、AWS 公共部門のソリューションアーキテクトであり、英国の教育機関の顧客を支援しています。 Laura は、お客様がスケーラブルなソリューションを設計および開発するだけでなく、現在教育セクターが直面している問題に対して、革新的なソリューションを考える一役を担っています。 Laura の専門は IoT で、EMEA 全体の教育向け Alexa SME も務めています。 Vittorio Denti Vittorio Denti は、ロンドンを拠点とする Amazon の機械学習エンジニアです。ミラノ工科大学 (ミラノ) と KTH 王立工科大学 (ストックホルム) でコンピューターサイエンスとエンジニアリングの修士号を取得後、AWS に入社しました。 Vittorio は分散システムと機械学習のバックグラウンドを持っています。彼は特にソフトウェア エンジニアリングと機械学習科学の最新のイノベーションに情熱を注いでいます。 Zamira Jaupaj Zamira Jaupaj は、オランダを拠点とするエンタープライズ ソリューション アーキテクトです。彼女は非常に情熱的な IT プロフェッショナルであり、中小企業向けのコンテナ、サーバーレス、データ分析を使用した重要で複雑なソリューションの設計と実装において様々な国で 10 年以上の経験を持っています。

この記事は Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate (記事公開日 : 2023 年 8 月 9 日) の翻訳です。 導入 Amazon Elastic Container Service ( Amazon ECS ) タスクは、同時かつ同一の AWS Fargate インスタンス または Amazon EC2 コンテナインスタンス にスケジューリングされる、1 つ以上のコンテナで構成されます。コンテナでは Linux namespace を使用してワークロードの分離を実現するため、Amazon ECS タスク内で複数のコンテナが一緒にスケジューリングされた場合にも、コンテナ同士、あるいはコンテナとホスト間は分離されます。 本日より、AWS Fargate 上の ECS タスクで Linux カーネルパラメータを調整できるようになりました。Linux カーネルパラメータを調整することで、コンテナ化されたネットワークプロキシの ネットワークスループットを最適化 したり、不要な接続を適切に終了するように TCP キープアライブパラメータを調整 し、ワークロードの信頼性を向上させることが可能になります。今回の発表により、AWS Fargate を使用する際にも、Amazon EC2 を使用する場合とより近い形で ECS タスクを実行できるようになりました。 さらに、本日より AWS Fargate 上の ECS タスク内のすべてのコンテナ間で、プロセス ID (PID) namespace を共有できるようになりました。ECS タスク内のコンテナ間で PID namespace を共有することで、AWS Fargate ワークロードの可観測性を実現する手段が広がります。例えば、コンテナランタイムセキュリティツールなどの可観測性ツールをサイドカーコンテナとして実行し、同じ ECS タスク内のコンテナのプロセスを監視することが容易になります。 awsvpc ネットワークモード を使用した場合の Network namespace に加えて、PID namespace も、AWS Fargate 上の ECS タスク内のコンテナ間で共有可能な namespace の一員となりました。 この記事では、AWS Fargate の System Controls と PID namespace の共有について深堀りしていきます。 System controls Linux システムでは、コマンドラインユーティリティ sysctl でカーネルパラメータを調整できます。 Docker や finch などのコマンドラインインターフェースを使用してコンテナをローカルで起動する場合、 --sysctl フラグを指定することでカーネルパラメータを変更できます。ECS タスクの場合、 タスク定義 の systemControl キーでパラメータを定義できます。 コンテナ化されたネットワークプロキシを AWS Fargate 上で実行しているお客様からは、ワークロードにおいてより高いスループットを実現するために net.* カーネルパラメータを調整する必要がある、という 声 を頂いていました。特に要望が多かったカーネルパラメータには、接続要求を格納するキューの深さ net.core.somaxconn や、TCP/UDP 接続時に使用する一時的なエフェメラルポートの範囲 net.ipv4.ip_local_port_range などがあります。 信頼性の高いワークロードを設計する際に、AWS Fargate 上の ECS タスクの TCP キープアライブパラメータをカスタマイズしたい、という声も頂いていました。短い TCP キープアライブタイムアウトを設定することで、アプリケーションはネットワーク障害を迅速に検知し、失敗した接続を閉じることができます。TCP キープアライブを調整するユースケースの例としては、コンテナワークロードが Amazon Aurora PostgreSQL クラスター と通信している場合や、Amazon VPC NAT Gateway の トラブルシューティング を行う場合などが考えられます。 以前は、EC2 上で ECS タスクを実行する場合にのみ systemControl キーを設定可能でしたが、本日より AWS Fargate 上の ECS タスクにおいても、同様に設定可能となります。2 つのカーネルパラメータを調整する Amazon ECS タスク定義の例を以下に示します。 { ... "containerDefinitions": [ { "name": "myproxy", "image": "111222333444.dkr.ecr.eu-west-1.amazonaws.com/myproxy:latest", "essential": true, "systemControls": [ { "namespace": "net.core.somaxconn", "value": "6000" }, { "namespace": "net.ipv4.ip_local_port_range", "value": "1024 65000" } ] } ] } AWS Fargate / Amazon EC2 上の ECS タスクで設定可能なすべてのパラメータは、 Amazon ECS ドキュメント で確認できます。 IPC namespace のカーネルパラメータを使用する場合、IPC namespace はタスク内のコンテナ間で共有されないため、各コンテナに固有の値を設定できます。一方、Network namespace のカーネルパラメータを使用する場合、1 つのコンテナにパラメータを設定すると、タスク内のすべてのコンテナのパラメータが変更されます。具体的には、以下のように設定が適用されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を設定した場合、この変更はコンテナ 2 にも反映されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を、コンテナ 2 に net.ipv4.tcp_keepalive_time=200 を設定した場合、タスク内で最後に起動するコンテナのパラメータのみが適用されます。 PID namespace の共有 PID namespace は、コンテナ内のプロセスが参照可能なプロセスを制限します。デフォルトでは、コンテナ内のプロセスは同じコンテナ内のプロセスのみを参照でき、他のコンテナ内、または実行基盤となるホスト上のプロセスは参照できません。コンテナ間で PID namespace を共有する一般的なユースケースとして、可観測性ツールがあります。コンテナランタイムセキュリティツールは、多くの場合サイドカーコンテナで実行されます。このとき、サイドカーコンテナ内のプロセスがアプリケーションコンテナ内のプロセスを監視し、不審なシステムコールが実行されていないかどうかを確認します。 今回の発表により、タスク定義内の pidMode キーの値を task に設定することで、AWS Fargate においても ECS タスク内のコンテナ間で PID namespace を共有できるようになりました。 ウォークスルー このウォークスルーでは、まず PID namespace を共有した ECS タスクを作成します。このタスクには、アプリケーションコンテナ (nginx) とサイドカーコンテナ (デモ用の sleep プロセス) の 2 つのコンテナが含まれています。その後、サイドカーコンテナ内のプロセスが、アプリケーションコンテナ内のプロセスとどのようにやり取りできるかを確認します。 前提条件 このウォークスルーでは、Amazon VPC 内に作成した Amazon ECS クラスターを使用します。自身の AWS アカウントで新たに作成する場合は、 Amazon ECS getting started guide を参照してください。 AWS アカウントとコマンド実行環境の両方において、 ECS exec の前提条件 を満たしていることを確認してください。 AWS Fargate 上で ECS タスクを実行する 1. pidMode を有効化した、2 つのコンテナを含むタスク定義を作成します。以下の例では、タスク定義内の IAM ロール ( executionRoleArn と taskRoleArn ) を、前提条件で作成した IAM ロールに置き換えてください。 $ cat &lt;&lt;EOF &gt; taskdef.json { "family": "fargatepidsharing", "executionRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecutionRole", "taskRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecRole", "networkMode": "awsvpc", "requiresCompatibilities": [ "FARGATE" ], "containerDefinitions": [ { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:1.25-perl", "essential": true }, { "name": "sleeper", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "essential": true, "command": [ "sleep", "infinity" ], "linuxParameters": { "initProcessEnabled": true } } ], "cpu": "256", "memory": "512", "pidMode": "task" } EOF 2. aws ecs register-task-definition コマンドを実行し、タスク定義を登録します。 $ aws ecs register-task-definition \ --cli-input-json file://taskdef.json 3. aws ecs run-task コマンドを実行し、AWS Fargate 上で ECS タスクを実行します。以下の例では、ECS クラスター名、VPC サブネット、セキュリティグループの値を置き換える必要があります。外部からこのタスクにアクセスする必要はないので、プライベートサブネットと、イングレスルールを持たないセキュリティグループ (デフォルトのセキュリティグループなど) で十分です。 $ aws ecs \ run-task \ --count 1 \ --launch-type FARGATE \ --task-definition fargatepidsharing \ --cluster mycluster \ --enable-execute-command \ --network-configuration "awsvpcConfiguration={subnets=[subnet-07bd4d10ea848a008],securityGroups=[sg-061b33f4ed6b97c34],assignPublicIp=DISABLED}" 4. ECS タスクが正常に起動したら、 aws ecs execute-command コマンドを実行して、ECS タスク内のサイドカーコンテナでターミナルセッションを開始します。このコマンド実行時にエラーが発生する場合は、 amazon-ecs-exec-checker スクリプトを使用して、すべての前提条件を満たしていることを確認してください。 # ECS タスク ID を取得する $ aws ecs list-tasks \ --cluster mycluster { "taskArns": [ "arn:aws:ecs:us-west-2:111222333444:task/moira-prod/5ce56f226dd4477a9f57918a98fc852f" ] } # 実行中の ECS タスクで bash シェルを起動する $ aws ecs execute-command \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f \ --container sleeper \ --interactive \ --command "/bin/bash" 5. ECS exec のターミナルセッションで、共有した PID namespace を確認できます。そのために、サイドカーコンテナ内に診断ツールをインストールします。 $ yum install procps strace -y 6. ps コマンド (上記でインストールした procps パッケージに含まれます) を使用することで、共有した PID namespace で実行中のすべてのプロセスを確認できます。このコマンドの出力には、サイドカーコンテナのプロセスだけでなく、アプリケーションコンテナの nginx プロセスも表示されます。また、ECS exec の機能を提供する AWS Systems Manager Session Manager のプロセスも表示されます。 $ ps -aef --forest UID PID PPID C STIME TTY TIME CMD root 38 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 72 38 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 34 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 73 34 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 266 73 0 09:58 ? 00:00:00 \_ /managed-agents/execute-command/ssm-session-worker ecs-execute-command-0147ec3fd84d94d24 root 276 266 0 09:58 pts/1 00:00:00 \_ /bin/bash root 286 276 0 09:59 pts/1 00:00:00 \_ ps -aef –forest root 8 0 0 09:53 ? 00:00:00 /dev/init -- sleep infinity root 19 8 0 09:53 ? 00:00:00 \_ sleep infinity root 7 0 0 09:53 ? 00:00:00 nginx: master process nginx -g daemon off; 101 56 7 0 09:53 ? 00:00:00 \_ nginx: worker process 101 285 7 0 09:59 ? 00:00:00 \_ nginx: worker process root 1 0 0 09:53 ? 00:00:00 /pause 7. PID namespace を共有することで、アプリケーションコンテナ内のプロセスが実行するシステムコールを監視することができます。ステップ 5 でインストールした strace パッケージを使用して、メインの nginx プロセスを監視してみましょう。システムコールを生成するには、 kill コマンドで nginx ワーカープロセスを強制終了します。以下の例では、メインの nginx プロセスは PID 7 で、ワーカープロセスは PID 56 です。これらの値は実行する環境によって異なる場合があるため、自身の環境に合わせて値を置き換えてください。 # プロセスの監視を開始する $ strace -p 7 -o straceoutput.txt &amp; # nginx ワーカープロセスを強制終了する $ kill -9 56 # プロセスの監視ログを表示する $ cat straceoutput.txt rt_sigsuspend([], 8) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=56, si_uid=101, si_status=SIGKILL, si_utime=0, si_stime=0} --- gettid() ... このウォークスルーでは、PID namespace を共有することで、サイドカーコンテナ内のプロセスが ECS タスク内の他のコンテナで実行中のすべてのプロセスを参照し、監視できることを確認しました。ステップ 7 では、アプリケーションコンテナ内のプロセスを強制停止させ、それに伴ってアプリケーションコンテナ内で実行されるシステムコールをサイドカーコンテナから確認しました。 後片付け 以下の手順を実行し、作成したリソースを削除します。 1. ECS Exec のターミナルセッションで exit コマンドを実行し、ECS exec を終了します。 2. aws ecs stop-task コマンドを実行し、ECS タスクを停止します。 $ aws ecs stop-task \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f 3. aws ecs deregister-task-definition コマンドを実行し、ECS タスク定義を登録解除します。 aws ecs deregister-task-definition \ --task-definition fargatepidsharing:1 PID namespace を共有する際の注意点 AWS Fargate 上の ECS タスク内のコンテナ間で PID namespace を共有できるようになりましたが、これには注意すべき点がいくつかあります。それらの注意点を、ウォークスルーで作成したアプリケーション/サイドカーコンテナの例に沿って説明します。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナ内のプロセスを監視するだけでなく、停止または再起動できます。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナのファイルシステムに部分的にアクセスできます。例えば、アプリケーションが PID 7 として実行されている場合、サイドカーコンテナ内では /proc/7/root/ にあるアプリケーションコンテナのファイルシステムにアクセスできます。このとき、Unix ファイルパーミッションが、アプリケーションコンテナのファイルシステムを保護する唯一の仕組みとなります。 ECS タスクで PID namespace を共有する場合、 pause プロセスが PID 1 として新しく実行されます。 アプリケーションコンテナ内で実行されるプロセスの完全なトレーサビリティを実現するためには、ECS タスクに SYS_PTRACE Linux capability を追加することを検討してください。 まとめ 今回の発表によって、AWS Fargate 上でより多くのワークロードを実行されることを楽しみにしています。PID namespace の共有とカーネルパラメータの調整は、 AWS Containers Roadmap でリクエストされていた機能です。私たちは皆様の声を大切にしており、GitHub issue による追加の機能要望や改善に関するフィードバックを心待ちにしています。AWS Fargate のセキュリティアーキテクチャの詳細については、 AWS Fargate セキュリティホワイトペーパー を参照してください。