Vercel は、Amazon EventBridge スケジューラを利用して Cron Jobs を実装し、顧客がスケジュールされたタスクを大規模に作成、管理、実行できるようにしました。この機能の導入は急速に進み、リリースから数か月以内に毎週 700 万回を超える cron 呼び出しが行われるようになりました。この記事では、同社がどのようにそれを実現したのか、そして同社が経験している大規模なスケールにどのように対処したかを示します。 Vercel は、エンジニアがフロントエンドアプリケーションのデプロイと実行をより容易に行えるようにするフロントエンドクラウドを構築しています。 過去 2 年間で Vercel でのデプロイは 1 億件を超えています 。Vercel は、サーバーレステクノロジーを大規模に利用することで、ユーザーが設定することなく、クラス最高の AWS インフラストラクチャを活用できるようサポートしています。Vercel は、デベロッパーがフロントエンドアプリケーションをホストするのに役立つ機能を多数提供しています。しかし、今年の初めまで、同社はまだ Cron Jobs を構築していませんでした。 cron ジョブは、あらかじめ決められた間隔または固定時刻における特定のコマンドまたはスクリプトの実行を自動化するスケジュールされたタスクです。これにより、ユーザーは、バックアップ、顧客への通知メールの送信、サブスクリプションの更新が必要な場合の支払い処理など、定期的かつ反復的なアクションを設定できます。cron ジョブは、効率を向上させ、日常業務を自動化するためにコンピューティング環境で広く利用されており、Vercel の顧客からは、この機能を求める声が多く寄せられていました。 2022 年 12 月、Vercel はイノベーションを促進するために社内ハッカソンを主催しました。ここで、 Vincent Voyer 氏と Andreas Schneider 氏が協力して、Vercel プラットフォーム用の cron ジョブ機能のプロトタイプを構築しました。Voyer 氏と Schneider 氏は 5 人からなるチームを結成し、1 週間かけてこの機能に取り組みました。チームは、cron ジョブを表示するユーザーインターフェイスの構築から、機能のバックエンド実装の作成まで、さまざまなタスクをこなしました。 Amazon EventBridge スケジューラ ハッカソンチームが cron ジョブの問題の解決について考え始めたとき、最初のアイデアは、 スケジュールに従って実行される Amazon EventBridge ルール を利用することでした。しかし、この機能には AWS リージョンごとにアカウントあたり 300 個のルールという制限があり、これでは意図した用途には十分ではないことがすぐにわかりました。幸運にも、チームメンバーの 1 人が AWS コンピューティングブログで Amazon EventBridge スケジューラの発表 について読んでおり、チームはこれが自分たちの問題を解決するのに最適なツールであると考えました。 EventBridge スケジューラ を利用すると、基盤となるインフラストラクチャをプロビジョニングまたは管理することなく、270 を超える AWS サービスにわたって数百万のタスクを 1 回限り、または繰り返し実行するようにスケジュールできます。 Vercel で新しい cron ジョブを作成するには、顧客はこのタスクを実行する頻度と呼び出す API を定義する必要があります。Vercel はバックエンドで EventBridge スケジューラを利用し、新しい cron ジョブが作成されるときに新しいスケジュールを作成します。 エンドポイントを呼び出すために、チームは、入力パラメータとして呼び出す必要があるパスを受け取る AWS Lambda 関数を利用しました。 cron ジョブの実行時刻になると、EventBridge スケジューラは関数を呼び出し、設定されている顧客のウェブサイトのエンドポイントを呼び出します。 週末までに、Voyer 氏とチームは cron ジョブ機能の実用的なプロトタイプバージョンを完成させ、ハッカソンで賞を勝ち取りました。 Vercel Cron Jobs の構築 12 月のある 1 週間にわたってこのプロトタイプに取り組んだ後、ハッカソンは終了し、Voyer 氏とチームは通常業務に戻りました。2023 年 1 月初旬、Voyer 氏と Vercel のチームは、このプロジェクトを発展させて、実際の製品を実現することを決定しました。 ハッカソン中にチームは機能の基本的な部分を構築しましたが、本番環境に対応できるよう、いくつかの細かい点を磨き上げる必要がありました。Voyer 氏と Schneider 氏はこの機能に取り組み、2 か月も経たない 2023 年 2 月 22 日に Vercel Cron Jobs を一般向けに発表しました。 発表のツイート は 40 万回を超えるビューを獲得し、コミュニティはこのリリースを高く評価しました。 この機能の導入は非常に迅速でした。Cron Jobs のリリースから数か月以内に、Vercel は 1 週間あたり 700 万回を超える cron 呼び出しに達し、採用は今後も増加すると予想しています。 Vercel Cron Jobs がスケールを処理する方法 これほどのペースで導入が進んでいることを踏まえると、Vercel にとってこの機能をスケールすることは非常に重要です。このペースで cron 呼び出しの量をスケールするには、ビジネスおよびアーキテクチャの観点でいくつかの決定を下す必要がありました。 ビジネスの観点からは、同社は無料利用枠の顧客についての制限を定めました。無料利用枠の顧客は、自らのアカウントで最大 2 個の cron ジョブを作成できますが、設定できるスケジュールは時間単位のみです。つまり、無料利用の顧客は 30 分ごとに cron ジョブを実行することはできず、最大でも 1 時間ごとに実行できるのみとなります。Vercel の有料階層の顧客のみが、タスクのスケジュール設定に EventBridge スケジューラの分単位の粒度 を利用できます。 また、無料利用の顧客の場合、分単位の精度は保証されません。これを実現するために、Voyer 氏は EventBridge スケジューラの時間枠設定を利用しました。 柔軟な時間枠 設定を利用することで、時間枠内でスケジュールを開始できます。これは、ダウンストリームサービスに対する複数のリクエストの影響を軽減するために、スケジュールされたタスクが時間枠全体に分散されることを意味します。これは、例えば、多くの顧客が深夜にジョブを実行したい場合に非常に便利です。柔軟な時間枠を利用すると、設定された時間枠全体で負荷を分散できます。 アーキテクチャの観点からは、Vercel は API をホストし、cron ジョブが呼び出す関数を所有することの利点を活用しました。 これは、Lambda 関数が EventBridge スケジューラによって開始されると、関数は API からの応答を待たずに実行を終了することを意味します。その後、Vercel は、オブザーバビリティメカニズムから API と Vercel 関数が正しく実行されたかどうかをチェックすることで、cron ジョブが実行されたかどうかを検証します。この方法を用いることで、関数の実行時間は 400 ミリ秒未満と非常に短くなります。これにより、Vercel は同時実行の制限に影響を及ぼすことなく、1 秒あたりに多くの関数を実行できます。 影響 Vercel による Cron Jobs の実装は、サーバーレステクノロジーがどのようなことを実現できるのかを示す優れた例です。2 か月間にわたって 2 人がフルタイムで働くことで、コミュニティが必要としていた機能をリリースすることができ、その機能は広く導入されました。この機能は Vercel のプラットフォームの完全性を示すものであり、有料アカウントに移行するよう顧客を説得するための重要な機能となっています。 EventBridge スケジューラの利用を開始するには、 EventBridge スケジューラの Serverless Land のパターン を参照してください。ここでは、役立つ幅広い例を見つけることができます。 –  Marcia 原文は こちら です。

最近、多くのお客様は大規模言語モデル (Large Language Model: LLM) に高い期待を示しており、生成系 AI がビジネスをどのように変革できるか考えています。しかし、そのようなソリューションやモデルをビジネスの日常業務に持ち込むことは簡単な作業ではありません。この投稿では、MLOps の原則を利用して生成系 AI アプリケーションを運用化する方法について説明します。これにより、基盤モデル運用 (FMOps) の基盤が築かれます。さらに、Text to Text のアプリケーションや LLM 運用 (LLMOps) について深掘りします。LLMOps は FMOps のサブセットです。以下の図は、議論するトピックを示しています。 具体的には、MLOps の原則を簡単に紹介し、FMOps および LLMOps との主な違いに焦点を当てます。これは、プロセス、人材、モデル選択と評価、データプライバシー、モデルのデプロイメントなどに関連します。そのまま利用する場合、スクラッチから基盤モデルを作成する場合、ファインチューニングする場合の全てに当てはまります。本アプローチは、オープンソースとプロプライエタリモデルの両方に同様に適用できます。 機械学習の運用サマリー Amazon SageMaker を利用したエンタープライズのための MLOps 基盤ロードマップ で定義されているように、機械学習と運用 (MLOps) は、機械学習 (ML) ソリューションを効率的に実運用するために、人材、プロセス、テクノロジーを組み合わせたものです。これを達成するには、以下に示すチームとペルソナが協力する必要があります。 これらのチームは以下の通りです。 アドバンスド・アナリティクス・チーム(データレイクとデータメッシュ) – データエンジニアは、複数のソースからデータを準備および取り込み、ETL (抽出、変換、ロード) パイプラインを構築してデータを策定およびカタログ化し、ML ユースケースに必要な履歴データを準備する責任があります。これらのデータ所有者は、複数のビジネスユニットまたはチームへのデータアクセスの提供に焦点を当てています。 データサイエンティスト・チーム – データサイエンティストは、予め定義された主要業績評価指標 (KPI) に基づいて、ノートブックでベストモデルを作成することに集中する必要があります。研究フェーズの完了後、データサイエンティストは ML エンジニアと協力して、CI/CD パイプラインを使用してモデルのビルド (ML パイプライン) と実稼働環境へのモデルのデプロイメントの自動化を作成する必要があります。 ビジネスチーム – プロダクトオーナーは、ビジネスケース、要件、およびモデルパフォーマンスを評価するために使用される KPI を定義する責任があります。ML コンシューマーは、意思決定を左右するために推論結果 (予測) を利用するその他のビジネスステークホルダーです。 プラットフォームチーム – アーキテクトは、ビジネスの全体的なクラウドアーキテクチャと、異なるサービスがどのように接続されているかの責任があります。セキュリティ SME は、ビジネスのセキュリティポリシーとニーズに基づいてアーキテクチャをレビューします。MLOps エンジニアは、データサイエンティストと ML エンジニアが ML ユースケースを実運用化できるように、安全な環境を提供する責任があります。具体的には、ビジネスとセキュリティの要件に基づいて、CI/CD パイプライン、ユーザーとサービスの役割とコンテナの作成、モデル利用、テスト、およびデプロイメントの方法論を標準化する責任があります。 リスクとコンプライアンス・チーム – より制限的な環境の場合、監査人はデータ、コード、モデルアーティファクトを評価し、ビジネスが規制 (データプライバシーなど) に準拠していることを確認する責任があります。 ビジネスのスケーリングと MLOps の成熟度に応じて複数のペルソナを同一人物が担当する場合があることに注意してください。 これらのペルソナは、以下の図に示すように、さまざまなプロセスを実行するための専用の環境を必要とします。 環境は以下の通りです。 プラットフォーム管理 – プラットフォームチームが AWS アカウントを作成し、適切なユーザーとデータをリンクできるプラットフォーム管理環境です。 データ – データレイヤーは、データエンジニアまたは所有者とビジネスステークホルダーがデータを準備、操作、および可視化するために使用するデータレイクまたはデータメッシュと呼ばれる環境です。 実験 – データサイエンティストは、概念実証 (Proof of Concept: PoC) がビジネスの問題を解決できることを証明するために、新しいライブラリと機械学習技術をテストするためのサンドボックスまたは実験環境を使用します。 モデル構築、モデルテスト、モデルデプロイメント – モデルの構築、テスト、およびデプロイメント環境は、研究を実運用に移行するためにデータサイエンティストと ML エンジニアが協力して研究を自動化する MLOps のレイヤーです。 ML ガバナンス – パズルの最後のピースは、モデルとコードの成果物が保存、レビュー、および対応するペルソナによる監査対象となる ML ガバナンス環境です。 以下の図は、 Amazon SageMaker を利用したエンタープライズのための MLOps 基盤ロードマップ で既に説明されているリファレンスアーキテクチャを示しています。 各ビジネスユニットには、ML ユースケースを実運用化するための独自セットの Dev (自動化されたモデルトレーニングとビルド)、Pre Prod (自動テスト)、Prod (モデルのデプロイとサービング) アカウントがあります。これらは、中心化されたデータレイクまたは分散データメッシュからデータを取得します。生成されたすべてのモデルとコードの自動化は、モデルレジストリの機能を使用して Tooling アカウントに集約されます。これらすべてのアカウントのインフラストラクチャコードは、プラットフォームチームが抽象化、テンプレート化、保守、および各新規チームの MLOps プラットフォームへのオンボーディングで再利用できる共有サービスアカウント (advanced analytics governance account) でバージョン管理されます。 生成系 AI の定義と MLOps との違い クラシックな機械学習では、人材、プロセス、テクノロジーの前述の組み合わせにより、ML ユースケースを製品化できます。ただし、生成系 AI では、ユースケースの性質により、これらの機能の拡張または新機能が必要になります。これらの新しい概念の 1 つは、基盤モデル (Foundation Model: FM) です。これらは以下の図に示すように、広範囲の他の AI モデルを作成するために使用できるため、そのように呼ばれています。 FM はテラバイト単位のデータでトレーニングされており、3 つの主なカテゴリの生成系 AI ユースケースにおいて、最良の回答を予測するための数百億のパラメータを持っています。 Text to Text – FM (LLM) は、ラベルなしデータ(フリーテキストなど)でトレーニングされており、次の最適な単語または一連の単語 (段落または長文) を予測できます。主なユースケースは、人間らしいチャットボット、要約、プログラミングコードなど、その他のコンテンツ作成などです。 Text to Image – &lt;テキスト、画像&gt; のペアなどのラベル付きデータを使用して、最適なピクセルの組み合わせを予測できる FM をトレーニングすることができます。使用例としては、服のデザイン生成や想像上のパーソナライズされた画像があります。 Text-to-Audio or Video – トレーニングされた FM のために、ラベル付きデータとラベルなしデータの両方を使用できます。主な生成系 AI のユースケースの例は音楽の作曲です。 これらの生成系AIユースケースを実運用化するには、MLOps ドメインを借用および拡張して、以下を含める必要があります。 FM 運用 (FMOps) – これにより、使用例のタイプを問わず、生成系 AI ソリューションを実運用化できます。 LLM 運用 (LLMOps) – これは FMOps のサブセットであり、LLM ベースのソリューション (Text to Text など)の実運用化に焦点を当てています。 以下の図は、これらのユースケースの重複を示しています。 従来の機械学習や MLOps と比較すると、FMOps と LLMOps は、以下の 4 つの主なカテゴリーに基づいて異なります。これらは、以下のセクションで取り上げます: プロセス、人材、FM の選択と適応、FM の評価と監視、データプライバシーとモデルのデプロイメント、技術ニーズ。監視については、別の投稿で取り上げます。 生成系 AI ユーザータイプごとの運用化の旅 プロセスの説明を簡単にするために、以下の図に示すように主な生成系 AI ユーザータイプを分類する必要があります。 ユーザータイプは以下の通りです。 プロバイダー – スクラッチから FM を構築し、製品として他のユーザー (ファインチューナーとコンシューマー) に提供するユーザー。彼らはエンドツーエンドの ML と自然言語処理 (NLP) の専門知識、および膨大なデータラベラーとエディタのチームを持っています。 ファインチューナー – プロバイダーから FM を再トレーニング (ファインチューニング) して、カスタム要件に合わせるユーザー。彼らはモデルのサービスとしてのデプロイをオーケストレーションします。これは、コンシューマーが使用するためのものです。これらのユーザーは、エンドツーエンドの ML とデータサイエンスの専門知識、モデルのデプロイと推論の知識が必要です。チューニングのためのプロンプトエンジニアリングを含むドメイン知識も必要です。 コンシューマー – テキストのプロンプトまたはビジュアルインターフェースによって、プロバイダーまたはファインチューナーの生成系 AI サービスと対話し、所望のアクションを完了するユーザー。ML の専門知識は必要ありませんが、主にアプリケーション開発者またはエンドユーザーで、サービスの機能についての理解が必要です。良い結果のために必要なのはプロンプトエンジニアリングのみです。 定義と必要な ML の専門知識に従って、MLOps は主にプロバイダーとファインチューナーに必要です。一方、コンシューマーは DevOps や AppDev の原則を使用して、生成系 AI アプリケーションを作成できます。さらに、次のようなユーザータイプの変遷が観察されています。プロバイダーは、垂直セクター (金融セクターなど) に基づくユースケースをサポートするためにファインチューナーになる可能性があります。または、コンシューマーは、より正確な結果を得るためにファインチューナーになる可能性があります。しかしながら、以降ではユーザータイプごとの主要なプロセスを観察しましょう。 コンシューマーの旅 以下の図は、コンシューマーの旅を示しています。 前述のとおり、コンシューマーは、特定の入力、つまりプロンプトを提供することによって、FM を選択、テスト、使用する必要があります。プロンプトとは、コンピュータプログラミングや AI のコンテキストで、モデルまたはシステムに対して与えられる入力を指します。これは、テキスト、コマンド、質問の形式をとることができ、システムはこれを使用して出力を処理および生成します。FM によって生成された出力は、エンドユーザーが使用できます。エンドユーザーは、これらの出力を評価して、モデルの将来の応答を強化する必要があります。 これらの基本プロセスに加えて、ファインチューナーが提供する機能を活用してモデルをファインチューニングすることをコンシューマーが望んでいることに私たちは気づきました。たとえば、画像を生成する Web サイトを考えてみましょう。ここでは、エンドユーザーはプライベートアカウントを設定し、個人写真をアップロードし、その後、それらの画像に関連するコンテンツを生成できます (たとえば、バイクに乗って剣を振り回しているエンドユーザー、またはエキゾチックな場所にいるエンドユーザーを描いた画像)。このシナリオでは、コンシューマーが設計した生成系 AI アプリケーションは、API を介してファインチューナーのバックエンドと対話して、この機能をエンドユーザーに提供する必要があります。 しかし、その前に以下の図に示すような、モデルの選択、テスト、使用、入力と出力の対話、および評価のプロセスに注力しましょう。 * 利用可能な15,000のFMリファレンス ステップ1. トップ FM 機能を理解する 基盤モデルを選択する際には、ユースケース、利用可能なデータ、規制などに応じて、考慮すべき多くの観点があります。包括的ではないが、次のような優良チェックリストが考えられます。 プロプライエタリまたはオープンソースの FM – プロプライエタリモデルは金銭的コストがかかりますが、通常、生成されたテキストまたは画像の品質の点で優れたパフォーマンスを発揮します。これは、最適なパフォーマンスと信頼性を確保する専任のモデルプロバイダーチームによって開発・維持管理されることが多いためです。一方、オープンソースモデルの採用も増加しており、無料である以外に、アクセスしやすく柔軟性があるという追加のメリットがあります (例えば、すべてのオープンソースモデルはファインチューニング可能です)。プロプライエタリモデルの例として Anthropic の Claude モデルが、高性能なオープンソースモデルの例として 2023 年 7 月時点の Falcon-40B があります。 商用ライセンス – FM を決定する際、ライセンスの考慮事項が重要です。一部のモデルはオープンソースですが、ライセンスの制限または条件により、商業目的で使用できないことに注意することが重要です。違いは微妙な場合があります。たとえば、新しくリリースされた xgen-7b-8k-base モデルはオープンソースで商用可能 (Apache-2.0ライセンス) ですが、Instruction Fine-Tuning バージョンのモデル xgen-7b-8k-inst は研究目的でのみリリースされています。商用アプリケーションの FM を選択する場合、ライセンス契約を確認し、その制限を理解し、プロジェクトの意図された使用目的と整合していることを確認することが重要です。 パラメータ – パラメータの数は、ニューラルネットワークの重みとバイアスで構成されます。これはもう 1 つの重要な要因です。パラメータが多いほど、モデルはより複雑で可能性のある強力なモデルになります。これは、データ内のより精妙なパターンと相関関係を捉えることができるためです。ただし、トレードオフはより多くのコンピューティングリソースが必要になり、実行コストが高くなることです。また、オープンソースでは小規模モデル (70 億 ~ 400 億のパラメータ)のファインチューニング時に良好なパフォーマンスを発揮する傾向が特に見られます。 速度 – モデルの速度は、そのサイズの影響を受けます。大規模モデルは、計算の複雑さが増すため、データ処理が遅くなりがちです (レイテンシが高くなる)。したがって、高い予測力を持つモデル (多くの場合、大規模モデル) の必要性と、特にチャットボットなどのリアルタイムまたはニアリアルタイム応答を必要とするアプリケーションの速度に関する実際の要件のバランスを取ることが重要です。 コンテキストウィンドウサイズ (トークン数) – プロンプトごとに入力または出力できる最大トークン数によって定義されるコンテキストウィンドウは、モデルが一度に考慮できるコンテキスト量を決定するのに重要です (トークンは英語では約 0.75 語に相当します)。コンテキストウィンドウが大きいモデルは、長い会話やドキュメントに関わるタスクに役立つ、より長いテキストシーケンスを理解および生成できます。 トレーニングデータセット – FM がどのような種類のデータでトレーニングされたかを理解することも重要です。一部のモデルは、インターネットデータ、コーディングスクリプト、インストラクション、人間のフィードバックなど、さまざまなテキストデータセットでトレーニングされている場合があります。テキストと画像データの組み合わせなど、マルチモーダルデータセットでトレーニングされている場合もあります。これは、異なるタスクに対するモデルの適合性に影響を与える可能性があります。また、組織にはモデルが正確にどのソースでトレーニングされたかに応じて、著作権の問題が発生する可能性があるため、トレーニングデータセットを注意深く検証することが必須です。 品質 – FM の品質は、そのタイプ (プロプライエタリかオープンソース)、サイズ、トレーニング内容に基づいて異なる場合があります。品質はコンテキスト依存であり、あるアプリケーションで高品質と見なされるものが、別のアプリケーションではそうでない可能性があります。たとえば、インターネットデータでトレーニングされたモデルは、会話型テキストの生成には高品質だと考えられる可能性がありますが、技術的または専門的なタスクにはそうでない可能性があります。 ファインチューニング可能 – モデルの重みやレイヤーを調整することによって FM をファインチューニングできる機能は、重要な要因となり得ます。ファインチューニングにより、モデルをアプリケーションの具体的なコンテキストにより適合させ、特定のタスクでのパフォーマンスを向上させることができます。ただし、ファインチューニングには追加のコンピューティングリソースと技術専門知識が必要であり、すべてのモデルがこの機能をサポートしているわけではありません。オープンソースモデルは、モデルアーティファクトをダウンロードでき、ユーザーはそれらを自由に拡張および使用できるため、(一般に) 常にファインチューニングが可能です。プロプライエタリモデルの場合、ファインチューニングのオプションを提供していることがあります。 顧客または開発チームの既存スキル – FM の選択は、顧客または開発チームのスキルと習熟度の影響も受けます。組織のチームに AI/ML の専門家がいない場合、API サービスの方が適している可能性があります。また、チームが特定の FM に広範な経験を持っている場合、新しいものを学習および適応するために時間とリソースを投資するよりも、それを使用し続ける方が効率的な場合があります。 プロプライエタリモデルとオープンソースモデルの 2 つの短いリストの例を以下に示します。ニーズに基づいて同様の表を作成し、利用可能なオプションの概要を迅速に把握できます。これらのモデルのパフォーマンスとパラメータは急速に変化し、本ブログを読まれているタイミングでは古い情報になっている可能性がある一方で、サポート言語など、特定の顧客にとって重要な他の機能があることに注意してください。 以下は、AWS で利用可能な注目すべきプロプライエタリ FM の例です (2023 年 7 月時点)。 以下は、AWS で利用可能な注目すべきオープンソース FM の例です (2023 年 7 月時点)。 10 – 20 の潜在的な候補モデルの概要を作成した後、この短いリストをさらに絞り込む必要があります。このセクションでは、次のラウンドの候補として実行可能な 2、3 の最終モデルを迅速に生成するメカニズムを提案します。 次の図は、初期の短いリスト作成プロセスを示しています。 通常、高品質なプロンプトを作成して AI モデルがユーザー入力を理解および処理できるようにする専門家であるプロンプトエンジニアは、要約など同じタスクをモデルで実行するさまざまな方法を試します。これらのプロンプトはその場で作成されるのではなく、プロンプトカタログから体系的に抽出されることをお勧めします。プロンプトカタログは、プロンプトの複製を避け、バージョン管理を可能にし、次のセクションで紹介するさまざまな開発段階の異なるプロンプトテスター間の一貫性を確保するためにプロンプトをチーム内で共有するための中心的な場所です。このプロンプトカタログは、特徴量ストアの Git リポジトリに似ています。潜在的にはプロンプトエンジニアと同じ人物である可能性のある生成系 AI 開発者は、開発を目指している生成系 AI アプリケーションに適しているかどうかを判断するために、出力を評価する必要があります。 ステップ2. トップ FM をテストおよび評価する 短いリストが約 3 つの FM に絞り込まれた後、ユースケースに対する FM の機能と適合性をさらにテストするための評価ステップを推奨します。評価データの可用性と性質に応じて、以下の図に示すように、異なる方法を提案します。 最初に使用する方法は、ラベル付きのテストデータがあるかどうかによって異なります。 ラベル付きデータがある場合は、従来の ML モデルと同様に、モデル評価を実行できます (一部のサンプルを入力し、出力をラベルと比較します)。テストデータに離散ラベル (肯定的、否定的、中立的な感情分析など) があるか、非構造化テキスト (要約など) であるかによって、評価のための異なる方法を提案します。 精度指標 – 離散出力 (感情分析など) の場合は、精度、再現率、F1 スコアなどの標準的な精度指標を使用できます。 類似性指標 – 出力が非構造化(要約など)の場合は、ROUGE やコサイン類似度などの類似性指標を提案します。 一部のユースケースは、唯一の正解を持たない場合があります (例:「5 歳の娘のための短い子供向けの物語を作成する」)。このような場合、ラベル付きのテストデータがないため、モデルを評価することがより困難になります。モデルの自動評価と人のレビューの重要性に応じて、次の 2 つのアプローチを提案します。 Human-in-the-Loop (HIL) – この場合、プロンプトテスターのチームがモデルからの応答をレビューします。アプリケーションの重要性に応じて、プロンプトテスターはモデル出力の 100 % をレビューするか、サンプルのみをレビューする可能性があります。 LLM 駆動型評価 – このシナリオでは、プロンプトテスターは、テスト対象のものよりも強力な (おそらく遅く、コストもかかる) LLM に置き換えられます。LLM は、モデルが生成する全ての応答をレビューしてスコア付けします。この方法では品質が低下する可能性がありますが、モデルパフォーマンスの初期の目安を提供できる、より安価で高速な評価オプションです。 たとえば、入力クエリ、LLM 応答、インストラクションが含まれる次のサンプルプロンプトを LLM に使用できます: 「上記に表示されているユーザーの質問に対する AI アシスタントのパフォーマンスについてフィードバックをお願いします。助手の応答の有用性、関連性、正確性、詳細のレベルを評価してください。アシスタントは、高いスコアほど全体的なパフォーマンスが向上する 1-10 の尺度で全体的なスコアを受け取る必要があります。」 このプロンプトは、別の LLM (EvalLLM) に送信されて評価されます。次は、Falcon-40B モデルの応答が EvalLLM (このケースでは Claude) によって評価された例です。「スエズ運河が建設されなければどうなっていたか」という質問を使用します。応答は次のとおりです。 質問: スエズ運河が建設されなければどうなっていたか? falcon-40b-instruct スエズ運河が建設されなければ、船は地中海と紅海の間を航行するためにアフリカを迂回しなければなりませんでした。 これにより、航海時間と距離が大幅に増加し、効率性が低下し、コストがかかるようになります。 また、スエズ運河がなければ、中東と北アフリカの多くの国々は世界の他の地域との接続が非常に薄れ、経済発展と文化発展が阻害されていたでしょう。 レビュー(スコア: 9/10) アシスタントの応答は非常に適切で、正確で、詳細です。 これは、スエズ運河の非存在に関するユーザーの仮想の質問に対して優れた回答を提供しています。 アシスタントは、海上交通と中東・北アフリカの経済的・文化的影響について的確に指摘しています。 ただし、地政学的含意や世界的な貿易パターンへの影響についてさらに詳述すれば、より包括的な回答になったでしょう。 次の図は、エンドツーエンドの評価プロセスの例を示しています。 この例に基づき、評価を実行するには、プロンプトカタログに格納されているサンプルプロンプトと、特定のアプリケーションに基づくラベル付けされたまたはラベルなしの評価データセットを提供する必要があります。 たとえば、ラベル付きの評価データセットであれば、「2023年の英国首相の氏名を教えてください」というプロンプト(入力とクエリ)や「Rishi Sunak」といった出力と回答を提供できます。 ラベルなしのデータセットの場合は、「小売りウェブサイトのソースコードを生成する」などの質問や指示のみを提供します。 プロンプトカタログと評価データセットの組み合わせを、 評価プロンプトカタログ と呼びます。 プロンプトカタログと評価プロンプトカタログを区別する理由は、後者は特定のユースケースを対象としているのに対し、プロンプトカタログには質問応答などの汎用のプロンプトとインストラクションが含まれるためです。 この評価プロンプトカタログを使用すると、次のステップは、トップ FM に評価プロンプトを入力することです。 結果は、プロンプト、各 FM の出力、スコアとともにラベル付き出力が含まれる評価結果データセットになります(存在する場合)。 ラベルなしの評価プロンプトカタログの場合、結果をレビューしてスコアやフィードバックを提供する HIL または LLM の追加ステップがあります(前述)。 最終的な結果は、すべての出力のスコアを結合した集計結果(平均精度や人間の評価を計算)で、ユーザーはモデルの品質をベンチマークできます。 評価結果が収集されたら、いくつかの次元に基づいてモデルを選択することを提案します。 これらは通常、精度、速度、コストなどの要因に関係します。 次の図は、例を示しています。 各モデルは、これらの次元に沿って強みと特定のトレードオフを持っています。 ユースケースに応じて、これらの次元に異なる優先順位を割り当てる必要があります。 前の例では、最も重要な要因としてコストを優先し、次に精度、そしてスピードとしました。 FM1 ほど効率的ではなく、遅いものの、十分に効果的で、ホスティングコストも大幅に安価です。 したがって、FM2 をトップ選択として選択する可能性があります。 ステップ3. 生成系 AI アプリケーションのバックエンドとフロントエンドを開発する この時点で、生成系 AI 開発者は、プロンプトエンジニアとテスターの助けを借りて、特定のアプリケーションに適した正しい FM を選択しました。 次のステップは、生成系 AI アプリケーションの開発を開始することです。 生成系 AI アプリケーションの開発をバックエンドとフロントエンドの2つのレイヤーに分けています。以下の図の通りです。 バックエンドでは、生成系 AI 開発者は、選択した FM をソリューションに組み込み、プロンプトエンジニアと協力して、エンドユーザーの入力を適切な FM プロンプトに変換するための自動化を作成します。 プロンプトテスターは、自動または手動 (HIL または LLM) のテストのために、プロンプトカタログに必要なエントリを作成します。 次に、生成系 AI 開発者は、最終出力を提供するためのプロンプトチェーンとアプリケーションメカニズムを作成します。 このコンテキストでは、プロンプトチェーンは、より動的でコンテキスト認識のある LLM アプリケーションを作成するテクニックです。 これは、複雑なタスクを一連の小さな、管理可能なサブタスクに分解することによって機能します。 たとえば、LLM に「イギリスの首相はどこで生まれ、その場所はロンドンからどのくらい離れているか」と尋ねた場合、タスクは、「イギリスの首相は誰ですか」、「出生地はどこですか」、「その場所はロンドンからどのくらい離れていますか」などの個々のプロンプトに分解できます。以前のプロンプトの評価に基づいてプロンプトが構築される場合があります。 一定の入力と出力の品質を確保するために、生成系 AI 開発者は、エンドユーザーの入力とアプリケーション出力を監視およびフィルタリングするメカニズムも作成する必要があります。 たとえば、LLM アプリケーションが有害なリクエストと応答を回避することを目的としている場合、入力と出力の両方に有害性検出を適用し、それらを除外できます。 最後に、良好例と悪例で評価プロンプトカタログを拡張するのに役立つ、評価メカニズムを提供する必要があります。 これらのメカニズムのより詳細な表現は、今後の投稿で提示されます。 この機能を生成系 AI エンドユーザーに提供するには、バックエンドと対話するフロントエンドウェブサイトの開発が必要です。 したがって、DevOps および AppDevs (クラウド上のアプリケーション開発者)のペルソナは、入力/出力および評価の機能を実装するために、ベストプラクティスに従う必要があります。 この基本的な機能に加えて、フロントエンドとバックエンドには、パーソナルユーザーアカウントの作成、データのアップロード、ブラックボックスとしてのファインチューニングの開始、基本 FM の代わりにパーソナライズされたモデルの使用などの機能を組み込む必要があります。 生成系 AI アプリケーションのプロダクション化は、通常のアプリケーションと同様です。 次の図は、サンプルアーキテクチャを示しています。 このアーキテクチャでは、生成系 AI 開発者、プロンプトエンジニア、DevOps または AppDev がアプリケーションを手動で作成およびテストし、専用のコードリポジトリを介して CI/CD 経由で開発環境(前の図の GenAI App Dev) にデプロイし、dev ブランチとマージします。 この段階で、生成系 AI 開発者は、FM プロバイダーによって提供された API を呼び出すことにより、対応する FM を使用します。 次に、アプリケーションを広範にテストするには、コードをテストブランチにプロモートする必要があります。これにより、CI/CD を介してプリプロダクション環境 (GenAI App Pre Prod) へのデプロイがトリガーされます。 この環境で、プロンプトテスターは大量のプロンプトの組み合わせを試し、結果を確認する必要があります。 プロンプト、出力、レビューの組み合わせは、評価プロンプトカタログに移動し、今後のテストプロセスを自動化する必要があります。 この広範なテストの後、最後のステップは、メインブランチとのマージにより、生成系 AI アプリケーションを CI/CD 経由で本番にプロモートすることです (GenAI App Prod)。 プロンプトカタログ、評価データと結果、エンドユーザーデータとメタデータ、ファインチューニングされたモデルのメタデータなど、すべてのデータをデータレイクまたはデータメッシュレイヤに格納する必要があることに注意してください。 CI/CD パイプラインとリポジトリは、別のツールアカウント( MLOps に記載のものと同様)に格納する必要があります。 プロバイダーの旅 FM プロバイダーは、ディープラーニングモデルなどの FM をトレーニングする必要があります。 彼らにとって、エンドツーエンドの MLOps ライフサイクルとインフラストラクチャが必要です。 履歴データの準備、モデル評価、および監視に追加が必要です。 以下の図は、そのプロセスを示しています。 従来の ML では、真値を ETL パイプライン経由でフィードすることにより、履歴データが作成されます。 例えば、顧客離反予測のユースケースでは、自動化によりデータベーステーブルが顧客の離反/非離反ステータスに基づいて自動的に更新されます。 FM の場合、ラベル付きまたはラベルなしのデータポイントの10億~100億が必要です。 テキスト対画像のユースケースでは、データラベラーチームが手動で&lt;テキスト、画像&gt;のペアにラベルを付ける必要があります。 これは、多くの人的リソースを必要とする高価な作業です。 Amazon SageMaker Ground Truth Plus は、このアクティビティを実行するためのラベラーチームを提供できます。 LLM の場合などのラベルなしデータのユースケースの場合、データはラベルが付いていません。 ただし、既存の未ラベルの履歴データのフォーマットに従う必要があるため、データエディターが必要なデータ準備を行い、一貫性を確保する必要があります。 履歴データの準備が整ったら、次のステップはモデルのトレーニングと運用化です。 消費者のシナリオに記載されているのと同じ評価手法を使用できることに注意してください。 ファインチューナーの旅 ファインチューナーの目的は、既存の FM を特定のコンテキストに適合させることです。 たとえば、FM モデルは一般目的のテキストを要約できますが、金融報告書を正確に要約できないかもしれません。または、一般的ではないプログラミング言語のソースコードを生成できない可能性があります。 このような場合、ファインチューナーはデータにラベルを付け、トレーニングジョブを実行してモデルをファインチューニングし、モデルをデプロイし、コンシューマーのプロセスに基づいてモデルをテストし、モデルを監視する必要があります。 次の図は、このプロセスを示しています。 現時点では、ファインチューニングのメカニズムが2つあります。 ファインチューニング – FM とラベル付きデータを使用することにより、トレーニングジョブはディープラーニングモデルのレイヤの重みとバイアスを再計算します。 このプロセスは計算資源を大量に必要とする可能性があり、代表的な量のデータが必要ですが、正確な結果を生成できます。 パラメータ効率的ファインチューニング (PEFT) – すべての重みとバイアスを再計算する代わりに、研究者はディープラーニングモデルに追加の小さなレイヤーを追加することにより、満足のいく結果を達成できることを示してきました ( LoRA など)。 PEFT は、ディープファインチューニングよりも計算リソースが少なくて済み、トレーニングジョブに必要な入力データが少なくて済みます。 欠点は、精度が低下する可能性があることです。 次の図は、これらのメカニズムを示しています。 2つの主要なファインチューニング方法を定義したので、次のステップは、オープンソースおよびプロプライエタリの FM をどのようにデプロイおよび使用するかを決定することです。 オープンソースの FM の場合、ファインチューナーはウェブからモデルアーティファクトとソースコードをダウンロードできます。たとえば、 Hugging Face Model Hub を使用できます。 これにより、モデルを深くファインチューニングし、ローカルのモデルレジストリに格納し、 Amazon SageMaker エンドポイントにデプロイする柔軟性が得られます。 このプロセスにはインターネット接続が必要です。 よりセキュアな環境(金融セクターの顧客など)をサポートするには、モデルをオンプレミスでダウンロードし、すべての必要なセキュリティチェックを実行し、AWS アカウントのローカルバケットにアップロードできます。 次に、ファインチューナーは、インターネット接続なしでローカルバケットから FM を使用できます。 これにより、データプライバシーが確保され、データがインターネット経由で移動しないようになります。 次の図は、この方法を示しています。 プロプライエタリ FM の場合、ファインチューナーがモデルアーティファクトやソースコードにアクセスできないため、デプロイプロセスは異なります。 モデルは、プロプライエタリ FM プロバイダーの AWS アカウントとモデルレジストリに格納されています。 SageMaker エンドポイントにこのようなモデルをデプロイするには、ファインチューナーは直接エンドポイントにデプロイされるモデルパッケージのみをリクエストできます。 このプロセスでは、プロプライエタリ FM プロバイダーのアカウントで顧客データを使用してファインチューニングを実行する必要があるため、リモートアカウントで顧客機密データが使用されてファインチューニングが実行されることや、複数の顧客間で共有されるモデルレジストリでモデルがホストされることに関する疑問が生じます。 これにより、プロプライエタリ FM プロバイダーがこれらのモデルを提供する必要がある場合、マルチテナントの問題がより困難になります。 ファインチューナーが Amazon Bedrock を使用する場合、これらの課題が解決されます。データはインターネット経由では移動せず、FM プロバイダーはファインチューナーのデータにアクセスできません。 前述の例で説明したように、ウェブサイトが数千人の顧客がパーソナライズされた画像をアップロードすることを可能にする場合と同じ課題が、オープンソースモデルにもあります。 ただし、これらのシナリオは、ファインチューナーのみが関与しているため、制御可能であると見なすことができます。 次の図は、この方法を示しています。 技術的な観点から、ファインチューナーがサポートする必要のあるアーキテクチャは、MLOps と同様です(次の図を参照)。 ファインチューニングは、 Amazon SageMaker Pipelines などを使用した ML パイプラインを作成することにより、開発で行う必要があります。前処理、ファインチューニング(トレーニングジョブ)、および後処理を実行し、ファインチューニングされたモデルをオープンソース FM の場合はローカルのモデルレジストリに送信し(そうでない場合、新しいモデルはプロプライエタリ FM プロバイダー環境に格納されます)。 次に、本番前にモデルをテストする必要があります。最後に、モデルがサービスとして提供され、監視されます。 現在(ファインチューニングされた) FM には、GPU インスタンスエンドポイントが必要です。 各ファインチューニングモデルを個別のエンドポイントにデプロイする必要がある場合、数百ものモデルがあるとコストが増加する可能性があります。 したがって、マルチモデルエンドポイントを使用し、マルチテナンシーの課題を解決する必要があります。 ファインチューナーは、特定のコンテキストに基づいて FM モデルを適合させ、ビジネス目的で使用します。 つまり、ファインチューナーはほとんどの場合、前のセクションで説明したすべてのレイヤーをサポートするコンシューマーでも必要です。これには、生成系AIアプリケーションの開発、データレイクとデータメッシュ、MLOps が含まれます。 以下の図は、生成系 AI エンドユーザーに提供するための完全な FM ファインチューニングライフサイクルを示しています。 次の図は、重要なステップを示しています。 主なステップは以下のとおりです。 エンドユーザーがパーソナルアカウントを作成し、プライベートデータをアップロードします。 データはデータレイクに格納され、FM が期待するフォーマットに前処理されます。 これにより、モデルをモデルレジストリに追加するファインチューニング ML パイプラインがトリガーされます。 そこから、モデルは最小限のテストで本番にデプロイされるか、手動の承認ゲートを備えた広範なテストを経てプッシュされます。 ファインチューニングされたモデルは、エンドユーザーが利用できるようになります。 このインフラストラクチャはエンタープライズ顧客以外には複雑なため、AWS はこのようなアーキテクチャの作成の労力を軽減し、ファインチューニングされた FM をより製品に近づけるために Amazon Bedrock をリリースしました。 FMOps および LLMOps のペルソナとプロセスの差別化点 前述のユーザータイプ(コンシューマー、プロデューサー、ファインチューナー)のジャーニーに基づいて、特定のスキルを持つ新しいペルソナが必要です。以下の図に示されています。 新しいペルソナは以下の通りです。 データラベラーとエディター – これらのユーザーは、&lt;テキスト、画像&gt;のペアなどのデータにラベルを付けたり、フリーテキストなどのラベルなしデータを準備したりして、アドバンスドアナリティクスチームとデータレイク環境を拡張します。 ファインチューナー – これらのユーザーは FM に関する深い知識を持ち、それらを調整する方法を知っており、クラシック ML に焦点を当てるデータサイエンティストチームを拡張します。 生成系 AI 開発者 – FM の選択、プロンプトチェーン、アプリケーション、入力と出力のフィルタリングに関する深い知識を持っています。 彼らは新しいチームである生成系 AI アプリケーションチームに属します。 プロンプトエンジニア – これらのユーザーは、コンテキストにソリューションを適合させ、テストし、プロンプトカタログの初期バージョンを作成する入力と出力のプロンプトを設計します。 彼らのチームは生成系 AI アプリケーションチームです。 プロンプトテスター – これらのユーザーは生成系 AI ソリューション(バックエンドとフロントエンド)を大規模にテストし、結果をプロンプトカタログと評価データセットの拡張にフィードします。 彼らのチームは生成系 AI アプリケーションチームです。 AppDev と DevOps – これらのユーザーは、生成系 AI アプリケーションのフロントエンド(ウェブサイトなど)を開発します。 彼らのチームは生成系 AI アプリケーションチームです。 生成系 AI エンドユーザー – これらのユーザーは、ブラックボックスとしての生成系 AI アプリケーションを消費し、データを共有し、出力の品質を評価します。 生成系 AI を組み込むために MLOps プロセスマップの拡張バージョンは、次の図のように示すことができます。 新しいアプリケーションレイヤーは、生成系 AI 開発者、プロンプトエンジニア、テスター、AppDev が生成系 AI アプリケーションのバックエンドとフロントエンドを作成する環境です。 生成系 AI エンドユーザーは、インターネット (Web UI など)を介して生成系 AI アプリケーションのフロントエンドと対話します。 一方、データラベラーとエディターは、バックエンドにアクセスすることなくデータを前処理する必要があります。 したがって、データと安全に対話するためのエディター付きの Web UI (Web サイト)が必要です。 SageMaker Ground Truth はこれらの機能をすぐに利用できるように提供します。 まとめ MLOps は、ML モデルを効率的に本番化するのに役立ちます。 ただし、生成系 AI アプリケーションを運用化するには、追加のスキル、プロセス、テクノロジーが必要で、FMOps と LLMOps につながります。 この投稿では、FMOps と LLMOps の主な概念を定義し、人材、プロセス、テクノロジーの観点から MLOps 機能との主な違いについて説明しました。 FM モデルの選択と評価、および生成系 AI アプリケーションの開発ライフサイクルについて説明しました。 今後、議論したドメインごとのソリューションの提供に焦点を当て、FM 監視(有害性、バイアス、幻覚など)やサードパーティまたはプライベートデータソースアーキテクチャパターン(検索拡張生成など) の FMOps/LLMOps への統合に関する詳細を提供する予定です。 詳細については、 Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ を参照し、 Amazon SageMaker JumpStart 事前トレーニングモデルでの MLOps プラクティスの実装 でエンドツーエンドのソリューションを試してください。 ご意見やご質問があれば、 コメント欄 にお寄せください。 著者について Dr. Sokratis Kartakis は、Amazon Web Services のシニア機械学習および運用専門ソリューションアーキテクトです。 Sokratis は、AWS サービスを活用し、運用モデル、つまり MLOps の基盤と変革ロードマップを形作ることにより、エンタープライズ顧客が機械学習 (ML) ソリューションを産業化するのを支援に集中しています。 彼は、エネルギー、小売、ヘルスケア、ファイナンス/銀行、モータースポーツなどの領域で、革新的なエンドツーエンドの ML および IoT ソリューションの発明、設計、リーダーシップ、実装に15年以上携わってきました。 Sokratis は、家族や友人と過ごしたり、バイクに乗ったりすることで余暇を過ごすのが好きです。 Heiko Hotz は、自然言語処理、大規模言語モデル、生成系 AI に特化した AI および機械学習のシニアソリューションアーキテクトです。 この役割に就く前は、Amazon の欧州顧客サービスのデータサイエンス部門の責任者を務めていました。 Heiko は、AWS で AI/ML の旅を成功させるお客様を支援しており、保険、金融サービス、メディア&amp;エンターテイメント、ヘルスケア、ユーティリティ、製造など、多くの業界の組織と協力してきました。 Heiko は、できる限り旅行するのが趣味です。 <!-- '"` --> 翻訳はソリューションアーキテクトの中島佑樹、伊藤芳幸が担当しました。原文は こちら です。

