AWS DataSyncの利用で、コストが急増し数十万が消えた事例を紹介します。AWSを利用している方へ、注意喚起として読んでいただければなと思います。
コスト増加発見
AWSアカウントの管理を実施してます。毎週金曜日にAWS利用料の確認をしているのですが、S3のコストが徐々に上昇していることを確認しました。詳細を見てみるとS3に対してLISTのAPIが大量に発生していることがわかりました。
1000リクエストあたり0.005$
ログ出力用のS3バケットに対してのAPIだったのですが、ログ出力用のS3バケットに対してPUTはしていますが、LISTしていない認識でしたのでハテナ状態でした。
S3周りのインフラ構成
S3周りのインフラ構成は以下です。
あるストレージサービスからDataSyncにより、ログデータをS3へ転送するようになってます。
DataSyncの仕組み
DataSyncは、あるストレージサービスから別のストレージサービスへ転送する機能となってます。（超ざっくり説明です。）転送元のストレージサービスにあるファイルを確認し、その後、転送先のS3にその※ファイルが存在するかどうかを調べ、あれば何もしない。なければファイル転送を行う仕組みとなっています。
※設定によっては、転送先のファイルを調べずに転送することもできます。詳細は以下のAWS公式サイトを確認ください。
コスト増加の原因
コスト急増原因はDataSyncからS3へ対してのLIST APIでした。
上記と同じ説明になりますが、DataSyncは転送元と転送先を比較して、転送するしないを決定しています。比較のタイミングで転送先（S3）へListのAPIをたたいていることになります。
S3の転送先パスに大量のオブジェクトが存在する場合は、その分ListAPIが走ります。これが今回のコスト増加原因です。
さらに、DataSync転送とは別に、転送先パスに階層の深いデバックログを出力していました。（フォーマット：yyyy/MM/dd/hh/mm/ss）開発用デバックログなので、アプリが動くたびにログ出力されるので、大量のS3オブジェクトが出来上がります。
これら大量のS3オブジェクトをDataSync転送時に読み込むこととなるので、APIが多発し今回の金額増加につながりました。
対策
- 新規のAWSリソースを利用するときは裏で実行されているAPIも把握する
- 今回は、DataSyncがS3に対してListAPIをたたいていることを知らなかったため
- DataSync転送先のパスには、階層の深いオブジェクトは配置しない
- S3のバケットポリシーにて、DataSyncからの転送のみ許可するポリシーを追加する
- コストが急増した時のためにアラート設定をする
- 負荷試験なども実施するので、どうしてもコストが上がる時があるので検討が必要
おわりに
今回のコスト増加が発生して、初めてDataSyncがS3に対してListAPIを叩いていることに気づきました。新規のAWSリソースを使うときは、仕組みと裏で何のAPIを叩いているのか把握する大切さを学びました。また、最小権限の法則の大切さも改めて実感しました。
コメント