※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！

こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。

データベースの最適解

DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現在は模索しています。

第１・第２世代の “ツラミ” を表にまとめました。項目としては運用・性能・品質・コストが存在し、それぞれの項目にて ◯・△・✕ で “ツラミ” の度合いを示しています。

第１世代の “ツラミ” は運用でした。DeNA では数百シャードのデータベースを運用しており、それに伴う運用、中でも故障対応が工数を圧迫していました。もちろん作業の９割程度は自動化されており、作業自体も難しいものではありません。それでもなお完全自動化とはいかず、我々は工数を消費させられていました。これが第１世代の “ツラミ” です。

第２世代の “ツラミ” はコストです。 まず改善点ですが、第２世代へ移行したことによって運用面は大きく改善しました。故障対応は難易度・作業時間共に大きく減少し、更に対応が楽になりました。加えて、特定の時間帯だけデータベースを増減させるなど、台数調整もある程度は自動化出来るようになりました。より長期的な問題としてシャード統合やイベント対応は残ったものの、かなり運用が楽になったと言えます。

さらなる詳細は 数百shard のデータベース運用を最適化する手法 をご参照ください。

逆に “ツラミ” が増してしまった点はコストです。やはり Aurora は高く、EC2 上に MySQL を構築していた第１世代と比較してコストはかなり増大しました。単純な同スペックのインスタンス料金で比較すると、Aurora は EC2 インスタンスの約２倍にもなります。加えてバックアップ取得時には、その保存料と通信費もかさみます。結果、コスト全体のかなりの割合を Aurora が占めるようになりました。これが第２世代の “ツラミ” です。

第３世代では、これらの “ツラミ” をデータベースアーキテクチャーによって解消した上で、性能・品質の点も従来と同程度を担保できるものを検討しています。

続く第３世代のデータベース構成としては、Aurora Serverless v2 と TiDB を検討しています。ここではそれぞれの特徴について、簡単に触れていきます。

Aurora Serverless v2 は近々 GA が予定されている(はず)の AWS の新サービスです。2018年に GA した Aurora Serverless の後継に該当しますが、単純なバージョンアップとは思えないほど様々な機能を備えています。 具体的には、既存 Aurora Cluster に組み込める Aurora 本体との互換性、オートスケールのロジックの改善と、それに伴うコスト削減効果の上昇、より詳細なキャパシティ設定などが挙げられます。 未知の要素も大きいですが、第２世代での知見がそのまま活かせそうな点、コスト削減が見込める点から非常に期待しているサービスです。

TiDB は主に PingCAP によって開発が進められている、オープンソースの NewSQL データベースです。 NewSQL にしては珍しく MySQL v5.7 互換であり、ACID トランザクションをサポートしています。 また、他の NewSQL と同様に、台数追加による水平スケール・分散システムによる高い可用性が保証されています。これらの特徴から TiDB を第３世代データベースとして検討するに至りました。

今回はこの２つの内、TiDB に関する検討をご紹介させて頂きます。

運用改善 in TiDB

TiDB の検討へ入る前に、TiDB 自体の構成と互換性について、少し掘り下げていきます。

NewSQL である TiDB は複数のコンポーネントから構成されています。最小構成の TiDB には ストレージ層に該当する KVS の TiKV。データロケーションやメタデータを管理する PD。同じ名前で少しややこしいですが、MySQL 互換の Interface を提供し、TiKV からデータを取り出す TiDB の３つのコンポーネントが含まれます。

TiDB と MySQL v5.7 互換は完璧でなく、外部キー制約など一部の機能がサポートされていません。また、大きな違いとして主キーの単調増加性も担保されていません。 しかしそれ以外の機能、バックアップ、リストア、レプリケーションは MySQL と同様の使い勝手が出来るため、依然互換性が高いことには変わりません。

より詳細な差分に関しては、 TiDB の公式ページ に記載 があります。

次に、TiDB を用いてどのように既存データベース構成を改善していくのかを見ていきます。

まずは、運用面です。先程、運用上の “ツラミ” として “シャード統合” と “イベント対応” を挙げました。これらは TiDB の持つスケールへの柔軟性で、解消できます。

