クラウドネイティブなビッグデータプラットフォームのK8sベースを構築する方法

デジタル変革の加速に伴い、ビッグデータはビジネス管理の主な手段の1つとなり、ますます多くの業界がビッグデータを通じて業績向上を達成することを選択するようになっています。今年初め、CNCF ChinaのディレクターであるChen Zehui氏は、2022 Cloud Native Superhero Conferenceで、Kubernetes（K8s）は現在では普及しており、ますます多くの人々がクラウドネイティブとKubernetesを使用していると述べました。データ時代において、企業はどのようにしてクラウドネイティブのビッグデータ プラットフォームを構築し、K8s を活用してその価値を最大化できるのでしょうか?今日は、Zhiling Cloud Technology のクラウド プラットフォームの R&D マネージャーである Jason と一緒に、その詳細について学びましょう。

背景

クラウド ネイティブ アーキテクチャとは何ですか?

クラウド ホストまたはコンテナー化されたプログラム上で実行されるすべてのプログラムがクラウド ネイティブ プログラムであるとは限りません。

過去 10 年間、クラウド コンピューティングの発展に伴い、クラウド ネイティブ テクノロジー アーキテクチャは徐々に多くのテクノロジー企業に採用され、適用されるようになりました。その概念は次のように要約できます。

• コンテナ化: 実行可能なコードはコンテナ内でリリースする必要がある
• 動的管理: サービスを動的に構成し、使用量に応じて支払う
• マイクロサービス: ノード自体でマイクロサービスを実行するのではなく、K8s などのクラウド オペレーティング システムを使用して、リソース プールのマイクロサービスを公開および操作します。
• オーケストレーション: クラウド プラットフォーム オペレーティング システムを個別に管理するのではなく、基盤となるクラウド プラットフォーム オペレーティング システムの分散管理システムを使用します。
• 自動化: ほとんどの操作は手作業ではなくコードによって実行されます。

クラウドネイティブアーキテクチャの利点

クラウド ネイティブ アーキテクチャを使用すると、マルチテナント、オンデマンド拡張、効率的な反復、コスト削減、セキュリティとコンプライアンスなど、多くの利点があります。

Zhiling Cloud の共同創設者兼 CEO である Peng Feng 博士は、かつて Twitter を例に挙げて、クラウドネイティブ アーキテクチャの利点を強調しました。

「Twitter は 2011 年に独自のプライベート クラウド プラットフォームの構築を開始しました。部門の壁、データ サイロ、アプリケーション サイロ (クラウド プラットフォームとその上のビッグ データ プラットフォームのリリース仕様に準拠する必要があるため) を回避しながら、ビジネス開発の効率が桁違いに向上しました。80 台のマシンからなる Hadoop クラスターから 8,000 台のマシンからなるグローバル データ プラットフォームまで、統合クラスターのデータ機能マトリックスを継続的に拡張して、ビジネス運用をサポートしています。アプリケーションのクラウド ネイティブな性質により、多くのデータ機能構築タスクも可能になりました。」

企業が従来のビッグデータ プラットフォームを使用する際に直面する困難や課題と比較すると、クラウド ネイティブ アーキテクチャの利点がより強調されます。では、クラウドネイティブ アーキテクチャはどのようにしてこれらの困難を解決し、ビッグデータ プラットフォームを構築するための現在の市場トレンドになるのでしょうか?

従来のビッグデータ プラットフォームの難しさは、主にコンポーネントのインストールと運用および保守の複雑さにあります。

• 各ビッグデータ コンポーネントには、独自のインストール プロセス、システム要件、サードパーティ ライブラリのサポート要件があります。
• 独立した分散管理、高可用性、フォールトトレランス、ログ記録、承認、認証メカニズム
• マルチテナント、リソース分離、監査、課金のサポートを実装するのが難しい
• ツールシステムは複雑で、CI/CD、システムテスト、品質管理をサポートできない
• ビッグデータコンポーネントとアプリケーションの混合スケジューリングを実装することは不可能であり、リソースの使用率が低い

そのため、データ アプリケーションの開発プロセスと管理はさまざまなシステム コンポーネントに分散しており、統一されたグローバル管理が欠如しているため、開発と運用の効率が低下します。

従来のビッグデータ プラットフォームに存在する問題により、データ駆動型のビジネス運用のより豊富な要求をサポートすることが徐々に不可能になってきたため、ビッグデータ プラットフォームのクラウドネイティブ性が新たな市場トレンドとなっています。具体的には：

