はじめに 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 からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

大企業や中小企業を問わず、多くの組織がアマゾン ウェブ サービス(AWS)上で分析ワークロードの移行と近代化に取り組んでいます。AWS への移行にはさまざまな理由がありますが、主な理由の 1 つは、インフラストラクチャのメンテナンス、パッチ適用、モニタリング、バックアップなどに時間を費やす代わりに、フルマネージドサービスを利用できることです。リーダーシップと開発チームは、現在のインフラストラクチャのメンテナンスではなく、現在のソリューションの最適化や新しいユースケースの実験などにより多くの時間を費やすことができます。 AWSを利用することでスピードを上げられる一方で、スケール拡大に伴い受信および処理データに対して責任を持つ必要性が生じます。これらの責任には、データプライバシー法および規制を順守すること、個人を特定できる情報 (PII) や上流のソースからの保護された健康情報 (PHI) などの機密データを非公開のまま保存することが含まれます。 この投稿では、データプライバシーの懸念に対処するために大量の開発時間を費やす必要なく、組織のデータプラットフォームをスケールし続けることができる方法を示す、ハイレベルなアーキテクチャと具体的なユースケースについて説明します。個人を特定できる情報 (PII) データを Amazon OpenSearch Service にロードする前に、 AWS Glue を使用して検出、マスキング、編集を行います。 ソリューションの概要 次の図は、高レベルのソリューションアーキテクチャを示しています。 設計のすべてのレイヤーとコンポーネントは、 AWS Well-Architected Framework Data Analytics Lens に沿って定義されています。アーキテクチャは、次のコンポーネントで構成されています。 ソースデータ データは、データベース、ファイル転送、ログ、SaaS(Software as a Service) アプリケーションなど、数十から数百のソースから送られてくる可能性があります。組織は、これらのチャネルを通じて流れ込んできたデータや、ダウンストリームのストレージやアプリケーションに入ったデータを常にコントロールできているとは限りません。 取り込み: データレイクのバッチ、マイクロバッチ、ストリーミング 多くの組織では、バッチ、マイクロバッチ、ストリーミングジョブなど、さまざまな方法でソースデータをデータレイクに取り込んでいます。 例えば、 Amazon EMR 、 AWS Glue 、 AWS Database Migration Service (AWS DMS) は、 Amazon Simple Storage Service (Amazon S3) 上のデータレイクにシンクするバッチおよび/またはストリーミング操作を実行するために使用できます。 Amazon AppFlow は、さまざまな SaaS アプリケーションからデータレイクにデータを転送するために使用できます。 AWS DataSync と AWS Transfer Family は、さまざまなプロトコルを介してデータレイクへのファイルの移動を支援できます。 Amazon Kinesis と Amazon MSK にも、Amazon S3 上のデータレイクに直接データをストリーミングする機能があります。 S3 データレイク データレイクに Amazon S3 を使用することは、モダンなデータ戦略に沿っています。Amazon S3 は、パフォーマンス、信頼性、可用性を犠牲にすることなく、低コストのストレージを提供します。 このアプローチでは、必要に応じてコンピューティングリソースをデータに紐づけ、実行に必要な容量分のみを支払うことができます。このアーキテクチャでは、機密データを含む可能性のある様々なソース(内部および外部)から生データが来ることがあります。 AWS Glue Crawler を使用することで、データを発見およびカタログ化できます。これによりテーブルスキーマが構築され、最終的には AWS Glue ETL と PII 変換を用いたデータレイク内の機密データ検出、マスクおよび編集が容易になります。 ビジネスコンテキストとデータセット アプローチの価値を示してみましょう。あなたは金融サービス機関のデータエンジニアリングチームのメンバーであるとします。要件は機密データを検出し、組織のクラウド環境に取り込まれる際にマスキングすることです。このデータはダウンストリームの分析プロセスで利用されます。将来的には、内部銀行システムから収集したデータストリームに基づいて、過去の支払い取引を安全に検索できるようになります。運用チーム、顧客、インターフェースアプリケーションからの検索結果は、機密フィールドについてはマスキングする必要があります。 次の表は、このソリューションで使用されるデータ構造を示しています。明確化のために、生の列名を整理された列名にマッピングしています。このスキーマ内の複数のフィールド(名、姓、社会保障番号(SSN)、住所、クレジットカード番号、電話番号、Eメール、IPv4アドレスなど)が機密データと見なされることに注意してください。 生データの列名 修正後の列名 型 c0 first_name 文字列 c1 last_name 文字列 c2 ssn 文字列 c3 address 文字列 c4 postcode 文字列 c5 country 文字列 c6 purchase_site 文字列 c7 credit_card_number 文字列 c8 credit_card_provider 文字列 c9 currency 文字列 c10 purchase_value 整数 c11 transaction_date 日付 c12 phone_number 文字列 c13 email 文字列 c14 ipv4 文字列 ユースケース: OpenSearch Service への読み込み前の個人情報バッチ検出 このアーキテクチャを実装しているお客様は、さまざまな分析を大規模に実行するために、Amazon S3 上にデータレイクを構築しています。このソリューションは、OpenSearch Service へのリアルタイム取り込みが不要で、スケジュールで実行される、またはイベントによってトリガーされるデータインテグレーションツールを使用することを計画しているお客様に適しています。 Amazon S3 にデータレコードが到着する前に、データレイクにすべてのデータストリームを信頼できる形で安全に取り込むための取り込みレイヤーを実装します。 Kinesis Data Streams は、構造化および半構造化データストリームの高速な取り込みのための取り込みレイヤーとして導入されます。これらの例としては、リレーショナルデータベースの変更、アプリケーション、システムログ、クリックストリームなどがあります。変更データキャプチャ (CDC) ユースケースの場合、Kinesis Data Streams を AWS DMS のターゲットとして使用できます。機密データを含むストリームを生成するアプリケーションやシステムは、Amazon Kinesis Agent、AWS SDK for Java、Kinesis Producer ライブラリのいずれかの 3 つのサポートされている方法を介して Kinesis Data Streams に送信されます。最後のステップとして、 Amazon Kinesis Data Firehose がリアルタイムに近いバッチデータを高い信頼性で S3 データレイクのデスティネーションにロードするのに役立ちます。 次のスクリーンショットは、 データビューア を介してKinesis Data Streams を通過するデータフローと、raw S3 プレフィックスに着地するサンプルデータの取得方法を示しています。このアーキテクチャでは、 データレイクの基礎 で推奨されている S3 プレフィックスのデータライフサイクルに従いました。 次のスクリーンショットの最初のレコードの詳細からわかるように、JSON ペイロードは前のセクションと同じスキーマに従っています。 Kinesis データストリームに流れ込む改変されていないデータが見えます。これは後の段階で改変されます。 データが Kinesis Data Streams に収集・取り込まれ、Kinesis Data Firehose を使用して S3 バケットに配信された後は、アーキテクチャの処理レイヤーが引き継ぎます。 パイプラインでの機密データの検出とマスキングを自動化するために、AWS Glue PII transform を使用します。 次のワークフロー図に示すように、AWS Glue Studio で変換ジョブを実装するために、コード不要の視覚的 ETL アプローチを採用しました。 まず、 pii_data_db データベースから raw のソース Data Catalog テーブルにアクセスします。このテーブルは、前のセクションで提示されたスキーマ構造を持っています。処理済みの raw データを追跡するために、 ジョブブックマーク を使用しました。 AWS Glue Studio のビジュアル ETL ジョブで AWS Glue DataBrew レシピ を使用して、2つの日付属性を OpenSearch で期待される フォーマット と互換性のある形式に変換します。これにより、完全なノーコード体験が実現できます。 Detect PIIアクションを使用して、機密性の高いカラムを特定します。AWS Glue には、選択したパターン、検出閾値、データセットの行のサンプル部分に基づいてこれを判断させます。この例では、アメリカ合衆国 (SSN など)に特に適用されるパターンを使用しましたが、他の国の機密データは検出されない場合があります。 使用例に適用できる利用可能なカテゴリと場所を確認するか、AWS Glue の正規表現 (regex) を使用して、他の国の機密データの検出エンティティを作成できます。 AWS Glue が提供する適切なサンプリング方法を選択することが重要です。この例では、ストリームから入ってくるデータにはすべての行に機密データが含まれていることがわかっているため、データセット内のすべての行を 100% サンプリングする必要はありません。下流のソースに機密データを一切許可したくない場合は、選択したパターンのデータを 100% サンプリングするか、データセット全体をスキャンして個々のセルに対処し、すべての機密データが検出されるようにすることを検討してください。サンプリングから得られるメリットは、スキャンする必要のあるデータ量が減るため、コストが削減されることです。 Detect PII アクションを使用すると、機密データをマスキングする際にデフォルトの文字列を選択できます。この例では、******** という文字列を使用しています。 apply mapping オペレーションを使用して、 ingestion_year 、 ingestion_month 、 ingestion_day などの不要なカラムの名前変更や削除を行います。 このステップでは、あるカラム ( purchase_value ) のデータ型を文字列から整数に変更することもできます。 この時点から、ジョブは OpenSearch Service とAmazon S3 の2つの出力先に分割されます。OpenSearch Service のプロビジョニングされたクラスターは、 Glue 用の組み込み OpenSearch コネクタ を介して接続されています。書き込み先の OpenSearch インデックスを指定し、コネクタが資格情報、ドメイン、ポート設定を処理します。下のスクリーンショットでは、指定されたインデックス index_os_pii に書き込んでいます。 マスクされたデータセットは、キュレーションされた S3 プレフィックスに格納します。 そこでは、特定のユースケースに対して正規化され、データサイエンティストによる安全な利用やアドホックなレポートのニーズに対応できるようにデータが用意されています。 統一的なガバナンス、アクセスコントロール、監査証跡をすべてのデータセットと Data Catalog テーブルに適用するには、 AWS Lake Formation を使用できます。これにより、AWS Glue Data Catalog テーブルと基礎となるデータへのアクセスを、必要なアクセス許可を付与されたユーザーとロールに限定できます。バッチジョブが正常に実行された後、OpenSearch Service を使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。 バッチジョブが正常に実行された後、OpenSearch Serviceを使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。 操作データから、前のスクリーンショットのように、クレジットカードプロバイダー別の1日当たりの取引数などのトレンドを特定できます。また、ユーザーが購入を行う場所とドメインも判断できます。 transaction_date 属性により、時間の経過とともにこれらのトレンドを確認できます。次のスクリーンショットは、取引情報が適切に編集されたレコードを示しています。 Amazon OpenSearch にデータをロードする他の方法については、 Amazon OpenSearch Service へのストリーミングデータをロードする を参照してください。さらに、機密データは他の AWS ソリューションを使用して発見およびマスキングすることもできます。 たとえば、 Amazon Macie を使用して S3 バケット内の機密データを検出し、次に Amazon Comprehend を使用して検出された機密データを編集することができます。詳細については、 AWSサービスを使用した PHI および PII データの検出の一般的な手法 を参照してください。 まとめ この投稿では、環境内の機密データを扱うことの重要性と、組織のスケールを速くする一方でコンプライアンスを維持するためのさまざまな方法とアーキテクチャについて説明しました。これで、データを検出、マスク、編集してAmazon OpenSearch Service にロードする方法がよく理解できるはずです。 著者について Michael Hamilton は、AWS 上でのエンタープライズ顧客の分析ワークロードの現代化と簡素化を支援する上級ソリューションアーキテクトです。仕事以外の時間では、マウンテンバイクに乗ったり、妻と3人の子どもたちと過ごすのが楽しみです。 Daniel Rozo は、オランダの顧客を支援する AWS のシニアソリューションアーキテクトです。 彼の情熱は、シンプルなデータとアナリティクスのソリューションのエンジニアリングと、顧客が現代のデータアーキテクチャに移行するのを助けることです。 仕事の外では、テニスをしたり自転車に乗ったりしています。 本投稿はソリューションアーキテクトの榎本が翻訳いたしました。原文は こちら です。

