マネージドサービス部 佐竹です。
AWS re:Invent 2023 期間中、AWS Compute Optimizer のコンソール画面に新たに「Rightsizing preferences」という設定ページが追加されました。本日はこれについて解説していきます。
- はじめに
- Rightsizing preferences で何が可能になったのか
- まとめ
はじめに
EC2 インスタンスや EBS ボリュームのコスト最適化に役立つサービスが「AWS Compute Optimizer」です。
本機能は Savings Plans や Reserved Instances を購入する前に利用することをお勧めしており、我々も日々の業務でお客様と共に推奨を確認し、ディスカッションしながらコスト最適化を推し進めております。
これまで、本エンジニアブログでは様々な AWS Compute Optimizer のアップデートをご紹介してきましたが、昨年に引き続き AWS re:Invent 期間中に機能追加がありました。
以下がそのアナウンスページです。
本アップデートについて詳しく見ていきます。
Rightsizing preferences で何が可能になったのか
最初にまとめ
AWS Compute Optimizer の「rightsizing recommendation preferences」機能を使用することで、 AWS Compute Optimizer が生成する推奨結果をユーザの好みに近づけることが可能になりました。
ただし、対象は Amazon EC2 および Auto Scaling グループにおけるインスタンスの推奨事項に限られます。
以下が機能の概要です。
- AWS Organizations ( AWS アカウントレベルの設定反映) に対応しており、またリージョン指定での設定が可能
- 特定のインスタンスファミリーを推奨結果から除外することが可能になった
- 無料の分析期間に新たに「32日間」が追加された
- CPU 使用率の「Threshold」と「Headroom」を組み合わせてのカスタマイズが可能となった
AWS マネジメントコンソールの画面を用いた説明
AWS Compute Optimizer のコンソール画面左下に「Rightsizing」が追加されています。
ここから新たに追加された設定が利用できるため、順にマネジメントコンソールのキャプチャを添えながらご説明します。
Preference level (Organizations only)
まず「Preference level (Organization)」は、AWS Organizations に統合された機能です。
マネジメントアカウントもしくは委任された administrator アカウントであれば「組織の全アカウントでその設定を反映させる」のか「特定のアカウント1つのみに設定するのか」が選択可能です。全 AWS アカウントで同じ設定を施したい場合は、「All opted-in accounts」で設定が可能です。
続けて「Edit」を押下して進めます。
Regional scope
設定のデフォルトは「Any region」となっており、全てのリージョンに本設定が反映されるようになっています。
ただし「Custom regions」を選択することで、特定のリージョンのみに影響を限定することも可能です。
Preferred EC2 instances
デフォルトは「Any instance type」です。
AWS Compute Optimizer は、対応している全てのインスタンスタイプを推奨の結果に利用します*1。
これを「Limit to specific instance types and sizes」に変更し、不要なインスタンスファミリー（コンソールでは Instance Type と記載されている）を除外することが可能となりました。
これは一例ですが「g」と検索し、チェックボックスを外して対象から除外することで、Graviton をまとめて推奨から取り除くようなこともできます。ただこの例では「g4dn」まで除外しないよう注意が必要です。
コンソール最下部には Automatically consider future variations of the instance families selected というオプションがあります。
デフォルトが「オン」のこのオプションは、今後新たに AWS Compute Optimizer に対応したインスタンスタイプが追加された場合に、それを自動的に推奨事項に含めるかという設定です。
設定を「オフ」にすることで、「新しく Compute Optimizer に対応したインスタンスタイプが自動的に推奨に含まれる」ということを防ぐことが可能です。
本機能の有効な使い道ですが、例えば、EC2 Instance Savings Plans を組織的に利用されている場合に、そのインスタンスファミリー以外を推奨から除外するような使い方が考えられます。そのようにしておけば、EC2 Instance Savings Plans が無駄になる可能性を少しでも下げることができるでしょう。
Lookback period and metrics
Lookback period
分析のために利用する期間はこれまでデフォルトの14日間と、有償 (paid feature) の93日間のみでしたが、新たに32日間が追加されました。
以下が現在の選択肢です。
- 14 days (default)：無料
- 32 days：新規に追加された設定で無料
- 93 days (via enhanced infrastructure metrics)：paid feature
メトリクス分析対象の期間を14日よりも伸ばしたいユーザには朗報となるアップデートです。
なおデフォルトで「93 days」 はグレーアウトしており選択ができません。93日間の Lookback period を有効とするには「Enable enhanced infrastructure metrics」を押下して設定を行う必要があります*2。
CPU utilization presets
以下の4つのプリセットから、CPU 使用率の分析傾向を設定することが可能です。
- Maximum savings
- Balanced
- Default
- Maximum performance
また、プリセットを利用せず「Threshold（しきい値）」と「Headroom（バッファー*3）」を個別に組み合わせて「カスタム」として利用することもできます。
ではこれらの4つプリセットの組み合わせがどのような特徴を持っているのか AWS 公式ドキュメントを参考にそれぞれ見ていきます。
Maximum savings / 最大に節約したい場合
※グラフは説明用の例であり、実際のインスタンスの使用率を示しておりません
しきい値は P90 に設定され、ヘッドルームは 0% に設定されます。これにより、ワークロードのパフォーマンスはバッファーなしで推奨事項が提供されます。
この設定では、使用率の履歴から最も高いデータポイントの上位 10% が削除され、将来の使用量の増加に備えて追加のバッファーが予約されないため、レイテンシが高くなったり、パフォーマンスリスクが大きくなったりする推奨事項が生成される可能性があります。
Threshold の設定を掘り下げる
ここで「使用率の履歴から最も高いデータポイントの上位 10% が削除され」という文章について補足しておきます。
AWS 公式ドキュメントを読んでも remove もしくは ignore という単語の理解が難しいのですが、コスト最適化のためにインスタンスタイプを下げる目的で機能の実装を想像すると「100%付近の利用率を無視したほうが良い場合がある」ということが理解できると思います。
具体的に考えてみましょう。
上図のような CPU 使用率を持つインスタンスがあるとします。このグラフを見るに「2023/11/7」だけが突出して CPU が高騰しています。しかしそれ以外の日は、総じておよそ 40% 以下に落ち着いています。
もし、この CPU 使用率が「何らかの特殊なオペレーション」によるものであれば、これを無視し分析することでインスタンスタイプのスペックダウンが可能でしょう。
実際に、この値を無視してインスタンスタイプを半分のスペックへと変更した場合の想定される CPU 使用率は以下の図になります。
もともと 20% であった CPU 使用率はスペックダウン後に 40% へ、また 40% の CPU 使用率 は 80% へ増加します。
このように、スペックを引き下げた後も基本的には安定して稼働してくれそうなことが分かります。そしてThreshold の「P90、P95、P99.5」はそれぞれ、その切り捨てをどこでやるかという設定となっています。
つまり「P99.5」が最もセンシティブで保守的な設定であり、「P90」はかなり攻めた設定であることが理解できるでしょう。
Balanced / バランス型
しきい値は P95 に設定され、ヘッドルームは 30% に設定されます。この推奨事項では、95% 以上の時間にわたって、CPU 使用率が 70% 未満にとどまることを目標としています。
これはほとんどのワークロードに適しており、デフォルト設定よりも多くの節約の機会を特定できます。もし、利用率の急激な上昇に特別センシティブではないワークロードであれば、これはデフォルトの設定に対する良い代替案となります。
Default / デフォルトの設定
しきい値は P99.5 に設定され、ヘッドルームは 20% に設定されます。これらの設定は、99.5% 以上の時間にわたって CPU 使用率が 80% 未満に維持されることを目標としています。
これにより、パフォーマンスの問題が発生するリスクは非常に低くなりますが、節約の機会が制限される可能性があります。
Maximum performance / パフォーマンスを優先する
しきい値は P99.5 に設定され、ヘッドルームは 30% に設定されます。
これにより、デフォルト設定と比較してワークロードのパフォーマンスバッファーが高くなる推奨事項が提供されます。
CPU usage の所感
基本的にはデフォルトのまま運用頂ければこれまでと変わらない精度でご利用頂けます。
ただ、記載が合った通り「Balanced」にすることでより多くのコスト最適化のチャンスが得られる可能性があります。このため一度「Balanced」に変更し、どのように結果が変わるのか変化をみて頂くのも1つの手だと感じます。
カスタム設定にはなりますが「Threshold が P95」かつ「Headroom が 20%」という組み合わせがないため、「Maximum savings」と比較した「Moderate savings」としてこの組み合わせも良いのではと感じました。
設定保存後24時間以内に反映がされる
設定は「Save Preferences」を忘れずに押下し反映してください。
また以下の AWS 公式ドキュメントに記載がありますが、本設定の反映は24時間以内に順次反映とのことでした。
まとめ
本ブログでは AWS re:Invent 2023 期間中に発表された「AWS Compute Optimizer」の新機能である「Rightsizing preferences」についてご紹介しました。
特に、Compute Optimizer のメトリクス分析期間が32日間まで無料で延長できるオプションが追加されたのが嬉しいですね。というのも、利用者様からは「分析期間が14日間（2週間）では少し心もとない」という言葉を頂くことも多いためです。
また、CPU usage の閾値とバッファーをそれぞれカスタムすることが可能となったため、例えば「本番環境は Maximum performance」そして「検証環境は Maximum savings」という設定の使い分けも可能となりました。
加えて、特定のインスタンスファミリーを除外することで、EC2 Instance Savings Plans を組織的に利用されている場合に、そのインスタンスファミリー以外を推奨から除外する使い方も可能となっております。これは「EC2 の利用者によってインスタンスタイプを変更されてしまい、EC2 Instance Savings Plans が無駄になってしまう」という可能性を少しでも下げてくれることでしょう*4。
ますます便利になった AWS Compute Optimizer をこれまで以上にご活用いただき、より皆様のコスト最適化が進むことを期待しつつ、本ブログを終わりにしたいと思います。
では、またお会いしましょう。
*1:存在している全てのインスタンスタイプではなく、AWS Compute Optimizer に対応しているインスタンスタイプのみが表示される点に注意してください
*2:93日間の有償オプションの設定画面は本アップデートによってこちらに統合されたようです
*3:部屋の中などで、頭から天井までの余裕となるスペースのこと
*4:よりシビアにコントロールする場合は、AWS Organizations の SCP で特定のインスタンスタイプを使用禁止にしてください
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