• K8s は基本的にクラウド プラットフォームの標準構成になっています。 K8s に適応するだけで済みます。
• 新しいビッグデータコンポーネントはクラウドネイティブな方法でリリースされることが多くなっています
• Hadoopはクラウドネイティブストレージ+リソーススケジューリングに置き換えられ、既存のHadoopクラスターのワークロードを移行する必要がある
• オリジナルのビッグデータプラットフォームが構築され、DataOpsの必要性が浮上した
• クラウドネイティブアプリケーションの普及に伴い、データソースが徐々に標準化され、オンラインでの統合処理が可能になります。
• デジタルトランスフォーメーションには、敷居が低く、ローコードのセルフサービスプラットフォームが必要

企画・設計

次に、このようなクラウドプラットフォームシステムをどのように計画し、設計するかについて説明します。これは、インフラストラクチャ層 (IaaS)、プラットフォーム サービス層 (PaaS)、アプリケーション配信層から確認できます。各レイヤーでは、現在のビジネス規模とニーズに基づいて、次のようないくつかの問題を検討する必要があります。

• IaaS: インフラストラクチャ管理コストのトレードオフ
• PaaS: K8s バージョン管理、監視、アラーム ログの統合
• アプリケーション配信: コンテナ オーケストレーション レイヤーの複雑な概念を分離し、アプリケーション開発に集中する方法

私たちの目標は、K8s クラウド プラットフォームを提供することです。要件は次の 3 つの側面に分けられます。

• まず、IaaS レイヤーを構築する際には、パブリック クラウドでホストするか、独自のプライベート クラウドを構築するか、あるいは最も複雑なハイブリッド クラウド アーキテクチャを使用するかを決定する必要があります。
• 次に、PaaS レイヤーを構築するときに、ネイティブ K8s を使用するか、K8s の分散バージョン (パブリック クラウド ベンダーの K8s サービス、または Kubesphere、Rancher、OpenShift などのプライベート ディストリビューション) を使用するかを決定する必要があります。
• 最後に、アプリケーション配信システムがあります。私たちの目的は、K8s を構築すること自体ではありません。 K8s プラットフォームの提供後、さらに重要なのは、いかにして業務システムを K8s プラットフォームに迅速かつ柔軟に「移行」し、将来的にはコンテナ ランタイム/ネットワーク/ストレージ インターフェイス、自動障害移行、エラスティック スケーリング、テナント制御など、K8s コンテナ オーケストレーションのさまざまな機能を最大限に活用できるかです。

上記3つの側面における設計計画に関して、現状と問題点は以下のとおりです。

（１）IaaS層：最も重要なのは管理コストとのトレードオフです。パブリック クラウドは構築が最も速く、パブリック クラウド製品を使用できる機能のみが必要です。管理コストは比較的低いですが、製品は非常に高価です。プライベート クラウドでは、仮想化プラットフォームを構築および運用する能力が必要であり、管理コストが比較的高くなります。ハイブリッド クラウドには、最初の 2 つの機能に加えて、ネットワーク インフラストラクチャを構築する機能も必要であり、管理コストが最も高くなります。

（2）PaaS層：公式オープンソース版ではカスタマイズは必要ありませんが、完全なエコシステムを構築するには、ウェアハウス、監視、アラーム、ログ、負荷分散などの追加システムを構築する必要があります。テクノロジの選択は制御可能ですが、高いチーム能力が必要です。ディストリビューション バージョンは一般に比較的完全なエコシステムを提供しますが、テクノロジの選択は制御不能で簡単に制限されることがよくあります。さらに、カスタム要件を満たすのが難しい場合は、自分で構築する必要があります。さらに、K8s バージョンは非常に迅速にリリースされます。新しい機能を使用したり、バグを修正したりしたい場合は、新しいバージョンに追いつく必要がありますが、基盤となるプラットフォームのアップグレードは非常に困難で、事故が発生しやすくなります。

（3）アプリケーション配信：K8sの利点は、一見すると海に浮かぶ美しい島のように見える強力なコンテナ化されたオーケストレーション機能です。欠点は、システムアーキテクチャ、概念原理、管理、使用法が非常に複雑であることです。より深く理解していくと、その島は氷山の一角に過ぎないことがわかります。アプリケーション開発者にとって、プラットフォーム エンジニアは、コンテナ オーケストレーション レイヤーの機能を抽象化、分離、カプセル化、簡素化する必要があります。これにより、上位レベルのユーザーは、氷山全体の重荷を背負うことなく、アプリケーション開発に集中できるようになります。

実装パス

