In-depth analysis of hundreds of PB level data bus technology

クラウドネイティブシナリオにおけるデータバスの需要シナリオと課題

データバスの概要

ビッグデータアーキテクチャのトラフィックハブとして、データバスは異なるビッグデータコンポーネント間のデータブリッジの役割を担っています。データバスを通じて、サーバー、Kubernetes、アプリケーション、Web、IoT / モバイル端末から生成される各種異種データをリアルタイムでアクセスし、統一されたデータ管理を実現することで、下流システムとのデカップリングを達成できます。その後、データクレンジング、データ配信、リアルタイムコンピューティング、オフラインコンピューティングなどの計算処理を非同期で実行し、構造化データを下流の分析およびアーカイブシステムに配信することで、明確なデータフローの構築目標を達成できます。広義には、データ取得とアクセス、伝送リンク、ストレージキュー、消費計算、配信などもデータバスの範疇に含まれ、全体として収集アクセス層、パイプライン層、コンピューティング層の 3 層に分類できます。

データバスを通じて、以下の目的を容易に達成できます。

• プロデューサーとコンシューマーのデカップリング：コンシューマーは送信側の詳細を一切意識する必要がなく、システム接続の複雑性を低減し、システムの信頼性を向上させます。

• トラフィックピークへの対応：データ生産とデータ消費を非同期化し、ピークを削り谷を埋めます。

• 統一された形式と操作セマンティクスの定義：複数の異種データをアクセスし、データ処理を通じて統一形式を構築します。

簡単な例を挙げると、コンピューティング広告検索システムにおいて、広告のインプレッションデータは非常に重要です。1 つのインプレッションデータが複数のサブスクリプションで消費されることが多く、アプリケーションシナリオも多様です。秒単位の精度を持つリアルタイムコンピューティングサービスもあれば、Hadoop に類似した時間単位や日単位のバッチ処理タスクもあります。データを直接接続する場合、さまざまな異常シナリオを考慮する必要があり、システムが非常に複雑になります。データバスを通じて、システムの複雑性を大幅に低減し、信頼性を向上させることができます。これにより、オフラインメンテナンスやダウンタイムの後でも、任意のデータサブスクリプションシステムが直前のブレークポイントから処理を再開できます。

クラウドネイティブシナリオにおける技術的課題

毎日数百億件の読み書き、約 100 ペタバイトのデータトラフィック、数万のユーザーというシナリオに直面し、高可用性データバスを構築することは非常に大きな挑戦となります。以下にトラフィックシナリオの例を示します。

• プロデューサー：ビジネスプロモーションなどのイベントにより、トラフィックが数分間で 10 倍以上、場合によっては 100 倍以上に急増する。

• コンシューマー：数十のサブスクリプションが同時に 1 つのデータを消費する。

• 毎日数百の異種データソースが異なる方法でアクセスされ、大量の適合作業が必要となる。

数十年の急速な発展を経て、開発手法、システムアーキテクチャ、デプロイメント方式、インフラストラクチャなども数度の革新的な変化を経験し、より迅速な開発とデプロイメント効率をもたらしました。しかし、システムとネットワーク環境全体はより複雑になり、デプロイメント方式と動作環境はより動的で不確実性が高まり、データソースとアクセスするデータ量は大幅に増加し、トラフィック変動やその他の不確実要因も大きくなり、アクセスの難易度も従来の構成とは大きく異なっています。これらはクラウドネイティブ時代のデータバスに対する新たな要件です。

まとめると、クラウドネイティブ時代におけるデータバスの技術的課題は、収集アクセス層、パイプライン層、コンピューティング層の 3 つの観点から展開できます。収集アクセス層はデータソースのアクセスの豊富さ、アクセスの容易さ、リソースコスト、データ収集の信頼性に焦点を当てます。パイプライン層はネットワーク品質、帯域幅、水平スケーラビリティ、セキュリティと分離、エコシステムの豊富さなどに焦点を当てます。コンピューティング層はコンピューティング構文、トラフィック処理帯域幅、スケーラビリティに焦点を当てます。

