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
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
Search
freee
April 11, 2024
Technology
2
1.1k
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
freee
April 11, 2024
Tweet
Share
More Decks by freee
See All by freee
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incorporating the “essence of product development” into organizational development and continuing to face uncertainty
freee
0
91
LGBTQ__support_WOMEN_女性として働くということ_DEI
freee
1
270
QAエンジニア_Summer Internship説明会(26卒)
freee
0
160
権限管理基盤の開発とQAの今 / Authority Management Infrastructure Development and QA Now
freee
1
1.2k
国籍と専門性を超えてのコラボレーション / Collaboration across nationalities and specialties
freee
1
1.2k
デザインリサーチの広げ方 〜XDの姿勢・態度・思考〜 / How to Expand Design Research 〜˜XD's Attitude, Attitude, and Thinking
freee
1
1.2k
グローバルなQAエンジニア・・・ってナニ!? / Global_QA_Engineer..._What_s_that.pdf
freee
1
1.2k
ぶきっちょPMによるfreeeのカルチャーとプロダクトのつながりについて / The Connection Between Freee's Culture and Product by a Clumsy PM
freee
1
1.2k
スモールビジネスを、世界の主役に。 / Empower-Small-Businesses-to-Take-Center-Stage.
freee
1
1.2k
Other Decks in Technology
See All in Technology
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
AWSでRAGを作る法方
sonoda_mj
1
140
Azure OpenAI Service Dev Day / LLMでできる!使える!生成AIエージェント
masahiro_nishimi
3
740
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践
yuriemori
0
190
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
150
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
[NIKKEI Tech Talk] KDDI/KAG Scrum & Community for Engineering Training
curanosuke
2
220
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
Github Actions 로 Android 팀의 효율성 극대화
hadonghyun
0
160
Featured
See All Featured
Designing the Hi-DPI Web
ddemaree
276
34k
How to name files
jennybc
67
96k
Thoughts on Productivity
jonyablonski
64
4.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
Why Our Code Smells
bkeepers
PRO
332
56k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
16
1.6k
Fireside Chat
paigeccino
25
2.8k
Designing for Performance
lara
604
67k
Building Flexible Design Systems
yeseniaperezcruz
323
37k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
We Have a Design System, Now What?
morganepeng
46
7k
Transcript
巨大なテーブルのテーブル定義を無停止で安全に 誰でも変更できるようにする 2024.04.08
2 • freeeのエンジニア • 2023/3までfreeeでDBREのチー ムリーダーをやっていました。 • その後転職の後2024/1からfreee に出戻り
• 最近はプロダクト横断で利⽤す る基盤システムを作っています • 最近はDB系の論⽂を読む会を主 催しています shallow1729
3 テーブル定義の変更の重要性と課題 • WEB開発においてはサービスの開発後に新しい要件に合うようにカラムやインデッ クスの追加、変更が必要になるケースがある • 頻繁にDDLを行いたいが以下のように無停止でのDDLには危険性がある ◦ DDLの実行はテーブルのサイズや行いたい変更の種類によっては実施が困難
▪ 数十億レコードのテーブルのインデックスの追加 ▪ カラムのデータ型の変更などのOnline DDLできないもの • ドキュメントのPermits Concurrent DMLを確認 ◦ DDLの負荷が問題になるケースがあるがコントロールしづらい ◦ アクセスの多いサービスでのDDLではメタデータロックのケアが必要(後述) DDLを無停止で頻繁に行いたいユースケースがあるがMySQLの標準の仕組みは 要件に合わない
4 メタデータロックの動作 • MySQLはInnoDBなどのストレージエンジンで取る行ロックなどとは別にエンジンの レイヤーで取るメタデータロックというやつがいる • クエリやDML時はshared、DDLの実行時はexclusiveにロックを取る • メタデータロックはトランザクションの終了時に手放される •
exclusive lockはshared lockを待つ必要があり、exclusive lockが待っていると後続 の処理はshared lockを取れない DDLの対象テーブルに対してロングトランザクションがあるとDDLが実行できず、 後続のクエリも待たされる
5 メタデータロックの競合のイメージ ロングトランザクションのある状況でDDLを実行するのは危険
6 メタデータロックの問題の回避策 • lock_wait_timeoutというMySQLのパラメーターでメタデータロックの取得待ちのタイ ムアウトを決められるので、これが小さいとロック待ちで詰まることを回避できる • freeeではDDLを実行するセッションのみlock_wait_timeoutを小さくすることで既存の ワークロードへの影響を最小限にOnline DDLの安全性を高めている •
しかし、メタデータロックは一般にDDLの開始時と終了時の二度取るタイミングがあ り、終了時にタイムアウトが発生すると最初からやり直しになる...
7 MySQLのOnline DDLの課題のまとめ • MySQLの通常のOnline DDLでは以下のケースで課題がある ◦ データ量の多いテーブルのインデックス追加やデータ型の変更などOnline DDLを利用できないケー スがある
◦ DDLの負荷自体がワークロードに影響を与えるリスクがあるがコントロールが難しい ◦ メタデータロックの問題があり、ロングトランザクションがあるワークロードでのOnline DDLはリスク がある ▪ lock_wait_timeoutを小さくすることで影響は減らせるがDDLが失敗するリスクが上がる
8 一般的な代替案 • メンテナンスを実施してDDLを実行 • レプリカでDDLを実行した後にレプリカをプライマリーに昇格する • pt-online-schema-change(ptosc)などのDDLを実行するためのツールの利用
9 レプリカでDDLを実行して切り替える • インフラ作業やMySQLの標準の機能(レプリケーションやDDL)で済むので実装は不要 • インフラの理解や権限が必要でプロダクトチームに任せづらく、スケールしない • プライマリーへの昇格時に接続先を変更するために許容できない停止時間が発生する
10 ptoscの動作 • ソフトウェアの処理で完結するのでインフラよりはプロダクトチームに権限を渡しやすい • パラメーターで負荷の調整が可能で切り替え時の停止時間も小さい • 利用経験のある人が少なく、学習コストがかかりそうなのでスケーラビリティの問題がある
• 通常のDDLより時間がかかる上、メタデータロックを取るステップが最後にあり、メタデータロックの取得に 失敗する可能性のケアが必要
11 freeeでの解決策 • ptoscをRDS/Auroraに対して実行するECS taskを呼び出すAWS Step Functionsを 用意 • AWS
Step Functionsの定義はTerraformで管理し、ptoscに関するTerraformの変更 やStep Functionsの実行権限、実行ログの閲覧権限などを各プロダクトチームに付 与 ◦ TerraformはGitHubで管理されており、prに実行したいDDLを書いてマージするとStep Functionsに その情報が反映される • ptoscをそのまま使うのではなく、設定や手順などについてDBREのベストプラクティ スが反映している
12 freeeでの解決策の図
13 ptoscの実行に関する工夫 • メタデータロックのケア ◦ lock_wait_timeoutを短くする ◦ ptoscの最後のスワップは行わずに実行し、別タスクでswapを行う(--no-swap-tables)
▪ スワップの失敗時にリトライできるようにするため+後述の事前チェックのため • ptoscの実施によるワークロードへの影響のケア ◦ chunk sizeなどのパラメーターの調整 ◦ max loadなどのptoscに備え付けの高負荷を検知して処理を止める仕組みの利用 ▪ 使っていないがRDSのcpu使用率を見て止めるパッチを作ったりもした • ptoscが正しく実施できたかの事前チェック ◦ テーブルのレコードをちょっとずつ比較して差分が無いかを確認 • その他失敗時の掃除なども含めてジョブを用意してプロダクトチームに提供
14 ptoscの導入の効果 • int32のauto incrementのカラムが一杯になりかけていたテーブルについてデータ型 をbigint化する事を無停止で実現 • 負荷の調整によりアクセスの多い時期でも安全にDDLを実現。DDLのためにメンテ を行わなくてもよくなる。 •
大半のオペレーションが自動化され、権限がプロダクトチームにあるので各チーム で実行が可能になり作業のスケーリングを実現 • ptosc実行中のレプリケーション遅延などの問題もAurora MySQLの場合独自のレ プリケーションの仕組みでほとんど起きなかった
15 まとめ • freeeではサービスの継続的な成長を支えるための独自のDDLの仕組みを用意し、 プロダクトチームに提供している • 無停止で: ptoscにより数十億レコードのテーブルのデータ型の変更のようなOnline DDLが使えないケースも対応する •
安全に: DBREのベストプラクティスを自動化処理の実装に落とし込む • 誰でも: プロダクトチームにタスクの実行権限を渡す事でツールの学習コストを抑 え、プロダクトチーム主体で難易度の高いDDLも必要なタイミングで各自で実現で きるようにする
16 技術的な詳細を知りたい方は • pt-online-schema-changeの導入時に検討したこと、およびRailsアプリとの併用に ついて • AWSマネージドサービス+Terraformを活用してDBオペレーションをより安全&簡単 に(pt-oscの例)
スモールビジネスを、世界の主役に。