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
売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 / JJUG CCC 2...
Search
west-c
May 18, 2019
Programming
2
3.1k
売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 / JJUG CCC 2019 Spring
west-c
May 18, 2019
Tweet
Share
More Decks by west-c
See All by west-c
大規模案件における手戻りを防ぐ要件定義・開発事例 / 2022-11-09 RAKUS Meetup
westc
0
1.1k
ローンチ1年目プロダクトのテストコード事情 / 2021-08-25 devtestlt
westc
0
140
はじめてのフロントエンド・バックエンド分離 / 2020-08-25 RAKUS Meetup
westc
3
2.6k
Other Decks in Programming
See All in Programming
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
1k
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
260
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
170
From the Wild into the Clouds - Laravel Meetup Talk
neverything
0
150
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
990
未経験でSRE、はじめました! 組織を支える役割と軌跡
curekoshimizu
1
150
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
900
Open source software: how to live long and go far
gaelvaroquaux
0
660
SwiftUI Viewの責務分離
elmetal
PRO
2
270
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
210
複数のAWSアカウントから横断で 利用する Lambda Authorizer の作り方
tc3jp
0
120
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
8
2.4k
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Writing Fast Ruby
sferik
628
61k
Fireside Chat
paigeccino
34
3.2k
Code Reviewing Like a Champion
maltzj
521
39k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
The Cult of Friendly URLs
andyhume
78
6.2k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
990
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Transcript
売れてる SaaS への オブジェクトストレージ導入に まつわる泥臭い話 株式会社ラクス 西角 知佳 JJUG CCC
2019 Spring 1
自己紹介 • 西角 知佳 • 所属:株式会社ラクス • 2015年に新卒入社(入社5年目) • 経費精算クラウドサービス
の機能開発を担当 2
本日の内容 • 「売れてる SaaS」へのオブジェクトストレージ導入 の背景 • 導入時に気を付けたこと • 導入後に発生したトラブル •
導入による効果 3
「売れてる SaaS」への オブジェクトストレージ導入の 背景 4
の概要 交通費・経費など、お金にかかわる全ての処理を 一元管理できるクラウド型の経費精算システム • 2009年サービス開始 • SaaS型経費精算システムで導入社数第1位 ※:ITR「ITR Market View:予算・経費・就業管理市場2018」SaaS型経費精算市場:
累計導入社数ランキング(初期出荷から2017年12月末までの累計導入社数) 5
• 累計導入社数 4,382社(2019年3月末) • 2018年度の新規受注 1,355社 の概要 6 17 44
107 229 417 760 1,236 1,957 3,027 4,382 2 0 1 0 年 3 月末 2 0 1 1 年 3 月末 2 0 1 2 年 3 月末 2 0 1 3 年 3 月末 2 0 1 4 年 3 月末 2 0 1 5 年 3 月末 2 0 1 6 年 3 月末 2 0 1 7 年 3 月末 2 0 1 8 年 3 月末 2 0 1 9 年 3 月末 累計導入社数の推移(単位:社)
楽楽精算が抱えていた課題 伝票に証票(領収書)ファイルを添付できる ファイルデータは DB 内にバイナリ型で保持 7 経費精算書 id file_name file
1 hoge.pdf … … … アップロード 申請者 データベース 証票 hoge.pdf
楽楽精算が抱えていた課題 ファイルデータのサイズ増加量が年々加速 8 0 50 100 150 200 250 300
2010 2011 2012 2013 2014 2015 2016 ファイルデータのサイズ増加量(単位:GB)
楽楽精算が抱えていた課題 DB内に保持するファイルデータ増加による: • DBサーバのディスク枯渇の懸念 • メンテナンス時間増大の懸念 • DBバックアップ・VACUUM・REINDEX・ANALYZE 9
楽楽精算が抱えていた課題 DB内に保持するファイルデータ増加による: • DBサーバのディスク枯渇の懸念 • メンテナンス時間増大の懸念 • DBバックアップ・VACUUM・REINDEX・ANALYZE 10 これ以上ディスクの
増設ができない……
楽楽精算が抱えていた課題 DB内に保持するファイルデータ増加による: • DBサーバのディスク枯渇の懸念 • メンテナンス時間増大の懸念 • DBバックアップ・VACUUM・REINDEX・ANALYZE 11 これ以上ディスクの
増設ができない…… メンテナンス時間が 24時間を超えそう……
楽楽精算が抱えていた課題 DB内に保持するファイルデータ増加による: • DBサーバのディスク枯渇の懸念 • メンテナンス時間増大の懸念 • DBバックアップ・VACUUM・REINDEX・ANALYZE 外部ストレージへのファイルデータの移行を決定 12
メンテナンス時間が 24時間を超えそう…… これ以上ディスクの 増設ができない……
導入による効果 13
導入後のDBサーバのディスク使用量 • 2TB 以上のファイルデータを移行 • データ量が最大のサーバで270GB → 27GB(約90%減) 14 外部ストレージに分離後、
DBよりファイルデータを削除
• データ量が最大のサーバで約 90% のメンテナンス時間短縮 導入後のメンテナンス時間 15 導入前の 所要時間(h) 導入後の 所要時間(h)
DBバックアップ 7.00 0.75 VACUUM 3.50 0.25 REINDEX 1.00 0.25 ANALYZE 1.50 0.25 合計 13.00 1.5 約90%減
ストレージ選定 16
クラウドかオンプレか • クラウドストレージ(e.g. Amazon S3) • オンプレミスストレージ 17
クラウドかオンプレか • クラウドストレージ(e.g. Amazon S3) • 外部サービス利用による顧客心象の懸念 • オンプレミスストレージ •
クラウドよりもコスト増 コスト増は許容範囲内のためオンプレミスの方針で決定 18
製品選定 ファイルストレージ・オブジェクトストレージ含めベンダ選定 • コスト • 容量制限 • ベンダロックインが発生しうる技術の有無 • etc
19
製品選定 オブジェクトストレージ CLOUDIAN HyperStore を選定 • コストが低くスモールスタートで開始可能 • サーバ増設により無制限に容量追加が可能 •
Amazon S3 のインターフェースと互換 20
オブジェクトストレージ導入時に 気を付けたこと 21
導入時に気を付けたこと 22 データ移行による影響洗い出し 安全確実にデータ移行する方法
導入時に気を付けたこと 23 データ移行による影響洗い出し 安全確実にデータ移行する方法
楽楽精算の技術スタック • 使用言語:Java • データベース:PostgreSQL • オブジェクトストレージ操作ライブラリ: AWS SDK for
Java ←New! 24
アーキテクチャ 方針:データ構成は大きく変えずデータ参照先を切り替える • DAOでオブジェクトストレージへのアクセスを吸収する • オブジェクトキー・ファイル名等の情報はDBに格納 25
id file_name file 1 hoge.pdf … … 26 26 クライアント
データベース Controller file_name = hoge.pdf file = Before DAO DTO
27 27 id file_name object_key file 1 hoge.pdf 00123 …
… クライアント データベース オブジェクトストレージ Controller file_name = hoge.pdf file = After DAO DTO 00123
28 28 id file_name object_key file 1 hoge.pdf 00123 …
… クライアント データベース オブジェクトストレージ Controller file_name = hoge.pdf file = After DAO DTO DTOの中身は 変わらない 00123
DBからの移行で考えるべきこと DB内の情報とオブジェクトストレージ内のファイルデータの 整合性が崩れる可能性がある • DB上に存在しないデータがオブジェクトストレージ上に存 在する(浮いた状態) • DB上に存在するデータがオブジェクトストレージ上に存在 しない(参照が切れた状態) 29
DBからの移行で考えるべきこと DB内の情報とオブジェクトストレージ内のファイルデータの 整合性が崩れる可能性がある • DB上に存在しないデータがオブジェクトストレージ上に存 在する(浮いた状態) • DB上に存在するデータがオブジェクトストレージ上に存在 しない(参照が切れた状態) 30
既存の設計 31 データベース id file_name file 1 hoge.pdf id file_name
file ユーザ 削除操作 物理削除
32 データベース オブジェクトストレージ id file_name object_key 1 hoge.pdf 00001 id
file_name object_key ユーザ 既存に倣った設計で 外部ストレージ導入 削除操作 物理削除 物理削除
33 データベース オブジェクトストレージ id file_name object_key 1 hoge.pdf 00001 id
file_name object_key 1 hoge.pdf 00001 ロールバック id file_name object_key ユーザ 削除操作 参照先が 存在しない 物理削除 物理削除 既存に倣った設計で 外部ストレージ導入
採用した設計 34 データベース オブジェクトストレージ id file_name object_key 1 hoge.pdf 00001
id file_name object_key 1 hoge.pdf 00001 ユーザ 削除操作 論理削除 物理削除 物理削除 id file_name object_key バッチ 削除処理
35 データベース オブジェクトストレージ id file_name object_key 1 hoge.pdf 00001 id
file_name object_key 1 hoge.pdf 00001 ロールバック id file_name object_key 1 hoge.pdf 00001 ユーザ 削除操作 論理削除 採用した設計
導入時に気を付けたこと 36 データ移行による影響洗い出し 安全確実にデータ移行する方法
どのように移行するか 移行対象のファイルデータ合計は 2TB 以上 メンテナンス時間での一括データ移行は作業時間的に厳しい オブジェクトストレージ導入後にバッチで徐々に移行する • 移行完了したファイルはオブジェクトストレージを参照 • 未移行のファイルはデータベースを参照
37
どのくらい移行するか 移行過渡期はなるべく短期間にしたい • 20日で移行完了目標 実際のデータ量を調査し移行頻度・件数を調整 10分に1回移行バッチを起動 移行バッチ1回につき各テナント75件を移行 38
安全にデータを移行するために 移行完了後しばらくはファイルデータをDBと二重管理 • オブジェクトストレージの運用に慣れるまでは予期せぬト ラブルが発生する可能性が高い • 予期せぬトラブルによりお客様のファイルデータが消失し てしまう事態を避ける DBのファイルデータは次バージョンリリース時に削除 39
導入後に発生したトラブル 40
DBサーバのディスク容量枯渇危機 • データ移行時、DB内のオブジェクトキー情報を 更新するためレコードをUPDATE • カラム内にはファイルデータも存在する 41 id file_name object_key
file 1 hoge.pdf 00123 … … データベース オブジェクトストレージ PUT UPDATE オブジェクトキーのみ更新 移行バッチ
DBサーバのディスク容量枯渇危機 • アーカイブログが大量に出力されディスク容量が逼迫 • O/Rマッパーで全カラムUPDATEしていたため、ファイル データに対する更新も行われた 42 id file_name object_key
file 1 hoge.pdf 00123 … … データベース オブジェクトストレージ PUT UPDATE 全カラムをUPDATEしていた 移行バッチ
DBサーバのディスク容量枯渇危機 • 一時的にアーカイブログを手で削除することに…… ダミーデータを本番相当数用意して検証を行うべきだった 43
再掲:導入による効果 44
楽楽精算が抱えていた課題 DB内に保持するファイルデータ増加による: • DBサーバのディスク枯渇の懸念 • メンテナンス時間増大の懸念 • DBバックアップ・VACUUM・REINDEX・ANALYZE 45
DBサーバのディスク枯渇の懸念 • 2TB 以上のファイルデータを移行 • データ量が最大のサーバで270GB → 27GB(約90%減) 46 外部ストレージに分離後、
DBよりファイルデータを削除
• データ量が最大のサーバで約 90% のメンテナンス時間短縮 メンテナンス時間増大の懸念 47 導入前の 所要時間(h) 導入後の 所要時間(h)
DBバックアップ 7.00 0.75 VACUUM 3.50 0.25 REINDEX 1.00 0.25 ANALYZE 1.50 0.25 合計 13.00 1.5 約90%減
まとめ 48
まとめ オブジェクトストレージ導入により楽楽精算が抱えていた 課題を解消することができた 導入時に意識する点: • DBとオブジェクトストレージとの整合性 • データ移行の方法・頻度 • データサイズが大きいレコード更新に伴う影響
• 必要に応じて本番を想定した検証の実施 49
ご清聴ありがとうございました 50