オープンソースソリューションの選択と比較

現在、業界の主流ビッグデータアーキテクチャは 5 つの部分に分けられ、そのうち最初の 3 つがデータバスを構成しています。

• 収集エンド：観測データの収集と事前データ処理の一部を担います。クラウドネイティブの発展に伴い、収集エンドは時代のトレンドに適応し、Kubernetes 収集に対するフレンドリなサポートを提供する必要があります。一般的な収集エンドには、Filebeat、Fluentd / Fluent Bit、Telegraf、およびオープンソースの iLogtail があります。

• メッセージキュー：収集エージェントは通常、収集したデータを直接ストレージシステムに送信せず、メッセージキューに書き込みます。これによりトラフィックのピークを削り谷を埋める役割を果たし、トラフィックピークによるストレージシステムのダウンタイムを回避します。一般的なメッセージキューには Kafka、RabbitMQ などがあります。

• コンピューティング：メッセージキュー内のデータを消費し、処理と集約を行ってからストレージシステムに出力します。一般的なものに Flink と Logstash があります。注目すべきは、一部の企業が iLogtail オープンソース版をログアーキテクチャのコンピューティング層として配置し始めていることです。

• ストレージ分析エンジン：データを収集し、永続的に保存し、クエリと分析を行う機能を提供します。一般的なストレージ分析エンジンには、Elasticsearch、ClickHouse、Loki、Prometheus、InfluxDB があります。

• 可視化：Kibana と Grafana と連携し、データの可視化機能を提供します。

ユーザーは収集エンド、メッセージキュー、コンピューティングのオープンソースコンポーネントを組み合わせてデータバスを構築できます。オープンソースコンポーネントベースのデータバス構築は技術的に可能ですが、全体の実装複雑性が高く、複数のシステムを連携して保守する必要があります。さらに、前述のクラウドネイティブシナリオにおける課題に完全に対応することはできず、たとえばネットワーク品質とリージョン計画は超えがたいギャップとなります。

データバスの全体アーキテクチャ

可観測性プラットフォームは、データの取得方法とクエリ方法を解決するだけでなく、特定のビジネスシナリオのアプリケーション機能を提供し、断片的で情報の少ないデータからより大きなデータ価値を掘り起こすことを支援します。典型的なクラウドネイティブ可観測性プラットフォームは、下から上へデータバス、ストレージ分析、ツール、アプリケーションの 4 つのレベルに分類できます。その中で、データバスは可観測性プラットフォーム全体のデータ基盤であり、データ分析と上位ビジネスアプリケーションにデータ保証を提供します。データバスは基盤として十分に信頼性が高く、安定性があり、データの流れをスムーズに保ち、企業デジタル化プロセスにおけるトラフィック変化の需要に柔軟に対応できる必要があります。次に、Alibaba Cloud SLS データバスのアーキテクチャと実践について重点的に紹介します。

本記事の前半では、典型的なデータバスは収集アクセス層、パイプライン層、コンピューティング層の 3 層に分けられることを紹介しました。SLS データバスのアーキテクチャも同様に分類できます。

• 収集アクセス層：データバス上のすべてのデータのアクセスを担い（Log、Metric、Trace、Event などをサポート）、Alibaba Cloud の各種サービスと深く統合されています。アクセス方法は SDK / API を基盤とし、観測データコレクター iLogtail、データインポートサービス、オープンソース標準プロトコルなど、多様なアクセス方式に拡張されています。

• パイプライン層：LogHub をデータバスのコアフローハブとして使用し、Kafka を完全に置き換えることができます。RESTful API が外部アクセスサービスを提供し、コンシューマーグループがリアルタイム消費サービスを提供します。

• コンピューティング層：LogHub の下流サービスとして、リアルタイムコンシューマーグループに基づく各種データ処理と配信サービスを提供します。また、主流のオープンソースストリームコンピューティングエコシステムとの連携もサポートします。

以上で SLS データバスの全体像を把握しました。次に、データアクセス、トラフィックハブ、データ処理について詳しく紹介します。

データアクセスの技術アーキテクチャと実践

