この記事は Amazon EKS now supports Kubernetes version 1.29 (記事公開日: 2024 年 1 月 23 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) チームは、 Amazon EKS 、 Amazon EKS Distro および Amazon EKS Anywhere (リリース 0.19.0) における Kubernetes バージョン 1.29 のサポートを発表できることを嬉しく思います。このバージョンのテーマは、美しい芸術形式である「曼荼羅」で、それは宇宙の完璧さを象徴しています。そのため、リリース名は「Mandala」です。Kubernetes リリースチームは公式リリース発表の中で、このリリースは「コミュニティの相互接続性、熱狂的なファンや専門家によって織り上げられた活気に満ちたタペストリー」を反映していると述べています。 アップグレードの前提条件 Amazon EKS で Kubernetes v1.29 にアップグレードする前に、完了する必要がある重要なタスクがいくつかあります。次のセクションでは、アップグレード前に対処する必要がある変更点の概要を説明します。 FlowSchema と PriorityLevelConfiguration の API バージョンを更新してください。 非推奨の flowcontrol.apiserver.k8s.io/v1beta2 API バージョンの FlowSchema および PriorityLevelConfiguration は、Kubernetes v1.29 では提供されなくなりました。 非推奨のベータ API グループを使用するマニフェストまたはクライアントソフトウェアがある場合は、v1.29 にアップグレードする前にこれらを変更する必要があります。 詳細については、 Deprecated API Migration Guide を参照してください。 Kubernetes 1.29 のハイライト この記事では、Kubernetes バージョン 1.29 リリースの注目すべき機能強化、および削除と非推奨の一部について説明します。まず、このリリースでは v1beta2 Flow control API グループの削除など、いくつかの重要な変更がもたらされることに注意することが重要です。これは、v1.29 にアップグレードする前に、非推奨 API グループを使用しているマニフェストまたはクライアントソフトウェアを更新する必要があることを意味します。最後に、v1.29 には、SidecarContainers のベータ版サポートなど、私たちが楽しみにしている機能強化がいくつかあります。Kubernetes バージョン 1.29 の変更とアップデートの完全なリストについては、Kubernetes の 変更ログ を確認してください。 以下は、v1.29 のリリースに関して私たち技術コミュニティが興奮しているいくつかの機能強化です。完全なリストは こちら を参照してください。 高度な Pod 管理機能がベータ版に到達 Kubernetes v1.29 では、一連の高度なポッド管理機能が導入されます。これらは強力な機能ですが、その影響を総合的にテストし、問題が発生した場合のロールバック計画を立てておくことをお勧めします。何らかの問題が発生した場合は、機能を無効にして kubelet を再起動することをお勧めします。 #753 がベータ版に移行し、SidecarContainers フィーチャーゲートがデフォルトで有効になりました。この機能により、Init コンテナを Pod が終了するまで実行し続けることができ、事実上、Init コンテナをサイドカーコンテナに変えることができます。これは、Pod 内のメインコンテナと並行して実行する必要がある、長時間実行する補助プロセスの管理の問題を解決します。たとえば、Pod にメインアプリケーションコンテナと、メインアプリケーションからログを収集して転送するロギングコンテナがある場合、ロギングコンテナをサイドカーコンテナとして定義できます。これにより、メインアプリケーションコンテナが実行されている間、ロギングコンテナは実行とログの収集を継続し、継続的なログの収集と転送を行うことができます。 セキュリティ強化 #2799 がベータ版に移行し、LegacyServiceAccountTokenCleanUp フィーチャーゲートがデフォルトで有効になりました。この機能により、Secret ベースの未使用の従来のサービスアカウントトークンを自動的にクリーンアップできます。具体的には、従来の自動生成された Secret ベースのトークンが長期間 (デフォルトで 1 年間) 使用されていない場合、無効であるとラベル付けし、無効であるとマークされた後、長期間 (デフォルトでさらに1年間) 使用が試みられなかった場合、自動的に削除します。例えば、Kubernetes クラスターが v1.22 で作成され、自動生成された Secret ベースのサービスアカウントトークンがあった場合、v1.29 にアップグレードした後でも、それらのレガシートークンが残っている可能性があります。この機能は、不要になった古い未使用トークンを自動的にクリーンアップし、潜在的な攻撃対象領域を減らすのに役立ちます。未使用のトークンを使用しているかどうかを確認するには、以下のコマンドを実行してください。 kubectl get cm kube-apiserver-legacy-service-account-token-tracking -nkube-system #3299 が安定版に移行し、Kubernetes v1.29では、KMSv2 および KMSv2KDF フィーチャーゲートがデフォルトで有効になりました。しかし、KMSv2 は現在 Amazon EKS ではサポートされていないことに注意してください。 これは、Kubernetes v1.29 で安定版に移行した最もクールな機能の完全なリストではありません。完全なリストについては、 Graduations to stable を参照してください。 削除された API バージョンと機能 現在では、Kubernetes の新しいバージョンがリリースされると、Kubernetes API のバージョンや機能が非推奨になったり、削除されたりすることは珍しくありません。このような場合、 v1.29 にアップグレードする 前に、すべてのマニフェストとコントローラーをこのセクションに記載されている新しいバージョンと機能に更新することが不可欠です。以下は v1.29 リリースの重要な注意点です。完全なリストについては、すべての Deprecations and removals in Kubernetes v1.29 を参照してください。 ノードの status.nodeInfo.kubeProxyVersion フィールドの非推奨化 Node オブジェクトの .status.kubeProxyVersion フィールドは現在非推奨となり、Kubernetes プロジェクトは将来のリリースでこのフィールドを削除することを提案しています。この非推奨フィールドは正確ではなく、歴史的には kubelet によって管理されてきましたが、実際には kubelet は kube-proxy のバージョンや kube-proxy が実行されているかどうかを知りません。クライアントソフトウェアでこのフィールドを使用している場合は、使用を中止してください。情報は信頼できず、このフィールドは非推奨になりました。 Amazon EKS の Kubernetes バージョンサポート Amazon EKS は現在、7 つの Kubernetes バージョン (v1.23 〜 v1.29) を サポート しています。Kubernetes v1.24 〜 v1.29 は標準サポートで、v1.23 は現在延長サポート中です。Kubernetes バージョン 1.24 は、2024 年 2 月 1 日に延長サポートに入ります。Amazon EKS の延長バージョンサポートについては、 こちらのブログ記事 と FAQ をご覧ください。延長サポートを利用したくない場合は、標準サポートの Kubernetes バージョンへのアップグレードをご検討ください。 まとめ この記事では、Kubernetes バージョン v1.29 の注目すべき変更点を説明し、利用可能となった最もエキサイティングな機能のいくつかを紹介しました。 Kubernetes v1.29 リリースノート に記載されているその他の改善点もぜひチェックしてください。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、 こちら のドキュメントを参照してください。 簡単なアンケート にご参加いただき、今後のブログ記事でご覧になりたい情報をお知らせください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