シャード統合とは、データベースリソースの縮小作業を指します。サービスのデータベースコスト削減のために行われ、２つのシャードを１つに統合することでデータベース台数を削減します。イベント対応とは、データベースの一時的な増強作業を指します。サービスの周年記念といったイベントのために行われ、増加する負荷に対応できるように期間中データベースのスペックを上げます。

シャード統合の本質はデータベースの台数調整によるコスト削減ですが、TiDB ではこの作業は不要になります。というのも、TiDB はその特徴としてストレージ層のデータバランシングを自動で行います。例えば TiKV が 10台存在するクラスターへ 100GB のデータを投入した場合、１台の TiKV が保持するデータ量は 約 10GB になります。ここから 5台 TiKV を取り除いた場合は、１台の TiKV が保持するデータ量が 20GB になるよう自動で調整がなされます。このため TiDB におけるシャード統合とは、単に TiKV の台数を半減させる作業と変わらず、日々の台数調整作業の中に組み込むことができます。

イベント対応もその作業自体は短期的なスペック変更であり、同様に TiKV の台数追加により解消できます。これは Aurora とは異なり、TiDB では台数に応じて書き込み性能がスケールするためです。通常 Aurora にて書き込み性能を向上させるためには、フェイルオーバーを伴うスケールアップしかありません。しかし、TiDB はデータベースであるにも関わらず、スケールアウトを可能にしています。この手間の差により TiDB では台数調整のみでイベント対応が完結し、運用工数は極限まで小さくなります。

このように TiDB は我々の運用を劇的に楽にしてくれます。

性能検証 in TiDB

次に TiDB を性能面から見ていきます。目的は以下の２つを設定して検証しました。

• TiDB は MySQL・Aurora と同等の性能 (TPS、QPS、Latency) を出すことは可能か。
• TiDB、TiKV のそれぞれのスペックは性能 (TPS、QPS、Latency) へどのような影響を与えるのか。

データベースの性能評価は１つの指標で語れるほど甘くはありませんが、何かしらの方法で比較はしなくてはなりません。今回は sysbench に存在するテストケースの内、read_only、write_only、read_write を採用し検証しました。

検証環境は AWS の VPC 内部に構築し、３つのアベイラビリティゾーンに跨るサブネットを作成しています。TiDB、TiKV、PD はそれぞれ均等な数が各アベイラビリティゾーンに配置されるような構成にし、インスタンスタイプは TiDB のレポート を参考に決定しました。

また、TiDB、TiKV、PD をそれぞれ３台配置する最小限の構成から、TiDB と TiKV を ３、６、９と増加し、TiDB、TiKV の台数がそれぞれパフォーマンスに与える影響を調査していきます。

TiDB、TiKV の台数を３、６、９ と変化させた場合の read_only の QPS の変化を表にまとめました。

真っ先に目に付くのは、TiDB と TiKV の台数追加への QPS 上昇値の違いです。 TiKV の台数追加では、TiDB３台、TiKV６台構成から TiDB３台、TiKV９台構成への変更では 唯一 QPS が変化しなかったもの、それ以外の変更で 2 または 1.5 倍の上昇値を記録しました。

反対に TiDB の台数追加は値が大きく上昇したのは、TiDB３台、TiKV９台 から TiDB６台、TiKV９台の場合のみであり、それ以外は QPS の上昇は殆ど見られませんでした。 なお、sysbench 実行中に TiDB３台、TiKV９台構成の TiDB の CPU 使用量を確認したところ、100% 近くまで張り付いており、やはり CPU ネックになっていました。

これらの点から TiDB の読み込み性能は主に、TiKV と TiDB の２つのコンポーネントのスペックに依存しており、その台数を変化させることでスケールすることが分かりました。

同様に write_only の QPS 変化を表にまとめています。

まず気になる点は、TiDB への依存が減っている点です。TiDB３台、TiKV６台構成と TiDB３台、TiKV９台構成の QPS を参照すると、約 1.5 倍に増えており TiDB の台数によらず性能がでています。 これは、読み込みでは TiDB の CPU ネックになっていたものが、TiKV の何らかのリソースへ移ったためと考えられます。

