メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も大きな衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチとして、 前編 では（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介し、後編では（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。 （３）AWS Mainframe Modernizationでのソリューション選定 AWSや AWSパートナー はさまざまな移行ソリューションを提供しており、用途に合わせた最適なソリューションを選定することができます。ここではAWS Mainframe Modernizationが提供する「 自動リファクタリング 」、「 リプラットフォーム 」についてご紹介します。なお、データ移行の新しいソリューションとしては、「 データレプリケーション 」、「 ファイル転送 」があります。 a. 「自動リファクタリング」ソリューション AWS Blu Age は、新しいウェブ・フレームワークとクラウド DevOps のベストプラクティスを駆使し、レガシーな言語アプリケーションをアジャイルなJavaベースのサービスに自動変換する強力なリファクタリング・ソリューションです。AWS Blu Ageは業務ロジックの変更を最小限に抑え、初期投資を削減することを目指しています。これにより、既存のシステムを効率的にアップデートし、ビジネスへの影響を低く抑えることができます。アップデートされたシステムと幅広いソリューションのオプションにより、新しいニーズにも素早く対応できるのは大きな利点です。また、AWS Blu AgeはJavaとの親和性を活かし、既存のシステムと新たなシステムをシームレスに連携させることができます。さらに、AWS Blu Ageは、システム全体に与えるリファクタリングによる影響を事前に評価し、品質を確保することができるため、安定したシステム運用を維持しつつアップデートを進める信頼性があります。このように、AWS Blu AgeとJavaを組み合わせることは、効率的かつ確実な業務モダナイゼーションを実現するための有力な手段です。 b. 「リプラットフォーム」ソリューション Micro Focusツールチェーン を使用して、COBOLアプリケーションの移行を行うアプローチは、特に注目されています。なぜなら、COBOLは長い歴史を持ち、その安定性と信頼性が確立されており、多くの企業で広く利用されているからです。したがって、既存のCOBOLシステムを維持しながら、プラットフォームをアップデートすることで、ビジネス運用の安定性を確保することが可能です。リプラットフォームのアプローチは、新たなシステムへの移行に比べてコストを大幅に削減できる点でも魅力的です。既存のシステムを基盤として、必要な部分を最新の技術で更新することで、コストを節約しながらシステムをモダナイゼーションできます。また、COBOLのスキルを持つエンジニアや開発者が新たなスキルを習得するためには時間とリソースが必要ですが、既存の人材を活用することでシステムの継続的な運用を確立することができます。統合されたMicro Focusツールチェーンを使用したCOBOLアプリケーションの移行は、AWS Mainframe Modernizationの成功事例の一つとしてビジネスに大きな価値を提供します。 おわりに Mainframe Modernizationは、ビジネスゴールを明確に設定し、最適な戦略を立案し、最適なソリューションを選択することで、多くのビジネス・メリットを享受することが出来ます。新しいテクノロジーとアプローチを活用することで、コストの削減、アジリティの向上、技術的負債とリスクの低減などが実現可能です。ビジネスのさらなる発展に向けてMainframe Modernizationへの取り組みは現代のビジネス環境に不可欠なステップになります。

メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチの前編として（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介します。 （１）ビジネス状況に応じたビジネスゴールの設定 メインフレームを運用しているお客様がビジネスゴールを設定するには、主要な観点を考慮した上でビジネス状況に応じた検討を行うことが重要です。 a. 財務上の成果 メインフレームの運用保守コストは他のコンピュータ資源に比べ高額であり、上昇傾向にあります。財務上の成果を達成するために、コストを削減し、運用効率を向上させる必要があります。 b. ビジネスリスクの軽減 メインフレームの技術的負債や人的リスク等のリスクを軽減し、競争力を確保するためには、最新のテクノロジーに適応させる必要があります。モダナイゼーションやクラウド移行により、目標とするビジネスゴールを設定します。 c.　ワークロードの特性 メインフレームのワークロードには、ビジネスの中心で利用され今後も更改され続けるもの、現状ほとんど変更がなく維持を継続する個々のワークロードの特性があります。その特性に合わせたビジネスゴールを設定します。 d. 俊敏性とインサイトの確保 メインフレームのデータはマスタデータとして広く活用されていますが、特有のデータ構造のため俊敏性や拡張性に劣ります。最新のテクノロジーの採用とデータ利用の革新性を高め、ビジネスプロセスの改善や意思決定のサポートに役立てるビジネスゴールを設定します。 （２）Mainframe Modernizationに向けた戦略立案 メインフレームをモダナイズするには、ビジネスゴール、ワークロードの特性および移行コスト等を考慮した移行戦略を立案します。その上で、ビジネスニーズに合った最適な移行ソリューションを選定します。 a. Migration & Modernization（移行とモダナイゼーション） 対象のワークロードをクラウドに移行することで、コストの削減、アジリティの向上、技術的負債とリスクの低減を実現することができます。ビジネスゴールに従って7Rアプローチによる移行戦略を策定します。以下に戦略策定の例を示します。 リプラットフォーム：短期間にできる限りコストを掛けずに他のプラットフォームに移行します。 リファクタリング：モダナイゼーションと俊敏性を高めつつコストを抑えて移行します。 リパーチェス、リライト：積極的に投資をおこない革新的な環境に作り直します。 b. Augmentation & Integration（拡張と統合） クラウドによる俊敏性と革新性を提供することで、メインフレームのデータから最大限の価値を引き出すことができます。ここでは、データの価値を高めるための戦略を策定します。 クラウド上でのデータ活用：メインフレームからクラウドにリアルタイムでデータを連携し、クラウド上で新しいチャネルや機能を提供し、顧客に新たな価値を提供します。 クラウド上でのデータ分析: データをクラウド上で分析し、洞察を得て戦略的な意思決定に活用します。 クラウドストレージ を使用したバックアップとアーカイブ: データの安全なバックアップと長期保存をクラウドストレージで行うことで、データの保護と可用性を向上させます。 Mainframe Modernizationのアプローチは、ビジネスゴールを設定した上で移行戦略を策定することが重要です。その上でソリューションを選定することでビジネスニーズに沿ったアプローチが可能になります。 後編 では、（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。

ソリューションアーキテクトの浅野です。2023年8月24日に「 製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～ 」をオンライン開催しました。 本セミナーでは製造業での製品設計の研究・開発をされているお客様に向けて、流体解析や構造解析などで用いら入れるCAEなどでのAWS活用をご紹介いたしました。AWSからは、実際にAWSのHPCを活用頂いているお客様にご登壇頂き、設計者の方々ににいかに簡単にご利用いただけるか、セキュリティへの対応、実際のアプリケーション性能、AI/MLの活用事例をご紹介頂きました。AWSからは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介しております。 本記事では、発表内容の概要と、発表資料を掲載します。 セミナー概要 タイトル :「製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～」 日時 : 2023 年 8 月 24 日 (木) 10:00 – 12:00 10:00 – 10:05 オープニング スピーカー: AWS シニアビジネスデベロップメントマネージャー 舛重 国規 10:05 – 10:35 クラウドで設計・開発プロセスを爆速化！AWSを活用したオムロン独自の研究開発環境「RDinX」 スピーカー: オムロン株式会社 経営基幹職 津田 学 氏 自社セキュリティ基準に準拠したオムロン独自のAWS開発環境「RDinX」を構築。CAE・最適化のための演算リソースの柔軟な確保を実現し、パワーエレクトロニクス技術のプロセスを大幅削減！ 講演資料 10:35 – 11:05 プラントエンジニアリングのCAEにおけるHPC on AWS活用事例（ベンチマークを中心として） スピーカー: 千代田化工建設株式会社 リードエンジニア 髙城 恭司 氏 長年3次元流動解析（CFD）をHigh Performance Computing基盤にて実施しているが、近年はCPUおよびGPUの選択肢が増えている。本講演では、プラントエンジニアリングにおけるCAE活用事例や、各種CPUおよびGPUの実検討モデルにおけるベンチマーク結果（計算速度）について発表する。 講演資料 11:05 – 11:35 マテリアルズ・インフォマティクスと画像検査自動化への挑戦 スピーカー: 三協立山株式会社 三協マテリアル社 林 良和 氏、佐藤 晃太 氏 MI（林 様）: 材料工学の分野で「機械学習を活用した材料探索」（MI）が注目されています。本セッションではAmazon SageMakerを用いたMIによる材料開発について紹介します。 画像解析（佐藤 様）: Pythonを始めて数か月のエンジニアが、社内で蓄積された画像検査データとAmazon SageMakerを使って、画像検査の自動化に挑戦した過程をご紹介します。 講演資料 11:35 – 11:55 HPC on AWS の概要と最新動向 スピーカー: AWS シニアソリューションアーキテクト 吉廣 理 AWS では HPC 環境に求められる高レベルな CPU /ネットワーク/ストレージパフォーマンスは勿論、VDI やオーケストレーションなどクラウド HPC 環境をアシストする機能を兼ね備えています。本セッションでは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介します。 講演資料 11:55 – 12:00 クロージング スピーカー: AWS シニアデベロップメントマネージャー 舛重 国規 おわりに 今回のセミナーでは、設計・開発分野でAWSを活用頂いているお客様より、実際の活用例や、導入にあたっての課題といったリアルな使い方についてご紹介頂きました。実業務での使い心地や導入時の課題に関心がある方々にとって、参考にして頂ける内容になっております。AWSでは、HPC環境を簡単に構築でき、コスト効率よくご利用いただけます。ぜひ設計・開発業務でもAWSをご活用ください！

このブログ記事は、Telco Solutions Architect の Jack Chen と、Developer Advocate の Robert Belson が執筆しています。 AWS Wavelength は、AWS のコンピューティングサービスとストレージサービスを 5G ネットワーク内に組み込み、超低レイテンシーアプリケーションの開発、デプロイ、スケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。AWS は、Wavelength Zones における Application Load Balancer (ALB) のサポートを開始しました。ALB はレイヤー 7 の負荷分散のユースケースに対応していますが、 Wavelength Zones にデプロイされる一部の低レイテンシーアプリケーションでは、QUIC、WebRTC、SRT などの UDP ベースのプロトコルに依存しており、レイヤー 7 ロードバランサーでは負荷分散できません。この投稿では、AWS Wavelength の一般的な負荷分散パターンについて説明します。これには、DNS ベースの負荷分散が、複数の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス間で非 HTTP (s) トラフィックを負荷分散するという顧客の要件にどのように対処できるかを示すアーキテクチャ案が含まれます。 このソリューションは、Wavelength Zones で実行されるワークロードの自動スケールアップおよびスケールダウン機能の基盤も構築します。 AWS Wavelength における負荷分散のユースケース AWS リージョンでは、可用性の高いエッジアプリケーションのデプロイを検討しているお客様が、受信したアプリケーショントラフィックを 1 つ以上のアベイラビリティーゾーン(AZ) の複数のターゲットに自動的に分散するアプローチとして Amazon Elastic Load Balancing (Amazon ELB) を検討することがよくあります。ただし、本投稿の公開時点では、AWS マネージドである Network Load Balancer (NLB) は Wavelength Zonesではサポートされておらず、ALB は世界中のすべての Wavelength Zones に展開されています。そのため、この投稿は、AWS Wavelength の負荷分散ソリューションに関する一般的なアーキテクチャガイダンスを文書化することを目的としています。 最も顕著な AWS Wavelength のユースケースの 1 つとして、WebRTC のようなプロトコルを大規模に使用した UDP 通信の没入感が高い動画ストリーミングがあります。ここでは、ライブイベントや一般的な顧客アクセスパターンによるトラフィック急増に対応するために負荷分散ソリューションが必要になることがよくあります。レイヤー 4 トラフィックに依存するこれらのユースケースでは、レイヤー 7 の ALB で負荷分散することはできません。代わりに、レイヤー 4 の負荷分散が必要です。 現在までに、レイヤー 4 ロードバランサーを含め以下の2つのインフラストラクチャデプロイメントが最もよく見られます。 Amazon EC2 ベースのデプロイメント : 多くの場合、初期段階の企業や ISV が選択する環境ですが、EC2 インスタンス群は、ビデオストリーミング、データ分析、産業 IoT (IIoT) アプリケーションなどの高スループットのユースケースでロードバランサーを活用します。 Amazon EKS デプロイメント : インフラストラクチャのパフォーマンスとコスト効率を最適化したいお客様は、エッジでのコンテナデプロイメントにより Wavelength Zones のアプリケーションを管理できます。次に、外部ロードバランサーを NodePort オブジェクトを介して公開されたサービスを指すように構成できます。さらに、Kubernetes の Ingress を作成するときに、 AWS Load Balancer Controller を活用して ALB をプロビジョニングするという方法も一般的です。 デプロイメントタイプにかかわらず、以下の設計上の制約を考慮する必要があります。 ターゲット登録 : AWS が管理していない負荷分散ソリューションの場合、ロードバランサーのターゲット登録をシームレスに行うためのソリューションはお客様が管理する必要があります。考えられる解決策の 1 つとして、最近の HAProxyConf でのプレゼンテーション をご覧ください。 エッジディスカバリ : キャリア向けエンドポイントごとに DNS レコードを Amazon Route 53 に入力することはできますが、DNS はモバイルクライアントを最適なモバイルエンドポイントに確定的にルーティングするわけではありません。利用可能な場合にモバイルクライアントを最もレイテンシーの低いエンドポイントに最も効果的にルーティングするには、エッジディスカバリサービスが必要です。 クロスゾーン負荷分散 : AWS Wavelength のハブアンドスポーク設計を考えると、お客様管理のロードバランサーはその Wavelength Zones にのみトラフィックをプロキシする必要があります。 ソリューションの概要 — Amazon EC2 このソリューションでは、Amazon EC2 ベースのデプロイメントで、単一の Wavelength Zones で可用性の高い負荷分散を実現します。別の投稿では、 AWS Wavelength における Amazon Elastic Kubernetes Service (Amazon EKS) クラスターの AWS Load Balancer Controller に必要な設定について説明します。 提案ソリューションでは、DNSベースの負荷分散を導入しています。これは、インテリジェントな負荷分散ソフトウェアの複雑さを解消し、Domain Name System (DNS) リゾルバーがトラフィックをエンドポイントセットに（均等に、または加重分散で）分散できるようにする手法です。 本ソリューションでは、Amazon Route 53 の 加重ルーティングポリシー を活用して、Wavelength Zones 内で実行されている複数の EC2 インスタンスに対するインバウンド DNS クエリを解決します。特定ワークロードの EC2 インスタンスは Wavelength Zones にデプロイされるため、起動時に キャリア IP アドレス をネットワークインターフェイスに割り当てることができます。 このソリューションにより、AWS Wavelength インスタンスにアタッチされたキャリア IP アドレスが、お客様提供のパブリックホストゾーンの DNS レコードとして自動的に追加されます。 パブリックホストゾーンのレコードがいくつあったとしても、Route53 がクエリにどのように応答するかを決定できるよう、Route53 には多数のルーティングポリシーが用意されています。 シンプルルーティングポリシー — Wavelength Zones の単一リソースにトラフィックをルーティングする必要がある場合は、シンプルなルーティングを使用できます。1 つのレコードに複数の IP アドレスを含めることができますが、Route 53 は値をランダムな順序でクライアントに返します。 加重ルーティングポリシー — 指定した比率を使用してトラフィックをより確定的にルーティングさせる場合は、このポリシーを選択できます。たとえば、キャリア IP アドレス A にトラフィックの 50% を受信させ、キャリア IP アドレス B にトラフィックの 50% を受信させたい場合は、それぞれ 50 と 50 の重みを持つ 2 つの個別の A レコード (キャリア IP アドレスごとに 1 つ) を作成します。Route 53 のルーティングポリシーの詳細については、 Route 53 デベロッパーガイド をご覧ください。 提案ソリューションは、Route 53 DNS の 加重ルーティングポリシー を利用して、Wavelength Zones で実行されている複数の EC2 インスタンスにトラフィックをルーティングします。 レファレンスアーキテクチャ 次の図は、本ソリューションの負荷分散コンポーネントを示しています。このコンポーネントでは、Wavelength Zones の EC2 インスタンスにキャリア IP アドレスが割り当てられます。ホスト (www.example.com など) の加重 DNS レコードは、キャリア IP アドレスで更新されます。 デバイスが DNS クエリを実行すると、指定されたドメイン名に関連付けられているキャリア IP アドレスのいずれかが返されます。デバイス数が多い場合は、リソースプール内のすべての EC2 インスタンスに負荷が均等に分散されると予想されます。非常にエフェメラルなモバイルエッジ環境であることを考慮すると、キャリア IP はワークロードに対応するために頻繁に割り当てられ、さらにすぐにリリースされる可能性があります。ただし、この予測不可能な動作により、古い DNS レコードが生成され、「ブラックホール」、つまり存在しなくなったエンドポイントへのルートが発生する可能性があります。 Time-To-Live (TTL) は、DNS 再帰リゾルバーがこのレコードに関する情報をキャッシュする時間を秒単位で指定する DNS 属性です。 この例では、30 秒に設定して、DNS リゾルバーが権威ネームサーバーから最新のレコードを取得するように強制し、古い DNS 応答を最小限に抑える必要があります。ただし、TTLを低くするとコストに直接影響します。これは、再帰リゾルバーから常に最新のレコードを取得するために Route 53への呼び出しが増えるためです。 ソリューションの中核となるコンポーネントは次のとおりです。 EC2 起動テンプレート — Amazon マシンイメージ (AMI) 、 Amazon Elastic Block Storage (Amazon EBS) のタイプとサイズ、キャリア IP が関連付けられた Elastic Network Interface (ENI) アタッチメント、 インスタンスタグ 、その他の属性などのインスタンス設定情報を指定します。 AWS Auto Scaling グループ — 自動スケーリングを目的として論理的にグループ化された EC2 インスタンス群 Wavelength Zones の上記のサービスに加えて、AWS リージョンでは以下のサービスも利用されています。 AWS Lambda — Route 53 サービスに API 呼び出しを行って DNS レコードを更新するサーバーレスのイベント駆動型関数 Amazon EventBridge — EC2 インスタンスの ライフサイクルイベント に反応し、Lambda 関数を呼び出して DNS を更新するサーバーレスイベントバス Amazon Route 53 — AWS Wavelength がホストするリソースを指すドメインレコードを含むクラウド DNS サービス 本投稿では、特定の負荷分散ソフトウェアソリューションは意図的にお客様に任せています。お客様は、HAProxy や NGINX など、 AWS Marketplace で入手可能なさまざまな一般的なロードバランサーを活用できます。DNS レコードの自動登録に重点を置いて機能的な負荷分散を実現するために、このソリューションはステートレスワークロードのみをサポートするように設計されています。ステートフルなワークロードをサポートするには、スティッキーセッション（ターゲットグループ内の同じターゲットにリクエストをルーティングするプロセス）を基盤となるロードバランサーソリューションで構成する必要があり、DNSがネイティブに提供できる範囲外です。 自動化の概要 前述のコンポーネントを使用して、以下のワークフローの自動化を実装できます。 Amazon CloudWatch アラーム は、Auto Scaling グループの スケールアウトまたはスケールイン イベントをトリガーし EC2 インスタンスを追加または削除することができます。EventBridge は EC2 インスタンスの状態変更イベントを検出し、Lambda 関数を呼び出します。この関数は、EC2 インスタンスの状態変化に関連する加重 A レコード を追加（スケールアウト）または削除（スケールイン）することにより、 Route53 の DNSレコードを更新します。 自動自動スケーリングポリシーの設定は、この記事の範囲外です。 メモリ使用率 などの 事前定義済み のカスタムメトリクスに基づいて、使用を検討できる Auto Scaling トリガーは多数あります。デモでは、手動による自動スケーリングを利用します。 すでに説明したコアコンポーネントに加えて、このソリューションでは AWS Identity and Access Management (IAM) ポリシーと CloudWatch も利用しています。どちらのサービスも、 AWS Well-Architected なソリューションを AWS で構築するための重要コンポーネントです。また、 AWS Systems Manager Parameter Store を使用してユーザー入力パラメータを追跡しています。ソリューションのデプロイは、 AWS CloudFormation テンプレートによって自動化されます。提供される Lambda 関数は AWS Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。 Amazon Virtual Private Cloud (Amazon VPC) 、 サブネット 、 Carrier Gateway 、および ルートテーブル は、AWS ベースのネットワークインフラストラクチャにおける基本的な構成要素です。今回のデプロイメントでは、新しい VPC を作成し、選択した Wavelength Zones に 1 つのサブネット、Carrier Gateway を作成し、このサブネットのルートテーブルを更新して、デフォルトルートを Carrier Gateway を指すようにします。 導入の前提条件 本ソリューションを AWS アカウントにデプロイするための前提条件は次のとおりです。 Wavelength Zones へのアクセス : アカウントが Wavelength Zones を使用するための許可リストにない場合は、 こちら から Wavelength Zones にオプトインしてください。 Route 53 でホストされているパブリック DNS ホストゾーン : このソリューションをデプロイするには、登録済みのパブリックドメインへのアクセス権が必要です。このドメインのゾーンは、AWS Wavelength ワークロードをデプロイ予定のアカウントと同じアカウントでホストする必要があります。 パブリックドメインをお持ちでない場合は、 新しいドメイン を登録できます。ドメイン登録にはサービス料がかかりますのでご注意ください。 Amazon S3 バケット : Route 53 の DNS レコードを更新する Lambda 関数では、ソースコードを.zip ファイルとして Amazon S3 バケットに保存します。 Amazon EC2 キーペア : デプロイには既存のキーペアを使用できます。このソリューションをデプロイする予定のリージョンにキーペアがない場合は、 これらの手順 に従って作成してください。 4G または 5G 接続デバイス : インフラストラクチャは基盤となる接続デバイスとは独立して導入できますが、接続をテストするには、いずれかの Wavelength パートナーネットワークが利用可能なモバイルデバイスが必要です。詳細については、 通信プロバイダーと Wavelength Zones のロケーション一覧 を確認してください。 まとめ この投稿では、AWS Wavelength Zones で実行されているワークロードに DNS ベースの負荷分散を実装する方法を示しました。EventBridge ルール と Lambda 関数を使用して Route 53 がホストする DNS レコードを更新するソリューションをデプロイしました。AWS Wavelength について詳しく知りたい場合は、 こちら からAWS Compute ブログチャンネルを購読してください。 原文は こちら です。翻訳はソリューションアーキテクトの新谷 歩生が担当しました。