データアクセス機能の概要

データバスのコアトラフィックハブとして、LogHub はデフォルトで HTTP / HTTPS プロトコルの API 書き込み機能を提供し、アクセスシナリオを簡素化し信頼性を向上させるために多言語の SDK を提供しています。SDK は Java、Go、C++ などのサーバーアプリケーション、Android、iOS などのモバイルシナリオ、さらに JavaScript などのフロントエンドシナリオまでカバーしています。

自社開発のオープンソース観測データコレクター iLogtail は、サーバーシナリオとコンテナシナリオの観測データ収集機能を担い、Windows、Linux オペレーティングシステム、X86、ARM アーキテクチャをカバーしています。Alibaba Cloud の優位性を活かし、Alibaba Cloud 上の各種メインストリームクラウドサービスのログ、メトリック、セキュリティ監査データの収集をシームレスにサポートしています。

また、一般的なプロトコルに対する豊富なサポートも備えており、Syslog、Kafka、Prometheus、JDBC、OpenTelemetry などのオープンソースプロトコルと互換性があります。Logstash、Fluentd、Telegraf などの多くのオープンソース収集ツールもサポートしています。

Producer Library

Java、Go などのビッグデータ、高同時実行シナリオ向けに、SDK を基盤とした Java Producer と Go Producer を提供しています。IoT / 組み込みデバイス向けに C Producer を導入しています。

API や SDK で直接データを送信するのに比べ、Producer を使用するとより高レベルなカプセル化が得られ、パフォーマンスと信頼性が大幅に向上します。

• スレッドセーフ：Producer 内のすべてのメソッドと公開インターフェイスはスレッドセーフです。

• 非同期送信：クライアントのコンピューティングと I/O ロジックが分離されています。Producer の送信インターフェイスの呼び出しは通常即座に返ります。Producer は内部で送信データをキャッシュしてマージし、バッチ送信することでスループットを向上させます。

• 障害リトライ：再試行可能な例外に対して、Producer はユーザーが設定した最大リトライ回数とリトライバックオフ時間に基づいてリトライします。

• 優雅なクローズ：ユーザーがクローズメソッドを呼び出してクローズする際、Producer はキャッシュされたすべてのデータを送信し、ログの損失を防止します。

• 高パフォーマンス：マルチスレッド、キャッシュ戦略、バッチ送信などの手段により、送信効率を効果的に向上させます。

観測データコレクター iLogtail

iLogtail はデータバスデータアクセスの重要なトラフィックソースです。軽量、高性能、自動設定などの多くのプロダクションレベルの特徴を備え、物理マシン、仮想マシン、Kubernetes などの環境にデプロイしてテレメトリデータを収集できます。iLogtail のコアポジショニングは観測データのコレクターであり、開発者が統一されたデータ収集層を構築し、可観測性プラットフォームが各種上位アプリケーションシナリオを作り出すのを支援します。iLogtail はデータバスのデータアクセス問題を解決できます。

Alibaba Cloud / Ant Group およびパブリッククラウドシナリオの継続的な最適化により、iLogtail はパフォーマンス、リソース消費、信頼性、マルチテナント分離、Kubernetes サポートなどのハード指標において、オープンソースエージェント（Fluentd、Logstash、Beats など）と比較してより先進的であり、複数のビジネスシナリオにおける厳格な要件を満たすことができます。iLogtail は 2022 年 6 月 29 日に完全にオープンソース化され、多くの開発者の注目を集め、2022 年 11 月 7 日に GitHub スター数が 1,000 を超えました。

