データベース改善プロジェクトの背景
まあ、ダックリ言うとデータが増えてきて、サービスの運用にとか、将来のミッションとして掲げているところの数値みたいなところを覆うと思ったら、このままだといかんよな、みたいな経緯があったりするかね。
あれ、これもうまく編集してくれる感じなの?
そうですそうです。
おお、すごい、天才や。
まあ、ダックリそんな感じのところで、プロジェクトの背景とか、DBのソリューションとしてはこういうアイデアがあるよねっていうことと、
今、それに向けてデータのクレンジングとかやってますよ、みたいな話でいいのかな。
フレッグがめっちゃ苦労してくれたところとか。
それじゃあ、TimeTreeTechTalk始めていきたいと思います。
今日は、TimeTreeの裏側をまさに支えているデータベースの話をしたいなと思いまして、
2人のゲスト、ミウとグレックをお呼びしました。
それぞれ簡単に自己紹介していただけますかね。
じゃあ、ミウ、どうぞ。
はい、ミウです。よろしくお願いします。
今は主にSREチームのマネジメントと実装、実行をやってます。
ありがとうございます。
では、続いてグレックお願いします。
はい、グレックと言います。
3年くらい前に、ちょうど3年くらい前に、
TimeTreeに入社して、バックエンドエンジニアとして勤っております。
今は、一応SREチームに所属している。
SREチームとバックエンドチームで勤っている。
バックエンドチームで勤っている。
SREチームに勤っております。
バックエンド、幅広くいろんなことやってますからね。
そういうことですね、すごいですね。
私、スコットもこのチームで、あんまり手は動かせてないんですけど、
過去の経緯とかしてたりするので、その辺の話をしたり、
みたいなことをやってサポートしてたりしますね。
で、そうですね、最近ミウとグレックは主にTimeTreeの
すごいたくさんのデータが入ったデータベースを
いろいろこねこねしてるところだったりするんですけど、
ミウ、このプロジェクトが立ち上がった背景だったり経緯みたいなのって、
あと簡単にどういうことを目指しているのかみたいなことを
話してもらってもいいですか?
はい。ではまず背景からお伝えします。
今はSREなんですけど、もともとはインフラエンジニアとして
ジョインしたんですけど、
そういったメインクラウドAWSを利用してまして、
皆さんご存知かと思うんですけど、
サーバーだったりデータベースだったりっていうのを
メトリクスを眺めながら、日々状況の推移っていうのを確認してました。
おかげさまでTimeTreeのユーザー自体も
順調に進捗していく中で、
今後そのデータベースっていう一つのリソースに対して
物理的なスケールアップ上限っていうのがある中で、
今後上限なくユーザーが増えていった場合に
データベースが破綻するような危機感を
なんとなく持ちながらしていたんですけど、
だんだんサービスがでかくなっていく中で、
サービスとしてアクセルを完全に踏み始める前に
何とかしたいと思いついて、
今年の頭にプロジェクトとして、
最初は自立プロジェクト、
社内にはそういったプログラムがあるんですけど、
社内の自立プロジェクトっていうのを立ち上げて、
本格的に動き出したというのが経緯です。
最初は僕とグレッグとスコットでなんとなく、
本格的といっても最初はちょっとなんとなくやってたんですけど、
いろいろ話を進めていく中で、
データのクレンジングと戦略
どんどんどんどん本格的に動き出していったというところで、
目指すところは3年、5年、10年経っていく中で、
永遠にデータが増えていっても問題なく動くような、
そんな環境をベストな環境として目指していくというのが今の状況です。
はい、そうですよね。
結構データベースの列の数っていうんですかね、
行の数か、
いろいろなことでボトルネックになったりしていて、
その辺が結構将来に向けてすごい足を引っ張りそうだな、
みたいな感じでしたよね。
そうですね。
特にスキーママイグレーションなどを実行する際の
ローカルストレージ周りだったりとかが結構逼迫していくような感じですね。
そうですね。
我々意外と、今70億ぐらいレコードありましたっけ?
予定のレコードとかね。
そういう状態なんですけど、
割と結構オルタテーブルをブンブン回していて、
ゴーストっていうツールを使って、
GitHubの作ってくれたゴーストっていうツールを使って
ブンブン回してるんですけど、
それでもインデックスを追加しようとすると、
クラウド上にあるデータベースのローカルストレージの
テンポラリーの容量を食いつぶしてしまって、
インデックスが作れない、みたいな状態になったりとかするっていうところが
そろそろきついな、みたいな感じですよね。
はい、そうですね。
ただ一点驚いたのは、
これは入社時の時から、
僕5年前に入社して、
今でもすごいなと思うのは、
データベース的には結構ハードな運用してる割には、
クエリとかがシンプルなので、
パフォーマンスが今でも十分出ているってところが
やっぱすごいなっていう、
技術力の高さっていうのをちょっと感じました。
上げてきますね。
割とそうですね、
クエリ周りのワークロードは結構シンプルなので、
そんな複雑なクエリにはかなくてもいいっていうところは、
アプリケーションの設計が良かったのかな、
基本設計が良かったのかな、みたいなところは思いますね。
そうですね。
こんなにユーザー数の多いサービスに関わるのは初めてだったんですけど、
純粋にすごいなって思いました。
こういうボトルネックっていうんですかね、
データベースをいじるときのボトルネックみたいなことだったりっていうのを
考えたときにいろいろソリューションみたいなアイディアは
世の中でいっぱいあると思うんですけど、
こういうことを考えましたみたいなことって話してもらってもいいですか?
グレッグに聞いた方がいいかな?
データベースが、要は大量にデータがあることによって困るみたいな問題ですよね、これはね。
そうですね。
アプリケーション側から見たときとか、
例えば変に思いっくりは発行できないみたいなのがあるかもしれない。
適切にインデックスを設定してあげて、
そのインデックスを使うような状況にしないといけない。
パフォーマンスをちゃんと担保するためのアプローチを模索し続けなきゃいけないとか、
あと結合して処理する、テープル結合して処理するみたいなのはどうしてもコストがかかるので、
そういったものを避けるところとか細かいところもあるかなと思うんですけど、
インデックス追加するっていうのとさっき言ったゴーストを実行しないといけないケースも多くて、
むやみ当たるとインデックスを追加するのも難しい。
むやみ当たるっていうのはよくないんですけど、
気軽にインデックス追加しづらいみたいな問題があって、
逆にその作業を完了するのに数週間かかっちゃうみたいな。
そういったのをどうにかしたいなとなると、
例えばデータが多い場合にはシャーディングみたいな構成とかにデータベースを見直してあげるのがいいのかなとかっていうのが、
最初の出発点だったかなと思います。
シャーディングね、そうなんですよね。
もともとMUが入る前ぐらいなのかな、
予定だけ垂直分割っていうんですかね。
予定と予定につくコメントのデータだけ別のデータベースに入ってたんですよね。
論理的に。
インスタンス的には同じ中に入ってるんですけど、
その辺のコネクション周りがめちゃくちゃ複雑で、
データも少なかったので一回統合したっていう背景があったりするんですけど、
今、グレッグが話してくれたのは垂直というよりかは、
プロキシとKubernetesの運用
いわゆる水平分割ですよね。
同じテーブルをいくつものインスタンスに分けるみたいな話だと思ってて、
例えば、カレンダー1からカレンダー10まではインスタンスA、
カレンダー10から20のデータはインスタンスBみたいなところにデータを入れて、
アプリケーション側でそれを裁くみたいなアイディアかなと思ってて、
僕、前職ソーシャルゲームの会社だったんですけど、
書き込みボトルネックがあったりするのでシャーディングしないといけないみたいなことがあって、
そういう実装したことがあるんですけど、
アプリケーション側でコードを書くのめちゃめちゃきつくて、
泣きそうになりながらコードを書いてます。
特にトランザクション周りがめんどくさくてですね。
なるほど。
その辺の設計っていうんですかね。
要はインスタンスをまたがないようにデータを設計しないといけない。
ゲームだったんですけど、ゲームの要求に合わせて。
なるほど。僕はシャーディングされたアプリケーション開発の経験がなかったので、
その辺の運用というか、実際にした後の開発がどういう風に変わっていくのか、
あまりイメージ持てるってなかった部分もあるんですけど、
共有カレンダーっていう性質上、シャーディングの分割基準みたいなところですかね、
起点化っていうのをちゃんと設計したりとか、
それに合わせたアプリケーションの作りにしなきゃいけないなとかっていうところに
イメージは持ってたりはしていて、
それはそれで結構コールしなければいけないというのがめちゃくちゃ増えて、
シャーディングするのはいいけど、した後の大変そうだなっていうイメージは持ってたんで、
なかなか選択肢として取るべきなのかどうかは結構難しいところだなと。
僕もこの2人と一緒にこういうシャーディングどうするみたいな、
アプリケーションめっちゃしんどいぞみたいな話をしてたときに知ったんですけど、
Vitesっていう、あれ元々YouTubeですかっけ、
YouTubeで使われてるプロキシみたいなやつですね、
シャーディングをサポートしてくれるプロキシみたいなものがあるっていうのを知って、
これならアプリケーション側しんどくないというところで、
いやーいい時代になったなーってすげー思ったんですけど、
MewとかGregとかVitesみたいなものを見たときにどういうことを考えたりしたのか、
今どういうことを考えてるのかって聞いてもいいですか?
僕はですね、これめちゃくちゃ便利だなと、便利そうと思って、
要はアプリケーション側から見たら、そこまでコスト払わないで、
データベースに接続する部分は同じとして考えて使えそうだなと思ったので、
もちろんパフォーマンス、レイテンシーの劣化はあると思うんですけど、
劣化と上昇はあると思うんですけど、
ただアプリケーション側すごい楽になるんで、
これが原理的な回だったらとても使いやすそうだなという感じも持てましたね。
ただ自前で運用するっていう風になったときに、
どういう風にやるのかなってイメージを持ててなかったんで、
ちょっとその辺は確実な部分がすごく多くて、
色々調べたりはしてたという感じですね。
これってVitesseで確かKubernetesで動いてるんですよね?
そうですね、運用するとしたらKubernetesで運用。
プロジェクトの難しさと課題
確かにみんはすごい調べてた気がするけど、
僕らはちゃんとKubernetes運用したことないから、
あれですけど、みんまじでやるんだったらどうなりそうだと思ってました。
嫌だなと思ってました、Kubernetes。
正直運用は結構言っても大変だろうなと思ってましたね。
Kubernetes自体はVitesseだけに限定してしまえば、
そこまで負荷はまず上がらないだろうなと思ってはいたんですけど、
それよりもどっちかっていうと、
マネージメントしてくれるとはいえリシャーディングとかもやっぱ辛そうだよなとかも思ってたし、
あとはシャーディングが増えることに対して、
プロキシ部分のパフォーマンスがどれだけぐらい持つのかなとか、
見えてない部分、
あとは純粋にデータベースサーバーがスケールアウトしていくことによる運用負荷、
どれぐらいいくのかなっていうのはそこそこ怖い印象ですね。
確かにいきなりプロダクション投入ですもんね。
そうなんですよね。
それが本当このプロジェクト自体難しくさせてるっていうか、
いきなり初めて使うテクノロジーを5000万ユーザーにいきなり提供するみたいな難しさがすごいあるなと思ってて。
実際に運用していくところもそうですし、
データ移行の下準備
データ移行するっていうところの課題もたくさんあるので、
その辺は結構難しい。
調べながらもやっぱ難しいなというところは。
データ移行っていう話が出ましたけど、
堀井君はデータ移行いろいろやってるんですよね。
取り組み、データ移行のための下準備みたいなことを延々とやっています。
下準備の話してくださいよ、もう。
基本的に、もともとこのプロジェクトを始まった頃は、
Auroraのバージョン2でMySQLというデータベースの5.7に互換するものを使ったんですけど、
SQLとかを使うってなると、MySQLがバージョン8以降のものなんで、
一回Auroraのバージョンを上げないといけないなっていうところをやったりしていたりとか、
あとはやった上でさらにいくつか文字コードの問題とか残ってたんで、
それを細かく見直して、
理想的な状態に変えていくみたいなところをやるんですけど、
基本的にたくさんのテーブルの影響があるので、
テーブルの移行をやっては失敗し、やっては失敗し、みたいなことをやってました。
そうですね、それこそテーブルの文字コードとコレーションとか変えようとすると、
うまくいかなかったりみたいなのをいっぱいやってましたね。
そうですね、最近やってるのはAurora Blue Green Deploymentっていう機能を使って、
リードクラスターみたいなのを作って、
そっち側にオルタブンで隙間の変更した後に本番とスイッチするっていうようなことができるものがあるんですけど、
それ使ってやっていって、
起きた問題が確か、リードレプリカに流れ込んでくるWindowsのデータ化のタイプのキャスト、型のキャストに失敗する、
文字コードがあるとそこの型のキャストが失敗するっていうケースがあって、
その設定のパラメーターの調整を見落としてたんで、
そこを直したらうまくいったってことなんですけど、
いろいろスキームの違うことによる細かいプラグインとか、
パラメーターチューニングが必要で、またやり直してみるっていう感じで。
データベースの挑戦的な課題
泥臭い話ですね、いい感じですね。
これはここまで一例なので、
また移行の下準備中ではあるので、
何か問題があったときに対応していくっていう感じで、
ちょっとずつデータベースと仲良くなれてきてるかなという気持ちは。
今のいい話でしたね。
文字コードとか、それこそコレーションとかが結構テーブルによってバラバラだったり、
その辺がやっぱりすごい大変だって整理しましたね、
グレイクと一緒にね。
そうですね。
マックスもいたね。
マックスでメンバーに一時期手を貸していたと思っていて。
それこそ簡単なパッとやるだけだったら、
データがちっちゃければすぐ終わるような作業が、
ただただデータが多いというだけで、
すごい課題がめちゃくちゃ難しくなるので。
特に大きいテーブルに対してスキームの変更をするってなったら、
どうしても早くて1週間から2週間ぐらいで動かなきゃいけないので、
失敗したらプラスかかるみたいな感じがあるので。
やってみて失敗しては繰り返していこうと。
プロダクションにも影響を与えないようにみたいなことでやろうとするのが本当に大変なんですよね。
会場で使っているので、
基本的に日本時間の深夜の方はアクセス数としては少ないんですけども、
何かスキーマ変更の実行というか、
本番リリースかな、
みたいなことをするときには、
少なからず本番に影響があることがあるので、
そういう実行のタイミングとかもアクセスを見て考えて、
計画するのもなかなかハードだなと思ったりして。
本当そうなんですよ。
ことをずっと繰り返してるみたいな。
そうそう。
こういうことを楽しめる仲間が増えてくれたらいいなってすごい思いますね。
今の話だけするとだいぶつらい話が多いと思う。
つらいじゃない、チャレンジングな。
チャレンジングな話がすごい多いですから。
ハードなことは学びがとっても多くて、
僕はあんまりデータベースがそんな詳しくない状態で、
このプロジェクトに関わり始めたんですけど、
関わってからは結構ドキュメント読み込んだりとか、
いろいろ試したりとか、
ということを細かくやるようになってきて、
新しく学べることはたくさんあるなと。
なかなか調べて分かるというよりかは、
手を動かさないと分からない領域だったりするので、
そういう意味でいうと本当に勉強になるなと思いますね。
全部難しいんですけど、
今やろうとしていることは本当に難易度が高いことだと思っていますし、
もちろんインフラのSREという視点からも難しいですし、
それだけではないアプリケーションの内部の部分も絡んできますし、
あとは実際に移行しますとなったら、
移行計画だったりユーザーへの影響、
あとはうちAZ広告もやってますけど、
そういったステークホルダーへの影響とか、
いろいろ考えた中での調整だったり、
あとは移行期間中プラスアルファのリソースを利用するので、
そこに対する予算計画とか、
考えることは山ほどあるんですけど、
さっきグレイクもスコットも言ってましたけど、
難易度が高ければ高いほど得るものは大きいですし、
これをやることによって中長期的に見てタイムツリーに対して
メリットが出るのは明白だし、
個人的なスキルアップだったり、
スキルアップにもつながるし、
自己肯定感、満足感というのも得られるでしょうし、
プラスになることの方が圧倒的に多いと思うので、
大変だけど楽しいという感じですね。
なかなかこういう環境ってないと思うので、我々としてはね。
あとやっぱり一つ聞いてる人に伝えたいのは、
最初に言ったんですけど、
最初本当に危機意識だけ持ってたものが、
個人の動きによって会社が危機感を認識して、
プロジェクトとして本格的に今動いているという状況も
会社として素晴らしいなと。
そうですね。会社のミッションから考えた時に、
今のうちにこれを手を取っておかないといけないって
ミウが声を挙げてくれたことが、
実際プロジェクトとしてチームとして動けるようになった
みたいな動きはすごい良かったなと思いますよね。
なのでエンジニアとしてこの会社に携わる部分の楽しさっていうのに
相まって余計難易度の高いプロジェクトでも
楽しく過ごせてるのかなっていう気はしてます。
はい、ということでまだ道半ばではあるんですけれども、
こういう大変なこと、大変なことって言っていいですかね、
難しいこと、チャレンジングのことを
やってみたいなっていう方がいらっしゃったら
ぜひカジュアルで無面談でもいいんで、
ぜひ何か応募でもしていただければなと思います。
話せてないこともあるので気になる方は
オフレコで聞きたい話がある方はぜひ聞いてください。
じゃあこんなところかな。
じゃあ今回のタイムツリーテックトークは
こんな感じのデータベースの最近のお話をしました。
ということで今回は終わりたいと思います。
ありがとうございます。
ありがとうございました。
ありがとうございました。