この記事は、Napptive の CTO である Daniel Higuero 氏と共同執筆したものです。 イントロダクション クラウドネイティブなアプリケーションの時代に、Kubernetes はコンテナオーケストレーションの分野における傑出したテクノロジーとして登場しました。しかしながら、Kubernetes を使う際には、クラスターの設定、クラスター全体のアドオン、補助するツールの実行や管理だけでなく、アプリケーションのデプロイに関わる設定 (Deployment、Service、Ingress, Horizontal Pod Autoscaling、LimitRange など) を理解することをユーザーに要求します。これはアプリケーションを実行するプラットフォームの構築に高い柔軟性をもたらす一方で、本番環境においてこういった設定を完全に把握し、プラットフォームを保守・実行することは簡単なタスクではありません。顧客の話によると、Kubernetes 上でアプリケーションのプラットフォームを構築・実行することに関連する懸念は、通常 1 つのチームに降りかかります。チームの名前は、誰に尋ねるかにもよっても異なるかもしれませんが、本記事ではチーム内のメンバーを プラットフォームエンジニア と呼びます。オペレーションモデルと責任 (言い換えると、自身でも運用するものを構築したり、他のユーザーが再利用できるテンプレートを作成する) は異なる場合がありますが、その目的は通常は同じで、社内の顧客や アプリケーション開発者 が簡単に利用できるプラットフォームを構築することです。 アプリケーション開発者はエンドユーザーに価値を提供するビジネスロジックと機能の実装に責任がある一方で、必ずしも Kubernetes の一部始終 (Ingress オブジェクトの詳細を適切に設定する方法など) を理解しているわけではありません。できれば、これらのチームはアプリケーションを実行する最小限の設定のみを指定したいと考えています。具体的には、どのポートをリッスンするのか、どのコンテナイメージを使用するのか、アラームの設定にどのメトリクスとしきい値を使用するのか、といったものです。 これらのペルソナは、両方ともビルダーです。内部向け、あるいは外部向けの顧客に公開されるプロダクトを開発しています。本番環境においては、構築するものは安定していて時間の経過とともに顧客の期待を満たすために進化可能である必要があります。 ソリューション概要 双方向の組織的な依存関係の削減 アプリケーション開発者を支援する 1 つの方法は、抽象化を通じて組織標準を導入することです。難しいのは、これらの抽象化を正しくおこなうことです。Kubernetes はそれ自体がアプリケーション、リソース、ストレージ、コンピュートの抽象化をおこなう一方で、この抽象化は、プラットフォーム開発者とアプリケーション開発者の双方にとって効率的であるには低レベルであることが多いと考えられています。例を挙げることで、こういった論拠を発展させてみましょう。プラットフォームチームが Kubernetes API をそのまま顧客 (すなわち、アプリケーションチーム) に公開し、変更がロールアウトされる必要があるシナリオを想像してください。おそらく、Kubernetes の 廃止予定の API 移行ガイド で説明されている Kubernetes v1.22 の Ingress オブジェクトの API グループの変更のような、新しい Kubernetes のバージョンと関係しているかもしれません。Ingress オブジェクトを例に挙げると、networking.k8s.io/v1beta1 API バージョンは Kubernetes 1.22 で廃止され、ユーザーは Ingress の定義を networking.k8s.io/v1 に変更する必要がありました。この変更により、プラットフォームチームと全ての顧客に依存関係が生じました。新しい API バージョンに沿うように設定を変更する必要があったからです。またこれは、プラットフォームチームが Kubernetes クラスターをアップグレードする前に、全ての顧客一人ひとりが新しいバージョンの API を使用する必要があることを意味しています。 このチーム間の双方向依存関係の例は、通常はプラットフォームチームとアプリケーションチームは一対多の関係であり、Kubernetes をアップグレードできないシナリオに繋がる可能性があります。Kubernetes のアップグレードが顧客のアプリケーションを壊すかもしれず、Kubernetes のバージョンのアップグレードが遅れるシナリオに陥り、サポートされているライフサイクル ( Amazon EKS Kubernetes リリースバージョンカレンダー を参照) から外れ、重要なアップデートの取り込みが停止するリスクがありいます。 Platform as a Product 前述のシナリオのような課題を解決する 1 つの方法は、独自の抽象化のレイヤーを作成することです。これは、サービスの API を構築する場合と同じように考えることができます。その API は安定していて、小さく、使用している基盤となるデータベースエンジンについての詳細が漏れないようにしたがるでしょう。それは API を利用するユーザーの関心事ではないからです。所有するインタフェースを通じて明確に定義された設定の選択肢の小さなセットをアプリケーションチームに公開することで、基盤となる実装 (この場合は Kubernetes) の詳細を顧客に漏らすことなく、改善点や機能をより早く実装できます。先程の例を踏まえると、このようなプラットフォームの改善は、Service と Ingress を使ってサービスを公開する従来のアプローチから、Kubernetes Gateway API でのサービスの公開に移行することかもしれません。 Open Application Model (OAM) 前述の抽象化は様々な方法で実現できますが、この記事では、アプリケーションのコンポーネントをデプロイする構成の抽象化を標準化する方法として、 Open Application Model (OAM) について説明します。これは抽象化のさらなる抽象化に少し似ているように聞こえるかもしれません。そうではありますが、これらの抽象化は、抽象化を利用するペルソナの目的を果たしていることを念頭に置いてください。Kubernetes は、プラットフォームを構築するプラットフォームエンジニアが、基盤となるインフラストラクチャリソースを使用するための抽象化のレイヤーとして機能し、OAM はプラットフォームエンジニアリングチームによって構築されたプラットフォームを使用するアプリケーション開発者向けの抽象化のレイヤーとして機能します。 OAM は、クラウドネイティブなアプリケーションを構築するためのオープンソースの 仕様 です。サービス、構成、依存関係を含む、アプリケーションのコンポーネントを宣言的に定義できます。OAM は、開発者が大幅な変更を加えることなく異なるプラットフォームのバージョンに簡単にデプロイ可能な、ポータブルなアプリケーションを作成することを可能にします。また、デプロイ・スケーリング・更新を含む、アプリケーションのライフサイクルを管理するためのフレームワークも提供します。OAM はその柔軟性と相互運用性により、クラウドでのモダンアプリケーション開発のための強力なツールとなっています。OAM の仕様は、必要に応じて新しいコンポーネントや機能を追加し拡張できるように設計されています。また OAM 仕様をサポートするどのプラットフォームでも使用できるという意味でも、非依存的です。このモデルでは、機能的な目的を達成するためにまとめてデプロイされるサービスの集合として、Application を定義します。 KubeVela KubeVela は前述の Open Application Model を実装するオープンソースのプロジェクトです。Kubernetes 上でアプリケーションを構築・デプロイ・管理するためのデリバリープロセスとして定義されています。開発者がアプリケーションのコンポーネントとそれらの関係を宣言的な方法で定義することを可能にする高レベルのプログラミングモデルを提供します。KubeVela のモデル主導型アプローチは、Kubernetes に関連する複雑さを大きく取り除き、開発者がインフラストラクチャの管理ではなくコードを書くことに集中できるようにします。また KubeVela は、アプリケーションの複数のコンポーネントを統合し、ローリングアップデート・ロールバック・カナリアリリースを実行できる、強力なデプロイエンジンを提供します。KubeVela の柔軟性と使いやすさは、Kubernetes の深い専門知識を必要とせずに Kubernetes 上でクラウドネイティブなアプリケーションを構築したい開発者にとって、良い選択になります。 KubeVela の Application は、以下の要素で構成されています。 Components: アプリケーションの機能要素について記述します。通常はバックエンドのマイクロサービスと関連付けられます。異なる Component の type が、リクエストを受信するバックエンドサービスなどの長時間実行されるプロセスと、定期的なバックアップタスクなどの短時間で終了するプロセスの両方をサポートします。 Traits: Trait を Component に関連付けることで、Component の基礎となる機能を拡張または変更できます。例えば、Trait はコンポーネントのログを別のサブシステムにエクスポートしたり、コンポーネントをインターネットに公開する追加の要素を作成したり、コンポーネントを実行するための設定オプションを追加したりできます。Component には、必要に応じて多くの Trait を関連付けることができます。 Policies: Trait と同様に、すべての Component に影響するアプリケーションレベルの設定オプションを適用する方法を提供します。 Workflows: 開発者がアプリケーションのデプロイ方法を定義できるようにします。これにより、コンポーネントのデプロイから他のサービスとの通信まで、複数の type のアクションを可能にする個々のワークフローステップを利用できます。 以下の図は、 KubeVela のドキュメントサイトから抜粋したものです。 ソース: https://kubevela.io/docs/getting-started/core-concept このアプローチにより、プラットフォームチームは Pod・Ingress・インフラストラクチャコントローラーのリソース ( AWS Controllers for Kubernetes や Crossplane ) など、全てのコンポーネントの低レベルの設定を保持する抽象化のレイヤーを作成でき、アプリケーションチームはそれを利用できます。アプリケーションチームは、作成・アップグレード・削除を含むコンポーネントのライフサイクル全体を担当します。以下の図は、もっとも単純な抽象化を示しています。 プラットフォームチームは、Deployment 設定、 Pod Topology Spread Constraints 、Ingress、Service の設定 (プロトコルまたはその他のパラメータに基づく) 及びその他の Kubernetes オブジェクトの構成など、Kubernetes のドメイン固有の設定を担当します。アプリケーションチームは、アプリケーション全体を表すとても軽量な構成を作成することに責任を持ちます。KubeVela の Component と Trait の抽象化を用いるため、アプリケーションチームは Kubernetes オブジェクトとその構成を設計した経験が豊富である必要はありません。 以下のハンズオンの例からもわかるとおり、最小限の設定で 1 つのアプリケーションを作成すると、Ingress または Service、HPA (オートスケーリング用) および Deployment というオブジェクトが生成されます。Kubernetes におけるデプロイの内容について知らなくても実現可能です。 ウォークスルー 何を構築するのか？ OAM と Kubernetes の価値を実証するために、 フロントエンド のコンポーネントと バックエンド のコンポーネントを組み合わせたサンプルアプリケーションを使用します。これらのサービスが合わさることで 1 つのアプリケーションを表します。アプリケーション開発者は Kubernetes について知る必要はありません。代わりに、KubeVela によって実装された、標準化された OAM モデルを使用できます。その結果、Kubernetes オブジェクトの設定 (Deployment、Ingress、ConfigMap など) はシンプルになります。アプリケーション開発者はこの OAM ベースのコンポーネントを使用して、アプリケーションを Kubernetes クラスターにデプロイします。 前提条件 始める前に、以下の前提条件を満たす必要があります。 Amazon Command Line Interface ( AWS CLI ) kubectl 実行中の Amazon Elastic Kubernetes Service (Amazon EKS) クラスター AWS LoadBalancer Controller がインストールされていること ( ガイド を参照すること) vela CLI ( KubeVela ユーザーインタフェース のため) アプリケーションコードを設定ファイルをホストする GitHub アカウント (GitOps アプローチを使用している場合) このセクションでは、Amazon EKS で KubeVela を使用して OAM を実装するために必要なステップを示します。 KubeVela を用いて環境をブートストラップする 最初のステップとして、OAM を使用して Kubernetes にクラウドネイティブなアプリケーションを構築およびデプロイするためのオープンソースフレームワークである KubeVela をデプロイしてみましょう。以下のコマンドで示すように、Amazon EKS クラスターに KubeVela をインストールします。 helm repo add kubevela https://charts.kubevela.net/core helm repo update helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait Apache Configuration これらのコマンドは vela-system という名前の新しい Namespace を作成し、Amazon EKS クラスターに最新バージョンの KubeVela をインストールします。インストールした後、KubeVela を用いて OAM アプリケーションを定義およびデプロイできます。KubeVela ダッシュボードを有効化したい場合は、以下のコマンドを使用できます。 # vela addon enable velaux Apache Configuration ダッシュボードにアクセスするには、以下のコマンドを使用します。 # kubectl port-forward svc/velaux-server 8000:8000 -n vela-system Apache Configuration ブラウザを操作し、以下のようにダッシュボードにアクセスします。管理者ロールのユーザーとパスワードを登録しセットアップします。 KubeVela によるアプリケーションのデプロイ 前述のとおり、アプリケーションは 2 つのマイクロサービスで構成されています。マイクロサービスをデプロイするために、アプリケーションチームはもはや Kubernetes の Deployment の設定を覚える必要はありません。ここで OAM が登場します。 複数の Kubernetes オブジェクトをデプロイする代わりに、アプリケーションを設定するための適切な知識を持っていさえすれば、開発者はアプリケーションの高レベルな抽象化を以下のように定義できます。 # cat <<EOF > app.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: web-app spec: components: - name: frontend type: webservice properties: image: "public.ecr.aws/aws-containers/ecsdemo-frontend:latest" ports: - port: 3000 expose: true traits: - type: cpuscaler properties: cpuUtil: 80 max: 6 min: 1 - type: env properties: env: NODEJS_URL: "http://ecsdemo-nodejs.default.svc.cluster.local/" - name: backend type: webservice properties: image: "public.ecr.aws/aws-containers/ecsdemo-nodejs:latest" ports: - port: 8080 expose: true traits: - type: scaler properties: replicas: 2 EOF kubectl apply -f app.yaml Apache Configuration Application マニフェストの構成について説明します。フロントエンドとバックエンドという 2 つの Component があります。これらの Component は type が webservice です。これは、KubeVela のインストールに付属するビルトインのコンポーネントタイプの 1 つです。組織の標準に沿った独自のコンポーネントの実装を作成することもできます。各 Component 内で、定義された Trait を確認できます。各 Trait には独自の実装があり、デモンストレーションを目的として、2 つの異なる Trait として、オートスケーリングと ENV Trait を使用しました。覚えておいて頂きたいのは、Component と Trait を組み合わせるこの方法は、Trait で定義される API に忠実に従う限り、メトリクスのバックエンドを別のものに切り替えるなど、Trait の基礎となる実装を後で変更または拡張できるようにするためであるということです。これには、Component と Trait を組み合わせる方法を変えることは含まれません。 KubeVela は作成する全てのオブジェクトにデフォルトの Label を付与するので、web-app Application の関連するオブジェクトを全て取得できます。ターミナルで以下のコマンドを実行して、アプリケーション用にどのようなオブジェクトが作成されたのかを調べてみましょう。 # kubectl get all --selector=app.oam.dev/name=web-app -L app.oam.dev/component NAME READY STATUS RESTARTS AGE COMPONENT pod/backend-6959d96ddc-4vnlc 1/1 Running 0 3d14h backend pod/backend-6959d96ddc-bmm4p 1/1 Running 0 3d14h backend pod/frontend-76877d4554-dzldt 1/1 Running 0 3d14h frontend NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE COMPONENT service/backend ClusterIP 10.100.148.2 <none> 8080/TCP 3d14h backend service/frontend ClusterIP 10.100.171.75 <none> 3000/TCP 3d14h frontend NAME READY UP-TO-DATE AVAILABLE AGE COMPONENT deployment.apps/backend 2/2 2 2 3d14h backend deployment.apps/frontend 1/1 1 1 3d14h frontend NAME DESIRED CURRENT READY AGE COMPONENT replicaset.apps/backend-6959d96ddc 2 2 2 3d14h backend replicaset.apps/frontend-76877d4554 1 1 1 3d14h frontend NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE COMPONENT horizontalpodautoscaler.autoscaling/frontend Deployment/frontend <unknown>/80% 1 6 1 3d14h frontend Apache Configuration ご覧のとおり、Service が 2 つ、Deployment が 2 つ、Horizontal Pod Autoscaler が 1 つあります。 簡潔に言うと、各オブジェクトは app.oam.dev/component ラベルの値に基づいて特定の Component に関連付けられます。KubeVela と Open OAM は、プラットフォームチームがより高レベルな概念を作成し、それらを組み合わせてより高度な構造にすることを可能にします。その後、これらの構造をアプリケーションチームが使用できるようになります。 フロントエンドサービスへのポートフォワーディングを設定することで、アプリケーションが実行されていることをテストできます。 # kubectl port-forward svc/frontend 3000:3000 Forwarding from 127.0.0.1:3000 -> 3000 Forwarding from [::1]:3000 -> 3000 Apache Configuration その後、ブラウザで http://localhost:3000 にアクセスして、アプリケーションが実行中であることを確認できます。 クリーンアップ 以下のコマンドを使用して、Application、Component、Trait をクリーンアップできます。 kubectl delete -f app.yaml Apache Configuration オプションで、 このドキュメント に従って作成された Amazon EKS クラスターを削除できます。 結論 本記事では、KubeVela を使って OAM を実装する方法を紹介しました。OAM は、Kubernetes 上でクラウドネイティブなアプリケーションを構築しデプロイするための標準化されたアプローチを提供します。OAM と KubeVela で抽象化をおこなうことで、開発者が Kubernetes でクラウドネイティブなアプリケーションを構築しデプロイするプロセスをシンプルにでき、開発者は顧客に価値を提供することに集中できます。 このブログ記事で紹介したコンセプトに興味がある場合は、ソーシャルメディア (Linkedin または Twitter) を使ってお気軽にご連絡ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

広告クリエイティブは、生成系 AI（Generative AI, GenAI）によって革命を起こす可能性を秘めています。 生成系 AI モデルを再トレーニングし、テキストプロンプト (モデルによって生成されるシーンやオブジェクトを説明する文) などのいくつかの入力をモデルに与えることで、製品画像などさまざまな種類の斬新な画像を作成できるようになりました。 この手法は、2022 年から Stable Diffusion 、 Midjourney 、 Dall-E-2 などの潜在拡散モデル (Latent Diffusion Model) と呼ばれる新しいクラスの基盤モデル（Foundation Model, FM）の爆発的増加によって有望な結果を示しています。 ただし、これらのモデルを本番環境で使用するには、生成プロセスを継続的に改良して一貫した出力を生成する必要があります。 多くの場合、製品のサンプル画像を大量に作成し、巧妙で迅速なエンジニアリングを行う必要があるため、大規模な作業は困難になります。 この記事では、特に大量の画像を扱う場合に、この革新的なテクノロジーを活用して、魅力的で革新的な広告を大規模に生成する方法について模索します。生成系 AI の力、特にインペインティング技術を利用することで、画像の背景をシームレスに作成でき、視覚的に美しく魅力的なコンテンツを作成でき、（モデルハルシネーションと呼ばれる）望ましくない画像アーティファクトを減らすことができます。 また、 Amazon SageMaker エンドポイントを活用して、この手法の実用的な実装についても詳しく説明します。これにより、この創造的なプロセスを推進する生成系 AI モデルの効率的なデプロイが可能になります。 生成系 AI ベースの画像生成では、画像内の欠落している要素を置き換えるための強力なソリューションである、インペインティングを重要なテクニックとして採用しています。 ただし、これにはいくつかの課題があります。 たとえば、画像内のオブジェクトの位置を正確にコントロールすることは制限されるため、次の画像例に示すような生成した画像自体の問題や、オブジェクトの浮き上がり、境界がシームレスに融合していないなどの問題が発生する可能性があります。 この問題に対処するために、この記事では最低限の指示で多数のリアルな画像を生成し、創造の自由と制作における効率性のバランスをとることを提案します。 提案されたソリューションを本番環境向けに拡張し、AWS 環境への AI モデルのデプロイを効率化するために、SageMaker エンドポイントを使用してデモを行います。 特に、インペインティング処理をレイヤーのセットとして分割します。この各レイヤーは異なるプロンプトのセットを持つことがあります。 このプロセスは、以下のステップに要約できます。 まず、一般的なシーンのプロンプト (たとえば「後ろに木がある公園」など) を入力して背景画像を生成し、その背景にオブジェクトをランダムに配置します。 次に、オブジェクトを置く場所をプロンプト（たとえば「芝生の上でのピクニック」、「木製のテーブル」など）で指示し、オブジェクトの中央下部より下の部分にレイヤーを追加します。 最後に、背景と同じプロンプトを使用して、オブジェクトの中央上部より上の部分に背景レイヤーに似たレイヤーを追加します。 このプロセスの利点は、背景に対して人間の期待に沿った拡大縮小や配置を解釈するため、オブジェクトのリアリティが向上することです。 次の図は、提案されたソリューションの手順を示しています。 ソリューション概要 これらのタスクを実行するには、次のデータフローが考えられます。 Segment Anything Model (SAM) と Stable Diffusion インペインティング モデルは SageMaker エンドポイント にホストされます。 背景プロンプト (Background Prompt) を使用して、Stable Diffusion モデルを使用して背景画像 (Generated Background Image) を生成します。 基本となる商品画像 (Base Product Image) が SAM を介して渡されマスク画像 (Mask) が生成されます。 マスク画像の逆はアンチマスク画像 (Anti-Mask) と呼ばれます。 生成された背景画像とマスク画像が、前景用のプロンプト (Foreground Prompt) とネガティブプロンプト (Negative Prompt) と一緒に Stable Diffusion インペインティングモデルへの入力として使用され、中間生成物としての背景画像 (Generated Intermediate Background Image) が生成されます。 同様に、生成された背景画像、アンチマスク画像、前景用のプロンプト、ネガティブプロンプトが Stable Diffusion Inpainting モデルへの入力として使用され、中間生成物としての前景画像 (Generated Intermediate Foreground Image) が生成されます。 最終的に生成される商品画像の出力結果 (Generated Product Image) は、生成された中間の前景画像と生成された中間の背景画像を組み合わせることによって得られます。 前提条件 エンドポイントのデプロイと推論の実行に使用する SageMaker ノートブック を作成する AWS CloudFormation テンプレートを開発しています。 以下にアクセスできる AWS Identity and Access Management (IAM) ロールを持つ AWS アカウントが必要です。 AWS CloudFormation SageMaker SageMaker エンドポイントには ML モデルを実行するインスタンスが提供されていますが、生成系 AI モデルのような負荷の高いワークロードを実行するには、GPU 対応の SageMaker エンドポイントを使用します。 価格の詳細については、 Amazon SageMaker の料金 を参照してください。 モデルのホストには NVIDIA A10G 対応の ml.g5.2xlarge インスタンスを使用しています。 Amazon Simple Storage Service (Amazon S3) 詳細については、 GitHub レポジトリ と CloudFormation テンプレート をご確認ください。 製品の対象領域をマスクする 一般的には、配置したいオブジェクトの画像と、オブジェクトの輪郭を描いたマスクを用意する必要があります。 これは Amazon SageMaker Ground Truth などのツールを使用して行うことができます。あるいは、オブジェクトが画像の真ん中にあると仮定すれば、Segment Anything Models（SAM）などの AI ツールを使用してオブジェクトを自動的にセグメント化することもできます。 SAM を使用してマスク画像を生成する 高度な生成系 AI 技術である SAM を使用すると、画像内のさまざまなオブジェクトに高品質のマスク画像を簡単に生成できます。 SAM は、広範なデータセットでトレーニングされた深層学習のモデルを使用して、対象オブジェクトを正確に識別してセグメント化し、正確な境界とピクセルレベルのマスク画像を提供します。 この画期的なテクノロジーは、手作業でマスク画像を作成するという時間と労力のかかる作業を自動化することで、画像処理のワークフローを革新します。 SAM により、企業や個人はオブジェクト認識、画像編集、コンピュータービジョンタスクなどのためのマスク画像を迅速に生成できるようになり、視覚的な分析と操作の可能性が広がります。 SAM モデルを SageMaker エンドポイントでホストする ノートブック 1_HostGenaiModels.ipynb を使用して SageMaker エンドポイントを作成し、SAM モデルをホストします。 inference_sam.py 内の推論コードを使用し、それを code.tar.gz ファイルにパッケージ化し、それを使用して SageMaker エンドポイントを作成します。 このコードは SAM モデルをダウンロードし、エンドポイントにホストし、推論を実行して出力を生成するためのエントリポイントを提供します。 SAM_ENDPOINT_NAME = 'sam-pytorch-' + str(datetime.utcnow().strftime('%Y-%m-%d-%H-%M-%S-%f')) prefix_sam = "SAM/demo-custom-endpoint" model_data_sam = s3.S3Uploader.upload("code.tar.gz", f's3://{bucket}/{prefix_sam}') model_sam = PyTorchModel(entry_point='inference_sam.py', model_data=model_data_sam, framework_version='1.12', py_version='py38', role=role, env={'TS_MAX_RESPONSE_SIZE':'2000000000', 'SAGEMAKER_MODEL_SERVER_TIMEOUT' : '300'}, sagemaker_session=sess, name='model-'+SAM_ENDPOINT_NAME) predictor_sam = model_sam.deploy(initial_instance_count=1, instance_type=INSTANCE_TYPE, deserializers=JSONDeserializer(), endpoint_name=SAM_ENDPOINT_NAME) SAM モデルを呼び出してマスク画像を生成する 次のコードは 2_GenerateInPaintingImages.ipynb ノートブックの一部で、エンドポイントを実行して結果を生成するために使用されます。 raw_image = Image.open("images/speaker.png").convert("RGB") predictor_sam = PyTorchPredictor(endpoint_name=SAM_ENDPOINT_NAME, deserializer=JSONDeserializer()) output_array = predictor_sam.predict(raw_image, initial_args={'Accept': 'application/json'}) mask_image = Image.fromarray(np.array(output_array).astype(np.uint8)) # save the mask image using PIL Image mask_image.save('images/speaker_mask.png') 次の図は、製品画像から取得したマスク画像を示しています。 インペインティングを使用して画像を生成する SAM によって生成されたマスク画像を使ったインペインティングの力と、ユーザーのプロンプトを組み合わせることで、素晴らしい生成画像を作成できます。 インペインティングは高度な生成系 AI 技術を利用して、画像の欠けている部分やマスク画像されている部分をインテリジェントに埋め、周囲のコンテンツとシームレスに融合します。 SAM が生成したマスク画像をガイダンスとし、ユーザーのプロンプトをクリエイティブな入力として使用することで、インペインティングアルゴリズムは視覚的に一貫した文脈に適したコンテンツを生成し、とても美しくパーソナライズされた画像を作成できます。 このテクノロジーの融合により、クリエイティブな可能性が無限に広がり、ユーザーは自分のビジョンを鮮やかで魅力的なビジュアルストーリーに変えることができます。 SageMaker エンドポイントで Stable Diffusion のインペインティングモデルをホストする 2.1 と同様に、ノートブック 1_HostGenaiModels.ipynb を使用して SageMaker エンドポイントを作成し、Stable Diffusion のインペインティングモデルをホストしています。 inference_inpainting.py 内の推論コードを使用し、それを code.tar.gz ファイルにパッケージ化し、それを使用して SageMaker エンドポイントを作成します。 このコードは Stable Diffusion インペインティングモデルをダウンロードし、エンドポイントでホストし、推論を実行して出力を生成するためのエントリポイントを提供します。 INPAINTING_ENDPOINT_NAME = 'inpainting-pytorch-' + str(datetime.utcnow().strftime('%Y-%m-%d-%H-%M-%S-%f')) prefix_inpainting = "InPainting/demo-custom-endpoint" model_data_inpainting = s3.S3Uploader.upload("code.tar.gz", f"s3://{bucket}/{prefix_inpainting}") model_inpainting = PyTorchModel(entry_point='inference_inpainting.py', model_data=model_data_inpainting, framework_version='1.12', py_version='py38', role=role, env={'TS_MAX_RESPONSE_SIZE':'2000000000', 'SAGEMAKER_MODEL_SERVER_TIMEOUT' : '300'}, sagemaker_session=sess, name='model-'+INPAINTING_ENDPOINT_NAME) predictor_inpainting = model_inpainting.deploy(initial_instance_count=1, instance_type=INSTANCE_TYPE, serializer=JSONSerializer(), deserializers=JSONDeserializer(), endpoint_name=INPAINTING_ENDPOINT_NAME, volume_size=128) Stable Diffusion のインペインティングモデルを呼び出し、新しい画像を生成する SAM モデルを呼び出す手順と同様に、ノートブックの 2_generateInPaintingImages.ipynb を使用してエンドポイントで推論を実行し、結果を生成します。 raw_image = Image.open("images/speaker.png").convert("RGB") mask_image = Image.open('images/speaker_mask.png').convert('RGB') prompt_fr = "table and chair with books" prompt_bg = "window and couch, table" negative_prompt = "longbody, lowres, bad anatomy, bad hands, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, letters" inputs = {} inputs["image"] = np.array(raw_image) inputs["mask"] = np.array(mask_image) inputs["prompt_fr"] = prompt_fr inputs["prompt_bg"] = prompt_bg inputs["negative_prompt"] = negative_prompt predictor_inpainting = PyTorchPredictor(endpoint_name=INPAINTING_ENDPOINT_NAME, serializer=JSONSerializer(), deserializer=JSONDeserializer()) output_array = predictor_inpainting.predict(inputs, initial_args={'Accept': 'application/json'}) gai_image = Image.fromarray(np.array(output_array[0]).astype(np.uint8)) gai_background = Image.fromarray(np.array(output_array[1]).astype(np.uint8)) gai_mask = Image.fromarray(np.array(output_array[2]).astype(np.uint8)) post_image = Image.fromarray(np.array(output_array[3]).astype(np.uint8)) # save the generated image using PIL Image post_image.save('images/speaker_generated.png') 次の図は、調整されたマスク画像、生成された背景画像、生成された製品画像、および後処理後の画像を示しています。 生成された商品画像は、次のプロンプトを使用します。 背景生成 — “chair, couch, window, indoor”（日本語訳：「椅子、ソファ、窓、屋内」） インペインティング — “besides books”（日本語訳：「本以外」） クリーンアップ この記事では、コストの大部分を占める 2 つの GPU 対応の SageMaker エンドポイントを使用します。 これらのエンドポイントは、使用していないときに余分なコストがかからないように、オフにする必要があります。エンドポイントのクリーンアップに役立つノートブック 3_CleanUp.ipynb を用意しています。 また、SageMaker ノートブックを使用してモデルをホストし、推論を実行します。 そのため、ノートブックインスタンスが使用されていない場合は停止することをお勧めします。 まとめ 生成系 AI モデルは通常、効率的に実行するには特定のリソースを必要とする大規模な ML モデルです。 この投稿では、広告のユースケースを使用して、SageMakerエンドポイントが、テキストから画像への基盤モデルである Stable Diffusion などの生成系 AI モデルをホストするためのスケーラブルで管理された環境を提供する方法を説明しました。 2 つのモデルをホストして必要に応じて実行する方法と、 1 つのエンドポイントから複数のモデルをホストする 方法を説明しました。 これにより、インフラストラクチャのプロビジョニング、スケーラビリティ、監視に関連する複雑さが解消され、組織はモデルの導入と予測の提供だけに集中してビジネス上の課題を解決できます。 SageMaker エンドポイントを使用すると、組織は統一されたインフラストラクチャ内で複数のモデルを効率的に展開および管理できるため、最適なリソース利用を実現し、運用のオーバーヘッドを削減できます。 詳細なコードは GitHub で公開されています。 このコードでは、AWS CloudFormation と AWS Cloud Development Kit (AWS CDK) を使用して SageMaker ノートブックやその他の必要なリソースを作成するプロセスを自動化する方法を示しています。 著者について Fabian Benitez-Quiroz は AWS プロフェッショナルサービスの IoT エッジデータサイエンティストです。 オハイオ州立大学でコンピュータービジョンとパターン認識の博士号を取得しています。 Fabian は、さまざまな業界のお客様が IoT デバイスやクラウド上で低レイテンシーで機械学習モデルを実行できるよう支援しています。   Romil Shah は AWS プロフェッショナルサービスのシニアデータサイエンティストです。 Romilは、コンピュータービジョン、機械学習、IoT エッジデバイスにおいて6年以上の業界経験があります。 彼は、顧客がエッジデバイスやクラウド向けに機械学習モデルを最適化して展開できるよう支援しています。 顧客と協力して、基盤モデルを最適化および展開するための戦略を策定しています。   Han Man は、カリフォルニア州サンディエゴを拠点とする AWS プロフェッショナルサービスのシニアデータサイエンスおよび機械学習マネージャーです。 ノースウェスタン大学で工学の博士号を取得し、経営コンサルタントとして製造、ファイナンスサービス、エネルギーの分野でクライアントにアドバイスを提供した経験が数年あります。 現在、彼はさまざまな業種の主要顧客と熱心に協力して、AWS で ML と生成系ソリューションを開発および実装しています。   翻訳はソリューションアーキテクトの柏村が担当しました。原文は こちら です。

