60億円の損害を出した 「DMMブックス」 70％OFFキャンペーンでプラットフォームに何が起きていたか

Transcript

1. © DMM.com 60億円の損害を出した 「DMMブックス」 70％OFFキャンペーンでプラットフォームに何が起きていたか 合同会社 DMM.com SRE部 小野 博志 2021/10/07
2. © DMM.com 自己紹介 2 小野 博志 / Ono Hiroshi 合同会社DMM.com ITインフラ本部 SRE部 エンジニアリング　マネージャー ２００５年に新卒で中小独立系Sierに入社。Javaを使ったWeb系開発に従事。 ２００８年よりMSP（マネージド・サービス・プロバイダ）の業務に従事。アカウントSEから始まり、サービス企画や テクニカルディレクターを務める。エンタープライズの領域で大規模なコーポレートサイト、WebCMSを中心とし て担当していた。 ２０１８年よりB2Cもやってみようかなって思って２０２０年にDMM.comに入社。DMMブックスやNewRelicの導 入推進を主に担当しています。 Ansible大好き人間ですが最近コンテナばっかり触っているので全然使えてないのが悲しみです。 いつの間にかAnsible 4系が出ているんですね。
3. © DMM.com 予備知識として 3
4. © DMM.com 話題のコミックや小説などを パソコンやスマホで 読めるプラットフォーム コミック、雑誌、小説、写真集等の電子書籍を配信しております。現在は 66万冊以上の作品を取り揃えており さまざまなジャンルの作品を提供しています。
5. © DMM.com DMMブックス 70%OFFキャンペーンとは 「DMM電子書籍」から「DMMブックス」へとサービス名称を変更することを記念して始めたキャンペーン。 ３月２５日〜６月３０日の期間限定で、初回購入者限定にはなるが、ほぼ全ての作品が最大１００冊まで 70%OFFで購入できる破格のキャンペーン。 今までも50%OFFクーポンは存在していたが今回は記念ということで今まで類を見ない大盤振る舞いを実施した。 5
6. © DMM.com キャンペーンのビジネス的な裏側 6 ぜひ弊社のオウンドメディアの記事 「60億円の損害を出した「DMMブックス」70％OFFキャンペーン早期終了の裏側を責任者と会長に 聞いた。」を御覧ください。 LINK: https://inside.dmm.com/entry/2021/07/01/dmm-books
7. © DMM.com DMMブックスのシステム構成 7 2021年4月当時のDMMブックスのシステム（主要部分に限定） オンプレ AWS webサーバ (ECS/AutoScaling) WWWサーバ （共通CSSなど） 会員情報API 書籍配信サーバ (ebook01-04) DMMブックス 担当以外の方が 管理 DBサーバ (RDS MySQL/bookDB) Cacheサーバ (EC2/Memcached)
8. © DMM.com 本題 8
9. © DMM.com 本日のお話を簡単にまとめると 9 • 70%OFFキャンペーンという大盤振る舞いをしたら予想以上の反響があって、売れ過ぎちゃって早期 終了することになりました。 • すると駆け込み需要でアクセスが集中し、最終的にDMMブックスのサイトが止まりました。 • なんとかするためにボトルネック見つけて改修したら、次々とボトルネックが見つかって一生懸命直して ました • なので今はとても盤石なプラットフォームが出来ましたというお話です
10. © DMM.com キャンペーンに備えて 10 • いつものキャンペーンと同じぐらいだろうと想定してキャンペーン前にスペックアップなど事前準備をし ていました • 実際キャンペーン開始当初は想定通りの負荷状況でした • しかしある日を境にとてつもないアクセスが来るようになりました
11. © DMM.com きっかけは一つのツイートでした 11 XXXX @XXXXXXXXX TLのオタクへ
 今DMMブックスで初めて漫画買う人にもれなく70パーセントOFF のクーポン貰えるからめちゃくちゃお得やで!!!!!!!!!!!!!!私はハイ キューと鬼滅とヒロアカ全巻（99巻）買って14000円いかなかった
 いくつかのツイートによってバズリました
