PlanetScale さわってみた

Transcript

1. PlanetScale さわってみた 小黒 陽弘
2. 今日はなすこと • PlanetScale について ◦ PlanetScale とは ◦ すごいところ • 実際に使ってみる ◦ PlanetScaleの管理画面からテーブルを作る ◦ 普通の読み書きを試す ◦ レプリケーションを試す ◦ 同時接続1000を試す ◦ オートスケールを試す ◦ スキーマチェンジを試す • まとめ
3. PlanetScaleについて
4. PlanetScaleとは？？ • スケーラブルなフルマネージドDB ◦ MySQLと同じように使える • Webサービスを運用する上でエンジニアが血反吐を吐きながら対応してた作業を いろいろよしなにやってくれる革新的なサービス • 2021年末ごろに120億円調達してぶち上げてくぞ！！ってタイミング • めっちゃ太っ腹なので無料枠が超充実してて無料のデータベースとして個人開発で もガンガン使える状態
5. すごいところ • ① ノンブロッキングスキーマ変更 • ② シャーディング • ③ ブランチ運用
6. すごいところ① - ノンブロッキングスキーマ変更 • 普通のMySQLでは、レコード数の多いテーブルのスキーマ変更は時間がかかる上 に、テーブルロックがかかるので（厳密にはアルゴリズムによる）、レコード数の多い テーブルのスキーマ変更はかなり大変 • 小黒は過去下図のようにして実現していた 2. カラム変更した同じ構成のテー ブルを作ってデータをコピーしてい く 3. カラム変更したテーブルを 切り替え（rename） new_table old_table 1. Webサービスをメンテ状態 へ new_table old_table 4. メンテ解除 old_table new_table
7. すごいところ① - ノンブロッキングスキーマ変更 • PlanetScaleは面倒な作業なしでスキーマ変更が可能！！ ◦ しかもサービスはとめずにやってくれる（ノンブロッキング！！） ◦ 内部的には書き換え中に old_table に飛んできたクエリも全てコピーし、 old_table と new_table で 差分がなくなった時に切り替えるらしい。すごい 1. カラム変更した同じ構成のテー ブルを作ってデータをコピーしてい く 2. カラム変更したテーブルを 切り替え（rename） new_table old_table new_table old_table
8. すごいところ② - シャーディング • MySQLなどでシャーディングする場合、どこのデータベースにデータをとるかアプリ 側で都度確認しなきゃいけない common 1. user_id: 1 の情報が格納され てるDBを教えて〜 2. user_id: 1 の情報が格納され ているのは shard3 です！ 3. user_id: 1 の情報をくれ〜 shard1 shard2 shard3 アプリケーション
9. すごいところ② - シャーディング • PlanetScaleが全部やってくれる！！！ • シャード用の処理をわざわざ実装しなくてOK 1. user_id: 1 の情報をくれ〜 user_id: 1 は shard3 に問い合 わせればOK shard1 shard2 shard3 アプリケーション
10. すごいところ③ - ブランチ運用 • PlanetScaleではデータベースの状態をブランチで管理している user_id: 1, name: hoge user_id: 2, name: fuga … main
11. すごいところ③ - ブランチ運用 • 任意の状態からブランチを切ってデータベースをコピーできる！！ user_id: 1, name: hoge user_id: 2, name: fuga … main dev user_id: 1, name: hoge user_id: 2, name: fuga …
12. すごいところ③ - ブランチ運用 • つまり..本番のデータベースをコピーしてさくっとテストできる！ ◦ バッチのテスト ◦ マイグレーションのテスト ◦ … user_id: 1, name: hoge user_id: 2, name: fuga … main dev user_id: 1, name: hoge user_id: 2, name: fuga …
13. すごいところ③ - ブランチ運用 • ただしデータまでコピーしてくれるのはTeamプラン(600$/月)から... user_id: 1, name: hoge user_id: 2, name: fuga … main dev user_id: 1, name: hoge user_id: 2, name: fuga …
14. 実際に使ってみる
15. 実際にためしてみたこと • PlanetScaleの管理画面からテーブルを作る • 普通の読み書きを試す • レプリケーションを試す • 同時接続1000を試す • オートスケールを試す • スキーマチェンジを試す
16. PlanetScaleの管理画面からテーブルを作る • PlanetScaleは管理画面が充実していて、各種操作をWebUIベースで行うことが できる ◦ CLIもあるのでどちらからでも操作可能 • 次スライド以降ではUI上でテーブルを作る様子を順に追っていく
17. PlanetScaleの管理画面からテーブルを作る • ログイン後の画面で New database を選択してデータベースを作れる
18. PlanetScaleの管理画面からテーブルを作る • aws の region 指定して db インスタンス作れる。無料なのにすごい • スペックの指定はなかったので、課金してもパワーアップするとかはなさそう
19. PlanetScaleの管理画面からテーブルを作る • データベースはすぐできる。ダッシュボードのConnect をクリックすると接続情報 が出てくるので、それ使ってあとはMySQLと同じようにたたけばOK ◦ フレームワークでよく使う設定形式に合わせて接続情報を出力してれて優しい
20. PlanetScaleの管理画面からテーブルを作る • 管理画面上のConsoleから create table を流せる ◦ CLI経由でも流せるし、直接繋いで流すこともできる • 今回はこんなテーブルを検証用に作ってみた
21. 普通の読み書きを試す • めっちゃシンプルな読み書きの構成でテストして、パフォーマンスを検証してみた ここの時間を計測
22. 普通の読み書きを試す クエリ ミリ秒（１０００回の平均） insert into Tasks (Name) values(?) 16 select * from Tasks where id = ? 12 update Tasks set Name=? where id = ? 17 delete from Tasks where id = ? 17 • 下記のクエリをそれぞれlambda経由で発行した • lambda <-> planetscale の間の通信時間は下記。そこまで遅くはない ※ 1000万レコードが入っているテーブルに対して上記を順に実行した ※ id は PK なのでIndex が貼ってある ※ ハンドシェイクの分は含んでおらずクエリの結果を受け取るまでの時間
23. 普通の読み書きを試す • Index ◦ 先ほどのテーブルに select * from Tasks where Name=? というIndexが貼られていないクエリを試 したが 10sec くらいかかったので普通に Indexの概念は有効そうだった • Transactionの発行 ◦ 問題なく発行でき、rollback/commitが有効だった ◦ ただ Transaction は 20sec しかもたないらしく、バッチ処理などでまとめて commitするとかは厳し そう ▪ そもそもそーゆのが微妙なんだけど、、
24. レプリケーションを試す • レプリカの作成はGUIから行える ◦ ただし１DBあたり１リージョンしか作れないので、 Masterとは違うリージョンに作らなきゃいけな い、、
25. レプリケーションを試す • Masterに対してと同じようにReplicaのパフォーマンスも測ってみた • くそおそかった クエリ ミリ秒（１０００回の平均） select * from Tasks where id = ? 178
26. レプリケーションを試す • PlanetScale ではVitess が中で replica を作ってくれてるのでわざわざread only 用のデータベースを作らなくてもいいのかもしれない、、 ◦ リージョンが別なことを考慮すると、グローバルな Webアプリケーション向けに物理距離が近いデー タベースを用意するために作ってるのかも、、？
27. 同時接続 1000 を試す • しれっと同時接続数が hobby プランでも 1000と書かれている • 本当に耐えられるか試してみた
28. 同時接続 1000 を試す • aws の分散負荷チェックツールを使って検証 • lambdaを使って並列でPlanetScaleにリクエストを投げまくってみた ◦ lambda の同時実行数を1000にしたので理論上は 1000並列になるはず、、？ ◦ lambda の関数はシンプルな select を行うだけのもの
29. 同時接続 1000 を試す • 合計20万のリクエスト５分間投げ続けたが、エラーを返すものはなく、安定して いた ◦ 毎回ハンドシェイクしてるのでレスポンスはめっちゃ遅い。 connection を保持できれば本当 はもっと早くなるはず
30. オートスケールを試す • オートスケールができると価格表に書いて あったので有料プランにしてためしてみた • が...ドキュメントを探しても方法が見つか らず、ひたすらinsertしてもshard は増え ず... • vitess 的にはshardを増やす際には設定 が必要らしいので何か設定が必要なのか も。残念
31. スキーマチェンジを試す • PlanetScaleにはブランチ機能があり、ブランチを切って、そこでスキーマ変更を行 い、マージリクエストを作って main ブランチにマージするというワークフローでス キーマを変更する
32. スキーマチェンジを試す • まずブランチをつくる
33. スキーマチェンジを試す • 作ったブランチでスキーマ変更
34. スキーマチェンジを試す • Deploy Requestを作成する
35. スキーマチェンジを試す • 作られたDeploy Requestを deploy する ◦ githubのPRみたいに差分チェックしてレビューできる！すごい！
36. スキーマチェンジを試す • Deploy完了 ◦ 1000万レコード入ってるテーブルに対しての alterだったがわりとすぐ終わった ◦ deploy中にリクエスト投げてもエラーにはならなかった！！！
37. スキーマチェンジを試す • 障害が起きちゃった時用に Revert 機能もついてる！ ◦ revert の revert はできなかったが、ボタンを押すと数秒で元に戻っていた。すごい
38. まとめ • Good ◦ 簡単に使える ◦ 大量アクセスに強い ◦ オンラインDDL • Bad ◦ やっぱりちょっと高い、、、 ◦ ドキュメントが不足している（オートスケール試したかった〜〜） • 総評 ◦ 負荷分散の仕組みやオンライン DDLなど、未来な感じがするサービスでした ◦ 運用の手間をどこまで削減できるか、をすごく考えてるなーと ◦ スケールした時にお金めっちゃ取られそうなので、商用サービスの本番環境に持ってくるにはちょっ と怖いなあと思いましたが、個人開発であればもはやこれ一択なのでは