ビジネスアナリストであれば、顧客の行動を理解することは、おそらく最も重要なことの1つです。顧客の購入決定の背後にある理由とメカニズムを理解することで、収益の拡大を促進できます。一方で、顧客の喪失 (一般に顧客解約と呼ばれる) は常にリスクを伴います。顧客が離脱する理由についてのインサイトを得ることも、利益と収益を維持するためにも同様に重要です。 機械学習 (ML) は貴重なインサイトを提供できますが、 Amazon SageMaker Canvas が導入されるまでは、顧客離れ予測モデルを構築するには ML の専門家が必要でした。 SageMaker Canvas はローコード/ノーコードのマネージドサービスで、コードを 1 行も記述しなくても多くのビジネス上の問題を解決できる ML モデルを作成できます。また、まるでデータサイエンティストであるかのように、高度な指標を使用してモデルを評価できます。 前提条件 この記事で説明されているタスクのすべてまたは一部を実装する場合は、SageMaker Canvas にアクセスできる AWS アカウントが必要です。SageMaker Canvas、顧客離れ予測モデル、およびデータセットに関する基本事項については、「 Amazon SageMaker Canvas を使用したコーディング不要の機械学習による顧客離れの予測 」を参照してください。 モデル性能評価の概要 一般的なガイドラインとして、モデルのパフォーマンスを評価する必要がある場合、新しいデータを見たときにモデルが結果をどれだけうまく予測できるかを測定することです。この予測は推論と呼ばれます。まず、既存のデータを使用してモデルをトレーニングし、次に、まだ見ていないデータに基づいて結果を予測するようにモデルを呼び出します。モデルがこの結果をどの程度正確に予測するかが、モデルのパフォーマンスを理解するうえで重要です。 モデルが新しいデータを見ていないとしたら、予測が良いか悪いかをどうやって知ることができるでしょうか？つまり、結果が既に分かっている過去のデータを実際に使用して、その値をモデルの予測値と比較するというものです。これは、過去のトレーニングデータの一部を取っておき、モデルが予測した値と比較できるようにすることで可能になります。 顧客離れ（カテゴリ分類の問題）の例では、多くの属性（各レコードに 1 つ）を持つ顧客を説明する履歴データセットから始めます。Churn と呼ばれる属性の 1 つは True でも False でもかまいません。これは、顧客がサービスを辞めたかどうかを表すものです。モデルの精度を評価するために、このデータセットを分割し、一方の部分 (トレーニングデータセット) を使用してモデルをトレーニングし、もう一方の部分 (テストデータセット) の結果を予測するようにモデルを呼び出します (顧客を離脱する顧客かそうでないかに分類)。次に、モデルの予測をテストデータセットに含まれる正解データと比較します。 高度なメトリクスの解釈 このセクションでは、モデルのパフォーマンスを理解するのに役立つ SageMaker Canvas の高度なメトリクスについて説明します。 混同行列 SageMaker Canvas は混同行列を使用して、モデルが予測を正しく生成することを視覚化するのに役立ちます。混同行列では、予測値を実際の過去 (既知の) 値と比較するように結果が整理されます。次の例は、 positive と negative を予測する 2 つのカテゴリの予測モデルで混同行列がどのように機能するかを説明しています。 True positive — 正解ラベルがpositiveの場合、モデルはpositiveを正しく予測しました True negative — 正解ラベルがnegative場合、モデルはnegativeを正しく予測しました。 False positive — 正解ラベルがnegativeの場合、モデルは誤ってpositiveと予測しました。 False negative — 正解ラベルがpositiveの場合、モデルは誤ってnegativeと予測しました。 次の画像は、2 つのカテゴリの混同行列の例です。この顧客離れ予測モデルでは、実際の値はテストデータセットから得られ、予測値はモデルに問い合わせて得られます。 正解率 正解率は、テストデータセットのすべての行またはサンプルのうち、正しい予測のパーセンテージです。True と予測された真のサンプルと、False と正しく予測された偽サンプルを、データセット内のサンプルの総数で割ったものです。 モデルがどのくらいの割合で正しく予測したかわかるため、理解しておくべき最も重要な指標の1つですが、場合によっては誤解を招く可能性があります。例えば: クラスの不均衡 — データセット内のクラスが均等に分布していない（あるクラスのサンプル数が不均衡で、他のクラスのサンプル数が非常に少ない）場合、正解率は誤解を招く可能性があります。このような場合、データごとに過半数のクラスを予測するだけのモデルでも、高い正解率となってしまいます。 コスト考慮型の分類 — アプリケーションによっては、クラスごとに誤分類のコストが異なる場合があります。たとえば、ある薬物が病状を悪化させる可能性があるかどうかを予測する場合、偽陰性（たとえば、その薬物が実際にはその薬物を使用すると悪化するにもかかわらず、悪化しない可能性を予測）は、偽陽性（たとえば、実際には悪化しないのにその薬を使用することで悪化する可能性があると予測すること）よりもコストがかかる可能性があります。 精度（Precision）、再現率（recall）、F1スコア（F1 score） 精度は、予測されるすべての陽性（TP+FP）に対する真陽性（TP）の割合です。陽性の予測のうち、実際に正しかったものの割合を測定します。 再現率は、実際の陽性（TP + FN）すべてに対する真陽性（TP）の割合です。モデルによって陽性と正しく予測された陽性例の割合を測定します。 F1 スコアは、精度と再現率を組み合わせたもので、両者のトレードオフのバランスを取った単一のスコアになります。精度と再現率の調和平均として定義されています。 F1 score = 2 * (精度 * 再現率) / (精度 + 再現率) F1のスコアの範囲は0〜1で、スコアが高いほどパフォーマンスが優れていることを示します。F1 スコアが 1 の場合は、モデルが完全な精度と完全な再現率の両方を達成したことを示し、スコアが 0 の場合は、モデルの予測が完全に誤っていることを示します。 F1スコアは、モデルのパフォーマンスをバランスよく評価します。精度と再現率を考慮して、陽性事例を正しく分類し、偽陽性と偽陰性を回避するモデルの能力を反映した、より有益な評価指標となります。 たとえば、医療診断、不正検知、感情分析では、F1が特に重要です。医療診断では、特定の疾患または状態の存在を正確に特定することが重要であり、偽陰性または偽陽性は重大な結果をもたらす可能性があります。F1スコアでは、精度（陽性症例を正しく特定する能力）と再現率（すべての陽性症例を発見する能力）の両方が考慮され、疾患の検出におけるモデルの性能をバランスよく評価できます。同様に、実際の不正事例の数が非不正事例と比較して比較的少ない不正検出（不均衡なクラス）では、真陰性の事例の数が多いため、精度だけでは誤解を招く可能性があります。F1スコアは、精度と再現率の両方を考慮して、モデルが不正なケースと非不正的なケースの両方を検出する能力を包括的に測定します。また、感情分析では、データセットのバランスが取れていないと、ポジティブな感情クラスのインスタンスを分類する際のモデルのパフォーマンスが精度に正確に反映されない可能性があります。 AUC (area under the curve) AUC メトリクスは、すべての分類閾値においてポジティブクラスとネガティブクラスを区別する二項分類モデルの能力を評価します。閾値とは、モデルが 2 つのクラス間の判断に使用する値で、サンプルがクラスに含まれる確率をバイナリ判定に変換します。AUC を計算するには、さまざまな閾値設定にわたって真陽性率 (TPR) と偽陽性率 (FPR) をプロットします。TPR は実際のすべての陽性に対する真陽性の割合を測定し、FPR は実際の陰性すべてのうちで偽陽性の割合を測定します。結果として得られる曲線は、受信者動作特性 (ROC) 曲線と呼ばれ、さまざまな閾値設定での TPR と FPR を視覚的に表しています。AUC 値は 0 ～ 1 の範囲で、ROC 曲線の下の領域を表します。AUC 値が高いほどパフォーマンスが良く、分類モデルが完璧であれば AUC は 1 になります。 次のグラフは、TPR を Y 軸、FPR を X 軸とした ROC 曲線を示しています。曲線がプロットの左上隅に近づくほど、モデルはデータをカテゴリに分類しやすくなります。 わかりやすくするために、例を見てみましょう。不正検出モデルについて考えてみましょう。通常、これらのモデルは不均衡なデータセットからトレーニングされます。これは、通常、データセット内のほとんどすべてのトランザクションが不正ではなく、不正とラベル付けされたトランザクションはごくわずかであるためです。この場合、精度だけではモデルのパフォーマンスを十分に捉えられない可能性があります。不正ではないケースの多さに大きく影響され、誤解を招くような高い精度スコアにつながるからです。 この場合、AUCは、モデルが不正な取引と不正でない取引を区別する能力を包括的に評価できるため、モデルのパフォーマンスを評価するためのより良い指標となるでしょう。さまざまな分類閾値における真陽性率と偽陽性率のトレードオフを考慮に入れて、より微妙な評価ができます。 F1スコアと同様に、AUCはデータセットのバランスが崩れている場合に特に役立ちます。TPR と FPR のトレードオフを測定し、分布に関係なくモデルが 2 つのクラスをどれだけうまく区別できるかを示します。つまり、一方のクラスが他方のクラスよりも大幅に小さくても、ROC 曲線では両方のクラスを同等に考慮することで、モデルの性能をバランスよく評価できるということです。 その他の主要トピック ML モデルのパフォーマンスを評価および改善するために利用できる重要なツールは、高度なメトリクスだけではありません。データ準備、特徴量エンジニアリング、特徴量重要度分析は、モデル構築に不可欠な手法です。これらのアクティビティは、生データから有意義なインサイトを抽出し、モデルのパフォーマンスを向上させる上で重要な役割を果たし、より堅牢で洞察に富んだ結果につながります。 データ準備と特徴量エンジニアリング 特徴量エンジニアリングは、生データから新しい変数 (機能) を選択、変換、作成するプロセスであり、ML モデルのパフォーマンスを向上させる上で重要な役割を果たします。入手可能なデータから最も関連性の高い変数や特徴量を選択するには、モデルの予測に寄与しない無関係な特徴量や冗長な特徴量を削除する必要があります。データの特徴量を適切な形式に変換するには、スケーリング、正規化、欠損値の処理が含まれます。最後に、既存のデータから新しい機能を作成するには、数学的な変換、さまざまな機能の組み合わせや相互作用、またはドメイン固有の知識に基づく新しい機能の作成を行います。 特徴量重要度分析 SageMaker Canvas は、データセット内の各列がモデルに与える影響を説明する特徴量重要度分析を生成します。予測を生成すると、列の影響を確認して、各予測に最も大きな影響を与える列を特定できます。これにより、どの特徴量を最終モデルに含めるべきか、どの特徴量を破棄すべきかについてのインサイトが得られます。列への影響度は、ある列が他の列と比較して予測を行う際にどの程度重要かを示すパーセンテージスコアです。列への影響が 25% の場合、Canvasは予測結果への影響を、その列が 25%、その他の列が 75% と重み付けします。 モデルの精度を向上させるためのアプローチ モデルの精度を向上させる方法は複数ありますが、データサイエンティストと機械学習担当者は通常、前述のツールとメトリクスを使用して、このセクションで説明した2つのアプローチのうちのどちらか1つを使用します。 モデル中心のアプローチ このアプローチでは、データは常に同じままで、望ましい結果が得られるようにモデルを繰り返し改善するために使用されます。このアプローチで使用されるツールには以下が含まれます。 関連する複数の機械学習アルゴリズムを試してみる。 アルゴリズムとハイパーパラメーターのチューニングと最適化。 さまざまなモデルアンサンブル法。 事前トレーニング済みモデルの使用 (SageMaker には ML 担当者に役立つさまざまな 組み込みモデルや事前トレーニング済みモデル が用意されています)。 AutoML は SageMaker Canvas が舞台裏で ( Amazon SageMaker Autopilot を使用して) 行っていることであり、上記のすべてを網羅しています。 データ中心のアプローチ このアプローチでは、データ準備、データ品質の向上、およびパフォーマンスの向上を目的としたデータの反復修正に重点が置かれています。 モデルのトレーニングに使用したデータセットの統計情報の調査 (探索的データ分析 (EDA) とも呼ばれます)。 データ品質の向上 (データクリーニング、欠損値の補完、外れ値の検出と管理)。 特徴量の選択。 特徴量エンジニアリング。 データ拡張。 Canvasにおけるモデルパフォーマンスの向上 まず、データ中心のアプローチから始めます。モデルプレビュー機能を使用して最初の EDA を実行します。これにより、データ拡張、新しいベースラインの生成、そして最終的に標準ビルド機能を使用したモデル中心のアプローチによる最適なモデルの作成に使用できるベースラインが得られます。 この記事では通信携帯電話会社の 合成データセット を使用します。このサンプルデータセットには 5,000 件のレコードが含まれており、各レコードには 21 の属性を使用して顧客プロファイルを記述しています。詳細については、「 Amazon SageMaker Canvas を使用したコーディング不要の機械学習による顧客離れの予測 」を参照してください。 データ中心のアプローチによるモデルプレビュー 最初のステップとして、データセットを開き、予測する列である Churn? を選択します。そして、 Preview model を選択してプレビューモデルを生成します。 Preview model ペイン には、プレビューモデルの準備が整うまでの進捗状況が表示されます。 モデルの準備が整うと、SageMaker Canvas は特徴量重要度分析を生成します。 最後に、モデルプレビューの作成が完了すると、 Preview model ペイン にはモデルへの影響を含む列のリストが表示されます。これらの情報は、その特徴量が予測にどの程度関連しているかを理解するのに役立ちます。 Column impact は、ある列が他の列と比較して予測を行う際にどの程度重視されているかを示すパーセンテージスコアです。次の例では、「Night Calls」列について、SageMaker Canvas はその列について 4.04%、その他の列では 95.9% と重み付けしています。値が大きいほど、影響も大きくなります。 ご覧のとおり、プレビューモデルの精度は 95.6% です。データ中心のアプローチを使用してモデルのパフォーマンスを改善してみましょう。データ準備を行い、特徴量エンジニアリングの手法を使用してパフォーマンスを向上させます。 次のスクリーンショットに示すように、「Phone」列と「State」列が予測に与える影響は他の列に比べてはるかに小さいことがわかります。そのため、この情報を次のフェーズであるデータ準備のインプットとして使用します。 SageMaker Canvas には ML データ変換が用意されており、これを使用してデータをクレンジング、変換、モデル構築の準備を行うことができます。これらの変換はコードを書くことなくデータセットに使用でき、モデルレシピに追加されます。モデルレシピとは、モデル構築前にデータに対して実行されたデータ準備の記録です。 使用するデータ変換は、モデルを構築するときに入力データを変更するだけで、データセットや元のデータソースは変更しないことに注意してください。 SageMaker Canvas には、構築用のデータを準備するための以下の変換方法が用意されています。 日時抽出 列削除 行フィルター 関数と演算子 行の管理 列名変更 行削除 値の置換 時系列データの再サンプリング まず、予測にほとんど影響がないことがわかった列を削除することから始めましょう。 例えば、このデータセットでは、電話番号はアカウント番号と同等です。他のアカウントが解約される可能性を予測する上では役に立たず、有害ですらあります。同様に、顧客の状態はモデルにあまり影響しません。Phone 列と State 列を削除して、 Column name の下にあるチェックボックスの選択を解除しましょう。 次に、追加のデータ変換と特徴量エンジニアリングを実行してみましょう。 例えば、以前の分析では、顧客への請求金額が解約に直接影響することがわかりました。そこで、日中、夜、深夜、の国際電話の「料金」、「通話時間」、「通話回数」を組み合わせて、お客様への合計請求額を計算する新しい列を作成してみましょう。そのためには、SageMaker Canvas のカスタム数式を使用します。 まず Functions を選択し、次に数式のテキストボックスに次のテキストを追加します。 (Day Calls*Day Charge*Day Mins)+(Eve Calls*Eve Charge*Eve Mins)+(Night Calls*Night Charge*Night Mins)+(Intl Calls*Intl Charge*Intl Mins) 新しい列に「合計料金」など適切な名前 を付け、プレビューが生成されたら Add を選択します。これで、モデルレシピは次のスクリーンショットのようになるはずです。 このデータ準備が完了したら、新しいプレビューモデルをトレーニングして、モデルが改善されたかどうかを確認します。もう一度 Preview model を選択すると、右下のペインに進行状況が表示されます。 トレーニングが終了すると、予測精度の再計算が行われ、新しい  Column impact も作成されます。 最後に、プロセス全体が完了すると、前に見たのと同じペインが、新しいプレビューモデルの精度で表示されます。モデルの精度が 0.4% (95.6% から 96% に) 向上したことがわかります。 MLはモデルのトレーニングプロセスにはある程度の確率性を導入しており、ビルドごとに異なる結果につながる可能性があるため、本記事の画像の数値は実際の数値とは異なる場合があります。 モデル中心のアプローチによるモデル作成 Canvasには、モデルを作成するための2つのオプションがあります。 Standard build – 速度を犠牲にして精度を高める最適化されたプロセスから最適なモデルを構築します。Auto-ML を使用して、モデルの選択、ML のユースケースに関連するさまざまなアルゴリズムの試行、ハイパーパラメータの調整、モデルの説明可能性レポートの作成など、ML のさまざまなタスクを自動化します。 Quick build – Standard build に比べてわずかな時間で単純なモデルを構築できますが、精度はスピードと引き換えられます。Quick Build は、データの変更がモデルの精度に与える影響をより迅速に把握するために反復試行を行う場合に役立ちます。 引き続き Standard build アプローチを使用してみましょう。 Standard build 前述したように、Standard build は、精度を最大化するために最適化されたプロセスから最適なモデルを構築します。 顧客離れ予測モデルのビルドプロセスには約45分かかります。この間、Canvasは何百もの候補パイプラインをテストし、最適なモデルを選択します。次のスクリーンショットでは、予想されるビルド時間と進行状況を確認できます。 標準のビルドプロセスでは、ML モデルによってモデルの精度が 96.903% に向上しました。これは大幅な改善です。 advanced metrics を見る Analyze タブを使用してモデルを調べてみましょう。 Scoring タブで Advanced metrics を選択します。 このページでは、F1スコア、正解率、精度、再現率、AUCなどの高度なメトリクスと混同行列を組み合わせて表示します。 予測の生成 メトリクスが適切に表示されたので、 Predict タブでバッチ予測または単一 (リアルタイム) 予測のいずれかでインタラクティブな予測を実行できます。 次の 2 つの選択肢があります。 このモデルを使用して、バッチ予測または単一予測を実行します。 モデルを Amazon SageMaker Studio に送信して、データサイエンティストと共有します。 後片付け 記事の作業を実施後、 セッション料金 が発生しないようにするには、SageMaker Canvas からログアウトしてください。 まとめ SageMaker Canvas には、コーディングや専門的なデータサイエンスや ML の専門知識を必要とせずにモデルの構築と精度を評価してパフォーマンスを向上させることができる強力なツールが用意されています。顧客離れ予測モデルを作成した例で見てきたように、これらのツールをデータ中心のアプローチと高度なメトリクスを使用するモデル中心のアプローチの両方と組み合わせることで、ビジネスアナリストは予測モデルを作成して評価できます。また、ビジュアルインターフェイスを使用すると、正確な ML 予測を自分で生成できます。参考文献に目を通し、これらのアプローチが他の種類のML問題にも適用可能であることを確認してみてください。 参考文献 Predict customer churn with no-code machine learning using Amazon SageMaker Canvas Build, Share, Deploy: how business analysts and data scientists achieve faster time-to-market using no-code ML and Amazon SageMaker Canvas Customizing and reusing models generated by Amazon SageMaker Autopilot Amazon SageMaker Canvas Immersion Day Workshop Manage AutoML workflows with AWS Step Functions and AutoGluon on Amazon SageMaker 著者について Marcos は、米国フロリダ州を拠点とする AWS シニア機械学習ソリューションアーキテクトです。その職務では、米国のスタートアップ企業のクラウド戦略を導き、支援し、リスクの高い問題に対処し、機械学習ワークロードを最適化する方法に関するガイダンスを提供しています。クラウドソリューション開発、機械学習、ソフトウェア開発、データセンターインフラストラクチャなど、テクノロジーに関する 25 年以上の経験があります。 Indrajit は AWS エンタープライズシニアソリューションアーキテクトです。彼の役職では、クラウドの導入を通じて顧客がビジネス上の成果を達成できるよう支援しています。マイクロサービス、サーバーレス、API、イベント駆動型パターンに基づいた最新のアプリケーションアーキテクチャを設計しています。DataOps と MLOps のプラクティスとソリューションを採用することで、顧客と協力してデータ分析と機械学習の目標を実現できるよう努めています。Indrajit は、サミットや ASEAN ワークショップなどの AWS の公開イベントで定期的に講演を行い、いくつかの AWS ブログ記事を公開しているほか、AWS でのデータや機械学習に焦点を当てた顧客向けの技術ワークショップも企画しています。 翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です。

日本政府は成長と分配の好循環を目指す「新しい資本主義」の実現に向けて、社会課題の解決に取り組むスタートアップがそのドライバーであると捉えスタートアップへの支援を強化し、持続可能な社会を目指しています。さらに、スタートアップ育成5か年計画の中では、グローバル市場での優位性という観点から非言語技術の創出を目指し研究開発型スタートアップへの支援に関する予算が多く割り当てられており、その成長に期待が寄せられています。 アマゾン ウェブ サービス ジャパン合同会社（以下、AWSジャパン）は、クラウドを始めとした新たなデジタルテクノロジーを社会実装するうえで欠かせないのがスタートアップであると考え、過去10年にわたり数千におよぶ日本のスタートアップを支援してきました。その中でも研究開発型のスタートアップ支援に関連して、AWSジャパンは2022年9月につくば市と研究開発型スタートアップの成長加速に向けた連携を発表し支援するなど、より良い社会と市民生活の実現に貢献すべく、様々な関係団体との連携を図っています。 慶應義塾大学は、多様な社会課題を解決できるスタートアップを多く輩出するために、2026年までに大学発のスタートアップの設立数を300社とすることを目標とし、経済産業省の2022年度調査で大学別のスタートアップ企業数が全国３位となるなど、育成を強化しています。 このような背景からAWSジャパンは、本日、 慶應義塾大学イノベーション推進本部 とスタートアップの支援について連携して取り組んでいくことを発表しました。この連携により、社会課題の解決に挑戦する慶應義塾大学発スタートアップは、コンピューティングに関する支援を受けることで、AWSの人工知能 (AI) や機械学習 (ML)といった最新のテクノロジーの活用が容易になるとともに、起業やその後の成長をさらに加速していくことが期待されます。AWSジャパンは、慶應義塾大学とともに、国内の産業活性化の支援のみならず、グローバルの社会課題解決の支援に向けて取り組んでいきます。 この連携は、 慶應義塾大学関連スタートアップ や起業を目指す研究者に対する多角的な支援体制の構築を特徴としており、具体的には、主にAWSジャパンが提供する以下の4つの支援から成り立っています。 計算リソース提供 ： AWS Activate※プログラムを活用し、慶應義塾大学関連スタートアップに対して、最大$5,000分のAWS利用バウチャーや他のSaaSのディスカウントを提供します。 技術・人材支援 ： AWSエンジニアによる個別の技術相談会を開催し、CTO人材の学習やネットワーキングの機会を提供します。これには、オンサイトのワークショップも含まれます。 情報提供 ： セキュリティ対策、データ保護法規、IT運用コスト最適化、AI/MLの最新サービスなどに関する情報発信を行います。これらはセミナーや勉強会の形で実施します。 起業文化醸成 ： セミナーやイベントを通じて起業文化を醸成します。具体的には、AWSが企画するアントレ教育関連イベントへの紹介や、補助金や事業化支援の制度活用に関する情報提供を行います。 慶應義塾大学 イノベーション推進本部 統括本部長 天谷 雅行のコメント 「全社会の先導者」という慶應義塾の目的の下、研究・教育成果を基にしたスタートアップ創出に力を入れる本学にとって、世界規模のクラウドサービスを展開するAWSジャパンとの連携は大きな意味を持つものと考えています。慶應義塾大学イノベーション推進本部は、本連携協定の下、スタートアップ・エコシステムの発展に貢献し、世界規模の課題解決ができるようなディープテック企業の成長を支援していきます。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮のコメント 慶應義塾大学イノベーション推進本部とAWSジャパンの連携は、起業を志す研究者や学生が必要とする支援を提供することで、慶應義塾大学を中心としたスタートアップコミュニティの拡大を目指すものです。この連携により大学の研究が素早く社会実装されるモデルを構築し、国内の産業活性化のみならず、グローバルの社会課題解決に貢献したいと考えます。慶應義塾大学とAWSジャパンが日本のイノベーション創出における先導者になることを期待しています。 ※AWS Activate は、スタートアップ企業のジャーニーでのあらゆるステップを簡素化するために設計された無料のツール、リソース、およびコンテンツを、ふさわしいスタートアップ企業に提供するものです。メンバーは登録後すぐに、AWS が厳選した、ビジネスおよび技術的なニーズに関するエキスパートのヒント、トレーニングとサポート、事前構築済みのインフラストラクチャテンプレートなどの特典を受け取ることができます。

