How Hologres supports large-scale deployment and operation and maintenance

1. 超大規模デプロイが直面する課題

インターネットの発展に伴い、データ量は爆発的に増加し、スタンドアロンデータベースではビジネスニーズを満たせなくなりました。特に分析分野では、1 つのクエリで大量のデータ、場合によっては全データを処理する必要があり、膨大なデータがもたらすプレッシャは特に切実な問題となっています。同時に、企業のデジタルトランスフォーメーションの加速に伴い、データの適時性がますます重要視されており、データをいかに活用してビジネスをより良く支援するかが、企業のデジタルトランスフォーメーションの鍵となっています。

ビッグデータのリアルタイムデータウェアハウスシナリオでは、データベースの規模が従来のデータベースに比べて大幅に拡大する傾向にあります。データ量の増加 (TB レベル、PB レベル、さらには EB レベル)、データ処理の複雑さの増大、より高速なパフォーマンス、サービスと分析の同時満足などです。

オープンソース OLAP システムを使用した経験のあるユーザー、特にオープンソース OLAP でクラスターを構築したユーザーは、ClickHouse や Druid などのデプロイと運用保守の難しさを痛感しています。具体的には、以下の問題に直面しています。

・クラスターの迅速なデリバリと弾力的スケーリングをいかに実現するか
・サービス可用性指標と SLA システムをいかに定義するか
・ストレージとコンピューティングの統合によるモデル選定と容量計画の難しさ
・モニタリング機能の弱さ、障害復旧の遅さ、自己修復機能の欠如

同時に、規模の拡大、大規模なメリット、高性能スループットからのプレッシャにより、リアルタイムデータウェアハウスのデプロイと運用保守の難易度は指数関数的に増加し、システムはスケジューリング、デプロイ、運用保守において多くの課題に直面しています。

・1 万ノード規模の単一クラスターにおけるサービスインスタンスの秒レベル起動と弾力的スケーリング能力を実現するスケジューリング能力
・大規模クラスターの容量計画、安定性保証、マシン自己修復の実現と関連する運用保守効率の向上
・インスタンスおよびクラスターモニタリングの適時性と精度の両立、分レベルでの問題発見と問題解決をいかに達成するか

Alibaba Cloud のクラウドネイティブ基盤サービスにおける強力な研究開発能力により、リアルタイムデータウェアハウス Hologres は、優れたアーキテクチャ設計や Alibaba Cloud ビッグデータインテリジェント運用保守プラットフォームなど、複数のコア機能の構築を通じてこれらの課題を解決し、強力なパフォーマンス、優れたスケーラビリティ、高い信頼性、メンテナンスフリーを備えたリアルタイムデータウェアハウスプロダクトをユーザーに提供しています。

本記事では、超大規模デプロイと運用保守システム構築の観点から、超大規模リアルタイムデータウェアハウスが直面する課題と、それに対する設計およびソリューションを分析し、高負荷と高スループットをサポートしながら高性能を実現し、本番レベルの高可用性を達成する方法を紹介します。

2. クラウドネイティブベースの大規模スケジューリングアーキテクチャ設計

クラウド技術の台頭により、Kubernetes をコンテナアプリケーションクラスター管理システムとして利用するシステムが増えています。Kubernetes はコンテナ化アプリケーションに対し、自動リソーススケジューリング、コンテナデプロイ、動的拡張、ローリングアップグレード、負荷分散、サービス検出などの機能を提供します。

Hologres はアーキテクチャ設計の初期段階から先を見据えた最適化を行い、クラウドネイティブなコンテナ化デプロイ方式を採用し、Kubernetes をリソーススケジューリングシステムとして使用することで、リアルタイムデータウェアハウスシナリオにおける超大規模ノードとスケジューリング能力のニーズを満たしています。Hologres が依存するクラウドネイティブクラスターは 1 万台以上のサーバーをサポートでき、単一インスタンスは 8,192 ノード、さらにはそれ以上の規模に達することができます。