iLogtail のコアな強みの 1 つは、高性能と低オーバーヘッドです。iLogtail は Linux 環境で inotify を主なファイルモニタリング手段として使用し、ミリ秒単位の遅延でデータを検出する機能を提供します。異なるオペレーティングシステムへの対応と各種特殊収集シナリオのサポートのため、iLogtail はポーリングもデータ検出方式として使用しています。ポーリングとイベント共存のハイブリッド方式により、iLogtail はパフォーマンスの優位性と堅牢性の両方を備えたファイル検出メカニズムを構築しています。さらに、iLogtail はロックフリーのイベント処理モデルを採用しています。業界の他のオープンソースエージェントが各設定に独立したスレッド / ルーチンを割り当ててデータ読み取りを行うのとは異なり、単一スレッドで iLogtail のデータ読み取りを行います。データ読み取りのボトルネックはコンピューティングではなくディスクにあるため、単一スレッドですべての設定されたイベント処理とデータ読み取りを完了できます。単一スレッドの使用により、iLogtail のイベント処理とデータ読み取りがロックフリー環境で動作し、データ構造がより軽量となり、マルチスレッド処理よりも優れたコストパフォーマンスを実現しています。

本番環境では、数百の収集設定が 1 つのサービスに共存するのが一般的です。各設定の優先度、ログ生成速度、処理方法、アップロード先アドレスは異なる可能性があるため、各種ユーザー定義設定の分離方法を効果的に解決し、収集設定の QoS が一部の設定例外の影響を受けないようにする必要があります。iLogtail はタイムスライスベースの収集スケジューリング、多段階の高低水位フィードバックキュー、ノンブロッキングイベント処理、フロー制御 / 収集停止ポリシー、設定の動的更新などの複数の重要技術を採用し、統合して分離性、公平性、信頼性、制御性、コスト効率の 5 つの特徴を持つマルチテナント分離スキームを実現しています。長年のダブルイレブンのトラフィックピークを経て、このソリューションは他のオープンソースソリューションよりも安定性が高く、コスト効率に優れていることが実証されています。

データソースの多様性はデータバスの生命線であると言っても過言ではありません。そうでなければ、巧婦も米なき炊事はできません。プラグイン設計により、iLogtail は単純なファイル収集の範疇を突破し、アップストリームとダウンストリームのエコシステムを効果的に拡張し、真の観測コレクターとなりました。現在、iLogtail は多くのデータソースのアクセスをサポートしています。データソースタイプは Log、Metric、Trace をカバーします。ファイル収集に加え、HTTP、MySQL Binlog、Prometheus、SkyWalking、Syslog などの標準プロトコルのサポートも含まれます。eBPF による非侵襲的なネットワークデータ収集も iLogtail でサポートされています。データ出力エコシステムも SLS から Kafka、gRPC などへ段階的に拡張されています。今後はオープンソースコミュニティとの共同構築を通じて、ClickHouse、Elasticsearch などもサポートされる予定です。

多くの異種データのアクセスに直面し、データバスの責務の 1 つはデータ処理を通じて統一されたデータ形式を構築することです。iLogtail は強力なデータ処理機能も提供し、データ形式の正規化、データフィルタリング、コンテキスト相関などの前処理を事前に行えます。iLogtail は Pipeline として設計されています。まず Input プラグインでデータを収集し、収集設定で設定された Processor で処理し、Aggregator プラグインでパッケージ化し、最後に Flusher を通じてストレージシステムに送信します。データ処理環境にはデータ分割、フィールド抽出、フィルタリング、データ拡張などが含まれます。すべてのプラグインは自由に組み合わせできます。

クラウドネイティブの導入に伴い、iLogtail は Kubernetes を完全にサポートし、現在 Docker と Containerd の 2 つのメインストリームコンテナランタイムに対応しています。iLogtail はリアルタイムでコンテナリストを監視し、コンテナとログ収集パスのマッピングを維持することで、効率的なファイル収集機能と組み合わせて、最適なコンテナデータ収集体験を提供します。iLogtail はコンテナタグ、環境変数、Kubernetes タグ、Pod 名、名前空間などの方法でコンテナフィルタリングをサポートし、ユーザーに便利な収集ソース設定機能を提供します。DaemonSet、Sidecar、CRD などのデプロイメント方法をサポートし、異なるシナリオに柔軟なデプロイメント機能を提供します。さらに、iLogtail は CI/CD 自動デプロイメントと運用保守に高い要件を持つユーザー向けに Kubernetes ネイティブサポートを提供し、CRD を通じた収集設定管理をサポートします。このスキームでは、iLogtail Kubernetes が AliyunLogConfig という CustomResourceDefinition 拡張を追加します。同時に、Alibaba Log Controller を開発して AliyunLogConfig イベントをリッスンし、iLogtail 収集設定を自動的に作成してログ収集を完了させます。