このブログ記事では、スケーラブルで回復力のある不動産リースと検索のためのイベント駆動型サーバーレスソリューションを構築する方法を紹介します。このソリューションは、不動産投資信託 (REIT) の先駆者である AvalonBay Communities, Inc. 向けに開発されました。このソリューションにより以下が可能になります。 1 日あたり 150,000 件以上のマルチパラメータ検索 1 か月あたり 3,500 件以上のリース申請への対応と 85,000 件の家賃支払い処理 AvalonBay はエクイティ REIT です。同社は、米国の主要市場でアパートの開発、再開発、買収、管理を行ってきた長い実績があり、革新的なテクノロジーソリューションを使用して顧客に長期的な価値をもたらしています。AvalonBay はデータ主導型のインサイトがビジネスの成長に貢献することを理解していました。しかし、不動産から不動産管理システム、財務システム、会計システムまで、複数のデータセット間の複雑な相互依存関係を管理するには、新しいソリューションが必要であることに気づきました。 課題 AvalonBay は、2022 年 9 月 30 日現在、12 の州とワシントンD.C. の 88,405 戸の集合住宅を含む 293 のアパートコミュニティを直接的、間接的に保有しています。このうち 18 のコミュニティは開発中、 1 つは再開発中でした。こうした状況は、複数の地域で、様々な基準に基づいてアパートを検索して賃貸することを検討している社内外のユーザーとって課題となりました。たとえば、特定のアメニティ、賃貸条件、家具、空室日が設定されている建物内のユニットを見つけることが必要です。 ソリューション概要 AvalonBay の申込者と居住者向けのフルマネージド型のリーシングソリューションは、アマゾンウェブサービス (AWS) 上にホストされています。このソリューションは安全で、オートスケーリングが可能で、マルチリージョンに対応しているため、リソースを効率的に使用しながら耐障害性とパフォーマンスを確保できます。 このイベント駆動型のソリューションの中では、 AvalonBay のリーシングサービスが複数の AWS リージョン上にホストされており、さまざまな地域のユーザーに対して低レイテンシーの応答を提供します。 このブログ記事では、図 1 に示す1 つのリージョン (Region East) のみでのユースケース実装に焦点を当てています。 図1 : AvalonBay リーシング処理プラットフォーム このソリューションには、会社の主要な目標を達成するために、いくつかの AWS サービスが統合されています。それぞれのアーキテクチャとその目的について見ていきましょう。 Amazon Route 53 : AvalonBay のリーシング処理ソリューションではサービス障害が継続してしまう状況は容認できません。リーシング処理は マルチ AZ アーキテクチャによって高い耐障害性を提供するだけでなく、マルチリージョンのアクティブ-アクティブ構成のアーキテクチャによって、リージョンレベルの高可用性を実現します。 レイテンシーに基づくルーティング を備えた Amazon Route 53 では、数秒以内にリクエストを別のリージョンに動的に再ルーティングできます。 Amazon API Gateway : Amazon Route 53 のレイテンシーに基づくルーティングは、複数の AWS リージョンの API ゲートウェイエンドポイントにトラフィックをルーティングするように設定されています。 Amazon Cognito ユーザープール を使用して API へのアクセスを制御するために API Gateway Authorizer が追加されています。 Provisioned Concurrency が有効化された AWS Lambda : AWS Lambda は複数のアベイラビリティーゾーンを跨いでオートスケーリングし、プライベートサブネットを介して保護されるよう設定されています。これにより、アベイラビリティーゾーン全体にわたる水平スケーリング機能、自己修復能力、耐障害性が実現します。 Provisioned Concurrency は、実行環境のセットアップによるコールドスタートを最小限に抑え、 API 呼び出しにかかる時間を大幅に短縮します。 Amazon Aurora Serverless v2 PostgreSQL 互換エディション : Amazon Aurora Serverless v2 は Amazon Aurora 用のオンデマンドの自動スケーリング設定です。リーシング処理ソリューションには、Amazon Aurora Serverless v2 PostgreSQL 互換エディションが使用されています。Amazon Aurora Global Database は 2 つのリージョンで構成されています。 us-east-1 リージョンはプライマリクラスター、 us-west-2 リージョンはセカンダリークラスターです。 計画的なフェイルオーバー、計画外のフェイルオーバーの両方に対応可能なグローバルデータベースエンドポイントの自動管理は、Amazon Route 53 プライベートホストゾーン、 Amazon EventBridge 、 AWS Lambda によって設定されています。 Amazon RDS Proxy for Aurora : Amazon RDS Proxy を使用すると、リーシングアプリケーションがデータベース接続をプールして共有できるため、スケーリング能力が向上します。また、アプリケーション接続を維持したままスタンバイデータベースインスタンスに自動接続できるので、リーシングソリューションのデータベース障害に対する耐性が高まります。 Amazon EventBridge : Amazon EventBridge は、主に次の2つの目的でソリューションをサポートします。 リーシングフローの監視 – リース申請プロセス中、このソリューションは AvalonBay 、プロパティマネジメント、ファイナンスポータル、管理業務などの外部アプリケーションで使用される様々なイベントを生成します。リーシングイベントは AWS Lambda 、 Amazon Simple Notification Service (Amazon SNS) 、外部の API エンドポイントなど、複数の宛先に対してのイベントルールが設定された Amazon EventBridge に送信されます。 Amazon Aurora Serverless v2 グローバルフェイルオーバー処理 – Amazon Aurora は、あらゆる種類のグローバルデータベースアクティビティを含むアクションやイベントをもとにイベント情報を生成します。 計画されたフェイルオーバーが実行された時 – AWS コマンドラインインターフェイス (AWS CLI) 、API 、コンソールのいずれかを介して、グローバルデータベースフェイルオーバープロセスが開始され、イベントが生成されます。 Aurora クラスターの 1 つが AWS CLI 、 API 、コンソールを使用してグローバルクラスターから削除されると、Aurora クラスターは単一のプライマリクラスターとして昇格されます。このプロセスが完了すると、イベントが生成されます。EventBridge ルールは、グローバルデータベースが管理する計画的フェイルオーバーが正常に完了した際のイベントパターンに合わせて作成されています。フェイルオーバーが完了すると完了イベントが検出され、このルールがトリガーされます。イベントルールは、グローバルデータベースのフェイルオーバー時にトリガーされる Amazon CloudFront CNAME レコードを正しい値に更新する Lambda 関数を呼び出すように設定されています。 スケーラブルな検索ソリューション リーシングの専門家は要求された情報を得るために、AvalonBay の検索ソリューションを使用して膨大な量の物件情報を簡単にスキャンできる必要があります。 Amazon OpenSearch Service を使用すると、エージェントはプロパティプロファイルやその他の資産データを生成して、一致するユニットを特定し、エンドカスタマーに迅速に対応できます。Amazon OpenSearch Service はビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現する完全にオープンソースの検索および分析エンジンです。Amazon OpenSearch Service はアプリケーション監視、ログ分析、オブザーバビリティ、ウェブサイト検索などのユースケースに採用されています。 Amazon OpenSearch Service を特徴とする AvalonBay 検索サービスのソリューションアーキテクチャを図 2 に示します。 図2 AvalonBay 検索サービスアーキテクチャ AvalonBay の検索には、キーワードと URI検索 、SQL ベースの検索、 カスタムパッケージ検索 を含んだ検索条件が必要です。これらの詳細は Amazon OpenSearch Service 開発者ガイド に記載されています。 Amazon OpenSearch は、障害が発生した OpenSearch サービスノードを自動的に検出して置き換えるため、インフラ管理に関するオーバーヘッドが軽減されます。このアーキテクチャーを段階的に詳しく見ていきましょう。 Amazon Kinesis イベントストリーム – AvalonBay コミュニティでは、アメニティ、機能、プロモーション、価格などの検索属性をニアリアルタイムで更新する必要があります。さまざまなプロデューサーによって作成されたイベントは Amazon Kinesis を通じてストリーミングされ、 Amazon OpenSearch Service に挿入、更新されます。 Amazon OpenSearch Service – Amazon OpenSearch Service はエンドツーエンドのコミュニティ検索に使用されます。マネージドサービスによってAmazon OpenSearch Service クラスターは AWS クラウドに簡単にデプロイ、運用、スケーリングすることができます。コミュニティ検索データは読み取り専用であるため、使用頻度に応じて UltraWarm ストレージ と コールドストレージ を使用します。 Amazon Simple Storage Service (S3) – さまざまなコミュニティ文書、ポリシー、画像ファイル、動画ファイルは主要な検索要素です。これらは契約上の義務により、何年にもわたって安全かつ確実に維持されなければなりません。Amazon S3 は、 高い耐久性 、 ライフサイクルルール 、さまざまな 保存管理 により、この作業を簡素化します。 まとめ この記事では、AvalonBay が AWS のサーバーレスプラットフォームを利用して、耐障害性、パフォーマンス、拡張性を損なうことなく、カスタムされたリーシングと検索ソリューションをデプロイした方法について説明しました。このソリューションはフルマネージド型で年中無休で稼働し、オンプレミスに追加の機器を用意する必要はありません。 リーシングと検索のソリューションに AWS を選択したことで、AvalonBay はコスト面でのメリットを生かしながら、動的に規模を拡大し、将来の成長需要に対応できるようになりました。さらに、AWS のサービスは世界中で利用できるため、パフォーマンス要件を満たすサービスを地理的に離れた場所にデプロイすることが可能になります。 著者について Amarpreet Kalra Amarpreet Kalra は AWS のシニアソリューションアーキテクトで、お客様と協力して AWS のベストプラクティスを使用して AWS のシステムアーキテクチャを設計しています。Amarpreet は、15 年間金融サービス向けの分散システムの設計と構築をしてきました。余暇はノースカロライナ州シャーロットで家族と静かな生活を送っています。 Dr. Ivan Panushev Dr. Ivan Panushev は AWS のエンジニアリング、建設、不動産担当プリンシパルパートナーソリューションアーキテクトです。また、米国国立建築科学研究所 (NIBS) の米国全国 BIM プログラム運営委員会のメンバーでもあります。Dr.Panushevは、ハーバード大学で工学と設計の博士号、修士号、学士号を取得しています。 Kausik Dey Kausik Dey はニュージャージー州に拠点を置く AvalonBay のソフトウェアエンジニアリング担当ディレクターです。スケーラブルで耐障害性と可用性に優れたソリューションのアーキテクチャ設計、実装に 20 年以上携わってきました。ビジネス関係者と協力してデジタルトランスフォーメーションと AWS 導入の道のりをサポートすることを楽しんでいます。彼の重点分野は、サーバーレス、アプリケーション統合、セキュリティです。余暇は旅行や読書に費やしています。 翻訳はソリューションアーキテクトの奈良が担当しました。原文は こちら です。

データマイグレーションは、組織がクラウドに移行するための重要な第一歩です。多くの場合、ビジネスクリティカルなアプリケーション、データベース、データアナリティクスワークロード、データウェアハウス、ビッグデータ、学習済みの人工知能/機械学習 (AI/ML) モデルのリフトアンドシフトが必要となります。データはさまざまなレイヤーで生成・保存されます。そのため、マイグレーションのプロセスは複雑なものとなり、データの取り込みとマイグレーションのプロセスを合理的な方法論を用いて適切に設計し、継続的なデータ転送をできるようにすることが重要です。 Globe Telecom はフィリピンの大手通信サービスプロバイダーです。フィリピン国内で最大級のモバイル、固定回線、ブロードバンドネットワークを運営しており、約 6,000 万人もの顧客を抱えています。Globe Telecom は、ウェブポータル、コンテンツ登録プラットフォーム、オンラインストア、セルフサービスアプリに AWS を利用することで、優れた顧客体験を提供しています。 この記事では、Cloudera data を Amazon Simple Storage Service (Amazon S3)へ移行した内容を含む、Globe Telecom のデータマイグレーションの道のりを紹介します。このプロジェクトでは、Globe Telecom の Enterprise Data Office (EDO) は異なる事業主体毎に分散してデータを所有していました。Globe Telecom は、7.2 PBのHadoop Distributed File System (HDFS) データを、4ヶ月以内にネットワーク経由での移行を命じられました。移行中もシステムは継続して本番稼動しており、稼働中の Cloudera からS3 バケットへデータ転送を継続することで、データを最新の状態に保ちました。Globe Telecom が保有する Cloudera のライセンスは更新期限が迫っていました。また、新しく生成されたデータがオンプレミスのストレージの容量を圧迫し、ストレージの容量上限に達する懸念があったこともあり、厳しいスケジュールでの移行が必要でした。 Globe Telecom の技術的な要求事項 Globe Telecom は生データを格納するデータレイクとして、 Amazon S3 上に集中型のデータリポジトリの構築・管理を行う必要がありました。 Amazon S3 にデータが到着すると、前処理、分析エンジンとの共有後にデータインサイトを実施する必要がありました。ビジネスユーザーはその後、Business Intelligence (BI) ツールを活用したデータの視覚化を行い、データ主導のビジネス上の意思決定に役立てています。 Globe Telecom の データマイグレーションに対する要件: Cloudera は HDFS のソース ステージングエリアを使用しない HDFS ストレージノードからのデータマイグレーションの実現 10Gb/s の帯域を持つ AWS Direct Connect を活用したオンラインデータマイグレ―ション データサイズとしては、7.2 PBあり、履歴データと新しく受信したデータから構成 総ファイル数は 10億以上 履歴データと新しいデータセットの増分同期 マイグレーション実施に必要になるオンプレミスリソースへの影響は最小限にする 自動化、モニタリング、レポーティング及びスクリプトのサポート ソリューションの評価 当初は履歴データ移行、新しく取り込んだデータの転送、及びソースとなる Cloudera システムからオープンファイル同期を実行する機能をもつベンダーの製品を検討していました。全体的な機能セットは魅力的で、Globe Telecom の主要な要件を満たしていました。しかし、ライセンス費用、インフラ要件、そして本記事で扱う内容のように大規模ケースの場合、複雑さが重くのしかかり導入を断念しました。更に概念実証(Proof of Concept, PoC )実験を行うためにソフトウェアを入手することも困難でした。 そこで、HDFS のデータを Amazon S3 へマイグレーションするために、 AWS DataSync を含む他ソリューションの評価し、 DataSync を採用しました。採用理由としては、Globe Telecom の主要な要件を満たしており、複数の DataSync エージェントを使用することによってスケールアウトアーキテクチャを構築できる柔軟性が提供されるというところでした。 PoC の間、Globe Telecom は以下のような成功基準を挙げ、各ツールに対して一連のテストを実施しています: 俊敏性 信頼性 機能性 可用性とスケーラビリティ セキュリティ サポートと将来性 コスト テストは拮抗した競争となっており、上記の要素の中で差別化可能なものは、コスト、可用性、スケーラビリティでした。最終的に DataSync の選定に影響を与えた要素としては、これらのものに加え、次のような理由がありました。 簡単なセットアップとデプロイ AWS Command Line Interface (AWS CLI)とスクリプトをサポート ソースとターゲット間の増分データ転送 単一ダッシュボードでのモニタリング タスクベースで拡張可能 Amazon Elastic Compute Cloud (Amazon EC2) 上の DataSyncエージェント シンプルな料金体系 ソリューションの概要 Globe Telecom は、DataSync を使用して 7.2PBの Cloudera データをマイグレーションするために独自のソリューションアーキテクチャを構築しました。AWS としては、低レイテンシーアクセスとパフォーマンスを向上させるためには、ソースストレージのできるだけ近くで DataSync エージェントを実行することを推奨しています。しかし、Globe Telecom がとった構成は、全ての DataSync エージェントは EC2 インスタンスとして稼働しています。これは、オンプレミスのフットプリントを無くすアプローチがとられたからです。DataSync エージェントについての詳細は、 DataSync エージェントの要件 を参照してください。 各 タスク の実行に際しては、” include filters “を適用しています。この機能は AWS DataSync が有するユニークな機能です。ソースストレージの特定フォルダをターゲットに、複数のDataSync エージェントにてデータ転送を行うことで、データ転送をスケールさせることが可能です。これにより、複数のエージェントを用いて DataSyncタスクの並列化を実現しています。PoC 実施に際してこのような準備や調査を細密に実施していく事によって、スムーズな PoC 実施を実現しています。 レジリエンスのための構成 EC2 インスタンスを Availability Zones (AZ)に分散させ、”include filters”でタスクに基づいたエージェントのグループ化を実施しています。こうすることで、HDFS データマイグレーションに際して弾力性のあるアーキテクチャを構築しています。今回の環境は、10 Gbpsの帯域が利用できるネットワークと、一貫した読み取りスループットを提供するソースストレージが存在していたこともあり、待ち時間やパフォーマンス問題は発生していません。また、エージェントごとのタスク割り当てを慎重に計画し、フィルタを使用することによって、データの取り込みの最適化が行えています。 それぞれの AZ で実行されるタスクでは、各ソース HDFS ロケーションに設定された3つの DataSync エージェントが利用されます。万が一の事態に備え追加でで 2つ、スタンバイエージェントの配備・起動を行っています。DataSync タスクはエージェント間での自動フェイルオーバー機能の提供はありません。しかしながら問題が発生したエージェントの代わりにスタンバイエージェントを利用可能です。 スケールのためのデザイン DataSync エージェントは、オンプレミスとセキュアなエンドツーエンド接続を提供するプライベート VPC エンドポイント を使用しアクティベートしました。現在のソースシステムにおいて、以下のパフォーマンスを達成しています: ソースシステム ネットワーク帯域 ネットワークスループット 読み込み IoPS Cloudera CDH 5.13.3, 370 データノード, 2 ネームノード 10 Gb/s 800 MB/s 27 K 以下のソース Cloudera ロケーションでは、フォルダに各タスクを処理する特定のエージェントを含めています。この方法で、AZ 全体で 9～12 のエージェントを使用し6～9タスクを処理しました。 データタイプ ソースディレクトリ ロケーション S3 上の送信先ロケーション 履歴データ HDFS /S2/data/ Prod S3 /s2/data タスクの並行実行により、ネットワーク利用率は 85% を実現しています。これによって、1日あたりの最大 72TB データ転送を実現しました。これは800MB/s 、約2.2TB/hとなります。 DataSync エージェントのサイジングとしては、各タスクあたり 5,000万ファイルの要件を満たすために、m5.4xlarge インスタンスとしてデプロイしています。 以下の画像は、タスクの実行と DataSync ロケーションでの “include filters” のために作成した戦略です。 マイグレーションを行っていくにあたり、最初のフェーズで移行が必要なデータセットとして、履歴データ用のHDFS ディレクトリが格納されているデータセットがありました。そのため、それらを優先対象として扱っています: 以下の画像中の s1、s2及びその配下のディレクトリ群です これらのデータセットには、6PB超の履歴データと、最初の同期フェーズ後に移行される125TBの日時の増分データで構成されています。 さらに、同一ソースロケーションとタスクフィルタを組み合わせて使用し、ファイル更新の増分の移行するタスクを実行しました。 最後に Globe Telecomの EDO のデータマイグレーションプロジェクトは、4か月という定められたプロジェクト期間内に無事完遂しました。 DataSync は俊敏性、柔軟性、セキュリティを提供し、高いパフォーマンスとより迅速で安全なデータ移動のためのスケールアウトアーキテクチャを構築しました。ビルトインされた自動化、モニタリング、単一のダッシュボードでのビュー、タスク完了レポートによりチームメンバーはデータ移行戦略に集中できています。また、データ移行コストを削減し、移行フェーズで安心感を得ることができました。DataSync のデータ整合性と検証チェックにより、移行後のデータに自信を持つことができました。これにより、分析データパイプラインを迅速に開始でき、エンドユーザーに対してさらなるデータ処理実現とデータ可視化を短納期で実現できました。AWS Cloud への HDFS データマイグレーションの効率化に DataSync が寄与しました。 この記事を読んでいいただきありがとうございます。AWS DataSyncの詳細については デモ をご覧ください。 この記事はアマゾンウェブサービスジャパンの畠泰三が翻訳しました。原文は こちら

注: この記事では、Symantec Server 中間認証局 (ICA) の更新に関する重要な発表と、今後予定されている AWS IoT Core のコントロールプレーンエンドポイントと新たにサポートされる AWS IoT Core カスタマーエンドポイントの TLS1.2 仕様への切り替えについて取り上げます。 概要 この記事では、Symantec Server の中間認証局 (ICA) の今後の変更と、 コントロールプレーンエンドポイント のデフォルトでの TLS 1.2 への切り替えについて説明します。また、 AWS IoT Core の カスタムドメイン と 設定可能なエンドポイント 機能の使用方法に関する推奨事項についても説明します。さらに、単一の信頼できるエンドポイントに接続するデバイスにクライアント側のカスタム証明書 (自己署名された証明書) を使用する方法についても説明します。これにより、パブリック CA に関連する不確実性がなくなります。 変更 #1: Symantec Server ICA の更新 お客様がデフォルトで最新のセキュリティ機能を利用できるようにするため、 AWS IoT Core のコントロールプレーンエンドポイント と新しく作成されたお客様のエンドポイントを TLS1.2 に切り替え、VeriSign Class 3 パブリックプライマリ認証機関 — G5 に基づく新しいサーバー証明書を用意します。さらに、下位互換性を維持するために、すべての既存のカスタマーエンドポイントは、現在の TLS バージョンと設定のままとします。AWS IoT Core の 設定可能なエンドポイント 機能を使用して、お客様の都合に合わせて、既存の顧客エンドポイントを TLS 1.2 または TLS 1.3 に移行することをお勧めします。 Symantec Server ICA (中間認証局) の更新 現在の Symantec Server ICA は 2023 年 10 月 31 日に有効期限が切れます。すべての Symantec Server 側証明書の発行には、更新された Symantec Server ICA が使用されます。 サーバー証明書のトラストチェーン (Symantec) 図 1.0 この変更はデータプレーンにのみ適用され、Symantec のエンドポイントにのみ適用されます。 Amazon Trust Services (ATS) エンドポイント を使用しているお客様には影響はありません。AWS では、可用性のリスクが生じるため、 証明書ピンニングを使用しないことを推奨しています 。ただし、証明書ピンニングが必要なユースケースの場合は、AWS では、中間 CA またはリーフ証明書ではなく、ATS が署名した Amazon ルート CA 1 または Amazon ルート CA 3 にピン留めすることを推奨しています。最初に Symantec のルート CA (VeriSign クラス 3 パブリックプライマリ認証局 — G5) にピン留めしていた場合は、デバイスは引き続き AWS IoT Core に接続できます。 アクション/推奨事項: 現在の Symantec Server 中間認証局 (ICA) 証明書は 10 月 31 日に期限切れとなり、VeriSign クラス 3 パブリックプライマリ認証局 (G5) に基づく新しいサーバー ICA 証明書が徐々に公開される予定です。AWS はプロセスを注意深く監視しており、互換性のないデバイスを検出したら、お客様に連絡します。デバイスの動作が変わったり、デバイスが AWS IoT Core と通信できないことに気付いた場合は、 カスタマーサポート またはテクニカルアカウントマネージャー (TAM) に連絡してください。 アプリケーションの安全性と互換性を確保するために、信頼できない Symantec Server ICA 証明書とのハードコーディングされた関連付けをすべて削除し、公的に信頼されているルート CA (ATS 署名付き Amazon ルート CA 1 や Amazon ルート CA 3 など) を使用することを強くお勧めします。 Amazon Trust Services (ATS) エンドポイントを使用してファームウェアを更新し、 ここ から証明書チェーン全体を ATS ルートと照合して検証してください。少なくとも Amazon ルート CA 1 と Amazon ルート CA 3 をデバイスに入れてください。デバイスの容量がある場合は、将来最大限の互換性を実現するために、5 つすべてをストアに入れてください。 Symantec Server 中間認証局 (ICA) 証明書にピン留めしていて、更新後に接続障害が発生した場合は、ファームウェアを更新して、Symantec ルート CA (VeriSign Class 3 パブリックプライマリ認証局 — G5) と照合して証明書チェーン全体を確認してください。この証明書は こちら から入手してください。 カスタムドメインと設定可能なエンドポイントを使用してください。 設定可能なエンドポイントを使用すると、デバイスに適用される TLS ポリシーを制御できます。繰り返しますが、新しいポリシーを使用してエンドポイントを作成し、準備が整ったらデバイスをそのエンドポイントに移動することで、段階的に制御できます。 パブリック CA を使用するモバイルアプリ用と、プライベート CA (または自己署名) 証明書を使用するデバイス専用の 2 つのエンドポイントを用意し、TLS セキュリティポリシーを十分に把握しておくことをお勧めします。 クライアント側で証明書のサイズを制限しないでください。パブリック CA では、サーバー証明書を定期的に更新する必要があります。OCSP レスポンダーの URL やその他のオプションを追加することで、サーバー証明書のサイズが時間とともに大きくなる可能性があります。今後のサーバー証明書を処理するのに十分なバッファを追加することをお勧めします。 AWS IoT Core Device Advisor を使用して、デバイスと大規模サーバー証明書との互換性を確認できます。 Amazon Trust Services (ATS) の署名付きルート CA を使用する ATS の署名付きルート CA を使用するようにデバイスを更新する手順は次のとおりです。 デバイスが現在使用しているルート CA を特定します。そのためには、デバイスが AWS IoT Core に接続したときに表示されるサーバー証明書チェーンを確認します。 AWS IoT Core のドキュメント から ATS 署名付きルート CA をダウンロードします。 ATS 署名付きルート CA をデバイスのトラストストアにインストールします。具体的な手順は、使用しているデバイスの種類によって異なります。 デバイスをテストして、ATS が署名したルート CA を使用して AWS IoT Core に接続できることを確認します。 変更 #2: TLS 設定の更新 セキュリティへの継続的な取り組みの一環として、AWS IoT Core のコントロールプレーンエンドポイントと新しく作成されたお客様のエンドポイントが、デフォルトで TLS 1.2 以上の仕様になることをお知らせします。このアップグレードにより、お客様は業界の最新のセキュリティ標準と拡張機能の恩恵を受けることができます。また、 AWS がすべての AWS サービス API エンドポイントの TLS 設定を最低バージョン TLS 1.2 に更新する 予定であることにもご留意ください。 アクション/推奨事項 コントロールプレーンのエンドポイント: TLS 1.0/1.1 を使用している場合は、これらの接続では TLS 1.2 以上を使い始める必要があります。 データプレーンエンドポイント: TLS 1.0/1.1 を使用して AWS IoT Core に接続するデバイスは引き続き通常どおり動作しますが、セキュリティの将来性を確保するために、これらのデバイスを更新して TLS 1.2 の最小バージョンに対応するようにすることをお勧めします。 エンドポイントの移行 シームレスな移行を容易にするために、既存の顧客エンドポイントを都合の良いときに TLS 1.2 または TLS 1.3 に移行できる設定可能なエンドポイントを導入しました。この柔軟性により、特定の要件とスケジュールに合わせて移行プロセスを調整できます。詳細な手順については、以前の ブログ投稿 をご覧ください。 カスタムドメインと設定可能なエンドポイントの設定 AWS IoT Core でカスタムドメインと設定可能なエンドポイントをセットアップして、サーバー証明書をより細かく制御し、データエンドポイントの動作を管理すること。詳細な手順については、以前の ブログ投稿 をご覧ください。実稼働環境にデプロイする前に、必ず構成を徹底的にテストすることを忘れないでください。 まとめ このブログ記事では、将来を見据えた IoT 導入に役立つ 2 つの重要な発表について説明しました。 Symantec Server ICA 証明書に別れを告げると同時に、これまでの貢献に感謝するとともに、より強力なセキュリティ対策の必要性を認識し、ATS 署名証明書と ATS エンドポイントの使用を推奨しています。ATS などの信頼できる認証局 (CA) の最新の SSL/TLS サーバー証明書に移行することで、高度なサイバー脅威からアプリケーションを強化し、最新のブラウザやデバイスとの互換性を確保できます。 また、AWS IoT Core のコントロールプレーンと新しく作成されたお客様のエンドポイントでは、TLS 1.0/1.1 から移行して最新の TLS 1.2 標準をデフォルト設定として採用しました。 最後に、カスタムドメインと設定可能なエンドポイントを活用して、サーバー証明書をより細かく制御し、データエンドポイントの動作を管理することをお勧めします。 よく寄せられる質問 Q1: 自分が影響を受けているかどうかはどうすればわかりますか? A: ATS サーバー証明書を使用している場合、変更はありません。Symantec Server 証明書については、デバイスの TLS 実装が ICA を固定していないことを確認してください。この場合は問題ありません。確認方法についての一般的な説明はできませんが、提案できる可能性の 1 つは、デバイスコードに組み込まれているすべての証明書を見て、2023 年に有効期限が切れる証明書があるかどうかを確認することです。または、組み込まれている証明書が ATS の Amazon ルート CA 1 と Amazon ルート CA 3、および Symantec VeriSign クラス 3 パブリックプライマリ認証局 (G5) であることを確認することもできます。 Q2: AWS IoT Core とのデバイス通信動作の変化に気付いたらどうなりますか? A: デバイスの動作が変わったり、デバイスが AWS IoT Core と通信できないことに気付いた場合は、 カスタマーサポート またはテクニカルアカウントマネージャー (TAM) に連絡してください。 ヘルプはどこで受けられますか? 質問がある場合は、 AWS サポート または担当のテクニカルアカウントマネージャ (TAM) に問い合わせるか、 AWS re: Post の AWS IoT フォーラム で新しいスレッドを開始してください。 詳細はこちら AWS IoT Core での TLS 1.2 と TLS 1.3 のサポートの利点と移行方法の詳細については、以下のドキュメントをご覧ください。 AWS IoT Core のコントロールプレーンエンドポイント AWS IoT Core のデータプレーンエンドポイント AWS IoT Core で TLS 1.3 のサポート開始 TLS 1.2 がすべての AWS API エンドポイントへの接続に必要な最小バージョンになります AWS IoT Coreでのトランスポートセキュリティ 証明書を発行して管理する AWSの自社認証局への移行に備える方法 AWS IoT Core のカスタムドメインを利用してコネクテッドデバイスを AWS に移行する Elliptic Curve Cryptography and Forward Secrecy Support in AWS IoT AWS IoT Core がお客様に提供する Symantec の認証局無効化の対応方法 (外部リンク) DigiCert ルート証明書 著者について Syed Rehan はアマゾン ウェブ サービス (AWS) のシニア IoT サイバーセキュリティスペシャリストです。ロンドンを拠点とし、AWS IoT Core Security Foundations チームで働いています。彼は世界中の顧客にサービスを提供し、セキュリティ専門家、開発者、セキュリティ意思決定者と協力して AWS IoT サービスの採用を促進しています。サイバーセキュリティ、IoT、クラウド技術に関する豊富な知識を持つ Syed は、スタートアップから大企業に至るまで、さまざまなお客様が AWS エコシステム内で安全な IoT ソリューションを構築できるよう支援しています。 この記事は Syed Rehan によって書かれた How to update changing certificate requirements with AWS IoT Core の日本語訳です。この記事はソリューションアーキテクトの岡本 晋太朗が翻訳しました。

