AWS SaaS Factory シニアパートナーソリューションアーキテクト Peter Yang 氏、AWS SaaS Factory プリンシパルパートナーソリューションアーキテクト Ranjith Raman 氏による投稿 Amazon Web Services (AWS) のサービスを使用してデータ取り込みアーキテクチャを設計および実装する方法はいくつかあります。 マルチテナントの Software as a Service (SaaS) 構成でデータを取り込む場合、ソリューションに組み込むべき追加の考慮事項、課題、トレードオフがあります。 SaaS の場合、テナントの詳細を取得し、取り込みプロセス全体で伝達されるようにする必要があります。これは、テナントのペルソナに基づいてデータを分離し、ワークロードとストレージを分割する方法に直接影響します。 マルチテナントデータ取り込みプロセスを実装する際に使用できる戦略は複数あります。専用 (サイロ型) メカニズムを使用するものと、共有 (プール型) 取り込みモデルを使用するものがあります。どちらも完全に有効で、両方を混在させることができますが、この投稿では、プール型モデルでのデータ取り込みの実装の細部に焦点を当て、テナントが取り込みリソースを共有する際に考慮すべきさまざまな点を取り上げます。 この投稿には、コードの実際に動作するサンプルソリューションが付属しています。このソリューションをデプロイするための手順は、 GitHub から参照できます。 マルチテナントデータ取り込みの設計上の考慮事項 ソリューションの技術アーキテクチャについて詳しく見ていく前に、マルチテナントデータ取り込みプロセスを設計する際の主な考慮事項を見ていきましょう。以下は、このようなソリューションを構築する際に SaaS プロバイダーが検討する一般的な要素のリストです: スケーリングとパフォーマンス: 大量のリクエストを処理し、シームレスに数千のテナントにスケールできる能力 セキュリティと隔離: テナントのイベントが認証されていることを保証するためのコントロールを実装し、そのコントロールを使用したデータのパーティショニングと隔離の判断 リソース管理: 突発的で予測が困難なトラフィックを処理するシームレスな容量管理 運用効率: 運用と管理のオーバーヘッドを削減 ソリューションアーキテクチャ この投稿では、データ (EC サイトや POS アプリケーションなどを想定) を収集および集計し、このデータをテナント / 顧客固有の属性で処理 (エンリッチおよび変換) してバックエンドデータストアに格納するサンプルソリューションをもとに説明を行います。 これらのアプリケーションは通常、「注文の合計」や「購入された商品のカテゴリー」などのクリックストリームデータやイベントを追跡し、データからトレンドを特定したり、重要な洞察を導き出すことを目的としています。 任意の瞬間にアクティブなユーザー数によっては、1 秒間に生成されるデータは大量になる可能性があります。 そのようなビジネスやユースケースをサポートするには、非常にスケーラブルでパフォーマンスが高く、イベントを非常に低いレイテンシーで処理できるアーキテクチャが必要です。 次の図は、ソリューションのアーキテクチャを示しています。 図 1 – ハイレベルアーキテクチャ リクエストフロー このアーキテクチャの詳細に入る前に、サンプルソリューションで採用されているハイレベルな要素を見て見ましょう。 以下が、このソリューションの一部であるいくつかのステップです: このソリューションのフローは、図 1 の左側から開始します。テナントは、 Amazon API Gateway が提供する REST API を使用して、SaaS 環境にメッセージやイベントを送信します。これは、ストリーミングイベントのエントリポイントであり、各テナントからのイベントの認証を担当します。 Amazon API Gateway は、 Amazon Cognito を使用してJSON Web Token (JWT) を検証する Lambda オーソライザー を利用します。Lambda オーソライザーは、 Amazon Kinesis Data Streams への入力として使用できるように、Amazon API Gateway のコンテキストに tenantId を追加します。 Amazon API Gateway はプロキシとして機能し、Kinesis Data Streams にテナントイベントをプッシュします。Kinesis Data Streams は、あらゆる規模でデータストリームをキャプチャ、処理、保存するのに適した、サーバレスなストリーミングデータサービスです。この例では、Kinesis Data Streams が異なるテナントからのストリーミングデータを収集するデータインジェストストリームになります。 Amazon Kinesis Data Streams はデータを Amazon Managed Service for Apache Flink  にプッシュします。このソリューションでは Amazon Kinesis Data Analytics for Apache Flink がデータの処理を行い、tenantId とtimestamp の追加に利用されます。これらの値は Amazon Data Firehose がストレージとして利用される Amazon Simple Storage Service (Amazon S3) のプレフィックスの作成に使用します。 Amazon Kinesis Data Analytics for Apache Flink はテナントイベントを Amazon Data Firehose にプッシュします。Amazon Data Firehose は、リアルタイムのストリーミングデータを直接 S3 に配信し、ストレージとさらなる処理のために使用されます。S3 には、マルチテナントデータを効率的に保存および整理するためのいくつかのメカニズムがあります。 より深い考察は、S3 を使用したマルチテナンシー実装のさまざまな戦略が議論されているこの AWS ブログ投稿 をチェックしてください。 これでハイレベルなアーキテクチャを理解したので、ソリューションの各コンポーネントについてより詳しく見ていきましょう。 リクエストの認証と認可 Amazon API Gateway は、このソリューションのフロントドアとして機能し、テナントアプリケーションからのデータストリームをスケーラブルな方法で取り込むための、セキュアなエントリーポイントを提供します。API Gateway を使用することで、テナントコンテキストを抽出し、受信リクエストを認証する Lambda オーソライザー を導入することもできます。 このテナント情報は、テナントが Amazon Cognito によって認証されたときに生成された エンコード済み JSON Web トークン (JWT) を介して渡されます。このコンテキストは、インジェストされたデータを個々のテナントに関連付けることをこのソリューションが可能にするために不可欠です。 API Gateway によって処理される各リクエストは、JWT からテナントコンテキストを抽出し、リクエストのアクセス範囲を設定する AWS Identity and Access Management (IAM) ポリシーを返す Lambda オーソライザーを呼び出します。 ポリシーとともに、リクエストのコンテキストにテナント ID ( tenantId ) も導入します。フローの後半で、このコンテキスト値の利用方法を見ていきます。以下のコード例は、コンテキストの一部として tenantId を設定する方法を示しています。 policy = AuthPolicy(principalId, awsAccountId) policy.restApiId = apiGatewayArnTmp[0] policy.region = tmp[3] policy.stage = apiGatewayArnTmp[1] policy.allowAllMethods() authResponse = policy.build() context = { 'tenantId': tenantId, } authResponse['context'] = context return authResponse Kinesis Data Streams へのデータのルーティング リクエストが正常に処理された後に、メッセージが Amazon API Gateway から Amazon Kinesis Data Streams に転送されるように設定します。これは、テナントデータのストリームを収集および処理します。以下の 図 2 は、設定手順を示しています。 ここでは、統合リクエストの統合タイプを AWS サービスに設定しています。つまり、リクエストを AWS サービス (この例では Kinesis Data Streams) に転送しているということです。 図 2 – Amazon API Gateway の統合リクエスト値 リクエストがストリームに転送される前に、API Gateway で変換を適用して、Kinesis Data Stream が期待している形式にリクエストを変換します。 Amazon API Gateway ではマッピングテンプレートを使用して、メソッドリクエストのペイロードを対応する統合リクエストにマップできます。 ソリューションでは、図 3 に示すように、テンプレートを使用して StreamName、Data、 および PartitionKey の値を設定しています。 Lambda オーソライザー によって設定された コンテキスト の一部として受信した tenantId フィールド を使用して、Kinesis Data Streams で必要な属性である PartitionKey の値を設定しています。 このテンプレートにより、ダウンストリームのサービスに渡されるすべてのリクエストが、そのリクエストを行うテナントとの関連付けがされていることを確認します。 図 3 – Amazon API Gateway マッピングテンプレート Amazon Managed Service for Apache Flink によるストリーミングデータの処理 前のセクションで説明したように、データストリームに送信するすべてのメッセージには、tenantId というパーティションキーがあります。このパーティションキーの値は、メッセージを処理するシャードに影響を与えます。 各 Kinesis ストリームには1つ以上のシャードがあり、シャード数は Kinesis が処理できるデータ量 に直接影響します。 パーティションキーによってはホットシャードを引き起こし、ストリームのパフォーマンスに影響を与える可能性があることに気を付けてください。 データストリームによってメッセージが処理されると、Amazon Managed Service for Apache Flink を使用して、データのさらなる分析を行います。このサービスを使用すると、Java のようなプログラミング言語を使用して、ストリーミングデータを処理および分析できます。 サンプルソリューションでは、データが次のサービスに転送される前に、Flink ジョブを使用してメッセージを追加のフィールドで拡張しています。 図 4 の実装で見られるように、Flink ジョブには inputStreamName があり、これはデータの送信元を示しています。今回の場合は Kinesis Data Stream です。 上述のとおり、Flink ジョブはメッセージを Amazon Data Firehose 配信ストリームにプッシュする前に、tenantId の追加属性とタイムスタンプフィールドも追加します。 図 4 – Amazon Managed Service for Apache Flink – InputStream と FirehoseOutputStream の設定 また、下記の図 5 のコードに示すように、TenantId フィールドはメッセージが Amazon S3 のどのパスに配置されるかを示すために使用され、タイムスタンプは Flink ジョブがメッセージを処理した正確な時刻を反映します。 図 5 – Flink ジョブでのtenantId の設定 Amazon Data Firehose を使用したデータ配信 サンプルソリューションでは、サービスごとのテナント分割モデルを使用してスケールを向上させるために、Amazon Data Firehose を利用してメッセージを S3 に配信しています。これは特に、SaaS システムに多数のテナントがある場合に効果的です。 Flink では、Flink ジョブから直接メッセージを S3 に配信できます。 しかし、データを Amazon Data Firehose に送信することで、このソリューションを将来的に拡張できる柔軟性が得られます。例えば、 Amazon Redshift 、 Amazon OpenSearch Service などの その他の送信先 や、その他のモニタリングソリューションをサポートできるようになります。 図 6 – Amazon Kinesis Data Firehose デリバリーストリーム 図 6 に示すように、配信ストリーム delivery-multi-tenant-firehose-stream は動的パーティショニング機能を利用しています。これにより、データ内のキーを使用して、Data Firehose のストリーミングデータをパーティション分割することができます。 図 7 – tenantId と timestamp を使用した動的パーティショニング キーは、対応するテナントの S3 プレフィックス位置に配信される前のデータのグループ化に用いられます。図 7 に示すように、動的パーティショニングを実装するために、入力メッセージの一部であったフィールド tenantId と timestamp を使用しました。S3 プレフィックスの一部として tenantId があることで、データの消費時に S3 のテナント分離戦略の一部として使用できる IAM ポリシー を作成できます。 最後に、S3 へのデータ配信のために、Amazon Data Firehose は、配信ストリームのバッファリング設定に基づいて、複数の入力レコードを連結します。 S3 へのデータ配信の頻度は、配信ストリームの S3 バッファサイズとバッファ間隔の値によって決まります。 こちらの詳細は、 AWS ドキュメント で確認できます。 結論 この投稿では、AWS のサービスを使用してマルチテナントのデータ取り込みと処理エンジンを構築する方法を探りました。 このデータパイプラインの各コンポーネントと、SaaS のマルチテナントデータ取り込みプロセスの設計アプローチに影響を与える可能性のあるいくつかの主な考慮事項を検討しました。 また、AWS サービスを使用して、マルチテナントのストリーミングデータをどのようにインジェスト、変換、ストレージできるかを確認しました。その際、データの安全な処理を保証するために、パイプラインに構築物が組み込まれていることも確認しました。 ここで紹介したサンプルアプリケーションを掘り下げていくと、AWS 上に完全な実働ソリューションを構築する上でのエンドツーエンドの全体的な体験がよりよく理解できるようになるでしょう。 これにより、SaaS データ取り込みプロセスのニーズと整合性のあるポリシーの周りを形作ることができる一方で、良い出発点を提供するはずです。 このソリューションのより詳細な概要については、環境のすべての動的な要素を理解するのに役立つ段階的なデプロイ手順が記載されている GitHub リポジトリをご覧いただければと思います。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaSの旅路にあるどの段階の組織でも支援します。新しい製品の構築、既存アプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、様々なニーズに対応できます。より多くの技術的、ビジネス的なコンテンツやベストプラクティスを知るには、 AWS SaaS Factory Insights Hub をご覧ください。 SaaS ビルダーは、エンゲージメントモデルについて問い合わせたり、AWS SaaS Factory チームと連携するために、アカウント担当者に連絡することをお勧めします。 こちらに 登録して、 AWS 上の最新の SaaS のニュース、リソース、イベントについて通知を受け取ることができます。 翻訳はソリューションアーキテクトの福本が担当しました。原文は こちら です。 なお、翻訳版では Amazon Kinesis Data Analytics と Amazon Kinesis Data Firehose の名前変更に伴い、それぞれ Amazon Managed Service for Apache Flink、Amazon Data Firehose と表記しています。 https://aws.amazon.com/jp/about-aws/whats-new/2023/08/amazon-managed-service-apache-flink/ https://aws.amazon.com/jp/about-aws/whats-new/2024/02/amazon-data-firehose-formerly-kinesis-data-firehose/

レジリエンスは、あらゆるワークロードの開発において重要な役割を果たしており、 生成 AI ワークロードも例外ではありません。生成 AI ワークロードを開発する際には、レジリエンスの観点における独自の考慮事項があります。組織の可用性と事業継続性の要件を満たすためには、レジリエンスを理解し、優先順位を付けて対応することが不可欠です。本ブログ記事では、生成 AI ワークロードを構成する各スタックとそれらの考慮事項について説明します。 生成 AI ワークロードを構成するスタック 生成 AI の魅力の多くがモデルに焦点を当てていますが、完全なソリューションには複数分野の人材、スキル、ツールが必要です。次の図は、 a16z （Andreessen Horowitz）が公開している大規模言語モデル (LLM) を利用した新しいアプリケーションスタックを AWS の視点で捉えたものです。 従来の AI や機械学習 (ML) を中心としたソリューションと比較すると、生成 AI ソリューションには以下が含まれていることが分かります。 新しいロール – モデルチューナーだけでなく、モデルの開発元やモデルインテグレーターの役割も考慮する必要があります 新しいツール – 従来の MLOps スタックは、プロンプトエンジニアリングやエージェント（他のシステムと対話するツールを呼び出す）に必要な実験の追跡やオブザーバビリティに対応していません 検索拡張生成 (RAG) 従来の AI モデルとは異なり、RAG は外部ナレッジソースを統合することで、より正確でコンテキストに関連したレスポンスを可能にします。RAG を使用する際の考慮事項は以下のとおりです。 外部ナレッジソースからのデータ取得に適切なタイムアウトを設定することは、顧客体験にとって重要です。チャットの最中に切断されることほど、ユーザー体験を損なうものはありません。 プロンプトへの入力データが、利用するモデルのトークン数制限内であることを検証してください。 プロンプトを信頼できるデータストアに保存してください。万が一プロンプトを紛失した場合やディザスタリカバリ戦略の一環として、プロンプトを保護できます。 データパイプライン RAG パターンを使用して基盤モデルにコンテキストデータを提供する場合、ソースデータを取り込み、埋め込みベクトルに変換し、ベクトルデータベースに保存できるデータパイプラインが必要です。コンテキストデータを事前に準備している場合はバッチパイプラインになります。新しいコンテキストデータを逐次取り込む場合は低レイテンシパイプラインとなります。バッチパイプラインの場合、一般的なデータパイプラインと比較して、いくつかの課題があります。 データソースには、ファイルシステム上の PDF ドキュメント、CRM ツールのような SaaS (Software as a Service) からのデータ、既存の Wiki やナレッジベースなどが考えられます。これらのソースからの取り込みは、 Amazon S3 (Amazon Simple Storage Service) 上のログデータやリレーショナルデータベースにある構造化データなどの一般的なデータソースからの取り込みとは異なり、並列処理のレベルがソースシステムによって制限される可能性があるため、スロットリングを考慮し、バックオフ手法を使用する必要があります。また、ソースシステムの一時的な障害等に備えて、エラー処理とリトライロジックを組み込む必要があります。 埋め込みモデルは、パイプライン内でローカルに実行するか外部モデルを呼び出すかに関わらず、パフォーマンスのボトルネックになる可能性があります。埋め込みモデルは主に GPU 上で実行される基盤モデルであり、そのキャパシティは有限です。モデルをローカルで実行する場合は、GPU 容量に基づいてタスクを割り当てる必要があります。モデルを外部で実行する場合は、外部モデルが飽和状態にならないようにする必要があります。いずれの場合も、達成できる並列度は、バッチパイプラインが利用できる CPU や RAM の量ではなく、埋め込みモデルによって決定されます。 低レイテンシパイプラインの場合、埋め込みベクトルの生成時間を考慮してください。アプリケーションは低レイテンシパイプラインを非同期で呼び出す必要があります。 ベクトルデータベース ベクトルデータベースには 2 つの機能があります。埋め込みベクトルの保存および、あるベクトルに対して最も近い k 個のマッチングを見つける類似検索を実行することです。また、ベクトルデータベースには大きく分けて次の 3 つのタイプがあります。 Pinecone 等のベクトルデータベース専用 SaaS 製品やサービスに組み込まれたベクトルデータベース機能（ Amazon OpenSearch Service や Amazon Aurora などの AWS サービスも含まれる） 一時データに使用できるインメモリデータベース（低レイテンシが要求されるシナリオ） 本ブログ記事では、類似性検索機能の詳細については説明しません。これらは重要ですが、システムの機能的な側面であり、レジリエンスに直接影響を与えないためです。その代わり、ストレージシステムとしてのベクトルデータベースのレジリエンスの側面に焦点を当てます。 レイテンシ – 高負荷や予測不可能な負荷に対してもパフォーマンスを発揮できますか。そうでない場合、アプリケーションはレート制限やバックオフ、リトライ処理を行う必要があります。 スケーラビリティ – いくつベクトルを保持できますか。ベクトルデータベースの容量を超える場合、シャーディングや他のソリューションを検討する必要があります。 高可用性とディザスタリカバリ – ベクトルデータベースは、単一のリージョンで高可用性を実現していますか。別のリージョンにデータをレプリケートして災害復旧目的で使用できますか。埋め込みベクトルは貴重なデータであり、再生成にはコストがかかります。 アプリケーション 生成 AI ソリューションの統合において、アプリケーションには、3 つの固有の考慮事項があります。 高いレイテンシの可能性 – 基盤モデルは大きな GPU インスタンス上で実行されることが多いため、GPU 容量が確保できない可能性があります。レート制限、バックオフとリトライ、負荷制限のベストプラクティスを使用してください。高いレイテンシがアプリケーションのメインインターフェースに干渉しないように、非同期処理を利用した設計にします。 セキュリティ態勢 – エージェント、ツール、プラグイン、その他の方法を使用してモデルを他のシステムに接続している場合は、セキュリティ態勢に特に注意を払います。モデルはこれらのシステムと予想外の方法でやりとりしようとする可能性があります。たとえば、他のシステムからのプロンプトの受信を制限するなど、標準的なプラクティスである最小特権のアクセス許可に従ってください。 急速に進化するフレームワーク – LangChain のようなオープンソースフレームワークは急速に進化しています。このような成熟度の低いフレームワークから他のコンポーネントを分離するために、マイクロサービスアプローチを使用します。 キャパシティ キャパシティは、推論とトレーニングモデルのデータパイプラインという 2 つのコンテキストで考えることができます。組織が独自のパイプラインを構築する際にキャパシティが考慮事項となります。ワークロードを実行するインスタンスを選択する際、CPU とメモリが最大の要件の 2 つです。 生成 AI ワークロードをサポートできるインスタンスは、汎用インスタンスタイプよりも入手が難しい場合があります。インスタンスの柔軟性は、キャパシティとキャパシティプランニングに役立ちます。使用可能なインスタンスタイプはリージョンによって異なります。 重要なユーザージャーニーの場合、インスタンスタイプを予約または事前プロビジョニングし、必要なときに利用できるよう検討してください。このパターンにより、レジリエンスのベストプラクティスである静的に安定したアーキテクチャが実現できます。AWS Well-Architected Framework の信頼性の柱における静的安定性の詳細については、 静的安定性を使用してバイモーダル動作を防止する を参照してください。 オブザーバビリティ Amazon SageMaker や Amazon Elastic Compute Cloud (Amazon EC2) 上でモデルをホストする場合は、通常収集するリソースメトリクスである CPU や RAM の使用率に加えて GPU の使用率も注意深く監視します。基盤モデルや入力データが変更されると、GPU 使用率が予期せず変化する可能性があります。GPU メモリが不足するとシステムが不安定な状態になる可能性があります。 スタックの上位では、システム内の呼び出しの流れをトレースして、エージェントとツール間の対話をキャプチャすることも重要です。エージェントとツール間のインターフェースは API コントラクトほど正式に定義されていないため、パフォーマンスのみならず、新しいエラーシナリオを捉えるためにもこれらのトレースを監視する必要があります。モデルやエージェントのセキュリティリスクや脅威を監視するために、 Amazon GuardDuty などのツールを使用できます。 埋め込みベクトル、プロンプト、コンテキスト、出力のベースラインとこれらの間の相互作用もキャプチャする必要があります。これらが時間とともに変化する場合、ユーザーがシステムを新しい方法で使用している、コンテキストに渡す参照データが想定問答をカバーできていない、またはモデルの出力が突然変化したことを示している可能性があります。 ディザスタリカバリ 事業継続計画とディザスタリカバリ戦略を策定することは、どのワークロードにとっても必須です。生成 AI ワークロードも例外ではありません。ワークロードに適用可能な障害モードを理解することで、戦略の指針となります。 Amazon Bedrock や SageMaker などの AWS マネージドサービスを使用している場合は、そのサービスが復旧用の AWS リージョンで利用可能であることを確認してください。本ブログ記事の執筆時点では、これらの AWS サービスはリージョン間のデータレプリケーションをネイティブでサポートしていないため、ディザスタリカバリのためのデータ管理戦略を検討する必要があります。また、災害時にファインチューニングされたカスタムモデルを利用したい場合、複数のリージョンにおいてファインチューニングを行っておく必要があります。 まとめ 本ブログ記事では、生成 AI ソリューションを構築する際にレジリエンスを考慮する方法について説明しました。生成 AI アプリケーションにはいくつか興味深いニュアンスがありますが、既存のレジリエンスパターンとベストプラクティスは依然として適用できます。あとは、生成 AI アプリケーションの各スタックを評価し、関連するベストプラクティスを適用することが重要です。 生成 AI と AWS サービスでのその利用に関する詳細は、次のリソースを参照してください。 Securing generative AI: An introduction to the Generative AI Security Scoping Matrix Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます (プレビュー版) Llama Guard is now available in Amazon SageMaker JumpStart 著者について Jennifer Moran は、ニューヨークを拠点とする AWS シニアレジリエンシーソリューションアーキテクトです。ソフトウェア開発、アジャイルリーダーシップ、DevOps など、多岐にわたる技術分野で働いた経験を持っています。顧客のレジリエンス向上とその重要性について公に発信することを楽しんでいます。 Randy DeFauw は、AWS シニアプリンシパルソリューションアーキテクトです。ミシガン大学で自動運転車両のコンピュータビジョンについて研究し、電気電子工学の修士号を取得しています。また、コロラド州立大学で MBA を取得しています。Randy はソフトウェアエンジニアリングから製品管理まで、テクノロジー分野のさまざまなポジションを歴任してきました。2013 年にビッグデータ分野に参入し、その分野を探索し続けています。機械学習分野のプロジェクトに積極的に取り組んでおり、Strata や GlueCon など、数多くのカンファレンスでプレゼンテーションを行っています。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