トラフィックハブの技術アーキテクチャと実践

SLS データバスのトラフィックハブとして、LogHub は大量の観測データのリアルタイムアクセスと消費をサポートする高スループットデータチャネルです。観測データシナリオでは、Kafka などのメッセージキュー製品も使用可能ですが、パフォーマンス、使いやすさ、安定性により優れています。

LogHub は追加専用のログキュー構造として理解でき、複数のシャードを通じて I/O とストレージの水平拡張を実現します。さらに、キュー上に多段階インデックスを作成し、各データのキュー内位置を迅速に特定でき、キューモデルにランダムクエリ機能を付与します。

• レジリエンス：1〜512 シャードをサポートし、ミリ秒単位で拡張と縮小が可能です。

• 高スループット：単一シャードで 5 MB/秒 の書き込みと 10 MB/秒 の読み取りをサポートします。

• 高フォールトトレランス：スタンドアロンのフェールオーバーでも正常な書き込みに影響しません。

• 重複排除：ExactlyOnce 重複排除をサポートします。

• ランダムクエリ：1% の追加ストレージコストで、任意のデータのランダムクエリ（1 IO）をサポートします。

Logstore / Metricstore は SLS 観測データの収集、保存、クエリの単位です。LogHub は Logstore / Metricstore のキューモデルとして、リアルタイムデータ書き込みとストリーム消費の機能を提供します。同時に、この基盤の上にモデルを拡張し、統一された観測性分析エンジンを構築します。

• インデックスモデル：インデックスを作成することでデータフィルタリング機能を提供します。クエリ時にインデックスに基づいてヒットデータを迅速に特定し、キューモデルから必要なデータを効率的に選択できます。

• オリジナル列ストレージモデル：特定フィールドの列ストレージに対するビッグデータ統計分析機能を提供します。

• PK（時系列）列ストレージモデル：時系列データの特徴に基づき、プライマリキーソート後のフィールド列ストレージモデルを提供し、時系列データ読み取りの効率を効果的に向上させます。

グローバル化サポートとインテリジェントアクセラレーション

LogHub は Alibaba Cloud 上のインフラストラクチャです。Alibaba Cloud のグローバルデプロイメントを活用し、優先性を備え、Alibaba Cloud のリージョンと同期しています。これは他のオープンソースデータバスが匹敵できない優位性でもあります。グローバルビジネスが最寄りのリージョンを選択できることを保証し、関連する法的データの国外持ち出しが許可されないという一部のア国や組織の要件にも対応できます。

LogHub と CDN はグローバル自動アップロードアクセラレーションソリューションを共同で立ち上げました。Alibaba Cloud CDN のハードウェアリソース（3,200 以上のノード、70 以上の国をカバー）に基づき、グローバルデータは最寄りのエッジノードからアクセスされ、内部高速チャネルを通じて LogHub にルーティングされ、ネットワーク遅延とジッターを大幅に削減します。

弾力性と順序保持処理

本番環境では、トラフィックのピークと谷の状況、およびビジネス層のマッピング不均衡により特定のパーティション（シャード）に非常に大きなトラフィックが発生するシナリオに直面することがよくあります。エラスティックスケーリング（マージ / 分割）はこれらの問題を解決するメカニズムです。

シャード分割の原理

シャード分割操作はトラフィック拡張の重要な手段であり、1 つの読み書きシャードを 2 つの読み書きシャードに分割することです。同時に、元のシャードは読み取り専用になりますが、既存のデータは引き続き消費と読み取りが可能です。

マージ操作は分割操作の逆で、隣接する 2 つの読み書きシャードを 1 つの読み書きシャードに結合し、元の 2 つのシャードは読み取り専用になります。

負荷分散：ピーク値とボトム値に基づく弾力的スケールでコストを制御します。

