Kubernetes Forum＠ソウル、YouTubeの本番で利用されるVitessのセッションを紹介

ソウルで開催されたKubernetes Forumでは、Multicluster（マルチクラスター）やFederation（フェデレーション）といった大規模環境でのKubernetesの運用に関するセッションに注目が集まっていた。加えて、もう一つ注目を集めていたセッションがVitessに関するものだ。

セッションのスピーカーは、YouTubeでVitessを開発して、その後Vitessの開発とサポートを行うPlanetScaleを起こしたCEOのJitendra Vaidya氏と、エンジニアのDeepthi Sigireddi氏だ。

プレゼンテーションは以下のリンクから参照されたい。

Jurisdiction Aware Databases with Vitess（PDF）

VitessはCNCFのインキュベーションからはすでにGraduationしている成熟したプロジェクトだが、実際にはCNCFにホストされたのは2018年2月、Graduationが2019年11月なので、2年に満たない期間で卒業したことになる。一方Kubernetesの卒業は2018年3月で、CNCFの創設が2015年12月なので、VitessはKubernetesよりも短い時間での卒業となる。

プレゼンテーションを行うPlanetScaleのエンジニア、Sigireddi氏（左）とCEOのVaidya氏

CNCFが用意した別の動画でPlanetScaleのCTOであるSugu Sougoumarane氏が解説した内容によれば、2015年にKubernetesがV1になる前の時点で、VitessはKubernetesに対応していたというから驚きである。その種明かしをすると、GoogleがYouTubeを買収した2006年の時点では当然のことながら、YouTubeは自社のデータセンターで運用を行っており、そこでMySQLに対する問題点を解決するためにVitessが開発された。その当時はVitessをプロプライエタリなソフトウェアにするか、オープンソースソフトウェアにするかという議論があったが、最終的にオープンソースソフトウェアモデルを選択したという。

その後、Googleからの要請でVitessをGoogleのデータセンターにマイグレーションすることになる。その際にGoogleのプロプライエタリなAPIを呼ぶ必要が出てきた。このプロプライエタリなAPIというのは、主にGoogle社内で使われているコンテナオーケストレーションツールであるBorgを指す。しかしそれを行うと、オープンソースソフトウェアとしては公開ができなくなるということで、BorgやロギングなどのAPIについては抽象化するレイヤーを追加することで、オープンソースの部分とBorgに対するプロプライエタリな部分を切り分けたという。その後、GoogleがBorgのオープンソースソフトウェア版であるKubernetesを公開する際に、その抽象化レイヤーの下をKubernetes用に置き換えたというのが真相のようだ。

つまりVitessは、BorgからKubernetesに生まれ変わる前に、すでにスケールアウトできるMySQLのデータベースとして利用され始めたと言えるだろう。そしてその背景には、YouTubeが遭遇した課題がある。

Vitessが解決した問題点とは

このスライドではデータローカリティ（そのデータがどの国／地域に存在するのかを明示すること）の必要性を強調しているが、YouTubeが映画などのコンテンツを配信していたプラットフォームであることを思えば、「どの国のユーザーがどの映画を視聴可能なのか？」「そのコンテンツはどこに存在するのか？」という固有の問題に取り組んだ結果であることは明らかだ。その上で、データの存在する場所を保持しながら、水平にスケールするMySQLデータストアを実装したのがVitessと言える。

また複数のロケーションにデータを分散させる要件を満たすように設計すれば、アプリケーションもそれを意識した構造に再設計する必要があるというのが3つ目の問題点だ。Vitessに関して言えば、それをミドルウェアであるvtgateとMySQLインスタンスを保持するvttabletが実装しているため、アプリケーション側は何も変更する必要がない。この点もMySQLからのVitessへのマイグレーションが進む大きな理由だろう。

Vitessのアーキテクチャー

