複雑な分散アーキテクチャにおけるコンピューティングガバナンスへの道

導入

現在の複雑な分散アーキテクチャ環境では、サービス ガバナンスが普及しています。ただし、上位レベルの APP とサービスから基盤となるコンピューティング エンジンまでの次のレベルを見ると、各エンジンは依然として独立して動作しており、クライアント サーバー モデルはあらゆる場所で緊密に結合されています。複雑な環境におけるさまざまな種類の多数のコンピューティング タスクを、より簡潔で柔軟、秩序正しく、制御可能な方法で送信および実行し、結果を確実に返すことができるように、「コンピューティング ガバナンス」を実装するにはどうすればよいでしょうか。コンピューティングミドルウェア Linkis は、上記の問題を実践したものです。

[[311888]]

1. 複雑な分散アーキテクチャ環境におけるコンピューティング ガバナンスの問題点は何ですか?

1. 複雑な分散アーキテクチャ環境とは何ですか?

分散アーキテクチャとは、システムのコンポーネントがネットワークで接続された異なるコンピューターに分散されていることを意味します。コンポーネントは、ネットワークを介してメッセージを渡すことで通信および調整し、共同で特定の目標を達成します。一般的に、高凝集性と低結合性、高同時実行性、高可用性などの問題を解決するための分割方向は、水平（クラスタリング）と垂直（機能モジュール分割）の 2 つがあります。

複数の分散アーキテクチャ システムが分散システム クラスターを形成し、比較的複雑な分散アーキテクチャ環境が作成されます。通常、複数の上位層アプリケーション サービスと、複数の基礎となる基本的なコンピューティング エンジンおよびストレージ エンジンが含まれます。次の図に示すように:

2. 計算ガバナンスとは何ですか?

『マイクロサービス設計』という本でも述べられているように、都市計画者が大規模で複雑かつ絶えず変化する都市に直面したときに計画、設計、管理を行う必要があるのと同様に、大規模で複雑なソフトウェア システム環境内のさまざまな領域、要素、役割、関係も、混乱を招くことなく、より簡潔でエレガント、秩序正しく、制御可能な方法で連携できるように規制および管理する必要があります。

現在の複雑な分散アーキテクチャ環境では、多数のアプリとサービス間の通信、調整、管理には、SOA（サービス指向アーキテクチャ）からマイクロサービスまでの成熟した概念と、ESBからサービスメッシュまでの多数のプラクティスがあり、サービス登録と検出、構成管理、ゲートウェイルーティングからフロー制御と回路遮断、ログ監視など、一連のサービスガバナンス機能の完全なシリーズを実現しています。サービスガバナンスフレームワークの「ミドルウェア」層設計は、サービス間の分離、異種シールド、相互運用性を効果的に実現し、ルーティング、フロー制御、状態管理、監視などのガバナンス機能の共通の抽出と再利用を提供し、アーキテクチャ全体の柔軟性、制御機能、スケーラビリティ、保守性を向上させます。

しかし、次のレベルを見ると、APP、サービスからバックグラウンド エンジン レベルまで、各エンジンは依然として互いに独立しており、クライアント サーバー モデルはどこでも緊密に結合されていることがわかります。多数の上位アプリケーションと多数の基礎エンジンの間には、共通の「ミドルウェア」フレームワーク設計が欠けています。下の図のメッシュと同様です。

コンピューティング ガバナンスは、上位レベルのアプリケーションと基礎となるコンピューティング (ストレージ) エンジン間のクライアントからサーバーへの接続層における密結合、柔軟性と制御の欠如、再利用性の欠如、スケーラビリティ、保守性の低さに重点を置いています。複雑な分散アーキテクチャ環境におけるさまざまな種類のコンピューティング タスクを、より簡潔で柔軟、秩序正しく制御可能な方法で送信および実行し、結果を正常に返すことを可能にする必要があります。次の図に示すように:

3. 計算ガバナンス問題の説明

コンピューティング ガバナンスの問題をさらに詳しく見ると、ガバナンス (アーキテクチャ) とインサイト (洞察) の 2 つのレベルに分けることができます。

（１）コンピューティングガバナンス（アーキテクチャ） - アーキテクチャ上の問題。

密結合の問題、上位層アプリケーションと基盤となるコンピューティングおよびストレージ エンジン間の CS 接続モード。

すべてのアプリ、サービス、および基盤となるコンピューティング エンジンとストレージ エンジンは、クライアント サーバー モデルを通じて接続され、緊密に結合されています。以下に示すように、Analytics Engine の Spark を例に挙げます。

この状況により、次のような問題が発生します。

• エンジン クライアントへの変更 (バージョン アップグレードなど) は、クライアントが組み込まれているすべての上位層アプリケーションに直接影響します。アプリケーションシステムの数が多く規模が大きい場合、変更にかかるコストは非常に高くなります。
• 直接接続モードでは、基盤となるコンピューティングおよびストレージ エンジン インスタンス レベル全体にわたる上位層アプリケーションのルーティングおよび負荷分散機能が不足します。言い換えれば、特定の基盤エンジンによって提供される特定の接続方法に依存しますが、一部のエンジンではそれが可能で、一部のエンジンでは不可能です。
• 時間が経つにつれて、新しい上位層アプリケーションと新しい基盤エンジンが絶えず追加され、全体的なアーキテクチャと呼び出し関係がより複雑になり、スケーラビリティ、信頼性、保守性が低下します。

車輪の再発明の問題は、各上位レベルのアプリケーション ツール システムがコンピューティング ガバナンスの問題を繰り返し解決する必要があることです。

各上位層アプリケーションは、さまざまなクライアントを繰り返し統合し、基盤となるエンジン メタデータの取得と管理を含む、クライアントとエンジンの接続とそのステータスを作成および管理する必要があります。同時ユーザー数が増加し、同時コンピューティング タスクの量が増えると、各上位層アプリケーションは、リソース競合、権限分離、コンピューティング タスクのタイムアウト管理、クライアント側の複数のユーザー間の失敗の再試行などのコンピューティング ガバナンスの問題を繰り返し解決する必要があります。

Web ベースの IDE 開発環境、ビジュアル BI システム、レポート システム、ワークフロー スケジューリング システムなど、100 を超える同時タスクを実行する上位レベルのアプリケーションが 10 個あり、それぞれが 3 つの基盤となるコンピューティング エンジンに接続されているとします。前述のコンピューティング ガバナンスの問題を 1 つずつ 10*3=30 回解決しなければならない場合があり、これはさまざまな企業で常に発生している現実です。これによって生じる人的資源の浪費は軽視できない。

拡張は困難です。上位層アプリケーションは、基盤となるコンピューティング エンジンに接続する必要があり、メンテナンス コストが高く、大きな変更が必要になります。

CS の密結合モードでは、上位層アプリケーションが新しい基盤となるコンピューティング エンジンに接続するたびに、大きな変更が必要になります。

Spark とのドッキングを例にとると、Spark ジョブを送信する必要がある上位アプリケーション システムの各マシンでは、Java および Scala ランタイム環境と変数をデプロイおよび維持し、Spark クライアント パッケージをダウンロードしてデプロイし、Spark 関連の環境変数を構成および維持する必要があります。 Spark on YARN モードを使用する場合は、Spark ジョブを送信する必要がある各マシンに Hadoop 関連の jar パッケージと環境変数をデプロイして管理する必要もあります。 Hadoop クラスターで Kerberos を有効にする必要がある場合、残念ながら、上記の各マシンで、keytab やプリンシパルなどの一連の Kerberos 関連の構成を維持およびデバッグする必要もあります。

