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

Transcript

1. © DMM.com
   60億円の損害を出した
   「DMMブックス」
   70％OFFキャンペーンでプラットフォームに何が起きていたか
   合同会社 DMM.com SRE部 小野 博志
   2021/10/07
   

   View Slide

2. © DMM.com
   自己紹介
   2
   小野 博志 / Ono Hiroshi
   合同会社DMM.com
   ITインフラ本部 SRE部
   エンジニアリング　マネージャー
   ２００５年に新卒で中小独立系Sierに入社。Javaを使ったWeb系開発に従事。
   ２００８年よりMSP（マネージド・サービス・プロバイダ）の業務に従事。アカウントSEから始まり、サービス企画や
   テクニカルディレクターを務める。エンタープライズの領域で大規模なコーポレートサイト、WebCMSを中心とし
   て担当していた。
   ２０１８年よりB2Cもやってみようかなって思って２０２０年にDMM.comに入社。DMMブックスやNewRelicの導
   入推進を主に担当しています。
   Ansible大好き人間ですが最近コンテナばっかり触っているので全然使えてないのが悲しみです。
   いつの間にかAnsible 4系が出ているんですね。
   

   View Slide

3. © DMM.com
   予備知識として
   3
   

   View Slide

4. © DMM.com
   話題のコミックや小説などを
   パソコンやスマホで 読めるプラットフォーム
   コミック、雑誌、小説、写真集等の電子書籍を配信しております。現在は
   66万冊以上の作品を取り揃えており
   さまざまなジャンルの作品を提供しています。
   

   View Slide

5. © DMM.com
   DMMブックス 70%OFFキャンペーンとは
   「DMM電子書籍」から「DMMブックス」へとサービス名称を変更することを記念して始めたキャンペーン。
   ３月２５日〜６月３０日の期間限定で、初回購入者限定にはなるが、ほぼ全ての作品が最大１００冊まで
   70%OFFで購入できる破格のキャンペーン。
   今までも50%OFFクーポンは存在していたが今回は記念ということで今まで類を見ない大盤振る舞いを実施した。
   5
   

   View Slide

6. © DMM.com
   キャンペーンのビジネス的な裏側
   6
   ぜひ弊社のオウンドメディアの記事 「60億円の損害を出した「DMMブックス」70％OFFキャンペーン早期終了の裏側を責任者と会長に
   聞いた。」を御覧ください。
   LINK: https://inside.dmm.com/entry/2021/07/01/dmm-books
   

   View Slide

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)
   

   View Slide

8. © DMM.com
   本題
   8
   

   View Slide

9. © DMM.com
   本日のお話を簡単にまとめると
   9
   • 70%OFFキャンペーンという大盤振る舞いをしたら予想以上の反響があって、売れ過ぎちゃって早期
   終了することになりました。
   • すると駆け込み需要でアクセスが集中し、最終的にDMMブックスのサイトが止まりました。
   • なんとかするためにボトルネック見つけて改修したら、次々とボトルネックが見つかって一生懸命直して
   ました
   • なので今はとても盤石なプラットフォームが出来ましたというお話です
   

   View Slide

10. © DMM.com
    キャンペーンに備えて
    10
    • いつものキャンペーンと同じぐらいだろうと想定してキャンペーン前にスペックアップなど事前準備をし
    ていました
    • 実際キャンペーン開始当初は想定通りの負荷状況でした
    • しかしある日を境にとてつもないアクセスが来るようになりました
    

    View Slide

11. © DMM.com
    きっかけは一つのツイートでした
    11
    XXXX
    @XXXXXXXXX
    TLのオタクへ

    今DMMブックスで初めて漫画買う人にもれなく70パーセントOFF
    のクーポン貰えるからめちゃくちゃお得やで!!!!!!!!!!!!!!私はハイ
    キューと鬼滅とヒロアカ全巻（99巻）買って14000円いかなかった

    いくつかのツイートによってバズリました
    

    View Slide