多くの AWS のお客様は、アーキテクチャをモダナイズし、オープンソースデータベースに移行し始めています。 Babelfish for Aurora PostgreSQL を使用すると、SQL Server から Amazon Aurora PostgreSQL Compatible エディション へのアプリケーションの移行が容易になります。Babelfish では、Aurora PostgreSQL Compatible は一般的に使用される T-SQL 言語とセマンティクスをサポートするため、アプリケーション内のデータベース呼び出しに関連するコード変更の量を減らすことができます。 この投稿では、 AWS Database Migration Service (AWS DMS) を使用したデータ移行を含め、Microsoft SQL Server データベースを Babelfish に移行する方法を示し、移行には SQL Server Northwind サンプルデータベース を使用します。さらに、いくつかの一般的な問題とその解決方法についても検討します。 Babelfish 概要 段階的な移行プロセスを説明する前に、Babelfish のアーキテクチャを見てみましょう。Babelfish は、T-SQL コードやクライアントの接続ドライバーへの変更を最小限に抑えて SQL Server アプリケーションを Aurora PostgreSQL Compatible に移行するための移行アクセラレーターです。これにより、ライセンスを取得した独自のオンプレミスデータベースマネージメントシステム (DBMS) からクラウド内のオープンソース DBMS への移行が可能になり、モダナイゼーションへの道が開けます。 Babelfishは、PostgreSQL が SQL Server 用に作成されたアプリケーションからのクエリを理解する機能を提供します。Babelfish は SQL Server ワイヤプロトコルと SQL Server のクエリ言語である T-SQL を理解しているので、データベースドライバを切り替えたり、アプリケーションクエリをすべて書き直したりする必要はありません。次の図に示すように、SQL Server 接続ライブラリを使った TDS 接続と標準の PostgreSQL 接続を作成できます。 Babelfish の利点は次のとおりです。 既存のクエリを保持 – 言語拡張により Aurora PostgreSQL Compatible で T-SQL と連携できるようになります。 移行を加速 – 移行をより早く完了できるため、数か月から数年の作業を節約できます。 イノベーションの自由 – T-SQL コードをオープンソースの機能と並行して実行し、使い慣れたツールを使用して開発を続けることができます。 ソリューション概要 Babelfish へのマイグレーションの大まかな手順は次のとおりです。 DDL を生成し、 Babelfish Compass ツールを使用して分析を実行します。DDL は次のオプションを使用して生成できます。 SQL Server Management Studio (SSMS) を使用してデータベーススキーマをエクスポートする。 Babelfish Compass v.2023-08 以降では、分析が必要な SQL Server データベースの DDL 生成を Compass がオプションで直接実行することも可能。 Babelfish extension を使用して Aurora PostgreSQL インスタンスを作成します。 ポート 1433 に対して DDL スクリプトを実行して、Babelfish のスキーマを再作成します。 AWS DMS を使用して SQL Server から Babelfish にデータを移行し、SQL Server ではなく Babelfish TDS ポートに接続するようにクライアントアプリケーションを再設定します。 バックエンドが Babelfish である .NET アプリケーションの場合、アプリケーションコードを変更する必要はほとんどありません。 Babelfish でサポートされていない機能 については、アプリケーションコードを変更する必要があります。 以下のセクションでは、SQL Server から Babelfish for Aurora PostgreSQL に移行するためのステップバイステップの詳細を説明します。 Babelfish Compass アセスメントツール Babelfish Compass は、Windows、Mac、Linuxで動作し、Babelfish との互換性を評価するスタンドアロンツールです。このツールは DDL コードと SQL コードを調べ、サポートされている機能とサポートされていない機能をすべて一覧表示した詳細なレポートを提供します。 Babelfish Compass をインストールして実行するには、次の手順を実行してください。 Babelfish Compass の最新バージョン (.zip ファイル) を GitHub からダウンロードしてください。 ファイルを必要なフォルダに解凍します。このフォルダーには 3 つの zip ファイルがあります。 BabelfishCompass_V.2023-08.zip というファイルを解凍する必要があります。 Babelfish Compass には 64 ビット Java/JRE 8 以降が必要です。Compass レポートを実行する前にインストールする必要があります。 CMD (Windows) を開き、zip ファイルを解凍したパスに移動します。 インストールを確認するには、 -help オプションを指定して BabelfishCompass を実行します。 BabelfishCompass -help Bash Northwind データベースの Compass レポートの生成 Compass ツール機能を使用して、Compass v.2023-08 以降で DDL を生成します。このオプションは、SQL Server に多数の SQL Server インスタンスまたはデータベースが存在する場合に便利です。Compass に DDL 生成を実行させるには、次のコマンドラインオプションを指定する必要があります。その後、Compass は SQL Server に接続して DDL ファイルを生成し、生成されたファイルに対して Compass 解析を実行します。 -sqlendpoint – SQL Server のホスト名または IP アドレス。オプションでポート番号を指定することもできます (たとえば、10.123.45.67,1433 や mybigbox,1433)。 -sqllogin – SQL Server に接続するためのログイン名。DDL を生成する権限を得るには、通常、このログインが sysadmin ロールのメンバーである必要があります。 -sqlpasswd – 対応するパスワード。 -sqldblist – これはオプションです。省略するか、all を指定すると、サーバー内のすべてのユーザーデータベースに DDL が生成されます。あるいは、データベース名をコンマで区切ったリストを指定することもできます。 DDL 生成の速度は、SQL Server とのネットワーク上の距離に大きく依存します。時間がかかりすぎる場合は、 CTRL+C を使用してプロセスをキャンセルし、SSMS を使用して手動で DDL 生成を行うと、処理が速くなる場合があります。 BabelfishCompass Northwind-report5 -sqlendpoint < endpoint > -sqllogin < login > -sqlpasswd < password > -sqldblist Northwind -optimistic -reportoptions xref -rewrite Bash 上記のスクリプトは、Babelfish compass レポートを生成し、デフォルトではユーザーの Documents\\ BabelfishCompass フォルダーに保存されます。また、このスクリプトは、指定したデータベースごとに個別の DDL ファイルを生成し、以下のスクリーンショットのようにコンピュータの TEMP ディレクトリに保存します。 compass レポートを生成する他のオプションは、最初に SSMS を使用して DDL を生成し、Babelfish compass コマンドを実行してレポートを生成することです。詳細については、「 Babelfish Compass を Deep Dive する 」を参照してください。 結果の分析 移行作業全体を評価するには、最初にレポートの上部にある概要セクションを確認することです。このセクションには、オブジェクトの数と SQL コードの行数が報告されています。これにより、アプリケーションがどれほど大きく、どれだけの労力が必要かがひと目でわかります。 --- Report Setup --------------------------------------------------------------- BabelfishFeatures.cfg file : v.3.2.0, Jun-2023 Target Babelfish version : v.3.2.0 (PG 15.3) Command line arguments : Northwind-report SMOTest -sqlendpoint ****** -sqllogin **** -sqlpasswd ******** -sqldblist Northwind DDL input files : Northwind_SMO_DDL_2023-Aug-10.sql DDL input files location : C:\Users\ADMINI~1\AppData\Local\Temp\2\CompassAutoDDL-2023-Aug-10-01.36.40 User .cfg file (overrides) : C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.cfg Report name : Northwind-report This report : C:\Users\Administrator\Documents\BabelfishCompass\Northwind-report\report-Northwind-report-bbf.3.2.0-2023-Aug-10-01.37.18.html Session log : log\session-log-Northwind-report-bbf.3.2.0-2023-Aug-10-01.36.40.html ================================================================================ -------------------------------------------------------------------------------- --- Executive Summary for Babelfish v.3.2.0 ------------------------------------ -------------------------------------------------------------------------------- Total #lines of SQL/DDL: 1272 #Procedures/functions/triggers/views: 23 #Tables: 13 SQL features not supported by Babelfish : 127 Estimated complexity of not-supported features: medium:127 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- --- Applications Analyzed (1) -------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents Northwind (1272 lines SQL) -------------------------------------------------------------------------------- --- Assessment Summary --------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents #applications : 1 #input files : 1 #SQL batches : 350 #lines SQL/DDL processed : 1272 #lines SQL in objects : 208 (procedures/functions/triggers/views) total #SQL features : 1208 Supported : 750 Not Supported : 0 Review Semantics : 45 Ignored : 413 Overridden by user .cfg file (C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.Optimistic.cfg): Ignored (was: Not Supported) : 129 -------------------------------------------------------------------------------- --- Object Count --------------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents DATABASE : 1 LOGIN : 51 PROCEDURE : 7 (72 lines SQL) without issues: 7 of 7: list TABLE : 13 (144 columns) without issues: 13 of 13: list VIEW : 16 (136 lines SQL) without issues: 16 of 16: list constraint CHECK : 8 constraint FOREIGN KEY : 13 constraint PRIMARY KEY : 13 index : 26 user-defined datatype (UDD), scalar : 3 HTML 次に、「Not Supported（サポート対象外）」、「Review Manually（手動レビュー）」、「Review Semantics(セマンティクスの確認）」、「Review Performance（パフォーマンスの確認）」、「Ignored（無視）」の「SQL 機能の概要」セクションに着目します。 問題に基づいて、考えられる回避策を開発するか、移行されたアプリケーションに必要のない機能をスケールダウンして移行のスコープを狭めます。移行のスコープを狭めるには、開発者とアプリケーションオーナーの協力が必要です。コマンドで Optimistic オプションを使用すると、一部のコマンドが Not Supported ではなく Ignored の下に一覧表示されます。 Optimistic オプションなしでレポートを生成すると、以下の機能はサポート対象外としてレポートされます。最適化オプションで無視された機能は、アプリケーションを移行する目的では通常は無視できます。 Optimistic オプションを使用して Northwind スキーマの compass レポートを生成する場合、サポートされていない機能はないことに注意してください。 -------------------------------------------------------------------------------- --- SQL features 'Ignored' in Babelfish v.3.2.0 --- (total=413) ---------------- -------------------------------------------------------------------------------- Back to Table of Contents DDL (286/14) Option ALLOW_PAGE_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_PAGE_LOCKS=ON, Index, in CREATE INDEX : 26 Option ALLOW_ROW_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_ROW_LOCKS=ON, Index, in CREATE INDEX : 26 Option DROP_EXISTING=OFF, Index, in CREATE INDEX : 26 Option IGNORE_DUP_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ONLINE=OFF, Index, in CREATE INDEX : 26 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, Index, in CREATE INDEX : 26 Option PAD_INDEX=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option PAD_INDEX=OFF, Index, in CREATE INDEX : 26 Option SORT_IN_TEMPDB=OFF, Index, in CREATE INDEX : 26 Option STATISTICS_NORECOMPUTE=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option STATISTICS_NORECOMPUTE=OFF, Index, in CREATE INDEX : 26 Permissions (39/2) ALTER AUTHORIZATION ON object TO SCHEMA OWNER : 36 ALTER AUTHORIZATION ON TYPE TO SCHEMA OWNER : 3 Users (88/4) ALTER SERVER ROLE processadmin ADD MEMBER : 1 ALTER SERVER ROLE setupadmin ADD MEMBER : 1 Login option CHECK_EXPIRATION, in CREATE LOGIN : 43 Login option CHECK_POLICY, in CREATE LOGIN : 43 HTML Babelfish for Aurora PostgreSQL クラスターの生成 Babelfish クラスターの作成は Aurora PostgreSQL クラスターの作成とほぼ同じです。Babelfish for Aurora PostgreSQL は Aurora PostgreSQL バージョン 13.4 以降でサポートされているため、サポートされているバージョンを選択して Babelfish の設定セクションで「Babelfish をオンにする」にチェックします。 Babelfish クラスターを作成するときは、移行された単一の T-SQL ユーザーデータベースを使用するか、移行した複数の T-SQL ユーザーデータベースを一緒に使用するかを選択します。 single-db を指定した場合、Babelfish では 1 つの T-SQL データベースしか作成できず、T-SQL スキーマは Babelfish データベースでは通常の PostgreSQL スキーマとして作成されます。マルチデータベースモードでは、PostgreSQL からアクセスすると、ユーザーデータベースのスキーマ名は dbname_schemaname になります。T-SQL からアクセスするとスキーマ名は同じままです。詳細については、「 1 つのデータベースまたは複数のデータベースでの babelfish の使用 」を参照してください。 Babelfish クラスター内の複数の T-SQL ユーザーデータベースがサポートされるため、移行モードには multi-db を使用することをお勧めします。クラスターの作成後にこの値を変更することはできないため、最初は T-SQL ユーザーデータベースが 1 つしか必要ない場合でも柔軟性を持たせたほうがよいです。 SQL Server に近い状態にしておくために、プライマリユーザー名として sa を選択できます。 Babelfish クラスターを作成すると、リーダーとライターという 2 つのエンドポイントが提供され、異なるポートで PostgreSQL と T-SQL の両方がサポートされます。 Babelfish クラスターへの接続 次のステップは、Babelfish クラスターとの接続を確立し、SQL Server Management Studio (SSMS) を使用して新しいデータベースにスキーマを作成することです。SSMS は SQL Server に接続するための GUI ベースのクライアントツールで、オブジェクトエクスプローラーによるオブジェクトの表示とスクリプト作成は限定的にサポートされています。 Babelfish エンドポイントクラスターと認証情報を入力し、[接続] を選択します。 SSMS で DDL スクリプトを実行する Babelfish のスキーマの再作成 Babelfish でスキーマを再作成するには、以下の手順に従ってください。 次のクエリを使用して、Babelfish と Aurora PostgreSQL のバージョンを確認してください。 -- Check your version SELECT SERVERPROPERTY ( 'babelfishversion' ) AS BabelfishVersion , aurora_version ( ) AS AuroraPostgreSQLVersion , @ @VERSION AS ClassicSQLServerVersion GO SQL Babelfish のエスケープハッチを無視するように設定 – Babelfish は可能な限り、制御フローとトランザクション状態の SQL 動作を模倣します。Babelfish はエラーに遭遇すると、SQL Server のエラーコードと同様のエラーコードを返します。失敗する可能性のあるステートメントを処理するために、Babelfish ではエスケープハッチと呼ばれる特定のオプションを定義しています。エスケープハッチは、サポートされていない機能や構文に遭遇したときの Babelfish の動作を指定するオプションです。以下のステートメントを使用して、すべてのエスケープハッチが厳密な動作を無視するように設定します。 EXECUTE sp_babelfish_configure '%' , 'ignore' , 'server' ; GO SQL Northwind データベースを作成し、T-SQL カタログビューを使用して検証します。 -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL Babelfish と PostgreSQL 間のスキーママッピングを確認してください。この情報は、データロード用の DMS タスクを作成するのに役立ちます。 SELECT pg . dbname AS BabelfishDBName , be . orig_name AS SchemaName , pg . nspname AS PGSchemaNameForDMS , pg . oid , SCHEMA_ID ( be . orig_name ) AS MapsToPGOID FROM sys . pg_namespace_ext AS pg INNER JOIN sys . babelfish_namespace_ext AS be ON pg . nspname = be . nspname WHERE dbname = DB_NAME ( ) ORDER BY SchemaName ; SQL Babelfish クラスターに選択した multi-db または single-db 構成に応じて、異なる結果が表示されます。これは、PostgreSQL がこれらのオプションごとにデータベース名とスキーマ名を内部的に異なる方法でマッピングするためです。 multi-db の Babelfish クラスターの結果: single-db の Babelfish クラスターの結果: 完成したスクリプトを実行して、Babelfish でスキーマオブジェクトを作成します。 Babelfish は現在、DMS での BYTEA データ型を使用したバイナリ、VARBINARY、および IMAGE データ型の移行をサポートしています。Northwind データベーススクリプトを変更して、任意の IMAGE データ型を BYTEA に変更してください。元の Northwind データベースでは、カテゴリテーブルの Picture 列は IMAGE データ型を使用し、Employee テーブルの Photo 列は IMAGE データ型を使用します。最後のスクリプトでは、以下のように検索して置換します。 [ image ] with [ bytea ] /* [ image ] */ Bash テーブルにプライマリキーとユニークキーのみを使用してスクリプトを実行すると、データロードプロセスが高速化され、データロードプロセスが終了したら追加のインデックスと制約を作成できます。 以下のスクリプトを使用して、前のステップで作成したテーブルを検証します。 --using T-SQL view SELECT * FROM sys . tables ; SQL AWS DMS を使用した SQL Server から Babelfish へのデータ移行 AWS DMS バージョン 3.5.1 では、Babelfish マイナーバージョン 14.8 および 15.3 以降の Aurora PostgreSQL のサポートデータタイプのサポートが強化されています。SQL Server ソースエンドポイントと Aurora PostgreSQL ターゲットエンドポイントで DMS の使用を開始する方法は次のとおりです。 AWS DMS コンソールで、ワークロードに応じてインスタンスのサイズを選択して レプリケーションインスタンスを作成 します。 ソースエンドポイントとターゲットエンドポイント を作成します。 ソースエンドポイント – ソースエンドポイントは SQL Server を指している必要があります。 ターゲットエンドポイント – Aurora PostgreSQL ターゲットエンドポイント は Babelfish にデータを移行するための推奨方法です。AWS DMS コンソール、API、または CLI コマンドを使用して AWS DMS ターゲットエンドポイントを作成するときは、次の点に注意してください。 ターゲットエンジンを Amazon Aurora PostgreSQL として指定します。 データベースに babelfish_db という名前を付けます。 エンドポイント設定セクションで、 DatabaseMode を Babelfish に、 BabelfishDatabaseName をターゲットの Babelfish T-SQL データベースの名前に指定した設定を追加します。マイナーバージョン 15.3 および 14.8 より前の Aurora PostgreSQL で Babelfish を使用している場合は、これらのエンドポイント設定を使用しないでください。 レプリケーションタスクを作成 して開始し、ターゲットデータベースに指定されたテーブルのデータをロードします。AWS DMS エンドポイントとしての Babelfish の詳細については、「 AWS Database Migration Service のターゲットとしての Babelfish の使用 」を参照してください。 Northwind データベースを移行するためのタスク設定は次のとおりです。 ターゲットテーブルの準備 -「何もしない」。このモードでは、AWS DMS はターゲットデータベースを変更しません。Babelfish 3.2.0 および 2.5.0 リリースの DMS 3.5.1 の新機能を活用するには、フル LOB モードを選択する必要があります。 テーブルマッピングルール – スキーマ名が ‘dbo’、ソーステーブル名が ‘%’ のような dbo スキーマのすべてのテーブル、またはソース SQL Server データベースの特定のテーブルを含めるには、次のルールを追加します。 変換ルール – multi-db または single-db 構成に応じて必要な変換ルールは次のとおりです。 multi-db モードを使用する場合は、お使いの PostgreSQL スキーマである northwind_dbo と一致するように dbo スキーマの名前を変更してください。 どちらのモードでも、テーブルの名前を小文字に変更します。以下のスクリーンショットは変換ルールを示しています。 テーブル統計を確認して、データのロードを確認します。DMS レプリケーションタスクが正常に完了すると、テーブル統計を表示できます。 あるいは、データベースにクエリを実行してデータを検証することもできます。 SELECT TOP 10 * FROM categories ORDER BY [ CategoryID ] SQL BYTEA データ型を IMAGE に戻す – ほとんどのアプリケーションは BYTEA で正常に動作しますが、IMAGE に戻す必要がある場合は、以下のスクリプトを使用して IMAGE データ型の新しい列を追加、その列にデータをコピーしてから元の列を削除し、最後に元の列名と一致するように名前を変更します。 ALTER TABLE [ dbo ] . [ Categories ] ADD [ PictureImage ] IMAGE NULL ; UPDATE [ dbo ] . [ Categories ] SET [ PictureImage ] = [ Picture ] ; SELECT [ CategoryID ] , CASE WHEN CAST ( [ Picture ] AS Image ) = [ PictureImage ] THEN 'Match' ELSE 'No Match' END AS [ Compare ] FROM [ dbo ] . [ Categories ] ; ALTER TABLE [ dbo ] . [ Categories ] DROP COLUMN [ Picture ] ; -- Rename column EXEC sp_rename 'categories.pictureimage' , 'Picture' , 'COLUMN' ; SQL DMS からデータを読み込んだ後、IDENTITY 列をリセットします。SQL Server では、IDENTITY 列を主キーに使用したり、値の自動インクリメントが必要なその他の列を使用したりするのが一般的です。IDENTITY 列または SERIAL データ型を使用するテーブルを含むデータを移行したら、以下のスクリプトを使用して列の最大値に基づいて PostgreSQL ベースのシーケンスオブジェクトをリセットします。 -- following T-SQL query to generate statements to seed the associated sequence object. USE Northwind ; GO DECLARE @schema_prefix NVARCHAR ( 200 ) = '' IF current_setting ( 'babelfishpg_tsql.migration_mode' ) = 'multi-db' SET @schema_prefix = db_name ( ) + '_' SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name ( tables . schema_id ) + '.' + tables . name + ''', ''' + columns . name + ''') ,(select max(' + columns . name + ') from ' + schema_name ( tables . schema_id ) + '.' + tables . name + '));' FROM sys . tables tables JOIN sys . columns columns ON tables . object_id = columns . object_id WHERE columns . is_identity = 1 UNION ALL SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));' FROM information_schema . columns WHERE column_default LIKE 'nextval(%' ; SQL 次のステートメントは、前のクエリによって生成されます。Northwind データベースに対して実行してください。 -- Generated statements SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.categories' , 'categoryid' ) , ( select max ( categoryid ) from dbo . categories ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.employees' , 'employeeid' ) , ( select max ( employeeid ) from dbo . employees ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.orders' , 'orderid' ) , ( select max ( orderid ) from dbo . orders ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.products' , 'productid' ) , ( select max ( productid ) from dbo . products ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.shippers' , 'shipperid' ) , ( select max ( shipperid ) from dbo . shippers ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.suppliers' , 'supplierid' ) , ( select max ( supplierid ) from dbo . suppliers ) ) ; SQL SSMS のスクリプト生成ウィザードを使用して、次のように作成スクリプトを再生成します。 データベーステーブルだけのスクリプトを作成して、チェック制約、インデックス、トリガーなどを別のファイルに含めます。テーブルはすでに移行されているので、テーブル作成セクションをコメントアウトしてください。最終的なスクリプトには、インデックス、制約、トリガーのみを含める必要があります。Babelfish クラスター内の Northwind データベースに対してスクリプトを実行します。 ビューだけのスクリプトを作成し、Babelfish クラスターの Northwind データベースに対して実行します。 ストアドプロシージャだけのスクリプトを作成し、サポートされていない機能を修正して、Babelfish クラスターの Northwind データベースに対して実行します。 移行の問題と解決策 このセクションでは、以前の移行作業でお客様に見られた、バージョン 3.2 の Babelfish の問題点と考えられる解決策について説明します。 ストアド・プロシージャおよびストアド・ファンクションでサポートされていない機能 アプリケーションのテストをより早く開始するための方法の 1 つは、サポートされていないストアドプロシージャ本体をコメントアウトし、例外を投げたりエラーを発生させたりすることです。ストアドプロシージャのシグネチャ (名前、入力、出力) は引き続き維持されます。理論的には、パラメータ化された正規表現 (グループキャプチャ付き) を書いてこれを行うことができます。以下に例を挙げます。 これにより、サポートされていない機能のサブセットが原因で、解決に時間がかかる可能性がある一部のテスト作業を中断することなく、サポートされていない問題を切り分け、個別にリリースして修正することができます。 トラブルシューティングクエリ これは、Babelfish への移行後に最もよく発生する問題です。これらの問題の多くは、SQL Server と PostgreSQL の間で異なるインデックス戦略が原因であることが多く、PostgreSQL 側の EXPLAIN ANALYZE または SET BABELFISH_STATISTICS PROFILE を使用して診断できます。 よくある問題は、述語 (predicate) の列に式がある場合でも SQL Server はインデックス付き列を使用できるが、PostgreSQL では使用できないというものです。解決策は、PostgreSQL で述語式と一致する式インデックスを作成することです。クエリを分析したら、インデックスと JOIN 条件が適切であることを確認して、考えられる修正を適用してください。次のコードを使用してください。 SET BABELFISH_STATISTICS PROFILE {ON|OFF} を使用して、ステートメントの実行に使用されたクエリプランを表示します SET BABELFISH_SHOWPLAN_ALL {ON|OFF} を使用すると、コマンドを実行せずにステートメントの推定説明プランを表示できます。 次の例では、 BABELFISH_SHOWPLAN_ALL がアクセスパス、インデックススキャン（存在する場合）、および操作のコストの詳細を提供し、パフォーマンスチューニングに役立ちます。 SET BABELFISH_STATISTICS PROFILE ON GO SELECT * FROM test a JOIN test2 b ON a . a = b . a WHERE b . c = 'A926' SQL この例では、パフォーマンスを向上させるために、列 c の test2 にインデックスを作成します。これは実行計画に反映され、操作のコストも削減されます。 CREATE INDEX ix_test_1 ON test2 ( c ) ; SQL 詳細については、「 クエリプランのレビュー 」を参照してください。 統計情報の更新 データベースオブジェクトの統計情報は、クエリのパフォーマンスにとって重要です。データベースオプティマイザーは、これらの統計情報を使用して最適な実行プランを決定し、それをデータ取得に使用します。 この記事の執筆時点では、Babelfish では統計情報の収集と更新はサポートされていません。回避策として、PostgreSQL の機能を使用してテーブルの統計情報を取得してください。 SQL Server command – UPDATE STATISTICS PostgreSQL command – ANALYZE 詳細については、 ANALYZE を参照してください。 テーブルインデックスの再構築 インデックスはクエリのパフォーマンスにとって重要です。T-SQL では、インデックスの再作成に DBCC コマンドまたは ALTER INDEX コマンドのいずれかを使用します。 DBCC DBREINDEX ( 'northwind . dbo . employees’ ) ; ALTER INDEX ALL ON northwind . dbo . employees REBUILD ; SQL これらのコマンドは Babelfish ではサポートされていません。代わりに、PostgreSQL 接続から PostgreSQL ステートメント REINDEX TABLE を使用できます。 REINDEX TABLE dbo . employees’ ; SQL 詳細については、「 テーブルインデックスの再構築 」を参照してください。 Babelfishではサポートされていないコード機能 Babelfish 関数またはコード構文と SQL Server にはいくつかの違いがあります。次の表は、回避策の例をいくつか示しています。 SQL Feature Babelfish Workaround MERGE 文 Compass レポート書き換えオプションを使用すると、MERGE ステートメントの回避策が生成されます。 -MERGE を UPDATE に置き換え、必要に応じて挿入を追加します。 UPDATE LOCATIONS SET LocationName=S.LocationName FROM Locations T, Locations_stage S WHERE T.LocationID=S.LocationID AND ( T.LocationID =3 ) EOMONTH () などの日付関数 サポートされていない日付関数のほとんどは、DATEADD や DATEPART などを使用する Compass rewrite オプションで書き換えられます。 PIVOT clause SUM (WHEN…) 句を使用してステートメントを書き直します。 UPDATE, WITH (Common Table Expression) as target このステートメントは Babelfish ではサポートされていません。必要なすべての条件を WHERE 句に入力して、もとになるテーブルに対して UPDATE ステートメントを手動で書き換えます。 DBCC commands DBCC は、データベースメンテナンスのための SQL Server ネイティブコマンドです。Babelfish の基盤となるデータベースである PostgreSQL データベースエンジンは DBCC をサポートしていないため、Babelfish の場合は PostgreSQL コマンドを特定の目的に使用してください。 DEFAULT パラメータ値を使用したプロシージャまたは関数を呼び出し Babelfishは、プロシージャまたは関数呼び出しでの DEFAULT キーワードをサポートしていません。Compass は、DEFAULT キーワードの代わりに実際のデフォルトパラメータ値を使用して呼び出しを書き換えます。次に例を示します。 –Before rewrite dbo.stored_procedure_1( @variable1, parameter_value, DEFAULT, DEFAULT, DEFAULT) –After Babelfish Compass rewrite dbo.stored_procedure_1( @variable1, parameter_value, /*REWRITTEN*/ 'N/A' /*DEFAULT*/, /*REWRITTEN*/ NULL /*DEFAULT*/, /*REWRITTEN*/ 0 /*DEFAULT*/) まとめ この投稿では、Babelfish Compass ツールと AWS DMS の使用を含め、SQL Server アプリケーションを Babelfish for Aurora PostgreSQL に移行する手順を示しました。サポートされていない機能の詳細を知るために、Babelfish Compass レポートで注目すべきセクションについて説明しました。また、AWS DMS を使用して Babelfish クラスターにデータをロードする方法の詳細も示しました。最後に、Babelfish の移行を加速させるのに役立つ一般的な移行問題と、考えられる解決策について説明しました。 AWS Babelfish チームは、製品を継続的に改善し、定期的に新機能を追加しています。 最新の改善点 については、四半期ごとにリリースされる Babelfish for Aurora PostgreSQL のアップデートを確認してください。 Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL 」を参照してください。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Amit Arora は、AWS でデータベースと分析を専門とするソリューションアーキテクトです。金融テクノロジー、世界のエネルギー分野のお客様、AWS 認定パートナーと協力して、クラウド移行プロジェクトに関する技術支援や顧客ソリューションの設計を行い、お客様が既存のデータベースを AWS クラウドに移行して近代化できるよう支援しています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 今週木曜に AWS Innovate AI/ML and Data Edition が開催されます。オンライン開催で「生成AI 」「AI/MLプラットフォーム」「ビジネスユースケース」のトラックが用意されていますので、ぜひご興味のあるセッションに参加ください。 – AWS Innovate AI/ML and Data Edition 2024 年 2 月 22 日 (木) また、3月2日の JAWS DAYS 2024 も近づいてきましたね。そろそろ残席が少なくなってきているようなので、早めの申し込みをお勧めします。 – JAWS DAYS 2024 – LEAP BEYOND それでは、先週の主なアップデートについて振り返っていきましょう。 2024年2月12日週の主要なアップデート 2/12(月) AWS Wickr now allows you to try premium features for free AWS Wickr で、StandardプランとPremiumプランの機能を最大3ヶ月間無料で試すことができる拡張フリートライアル体験(enhanced free trial experience)が利用可能になりました。Wickrはエンドツーエンドの暗号化されたメッセージングとコラボレーションを支援するサービスです。 Amazon DocumentDB (with MongoDB compatibility) now supports text search Amazon DocumentDB (MongoDB互換性) で、テキスト検索がサポートされました。フィールドにインデックスを作成しておくことで高速なテキスト検索を実現します。Amazon DocumentDB 5.0以降で利用可能であり、現時点では英語のみのサポートです。 Amazon DocumentDB (with MongoDB compatibility) now supports maintenance notifications Amazon DocumentDB にメンテナンス通知の機能が追加されました。これにより、AWS Health DashboardやEメールを通じて、スケジュールされたメンテナンスアクティビティについて通知を受け取ることができるようになります。 AWS AppSync introduces 12 new Amazon CloudWatch metrics for enhanced monitoring AWS AppSync で使用状況とパフォーマンスのより詳細な可視化を実現するために、より多くのメトリクスが提供されるようになりました。利用者のメトリクスの拡張として、リクエストとエラーのカウント、レイテンシー、キャッシュヒット/ミスの詳細なビューといった新しいオプションを含むようになりました。また、ネットワーク/CPUスループットの問題を診断する際に役立つ2つのキャッシュメトリクスも追加されました。詳細は こちらのドキュメント をご覧ください。 2/13(火) Amazon EMR on EC2 now supports retrieval of 10,000 steps completed within last 7 days Amazon EMR Step(ENRのジョブ管理の単位)のAPIであるDescribeStepとListStepで、過去7日間に完了した最大10,000ステップの取得をサポートするようになりました（以前は1,000ステップまででした）。 Amazon Redshift announces support for the INTERVAL data type and Continue Handler statements in stored procedure Amazon Redshiftで INTERVAL データ型がサポートされました。これは期間（レンジ）を表現するための型です。例えば12時間、6週間、1ヶ月などを定義できます。詳細は こちらのドキュメントをご覧ください 。 2/14(水) Amazon OpenSearch Service now lets you update cluster volume without blue/green Amazon OpenSearch Service でブルー/グリーンデプロイメント(Blue/Green deployment)を必要とせずに、クラスターのボリュームサイズ、ボリュームタイプ、IOPS、スループットを変更できるようになりました。ブルー/グリーンデプロイメントの場合、別クラスターを新しい設定で平行して起動してから移行しますが、こういった手間や時間をかけることなく変更が可能になりました。 Amazon OpenSearch Serverless now supports TLS 1.3 and perfect forward secrecy Amazon OpenSearch Serverless で TLS 1.3 が利用可能になり、合わせて perfect forward secrecy もサポートされるようになりました。これは暗号化プロトコルの仕様として、仮に秘密キーが漏洩した場合でも、以前のセッションで暗号化されたデータの安全性を守るように鍵を利用する手法であり、外部からのアタックに対してより堅牢な通信を実現します。 2/15(木) API Gateway now supports TLS 1.3 API Gatewayが TLS 1.3 をサポートしました。これによりラウンドトリップ(1-RTT)の TLS ハンドシェイクを使うことによるパフォーマンスを最適化と、前述の OpenSearch Service と同様に perfect forward secrecy をサポートする暗号のみを使うことで、セキュリティの強化を提供します。 Amazon RDS for Db2 now supports audit logging Amazon Relational Database Service (Amazon RDS) for Db2 がデータベースの監査ログをサポートするようになりました。これを有効化することで、 IBM Db2 ネイティブの監査機能が利用可能になります。監査ログは Amazon S3 に格納されます。詳細は こちらのドキュメントを参照 してください。 2/16(金) Amazon MSK now supports in-place version upgrades for Tiered Storage enabled clusters Amazon MSK がTiered Storage対応クラスターにおいて、インプレースバージョンアップグレードをサポートしました、v2.8.2.tieredを使用しているクラスターは、最新のApache Kafka 3.6.0にアップグレードできるようになりました。v3.6.0はTiered Storageの本番環境グレード(production-grade Tiere)での稼働サポートが含まれています。 Amazon Data Firehose enables selecting a time zone for bucket prefixes when delivering streams to Amazon S3 Amazon Data Firehose (※Amazon Kinesis Data Firehoseから改名されました) で、Amazon S3バケットへのストリーム配信時に、タイムゾーンを選択したバケットプレフィックスの作成が可能になりました。これまでは日本時刻でPrefixを作成する場合にはLambdaとの組み合わせ等が必要でしたら、今回の改善で設定のみで利用可能になりました。詳細は こちらのドキュメントをご覧 ください。 最後に、ちょっと気が早いですが今年のAWS Summitの開催日程が決まりましたので、ご案内します。今年は 2024 年 6 月 20 日（木）～21日（金）の2日間、幕張メッセでの開催です。以下のサイトでEメールアドレスを登録しておいていただくと、申し込み開始時に通知が届きます。 – AWS Summit Japan それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/Twitter – @simosako )

