大規模データセットのロードとレプリケーションの課題
LinkedInの環境には、新しいデータセットが常に入ってくるため、迅速にアップロードをして提供することを心がけているという。実際に同社内のSLA（Service Level Agreement）では、24時間以内に新しいデータセットを追加するようにしている。
このとき、新しいデータセットを単に追加するだけでなく、既存のデータセットにおける再処理が必要だ。LinkedInではデータロードについて、8,000から70,000のレコードを毎日処理するような検証をさまざまな方法で実施。SQLベースのアップデートではレイテンシーが約1.6倍に上昇することが確認できたという。一方、TiDB Lightningを用いたLogical Import Mode、Physical Import Modeで試してみると、バルクアップロードの性能がそれぞれ10倍、16倍と向上するも、レイテンシーに大きな影響を与えることも判明。サービスへの影響が大きいため、現時点で適用することは難しいとした。
とはいえ、LinkedInでは、今後100テラバイト規模のデータセットを処理することも求められる。よりレイテンシーに影響を与えない方法が求められる中、具体的な対策を検討している最中だとSinghai氏。たとえば、クラスターを分離するような方法も考えているが、データの一貫性を担保することが難しくなる。サーバークラスターを別に構築することでレプリケーションする案もあるが、どちらも検証中のフェーズだと明かした。
また、LinkedInでは、世界中に“アクティブ─アクティブ”なデータセンターを持ち、アップデートはどのデータセンターでも対応可能だという。更新されたデータは、カラム単位でレプリケーションされるが、データセンター間のレイテンシーが大きすぎると失敗するケースもでてくる。もし、何度も処理がラウンドトリップしてしまえば、ユーザーにも大きな影響を与えるだろう。
そこで同社では、非同期レプリケーションを利用している。ただし、同じ列が同時更新される可能性があり、コンフクリクトが発生しかねない。そのため、競合を解決する必要があり、LinkedInでは一貫性を多少妥協する（より後に書き込んだものを正とする）ことで実現しているという。何を妥協して実現するか、この判断で重要となるのは顧客体験だとSinghai氏は説明する。問題があったとき、“顧客体験”への影響を最小限にできるように設計しているという。
[画像クリックで拡大]
なお、非同期レプリケーションを拡張性の観点から見ると、増分バックアップデータを複製するために使用されるCDCツール（TiCDC）の最大スループットが限界値となり、大きなクラスターをもつ環境下では、スループットが低下するなどの問題が発生してしまう。また、同期処理のラグ（遅延時間）が数分、数時間と大きくなると、データベース間の同期が十分に取れないため大きな問題となる。大規模な環境下では、非同期レプリケーションを考慮すべき問題が他にもあり、レプリケーションのために必要なメタデータがユーザーに見えてしまうことも顧客体験上は問題だとSinghai氏は指摘する。
たとえば、50万台のサーバーで数100万のコアがあるとき、すべてのクラスターが同じハードウェアということを保証できない。ハードウェアの世代も違えば、ベンダーも異なるだろう。そのため、クラスターSKU（Stock Keeping Unit：製品構成）が異なってしまう点も難しい問題だ。こうした課題を解決するため、TiDBがセルフヒーリングを行えることは重要だとする。特にリバランシングができる点は良い一方、その頻度やタイミングなどをコントロールできたほうが良いとも指摘した。
[画像クリックで拡大]
先述したようにLinkedInではマルチテナンシーを重要視するが、まだ実現できたわけではない。現状、QPSやクラスターのサイズ、レプリケーションなどへの対応を優先しているためだ。大規模なTiDBクラスター環境における性能や可用性などをどのように担保すべきか、まだまだ学んでいる状態であり、進行中のものも多いとSinghai氏。今後は、TiDBユーザーコミュニティとコラボレーションすることで、一緒にTiDBを強くしていきたいと言うのだった。
