マルチテナントのサービスインフラに大きなテナントを受け入れるまで

Hatena Engineer Seminar #31 「少年ジャンプ＋」 サーバーサイド編
https://hatena.connpass.com/event/331414/
2024/10/15(火)
のうち「マルチテナントのサービスインフラに大きなテナントを受け入れるまで」のスライドです。

GigaViewerはマルチテナントで様々な規模のサービスを運用していました。大きなテナントを受け入れるには、サービスインフラの面で考慮すべき点がありました。主に想定される負荷への対応の流れをお話します。

Transcript

1. マルチテナントのサービスインフラ に大きなテナントを受け入れるまで 2024-10-15 Hatena Engineer Seminar #31 「少年ジャンプ＋」 サーバーサイド編 id:koudenpa
2. 自己紹介 • id:koudenpa ◦ コウデン • はてなでの役割 ◦ マンガメディア開発チーム ◦ テックリード ▪ エンジニアリングを広く見る
3. GigaViewer • はてなが提供するマンガビューワ • GigaViewer for Apps • GigaViewer for Web • 「マルチテナントのサービス」
4. マルチテナントのサービス https://hatena.co.jp/solutions/gigaviewer
5. 少年ジャンプ ＋ • 株式会社集英社が配信するマンガサービス • スマホアプリ版 • Webブラウザ版 • 「大きなテナント」
6. 少年ジャンプ ＋とGigaViewer • 2024年3月末にfor Appsに提供開始 • for Webへは以前から提供中 • GigaViewer for Appsに • 少年ジャンプ＋を • 「受け入れる」 https://hatena.co.jp/press/release/entry/2024/03/29/120000
7. 目次 • 受け入れるテナントの規模 • インフラの分割 • 想定される負荷の試験 • リリース後の対応
8. 受け入れるテナントの規 模
9. パブリックな数字を見てみる
10. 素朴に大きい • 数字の規模が明らかに大きい • UU/リクエスト数等も多いと分かっている
11. インフラの分割
12. GigaViewerの構成 GigaViewer サーバサイド （テナント共通） テナントA テナントB テナントC
13. GigaViewerサーバサイド スケールアウト可 • アプリケーション 実行環境 スケールアウト不可 • 各種データベース
14. インフラ分割の判断 • スケールアウト不可リソースの上限 ◦ 超えるリスク • スケールアウト可リソースのテナント間影響 ◦ 想定外の影響リスク • 一式独立したものに分割
15. 素朴に分割実施 • 分割先環境一式を構築 • メンテナンスイン ◦ 【重要】 ブラウザ版メンテナンス実施のお知らせ 12/21(木) 午前1:00～5:00 • DBを複製 • DNSレコードを分割先に切り替え • メンテナンスアウト https://shonenjumpplus.com/article/infomation_231221
16. 分割先環境一式を構築 DNS 既存 サーバー環境 既存 DB 新設 サーバー環境 新設 DB 全テナント
17. メンテナンス中にDB複製 DNS 既存 サーバー環境 既存 DB 新設 サーバー環境 新設 DB メ ン テ ナ ン ス
18. DNSを切り替えてメンテナンスアウト DNS 既存 サーバー環境 既存 DB 新設 サーバー環境 新設 DB 他テナント 少年 ジャンプ＋
19. 構築はできる限り 便利に
20. 結果 • 独立した本番運用環境 • 受け入れ後の出来事の影響範囲が最小化
21. 想定される負荷の試験
22. 想定される負荷 「UU/リクエスト数等も多いと分かっている」 • 分かっている数値が基本
23. 試験シナリオ • 個別の操作毎の呼び出し • ピークタイムのリクエスト傾向再現 • 分かっている数値に安全係数を掛けて設定
24. 試験環境 • 負荷試験向けの独立環境を構築 • 本番想定のリソースサイズに設定 • 本番相当量のデータを投入
25. 構築はまぁまぁ 便利に
26. 試験実施 • シナリオ実行 • 素朴にボトルネック修正 • 想定負荷に耐えるまで繰り返し シナリオ実行 ボトルネック修正 試験結果 試験環境更新 k6 Performance Insights, X-Ray, etc
27. データベース周り修正 • Performance Insights ◦ 試験実施中の結果を見て ◦ 時間が掛かっているクエリ周りを見直す ◦ INDEXを付けるのが主
28. アプリケーション修正 • X-Ray ◦ 負荷試験で遅かったトレースを見て ◦ 時間が掛かっている処理周りを見直す ◦ N+1、キャッシュ調整が主 ▪ GraphQLのDataLoader/アプリケーションキャッシュなど
29. 結果 • 想定負荷の試験をパス • 受け入れ準備整う
30. そして
31. リリース • メンテナンスイン ◦ 【重要】3月28日 長時間メンテナンス実施およびアプリ 仕様変更のお知らせ • リリース作業 ◦ データの移行含めて諸々計画した ◦ このスライドはそれを書くには狭すぎる • メンテナンスアウト…… https://shonenjumpplus.com/article/info20240328
32. リリース後の対応
33. リリース当日 • 想定外の負荷はあった • ホットフィックス！
34. リリース後 • 想定外の負荷はあった • 都度フィックス！！
35. 素朴に適宜対応 • 想定ではなく実際 • 対応はしやすい
36. 特に印象的だった対応 • 色々あった ◦ 本番だけ重いSQL ◦ キャッシュ漏れ ◦ etc • ぶっちぎりNo.1印象深かったのは？
37. ある月曜0時のリクエスト数 • 月曜0時とは？ • 週刊少年ジャンプの配信時刻 23:00 00:00
38. ALBのスパイク耐性を突破 • 噂によると…… • 5分で5倍になると耐えられない • 1分未満で5倍以上 • ALBは数分遅れでスケールアウト ◦ CloudTrailにNICの作成ログ
39. スパイク対応 • ALBを暖機するか • スパイク耐性のあるNLBに移行するか • 後者で対応 • ALBとNLBでは機能が違うが？ • 今回は適合した
40. 結果 • なんとか 受け入れ後も運用できている
41. まとめ
42. 大きなテナントを受け入れるに当って • 見積もって ◦ 受け入れるテナントの規模 • 準備して ◦ インフラの分割 • 検証して ◦ 想定される負荷の試験 • 受け入れた ◦ リリース後の対応
43. これから • 素朴に都度対応 • SREをやっていく