今回は、クラウド破産について3つの実例を元に紹介する。
クラウドサービスの利用がごく一般的になった昨今。
従量課金による初期費用の安さと変化に対応できる柔軟性は魅力的であることは間違いないが、一方で使い方を誤ると高額な請求を受けてしまう。
今回は、このクラウド破産を未然に防ぐために、俺の知る範囲での実例と対策を紹介する。
文鳥と暮らす在宅エンジニア yassan です。仕事の生産性や生活の質を高めるアイデアを共有しています。
クラウド破産とは
クラウド破産とは、クラウドサービスで想定外の料金を請求されてしまうことだ。
破産と聞くと恐ろしいが、この造語は請求者が実際に破産したかどうかではなく、高額な請求をされたことが焦点となる。
従量課金がゆえに気付かないうちに料金が膨れ上がり、月次の請求時に面食らうことが多い。
コストアラートを設定していたとしても、コストの反映には数十時間のラグがあるため、対処が遅れることもある。怖い。
実例紹介
では実例を元にクラウド破産について紹介する。
S3 ストレージクラスの一括変更
S3ストレージクラスの一括変更は非常に危険。
S3ストレージクラスについておさらいしておくと、S3オブジェクトの保存特性からコスト最適ができるように様々なクラスが提供されている。
代表的な例で言えば、アクセス頻度の極端に低いオブジェクトはGlacierを採用することで、ストレージコストを削減できる。
このような便利なストレージクラスだが、使い方を誤ると高額請求を受ける。
それはつまり、大量のオブジェクトを一括でストレージクラスを変更することだ。
実はストレージクラスの変更には料金が発生する。
ドキュメントから抜粋すると以下の通り。
PUT、COPY、またはライフサイクルルールを使用してデータを S3 ストレージクラスに移動する場合、リクエストごとに取り込み料金が発生します。オブジェクトをストレージクラスに移動する前に、取り込みまたは移行のコストを検討してください。
https://aws.amazon.com/jp/s3/pricing/
公式の料金表を元に、1000万オブジェクトをスタンダードからGlacier Flexible Retrievalに移行しようとすると、
1000万 / 1000リクエスト * $0.03426 = $342.6これだけの料金が発生する。
大したことないと思うかもしれないが、実際のユースケースを想像してみてほしい。
S3のストレージクラスに注目する時はどんな時かというと、S3ストレージコストが高くてコスト削減をしたい時 のはずだ。
つまり、それだけ多くのオブジェクトを抱えている可能性が高く、なおかつコストがすでに逼迫している状況なのだ。
そんな折に、ストレージクラスを変えれば安くなると安直に変更してしまうと、思いもよらない移行料金で大ダメージを受けてしまう。
対策としては、移行を検討するときに、移行対象とするオブジェクトが何件あるのかを確認して、移行料金を試算してみることがおすすめ。
CloudTrail データイベントの取得
CloudTrailのデータイベントの取得も非常に危険だ。
CloudTrailをおさらいしておくと、AWS上の操作をイベントという単位でログ記録する監査向けのサービス。
イベントには4種類あり、その中でよく知られているのは管理イベントとデータイベントだ。
管理イベントは、リソースに対する全般的な操作に関するもの。
デフォルトで有効になっているため、特別な設定はしていなくてもコンソールから90日間の操作履歴を確認することができる。
また、S3に出力せずにコンソールで確認する分には無料だ。S3に出力する場合は別途料金が発生する。
データイベントは、リソース内のデータに対する操作に関するもの。
ちょっとわかりにくいので、実際の例で言えば、S3バケットのGet, Delete, Putや、DynamoDBテーブルへのPut, Delete, Update など。
（S3バケットの作成やDDBテーブルの作成は管理イベント）
データイベントはデフォルトで有効になっていないため、特定のリソースのデータ操作をS3に記録するには、明示的に設定をする必要がある。
クラウド破産に話を戻すと、このデータイベントというのが非常にリスクが高い。
データイベントの料金は、データイベント 100,000件あたり $0.10 だ。
1イベント = 1回APIリクエスト呼ぶ ことなので、10万回データ操作すると $0.10 発生する計算になる。
これも大したことないと思うかもしれないんだけど、実際のところ10 万回程度でデータイベントが収まるわけがない。
特に、イベントセレクター（取得するデータイベントのフィルタリングのこと）を粗く設定した場合は、10万なんて余裕で超える。
「とりあえず広めにデータイベントを有効にしておいて、後で必要なものにフィルタリングしていけばいいか〜」なんてしてしまうと大変なことになる。
対策はとしては、イベントセレクターで可能な限り取得するログを制限をして、コストの様子を見ながら少しずつ対象を広げていくことがおすすめ。
Lambda再起呼び出し
Lambdaの再起呼び出しも危険だ。
これは読んで字の如くではあるんだけど、Lambdaを再起呼び出ししてしまうと、最悪Lambdaの同時実行がスケールし続けて実行数が莫大なことになる。
（やったことはないけど、理論上はアカウントで設定しているクォータの上限値までぶん回すことになると思う）
ただ、Lambda再起呼び出しに関しては、AWS側も対策をしている。
特定のAWSサービス（S3 / SQS / SNS）と統合している場合、リクエストチェーンをAWS側が把握しており、16回程度の実行で自動的に停止するようになっているとドキュメントに記載がある。
俺は試したことがないので、実際にどのような挙動になるのかはわからないが、自動的に止まるのであれば安心だ。
問題は、この特定のサービスを利用しないで組んだアーキテクチャ。
その場合は責任共有モデルに従って、再起実行の際は開発者側の責任ということになる。
再起呼び出しを利用しないアーキテクチャが理想ではあるが、やむを得ない場合は、
上記の特定のサービスを介すか、StepFunctionでリクエストチェーンを管理する仕組みを自前で実装しておいた方が良い。
まとめ
というわけで、クラウド破産の3つのシナリオを紹介した。
どれもありそうな話だと思うので、これから利用する方はぜひ気をつけていただきたい。
コスト削減に悩んでいる場合は、下記の書籍を一読しておくのがおすすめ。
コストの可視性や組織の運用の悩みであればAWSコスト最適化ブック、ピンポイントでの困り事や個別具体な削減策であれば、もっと絞れる AWSコスト超削減術。