また少ない台数ではありますが、TiKV３台の場合と TiKV９台の場合で一台あたりの QPS 性能の平均を取り比較してみると、TiKV３台では 約 8,500 QPS、TiKV９台では 約 8,100 QPS と多少性能は落ちているものの順当にスケールしていることが確認できます。

これらの点より、TiDB における書き込み性能は主に TiKV のスペックに依存しており、読み込み性能と同様にスケールアウトによってその性能が向上すること分かりました。

最後に read_write の QPS 変化を表にまとめました。

特筆する点は、やはり TiDB３台、TiKV９台構成の場合です。TiDB３台、TiKV６台構成と比較すると、QPS の変化が多少伸び悩んでいる様子が見て取れます。read_write は１つのトランザクション内部で read_only、read_write の SQL 続けて発行しているため、ある程度は TiDB の CPU への依存がありこのような結果になったのではと推測しています。

読み込みと書き込みを続けてに実行するこのような read_write の挙動は、今回のテストケースの中では最もアプリケーションに近いものと捉えることができます。よって今回の試験を通してTiDB の性能を語る上で、重要な指標となってきます。

同様の検証を MySQL・Aurora に対しても行い、表にしました。

Aurora は writer と reader の２台構成とし、MySQL は master１台、slave２台の合計３台構成としています。括弧の中には sysbench の対象としたデータベースを記載しました。(_m ならば master １台。_s, _s ならば slave ２台が対象) 比較対象として TiDB３台、TiKV３台構成と TiDB３台、TiKV６台構成の結果を載せています。

最初に目を引くのは、MySQL の read_only の結果です。master、slave、slave の３台のみで 100,000 QPS 以上の値を記録しているにも関わらずコストが最も低く、優れたデータベース構成と言えます。TiDB３台、TiKV３台構成と比較してもその差は歴然です。 が、write_only を参照すると TiDB とその差は逆転しています。これは MySQL の書き込み性能がスケールアウトしないためであり、これ以上 QPS を稼ぐにはマルチシャードによる水平分割しかありません。

一方 TiDB も１台あたりの QPS はそこまで大きくありません。複数コンポーネントを備えているため、コンポーネント間の通信によって QPS が低く抑えられているためです。それでもなお、データベースをスケールアウトさせることが出来るのは驚異的であり、TiDB には検討する価値があります。

最後に、read_write の値を比較します。コストあたりの性能においては MySQL や Aurora に軍配があがるものの、TiDB の性能とその差は小さく十分に実用に耐えうるものです。台数追加によるスケール性能を加味すると、特段 MySQL・Aurora と比較して特段劣っているわけではありません。

品質検証 in TiDB

続けて TiDB の品質面を明らかにしていきます。構成要素としては 可用性・耐久性・完全性が考えられ、今回は特に TiDB の可用性について、検証を行いました。

検証は sysbench の read_only を用いました。試験中に AWS CLI にて決められた台数の TiKV インスタンスを強制的に停止し、sysbench の結果に及ぼす影響を調査しました。なお、インスタンスタイプなどの設定は性能検証の際と全く同じものを使用しています。

検証は以下のように条件を変えて数回実施しています。これは停止台数や全体台数のによって結果が変わらないことを確認するためです。TiDB３台、TiKV３台から１台停止を基本とし、全体台数を増やしたパターンと、全体台数と停止台数を増やしたパターンを追加しています。

それぞれの条件で sysbench を実行し、得られた QPS の変化をグラフにまとめました。

グラフより、TiKV インスタンスの停止直後に QPS が大きく落ち込んでいます。時間にして１０秒ほど完全に QPS の値が０になった後、更に１０秒の時間を経て元の QPS まで復旧しています。

この結果より、復旧速度という面では TiDB は第１・第２世代 に勝ちを譲ることとなります。２０秒も十分速いですが、第１・第２世代は DeNA 独自の MHA、フェイルオーバーにより数秒での復旧が可能なためです。なおこの２０秒は調整が可能ですが、トレードオフとして安全面を犠牲にすることとなります。