これは、Spark に接続するための単なる低レベル エンジンです。上位層のアプリケーション システムと基盤となるエンジンの数が増えるにつれて、維持する必要がある関係は直積的に増加します。クライアントと構成の展開と保守だけでも頭痛の種になります。

アプリケーション アイランドの問題と、異なるアプリケーション ツールと異なるコンピューティング タスク間の相互運用性。

複数の相互に関連する上位層アプリケーションでは、バックグラウンド エンジンに実行のため送信されるさまざまなコンピューティング タスク間に、ユーザー定義のランタイム環境変数、関数、プログラム パッケージ、データ ファイルなどを共有する必要があるなど、何らかの接続と共通点があることがよくあります。現在の状況では、各アプリケーション システムは孤立した島のようになっています。関連する情報とリソースは直接共有することができず、さまざまなアプリケーション システムで手動で繰り返し定義および管理する必要があります。

典型的な例としては、データバッチ処理プログラムの開発中に、データ探索および開発 IDE システムでユーザーが定義した一連の変数と関数を、データ視覚化システムで再定義する必要があることが挙げられます。 IDE システムによって生成されたデータ ファイルの場所と名前を、視覚化システムに直接かつ便利に渡すことはできません。依存するプログラム パッケージも IDE システムからダウンロードし、視覚化システムに再アップロードする必要があります。ワークフロー スケジューリング システムの場合、このプロセスを繰り返す必要があります。異なる上位層アプリケーション間のコンピューティング タスクの実行依存関係には、相互通信機能と再利用機能が欠けています。

（２）計算ガバナンスの洞察 - 詳細な機能の問題：

上記のアーキテクチャ上の問題に加えて、複雑な分散アーキテクチャ環境におけるさまざまな種類のコンピューティング タスクをより簡潔で柔軟、秩序正しく、制御可能な方法で送信および実行し、結果を正常に返すためには、コンピューティング ガバナンスでは、高同時実行性、高可用性、マルチテナント分離、リソース管理、セキュリティ強化、コンピューティング戦略などの詳細な機能にも重点を置く必要があります。これらの質問は比較的簡単で理解しやすいので、ここでは一つ一つ説明しません。

2. Linkis コンピューティング ミドルウェアに基づくコンピューティング ガバナンス - アーキテクチャ

1. Linkisアーキテクチャ設計の紹介

コア機能モジュールとプロセス

コンピューティング ミドルウェアである Linkis は、密結合、車輪の再発明、拡張の難しさ、アプリケーション アイランドなどの前述のコンピューティング ガバナンスの問題を解決するために WeBank によって特別に設計されました。現在、重点は、複雑な分散アーキテクチャの典型的なシナリオ、つまりデータ プラットフォーム環境におけるコンピューティング ガバナンスの問題を解決することにあります。

Linkis はコンピューティング ミドルウェアとして、上位層アプリケーションと基盤となるエンジンの間に中間層を構築します。上位レベルのアプリケーションは、外部に提供される標準化されたインターフェイス (HTTP、JDBC、Java など) を通じて、さまざまな基盤となるコンピューティング エンジンやストレージ エンジン (Spark、Hive、TiSpark、MySQL、Python など) にすばやく接続し、さまざまな種類のコンピューティング タスクを送信して実行し、上位レベルのアプリケーション間でコンピューティング タスクのランタイム コンテキストと依存関係の相互通信と共有を実現できます。また、マルチテナント、高同時実行、タスク分散および管理戦略、リソース管理などの機能をサポートすることで、さまざまなコンピューティングタスクをより柔軟かつ確実に制御しながら送信および実行し、結果を正常に返すことができるため、コンピューティングガバナンス層の上位アプリケーションの開発および運用コストと環境全体のアーキテクチャの複雑さが大幅に削減され、一般的なコンピューティングガバナンスソフトウェアのギャップが埋められます。

Linkis を介したコンピューティング タスクの送信と実行のプロセスをより詳しく理解するために、まず Linkis のコアの「コンピューティング ガバナンス サービス」部分の内部アーキテクチャとプロセスを見てみましょう。以下のように表示されます。