Amazon Aurora は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。 Aurora は、従来のエンタープライズデータベースのパフォーマンスや可用性と共に、オープンソースデータベースのシンプルさとコスト効率を兼ね揃えています。 Aurora Global Database を使用すると、リレーショナルデータベースを複数のリージョンにまたがって構築する事ができます。 Global Database は、リージョンを跨いだ災害復旧が必要な場合や、セカンダリリージョンで低レイテンシな読み取りを実現する場合のユースケースに理想的な選択肢です。 Global Database は、リーダーを複数のリージョンに拡張するための優れた方法です。 2023 年 8 月、Aurora チームは、Aurora MySQL および Aurora PostgreSQL 用の新しい Global Database フェイルオーバー 機能の提供を 発表 しました。この機能は、Aurora Global Database をサポートするすべてのバージョンで利用可能です。Global Database フェイルオーバーは、リージョン間の計画外のフェイルオーバーイベントが発生した際に、Global Database クラスターをフェイルオーバーする運用オーバーヘッドを削減します。この投稿では、Aurora Global Database の Global Database フェイルオーバー機能を詳しく説明し、分散アプリケーションの障害に対する耐性を高めるため、その仕組みと活用方法を探ります。 注: 「計画的なフェイルオーバー」の用語は廃止され、今後は同じ機能を「 Global Database スイッチオーバー」と呼びます。 Aurora Global Database の概要 Global Database クラスターは、複数のリージョナル DB クラスターで構成されます。 Global Database クラスターは、サポートされているリージョンに最大 6 つのリージョナル DB クラスター（ us-east-1 と us-west-2 の両方の DB クラスタなど）を含めることができます。 Global Database トポロジーでは、1 つのリージョンのみがプライマリとなり、他のすべてのリージョンはセカンダリです。プライマリリージョンには、唯一のライター DB インスタンスが含まれており、唯一のアクティブなライターエンドポイントも含まれています。ライターエンドポイントは常にアクティブなライターノードを指します。セカンダリリージョンにもライターエンドポイントがありますが、それらは非アクティブとなることに注意してください。 各々のリージョナル DB クラスターはリーダーエンドポイントを保有しています。リーダーエンドポイントは、もしリードレプリカが存在する場合、リージョナル DB クラスタ内のリードレプリカへの読み込みトラフィックを負荷分散します。リーダーエンドポイントは、Global Database フェイルオーバー後も影響を受けません。 顧客がプライマリリージョンを変更するシナリオは 、計画されたイベント (例えば、リージョンのローテーションなど) への対応と計画外のイベント (例えば、リージョンの停止など) への対応の 2 パターンあります。「 Global Database スイッチオーバー 」 （以前は「計画的なフェイルオーバー」と呼ばれていました）は、計画的なイベントをサポートする既存の機能で、現在のプライマリリージョンからセカンダリリージョンにマネージドな方法で切り替えることができます。 Global Database スイッチオーバー は、災害復旧 (DR) テストのためにプライマリリージョンとセカンダリリージョンを切り替えるリージョナルローテーション (Follow the sun) などの計画的な操作に使用できます。 Global Database スイッチオーバー処理 は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス （AWS CLI ）、または RDS API を介して呼び出すことができます。スイッチオーバー処理の間、ユーザーが選択したセカンダリ DB クラスターがプライマリとなり、古いプライマリ DB クラスターがセカンダリの役割を引き継ぎます。Global Database スイッチオーバーでは、レプリケーションの方向も新しいプライマリリージョンから新しいセカンダリリージョンに変更されます。スイッチオーバー処理中に、古いプライマリリージョン （現在はセカンダリ)）のライターエンドポイントが非アクティブになり、新しいプライマリ DB クラスターのライターエンドポイントがアクティブなライターエンドポイントになります。エンドポイントの切り替えが発生した後、データベースユーザーとアプリケーションを再構成して、新しいエンドポイントを使用するように接続文字列を更新する必要があります。Global Database スイッチオーバーの詳細については、 Aurora のドキュメント を参照してください。 「計画外のフェイルオーバー」の課題 現在のプライマリリージョンの DB クラスターにおいて、サービスレベルの停止した場合やプライマリリージョンが完全に停止した場合、計画外のフェイルオーバーが必要になる可能性があります。 AWS のリージョナルアーキテクチャは高いレジリエンスを備えているため、このようなシナリオは非常にまれなケースである事に注意してください。しかしながら、完全に排除することもできません。従来、Aurora Global Database フェイルオーバーは、残っているセカンダリリージョン DB クラスターの 1 つを手動で切り離し、そのクラスターを手動でプライマリに昇格させることによって実現されていました。このアプローチはうまく機能しましたが、いくつかの課題もありました。 一つ目の課題は、Global Database の設定からクラスターを削除してスタンドアロンなクラスターに変換するという既存のアプローチは、既存の Global Database トポロジーに影響を与える事です。これは、古い Global Database のクラスター名が無効になったことを意味します。さらに、リージョナルデータベースの DB クラスターが分離され、残ったリージョン DB クラスタが昇格された後、アプリケーションで使用できる唯一のリージョン DB クラスターになります。つまり、別のセカンダリリージョンを追加して、新しい Global Databaseのトポロジーを手動で再作成する必要がありました。また、リージョンが再び利用可能になった際には、古いプライマリリージョンにDB クラスタを再作成し、新しい Global Database クラスターに追加する必要もありました。 Global Database フェイルオーバーのご紹介 新しい Global Database フェイルオーバー機能の公開により、リージョナルサービスの停止などの障害の際にも計画外の Aurora Global Database フェイルオーバーで管理できるようになりました。この機能は、新しい Global Database のデプロイメントで利用できだけでなく、既存の Aurora Global Database デプロイメントでも遡って利用する事が可能です。 Global Database フェイルオーバー機能を使用するため、構成変更を行う必要はありません。 Global Database フェイルオーバー は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または API を介して利用できます。お客様は、Global Database クラスターを最初に作成した複数のリージョンから残りの正常動作している 1 つのリージョンを選択し、フェイルオーバープロセスを開始することができます。例えば、Global Database が us-east-1 、 us-west-2 、および eu-east-1 リージョンで作成され、 us-west-2 でサービス停止が発生していると仮定します。このシナリオでは、Global Database フェイルオーバーは、 us-east-1 または eu-east-1 リージョンのいずれかから開始できます。 Global Database フェイルオーバーが開始されると、次の手順が実行されます。 ユーザーが選択したセカンダリ DB クラスターは、リードレプリカの 1 つをライターとして昇格させ、Global Database のトポロジーにおけるプライマリ DB クラスターの役割を引き受けます。 Global Database のトポロジーに他のセカンダリクラスターがある場合、それらは再構成されます。 Aurora Global Database サービスは、古いプライマリリージョンの可用性を引き続き監視します。利用可能になり正常になると、Aurora Global Database は、現在のプライマリリージョンの DB クラスターのスナップショットを復元することにより、このリージョンを Global Database に追加し直します。 古いプライマリリージョンが Global Database クラスターに再度追加されると、古いストレージボリュームのスナップショットの取得が試行され、成功すると、次の命名規則でスナップショットが利用可能になります。 rds:unplanned-global-failover-<cluster name>-timestamp Global Database フェイルオーバーは、Global Database のトポロジーを維持しながら、リージョナル DB クラスターを手動で昇格させる運用オーバーヘッドを削減します。フェイルオーバーが完了したら、アプリケーションの向け先を新しいプライマリ DB クラスターのライターエンドポイントに変更し、新しい DB クラスターからの読み込みと書き込みを開始できます。他の存続するセカンダリリージョンにアプリケーションとクライアントがある場合、セカンダリリージョンの DB クラスターのリーダーエンドポイントから読み込みを開始するには、セカンダリ DB クラスターが再構築されるまで待つ必要があります。 Best Practices Global Database フェイルオーバー中に、ユーザーが選択したセカンダリリージョン DB クラスターがプライマリに昇格されます。ただし、プライマリのパラメーターなどの構成オプションは自動的には継承されません。設定の不一致を軽減するには、Aurora DB クラスターのパラメーターグループを作成し、オプションを事前に設定することを推奨します。また、 Amazon CloudWatch アラートやその他のサードパーティモニタリングなどの監視ツールを導入することを推奨します。また、セカンダリリージョンで AWS Secrets Manager 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda などの外部サービスの依存関係をプライマリリージョンの設定と同様に構成することも推奨します。Global Database の設定の一部として ヘッドレスクラスター を使用する場合は、フェイルオーバーを開始する前に、適切なサイズのコンピューティングインスタンスを必ず追加してください。 推奨事項のより詳細なリストについては、「 Aurora ユーザー ガイド 」を参照してください。 Global Database フェイルオーバーの実行 少なくとも 1 つのインスタンスを含むセカンダリリージョン DB クラスターを少なくとも 1 つ含む Aurora Global Database を作成する場合、Global Database フェイルオーバー機能とGlobal Database スイッチオーバー機能を実行するオプションがあります。 Aurora Global Database を設定するには、「 Amazon Aurora Global Database のスタート方法 」のユーザーガイドを参照してください。 次の例（Figure. 1）では、2 つの DB クラスターを含む Aurora Global Database を作成しました。プライマリリージョンは ap-southeast-1 にあり、セカンダリリージョンは ap-south-1 リージョンにあります。 Figure.1 A Global Database Cluster コンソールを使用してGlobal Database フェイルオーバーを実行するには、次の手順を実行します。 フェイルオーバーする Aurora Global Database クラスターを選択します。 [アクション] メニューで、 [グローバルデータベースの切り替えまたはフェイルオーバー] を選択します。 Figure.2 Failover Global Database cluster 新しいプライマリクラスター で、プライマリに昇格するアクティブなセカンダリ Aurora DB クラスターを選択します。 フェイルオーバーの理由として [フェイルオーバー（データ損失を許可）] を選択します。フェイルオーバーを実行するには、「 確認 」と入力し、 [確認] を選択します。 Figure.3 Choose Failover フェイルオーバーの実行後、データベースのステータス状況を確認できます。データベースリストのステータス列に従って、フェイルオーバープロセスを監視できます。Global Database レプリケーションが非同期に行われる性質により、新しいプライマリ DB クラスターでのフェイルオーバー後に一部のデータが失われる可能性があります。 新しいプライマリリージョンの DB クラスターが最初に利用可能になり、新しいプライマリから新しいセカンダリの DB クラスターへのレプリケーションをセットアップするのに数分かかります。データベースのサイズに応じて、新しいセカンダリリージョンクラスターのセットアップには数分から数時間かかる場合があります。他のセカンダリ リージョン DB クラスターが存在する場合は、それらも再作成され、レプリケーションが再度確立されます。フェイルオーバーが完了すると、プライマリリージョン DB クラスターとセカンダリリージョン DB クラスターの両方が利用可能になっていることがわかります。 Figure.5 Failover completed AWS CLI を使用して Global Database フェイルオーバーを実行するには、次のようなコマンドを使用できます。 aws rds --region primary-region failover-global-cluster --global-cluster-identifier global_db_identifier \ --target-db-cluster-identifer ARN-of-secondary-to-promote --allow-data-loss Conclusion この投稿では、新しくリリースされた Aurora Global Database フェイルオーバー 機能とその利点について説明しました。この機能を使用すると、計画外の停止中にフェイルオーバーから Aurora Global Database クラスターを迅速に回復し、運用負担を軽減できます。 Aurora Global Database について詳しくは、 詳細なドキュメント をご覧ください。 Aurora Global Database を探索し、 RDS コンソール に移動してこれらの機能の詳細を学び、Global Database クラスターの作成を試してください。 著者について aaaaaaaaaaaaaaaa Aditya Samant はリレーショナルデータベース業界ではベテランで、商用データベースやオープンソース データベースを扱った経験が 20 年以上あります。長年にわたり、データベースコンサルタント、プロフェッショナルサポート、DBA、データベースアーキテクトなど、多くの役割を果たしてきました。彼は現在、アマゾン ウェブ サービスでシニアデータベーススペシャリスト ソリューションアーキテクトとして働いています。現在の役割では、顧客と協力してスケーラブルで安全かつ堅牢なクラウドネイティブアーキテクチャを設計することに時間を費やしています。また、Aditya はサービスチームと緊密に連携し、Amazon の主力リレーショナル データベースである Amazon Aurora の新機能の設計と提供にも協力しています。 Surendar Munimohan は、アマゾン ウェブ サービスのシニアデータベースソリューション アーキテクトです。彼は 10 年以上、リレーショナルデータベースを扱い、AWS で拡張性の高いアプリケーションを構築した経験があります。現在の役割では、顧客と協力して、AWS クラウドでスケーラブルで可用性が高く、安全でコスト効率の高いソリューションを設計しています。 翻訳はソリューションアーキテクトの「藤川 貞信」が担当しました。原文は こちら です。

生成系 AI の発展と共にモデルの規模はどんどん大きくなり、デプロイするためのインフラの選択や設定はますます複雑になっています。 Amazon SageMaker JumpStart は大規模言語モデルを最適な設定、かつワンクリックでデプロイする機能を提供します。 オープンソースコミュニティとの連携を通じ 、AWS はこれまで Meta の Llama2 や TII の Falcon などを JumpStart で提供してきましたが、この度 rinna 株式会社 から公開されている大規模言語モデルも JumpStart から利用できるようになりました。 日本語に対応したモデルが SageMaker JumpStart に採用されるのは初めてです。 初回のリリースとして、教師有り学習かつ強化学習済みである japanese-gpt-neox-3.6b-instruction-ppo が利用可能になりました。機械学習の統合開発環境である Amazon SageMaker Studio を起動し、 Home にある SageMaker JumpStart から Models, notebooks, solutions を選択し、 “rinna” で検索することで見つけることができます。 rinna のモデルは Hugging Face で公開されており、 Amazon SageMaker Studio Lab など無料の Jupyter Notebook のサービスで動かすこともできます。ただ、自ら推論のコードを実装し Notebook サービスの限られた GPU やディスクリソースでモデルを動作させるのは面倒ですし時間がかかります。 SageMaker JumpStart では 1 クリックで AWS のエンジニアが最適化したセットアップでモデルを動かすことができ、本記事でご紹介する rinna のモデルの場合 1 時間ずっと推論をし続けても 200 円未満で済みます。 Python SDK を利用した呼び出しを使用することでベンチマーク用データセットに対するまとまった推論も容易に行うことができますし、 API Gateway と組み合わせることで迅速に Web API 化しアプリケーションコードと統合することもできます 。実装・実験いずれに使うにあたっても推奨できるサービスです。 Amazon SageMaker JumpStart で rinna のモデルを起動する Amazon SageMaker Studio から JumpStart のメニューを起動します。 SageMaker Studio を使うのが初めてという方は、 SageMaker Immersion Day のハンズオン を参考に環境を構築してください。環境を作るだけ / 起動するだけでは料金はかかりません。実行する Jupyter Notebook やエンドポイント、学習ジョブなどに割り当てたインスタンス、またデータの保管や転送に対し課金が発生します。ここから先、課金が発生するタイミングについてはその旨と価格の目安を記載します。 SageMaker Studio にアクセスしたら、 JumpStart のメニューから “rinna” で検索を行います。ヒットしたモデルカードをクリックすると、モデルの詳細画面が開きます。デプロイするのに必要なのは、 “Deploy” のボタンを押すだけです。 Deployment Configuration ではインスタンスの選択やエンドポイントの設定を行うことができます。インスタンスは最適なものからのみ選べるようになっているので、非常に長いドロップダウンリストに悩まされることはありません。 Security Settings ではエンドポイントの作成に使用する IAM ロールや VPC 、モデルの暗号化に使うキーを設定できます。 rinna のモデルでは現在 “Train” は行うことができませんが、近日対応する予定です。対応後は、データが置いてある Amazon S3 のパスを指定するだけで転移学習が行えるようになります。 Deploy を押すとデプロイが開始します。 4~5 分で完了します。 “In Service” となったらデプロイ完了です。この時点から、エンドポイント用に指定したインスタンスの課金 ( 今回は ml.g5.2xlarge で オンデマンドの価格 は 2023 年 9 月時点で $1.212/時 、同時期の換算レートで 177 円/時 ) が開始するため注意してください。 Use Endpoint from Studio のセクションから “Open Notebook” をクリックします。 ここで、ノートブックを動かすためのインスタンスが別途必要になります。ノートブックが動けばよいので、それほどスペックのあるインスタンスは必要ありません。今回使用したインスタンスは ml.t3.medium で 東京リージョンのオンデマンド価格 は $0.065 (同時期の換算レートで 10 円/時) です。料金が気になる方は、ローカル PC や Amazon SageMaker Studio Lab から API を通じ利用することもできます。 ノートブックの内容は現時点では英語になっています。 payload の inputs を例えば次のように書き換えます。この inputs は、 Hugging Face の japanese-gpt-neox-3.6b-instruction-ppo に記載されている例を参考に作成しました。ユーザーとシステムの対話形式となっています。改行は明示的に <NL> で表記し入力文を作成します。 "inputs": "ユーザー: オムレツを作るためにはどんな手順が必要ですか？<NL>システム: ", 上から順に “Query endpoint that you have created” まで Jupyter Notebook のセルを実行すると、次のような出力が得られます。 Input Text: ユーザー: オムレツを作るためにはどんな手順が必要ですか？<NL>システム: Generated Text: まず、卵を用意します。卵をボウルに割り入れ、塩とコショウで味付けします。次に、卵に小麦粉を混ぜ合わせます。 プロンプトを変えたり、ハイパーパラメーターを変えることでその違いを検証できます。 検証が終了したら、忘れずに 1) Notebook に使ったインスタンスを停止して、 2) エンドポイントのインスタンスも停止してください。 SageMaker Studio の画面の左側にある電源メニューから Notebook の起動に使われているインスタンスを確認、停止できます。 JumpStart のエンドポイントはモデルの詳細画面にある Delete Endpoint から停止することができます。 モデルの詳細画面を見失った場合、JumpStart の Launched JumpStart assets のメニューからいつでも参照できます。 Title がリンクになっており、モデル詳細画面が開けます。一度エンドポイントを停止すると、ここには表示されなくなります。 AWS Japan の大規模言語モデルに対する取り組み AWS Japan として 7 月 3 日に「 LLM 開発支援プログラム 」を発表し、日本で大規模言語モデルの構築にチャレンジするお客様を支援しています。 9 月 4 日には採択企業が公開され 、お客様自身からプレスリリースも頂いています。 rinna 株式会社も採択された企業の一つです。今後、開発の成果として様々なモデルがオープンソースとして公開されたり、サービスをより良いものにするために活用されます。 公開を許可頂いている採択された会社と団体の名（五十音順）。プレスリリースを頂いている会社様はリンクをつけています。 カラクリ株式会社 株式会社サイバーエージェント ストックマーク株式会社 Sparticle 株式会社 Turing 株式会社 株式会社 Preferred Networks 株式会社 Poetics 株式会社松尾研究所 株式会社マネーフォワード 株式会社ユビタス 株式会社 Lightblue 株式会社リクルート 株式会社リコー rinna 株式会社 株式会社ロゼッタ 株式会社わたしは LLM 開発支援プログラムは開発の支援だけではなく、ビジネス支援も行うことが特徴です。大規模言語モデルの活用はまだ発展途上の領域であり、多様な活用の可能性がある一方、不確実でもあります。 AWS はプログラム採択企業に対し、 世界中の AWS のお客様にリーチできる AWS Marketplace や Amazon SageMaker JumpStart を活用頂くことでモデルの市場投入を支援します。モデルを利用するお客様にとっても、このプラットフォームを利用することでモデルの実装・実験を加速できます。今回、日本語という言語特化のモデルが AWS のプラットフォームに掲載されるのは、商用では LightOn のフランス語モデル 、 NCSoft の韓国語モデル に次いで 3 番目、 オープンソースのモデルでは初めてになります。この活動の背景には、日本のデベロッパーリレーションズ、ソリューションアーキテクト、事業開発マネジャーの粘り強い活動があります。本ブログを通じお伝えしたい事実は、 日本のお客様の声、開発者の声は AWS Japan を通じ AWS にきちんと届いており実際にサービス機能の改善・拡張として実現するということです 。ぜひ今後も忌憚のないフィードバックをお寄せください。 今後日本語のモデルを拡充しお客様の比較検証を容易にすると共に、 AWS 自身も 先の OpenCALM の記事 のようにモデルの性能やコストの検証を行い「モデルのカスタマイズを行うべき場面」を明らかにしていきます。 モデルの利用シーンが明らかになることでビジネス機会が創出され、モデルを掲載頂いているお客様と利用いただくお客様双方にとってプラットフォームの価値を高められると考えています。 rinna 株式会社は人とコミュニケーションを行う AI の開発を推進しており、この領域での検証にまず着手する予定です。 AWS は公開されたモデルが利用されることでフィードバックが集まりよりニーズに合ったモデルが生まれるエコシステムの構築を目指し、今後も取り組みを進めていきます。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。  