計画と設計のすべてのレベルでの具体的な実践を組み合わせて、私たち自身の実装パスについてお話ししましょう。まず、インフラストラクチャ層とプラットフォーム サービス層では、パブリック クラウド シナリオの場合、Alibaba Cloud Container Service ACK に基づいてパブリック クラウド シナリオで K8s プラットフォームを構築するのが私たちの実践です。

ACK は、Alibaba Cloud の仮想化、ストレージ、ネットワーク、セキュリティ機能を統合し、高性能でスケーラブルなコンテナ アプリケーション管理機能を提供し、エンタープライズ レベルのコンテナ化されたアプリケーションのライフサイクル管理全体をサポートします。

ACK は現在、バージョン 1.22.3 と 1.20.11 をサポートしています。偶数の Kubernetes メジャー バージョンのみがリリースされます。バージョンサポートポリシーは次のとおりです。

• クラスターの作成: ACK は、v1.16 や v1.18 など、Kubernetes の 2 つのメジャー バージョンの作成をサポートしています。 Kubernetes の新しいバージョンがリリースされると、古いバージョンでは関数を作成できなくなります。
• アップグレードと O&M 保証: ACK は、Kubernetes の最新の 3 つのメジャー バージョンの安定した動作を保証し、最新バージョンから以前の 2 つのメジャー バージョンへのアップグレード機能をサポートします。例えば、現在の最新バージョンが v1.20 の場合、ACK は v1.18 および v1.16 のアップグレード機能をサポートします。
• チケット回答: ACK は、Kubernetes の最新の 3 つのメジャー バージョンに対してのみテクニカル サポートを提供します。

そのため、プライベート クラウドのシナリオでは、当社の構築プラクティスでは VMware の技術アーキテクチャ セットを採用し、物理マシンには DELL の PowerEdge シリーズを使用します。 VMware ESXi は物理マシン上に展開され、複数の物理マシン リソースが VMware vCenter Server を通じてリソース プールに編成され、仮想化管理プラットフォームを形成します。

さらに、プライベートリリースのシナリオでは、K8s システム全体をデプロイする必要があり、QingCloud の KubeKey を選択しました。

このオープンソースの K8s インストーラー プロジェクトを使用すると、Kubernetes と KubeSphere を個別に、または全体として簡単に、効率的かつ柔軟にインストールできます。

サポートされている Linux ディストリビューション:

• Ubuntu 16.04、18.04、20.04
• Debian バスター、ストレッチ
• CentOS 7 の場合
• SUSE Linux Enterprise Server 15

サポートされている Kubernetes バージョン:

• v1.17: v1.17.9
• v1.18: v1.18.6
• v1.19: v1.19.8
• v1.20: v1.20.6
• v1.21: v1.21.5 (デフォルト)
• v1.22: v1.22.1

使い方も比較的簡単です。具体的な操作は以下のとおりです。

• クラスターを作成します。

 ./kk クラスターを作成- f config .yaml

• ノードを追加します。

 ./kk ノードを追加- f config .yaml

• ノードを削除するには:

 ./kk ノード<ノード名> を削除-f config .yaml

• クラスターを削除するには:

 ./kk クラスターを作成- f config .yaml

アプリケーション配信レイヤーでは、KubeVela エンジンをベースにしたプラットフォームを構築するのが私たちのやり方です。

すぐに使用できる最新のアプリケーション配信および管理プラットフォームである KubeVela は、ハイブリッド クラウド環境でのアプリケーション配信をよりシンプルかつ高速にします。 KubeVela を使用するソフトウェア開発チームは、オンデマンドでクラウドネイティブ機能を使用してアプリケーションを構築できます。チームの拡大やビジネス シナリオの変化に応じて機能を拡張します。一度ビルドすればどこでも実行できます。

KubeVela は、クラウドネイティブ アプリケーションの配信と管理のシナリオを中心に展開されます。その背後にあるアプリケーション配信モデルは、オープン アプリケーション モデル (略して OAM) です。その中核は、アプリケーションの展開に必要なすべてのコンポーネントと運用および保守アクションを、インフラストラクチャに依存しない統一された「展開計画」として記述し、ハイブリッド環境で標準化された効率的なアプリケーション配信を実現することです。

KubeVela を使用する理由

クラウドネイティブ テクノロジーの開発傾向は、クラウドや環境全体で一貫性の高いアプリケーション配信を実現するために、Kubernetes を共通の抽象化レイヤーとして使用する方向に進んでいます。ただし、Kubernetes は基盤となるインフラストラクチャの詳細を統合することには優れていますが、ハイブリッド分散展開環境上のアプリケーション層のソフトウェア配信モデルや抽象化は提供しません。統一された上位レベルの抽象化のないこのソフトウェア配信プロセスは、生産性を低下させ、ユーザー エクスペリエンスに影響を与えるだけでなく、生産時にエラーや障害を引き起こすこともわかっています。