Vitessのアーキテクチャーを示したこのスライドでわかることは、アプリケーションからMySQLを切り離した構造になっていることだ。アプリケーションからは中間に位置するvtgateがMySQLのように見える。実装上vtgateはゲートウェイとして存在するだけで、実際のMySQLインスタンスはvttabletと呼ばれるプロセスの配下に存在し、vttabletがMaster-Replicaの構造を持ってデータベースのシャーディング（水平分割）を実装する。

VitessがユニークなのはKubernetesの初期のころから対応しているにも関わらず、KubernetesのPodスケジューリングに依存しないことだ。MySQLのシャーディングのために、MasterとReplicaという複数のプロセス（vttablet）がセットとなり、データを分割するが、MasterとなるPodが停止した時にKubernetesはそれをリスタートするように動作する。しかしそれでは性能が悪すぎるためにVitessはvtgateというゲートウェイをデータストアの直前に置き、フェイルしたMasterを再起動する代わりに別のReplicaをMasterと設定してデータアクセスを継続できるように設計されている。そのため、アプリケーションはKubernetesのPodリスタートを待たずに数ミリ秒の遅延でアクセスすることが可能となり、アプリケーション側での性能低下を防止できる。

また管理のためのプロセスであるvtctldというプロセスが常にvttabletのサービスディスカバリーを行うために、MySQLクラスターの信頼性は保持できる構造になっているという。Podの関係などはTopologyと呼ばれるetcdベースのメタデータストアで管理される。ちなみにVitessはGoで記述されているという点もクラウドネイティブとも言えるだろう。

VitessのKeyspaceはMySQLのDatabaseに相当

Shardingについて説明するこのスライドでは、データが分割され別々のデータベースに格納されるだけではなくMaster-Replicaに複製され、Cellと呼ばれる単位で別のノードにも実装されることが簡潔に説明されている。Cellはデータセンター的に言えばAvailableZoneに相当する独立したサーバー群である。Cellの管理はアプリケーションではなくVitessに任されるので、デベロッパーは単純なMySQLにアクセスするだけで冗長性を上げることができる。

実際にVitessがどのように動くのかについては、CNCFによるVitessを紹介するビデオを参照されたい。

Vitess: Sharded MySQL on Kubernetes

動画の全編の視聴をお勧めするが、最低でもデモ（24分15秒～）だけは見て欲しい。それでVitessの概要を掴めるはずだ。ここではECサイトを例に挙げて、Product、Customer、Order、Merchantという4つのテーブルを使ってオンラインでオーダーを受ける処理を行うものだ。

CustomerとOrderはShardingされて格納される。デモではテーブルの中身と実行するSQL文、そして結果が1画面で見られることによって実際のデータが変化していくことを理解できる。デモだけでも17分ほどある動画だが、ぜひ最後まで見て欲しい。速度を上げるためにテーブルを複製するMaterializeの機能も理解できる。

またセッションの後にVaidya氏と話した際に、以下のコメントを得た。「真の意味のマルチクラウド、ハイブリッドクラウドなデータベースを実現できるのはVitessだけだ。Auroraは信頼性をAWSが担保するが、それではAWSにロックインされてしまう。Kubernetesの良いところは、オンプレミスでもパブリッククラウドでも動くところだが、データベースに関してはそれができなかった。VitessはYouTubeやSquare、JD.comなどで使われているように、本当の意味でマルチクラウドなデータベースを実現できている」このコメントにあるように、信頼性を保ちながらパブリッククラウドにロックインされることを避けるためにVitessを使うというのは、説得力のある意見だろう。

蛇足だが、Vaidya氏には両手の指がほぼ欠損しており、それについて質問したところ「若い頃、ヒマラヤに登った時に遭難して指を失ってしまった。でも今は何の問題もなく生活も仕事もできるよ。唯一できなくなったのはピアノを弾くことぐらいだが、それは指を失う前からできなかったので問題はない」と笑い飛ばしていたのが印象的だった。今後のVitessの応用事例についても注目して行きたい。