コンピューティング ガバナンス サービス: コンピューティング ミドルウェアのコア コンピューティング フレームワークであり、主にジョブのスケジューリングとライフサイクル管理、コンピューティング リソース管理、エンジン コネクタのライフサイクル管理を担当します。

パブリック拡張サービス: 基本的なパブリック機能を提供し、さまざまな Linkis サービスおよび上位層アプリケーション システムにサービスを提供できる一般的なパブリック サービス。

コンピューティング ガバナンス サービスの主なモジュールは次のとおりです。

• エントリ サービス Entrance は、ジョブ要求を受信し、対応するエンジンにジョブ要求を転送し、非同期キュー、高同時実行性、高可用性、およびマルチテナント分離を実装する役割を担います。
• アプリケーション管理サービス AppManager は、すべての EngineConnManager と EngineConn の管理を担当し、EngineConnManager レベルおよび EngineConn レベルのラベル付け機能を提供します。新しいエンジン プラグインをロードし、RM からリソースを適用し、リソースに基づいて EngineConn を作成するように EM に要求します。ラベル付け関数に基づいて、使用可能な EngineConn をジョブに割り当てます。
• リソース管理サービス ResourceManager は、リソース アプリケーションを受信し、リソースを割り当て、システム レベルおよびユーザー レベルのリソース管理機能を提供し、EngineConnManager レベルおよび EngineConn の負荷管理を提供します。
• エンジン コネクタ管理サービス EngineConn Manager は、EngineConn の起動、EngineConn のライフ サイクルの管理、およびリソースと負荷の状態を RM に定期的に報告する役割を担います。
• エンジン コネクタ EngineConn は、基盤となるエンジンとの対話、ユーザー ジョブの解析と変換、基盤となるエンジンへのコンピューティング タスクの送信、基盤となるエンジンの実行のリアルタイムでの監視、関連するログ、進行状況、ステータスの Entrance へのプッシュバックを担当します。

上図に示すように、ジョブの投入と実行は主に次の 11 のステップに分かれます。

1. 上位層アプリケーションがコンピューティング ミドルウェアにジョブを送信し、マイクロサービス ゲートウェイ SpringCloud Gateway がジョブを受信して​​ Entrance に転送します。

2. 消費ジョブを開始し、ジョブに対して AppManager から利用可能な EngineConn を申請します。

3. 再利用可能なエンジンがない場合、AppManager は ResourceManager からリソースを申請し、ジョブ用に新しい EngineConn を開始しようとします。

4. リソースを申請し、リソースに応じてEngineConnManagerに新しいEngineConnを起動するように依頼します。

5.EngineConnManager は新しい EngineConn を開始し、新しい EngineConn 情報を積極的にプッシュバックします。

6. AppManager は新しい EngineConn を Entrance に割り当て、Entrance は EngineConn をユーザー ジョブに割り当てます。ジョブの実行が開始され、計算タスクが EngineConn に送信されます。

7.EngineConn は、基盤となるコンピューティング エンジンにコンピューティング タスクを送信します。

8.EngineConn は、基盤となるエンジンの実行をリアルタイムで監視し、関連するログ、進行状況、ステータスを Entrance にプッシュバックします。 Entrance は、EngineConn によって送信されたログ、進行状況、ステータスを WebSocket を介して上位アプリケーション システムにアクティブにプッシュバックします。

9. EngineConn が実行されると、コンピューティング タスクのステータスと結果セット情報がプッシュバックされ、Entrance はジョブと結果セット情報を JobHistory に更新して上位アプリケーション システムに通知します。

10. 上位アプリケーション システムは JobHistory にアクセスして、ジョブと結果セットの情報を取得します。

11. 上位層アプリケーションシステムはストレージにアクセスし、ジョブ結果セットを要求します。

