NRDB: 世界最大のテレメトリデータベースを支える3つの設計原則

New Relicの心臓部であるNRDBについて解説した記事、“NRDB: Three Design Principles Behind The World’s Most Powerful Telemetry Database” の翻訳です。


ローンチの日。何年もの努力がこの瞬間に費やされてきました。あなたは、製品の細部にまでこだわり、技術スタックを準備するために疲れを知らずに働いてきました。リリースの準備は整っています。最後に心配なのは、そう、モニタリングプラットフォームです。

しかし、あまりにも頻繁に行われるローンチは手に汗握る瞬間の連続であり、複雑なモニタリング設定がそれに拍車をかけています。何かがうまくいかなかったら?特殊なツールの海の中でパズルのピースを眺めながら、どこが悪いか見つけられる?正しい情報を正しいフォーマットで記録できていて、出てくるであろう質問に答えられる?データパイプラインは、データ量の増加に合わせてスケールできるように構築されていますか?

別の方法があります。モニタリングは不安を増やすのではなく、不安を減らすべきだ、私達はそう考えています。すべてのデータは一箇所に集められ、接続されているべきです。ツールによって、質問されるだろうと想像していなかったような質問にも、素早く答えられるようになります。そして、モニタリングのスケールアップは私たちの問題であり、あなたの問題ではありません。

このブログでは、New Relic Oneプラットフォームを支えるデータベースとその設計原理、ミリ秒単位のパフォーマンスをどのように実現しているのか、そして極大日に対してどのようにサポートできるのかを紹介いたします。

3つの設計原則

New RelicはSaaS APMの先駆者として、お客様のデッドライン、スポーツイベント、製品の発売などなどを10年以上にわたってサポートしてきました。その経験は、New Relicが構築したすべての製品に生かされていますが、その中心となっているのが、世界で最も強力なテレメトリデータベースである New Relic Database (NRDB) です。NRDBは、毎分10億イベント以上のテレメトリデータを取り込み、世界中の18万以上のアカウントのニーズに応えています。そのユニークなパワーは、3つの設計原則を遵守していることに由来しています。

  1. 観測性(オブザーバビリティ)には統合されたテレメトリデータベースが必要
  2. リアルタイムの調査にはスピードと柔軟性の両立が必要
  3. ダイナミックな需要には無制限のスケーラビリティが必要

観測性には統合されたテレメトリデータベースが必要

NRDB は、メトリクス、イベント、ログ、トレースを統合されたデータベースで結合することによって、テクノロジースタックの完全なビューを提供し、ビジネスに影響を与える問題を特定、理解、解決することを実現しています。システムをオンラインに戻すのに数分、あるいは数時間を無駄にしている間に、複数のシステムを調べて干し草の中から針を探す、そのような仕事はもう必要ありません。 New Relic Query Language (NRQL) を使用すると、単一のインターフェイスで NRDB 内のすべてのデータを検索することができます。

リアルタイムの調査にはスピードと柔軟性の両立が必要

ほとんどのデータベースでは、スピードと柔軟性のどちらかを選択する必要があります。スキーマとインデックスを適切に定義していれば、素早くレスポンスが得られるでしょう。もしくは、様々な形のクエリを送る想定であれば、レスポンスが遅くなるのを我慢する必要があるかもしれません。

現代的世界に存在する複雑な分散システム、マイクロサービス、短命なインフラストラクチャでは、投げられるであろうすべてのクエリを予測することは不可能です。トラブルが発生したときには、考えたこともなかったクエリに応答する必要があるかもしれません。スキーマレスで素早いクエリ応答性能を持ち、インデックス定義が不要でアドホックなクエリにも対応でき、そしてスピードと柔軟性のどちらも手にすることができる、それが NRDB をゼロから構築した理由です。

NRDBがミリ秒の性能を実現する方法

定義されたインデックスが使えないクエリへのレスポンスには、膨大な量のデータを処理する必要があります。そのため、NRDBでは速度と並列化のための最適化がなされています。NRDBは秒間何千ものクエリを処理して、数テラバイトのデータを保持している利用者にレスポンスを返しています。検索のためにデータを移動させるのは筋の悪い選択で、その代わり、クエリをデータに移動させています。