下図では、最初は Shard0 のみがサービスを提供していました。その後、夕方のトラフィックピークに伴い、単一シャードではビジネストラフィックをサポートしきれなくなったため、Shard0 を Shard1 と Shard2 に分割してサービスを提供しました。トラフィックが再び安定すると、コストのために新しい Shard3 をマージしてサービスを提供します。

ログの順序保持処理：異なるインスタンスを異なるパーティションにマッピングし、パーティションの処理能力を調整します。

一部のビジネスシナリオでは順序保持のニーズがあります。データ書き込み時に、異なるビジネスのデータを Hash ルールを通じて固定のシャードにマッピングすることが多いです。

下図のビジネスシナリオでは、Shard1 が 3 つの DB のトラフィックを担っています。この場合、シャード分割によりトラフィックを均等化できます。分割後、元の Shard1 は読み取り専用になり、データは引き続き消費できますが、新しいデータの書き込みは受け付けません。新しく分割された Shard3 と Shard4 が外部サービスを提供します。

シャード調整前後の境界データの順序をどのように保持するか。LogHub はシャードの順序付き消費機能を提供します。つまり、シャード分割後、元のシャードデータ（Shard1 のデータ）を先に消費し、その後分割されたシャードデータを同時に消費します（Hash ポリシーにより同じビジネスが 1 つのシャードに配置されることが保証されます）。同様に、シャード統合シナリオでも、元のシャードデータを先に消費し、その後元のシャードからマージされた新しいシャードデータを消費します。厳密な順序が必要ないシナリオでは、消費率を向上させるために、シャードの順序付き消費機能をオフにして、すべてのシャードを同時に消費することもできます。

安定性構築

粗粒度フロー制御：プロジェクトレベル

プロジェクト全体のフロー制御の主な目的は、ユーザーの全体的なリソース使用量を制限し、フロントエンドでリクエストを拒否して、トラフィックがバックエンドに透過してクラスター全体がダウンするのを防ぐことです。

• 毎秒数千の Nginx フロントエンドが受信した各プロジェクトのトラフィックとリクエストを集約し、QuotaServer に送信します。

• QuotaServer はすべての Nginx からのプロジェクト統計を集約してクォータ上限を超えているかを判定し、フロー制限措置を取るかどうかを決定します。その後、すべての Nginx フロントエンドにクォータ超過プロジェクトのリストが通知されます。

• Nginx フロントエンドは無効化プロジェクトのリストを取得すると、即座に反応し、これらのプロジェクトのリクエストを拒否します。

細粒度フロー制御：シャードレベル

シャードレベルのフロー制御はより精緻で、セマンティクス（エラーコード）がより明示的で、より制御性が高いです。

• 各シャードは処理能力を明確に定義しています。たとえば、書き込み 5 MB/秒、読み取り 10 MB/秒です。

• シャードキューがブロックされた場合、シャードトラフィックがクォータを超えているかに基づいて、ユーザーにフロー制限（HTTP エラーコード 403）またはシステムエラー（HTTP エラーコード 500）が返されます。同時に、シャードフロー制限情報が QuotaServer に通知されます。

• QuotaServer はフロー制限情報を受信すると、即座にすべての Nginx にフロー制限情報を同期できます。

• Nginx フロントエンドはシャードフロー制御情報を取得し、シャードに対して正確なフロー制御を実施します。

データ処理の技術アーキテクチャと実践

前述のデータアクセス部分からわかるように、データバスはトラフィックハブとして各種異種データのアクセスを担っています。iLogtail は強力なデータ前処理機能を備えていますが、歴史的な理由やアクセス方法の違いにより、データ形式が大きく異なる場合があります。統一された形式仕様の達成は困難で、後続の分析に大きな困難をもたらします。そのため、データバスにはデータ処理リンクが必要で、これに対して主にデータ処理サービスとスケジュール SQL に基づくデータ処理機能を提供しています。

• データ処理：LogHub を基盤としたストリームモデル実装で、リアルタイムでの行単位データ処理とリンクオーケストレーションを行います。

