ここがつらいよマルチテナント

2022/10/13に実施したイベント「最近チャレンジしたことをまとめてみた」で利用した資料
https://mgre.connpass.com/event/260781/

Transcript

1. ここがつらいよマルチテナント © MGRe, Inc. 2022.10.13 メグリ株式会社 プロダクト部サーバーサイドエンジニア 蔵下 正治
2. © MGRe, Inc. All Rights Reserved. 2 本日のお題 マルチテナント向けSaaS開発時の経緯とマルチテナントのつらみとその対策につ いて
3. © MGRe, Inc. All Rights Reserved. 3 Index 01. 本日のお題 02. MGReについて 03. MGReの歴史 04. 過去のサービスとの比較 05. マルチテナントにしてつらかった点 06. 対策 07. まとめ
4. © MGRe, Inc. All Rights Reserved. 4 MGReについて
5. © MGRe, Inc. All Rights Reserved. 5 MGReについて • マルチテナント向けのSaaS • ニュース、お知らせ、クーポン、店舗検索、プッシュ通知、アイテム 等 + 会員証の基本機能 • 様々なECや会員基盤システムと連携が可能 χϡʔε Ϋʔϙϯ ΞΠςϜ ళฮ ձһূ
6. © MGRe, Inc. All Rights Reserved. 6 MGReについて
7. © MGRe, Inc. All Rights Reserved. 7 過去のサービスとの比較 डୗ࣌୅ ؀ڥ γϯάϧςφϯτ γϯάϧςφϯτ Ϛϧνςφϯτ ࣮૷ํ๏ ϑϧεΫϥον ύοέʔδʢϕʔείʔυ͔Β੾Γ ग़͠
   ΧελϚΠζʣ 4BB4
   
   ΧελϜྖҬ αʔόʔʢ"84ʣ &$
   
   ".* &MBTUJD#FBOTUBML ʢϚωʔδυ&$ʣ 'BSHBUFʢίϯςφʣ σʔλϕʔε 3%4
   NZTRM "VSPSB "VSPSB4FSWFSMFTT Πϯϑϥ؅ཧ $MPVE'PSNBUJPO
   
   εΫϦϓτ $MPVE'PSNBUJPO σϓϩΠ $PEF1JQFMJOF $PEF1JQFMJOF
   
   &$3 ϩάɾσʔλऩू $MPVE8BUDI $MPVE8BUDI
   
   ,JOFTJT
   'JSFIPTF
8. © MGRe, Inc. All Rights Reserved. 8 マルチテナントにしてつらかった点
9. © MGRe, Inc. All Rights Reserved. 9 マルチテナントにしてつらかった点 • パフォーマンスの課題 ◦ DB（Aurora Serverless）の性能限界が見えてる ◦ WAF 等 AWS のリソース上限 • 運用の課題 ◦ テナント領域のアップデートが手間 ◦ テナントが混ざる • 一番の課題 ◦ やらかすと被害が大きい
10. © MGRe, Inc. All Rights Reserved. 10 • DB（Aurora Serverless）の限界 ◦ コンテナ（API）はいくらでも増やせる ◦ プッシュ配信時のスパイクアクセス ◦ MGRe のセグメント配信は仕様上キャッシュが難しい ◦ 通勤時（9時台）やスーパー等の小売はお昼過ぎ（12〜13時台）と夕方 （17時以降） パフォーマンスの課題 データベース容量（ACU） CPU使用率
11. © MGRe, Inc. All Rights Reserved. 11 • WAF 等 AWS のリソース上限 ◦ route53 でテナントごとにドメインを用意 → 上限500程度 ◦ テナントごとにロードバランサを用意 → 上限100程度 ◦ WAF による管理画面用 API の IP 制限 → 正規表現のため最大文字数 の制限 ◦ Aurora Serverless のさばける上限 → 上限 ACU 256（メモリ 488GB） パフォーマンスの課題
12. © MGRe, Inc. All Rights Reserved. 12 • テナント領域のアップデートが手間 ◦ テナント毎に異なる認証処理を吸収 ◦ mgre-auth という gem を用意 ◦ ある程度共通化はされているものの数が多い • テナントが混ざる 運用面の課題
13. © MGRe, Inc. All Rights Reserved. 13 • やらかすと被害が大きい ◦ あるテナントのユーザー数とニュースのレコード数が増加 ◦ それによりセグメント検索 API のパフォーマンスが低下 ◦ リクエストがつまり始める ◦ リクエストがつまっているためコンテナが新しく立ち上がり続ける ◦ コンテナ起動時に DockerHub からあるイメージをプルしていた ◦ 短時間にプルし過ぎたためレート制限 ◦ イメージをプル出来ずコンテナ起動失敗 ◦ 生きているコンテナも次々死ぬ ◦ コンテナがいなくなり全てのテナントでサービス停止😭 一番の課題
14. © MGRe, Inc. All Rights Reserved. 14 対策
15. © MGRe, Inc. All Rights Reserved. 15 • 古いデータの削除、非公開化 ◦ インデックスの見直しも含め、取得レコード数を減らすのが最も効果的 • Aurora Serverless v2 への移行 ◦ 細かく素早い ACU（容量）変更 ▪ 0.5単位、v1 は8→16→32のように2の累乗単位 ◦ 適切な ACU 選択によるコストメリット、マルチ AZ 対応等 v1 から比べ て多くの利点 ◦ v1 はインスタンス1つのみ、v2 は Aurora と同じライター／リーダーク ラスター方式 ◦ v1 からの進化というより Aurora をサーバーレスにした感じ パフォーマンスの対策
16. © MGRe, Inc. All Rights Reserved. 16 • テナント領域のアップデートの自動化 ◦ PR 後各テナントのリポジトリにおいてコミット→ PR までの自 動化、スタンダードプランにおいてはマージ〜自動デプロイまで の仕組みづくり 運用面の課題
17. © MGRe, Inc. All Rights Reserved. 17 • QA（テスト）含むリリース体制の整備 ◦ 項目書を作り計画立てたテストに • 手軽に行える負荷テスト ◦ k6 一番の課題 • MAU が大きいテナントの分離 ◦ 別の DB インスタンスを用意する
18. © MGRe, Inc. All Rights Reserved. 18 まとめ
19. © MGRe, Inc. All Rights Reserved. 19 まとめ • Aurora Serverless v2 はいいぞ • QA さんありがとう