Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ono-hiroshi1

October 08, 2021
Tweet

More Decks by ono-hiroshi1

Other Decks in Programming

Transcript

  1. © DMM.com 自己紹介 2 小野 博志 / Ono Hiroshi 合同会社DMM.com

    ITインフラ本部 SRE部 エンジニアリング マネージャー 2005年に新卒で中小独立系Sierに入社。Javaを使ったWeb系開発に従事。 2008年よりMSP(マネージド・サービス・プロバイダ)の業務に従事。アカウントSEから始まり、サービス企画や テクニカルディレクターを務める。エンタープライズの領域で大規模なコーポレートサイト、WebCMSを中心とし て担当していた。 2018年よりB2Cもやってみようかなって思って2020年にDMM.comに入社。DMMブックスやNewRelicの導 入推進を主に担当しています。 Ansible大好き人間ですが最近コンテナばっかり触っているので全然使えてないのが悲しみです。 いつの間にかAnsible 4系が出ているんですね。
  2. © DMM.com DMMブックスのシステム構成 7 2021年4月当時のDMMブックスのシステム(主要部分に限定) オンプレ AWS webサーバ (ECS/AutoScaling) WWWサーバ

    (共通CSSなど) 会員情報API 書籍配信サーバ (ebook01-04) DMMブックス 担当以外の方が 管理 DBサーバ (RDS MySQL/bookDB) Cacheサーバ (EC2/Memcached)
  3. © DMM.com 本日のお話を簡単にまとめると 9 • 70%OFFキャンペーンという大盤振る舞いをしたら予想以上の反響があって、売れ過ぎちゃって早期 終了することになりました。 • すると駆け込み需要でアクセスが集中し、最終的にDMMブックスのサイトが止まりました。 •

    なんとかするためにボトルネック見つけて改修したら、次々とボトルネックが見つかって一生懸命直して ました • なので今はとても盤石なプラットフォームが出来ましたというお話です
  4. © DMM.com 書籍配信サーバの高負荷(その1) 12 最初に古い書籍を配信するサーバが高負荷になりました。ただ、オンプレの物理サーバで大容量ディスクが必要ということもあり、用意 できず見守るだけでした。一番負荷が高くなるのが最新刊を配信するサーバではないという、今までとアクセス動向が大きく異なる状況 でした。 ebookサーバ ebook01サーバグループ ebook02サーバグループ

    ebook03サーバグループ ebook04サーバグループ 書籍が増えるたびに新しいサーバを追加 してきた。ebook03/04に新しい書籍が追 加されていく。 他のサーバグループも負荷は高かったが ebook01 が顕著に負荷が高くなった。サーバスペックも異な るが、100冊キャンペーンは冊数が多い、古いシ リーズものを買う人が一定層いたため影響が出や すい状態だった。
  5. © DMM.com Cacheサーバの切り替えで高負荷 13 EC2ベースでMemcachedを使ってましたが、スケールしにくいため、動作検証は終えていた AWS ElasticCache(Memcached)へ切り 替えました。サーバスペックは十分なものを用意していましたが、ピークタイム時にサイトが重くなってしまいました。 公式資料よりもかなり低い数値で頭打ちにななるよ うな仕様だった

    カタログスペックは最大と書いてあるので嘘ではな いが・・・ 実測値についての参考資料 :https://cloudonaut.io/ec2-network-perf ormance-cheat-sheet/ AWSではサーバスペックが低いとカタログスペックのネットワーク速度は出ないようです。そのことを把握しておらずピークタイム時の トラフィックに耐えれずレスポンスタイムの大幅な悪化に繋がりました。
  6. © DMM.com 想定を上回る反響で早期終了告知 14 DMMブックス @DMM_DigitalBook 【お知らせ】
 ユーザーの皆様から想定を上回るご反響をいただいたため、 4/12(月)11:59をもちまして「DMMブックス 初回購入限定最大100

    冊70%OFFクーポン」の配布を終了させて頂きます。
 すでにクーポンをお持ちの方は使用期限内はご利用頂けます。
 もちろん駆け込み需要が来る覚悟は出来てました
  7. © DMM.com 会員基盤APIへの大量アクセスであわや全体障害に 20 購入時の処理においてN+1問題が発生していました。具体的には100冊本を買うと100回ユーザの情報を取得していました。大量アク セス+キャンペーンで大量の冊数を買うユーザが殺到しており、会員基盤 APIに多数のアクセスをしてしまいDMM全体の障害の恐れが 出てきました。 AWS側のホスト数の推移 意図的にオートスケールの台数を絞って

    会員基盤APIへのリクエスト数を縛ることに その夜はアプリケーションの改修は行わず AWS側はリクエスト数に応じて オートスケールする こちらのリクエストを絞った上で会員基盤 API側のサーバ追加を行うことで全体影響ほぼでなかったが、 DMMブックスとしてはエラー を検知していたのでさらなる調査に
  8. © 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アドレスを増やす形で制限事項に該当しないように変更しました。 2時間ぐらいでやってくれた担当の方に心から感謝しました。
  9. © DMM.com 24 書籍配信サーバ 日々増え続けるアクセスおよび負荷に耐えられる AWS化(CloudFront + S3)へ移行 アプリケーション見直し NewRelic/Datadogを活用しSlowクエリ及びアプリケーションのボトルネックを定期的に調査

    監視項目の追加 NatGatewayのメトリクスは監視対象に含まれていなかったため追加 APMの本格導入 DataDogを利用していたがPHPフレームワークが対応していなかったため NewRelicへ乗り換え Memcachedの再移行 ネットワーク帯域を考慮したスペックへ変更し再切り替え 外部APIへのタイムアウト見 直し NatGatewayのポートを使い切らないようタイムアウト値を見直し その後対応した対策
  10. © DMM.com 今回の勉強会のテーマを踏まえての総括 25 • 買えない/閲覧できないなど、新規・既存どちらのユーザにも大きな迷惑をかけた点については反省しました • ただ社内ではチームが批判に晒されるなどネガティブなものはありませんでした • その背景には、なぜそれが起きたのかきちんとデータを収集出来ており、その原因を探り、改善のアクションに繋げられる状態に

    なっていたからだと思っています。 • 今回テーマがTech ValueのScientificですが、これが私の考える「Scientific」だと思っています。 • 付け加えるなら、私はSRE部なのでSRE(Site Reliability Engineergin)におけるObservability(可観測性)だとも捉えています。 • 今回大きな失敗ではありましたが、それを乗り越えてプラットフォームとしてより強固になりました • さらには障害対応を通してチームの一体感もより出てよかった側面もあったと思っています