このブログ記事では、AlibabaがTSDBを使って、W11 ショッピングフェスティバル(独身の日)をサポートするための高効率なリアルタイム監視システムを構築したことについて紹介します。
Alibabaのシニア開発エンジニアであるChai Wu氏は、長年にわたりAPM SaaS製品の研究開発に携わってきました。彼は、Druid、ClickHouse、InfluxDBなど、業界をリードする複数の時系列データベースを使用してきました。長年の時系列データベースの経験を活かし、現在はAlibabaでTSDBのコアエンジンの開発に取り組んでいます。
本記事は同氏の講演をもとに、主に以下のトピックのうち最初の3つを取り上げています。
1、時系列サービスの概要
2、TSDB
3、コア技術
4、まとめと展望
時系列サービスの概要
2016年にTSDBがサービスインしてから3年が経過し、TSDBは3回のAlibaba W11(独身の日)プロモイベントをサポートするために利用されています。Alibabaでは、2016年がTSDBの最初の年でした。2017年は、TSDBがAlibaba社内で広く使われるようになりました。次の図は、2017年と2018年の大きなプロモイベントにおけるTSDBのスループット性能を示しています。書き込みスループットは、2017年の2,000万TPSから2018年の4,000万TPSへと倍増しました。また、ピーク時のクエリ性能は8000QPSから2万QPSに向上しました。これはAlibabaのコアビジネスのスループット情報であり、1日の時系列データは平均で800TBになります。時系列データは数百億点の時間で構成され、Alibabaグループの130以上のサービスをカバーしています。
時系列サービスのシナリオ
時系列サービスは、インフラから上位層のアプリケーションまで、すべての主要なシステム層に関わっています。インフラ層では、主に物理的なマシンやOSの監視を行います。基本的な保守層には、Sunfire、CloudMonitor、GOCなどがあります。Sunfireは、Alibabaの統合的な監視・ログそしてアラートシステムです。CloudMonitorは、Alibaba Cloudの統合監視システムです。GOCは、グローバルな緊急スケジューリングオペレーションシステムで、アラートデータや障害評価データを含んでいます。リソーススケジューリングシステムには、現在サービス中のスケジューリングシステムや人気の高いKubernetesなど、多数のコンテナが存在しています。クラスタ管理層で最も著名なサービスはDBPaaSで、すべてのAlibabaデータベースインスタンスの監視とスケジューリングを担当しており、TPSは数千万に達しています。上位層のアプリケーションには、主にIoTアプリケーションシナリオ（Hema FreshやCainiao IoTなど）、APMシナリオ（GoldenEyeやeコマースのメトリクス監視 ）、セキュリティ部門のコアエンドツーエンド監視などが含まれます。対象となるアプリケーションシナリオは、DCから上位層のSaaSまで様々です。
課題
現在、時系列データベースは、ビジネス側の要件や課題など、多くの課題に直面しています。例えば、APMアプリ「Taobao Magic Rabbit」では、エンドユーザーとのやり取りが発生します。このアプリは、高頻度かつ低レイテンシーのクエリが課題となる可能性があります。また、OLAPシステムや分散システムの多くは、大量のデータを長期的かつ多次元的に集約して分析します。時系列データベース特有の拡散したタイムラインも、大量のタイムラインをどのように集約するかなどの課題があります。また、W11(独身の日)プロモーションイベント時の高トラフィックの影響も、時系列データベースの容量に大きな課題を与えています。
TSDB
TSDBのアーキテクチャ
Alibaba Group自体で使用されているTSDBと、Alibaba Cloudで公開されているTSDBは、同じアーキテクチャを使用していますが、異なる機能を持っています。次の図は、コレクション側のTSDB、サーバー側のTSDB、そしてユーザーに関係の深いプロトコル（可視化、Grafanaの表示、時系列インサイト）を示しています。時系列インサイトでは、時系列データをインポートして直接閲覧・分析することができます)。コレクション側には、一連のエッジ・コンピューティング・ソリューションが実装されています。エッジコンピューティングは、主にIoTシナリオや、リソースが限られていたり不安定な環境で適用されます。エッジ・コンピューティングは、サーバー上のTSDBと相互に接続されています。サーバー上のTSDBは、エッジとクラウドの統合を実現するために、ルールを直接発行し、エッジデータのクリーンアップとコンピューティングを実行することができます。
時系列エンジンのアーキテクチャ全体には、たくさんのコンテンツが含まれています。コアとは、基礎となるTSDBのコア時系列エンジンのことです。上位層には、コンピューティングエンジン、TSQLエンジン、インテリジェント分析エンジンがあります。基盤となるTSDBのコア時系列エンジンは、時系列インデクシング、ストリームデータアグリゲート、ストレージエンジン、安定性管理といった複数のモジュールで構成されています。時系列インデクシングとは、タイムラインのクエリとフィルタリングを意味します。ストリームデータアグリゲートは、大量のデータを効率的にアグリゲート分析する方法を指します。ストレージエンジンは、大量の時系列データを保存するためのソリューションを提供します。安定性管理はAlibabaの最優先事項です。安定性管理では、TSDBがAlibabaグループ内やクラウド上で長期間安定して動作することを保証する方法を扱います。計算エンジンは、Alibabaが独自に開発した時系列ストリーム計算エンジンで、事前集計、ダウンサンプリング、連続クエリを行います。連続クエリは、アラートや複雑なイベント分析のシナリオでよく使われます。TSQLエンジンもAlibabaが開発したもので、分散型のエクゼキュータとオプティマイザを内蔵しています。TSQLエンジンは、時系列解析機能を拡張し、ユーザーのアプリケーションの閾値を下げることができます。インテリジェンス・エンジンは、学習または生成されたモデル・アルゴリズム・ライブラリと、カスタマイズされた業界ソリューションを提供します。
TSDBの機能比較
ダイナミックスキーマのサポート。ほとんどすべてのNoSQLデータベースはタグの書き込みをサポートしています。しかし、TimescaleDBは伝統的なリレーショナルデータベースであるPostgresをベースにしているため、動的なスキーマをサポートしていません。
多値モデル。多値モデルは、時系列シナリオでの書き込み速度を大幅に向上させることができます。例えば、風力発電所のモニタリングでは、通常、風向と風速の2つのメトリクスを使用します。この場合、2つのメトリクスを同時に書くことは、単一値モデルで1つのメトリクスを一度に書くよりもはるかに優れています。さらに、多値モデルは上位層のSQLモデルとの親和性が高く、例えば、selectクエリを作成する場合に、複数の値に基づいて分析を行うことができます。
時系列インデックス。比較的、OpenTSDBはHBaseをベースにしたフィルタリングを実装しており、時系列インデックスを持っていません。しかし、TSDBやInfluxDBのようなデータベースでは、クエリの効率を最適化するために時系列インデックスを提供しています。
事前のアグリゲーションとダウンサンプリング Facebook Gorillaが開発されてから、時系列圧縮が注目されるようになりました。時系列データの特徴に応じて適切な圧縮を行うことができます。例えば、タイムスタンプが連続していてデータが安定している場合、delta-of-deltaやxorを使った時系列圧縮は、一般的な圧縮よりもはるかに効率的です。
SQL機能。SQLインターフェースは、ユーザーがTSDBを利用する際の敷居を下げ、SQLに慣れたユーザーが時系列モデルを直接利用できるようにします。また、SQLインターフェースは、SQLの力を利用して時系列解析などの機能を拡張することができます。
クラスタ機能。InfluxDBは、いくつかの高可用性とクラスタソリューションを提供しています。ただし、安定した高可用性ソリューションは有料版で提供されます。TimescaleDBのクラスタ機能はまだ開発中です。OpenTSDBはHadoopのエコシステムに基づいているので、スケーラビリティは問題にならないはずです。
2018年の「W11(独身の日)」イベントにおいて、TSDBはどのようなサポートを行っているでしょうか？ まず、異なるビジネスサイドの要求を満たすことができる一連のソリューションを提供します。高頻度かつ低レイテンシーのクエリ、高性能なアグリゲーション、大量データの低コストなストレージ、大量のタイムラインの管理をサポートします。また、機能モデルでは、時系列インデックスを最適化し、KVストレージをベースにしたインデックスを作成することで、無制限のタイムラインの読み書きを実現しています。高頻度かつ低レイテンシーのクエリをサポートするために、Facebook Gorillaを参考にして、分散キャッシュストレージシステムを実装しています。最後に、コンピューティングエンジンです。技術的には、時系列インデックスの最適化、ストリームアグリゲートエンジン、プレアグリゲートとダウンサンプリング、ワークロードマネジメント、そして自社開発の時系列圧縮に注力しています。
TSDBのコア技術
大量の時系列データのストレージ
低コストのストレージを実現するには？次の図は、W11(独身の日)イベントの際の実際のアプリケーションシナリオです。
DBPaaSは、Alibabaグループのすべてのデータベースインスタンスの監視と分析に使用されています。これには、すべての基礎となるマシン、コンテナ、およびオペレーティングシステムのさまざまなメトリクスと、上位層のデータベースインスタンスの多くのメトリクスが含まれます。これらのメトリクスはすべて、統一されたクエリと分析のために一連のデータベースに保存されます。DBPaaSには、毎年開催されるW11(独身の日)イベント時のデータベースパフォーマンスデータも保存されています。毎年のW11(独身の日)の詳細なデータは、一連のデータベースに保存されます。DBPaaSには大きな課題があります。まず、DBPaaSはすべてのデータベースインスタンスを監視し、W11(独身の日)イベントの際には、これらのリアルタイム指標をAlibabaのコアオペレーションセンターのダッシュボードに統合する必要があるため、ダッシュボードの表示をいかに正確に、タイムリーに、安定して行うかがTSDBにとって大きな課題となります。もう1つの課題は、平均書き込み速度が1000w TPS、ピーク速度が1400w+ TPSであるW11イベント中に、大量のデータをどのように保存するかです。さらに、毎日何百TBものデータが生成されます。このような大量のデータを保存すること自体が大きな課題となっています。
時系列データの圧縮
下図の左部分はテーブルで、各行が時系列を表しています。テーブルの構造は、OpenTSDBのテーブルと同じです。KVは時系列モデルの特異性から、通常このように設計されています。
0から3600までの数字は、過去1時間のデータを表しています。データは1秒ごとに収集されます。つまり、各データ行には合計3600個の列が含まれ、各列には値があります。OpenTSDBでは、データは圧縮されずに保存されます。ミリ秒ごとにデータを収集する場合、1つのデータ行には360万列が必要です。時間のウィンドウはまだ調整できますが、多くの制限があります。Facebook Gorillaを参考にしたAlibabaは、ストレージ層に時系列圧縮アルゴリズムを導入しました。すべてのタイムスタンプと値は、カラムをマージすることで2つの大きなデータブロックに集約されます。時系列圧縮アルゴリズムは、データブロックの圧縮に使用されます。その後、基礎となるKVストレージで一般的なブロック圧縮が行われます。全体の圧縮率は、実際のオンラインビジネスのデータに基づいて計算され、最大で15:1になります。具体的には、タイムスタンプにはdelta-delta、float型にはXORエンコーディング、integer型にはシンプルな可変長エンコーディング、string型には一般的な圧縮を使用しています。注：非可逆圧縮アルゴリズムもサポートされていますが、Alibabaではいくつかの特殊な要件のために使用されていません。
次の図は、実際のビジネスシナリオにおけるデータ圧縮の効果を示しています。合計6TBのデータが、一般的なブロック圧縮アルゴリズムを使用することで715GBに圧縮され、10倍以上のサイズ削減に成功しています。
時系列圧縮とブロック圧縮を組み合わせることで、この容量のデータを413GBに圧縮することができ、約15:1の圧縮率を実現しました。ブロック圧縮のみの場合と比較して、時系列圧縮とブロック圧縮の組み合わせでは、圧縮効果が40%向上しており、ストレージコストの削減に大きな意味があります。また、時系列圧縮はブロック圧縮の前に行われ、時系列圧縮後のデータサイズはすでに非常に小さいため、ブロック圧縮の効果が影響を受けないという利点もあります。大規模なクエリのシナリオでは、RTが半分になります。長い時間範囲のデータをスキャンする場合、データはすでに高度に圧縮されています。そのため、I/O効率は非常に高く、RTも半分程度に抑えることができます。
プレアグリゲーションとダウンサンプリング
データのダウンサンプリングと時間間隔によるデータのグルーピング
例えば、お客様に異なる時間間隔のレポートを作成し、年、月、週ごとに詳細なデータを見ることができるようにします。これがドリルダウンのプロセスです。詳細データからすぐに集計を行うためにTSDBを直接使用すると、ユーザーエクスペリエンスが低下し、応答時間が長くなります。
大量のデータの集計や統計解析。例えば、過去6ヶ月間のデータに対して、合計、最小、最大の演算や、P99/P55の統計を行う。これらのシナリオは多くの計算を必要とするため、すべての詳細データから直接集約を実装することは不可能です。
タイムライン参加
例えば、成功したトランザクション、失敗したトランザクション、および合計トランザクションをカウントし、成功率を計算します。データの収集は、収集側から表示側までシステマティックに行われるため、収集側の収集ソースを直接変更すると、柔軟性が損なわれる可能性があります。そのため、複数のタイムラインの結合操作をサポートするエンジンが必要となります。
リアルタイム例外検出とリアルタイム・コンピューティング
例えば、メンテナンスダッシュボードで正確なリアルタイムデータを提供し、お客様に例外的なデータポイントを送って警告します。
次の図に示すソリューションは、コンピューティングエンジンとストレージエンジンの両方を含んでいます。Alibabaバは、時系列ストリームのコンピューティングエンジンを独自に開発しています。TSDBは、Alibaba Cloud上のパブリッククラウドの顧客やプライベートクラウドの顧客だけでなく、Alibaba Groupの内部顧客にもサービスを提供する必要があります。異なるシナリオでは、リソースの配置には異なる限界があります。これを考慮して、我々は独自の時系列蒸気コンピューティングエンジンのためのセマンティックフレームワークを設計しました。Flink、Spark、JVMメモリが下層でサポートされています。大規模な計算も小規模な計算も実装可能です。
これに基づいて、時系列エンジンは連続的なクエリの機能を提供します。データストリームの時系列データを直接照会して分析し、複雑なイベントの警告や分析を行うことができます。時系列ストリーム計算エンジンは、TSDBと相互に接続されています。ユーザーがTSDBにデータを書き込むと、部分的なデータがストリーム・コンピューティング・エンジンに転送されます。ユーザーはTSDBを操作して、ダウンサンプリングが必要なデータや事前に集計が必要なデータを適切に判断することができます。
さらに、ユーザーはいくつかのアラート・ルールを設定し、そのルールをTSDBに配信することができます。TSDBはアラートを実施するために、時系列ストリームコンピューティングでの連続クエリのルールを送信します。TSDBは詳細データを、時系列ストリームコンピューティングはサマリーデータ（ダウンサンプリング、プレアグリゲーション後のデータ）を書き込みます。TSDBは詳細データを、時系列計算はサマリーデータ（ダウンサンプリング、事前集計後のデータ）を書き込みます。上位層では、min, max, sum, count, p99, P95, median statistics などの集計演算子をサポートしています。また、複数のタイムラインを結合したり、順序付けされていないデータや重複したデータを書き込むことも可能です。
高頻度かつ低レイテンシーのクエリ
モバイルAPMアプリケーションとして、Taobao Magic RabbitはAlibabaの500以上のモバイルアプリのデータ分析とモニタリングをサポートします。モバイルAPMは、読み書きのスループットとユーザーのインタラクションの関連性が特徴です。モバイルAPMのデータは、トランザクションの時系列データです。例えば、W11(独身の日)中にプロモーションイベントが発表されると、多くのユーザーが特定の機能に同時にアクセスすることで、膨大な量のバーストトラフィックが発生します。
W11(独身の日)イベント中、Taobao Magic Rabbitが監視するクエリピークは最大4,000QPSです。次の図は、書き込みトラフィックが平均600,000TPSからピーク時には6,000,000TPSに増加していることを示しています（トラフィックの10倍増）。また、ビジネス・サイドでTSDBに従って行われるリアルタイム・ポリシーや決定は、モバイル・アプリケーションのユーザー・エクスペリエンスに直接影響を与えます。そのため、ビジネスサイドでは、TSDBのRTが20ms以下であることが求められます。このようなシナリオでは、OpenTSDBのような従来のTSDBでは、HBaseでクエリを実行する際のI/Oパスが長すぎて、クエリ処理中に多くのディザリングやグリッチが発生します。このような状況で、OLAPシステムが99%の読み書き操作のRTを20ms以下にすることは非常に困難です。
高頻度かつ低レイテンシーのクエリをサポートするために、Facebook Gorillaを参考にして、Javaベースの分散キャッシュソリューションを設計しました。クラスターはZooKeeperをベースにシャーディングと容量調整を実装し、ダイナミックなスケーリングをサポートします。W11(独身の日)のイベント期間中、このソリューションは1,000万TPS以上（トラフィックが10倍に増加）をサポートしました。このソリューションの鍵は、TSEmノードの設計にあります。TSMemは、まず2つの課題を解決する必要があります。1つ目は高いスループットを実現する方法、2つ目は99%のクエリのRTを20ms以下にして低レイテンシーを実現する方法です。
TSMemは、Disruptorフレームワークに基づいて、RingBufferでユーザーの同時読み取り/書き込み要求をステージングします。TSMemは、「複数のプロデューサと1つのコンシューマ」モードを採用しています。1つのコンシューマーがユーザーのリクエストを消費した後、そのクエストは対応するワーカスレッドに割り当てられます。ワーカースレッドプールの各スレッドは、時系列のキャッシュシャードに対応しています。したがって、これは実際にはDisruptorに基づいたメモリシャーディングです。1つのワーカスレッドが1つのシャードに対応するため、ロックなどのリソースの競合を考慮する必要がありません。
また、読み込み要求と書き込み要求は同じリンクに割り当てられ、同じワーカースレッドで処理されるため、ロックフリーでの読み書きが可能です。RingBufferのバッチ機能を使えば、単純な書き込みや小さな書き込みのバッチを、RingBufferを通じて1つの大きなバッチに蓄積することができます。そして、ワーカースレッドで1つのバッチ操作を行うことで、スループットを大幅に向上させることができます。また、効率的なメモリ管理と不具合の少ないRTをいかに確保するかという課題もあります。まず、JVMのGCの影響を減らし、すべての時系列データを時系列ブロックに入れ、参照回数に基づいてチャンクプール管理を行う必要があります。これにより、一時的なオブジェクトを多く作りすぎないようにしています。そのため、GC全体が比較的安定しています。この方法により、作成されるデータブロックの数とオーバーヘッドが削減されます。また、極端な状況下で、大きな新しい時系列ブロックへの予期せぬリクエストによって生じるレイテンシーの振動も回避できます。
効率的な集計分析
Sunfireは、Alibabaが提供するログ収集・基本監視・アラートの統合プラットフォームです。Alibabaグループの5万以上のアプリケーションを網羅しています。監視指標は、インフラから、IaaS、PaaS、SaaS、無線アプリケーションなどの上位層のアプリケーションまでカバーしています。これらのシナリオでは、アプリケーションの膨大な範囲、ビジネスの複雑さ、大量のデータ量のために、1秒間に大量の時系列データをスキャンする必要があることが主な課題です。例えば、W11(独身の日)中に事前にサービスをスケールアウトします。
新しいマシンのバッチを追加することは、新しい時系列のバッチを作成することに相当します。1秒間に何十万もの時系列を作成することができます。次の図は、1日に新しいマシンのバッチを追加した後の消費プロセス全体を示しています。W11(独身の日)プロモ中のタイムラインの累積数は60億で、さらに増え続けています。1秒間に500万点の時間をスキャンするという要件を満たすにはどうすればよいのでしょうか。
OpenTSDBのメモリ上で集計処理を行い、ユーザーのクエリに直接応答すると、すべてのタイムポイントをメモリ上に置かなければならず、大きな不安定性が生じます。また、タイムラインの作成速度の問題もあります。例えば、OpenTSDBはUIDテーブルをベースにしているため、辞書テーブルのアトミック操作には1つの性能上のボトルネック（約20万TPS）があり、ビジネス展開の妨げになります。
時系列インデックス
高次元集計分析には、TSDBの2つの内部モデル、ストリーム集計エンジンと時系列インデックスがあります。時系列インデックスは、インデックスとインデックス推定器の2つの部分から構成されています。次の図は、時系列インデックスのクエリ処理の全体像を示しています。まず、クエリのパーシングが行われます。次に、推定器がクエリの最適化に使用されます。実際のクエリのステップは、時系列インデックスによって実行されます。最後に、タイムラインが返されます。ストリーム集約エンジンは、基礎となる時系列ストレージ内で、取得した時間範囲に該当するすべての時系列データを抽出します。その後、データはダウンサンプリングされ、事前に集計された後、最終結果がユーザーに返されます。
次の図は、タイムラインのライフサイクルを示しています。異なるフェーズでは、いくつかのタイムラインが失効し、いくつかの新しいタイムラインが作成されることがあります。ユーザーがt2とt3の間の時系列データを照会するとき、t0とt2の間に期限切れとなったタイムラインを照会したくはありません。タイムラインが1つ増えると、ストリーム集約エンジンが下層のストレージからデータポイントを抽出する際に、I/O操作を1つ実行しなければならないことになります。バージョン1.3より前のInfluxDBでは、フルメモリ・タイムライン・インデックスが採用されています。フルメモリ・タイムライン・インデックスは時間範囲をフィルタリングしません。ユーザーがt2とt3の間のデータを照会すると、すべてのタイムラインが返されます。バージョン1.3以降のInfluxDBのインデックスはファイルベースであり、2つのタイムラインを直接返すことができるため、パフォーマンスが大幅に向上します。
InfluxDBが時系列インデックスを実装しているように、私たちのTSDBでもKVに基づいたインデックスを実装しています（基本的には転置インデックス）。 時系列インデックスの特徴として、タイムスタンプに転置インデックスが追加されることが挙げられます。転置インデックスがタイムスタンプに付加されると、インデックスクエリを実行する際に、対象となるタイムラインをまずタグと値でフィルタリングし、その後、時間次元で再度データをフィルタリングすることができるようになります。これにより、フィルタリングの効果が向上します。また、転置インデックスがKVストレージに永続化されると、インデックスノードはステートレスに動作するようになり、水平方向のスケーリングやタイムラインのTTLがサポートされます。
次の図は、時系列インデックスの推定量を示しています。estimatorは、ユーザーが時系列インデックスにクエリを実行する際に、より高いクエリ効率を実現するためのものです。推定器のデータは、以下の3つのソースから得られます。転置インデックスのタグや復帰インデックス全体が何本のタイムラインを持っているかなどのハイパーログカウンター、特定のタイムラインが存在するかどうかを記録するBloomFilter、そしてメモリ上の時系列インデックスキャッシュです。問い合わせの際には、まず、転置インデックス全体の比較的小さなコレクションに対して演算を行い、演算や問い合わせ条件を優先度順に並べ替えることになります。
ユーザが等価クエリとファジーマッチングを選択した場合、まず精度の高い等価クエリを行い、同時にコレクションサイズの比較も行います。例えば、ユーザーがデータセンター次元とIP次元の2つの条件を提供した場合、IP次元に対応するタグはより多くのタイムラインを持ち、より高いフィルタ効率を提供するため、推定装置は最初にIP次元でクエリを実行します。BloomFilter と HLL は大まかな統計量を実装しているが、2つの検索条件に対応するコレクションが桁違いに異なる場合、検索効率を大幅に向上させることができます。また、BloomFilter でタイムラインが存在しないと判断された場合、クエリ全体が直ちに停止します。
ストリームアグリゲートエンジン
前述のプレアグリゲーションとダウンサンプリングは、TSDBにデータが書き込まれる前に行われます。ストリーム集約エンジンは、ユーザーがTSDBプロセスでデータを照会する際に使用される集約・計算エンジンです。ストリームアグリゲートエンジンは、パイプラインソリューションに基づいて設計されています。パイプラインにはさまざまなステップがあります。10種類以上のコア・アグリゲーション演算子、20種類以上のフィリング・ポリシー、10種類以上の挿入アルゴリズムを提供しています。複雑なユーザーのクエリは、シンプルな演算子の組み合わせに変換することができます。この変換結果により、クエリ全体の結果の正確性を確保することができます。
前述のように、時系列インデックスでクエリされたタイムラインは、ストリームアグリゲートエンジンに送られ、特定の時系列データが時系列データストレージから抽出されます。ダウンサンプリング、補完、集約などの操作は、ユーザーのクエリ基準に基づいて実行されます。パイプライン全体に含まれるのは、先に挙げた演算子だけではありません。topN、limit、interpolationなどの演算子も含まれています。緩い結合の設計により、良好なスケーラビリティを実現しています。
また、パイプライン全体では、データベースからデータを小分けにして抽出し、抽出したデータをストリームエンジンのオペレータに送ります。得られた小さなデータのバッチは、メモリに列挙された形で保存されます。各演算子は良好な性能を示しています。さらに、メモリ内のストリーム集約エンジンは、事前の集約とダウンサンプリングの結果を、これらの結果がTSDBに書き込まれる前にシームレスに統合することができます。5分という粒度のデータを事前に計算し、ダウンサンプリングでTSDBに書き込んだとします。ユーザーが5分という粒度でダウンサンプリングされたクエリを実行した場合、ストリームコンピューティングエンジンは、データ計算のために時系列データベースから詳細なデータを取得する必要はありません。その代わり、ストリーム・コンピューティング・エンジンは、5分という粒度のデータを直接取得して、さらに反復計算を行うことができます。TSDBと計算エンジンは相互に接続されています。
安定性確保
ワークロード管理
TSDBは、Alibabaグループの内部サポートを提供し、プライベートクラウドとパブリッククラウドの両方のお客様にサービスを提供するために設計されているため、安定性は非常に重要です。TSDBでは、以下の3つの方法で安定性と安全性を確保しています。1つ目の方法は、リソースの分離です。2つ目は、タイムラインや時系列データに基づいたきめ細かなトラフィック制御です。最後に、包括的なメトリック監視です。
リソースの分離。読み込みスレッドと書き込みスレッドを分離することで、問い合わせリンクに障害が発生しても書き込み操作には影響がなく、書き込みリンクに障害が発生しても問い合わせには影響がないようにします。リソースの分離は、遅いクエリや大きなクエリにも対応しています。フィンガープリントは、ユーザーのクエリ条件に基づいて計算されます。フィンガープリントとクエリ履歴のレコードを使って、クエリがスロークエリかラージクエリかを判断します。クエリが遅いクエリの場合、TSDBはそのクエリを直接、ソースが限定された別のアイソレーション・キューに入れます。通常のクエリであれば、TSDBはそのクエリをより多くのリソースを持つキューに入れ、クエリ全体をある程度高速化します。
包括的なメトリクスの監視。TSDB全体のスループット、レスポンスタイム、主要なI/Oメトリクスのほか、時系列インデックスモジュールやストリームアグリゲートモジュールなどのコアモジュールのコアメトリクスを監視します。メトリクスを監視することで、TSDB内部で何が起こっているかを明確に把握し、問題点を迅速に発見することができます。
タイムラインや時系列データに基づくきめ細かなトラフィック制御。エンド・ツー・エンドのトラフィック制御の目的は、バーストトラフィックが発生したり、ユーザーのワークロードが急激に増加した場合に、エンジンが影響を受けたり、クラッシュしたりしないように保護することです。まず、TSDBは、読み取り/書き込みエントリでI/Oスレッドのリソースを制御します。TSDBは、2つのコアモジュールのエントリーとI/O出口でもトラフィックを制御し、さらに、多くのトラフィック制御ディメンションが用意されています。例えば、タイムラインモジュールを対象としたトラフィックコントロールを実装することができます。タイムラインの数が多すぎると、ビジネス時系列モジュールに設計上の欠陥があると考えられます。このため、クエリがカバーする時系列の数を減らすために、事前集計などの操作が必要になります。他の次元としては、クエリでカバーする時系列データポイントの数、スループット（I/O）、クエリの時間消費などがあります。
まとめと今後の展望
前述のシナリオは、TSDBが2018年に実装した、あるいは現在解決しようとしているシナリオです。では、今後のTSDBの開発動向と、TSDBに期待される機能や特徴を見ていきましょう。まず、コールドデータとホットデータのヘテロジニアスなストレージを実装する必要があります。これは、ユーザーのコスト削減を目的としています。データの価値がますます重要視されているため、ユーザーの詳細なデータを長期間保存することが好ましい選択肢となっています。そのためには、Alibaba Cloud OSSへの接続など、詳細データを長期保存するためのソリューションが必要となります。
2つ目は、サーバーレスの読み書き機能を実装することです。サーバーレスでの読み書きにより、TSDBはユニバーサルな分析とコンピューティングを実現します。ユニバーサルアナリシス＆コンピューティングとは、短期的な高頻度・低レイテンシーのクエリ、OLABシステムでの長期的な高次元集約分析、履歴詳細データや過去一定期間のデータの分析などを指します。サーバーレスは、履歴データやコールドデータの分析方法を決定します。サーバーレスは、計算、問い合わせ、書き込みのコストを下げることで、ユーザーのコストを下げることができます。
3つ目は、時系列のエコシステムを取り入れることです。例えば、Prometheusやその他の商用時系列データベースや監視ソリューションのシステム設計から学ぶことができます。オープンソースコミュニティを受け入れ、ストリームコンピューティング、時系列インデックス、コンピューティングエンジン、SQLエンジンなど、TSDBの利点を生かすために、可用性の高い安定したソリューションや代替手段を提供する必要があります。お客様により良いソリューションを提供していきたいと考えています。
最後に、スマートな時系列解析をさらに推進し、お客様の特定の課題を解決するために、より安定した信頼性の高いモデルを提供していきます。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