AI/ML（機械学習）の技術を実ビジネスに活用できるか検証するPoC（Proof of Concept：概念実証）フェーズにおいては、対象範囲を絞った小さなデータセットでMLモデルの構築・評価を行うことがあります。例えば小売業において、特定の店舗や商品カテゴリに絞り、需要予測モデルを構築してみるケースなどです。 PoCでよい結果が得られれば、全店展開や全商品展開など実ビジネスへの導入にむけてプロジェクトが動きますが、ここで課題が発生します。大規模データが対象になったことによる処理時間やコストの増大です。大規模データ処理基盤をいちから検討すると工数がかかり、本番導入への障壁になる可能性もあります。 このような課題解決に向けて、私たちは 小売業で売り上げ数量の予測を実現するサンプルソリューションを公開しました 。この記事では、Amazon Redshift Serverless と Amazon SageMaker を使用した大規模データ活用ソリューションで、実際にさまざまなサイズのデータで検証を行い、本ソリューション利用にかかるコストや時間を示すとともに、検証から得られたソリューション利用のポイントを解説します。 ソリューション 大規模データ処理を高速かつ低コストに実現するためのソリューションを GitHub で公開しています。このソリューションは、小売業を想定したサンプルデータセットを併せて用意しており、店舗別、商品別の売上個数の予測値を算出します。アーキテクチャの詳細は こちら を参照してください。 主な処理は、Amazon Redshift Serverless によるデータの前処理や特徴量生成、Amazon SageMaker によるMLモデルのトレーニング、SageMaker による推論（店別・商品別の売り上げ数量予測）の3つです。 Amazon Redshift Serverless は、大規模なデータに対する分析や加工をコスト効率よく高速に実行できるデータウェアハウスのサービスです。機械学習に必要な前処理をSQLで手軽に実行することができます。また、Serverless であることからインフラストラクチャーの管理が不要であるため、運用にあたってインフラストラクチャーの専門家を配置する必要はありません。 Amazon SageMaker は、高性能かつ低コストの機械学習をあらゆるユースケースで実現するための、包括的なツールセットを提供するフルマネージドサービスです。SageMakerを使用することで、ノートブック、デバッガー、プロファイラー、パイプライン、MLOpsなどのツールを使って、スケール可能なMLモデルの構築、トレーニング、デプロイができます。また、データサイエンティストやMLエンジニアが機械学習モデルのトレーニングとデプロイを迅速に開始できるようにする組み込みアルゴリズムスイートを提供しています。 本ソリューションでは SageMaker ビルトインアルゴリズムの LightGBM を利用しています。売り上げ数量予測は夜間にバッチ処理にて計算する運用を想定し、SageMaker バッチ変換ジョブを用いています。データ規模に対する処理時間とコストのベンチマークのため、MLモデルの予測精度は評価対象外としています。 サンプルデータセット ソリューションには、下の表に示すような商品マスタ、店舗マスタ、イベントカレンダ情報、天気情報、トランザクション（会計）データなどが用意されています。これらのデータは人工的に作成しています。データのさらなる詳細については こちら をご参照ください。 ファイル名 データ名 概要 categories.csv 商品カテゴリマスタ 商品の大分類、中分類、小分類などのカテゴリに関する情報 event_calendar.csv イベントカレンダ 祝日や、全社的なイベントに関する情報。店舗からの入力が必要な「店舗別イベント情報」は用いない。 products.csv 商品マスタ 商品名、カテゴリ、価格などの商品に関する情報 stores.csv 店舗マスタ 店舗タイプや所在地などの店舗に関する情報 transactions.csv 会計記録 1会計処理(トランザクション)を1レコードで記録。購買商品詳細はtransaction_details.csvに記録 transaction_details.csv 会計明細 会計内容の詳細、購買商品の種類ごとにレコードを持つ weather.csv 天気情報 外部システムから取得した日別、都道府県別の天気に関する情報 GitHubにあるサンプルデータ は、10MB程度の小さなものです。今回の検証ではより大きなデータセットを作成し、4つのデータセットに対して検証を行います。データセット名と特徴は以下の通りです。 retail_small : GitHubにある小規模データセット。20商品、3店舗、トランザクション5分に1回。 retail_medium : 中規模データセット。3500商品、200店舗、トランザクション1分に1回。 retail_large : 大規模データセット。3500商品、2000店舗、トランザクション1分に1回。 retail_extra_large : 特大規模データセット。3500商品、20000店舗、トランザクション1分に1回。 各データセットにおける各ファイルの詳細を以下に示します。 ファイル名をクリックするとダウンロードすることができます。   データセット ファイル名 レコード数 サイズ(.csv) サイズ(.csv.gz) 説明 retail_small categories.csv 14 864 B – – event_calendar.csv 19 1.6 KB – – products.csv 20 1.4 KB – 20商品 store.csv 3 200 B – 3店舗 weather.csv 90 6.4 KB – – transactions.csv 25059 2.1 MB – 各店舗5分に1回発生 transaction_details.csv 137559 8.2 MB – – TOTAL 約 16 万 10.3 MB – – retail_medium categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 200 16 KB – 200店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 8352200 726 MB 100 MB 各店舗1分に1回発生 transaction_details.csv.gz 45999200 2.9 GB 310 MB – TOTAL 約 0.46 億 3.7 GB 0.4 GB – retail_large categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 2000 157 KB – 2000店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 83522000 7.2 GB 992 MB 各店舗1分に1回発生 transaction_details.csv.gz 459992000 30 GB 3.1GB – TOTAL 約 4.6 億 37 GB 4 GB – retail_extra_large categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 20000 1.6 MB – 20000店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 835220000 74 GB 9.7 GB 各店舗1分に1回発生 transaction_details_storeid_1_2000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_2001_4000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_4001_6000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_6001_8000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_8001_10000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_10001_12000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_12001_14000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_14001_16000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_16001_18000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_18001_20000.csv.gz 459992000 30 GB 3.1 GB – TOTAL 約 46 億 374 GB 40 GB – retail_extra_largeデータセットのtransaction_details.csvについては、2000店舗ごとにファイルを分けています。データ内容はstore_id以外は各店舗で同一です。 実験：処理時間とコストの計測 4つのデータセットに対して、Redshift Serverless による前処理、SageMaker による学習、SageMaker による推論の処理時間とコストを計測しました。 実施手順 GitHub上に準備されているretail_smallデータセットに対しては、 クイックスタートガイド に従って実施することができます。その他3つのデータセットに対しては、データセットをダウンロードして実施する必要があります。以下にretail_extra_largeのケースについてガイドします。 retail_extra_largeデータセットの検証ガイド クイックスタートガイド:デプロイの準備 「4. 実行環境の準備」において、AWS Cloud9 のリサイズは 500GB とします。データセットのダウンロードで必要なためです。（retail_medium、retail_largeは 100GB で十分） クイックスタートガイド:How to deploy 「1. cdk.jsonを編集」において、パラメータの編集を行います。 “trainingInstanceType”の、”ml.m5.xlarge”を”ml.m5.4xlarge”に変更します。（SageMaker学習ジョブでのメモリ枯渇に対応。retail_medium、retail_largeは変更不要） クイックスタートガイド:Operation 「3. テストデータをアップロード」において、データセットのダウンロード、.gzファイルの解凍、S3へのアップロードを行います。 まず、Cloud9 のターミナルで以下のコマンドを実行し、ファイルのダウンロードを行います。(retail_medium、retail_largeの場合は、-Pオプションの格納先ディレクトリと、ダウンロードURLを変更してください。） <Cloud9 ターミナルで実行> cd /home/ec2-user/environment/retail-large-data-ml-e2e/test wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/categories.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/event_calendar.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/products.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/store.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/weather.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transactions.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_1_2000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_2001_4000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_4001_6000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_6001_8000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_8001_10000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_10001_12000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_12001_14000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_14001_16000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_16001_18000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_18001_20000.csv.gz ダウンロードファイルに含まれる.gzファイルを解凍します。 <Cloud9 ターミナルで実行> gunzip extralargedata/*.gz 解凍したデータセットをCloud9からS3にアップロードします。まず、以下の upload_s3.sh  ファイルを作成します。 <Cloud9 ターミナルで実行> cd /home/ec2-user/environment/retail-large-data-ml-e2e/test touch upload_s3.sh upload_s3.sh を開き、以下の内容を記載します。 <upload_s3.shの中身> #!/bin/bash echo "create prefix in ${INPUTBUCKET}" echo "data size is ${DIR_SIZE}" aws s3 cp ${DIR_SIZE}/categories.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/categories/categories.csv aws s3 cp ${DIR_SIZE}/event_calendar.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/event_calendar/event_calendar.csv aws s3 cp ${DIR_SIZE}/products.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/products/products.csv aws s3 cp ${DIR_SIZE}/store.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/stores/store.csv aws s3 cp ${DIR_SIZE}/weather.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/weather/weather.csv aws s3 cp ${DIR_SIZE}/transactions.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transactions/transactions.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_1_2000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_1_2000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_2001_4000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_2001_4000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_4001_6000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_4001_6000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_6001_8000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_6001_8000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_8001_10000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_8001_10000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_10001_12000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_10001_12000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_12001_14000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_12001_14000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_14001_16000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_14001_16000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_16001_18000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_16001_18000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_18001_20000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_18001_20000.csv この、 upload_s3.sh をターミナルから以下のコマンドで使用します。INPUTBUCKET変数にはS3バケット名(retaildatasolutionstack-inputbucketXXXの正しい名称)を記載してください。 <Cloud9 ターミナルで実行> ### バケット名置き換える export INPUTBUCKET=retaildatasolutionstack-inputbucketXXXXXXXX-XXXXXXXXXXXXX ### Cloud9のデータセットディレクトリ export DIR_SIZE=extralargedata for GENDATE in 2023-04-01 2023-04-15 2023-04-16 2023-04-17 do export PROCESSINGDATE=${GENDATE} bash upload_s3.sh done この後は、 クイックスタートガイド:Operation 「4. ワークフローキック」から手順通りに実行します。 計測方法 Redshift Serverlessについては、AWS Step Functionsの”WakeUpRedshift”から”TrainingKicker”までを処理時間とします。この中で”WaitForWakeUp”は600秒待つ設定となっているので、処理時間から600秒を引いて算出します。 Redshift Serverlessのコストについては、4回ジョブを実行するので、合計コストを4で割った値とします。 SageMaker学習については、SageMakerトレーニングジョブの詳細画面から「請求可能な時間（秒）」を取得し、 インスタンスの単価 から算出します。 SageMaker推論はバッチ変換ジョブの詳細画面から「およそのバッチ変換所要時間」を取得し、インスタンスの単価と数から算出します。 その他条件 リージョン:東京リージョン(ap-northeast-1） 学習インスタンスタイプ: ml.m5.xlarge (retail_extra_largeのみ検証ガイドで述べた通りml.m5.4xlarge) 推論インスタンスタイプ: ml.m5.xlarge cdk.jsonのパラメータ”inferenceInstanceCount”は1とし、負荷分散しない場合の推論処理時間を計測する。 計測結果 計測は2023年12月〜2024年1月のものであり、最新の状況では異なる可能性があることをご留意ください。 東京リージョンにおけるml.m5.xlargeの時間あたり料金は0.298USD、ml.m5.4xlargeは1.19USDになります。（トレーニング、バッチ変換ともに） データセット データサイズ Redshift Serverless 処理時間 [秒] Redshift Serverless コスト [ドル] SageMaker学習 処理時間 [秒] SageMaker学習 コスト [ドル] SageMaker推論 処理時間 [秒] SageMaker推論 コスト [ドル] TOTAL 処理時間 [秒] TOTAL コスト [ドル] retail_small 10.3 MB 259 4.48 77 0.00637 120 0.00993 456 4.4963 retail_medium 3.7 GB 558 7.755 167 0.01382 240 0.01987 965 7.78869 retail_large 37 GB 2159 28.295 924 0.07649 1320 0.10927 4403 28.48076 retail_extra_large 374 GB 4136 70.58 2584 0.85416 12420 1.0281 19140 72.46226 処理時間を [秒] から [時分秒] へ、コストを [ドル] から[円] へ変換して以下に示します。(1ドル = 150円換算) コストは少数第2以下切り捨てで表示しています。 データセット データサイズ Redshift Serverless 処理時間 [時分秒] Redshift Serverless コスト [円] SageMaker学習 処理時間 [時分秒] SageMaker学習 コスト [円] SageMaker推論 処理時間 [時分秒] SageMaker推論 コスト [円] TOTAL 処理時間 [時分秒] TOTAL コスト [円] retail_small 10.3 MB 4分19秒 672.0 1分17秒 0.9 2分0秒 1.4 7分36秒 674.4 retail_medium 3.7 GB 9分18秒 1163.2 2分47秒 2.0 4分0秒 2.9 16分5秒 1168.3 retail_large 37 GB 35分59秒 4244.2 15分24秒 11.4 22分0秒 16.3 1時間13分23秒 4272.1 retail_extra_large 374 GB 1時間8分56秒 10587.0 43分4秒 128.1 3時間27分0秒 154.2 5時間19分0秒 10869.3 さらに処理時間を短縮するために 前処理に関しては、データの規模がさらに大きくなり、処理時間が問題になってきた場合は、Amazon Redshift Serverlessの処理能力をスケールさせることで対応することができます。Amazon Redshift Serverlessではベースの処理能力をRPU (Redshift Processing Unit) という単位で設定することができます。この値を大きくすることで処理能力を増大させ、処理の実行時間を短縮することができます。Amazon Redshift Serverlessの料金体系はRPUとクエリ実行時間を掛け合わせたものであるため、例えばRPUを2倍にすることで実行時間を半分にできたとすると、合計の料金が変わることなく実行時間を短縮することができます。 SageMaker学習に関しては、今回は1インスタンスで実施したが、長時間になることはありませんでした。しかし特徴量の数やハイパーパラメータによっては長時間化する可能性があります。その場合の選択肢として、 SageMakerビルトインアルゴリズムのLightGBMは分散学習機能を実装 しています。 SageMaker推論に関しては、retail_extra_large場合でも5時間強、10000円強程度であったことは、夜間のバッチ処理を想定しても実用に耐えうる値と思われます。また、今回は推論インスタンスを１で実施しましたが、”inferenceInstanceCount”パラメータを1より大きくすることで分散して推論処理を得られることができます。参考に、”inferenceInstanceCount”を4にした場合、3時間27分が55分となりました。単純に1/4の時間にはなりませんが、処理時間をパラメータ変更のみで大きく短縮することができます。 まとめ 本稿では、「 小売業で売り上げ数量の予測を実現するサンプルソリューション 」を活用することで、コストを抑えつつ、大規模データを短時間で処理できることを示すために検証を行いました。POCのデータサイズでは問題にならなくても、大規模データを利用する本番環境ではコストや時間が課題になることがあります。 今回の検証では、データサイズの増加にあたって並列度をあげることで時間が短縮できること、370GB、47億レコードのデータに対して5時間強、10000円強程度で処理が可能という結果を得ました。これは本ソリューションが大規模データにおいて高いコストパフォーマンスを提供することを示しています。 一方で、あくまで今回のデータセットに対しての結果であり、別データでも同じ性能が出るとは限らない点に注意が必要です。データや前処理ロジック、モデルパラメータで異なりますので。本稿を参考に、自社のデータでも試していただければと思います。 著者について 伊藤 芳幸(Ito Yoshiyuki), シニア機械学習ソリューションアーキテクト 生成AIを含むAI/ML技術の支援を担当しています。事業会社での経験を生かし、ビジネス上の課題を解決するためのAI/MLソリューションの提案や導入支援に努めています。新しい技術に触れることは楽しみの一つで、積極的に手を動かしています。 プライベートでは育児に忙しい日々を送っていますが、フットサルやジム通いを通じてストレスを発散しています。 秋田 仁雅(Akita Yoshinori), プロトタイピングエンジニア 普段は AWS を用いてプロトタイプを開発することでお客様の課題を解決するプロトタイピングエンジニアという業務を担当。 平間 大輔(Hirama Daisuke), Redshift スペシャリストソリューションアーキテクト AWSでは主にデータウェアハウスサービスのAmazon Redshiftに関する技術支援を担当。パフォーマンスチューニングが大好物。プライベートでは最近レトロPCいじりにハマっています。 下佐粉 昭(Shimosako Akira, @simosako ), シニアソリューションアーキテクト (アナリティクス) AWS ではデータレイク、データウェアハウス、BI 等アナリティクス領域専門のエンジニアとして活動。分析システムを AWS 上で稼働させるための技術支援を行いつつ、オンラインセミナーやイベントを通じて、新しい考え方や技術を広くを伝える活動をしている。 最近は「週刊 AWS」で、AWS の最新情報を伝える活動も行っている。プライベートは完全なインドア派でスポーツ観戦・観劇・絵画や映画の鑑賞と体を動かさないことに時間を費やしているが、そろそろ運動する習慣を作らないとヤバいのではと焦る日々。

このブログでは、大規模言語モデル（LLM）、Amazon Bedrock、Amazon OpenSearch Service を使用しておすすめの映画を教えてくれるチャットボットを作成する方法をご紹介します。このデモンストレーションでは、幅広いエンターテイメントのメタデータを提供する IMDb and Box Office Mojo Movies/TV/OTT のライセンス可能なデータパッケージを使用します。Amazon Web Services（AWS）の Media & Entertainment（M&E）のお客様の多くは、 AWS Data Exchange を通じて IMDb データのライセンスを取得しています。これにより、コンテンツが見つけやすくなり、顧客エンゲージメントと定着率が高まります。完全一致クエリとセマンティック一致クエリの両方において、IMDb データセット上に検索拡張生成（RAG）チャットボットを構築する方法について説明していきます。 背景 映画やテレビ番組を見ているときに、「他にもこのような映画がないかな？」、「この映画の俳優は他にどんな映画に出演しているのかな？」などと思ったことはありませんか？このブログ記事では、Amazon Bedrock サービスの LLM と IMDb などの外部データソースを使ってこれらの質問に答える方法をご紹介します。 この記事では、オンラインの M&E プラットフォームで会話型検索を有効にして、使いやすいユーザーエクスペリエンスを提供する方法について順を追って説明します。昨今、LLM はさまざまな自然言語処理や自然言語理解（NLP/NLU）タスクの分野で画期的な成果を上げています。LLM は、未加工のユーザーの意図を正確に理解し、特定のコンテキストに沿った結果を生成することができます。また、いくつかの例（few-shot 学習）を与えることで、RAG 技術を通じてナレッジベースに基づいて質問に答えることができます。これらの技術と IMDb のようなデータセットを併用することで、ストリーミングプラットフォームのユーザーは「トム・クルーズが出演するコメディー映画」や「ロンドンで撮影されたトム・ホランド出演のスパイダーマンの映画」などの高度な検索クエリを作成することができます。さらに、LLM の会話機能のおかげで、ユーザーは洗練されたクエリから始める必要がなくなります。ユーザーは LLM に一連の探索的なクエリを実行し、興味のある映画を絞り込むことができます。 IMDb と Box Office Mojo Movie/TV/OTT のライセンス可能なデータセット AWS Data Exchange の IMDb データセットは、16 億件を超えるユーザー評価、1,300 万人を超えるキャストとクルーのクレジット、1,000 万本もの映画/テレビ/エンターテイメント作品、ならびに 60 か国以上の世界の興行収入レポートデータを保持しています。 大規模言語モデル（LLM） 大規模言語モデル（LLM）は、一連の単語やフレーズを予測できるように、膨大な量のテキストデータを用いた広範囲にわたるトレーニングされた人工知能（AI）モデルです。これらのモデルは、言語翻訳、テキスト生成、感情分析など、さまざまな自然言語処理業務に精通しています。特にラベル付けされたデータが不十分な状況で真価を発揮し、ラベル付けされていないデータから単語の適切な文脈や解釈を予測できるため、人の言葉に近いテキストを作成することができます。 検索拡張生成（RAG） 検索拡張生成（RAG）は、コンテンツの検索と生成を組み合わせたニューラルテキスト生成手法です。LLM の最近の進歩により、一貫性のある流暢なテキストを生成できるようになりました。しかしながら、これらのモデルは生成機能のみに依存しているため、事実に即した正確で一貫性のあるテキストの生成は苦手です。この問題を克服するために、研究者たちは、ニューラルテキスト生成とニューラル情報検索を組み合わせた RAG を提案しました。まず、検索モデルを使用してナレッジソースから関連情報を取得します。ここで取得した情報が、その後のテキスト生成プロセスに情報を提供する基盤となります。次に、取得した情報はニューラルテキスト生成モデルに統合されます。この統合は、生成プロセスをガイドし、制約を課す役割を果たします。この方法を組み合わせた結果、生成モデルは、取得した情報と一貫性のある、より事実に即した出力を生成できるようになります。 Amazon OpenSearch Service Amazon OpenSearch Service は、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できるフルマネージドサービスです。OpenSearch は、Elasticsearch から派生したオープンソースの分散型検索および分析パッケージソフトです。OpenSearch Service は、OpenSearch の最新バージョンに加え、19 バージョンものElasticsearch（バージョン 1.5 から 7.10）をサポートしているほか、OpenSearch Dashboards と Kibana（バージョン1.5から7.10）を利用した視覚化機能も提供しています。 アーキテクチャ IMDb and Box Office Mojo Movie/TV/OTT のデータセットを使って会話型検索とチャットがどのように行われるかを見てみましょう。 次の図は、（1）ユーザークエリを受信して結果を表示するフロントエンドとして機能する Streamlit アプリ、（2）クエリを処理してレスポンスを得る多数のバックエンドコンポーネントで構成されるソリューションアーキテクチャを示しています。 まずユーザーは、Streamlit アプリを操作して検索するユースケースに関連するクエリを入力します（上図に青丸で表示）。これには、特定のジャンルや特定の俳優が演じる映画を検索する質問などが含まれます。 バックエンドでは、Amazon Bedrock の LLM を使用して、ユーザークエリを OpenSearch ドメイン固有言語（DSL）クエリまたはエンベディングに変換します。たとえば、下記のユーザー検索クエリ： "What movies are starring Tom Cruise?" （トム・クルーズが主演している映画は？） は下記の検索クエリに変換されます。 {"query":{"bool":{"must":[{"terms":{"stars.keyword": ["Tom Cruise"]}}]}}, "sort": [{"rating": {"order": "desc","missing":"_last", "unmapped_type" : "long"}}]} 検索クエリは、OpenSearch インデックス（ここでは、全文インデックスと kNN ベースインデックスの両方を作成します）に保存されている IMDb and Box Office Mojo データセット内の最も類似した記録を返します。レスポンスには、映画のプロット、公開日、ジャンル、ロケーション、評価、監督、プロデューサーなど、関連する映画に関する情報が含まれます。 目的の出力を得るための理想的なプロンプトや指示（プロンプトエンジニアリング）は、LLM によって異なる場合があることに注意してください。 こちら で指示を変更して、選択した LLM に合わせて最適化することができます。 検索結果を受け取った後、ユーザーは仮想エージェントのアクティブ化を選択できます。このエージェントは、検索クエリに対するレスポンスドキュメントと LLM を使用して、検索結果で見つかった映画に関するいかなる質問にも回答できます。さらに、チャットインタラクションにはセッション固有のメモリが保持されるので、仮想エージェントは回答する際に以前のユーザー検索クエリを参照することができます。 前提条件 このソリューションを実装するには、AWS アカウントが必要であり、OpenSearch サービスと Bedrock に精通している必要があります。このアプリケーションをテストするための大まかな手順は次のとおりです。 IMDb データセットの作成 IMDb エンベディングの生成 OpenSearch インデックスの作成 Streamlit アプリケーションのローンチとテスト AWS CloudFormation によるリソースのプロビジョニング ソリューションの構造をご理解頂いたところで、ソリューションをアカウントにデプロイしてサンプルワークフローを実行することができます。このワークフローは、Amazon OpenSearch Service と Amazon SageMaker Studio ドメインを適切な設定の VPC モードで起動します。 スタックは、GitHub リポジトリの cloudformation template を使用して、AWS CloudFormation コンソールの AWS Region us-east-1 上でローンチできます。 1.     IMDb データセットの作成 1.1 データを Amazon S3 にエクスポートする IMDb データセットを使用するには、以下の手順に従います。 Step 1: AWS Data Exchange で IMDb データにサブスクライブする こちらのリンク（ https://console.aws.amazon.com/ ）から AWS Management Console にログインする。 検索バーで AWS Data Exchange を検索し、 [AWS Data Exchange] をクリックする。 左側のパネルの [Browse catalog] をクリックする。 [Browse catalog] の検索ボックスに [IMDb] と入力する。 IMDb and Box Office Mojo Movie/TV/OTT Data（SAMPLE） または IMDb and Box Office Mojo Movie /TV/OTT Data（PAID） のいずれかにサブスクライブする。 IMDb は毎日 1 回、データセットを AWS Data Exchange に公開しています。 Step 2: IMDb データを ADX から Amazon S3 にエクスポートする こちらの ワークショップ の手順に従い、IMDb データを ADX から Amazon S3 にエクスポートする。 Step 3: ファイルを解凍して title_essential_v1_complete.jsonl および name_essential_v1_complete.jsonl を取得する 1.2 IMDb データセットを処理する IMDbデータをインデックス作成に使用するには、未加工データを表形式に処理する必要があります。まず、IMDbファイルを統合して映画のタイトル情報を映画のキャスト/スタッフの情報とマージし、俳優や監督などのすべての名前を1つのデータセットにまとめます。次に、それをMovieLensデータに含まれる映画の小さめのセットと合わせてサブセットを作成し、映画の数を減らして小さなカタログ状にします。このサブセットの作成は任意であり、データセット全体を処理することも可能です。 2つのIMDbデータセット（code）をマージする手順は次のとおりです。   title_essential データセットを列でフィルタリングする： `[‘image’, ‘titleId’, ‘originalTitle’, ‘titleDisplay’, ‘principalCastMembers’, ‘principalCrewMembers’, ‘genres’, ‘keywordsV2’, ‘locations’, ‘plot’, ‘plotShort’, ‘plotMedium’, ‘plotLong’, ‘imdbRating’, ‘year’, ‘titleType’]` 列 principalCastMembers  列をカテゴリ別に分割し、Actors、Directors、Producers の 3 つの列を新たに作成する。（これらの列には数字のIDしか含まれていません） name_essential データセットのマッピングからキャストメンバー（俳優、監督、プロデューサー）の実際の名前を含めて、映画データセットに追加する。 キーワード、ロケーション、ポスター URL の処理済みバージョンを追加する。 結果を Parquet ファイルとして S3 に保存する。（例：s3://<bucket>/<folder>/movies.parquet） IMDb データセットが作成されると、追加の処理ではデータセットのサイズを小さくするために、小さい方の MovieLens データセット（ml-latest-small.zip）の映画だけが保持されます。データスキーマの一貫性を保ちつつ、大きな IMDb データセットを処理したい場合は、このステップを省略できます。 こちら のノートブックから、以下のステップを実行してください。 未加工のIMDbデータセット全体をフィルタリングして、Movie Lens データセットに含まれる映画のみにする。 ロケーションを処理して、都市名と国名の重複を削除する。 結果を Parquet ファイルとして S3 に保存する。このファイルへのデフォルトパスは s3://<bucket>/<folder>/imdb_ml_data.parquetです。 以下は、サンプルデータセットのサブセットのスナップショットです。 2.     エンベディングの作成 前述のデータセットは、「トム・ハンクスの映画にはどんなものがある？」などのクエリをフィルタリングするのに役立つかもしれませんが、「スナイパーアクション映画にはどんなものがある？」などのクエリに答えるためには、データセットを豊富なセマンティック情報でさらに強化する必要があります。 そのためには、 こちら のノートブックの指示に従い、以下のタスクを実行してください。 1.     movielens-20m データセット からの信頼性の高いキーワードで  IMDb キーワードを強化する。このステップは任意です。 2.     T5 large モデルの sentence-transformer を使用して、「プロット」、「キーワード」、「プロット+キーワード」列のエンベディング（サイズ 768）を生成する。 3.     エンベディングを元の映画データセットに追加し、Parquet ファイルとして S3 に保存する。 次に、 リポジトリ に戻り、 src/ フォルダで以下を実行します。 python index_creation.py このコマンドは以下のタスクを実行します。 Boto3 Python ライブラリを使用して OpenSearch Service クライアントを初期化する。 IMDb データセットの空白のエントリを NULL で埋める。 テキストと kNN エンベディング検索用に 2 つのインデックスを作成し、ingest_data_into_os 関数を使用して結合されたデータフレームからデータを一括アップロードする。 インデックスが作成されたら、 config.yml のドメイン名とインデックス名を更新します。 このデータ取り込みプロセスには 5～10 分かかります。この例では、テキストベースの検索と kNN エンベディングベースの検索を可能にする 2 つのインデックスが作成されます。テキスト検索は、ユーザーが入力する自由形式のクエリを映画のメタデータにマッピングします。「クリストファー・ノーラン監督の映画」、「俳優トム・ハンクスが出ている映画」などのクエリは、監督やプロデューサーなどの特定のメタデータにマッピングされるため、直接テキスト検索に使用されます。しかし、「スナイパーアクション映画にはどんなものがある？」などの自由形式のクエリは、エンベディングベースのセマンティック検索にルーティングされます。kNN エンベディング検索では、エンベディングの潜在空間から最も近い k 本の映画を見つけて出力として返します。 OpenSearch インデックスの詳細については、 こちらのブログ記事 を参照してください。 3.     Streamlit アプリを作成 OpenSearch でテキスト検索と kNN インデックスが動作するようになったので、このユースケースのフロントエンドを作成する Python パッケージである Streamlit を使用して ML を利用したアプリケーションを構築できます。 コードを実行するには、まず Streamlit と aws_requests_auth が Python 環境（EC2 や ECS コンテナなどの適切なコンピューティングインフラストラクチャ）にインストールされていることを確認する。提供されている コードリポジトリ は Amazon SageMaker Studio 上で Streamlit を実行します。以下のコマンドを使用して要件をインストールします。 pip install -r requirements.txt streamlit/フォルダーに移動して以下を実行し、Streamlit アプリの SageMaker Studio の URL を取得する。 sh run.sh 次に、Streamlit アプリケーションを実行してポート番号を取得する。 streamlit run chat.py SageMaker Studio の URL とポート番号を{sm_studio_url}/{ port_number }/ のように組み合わせます。 Streamlit アプリでは次のように表示されます。 検索とチャット IMDb 会話型検索アプリケーションに移動したら、以下を選択できます。 LLM このデモンストレーションでは、LangChain を使用して、LLM として Amazon Bedrock（Claude-V1）を利用しています。 Task type（タスクタイプ） 「検索（Search）」または「検索とチャット（Search and Chat）」。特定のクエリにサブスクライブしている IMDb データセット内の映画だけを特定したい場合は、「検索」を選択します。検索クエリで出力された映画についてさらに質問できるようにチャットボットにもアクセスしたい場合は、「検索とチャット」を選択します。検索およびチャット機能は、選択した特定の LLM によって実行されます。 Question（質問） 検索のユースケースに対する質問を選択します（タスクタイプに「検索」を選択した場合も、「検索とチャット」を選択した場合も）。アプリケーションには一連のデフォルトの質問のほか、次に示すように独自の質問を追加するオプションが用意されています。 検索のユースケースに対する質問は、次のいずれかに分類されます。 完全一致:ロケーション、俳優、プロット、評価、監督などに基づいた映画の検索 セマンティック一致:他と似ている映画の検索 たとえば、「トム・クルーズが主演するアクション映画にはどのようなものがありますか？」という質問をした場合、LLM は、IMDb データセット内の映画の中で、これと完全に一致するものを検索し、次の出力を生成します。 さらに、「検索とチャット」機能を選択した場合、次のチャットインターフェースがアプリケーションに出力されます。 現在、チャットチェーンはコンテキストの長さを維持するために一度に 5 つの質問に対応しています。ただし、コンテキストの長さを一定に保つために、コンテキストをチャンク化したり、最後の k 件の会話履歴をストーリー化するなどの高度な方法を試すこともできます。 レコメンデーションによる検索結果の強化 現在のシステムは検索インデックスからコンテンツを汎用的に取得しますが、 Amazon Personalize のリランキング サービスなどの別のツールと連携させて、これまでにキャプチャされたユーザー履歴に基づいて検索結果を並べ替えることもできます。 まとめ 本記事では、Bedrock と OpenSearch サービスによるテキスト検索と kNN ベースの検索を使用して、IMDb データセットの上に会話型検索を構築するソリューションを構築する方法について説明しました。このアプリケーションは LLM を使用して、ユーザーの質問を OpenSearch 経由でクエリできるコマンドに変換し、また特定の映画についてさらに質問するための会話型仮想エージェントを提供します。 この記事のコードサンプルの詳細については、 GitHub リポジトリをご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 石井が担当しました。原文は こちら をご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近本当に寒くなりましたね。毎朝ウォーキングをしていたのですが、最近は零度を下回ることもあり、代わりに昼休憩にウォーキングをするようになりました。春になるまでは昼ウォーキングにして、春になったらまた朝に戻そうと思っています。 さて、AWSでは、AWS re:Inventの内容をまとめて日本語でお伝えするAWS re:Invent Recapを年初に実施していますが、今年はインダストリー編（業界ごと）とソリューション編（AWSサービスごと）の２つに分けて実施予定です。インダストリー・ソリューション別に時間を区切っているので、興味があるところに出やすい構成にしています。ぜひご参加ください。 – AWS re:Invent Recap – インダストリー編 2024 年 1 月 30 日（火）〜 2 月 1 日（木） – AWS re:Invent Recap – ソリューション編 2024 年 2 月 6 日（火）〜 9 日（金） それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月15日週の主要なアップデート 1/15(月) 米国祝日のためこの日の発表はありませんでした 1/16(火) AWS Transfer Family provides static IP addresses for SFTP connectors AWS Transfer for SFTP connector で固定的なIPアドレス設定がサポートされました。SFTP Connector は、リモートのSFTPサーバーとS3間のファイル連携を提供するTransfer for SFTP の機能です。この新機能はConnectorを作成する際に自動的に複数の固定IPアドレスが付与されるもので、リモートのSFTPサーバーでのIPアドレスフィルタリングを容易にします。 Amazon Corretto January, 2024 quarterly updates Amazon の無料 OpenJDK ディストリビューション Amazon Corretto の四半期アップデートが公開されました。Corretto 21.0.2, 17.0.10, 11.0.22, 8u402 がリリースされています。それぞれバグフィックス・セキュリティフィックスを含むため、早めの更新をお勧めします。 Amazon RDS for MySQL now supports multi-source replication Amazon RDS for MySQL でマルチソースレプリケーションがサポートされました。名前の通り、最大15のソースDBから1つのDBへのレプリケーションをサポートします。本機能はRDS for MySQL 5.7.44以降、もしくは8.0.35以降で利用可能です。 1/17(水) GLIDE for Redis, an OSS Redis client sponsored by AWS, now available in preview GLIDE (General Language Independent Driver for the Enterprise) for Redis という、OSSのRedisクライアント実装が公開されました。RESP (Redis Serialization Protocol) を高い信頼性・性能で提供すえることを目標に開発されており、OSSのRedisや、 Amazon ElastiCache for Redis、 Amazon MemoryDB for Redisへの接続に利用可能です。 こちらのGithubレポジトリで公開 されています。 Amazon RDS for SQL Server Supports TempDB configuration replication Amazon RDS for SQL Server で Multi-AZ構成を組んでいる際に TempDB の設定（名前、増加サイズ等）、がプライマリーからセカンダリーに同期されるようになりました。 これにより、プライマリー側で設定変更した際には、ユーザが操作しなくてもセカンダリーでも同じ設定でTempDBが利用されるようになります。 1/18(木) Simplify AWS Marketplace renewals with new future dated agreements feature AWS Marketplaceに将来の日付を指定した契約・契約更新の機能が追加されました。この機能により、AWS Marketplace の販売者は SaaS プライベートオファー作成プロセスの一環として未来の「開始日」を指定できます。購入者がオファーが受理すると、 ‘future dated’ agreement (将来の日付指定契約)が作成され、指定された開始日からユーザーがサービスを利用可能になります。詳細は こちらのドキュメント をご覧ください。 Amazon FSx for Windows File Server increases maximum IOPS level to 400,000 Amazon FSx for Windows File Server で、4Gb/s～12Gb/s のスループット容量レベルの際、従来より14%高い、最大400,000IOPSが提供可能になりました。また、この新機能による追加のコストは発生しません。 Amazon SNS now supports FCM HTTP V1 API for delivering mobile push notifications Amazon SNS のモバイルプッシュ機能において Google Firebase のHTTP V1 APIを使ったプッシュ通知がサポートされました。トークンベースの認証を行う既存もしくは新規のアプリケーションで利用可能です。 Google は 2024年6月1日から、従来の FCM v1 API を使用したモバイルプッシュ通知を送信する機能を廃止する予定のため、6月1日までに移行することをおすすめします。What’s newに各種ドキュメントへのリンクがありますので、それらを参照してください。 AWS CodeBuild announces support for reserved capacity AWS CodeBuild は、コンパイル・テスト・ビルドを自動実行する環境を提供するフルマネージド型のサービスです。今回リザーブドキャパシティ機能が追加されました。これにより、コンパイルやテストに必要なリソースを事前にプロビジョニングしておけるため、繰り返しビルドを行う際の時間を短縮可能です。リザーブドキャパシティについては こちらのドキュメント をご覧ください。 1/19(金) Amazon RDS for Db2 now supports Cross-Region Automated Backups Amazon RDS for Db2 でクロスリージョン自動バックアップがサポートされました。Snapshotのデータを自動的に他リージョンにコピーすることで、遠隔地リカバリー等のニーズに対応するものです。東京・大阪リージョンともに、ソース・ターゲット双方のリージョンとして設定可能です。 AWS announces higher read IOPS for Amazon Elastic File System Amazon Elastic File System (Amazon EFS) のIO性能向上がアナウンスされました。これまでは頻繁にアクセスされるデータおよびメタデータは、最大リード250,000IPOS、それ以外のデータは最大リード65,000IOPSでしたが、この65,000IOPSが90,000IOPSに40%性能向上しました。 Stream data into Snowflake using Kinesis Data Firehose and Snowflake Snowpipe Streaming (Preview) Amazon Kinesis Data Firehose で、 Snowflake データウェアハウスへのデータインジェクションのPreviewがアナウンスがされました。Snowpipeによるマイクロバッチ、およびSnowpipe Streamingによるストリーミング挿入の双方をサポートします。PreviewはN. Virginia、Oregon、Irelandリージョンで利用可能です。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

企業はクラウド移行の加速を常に追求しています。Infrastrcture as Code (IaC) は、クラウドリソースを効率的に自動化および管理するうえで不可欠です。 AWS Cloud Development Kit(AWS CDK) を使用すると、お気に入りのプログラミング言語でクラウドインフラストラクチャをコードとして定義し、 AWS CloudFormation を使用してデプロイできます。この記事では、組織内での CDK の採用を加速するための戦略とベストプラクティスについて説明します。この記事での議論は、組織がパイロットプロジェクトを成功裏に完了した後に始まります。この記事を読むことで、パイロットプロジェクトから得た教訓をプラットフォームエンジニアリングを通じて組織全体に広げる方法を学ぶことができます。再利用可能なコンポーネントの構築を通じて複雑さを軽減し、開発者ツールを介した高速かつ安全なデプロイ、内部開発者ポータル(IDP) によるプロジェクトのスタートアップの加速などの方法を学びます。CDK コミュニティへの参加とそこからのメリットについても述べます。 はじめに、テクノロジーの新しいトレンドであるプラットフォームエンジニアリングについて簡単に説明します。 DevOps のプラクティスは、IT 部門がより頻繁に、より高品質のソフトウェアを顧客に提供するのに役立っています。 DevOps の最近の進化は、ワークロードチーム (業務部門) をサポートするサービス、ツールチェーン、ドキュメントを構築するためのプラットフォームエンジニアリングチームの導入です。 プラットフォームエンジニアリングチームの重要な責任の 1 つは、ソフトウェアデリバリープロセスの管理です。 Amazon では、プラットフォームエンジニアリングを活用してデプロイメントを加速させてきた長い歴史があります。 これにより、年間 1 億 5 千万回のデプロイ を行いながら、 143 ものコンプライアンス 認定を取得できています。 プラットフォームエンジニアリングは、生産性を向上させ、アイデアと実装の間の摩擦を軽減し、セルフサービスポータルや開発者ツールを通じて安全でスケーラブルで再利用可能なリソースとコンポーネントのセットを介してワークロードの提供を加速することで、アジリティを向上させます。 プラットフォームエンジニアリングは、プラットフォームアーキテクチャ、データアーキテクチャ、プラットフォーム製品エンジニアリング、データエンジニアリング、プロビジョニングとオーケストレーション、モダンアプリ開発、CI/CDの 7 つの機能で構成されています。 プラットフォームエンジニアリングの詳細については、 AWS Cloud Adoption Framework をご覧ください。 これらの機能を確立するには、複数のプラットフォームチームとワークロードチームが協力する必要があります。 オペレーティングモデルの観点から、ワークロードチームはプラットフォームエンジニアリングと次の 3 つの方法のいずれかで対話しています (詳細については、 Building your Cloud Operating Model を参照してください)。 再利用可能なコンポーネントによる開発者の複雑さと認知負荷の軽減 では、プラットフォームチームはどのように CDK を利用して目標を達成できるのでしょうか。 プラットフォームエンジニアリングチームの一般的な目的の 1 つは、 コンストラクト と呼ばれる再利用可能なパターンを公開および提供することです。 コンストラクトは、複数のチームとプロジェクトで共有できる再利用可能な拡張可能な一般的なコンポーネントを作成するメカニズムを提供します。 多くのお客様は、暗号化や特定の AWS Identity and Access Management ポリシーなどのセキュリティのベストプラクティスを適用するために、独自のコンストラクト実装を記述しています。 例えば、デフォルトの Amazon S3 バケットコンストラクトの代わりに、組織のセキュリティ要件を実装した MyCompanyBucket を作成するかもしれません。このバケット構成は、セキュリティおよびコンプライアンスチームによって検証されたコンポーネントを使用していることを確認するために、複数のチームによって実装および拡張できます。 データガバナンスに焦点を当てるお客様の場合、CDK コンストラクトを使用することで、バックアップとアーキテクチャが組織のレジリエンスポリシーを満たすことを保証し、目標復旧時間 (RTO) と目標復旧時点 (RPO) のベストプラクティスを自動的に取り入れられるようになります。 データライフサイクルポリシーを適用したいユーザーの場合、統一されたアクセス制御を作成したり、必要な KPI を出力したりすることができます。CDK コンストラクトでは、デフォルトで安全でセキュアな構成を作成するための手段を提供できます。 CDK コンストラクトを DataOps に適用することで、データ系列のメタデータが保持され、データクレンジングが行われるテンプレート化された ETL パイプラインのメリットを享受できます。 お客様は AWS リソース以外のリソースのコンストラクトも作成しています。チームは、サードパーティの開発者ツール、可観測性システム、テストツールなどのコンストラクトを作成できます。このようにして、ワークロードチームは、1つのコードベースで AWS リソースと非 AWS リソースをコード化できます。独自のコンストラクトを書く際には、標準化を考慮しつつ、CDK パッケージのエコシステムの成長を活用する自由度と柔軟性のバランスが必要です。このバランスの例として、 AWS Solutions Constructs があります。これらは通常、標準のコンストラクトに基づいて作成されます。標準のコンストラクトを拡張せずに作成したコンストラクトは、ユーザーがより大きな CDK エコシステムと統合するのが難しくなります。 Construct Hub は、CDK 向けに定義されたクラウドアプリケーションの設計パターンとリファレンスアーキテクチャを発見および共有するための主要な場です。これらは AWS コミュニティによって構築および公開されています。AWS はパブリックな Construct Hub を提供していますが、企業は独自の AWS アカウント内にプライベートな Construct Hub を維持管理できます ( construct-hub 、 GitHub リポジトリ、または CDK ワークショップ で詳細を確認できます)。いずれの場合でも、主な目的は一貫しています。その目的とは、異なるワークロードチームが容易に利用できる共有ライブラリを提供することです。このアプローチにより、一貫性、再利用性が向上し、最終的にコスト削減と開発期間の短縮につながります。 このアプローチを活用する際にしばしばつまずく落とし穴の 1 つは、プラットフォームエンジニアリングチームが最新のテクノロジーを活用するための再利用可能なコンポーネントの構築が追いつかないことです。ここでパイロットプロジェクトからの教訓を活かすことが役立ちます。パイロットプロジェクトチームは、プラットフォームエンジニアリングチームと協力して、セキュリティのベストプラクティスを研究および実装します。一部のお客様は、プラットフォームエンジニアリングチームを新しいコンストラクトの作成者だけでなく、承認者としても機能させています。このモデルでは、パイロットプロジェクトチームは新しいテクノロジーのコンストラクトの構築にも取り組みます。プラットフォームエンジニアが新しいコンストラクトをレビューして承認します。プラットフォームエンジニアは、パイロットプロジェクトチームが保存時の暗号化、転送時の暗号化、最小特権などの必要な基準を満たしていることを確認します。承認されると、パイロットプロジェクトチームは新しいコンストラクトを Construct Hub に公開できます。このようにして、プラットフォームエンジニアリングは実験と革新を促進します。さらに、プラットフォームエンジニアリングチームは、コンストラクトの唯一の作成者ではなく、コンストラクトの作成についてインナーソース (訳註: 企業内でのソフトウェア開発にオープンソースソフトウェア開発の手法を取り入れること。) を推進できます。 DevSecOps のベストプラクティスを使用したアプリケーションのデプロイ アプリケーション開発者は、ビジネスの課題に直接対処するコードの作成に専門知識が集中すると、最も生産的になります。 組織の基準に沿ってアプリケーションをデプロイおよび運用する複雑なタスクは、特に新しいメンバーにとっては圧倒されるようなタスクになるかもしれません。 この複雑さはしばしばボトルネックとなり、実験的な開発プロセスを遅らせ、新しいアプリケーションの取り組みによる価値の提供を遅らせることがあります。 この課題への解決策は、デプロイパイプラインと運用モデルの自動化にあります。 徹底的にテストされた CDK コンポーネントをチーム間で共有し、堅牢な CI/CD (継続的インテグレーション/継続的デプロイ) プロセスを通じて検証することで、開発者への負担が大幅に軽減されます。 開発者はもはや組織のデプロイ戦略の複雑さに立ち入る必要がなくなり、独創的で革新的なコードの作成に集中できるようになります。 このアプローチは、開発プロセスを効率化するだけでなく、開発と運用の間のギャップを埋め、より緊密なチームとより迅速で効率的なリリースを実現します。 高品質なソフトウェアデリバリーの鍵の 1 つは、適切な継続的インテグレーションと継続的デリバリー (CI/CD)プロセスを整備することです。 実践的な例については、 CDK Pipelines: AWS CDK Continuous delivery for AWS CDK applications を参照できます。 この高レベルなコンストラクトは AWS CodePipeline によって動作し、 cdk deploy コマンドによるテストデプロイを超えて、異なるリージョンやアカウントの複数の環境への本番デプロイのための自動パイプラインを構築するのに役立ちます。 AWS CDK アプリケーションのソースコードを AWS CodeCommit 、GitHub、GitLab、BitBucket、または Amazon CodeCatalyst のソースリポジトリにコミットするたびに、AWS CDK Pipelines が自動的にアプリケーションの新しいバージョンをビルド、テスト、デプロイします。 このパイプラインは、スタック内のリソースが変更されたり、デプロイされる環境が変更されたりすると、パイプラインが自動的に再設定されます。 GitHub Actions ユーザーの場合は、 CDK Pipelines for GitHub Workflows をご覧ください。 複数のチームがこれらのパイプラインを拡張し、独自のステージを追加することで、デプロイされたコードが組織の品質、セキュリティ、リスク、コンプライアンス、クラウド財務管理の基準を満たすことを保証します。 パイプライン内にどのような自動化を組み込むかのベストプラクティスについては、 AWS Deployment Pipeline Reference Architecture を参照してください。 完全に機能するパイプラインを作成することで、プラットフォームエンジニアリングチームは、開発チームへの認知的負荷を軽減し、開発者体験を向上させることができます。 この戦略には 2 つの実装があります: クイックスタートパイプラインとゴールデンパイプラインです。 クイックスタートパイプラインでは、パイプラインは Construct Hub のコンストラクトとして作成され、再利用可能なコンポーネントに関する上記の議論と同様に扱われます。 パイプラインはシンプルなインターフェースと認知負荷の軽減を提供しますが、ワークロードチームはパイプラインを自身で制御し、自由に変更することができます。 その結果、セキュリティやコンプライアンス検証ツールのような品質管理の仕組みは、ワークロード チームによって無効にされ、パイプライン内のコントロールは保証できなくなります。 これは、コンプライアンスと監査のコストを削減したい組織にとっては望ましくありません。 コンストラクトのバージョン数が増えるにつれて、プラットフォームエンジニアリングチームは、ワークロードチームがどのバージョンを使用しているかを管理することが困難になる可能性があります。 ゴールデンパイプラインでは、パイプラインはコンストラクトとして作成されますが、中央集権化されたチームによって管理されます。 ワークロードチームはこれらのパイプラインを制御したり変更したりすることができません。したがって、セキュリティやコンプライアンスのツールのような品質管理の仕組みは無効化できません。 これらのコントロールは、監査人などのセキュリティ、リスク、コンプライアンスのステークホルダーに対して検証可能なものになります。 一方で、ワークロードチームからのアクセス許可を削除することにはコストが伴います。 ゴールデンパイプラインでは、プラットフォームエンジニアリングチームはしばしば、ワークロードチームのデプロイのトラブルシューティングに時間の大半を費やすことになります。 プラットフォームエンジニアリングチームはトラブルシューティングに時間を費やすことが増え、セキュリティと品質の基準を上げる新しいツールの導入、環境設定と組織の一貫性の改善、監査証跡と実施体制の強化などに時間を割くことがほとんどできなくなります。 2 つのメカニズムがこれらの戦略を補完します。 昔ながらの変更管理委員会 (CCB) は、証拠の収集と実施が困難な状況で検証可能性を提供します。 CCB は、パイプラインとアカウント作成プロセスに IT サービスマネジメント (ITSM) の承認とフリート管理プロセスを統合する CDK コンストラクトの恩恵を受けることができます。 一方で、ソフトウェアアーティファクトのためのサプライチェーンレベル (Supply chain Levels for Software Artifacts, SLSA) に関する新しい話題もあります。 これらのアーティファクトはデジタル証明として使用できます。 Kubernetes では、 Tekton chains のようなツールでこのパターンが見られます。OCI イメージに関連付けられた証明書や、証明書の存在を保証するために Kyverno が使用されています (詳細は Protect the pipe! Secure CI/CD pipelines with a policy-based approach using Tekton and Kyverno を参照)。 CDK によるマルチアカウントとクロスリージョンデプロイ DevOps のベストプラクティスは、本番へのデプロイ前に複数のステージでデプロイとテストを行うことを推奨しています。 さらに、AWS はステージごとに専用のアカウントの利用を推奨しています。これにより、リソースの分離とアクセス制御が容易になります。 このマルチアカウント戦略により、組織は AWS リソースを最大限に活用でき、詳細な制御が可能になります( Recommended OUs and accounts を参照)。 多くの場合、ワークロードごとに指定された AWS アカウントがあり、すべての CI/CD パイプラインがそこに存在します。 開発、ステージング、本番などの段階に対応する他の AWS アカウントにデプロイするために、これらのパイプラインによって実行されます。 AWS 上の CI/CD パイプラインを参照したクロスアカウント戦略の詳細については、 Building a Secure Cross-Account Continuous Delivery Pipeline をご覧ください。 自動化されたガバナンス 多くの企業は、CDK を利用してセキュリティ制御とポリシーを適用したり、デプロイパイプラインの一部としてコード解析ツールを使ってデプロイ前にセキュリティ上の問題を未然に防いだりしています。業界標準のツールである cdk-nag を利用することで、多くのチームが利用可能なルールセットを使ってアプリケーションのベストプラクティスをチェックしています。また、企業ではデプロイしたリソースを管理・整理するためのタグ付けの要件など、追加の要件を適用する独自の Aspect を作成している例も見受けられます。 お客様は、 CDK によって合成された CloudFormation テンプレート を作成し、 CloudFormation Guard を使用して、Policy as Code のドメイン固有言語 (DSL) ルールを使って出力を検証するための追加のチェックポイントを作成できます。プラットフォームエンジニアリングチームは、ルールを作成できます。ワークロードチームは、それらのルールを利用し、パイプライン内で CloudFormation Guard を実行できます。アプリケーションに CloudFormation Guard チェックを簡単に追加できる 公式コンストラクト があります。 AWS CDK では、インフラストラクチャはコードそのものです。 したがって、品質を確保し、開発者体験を向上させるために、すでに使用している標準的なツールを CDK でも使用する必要があります。 組織にコード品質プログラムがある場合は、CDK アプリケーションを Web アプリケーションやマイクロサービスと同様に扱う必要があります。 同様に、 Amazon CodeGuru Security と Amazon CodeWhisperer を使用することで、開発者は他アプリケーションと同様に、CDK コードのセキュリティと品質の改善に役立つ実行可能な推奨事項を得ることができます。 Aspects 、cdk-nag、コード品質ツールを使用することで、組織はデプロイ前にセキュリティの問題を防ぐことができますが、デプロイ後に機能するコントロールを作成することも重要です。 AWS CloudFormation Hooks を使用することで、お客様は CloudFormation スタックや CDK アプリケーションの作成、更新、削除の前にリソースを検査することができます。 CloudFormation Hooks を使用することで、プラットフォームエンジニアリングチームは、基準に沿っていないリソースのプロビジョニングに対して警告を出したり、防止することができます。 これらのフックは CDK で作成できます (詳細はこちらの Build and Deploy CloudFormation Hooks using A CI/CD Pipeline を参照)。 最後に、CDK を介して AWS Config のコンプライアンスチェックのルールセットをデプロイできます。 これらのルールのコレクションにより、組織は大規模にセキュリティ基準を要求できます。 組織がカスタムルールを作成したい場合、チームは AWS Config ルール のための高レベルのコンストラクトを使用してリアクティブコントロールを作成できます。 これらのパターンの多くは CDK よりも前から存在していましたが、CDK は企業内またはコミュニティ全体で共有されている再利用可能なコンポーネントを活用することにより、クラウドアプリケーションとコントロールの構築とデプロイを加速します。 アプリケーションの運用と可観測性 オープンソースコミュニティは、CDK アプリケーションの基本的なモニタリング機能を拡張する高レベルのコンストラクトライブラリを提供しています。 cdk-monitoring-constructs プロジェクトを使用すると、CDK アプリのモニタリングが簡単になります。同様に、 CDKWakeful はそれを一歩進め、多くのサービスを追加し、 Incident ManagerAWS Systems Manager Incident Manager 、 AWS Chatbot 、 Amazon Simple Notification Service による通知を自動的に受信するための、簡単に構成できるインターフェイスを提供します。オープンソースコミュニティからの既製ソリューションを活用することで、ビジネスロジックを中心としたカスタムメトリクスとしきい値に集中することができます。プラットフォームエンジニアリングチームは、オープンソースプロジェクトを変更および拡張して、ワークロードチームが運用を簡素化し、ヘルスステータスを集中システムに送信できるように支援できます。 内部開発者プラットフォームによる新規プロジェクトのスタートアップの加速 内部開発者プラットフォーム (Internal Developer Platform, IDP) は、プラットフォームエンジニアリングチームによって構築され、ゴールデンパスを構築し、開発者のセルフサービスを可能にします。これらのゴールデンパスは、ソースコントロールリポジトリとリポジトリ内に格納されたファイルを作成する一連のテンプレートとして表現されます。IDP がこれらのテンプレートを使用してソースコードリポジトリを作成すると、作成されたリポジトリには次のものが含まれる必要があります: チュートリアル (通常は README.md に記載) リファレンスドキュメント スケルトンソースコード 依存関係管理 CI/CD パイプラインテンプレート IaC テンプレート 可観測性の設定 CDK を使用すると、CI/CD パイプライン、IaC テンプレート、可観測性設定はすべて、単一の CDK アプリケーションの一部として構築できます。 プラットフォームエンジニアリングチームは、 Backstage 、 Humanitec 、 Port などのツールを使用して、ゴールデンパスを構築し公開します。 ゴールデンパスの構築には、基盤となるプロジェクト構造について 2 つの一般的なアプローチがあります。 一部の組織では、IaC コードリポジトリをアプリケーションコードから分離するアプローチを選択します。 他の組織では、すべてを 1 つのリポジトリに含めることを選択します。 ゴールデンパスと再利用可能なコンポーネントのどちらにどの程度配置するかについて、それぞれにトレードオフがあります。 両方のアプローチで、プラットフォームエンジニアリングチームは、CDKを活用することでコードの重複を回避できます。 組織が選択するアプローチによって、再利用可能なコンポーネントの整理方法が決まります。 以下では、両方のアプローチと再利用可能なコンストラクトへの影響について説明します。 アプローチ 1: 全てを一つのリポジトリに含める このアプローチでは、インフラストラクチャ、アプリケーション、設定、デプロイメントのすべてのコードが 1 つのリポジトリに含まれます。このアプローチにより、開発者はコラボレーションし、機能を構築し、迅速にイノベーションを起こすことができるため、推奨されるアプローチです。 詳細については、 ベストプラクティスのドキュメント を参照してください。 例については、 AWS Deployment Reference Architecture for Applications をご覧ください。 このアプローチは、バリューストリームに沿った (Stream-aligned な) チームで最も効果的です。 バリューストリームに沿ったチームは、同じチーム内に開発と運用の能力を備えています。 これらのチームは、技術的な機能ではなく、顧客の課題を解決することを目的として組織化されています。 プロジェクト内では、チームはアプリケーション階層 (API、データベースなど) やビジネス機能 (注文管理、製品カタログ、配送サービスなど) などの論理単位で組織化できます。 バリューストリームに沿った組織では、大規模で高度に標準化された再利用可能なコンポーネントがより適しています。 このタイプのコンストラクトの極端な例は、マイクロサービス全体のコードを含む単一のコンストラクトです。これらのチームでは、認知負荷は顧客の課題に集中しているため、アプリケーションの開発の複雑さを減らすことが成功の鍵となります。 アプローチ 2: アプリケーションコードのパイプラインを分離する この代替アプローチでは、アプリケーションコードとインフラストラクチャを別リポジトリに格納し、パイプラインを分離します。 パイプラインを分離すると、機能開発に焦点を当てるワークロード担当者と、それらのアプリケーションが実行されるインフラストラクチャの構築に注力するインフラエンジニアの間で、サイロ化やコラボレーションの減少につながることがしばしばあります。 このアプローチは、「マトリックス型」のチームで最もうまく機能します。 マトリックス型組織は、技術的な能力 (開発、運用、セキュリティ、ビジネスなど) を中心に構築されています。 こうした場合、高度に標準化されたコンストラクトよりも、よりモジュール型のコンストラクトの方がうまく機能します。 各組織のエキスパートは、CDK コンストラクトをメカニズムとして使用して、組織全体に自らの専門知識を共有できます。 この種のコンストラクトの例としては、集中型の監視にプラグインするためのフックを備えた、監視、アラート、セキュリティのためのコンストラクトなどがあります。 プラットフォームエンジニアリングによるコミュニティ・オブ・プラクティスの構築 大規模な組織内で新しいテクノロジーをスケールするには、コラボレーションを促進し、ベストプラクティスを確立し、エコシステムの変化に対応したコミュニティの構築と拡大が必要です。組織内にこれらのコミュニティ・オブ・プラクティスを作成できるようにするために、AWS は CDK ユーザーを教育するコンテンツの作成を中心とした複数のパブリックコミュニティをサポートしています。組織のコミュニティ・オブ・プラクティスのメンバーは、これらのパブリックな AWS サポートコミュニティを通じて、世界中の他の CDK 開発チームとつながることができます。 コミュニティ・オブ・プラクティス コミュニティ・オブ・プラクティス (CoP) は、非公式な交流や知識共有を通じて、特定のドメインで学習、協働、専門性を高めるために集まる、共通の関心事を持つ人々のグループです。 組織内で CDK を中心としたコミュニティ・オブ・プラクティスを確立することは、メンタリング、問題解決、再利用可能なアセットの実現につながることが証明されています。 はじめに、CDK を使用した再利用可能なコンストラクトと開発者ツールの作成者であるプラットフォームエンジニアリングチームが、コミュニティ・オブ・プラクティスの初期のコンテンツ作成者となります。 これにより、CDK の作成者が CoP を通じて自分の成果を公開するというフィードバックループが確立されます。 ユーザーは作成者に対して質問したり、直接的な指導をすることができます。 CoP がそれを確立した初期グループによって持続可能な形で拡大したら、CoP 内でハッカソンや Game Day を開始することができます。これによりイノベーションがもたらされ、組織全体の課題が解決されます。 完全に成熟したコミュニティ・オブ・プラクティスは、Wiki や知識のデータベースを所有しています。 タウンホール、オフィスアワー、ニュースレター、チャットチャネルなどのメカニズムを使用して、コミュニティを最新の状態に保ちます。 このようにして、CDK の専門知識が組織全体に広まっていきます。 AWS では、この専門知識の拡散により、プラットフォームエンジニアリング以外のチームも再利用可能なコンストラクトの作成者となっています。 再利用可能なコンストラクトを作成できる人を広げることで、自社のイノベーションを加速できます。 コミュニティ CDKをサポートするコミュニティは成長しつつあり、コンテンツ、コード、サンプル、ミートアップなど、さまざまなプラットフォームが利用できます。 CDK は現在 AWS によってメンテナンスされており、 AWS CDK GitHub ページ ではコミュニティのサポートのもと、プラットフォームへの貢献、イシューの提起、バックログの確認、アクティブなコミュニティメンバーとのディスカッションへの参加ができます。 CDK.dev は、CDK エコシステムを取り巻くコミュニティ主導のハブです。このサイトでは、最新のブログ、ビデオ、教育コンテンツをまとめています。また、 Slack プラットフォームへの参加リンクも提供しています。 CDK Patterns は、開発者が使用できる CDK で構築された AWS サーバーレスアーキテクチャパターンの オープンソースコレクション を提供しています。 これらのパターンは、 AWS コミュニティビルダー / AWS ヒーロー を通じて提供されています。 最後に、 AWS re:Post は、コミュニティが解決するための質問応答ポータルを提供します。 AWS コミュニティビルダー プログラムは、知識を共有しテクニカルコミュニティとつながることに情熱を持つ人々に対して、テクニカルリソース、教育、ネットワーキングの機会を提供しています。 コミュニティ・オブ・プラクティスは、cdk.dev のような AWS パブリックコミュニティを活用して、知識のギャップを埋めることができます。 タウンホールミーティングは、AWS Heroes やコミュニティビルダー、GitHub や re:Post への頻繁なコントリビューター、 CDK Day のスピーカーなどから恩恵を受けることができます。 ニュースレターは、すべてのAWS チャネルからの最新ニュースを集約および要約できます。 コミュニティ・オブ・プラクティスが CDK の専門知識を確立すると、このコラボレーションは双方向にもなります。 たとえば、組織のコミュニティのエキスパートは、 AWS Heroes になることができます。 成功事例は、 CDK Day 、ゲストブログ投稿を通じて共有でき、 AWS Summit 、 AWS re:Invent 、 AWS re:Inforce 、 AWS re:Mars などの主要イベントのいずれかで講演する可能性さえあります。 おわりに このブログ全体を通して述べてきたように、CDK ではインフラストラクチャはコードそのものです。 これによりインフラストラクチャ管理のパラダイムシフトが可能になりました。 今日、 Liberty Mutual 、 Scenario 、 Checkmarx 、 Registers of Scotland など、多くのお客様が CDK を使って成熟したエコシステムを構築しています。アクティブなオープンソースコミュニティ、長期サポートのための AWS 開発チーム、知識共有のための複数のプラットフォームがあるため、開発者は迅速に学習、構築、革新することができます。 成功したパイロットプロジェクトにより、CDK を採用した多くの組織が、よりアジャイルに、より速く革新できるようになりました。 これは Amazon でもまさに起こったことで、CDK は新しいサービス構築の第一選択肢です。 組織はしばしば、プラットフォームエンジニアリングを通じてスケールと複雑さの削減を実現します。 これらのチームは、ベストプラクティスを適用することで高レベルなコンストラクトを構築し、CI/CD パイプラインを提供してデプロイメントを加速します。 インフラストラクチャのコードに対するユニットテストや、各段階 (作成から運用まで) の構築者へのガイダンスを提供する堅牢なセキュリティ管理を用いることで、デプロイメントの安全性が高まります。 最後に、コミュニティを構築することで、組織は成熟したエコシステムを構築できるようになります。 内部コミュニティとオープンソースコミュニティの両方を通じて、開発者はつながり、新たな発見や成長が実現されます。 この記事は David Hassler, Amritha Shetty, Chris Scudder, Kumar Karra による Best practices for scaling AWS CDK adoption within your organization を翻訳したものです。 翻訳は Solutions Architect の山崎宏紀が担当しました。

現代のクラウドコンピューティングにおいて、Infrastrcture as Code (IaC) は、クラウドリソースのデプロイと管理に不可欠な要素となっています。 AWS Cloud Development Kit (AWS CDK) は、開発者が馴染みのあるプログラミング言語を使用してクラウドリソースを定義できるようにする、人気のオープンソースフレームワークです。関連するオープンソースツールである Projen は、複雑なソフトウェア設定の管理を簡素化する強力なプロジェクト生成ツールです。この記事では、Projen と AWS CDK を使用するための基本的な使い方について学び、Projen を使用することのメリットや課題について議論します。 Projen とは 高品質でモダンなソフトウェアを構築するには、lint、テスト、リリースの自動化などのタスクを処理するために、たくさんのツールと設定ファイルが必要です。各ツールには、JSON や YAML のような固有の設定インターフェースと構文があり、メンテナンスの複雑さが増します。 新しいプロジェクトを始めるとき、ゼロから始めることはめったになく、しばしばプロジェクト生成ツール (例えば、 create-react-app ) を使用して新しいプロジェクトを生成します。大量の設定が自動的に作成され、それらのファイルの所有権が付与されます。さらに、プロジェクト生成ツールは多数存在し、毎日のように新しいツールが公開されています。 Projen は、開発者がプロジェクトの設定ファイルを効率的に管理し、高品質なソフトウェアを構築できるよう支援するプロジェクト生成ツールです。コード内でプロジェクト構造と設定を定義できるため、さまざまな環境とプロジェクト間でのメンテナンスと共有が容易になります。 Projen は、AWS CDK コンストラクトライブラリ、React アプリケーション、Java プロジェクト、Python プロジェクトなど、 複数のプロジェクトタイプ をサポートしています。新しいプロジェクトタイプはコントリビューターによって追加され、プロジェクトは複数のプログラミング言語での開発が可能です。 Projen は、 jsii ライブラリを使用しています。これにより、API を一度記述すると、複数のプログラミング言語でライブラリを生成できます。さらに、Projen は projenrc ファイルを通じて、プロジェクト全体の設定を管理する単一のインターフェイスを提供します！ 次の図は、Projen を使用した AWS クラウドリソースのデプロイプロセスの概要を示しています: この例では、Projen を使用して、たとえば新しい CDK TypeScript アプリケーションなどの新しいプロジェクトを生成できます。 開発者は、AWS CDK リソースを使用してインフラストラクチャとアプリケーションコードを定義します。プロジェクト構成を変更するために、開発者は package.json などのファイルを直接編集する代わりに、 projenrc ファイルを使用します。 プロジェクトは CloudFormation テンプレートを生成します。 CloudFormation テンプレートは AWS アカウントにデプロイされ、AWS クラウドリソースをプロビジョニングします。 図1 – Projen の提供する機能: Projen はプロジェクトの開始をサポートし、プロジェクトの他の要素を気にする代わりにコーディングに集中できるようにします。lint、ユニットテストとコードカバレッジ、リリースとバージョニング、依存関係管理のための複数のGitHub アクションがすぐに利用できます。 Projen のメリットと課題 メリット 一貫性 : Projen を使用することで、標準的なプロジェクトテンプレートを定義できるため、異なるプロジェクト間での一貫性を確保できます。異なるプロジェクト生成ツールを使用する必要がなく、Projen のみを使用できます。 バージョン管理 : プロジェクト設定がコードで定義されているため、変更履歴の追跡や他者とのコラボレーションが容易になります。 拡張性 : Projen は、さまざまなプラグインと拡張機能をサポートしているため、特定のニーズに合わせてプロジェクト設定をカスタマイズできます。 AWS CDK との統合 : Projen は AWS CDK とのシームレスな統合を提供し、クラウドリソースの定義とデプロイプロセスを簡略化します。 多言語対応 CDK コンストラクトライブラリ : 一度のビルドによって、複数のランタイムで実行できます。Projen は、TypeScript で開発された CDK コンストラクトを、JSII のサポートにより Java (Maven) や Python (PyPI) に変換および公開できます。 API ドキュメント : CDK コンストラクトの構築時には、コメントから API ドキュメントを生成します。 課題 Microsoft Windows のサポート。Projen が Windows 環境で完全に動作しないという未解決の issue がいくつかあります ( https://github.com/projen/projen/issues/2427 と https://github.com/projen/projen/issues/498 )。 フレームワークの Projen は、アーキテクチャ、ベストプラクティス、規約についてのいくつかの前提が存在します。 Projen はまだ GA (General Availability、正式リリース版) ではなく、この記事を書いている時点でのバージョンは v0.77.5 です。 Projen の利用手順 ステップ1: 前提条件の設定 AWS アカウント Node のダウンロードとインストール yarn のインストール AWS CLI : 資格情報の設定 AWS CDK を使用したスタックのデプロイには、専用の Amazon S3 バケットやその他のコンテナが、デプロイ中に AWS CloudFormation で利用できるようにしておく必要があります ( 詳細情報 )。 注 : Projen をグローバルにインストールする必要はありません。 npx を使用して Projen を実行するので、必要なすべてのセットアップステップが処理されます。 npx は、次の npm パッケージを実行するツールです。 ローカルの node_modules フォルダ内に存在する グローバルにインストールされていない npx は npm バージョン 5.2+ にバンドルされています ステップ2: 新しい Projen プロジェクトの作成 次のコマンドを使用して、新しい Projen プロジェクトを作成できます: mkdir test_project && cd test_project npx projen new awscdk-app-ts このコマンドは、AWS CDK サポートが含まれた新しい TypeScript プロジェクトを作成します。サポートされているプロジェクトタイプの完全なリストは、公式ドキュメント Projen.io 、またはプロジェクトタイプを指定せずに npx projen new コマンドを実行することで参照できます。また、 npx projen new awscdk-construct を使用して再利用可能なコンストラクトを作成し、それを他のパッケージマネージャに公開することもできます。 作成されたプロジェクト構造は次のようになります: test_project | .github/ | .projen/ | src/ | test/ | .eslintrc | .gitattributes | .gitignore | .mergify.yml | .npmignore | .projenrc.js | cdk.json | LICENSE | package.json | README.md | tsconfig.dev.json | yarn.lock Projen は次のものを含む新しいプロジェクトを生成しました: GitHub のワークフローファイルを使用してプロジェクトをビルドおよびアップグレードできる空の git リポジトリ。リリースワークフローは projen のタスクでカスタマイズできます。 .projenrc.js はプロジェクトの主な設定ファイルです Visual Studio Code との統合のための tasks.json ファイル 空の CDK スタックを含む src フォルダ License と README ファイル package.json には、名前、バージョン、依存関係など、プロジェクトに関する機能的なメタデータが含まれています git でファイルを管理するための .gitignore 、 .gitattributes ファイル JavaScript でのパターンを特定する .eslintrc パッケージマネージャからファイルを除外するための .npmignore プルリクエストを管理するための .mergify.yml コンパイラオプションを設定する tsconfig.json 生成されたファイルのほとんどには、次のような免責事項が含まれています: # ~~ Generated by projen. To modify, edit .projenrc.js and run "npx projen". Projen の力は、その単一の設定ファイル .projenrc.js にあります。 このファイルを編集することで、プロジェクトの lint ルール、依存関係、 .gitignore などを管理できます。 Projen は変更をすべての生成されたファイルに反映させることで、プロジェクト全体の依存関係管理を簡素化および統一します。 Projen によって生成されたファイルは手動で編集することを意図していません。 手動で変更を加えた場合、次に npx projen コマンドを実行したときに上書きされます。 プロジェクト設定を編集するには、単純に .projenrc.js を編集し、再生成のために npx projen を実行してください。 Projen API の詳細については、 こちらのドキュメント を参照してください: 。 Projen は projenrc.js ファイルの設定を使用して、基本的なメタデータ(プロジェクト名、CDK バージョン、デフォルトのリリースブランチなど)を持つ新しい AwsCdkTypeScriptApp をインスタンス化します。 このプロジェクトタイプでは、カスタマイズのために追加の API が利用できます(例: ランタイム依存関係の追加)。 プロパティを変更して、Projen の反応を確認してみましょう。 例として、 projenrc.js のプロジェクト名を更新します: name: 'test_project_2', その後、 npx projen コマンドを実行します。 完了したら、プロジェクト名が package.json ファイルで更新されたことがわかります。 ステップ 3: AWS CDK リソースの定義 Projen プロジェクト内で、TypeScript などの開発者が馴染みのあるプログラミング言語を使用して AWS CDK リソースを定義できます。 たとえば、 Amazon Simple Storage Service(Amazon S3) バケットを定義する例を次に示します: 1. src/ ディレクトリの main.ts ファイルに移動します。 2. ファイルの先頭のインポートを次のように変更します: import { App, CfnOutput, Stack, StackProps } from 'aws-cdk-lib'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; 3. 行 9 の「 // define resources here... 」を次のコードに置き換えます: const bucket = new s3.Bucket(this, 'MyBucket', { versioned: true, }); new CfnOutput(this, 'TestBucket', { value: bucket.bucketArn }); ステップ 4: 合成とデプロイ 次に、 アプリケーションのブートストラップ を実行します。ターミナルで以下を実行してください。 $ npx cdk bootstrap リソースを定義したら、CloudFormation テンプレート(アプリケーションによっては複数)を含むクラウドアセンブリを合成できます。(訳註: linter の仕様上、 main.ts の25行目でスタック名を test-project-devに変更する必要があります。) $ npx projen build npx projen build はいくつかのアクションを実行します。 アプリケーションのビルド CloudFormation テンプレートの生成 テストとリンターの実行 Projen の synth() メソッドは、Projen によって管理されているすべての設定ファイルの実際の合成(および更新)を実行します。これは、Projen で管理されているすべてのファイルを削除し(ファイルがある場合)、ユーザーが指定した最新の設定に基づいてそれらを再合成することによって実現されます。 利用可能な npx projen コマンドの完全なリストは、 .projen/tasks.json で確認できます。また、プロジェクト API project.addTask を使用して、必要なカスタムアクションを実行する新しいタスクを追加することもできます! タスクは、シェルスクリプトでバックアップされたプロジェクトコマンドシステムを定義するプロジェクトレベルの機能です。 CDK アプリケーションのデプロイ $ npx projen deploy Projen は、CDK によって生成されたテンプレートに基づいて変更セットを作成し実行することで、設定された AWS アカウントに CloudFormation スタックをデプロイするために cdk deploy コマンドを使用します。上記のステップの出力は次のようになるはずです。 deploy | cdk deploy ✨ Synthesis time: 3.28s toto-dev: start: Building 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: success: Built 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: start: Publishing 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: success: Published 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: deploying... [1/1] toto-dev: creating CloudFormation changeset... ✅ testproject-dev ✨ Deployment time: 33.48s Outputs: testproject-dev.TestBucket = arn:aws:s3:::testproject-dev-mybucketf68f3ff0-1xy2f0vk0ve4r Stack ARN: arn:aws:cloudformation:us-east-1:263905523351:stack/testproject-dev/007e7b20-48df-11ee-b38d-0aa3a92c162d ✨ Total time: 36.76s アプリケーションは、設定された AWS アカウントに正常にデプロイされました。また、作成された S3 バケットの Amazon リソースネーム (ARN) は、CloudFormation のスタックの出力タブから利用でき、ターミナルの「Outputs」セクションに表示されます。 クリーンアップ CloudFormation スタックの削除 ワークショップのこのセクションで作成したリソースをクリーンアップするには、CloudFormation コンソールに移動し、作成したスタックを削除します。プログラムで同じタスクを実行することもできます。 $ npx projen destroy 次の出力が表示されるはずです。 destroy | cdk destroy Are you sure you want to delete: testproject-dev (y/n)? y testproject-dev: destroying... [1/1] ✅ testproject-dev: destroyed S3 バケットの削除 S3 バケットは保持ポリシーが RETAIN に設定されているため削除されません。S3 コンソールに移動し、作成したバケットを削除してください。そのバケットにファイルを追加した場合は、削除する前に空にする必要があります。詳細は、 バケットの削除 を参照してください。 おわりに Projen と AWS CDK は、クラウドリソースとプロジェクト構成を管理するための強力な組み合わせを提供します。Projen を利用することで、プロジェクト間の一貫性、バージョン管理、拡張性を確保できます。AWS CDK との統合により、開発者に馴染みのあるプログラミング言語を使用してクラウドリソースを定義およびデプロイできるため、プロセス全体がより開発者フレンドリーなものになります。 クラウド開発のベテランであれ初心者であれ、Projen と AWS CDK は、クラウドリソース管理の合理化されたアプローチを提供します。Infrastructure as Code のメリットを、柔軟でパワフルなモダン開発ツールとともに体験してみてください。 この記事は、Alain Krok, Dinesh Sajwan, Michael Tran らによる Getting started with Projen and AWS CDK を翻訳したものです。 翻訳は Solutions Architect の山崎宏紀が担当しました。

こんにちは。元メーカー生産技術出身でAWSへ転身した、変わり種ソリューションアーキテクトの岩根と黒田です。 ものづくり白書2023 では、日本の製造業について「我が国の生産現場は、高度なオペレーション・熟練技能者の存在によって、現場の最適化・高い生産性に強みを持つ」と分析しており、熟練技能者がクラフトマンシップを発揮して高い現場力を維持していることが強みという認識が示されています。一方で、「海外の先進企業は、データ連携や生産技術のデジタル化・ 標準化に強みを持ち、企業の枠を越えた最適化を実現」という表現で日本と海外先進企業の違いを分析しています。日本の製造業が今後さらに競争力を高めていくためには、高い現場力による部分最適と、データ連携によるデータドリブンなオペレーションと全体最適とを両立させることが鍵となりそうです。本ブログでは、部分最適と全体最適という一見すると相反したものを目指すデータドリブンとクラフトマンシップが交わるのか？について考察していきます。 なぜデータドリブンが必要なのか？ なぜ、今データドリブンな意思決定が必要なのでしょうか。工場オペレーションの効率化や加工精度の追求には引き続きクラフトマンシップが欠かせないでしょう。一方、若年者の減少、非正規雇用の増加、雇用流動性の高まりを考えると、これまでと同じやり方での技能伝承も課題になってくるでしょう。さらには、サプライチェーンはグローバル規模に拡大し、炭素排出量のような新たに把握が求められる情報についても増加の一途をたどっています。広範囲かつ多岐にわたる情報のトレーサビリティを求められ、個人の勘・コツで管理できる範疇を超えてきていると感じる方も多いのではないでしょうか。このような理由により、意思決定は複雑化し「現場の高度なオペレーション・熟練技能者の存在 による現場の部分最適・高い生産性」だけで競争力を保つのは困難になりつつあります。加えて、スマートプロダクトやSoftware-Defined-Vehicle（SDV）のような、「売ってから進化するプロダクト」の登場により、競争力を保つために求められる改善スピードが格段に速くなっていることも拍車をかけていると言えそうです。こうした課題に立ち向かうための武器が “データ” であると考えます。客観的なデータをもとに意思決定することで、より迅速に、説明性・再現性をもたせることが可能になります。 データドリブンを実装するためのアプローチ ここで二つの寓話をご紹介します。「製造業と関係ない！」と感じられるかもしれませんが、まずはお読みください。 寓話1： 老舗鰻店の決断 創業100年を超える老舗鰻店のA鰻店では、コロナ禍で悪化した経営状況から、地方で飲食チェーンを展開するB社の傘下に入り営業を続けていた。A店では創業以来継ぎ足し続けた秘伝のタレが味の秘訣であり、4代続く板前に代々引き継がれてきた。ある日B社の幹部がA店を訪れ、「A鰻店の2号店を出したい。ゆくゆくはチェーン展開も考えている。自慢のタレの成分分析をして、工場で生産できるようにしたい。協力してくれないか」と持ちかけた。 寓話2: ファイターの意思決定 とある人気アニメで主人公のライバルとなる戦闘民族は、相対する相手と戦う際に、相手の強さが数値でわかるスマートグラス機器を装着している。そこで相手の強さが定量的にわかる上に、自身の強さも把握しておくことで、有利に戦闘を進めることができるようになっている。 何が言いたいのか？ 2つの寓話で私は何を言いたかったのでしょうか。鰻店の話では、オーナー企業の投げかけに対してA店側がどんな反応だったか描いていませんが、ネガティブな反応が出ることは想像に難くありません。職人が辞めるかもしれません。ではB社のアプローチは間違っているのでしょうか？データをもとに味を再現可能にする、目指すこととしてなんら間違ってはいませんね。では何が間違っていたのか。私は急激に変えようとし過ぎているところに問題があると思います。熟練技能者の意向を無視して、彼らの「技」をデータソースとしてしか捉えておらず、リスペクトがありません。いずれは熟練技能者が不在でも成立する世界観を確立するにしても、現状は匠が存在している以上、彼らの意思決定を支援する方向にこそデータドリブンアプローチは向いていると言えないでしょうか。それを表現したのが寓話2です。ここに出てくる戦闘民族は、自身の強さと言う絶対的な技能を持ちつつ、データをも手中にすることで、さらにその強さに磨きをかけることに成功していそうです。要は、 初めはデータを活用する主体を熟練技能者にする 受益者＝提供者から始める そこで得られた知見を再活用できるパイプラインを整える 情報を集約する ことが重要になってくるのではないでしょうか。 図1: 情報の集約順序と受益する順序 具体例 ： 設備保全技術者の悩み 寓話が続いたので、工場の生産設備の保全技術者を主役に据えて具体例でお話します。保全業務のミッションは、設備の稼働率と製品の品質を維持・向上することです。生産設備は通常、構造物やアクチュエータなどのメカ部品と、それを制御するためのプログラマブルロジックコントローラー（PLC）、PLC上で設備の動作を制御するラダープログラムなどで構成されます。優れた保全技術者は、自身が担当する設備のメカ・制御に精通し、必要に応じてその両方を改修する必要があります。いわゆる多能工ですね。前職で彼らの動きを実際に追いかけた経験があるのですが、何か設備に異常があって止まったときの集中力やスピード感、仮説検証の速さなどは目を見張るものがあります。まさに熟練技能者と言えるでしょう。その熟練技能者である保全技術者が、最も手を焼くトラブルはなんでしょうか？いくつかありますが、ここでは2つほど挙げてみましょう。1つ目は「ダンマリ停止」という現象です。一見すると、明らかなメカの破損があったり、PLCがエラーを発報しているわけではなく、ただ「止まっている」状態です。しかも、リセットして再起動すると正常に動いたりもする。それが散発的に起きるので、原因を追いにくいと言うわけです。2つ目は、長納期部品の破損トラブルです。設備を稼働させるために重要かつ長納期のメカ部品が壊れると、復旧に時間がかかり生産の影響が大きくなります。これらを工場長目線で見る場合には、どのラインがどれだけ稼働しているか、という情報が必要ですが、保全技術者は1つ1つの設備に対してアクションが必要なため、いつ・何が・どんな理由で止まったか、といったより具体的な情報が必要です。 図2: 設備の保全技術者は熟練技能者 解決策は？ それでは保全技術者の悩みをどのように解決すれば良いのでしょうか？ まずはダンマリ停止のような事象を正しく捉えることが先決です。特に複合設備で構成されるラインにおいては、停止の原因も様々です。例えば前工程からのワーク（製造品）が届かない「ワーク待ち」の状態や、後工程のサイクルタイムが何らかの原因で長くなり、ワークの渋滞で払い出せないなども考えられます。また、純粋にPLCのエラー検出ロジックに抜け漏れがあり、想定していない状態により停止することもあります。それらの状態を複合的に把握して「何が起きていたのか」を正しく捉えることが重要です。そのためには、各設備のPLCの情報を集約して一元化し可視化する、ときにはカメラなども有効活用して停止時の状態を捉える、などの仕掛けが必要となります。 AWS IoT SiteWise を用いると、PLC やセンサーなどの時系列情報の集約化・可視化が容易に行えます。動画の分析が必要な場合には、 Kinesis Video Streams を用いることで、クラウド上でデータの分析を行うことができます。重要部品の予知保全などに向けては、 Amazon Monitron を用いた回転機械の予知保全や、収集データを Amazon SageMaker で学習し独自の推論モデルをデプロイするなどの方策が考えられます。これらはもちろん、熟練技能者に還元できるデータ基盤ですし、さらにそのデータを集約することで、より上位のレイヤーでの意思決定にも使えるデータ群であるはずです。 図3: つながる工場のリファレンスアーキテクチャ 裾野から上位レイヤーへ こうして、熟練技能者に還元できるデータ活用の基盤を整えることは、そのまま工場長レベル、経営レベルのデータドリブンな意思決定を行うための礎になります。集めたデータを集約し、 Amazon QuickSight などで各レイヤーに必要な切り口で可視化することで、あらゆるレイヤーの意思決定に役立ちます。2023年の AWS Summit Tokyo で展示した 製造ダッシュボード は、キャッシュフローの観点から工場の健康状態を可視化する事例として開発しました。これらのデータソースには、当然ながら先述の製造現場の情報も含まれています。詳細は 別ブログ に譲りますが、現場のデータと基幹システムのデータを掛け合わせて、図5のような可視化を行うことができる、という事例として好評を得ました。 図4: 製造ダッシュボードの簡易アーキテクチャ図 図5: 現場レベルのデータと基幹システムデータを合わせた意思決定のための可視化の例 まとめ 今回は保全技術者を例に挙げて説明しましたが、他にも組立作業者や設備のオペレータ、検査員など、現場レベルでデータドリブンの恩恵を受けられる人たちは大勢いると思います。その人たちに、「上位の意思決定のためにデータを集めろ！」とトップダウンで落とすのではなく、彼らに恩恵のある形でデータ基盤を整えていくと、熟練技能者のクラフトマンシップという、日本の宝を傷つけることなく、「データドリブンとクラフトマンシップが交わる」と言えるのではないでしょうか。また、それらデータを現場に還元しつつ集約するパイプラインを整えることで、より全体最適に向けたデータドリブンな経営に歩を進めることができるのではないでしょうか。それこそが、データドリブンで先を行く海外製造業との差別化要因になると思います。 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。 黒田 雄大 (Yuta Kuroda) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車部品サプライヤーの生産技術部門、情報システム部門、Smart Factory プロジェクトを経て AWS Japan に入社。エンタープライズ事業本部でソリューションアーキテクトとして東海圏の製造業のお客様を中心に技術支援しています。

クラウド移行の停滞は、クラウド採用のビジネス価値を損なう可能性があります。したがって、早期警告サインに注意を払い、タイムリーに修正アクションを取ることが重要です。このブログ記事では、すべてのクラウド移行リーダーが認識しておくべき 5 つの大きな落とし穴について紹介します。これらの問題を早期に発見すれば、停滞を回避することができます。 落とし穴 #1: ステークホルダーの合意の欠如 進捗が順調でない兆候の 1 つは、移行の対象となる業務アプリケーションのリストが変わり続けていることです。一部のアプリケーション オーナー達は、自身のアプリケーションが移行の対象であることを十分に認識していない可能性があります。そのため、彼らは移行作業を保留にして、移行のタイミングを疑問視したり、追加の準備作業を要求したりします。こうした状況が積み重なり、プロジェクトスポンサーから進捗不足についてエスカレーションされた問い合わせが行われることがよくあります。この問題の根本的な原因は、通常、アプリケーションとビジネスチームからの賛同と合意形成の欠如にあります。明確なトップダウンの方針指示なしに、クラウド移行イニシアチブへの投資を行おうとしているためです。 これに対処するには、ビジネスによるスポンサーシップを優先し、プロジェクトのコミットメントを行う際は、アプリケーションおよびビジネスチームからの賛同を得ることが必要です。これを後回しにすると、解決するのがさらに困難になるでしょう。ビジネス成果を達成するための クラウド採用メリット を強調することにより、ビジネスチーム内でのコンセンサスを構築してください。また、クラウド移行するチームにインセンティブを提供することを検討してください。早期に移行するチームに対しては、最初の 6 ヶ月間のクラウドコストの配賦を免除する、といった方法があります。移行プロジェクトのスポンサーとなる上級役職者のリストを作成し、チームのサポートをコミットし、彼らがそれぞれの事業部門におけるプロジェクト完遂の責任を負っていることを明確にしましょう。 落とし穴 #2: 移行ウェーブの計画が常に変動している クラウド移行が停滞するもう 1 つの兆候は、移行ウェーブ (訳註：一つのグループとしてまとめて移行するサーバー群またはアプリケーション群) の計画が変わり続けている時です。適切に定義されたウェーブ計画は、アプリケーション間の依存関係に基づいて、各フェーズまたはウェーブで移行されるものを優先順位付けします。多数のアプリケーション グループによって使用される共有アプリケーションやサービスがある場合、ウェーブの範囲が大きくなり過ぎて一度にすべてを移行できなくなります。このような依存関係を後になって発見したチームは、通常、関連するすべてのアプリケーションを移行ウェーブから削除し、再計画のためにバックログに追加してしまいます。その結果、移行チームは効果的に利用されず、遅延とコスト超過を招きます。 プロジェクトスポンサーは、移行ウェーブの範囲縮小に疑問を抱き、過度に保守的なアプローチであるとみなして、移行速度を上げるようクラウド移行リーダーに圧力をかけます。この問題のよくある根本原因は、移行ウェーブの計画時にアプリケーションポートフォリオに関する十分なインベントリデータがないことです。 これを緩和するには、移行の開始時に、優先度の高いアプリケーションのチームとの設計レビューを実施します。 AWS Migration Hub を介する AWS ディスカバリツール (訳註：アプリケーションおよびサーバー情報の収集ツール) のような、 ツールベースのアプリケーションディスカバリプロセス を移行ウェーブ計画の前に実施してください。アプリケーションディスカバリの結果に基づいて、文書化され正式に拘束力のある プロジェクトベースライン を確立します。 変更を管理および監視し、ベースラインからの逸脱について早期にエスカレーションできるよう、正式な変更管理プロセスを実装します。 落とし穴 #3: 移行アプローチがアプリケーションによって異なる 移行プロセスにおける重要な懸念事項は、移行アプローチがアプリケーションごとに大きく異なる場合です。これにより移行方法論に一貫性がなくなり、チームが延々と議論を続けたり、設計上の決定を後から見直したり、決定済みの移行範囲を都合よく改変してしまったりすることになります。この落とし穴は、規模の経済や一貫した成果の達成を阻害するため、移行プロジェクトに重大な悪影響を及ぼします。クラウドへの移行に伴って技術的な最適化に過度に重点を置くと、移行の全体的な進行が遅くなります。また、元のビジネスケースで予測された価値を実現することも難しくなります。 この課題を克服するには、事前の対策が不可欠です。標準的な 移行アプローチ とターゲット アーキテクチャ パターンを定義して移行方法論を標準化し、スケールする基盤を構築します。また、合理化プロセスの一環として、共通の移行戦略に基づいてアプリケーションをグループ化します。 メインフレームアプリケーション のリファクタリングのような、かなりの変更を必要とするワークロードに対しては、ツールによる自動化を標準的に利用し、カスタマイズした移行作業をできるだけ減らします。停滞を避けるため、 一貫した設計決定アプローチ をクラウド移行の初期フェーズで確立してください。 落とし穴 #4: 効果の無いエスカレーション 移行が計画通りに進んでいない場合は、可視性とリーダーシップの支持を得るためのエスカレーションプロセスを用意することが不可欠です。プログラムマネジメント会議は、多くの場合、リーダーシップの助けを必要とするリスクや課題について話し合い、対処する場です。共有サービスチーム (訳注：認証機能やログ収集機能など、多くの業務アプリケーションが共通して利用するサービスの担当チーム) のリーダーなどの適切なステークホルダーがこれらの重要な会議に参加しないと、移行イニシアチブの進捗に悪影響を及ぼします。 したがって、プロジェクトのキックオフ前に包括的な コミュニケーション計画 と ガバナンス構造 を確立する必要があります。これにより、課題に十分な注意が払われ、障害を取り除くことができる適切な人物が会議に参加することを確実にできます。共有サービスチームと、緊急解決時間の定義や、ファイアウォール更新のような標準的なリクエストの受付担当者のアサインを交渉することも検討して下さい。これにより、移行チームはアジャイルスプリントでの作業を続けることができ、停滞を防ぐことができます。 落とし穴 #5: 移行に関する問題認識の遅れ 移行プロセスにおける問題表出の遅れは、懸念すべきことです。これはいくつかの症状から明らかになります。移行の進捗状況に関する極めて重要なアップデートが、プロジェクトリーダーに積極的に伝えられていない場合があります。実際に遅延が発生して初めて、問題に気づくということがよく起きているかもしれません。すると、プロジェクトスポンサーは、プロジェクトチームがクラウド移行を管理できているという信頼を失い始めます。問題が素早く対処されないため、ビジネス成果が達成できないリスクがあります。 これに対処するには、クラウド移行開始時の 移行統制メカニズム に対する合意が重要です。これらのメカニズムは通常、 効果的な設計決定アプローチ と 移行プロセス や ツール の確立、 ベースライン計画の作成 、移行チームの技術リーダーの任命、効果的な エスカレーションパス の構築を含みます。移行統制メカニズムは、監督の強化、課題の早期発見、移行の円滑化に役立ちます。 まとめ このブログ記事では、クラウド移行リーダーが注意すべき 5 つの重要な落とし穴に焦点を当てています。これらは、移行プロセスとビジネス成果の実現を妨げる可能性があります。クラウド移行のジャーニーを成功させるには、これらの落とし穴を早期に認識して対処することが不可欠です。よりスムーズな移行体験への道を開くための重要なポイントは次のとおりです。 移行プロジェクトのキックオフ前に、テクノロジーチームおよびビジネスチームと、移行に対するトップダウンの方針指示内容を確認する。 移行範囲のベースラインを作成し、プロジェクトの変更管理を正式化する。 移行に対するトップダウンの目標と技術戦略の整合性を取る。 プロジェクトの初日から効果的なエスカレーションパスを構築する。 移行を円滑に進めるための主要なプロジェクト管理メカニズムについて合意する。 さらなる学習リソース Guide for AWS large migrations Cloud migration health-check matrix How to migrate AWS Migration Acceleration Program Cloud-driven enterprise transformation on AWS 著者について Rostislav Markov Rostislav は AWS プロフェッショナルサービスのプリンシパルアーキテクトです。テクニカルリーダーとして、AWS のお客様やパートナーのクラウドトランスフォーメーションプログラムに取り組んでいます。仕事以外では、家族と屋外で過ごしたり、テニスをしたり、スキーを楽しんだりしています。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

この記事は、 Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 を翻訳したものです。 多くの software-as-a-service (SaaS)アプリケーションはマルチテナントデータを Amazon Simple Storage Service(Amazon S3) に保存しています。Amazon S3 にマルチテナントデータを配置するには、バケットとキーにテナントデータをどのように分散させるかを考える必要があります。それは、SaaS ソリューションのセキュリティ、管理性、パフォーマンスを損なうことなく行う必要があります。 この記事では、Amazon S3 でテナントデータをパーティション化する際に適用できるさまざまな戦略を説明します。これらの戦略を自社のソリューションに適用する際に影響を与える可能性のある考慮事項を明示し、パーティション戦略がテナント分離と S3 オブジェクトへのアクセス制限にどのような影響を与えるかを見ていきます。 Amazon S3 データパーティション化 マルチテナントデータを表現するためのさまざまなアーキテクチャパターンを検討する際、そのデータをどう編成するか決める必要があります。このようなマルチテナントストレージメカニズムとパターンを通常、 データのパーティション化 と呼びます。 各 Amazon Web Services (AWS) ストレージ技術は通常、データパーティショニングモデルの独自のコレクションを持っています。これはソリューションのさまざまなニーズをサポートするためにテナントオブジェクトをどのように編成できるかを検討する際、 Amazon S3 においても言えることです。 どのパターンを選択するかは、いくつかの要因に影響を受けることに注意することが重要です。推定総テナント数、テナント環境の分離モデル、アプリケーションのアクセスパターンは、選択するオプションに影響を与える可能性のある考慮事項の 1 つです。 以下のセクションでは、一般的なマルチテナント S3 戦略を見ていき、これらの戦略がどんなケースでどのように適用されるかに焦点を当てます。 テナント専用バケットモデル (Bucket-Per-Tenant) テナントデータを Amazon S3 でパーティション化する最も単純なアプローチは、テナント毎に個別のバケットを割り当てることです。以下の図は、このモデルの例を示しています。 このアプローチでは、各テナントにデータを保持するバケットが割り当てられます。このバケットには、テナントと一意に結びつく名前が付けられます。 このモデルは、少数のテナント (数十または数百) を扱う場合にうまく機能します。しかし、はるかに多くのテナントをサポートする必要のある環境には適していません。Amazon S3 には、AWS アカウント毎にデフォルトで最大 100 バケットの制限があります (ハード制限は 1000) があります。 もう 1 つの考慮事項は、バケット名です。各 S3 バケット名はすべての AWS アカウント全体でグローバルに一意である必要があるため、テナント毎のバケットモデルではこの要件をサポートする命名規則が必要になります。 バケット名は公開されているため、一般にテナント固有の情報を含む名前は避けるべきです。 最後に、S3 バケット数の制限は、この SaaS アプリケーション固有のものではありません。他の環境 (本番、ステージング、開発) や専用のバケットを必要とする AWS サービスがクォータの一部を利用している可能性があります。 全体として、テナント毎のバケットモデルはシンプルですが、 SaaS 環境のスケールと俊敏性に影響を与える可能性のあることは明白です。 テナント毎のオブジェクトキープレフィックス モデル SaaS プロバイダーはテナント専用バケットモデルの制限を克服し、より大規模な展開を実現するために、キーのプレフィックスを使用してオブジェクトをテナントと関連付ける場合があります。このアプローチによりデータパーティション構造や編成を損なうことなく、はるかに大規模なテナントコレクションに拡張できます。 ここでは、 2 つのテナントが 1 つのバケットを共有しています。各テナントには、そのテナントに属するオブジェクトを識別する一意のプレフィックスがあります。幸いなことに、バケットに格納できるオブジェクト数やプレフィックス数には 制限がない です。 表面化する可能性のある課題の 1 つは、S3 キーに対する操作がテナント全体で均等に分散している可能性が低いことです。パーティション分割されたプレフィックス毎に、ソリューションは 1 秒間に数千のトランザクション を実現できます。個々のテナントのプレフィックスをシャーディングすることで、負荷をより分散させることができます。 データベースでマッピングしたテナントオブジェクト 場合によってはアプリケーションのオブジェクトアクセスパターンが S3 オブジェクトのパーティション分割方法の選択に影響することがあります。アプリケーション固有の基準 (たとえば、project-a に属する tenant-1 オブジェクトをすべて検索する) を満たすテナントのオブジェクトを検索したいシナリオを想像してみましょう。 ここでのアイデアは、検索可能な要素をデータベースに移動し、そのデータベースを検索して S3 オブジェクトへの参照を見つけ出す、ということです。以下の図は、このユースケースの例を示しています。 この例では、S3 オブジェクトのリクエストを処理するオブジェクトアクセスサービスを図に導入しました。このサービスは、アプリケーションで管理されているいくつかの基準に基づいて S3 オブジェクトをリクエストする機能をサポートするアプリケーションのマイクロサービスになります。 テナントはパラメーターを指定してリクエストを送信し、サービスは識別されたテナントとクエリに必要なパラメーター (ProjectID など) を含むデータベースにクエリを実行します。これらのパラメーターは、データベースをクエリして特定のテナントの S3 オブジェクトを参照するために使用されます。 データベースを使用して S3 オブジェクトへのアクセスを管理しているため、この例ではすべてのテナントの S3 オブジェクトをフラットな階層に混在して格納しています。これらのオブジェクトを常にデータベースから見ることができるのであれば、データベース内のテナント ID の列は、テナント ID に基づいて分離が適用されるパーティショニングモデルを表している可能性があります。これにより、S3 オブジェクトを、このマッピングデータベーステーブルを介してテナントに接続されたオブジェクトのグローバルプールとして保存できます。フラットな構造では、 リクエストスロットリング を避けるためにプレフィックスがランダムな固有のオブジェクトキーが必要です。 さらに、このアプローチは、テナントオブジェクトをプレフィックスで分割した、テナント毎のプレフィックスと組み合わせたハイブリッドモデルでもかまいません。その他に S3 オブジェクトタグを使用して、格納されている各オブジェクトにテナントのメタデータを追加する方法があります。 Amazon S3 オブジェクトのタグ付 けには追加料金がかかります。 顧客による直接アクセスや AWS サービス統合など、オブジェクトアクセスサービスの外部に他のアクセスパターンがある場合は、オブジェクトにキープレフィックスまたはタグを追加するとよいでしょう。 テナント分離 テナントの分離 は、すべての SaaS プロバイダーが対処しなければならない基本的なトピックの 1 つです。これは、あるテナントが別のテナントのリソースにアクセスできないようにするアーキテクチャの仕組みです。ここで障害が発生すると、SaaS ビジネスにとって重大で回復不能な事態になる可能性があります。 S3 データパーティション化のモデルを選択する際には、特定のパーティション化モデルがソリューションのテナント分離フットプリントにどのように影響するかも考慮する必要があります。テナント単位およびテナント単位のプレフィックス戦略では、テナント固有の AWS Identity and Access Management (IAM) ポリシーを定義できます。これにより、サービス固有の リソース、アクション、条件コンテキストキー を使用して、テナント間でリソースにアクセスできないようにすることができます。 さまざまなパーティション化モデルに使用される IAM ポリシーは、SaaS 環境のニーズとポリシーサイズ制限に基づいて、静的に作成することも、動的に生成することもできます。この戦略の詳細については、「 動的に生成された IAM ポリシーによる SaaS テナントの分離 」をご覧ください。 エンドポイントベースのパーティション化と分離 Amazon S3 アクセスポイント は、S3 オブジェクトへのアクセスを可能にする名前付きのネットワークエンドポイントです。これにより、S3 データを一連のバケットやキーと見なす必要がなくなります。代わりに、アクセスポイントを使用して各テナントのデータへのアクセスを制御することに焦点が移ります。デフォルトでは、1 つのアカウントに設定できるアクセスポイントのクォータは 1,000 個です。 この方法では、特定のテナントに関連付けられているオブジェクトへのアクセスを管理できるポリシーを使用して、個々のテナントのエンドポイントを定義できます。アクセスポイントは、S3 バケット名、オブジェクトキープレフィックス、またはオブジェクトタグ制限をサポートする静的に設定された IAM ポリシーを使用します。 これにより、テナントの分離を維持しながら、他の AWS サービスまたはアカウントから S3 オブジェクトにアクセスできます。アクセスポイントは AWS のサービスや機能の一部で動作しますが、すべてではありません。また、SaaS のお客様が自分の AWS アカウントから S3 オブジェクトに直接アクセスできるようにすることもできます。 暗号化キーによるテナントオブジェクトの保護 SaaS ソリューションの S3 パーティション化モデルは、追加のセキュリティ上の考慮事項の影響を受ける可能性があます。環境によっては、組織のコンプライアンスやデータ機密性のニーズにより、暗号化によるオブジェクトの保護をさらに強化する必要があります。 ここでは、各テナントに データを保護するキー をどのように提供できるかに重点をおきます。このようなシナリオでは、Amazon S3 を AWS Key Management Service (AWS KMS) と組み合わせて使用すると、S3 オブジェクトをサーバー側で暗号化できます。 採用した S3 パーティション化モデルは、キーの適用方法に影響します。たとえば、テナント単位のバケットモデルでは、バケット毎に固有の暗号化キーを割り当てることができます。 テナント毎のプレフィックスモデルでも、 エンベロープ暗号化 を使用してルート暗号化キーを共有し、各オブジェクトを個別に暗号化できます。エンベロープ暗号化とは、プレーンテキストデータをデータキーで暗号化し、そのデータキーをルートキーで暗号化することです。 アプリケーションコードがオブジェクトの書き込みリクエストを処理する場合、オブジェクトごとに暗号化に使用する AWS KMS キーを指定できます。AWS アカウントの各リージョンで、最大 10,000 個のカスタマー管理キーを使用できます。また、オプションでオブジェクト毎に追加の暗号化コンテキストを指定し、 認証化された暗号化 をサポートすることもできます。 AWS Key Management Service によるサーバー側の暗号化 (SSE-KMS) を使用すると、 Amazon S3 バケットキー により AWS KMS リクエストのコストを最大 99% 削減できます。この S3 バケットキーは S3 内で一定期間使用され、同じ AWS KMS キーで暗号化されたオブジェクトの S3 バケットキーのみが共有されます。これにより、KMS API のリクエスト数の制限を下回ることができます。 暗号化と IAM ポリシーは、全体的なセキュリティとテナント分離モデルの一部として組み合わせることができます。 テナントの活動と利用量 SaaS ソリューションは多くの場合、製品のコストが顧客の利用プロファイルに基づいて決定される従量課金制モデルで販売されます。テナントレベルでコスト情報を追跡することで、メータリングや価格設定を利用量ベースで決定できます。 テナント単位のバケットモデルでは、 コスト配分タグ を使用して個別の S3 バケットにラベルを付けることで、テナントのストレージコストを追跡できます。 テナント毎のプレフィックスアプローチでは、 Amazon S3 インベントリ を使用して S3 の利用量を追跡できます。これには、ソースバケット内のオブジェクトのリストと各オブジェクトのメタデータが含まれます。メタデータフィールドにはキー名とサイズが含まれます。ただし、インベントリリストにはオブジェクトタグは含まれていません。S3 バケットまたは共有プレフィックスのインベントリは、日単位または週単位で生成できます。 インベントリ完了時の Amazon S3 イベント通知 を設定できます。Amazon S3 インベントリには追加料金がかかります。 Amazon Athena を使用すると、 S3 インベントリをすばやく分析してクエリを実行する こともできます。Athena では実行したクエリに対してのみ支払いが発生し、各クエリでスキャンされたデータ量に基づいて課金されます。 サーバーアクセスログ は、S3 バケットに対して行われたリクエストの詳細な記録を提供します。これらのログを使用してテナントの API リクエストとデータ転送コストの両方に関する S3 請求額を分析できます。これは、Amazon Athena を使用して サーバーアクセスログの分析とクエリを行う ことができる一例です。ログレコードフィールドには、時間、バケット、キー、送信バイト数、オブジェクトサイズが含まれますが、オブジェクトタグは含まれません。 これらのログは ベストエフォート方式で配信 されることに注意してください。ログレコードが失われることはほとんどないですが、リクエストが実際に処理されてから特定のリクエストのログレコードの配信されるまで時間がかかることがあります。 ライフサイクル設定ルールの利用 Amazon S3 では、S3 オブジェクトの ライフサイクルを定義する こともできます。SaaS 環境ではテナント毎に (ティアやその他のアプリケーションに対する要件に基づいて) 異なるライフサイクルポリシーを提供することもできます。 これらの S3 ライフサイクル管理ルールを使用して、オブジェクトを別のストレージモデルに移行するタイミングがいつ期限切れになるか判断できます。たとえば、プレミアム階層のテナントには、基本階層のテナントとは異なる移行ルールが適用される場合があります。 ライフサイクルルールは、ライフサイクルルールで指定した <Filter> 要素に基づいて、バケット内のすべてまたは一部のオブジェクトに適用できます。キープレフィックス、オブジェクトタグ、またはその両方の組み合わせでオブジェクトをフィルタリングできます。S3 ライフサイクル設定には最大 1,000 個のルールを設定できますが、この制限は調整できません。 S3 バケットのその他の設定 Amazon S3 のセキュリティとアクセス管理 に関する AWS re: Invent 2021 セッションは、マルチテナントの SaaS アプリケーションで使用されているもの含め、すべての Amazon S3 バケットにおけるコストとセキュリティ管理に有益です。 Amazon S3 Intelligent-Tiering ストレージクラスは、アクセスパターンが変化すると、運用上のオーバーヘッドやパフォーマンスへの影響なしに、データを最も費用対効果の高いアクセス階層に自動的に移動することで、ストレージコストを最適化するように設計されています。 S3 バケットのアクセスコントロールリスト (ACL) を無効にすることをお勧めします。 アカウント管理者とバケット所有者は、 S3 Block Public Access を使用することで、リソースの作成方法に関係なく S3 リソースへのパブリックアクセス制限を簡単に一元管理できます。 まとめ Amazon S3 にマルチテナントデータを正しく保存することは、多くの SaaS アプリケーションにとって重要です。この記事では、データパーティション化の複数のオプションとその主な考慮事項について説明しました。アクセスポリシーや暗号化など、テナント分離をサポートする戦略を言及しました。 テナントのアクティビティとコストトラッキング、オブジェクトのライフサイクル管理、その他のバケットセキュリティ設定に関する関連情報も含まれています。 AWS SaaS Factory について AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。 AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。 また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。 こちら にご登録いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。 翻訳はテクニカルソリューションアーキテクトの呉( @kkam0907 ) が担当しました。原文は こちら です。

この記事は An Overview of Bulk Sender Changes at Yahoo/Gmail (記事公開日: 2024 年 1 月 12 日) を翻訳したものです。 Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service (Amazon SES) を利用するお客様が具体的に何をすべきかを詳しく見ていきましょう。 新しいメール送信者の要件は何ですか? 新しい要件には、メールボックスプロバイダーへの良好な配信を実現するために、すべてのメール送信者が従うべき長年培われてきたベストプラクティスが含まれています。Gmail、Yahoo Mail、その他のメールボックスプロバイダーに対して、1 日に 5000 件を超える大量のメッセージ (バルクメール) を送信する場合や、多くのの受信者がそのメールを迷惑メールとして報告する場合に、これらのベストプラクティスに従う必要があるという点が新しい点です。 新しい要件は、1) ドメイン認証の厳守、2) バルクメールの購読を簡単に解除する方法の提供、3) 迷惑メールの苦情率を監視して 0.3% 未満に抑えるという 3 つのカテゴリに分類できます。 * このブログは元々 2023 年 11 月に公開されたもので、タイムラインを明確にし、その他のリソースへのリンクを提供するために 2024 年 1 月 12 日に更新されました。 1. ドメイン認証 メールボックスプロバイダーは、DKIM と SPF によるドメインに合わせた認証を要求し、メッセージの From ヘッダーで使用されるドメインに DMARC ポリシーを適用することを要求します。たとえば、 gmail.com は隔離を行う DMARC ポリシーを公開します。これは Gmail から送信されたと主張する不正なメッセージは、迷惑メールフォルダに送信されることを意味します。 SPF と DKIM のドメインアライメントについて理解を深め、ドメインの DMARC ポリシーから最大限の価値を引き出すには、 Amazon SES: Email Authentication and Getting Value out of Your DMARC Policy をご覧ください。 次のステップは、Amazon SES を利用するお客様がドメイン認証要件をどのように遵守できるかを概説したものです。 ドメイン ID の採用: 現在 Amazon SES で E メールアドレス ID を主に使用しているお客様は、メールボックスプロバイダーへの配信性を向上させるために、検証済みのドメイン ID を採用する必要があります。SES で 検証済みのドメイン ID を使用すると、メッセージにはドメインに合わせた DKIM 署名が付きます。 どのドメインを使うべきかわかりませんか？認証済み E メールの送信に関するその他のベストプラクティスガイダンスについては、 Choosing the Right Domain for Optimal Deliverability with Amazon SES を参照してください。 カスタム MAIL FROM ドメインの設定: ベストプラクティスにさらに沿うために、SES を利用するお客様は SPF がドメインにアライメントするように カスタム MAIL FROM ドメインも設定する必要があります。 以下の表は、Amazon SES で使用する ID のタイプに基づいた 3 つのシナリオを示しています。 From ヘッダーに example.com を使用するシナリオ DKIM で認証される ID SPF で認証される ID DMARC 認証の結果 検証済みのメールアドレス ID として foo@example.com を使用 amazonses.com email.amazonses.com 失敗 — 送信ドメインに一致する DKIM 署名または SPF レコードがないため、DMARC 認証が失敗します。 検証済みドメイン ID として example.com を使用 example.com email.amazonses.com 成功 — DKIM 署名が送信ドメインと一致しているため、DMARC 認証に合格します。 検証済みドメイン ID として example.com 使用し、カスタム MAIL FROM ドメインとして bounce.example.com を使用 example.com bounce.example.com 成功 — DKIM と SPF は送信ドメインと一致しているため合格します。 表 1: Amazon SES で使用される ID のタイプに基づく 3 つのシナリオ。検証済みのドメイン ID を使用し、なおかつカスタム MAIL FROM ドメインを設定すると、DKIM と SPF の両方が From ヘッダードメインの DMARC ポリシーに準拠することになります。 サブドメインを戦略的に使用する: Amazon SES を利用するお客様は、さまざまな E メール送信のユースケースに応じて、From ヘッダーで使用されるドメインとサブドメインへの戦略的なアプローチを検討する必要があります。例えば、マーケティングメールの送信には 検証済みドメイン ID marketing.example.com を使用し、トランザクションメールの送信には 検証済みドメイン ID receipts.example.com を使用するといった具合にです。 なぜドメインを区別するのでしょうか? マーケティングメッセージは迷惑メールの苦情率が高くなる場合があり、一括送信者の要件を満たす必要がありますが、購入領収書などのトランザクションメールでは、必ずしもバルクメールに分類されるほど迷惑メール苦情が多くなるとは限りません。 DMARCポリシーを公開する: ドメインの DMARC ポリシーを公開します。メッセージの From ヘッダーに使用するドメインには、DNS 内のドメインの DMARC ポリシーに p= タグを設定したポリシーが必要です。このポリシーは「p=none」に設定することで一括送信の要件を満たすことができます。そのドメインを使用するすべての E メールが DKIM または SPF ドメインに整合する認証済み識別子で認証されたことを確認したら、後で隔離 (p=quarantine) または拒否 (p=reject) に変更できます。 2. E メール受信者が簡単に配信停止できるように設定する 一括送信者には、メッセージ内に見つけやすいリンクを追加して購読を解除するメカニズムを含めることが期待されます。2024 年 2 月から適用されるメールボックスプロバイダーのルールでは、送信者は RFC 2369 と RFC 8058 で定義されているワンクリック購読解除ヘッダーを追加することが要求されます。これらのヘッダーを使用すると受信者が簡単に購読を解除できるようになり、受信者がメッセージを迷惑メールとしてマークして苦情を申し立てる頻度が減ります。 メールボックスプロバイダーがバルクメールと判断する要因は様々です。1 日あたり 5,000 件を超える量も 1 つの要因ですが、メールボックスプロバイダーが使用する主な要因は、受信者が本当にそのメールを受け取ることを望んでいるかどうかです。 メールがバルクと見なされるかどうかわからない場合は、迷惑メールの苦情率を監視してください。苦情率が高い場合や増え続けている場合は、受信者が簡単に購読を解除できる方法を提供する必要があることを示しています。 簡単に購読解除を行えるようにする要件を順守する方法 次のステップは、Amazon SES を利用するお客様が簡単に購読解除できる要件を満たす方法をまとめたものです。 送信するメッセージにワンクリック購読解除ヘッダーを追加する: Amazon SES を利用するお客様が、大量または迷惑と思われる可能性のあるメッセージを送信する場合には、受信者が簡単に購読を解除できる方法を実装する必要があります。これには SES の 購読管理機能 を使用することができます。 メールボックスプロバイダーは、一括送信者に対し、受信者がワンクリック購読解除ヘッダーを使用してワンクリックでバルクメールの購読を解除できるようにすることを要求しています。ただし、メッセージ内の購読解除リンクを使用して、受信者がオプトアウトの設定を行うためのランディングページに受信者を誘導してもかまいません。 SES の購読管理機能を使用せずにワンクリック購読解除を設定するには、送信メッセージに次の両方のヘッダーを含めてください: List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://example.com/unsubscribe/example> 受信者がワンクリックで購読を解除すると、次の POST リクエストが届きます: POST /unsubscribe/example HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-Click Gmail の FAQ と Yahoo の FAQ はどちらも、一括送信者が各メッセージのフッターに、機能する登録解除リンクを明確に表示している限り、ワンクリックの登録解除要件は 2024 年 6 月まで適用されないことを明確にしています。 配信停止リクエストを 2 日以内に受け付ける: 購読解除手続きを行うと、受信者が今後同様のメッセージを受信しなくなることを確認してください。メールボックスプロバイダーは、一括送信者が受信者にワンクリックで E メールの購読を解除できるようにすること、および送信者が購読解除要求を 2 日以内に処理することを要求しています。 SES の購読管理機能を採用する場合は、受信者のオプトアウト設定をメール送信リストのソースと必ず統合してください。独自のワンクリック購読解除を実装する場合 (Amazon API Gateway と AWS Lambda 関数を使用する場合など) は、ソースとなるメーリングリストからその E メールアドレスへの送信が抑制するように設計されていることを確認してください。 メーリングリストの作成方法を見直す: メーリングリストの購入を控えること、オプトインフォームをボットの悪用から保護すること、確認メッセージで受信者の好みを確認すること、要求されていないカテゴリに受信者を自動的に登録しないようにすることなど、責任ある E メールの取り扱いを行ってください。 新しく義務付けられたベストプラクティスを順守する前に、迷惑メールの苦情率が高くならないようにするには、メーリングリストのオプトインを適切に行うことが最善の方法です。詳細については、 What is a Spam Trap, and Why You Should Care をご覧ください。 3. 迷惑メール率を監視する メールボックスプロバイダーは、自分の E メールがメールボックスプロバイダーによって迷惑メールとして扱われないように、すべての送信者に迷惑メールの苦情率を 0.3% 未満に抑えるよう要求します。次のステップは、Amazon SES を使用するお客様が迷惑メール苦情率の要件を満たす方法をまとめたものです。 Google ポストマスターツールへの登録: Amazon SES を利用するお客様は、Gmail 受信者に対する迷惑メールの苦情率を監視するために Google ポストマスターツール に登録することが推奨されます。 Gmail では、迷惑メールの苦情率を 0.1% 未満に抑えることを推奨しています。Gmail の受信者と他のメールボックスプロバイダーの受信者が混在して送信する場合、Gmail の Postmaster Tools によって報告される迷惑メール苦情率は、指標を確認できないメールボックスプロバイダーでの迷惑メール苦情率を示す良い指標となります。 Amazon SES の Virtual Deliverability Manager を有効にする: Amazon SES アカウントで Virtual Deliverability Manager (VDM) を有効にします。お客様は VDM を使用して、多くのメールボックスプロバイダーのバウンス率と苦情率をモニタリングできます。Amazon SES では、 レピュテーションメトリクスを監視し、苦情率を 0.1% 未満に抑えること をお客様に推奨しています。 設定セットを使用して送信を分離し保護する: Amazon SES を利用するお客様は、送信ユースケースをドメインごとに分離することに加えて、送信ユースケース毎に異なる 設定セット を使用することが推奨されます。 設定セットを使用すると、よりきめ細かく 送信アクティビティをモニタリング し、 制限を実装 できます。迷惑メールの苦情率が許容範囲を超えた場合は、 設定セットを使用する送信を自動的に一時停止する こともできます。 まとめ これらの変更は 2024 年 2 月に予定されていますが、各メールボックスプロバイダーが変更を適用する正確なタイミングと方法は異なる場合があることに注意してください。2 月より前にいずれかのメールボックスプロバイダーで配信に関する問題が発生した場合は、最初のステップとしてこれらの必要なベストプラクティスを順守することが最善の方法です。 このブログが、この変更に関して混乱している部分を明らかにし、2024 年 2 月に向けて準備しておくべき情報を皆様に提供できることを願っています！ 参考リンク: Gmail のお知らせ: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ Yahoo のお知らせ: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam DMARC ポリシーに関するブログ: Amazon SES: Email Authentication and Getting Value out of Your DMARC Policy 適切なドメインの選択に関するブログ: Choosing the Right Domain for Optimal Deliverability with Amazon SES 翻訳はクラウドサポートエンジニアの富岡が担当しました。原文は こちら です。

はじめに Amazon Elastic Cotainer Service (Amazon ECS) は、AWS 上で毎週何十億ものアプリケーションコンテナのライフサイクルを管理しているコンテナオーケストレーションサービスです。Amazon ECS の主な目標の 1 つは、運用者にかかる諸々の負担を取り除くことです。Amazon ECS はアプリケーションコンテナを 24 時間 365 日監視し、予期しない変化に人間よりも迅速かつ適切に対応できます。Amazon ECS は、アプリケーションコンテナのデプロイを継続的に自己修復してあるべき状態に戻すことで、アプリケーションのクラッシュやハードウェア障害などの望ましくない変更に対応します。また、トラフィックの急増など、アプリケーションが停止する原因となる外部要因もあります。こうした要因には対処が難しい場合があります。この投稿では、Amazon ECS がタスクの正常性の問題とタスク置換を処理する方法に最近加えられた変更と、これらの変更によって Amazon ECS でオーケストレーションされたアプリケーションの可用性がどのように向上するかについて詳しく説明します。 タスクの正常性評価 Amazon ECS はいくつかの基準に基づいてタスクの正常性を評価します。 まず、タスクが正常であるためには、必須とマークされているすべてのコンテナが実行されている必要があります。すべての Amazon ECS タスクには、少なくとも 1 つの必須コンテナが必要です。ベストプラクティスに則ったコンテナは 1 つのアプリケーションプロセスを実行し、重大なランタイム例外によってそのプロセスが終了すると、コンテナは停止します。停止したコンテナが必須とマークされていた場合は、タスク全体が正常でないと見なされ、タスクを置き換える必要があります。 Amazon ECS タスク定義を使用して、Amazon ECS エージェントがコンテナ内で定期的に実行する内部ヘルスチェックコマンドのオプションを設定できます。このコマンドは、成功を示す終了コード 0 を返すことが期待されています。0 以外の終了コードが返された場合は、失敗したことを意味します。その場合コンテナは異常と見なされます。必須コンテナに異常があるためタスクも異常と見なされ、Amazon ECS がタスクを置き換えます。 Amazon ECS サービスを使用して、アプリケーションコンテナと他の AWS サービスとの間のアタッチメントを設定できます。たとえば、コンテナデプロイを Elastic Load Balancing ( ELB ) または AWS Cloud Map に関連づけることができます。これらのサービスは独自の外部ヘルスチェックを行います。たとえば、ELB は定期的にコンテナへの接続を開いてテストリクエストを送信しようとします。その接続を開くことができない場合や、コンテナが予期しない応答を返した場合、またはコンテナの応答に時間がかかりすぎる場合、ELB はターゲットコンテナが異常であると見なします。Amazon ECS は、Amazon ECS タスクが正常か異常かを判断する際に、この外部のヘルスステータスも考慮します。ELB ヘルスチェックに異常があると、タスクは置き換えられます。 タスクが正常であるためには、すべてのヘルスステータスのソースが正常と評価されなければなりません。いずれかのソースが異常ステータスを返した場合、Amazon ECS タスクは異常と見なされ、置き換えられます。 タスク置換動作 Amazon ECS タスクの置換は、主に次の 2 つの状況で行われます。 UpdateService API コールによって新しいデプロイがトリガーされる場合。以前のデプロイに含まれる既存のタスクを、新しいデプロイに含まれる新しいタスクに置き換える必要があります。 アクティブなデプロイの内、既存のタスクに異常が生じた場合。正常なタスクの数を維持するには、異常なタスクを置き換える必要があります。 Amazon ECS は黎明期から、ローリングデプロイ中のタスク置換の動作については、Amazon ECS サービスの 2 つのプロパティを使用して設定可能でした。 maximumPercent – これにより、Amazon ECS がサービスの希望するタスク数を超えて起動できる追加タスクの数がコントロールされます。たとえば、 maximumPercent が 200% で、サービスの希望するタスク数が 8 タスクの場合、Amazon ECS は合計で 16 タスクまで追加タスクを起動できます。 minimumHealthyPercent – これにより、デプロイ中に Amazon ECS サービスの希望するタスク数を下回ることが許される割合がコントロールされます。たとえば、 minimumHealthyPercent は 75% で、サービスに必要なタスク数は 8 タスクとします。その場合、Amazon ECS は 2 つのタスクを停止して、サービスのデプロイメントを実行中のタスクを 6 つに減らすことができます。 maximumPercent と minimumHealthyPercent は、Amazon Elastic Compute Cloud ( Amazon EC2 ) 上で Amazon ECS タスクを実行するときに、ローリングデプロイの動作を微調整するための効率的な制御として長年機能してきました。しかし、これらのデプロイコントロールは、ますます多くの Amazon ECS ユーザーがサーバーレスの AWS Fargate を選択している世界ではあまり意味がありません。AWS Fargate の使用率は、クラスターに登録した Amazon EC2 インスタンスの数によって制約されないため、モダンアプリケーションではローリングデプロイ中に実行タスク数が希望する数を下回ったり、起動される追加タスクの数を減らしたりすることを Amazon ECS に要求する必要がありません。 さらに、問題のあるタスクを置き換えるという点では、もともと maximumPercent と minimumHealthyPercent によるコントロールは無視されていました。タスクが異常になると、サービスの必要数が minimumHealthyPercent で定義されたしきい値を大幅に下回る可能性があります。たとえば、8 つのタスクを実行していて、そのうちの 4 つに異常が生じた場合、Amazon ECS は 4 つの異常なタスクを終了し、4 つの代替タスクを起動します。実行中のタスクの数は、一時的に必要な数の 50% まで下がってしまいます。 Amazon ECS による異常なタスクの置き換え方法がアップデートされました 2023 年 10 月 20 日より、Amazon ECS は異常なタスクを置き換えるときに可能な限り maximumPercent を使用するようになりました。この仕組みを理解するために、いくつかのシナリオを見てみましょう。 タスクのクラッシュ あなたは希望するタスク数が 8 つ、最大パーセントが 200% のサービスを実行しています。8 つのタスクのうちの 4 つに重大な実行時例外が発生しています。そのプロセスがクラッシュして終了し、重要なコンテナが終了してしまいました。Amazon ECS は、必須コンテナが終了したことで 8 つのタスクのうちの 4 つに異常が発生したことを観測しました。残念なことに、異常なコンテナがクラッシュしたため、Amazon ECS の正常稼働率が 100% を下回ることを避けられません。実行中タスクの数は一時的に希望の数の 50% まで下がりますが、Amazon ECS は実行中タスクの数を希望の 8 タスクに戻すために、できるだけ早く 4 つの代替タスクを開始します。 フリーズされたタスク あなたは希望するタスク数が 8 つ、最大パーセントが 200% のサービスを実行しています。コード内の無限ループが原因で、8 つのタスクのうちの 4 つはフリーズしますが、プロセスは実行されたままです。アタッチされたロードバランサーはサービスにヘルスチェックリクエストを送信し、ターゲットコンテナがヘルスチェックリクエストに応答しなくなったため、ターゲットに異常があるとマークしました。Amazon ECS は、これら 4 つのフリーズされたタスクを異常と見なします。サービスの最大パーセントでは、最大 16 個のタスクを処理できます。Amazon ECS は、異常な 4 つのタスクに対する 4 つの代替タスクを起動し、実行中タスクは合計 12 個になります。追加した 4 つのタスクが正常になると、Amazon ECS は異常な 4 つのタスクを停止します。これにより、実行中のタスク数は必要な 8 タスクに戻ります。 過負荷のタスク あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。サービスには Auto Scaling ルールがアタッチされています。また、ロードバランサーも接続されており、ロードバランサーを経由して大量のトラフィックが流入します。トラフィックが急増するため、タスクからの応答時間が大幅に遅くなります。応答時間が遅くなると、ロードバランサーのヘルスチェックが失敗し、ELB は 8 つのターゲットすべてを異常とマークします。ELB は正常なターゲットがないため オープンに失敗 し、すべてのターゲットにトラフィックを分散し続けます。 Amazon ECS は、8 つのタスクすべてが正常でないことを観測します。そして、Amazon ECS はこれらの異常なタスクを置き換えようとします。最大パーセントを 150% に設定すると、サービスは最大 12 個の実行中タスクを起動できます。そのため、Amazon ECS は異常な実行中タスクを直ちに停止することはしません。代わりに、既存の 8 つの正常でないタスクと並行して 4 つの代替タスクを起動します。幸いこれらの 4 つの追加タスクにより、ELB はより多くのターゲットにトラフィックを分散できるようになります。実行中の 12 個のタスクはすべてタイムアウトすることなく受信トラフィックを処理できるようになり、正常性が安定します。Amazon ECS は、正常に実行されているタスクが 12 個であることを観測します。 同時に、元の 8 つの実行中タスクの CPU 使用率が高いことが観測されたことに基づいて、アプリケーションの Auto Scaling ルールが実行されました。このルールにより、Amazon ECS サービスに必要な実行中タスクの数が 8 個から 10 個に更新されました。そのため、Amazon ECS は 12 個の正常に実行されているタスクのうちの 2 つだけを停止します。これにより、タスク数は必要な実行中タスク数である 10 個まで減少します。 制限された最大パーセント あなたは必要なタスク数が 8 つのサービスを実行していますが、ダウンストリームの制限またはインフラストラクチャの制約により、最大パーセントを 100% に設定しています。これでは、実行中の 8 つのタスクと並行して、Amazon ECS が追加のタスクを起動することはできません。このデプロイのタスクがフリーズしたり、過負荷になってヘルスチェックに失敗し始めたら、Amazon ECS はそのタスクを置き換える必要があります。Amazon ECS はまず異常なタスクを停止し、異常なタスクが停止された後に代替タスクを起動します。つまり、実行中のタスク数は依然として一時的に必要な数を下回っています。 ローリングデプロイ中にタスクがヘルスチェックに失敗 あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。ローリングデプロイを行い、新しいタスク定義に基づいて実行中タスクを更新しました。最大パーセントは 150% なので、Amazon ECS は現在実行中のタスクと並行して追加のタスクを起動できます。ローリングデプロイでは、すでに 4 つの追加タスクの起動がトリガーされています。現在、このサービスには 12 個の実行中タスク (8 個の古いタスクと 4 つの新しいタスク) があります。 このローリングデプロイの最中に、予期しないバグが原因で、古いタスクの一部がヘルスチェックに失敗してしまいました。アクティブなローリングデプロイが行われているため、Amazon ECS は異常なタスクを直ちに終了し、できるだけ早く新しいタスクのインスタンスに置き換えます。ローリングデプロイ中、Amazon ECS は常に失敗したタスクを新しいアクティブなデプロイのタスクに置き換えようとします。 外部要因による継続的なタスク障害 あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。コードが依存しているダウンストリームサービスの 1 つが予期しない応答を返し始め、その結果、コードがヘルスチェックに失敗し始めました。Amazon ECS は 8 つのタスクに異常があり、置き換える必要があると判断したため、8 つの初期タスクと並行して、4 つの代替タスクを追加で起動します。この時点で、12 個のタスクが実行されています。8 個は元のタスク、4 個は代替タスクです。残念ながら、代替タスクは元のタスクと同じ信頼性の低いダウンストリームサービスに依存しているため、12 個のタスクはすべて正常ではありません。 代替タスクが安定せず、Amazon ECS は異常なタスクの数がサービスに必要な数よりも多いと判断したため、異常なタスクの数を必要な数に戻すために、異常なタスクの 4 つをランダムに停止します。Amazon ECS は、問題のあるタスクのうちどのタスクが「元のタスク」で、どのタスクが「代替タスク」であったかについて、ステートフルな情報を保持していません。異常なタスクが十分に停止され、さらにタスクを追加する余地ができたら、ECS は代替タスクを再び開始しようとします。これは、ダウンストリームのサービスが再び信頼できる状態になるか、障害状態をより適切に処理するコード更新が UpdateService API 呼び出しによってロールアウトされるまで、無限に続きます。 ヘルスチェックとワークロードの急増への迅速な対応 以前は、Amazon ECS は常に異常なタスクを最初に停止し、次に代替タスクを起動していました。この動作は、既存のタスクを停止せずに代替タスクを起動する余地がない、静的なサイズの Amazon EC2 インスタンスからなるクラスターにタスクが密集して binpack ( タスク配置戦略 の 1 つ) されている世界では理にかなっています。しかし、最近では、サーバーレスの AWS Fargate キャパシティーを使用して実行されているコンテナワークロードが増えています。AWS Fargate は必要に応じてオンデマンドのコンテナ容量を提供できるため、実行中タスクを中断して代替タスクのための余地を作る必要はありません。さらに、Amazon EC2 上で Amazon ECS を利用しているお客様の多くは、Amazon EC2 インスタンスからなる静的なサイズを持つクラスターにデプロイするのではなく、Amazon ECS キャパシティプロバイダーを利用してオンデマンドで追加の Amazon EC2 インスタンスを起動するようにしています。そのため、現在 Amazon ECS ではサービスの maximumPercent の使用を優先し、代替タスクが正常になるまで異常なタスクを可能な限り実行し続けます。 さらに、Amazon ECS の新しいタスク置換動作により、高負荷なタスクが終了するのを防ぐことができます。ワークロードが急増すると、場合によってはデプロイの内のいくつかのタスクが異常になり、その結果タスクが置き換えられてしまいます。しかし、Amazon ECS が代替タスクを起動するために異常なタスクを停止すると、ロードバランサーは残りの正常なタスクに多くのワークロードを移してしまい、その結果、それらのタスクは異常な状態になります。短時間のうちに、全ての正常なタスクに負荷がかかると、ヘルスチェックの失敗が次々に発生し、すべてのタスクに異常が生じてしまいます。 最終的には、アプリケーションの Auto Scaling ルールが実行され、デプロイメントがワークロードを処理するのに十分なサイズにスケールアップされます。しかし、ほとんどの場合、トラフィックが急増すると集計されたリソース消費量に基づくオートスケールがトリガーされる前に、ロードバランサーのヘルスチェックが失敗します。Auto Scaling ルールは、コンテナデプロイメントをスケールアウトして対応する前に、少なくとも 1 分間の高い平均リソース使用率を監視する必要があります。ただし、過負荷のタスクでは、ロードバランサーのヘルスチェックがすぐに失敗する可能性があります。 大量のワークロードを処理しているためにタスクが正常でないシナリオでは、Amazon ECS の新しいタスク置換動作により、サービスの可用性と信頼性が大幅に向上します。Amazon ECS はヘルスチェックの失敗を検知し、Auto Scaling ルールがトリガーされる前に、入ってくるワークロードの急増に対応できるようにするための代替タスクを事前に並行起動します。Auto Scaling ルールがトリガーされると、代替タスクと元のタスクの両方が正常でサービスの現在の必要なタスク数を満たしていれば、両方のタスクを保持します。 結論 この投稿では、異常なタスクを処理するときの Amazon ECS の新しい動作について説明しました。ミッションクリティカルなアプリケーションに Amazon ECS を採用するお客様が増えるにつれ、私たちは常に困難で新しいオーケストレーション問題に大規模に取り組むことに喜びを感じています。この最新のタスク置換動作は、規模の大小を問わずお客様のニーズに応えられるように設計されています。これにより、アプリケーションの障害やトラフィックの急増などの不利な状況でも、コンテナのデプロイメントをオンラインかつ可用性の高い状態に保つことができます。 Amazon ECS の今後の追加機能の詳細や、独自の課題を作成して変更や新機能をリクエストするには、 Amazon ECS パブリックロードマップ をご覧ください。 Amazon ECS スケジューラーの動作の詳細については、公式ドキュメントの サービススケジューラーの概念 を参照してください。 本記事は A deep dive into Amazon ECS task health and task replacement (2023 年 11 月 3 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

この記事は Amazon EKS extended support for Kubernetes versions pricing (記事公開日: 2024 年 1 月 16 日) を翻訳したものです。 Introduction 2023 年 10 月 4 日、 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes バージョンに対する延長サポートの パブリックプレビューを発表 しました。これは Kubernetes のマイナーバージョンのサポート期間を 12 ヶ月延長します。そして本日、延長サポートの料金設定を発表します。延長サポート期間中の Kubernetes バージョンを実行している Amazon EKS クラスターは、クラスターあたり 0.60 USD / 1 hour の料金が発生します。この料金は 2024 年 4 月の請求サイクル (2024 年 4 月 1 日開始) から適用されます。標準サポート期間中の Kubernetes バージョンを実行しているクラスター料金の変更ありません。引き続き、クラスターあたり 0.10 USD / 1 hourの料金が適用されます。 この価格設定には、Kubernetes のコントロールプレーンを実行するためのコストが含まれています。別途、Kubernetes のワーカーノードを実行したり、その他のクラスター機能をサポートするために作成する AWS リソース (Amazon Elastic Compute Cloud [ Amazon EC2 ] インスタンス、 AWS Fargate 、Amazon Elastic Block Store [ Amazon EBS ] ボリューム、 AWS Outposts キャパシティなど) の料金も発生します。使用した分だけ支払う方式で、最低料金はなく、前払いのコミットメントもありません。 Amazon EKS では、Kubernetes バージョン 1.23 以降のバージョンに対して延長サポートが利用できます。各バージョンの標準サポート期間と拡張サポート期間は、Amazon EKS の リリースカレンダー を参照してください。 Kubernetes バージョンに対する Amazon EKS の延長サポートとは何ですか? Amazon EKS の延長サポートは、Kubernetes のマイナーバージョンが Amazon EKS で利用開始になった時点から最大 26 ヶ月間のサポートを提供します。Amazon EKS の延長サポート期間中のバージョンは、Amazon EKS が管理する Kubernetes コントロールプレーンの継続的なセキュリティパッチを受け取ります。さらに、Amazon EKS は Amazon VPC CNI、kube-proxy、CoreDNS アドオン、AWS が提供する Amazon EKS 最適化 Amazon Linux AMI、Bottlerocket、Amazon EKS 最適化 Windows AMI、Amazon EKS Fargate ノードの重要なパッチをリリースします。 (注: AWS が提供する Amazon EKS 最適化 Windows AMI のサポートは、Kubernetesバージョン 1.24 以降で利用できます)。 AWS は、標準サポートまたは延長サポート両方で提供されるすべての Amazon EKS バージョンを完全なテクニカルサポートでバックアップします。Kubernetes バージョンの延長サポートは、Amazon EKS が利用できるすべての AWS リージョン ( GovCloud (US) リージョン含む) で利用できます。 Amazon EKS バージョンはいつ標準サポートまたは延長サポートの対象になりますか? 標準サポートは Kuberenetes バージョンが Amazon EKS で利用可能になった時点から開始され、アップストリームの Kubernetes のマイナーバージョンサポート期間と同様に 14 ヶ月間継続します。Amazon EKS の延長サポートは、標準サポートが終了した直後から開始され、12 ヶ月間継続します。Kubernetes のバージョン 1.23 以降は、Amazon EKS の延長サポートの対象となります。 延長サポートにはどれくらいの費用がかかりますか? Amazon EKS クラスターの実行コストはコントロールプレーンの Kubernetes マイナーバージョンに基づいています。Amazon EKS クラスターで標準サポートの Kubernetes バージョンを実行している場合、クラスターあたり 0.10 USD / 1 hour の料金をお支払いいただきます。Amazon EKS クラスターで延長サポートの Kubernetes バージョンを実行している場合、クラスターあたり 0.60 USD / 1 hour の料金 をお支払いいただきます。 延長サポートの仕組みをわかりやすく説明するシナリオをいくつか紹介します Amazon EKS クラスターが大量にあり、それらが異なる Kubernetes バージョンが実行されている場合、標準サポートのバージョンを実行しているクラスターにはクラスターあたり 0.10 USD / 1 hour が請求され、延長サポートのバージョンを実行しているクラスターには、クラスターあたり 0.60 USD / 1 hour が請求されます。 延長サポート対象の Kubernetes バージョンを使用して新しい Amazon EKS クラスターを作成する場合、0.60 USD / 1 hour を支払うことになります。 延長サポートの Kubernetes バージョンを使用して Amazon EKS クラスターを実行していて、そのクラスターのコントロールプレーンを標準サポートの Kubernetes バージョンにアップグレードする場合、アップグレード前にクラスターが延長サポートバージョンを実行していた時間に対して 0.60 USD / 1 hour 、アップグレード後は 0.10 USD / 1 hour を支払うことになります。 標準サポート期間と延長サポート期間での Amazon EKS の請求を説明する例をいくつか示します。 例 1: Amazon EKS が Kubernetes の新しいバージョンをリリースしたその日に、そのバージョンの Amazon EKS クラスターを作成し、コントロールプレーンのバージョンをアップグレードせずにそのクラスターを 26 か月間実行するとします。バージョンが標準サポートの対象となる最初の 14 か月間は、 0.10 USD / 1 hour を支払うことになります。14 か月後、Kubernetes バージョンは延長サポートに移行します。これで、残りの 12 か月間は 0.60 USD / 1 hour を支払うことになります。26 か月間のこのクラスターの実行には、平均して 0.33 USD / 1 hour を支払うことになります。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 14 0.10 USD 延長サポート 12 0.60　USD 26 か月間のサポートの平均費用 0.33 USD   例 2: 標準サポート期間を 4 ヶ月経過した Kubernetes のバージョン (つまり、そのバージョンの標準サポート期間が残り 10 ヶ月) で Amazon EKS クラスターを作成したとします。このバージョンの標準サポートが終了し、次の標準サポートの対象となる次のバージョンにアップグレードする前に、6 か月間の延長サポートを利用することにしました。このクラスターを実行した 16 か月間は、最初の 10 か月は 0.10 USD / 1 hour、残りの 6 か月は 0.60 USD / 1 hour を支払います。このクラスターを 16 か月間実行するには、平均して 0.29 USD / 1 hour を支払うことになります。 (注: クラスターを標準サポートの Kubernetes バージョンにアップグレードすると、請求額はクラスターあたり 0.10 USD / 1 hour に戻ります)。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 10 0.10 USD 延長サポート 6 0.60　USD 16 か月間のサポートの平均費用 0.29 USD   例 3: 新しいバージョンをすぐに採用し、Amazon EKS クラスターの定期的なアップグレードサイクルに従うことで、14 か月の標準サポート期間を超えて Kubernetes バージョンを使用しないとします。この場合、現在の Amazon EKS の請求に変更はありません。クラスターには引き続き 0.10 USD / 1 hour をお支払いいただきます。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 14 0.10 USD 延長サポート 0 0.60　USD 14 か月間のサポートの平均費用 0.10 USD   次の表と図は、Amazon EKS で現在利用可能な Kubernetes バージョンのサポート終了日と料金をまとめたものです。 サポートタイプ 期間 料金 (クラスター 1 hour あたり) 標準サポート Amazon EKS で Kubernetes バージョンが利用可能になった日から 14 か月間 0.10 USD 延長サポート Amazon EKS の標準サポート終了日から 12 か月間 0.60 USD Kubernetes version 標準サポートの期間 延長サポートの期間 1.23 2022 年 8 月 – 2023 年 10 月 2023 年 10 月 – 2024 年 10 月 1.24 2022 年 11 月 – 2024 年 1 月 2024 年 1 月 – 2025 年 1 月 1.25 2023 年 2 月 – 2024 年 5 月 2024 年 5 月 – 2025 年 5 月 1.26 2023 年 4 月 – 2024 年 6 月 2024 年 6 月 – 2025 年 6 月 1.27 2023 年 5 月 – 2024 年 7 月 2024 年 7 月 – 2025 年 7 月 1.28 2023 年 9 月 – 2024 年 11 月 2024 年 11 月 – 2025 年 11 月 * 正確な日付については、Amazon EKS Kubernetes リリースカレンダー を参照してください。このカレンダーは定期的に更新されるので、正確かつ最終的なバージョンサポート日を知るには信頼できる情報源と考えてください。 Next Steps Kubernetes バージョンの延長サポートは、現在 Amazon EKS のすべてのお客様にプレビュー版として追加費用なしでご利用いただけます。2024 年 4 月の請求サイクル (2024 年 4 月 1 日から) から、延長サポート対象の Kubernetes バージョンで実行されている Amazon EKS クラスターには、クラスターあたり 0.60 USD / 1 hour が課金されます。クラスターはいつでも標準サポートのバージョンに アップグレード できることを忘れないでください。標準サポートの料金に変更はなく、クラスターあたり 0.10 USD / 1 hour のままです。Amazon EKS リリースカレンダー を使用して、バージョンサポートの最新の日付を確認してください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

この記事は、 Achieve high availability in Amazon OpenSearch Multi-AZ with Standby enabled domains: A deep dive into failovers を翻訳したものです。 Amazon OpenSearch Service は最近、 Multi-AZ with Standby を導入しました。これは重要なワークロードに対して、強化された可用性と一貫したパフォーマンスをビジネスに提供するために設計されたデプロイメントオプションです。この機能により、マネージドクラスターはゾーンのインフラストラクチャ障害に対する回復力を保ちながら、99.99% の可用性を実現できます。 この投稿では、Multi-AZ with Standby での検索とインデックスの仕組みと、その信頼性、シンプルさ、耐障害性をもたらす基盤メカニズムについて掘り下げます。 背景 Multi-AZ with Standby では、OpenSearch Service ドメインのインスタンスを 3 つのアベイラビリティーゾーンにまたがってデプロイします。そのうち 2 つのゾーンがアクティブ、1 つがスタンバイとして指定されます。この構成により、すべてのゾーンで同じキャパシティを維持することで、ゾーン障害が発生した場合でも一貫したパフォーマンスが確保されます。特に、このスタンバイゾーンは 静的に安定した設計 に従うため、障害時のキャパシティのプロビジョニングやデータ移動の必要がなくなります。 通常の運用中、アクティブゾーンは読み込みと書き込みのリクエストのためのコーディネータートラフィック、およびシャードクエリトラフィックを処理します。一方、スタンバイゾーンはレプリケーショントラフィックのみを受信します。 OpenSearch Service は、書き込みリクエストに同期レプリケーションプロトコルを利用します。 これにより、障害が発生した場合にスタンバイゾーンをアクティブな状態にすばやく昇格させることができます (フェイルオーバーまでの平均時間は 1 分以内)。これを ゾーンフェイルオーバー と呼びます。 以前にアクティブだったゾーンはスタンバイモードに降格され、正常な状態を回復するためのリカバリ操作が開始されます。 検索トラフィックのルーティングとフェイルオーバーによる高可用性の保証 OpenSearch Service ドメインにおいて、 コーディネータ とは、特にインデックス作成と検索リクエストを扱う HTTP(S) リクエストを処理するすべてのノードです。Multi-AZ with Standby を有効化したドメインでは、アクティブゾーンのデータノードが検索リクエストのコーディネータとして機能します。 検索リクエストのクエリの段階では、コーディネータはクエリ対象のシャードを決定し、そのシャードコピーをホストしているデータノードにリクエストを送信します。クエリは各シャードでローカルに実行され、マッチしたドキュメントがコーディネータノードに返されます。シャードコピーを含むノードにリクエストを送信する責務を持つコーディネータノードは、プロセスを 2 つのステップで実行します。 まず、シャードコピーにトラフィックが均一に分散されるように、シャードコピーをクエリするためにノードを問い合わせる順序を定義するイテレータを作成します。 その後、リクエストが関連するノードに送信されます。 シャードコピーのクエリ対象ノードの順序付きリストを作成するために、コーディネータノードはさまざまなアルゴリズムを使用します。 これらのアルゴリズムには、ラウンドロビン選択、適応型レプリカ選択、優先度ベースのシャードルーティング、 重み付きラウンドロビン が含まれます。 Multi-AZ with Standby の場合、シャードコピーの選択には重み付きラウンドロビンアルゴリズムが使用されます。このアプローチでは、アクティブゾーンには重み 1 が割り当てられ、スタンバイゾーンには重み 0 が割り当てられます。これにより、スタンバイアベイラビリティーゾーンのデータノードに読み取りトラフィックが送信されないことが保証されます。 重みはクラスター状態メタデータ内に JSON オブジェクトとして保存されます: "weighted_shard_routing": {     "awareness": {         "zone": {             "us-east-1b": 0,             "us-east-1d": 1,             "us-east-1c": 1          }      },      "_version": 3 } 次のスクリーンショットに示すように、 us-east-1b リージョンのゾーンステータスが StandBy となっており、このアベイラビリティーゾーン内のデータノードがスタンバイ状態であり、ロードバランサーからの検索やインデックス要求を受信していないことを示しています。 定常状態の運用を維持するために、スタンバイのアベイラビリティーゾーンは 30 分ごとにローテーションされ、すべてのネットワークパーツがアベイラビリティーゾーン全体でカバーされていることが保証されます。このプロアクティブなアプローチは、読み取りパスの可用性を検証し、潜在的な障害時のシステムの回復力をさらに強化します。次の図は、このアーキテクチャを示しています。 前の図では、Zone-C の重み付きラウンドロビンの重みが 0 に設定されています。これにより、スタンバイゾーンのデータノードがインデックス作成や検索トラフィックを受信しないことが保証されます。 コーディネータがシャードコピーのクエリをデータノードに対して行うとき、クエリを送信するノードの順序を決定するために、重み付きラウンドロビンの重みが使用されます。 スタンバイアベイラビリティーゾーンの重みが 0 であるため、コーディネータのリクエストは送信されません。 OpenSearch Service クラスターでは、次のスクリーンショットに示すように、アベイラビリティーゾーンのローテーションメトリクスを使用して、アクティブゾーンとスタンバイゾーンをいつでも確認できます。 ゾーン障害時には、スタンバイアベイラビリティーゾーンがシームレスにフェイルオープンモードに切り替わり、検索リクエストを処理します。 これは、アクティブなアベイラビリティーゾーンで正常なシャードコピーが利用できない場合、スタンバイを含むすべてのアベイラビリティーゾーンにシャードクエリのトラフィックがルーティングされることを意味します。 このフェイルオープンアプローチにより、障害時の検索リクエストが中断されることから保護され、サービスの連続性が確保されます。次の図は、このアーキテクチャを示しています。 前の図では、定常状態時に、シャードクエリのトラフィックは、アクティブなアベイラビリティゾーン (ゾーン A とゾーン B) のデータノードに送信されます。 ゾーン A のノード障害が発生すると、スタンバイのアベイラビリティゾーン (ゾーンC) がオープンになってシャードクエリのトラフィックを受け取るため、検索リクエストに影響はありません。 最終的に、ゾーン A が不健全と検出されると、読み込みフェイルオーバーがスタンバイをゾーン A に切り替えます。 フェイルオーバーが書き込み障害時に高可用性を確保する方法 OpenSearch Service のレプリケーションモデルは、プライマリバックアップモデルに従っており、ユーザーの書き込みリクエストを承認する前に、すべてのシャードコピーからの承認が必要となる同期的な性質を特徴としています。このレプリケーションモデルの顕著な短所の 1 つは、書き込みパスに何らかの障害が発生した場合の低速化に対する脆弱性です。これらのシステムは、アクティブなリーダーノードに依存して、障害や遅延を特定し、その情報をすべてのノードにブロードキャストします。これらの問題を検出するのにかかる時間 (平均検出時間) と、その後解決するのにかかる時間 (平均修復時間) が、システムが障害状態で動作する時間を大きく左右します。さらに、ゾーン間通信に影響を与えるネットワークイベントは、レプリケーションの同期的な性質のため、書き込みリクエストを大幅に阻害する可能性があります。 OpenSearch Service は、書き込みトラフィックをレプリケートし、メタデータの更新を調整するために、選出されたリーダーを通じて内部のノード間通信プロトコルを利用します。 したがって、ストレスを受けているゾーンをスタンバイにすることは、書き込み障害の問題に効果的に対処することにはなりません。 ゾーンの書き込みフェイルオーバー: ゾーン間レプリケーショントラフィックの遮断 Multi-AZ with Standby の場合、想定外のゾーン障害やネットワークイベントなどで発生する可能性のあるパフォーマンスの問題を軽減するために、ゾーン間の書き込みフェイルオーバーは効果的なアプローチです。このアプローチでは、影響を受けたゾーン内のノードをクラスターから正常に削除することで、ゾーン間の入出力トラフィックを効果的に遮断します。ゾーン間のレプリケーショントラフィックを遮断することで、ゾーン障害の影響を影響を受けたゾーン内に限定することができます。これにより、お客様により予測可能な体験を提供し、システムが信頼性高く稼働し続けることを確実にします。 グレースフルな書き込みフェイルオーバー OpenSearch Service 内の書き込みフェイルオーバーのオーケストレーションは、選出されたリーダーノードによって、明確に定義されたメカニズムを通じて実行されます。 このメカニズムには、クラスター状態の公開のためのコンセンサスプロトコルが含まれており、すべてのノードが一致して、常に 1 つのゾーンのみを廃止対象として指定することに同意します。 重要なことに、影響を受けたゾーンに関連するメタデータは、障害の発生時に完全な再起動があったとしても、その永続性を確保するために、すべてのノード間でレプリケートされます。 さらに、リーダーノードは I/O フェンシングを始める前に、まず影響を受けるゾーン内のノードを 5 分間スタンバイ状態に置くことで、スムーズで正常な移行を保証します。この意図的なアプローチにより、影響を受けたゾーン内のノードに新しいコーディネータトラフィックやシャードクエリトラフィックが向けられるのを防ぎます。これにより、これらのノードは進行中のタスクを正常に完了し、サービスから外される前に未処理のリクエストを徐々に処理できるようになります。次の図は、このアーキテクチャを示しています。 リーダーノードの書き込みフェイルオーバーを実装するプロセスで、OpenSearch Serviceは次の主要なステップに従います。 リーダーの譲位 – リーダーノードが書き込みフェイルオーバーがスケジュールされているゾーンに位置している場合、システムはリーダーノードが自発的にリーダーシップの役割から下りることを保証します。この譲位は管理された方法で実行され、プロセス全体が別の適格なノードに引き継がれ、必要なアクションを担当します。 廃止予定のリーダーの再選を防ぐ – 書き込みフェイルオーバーがマークされたゾーンからのリーダーの再選を防ぐために、適格なリーダーノードが書き込みフェイルオーバーアクションを開始すると、廃止予定のリーダーノードがさらなる選挙に参加しないようにする措置を講じます。これは、廃止予定のリーダーノードを投票設定から除外することによって実現され、クラスターの運用の重要なフェーズでの投票を効果的に防ぎます。 書き込みフェイルオーバーゾーンに関連するメタデータはクラスター状態内に保存されます。この情報は、分散された OpenSearch Service クラスター内のすべてのノードに次のように公開されます。 "decommissionedAttribute": {     "awareness": {         "zone": "us-east-1c"      },      "status": "successful",      "requestID": "FLoyf5v9RVSsaAquRNKxIw" } 次のスクリーンショットは、ゾーンでネットワークの低速化が発生した際、書き込みフェイルオーバーが可用性の回復に役立つことを示しています。 ゾーン回復後の書き込みフェイルオーバー ゾーンの再起動プロセスは、ゾーンの書き込みフェイルオーバー後のリカバリフェーズで重要な役割を果たします。 影響を受けたゾーンが復旧し、安定していると見なされた後、以前に廃止されたノードがクラスターに再参加します。 この再参加は通常、ゾーンが再起動されてから 2 分以内の時間枠で発生します。 これにより、ピアノードとの同期が可能になり、レプリカシャードのリカバリプロセスが開始されるため、クラスターは目的の状態に効果的に復元されます。 結論 OpenSearch Service は Multi-AZ with Standby の導入により、重要なワークロードの高可用性と一貫したパフォーマンスを実現するための強力なソリューションが企業に提供されます。このデプロイオプションを使用することで、企業はインフラストラクチャの回復力を強化し、クラスタの構成と管理を簡素化し、ベストプラクティスを適用できます。 重み付きラウンドロビンによるシャードコピー選択、プロアクティブなフェイルオーバーメカニズム、フェイルオープンなスタンバイアベイラビリティゾーンなどの機能により、OpenSearch Service の Multi-AZ with Standby は、要求の厳しいエンタープライズ環境において、信頼性が高く効率的な検索エクスペリエンスを実現します。 Multi-AZ with Standby の詳細については、 Amazon OpenSearch Service Under the Hood: Multi-AZ with Standby を参照してください。

ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。 そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、そのためにどの資料を確認した方がいいのかを役割別にまとめていきます。 本ブログは自治体においてガバクラ利用を検討されているお客様に向けた「自治体職員編」です。 そのほかの方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 (本ブログ) ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築補助者編』 ガバメントクラウドの道案内: 『 ASP ＆運用管理補助者編』 本ブログの構成 ここでは気にするべきポイントをステップに分けて紹介します。 AWS について学ぶ ガバクラで使用するネットワーク範囲を考える どの範囲までアプリケーションをガバメントクラウドに移行するか考える 「共同利用方式」か「単独利用方式」かを考える 各事業者の役割を理解する (単独利用方式の場合) 統合運用補助事業者を立てる必要があるか確認する ネットワーク接続方式を考える 費用の算出方法を考える それぞれの対応方法について概要と、どのように考えていくかをお伝えします。 (1) AWS について学ぶ ガバクラを利用するにあたり、もし AWS の利用をお考えであればまずは AWS でできることについて知る必要があります。 AWS では月に1回ウェビナーを開催し、AWS の概要から利用できるサービスの概要、想定される構成などガバメントクラウドでの利用に必要な内容についてご紹介しています。 ぜひ一度こちらをご覧いただき、AWS の理解を深めていただけると嬉しいです。 自治体向けオンライントレーニング 〜ガバメントクラウド（AWS編）対応版〜 直近の参加が難しい方はオンデマンド版もご用意しております。 お手数ですが担当営業にご連絡いただくか、本ブログ末尾のお問い合わせ窓口よりご連絡ください。 (2) ガバクラで使用するネットワーク範囲を考える ガバメントクラウドで AWS を利用する場合、AWS 上で使用する IP アドレス範囲はお客様側で自由に決定することが可能です。 (一部の共同利用方式では ASP と連携しながら IP アドレスを決める必要があります。後述します) 一方で、AWS とオンプレミス (庁舎など) は L3 レベルで接続されるため、AWS に割り当てる IP アドレスはオンプレミスで使用していない IP アドレスである必要があります。 そこで、ガバメントクラウドを利用するにあたってはオンプレミスで使用していない IP アドレス範囲を確認し、割り当てる必要があります。 AWS のネットワークの考え方についてより知識を深めたい方は [AWS Black Belt Online Seminar] Amazon VPC をご覧ください。 (3) どの範囲までアプリケーションをガバメントクラウドに移行するか考える 個人番号利用事務系に属する 20 業務がガバメントクラウドの移行対象となっていますが、関連システムについてもガバメントクラウドへ移行することが可能とされています。 AWS からオンプレミスへの通信と AWS 内部での通信では下図のように通信料金が異なりますため、データ連携が多く発生するシステムに関しては 20 業務以外のシステムでも AWS へ移行する方が費用が抑えられる場合があります。 ※上記費用は 2024 年 1 月現在のものです。また、通信に関わる費用は上記料金以外にもございます。詳しくは ネットワーク運用補助事業者の方向けのブログ および使用するサービスのドキュメントをご参照ください。 「20 業務のシステムとデータ連携がどの程度発生するか」を検討した上で 20 業務のシステム以外まで視野を含めてどのシステムをガバメントクラウド移行対象とするかを検討していく必要があります。 (4) 「共同利用方式」か「単独利用方式」かを考える ガバメントクラウドの利用方式は大きく分けて「共同利用方式」と「単独利用方式」の二つがあります。 共同利用方式 パッケージベンダーがアカウントを持った上でシステムを構築し、SaaS 形式で利用できるようにする方式 単独利用方式 自治体がアカウントを持った上で、そのアカウント上にシステムの構築を依頼して利用する方式 利用方式に応じて、自治体の責任範囲・自由度が異なりますため、ガバメントクラウド上で実現したい内容に合わせて適宜選択いただく必要があります。 また、パッケージによっては単独利用方式・共同利用方式のどちらかしか採用できない場合があります。 利用方式を決定する際にはパッケージベンダーとも会話しながら進めていくことが望ましいです。 以下にそれぞれの利用方式の参考となる比較表を記載します。 (5) 各事業者の役割を理解する ガバメントクラウドではパッケージベンダーの他に、運用補助事業者やネットワーク構築運用補助者など複数の事業者が紐づく形で構築されることが多いかと考えます。 各登場人物の役割分担については 以前公開したブログ にタスクリストのダウンロードに関する記載がありますので、こちらをご確認ください。 (6) (単独利用方式の場合) 統合運用補助事業者を立てる必要があるか確認する 採用した利用方式が単独利用方式の場合、かつマルチベンダー (マルチアカウント) でパッケージが構築される場合、複数のアカウントを跨ぐ形でメトリクスを取得しダッシュボードを作成するなど統合的に運用管理を行う事業者が必要となる場合があります。 単独利用方式の場合、これを実施する「統合運用管理補助者」を立てるかどうかを検討する必要があります。 統合運用補助者の役割および必要となると考えられる作業に関してはブログ「 ガバメントクラウドの道案内『統合運用管理補助者編』 」をご確認ください。 (7) ネットワーク接続方式を考える オンプレミスから AWS への接続に関しては専用線が必要となります。 専用線をどう利用するかに関してはいくつか検討できる方式があります。以下は一例です。 自治体が個別に専用線を契約する方式 自治体が回線業者と契約することで AWS まで専用線を敷設する方式 自治体が単独で契約するためスピード感を持って敷設することができ、専用線を占有することができる。 複数団体で専用線を共有する方式 現在複数自治体でデータセンターを共有していたり、情報ハイウェイ等自治体共有のネットワークがある場合、そこから専用線を伸ばして AWS へ接続する方式 複数の自治体でネットワークを共有するため、コストを按分することが可能となる LGWAN を利用する方式 次期 LGWAN ではガバメントクラウドへの接続サービスの提供が予定されているため、それを利用する方式 今後公開される詳細情報を確認しながら検討 以上の方式の中から、どの選択が実現可能か検討いただければと思います。 (8) 費用の算出方法を考える ガバメントクラウドでは費用に関しては各 CSP の計算ツールを利用することが求められています。 AWS では Pricing Calculator を用意しておりますため、これを使用していただくことが可能です。 Pricing Calculator の使い方についてはウェビナー「 Pricing Calculator ～見積の仕方と自治体のモデルケース～ 」をご覧ください。 上記ウェビナーでご確認いただける通り、Pricing Calculator を使用できるのはあくまで「AWS で稼働させるシステムが利用するサービス・スペックがわかっている場合」のみになります。 今回20業務のシステムに関してはパッケージベンダーが新規に構築する場合が多いかと思いますので、可能であればパッケージベンダーの方に問い合わせていただき、Calculator を使用した見積もりを共有いただくと現実に即した費用感が得られやすいかと考えます。 上記方法が難しそうであった場合、既存のリソース表を基に Pricing Calculator に入力いただく必要が出てきます まとめ 本ブログでは、自治体のお客様がガバメントクラウドを利用するにあたって検討すべきポイントをご紹介しました。 検討すべきポイントの整理と、検討すべきポイントがわかっていてもどの資料を見ると理解が深められるかわからなかった方に対するサポートがこのブログでできていれば嬉しいです。 自治体に所属している方、または関連するベンダー・パートナーの方でこのブログに関して追記した方がいい事項やご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

自治体のお客様において、現在ガバメントクラウドの利用検討が進んでいます。ガバメントクラウドを利用するうえでは、さまざまな事業者が分担して作業することが多いと思います。 例えば、「ネットワーク構築運用補助者」がネットワーク経路を整備し、「運用管理補助者」が運用管理を行う個別領域上に、「ASP」がシステムを構築します。それぞれの事業者の詳細な役割分担については、 こちらのブログ をご参照ください。 本ブログは自治体においてガバメントクラウド利用を検討されているお客様に向けた「ネットワーク構築運用補助者編」です。ネットワーク構築運用補助者がネットワーク構築や運用管理を行っていく上で、気にするべき点や、参考となる資料をまとめています。作業内容の確認等に、ご利用いただければと思います。 その他の方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築運用補助者編』(本ブログ) ガバメントクラウドの道案内: 『ASP＆運用管理補助者編』 また、本ブログは以下のような方を対象として記述しています。 ネットワーク構築運用補助者を担う事業者の方 ネットワーク構築運用補助者を立てることをご検討されており、詳細を知りたい自治体の方 本ブログの構成 ここからはネットワーク構築運用補助者について以下のような章立てでお話しします。 ネットワーク構築運用補助者の役割と担当する事業者について 地方公共団体からガバメントクラウドへの接続パターンについて ネットワークを集約する構成について まとめ 免責事項 ガバメントクラウドに関するお問い合わせ ネットワーク構築運用補助者の役割と担当する事業者について 多くの地方公共団体の基幹システムは、マルチベンダーで構成されており、ガバメントクラウド上ではマルチアカウント構成になることが多いと思います。 マルチベンダー・マルチアカウントの構成の場合には、AWS Transit Gateway の設置と運用を行うベンダーが必要です。すべての基幹システムが共同利用方式でも、ネットワークアカウント (ネットワーク構築運用補助者) は必要となると考えます。 ネットワーク構築運用補助者は、具体的には 自治体からガバメントクラウドへの接続 マルチベンダー環境 (マルチアカウント含む) 利用時における、 AWS Transit Gateway 等を用いた接続設定 Windows Server Update Services (WSUS) 等ガバメントクラウド向け・庁内環境向けのアップデート用サーバを置いた場合のインターネット接続設定 等を行う場合に必要となるかと考えます。 また、ネットワーク構築運用補助者がガバメントクラウド全体の運用管理補助業務を担う場合、ネットワーク構築運用補助者が運用管理補助業務を兼任することが想定されます。これは、ネットワーク構築運用補助者はもともとガバメントクラウド全体のネットワークを管理することが求められているため、セキュリティについての管理も兼任しやすいと考えています。その場合は、 こちらのブログ をご参照ください。 地方公共団体からガバメントクラウドへの接続パターンについて 地方公共団体とガバメントクラウドとの接続方法は、各拠点から敷設する専用回線及び閉域ネットワークの利用形態によって、主に 5 パターンが想定されます。各パターンの特徴や考慮事項を踏まえて、適した接続方法を下記またはそれ以外のパターンから検討する必要があります。 地方公共団体から専用線で接続する方法 各地方公共団体団体から個別に専用線・Direct Connect を敷設し、ガバメントクラウドへ接続する方法です。回線を共同利用する場合と比較して、回線費用の負担が大きくなる可能性があります。 ASP のデータセンタから専用線で接続する方法 既存の地域回線等を利用し、各地方公共団体からデータセンタへ専用線を集約する方法です。個別に接続する場合と比較して、回線費用の負担を抑えられる可能性があります。また団体間でIPアドレス帯が重複する場合は、トンネリング等の対応が必要となります。 都道府県 WAN を経由して接続する方法 地方公共団体において都道府県 WAN 事業者の回線を利用する方法です。個別に接続する場合と比較して、回線費用の負担を抑えられる可能性があります。また団体間で IP アドレス帯が重複する場合は、トンネリング等の対応が必要となります。 既に接続しているパブリッククラウドの接続回線で接続する方法 既設環境でパブリッククラウドに接続している場合、その回線を利用する方法です。アクセス回線の帯域について、新たに接続するクラウドサービスの通信等を再検討する必要があります。 LGWAN を経由して接続する方法 各地方公共団体から LGWAN を利用し、ガバメントクラウドへ接続する方法です。ガバメントクラウドに接続するためのクラウド接続サービスは LGWAN で構築予定のため、クラウド接続サービスに係る新規調達等が不要になりイニシャルコストを抑えられる可能性があります。 ネットワークを集約する構成について 上記の地方公共団体からガバメントクラウドへの接続パターンについて、2 や 3 の場合に回線を集約してガバメントクラウドへ接続を検討する事業者様もいらっしゃるかと存じます。以下がイメージです。 その際に、以下の項目が、ネットワークを検討する際に気になる点と考えます。各項目について参考となる情報をまとめています。 DNS の設計 IP アドレス範囲重複への対応 ネットワーク関連の費用 DNSの設計について 地方公共団体からガバメントクラウド環境のシステムの名前解決を行う場合に、Amazon Route 53 のインバウンドエンドポイントを地方公共団体の基幹ネットワークのオンプレミス DNS サーバに、フォワーダーとして設定することで名前解決することが可能です。Amazon Route 53 のインバウンドエンドポイントを使用しない場合は、Amazon (provided) DNS にフォワードする DNS サーバを別途構築する必要があります。AWS の Amazon Route 53 Resolver の知識を深めたい方は [AWS Black Belt Online Seminar] Amazon Route 53 Resolver をご覧ください。 また、Amazon Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化するソリューションは こちらのブログ をご参照ください。 IP アドレス範囲重複への対応 複数の地方公共団体から同一の閉域ネットワークに接続する際、各拠点の IP アドレス範囲は重複させることができず、もし重複する場合にはガバメントクラウドに接続するための対応が別途必要となります。 地方公共団体からガバメントクラウドへの接続を閉域ネットワーク共同利用で行う場合を例として、対応方法を以下に示します。 地方公共団体から本番アカウントの Transit Gateway まで、Site-to-Site VPN を利用して IPsec トンネルを構成して接続することで対応可能です。Private IP VPN を利用して IPsec トンネルを構成して接続します。技術詳細については、 こちらのブログ をご参照ください。また Transit Gateway Connect を利用して GRE over IPsec トンネルを構成して接続することで対応も可能です。 団体間で VPN Tunnel IP と Transit Gateway のルートテーブルを分けて管理することで、団体の庁舎の CIDR や 、宛先の VPC の CIDR が重複していても、ルーティングすることが可能となります。 詳しくは、毎月開催している自治体向けオンライントレーニングの ウェビナー (11：ガバメントクラウド利用におけるネットワーク構成例と作業内容の整理) でもご紹介しております。ぜひご確認ください。 ネットワーク関連の費用 ネットワークアカウントとアプリケーションアカウントにそれぞれどのようにネットワーク関連の費用がかかるのかを気にされている自治体や事業者の方が多くいらっしゃるかと存じます。 ネットワーク構成によって、以下の例をご参考にネットワーク関連の料金を整理いただければと思います。 (2024 年 1 月時点でのサービス内容及び価格に基づいたスライドや説明になっています。最新の情報は AWS公式ウェブサイト にてご確認ください。) ネットワークアカウント (図のアカウント A) AWS VPN の費用 サイト間 VPN 接続の従量課金費用 データ転送アウト費用 AWS Direct Connect の費用 接続ポート時間費用 ※契約形態に依る AWS Transit Gateway の費用 AWS Transit Gateway VPN アタッチメント費用 AWS Direct Connect アタッチメント費用 Direct Connect ゲートウェイ-AWS Transit Gateway データ処理費用 アプリケーションアカウント (図のアカウント B) AWS Direct Connect の費用 データ転送アウト費用 AWS Transit Gateway の費用 AWS Transit Gateway アタッチメント費用 TAWS Transit Gateway アタッチメント-AWS Transit Gateway データ処理費用 まとめ このブログではネットワーク構築運用補助者となる事業者の方向けに役割範囲や作業内容についてご説明いたしました。ガバメントクラウドではガバメントクラウド固有の事情や制約等が発生し、初めて触れる事業者の方には難しいものとなっているかと思います。そんな中、ネットワーク構築運用補助者の作業内容を理解し、複数のガバメントクラウド個別領域全体を安全に運用管理していくためにこのブログをお役立ていただけると大変嬉しく思います。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承の上、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

この記事は、 Amazon OpenSearch Service now supports 99.99% availability using Multi-AZ with Standby を翻訳したものです。 お客様は、ミッションクリティカルなアプリケーションや監視に Amazon OpenSearch Service を使用しています。しかし、OpenSearch Service自体が利用できない場合はどうなるのでしょうか? たとえば、E コマースの検索がダウンした場合、収益が失われます。アプリケーションをOpenSearch Serviceで監視している場合、利用できなくなると、アプリケーションの問題を検出、診断、修復する能力が低下します。これらのケースでは、収益の損失、顧客の不満、生産性の低下、あるいは組織の評判へのダメージを被る可能性があります。 OpenSearch Service は、 ベストプラクティス に従うことで 99.9% の可用性のSLAを提供します。しかし、それらのプラクティスを実践するのは複雑で、OpenSearch のデータ配置と管理に関する知識と経験が必要となります。また、OpenSearch Service が AWS のアベイラビリティゾーンやネットワーク、分散システム、OpenSearch の自己回復能力、回復方法とどのように相互作用するかについての理解も必要です。さらに、ノードが応答しなくなるなどの問題が発生した場合、OpenSearch Service は欠落したシャード (データ) を再作成することで回復しますが、これによりドメイン内で大量のデータ移動が発生する可能性があります。 このデータ移動はクラスターのリソース使用量を増加させ、パフォーマンスに影響を及ぼす可能性があります。 クラスターのサイズが適切でない場合、可用性が低下し、3 つのアベイラビリティーゾーンにプロビジョニングする目的を達成できなくなります。 AWS は OpenSearch Service の新しいデプロイメントオプションである Multi-AZ with Standby を発表しました。これにより、高頻度の監視、迅速な障害検出、障害からの迅速な回復などの重労働を軽減し、インフラ障害が発生した場合でもドメインの可用性とパフォーマンスを維持できるようになります。Multi-AZ with Standby を使用すると、ドメインは 99.99% の可用性と一貫したパフォーマンスを実現できます。 この記事では、この新しいオプションのメリットと、Multi-AZ with Standby で OpenSearch クラスターを設定する方法について説明します。 ソリューション概要 OpenSearch Service チームは、お客様のために数万のドメインを運用する中で得た経験を、Multi-AZ with Standby 機能に組み込みました。Multi-AZ with Standby を採用すると、OpenSearch Service は 3 つのアベイラビリティゾーンにまたがるクラスターを作成し、各アベイラビリティゾーンにはクラスター内のデータの完全なコピーが含まれます含めます。次に、OpenSearch Service は1つのアベイラビリティゾーンをスタンバイモードにし、すべてのクエリを他の 2 つのアベイラビリティゾーンにルーティングします。ハードウェア関連の障害を検出すると、OpenSearch Service は 1 分以内にスタンバイプールのノードをアクティブに昇格させます。Multi-AZ with Standby を使用すると、OpenSearch Service は失われたノードからデータを再分配または再作成する必要がありません。その結果、クラスターのパフォーマンスは影響を受けず、可用性が低下するリスクを排除します。 前提条件 Multi-AZ with Standby には、以下の前提条件が必要です : ドメインは OpenSearch 1.3 以上で実行する必要があります ドメインは 3 つのアベイラビリティゾーンにまたがってデプロイされる必要があります ドメインには 3 つ (または 3 の倍数) のデータノードが必要です 3 つの専用クラスターマネージャー (マスター) ノードを使用する必要があります ドメインと専用マスターノードのサイジングのガイダンスについては、 Amazon OpenSearch Service ドメインのサイジング を参照してください。 Multi-AZ with Standby を使用した OpenSearch クラスターの設定 Multi-AZ with Standby は、新しいドメインを作成するときにも、既存のドメインに追加するときにも使用できます。 AWS Management Console を使用して新しいドメインを作成する場合、新しい Easy create オプションまたは従来の Standard create オプションを選択することで、Multi-AZ with Standby を使用して作成できます。既存のドメインは、ドメイン設定を編集することで Multi-AZ with Standby を使用するように更新できます。 Easy create オプションは、名前が示すように、ほとんどの設定をベストプラクティスの選択肢にデフォルトすることで、ドメインの作成を容易にします (大部分は後から変更可能です) 。ドメインは最初から高可用に設定され、Multi-AZ with Standby としてデプロイされます。 データノードを選択する際は、各アベイラビリティゾーンに均等に分散されるように、3 つ (または 3 の倍数) のデータノードを選択する必要があります。OpenSearch Service コンソールの Data nodes テーブルは、アベイラビリティゾーンの 1 つがスタンバイになることを視覚的に表しています。 同様に、専用マスターノードを選択する際には、計画しているデータノード、インデックス、シャードの数を考慮して、インスタンスサイズを決定することをお勧めします。 ドメインが作成されたら、OpenSearch Service コンソールの Cluster configuration で、デプロイメントタイプを確認できます。以下のスクリーンショットを参照してください。 インデックスを作成する際は、コピー数 (プライマリとレプリカ) が 3 の倍数になるようにしてください。レプリカ数を指定しない場合、サービスはデフォルトで 2 を設定します。これは、各アベイラビリティゾーンにデータのコピーが少なくとも 1 つ存在することを保証するために重要です。ログワークロードの場合は、 index template などを使用することをお勧めします。 OpenSearch Service は、ノードとデータコピーを 3 つのアベイラビリティゾーンに均等に分散させます。通常の運用では、スタンバイノードは検索リクエストを受信しません。2 つのアクティブなアベイラビリティゾーンがすべての検索リクエストに応答します。ただし、データはこれらのスタンバイノードにレプリケートされるため、常に各アベイラビリティゾーンにデータの完全なコピーが存在することが保証されます。 インフラ障害イベントへの対応 OpenSearch Service は、ノード障害、ディスク障害、アベイラビリティゾーン障害などのイベントについてドメインを継続的に監視します。アベイラビリティゾーン障害などのインフラ障害が発生した場合、OpenSearch Service は影響を受けたアベイラビリティゾーンが回復する間、スタンバイノードをアクティブに昇格させます。影響を受けたアベイラビリティゾーンからのトラフィックは1分以内に転送されるため、影響 (がある場合) は実行中のリクエストに限定されます。 ドメインのステータス、アクティブおよびスタンバイのデータノードメトリクス、アベイラビリティゾーンのローテーションメトリクスは、 Cluster health タブで確認できます。以下のスクリーンショットは、Cluster health とデータノードのメトリクス ( CPU 利用率、JVM memory pressure 、ストレージなど) を示しています。 以下のスクリーンショットは、 AZ Rotation Metrics セクション ( Cluster health タブの下にあります) で、アベイラビリティゾーンの read と write のステータスを示しています。OpenSearch Service は、イベントに対応できるように準備ができていることを確認するために、30 分ごとにスタンバイのアベイラビリティゾーンをローテーションさせます。トラフィックに応答しているアベイラビリティゾーンは値が 1 で、スタンバイのアベイラビリティゾーンは値が 0 です。 考慮事項 この機能には、より高い可用性を提供し、パフォーマンスを維持するいくつかの改善とガードレールが実装されています。ノードあたりのシャード数、ドメインのシャード数、シャードのサイズに関する特定の静的な制限が適用されています。OpenSearch Service はデフォルトで Auto-Tune も有効にします。Multi-AZ with Standby は、最もコスト効果的で高パフォーマンスなストレージオプションである GP3 または SSD-backed インスタンスにストレージを制限します。さらに、不正なクエリを検出する高度なトラフィックシェイピングメカニズムを導入しており、これによりドメインの信頼性がさらに向上します。 高可用性とパフォーマンスを実現するために、お客様のワークロードに基づいてドメインインフラストラクチャのニーズを評価することをお勧めします。 まとめ Multi-AZ with Standby は、US West (N. California)、 AWS GovCloud (US-Gov-East, US-Gov-West) を除いた OpenSearch Service が利用できるすべてのAWSリージョンで利用できるようになりました。お試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS サポート窓口までフィードバックをお送りください。 翻訳は Solutions Architect 川岸が担当しました。

皆様の 2024 年のご多幸とご繁栄をお祈りします。 新年を迎えるにあたり、サプライチェーンマネジメントの私の 2024 年の予測を共有したいと思います。 サプライチェーンマネジメントの状況は前代未聞のペースで進化し続けています。 過去数年間、世界中のサプライチェーンの回復力と適応力を示されてきました。 かつてサプライチェーンマネジメントの要であった従来のアプローチは、今ではより統合され技術的に進歩したソリューションに道を譲っています。 このシフトは単なるトレンドではなく、気候変動、地政学的動向、マクロ経済問題、顧客行動の変化など、増え続ける課題に対処するために必要不可欠な進化です。 このブログでは、本年の主な予測を述べ、これらの変化がサプライチェーンマネジメントの未来をどう形作るかに焦点を置きます。 過去、サプライチェーンの問題は、PLM (製品ライフサイクル管理)、WMS (倉庫管理システム)、TMS (輸送管理システム)、OMS (注文管理システム) などの特化したスタンドアロンシステムを導入することで対処されてきました。 これらのシステムは、サプライチェーンの特定の問題を解決するのに効果的でしたが、エンドツーエンドの統合ソリューションを提供したり、大きな課題に効果的に適応したりする能力が不足していました。 2024 年の予測 このように考えると、過去五年間のサプライチェーンマネジメントでは 2 つの重要なトレンドがあったと思います。 第 1 に、組織は、機能横断的かつシステム的な問題に対処するデータファースト戦略をますます採用するようになっています。 このアプローチは、在庫の可視性を高め、在庫の不一致を減らし、消費者の信頼を育みながら、サプライチェーンの混乱に適応できるようにします。 第 2 に、サプライチェーンマネジメントのシンプル化へのトレンドが高まっており、組織は手動のデータ統合方法を機械学習 (ML) ベースのデータ連携に置き換えています。 これは、個別の問題解決から、統合され技術的に進歩したアプローチへの顕著なシフトを表しており、今日のグローバルサプライチェーンの課題の複雑さに対応しています。 これらのトレンドは、サプライチェーンマネジメントに影響を与え続けるでしょう。そして、次の重要な予測にもつながります。 生成系 AI が、意思決定を改善し加速するために、差別化につながらない重労働を解消する。 生成系 AI への関心が高まっていますが、 同時に効果的な展開、使用法、セキュリティ、倫理に多くの混乱が生じています。特にサプライチェーンマネジメントにおいては、多くの混乱があります。2024 年には、生成系 AI がサプライチェーンマネージャーにより良い洞察をもたらし、複雑なシナリオの結果や、サプライチェーン運用における複数の選択肢のトレードオフを発見するのをどのように支援するかについて、より詳細が明らかになっていくでしょう。 サプライチェーンマネジメントは、計算やトレンド分析を支援するために ML などのテクノロジーの採用はゆっくりでしたが、よりスマートで、効率的で、顧客中心のソリューションが必要なことが明確になるでしょう。意思決定を加速するためにデータの層を掘り下げて労働集約的なタスクを自動化することは、生成系 AI にとって理想的なユースケースです。 サプライチェーンリーダーは、複雑なシナリオ、トレードオフ、潜在的な結果に対処するために、会話形式で何、なぜ、もし~ならばと質問することができるようになるでしょう。 生成系 AI は、運用パフォーマンス、サステナビリティ指標、財務健全性の分析を自動化することによって、サプライヤーの監査、評価、選択、置き換えの業務を簡略化するでしょう。 ついにデータが関連付けられ、革新的なサプライチェーンマネジメント機能が利用可能になる。 貴重なサプライチェーンデータはまだデータサイロに分散しており、効果的に使用することが困難です。以前は、真のサプライチェーン可視化を実現するための技術は実装コストがかかりすぎていましたが、大規模言語モデルによるデータ取り込みと変換により、この参入障壁が下がっています。2024 年には、組織のモチベーションが高まり、複数のシステムに分散したデータをより簡単に統合モデルに変換できるようになるでしょう。組織はついに、サプライチェーンのデータを統合してサプライチェーンの意思決定を改善するための実用的、スケーラブル、費用対効果の高いアプローチを手に入れるでしょう。データが増えれば、組織はより良いインテリジェンスと可視性を得ることができます。データを 1 か所に置くことで、組織はついに効果的な生成系 AI 戦略を展開し、生成系 AI モデルから最適なパフォーマンスを引き出すことができます。 デジタルサプライチェーンは、不確実な世界に対する俊敏性を高めるだろう。 生成系 AI を活用したデジタルサプライチェーンは、サプライチェーンのさまざまな意思決定の影響を説明するシナリオのシミュレーションを可能にします。最近の環境、経済、地政学的な問題が示すように、不安定な状況はいつでも、どこでも起こり得ます。デジタルサプライチェーンを利用する組織は、こうした混乱がいつ発生したかに関わらず、回復力を高める可能性があります。 デジタルサプライチェーンは、組織が物理的なサプライチェーンの俊敏性と柔軟性を向上させるのに役立ちます。生成系 AI を使えば、さまざまな変数を用いて数十万ものシナリオを実行して結果を予測し、より正確なガイダンスを提供するでしょう。そうすれば、組織はサプライチェーン全体の効率性、有効性、即応性を最大化するように行動できます。このアプローチにより、組織はデジタルサプライチェーンを用いて正しい意思決定を行い、物理的なサプライチェーンを用いて、その知識に基づいて迅速かつ正確に行動できます。 結論 2024 年を通して、サプライチェーンマネジメントに先進的な技術、特に生成系 AI を統合していくことは、単なる競争上の優位性ではなく、必要不可欠なことになるでしょう。状況の変化にすばやく適応し、情報に基づいた意思決定を行い、運用の効率性を維持する能力が欠かせません。サプライチェーンマネジメントの未来は疑いなくデジタル化の道を進んでいきます。この変化を受け入れる者が、よりレジリエントで効率的、顧客中心のサプライチェーンを生み出す道を切り拓くリーダーとなるでしょう。待ち受ける課題とチャンスをつかむ準備をして、この未来に自信を持って踏み込んでいきましょう。明けましておめでとうございます! 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビジネスアプリケーションのビジョンの策定と実現を担当しています。彼と彼のチームは、サプライチェーンの機能を根本的に考え直し、世界で初めての継続的に改善するサプライチェーン管理システムを市場に提供することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等卒業生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースを修了しています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。 <!-- '"` -->

Amazon DynamoDB テーブルでプロビジョンドキャパシティを使用する場合、突然のリクエストトラフィックの増加 (スパイク) に対して、スロットルされることなく対処するための最善の方法を検討するのは課題の一つです。スロットルは、リクエストレートが設定された制限を超えたことを DynamoDB が検知した場合に発生するサービス応答です。たとえば、テーブルの書き込み容量ユニット (WCU) を 10,000 にプロビジョニングしており、トラフィックが 20,000 を消費するレートでアクセスされた場合、やがてスロットルが発生し、スロットルされたリクエストを処理するためリトライをする必要があります。 突発的かつ長時間続くトラフィックスパイクほど、テーブルにスロットルが発生する可能性が高まります。ただし、突発的なトラフィックに対して、スロットルの発生を避けることができないわけではありません。ここでは、トラフィックのスパイクに対処するための 8 つの設計と、それぞれの利点と欠点を紹介します： Auto Scaling とバーストキャパシティを利用する Auto Scaling のターゲット使用率を調整する オンデマンドモードに切り替える バックグラウンド処理をセルフスロットルする バックグラウンド処理をスロースタートする スパイクのタイミングを予測できる場合、Auto Scaling スケジュールを使用する スパイクのタイミングを予測できない場合、積極的に Auto Scaling の調整を使用する 戦略的に一定レベルのスロットルを許容する DynamoDB のスロットルに関する背景 DynamoDB において、読み取りおよび書き込みリクエストがスロットルされる状況は主に 2 つあります。第一に、テーブルへのリクエストレートがテーブルのプロビジョンドキャパシティを超えた場合。第二に、特定のパーティションへのリクエストレートがすべてのパーティションに存在するハードリミットを超えた場合。この投稿では、テーブルレベルのスロットルに焦点を当てています。これらは急激なトラフィックスパイクに最も関連する制限です。 テーブルおよびパーティションの制限について詳しく知りたい場合は、「 DynamoDB のスケーリング: パーティション、ホットキー、Split for heat がパフォーマンスに与える影響 (第 1 部: ローディング) 」を参照してください。 DynamoDB のプロビジョニングされたテーブルでは、プロビジョニングされたスループット容量を割り当てることでテーブルの読み取りおよび書き込みの能力を明示的に制御します。読み取りスループット ( 読み取りキャパシティユニット、または RCU で表される) および書き込みスループット ( 書き込みキャパシティユニット、または WCU で表される) を割り当てます。割り当てるほど、スロットルが発生するまでにテーブルまたはインデックスで実行できる読み取りまたは書き込み作業が増え、時間ごとのコストも上がります。 グローバルセカンダリインデックス ( GSI ) は、ベーステーブルとは異なるプロビジョニングされたスループット容量を持っています。それらの制限はテーブルと同じように機能します。この投稿の残りの部分では、「テーブル」という用語はテーブルとインデックスの両方を指すことがあります。 1. Auto Scaling とバーストキャパシティを利用する 通常、トラフィックは一日中変動します。プロビジョンドキャパシティテーブルでこれを処理するクラシックな方法は、Auto Scaling 機能をオンにすることです。Auto Scaling はテーブル上の消費されたキャパシティを監視し、その応答としてプロビジョンドキャパシティの増減を調整します。最小値 (これ以下にはならないように) 、最大値 (これ以上にはならないように) 、およびターゲット使用率 (プロビジョニングされた合計量に対して、消費されている量をこの割合に保つように試みる) を構成します。Auto Scaling は通常のエンドユーザートラフィックの変動や一時的なスパイクに対処するために調整されます。 Auto Scaling はターゲット使用率を超える 2 分間の消費キャパシティを観測すると、プロビジョンドキャパシティを上方に調整します。利用率がターゲット使用率ラインよりも 20 ％ (相対ではなく、2,000 ベーシスポイントとして) 低い状態を 15 分間観測すると、プロビジョンドキャパシティを下方に調整します。スケールアップはいつでも発生できますが、スケールダウンはより厳格なルールがあります。これは「 Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ 」で説明されています。 「1 日あたりの DynamoDB テーブルで実行できるプロビジョンドキャパシティーの減少数には、デフォルトのクォータがあります。日付は、協定世界時 (UTC) に従って定義されます。特定の日に、その日に他の減少をまだ実行していない限り、1 時間以内に最大 4 回の減少を実行することから始めることができます。その後、前の 1 時間に減少がない限り、1 時間あたり 1 回追加で減少を実行できます。これにより、1 日で減らすことができる最大の回数は 27 回になります (1 日の中で最初の 1 時間は 4 回、その後は 1 時間ごとに 1 回)。」 「テーブルとグローバルセカンダリインデックスの減少制限は別々に設定されているため、特定のテーブルのグローバルセカンダリインデックスにはいずれも、独自の減少制限が設定されています。」 Auto Scaling は Amazon CloudWatch を使用して消費キャパシティを観測します。CloudWatch メトリクスは即座ではなく、2 分以上の遅延があります。これは Auto Scaling が DynamoDB テーブルを監視する際に、常に少し過去を見ていることを意味します。Auto Scaling はプロビジョニングされた量を変更するために必要なデータが揃うまでに最短 4 分かかります。 Auto Scaling のターゲット使用率は、この時間ウィンドウ内でのトラフィックスパイクに対応するための余裕を提供します。テーブルが 70,000 WCU を消費している場合、70 ％のターゲット使用率を持つ Auto Scaling は 100,000 WCU をプロビジョニングします。追加の 30,000 WCU は、Auto Scaling がより高い量をプロビジョニングできるようになるまでのトラフィックスパイクを処理する余裕 (パディング) です。これにより、最も極端なトラフィックスパイクを除いて、スロットルが発生することはありません。 パディングを超えるスパイクが発生する場合、DynamoDB はバーストキャパシティを提供し、テーブルが一時的にプロビジョニングされたレベルを超えることを許可します。詳細は「 DynamoDB のスケーリング: パーティション、ホットキー、Split for heat がパフォーマンスに与える影響 (第 2 部: クエリの実行) 」を参照してください。バーストキャパシティは常に有効です。 図 1 は典型的な Auto Scaling の動作を示しています。ゆらぎのあるオレンジの線は一日中にわたる 300,000 WCU から 650,000 WCU までの書き込みトラフィックの消費を示しています。水平の青い線は Auto Scaling によって制御されるプロビジョニングされた書き込み容量です。必要に応じて上下に動きます。 図 1 : Auto Scaling の動作 – ゆらぎのあるオレンジの線は書き込みの消費を示し、水平の青い線はプロビジョンドキャパシティです 真夜中直後 (グラフの 3/4 の位置) を注意深く見ると、スロットリングの影響が見られます。オレンジの消費線は 375,000 WCU から 640,000 WCU に急激にジャンプし、520,000 WCU に設定された青いプロビジョンドキャパシティラインをはるかに超えました。この一時的な超過は、バーストキャパシティによって許可されました。スパイクが続き、数分後にはバーストキャパシティが使い果たされたため、オレンジ色の消費ラインがプロビジョニングされたラインまで下がり、Auto Scaling によってプロビジョニングされた青色のラインが上方に引き上げられ、消費が回復するまでの約 1 分かかりました。 (黒い矢印はこの出来事を指しています) 。 図 2 は、4,000 WCU から 18,000 WCU にユーザーロードを急激に増加させ、スロットルを生成するように設計された、1 時間のシンセティックテストを示しています。このシンセティックテストには、本当のユーザー負荷のようなランダムなジッタが含まれていますが、すべて人工的に生成されたものです。そのため、さまざまな動作を微調整して結果をテストすることができます。 この最初のテストのテーブルは、70 ％ のターゲット使用率で Auto Scaling が有効になっています。上側の図には、結果として得られた消費キャパシティ (変動している青い線) とプロビジョンドキャパシティ (四角い赤い線) が表示されています。下側の図には、同じ時間枠内のテーブルのスロットル数が表示されています。スパイクは急で、スロットルを引き起こすのに十分な長さがあります。 注：赤い線は、Auto Scaling イベントログで説明されているとおり、分単位のスケーリング活動を正確に示すために手書きされています。CloudWatch はプロビジョンドキャパシティの情報を分単位では受け取りません。 図 2 : シンセティックテスト – テーブルが 70 ％のターゲット使用率で構成され、トラフィックが 4,000 WCU から18,000 WCU に急増する状況を示しています このテストは、最初に 4,000WCU から 5,000 WCU を消費する比較的平らなトラフィックから始まります。Auto Scaling により、プロビジョンドキャパシティは約 7,500 WCU に維持されます。トラフィックの単純な変動はパディングによって処理されます。そして、13:07 に書き込みトラフィックが急激に 18,000 WCU にジャンプします。最初はスロットリングは発生しません。バーストキャパシティが余剰の使用を許可します。しかし、13:11 にはバーストキャパシティが尽き、書き込みレートはプロビジョニングされた量に下がり、他のすべてのリクエストはスロットリングされます。スロットリングは 13:13 まで続き、その後、Auto Scaling によってプロビジョンドキャパシティは 26,000 WCU まで増加します。これは、スパイクに対処するのに十分な量であり、別のスパイクがあった場合に備えたパディングも行われます。最終的に、スパイクが収束してから約 15 分後に、Auto Scaling はプロビジョニングされた量を元に戻します。 この投稿の残りの部分では、デフォルトの Auto Scaling では処理できない、非常に急激で持続的な読み取りまたは書き込みトラフィックの増加のシナリオを含むアクセスパターンを持つテーブルがある場合の設計について検討します。 2. Auto Scaling のターゲット使用率を調整する 考慮すべき調整の一つは、Auto Scaling のターゲット使用率を低く設定することです。これは、予測できない時間にエンドユーザーのトラフィックが予想外に発生し、スロットルを回避して低いレイテンシを維持したい場合に効果的です。 Auto Scaling のターゲット使用率は、テーブルがスパイクを処理するために手元に保持するパディングの量を制御します。これは 20 ％から 90 ％までの範囲で設定できます。低い値はより多くのパディングを意味します。例えば、ターゲットが 40 ％の場合、現在のトラフィックレベルの 1.5 倍をパディングに割り当てます。つまり、10,000 WCU をアクティブに消費しているテーブルは、40 ％のターゲットを達成するために 25,000 WCU をプロビジョニングします。低いターゲット使用率には 3 つの利点があります。 スパイクを処理するためにより多くのパディングが提供される。 スパイクがプロビジョニングされたレベルを超える場合、バーストキャパシティの許容が増加する。なぜなら、バーストキャパシティの許容はプロビジョニングされた量に比例しているためです。 Auto Scaling をより迅速に立ち上げることができます。Auto Scaling は、消費されたキャパシティがどれだけターゲット使用率を超えて増加したかを見て、どれだけ増やすかを決定します。スロットルの数は考慮しません。より多くのパディングがあると、予期せぬスパイクのうちの大部分が検知され、それを使用して大きなジャンプを計算できます。パディングがほとんどない場合、スパイクはより抑制されて見え (容量を消費する代わりにスロットルが発生するため) 、Auto Scaling はより小さなステップで進みます。 デメリットはコストの増加です。プロビジョニングされた量に基づいて料金が発生するため、より多くのパディングはより多くのコストを意味します。また、Auto Scaling がトラフィックのスパイクに応じてプロビジョンドキャパシティを上方に調整するたびに、再び下方に調整するまでに一定時間がかかる可能性があります。その期間中には追加のコストがかかります。スロットルとコストのバランスを見て、適切なターゲット使用率を選択します。 Auto Scaling のターゲット使用率を調整する場合は、ベーステーブルだけでなく、GSI (グローバルセカンダリインデックス) も考慮することを忘れないでください。 図 3 は、以前と同じトラフィックパターンを再現していますが、今回はターゲット使用率を 60 ％に設定しています。スロットリングは発生しません。 図 3 : シンセティックテスト – テーブルが 60 ％のターゲット使用率で構成され、トラフィックが 4,000 WCU から 18,000 WCU に急増する状況を示しています。今回はスロットルが発生していません。 低いターゲット使用率はより多くのパディングを提供しました。テストの最初の 10 分間では、Auto Scaling は前回のテストとは異なり、7,500 WCU ではなく 9,000 WCU に近くプロビジョニングしました。18,000 WCU への急激なジャンプは 14:28 に発生し、14:35 には Auto Scaling がプロビジョニングされた量を上方に調整しました。図 2 と同じくらいの大きなスパイクが発生しても、低いターゲット使用率のテーブルでは一切スロットルが発生しませんでした。 ここで低いターゲット使用率が提供した 2 つの利点は次の通りです。まず第一に、余分なパディングがあったため、スパイク中に必要なバーストキャパシティが少なかったことです。第二に、スパイク前に高いプロビジョニング量を確保しておくことで、消費できるバーストキャパシティがより多くなっていました。この組み合わせにより、このシナリオでは一切スロットルが発生しませんでした。 3. オンデマンドモードに切り替える スロットルの回避が最優先の場合に考慮すべき有用なデザインの一つは、テーブルを オンデマンドモード に変更することです。 オンデマンドでは、価格は完全に消費量に基づいています。各リクエストにはわずかな料金が発生します。秒ごとに一定量の RCU および WCU を割り当てて時間単位で支払うのではなく、リクエストごとに読み取りリクエストユニット (RRU) または書き込みリクエストユニット (WRU) を消費します。オンデマンドではプロビジョニングはなく、自動スケールアップやスケールダウンも必要ありません。急増するワークロードや予測不可能なワークロードに最適です。 オンデマンドテーブルは、突然のトラフィックスパイクに対するスロットリングの発生確率を大幅に減少させます。オンデマンドテーブルは、2 つの理由でのみスロットリングします。まず第一に、パーティションの制限を超えた場合 (プロビジョニングモードと同じ) 。第二に、テーブルへのトラフィックがアカウントのテーブルレベルの読み取りまたは書き込みスループット制限を超える場合です。これらはデフォルトで 40,000 のガードレールに設定されていますが、これをより高く設定することは可能で、より高く設定しても追加料金は発生しません。 図 4 は、同じトラフィックパターンを再現していますが、今回はオンデマンドモードのテーブルです。プロビジョニングされた値はありません (赤い線はありません) し、テーブルレベルのスロットルもありません。 図 4 : オンデマンドモードはトラフィックの急激な増加に対して即座に反応するため、スロットリングが発生しません テーブルをオンディマンドに設定して、そのまま使うことができます。プロビジョニング、ターゲット使用率、スケールアップまたはスケールダウンについて考える必要はありません。テーブルはプロビジョニングモードとオンデマンドモードの間で自由に切り替えることができます。テーブルは 24 時間ごとにオンデマンドモードに切り替えることができます。また、テーブルはいつでもプロビジョニングモードに戻すことができます。テーブルをオンデマンドモードに変更して、1 日のうちスパイクが予想される時間に使用し、他の滑らかなトラフィック時間帯に対してはプロビジョニングモードに変更すると便利かもしれません。 オンデマンドテーブルはプロビジョニングテーブルよりも高価であるという一般的な誤解があります。時にはそうであり、時にはそうではありません。比較的平坦なトラフィックの場合、コストの面でプロビジョニングモードが優れています。ワークロードにトラフィックスパイク (急激な上昇と下降) が多いほど、オンデマンドモードの方がコスト優位になります。十分なスパイクがあれば、オンデマンドモードがより低コストの選択肢になる可能性があります。なぜなら、オンデマンドモードはすべてのパディングに関連する追加のコストを回避し、スパイク後のダウンサイジングの待ち時間がないからです。 数学的には、プロビジョニングされたテーブルの達成利用率が 15 ％未満の場合、オンデマンドモードはより低コストな選択肢になります。達成された使用率は、消費されたキャパシティの合計を、その月のプロビジョンドキャパシティの合計で割ったものとして計算されます。ダウンサイジングの遅れのため、ターゲット使用率よりも低くなります。 4. バックグラウンド処理をセルフスロットルする トラフィックの急増が、ある程度制御できるバックグラウンド処理によって引き起こされている場合は、バックグラウンド処理をセルフスロットルさせるという別のオプションを検討する必要があります。基本的には、バックグラウンド処理の消費レートを制限させることで、エンドユーザーのトラフィックと過度に競合しないようにし、必要な Auto Scaling の増加を抑制します。 大幅なスパイクは、背後で何らかのバックグラウンドアクティビティが行われることが原因となることがよくあります。新しいデータセットのロード、日次アイテムのリフレッシュ、履歴データの選択的な削除、または分析のためにテーブルをスキャンするなどの状況では、バックグラウンド処理がどのように振る舞うかを制御できるかもしれません。 バックグラウンド処理がセルフスロットルのレートで実行されるようにします。通常の Auto Scaling のパディングに簡単に収まるようなレートを選択します。このようにすると、開始時にはスロットリングを引き起こさず (ホットパーティションがないと仮定) 、Auto Scaling はテーブルに必要なパディングを復元するために上方に調整できます。もし外部のパーティーがスパイキートラフィックを駆動させている場合は、アプリケーションアクセスポイントで各外部パーティをレートリミットできるかどうかを検討してください。 バルク処理は、各リクエストで ReturnConsumedCapacity を要求し、1 秒あたりどれだけの容量を消費しているかを追跡することで、セルフスロットルできます。消費量が高すぎる場合は、処理を遅くすることができます。複数の別々のクライアントプロセスを使用している場合、クライアントごとに一定の最大容量消費率を許可することができます。 次の図は、セルフスロットルのバルク処理がスパイクのサイズを制限し、スロットリングを回避する様子を示しています。テーブルは再び図 2 と同じく 70 ％のターゲット使用率を持っていますが、今回はバルク処理タスクが少し遅く、少し長く実行されるようになっているため、リクエスト率はわずか 14,000 WCU にしか上昇していません。 図 5 : 18,000 WCU ではなく 14,000 WCU にジャンプすることで、スロットリングが回避されます 14,000 WCU への小さなスパイクは、スパイク中に消費されるバーストキャパシティが少なくなり、テーブルがスロットリングする前に Auto Scaling が上向きに調整するための時間を与えます。 このセルフスロットルのアプローチは、バックグラウンド処理が穏やかなペースで実行されることが許容される場合に機能します。その場合、これには Auto Scaling が上方に調整する量を制限するという追加の利点があります。バックグラウンド処理が 10 分間で一定の 4,000 WCU または 5 分間で 8,000 WCU を消費する場合を想像してみてください。オンデマンドテーブルではこれら 2 つのオプションは同じ価格です。ただし、Auto Scaling を使用するプロビジョニングテーブルでは、より穏やかなジョブはより小さな Auto Scaling の増加を引き起こします。Auto Scaling の減少を 1 時間待たなければならない場合、それははるかに低いプロビジョニングキャパシティでの 1 時間です。ここでのテスト結果では、ピークのプロビジョニングが 20,000 WCU であることがわかります。これは元のテストの 26,000 WCU からの減少です。 このアプローチはスパイクをプラトーに変え、Auto Scaling を使用したプラトーは通常より低いコストになります。 5. バックグラウンド処理をスロースタートさせる できるだけ早く完了させたいバックグラウンド処理があり、エンドユーザーのトラフィックに影響を与えるスロットルの発生リスクを避けたい場合は、バックグラウンド処理をスロースタートさせることができます。 スロースタートは、前述のようにワークがセルフスロットルすることを必要としますが、最初は緩やかに始め、数分ごとにリクエスト率を増加させます。この緩やかな開始の挙動により、Auto Scaling は需要の増加に対応するための時間を確保できます。スポーツと同様に、何かを壊さないように最初にウォームアップすることが望ましいのです。 この前のオプションと比較して、これは潜在的なコスト削減を提供しませんが、テーブルレベルのスロットリングとエンドユーザートラフィックとの競合のリスクを制限し、 (ウォームアップ後には) 任意に高速なリクエスト率 (構成された Auto Scalingの最大値およびアカウントレベルおよびテーブルレベルの制限のみによる制限) を可能にします。 以下の図は、スロースタートが Auto Scaling のパディング内に収まり、スロットリングを回避するだけでなく、容量を増やす必要性について Auto Scaling にシグナルを送ることができた様子を示しています。 図 6 : バックグラウンド処理のスロースタートにより、Auto Scaling が適応する時間が確保されます 22:49 から 23:00 の間に、トラフィックは 4,000 から 9,000、次に 14,000、最後に 18,000 へと段階的に増加しました。このスロースタートにより、Auto Scaling はバーストキャパシティが消耗される前に独自の増加を行うための十分な時間がありました。テストは元のテストと同じ 18,000 WCU のレートに達し、同じ 70 ％のターゲット使用率ですが、スロースタートを始めることですべてのスロットリングを回避しました。 6. スパイクのタイミングを予測できる場合は、Auto Scaling スケジュールを使用する スパイクがあり、それが予測可能な場合 (たとえば、毎日午前 5 時に大量のロードを実行するか、毎朝午前 9 時にエンドユーザーリクエストが存在しない状態から急激に増加する場合など) 、 スケジュールされたスケーリング を使用できます。 スケジュールされたスケーリングでは、テーブルの最小値と最大値を日時に応じて異なる値に設定できます。 スケジュールされたアクション を制御するために crontab の表現力を最大限に活用できます。 たとえば、スパイクが来ることがわかっており、それがどのくらいの量かも知っている場合、スパイクを処理できるように Auto Scaling の最小値を大きくすることで、テーブルのプロビジョンドキャパシティを増やすことができます。スパイクが始まると最小値を下げることができます。最小値を下げることはプロビジョンドキャパシティを下げるわけではありません。実際の消費が減少するのを確認した時に、Auto Scaling がそれを下げるだけです。 次の図はトラフィックのスパイクがそのレートにジャンプする 2 分前に、Auto Scaling の最小値を 18,000 WCU に調整するというスケジュールされたアクションを示しています。 図 7 : 予測可能なスパイクの前に積極的にスケールアップした場合 この積極的な Auto Scaling の最小値の調整により、いかなるスロットリングも回避されました。18,000 への最初の上昇はスケジュールされたアクションでした。33,000 への 2 回目の上昇は、実際のトラフィックに対応し、必要なパディングを追加するための Auto Scaling の反応でした。 7. スパイクのタイミングを予測できない場合は、積極的に Auto Scaling の調整を要求する 正確なスパイクのタイミングを予測することはできないが、それが始まりそうなタイミングを検知することができる場合は、積極的に Auto Scaling の調整をリクエストすることができます。 たとえば、朝に大量のバルク処理があることを知っているが、具体的な時刻はわからないという場合を考えます。この場合、バルク処理が始まるときに、特定のキャパシティの引き上げをプロアクティブに要求することができます。あるキャパシティ量を要求するために「準備しろ、今行くぞ」というコールをして、遅延を発生させずにテーブルを調整するイメージです。 実際には、テーブルのプロビジョンドキャパシティを上方に調整するのは非常に速いです。通常、1 分未満で行われます。唯一の注意点は、テーブルのプロビジョニングされた制限を、以前に設定された制限よりも高く上げる場合です。このように新しいハイウォーターマークを設定すると、テーブルはその容量を大きくする必要があり、この増強には時間がかかることがあります。この増強が迅速に達成できるようにするためのベストプラクティスは、テーブルとインデックスを一度、最大の読み取りおよび書き込みレベルでプロビジョニングし、その後再びダウンスケーリングする前に、本番で必要な最大のレベルに設定することです。これにより、後のキャパシティ引き上げを迅速に行うことができます。これをテーブル作成時に行うことができる場合は、それが最速の方法となります。 では、Auto Scaling テーブルのプロビジョンドキャパシティを積極的に増やす方法について説明します。テーブルを直接更新すると、Auto Scaling は変更を認知せず、独自の Auto Scaling アクションで変更を元に戻す可能性があります。より信頼性の高い手法は、Auto Scaling の最小値を新しいプロビジョンドキャパシティとして設定することです。これにより、Auto Scaling はプロビジョンドキャパシティを増やし、また、その発生を認識します。 キャパシティの各リクエスタはコーディネーターにアクセスし、テーブルまたは GSI に一定量の追加キャパシティを要求し、それが届くのを待ってから、遅延なく、かつテーブルレベルのスロットリングを引き起こすことなく開始するべきです。 コーディネーターは各リクエストを受け取り、現在のトラフィックを調査し、要求されたキャパシティを追加し、新しい Auto Scaling の最小値を割り当てます。数分後、バルクワーカーのアクティビティがバルク処理の終了までプロビジョニングレベルを高い要求値に保つことを信頼して、最小値を元の値に戻すことができます。ダウンスケールのタイミングを注意深く計る必要はありません。テーブルを素早くアップスケールするだけです。 最終的な結果は、図 7 と同じように見え、同じように振る舞いますが、事前にタイミングを知る必要がないという違いがあります。 8. 戦略的に一定のスロットリングを許可する 最後に考慮すべきデザインは、アプリケーションデザインでスロットリングを戦略的に許可することです。確実に低いレイテンシであることが厳密な要件でない場合はこれを検討してみてください。一部のスロットリングを受け入れることは、コスト効果が高い選択肢となり得ます。 スロットリングは致命的ではありません。また、データベースに損傷を与えることはありません。単にレイテンシを増加させるだけです。 例えば、エンドユーザートラフィックがないテーブルに対してバルク処理を実行している場合、バルク処理がテーブルの最大容量と同じかそれ以上で実行されることで、途中でいくつかのスロットリングが発生するのがちょうどいいかもしれません。スロットルをなくすために容量を上げた場合よりも負荷は少し長くかかりますが、コストは一定になり、すべてのキャパシティが使用されるため、パディングやその他の考慮は必要ありません。 ただし、テーブルにエンドユーザートラフィックが同時に存在する場合、このようなバルク処理を実行すると、エンドユーザーが彼らの書き込みでスロットリングに遭う可能性があり、これはエンドユーザーに認知されるレイテンシを増加させ、問題になるかもしれません。戦略的にスロットリングを許可する選択肢は、クライアントが低レイテンシを必要としない場合に最も適しています。 デフォルトでは、SDK による呼び出しはスロットリングの応答を検知した場合、リクエストを再試行します。これは SDK 自身が行うため、クライアントはスロットリングが発生していることに気付かないことがよくあります。リクエストは数回再試行され、成功すると、クライアントにとっては成功した (通常よりも高いレイテンシのある) リクエストのように見えます。SDK が実行可能なリトライカウントを超えるまで失敗した場合にのみ、プロビジョニングされたスループットが超過した例外が発生します。この例外が表示された場合は、例外をキャッチして (まだ作業が必要な場合は) リクエストを再試行する必要があります。最終的には、リクエストは成功します。テーブルが 10,000 RCU でプロビジョニングされている場合、ミリ秒ごとにリクエスト処理に利用可能な RCU は 10 増加します。 スロットリングイベントは CloudWatch に ReadThrottleEvents 、 WriteThrottleEvents 、 ThrottledRequests として表示されます。スロットルされたクライアントの数が少ない場合、クライアントが成功する前に一連の迅速な自動再試行を実行すると、大量のスロットリングイベントが生成される可能性があります。このため、正確なカウントよりもスロットリングイベントの大まかで相対的な大小に焦点を当てるべきです。また、スロットリングはテーブルレベルで発生する可能性がありますが、ホットパーティションがある場合はパーティションレベルでも発生する可能性があります。CloudWatch メトリクスはこの 2 つを区別しませんが、 CloudWatch Contributor Insights はこのデバッグに役立ちます。 まとめ Auto Scaling とバーストキャパシティは、大規模なトラフィックの急激で持続的な増加に対処できますが、急激で持続的な増加ほど、テーブルでスロットリングが発生する可能性が高くなります。 Auto Scaling のターゲット使用率を下げることで、トラフィックの増加に対する余裕を増やすことも、テーブルをオンデマンドモードに切り替えて、設定して忘れるという選択をすることもできます。 サージがバックグラウンド処理によって引き起こされる場合 (大規模で持続的なサージの場合がよくあります) 、バックグラウンド処理をセルフスロットルして消費量を低く抑えるか、または Auto Scaling が適応するのに十分な時間をかけて徐々に開始するようにすることができます。 サージのタイミングを事前に知っている場合は、Auto Scaling の変更をスケジュールして、スループットの最小値をサージを処理するのに十分な値に上げることができます。事前にサージのタイミングがわからない場合でも、開始の瞬間を特定できる場合は、Auto Scaling の増加を積極的にリクエストすることができます。 最後に、低レイテンシが必要ではない場合は、戦略的に一定のスロットリングを許可することを検討できます。 変更を行う際は、関連する GSI の設定も調整することを忘れないでください。 コメントや質問がある場合は、コメントセクションにコメントを残してください。 AWS Database Blog で Jason Hunter によって書かれた DynamoDB の投稿 やその他の投稿を見つけることができます。 (本記事は 2023/09/20 に投稿された Handle traffic spikes with Amazon DynamoDB provisioned capacity を翻訳した記事です。翻訳は Solutions Architect の嶋田朱里が担当しました。) 著者について Jason Hunter は Amazon DynamoDB に特化したカリフォルニア拠点の Principal Solutions Architect です。彼は 2003 年から NoSQL データベースに携わっています。また、Java、オープンソース、およびXML への貢献で知られています。 &nbsp; &nbsp; Puneet Rawal は AWS データベースに特化したシカゴ拠点の Sr Solutions Architect です。彼は 20 年以上の経験を持ち、大規模なデータベースシステムの設計と管理に従事しています。

1月16日、 AWS Supply Chain 用の 3 つの新しいモジュールがリリースされました。これらのモジュールは、サプライチェーンの各サイトで最適な在庫レベルを維持することを目的として、サプライチェーンのすべての階層にわたるサプライヤーとの連携を支援するために設計されています。概要を以下に示します。 Supply Planning – このモジュールは、原材料、部品、完成品の購入を正確に予測して計画するのに役立ちます。複数のアルゴリズムを使用して、発注書と在庫移動要件を含む供給計画を作成します。 N-Tier Visibility – このモジュールは、エンタープライズの内部システムを越えて、可視性とコラボレーションを取引パートナーの複数の外部階層にまで拡大します。 Sustainability – このモジュールは、二酸化炭素排出量に関するデータに加えて、商品の取得、製造、輸送、廃棄に使用された有害物質に関するレポートをリクエスト、収集、確認するためのより安全で効率的な方法を提供します。取引パートナーの複数の階層へのデータリクエストの送信、回答の追跡、欠席者へのリマインダーの送信、回答を保存および表示するための中央のリポジトリの提供が可能になりました。 各機能を見ていきましょう。 Supply Planning AWS Supply Chain には、独自の機械学習アルゴリズムを使用して需要を予測し、2 年以上前の過去の注文品目データに基づいて需要計画を生成する Demand Planning モジュールが既に含まれています。予測は、流通センターや小売店を始めとして、詳細で具体的です。 新しい Supply Planning モジュールは、需要計画を入力として使用します。既存の在庫を調べ、不確実性を考慮して、在庫戦略を含む追加のビジネス入力をサポートします。最終的に、コンポーネントと原材料のレビューと承認用の発注書が生成されます。Supply Planning モジュールのメインページを以下に示します。 このモジュールは、自動補充と製造計画もサポートしています。製造計画は、複数の直接および間接的な上流供給元から調達された個々のコンポーネントに分解 (展開) された部品表 (BoM) から逆算して進められます。 供給計画は、計画範囲と計画スケジュールに基づいて行われます。計画範囲と計画スケジュールは、どちらも組織プロファイルで定義されます。 このモジュールの設定では、発注書のレビューと承認をカスタマイズすることもできます。 N-Tier Visibility このモジュールは、直接のベンダー、ベンダーに供給するベンダーなどと連携して作業するのに役立ちます。ベンダーが自動的に検出され、 AWS Supply Chain へのオンボーディングがセットアップされます。このモジュールは、発注書に関する手動および EDI によるコラボレーションをサポートする一方で、不一致やリスクを特定し、必要に応じて代替ベンダーを見つけるのにも役立ちます。 モジュールのメインページには、取引パートナーの概要が表示されます。 ポータルのステータス 列には、既にオンボーディングされているパートナー、招待済みのパートナー (および招待の有効期限が切れているパートナー)、まだ招待されていないパートナーが表示されます。 [Invite partners] をクリックして招待を延長できます。パートナー (通常、Supply Chain データレイクのデータを使用して自動的に検出) を選択し、 [Continue] をクリックします。 次に、選択した各パートナーの連絡先情報を入力し、 [Send invites] をクリックします。 連絡先は E メールで招待状を受け取り、招待を承認できます。招待を承認したパートナーは、供給計画と発注書を (E メールまたは EDI 経由で) 電子的に受け取って対応できます。 Sustainability Sustainability モジュールは、パートナーからのコンプライアンスおよびサステナビリティデータを要求、受信、レビューするために役立ちます。これは、既に説明したパートナーネットワークに基づいて構築されており、データのリクエストを追跡します。 データをリクエストするには、必要なデータのタイプとデータが必要なパートナーを選択し、 [Continue] をクリックします。 次に、期日など、リクエストを定義する詳細を入力します。選択したパートナーにテキストメッセージでの応答やファイルでの応答を依頼できます。 各パートナーから提供された回答とファイルは Supply Chain データレイクに書き込まれ、 Amazon Simple Storage Service (Amazon S3) バケットにエクスポートすることもできます。 AWS Supply Chain のリソース AWS Supply Chain を初めて使用する際に詳細が必要な場合は、使用開始に役立つリソースが用意されています。 AWS Supply Chain – ホームページ。 AWS Supply Chain の一般提供が開始されました — 可視性の向上と実用的なインサイトによるリスクの軽減とコストの削減 – ブログ投稿。 AWS Supply Chain が上流における新機能を発表します – ブログ投稿。 AWS Supply Chain によるライフサイクルの異なる製品の需要計画の改善 – ブログ投稿。 AWS Supply Chain: Helping Woodside Energy optimize their supply chain – 動画。 – Jeff ; 原文は こちら です。

新年の始まりである 1 月に何か新しいことを学ぼうという抱負を持った方も多いと思います。何か新しいことを学び、無料の Amazon Web Services (AWS) 学習バッジ を取得することを考えている場合は、新しい Events and Workflows ラーニングパス をチェックしてみてください。 このラーニングパスでは、 AWS Step Functions 、 Amazon EventBridge 、イベント駆動型アーキテクチャ、サーバーレスについて理解すべきことをすべて学習できます。ラーニングパスの終了時には評価を受けることができます。評価に合格すると、 Credly から提供される AWS 学習バッジを履歴書やソーシャルメディアのプロフィールで共有できます。 1月8日週のリリース 1月8日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon Route 53 – Route 53 Resolver DNS Firewall を有効にして、DNS クエリ形式の質問セクションに含まれるクエリタイプに基づいて DNS トラフィックをフィルタリング できるようになりました。さらに、 Route 53 は、DNS レコードの追加のルーティングポリシーとして地理的近接性ルーティングをサポート するようになりました。リソースへのトラフィックのルーティングを行う地理的領域を拡大または縮小するには、レコードのバイアス値を変更します。これは、応答性の高いデジタルエクスペリエンスを提供する必要がある業界にとって非常に役立ちます。 Amazon CloudWatch Logs – CloudWatch Logs がアカウントレベルのサブスクリプションフィルターの作成をサポートするようになりました。 この機能を使用すると、アカウントのすべてのロググループを Amazon OpenSearch Service や Amazon Kinesis Data Firehose などのその他のサービスに転送することができます。 Amazon Elastic Container Service (Amazon ECS) – Amazon ECS が Amazon Elastic Block Store (Amazon EBS) と統合した結果、EBS ボリュームをプロビジョニングして、 AWS Fargate および Amazon Elastic Cloud Compute (Amazon EC2) の両方で実行する Amazon ECS タスクにアタッチできるようになりました。この機能が実際に使用されている様子を紹介する Channy のブログ記事 を参照してください。 Amazon EventBridge – EventBridge が EventBridge バスのターゲットとして AWS AppSync をサポートするようになりました。 .これにより、バックエンドアプリケーションからフロントエンドクライアントにリアルタイムの更新をストリーミングすることが可能になります。例えば、バックエンドで注文ステータスが変化したときに、行った注文からモバイルアプリケーションで通知を受け取ることができます。 Amazon SageMaker – SageMaker が機械学習 (ML) インターフェイス向けに M7i、C7i、および R7i インスタンスをサポートするようになりました 。これらのインスタンスは、カスタムの第 4 世代 Intel Xeon スケーラブルプロセッサを搭載し、前の世代のプロセッサよりも最大 15% 優れた価格パフォーマンスを実現しています。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性がある、その他の更新情報とニュースです。 1月15日週、 サーバーレス愛好家 の方向けに、 AWS Compute ブログ で、 2023 年の最終四半期のサーバーレス ICYMI の四半期ごとのまとめが公開されました (見逃した場合のため) 。この投稿は、10 月、11 月、12 月に行われた発表に加えて、その期間に AWS デベロッパーアドボケートが作成したすべての関連コンテンツをまとめたものです。このブログ投稿に加えて、AWS re:Invent 2023 で公開された新しいデモアプリケーション ServerlessVideo についても学ぶことができます。 1月15日週は、お客様が直面する一般的な課題を解決する方法を説明する非常に興味深いいくつかのブログ記事もありました。1 つ目は、 Amazon Cognito ユーザープールのアクセストークンをカスタマイズする方法 を説明する AWS Security ブログのブログ投稿です。2 つ目は、 Amazon DynamoDB を使用してデータを効果的にソートする方法 を説明する AWS Database ブログの記事です。 AWS の公式ポッドキャスト &nbsp;– 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースニュースレター &nbsp;– 私の同僚である Ricardo &nbsp;が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 トルコのお客様 については、2024 年 1 月 1 日、AWS Turkey Pazarlama Teknoloji ve Danışmanlık Hizmetleri Limited Şirketi (AWS Turkey) が AWS EMEA SARL (AWS Europe) からトルコのお客様向けの 契約当事者 およびサービスプロバイダーの業務を引き継ぎました。これにより、トルコの AWS のお客様は、現地通貨 (トルコリラ) と現地の銀行との取引が可能になります。AWS Turkey の詳細については、 よくある質問ページ を参照してください。 AWS の今後のイベント 今年の初めは、今後 2 か月間に世界中で開催される AWS re:Invent の要約シーズンです。 要約ページ をチェックして、最寄りのイベントを見つけることができます。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの 開発者向けイベント のすべてを閲覧できます。 1月15日週はここまでです。次週再びアクセスして、新たな Week in Review をぜひお読みください! –&nbsp; Marcia この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。