秒間1800リクエストの世界 / The world of 1800 reqs per sec

秒間1800リクエストの世界 / The world of 1800 reqs per sec

PHPカンファレンス福岡2017の資料です

40575ebf9c2f4a6e3bcb68630f446a3b?s=128

HASEGAWA Tomoki

June 10, 2017
Tweet

Transcript

  1. 1,800リクエスト/秒の世界 The world of 1,800 requests / sec 長谷川智希 HASEGAWA

    Tomoki
  2. 長谷川 智希 デジタルサーカス株式会社 副団長CTO Digital Circus, Inc. Vice-master CTO Tokyo,

    Japan @tomzoh
  3. ライフワーク: Web / iOSアプリ開発, ビール, 電子工作,
 サッカー観戦, レンタルカートレース, … 長谷川

    智希 Web / iOS App Development, Beer, IoT, Watch soccer match, Rental Kart Racing, … デジタルサーカス株式会社 副団長CTO Digital Circus, Inc. Vice-master CTO Tokyo, Japan Lifeworks: @tomzoh
  4. None
  5. None
  6. WE ARE HIRING!! Web Development Mobile App Development ( )

    (iOS, Android) http://www.dgcircus.com Omotesando, Tokyo
  7. 今日のテーマ The world of 1,800 requests / sec 1,800リクエスト/秒の世界 Today’s

    theme
  8. システム概要

  9. 今回の対象システム • Web + API + iOS/Android アプリ • 就職活動関連アプリ

    • ユーザ数: 100万前後
  10. 今回の対象システム • Web + API + iOS/Android アプリ • 就職活動関連アプリ

    • ユーザ数: 100万前後
  11. システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB iOS / Android Mobile Apps 1,000,000users
  12. 技術スタック

  13. 技術スタック 今日の話

  14. 負荷がやってくる

  15. なぜわかっている?

  16. 03/01 0:00 就職活動解禁

  17. 負荷 • 負荷がやってくる

  18. 負荷 • 負荷がやってくる • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る •

    負荷を作り出して構成を調整
  19. 負荷 • 負荷がやってくる • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る •

    負荷を作り出して構成を調整 • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
  20. • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •

    負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
  21. 負荷の計算に使える材料

  22. 負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率

  23. 負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec

  24. 負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec 30%

  25. 負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec 30% ×

  26. \3,000 PV/sec /

  27. \3,000 PV/sec / ざわ... ざわ...

  28. まあ待て

  29. 落ち着け

  30. Ȑ

  31. Ȑ API

  32. PV APIコール

  33. PV APIコール ≠

  34. PV APIコール ≠ 変換

  35. PV → API • ユーザがどういう行動を取るか • シナリオを作成 • シナリオの各ステップで発生するAPIコールをリストアップ •

    シナリオの各ステップから、同じ動作をWebで実施した場合 に発生するPVに変換 • PV → APIコールの変換ができる
  36. シナリオ No. 操作 ユーザ 操作 処理 時間 仮想 PV 1

    アプリ初回起動 1 2 ログイン画面からのログイン処理 10 1 2 3 ホーム表示 2 1 1 4 検索タブ表示 2 1 5 検索 10 2 3 6 検索結果一覧画面表示 1 7 (詳細画面 → エントリー)x 30 3,000 120 120
  37. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
  38. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
  39. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
  40. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
  41. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
  42. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
  43. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
  44. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
  45. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
  46. シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒

    シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
  47. シナリオが出来た

  48. • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •

    負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
  49. システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB
  50. システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ 16 × m4.large vCPU: 2 / memory: 8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ
  51. None
  52. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする?

  53. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM

    VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start
  54. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM

    VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start
  55. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM

    VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB
  56. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM

    VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB 8GB中1.6GB(20%)くらいOSに…。 残り80%(6.4GB)をApacheに。
  57. Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM

    VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB 8GB中1.6GB(20%)くらいOSに…。 残り80%(6.4GB)をApacheに。 80% / 0.4% = 200
  58. Apache設定 Timeout 10 KeepAliveTimeout 120 StartServers 200 MinSpareServers 200 MaxSpareServers

    200 ServerLimit 200 MaxClients 200
  59. • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •

    負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
  60. 負荷メーカーと言えば彼

  61. None
  62. JMeterでシナリオを実装する 

  63. JMeterでシナリオを実装する シナリオ ウェイト 処理 時間 仮想 PV 創出 PV/sec シナリオ

    割合 必要 PV/秒 同時セッシ ョン シナリオ2 27 10 8 0.22 40% 1,200 5,550 
  64. JMeterでシナリオを実装する シナリオ ウェイト 処理 時間 仮想 PV 創出 PV/sec シナリオ

    割合 必要 PV/秒 同時セッシ ョン シナリオ2 27 10 8 0.22 40% 1,200 5,550 
  65. シナリオが実装できた

  66. よし負荷テストだ

  67. None
  68. 実行!!

  69. /ファー\ 実行!!

  70. None
  71. Macのファン全開

  72. Macのファン全開 • 今回欲しかった並行実行数は27,000セッション。 • Mac 1台では負荷をかけきれない。

  73. どうしたか

  74. スケールアウト

  75. システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ
  76. システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ 5 × m4.large vCPU: 2 / memory: 8GB EC2 Ȑ Ȑ Ȑ
  77. 

  78. 

  79. None
  80. システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:

    8GB  EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ 5 × m4.large vCPU: 2 / memory: 8GB EC2 Ȑ Ȑ Ȑ
  81. さて本格負荷テストだ

  82. ……

  83. まったく捌けない

  84. 予想外にキツイ

  85. 予想外にキツイ • 負荷をかけ始めた瞬間にレスポンスが悪化し、
 ELBから外される。 • すべてのWebサーバがELBから外されて
 ゲームオーバー。 • 5分と保たない。

  86. どうしよう

  87. 対策を考えよう

  88. まず起動プロセスを整理

  89. APIコール Ȑ

  90. APIコール Ȑ 端末登録

  91. APIコール Ȑ 端末登録 デバイストークン登録

  92. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得

  93. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得

  94. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得

  95. 負荷対策 • APIの特徴: 多くは参照系かつ全員同じ。

  96. 負荷対策 • APIの特徴: 多くは参照系かつ全員同じ。
 →静的ファイル化してしまおう • CakePHPを使っている • app/webroot 配下にファイルを置けばApacheだけでリクエ

    スト & レスポンスが完了する。 • CakePHPが実行されないので(PHP比)超高速に処理可能。
  97. どうなったか

  98. 爆★速

  99. Ȑ システム設定取得

  100. Ȑ システム設定取得

  101. 静的ファイル化 • いくつかのAPIを静的ファイル化
 → 現実的な速度が出る様になった。 • 副作用:
 管理画面から値を変更してもAPIに反映されない • この高負荷体制は数日間の時限なのであまり問題にならな

    い。
  102. 負荷テスト完了

  103. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
  104. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
  105. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
  106. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
  107. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果 お得
  108. • Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。

    • Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
  109. よし、これで万全!

  110. そんなふうに考えていた時期が 俺にもありました

  111. さて当日

  112. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 12:00 PUSH通知
  113. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 12:00 PUSH通知
  114. アプリアップデート強制ON PUSH通知

  115. アプリアップデート強制ON PUSH通知 天井張り付き

  116. むむっ!?

  117. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
  118. アプリアップデート強制ON PUSH通知

  119. アプリアップデート強制ON PUSH通知

  120. アプリアップデート強制ON PUSH通知 API静的化

  121. ひと安心

  122. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
  123. アプリクローズ Ȑ 端末登録 デバイストークン登録 システム設定取得

  124. アプリクローズ Ȑ 端末登録 デバイストークン登録 システム設定取得 「アプリクローズ」

  125. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
  126. None
  127. None
  128. まあまあ…落ち着いた

  129. タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00

    PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
  130. 2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1

    3:00 JST サイト・アプリオープン RDS
  131. 2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1

    3:00 JST サイト・アプリオープン 0:03JST 1,800リクエスト/秒 RDS
  132. 2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1

    3:00 JST サイト・アプリオープン 0:03JST 1,800リクエスト/秒 RDS
  133. 昼になっても落ち着かない…

  134. 対策するか…

  135. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得

  136. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的

  137. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的

    動的 動的
  138. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的

    動的 動的 初回のみ
  139. APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的

    動的 動的 初回のみ 起動のたび
  140. None
  141. デバイストークン登録API、 ユーザを探すSQLが遅いな…

  142. デバイストークン登録API、 ユーザを探すSQLが遅いな… 検索キーにインデックスが無い…

  143. デバイストークン登録API、 ユーザを探すSQLが遅いな… 検索キーにインデックスが無い… 開発環境で…

  144. mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------+---------+- |

    id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------+---------+- | 1 | SIMPLE | users | NULL | ALL | NULL | NULL | NULL | +----+-------------+-------+------------+------+---------------+------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.25 sec)
  145. mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------+---------+- |

    id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------+---------+- | 1 | SIMPLE | users | NULL | ALL | NULL | NULL | NULL | +----+-------------+-------+------------+------+---------------+------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.25 sec) フルスキャンになってて0.25secかかってる…。 インデックス足してみよう。
  146. mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------------+---------+- |

    id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------------+---------+- | 1 | SIMPLE | users | NULL | ref | index_hash | index_hash | 162 | +----+-------------+-------+------------+------+---------------+------------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.00 sec)
  147. mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------------+---------+- |

    id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------------+---------+- | 1 | SIMPLE | users | NULL | ref | index_hash | index_hash | 162 | +----+-------------+-------+------------+------+---------------+------------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.00 sec) 効果絶大やんけ…。
  148. None
  149. 本番に足したろ。

  150. 本番に足したろ。 mysql> alter table users add index …

  151. 本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし

    Ctrl + C も怖い。 しばらく置いておこう…。
  152. 本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし

    Ctrl + C も怖い。 しばらく置いておこう…。
  153. 本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし

    Ctrl + C も怖い。 しばらく置いておこう…。 DBサーバの負荷がむっちゃ 下がったんですが、 何か起きてますか!?
  154. RDS

  155. インデックス追加完了 RDS

  156. むっちゃサックサクに

  157. めでたい!

  158. まとめ

  159. まとめ • 1,800リクエスト/秒の世界を体験した。 • 負荷試験 & 対策 • 負荷をかけるのにも工夫が必要。 •

    Apacheのエラーレートだけでなくサーバの
 リソース利用状況もチェックするべき。 • チューニング • Apacheで完結するアクセスは爆速。 • レコード数が多いテーブルではインデックス特に大事。
  160. あたりまえのことを あたりまえに

  161. Thanks WE ARE HIRING @tomzoh プリーズ: #phpconfuk / ブログ /

    懇親会
  162. AWS / EC2の注意点 • いろいろなものに制限がある。 • EC2インスタンス数 • IPアドレス数 •

    どちらも申請すると上げてもらえるけど1〜2営業日必要 • 負荷テストをする時にも申請が必要 • これも1〜2営業日
  163. 告知

  164. builderscon tokyo 2017 2017.08.3(木)〜5(土) https://builderscon.io/tokyo/2017 チケット販売中

  165. iOSDC Japan 2017 https://iosdc.jp/2017/ スポンサー募集中 2017.09.15(金)〜17(日)

  166. PHPerKaigi 2018 https://phperkaigi.jp スポンサー募集…するかも 2018.03.10(土) • PHPerのためのカンファレンス • 東京都練馬区 Coconeriホールにて

    • 朝から晩までテックトーク • 夕方からはビールを飲みながら • 夜はクラフトビールで懇親会
  167. Thanks WE ARE HIRING @tomzoh プリーズ: #phpconfuk / ブログ /

    懇親会