2.1 1 万ノード規模の Kubernetes スケジューリング

Kubernetes が公式に発表している最大クラスターサイズは 5,000 台です。Alibaba Cloud のシナリオでは、ビジネス規模の要件を満たしリソース利用率を向上させるため、クラウドネイティブクラスターの規模を 1 万台に到達させる必要があります。周知の通り、Kubernetes は etcd と kube-apiserver に強く依存する中央ノードサービスであり、この部分がパフォーマンスボトルネックとなっています。1 万台規模を突破するには、関連コンポーネントの詳細な最適化が必要です。同時に、シングルポイントフェールオーバの速度問題を解決し、クラウドネイティブクラスターの可用性を向上させる必要もあります。

ストレステストにより、1 万ノード規模と数百万ポッドのプレッシャをシミュレーションしたところ、深刻な応答遅延問題が発見されました。

・etcd の読み取り/書き込み遅延が多く、サービス拒否の状況を引き起こすことがある。同時に、ストレージ容量の制限により、Kubernetes が大量のオブジェクトを保存できない
・API Server のクエリレイテンシが非常に高く、同時クエリリクエストがバックエンド etcd の OOM を引き起こす可能性がある
・Controller の処理遅延が高く、異常からの回復に時間がかかる。異常再起動が発生した場合、サービスの回復に数分を要する
・Scheduler のレイテンシが高くスループットが低いため、日常の運用保守ニーズを満たせず、大規模プロモーションなどの極端なシナリオには対応できない

K8s クラスター規模のボトルネックを突破するため、関連チームは詳細な調査を行い、処理ボトルネックの原因を特定しました。

・kubelet がパフォーマンスボトルネックであることが判明。kubelet は 10 秒ごとにフル情報量をハートビート同期として K8s に報告し、データ量は数 KB から大きいもので 10 KB 以上に達する。ノード数が 5,000 に達すると、kube-apiserver と etcd に書き込みプレッシャが生じる
・etcd の推奨ストレージ容量はわずか 2 GB であり、1 万台規模の K8s クラスターのオブジェクトストレージ要件はこの制限を大幅に超え、パフォーマンスを低下させてはならない
・高可用性をサポートする複数の API Server のデプロイで、負荷が不均等になり、全体的なスループットに影響を与える
・既存の Scheduler はパフォーマンスが低く機能が弱いため、混合デプロイメントや大規模プロモーションなどのシナリオに対応できない

この状況に対して、以下の最適化を行い、1 万台規模のスケジューリングを実現しました。

・etcd に新しいメモリフリーページ管理アルゴリズムを設計し、etcd のパフォーマンスを大幅に最適化
・Kubernetes の軽量ハートビートの実装と HA クラスター下の複数 API Server ノードの負荷分散改善により、APIServer のパフォーマンスボトルネックを解決
・ホットスタンバイにより Controller/Scheduler のアクティブ・スタンバイ切り替え時のサービス中断時間を大幅に短縮し、クラスター全体の可用性を向上
・等価クラス処理のサポートとランダム緩和アルゴリズムの導入により、Scheduler のスケジューリングパフォーマンスを向上

3. Hologres 運用保守システム構築

3.1 Hologres 運用保守システムの概要

OLAP システムで遭遇する問題と課題、および超大規模デプロイのプレッシャ下の運用保守課題に対応するため、Alibaba Cloud ビッグデータ運用保守プラットフォームを活用し、リソースとクラスターデリバリの自動化、クラスターおよびインスタンスレベルのリアルタイム可観測性、インテリジェント自己修復システムを備えた Hologres 運用保守システムを設計し、Hologres の SLA を本番可用性レベルに引き上げました。

3.2 クラスターの自動デリバリ