また、QPS が０になっているというのも懸念点です。TiKV 一部のみの停止にも関わらず、全体の QPS の値が０まで低下しています。この点に関しては sysbench のテストケースの影響とも取れ、更に実際のワークロードなどで検証が必要です。

このように気になる点はありますが、TiDB の AZ 障害へのリアクションや、一定の可用性が担保されていることが確認できました。

コスト in TiDB

最後に TiDB をコスト面から検証します。TiDB 置き換えの試算を進める中で、意外にもネックになるのはディスク容量でした。これには２つの理由があります。

１つ目に、リリースからある程度時間が経過したサービスの場合、要求されるディスク容量がより大きくなるためです。ゲームはその特性上リリース直後は最も負荷が高く、その後負荷は緩やかに低下します。他方、ディスクへ保存するデータ量は、その速度は減衰しますが総量としては増え続けます。このためリリースから時間が過ぎるほど、QPS の要求ハードルは下がり続けますがディスクへの要求ハードルは上がり続けます。

２つ目に、AZ 障害 +α を耐えうる冗長性を担保するためです。TiDB はインスタンス障害に備えて、内部でデータコピーを生成し異なる TiKV に格納しています。デフォルトのコピー数は３ですが、これでは第１・第２世代と同レベルの冗長性は担保できませんでした。３コピーでは、AZ 障害中に別 AZ のインスタンスが追加で故障するとデータロストの可能性があります。DeNA で安定運用できる冗長性を担保するためには、コピー数は５となり結果データ総量は増加します。

一方で、ディスク容量をより効率よく利用できるようなる側面もあります。TiDB のストレージ層である TiKV は容易にディスク拡張が行え、ディスク使用量の閾値もより高いものに設定することができます。例えば既存のディスク使用量が約５０％の場合、台数を削減し全台８０％程度のディスク使用量となるように調整。その後は使用量の増加に応じて台数追加をしていくと行った、柔軟な対応が可能になります。

これによりディスク使用率５０％の MySQL が複数台存在するとしても、ディスク使用率８０％のより少ない台数の TiKV で同レベルの冗長性を確保できます。

実際の試算内容は載せられないため、サンプルではありますが MySQL８台構成を、TiDB２台、TiKV６台構成へ置き換えた際のコスト変化を表にまとめました。なお、TiDB 全体に占める PD 料金の割合はかなり小さくなるため、今回の考慮からは外しています。

前述のとおり TiDB２台、TiKV６台構成であれば MySQL ８台構成と同レベルのコストで実現可能という目算が立ちました。 また TiKV、TiDB のインスタンスタイプとしてそれぞれ i3.2xlarge、c5.4xlarge を使用していますが、これらはまだコスト削減の余地を残しています。

しかしそれでもなお、TiDB、TiKV という２コンポーネント化によるコスト増加は痛いというのが正直なところです。

評価 in TiDB

現時点のまとめとして、運用・性能・品質・コスト面の TiDB への評価を表にしました。

運用はシャード統合やイベント対応の工数が短縮されになり、かなりの改善が見込めます。性能に関しても、１台あたりの性能では劣るものの、書き込み性能が水平にスケール出来る点。またそのスケール幅がリニアな点より、MySQL・Aurora と同程度の性能を出すことは難しく無いと判断できます。

他方、品質とコスト面では懸念が残りました。品質に関しては MySQL の互換性と可用性で懸念が生じており、アプリケーションも交えた検証が必要と言えます。このため現時点では？と記載しています。 コスト面は同程度のコストを維持することは可能としつつも、コンポーネント増加による台数追加や、単純な MySQL ほど台数が性能に反映されない点から△としました。

以上が行った TiDB への検証の内容になります。数百シャードレベルのデータベースともなると、その規模でしか発生しない問題や “ツラミ” が大きく重くのしかかって来ます。DeNA ではこれらを改善し利用者に Delight を届けるべく、TiDB や Aurora Serverless v2 といった新技術に挑戦しています。

おわりに

私たちは、DeNA グループ全体のシステム基盤を横断して管理しているインフラ部門に所属しています。こちらでチームの紹介をしていますので、ぜひご覧ください。