新メール配信基盤への移行 /ikyu-mail-platform

一休✕bitFlyer C#をつかったサービス開発の裏側
https://ikyu.connpass.com/event/35161/

Transcript

1. 新メール配信基盤への移行 株式会社一休 宿泊事業本部 開発部 飯迫 正貴 2017/06/28 【一休 × bitFlyer】C#を使ったサービス開発の裏側
2. 今日お話すること
3. 今日お話すること • 背景 • 新メール配信基盤の概要 • どう移行したか • 運用開始後にわかったこと • （全体を通して）意識したこと
4. 背景
5. 背景 • すべてのサービスをオンプレからクラウドへ移行中 • トランザクションメールが対象 • 既存の各サービスからのメール • SMTPでオンプレの共通メールサーバーから送信していた • マーケティングメールは対象外 • メルマガ
6. 要件整理・課題 • サービス側がクラウドに移行するまでにメールもクラウドに • もちろんそうですね • ユーザーからの問い合わせに対応するためのログが必要 • CSチームで送達確認や本文の確認をしている • 既存の仕組みだと検索が面倒で時間がかかっている • メール送信処理が同期処理になっていて遅い • 非同期にしたい • 今となってはメールである必要のないものがある • システムチーム宛のものなど • SaaS になると送信量で課金額が決まる
7. どうしたか • 新メール配信基盤は最初から全部クラウドで構築 • Mail SaaS は SendGrid に • SMTPをとりあえず生き残らせるとかはやらない • 暫定対応なしで一気に最終形へ • メールの送信ログは DynamoDB へ • 権限がある人には簡単に参照できる検索画面を用意 • メール送信リクエストは Message Queue で非同期に • 送る側は SQS に Queue を入れるだけ • メールでなくていいものは新基盤には移行しない • 代替として Log SaaS へ流す • 必要に応じて Log SaaS から Slack へ通知する
8. 新メール配信基盤の概要
9. アーキテクチャ • メール送信
10. アーキテクチャ • Webhook 受信
11. 使い方
12. メール送信履歴検索 • CSチームでユーザーから問い合わせがきたときに利用 • 送達確認 • 内容（本文）確認 • バウンスリストからの削除
13. メール送信履歴検索(Before) 面倒…
14. メール送信履歴検索(After) 権限のある人は即検索可能に！
15. アーキテクチャ • メール送信履歴検索
16. 実装 / インフラ • メール送信 • ASP.NET Core / .NET Core /C# • AWS Elastic Beanstalk • 64bit Amazon Linux running Docker • Webhook 受信 • .NET Core / C# • AWS Lambda • メール送信履歴検索 • ASP.NET Core / .NET Core / C# • Windows Server • 諸事情あってまだオンプレ
17. CI / CD • Staging • GitHub master merge => Circle CI => AWS EB or Lambda • Production • GitHub release merge => Circle CI => AWS EB or Lambda
18. CI / CD
19. どう移行したか
20. 移行方針 • 送信量の少ないサービスから移行 • AWS 側のリソース調整 • IP ウォームアップ • 詳しくはこちら => https://sendgrid.kke.co.jp/blog/?p=326 • 送信量の少ないサービスは一括移行 • 送信量の多いサービスは徐々に移行 • メールを送る必要がないものやめる • 代替を用意 • 添付ファイルをやめる • もちろん SendGrid API は対応している • が、DynamoDB には JSON を保存するだけにしたい
21. 移行順序 / 送信量 / 言語 • 一休.com海外 • 送信量 小 • ASP.NET MVC / C# • 一休.comギフト • 送信量 小 • Classic ASP • 会員基盤や内部向けAPI • 送信量 中 • ASP.NET MVC / C# • 一休.com（宿泊予約） • 送信量 大 • ASP.NET Web Forms / VB + C# • 一休.comスパ • 送信量 小 • PHP • 一休.comレストラン • 送信量 大 • Classic ASP スパまで完了
22. 移行方法 (C# or VB) • 共通メール送信用ライブラリ • 現行と同様のインターフェースで別の namespace に新 API を追加 • 旧 API は Obsolete • 部分的な移行もできるように • AppVeyor NuGet で管理 • ライブラリを利用しているサービス • namespace 変更のみで移行完了 • プルリクのレビューが楽 • ライブラリを利用していないサービス • 同じ方針で実装
23. 移行方法 (C# or VB)
24. 移行方法 (C# or VB)
25. 移行方法 (Classic ASP) • namespace 戦法が使えない • 共通の送信ロジックを変更して一括移行（ギフト・スパ） • もしくは、地道に新APIに移行（レストラン） • AWS SDK ない問題 • AWS API Gateway + Lambda で対応（ギフト・スパ） • Lambda から SQS に Enqueue • COMで対応？（レストラン） • レストランはこれから
26. 部分移行 • 特に予約完了メールは送信量が多い • かつ重要度が高い • 1%, 10%, 50%, 100% と徐々に新APIへ移行 • テストはしているが、完璧ではない可能性がある • もし失敗しても 1% リカバリーするほうが比較的楽
27. 部分移行
28. メールの代替を用意（Before） • バッチ処理結果や特定の例外をメールで送っていた • システムチーム宛 • サービス開始当時はそれしかなかった • メールを GAS で振り分けて Slack にアラートを上げていた • アラートの条件変更がメンテしづらい
29. メールの代替を用意（Before） • 例外メールによる全体の配信遅延 • たまにアプリのバグで例外メールが飛び続けていた
30. メールの代替を用意（After） • Log SaaS (Logentries) へ流すようにした • 同時に構造化ログに • フィルターや集計がしやすく • Logentries 側からアラートを設定 • 条件変更は誰でも簡単にできる • ただデフォルトの Slack 通知機能は微妙 • Raw log が出るだけでカスタマイズもできない • Azure Functions で Webhook を受け取って Slack に通知 • 最初は csx で作ったが、あとで Precompiled Function に変更 • チームで管理するのでちゃんと CI/CD をやりたかった • csx は CD 設定簡単だけどコンパイルエラーだと死ぬ • CI/CD • GitHub => AppVeyor => MS Azure
31. メールの代替を用意（After） バッチ処理結果ログ / Slack アラート
32. 添付ファイルをやめる • バッチ処理でメールにファイルを添付していた • 提携企業や経理あて • S3 への保存に変更 • ダウンロード用の Pre-signed URL を本文に記載
33. 添付ファイルをやめる(Before) 経理あてのメール
34. 添付ファイルをやめる(After) 経理あてのメール
35. ドメインホワイトリスト • 移行前 • 開発環境からメールは送れなかった • 確認方法はあった • 移行後 • 開発環境からもStagingの新メール配信基盤を使うようにした • 開発用実装を持ちたくなかった • 環境依存バグの温床 • とはいえ、誤送信は困る • Config に宛先ドメインのホワイトリストを追加 • Staging はこの設定により特定のドメインにしか実際に送信されない
36. ドメインホワイトリスト
37. 運用開始後にわかったこと
38. docomo/au のバウンス率が高い • docomo/au 限定で５回までは自動的にバウンスリストから削 除する仕組みを追加 詳しくはこちらで！ https://docs.com/shibayan/6046/sendgrid-c-v3-api
39. yahoo.co.jp のバウンス率が高い • Yahoo!ログインに対応したためYahoo!ユーザーが増えた • Yahoo!メールは一定期間が使わないとメールボックスが Suspendされる仕様 • 使ってないけど通知先に設定されたままのユーザーが多い？
40. 速い • アプリ側は Enqueue するだけなので • あるバッチの例 • ユーザーに一括でメール送信している系のバッチ
41. DynamoDB • Write / Read Capacity の調整がちょっと面倒 • provisioned throughput 課金 • 読み書きの性能を予約しておくスタイル • 超過すると例外が発生 • ProvisionedThroughputExceededException • 札束で殴ることもできるが… • 特にバッチ処理で一気に Enqueue されると厳しい • Elastic Beanstalk の設定で同時実行数（並列度）を微調整 • Worker Configuration => HTTP connections
42. Before
43. After
44. DynamoDB • Auto Scaling 機能が今月リリースされた • まだ試してない • 使用量に応じて自動的に Capacity を変更してくれる • ただし反映に時間がかかる • Write スパイクに有効な機能ではない
45. その他 • 一部の IP が Office 365 の Blacklist 入りしていた • いきなりたくさん送るとなりやすいらしい • 気をつけていたのに • https://sender.office.com/ から解除 • CS側でバウンスリストからの削除ができないと運用が回らない • メール送信履歴検索画面に削除機能を追加
46. SendGrid / KKE がよい
47. SendGrid / KKE がよい • SendGrid の採用が決まってからエヴァンジェリストの方にす ぐ来てもらえた • その後も何度もアドバイスをもらった • KKEさんはノウハウや事例をたくさん持っている • 安心・感謝 • しっかりしたドキュメントがある • 公式ライブラリが使いやすくなった
48. 今後の対応 • ブロック検知 • メールの HTML 化と開封率の取得 • まだ一部のメールしか HTML 対応していない • プレーンテキストの見た目のまま無理やり HTML にすることは可能だ が、怪しまれて逆に開封率が下がるらしい • ちゃんと文面を HTML 対応する必要がある
49. 意識したこと
50. 意識したこと • 要件 / 課題整理 • どんな課題を解決するのか明確にする • オンプレからクラウドにしてスケールしやすく • 同期処理から非同期処理にして高速化 • メールログを参照を簡単にしてCSチームの手間を削減 • やらないことを明確にする • 暫定アーキテクチャは作らない • 要らなくなったメールは移行しない • 設計 / 構築 • とにかくシンプルにして、本当に必要なものだけ作る • C# で統一して生産性と安定性をとる • SaaS特性、クラウド特性を理解する • なるべくSaaSに委譲してエンジニアの関心事や手間を減らす • 移行作業 • 移行は必要最低限の変更だけやる • 改善の方にリソースを割く