1年以上にわたり検証してわかった課題と対策
記事公開日：2024年8月20日
2024年7月3日、オープンソースの分散型NewSQLデータベースである「TiDB」のユーザーが集い、情報交換を行うイベント「TiDB User Day 2024」が都内会場およびオンラインで開催された。LinkedIn Corporation SW Engineering DirectorであるAshish Singhai氏は、「Learnings from Experimenting with TiDB at Scale」と題し、世界最大級のビジネスSNSであるLinkedInが、膨大なデータを扱う基盤としてTiDBを採用し、その検証で得られた知見について詳しく説明した。
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氏は、「サービス停止は許されず、計画的なメンテナンス時間すら設けることができません。また、複数のアプリケーションやデータセットが存在し、多くのチームがデータを扱うため、システムは非常に複雑です。そのため、複数の利用者がそれぞれ独立してデータベースを利用できる、マルチテナンシーに対応することも重要です」と語る。
Ashish Singhai氏 LinkedIn Corporation, SW Engineering Director
この大規模かつ複雑なシステム運用環境は、常に変化する点も特徴的だ。たとえば、ハードウェアが故障して再インストールが行われたり、クラスターを拡張するソフトウェアが導入されたりすることもある。つまり、日々変化があるような環境では、“オペラビリティ（運用性）”を担保せねばならず、拡張性が高くとも運用性が低ければ意味はないのだ。「自己修復ができ、信頼性とレジリエンスが備わった環境でなければなりません」とSinghai氏は言う。
LinkedInで求められるシステム要件
このような複雑な環境を支えるため、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％まで上昇することが分かったという。
TSO検証時のレイテンシーやCPU使用率などを比較
これはロック・コンテンションがボトルネックとなっているためで、対策にはスケールアップが考えられる。単純に性能の高いマシンを使うことでQPSを改善できるだけでなく、TSOフォロワーも有効になるだろう。これにより、PDマシンのワークロードを少し開放でき、CPUにも余裕が出る。
もう1つの対策は、“待つこと”だ。時間をかけてより大きなバッチにすることで、リソースの効率化を図るという方法だ。もちろん、レイテンシーは少し高くなるが、PDの拡張性は改善できる。今後のTiDBのリリースでは、PDのワークロードを分離するマイクロサービス化が予定されており、それにより拡張性のさらなる改善にも期待しているとSinghai氏は言う。
また、ハートビートでのボトルネックも似たような状態だ。クラスターに複数のシャードがあり、それぞれのやり取りに時間がかかってしまう。LinkedInの実験では、1分間あたり1000万ハートビートまではサポートできたが、ロック・コンテンションの影響でこれ以上の値は超えられなかったという。そこで有効な対策は、リソースを追加しコアを増やすこと、そしてリージョンのサイズを大きくしてリージョン数を減らす方法だとSinghai氏。
加えて、ハートビートの間隔を空けることも有効だ。あまりアクティブでないリージョンをハイバネーション（休止）することも、拡張性の改善につながる。他にもGo言語自体がボトルネックになることは分かっているが、オープンソースのコミュニティで対策されているため解決するとした。
出典：EnterpriseZine / DB Online – 「10億人規模SNSを支えるTiDBの超大規模クラスター環境、LinkedInはいかに実現しているのか」(2024年8月20日)