• スケジュール SQL：Logstore インデックスモデルを基盤とした実装で、データの定期的な分析集約処理を行い、主にサンプリング、重複排除、指標構築に使用されます。

さらに、オープンソースエコシステムをより良くサポートするため、カスタム消費や Flink ストリーム消費の機能もサポートしています。

データ処理

データ処理サービスは、大部分の処理とオーケストレーションシナリオを効果的に解決できます。

• 正規化：最も頻繁に使用されるシナリオです。たとえば、テキストログデータからキー情報を抽出し、標準化されたデータに変換します。

• エンリッチメント：たとえば、ユーザーのクリックデータには商品 ID しか含まれておらず、分析時にデータベースから詳細情報を関連付ける必要があります。

• マスキング：個人情報保護関連法の整備に伴い、機密データ（個人情報など）の取り扱いに対する要件がますます高まっています。

• 分割：データ書き込み時に、パフォーマンスと利便性のために複数のデータが結合されて出力されることがあり、分析前に独立したデータ項目に分割する必要があります。

• 配信：異なるタイプのデータを異なる特定の宛先に書き込み、下流のカスタマイズに対応します。

全体アーキテクチャ

データ処理サービスは、リアルタイムコンシューマーグループに基づいてソース Logstore からロードバランシングされたデータを消費します。ソース Logstore のシャード数がデータ処理タスクの同時実行の上限を決定します。データ処理スケジューラーが新しいジョブを開始すると、自動的にソース Logstore にコンシューマーグループを作成してバインドします。コンシューマーグループ内の複数のコンシューマーは、それぞれ異なるシャードのデータを独立して処理します。データ量の増加に伴い、ソース Logstore からより多くのシャードを分割する必要があります。同時に、より多くのコンシューマーがデータ処理ジョブのために独立して動作できます。

ジョブが外部リソースを関連付ける必要がある場合、各コンシューマーは独立してリソースのコピーを保持し、高性能な関連コンピューティングを実現します。

弾力メカニズム

ログデータの特徴は、データ量の膨大さに加え、データ量の周期的な変動と非常に狭いピーク波形です。たとえば、ライブ配信プラットフォームの場合、毎日のトラフィックの 90% は 21:00 から 23:00 のレジャー時間帯に集中しており、この期間のデータ量は通常の数十倍になります。このような極端なシナリオに直面して、データ処理はコンピューティング能力の弾力的な拡張を実現し、ユーザージョブの高性能動作を保証し、リソースの無駄を最小限に抑える必要があります。

タスクスケジューリングにおけるデータ処理の弾力的スケーリングは、LogHub のコンシューマーグループと Kubernetes の HPA メカニズムに基づいています。システムでは、ストレージとコンピューティングの分離を通じてデータ処理のコンピューティング能力を自由に拡張できます。ユーザー側から見ると、従量課金型のサービス指向コンピューティングプラットフォームであり、複雑な詳細を気にする必要はありません。

Kubernetes ネイティブの HPA は CPU とメモリのみをサポートしており、大部分のデータ集約型ジョブには十分です。しかし、データ処理では、一部の顧客がデータをオーケストレーションしてリージョン間でデータを転送します。このようなネットワーク / I/O に敏感なシナリオに直面して、組み込みの HPA メトリクスでは対応できません。そのため、より包括的な HPA メトリクスを導入し、さまざまなビジネスシナリオでのジョブ要件をサポートしています。さらに、インテリジェントアルゴリズムを使用して HPA メトリクスを継続的にアップグレードおよび最適化します。たとえば、ジョブの履歴実行特徴に基づいて事前にリソースを割り当て、ジョブ実行の安定性をさらに向上させます。

クラウドデータ処理言語（DPL）

データ処理サービスは Python 構文に基づいてユーザー側インターフェイスを設計し、完全な組み込みデータ処理機能を提供しています。これを Cloud Data Processing Language（DPL）と呼びます。DPL を使用すると、わずかなコードで非常に複雑なデータ処理ロジックを完了できます。

以下は情報エンリッチメントの例です。HTTP リクエストにおいて、RDS ディメンションテーブルの関連付けを通じて、リクエストステータスコード（http_status フィールド）の詳細説明（http_code_desc フィールド）を元のデータに追加します。

