Datadog

Transcript

2. 2 1 AWS への ワークロードの移行 3 ページ 2 AWS における サーバーレス アプリケーション 19 ページ 3 AWS における コンテナ化された アプリケーション 45 ページ
5. 5 Datadog を使用して AWS 上のワークロードを監視 アマゾン ウェブ サービス（AWS）への移行 AWS に移行するメリット – 使いやすさ – 費用対効果が高く、スケーラブルなプラットフォーム – 耐障害性の高いアプリケーションの構築における柔軟性の向上 クラウド移行の課題 クラウド移行のフェーズ – 既存のインフラストラクチャと組織の準備状況を評価する – チームとリソースを動員する – ワークロードを移行してモダナイズする Datadog を使用して AWS への移行を監視 移行前にサービス間の依存関係を可視化する 移行時に、オンプレミスホストとクラウドホストの高レベルのパフォーマンスを比較する 新しいホストをオンライン後すぐに検出する 新たに移行したサービスをプロアクティブに監視する 移行：要点 参考資料 6 8 8 9 9 10 10 11 11 12 13 14 15 16 17 17 18 18 AWS と Datadog によるクラウドスケールの監視 AWS へのワークロードの移行
6. 6 Datadog を使用して AWS 上のワークロードを 監視 アマゾン ウェブ サービス（AWS）は、グローバル規模の分散型アプリケーションを 構築するために幅広く採用されているクラウドプラットフォームです。オンプレミス のワークロードを AWS に移行することで、包括的な一連のサービスを活用して、耐 障害性および費用対効果の高いアプリケーションを構築できるようになります。チー ムでは、フルマネージドサービスを使用して既存のリソースを最適化し、アプリケー ションを再構築して、コンテナによって独立したマイクロサービスにワークロードを 分離できます。加えて、クラウドを使用してサーバーレスアプリケーションを構築す ることで、物理サーバーへの依存度を下げ、運用コストをさらに削減できます。 AWS は、このようなタイプのインフラストラクチャのサポートや、クラウドへの容易 なワークロード移行に必要なサービスを提供します。Amazon Elastic Compute Cloud （Amazon EC2）を使用して環境のホスティング構成やリソースのコントロールを強 化することも、AWS Lambda や AWS Fargate などのサービスを活用してサーバーレ スコードやコンテナを自動管理することもできます。また、AWS ではコンテナオー ケストレーターとして、Amazon Elastic Kubernetes Service（Amazon EKS）または Amazon Elastic Container Service （Amazon ECS） を選択できます。 オーケストレーター はそれぞれ、他の AWS サービスと緊密に統合され、フルマネージドアプリケーション の容易な構築を可能にします。
7. 7 本 eBook では、AWS へのワークロード移行に伴うメリットと複雑さのほか、コンテ ナやサーバーレスコンピューティング向けに AWS で提供しているサービスについて 詳しく説明します。また、ワークロードが効率的に実行されているか確認するために 追跡できる、 各サービスの主要なパフォーマンスメトリクスについても取り上げます。 最後に、Datadog のような監視ソリューションを使用することで、AWS への移行の 各段階のほか、各 AWS サービスのパフォーマンスについても容易に追跡できること を解説します。アプリケーションリソースをクラウドに移行する際に Datadog を使用 すれば、データベース、API、コンテナ、サーバーレス関数などの依存関係を可視化し、 オンプレミスのホストから AWS に流れるデータをシームレスに監視できるようにな ります。
8. 8 アマゾン ウェブ サービス （AWS）への移行 AWS のようなクラウドプラットフォームは、オンプレミスのインフラストラクチャか らアプリケーションやワークロードを移行する際に、独自のメリット（および課題） をもたらします。移行を成功させるには、既存のワークロードの状態とその依存関係 を評価するだけでなく、要件を満たした候補（データベース、ホスト、ワークロード など） の最適な移行パスを判断する必要もあります。AWS では、 移行プロセスをスムー ズに進めるための戦略がいくつか提供されており、Datadog を使用すると、プロセス の各ステップを監視できるようになります。 AWS に移行するメリット クラウド移行の主な要因として、組織で検討されることが多いのは、以下のとおりで す。 – コスト削減またはコストコントロールの向上 – チームの俊敏性と生産性の向上 – 耐障害性とセキュリティの高いアプリケーションの構築 – 運用責任のクラウドへの移行 – ハードウェアやソフトウェアのサポート終了の到来 – データセンターや他のアプリケーションリソースの統合 – 旧式のサービスの入れ替えを目的としたデジタルテクノロジーの導入 – グローバル規模のアプリケーションのデプロイ – 最先端テクノロジーへのアクセス
9. 9 AWS は、クラウドへのワークロード移行に対するこうした動機に対処するために、 アプリケーションをデプロイおよび管理するための使いやすいツール、アプリケー ションリソースを最適化する費用対効果の高いプラットフォーム、そしてワークロー ドの複雑さに関係なく、耐障害性が高く、スケーラブルなアプリケーションをオンデ マンドで構築するための幅広いフルマネージドサービスを提供しています。 使いやすさ AWS では、新規アプリケーションの構築や既存アプリケーションへの機能実装を行う 方法として、 AWS マネジメントコンソール、 一連のサービス API、 AWS コマンドライン インターフェイス（AWS CLI）の 3 つを提供しています。 ユーザーフレンドリーなコンソールを活用すれば、200 以上の AWS サービスに対し、 作成、設定、デプロイを 1 か所で行うことができます。AWS が提供するあらゆる種類 の製品をサポートする包括的な API セットにより、既存のアプリケーション機能にプ ログラムを使ってサービスを統合したり、AWS プラットフォームでアプリケーション 全体を構築したりすることが可能になります。また、AWS CLI を使用すれば、ターミ ナルプログラムから AWS サービスを操作できるため、アプリケーション管理の柔軟 性が大幅に高まります。AWS では、必要に応じたリソースのスピンアップが可能なた め、本番環境に対応したアプリケーションやサービスを容易にデプロイできます。 費用対効果が高く、スケーラブルなプラットフォーム 総所有コスト（TOC）の計算式は、組織が新しい IT システムやリソースの直接 / 間接 コストを評価するのに役立ちます。ユースケースに応じて、 これには、 サーバー（ハー ドウェア、OS、仮想化など） 、ストレージ、インフラストラクチャのネットワークや データセンター、人件費といった運用 / メンテナンスのコストを織り込むことができ ます。 クラウドプロバイダーに移行する際には、 新しいプラットフォームでアプリケー ションやインフラストラクチャの運用に関連するコスト削減を確実に実現する必要が あります。 AWS では、リソースに応じた従量課金制モデルを提供しているため、使用した分だけ 料金を支払えばよく、インフラストラクチャの管理コストを全体的に削減できます。 さらに、多くの AWS サービスでは、需要に基づいて自動的にリソースをスケーリン グしてくれるため、 ビジネス目標を達成するために必要な分のみをスピンアップでき、 容量を無駄にせずに済みます。つまり、より多くのアプリケーションサービスをクラ ウドに移行し、サードパーティ製ツールやカスタムツールの依存度を下げ、チームの 俊敏性、スピード、生産性を向上させることができるということです。
10. 10 耐障害性の高いアプリケーションの構築における柔軟性の向上 AWS では、EC2 インスタンスの OS や AWS Lambda 関数のプログラミング言語など、 インフラストラクチャを構成するコンポーネントに対するコントロールを向上させる ことができます。これにより、アプリケーションの設計と構築において、よりきめ細 かなカスタマイズオプションを得られます。たとえば、Go アプリケーションを構築 している場合は、AWS SDK for Go を使用すれば、Amazon DynamoDB、Amazon S3、 Amazon EKS などの AWS サービスとアプリケーションを容易に統合できるようにな ります。 また、多くの AWS サービスはフルマネージドサービスのため、ハードウェアやソフ トウェアのパッチ適用について心配する必要がありません。さらに開発環境を中断す ることなく、移行を達成できます。AWS は 24 の異なる地域にわたる 76 のアベイラ ビリティゾーンをサポートしているため、AWS を使用すれば、グローバル規模の高可 用性アプリケーションを構築できます。いずれかのアベイラビリティゾーンでアプリ ケーションコンポーネントの障害が発生しても、トラフィックを別のゾーンに容易に ルーティングできるため、顧客は継続してアプリケーションを利用できます。 クラウド移行の課題 ワークロードを AWS に移行する際には、移行プロセス全体の摩擦を減らすために、 エンドツーエンドの可視化が必要になります。アプリケーションサービスがオンプレ ミスとクラウドの両方のリソースに配置されるハイブリッド環境では、 特に必要です。 エンドツーエンドで可視化できない場合は、移行によってワークロード監視に死角が 生じ、コストのかかるシステム停止やその他のパフォーマンスインシデントにつなが る可能性があります。また、移行が完了したら、問題のトラブルシューティングや顧 客向けアプリケーションの可用性確保のために、シームレスにアプリケーションの監 視を継続し、各 AWS サービスから主要なパフォーマンスメトリクスを追跡できるよ うにすることが重要となります。 クラウド移行においては、特に移行する必要のあるワークロードを判断する場合、事 前にコストがかかることもあります。移行プロセス中にアプリケーションに何らかの 変更を加えると、多くの場合、既存のワークロードをサポートするのに適切なツール があるか確認するために、最初に多くの時間と資金を投入する必要があります。たと えば、新しいクラウドサービスを活用して相互運用性を確保するために、既存のアプ リケーションアーキテクチャやインフラストラクチャの一部または全部のリファクタ リングが必要な場合や、モノリシックなアプリケーションを複数の異なるマイクロ サービスに分割する場合が考えられます。このような場合は、新しいクラウドインス タンス、コンテナ、ストレージ、API、関数などへの先行投資が必要になります。
11. 11 アプリケーションをクラウドに移行する際の 2 つ目の課題は、新しいシステムや慣れ ないツールにより、安定していた開発環境やプロセスに混乱が生じることです。新し いクラウドテクノロジーとプロセスについてチームメンバーのトレーニングを実施す ることは、スムーズな移行を実現する上で重要な役割を果たします。チームの目標や 帯域幅に合った移行計画が確立されていないと、クラウドサービスの利用や移行プロ セスの複雑さに慣れていないメンバーがいる場合は特に、 チーム（およびリーダー層） の賛同を得ることが難しくなります。 チームに共通する懸念事項として、新たに移行したサービスのセキュリティを確保す ることが挙げられます。クラウドプラットフォームには、セキュリティロール、ポリ シー、パーミッション設定の複数のレイヤーがあります。新たに移行したサービスの セキュリティを適切に確保しないと、機密情報が流出するリスクにさらされます。ま た、適切なセキュリティポリシーを策定しないと、移行したサービスに対して、チー ムからアクセスや作業ができなくなる可能性があります。 クラウド移行のフェーズ ここまで、クラウドへの移行のメリットと課題について説明してきましたが、次にク ラウドへの移行を始めるにあたっての注意点を見ていきます。クラウド移行には慎重 な計画が必要です。AWS では、移行をサポートするために、 「評価」 「モビライズ（動 員） 」 「移行とモダナイゼーション」の 3 フェーズの移行プロセスを推奨しています。 このプロセスに従うことで、確実に移行を成功させることができます。 既存のインフラストラクチャと組織の準備状況を評価する 移行の第 1 フェーズでは、オンプレミスの既存リソースと、AWS への移行に向けて の組織の準備状況を評価します。AWS では、サービスをクラウドに移行する際のコ ストや価値を判断するのに役立つさまざまなツールを提供しています。たとえば、 Migration Evaluator と Cost Explorer は、既存のオンサイト IT リソース（ネットワー クハードウェア、ストレージ、帯域幅など）を維持した場合と、クラウドへ移行した 場合の初期費用と毎月のコストを比較するのに役立ちます。また、AWS で提供してい る AWS Cloud Adoption Framework（AWS CAF）を使用すれば、移行プロセスの次の フェーズに対する組織の準備状況を評価できます。
12. 12 チームとリソースを動員する モビライズ（動員）フェーズでは、AWS への移行に向けて、チーム、ツール、文化、 プロセスの準備を整えます。このフェーズでは、詳細なポートフォリオの発見を行え ます。既存インフラストラクチャのリソースと依存関係を調べることで、リソースの 動員に向けて、以下のような最適な候補を特定できます。 – 利用を停止する必要があるレガシーシステム – スループットは低いが、多くのコンピューティングリソースを使用している ため、費用対効果が見込めないアプリケーション – 依存関係が少ないため、移行が容易なアプリケーション – 拡大する顧客基盤をサポートするために迅速なスケーリングが必要なアプリ ケーション – グローバル規模のアプリケーションをサポートする必要があるサービス 要件を満たす候補を特定したら、それらの移行に最適な戦略を決定する必要がありま す。たとえば、レガシーシステム / アプリケーションは、クラウドに移行するのでは なく、単にリタイアさせた方が適切なこともあります。こうすることで、クラウドプ ラットフォームへの移行が必要なアプリケーションに焦点を絞ることができます。 ほかにも、以下のような共通戦略があります。 – リホスト：クラウドの最適化を行わずに、サービスをクラウドに移行（また はインポート）する（例：Oracle Database を、Amazon EC2 インスタンス上 の Oracle に移行する） – リプラットフォーム：オンプレミスのサービスをマネージドサービスに移行 する（例：オンプレミスのデータベースを Amazon DynamoDB に移行する） – リファクタリング：クラウドの機能を活用するためにアプリケーションサー ビスを再設計する（例：モノリシックアプリケーションのリファクタリング を行い、コンテナ化されたアーキテクチャを使用する） – リロケート：構造を変えずに、仮想化されたアプリケーションを AWS に移行 する
13. 13 クラウドへの移行には、チームのワークフローにおいて大きな変化を伴うため、移行 のためにリソースを動員することに加え、移行に向けて組織の準備を整えることが非 常に重要です。 チームの動員には、 組織の移行をスムーズに進めるために、 リスク軽減、 トレーニング、コミュニケーションといった領域の戦略を策定することが含まれる場 合があります。既存のインフラストラクチャやビジネスニーズに対して、どの戦略が 最も有用かを評価することが重要です。 最初に概念実証を構築することは、 ビジネスに不可欠なワークロードを移行する前に、 AWS サービスをテストして慣れるのに役立ちます。 戦略によっては、 アプリケーション だけでなく、アプリケーションデータも新しいクラウドベースのサービスに移行する ことが含まれている場合があります。たとえば、バックアップやファイルサーバーを Amazon S3 に移行することを検討できます。 しかし、 アプリケーション全体とそのデー タを一度に移行することには、 顧客向けサービスの停止のほか、 予期せぬパフォーマン ス問題が生じるリスクが伴います。こうしたリスクを軽減するために、時間をかけて 移行を展開し、AWS サービスの十分なテストを行うまでは、アプリケーションの特定 の部分だけをクラウドに移行することになる可能性もあります。これにより、アプリ ケーションコンポーネントを安全に移行し、それらを 1 つずつ最適化できます。 ワークロードを移行してモダナイズする 移行の最終フェーズでは、要件を満たすワークロードを移行し、それらを運用するた めに AWS で提供されている機能を活用します。AWS では、ワークロードの最適化、 自動スケーリング、プロビジョニング、保護のためのサービスがいくつか提供されて います。たとえば、CloudEndure Migration は、物理環境、仮想環境、その他のクラ ウド環境から AWS への迅速なリソース移行を可能にします。 新たに移行したサービスについては、AWS CloudFormation を使用すれば、コードと してインフラストラクチャを構築し、デプロイとアップグレードを自動化できます。 また、AWS ではさまざまなセキュリティポリシー、パーミッション、ロールを提供し ているため、クラウドサービスのセキュリティコントロールを向上させることができ ます。たとえば、チーム向けに多要素認証を実装する、チームベースのセキュリティ ポリシーを作成して S3 バケットなどの特定の AWS リソースへのアクセスを制限す る、データを自動的に暗号化する、といったことが可能です。 慎重に計画を策定することで、重要なアプリケーションのワークロードの移行を成功 させることができます。
14. 14 Datadog を使用して AWS への移行を監視 サービスの実行場所を問わず、移行する際には、サービスのパフォーマンスを可視化 することが重要となります。Datadog は、オンプレミス環境、ハイブリッド環境、ク ラウド環境からデータを収集し、移行プロセス全体ですべてのサービスを監視できる ようにします。
15. 15 Datadog を使用すると、クラウドへの移行に適したサービスを評価し、新たに移行し たホストをスピンアップ後すぐに監視できるほか、オンプレミスとクラウドのサービ ス間のパフォーマンスを容易に比較することも可能になります。また、Datadog の機 能は相互に緊密に統合されているため、たとえば分散トレースから関連ログやインフ ラストラクチャのメトリクスに至るまで、あらゆるデータポイント間でピボットし、 トラブルシューティングのための豊富なコンテキストを取得できます。さらに、移行 プロセス全体にわたってすべてのサービスのワークロードパフォーマンスを追跡する ための専用ダッシュボードを構築することも、パフォーマンスの異常を通知するア ラートを作成することもできます。 移行前にサービス間の依存関係を可視化する 前述したように、まず既存アプリケーションのワークロードを評価して、要件を満た す移行候補を特定することが非常に重要となります。Datadog のサービスマップを使 用すると、アーキテクチャのコンポーネントとそれぞれの依存関係を可視化できるよ うになるため、どのサービスをクラウドに移行できるかについて、多くの情報に基づ いて判断することが可能になります。たとえば、サービスマップでアプリケーション データベースの依存関係があまりにも多ければ、ワークロードを中断せずに安全にク ラウドに移行できないと判断できます。
16. 16 移行時に、オンプレミスホストとクラウドホストの 高レベルのパフォーマンスを比較する Datadog のホストマップを使用すると、CPU の使用率やリクエストのスループットな ど、ホストの主要なパフォーマンスメトリクスの高レベルビューを得られます。これ により、 過少または過剰にプロビジョニングされているリソースを容易に特定し、 オン プレミスのホストと、移行先の新たなホストのパフォーマンスを比較できます。たと えば、ホストマップを使用すれば、オンプレミスのサービスと Amazon EC2 インス タンスに （ 「リホスト」 などで） 移行したサービスのパフォーマンスを比較できるため、 概念実証を行って AWS サービスをテストした上で、残りのワークロードの移行につ いて判断することが可能になります。 Datadog は自動的に、 オンプレミスのすべてのホストから「host」や「service」といっ たタグを取得し、 AWS サービスから 「availability zone」 や 「autoscaling_group」 といっ たインフラストラクチャタグを取得するため、オンプレミス環境やクラウド環境全体 で特定のリソースを検索してドリルダウンできます。
17. 17 新しいホストをオンライン後すぐに検出する ワークロードを AWS に移行する主なメリットは、プロビジョニングとスケーリング の機能を活用できることです。 AWS では、 需要に応じてリソースを自動的にスケーリン グし、Datadog を使用してそうしたリソースをスピンアップ後すぐに監視できます。 ライブコンテナの監視機能を使用すると、すべての Kubernetes クラスターと、EKS または ECS でホスティングされている個々のコンテナのステータスとパフォーマンス をリアルタイムで把握できます。Datadog は 2 秒の解像度でリソースメトリクスを収 集するため、コンテナ環境の最新の状態を継続的に把握できます。 新たに移行したサービスをプロアクティブに 監視する 移行の最終フェーズにおいて、AWS の機能をさらに活用してワークロードのプロビ ジョニング、最適化、セキュリティ保護を行うには、オンプレミスや新たに移行した サービスを完全に可視化する必要があります。Datadog では、以下のようなコア機能 を提供しており、サービスをさらに AWS に移行する際も、継続してインフラストラ クチャを監視できます。 – Datadog Agent：あらゆる環境のホストやアプリケーションから、メトリク ス、プロセスデータ、ネットワークパフォーマンスデータ、トレースデータ、 ログを収集する – AWS インテグレーション：AWS のすべてのサービスについて、Amazon CloudWatch を通じてサービス固有のメトリクスとログを収集する – Synthetic 監視：API テストと UI テストを通じてアプリケーションの機能性 を検証する – ログ管理：ログを一元的に監視および分析する。ログは Amazon S3 にアーカ イブできる インフラストラクチャをデプロイするための新しいワークフローに、Datadog を容易 に統合できます。たとえば、AWS CloudFormation を使用して、運用監視データを自 動的に Datadog に送信するインフラストラクチャリソースをデプロイおよび構成でき ます。また、Datadog を使用すれば、AWS 固有の脅威検出ルールによって、新たに 移行したサービスをセキュリティで保護できるため、AWS IAM ユーザーの不審なログ イン操作、EC2 インスタンスへの DoS 攻撃、S3 バケットへのポリシー変更といった 問題を検出できるようになります。
18. 18 移行：要点 これまで、AWS に移行して費用対効果および耐障害性の高いアプリケーションを構築 することで得られるメリットのほか、サービスをクラウドに移行する際の課題を説明 してきました。重要なのは、ワークロード移行時の予期せぬパフォーマンス問題を軽 減できるように、 移行戦略を策定することです。 そして、 移行プロセスを開始した後は、 クロスプラットフォームの可視化が、移行を成功させるための鍵となります。 レガシーアプリケーションとその依存関係についての理解を深められるように、移行 前にオンプレミスインフラストラクチャの状態を可視化し、各リソースのパフォー マンスを詳しく把握できる Datadog の機能についても紹介しました。リソースを移行 する際には、Datadog を使用すれば、AWS でのスピンアップ後すぐにリソースを監視 できます。移行後も、残っているオンプレミス環境と、AWS　でホスティングされて いる新しいインフラストラクチャの両方のパフォーマンスを引き続き監視できます。 ホストマップ / サービスマップやライブコンテナ監視などの Datadog 機能を使用する ことに加え、環境のパフォーマンス異常を通知するためのアラートを作成することも 可能です。また、Synthetics を使用すると、新たに移行したアプリケーションの機能 を検証するためのブラウザテストを構築できます。Datadog の広範な機能セットによ り、移行のすべてのフェーズにおいて、あらゆるリソースを監視できるようになりま す。 参考資料 移行の監視に関する詳細については、以下のガイドを参照してください。 – Ensuring successful cloud migrations with cross-platform visibility from Datadog（Datadog のクロスプラットフォーム可視化機能でクラウド移行を 確実に成功させる） – Key metrics for AWS monitoring (AWS を監視するための重要なメトリクス ) – Datadog's 1-click integration for AWS（Datadog の AWS 向けワンクリック統 合） また、AWS へのワークロード移行に関するこれらの監視戦略を実践したい場合は、 www.datadog.com において、Datadog のフル機能を利用できるトライアル版をお申 し込みください。
21. 21 22 23 23 33 33 34 34 35 35 36 38 39 40 43 44 AWS におけるサーバーレスアプリケーションの監視 AWS Lambda – AWS Lambda の監視方法 Amazon API Gateway – API Gateway の監視方法 AWS Step Functions – AWS Step Functions の監視方法 AWS Fargate – AWS Fargate の監視方法 Datadog を使用して AWS サーバーレスプラットフォームを監視 – サーバーレスメトリクスを可視化する – サーバーレスログを 1 か所で検索および分析する – Datadog APM を使用してトレースデータを調査する – サーバーレスエコシステムを完全に可視化する 参考資料 AWS と Datadog によるクラウドスケールの監視 AWS におけるサーバーレスアプリケーション
22. 22 AWS におけるサーバーレス アプリケーションの監視 サーバーレスアーキテクチャを採用することで、サーバーのプロビジョニングや管理 など、アプリケーションに関する従来のオペレーションの責任をチームからクラウド へ移行できます。クラウドプロバイダーは、インフラストラクチャのリソースを管理 し、必要に応じてそれらを利用してサーバーレスコードをデプロイする責任を担うよ うになりつつあります。サーバーレスをアプリケーションに活用することで、常時稼 働するアプリケーションリソース（サーバー容量、ネットワーク、セキュリティパッ チなど）の支払いや管理が不要になるため、費用対効果が高くなります。課金される のは、 関数に使用するリソースに対してのみです。また、 サーバーレスアーキテクチャ は、需要に応じて容易にスケーリングすることもできます。 サーバーレスアーキテクチャを使用してワークロードを実行すると、監視に関する新 たな課題が生じます。サーバーレスアプリケーションは、従来のハードウェア上で実 行されるものとは根本的に異なります。一例として、一般的なシステムメトリクスを 収集できないことが挙げられます。しかし、サーバーレス関数のパフォーマンスを監 視するために、運用監視データの収集が重要であることは変わりません。たとえば、 AWS Lambda 関数は、同時実行数の上限と割り当てメモリによってコントロールされ ます。上限を超えると、関数がタイムアウトするか、ランタイムによって強制終了と なります。 こうしたシナリオの一部のほか、 AWSのサーバーレスツールプラットフォー ムを監視するための主要なメトリクスを紹介します。取り上げるプラットフォームは 以下のとおりです。 – AWS Lambda – AWS Fargate – Amazon API Gateway – AWS Step Functions
23. 23 また、Datadog を使用することで、どのようにサーバーレスアーキテクチャ全体を 1 か所で監視できるようになり、AWS のサーバーレスツールのパフォーマンスに関する 知識を深められるかについても説明します。 AWS Lambda AWS Lambda は、AWS サーバーレスプラットフォームの中心となるコンピュートサー ビスであり、サーバーレスコードを関数としてデプロイします。関数はイベント駆 動型であり、メッセージキュー、ファイルのアップロード、HTTP リクエスト、cron ジョブなどのイベントでトリガーできます。Lambda 関数は、Amazon API Gateway からの API コールや DynamoDB テーブルへの変更など、別の AWS サービスからのイ ベントを使用してトリガーすることが可能です。サービスが初めて関数を呼び出し たときに、関数のランタイムとハンドラーメソッドが初期化されます。AWS Lambda はさまざまなランタイムをサポートしているため、好みのプログラミング言語（Go、 Python、Node.js など）で関数を記述し、同一環境内でそれらを実行できます。 AWS Lambda の監視方法 AWS Lambda はユーザーに代わってインフラストラクチャのリソースを管理するた め、ユーザーは CPU 使用率などの一般的なシステムメトリクスを取得することはで きません。その代わり、Lambda は関数を実行したときのパフォーマンスと効率をレ ポートするため、 関数を監視すれば、 関数の使用率、 呼び出し、 同時実行数（プロビジョ ニング済み同時実行数を含む）を追跡できます。 主要関数のパフォーマンスと使用率のメトリクス Lambda は、関数が使用されている時間（パフォーマンス）と、呼び出し中に関数が 使用するメモリの量（使用率）を自動的に追跡します。このデータを監視することで、 関数を最適化し、コストを管理できます。関数使用率のメトリクスは、以下のログの 例で示すように、CloudWatch のログに含まれています。 ``` REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9 Duration: 72.51 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 58 MB Init Duration: 2.04 ms ```
24. 24 期間と課金期間：関数の実行時間（期間）を監視することで、どの関数を最適化でき るか（または最適化すべきか）を判断できるようになります。コードの実行に時間が かかる理由としては、コールドスタート（非アクティブな Lambda 関数のレスポン ス時間における初期遅延） 、過度に複雑なコードのほか、サードパーティや他の AWS サービスを利用する関数の場合はネットワークレイテンシーなどが挙げられます。 Lambda では、総実行時間を 15 分に制限しており、制限時間に達すると、関数を終 了してタイムアウトエラーを発行します。このため、期間を監視することで、このし きい値に達するタイミングを確認できるようになります。 課金される期間は、100 ミリ秒単位で切り上げられた実行時間に基づきます。課金期 間は、関数のメモリサイズと共に、AWS Lambda の価格設定のベースとなります。こ れについては、後述します。 関数の期間とその課金期間を比較して、実行時間を短縮してコストを削減できるかど うかを確認できます。たとえば、以下の関数のログを見てみましょう。 ``` REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9 Duration: 102.25 ms Billed Duration: 200 ms Memory Size: 128 MB Max Memory Used: 120 MB Init Duration: 2.04 ms ```
25. 25 関数の期間（Duration）は 102 ミリ秒ですが、 支払いは 200 ミリ秒の課金期間（Billed Duration）に基づきます。期間が一定している場合は（約 102 ミリ秒など） 、期間と 課金期間を短縮するためにメモリを追加できることがあります。たとえば、関数の メモリを 128 MB から 192 MB に増やして期間が 98 ミリ秒になれば、課金期間は 100 ミリ秒になります。これはつまり、課金期間の対象ブロックが 200 ミリ秒ではなく、 100 ミリ秒になるため、課金額が少なくなるということです。簡単な例を紹介しまし たが、特に何百もの関数にまたがる大量のリクエストを管理している場合、この 2 つ のメトリクスを監視することは、関数のコストを理解する上で重要です。 メモリサイズと最大使用メモリ：関数の期間と課金期間は、関数に割り当てられてい るメモリ量によって部分的な影響を受けます。実行に時間がかかる場合は、リクエス トを処理するのに十分なメモリがない可能性があります。また、関数で必要な量より も多くのメモリを割り当ててしまう場合も考えられます。いずれの場合もコストに影 響するため、メモリ使用量を追跡することで、処理能力と実行時間のバランスを取る ことができます。関数には、AWS Lambda クォータの範囲内でメモリを割り当てるこ とができます。Lambda ログでは関数のメモリサイズと記述されます。 以下のように、CloudWatch のログで、関数のメモリ使用量とその割り当てメモリを 比較できます。 ``` REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9 Duration: 102.25 ms Billed Duration: 200 ms Memory Size: 512 MB Max Memory Used: 58 MB Init Duration: 2.04 ms ``` 関数で使用しているメモリ（Max Memory Used）が、割り当てられたメモリのごく一 部であることがわかります。この状況が続いている場合は、関数のメモリサイズを調 整してコストを削減することをお勧めします。一方、関数のメモリ使用量が常にメモ リサイズに達している場合は、受信したリクエストを処理するのに十分なメモリがな いため、実行時間が長くなります。 主要な関数呼び出しメトリクス Lambda 関数は、同期、非同期、イベントソースマッピング経由の 3 つの方法のいず れかで呼び出すことができます。 同期サービスでは、イベントを作成し、それを Lambda が直接関数に渡し、関数がレ スポンスを返すのを待ってから結果をサービスに戻します。 これは、 アプリケーション のワークフローにおいて、次のステップに移る前に関数の結果が必要な場合に役立ち ます。エラーが発生した場合は、最初に Lambda にイベントを送信した　AWS　サー ビスが呼び出しを再試行します。
26. 26 非同期の呼び出しでは、サービスが関数を呼び出すとすぐに呼び出しイベントを手放 して、Lambda がそれをキューに追加します。サービスは、イベントが正常にキュー に追加されたというレスポンスを受け取るとすぐに次のリクエストに移ります。非同 期の呼び出しは、 Lambda によるリクエスト処理が終了するまで待つ必要がないため、 サービスの待ち時間を短縮するのに役立ちます。タイムアウトや関数コードの問題が 生じて、関数からエラーが返される場合、Lambda はイベントの処理を最大 2 回再試 行し、 それでもエラーが返されるときはそのイベントを放棄します。Lambda はまた、 関数の同時実行数がイベントを処理するのに十分ではない場合に、イベントをキュー に戻し、エラーを発生させることもあります。 さらに、ユーザーはイベントソースマッピングを使用して、Amazon Kinesis や DynamoDB ストリームなどのイベントソースを Lambda 関数にリンクさせることも できます。マッピングは、Lambda 関数のトリガーとして機能するようにデータスト リームやキューを構成するリソースです。たとえば、Kinesis のデータストリームを 関数にマッピングすると、Lambda ランタイムは、ストリーム内のシャード（レコー ドのシーケンス番号）からイベントのバッチ（レコード）を読み取り、それらのバッ チを関数に送信して処理します。デフォルトでは、エラーを返してバッチを処理でき ない関数の場合は、バッチが成功するか、またはバッチ内のレコードが期限切れにな るまで（データストリームの場合） 、バッチを再試行します。レコードの処理中に関 数が停止しないようにするために、イベントソースマッピングを作成する際に、再試 行回数、バッチ内のレコードの最大有効期間、バッチサイズを設定できます。 これらの呼び出しメソッドはそれぞれ、すべての呼び出しタイプに適用される標準的 なメトリクスに加え、監視すべきメトリクスが異なります（呼び出し回数やイテレー ター経過時間など） 。 呼び出し回数：呼び出し回数を監視することで、アプリケーションのアクティビティ や関数の全体的なパフォーマンスを把握できるようになります。呼び出し回数に異常 な変化が生じた場合は、関数のコードか、接続されている AWS サービスのいずれか に問題があることを示している可能性があります。たとえば、関数のダウンストリー ムサービスが停止した場合、複数回の再試行が強制的に行われ、関数の呼び出し回数 が増える可能性があります。 さらに、関数が複数のリージョンに配置されている場合は、呼び出し回数を使用して、 関数が最小限のレイテンシーで効率的に実行されているかどうかを判断できます。た とえば、どの関数がどのリージョンで最も頻繁に呼び出されているかを素早く確認 し、それらを別のリージョンやアベイラビリティゾーンに移動させる必要や、レイ テンシーを改善するために負荷分散を変更する必要があるかどうかを評価できます。 Lambda@Edge のようなサービスは、顧客に近いリージョンでコードを自動的に実行 することでレイテンシーを改善できます。
27. 27 イテレーターの経過時間：ストリームベースの呼び出しの場合、Lambda はイテレー ター経過時間のメトリクスを発行します。イテレーター経過時間とは、バッチの最後 のレコードがストリーム （Kinesis、 DynamoDB など） に記述されてから Lambda がバッ チを受信するまでの間の時間です。これにより、ストリームに記述されているデータ 量が多すぎて関数が処理しきれない場合を把握できるようになります。 イテレーター経過時間が長くなるシナリオがいくつかあります。 – 関数の実行期間が長い – ストリーム内のシャード数が十分ではない – 呼び出しエラーがある – バッチサイズが不足している イテレーター経過時間が増えている場合、関数がデータのバッチを処理するのに時間 がかかりすぎて、アプリケーションに未処理イベントの大量のバックログが構築され ている可能性があります。 イテレーター経過時間を短縮するには、Lambda 関数がレコードをバッチで処理する のにかかる時間を減らす必要があります。処理時間が長い原因として、関数が効率的 に動作するのに十分なメモリがないことが考えられます。関数に割り当てるメモリ量 を増やすか、関数コードを最適化する方法を見つけることをお勧めします。
28. 28 バッチ処理可能な最大レコード数を決定するストリームのバッチサイズを調整するこ とで、場合によってはイテレーター経過時間を短くすることができます。別のダウン ストリームサービスを単にトリガーするためのコールで大半が構成されているバッチ の場合、バッチサイズを大きくすることで、1 回の呼び出しで処理するレコードを増 やすことができ、 スループットが向上します。しかし、 追加の処理を必要とするレコー ドがバッチに含まれている場合は、バッチサイズを小さくしてシャードの停滞を回避 する必要があるかもしれません。 関数のイテレーター経過時間を監視するためのもう 1 つの主要な要素は、呼び出しエ ラーの追跡です。呼び出しエラーは Lambda のログで確認できます。呼び出しエラー は、関数のイベント処理時間に影響することがあります。レコードのバッチが常にエ ラーを発生させていると、 その関数は次のバッチに進むことができなくなり、 イテレー ター経過時間が長くなります。呼び出しエラーは、関数にアクセスしているストリー ムの問題（不正なパーミッションなど）や、Lambda の同時実行数の上限を超えてい ることを示している場合があります。 関数の同時実行数の監視 関数の同時実行数は、関数が一度に処理できる呼び出しの数を表す指標です。サービ スが初めて関数を呼び出したときに、Lambda ランタイムは、イベントを処理する関 数のインスタンスを新規作成します。サービスがイベントを処理しているときに関数 を呼び出した場合、Lambda は別のインスタンスを作成します。このサイクルは、受 信したリクエストに対応するのに十分な関数インスタンス数になるまで、または関数 が同時実行数の上限に達してスロットリングされるまで続きます。 デフォルトでは、Lambda はリージョンあたり 1000 件の同時実行が可能な初期プー ルを作成し、そのリージョン内のすべての関数で共有されます。AWS サポートにリク エストを提出することで、リージョンあたりの上限を増やすことができます。また、 Lambda では、リージョンごとの同時実行数のプールにおいて、すべての関数で少な くとも 100 件の同時実行が常に可能な状態にしておく必要があります。関数の呼び 出し回数と共に同時実行数を監視することで、オーバープロビジョニングされた関数 を管理し、アプリケーショントラフィックのフローをサポートするよう関数をスケー リングできます。たとえば、新しい呼び出しのバーストが発生したときに、受信した トラフィックを処理できるだけの十分な同時実行数がない場合、関数がスロットリン グされる可能性があります。
29. 29 Lambda は、受信したリクエスト数に基づいて自動的に関数インスタンスをスケー リングしますが、 最初のバースト時に作成できるインスタンス数には上限があります。 この上限に達すると（リージョンに応じて 500 ～ 3,000 のインスタンス） 、利用可能 な同時実行数をすべて使い果たすまで、1 分あたり 500 インスタンスの速度で関数が スケーリングされます。この利用可能な同時実行数は、リージョンごとの同時実行数 の上限や、関数の予約済み同時実行数から引き出されています。予約済み同時実行数 は、1 つまたは複数の関数に割り当てる利用可能な同時実行数のプールに含まれてい るものです。予約済み同時実行数を設定することで、関数がスケーリングするのに十 分な同時実行数を確保できるようになります。 また、 コントロール不能な状態でスケー リングしたり、同時実行数のプールを占有したりすることも回避できます。 関数の同時実行数の予約は、比較的多くの同時実行数を定期的に必要とする関数を把 握している場合に役立ちます。また、同時実行数を予約することで、関数があまりに も多くのリクエストを処理してダウンストリームサービスをあふれさせるような事態 も回避できます。 関数が予約済み同時実行数を使い果たした場合、 予約していないプー ルから同時実行数を追加して使用することはできません。関数の同時実行数を予約す ると、利用可能な同時実行数のプールサイズが小さくなるため、他の関数のパフォー マンスに影響を与えない場合にのみ予約するようにしてください。
30. 30 同時実行数：同時実行数を監視するために、Lambda は同時実行数メトリクスを発行 します。このメトリクスを使用すると、関数がプール内の同時実行数をすべて使い切 るタイミングを追跡できます。 上図の例では、特定の関数の実行数にスパイク（急激な増加）が見られます。 前述のように、共通の実行数プールから同時実行数を予約することで、関数の同時実 行数を制限できます。これは、関数があまりにも多くのリクエストを同時に処理しな いようにする必要がある場合に役立ちます。ただし、Lambda では、予約済みの同時 実行数を使い果たすと、関数をスロットリングすることに留意する必要があります。 予約されていない同時実行数：予約されていない実行数は、アカウントで利用可能な 同時実行の総数から、予約済みの同時実行数を差し引いたものに相当します。予約さ れていない同時実行数のメトリクスと、 同時実行数のメトリクスを比較して、 重いワー クロード時にどの関数が残りの同時実行数プールを使い果たすかを監視できます。 前掲のグラフは、予約されていない同時実行数のスパイクと、1 つの関数が利用可能 な同時実行数の大半を使用している状況を示しています。これは、アップストリーム サービスがあまりに多くのリクエストを関数に送信していることが原因となっている 可能性があります。
31. 31 プロビジョニング済み同時実行数の監視： Lambda は必要なときにしか関数コードを実行しないため、しばらく関数を使用して いない場合、追加のレイテンシー（コールドスタート）が発生することがあります。 これは、Lambda では新しいコンテナを初期化し、非アクティブな関数に対してパッ ケージ化された依存関係をプロビジョニングする必要があるためです。初期化のたび に、関数の実行をさらに数秒遅らせることがあります。Lambda はコンテナを約 45 分間起動させたままにしますが、この時間はリージョンによっても、VPC を使用して いるかどうかによっても異なります。 関数の起動時間が長いと（依存関係が多い場合など） 、リクエストのレイテンシーが 大きくなる可能性があります。Lambda がリクエストの急増に対応するために新しい インスタンスを初期化する必要がある場合は、特にそうなります。これを軽減するに は、プロビジョニング済み同時実行数を使用します。これにより、自動的に関数イン スタンスが事前に初期化されるため、 リクエストが迅速に処理されるようになります。
32. 32 十分なレベルのプロビジョニング済み同時実行数（ウォームインスタンス数など）を 関数に割り当てることで、コールドスタートが発生する可能性を低下させることがで きます。 これは 1 日の特定の時間帯にトラフィックが急増するアプリケーション （フー ドデリバリアプリケーションなど）にとって非常に重要となります。プロビジョニン グ済み同時実行数は、Application Auto Scaling で管理できます。これにより、スケー リングのスケジュールや使用率に基づいて同時実行数を自動的に調整して、受信する トラフィックに備えることができます。 プロビジョニング済み同時実行数は、 アカウン トのリージョンにおける同時実行数プールから引き出されており、異なる価格モデル を使用していることに留意する必要があります。 プロビジョニング済み同時実行数の使用率：関数のプロビジョニング済み同時実行数 の効率を監視するための主要なメトリクスの 1 つが、プロビジョニング済み同時実行 数の使用率です。利用可能なプロビジョニング済み同時実行数をすべて使い切ってい る（使用率のしきい値に達している）関数は、同時実行数の追加が必要な場合があり ます。また、使用率が常に低い場合は、関数をオーバープロビジョニングしている可 能性があります。その関数のプロビジョニング済み同時実行数を無効にするか削減し て、コストを調整できます。
33. 33 Amazon API Gateway Amazon API Gateway は、 専用の API サーバーを管理することなく、 アプリケーション の API を作成して公開できるサービスです。サーバーレスエコシステムにおいて、 API Gateway は、適切な関数、クラスター、またはインスタンスに HTTP リクエスト をルーティングして処理を行えるほか、Amazon Cognito のような他の AWS サービス と接続した際に認証と認可のレイヤーを提供します。 Amazon API Gateway の監視方法 API に依存している関数は、API が失敗した場合や、API のレイテンシーで大幅な増加 が発生した場合に機能しなくなります。特にエラーやレイテンシーのメトリクスを調 べて、API のパフォーマンスを監視することは、サーバーレスアプリケーションが顧 客に利用可能であることを確認するための重要な要素となります。 API Gateway の主要なメトリクス 5xx エラー ： クライアントから API エンドポイントにリクエストが送信されると、エン ドポイントはリクエストが成功したかどうかを示す HTTP レスポンスコードを返し ます。たとえば、HTTP レスポンスが 200 の場合はリクエストが受信されたことを示 し、レスポンスが 5xx の場合はサーバー側でエラーが発生したことを示します。503 （Service Unavailable）は、API Gateway でよくあるサーバーエラーです。こうしたエ ラーは通常、API Gateway で構成ミスがある場合や（存在していない関数を参照して いるなど） 、処理するリクエストが多すぎる場合に発生します。 インテグレーションレイテンシーとレイテンシー：Amazon CloudWatch には、API Gateway 向けにレイテンシー関連の 2 つのメトリクスがあります。インテグレー ションレイテンシーのメトリクスは、関数がリクエストを送信してから API Gateway にレスポンスを返すまでの時間を測定し、関数のレスポンス状態を監視するのに役立 ちます。レイテンシーのメトリクスは、API コールのエンドツーエンドのレスポンス 状態、 つまり、 API Gateway がクライアントからリクエストを受け取ってからレスポン スを返すまでの時間を測定します。 インテグレーションレイテンシーの増加は、API Gateway がアイドル状態の関数を呼 び出そうとする「コールドリクエスト」や、API Gateway が別の AWS リージョンに ある関数や他のリソースを呼び出すことが原因で発生することがあります。API コー ルのエンドツーエンドのレスポンス状態（レイテンシーなど）は、AWS サービスの一 般的なレイテンシーの影響を受ける可能性があるため、インテグレーションレイテン シーとレイテンシーの両方のメトリクスを比較して、問題の原因を特定することが重 要となります。
34. 34 API Gateway ログの監視 API に関する問題をデバッグする際に、API のレイテンシーとエラーのメトリクスか らわかることは、全体の一部だけです。異常な動作が発生した理由を理解しておく必 要もあります。API Gateway の実行ログとアクセスログを使用し、CloudWatch で API コールをログに記録することで、API のアクティビティに関する豊富なコンテキスト を得ることができます。実行ログには、エラー / リクエスト / レスポンスのパラメー ターや、ペイロードの情報をはじめ、実行されたコールのタイプについての詳細情報 が記述されます。アクセスログでは、誰がどのように API にアクセスしたかが示され ます。 たとえば、API Gateway のログを監視することで、API エラーの増加が、特定の API にアクセスするクライアントのパーミッションが不十分なために発生したのか、ダ ウンストリームの Lambda 関数が不正なレスポンスを返したために発生したのかを 判断できます。API Gateway のログにより、API に関するトラブルシューティングに 必要なコンテキストを得られるため、誤って設定された各 API エンドポイントの IAM ロールをエンドツーエンドで可視化できます。 AWS Step Functions AWS Step Functions は、分散アプリケーションのコンポーネントを個々のステートマ シンに分割できるサービスです。これにより、アプリケーションワークロード内のス テップを容易に管理し、可視化できるようになります。Step Functions を使用して実 行できるタスクとしては、アプリケーションの登録ステップを管理する、複数のシス テムからのデータを単一の形式にマージして処理する、購買システムに手動の承認プ ロセスを組み込む、といったものが挙げられます。 AWS Step Functions の監視方法 Amazon CloudWatch は、ステートマシンの実行を追跡するメトリクスをはじめ、 Step Functions を監視するためのさまざまなメトリクスを提供します。実行を監視す ることで、AWS クォータに達しないようにしたり、ステートマシンを無期限に実行さ せるリスクを回避したりすることができます。 AWS Step Functions の主要なメトリクス Execution time（実行時間） ：ステートマシンは、タイムアウトするまで 1 年間実行 できますが、 現在の実行が終了する前に新たな実行をトリガーすることができるため、 結果として無期限の実行ループになる可能性があります。実行時間として、ステート マシンが実行されている時間が測定されるため、実行時間があまりにも長いステート マシンを特定してトラブルシューティングすることが可能です。
35. 35 Failed executions（失敗した実行数）: 失敗した実行数は、サーバーレスアプリケー ションのヘルスを監視するためのもう 1 つの主要なメトリクスです。AWS Lambda の メトリクスと相関させることで、Step Functions と Lambda 関数の間のブレークダ ウンの原因を特定できます。たとえば、失敗したステートマシンの実行数と Lambda のエラー数の両方が等しく増加している場合、問題は特定の Lambda 関数に関連して いる可能性があります。Lambda のエラー数が少ない場合は、実行エラーの原因とし て IAM ロールの構成ミスが考えられます。 AWS Fargate AWS Fargate は、サーバーレスアーキテクチャを構築するためのもう 1 つのツー ル で す。Fargate は、Amazon Elastic Container Service（ECS） と Amazon Elastic Kubernetes Service（EKS）の両方と統合されます。これにより、サーバーや Amazon EC2 インスタンスを手動でプロビジョニングすることなくコンテナを実行できるよう になります。Fargate は Lambda よりも多くの CPU と RAM 容量をインスタンスに提 供しており、ランタイムの制限はありません。 ECS で Fargate を使用してアプリケーションを起動するには、ネットワーク、IAM ポ リシー、CPU、メモリの要件を自動的にプロビジョニングするタスクを定義します。 Fargate は、その構成に基づいてコンテナを起動し、アプリケーションを実行します。 EKS の場合は、どの Kubernetes ポッドを実行すべきかを決定する Fargate プロファ イルを作成します。AWS は、ポッドのリソース要件に最適な Fargate コンピュートリ ソースを使用して、それらを自動的にプロビジョニングします。 AWS Fargate の監視方法 AWS Fargate の主要なメトリクス Fargate は、EKS と ECS の両方で使用できるため、両方のプラットフォームで Fargate のパフォーマンスを監視するための主要なメトリクスをいくつか説明します。 メモリと CPU 使用率：AWS の価格設定は、タスクやポッドの構成済み CPU とメモリ リソースに基づきます。このため、 メモリと CPU 使用率は、 コンテナのプロビジョニン グが過不足なく行われているかどうかを確認するための重要なメトリクスとなりま す。通常の使用量よりも多くのメモリをタスクに割り当てている場合は、必要以上に 多く支払っている可能性があります。たとえば、2 GB しか使用しないタスクに 8GB のメモリを割り当てている場合は、 プロビジョニングされたメモリ量を減らすことで、 パフォーマンスに影響が及ぶリスクをそれほど負うことなく、 コストを削減できます。 反対に、EKS ポッドのメモリ使用量が、設定した制限を超えた場合には、EKS ポッド が終了する可能性があります。 EKS ポッドと ECS クラスターの CPU 使用率を監視することで、コンピュートリソー スがスロットリングに近い状態にあるかどうかを判断できます。CPU のしきい値に達 しそうになったら、負荷に対応できるように環境をスケーリングできます。
36. 36 Datadog を使用して AWS サーバーレスプラットフォームを監視 サーバーレスアプリケーションは、監視に関する新たな課題をもたらします。受信し たリクエストや他のサービスがどのように関数とやりとりしているか、また、高い需 要やエラーに対する関数の耐障害性はどの程度かに留意する必要があります。たとえ ば、新しいリクエストが殺到した際に、そのトラフィックを処理するのに十分な同時 実行数がない場合は、AWS で関数がスロットリングされる可能性があります。また、 アップストリームのサービスからエラーが発生し、関数コードの実行が阻止される可 能性もあります。 サーバーレスアプリケーションを効果的に監視するには、サーバーレスアーキテク チャ全体を可視化して、関数と他の AWS サービスがどのように相互運用しているか を把握できるようにする必要があります。 Datadog は、 サーバーレスアプリケーション の状態を 1 か所で完全に可視化します。エンドツーエンドのトレースでサービスのボ トルネックを特定し、カスタムメトリクスを追跡し、データを相関させ、関数のパ フォーマンスに関する有用な情報を得ることができます。
37. 37 高度なレベルでは、Datadog ではビルトインの AWS インテグレーションを提供 し て お り、 サ ー バ ー レ ス ア プ リ ケ ー シ ョ ン（Lambda、Fargate、API Gateway、 Step Functions など）に使用されているものを含め、すべての AWS サービスから CloudWatch データを収集しています。Datadog のサービスマップを使用すると、す べてのサーバーレスコンポーネントを 1 か所で可視化し、環境内のアップストリーム とダウンストリームの依存関係全体におけるトラフィックフローを把握できるように なります。 サーバーレス関数の理解を深めるために、Datadog では専用の Lambda レイヤー と Forwarder を使用して、ユーザーの関数から運用監視データを収集します。Datadog の Lambda レイヤーは、各関数のランタイムの一部として実行され、Datadog Forwarder Lambda 関数と連携して、標準的な CloudWatch メトリクスよりも詳細な 拡張メトリクスを生成します。Lambda レイヤーで収集したデータは、Datadog のす ぐに使える AWS インテグレーション経由で既に収集しているメトリクス、ログ、そ の他のトレースを補完します。
38. 38 サーバーレスメトリクスを可視化する AWS Lambda メトリクスの収集 Datadog は Lambda レイヤーと Forwarder を使用してカスタムメトリクスを収集し、 リアルタイムの拡張メトリクスを生成します。これは、Datadog がユーザーの AWS 関数ログから自動的に抽出する、課金期間、タイムアウト、予測コストなどのメトリ クスです。Lambda レイヤーは、 （同期または非同期で）カスタムメトリクスを送信 することもできるため、アプリケーションワークフローに固有のユースケースについ て、アプリケーションへのユーザーログイン、アイテムの購入、ユーザープロファイ ルの更新など、さらに有用な情報を得ることが可能です。コードにオーバーヘッドを 追加しないことから、メトリクスの非同期送信が推奨されています。これは、アプリ ケーションのパフォーマンス重視のタスクに対応する関数にとって、最適なソリュー ションとなります。 Datadog では、Lambda、Step Functions、Fargate のダッシュボードなど、すぐに使 えるインテグレーションダッシュボードを AWS インフラストラクチャ向けに提供し ています。これにより、サーバーレスアプリケーションのパフォーマンスの概要を把 握できるようになります。
39. 39 たとえば、前掲のダッシュボードでは、すべての Lambda 関数のコールドスタート、 エラー、メモリ使用量を容易に追跡できます。また、ダッシュボードをカスタマイズ して、関数ログやトレースデータのほか、他のサービスからのメトリクスも含め、容 易に相関させることもできます。 サーバーレスログを 1 か所で検索および分析する AWS Lambda によるログ作成 Datadog の Lambda レイヤーは、CloudWatch のログを自動的に Datadog Forwarder に転送し、Datadog Forwarder がそれを Datadog にプッシュします。Forwarder は、Amazon S3 のイベントや Amazon Kinesis のデータストリームイベントなど、 ログやその他のテレメトリをアカウントに送信できます。CloudFormation 経由で Forwarder をデプロイすることが推奨されています。そうすると、自動的に AWS が 適切なロールで Lambda 関数を作成し、Datadog の Lambda レイヤーを追加し、さ らに「functionname」 「region」 「account_id」などの関連タグを作成するためです。 これらを使用して、ユーザーは Datadog でログを検索できるようになります。 Forwarder は Lambda 関数であるため、実行はトリガーに依存します。Datadog で これらのトリガーを自動的に設定することも、手動で設定して、S3 バケットまたは CloudWatch ロググループに追加されたらすぐにデータを転送することもできます。 設定が完了すると、Datadog の Lambda Forwarder は、Lambda（および設定した他 の AWS サービス）から Datadog アカウントへのログ送信を開始します。 Lambda 関数は大量のログを生成するため、インシデント発生時に問題を特定するこ とや、単に関数の現状を監視することが困難になります。Datadog のログパターンを 使用すると、ログの中で気になる動向を明らかにするのに役立ちます。 たとえば、ダッシュボードで Lambda エラーでスパイクが見られる場合は、ログパ ターンを使用して、最もよくあるエラーのタイプを素早く検索できます。以下の例で は、 「AccessDeniedException」のパーミッションエラーを記録した関数ログのクラ スターを確認できます。ログからスタックトレースを得られるため、詳細なトラブル シューティングを行うことができます。
40. 40 Datadog のログアラートを Amazon EventBridge へルーティングする Datadog ではさらに、ログからアラートを作成して問題が通知されるようにするこ とも、Amazon EventBridge インテグレーションによって関数管理のワークフローを 自動化することもできます。たとえば、メモリ不足エラーに対して Lambda 関数が Datadog のログアラートをトリガーする場合、EventBridge を使用してその関数のメ モリ量を自動的に増やすことができます。これにより、修復パイプラインを簡素化で きるため、アプリケーションを確実に稼働し続けることが可能となります。 Datadog APM を使用してトレースデータを調査する AWS Lambda によるトレース Datadog Lambda レイヤーは、トレースヘッダーをサービス間で自動的に伝達し、 サーバーレスアプリケーションにエンドツーエンドの分散トレースを提供します。 Datadog APM は、サーバーレスアーキテクチャ全体でリクエストトラフィックをネイ ティブにトレースするために、Lambda レイヤーと一緒に使用できるトレースライブ ラリを提供します。 トレースは非同期送信されるため、 サーバーレスアプリケーション にレイテンシーのオーバーヘッドが追加されることはありません。
41. 41 また、Datadog では、AWS Fargate、Amazon API Gateway、Amazon SNS、Amazon SQS など、サーバーレスアプリケーションと一緒に使用できる他のサービス向けの インテグレーションも提供します。これにより、サーバーレスアーキテクチャのすべ てのレイヤーを可視化できるようになります。これらのインテグレーションを有効に すると、エラーやコールドスタートを発生させている特定の関数にドリルダウンして パフォーマンスを最適化できます。AWS では、関数の実行にかかる時間、各関数に割 り当てられたメモリ量、関数に対するリクエスト数に基づいて課金されます。これは つまり、コストが急増する可能性があるということです。たとえば、ネットワーク障 害が発生している API Gateway サービスに対して大量の関数が呼び出しを行い、レス ポンスを待機しなければならない場合にはコストが急増します。 トレースを使用すると、API Gateway などのアップストリームとダウンストリームの 依存関係をマップし、スタック全体でリクエストをトレースして、レイテンシーのボ トルネックを特定できるようになります。また、Datadog Forwarder を使用すると、 サーバーレスログを分析し、関数が生成するエラーのタイプを素早く特定することも 可能になります。 サーバーレス関数からのトレースデータの分析を開始するには、Datadog の Serverless ビューを使用します。このビューでは、すべての関数を包括的に表示し、 呼び出し回数やメモリ使用量などの主要なメトリクスを含めることができます。特定 の関数を検索したり、すべての関数にわたってパフォーマンスメトリクスを表示した りすることも可能です。Serverless ビューでは、以下の例のように、特定のメトリク スごとに関数を並べ替えれば、大量のメモリを使用している関数や、最も呼び出され ている関数を明確にすることができます。
42. 42 関数をクリックすると、関連するすべてのトレースとログのほか、各呼び出しの詳細 な情報（期間、関連するエラーメッセージ、呼び出し中に関数でコールドスタートが 発生したかどうかなど）も表示されます。 API のレイテンシーとコールドスタートの 2 つは、サーバーレス関数に関するよくあ る問題であり、どちらも関数の実行時間を大幅に増加させることがあります。コール ドスタートは通常、より多くのリクエストを処理するために関数がバックグラウンド でスケーリングするときに発生します。API のレイテンシーは、ネットワークやその 他のサービスの停止が原因で起こることがあります。Datadog を使用すると、すべて の関数について、レイテンシーとコールドスタートをプロアクティブに監視できるよ うになります。 たとえば、通常と異なるレイテンシーが関数で発生したときに通知が届くように、異 常値のアラートを作成できます。トリガーされたアラートから、トレースやログに切 り替えて、レイテンシーの原因がコールドスタートなのか、API サービスの依存関係 における問題なのかを判断できます。Datadog ではまた、コールドスタートの発生を 自動的に検出し、トレースに「cold_start」タグを適用するため、コールドスタート が発生している関数を容易に特定し、詳細なトラブルシューティングを行うことがで きます。
43. 43 関数の実行時間が増大している原因がコールドスタートの過多である場合は、プロビ ジョニング済み同時実行数を使用することで、初期化のレイテンシーを減らすよう Lambda を構成できます。一方、API サービスからレイテンシーが発生している場合 は、 リージョンをまたぐ呼び出しが原因の可能性があります。その場合は、 アプリケー ションリソースの配置場所を同じ AWS リージョン内に変更する必要があるかもしれ ません。 サーバーレスエコシステムを完全に可視化する これまで、 サーバーレスアプリケーションを監視するための主要なメトリクスのほか、 よくあるサーバーレス問題のトラブルシューティング方法について説明してきまし た。AWS は包括的なツールスイートを提供しており、ユーザーはプロビジョニングや インフラストラクチャリソース管理ではなく、スケーラブルなサービスの構築に注力 できるようになります。 Datadog は、 こうしたサーバーレスアプリケーションを深部まで可視化し、 ビルトイン のサービスインテグレーション、専用の Lambda レイヤー、インストールしやすい Forwarder を使用して、運用監視データを容易に収集できるようにしています。ユー ザーは、 インテグレーションダッシュボードでサーバーレスのメトリクスを可視化し、 Datadog の Log Explorer でログをふるいにかけ、Datadog APM で分散リクエストト レースを分析できます。
44. 44 参考資料 サーバーレスアプリケーションの監視に関する詳細については、以下のガイドを参照 してください。 – AWS Lambda monitoring series（AWS Lambda の監視シリーズ） – Monitoring Amazon EKS on AWS Fargate（AWS Fargate で Amazon EKS を監 視する） – Monitoring AWS Step Functions（AWS Step Functions の監視） また、お使いのサーバーレス環境でこれらの監視戦略を実践したい場合は、www. datadog.com において、Datadog のフル機能を利用できるトライアル版をお申し込み ください。
47. 47 クラウドにおけるコンテナの進化 絶えず変化するコンテナ化されたワークロード Amazon Elastic Container Service（ECS） Amazon ECS の仕組み – EC2 インフラストラクチャ上の ECS – Fargate 上の ECS Amazon ECS の監視方法 – ECS ステータスの監視 – 監視のための主要な ECS リソースメトリクス Amazon Elastic Kubernetes Service（EKS） Amazon EKS の仕組み – EKS によるワークロードの管理方法 Amazon EKS の監視方法 – EKS ステータスの監視 – コントロールプレーンの監視 – EKS リソースメトリクスの監視 オーケストレーションされたクラスターをサポートする AWS サービスの監視 AWS コンテナ環境の包括的な監視 コンテナスタックの可視化 – カスタマイズ可能なダッシュボード – ライブコンテナビュー – コンテナマップ 自動アラート 全体監視とインシデント対応 動的な環境のフルスタック運用監視 参考資料 48 48 50 50 52 53 54 54 55 59 60 61 63 63 67 71 75 76 78 78 79 80 81 83 87 87 AWS と Datadog によるクラウドスケールの監視 AWS におけるコンテナ化されたアプリケーション
48. 48 クラウドにおける コンテナの進化 コンテナは、日常的に使用されている多くのアプリケーションを強力にサポートしま す。特にマイクロサービス指向アーキテクチャやアジャイルワークフローに適してい るコンテナは、開発者の効率性、機能速度、リソースの最適化を向上させるのに役立 ちます。 このセクションでは、クラウドにおいて変化し続けているコンテナの現状を説明し、 オーケストレーションテクノロジーが今日のコンテナエコシステムに欠かせないも のになっている理由を探ります。そして、Amazon Elastic Container Service（ECS） と Amazon Elastic Kubernetes Service（EKS）という 2 つのコンテナオーケストレー ションシステムを活用する際に監視すべき主要なメトリクスを紹介します。最後に、 Datadog などの包括的な監視プラットフォームを使用して、これらのメトリクスをす べて収集し、コンテナ化された環境のフルスタックの可視化を実現する方法について 説明します。 絶えず変化するコンテナ化されたワークロード コンテナとは、最も基本的なレベルでは、分離された仮想の実行環境（ランタイム） であり、必要な依存関係もすべて含んだパッケージで提供されます。これにより、ア プリケーションのデプロイ先がローカル環境、企業のプライベートデータセンター、 パブリッククラウドのいずれであっても、場所を問わず常にアプリケーションが実行 されるようになり、 開発プロセスが簡素化されます。コンテナ化では、 仮想マシン （VM） よりも軽量で、デプロイやスケーリングがしやすい、個別のソフトウェア単位にアプ リケーションを分割することで、リソースのプロビジョニングをさらに効率化し、ア ジャイルなワークフローと迅速なリリースサイクルをサポートします。
49. 49 コンテナ環境が複雑化するにつれ、動的なコンテナインフラストラクチャの管理、ス ケーリング、運用に関する作業（利用可能なリソースが十分にあるノードへのコンテ ナのデプロイ、異常があるコンテナの再起動、望ましいすべてのリージョンでコンテ ナが実行され高可用性が確保されていることの確認といったタスク）を容易にするた めに、Kubernetes などのコンテナオーケストレーションソリューションを導入する 開発チームが増えています。 オーケストレーションは、チームが動的なコンテナ環境を大規模に管理し、インフラ ストラクチャリソースをより効率的に使用できるようにします。Docker を採用して いる 1 万社以上の企業の使用状況データをまとめたレポートによると、ホストあたり の実行中のコンテナ数（中央値）は、オーケストレーション環境では 11.5 個に対し、 非オーケストレーション環境では 6.5 個です。これは、オーケストレーターによって、 組織がより多くのコンテナを実行し、各ホストで利用可能なリソースをより多く活用 して、インフラストラクチャのコストを効果的に削減できるという考えを裏付けてい ます。 クラウドプロバイダーは、コンテナオーケストレーションをさまざまな組織で利用で きるようにするために、高可用性、セキュリティ、ネットワークのビルトインサポー トを備えるマネージドサービスを提供し、コンテナオーケストレーションに関連する 運用上の課題の多くに対処しています。 このセクションでは、AWS クラウドにおいて、コンテナ化されたアプリケーションを 効果的に実行するために特別に設計された 2 つのマネージドコンテナオーケストレー ションテクノロジー、Amazon Elastic Container Service（ECS）と Amazon Elastic Kubernetes Service（EKS）に焦点を当てます。この 2 つのコンテナオーケストレー ションテクノロジーの概要と、それらを使用する際に監視すべき主要なメトリクスを 探ります。また、そうしたサービスのために AWS Fargate によるサーバーレスインフ ラストラクチャを導入することで、自社ホストのプロビジョニングや管理が不要にな ることについても説明します。
50. 50 Amazon Elastic Container Service（ECS） Amazon ECS の仕組み 2015 年に初めてリリースされた Amazon Elastic Container Service（ECS）は、 AWS クラウドでのコンテナの効率的な管理とスケーリングを支援するものです。ECS を使用することで、Amazon EC2 インフラストラクチャ、AWS Fargate によるマネー ジドコンピュートリソース、またはその両方を組み合わせた環境でコンテナを起動で きるようになります。 EC2 インフラストラクチャ上にコンテナをデプロイすることで、 コンテナをホスティングするサーバーをより直接的にコントロールできるようになり ます。一方 AWS Fargate からは、コンテナを実行するインフラストラクチャのプロビ ジョニング、管理、監視を行う必要がないという利便性を得られます。 タスクは、ECS ワークロードの基礎となるものです。各タスクは、タスク定義（実 行するコンテナイメージ、各コンテナに割り当てるリソース数などの情報を記述で きる指示書）に従ってコンテナの起動、終了、構成を担います。タスク定義では、 Amazon Elastic Container Registry（ECR） 、Docker Hub、またはその他のレジストリ からイメージに名前を付けることができます。 タスク定義に記述されている仕様に従ってタスクを自動的にスケジューリングする サービスを作成できます。サービス定義内では、タスクを実行するのに望ましいイン スタンス数を指定できます。サービスは、タスクのステータスを継続的に追跡し、そ れに応じてタスクの起動と終了を行うため、望ましい数のタスクインスタンスを実行 しているかどうかをいつでも確認できるようになります。
51. 51 キャパシティプロバイダー戦略を設定するか、タスク定義で起動タイプを指 定することで、ECS タスクで使用するインフラストラクチャのタイプ（EC2、 Fargate、またはその組み合わせなど）を決定できます。たとえば、以下のタスク 定義では、Flask アプリケーションコンテナと Redis コンテナを指定しています。 requiresCompatibilities パラメーターは、このタスクでは Fargate 起動タイプを使 用する必要があることを示しています。 { ″family″: ″my-flask-app-family″, ″executionRoleArn″: ″arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole″, ″compatibilities″: [ ″EC2″, ″FARGATE″ ], ″″containerDefinitions″: [ { ″entryPoint″: [ ″python″, ″app.py″ ], ″essential″: true, ″image″: ″my-flask-app″, ″name″: ″app″, ″portMappings″: [ { ″containerPort″: 4999, ″hostPort″: 4999, ″protocol″: ″tcp″ } ] }, { ″essential″: true, ″image″: ″redis:latest″, ″name″: ″redis″, ″portMappings″: [ { ″containerPort″: 6379, ″hostPort″: 6379, ″protocol″: ″tcp″ } ] }, ], ″cpu″: ″256″, ″memory″: ″512″, ″networkMode″: ″awsvpc″, ″requiresCompatibilities″: [ ″FARGATE″ ], ″revision″: 11, ″status″: ″ACTIVE″ }
52. 52 EC2 インフラストラクチャ上の ECS ECS タスクを Amazon EC2 にデプロイすることで、ワークロードを実行する仮想イン スタンスのプロビジョニング、管理、スケーリングを柔軟に行うことができるように なります。この設定では、ECS コンテナインスタンス—として知られる EC2 インス タンスはそれぞれ、ECS コンテナエージェントを実行し、そのインスタンス上で実行 されるコンテナの管理を担います。エージェントは、実行中のタスクについての情報 を ECS API に渡し、ECS からのリクエストに応じてタスクを管理します。 EC2 インフラストラクチャ上で実行されるタスクの場合、 利用可能なリソースの量は、 タスク定義で指定されたリソース要件によって決まります。タスク定義でリソースが 設定されていない場合、リソースはタスクをホスティングするコンテナインスタンス の容量によって自動的に制限されます。 ECS リソースのメトリクスを監視することは、 ECS サービスに適したスケーリングポリシーを作成し、ワークロードがスムーズに実 行できるだけの十分な容量を確保するために非常に重要です。これらのメトリクスや その他のメトリクスについては、後ほど詳しく説明します。
53. 53 Fargate 上の ECS Fargate を使用すれば、ECS のタスクを AWS のマネージドインフラストラクチャに配 置することで、EC2 インスタンスの管理やプロビジョニングが不要になります。ECS は、タスク定義のリソース要件に応じたサイズの Fargate コンピュートリソースを自 動的にプロビジョニングします。ECS タスクを実行するのに利用可能なリソース量が EC2 コンテナインスタンスに十分にないと、ECS タスクのスケジュール設定が失敗す る場合がありますが、 Fargate はそうした不確実性を取り除いてエンジニアリングチー ムが運用上の問題への対処に費やす時間を減らすことができるようにします。 ECS で使用しているインフラストラクチャのタイプに関係なく、コンテナ化されたア プリケーションがスムーズに実行されるように、以下の主要なメトリクスに注意を払 う必要があります。
54. 54 Amazon ECS の監視方法 Amazon ECS で自動デプロイメントを実行する際には、コンテナが期待どおりに起動 し、終了しているかを確認するために、クラスターのステータスを監視する必要があ ります。また、ECS ワークロードのリソース使用状況を監視し、Fargate を使用して いない場合は、それらが実行されているコンテナインスタンスを監視する必要があり ます。 ECS ステータスの監視 「望ましいタスク数」と「サービスごとの実行中のタスク数」の比較：ECS サービス は自動的に、望ましいタスク数が常に実行されるようにします。タスクの停止や失敗 が予期せず発生した場合、ECS サービスがそれの代わりになる別のタスクを起動する まで、実行中のタスク数は、望ましいタスク数を下回ります。 望ましいタスクインスタンス数を増加させる新バージョンのサービスをデプロイした 直後は、ECS サービスが新しい要件を満たすためにタスクを自動的に起動します。そ の結果、新しいタスクが初期化されているときには、望ましいタスク数と実行中のタ スク数が一時的に不一致になることがあります。しかし、望ましいタスク数よりも実 行中のタスク数が常に下回っているように見える場合は、それらのタスクが実行され ていない理由を調査する必要があります。 たとえば、最新のタスク定義に誤字がある、タスクが Elastic Load Balancing のヘル スチェックに失敗した、タスクを実行しているコンテナインスタンスが停止または終 了した、といった理由が考えられます。サービスイベントは、望ましいタスク数と実 行中のタスク数の比較のほか、クラスターにタスクを配置する際に ECS で問題が発生 していないかどうかを把握するのに役立ちます。
55. 55 監視のための主要な ECS リソースメトリクス ECS タスク定義では、ECS がタスクや個々のコンテナに割り当てるリソースの最大量 を指定できます。タスクレベルのリソースの上限は、ECS がタスク内のすべてのコン テナで共有可能にするリソースの最大量として機能します。また、さらに詳細なレベ ルでリソースを管理するために、タスク内の個々のコンテナのリソースに上限を指定 することもできます。 Fargate を使用している場合は、タスクレベルでリソースの上限（タスクサイズとも 呼ばれる）を設定する必要があります。ECS はそれを使用して、タスクにプロビジョ ニングするコンピュートリソース量を決定します。これはまた、タスクが使用できる CPU とメモリの最大量にもなります。EC2 インフラストラクチャにデプロイされる タスクの場合、タスクレベルでのリソースの上限はオプションとなります。タスクに 利用可能なリソースの最大量は、そのタスクが実行されるコンテナインスタンスのリ ソース量に自動的に制限されるためです。 EC2 で実行される ECS タスクでは、コンテナレベルでメモリの上限を指定すること が求められます。しかし、コンテナレベルでの CPU の上限はオプションとなります。 特に指定がない限り、ECS は各コンテナに対して、デフォルトの CPU ユニット数を 予約するためです。タスク内のコンテナに対し、ハードメモリまたはソフトメモリの 上限（もしくはその両方）を設定できます。ソフトメモリの上限を指定すると、ECS はその値を使用して、予約するメモリ量を決定します。ソフトメモリの上限を指定せ ず、ハードメモリの上限のみを指定すると、その値は ECS が予約するメモリ量となり ます。ソフトメモリの上限を適度に小さい値に設定することで、少ないコンテナイン スタンスで多くのタスクをスケジューリングできる柔軟性が ECS にもたらされ、コス ト削減につながる場合があります。しかし、予約した量よりも多くのリソースをコン テナで実際に必要とする場合は、 パフォーマンス問題を引き起こす可能性もあります。
56. 56 リソース予約のメトリクスは、EC2 で実行されている ECS タスクによって現在予約さ れている総リソース量の割合を追跡するために利用できます。予約されたリソース量 は、タスク定義で定義されたコンテナレベルでのリソースの上限（CPU の場合は、上 限が指定されていなければ、 デフォルトの予約ユニット数）に基づいて計算されます。 この場合、総リソース量はクラスター内のコンテナインスタンスのサイズに基づいて 計算されます。 以下のリソース使用量メトリクスを監視することで、EC2 および Fargate 上のワーク ロードに対して、効果的な Auto Scaling ポリシーを作成できます。EC2 コンテナイン スタンス上で実行されているタスクにのみ適用されるメトリクスは、それに応じて マークが表示されます。 メモリ使用率 ： タスク内のコンテナにハードメモリの上限を設定している場合に、 コン テナレベルのメモリ使用率が常に高いときは、ECS がハードメモリの上限を超えた コンテナを終了させるため、チームに注意喚起することをお勧めします。また、タス ク定義を更新して、このハードメモリの上限を増加または削除することもお勧めしま す。EC2 を使用している場合は、タスク定義内でコンテナのスワップ容量を設定でき ます。これは、OOM-kill（メモリ不足によって停止）されるプロセスの可能性を減ら すのに役立ちますが、レイテンシー重視のアプリケーションには適していない場合が あります。 CPU 使用率：EC2 を使用してタスクを実行している場合、クラスターレベルの CPU 使用率を監視することで、十分なコンテナインスタンスが実行されているか、それと もワークロードをサポートするために追加する必要があるかを判断できます。EC2 に おいてこのメトリクスは、サービスまたはクラスター全体で現在使用中の予約済み CPU の割合を測定します。そのため、サービス内のコンテナの合計 CPU 使用率が、 それらのコンテナに最初に予約された CPU 使用率を超えた場合、このメトリクスが 100% を上回ることがあります（注：これは、CPU の予約がハードメモリの上限とし て機能する Windows コンテナインスタンスの場合は、該当しません） 。このメトリク スを監視し、そして、リアルタイムの CPU 使用率に基づいて ECS サービスのサイズ を自動的に調整するポリシーを構成するのに使用できます。 ECS タスクを実行しているのが EC2 か Fargate かに関係なく、コンテナレベルでの CPU 使用率メトリクスは、特に CPU 負荷の高いコンテナを特定するのに役立ちます。 たとえば、特定のコンテナがリソースを占有してしまい、それを必要とするタスク内 の他のコンテナで作業を完了できなくなることを防ぐために、コンテナレベルで CPU の上限を設定する必要があると判断する場合があります。 CPU とメモリの予約（EC2 のみ） ：予約メトリクスは、EC2 コンテナインスタンスで 実行されている ECS タスクにのみ適用されます。CPU とメモリの予約メトリクスは、 実行中のタスクによって予約されているすべての CPU またはメモリの割合を測定し ます（クラスター内のすべてのインスタンスの合計容量に基づいて計算されます） 。 これらのメトリクスを監視することで、ECS でワークロードのスケジューリングと起 動を成功させることができます。
57. 57 たとえば、タスクを実行するのに十分な空きメモリがあるコンテナインスタンスを ECS で検出できなかった場合、そのタスクは保留状態のままになります。ECS サービ スイベントには、 「すべての要件を満たすコンテナインスタンスがないため、サービ ス < サービス名 > にタスクを配置できませんでした」というようなメッセージが表示 されます。この問題を解決するには、タスク定義で予約されているメモリの量を減ら すか、タスクのリソース要件を満たす十分なメモリがあるコンテナインスタンスを追 加します。 リソース量に関する問題は、実行中のタスク数が望ましいタスク数を下回ったままで ある理由を説明するのに役立つ可能性があります。 こうした問題が発生しないように、 メモリまたは CPU の予約が一定レベルを超えた場合に、コンテナインスタンスをプ ロビジョニングするよう Auto Scaling ポリシーを作成できます。 I/O メトリクス：ECS では、各 EC2 コンテナインスタンスまたはコンテナから読み書 きされるバイト数の予期せぬ低下を監視して、必要とされるストレージにタスクから 確実にアクセスできるようにします。ECS タスクでは、Amazon Elastic File System （EFS）ボリュームを使用すれば、高度にスケーラブルで永続的なストレージにコン テナからアクセスできるようになります。あるいは、バインドマウント（すでにコン テナインスタンスにアタッチされている Amazon Elastic Block Store ボリュームをマ ウントするなど）といった他のストレージオプションを指定することもできます。
58. 58 ECS では、配置前にタスクのディスク要件が考慮されないため、ストレージ要件を満 たさないコンテナインスタンスでタスクが実行される可能性があります。EFS を使用 するメリットの 1 つは、ボリュームに残っているストレージ容量を監視する必要がな いことです。クラスターにデータを追加すると、EFS によって自動的にスケーリング されます。EC2 タスクで EFS を使用していない場合は、コンテナインスタンスで利用 可能なディスク容量を監視し、十分なストレージがある新しいインスタンスにワーク ロードを移行する必要があります。 ネットワークのスループット：クラスター内のネットワーク接続の状態を監視するこ と （コンテナ化された独自のマイクロサービス間だけでなく、 ECS コンテナエージェン トと ECS API 間のネットワーク接続の状態も監視すること）は非常に重要です。コン テナインスタンス（該当する場合）やコンテナに対する送受信のネットワークスルー プットに関する問題を検出するために、アラートを設定できます。これは構成に問題 があることを示している場合があるためです。Application Load Balancer（ALB）を 使用して ECS サービスのタスク間でトラフィックを分散させている場合、ALB のメト リクスとログは、サービスがトラフィックを受信できない問題を調査するのにも役立 ちます。
59. 59 Amazon Elastic Kubernetes Service （EKS） Kubernetes（K8s）は、2014 年に Google がオープンソース化した、人気の高いコン テナオーケストレーションソリューションです。多くの組織では AWS で自己管理型 Kubernetes クラスターを運用していますが、Kubernetes インフラストラクチャの運 用は専任の技術チームでなければ難しい場合があります。Amazon Elastic Kubernetes Service（EKS）を使用すると、Kubernetes に組み込まれているすべての機能にアク セスしながら、運用上のオーバーヘッドを削減できます。
60. 60 Amazon EKS の仕組み Amazon EKS は、フルマネージド Kubernetes コントロールプレーンを提供します。 これは、クラスターの状態維持やワークロードの管理 / スケジューリングなどの重要 なタスクを担います。コントロールプレーンは、以下の要素で構成されています。 – API サーバー：クライアント / アプリケーションやワーカーノードがクラス ターに関する情報にアクセスできる API を公開する – コントローラーマネージャー：望ましい状態にクラスターを近づける処理を 担う – スケジューラー：クラスターの状態についてクエリを実行し、ワーカーノー ドへのワークロードの割り当て方法を決定する – etcd：クラスターの状態、クラスター構成データ、その他の情報を追跡する 分散型キー値ストア コントロールプレーンはクラスターのブレインとして機能するため、正常で高い可 用性を維持することが非常に重要です。1 つのノードでコントロールプレーンを実行 することもできますが、少なくとも 3 つのコントロールプレーンノードをプロビジョ ニングすることが推奨されています。Amazon EKS は、複数の AWS アベイラビリティ ゾーンにコントロールプレーンノードをデプロイして、 高可用性を確保します。また、 コントロールプレーンノードを継続的に監視し、異常がある場合は交換します。 EKS は、 フルマネージドのコントロールプレーンのほか、 コントロールプレーンとワー カーノード間だけでなく、各ノードにあるポッド間でも、ビルトインのネットワーク をクラスターに提供します。また、EKS は Kubernetes 準拠の認定を受けているため、 Kubernetes のワークロードを EKS に移行する場合でも、新しいクラスターを立ち上 げる場合でも、容易に始めることができます。 EKS は、AWS App Mesh（ ア プ リ ケ ー シ ョ ン の ネ ッ ト ワ ー ク を 提 供 ） や AWS CloudFormation（EKS インフラストラクチャをコードとしてデプロイ）といった補 完的なサービスとシームレスに統合し、AWS クラウドで Kubernetes クラスターを容 易に実行できるようにします。
61. 61 EKS によるワークロードの管理方法 EKS クラスターは、 コントロールプレーンノード （AWS が管理） とワーカーノード （EC2 インスタンスまたは Fargate が管理するコンピュートリソース）の 2 タイプのノード で構成されます。各ワーカーノードでは、ノードの監視とコントロールプレーンとの 通信を行う kubelet プロセスを実行します。ワーカーノードでは、Kubernetes にデプ ロイできる最小単位であるポッドも 1 つ以上実行します。 ポッドは、 アプリケーション のワークロードを実行する 1 つ以上のコンテナによるグループであり、容易にスケー リングできます。同一ポッド内のコンテナは、共有ストレージと単一のネットワーク IP へのアクセスが許可されています。ポッドは、 アプリケーションのインスタンスか、 単一のコンポーネント（NGINX など）かを問わず、クラスター内でワークロードを実 行する任意の単位になります。 マニフェストは、クラスター内のオブジェクトについて、望ましい状態を定義する設 定ファイル（YAML または JSON 形式）です。マニフェストには、 起動するポッド数と、 各ポッドを構成するコンテナが記述されており、場合によっては、ワークロードのリ ソース要件も含まれています。 コントロールプレーンは、マニフェストの情報を使用して、クラスター全体でポッド をスケジューリングする場所を決定します。
62. 62 EKS は ECS と同様に、EC2 ワーカーノードまたは Fargate でワークロードを起動でき ます。EKS を EC2 インフラストラクチャ上にデプロイした場合、 Kubernetes ワーカー ノードは、下図のように実質的に EC2 インスタンスになります。EKS は、クラスター を分離する仮想プライベートクラウド（VPC）で実行されます。
63. 63 EKS を使用すると Kubernetes コントロールプレーンノードを管理する必要がなくな りますが、Fargate 上で EKS を使用すると、さらに一歩進んで、ワーカーノードを すべて管理する必要もなくなります。Fargate プロファイルに記述されている仕様を 満たしている EKS ポッドの場合、AWS はポッドのリソース仕様に準じるサイズで、 Fargate による専用マネージドコンピュートリソースを使用して、そのポッドを起動 します。ポッド仕様にリソースリクエストが含まれていない場合、Fargate はデフォ ルトで最小のリソース仕様を使用してフリートからコンピュートリソースをプロビ ジョニングします。 Amazon EKS の監視方法 Amazon EKS のワークロードをスケーリングして運用する際には、クラスターとコン トロールプレーンのステータスを監視して、すべてがスムーズに稼働していることを 確認する必要があります。また、リソースの制約が原因で EKS がポッドの削除やワー クロードのスロットリングを行うことがないように、EKS のコンテナ、ポッド、 （該 当する場合は）ホスト全体のリソース使用量を監視することも重要です。 EKS ステータスの監視 Kubernetes API サーバーは、ポッドなどの Kubernetes オブジェクトの数量、ヘルス、 可用性について、クラスター状態情報を出力します。Kubernetes はこのデータを使 用して、望ましい状態にクラスターを近づけるためにポッドの起動、スケジューリン グ、終了が必要かどうかを決定します。
64. 64 Kubernetes はコントローラーを使用してクラスターの状態を管理します。コント ローラーの主なタイプは、DaemonSet と Deployment の 2 つです。DaemonSet （Fargate ではサポートされていません）は、特定のポッドがクラスター内のすべての ノード（または指定されたノードセット）で実行されるようにします。Deployment は、ワークロードを実行するための特定数のポッドを起動します。ポッドの状態は短 期的であるため、Deployment マニフェストでは一般にサービスも定義しており、こ れは Deployment で実行されているポッドへの永続的なアクセスを提供します。以 下のマニフェストは、3 つのポッドを作成し、それぞれが Redis コンテナを実行する Deployment を定義しています。また、この Deployment のポッドへのアクセスを可 能にするサービスも定義しています。 apiVersion: apps/v1 kind: Deployment metadata: name: redis spec: replicas: 3 template: metadata: labels: role: redis spec: containers: - name: redis image: redis:5.0 ports: - name: redis containerPort: 6379 --- apiVersion: v1 kind: Service metadata: name: redis labels: role: redis spec: ports: - port: 6379 targetPort: 6379 selector: role: redis Kubernetes は、使用しているコントローラーに応じて変化するクラスター状態 のメトリクスを発行します（たとえば、望ましいポッド数は、Deployment 内の kube_deployment_spec_replicas と、DaemonSet 内 の kube_daemonset_status_ desired_number_scheduled を比較することで測定されます） 。こうした少しの違い はありますが、クラスター状態に関するすべてのメトリクスによって、クラスター全 体のオブジェクトの状態が可視化されます。その際は、DaemonSet、Deployment、 または別のタイプのコントローラーとして実行されているかどうかは関係ありま せん。
65. 65 以下のクラスター状態メトリクスは、 ワークロードの起動に関する問題を明らかにし、 クラスターのサイズが適切であることを確認するのに役立ちます。EC2 ワーカーノー ド上で実行されているポッドにのみ適用されるメトリクスは、それに応じてマークが 表示されます。 望ましいポッド数と現在のポッド数の比較：すべてがスムーズに進んでいれば、これ らの数は一致するはずです。こうしたメトリクスが長期にわたって不一致のときにア ラートを出すことで、ポッドが失敗する原因となっている設定エラーなどの問題を検 出できます。ポッドのログを調べることで、トラブルシューティングのための非常に 有用な情報を得ることができます。 望ましいポッド数がクラスターで実行されていない場合は、ノードでリソース量の問 題が発生している可能性があります。EKS が EC2 インフラストラクチャにポッドを デプロイする場合、リソースリクエストに対応できるリソースがあるワーカーノード でのみポッドをスケジューリングします。ポッドを実行できるほど十分な利用可能リ ソースを持つノードがない場合は、保留中の状態でポッドが停止してしまうことがあ ります。その場合は、こうした問題に陥らないように、クラスターの自動スケーリン グポリシーを変更する必要があるかもしれません。EKS ポッドを Fargate にデプロイ する場合には、AWS がポッド専用のコンピュートリソースをプロビジョニングして、 ポッドのリソースリクエストに確実に対応できるようにするため、この問題はあまり 気になりません。
66. 66 ノードのステータス（EC2 のみ） ：このメトリクスは、EC2 インスタンスを使用して EKS ポッドを実行している場合にのみ適用されます。 各 EKS ワーカーノードは、 ステー タスの変化を検出するたびに、またはデフォルトでは 5 分ごとに（この間隔は設定可 能） 、以下のヘルス状態をコントロールプレーンに送信します。 – Ready ：ノードがポッドを受け入れる準備ができている場合に True になる – MemoryPressure：ノードメモリの空き容量が少なすぎる場合に True になる – PIDPressure：実行しているプロセス数が多すぎる場合に True になる – DiskPressure：残りのディスク容量が少なすぎる場合に True になる – NetworkUnavailable：ネットワークが適切に設定されていない場合に True になる Ready と NetworkUnavailable のチェックを監視することで、ポッドを実行できない ノードを検出し、そのノードに関するトラブルシューティングを行えるようになりま す。 ノードが Ready 状態で、 設定されているタイムアウト （デフォルトは 5 分） を超えても、 Unknown や False が返される場合は、Kubernetes がそのノードのすべてのポッドを 削除します。MemoryPressure または DiskPressure のチェックで、ノードが True を 返す場合は、kubelet がリソースの解放を試行します。 ポッドの容量（EC2 のみ） ：EKS では、インスタンスタイプによって、サポートされ る Elastic Network Interface（ENI）の数が決まり、各 ENI は有限数の IP アドレスしか サポートしません。各ポッドはそれぞれ独自の IP アドレスを持つため、どのノード やクラスターでも、限られた数のポッドしかサポートできません。 各インスタンスタイプで許可されている IP アドレスの最大数、つまりポッドの最大 数を追跡し、実行中のポッド数 / 望ましいポッド数や kubelet のポッド上限（デフォ ルトではノードあたり 110 ポッド） と比較することで、 フリート内のノード数をスケー ルアップする必要があるかどうかを判断できるようになります。
67. 67 利用可能なポッドと利用不可のポッド：利用不可のポッドが増えていることを検出し た場合や、特定のポッドが常に利用不可の状態である場合は、設定に問題がある可能 性があります。 たとえば、 リクエストの受け入れを開始する前に、 特定のタスク （キャッ シュをメモリにロードするなど）を完了するための時間をコンテナで確保するよう Readiness Probe を設定する場合があります。Readiness Probe の要求が厳しすぎる 場合（厳密には不要なサードパーティの依存関係を必要とするなど） 、ポッドが利用 不可になる可能性があります。詳細については、ポッドのログを参照してください。 利用不可のポッドは、クラスターに容量の問題があることを示唆している可能性があ ります。新たに起動したポッドを受け入れるのに十分なリソース量がノードにないか もしれません。クラスターが EC2 ワーカーノードで実行される場合に、リソース量の 問題でポッドがスケジューリングできないときは、Kubernetes Cluster Autoscaler を 使用して、より多くのワーカーノードをプロビジョニングできます。 コントロールプレーンの監視 コントロールプレーンが残りのクラスターと効率的に通信できない場合は、アプリ ケーションも適切に実行できません。EKS において、コントロールプレーンはフルマ ネージドであり、ビューから抽象化されたものですが、コントロールプレーンのメト リクスを監視してクラスター全体の問題を検出することは可能です。そのメトリクス には、API サーバーへのリクエストのレイテンシーや、Kubernetes と AWS 間の抽象 化レイヤーである AWS クラウドコントローラーマネージャーへのリクエストのレイ テンシーが含まれています。
68. 68 さらに細分化するには、コントロールプレーンの監査ログを収集して、API サーバー へのリクエストのうち、特定のタイプのレイテンシーを監視することもできます。 API サーバーは、Kubernetes の状態へのすべての変更を処理し、このアクティビティ を監査ログという形ですべて追跡するため、クラスターに影響を及ぼす重要な操作を さかのぼって調べるのに役立ちます。 EKS のようなマネージドサービスを運用している場合でも、自己ホスト型の Kubernetes クラスターを運用している場合でも、以下のコントロールプレーンデー タは、監視する上で特に役立ちます。 ユーザーあたりの累積 API クエリ時間：この情報は、監査ログから計算し、メトリク スに変換できます。このメトリクスは、API サーバーのレスポンスに時間がかかって いる場合に、特定のサービスやユーザーによるリクエストで API サーバーに過剰な負 荷がかかっているかどうかを検出するのに役立ちます。スケーリング操作を含むすべ てのリクエストが API サーバーを経由する必要があるため、API サーバーのレスポン スに時間がかかると、最終的にはユーザーに対するパフォーマンスが低下します。た とえば、API サーバーに過剰な負荷がかかっていると、Horizontal Pod Autoscaler は トラフィックの増加に対処できるほど迅速にポッドをスケールアップできないため、 アプリケーションのロードに時間がかかることがあります。
69. 69 このメトリクスで予期せぬスパイクが見られた場合、それらのクエリの発生元を調べ ることができます。これにより、設定に誤りがあるために、API サーバーに不必要に 高い負荷をかけているサービスを特定できるようになります。たとえば、kube2iam を使用していて、API サーバーへのクエリに異常に長い時間がかかっている場合（上 掲のグラフにおける青色のスパイク） 、最近何か設定に変更を加えたかどうかを確認 することで、詳細を調査できます。 kube2iam の各ポッドが、ローカルノード上で実行されているポッドだけでなく、ク ラスター内のすべてのポッドに関するデータについて API サーバーにクエリを実行す るよう誤って設定してしまった場合（--node flag を使用）API クエリ時間の増加を 監視することで、クラスターがダウンする前に、そのような問題を検出して修復でき ます。 スケジューリング期間：このメトリクスにスパイクが見られる場合、ポッドがノード でのスケジューリングに長い時間がかかっていることを意味し、これはアプリケー ションの他の問題に波及する可能性があります。
70. 70 また、 スケジューリングの試行回数を結果（エラー、 スケジュール内、 スケジュール外） ごとに分割して監視することもできます。スケジュール外のイベントが多数発生して いる場合は、設定ミスを示している可能性があります（テイントと容認が過度に制限 されており、スケジューラーがクラスター内で適切なノードを検出できないなど） 。 また、ポッドの要件を満たすほど十分な割り当て可能リソースがノードにないことを 示している可能性もあります。Kubernetes の監査ログを参照することで、スケジュー ル外のポッドの発生理由を判断できます。
71. 71 EKS リソースメトリクスの監視 EKS がノード全体にわたるポッドをスケジューリングすると、ノード上の利用可能な リソースをすべて使い果たし、ひいては CPU のスロットリングやポッドの削除を引 き起こすことがあります。Kubernetes のマニフェストには、各コンテナが使用する CPU（コア単位）とメモリの量を指定するリクエストと上限（リミット）を追加でき るオプションがあります。リクエストとはコンテナに割り当てられる CPU やメモリ の最小量のことであり、上限とはコンテナで使用可能な最大量のことです。ポッドレ ベルのリクエストと上限は、ポッドで実行されるコンテナのリクエストと上限を加算 して計算されます。 リソースのリクエストと上限を適切に指定することで、 それらをバランスよく維持し、 使用されないリソースに対して過剰なプロビジョニング（および支払い）をすること なく、ポッドが作業を実行するのに十分な利用可能リソースを確保できます。 以下のリソースメトリクスは、ポッドが正常で、スムーズに実行できることを確認す るのに役立ちます。 EC2 インフラストラクチャにポッドをデプロイする場合は、 各ワー カーノードのリソース使用状況も監視する必要があります。Fargate はこのインフラ ストラクチャレイヤーを抽象化しますが、 これはつまり、 注力する必要があるのはコン テナレベルとポッドレベルのリソースメトリクスだけでよいということです。 メモリ使用率：kubelet は、実行されているノードのヘルスを監視します。kubelet が ノードのメモリ不足を検出した場合（すなわち MemoryPressure のチェックで True が出力される） 、リソースを解放するためにポッドの削除を開始する可能性がありま す。このような状況において、リクエストを上回るメモリを使用しているポッドは、 削除候補になります。
72. 72 EC2 インスタンスで実行されるポッドのメモリ上限を指定しないと、ノードで利用可 能なメモリがすべて使用される可能性があります。このシナリオを回避するために、 メモリの上限、またはポッドが使用できるメモリの最大量を指定できます。メモリ使 用率と設定済みのメモリ上限を比較することで、実際の需要を満たすために上限を増 減させる必要があるかどうかを判断できます。メモリ上限を設定する際には、システ ムデーモンや kubelet 用のメモリを予約することを忘れないでください。 リソース使用率のメトリクスを監視することで、ポッドの仕様において不必要に高い リソース要件を設定するのを防ぐこともできます。Fargate は、ポッドのリソースリ クエストを使用して、それらのポッドにプロビジョニングするコンピュートリソース 量を決定します。ポッドのメモリ使用量が、リクエストした量を常に下回っている場 合は、EKS ポッドの仕様でリクエスト量を減らすことができることがあります。その ような場合、Fargate では、パフォーマンスを低下させることなく、より少なく低コ ストのコンピュートリソースで、ワークロードをスケジューリングできる可能性があ ります。 ノードあたりのメモリのリクエスト量と、ノードあたりの割り当て可能メモリ量の比 較（EC2 のみ） ：EC2 ノードで EKS ポッドを実行している場合、これらのメトリクス を比較してノードのサイズが適切かどうかを判断したり、ポッドの仕様でリソース要 件を調整する必要があるかどうかを確認したりするのに役立ちます。各ノードの割り 当て可能メモリは、そのノードで実行されているポッドにまだ割り当てられるメモリ 量を表します。割り当て可能メモリは、ワーカーノードのインスタンスタイプの全容 量と同じではありません。実際の値を計算するには、OS と Kubernetes のシステムプ ロセスで予約されているメモリ量を差し引く必要があります。 （すでにノードが実行されているポッドのメモリのリクエスト量を合計した後に） ポッ ドの最小メモリのリクエストに対応できるだけの十分な割り当て可能メモリがノード にない場合、ポッドはそのノードではスケジューリングできません。これら 2 つのメ トリクスを、望ましいポッド数と現在のポッド数と一緒に監視し続けることで、新し いポッドに対応できるだけの十分な容量がノードにない場合に検出できます。
73. 73 ディスク使用率：Kubelet がノードのディスク容量が少ないことを検出した場合（ DiskPressure のチェックを通じてなど） 、リソースを解放するためにポッドの削除が 始まる可能性があります。EKS ポッドが実行されているのが Fargate か EC2 かによっ て、ストレージの設定が異なります。Fargate は、各ポッド内のコンテナで共有でき る短期的なローカルストレージを提供します。永続的なストレージの場合、ポッドか らアクセスできる Amazon Elastic File System（EFS）ボリュームをプロビジョニング できます。EC2 を使用している場合、ポッドは EBS ボリュームを使用できます。EBS ボリュームは、EC2 インスタンスのルートボリュームか、永続的なストレージのため の永続的なボリューム（PV）のいずれかになります。これらのボリュームの使用レベ ルを監視することで、ボリュームを使用するサービスに影響が出る前に、潜在的な問 題を把握するのに役立ちます。 CPU 使用率：メモリとは異なり、CPU は圧縮可能なリソースであるため、ポッドが CPU の上限を超えた場合、ノード上の kubelet は、ポッドで利用可能な CPU の容量 をスロットリングしますが、 CPU の削除は行いません。高い CPU 使用率とアプリケー ションパフォーマンスのメトリクスを相関させることで、CPU のスロットリングが ユーザー向けサービスの速度低下を引き起こしているかどうかを把握できるようにな ります。
74. 74 また、CPU 使用率を監視すると、ポッドのワークロードへのクラスターの適合性を向 上させるためには、CPU のリクエストと上限を調整する必要があるのか、それとも自 動スケーリングポリシーを調整する必要があるのかを判断できるようにもなります。 ノードあたりの CPU リクエスト数とノードあたりの割り当て可能 CPU 数 の比較 （EC2 のみ） ：割り当て可能な CPU は、ノード上で新たにスケジューリングされたポッ ドに対応するために利用可能な CPU リソースの量を測定します。Kubernetes は CPU をコア単位で測定します。EKS クラスターで 1 つの CPU コアは、EC2 インスタンス での 1 つの AWS vCPU に相当します。リクエストされたコア数と、ノードで利用可能 な vCPU 数を比較することで、キャパシティプランニングに役立つ情報を得ることが できます。下図は、各ノードで実行されているポッドの CPU リクエスト数の合計を、 インスタンスタイプに基づいて、ノードあたりの割り当て可能な最大 CPU 数（青色 の表示）と比較したものです。 ネットワークインとネットワークアウト ： EKS では、ポッド同士、およびポッドとコン トロールプレーン間で正常に通信できるように、ネットワークを設定します。ポッド との送受信および（EC2 を使用している場合は）ノードとの送受信のトラフィックを 監視することで、修正が必要なネットワーク問題があるか判断できます。 また、 ネットワークのメトリクスをロードバランサーのメトリクスと相関させて、 ネッ トワーク問題が負荷分散のエラーに関連しているか確認することもお勧めします。 Fargate で現在サポートしているのは Application Load Balancer（ALB）だけですが、 EC2 インスタンスでは、ALB のほか、Classic Elastic Load Balancer と Network Load Balancer も使用できます。
75. 75 オーケストレーションされた クラスターをサポートする AWS サービスの監視 Amazon ECS や EKS のようなマネージドオーケストレーションサービスを使用している 場合でも、EC2 インスタンスでコンテナをセルフ管理している場合でも、クラスターが 依存している可能性が高いのは、 AWS クラウドにおける以下のような別のサービスです。 – Amazon EC2：EKS ワーカーノードや ECS コンテナインスタンスをプロビジョ ニング – Elastic Load Balancing – AWS Auto Scaling：クラスターを動的にスケーリング – Amazon EBS ： EC2 インスタンス上で実行されている ECS や EKS のワークロー ドに永続的なストレージボリュームを提供 – AWS App Mesh：アプリケーションネットワーキング向け – AWS CloudFormation：インフラストラクチャをコードとしてデプロイ – Amazon Elastic Container Registry：コンテナイメージを管理 包括的な監視ソリューションは、オーケストレーションされたアプリケーションやそ れらが依存しているサービスのすべてのレイヤーにわたって可視化できます。次に、 Datadog がどのようにしてクラスターからのメトリクス、トレース、ログ、そしてク ラスターが実行しているサービスを統合し、1 つのプラットフォームでコンテナワー クロードに関する深く有用な情報を得られるようにしているかを探ります。
76. 76 AWS コンテナ環境の 包括的な監視 オーケストレーションされた環境は複雑かつ短期的であり、監視すべき抽象化レイ ヤーが数多く存在します。完全な運用監視を実現するには、インフラストラクチャ全 体で、コンテナのスピンアップ、シャットダウン、シフトに合わせて、コンテナを動 的に追跡する必要があります。 マ ネ ー ジ ド サ ー ビ ス を 実 行 し て い る 場 合 で も、 自 社 の EC2 イ ン ス タ ン ス で Kubernetes クラスターをホスティングしている場合でも、Datadog は、以下のよう にさまざまな方法で、オーケストレーションされた環境のあらゆるコンポーネントか ら運用監視データを収集できるようにします。 – EC2 および Fargate で実行されている Amazon ECS タスク – EC2 および Fargate にデプロイされた Amazon EKS のポッド – kube-state-metrics（クラスター状態のメトリクス向け） 、 Metrics Server（コン テナとノードからのリソース使用状況のメトリクス向け） 、コントロールプ レーンデータによる Kubernetes 環境 – Amazon EC2、AWS App Mesh、Elastic Load Balancing、Amazon EBS などと のターンキーインテグレーションにより、オーケストレーションされたクラ スターをサポートする AWS サービス
77. 77 このセクションの前半で説明したメトリクスに加え、オープンソースの Datadog Agent を使用して、クラスター内のコンテナ、ポッド、ノードから分散トレースとロ グを収集できます。Datadog プラットフォームでは、これらすべてのデータソース を容易に相関付けて、アプリケーションに関する知識を深めることができます。た とえば、下図のログでは、ノードが DiskPressure のチェックで True を返した後に、 kubelet がリソースの解放を開始したことを示しています。このログから直接 [Metrics （メトリクス）] タブをクリックすると、ノードから収集した相関性のあるリソース使 用率メトリクスが表示され、より詳細なコンテキストを得ることができます。 Agent には、Redis や NGINX などのクラスターで実行されているサービスの監視を自 動的に設定する Autodiscovery 機能も含まれています。また、何百ものインテグレー ションを設定して、自社環境のすべてのシステム、サービス、コンポーネントからテ レメトリデータを収集することもできます。これらのインテグレーションの詳細につ いては、ドキュメントを参照してください。
78. 78 コンテナスタックの可視化 クラスターからのリアルタイムの監視データを Datadog で収集したら、以下を使用し て、コンテナアプリケーションとインフラストラクチャをすぐに可視化できます。 – すぐに使えるダッシュボード：Amazon ECS、Kubernetes、その他のサービ ス向けに使用できる – ライブコンテナビュー：プロセスレベルの詳細な知識を得ることができる – コンテナマップ：コンテナインフラストラクチャを俯瞰的に表示できる カスタマイズ可能なダッシュボード Datadog では、Amazon ECS、Kubernetes、およびその他のサービス向けに、すぐに 使えるダッシュボードを提供しているため、環境の主要なメトリクスを素早く可視化 できます。ECS ダッシュボード（下図参照）には、クラスター内のタスクやコンテナ のステータス、サービスイベントやリソース使用率のメトリクスが表示されます。ス タックの可視化を強化するために、あらゆるダッシュボードのクローンを作成してカ スタマイズし、ロードバランサー、データベース、その他のサービスからの関連デー タを含めることができます。
79. 79 ライブコンテナビュー Datadog のライブコンテナビューでは、すべてのコンテナからリアルタイムのリソー ス消費メトリクスが表示されます。テレメトリデータは、Amazon CloudWatch や Kubernetes ラベルなどのソースから Datadog がインポートした豊富なメタデータで 自動的にタグ付けされます。Datadog を使用すると、統一されたサービスタグ付け を 実装することもできます。これにより、すべてのテレメトリデータに対し、クリティ カルタグ（env、service、version）を付け、相関させて操作できます。これらのタ グやその他のタグを使用して、Kubernetes Deployment や ECS タスクファミリーな ど、あらゆる要素に関してライブコンテナビューをグループ化およびフィルタリング し、個々のコンテナにドリルダウンして問題をデバッグできます。Datadog Agent は、 2 秒の解像度でコンテナからメトリクスを収集するため、アプリケーションのどこか で問題を引き起こしている可能性のあるリソース使用量の重要なスパイクを特定でき ます。
80. 80 コンテナマップ Datadog コンテナマップでは、コンテナインフラストラクチャ全体を俯瞰的に表示で きます。 コンテナレベルのメトリクスを選択し、 タグでグループ化およびフィルタリン グすることで、環境のあらゆる要素に関してホットスポットを特定できます。以下の 例では、ECS タグを使用して特定の task_family をフィルタリングしてから、それら のコンテナを task_version でグループ化しています。これにより、 タスクバージョン 2 の ECS コンテナでは、タスクバージョン 1 のコンテナと比較して大量の CPU を使 用していることを見つけることができます。これは、バージョン 2 には、CPU 使用量 を増加させるような変更を含んでいる可能性があることを示しています。デバッグを 続けるために、チームはコードの変更を確認し、更新が必要かどうかを判断できます。 コンテナマップは、自社がベストプラクティスに従っているかどうかを把握するのに も役立ちます。Kubernetes の推奨事項は、デフォルトの latest にするのではなく、 コンテナのイメージタグごとにバージョン番号を明示的に定義することです。これに より、自社環境で実行されているバージョンを追跡できるため、更新してリグレッ ションや設定エラーが発生した場合に、安定したバージョンに戻すことができます。 下図では、corp-site という Kubernetes サービスを image_tag でグループ化するこ とにより、latest のバージョンを使用しているコンテナの数を確認できます。推奨 されている特定のイメージダイジェストを使用する場合とは対照的です。
81. 81 自動アラート モニターは、 アプリケーションの高レイテンシーから、 メモリ不足エラーなどのリソー ス量の問題に至るまで、自動的に問題を追跡するのに役立ちます。ここでは、オーケ ストレーションされたクラスター内の潜在的な問題を即座に顕在化させることができ るアラートの例をいくつか紹介します。 Datadog を使用すれば、モニターを作成して、終了したポッド、Kubernetes ノード での大量のディスク使用量、CrashLoopBackoff ステータスのポッドなど、重要な問 題について自動的にチームに通知できるようになります。以下の例では、複数のコン テナがメモリの上限に達したために終了したことを検出するモニターを構成していま す。
82. 82 以下のモニターは、一定時間にわたり少なくとも 1 つのノードが Unknown の状態の ままであることを Datadog で検出すると、チームベースの Slack チャンネルに通知を 送信します。このモニターでは、Kubernetes のテレメトリデータは環境ごとにタグ 付けされるため、ステージングからのデータは除外されます。 ノードコントローラーが一定時間（デフォルトでは 40 秒）にわたってノードからレ スポンスを受信できない場合、 そのノードの状態を Unknown としてマーク付けします。 ノードが特定の期間（設定した pod-eviction-timeout の長さ）にわたって Unknown の状態が続くと、ノードコントローラーはノード上のポッドの削除を開始します。 Unknown の状態に陥っているノードについてアラートを受け取るよう Datadog を設 定することで、ポッドが削除される前に、問題を検出して解決できます。 包括的な監視を行う上で、アラートは重要な要素ですが、それはパズルの 1 つのピー スに過ぎません。アラートを受信したらすぐに問題を調査できなければなりません。 Datadog を使用すると、コンテナ化されたアプリケーションから、相関関係のあるメ トリクス、分散トレース、ログを容易に操作できるようになり、インシデント対応プ ロセスが促進されるため、根本原因分析に必要なすべてのコンテキストを得ることが できます。
83. 83 全体監視とインシデント対応 複雑な分散型システムを運用している場合、障害や停止は避けられません。動的で短 期的な環境では、リソースの容量問題やスケジューリングのエラーについてすべてア ラートを出すことは不可能です。特に、Kubernetes は自己修復するよう設計されて おり、多くの問題が自動的に解決される可能性が高くなっています。 アラート疲れを軽減するには、ユーザーに直接影響するとは限らない根本的な原因で はなく、問題の現象に対してアラートを発行することをお勧めします。つまり、たと えば、 ユーザーエクスペリエンスの低下につながるとは限らないリソースの問題 （CPU 使用率が高いなど）ではなく、ユーザーが直面するエラーやパフォーマンスの問題 （ロード時間が非常に長い、アプリケーションのエンドポイントにアクセスできない など）に対してアラートを発行するということです。アラート通知の中に、調査に役 立つリソースとして、ダッシュボードへのリンクを含めることができます。 ここでは、Kubernetes でオーケストレーションされた環境における可用性の問題を 調査する方法の例を見ていきましょう。ユーザー向けエンドポイントにおいて 500 件 もの高率のエラーが発生したというアラートを受信したとします。これは何か誤りが あることを示す重大な兆候です。このエンドポイントでは、 Elasticsearch を使用して、 ユーザーにデータのクエリと表示を行っています。アラート通知には、このサービス のために構築したダッシュボードへのリンクが含まれていたため、何が起こっている かを素早く把握できました。ダッシュボードでは、サービスでの 500 件のエラーとほ ぼ同時期に Elasticsearch のクエリエラーが高率で発生したことがわかります。
84. 84 コンテナレベルのリソースメトリクスは、Elasticsearch のデータポッドで「CPU ス ロットリング」と「検索スレッドプールでの拒否」の増加があることを示していま す。Elasticsearch はスレッドプールを使用して、ワークロードを管理しています。処 理しきれないほど多くのリクエストを受け取ると、それらをスレッドプールのキュー に追加します。この場合、検索スレッドプールのキューが最大サイズに達したため、 Elasticsearch はリクエストを拒否し始めました。 問題の周辺の状況をより詳細に把握するために、Datadog APM でサービスレベルの ダッシュボードを確認することにします。このダッシュボードから、最近になってこ のサービスが異常に多いクエリを受信するようになったことがわかります。
85. 85 リクエストスループットのメトリクスを version タグごとに分類すると、最新のリ リース（青色）は明らかに、以前のリリース（灰色）に比べて、クエリのスループッ トが向上していることがわかります。さらに詳細に調査するために、そのバージョン で更新されたアプリケーションコードを調べます。すると、検索クエリをあまりにも 積極的に再試行する（バックオフロジックを使用せずに、最大 6 回）という不具合を 見つけました。これが、Datadog APM ダッシュボードで見られたリクエスト率の増加 の原因です。 調査の一環として、このクラスターで設定されたリソースのリクエストと上限につい ても詳しく調べることにします。そして、使用中の EC2 インスタンスタイプの CPU 容量よりも、CPU の上限が大幅に低いことを見つけます。Kubernetes は、コンテナ が不必要に低い CPU の上限に達するたびに、ノードがまだ CPU の全容量を使用して いないにもかかわらず、コンテナの CPU をスロットリングしていました。
86. 86 このクラスターではノードごとに Elasticsearch ポッドを 1 つだけスケジューリング するよう Kubernetes を設定しているため、実行中の EC2 インスタンスの CPU 容量を コンテナでより多く活用できるように、CPU の上限を引き上げることにしました（た だし、システムデーモンと kubelet を実行するための CPU 容量は予約したままとして おきます） 。CPU の上限を高く設定し、再試行ロジックの不具合を修正すると、サー ビスが回復します。このサービスレベルのダッシュボードには、ポッドレベルの CPU 使用率と CPU 上限のメトリクスが自動的に含まれるため、将来的に、CPU スロット リングとアプリケーションのパフォーマンス問題と相関性があるかどうかを容易に見 極めることができるようになります。
87. 87 動的な環境のフルスタック運用監視 このセクションでは、Amazon ECS や Amazon EKS などのマネージドオーケストレー ションサービスが、コンテナワークロードを大規模にデプロイするのにいかに役立つ か、そして、これらの各サービスを使用する際に監視すべき主要なメトリクスについ て説明してきました。また、Fargate がサーバーレスのコンピュートエンジンで ECS コンテナや EKS コンテナを実行するオプションを提供し、独自のインフラストラク チャを管理する必要性を軽減することも解説しました。 マ ネ ー ジ ド サ ー ビ ス を 使 用 し て い る 場 合 で も、 自 社 の EC2 イ ン ス タ ン ス で Kubernetes を運用している場合でも、ユーザーが直面する問題をトラブルシュー ティングするためには、フルスタックの運用監視が非常に重要となります。Datadog がスタックの全レイヤーからテレメトリデータを集約することで、不良コードのデプ ロイから Kubernetes のリソース上限の設定ミスに至るまで、重大な問題における潜 在的な根本原因を効果的に調査できるようになります。 参考資料 コンテナ化されたアプリケーションの監視の詳細については、以下のリソースを参照 してください。 – Amazon ECS monitoring guide（Amazon ECS 監視ガイド） – Amazon EKS monitoring guide（Amazon EKS 監視ガイド） – Kubernetes audit logs monitoring guide（Kubernetes 監査ログの監視ガイド） お使いの環境でこれらの監視戦略を実践したい場合は、www.datadog.com において、 Datadog のフル機能を利用できるトライアル版をお申し込みください。