このページの本文へ

「Send with Confidence」で披露されたSaaS障害への備え

メールを重視する一休.comがSendGridの障害から学んだこと

2018年07月19日 09時30分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 5月29日、構造計画研究所は同社が国内で販売代理店を務める「SendGrid」のイベント「Send with Confidence」を開催。米SendGridのプロフェッショナルが語った前半に引き続いて行なわれた後半では、ホテル・レストランの予約サイトである一休.comのしばやん氏がSendGridの大障害から得た教訓を披露した。

AWSへの全面移行を機にSendGridを導入した一休.com

 Webサービスとしては老舗となる一休.comは、「こころに贅沢させよう。」を掲げ、厳選したホテル・レストランを専門に扱う予約サイト。そんな一休.comにとってメール送信は「非常に重要」だという。たとえば、一休.com側からの予約完了メールの送信が失敗すると、ユーザーが予約できてないものだと思い、重複予約が発生してしまう。「メールが素早くきちんと届くことはサービスの生命線」としばやん氏は語る。

一休.comのしばやん氏

 一休.comも以前はデータセンターに自前のSMTPサーバーを構えていたが、昨年AWSに全面移行したのを機にSendGridを導入。現在は新規会員登録やホテル、レストランのユーザー向け予約完了、施設や店舗向けの予約通知などのトランザクションメールの配信で利用中。今後はマーケティングメールもSendGridに移行する予定となっている。「いろいろなサービスを検討しましたが、日本語のサービスがあり、信頼性も高かったSendGridに移行しました」。従来は.NETにおけるISO-2022-JPの不具合で文字化けもあったが、SendGridへの移行で問題も解消したという。

一休.comでのメール送信の仕組み

 一休.comでは、Elastic Beanstalkを使ってキューイングサービスであるAmazon SQSと配信サーバーのワーカーを構成し、バランシングしてSendGridにリクエストを送っている。同時に配信サーバーではメールごとにユーザーIDを生成してトラッキングに利用したり、送信ログをDynamoDBに送信しているという。

朝からエラーレートが上がり、最大1時間の遅延が発生

 続いてしばやん氏は2017年8月に起こったSendGrid障害について振り返る。障害が起こった日は、朝からエラーレートが上がり始め、「感覚的には7~8割が送信に失敗し、成功は2割くらい」(しばやん氏)という状態になった。同時に遅延も発生し始め、最高で1時間くらいの遅延が発生していたという。

 一休.comではもともと5回送信に失敗した段階で、SQSのデッドレターキューに入ることになっていた。しかし、デッドレターキューから送信キューに戻す処理を用意していなかったため、障害でメールが完全に届かない状態になってしまった。しかも、AWSやネットワーク、DNSなどの障害を疑っていたため、SendGrid自体の障害発生告知に行き着くまで時間を費やしてしまったという。「半年間、ノートラブルだったので完全に油断して、原因の特定にかなりの時間を要してしまった」としばやん氏は振り返る。

 この段階でメールの遅延は数万通レベルに達していたが、ここまで大規模な障害を想定していなかったため、モニタリングも弱く、リカバリーの手段も用意していなかった。唯一、送信ログはすべてDynamoDBに保存していたため、送信メールについての情報を失わなかったのが救いだったという。

SendGrid障害の学び

障害後に実践した「失敗を前提とした設計」

 結局、障害復旧まで1日かかってしまったが、翌日からは「失敗を前提とした設計」に向け、迅速に改善を行なった。Elastic BeanstalkとSendGridか切り分けられなかった問題に関しては、エラー時のレスポンス詳細をログに入れるようにした。また、デッドレターキューからのリカバリが手動だったの件に関しては、管理画面から一括で未送信メールにリカバリできるよう改善した。「最初からやっとけと言われたらその通りなんですが、障害で改めて実感したということです」としばやん氏は振り返る。

失敗を前提にすることが教訓だった

 また、障害時に遅延具合や影響範囲を簡単に確認できなかったため、モニタリングを強化した。同社が導入しているDatadogにElastic BeanstalkのWorkerやSQSのメトリクスを追加し、10分以上の配信遅延が発生した場合はSlackにアラートを上げるようにした。さらに管理画面から送信できなかったメールを確認できるようにし、未送信メールも簡単にリカバリできるようにしたという。

 しばやん氏は、「検知とリカバリの仕組み、運用のためのドキュメントを用意した。また属人化を避けるため、事業部ごとに担当者を1人任命した」と、障害対応の体制が整えたことをアピール。その上で、「昨年以来、障害が発生していないので平和な日常を送れています。SendGridの本社で苦労してもらっていることに感謝しています」と語り、セッションを締めた。

カテゴリートップへ

ピックアップ