Hologres は完全にクラウドネイティブ方式で設計・実装されています。ストレージとコンピューティングの分離によりコンピューティングリソースとストレージリソースを切り離し、コンピューティングノードは K8s クラスターを通じてデプロイ・起動されます。独自運用管理システム ABM を通じて、クラスターデリバリではクラスター設計を抽象化し、リソースクラスターとビジネスクラスターの概念を分離しています。リソースクラスターのデリバリでは、ABM が基盤プラットフォームと連携してリソースクラスターを作成・管理し、容量を維持します。ビジネスクラスターでは、ABM が K8s 概念に基づくデプロイテンプレートを提供し、管理制御などのノードをリソースクラスター上で迅速に起動してデリバリを完了します。

3.3 可観測性システム

システムの可観測性は、ビジネスがクラスターの水位をより良く管理し、問題をトラブルシューティングするのに役立ち、エンタープライズレベルの管理制御能力を向上させます。可観測性では、よりシンプルで分かりやすいモニタリング指標を提供するだけでなく、成熟したログ収集システムも必要であり、よりシンプルな運用保守を実現し、ビジネス上の問題のみに責任を負うだけで済むようにする必要があります。Alibaba Cloud のモニタリングプロダクトと Hologres の可観測性要件に基づき、Hologres のリアルタイムモニタリング機能を設計しました。

メトリックモニタリングシステム

詳細なシステム能力の観測、パフォーマンスモニタリング、迅速な問題の特定とデバッグをサポートするため、Hologres は非常に豊富なメトリックモニタリングシステムをサポートしており、メトリックリンク全体の収集、ストレージ、クエリに対して非常に高い要件を課しています。モニタリングリンクには、Alibaba が開発した Emon プラットフォームを選択しました。Emon は毎秒数十億レベルのメトリック書き込みをサポートするほか、自動ダウンサンプリング、集約最適化などの機能もサポートしています。コアメトリックはクラウドモニタリングにエクスポートされ、ユーザーがインスタンスのモニタリングと観測、問題の自己特定を容易に行えるようにしています。

ログ収集モニタリング

ログ収集では、Hologres は成熟したクラウドプロダクトである SLS を採用し、中央集約型ログの検査とフィルタリングをサポートしています。同時に、Hologres のログ量も非常に大きいため、収集ではサブモジュールとグレーディングメカニズムを採用し、コストを制御しています。これにより、トラブルシューティングと監査のニーズを適切に解決できます。同時に、SLS はキーワードベースのモニタリングソリューションも提供しており、重要なエラーに対してアラームを発し、タイムリな問題処理を可能にしています。

メタウェアハウスベースの可用性モニタリング

メトリックとログの収集・アラームでは、特定モジュールに反映される問題が多く、上記の方法だけでは特定のインスタンスの可用性を完全には判断できません。これに基づき、Hologres 運用保守データウェアハウスを構築し、多次元のイベントと状態を通じてインスタンスが正常に動作しているかを包括的に判断しています。多次元データはメタウェアハウスに収集・維持されます。これには、インスタンスのメタデータ、Hologres 内各モジュールの可用性判断基準、インスタンス各モジュールのステータス、および運用保守イベント、顧客イベント、システムイベントなどを含むイベントセンターが含まれます。インスタンスの可用性判断と同時に、メタウェアハウスはインスタンス診断とインスタンス検査のための各種データも提供します。現在、メタウェアハウスの機能はスロークエリログとしてリリースされており、ユーザーはスロークエリログを使用してセルフサービスで問題診断とチューニングを行えます。

3.4 インテリジェント運用保守によるプロダクト SLA の向上

完全な可観測性の基盤の上に、問題特定の速度を向上させ、インスタンス回復時間を短縮、すなわち Hologres の MTTR を改善するため、Alibaba Cloud ビッグデータ運用保守プラットフォームが提供する基本機能とインテリジェント運用保守ソリューションに基づき、完全な Hologres SLA 管理システムと障害診断・自己修復システムを構築しました。

SLA システム