はじめに AWS は AWS IoT でコネクテッド ビークル プラットフォームをモダナイズし、構築するための新しいアーキテクチャーガイダンスとデザインパターンを発表します。今日、自動車メーカー (OEM) は、提供するハードウェアやスペックだけでなく、革新的なソフトウェア主導のコネクティビティ機能によって、ポートフォリオを差別化しています。車両コネクティビティを備えて、車両データ（テレメトリ）を収集することにより、自動車メーカーは以下のような、より高度な機能を構築し提供しています： ソフトウエアデファインドビークル (SDV) と無線アップデート (OTA) により、車両のライフタイムに渡って車両機能を向上（例、自動運転など） インテリジェントなマッピングと位置情報サービス（スマートパーキング、交通予測） 車両のジオフェンシング（家族の位置を特定） インフォテインメントおよびエンターテインメント・サービス（ダイナミック アプリ ストア） ドライバーサポートの強化（居眠り運転アラート） 車両セキュリティモード（接続された車両カメラからのイベントベースの録画とライブ・ストリーミング） リモート車両操作（リモートスタート、車両のロック/アンロック、デジタルキー） コネクテッド ビークル プラットフォームは、車両のテレメトリを収集し、クラウドに送信するプロセスを簡素化し、AWS サービスが取り込んだデータを収集、分析、処理することを可能にします。 Honda や WirelessCar のような自動車会社は、サービスのパフォーマンス、スケーラビリティ、費用対効果、柔軟性に基づいて、コネクテッド ビークル プラットフォームに AWS IoT を採用しています。レガシーな車両プラットフォームやオンプレミスの技術スタックを維持する多くの企業は、クラウドネイティブなアーキテクチャに移行することでシステムをモダナイズしています。この記事では AWS IoT Core や AWS IoT FleetWise のようなサービスを、最新のコネクテッド ビークル プラットフォーム アーキテクチャの一部としてどのように利用できるかを紹介します。 MQTT メッセージブローカーの利点 メッセージブローカーは、車両とクラウド間の双方向で安全な通信を提供するため、コネクテッド ビークル アーキテクチャの中心となります。コネクテッド ビークルのメッセージブローカーのデファクトスタンダードである MQTT は、車両とクラウド間の常時接続を可能にします。断続的な接続性（地下トンネルを走行する車両など）でも MQTT はバッファリング、キューイング、車両接続が再確立された際の同期を難なく処理します。 MQTT は軽量で、クラウドとの効率的な通信を可能にし、エッジでの消費電力を削減するため、コネクテッド ビークル プラットフォームに理想的な通信プロトコルです。リクエスト/レスポンスや複数の TLS ハンドシェイクの代わりに常時接続を利用するため、他のプロトコル (HTTP など) ではよりコストがかかり、効率も悪くなります。 AWS IoT Core はマネージド MQTT メッセージブローカーを提供し、毎日接続される何億ものデバイスを既にサポートしているため、自動車メーカーはスケーリングや弾力性、ピーク需要に対応するためのコンピューティングインフラのプロビジョニングについて心配する必要がありません。 AWS IoT Core は、マルチリージョン機能と従量制の使った分だけ支払う実用的な価格モデルにより、数百万台の車両を容易に拡張し、確実に処理します。マネージド AWS IoT サービスに移行することで、お客様は運用コストとサードパーティのテクノロジーライセンスのコストを削減できます。 AWS IoT Core はグローバルで利用できるため、お客様は現地のデータ保存、主権、プライバシー要件に準拠できます。サービスのアップタイムと可用性に対するコミットメントとして、 AWS は AWS IoT Core の Service Level Agreement を提供しています。 コネクテッド ビークル アーキテクチャの文脈では、 AWS IoT Core は、世界中の地域の車両がクラウドと安全に通信するために使用するコネクティビティレイヤー(業界標準のマネージド MQTT メッセージブローカー) を提供します。 AWS IoT Core MQTT ブローカーは、パブリッシュ / サブスクライブメカニズムを利用したイベントドリブンアーキテクチャを可能にします。この通信プロトコルは、コスト効率の高いストレージ、オンデマンドの高性能コンピュート、機械学習サービスの豊富なポートフォリオ、その他多くの AWS サービス統合のために、車両が他のダウンストリーム AWS サービスと安全に接続し、通信することも可能にします。 AWSは最近、 MQTT v5 のフルサポートを発表 し、コネクテッド ビークルのユースケースをさらに拡大すると発表しました。 MQTT v5 には、コネクテッドプラットフォームに適用される以下のような 新機能 があります： メッセージの有効期限とリクエスト / レスポンスオプションによるコンパニオンアプリ開発の柔軟性 Protobuf サポートとユーザープロパティによる、より強力なデバイスメッセージング 共有サブスクリプションを利用することで、インジェスト処理アプリケーションをより簡単に拡張可能 トピックエイリアスとセッションの有効期限によるリソース管理の向上 これらの MQTT v5 の新機能により、多くのお客様が、オンプレミスまたはサードパーティソリューションでホスティングされた既存のインプロダクション MQTT メッセージブローカーを、マネージド MQTT サービスのために AWS IoT Core に移行しています。これにより、現在のプラットフォームとの機能パリティを維持し、インフラストラクチャを管理するための運用オーバーヘッドを削減することで、コストとエンジニアリング時間を節約することができます。 既存のコネクテッド ビークル プラットフォームのモダナイズ AWS は最近 AWS IoT でコネクテッド ビークル プラットフォームを構築するための新しい リファレンスアーキテクチャ のセットを発表しました。これは、本番環境で利用中のレガシープラットフォームの近代化に伴うリスクを最小化するために、既存の車両の設定を固定したまま、 AWS IoT Core への移行が容易であることを示すことに焦点を当てています。最新の MQTT v5 機能により OEM はベンダーロックインを回避し、現在のコネクテッドビークルのワークロードをシームレスに更新し、インジェストエンドポイントを AWS IoT Core に切り替えることで、マネージド MQTT メッセージブローカーに移行することができます（既存のプラットフォームが MQTT 3.1 または MQTT v5 仕様に準拠し、適切に実装されている限り）。これにより OEM は現在のメッセージブローカーをモダナイズし、他の AWS サービス（ストレージ、コンピュート、機械学習、アナリティクス、可視化ツールなど）に簡単にアクセスできるようになります。 図1: AWS Connected Vehicle Architecture – モダナイゼーション モダナイゼーション リファレンス アーキテクチャーは、コネクテッド ビークル プラットフォーム内の最も一般的な機能に関するハイレベルなガイダンスを提供します。アーキテクチャに記載されているすべてのユースケースや機能を実装する必要はありません。その代わりに、ベストプラクティスの技術ガイダンスと再現可能なデザインパターンを提供し、 AWS IoT Core と MQTT v5 のパワーを説明することを目的としています。リファレンスアーキテクチャを実装するために、 mTLS 、 MQTT 、および適切な暗号ライブラリ（例えば AWS IoT Core に接続するために必要な要件をサポートする OpenSSL ライブラリ）を使用して AWS IoT Core に安全に接続するために車両がプロビジョニングされている（またはされる予定である）という基本的な前提があります。 MQTT メッセージブローカーを AWS IoT Core に移行することで、既存の車両プラットフォームのパブリッシュとサブスクライブのメカニズムをそのまま動作させることができます。移行を完了するために、クラウド内のロジックが更新され、車両から送信されたデータペイロードを処理するように構成されます。 AWS re:Invent 2022 で Mercedes-Benz Research & Development North America はメッセージブローカーのモダナイズ化のアプローチを発表し、メッセージブローカー実装の複雑さを軽減し、コストを削減するために数百万台の車両を AWS IoT Core に移行した方法を説明しました。 彼らにとって、近代化されたパブリッシュ/サブスクライブ アーキテクチャは、トラブルシューティング、デバッグ、トレース機能のために、車両単位でより良い観測性を提供します。ストリーミングアーキテクチャとメッセージブローカーの更新により、遠隔測定収集とコマンド/制御オペレーションを分離することができ、本番ワークロードの迅速な反復と Amazon Kinesis などの他のダウンストリーム AWS サービスとのシームレスな統合が可能になりました。 このメッセージブローカーのモダナイズ化のアプローチにより OEM はいくつかの簡単なステップで AWS IoT Core への移行を開始することができ、コネクテッド・ビークル・プラットフォームの運用、観測可能性、拡張性に即座に影響と価値を提供することができます。 新しい次世代コネクテッド・ビークル・プラットフォームの構築 MQTT v5 と AWS IoT Core で新しい次世代コネクテッド ビークル プラットフォームを構築しようとする、あるいは既存の AWS IoT Core プラットフォームを MQTT v5 の新機能で拡張しようとする OEM 、自律走行車スタートアップ、テレマティクス ソリューション プロバイダーのために、コネクテッドプラットフォームの主要な要素と機能に焦点を当てた新しいコネクテッド ビークル リファレンスアーキテクチャを公開しました。これは AWS IoT と関連する AWS サービスで次世代コネクテッド ビークル プラットフォームを構築するためのベストプラクティスの設計または青写真であり、最新のクラウドネイティブアプローチで可能性を実証します。 図2: AWS Connected Vehicle Architecture このアーキテクチャは AWS IoT Core と AWS IoT FleetWise で車両をクラウドにセキュアに接続するために必要な車両側のコンポーネントから始まります。 AWS IoT Core との通信には X.509 証明書と秘密鍵による相互 TLS(mTLS) 認証が必須となります。 AWS は IoT SDK を提供しており、カスタマイズしてコネクテッド・ビークルのソフトウェア・スタックに統合することができます。 AWS IoT Core に接続するために、 AWS は車両に特定のソフトウェアをデプロイすることを要求または義務付けていません。 AWS IoT FleetWise をコネクテッドプラットフォームに含めるために AWS はオープンソースで軽量の AWS IoT FleetWise Edge Agent を提供しており GitHub から ダウンロード できます。 FleetWise Edge Agent は、車両の CAN バスからの信号をデコードし、条件やイベントに基づいてデータをクラウドに送信し、クラウド上の AWS IoT FleetWise サービスと連携してデータを保存し、アクションを実行し AWS アカウントに送信されたデータを配信します。 マルチリージョンのデプロイメントのために AWS は車両がクラウドインフラストラクチャに接続する方法を管理するために顧客が設定するルールに基づいて、車両が通信すべき最も近いブローカーを識別する Route53 ジオロケーションルーティングを使用するシンプルなデザインパターンを持っています。また Route53 に初めて接続する際に、車両のブートストラップ構成として使用できる動的トピックとサブスクリプションに関するガイダンスも提供します。 AWS IoT FleetWise は 自動車業界向けに構築された初の AWS サービスであり、クラウドファーストアプローチを使用して車両をモデル化し、それらのモデルでデータ収集キャンペーンを展開します。 AWS IoT FleetWise は AWS IoT Core と連携して動作し AWS IoT Core と同じ認証メカニズムを使用してデータを集約し AWS に送信します。 まとめ 新しい IoT リファレンスアーキテクチャのガイダンスは AWS IoT でコネクテッドビークル・プラットフォームを構築している AWS の顧客とパートナーに、ガイダンスとベストプラクティスを示し、提供することを意図しており、修正なしでデプロイされなければならない包括的でモノリシックなアーキテクチャであることを意図していません。このアーキテクチャは、ディスカッション、ブレーンストーミング、車両のライフサイクルを通じた長期的な運用と保守性のために最適化された最新の次世代コネクテッドビークル・プラットフォームを構築するための基礎となる青写真の出発点として意図されています。技術的なアーキテクチャーを超えた、より規定的なガイダンスについては AWS IoT for Automotive ワークショップ やAWSホワイトペーパー 「 Designing next generation vehicle communication platforms on AWS IoT Core 」 を参照することを推奨します。また AWS アカウントチームと連絡を取り、ブレインストームやその他の技術セッションをスケジュールし、AWSのサブジェクトマターエキスパートがお客様のビジネスと技術要件を満たす最適なAWSアーキテクチャの設計を支援することをお勧めします。 Andrew Givens Andrew は Amazon Web Services の IoT スペシャリストです。アトランタを拠点に、グローバルな自動車業界の顧客が AWS IoT 上でコネクテッド・ビークル・ソリューションを構築するのを支援しています。自動車業界での深い経験を持ち、AWS上の拡張可能でスケーラブルな車両通信プラットフォームに特に関心を持っています。 Lowry Snow Lowry は Amazon Web Services の IoT およびコネクテッド・ビークルのプリンシパル・ワールドワイド GTM リードです。ソルトレイクシティを拠点とし、過去 5 年間 AWS IoT チームで Go-to-Market の取り組みをリードしており AWS サービスによるコネクテッド・ビークル・プラットフォームの構築と近代化に注力しています。 この記事は Adam Givens と Lowry Snow によって書かれた Building and Modernizing Connected Vehicle platforms with AWS IoT の日本語訳です。この記事は シニア プロトタイピング ソリューション アーキテクトの市川 純が翻訳しました。

この記事は、 Simulating Automotive E/E Architectures in AWS Part 2: Solution in Action を翻訳したものです。 本記事は、AWS で自動車の電気/電子（E/E）アーキテクチャをシミュレーションする方法についてガイダンスを提供する2部構成のシリーズの2つ目のブログ記事です。 パート1 では、自動車の E/E アーキテクチャのトレンドと、クラウドを利用した ECU ソフトウェアのシミュレーションに関する一般的な概念と自動車メーカーが直面する課題について説明しました。パート2では、 AWS および dSPACE VEOS と、AWS Graviton を使用した HPC イメージのネイティブ ARM を組み合わせて使用することにより、自動車メーカーが AWS および dSPACE のテクノロジを使用して自動車の E/E アーキテクチャをシミュレートする方法について説明します。 dSPACE は、主に自動車業界で使用される開発、テスト、および検証のためのツールと専門知識を提供する AWS パートナーです。dSPACE は30年以上の歴史の中で、シミュレーションおよび検証ソリューションのグローバルテクノロジーリーダーとなり、特に HIL（Hardware-in-the-Loop）システムで知られています。dSPACE は、仮想 ECU の複雑なネットワークをシミュレートするように設計された製品である VEOS や、ADAS（先進運転支援システム）/AD（自律走行システム）を含むさまざまな領域で使用できるクラウドベースのスケーラブルなシミュレーション用の SIMPHERA など、SIL（Software-in-the-Loop）ソリューションのポートフォリオを継続的に拡張しています。 VEOS-Graviton ソリューションは、自動車の E/E アーキテクチャをエミュレートするために設計されたdSPACE の VEOS（仮想イーサネットバス）を使用して、開発チームが仮想 ECU をテストする方法を示しています。これにより、さまざまなテストシナリオ下で入出力信号の早期検証や、AWS 上でのサブシステム間の通信が可能になります。 dSPACE と AWS の E/E シミュレーションソリューション dSPACE には、エッジ ECU およびゾーン ECU を仮想化し、 Amazon EC2 x86ベースのインスタンス 上のVEOS で実行するためのソリューションと、HPC を AWS Graviton インスタンスで実行するためのソリューションがあります。HPC とゾーン ECU の間には、このブログシリーズのパート1の「最新の自動車 E/Eアーキテクチャ」でも説明したように、多くの通信が存在する。シミュレーションソリューションのセットアップでは、VEOS（仮想ゾーン ECU）と AWS Graviton（仮想 HPC）間の通信を確立する必要があります。 このセットアップでは、仮想ゾーン ECU を VEOS の仮想イーサネットチャンネルに接続する必要があります。このシミュレートされたイーサネットチャネルは、どのホストイーサネットデバイスからも独立しています。通信を可能にするには、HPC を代表する AWS Graviton インスタンスを VEOS を実行する仮想イーサネットチャネルに接続する必要もあります。VEOS は別のインスタンスにインストールされていることに注意してください。 dSPACE は、VEOS と AWS Graviton インスタンス間の通信を処理するためのブリッジコンポーネントを開発しました。ブリッジは2つの部分で構成されています： 1つの部分は VEOS で実行され、仮想イーサネット上で通信し、もう1つの部分は AWS Graviton インスタンス上で実行されます。ブリッジは OSI レイヤー2でイーサネットフレームをキャプチャし、インジェクションすることができます。これにより、シミュレーション内のコンポーネント上で本番イーサネット通信スタックを実現することが可能になります。 自動車業界で使用される一般的な通信プロトコルの1つは、 SOME/IP （ OSI モデル のレイヤー7）です。これは、UDP/IP と TCP/IP（OSI モデルのレイヤー3および4）に基づくサービス指向プロトコルです。ブリッジは下位レベルで Ethernet トラフィックを転送するため、dSPACE ブリッジコンポーネントを使用して、市販の SOME/IP スタックを使用したり、SOME/IP プロトコルの動作を調査したりすることができます。 dSPACE には、SOME/IP Restbus モデル を作成するためのソリューションも用意されており、例えば、ゾーン ECU がまだ使用可能でない場合に仮想的なゾーン ECU を作成することができます。これにより、VEOS でゾーン ECU をシミュレートすることも、Restbus モデルで AWS Graviton インスタンスと通信することも可能になります。ブリッジが2つのシミュレーションインスタンスとどのように相互作用するかを図1に示します。 図1：dSPACE ブリッジソリューションを示すハイレベルアーキテクチャ VEOS では、エッジ ECU のシミュレーションや仮想バス（ CAN 、 LIN ）の設定も可能です。図2に示すように、ゾーナルアーキテクチャのシミュレーションに必要なあらゆる種類の ECU とモデルで構成される複雑なシミュレーションシステムを作成できます。 図2：AWS 上の全モデルとシミュレーションされた ECU を示すアーキテクチャ VEOS と AWS Graviton インスタンス間の同期に関して、図2に示すソリューションは、現時点では疎結合アプローチに依存しています。このアプローチにより、開発チームは必要に応じて自動車コンポーネントを簡単に切り替えることができます。 AWS Graviton インスタンスでは、自動車用 HPC で一般的に使用されているリアルタイム OS が利用されています。VEOS は、リアルタイム動作の近似を実現することを支援し、仮想コンポーネントのタスクをオンタイムで呼び出すことができます。 AWS 上で実現できるソリューションのアーキテクチャ図を図3に示しています。この図では、開発チームが dSPACE ControlDesk を活用して、仮想 ECU を実現している Amazon EC2 インスタンスとどのように接続するかを説明しています。 図3：シミュレーション・ソリューションの AWS アーキテクチャ図 このアーキテクチャに加えて、 AWS Batch 、 Amazon Elastic Kubernetes Service 、 AWS Step Functions などの AWS クラウドコンポーネントを使用して、個々のコンポーネントをコンテナ化してスケーラビリティを高めることもできます。 ソリューションの実行 VEOS-Graviton ソリューションのデモを行うため、AWS は dSPACE をサポートし、簡素化されたヒーターコントローラというシンプルかつ鮮明なデモプロジェクトを作成しました。 AWS と dSPACE は、業界をリードする自動車用ソフトウェアコンポーネントのプロバイダである Elektrobit 社と協力しました。Elektrobit 社の EB Corbos 製品ラインには、Adaptive アプリケーション向けの AUTOSAR ランタイムが含まれています。Elektrobit 社と AWS は、このランタイムと関連する Adaptive アプリケーションを AWS Graviton インスタンス上で実行する環境を構築しました。AWS クラウドでの EB Corbos による Adaptive アプリケーションの開発と実行に関する詳細情報は、 こちら のブログ記事でご覧いただけます。 このデモでは、Elektrobit は EB Corbos を利用した Adaptive アプリケーションとしてヒーターコントローラーを実装し、AWS Graviton インスタンスにデプロイしました。ヒーターコンポーネントは、デモの車両のメイン HPC を表しています。 センサー/アクチュエーター、エッジ、ゾーン ECU 用の個別の仮想コンポーネントの代わりに、すべての機能が Restbus モデルにまとめられ、VEOS で実行されます。Android インスタンスが HMI を表し、デジタルコックピット UI も AWS Graviton インスタンス上で実行されています。ヒーターコントローラ、より正確には EB Corbos 通信スタックは、ブリッジコンポーネントを介して Restbus モデルとデータを交換します。これは、AWS Graviton のホストイーサネットと VEOS の仮想イーサネットを接続します。 デモセットアップの代表的な図を図4に示します。 図4：E/E シミュレーションデモのハイレベルアーキテクチャ シミュレーションが開始されると、開発者は Android ベースのデジタルコックピット UI から目標温度を設定することができます。コントローラアプリケーションは、目標温度を取得し、VEOS で実行されている Restbus モデルから現在の温度も受信します。ヒーター電力を計算し、Restbus モデルに送信します。AWS の Graviton 上のコントローラアプリケーションと VEOS の Restbus モデルは、クローズドループシナリオを表しています。 Restbus モデルは 「車室内温度サービス 」を、コントローラーアプリケーションは 「ヒーターコントローラーサービス 」を、デジタルコックピット UI は 「目標温度サービス 」を提供します。シミュレーションの初期段階では、開発者は関連する SOME/IP イーサネット通信を監視し、サービスディスカバリーやイベントサブスクリプションメッセージを見ることができます。また、dSPACE のソフトウェアを使用して、コンポーネント間で交換されるメッセージを監視することもできます。たとえば、 dSPACE ControlDesk は、監視、実験、および計測のための dSPACE の別の製品です。ControlDesk を使用すると、VEOS に接続してシミュレーションシステムと対話することができます。図5に示すように、仮想 Ethernet チャネルのトラフィックを解析できます。 図 5：ControlDesk Ethernet トラフィック・ビュー SOME/IP 通信が機能し、すべてのイベント登録が成功した場合、Android デジタル・コックピットの UI を使用して目標温度を変更することができます。この場合、図 6で強調表示されているように、2つのボタンを使用して、16度から 28 度の範囲を 0.5度のステップ・サイズで変更することができます。 ControlDesk はまた、現在の温度を測定することができます。これは Restbus モデルから読み込まれ、シミュレーション中に ControlDesk ビューにプロットされる信号です。ターゲット温度が UI を通して変更されるたびに、コントローラアプリケーションは、電流温度が一致するようにヒーターパワーを調整します。これは図7の ControlDesk プロッタに示されています。 VEOS と AWS Graviton の接続により、開発者などのソリューションユーザーは、ネイティブアプリケーションコードを実行する複数の HPC を含む自動車 E/E アーキテクチャを表現するシミュレーションシステムを作成することができます。 まず、シミュレーションが開始されるか、予期せぬクラッシュ、エラー、警告が発生しないかを確認するために、ユーザーはテスト実行を行うことができます。(仮想 ECU や HPC のような）個々のコンポーネントや、予期せぬ動作を引き起こす可能性のある初期入力信号やバスフレームに関連する問題を特定できます。いずれの場合も、仮想環境を使用して問題をデバッグして解決することが可能です。 検証チームが実施するインターフェーステストを通じて、すべてのコンポーネントが互いに正しく通信できるかどうかを確認することができます。ネットワークレベルの一例として、HPC とそのカウンターパートとなる ECU 間のサービス指向通信の調査があります。HPC とゾーン ECU の SOME/IP コンフィギュレーションにミスマッチがあれば、シミュレーション・システムで明らかになります。イーサネット・トラフィックを調査することで、開発者とテスト担当者は根本的な原因を理解し、設定を修正することができます。同様に、その他のプロトコル（ DDS や MQTT など）の動作も調査することで、コンフィギュレーションの潜在的な問題を特定し、修正することができます。 フォールト・インジェクション・テストは、データが破損したり歪んだりした場合のシステムの堅牢性をチェックするために使用できる。VEOS で動作するコンポーネントには、信号へのオフセットの追加やイーサネットフレームのドロップなど、他のコンポーネントと交換されるデータを操作するためのさまざまなオプションがあります。このようにして、AWS Graviton 上で動作する HPC にエラーを注入し、その動作を分析し、よりロバストな動作を検討することも可能です。 インタラクティブか自動化か 異なるテストを実施するための2つの主要なアプローチがあります： 実験や対話的アクセスによる手動のアプローチ テスト自動化の利用 実験において、開発チームは、確立されたインターフェース（ XIL API ）またはツール（ControlDesk など）を使用して VEOS へインタラクティブにアクセスすることができます。これにより、システムの挙動を理解するための測定が可能な信号やバスレベルへのアクセスが可能になります。ユーザーが AWS Graviton インスタンスを VEOS に接続すると、AWS Graviton 上の HPC ソフトウェアスタックとクローズドループセットアップの一部である VEOS のモデルを評価し、シミュレーションするように、暗黙的に HPC と通信することを選択できます。実験中に作成された設定は、後で HIL 環境に再利用することができます。 自動車開発者は、さまざまなテストを頻繁に実行するために、dSPACE AutomationDesk のようなテスト自動化ツールを利用することができます。さまざまなテストルーティン（入力信号を特定のレベルに設定し、結果の出力信号を基準値と比較するなど）を作成することで、開発者は CI または CT（継続的テスト）のパイプラインの一部となるさまざまなテストケースを作成できます。 VEOS や AutomationDesk などの dSPACE ツールは、クラウド環境で大規模に実行するのに適しています。 SIMPHERA により、dSPACE は、さまざまな車両機能の検証テストスイートを作成、実行、および評価するためのクラウドベースのソリューションを提供します。また、シミュレーションシステムの作成とパラメータを設定し、それらをオーケストレーションして、カスタムの実行ノードで多数のテストケースを効率的に実行します。SIMPHERA の主な焦点は、ADAS および AD ソフトウェアの動作を理解するためのシナリオベースのテストです。 図 8：dSPACE SIMPHERA の AWS リファレンスアーキテクチャ まとめ 本ブログでは、dSPACE VEOS と AWS Graviton インスタンスを接続し、クラウド環境で最先端の自動車E/E アーキテクチャをシミュレートするという新しいコンセプトを紹介しました。また、dSPACE、AWS、および Elektrobit が実施したデモを紹介し、このコンセプトがどのように機能するかを説明しました。最後に、自動車用ソフトウエアの開発者およびテスト担当者が、完全仮想かつスケーラブルな環境でさまざまなテストを実施するために、このアプローチをどのように活用できるかを説明しました。 AWS と dSPACE は、実装の詳細を改善し、AV/ADAS 領域などのさらなるユースケースを調査して、お客様向けのクイックレファレンスガイドを提供する予定です。HPC を含む自動車用ソフトウェアを開発またはテストする必要がある場合、VEOS-Graviton の接続により、ネイティブアプリケーションコードを使用しながら統合およびテスト用の仮想環境を構築することができます。これにより、全体的な開発プロセスまたは検証戦略において、コストと市場投入までの時間を削減する機会が得られます。 VEOS-Graviton による E/E シミュレーションソリューションのライブデモをご希望の場合は、 dSPACE または AWS にお問い合わせください。 TAGS:  automotive , hpc , Simulation , software defined vehicle Fabian Bronner Fabian Bronner は、自動車業界向けの Software-in-the-Loop ソリューションに特化した dSPACE のビジネスデベロッパーです。完全に仮想化された環境で自動車用ソフトウェアを大規模にテストする機能を開始または拡張したいお客様をサポートしています。新しい要件や課題について学ぶと同時に、パートナーやお客様と一緒にコンセプトを開発し、急速に進化する業界を一緒に形成しています。デジタルとコネクテッドな世界のバランスを取るために、ファビアンはオフラインでヨットに乗ることを楽しんでいる。 Jeremy Dahan Jeremy Dahan は、Amazon Web Services の Automotive Compute Sr Tech GTM Specialist です。クラウド機能を活用して、自動車用ソフトウェアに関する最も困難な問題に取り組む顧客やパートナーを支援している。自動車業界で10年以上の経験があり、特に組込みソフトウェアと最近ではクラウドに詳しい。AWS上でプロダクトを構築していないときは、自動車/IoTセンサーをいじっている。 Jerry Bonnah Jerry Bonnah は、Amazon Web Services のシニアパートナー・ソリューションアーキテクトです。コネクテッド・ビークル・テクノロジーを中心とした自動車業界を専門とし、パートナーと緊密に連携してこの分野の新製品や新機能の設計、共同開発、共同開発を行う。テクノロジーリーダーシップ、ソリューションアーキテクチャ、新製品立ち上げにおいて10年以上の経験を持つ。AWS 上で物事を構築していないときは、AWS 上で次に何を構築できるかを考えている。 Luke Harvey Luke Harvey は、Amazon Web Services のプリンシパル・パートナー・ソリューション・アーキテクト。AWSのグローバル自動車パートナー戦略の責任者であり、戦略パートナーがクラウドを活用して最先端のソリューションを構築、マーケティング、販売できるよう支援する。自律走行車とコネクテッド・ビークルのテクノロジーにおいて、10年以上自動車業界をリードしてきた経験を持つ。AWS でプロダクトを構築していないときは、ミシガン州で家族と養蜂に時間を費やしている。 Moritz Schniedermann Moritz Schniedermann は dSPACE のアプリケーションエンジニアで、エンジニアリングおよび事前開発活動を担当しています。ECU のデータ再生と仮想化に関する専門知識を生かし、自動車用ソフトウエアがハードウエア段階に到達する前に、その機能性と信頼性を保証しています。SIL シミュレーションをさまざまなコシミュレーションシナリオで活用することにより、自動車業界における最先端のシミュレーションソリューションの発展に貢献しています。 このブログは、シニアソリューションアーキテクトの渡邊翼が翻訳しました。

AWS AppSync は、GraphQL API をクラウド上で構築、管理、ホストできるサービスです。AppSync を使用すると、GraphQL スキーマを記述し、リゾルバを使用してデータソースに接続するだけです。リゾルバは、AppSync が異なるデータソースから情報を取得するために GraphQL リクエストを変換する方法です。2022 年 11 月、AppSync は JavaScript リゾルバを導入 し、開発者が AppSync ビジネスロジックを書きやすくなりました。JavaScript リゾルバの開始には、コードエディターでの型検証とオートコンプリートを提供する @aws-appsync/utils や開発中の問題を素早くキャッチして修正する @aws-appsync/eslint-plugin などの開発を簡素化するための NPM ライブラリが含まれています。 本日 (2023 年 8 月 31 日)、DynamoDB データソースと対話するための新しいモジュールと関数をリリースし、 Amazon DynamoDB 用のリゾルバをさらに書きやすくしました。新しいモジュールは、 put 、 get 、 delete 、 update 、 scan 、 sync 、 query といった一般的な操作の DynamoDB リクエストを作成するのに必要なコードを簡素化します。さらに、更新時にアイテムの属性を細かく変更するための操作ヘルパーも提供します。このモジュールは、TypeScript を使用する場合に開発者がローカルで型安全なコードを記述できるようにするための型定義とともに、パブリックな @aws-appsync/utils パッケージで利用可能です。 概要 DynamoDB データソース用の新しい JavaScript モジュールは、DynamoDB のリクエストを数行のコードで簡単に表現できるようにします。例えば、DynamoDB テーブルに id を primaryKey とし、属性に key/value のペアを持つ新しい item を追加したいとします。以下のコードは ddb.put ユーティリティを使用しており、 key と item を入力として DynamoDB の PutRequest を作成します。 import * as ddb from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const item = { id: util.autoId(), ...ctx.args }; return ddb.put({ key: { id: item.id }, item }); } export const response = (ctx) => ctx.result; DynamoDB のデータソースから scan を使って情報を取得することもできます。例えば、テーブルにいくつかの項目を追加したので、それらの項目のリストを取得したいとします。以下のコードでは、 ddb.scan ユーティリティを使用して、 limit と nextToken の値を入力として、DynamoDB から返される結果をページ分割しています。 import * as ddb from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const { limit = 10, nextToken } = ctx.args; return ddb.scan({ limit, nextToken }); } export const response = (ctx) => ctx.result.items; 次は、リゾルバロジックを追加した AppSync API でこれらの関数を使ってみましょう。 はじめに DynamoDB 用の JavaScript モジュールは、AppSync コンソールで始めることができます。 AppSync コンソールで、 Create API を選択します。 API Type はデフォルトのまま、 Next を選択します。 Specify API details ページで、API の名前を ToDo-API にし、 Next を選択します。 Specify GraphQL resources ページで、 Create type backed by a DynamoDB table now を選択します。 AppSync コンソールは、新しい GraphQL タイプ、タイプに関連する操作、およびデータソースとして使用するDynamoDB テーブルの作成をサポートします。新しい JavaScript モジュールの機能を説明するために、 id 、 owner 、 name 、 severity 、 dueOn のフィールドを持つ Todo タイプを作成します。 モデル情報を以下の値で埋めてください。フィールドを追加するには、 Add new field を選択します。モデル名には ToDo と入力します。 Additional settings セクションで、 Resolver runtime を AppSync JavaScript のままにします。 モデルテーブルの構成セクションで、テーブル名、主キー、ソートキーを以下の値で入力し、 Next を選択します。 API の詳細を確認し、 Create API を選択します。 ToDo-API 、DynamoDB データソース、JavaScript リゾルバが自動的に作成されます。 Schema ページでは、GraphQL スキーマの確認と変更、リゾルバの編集、スキーマのフィールドへの新しいリゾルバのアタッチができます。DynamoDB の新しい JavaScript モジュールを使用するために、リゾルバのロジックを更新してみましょう。 Schema ページに移動します。 Resolvers セクションで、 Filter types... 検索バーに Mutation と入力します。 createToDo(...) : ToDo フィールドに ToDoTable リゾルバを選択します。 createToDo リゾルバには、 condition 、 key 、および attributeValues を含む DynamoDB PutItem リクエストを構築するヘルパー関数が含まれています。これらの値はすべて DynamoDB が PutItem リクエストを期待するマップオブジェクトに変換されます。 function dynamodbPutRequest(params) { const { key, values, condition: inCondObj } = params; let condition; if (inCondObj) { condition = JSON.parse(util.transform.toDynamoDBConditionExpression(inCondObj)); if (condition && condition.expressionValues && !Object.keys(condition.expressionValues).length) { delete condition.expressionValues; } } return { operation: 'PutItem', key: util.dynamodb.toMapValues(key), attributeValues: util.dynamodb.toMapValues(values), condition, } } DynamoDB の JavaScript モジュールを使って、このロジックをシンプルにしてみましょう。 リゾルバのコードに以下の import 文を追加します。 import { put } from '@aws-appsync/utils/dynamodb'; リクエストハンドラを以下のコードに置き換え（オプションで dynamodbPutRequest 関数を削除）、 Save を選択します。 export function request(ctx) { const { id, owner, ...item } = ctx.args.input; const key = { id, owner }; const condition = { }; Object.keys(key).forEach(k => condition[k] = { attributeExists: false }); return put({key, item, condition}); } 新しいモジュール関数を使用すると条件操作、キー、および属性値を構築するロジックを簡素化できます。これで、 toMapValues ユーティリティや toDynamoDBConditionExpression ユーティリティを使用する必要がなくなりました。この機能は、 put ユーティリティ関数で抽象化されています。 updateToDo 操作のより複雑なリゾルバを見てみましょう。 Schema ページに移動します。 Resolvers セクションで、 Filter types... 検索バーに Mutation と入力します。 updateToDo(...) : ToDo フィールドに ToDoTable リゾルバを選択します。 createToDo リゾルバと同様に、 updateToDo リゾルバには、DynamoDB の UpdateItem リクエストを構築するヘルパー関数が含まれています。新しいモジュールを使って、このロジックを単純化してみましょう。 リゾルバのコードに以下の import 文を追加します。 import { update, operations as ops } from '@aws-appsync/utils/dynamodb'; リクエストハンドラを以下のコードに置き換えて、 Save を選択します。 export function request(ctx) { const { id, owner, ...values } = ctx.args.input; const key = { id, owner }; const condition = {}; Object.keys(key).forEach(k => condition[k] = { attributeExists: true }); const updateObj = {}; Object.entries(values).forEach(([k,v]) => updateObj[k] = v ?? ops.remove()); return update({ key, condition, update: updateObj }); } DynamoDB 用の JavaScript モジュールを使用することで、 operations 関数と update 関数を利用して更新式を作成するコードを簡素化することができます。ここでは、更新中に属性を削除するために、指定された属性が null かどうかをチェックし、 operations.remove() を使用して削除されたものとしてマークしています。 operations ヘルパーは、更新中にアイテムの属性に対してさまざまなアクションを実行するために使用できる関数を提供します。利用可能なヘルパーは以下のとおりです。 add() ：属性をネストした複雑な構造を含む、新しい属性を追加します remove() ：アイテムから属性を削除します replace() ：既存の属性 (または入れ子になった属性) を更新時に置き換えます increment() ：指定した数だけ属性をインクリメントします decrement() ：属性を指定した数だけデクリメントします append() ：属性の末尾に項目を追加します： 属性リストの最後に項目を追加します prepend() ：属性リストの先頭に項目を追加します updateListItem() ：リストの特定のインデックスの項目を更新します operations ヘルパーを使用すると、以下のように、JavaScript リゾルバで複雑な更新操作を数行で書くことができます。 import { update, operations as ops } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { const updateObj = { count: ops.increment(1), friends: ops.append(['John']), address: ops.add({ street1: '123 Main St', street2: 'Unit A', city: 'New York', zip: '10001' }), pets: [ops.updateListItem('rex', 2)], }; const condition = { friends: { size: { lt: 5 } }, id: { attributeExists: true } }; return update({ key: { id: 1 }, update: updateObj, condition }); } 上のコードの更新リクエストでは以下を行っています。 count 属性のインクリメント フレンドリストに “John” をフレンドとして追加 アイテムに住所の追加 pet 属性の 3 番目のエントリの値を変更 更新は、指定されたキー ( id) を持つアイテムが存在し、友達リストのサイズが 5 未満である場合にのみ許可されます。 モジュール関数の詳細については、 AppSync ドキュメント を参照してください。これらの新しい関数の使用方法については、 AWS AppSync examples リポジトリ を参照してください。 まとめ 本記事では、AppSync リゾルバのリゾルバロジックを簡素化する DynamoDB の新しいJavaScriptモジュールについてレビューしました。さらに、AWS AppSync を簡単に使い始める方法と、新しいモジュールを使用するリゾルバの書き方についても説明しました。JavaScript のリゾルバや DynamoDB の新機能の詳細については、 ドキュメント や チュートリアル を参照してください。また、使いやすいサンプルやガイドは samples リポジトリ にあります。 本記事は、 Introducing new AWS AppSync module and functions for DynamoDB JavaScript resolvers を翻訳したものです。翻訳はソリューションアーキテクトの 稲田大陸 が担当しました。

