最近読んだもの 40 - Vitess 導入事例、CloudSQL Insights など
- Scaling Datastores at Slack with Vitess - Slack Engineering
- Slack の Vitess 導入事例
- MySQL の既存の資産を活かしながらプロダクト開発の速度を落とさずにスケールさせるには、やはり NewSQL への移行よりもこうしたソリューションの方が現実的なんだなと思った
- Square | Cloud Native Computing Foundation
- Square の Vitess 導入事例
Only 5% of the system had to be changedいい数字- こういう企業たちが upstream に還元してくれているのがとても心強い
- Partitioning GitHub’s relational databases to handle scale | The GitHub Blog
- 前にも読んだことがあったけれど、データの cutover の部分を再読
- テーブルを分割する際に別クラスタにダウンタイムなしででーたを移動させるプロセス
- Vitess を利用する方式と、導入して間もないときは独自のスクリプトでの移行も行ったらしい
- 後者は primary を一度リードオンリーにし、レプリカへのレプリケーション完了を確認し、レプリカをマスターにプロモートし、SQLProxy の向き先を変更するというもの
- github の規模でもオフピークに実施すれば十分少ないエラーで切り替えられれたらしい
- primary で 50,000 queries/s くらい？
- MySQL database performance monitoring | Google Cloud Blog
- CloudSQL insights が MySQL にも来るらしい
- 早速申し込んだ
- Selecting a Startup Stack for Scale
- ポジショントークぽい部分もありつつ、スタートアップにおけるスケール対応のタイミングとして、実際に問題になってからやるといいというのは割と聞く話かなと思うけど、理想的には問題になる前に必要十分な時間をとって対応した方が良いと言っているのは、確かにその通りだなと思った
- 技術選定に関しても、現状のコードベースへの変更が小さく、将来の拡張性を損なわす、学習コストが高すぎず、採用コストが高すぎないものが（あくまで理想だが）良いので、そこを出来るだけ目指すべきというのも、判断軸の整理になって良かった
- GitHub Availability Report: March 2022 | The GitHub Blog
- mysql1 の負荷対応を引き続き地道にやっているらしい
- 今回は actions のテーブルを functional sharding しているらしい
- また特定の機能にメンテナンスウィンドウを設けて、高負荷時に止めたりしていたらしい
- ユーザーとしては気づかなかった
- Understanding Software Dynamics 9 章まで
- observability の章に突入
- ログの出し方やサマリーの仕方など、納得感がある