AWS Step Functions は、完全マネージドのビジュアルワークフローサービスで、 AWS Glue 、 Amazon EMR 、 Amazon Redshift などのさまざまな抽出・変換・読み込み (Extract, Transform, Load; ETL) テクノロジーを含む複雑なデータ処理パイプラインを構築できます。個々のデータパイプラインタスクを繋ぎ、ペイロード、リトライ、エラー処理を最小限のコードで構成することで、ワークフローを視覚的に構築できます。 Step Functions は、データパイプライン内のタスクが一時的なエラーで失敗した場合、自動リトライとエラー処理をサポートしていますが、アクセス許可の誤り、無効なデータ、パイプライン実行中のビジネスロジックの失敗など、回復不可能な失敗が発生する可能性があります。これにより、ステップで発生した問題を特定し、問題を修正してワークフローを再起動する必要があります。従来は、失敗したステップを再実行するには、ワークフロー全体を初めからやり直す必要がありました。これにより、特に複雑な長時間実行の ETL パイプラインの場合、ワークフローの完了が遅れていました。パイプラインに最初から実行するための状態遷移回数が増加するため、Map, Parallel ステートを使用する多数のステップがある場合、コストも増加します。 Step Functions では、失敗、中止、タイムアウトしたステートからワークフローを再実行できるようになりました 。これにより、ワークフローをより速く、低コストで完了させ、ビジネス価値の提供にさらに時間を費やすことができます。後続の問題が解決した後、失敗したステートに提供された同じ入力を使用して、失敗したワークフロー実行を再実行することで、取り扱われなかった失敗からより早く回復できるようになりました。 この投稿では、Step Functions の Distributed Map ステート を使用して、 Amazon Relational Database Service (Amazon RDS) のテーブルからデータをエクスポートする ETL パイプラインジョブをご紹介します。その後、障害をシミュレートし、新しい失敗したステートから再実行する機能を使用して、障害が発生したタスクを障害発生地点から再起動する方法をデモンストレーションします。 ソリューションの概要 データパイプラインに含まれる一般的な機能の 1 つに、複数のデータソースからデータを抽出し、データレイクにエクスポートしたり、別のデータベースにデータを同期したりすることがあります。 Step Functions の Distributed Map ステートを使用することで、このようなエクスポートや同期のジョブを最大 10,000 の並列度で実行できます。Distributed Map は、 Amazon Simple Storage Service (Amazon S3) から数何百万のオブジェクト、または単一の S3 オブジェクトから数百万レコードを読み込み、それらのレコードを後続のステップに配信することができます。 Step Functions は、Distributed Map 内のステップを、最大 10,000 の並列度で子ワークフローとして実行します。 10,000 の並列度は、AWS Glue のような他の多くの AWS サービスがサポートする並列度を大きく上回っています。AWS Glue は、ジョブごとに最大 1,000 のジョブ実行という制限 (ソフトリミット) があります。 このサンプルデータパイプラインは、 Amazon DynamoDB から商品カタログデータ、 Amazon RDS for PostgreSQL データベースから顧客注文データをソースとしています。データはその後前処理され、変換され、さらなる処理のために Amazon S3 にアップロードされます。データパイプラインは、RDS データベースの Data Catalog を作成するために、 AWS Glue クローラー で開始されます。AWS Glue クローラーの起動が非同期であるため、パイプラインにはクローラーの完了をチェックする待ちループがあります。AWS Glue クローラーの完了後、パイプラインは DynamoDB テーブルと RDS テーブルからデータを抽出します。これら 2 つのステップは独立しているため、並列ステップとして実行されます。1 つは、 AWS Lambda 関数を使用して、DynamoDB から S3 バケットにデータを出力、変換、ロードするものです。もう 1 つは、 AWS Glue ジョブ同期インテグレーション を使用した Distributed Map で、RDS テーブルから S3 バケットに同様の処理を行います。 AWS Identity and Access Management (IAM) アクセス許可が、Step Functions から AWS Glue ジョブを呼び出すために必要であることに注意してください。詳細は、 Step Functions から AWS Glue ジョブを呼び出すための IAM ポリシー を参照してください。 次の図は、Step Functions のワークフローを示しています。 RDS データベースには、顧客と注文データに関連する複数のテーブルがあります。Amazon S3 は、すべてのテーブルのメタデータを .csv ファイルとしてホストしています。このパイプラインは、Step Functions の Distributed Map を使用して、Amazon S3 からテーブルメタデータを読み取り、すべてのアイテムを反復処理し、後続の AWS Glue ジョブを並列で呼び出してデータをエクスポートします。次のコードを参照してください: "States": { "Map": { "Type": "Map", "ItemProcessor": { "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" }, "StartAt": "Export data for a table", "States": { "Export data for a table": { "Type": "Task", "Resource": "arn:aws:states:::glue:startJobRun.sync", "Parameters": { "JobName": "ExportTableData", "Arguments": { "--dbtable.$": "$.tables" } }, "End": true } } }, "Label": "Map", "ItemReader": { "Resource": "arn:aws:states:::s3:getObject", "ReaderConfig": { "InputType": "CSV", "CSVHeaderLocation": "FIRST_ROW" }, "Parameters": { "Bucket": "123456789012-stepfunction-redrive", "Key": "tables.csv" } }, "ResultPath": null, "End": true } } 前提条件 ソリューションをデプロイするには、次の前提条件が必要です: AWS アカウント AWS CloudFormation スタックリソースをデプロイするための適切な IAM アクセス許可 CloudFormation テンプレートの起動 AWS CloudFormation を使用してソリューションリソースをデプロイするには、次のステップを完了してください: 以下を選択してCloudFormationスタックを起動してください。 スタック名を入力してください。 機能と変換 の下のすべてのチェックボックスを選択してください。 スタックの作成 を選択してください。 CloudFormation テンプレートは、次のものを含む多くのリソースを作成します: データパイプラインとなる Step Functions ワークフロー エクスポートされたデータと Amazon RDS のテーブルのメタデータを格納する S3 バケット DynamoDB の製品カタログテーブル 事前にテーブルがロードされた RDS for PostgreSQL データベースインスタンス RDS テーブルをクロールして AWS Glue Data Catalog を作成する AWS Glue クローラー RDS テーブルから S3 バケットにデータをエクスポートするパラメータ化された AWS Glue ジョブ DynamoDB から S3 バケットにデータをエクスポートする Lambda 関数 障害のシミュレート ソリューションをテストするには、次のステップを完了してください: Step Functions コンソールで、ナビゲーションペインの ステートマシン を選択します。 ETL_Process という名前のワークフローを選択します。 デフォルトの入力でワークフローを実行します。 数秒で、ワークフローは Distributed Map ステートで失敗します。 マップ実行のエラーは、マップ実行と子ワークフローの Step Functions ワークフロー実行イベントにアクセスすることで調査できます。この例では、例外が AWS Glue の Glue.ConcurrentRunsExceededException によるものであることがわかります。このエラーは、AWS Glue ジョブの同時実行要求数が、設定された数を超えていることを示しています。Distributed Map は Amazon S3 からテーブルメタデータを読み取り、.csv ファイルの行数と同じ数の AWS Glue ジョブを起動しますが、AWS Glue ジョブは作成時に同時実行数が 3 に設定されています。これが子ワークフローの失敗を引き起こし、失敗が Distributed Map ステート、次いで Parallel ステートに伝播した結果です。Parallel ステートのもう一方のステップで DynamoDB テーブルを取得する処理は正常に完了しました。Parallel ステートのいずれかのステップが失敗した場合、連鎖的な失敗が見られるように、ステート全体が失敗します。 Distributed Map による障害への対処 デフォルトでは、ステートがエラーを報告すると、Step Functions はワークフローの失敗を引き起こします。 Distributed Map ステートでこの失敗を処理する方法は複数あります: Step Functions を使用すると、 エラーをキャッチし、エラーをリトライし、別のステートにフォールバックして エラーを適切に処理することができます。次のコードを参照してください: Retry": [ { "ErrorEquals": [ "Glue.ConcurrentRunsExceededException " ], "BackoffRate": 20, "IntervalSeconds": 10, "MaxAttempts": 3, "Comment": "Exception", "JitterStrategy": "FULL" } ] JSON 場合によっては、ビジネスが障害を許容できることがあります。これは、数百万のアイテムを処理していて、データセットにデータ品質の問題があることを予測している場合に特に当てはまります。デフォルトでは、Map ステートのマップ処理が失敗すると、他のすべてのマップ処理が中止されます。Distributed Map を使用すると、障害のしきい値として、失敗したアイテムの最大数または割合を指定できます。障害が許容レベル内であれば、Distributed Map は失敗しません。 Distributed Map ステートを使用すると、子ワークフローの並列実行数を制御できます。並列実行数を AWS Glue ジョブの並列実行数にマッピングできます。この並列実行数は、ワークフロー実行レベルでのみ適用されることに注意してください。ワークフローの異なる実行を跨いでは適用されません。。 エラーの根本原因を修正した後、失敗したステートからステートを再実行できます。 失敗したステートの再試行 このサンプルソリューションの問題の根本的な原因は、AWS Glue ジョブの同時実行性にあります。 失敗したステートを再実行するために、次のステップを完了してください: AWS Glue コンソールで、 ExportsTableData という名前のジョブに移動します。 ジョブの詳細 タブの 詳細プロパティ で、 最大同時実行数 を 5 に更新します。 再実行機能のローンチに伴い、過去 14 日間で正常に完了しなかった 標準ワークフロー の実行を再起動できるようになりました。 これには、失敗、中止、タイムアウトした実行が含まれます。 失敗したワークフローは、最後に正常に完了しなかったステートと同じ入力を使用して、失敗したステップからのみ再起動できます。 最初のワークフロー実行とは異なるステートマシン定義を使用して、失敗したワークフローを再起動することはできません。 失敗したステートが正常に再起動されると、Step Functions はすべての後続のタスクを自動的に実行します。Distributed Map の再起動がどのように機能するかの詳細については、 マップ実行の再起動 を参照してください。 マップ内のステップが子ワークフローとして実行されるため、ワークフローの IAM 実行ロールには、Distributed Map のステートを再起動するためにマップ実行を再実行する権限が必要です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "states:RedriveExecution" ], "Resource": "arn:aws:states:us-east-2:123456789012:execution:myStateMachine/myMapRunLabel:*" } ] } JSON プログラムで失敗したステップからワークフローを再実行するには、 AWS Command Line Interface (AWS CLI) や AWS SDK を使用するか、視覚的な操作体験を提供する Step Functions コンソールを使用できます。 Step Functions コンソールで、再実行したい失敗したワークフローに移動します。 詳細 タブで、 失敗から再実行 を選択します。 パイプラインは、AWS Glue ジョブを実行するのに十分な同時実行数があるため、正常に実行されます。 ワークフローをプログラムで失敗したポイントから再実行するには、 新しい Redrive Execution API アクションを呼び出します。同じワークフローが最後の失敗したステートから開始され、最後に成功しなかったステートと同じ入力が使用されます。ワークフロー定義と、再実行対象のステートとステートへの入力は、変更できません。 子ワークフローの異なるタイプについて、次の点に注意してください: Express 子ワークフローの再実行 – Distributed Map 内の Express ワークフローである失敗した子ワークフローの場合、再実行機能により、子ワークフローの先頭からシームレスに再起動できます。 これにより、マップ全体を再起動することなく、個々のマップに固有の問題を解決できます。 標準子ワークフローの再実行 – Distributed Map 内の標準ワークフローである失敗した子ワークフローの場合、再実行機能はスタンドアロンワークフローと同じように機能します。 各マップ内の失敗したステートを、すでに正常に実行された不要なステップをスキップして、失敗したポイントから再起動できます。 Step Functions のステータス変更通知 を Amazon EventBridge と組み合わせることで、失敗時にメールを送信するなどの失敗通知ができます。 クリーンアップ リソースをクリーンアップするには、AWS CloudFormation コンソールから CloudFormation スタックを削除してください。 まとめ この投稿では、Step Functions の再実行機能を使用して、失敗したステップを失敗したポイントから再起動することにより、Distributed Map 内の失敗したステップを再実行する方法を示しました。 Distributed Map ステートを使用すると、サーバーレスアプリケーション内で大規模なパラレルワークロードを調整するワークフローを記述できます。 Step Functions は、最大並列度 10,000 で Distributed Map 内のステップを子ワークフローとして実行します。これは、多くの AWS サービスでサポートされている同時実行数を大きく上回っています。 Step Functionsの Distributed Map の詳細については、 Step Functions – Distributed Map を参照してください。ワークフローの再実行の詳細については、 Redriving executions を参照してください。 本記事は、Sriharsh Adari、Joe Morotti、Uma Ramadoss による “ Build efficient ETL pipelines with AWS Step Functions distributed map and redrive feature ” を翻訳したものです。 翻訳はソリューションアーキテクトの高橋が担当しました。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2023 年 11 月 15 日に、「【Edtech Meetup】Edtech スタートアップがグローバルに活躍するには？」と題したイベントを AWS Startup Loft Tokyo にて開催しました。 このイベントでは、グローバルに活躍する Edtech スタートアップの方々をお招きし、Go to Market 戦略やグローバル展開における苦労とその乗り越え方などについてパネルディスカッションを行いました。 Edtech スタートアップや教育業界の方々が集まり、業界のプロフェッショナルの方々との交流を深め、新たなアイデアやビジネスチャンスを見つける機会を創出いたしました。今回はそのレポートをお届けします。 オープニング イベント冒頭では、AWS パブリックセクター 教育事業本部 初等中等教育/EdTech 営業部長の平塚 建一郎が、オープニングのあいさつをしました。 AWS パブリックセクター 教育事業本部 初等中等教育/EdTech営業部長 平塚　建一郎 日本では、少子高齢化が大きな社会問題になっています。2022 年の日本人出生数は約 77 万人であり、統計を始めた 1899 年以降で最少。初めて 80 万人台を割り込みました。「これは教育関連の事業を手がけている方々にとって、切実な問題ではないかと思います」と平塚は触れます。 日本の人口は徐々に減少していくため、教育関連の事業をグロースさせるうえでは“世界”に目を向けることが重要です。現在、日本の 15 歳未満の人口は約 1,435 万人ですが、世界の 15 歳未満の人口は約 18 億人。単純計算すると、世界には日本の 100 倍以上の市場が存在します。 しかし、日本企業が海外進出するには大きなハードルがあります。商習慣や文化の違い、法規制、販路拡大、知的財産の扱い、人員の確保、資金調達といった問題を乗り越える必要があるのです。そうした課題に対する解決策のヒントを提供するため、AWS は本イベントを開催しました。すでにグローバル展開を行っている各社から、各種の課題をいかにして乗り越えてきたのかを解説していただきます。 「最後になりますが、私たち AWS もグローバル企業のうちの一社です。世界各国で Edtech 企業のご支援をさせていただいております。何かしらの形でみなさまのお役に立てればと考えておりますので、お気軽にご相談ください。何卒よろしくお願いいたします」と、平塚はあいさつを終えました。 パネルディスカッション開始 ＜モデレーター＞ ワンダーファイ株式会社　代表取締役 CCO /ファウンダー　川島 慶 氏 ＜スピーカー＞ ELSA, Corp. 日本法人代表 玉置 俊也 氏 Riiid Inc.　日本代表　Moon YongJoo 氏 Instructure, Inc.　Channel Account Manager APAC Japan　玉木 和将 氏 ここからは、グローバル展開を行っている各社が登壇。ワンダーファイ社は、世界中の子どもから「知的なわくわく」を引き出すための教材やコンテンツを開発・運営する会社です。STEAM 教育領域の通信教育サービス「ワンダーボックス」 や、150 カ国 200 万人の子どもが楽しむ思考力が育つアプリ「シンクシンク」を運営しています。 ELSA 社は英語をより正しく、自信を持って話せるようになるための AI パーソナルコーチアプリ「ELSA」を提供する企業。「ELSA」は世界の AI 企業 100 にも選ばれた独自の音声認識技術を用いていて、学習者は自分自身のスピーキングの弱みを把握して短期間で改善できます。現在、100 カ国以上 5,000 万人のユーザーに利用されています。 Riiid 社は多くの AI エンジニア/リサーチャーが在籍する韓国発のディープテックベンチャー。機械学習領域で研究や論文発表を行い、特に教育や学習分野の研究に力を入れてきました。事業としては AI パーソナライズ TOEIC 学習アプリ「Santa」などを提供。「Santa」は韓国と日本で合計 600 万人以上のユーザーが利用しています。 Instructure 社は、アメリカに本拠地を置く Edtech スタートアップ企業です。Web ベースの学習管理システム「Canvas」や評価管理システム「MasteryConnect」の開発・提供を行っています。Instructure 社の顧客数は 6,000 機関以上あり、アメリカのアイビーリーグの全教育機関が「Canvas」を使用しています。 各企業の概要紹介や登壇者による活動内容の紹介の後、パネルディスカッション形式での議論を行いました。 ワンダーファイ株式会社　代表取締役 CCO /ファウンダー　川島 慶 氏 グローバル展開において、さまざまな障壁を乗り越える方法 ここからは、グローバル展開において経験した苦労や障壁、それを乗り越える方法などについて各社が事例を話しました。 玉置 氏は ELSA 社とRiiid 社、Instructure 社の本社が海外にあることを述べたうえで、「本社と日本との商慣習の違いで苦労することが多い」と述べます。たとえばアメリカの企業では多くの場合、可能な限りスピーディーにビジネスの成果を出すことを従業員に求めます。事業の海外展開においても、それは同様です。 しかし、特定の国への進出をゼロからスタートする場合、そんなに簡単には売上を立てられる状態にはなりません。ましてや、日本は「企業同士の関係値や信頼関係を構築してからサービスを契約する」という慣習が根強く、アメリカのように「お互いの利害関係が一致すればすぐにサービスを契約する」という文化ではないのです。その点を、本社へと適切に伝えることが大事だといいます。玉置 氏の所属する ELSA 社においても、日本で最初の顧客を獲得するまでに長い時間がかかりました。 また、Moon 氏は「同じプロダクトであっても、韓国と日本とではユーザーのニーズやユースケースが全く違っていた」と話します。Riiid 社の提供する「Santa」は、TOEIC のための英語学習を行うユーザーを対象としています。韓国では主なユーザーが大学生であり、ほとんどの人が就職活動のために TOEIC を受けます。アプリを利用する期間が数カ月ほどの短期間なのです。 一方、日本では転職活動や昇進などをきっかけに TOEIC の学習をする人が多く、より長期間アプリを使用する傾向にあります。「こうした情報は、実際に現地で働いてみなければなかなか見えてきません」と Moon 氏は述べました。 また、イベント中盤では「各国の拠点の裁量やプレゼンスを大きくしていく方法」についても語られました。川島 氏の所属するワンダーファイ社は、2017 年より国際協力機構（JICA）中小企業海外展開支援事業として、カンボジアにおいて思考力教育の導入事業を手がけています。この事業では、カンボジアの拠点のメンバーがプレゼンスを発揮し、現地の政治家との連携などを行っているのです。 Instructure, Inc.　Channel Account Manager APAC Japan　玉木 和将 氏 このテーマについて玉木 氏は「特定の国に新しい拠点を築く場合、ビジネスの土台を作るにはかなりのエネルギーが必要」と述べます。ここで言う“土台”は、パートナー企業の開拓のように“社外”との活動や関係性構築だけではなく、“社内”とのやりとりも含まれます。たとえば、本社に対して日本の商慣習や文化、教育業界の状況などを伝え、ビジネスプランにそれらを活かさなければならないのです。 玉木 氏は過去に経験した印象深い出来事として、日本以外の国で働く Instructure社のメンバーにチャットツール上であいさつをした際のエピソードを挙げます。その社員からは「日本拠点があることを知らなかった」という旨の返答があり、「社内外に向けて積極的に情報発信しなければならない」と痛感したのだといいます。 海外展開を成功させるためのヒント イベント終盤では、企業が海外展開を成功させる知見について語られました。玉木 氏は、日本における採用とアメリカにおける採用の違いと、それに関連して事業をスケールさせるための考え方を話しました。 アメリカにおける採用では「その人材が特定の職能におけるスペシャリストであり、社内でその役割のみを果たすこと」を期待して人を採ります。社員は一人一役であり、専門性を持ったメンバーがチームとして動くことで企業が成り立っているのです。 一方で、日本における採用では「その人材が部署内のさまざまな業務を担当し、ジェネラリストとして立ち回ること」を期待されることが多いです。異動により、その社員が専門知識を持たない業務を担当することもあります。この仕組みにより、企業全体の生産性がなかなか向上しないという課題が生じます。玉木 氏は「事業をスケールさせるためには、日本企業も“チームとして動くこと”を前提とした組織・制度構築が必要」と語りました。 また、サービスを各国に展開してビジネスを成功させるうえでは、特定の国における成功体験を他の国に持ち込んではならないと玉木 氏は言及。その国の慣習や文化、ユーザーに合わせた形でサービスの機能やプランなどをローカライズしていく必要があるのです。 Riiid Inc.　日本代表　Moon YongJoo 氏（写真右） Moon 氏も「グローバル展開を考えるならば、必ず一人はその国で働くメンバーが必要。他国に拠点を置かずに簡単にスタートしたいのはわかるが、デスクで他の国を完璧に想像するのはできない。マーケティングクリエイティブすら毎日変わってる中で、他の業務をしながら他国の市場状況を理解するのは不可能に近い。正しい市場反応を得られるためには、正しい検証方法が必須なので、現地を理解して正しい検証ができるメンバーが最低一人は必要になる。また、海外進出は必ず何度も失敗を繰り返すことになるので、何度も失敗してもそこから学んで成功に持っていける体制がもっとも大事です。 現地専任の人ではない限りは、小さな失敗でもすぐ諦める可能性がものすごく高い。現地のことを理解、失敗を繰り返せる体制、この二つなしではどれほど素晴らしいサービスでも必ず失敗してしまう。」と述べました。 玉置 氏は ELSA 社の事例を踏まえて「日本からグローバルに進出する場合、そして他の国から日本に進出する場合に役立ちそうな Tips を最後に共有させてください」と述べました。 ELSA 社がユーザーを増やすために大切にしていることとして、玉置 氏はグロースループを挙げます。これは、特定のユーザーが他のユーザーを呼び込むという制度設計のことです。たとえばインフルエンサーマーケティングにおいても、“共感”をベースに施策を推進することを大切にしているといいます。 ELSA 社では英語の AI パーソナルコーチアプリ「ELSA」の認知拡大のために、お笑い芸人のたむらけんじ 氏をプロモーションに起用しています。たむら 氏は 50 歳の誕生日を機に、活動拠点をアメリカに移しました。その様子を SNS で見ていた ELSA 社の社員が「たむら 氏を手助けしたい」という思いから、彼にアプローチしたのだといいます。その後、たむら 氏は ELSA 社のビジョンや「ELSA」のプロダクトコンセプトに共感し、自発的にさまざまなプロモーションを行ってくれるようになりました。 ELSA, Corp. 日本法人代表 玉置 俊也 氏 この例のように「ユーザーがプロダクトを好きになってくれること」「ユーザーが他の方々と一緒に楽しく学べるようなプロダクトにすること」などを ELSA 社は重視して、施策・機能の設計をしています。 それに加えて、ELSA 社は世代を超えて楽しめる学習体験を作ることも意識しています。例を挙げると、子どもが「ELSA」を使って自宅で英語学習をする際に、家族も一緒に楽しめるような仕掛けを用意しています。それがきっかけで、両親が「ELSA」の良さに気付き、自分の働く企業にプロダクトを導入する可能性が生まれるのです。「こうした共感ベースのアプローチを、ぜひ参考にしていただければ幸いです」と玉置 氏は結びました。 AWS パブリックセクター　パートナーアライアンス本部 パートナー事業開発マネジャー 松下 紘之 イベント終盤には AWS からのお知らせとして、AWS パートナーネットワーク（以下、APN）についての紹介をしました。AWS パートナーネットワーク (APN) は、オファリングの構築、マーケティング、およびお客様への販売のためのプログラムとリソースを活用するパートナーのグローバルコミュニティです。 APN への参加後、企業は自社のビジネスに関連するパートナーパスに登録します。パートナーパスには「ソフトウェアパス」「ハードウェアパス」「サービスパス」「トレーニングパス」「ディストリビューションパス」の 5 種類が存在しています。 パートナーパスの詳細はこちら APN の 加入企業は、AWS を基盤としたビジネスの構築に役立つ AWS パートナープログラムを効果的に活用することで、 事業成長に結びつけていただくことが可能です。 AWS パートナープログラムの詳細はこちら 今回のイベントは AWS パブリックセクターが主催していることもあり、これらのプログラムのうち、AWS 公共部門パートナープログラムについて詳細に解説。そして、このプログラムを積極活用し公共パートナービジネスの急速成長を目指していく企業に対しての、AWS のアクセラレーション支援の概要や事例についてもご紹介しました。 AWS パブリックセクターは今後も、Edtech スタートアップの方々に向けてさまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心を持たれた方は、ぜひお気軽にこちらまでお問い合わせください。みなさまのご参加をお待ちしております！ このブログは、アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャー（ Startup ）である田村 圭が執筆しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 JAWS DAYS 2024 が 3 月 2 日 (土) に開催されます。これは東京で 5 年ぶりに開催されるリアルイベントで、オフラインで実施されます。多様なテーマのイベントが計画されており、「新しいビジネスアイディアを持つ人が、JAWS DAYS 2024 に参加しているエンジニアと一緒に即席でアーキテクチャを検討する」というような興味深い内容が予定されています。申し込みはまだ開始されていませんが、3 月 2 日 (土) 10:00 から池袋サンシャインシティで開催されますので、興味のある方は事前に日程を確保すると良いと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月8日週の主要なアップデート 1/8(月) Amazon ECS improves deployment monitoring responsiveness for Amazon ECS services Amazon ECS でデプロイメントサーキットブレーカーを利用した際に、デプロイを「失敗」と判断するまでの時間が短縮され、迅速にロールバックできるようになりました。デプロイメントサーキットブレーカーは、ECS サービスのデプロイ後にタスクが RUNNING に遷移しない状況や、ヘルスチェックに失敗し続けるような状況を検知して、ロールバックを実行できる機能です。本アップデートにより、20 個未満のタスクを動かすサービスについて、「失敗」と判断するための最小閾値を 10 個から 3 個に下げました。 AWS Mainframe Modernization AWS Blu Insights is now available in additional regions AWS Blu Age サービスの AWS Blu Insights 機能が、東京を含む 14 リージョンで新しく利用できるようになりました。AWS Blu Age は、メインフレームで動作するアプリケーションを Java ベースのアプリケーションに自動変換し、モダナイゼーションを支援するサービスです。AWS Blu Insights は、コードベースの分析及び変換機能を提供します。アップデート以前は海外のリージョンで利用する事が出来ましたが、組織のセキュリティポリシー上、国外のリージョンを利用するハードルがある場合もあります。今回のアップデートで、国内の東京リージョンで利用ができるようになりました。 Amazon OpenSearch Service expands Graviton2 support to six additional regions Amazon OpenSearch Service の Graviton2 サポートが、大阪を含む 6 リージョンで新たに利用可能になりました。Graviton は Amazon が設計した 64 ビットの Arm Neoverse コアとカスタムシリコンを利用して構成されています。x86 ベースのインスタンスと比べて、最大 30 % 優れたコストパフォーマンスを提供できます。 1/9(火) Amazon EC2 C7i instances are now available in 8 additional AWS Regions Amazon EC2 で新たに C7i インスタンスが利用可能になりました。カスタムされた第 4 世代の Intel Xeon プロセッサー (Sapphire Rapids) を搭載しています。C6i インスタンスと比較して、最大 15 % 優れたコストパフォーマンスを提供し、バッチ処理、データ分析、広告配信、動画エンコードなど、コンピューティングリソースを消費する使い方に向いています。 AWS CodeBuild now supports a X-Large Linux compute type AWS CodeBuild の LINUX_CONTAINER ビルド環境で、新たに BUILD_GENERAL1_XLARGE (36 vCPU、70 GB メモリ、256 GB ディスク) をサポートしました。アップデート以前は、2 vCPU、4 vCPU、8 vCPU、72 vCPU の 4 パターンから選択できました。今回新たに 36 vCPU が追加され、ビルド対象とコストを見ながら、最適な環境を選択しやすくなりました。 AWS CloudShell now supports Docker in 13 Regions AWS CloudShell で新たに Docker をサポートしました。CloudShell 環境に Docker が事前インストールされるようになり、コンテナの起動、作成などを通じてコンテナベースの開発を素早く行えるようになりました。東京リージョンを含めた 13 リージョンで利用可能です。 1/10(水) Amazon EC2 M7i-flex and M7i instances now available in additional AWS regions Amazon EC2 で M7i と M7i-Flex インスタンスが、東京を含めた 2 つのリージョンで新たに利用可能となりました。カスタムされた第4世代の Intel Xeon プロセッサー (Sapphire Rapids) が搭載されています。M7i は、M6i と比較して最大 15 % 優れたコストパフォーマンスを実現します。新たな概念 の M7i-Flex は、 M7i をより安価に利用出来る汎用的なインスタンスタイプです。CPU の性能の 40 % 分は常時利用出来るベースラインが提供されています。40 % を超えた場合、95 % の確率で CPU パフォーマンスの 100 % を利用できます。残りの 5 % は、数ミリ秒 ~ 数十ミリ秒待機することで CPU が提供されます。M7i-Flex は、このような仕組みに基づき安価に利用できるタイプとなっており、選択肢のひとつに入れていただけると良いと思います。 Amazon Location Service now supports additional places content in Maps Amazon Location Service で、新たにカスタムレイヤーの概念が追加されました。カスタムレイヤーを有効化することで、地図上に要素を追加できます。現在のところ、カスタムレイヤーとして Point of Interest (POI) が選択可能です。これは、地図上にショップ、レストラン、サービス施設、アトラクション、その他興味を持つ場所の情報を追加できます。人の目で地図を見たときに、場所情報も一緒に確認することで、視覚的によりわかりやすく利用できるようになりました。現在、カスタムレイヤーは Esri Navigation のマップスタイルのみ利用可能です。 1/11(木) Amazon CloudWatch Logs now supports account level subscription filter Amazon CloudWatch Logs でアカウント単位のサブスクリプションフィルター機能を追加しました。取り込まれたログをリアルタイムに、Kinesis Data Streams、Kinesis Data Firehose、AWS Lambda を経由して、データ処理や他のサービスへ転送などができます。今までは、ロググループ単位でサブスクリプションフィルターを設定するものだったため、複数のロググループにまたがった設定を行いたいときに、一つずつ設定が必要でした。今回のアップデートで、アカウント単位のサブスクリプションフィルターが利用できるようになり、アカウント全体に 1 つのサブスクリプションフィルターポリシーを設定することで、複数のロググループに取り込まれたログを出力できるようになりました。また、設定のシンプル化に加えて、ロググループあたりのサブスクリプションフィルターを設定する Service Quota の上限が 2 となっており、これを節約できるメリットもあります。 Amazon EC2 R7i instances are now available in more AWS regions Amazon EC2 で、R7i インスタンスが、東京を含む 9 つのリージョンで新たに利用可能となりました。R7i インスタンスは、R6i インスタンスと比較して最大 15% 優れたコストパフォーマンスを提供します。これらのインスタンスは SAP 認定を受けており、SAP、SQL、NoSQL データベース、分散型 Web スケールのインメモリキャッシュ、SAP HANA などのインメモリデータベース、Hadoop や Spark などのリアルタイムビッグデータ分析など、メモリを大量に消費するワークロードに最適です。 Amazon ECS and AWS Fargate now integrate with Amazon EBS Amazon ECS と AWS Fargate が Amazon EBS と統合され、EBS ボリュームを簡単にプロビジョニングし、ECS タスクにアタッチができるようになりました。この機能により、ECS Task で、ETL ジョブ、メディアトランスコーディング、ML 推論ワークロードなど、ストレージやデータ集約型のアプリケーションを簡単にデプロイるようになりました。元々、ECS on Fargate で統合されているストレージは、「一時ストレージ」と「EFS」がありました。「一時ストレージ」は、簡単に利用できる一時的なストレージ領域ですが、最大 200 GB の制限があります。「EFS」はより大容量のストレージを利用出来ますが、パフォーマンス管理などが必要となっていました。今回のアップデートで、Task に 専用の EBS ボリュームをアタッチできるようになり、低レイテンシーと高パフォーマンスを両立するブロックストレージを利用できるようになりました。新規に EBS ボリュームをプロビジョニングするパターンと、Snapshot を利用して事前にデータを格納しておくパターンが選択できます。詳細は こちらの Blog をご参照ください。 1/12(金) ROSA with hosted control planes (HCP) is generally available Red Hat OpenShift Service on AWS (ROSA) で、Hosted Control Plane (HCP) の一般提供が開始されました。これにより、ROSA の実行コストの削減、クラスターの作成時間の短縮、アップグレードの柔軟性が向上しました。従来の構成は、ROSA のコントロールプレーン (Master Node、Infrastructure Node) をお客様の AWS アカウント上にデプロイする必要がありました。その際、最小構成でも 7 台の EC2 インスタンスが必要で、コスト増加やインスタンス管理の手間が発生していました。しかし、今回のアップデートにより、コントロールプレーンを ROSA サービス側で提供する HCP 構成を選択できるようになり、最低 2 台の EC2 インスタンスから利用可能になりました。HCP を利用する場合、コントロールプレーンの料金として 1 時間あたり $0.25 が追加されますが、インスタンスの台数が減少することで全体のコスト削減が期待できます。 Private Access to the AWS Management Console is available in 7 additional AWS Regions AWS マネジメントコンソールにおける Private Access 機能が、東京を含む 7 つのリージョンで提供を開始しました。この機能の主なユースケースは、組織内の操作端末からAWS マネジメントコンソールにアクセスする際に、未管理の AWS アカウントへのアクセスを制限することが挙げられます。例えば、セキュリティ上の理由から、組織内の端末を使って個人所有の AWS アカウントへのアクセスを禁止する場面がこれに当たります。誤解されやすい点ですが、Private Access 機能を使用しても、Web Proxy の利用など、インターネット経由のアクセスは依然として必要です。画像や JavaScript、CSS はインターネット経由で取得されます。また、Private Access で利用できないサービスも存在します。詳細については、 こちらのドキュメント を参照してください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

