Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ここがつらいよマルチテナント
Search
メグリ株式会社
October 26, 2022
Technology
0
740
ここがつらいよマルチテナント
2022/10/13に実施したイベント「最近チャレンジしたことをまとめてみた」で利用した資料
https://mgre.connpass.com/event/260781/
メグリ株式会社
October 26, 2022
Tweet
Share
More Decks by メグリ株式会社
See All by メグリ株式会社
株式会社MGRe会社紹介資料(2025年4月更新)
saiyou_mgre
0
3k
メグリ株式会社_メグリコンパス.pdf
saiyou_mgre
1
790
アップロードキーに苦戦した話 🤯
saiyou_mgre
0
2.4k
メグリ株式会社_エンジニア向け会社紹介資料
saiyou_mgre
1
21k
メグリ株式会社
saiyou_mgre
1
23k
Other Decks in Technology
See All in Technology
DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025
nologyance
1
380
バッチ処理で悩むバックエンドエンジニアに捧げるAWS Glue入門
diggymo
3
200
テストを軸にした生き残り術
kworkdev
PRO
0
200
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
130
Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform
pei0804
1
170
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
240
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.2k
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
210
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
170
S3アクセス制御の設計ポイント
tommy0124
3
190
生成AIでセキュリティ運用を効率化する話
sakaitakeshi
0
630
Featured
See All Featured
For a Future-Friendly Web
brad_frost
180
9.9k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Navigating Team Friction
lara
189
15k
RailsConf 2023
tenderlove
30
1.2k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
A designer walks into a library…
pauljervisheath
207
24k
Done Done
chrislema
185
16k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Facilitating Awesome Meetings
lara
55
6.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Transcript
ここがつらいよマルチテナント © MGRe, Inc. 2022.10.13 メグリ株式会社 プロダクト部サーバーサイドエンジニア 蔵下 正治
© MGRe, Inc. All Rights Reserved. 2 本日のお題 マルチテナント向けSaaS開発時の経緯とマルチテナントのつらみとその対策につ いて
© MGRe, Inc. All Rights Reserved. 3 Index 01. 本日のお題
02. MGReについて 03. MGReの歴史 04. 過去のサービスとの比較 05. マルチテナントにしてつらかった点 06. 対策 07. まとめ
© MGRe, Inc. All Rights Reserved. 4 MGReについて
© MGRe, Inc. All Rights Reserved. 5 MGReについて • マルチテナント向けのSaaS
• ニュース、お知らせ、クーポン、店舗検索、プッシュ通知、アイテム 等 + 会員証の基本機能 • 様々なECや会員基盤システムと連携が可能 χϡʔε Ϋʔϙϯ ΞΠςϜ ళฮ ձһূ
© MGRe, Inc. All Rights Reserved. 6 MGReについて
© MGRe, Inc. All Rights Reserved. 7 過去のサービスとの比較 डୗ࣌ ڥ
γϯάϧςφϯτ γϯάϧςφϯτ Ϛϧνςφϯτ ࣮ํ๏ ϑϧεΫϥον ύοέʔδʢϕʔείʔυ͔ΒΓ ग़͠ ΧελϚΠζʣ 4BB4 ΧελϜྖҬ αʔόʔʢ"84ʣ &$ ".* &MBTUJD#FBOTUBML ʢϚωʔδυ&$ʣ 'BSHBUFʢίϯςφʣ σʔλϕʔε 3%4NZTRM "VSPSB "VSPSB4FSWFSMFTT Πϯϑϥཧ $MPVE'PSNBUJPO εΫϦϓτ $MPVE'PSNBUJPO σϓϩΠ $PEF1JQFMJOF $PEF1JQFMJOF &$3 ϩάɾσʔλऩू $MPVE8BUDI $MPVE8BUDI ,JOFTJT 'JSFIPTF
© MGRe, Inc. All Rights Reserved. 8 マルチテナントにしてつらかった点
© MGRe, Inc. All Rights Reserved. 9 マルチテナントにしてつらかった点 • パフォーマンスの課題
◦ DB(Aurora Serverless)の性能限界が見えてる ◦ WAF 等 AWS のリソース上限 • 運用の課題 ◦ テナント領域のアップデートが手間 ◦ テナントが混ざる • 一番の課題 ◦ やらかすと被害が大きい
© MGRe, Inc. All Rights Reserved. 10 • DB(Aurora Serverless)の限界
◦ コンテナ(API)はいくらでも増やせる ◦ プッシュ配信時のスパイクアクセス ◦ MGRe のセグメント配信は仕様上キャッシュが難しい ◦ 通勤時(9時台)やスーパー等の小売はお昼過ぎ(12〜13時台)と夕方 (17時以降) パフォーマンスの課題 データベース容量(ACU) CPU使用率
© MGRe, Inc. All Rights Reserved. 11 • WAF 等
AWS のリソース上限 ◦ route53 でテナントごとにドメインを用意 → 上限500程度 ◦ テナントごとにロードバランサを用意 → 上限100程度 ◦ WAF による管理画面用 API の IP 制限 → 正規表現のため最大文字数 の制限 ◦ Aurora Serverless のさばける上限 → 上限 ACU 256(メモリ 488GB) パフォーマンスの課題
© MGRe, Inc. All Rights Reserved. 12 • テナント領域のアップデートが手間 ◦
テナント毎に異なる認証処理を吸収 ◦ mgre-auth という gem を用意 ◦ ある程度共通化はされているものの数が多い • テナントが混ざる 運用面の課題
© MGRe, Inc. All Rights Reserved. 13 • やらかすと被害が大きい ◦
あるテナントのユーザー数とニュースのレコード数が増加 ◦ それによりセグメント検索 API のパフォーマンスが低下 ◦ リクエストがつまり始める ◦ リクエストがつまっているためコンテナが新しく立ち上がり続ける ◦ コンテナ起動時に DockerHub からあるイメージをプルしていた ◦ 短時間にプルし過ぎたためレート制限 ◦ イメージをプル出来ずコンテナ起動失敗 ◦ 生きているコンテナも次々死ぬ ◦ コンテナがいなくなり全てのテナントでサービス停止😭 一番の課題
© MGRe, Inc. All Rights Reserved. 14 対策
© 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 をサーバーレスにした感じ パフォーマンスの対策
© MGRe, Inc. All Rights Reserved. 16 • テナント領域のアップデートの自動化 ◦
PR 後各テナントのリポジトリにおいてコミット→ PR までの自 動化、スタンダードプランにおいてはマージ〜自動デプロイまで の仕組みづくり 運用面の課題
© MGRe, Inc. All Rights Reserved. 17 • QA(テスト)含むリリース体制の整備 ◦
項目書を作り計画立てたテストに • 手軽に行える負荷テスト ◦ k6 一番の課題 • MAU が大きいテナントの分離 ◦ 別の DB インスタンスを用意する
© MGRe, Inc. All Rights Reserved. 18 まとめ
© MGRe, Inc. All Rights Reserved. 19 まとめ • Aurora
Serverless v2 はいいぞ • QA さんありがとう