夏ももう終わりに近づいていますが、今回は夏にちなんだ怖い…というか肝が冷えた（冷えたくなかった）お話です。
何をやらかしたのか
あるアップデート作業後、NAT GatewayのBytesOutToSourceが異常に増えました。
CloudWatchメトリクスからNAT GatewayのBytesOutToSourceを確認したところ、平常時の10倍以上の数値を示していました。
これによりNAT Gatewayの課金額も膨れ上がり、1日にNAT Gatewayだけで数千円請求されてしまうという事態に💀
この異常な状態のまま連休を挟んだので諭吉が飛んでいきました…
BytesOutToSourceとは
VPC 内の NAT ゲートウェイ経由でクライアントに送信されたバイト数。
値が 0 より大きい場合は、インターネットから NAT ゲートウェイの背後にあるクライアントへのトラフィックがあることを示します。BytesOutToSource の値が BytesInFromDestination の値より少ない場合、NAT ゲートウェイの処理中、またはトラフィックが NAT ゲートウェイによりアクティブにブロックされている間に、データ損失が発生する可能性があります。
単位: バイト
統計: 最も有用な統計は Sum です。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway-cloudwatch.html
原因
- VPC LambdaがNAT Gatewayを経由してRDSへSELECT文を実行したところ、取得レコード数が膨大だった為にBytesOutToSourceが跳ね上がった模様。
- 問題のSELECT文は頻繁に実行される処理だった為に通信料の増大に拍車をかけた。
つまりはビジネスロジック側の問題でした。
テーブル設計や諸処の問題でSELECT文のWHERE句の条件を少なく書かざるを得なかった為に、このようなことが起きてしまいました…。 とりあえずはLambdaのソースコードのバージョンを戻すことで一旦問題は回避。
異常を検知できた理由
AWS Cost Anomaly Detection
「AWS Cost Anomaly Detection」からメールで異常コストの通知が来ていました。 機械学習でコストが跳ね上がっていることを検知してくれる超便利機能です。 本当にこれを設定していてよかった…。
AWSを利用しているなら有効化しておくべきです。
対応
- SQLでの取得レコードは極力必要最小限に絞れるようシステム設計を見直す。
基本的なことだと思いますが、扱うレコード数が少なくなりがちな開発環境故に見落としてしまった形でした。 肝が冷えた…。
