1年以上にわたり検証を重ねたLinkedIn、PDボトルネックの解消に向けた取り組みとは
LinkedInは、TiDBの開発元であるPingCAPと協力し、1年以上にわたりTiDB環境の検証を進めてきた。そもそもLinkedInは、世界で10億人を超える登録メンバーと数千万の組織が利用する巨大SNSであり、そのデータ処理基盤には膨大な負荷がかかる。たとえば、2024年1月にはピーク時に毎秒255万のリクエスト、1日に4.5兆ものKafkaメッセージが送信されているという。
また、LinkedInには、数百万ペタバイトものデータが保存されており、データレイクにはエクサバイト規模のデータが蓄積されている。日々発生する大量のクエリを処理するため、TiDBの大規模な環境を構築・運用することが極めて重要だとSinghai氏は強調。さらに世界中で24時間利用されるSNSであるため、99.99%以上の可用性が求められる。Singhai氏は、「サービス停止は許されず、計画的なメンテナンス時間すら設けることができません。また、複数のアプリケーションやデータセットが存在し、多くのチームがデータを扱うため、システムは非常に複雑です。そのため、複数の利用者がそれぞれ独立してデータベースを利用できる、マルチテナンシーに対応することも重要です」と語る。
LinkedIn Corporation, SW Engineering Director
この大規模かつ複雑なシステム運用環境は、常に変化する点も特徴的だ。たとえば、ハードウェアが故障して再インストールが行われたり、クラスターを拡張するソフトウェアが導入されたりすることもある。つまり、日々変化があるような環境では、“オペラビリティ（運用性）”を担保せねばならず、拡張性が高くとも運用性が低ければ意味はないのだ。「自己修復ができ、信頼性とレジリエンスが備わった環境でなければなりません」とSinghai氏は言う。
[画像クリックで拡大]
このような複雑な環境を支えるため、LinkedInはさまざまな検証を実施しており、その中の1つにServingシステムにおける、大規模なデータセットのロードとクエリがある。対象システムでは大規模クラスターを構築しており、任意の結合やインデックス検索が行われるが、データサイズとクエリ量を別々に拡張できることが要件だ。たとえば、QPS（Queries Per Second）を拡張することもあれば、QPSは増やさずにデータサイズだけを大きくする場合もある。なお、システムの規模は約500万QPS、5ペタバイトものデータ量になるという。
また、クラスターを拡張するためにリージョンを越えたレプリケーション、新たなデータセットに対するバルクロードもサポートしなければならない。これらすべてが、本番サービスに影響を与えないように実施できなければならず、だからこそ運用性と拡張性の共存が「極めて重要だ」と強調する。
さらにスケールアップの際にも、システムに影響を及ぼしてはいけない。ハードウェアを修理したり、アップデートを行ったりと、これらの作業が行われる間もデータの整合性に影響を与えず、データを失うことはもちろん、破損も許されない。計画的なメンテナンスを実施するときも、ユーザーにそれを感じさせてはいけないという。「問題が生じた際には、ユーザーに影響を及ぼすことなく対処できなければなりません。たとえ計画していないイベントが発生しても、システムが落ちるようなことは許されません」とSinghai氏。こうした厳格な要件を満たしながらTiDBのクラスターを拡張しようとすると、「PD（Placement Driver）」がボトルネックになったと説明する。
PDは、TiDBクラスターを管理するための核となるもので、これがボトルネックとなる要素は2つあるという。1つがクラスターの各サーバーの死活監視を行う「ハートビート」、もう1つはクエリごとにタイムスタンプを割り当てる「TSO（TimeStamp Oracle）」だ。
LinkedInでは、TSOの限界をテストした結果、PDへのgRPCリクエストは約20万QPSが最大となった。各gRPCリクエストがPDに投げられる際には、バッチ処理のように複数のQPSを代表する形となる。たとえば、20万QPSが最大のgRPCリクエストであれば、10倍の200万QPSがシステム全体のQPSだ。このときワークロードを変えて実験すると、10万リクエストでのレイテンシーは0.4ミリ秒、CPU利用率も30％前後と良好だったが、20万リクエストになるとPDリソースが飽和状態となり、レイテンシーも2ミリ秒、CPU利用率も75％まで上昇することが分かったという。
[画像クリックで拡大]
これはロック・コンテンションがボトルネックとなっているためで、対策にはスケールアップが考えられる。単純に性能の高いマシンを使うことでQPSを改善できるだけでなく、TSOフォロワーも有効になるだろう。これにより、PDマシンのワークロードを少し開放でき、CPUにも余裕が出る。
もう1つの対策は、“待つこと”だ。時間をかけてより大きなバッチにすることで、リソースの効率化を図るという方法だ。もちろん、レイテンシーは少し高くなるが、PDの拡張性は改善できる。今後のTiDBのリリースでは、PDのワークロードを分離するマイクロサービス化が予定されており、それにより拡張性のさらなる改善にも期待しているとSinghai氏は言う。
また、ハートビートでのボトルネックも似たような状態だ。クラスターに複数のシャードがあり、それぞれのやり取りに時間がかかってしまう。LinkedInの実験では、1分間あたり1000万ハートビートまではサポートできたが、ロック・コンテンションの影響でこれ以上の値は超えられなかったという。そこで有効な対策は、リソースを追加しコアを増やすこと、そしてリージョンのサイズを大きくしてリージョン数を減らす方法だとSinghai氏。
加えて、ハートビートの間隔を空けることも有効だ。あまりアクティブでないリージョンをハイバネーション（休止）することも、拡張性の改善につながる。他にもGo言語自体がボトルネックになることは分かっているが、オープンソースのコミュニティで対策されているため解決するとした。
大規模データセットのロードとレプリケーションの課題
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を強くしていきたいと言うのだった。
