クラウドネイティブ ビッグ データは、ビッグ データ プラットフォームの次世代アーキテクチャおよび運用形式です。ByteDance の社内ビジネスの急速な成長に伴い、多数のコンポーネント、複雑なインストールと運用、基盤となる環境との過剰な結合など、従来のビッグデータ運用および保守プラットフォームの欠点が徐々に明らかになり、ビジネス側にとってはすぐに使用できるログ、監視、アラーム機能が不足しています。これに関連して、当社はクラウドネイティブなビッグデータの運用と保守管理の一連の実践を実行してきました。クラウドネイティブな運用および保守管理の方法を通じて、最終的にビジネス当事者の状態認識を弱め、環境の違いを遮蔽し、異なる環境でのエクスペリエンスを統一することができます。
著者｜ByteDance シニア R&D エンジニア - Luo Laifeng
事業状況と背景のご紹介
過去数年間、ByteDance は自社のビジネスをサポートする過程で
ビッグデータの分野で多くのエンジン ツールを蓄積しており
、現在、
これらのエンジン ツールの
機能の標準化および製品化を模索しています
。この
プロセス
には主に次のような問題があります
。
-
多くの コンポーネント : ビッグ データの分野では 、ジョブを完了するために多くのコンポーネントが必要です。たとえば、分散ビッグ データ ストレージとさまざまなタスク実行エンジン: Flink、Spark、および さまざまな ETL用の OLAPツール 、 ETL をスケジュールするための タスク スケジューリング ツール、ツール エンジンをサポートする実行ログ監視システムとプロジェクト ユーザー権限の補助システム。
-
複雑な導入 : これらのシステムには 複雑に連携する コンポーネントが多数あるため、導入が困難になります。 たとえば、完全な運用環境を展開するには、複数の依存関係や 構成管理が必要となる場合があります 。 基盤となるビッグ データストレージ に対するさまざまなタスク エンジンの依存関係などの強い依存関係があり、ログ監視システムに対するタスク エンジンの依存関係などの弱い依存関係 もあり 、メッセージ ミドルウェアがログを収集する必要があるが、ログ収集自体はメッセージ ミドルウェアに依存しており、それらの構成も相互ネストを形成するなどの循環依存関係さえあります。
-
環境結合 : たとえば、タスク実行エンジンはビッグ データストレージ構成 をネストする必要がある場合があり、ログ収集では各 コンポーネントのディレクトリとその形式を認識する必要がある場合があります。これらの複雑な構成と依存関係は毎日維持する必要があるため、展開が複雑になると環境の結合が発生し、時間の経過とともにこの環境との深い結合が形成され、移行が困難になります。
近年の
クラウド ネイティブの概念の台頭により
、上記の問題を解決するために、これらのツールをクラウド ネイティブに変換することも試みています。
クラウドネイティブシナリオの特徴
-
サービスレスなステータス認識: ユーザーは、その背後にある実行ステータスに注意を払わずに関数を使用でき、その背後にあるロジックを気にする必要もありません。
-
極めて柔軟なスケーリング :実行ステータスをユーザーから隠した 後、 クラウドネイティブのシナリオ ではスケーリングがさらに極端になり、オンデマンドでの使用によりコストを大幅に削減できます。
-
高速フェイルオーバー : 障害が発生した場合 、究極の柔軟なスケーリング機能を利用して、障害のあるノードをすぐに オフラインにし、新しい正常なノードを追加して 高速フェイルオーバー を実現できます。 このフェイルオーバーも、ユーザーにとっては無意味で無害なアクションです。
上記3つの特徴がお互いを高め合い、好循環を生み出します。
クラウドネイティブの進化の方向性
前述のクラウドネイティブな変革については、主に次
のような。
-
コンポーネント マイクロサービス : サービス全体 を責任に応じて複数の小さなコンポーネントに分割することで、 アーキテクチャ 全体の 結合性 が高まり、結合度が低くなり 、環境全体の変化の複雑さが軽減され、大規模な共同開発が容易になります。
-
アプリケーションのコンテナ化 : コンテナは移植性を提供し、環境間の一貫性を確保できます。
-
不変のインフラストラクチャ : すべてのコンテンツをカプセル化することで、基礎となるインフラストラクチャが分離され、それによってインフラストラクチャが不変であることが保証されます。これにより、展開に一貫性、信頼性、シンプルさがもたらされ、環境の状態をより制御しやすくなります。
-
宣言型 API : 宣言型 API を使用すると、ユーザーは達成したい状態を宣言するだけでよく、バックエンド サービスはそれを満たすために最善を尽くします。そのため、ユーザーは特定のプロセスを認識する。
アーキテクチャの進化
クラウドネイティブビッグデータの概要
クラウドネイティブ
ビッグ データ
は主にコンテナ上に構築されます。ここでのコンテナは、パブリック
クラウド
の
コンテナ サービス
または
プライベート クラウドのコンテナ ベースです。プライベート クラウドのコンテナ ベースは、オープン
ソース
のK8s / K8s ベースの変換ベースです。クラウドネイティブ ビッグデータ全体は、3 つの主要なプラットフォームと主要なサポート システムに分けることができます。3つの主要なプラットフォームは、スケジューリング層、エンジン層、プラットフォーム層です。コンテナの上にはリソース スケジューリング層があり、クラスター全体のコンピューティング、ストレージ、およびネットワーク リソースの統合管理とスケジューリングを担当します。スケジューリング レイヤーの上のコア エンジン レイヤーは、主にByte によって開発された統合ビッグデータ ストレージ システムであり、 HDFSセマンティクスと互換性があり、標準の S3オブジェクト ストレージとのドッキングをサポートします。ストレージ層の上位層は、Flink 、Spark 、その他の自社開発または最適化されたコンピューティング エンジン、メッセージミドルウェア、ログ検索エンジン、リアルタイム分析エンジン、その他のツールです。最上位はプラットフォーム サービス層で、これらのエンジン機能をパッケージ化し、外部出力製品に統合する役割を果たします。
今回導入した運用保守管理基盤は、上記3つのプラットフォームに対応し、日々の
コンポーネントの運用保守
のための管理機能を提供するとともに、
ビッグ
データ全体のクラウドネイティブ化への対応を図るため、
運用保守管理モジュールにもクラウドネイティブな改良を加えました。
クラウドネイティブでの運用保守実践
-
低いリソース占有率 : 運用および保守管理モジュールは ユーザー指向の 製品コア機能ではないため、その存在は十分に低く、リソースの割合は十分に小さい必要があり、一部の小規模なシナリオであっても無視できるほどである必要があります。
-
強力なスケーラビリティ : 日常の運用および保守管理では、ログの監視はクラスターのサイズと正の相関があるため、 運用および保守管理に関連するすべての機能は、環境に合わせて水平方向に迅速に拡張する機能を備えている必要があります 。
-
高い安定性 : 運用および保守管理には安定性に対する高い要件があり、障害が発生した場合でも迅速に回復できなければならず、他のコンポーネントに 災害 復旧 管理 機能を提供する必要もあります。
-
強力な移植性 : 運用保守管理モジュールの主な目標の 1 つは、 クラウド ネイティブの ビッグ データ製品全体の迅速な移行をサポートすることです。そのため、環境結合の問題がないことが必要です。また、すべての関連機能は、さまざまな環境で運用保守管理機能の完全なセットを柔軟に提供できるプラグイン設計をサポートする必要があります。
-
環境への意識が弱い ： 環境の違いによる運用保守管理の違いから 上位事業者を保護し、異なる環境 での運用保守管理機能を上位事業者が統一的に利用できるようにする。
そこで、上記の要件を満たすために、注意すべき方向性を以下にまとめます。環境管理の観点からは、さまざまな展開に適応するために一連の統一環境モデルを抽象化する必要があります。さらに、コンポーネントのメタデータの依存関係、構成、その他の情報を統一的に管理するための柔軟で便利なコンポーネント管理サービスが必要です。最後に、ログ、監視、アラームなどの共通機能などの機能を抽象化し、抽象化を通じて上位層のビジネスを環境
の差異から
保護
する機能が必要です。
環境管理とコンポーネントサービス
環境管理
環境全体は、機能に応じて、コントロール プレーン、システム プレーン、データ プレーンの 3 つの論理領域に分割できますが、これら 3 つの領域は論理領域の分割にすぎず、物理環境を分離するものではないことに注意してください。たとえば、一部のシナリオでは、コントロール プレーンをシステム プレーンと結合でき、一部の小規模シナリオでは、3 つのプレーンを 1 つの
物理クラスターに結合することもできます
。
-
コントロール プレーン : 弱いビジネス ベアラーを提供するために使用され、環境制御、原価計算、サービス ゲートウェイを担当する全世界で唯一のサポート作業です。
-
システムプレーン : 各論理ユニット内で一意ですが、システム全体では複数の論理ユニットが存在する可能性があります。たとえば、同じ都市でマルチアクティブ/異なる場所でマルチアクティブのシナリオでは、各論理ユニットはコンピュータ室/エリアに対応し、複数の論理ユニット間の関係はコントロールプレーンの調整に依存します 。
-
データ プレーン : エンジンの動作に必要なコンピューティング、ストレージ、ネットワーク、その他のリソースを提供するために使用され、システム プレーンの統一された調整の下で、複数のデータ プレーンが論理的なフェデレーション クラスター 。
コンポーネントサービス
コンポーネントは環境の領域を分割することでレベルに分割されており、主に
システム レベル、クラスタ レベル、テナント レベル、プロジェクト レベルに分けることができます。システム レベルは、ビジネス管理および制御ロジックの大部分を担当します。クラスター レベルは、主にログ データ/監視データの収集を完了します。エージェントおよび内部の自社開発スケジューラーとオペレーターです。テナント レベルは、主に、特定の大規模ユーザー専用のコンポーネントをサポートするために使用されます。最下位のプロジェクト レベルは、ユーザー ジョブ インスタンス、ミドルウェア インスタンス、およびその他のサードパーティ ツールです。
ここでの分割により、展開全体がグリッド状に分割されるため、各コンポーネントは自身が配置されているグリッドのみに注目すればよく、コンポーネントと環境情報との間の結合は十分に遮蔽される
。
コンポーネントサービス: Helmカスタマイズの改善
K8s は
単一リソースのサポートに非常に適しており、特定の分野での操作も非常に豊富です。しかし、単純なサービスには複数のリソースの連携
も
必要です。たとえば、Deployment では、ビジネス ロジックを実行するために構成を保存するために ConfigMap が必要であり、その後、サービスを外部に簡単に公開するために、Service を介してポータルにアクセスする必要があります。ただし、K8s は、ここでリソースを調整するための優れたツールを提供しません。
オープンソース ソリューション
では
、多くのオープンソース
コンポーネントは
基本的に
K8s 移行用の
Helm Chart を提供しますが、オープンソース エコシステムへの統合を高めるために、Helm に基づいた独自のコンポーネント サービスも構築しました。
オープンソース
Helmコマンド ライン ツールは、クラウド ネイティブシナリオのコンポーネント間のAPI呼び出しには適していないため、オープンソース Helm のサービス指向の詳細なカスタマイズを行い、共通のデプロイメント、アンインストール、アップグレード、およびロールバック要件で API を介して公開し、ビジュアル インターフェイスを追加しました。同時に、詳細なシミュレーション デプロイメントもサポートしており、ユーザーが迅速にデプロイ、検証、デバッグできるようにします。上位レベルのビジネス コンポーネントは、独自のビジネス ドメインにさらに注意を払うことができます。
ディスクの管理
ネイティブ
K8s
はステートレス ロード サポートには非常に適していますが、
ステートフル ロード サポートには少し不十分であり
、主にローカル ディスクの使用に反映されており、次の問題点を分析してまとめました。
-
環境結合 : K8s がローカル ディスクを使用する場合、ローカル ディスクのマウント ポイント、種類、サイズを事前に認識する必要があります。これにより、特定の結合現象が発生します 。
-
低い使用率 : グローバルで統合されたストレージのスケジューリングおよび管理 コンポーネントが欠如しているため、コンポーネント間の効率的な 混合 が形成できず 、全体的なディスク使用率が低くなります。
-
不十分な分離 : ディスクがディスク全体として使用される場合、使用率は低くなりますが、ディスク全体として使用されない場合、 コンポーネント間の分離が不十分になります 。
-
保守の困難さ ：業務運用においては、ディスク上の コンポーネントの動的要件により 拡張・縮小の調整 が必要になることが多いです が、事前にさまざまなユーザーの操作を調整するため、タイムスパンが長く、リンクが長く、保守の難易度が高くなります。
統合されたスケジュール設定
このため、
クラスタのすべてのディスク情報を一元的に収集するだけでなく、一元管理できる管理用の統合
CSI
(Container Storage Interface)セットを開発しました。
これに基づいて、ディスク全体の使用シナリオを 3 つのカテゴリ (共有容量ボリューム、共有ディスク ボリューム、および専用ディスク ボリューム) に分類します。
共有容量ボリュームとは、容量が共有されていることを意味します。
このタイプのシナリオはIO の影響を受けず、強力なスペース容量制限も必要ありませんが、
一時的なデータ ストレージや
典型的な
ビッグ データ
ジョブのログなど、柔軟性に対するより高い要件があります。
共有ディスク ボリュームは IO の影響をあまり受けませんが、分離と永続性に関して特定の要件があり、障害が
発生した場合には取得する必要があります。ただし、取得できなくても、致命的な結果は生じません。最も一般的なシナリオはキャッシュです
。
排他的ディスク ボリュームには高度な IO 分離が必要で、メッセージ ミドルウェア
Kafka
や
HDFS
などの一般的なシナリオが必要です。
ディスク管理の概要
ディスク
管理では
、ディスクは 2 つの大きな領域に分割され、最初の領域はよく使用される EmptyDir などの
K8s
によって維持され、この部分は構成データまたは少量の一時データを保存することをお勧めします。
残りの領域は前述のCSI
による統合管理であり
、主に前述の 3 つのストレージ ボリュームに対応する 3 つの領域に分割され、
共有容量ボリュームは単純なローカル パスに基づいてサポートされます。共有ディスク ボリュームについては、最初にすべてのディスクがボリューム グループにまとめられ、ビジネス コンポーネントが共有ディスク ボリュームを申請するときに論理ボリュームを作成して、
分離
の効果を実現します。
排他的ディスク ボリュームはディスク全体を所有し、統合された
CSIを通じてそれを一連のストレージ クラスに抽象化します。上位レベルのビジネス コンポーネントは、独自のニーズに応じて対応するストレージボリュームを適用できます。パブリッククラウドディスクまたは集中ストレージを使用するシナリオの場合でも、このCSIセットを使用してビジネスにさまざまなストレージ ボリュームを提供し、容量制御を実現し、またこの CSI を使用してディスク情報をコンポーネントから分離することをお勧めします。
統合ログ監視アラーム
ログ
ログはポータビリティを難しくする要因でもあるため、業務の分離、効率的な収集、公平な配信、安全性・信頼性を実現するために、ログ収集リンクの一元管理も実施しています。
現在、ログ収集には 2 つの方法がサポートされています。1 つは、さまざまなコレクタを提供し、主に Java と Python をサポートする侵入型収集です
。この方法は侵入型
で
あるため、ほとんどのコンポーネントはファイルベースの収集に慣れているため、Filebeatを介したファイルベースの収集もサポートしています。収集後、トラフィック制御のためにクラスターのログ エージェントに集約され、さらに統合APIを使用したログ検索シナリオをサポートするために統合集中ストレージに集約されます。また、カスタマイズされたエンジンに対象を絞った API も提供されるため、ユーザーは特定のシナリオに応じて対応する API を使用できます。
2 番目は
Filebeat
コレクション
です。コンテナ シナリオでは、これはファイル ベースのコレクションです。物理マシン ベースの収集とは異なります。主な違いはコンテナの観点にあります。ログ ストレージ パスも実際の物理ストレージ パスとは異なります。この問題を解決するには、まずカスタマイズされたログ ルール
CRDを通じて
独自の収集ルールを宣言し、次に
コンポーネントを通じて
サービスをデプロイします。コンポーネント全体の作成
と更新により、Filebeat の検出メカニズムはログ ルールの CRD の作成、変更
、または削除を
動的に検出し
、それを生成して、 Filebeatホットロード メカニズムを通じて独自のログ収集ルールにロードします。
Filebeatのデプロイメント形式
では
、クラスターのノード情報を認識でき、対応する権限を持っている場合は、それを DeamonSet としてデプロイできるため、
全体の
リソース比率
が低くなり
、クラスターは
データ
収集に Filebeat のセットを使用します
。
パブリック クラウド コンテナ サービスのシナリオでは特定のノード情報が認識されず、DeamonSet をデプロイする権限がないため、特定の Pod にサイドカーを挿入してログを収集することがサポートされており、これによりコンテナ内の
ファイル
ベースのログ収集を統合できます。
ログデータリンク
クラウド ネイティブのシナリオ
では
、ログ収集は単なる統合収集リンクではなく、リソース消費を最小限に抑えた効率的なログ収集をサポートします。クラウドネイティブのシナリオは本来
マルチテナント指向であるため
、テナントとコンポーネント間のトラフィックは大きく変化
し
、単一テナントの異常なトラフィック
が
ログ収集全体に障害を引き起こすことはありません。そこで、各クラスタ内のログ
エージェントで
テナントのトラフィックを制御し、異常に大きなトラフィックが発生した場合にはフロー
を制限し
たり
融合したりする措置を講じます
。同時に、マルチテナントシナリオでの公平な分散、ログ収集のフェイルオーバー、クラウドネイティブシナリオでの
ポッド再構築/アクティブアップグレード
なども確保する必要があります。これらの部分が、今後の主な投資の大まかな方向性となります。
警報
アラーム システム全体は、
オープン ソースの
Nightingaleに基づいて
変換され
、
オープン ソースの Nightingale の概要には、インジケーター データを保存するためのPrometheus 、アラーム ビジネス データを保存するためのデータベース、およびコアコンポーネント: WebApi と Server が含まれます。WebApi は、ルールの追加、削除、変更、クエリ、インデックス クエリの実行などのユーザー操作を行うために使用されます。サーバーは、ルールのロード、アラーム イベントの生成、アラーム通知の送信などを担当します。オープンソースの Nightingale では、Server が Prometheus の PushGateway の役割も担っていますが、Byte の製品は独自のユーザー システムと監視システムを持っているため、アラームのカスタマイズは主に WebApi と Server に集中しています。
プロセスの概要
ユーザーはまず WebAPI を通じて独自のアラーム ルールを生成し、データベースに永続化します。その後、サーバーはそのルールを自身のメモリにロードし、
コンシステントます。アラーム イベントが発生すると、対応する制御モジュールが呼び出されてアラーム通知が送信され、アラーム イベントがデータベースにバックフィルされます。主な最適化は次の側面に反映されます。
-
まず、当社の製品システムは、運用保守管理基盤と同様の統一ユーザーシステムを採用しており、これをベースにユーザーグループ機能や 職務リスト機能を追加し、警報分野の利用習慣に合わせたものとなっております。
-
第 2 に、 オープンソースの Nightingale は ログ ルールを完全に読み込みますが、潜在的なパフォーマンス リスクが存在します。完全読み込みを増分読み込みに 変換することで、 関連するパフォーマンス リスクをさらに排除します。
-
第三に、アラーム通知モジュールは環境と強い結合関係を持っています。 DingTalk、Enterprise WeChat、 Feishu 、SMS 通話など、 環境によってアラーム通知は大きく異なるためです。同じ SMS アラームであっても、環境が異なると SMS プロバイダーやドッキング インターフェイスが異なる場合があるため、 動的メッセージ テンプレートの機能が提供されます。
フィードテンプレート
-
アラーム イベントに関する一部の情報は、動的メッセージ テンプレートを通じて参照でき、豊富なコンテキストを備えたアラーム情報を組み立てて、アラーム システムをより柔軟にし、エクスペリエンスを 向上させることができます 。
-
通知方法はプラグインとして設計されており、ユーザーは環境ごとに異なる送信プラグインを開発するだけで済み、コアプロセスの一貫性も確保できます。
通知モジュール
通知モジュールでは、アラーム イベントがサーバーによって生成され、その後、前のメッセージ テンプレートをレンダリングすることによって実際のアラーム メッセージが取得され、その後アラーム メッセージが通知モジュールに送信されます。通知モジュールは、通知メソッドとオブジェクトに基づいて通知レコードを生成し、それをキューに入れ
ます
。さまざまな環境によりよく適応するために、ここでのキューは実際のメッセージ キュー、またはデータベースを通じてシミュレートされたメッセージ キューにすることができます。
最後に、複数のワーカーが同時に情報を消費し、さまざまな送信プラグインを呼び出してメッセージを送信します。ワーカーのほかに、失敗したメッセージの送信を再試行するための全体的な送信ステータスの定期的なスレッドの
ポーリング/
検査もあり、再試行回数が一定の回数に達すると運用およびメンテナンスのアラームが生成されます
。
オープンソースの
ナイチンゲールシステム
のもう 1 つの大きな特徴は動的しきい値であり、全体的な使用において、イベントが発生し、アラームがトリガーされ、トレーニング分析への手動フィードバックが循環
教師あり学習のプロセスを形成し
、動的しきい値の生成ルールが常に調整されます。
モニター
全体的な監視アーキテクチャの概要では、上位層が前述のデータ プレーンであることがわかります。データ プレーンの各クラスタには、物理クラスタのすべてのコンポーネントの監視データを収集および集約するための Prometheus があります。ここで、Prometheus は本質的にエージェントであり、データ ストレージ、クエリ、およびその他の責任を負いません。最後に、Prometheus は、収集された監視データをシステム プレーン上の監視システムにリモートで書き込みます。
監視システムは、
すべての監視データを保存するために使用されます。データ ストレージの水平スケーリングを容易にするために、抽象化レイヤーも作成されます。その背後にある実際の実装は、パブリック クラウド上の既存のクラウド モニタリング サービス、S3 のオブジェクト ストレージ サービス、または自社開発のビッグ データ ストレージ サービスです。一部のプライベート クラウド シナリオでは、ユーザー定義のストレージ サービスに接続することもできます。この層の統合ストレージでは、すべての監視データのクエリ サービスを引き受けるクエリ サービスが追加され、視覚的な大規模表示とフロントエンド インタラクションが形成されます。
クエリ サービス
に対して も、対象を絞った最適化が行われています。例えば、監視データが追加されるだけで更新されない、一定期間の監視データが頻繁に繰り返し取得される場合、時間スパンの大きなクエリをスパンの小さな複数のサブクエリに分割して同時実行し、集計・呼び出しを行うことでクエリの速度を向上させる水平分割機能を導入します。さらに、監視データ自体は不変であるため、クエリされたデータの一部に対してキャッシュを作成し、予測を容易にするクエリ シナリオを追加できるキャッシュを導入しました。上記 2 つの最適化を相互に促進することで、全体的なクエリ効率が向上します。
全体的に最適化されたモニタリング システムの主な利点は、さまざまな環境でワンクリックの指標収集をサポートできることです。パフォーマンスの最適化の観点から、データの事前集約、ダウンサンプリングなどの機能をサポートし、システム全体の機能を強化します。また、ストレージとコンピューティングをある程度分離する特性を持つビッグ データ ストレージに接続し、システム全体の水平方向の拡張性を大幅に強化します。最後に、ログ、アラーム、リンク追跡などのモニタリングおよびその他の運用およびメンテナンス ツールも深く統合します。機能を強化し、製品の全体的なユーザー エクスペリエンスを最適化します。
Volcano Engine のクラウド ネイティブ コンピューティング製品のパノラマ
{{名前}}
{{名前}}