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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© DMM.com DMMブックスのシステム構成 7 2021年4月当時のDMMブックスのシステム（主要部分に限定）オンプレ AWS webサーバ (ECS/AutoScaling) WWWサーバ（共通CSSなど）会員情報API 書籍配信サーバ (ebook01-04) DMMブックス担当以外の方が管理 DBサーバ (RDS MySQL/bookDB) Cacheサーバ (EC2/Memcached)

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© DMM.com 想定を上回る反響で早期終了告知 14 DMMブックス @DMM_DigitalBook 【お知らせ】  ユーザーの皆様から想定を上回るご反響をいただいたため、 4/12(月)11:59をもちまして「DMMブックス初回購入限定最大100 冊70%OFFクーポン」の配布を終了させて頂きます。  すでにクーポンをお持ちの方は使用期限内はご利用頂けます。  もちろん駆け込み需要が来る覚悟は出来てました

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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