この記事は、 Simulating Automotive E/E Architectures in AWS – Part 1: Accelerating the V-Model を翻訳したものである。 過去15年の間に、自動車内の電子制御ユニット（ECU）、関連するセンサー、アクチュエーター、配線を含む自動車の電気／電子（E/E）アーキテクチャの複雑さが増しています。自動車メーカーは、E/E アーキテクチャに新たなハードウェア・コンポーネントを追加し続けるのではなく、小型の単体 ECU を大型の高性能コンピュータ（HPC）に統合し、少数の分散型 ECU を維持する方向にシフトしています。これは、配線の削減や車両の軽量化など、自動車メーカーにメリットをもたらします。これらの HPC の計算能力を利用して、自動車メーカーは、 リッチで新しいユーザーエクスペリエンス と 頻繁なソフトウェアアップデート を備えたソフトウェアプラットフォーム全体を構築しています。最新の E/E アーキテクチャでは、HPC と単体 ECU が混在して使用されるため、これらの相互運用を検証する必要があります。そのため、自動車業界ではサブシステム全体の仮想検証に対する需要が高まっています。 このブログシリーズは2部構成になっています。パート1では、自動車の E/E アーキテクチャのトレンドと、クラウドを活用した ECU ソフトウェアのシミュレーションに関して自動車メーカーが直面する一般的な概念と課題について説明します。 パート2 では、自動車メーカーが AWS と dSPACE テクノロジを使用して自動車 E/E アーキテクチャのシミュレーションを行う方法について説明します。dSPACE VEOS とAWS Graviton を活用したネイティブ ARM for HPC のイメージを組み合わせて使用します。 最新の自動車 E/E アーキテクチャ 最近の自動車 E/E アーキテクチャでは、関連機能をドメインコントローラに統合することで、多数の単一機能モジュールを管理する複雑さに対処しています。これらの「ドメイン集中型アーキテクチャ」には、ADAS（先進運転支援システム）やパワートレインなどの主要なドメインごとに主要な計算ユニットが含まれています。ドメイン・コントローラーは、ゲートウェイを介して互いに通信し、インフォテイメント・ドメインに関連する画面上で ADAS アプリケーションのステータスを監視するようなクロスドメイン機能を可能にします。センサーやアクチュエーターは、CAN、LIN、車載イーサネットなどの車載バスを介してドメイン・コントローラーに接続されます。 自動車メーカーが部品点数をさらに削減する方法を検討するにつれ、「車両集中型アーキテクチャ(ゾーンアーキテクチャ)」の人気が高まっています。ドメイン・コントローラで提供される機能をさらに統合し、1桁台の数の HPC で置き換えることができるようになりました。高速イーサネット接続を通じて、HPC はゾーン ECU と通信する。一握りの HPC が車両全体の特定の位置に配置され、周辺のすべてのセンサーとアクチュエーターに接続されます。これにより、図1に示すように車両内部の配線が削減されます。 図1：E/E アーキテクチャ概念図 物理的な ECU の数が減っても、自動車ソフトウェアのテストや検証の労力が減るわけではありません。車両集中型アーキテクチャは、より複雑な自動車ソフトウェア（クロスドメインなど）を可能にし、車両のライフサイクルにわたって、追加のコネクティビティ（V2X など）、継続的なソフトウェア更新、新しいソフトウェア機能を実現します。 自動車ソフトウェア開発モデル 現代のソフトウェア開発において、開発者は DevOps を取り入れています。DevOps とは、組織がアプリケーションやサービスを高速で提供する能力を高める、文化的哲学、実践、ツールの組み合わせです。継続的インテグレーション（CI）は、開発者が定期的に中央のリポジトリに作業をマージし、そこで自動化されたビルドとテストを実行できるようにするために必要です。CI の主な目標は、ソフトウェアの品質を向上させ、機能のアイデアからリリースまでの時間を短縮するために、バグを早期に発見し対処することです。 しかし、自動車業界では、機能安全に関する ISO-26262 や ASPICE （Automotive Software Process Improvement and Capability dEtermination、ISO/IEC 15504に基づく）のような設計標準が存在し、自動車用ソフトウェアコンポーネントの設計をどのように行うかに対応しています。ISO-26262 と ASPICEは、伝統的なウォーターフォールモデルに基づく開発プロセスである V モデル に基づいています。ウォーターフォールモデルは、ソフトウェア開発に対する直線的なアプローチであり、各フェーズが完了してから次のフェーズに入る。自動車メーカーやサプライヤーが採用しており、開発プロセス全体を通じてテストと検証の必要性を強調しています。Vモデルは2つのフェーズからなり、左側が「設計」フェーズ、右側が「検証フェーズ」です。これを図2に示します。 図2：自動車 V モデル開発プロセス 設計フェーズでは、開発者はテストフェーズで検証を開始する前に、システム設計、仕様、要件を前もって定義します。このプロセスは、リリース・サイクルの遅延やバグやエラーの発見を遅らせる結果になりかねません。自動車メーカーが、最新の DevOps が提供するスピードと俊敏性を利用しつつ、業界が求める設計標準をサポートする方法を必要としていることは明らかです。 “Shift-Left” AWS と dSPACE は、クラウド上のシミュレーション技術を使用して、車両集中型アーキテクチャシステムの検証と検証を “Shift-Left “することに取り組んでいます。これらのシミュレーション技術により、自動車業界は、テストケースを並行して実行することで、通常 V モデル内で定義される検証プロセスを加速することができます。これには、開発サイクルの早い段階でテストを行い、問題を修正するのが難しくコストもかかるプロセスの右側を待つのではなく、クラウドで大規模にテストを可能にすることが必要です。クラウドネイティブな DevOps とシミュレーションを使用して不具合を早期に発見することで、エンジニアはコストのかかるエラーのリスクを低減し、ソフトウェア全体の品質向上に貢献できます。Shift-Left テストは、より頻繁なフィードバック・ループとコストのかかる問題の早期発見を可能にするため、コスト削減と市場投入のスピードアップにも役立ちます。 “Shift-Left” モデルは、完全なソフトウェア環境で必要とされるテストの数を増やす一方で、HIL（Hardware in the Loop）システムを使用したシステムおよび統合の必要性を減少させるものでありません。Shift-Left モデルは、開発サイクルの早い段階でのテストに重点を置くようにすることです。自動車のソフトウェア開発チームは、より費用対効果の高い SIL(Software-in-the-Loop) テストによって V モデルを迅速に反復することで、クラウドネイティブの DevOps によって提供されるよりアジャイルな開発手法を利用することができます。開発プロセスにこれらの手法を適用することで、品質が向上し、V モデルの意図に忠実であり続けることができます。 シミュレーションモデル 完全に仮想化されたシミュレーションシステムを組み合わせ、実験を行い、テストを自動化する前に、E/E のすべてのコンポーネントが仮想環境に適していなければなりません。車両集中型アーキテクチャの場合、これらのコンポーネントにはエッジ、ゾーン ECU、HPC が含まれます。バーチャル ECU を入手できない場合は、実際のセンサーやアクチュエーターの特性をエミュレートするシミュレーションモデルを作成することができます。シミュレーションモデルにはいくつかの種類があり、プラントモデル、環境モデル、レストバスモデルに分類できます。すべての仮想コンポーネント間の通信を確立するためには、必要に応じて仮想 I/O 接続とバスを設定することも重要です。図3は、目標とするシミュレーション・システムの代表的なブロック図です。 図3：シミュレーションシステムの I/O とモデル表現 すべての制御ユニットを仮想化することが、仮想シミュレーションシステムを構築するための鍵となります。一般的なアプローチを説明するために、ECU と HPC の4つの主要レイヤーを図4に示すハイレベルスケッチで考えてみましょう。 図4：ECU レイヤーのブロック図 特定の周辺機器や接続を備えたターゲット・ハードウェアに依存する代わりに、コンポーネントはターゲット・ハードウェアから切り離された開発環境内で実行できるようにする必要があります。 さらに説明するために、ゾーン・アーキテクチャに関連する2種類のオペレーティング・システムを区別することが役に立ちます： OSEK OS-like と  POSIX である。これらのオペレーティングシステムは、異なる組み込みプラットフォーム間での互換性を可能にする標準に準拠しているため、ハードウェア依存からソフトウェアを抽象化する上で重要です。 エッジ ECU とゾーン ECU は、一般的に OSEK OS のような OS の上に構築されています。これらはマイクロコントローラ上で動作し、フットプリントが小さくリアルタイムアプリケーションに最適化されているため、組み込みプログラミングに非常に適しています。 AUTOSAR Classic プラットフォーム は、OSEK-like なスタックの一例です。dSPACE VEOS の主な機能の1つに、この種のコンポーネントのシミュレーションがあります。 dSPACE VEOS  のクラウドベースのシミュレーション dSPACE VEOS は、ECU ソフトウエア検証用のシミュレーションプラットフォームです。特定のシミュレーションハードウエアに依存することなく、ファンクションモデル、FMU（Functional Mock-up Unit）、仮想 ECU（V-ECU）、車両モデルなど、さまざまなモデルを幅広くサポートしています。 VEOS は、車載イーサネット、CAN、LIN  バス通信を、バス特有の効果をすべて含めて、ハードウェアを追加することなくシミュレートできるため、仮想 ECU ネットワークに関連するバスシミュレーションのニーズにも対応します。 既存のツールを接続して使用するためのオープンインターフェースにより、VEOS は、異なるサブシステムを分散してモデリングおよびシミュレーションできる、 コ・シミュレーション セットアップもサポートしています。コ・シミュレーションにより、異なるツール間での時間同期や相互作用が可能になります。 VEOS は標準的な PC（Windows および Linux）上で動作し、クラウドベースのソリューションへの統合も容易なため、機能開発者、ソフトウェアアーキテクト、ECU テスターは、SIL テストのためのさまざまな貴重な選択肢を得ることができます。 エッジ ECU とゾーン ECU をシミュレートするために、VEOS は、アプリケーションレイヤーと基本ソフトウェアのさらなる部分を VEOS で実行し、x86環境で実行できるように調整された OS を提供します。 VEOS は、I/O とバスドライバーを抽象化するためのモジュールをいくつか提供しています。そのため、OSEK ベースのコンポーネントを実行し、I/O およびバスレベルで接続することができます。 図5：AWS 上でのエッジ/ゾーン ECU シミュレーション OS / Kernel /ドライバー レイヤーを調整することで、チップシミュレーションを回避し、シミュレーションの妥当なパフォーマンスを達成することも可能です。もちろん、意味のあるシミュレーション結果を得るためには、その調整が動作に大きな影響を与えないようにする必要があります。 もう一つのカテゴリーである POSIX は、一般的にゾーン・アーキテクチャの高性能コンピュータ（HPC）に関連しています。HPC は、性能、アーキテクチャの点で IT サーバーに近く、要求の厳しいアルゴリズムを実行する機能を提供する一方で、高い信頼性を維持する必要があります。 高性能である一方、エネルギー効率に優れている必要があり、自動車メーカーは、HW アクセラレータと組み合わせて、このような HPC の計算コアとして Arm ベースのプロセッサを採用しています。HPC は、車載インフォテインメントや ADAS のようないくつかの領域ですでに好まれており、SDV（Software-Defined Vehicle）における計算環境の成功要因になることが期待されています。 HPC シミュレーションのための AWS Graviton AWS は、 AWS Graviton と呼ばれるカスタム64ビット Arm ベースプロセッサを提供しており、クラウドワークロード向けに最大40%の最適価格での性能向上を実現するよう設計されています。HW アクセラレータを含む、より多くのインスタンスタイプにこれらのプロセッサオプションを搭載することで、自動車開発者は、組み込み自動車プラットフォームでも使用されている同じ Arm の知的財産（IP）とツールを使用して、POSIX ベースの HPC アプリケーションとツールチェーンを開発し、実行することができます。これにより、クロスコンパイルの必要なく、Arm 命令セット・アーキテクチャを直接実行することができます。 図6：AWS 上の HPC シミュレーション しかし、AWS Graviton ベースのシステムは、車両で利用される SoC や ECU と100％同一ではないことに注意することが重要です。たとえば、これらのクラウドシステムには物理的な CAN バスはありません。AWS と dSPACE は、開発サイクルのかなり早い段階で SIL 機能を解放および強化することにより、価値の提供を支援しています。したがって、HIL 検証も引き続き必要条件となります。CPU パリティなどの側面を直接考慮し、入力と出力の違いを再生メッセージングを使用してさらにシミュレートすることができます。自動車エンジニアは、システムに存在しないハードウェア周辺機器をシミュレートまたはエミュレートすることもできます。 このアプローチを成功させるためには、自動車分野で利用されるハイパーバイザーやオペレーティングシステムを開発しているソフトウェアベンダーも AWS Graviton 上で動作させるように協力していく必要があります。今日、我々は、 Blackberry QNX や 組み込み Linux のような、自動車で使用されるいくつかのAmazon Machine Images（AMI）がすでに AWS Graviton 上でネイティブに動作する形で提供されています。 まとめ このブログシリーズ Part2 では、dSPACE と AWS がどのように AWS 上で自動車 E/E アーキテクチャのシミュレーションを実現しているかをご紹介します。このブログでは、ソリューションの技術的な詳細とスケールを実現するためのアプローチについて説明します。 このソリューションの詳細については、 dSPACE または AWS にお問い合わせください。 TAGS:  automotive , hpc , Simulation , software defined vehicle Fabian Bronner Fabian Bronner は、自動車業界向けの Software-in-the-Loop ソリューションに特化した dSPACE のビジネスデベロッパーです。完全に仮想化された環境で自動車用ソフトウェアを大規模にテストする機能を開始または拡張したいお客様をサポートしています。新しい要件や課題について学ぶと同時に、パートナーやお客様と一緒にコンセプトを開発し、急速に進化する業界を一緒に形成しています。デジタルとコネクテッドな世界のバランスを取るために、ファビアンはオフラインでヨットに乗ることを楽しんでいる。 Jeremy Dahan Jeremy Dahan は、Amazon Web Services の Automotive Compute Sr Tech GTM Specialist です。クラウド機能を活用して、自動車用ソフトウェアに関する最も困難な問題に取り組む顧客やパートナーを支援している。自動車業界で10年以上の経験があり、特に組込みソフトウェアと最近ではクラウドに詳しい。AWS上でプロダクトを構築していないときは、自動車/IoT センサーをいじっている。 Jerry Bonnah Jerry Bonnah は、Amazon Web Services のシニアパートナー・ソリューションアーキテクトです。コネクテッド・ビークル・テクノロジーを中心とした自動車業界を専門とし、パートナーと緊密に連携してこの分野の新製品や新機能の設計、共同開発、共同開発を行う。テクノロジーリーダーシップ、ソリューションアーキテクチャ、新製品立ち上げにおいて10年以上の経験を持つ。AWS 上でプロダクトを構築していないときは、AWS 上で次に何を構築できるかを考えている。 Luke Harvey Luke Harvey は、Amazon Web Services のプリンシパル・パートナー・ソリューション・アーキテクト。AWS のグローバル自動車パートナー戦略の責任者であり、戦略パートナーがクラウドを活用して最先端のソリューションを構築、マーケティング、販売できるよう支援する。自律走行車とコネクテッド・ビークルのテクノロジーにおいて、10年以上自動車業界をリードしてきた経験を持つ。AWS で物事を構築していないときは、ミシガン州で家族と養蜂に時間を費やしている。 Moritz Schniedermann Moritz Schniedermann は dSPACE のアプリケーションエンジニアで、エンジニアリングおよび事前開発活動を担当しています。ECU のデータ再生と仮想化に関する専門知識を生かし、自動車用ソフトウエアがハードウエア段階に到達する前に、その機能性と信頼性を保証しています。SIL シミュレーションをさまざまなコシミュレーションシナリオで活用することにより、自動車業界における最先端のシミュレーションソリューションの発展に貢献しています。 このブログは、シニアソリューションアーキテクトの渡邊翼が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 突然ですが、みなさんAWSome Dayをご存知でしょうか？ AWSは AWSome Day Online Conference というAWSクラウドの基礎を3時間で学ぶオンラインイベントを開催しています。 次回2023年11月16日(木)が年内最後の開催予定となりますのでご興味ある方はこの機会を逃さずにご登録をお願いします！ それでは、先週の主なアップデートについて振り返っていきましょう。 2023年9月18日週の主要なアップデート 9/18(月) Amazon EBS Multi-Attach on io2 volumes now supports NVMe reservations Amazon EBS io2でのMulti-Attach volumeがNVMe reservationsによるストレージフェンシングをサポートしました。今回のアップデートにより柔軟な排他制御が可能になり、例えばSQL Server フェールオーバー クラスター インスタンス(FCI)などのストレージフェンシングを必要とするアプリケーションを単一のアベイラビリティゾーンにデプロイできるようになりました。詳細については ブログ もご確認ください。 Amazon RDS Performance Insights supports SQL-level metrics for Amazon RDS for SQL Server Amazon RDS Performance InsightsがAmazon RDS for SQL ServerのSQL レベル メトリクスをサポートしました。これにより実行回数の多い、実行時間が長い、あるいは実行中に停止したSQLクエリを簡単に特定できるようになりました。 9/19(火) Announcing general availability of Amazon EC2 M2 Pro Mac instances for macOS Amazon EC2 M2 Pro Mac インスタンスがGAしました。M2 Pro Mac インスタンスはApple M2 Pro Mav Miniコンピューターで構築されており、Appleプラットフォーム向けのアプリケーション構築やテストの際に既存のM1 Mac インスタンスより最大35%速いパフォーマンスを実現します。米国西部（オレゴン）と米国東部（オハイオ）のリージョンでご利用いただけます。 9/20(水) Amazon RDS for Oracle supports M6i, R6i, and R5b instances in new regions Amazon RDS for OracleのM6i、R6i、R5bサポートリージョンが追加されました。M6iインスタンスは新たに大阪を含む9リージョン、R6iは大阪を含む8リージョン、R5bは6リージョンでご利用いただけます。 Announcing Swift Package Manager support in AWS CodeArtifact AWS CodeArtifactのSwift パッケージ マネージャー(SwiftPM)サポートがGAされました。前日のM2 Pro Mac インスタンス同様Appleプラットフォーム向けのアプリケーション開発をサポートするアップデートになります。 AWS CodeArtifactのSwiftPMサポートは東京を含む13のCodeArtifactを提供する全リージョンで利用可能です。 Amazon Location Services announces a price reduction of up to 75% for tracking and geofencing Amazon Location Serviceの値下げが発表されました。月間の利用料に応じて4段階の料金モデルが提供されるようになったことで位置情報追跡時に利用するトラッキングの書き込みが最大75%、追跡対象が指定範囲に入った際の通知等に利用するジオフェンシングの位置評価が最大70%値下げになります。この値下げは2023年9月1日付で適用され自動的にAWSの請求に反映されます。 9/21(木) Amazon Corretto 21 is now generally available Amazonの提供するOpenJDK21ディストリビューションであるAmazon Corretto 21がGAしました。このバージョンは長期サポート（LTS）の対象になっており、Linux、Windows、およびmacOSで利用できます。OpenJDK21の特徴的な機能の詳細は What’s Newの記事 や OpenJDKのプロジェクトページ をご確認ください。 Simulate interruptions in your Spot Fleet directly from the Amazon EC2 Console Amazon EC2のコンソールから直接スポットフリートに対してインスタンスの中断を注入できるようになりました。2022年にAWS Fault Injection Simulator (FIS)を使用して単一のEC2スポットインスタンスの中断をシュミレートできる機能がリリースされましたが、その機能が強化され、スポットフリートに対応した形になります。この機能はFISを利用できるすべてのAWSリージョンで利用可能です。 9/22(金) Amazon DocumentDB (with MongoDB compatibility) supports in-place major version upgrade Amazon DocumentDB (MongoDB 互換)がバージョン3.6, 4.0からバージョン5.0への既存クラスタのメジャーバーションアップグレード(MVU)をサポートしました。これまではデータベース移行ツールやバックアップしての対応が必要でしたが、AWSコンソール、SDKやCLIと使用して一括アップデートすることが可能です。詳細は ドキュメント もご確認ください。 AWS App Runner launches improvements for Auto-Scaling configuration management AWS App Runnerのオートスケーリング設定(ASC)をより柔軟に管理できるようになりました。これまでASCリソースの管理には一定の制限があり、既存のASCの更新やデフォルトASCを設定することができませんでした。今回の改善によりApp Runnnerを作成するときのデフォルトASCを設定したり、既存のASCの更新、使用するACSの一覧表示等が可能になりました。詳細については ドキュメント もご確認ください。 9月も最終週になり、地域によっては朝晩は冷え込むようになってきました。どうぞ体調にお気をつけてください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