12. © DMM.com
    書籍配信サーバの高負荷(その１)
    12
    最初に古い書籍を配信するサーバが高負荷になりました。ただ、オンプレの物理サーバで大容量ディスクが必要ということもあり、用意
    できず見守るだけでした。一番負荷が高くなるのが最新刊を配信するサーバではないという、今までとアクセス動向が大きく異なる状況
    でした。
    ebookサーバ
    ebook01サーバグループ
    ebook02サーバグループ
    ebook03サーバグループ
    ebook04サーバグループ
    書籍が増えるたびに新しいサーバを追加
    してきた。ebook03/04に新しい書籍が追
    加されていく。
    他のサーバグループも負荷は高かったが
    ebook01
    が顕著に負荷が高くなった。サーバスペックも異な
    るが、100冊キャンペーンは冊数が多い、古いシ
    リーズものを買う人が一定層いたため影響が出や
    すい状態だった。
    

    View Slide

13. © DMM.com
    Cacheサーバの切り替えで高負荷
    13
    EC2ベースでMemcachedを使ってましたが、スケールしにくいため、動作検証は終えていた
    AWS ElasticCache(Memcached）へ切り
    替えました。サーバスペックは十分なものを用意していましたが、ピークタイム時にサイトが重くなってしまいました。
    公式資料よりもかなり低い数値で頭打ちにななるよ
    うな仕様だった
    カタログスペックは最大と書いてあるので嘘ではな
    いが・・・
    実測値についての参考資料
    ：https://cloudonaut.io/ec2-network-perf
    ormance-cheat-sheet/
    AWSではサーバスペックが低いとカタログスペックのネットワーク速度は出ないようです。そのことを把握しておらずピークタイム時の
    トラフィックに耐えれずレスポンスタイムの大幅な悪化に繋がりました。
    

    View Slide

14. © DMM.com
    想定を上回る反響で早期終了告知
    14
    DMMブックス
    @DMM_DigitalBook
    【お知らせ】

    ユーザーの皆様から想定を上回るご反響をいただいたため、
    4/12(月)11:59をもちまして「DMMブックス 初回購入限定最大100
    冊70%OFFクーポン」の配布を終了させて頂きます。

    すでにクーポンをお持ちの方は使用期限内はご利用頂けます。

    もちろん駆け込み需要が来る覚悟は出来てました
    

    View Slide

15. © DMM.com
    RDSのCPUが高まったためスペック変更
    15
    終了告知によりさらにアクセスが増え
    RDSのCPU使用率が大きく上昇した。ここから更に増えることも予想できたためスペックアップを実
    施しました。vCPU換算で40vCPUから96vCPUまで増やした（台数を減らしてスペックをあげた）
    ある1台のRDSのCPU使用率。まだまだ増えそう
    な傾向があったが、スペック変更で半分程度まで落
    ち着いた
    これで一定のレスポンスタイムは確保できるように
    

    View Slide

16. © DMM.com
    共通アセット系のサーバで遅延
    16
    DMMではサービス横断の共通のアセット（
    CSS/JS/Image）が存在します。wwwサーバから配信しており、DMMブックスのアクセス増
    により別サイトで閲覧しにくい状況が生まれました。
    Apacheのワーカープロセスが上限に達しており、リソースを見ると余裕があったため
    Apacheの設定を見直して復旧しました
    

    View Slide

17. © DMM.com
    そして今回最大の危機へ
    ほとんど使えてなかった夜です
    17
    

    View Slide

18. © DMM.com
    某ネットメディアの紹介から更にアクセスが・・
    18
    XXXX
    @XXXXXXXXX
    DMMブックスの最大100冊70％オフクーポン、予定より早く明日
    12日11時59分までで配布終了となったためご注意ください（クー
    ポンだけでも入手しておけば、取得後7日間まで使用可能です／
    現在サイトがかなり重くなっているようです）
    紹介してくれるのはありがたいけど辛い
    

    View Slide

19. © DMM.com
    書籍配信サーバの高負荷(その２)
    19
    ebook03と04は耐えていたが、ebook01と02が高負荷になりました。さらにebook01は分散ファイルシステムとしてGlusterFSを利用し
    ていますが、GlusterFSのコマンド実行が、応答を返さない
    /返しても恐ろしく遅い状態になっていました。
    しかも再起動した場合に立ち上がらない恐れもあり触れない状態となっていた。そしてスプリットブレイン（同期不整合）が起きていたこと
    も後からわかった。それでもユーザからの応答は返せていたのは首の皮一枚繋がったと思ってました。
    突出している２つのラインが
    ebook01/02
    このグラフでは丸められてしまっているがリアルタ
    イムでは100を超える瞬間もあった。
    

    View Slide

20. © DMM.com
    会員基盤APIへの大量アクセスであわや全体障害に
    20
    購入時の処理においてN+1問題が発生していました。具体的には１００冊本を買うと１００回ユーザの情報を取得していました。大量アク
    セス＋キャンペーンで大量の冊数を買うユーザが殺到しており、会員基盤
    APIに多数のアクセスをしてしまいDMM全体の障害の恐れが
    出てきました。
    AWS側のホスト数の推移
    意図的にオートスケールの台数を絞って
    会員基盤APIへのリクエスト数を縛ることに
    その夜はアプリケーションの改修は行わず
    AWS側はリクエスト数に応じて
    オートスケールする
    こちらのリクエストを絞った上で会員基盤
    API側のサーバ追加を行うことで全体影響ほぼでなかったが、
    DMMブックスとしてはエラー
    を検知していたのでさらなる調査に
    

    View Slide

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アドレスを増やす形で制限事項に該当しないように変更しました。
    ２時間ぐらいでやってくれた担当の方に心から感謝しました。
    

    View Slide

22. © DMM.com
    4/12 クーポン発行終了
    22
    ４月１２日１２：００（お昼）でクーポン発行も終了し一段落つく。ただしクーポンは取得から１週間利用可能なため引き続きサーバ状況に
    は注視しつつ、バックオフィス系の連携がデータ量が多くいくつか失敗している問題に着手開始。
    その他、PHPでcURLを使ったAPIへのコネクションが残り続ける問題や、
    ElasticSearchのDescribeElasticSearchDomeinリクエストを
    呼び出し過ぎてAWSさんから至急対応をお願いされる、数千以上のスプレットブレインの対応などいくつか問題が起きたのですが、次
    回話す時のネタとしてストックさせて下さい。
    

    View Slide

23. © DMM.com
    まとめ
    23
    

    View Slide

24. © DMM.com 24
    書籍配信サーバ 日々増え続けるアクセスおよび負荷に耐えられる
    AWS化（CloudFront + S3）へ移行
    アプリケーション見直し NewRelic/Datadogを活用しSlowクエリ及びアプリケーションのボトルネックを定期的に調査
    監視項目の追加 NatGatewayのメトリクスは監視対象に含まれていなかったため追加
    APMの本格導入 DataDogを利用していたがPHPフレームワークが対応していなかったため
    NewRelicへ乗り換え
    Memcachedの再移行 ネットワーク帯域を考慮したスペックへ変更し再切り替え
    外部APIへのタイムアウト見
    直し
    NatGatewayのポートを使い切らないようタイムアウト値を見直し
    その後対応した対策
    

    View Slide

25. © DMM.com
    今回の勉強会のテーマを踏まえての総括
    25
    • 買えない／閲覧できないなど、新規・既存どちらのユーザにも大きな迷惑をかけた点については反省しました
    • ただ社内ではチームが批判に晒されるなどネガティブなものはありませんでした
    • その背景には、なぜそれが起きたのかきちんとデータを収集出来ており、その原因を探り、改善のアクションに繋げられる状態に
    なっていたからだと思っています。
    • 今回テーマがTech ValueのScientificですが、これが私の考える「Scientific」だと思っています。
    • 付け加えるなら、私はSRE部なのでSRE(Site Reliability Engineergin)におけるObservability(可観測性)だとも捉えています。
    • 今回大きな失敗ではありましたが、それを乗り越えてプラットフォームとしてより強固になりました
    • さらには障害対応を通してチームの一体感もより出てよかった側面もあったと思っています
    

    View Slide

26. © DMM.com
    宣伝
    26
    https://book.dmm.com/book/feature/friday-sale/index.html
    

    View Slide