コンピューティングタスク管理戦略サポート

複雑な分散環境では、コンピューティング タスクは単純な送信、実行、結果の返却だけではないことがよくあります。また、送信の失敗、実行の失敗、ハングなどの問題が発生する可能性もあります。多数の同時実行シナリオでは、テナント間の相互影響や負荷分散などの問題を解決するために、コンピューティング タスクをスケジュールして分散することも必要です。

Linkis は、コンピューティング タスクにラベルを付けることによって、タスクのスケジュール設定、配布、ルーティングなどの観点からコンピューティング タスク管理戦略をサポートし、必要に応じてタイムアウト、自動再試行、グレースケール、マルチアクティブなどの戦略サポートを構成できます。

Spring Cloudマイクロサービスフレームワークに基づく

ビジネス アーキテクチャについて説明しましたが、次は技術アーキテクチャについて説明しましょう。コンピューティング ガバナンス層環境では、多くの種類のコンピューティング タスクのライフ サイクルが短くなります。たとえば、Spark ジョブは数十秒から数分で完了する可能性があり、EnginConn (EnginConnector) は多数の動的な開始および停止状態になります。 Linkis のフロントエンド ユーザーおよびその他の管理ロール サービスは、関連するサービス インスタンスのステータス変更をタイムリーに動的に検出し、最新のサービス インスタンス アクセス アドレス情報を取得できる必要があります。同時に、モジュール間の通信、ルーティング、調整、および各モジュールの水平拡張、負荷分散、高可用性などの機能も考慮する必要があります。

上記の要件に基づいて、Linkis は実際には Spring Cloud マイクロサービス フレームワーク テクノロジーに基づいています。上記の各モジュール/ロールはマイクロサービスにカプセル化されており、Linkis の完全なコンピューティング ミドルウェア機能を統合するために複数のマイクロサービス グループが構築されています。

マルチテナント管理の観点から、上記のサービスは、テナント関連サービスとテナント非依存サービスの 2 種類に分けられます。テナント関連サービスとは、Entrance、EnginConn（EnginConnector）Manager、EnginConnなど、タスクロジックの処理負荷が大きく、リソース消費量が多く、または相互影響を避けるために特定のテナント、ユーザー、物理マシンなどに応じて分離・分割する必要があるサービスを指します。 App Manger、Resource Manager、Context Service などの他のサービスはテナントに依存しません。

Eureka は、マイクロサービスの動的な登録および検出センターとして機能し、テナントに依存しないすべてのサービスの負荷分散およびフェイルオーバー機能としても機能します。

Eureka には制限があります。つまり、クライアント側では、バックエンド マイクロサービス インスタンスの検出およびステータス更新メカニズムは、クライアントがアクティブにポーリングして更新し、最速でも 1 秒に 1 回に設定できます (実際には更新が完了するまでに数秒かかります)。このように、多数のバックエンド EnginConn サービスのステータスを迅速に更新する必要がある Linkis などのシナリオでは、適時性を満たすことができず、Eureka サーバーとバックエンド マイクロサービス インスタンスに対するスケジュールされたポーリング更新のコストが非常に高くなります。

この目的のために、Spring Cloud Ribbon を変更し、Eureka クライアントのマイクロサービス インスタンス ステータス更新メソッドをその中にカプセル化し、頻繁な定期ポーリングではなく、条件が満たされたときにアクティブに更新を要求するようにしました。これにより、タイムリーな要件を満たしながら、ステータス取得のコストが大幅に削減されます。

Spring Cloud Gateway は、Linkis への外部リクエストのエントリ ゲートウェイの役割を果たし、フロントエンド ユーザーの呼び出しロジックを簡素化し、サービス インスタンスが絶えず変化する場合に最新のサービス インスタンス アクセス アドレス情報を迅速かつ簡単に取得するのに役立ちます。