ただし、最新のマイクロサービス アプリケーションの配信プロセスのモデリングは非常に断片化されており、困難です。これまでのところ、上記の問題を解決しようとする技術的ソリューションのほとんどは、実際の生産使用における問題をカバーするには単純すぎるか、実装するには複雑すぎます。クラウド ネイティブによってもたらされたインフラストラクチャ機能の爆発的な成長により、新世代のアプリケーション管理プラットフォームでは、機能を統合したり、ハードコードされた方法で UI を構築したりすることができなくなりました。基本的な機能とシナリオを満たすことに加えて、プラットフォーム独自の拡張機能が、新時代のアプリケーション管理プラットフォームの中心的な要求となっています。つまり、プラットフォームはシンプルで使いやすいだけでなく、アプリケーションの配信と管理の要件の複雑さが増すにつれて継続的に拡張でき、開発者がセルフサービスでアクセスして使用し、クラウドネイティブ エコシステムのメリットを十分に享受できる必要があります。

これは KubeVela の核となる価値でもあります。ハイブリッド環境 (マルチクラスター/マルチクラウド/ハイブリッド クラウド/分散クラウド) のアプリケーション配信プロセスを簡素化できます。同時に、ビジネスの急速な変化によってもたらされる反復のプレッシャーにいつでも対応できるほど柔軟です。これは、プラットフォーム ビルダーの拡張と自己構築のニーズを満たす、ハイブリッド配信環境向けの高度にスケーラブルなアプリケーション配信エンジンです。同時に、開発者がセルフサービス方式でクラウドネイティブ アプリケーションを開発および提供できるようにする、すぐに使用できる一連の拡張コンポーネントが付属しています。

KubeVela コア機能

統合アプリケーション配信モデル: KubeVela は、アプリケーション配信のトップレベルの抽象化として、革新的なオープン アプリケーション モデル (OAM) を提案しました。このモデルは、コンテナ、データベース、さらには仮想マシンを含むあらゆる種類のワークロードをさまざまなクラウドや Kubernetes クラスターに配信することをサポートします。ユーザーはインフラストラクチャの詳細を心配する必要がなく、アプリケーションの定義と展開にのみ集中する必要があります。アプリケーションは一度オーケストレーションするだけでどこでも実行できるため、さまざまなプラットフォームに適応する手間が省けます。

• 宣言型配信ワークフロー: KubeVela の配信モデル全体は、ユーザー エクスペリエンスと堅牢性の両方を考慮し、ユーザーの宣言によって完全に駆動されます。制御ループにより、構成のドリフトを効果的に回避でき、マルチテナント権限制御機能を備えています。ユーザーは、CUE 言語 (Google Borg システムから派生したデータ構成言語) を使用して、需要シナリオに応じて配信ワークフローの各ステップを自由に設計および選択し、急速なビジネス成長のニーズを満たしながら、最終状態に向けて生産環境の安定性を継続的に確保できます。
• マルチクラスター/ハイブリッド クラウド アプリケーション配信コントロール プレーン: KubeVela は、マルチクラスター/ハイブリッド環境の継続的配信戦略の豊富なセットと、環境間配信をネイティブにサポートします。これらの配信戦略は、分散配信プロセスに十分な効率性とセキュリティの保証を提供します。 KubeVela が提供する集中管理および制御機能により、各クラスターの問題のトラブルシューティングの負担も軽減され、さまざまなプラットフォームに統一されたエクスペリエンスが提供されます。自動配信の利便性を享受するために、Kubernetes の専門家である必要はもうありません。

KubeVela と従来の PaaS プラットフォームの比較

従来の PaaS (Heroku、Cloud Foundry など) は、開発者のエクスペリエンスと効率性を向上させることを目的として、完全なアプリケーションの展開および管理機能を提供します。このシナリオでは、KubeVela も同じ目標を持っています。

ただし、KubeVela とそれらの最大の違いは、そのスケーラビリティです。

KubeVela はプログラム可能です。配信ワークフロー、さらにはアプリケーション配信および管理機能セット全体は、独立したプラグ可能なモジュールで構成されています。これらのモジュールは、CUE テンプレートを記述することでいつでも追加/削除/再定義でき、変更はすぐに有効になります。このメカニズムと比較すると、従来の PaaS システムには多くの制限があります。より優れたユーザー エクスペリエンスを実現するために、アプリケーションの種類や提供される機能にさまざまな制約を課す必要がありますが、アプリケーション配信の要件が増大するにつれて、ユーザーの要求は必然的に PaaS システムの能力を超えてしまいます。これは KubeVela プラットフォームでは決して発生しません。