はじめに 本記事では、個人用の Java 版 Minecraft サーバーを AWS 上にデプロイする方法をご紹介します。サーバーを AWS にホストすることで、自宅サーバーを使用した際に伴う、一般的なネットワーク上の課題やセキュリティ上の懸念を解消することができます。また、仮想マシンを制御できるため、任意の MOD やプラグインを構成することができます。今回は、 Amazon Elastic Compute Cloud (EC2) を使用して、友人と一緒に使用できる Minecraft サーバーを稼働させます。本記事で、コストの最適化についての説明は省きますが、サーバーのコストを削減する方法はたくさんあります。 ソリューション概要 本ソリューションは、Amazon EC2 を使用して、Minecraft サーバー用の仮想マシンを起動します。EC2 ではネットワーク構成を制御でき、さまざまな CPU および RAM オプションを備えた数百種類の EC2 インスタンスタイプから選択できます。この柔軟性により、小規模なプレイヤーベースと大規模なプレイヤーベースの両方をサポートするサーバーをホストできます。 仮想マシンは、AWS クラウド上の仮想プライベートネットワークである Amazon Virtual Private Cloud (VPC) で起動されます。さらに、EC2 インスタンスをセキュリティグループで保護します。セキュリティグループは、EC2 インスタンスへのアクセスを制御できる仮想ファイアウォールです。サーバーの設定を簡単にするために、必要なソフトウェアをインストールしてサーバーを実行するのに役立つ bash スクリプトを用意しています。 ウォークスルー 前提条件 AWS アカウント Minecraft Java Edition Account ステップ EC2 インスタンスのセットアップ カスタムスクリプトを使用して Minecraft サーバーのセットアップを自動化 Minecraft サーバー専用の IP アドレスを割り当て サーバーオペレータの設定、ワールドファイルの変更など クリーンアップ EC2 インスタンスのセットアップ Java 版 Minecraft サーバーを実行するには、Amazon EC2 を使用して仮想マシンを作成する必要があります。 AWS コンソール にログインします。 コンソールの右上で、プレイヤーのロケーションに適した AWS リージョンを選択します (たとえば、プレイヤーベースが米国西海岸にある場合は、us-west リージョンのいずれかを選択します)。 EC2 と検索し、EC2 ダッシュボードに移動します。 インスタンスを起動 を押します。 EC2 インスタンスの設定をここで行います。インスタンスに Minecraft Server などの名前を付けます。1 番目の Amazon Linux AMI を選択し、アーキテクチャを 64 ビット (Arm) に変更します。今回は、 Amazon Linux 2023 AMI を使用しました。 インスタンスタイプで、 t4g.small を選択します。サーバーが処理しきれないほどの多くのユーザが接続する場合は、いつでも サーバーをより大きな EC2 インスタンスにアップグレード できます。 キーペア名で 新しいキーペアを作成 を押します。キーペア名を入力し、 キーペアを作成 を押します。秘密鍵は自動的にダウンロードされます。 ネットワーク設定のセクションまでスクロールします。右上の 編集 ボタンをクリックします。ここで、EC2 インスタンスを保護し、安全でない接続を防ぐためのセキュリティグループを作成します。 デフォルト VPC を選択し、サブネットは指定しないままにして、パブリック IP の自動割り当てを有効にします。デフォルト VPC には、各 アベイラビリティーゾーン に 1 つのパブリックサブネットがあるため、変更せずに選択できます。 ファイアウォールで、 セキュリティグループの作成 を選択します。セキュリティグループ名を Minecraft Security Group に変更します。オプションで、 Security group with ports open for Minecraft Server &amp; SSH などの説明を追加します。 次に、接続を許可するインバウンドルールを 2 つ追加します。 EC2 Instance Connect は、AWS コンソールから EC2 インスタンスに安全に接続する方法です。EC2 インスタンスに接続するには、EC2 Instance Connect IPアドレスからの SSH トラフィックを許可する必要があります。EC2 Instance Connect IP アドレスの範囲は、EC2 インスタンスが置かれている AWS リージョンによって異なります。EC2 インスタンス接続の一般的な US の IP 範囲は次のとおりです。 IP CIDR Ranges us-east-1: 18.206.107.24/29 us-east-2:&nbsp;3.16.146.0/29 us-west-1:&nbsp;13.52.6.112/29 us-west-2: 18.237.140.160/29 EC2 インスタンスを起動するリージョンが上記のリストにない場合は、 AWS IP アドレスのドキュメント で IP 範囲を確認できます。JSON ファイルをダウンロードし、ブラウザで開きます。それを生データとして表示し、 Ctrl+F または Command+F を使用して文書内のテキストを検索します。検索バーに EC2_INSTANCE_CONNECT と入力し、利用するリージョンのインスタンス接続 IP を見つけます。 インバウンドセキュリティグループのルール に進んでください。デフォルトの SSH トラフィックルールで、ソースタイプを カスタム に変更します。使用している地域の IP アドレス範囲をソースフィールドに入力します。us-east-1 IP の使用例については、以下のスクリーンショットを参照してください。 セキュリティグループに別のインバウンドルールを追加して、ポート 25565 でどこからでも (0.0.0.0/0) TCP トラフィックを許可します。これにより、Minecraft プレーヤーがサーバーに参加できるようになります。 ネットワーク設定は次のようになります (この例では us-east-1 リージョンを使用しました)。 ストレージ設定のセクションに進んでください。ルートボリューム EBS には 8GB を選択します。これは、EC2 インスタンスが関連付けているストレージの量です。必要に応じてストレージを追加することもできますが、始めるには 8GB で十分です。 無料利用枠 の対象となるお客様は、EBS で最大 30GB の SSD を無料で入手できます。 Minecraft を自動的にダウンロードしてセットアップするようにユーザーデータを設定する 次に、EC2 インスタンスを起動するたびに Minecraft サーバーを自動的にダウンロード、設定、実行する bash スクリプトを追加します。 重要: スクリプトは、お客様に代わって Minecraft との エンドユーザー使用許諾契約 (EULA) に自動的に署名します。これは Minecraft サーバーの jar ファイルを実行するために必要で、通常はユーザーが行います。このスクリプトを使用することにより、Minecraft サーバーを実行するための EULA に同意したものとみなされます。 ページの一番下までスクロールし、 高度な詳細 セクションを見つけて展開します。もう一度ページの一番下までスクロールして、 ユーザーデータ フィールドを見つけます。 ユーザーデータ フィールドに、以下の Minecraft セットアップスクリプトの自動化 セクションのスクリプト全体をコピーして、 ユーザーデータ セクションに貼り付けます。 Minecraft セットアップスクリプトの自動化 #!/bin/bash # *** INSERT SERVER DOWNLOAD URL BELOW *** # Do not add any spaces between your link and the "=", otherwise it won't work. EG: MINECRAFTSERVERURL=https://urlexample MINECRAFTSERVERURL= # Download Java sudo yum install -y java-17-amazon-corretto-headless # Install MC Java server in a directory we create adduser minecraft mkdir /opt/minecraft/ mkdir /opt/minecraft/server/ cd /opt/minecraft/server # Download server jar file from Minecraft official website wget $MINECRAFTSERVERURL # Generate Minecraft server files and create script chown -R minecraft:minecraft /opt/minecraft/ java -Xmx1300M -Xms1300M -jar server.jar nogui sleep 40 sed -i 's/false/true/p' eula.txt touch start printf '#!/bin/bash\njava -Xmx1300M -Xms1300M -jar server.jar nogui\n' &gt;&gt; start chmod +x start sleep 1 touch stop printf '#!/bin/bash\nkill -9 $(ps -ef | pgrep -f "java")' &gt;&gt; stop chmod +x stop sleep 1 # Create SystemD Script to run Minecraft server jar on reboot cd /etc/systemd/system/ touch minecraft.service printf '[Unit]\nDescription=Minecraft Server on start up\nWants=network-online.target\n[Service]\nUser=minecraft\nWorkingDirectory=/opt/minecraft/server\nExecStart=/opt/minecraft/server/start\nStandardInput=null\n[Install]\nWantedBy=multi-user.target' &gt;&gt; minecraft.service sudo systemctl daemon-reload sudo systemctl enable minecraft.service sudo systemctl start minecraft.service # End script 次に、Minecraft サーバーファイルをダウンロードするために、スクリプトにリンクを追加する必要があります。Minecraft サーバーの最新バージョンを実行するには、公式の Minecraft サーバーダウンロードページ にアクセスしてください。 Download minecraft_server.1.20.4.jar and run it with the following command: と表示されている場所を見つけてください。ハイパーリンク Minecraft_server.jar を右クリックして、リンクをコピーします。 下の画像は、Minecraftの公式サイトからサーバー jar ファイルのダウンロードリンクを取得する方法を示しています。 前のステップでコピーしたリンクを使用して、EC2 インスタンス起動ページの ユーザーデータ に戻ります。スクリプトの上部にある MINECRAFTSERVERURL= フィールドを探してください。マインクラフトサーバーのリンクを MINECRAFTSERVERURL 変数フィールドに貼り付けます。 = と貼り付けようとしている Minecraft jar ファイルの URL の間にスペースを入れないでください。スクリプトの他の部分は編集しないでください。以下の画像は、ユーザーデータフィールドでの正しい設定の例を示しています。 例: Minecraft 1.20.1 では、ユーザーデータ内のコマンドは以下になります。 “MINECRAFTSERVERURL= https://piston-data.mojang.com/v1/objects/84194a2f286ef7c14ed7ce0090dba59902951553/server.jar” 上記の手順をすべて完了したら、 インスタンスを起動 を押します。EC2 インスタンスは、初回起動時にサーバーの設定と起動に最大 5 ～ 10 分かかる場合があります。Minecraft サーバーをテストするには、インスタンス設定でパブリック IPv4 アドレスを探し、起動後数分経ってから Minecraft でその IP に接続します。 Minecraft サーバーへの接続に問題がある場合は、以下のオプションを試してください。 ユーザーデータスクリプトは、初回起動時に実行に最大 10 分かかることがあるため、十分に待ってください。 EC2 インスタンスを停止して起動してみてください。 セキュリティグループのネットワーク設定を確認してください。 マインクラフトサーバー専用の IP アドレスを設定する EC2 インスタンスがオフになるたびに、そのパブリック IP アドレスが変更されます。サーバーの電源を入れたり切ったりするたびに新しい IP を検索しなければならないのは非効率的です。この問題を解決するために、Elastic IP を EC2 インスタンスに関連付けます。Elastic IP アドレスは、変更されず、さまざまなリソースにアタッチできる専用 IP アドレスです。 Elastic IP などのパブリック IPv4 アドレスには、AWS 上で 料金が発生 します。コストを節約するためには、サーバーがしばらくアイドル状態になる場合は、 Elastic IP アドレスを解放してから、EC2 インスタンスを停止します。Elastic IP を解放して再度関連付けると、サーバーの IP アドレスが変更されることが多いことに注意してください。 Elastic IP のセットアップ EC2 ダッシュボードで、左側のツールバーを展開します。 ネットワーク&amp;セキュリティ で、 Elastic IP をクリックします。 右上の Elastic IP アドレスの割り当てる ボタンをクリックします。 Amazon の IPv4 アドレスプール からパブリック IPv4 を選択します。 割り当て を押します。 Elastic IP を選択し、 アクション → Elastic IP アドレスの関連付け をクリックします。リソースタイプを インスタンス としてクリックし、ドロップダウンメニューから Minecraft Server インスタンスを選択します。次に、 関連付ける をクリックします。 Minecraft Server EC2 インスタンスに戻り、パブリック IPv4 フィールドの下を見るとご自身の Elastic IP アドレスを確認できます。 Minecraft サーバーに接続するには、ゲームのマルチプレイヤー画面に移動し、サーバーを追加するか、直接接続を使用してください。 サーバーアドレス フィールドに、EC2 インスタンスのパブリック IPv4 アドレスを入力します。Elastic IP をインスタンスに関連付けた場合、Elastic IP はサーバーアドレスになります。 サーバーオペレータの設定、ワールドファイルの変更など Minecraft サーバーのセットアップが完了したので、ゲーム内でコマンドを実行するサーバーオペレーターを追加する必要があります。新しいワールドファイルのアップロード、プラグインの追加などもできます。これは、EC2 インスタンスのセットアップ時に設定した EC2 Instance Connect を介して行うことができます。 まず、EC2 ダッシュボードに移動し、Minecraft サーバーの EC2 インスタンスを見つけ、その横にあるチェックボックスをクリックして、コンソールの上部にある 接続 ボタンを押します。 インスタンスに接続 画面で、下にスクロールして 接続 をクリックします。ユーザーはすでに ec2-user になっているはずです。そうでない場合は、 ec2-user 　に変更してください。接続に失敗した場合は、EC2 インスタンスを再起動し、数分待ってから再試行できます。接続するオプションがない場合は、EC2 インスタンスを正しく設定していない可能性があります。EC2 インスタンスのセットアップセクションに戻って再確認する必要があります。 ここでは、一般的なトラブルシューティングのヒントをいくつか紹介しています。 ログインに成功すると、端末画面が表示されます。次に、一連のコマンドを入力して Minecraft サーバーディレクトリに移動し、必要な設定ファイルを編集します。 まず、 cd /opt/minecraft/server/ と入力して Enter キーを押します。これは サーバーファイルが格納されている EC2 インスタンスのディレクトリです。将来サーバー設定を編集する場合に備えて、このディレクトリを覚えておいてください。 ls と入力して Enter キーを押して、サーバーファイルがすべて存在することを確認します。下の画像の ls コマンドにリストされているものと同じ出力が表示されるはずです (例: world、logs、server.jar)。 start と stop が緑色に強調表示されていることに注意してください。 start ファイルは、EC2 インスタンスを起動したり再起動したりするたびに自動的に実行される実行ファイルです。この機能が Minecraft サーバーを起動するので、手動で起動する必要はありません。これらは編集しないでください。 Minecraft サーバーコンソールは表示されませんが、まだ実行中です。最初にサーバーをオフにしないと、ファイルまたはフォルダーを編集できません。そのためには、 sudo ./stop と入力して stop スクリプトを実行します。これにより、 stop スクリプトが管理者として実行されます。これで、新しいワールドやプラグインなどを追加できます。 下の画像は、EC2 インスタンスの接続画面と、赤色のボックスで囲われた入力が必要な一連のコマンドを示しています。 また、 SCP コマンド または Amazon S3 を使用してアップロードすることで、ローカルコンピューターから EC2 インスタンスに新しいワールドやその他のファイルをアップロードすることもできます。また、 server.properties ファイルを vim や nano などの UNIX テキストエディターで編集することもできます。 オペレータを追加したり、コンソール自体からコマンドを実行したりするには、 sudo ./start と入力してサーバを再実行する必要があります。これにより、起動スクリプトが管理者として実行され、Minecraft サーバーがロードされます。下の画像のようにサーバーコンソールが起動します。サーバーが起動するまでに数分かかることがあります。 コンソールに Done と表示されたら、サーバーは稼働しています。これで、ターミナルで / なしで通常の Minecraft コマンドを入力して実行できます。たとえば、プレイヤーをオペレーターとして追加するには、 op *PLAYERNAMEHERE* と入力します。 以下は、ロードが完了したときにサーバーコンソールが出力する内容の参照画像です。サンプルプレイヤー名を使用して、サーバーのオペレーターとして追加しました。 お疲れ様でした！サーバーディレクトリに正常にアクセスし、好みに合わせて変更しました。アップロードするサーバーファイルを完全に制御できます。MOD、プラグインなどを追加していきましょう！ クリーンアップ この投稿でプロビジョニングされたリソースから課金されないように、リソースをクリーンアップします。 EC2 ダッシュボードで、選択ボックスを使用して EC2 インスタンスを選択します。右上の インスタンスの状態 を選択し、 終了 を選択 します。 同じ EC2 の画面で、サイドバーを開いて Elastic IP を選択します。EC2 インスタンスに使用されている Elastic IP の横にある選択ボックスを押し、右上の アクション を押して、 Elastic IP アドレスの解放 を押します。 リソースのクリーンアップが完了しました。 結論 おめでとうございます！これで、専用 IP アドレスを持つ EC2 インスタンスに Minecraft サーバーができました。Minecraft サーバーでプレイしていないときは、EC2 インスタンスを小まめに停止することを強くお勧めします。これにより、コストを節約でき、 Minecraft サーバーが立ち上がっているときのみ料金が発生します。次のステップとして、Minecraft Server が使用されていないときに EC2 インスタンスを自動的に停止するソリューションの開発を検討することをお勧めします。 本ブログはソリューションアーキテクトの濵野が翻訳しました。原文は こちら です。

