このトピックでは、Lindorm のアーキテクチャについて、背景情報と全体構造を含めて説明します。
背景情報
情報技術の急速な発展により、さまざまな業界のさまざまなビジネス活動によって、より多くの種類のデータが生成されています。データには、メタデータ、運用データ、デバイスまたはシステムからの測定データ、ログなどの構造化ビジネスデータが含まれます。また、運用データ、ログ、画像、ファイルなどの半構造化ビジネスデータも含まれます。従来のソリューションでは、ITアーキテクチャを設計する際に、さまざまなストレージ技術と分析技術を使用して、複数の種類のデータを保存、クエリ、分析する必要がありました。次の図は、従来のソリューションにおけるアーキテクチャを示しています。
この種の技術ソリューションは、断片化された技術を統合して、さまざまなシナリオの要件を満たします。複数のデータベースを使用して、さまざまな種類のデータを個別に処理する必要があります。この種のソリューションには、次の欠点があります。
複数の複雑な技術コンポーネントが使用される。
技術の選択が複雑である。
データアクセスとデータ同期に長いプロセスが必要となる。
これらの欠点は、技術担当者に高い要件を課し、ビジネスの展開サイクルの長期化、障害率の増加、メンテナンスコストの増加につながります。これは、情報システムの開発に関する問題を引き起こす可能性があります。技術の断片化は、技術アーキテクチャの断片化にもつながります。これは、技術アーキテクチャの進化と発展に役立たず、最終的には技術アーキテクチャがビジネス開発の要件を満たせなくなる原因となります。たとえば、ゾーン間の高可用性を構成したり、グローバル同期を有効にしたり、ストレージコストを削減したりして、増え続けるビジネスの要件を満たす必要があります。この場合、各技術コンポーネントを個別に進化させ、開発する必要があります。これには、長い時間とより多くの人員が必要です。ビジネスの成長に伴い、より多くの種類のデータが生成されます。さまざまな種類のデータを差別化して処理する需要は、日々増加しています。これは、データの断片化をさらに引き起こします。
情報技術の発展における大きな問題は、さまざまなビジネスニーズの増加により、さまざまな種類のデータが生成されることです。これにより、差別化されたデータ処理の要件を満たすために、より複雑で高価なストレージアーキテクチャが必要になります。 5G、IoT、Internet of Vehicles（IoV）などの新しい情報技術の適用も、この問題の発生原因となります。この問題を解決するために、Alibaba Cloud は、マルチモデルデータの統合ストレージ要件、クエリ要件、分析要件を満たす Lindorm をリリースしました。従来のソリューションと比較して、Lindorm はストレージアーキテクチャを簡素化し、システムの安定性を向上させ、構築コストを削減できます。次の図は、Lindorm システムを示しています。
全体アーキテクチャ
Lindorm は、ストレージリソースとコンピューティングリソースが分離された、革新的なクラウドネイティブマルチモデル統合アーキテクチャを採用しています。このアーキテクチャは、クラウドコンピューティング時代のリソースの分離と自動スケーリングの要件を満たすことができます。 Lindorm は、LindormDFS というクラウドネイティブ分散ファイルシステムを統合ストレージベースとして使用します。 LindormDFS に基づいて、ワイドテーブルエンジン、時系列エンジン、検索エンジン、ストリーミングエンジンなど、複数の専用エンジンが構築されています。 Lindorm はマルチモデルエンジンシステム上で動作し、SQL を使用して Lindorm インスタンスにアクセスし、さまざまなモデルにわたって関連クエリを実行できます。 Lindorm は、Apache HBase、Apache Cassandra、OpenTSDB、InfluxDB、Apache Kafka、Hadoop Distributed File System（HDFS）のオープンソース標準インターフェースとも互換性があります。これにより、既存のビジネスワークロードを Alibaba Cloud にシームレスに移行できます。アーキテクチャの最上位層では、Lindorm は Lindorm Tunnel Service（LTS）を提供して、エンジン間でデータをリアルタイムで転送し、データの変更をキャプチャします。このように、Lindorm は、データ移行、リアルタイムデータ変更追跡、Lindorm とデータレイク間のデータ転送、データウェアハウスから Lindorm へのデータ同期、アクティブ地理冗長性、バックアップとリカバリなどの複数の機能を提供します。
LindormDFS
LindormDFS は、クラウドストレージインフラストラクチャ向けに設計された分散ストレージシステムです。 LindormDFS は HDFS プロトコルと互換性があり、主要顧客の要件を満たすためにローカルディスクで実行できます。 LindormDFS は、すべての Lindorm エンジンと外部コンピューティングシステムに、統合された環境に依存しない標準インターフェースを提供します。次の図は、LindormDFS のアーキテクチャを示しています。
LindormDFS は、パフォーマンス、標準、容量の 3 つのストレージタイプを提供します。実際のビジネスシナリオにおけるコールドデータとホットデータの特性に基づいて、ストレージタイプの組み合わせを使用できます。 LindormDFS は、マルチモデルエンジンシステムによって提供されるコールドデータとホットデータの分離機能と組み合わせて使用できます。これにより、コールドデータとホットデータにストレージリソースを割り当てることができます。大量のデータのストレージコストを削減できます。
データコンピューティングと分析、データのバックアップとアーカイブ、データのインポートなどのさまざまなシナリオで、LindormDFS を使用して、外部システムからさまざまな Lindorm エンジンの基盤となるデータファイルにアクセスできます。これにより、データの読み取りおよび書き込み操作の効率が大幅に向上します。たとえば、オフラインコンピューティングシステムで特定のデータ形式の基盤となるファイルを生成し、そのファイルを LindormDFS に直接インポートして、データのインポートによるビジネスのダウンタイムを短縮できます。
LindormTable
Lindorm は、大量の半構造化データと構造化データの分散ストレージ用に LindormTable というワイドテーブルエンジンを提供します。 LindormTable は、メタデータ、注文、請求書、ユーザープロファイル、ソーシャルメディア情報、フィード、ログを保存するために使用できる NoSQL データベースシステムです。このシステムは、Apache HBase や Apache Cassandra などの複数のオープンソースソフトウェアの標準インターフェースと互換性があります。 LindormTable は、自動シャーディング、マルチレプリカストレージ、ログ構造マージツリー（LSM）の概念に基づいて開発されています。 LindormTable は、グローバルセカンダリインデックス、多次元検索、動的カラム、有効期限（TTL）などのクエリ処理機能を提供します。 LindormTable は、テーブルあたり数百兆行を保存し、数千万の同時リクエストを処理し、数ミリ秒で即時応答をサポートし、強力な整合性のためにゾーン間のディザスタリカバリを実装できます。これにより、ビジネスは大規模データをオンラインで保存およびクエリするための要件を満たすことができます。 LindormTable は、大量の半構造化データと構造化データを保存するために使用できる NoSQL データベースシステムです。 LindormTable は、Apache HBase や Apache Cassandra などの複数のオープンソースソフトウェアの標準インターフェースと互換性があります。次の図は、LindormTable の全体アーキテクチャを示しています。
LindormTable は、LindormDFS にデータを永続的に保存します。自動シャーディング機能により、テーブル内のデータがクラスター内の複数のサーバーに分散されます。各パーティションには、1 つのプライマリレプリカと複数のセカンダリレプリカを含めることができます。プライマリレプリカとセカンダリレプリカは、異なるゾーンにロードして、クラスター内での高可用性と強力な整合性を確保できます。プライマリレプリカとセカンダリレプリカ間でデータが同期される方法と読み取り/書き込みモードは、整合性レベルによって異なります。
強力な整合性：プライマリレプリカのみが読み取りおよび書き込み操作をサポートします。データは非同期モードでセカンダリレプリカに同期されます。プライマリレプリカに障害が発生した場合、セカンダリレプリカがプライマリレプリカに昇格されます。フェイルオーバーを実行する前に、システムは障害が発生したプライマリレプリカからデータを同期し、セカンダリレプリカにすべてのデータが含まれていることを確認します。データ同期は、プライマリノードによって調整されます。
結果整合性：プライマリレプリカとセカンダリレプリカの両方が読み取りおよび書き込み操作をサポートします。データはプライマリレプリカとセカンダリレプリカ間で同期され、データの最終的な整合性が確保されます。
LindormTable のマルチレプリカアーキテクチャは、PACELC 定理に基づいています。テーブルごとに整合性レベルを指定して、テーブルごとに異なる可用性とパフォーマンスを確保できます。結果整合性レベルを指定すると、特定の条件が満たされたときに、サーバーは各読み取り/書き込みリクエストに対してレプリカへの同時アクセスをトリガーします。これにより、リクエストの成功率が大幅に向上し、応答グリッチが減少します。同時実行制御メカニズムは、内部非同期フレームワークに基づいて構築されています。複数のスレッドを開始する場合と比較して、このメカニズムは追加リソースをほとんど消費しません。同時アクセスのトリガー条件は、2 つのタイプに分類できます。
最初のタイプはタイムアウトトリガーです。リクエストごとに GlitchTimeout を構成できます。各リクエストは 1 つのレプリカに送信されます。指定された期間内にレプリカから応答が返されない場合、リクエストは残りのすべてのレプリカに送信されます。最小レイテンシで返すことができる応答が使用されます。
2 番目のタイプはブラックリストポリシーです。サーバーは、タイムアウト、エラーのスロー、検出などのメカニズムに基づいて、応答しないレプリカまたは応答に長い時間がかかるレプリカをブラックリストに追加します。これにより、リクエストは、ハードウェアの制限またはソフトウェア設計の欠陥があるノードをバイパスできます。これにより、サービスの安定性とサービスの可用性を最大限に高めることができます。停電などの外部要因によりシステムが応答を停止した場合、ノードが利用できなくなってから 1 ～ 2 分後にノードはハートビートを失います。 LindormTable のマルチレプリカアーキテクチャは、レイテンシを短縮し、サービスの可用性を大幅に向上させることができます。
LindormTable の LSM ツリーは、ホットデータをコールドデータから分離するために使用されるデータ構造です。このデータ構造を使用して、テーブル内のホットデータとコールドデータを自動的に分離し、透過的なクエリを実行できます。 LindormTable は、基盤となるレイヤーの LindormDFS のホットストレージ管理機能とコールドストレージ管理機能と組み合わせて使用して、大量のデータの全体的なストレージコストを劇的に削減できます。
LindormTable によって提供されるデータモデルは、複数のデータタイプをサポートする緩やかなテーブル構造です。従来のリレーショナルモデルと比較して、LindormTable は事前定義されたカラムタイプを提供し、DDL リクエストを開始せずにカラムを動的に追加することもできます。これにより、ビジネスはビッグデータシナリオにおけるデータの柔軟性とデータ変更の要件を満たすことができます。 LindormTable は、グローバルセカンダリインデックスと転置インデックスもサポートしています。システムは、指定されたクエリ条件に基づいて最適なインデックスを自動的に選択し、ブールクエリの実行を高速化します。 LindormTable は、ユーザープロファイルや課金シナリオなど、大量のデータをクエリする必要があるシナリオに適しています。
LindormTSDB
Lindorm は、大量の時系列データを保存および処理するために LindormTSDB という時系列エンジンを提供します。 LindormTSDB は分散時系列エンジンであり、オープンソース OpenTSDB の標準インターフェースと互換性があります。 LindormTSDB は、範囲パーティションとハッシュパーティションの組み合わせ、および時系列データの特性とクエリ方法に基づいた専用の LSM アーキテクチャとファイル構造を使用します。 LindormTSDB は、大量の時系列データに対して低コストのストレージ、ダウンサンプリング、集計計算、高可用性、ディザスタリカバリを提供します。 LindormTSDB は、IoT や監視などのシナリオで測定データとデバイス運用データを保存および処理できます。次の図は、LindormTSDB の全体アーキテクチャを示しています。
TSCore は、LindormTSDB でのデータ構造化に使用されるコアコンポーネントです。 TSCore の全体アーキテクチャは、LSM 構造に似ています。データは Memchunk に書き込まれ、その後ディスクにフラッシュされます。時系列データは時系列に基づいて書き込まれます。したがって、LindormTSDB は専用のファイル構造 TSFile を使用して、時間ウィンドウごとにデータを分割します。データは、時間によって物理的および論理的に分離されます。これにより、コンパクションにおける I/O 増幅が大幅に削減され、TTL の実装とホットデータとコールドデータの分離が効率的になります。
TSCompute は、時系列データのリアルタイムコンピューティングに使用されるコンポーネントです。 TSCompute は、ダウンサンプリングとタイムライン集計の監視要件を満たすために使用されます。 TSCompute は Lindorm ストリーミングエンジンを使用してデータにサブスクライブし、完全にメモリ内コンピューティングに基づいています。したがって、TSCompute は軽量で効率的であり、LindormTSDB の組み込みコンピューティング機能に適しています。複雑な分析要件を満たすために、LindormTSDB を Spark や Flink などのシステムに接続できます。これにより、システムはより多くのシナリオをサポートし、ビジネスの変化に適応できます。
LindormSearch
Lindorm は、大量のデータを処理するために LindormSearch という検索エンジンを提供します。 LindormSearch は分散検索エンジンであり、Apache Solr の標準インターフェースと互換性があります。 LindormSearch を使用して、LindormTable と LindormTSDB のインデックスを保存し、クエリを高速化できます。 LindormSearch の全体アーキテクチャは LindormTable の全体アーキテクチャと同じであり、自動シャーディング、マルチレプリカストレージ、Lucene に関連する概念に基づいて構築されています。 LindormSearch は、全文検索、集計計算、複雑な多次元クエリなどの機能を提供します。また、大量のデータの効率的な検索の要件を満たすために、水平スケーリング、一度書き込めば何度でも読める、ゾーン間のディザスタリカバリ、TTL も提供します。次の図は、LindormSearch のアーキテクチャを示しています。
LindormSearch は、LindormDFS にデータを永続的に保存します。自動シャーディング機能により、データがクラスター内の複数の SearchServer に分散されます。各シャードには、プライマリレプリカと複数の読み取り専用レプリカがあります。これにより、集計クエリの効率が向上します。これらのレプリカはストレージを共有して、データ冗長性を排除します。
Lindorm システムでは、LindormSearch を独立したモデルとして使用して、半構造化データと非構造化データに緩やかなドキュメントビューを提供できます。 LindormSearch は、ログデータ分析と全文検索に適しています。 LindormSearch を使用して、LindormTable と LindormTSDB のインデックスを保存することもできます。このプロセスはユーザーに対して透過的です。 LindormTable と LindormTSDB の一部のフィールドは、内部データリンクを介して LindormSearch に自動的に同期されます。データモデルと読み取りおよび書き込みアクセスリクエストは、ユーザーに対して統合されたままです。ユーザーは検索エンジンを認識していません。データの関連付け、整合性、クエリ集計、TTL 管理などのクロスエンジンタスクはすべて、システムによってシンプルかつ透過的に処理されます。これにより、ユーザーは統合マルチモデルアーキテクチャを効率的に使用できます。
Lindorm ストリーミングエンジン
Lindorm ストリーミングエンジンは、ストリーミングデータを処理するために開発されました。このエンジンは、ストリーミングデータストレージと軽量コンピューティング機能を提供します。 Lindorm ストリーミングエンジンは、Kafka API および Flink SQL と互換性があります。このエンジンを使用して、ビジネスでストリーミングデータを処理および使用できます。
Lindorm ストリーミングエンジンは、ストリーミングストレージコンポーネントとストリーミングコンピューティングコンポーネントを統合しています。 2 つのコンポーネントは全体としてデプロイされ、ストリーミングデータをリアルタイムで高パフォーマンスで処理します。ストリーミングストレージコンポーネントは、メッセージサービスのログデータにサブスクライブし、データを Lindorm ストリーミングエンジンに書き込み、データを LindormDFS に永続的に保存します。ストリーミングストレージコンポーネントは Apache Kafka の API と互換性があり、低コストで高スループットとスケーラビリティを提供できます。ストリーミングコンピューティングコンポーネントは、メッセージサービスからのログデータをリアルタイムで処理します。処理結果は、LindormTable または LindormTSDB に同期できます。ストリーミングコンピューティングコンポーネントは Flink SQL と互換性があります。
LDPS
Lindorm は、Lindorm Distributed Processing System（LDPS）というコンピューティングエンジンを提供します。 LDPS は、クラウドネイティブアーキテクチャに基づいて提供される分散コンピューティングサービスです。 LDPS のコンピューティングノードは、Alibaba Cloud Serverless Kubernetes（ASK）クラスターで実行されます。 LDPS は、Spark Community Edition のコンピューティングモデルとプログラミングインターフェースをサポートしています。 LDPS は LindormDFS の機能も統合しており、基盤となるストレージ機能とインデックス作成機能を完全に使用して、分散ジョブを効率的に完了します。 LDPS は、データ生成、インタラクティブ分析、機械学習などのシナリオで高パフォーマンスのコンピューティングサービスを提供します。 LDPS はジョブ管理インターフェースも提供します。 Spark Web UI（SparkUI）で Spark ジョブを監視および維持できます。