はじめに

インスタンスのサイズダウンは何度か実施した記憶があるのですが、そのたびに何を調査すべきか調べなおしている気がしたのでまとめてみました。
既出でしたらすみません。

1. サーバレス化の検討

そのサーバ、本当に自前で管理する必要がありますか？
サーバレス化には様々なメリットがあります。
個人的には特に「運用の簡素化」の恩恵が大きいと考えています。
サービス改善にかけれる時間がその分増えると思うとワクワクしますね(しない)。
サイズダウンを考えるこのタイミングでサーバレスアーキテクチャに移行できないのか検討・提案してみるのはいかかでしょうか。

↓サーバレス化のメリット例 (by chatgpt)

コスト削減: サーバレスアーキテクチャでは、リソース使用量に応じて課金されるため、アイドル状態のインスタンスに対して余分なコストがかかりません。
スケーラビリティ: サーバレス環境では、リクエスト量に応じて自動的にスケーリングされるため、ピーク時のトラフィックにも柔軟に対応できます。
運用の簡素化: サーバレスではインフラ管理やサーバのパッチ適用などの運用タスクが減るため、開発者はアプリケーションの開発に専念できます。
高い可用性: サーバレスプロバイダーは高い可用性を提供しており、障害が発生しても迅速に復旧することができます。

2. リソース使用状況の確認

2.1 CPU使用率(CPUUtilization)

CloudWatch の標準メトリクスで確認できます。
特に t系に変更する場合は、CPUクレジットの概念についてちゃんと調べましょう。
バースト可能って100%を超えていいって意味じゃないので勘違いしないように。

2.2 メモリ使用率(MemoryUtilization)

カスタムメトリクスです、取得してない場合はこれを機に取得することをお勧めします。
メモリは基本的に単調増加なので計算もしやすいですね。
メモリ解放のタイミング(インスタンス再起動など)や GC の仕様を把握しておくといいです。
アプリケーションの成長にも気を付けたいところ..

3. ストレージパフォーマンスの評価

3.1 EBS 帯域幅(DiskReadBytes/DiskWriteBytes)

標準メトリクスです。
「最大」という数値に惑わされないでください。CPUとは異なり、クレジットは蓄積される仕様ではないようです。

アスタリスク (*) が付いているインスタンスでは、最大パフォーマンスを 24 時間につき少なくとも 30 分間維持することができます。その後、ベースラインの性能に戻ります
Read/Write で同じ帯域を使用している(たぶん)ため合計値がベースラインを超えていないか確認しましょう。
Byte, bit の単位に注意。

3.2 EBS IOPS(DiskReadOps/DiskWriteOps)

標準メトリクスです。
帯域幅と同じように「最大」という数値は参考程度に見ましょう。
同様に Read/Write の合計値がベースラインを超えていないか確認しましょう。
EBS ボリュームにも IOPS の制限があるのでどちらがネックになるかはちゃんと見た方がよいです。

4. ネットワーク性能の確認

4.1 ネットワーク帯域幅 (NetworkIn/NetworkOut)

インスタンスのネットワーク入力/出力バイト数を示す標準メトリクスです。
ストレージパフォーマンスと同じように「最大」という数値は参考程度に見ましょう。
同様に In/Out の合計値がベースラインを超えていないか確認しましょう。
ENA がサポートされているインスタンスを使用していて有効化している場合には、変更後のインスタンスで ENA がサポートされているかは忘れずに確認しましょう。

5. パフォーマンスモニタリングとアラート設定の確認

インスタンスサイズダウン後はメトリクスが以前より高い値を記録することが容易に想像できます。
変更前後で同じ60%にアラートを設定していても、パフォーマンス的余裕は以前より減っているはずです。
必ずアラートラインが適切か見直しましょう。
t系にしたときはクレジット消費量のメトリクス監視も入れたいですね。
顧客のためではありません、休日の夜中に起こされた時の調査難易度を下げるためです。

6. スケーリングポリシーの調整

アラートを設定したらオートスケーリング設定が適切に機能するかどうかを確認し、必要であれば設定を調整してください。
顧客のためではありません、休日の夜中に起こされないようにするためです。

7. コスト削減効果の評価

これを見ている方は既に実施済みだとは思いますが今一度確認しましょう。
このサイズダウンにどれほどの価値があり、誰がその価値を生み出したのか正当に評価されるために..

8. 上司(顧客)の顔色の確認

要するに「リスクとコスト削減効果のバランスの共有」です。
大幅に削減ができる時ほど怪訝な顔されがちな気がします。
少ししか削減できないことは分かってもらえることが多い気がします。
当然ですがどちらの時でもちゃんと説明できるようになるといいですね。

まとめ

後半は少しふざけた記述になってしまいましたが、おおむね確認すべき項目はまとめられたのではないかと思っています。
漏れている項目があればコメントに書いていただいたり、編集リクエストをいただければと思います。
ほかにもプロジェクト毎に要件があると思いますし、これが全てと断言するのは無理なので参考程度に見ていただければと思います。

最後までお読みいただきありがとうございました。

参考

EC2 パフォーマンス(AWS 公式 doc)
EBS パフォーマンス(AWS 公式 doc)
ネットワークパフォーマンス(AWS 公式 doc)