はじめに ソフトウェア開発および運用業界は近代化を進めており、プロセスの標準アプローチとして DevOps を採用するケースが増えています。しかし、SAP のインストールと運用は依然として手作業で行われる傾向にあります。これを自動化されたアプローチに進化させるために、 1 つ目のブログ記事 で、Terraform と AWS Launch Wizard などのネイティブ AWS ツールを使用して SAP アプリケーションのインフラストラクチャをプロビジョニングする方法を示しました。続いて 2 番目のブログ記事 では、AWS Systems Manager を使用した SAP ソフトウェアのインストールの自動化について説明しました。最後に、 3 番目のブログ記事 では、自動化について詳しく説明し、高可用性 (HA) で動作する SAP ランドスケープのフルインストールをエンドツーエンドで実行しました。 このブログ記事では、SAP ランドスケープの運用に重点を置いています。アプリケーションの耐障害性を理解し、デプロイされたアプリケーションが目標復旧時間を満たしていることを確認するには、高可用性テストが必要です 。多くの組織では、監査プロセスへの準拠を維持するために、高可用性構成を時々テストする必要もあります。 このブログで詳しく説明されているソリューションは、AWS SAP プロフェッショナルサービスチームが多くのお客様と共同で行った SAP HANA ワークロードの高可用性クラスタのデプロイとテストを自動化した結果です。SAP HANA ワークロードの高可用性クラスタは、お客様が必要に応じて使用および適応できるオープンソース (以下のリンク) として提供されています。 このブログ記事では、 カオスエンジニアリング と呼ばれる業界全体のプラクティスを SAP の世界に紹介しています。これにより、SAP ランドスケープの動作について確信が持てるようになり、予測可能性が高まります。また、システム停止や重大なエラーの発生後に自己修復するように構成する方法についても同様です。 カオスエンジニアリングを適用すると、問題が発生する前に潜在的な問題を特定できるため、SAP ランドスケープの回復力を向上させることができますが、当社の経験から言うと、必要な一連のテストシナリオを手動で実行するには最大で 2 か月かかることがあり、ほとんどの組織では高度なスキルを持つ専門家が必要です。 このブログ記事では、これらのテストシナリオを自動化し、チームの時間を大幅に節約し、監査プロセスのコンプライアンスを維持するための出発点として使用できるサンプルコードを共有します。 一般的な手動アプローチと比較して、このソリューションが HA 構成のテストにもたらすメリットは次のとおりです。 スピード: 約 2 か月から数時間。 信頼性: 12 の HA テストシナリオ (後述) を反復可能なプロセスでカバーします。 ヒューマンエラーの削減: HA テストは繰り返し可能なプロセスになるため、ヒューマンエラーによるテストの潜在的な失敗率が減少します。 監査資産: このソリューションによって生成される最終的な HTML レポートには、監査資産に必要な共通情報がすべて含まれています。 改善資産: エラーが発生した場合、最終的な HTML レポートではテスト中に具体的に何が問題になったかが強調され、エラーの前後のシステムの全体像も示されます。その後、この問題は SAP BASIS の専門家に解析され、高可用性構成に関する修正が適用されます。 ここで紹介するソリューションには、いくつかの異なる実行方法があります。しかし、最終的には、「レポート」セクションで示した例のように、すべてが HTML レポートを生成します。 このソリューションを出発点として、必要なコードがすべて揃った パブリック GitHub リポジトリ があります。実行方法を理解するには、「How to Run」のセクションを参照してください。 このガイド を使えば、簡単なラボ環境を構築できます。このサンプルコードは、企業での HA テストの自動化に必要な労力を軽減するための出発点として使用してください。このサンプルコードは、RedHat OS (オペレーティングシステム) 上の SAP HANA 1909 で実行できるようにビルドされ、テストされています。 前提条件 このガイドを開始してこのコードを実行する前に、以下の前提条件を満たす必要があります。 Ansible をコントローラインスタンスにインストールします。コントローラインスタンスには以下のものがあります。 独自のインスタンス、ラップトップ、ワークステーション このソリューションの実行を自動化する CI/CD ツール アンシブルタワー コントローラインスタンスと HA テストを実行する SAP ランドスケープインスタンスとの間に SSH アクセスと接続が確立されました。 1 つの SAP ランドスケープの構成は次のとおりです。 HA が以前に構成された 2 つの HANA インスタンス。詳細については、Red Hat Enterprise Linux クラスターの設定に関する AWS ドキュメント 「 configuring Red Hat Enterprise Linux clusters for SAP on AWS 」 を参照してください。 ASCS インスタンス 1 つ PAS インスタンス 1 つ AWS CLI (コマンドラインインターフェイス) で以下の権限が設定された 1 つの AWS IAM ロール。このロールはコントローラインスタンスの AWS CLI で設定する必要があります。Ansible はテスト中にこれを使用して SAP ランドスケープとやり取りします。詳細については、AWS CLI に追加のプロファイルを設定する方法をご覧ください。 ec2:StartInstance で全てのインスタンスを起動する ec2:RebootInstances で全てのインスタンスを再起動する ec2:StopInstances の全てのインスタンスを停止する AMI を作成し、このシナリオに関係するインスタンスから各 EBS ボリュームのスナップショットをバックアップとしてキャプチャします。 想定するする高可用性テストシナリオ 各テストシナリオの目標は、すべてのテストを一度に実行したくない場合に備えて、スタンドアロンのテストとして役立つようにすることです。そのために、テストシナリオの前後に特定のタスクを実行して、環境の設定が有効で、テストが正常に完了したことを確認しています。これらの一般的な手順は、実行順序に示されているとおりです。 実行に必要なすべての入力パラメータが通知されましたか? ノードとコントローラーノードは接続されていますか? どのノードがプライマリで、どのノードがセカンダリか? 最低限の高可用性構成は整っているか? HANA に設定されているレプリケーションモードは、フェイルオーバー前とフェイルオーバー後に同じですか? テスト開始前の ASCS エンキュー番号はいくつですか?フェイルオーバー後の番号と一致していますか? PAS は正しいデータベースインスタンスに接続されていますか?フェイルオーバー前とフェイルオーバー後? GitHub リポジトリにあるテストシナリオは以下の通りです。 プライマリデータベースの「HDB Stop」。 新しいプライマリデータベースで「HDB Stop」(フェイルオーバー後)。 セカンダリデータベースの「HDB Stop」。 プライマリデータベースの「PCS node standby」。 新しいプライマリデータベースの「PCS node standby」(フェイルオーバー後)。 プライマリデータベースの「kill -9 pid」。 プライマリデータベースに「echo ‘b’ &gt; /proc/sysrq-trigger」があると、インスタンスがクラッシュします。 新しいプライマリデータベースで「echo ‘b’ &gt; /proc/sysrq-trigger」が発生してインスタンスがクラッシュする (フェイルオーバー後)。 プライマリデータベースで「HDB kill -9」が発生しました。 新しいプライマリデータベースで「HDB kill -9」(フェイルオーバー後)。 プライマリデータベースを再起動。 新しいプライマリデータベースを再起動 (フェールオーバー後)。 レポート 図 1 — 最後のステップで障害が発生して生成された HTML レポートの例 図 1 に示されている HTML は、 実行された 2 つのシナリオ を示しています（さらに、実際のテストを実行する前にシステム構成を全体的にチェックする #1 と、 #6 のシステムクラッシュに必要な事後処理である #7）。そのうちの1つは成功（HDB 停止、ケース #3、#4、#5）、システムクラッシュ（#6）は、ポストアクションステップ（#7）で見つかったように）失敗しました。 コードの実行方法 シングルボタンによる代替方法: 3番目のブログ記事で説明したソリューションを使用している場合は、プロジェクトをリロードし (1 — vagrant destroy、2 — git pull、3 — vagrant up)、[Credentials] ですべてのパラメータを再入力し、[SAP Hana+ASCS+PAS 3 Instances] フォルダの下にある [Run HANA HA test] としてリストされている新しいジョブを見つけて、[build now] をクリックします。図 2 は、テストが完了した後の結果を示しています。 画像 2 — Jenkins パイプラインを使用して HA テストを実行したときの最終出力 これが完了すると、次の場所に移動する HTML レポートが表示されます。 ビルド番号 (この場合は 24) をクリックし、 「Workspaces」に移動します。 リストされている最初の項目を選択します。 フォルダー Report を選択し、 「report-&lt;current date and time&gt;.html」を右クリックし、ローカルデスクトップに保存します。必ずローカルに保存してください。保存しないと、レポートの形式が正しくありません。 図 3 — 最終的な HTML レポートをローカルに保存する 主な手順 Linux または Mac コンピューター上のターミナルにアクセスできる環境を用意します。 AWS CLI をローカルに設定してください。 GitHub リポジトリのクローンを作成してください。 各サーバー (HANA プライマリ、HANA セカンダリ、ASCS、PAS) について、hosts.yaml ファイルの情報を更新します。 ansible_host ansible_user ansible_ssh_private_key_file var_file.yaml を開いて、必要な情報を入力します。 # Field Default value Comments Information for HANA 1 INPUT_HANA_SID AD0 Your HANA SID 2 INPUT_HANA_INSTANCE_NUMBER 0 Your HANA instance number 3 INPUT_SYSTEM_USER SYSTEM Username for the SYSTEM default user. This will be used to check if a backup is available before starting the tests 4 INPUT_SYSTEM_PASSWORD P@ssw0rd Password for the SYSTEM user. This will be used to check if a backup is available before starting the tests 5 INPUT_HANA_SYNC_MODE SYNC HANA replication mode Information for ASCS 6 INPUT_ASCS_SID AD0 Your ASCS SID 7 INPUT_ASCS_INSTANCE_NUMBER 0 Your ASCS instance number Information for PAS 8 INPUT_PAS_SID AD0 Your PAS SID 9 INPUT_PAS_INSTANCE_NUMBER 0 Your PAS instance number 10 INPUT_CHECK_R3_TRANS TRUE Whether to check the R3trans command on PAS after database failovers or not Information for AWS CLI 11 INPUT_AWS_REGION us-east-1 The region where your instances are 12 INPUT_AWS_CLI_PROFILE default The profile you configured for your AWS CLI on Pre requisites, item 2 13 INPUT_PRIVATE_SSH_KEY /my/path/to/pemFile.pem Path to the SSH key for Ansible to SSH into your instances ファイル「how_to_run.sh」を実行してください。 これがソリューションを実行する一番の近道です。BASH に慣れている場合は、「how_to_run.sh」ファイルを見てその動作を理解し、自分のシナリオで自動化できる可能性を見つけることをお勧めします。 HANA のサイズと構成によって、この作業には多少時間がかかります。ベンチマークとして、空の SAP ランドスケープインストールで 12 のシナリオをすべて実行すると、約 45 分から 1 時間かかります。 SAP 環境が大きい場合は、「More configurations allowed」のセクションをよく読んでソリューションの実行方法をカスタマイズし、シナリオを複数の実行に分割することをお勧めします。これにより、大量のテストを実行する前に、より短い時間枠で出力を確認し、インストールで発生する可能性のあるエラーを理解できます。 最終レポートを分析 テストが完了すると、各テストの結果を含む HTML レポートが生成されます。障害が発生した場合、このレポートには修復計画を設計するための基本リソースとして必要な情報がすべて記載されています。これにより、(1) どのテストがうまくいかなかったかを理解するための情報が得られます。(2) 失敗したコマンドは具体的にどれですか ? そして (3) そのコマンドがエラーになる直前にサーバーはどのように構成されていましたか? レポートには (上記の項目 3 を理解しやすくするため)、調査に役立つ最も一般的な SAP HANA トラブルシューティングコマンドのスナップショットがいくつか記載されています。レポートに記載されているコマンド情報の例: crm_mon -A1 HDB proc hdbnsutil -sr_state hdbuserstore list python systemReplicationStatus.py sapcontrol (…) -function GetProcessList 図 1 に示すレポート例に従い、手順 7 で「失敗」をクリックすると、画面は手順7の「Run POST ACTIONS for Scenario CRASH_NODE_PROC_PRE:」の詳細に移動します。 図 4 — エラーが発生したステップの詳細 赤色のステップの前の青色のステップは、エラーが発生する前にシステムで実行されたアクションを示しています。これを使うと、エラーが発生する前のシステム状態を理解できます。 エラー自体は赤色で表示され、何が起きたかを示す追加情報も表示されます。図 5 は、フェイルオーバーイベントの後も PAS が古いノードに接続されたままで、新しいプライマリノードに切り替えなかったことが検出された例を示しています。 図 5 — エラーが強調表示 テストシナリオの量と順序のカスタマイズ このソリューションは 12 のシナリオすべてを実行するように事前に構成されていますが、Ansible に慣れて実行方法を変更したい場合は、目的に合わせてシナリオの数を減らすことができます。そのためには、aws-sap-hana-ha-test/main.yaml ファイルを見つけて、実行したくないブロックにコメントを付けてください。1 番目と 2 番目のブロック (「Check Inputs」と「Check current HA installation (prep / bridge tasks)」) は必須で、常に実行する必要があります。 例えば、単純な「HDB Stop」シナリオだけを実行して解決策を知りたいとしましょう。そうすれば、66 行から最後までのすべての行にコメントできます。 ほとんどのシナリオはスタンドアロンで、さまざまな順序で実行できるため、すべてをカスタマイズできます。唯一の例外は「Crush Instance」シナリオで、その後に「Post Action」シナリオを含める必要があります。そのため、93 行目または 111 行目のクラッシュシナリオを実行している場合は、そのすぐ下のシナリオ (それぞれ 102 行目と 120 行目) にしてください。 次のステップ 始める準備はできましたか?インストール自動化リポジトリに直接アクセスして、ご使用の環境でのテストを開始してください。 テストが完了したら、特定のニーズに合わせてリポジトリをカスタマイズできます。リポジトリのフォルダには README があり、各フォルダがどのように機能してすべてをまとめ、最終的に SAP を実行させるかについての詳細な説明が記載されています。 SAP システムを DevOps モデルに移行する際に専門家によるガイダンスやプロジェクトサポートを求めている場合は、AWS プロフェッショナルサービスグローバル SAP 専門プラクティスが役に立ちます。ハウスサービスや Phillips 66 などの SAP on AWS のお客様が、SAP 変革を加速させるために当社のチームとの連携に投資するケースが増えています。私たちがどのように支援できるかについて詳しく知りたい場合は、 AWS プロフェッショナルサービスチーム にお問い合わせください。 何千ものお客様が AWS for SAP を選択する理由については、 AWSの SAP ページ をご覧ください。 SAP on AWS ディスカッションにご参加ください。 カスタマーアカウントチームと AWS サポートチャネルに加えて、re: POST — AWS コミュニティ向けの最適化された Q&amp;A エクスペリエンスを通じて 私たちとつながることができます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、 re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

