データベースの移行計画
何の音か全然わかんない。
これ今、みゅーがコーヒー入れようと思って、みゅーで多分ね、コーヒー豆ひいてたんですよね。
そうですね。みゅーどうですか?おいしい豆ひけました?
あれ?ちょっと今、集中してらっしゃるから、あれかな?
タイムツリーテックトーク、始めていきたいと思います。
今回はですね、今回も私、スコットが、こういうの何ていうの?モデレーターって言うんですか?
わかんないんですけど、しゃべります。
今回は、みゅーとグレッグを迎えて、前回、データベース周りの話をしたと思うんですけど、その続編のお話をしていきたいなと思います。
じゃあ、ちょっと簡単にみゅーとグレッグ自己紹介してもらおうかな。
みゅーはさっきも豆ひいてて集中してるかもしれないんで、グレッグから。
はい、グレッグです。タイムツリーのCTO室のエタリーチームに所属していて、バックエンドエンジニアをしています。
今は、データベースをマイグレーションするプロジェクトとかで色々やってるという感じです。
はい、めっちゃ色々やってもらってます。よろしくお願いします。
みゅーもコーヒー入った?大丈夫?
はい、大丈夫です。みゅーです。よろしくお願いします。
SLAチームで一応リーダーをやっていまして、インフラ周り全般と、あとはクラウドベンダーとのやり取りとか色々やってます。
はい、よろしくお願いします。
前回は、確かデータベースの課題ですね。今、AWSさんのAuroraを使ってるんですけれども、
今、ストレージ面の課題に当たっていて、移行をどうしようかという話をしたと思うんですけど、
前回、色々候補ですね。シャーディングをするのかとかいう話をして、その中の話で、
Vitesseのマネジメントサービスのプラネットスケールを使うのかとか、
果たして、はたまたスパナーかみたいな話を色々して検討してたという話をしてたような気がするんですけど、
我々が出した結論としては、スパナーを使うと結論を出しまして、
今、先ほどお話しした通り、AWSさんからGoogleクラウドさんに移行をするという茨の道を歩み始めたというところ。
とても大変なんですけれども、スパナーを使うメリットとか色々考えた結果、この選択をしましたという感じですね。
すごい長い茨の道になるんですけど、ミューにどういう計画の全体像みたいなお話をしてもらった方がいいかな?
そうですね。今回のGoogle移行というところなんですけど、とはいえ全てのものを、リソースを…
あ、ちょっと待ってくださいね。
コーヒーだ。コーヒーに目指したんだ、今。
ちゃんと1時から収録するって言ってたでしょ?
全てのAWSのリソースがターゲットというわけではなくてですね、
最大の目的はやはり先ほどスコットの説明にあった通り、データベースのストレージの上限に対する打ち手というところですので、
まずはデータベースとそれに接続している各種サービスを移行するといったものが今回のフェーズの目的、ゴールになります。
で、その上でのロードマップというのを、そのクラウドベンダーGoogleさんとのやり取りから、予算算出、あとは各サービスとの調整と、
あとはデータの移行の期間とかを考えた上でのロードマップを年内で引いたという感じですね。
なので規模感で言うと、規模感で言うと、そうですね、言ってもメインのサービス全てが移行されることになるので、
タイムツリーとしてはそこそこかなり大きな規模になるかなという感じです。
そうですね、タイムツリーの本体、APIサーバーとして動いているものだったり、
あと周辺のところをですね、ごそっと移行するというような形になりますね。
ごそっと移行するみたいな話は、逆に移行しないものみたいなことから話した方が分かりやすかったですかね。
そうですね、移行しないものとしましては、
例えばアセットなどのクラウドフォロー、CDN周りは大きなところで言うと移行しない部分になります。
背景としては直接アプリケーションというかクライアントからアクセスされる部分なので、
データベースからちょっと気に入らせて考えることができるというところですね。
あとはAWSではAuroraのほかにDynamoDBを利用しているんですけども、
DynamoDBもレイテンシーとしてクリティカルな利用の方法というのをほぼしていない状況というところで、
そこも移行対象外というふうに判断はしています。
ちょっと今とりあえず一番厳しいタイムツリー本体の、
ぶっちゃけ一番大きい予定データが入っているところを移行する、それに付随する、
直接アクセスがあるところをごっそり移行しようかなというような感じで、
対象となっているのがその画像とかファイルだったり、
あとDynamoDBのところもレイテンシーチェックした結果大丈夫そうだったらとりあえず移行対象から外して、
ちょっとスコープを狭めていこうというところですね。
そうですね。スコープを狭める最大の原因というのはやはりデータベースを移行するということを、
まず今年中に間に合わせるということが大きな目標になるので、
税抜くじゃないですけど無駄なものを反り落としていくという感じですね。
今最終的なゴールとしてはその辺も考えてはいるんですけど、
年内にっていうところでフェーズを切って動いているという感じですね。
という感じでですね、ロードマップとかマイルスを切って進めている感じになるんですけれども、
スキーマの変更とアプリケーションの修正
もうちょっと細かい話というか泥臭い話というか辛い話というかっていうのをですね、
アプリ観点だったり、実際のインフラストラクチャーの周りみたいなところで聞いてみたいなと思うんですけど、
じゃあそうですね、実際のアプリケーションに関してデータベース、
もともとAuroraはMySQLの互換のやつで使ってたんですけど、
Spannerに移行するということで結構仕組みが変わるというところで、
アプリケーションにも変更が入るんですけど、
Gregg、今どういうことをやっているのか聞いた方がいいかな。
今どういうことをやっているんですかね。
今はCloud SpannerにInterleaveというテーブルの親関係みたいなのを作ることができる機能が、
ざっくり言うとそういうのがあるんですけど、
それを使うためにスキーマをいろいろ見直していますというところですね。
そのスキーマ変更の作業を着々と進めているという状況ですね。
なるほどですね、そうなんですよね。
SpannerのInterleaveという仕組みが、ちゃんと考えないといけないよねという、
我々のアクセスの規模から考えると、
先にちゃんと設計してから入らないと、
逆にパフォーマンスが落ちるかもみたいな懸念もあるので。
そうですね、データベース自体を移行するので、
スキーマも全面的に見直さなきゃいけない。
そうですね。
そのためのいわゆるお掃除だったり、
属性の追加だったりみたいなことをやっている感じもありますよね。
そうですね、あとは普通の開発としてやっていくので、
その辺どういうふうにやっていくのかというところも計画したりとか、
実際にRedisから使うSpannerのアダプター、
Ruby Spanner Active RecordというSpannerアダプターがあるんですけど、
それをいろいろ使って試したりということをやっていたりするという感じですね。
その辺は本当に未知の領域だし、
特にプロダクションで実際どうなるのかみたいなこととかも、
本当に全然わかんない中で進めていると思うんですけど、
これ一番しんどいな、みたいなことってありました?
うーん、一番しんどいなはやっぱりあれですね、
今はとりあえずこれでいいかなってスキーマ設計を固め始めてはいるんですけど、
実際にそれに移行したときにパフォーマンスが出るのかっていうのは、
実際に試さないとわからないっていうのはありますね。
そのためにはデータをAuroraからSpannerに移行していくというか、
何ていうんですかね、流していくというか、
そういった裏でやらなきゃいけない仕組みもあると思うので、
その辺の構築とかも早く気をつけないとなという状況ですかね。
そうですね、実際にSpannerにデータを入れて、
不可視圏じゃないですけど、ちょっとやってとかっていう、
シミュレーションレベルでしかないと思うんですけど、
そういうこともちょっとやらないと、
なかなか安心して切り替えられないなみたいなところですよね。
そうですね。
我々にとってもSpannerを使うのも初めてですし、
いきなり結構でかいスケールから入るので、
ちゃんとプレッシャーがすごいあって、
データの中身の難しいことを一手にブレイクが引き寄せてくれているというような感じになっております。
一方でレールズですよね、レールズ使ってるんですけど、
レールズ周りの変更とかって今何をやってたり、
アプリケーション側の変更っていうんですかね、
レールズの、Rubyのコードのところの変更とかって何かやってたりするんですか。
まず今使われてないコードは片っ端から消していくというか、
モデルとか、そういうのをちゃんとやり切るところもスタートラインという感じなので、
そこもやってますね。
そうですね、いろいろクローズした機能とかもあるんだけど、
残骸が残ってたりとか。
そうそう、なので歴史を覆うみたいなことが最近多いかもしれませんね。
そうですね、いっつもプロリクエスト。
そうですね。
ごめんなさい、これはもう使ってないですっていうコメントをつけるっていう。
はい、聞いたりします。
あとはインターリーグを使うということは複合主旗を使うことになるので、
今もたまたま歴史的経緯で複合主旗を使っていて、
コンポジットプライマリーキーズっていうGEMを使っているんですけど、
これが新しいレールズのバージョンだとちょっとサポートが怪しそうな気配があるので、
標準のRuby、レールズの7.1から入った複合主旗の機能に移行するっていうところとかも
非常に調べながら向き合っているっていう最中ですね。
結構標準でサポートされた機能なので、
結構レールズのコードをコミット追っかけないとどうなってるか分からないみたいなところもあるので。
そうですね、まだ不安定な部分もありそうなので、その辺を見たりしていると。
結構変更も入りますしね。
普通のアプリケーションエンジニアにしてみると結構難しいこと。
難しいことはフレームワークに深く入り込みつつでかいデータを使うみたいなことをやってるっていう感じですね。
楽しそうだなぁ。
いいなぁ。
僕もちょっとレビューぐらいしかできてないんですけど。
いやいや、めっちゃ助かってます。ありがとうございます。
レビューできてないんですが。
一方で次があれですね、インフラですよね。
もうなんかごっそり変わるっていうことで、
みゅうが今いろいろと作り直してくれてるという感じなんですけど、
今はどんなことやってますか、みゅう。
データの移行とパフォーマンステスト
そうですね。今まででいうと、
実はまずGoogle移行が決まったときに、
実はまだうちでは組織的なGoogleクラウド運用に対しての
IACというか整理というのがそこまでちゃんとされてない状況だったんですけど、
実は裏では分析用にビッグクエリを利用していたりとか、
すでに利用はしていた状況でした。
今回まずタイムツリーサービスが移行されるって決まったときにですね、
前段としてまずGoogleクラウドをちゃんと運用しないといけないというふうに思ったので、
まずは組織にひんも付くプロジェクトとかフォルダとかですね、
経費をよく見やすくしたりとか、
会社の組織に合わせたフォルダを作成したりとか、
そこら辺の整理をまず前段としてSREの仕事としてしていましたっていう感じなんですね。
で、そこから実際に移行に対する作業っていうのが始まったんですけど、
そうですね、さっきグレックからもあったんですけど、
パフォーマンステストとかもいろいろ用意しなくちゃいけないっていうところの
一つの課題としてやはりデータベースのデータが非常に大きいというところがありまして、
なので、AuroraからSpannerに本番データを移行する方法として、
Auroraからデータストリームを利用してクラウドストレージに配置してたから、
データフローを使ってSpannerにインサートするっていうフローを想定しているんですけど、
それをやるとですね、何ヶ月もかかってしまうというところで、
スタートをかなり早めても今年中に終わらせるっていうのがかなりギリギリ。
その中で、切り替える前にパフォーマンステストをしなくちゃいけないっていう課題があるので、
データベースの移行準備
スケジュールとしてはかなり複雑というか、かなり厳しい状況の中でどうするかっていうところの課題に最近ぶち当たっていて、
で、今やっているところがSpannerマイグレーションツールっていうGoogleさんが用意しているツールがあって、
それだとMySQLダンプから直接Spannerにマイグレートできるということで、
今Auroraのダンプを取って、それをGoogleのストレージの方に移動させるっていう作業をやってるんですけど、
そのまたダンプが重いですので、
AWSのS3もGoogleクラウドストレージも一つのオブジェクトに対する上限が5テラでして、
それ以上のテラバイト数にいってしまうので、今テーブルごとにダンプを取ったりですね、
その取ったデータをさらにジップ圧縮して移動させやすくしたりとか、
そういったところを裏でやりながらGoogleのほうの環境を整えているというところです。
ちなみに今5テラまでっていう話聞こえたんですけど、どのくらいオーバーしてるんですか?
そうですね、だいたい今だとダンプファイルが7テラぐらいですね。
ロイオーバーですね。
あと2,3年着手が遅かったらちょっとやばかったかもしれない。
でも2,3年遅かったらひょっとしたら5テラの上限がなかったかもしれない。
そういう問題ではないんですけど。
その可能性も十分ありましたね。
ちょっと今Miuの発言からいろいろ出てきたんですけど、
データストリームとかマイグレーションツールとかいろいろ出てきたんですけど、
Googleさんのそういうデータの移行用のサービスを使って
スパナにリアルタイム、もうリアルタイムですよね。
リアルタイムで同期するっていうシチュエーションを作るっていう。
そうですね、じゃあちょっと技術的なラジオなのでちょっとだけ説明すると、
データストリームっていうのはストリームっていう通りイベントというか、
データベースがソースになると、
Binlogから追随して同期を図っていくツールになります。
ただBinlogだけだと今まであるデータっていうのが同期できないので、
データ移行の課題
そこはBackfillという機能がもともと用意されていてですね、
まず現状のスナップショットというか断面をデータを一気に同期させてから
Binlogを追随することによってリアルタイムな完全同期が可能になるという感じですね。
それがデータストリームだけだと時間がかかっちゃうので、
最初の一発目はマイグレーションツールを使ってダンプでインサートしようと。
そうですね。
ダンプのときのBinlogの地点って言ったらいいのかな。
あれは覚えておく必要があるって感じなんですよね、多分。
今回の目的っていうのは、
ある程度のデータ量を保持した移行を素早く実施するっていうところがやりたいことで、
その背景としては、ある程度のデータ量をスパナーに入れてパフォーマンス計測がしたいというところ。
なるほどですね。
なので、今の現在のデータ量があればもう十分だと思って、
一旦その後の同期っていうのは考えずにですね。
なるほどですね。一旦じゃあとりあえずパフォーマンステストのためにドカッとデータを入れたいという。
そうそうそうですね。
なるほどですね。ありがとうございます。
その後はURLさんのさっきのデータストリームとかを使って、
同期しているシチュエーションを作って、切り替えのための準備をするというような感じですね。
そうですね。
タイムツリーを使っていただいている中で書き込みをすると、
AWSさんのAuroraとGoogle CloudさんのSpannerに両方とも書き込まれるシチュエーションを作る必要があるというのが、
これだけデータがでかいというだけで大変なことになるという話ですね。
データだったり書き込まれる量もありますね、当然ね。
そうですね。
あとちょっと話にも出てたと思うんですけども、
もともとデータの分析とかのためにビッグクエリを使って、
タイムツリーのログデータだったり、データをそのものをビッグクエリに入れたりして分析とかしてたんですけど、
その状況が結構あれなんですよね。
あんまり管理されていなかったというところが正直あって、
僕が作った適当なオースのアプリケーションとかプロジェクトとかいっぱいあるんですよね、確か。
それ全部そうでしたっけ?
いや、覚えてないな。
僕が確か消したのかな。
いろいろ試したプロジェクトがいっぱいあった気がする。
ちょっと後で確認しに行こう。
でもその辺もIAC部分的にできてたんでしたっけ?
そうですね。
分析系の部分というのが、そもそもプロジェクト管理とかも結構曖昧というか、
まあいいだろうみたいな感じでやってたのが一つあるのと、
あとはIACの部分でいうと、
えっとね、僕が入社した頃、5年前とか6年前とかは、
まだね、GoogleのIACがそこまで便利じゃなかったんですよ。
ああ、確かに。
テレフォームとかも対応してない。
結構あったり、そうそうあって、
なので、できる範囲ではやってたけど、
まあ結局お隣になって置いてかれてったっていうのが現状でしたね。
確かにそういうこともありましたね。
そうそう。で、分析チームは分析チームで今新しい分析プロジェクトっていうのを作って、
整理すごいきれいにしようとしてくれてたりとかして、
なるほど。
整地化されていってるっていう感じですね。
その辺のアプリケーション寄りのところとかの整理だったりとか、
っていうところが今課題になっててやってくれてると。
あとね、そう。
知見がまだGoogleクラウドの知見がその時あまりなくて、
何でしたっけ?アカウント管理が前だとGoogle…
Googleワークスペース?
ワークスペースの前って何でしたっけ?
覚えてない。
アカウント管理のやつあるじゃないですか。
アカウント管理のあれ。
その権限とテラフォームの管理がバッティングしちゃったりとかして、
うまいこと運用できなかったんですよね、知見の浅さによって。
G Suite?
あ、そうだ。
それだ。
データ移行後の運用
そうだ。
それだ、G Suite。
そうだ。
思い出した。
そうそう。
クラウドの管理の方法も結構昔はコンソールでやったり、
ACでやったりとかしてて、なんか競合入っちゃったりとか。
運用体制もそこまで考えられてなかった感じですね。
そうですね。
結構適当にやってたところがあったし、
それでも大丈夫なぐらいの人数だったっていうのもありますよね。
そうですね。
誰かいじったなーみたいなことを言うと、
ごめんなさい、僕ですみたいなこと。
ごめんなさい、僕ですって言ってたのも多分僕だと思うんですけど。
それぐらいのでかい声をあげれば、とにかく届いたみたいな距離感もあったので、
なんとかなってたんですけど、
ちょっと組織とかもこれから大きくなっていく形で、
ちゃんと管理しようという動きが出てくるのは当然のことかなというところですね。
その辺もちょっと整えていかないと、
その後切り替えた後の運用も当然入ってくるんでね。
考えないと難しいよねっていうところで、
今整備してもらっているというところですね。
現状としてはこんなところかな。
本当にデータを移行する、
データを突っ込んだとどうだっていうことに関しては、
また次回以降の話になるかなと思って、
まだ今は下準備だったりとか、
お掃除、移行元のお掃除みたいなことが、
ちょっとメインのタスクになっているというような感じですね。
あと一番というか非常に助かった制度は、
Googleさんのタップがすごい良かったですよね。
すごい良かったですね。
何の略だったか忘れてしまいましたけれども。
もちろん忘れてしまいました。
アクセラレーションプログラムでしたっけ?
確かそんなやつ。
アクセラレーションプログラムってやつですね。
Googleさんのオフィスに行って、
そのやりたいことみたいなことだったりっていうのを、
ペアプロとかモンプロに近い感じで物事を進めるっていうんですかね。
設計の話などをしながら、
Googleさんにいろいろ知見を教えていただいて、
自分たちのインプットとして考えていくみたいな、
プログラムを組んでいただきまして、
そこでいろいろ、そこですごくGoogleクラウドのコンポーネントについても
いろいろ教えていただいて、
何ができて何ができないのかみたいな話とかも含めて、
今の自分たちの環境と実行環境と比べてどうするっていう話とかも
進められることができて、
すごくそれで。
その場でハンズオンでやってくれるんですか。
そうですね、すごい進んだ感じがありましたね。
すみません、ちなみにこれはAWS版と比較して、
良い悪い言うけど、
そのプログラムが良かったというだけですので、ご了承ください。
知見、大規模な運用っていう観点でいうと知見がないところに
サポートしていただいたのは本当に助かったなというところが
素直な感想でしたね。
今こんなことをやってて、
この先、年内にとりあえず移行するっていうことで、
ロードマップを組んでいるので、
その先はまだちょっと未定ですけれども、
移行していないコンポーネントをどうやって移行するかっていう、
その先のロードマップもまたゴールが見えてきたら作り始めて、
動かしていくという形になるのかなと思っているので、
またその話もいずれできればなという感じですかね。
ということで、今回のTechTalkはこれでおしまい。
ありがとうございます。
ありがとうございました。