このブログは 2023 年 8 月 30 日に Katja Philipp、Jonas Bürkel、Steffen Grunwald によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 このブログ記事シリーズでは、持続可能性を目的として AWS の使用を最適化したいと考えているチーム向けに、持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法の概要を説明します。 パート I では、持続可能性に関するプロキシメトリクスと重要業績評価指標 (KPI) の動機について説明しました。使用量ベースのメトリクス、正規化、ビジネスメトリクスの組み込みの概念を説明し、お客様がこれらのメトリクスを使用して持続可能性を最適化する方法の例を共有しました。 パート II では、持続可能性と効率化のベストプラクティスを組織的に大規模に採用するために AWS の利用を最適化したいチーム向けに、プロキシメトリクスデータパイプラインを設定してサステナビリティプロキシメトリクスのショーバックメカニズムを確立する方法について説明します。 プロキシメトリクスパイプラインの設定 以下の図 1 は、プロキシメトリクスデータパイプラインの概念的な概要を示しています。1 つの管理アカウントと複数の子アカウントで構成され、さまざまなワークロードが実行されているマルチアカウント構造を想定しています。1 つの中央最適化アカウントがすべてのワークロードアカウントからのコストとリソースの使用状況データの取り込み、処理、視覚化を担います。 AWS では、このようなマルチアカウントガバナンス戦略は通常 AWS Control Tower を使用して実装され、AWS ランディングゾーンと呼ばれます。この構成では、 AWS Organizations を使用してアカウントを組織単位 (OU) の下に階層的に構造化します。図示されている最適化アカウントは通常、組織のインフラストラクチャ OU の一部であり、ワークロードアカウントはワークロード OU の一部です。 リソースのタグ付け 戦略を導入することを強くお勧めします。これは、キーと値のペアの形式でメタデータを割り当てることにより、リソースを一貫して分類およびグループ化するためのベストプラクティスです。これにより、後で特定のメトリクスに含めるリソースの範囲をきめ細かく定義できます。 図 1 : サステナビリティプロキシメトリクスデータパイプライン これを踏まえて、最初のプロキシメトリクスパイプラインを確立するには以下が含まれます。 設定したユーザー定義の コスト配分タグ を含めて組織の管理アカウントに保存する AWS コストと使用状況レポート (CUR) を作成し、中央最適化アカウントに複製します。CUR は、すべての AWS サービスの詳細な消費情報を得るための主要なデータソースです。 アカウントとワークロード固有のメトリクスをそれぞれのワークロード OU から中央最適化アカウントに定期的にプッシュします。目的は CUR ではカバーされないメトリクスの計算に必要な追加のデータポイントを取り込むことです。 Amazon CloudWatch では、複数のソースアカウントとリージョンからログとメトリクスをキャプチャします。複数のアカウントのログとメトリクスを処理するさまざまな方法については、AWS の規範ガイダンス「 集中型または分散型アカウントでの CloudWatch の使用 」をご覧ください。 AWS Compute Optimizer は、使用率に関する情報や適切なサイジングに関する推奨事項を提供する優れた情報源です。Compute Optimizer はリージョン別のサービスであるため、複数の地域から中央最適化アカウントにデータを収集する必要があります。詳細な手順については、 Compute Optimizer Data Collection lab をご覧ください。 ワークロードによっては、追加のメトリクスが必要になります。対応する AWS Well-Architected lab の Data Collection Modules をチェックして、他のメトリクスソースを統合する方法を確認してください。 プッシュまたはプルメカニズムを使用してビジネスメトリクスを取り込み、最適化アカウントの中心的な S3「メトリクスレイク」バケットを形成します。目的のメトリクスに応じてソースデータはデータウェアハウス、データベース、またはモニタリング / オブザーバビリティシステムに配置されます。ビジネスメトリクスを AWS リソースの使用状況と簡単に集計するには、そのデータを時系列形式で利用できる必要があります。 次に、メトリクスレイクバケット内のすべてのデータ（CUR、AWSメトリクス、ビジネスメトリクス）がカタログ化され、定期的に抽出、クリーンアップ、変換されて視覚化できるようになります。処理されるデータセットは時間ベースで、通常、(1) 適用可能な時間枠、(2) 識別基準となるワークロードメタデータタグまたは AWS アカウント、(3) 正規化に使用されるビジネス指標 (分母) の 3 つの要素で構成されます。 サステナビリティのプロキシメトリクスと KPI はグローバルダッシュボードに表示され、通常は 1 時間ごとのデータ粒度で毎日更新されます。 図 1 は、上記の点がプロキシメトリクスパイプラインの特定のステップとどのように関連しているかを示しています。始めるための簡単なステップバイステップガイドとして、AWS Well-Architected lab の Turning Cost & Usage Reports into Efficiency Reports をご覧ください。 Visualize the data for impact サステナビリティのプロキシメトリクスと KPI を、最適化の機会と企業目標の達成レベルを理解したいと考えている経営陣と KPI を所有するアプリケーションチームという 2 つの主要な対象者に伝えます。最適化の前提と実験を検証して次の最適化の機会を見極めるためには、わかりやすくアクセスしやすいものでなければなりません。その例を以下の図 2 に示します。詳細については、Amazon Builders’ Library に 運用を可視化するためのダッシュボードの構築に関する詳細情報 が掲載されています。 図 2 : サステナビリティプロキシメトリクスダッシュボード コンピュートプロキシメトリクスについては、まず以下の可視化から始めてください。 さまざまなアカウント ID またはワークロードタグでの全体的なコンピューティングリソース使用量を視覚化して、Amazon EC2、 AWS Fargate 、 AWS Lambda の比率を確認します。 特定のワークロードタグ (タグ付け戦略が導入されていない場合はアカウント ID) の EC2 インスタンスタイプ別のコンピューティングキャパシティを視覚化します。これは最適化をどこから始めるべきかを示す一般的なグラフです。主な要因は一番上にあります。 さらにドリルダウンしてあるアプリケーションの経時的な使用状況を、そのアプリケーションのビジネス指標で標準化して表示することを想像してみてください。 お客様には、例えば AWS Graviton や Amazon EC2 スポットインスタンスを採用するという目標があります。導入率を時系列で視覚化します。 プロセスにおけるサステナビリティプロキシメトリクスの確立 サステナビリティプロキシメトリクスダッシュボードは、AWS のコストと使用状況レポートを使って計算されます。通常、このデータはすでにクラウドセンターオブエクセレンス (CCoE)、FinOps、またはクラウドコスト効率化チームによってコスト管理に使用され、理解されています。サステナビリティプロキシメトリクスによって確立されたコストショーバックプロセスを拡張することで、ゼロから始めるのではなく会社にとって何が有効で何が効果的でないかについて過去に学んだことを活用できます。ショーバックメカニズムの継続的な開発のためのスポンサーとプロダクトオーナーを定義しましょう。開発は 1 回限りの作業ではなく、フィードバックを集めて取り入れ、効果のある新しいメトリクスやビジュアルを実装する必要があります。メカニズムの価値を最大化するために、役に立たない邪魔になるビジュアルやデータを削除してください。 200 以上の AWS クラウドサービスにより、追跡、視覚化、最適化の可能性が数多くあります。まず、 持続可能性に関する責任共有モデル で最もシェアが高い、組織内でよく利用されているサービスから始めてください。例えば EC2 インスタンスの場合、あなたがインスタンスサイズやファミリーを制御でき、利用状況を所有し、インストールされたソフトウェアの効率性を管理できるインスタンスから始めましょう。 ポリシーを使用してデータセットのライフサイクルを管理したり 、必要に応じて ビルド環境のスケジュールを設定 したり、 マネージドサービスに移行 したりするなど、リソース効率に継続的に影響する AWS Well-Architected 持続可能性の柱のベストプラクティス から得られる影響の大きい手間のかからない成果に焦点を当ててください。サービスの消費量が最も多いアカウントに焦点を当てた AWS Well-Architected Framework レビューのパイロット版を実施してください。 個々のアプリケーションチームがダッシュボードを利用できるようにして、チームミーティングや運用レビューなどで自由に利用できるようにします。メールレポートも同様に機能しますが、ドリルダウンのようなインタラクティブなコントロールが欠けていてすぐに時代遅れになります。個々のチームや会社全体へのデータの可視性について問い合わせてください。 最適化の成果をリーダーに見えるようにして、成功を再現しましょう。最適対策前後のサステナビリティ KPI を活用して、成功を伝えましょう。金銭的利益を重視するステークホルダーと、関連する費用対効果を共有できます。AWS Customer Carbon Footprint Tool の長期データで数字を補足してください。成功を祝い、リーダーシップが可視化されることで、持続可能な行動に対する意識と認識が高まります。最適化の詳細を共有することで、他のチームもそのアプリケーションの成功を再現するようになります。 結論と次にすべきこと この投稿では、プロキシメトリクスのデータパイプラインを確立する方法、効果的なビジュアル、ショーバックメカニズムを確立するためのベストプラクティスを説明しました。実際にこの理論を使って、アプリケーションのサステナビリティプロキシメトリクスの測定と最適化を適用するために、 CUDOS Sustainability Dashboard ワークショップ で段階的な実装手順とベストプラクティスを紹介しています。 持続可能性のためにワークロードを最適化する方法に関する詳細情報をお探しの場合は、 AWS Well Architected 持続可能性の柱 と AWS re: Invent 2022 セッションの Delivering sustainable, high-performing architectures (SUS303) をご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 Katja Philipp Katja Philipp は、ドイツのミュンヘンに拠点を置くアマゾンウェブサービスのサステナビリティソリューションアーキテクトです。彼女は、顧客がクラウド、テクノロジー、データを活用して持続可能性に関する課題を解決し、リソース効率を重視した設計を行えるように支援しています。Katja は、持続可能性と、より良い未来に向けて現在の課題を解決するためにテクノロジーをどのように活用できるかに情熱を注いでいます。 Jonas Bürkel Jonas Bürkel は、ドイツを拠点とする AWS のソリューションアーキテクトです。製造業のお客様が、独自のビジネス要件や技術要件を満たすソリューションをクラウドで構築できるよう支援しています。Jonas は、持続可能性や、テクノロジーがどのように効率化に役立つかにも情熱を注いでいます。 Steffen Grunwald Steffen Grunwald は、アマゾンウェブサービスのプリンシパルソリューションアーキテクトです。クラウドを通じてお客様が持続可能性の課題を解決できるようサポートしています。ソフトウェアエンジニアリングのバックグラウンドが長く、持続可能性、パフォーマンス、コスト、運用効率を高め、イノベーションのスピードを上げるために、アプリケーションアーキテクチャと開発プロセスを深く掘り下げることが大好きです。

このブログは 2023 年 8 月 11 日に Katja Philipp、Jonas Bürkel、Steffen Grunwald によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 持続可能性は、顧客、従業員、規制当局、投資家、パートナーにとって重要な意思決定要素となっています。顧客は持続可能な事業と運営への道を歩み始めています。IT インフラストラクチャを構築、導入、維持している場合、環境への影響を減らすことは、全社的な持続可能性目標を達成するための重要なステップです。そのため、現代のソフトウェアやシステムアーキテクチャでは、セキュリティ、保守性、信頼性などと並んで、持続可能性は非機能要件になりました。 クラウドでワークロードを設計する場合、持続可能性は AWS とお客様の間で 共有される責任 です。AWS がクラウドの持続可能性を最適化することで、お客様はクラウド内の持続可能性に責任を負うことになります。お客様はサービスの利用とリソース効率を最適化します。 このブログ記事シリーズでは、持続可能性の観点から AWS の使用を最適化したいと考えているチーム向けに、持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法の概要を説明します。パート I では、プロキシメトリクスの概念と正規化の重要性について紹介します。また、お客様がこの概念をどのように利用してアプリケーションの環境への影響を軽減したかの例も示します。 プロキシメトリクスでワークロードを最適化 すべての最適化は、メトリクスや KPI に基づいた目標 (コスト削減、パフォーマンスの向上、温室効果ガス排出量の削減) から始める必要があります。 AWS Customer Carbon Footprint Tool (CCFT) は、お客様の AWS サービスの使用に伴う温室効果ガス排出量の重要なアウトプットメトリクスを提供します。この排出データは、月次ベースでの大まかな影響の報告と把握に使用されます。ただし、AWS が CCFT の対象スコープの拡大と対象サービス粒度の改善に取り組んでいる一方で (この ブログ を読んでください)、継続的な最適化サイクルを実践するにはきめ細かなメトリクスが必要です。絶対排出量だけではワークロードの効率は明らかになりません。排出量は、アプリケーションの使用状況やエネルギーの炭素強度などアプリケーションチームが責任を負わない要素を含む、複数の要因による結果です。 これらの目的のために、AWS Customer Carbon Footprint Tool によって報告された二酸化炭素排出量をサステナビリティプロキシメトリクスと呼ばれる従属メトリクスで補完しています。また、クラウドインテリジェンスダッシュボードの一部として、サステナビリティプロキシメトリクスダッシュボード ( このリンク からダッシュボードにアクセスできます) も公開しました。 優れたサステナビリティプロキシメトリクスは、二酸化炭素排出量のきめ細かい代替手段となりワークロードの効率に関する洞察を提供します。メトリクスはほぼリアルタイムで追跡され、アプリケーションチームやリソースに分類されるため、最適化サイクルタイムを短縮するのに適しています。コンピューティング、ストレージ、ネットワーキングの観点から見たリソースの使用状況を反映する具体的なメトリクスです ( こちらのブログをお読みください )。 図 1 : AWS 排出量の概要 図 1 に示すように、AWS サービス使用時の 温室効果ガス排出量 の計算は、複数のデータソースに依存します。これには、クラウドリソースの運用に必要なエネルギー (スコープ 1 と 2) と、バリューチェーンの上流と下流の物理資源のライフサイクルに関連する間接的な排出量 (スコープ 3) が含まれます。同様に、コストは AWS のサービスの使用状況によって決まる単純な関数です。ただし、コストは使用量を反映しているとしても、ボリュームベースの割引はコストを削減しますが関連する排出量は削減しません。また、特定のサービスの料金体系にはリソース使用量のあらゆる側面が反映されているわけではありません。全てのサービスのリージョンへのインバウンドのデータ転送に料金がかからないことやデータ転送先のお客様の距離の違いによって転送料金が変わらないことを考えてみてください。AWS サービスの利用状況は、図中の左側のデータフローのようにお客様の業務プロセスに依存し、ビジネスニーズを満たすために利用されます。これらはすべて、効率化と最小限のリソースでビジネスニーズを満たすことに帰着します。 比較できるようにメトリクスを正規化 お客様がリソース消費量を定量化するために、Amazon EC2 インスタンスの数を数えたり、インスタンスの稼働時間をカウントすることがあります。これらのメトリクスはアプリケーションの比較、消費量の主な要因の特定、トレンドの特定には役立ちません。一部のアプリケーションでは終了前の数分間のみインスタンスを実行します。また、1 か月間 1 つのインスタンスを実行するアプリケーションもあります。同様に、インスタンスのサイズも重要です。インスタンスの稼働時間だけを利用するのではなく、インスタンスの vCPU の数を考慮に入れる必要があります。これを正規化と呼びます。 正規化する方法はたくさんあります。 リソース使用量の正規化 : インスタンスタイプに関する情報を使用し、インスタンス稼働時間に vCPU の数を掛けます。あるいは、Amazon EC2 リザーブドインスタンスで使用されているような 正規化要素 を考慮に入れることもできます。Amazon S3 や Amazon EBS など、GB 時間を使用する他のサービスにも同じことが当てはまります。 KPI については、総使用量に対する希望使用量の比率を計算します。CPU 使用率についてはすでにそのようになっています。 Amazon EC2 のスポット 導入が目標の場合、すべてのスポット時間をすべての vCPU 時間で割った値になります。また、 AWS Graviton を採用する場合は、すべての Graviton の vCPU 時間を合計 vCPU 時間で割った値になります。この種の KPI について、アプリケーションチームの最小目標パーセンテージを定義します。 スコアリングシステムを使用してサービスと機能に異なる重み付けを行い、アプリケーションチームがリソース効率の高いサービスを利用するように促します。例えば、Amazon S3 Standard ストレージクラスを Amazon S3 Intelligent-Tiering よりも高く重み付けします。これは、AWSにとって Amazon S3 Intelligent-Tiering の方がサービスを提供するためのエネルギーとハードウェアの使用量が少なくなるように最適化できる柔軟性があるからです。アプリケーションチームの目標は重み付けされた使用量を減らすことです。 リソース効率とはビジネスニーズを満たすために使用するリソースを最小限に抑えることです。KPI またはメトリクスでは、リソース使用量をビジネスユニットのメトリクスで標準化することでこれを考慮に入れる必要があります。これについては次のセクションで詳しく説明します。 ビジネスメトリクスによる正規化 ビジネスが成長してもリソース使用量の増加は憂慮すべきものではありませんが、顧客の需要が減少してもリソース消費が継続していることは警戒すべきことです。KPI にビジネスメトリクスを考慮に入れると、長期にわたる効率性を追跡し、明らかにすることに役立ちます。ビジネスメトリクスはワークロードの目的に特化したものです。例としては、月間アクティブユーザー数、管理されている保険契約数、API の呼び出しの成功数などがあります。リソース使用量をビジネスメトリクス (このユーザーガイド「 具体的な改善点を評価する 」を参照) で割って、以下の式に示すように、トランザクションあたりの vCPU 時間などのサステナビリティ KPI を計算します。理想的には、サステナビリティ KPI が下がるか、少なくとも横ばいであることを望みます。コストに関するユニットメトリクスという関連する概念は、「 アプリケーションのユニットメトリクスを選択、作成、追跡する 」というブログ記事にあります。 図 2 : サステナビリティプロキシメトリクス方程式 AWS re: Invent 2022 (CMP204) で、コスト、エネルギー、リソース効率に優れたコンピューティング環境を構築する半導体業界のグローバルリーダーである Arm 社が、電子設計自動化 (EDA) ジョブの測定、追跡、影響を軽減した方法を紹介します ( 録画 ををご覧ください)。彼らは Amazon EC2 インスタンスの vCPU 時間を使用して、Amazon EC2 スポット採用、AWS Graviton 採用のためのKPI、およびジョブごとに必要なリソースを計算しました。 同様に、Amazon Prime Video は、「AWS re: Invent 2022 Architecting sustainably and reducing your AWS carbon footprint (SUS205)」で、以下のサステナビリティプロキシメトリクスをどのように使用して最適化の効果を定量化および追跡したかを説明しています ( 録画 をご覧ください)。  再生エクスペリエンス : 1,000 同時ストリームあたりのインフラストラクチャコスト ($) コンテンツ配信 : ストリームあたりの配信帯域幅 (Gbps) コンテンツディスカバリーエクスペリエンス : 1000 ページのインプレッションあたりの正規化インスタンス時間 (NIH) 顧客獲得 : サブスクリプションあたりのインフラストラクチャコスト ($) Prime Video は、目標に向けて最適化を図り、持続可能性の目標とその他の非機能要件とのトレードオフを実施しました。「 Thursday Night Football 」の視聴者からの急増する需要に応えるため、システムに障害が発生した場合に重要ではないカスタマーエクスペリエンス機能をオフにする自動緊急時対応スイッチを実装しました。 まとめ この記事では、サステナビリティプロキシメトリックと KPI の動機について説明しました。使用量ベースのメトリクス、ビジネスメトリクスの標準化と包含という概念を説明し、お客様がこれらのメトリクスを使用して持続可能性を最適化する方法の例を共有しました。 次の投稿では、持続可能性の観点から AWS の使用を最適化して効率のベストプラクティスを大規模に導入したいと考えているチーム向けに、プロキシメトリクスデータパイプラインを設定して持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法について詳しく説明します。 持続可能性のためにワークロードを最適化する方法の詳細については、 AWS Well Architected の持続可能性の柱 を参照してください。アプリケーションのサステナビリティプロキシメトリクスの測定と最適化を始めたい場合は、「 サステナビリティプロキシメトリクスダッシュボード 」を見つけて今すぐ実装してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 Katja Philipp Katja Philipp は、ドイツのミュンヘンに拠点を置くアマゾンウェブサービスのサステナビリティソリューションアーキテクトです。彼女は、顧客がクラウド、テクノロジー、データを活用して持続可能性に関する課題を解決し、リソース効率を重視した設計を行えるように支援しています。Katja は、持続可能性と、より良い未来に向けて現在の課題を解決するためにテクノロジーをどのように活用できるかに情熱を注いでいます。 Jonas Bürkel Jonas Bürkel は、ドイツを拠点とする AWS のソリューションアーキテクトです。製造業のお客様が、独自のビジネス要件や技術要件を満たすソリューションをクラウドで構築できるよう支援しています。Jonas は、持続可能性や、テクノロジーがどのように効率化に役立つかにも情熱を注いでいます。 Steffen Grunwald Steffen Grunwald は、アマゾンウェブサービスのプリンシパルソリューションアーキテクトです。クラウドを通じてお客様が持続可能性の課題を解決できるようサポートしています。ソフトウェアエンジニアリングのバックグラウンドが長く、持続可能性、パフォーマンス、コスト、運用効率を高め、イノベーションのスピードを上げるために、アプリケーションアーキテクチャと開発プロセスを深く掘り下げることが大好きです。