1月11日は、 Amazon Elastic Container Service (Amazon ECS) が Amazon Elastic Block Store (Amazon EBS) との統合のサポートを開始し、より広範なデータ処理ワークロードをより簡単に実行できるようになったことを皆さんにお知らせしたいと思います。 AWS Fargate および Amazon Elastic Compute Cloud (Amazon EC2) で実行されている ECS タスクに Amazon EBS ストレージをプロビジョニングでき、ストレージやコンピューティングの管理は必要ありません。 コンテナ化されたパッケージとしてアプリケーションをデプロイすることを多くの組織が選択していますが、Amazon ECS の Amazon EBS との統合の導入により、組織はこれまで以上に多くのワークロードタイプを実行できるようになります。 既存のデータをフェッチし、処理を実行して、処理されたデータをダウンストリームでの使用のために保存する必要がある、ビッグデータの抽出、変換、ロード (ETL) ジョブなど、大量のトランザクションと高スループットをサポートするストレージが必要なデータワークロードを実行できます。ストレージライフサイクルは Amazon ECS が完全に管理するため、インフラストラクチャの更新を管理するために追加のスキャフォールディングを構築する必要がありません。その結果、データ処理ワークロードのレジリエンシーが向上すると同時に、管理に必要な労力も軽減されます。 これからは、Amazon ECS で実行されるコンテナ化されたアプリケーションのためのストレージを、さまざまなオプションから選択できるようになります。 Fargate タスクには、デフォルトで 20 GiB の エフェメラルストレージ が提供されます。大規模なコンテナイメージのダウンロードや、スクラッチ作業のために追加のストレージ容量が必要になるアプリケーションには、Fargate タスク用に最大 200 GiB のエフェメラルストレージを設定できます。 共有データセットに同時にアクセスする必要がある多数のタスクにまたがったアプリケーションの場合は、EC2 と Fargate の両方で実行されている ECS タスクに Amazon Elastic File System (Amazon EFS) ファイルシステムをマウントするように Amazon ECS を設定できます。このようなワークロードの一般的な例には、コンテンツ管理システムなどのウェブアプリケーション、社内 DevOps ツール、および機械学習 (ML) フレームワークが含まれます。Amazon EFS はリージョン全体で利用できるように設計されており、多数のタスクに同時にアタッチできます。 タスク全体で共有する必要がない、高パフォーマンスで低コストのストレージを必要とするアプリケーションの場合は、Amazon EBS ストレージをプロビジョニングして、Amazon EC2 と Fargate の両方で実行されているタスクにアタッチするように Amazon ECS を設定できます。Amazon EBS は、アベイラビリティーゾーン内で低レイテンシーかつ高パフォーマンスのブロックストレージを提供するように設計されています。 詳細については、AWS ドキュメントの「 Amazon ECS タスクでのデータボリュームの使用 」と「 Persistent storage best practices 」を参照してください。 EBS ボリュームの ECS タスクへの統合の開始方法 タスク定義でコンテナのボリュームマウントポイントを設定し、ランタイムで Amazon ECS タスク用の Amazon EBS ストレージ要件を渡すことができます。ほとんどのユースケースでは、タスクに必要なボリュームのサイズを指定するだけで開始できます。オプションで、すべての EBS ボリューム属性と、ボリュームのフォーマットに使用したいファイルシステムを設定できます。 1.タスク定義を作成する Amazon ECS コンソール にアクセスし、 [タスク定義] に移動してから、 [新しいタスク定義の作成] を選択します。 [ストレージ] セクションで [デプロイ時に設定] を選択し、新しい設定タイプとして EBS ボリュームを設定します。Linux ファイルシステムでは、タスクごとに 1 つのボリュームをプロビジョニングしてアタッチできます。 [タスク定義の作成時に設定] を選択する場合は、バインドマウント、Docker ボリューム、EFS ボリューム、 Amazon FSx for Windows File Server ボリューム、または Fargate エフェメラルストレージなどの既存のストレージオプションを設定できます。 これで、タスク定義でコンテナとソース EBS ボリュームを選択し、タスク内でボリュームがマウントされるマウントパスを指定できるようになりました。 $aws ecs register-task-definition --cli-input-json file://example.json コマンドラインを使用して、EBS ボリュームを追加するためのタスク定義を登録することもできます。以下のスニペットはサンプルで、タスク定義が JSON 形式で保存されています。 { "family": "nginx" ... "containerDefinitions": [ { ... "mountPoints": [ "containerPath": "/foo", "sourceVoumne": "new-ebs-volume" ], "name": "nginx", "image": "nginx" } ], "volumes": [ { "name": "/foo", "configuredAtRuntime": true } ] } 2.EBS ボリュームでタスクをデプロイして実行する これで、タスクを ECS クラスターで選択することによって、タスクを実行できるようになりました。ECS クラスターに移動して、 [新しいタスクの実行] を選択します。コンピューティングオプション、起動タイプ、およびタスク定義を選択できることに留意してください。 注意: この例では、アタッチされた EBS ボリュームを使用したスタンドアロンタスクのデプロイを説明していますが、必要に応じて設定された EBS ボリュームを使用するように、新規または既存の ECS サービスを設定することも可能です。 追加のストレージを設定できる新しい [ボリューム] セクションが表示されます。ボリューム名、タイプ、およびマウントポイントは、タスク定義で定義したものです。 EBS ボリュームタイプ 、サイズ (GiB)、IOP、および目的のスループットを選択します。 既存の EBS ボリュームを ECS タスクにアタッチすることはできません。ただし、既存のスナップショットからボリュームを作成する場合は、スナップショット ID を選択するオプションがあります。新しいボリュームを作成する場合は、このフィールドは空白のままにしておくことができます。ファイルシステムのタイプは、Linux の ext3 または ext4 ファイルシステムを選択できます。 タスクが終了すると、Amazon ECS がデフォルトでアタッチされたボリュームを削除します。タスクの終了後に EBS ボリューム内のデータを保持する必要がある場合は、 [終了時に削除] のチェックを外します。また、Amazon ECS がユーザーに代わって API コールを実行できるようにするための関連許可が含まれた、ボリューム管理用の AWS Identity and Access Management (IAM) ロールを作成する必要もあります。このポリシーの詳細については、AWS ドキュメントで インフラストラクチャロール を参照してください。 Amazon マネージドキーとカスタマーマネージドキーのどちらかを使用して、EBS ボリュームで暗号化を設定することも可能です。これらのオプションの詳細については、AWS ドキュメントの「 Amazon EBS 暗号化 」を参照してください。 すべてのタスク設定を完了したら、 [作成] を選択してタスクを開始します。 3.EBS ボリュームでタスクをデプロイして実行する タスクが開始されると、タスク定義の詳細ページでボリューム情報を確認できます。タスクを選択し、 [ボリューム] タブを選択することで、作成した EBS ボリュームの詳細情報を表示します。 チームは、EBS ボリュームの開発と運用をより効率的に整理することができます。例えば、アプリケーション開発者は、利用可能なストレージがあることをアプリケーションが想定するパスをタスク定義で設定でき、DevOps エンジニアは、アプリケーションデプロイ時のランタイムで実際の EBS ボリューム属性を設定できます。 これは、DevOps エンジニアが、開発環境の gp3 ボリュームや本番環境の io2 ボリュームなど、異なる EBS ボリューム設定を使用する異なる環境に同じタスク定義をデプロイすることを可能にします。 今すぐご利用いただけます Amazon ECS の Amazon EBS との統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、および欧州 (ストックホルム) の 9 つの AWS リージョンでご利用いただけます。お支払いいただく料金は、使用分の料金のみです (EBS ボリュームとスナップショットを含む)。詳細については、「 Amazon EBS の料金 」ページと、AWS ECS ドキュメントの「 Amazon EBS volumes 」を参照してください。 この機能をぜひお試しいただき、AWS の Public Roadmap 、 AWS re:Post for Amazon ECS 、または通常の AWS サポートの連絡先を通じてフィードバックをお寄せください。 – Channy P.S.このブログ投稿の執筆に貢献してくれた AWS のシニアエンタープライズデベロッパーアドボケイトである Maish Saidel-Keesing に心から感謝します。 原文は こちら です。

