はじめに
ますだです。
普段は AWS 案件の保守や運用を担当しています。
今更の話になりますが、入社間もなくの時期でなかなか思い入れのあるコスト削減の事例があり、その際に経験した内容を共有します。
結論を聞けば単純な話ですが意外と見落としがちなポイントで、また当時は他社の事例もあまり見かけなかったので、少しでも参考になればと思います。
ざっくりまとめ
- 問題：不適当な AMI を使用していた結果、リージョン間のデータ転送コストが増加
- 原因：不要なサービスやプロセスが稼働し、EBS スナップショットのデータ転送量が増加
- 対策：不要なプロセスの停止と AMI の選定見直し
- 効果：データ転送量とコストの大幅な削減（一ヶ月あたり 95% 減、全体でx十万円）
-
教訓：
- ベース AMI が自社の利用状況に適しているか再考する
- 不要なサービスやプロセスを定期的に確認する
- クロスリージョン構成のデータ転送コストに注意
- AWS サポートを有効活用する (心に刻む)
問題の発見
AWS の Cost Explorer でコストを分析していたところ、東京リージョンから大阪リージョンへのデータ転送量が右肩上がりになっていることがわかりました。
使用タイプ：APN1-APN3-AWS-Out-Bytes (GB)
（東京リージョン → 大阪リージョンへのアウトバウンド転送）
その中でも特に、「EBS Snapshot Copy」によるデータ転送量が急増していました。
初期調査
過去のインフラ構成の変更履歴を確認
コストが急増し始めた時期に何があったのか、まずはインフラ構成の変更履歴を確認しました。
（入社以前の時期だったため、完了済みの Backlog を片っ端から当たりました）
- 構成変更：とあるサーバーの構成を「東京 3 台」から「東京 2 台＋大阪 1 台」に変更
- 目的：災害対策として大阪リージョンにもサーバーを配置
ディスク使用率の確認
対象サーバーのディスク使用率をモニタリングしていましたが、大きな変化は見られず、ディスク容量が増えているわけではありませんでした。
スナップショットの仕組みと増分バックアップ
AWS では、EBS ボリュームのスナップショットは (基本的に) 増分バックアップ として動作します。
つまり、前回のスナップショットから変更があったブロックのみを保存します。
しかし、書き込みがほとんどないサーバーでも、何らかの要因で変更ブロックが増加し、スナップショットのデータ量が増える可能性があります。
AWS サポートとのやりとり
データ転送量の増加原因の手掛かりがないか、AWS サポートに問い合わせました。
質問内容（ざっくり抜粋）：
- スナップショットが毎回フルバックアップになっている可能性はありますか？
- リージョン間のデータ転送量の詳細を確認する手段はありますか？
サポートからの回答：
-
増分バックアップになっている ※1）：
スナップショットは増分バックアップとして動作しています。 -
データ転送量の確認方法：
「list-changed-blocks」 API を使用して、スナップショット間の変更ブロック数を確認できます。
※1）別件で AWS Backup におけるスナップショットの保持期間の見直し（1 日 → 1 週間と伸ばす）によって、コスト削減につながったことがあったため、毎回フルバックアップで取得されていないかを確認。本題と逸れるため、気が向けば別記事として更新します。
[1] EBS direct API を使用して EBS スナップショットの内容にアクセスする -
[2] list-changed-blocks
当たり前のようですが、以下推測の裏付けが取れました。
スナップショットの頻度とデータ変更量の関係
- 頻度が高く、データ変更が多い場合：データ転送量が増える傾向にある
- 頻度が低く、データ変更が少ない場合：データ転送量はそれほど大きくならない
増分バックアップの確認方法
EBS direct API の「list-changed-blocks」コマンドで変更ブロック数を確認する
詳細調査
AWS サポートに問い合わせている期間と並行して、サーバー内のログを詳しく調査したところ、amazon-ecs-init というプロセスが 15 秒ごとに動作を繰り返していることが判明しました。
ログの一部抜粋
level=info msg="Starting Amazon ECS Agent"
level=error msg="Unable to register as a container instance with ECS: AccessDeniedException..."
原因の推測
-
ECS 最適化 AMI を使用：
長年在籍しているメンバーにヒアリングしたところ、将来的なコンテナ運用を考慮して ECS 最適化 AMI を使用していましたが、実際には各環境の多くのサーバでコンテナを利用していませんでした。 -
不要なサービスが動作：
amazon-ecs-agentなどのプロセスが正常に動作せず、頻繁にディスクへの書き込みを行っていました。 -
ディスク I/O の増加：
この不要なディスク I/O が、スナップショット時の変更ブロック数を増加させ、データ転送量の増加につながっていました。
解決策の実施
不要なプロセスの停止
以下の不要なプロセスを停止し、自動起動も無効化しました。
amazon-ecs-agentcontainerdamazon-ecs-volume-plugin
停止手順
sudo systemctl stop ecs
sudo systemctl disable ecs
sudo systemctl stop containerd
sudo systemctl disable containerd
sudo systemctl stop amazon-ecs-volume-plugin
sudo systemctl disable amazon-ecs-volume-plugin
適切な AMI への変更検討
ECS 最適化 AMI ではなく、通常の Amazon Linux 2 AMI を使用することも検討しましたが、対象となるサーバ数もそこそこあり、既存環境の再構築コストを考慮し、今回は不要なプロセスの停止のみで対応としました。
このことで不要な I/O が減り、結果的にスナップショット取得時の変更ブロック数を抑えることにつながりました。
結果と効果
変更後、データ転送量とコストが大幅に減少しました。
- 一ヶ月あたり 95% 減、x十万円のコスト削減
教訓
ベース AMI の再考
- AMI が適しているか再検討：ベース AMI が自社の利用状況に適しているか、改めて確認するとお宝（爆弾）が眠っているかもしれません。
不要なサービスやプロセスの確認
- 定期的な確認：不要なサービスやプロセスが稼働していないか、定期的に確認することが大事ですね。
クロスリージョン構成のコスト意識
-
データ転送コストの認識：
リージョンを跨ぐ構成では、データ転送コストが嵩む場合があることを経験しました。 -
スナップショット料金とデータ転送量：
多少のスナップショット料金だとしても、リージョン間のデータ転送によって費用がかさむケースを学びました。
AWS サポートの活用
-
一番有益なサービスは AWS サポート：
結果的にひらめきとログ調査で原因を特定できましたが、AWS サポートは神のサービスです。 -
情報の整理：
問い合わせ文を作る際に、考えるきっかけや改めて情報の整理ができるので、サポートはなるべく使い倒すが吉ですね。
まとめ
2024 年 10 月時点で、マルチアカウント全環境のうち 35% のコスト削減 を達成することができています。
本件はほんの一部ですので、機会があればアウトプットを続けていきたいと思います。
本記事が少しでも参考になれば幸いです！