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

by koudenpa

Slide 1

Slide 1 text

マルチテナントのサービスインフラに大きなテナントを受け入れるまで 2024-10-15 Hatena Engineer Seminar #31 「少年ジャンプ＋」サーバーサイド編 id:koudenpa

Slide 2

Slide 2 text

自己紹介 ● id:koudenpa ○ コウデン ● はてなでの役割 ○ マンガメディア開発チーム ○ テックリード ■ エンジニアリングを広く見る

Slide 3

Slide 3 text

GigaViewer ● はてなが提供するマンガビューワ ● GigaViewer for Apps ● GigaViewer for Web ● 「マルチテナントのサービス」

Slide 4

Slide 4 text

マルチテナントのサービス https://hatena.co.jp/solutions/gigaviewer

Slide 5

Slide 5 text

少年ジャンプ＋ ● 株式会社集英社が配信するマンガサービス ● スマホアプリ版 ● Webブラウザ版 ● 「大きなテナント」

Slide 6

Slide 6 text

少年ジャンプ＋とGigaViewer ● 2024年3月末にfor Appsに提供開始 ● for Webへは以前から提供中 ● GigaViewer for Appsに ● 少年ジャンプ＋を ● 「受け入れる」 https://hatena.co.jp/press/release/entry/2024/03/29/120000

Slide 7

Slide 7 text

目次 ● 受け入れるテナントの規模 ● インフラの分割 ● 想定される負荷の試験 ● リリース後の対応

Slide 8

Slide 8 text

受け入れるテナントの規模

Slide 9

Slide 9 text

パブリックな数字を見てみる

Slide 10

Slide 10 text

素朴に大きい ● 数字の規模が明らかに大きい ● UU/リクエスト数等も多いと分かっている

Slide 11

Slide 11 text

インフラの分割

Slide 12

Slide 12 text

GigaViewerの構成 GigaViewer サーバサイド（テナント共通）テナントA テナントB テナントC

Slide 13

Slide 13 text

GigaViewerサーバサイドスケールアウト可 ● アプリケーション実行環境スケールアウト不可 ● 各種データベース

Slide 14

Slide 14 text

インフラ分割の判断 ● スケールアウト不可リソースの上限 ○ 超えるリスク ● スケールアウト可リソースのテナント間影響 ○ 想定外の影響リスク ● 一式独立したものに分割

Slide 15

Slide 15 text

素朴に分割実施 ● 分割先環境一式を構築 ● メンテナンスイン ○ 【重要】ブラウザ版メンテナンス実施のお知らせ 12/21(木) 午前1:00～5:00 ● DBを複製 ● DNSレコードを分割先に切り替え ● メンテナンスアウト https://shonenjumpplus.com/article/infomation_231221

Slide 16

Slide 16 text

分割先環境一式を構築 DNS 既存サーバー環境既存 DB 新設サーバー環境新設 DB 全テナント

Slide 17

Slide 17 text

メンテナンス中にDB複製 DNS 既存サーバー環境既存 DB 新設サーバー環境新設 DB メンテナンス

Slide 18

Slide 18 text

DNSを切り替えてメンテナンスアウト DNS 既存サーバー環境既存 DB 新設サーバー環境新設 DB 他テナント少年ジャンプ＋

Slide 19

Slide 19 text

構築はできる限り便利に

Slide 20

Slide 20 text

結果 ● 独立した本番運用環境 ● 受け入れ後の出来事の影響範囲が最小化

Slide 21

Slide 21 text

想定される負荷の試験

Slide 22

Slide 22 text

想定される負荷「UU/リクエスト数等も多いと分かっている」 ● 分かっている数値が基本

Slide 23

Slide 23 text

試験シナリオ ● 個別の操作毎の呼び出し ● ピークタイムのリクエスト傾向再現 ● 分かっている数値に安全係数を掛けて設定

Slide 24

Slide 24 text

試験環境 ● 負荷試験向けの独立環境を構築 ● 本番想定のリソースサイズに設定 ● 本番相当量のデータを投入

Slide 25

Slide 25 text

構築はまぁまぁ便利に

Slide 26

Slide 26 text

試験実施 ● シナリオ実行 ● 素朴にボトルネック修正 ● 想定負荷に耐えるまで繰り返しシナリオ実行ボトルネック修正試験結果試験環境更新 k6 Performance Insights, X-Ray, etc

Slide 27

Slide 27 text

データベース周り修正 ● Performance Insights ○ 試験実施中の結果を見て ○ 時間が掛かっているクエリ周りを見直す ○ INDEXを付けるのが主

Slide 28

Slide 28 text

アプリケーション修正 ● X-Ray ○ 負荷試験で遅かったトレースを見て ○ 時間が掛かっている処理周りを見直す ○ N+1、キャッシュ調整が主 ■ GraphQLのDataLoader/アプリケーションキャッシュなど

Slide 29

Slide 29 text

結果 ● 想定負荷の試験をパス ● 受け入れ準備整う

Slide 30

Slide 30 text

そして

Slide 31

Slide 31 text

リリース ● メンテナンスイン ○ 【重要】3月28日長時間メンテナンス実施およびアプリ仕様変更のお知らせ ● リリース作業 ○ データの移行含めて諸々計画した ○ このスライドはそれを書くには狭すぎる ● メンテナンスアウト…… https://shonenjumpplus.com/article/info20240328

Slide 32

Slide 32 text

リリース後の対応

Slide 33

Slide 33 text

リリース当日 ● 想定外の負荷はあった ● ホットフィックス！

Slide 34

Slide 34 text

リリース後 ● 想定外の負荷はあった ● 都度フィックス！！

Slide 35

Slide 35 text

素朴に適宜対応 ● 想定ではなく実際 ● 対応はしやすい

Slide 36

Slide 36 text

特に印象的だった対応 ● 色々あった ○ 本番だけ重いSQL ○ キャッシュ漏れ ○ etc ● ぶっちぎりNo.1印象深かったのは？

Slide 37

Slide 37 text

ある月曜0時のリクエスト数 ● 月曜0時とは？ ● 週刊少年ジャンプの配信時刻 23:00 00:00

Slide 38

Slide 38 text

ALBのスパイク耐性を突破 ● 噂によると…… ● 5分で5倍になると耐えられない ● 1分未満で5倍以上 ● ALBは数分遅れでスケールアウト ○ CloudTrailにNICの作成ログ

Slide 39

Slide 39 text

スパイク対応 ● ALBを暖機するか ● スパイク耐性のあるNLBに移行するか ● 後者で対応 ● ALBとNLBでは機能が違うが？ ● 今回は適合した

Slide 40

Slide 40 text

結果 ● なんとか受け入れ後も運用できている

Slide 41

Slide 41 text

まとめ

Slide 42

Slide 42 text

大きなテナントを受け入れるに当って ● 見積もって ○ 受け入れるテナントの規模 ● 準備して ○ インフラの分割 ● 検証して ○ 想定される負荷の試験 ● 受け入れた ○ リリース後の対応

Slide 43

Slide 43 text

これから ● 素朴に都度対応 ● SREをやっていく