マネージドサービス部 佐竹です。
今回は、AWS Compute Optimizer で Datadog のメトリクスを実際に取り込んで精度を向上させることができたことのご報告ブログになります。
- はじめに
- AWS Compute Optimizer に Datadog のメトリクスを取り込む設定
- AWS Compute Optimizer が Datadog の情報を正しく参照できた場合
- まとめ
はじめに
re:Invent 2022 期間中に以下のアップデートが発表されました。
これは「AWS Compute Optimizer で、可観測性パートナー 4 社 (Datadog、Dynatrace、Instana、New Relic) が提供する外部パフォーマンスメトリクスがサポートされるようになりました」という文面から始まっている通り、外部の監視サービスのメトリクスを AWS Compute Optimizer に連携させることで、その結果精度を向上させることができるようになった、という画期的なアップデートでした。
AWS はこの発表と同時に上記ブログもリリースしており、この中では「ACP Proxy Layer」という概念が図示されています。このレイヤーの役割は、各外部サービスのメトリクスを Amazon Kinesis Data Firehose を利用して Amazon S3 にデータを連携するというものです。
さらに本機能を AWS が無料で実現してくれました。
本題に入る前に、以下でこのアップデートに関するこれまでの状況を振り返りましょう。
AWS Compute Optimizer におけるメモリの重要性
AWS Compute Optimizer では CloudWatch Agent のメモリメトリクスを利用することで、その精度を向上させることができます。
具体例としては以下のように改善されます。
- メモリが参照できない場合の推奨はメモリを維持する
- m5.xlarge(Memory 16GB) ⇒r5.large(Memory 16GB)
- CPU 分のコストは削減されるが、メモリが維持されている分推奨(コスト最適化効果)は完全ではない
- メモリが参照できる場合の推奨はメモリを鑑みて推奨が変化する
- m5.xlarge(Memory 16GB) ⇒m5.large(Memory 8GB)
- メモリを含めて推奨されるため、よりコスト最適化効果が高い
上記の通り推奨の精度が改善されるため、コスト最適化効果もより高くなります。
このようにインスタンスのメモリが参照できているかどうかは、AWS Compute Optimizer の運用において非常に重要となっています。
そして本アップデートの後は、例えば Datadog Agent がインストールされていれば、Datadog Agent が CloudWatch Agent と同じ働きをしてくれることになりました。
これまでは Datadog Agent がインストールされていても直接 AWS Compute Optimizer がそのメモリを参照できなかったため、Compute Optimizer の推奨改善には CloudWatch Agent のインストールも必要になってしまっていました。正直、運用上の手間でしかなく、エンドユーザ様にもなかなかお勧めできるものではありませんでした。
しかし、それが不要となったのです。コスト最適化(及び持続可能性)の点でも、運用という観点においても、これはとても喜ばしいことです。
関連するブログ
なお、CloudWatch Agent のメモリメトリクスに関しては、以下のブログに詳しく記載していますため合わせてご覧ください。
何故ブログの公開が4月になったのか
さて、それだけ素晴らしいアップデートであればすぐに検証してすぐにブログにするのが私のモットーというところですが、本機能には課題がありました。
現在は大部分が解消済ですが、この機能は4月上旬まで AWS 側にも、Datadog 側にもどちらにも不具合があり、一部において正しく動作させることができませんでした。弊社で12月上旬から5か月かけてやっと(特に Windows OS において)正常動作までこぎつけることができましたので、その記念のブログとなります。
AWS Compute Optimizer に Datadog のメトリクスを取り込む設定
では早速、具体的な設定手順をご紹介します。
まずは、Datadog の公式手順を以下にご紹介します。
基本的にはこの手順の通りに進めます。
AWS 側の設定
「AWS Compute Optimizer のコンソールで、Accounts ページに移動し、外部メトリクス取り込みのアカウントレベルのプリファレンスを Datadog に設定する」と記載がある通り、まずは AWS アカウントで作業が必要です。
AWS Compute Optimizer の「Accounts」を開き、最下部に移動します。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411123542.png)
最下部に「Account-level preferences for external metrics ingestion」という設定が追加されていますので「Edit」を押下して設定画面を開きます。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411124702.png)
「External metrics ingestion」はデフォルト「No external metrics provider」になっているため、これを今回は「Datadog」に変更します。ラジオボタンを選択したら「Confirm」を押下して設定を終えます。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411124751.png)
「External metrics source」が Datadog になったことを確認したら、AWS 側の設定はこれで終了です。
Datadog 側の設定
次に Datadog 側の設定を行っていきます。
Amazon Web Services インテグレーションをインストール
まずは Datadog のコンソールから、AWS のインテグレーションを設定します。
既に Datadog を AWS リソースの監視に利用されている場合はこの設定は既に完了していると思われますが、念のため確認ください。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411131544.png)
確認画面としてはインテグレーションの一覧で「Installed」となっていれば問題ありません。インストールが完了していない場合、インストールボタンを押下して AWS インテグレーションをインストールしてください。
Datadog - AWS Compute Optimizer インテグレーションをインストール
次に AWS Compute Optimizer インテグレーションを設定します。
本来の手順とは順序が異なるのですが、先に行っても問題ないため、先の作業と同時に Datadog において「AWS Compute Optimizer インテグレーション」をインストールしてください。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411131835.png)
インストール後は先ほどと同様、AWS Compute Optimizer の項目がインテグレーションの一覧で「Installed」となっていることを確認します。
EC2 インスタンスに Datadog Agent をインストール
AWS Compute Optimizer との連携には、EC2 インスタンスに Datadog Agent がインストールされている必要があります。
こちらも既に Datadog を AWS リソースの監視に利用されている場合には、エージェントのインストールは既に完了していると考えられますが、対象のインスタンスにインストール済かどうか、念のため確認ください。
Metric Collection で EC2 を有効化する
ここまでの設定が終わっても、実際のところ Datadog と AWS Compute Optimizer との連携はうまくいきません。
次に、「DOCS>INTEGRATIONS>AMAZON EC2」に記載のある「Metric Collection で EC2 を有効化する」作業を行います。
これは、Datadog に Amazon EC2 の CloudWatch メトリクスを取り込ませるために必要な設定です。これが行われていないと、AWS Compute Optimizer が正しく動作しません。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411135945.png)
上図の通り、EC2 を有効にします。今回は「EC2/API」も(念のため)合わせて有効化してあります。
補足ですが、この設定の有効化においては懸念点があります。これを有効化すると、全ての EC2 インスタンスの CloudWatch メトリクスが Datadog へと連携されてしまい、台数によっては負荷や費用に懸念があります。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411140224.png)
その懸念がある場合は、「Limit Metric Collection to Specific Resources」を利用し、タグが付与された一部のリソースにメトリクスの取得を留めておくことが可能です。今回は画像の通り「Managedby:Serverworks」というタグキーとバリューが付与されているリソースだけに留めることとしました。
Datadog 側の設定確認
上記の設定が完了すると、Datadog の「Infrastructure List」において各 EC2 インスタンスに「AWS アイコン」と「Datadog アイコン」がそれぞれ表示されるはずです。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411141054.png)
この2つのアイコンが揃って表示されている場合、正しく設定が完了しています。
この状態で、AWS Compute Optimizer のデータが収集されるまで、目安として「7日間から14日間」ほど待機しましょう。
AWS Compute Optimizer が Datadog の情報を正しく参照できた場合
正しく設定が完了した状態では、AWS Compute Optimizer 上で以下のように結果が表示されます。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411141719.png)
結果一覧の「External metrics source Info」に「Datadog」と文字が表示されたら正しく動作できています。
Memory utilization がグラフで閲覧可能
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411142612.png)
正しくメモリが参照できており、表示上の問題もない場合は上図の通り「Memory utilization (percent)」が図示されます。また、それが「Over-provisioned」であればそのように合わせて表示も行われます。
Memory utilization がグラフで閲覧不可能な場合
![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/swx-satake/20230411/20230411142917.png)
「Memory utilization (percent)」に「Over-provisioned」と表示がされている通り、正しく分析はできているものの To enable memory metrics on this instance, install the Amazon CloudWatch agent or add a supported third-party product.
という表示のままとなってしまうインスタンスも現在は存在します。
どうやらこれは AWS 側の表示の不具合だそうですが、メモリのグラフは見られないものの推奨結果としては正しく動作できているとのことです。
AWS CLI を使ったメモリ値の確認
このような場合に「メモリが表示されていないだけなのかどうか?」を確認したい場合があると思います。その場合には、AWS CLI で確認が可能です。
以下が実行例となります。返り値の JSON はかなり長いため、途中でカットしました。アカウント ID やインスタンス ID はダミー値です。
aws compute-optimizer get-ec2-instance-recommendations --instance-arns arn:aws:ec2:ap-northeast-1:123456789012:instance/i-03503503503503549
{ "instanceRecommendations": [ { "instanceArn": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-03503503503503549", "accountId": "123456789012", "instanceName": "DevEC2Instance", "currentInstanceType": "m5.large", "finding": "UNDER_PROVISIONED", "findingReasonCodes": [ "CPUUnderprovisioned", "MemoryOverprovisioned" ], "utilizationMetrics": [ { "name": "CPU", "statistic": "MAXIMUM", "value": 98.89166666666668 }, { "name": "MEMORY", "statistic": "MAXIMUM", "value": 32.249999046325684 }, { "name": "EBS_READ_OPS_PER_SECOND", "statistic": "MAXIMUM", "value": 891.4166666666666 }, { "name": "EBS_WRITE_OPS_PER_SECOND", "statistic": "MAXIMUM", "value": 1544.6 }, { "name": "EBS_READ_BYTES_PER_SECOND", "statistic": "MAXIMUM", "value": 20775691.731770832 }, { "name": "EBS_WRITE_BYTES_PER_SECOND", "statistic": "MAXIMUM", "value": 23774747.721354168 },
というわけで、"name": "MEMORY" とある通り取得できていることが確認できました。
この不具合が修正されればもっと見栄えもよくなりそうです。
まとめ
今回のブログでは re:Invent 2022 で発表されたアップデートに関連して、実際に AWS Compute Optimizer で Datadog のメトリクスを取り込んで精度を向上させることができたことを証跡として記載しまとめました。
またそのために必要な設定についても、Datadog の公式ドキュメントに記載がない点も含め、注意事項を踏まえて記載しました。
現在、一部 AWS 側で表示がうまく行かない部分も残っているようですが、使用には十分耐える状態ですため是非 Datadog を利用されているお客様は AWS Compute Optimizer と連携を行いコスト最適化を進めて頂ければ幸いです。
では、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。