12. © DMM.com 書籍配信サーバの高負荷(その１) 12 最初に古い書籍を配信するサーバが高負荷になりました。ただ、オンプレの物理サーバで大容量ディスクが必要ということもあり、用意 できず見守るだけでした。一番負荷が高くなるのが最新刊を配信するサーバではないという、今までとアクセス動向が大きく異なる状況 でした。 ebookサーバ ebook01サーバグループ ebook02サーバグループ ebook03サーバグループ ebook04サーバグループ 書籍が増えるたびに新しいサーバを追加 してきた。ebook03/04に新しい書籍が追 加されていく。 他のサーバグループも負荷は高かったが ebook01 が顕著に負荷が高くなった。サーバスペックも異な るが、100冊キャンペーンは冊数が多い、古いシ リーズものを買う人が一定層いたため影響が出や すい状態だった。
13. © DMM.com Cacheサーバの切り替えで高負荷 13 EC2ベースでMemcachedを使ってましたが、スケールしにくいため、動作検証は終えていた AWS ElasticCache(Memcached）へ切り 替えました。サーバスペックは十分なものを用意していましたが、ピークタイム時にサイトが重くなってしまいました。 公式資料よりもかなり低い数値で頭打ちにななるよ うな仕様だった カタログスペックは最大と書いてあるので嘘ではな いが・・・ 実測値についての参考資料 ：https://cloudonaut.io/ec2-network-perf ormance-cheat-sheet/ AWSではサーバスペックが低いとカタログスペックのネットワーク速度は出ないようです。そのことを把握しておらずピークタイム時の トラフィックに耐えれずレスポンスタイムの大幅な悪化に繋がりました。
14. © DMM.com 想定を上回る反響で早期終了告知 14 DMMブックス @DMM_DigitalBook 【お知らせ】
 ユーザーの皆様から想定を上回るご反響をいただいたため、 4/12(月)11:59をもちまして「DMMブックス 初回購入限定最大100 冊70%OFFクーポン」の配布を終了させて頂きます。
 すでにクーポンをお持ちの方は使用期限内はご利用頂けます。
 もちろん駆け込み需要が来る覚悟は出来てました
15. © DMM.com RDSのCPUが高まったためスペック変更 15 終了告知によりさらにアクセスが増え RDSのCPU使用率が大きく上昇した。ここから更に増えることも予想できたためスペックアップを実 施しました。vCPU換算で40vCPUから96vCPUまで増やした（台数を減らしてスペックをあげた） ある1台のRDSのCPU使用率。まだまだ増えそう な傾向があったが、スペック変更で半分程度まで落 ち着いた これで一定のレスポンスタイムは確保できるように
16. © DMM.com 共通アセット系のサーバで遅延 16 DMMではサービス横断の共通のアセット（ CSS/JS/Image）が存在します。wwwサーバから配信しており、DMMブックスのアクセス増 により別サイトで閲覧しにくい状況が生まれました。 Apacheのワーカープロセスが上限に達しており、リソースを見ると余裕があったため Apacheの設定を見直して復旧しました
17. © DMM.com そして今回最大の危機へ ほとんど使えてなかった夜です 17
18. © DMM.com 某ネットメディアの紹介から更にアクセスが・・ 18 XXXX @XXXXXXXXX DMMブックスの最大100冊70％オフクーポン、予定より早く明日 12日11時59分までで配布終了となったためご注意ください（クー ポンだけでも入手しておけば、取得後7日間まで使用可能です／ 現在サイトがかなり重くなっているようです） 紹介してくれるのはありがたいけど辛い
19. © DMM.com 書籍配信サーバの高負荷(その２) 19 ebook03と04は耐えていたが、ebook01と02が高負荷になりました。さらにebook01は分散ファイルシステムとしてGlusterFSを利用し ていますが、GlusterFSのコマンド実行が、応答を返さない /返しても恐ろしく遅い状態になっていました。 しかも再起動した場合に立ち上がらない恐れもあり触れない状態となっていた。そしてスプリットブレイン（同期不整合）が起きていたこと も後からわかった。それでもユーザからの応答は返せていたのは首の皮一枚繋がったと思ってました。 突出している２つのラインが ebook01/02 このグラフでは丸められてしまっているがリアルタ イムでは100を超える瞬間もあった。
20. © DMM.com 会員基盤APIへの大量アクセスであわや全体障害に 20 購入時の処理においてN+1問題が発生していました。具体的には１００冊本を買うと１００回ユーザの情報を取得していました。大量アク セス＋キャンペーンで大量の冊数を買うユーザが殺到しており、会員基盤 APIに多数のアクセスをしてしまいDMM全体の障害の恐れが 出てきました。 AWS側のホスト数の推移 意図的にオートスケールの台数を絞って 会員基盤APIへのリクエスト数を縛ることに その夜はアプリケーションの改修は行わず AWS側はリクエスト数に応じて オートスケールする こちらのリクエストを絞った上で会員基盤 API側のサーバ追加を行うことで全体影響ほぼでなかったが、 DMMブックスとしてはエラー を検知していたのでさらなる調査に
21. © DMM.com AWS NAT GatewayでErrorPortAllocation 21 それでも会員基盤APIでエラーが出ていると検知しており、調べてみると AWS NatGatewayの制限事項に該当していました。その日は 対処策が無く（思いつかず）、ピークタイムが終わるまで見届けました。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html 
 
 NAT ゲートウェイは送信先別に最大 55,000 の同時接続をサポートできます。この制限は、単一の送信先に 1 秒あたり約 900 の接続 (1 分あたり約 55,000 の接続) を作成する場合にも適用されます。送信先 IP アドレス、送信先ポート、またはプロト コル (TCP/UDP/ICMP) が変更された場合は、追加の 55,000 の接続を作成できます。 
 55,000 を超える接続の場合は、ポートの割り当てエラーによる接続エラーの可能性が高くなります。これらのエラーは、NAT ゲートウェイの ErrorPortAllocation CloudWatch メトリクスを表示することでモニタリングできます。詳細については、 「Amazon CloudWatch を使用した NAT ゲートウェイのモニタリング 」を参照してください。 翌日会員基盤API側のIPアドレスを増やす形で制限事項に該当しないように変更しました。 ２時間ぐらいでやってくれた担当の方に心から感謝しました。
22. © DMM.com 4/12 クーポン発行終了 22 ４月１２日１２：００（お昼）でクーポン発行も終了し一段落つく。ただしクーポンは取得から１週間利用可能なため引き続きサーバ状況に は注視しつつ、バックオフィス系の連携がデータ量が多くいくつか失敗している問題に着手開始。 その他、PHPでcURLを使ったAPIへのコネクションが残り続ける問題や、 ElasticSearchのDescribeElasticSearchDomeinリクエストを 呼び出し過ぎてAWSさんから至急対応をお願いされる、数千以上のスプレットブレインの対応などいくつか問題が起きたのですが、次 回話す時のネタとしてストックさせて下さい。
23. © DMM.com まとめ 23
24. © DMM.com 24 書籍配信サーバ 日々増え続けるアクセスおよび負荷に耐えられる AWS化（CloudFront + S3）へ移行 アプリケーション見直し NewRelic/Datadogを活用しSlowクエリ及びアプリケーションのボトルネックを定期的に調査 監視項目の追加 NatGatewayのメトリクスは監視対象に含まれていなかったため追加 APMの本格導入 DataDogを利用していたがPHPフレームワークが対応していなかったため NewRelicへ乗り換え Memcachedの再移行 ネットワーク帯域を考慮したスペックへ変更し再切り替え 外部APIへのタイムアウト見 直し NatGatewayのポートを使い切らないようタイムアウト値を見直し その後対応した対策
25. © DMM.com 今回の勉強会のテーマを踏まえての総括 25 • 買えない／閲覧できないなど、新規・既存どちらのユーザにも大きな迷惑をかけた点については反省しました • ただ社内ではチームが批判に晒されるなどネガティブなものはありませんでした • その背景には、なぜそれが起きたのかきちんとデータを収集出来ており、その原因を探り、改善のアクションに繋げられる状態に なっていたからだと思っています。 • 今回テーマがTech ValueのScientificですが、これが私の考える「Scientific」だと思っています。 • 付け加えるなら、私はSRE部なのでSRE(Site Reliability Engineergin)におけるObservability(可観測性)だとも捉えています。 • 今回大きな失敗ではありましたが、それを乗り越えてプラットフォームとしてより強固になりました • さらには障害対応を通してチームの一体感もより出てよかった側面もあったと思っています
26. © DMM.com 宣伝 26 https://book.dmm.com/book/feature/friday-sale/index.html