スケジュール SQL

時系列ベースのデータ（ログ、メトリック）は蓄積後の数量が膨大です。Nginx アクセスログを例に取ると、各 HTTP / HTTPS アクセスリクエストは 1 件のアクセスログを記録します。毎日 1,000 万件のデータが生成されると仮定すると、年間では 36 億件のデータになります。大量のデータを長期間保存すると、大量のストレージスペースを占有するだけでなく、データ分析と処理にも大きなパフォーマンス圧力をもたらします。

スケジュール SQL はデータの定期的な集約、分析、処理を実行でき（標準 SQL、SLS クエリと分析構文をサポート）、スケジューリングルールに従って定期的に実行し、実行結果をターゲットデータベースに書き込みます。自己構築の API 呼び出し方式と比較して、以下の利点があります。

• SQL ランタイムが 600 秒に向上し、最大処理対象は 100 億件レベルのデータです。

• 最小 1 分サイクルで実行され、常駐または固定時間間隔のスケジューリング操作をサポートします。

• 柔軟なクエリタイムウィンドウパラメーター設定をサポートし、多様化されたニーズに対応します。

• ターゲットライブラリに ExactlyOnce で書き込みます。

• フルマネージド運用で、各種例外を自動的に処理します。

• その他のエンタープライズ機能：完全なジョブインスタンスの閲覧、リトライサポート（コンソール、API）、インスタンス実行失敗のアラート通知。

クラウドサービスデータ配信技術の実践

データ配信技術の概要

クラウドサービス（OSS、SLB など）はクラウドベンダーがホストしており、ユーザーはサーバーに直接ログインしてログを表示することはできません。データ配信技術は SLS データバス技術を基盤とした重要なサービスモジュールで、ユーザー認可を前提として、クラウドサービス側から各ユーザー側に観測データを配信できます。実装メカニズムは、クラウドプロダクトサービス側が事前収集、クリーニング（処理）プロセスを通じてログを中央データハブ（LogHub）に保存し、配信サービスを通じてマルチテナント形式でデータをユーザー側に配信します。以下の利点があります。

• マルチテナント分離

• トラフィックの無制限な拡張

• 複数シャードによる高同時実行性と低レイテンシ

Cloud Lens アーキテクチャ

データ配信技術はクラウドプロダクトサービス側からユーザー側への観測データの流れの問題のみを解決します。しかし、クラウドサービスログの収集、クラウド資産の帰属、マルチアカウントシステムの認証などは、依然として上位層のサービスで維持する必要があります。そのため、資産同期、自動収集サービス、マルチアカウントシステムなどの基本サービスを構築し、これらを総称して統合アクセスサービスと呼びます。その後、統合アクセスサービスを基盤として、各クラウドプロダクト向けに統一されたインタラクションと機能コンポーネントをさらに提供し、より上位のアプリケーション機能である Alibaba Cloud Lens を構築しました。

Alibaba Cloud Lens は SLS を基盤としてクラウドプロダクトの統一可観測性を構築し、Alibaba Cloud プロダクトの使用状況分析、パフォーマンスモニタリング、セキュリティ分析、データ保護、例外検出、アクセス分析などのサービスを提供します。コスト、パフォーマンス、セキュリティ、データ保護、安定性、アクセス分析の 6 つの次元から、クラウドプロダクトの運用保守分析を支援する機能を提供し、クラウドプロダクトの可観測性のハードルを効果的に下げています。

動的データ検出と収集

収集リンクの自動スケジューリングは Cloud Lens の主な特徴の 1 つです。グラフィカルな方法により、ワンクリックで自動化された資産検出とデータ収集（ユーザー側へ）を実現できます。内部的には DSL コードに依存して収集ロジックのレイアウトを実現しています。

今後の方向性についての考察と展望

今後、SLS データバス技術は収集アクセス、パイプライン、コンピューティングの 3 つのレベルで引き続き取り組み、可観測性プラットフォームに安定的で信頼性の高いデータ基盤を提供していきます。