さらに、KubeVela はランタイム クラスターから独立したアプリケーション配信コントロール プレーンです (これは次世代 PaaS システムの適切な形式であると考えています)。一方、既存の PaaS では、プラグインの形式でランタイム クラスターにデプロイされることが選択されることが多いです。

次に、簡単な例を使って、K8s 上でコンテナ化された方法でアプリケーションまたはサービスをすばやく実行する方法を見てみましょう。

Helmコンポーネントの提供

アプリケーションを配信した後は、そのメトリックとログを監視するためにアプリケーションを運用および保守する必要があります。

これに基づいて、KubeVela エンジン上にクラウド プラットフォームを構築する際に、ログ、監視、アラームに関して対応する自動統合を行いました。監視対象、監視パネル、ログ収集、アラームルール機能の 4 つの主要な側面で対応する開発が行われました。

次の図は、監視対象機能、監視パネル機能、ログ収集機能、およびアラームルール機能を示しています。

上向きの力

先ほど構築した基盤となるクラウド プラットフォーム システムに基づいて、最後にその機能について説明します。

当社の主力製品はワンストップのクラウドネイティブDataOpsプラットフォームであるため、基盤となるクラウドプラットフォームシステムには、上位のコンテナ化ビッグデータプラットフォーム、データ統合開発プラットフォーム、データ資産運用プラットフォーム、データ品質プラットフォームなど、さまざまなデータプラットフォームシステムが搭載されています。

• アプリケーション配信の観点から見ると、クラウド プラットフォームは、Hive、Spark、HDFS などのオフライン コンピューティング プラットフォームの一般的なオープン ソース コンポーネントや、Kafka、Flink などのストリーム処理プラットフォームのオープン ソース コンポーネントなど、データ プラットフォーム上でビッグ データとさまざまなミドルウェアを迅速にコンテナ化して統合することを可能にします。
• マルチテナントの観点から見ると、クラウド プラットフォームは、リソース割り当て管理、認証、承認などのデータ プラットフォームのマルチテナント管理を可能にします。
• 弾力性の観点から見ると、クラウド プラットフォームは、データ プラットフォーム サービスの弾力的なスケーリングとクラスター レベルのスケーリングを可能にします。
• スケジューリングの観点から見ると、クラウド プラットフォームでは、データ プラットフォーム サービスの K8s ネイティブ スケジューリング (Spark on K8s) と、Volcano などの拡張スケジューリング フレームワークの統合が可能になります。

コア エンジンが提供する柔軟性と拡張性により、当社のクラウド プラットフォームは将来的にさらに多くの K8s エコシステムとシステム機能を組み込むことができ、上位のビジネス レイヤーにさらに強力な機能とパフォーマンスのサポートを提供できるようになります。

具体的には、現在の中間結果は以下に反映されています。

• ビッグデータ コンポーネントの迅速な配信: Hive、Spark、HDFS、Kafka、Flink...
• データアプリケーションの迅速な開発と統合：カスタムプログラムのリリース
• 統合された可観測性の統合とプレゼンテーション: 監視、アラート、ログ
• システム全体のマルチテナント実装：テナントクォータ管理、サービス/データ認証+承認

将来的に DataOps をさらに強化する能力は、以下に反映されます。

• 開発・運用：CI/CD、マルチ環境管理
• 可観測性: ビッグデータ プラットフォームのフルリンク トレース
• 弾力的なスケーリング: ビッグデータ操作のための弾力的で適応性のあるリソース
• 強化されたスケジュール機能: Volcano Scheduler により、ビッグデータ システムの有効活用が可能に

著者について

Zhilingyun Technology のクラウド プラットフォームの R&D マネージャーである Jin Jin は、華中科技大学でコンピューター サイエンスの修士号を取得しています。彼は Zhiling Cloud に 6 年以上在籍しており、長年にわたりクラウド ネイティブおよびコンテナ化オーケストレーションの分野で研究開発に従事してきました。彼は、Zhiling Cloud の自社開発 BDOS アプリケーション クラウド プラットフォーム製品の開発を主導し、複数の大規模プロジェクトでそれを実装することに成功しました。大規模なコンテナ化オーケストレーションシステムに関する豊富な実践経験を持っています。