明けましておめでとうございます! クラウドテクノロジー、機械学習、そして生成系 AI の利用はますます簡単になっており、私たちの生活のほぼすべての側面に影響を及ぼしています。Amazon の CTO であるワーナー ヴォゲルス博士は、2024 年以降のテクノロジーについて 4 つの予測を立てています。 生成系 AI が文化を認識するようになる フェムテックがついに実力を発揮する AI アシスタントが開発者の生産性を再定義する 教育がテクノロジーのスピードに合わせて進化する テクノロジーに関するこれらの動向がどのように凝縮され、社会で最も困難な問題の解決に役立つかについては、「 Werner Vogels’ Tech Predictions for 2024 and Beyond 」ebook をダウンロードするか、ヴォゲルス博士の All Things Distributed ブログ をお読みください。 AWS および業界のソートリーダーたちからのインサイトを聞き、スキルを向上させて、インスピレーションを得るには、オンデマンドの AWS re:Invent 2023 動画 で、基調講演、イノベーショントーク、ブレークアウトセッション、および AWS ヒーローガイドのプレイリストを視聴しましょう。 過去数週間のリリース 2023 年 12 月 18 日の 前回の Weekly Roundup 以降の、年末そして先週からのリリースをいくつか取り上げたいと思います。 新しい AWS カナダ西部 (カルガリー) リージョン – カナダで 2 番目の新リージョン、AWS カナダ西部 (カルガリー) が開設されます。2023 年末の時点で、AWS には世界各国に 33 の AWS リージョンと 105 のアベイラビリティーゾーン (AZ) がありました。以前に、マレーシア、ニュージーランド、タイ、および AWS European Sovereign Cloud で開設予定の 4 つのリージョンに追加される 12 のアベイラビリティーゾーンについてお知らせしましたが、2024 年はこれらのリージョンについてより詳しい情報をお伝えしていくので、ぜひご期待ください。 Amazon Route 53 Resolver での DNS over HTTPS – インバウンドとアウトバウンド両方の Route 53 Resolver エンドポイントに DNS over HTTPS (DoH) プロトコルを使用できます。その名の通り、DoH は、HTTP over TLS または HTTP/2 over TLS をサポートして、ドメインネームシステム (DNS) 解決のために交換されるデータを暗号化します。 Amazon RDS 延長サポートへの自動登録 – 2024 年 2 月 29 日から、 Amazon Aurora および Amazon RDS で実行されている MySQL 5.7 データベースインスタンスと PostgreSQL 11 データベースインスタンスが Amazon RDS 延長サポートに自動登録されます。これにより、コミュニティサポートの終了 (EoL) 後にデータベースのメジャーバージョンへのアップグレードを実行するタイミングをよりよく制御できます。 新しい Amazon CloudWatch Network Monitor – Amazon CloudWatch の新機能で、AWS とオンプレミス環境間におけるネットワークの可用性とパフォーマンスのモニタリングに役立ちます。Network Monitor は手動インストルメンテーションが不要で、AWS のネットワークとユーザー独自のハイブリッド環境内の問題をプロアクティブかつ迅速に特定するためのリアルタイムのネットワーク可視性を提供します。詳細については、「 Monitor hybrid connectivity with Amazon CloudWatch Network Monitor 」をお読みください。 Amazon Aurora PostgreSQL の Amazon Bedrock との統合 – 生成系 AI アプリケーションを強化するための Aurora PostgreSQL データベースの Amazon Bedrock との統合には、2 つの方法を使用できます。 Amazon Bedrock との Aurora ML の統合 、および 検索拡張生成 (RAG) のための Knowledge Bases for Amazon Bedrock を用いた Aurora ベクトルストア で SQL クエリを使用できます。 Amazon Lightsail での新しい WordPress セットアップ – ウェブサイト設定の複雑性と設定に費やす時間を排除する新しいワークフローを使用して、 Amazon Lightsail で WordPress ウェブサイトをセットアップします。このワークフローでは、HTTPS でウェブサイトをセキュア化するための SSL 証明書の設定を含めた、必要なステップのすべてを完了することができます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 新年を迎えるにあたり、皆さんにとって興味深いと思われるその他のニュースをいくつかご紹介します。 AWS のエグゼクティブカスタマーにお勧めの本 – 新年の計画を立てて、他の人が何を実行し、何を考えているのかを理解しておきましょう。AWS エンタープライズ戦略チームが、AWS のエグゼクティブカスタマーに読んでいただきたい最も重要な本を推薦します。 プラットフォームエンジニアリングで AWS CDK 導入をスケールするためのベストプラクティス – DevOps における最近の進化は、ワークロードチームをサポートするサービス、ツールチェーン、およびドキュメントを構築するためのプラットフォームエンジニアリングチームの導入です。このブログ記事では、組織内での CDK の導入を促進するための戦略とベストプラクティスを紹介します。プラットフォームエンジニアリングを通じて、パイロットプロジェクトから学んだ教訓を組織全体にスケールする方法を学ぶことができます。 AWS Graviton インスタンスでの HPC アプリケーションの実行による高パフォーマンス – 数値流体力学 (CFD) 問題を解決するために Amazon EC2 Hpc7g インスタンス で Parallel Lattice Boltzmann Solver (Palabos) を実行すると、前世代の Graviton インスタンスと比較して、パフォーマンスが最大 70% 向上し、価格パフォーマンスも最大 3 倍向上しました。 新しい AWS open source newsletter、#181 – すべての最新オープンソースコンテンツをチェックしましょう。今週は、 AWS Amplify 、 Amazon Corretto 、dbt、Apache Flink、Karpenter、LangChain、および Pinecone などが取り上げられています。 AWS の今後のイベント カレンダーを確認して、新年に開催予定の次の AWS イベントにサインアップしましょう。 AWS at CES 2024 (1 月 9～12 日) – AWS が、自動車、モビリティ、輸送、および製造の各業界に特化した最新のクラウドサービスとソリューションを紹介します。 Amazon Experience Area に参加して、生成系 AI、ソフトウェア定義自動車、プロダクトエンジニアリング、サステナビリティ、新たなデジタルカスタマーエクスペリエンス、コネクテッドモビリティ、および自動運転などのさまざまな分野にまたがる最新のクラウド機能について学びましょう。 APJ Builders Online Series (1 月 18 日) – このオンラインカンファレンスは、AWS の中核的なコンセプトと、ステップバイステップのアーキテクチャのベストプラクティスを学ぶために設計されており、AWS の利用を開始し、成功を加速化させるために役立つデモンストレーションも行われます。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの 開発者向けイベント のすべてを閲覧できます。 1月8日週はここまでです。1月15日週に再びアクセスして、新たな Week in Review をぜひお読みください! – Channy この投稿は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Epic Games が開発した Unreal Engine は、フォトリアリスティックなビジュアルや没入感のある体験を作成およびレンダリングするための最も高度なツールの 1 つです。これは最新のゲームとメタバースを強化するために必要です。従来、このような体験には、ディスクリートGPUを搭載した重厚なクライアント、たとえばデスクトップコンピューターが必要でした。Unreal Engine の Pixel Streaming を使用すると、クラウド内のサーバーで Unreal Engine アプリケーションを実行し、レンダリングされたフレームとオーディオを WebRTC を使用してブラウザやモバイルデバイスにストリーミングできます。 AWS と Unreal Engine の Pixel Streaming を使用することで、開発者は Unreal Engine でコンテンツを作成し、それを Windows または Linux 上の Amazon Elastic Compute (EC2) にデプロイできます。この記事では、Unreal Engine アプリケーションを大規模にデプロイする方法に焦点を当てます。つまり、ユーザーのストリーミングリクエストに基づいて EC2 インスタンスを起動および停止できるということです。この記事では、これらの EC2 インスタンスでのユーザーストリーミングセッションの管理についても説明します。 Pixel Streaming コンポーネントの概要 ホスティングとデプロイの観点から、Pixel Streaming ソリューションには 4 つの主要コンポーネントがあります。 ゲームロジックを実行する Unreal Engine アプリケーションパッケージ WebRTCプロトコルを介してクライアントにトラフィックを処理するための シグナリングおよびWebサーバー 、および CoTURN （TURNサーバー用） 複数のゲームインスタンスに負荷を分散し、クライアントとゲームアプリケーション間の接続を処理する マッチメーカーサーバー クライアント (ブラウザ) でパッケージセッションを実行する フロントエンドコンポーネント シグナリングサーバー、CoTurn サーバー、およびUnreal Engine アプリケーションは同じ Amazon EC2 インスタンスでホストできます。インスタンスには、 G4dn などのインスタンスファミリーが提供する GPU 機能が必要です。インスタンスには、CoTURN がクライアントとの WebRTC セッションを維持するためのパブリック IP アドレスも必要で、 パブリックサブネット にデプロイできます。この記事の残りの部分では、この Amazon EC2 インスタンスをシグナリングサーバーと呼びます。 マッチメーカーサーバーは、 プライベートサブネット にデプロイされた別の 汎用 Amazon EC2 インスタンスでホストできます。この記事の残りの部分では、この Amazon EC2 インスタンスをマッチメーカーサーバーと呼びます。 フロントエンドコンポーネントは、プライベートサブネットにデプロイされた別の汎用 Amazon EC2 インスタンスでホストできます。この Amazon EC2 インスタンスをフロントエンドサーバーと呼びます。 これらのコンポーネントがデプロイされると、ユーザーのデバイス (Web ブラウザーなど) からのストリーミングセッションのリクエストにより、次の一連の手順が開始されます。 フロントエンドサーバーはユーザーのリクエストを受け取り、ユーザーのブラウザーに Web ページをレンダリングします。 ユーザーは Web ページ上のボタンを選択してセッションをリクエストし、そのボタンがマッチメーカーサーバーを呼び出します。 マッチメーカーサーバーはユーザーリクエストを受信し、リクエストを処理できるシグナリングサーバーがあるかどうかを確認します。 シグナリングサーバーが使用可能な場合、マッチメーカーサーバーはシグナリングサーバーの詳細をユーザーのブラウザーで実行されている Web ページに送信します。 Web ページは、シグナリングサーバーへの WebSocket 接続を確立します。 シグナリングサーバーは、ストリーマーポートで Unreal Engine アプリケーションパッケージに接続し、ユーザー情報を渡します。 Unreal Engine アプリケーションパッケージは CoTURN を使用してすべてのストリームトラフィックをユーザーのウェブページに転送します。 注:フロントエンドサーバーのデフォルト実装は、シグナリングサーバーと直接通信します (ステップ 5)。マッチメーカーを利用する場合はフロントエンドサーバーを修正してください。 上記の一連の手順では、ストリーミングセッションが単一のユーザーリクエストでどのように機能するかを説明していますが、複数の同時ユーザーセッションリクエストを処理するにはどうすればよいでしょうか。 また、セッションが完了したら、シグナリングサーバーはどうしますか？ 最後に、シグナリングサーバーがユーザーストリーミングリクエストにすぐに対応できない場合はどうなるでしょうか。そのようなシナリオでのユーザーインタラクションの処理方法をはどうすべきでしょうか。 さらに重要なのは、このストリーミングフレームワークを設定する際に、コストとセキュリティをどのように管理するかということです。 ソリューションの概要 このセクションでは、これらの要件を満たすソリューションアーキテクチャを定義することで、これらの質問のいくつかに答えます。まず、ユーザーセッションのリクエストに基づいてシグナリングサーバーを作成できるカスタムの水平スケーリングフレームワークを構築します。スケーリングフレームワークは 2 つの主要コンポーネントで構成されています。 シグナリングサーバーをいつ作成する必要があるかを判断するトリガー シグナリングサーバーを作成するプロセス トリガーは、受信したユーザーセッションリクエストを識別し、そのリクエストを処理できるシグナリングサーバーをマッチメーカーサーバーに確認する必要があります。マッチメーカーサーバーが使用可能なシグナリングサーバーを返すことができない場合、トリガーロジックは新しいシグナリングサーバーの作成を開始します。このオーケストレーションは、ユーザーセッションリクエストで このロジック を実行する AWS Lambda 関数によって行われます。 シグナリングサーバーを作成するプロセスは、 新しい Amazon EC2 インスタンスを起動 し、シグナリングサーバーのコンポーネントをデプロイする AWS Lambda 関数に実装されます。さらに、シグナリングサーバーを アプリケーションロードバランサー (ALB) のターゲットグループに登録して、ロードバランサーの URL を使用してシグナリングサーバーにアクセスできるようにすることができます。 Amazon EventBridge ルールを作成できます。このルールは、シグナリングサーバーの 状態 が「実行中」に変更されたときにトリガーされます。次に、 AWS Lambda 関数を呼び出して、シグナリングサーバーをターゲットグループに登録します。以下の図は同じフローを示しています。 シグナリングサーバーが実行されると、その状態は マッチメーカーサーバーに通知 されます。その後、マッチメーカーサーバーはこのシグナリングサーバーを利用して新しいユーザーセッションリクエストを処理できます。Pixel Streaming の概要で説明したように、マッチメーカーサーバーには、ユーザーセッションリクエストを処理するために利用可能なシグナリングサーバーインスタンスを見つける ロジック があります。さらに、使用中のシグナリングサーバが新しいユーザセッション要求を処理するように選択されないようにします。 シグナリングサーバーはユーザーセッションリクエストに基づいて作成されるため、シグナリングサーバーがリクエストを処理できるようになるまで、リクエストを追跡する必要があります。この要件には、 Amazon Simple Queue Service(SQS) FIFO が適しています。これにより、ユーザーのリクエストを処理する準備ができるまで保存し、先入れ先出し（FIFO）などの何らかの順序付けを適用して、どのリクエストが最初に処理されるかを決定することもできます。トリガーはキューをポーリングして、受信するユーザーセッションリクエストを監視できます。 さらに、シグナリングサーバーがリクエストを処理できるようになったら、その情報をユーザーに中継する必要があります。これで、ユーザーはサーバーを利用してセッションを開始できます。WebSocket 接続はこの要件に適合します。これにより、ユーザーに定期的にポーリングしてシグナリングサーバーの可用性を問い合わせる必要がなくなり、シグナリングサーバーの情報をユーザーに中継できます。 Amazon API Gateway は WebSocket 接続 をサポートしており、AWS Lambda 関数を使用して、WebSocket 接続を介して シグナリングサーバーの詳細をユーザーに送信します、取得されたIPなどの情報からユーザーはシグナリングサーバーに接続 することができます。 次の図は、ユーザー要求を管理するためのキューと WebSocket 接続の使用方法を示しています。 前のセクションでは、AWS Lambda 関数と EventBridge を組み合わせてシグナリングサーバーを ALB ターゲットグループに登録する方法について説明しました。ただし、ALB URLが、ユーザーセッションのマッチメーカーサーバーによって識別された指定されたシグナリングサーバーにトラフィックを転送するようにする必要があります。これを実現するもう 1 つの方法は、ターゲットグループに関連付けられた A LB リスナー内のルール を使用して、固有のクエリ文字列で特定のシグナリングサーバーにアクセスできるようにすることです。このクエリ文字列は、新しく作成されたシグナリングサーバーをALBターゲットグループに登録するときに定義されます。次に、 AWS Lambda 関数がこのクエリ文字列を（WebSocket接続を介して）ユーザーに中継し、ユーザーがセッションの指定されたシグナリングサーバーに誘導されるようにします。 最後に、ユーザーセッションが完了したらシグナリングサーバーをスケールインするメカニズムが必要になります。これを実現するには複数の方法がありますが、1 つの選択肢は、シェル/バッチスクリプトを使用して一定期間後にインスタンスを停止することです。この期間は、ユーザーセッションリクエストが通常どのくらいの期間続くかによって決まります。 たとえば Linux インスタンスの場合、 ユーザーデータ に sudo shutdown -halt +20 を追加すると、20 分後にインスタンスが自動的に停止します。 Amazon EventBridge ルールは、インスタンスの状態が停止状態になったときにトリガーされ、 AWS Lambda 関数を呼び出して インスタンスを終了するように記述 できます。 セキュリティコントロール 送信中の暗号化をサポートするために、マッチメーカーサーバー、フロントエンドサーバー、およびシグナリングサーバーの ALB で HTTPS リスナー を設定できます。これにより、お客様のデバイスとのすべての通信がSSL経由になります。 認証用: フロントエンドサーバーでホストされているアプリケーションを ID プロバイダー (Amazon Cognito など) と統合してユーザーを認証し、 bearer token を Amazon API Gateway に送信できます。 Amazon API Gateway には、WebSocket 接続上のトークンを検証する AWS Lambda 関数 ( AuthorizeClient ) を含めることができます ( ソリューションダイアグラム の項目 #2、3、4)。 マッチメーカーサーバーは、クライアント ID とシークレットを使用して API 呼び出しを認証するように設定できます。 最適化のその他の範囲 マッチメーカーサーバーには、使用可能なすべてのシグナリングサーバーを追跡するためのパーシスタンスレイヤーがありません。これを管理するには、 Redis 用 Amazon ElastiCache のようなものを使用することを検討してください。詳細については、「 Redis 用 Amazon ElastiCache 入門 」の記事を参照してください。 シグナリングサーバーは、認証にトークンを要求するように変更できます。トークンは、フロントエンドからの WebSocket 接続の最初のメッセージとして渡すことができます。これは、 WebSocket 接続の認証パターン を調べることで実現できます。 コスト最適化に関する考慮事項 このソリューションでは、オンデマンドをシグナリングサーバーインスタンスの 購入オプション と見なしています。コストを最適化するために、ストリーミングセッションの完了時にインスタンスを終了するようにスケーリングフレームワークを設定できます。また、任意の時点で実行中のインスタンスの最大数の上限を設定することもできます。そのサンプル実装が リポジトリ に含まれています。 年間を通じて消費量がほぼ一定であれば、シグナリングサーバーのコスト削減の手段として、 Reserved Instances または Savings plans を検討する価値があります。 マッチメーカーとフロントエンドサーバーの場合、それらをコンテナ化して AWS Fargate でホストできるため、需要に応じたスケーリングが可能になります。ただし、これには、使用可能なシグナリングサーバーを追跡するための persistence layer をマッチメーカーサーバーに追加する必要があります。 まとめ この記事では、Unreal Engine Pixel Streaming を Amazon EC2 インスタンスに大規模にデプロイし、AWS のサービスを活用して複数のユーザーにオンデマンドでセッションを提供できるソリューションを構築する方法を示しました。この記事で提案されているソリューションのリファレンス実装は、この リポジトリ でホストされています。これをフレームワークとして使用してソリューションをさらに構築および最適化し、AWS で Pixel Streaming をすぐに使い始めることができます。 Unreal Engine のウェブサイト で Pixel Streaming について詳しく調べてください AWS サービスの詳細は こちら AWS のメタバースソリューション について学ぶ 翻訳はソリューションアーキテクトの嶋田が担当しました。原文は こちら です。