Spring Cloud Gateway には制限があり、WebSocket クライアントは特定のバックグラウンド サービスにのみリクエストを転送でき、WebSocket クライアントはゲートウェイ API を介して複数のバックグラウンド WebSocket マイクロサービスに接続できません。これは、Entrance HA やその他のシナリオで必要です。

この目的のために、Linkis は Spring Cloud Gateway に対応する変更を加え、クライアントとの WebSocket 接続を確立するために Gateway に WebSocket ルーティング フォワーダーを実装しました。接続が正常に確立されると、クライアントの WebSocket 要求が自動的に分析され、ルールを使用して要求を転送するバックエンド マイクロサービスが決定され、WebSocket 要求は対応するバックエンド マイクロサービス インスタンスに転送されます。詳細については、Github の Linkis の Wiki にある記事「Gateway のマルチ WebSocket リクエスト転送実装」を参照してください。

Spring Cloud OpenFeign が提供する HTTP リクエスト呼び出しインターフェースと解析テンプレート機能は、Linkis が基盤となる RPC 通信フレームワークを構築するのに役立ちました。

ただし、Feign ベースのマイクロサービス間の HTTP インターフェイス呼び出しでは、単純なルールに従って B マイクロサービスの中からサービス インスタンスをランダムに選択するという単純な A マイクロサービス インスタンスのみを満たすことができます。 B マイクロサービス インスタンスが呼び出し元に非同期的に情報を返そうとすると、それは不可能です。同時に、Feign は単純なサービス選択ルールのみをサポートしているため、指定されたマイクロサービス インスタンスにリクエストを転送することはできず、受信側マイクロサービスのすべてのインスタンスにリクエストをブロードキャストすることもできません。

Linkis は、Feign に基づく独自の基盤となる RPC 通信ソリューションを実装しており、これはすべての Linkis マイクロサービスに統合されています。マイクロサービスは、リクエストの呼び出し側とリクエストの受信側の両方になることができます。リクエストの呼び出し元として機能する場合、ターゲットの受信側マイクロサービスの Receiver は Sender を通じてリクエストされます。リクエスト受信者として機能する場合、同期応答または非同期応答を完了するために、リクエスト受信者送信者によって送信されたリクエストを処理するために受信者が提供されます。下の図の通りです。詳細については、Github の Linkis Wiki にある記事「Linkis RPC アーキテクチャの概要」を参照してください。

これまで、Linkis は、Spring Cloud マイクロサービス フレームワークに基づいて、上位層アプリケーションと基盤エンジンの分離原則、そのコア アーキテクチャとプロセス設計、マイクロサービスの動的管理、通信ルーティング、各モジュールの水平拡張機能などを紹介してきました。

2. 分離: Linkis が上位層アプリケーションと基盤エンジンを分離する方法

Linkis はコンピューティング ミドルウェアとして、上位層アプリケーションと基盤となるエンジンの間に中間層を構築します。上位レベルのアプリケーションのすべてのコンピューティング タスクは、まず HTTP、WebSocket、Java などのインターフェイスを介して Linkis に送信され、その後 Linkis によって基盤となるエンジンに転送されます。 CS モードでは、基盤となるエンジンに直接接続されていた元の上位層アプリケーションの密結合が解除され、分離が実現されます。次の図に示すように:

分離により、基盤となるエンジンへの変更は Linkis ミドルウェアによってバッファリングされます。例えば、エンジン・クライアントのバージョンアップの際には、接続された上位層アプリケーションを一つずつ変更する必要はなく、Linkis層で統一的に完了することができます。また、グレースケール切り替え、マルチアクティブ、その他の戦略サポートなど、Linkis 層の上位層アプリケーションに対して、より透過的で使いやすいアップグレード戦略を実装することもできます。その後、さらに上位層のアプリケーションや基盤エンジンが接続されても、環境全体の複雑さは大きく変化せず、開発や運用保守の負担が大幅に軽減されます。