8月28日週は、AWS のテックリーダーが執筆した Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) に関するすばらしい記事がいくつかありました。 Werner Vogels 博士は、クラウドコンピューティングとして今日知られているサービスの幕を開けたオリジナルバージョンの 17 年間にわたる忠実な機能を称える「 Farewell EC2-Classic, it’s been swell 」を著述しました。バックグラウンドで実行されているスタックは非常に複雑でしたが、このサービスによってコンピューティングリソースの取得プロセスがいかに簡単になったかが紹介されています。 2006 年以来、私たちは長い道のりを歩んできましたが、お客様のためのイノベーションに終わりはありません。今年の AWS Storage Day で祝われたように、Amazon EBS は 15 年前の今月にローンチされました。Amazon の SVP の職にある優れたエンジニアの James Hamilton は、「 Amazon EBS at 15 Years 」の中で、このサービスが 1 日 100 兆の I/O オペレーションを処理し、毎日 13 エクサバイトのデータを送信するまでに進化した過程を紹介しています。 Werner 博士が記事に書いているように、「進化可能なシステムを構築することは戦略であり、オープンな視点からアーキテクチャを再検討することが必須」です。 お客様からのフィードバックを原動力とするイノベーションの取り組みは今日も続いています。今週も例外ではありません。 8月28日週のリリース 私が注目したリリースを以下に記載しました。 Amazon Kinesis Data Analytics から Amazon Managed Service for Apache Flink への名称変更 – Apache Flink を使ってリアルタイムのストリーミングアプリケーションを構築および実行するためのフルマネージドのサーバーレスサービスである Amazon Managed Service for Apache Flink を使用できるようになりました。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。詳細については、 私のブログ記事 を参照してください。 Amazon Aurora と Amazon RDS の延長サーポート – MySQL 5.7、PostgreSQL 11、および上位のメジャーバージョンを実行する Amazon Aurora と Amazon RDS データベースインスタンスのサポートが最大 3 年延長されます。これにより、これらのバージョンのサポートがコミュニティで終了した後でも、時間の余裕をもって新しいメジャーバージョンへのアップグレードを行ってビジネス要件を満たすことができます。 AWS Step Functions Workflow Studio のスターターテンプレートの強化 – スターターテンプレートを使用して、ワークフローの作成とプロトタイプ作成のプロセスを迅速に合理化できるようになりました。さらに、新しいコードモードを使用すると、デザインビューとコード構築ビューを簡単に切り替えることができます。Workflow Studio の構築エクスペリエンスが向上した結果、ドラッグアンドドロップのビジュアルビルダーエクスペリエンスと新しいコードエディターをシームレスに切り替えて、好みのツールを選択して開発を加速することができます。 詳細については、「 構築作業を効率化する新機能による Workflow Studio の強化 」を参照してください。 Amazon SES のすべての E メールの E メール配信履歴 – 個々の E メール配信問題のトラブルシューティング、重要なメッセージの配信確認、エンゲージメントに関与する受信者のきめ細かい個々の E メール単位での識別が可能になりました。E メールの送信者は、 Amazon SES Virtual Deliverability Manager を使用して、配信パフォーマンスの傾向を調査し、送信済みの各 E メールの配信およびエンゲージメントステータスを確認できます。 Amazon SageMaker のリアルタイムインターフェイスを介したレスポンスストリーミング – インターフェイスレスポンスをクライアントに継続的にストリーミングして、チャットボット、仮想アシスタント、音楽ジェネレーターなど、さまざまな生成系 AI アプリケーションのインタラクティブエクスペリエンスを構築できるようになりました。 レスポンスストリーミングの使用方法の詳細と使用例については、AWS ドキュメントの「 インターフェイスレスポンスのストリーミングを開始する 」と「 コンテナがリクエストを提供する方法 」、および AWS Machine Learning ブログの「 Elevating the generative AI experience: Introducing streaming support in Amazon SageMaker hosting 」を参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AI &amp; Sports: AWS と NFL がゲームにもたらす変革 – 過去 5 年にわたって、AWS は NFL (National Football League) のパートナーとして、ファンが試合をよりよく理解すること、放送局がよりよいストーリーを伝えること、そしてチームがデータを使用してオペレーションとプレーヤーの安全を改善することを支援してきました。AWS CEO の Adam Selipsky、NFL オールプロを獲得した Larry Fitzgerald 選手、NFL ネットワークの Cynthia Frelund 氏がスポーツにおける AI と機械学習の可能性について語り合うライブストリームの録画をご覧ください。 Amazon Science の Amazon Bedrock ストーリー – これは、 Amazon Bedrock を使用して、有害なコンテンツを避ける責任ある AI にフォーカスした Amazon Titan の FM を始めとする主要な基盤モデルで生成系 AI アプリケーションを構築およびスケールするメリットを紹介する優れた記事です。 Amazon EC2 の柔軟性スコア – これは、Auto Scaling グループ (ASG) を介したインスタンスのローンチに使用する設定を推奨の EC2 ベストプラクティスに即して評価するために AWS が開発したオープンソースツールです。このツールを使用すると、ベストプラクティスの適用状況を基に、構成の識別、改善、モニタリングに使用できる「柔軟性スコア」を取得できます。 オープンソースのニュースと最新情報については、私の同僚である Ricardo &nbsp;が厳選した最新のオープンソースプロジェクト、記事、イベントなどをお届けする このニュースレター をご覧ください。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent の計画はお済みですか。 今すぐ セッションカタログ を確認してください。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 AWS グローバルサミット – 最後の対面式 AWS Summit が 9 月 26 日に ヨハネスブルグ で開催されます。 AWS Community Day &nbsp; – AWS ユーザーグループが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 ニュージーランド &nbsp;(9 月 6 日)、 レバノン &nbsp;(9 月 9 日)、 ミュンヘン &nbsp;(9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 CDK Day – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントが 9 月 29 日に開催されます (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 今後予定されている AWS 主導の対面イベント、仮想イベント や AWS DevDay などの デベロッパー向けイベント をすべて閲覧できます。 — Channy この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は、『 AWS SAM support for HashiCorp Terraform now generally available 』の翻訳です。 2022 年 11 月、AWS は HashiCorp Terraform の AWS Serverless Application Model (AWS SAM) サポートのパブリックプレビューを 発表 しました。パブリックプレビューでは、Terraform ユーザーがサーバーレスアプリケーションをローカルでテストするのに役立つ機能のサブセットを取り入れました。本日 (2023 年 9 月 5 日)、AWS は AWS SAM における Terraform サポートの一般提供を開始します。この GA リリースでは、サーバーレスアプリケーションのローカル開発を強化するために AWS SAM の機能セットを拡張しています。 Terraform と AWS SAM はどちらも、開発者がインフラをコードとして定義する (IaC) ことを可能にするオープンソースのフレームワークです。開発者は、コードと同じように、インフラの定義をバージョン管理および共有することができます。しかし、AWS SAM はサーバーレスに特化して設計されているため、サーバーレス開発のために設計されたコマンドラインインターフェース (CLI) が含まれています。この CLI によって、開発者はビルドツールやデプロイツールとともに、ローカルエミュレータを使用してサーバーレスアプリケーションを作成、デバッグ、デプロイすることができます。今回のリリースで、AWS SAM はこれらのツールのサブセットを作成し、Terraform ユーザーにも提供します。 Terraform サポート パブリックプレビューのブログ では、最初の Terraform サポートを紹介しました。このブログでは、ローカル開発のための AWS SAM の拡張された機能セットを紹介します。また、このブログでは ネイティブの Terraform リソース ではなく、 AWS Lambda 関数および Lambda レイヤー用の Serverless.tf モジュール を使用することで、実装を簡素化しています。 モジュールは Lambda 関数とレイヤーのデプロイメントアーティファクトを構築できます。さらに、モジュールは Terraform リソースとのインタフェースとして AWS SAM が必要とするメタデータを自動的に生成します。ネイティブの Terraform リソースを使用する場合のメタデータの設定については、 プレビューのブログ をご覧ください。 コードのダウンロード AWS SAM の Terraform サポートを試してみるために、 aws-sam-terraform-examples リポジトリにアクセスしてください。リポジトリをクローンし、ga ディレクトリに移動して始めましょう: git clone https://github.com/aws-samples/aws-sam-terraform-examples cd aws-sam-terraform-examples/ga このディレクトリには、2 つのデモアプリケーションが含まれています。api_gateway_v1 は Amazon API Gateway REST API (v1) を、api_gateway_v2 は Amazon API Gateway HTTP API (v2) を使用していること以外は、どちらも同じアプリケーションです。どちらかを選択し、そのディレクトリの tf-resources フォルダに移動します。 cd api_gateway_v1/tf-resources 特に断りのない限り、このブログでは api_gateway_v1 アプリケーションを参照します。 コードの構成 コードの構成図 Terraform では、IaC を複数のファイルに分割することができます。このため、開発者はすべての Terraform ファイルを 1 つのディレクトリに集約し、リソースファイルを別の場所に保管することがよくあります。サンプルアプリケーションも、このように構成されています。 Terraform や AWS SAM のコマンドは、 main.tf ファイルの場所、今回は tf-resources ディレクトリから実行する必要があります。AWS SAM コマンドは一般的にプロジェクトルートから実行されるため、AWS SAM にはネスト構造をサポートするコマンドがあります。ネストされたフォルダから sam build コマンドを実行する場合は、 terraform-project-root-path フラグにプロジェクトのルートへの相対パスまたは絶対パスを渡します。 ローカルでの Lambda 関数の呼び出し (local invoke) Terraform のプレビュー版では、ローカル呼び出しをサポートしていましたが、今回 Serverless.tf に対応したことで体験がシンプルになりました。デモアプリケーションには 2 つの関数があります。responder 関数は API Gateway エンドポイントのバックエンド統合で、Auth 関数はカスタムオーソライザーです。両方のモジュール定義は functions.tf ファイルで見つけられます。 responder 関数 module "lambda_function_responder" { source = "terraform-aws-modules/lambda/aws" version = "~&gt; 6.0" timeout = 300 source_path = "${path.module}/src/responder/" function_name = "responder" handler = "app.open_handler" runtime = "python3.9" create_sam_metadata = true publish = true allowed_triggers = { APIGatewayAny = { service = "apigateway" source_arn = "${aws_api_gateway_rest_api.api.execution_arn}/*/*" } } } ここで、重要なパラメーターが 2 つあります: source_path : これはローカルのフォルダを指します。これは zip ファイルではないので、Serverless.tf は必要に応じて成果物をビルドします。 create_sam_data : AWS SAM が必要なファイルとモジュールを見つけるために必要なメタデータを生成します。 この関数をローカルで呼び出すには、以下のコマンドを実行します: build を実行して、ビルドスクリプトを起動します (訳註: 変数未定義のエラーが出る場合は、 export TF_VAR_aws_region=us-west-2 などを実行して設定してください)。 sam build --hook-name terraform --terraform-project-root-path ../ local invoke を実行して、任意の Lambda 関数を呼び出します。 sam local invoke --hook-name terraform 'module.lambda_function_responder.aws_lambda_function.this[0]' Terraform プロジェクトなので、AWS SAM にどのように処理を進めるかを知らせるために、 hook-name パラメータに terraform という値を指定する必要があります。関数名は、モジュール名とリソースタイプの組み合わせです。名前がわからない場合は、名前なしでコマンドを実行してください: sam local invoke --hook-name terraform AWS SAM がテンプレートを評価します。関数が 1 つしかない場合は、AWS SAM はその関数を呼び出します。今回のように複数ある場合、AWS SAM はどの関数を呼び出すか選択肢のリストを表示します。 エラー文の例 Auth 関数 オーソライザー関数は、モックイベントとしていくつかの入力データを必要とします。api_gateway_v1 プロジェクトのモックイベントを生成するには、以下のコマンドを実行します: sam local generate-event apigateway authorizer api_gateway_v2 プロジェクトでは以下を使用してください。 sam local generate-event apigateway request-authorizer API Gateway の REST と HTTP API ではカスタムオーソライザーの扱いが異なるため、結果として出力されるイベントも異なります。今回の例では、REST は標準的な トークンオーソライザー を使用して適切な AWS Identity and Access Management (IAM) ロールを返します。HTTP API の例では、 シンプルな pass または fail オプションを使用しています。 それぞれのサンプルでは、 events/auth.json にテスト用の適切な形式のイベントがすでに含まれています。Auth 関数を呼び出すには、以下を実行します: sam local invoke --hook-name terraform 'module.lambda_function_auth.aws_lambda_function.this[0]' -e ../events/auth.json アプリケーションは変更していないので、再度 sam build コマンドを実行する必要はありません。 ローカルでの API の実行 (local start-api) 一般利用可能のリリースで、API Gateway のローカルバージョンのエミュレートができるようになりました。これらのサンプルにはそれぞれ 2 つのエンドポイントが含まれています。片方は公開エンドポイントで、もう一方はカスタムオーソライザーによって保護されています。どちらも同じレスポンスを返します: { “message”: “Hello TF World”, “location”: “ip address” } 以下のコマンドを実行して、ローカルエミュレーターを起動します: sam local start-api --hook-name terraform AWS SAM がエミュレータを起動し、ローカルテストのために 2 つのエンドポイントを公開します。 公開エンドポイント curl を使って、公開エンドポイントをテストしてみましょう: curl --location http://localhost:3000/open ローカルエミュレーターがリクエストを処理し、ターミナルウィンドウにレスポンスを表示します。エミュレーターには、Lambda 関数からのログも含まれます。 公開エンドポイントの出力例 認証エンドポイント 追加の必要なヘッダー ( myheader ) を渡して、保護されているエンドポイントをテストしてみましょう: curl -v --location http://localhost:3000/secure --header 'myheader: 123456789' エンドポイントは、”Hello TF World” というメッセージで、認可済みの応答を返します。無効なヘッダー値でもエンドポイントを試してみてください: curl --location http://localhost:3000/secure --header 'myheader: IamInvalid' エンドポイントは、Unauthorized の応答を返します。 認可されていないレスポンス パラメーター Terraform と AWS SAM を一緒に使う場合、いくつかのオプションがあります: Hook-name: Terraform を使う際にすべてのコマンドで必要になります。プロジェクトが Terraform アプリケーションであることを AWS SAM に知らせます。 Skip-prepare-infra: AWS SAM は、terraform plan コマンドを使って必要なすべての成果物の特定と処理を行います。ただし、新しいリソースが追加または変更されたときのみ実行する必要があります。このオプションは、AWS SAM が terraform plan コマンドを実行しないようにします。このフラグが渡されていても、プランが存在しない場合は、AWS SAM はフラグを無視して terraform plan コマンドを実行します。 Prepare-infra: AWS SAM に terraform plan コマンドを強制実行させます。 Terraform-project-root-path: 現在のディレクトリをプロジェクトのルートとして上書きします。絶対パス ( /path/to/project/root ) または相対パス ( ../または../../ ) を使用できます。 Terraform-plan-file: 開発者が特定の Terraform プランファイルを指定できるようにします。このコマンドは、Terraform ユーザーがローカルコマンドを使うことも可能にします。 これらのオプションを組み合わせて、長いコマンドを作成することもできます: sam build --hook-name terraform --terraform-project-root-path ../ または sam local invoke –hook-name terraform –skip-prepare-infra 'module.lambda_function_responder.aws_lambda_function.this[0]' samconfig ファイル を使ってデフォルト値を設定すると、コマンドを短縮し、 開発プロセスを最適化 することができます。新しい samconfig YAML サポートを使うと、ファイルは次のようになります: version: 0.1 default: global: parameters: hook_name: terraform skip_prepare_infra: true build: parameters: terraform_project_root_path: ../ これらのデフォルト値を設定すると、コマンドは次のように短くなります: sam local invoke 'module.lambda_function_responder.aws_lambda_function.this[0]' AWS SAM は Terraform プロジェクトであることを認識し、Terraform プランが見つからない限り準備タスクをスキップするようになりました。プランの更新が必要な場合は、-prepare-infra フラグを追加してデフォルトの設定を上書きします。 デプロイとリモートデバッグ これらのプロジェクトのアプリケーションは、通常の Terraform アプリケーションです。他の Terraform プロジェクトと同じようにデプロイしてください。 terraform plan terraform apply 現在、AWS SAM accelerate は Terraform プロジェクトをサポートしていません。しかし、Terraformは API メソッドを使用してデプロイするので、サーバーレスアプリケーションは素早くデプロイされます。サードパーティの監視と terraform apply -auto-approve コマンドを利用することで、同様の体験に近づけることができます。 ロギングについては、 sam logs コマンドを活用しましょう。1 つまたは全てのリソースのログを出力する例として、プロジェクトのデプロイ出力を参照してください。 HashiCorp Cloud Platform HashiCorp Cloud Platform は、開発者がセキュリティと状態を維持するために一元化された場所を使用して、デプロイを実行できるようにします。開発者がクラウド上でビルドを実行する場合、AWS SAM がローカルのプランファイルをローカルのテストやデバッグで使用することはできません。しかし、開発者はクラウドでプランを生成し、ローカルで開発に使用することができます。この手順については、 ドキュメント を参照してください。 まとめ HashiCorp Terraform は、AWS クラウドでアプリケーションを構築するための人気の IaC フレームワークです。AWS SAM は IaC フレームワークであり、CLI は特に開発者がサーバーレスアプリケーションを構築するのを支援するように設計されています。 このブログでは、Terraform の新しい AWS SAM サポートと、開発者が開発体験を最大化するためにこれらを一緒に使う方法について説明してきました。ローカルで単一の関数を呼び出す方法や、ローカルで API Gateway エンドポイントをエミュレートする方法、デプロイする前にローカルで Lambda オーソライザーをテストする方法などを紹介しました。最後に、アプリケーションをデプロイし、AWS SAM を使ってデプロイされたリソースを監視しました。 サーバーレスについてさらに詳しく学びたい方は、 Serverless Land もご覧ください。 翻訳は、Partner Solutions Architect の櫻谷が担当しました。

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 私は AWS の先進的なサービスが、日本の公共のお客様にどのような価値を提供できるのか、海外の事例なども参考にしながら、日本の状況や課題に合せて分かりやすくお届けするサポートをさせて頂いております。 今回は、最近利用者が増加傾向にあり、賑わいが戻っている『空港』に着目しました。新型コロナウイルス感染症の５類感染症移行後初めての夏休みということで、久しぶりに飛行機で国内や海外への旅行に出かけられた方も沢山いらっしゃるのではないでしょうか。多くの人にとって、快適な空の旅の実現には、目的地に辿り着くまでの待ち時間が少ないことが欠かせないというのは世界共通です。空港がそのような乗客体験を実現するには、データの利活用が不可欠なのです。 そこで、空港におけるデータ利活用について興味深い AWS のブログを見つけましたのでご紹介したいと思います。 合わせて、「 空港におけるクラウド活用のベストプラクティス 」を資料にまとめましたので、ダウンロードリンクより是非ご確認ください。 空港と航空会社は、データの有効活用を望んでいる 一般にはあまり知られていませんが、空港は、他空港や航空会社、グランドハンドリングエージェント（空港内でチェックイン、手荷物運搬、配車などのサービスを多くの航空会社に提供する会社）とデータを共有し、業務プロセスを改善することにおいて大いに成功しています。例えば、A-CDM（Airport Collaborative Decision Making）では、空港の遅延を10％、CO2排出量を7.7％削減するなど、このコラボレーションは効率化に大きな影響を及ぼしています。 空港はこれをさらに進めたいと考えています。大韓航空やライアンエアーなどの航空会社が、AWS を使って予防整備や機内食の予測を行うなど、データがいかに産業を変革しているかを目の当たりにしているのです（その好例が Ryanair のパニーニ予測）。正確な予測、パーソナライズ、すべての関係者間での簡単なデータ共有によって空港運営と乗客体験が向上することは、彼らには察しがついています。最近、国際空港評議会（ACI）が、”空港のデータ共有とコラボレーションは、乗客の満足度を向上させる鍵である “と述べたことは、驚くことではありません。 空港はデータプラットフォームを構築している フランスの Nice Côte d’Azur をはじめ、多くの空港が最近 AWS 上にデータプラットフォームを構築しています。データプラットフォームは、一般的に複雑なビジネスルールを持ち、高度に構造化されたデータベースである空港運用データベース（AODB）とは異なり、空港のシステム全体、航空会社、第三者からさまざまな種類の情報を吸収、理解、視覚化、予測、共有するための柔軟なデータベースなのです。 シンシナティ空港では、データを予測分析とプロアクティブな通知に利用しており、これを Enterprise Awareness &amp; Situational Exceptions（EASE）と呼んでいます。EASE は、マネージドサービスの集合体である Amazon Relational Database Service（Amazon RDS）や、サーバーレスでイベント駆動型の計算サービスである AWS Lambda などの AWS サービスを利用して、企業のあらゆる部分から構造化および非構造化データを収集します。これにより、最も異質なデータセットであっても、動的な意思決定を改善することができます。シンシナティ空港は、空港プロセスにおける職員数を改善するだけでなく、ソーシャルメディア上の感情をモニターしています。例えば乗客がオイル流出事故に関するツイートを送信した場合、ほぼリアルタイムで対応することができます。また、空港は天候や現地の交通状況もモニターしており、運航計画の調整、および乗客への注意喚起の両方を行うことができます。 シンガポールのチャンギ空港は、DIVAイノベーションラボの基盤としてデータプラットフォームを構築し、新しいコンシェルジュアプリによって乗客への情報提供を向上させ、スタッフ向けの Where-To-Clean アプリによって、空港内で最近利用者が多いエリアを優先的に清掃するなどの取り組みを行っています。 空港の手荷物搬送システムで世界をリードするも Siemens Logistics、空港のあらゆる業務データを取り込み、分析し、可視化するための航空データハブを AWS 上に構築しました。例えば、同社の Baggage360 システムは、複数の情報源を利用して手荷物データを分析し、手荷物の流れを予測します。Siemens Logistics の航空データソリューション担当ディレクター、 Stephan Poser 氏は、「手荷物の流れを監視し、手荷物の処理時間を予測し、リスクのある接続を特定し、手荷物が重要な処理工程に入る時間を予測することができます」と述べています。「私たちは、手荷物受取りのベルト上で乗客にバッグが見えるようになるタイミングまで予測することができます。」 データプラットフォームを構内に持つ空港の中には、ニーズが高まるにつれ、拡張性や新サービスの追加に限界があることを発見しているところもあります。例えば、AWS パートナーの Wipro は最近、 Toronto Pearson 国際空港のデータプラットフォームをオンプレミスシステムから AWS に移行し、スケールと俊敏性を活用し、人工知能（AI）、機械学習（ML）、ほぼリアルタイムのデータインジェストなどの新機能を追加しました。 Wipro Canada のジェネラル・マネージャーである Anudeep Kambhampati 氏は、「AWS 上の新しい Databricks Lakehouse Platform は、さまざまなソースからほぼリアルタイムのビジネスインサイトを導き出し、継続的なイノベーションを促進するのに役立ちます」と述べています。 私は、なぜ空港が最近になってデータプラットフォームの構築に乗り出したのかに興味を持ちました。この技術は以前から存在していたのに、なぜ今になって？その答えとして、欧州の 30 以上の空港で、データによる業務改善を支援している Azinq のマネージングディレクター、 Chris Taylor 氏に話を伺いました。「AWS が提供するインフラやデータサービスを活用するため、当社の顧客はクラウドベースのデータプラットフォームに急速に移行しています。空港は、旅客とステークホルダーとの関わりを理解し、改善する上でのデータの価値を長い間認識してきましたが、これまではコストや技術面での障壁のため、データプラットフォームを構築することが困難でした。AWS 上の Airport Hive プラットフォームにより、空港は運営に関する洞察を容易に得ることができ、また小さな変化が財政的にも旅客体験的にも大きな影響を与え得るということも可視化されます。AWS のスケーラビリティと弾力性は、お客様がオンプレミスの導入にかかるコストや煩わしさを回避し、長期的な成長余地を確保することに役立ちます。“ データプラットフォームは、非常に特殊な問題を解決するのに役立ちます。例えば、米国のある主要空港では、短期駐車場でタクシーが待機しているという問題がありました。これはつまり、乗客が駐車するスペースが少なくなり、空港の収益が減少することを意味します。この問題を解決するために、空港は AWS パートナーの Slalom に依頼し、過去のフライト、天候、タクシー利用者のデータを利用したデータ予測モデルを構築し、事前にタクシーの需要を予測、必要な時だけタクシーを要請するようにしました。これにより駐車場のスペースが解放され、乗客の利便性が向上、空港は運営改善により約 500 万ドルの収益を回収することができました。 データ共有の課題を克服する 空港の課題のひとつは、必要なデータへのアクセスです。空港は、空港で活動するすべての航空会社や企業から必要なデータを入手することが困難であると述べています。AWS とパートナーは、空港がこの障害を克服するのを支援しています。 AWS は、空港と航空会社との連携、データ共有を支援してきました。私たちは、乗客体験の共有にこだわることで、空港と航空会社が協力関係を築ける可能性があると見ています。例えば AWS は空港と共に、乗客の明確なペインポイントを理解した上で、それを解決するのに必要となるデータの特定を支援し、そのデータをパートナーの航空会社と共有するため、実践的なアプローチをとっています。 サードパーティ企業は、空港のオペレーションを改善するために特別にデータフィードを提供しています。例えば Passur は、AWS 上に構築された API を通じて、フライトポジション、フライト予測、フライトイベントデータなどのほぼリアルタイムのデータフィードを空港に提供しています。Passur の CEO である Brian Cook 氏は、「空港は、資産管理、キャパシティプランニング、航空会社とのコラボレーションを改善するために当社のデータを使用しています」と述べています。「当社のデータフィードは、空港に遅延を事前に通知するため、空港は混乱に対処するための業務調整を事前に行うことができます。」また、サードパーティーのデータを1つのデータカタログで簡単に見つけることができる AWS Data Exchange には、気象やフライトデータなど数千ものデータセットがあります。 いかがでしたでしょうか？ 今後空港でのデータ利活用が進み、皆様の空の旅がますます快適になることを願うばかりです。 わたしは心配性なので、「何時までにチェックインしないといけないんだっけ？」「ラウンジはあったっけ？」「この荷物は機内に持ち込めるかな」「帰りのバスはちょうどいい時間にあるのか」などなどいろいろ気にしてしまうのですが 、データの利活用が進んで空の旅がますます快適になれば嬉しいと思います。そのために AWS もお役に立てればなお嬉しいですね。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 公共機関における AWS 導入のためのお役立ちサイト 資料 空港におけるクラウド活用のベストプラクティス この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

はじめに Amazon Web Services (AWS)上で稼働する SAP HANA ワークロードは、多くの場合、企業の中核であり、財務、調達、給与計算などの重要なビジネスプロセスを担っています。これらのシステム内のデータが確実に保護され、ディザスタリカバリを実行する必要があるシナリオのためのリカバリオプションがあることを保証するには、信頼性の高いバックアップとリストアのアプローチが不可欠です。バックアップ管理プロセスの自動化と簡素化は、一貫性のある効率的なバックアップ運用のための重要な側面です。 2012 年に AWS 上に SAP HANA データベースを初めてデプロイして以来、私たちはお客様のバックアップエクスペリエンスを向上させる方法を模索してきました。最初のステップは、 AWS Backint Agent for SAP HANA のリリースでした。これにより、お客様は Amazon Simple Storage Service（ Amazon S3 ）に直接バックアップできるようになり、”2 ステップ “アプローチの要件がなくなり、バックアップパフォーマンスが最適化されました。2023 年 5 月に、私たちはさらに一歩進んで、 Amazon Elastic Compute Cloud（Amazon EC2）上で SAP HANA 用の AWS Backup の一般提供 を発表しました。 AWS Backup for SAP HANA は、一元化されたコンソールベースのバックアップ管理を提供し、サポートされるすべての AWS リソースで一貫したエクスペリエンスを提供します。特徴としては、IAM ポリシーを使用したセキュリティの向上、専用のバックアップ保管庫、標準化された AWS モニタリングとレポート機能へのアクセス、ポイントインタイム・リストアのための継続的バックアップを最適化するインテリジェンスなどがあります。また、将来の運用活動のプラットフォームとして SAP HANA データベースの検出と登録を可能にする AWS Systems Manager for SAP を利用する最初のユースケースでもあります。 AWS Backup について AWS Backup は、様々な AWS リソースの大規模なデータ保護を簡素化する、費用対効果が高く、完全に管理されたポリシーベースのサービスです。以下は、SAP HANA にとって関心のある AWS Backup の機能です： バックアップの一元管理： データベースのバックアップスケジュール、継続的なバックアップとポイントインタイムリストア（PITR）の有効化、リカバリなどのバックアップ操作を一元管理できます。AWS Backup コンソールから他の AWS リソースとともに SAP HANA データベースリソースを管理できるため、IT ユーザーに一貫したエクスペリエンスを提供できます。 複数の AWS サービスとの統合： AWS Backup コンソールは、複数の AWS モニタリングサービスと統合されているため、バックアップステータスに基づいた監視やアクションを簡単に実行できます。 Amazon CloudWatch を使用して、AWS Backup は完了または失敗したバックアップ、コピー、およびリストアジョブのメトリクスを提供します。AWS CloudTrail は、AWS バックアップ API コールを監視するために使用できます。 AWS CloudTrail は、AWS Backup のすべての API コールをイベントとしてキャプチャする。 Amazon Simple Notification Service (Amazon SNS) を使用することで、バックアップが成功した時やリストアがトリガー/完了した時などのバックアップステータスに基づいた通知を構成できます。また、 Amazon EventBridge を使用して AWS Backup イベントを監視できます。AWS バックアップは、ベストエフォートベースのポリシーで 5 分ごとに EventBridge にイベントをトリガーします。 AWS PrivateLink を使用した VP C エンドポイントのインターフェース： AWS Backup は AWS PrivateLink をサポートしています。 AWS PrivateLink では、インターフェース VPC エンドポイントを作成することで、Amazon Virtual Private Cloud（VPC）と AWS Backup エンドポイント間のプライベート接続を確立できます。AWS Backup for SAP HANA と AWS PrivateLink により、すべてのネットワークトラフィックを AWS グローバルネットワーク内に維持しながら、安全でスケーラブルな方法で AWS Backup for SAP HANA オペレーションにプライベートアクセスできます。 バックアップボールトの暗号化：AWS Backup では、バックアップ Vault はバックアップを保存して整理するコンテナです。SAP HANA データベースのバックアップは、AWS Key Management Services（AWS KMS）を使用して暗号化された バックアップボールト に保存されます。 AWS BackupVault Lock： AWS Backup Vault Lock は、バックアップのライフサイクルの変更を防止し、バックアップの手動削除を防止する機能で、コンプライアンス要件を満たすのに役立ちます。AWS Backup Vault Lock は、Write-Once-Read-Many（WORM）モデルを使用してバックアップを保存していることを確認するセーフガードを実装しています。 AWS Backup for SAP HANA の利用をはじめるには： AWS BackupでSAP HANA のバックアップのスケジューリングを開始する前に、いくつかの前提条件があります。これらは、 AWS Backup for SAP HANA on EC2 のドキュメントで詳細に説明されており、Amazon EC2 インスタンス用の Amazon IAM ポリシーの設定、AWS Systems Manager for SAP への SAP HANA データベースの登録、AWS Backint Agent のインストールと設定、およびオプションとしてインターフェース VPC エンドポイントの設定が含まれます。これらの作業はすべて一度だけ実行すればよく、自動化も可能です。 図-1 SAP HANA バックアップの前提条件 バックアッププランとリソース割り当て： バックアップ計画は、リソースのコレクションに対するバックアップのスケジュール、頻度、保持を定義するために使用されます。これらのリソースには、Amazon EC2 上の SAP HANA が含まれ、データベースと非データベースリソースのバックアップに対する一貫したアプローチを可能にするために、重要な Amazon EC2 リソースと組み合わせることもできます。 継続的バックアップは、AWS バックアップで選択されたリソースに使用される。SAP HANA リソースが割り当てられたバックアッププランで、連続バックアップとポイントインタイムリストア（PITR）を有効にできます。このアクションは、SAP HANA のリストアに必要なフルバックアップ、差分バックアップ、ログバックアップの管理を AWS Backup に指示します。AWS バックアップは、最後のフルバックアップの日付と変更率に基づいたリカバリ時間を考慮しながら、適切であれば差分バックアップを使用し、費用対効果の高い方法でこれを行います。 図 – 2. リソースの割り当て AWS Backup の価格 AWS Backup for SAP HANA on Amazon EC2 の価格は、従量課金モデルです。例として、US-EAST-1（N.Virginia）リージョンでは、SAP HANA Backup は 1GB-Month あたり 0.06 ドル、コールドストレージに移行したバックアップは 1GB-Month あたり 0.01 ドルです。価格の詳細については、 価格ドキュメント のページを参照してください。 制限事項 現在サポートされていない機能のリストを確認するには、 リリースノート を参照してください。 推奨される実装方法 バックアップ戦略の実装または変更には、慎重な計画とテストが必要です。本番ワークロード用に設定する前に、サンドボックスや開発環境で AWS Backup に慣れることをお勧めします。信頼性と運用の柱は、SAP データを保護するためにバックアップを使用するための良い一般的なガイダンスを提供します。特に以下を参照してください。 ベストプラクティス 10.3 – 重要な SAP データの可用性を確保するためのアプローチを定義する 設計原則 12 – データ回復の計画 結論 AWS Backup for SAP HANA は、AWS 上の SAP HANA データベースのバックアップとリストア操作を簡単に実行できるようにします。AWS のお客様は、バックアップ、リストア、システムコピーなどのデータ保護アクティビティを一元管理し、自動化できるようになりました。お客様は、複数の AWS リソースとアカウントにまたがって管理を簡素化するために拡張できる、ネイティブな AWS エクスペリエンスから恩恵を受けることができます。まず、以下のドキュメントとブログをご覧ください。 Amazon EC2 インスタンス上の SAP HANA データベースのバックアップ Centrally Manage SAP HANA Database Backup Through the AWS Backup Console（英語） 何千ものお客様が AWS を信頼して SAP ワークロードの移行、近代化、革新を行っている理由については、 SAP on AWS のページをご覧ください。 クレジット 専門知識、サポート、ご指導をいただいた以下のメンバーに感謝いたします。 Sabari Radhakrishnan、Balaji Krishna、Adam Hill、Nerys Olver、Parisudh Marupurolu、Marcos Perez Seoane、Spencer Martenson. 翻訳は Partner SA 松本が担当しました。原文は こちら です。

多くのお客様はビジネスの価値や競争力を高めるために、 Amazon Web Services (AWS) にシステムをマイグレーションしています。クラウドマイグレーションによって得られるメリットの最大化を目的としたマイグレーションの実施だけではなく、アプリケーションのモダナイゼーションへの取り組みもマイグレーションと合わせて実施される傾向があります。この組み合わせにより、アプリケーションの俊敏性、拡張性、耐障害性が向上します。AWS を使用してワークロードのポートフォリオをモダナイズすることは、コンテナ、サーバーレス、目的別データストア、ソフトウェアの自動化を活用したワークロードのリプラットフォーム、リファクタリングやリプレースが可能であることを意味しています。これらの機能により、AWS の俊敏性と総コストの最適化(Total Cost Optimization, TCO)というメリットを最大限に享受いただく事が可能です。 今回の Let’s Architect！ では、ハンズオンや、お客様事例、ヒントや秘訣を共有します。そしてお客様のアプリケーションを AWS へマイグレーション・モダナイゼーションしていく際の参考にしてください。 Migrating to the cloud: What is the cost of doing nothing? クラウドマイグレーションの実現は、大企業よりも中小企業の方が早いと思っていませんか？実際は、クラウドマイグレーションのスピードは必ずしも企業規模に左右されません！企業規模はマイグレーションやモダナイゼーションの成功の明確な指標にはなりません。しかしながら、企業を進化させるためには文化と考え方の変革が不可欠です。 マイグレーションに関して言えば、何もしないことの代償は金銭的なものだけではありません。企業はイノベーションペースの低下や、セキュリティの負担増が予想されます。この動画では、マイグレーションを行うことによる財務的なメリットを分析し、AWS へのクラウドマイグレーションに取り組んでいくためのメンタルモデルを共有します。また、 マリオット のチームメンバーはどのようにマイグレーションを計画したのかということや、マイグレーションの過程で学んだ教訓を説明します。 re:Invent 2022 動画はこちら 早期にマイグレーションするメリット – re:invent 2022 の登壇資料を元にした参考訳 AWS でのレガシー .NET Framework モノリシック アプリケーションのモダナイゼーションへの道すじ 　( 原文 ) 企業等の組織の目的として、お客様のニーズに則した最高の技術的なソリューションを提供することがあります。クラウドを導入するどの段階においても、モノリシックなアプリケーションの管理と構築に終始する企業は数多く存在します。ここでは、モノリシックな .NET Framework アプリケーションから AWS 上のモダンな マイクロサービスへとマイグレーションしていく道筋を探り、モノリスアプリケーションをマイクロサービスに分割し、モノリスアプリケーションをコンテナ化する AWS のツールについて説明します。 コスト最適化もワークロードをモダナイズするための重要な要素です。この課題を解決していくには Linux ベースのシステムへの移行やオープンソースのデータベースエンジンの使用をする事などが含まれます。 Migrate and Modernize enterprise workloads with AWS という動画では、AWS を使用したエンタープライズワークロードのマイグレーションとモダナイゼーションの過程について説明します。 詳細については こちらのブログ ( 原文 )も参照ください。 マイクロサービスを用いたモダナイズ・リアーキテクチャ Implementing a serverless-first strategy in an enterprise あらゆる規模の組織が、AWS 上のサーバーレスアーキテクチャの活用で獲得可能な俊敏性、コスト削減、開発者エクスペリエンスといった恩恵を所望しています。費用対効果 (Return On Investment , ROI)は大企業にとって非常に大きなものになり得ます。しかし、セキュリティのベストプラクティスとガバナンスを確保しながら現状のアーキテクチャを克服していくことは、多くの企業が苦戦するハードルです。このライトニングトークでは、これらのハードルを克服するためにサーバーレスファースト戦略を導入していく方法を学びます。 デルタ航空 は、AWS 活用に向けた道のりの一環としてサーバーレスファーストを実現しており、その事例を共有します。 動画を視聴 サーバーレスの利点 Application Migration with AWS このワークショップは架空のアプリケーションを AWS へマイグレーションし、モダナイズする方法を紹介します: データベース移行の実施 多様な移行戦略(モノリスアプリケーションをコンテナに分解など)を使用した Web サーバーのマイグレーションとモダナイゼーション &nbsp;AWS Well-Architected Framework の運用上の優秀性、セキュリティ、パフォーマンス効率、コスト最適化といった柱に従い、デプロイしたアーキテクチャを改善する方法の解説 ワークショップにアクセス Web サーバーの様々なマイグレーション戦略 See you next time! アーキテクチャツールやリソースを参照いただきありがとうございます！ 次回はコンテナによる分散システムについて解説します。 このシリーズの他の投稿は、 AWS Architecture Blog の Let’s Architect! ページを参照ください。 本記事はアマゾンウェブサービスジャパンの畠泰三が翻訳を担当しました。原文は こちら

2023年8月、 Amazon Web Services（AWS） は VMware Explore US 2023 にグローバル・ダイヤモンド・スポンサーとして参加しました。この4日間のイベントはラスベガスで開催され、エキサイティングな発表、インサイトに満ちたセッション、ネットワーキングの機会で溢れていました。 このイベントは、 AWS のパートナーである VMware と共に、お客様のデジタルトランスフォーメーションジャーニーを支援するという我々のコミットメントが強調されました。 AWS ブースからスポンサーセッションに至るまで、 VMware Explore における当社のプレゼンスは、 VMware Cloud on AWS によって、お客様がいかに迅速かつ安全で、コスト効率の高いクラウド・ジャーニーを実現できるかを紹介しました。 本記事では、 VMware Explore US 2023 の主なハイライトについてまとめています。エキサイティングな発表内容や、 VMware Cloud on AWS のセッションにオンデマンドでアクセスできます。 クラウド変革を加速する最新の機能強化 VMware との戦略的協業は今年で6年目を迎えました。 VMware Cloud on AWS の一般提供開始以来、世界中の多くのお客様のクラウドへの迅速な移行を支援してきました。このソリューションにより、お客様は既存のインフラストラクチャとスキルセットを最大限利用しながら、クラウドの力を活用できるようになりました。 VMware Cloud on AWS の詳細については、 このビデオ をご覧ください。 今年の VMware Explore ではいくつかの重要な発表があり、以下のリストでは VMware Cloud on AWS に関する機能強化の概要を紹介します： VMware Cloud on AWS: Advanced Subscription Tier VMware Cloud on AWS Advanced subscription tier をご紹介します。この新しいサブスクリプションは、従来のサブスクリプションに代わるもので、お客様により高度なエクスペリエンスを提供します。 VMware Cloud on AWS の共同設計によるコンピュート、ネットワーク、およびストレージ機能による既存のメリットを享受しながら、クラウド管理およびセキュリティサービスにアクセスし、クラウド移行を加速することができます。 この新しいサブスクリプションでは、 VMware Aria Automation、Aria Operations、Aria Operations for Logs、Aria Migration の30日間無料トライアル、コンテキストを考慮したマイクロセグメンテーション（ L7 DFW AppID ）、分散FQDN 許可リスト、ユーザーID ベースのファイアウォール（ IDFW ）、 NSX+ Policy Management などの高度なセキュリティ機能など、 VMware の包括的なサービススイートを利用できます。 これらのサービスはすべて、 VMware Cloud on AWS ソリューションにシームレスに統合されており、すぐに使用できます。詳細については、 AWS の担当者にお問い合わせください。 ネットワーキングの強化 VMware NSX+ は、 NSX のフルマネージド SaaS （ Software-as-a-Service ） です。これにより、ネットワーク、セキュリティを提供し、運用チームが、プライベートクラウド、ハイブリッドクラウド、パブリッククラウドで、単一のクラウドコンソールから NSX サービスを利用し運用できます。 ストレージの強化 VMware Cloud on AWS は、ストレージを最適化して容量あたりのコストを削減しながら、エンタープライズグレードのパフォーマンスをトレードオフなく実現する vSAN Express Storage Architecture を発表しました。今回の発表により、 VMware Cloud on AWS は、業界初のシングルティアハイパーコンバージドインフラストラクチャ（ HCI ）ストレージソリューションを提供し、最適化されたパフォーマンス、効率性、高い回復力、次世代ストレージデバイスによる俊敏な運用を実現します。 また、 VMware Exploreでは、 Virtual Private Cloud （ VPC ） peering を通じて、お客様の Software-Defined Data Center （ SDDC ）と Amazon FSx for NetApp ONTAP の VPC を peering 可能になると発表されました。今回の発表により、2つの VPC 間のネットワーク接続により、プライベート IPv4 アドレスまたは IPv6 アドレスを使用して、 VPC 間でトラフィックをルーティングできるようになります。どちらの VPC 内のインスタンスも、あたかも同じネットワーク内にあるかのように相互に通信することができます。詳細については AWS のブログポスト をご覧ください。 災害対策およびランサムウェア リカバリの強化 VMware Ransomware Recovery は、組織が自信を持って機敏にランサムウェア攻撃から回復できるようにする、専用のランサムウェア Recovery-as-a-Service ソリューションを提供します。今回の機能強化により、お客様は最大50台の仮想マシン（ VM ）を同時に検査、管理、およびリカバリできるようになり、迅速なリカバリとダウンタイムの最小化が可能になります。 リージョン拡大 AWS は、お客様からのご要望が多い世界中のリージョンへのサービス拡大を続けています。チューリッヒとメルボルンが新たに加わり、 VMware Cloud on AWS は25リージョンでご利用可能になりました。 発表内容のより包括的なリストについては、　VMware の　 What’s New on VMware Cloud on AWS ブログポストを参照してください。 VMware Cloud on AWSセッションのオンデマンド視聴 AWS チームは、ブレイクアウト、チュートリアル、カスタマーパネル、および ask-me-anything ラウンドテーブルで構成される9つのスポンサーセッションを開催しました。以下の録画セッションをクリックしてオンデマンドでご覧ください。 AWS Keynote: Accelerate Transformation with VMware Cloud on AWS 組織を変革する準備を整えましょう。この基調講演では、シームレスなハイブリッドクラウドソリューションを実現する VMware Cloud on AWS の活用について、AWS と VMware のリーダーから話を伺います。このセッションでは、コラボレーションの最新情報、お客様の事例、ビジネス変革を推進するための思慮深いインサイトをご紹介します。 Deep Dive Tutorial: Accelerate Migration and Modernization このチュートリアルでは、移行とモダナイゼーションの専門知識を強化します。効果的な移行戦略とネットワークアーキテクチャを学ぶとともに、 VMware Cloud のシームレスな移行とワークロード最適化のための AWS サービスを習得します。 Panel: Successful Transformations with VMware Cloud on AWS このパネルセッションでは、AWS のお客様とパートナーによる実際のクラウド移行の成功事例をご紹介します。移行を加速し、デジタル変革を推進する上で VMware Cloud on AWS が果たす役割について焦点を当てています。 Are You Well Architected? Transform VMware Workload Migration with AWS このセッションでは、堅牢でスケーラブル、かつコスト効率の高い移行を実現するための実践的なインサイトを得ることができます。 AWS Well-Architected Framework を使用して VMware のワークロードを評価し、クラウド移行を設計する方法を学びます。 Using AWS AND VMware Synergy for Developer and DevOps Success AWS と VMware ソリューションの連携により、アプリケーション開発とデプロイを最適化する方法について理解を深めてください。このセッションでは、 VMware ソリューションで Amazon Elastic Kubernetes Service （ Amazon EKS ） の機能を強化する方法と、クラウド管理を合理化する方法について、エキスパートが解説します。 AWS クラウドで VMware Aria Cost を使用して、クラウドの財務と総所有コスト（ TCO ）をシームレスに管理する方法をご紹介します。 Building Advanced Storage and Network Architectures 弾力性のあるクラウド インフラストラクチャを構築する方法を学び、 vSAN、 Amazon FSx for NetApp ONTAP を使用した最適なストレージに関するインサイトを得ます。また、 AWS Direct Connect、 AWS Transit Gateway、 VMware Transit Connect を使用した効率的なネットワーキングについても学びます。 VMware Cloud on AWS を使用して、セキュリティ、マルチテナント、およびスケーリングに関する高度なテクニックを習得します。 Accelerate Data Center Exit with VMware Cloud on AWS for Public Sector 公共部門向けにカスタマイズされた VMware Cloud on AWS は、FedRAMP および米国国防総省の Impact Level 5 （ IL5 ） 認可を満たしながら、政府機関のワークロードの移行、モダナイゼーション、およびインフラストラクチャサービスを加速する方法についてご説明します。他の期間と共同で大規模なプロジェクトを完了したエキスパートから、データセンターの退避とクラウド移行に関するインサイトを得ることができます。 AWS と VMware ：6年にわたる共同イノベーションとその成果 AWS と VMware は、シームレスで統合されたハイブリッドクラウドソリューションをお求めのお客様に、両社の長所を提供することに専念しています。 VMware Explore US 2023 の AWS ブースにお越しいただいた皆様、スポンサーセッションにご参加いただいた皆様に感謝申し上げます。 最新のイノベーションをより深く知りたい方は、 VMware の What’s New on VMware Cloud on AWS ブログポストをご覧ください。 VMware Cloud on AWS に関するその他のセッション（ VMware 主催のセッションを含む）については、 VMware Video Library でご覧いただけます。 VMware Cloud on AWS がクラウドへの移行をより早く、安全で、かつ費用対効果の高いものにするために、どのように役立つかについての詳細は、 VMware の Web サイトをご覧ください： VMware Cloud on AWS website (AWS) VMware Cloud on AWS website (VMware) @vmwarecloudonaws (X/Twitter) 翻訳はソリューションアーキテクト　澤が担当しました。原文は こちら です。

このブログ記事は、Epic Games の Senior Product Specialist である Michael Muir 氏と共同執筆したものです。 図 01: Epic Games の Unreal Engine は、リアルタイムのコンテンツ生成、操作、レンダリングを提供します。 はじめに Epic Games の Unreal Engine は、リアルタイム 3D コンテンツの作成と操作に革命をもたらしました。Unreal Engine 5 の Lumen や Nanite などの技術的進歩により、没入感の高い忠実度とリアルなインタラクティブエクスペリエンスが飛躍的に向上し、テレビや映画からゲーム、建築、エンジニアリング、建設 (AEC) に至るまで、さまざまな業界で活用されています。 Unreal Engine の主な利点の 1 つは、アーティストがリアルタイムで最終クオリティ、またはそれに近いクオリティで作業できることです。しかしながら、このリアルタイムワークフローの利点は、アーティストがショットのレンダリングやその他のパイプラインプロセスが完了するのを待たなければならないとなると、途端にに失われてしまいます。Windows、Linux、macOS ベースのレンダーファーム向けのハイブリッド型の業務管理およびコンピュートマネジメントソフトウェアである AWS Thinkbox Deadline は、この問題の解決に役立ちます。レンダリングなどのプロセスをコンピュートファームにオフロード可能になるため、クリエイティブチームはその分、アーティスティックな課題に集中できるようになります。 この度、AWS Thinkbox は Epic Games と共同で、新しいさまざまな機能を網羅したプラグインのセットを発表しました。この新しいプラグインを使うと、レンダリングなどの一般的なタスクを Unreal Engine 内から直接 Deadline にサブミットすることができます。サブミット内容に関する固有の情報は、新しい Deadline Job Preset Asset タイプによりプロジェクト内に保持されます。Unreal Engine の Movie Render Queue のリモートレンダーを Deadline がサポートしたことによって、ユーザーはキューをすぐにサブミットし、ローカル、リモート、またはクラウドベースの Workers 上でレンダリングできます。また、新しい API セットにより、制作やワークフローのニーズに合わせて、より幅広いカスタムパイプライン処理機能がサポートされるようになりました。 “新しい Deadline プラグインで、 Unreal Engine 内からアーティストフレンドリーな方法で GPU レンダーファームにサブミットできるようになったことをうれしく思います” – Peter Nofz, VFX Supervisor, Rodeo FX 図 02: Deadline へのサブミットは Unreal Engine 内から直接行うことができます。 “ Deadline for UE5 プラグインは、エキサイティングな（そして必要とされていた）レンダーパイプラインを効率化するための次のステップです! ” – Aythan Maconachie, Tech Lead, Glitch Productions Deadline のセットアップ プラグインを使用して Deadline を Unreal Engine 環境に統合するには、以下の要件が必要です。 Deadline Repository の 10.3.0 またはそれ以降のバージョンのインストール。Deadline のインストール手順については、 こちら をご覧ください。 コンテンツを生成し、サブミットするための Unreal Engine のアーティストワークステーション（Unrealのバージョン 5.2.0 以降であること）。Unreal の新しいバージョンでプラグインをリビルドする必要がある場合は、Visual Studio Code 2022 などの開発環境も必要になります。Unreal Engine を開発用にセットアップする方法については、 こちら をご覧ください。 Unreal Engine のアーティストワークステーションに Deadline Client ソフトウェアがインストールおよび 設定済み であること。本ガイドでは、Deadline Client によるサブミット方法を使用しています。 ステップ 1: プラグインのインストール Unreal Engine のプラグインは Deadline Repository 内で提供されます。これらは Unreal Engine のプロジェクトにコピーする必要があり、今後作成する新規のプロジェクトごとにこの手順を繰り返す必要があります。 Unreal Project のフォルダー内に「 Plugins 」のサブフォルダーを作成します。 Deadline Repository のインストール画面に移動し、 &lt;Deadline Repository&gt;\plugins\UnrealEngine5\UnrealEnginePlugins にある Unreal Engine のプラグインフォルダーに移動します。 &nbsp; UnrealDeadlineService と MoviePipelineDeadline プラグインフォルダーを各プロジェクトの「 Plugins 」フォルダーにコピーします。 図 03: Unreal Engine プロジェクトに両方のプラグインを提供します ステップ 2: プラグインの有効化 プロジェクトのファイル構造内にあるファイルの保存先にプラグインがコピーされた状態で- Unreal Engine を起動し、対象のプロジェクトをロードします。 Unreal Deadline Service プラグインと Movie Pipeline Deadline プラグインの両方が Unreal Engine Editor にロードされていることを確認してください。 図 04: Unreal Engine 内の Deadline プラグインの設定 メインメニューからプラグインブラウザを開きます。 [Edit] &gt; [Plugins] 検索ダイアログで「 Deadline 」を検索します。 Unreal Deadline Service プラグインと Movie Pipeline Deadline プラグインの両方を有効にして、Editor を再起動します。 プラグインのビルドに使用されたバージョンよりも新しいバージョンの Unreal Engine を使用する場合は、その特定のバージョンと一致するようプラグインをリビルドする必要があります。確認を求められた場合は「 Yes 」と返してください。 図 05: Unreal Engine のバージョンと一致するプラグインのビルドを要求する確認画面 注： このプロセスが失敗した場合、よくある原因としては、開発環境の不備、つまり Visual Studio 2022 が整備されていない可能性があります。この リンク の詳細が示す Unreal Engine の要件に従って開発環境をアップデートする必要があります。このような問題の原因分析に役立つ詳細ログは、「 &lt;Unreal_Project &gt;/Saved/Logs 」フォルダーより確認できます。 ステップ 3: Unreal 内の Deadline Service プラグインの設定 Deadline Service プラグインは、Unreal Engine と Deadline 間の通信環境を設定するために使用されます。 Deadline Serviceを設定するには: [ Edit ] &gt; [ Project Settings ] に移動します。 ブラウザで「 Deadline 」を検索し、「 Plugins – Deadline Service 」を表示させます。 図 06: Deadline Service のオプション Deadline Command の有効化オプションは、Deadline とへサブミットする際にプラグインが使う通信のデフォルトの（推奨された）方法です。もう1つの方法は、ホストアドレスを利用して Deadline Web Service 経由で通信する方法ですが、このブログでは取り上げていません。 Deadline Service プラグインの基本設定が完了したら、さらに Unreal Engine 内のスクリプトに対して指定ディレクトリパスを設定することもできます。 &nbsp;[ Script Category Mapping s ] を追加します。 実行時に Deadline Data Asset によって解決されるディレクトリを示す key-value ペアを入力します。 ステップ 4: Data Asset ノードを使った Deadline ジョブの Preset Preset は Deadline のジョブサブミットの基礎となるもので、ジョブやタスクをサブミットする前に必ず Preset を作成する必要があります。Deadline ジョブの設定は、新しい「 DeadlineJobPresetLibrary 」クラスを使用して、Data Asset として Unreal Engine プロジェクト内に保存されます。Data Asset ノードを使うと、Deadline ジョブのサブミット用として、このプロジェクト内で再利用できる Preset を定義することができます。これらの詳細には、ジョブ名、コメント、ジョブの処理が可能な Workers の Group および Pool 、フレームレンジ、およびその他の追加情報が含まれます。 Deadline の Data Asset を作成するには: Content Browser を右クリックして、[ Miscellaneous ] &gt; [ Data Asset ] を作成します。 「 DeadlineJobPresetLibrary 」クラスを検索します。 新しい Data Asset には、「BasicDeadlineExport」など、目的を表す名前を付けます。 Job Options を展開し、Deadline ジョブの詳細を入力します。 新しい Preset 要素に、「Sequence export from Movie Render Queue」などの説明を付けます。 図 07: Deadline Data Asset は、Deadline ジョブ設定の Preset を指定するために使用されます ［ Job Info ］を展開して、Deadline ジョブの詳細を入力します。 ［ Batch Name ］はサブミットされるジョブの総称です。 ［ Group ］とは、ジョブにアサインされる UE リソースのグループのことです。 ［ Pool ］とは、ジョブにアサインされる UE リソースのプールのことです。 Plugin Info Preset を使って、後にプログラムで使用できるように追加の key-value ペアの入力が可能になります。以下は必須エントリ 2 つと推奨エントリ 1 つです。 Executable : タスクを処理させたいアプリケーションへのパス。&lt;Unreal_Install_Folder&gt;\Engine\Binaries\Win64\UnrealEditor-Cmd.exe など ProjectFile : 処理するプロジェクトファイルへのパス。&lt;Unreal_Project&gt;\ProjectFile.uproject など CommandLineArguments は任意ですが、非常に便利です。Unreal Engineの全コマンドライン引数については、 こちら をご覧ください。 Data Asset を保存します。 さらに、ジョブ Preset 内の各 Deadline オプションについては表示/非表示フラグを設定できます。これによりチームリーダーは、特定のオプションを、ジョブサブミット時にユーザーに対して表示または非表示にすることができます。表示/公開されているオプションは、ユーザーがジョブをサブミットする際に、Submitter 内で編集可能です。詳細については、「ステップ 5a: Movie Render Queueによるリモート実行」のセクションを参照してください。 注: 値データをクオートで囲む記述はサポートされていません。 ステップ5: Movie Render Queue によるレンダリング Movie Pipeline Deadline プラグインをインストールすると、Unreal Engine からショットやシーケンスの Movie Render Queue パイプラインを外部にサブミットして、Deadline 経由でレンダリングできます。Movie Render Queue内でのレンダリングには Warm Up Frames のような機能があるため、Unreal Engine はキューアイテムに合わせて同等に Deadline タスクを作成します。他の 3D・2D アプリケーションでは通常、フレーム単位でタスクを扱いますが、ここでは大抵ショット全体を 1 つのタスクとして扱います。 Deadline を Movie Render Queue の処理に対応できるように設定するには: Project Settings画面を開きます。[ Edit ] &gt; [ Project Settings ] 「 Movie Render Pipeline 」で検索し、[ Plugins] &gt; [ Movie Render Pipeline ]を表示させます。 &nbsp; [ Default Remote Executor ] の項目で「 MoviePipelineDeadlineRemoteExecutor 」を選択し、リモートレンダリングを実行するデフォルトの方法として Deadline を有効にします。 &nbsp; [ Default Executor Job ] の項目で「 MoviePipelineDeadlineExecutorJob 」を選択し、Deadline プラグインが Movie Render Queue UI 内で設定を表示できるようにします。 図 08: Deadline よりリモート実行できるように設定された Movie Render Queue シーケンスまたはショットを Deadline にサブミットするには、次の 2 つの方法があります。 ステップ 5a. Movie Render Queue によるリモート実行 Movie Render Queue を使用して、Deadline レンダリング向けにショットやシーケンスをサブミットすることができます。 図 09: Deadline でリモートレンダリングを実行するように設定された Movie Render Queue Movie Render Queue を使用してレンダリングするよう設定するには Movie Render Queue を開きます。 [ Windows ] &gt; [ Cinematics ] &gt; [ Movie Render Queue ] [ +Render ] ボタンをクリックしてシーケンスまたはショットをジョブキューに追加する、あるいは既存のショットの MoviePipelineQueue をロードします。 右側の Deadline ウィンドウからジョブの Batch Name を設定します。 同じく右側の Deadline ウィンドウ内で、レンダリング設定の制御に使用する Preset Library を選択します。 任意で、新しいアウトプットディレクトリとファイル名を指定します。 Preset Overrides のセクションでは、Deadline Data Asset のプリセットを変更することなく、現行レンダリングの Deadline Job Preset で表示されているパラメータを変更することができます。 Preset Overrides セクションでオーバーライドを作成するには: オーバーライドするパラメータの横にあるチェックボックスを選択します。 編集可能なフィールドに必要な変更を加えます。 上の例では、ユーザーは Submitter 内の 2 つのオプション（ジョブの［ Comment ］および［ Department ］の情報）を上書きしています。 レンダリングを Deadline にサブミットするには、[ Render (Remote) ] を選択して Unreal Engine に Deadline ジョブの作成を指示します。ここでは、ジョブが Deadline にサブミットされる間、コマンドラインコンソールが数秒間表示されます。 ステップ 5b. Queue Asset Submitter によるリモート実行 レンダリングジョブを Deadline にサブミットするもう 1 つの方法は Queue Asset Submitter を使用する方法です。Deadline プラグインを有効にした後に Unreal Engine メニューバーの Deadline メニューの下に表示されます。 図 10: Deadline でレンダリングをリモートで実行するように設定された Queue Asset Submitter Queue Asset Submitter を使用してレンダリングをリモートで実行するには： Queue Asset Submitter を開きます。［Deadline］ &gt; ［Submit Movie Render Queue Asset］ ジョブの［Batch Name］を設定します。 上記ステップ 4 にて Data Asset ノードを使ってジョブ情報を定義した Deadline ジョブの Preset に、［Submission Preset Name］と［Remote Preset Name］を設定します。 ［Queues］セクションで 「+」を選択し、Movie Render Queue のショット/シーケンスと関連情報をカプセル化した MoviePipelineQueue アセットを追加します。 [Submit] を選択して、ジョブを Deadlineに サブミットします Deadline のジョブと Workers Deadline Monitor アプリケーションを開くと、レンダリング待ちキューに自身のジョブと、他のユーザーがサブミットしたファーム内の他のジョブが確認できます。 図 11 : バッチ、ジョブ、タスクを表示した Deadline のモニター。Batch Name の「Meerkat」の下にネストされたジョブの「Main_SEQ」と、Movie Render Queue のエンティティごとに作成されたタスクが表示されています。 Deadlineに接続しているすべての Worker に Unreal Engine のタスクを割り当てることは可能ですが、Unreal Engine のタスクを扱う能力のある Worker にだけその作業が割り当てられるように、Worker の Pool と Group を正しく設定する必要があります。 Worker には以下の要件が必要です。 GPU など、目的とするタスクに適したハードウェア。 Deadline Data Asset &nbsp;が定義した場所に Unreal Engine&nbsp; (および関連要件) がインストールされていること。 Deadline Data Asset が定義した Unreal Engine のプロジェクトへのアクセス。 ジョブに関連する適切な Deadline の Group と Pool に 所属していること。 クラウドレンダリング Deadline では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを追加の Worker としてプロビジョニングすることで、レンダリングをクラウドに自動的かつ柔軟に拡張することができます。これらのクラウド Worker は必要に応じて立ち上げてタスクを実行させ、アイドル状態になると自動的にシャットダウンさせることができます。このコンピューティングには従量課金モデルが採用されます。 AWS の伸縮性のあるレンダリングを利用することには多くの利点があります。 変動コスト型の「オンデマンド」モデルでは、レンダーファームの固定費に対する多額な先行投資や、電力、冷却、スペース、セキュリティ面での継続的な所有コストが不要になり、ファームのコストを簡素化できます。 &nbsp;新しい GPU インスタンスを含む最新の AWS インスタンスを使用するよう、即時にレンダーファームを切り替えることができます。これにより、Unreal Engine などの製品にとって肝要な GPU や CPU 技術の進歩のペースより通常はるかに長い、ハードウェアの更新サイクルが不要になります。 レンダーファームのインフラストラクチャは、デザインチームの規模や絶えず変化する制作のニーズに応じて瞬時に動的スケーリングすることができます。これにより、制作のピークに備えてマシーンを事前に予測・管理・購入する必要がなくなります。 AWS は、32 のグローバルリージョンにわたって、レンダリング用のコンピューティングを含む 200 を超えるフル機能のサービスを提供しており（執筆時点現在）、それぞれがデータとサービスの冗長性と可用性を確保するために複数のアベイラビリティゾーンを提供しています。AWS Site-to-Site VPN、または AWS Direct Connect（AWS への専用ネットワーク接続）を利用することで、Unreal Engine のプロジェクトデータを処理前にレンダリングの Workers に同期し、完了時に結果の画像やアーティファクトを元に戻すことができます。 図 12: ストレージソリューションとして Perforce を利用したバーストレンダリングシナリオのアーキテクチャ例 今後のブログ記事で Unreal Engine のクラウド Worker へのデータ展開方法を説明する予定ですのでご期待ください。 まとめ 本記事では、チームが Unreal Engine を使用して、レンダリングなどの処理をアーティスト端末から Deadline ベースのレンダーファームにオフロードする方法について詳しく説明しました。Unreal Engine のタスクを、他の 3D や 2D のパイプラインのプロセス全体とともに 1 つのジョブの流れに統合し、その Group 内の優先順位に従ってスケジューリングできるようになりました。アーティスト端末などのオンプレミスリソースをより大きなコンピューティングリソースプールに統合することで、Unreal Engine やその他のアプリケーションが利用可能なコンピューティング能力を最大化することができます。Deadline との新たなインテグレーションにより、Unreal Engine は AWS クラウドを活用することで、プロジェクトの必要に応じて即座にスケーリングが可能になりました。 AWS Thinkbox Deadline の Unreal Engine Plugin に関して、潜在的な問題を報告、または、機能追加の提案をしたい場合は、Thinkbox Support 宛てに E メールで連絡してください : support@awsthinkbox.zendesk.com . 参考資料 Unreal Engineに関する情報は、以下からご覧いただけます。 https://www.unrealengine.com/ Deadlineに関する詳細なドキュメントは、以下からご覧いただけます。 https://www.awsthinkbox.com/deadline ワークステーションとレンダリングマシンの両方の GPU 稼働率を把握することで、効率が評価しやすくなります。以下のブログでは、AWS での分析に役立つ GPU データのログをセットアップしてキャプチャする方法について詳しく説明しています。 https://aws.amazon.com/blogs/machine-learning/monitoring-gpu-utilization-with-amazon-cloudwatch/ Unreal Engine について Epic Games の Unreal Engine は、世界で最もオープンで先進的なリアルタイム 3D ツールです。ゲーム、映画、テレビから放送やライブイベント、そして建築、自動車、シミュレーション、その他業界に至るまで、クリエイターたちは、最先端のコンテンツ、インタラクティブなエクスペリエンス、没入感のある仮想世界を提供するために Unreal を選んでいます。 @UnrealEngine をフォローし、unrealengine.com から Unreal を無料でダウンロードしてください。 Rodeo FX について Rodeo FX は、Montreal’s Top Employers に何度も選ばれ、2022 年の Mercuriades Awards では Employer of the Year に選ばれた、視覚効果・広告・アニメーション・体験型のサービスを提供するハイエンドのクリエイティブ企業です。昨年、「ストレンジャー・シングス 未知の世界」シーズン 4、「ウィッチャー」シーズン 2、および「ファウンデーション」シーズン1のシリーズ作品で 3 つのエミー賞にノミネートされ、最近では「ロード・オブ・ザ・リング：力の指輪」の第 1 シーズンでもノミネートされました。アカデミー賞を受賞した独立系企業である同社では、モントリオール、ケベックシティ、トロント、ロサンゼルスやパリのスタジオで 800 人近くのアーティストが制作にあたっています。Rodeo FX は、Netflix、HBO、Disney、Marvel、Amazon Studios、Warner Bros. やソニーなどの世界最高のストーリーテラーのクリエイティブパートナーであり、また YouTube、NBC、Apple の広告でもコラボレーションしてきました。現在取り組んでいる作品には、「ブルービートル」や「ファウンデーション」シーズン 2などがあります。最近リリースされた作品としては、「ウィッチャー」シーズン 3、「ジョン・ウィック：コンセクエンス」、「リトル・マーメイド」、「ガーディアンズ・オブ・ギャラクシー：VOLUME3」、そして同社が 2023 年の VES 賞を受賞した「ラブ、デス &amp; ロボット」Vol. 3 があります。 Glitch Productions について Glitch Productions は、シドニーを拠点とする独立系アニメーションスタジオで、世界中の何百万人ものファンに視聴されているオンラインコンテンツを制作しています。わずかな予算と時間で素晴らしいビジュアルの作成を可能にする Unreal Engine とリアルタイムレンダリングは、同社の成功に大きく貢献しています。Glitch Productions の現在の人気シリーズ「Murder Drones」は、同社の YouTube チャンネル で無料公開されています。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 森が担当しました。原文は こちら をご覧ください。

ハイブリッドクラウド戦略は、お客様に管理とガバナンスの課題をもたらします。これらの課題には、ハイブリッドな VMware Cloud on AWS (VMC) 環境とクラウド環境全体で一貫したクラウドセキュリティとコンプライアンスポリシーを維持すること、オペレーションデータを視覚化して処理するための単一画面の提供、複数のクラウド環境にわたるクラウドインフラストラクチャの導入の自動化と制御の提供が含まれます。 VMware Cloud on AWS を使用すると、VMware ワークロードを AWS で実行されている VMware が管理する Software-Defined Data Center (SDDC) に迅速に移行し、アプリケーションのリプラットフォーム (Replatform) やリファクタリングを行わずにオンプレミスのデータセンターを拡張できます。これにより、お客様は VMware の SDDC をデプロイし、AWS のグローバルインフラストラクチャ上の vSphere ワークロードをマネージドサービスとして使用できます。SDDC の仮想マシン (VM) から AWS のネイティブサービスを使用すると、ワークロードの俊敏性とスケーラビリティを高めながら、オペレーションオーバーヘッドを削減し、総所有コスト (TCO) を削減できます。 AWS Systems Manager (SSM) は、AWS、ハイブリッド、またはマルチクラウド環境向けの安全なエンドツーエンドの管理ソリューションです。このソリューションでは、Systems Manager のノード管理機能を使用して、ハイブリッド VMware Cloud on AWS 環境でコンピューティングリソースをリモート管理する方法を示します。 このソリューションでは、インベントリの収集や安全なセッションの開始など、Systems Manager による一元的なノード管理を行う方法を示します。 Amazon EC2 のパッチ自動化が VMware Cloud on AWS でシームレスに機能する方法と、一元化されたインターフェイスから VMware Cloud on AWS VM へのサードパーティパッケージのインストールとその後のプロビジョニングの両方を自動化する方法を紹介します。 インストール &nbsp; VMware Cloud on AWS 環境のセットアップ VMware Cloud on AWS の設定には、2 つのアカウントが必要です。1 つ目は VMware Cloud SDDC アカウントです。これは SDDC または VMware Cloud on AWS リソースを実行する AWS アカウントで、VMware が所有および運用しています。2 つ目に必要なアカウントは、お客様所有の AWS アカウントです。このアカウントを SDDC に正常にアタッチするには、そのアカウント内に少なくとも 1 つの Amazon Virtual Private Cloud (Amazon VPC) が必要です。この VPC を Connected VPC と呼びます。VMware Cloud SDDC のデプロイで説明されている 手順 に従って VMware Cloud SDDC アカウントをプロビジョニングすると、この VPC 内の AWS サービスに高帯域幅で低レイテンシーでアクセスできるように、Connected VPC に AWS Elastic Network Interfaces (ENI) が設定されます。 このソリューションでは、まず VMware Cloud SDDC アカウントと、Connected VPC アカウントの設定から始めます。Connected VPC アカウントで VPC を設定し、 AWS Resource Access Manager (AWS RAM) を使用して、共有されている AWS Transit Gateway に AWS Transit Gateway アタッチメント 経由でこの VPC を接続します。次に、この Transit Gateway は、VMware が提供する Transit Gateway である VMware Transit Connect とピアリングされ、このピアリングによって、Connected VPC アカウント内の VPC は VMware Cloud SDDC に接続されます。 Systems Manager エージェントを VMware Cloud SDDC 内の VMware Cloud on AWS 仮想マシン にデプロイし、お客様のワークロードアカウントで実行されている Systems Manager サービスに接続します。この設定により、Systems Manager のノード管理機能を使用してハイブリッド VMware Cloud on AWS 環境のコンピューティングをリモート管理し、ノードの一元管理と運用管理機能の両方を実現できます。 Systems Manager のセットアップ ハイブリッド環境用の Systems Manager の設定 — 他のクラウド環境の VM を含むハイブリッド環境の運用と管理を一元化するように Systems Manager を設定するには、次の 手順 に従います。 Systems Manager 用の VMware Cloud on AWS 仮想マシン の設定が完了すると、ハイブリッドマネージドノード (つまり VMware Cloud on AWS 仮想マシン) の ID は、プレフィックス「mi-」が付いた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと区別されます。Amazon EC2 インスタンス ID にはプレフィックス「i-」を使用します。 次の図は、このセットアップのソリューションアーキテクチャを示しています。 図1: Systems Manager による集中型運用管理のアーキテクチャ フリート管理 Systems Manager の機能の 1 つである Fleet Manager を使用すると、個々のノード (サービス、デバイス、またはその他のリソース) にドリルダウンして、ディスクやファイルの探索、ログ管理、コンソールからのユーザー管理などの一般的なシステム管理タスクを実行できます。 Systems Manager コンソール に移動し、左側のパネルで Fleet Manager を選択します。メインコンソールの Managed nodes パネルで、プレフィックス「mi-」の付いた VMware Cloud on AWS 仮想マシン を選択します。管理対象ノードをドリルダウンすると、仮想マシンに接続されているボリュームに保存されているフォルダとファイルデータに関する情報を表示できます。これには、インスタンスに関するリアルタイムのパフォーマンスデータや、 仮想マシン上のオペレーティングシステム (OS) ユーザーアカウントの管理などの情報が含まれます。 図 2: Systems Manager Fleet Manager を使用した管理対象ノードとしての VMware Cloud on AWS 仮想マシン 図 3: Systems Manager を使用した VMware Cloud on AWS 仮想マシン ノードの詳細 パッチ管理 Systems Manager の機能の 1 つである Patch Manager は、管理対象ノードにセキュリティ関連の更新とその他の種類の更新プログラムを適用するプロセスを自動化します。 Systems Manager コンソール に移動し、左側のパネルで [ Fleet Manager ] を選択します。メインコンソールの [ Managed node ] パネルで、プレフィックス「mi-」の付いた VMware Cloud on AWS 仮想マシン を選択し、次の手順を実行します。 ステップ 1: 下部のパネルから [ Tags ] を選択し、VMware Cloud on AWS 仮想マシン にタグキーと値を追加します。 ステップ 2: こちらの 手順 に従い、タグを使用して管理対象ノードをパッチグループに追加し、ステップ 1 と同じタグキーを PatchGroup タグキーのタグ値として使用するようにします。 AWS CloudFormation コンソールに移動し、 aws-patch-manager-v1.yaml CloudFormation テンプレートを 起動します 。パラメータには、上記のステップ 1 のタグキーを VmcTagKey パラメータの値として指定します。 このテンプレートは、毎週実行される Systems Manager State Manager アソシエーションを作成し、「AWS-RunPatchBaseline」自動化ドキュメントを使用して、タグ付けされた VMware Cloud on AWS 仮想マシン に対しパッチグループに関連付けられたパッチベースラインを適用します。テンプレートが正常にデプロイされたら、State Manager コンソールに移動し、右側のパネルで「PatchVmsWeekly」というサフィックスが付いた名前のアソシエーションを選択して、VMware Cloud on AWS 仮想マシン のパッチ適用をテストできます。[ Apply Association now ] ボタンを選択すると、VMware Cloud on AWS 仮想マシン のオンデマンドパッチ適用が開始されます。 以下の図は、VMware Cloud on AWS 仮想マシン のパッチ適用ステータスが非準拠から成功ステータスへと変わる様子を示しています。 図 4: パッチベースラインが適用される前の非準拠のパッチ適用ステータスを示す VMware Cloud on AWS 仮想マシン 図 5: Systems Manager Patch Manager によるパッチ適用中の VMware Cloud on AWS 仮想マシン 図 6: Systems Manager Patch Manager によるパッチの適用が成功したことを示す VMware Cloud on AWS 仮想マシン 図 7: Systems Manager Patch Manager のコンプライアンスレポートによるパッチの適用が成功したことを示す VMware Cloud on AWS 仮想マシン パッケージの配布 お客様は、CrowdStrike、TrendMicro、Tenable などのサードパーティのエージェントベースのパッケージや脆弱性管理ツールを日常的に活用して AWS 環境を保護しています。AWS は、 AWS Systems Manager Distributor (Distributor) によるサードパーティエージェントの配布をサポートしています。Distributor では、独自のソフトウェアをパッケージ化したり、Amazon CloudWatchAgent などの AWS 提供のエージェントソフトウェアパッケージを見つけて、お客様の VMware Cloud on AWS 環境を含む AWS Systems Manager マネージドインスタンスにインストールすることができます。 以下の手順に従って、サードパーティソフトウェア用のパッケージを作成し、Amazon S3 にアップロードします。このブログ記事では、s3-examplepackage-[ accountid ]-[ region ] という名前の Amazon S3 バケットを使用しています。サンプルパッケージフォルダの S3 バケットにアップロードされたステップワイズインストラクションのサンプルパッケージを使用して、ソリューションをデモンストレーションします。 サンプルパッケージ には、完成した JSON マニフェストと 3 つの.zip ファイルが含まれています。次の図は、S3 にアップロードされたカスタムパッケージを示しています。 図 8: VMware Cloud on AWS 仮想マシン にインストールするカスタムパッケージを含む S3 バケット AWS CloudFormation コンソール に移動し、こちらの 指示 に従って aws-centralizedssmdistributor-v1 CloudFormation テンプレートを使用して CloudFormation スタックを起動します。このテンプレートを使用すると、カスタムパッケージを、AWS Organizations の各メンバーアカウントの Distributor コンソールの Owned by me タブから Systems Manager Automation ドキュメントとして利用できるようになります。次に、各メンバーアカウントに State Managerーアソシエーションをプロビジョニングし、アソシエーションで指定されたスケジュールとタグに従ってそのアカウントにパッケージをインストールします。テンプレートは以下のパラメータを取ります。 PackageName: パッケージの名前 s3PackageBucket: パッケージコンテンツがアップロードされる S3 バケットの名前 (例: s3-examplepackage-[ accountid ]-[ region ]) s3PackageBucketFolder: マニフェストがアップロードされる S3 バケットフォルダーの名前 (例:SimplePackage2) s3PackageUrl: パッケージの内容がアップロードされるプレフィックスを含むバケットの HTTPS URL (例: https://s3-examplepackage-[ accountid ]-[ region ].s3 [ region ]. amazonaws.com/examplepackage) Version: マニフェストファイルの正確なバージョン名を指定します (例:1.0.2) AssociationName: アソシエーションの名前 Action: パッケージをインストールするかアンインストールするかを指定します。(例:In-place update) InstallationType: インストールの種類を指定します (例:Install または Uninstall) Outputs3Prefix: AWS Systems Manager の実行コマンド出力に使用される S3 キープレフィックス (“Default”) ScheduleExpression: AWS Systems Manager アソシエーションのスケジュール式。(例:「料金 (30 分)」) TargetResourceTagKey: ターゲットの AWS Systems Manager タグキー (パッケージを VMware Cloud on AWS 仮想マシン にのみインストールしたい場合は VmcTagKey を指定します) TargetResourceTagValue: ターゲットの AWS Systems Manager タグ値 (パッケージを VMware Cloud on AWS 仮想マシン にのみインストールしたい場合は、VmcTagKey の値を入力します) テンプレートが正常にデプロイされたら、AWS Systems Manager コンソールに移動し、左側のパネルから [ Distributor ] を選択します。「Owned by me」タブを選択し、サンプルパッケージがそこにあることを確認します。パッケージ (SimplePackage2) を選択し、詳細セクションからバージョンを検証します。追加情報セクションの添付ファイル情報に、カスタムパッケージ (examplepackage) のマニフェストファイルとまったく同じように zip ファイルとハッシュが含まれていることを確認します。Distributor で利用可能になったカスタムパッケージ（SimplePackage2）は次のとおりです。 図 9: Distributor の各メンバーアカウントの「Owned by me」タブでカスタムパッケージを利用できるようにする セッション管理 Systems Manager の機能の 1 つである Session Manager を使用すると、受信ポートを開いたり、拠点ホストを管理したり、SSH キーを管理したりすることなく、安全で監査可能なノード管理が可能になります。管理者は、1 つの場所から VMware Cloud on AWS 仮想マシン へのアクセスを許可および取り消すことができます。また、マルチクラウド環境の Linux、macOS、Windows Server の管理対象ノードのユーザーに 1 つのソリューションを提供できます。ユーザーは、SSH キーを提供しなくても、ブラウザまたは AWS コマンドラインインターフェイス（AWS CLI）からワンクリックで、クラウド上のマネージドノード（VMware Cloud on AWS 仮想マシンなど）に接続できます。 図 10: Windows VMware Cloud on AWS 仮想マシンによる安全なセッションアクセス インベントリー管理 Systems Manager の機能の 1 つである Inventory は、オンプレミスでも他のクラウドでも、AWS で実行されている管理対象ノードからメタデータを収集します。メタデータには、アプリケーション (アプリケーション名、発行者、バージョン)、ファイル (名前、サイズ、バージョン、インストール日、変更、最終アクセス日時)、ネットワーク構成 (IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスク) などが含まれます。Systems Manager Inventory によって収集されるメタデータタイプの全リストには、 こちら からアクセスできます。 Systems Manager コンソール に移動し、ナビゲーションペインで [ Inventory ] を選択します。Inventory ページの Systems Manager コンソールのデータには、データのクエリに役立ついくつかの定義済みカードが含まれています。 図 11: AWS Systems Manager Inventory に VMware Cloud on AWS 仮想マシン のインベントリメタデータのクエリに役立つ定義済みのカードが表示される クリーンアップ 繰り返しの課金を防ぎ、この記事で説明されていソリューションを試した後にアカウントをクリーンアップするには、次の手順を実行してください。 1.VMware Cloud on AWS 仮想マシン から Systems Manager エージェントをアンインストールするには、次の 手順 に従います。 2. aws-centralizedssmdistrubutor-v1 テンプレートの CloudFormation スタックを 削除 します。 3.このソリューション用に作成された s3-examplepackage-[ accountid ]-[ region ] Amazon S3 バケットを 削除 します。 まとめ クラウド運用サービスを使うと、統一された運用ビューと最適化された IT インフラストラクチャによって、クラウド全体にわたる管理、オーケストレーション、ポータビリティの課題を軽減できます。Systems Manager はクラウド運用サービスであり、ハイブリッド環境のコンピューティングをリモート管理するために使用できるノード管理機能を提供します。この投稿では、Systems Manager を使用して VMware Cloud on AWS で実行されているコンピューティングのインベントリの収集、安全なセッションの開始、パッチ管理とパッケージ配布の一元化と自動化を行う方法を示しました。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。

昨年、 VMware Cloud on AWS と Amazon FSx for NetApp ONTAP の統合 を発表しました。この統合が利用できるようになってから、注目が高まり、採用が増えてきています。 VMware Cloud on AWS により、オンプレミスのデータセンターを拡張し、マシンイメージ形式の変換やリプラットフォームを行うことなく、ワークロードを簡単に移行することができます。 Amazon FSx for NetApp ONTAP は、NetApp ONTAP ファイルシステムをクラウド上で利用できるフルマネージドのストレージサービスです。 また昨年に、 単一のアベイラビリティーゾーン (AZ) での展開 のサポートも開始しました。 AWS Transit Gateway (TGW) がソリューションの要件となっていましたが、ファイルシステムを VMware Cloud on AWS の Software-Defined Data Center (SDDC) に柔軟に接続できるようになりました。 そしてこの度、 Amazon VPC Cloud (VPC) ピアリング のサポートが開始されます。そのため、ソリューションの要件として AWS Transit Gateway が不要になります。 この記事では、VPC ピアリングによる接続の利点と、接続手順および考慮事項について説明します。 メリット VPC ピアリングは、2 つ以上の VPC ネットワーク間をプライベートに接続し、セキュリティを向上させます。トラフィックをパブリックインターネットから隔離すると、トラフィックが Amazon Web Services (AWS) クラウドネットワークから出ることがないため、スタックからのあらゆるリスクを軽減することができます。 ピアリングされた VPC と SDDC 間でピアリングが設定されますが、トラフィックは管理サブネットに制限され、NFS トラフィックのみが許可されます。 VPC ピアリングを使用すると、ネットワーク転送コストを節約でき、ネットワークレイテンシが改善します。ピアリングトラフィックは AWS ネットワークから出ないため、パブリック IP のレイテンシが小さくなります。VPC ピアリングは VPC 間にラインレートの接続を確立することで、ピアリングされた VPC において Elastic Network Interface (ENI) 間の通信が、ミリ秒以下のレイテンシで可能になります。 VPC ピアリングを使用する他の理由は、インスタンスがパブリック IP アドレスを必要としない場合や、パブリックインターネットへのネットワークアドレス変換 (NAT) を必要としない場合です。 ソリューションの概要 同一または異なる AWS アカウントやリージョンにある 2 つの VPC 間で、VPC ピアリング接続を作成することができます。VPC ピアリング接続では、プライベート IPv4 または IPV6 アドレスを使用してホスト間で通信できます。 Network File System (NFS) データストア接続は、NSX をバイパスし、ESXi ホストと FSx for ONTAP ベースの NFS ストレージの間で確立されるため、ルーティングされた接続を経由する必要なく、2 つの VPC 間で直接接続が確立されます。 図 1 – VPC ピアリング 接続プロセス 接続には、SDDC がデプロイされている VMware が管理する AWS アカウントと、Amazon FSx for ONTAP ファイルシステムがデプロイされているお客様の AWS アカウントが必要です。 VMware 管理の AWS アカウントと、お客様の AWS アカウント間で、VPC ピアリングをセットアップするために必要な大まかな手順を説明します。 お客様は VMware のカスタマーサクセス担当者またはアカウント担当者に連絡し、VCP ピアリングを依頼します。 リクエスト側 VPC の所有者 (VMware) が、受け入れ側 VPC の所有者 (お客様) に、VPC ピアリング接続を作成するためのリクエストを送信します。 VPC ピアリング接続を有効にするために、受け入れ側 VPC の所有者 (お客様) が、VPC ピアリング接続のリクエストを受け入れる必要があります。 お客様が VMware に連絡し、リクエストを受け入れ、VPC ピアリング接続を完了できることを伝えます。 VMware が、ピアリング接続を使用するようにネットワークルートを更新します。 お客様が、お客様の VPC で同じことを行い、NFS トラフィックを許可するようにセキュリティグループルールを設定します。 考慮事項 Amazon FSx for NetApp ONTAP の VPC ピアリングは、NFS データストアのトラフィック専用です。その他のトラフィックはブロックされています。 VPC ピアリングは、SDDC のバージョンが v1.20 以降であり、シングルアベイラビリティーゾーンの構成である必要があります。マルチアベイラビリティーゾーンの構成で FSx for NetApp を利用する場合は、AWS Transit Gateway を使用するアーキテクチャが必要で、SDDC への接続には引続き SDDC グループを使用する必要があります。SDDC が v1.20 より前のバージョンを実行しており、VPC ピアリングを利用したい場合は、VMware に SDDC のアップグレードをリクエストしてください。 VMware はストレッチクラスタのデータストアとして外部ストレージをサポートしていません。VMware のロードマップで将来的に対応予定となっています。 料金 VPC ピアリング接続の作成は無料です。また、同一アベイラビリティーゾーン内で VPC ピアリング接続を介して転送されるデータは無料です。ストレージと SDDC が異なるアベイラビリティーゾーンに配置されている場合には、アベイラビリティーゾーンをまたいだ VPC ピアリング接続間でのデータ転送料金が適用されます。 まとめ この VPC ピアリングの提供開始により、AWS Transit Gateway でのデータ処理料金のコストを追加で発生させることなく、Amazon FSx for NetApp ONTAP で VMware Cloud on AWS を最大限に活用することができます。これにより、VMware Cloud on AWS 内で運用する際の総所有コスト (TCO) をさらに削減し、機能を向上させることができます。 この導入オプションの詳細については、 VMware Cloud on AWS のページ 、 FSx for NetApp ONTAP の製品ページ 、 AWS News Blog のアナウンス をご覧ください。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。

このブログは 2023 年 4 月 19 日に Bowen Wang によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 プリンシパルプロダクトマネージャである Dennis Newberry とサステナビリティプロダクトマネージャの Kurt Yeager がブログに寄稿しました。 Customer Carbon Footprint Tool は CSV ダウンロードオプションをサポートするようになりました。これにより、カーボンフットプリントデータを詳細に確認し、そのデータを他のレポートシステムに取り込み、さらなる分析や情報共有を行うことができます。 背景 AWS のビジネス価値は、総所有コストの削減だけではありません。AWS の規模の経済性、高可用性、俊敏性は、スタッフの生産性の向上、ビジネスリスクの軽減、持続可能性の向上に役立ちます。AWS で得られるメリットの 詳細 をご覧ください。 近年、より効率的で持続可能な方法で事業を運営することに注力し、エネルギー効率の目標を設定する企業が増えています。AWS は 2022 年 3 月に Customer Carbon Footprint Tool (CCFT) をリリースしました。これにより、AWS サービスの使用による二酸化炭素排出量と、再生可能エネルギーで運用される AWS のインフラストラクチャを活用することによる現在および予測される排出削減量を追跡できます。 ダウンロード可能な CSV ファイルによる二酸化炭素排出量データの可視性向上 以前は、CCFT のサマリーレポートは PDF 形式でダウンロードできました。しかし、企業のニーズに基づいてより包括的なサステナビリティレポートにデータを取り込むことができるように、カーボンフットプリントレポートを CSV 形式でダウンロードしたいという声が多くのユーザーから寄せられています。ダウンロード可能なレポート形式の変更に伴ってAWS はレポート内のデータの細分化も強化しました。 炭素報告基準の引き下げ : AWS は炭素報告基準を小数点以下 1 桁から小数点以下 3 桁に引き下げました。つまり、炭素排出量データは、以前の 0.X 二酸化炭素換算トンから 0.00X 二酸化炭素換算トンで入手できるようになりました。この変更によって、環境が小さく二酸化炭素排出量が 0.1 二酸化炭素換算トン未満のお客様も二酸化炭素排出量を確認できるようになります。目に見える二酸化炭素排出量の閾値を 1 kg に引き下げることで、より多くのAWSのお客様が二酸化炭素排出量の報告を開始できるようになります。 カーボンの粒度の向上 ：CCFTのユーザーインターフェースと以前にダウンロードした PDF では、地域別またはサービス別の月次サマリーデータが表示されていました。新しい CSV ダウンロードにより、炭素データを月、サービス、地域別に多次元レベルで分析できるようになりました。たとえば、北米での Amazon EC2 使用量の二酸化炭素排出量を確認できるようになりました。これにより、二酸化炭素排出量の主な発生源をより正確に特定できます。 仕組み AWS 請求コンソールにログインし、「コストと使用状況レポート」を選択します。 画像 1 : 請求コンソールでのコストと使用状況レポート 下にスクロールすると、炭素排出量の概要、お客様の排出量の削減、地域別やサービス別の排出量の分布を含む概要レポートが表示されます。「ダウンロード」ボタンがあり、クリックすると詳細データを CSV ファイルとしてダウンロードできます。 画像 2 : Customer Carbon Footprint Tool のグラフや表、「ダウンロード」ボタン CSV レポートを作成すると、AWS アカウント ID、トン単位の炭素排出量データ、AWS サービス、地域の詳細が表示されます。これにより、選択したディメンション別にデータを表示するのが簡単になります。たとえば、地域、サービスごとのクイックピボット、または BI システムにデータを取り込むことができます。 図 1 : CSV 形式のサンプルの CCFT レポート 図 2 : CCFT データを含むピボットレポートの例 結論 炭素排出量レポートの可視性と柔軟性が向上したことで、持続可能性イニシアチブの進捗をより細かく管理および最適化できるようになります。Customer Carbon Footprint Tool の詳細については、この ユーザーガイドを ご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: Customer Carbon Footprint Tool Bowen Wang Bowen は、AWS 請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は財務リーダーとビジネスリーダーがクラウドの価値とクラウドの財務管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。前職ではあるテック系スタートアップ企業がビジネスオートメーション製品を中国市場に投入し、現地のカスタマーサービスコールセンターの設立を支援していました。

深層学習モデルを大規模にデプロイする際には、パフォーマンスとコストのメリットを最大化するために、基盤となるハードウェアを効果的に活用することが重要です。高スループットかつ低レイテンシであることが必要となる本番ワークロードの場合、 Amazon Elastic Compute Cloud (EC2) インスタンス、モデルサービングのスタック、デプロイアーキテクチャの選択が非常に重要です。非効率的なアーキテクチャはアクセラレーターの最適化がなされていないことから、不必要に高い本番コストにつながる可能性があります。 この記事では、AWS Inferentia アクセラレータ（Amazon EC2 Inf1 およびAmazon EC2 Inf2 &nbsp;インスタンスに搭載されています）に&nbsp;FastAPI モデルサーバーをデプロイする流れを説明します。また、ハードウェア効率の最大化を実現するために、すべてのNeuronCore に並列にデプロイされたサンプルモデルのホスティングも示します。 ソリューションの概要 FastAPI は、Flask や Django などの従来のフレームワークよりもはるかに高速な、Python アプリケーションをホストするためのオープンソースの Web フレームワークです。これらは広く使用されている Web Server Gateway Interface (WSGI) ではなく、 Asynchronous Server Gateway Interface (ASGI) を活用することで実現しています。ASGI は、WSGI がリクエストを順次処理するのとは異なり、非同期に処理します。このことから、FastAPI は低レイテンシが要求されるリクエストを処理するのに最適な選択肢となっています。FastAPI を使用することで、指定されたポートを介してクライアントからのリクエストを受け取るサーバーを Inferentia (Inf1/Inf2) インスタンスに デプロイできます。 私たちの目標は、ハードウェアを最大限に活用することで、最低コストで最高のパフォーマンスを達成することです。これにより、より少ないアクセラレーターでより多くの推論要求を処理できます。各 AWS Inferentia1 デバイスには 4 つの NeuronCore-v1 が含まれ、各 AWS Inferentia2 デバイスには 2 つの NeuronCore-v2 が含まれます。 AWS Neuron SDK を使用すると、各 NeuronCore を並列に使用できるため、スループットを犠牲にすることなく、4 つかそれ 以上のモデルを並列にロードおよび推論する際の制御が可能となります。 FastAPI を使用する際には、Python の Web サーバー&nbsp;( Gunicorn 、 Uvicorn 、 Hypercorn 、 Daphne ) の選択肢があります。これらの Web サーバーは、基盤となる機械学習 (ML)&nbsp; モデルの上に抽象化レイヤーを提供します。要求元クライアントは、ホストされたモデルを認識する必要がありません。クライアントは、サーバー下でデプロイされたモデルの名前やバージョンを知る必要はありません。すなわち、エンドポイント名はモデルをロードして実行する関数へのプロキシになります。対照的に、フレームワーク固有のサービングツール、たとえば TensorFlow Serving では、モデルの名前とバージョンがエンドポイント名の一部となります。サーバー側でモデルが変更された場合、クライアントは API 呼び出しを新しいエンドポイントに変更する必要があります。したがって、A/B テストなどの状況でモデルのバージョンを継続的に改善させている場合、FastAPI を備えた汎用 Python Web サーバーを使用すると、エンドポイント名が静的であるため、モデル提供時には便利な方法であるといえます。 ASGI サーバーの役割は、指定された数のワーカーを生成してクライアントからのリクエストを受信し、推論コードを実行することです。サーバーの重要な機能は、要求された数のワーカーが使用可能かつアクティブであることを確認することです。ワーカーが停止された場合、サーバーは新しいワーカーを起動する必要があります。この状況においては、サーバーおよびワーカーは Unix のプロセス ID (PID) によって識別される場合があります。このブログでは、Python Web サーバーとして人気のある Hypercorn サーバを使用します。 このブログでは、AWS Inferentia NeuronCore 上で FastAPI を使用し、深層学習モデルをデプロイするためのベストプラクティスを共有します。ここでは、複数のモデルを個別の NeuronCore にデプロイして、同時に呼び出すことができることを示します。このセットアップにおいては、複数のモデルが同時に推論できるため、スループットが向上し、NeuronCore の使用率が完全に最適化されます。コードは&nbsp; GitHub &nbsp;リポジトリに公開されています 。次の図は、EC2 Inf2 インスタンスに今回のソリューションを構築したアーキテクチャを示しています。 EC2 Inf1 インスタンスタイプでも同じアーキテクチャが適用されますが、4 つのコアがあります。そのためアーキテクチャ図が少し変更されます。 AWS Inferentia NeuronCore NeuronCore を使用するための AWS Neuron が提供するツールについて詳しく見てみましょう。次の表は、各 Inf1 および Inf2 インスタンスタイプに搭載されている NeuronCore の数を示しています。ホスト vCPU とシステムメモリは、すべての利用可能な NeuronCore で共有されます。 Instance Size # Inferentia Accelerators # NeuronCores-v1 vCPUs Memory (GiB) Inf1.xlarge 1 4 4 8 Inf1.2xlarge 1 4 8 16 Inf1.6xlarge 4 16 24 48 Inf1.24xlarge 16 64 96 192 Instance Size # Inferentia Accelerators # NeuronCores-v2 vCPUs Memory (GiB) Inf2.xlarge 1 2 4 32 Inf2.8xlarge 1 2 32 32 Inf2.24xlarge 6 12 96 192 Inf2.48xlarge 12 24 192 384 Inf2 インスタンスは、Inf1 インスタンスの NeuronCore-v1 に比べて新しい NeuronCores-v2 を含んでいます。コアの数は少ないですが、Inf1 インスタンスよりも4倍大きいスループットと10倍小さいレイテンシを提供することができます。Inf2インスタンスは、Generative AI や OPT/GPT 系統の大規模言語モデル、Stable Diffusion や vision transformers などの深層学のワークロードに最適な選択肢となります。 Neuron Runtimeは、Neuron デバイス上でモデルを実行する役割を担っています。Neuron Runtime は、どの NeuronCore がどのモデルをどのように実行するか を 決定します。Neuron Runtime の設定は、プロセスレベルで 環境変数 を使用して制御されます。デフォルトでは、Neuron フレームワーク拡張機能がユーザーの代わりに Neuron Runtime の設定を行います。ただし、より最適化された動作を実現するために、明示的な設定も可能です。 よく使われる環境変数は NEURON_RT_NUM_CORES &nbsp;と NEURON_RT_VISIBLE_CORES &nbsp;です。これらの環境変数を使用すると、Python プロセスを NeuronCore に関連付けることができます。 NEURON_RT_NUM_CORES &nbsp;では、指定された数のコアをプロセスに予約することができ、 NEURON_RT_VISIBLE_CORES &nbsp;では、NeuronCore の範囲を予約することができます。例えば、 NEURON_RT_NUM_CORES=2 myapp.py &nbsp;とすると、 myapp.py &nbsp;に2つのコアが予約され、 NEURON_RT_VISIBLE_CORES='0-2' myapp.py &nbsp;とすると、 myapp.py &nbsp;に0、1、2の3つのコアが予約されます。NeuronCore はデバイス（AWS Inferentia チップ）間でも予約することができます。したがって、 NEURON_RT_VISIBLE_CORES='0-5' myapp.py &nbsp;とすると、EC2 Inf1 インスタンスタイプの device1 の最初の4つのコアと device2 &nbsp;の1つのコアが予約されます。同様に、EC2 Inf2インスタンスタイプでは、この設定により&nbsp; device1 &nbsp;と device2 &nbsp;の2つのコアが予約され、 device3 &nbsp;に1つのコアが予約されます。以下の表はこれらの変数の設定をまとめたものです。 Name Description Type Expected Values Default Value RT Version NEURON_RT_VISIBLE_CORES Range of specific NeuronCores needed by the process Integer range (like 1-3) Any value or range between 0 to Max NeuronCore in the system None 2.0+ NEURON_RT_NUM_CORES Number of NeuronCores required by the process Integer A value from 1 to Max NeuronCore in the system 0, which is interpreted as “all” 2.0+ すべての環境変数の一覧については、 Neuron Runtime Configuration &nbsp; を参照してください。 デフォルトでは、モデルをロードする際に、モデルは明示的に上記の環境変数で指定されていない限り、NeuronCore 0にロードされ、次に NeuronCore 1 にロードされます。先述したように、NeuronCore は利用可能なホスト vCPU とシステムメモリを共有します。したがって、各 NeuronCore に展開されたモデルは利用可能なリソースを競合します。モデルが NeuronCore を大幅に利用している場合は、これは問題になりません。しかし、モデルが NeuronCore の一部をのみ使用し、残りをホスト vCPU で実行している場合は、NeuronCore ごとのCPUの利用可能性を考慮することが重要になります。これはインスタンスの選択にも影響を与えます。 次の表は、各 NeuronCore に 1 つのモデルを展開した場合のホスト vCPU とシステムメモリの数を示しています。アプリケーションの NeuronCore の使用状況、vCPU の使用状況、およびメモリの使用状況に応じて、どの設定がアプリケーションにとって最もパフォーマンスが高いかを確認するためにテストを実行することが推奨されています。 Neuron Top ツール を使用すると、コアの利用状況やデバイスおよびホストメモリの利用状況を視覚化するのに役立ちます。これらのメトリックに基づいて適切な判断を行うことができます。このブログの最後で Neuron Top の使用方法を示します。 Instance Size # Inferentia Accelerators # Models vCPUs/Model Memory/Model (GiB) Inf1.xlarge 1 4 1 2 Inf1.2xlarge 1 4 2 4 Inf1.6xlarge 4 16 1.5 3 Inf1.24xlarge 16 64 1.5 3 Instance Size # Inferentia Accelerators # Models vCPUs/Model Memory/Model (GiB) Inf2.xlarge 1 2 2 8 Inf2.8xlarge 1 2 16 64 Inf2.24xlarge 6 12 8 32 Inf2.48xlarge 12 24 8 32 自分で Neuron SDK の機能をテストしてみるには、最新の PyTorch 向け Neuron 機能 をチェックしてください。 システムセットアップ このソリューションで使用されたシステムのセットアップは以下になります。 インスタンスサイズ – Inf1.6xlarge（Inf1 の場合）、Inf2.xlarge（Inf2 の場合）&nbsp; インスタンス用のイメージ – Deep Learning AMI Neuron PyTorch 1.11.0（Ubuntu 20.04）20230125&nbsp; モデル –&nbsp; https://huggingface.co/twmkn9/bert-base-uncased-squad2 フレームワーク – PyTorch ソリューションのセットアップ ソリューションをセットアップするために必要な手順がいくつかあります。まず、 Amazon Elastic Container Registry &nbsp; からの push と pull を許可する IAM ロールを作成して、EC2 インスタンスがそれを担えるようにします。 ステップ1：IAMロールのセットアップ コンソールにログインして、IAM &gt; ロール &gt; ロールを作成 にアクセスします。 信頼されたエンティティタイプとして AWS のサービス を選択します。 ユースケースとして EC2 をサービスとして選択します。 次へ をクリックすると、利用可能なすべてのポリシーが表示されます。 このソリューションでは、EC2 インスタンスに ECR へのフルアクセスを許可します。 AmazonEC2ContainerRegistryFullAccess をフィルタリングして選択します。 次を押してロールの名前を inf-ecr-access &nbsp;とします。 注意 ：このポリシーのアタッチ&nbsp; EC2 インスタンスは Amazon ECR へのフルアクセスが可能になります。本番環境のワークロードに対しては、 最小特権の原則 に従うことを強く推奨します。 ステップ2：AWS CLI のセットアップ 上記で指定された Deep Learning AMI を使用している場合、AWS CLI がインストールされています。別のAMI（Amazon Linux 2023, Base Ubuntuなど）を使用している場合は、 このガイド に従って CLI ツールをインストールしてください。 CLI ツールがインストールされたら、&nbsp; aws configure &nbsp;コマンドを使用して CLI を設定します。アクセスキーがある場合はここに追加できますが、AWS サービスとのやり取りには必ずしも必要ありません。今回の工程には IAM ロールを使用しています。 注意 ：default プロファイルを作成するために少なくとも1つの値（default region または default format）を入力する必要があります。この例では、region に us-east-2 を、default format に json を設定します。 GitHubリポジトリをクローンする GitHub リポジトリ には、FastAPI を使用して AWS Inferentia インスタンスの NeuronCore 上にモデルを展開するために必要なスクリプトが提供されています。この例では、再利用可能なソリューションを作成するために Docker コンテナを使用しており、ユーザーが入力を提供するための config.properties &nbsp;ファイルが含まれています。 # Docker Image and Container Name docker_image_name_prefix=&lt;Docker image name&gt; docker_container_name_prefix=&lt;Docker container name&gt; # Deployment Setup path_to_traced_models=&lt;Path to traced model&gt; compiled_model=&lt;Compiled model file name&gt; num_cores=&lt;Number of NeuronCores to Deploy a Model Server&gt; num_models_per_server=&lt;Number of Models to Be Loaded Per Server&gt; 設定ファイルには、Docker イメージ と Docker コンテナのためのユーザーが定義するプレフィックスが必要です。 fastapi フォルダと trace-model &nbsp;フォルダの build.sh &nbsp;スクリプトでは、これを使用して Docker イメージを作成します。 AWS Inferentia に向けたモデルコンパイル モデルをトレースして、PyTorch Torchscript の .pt 形式ファイルを生成することから始めます。まず、 trace-model &nbsp;ディレクトリにアクセスして、 .env &nbsp;ファイルを変更します。選択したインスタンスのタイプに応じて、 .env &nbsp;ファイル内の CHIP_TYPE を変更します。例として、Inf2 を選択しますが、同じ手順は Inf1 のデプロイプロセスでも適用されます。 次に、同じファイル内で default region を設定します。この region は ECR リポジトリの作成に使用され、Docker イメージがこのリポジトリにプッシュされます。また、このフォルダには、AWS Inferentia 上で bert-base-uncased &nbsp;モデルをトレースするために必要なすべてのスクリプトが含まれています。このスクリプトは、 Hugging Face で利用可能なほとんどのモデルに使用できます。 Dockerfile には、Neuron でモデルを実行するためのすべての依存関係が含まれており、 trace-model.py&nbsp; コードがエントリーポイントとして実行されます。 Neuron コンパイルについて Neuron SDK の API は、PyTorch の Python API に非常に近いです。PyTorch の torch.jit.trace() &nbsp;は、モデルとサンプルとなる入力テンソルを引数として取ります。サンプル入力はモデルに引き渡され、モデルのレイヤーを通過する際に呼び出される操作が TorchScript として記録されます。PyTorch における JIT トレースについての詳細は、以下の ドキュメント を参照してください。 torch.jit.trace() &nbsp;と同様に、Inf1 の場合は以下のコードを使用して AWS Inferentia 上でモデルをコンパイルできるかどうかを確認できます。 import torch_neuron model_traced = torch.neuron.trace(model, example_inputs, compiler_args = [‘--fast-math’, ‘fp32-cast-matmul’, ‘--neuron-core-pipeline-cores’,’1’], optimizations=[torch_neuron.Optimization.FLOAT32_TO_FLOAT16]) Inf2 の場合、ライブラリは torch_neuronx と呼ばれます。以下は、モデルのコンパイルを Inf2 インスタンスにおいて確認する方法です。 import torch import torch_neuronx model_traced = torch.neuronx.trace(model, example_inputs, compiler_args = [‘--fast-math’, ‘fp32-cast-matmul’, ‘--neuron-core-pipeline-cores’,’1’], optimizations=[torch_neuronx.Optimization.FLOAT32_TO_FLOAT16]) モデルのトレースを行うと、次のようにしてサンプル入力となるテンソルを入力することができます。 answer_logits = model_traced(*example_inputs) 最後に生成された TorchScript をローカルディスクに保存します。 model_traced.save('./compiled-model-bs-{batch_size}.pt') 前述のコードに示されているように、 compiler_args &nbsp;と optimizations &nbsp;を使用しデプロイを最適化することができます。 torch.neuron.trace API の引数の詳細なリストについては、 PyTorch-Neuron trace python API &nbsp;を参照してください。 また、次の重要なポイントに注意して下さい。 Neuron SDK&nbsp;は、この執筆時点では動的なテンソル形状をサポートしていません。したがって、モデルは異なる入力形状に対して別々にコンパイルする必要があります。バケッティングを使用した可変入力形状での推論の実行についての詳細は、 Running inference on variable input shapes with bucketing &nbsp;を参照してください。 モデルをコンパイルする際にメモリ不足の問題に直面した場合、より多くの vCPU やメモリを搭載した AWS Inferentia インスタンスでモデルをコンパイルするか、コンパイルには CPU のみが使用されるため、さらに大きな c6i や r6i インスタンスも使用可能です。一度コンパイルされれば、トレースされたモデルはより小さなサイズの AWS Inferentia インスタンスでも実行できるはずです。 ビルドプロセス build.sh &nbsp;を実行することでコンテナをビルドします。ビルドスクリプトは、ベースとなる Deep Learning Container Image を取得し、HuggingFace の transformers &nbsp;パッケージをインストールし Docker イメージを作成する処理を行います。 .env &nbsp;ファイルで指定された CHIP_TYPE &nbsp;に基づいて、 docker.properties &nbsp;ファイルが適切な BASE_IMAGE &nbsp;を決定します。この BASE_IMAGE は、AWSが提供する Neuron Runtime 用の Deep Learning Container Image を指します。 これらの処理はプライベートな ECR リポジトリを利用します。そのため、イメージを取得する前にログインを行い、一時的なAWSクレデンシャルを取得する必要があります。 aws ecr get-login-password --region &lt;region&gt; | docker login --username AWS --password-stdin 763104351884.dkr.ecr.&lt;region&gt;.amazonaws.com 注意 ： &lt;region&gt; &nbsp;フラグで指定されたコマンドおよびリポジトリ URI 内のリージョンは、 .env &nbsp;ファイルに記載されたリージョンで置き換える必要があります。 このプロセスを簡易に実行するために、 fetch-credentials.sh &nbsp;ファイルを使用することができます。リージョンは自動的に .env &nbsp;ファイルから取得されます。 次に、 push.sh &nbsp;スクリプトを使用してイメージをプッシュします。このスクリプトは Amazon ECR にリポジトリを作成し、コンテナイメージをプッシュします。 最後に、イメージがビルドされてプッシュされたら、 run.sh を実行してコンテナとして実行し、 logs.sh &nbsp;を使用して実行中のログを表示できます。コンパイラのログ（以下のスクリーンショットを参照）では、Neuron でコンパイルされた算術演算子の割合と、モデルサブグラフの割合が表示されます。スクリーンショットは、 bert-base-uncased-squad2 &nbsp;モデルのログを示しています。ログによれば、算術演算子の 95.64% がコンパイルされ、Neuron でコンパイルされた演算子とサポートされていない演算子のリストも示されています。 最新の PyTorch Neuron パッケージでサポートされているすべての演算子のリストは こちら にあります。同様に、最新のPyTorch Neuronx パッケージでサポートされているすべての演算子のリストも こちら です。 FastAPI を使用してモデルをデプロイする モデルがコンパイルされた後、トレースされたモデルは trace-model &nbsp;フォルダに保存されます。この例では、バッチサイズ&nbsp;1&nbsp;としてトレースモデルを配置しています。ここでは、より大きいバッチサイズが実現不可能または必要ないユースケースを考えており、バッチサイズ&nbsp;1&nbsp;を使用しています。より大きいバッチサイズが必要なユースケースでは、 torch.neuron.DataParallel (Inf1 の場合) または torch.neuronx.DataParallel (Inf2 の場合) APIが役立つ場合があります。 fast-api フォルダには、FastAPI を使用してモデルをデプロイするためのすべての必要なスクリプトが含まれています。変更なしでモデルをデプロイするには、単に deploy.sh &nbsp;スクリプトを実行するだけで、FastAPI コンテナイメージがビルド、指定されたコア数でコンテナが実行され、各 FastAPI モデルサーバーで指定された数のモデルがデプロイされます。このフォルダには .env &nbsp;ファイルも含まれており、これを変更して正しい CHIP_TYPE &nbsp;と AWS_DEFAULT_REGION を反映させることができます。 注意 ：FastAPI スクリプトは、イメージのビルド、プッシュ、コンテナとしての実行に使用されるものと同じ環境変数に依存しています。FastAPI デプロイメントスクリプトは、これらの変数からの最後に知られている値を使用します。したがって、もし最後にトレースしたモデルが Inf1 インスタンスタイプの場合、そのモデルがこれらのスクリプトを介してデプロイされます。 fastapi-server.py ファイルは、サーバーのホスティングとモデルへのリクエストの送信を担当しており、以下のことを行います。 プロパティファイルからサーバーごとのモデル数とコンパイルされたモデルの場所を読み取ります。 Docker コンテナに対して利用可能な NeuronCore を環境変数として設定し、どの NeuronCore を使用するかを指定する環境変数を読み取ります。 bert-base-uncased-squad2 &nbsp;モデルの推論 API を提供します。 jit.load() &nbsp;を使用して、設定で指定されたサーバーごとに必要なモデルの数を読み込み、モデルと必要なトークナイザーをグローバルな辞書に格納します。 このセットアップでは、各 NeuronCore に格納されているモデルとその数を一覧表示するAPIを簡単に設定することができます。同様に、特定の NeuronCore からモデルを削除するための API も作成できます。 FastAPI コンテナをビルドするため Dockerfile は、モデルのトレース用にビルドした Docker イメージをベースにして構築されています。これが、 docker.properties &nbsp;ファイルがモデルのトレース用の Docker イメージの ECR パスを指定している理由です。今回のセットアップでは、すべての NeuronCore 上の Docker コンテナは同種のものであり、1つのイメージをビルドし、それから複数のコンテナを実行できます。エントリーポイントのエラーを回避するために、 Dockerfile で ENTRYPOINT&nbsp;["/usr/bin/env"] &nbsp;を指定してから、 hypercorn fastapi-server:app -b 0.0.0.0:8080 &nbsp;というスタートアップシェルスクリプトを実行します。このスタートアップスクリプトはすべてのコンテナで同じです。モデルのトレース用と同じベースイメージを使用している場合、build.sh スクリプトを実行するだけでこのコンテナをビルドできます。 push.sh &nbsp;スクリプトは、モデルのトレース用と同じままです。変更された&nbsp;Docker&nbsp;イメージとコンテナ名は、 docker.properties ファイルで提供されます。 run.sh ファイルは以下の操作を行います。 プロパティファイル から Docker イメージとコンテナ名を読み取ります。このプロパティファイルは、 config.properties &nbsp;ファイルを読み取ります。 config.properties &nbsp;ファイルには num_cores &nbsp;というユーザー設定が含まれています。 0 から num_cores &nbsp;までのループを開始し、各コアごとに以下を実行します。 &nbsp;ポート番号とデバイス番号を設定します。 NEURON_RT_VISIBLE_CORES &nbsp;を設定します。 ボリュームマウントを指定します。 Docker コンテナを実行します。 NeuronCore 0 で Inf1 用に展開するための Docker 実行コマンドは次のようになります。 docker run -t -d \ --name $ bert-inf-fastapi-nc-0 \ --env NEURON_RT_VISIBLE_CORES="0-0" \ --env CHIP_TYPE="inf1" \ -p ${port_num}:8080 --device=/dev/neuron0 ${registry}/ bert-inf-fastapi NeuronCore 5 で展開するための実行コマンドは次のようになります。 docker run -t -d \ --name $ bert-inf-fastapi-nc-5 \ --env NEURON_RT_VISIBLE_CORES="5-5" \ --env CHIP_TYPE="inf1" \ -p ${port_num}:8080 --device=/dev/neuron0 ${registry}/ bert-inf-fastapi コンテナが展開された後、 run_apis.py スクリプトを使用して、API を並列スレッドで呼び出します。コードは、各 NeuronCore に1つずつ展開された6つのモデルを呼び出すように設定されていますが、簡単に異なる設定に変更できます。クライアント側から API を呼び出す方法は以下の通りです。 import requests url_template = http://localhost:%i/predictions_neuron_core_%i/model_%i # NeuronCore 0 response = requests.get(url_template % (8081,0,0)) # NeuronCore 5 response = requests.get(url_template % (8086,5,0)) NeuronCore の監視 モデルサーバーが展開された後、NeuronCore の利用状況を監視するために、 neuron-top を使用して各 NeuronCore の利用率をリアルタイムで観測することができます。 neuron-top は、Neuron SDK 内の CLI ツールで、NeuronCore、vCPU、メモリの利用状況などの情報を提供します。別のターミナルで、次のコマンドを入力します。 neuron-top このコマンドによって、下の画像のような出力が得られます。このシナリオでは、Inf2.xlarge インスタンスでサーバーごとに2つの NeuronCore と 2 つのモデルを使用するように指定しています。以下のスクリーンショットでは、2 つのサイズが 287.8 MB のモデルが 2 つの NeuronCore にロードされていることが表示されています。合計 4 つのモデルがロードされているため、使用されているデバイスメモリは 1.3 GB です。矢印キーを使用して異なるデバイスの NeuronCore 間を移動できます。 同様に、Inf1.6xlarge インスタンスタイプでは、合計 12 のモデル（ 1 つのコアあたり 2 つのモデル、6 つのコア合計）がロードされていることが表示されます。合計 2.1 GB のメモリが消費され、各モデルのサイズは 177.2 MB です。 run_apis.py スクリプトを実行した後、各 NeuronCore の利用率の割合を確認できます（以下のスクリーンショットを参照）。また、システムの vCPU 使用率とランタイムの vCPU 使用率も確認できます。 以下のスクリーンショットは、Inf2 インスタンスのコア使用率の割合を示しています。 同様に、このスクリーンショットは、Inf1.6xlarge インスタンスタイプにおけるコアの利用率を示しています。 クリーンアップ 作成したすべての Docker コンテナをクリーンアップするために、すべての実行中および停止したコンテナを削除する cleanup.sh &nbsp;スクリプトを提供しています。このスクリプトはすべてのコンテナを削除しますので、実行中の一部のコンテナを保持したい場合には使用しないでください。 結論 プロダクションのワークロードはしばしば高いスループット、低レイテンシ、コストの要件を持っています。アクセラレータを最適でない方法で使用する非効率なアーキテクチャでは、不必要に高いコストにつながる可能性があります。この記事では、 FastAPI と NeuronCore を最適に活用し、スループットを最大化しながら最小のレイテンシで動作すること方法を示しました。詳しくは&nbsp; GitHubのリポジトリ に手順を公開しています。このソリューションを使用すると、各 NeuronCore に複数のモデルを展開し、異なる NeuronCore 上で複数のモデルを並列に運用することができ、パフォーマンスを損なうことなく行えます。 Amazon Elastic Kubernetes Service （Amazon EKS）などのサービスを使用してモデルをスケールで展開する方法については、「 AWS Inferentiaを使用して Amazon EKS で 3,000種類のディープラーニングモデルを 1 時間あたり 50 USD 以下で提供 」の記事を参照してください。 翻訳はソリューションアーキテクトの松崎が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 4 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明しました。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明しました。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに このブログ記事は、Windows Server のサポート終了への対応ブログシリーズの第 4 部です。この最後のブログ記事では、AWS Application Migration Service (AWS MGN) を使用して Windows Server のインプレースアップグレードを実行する方法について説明します。早速見ていきましょう。 AWS MGN を使用した Windows Server のインプレースアップグレードの実行 お使いの Windows 2012 または Windows 2012 R2 サーバーがまだオンプレミス環境で実行されている場合は、それらのサーバーを AWS MGN を使用して AWS に移行できます。移行の最後にサーバーを新しいバージョンの Windows にアップグレードするように AWS MGN を設定できます。AWS MGN を設定する手順については、この ブログ記事 (訳註：日本語でのAWS MGN 解説動画) をお読みください。AWS MGN で移行する手順を理解できます。 前提条件 1. AWS Identity and Access Management ( IAM ) ロール Windows Server のアップグレードを実行するための AWS MGN で移行後のテンプレートを準備する前に、以下のアクセス権限ポリシーを含む IAM ロール (図 1 参照) を作成する必要があります。 AmazonSSMManagedInstanceCore AWSApplicationMigrationFullAccess 図 1. ロールと権限を含む IAM 権限 2. サブネット ID 移行したインスタンスを実行するサブネット ID を書き留めておきます。サブネット ID は、AWS マネジメントコンソールの Amazon Virtual Private Cloud (Amazon VPC) サービス (図 2 参照) の [サブネット] にあります。 図 2. Amazon VPC とサブネット ID の選択 AWS MGN コンフィギュレーション AWS MGN では、Amazon Elastic Compute Cloud (Amazon EC2) の起動インスタンスで、あらかじめ定義されたさまざまな起動後のアクションを実行できます。組み込みの起動後テンプレートのいずれかを使用して、Windows Server のインプレースアップグレードを実行します。 このステップを開始するときは、ソースサーバーへの AWS MGN エージェントのインストールが既に完了していて、MGN コンソールに表示されている前提とします。 注意： この方法を使用して Windows Server 2008 R2 をアップグレードすることもできます。Windows Server 2008 R2 インスタンスを Windows Server 2016、2019、または 2022 にアップグレードするには、インプレースアップグレードを 2 回実行します。1 回目は Windows Server 2008 R2 から Windows Server 2012 R2 へ、その次は Windows Server 2012 R2 から Windows Server 2016、2019、または 2022 へのインプレースアップグレードです。 Windows Server 2008 R2 を Windows Server 2016、2019、または 2022 に直接アップグレードすることはサポートされていません。 &nbsp;AWS MGN で、 [ソースサーバー] に移動します (図 3 参照)。Windows アップグレードを実行するサーバーをクリックします。 図 3. Application Migration Service のアクティブソースサーバーページ &nbsp;[起動後設定] を選択します (図 4 参照)。 図 4 Application Migration Service ダッシュボード &nbsp; [起動後のアクションをアクティブ化する] が [はい] に設定されていることを確認します。それ以外の場合は、 [編集] をクリックします。 図 5. Application Migration Serviceの起動後のアクション &nbsp; [起動後設定の編集] (図 5 参照) で、 [Systems Manager エージェントをインストールし、起動したサーバーでのアクションの実行を許可する] を有効にします (図 6 参照)。 &nbsp; [テストインスタンスとカットオーバーインスタンス (推奨)] を選択し、 [設定を保存] を選択します (図 6 参照)。 図 6. 起動後のアクションの詳細とデプロイ &nbsp; [Windows upgrade] を選択し、 [編集] をクリックします (図 7 を参照)。 図 7. 起動後アクションの設定ページ &nbsp; [アクションの編集] で、 [このアクションをアクティブ化する] をオンにします (図 8 参照)。 図 8. 起動後のアクションページでのアクションの編集 次の情報を入力します (図 9 参照)。 IamInstanceProfile : 前提条件ステップ 1 で作成したプロファイル SubnetId : サーバーをデプロイしたいサブネットを設定します。前提条件セクションのステップ 2 を参照してください TargetWindowVersion : アップグレードしたい Windows バージョンを選択します。 KeepPreUpgradeImageBackUp : 今回の手順では False 設定します。条件に応じて、設定してください。 RebootInstanceBeforeTakingImage : 今回の手順では False 設定します。条件に応じて、設定してください。 入力後、アクションを保存します。 図 9. アップグレード前のイメージを変更しないようにするためのアクションパラメータとオプション 最終的に、起動後の設定に「SSM agent」と「Windows upgrade」の 2 つのアクションが表示されます (図 10 参照)。 図 10. 起動後の設定ページでの SSM Agent と Windows アップグレードの選択 &nbsp;AWS MGN でカットオーバーを行うと、ステップ 9 で設定した 2 つの起動後のアクションによって SSM Agent のインストールと、新しいバージョンの Windows OS へのインプレースアップグレードが実行されます (図 11 参照)。 図 11. Application Migration Service のアクティブなソースサーバーのカットオーバーページ 起動後のアクションは、移行ダッシュボードの [起動後のアクション] でモニタリングできます (図 12 参照)。 図 12. 移行のモニタリング カットオーバーが正常に完了すると、Amazon EC2 コンソールに新しい Windows Server 2019 が表示されるはずです (図 13 参照)。 図 13. EC2 コンソールでの移行完了の検証 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。 まとめ このブログ記事では、AWS Application Migration Service を使用した Windows Server のアップグレード方法について説明しました。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部 : AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 3 部 : AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法&nbsp; 最後に、 この電子書籍 を読んで、NextGen Healthcare、Parsons Corporation、SeatGeek、アーカンソー州裁判所管理局などの組織が AWS を使用して Windows Server ワークロードを移行、最適化、およびモダナイズする方法を参考にしてください。 アップグレードについてご支援が必要な場合は、 こちら から AWS にお問い合わせください。お客様の EOS の状況やニーズへの対応を支援いたします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 Kyaw Soe Hlaing Kyaw Soe Hlaing は、インフラストラクチャ、プラットフォーム、ID 管理を専門とするシニアソリューションアーキテクトです。顧客の複雑なビジネス要件に対応するソリューションの提供やアーキテクチャ設計に情熱を注いでいます。15 年以上の経験を持つ Kyaw は、パートナーと協力して AWS のお客様がクラウド変革の道のりを進めるために支援しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 3 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明しました。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに Windows Server のサポート終了 (End of Support、EOS) への対応ブログシリーズの第 3 部へようこそ。Windows コンテナを使用した EOS のモダナイゼーション方法について順を追って説明します。 早速見ていきましょう。 レガシーな ASP.NET Web アプリケーションを Windows コンテナにリプラットフォーム お客様の EOS の課題解決を支援する中で、レガシーアプリケーションやモノリシックアプリケーションの管理を容易にする目的で Windows コンテナを使用する案件が増えているようです (図 1 を参照) 。ASP.NET Web アプリケーションでは、Windows コンテナが最適な実行方法です。コンテナはもともとポータブルで、スケーラブルで、信頼性があります。ASP.NET Web アプリケーションを Windows コンテナで実行することで、ソースコードの再設計やリファクタリングについて心配する必要がなくなります。EOS となるWindows OS に対応すること以外にも、Windows コンテナにリプラットフォームすることでアプリケーションのモダナイズを開始 (または継続) できます。 図 1. マイグレーションとモダナイゼーションのアプローチ：リホスト、リプラットフォーム、リファクタリング App2Container による.NET Framework アプリケーションのモダナイゼーション 前提条件 これらの前提条件の詳細については、 こちら のドキュメントをご覧ください。 アプリケーションに、新しいOSへの移行を妨げるような、OSとの依存関係や Windows API (例：COM 相互運用) が使われていないか確認します。 組織の要件に基づいてターゲット Windows OS を設定します。 注意 ： Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Kubernetes Service (Amazon EKS) は、Windows コンテナを実行するためにサポートされている 2 つのオーケストレーションプラットフォームです。Windows Server 2022 にアップグレードすることをお勧めしますが、一般的なコンピューティングオプションでは Windows Server 2019 と 2022 がサポートされます。Windows Server 2016 は ECS の Amazon Elastic Cloud Compute (Amazon EC2) 起動タイプでのみサポートされています。 アプリケーションが App2Container (A2C) でサポート されていることを確認してください。 どのオーケストレーションプラットフォームを使用するか決めてください。Amazon ECS と Amazon EKS は Windows コンテナと App2Container の成果物をサポートしているプラットフォームです。 オプションで、 Amazon Simple Storage Service (Amazon S3) バケットを指定すると成果物をバケットに出力することができます。 また、アプリケーションが完全に機能するテスト環境をセットアップして、App2Container CLI ツールでアプリケーションをターゲットにすることができます。セットアップしない場合は、アプリケーションの成果物は App2Container を実行しているサーバーのローカルに保存されます。 手順に従って、移行先の OS バージョン (Windows Server 2019 または 2022) を実行し、移行元のWindow Server 2012 のアプリケーションサーバーからアプリケーションの成果物を抽出するリモートワーカーマシンをセットアップします。 手順については、「 Modernize with AWS App2Container Workshop 」をご覧ください。その結果、図 2 に示すように、.NET ウェブアプリケーションを AWS でモダナイズします。 図 2. .NET の AWS へのモダナイゼーションの例 アプリケーションを発見して分析する。 アプリケーションサーバー上で実行されているすべてのインターネット インフォメーション サーバー (IIS) の Web サイトと Windows サービスを記録する App2Container の分析コマンドを実行します。 分析出力ファイルを確認し、必要に応じて、コンテナのベースイメージを所望の移行先 OS になるように調整します。(例：mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022 — .NET Framework 4.8 Windows Server Core 2022 イメージ)。これは IIS と OS の構成の分析に基づいて自動的に設定されるはずです。 アプリケーションを抽出してコンテナ化する。 リモートワーカーマシンで extract コマンド を実行して、指定したアプリケーションのアプリケーションアーカイブを生成します。このアーカイブをワーカーマシンにコピーするか、Amazon S3 プレフィックスを指定することができます。 containerize コマンド を実行して Dockerfile を作成します。 コンテナ化されたアプリケーションをデプロイする。 Amazon ECS または Amazon EKS のアーティファクトを含むようにデプロイ設定を調整してください。次に、アプリケーションデプロイを実行してコンテナイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュし、アプリケーションを Amazon ECS または Amazon EKS にデプロイします。 アプリケーションが正常にコンテナ化され、パブリックアクセス向けに保護されたら、本番環境へのデプロイを計画する準備が整います。App2Containerは、アプリケーションのデプロイを容易にする継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの作成をサポートします。App2Container は、CodePipeline、Jenkins、Microsoft Azure DevOps など、いくつかの CI/CD ツールをサポート しています。App2Container を使用した CI/CD パイプラインの段階的なデプロイについては、ブログ記事「 AWS App2Container を使用してコンテナ化された ASP.NET アプリケーション用の CI/CD パイプラインの生成 (英文) 」を参照してください。 本番環境にプッシュする。 Windows Server 2012 で実行されているレガシーアプリケーションから、デプロイしたコンテナ化されたアプリケーションの前段にある新しいロードバランサーへのパブリック URL のカットオーバーを計画します。 アプリケーションに OS の依存関係がない場合は、最新の Windows OS を使用して新しいビルドサーバーをデプロイし、アプリの Dockerfile の FROM 行を変更し (図 3 参照)、新しいコンテナイメージを構築し (図 4 参照)、 ローリング更新 を行うだけで、今後の OS バージョンのアップグレードは簡単にできます。 注意：本番環境に実装する前に、基盤となるOSに大幅な変更がないことを確認するための適切なテストが必要です。 EOS OS: 図 3. EOS OS コンテナベースイメージ New OS: 図 4. Dockerfile の新しい OS コンテナベースイメージ App2Container の使用手順を詳しく理解するには、 App2Container の公開ドキュメント を参照してください。Amazon Relational Database Service (Amazon RDS) for SQL Server にデータベースを移行するユースケースをさらに詳しく知りたい場合は、 AWS App2Container によるモダナイズワークショップ を参照してください。 リファクタリング — .NET Framework&nbsp;を最新バージョンの .NET へ 組織で.NET Framework コードを最新バージョンの .NET にリファクタリングする準備ができている場合は、 Porting Assistant for .NET と AWS Toolkit for .NET Refactoring を利用できます。.NET 6 もしくはそれ以降のバージョンに移行することで、.NET コードを Linux コンテナで実行できるようになります。 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。アップグレードの進め方をステップバイステップの手順で示しています。 まとめ このブログ記事では、AWS App2Container を活用して .NET ウェブアプリケーションをアップグレードおよびモダナイズする方法について説明しました。このブログシリーズの次のブログ記事では、AWS Application Migration Service を使用して Windows OS をアップグレードする方法を紹介します。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部 : AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 4 部 : AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 アップグレードについてご支援が必要な場合は、 こちら から AWS にお問い合わせください。お客様の EOS の状況やニーズへの対応を支援いたします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Bill Pfeiffer Bill Pfeiffer は、アマゾン ウェブ サービスのシニアソリューションアーキテクトです。Bill は、お客様が安全でコストを最適化したインフラストラクチャを設計、実装、発展できるよう支援することを主な活動としています。Bill は、お客様がビジネス上の課題を技術的ソリューションで解決できるよう支援することに情熱を注いでいます。仕事以外では、ビルは家族と一緒にRV車に乗ってアメリカを旅行したり、ウルトラマラソン距離のスパルタンレースに出場したりすることを楽しんでいます。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 2 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明します。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 概要 AWS Systems Manager は、既存のインスタンスを最新バージョンの Windows Server にアップグレードするために利用できる選択肢の 1 つです。このブログ記事では、AWS Systems Manager を使用して Windows Server のインプレースアップグレードプロセスを自動化する方法を紹介します (図 1 参照)。このオプションの詳細を説明したビデオを公開しました。 AWS Online Tech Talks チャンネル にアクセスして (まだ登録していない場合は [チャンネル登録] をクリックしてください)、「 Navigate the Windows Server end of support challenge with AWS 」をチェックしてください。ソリューションが実際に動作していることを確認するには、 34:36 に早送りすることをお勧めします。 図 1. AWS SSM を使用したアップグレードプロセス 前提条件 注意 :この自動化プロセスは Windows Server 2008 R2、2012 R2、2016、2019 でのみ機能します。Windows Server 2008 R2 では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが最初に Windows Server 2012 にアップグレードされ、次に Windows Server 2016 または 2019 にアップグレードされます。 このアップグレードを完了するには、次の前提条件を満たす必要があります。 アップグレードが必要な Amazon EC2 インスタンス アップグレードする予定のインスタンスに SSM エージェントがインストールされ、動作している この自動化をインスタンスで機能させるために、TLS 1.2を有効にする アップグレードを正常に実行するために、ルートに少なくとも 20 GB の空き容量がある インスタンスが既存の Active Directory ドメインに参加している場合は、ホスト名の競合を避けるため、Active Directory に接続できないサブネット ID を指定することを推奨 「 パブリック IPv4 アドレスの自動割り当て 」が TRUE に設定されたパブリックサブネット。これは大きなブロッカーになる可能性があります。その場合は、このブログシリーズの第 1 部で説明した方法を使用してアップグレードすることを検討してください。 Amazon EC2 インスタンスが SSM と通信し、お客様に代わってアップグレードプロセスを実行できるようにする AWS Identity and Access Management (IAM) ロール。必要なロールを作成する方法については、 IAM ドキュメント を参照してください。 注意:この記事で説明されている自動化プロセスは、Windows Server 2008 R2、2012 R2、2016、および 2019 でのみ機能します。これを Windows Server 2008 R2 で実行する場合、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは最初に Windows Server 2012 にアップグレードされ、次に Windows Server 2016 または 2019 にアップグレードされます。また、自動化ドキュメントでは Windows Server のライセンス版や Bring Your Own License (BYOL) 版をアップグレードすることもできますが、BYOL を扱う際には追加の手順が必要であることを忘れないでください。詳細は こちらのドキュメント に記載されています。 制限事項 この自動化方法では、Windows ドメインコントローラー、クラスタ、または Windows デスクトップオペレーティングシステムのアップグレードはサポートされていません。さらに、以下のロールがインストールされている Windows Server 用の Amazon EC2 インスタンスはサポートされていません。 リモート デスクトップ セッション ホスト (RDSH) リモート デスクトップ接続ブローカー (RDCB) リモート デスクトップ仮想化ホスト (RDVH) リモート デスクトップ Web アクセス (RDWA) サポートされているアップグレードパス AWS Systems Manager オートメーションランブック AWSEC2-CloneInstanceAndUpgradeWindows では、以下のアップグレードパスをサポートしています。 Windows Server 2008 R2 から Windows Server 2012 R2 へ、Windows Server 2019 または 2022 へ Windows Server 2012 と 2012 R2 から Windows Server 2016 へ Windows Server 2012 R2 から Windows Server 2019 へ Windows Server 2016 から Windows Server 2019 へ Windows Server 2016 から Windows Server 2022 へ Windows Server 2019 から Windows Server 2022 へ Windows Server インスタンスのアップグレード オートメーションを使用してこのアップグレードを完了する手順を詳しく説明します。オートメーションに必要ないくつかの情報を記録するために、メモなどご用意ください。 OS のアップグレードを進める前に、次の点に注意しましょう。後で必要になります。 &nbsp; AWS マネジメントコンソール で、Windows 2012 のインスタンス ID を取得します (図 2 参照)。 図 2. AWS コンソールの Windows 2012 EC2 インスタンス EC2 インスタンスのネットワークプロパティを見て、パブリック サブネットID を書き留めておきます。 図 3. EC2 インスタンスのネットワークプロパティ AWS Identity IAM コンソールで、SSM にアクセス可能な作成した IAM ロールを選択します (図 4 参照)。以下は、ロールにアタッチする必要があり、インスタンスに関連付けられているポリシー名です。 図 4. IAM コンソールの SSM ポリシー 最後に、インスタンスのパスワードを入力します。 それでは、Windows Server 2012 インスタンスに RDP を実行してみましょう。図 5 に示すように、Windows Server 2012 R2 マシンには、いくつかのアプリケーションがデスクトップにロードされ、システムにインストールされています。アップグレードプロセスが完了したら、これを参考にします。 図 5. RDP セッションの Windows 2012 Windows Server 2012&nbsp;R2 をアップグレードする準備ができました! AWS Systems Manager コンソールを開き、 [変更管理] セクションにある [オートメーション] (図 6 参照) を選択します。 図 6. AWS コンソールでの AWS Systems Manager Automation [オートメーションの実行] を選択します (図 7 参照)。 図 7. AWS コンソールでのオートメーションの実行 検索フィールドに 「clone」と入力してフィルターを作成します。一連のオートメーションドキュメントが表示されます (図 8 参照)。 「 AWSEC2-CloneInstanceAndUpgradeWindows 」という名前のドキュメントを選択します (図 8 に表示)。 図 8. AWS コンソールのオートメーションドキュメント ドキュメントを読み込んだら、 [オートメーションを実行する] を選択します (図 9 参照)。 図 9. AWS コンソールでのオートメーションの実行 次の画面で、アップグレードするインスタンスを選択します (図 10 参照)。インスタンスにわかりやすい名前がある場合は、その名前を使用してください。そうでない場合は、事前に取得したインスタンス ID を入力します。 図 10. AWS Systems Manager コンソールで EC2 インスタンスを選択 ドロップダウンメニューを使用して、以前に収集した情報を入力します (図 11 を参照)。 – IamInstanceProfile – SubnetId – TargetWindowVersion アップグレードしようとしているインスタンスが BYOL オプションを使用している場合は、「BYOLWindowsMediaSnapshotId」フィールドに Windows Server 2012 R2 インストールメディアの EBS ボリュームのスナップショット ID を入力する必要があります。このセクションを完了したら、ページの下部に移動して [実行] を選択します (図 11 参照)。 図 11. アップグレードパラメータの指定 この時点で、正しいオプションを選択すると、図 12 に示すように [実行の詳細] ページが表示されます。プロセス全体が完了するまでに2時間以上かかる場合がありますのでご注意ください。Windows Server 2008 R2 の場合、自動化によって最初にインスタンスが Windows Server 2012 R2 にアップグレードされ、続いて選択した Windows Server のターゲットバージョンがアップグレードされます。 図 12. システムマネージャーの実行詳細 イメージの作成が完了したので、Amazon EC2 コンソールに移動しましょう (図 13 参照)。左側のペインの [イメージ] で、 [AMI] を選択します。次に、 自己所有 の AMI を選択していることを確認してください。リストにはいくつかの AMI があるかもしれません。オートメーションを起動したときの作成日を確認してください。もう 1 つの手がかりは、 AMI 名: upgraded という属性を使用して検索することです。AMI を見つけたら、 [AMI からインスタンスを起動] を選択します。 図 13. EC2 コンソールに表示される AMI 図 14 に示すように、 [インスタンスを起動] 画面が開きます。起動するインスタンスタイプを選択します。これは、使用状況のメトリクスに基づいてインスタンスを適切なサイズにする機会です。インスタンスをデプロイする正しい VPC とそのサブネットを必ず選択してください。 注意 : Windows Server 2012 R2 システムを複製したときには、必ず元の Windows 2012 R2 システムから取得したパスワードを使用してください。キーペアは、必要に応じて後で新しいインスタンスに追加できます。完了したら、 [インスタンスを起動] を選択します。すべてが正常に完了すると、次の画面が表示されます (図 15 参照)。 図 14. アップグレードされたインスタンスの起動開始 すべてが正常に完了すると、次の画面が表示されます (図 15 参照)。 図 15. 新しいインスタンスの起動が正常に開始 新しくアップグレードしたインスタンスにアクセスできることを確認し、プロセスの前半でコピーした元のパスワードを使用してリモートデスクトッププロトコル (RDP) 経由で接続します。 Amazon EC2 コンソールで、新しくアップグレードしたインスタンスを選択し、 [接続] を選択します (図 16 を参照)。 図 16. AWS コンソールでアップグレードされた EC2 インスタンス [インスタンスに接続] ウィンドウ (図 17 参照) の [RDP クライアント] タブでは、RDP クライアントを使用してサーバーに接続するためのインスタンスのパブリック DNS 名を取得できます。 図 17. アップグレードしたインスタンスに RDP で接続 ログインすると、図 18 に示すように、サーバー上にアプリケーションが表示されます。この場合では、Windows Server 2012 R2 システムにあったアプリケーションと同じものなります。 図 18. RDP で接続したアップグレードされたインスタンス おめでとうございます。これで、 サーバーが Windows Server 2012 R2 から Windows Server 2019 に自動的にアップグレードされました! システムを本番環境に戻す前に、アプリケーションの機能を検証して検証し、互換性の問題がないことを確認する必要があることに注意してください。 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。ステップバイステップのアプローチでは、アップグレードを自動化する方法を正確に示しています。 まとめ このブログ記事では、AWS Systems Manager を使用して Windows Server 2012 を自動的にアップグレードする方法について、手順を追って説明しました。この方法は、より大規模で複雑な環境に最も適用できると考えています。 これは EOS に対処するために利用できる多くの選択肢のうちの 1 つであり、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部: AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 3 部: AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法 第 4 部: AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 この記事で紹介した方法を確認するために AWS の支援を希望される場合は、 こちら からお問い合わせください。AWS は喜んでお客様とお客様のチームと面談し、お客様の EOS 状況に対処するための最適な選択肢を検討します。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 Kyaw Soe Hlaing Kyaw Soe Hlaing は、インフラストラクチャ、プラットフォーム、ID 管理を専門とするシニアソリューションアーキテクトです。顧客の複雑なビジネス要件に対応するソリューションの提供やアーキテクチャ設計に情熱を注いでいます。15 年以上の経験を持つ Kyaw は、パートナーと協力して AWS のお客様がクラウド変革の道のりを進めるために支援しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 1 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。第 1 部では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明します。第 2 部では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明します。 第 3 部では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。第 4 部では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに Windows Server のサポート終了 (End of Support、EOS) の課題への対応に関する 4 部構成のブログシリーズの第 1 回へようこそ。このブログ記事では、まず EOS を取り巻く課題について説明し、次に AWS 上の Microsoft Windows Server 2012 R2 を Windows Server 2019 に手動でアップグレードする手順について説明します。 概要 Microsoft が 2023年10月10日に Windows Server 2012 のサポートを終了するため、多くの IT 関係者は、このイベントの準備が整っていないか、どのように進めるべきかわからない状態にあります。心配する必要はありません。ソフトウェアのアップグレードにはいくつかの選択肢があります。ただし、それらの選択肢がチームにとってどのように有効なのか理解するのは難しい場合があります。 Microsoft は、他のオペレーティングシステム（OS）やソフトウェアベンダーと同様に、自社製品の EOS の日程を定期的に発表しています。通常、リリースから10〜12年後です。最近の例としては、2020年1月に EOS となった Windows Server 2008 と 2008 R2 のほか、2022年7月に EOS となった SQL Server 2012 や 2012 R2 などのデータベースがあります。このブログでは、2023年10月10日に EOS となる予定の Windows Server 2012 と 2012 R2 を対象としています。 アマゾン ウェブ サービス (AWS) には、これら 2 つのオペレーティングシステムを使用する多くのお客様がいます。これから説明する方法とアプローチのいくつかは、一般的な EOS の懸念事項にも当てはまります。また、更新が必要な難しいアプリケーションに関して懸念がある場合でも、AWS が支援します（このブログ記事の後半の EMP セクションを参照してください）。 このブログ記事では、EOS に関する技術的な問題点と、AWS 上の Windows Server 2012 を手動でアップグレードする手順について説明します。このシリーズの他の記事では、アップグレードに関するその他の選択肢を紹介します。Windows Server 2012 EOS の問題をビジネスの観点からさらに詳しく見るには、次の記事をご覧ください。 Microsoft Windows Server 2012 のサポート終了に関する AWS オプションを知ろう（英文） 。 EOS の課題 最も明らかな課題は、EOS の期限を過ぎてもソフトウェアを使い続けると、セキュリティアップデート、セキュリティ以外のアップデート、バグ修正、テクニカルサポート、オンラインテクニカルコンテンツのアップデートを受けられなくなることです。唯一の例外は、お客様がソフトウェアプロバイダーから拡張セキュリティ更新プログラムを購入した場合です。しかし、このタイプの購入は（過去でも現在でも）大きな懸念には対処せず、問題を将来に先延ばしにしているだけです。 より多くのお金を使わざるを得なくなる可能性もあります。 その他の技術的問題には次のようなものがあります。 OS をアップグレードできない : 新しいバージョンの Windows Server とアプリケーションの互換性がないため、お客様は OS をアップグレードできません。 アプリケーションの非互換性 : 上記の点と同様に、EOS オペレーティングシステムで実行されている一部のアプリケーションはアップグレードできません。 知識や選択肢の欠如 : 多くのITプロフェッショナルは、EOS の問題に取り組むためにどのようなツールが利用できるかを知らないかもしれません。 セキュリティとコンプライアンスに関する懸念 : 多くの規制環境では、アプリケーションとオペレーティングシステムを最新の状態に保つ必要があります。パッチを適用できない古いオペレーティングシステムは、マルウェア、ランサムウェア攻撃、セキュリティ侵害に対して脆弱なままです。 EOS の問題に対処するための人材や資金の不足 : 多くの場合、EOS の日程はIT部門の主な関心事ではなく、優先リストの下位に押し下げられています。 一部のソリューションはコストがかかりすぎる : 一部の延長サポート製品、ソリューション、オファーは、IT部門にとって書類上は見栄えが良いものの、多くの場合、費用がかかり、タイムリーに採用されないことがあります。 新機能やイノベーションの欠如 : 古いオペレーティングシステムには、現在のソフトウェアに期待されるような新機能がありません。 EOS の重要な技術的課題がいくつか明らかになったところで、AWS がそれらの課題への対応にどのように役立つかを見てみましょう。今日のビジネス環境では、何もしないという選択肢はありません。 EOS に対する AWS の技術的ソリューション AWS とそのパートナーは、専用のプログラム、ツール、技術支援により、お客様の Windows Server ワークロードの移行、アップグレード、モダナイズを支援することに重点を置いています。環境を評価や、Microsoft のライセンスオプションの見直しを行う際には、AWS を頼りにして、全体を通してサポートすることができます。 次のセクションでは、Windows Server 2012 R2 の手動アップグレードプロセスについて説明します。この方法、および関連するブログ記事シリーズに記載されている方法は、Windows 2008 R2などの古い EOS オペレーティングシステムにも適用できることに注意してください。サポートされている Windows Server のアップグレードの概要については、 こちら をご覧ください。 始める前に、テストを行って、アップグレードした OS で実行されているアプリケーションが完全に機能することを確認することが重要です (このブログ記事やシリーズでは説明はしません) 。 前提条件 以前、「 Amazon EC2 Windows Server インスタンス の OS を新しいバージョンにアップグレードする方法を教えてください 」というタイトルのブログ記事を公開しました。 その記事では、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサーバー移行を完了する方法についてのガイダンスを共有しました。このブログ記事は、このアップグレードに伴う参考資料となります。 アップグレードを開始する前に、 Amazon マシンイメージ (AMI) を作成するか、 Amazon Elastic Block Storage (EBS) ボリュームのスナップショットを作成します。このステップは、アップグレードプロセス中に問題が発生した場合の保護をさらに強化します。この方法をテストする前に、必ずバックアップを取っておくことをお勧めします。 Windows 用 EC2 ユーザーガイド では、パブリックインストールメディアを使用してインプレースアップグレードを実行することを推奨しています。BYOL バージョンの Windows Server をアップグレードする予定がある場合は、 独自のインストールメディアを作成する必要があること に注意してください。この ビデオ では、Windows Server 2012 R2 を実行している t2.large EC2 インスタンスをアップグレードする方法を示しています。インスタンスがいつデプロイされたかによって、開始前に実行する必要のある追加の手順があります。これには次のようなものがあります。 AWS マネジメントコンソール から、アップグレードする Windows Server のインスタンス ID を収集します。これは後で必要になります。 &nbsp;10 GB 以上の空きディスク容量があることを確認してください。 ユーザーガイドのリスト と比較して、インスタンスに最新の準仮想化 (PV) ドライバーがインストールされていることを確認してください。 古い世代のシステムには EC2ConfigService がインストールされている可能性があります。これは削除して、新しい EC2Launch サービスに置き換える必要があります。 Amazon Systems Manager (SSM) エージェント がインスタンスにもインストールされていることを確認してください。これにより、追加の自動化を実行し、今後インスタンスを管理できるようになります。 図 1 に示すように、Amazon EC2 コンソールにアクセスします。 [Elastic Block Store] セクションにある [スナップショット] を選択します。ドロップダウンで、 パブリックスナップショット を選択します。 図 1.「スナップショット」のリストを表示する Amazon EC2 コンソール 検索 (図 2 参照)に、「所有者エイリアス =「amazon」、説明:「Windows 2019 English Installation Media」というフィルターを含めます。 図 2. Amazon EC2 コンソールで Windows 2019 English Installation Media のフィルタを設定 図 3 に示すように、スナップショットを選択して確認します。次に [アクション] をクリックし、ドロップダウンから [スナップショットからボリュームを作成] を選択します。 図 3. Amazon EC2 コンソールでスナップショットリストと「スナップショットからボリュームを作成」アクションの表示 ボリュームを作成するときは (図 4 を参照)、インスタンスが配置されている正しいアベイラビリティーゾーンを選択し、最後までスクロールして、 [ボリュームの作成] を選択します。 図 4. ボリューム設定メニュー、インスタンスが正しいアベイラビリティーゾーンにあることを確認する方法、「ボリュームを作成」アクション ボリュームを作成したら、そのボリュームを選択して詳細を表示し、インスタンスにアタッチします (図 5 参照)。 図 5. ボリューム作成の成功 ボリュームをアタッチするには、 [アクション] を選択します。次に、ドロップダウンから [ボリュームのアタッチ] を選択します (図 6 参照)。 図 6.「ボリュームのアタッチ」画面 ボリュームのアタッチウィンドウで、アップグレードするインスタンスをリストから選択します。次に、 [ボリュームのアタッチ] を選択します (図 7 参照)。 図 7.「ボリュームのアタッチ」基本詳細画面 RDP または Amazon Fleet Manager を使用してインスタンスに接続します。次に、ディスクの管理を使用して Windows 2012 R2 マシンにボリュームをアタッチします。GUI を使用するか、PowerShell コンソールから diskmgmt.msc を実行できます。 ボリュームを右クリックして オンライン に設定します (図 8 参照)。 図 8. ディスクの管理を使用してボリュームを「オンライン」に設定 これでドライブがマウントされ、システムに d:\ ドライブとして接続されました (図 9 参照)。 図 9. ボリューム D: がシステムに接続 補足 ：マウントしたドライブのフォルダをご確認ください。インストールメディアによっては、ISOファイルの形式で保存されてる場合があります。その場合は、ISOファイルをマウントして、そちらで次の作業を進めてください。 いよいよアップグレードを開始します。PowerShell コンソールを開き、マウントしたばかりのドライブにディレクトリを変更して、次のコマンドを送信します。. /setup.exe /auto upgrade すべてが正しく完了したら、Windows Server 2019 セットアップのインストールウィンドウが表示されます。 Windows Server 2019 Datacenter エディション を選択します (図 10 を参照)。 図 10. Windows Powershell イメージ。Windows Server 2019 Datacenter (Desktop Experience) を選択 完了するまで画面の指示に従ってアップグレードを続行します。アップグレードプロセス中に、システムが数回再起動します。 OS のアップグレードが完了したら、システムを本番環境に戻す前にアプリケーションの機能を検証できます。 クリーンアップ アタッチしたインストールメディアのボリュームをデタッチしてください (図11を参照)。インストールメディア自体が不要となった場合は、EBS ボリュームを削除してください。 図 11. EBAボリュームのデタッチ AWS EMP AWS は、Windows Server 向けサポート終了移行プログラム (EMP) を使用して、レガシーな Windows Server アプリケーションを AWS 上の最新のサポート対象バージョンの Windows Server に移行するお手伝いをします。EMP には、レガシーアプリケーションを Windows Server 2003、2008、2012 から AWS でサポートされている新しいバージョンに移行するためのツールが含まれています。EMP ツールはセルフサービスオプションとして、または AWS パートナーまたは AWS プロフェッショナルサービスの支援を受けて自由に使用できます。 まとめ このブログ記事では、技術的な観点から見た Windows Server の EOS を取り巻く課題と、アップグレードに向けた対策が必要となる理由について説明しました。さらに、Windows Server 2012 と 2012 R2 の手動アップグレード方法についても説明しました。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 3 部 : AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法 第 4 部 : AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 ご支援が必要な場合は、 こちら からお問い合わせください。お客様の特定の EOS 状況について把握し、AWS でのアップグレードをお手伝いします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

こんにちは！アマゾン ウェブ サービス ジャパン合同会社（AWS Japan）のパブリックセクターチームです。 今回のブログでは、2023 年 6 月 13 日(火)・14 日(水) にカリフォルニア州 アナハイムで開催された「AWS re:Inforce 2023」における、梅谷 晃宏 氏（デジタル庁 エグゼクティブアドバイザー）、山本 教仁 氏（同 シニアエキスパート）の講演内容をダイジェストでご紹介します。 Amazon Web Services, Inc. (AWS) では、クラウドセキュリティとコンプライアンスのグローバルカンファレンスである「AWS re:Inforce」を毎年開催しています。今年の目玉の一つが、デジタル庁 梅谷氏、山本氏のBreakout sessionへの登壇です。 日本政府が進めているガバメントクラウドの取組や、AWSを活用した大規模なリスク管理のアプローチまで、全世界に向けた情報発信を頂きました。公共部門のみならず、規制の厳しい業種・業態においてクラウド活用を検討されている皆様には非常に参考になる内容となっています。是非ご一読ください。 「デジタル敗戦からの変革を目指して」 講演の序盤、コロナ禍を契機としたデジタル庁の設立当時の状況について、梅谷氏はこう振り返ります。 「過去 20 年の努力にも関わらず、新型コロナウイルスの流行という緊急事態に対して、政府の情報システムは有効に対応することができたとは言えないでしょう。平井卓也 初代デジタル大臣が“デジタル敗戦”（※）と表現した状況そのものです。」 （※出所：総務省 「 令和3年版　情報通信白書」 第１部 第３節 　） このコロナ禍において、梅谷氏はクラウドを活用した「ワクチン接種記録システム」のインフラ開発をリードしていきます。 「1700 を超える全国の自治体、そして 1 億 2000 万人の日本国民がエンドユーザーとなるシステムを二ヵ月という短期間で構築し、厳格なセキュリティ要件を遵守することは、極めて困難なことでした。ですが、IaC（Infrastructure as Code）によるベースラインの構築等、現代のクラウドサービスに実装されている最新のテクノロジーをフル活用することで、期日通りのサービス開始と、その後の継続的な改善を実現し、過去 2 年間の安定稼働を実現しています。」 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 この実務的に実証された成功をより共通的に政府、自治体で活用できるように標準化を進めたものが、政府共通のクラウドサービス環境である「ガバメントクラウド」と呼ばれるクラウドの利用環境です。 「マネージドサービスと自動化によって手作業を削減し、どのようなシステムであっても政府システムとして必要となるセキュリティやリスク要件をIaCテンプレートにコードで実装することで、一定水準以上のセキュアで均質な環境を用意し、システムオーナーはその上にアプリケーションを開発することに集中することで、全体の開発スピードと効率性、安全性を確保できるようになります。ガバメントクラウドでは、こうしたクラウドの特性を最大限活用し、迅速かつ柔軟に、安全でコスト効果の高いクラウド環境を提供することを目指しています。」 梅谷氏は、今後の展開とともに、ご自身のパートをこう締めくくります。 「ガバメントクラウドをベースに政府ITの構造や慣習をより良い物へと変革していくことになるでしょう。例えば、民間企業各社等とも連携をしながら、政府システムの SaaS 市場の拡大を図っていくといったことが考えられます。」 「ガバメントクラウドが挑む 5 つの課題」 そして、山本氏からは、ガバメントクラウドの発足時にどのような課題に直面したのか、またクラウドを活用することでそうした課題にどのように対応してきたのか、解説を頂きました。以下、5 つのカテゴリに整理されています。 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 データガバナンス（Data governance） 日本国内にデータが保持されるように、東京もしくは大阪のリージョンのみを許可。アカウントの所有権を国機関や地方公共団体にしてデータの所有権を明確にし、暗号化サービスやコンフィデンシャルコンピューティングを活用して、データの機密性を担保。 スケール（Scale） 13 の中央省庁や 1700 の地方自治体、そして準公共領域等の大規模システム環境の管理。AWS Control Tower を活用したマルチアカウント構成、AWS Security Hub によるガードレールの実装。 予算（Budgets） クラウド利用料の従量課金の実現（月額）や業務区分に応じた請求書＝Payer Account の分割。クラウド利用料の可視化によるトレンドの把握やコスト意識の醸成。 従来型セキュリティ（Traditional security） CI/CD パイプラインによる本番環境メンテナンスの自動化（ゼロタッチプロダクション）。マネージドサービス/IaC 主体のアーキテクチャによる OS 運用の廃止、一過性のテストに終わらない継続的なセキュリティ監視やアラート通知。 レガシーアーキテクチャ（Legacy architecture） 政府文書（「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」）における“クラウドスマート”の明記、ワクチン接種記録システムにおけるモダン化の実績、アプリケーションのモダン化に向けた2段階のアプローチ（R1：Replatform、R2：Rebuild）の定義。 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 その他、AWS の Greg Eppel （Cloud Operation Global Tech Leader）及び AWS Japan の大富部貴彦（パブリックセクター統括本部 官公庁事業本部長）から、政府機関のお客様に対する支援内容や、AWS セキュリティソリューション及びそれらを活用したリスク管理策について、ご紹介をしています。講演内容は こちら より是非ご覧ください。 Learn More AWS re:Inforce 2023 「Managing risk in a regulated environment, feat. Japan Digital Agency (GRC302)」 ─の講演内容は こちら 日本の公共部門の皆様へのご案内 AWS では、政府・公共部門、パブリックセクターの皆さまの各組織におけるミッション達成が早期に実現するよう、継続して支援して参ります。 今後とも AWS 公共部門ブログ で AWS の最新ニュース・公共事例をフォローいただき、国内外の公共部門の皆さまとの取り組みを多数紹介した 過去のブログ投稿 に関しても、ぜひご覧いただければ幸いです。お悩みの際には、お客様・パートナー各社様向けの相談の時間帯を随時設けておりますので、ぜひ AWS までご相談ください（ Contact Us ）。 ＊　＊　＊　＊ このブログは、アマゾン ウェブ サービス ジャパン合同会社のパブリックセクターチームが投稿しました。 ＊　＊　＊　＊

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 今週は Amazon RDSとAmazon AuroraのExtended Support開始をアナウンス しました。この機能は多くのお客様からご要望をいただいていたもので、あるバージョンのデータベースのサポート終了日が迫っているがバージョンアップの検証が間に合わないのでなんとかしてほしい、というケースに対応するものです。ソフトウェアのバージョンアップは避けて通れないものですが、いろいろな事情ですぐに着手できないケースは現実的に存在するので、そういった場合に新たな選択肢を提供できるサービスですね。 一方で、この機能は インスタンスのvCPUあたり1時間の費用が発生 します。長期間利用すればそれだけコストが増加することには注意してください。我々としては、今まで通りタイムリーなバージョンアップを強くお勧めしています。あくまでも「いざというときのプランB」としての選択肢が増えた、と捉えていただくのが良いのではないかなと思います。 それでは、8 月 28 日週のアップデートを振り返ってみましょう。 2023 年 8 月 28 日週の主要なアップデート 8/28(月) AWS Systems ManagerのPatch ManagerがLinux OSの新しいバージョンに対応 Patch ManagerはOSのパッチ管理を可能にするAWS Systems Managerの機能ですが、今回Linux OSの新しいバージョンをサポートし、新たにRed Hat Enterprise Linux(RHEL) 8.7, 9.0, 9.1, 9.2と、Rocky Linux 8.6, 8.7, 9.0, 9.1, 9.2と、Oracle Linux 8.6, 8.7, 9.0, 9.1, 9.2に対応しました。 AWS NeuronがLlama 2, GPT-NeoX, Stable Diffusion XLなどのモデルに対応 AWS Neuronは高性能で費用対効果の高いディープラーニング関係処理を可能にするSDKで、AWS InferentiaやAWS Traniumによるアクセラレーションを容易に実現します。今回 AWS Neuronバージョン2.13 で、新たに生成系AIアプリケーションで利用されるモデルであるLlama 2, GPT-NeoX, Stable Diffusion XL, CLIPに対応しました。Llama 2については学習と推論を、GPT-NeoXについては学習を、Stable Diffusion XLとCLIPについては推論をサポートしています。 8/29(火) Amazon VPC CNIプラグインがKubernetesのNetworkPolicyリソースに対応 Amazon VPC CNI(Container Networking Interface)プラグインを利用して、KubernetesのNetworkPolicyによるPod間の通信制御を行うことができるようになりました。この機能を利用するとPod間の通信を様々な要素に基づいて許可・拒否する設計を容易に実装に落とし込むことができます。 Amazon Connect Casesが日本語をはじめ9つの言語に対応 コンタクトセンターのサービスであるAmazon Connectには、一度の対応で完了しないようなお客様の課題解決のためにケース管理を行う機能として Amazon Connect Cases が用意されています。今回、Amazon Connect Casesが日本語をはじめとする9つの言語に対応し、日本国内のお客様向けの業務でも利用しやすくなりました。 8/30(水) Gateway Load Balancer Endpointを仮想プライベートゲートウェイとVPCサブネットの間に配置可能に AWS Direct ConnectやVPNを利用してオンプレミス環境とVPCを接続する場合に、オンプレミス側からの通信の出入口となるのが仮想プライベートゲートウェイ(Virtual Private Gateway)です。今回、仮想プライベートゲートウェイから流入するトラフィックがVPCサブネットに到達する前に、Gateway Load Balancer Endpointにルーティングする設定が可能になりました。これによって、オンプレミス側からのトラフィックをAWS Network Firewallやサードパーティソリューションで保護するように構成することが可能になります。 AWS Amplifyで多要素認証に時刻ベースのワンタイムパスワードをサポート AWS AmplifyのAndroid, Swift, Flutterライブラリで、多要素認証(MFA)の方式として時刻ベースのワンタイムパスワード(TOTP, Time-based One-Time Passwords)をサポートしました。詳細については ブログ記事 をご覧ください。 Amazon Kinesis Data Analytics改めAmazon Managed Service for Apache Flinkを発表 Apache Flinkを利用してストリーミングデータをリアルタイムで変換・分析するためのサービス、Amazon Kinesis Data Analyticsがサービス名を変更し、Amazon Managed Service for Apache Flinkとして再デビューしました。なお、名称変更に伴う機能の変更はありませんので、既存のアプリケーションは従来通り動作しますのでご安心ください。 Amazon S3がDNSクエリへの応答時に多値応答をサポート Amazon S3が、S3エンドポイントに関するDNSクエリに対する応答として多値応答(Multivalue answer)をサポートしました。この機能を利用するとDNSクエリに対して最大8つのIPアドレスを回答として受け取ることが可能になり、これによって複数のIPアドレスに対して同時接続することでスループットを向上させることが可能です。新しいバージョンのAWS SDKを利用している場合は、アプリケーションの変更なしにこのアップデートのメリットを活用することができます。 AWS Clean Roomsで分析結果の配信設定機能とApache Icebergサポートを発表 AWS Clean Roomsで2つの新機能が発表されました。ひとつは分析結果の配信設定機能で、AWS Clean Roomsを介して処理された分析結果を、分析者に自動的に送付するのではなく「結果を受領する権限をもつと設定されたメンバー」に限って送付することができます。これによって分析者と結果受領者を分離することが可能になり、複雑なデータ取り扱い要件がある場合にも対応できるようになります。ふたつめはApache Icebergテーブルのサポートで、こちらはプレビューの扱いです。 8/31(木) Amazon RDS Database Preview EnvironmentでPostgreSQL 16 Release Candidateが試用可能に BetaバージョンやRelease Candidateバージョンなどを先行して試用できる Amazon RDS Database Preview Environment で、Amazon RDSで稼働するPostgreSQL 16をプレリリース版として評価できるようになりました。 9/1(金) Amazon AuroraとAmazon RDSでMySQLとPostgreSQLのExenteded Supportを発表 MySQL 5.7やPostgreSQL 11とそれ以降のメジャーバージョンを実行するAmazon AuroraとAmazon RDSについて、Extended Supportを提供することを発表しました。2023 年 12 月以降、コンソールやCLI/APIを通じてExtended Supportにオプトインすることが可能になります。Extended Supportではオープンソースコミュニティがメジャーバージョンのサポート終了後に、重要なセキュリティとバグの修正を提供します。また、メジャーバージョンの標準サポート終了日から最大3年間にわたって特定バージョンのインスタンスを継続利用できます。この機能は新しいメジャーバージョンにアップグレードするための検証が間に合わない、といった場合に作業時間を確保することを目的として提供される有償サービスです。バージョンアップは随時実施すべきという考え方は変わりませんのでご注意を。 Amazon SageMaker Canvasで新たに8つのデータコネクタが利用可能に コード開発や機械学習の深い知識なしにデータに基づく予測を実現するAmazon SageMaker Canvasで、新たに8つのデータコネクタが利用可能になりました。Salesforce, Databricks, SQL Server, MySQL, PostgreSQL, MariaDB, Amazon RDS, Amazon Auroraに対応しています。また、Snowflakeからストレージを介しないデータの取り込みと、SalesforceとSnowflakeのOAuth 2.0接続もサポートされ、これまでよりも広範なデータソースからのデータを利用した予測が可能です。 Amazon Cognitoが大阪リージョンとイスラエルリージョンで利用可能に Amazon Cognitoがアジアパシフィック（大阪）リージョンと、イスラエル（テルアビブ）リージョンでご利用いただけるようになりました。 Amazon RDS for PostgreSQLのバージョン13と14でPL/Rustに対応 PostgreSQLのバージョン13と14を実行するAmazon RDSにおいて、新たなTrusted Procedural LanguageとしてRust言語をご利用いただけるようになりました。複雑な計算処理を実行するタイプのデータ処理に最適です。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

昨今、国内企業においても「生成系 AI 」をビジネスにおいて効果的に利用する動きが活発化してきています。 アマゾン ウェブ サービス （以下、AWS ） は、お客様がこの新しいテクノロジーの価値をフルに活かすために生成系 AI の専門家からなるチームを設置するとともに、柔軟性と費用対効果に優れた生成系 AI サービスを企業に提供することで、あらゆる組織が AI を活用できるよう支援するという目標を掲げています。 その一環としてAWS は 2023 年 6 月 22 日（米国時間）に、お客様の生成系 AI ソリューションの構築と展開を支援する新プログラム「 AWS 生成系 AI イノベーションセンター 」を稼働開始しました 。1 億米ドル（約 140 億円）を本プログラムに投資し、 世界中のお客様と AWS の AI と機械学習分野のエキスパートをつなぎ、生成系 AI によるサービス開発や業務効率化をサポートし企業がアイデアをすばやく効果的に実現できるよう支援するものです。 また、AWS ジャパンは、2023 年 7 月 3 日に、日本独自の施策として大規模言語モデル（ LLM ） 日本に法人または拠点を持つ企業・団体を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンス、AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット 及びビジネス支援等のサポートを提供します。そしてこの度、本プログラムが支援する企業・団体が正式に決定し、本格的な LLM 開発支援が始まり、2023 年 12 月以降の成果発表会へと進むことになります。 本日 2023 年 9 月 4 日に開催されるキックオフ会では、AWS LLM 開発支援プログラム採択結果の発表に加え、採択された一部企業・団体からの挨拶も予定されています。また AWS からは、今後のプログラム詳細の説明、技術スペシャリストによる具体的な支援体制などの紹介を行います。 AWS LLM 開発支援プログラム採択企業（公開可能な企業および団体）※社名五十音順 会社・団体名（五十音順） ・カラクリ株式会社 ・株式会社サイバーエージェント ・ストックマーク株式会社 ・Sparticle 株式会社 ・Turing 株式会社 ・株式会社 Preferred Networks ・株式会社 Poetics ・株式会社松尾研究所 ・株式会社マネーフォワード ・株式会社ユビタス ・株式会社 Lightblue ・株式会社リクルート ・株式会社リコー ・rinna 株式会社 ・株式会社ロゼッタ ・株式会社わたしは AWS では、日本における生成系 AI の拡大、LLM の選択肢拡大に向けてこれからも支援を継続していきます。