自治体のお客様において、現在ガバメントクラウドの利用検討が進んでいます。ガバメントクラウドを利用するうえでは、さまざまな事業者が分担して作業することが多いです。 例えば、「ネットワーク構築運用補助者」がネットワーク経路を整備し、「運用管理補助者」が運用管理を行う個別領域の上に、「ASP」がシステムを構築します。それぞれの事業者の詳細な役割分担については、 こちらのブログ をご参照ください。 単独利用方式の ASP が複数ある場合に、統合的に環境の統制をする体制を取るケースがあります。そのような場合、個別領域の運用管理補助者とは別に統合運用管理補助者を立てて、統合運用管理補助者がすべての AWS アカウントの統合管理を行います。 このブログでは、統合運用管理補助者が運用管理を行っていく上で気にするべき点や、参照できる資料をまとめました。作業内容の確認などに使っていただけるとうれしいです。 以下のような方を対象として記述しています。 統合運用管理補助者を担う事業者の方 統合運用管理補助者を立てることをご検討されており、詳細を知りたい自治体の方 以下の章で構成されています。 統合運用管理補助者が必要になる場合と担当する事業者について 統合運用管理補助者の役割範囲 マルチアカウントの場合の情報の集約方法 アラートが上がったときの対応について まとめ 免責事項 ガバメントクラウドに関するお問い合わせ 統合運用管理補助者が必要になる場合と担当する事業者について 統合運用管理補助者は、基本的には単独利用方式のアプリケーションが存在し、その上で自治体様に統合運用管理をしたいという意志がある場合に設置されます。全業務のアプリケーションが共同利用方式のみで完結する場合は不要になることが多いと思われます。 また、ネットワーク構築運用補助者がガバメントクラウド全体の運用管理補助業務を担える場合、ネットワーク構築運用補助者が統合運用管理補助業務を兼任することが想定されています。これは、ネットワーク構築運用補助者はもともとガバメントクラウド全体のネットワークを管理することが求められているため、セキュリティについての管理も兼任しやすいからです。 そうでない場合は、いずれかの単独利用運用管理補助者が統合運用管理補助者としてガバメントクラウド全体の運用管理補助業務を担当します。 統合運用管理補助者の役割範囲 統合運用管理補助者の役割範囲は主にインフラストラクチャレイヤーのセキュリティ面での運用管理を行うことです。あくまで参考ですが、例として以下のような業務が存在します。 ガバメントクラウド必須適用テンプレートなどの適用 AWS Config の構成情報を集約して監視、構成管理を行う AWS CloudTrail のログを集約して監視 Amazon Inspector , AWS Security Hub , Amazon GuardDuty などのセキュリティサービスの情報を集約して監視 以上のサービスで不審な動きが確認されたりアラートが発報された場合の対応 必要に応じて、情報が集約されたダッシュボードの作成 必要に応じて、 運用管理補助者兼 ASP 事業者へのガバメントクラウドの使い方の研修や、自治体との情報連携など Amazon CloudWatch などで確認できるアプリケーションレイヤーでのログやアラートの監視は、個々の運用管理補助者が行うことを想定しています。 マルチアカウントの場合の情報の集約方法 複数の AWS アカウントのセキュリティサービスなどの情報を集約するには、 AWS Organizations の機能を使うことが一般的です。しかし、ガバメントクラウドの個別領域はデジタル庁所有の AWS Organizations のメンバーアカウントなので、複数の個別領域の情報を集約するために AWS Organizations の機能を個別に適用できません。複数のアカウントの状況を把握するために、いちいち個別のアカウントから確認するのは大変です。 そのため、AWS Organizations の機能に頼らず情報を集約することが必要です。主に 2 とおりの方法が考えられます。 それぞれのサービスで設定し、個別のサービスにおいて結果を集約する さまざまなサービスの結果を Amazon Simple Storage Service (Amazon S3) にエクスポートし、 SIEM on Amazon OpenSearch Service (SIEM on AWS) を利用する (1) それぞれのサービスにおいて設定する場合 統合管理したいアカウント数が比較的少ない場合、または Amazon OpenSearch Service の費用など SIEM on AWS の利用に必要な費用や実装・運用コストを払いたくない場合は、それぞれのサービスにおいて個別に設定することで AWS の機能を用いて情報を集約できます。 AWS Config では、Config Aggregator を用いることで AWS Organizations に制約を受けず情報を集約可能です。詳しくは、 ドキュメント をご参照ください。 AWS CloudTrail では、Amazon CloudWatch に証跡を送信でき、Amazon CloudWatch Cross Account Observabillity を有効にすることで集約元のすべての CloudWatch ログを集約先アカウントから見られるようになります。詳しくは、 ドキュメント をご参照ください。 Amazon Inspector においては、上記のような自動集約機能がないため、Amazon S3 エクスポート機能を定期的にトリガーするなどして情報を集約する必要があります。詳しくは、 ドキュメント をご参照ください。 AWS Security Hub においては、 こちら の CloudFormation テンプレートなどを用いて結果を Amazon S3 に保存し、それをアカウント間でコピーして情報を集約する必要があります。 Amazon GuardDuty においては、個別に招待することで複数アカウントの検出結果を集約できます。詳しくは、 ドキュメント をご参照ください。 Amazon Detective では、メンバーアカウントを追加することで Organizations に制約を受けず情報を集約可能です。詳しくは、 ドキュメント をご参照ください。 詳しくは、2023 年 12 月 13 日に開催された ウェビナー でもご紹介いたしました。その際の資料や動画は こちら にございますので、ぜひご確認ください。 (2) SIEM on AWS を利用する場合 統合管理したいアカウント数が比較的多く、Amazon OpenSearch Service の費用などを払うことができ、 AWS Cloud Development Kit (AWS CDK) でのデプロイに親しみがある場合、 SIEM on Amazon OpenSearch Service (SIEM on AWS) を活用することが考えられます。 SIEM on AWS は、セキュリティインシデントを調査するためのソリューションです。Amazon OpenSearch Service を活用して、AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化できます。デプロイは、 AWS CloudFormation または AWS CDK で行い、30 分程度でデプロイは終わります。AWS サービスのログを Amazon S3 のバケットに PUT すると、自動的に ETL 処理を行い、SIEM に取り込まれます。ログを取り込んだ後は、ダッシュボードによる可視化や、複数ログの相関分析ができるようになります。 各アカウントのセキュリティサービスから Amazon S3 のバケットに PUT する方法も SIEM on AWS のドキュメント に記載してありますので、ご参照ください。 アラートが上がったときの対応について 統合運用管理補助者が確認すべきアラートとして、以下のようなものがあります。 セキュリティインシデントのアラート (AWS Security Hub, Amazon GuardDuty など) AWS サービス障害情報のアラート ( AWS Personal Health Dashboard など) 一方で、ASP/運用管理補助者が確認すべきアラートとして、以下のようなものがあります。 AWS サービスの CloudWatch メトリクスに関するアラート (CPU 使用率等) アプリケーションのログにひもづくアラート (CloudWatch Logs で確認できるもの) アラートが上がった場合に行う作業の例として、以下のようなものがあります。 原因調査などを実施する 各個別領域の運用管理補助者や ASP と協力し、解決する 必要に応じて自治体に情報連携する 原因調査には、AWS のサービスを利用できます。 Amazon GuardDuty と AWS Security Hub については、「Amazon GuardDuty と AWS Security Hub 利用時のオペレーションガイド」を こちら からダウンロードできます (3 つの資料が連結されており、一番下の資料です) 。 Amazon CloudWatch については、 こちら から初心者向けのハンズオンを体験できます。併せてご覧ください。 障害の発生時に行う作業の例として、以下のようなものがあります。 すみやかに自治体に障害発生状況や復旧の状況などを通知する 原因調査などを実施する 各個別領域の運用管理補助者や ASP と協力し、解決する 必要に応じて、 CSP に連絡する まとめ このブログでは統合運用管理補助者となる事業者様向けに統合運用管理補助者の役割範囲や作業内容についてご説明いたしました。ガバメントクラウドではガバメントクラウド固有の事情や制約などが発生し、初めて触れる事業者様には難しいものとなっているかと思います。そんな中、統合運用管理補助者の作業内容を理解し、複数のガバメントクラウド個別領域全体を安全に運用管理していくためにこのブログをお役立ていただけると大変うれしく思います。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害などの責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承のうえ、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせの他、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/