Amazon QuickSight Community は、AWS が提供する Business Intelligence(BI) サービスの QuickSight に関する様々な情報がまとまっており、QuickSight を利用時に出てきた疑問点を質問できるコミュニティです。その QuickSight Community において、2024年2月19日より日本語で質疑応答ができるようになりました。これにより、日本の QuickSight ユーザ間でネットワークを作り、スキルの向上を図ることができるようになります。Amazon QuickSight Community では、様々な学習に役立つコンテンツや、最新の情報などを提供しており、日本語のリソースも Japanese タグにて検索し、参照できるようになっています。 このブログでは、Amazon QuickSight Community の機能について紹介し、Japanese タグの日本語リソース確認方法、Community へのサインアップ方法、日本語での質問の投稿や返答、解決や通知方法について紹介します。 QuickSight Communityとは QuickSight Community にアクセスすると、以下のようなホーム画面が表示されます。 上部メニューバーは、各種リソースにすばやくアクセスできるようにそのリンクを提供しています。（一番左にある Q&A から Japanese（日本語） を選択することにより、以下で紹介する 日本語で質問｜Q&A カテゴリーに直接アクセスすることができます） その時点での注目イベントやアナウンスメントを大きく紹介し、イベントのリンクや、新機能に関する情報をすばやくアクセスできるようになっています。 カテゴリー (Categories)の一覧です。そして、このカテゴリーに 日本語で質問｜Q&A が追加されました！ Question & Answer (英語による質疑応答の一覧。検索も可能） Learning Center (動画やウェビナー、ワークショップなどスキル向上に必要なリソースを集約） What’s New / Blog (最新の製品アップデートやアナウンスメントとブログ) Events (週次・月次ウェビナーやオフラインイベントのサインアップ） Gallery (Arenaで作成したダッシュボードの公開ページ） 日本語で質問｜Q&A (日本語による質疑応答の一覧、検索も可能） 日本語で質問｜Q&A に入ると、日本語で投稿された質問の一覧が表示され、質問のタイトル(TOPIC)、返答数(REPLIES)、View数(VIEWS)、質問に対する最新アクティビティ日付(ACTIVITY)を確認できます。（質問の方法については、次の章で詳しく解説します） Learning Center に入ると、コンテンツのタイプによりさらにサブカテゴリー化されています。その中に 動画 | Japanese Videos というサブカテゴリーがあります。 その中に入ると、2023年に実施した QuickSight RoadShow in 東京のセッションを視聴することができるようになっています。 同じく、今度は Learning Center 内の Getting Started に入り、 Japaneseタグ で検索します。 日本語のコンテンツが表示されます。 How-to Video や Article も同様に Japaneseタグ にて、日本語コンテンツを参照することができます。 また、 What’s new / Blog に入り、同様に Japanese タグ で検索すると、日本語で提供されているブログを参照することができます。 今度は、 Events （イベント）にアクセスします。 同様に Japanese タグ で検索すると、現在日本語で開催予定にしているイベントの一覧を確認することができます。 日本語 Leaning Series の第一回を、3月27日12時から開催予定にしており、昨年末にリリースされた２つの新機能についてデモを交えながら紹介させていただきます。登録リンク先などの詳細情報は このトピック をクリックいただくことで、参照することができます。ぜひご登録ください。QuickSight に関わる日本語のイベントは今後この一覧にて通知する予定です。 実施した日本語Learning Seriesは録画され、 Learning Center 内の Learning Series Videos にアップロードされ、いつでも視聴することができるようになります。 QuickSight Community に参加する QuickSight Community ではログインしない場合でも、提供されているコンテンツをブラウズしたり検索することができますが、アカウントを作成いただくことで、質問をしたり、投稿への返答、コンテンツや返答にLikeをマークすることができるようになります。当 Community はパプリックコミュニティになるので、機密事項や個人情報に関わる情報については記載しないようお願いします。 Community へのサインアップ サインアップするには、以下のステップを実施します。 ホームページの右上にある Sign Up ボタンをクリックします。 既存の Amazon アカウント(米国 amazon.com のアカウント）を使用するか、EメールをIDに新しいアカウントを作成するかを選択します。EメールをIDに新しいアカウントを作成する場合は、Eメールアドレス、ユーザ名、パスワードを設定し、Create your account ボタンをクリックします。 新規にアカウントを作成した場合は、入力したEメールアドレスにアクティベンーションリンクが送られるので、それをクリックするだけで、アカウントの作成が完了します。 日本語で質問を投稿する ログインいただくことで、質問が投稿できるようになります。まず、質問を投稿する前に、検索にて同様の問い合わせが既に投稿されていないかを確認しましょう。 質問を投稿する手順は以下の通りです。 日本語で質問｜Q&A に入り、 ？ New Question  ボタンをクリックします。 投稿する質問内容について、タイトルを入力すると、その内容に基づき、既存の質問の中から類似した質問が右にリスト表示されます。同様の問い合わせがないようなら、投稿する前にタグを設定して下さい。タグを設定することにより、検索がしやすくなり似たような質問を見つけやすくなります。タグは最低２つ設定する必要があります。まず、ドロップダウンに表示されている author , developer , admin の中から該当するものを選択します（ビジュアル作成に関わる場合は author 、API やSDK 等に関する問い合わせの場合は developer 、ユーザやアセット、SPICE、サブスクリプションなどの管理面に関する問い合わせの場合は admin になります） その他のタグは、該当するタグを検索することにより、選択することができます。必ず、 Japanese タグを追加するようにしましょう。  タグの設定が完了したら、質問の内容について記述します。マークダウン記法をサポートする形で、テキスト入力だけでなく、ハイパーリンクやコードなどフォーマット済みテキストの入力、blockquote <引用タグ>の利用も可能で、入力すると、右にプレビュー表示がされるので入力と同時に確認することができます。 イメージのスクリーンショットもコピー＆ペーストで可能です。 質問内容の入力が完了したら、その下にある + New Quetion ボタンをクリックします。 日本語の質問に応答する ログインいただくことで、既に投稿されている質問に応答することができます。遠慮せずに積極的に返答をしたり、 (like this post)マークを提供し、Community を盛り上げていきましょう！ 返答は、 Reply ボタンをクリックします。 画面下に、返答入力用のフォームが提示されるので、返答内容を入力し、 Reply ボタンをクリックします。 特定の返答に対して応答するには、各返答下にある Reply アイコンをクリックすることで応答することができます。 また、気に入った返答に対しては、 (like this post)マークをクリックしましょう 日本語で投稿した質問への対応 投稿した質問に対しては、通知設定をすることができます。投稿した質問下にある (通知ベル)表示をみると、デフォルトでは Normal 設定となっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。クリックすることで、以下のような通知設定に変更することができます。 Watching ：全ての返答が新規にあった場合に通知され、その返答数がリスト上に明示されます Tracking ：返答数がリスト上に明示され、Normal設定と同様名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知されます Muted ：何も通知はされなくなり、最新リストからも表示されなくなります また、質問を投稿し、もらった返答により解決した場合、その返答に Solution マークを付与することができ、今後同じような質問をしたいユーザに対して的確な回答を明示することができます。ぜひ、積極的に Solution マークを付与しましょう！ 自分が投稿した質問に対して、的確な返答があった場合は、その返答下にある Solution マークをクリックします。 以下のように Solution マークが変わります。 さらに最初の質問内に、その返答内容が明記され、解決したことが一目で分かるようになります。 “日本語で質問｜Q&A” や “Japanese”タグに通知設定する 特定のトピック（質問）だけでなく、カテゴリー自体や特定のタグに対しても通知設定をすることができます。 カテゴリー自体に通知設定をする場合は、 日本語で質問｜Q&A に入り、画面右に表示される （通知ベル）アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching ：このカテゴリーにトピックス（質問）が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます。 Tracking ：名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます。 Watching First Post ：トピックス（質問）が新規に投稿されると通知されますが、その返答に対しては通知されません。 Muted ：何も通知はされなくなり、最新リストからも表示されなくなります。 Japanese タグに対して通知設定をする場合は、以下の手順で設定できます。 右上にあるプロファイルアイコンの左にあるアイコンをクリックし、 All tags を選択します。 タグの一覧が表示されているので、対象とする Japanese を選択します。 表示された画面の右にある （通知ベル）アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching ：このタグにトピックス（質問）が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます Tracking ：名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます Watching First Post ：トピックス（質問）が新規に投稿されると通知されますが、その返答に対しては通知されません Muted ：何も通知はされなくなり、最新リストからも表示されなくなります まとめ このブログでは、Amazon QuickSight Community について紹介し、サインアップの方法、日本語での質疑応答の方法、質問に対する解決設定方法、各種通知設定方法について紹介しました。QuickSight Community は、QuickSight を学習する上で必要な情報を集約しており、さらに日本語で利用することにより、日本での QuickSigh tユーザ間でネットワークを構築できる場となります。今後さらに日本語によるリソースを増強し、日本語 Learning Series についても定期的に開催していく予定です。ぜひ、この QuickSight Community を積極的にご活用ください。 ３月：日本語Learning Series 登録ページ

AWS は、プログラミング経験がない方でも生成AIアプリ開発に参加できるハッカソン「PartyRock Hackathon」を 2 月より開始しました。 すでにAWS は 2023 年 11 月に全ての builder が生成 AI をスタートするための”プレイグランド（遊び場）”である「PartyRock」を発表し(*1)、多くのお客様に生成 AI アプリ開発の楽しさを体験していただいています。Amazon Bedrock で動く PartyRock を使うことで、プログラミングの知識の有無にかかわらず、どのようなアプリを作りたいかを文字で入力するだけで、あっという間に生成 AI アプリを構築することができます（*2）。さらにこの開発体験を通じて「プロンプトエンジニアリング」についても自然に身につけることができます。しかも利用は無料。どなたでもお気軽にお試しいただくことができます。 そして今、このPartyRock 上でアプリを開発するハッカソン「 PartyRock Hackathon 」が世界規模で開催されています。すでに 4000 名近い方が参加し、多数のアプリが日々生み出されています。ご興味のある方はぜひ、 PartyRock Hackathon 公式サイト （英語）へお立ち寄りください。 (*1) AWSブログ「Amazon PartyRock の発表」 」 (*2) AWSブログ「PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス」 参考資料） Step by Stepで学ぼう！ PartyRockを利用した 生成 AI アプリの作り方

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 ここでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめていきます。 少し発展的な内容となっておりますので、ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、共同利用方式におけるコスト・セキュリティ管理について扱っていきます。 共同利用方式になったのでコスト・セキュリティについて把握できなくなり困っている自治体の方や、共同利用方式でアプリケーションを提供するベンダーの方にお役立ていただける内容となっています。 共同利用方式の場合にコスト・セキュリティ状態をどのように管理できるか？ 共同利用方式では、自治体は AWS アカウントの運用管理を個別に行わない前提となっており、 AWS アカウントのユーザーが払い出されないため、自治体職員はコストなどの情報を確認できません。 共同利用方式を SaaS と捉え、インフラのコスト・セキュリティの管理をパッケージベンダーへ一任するという考え方もあります。 一方で、従来通りインフラのコスト・セキュリティの情報を確認したい自治体の方もいらっしゃると思います。 AWS では、一部のコスト・セキュリティの情報に関しては、専用のダッシュボードを Amazon QuickSight で作成することで、AWSアカウントのユーザーを作成することなく自治体職員の方が確認できます。※ ここでは上記のニーズに対応できるよう、インフラのコスト・セキュリティの情報を Amazon QuickSight で可視化する方法について説明します。 ※ ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。 コスト ここでは、以下の 2 つのケースについてコストを可視化する方法について説明します。 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式) 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式) 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 1 つの AWS アカウントに 1 つの団体のリソースしか含まれないアカウント分離方式の場合、Cost and Usage Dashboard (CUD) , Cost and Usage Dashboards Operations Solution Dashboard (CUDOS) を利用すれば容易にコストに関する情報をダッシュボードに表示できます。 詳しい情報は 簡単に構築できる AWS コスト可視化ダッシュボードのユースケース – Cost and Usage Dashboard (CUD) と CUDOS – をご覧ください。 CUD はセットアップが簡単な分 CUDOS に比べ表示できる情報量が少なく、CUDOS は表示できる情報量が多い分セットアップに AWS CloudFormation 等の利用が必要という特徴があるため、用途に合わせてご選択ください。 以下の URL に CUDOS のダッシュボードのサンプルが公開されています。 CUDOS サンプルダッシュボード: https://cid.workshops.aws.dev/demo?dashboard=cudos 例えば、Compute のタブでは月毎の Amazon EC2 の利用料の推移を確認できます。 図 1) CUDOS の Compute ダッシュボードの例 1 つのAWSアカウントが複数団体のリソースを含む場合 ネットワーク分離・アプリケーション分離の方式を採用する場合や、共用リソースがある場合は費用按分について考える必要があります。 費用按分の戦略 費用按分の方法の考え方の一例として「リソースの Owner が明確なものはコスト配分タグで費用を按分し、タグ付け不可の場合・複数の団体で同じリソースを共用する場合は利用量・団体の人口規模等の指標で按分する」という考え方があります。 ここでは、上記の方法で費用按分を実施する方法の概要について説明します。 なお、ガバメントクラウドにおいて、自治体が利用する AWS アカウントは AWS Organizations のメンバーアカウントにあたるため、コスト配分タグコストタグを有効化できません。 そのため、管理アカウントで既に有効化されているタグを利用してコスト按分を行う必要があります。 既に有効化されているコストタグについては GCAS (Government Cloud Assistant Service) の記載をご参照ください。 タグ付け戦略 団体名のタグ タグ付け可能なリソースは団体ごとにタグ付けを行います。 タグ付け可能なリソース一覧は AWS Resource Groups とタグエディタで使用できるリソースタイプ や リソースタグの API リファレンス をご参照ください。 AWS CloudFormation・AWS CDK 等の IaC ツールを利用している場合、スタック単位でタグ付けが可能なため、簡単にタグ付けを行うことができます。 具体的には Owner=<団体名> といったタグを付けておきます。 タグ付け可能ではあるものの、複数の団体で同じリソースを共用する場合は按分方法ごとにタグを付けていきます。 按分方法ごとのタグ 複数の団体で共有するリソースは按分方法ごとにタグを付けます。 例えば、VPC FlowLog・API Gateway・ELB 等のアクセスログから各団体がどの程度システムを利用しているか計算し、費用按分する方法があります。 「API Gateway のアクセスログから団体ごとの利用料を算出するリソース」は Owner=divideByApi というタグを付けます。 他の按分の方法として、利用団体の人口で按分する方法が考えられます。例えば、更新サーバー (WSUS) などは団体規模が大きいほど更新対象のサーバー台数が多くなります。 その場合、団体規模とシステムの利用比率がおおよそ同じになることが多いため、団体の人口比で利用料を割ることを考えます。 この場合、 Owner=divideByPopulation というタグを付けます。 集計・可視化 ここではタグ付けしたリソースのコストを集計・可視化する方法について説明します。 AWS Data Exports を利用すると請求データを Amazon S3 へエクスポートできます。 Amazon Athena の データベースとテーブルの作成 の手順に従うと、Amazon S3 に配置してあるデータに対し、Athena SQL を利用した処理ができるようになります。 以下の計算を Amazon Athena で行い、新しいテーブルとして保存します。 団体名のタグ ごとにコストを集計 按分方法ごとのタグ で集計したコストをタグの値ごと合計し、按分方法に沿って計算・1 で計算した各団体のコストに加算 タグ付けできないコストはあらかじめ決めておいた按分方法で費用を按分し、2 のコストへ加算 図 2) 特定のタグがついたコストのみ集計して QuickSight で可視化した例 その後、 Amazon Athena データを使用したデータセットの作成 に従って、Amazon QuickSight から Amazon Athena のデータを参照します。 最後は Amazon QuickSight でのデータの視覚化 の手順に従い各自治体向けのダッシュボードを構築します。 Amazon QuickSight はダッシュボード単位で認可の制御ができるため、各自治体のユーザーごとに閲覧可能なダッシュボードの設定ができます。 以下の画像は上記と同様の方法で AWS Deta Exports により出力したデータから、特定のタグがついている料金のみ集計し、ダッシュボードを作成したものです。 セキュリティ ここでは、以下の 2 つのケースについてセキュリティを可視化する方法について説明します。 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式) 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式) 例として以下のようなダッシュボードを構築できます。（例は簡素なものとなっておりますが、簡単に表やグラフを追加することができます） 図 3) Security Hub の検出結果を QuickSight で可視化した例 図 4) Trusted Advisor の検出結果を QuickSight で可視化した例 S-1. Security Hub の結果を QuickSight で可視化する方法 (1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合) 以下の手順を踏むことによって、 Security Hub の検出結果を QuickSight で可視化することができます。 1. GitHub 上にある aws-security-hub-findings-export のソリューションを利用して Security Hub の検出結果をリアルタイムに S3 にエクスポートします。 2. Security Hub のエクスポート結果の json ファイルでは、キーに Amazon Athena で処理できない記号が含まれています。詳しくは、 ドキュメント をご参照ください。このため、 AWS Glue で Glue ETL Job をセットしてスキーマを変更する必要があります。具体的には、 DynamicFrame.apply_mapping() メソッドを使用して、フィールドの名前やフィールドタイプを変更しましょう。コードの例は ドキュメント に存在するので、ご参照ください。 3. AWS Glue Data Catalog Table を作成します。クローラーを使ってテーブルを構築し、スキーマを変更した後の S3 上のファイルからデータを読み込む方法が便利です。アカウントや日付でパーティション分割されているため、[Create a single schema for each S3 path (各 S3 パスの単一のスキーマを作成する)][Update all new and existing partitions with metadata from the table (すべての新規および既存のパーティションをテーブルからのメタデータで更新します)]にチェックを入れて単一のスキーマで読み込むことを推奨します。 4. QuickSight の Athena データソースを選択し、Athena ワークグループと Glue カタログ、データベースを指定してデータを読み込みます。 5. QuickSight を利用して、必要なデータを表やグラフで表示します。 S3 のクロスアカウントレプリケーション機能を使って、 S-1. の手順 1 で S3 にエクスポートしたデータをアカウントを跨いでレプリケーションすることもできます。詳しくは ドキュメント をご覧ください。 1 つのAWSアカウントが複数団体のリソースを含む場合 Security Hub の検出結果がリソースに紐づいている場合、Secuirty Hub のエクスポートされた検出結果にはそのリソースにつけられたタグの情報も含まれているため、リソースに対して自治体ごとにタグをつけておけば、その情報を用いて QuickSight 上でフィルタリングすることができます。タグの情報は、Resources フィールドの中の Tags フィールドに含まれています。 タグ付け戦略に関しては、コストの章をご覧ください。 ガバメントクラウド上のTrusted Advisor の検出結果を QuickSight で閲覧する方法 AWS Organizations 上のアカウントの Trusted Advisor の検出結果を QuickSight 上に集約する方法として、一般的には Trusted Advisor の組織ビュー や、 Cloud Intelligence Dashboard の一つである Trusted Advisor Organizational (TAO) Dashboard があります。 しかし、ガバメントクラウド上では、AWS Organizations のマネジメントアカウントにアクセスできないため、これらの方法が使えません。 今回は、以下の条件下で AWS Organizations 配下にある特定のメンバー AWS アカウント上の QuickSight に、Trusted Advisor のデータを集約し可視化を行うことを考えます。 AWS Organizations のマネジメントアカウントにはアクセスできず、さらに、デジタル庁が適用していサービスコントロールポリシーの範囲内の権限しか使ってはいけない。 Organizations 配下にある対象ではないアカウントのデータにアクセスしない。 各メンバーアカウントにはビジネスプラン以上のサポートプランが設定されている。 なお、Trusted Advisor の検出結果はアカウント全体の状態を表すものでありリソースに紐づけられたタグの情報が含まれないため、同じアカウントに異なる自治体のリソースが含まれている場合 (ネットワーク分離方式・アカウント分離方式) もアカウント単位の情報を確認することになります。 以下の手順で、これを実現することができます。 集約元となるアカウント（QuickSight を構築するアカウントを含む）の北部バージニア (us-east-1) リージョンでこちらの yaml ファイル を用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。 QuickSight を構築するアカウントの、サービスコントロールポリシーで使用が認められているリージョンでこちらの yaml ファイル を用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。 Accounts-Collector-Function-<スタック名>という名前の Lambda 関数において、AWS Organizations から対象となるアカウント ID やアカウント名を取得している部分を、直接指定するように書き換えます。環境変数に記載してそれを取り込むことをお勧めします。 EventBridge が定期的に発火して、Trusted Advisor のデータを収集します。すぐに発火させたい場合は、Scheduler-For-Accounts という EventBridge ルールを無効化して有効化してみてください。 QuickSight Enterprise Editionを有効にします。 Amazon QuickSight にアクセスして、管理者ユーザーを作成し、ユーザー名とアカウント名をメモします。 集約先となるアカウントのサービスコントロールポリシーで使用が認められているリージョンで、こちらの yaml ファイル を用いて CloudFormation スタックを作成します。上二つの確認事項には「yes」と回答し、先ほどメモしたユーザー名をUser name of QuickSight userに、Trusted Advisor のデータが入っている S3 バケット名を Path to Optimization Data Collection S3 bucket に記入します。Deploy TAO Dashboard を「yes」にして、スタックを作成します。 スタックが作成されると、TAODashboardURL が出力されます。ここにアクセスし、有効な QuickSight ユーザーでログインすると、ダッシュボードを見ることができます。 まとめ 本ブログでは、共同利用のセキュリティ・コスト のダッシュボードについて取り扱っていきました。ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。 共同利用方式において、自治体の方へどんな情報を提供するか・実装方法はどうしようか迷われていた方の参考になっていれば幸いです。 自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 押川令（Ray Oshikawa） パブリックセクターの自治体担当ソリューションアーキテクトです。 最近は自治体関連システムを担当されている企業様のサポートや、自治体業務システムのガバメントクラウドへの移行支援を中心に活動しています。   松本 侑也 (Yuya Matsumoto) パブリックセクターの自治体担当ソリューションアーキテクトです。 最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。

はじめに このブログ記事では、 CSC Generation Holdings, Inc. (CSC Generation) が、複数のブランドにわたるカスタマーサービス運営をサポートするために、Amazon Connect に移行した理由をお伝えします。CSC Generation は、 One Kings Lane や Sur La Table などの小売業者を高パフォーマンスなデジタルファーストブランドに変革させるマルチブランドの技術プラットフォームです。これらの小売業者の主な顧客は、上質な生活環境の演出に情熱を注ぐ個人、家族です。CSC Generation によるカスタマーサービス運営は、音声、チャット、Eメール、Web チケットを介して、各ブランドにさまざまなレベルのサポートを提供しています。これらのブランドはそれぞれ独自のサポートチャネルとキューを持っていますが、一部はオフィスを共有しています。 小売ブランドをデジタルファーストにするために、CSC Generation は柔軟で、エージェントの効率性と顧客のセルフサービス体験を改善するための組み込み AI 機能を備えたコンタクトセンターソリューションが必要でした。その結果、CSC Generation の開発チームは、独自の AI 駆動型 BPO 向上・生産性ソフトウェアである SnapBPO を構築しました。CSC Generation のチーフテクノロジストである Andrew Templeton との対談を通して、Amazon Connect への移行することで CSC Generation と同社の SnapBPO ソフトウェアが捉えた課題と機会について掘り下げます。 CSC Generation が直面していたカスタマーサービスの課題と、Amazon Connect への移行によってつかんだ活用機会は何でしたか ? CSC Generation の各ブランドと子会社には、インタラクティブ・ボイス・レスポンス (IVR) 構造を含む、顧客との対話を処理するための異なるワークフローがあります。Amazon Connect を使用することで、これらの構成とビジネスルールの全範囲を1つのコンタクトセンターソリューションにエンコードできることを知っていました。これは、ブランド全体で今後の作業をより効率的にする大きな機会でした。SnapBPO ソフトウェアを介して、「私の注文した商品の状況は ? 」といった電話問い合わせの自動化や、リアルタイムでの顧客情報の提供など、顧客向けの高度な新機能とエクスペリエンスを簡単に追加することもできます。 顧客にセルフサービスを提供することが CSC Generation にとって重要ということですね。セルフサービスを貴社業務にどのように組み込んでいますか？ CSC Generation のそれぞれのブランドの顧客向け Web サイトでのセルフサービスに加えて、最も一般的なワークフローでは、 IVR で番号プロンプトを表示することなくすべて音声で処理を提供できるようにしています。これにより、お客様は必要な支援について自分の言葉で説明できます。 SnapBPO ソリューションに Amazon Lex を組み合わせることで、最も一般的なお客様からのご質問に完全な文章で回答しています。 結果として、「私の注文した商品の状況は ? 」といった問い合わせの平均対応時間 (AHT) が 1 分未満に短縮されています。 あなたは生成 AI の可能性を実験しています。 顧客へのセルフサービス体験を設計および提供する方法がこのテクノロジーによってどのように変化したかを共有していただけますか ? 顧客の様々な質問表現すべてを知る必要はなくなりました。 生成 AI を使用することで、Amazon Lex で発話のリストを事前に生成できるうえ、顧客からの問い合わせを読み取り理解するために、より強力だが低速に実行される NLP モデルを使用できます。 たとえば、顧客が「私の注文した商品の状況は ? それと、タオルの方は速達にしたか忘れました」という 2 つの異なる質問をした場合、SnapBPO セルフサービスボットは各問い合わせを識別し、「 9 月 3 日のご注文は明日郵送で配達されます。タオルは速達を選択されています。他に何かお手伝いできることはありますか ? 」と応答できます。 さらに、検索拡張生成 (RAG) を使用することで、製品、ビジネス方針、顧客の注文履歴や行動に関するすべての情報をインデックス化しています。 これにより、リアルタイムで顧客との会話に関連するコンテキスト情報を迅速に検索できるようになりました。 生成 AI を活用したセルフサービス体験などのテクノロジーを用いる場合、当然、顧客からの信頼性の問題が生じます。お客様からの信頼を確保するためにどのような対策を講じていますか ? Amazon Lex は私たちの文章の分類、顧客からのフレーズの書き起こしを AWS のセキュリティとプライバシー制御のもと実行しています。 このコンテキストでの生成 AI の利用は、人々の想像よりありふれたユースケースです。私たちは主に「これはどのような文章なのか」や「注文番号は発話された番号の、一つ目なのか二つ目なのか」といった、質問の解釈に関心があります。 このように AI を利用し、注文番号や顧客名などの個人を特定できる情報を置き換えることで、機密情報は共有せず、文の構造のみを共有して最高のモデルを活用しています。 エージェント体験も、CSC Generation のカスタマーサポート戦略にとって重要です。Amazon Connect への移行は、エージェントのオンボーディングと全体的なサービス提供コストにどのような影響を与えましたか ? オンボーディングの観点からは、 AWS Identity Center とのシングルサインオンにより、IT チームにとっての管理が容易になりました。アプリケーションにエージェントをユーザーとして追加するだけで、 Security Assertion Markup Language (SAML) 連携によって同期されます。コールセンターを Amazon Connect エージェントワークスペース に移行するにともない、カスタマーサービスエージェントは統一されたインターフェースだけを覚えればよくなりました。エージェントはシーズンによってさまざまなブランド間を移動することがあるため、このアプローチは労働力の管理を簡素化します。コストの観点からは、エージェント 1 人当たりの通信費は、SnapBPO AI ソフトウェアと Amazon Connect を使用したことで、以前使用していたソリューションと比較して約 80% 低くなっています。 ブランド間での統一されたエージェント体験についてのビジョンの詳細と、これが平均処理時間(AHT)にどのような影響を与えるかを共有いただけますでしょうか ? キューのタイプとワークフローを、特定のブランドのポリシーに沿ってパラメータ化することで統一しました。 Amazon Connect エージェントワークスペースを使用することで、エージェントは、顧客が何のために問い合わせてきたのか、IVR がどのように対応したのか、過去の顧客とのやり取り履歴を確認できます。 このコンテキストにより、エージェントはよりパーソナライズされた形で顧客の質問に答えることができ、エージェントによる対話支援の平均処理時間 (AHT) を短縮できます。 また、エージェントはリアルタイムで内部のナレッジベースにアクセスして顧客の質問に答えたり、 Amazon Connect Tasks を使用してエージェントワークスペースから直接メールを表示、返信したりすることができます。 当社のブランドの1つでは、エージェントワークスペース内で Amazon Connect カスタマープロファイル と ケース を利用し始めました。これにより、お客様からの問い合わせを簡単に追跡および処理できます。エージェントは、注文ステータスの確認、破損商品の報告、価格調整、注文キャンセルと返品、製品に関する一般的な問い合わせなどのサポート要求をより適切に行うために、お客様とその短期または長期にわたる問い合わせの全体像を把握できます。Amazon Connect のこれらの機能を他のブランドでも早速有効化することを楽しみにしています。 CSC Generation における大きなテーマの 1 つは、テクノロジー、エージェント体験、データを統一することのようです。CSC Generation のブランドにまたがって、カスタマーサービスデータやマージン報告を統一することの価値をどのように見ていますか ? CSC Generation の傘下にあるブランドごとのスキーマレジストリとして機能する、内部データ管理プラットフォームにデータを保存し始めました。 例えば、One Kings Lane と Sur La Table はそれぞれ注文スキーマをデータ管理プラットフォームに登録しています。 生成型AIは、同じ論理型 ( 例 : 注文明細 ) の断片化されたスキーマを標準フォーマットに統一するために使用されます。 このデータを統一することで、個々のブランドは CSC Generation の傘下にあるすべてのブランドからの情報に選択的にアクセスできるようになり、チャットボットやエージェントが他のブランドでの購入内容に基づいて顧客にオファーをカスタマイズできるようになります。 さまざまなソースからのデータを統合することで、初期の顧客とのやり取りがより明確な視点で捉えられるようになり、ブランドが顧客基盤と最も親和性のある戦略やタッチポイントを特定できるようになります。これらの洞察は、広告の効果測定、顧客嗜好の理解、 SKU の収益性に関心のあるステークホルダーにとっての包括的な分析に不可欠です。 加えて、データを統合することでコールセンターの運用が大幅に改善されました。この新しいアプローチにより、緊急の問題により効果的に対処し、顧客からの問い合わせに対応し、サービス品質を向上させることができます。最終的に、この新しいアプローチにより、コールセンターがコストセンターであるだけでなく、収益源となる可能性があることが証明されるでしょう。 これらのカスタマーサポートバックエンドの変更は、顧客ロイヤルティと追加販売にどのような影響を与えますか ? 私たちが特に取り上げたい例の 1 つは、家具ブランドの 1 つです。 このブランドでは、優先的なセールスへのアクセス、新製品の早期アクセス、キャッシュバックプランを提供する有料の顧客ロイヤルティプログラムを開始しました。 ロイヤルティプログラムへの加入が見込まれる顧客とカスタマーサービスチームが対話する際、有料プログラムへの加入を二桁台半ばの割合で実現できています。 また、そうした顧客の生涯価値は、同じグループの他の顧客の 2 倍となっています。 今後、CSC Generation とその SnapBPO ソフトウェアは Amazon Connect をどのように利用するつもりですか ? 生成 AI をより多くのユースケースに展開するための計画はどんなものですか ? 生成 AI の可能性にわくわくしています。 Amazon Connect でこのテクノロジーの利用を拡大する予定です。チャットとボイスチャネルのエージェントへのレスポンスを提案するために生成 AI を使用するだけでなく、ビジョンを広げたいと考えています。「生まれた場所は ? 」といった従来のセキュリティ質問から、「 3 日前に購入したものは ? 」といったダイナミックで取引ベースの質問への移行によって、ユーザーを認証することも目指しています。この変更により、各個人のユニークな最近の取引に関連する答えを必要とすることで、顧客体験を高め、セキュリティを強化します。構造化されていないデータを活用することが、顧客をより深く理解する鍵となります。 SnapBPO ソフトウェア、コールセンター、カスタマーサービス運用のためのソリューションをついに見つけられたことを嬉しく思います。これは、ポートフォリオ企業内のさまざまな運用ドメインにおける卓越性と標準化を追求する CSC Generation ミッションを反映するものです。 結論 CSC Generation とその AI ベースの SnapBPOソフトウェアに、Amazon Connect は頻繁なリリースと改善を通して、 AI と自動化を利用してカスタマーサービスを改善するだけでなくコストを削減し成長を促進する機会を提供しています。 セルフサービス体験を統合し、エージェントの効率化を支援するために AI などの組み込み機能を活用することで、 CSC Generation はカスタマーサービスの運用を変革し、より効率的かつ効果的なものにすることができました。 世界中のビジネスがAmazon Connectをどのように利用して、顧客とエージェントのエクスペリエンスを改善しているかをご覧ください。 CSC Generation Holdings, Inc. (CSC Generation) について CSC Generation は、小売業者を取得し、それらを高パフォーマンスのデジタルファーストの消費者中心のビジネスに変革するマルチブランド技術プラットフォーム企業です。CSC Generation は、強力なマーケティングインテリジェンス、サプライチェーンおよび流通チャネル、優れたカスタマーサポート、そして実店舗およびオンラインとカタログ販売の経験により、小売業界の他社と一線を画しています。 Andrew Templeton Andrew Templeton は、構築、フリートロジスティクス、eコマースなどのさまざまな業界における革新的な AI 駆動の自動化プロジェクトの設計と実行を専門とする、P/L 経験を持つシーズンされた技術リーダーです。顧客サービスの自動化と品質問題の検出のイニシアチブを特に率いており、TypeScript でのソースコードリファクタリングのための高度なエンジンを開発するとともに、動的にスケーリングするデータ統合プラットフォームの確立にも貢献しています。技術的知見は広範囲に及び、TypeScript、Python、Ruby や React、Vue といったクライアントサイドフレームワークに加え、Amazon Web Services の上級認定も保有しています。 Chris Phan AWS テクノロジーを専門とするテクニカルアカウントマネージャーとして、クリスはテクノロジーとフロントエンド開発への情熱で、技術的な専門知識とクライアントサポートのダイナミックなブレンドを提供しています。クラウドベースのウェブソリューションの常に進化する領域において一人一人へのガイダンスと継続的な学びを通じて、顧客がユニークな課題に対処し戦略的な成功を達成するのを支援することに専念しています。   翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本投稿は小田急アプリや他社サービスなどに連携する列車遅延予測機能の追加とその精度向上の取り組みについて、実際に開発と構築をされました小田急電鉄株式会社経営戦略部の落合様に寄稿いただいたものです。 はじめに 鉄道各社ではより便利に鉄道をご利用いただくため、列車の走行位置や、個々の列車の遅れの情報を各社のアプリ等を通じてリアルタイムに配信しています。弊社も2017年に小田急アプリをリリースし現在に至るまで、多くのお客さまにご利用いただいております。リリース当初は「現在の遅れ」をご案内する機能しかありませんでしたが、2022年より遅延予測機能を追加し、「現在の遅れ」に加え、「各駅の到着見込み・発車見込み時刻」をご案内しています（図1）。加えて、昨今では様々な経路検索サービスにおいても、各列車の遅れに関する情報を表示して頂けるようになるなど、鉄道のリアルタイム情報を広くご利用いただけるようになってきました。 本ブログでは、AWS サーバーレスサービスと機械学習サービスを活用した、小田急アプリにおける、列車遅延予測システムと、予測精度向上に関する取り組みについてご紹介いたします。 列車の遅延 欧州のように大規模な鉄道ネットワークで発生する遅延と比較すると、日本の鉄道で発生する遅延は小規模であることが多いものの、様々な事由により、日々大小さまざまな遅延が発生しています。このため、必要により列車を運転する順序を変更したり、運転する区間を変更したりするなど、各列車の遅延が少なくなるよう運転整理を行っているものの、2本のレールの上に、たくさんの列車が次々と走行しているため、ときに道路と同じように渋滞が発生してしまうこともあります(図2)。このため、“今時点”では定刻通り運転していても、先を走行している列車に遅れが発生していると、その影響を受けて、のちに遅れが発生するという現象もしばしば発生してしまいます。 そこで、現在の遅れをご案内することはもちろんのこと、その遅延がこの先減少していくのか、あるいは拡大してしまうかを精度高く予測しご案内をすることで、ご利用のお客さまのご不便の度合いを少しでも解消したいと考えています。 AWS Lambda とAmazon S3 で構成した列車の遅延予測の仕組み 図3に現状の小田急アプリ・列車遅延予測機能の構成図をお示しいたします。当社社内のネットワークから閉域網により Amazon VPC と接続し、AWS PrivateLink を通じて、Amazon S3 のバケットに最新の列車の走行位置と、この先の列車の運転順序に関する情報をほぼリアルタイムに連携しています。これらのデータを AWS Lambda で加工し、Amazon Aurora に格納し、小田急アプリ向けに配信しています。 遅延予測関連のシステムについては、構築当初から連携する経路検索各社様へのデータ配信も視野に入れ、小田急アプリの配信基盤と別に、当社の MaaS プラットホームである MaaS Japan 上に構築しています。 遅延予測の機能は、AWS Lambda と Amazon S3 を使用するのみの非常にシンプルな構成で、列車の在線位置から「いつ、どこに、どの列車がいたか」という情報を取得し、時系列を整えた在線履歴データを Amazon S3 に出力する関数と、在線履歴データと列車の運転順序に関する情報から、15秒に1回、この先の列車の運行をシミュレーション予測し、同じく予測結果を Amazon S3 出力する関数の2つからなります。 用いた予測アルゴリズムもシンプルです。各列車の運行を各駅への到着、発車、通過という事象ごとにノードとして表現します。続いて各ノード間に必要な最低限の時間（駅間の走行に必要な時間・駅に停車している時間・列車と列車の間隔に必要な時間）を重みとした有向アークで結び、グラフネットワークを構成します（図4)。このグラフネットワークの各ノードの重みの和が最大の値（すなわちすべての制約を満たす最短の時刻）を最長径路探索により求めることで、予測時刻とするというものです[ 参考文献 ]。 従来の課題 – さらなる精度の向上に向けて 「現在の遅れ」のみご案内していた、遅延予測機能導入以前と比較すると、よりきめ細やかなご案内ができるようになったものの、課題がありました。それは、「駅に停車している時間」が毎日同じ時刻に発車する同じ列車でも、実は日々まちまちであるという点です。 自明ながら、駅に停車している時間が（計画よりも）長ければ、その先の遅延が拡大しますし、駅に停車している時間が（計画よりも）短ければ、この先回復できる見込みが生まれます。 図5は実際のばらつきを散布図に示したものです。横軸に当社の湘南台駅到着時の遅れを、縦軸は4駅先（所要時間約10分）の藤沢駅到着時の遅れの大きさを示しており、双方の関係性をプロットしています。例えば湘南台駅に30秒の遅れで到着した列車に着目すると、藤沢駅の遅れが -15秒（すなわち少々早着）～ 120秒の間まで存在することがご覧いただけます。 各システムでご案内できる見込み時刻は１つであることから、現状では「発車見込み時刻をご確認いただいた際、乗り遅れてしまわないこと」を優先し、遅延予測をする際には若干短めの数値を採用してきました。このため、今度はご乗車しているお客さまから、「実際はもっと遅れるのに、いつも回復する見込みの案内が出ていて不便」というご意見を頂いてしまうこともありました。 そこで、2023年度、新たな仕組みを導入することとしました。 機械学習を用いた停車時分予測モデルの導入 遅延予測精度の向上を図るため、過去の運行実績を学習データとして、リアルタイムに各駅の停車時間を予測できる、相関ルールをベースとした機械学習モデルの導入を検討しました。具体的には、連続する数駅分の停車に要した時間のみの情報から、その先各駅の停車に必要な時間を確率的に予測するというモデルです。 実施に当たっては、図3に示した通り、AWS で用意されている分析機能と、機械学習実施環境の基礎的な機能を用いて、以下の手順で実施しています。 Amazon S3に蓄積した運行実績を、Amazon Athena を使って整形し、訓練用のデータセットを抽出 Amazon SageMaker に用意されている Notebook 内で、訓練用データから Apriori アルゴリズム[ 参考文献 ]を用いて相関ルールを抽出したのち、予測に有用なルール Map ( JSON ファイル)を作成 リアルタイム情報と、出来上がったルール Map を用いて、駅での停車に必要な時間を予測、結果を Amazon S3 に出力する機能を AWS Lambda にて実施 予測した停車時間を加味して運行予測シミュレーションを実施 この機械学習モデルの導入を検証したところ、予測精度の向上を実現することができる見込みが立った（図6）ため、現在は一部の列車・区間で運用しています。 今後、適用範囲を拡大するとともに、AWSの各種機能を活用し、一定期間経過後に自動的に再学習し、モデルを最新の状態で予測できるよう、MLOpsの仕組みを整備していきたいと考えています。併せて、今回は相関ルールをベースとしていますが、XGBoostやニューラルネットワークといった他の手法の適用も試み、さらなる精度の向上を図れないか検討してまいります。 まとめ 本ブログ記事では、小田急電鉄における列車の遅延予測とその精度向上の取り組みについて、AWS Lambda と Amazon S3 というシンプルな組み合わせで、容易に遅延予測の仕組みを構築できたこと、ならびに、Amazon Athena 、Amazon SageMaker といったサービスを用いることで、容易に機械学習モデルを構築し、適用できることをご紹介いたしました。このように AWS のサーバーレスと機械学習サービスを活用することで容易に機械学習を用いた機能の追加ができることは AWS クラウドを利用する大きな利点だと感じました。 デジタル技術を活用し、鉄道をより便利にご利用いただくために取り組むべき課題はまだまだたくさんありますが、 AWS のみなさまにもサポートいただきながら、一つ一つ真摯に取り組んでまいりますので、これからも弊社をご愛顧いただけますと幸いです。 著者略歴 小田急電鉄株式会社 経営戦略部 落合 康文 2002年入社、駅・車掌・運転士を経験後、2012年より輸送計画業務を担当。2019年より現職に従事。小田急アプリや鉄道に関連するデータ分析業務などを担当。2021年日本大学にて博士（工学）修得

このブログはソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 はじめに 私たちが AWS Microservice Extractor for .NET をリリースしたときの目標は、モノリシックなアプリケーションからマイクロサービスを抽出するための使いやすいツールをお客様に提供することでした。この目標を達成するために、マイクロサービスで抽出する候補となるコードを見つけるための複数の方法を作成しました。この投稿では、Microservice Extractor の最新のイノベーションである、 AI を活用した自動化されたリファクタリングのレコメンデーション についてお話します。その後、マイクロサービスをグループ化して抽出するための各オプションを検討するタイミングについて説明します。 AIを活用したレコメンデーションとは? AI を活用した新しいレコメンデーション エンジンは、機械学習モデルを使用してプロジェクト内のソース コードをスキャンします。Microservice Extractor が分析を完了すると、ツールによってクラスが自動的にグループ化され、新しいマイクロサービスの候補が形成されます。 この新機能は、モダナイゼーションを必要とするアプリケーションの開発に関する専門知識をもはや持っていないお客様に最適です。このようなケースは、長期間にわたって使用されてきたアプリケーションを持つ企業で、元の開発者がもういない場合や、アプリケーションをアップグレードできない、またはアップグレードする意思のないサードパーティによって作成されたアプリケーションによく当てはまります。 適切なレコメンデーションオプションの選択 Microservice Extractor は、抽出のための3つの異なるオプションを提供します。手作業によるグループ化、ヒューリスティック分析、AIを利用したレコメンデーションです。これらのオプションはそれぞれ、マイクロサービスのクラスのグループを作成することができます。あなたの状況に最も適した抽出方法を選択してください。抽出オプションは相互に排他的ではありません。変化するニーズに基づいてマイクロサービスを特定するたびに、UI で異なる方法を選択できます。 リファクタリング対象のアプリケーションを深く理解しており、マイクロサービスの作成に関する具体的な目標がある場合は、手動でグループ化する方法を選択する必要があります。そのためには、抽出するクラスのレイアウトと、それらのクラスがアプリケーションの他の部分とどのようにつながっているかを理解する必要があります。 アプリケーションの使用経験は浅くても、抽出する必要がある機能を十分に理解している場合は、ソース コードのヒューリスティック分析によって、論理的な開始点に関するガイダンスが得られます。この分析では、分析対象のクラスの種類を識別することで、開始点を見つけます。たとえば、MVC アプリケーションのコントローラー クラスは、注文に関するマイクロサービスを抽出するための論理的な開始点かもしれません。 最後に、モダナイズするアプリケーションに関する専門知識が限られているか、まったくない場合は、AI を活用したレコメンデーション エンジンを使用して、候補となるマイクロサービスを見つけることができます。これらのレコメンデーションは、ヒューリスティック分析を超えて、開始点とサービスの境界を見つけます。AIを活用したレコメンデーションにより、Microservice Extractor はすべてのアプリケーションソースファイルを分析して、マイクロサービスに適した候補を生成する可能性が高いレコメンデーションを決定します。 これら 3 つのケースすべてで、グループ化を確認および調整して、リファクタリングの目標に向けて可能な限り最適なレコメンデーションを作成できます。 まとめ AWS Microservice Extractor は、既存のモノリシックアプリケーションから潜在的なマイクロサービスを特定する複数の方法を提供します。これらのオプションは、モダナイズするアプリケーションに関するさまざまな知識レベルに対応しています。 AWS Microservice Extractor for .NET をダウンロードすることで、AI を活用したレコメンデーションを今すぐ始めることができます。 投稿者について Tom Moore は、ボストン郊外のホーム オフィスで働いているプリンシパル デベロッパー アドボケイトです。.NET Developer Advocate として、Tom は .NET 開発者が AWS でアプリケーションを構築および実行できるように支援することに重点を置いています。Twitter では Basement Programmer @BasementProgra1 として活動しています。

ワークロードを大規模に構築、移行、運用する前に、組織の増大するニーズをサポートする、マルチアカウントアーキテクチャを実現するための基盤を構築する必要があります。この基盤が整えば、お客様は組織内のワークロードの分離を可能にする AWS アカウントを作成できます。 ビジネス目的と所有権に基づいてワークロードをグループ化し、AWS アカウントの構造を決定する際、お客様は組織の要件に合わせて AWS アカウントをカスタマイズする必要があります。クラウド運用チームは、このような繰り返し可能なアカウント設定を開発し、大規模環境でも一貫して適用できるようにするという課題に直面することがよくあります。AWS Control Tower は、お客様がベースラインとなるセキュリティ体制を整え、アカウント作成を自動化できるよう支援してきましたが、アカウントのカスタマイズとメンテナンスは複雑なプロセスになることがあります。 この投稿では、AWS Control Tower の Account Factory Customization (AFC) 機能を紹介し、AWS Control Tower のブループリントを活用することで、追加の技術的負債を負うことなく AWS アカウントを自動カスタマイズする方法を紹介します。AFC では、AWS Control Tower と AWS Service Catalog を使用してアカウントのブループリントを定義したり、事前定義されている AWS パートナーが提供するブループリントを使用して、マルチアカウントのプロビジョニングをスケールさせ、プロビジョニング後すぐに AWS アカウントの使用を開始することができます。これにより、クラウド運用チームは、新しく払い出された AWS アカウントに、カスタム設定を適用するプロセスを簡略化、繰り返し利用できるようになりました。 このブログ記事に登場する AWS のサービスと機能 AWS Organizations は、複数の AWS アカウントをポリシーベースで管理できます。AWS Organizations では、アカウントグループの作成、アカウント作成の自動化、それらのグループのポリシーの適用、管理を行うことができます。 AWS Control Tower は、お客様に代わって複数の AWS サービスを統合することで、組織のセキュリティとコンプライアンス要件に合わせ、シンプルにお客様の AWS 環境の管理を行うことができます。 Account Factory Customization (AFC) は、AWS アカウントのプロビジョニング・登録・更新の際に、アカウントのカスタマイズを可能にする AWS Control Tower の機能です。 AWS Service Catalog は、デプロイされた IT サービス、アプリケーション、リソース、メタデータを一元管理して、 Infrastructure as Code (IaC) テンプレートの一貫したガバナンスを実現できます。 AWS CloudFormation には、クラウド環境のすべてのインフラリソースを記述してプロビジョニングするための共通言語が用意されています。AWS CloudFormation では、標準的なテキストファイルを使用して、すべてのリージョン・アカウント上のアプリケーションに必要なすべてのリソースを、自動的かつ安全に、モデル化・プロビジョニングできます。 このブログ記事で使われている用語 カスタムブループリント — アカウントのプロビジョニング中に適用される、特定のリソースと構成を記述したカスタム設定のことを指します。AFC で使用します。 ハブアカウント — AFC が使用するブループリントの Service Catalog 中央リポジトリを管理するための AWS アカウント。 パートナーブループリント — AWS パートナーが作成したアカウント設定で、AWS パートナーの提供するソリューションと連携するために必要なリソースと設定を定義しています。 管理アカウント — 組織（AWS Organizations） を作成するために使用する単一の AWS アカウントです。AWS Control Tower の Account Factory のオペレーションは、管理アカウントから実行されます。 Service Catalog 入門ライブラリ — （Service Catalogで定義される） 製品（Products）を使い始めるのに役立つ、Well-Architected なベストプラクティステンプレートを提供するソリューションライブラリです。 ウォークスルー この投稿では、以下の方法を紹介します。 カスタムブループリントの作成 カスタムブループリントを新しい AWS アカウントにデプロイする すぐに使えるパートナーブループリントを新しい AWS Control Tower アカウントにデプロイする 既存の AWS Control Tower アカウントをブループリントで更新する AWS Control Tower 管理対象外のアカウントをブループリントで登録する プロビジョニング後のカスタムアカウントを管理する 図 1：AFC でカスタムアカウントを作成するエンドツーエンドのワークフロー 前提条件 デプロイ済みで利用可能な AWS Control Tower 環境にアクセスできる必要があります。AWS Control Tower を初回起動する必要がある場合は、 AWS Control Tower クイックスタートガイド に従ってください。 ブループリントを一元的に管理する、同じ組織内にあるハブアカウントを用意します。お客様は AFC を使用する前に、ハブアカウントに AWSControlTowerBlueprintAccess ロール を作成する必要があります。 AWS Control Tower に新たに登録するアカウントには、 AWSControlTowerExecution ロール を追加する必要があります。 パートナーブループリントで AWS Marketplace のサブスクリプションの必要条件がある場合は、AFC でデプロイする前に管理アカウントレベルで設定する必要があります。 カスタムブループリントの作成 AWS Service Catalog で独自のカスタムブループリントを作成し、要件に合わせて AWS Control Tower アカウントにデプロイすることができます。 まず、Service Catalog のリファレンスアーキテクチャリポジトリから、 サンプル CloudFormation テンプレート をダウンロードします。この記事では、AWS Backup のバックアッププランを作成するテンプレートを使用して、アカウント内の各種 AWS リソースの自動バックアップ設定を行います。 Service Catalog の製品（products）を一元的に保管する、ハブアカウントにログインします。AWS のベストプラクティスでは、Service Catalog の製品の保管には、管理アカウントを使用しないことが推奨されています。 Service Catalog に移動し、左側のナビゲーションペインから [製品リスト] を選択します。 [製品の作成] を選択し、 [製品の詳細] ペインで、次のスクリーンショットに示すように製品の詳細を入力します。 図 2：新しい製品の作成 [バージョンの詳細] ペインのさらに下にある [テンプレートファイルの使用] というラベルの付いたラジオボタンを選択し、 [ファイルの選択] ボタンを選択します。 1. でダウンロードした CloudFormation テンプレートを選択します。 図 3：新しい Service Catalog 製品への CloudFormation テンプレートのアップロード コンソールページの下部にある [製品を作成] ボタンを選択します。 新しく作成された製品が表示されます。次の手順ではこの製品をカスタムブループリントとして使用します。 図 4：新しく作成された製品 製品の作成に関する詳細については、 AWS Service Catalog 管理者ガイド を参照してください。 カスタムブループリントを新しい AWS アカウントにデプロイする これでカスタムブループリントの用意が整いました。次からはこのブループリントを使用し、 AWS Control Tower アカウントファクトリでカスタマイズされたアカウントを作成します。以下の手順で、カスタムブループリントを新しい AWS アカウントにデプロイします。 AWS Control Tower 管理アカウントにログインします。 マネジメントコンソールの AWS Control Tower サービス画面に移動します。 左側のナビゲーションペインから [Account Factory] を選択し、 [アカウントの作成] ボタンを選択します。 図 5：Account Factory での新規アカウントの作成 [アカウントの詳細] セクションで、新規作成するアカウントのための表示名と固有のアカウント E メールを入力します。 [アクセス設定] セクションでは、IAM Identity Center ユーザーの E メールと IAM Identity Center のユーザー名の詳細を入力します。 [組織単位] セクションで、アカウントを追加する先の組織単位を選択します。 図 6：アカウント作成ワークフローのアカウント詳細セクション [アカウントファクトリーのカスタマイズ] セクションを開きます。 AWS Service Catalog の製品を含むハブアカウント ID を入力し、 [アカウントを検証] を選択します。 ドロップダウンから 製品を選択 し、使用する 製品バージョン を選択します。前述の 「カスタムブループリントの作成」 で作成したブループリントを選択してください。 ブループリントにパラメータが含まれている場合は、そのパラメータが表示され、この場で入力することが可能です。デフォルト値がある場合は事前に入力されています。 最後に、ブループリントのデプロイ先となる [ホームリージョン] または [すべての管理対象リージョン] を選択します。Route 53 や IAM などのグローバルリソースは 1 つのリージョンにのみデプロイする必要がありますが、EC2 インスタンスや Amazon S3 バケットなどのリージョンリソースはすべての管理対象リージョンにデプロイできます。 すべてのフィールドに入力したら、 [アカウントの作成] を選択します。 図 7：アカウント作成ワークフローの アカウントファクトリーのカスタマイズ 入力項目 左側のナビゲーションペインから AWS Control Tower の [組織] 機能に移動すると、アカウントの進捗状況を確認できます。アカウントのプロビジョニングが完了次第、そのアカウント内でブループリントがデプロイされます。 すぐに使えるパートナーブループリントを新しい AWS Control Tower アカウントにデプロイする お客様はまた、AWS パートナーが作成および管理する定義済みのブループリントを使用して、特定のユースケースに合わせてアカウントをカスタマイズすることもできます。2023 年 3 月現在、11 社のローンチパートナーが、すぐに使えるアカウントブループリントを開発しました。これにより、ユーザーがパートナーのインフラストラクチャやセキュリティ製品サービスと連携するよう、アカウントを簡単に設定できるようになります。 図 8: アカウントファクトリカスタマイズのローンチパートナー すぐに使用できる AWS Control Tower ブループリントの完全なリストについては、コンソールから AWS Service Catalog に移動し、左側のナビゲーションペインから 「入門ライブラリ」 を選択してください。AWS Control Tower ブループリントのソースタイプでフィルタリングします。 図 9：「入門ライブラリ」と AWS Control Tower ブループリントのソースタイプ パートナーブループリントをデプロイする手順は次のとおりです。 AWS Service Catalog 製品の一元的管理をしている AWS ハブアカウントにログインします。 Service Catalog サービス画面に移動し、左側のナビゲーションペインから [入門ライブラリ] 機能を選択します。 AWS Control Tower ブループリントを検索してください。これにより、AFC で使用できるすべてのパートナー製品が表示されます。 この記事では、Datadog AWS Integration 製品を選択してください。 製品の詳細を確認したら、右上の [ポートフォリオに追加] を選択し、使用する新規または既存のポートフォリオを選択します。 これで、このパートナーブループリントが選択したポートフォリオおよび製品リストに表示され、AFC で使用できるようになります。 AWS Control Tower 管理アカウントにログインし、前述の「カスタムブループリントを新しい AWS Control Tower アカウントにデプロイする」の手順に従います。その際、先ほど入門ライブラリから追加した Datadog 製品を選択してください。 Service Catalog から [製品の詳細] セクションにアクセスすると、製品の起動に必要なパラメーターを説明したドキュメントへのリンクが表示されます。必要に応じて参照してください。 図 10: 製品のパラメータ情報へのリンク例 または、 Cloud Storage Security 、 Datadog 、 Cisco 、 Cribl のいずれかのパートナーブログで、AFCでの導入方法に関する具体的な手順を含むパートナーブループリントの詳細な概要を確認することもできます。 既存の AWS Control Tower アカウントをブループリントで更新する AWS Control Tower 環境内の既存の登録済アカウントで、ブループリント未登録、またはブループリントの変更が必要なアカウントは、次のように更新できます。 AWS Control Tower 管理アカウントにログインし、AWS Control Tower サービス画面に移動します。 左側のナビゲーションペインから、 [組織] 機能を選択します。 更新したいアカウントの横にあるラジオボタンを選択します。コンソール右上のセクションから [アクション] ドロップダウンを選択し、 [更新] を選択します。 必要に応じて [アカウントファクトリーのカスタマイズ] セクションを更新し、 [アカウントの更新] を選択します。 アカウントの進捗状況は [組織] ページで確認できます。アカウントの更新が正常に完了すると、ブループリントが展開されます。アカウントとブループリントの内容と詳細を表示するには、 [組織] ページでアカウント名を選択して [アカウントの詳細] ページに移動します。 AWS Control Tower 管理対象外のアカウントをブループリントで登録する AWS Control Tower に登録されていない組織内の既存のアカウントは、登録プロセス中に次のようにブループリントで更新できます。 AWS Control Tower 管理アカウントにログインし、AWS Control Tower サービス画面に移動します。 左側のナビゲーションペインから、 [組織] 機能を選択します。 カスタムブループリントに登録したい管理対象外のアカウントを特定します。 [状態] 列には、 「未登録」 ステータスが表示されているはずです。 アカウントの左側にあるラジオボタンを選択します。コンソール右上のセクションから [アクション] ドロップダウンを選択し、 [登録] オプションを選択します。 アカウントを追加する登録済み OU を選択します。 必要に応じて [アカウントファクトリーのカスタマイズ] セクションを更新し、 [アカウントの登録] を選択します。 アカウントの進捗状況は [組織] ページで確認できます。アカウントの更新が正常に完了すると、ブループリントが展開されます。アカウントとブループリントの内容と詳細を表示するには、 [組織] ページでアカウント名を選択して [アカウントの詳細] ページに移動します。 プロビジョニング後のカスタムアカウントを管理する デプロイ後にアカウントのブループリントを更新する必要がある場合があります。その場合は、CloudFormation テンプレートに必要な変更を加えて更新し、新しいバージョンとして AWS Service Catalog に保存します。AWS Control Tower の [組織] ページでブループリント名とバージョンでフィルタリングし、アカウントの 更新プロセス からアカウントのブループリントバージョンを更新し、最新の設定をデプロイできます。 アカウントからブループリントを削除する必要がある場合、またはアカウントを別の用途に転用する必要がある場合は、アカウントの更新プロセスからブループリントを削除し、アカウントを AWS Control Tower のデフォルト設定に戻すことができます。 アカウントをAWS Control Tower の管理対象から解除 すると、ブループリントからデプロイされたリソースと、アカウント内の AWS Control Tower が管理するリソースがすべて削除されます。その後、必要に応じて AWS Organizations を通じて アカウントを閉鎖 できます。新しいブループリントを追加するには、更新ワークフローを再実行し、アカウントに追加する新しいブループリントを選択します。新しくプロビジョニングされたアカウントは、関連するブループリントの実行中に障害が発生すると、AWS Control Tower 環境に登録されません。ブループリントが失敗した後にアカウントを登録するプロセスは、 AWS Control Tower ユーザーガイド に記載されています。 結論 この記事では、Account Factory Customization (AFC) がアカウントカスタマイズプロセスの簡略化にどのように役立つかを学びました。AWS Control Tower ブループリントを使用すると、独自のビジネスニーズを満たす完全にカスタム化されたリソースを定義したり、事前定義された AWS パートナーブループリントを使用して AWS Control Tower でネイティブに新しいアカウントのカスタマイズを開始したりできます。また、既存の AWS Control Tower アカウントを更新する方法や、AWS Control Tower 管理対象外のアカウントをブループリントに登録する方法についても学びました。 AFC では、モジュール式で再利用可能なメカニズムで要件を定義し、アカウントライフサイクルのどの時点でもカスタマイズをデプロイできます。これにより、AWS Control Tower 内のアカウントカスタマイズアクティビティが合理化され、独自のソリューションとパイプラインを維持するためのオーバーヘッドが削減されます。詳細については、 『Account Factory Customization (AFC) ユーザーガイド』 を参照してください。 本記事は、 Automate account customization using Account Factory Customization in AWS Control Tower を翻訳したものです。 翻訳はソリューションアーキテクトの白石 一乃が担当しました。 著者紹介 Ellie Ray Ellie Ray は AWS Control Tower のテクニカルサポート担当シニアプロダクトマネージャーです。彼女は、変革をもたらすソフトウェアとクラウドソリューションを構築し、市場に提供してきた8年以上のプロダクト経験があります。彼女は、AWS サービスの採用とクラウド移行のカスタマージャーニーを促進することに情熱を注いでいます。 Jim McDonald Jim McDonald は AWS のソリューションアーキテクトです。彼はクラウドアーキテクチャに情熱を傾け、お客様やパートナーが困難な課題を創造的な方法で解決できるよう支援しています。Jim は、石油・ガス、エネルギー、金融サービス、ヘルスケア、プロフェッショナルサービスの分野で30年以上の技術経験があります。 Adrian David Adrian David はアマゾンウェブサービスのテクニカルプログラムマネージャーで、AWS パートナー統合を専門としています。Adrian は AWS テクノロジーパートナーと協力して、お客様のクラウドへの移行を促進するソリューションを構築しています。

2023 年の AWS re:Invent において、 Amazon Bedrock のナレッジベース の一般提供の開始を発表しました。ナレッジベースを使用すると、 Amazon Bedrock の基盤モデル (FM) をお客様の企業データに安全に接続して、検索拡張生成 (RAG) を実現できます。 私の 過去の記事 では、Amazon Bedrock のナレッジベースがエンドツーエンドの RAG ワークフローをどのように管理するのかについてご説明しました。次の図に示すように、データの場所を指定し、データをベクトル埋め込みに変換するために埋め込みモデルを選択して、ベクトルデータを保存するために、Amazon Bedrock に AWS アカウントでベクトルストアを作成させます。独自のカスタムベクトルストアを指定するなど、RAG ワークフローをカスタマイズすることもできます。 私が 11 月に前回の記事を書いた後、ナレッジベースには多数の更新が導入されました。これには、 Amazon OpenSearch Serverless 用ベクトルエンジン 、 Pinecone 、および Redis Enterprise Cloud に加えて、追加のカスタムベクトルストアオプションとして Amazon Aurora PostgreSQL 互換エディション が利用可能になったことが含まれます。しかし、それだけではありません。新しい機能を簡単にご紹介します。 埋め込みモデルの追加の選択肢 埋め込みモデルは、ドキュメントなどのデータをベクトル埋め込みに変換します。ベクトル埋め込みは、ドキュメント内のテキストデータの数値表現です。各埋め込みは、データのセマンティックまたはコンテキスト上の意味を捉えることを目的としています。 Cohere Embed v3 – Amazon Titan Text Embeddings に加えて、 Cohere Embed English と Cohere Embed Multilingual の 2 つの追加の埋め込みモデルもお選びいただけるようになりました。それぞれ 1,024 次元をサポートしています。 Cohere Embed v3 モデル の詳細については、Cohere ブログをご覧ください。 ベクトルストアの追加の選択肢 各ベクトル埋め込みは、多くの場合、埋め込みが作成された元のコンテンツへの参照などの追加のメタデータとともに、ベクトルストアに格納されます。ベクトルストアは、保存されたベクトル埋め込みにインデックスを付けて、関連データを迅速に取得できるようにします。 ナレッジベースは、ベクトルデータを保存するためのベクトルストアをアカウント内に作成するなど、フルマネージドの RAG エクスペリエンスを提供します。また、サポートされているオプションのリストからカスタムベクトルストアを選択し、ベクトルデータベースのインデックス名と、インデックスフィールドおよびメタデータフィールドのマッピングを指定することもできます。 ベクトルストアに対して最近 3 つの更新が導入されたのでご紹介します。それらの更新とは、サポートされるカスタムベクトルストアのリストに対する Amazon Aurora PostgreSQL 互換および Pinecone サーバーレスの追加、ならびに、開発およびテストのワークロードのコスト削減に役立つ、既存の Amazon OpenSearch Serverless 統合の更新です。 Amazon Aurora PostgreSQL – Amazon OpenSearch Serverless 用ベクトルエンジン、Pinecone、Redis Enterprise Cloud に加えて、ナレッジベースのベクトルデータベースとして Amazon Aurora PostgreSQL もお選びいただけるようになりました。 Aurora は、MySQL および PostgreSQL と完全な互換性のあるリレーショナルデータベースサービスです。これにより、既存のアプリケーションやツールを変更せずに実行できます。Aurora PostgreSQL はオープンソースの pgvector 拡張機能をサポートしており、これにより、ベクトル埋め込みの保存、インデックス作成、クエリが可能になります。 一般的なデータベースワークロード向けの Aurora の機能の多くは、ベクトル埋め込みワークロードにも適用されます。 Aurora は、オープンソースの PostgreSQL と比較して最大 3 倍のデータベーススループットを提供し、Amazon Bedrock のベクトルオペレーションまで拡張します。 Aurora Serverless v2 は、Amazon Bedrock からのリアルタイムのクエリ負荷に基づいてストレージとコンピューティングキャパシティの伸縮自在なスケーリングを提供し、最適なプロビジョニングを実現します。 Aurora グローバルデータベース は、複数の AWS リージョンにわたる低レイテンシーのグローバル読み取りとディザスタリカバリを提供します。 ブルー/グリーンデプロイ は、同期されたステージング環境で本番データベースをレプリケートします。これにより、本番環境に影響を及ぼすことなく変更できます。 Amazon EC2 の R6gd および R6id インスタンス上の Aurora Optimized Reads は、ローカルストレージを使用して、複雑なクエリとインデックス再構築オペレーションの読み取りパフォーマンスおよびスループットを強化します。メモリに収まらないベクトルワークロードでは、Aurora Optimized Reads は、同じサイズの Aurora インスタンスと比較して最大 9 倍優れたクエリパフォーマンスを提供できます。 Aurora は、Secrets Manager、IAM、RDS Data API などの AWS サービスとシームレスに統合し、Amazon Bedrock からデータベースへの安全な接続を可能にするとともに、SQL を利用したベクトルオペレーションをサポートします。 ナレッジベース用に Aurora を設定する方法の詳細なチュートリアルについては、 AWS データベースブログのこの記事 と、 Aurora のユーザーガイド をご覧ください。 Pinecone サーバーレス – Pinecone は最近、 Pinecone サーバーレス を導入しました。ナレッジベースでカスタムベクトルストアとして Pinecone を選択した場合、Pinecone または Pinecone サーバーレスの設定の詳細を指定できます。両方のオプションがサポートされています。 Amazon OpenSearch Serverless で開発およびテストのワークロードのコストを削減する 新しいベクトルストアを迅速に作成するオプションを選択すると、Amazon Bedrock は、アカウント内の Amazon OpenSearch Serverless でベクトルインデックスを作成します。これにより、自分で何かを管理する必要がなくなります。 11 月に一般提供が開始されて以来、Amazon OpenSearch Serverless 用ベクトルエンジンでは、開発およびテストのワークロードのために冗長レプリカを無効にできるようになりました。これを使用することで、コストを削減できます。インデックス作成用と検索用に 1 OCU (OpenSearch Compute Unit) ずつ、合計 2 OCU のみで開始できるため、冗長レプリカを使用する場合と比較してコストを半分に削減できます。さらに、OCU の端数請求により、0.5 OCU から開始して必要に応じてスケールアップできるため、コストをさらに削減できます。開発およびテストのワークロードでは、少なくとも 1 OCU (インデックス作成と検索に分割) あれば十分になりました。これにより、本番ワークロードに必要な 4 OCU と比較して、コストを最大 75% 削減できます。 使いやすさの向上 – Amazon Bedrock のナレッジベースでクイック作成ワークフローを選択した場合、冗長レプリカはデフォルトで無効に設定されるようになりました。必要に応じて、 [本番ワークロードに更新] を選択して、冗長レプリカを含むコレクションを作成できます。 Amazon OpenSearch Serverless 用ベクトルエンジンの詳細については、 Channy の記事 をご覧ください。 FM の追加の選択肢 実行時、RAG ワークフローはユーザークエリから始まります。埋め込みモデルを使用して、ユーザーの入力プロンプトのベクトル埋め込み表現を作成します。次に、この埋め込みを使用し、データベースをクエリして類似のベクトル埋め込みを探し、クエリ結果として最も関連性の高いテキストを取得します。その後、クエリ結果が元のプロンプトに追加され、拡張されたプロンプトが FM に渡されます。次の図に示すように、モデルはプロンプト内の追加コンテキストを使用して補完を生成します。 Anthropic Claude 2.1 – Anthropic Claude Instant 1.2 および Claude 2 に加えて、ナレッジベースに Claude 2.1 をお選びいただけるようになりました。以前の Claude モデルと比較して、Claude 2.1 では、サポートされるコンテキストウィンドウサイズが 2 倍の 200 K トークンに増加しました。 Claude 2.1 の詳細については、Anthropic ブログをご覧ください。 今すぐご利用いただけます 埋め込みモデル、ベクトルストア、FM の追加の選択肢を含む Amazon Bedrock のナレッジベースは、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。 詳細 Amazon Bedrock のナレッジベースの製品ページ community.aws の Amazon Bedrock のナレッジベース コンソールの Amazon Bedrock Amazon Bedrock のナレッジベースに関する記事 Build generative AI applications with Amazon Aurora and Knowledge Bases for Amazon Bedrock (ブログ記事) Vector engine for Amazon OpenSearch Serverless is now available  (ブログ記事) –  Antje 原文は こちら です。

春節のお喜びを申し上げます。 皆様にとって新しい年が喜び、成功、そして無限の機会に満ちた 1 年でありますよう願っています。 この辰年が、途切れることのないつながりと無限の成長をもたらしますように 見逃した方のために、2024 年初頭に 1 年を計画する際に知っておくべき重要なニュースをご紹介します。 AWS は、 2023 Magic Quadrant for Strategic Cloud Platform Services でリーダーに選出されました。Gartner が 13 年連続でリーダーとして選出している AWS は、最も長期にわたる Magic Quadrant のリーダーの地位を確立しています。詳細については、 Sebastian のブログ投稿 を参照してください。AWS は、 2023 Gartner Magic Quadrant for Cloud Database Management Systems で 9 年連続にわたってリーダーに選出されました。また、あらゆるワークロード、ユースケース、データタイプにわたってお客様のデータ基盤にサービスの包括的なセットを提供することで、実行能力の面において最高の評価を得ています。詳細については、 Rahul Pathak のブログ投稿 を参照してください。 AWS は、 IDC MarketScape: Worldwide Data Clean Room Technology 2024 Vendor Assessment (2024 年 1 月) でもデータクリーンルームテクノロジーのリーダーに選ばれました。このレポートでは、さまざまな業界のユースケースでデータクリーンルームテクノロジーベンダーが評価されました。詳細については、 AWS for Industries ブログチャンネルの投稿 を参照してください。 2月5日週のリリース 私が注目したいくつかのリリースをご紹介します。 テキサス州ヒューストンの新しいローカルゾーン – ローカルゾーンは、AWS リージョンが存在しない人口密集地、業界、IT センターの近くにコンピューティング、ストレージ、データベース、その他の一部のサービスを配置する AWS インフラストラクチャデプロイです。AWS Local Zones は米国内のその他 15 の大都市圏と世界の 17 の大都市圏で利用可能なので、世界中のエンドユーザーに低レイテンシーのアプリケーションを提供できます。ヒューストンの新しいローカルゾーン (us-east-1-iah-2a) は、 Amazon EC2 コンソール設定 の [ゾーン] タブから有効にすることができます。 AWS CloudFormation IaC generator – アカウントでプロビジョニング済みで、CloudFormation によって管理されていない AWS リソースを使用してテンプレートを生成できます。今回のローンチにより、ワークロードを数分で Infrastructure as Code (IaC) にオンボーディングできるようになるので、これまで数週間を要していた手作業が排除されます。ワークロードの自動化、安全性、スケーラビリティという IaC のメリットを活用できるようになります。テンプレートを使用してリソースを CloudFormation にインポートするか、リソースを新しいアカウントまたはリージョンに複製できます。詳細については、 ユーザーガイド と ブログ投稿 を参照してください。 Amazon Bedrock コンソールの新しいルックアンドフィール – Amazon Bedrock の使いやすさと応答性、そしてダークモードのシームレスなサポートによるアクセシビリティの向上が実現し、更新された UI のコンソールエクスペリエンスが強化されました。新しいエクスペリエンスを開始するには、 Amazon Bedrock コンソール にアクセスしてください。 ALB でのワンクリックの WAF 統合 – Application Load Balancer (ALB) が AWS WAF とのコンソール統合をサポートするようになり、ALB の背後にあるアプリケーションをワンクリックで保護することが可能になりました。この統合により、ALB を使用するアプリケーションの一般的なウェブ脅威に対する防御の最前線としての AWS WAF 保護が可能になります。AWS WAF によって提供されるこのワンクリックセキュリティ保護は、 ALB コンソール の統合サービスセクションから新規および既存のロードバランサーの両方で使用できます。 Amazon ECS 上の AWS Fargate Windows コンテナを最大 49% 値下げ – コンテナ化されたアプリケーションが要求するインフラストラクチャと Windows Server ライセンスに関して、Fargate 上で実行する Windows コンテナの請求が 1 秒単位で行われるようになりました。2024 年 2 月 1 日 (午前 12 時 UTC) から、オンデマンドのインフラストラクチャ料金とともに、すべての Fargate Windows タスクの Windows コンテナの最小請求期間が (以前の 15 分から) 5 分に短縮されます。インフラストラクチャ料金と最低請求期間の変更は、毎月の AWS 請求書に自動的に反映されます。特定の値下げの詳細については、 料金ページ を参照してください。 Amazon Data Firehose の紹介 – Amazon Kinesis Data Firehose の名称が Amazon Data Firehose に変更されます。Amazon Data Firehose は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake、およびその他のサードパーティ製分析サービスにデータストリームをキャプチャ、変換、配信する最も簡単な方法です。名前の変更は、 AWS マネジメントコンソール 、 ドキュメント 、 製品ページ で有効になります。 AWS Transfer Family と Amazon EventBridge との統合 – ほぼリアルタイムの SFTP、FTPS、FTP ファイル転送イベント 、 SFTP コネクタ ファイル転送イベント通知、 Applicability Statement 2 (AS2) 転送オペレーション を Amazon EventBridge に公開することにより、AWS Transfer Family で条件付きワークフローを使用できるようになりました。Amazon EventBridge、またはこれらのイベントと統合される任意のワークフローオーケストレーションサービスを使用して、AWS でファイル転送とファイル処理のワークフローのオーケストレーションを行うことができます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 スーパーボウルで活躍する NFL のデジタルアスリート – AWS は NFL (ナショナルフットボールリーグ) と協力して、選手の健康と安全を次のレベルに引き上げています。NLF では、AI と機械学習を使用して、トレーニング、練習、試合における各選手の正確なコンディションを把握しています。特に2月4日週の日曜日のスーパーボウルでは、このテクノロジーが実際に活用されているのを見ることができました！ 責任ある人工知能への Amazon のコミットメント – 2 月 7 日、Amazon は、安全で安心できる人工知能 (AI) の推進に向けた政府と産業界の協力を促進することを目的としてアメリカ国立標準技術研究所 (NIST) によって設立された Artificial Intelligence Safety Institute Consortium に参加しました。Amazon は、AI の安全性を評価するツールの開発に役立つコンピューティングクレジットを寄付し、責任ある AI の開発と使用のための相互運用可能で信頼できる基盤を確立できるよう支援します。 韓国のコンプライアンス更新 – AWS は、韓国の電子金融取引の監督に関する規制 (RSEFT) 監査プログラムとしても知られる 2023 South Korea Cloud Service Providers (CSP) Safety Assessment Program を完了しました。AWS は、該当する規制やガイドラインをお客様が遵守することを支援するとともに、金融機関のお客様が最小限の労力でクラウドを利用できるように支援しています。また、AWS は、 韓国情報セキュリティ管理システム (K-ISMS) 標準 (2023 年 12 月 16 日から 2026 年 12 月 15 日まで有効) に基づく認証を正常に更新しました。 AWS クラウドクラブキャプテン会員募集中 – AWS クラウドクラブ は、高等教育課程の学生および個人学習者を対象として学生主導のユーザーグループです。大学や地域でのクラウドクラブの設立や共同設立に興味がある場合は、 2024 年 2 月 5 日～18 日の期間に申し込んでください。 AWS の今後のイベント カレンダーを確認して、今後予定されている AWS イベントにサインアップしてください。 AWS Innovate AI/ML と Data Edition – 無料のオンラインカンファレンスに参加して、生成 AI の最新テクノロジーを活用する方法を学びましょう。 アジアパシフィックと日本 (2 月 22 日)、 EMEA (2 月 29 日)、 南北アメリカ (3 月 14 日) に開催される AWS Innovate Online イベントに登録できます。 AWS 公共部門イベント – AWS Public Sector Symposium Brussels (3 月 12 日) に参加して、AWS クラウドがレジリエンシーの向上、持続可能なソリューションの開発、ミッションの達成にどのように役立つかをご覧ください。 AWS Public Sector Day London (3 月 19 日) には政府、医療、教育の各セクターの専門家が集まり、英国の公共サービスにおける差し迫った課題に取り組みます。 AWS Global Summit のキックオフ – AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。以下は、4 月に開催予定の AWS Summit イベントのリストです。 AWS Summit パリ (2024 年 4 月 3 日) AWS Summit アムステルダム (2024 年 4 月 9 日) AWS Summit シドニー (2024 年 4 月 10 日～11日) AWS Summit ロンドン (2024 年 4 月 24 日) 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの 開発者向けイベント のすべてを閲覧できます。 今週はここまでです。2月19日週に再びアクセスして、新たな Week in Review をぜひお読みください! – Channy この投稿は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Aurora MySQL 互換エディション バージョン 3 (MySQL 8.0 互換) は、Amazon Aurora MySQL でサポートされている最新バージョンのメジャーバージョンです。Amazon Aurora MySQL バージョン 3 を使用することで、最新の MySQL 互換機能とパフォーマンス向上を利用できます。MySQL 8.0 では JSON 関数、ウィンドウ関数、共通テーブル式 (CTE)、ロールベースの権限など、いくつかの新機能が導入されています。また、Amazon Aurora MySQL 3 には、 Amazon Aurora Serverless v2 、 Amazon Aurora ゼロ ETL 、 AWS Graviton3 サポート 、 拡張バイナリログ 、 Amazon Aurora I/O 最適化 などの新機能のサポートも含まれています。機能の完全なリストは、 MySQL 8.0 と互換性のある Aurora MySQL バージョン 3 を参照してください。 Amazon Aurora MySQL の新しいメジャーバージョンがリリースされたとき、DB クラスターをいつ、どのようにアップグレードするかを選択できます。 メジャーエンジンバージョンのアップグレードにより、既存のアプリケーションと下位互換性のない変更が導入される可能性があるため、データベースのバージョンをアップグレードし、メリットを最大化するための一般的な課題とベストプラクティスを認識しておくことが不可欠です。 この投稿では、アップグレードの準備をするにあたって始めるフレームワークについて説明し、標準サポートの終了タイムラインを確認した後、アップグレードプロセスの詳細について説明します。Aurora のアップグレードの事前チェック、全体的な手順、Aurora MySQL クラスターを変更するために使用できるさまざまなオプションから始めます。この投稿では、本番データベース クラスターをアップグレードする前のパフォーマンス テストのベスト プラクティス、変更が行われる際の監視手法、およびその他の重要な考慮事項についても説明します。 メジャーバージョンアップグレードの準備 メジャーバージョンのアップグレードを計画する際、データベースとアプリケーションの機能が期待どおりであることを確認するための一連のテストと検証ステップを定義することから始めることができます。 メジャーバージョンアップグレードの要件と成功基準を考える際、このトピックをより小さな目的に分解することが役立ちます。 計画に構造を与えるためのいくつかの重要な焦点領域は以下のとおりです: 互換性 – アップグレード後もクライアントアプリケーションが正しく動作することを確認します。アプリケーションが期待通りに動作し続けるために必要なプラットフォーム、データベース、クエリレベルの機能を特定します。本番環境へのアップグレード前に、互換性の問題を特定するためにアップグレードプロセスのテストを行います。テスト方法については、 アップグレード前の新しい Aurora バージョンでの DB クラスタのテスト を参照してください。 パフォーマンス – 本番データベースのアップグレード前のパフォーマンステストには、アプリケーションのパフォーマンスを適切に維持することと、期待される改善を検証することが含まれます。この投稿では、MySQL 5.7 と MySQL 8.0 間の 変更 によって導入される可能性のある違いがあるため、クエリパフォーマンスをテストするための推奨事項とツールについて説明します。 可用性 – 可用性には 2 つの重要な側面があります。1 つ目はアプリケーションのダウンタイムを最小限に抑えること、2 つ目は問題が発生した場合のフォールバックオプションを用意することです。許容できるダウンタイムとアップグレードプロセスをどの程度制御したいかに応じて、この投稿で説明する複数のアップグレードオプションから選択できます。 工数 – メジャーバージョンアップグレードの準備中は、本番環境での変更の前に非本番環境でアップグレードの計画とテストに必要なエンジニアリングの工数も見積もる必要があります。準備ステップのコストと工数を評価する際は、その作業が他の場所で再利用できるかどうかを考慮してください。適切な変更管理手順の作成に投資することで、その作業を他の状況で再利用できる可能性が高くなります。 アップグレードのタイムライン Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換)は、2024 年 10 月 31 日に標準サポートが終了します。詳細な手順については、 Amazon Aurora MySQL 互換エディション バージョン 2 の標準サポート終了の準備 を参照してください。 標準サポートの終了タイムライン 標準サポート期間終了に向けた主な日程は以下のとおりです。 2024 年 10 月 31 日まで – Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換)から Amazon Aurora MySQL バージョン 3(MySQL 8.0 互換)へのクラスターのアップグレードができます。 2024 年 10 月 31 日 – この日に、Aurora MySQL バージョン 2 が標準サポートの提供終了となります。Aurora や RDS の標準サポート提供終了日から最大 3 年間、既存のバージョンを使用し続けることができるよう、 Amazon RDS 延長サポート にオプトインできます。 Amazon RDS 延長サポート 2023 年 9 月、AWS は Amazon RDS 延長サポート を発表しました。これは、 Amazon Relational Database Service (Amazon RDS)が、Amazon Aurora MySQL または Amazon RDS for MySQL のメジャーバージョンに対して、Aurora または RDS の標準サポート終了日から最大 3 年間、重要なセキュリティおよびバグ修正を提供する有償のサービスです。 詳細については、 Amazon Aurora および Amazon RDS 上の MySQL データベース向け Amazon RDS延長サポートのご紹介 および Aurora の料金 の Amazon RDS延長サポートのコストを参照してください。 Aurora バージョンのリリース日とサポート終了日の更新されたタイムラインの詳細については、 Amazon Aurora メジャーバージョン と Amazon Aurora マイナーバージョン を参照してください。 ターゲットバージョンの選択 Amazon Aurora MySQL 2 クラスタを Amazon Aurora MySQL 3 にアップグレードすることを検討する際、アップグレードの対象バージョンとして選択できるマイナーバージョンが複数あることに気づくかもしれません。 本ブログ執筆時点で、最新の Amazon Aurora MySQL バージョンは MySQL 8.0.32 と互換性のある Amazon Aurora MySQL 3.05 です。 Aurora MySQL 3 は長期サポート( LTS ) バージョンもサポートしています。これは MySQL 8.0.28 と互換性のある Aurora MySQL 3.04 マイナーバージョンです。 LTS リリースを利用しているデータベースクラスタは、そのリリースが利用可能になってから少なくとも 3 年間は同じマイナーバージョンのままでいられるため、クラスタのアップグレードサイクルを少なくすることができます。 Aurora MySQL 3 へのアップグレード時にはLTS リリースを使用するのではなく、最新のデフォルトマイナーバージョンにアップグレードして、最新の機能とバグ修正を利用することをおすすめします。 バージョンごとの機能と改善点については、Amazon Aurora MySQL 3 のリリースノート Database engine updates for Amazon Aurora MySQL version 3 をご覧ください。 Amazon Aurora MySQL 3 へのアップグレードの事前チェック データベースエンジンのメジャーバージョンをアップグレードする際、既存のアプリケーションとの互換性を新しいバージョンとその機能の両方で確認することが、アップグレードの全体的な成功において重要な役割を果たします。MySQL データベースのバージョンとリリースごとにアプリケーションとの動作や対話方法が異なる場合があり、これによりアプリケーションの動作に変更が生じる可能性があります。 MySQL 8.0 には MySQL 5.7 と比較して多くの変更が含まれています。 例えば、以前は予約されていなかった一部の キーワード ( RANGE など)が MySQL 8.0 では予約されている可能性があります。 また、一部の 機能 (クエリキャッシュなど) が MySQL 8.0 で削除されている可能性があります。 これらの違いはアップグレード中に対処する必要がある場合があります。 ベストプラクティスとして、 MySQL 8.0 の新機能 を詳しく調べ、すべての変更を参照し、それらがワークロードに適用されるかどうかを確認することをおすすめします。 特に Amazon Aurora MySQL の場合は、「 Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較 」を参照して、アップグレード時の変更点を確認することもできます。 AWS Management Console や AWS Command Line Interface(AWS CLI) から Aurora MySQL 2 から Aurora MySQL 3 へのアップグレードを開始すると、Aurora はバックグラウンドで自動的に事前チェックを実行して、非互換性を検出します。 これらの事前チェックは必須で、スキップできません。 コミュニティ版 MySQL に含まれるものと、Aurora が導入したものの両方のチェックが含まれます。 詳細については、 Aurora MySQL のメジャーバージョンアップグレードの事前チェック を参照してください。 事前チェックはアップグレードのために DB インスタンスが停止する前に実行されるため、実行している間はダウンタイムは発生しません。 事前チェックで非互換性が見つかった場合、Aurora は自動的にアップグレードをキャンセルし、データベースのダウンタイムを発生させず、5.7 互換のライターインスタンスへの変更も行いません。 Aurora は、Amazon RDS コンソールの ログとイベント セクションと upgrade-prechecks.log ファイルの両方で、非互換性についてイベントを生成します。 errorCount がゼロでない場合、アップグレードが成功しなかったことを示しています。 ほとんどの場合、ログエントリには問題を修正するための MySQL ドキュメントへのリンクが含まれています。 アップグレードを妨げる可能性のあるサンプルのシナリオとその解決策については、 Aurora MySQL バージョン 3 のアップグレードのトラブルシューティング で説明されています。 upgrade-prechecks.log は、Amazon RDS コンソールの ログとイベント セクションで見つけることができます。 また、 aws rds describe-db-log-files に続けて aws rds download-db-log-file-portion を使用することで、AWS CLI を使用することもできます。 アップグレードを開始する前に、 コミュニティエディションの MySQL プリチェッカーツール を使用して既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題の大部分を特定するためのアドホックテストを実行することもできます。 ベストプラクティスとして、本番環境でアップグレードする前に、アップグレードプロセスのテストを行うことをおすすめします。 テスト方法については、 アップグレード前に新しい Aurora バージョンで DB クラスターをテストする を参照してください。 これらのテストを実行することで、Aurora の事前チェックログファイルを使用して、アップグレードの非互換性 (存在する場合) を把握できるだけでなく、事前チェックの実行にかかる時間とアップグレード全体の期間の見積もりが得られます。 アップグレードにかかる期間は、ワークロードとデータベースオブジェクトの数によって異なります。 最後に、Aurora の事前チェックは、プロシージャ定義内の予約語など、データベースオブジェクトの非互換性をチェックします。 アプリケーション側のロジックは検証しないため、予約語やサポート外の構文がアプリケーションにどのような影響を与えるかを確認する必要があります。 アップグレードする前に、すべての機能が新しいバージョンで正しく動作することを確認するために、アプリケーションのテストを十分に行うことを強くおすすめします。 全体的なアップグレードプロセス Amazon Aurora MySQL は、次のフローチャートに示すように、マルチステージのプロセスとしてメジャーバージョンアップグレードを実行します。 Aurora MySQL クラスターのバージョン 2.x からのアップグレードを開始すると、Aurora はまず、前述した対象バージョンとの互換性の問題を特定するための事前チェックを実行します。次にアップグレードに問題がある場合にロールバックできるように、事前アップグレードスナップショットを作成します。データベースは再起動され、データベースに長時間実行されるトランザクションや高い InnoDB History List Length があった場合、このステップで Undo ログ がパージされます。MySQL 8 は データディクショナリ の新しい実装を導入するため、データベースオブジェクトは変更に応じて変換され、クラスターのライターインスタンスが最初にアップグレードされた後、リーダーインスタンスがアップグレードされます。詳細については、 データディクショナリのアップグレード方法 と Aurora MySQL のインプレースメジャーバージョンアップグレードの仕組み を参照してください。 Amazon Aurora MySQL のメジャーバージョンアップグレードの実行 ここまでで背景を確認したので、クラスターを Amazon Aurora MySQL 3 へメジャーバージョンアップグレードする手順について説明します。Amazon Aurora MySQL では、コンソール、AWS CLI、Amazon RDS API を介して DB クラスターを変更することで、メジャーバージョンアップグレードを手動で開始できます。アップグレード中はアプリケーションのダウンタイムが必要になります。Aurora はクラスター全体のエンジンバージョンをアップグレードするため、ライターとリーダーの DB インスタンスのアップグレードが同時に実行されます。ベストプラクティスとして、アップグレードを開始する前に 手動スナップショットを作成 して、ロールバック計画を立てることができます。このセクションでは、簡単な順に次のアップグレードオプションをカバーします。 インプレースアップグレード Amazon RDS ブルー/グリーンデプロイメント スナップショットリストアと Aurora クローン インプレースアップグレード これは最も単純なオプションで、クラスター自体でアップグレードプロセスを実行できます。これは新しいクラスターを作成しません。この手法では、すべてのデータを新しいクラスターボリュームにコピーする必要がないため、同じクラスターエンドポイントとクラスターのその他の特性が維持されます。Aurora がインプレースアップグレードを実行している間、クラスターはダウンタイムを観測します。注意が必要な点は、アップグレードプロセスを途中でキャンセルできず、アップグレードが成功または失敗するまで実行され続けることです。アップグレードプロセス中に問題が発生した場合、Aurora は変更をロールバックしようとします。詳細については、 Aurora MySQL のインプレースメジャーバージョンアップグレードの仕組み を参照してください。 このオプションは本番環境のアップグレードに使用できますが、アップグレード期間中はダウンタイムが発生します。設定が簡単なため、本番で実行する前にアップグレードプロセスをテストすることもできます。インプレースアップグレードを実行する手順の詳細は、 インプレースアップグレードの実行方法 を参照してください。トラブルシューティングのヒントについては、 Aurora MySQL のインプレースアップグレードのトラブルシューティング を参照してください。 Amazon RDS ブルー/グリーンデプロイ データベースのアップグレード中のダウンタイムを最小限に抑えることが最優先事項である場合は、古いクラスタとアップグレードされた新しいクラスタを並行して実行するマネージドプロセスを使用できます。 Amazon RDS のブルー/グリーンデプロイメント を使用すると、新しいクラスタを引き継ぐ準備が整うまで、古いクラスタから新しいクラスタへデータをレプリケートできます。 この機能を使用して、データベースクラスタをアップグレードし、ダウンタイムを最小限に抑え、リスクの低いアップグレードを実現できます。 ブルー/グリーンデプロイメントは、現在の本番環境であるブルー環境と、ステージング環境であるグリーン環境の 2 つのデータベース環境で構成されます。 これらは、MySQL バイナリログレプリケーションを使用して同期されています。 したがって、Aurora MySQL DB クラスタのブルー/グリーンデプロイメントを作成する前に、クラスタは バイナリロギング ( binlog_format ) が有効になっているカスタム DB クラスタパラメータグループに関連付ける必要があります。 まだ有効になっていない場合、この変更にはブルークラスタの再起動が必要です。 ブルー/グリーンデプロイメントの作成手順については、 ブルー/グリーンデプロイメントの作成 を参照してください。 グリーン環境でメジャーまたはマイナー DB エンジンバージョンのアップグレードなどの変更を、ブルー環境に影響を与えることなく行うことができます。グリーン環境でアップグレードをテストした後、 スイッチオーバー を実行して、グリーン環境をプロモートできます。スイッチオーバーのタイムアウトは 30-3,600 秒(1 時間)を指定できます。スイッチオーバーが成功すると、Amazon RDS はグリーン環境のエンドポイントの名前をブルー環境の対応するエンドポイントと一致するようにリネームするため、アプリケーションの変更は必要ありません。スイッチオーバーが成功したことを確認するには、 ブルー/グリーンデプロイのベストプラクティス を参照してください。詳細な手順を含むデモを見るには、 RDS ブルー/グリーンデプロイを使用した Amazon Aurora MySQL バージョン 3 へのアップグレード を参照してください。 スナップショットの復元と Aurora のクローン 開発/テスト環境のアップグレードなど、アップグレード中のダウンタイムをある程度許容できるユースケースでは、スナップショットの復元や Aurora クローンを使用できます。これは、データベースのパフォーマンスとアプリケーションの互換性の観点からメジャーバージョンアップグレードをテストするためのテスト環境を作成する際に役立つことがよくあります。 はじめに、アップグレードしたいクラスタの 手動スナップショット を作成 します。 スナップショットを取得する前に、現在のクラスタへの書き込みワークロードを停止することにしても構いません。 次に、スナップショットから リストア し、リストア中にアップグレードしたい ターゲット エンジンバージョンを選択します。 アップグレードはリストアプロセスの一部として実行されます。 アップグレードが完了し、アップグレードされたクラスタが利用可能になったら、すべてのクライアントトラフィックを新しくアップグレードされたクラスタにリダイレクトします。 ワークロードを再び有効にする前に、新しいクラスタで必要なすべての設定とカスタマイズが適用されていることを確認してください。 不要になったときに元のクラスタを削除できます。 大規模なデータセットの場合、Aurora が 3 つのアベイラビリティーゾーンに分散したストレージクラスターボリュームを構築するため、リストア時間が増加することがあります。 Aurora クローン は、より高速でコスト効率の高いオプションです。書き込みワークロードを停止し、オリジナルのクラスタの Aurora クローンを作成 できます。クローンが利用可能になったら、クローンデータベースでメジャーバージョンアップグレードを実行するために、インプレースアップグレード(前述の通り)を実行できます。アップグレードが完了し、クラスタが利用可能になったら、アプリケーショントラフィックをアップグレードされたクラスタにリダイレクトできます。 スナップショットの取得やクローンの作成前に書き込みを停止するため、どちらのオプションでもダウンタイムが発生します。 加えて、新しいクラスタが作成されます。 これは、クラスタに新しいエンドポイントが割り当てられ、アプリケーションコードをアップグレードされた新しいクラスタを指すように更新する必要があることを意味します。 メジャーバージョンアップグレード方法の概要 次の表はアップグレードオプションの概要を示しています。 方法 メリット デメリット インプレースアップグレード 直感的で便利同じデータベースエンドポイントを維持 アップグレード期間中のダウンタイム RDS ブルー/グリーンデプロイメント マネージド機能効率的リスクとダウンタイムの軽減ブルーとグリーンの環境を同期エンドポイントは自動的に更新 まだ有効になっていない場合、 再起動を必要とする バイナリロギングを有効にする必要があります。 さらに、新しいグリーン環境を作成するため、追加コストが発生します。 スイッチオーバーが実行された後、前のブルー クラスタを 削除 してコストを節約できます。 スナップショットリストア アップグレードのテストや本番環境でのアップグレードに使用 新しいクラスタのリストアとアップグレードにかかる時間のダウンタイム クローン スナップショットのリストアよりも高速 クローンでインプレースアップグレードを実行するためにかかる時間のダウンタイム 最後に、ロールバックオプションを含む 手動のブルー/グリーンデプロイメント を設定するという選択肢もあります。 本番環境のアップグレード前のテスト環境のパフォーマンステスト テスト環境をアップグレードした後、本番環境でアップグレードを実施する前に、データベースのパフォーマンスを監視およびテストすることが重要です。 通常、クエリ実行エンジンはバージョンアップごとに改善されますが、まれに新しいバージョンでクエリが最適ではない実行プランを使用する場合があります。 MySQL 5.7 と MySQL 8.0 の変更 (たとえば、新しいデータディクショナリなど) によってクエリパフォーマンスの違いが観察される可能性があります。 これらのパフォーマンスの不一致を診断するための推奨事項を以下に示します。 Aurora クラスタの過去のパフォーマンスデータを保存し、ベースラインを確立することをおすすめします。このデータを使用して、現在のパフォーマンスを過去の傾向と比較できます。また、通常のパフォーマンスパターンと異常を区別し、問題に対処する手法を考案できます。 Aurora MySQL 2 クラスタからサンプルワークロードをキャプチャし、バージョン 3 でのパフォーマンス変更を確認するために Aurora MySQL 3 で再実行します。 mysqlslap のようなツールを使用して、ブルートフォーステストのためにワークロードを再生できます。ただし、同じパラメータで同一のクエリを再実行するため、結果は異なる可能性があり、追加の検証が必要になる場合があります。 sysbench を使用して Aurora パフォーマンスを評価できます。詳細については、 Amazon Aurora パフォーマンスアセスメントテクニカルガイド を参照してください。このガイドは sysbench を使用してパフォーマンスを評価していますが、bash スクリプトを調整することで、使用するツールを変更できます。 Amazon RDS Performance Insights を使用して、データベースの負荷、上位 SQL クエリ、ユーザー、待機イベントを評価します。データベース負荷が Amazon Aurora MySQL 待機イベント にどのように影響しているかを監視します。これは、パフォーマンスのボトルネックを特定するための最も重要なツールの 1 つになります。 実行に長時間かかるクエリを見つけて、最適化の対象とするために、 Aurora MySQL スロークエリログ を有効にすることを検討してください。 メジャーバージョンアップグレードによって、クエリの実行計画が変更される可能性があります。違いを比較するために、古いバージョンと新しいバージョンからサンプル実行計画を収集できます。さらに、以前のバージョンで force index などの最適化ヒントを使用しているクエリを確認します。これらは、メジャーバージョンアップグレード後に異なる動作をする可能性があります。Performance Insights とスロークエリログを使用して、データベースの待機に最も貢献している上位 SQL を特定した後、これらのツールの一部を使用してクエリを最適化できます。 EXPLAIN を使用すると、クエリの実行に関連する個々のステップが表示されます。 クエリプロファイリング は、現在のセッションで実行されているステートメントのリソース使用状況を示します。 ANALYZE TABLE はテーブルとインデックスの統計を更新します。これにより、オプティマイザがクエリを実行するのに適切なプランを選択できます。 コミュニティ版 MySQL 8.0 と Amazon Aurora MySQL 3 から クエリキャッシュ が削除されています。Aurora MySQL 2 クラスタでクエリキャッシュを使用している場合は、この 変更 がデータベースのパフォーマンス ( SelectLatency などの メトリクス ) にどのような影響を与えるかを確認してください。 MySQL 8.0 コミュニティエディションは一時テーブルを以前の MySQL バージョンとは異なる方法で処理します。この動作の変更は、Amazon Aurora MySQL 3 でも反映されています。ワークロードで多数の一時テーブルが作成される場合は、変更とその影響を確認してください。詳細は、 Aurora MySQL バージョン 3 の新しい一時テーブルの動作 を参照してください。 MySQL 8.0 コミュニティエディションの デフォルト文字セット は utf8mb4 であり、Aurora MySQL 3 でも同様です。アップグレード前に文字セットで必要な変更を確認してください。照合順序の競合のためにテーブルインデックスを使用できない場合、一部のクエリとストアドプロシージャのパフォーマンスが低下する可能性があります。 2 つのバージョン間のパフォーマンスを比較しているため、パフォーマンス関連パラメータのデフォルト値の変更を確認します。これは、問題を隔離および絞り込むのに役立つステップです。詳細については、 変更されたサーバーのデフォルト を参照してください。 モニタリングとアラート アップグレードを開始したら、DB インスタンスのヘルスを監視する方法や、アップグレード中のエラーをチェックする方法を確認しましょう: アップグレードの現在のステータスは、 Aurora イベントを監視する ことで確認できます。アップグレードのステータスを通知するには、 DB インスタンスイベント のアップグレードに対応する RDS イベント ID を購読できます。 Amazon CloudWatch の CPUUtilization や FreeableMemory などのメトリクスを使用して、アップグレード後のリソース消費や、 SelectLatency 、 CommitLatency などのクエリレイテンシーメトリクスへの影響を監視できます。メトリクスの完全なリストは、 Amazon Aurora の Amazon CloudWatch メトリクス を参照してください。 CloudWatch アラーム を使用して、メトリクスが指定したしきい値を超えた場合に通知を受け取り、問題をトラブルシューティングできます。 Aurora アップグレードでは、 初期ステップ には Aurora によるクリーンシャットダウンと、トランザクションロールバックや UNDO パージなどの未完了操作の完了が含まれます。したがって、本番環境でアップグレードを開始する準備をする際には、アップグレード期間に影響を与える可能性のある長時間実行されるトランザクションがデータベースにないことを確認してください。同様に、 高いロールバックセグメント履歴の長さ は、Aurora がターゲットバージョンへのアップグレード前に UNDO ログをパージするため、アップグレードプロセスが遅くなる可能性があります。確認するには、次のコマンドを使用できます: SHOW ENGINE INNODB STATUS SHOW FULL PROCESSLIST SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len"; Amazon Aurora MySQL は、クラスタの起動とシャットダウンでエラーが発生した場合に mysql-error.log ファイルを書き込みます。ログファイルにはタイムスタンプもあり、ログエントリが書き込まれた時刻を判断できます。アップグレード中に問題が発生した場合は、ログを確認できます。詳細については、 Aurora MySQL エラーログ を参照してください。 アップグレードが何らかの理由で失敗した場合は、 mysql-error.log ファイルを確認して、問題をトラブルシューティングできます。エラーがアップグレードの事前チェック中に発生した場合は、 upgrade-prechecks.log ファイルでエラーと解決手順を確認してください。 主な考慮事項 Amazon Aurora MySQL 5.7 から 8.0 へのアップグレード時には、次の重要な点を考慮する必要があります。 メジャーバージョンアップグレード時にカスタムパラメータグループが指定されていない場合、Aurora はターゲットのアップグレードバージョン用に自動的に新しいパラメータグループを作成します。カスタムパラメータグループを使用している Amazon Aurora MySQL インスタンスの場合は、アップグレード時に、現在のバージョンパラメータグループと同様のパラメータを持つターゲットバージョンのパラメータグループを常に選択してください。パラメータの変更については、 Aurora MySQL バージョン 3 のパラメータ変更 を参照してください。 lower_case_table_names パラメータにカスタム値を使用している場合は、この設定をあらかじめカスタムパラメータグループで設定する必要があります。Amazon Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード時には、 lower_case_table_names に同じ設定を使用することをおすすめします。MySQL 5.7 とは異なり、MySQL 8.0 はアップグレード後に lower_case_table_names の値を変更することが制限されます。アプリケーションの要件を確認し、設定する値を決定してください。これを後から変更することはできません。 Amazon Aurora グローバルデータベース を使用している場合は、 グローバルデータベースのインプレースメジャーアップグレード のステップを確認してください。 Aurora Serverless v1 を使用している場合は、 ダウンタイムを最小限に抑えて Aurora Serverless v1 から v2 へアップグレードする を参照してください。 Aurora クラスタに大量のデータベースオブジェクト(テーブル、データベース、イベント、トリガー、ストアドプロシージャなど)が含まれている場合は、 インスタンスクラス を大きくすることで、アップグレードをより高速に完了できるように CPU 容量とメモリリソースを増やすことを検討してください。 結論 この投稿では、Amazon Aurora MySQL 3 のアップグレード手順、異なるアップグレードプロセス、ベストプラクティスを確認しました。 Amazon Aurora MySQL 2.x クラスタをアップグレードし、最新バージョンで利用できる新機能と最適化を活用するために必要なテストを実行することをおすすめします。 アップグレードの詳細については、 Amazon Aurora MySQL DB クラスタのアップグレード を参照してください。 本記事は、 Upgrade to Amazon Aurora MySQL version 3 (with MySQL 8.0 compatibility) を翻訳したものです。翻訳はソリューションアーキテクトの鈴木大樹が担当しました。 著者について Shagun Arora は、Amazon Web Services のデータベース専門ソリューションアーキテクトです。AWS クラウド上でスケーラブルで高可用性かつセキュアなソリューションの設計を顧客とともに行っています。 Dilip Simha は、Amazon Aurora MySQL チームのエンジニアリングマネージャーです。エンタープライズソフトウェア分野に 20 年の経験があり、この 5 年間は Amazon で働いています。 Aditi Sharma は AWS のテクニカルアカウントマネージャーで、RDS データベースチームのクラウドサポートエンジニアとしてキャリアをスタートし様々なデータベースエンジンを取り扱いました。テクニカルアカウントマネージャーの役割に就く前に、AWS でいくつかの役割を経験しています。AWS への入社前は銀行業界でソフトウェア開発エンジニアとして働いていました。管理情報システムの修士号とコンピューターサイエンスエンジニアリングの学士号を持っており、認定スクラムマスター、製品オーナー、AWS Database specialty、AWS Solutions Architect の資格も取得しています。 Isael Pimentel は、複雑なインフラストラクチャの開発と管理に 15 年以上の経験を持つ AWS のシニアテクニカルアカウントマネージャーで、AWS Solutions Architect、AWS Network Specialty、 AWS Security Specialty、MSCA、CCNA など、複数の認定資格を持っています。

[2023 年 7 月 26 日更新] AWS Config は最近、 リソースタイプ別の記録の例外 に対応しました。この変更の前は、すべてのリソースタイプを明示的に設定する必要がありました。このブログはその変更を取り入れ、運用管理を容易にするように更新されました。 AWS の最大規模のお客様の中には、 AWS Control Tower を使用して、複数アカウントの AWS 環境を管理・保護している方もいらっしゃいます。AWS Control Tower は、アカウント登録時に AWS Config を有効化し、セキュリティのベストプラクティスを実装しています。これにより、サポートされているすべての AWS リソースがモニタリングされます。 すべてのリソースをモニタリングすると、必要のないリソースのアクティビティも記録されてしまうという声を一部のお客様からいただくことがあります。本番環境において、コンプライアンス目的で必要な情報を記録することは多くのお客様にとって重要です。しかし、開発環境やステージング環境では本番環境ほど詳細にログを記録する必要はないかもしれません。その場合、記録対象から不要なリソースをフィルタリングすることは、対策となるうえに AWS Config のコストを抑えることにもつながります。 AWS Config の料金は、記録された設定項目数、ルールの評価数、コンプライアンスパックの評価数に基づいて決定します。 詳細は、 AWS Config の料金 を参照してください。 AWS Control Tower で管理されているリソースを直接更新した場合、ランディングゾーンのドリフトが発生する可能性があります。このドリフトは、将来の AWS Control Tower のサービス更新と競合したり、アカウント管理操作のブロッカーとなる可能性があります。 したがって、個々のアカウント内の AWS Config など、AWS Control Tower で管理されているリソースを直接更新することはおすすめしません。 この記事では、アカウントの更新や作成の際に影響を与えることなく、既存の AWS Config サービスを変更するソリューションについて説明します。 先ほど述べたように、ビジネス上の必要性やメリットがない場合、一部のお客様は特定のリソースタイプの記録を AWS Config から除外することがあります。AWS Config ルールと AWS Security Hub は、AWS Config によるリソースの記録に依存しています。したがって、AWS Config レコーダーから特定のリソースタイプを除外する前に、記録しない場合の影響を理解することが不可欠です。 このソリューションをデプロイする前に、AWS Config の料金について理解し、このソリューションが要件を満たすのに役立つか確認する必要があります。これから紹介するステップ 1 と 2 を参照してください: AWS Config のコストについてより深く理解する このソリューションをデプロイして、環境内で重要だと考えているリソースのセットに記録を限定する AWS Config のコスト理解 コストについて理解する第一歩は、多くの場合、 AWS Cost Explorer の確認となります。まず、ここから始めましょう。AWS Cost Explorer の右側にある フィルター を設定して、AWS Config サービスのみが表示されるようにします。また、 ディメンション から「使用タイプ」を選択し、「使用タイプ」でグループ化されるようにします。 下図の例で示すテストアカウントでは、必要な 20 個の代わりに 2000 個以上の Amazon Simple Queue Service(SQS) キューが作成されるという誤った設定をシミュレーションしました。 図 1 では時刻の粒度を日別にしたときに、5 月 9 日に AWS Config のコストが急上昇したのがわかります。実際のドル値のスケールは説明目的で小さくしています。使用タイプでグループ化すると、us-west-2 リージョンの ConfigurationItemRecorded が主な原因であることがわかります。 図 1: 使用タイプ別にグループ化した結果 さらに「連結アカウント」としてグループ化することで、確認のために選択したアカウントのうちどれがコストに影響を及ぼしているかを理解できます。図 2 では、5 月 9 日と 10 日に AWS Config のコストが突然スパイクしたのは、 raovi-2021-aft アカウントが起因だったことがわかります。 図 2: 連結アカウントでグループ化した結果 最後に、個々のアカウントにログインし、AWS Config のコンソールよりダッシュボードを表示して、記録された設定項目のメトリクスを確認してください。コスト上昇を引き起こしているリソースタイプを把握するために、リソースタイプフィルタを適用することもできます。 図 3 のシミュレーション例は、2000 件を超える AWS Config 項目が突然記録されたスパイクを示しています。これにより、 ConfigurationItemRecorded コストが増加しました。 図 3: マネジメントコンソールにおける AWS Config 使用状況メトリクス 図 4: AWS Config 使用状況メトリクスのリソースタイプを使ったフィルター マネジメントコンソールから AWS Config のダッシュボードに遷移し、AWS Config 使用状況メトリクスを確認すると、これらのメトリクスをリソースタイプでさらにフィルタリングできます。 ソリューションの概要 このソリューションは、AWS Control Tower の管理アカウントのホームリージョンにデプロイしてください。このソリューションでは各管理対象アカウントの AWSControlTowerExecution ロールを利用して、すべての AWS Control Tower 管理リージョンの AWS Config レコーダーのリソースタイプを更新します。AWS Control Tower は、アカウント作成プロセス中にこのロールを作成します。ソリューションで提供している AWS CloudFormation テンプレートのデフォルト値は、いくつかのサンプルリソースを AWS Config の記録対象から除外する設定にしています。パラメータはソリューションをデプロイする際にお客様のユースケースに応じて更新できます。 図 5: ソリューション概要 このソリューションは、ランディングゾーンの更新やアカウントの管理など、特定の管理操作に対して AWS Control Tower が生成するライフサイクルイベントを利用します。 Amazon Event Bridge のルールが作成され、 UpdateLandingZone 、 CreateManagedAccount 、 UpdateManagedAccount のイベントが発生した際に、Producer Lambda 関数が起動します。 AWS Lambda の Producer 関数は、AWS Control Tower によって作成された AWS CloudFormation スタックセットをクエリすることで、AWS Config レコーダーがデプロイされているすべてのアカウント ID とリージョンのリストを取得します。 次に AWS Lambda の Producer 関数は、アカウント ID とリージョンのリストを Amazon SQS キューに送信します。 Amazon SQS キュー内の各メッセージが AWS Lambda の Consumer 関数を呼び出します。 AWS Lambda の Consumer 関数はメンバーアカウント内で AWSControlTowerExecution ロールを引き受け、デプロイ時に指定した入力パラメータに従って AWS Config レコーダーを更新します。 CreateManagedAccount と UpdateManagedAccount の 2 つのイベントについては、AWS Lambda の Producer 関数が、特定のアカウント ID の AWS Config レコーダーをデプロイするために AWS CloudFormation スタックセットを使用しているリージョンのリストを取得します。これにより、不要なリソースの使用が回避され、コストが最小限に抑えられます。 デプロイ手順 Git リポジトリ をクローンするか、 template.yml ファイルをダウンロードしてください。Git リポジトリからダウンロードした template.yml ファイルを使用して、AWS Control Tower 管理アカウントのホームリージョンで AWS CloudFormation スタックを 作成 します。2 つのパラメータが提示されるので、1 つずつ見ていきましょう。 ConfigRecorderExcludedResourceTypes パラメータは、記録対象から除外する必要があるすべての AWS Config リソースタイプ のリストです。リストがお客様のユースケースにマッチしていること、コンマ区切りの正しいフォーマットになっていること確認してください。 ExcludedAccounts パラメータは、変更を除外の対象外とする AWS アカウントのリストです。AWS Control Tower の管理アカウント、ログアーカイブアカウントおよび監査アカウントのアカウント ID を置き換えてください。任意でこのソリューションから除外するその他の AWS アカウント ID を追加してください。 パラメータを指定した後、スタックを作成し、スタックのデプロイが成功するのを待ちます。スタックのステータスが CREATE_COMPLETE になると、ソリューションが 1 回実行されます。AWS Lambda の Producer 関数の 1 回の呼び出しと、AWS Lambda の Consumer 関数が数回呼び出されていることを確認してください。 検証 AWS Config レコーダーの変更を確認するには、リンクされた各アカウントにログインし、マネジメントコンソールから AWS Config の設定から リソースタイプ を確認してください。リソースタイプのリストは、スタック作成時に入力した AWS CloudFormation パラメータ ConfigRecorderResourceTypes と一致する必要があります。 図 6: AWS Config 設定画面 さらに、使用状況メトリクスから 記録された設定項目 を確認することができます。この場合、除外している項目のカウントは 0 になります。 クリーンアップ このソリューションをクリーンアップするには、上記のデプロイ手順で作成した AWS CloudFormation スタックを削除してください。 クリーンアップするまで、AWS Cloudformation テンプレートの ConfigRecorderExcludedResourceTypes パラメータで指定したリソースは AWS Config に記録されません。 まとめ 本ブログでは、AWS Config のコスト上昇を特定する方法を学びました。 さらに、ビジネス価値をもたらさないリソースタイプの記録を除外する方法も学びました。 この方法により、既存の AWS Control Tower の設定、将来のランディングゾーンの更新、およびアカウント管理機能への影響を回避できます。 AWS Control Tower と AWS Config を実践的に体験していただくには、 AWS Control Tower ワークショップ をお試しください。 著者: Vijay Shekhar Rao Vijay Shekhar Rao は パートナーソリューションアーキテクトで、グローバルシステムインテグレーターと共にお客様の支援を行っています。 Kishore Vinjam Kishore Vinjam はパートナーソリューションアーキテクトで AWS Service Catalog、AWS Control Tower や AWS Marketplace に非常に詳しいです。 Husain Ali Husain Ali はソリューションアーキテクトでグリーンフィールドのお客様の支援を行っています。

イノベーションは野村グループのDNAです。同社のコーポレート・スローガン「目指すのは、”今”以上の”未来”。」は、新しいテクノロジーを開拓してきた歴史を反映しています。同社は、社員のデジタルスキルを向上させることにより企業の競争力を高めることを目的として、グローバル人材開発チームのイニシアティブとしてDigital IQプログラムを立ち上げました。このプログラムの一環として2023年はAIと機械学習に関する社員の知識を深めるため、AWSと協力してDigital IQ グランプリを開催しました。このグランプリは2023年6月にロンドンで試験的に開催されました。これは、野村グループの社員が各国で現地の仲間と競い合い、ワクワクしながらスキルアップできるように設計されたものでした。 このイベントの小さなスタートは、すぐに参加者に興奮とともに価値を提供することになりました。ロンドンのイベントの成功体験をもとに、野村グループはDigital IQ グランプリを、シンガポール、ポーワイ（インド）、東京、ニューヨークとグローバルに展開しました。 学習とコラボレーションの実現 野村グループがロンドンで 2023年6月の試験的に実施したグランプリの内容を社内で通知をした所、他の地域でもAWS Deep Racer イベントへの関心が高まりました。こうした反応に対して野村グループのDigital IQプログラムチームは、Digital IQ グランプリのグローバル展開を決めて、グランプリ参加希望者向けのオフィスアワーや社内にチャットグループを作り、 AWS のエキスパートを招いたAWS DeepRacer のワークショップを各地域で開催しました。東京でのイベントの前にはAWS Management Console を使ったことのない社員たちがコンソールにログオンして、 AWS DeepRacer がどのように機能するかを学び、 AWS DeepRacer サービスを探索し、コードを書き始め、強化学習について学び、 AWS DeepRacer シミュレータを使って自分のモデルをトレーニングしました。 参加希望者はグランプリに向けて複数人からなるチームを結成し、チーム内でのコラボレーションも始めました。オフィスアワーには大きな反響があり、参加者からは 強化学習に関してやAWS DeepRacer のモデル学習を深く理解するための多くの質問がされました。 ITの壁を破る – 非IT系社員の参加 野村グループのアプローチで特筆すべき点は、IT職ではない参加者を意図的に取り込んだことです。実に東京のイベント参加者の50％以上がIT部門所属ではない方となっており、多様なビジネス・バックグラウンドを持っていました。AIをビジネスで活用するためには、実業務を熟知するビジネス部門の視点が欠かせません。野村のこの意図的な戦略は、テクニカル主体のAIの世界にビジネス部門を招き入れ、AIが自らの業務生産性を上げるためのツールになる可能性があることを理解してもらうために部門を超えたコラボレーションを促進することを目的としていました。実際に東京の AWS DeepRacer イベントで優勝したチームのメンバーは、非IT職の参加者でした。 非IT職の方は業務の中でAIに触れる機会が少ない事もあり、座学のAI/MLトレーニングを提供してもAIは難しいというイメージを持ってしまいがちです。しかし、AWS DeepRacer はゲーム感覚で楽しみながらAI/MLのテクノロジーを体験できるサービスとなっているため、AI/MLを学ぶ最初のステップとして最適なサービスとなっています。 AWS DeepRacer では機械学習のいくつかの方式のうち強化学習という方式を採用しています。強化学習では、与えられた環境に対して最適なアクションの選択を学習します。完全自律型のレースカーが走行するコースが環境、レースカーがどのように走るか（速度や方向）を決めるのがアクションです。決めたアクションが正しい判断だった場合、例えばコースアウトせずに方向転換したというアクションに対して報酬を与えます。これにより、多くの報酬を獲得するための走りかたをトレーニングによって獲得し、より上手に走行できる強化学習のモデルを構築することができます。AWS DeepRacerにおけるモデルトレーニングの成果が、コース上を正しく走るという結果に即時反映されるため、参加者も報酬メカニズムについて理解しやすいというのがAWS DeepRacerの特徴です。 「東京での成功は、 AI がIT専門家だけのものではないことを証明しました。 AI は学び、革新しようとするすべての人のためのものです」と、本イベントのExecutive Sponsor 野村ホールディングスグループＩＴ担当 の堀晃雄氏は述べています。 東京では合計80人以上の社員が38チームに分かれ、予選と決勝を含む54レースで合計311周を走行しました。優勝チームは最速で8.841秒というラップタイムを記録しました。 勢いを維持 野村グループは現在、チャットボット、パーソナライゼーション、ドキュメントスキャナーを使ったビジネス課題の解決など、生成 AI 技術を含む AI をベースとした複数のユースケースの検討やPoCを進めています。Amazon Bedrockの活用も進んでいます。 野村グループについて 野村グループは、グローバルに拠点をもつ金融サービス・グループです。営業、インベストメント・マネジメント、ホールセールという3つの部門が約30の国と地域を越えて連携し、アジアと日本、そして世界をつないでいます。野村グループは、「社会課題の解決を通じた持続可能な成長を実現する」という経営ビジョンのもと、お客様をはじめとしたすべてのステークホルダーの声に応え、創造性豊かで付加価値の高いソリューションを提供しています。 AWS DeepRacer について AWS DeepRacer は、強化学習に対応した 1/18 スケールの完全自律型レースカー、3D レーシングシミュレーター、およびグローバルレーシングリーグを備えた、強化学習 (RL) を自由自在に操る最速の手段です。デベロッパーは、オンラインシミュレーターで RL モデルのトレーニング、評価、調整を行います。学習したモデルを AWS DeepRacer にデプロイし、実際に自律型車両に搭載して、AWS DeepRacer チャンピオンカップを求めて AWS DeepRacer リーグで競争できます。 謝辞 アマゾン ウェブ サービス ジャパン合同会社の下記メンバーからブログの内容についてサポートいただきました。 Yuya Kimura, Arioka Kosuke, Aoki Minoru

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 週刊AWS の記事の最初に、読んでいる方に興味を持っていただけそうな最近の AWS のイベントを一言で紹介することが多いです。今週は別の角度から、「AWS イベントを探す方法」を紹介します。こちらの「 AWS イベントスケジュール 」のページには、直近公開される日本語のイベントが一覧化されていて、業務に役立ちそうなものをピックアップしやすくなっています。また、AWS パートナー様のイベントもリストアップされております。ぜひご活用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年2月5日週の主要なアップデート 2/5(月) Generate AWS CloudFormation templates and AWS CDK apps for existing AWS resources in minutes AWS CloudFormation で既存のリソースから、CloudFormation のテンプレートファイルや、CDK のアプリケーションコードを生成できるようになりました。例えば、AWS マネジメントコンソールで手動で作成した EC2 などのリソースを対象にして、各種設定に基づいたテンプレートファイルを生成できます。これまでは、CloudFormation の外で作成したリソースからテンプレートファイルを生成するには、手動で作成したり、Former2 といった外部のツールを利用することが考えられました。今回のアップデートでこの機能が AWS にネイティブに提供されるようになり、多くのシチュエーションで利用しやすくなりました。 2/6(火) AWS Fargate announces a price reduction for Windows containers on Amazon ECS Amazon ECS on Fargate で Windows コンテナを動かす際の最低課金期間が 15 分から 5 分に短縮され、より実利用時間に即した料金が請求されるようになりました。Fargate の料金は、割り当てた vCPU やメモリに基づき、利用時間を秒単位で計測し計算されます。秒単位で計算する際に、最低課金期間が設定されており、Task をすぐに立ち上げて削除すると、「最適課金期間」が発生していました。この最低課金期間が元々は 15  分だったのが、今回のアップデートで 5 分に短縮され、頻繁に Windows コンテナを立ち上げて落とすような環境でより安価に利用しやすくなりました。 AWS Application Load Balancer announces one-click WAF integrations ALB で AWS WAF とのコンソール統合機能が追加されました。AWS マネジメントコンソールで ALB を新規作成する際に、一定のマネージドルールが設定された WAF Web ACL を同時に作成し ALB にアタッチすることができるようになりました。また、新規だけではなく、既存の Web ACL も選択ができます。今までは、ALB と WAF で個別に設定をする必要がありましたが、ALB の画面の中でスムーズに WAF と統合ができるようになりました。 AWS WAF announces Captcha improvements AWS WAF の Captcha 機能で、使いやすさが向上した新しい Captcha タイプ、8 つの言語での音声 Captcha のサポート、取り消し可能な API キーが追加されました。音声タイプの Captcha では、新たにスペイン語、ドイツ語、フランス語、ポルトガル語、イタリア語、トルコ語、オランダ語、アラビア語の8つの言語をサポートするようになりました。なお、Captcha の読み上げ音声は日本語は対応していません。次に、Grid Captcha と呼ばれる新しい Captcha タイプが追加されました。これは「以下の画像から、イスの画像をすべて選択してください」といった指示が与えられ、それに合致する画像を選択できるかどうか確認するものです。 こちらのドキュメント に新しい Grid Captcha のサンプルが画像付きで紹介されており、気になる方はご参照ください。 Announcing disruption controls for Karpenter このアップデートを説明するために、前提知識が必要なので、少し説明を入れます。Karpenter はオープンソース Kubernetes クラスターオートスケーラーです。需要に合わせて Kubernetes クラスターを構成するコンピュートリソース (例 : EC2) を自動的に増減することで、コスト効率やアプリケーション可用性を高めることができます。今回のアップデートで、Karpenter に disruption controls と呼ばれる「disruption」の方法やタイミングをコントロールする機能が追加されました。「disruption」は、Karpenter で管理している Kubernetes クラスターの EC2 といった仮想マシンリソースを停止する処理を意味する用語です。「disruption」が発生する契機はいくつかあります。例えば、定期的に EC2 インスタンスを入れ替え最新の状態に保つ用途で利用できる「Expiration」、NodePool や EC2NodeClass などの設定変更を行う際の「Drift」、リソースを十分利用していない無駄がある EC2 インスタンスを小さいインスタンスに統合する「Consolidation」などがあります。今回のアップデートで、disruption budgets を設定し、同時に停止できる EC2 インスタンスの割合や数を指定できるようになりました。サービス継続に十分なリソースを確保しつつ、コスト効率化をより改善するメリットがあります。また、disruption budgets は特定の時間帯や曜日によって増減することもでき、通常の期間と重要な期間を分けて管理ができます。詳細は こちらのドキュメント を参照ください。 2/7(水) AWS DataSync now supports manifests for transferring a specific set of files AWS DataSync で、タスクによって転送される対象のファイルを定義するための、マニフェスト機能が新たに導入されました。これまでもフィルター機能があり、例えば特定のフォルダ以下を転送の対象にすることができました。今回のアップデートでは、フィルター機能とは別に具体的に転送したいファイルのリストを Amazon S3 バケットに配置し、タスクを実行することができます。DataSync タスクは毎回スキャンを行うため、ファイル数が膨大になるとタスク実行時間が長くなる可能性がありますが、マニフェストを定義することで、転送のための準備時間が短くなるメリットがあります。 2/8(木) AWS Transfer Family now publishes events to Amazon EventBridge for SFTP, FTPS, and FTP servers AWS Transfer Family でファイル転送を行う際に、Amazon EventBridge へイベントを送ることができるようになりました。Transfer Family の SFTP サーバについては、これまでも workflow 機能がありましたが、AWS Transfer Family 独自のものであり、用意された内容に基づいた処理を行うこと（例えばタグをつける、など）が中心の考え方でした。このアップデートにより、例えば AWS Step Functions を呼び出すことで、独自のデータ加工や前処理を実行できます。単に Amazon S3 にファイルを格納する PUTイベントで実装するのとは異なり、コネクタID や送信側の情報（Transfer Family ならではの情報）を利用して、セキュリティを目的としたフィルターを入れる、取引先ユニークな加工をいれる、といった機能の実装を検討できます。 Amazon MSK Replicator is now available in 9 additional AWS regions Amazon MSK Replicator を使用して、新たに東京リージョンを含めた 9 個のリージョンで、クラスター全体でストリーミングデータをレプリケートできるようになりました。MSK Replicator は Amazon MSK の機能で、数回クリックするだけで、同じ or 異なる AWS リージョンの Amazon MSK クラスター間でデータをレプリケートできます。これまでよりも高い可用性を実現でき、継続性に優れた事業を行うのに役立つ機能です。 2/9(金) Amazon Bedrock console gets a modern look-and-feel Amazon Bedrock のマネジメントコンソールの画面が新しくなりました。UI が更新され、使いやすさ、応答性、アクセシビリティが向上し、新たにダークモードをサポートするようになりました。今までの画面と比べて、よりモダンな見た目に変更されていると感じており、個人的にも気に入っています。 Amazon GuardDuty Malware Protection now supports scanning EBS managed key encrypted volumes Amazon GuardDuty Malware Protection で、EBS マネージドキーで暗号化されたボリュームをスキャンできるようになりました。GuardDuty は、Amazon EC2 インスタンスまたはコンテナのワークロードで悪意のあるソフトウェアを示す不審な動きを特定すると、マルウェア検出スキャンを開始します。GuardDuty が生成する、Amazon EBS ボリュームのスナップショットに基づくレプリカ Amazon EBS ボリュームに対して、トロイの木馬、ワーム、暗号化マイナー、ルートキット、ボットなどのスキャンを実行します。 CodePipeline supports additional trigger filters and new execution modes CodePipeline V2 タイプのパイプラインで、新たにパイプライントリガーのフィルターと、パイプライン実行モードをサポートしました。パイプライントリガーのフィルターでは、glob 形式で、連携する Branch 名やファイルパスを指定できるようになり柔軟性が向上しました。うれしい例を一つあげると、1 個の Repository に複数のコードベースをまとめて管理する Monorepo というアプローチ方法があります。1 個の Repository で管理するため、依存関係がシンプルになるメリットや、統一したビルドツールを横断的に利用できるメリットがあります。今回のアップデートで、ファイルパスを指定できるようになったため、Monorepo 構成で CodePipeline のトリガーができるようになりました。例えば infrastructure/**  と指定することで、「infrastructure」フォルダーが変更されたときだけ Pipeline をトリガーすることができます。詳細は こちらの Blog をご確認ください。 Introducing Amazon Data Firehose, formerly known as Amazon Kinesis Data Firehose Amazon Kinesis Data Firehose が Amazon Data Firehose に名前が変更になりました。Kinesis という単語が消えた形です。Amazon Data Firehose は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake、その他のサードパーティ分析サービスにデータストリームを取り込み、変換し、配信を支援するサービスです。この名称変更は、AWS マネジメントコンソール、ドキュメント、およびサービスのウェブページで有効です。サービスエンドポイント、API、AWS CLI、AWS IAM アクセスポリシー、Amazon CloudWatch メトリクスなどの変更はありません。既存のアプリケーションは以前と同じように動作します。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

OTT の世界における QoS とその重要性について 今日のデジタル時代において、高速インターネットの普及とストリーミング・デバイスの多様化により、OTT（Over-the-Top）コンテンツは日常生活に欠かせないものとなっています。しかし、OTT コンテンツのサービス品質（QoS）を確保するための選択肢が豊富なため、コンテンツ・プロバイダーと消費者の双方にとって重要な課題となっています。国際電気通信連合（ITU）は、ネットワーク管理と保証に重点を置く QoS と、主観的なユーザー満足度を評価する QoE（Quality of Experience）を区別しています。優れた品質体験を実現するには、ネットワーク・パフォーマンスだけでなく、より広範な要素を考慮する必要があります。QoS と QoE を効果的に管理するために、事業者は、QoE についてはリバッファリングやビデオ再生の失敗、QoS については HTTP エラーコード、待ち時間、キャッシュヒットレートなど、業界レベルの主要なメトリクスを監視する必要があります。この継続的な取り組みは、 Amazon CloudFront を中心に、OTT 配信の可観測性を改善し、QoS の側面を強化することを目的としています。 以前の投稿では、 CMCD のソリューションによる QoE の可視性の向上 について説明しました。お客様への可観測性を向上させる取り組みを継続し、この投稿では CloudFront を使用した OTT 配信の QoS 側面について深く掘り下げます。 この投稿について この投稿では、大規模イベントや 24 時間 365 日のリニアストリームにおけるアセット配信の可観測性を向上させるリアルタイムダッシュボードの導入について説明します。CloudFront のリアルタイム・ロギング機能を使用して、このソリューションは配信パフォーマンス指標をほぼリアルタイムで可視化します。これを利用して、動画配信コンポーネントのさまざまな側面への可観測性を拡大することができます。 CloudFront 動画アセット配信ダッシュボードは、ストリーミング解像度と動画アセットに関連するメトリクスを取得します。このダッシュボードは、最も一般的に使用される動画解像度を考慮に入れています。各解像度のデータを分析することで、ダッシュボードは、パフォーマンスの傾向を特定し、視聴者のアセット配信の全体的な品質を向上させることができるデータ駆動型の意思決定を行うのに役立ちます。この情報により、お客様はストリーミング・インフラを最適化し、視聴者に最高の視聴体験を提供することができます。 また、これらのメトリクスをさらにマニフェストとセグメントに分割し、ワークフローに組み込まれたロジックが 2 つの一般的なビデオ・フォーマットである HLS と MPEG-DASH を考慮しています。 アーキテクチャー この画像に示すように、CloudFront 動画アセット配信ダッシュボードを構築するために必要なメトリクスを配信するために、以下のアーキテクチャーが使用されます： 図 1：ソリューション全体のアーキテクチャー 動画コンテンツをストリーミングしているお客様が動画アセットをユーザーに配信する CloudFront ディストリビューションをすでに持っているとします。このことを念頭に置いて、ダッシュボードを現在のメディア配信フローにプラグインし、メトリクスをダッシュボードに入力し始めることができます。ダッシュボードを構築するアーキテクチャーのコンポーネントを以下に示します： 1- CloudFront リアルタイムログ ： CloudFront が各リクエストの詳細をほぼリアルタイムで提供するために必要です。生成されるデータ量を減らし、コストとパフォーマンスを管理するために、この設定のフィールドは、ダッシュボードに入力するために必要な情報だけを提供するように特別に選択されています。トラブルシューティングやその他のユースケースのためにさらなる情報が必要な場合は、 CloudFront 標準ログ を活用することをお勧めします。さらに、リアルタイムログの設定にフィールドを追加する必要がある場合、 AWS Lambda 関数のコードをカスタマイズして追加のフィールドを処理する必要があります。現在使用されているフィールドは以下の通りです： timestamp sc-bytes sc-status cs-uri-stem time-taken x-edge-result-type asn 各フィールドがログに追加する情報の詳細については、CloudFront のドキュメントを参照してください。 2- Amazon Kinesis Data Streams ： これは CloudFront がログをプッシュする最初のサービスです。CloudFront 上のリアルタイムログの設定は、ダッシュボードの構築に必要なフィールドと Kinesis Data Streams を宛先として設定されています。 3- 変換用 Lambda ： データは Amazon Kinesis からバッチで受信され、この Lambda はリアルタイムログからデータを分解し、ダッシュボードに必要なメトリクスを作成するコードを実行します。 4- CloudWatch Logs/メトリクス ： より費用対効果を高めるために、このフローは CloudWatch Embedded Metric Format (EMF) を使ってメトリクスを公開します。EMF を使用することで、PutMetric API コールの実行を避けることができるため、節約になります。メトリクスが送信されるログ・グループは、最大 30 日間データを保持する必要があります。 5- メディア用 CloudWatch ダッシュボード ： メディア配信を監視するメディア配信管理者と運用チームは、ここでメディアアセット配信のメトリクスを分析およびレビューできます。 前提条件 以下の前提条件が必要となります。 このソリューションを使用するユーザーは、各アセットタイプ（HD/UHD/nonHD）ごとに一意の識別子を URL に統合する必要があります。ほとんどの場合、顧客はビデオ資産の解像度に基づいたファイル構造を作成します。さらに、HTTP URL にも同じ構造を適用します。たとえば、超高解像度（UHD）コンテンツをストリーミングする場合、URL の一部として「 soccer_match_uhd 」のような一意の識別子や「 3840×2160 」のような解像度そのものを使用することができます。このソリューションは URL パーサーに基づいており、Query String 内の識別子はこのソリューションでは機能しないことに注意してください。 このソリューションは、お客様の既存の動画ワークフローとシームレスに統合できるように設計されています。ユーザーは、動画ワークフローの一環として、CloudFront ディストリビューションを利用してアセットを配信する必要があります。 ソリューション・メトリクスの深掘り このセクションでは、利用可能なメトリクスとその意味について説明します。以下の画像は、ダッシュボードの動作イメージです。 図 2：ダッシュボードのメトリクスビュー 用語の理解： UHD: UHD は Ultra-High Definition の略で、標準的な高解像度（HD）よりも大幅に高いビデオ解像度を指す。UHD の解像度は通常 3840×2160 ピクセルです。 FHD/HD：HD は High Definition の略で、標準画質（SD）ビデオの解像度よりも大幅に高いビデオ解像度を指す。HD の解像度は通常 1280×720 ピクセル（720p）。FHD はフルハイビジョンの 1920×1080 ピクセル（1080p）を指し、現在の業界では、HD は両方の解像度を指すために使用されることがあります。そのため、ダッシュボードを簡潔にするために、これらの解像度をひとまとめにしました。 SD: SD は Standard Definition の略で、HD 規格よりも低いビデオ解像度を指します。一般的には 480p 以下の解像度を指します。 Segment/manifest delivery latency by Stream ： 視聴者に配信されるコンテンツの待ち時間データを提供します。このメトリックは、マニフェストおよびセグメントファイル別、ストリーム配信タイプ別に分類されます。こちらは、CloudFront がリクエストを受信してからコンテンツが視聴者に送り返されるまでのレイテンシの合計を示しています。 BytesDownloaded per Stream ： ストリーミングされているコンテンツが各ストリームのタイプ間でどのように分割されているかを管理者が理解するためのものです。そして、視聴者ベースの行動を理解するために使用することができます。また、異なる利用ベース間で全体的な配信品質を向上させるために、より多くの収益を提供するコンテンツ品質や、より多くの注意が必要なコンテンツ品質に関するインプットを提供します。 Latency by Autonomous System Number (ASN) ： この指標は、コンテンツがリクエストされ、CloudFront によって提供されるまでの時間を示しています。トップ 10 の ASN と解像度別に分類されています。このメトリクスは、特定の ASN に問題があるかどうかを特定するのに役立ち、ストリーミング配信内の待ち時間の問題を特定するのに役立ちます。これらの特定のメトリクスは、クエリを通じて提供され、過去 3 時間のデータのみが表示されます。 Cache Hit Ratio metrics ： マニフェストおよびセグメント・ファイルの配信に関するキャッシュ・ヒット率メトリクスです。これらは、監視チームがこれらのタイプのコンテンツのキャッシュについて改善の可能性を発見するのに役立つように設計されています。通常、コンテンツが可能な限りユーザーに近いところから配信されていることを確認するため、より高いキャッシュヒット率でセグメントを確認したいと考えます。これは、各解像度の配信ごとに分類されています。 4xx/5xx Error Rates per Stream ： ストリームタイプ別に分類されたエラーレートを示します。これは、ストリームごとのリクエストのエラー発生率を把握するのに役立ちます。レートが上昇した場合、ストリーム・タイプに基づいてトラブルシューティングを迅速に行うことができます。 デプロイ手順 このダッシュボードをデプロイするために、必要なリソースをすべてデプロイする CloudFormation テンプレートが用意されています。 ステップ1 ： CloudFormation コンソールにアクセスしてテンプレートをデプロイします。 ステップ2 ：このCloudFormation テンプレートは、ダッシュボードに必要なすべてのリソースをデプロイします。テンプレートをデプロイする際、いくつかの入力が必要になります： CloudFrontRealTimeLogsSamplingRate ： CloudFront が提供するリクエストがリアルタイムログパイプラインに送られるサンプルレートを定義します。パイプラインを流れるデータが多いほど、このソリューションのコストが高くなるため、これによりコストを制御できます。 UHDExists, FHDExists, HDExists ： これらのパラメータでは、このメディア配信フローに Ultra HD、Full HD、およびHD ストリーミングがあるかどうかを指定します。これらの解像度がメディア配信フローに含まれていない場合は、falseのままにします。 FHDStreamIdentifier ： これは、ユーザーが要求しているコンテンツの URI 内のFHD 解像度ストリームの一意の識別子です。 HDStreamIdentifier ： 前述の「FHDStreamIdentifier」と同様、HD ストリームの一意な識別子です。 UHDStreamIdentifier ： 前述の「FHDStreamIdentifier」と同様、Ultra HD ストリームの一意な識別子です。 図 3：CloudFormation のパラメーター ステップ 3. CloudFormation テンプレートが実行され、スタックの全コンポーネントがデプロイされたら、次のステップはCloudFront  リアルタイムログ設定をメディアコンテンツを提供する CloudFront ディストリビューションにアタッチすることです。これを行うには、以下のサブステップに従います： ステップ3.A. CloudFront コンソールを開き、 ログ > リアルタイム設定 を選択します。 ステップ3.B. CFMediaDashboardLogs 設定を開き、 “ディストリビューションにアタッチ” を選択します。 ステップ3.C. 次のページで、メディアコンテンツの配信に使用するディストリビューションとキャッシュビヘイビアを選択します。次に  “Attach”  を選択します。次の画像のように、メディアアセット（マニフェストとセグメント）を提供するすべてのビヘイビアを選択してください。 図 4：CloudFront のリアルタイムログ 図 5：ディストリビューションへのリアルタイム・ログのアタッチ 設定されたディストリビューションでライブトラフィックが実行されている場合、ダッシュボードにはメトリクスが入力されています。CloudWatch ダッシュボードを開くと、”CloudFrontVideoAssetDeliveryDashboard”という名前のダッシュボードを開くことができます。 ダッシュボードの使用とコストに関する考察 CloudFront 動画アセット配信ダッシュボードソリューションは、複数のシナリオで使用することができます。さらに、AWS のコストモデルに従い、このソリューションは従量課金です。オペレータは、必要性と使用状況に応じて、ワークフローからこのダッシュボードをいつでも開始/停止することができます。 このソリューションに関係する価格設定は、CloudWatch で処理されたデータ、Kinesis にデータが送信されるレートと各レコードのサイズ、CloudFront リアルタイムログリクエスト（生成されるログ行数に基づいて課金される）、Lambda の呼び出し数とその合計時間となります。これらのディメンションはすべて、CloudFront へのリクエストレートと、ソリューションのデプロイ時に選択したサンプリングレートの影響を受けます。 ログ構成が CloudFront ディストリビューションから切り離されるとすぐに、ログの入力が停止し、コストも停止することに注意してください。以下の画像で、どのように設定を切り離すかを確認できます。 図6：リアルタイム・ログの切り離し ダッシュボードのクリーンアップ インフラをクリーンアップするためには、リソースをデプロイした CloudFormation スタックを削除しなければいけません。 クリーンアップが適切に機能するように、2 つのステップを踏む必要があります。 1- CloudFront リアルタイムログを CloudFront ディストリビューションから切り離す必要があります。そのためには、リアルタイムログ設定を開いてディストリビューションから切り離します。 2- 次のステップは、他のすべてのリソースを作成した CloudFormation スタックを削除することになります。スタックの削除が完了すると、すべてのリソースが AWS アカウントから削除されます。 まとめ この投稿では、CloudFront を通じてストリーミング・コンテンツを配信する企業が、ストリーミング配信をより可視化し、OTT ストリーミングアセットの QoS を評価できるように設計された新しいソリューションを紹介しました。 このソリューションの導入により、お客様は動画配信コンポーネントをエンドツーエンドで把握することができます。CloudWatch を使用して CloudFront 動画アセット配信ダッシュボードを活用することで、企業は動画配信ワークフローのパフォーマンスをリアルタイムで可視化することができます。さらに、CMCD ツールを使用することで、顧客はクライアント側のテレメトリーに関する洞察も得ることができ、企業が動画配信戦略を回顧するための完全なデータセットを提供します。このようなエンドツーエンドのアプローチによる動画配信パフォーマンスのモニタリングと分析により、企業は十分な情報に基づいた意思決定と迅速な是正措置を取ることができ、一貫した QoS で高品質のストリーミングコンテンツを確実に提供することができます。 本記事は、「 QoS Observability for OTT Streaming using Amazon CloudFront 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

Amazon QuickSight は、共同作業の場所を問わず、わかりやすいインサイトを提供することができるクラウドネイティブのビジネスインテリジェンス (BI) サービスです。ユーザーはスケジュールされた方法、またはプログラムされた方法で、 SPICE (Super-fast, Parallel, In-memory Calculation Engine) にデータをインポートできます。 QuickSight データセットの更新を設定する場合、更新が失敗したときに所有者に電子メールを送信できますが、一時的なエラーが原因で更新が失敗する可能性があるため、ネイティブに再試行する方法はありません。 この投稿では、更新に失敗したデータセットの取り込みを自動的に再試行するために必要なすべてのリソースを AWS CloudFormation を使いデプロイする方法を示します。これにより、更新が正常に完了したかどうか、障害原因に関する詳細情報がデータセット所有者に提供されるため、ユーザーがデータを利用できるようになるまでの時間を短縮できます。 さらに、QuickSight のアセットは、 Amazon CloudWatch メトリクスを使用して モニタリング できます。 QuickSight の開発者と管理者は、これらのメトリクスを使用して、QuickSight エコシステムの可用性とパフォーマンスをほぼリアルタイムで観察し、対応することができます。 ソリューションの概要 CloudWatch メトリクスを使用して、QuickSight からほぼリアルタイムのイベントをキャプチャし、失敗したデータセット更新の新しい取り込みを開始する AWS Step Functions ステートマシンを対象とする CloudWatch メトリックアラームと、 Amazon EventBridge ルールを設定します。 次の図は、この投稿のアーキテクチャを示しています。Step Functions ステートマシンと関連する AWS Lambda 関数は、CloudFormation テンプレートを通じてデプロイされます。 次のセクションでは、モニタリングしたいデータセット ID を特定し、CloudFormation テンプレートをデプロイ、作成されたリソースを確認、ソリューションをテストし、不要な課金を回避するためにクリーンアップする方法を示します。 前提条件 このチュートリアルを実施するには、以下が必要です: AWS アカウント QuickSight Enterprise Edition のサブスクリプション CloudWatch メトリック、CloudWatch アラーム、EventBridge、QuickSight、Step Functions、Lambda へのアクセス権限を持つ AWS Identity and Access Management (IAM) ロール 使用するサービスと Python の基本的な知識 モニタリングしたいデータセットIDの特定 データセット ID を特定するには、次の手順を実行してください: QuickSight コンソールのナビゲーションペインで、 Datasets を選択します。 モニタリングしたいデータセットを選択します。 ブラウザの URL から、 data-sets/ と /view の間の部分をコピーします。次のような URL になります: https://us-west-2.quicksight.aws.amazon.com/sn/data-sets/4712aba2-6ecc-4521-b009-deb5b276a5f6/view テストに使用できるデータセットがない場合は、次の手順で Amazon Athena テーブルを作成し、データセットを作成できます。 このテーブルを使用して、SPICE にインポートする QuickSight データセットを作成します。更新の失敗をシミュレートするために、テーブルを削除してデータセットの更新を失敗させます。この失敗により、作成したステートマシンがトリガーされ、更新を自動的に再試行します。 Athena コンソールで、 テーブルを作成 します。この投稿では、Athena の CTAS を使用して、 foo_bar というシンプルなテーブルを作成します。 QuickSight コンソールで、ナビゲーションペインの Datasets を選択します。 New dataset を選択します。 Create dataset より、 Athena を選択します。 Data source name に名前を入力し、テーブルの作成に使用した Athena ワークグループを選択します。 Create data source を選択します。 Choose your table セクションで、カタログ、データベース、テーブルを指定します。 Edit/Preview を選択します。 Query mode で、 SPICE を選択します。 Save & Publish を選択し、 Cancel を選択してデータセットビューに戻ります。 このビューから名前を選択してデータセットを開きます。 Refresh タブで、データセットが作成されたときの更新ステータスを確認できます。ここでは Completed と表示されています。 ブラウザの URL から、先ほど説明したようにデータセット ID を取得します。 リソースのデプロイ この手順では、障害発生後の自動取り込みを管理するために、Step Functions ステートマシンと Lambda 関数を作成します。次の手順を実行してください: AWS CloudFormation コンソールを開きます。 コンソール上でテンプレートを開くために、 Launch Stack を選択します。 Next を選択します。 Parameters にある DataSetID へ前の手順で取得した QuickSight データセット ID を入力します。 Next を選択します。 次のページで、 Next を選択します。 最終ページで詳細を確認し、 I acknowledge that AWS CloudFormation might create IAM resources. を選択します。 Submit を選択します。 スタックの作成が完了するまでには約 2 分かかります。 リソースの確認 リソースを確認するには、次の手順を実行してください: AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。 Type が AWS::CloudWatch::Alarm の Physical ID を選択して、リソースを新しいタブで開きます。 CloudWatch アラームの詳細を確認します。 View EventBridge rule を展開すると、EventBridge ルールの基礎となるパターンが表示されます。 ブラウザで、CloudFormation コンソールが開いているタブに戻ります。 Type が AWS::Events::Rule の Physical ID を選択して、リソースを新しいタブで開きます。 Event pattern タブに、EventBridge ルールで説明されていたイベントと同様のイベントが記載されています。唯一の違いは、state に ALARM を追加したことで、ステータスが OK に変更されたときもターゲットがトリガーされないことです。 ブラウザで、CloudFormation コンソールが開いているタブに戻ります。 Type が AWS::StepFunctions::StateMachine の Physical ID を選択して、リソースを新しいタブで開きます。 Edit を選択して、Step Functions のステートマシン定義を開きます。 Lambda 関数を選択し、 View function を選択すると Lambda 関数を開くことができます。 Step Functions のステートマシンロジック ステートマシンが実行されると、Check Previous Ingestions ステートの最初の Lambda 関数が実行され、前回の取り込みのステータスがチェックされます。 最新のステータスが完了している場合、ステートマシンは COMPLETED のステータスを送信し、Success 状態を経由して終了します。 Lambda 関数による更新失敗が特定の回数 (デフォルトでは 6 回) を超えた場合、 TOO_MANY_FAILURES のステータスを送信し、Fail 状態を経由して終了します。リトライ回数は Lambda 関数で設定できます。 ステータスが COMPLETED でも TOO_MANY_FAILURES でもない場合、ステートマシンは Default の状態を経由して、Start New Ingestion 状態の次の Lambda 関数を実行します。その後、フローは 60 秒間待機した後、Get Ingestion Status 状態の Lambda 関数を実行して取り込みのステータスを確認します。この Lambda 関数がステータス COMPLETED を返した場合、ステートマシンは Success 状態を経由して終了します。ステータスが FAILED の場合は Fail 状態を経由して終了します。それ以外のステータスの場合は、再び 60 秒間待機した後、再確認します。 開始される更新の種類は、最後の更新と同じになります。データセットの編集中にエラーが発生する可能性があり、更新タイプ EDIT でエラーが発生します。自動更新プロセスが失敗していないため、この時点ではコードは取り込みを再試行しません。 ソリューションのテスト AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。 Logical ID が DataSourceIngestionFailed の Physical ID で指定されているリンクを選択します。 これにより、モニタリングしているデータセットに関連する CloudWatch アラームが開きます。 データセットのソースを更新できないようにするか、テストのために作成したデータセットを使用している場合は、作成したテーブルを削除してください。 QuickSight データセットから、 REFRESH NOW を選択し、 Full refresh を選択して、 CONTINUE を選択します。 データセットの更新は Failed と表示されます。 1 分待って、CloudWatch アラームのステータスをもう一度確認してください。 アラーム状態は In alarm になります。 CloudFormation スタックの Resources タブで、 Logical ID が QuickSightRestartIngestionStateMachine の Physical ID に指定されているリンクを選択します。 これにより、リトライロジックを実行する Step Functions ステートマシンが開きます。 Name の下にある ID を選択して、ステートマシンの最新の実行を表示してください。 この実行では、取り込みが再試行されましたが、失敗したため、ステータスが Fail に設定されています。 メールアラートを有効にするには、QuickSight コンソールに移動し、ナビゲーションペインの Datasets を選択します。 機能を有効にするデータセットを選択します。 Refresh タブで、 Email owners when a refresh fails を選択します。 このオプションをデータセットで選択した場合、所有者はEメールを通じてすべての失敗の通知を受け取ります。 クリーンアップ 今後の請求を避けるために、作成したリソースを削除してください: AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Delete を選択します。 これにより、スタックによって作成されたすべてのリソースが削除されます。 まとめ このチュートリアルでは、QuickSight データソースの失敗した更新を自動的に再試行するために必要なすべてのリソースを作成しました。 これらのリソースが相互にどのように関連しているか、そしてこのソリューションがデータを自動的に更新することで QuickSight のユーザーエクスペリエンスを改善し、データセットの更新が失敗したときには、QuickSight オペレーターの手動作業を自動化することで、オペレーターエクスペリエンスを改善する方法を示しました。 詳細は、 Amazon QuickSight をご覧ください。 QuickSight コミュニティ に参加して、他のユーザーと質問したり、答えたり、学んだりすることができます。 翻訳はソリューションアーキテクトの松浦が担当しました。原文は こちら です。 著者について Andres Castro  は、グローバルファイナンシャルサービスのグローバルソリューションアーキテクトです。過去25年間、コンサルティングや金融セクターで DevOps エンジニア、ファイナンスデータソリューションアーキテクト、クラウドエンジニアとして働いていました。ビジネスインテリジェンス、データガバナンス、データアナリティクス、その他すべてのクラウドに情熱を注いでいます。

本日は、AWS Cloud Development Kit (CDK) の新機能である CDK Migrate についてご紹介します。この機能を使用することで、ユーザーは以前にデプロイされた AWS CloudFormation テンプレートや CloudFormation スタック、 Infrastrcture as Code (IaC) の管理外で作成されたリソースを CDK アプリケーションに移行できます。この機能は、CloudFormation の管理外で作成されたリソースをテンプレートにインポートし、新しく生成された CloudFormation スタックに取り込むのに役立つ CloudFormation IaC ジェネレーター と同時に公開されています。IaC ジェネレーターの詳細は、 AWS CloudFormation にアプリケーション全体をインポート をご覧ください。 AWS でリソースを作成および管理する方法には、「クリック操作」(マネジメントコンソールでの作成および更新)、AWS API、Infractrcture as Code (IaC) を使用するなどの、さまざまな方法があります。IaC を使用してリソースのライフサイクルを管理することは推奨されるプラクティスですが、導入するためのプロセスが必要かもしれません。IaC の利用に慣れていない担当者は、コンソールを使用してリソースを作成し、更新する可能性が高いでしょう。これは小規模なユースケースや新しいサービスのテストには許容できるかもしれませんが、環境の複雑さが増すにつれて、維持管理はより困難になります。同じ構成を他のアカウント、環境、リージョンに再デプロイする必要がある場合、状況はさらに悪化します。構成を複製しようとすると人的ミスが非常に起こりやすくなります。IaC は、ユーザーが一度定義すればどこでも同じ構成をデプロイできるようにし、この問題を解決します。IaC への移行を遅らせてきた人にとって、IaC ジェネレーターと CDK Migrate を使用して IaC の世界へ飛び込む時が来ました。これらの機能によって移行を加速および簡素化できます。 はじめに AWS CDK へのリソースの移行の最初のステップは、ユーザーが IaC を利用するのに最適なメカニズムを理解することです。 IaC を宣言的に定義したい (YAML のような設定言語を介してリソースを管理したい) ユーザーの場合、CloudFormation テンプレートを生成したり、CloudFormation スタック内の既存リソースを管理したりできる IaCジェネレーター を検討することをおすすめします。 高級プログラミング言語を介して IaC を管理したり、それらのテンプレートの上に高度な抽象化と自動化を構築したいユーザーの場合、AWS Cloud Development Kit と CDK Migrate が優れたオプションとなります。 CDK CLI には、既存の CDK アプリケーションにリソースをインポートする機能もあります。CDK migrate を使用する場合と CDK import を使用する場合の使用例を確認しましょう。 CDK Migrate ユーザーは、1 つまたは複数のリソースを 新規の CDK アプリケーションに移行したいと考えています。 移行対象の AWS リージョン内の既存リソースの例: IaC 管理外で作成されたリソース デプロイ済みの CloudFormation スタック ユーザーは CloudFormation テンプレートから 新規の CDK アプリケーションに移行したいと考えています。 ユーザーは、既存のリソースおよび CloudFormation テンプレートから CDK コードを生成するための一貫した体験を求めています。 CDK Migrate 機能は AWS CDK の利用を加速させることを目的として設計されていますが、制限事項があることを理解することが重要です。 制限事項の詳細については、 ドキュメント をご確認ください。 CDK Import ユーザーは、CDK の外で作成された 1 つ以上のリソースをインポートしたい 既存の CDK アプリケーションを持っています。 AWS リージョン内の移行対象となる既存リソースの例: IaC 管理外で (クリック操作によって) 作成されたリソース デプロイ済みの CloudFormation スタック ユーザーは独自に CDK アプリ内でリソースを定義する必要があり、CDK コードで定義されたリソースがアカウント内の実際のリソースに直接マッピングされることを確認します。この機能を使用するには複数のステップのプロセスに従う必要があります。詳細は こちら を参照してください。 このブログでは、ローカルの CloudFormation テンプレートを取り込み、新しい CDK アプリケーションに変換する方法の例を紹介します。 利用手順 はじめに、CDK アプリケーションに変換される以下の CloudFormation テンプレートを利用します。このテンプレートは、AWS Lambda 関数、AWS Identity and Access Management (IAM) ロール、Amazon S3 バケットを、動的に値を指定するためのパラメータを使用して作成します。 以下がテンプレート全文です: AWSTemplateFormatVersion: "2010-09-09" Description: AWS CDK Migrate Demo Template Parameters: FunctionResponse: Description: Response message from the Lambda function Type: String Default: Hello World BucketTag: Description: The tag value of the S3 bucket Type: String Default: ChangeMe Resources: LambdaExecutionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole HelloWorldFunction: Type: AWS::Lambda::Function Properties: Role: !GetAtt LambdaExecutionRole.Arn Code: ZipFile: | import os def lambda_handler(event, context): function_response = os.getenv('FUNCTION_RESPONSE') return { "statusCode": 200, "body": function_response } Handler: index.lambda_handler Runtime: python3.11 Environment: Variables: FUNCTION_RESPONSE: !Ref FunctionResponse S3Bucket: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: AES256 Tags: - Key: Application Value: Git-Sync-Demo - Key: DynamicTag Value: !Ref BucketTag Outputs: S3BucketName: Description: The name of the S3 bucket Value: !Ref S3Bucket Export: Name: !Sub ${AWS::StackName}-S3BucketName これは、migrate コマンドを実行するときに使用するテンプレートです。 このデモは CloudFormation テンプレートを CDK アプリケーションに移行するものですが、以前にデプロイ済みのスタックや IaC で作成されていないリソースも移行できます。 Migrate CloudFormation テンプレートから CDK への移行は、単一のコマンド cdk migrate で実行できます。 ローカルの CloudFormation テンプレートファイル (ここでは demo-template.yaml とします) を指定するだけで、CLI がテンプレートを CDK アプリケーションに変換します。 このコマンドの出力と結果は、CDK コードと依存関係で構成されるディレクトリになりますが、スタックはデプロイされません。 cdk migrate --stack-name CDK-Local-Template-Migrate-Demo --language typescript --from-path ./demo-template.yaml 上記のコマンドでは、CDK CLI に --from-path パラメータを使用して CloudFormation テンプレートファイルを取り込み、CDK アプリケーションで利用する言語を選択するよう指示しています。CDK CLI はテンプレートを変換するとともに、CDK アプリケーションに必要な依存関係を備えたプロジェクトフォルダを作成します。 移行が完了すると、CDK アプリケーションはプロジェクト構造やファイルとともに使用準備が整いますが、まだデプロイされていません。以下は生成されたファイル構造です: 上記の出力は、デプロイの準備ができた CDK Typescript アプリケーションのディレクトリ構造を表しています。CDK コードは bin と lib の 2 つのディレクトリに格納されています。bin ディレクトリ内には、CDK アプリケーションを作成し、CDK Stack クラスを呼び出すコードがあります。ファイル名は、migrate コマンドの実行時に –stack-name パラメータに渡された入力と一致するので、この場合のファイル名は bin/cdk-local-template-migrate-demo.ts です。以下は生成されたコードです: CdkLocalTemplateMigrateDemoStack がインポートされ、インスタンス化されます。これは、既存の CloudFormation テンプレート (またはスタックやリソース) から変換されたコードが存在する場所です。 上記のファイル名の付け方と同様に、CDK スタックコードのファイル名と場所は lib/cdk-local-template-migrate-demo-stack.ts です。 変換されたコードを見てみましょう。 上記の自動生成されたコードをオリジナルの CloudFormation テンプレートと比較すると、リソースの定義が似ていることがわかります。これは、migrate コマンドが CloudFormation で利用可能なすべてのリソースを表現できる、L1 コンストラクトを使用して CDK コードを生成しているためです。 CDK コンストラクトとコンストラクトが提供するさまざまなレベルの抽象化について詳しくは、この ビデオ をチェックしてください。 CloudFormation のパラメータは、インターフェイス内に定義されたプロパティに変換され、Stack クラスに渡されます。Stack クラスのコード内では、元の CloudFormation パラメータで設定されたデフォルト値に基づいて、プロパティのデフォルト値が設定されます。それらのデフォルト値を指定した値で上書きしたい場合は、次のようにプロパティを CDK スタックに渡すことができます: 新しく作成した CDK アプリケーションで、AWS アカウントにデプロイする準備が整いました。 デプロイ このアカウントとリージョンで CDK を初めて使用する場合は、cdk bootstrap コマンドを実行してください。このコマンドは、CDK がリージョンとアカウントにリソースを適切にデプロイするために必要なアセットを作成します。 詳細は こちら をご覧ください。ブートストラッププロセスが完了すると、デプロイに進むことができます。 作成された CDK アプリケーションはデプロイの準備ができていますが、デプロイする前に cdk diff を実行してデプロイされる内容を確認することをおすすめします。diff コマンドを実行すると、 変更セット が作成され、提案されている変更 (この場合は新規のスタックとリソース) が表示されます。(訳註: 環境によって以下の GIF 画像が表示されない場合があります。 cdk diff の実行の様子が示されています。) 出力から、すべての新しいリソースが作成されようとしていることがわかります。cdk diff コマンドが、既存のリソースやスタックに対して実行された場合 (上記のプロパティの更新のように変更がないと仮定します)、diff は既存のリソースへの変更を示しません。 次に、 cdk deploy コマンドの実行によりスタックをデプロイします 。デプロイが完了したら、AWS コンソールに移動し、Lambda 関数を確認してください。Lambda 関数のテストを実行すると、レスポンスは “CDK Migrate Demo Blog” という functionResponse プロパティの更新内容と一致するはずです。(訳註: body が null となる場合、 lib/cdk-local-template-migrate-demo-stack.ts で CfnFunction の environment で functionResponse を FUNCTION_RESPONSE に変更してください。本事象に関連する issue #28997 #29027 が報告されています。) まとめ この投稿では、CDK migrate コマンドが、CloudFormation テンプレートからであれ、以前にデプロイされた CloudFormation スタックからであれ、CloudFormation IaC ジェネレータ機能を介してリソースをインポートする方法からであれ、リソースを CDK に移行してインフラストラクチャをコードとして管理できるようにするのにどのように役立つかについて説明しました。この機能をテストしてフィードバックや機能リクエストを GitHub の リポジトリ にぜひ投稿してください。さらに、CDK のご利用が初めての方のために、スタートアップの際に役立つリソースがいくつかあります。 AWS CDK Immersion Day ワークショップ CDK Live! (ライブストリームとチュートリアルの YouTube チャンネル) CDK ベストプラクティスガイド 本記事は、 Announcing CDK Migrate: A single command to migrate to the AWS CDK を翻訳したものです。翻訳はソリューションアーキテクトの山崎宏紀が担当しました。