Hologres 運用保守ウェアハウスのデータとインスタンス可用性定義に基づき、Hologres インスタンスレベルの可用性管理システムを確立しました。インスタンス可用性データは ABM SLI データベースに取り込まれます。SLI はデータと条件に基づいてインスタンス可用性モニタリングをトリガーします。モニタリングが発行されると、インスタンスの診断がトリガーされ、システムは診断結果に基づいて自己修復を実行するかどうかを判断します。自動回復が可能と判断された場合は自己修復をトリガーして障害の自動回復を実行し、未知の状況の場合は手動作業指示の生成をトリガーします。作業指示システムは担当者がフォロアップし、徐々に自己修復アクションとして形成されていきます。

インテリジェント検査

インテリジェント検査は、クラスターまたはインスタンスの潜在的かつ非緊急の問題を解決し、オンライン安定性に影響を与えるような軽微な問題の蓄積による質的変化を防止します。明確に定義された検査項目に加え、インテリジェント検査はクラスタリングアルゴリズムなどを導入してシステム指標を分析し、クラスター内の離散ノードを発見してタイムリに処理することで、問題ノードによるインスタンス全体の可用性への影響を回避します。

インテリジェント診断と自己修復

インテリジェント診断は、運用保守ウェアハウスのデータに加え、ログクラスタリング、根本原因分析など診断関連のアルゴリズムサポートにも依存し、エラーログをクラスタリングしてクラスタリング結果にマーキングを行います。ABM が提供するアルゴリズムとエンジニアリング能力のサポートにより、インスタンス診断は既にビジネスが問題を迅速に特定し、問題解決の効率を向上させ、インスタンスの MTTR を短縮するのに役立っています。

4. Hologres プロダクトレベル運用保守機能

前述の Hologres サービス自体の運用保守安定性保証に加え、Hologres プロダクト側では、さまざまな方法でシステムの安定性を向上させています。

4.1 高可用性アーキテクチャ
高可用性アーキテクチャ設計を採用し、長年にわたり Alibaba Group のダブルイレブンなどの大規模プロモーションのトラフィックピークを安定的にサポートし、大規模な本番テストを経ています。具体的には以下の通りです。

・ストレージとコンピューティングの分離アーキテクチャによりシステムの拡張柔軟性を強化
・マルチモーダルレプリケーションによりデータの読み取りと書き込みの分離を解決。主にマルチコピによるスループット向上、シングルインスタンスリソースグループ隔離、マルチインスタンス共有ストレージ高可用性を含む
・スケジューリングシステムによりノードフェールオーバーの迅速な回復能力を向上

4.2 多様なシステム可観測性指標

Hologres 自体のアーキテクチャ設計に加え、ユーザーに多様な観測指標を提供し、クラスター状態のリアルタイムモニタリングと事後レビュを複雑な操作なしで実現でき、ビジネスにのみ集中できます。

・多次元モニタリング指標：CPU、メモリ、接続数、IO などのモニタリング指標をリアルタイムクエリし、リアルタイム早期警告を実現
・スロークエリログ：時間、実行計画、CPU 消費量などの指標を通じて、遅いまたは失敗したクエリを診断・分析し、最適化措置を講じて自己診断能力を向上
・実行計画の可視化：さまざまな表示方法を通じて Query の実行と実行分析を行い、オペレータを詳細に解釈し、最適化の提案をガイドして盲目的な最適化を回避、パフォーマンスチューニングのしきい値を下げ、パフォーマンスチューニングの目的を迅速に達成

5. まとめ

大規模スケジューリングが直面するスケジューリングパフォーマンスボトルネックの分析と対象最適化を通じて、Hologres は 8,192 ノード、さらにはそれ以上の規模のインスタンスデリバリとスケーリングを完了できます。同時に、クラウドネイティブベースの Hologres インテリジェント運用保守システム構築により、大規模クラスターとインスタンスが直面する運用保守効率と安定性向上の問題を解決しました。スループットを処理しながら高性能を実現し、本番レベルの高可用性を実現し、ビジネスをより良くサポートし、企業のデジタルトランスフォーメーションに強力な支援を提供しています。