この記事は本番環境でやらかしちゃった人のアドベントカレンダー14日目の記事です。
多少フェイクを入れているので整合性のおかしい部分があってもご了承ください。
https://qiita.com/advent-calendar/2019/yarakashi-production
背景
- モバイル版だけでMAUxx万人のそこそこ規模の大きいサービス。Android/iOS/Webの３プラットフォームで提供。
- 開発元が撤退済みで、運営元から協力を依頼されとりあえずWeb以外の面倒を見ることに。２社にバラバラに開発を頼んでいたようで、なぜか変なところでAWS環境が２つに別れている。
- 色々と設計が荒く、ドキュメントもないのでアプリの追加開発の片手間でアーキテクチャの全容把握と改善計画を練っている途中の状況
- 新規登録時の確認メール、パスワード再発行メールでAWS SESを利用（メール利用はそれだけと認識していた）
- なおAWSのサポートプランは無し
事件発生
(一日目）
運用開始時からユーザからの問い合わせに返答していただいている会社の方から連絡あり
運用担当「毎日問い合わせ内容のCSVがメールで届くのですが、今日はきていないようです。確認お願いします。」
私「（そんな運用になっていたのか・・・)調査します」
...調査結果
問い合わせ内容テーブルから毎日レコードを取り出してCSVにしメール添付送信しているLambdaを発見
試しに実行してみたがメールは飛ばず。
定時も過ぎていたので調査は後回しにして取り急ぎSlackに転送するように改修。
私「Slackのほうに転送するように改修しました。」
私「送信できなくなっている件については翌日調査します。」
一日目 終
(二日目）
運営元から連絡あり
運営元「パスワード再発行のメールが届かないと問い合わせが来ているのですが、確認お願いします」
私「（メールの問題が続くな...嫌な予感が...）調査します」
...数分後
私「Status...SHUTDOWN...!?」
私「メール全停止してます!パスワードリセットどころか新規登録もできません!」
運営元「え、2日後からデカい広告打つんですけど...」
私「え...？」
完
SESの状況
bounce管理一切されてなかった。
SESにおけるbounce管理の重要性については他の方の記事をご参照ください。
https://qiita.com/zaru/items/4be9b55ba807670cf224
https://qiita.com/KeijiYONEDA/items/5e810d1f07392ab51d22
https://qiita.com/Yoshi_T/items/b12c74b6af09df05dff3
こちらはもう手遅れでBounce Rate 13%でStatusがSHUTDOWNになってました。
何が起こったか
普通は止められる前にAWSから警告メールが来るんですが、
連絡先が撤退した開発元のままで、変えてもらうのを忘れてました。
まぁ転送とかしてくれないですよね。
数週間前
- Web側の問い合わせフォームに@qq.com ドメインのアドレスで大量スパム投稿を受ける。
- 実はWebの問い合わせの受理確認(?)メールにも同じSESを使っていた
- AWSから「君のところのSESレビュー対象にしたよー。ちゃんと対策しないとSES止めるね」と、開発元に届く
参考:問い合わせフォームに大量スパム。「qq.com」のスパムを対策しました
第一報時
- 再度スパム
- AWSから止めたわとういう激おこメールが開発元に届く
対応
SES回復方法
- 再開のためにはAWSに見直しリクエストを送る必要あり。
- ただし、問題の根本解決を行わないと再開は許可されない
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/e-faq.html#e-faq-sp
Q7.見直しのリクエストをするにはどうすればよいですか?
見直しをリクエストするには、AWS アカウントに関連付けられたメールアドレスから ses-review@amazon.com に E メールでご連絡ください。。
重要
アカウントのセキュリティを保護するために、Amazon が対応できるリクエストは AWS アカウントに関連付けられた E メールアドレスから送信されたものに限られます。
リクエストで以下の情報が提供します。
この問題の原因に関する情報。
問題修正のために行った変更のリスト。実装済みのステップのみを含め、今後実装する予定のステップは含めないでください。
これらの変更により今後どのように同じ問題の再発が防止されるかに関する情報。
アカウントの E メール送信機能が一時停止となったイベントの性質によっては、追加情報を提出していただく場合があります。リクエストに含める情報のリストについては、発生した問題に関する、よくある質問のトピックを参照してください。
とりあえずごまかしメール
Web側はどこの会社も面倒をみていない完全放置状態で、
今から面倒を見るような契約結んでreCAPTCHA入れる改修をしてまたAWSにメールして。。
とかやっていたら間に合わないと判断。
とりあえずすっとぼけてバッチせいってことにしてメールしてみました。
が、だめでした。
ses-review@amazon.comにメール
私「AWSさんへ メール送信バッチの設定を間違って無効なメーリスに大量にメールおくってbounceが上がっちゃいました。」
私「バッチも止めたし、bounceをハンドリングする仕組みも入れたので許してください」
...30時間後
AWS「いや問い合わせフォームにスパム送られたのが原因だから。ちゃんとreCAPTCHAとか入れてね。詳細な情報も送るね」
私「ちゃんと見てる！しかも親切！ でも今は嬉しくないし、レスポンスめっちゃ遅い！」
どうしたか
SESをあきらめて別のサービスに登録して切り替えました。切り替えの作業時間2時間ぐらい。
広告配信にはギリギリ間に合いました。復旧まで登録できなかったユーザさんごめんなさい。
Webの問い合わせフォームは放置しました。受領確認メールはなくてもいいですよね。
mailgunとかsendgridとか、bounce管理しなくてもいいし※1、設定も簡単だし、そんなにお高くなくていいですよね。
ちなみにmailgunだと色々やらないとhotmailとかyahooメールに弾かれますがそれはまた別の話※2。
https://www.mailgun.com
https://sendgrid.kke.co.jp/
※1 「しなくていい」は語弊がありましたすみません。（たしか）SESはサプレッションリスト入りしたアドレスへの送信リクエストがbounce扱いだけど他は違ったので楽だったと記憶しています、あと管理も諸々楽という感じです。
※2 ちょうど闇のカレンダーのほうでレピュテーションの記事を書いていただいているようなのでそちらをご参照ください
メールというインターネットの闇とIPレピュテーション（だけど重要）(前編)
何を学ぶか
- AWSのアカウントに登録してあるアドレスは、システム運営する人(特にエンジニア）に送られるように真っ先に変更してもらうこと。
- SESのbounce管理はちゃんとやる。もしくは使わない。使わないほうが楽な場合も多い。
- 問い合わせフォームにはreCAPTCHA等スパムが送られない仕組みを入れる。
- AWSのサポートプランにはちゃんと入ろう。
最後に
ありきたりな学びになってしまいましたが、１つ１つちゃんとやりましょう。。という話でした。
周りのエンジニアの方々には切替時に色々なアドバイスいただき、大変助かりました。ありがとうございました。