3. 再利用: 上位層アプリケーションの場合、Linkis はコンピューティング ガバナンス モジュールをどのように凝縮して再利用し、重複開発を回避しますか?

上位層アプリケーションの再利用 Linkis の例 (Scriptis)

Linkis を使用すると、上位レベルのアプリケーションは、Linkis に基づく複数のバックエンド コンピューティングおよびストレージ エンジンのドッキング サポートを迅速に実装できるほか、変数、関数、リソース制御、マルチテナント、インテリジェント診断のカスタマイズと管理などのコンピューティング ガバナンス機能も実装できます。

利点：

たとえば、WeBank と Linkis がオープンソース化したインタラクティブなデータ開発および探索ツールである Scriptis を考えてみましょう。 Scriptis 開発者は、Web UI、複数のデータ開発言語のサポート、スクリプト編集機能などの純粋なフロントエンド機能の実装にのみ集中する必要があります。 Linkis は、ストレージの読み取りと書き込み、コンピューティング タスクの送信と実行、ジョブ ステータス ログの更新、リソース管理など、ほぼすべてのバックエンド機能を処理します。 Linkis の大規模なコンピューティング ガバナンス レイヤー機能を再利用することで、Scriptis プロジェクトの開発コストが大幅に削減され、現在、Scriptis ではメンテナンスとバージョン反復作業を完了するために限られた数のフロントエンド担当者のみが必要になっています。

下の図に示すように、Scriptis プロジェクトのコードのうち 99.5% はフロントエンドの JS および CSS コードです。背景は基本的にLinkisをそのまま再利用しています。

4. 急速な拡張: Linkis はどのようにして最小限の開発労力で新しい基盤エンジンとの迅速な統合を実現するのでしょうか?

モジュラー式のプラグ可能なコンピューティングエンジンアクセス設計、新しいエンジンアクセスはシンプルで高速

一般的なインタラクティブ コンピューティング エンジン (タスクの送信、実行、および結果の返却) の場合、ユーザーは buildApplication と executeLine の 2 つのメソッドのみを必要とします。はい、たった 2 つの方法、2 つの方法で、非常に少ないコードで新しいコンピューティング エンジンを Linkis に接続できます。以下に例を示します。

(1) AppManager部分: ユーザーが実装する必要があるインターフェースはApplicationBuilderであり、これは新しいエンジンコネクタインスタンスを起動するコマンドをカプセル化するために使用されます。

 //ユーザーが実装する必要があるメソッド: 新しいエンジン コネクタ インスタンスの起動コマンドをカプセル化するために使用されます defbuildApplication(protocol:Protocol):ApplicationRequest

（２）EngineConn部分：ユーザーはexecuteLineメソッドを実装するだけで、計算タスクを新しいエンジンに送信できます。

 //ユーザーが実装する必要があるメソッド: コンピューティング タスクを送信して実行するために基盤となるエンジンを呼び出すために使用されます defexecuteLine(context:EngineConnContext,code:String):ExecuteResponse

その他のエンジン関連の関数/メソッドにはデフォルトの実装があり、カスタマイズを必要とせずに直接再利用できます。

5. 接続性: Linkis がアプリケーション サイロを解消する方法

Linkis が提供するコンテキスト サービス、ストレージ、マテリアル ライブラリ サービスを通じて、複数の上位層アプリケーションは、環境変数、関数、プログラム パッケージ、データ ファイル、その他の関連情報やリソースを簡単に共有および再利用でき、アプリケーション サイロを打破できます。

コンテキストサービスの紹介

コンテキスト サービス (CS) は、さまざまな上位層アプリケーション システムとさまざまなコンピューティング タスクに対して統合されたコンテキスト管理サービスを提供して、コンテキストのカスタマイズと共有を可能にします。 Linkis では、CS が管理する必要があるコンテキスト コンテンツは、メタデータ コンテキスト、データ コンテキスト、リソース コンテキストの 3 つの部分に分けられます。