すべての NRDB クエリは、クエリルータから始まります。クエリルータは、クラスタ内のデータを見つけて、処理するクエリを数百、あるいは数千のワーカーに送信して、関連するデータがどこに存在するかをスキャンします。NRDBのマルチテナントクラスターでは、メモリとIOの消費バランスをとるため、大きなクエリは小さな断片に分割されます。分割されたクエリの断片は他のルーターに送られ、データを保持しているワーカーにクエリの断片を配信します。NRDB のインメモリキャッシュは、最近実行されたクエリに対して素早く結果を返したり、あまり頻繁にはリクエストされないクエリ対してはワーカーがディスクからデータをスキャンして対応したりします。各ワーカーがクエリを処理するためにファイルを読み込むと、プロセスは逆順になります。最初に、各ファイルの結果がワーカー上でマージされます。次に、元のルーターがすべてのデータを持っている状態になるまで、ルータは再帰的に各ワーカーの結果はをマージして、完成した結果がユーザーに返されます。

ダイナミックな需要には無制限のスケーラビリティが必要

New Relicは世界中のお客様の予測不可能な需要をサポートするために、NRDBを無制限にスケーリングするように設計しました。New Relicの顧客は小売からエンターテイメント、アパレルからヘルスケア、ゲームからEコマースに至るまで、過去10年間で成長してきました。NRDBはスケーリングされており、ローカルな需要の急増による全体的な影響を最小限に抑えています。NRDBは毎分10億イベント以上のデータを取り込んでおり、トラフィックが急激に増加した顧客がいたとしても、NRDBは何百万イベントのデータ増加くらいは簡単に処理します。

NRDBはあなたのビジネスの役に立つ

クエリの中央値が60ミリ秒という超高速なレスポンスと、1回のクエリで500億以上のイベントを分析する機能を備えたNRDBによって、最大の干し草の山の中から針を見つけることができます。また、マルチテナントアーキテクチャを採用しているため、小規模のお客様でも大規模なユーザーと同じ大規模なコンピューティングリソースの恩恵を受けることができます。さらに、NRDB は以下の機能を提供します。

  • 単一のクエリインターフェイス: NRQLを使用して、すべてのテレメトリデータをクエリできる
  • インテリジェンス: すべてのデータソースにまたがったインサイトを結びつけられる
  • パフォーマンス: 数百億単位のデータをミリ秒単位でクエリして、結果を得られる
  • 弾力性: ビジネスを拡張に応じて、安心してデータリテンションを拡張できる
  • 予測可能なコスト: 必要なものだけを支払う

世界で最も強力な遠隔測定データベースがどのようにしてNew Relicプラットフォームを支えているのかについては、Inside NRDB: A Flexible, Unified Database Built to Scaleをお見逃しなく。

この投稿には、連邦証券法で定義されている「将来の見通し」に関する記述が含まれています。これには、New Relic Database (NRDB) の市場動向や機会に関する記述、および NRDB が現在および将来の New Relic のお客様に提供する可能性のある利益に関する記述が含まれますが、これに限定されません。このような将来の見通しに関する記述でカバーされている事項の達成または成功は、 New Relic の現在の仮定、期待、信念に基づくものであり、 New Relic の実際の結果、パフォーマンス、または成果が将来の見通しに関する記述で明示または暗示されているものと大きく異なる可能性のある実質的なリスク、不確実性、仮定、および状況の変化の影響を受ける可能性があります。New Relic の財務およびその他の業績、ならびに本投稿の将来の見通しに関する記述に影響を与える可能性のある要因に関する詳細な情報は、New Relic が SEC に随時提出している資料に含まれています。これらの文書のコピーは、New RelicのInvestor Relationsのウェブサイト(http://ir.newrelic.com)またはSECのウェブサイト(www.sec.gov)で入手することができます。New Relic は、法律で義務付けられている場合を除き、これらの将来の見通しに関する記述を更新する義務を負わず、また更新する意図もありません。

kotani@newrelic.com'

New Relicではシニア・カスタマーサクセス・マネージャーとして、New Relicプラットフォームを使い倒していただく係をしています。それまでは業務システム業界でSEとして7年の経験を積んだ後、広告配信サービスを構築・運用をリーダー/CTOとして8年ほど経験し、スクラッチからのアプリケーション開発、クラウド利用推進、開発組織の改善などなどやってました。よく使う言語はScala, Go。好きなビルドツールはMakeです。 View posts by .