メタデータ コンテキストは、コンピューティング タスク内の基礎となるエンジン メタデータのアクセスおよび使用の仕様を定義します。主な機能は次のとおりです。

• すべてのユーザー メタデータ情報 (Hive テーブル メタデータ、オンライン ライブラリ テーブル メタデータ、HBase、Kafka などのその他の NOSQL メタデータを含む) の読み取りおよび書き込みインターフェイスを提供します。
• コンピューティング タスク内で必要なメタデータの登録、キャッシュ、および管理。
• データ コンテキストは、コンピューティング タスクにおけるデータ ファイルへのアクセスと使用の仕様を定義します。データ ファイルのメタデータを管理します。
• ランタイム コンテキストは、さまざまなユーザー定義の変数、関数、コード セグメント、パッケージなどを管理します。
• 同時に、Linkis は統合されたマテリアル管理およびストレージ サービスも提供し、必要に応じて上位アプリケーションを接続することで、スクリプト ファイル、プログラム パッケージ、データ ファイルなどのストレージ レイヤーの接続を実現します。

3. コンピューティングミドルウェアに基づくコンピューティングガバナンス Linkis - Insight

この章では、Linkis の詳細なコンピューティング ガバナンス機能の設計と実装について説明します。複雑な状況下でのコンピューティング タスクの正常な実行を保証するために、高同時実行性、高可用性、マルチテナント分離、リソース制御、コンピューティング タスク管理戦略に関して、詳細な検討と実装が数多く行われています。

1. コンピューティングタスクの高度な同時実行サポート

Linkis のジョブは、マルチレベルの非同期設計パターンに基づいています。サービスは、効率的な RPC およびメッセージ キュー モードを通じて迅速に通信できます。ジョブに作成者やユーザーなどのさまざまなタイプのラベルを付けてタスクを転送および分離することで、ジョブの同時実行能力を向上させることができます。 Linkis を利用すれば、1 つのエントリーサービス (Entrance) で 10,000 件を超えるオンライン求人依頼を同時に処理できます。

マルチレベル非同期の設計アーキテクチャ図は次のとおりです。

上図に示すように、ジョブは GateWay から Entrance に移動した後、生成から実行、情報のプッシュまで複数のスレッド プールを通過します。各リンクは非同期設計モードを採用しています。各スレッド プール内のスレッドは 1 回実行された後に終了されるため、スレッドのオーバーヘッドが削減されます。リクエストから実行、情報のプッシュまでのジョブ全体が非同期で完了するため、ジョブの同時実行能力が大幅に向上します。

ここでは、コンピューティング タスクの最も重要な部分であるジョブ スケジューリング レイヤーについて説明します。大量のユーザーからの何千もの同時タスクのプレッシャーは、ジョブ スケジューリング レイヤーにどのように実装されますか?

リクエスト受信層では、リクエスト受信キューは、フロントエンドユーザーによって送信された数千のコンピューティングタスクをキャッシュし、システム/ユーザーレベルごとに分割されたスケジューリンググループに従って、下流のジョブスケジューリングプール内のさまざまなスケジューリングキューに配布します。ジョブ スケジューリング レイヤーでは、複数のスケジューリング グループに対応するスケジューラが対応するスケジューリング キューを同時に消費し、ジョブを取得してジョブ実行プールに送信して実行します。このプロセスでは、マルチスレッド、マルチレベルの非同期スケジューリングおよび実行テクノロジが広範に活用されます。図は以下のとおりです。

2. その他の改良点

Linkis は、高可用性、マルチテナント分離、リソース制御、コンピューティング タスク管理戦略に関しても、多くの詳細な検討と実装を行っています。スペースが限られているため、ここでは各詳細機能の実装については詳しく説明しません。 Github の Linkis の Wiki を参照してください。 Linkis の計算ガバナンス - Insight の詳細な機能については、今後特別に紹介する予定です。