MESOSテクノロジーに基づく分散クラスターインフラストラクチャでのアプリケーション管理システムの構築

今日では、「ビッグデータ」という用語が広く耳にされています。 ネットワークおよび「ビッグデータ」の処理に関連する多数の出版物に登場した後、このトピックへの関心は常に高まっています。 データベース管理システム

テクノロジーNoSQLを使用。 「BIG DATA」システムを構築するには、印象的なハードウェアリソースが必要であると誰もが理解しています。 さらに重要なことは、システムのコンピューティングリソースを最適に使用し、それらを効果的にスケーリングできることです。 これにより、データ処理システムを構築するアプローチが必然的に変わります。 強力なコンピューティングサーバーのセットが動作するデータウェアハウスを集中化するという原則に基づいて以前のシステムが構築されていた場合、このアプローチは徐々にバックグラウンドに移行しています。 中電力の多数の標準サーバーのクラスターに基づいて構築されたシステムが増えています。 このようなシステムには集中ストレージはありません。 クラスター内のデータを処理するために、各サーバーのローカルディスクリソースを使用するモジュラー分散ストレージシステムが使用されます。 集中型ストレージシステムにディスクを追加し、コンピューティングサーバーをアップグレードして以前のスケーリングを実行した場合、これらの同じ問題は、標準ノードをクラスターに追加するだけで解決されます。 このアプローチは着実に進んでいます。



このようなシステムを運用するプロセスでは、一部のノードでコンピューティングリソースが不足するという問題に対処する必要があります。 クラスターのノードの負荷が不均等に分散している場合があります。ノードの一部がアイドル状態で、他の部分がさまざまなタスクで過負荷になっています。 これらの問題は、より多くのノードをクラスターに追加することで「広範囲に」解決できます。 ただし、異なるタスクと異なるクラスターノード間のリソースの分散を最適化する「集中的な」アプローチを適用することは可能です。



いずれにせよ、最近、負荷条件の変化に応じて利用可能なリソースを迅速かつ柔軟に再配分できるシステムが急務となっています。 実際には、上記の機能を実装するために、システムは3つの主要な条件を確実に満たす必要があります。

1. 個々のサーバーのコンピューティングリソースを共通のセットに結合する機能を提供します。
2. 任意のクラスターノードで任意のアプリケーションを実行する機能を提供します。
3. 共通のセットから特定の量の各タスクに個別にコンピューティングリソースを割り当てる機能を提供します。

しばらく前に一般化されたコンピューティングリソースでクラスター管理システムを作成するというアイデアは、MESOSと呼ばれる製品でApache Foundationによって実装されました。 この製品を使用すると、最初の条件を確実に満たすことができます。複数のハードウェアサーバーのコンピューティングリソースを1つの分散リソースセットに結合し、クラスターコンピューティングシステムを編成します。







簡単に言えば、その仕組み：クラスターの各ノードでMESOSサービスが起動し、mesos-masterとmesos-slaveの2つのモードで動作します。 したがって、各クラスターノードは、mesos-slaveロール、mesos-masterロール、または両方のロールを適切に受け取りますが、これも可能です。 Mesos-slaveノードは、mesos-masterノードから受信したコマンドでアプリケーションを実行するように設計されています。 mesos-masterノードは、クラスターノードでアプリケーションを起動するプロセスを制御するため、2番目の条件が満たされます-任意のクラスターノードで任意のアプリケーションを実行できます。 Mesos-masterノードは通常、フォールトトレランスを提供するために2または3です。 デフォルトでは両方のロールがノードで同時に起動されるため、ほとんどのノードでmesos-masterロールを無効にすることをお勧めします。 mesos-slaveノードとmesos-masterノードの相互作用は、Apache Zookeeperを使用して実行されます。 Apache MESOSシステムの機能は、サードパーティのアプリケーションをフレームワークとしてMESOSに統合することにより、柔軟に拡張できます。



Apache MESOSの主要なアプローチは、mesos-slaveノードが使用可能な空きハードウェアリソース（CPUおよびRAM）を考慮に入れて、mesos-masterノードにその数を伝えることです。 その結果、mesos-masterには、mesos-slaveノードで利用可能なコンピューティングリソースに関する完全な情報があります。 同時に、彼はノードにスレーブコマンドを発行してアプリケーションを起動するだけでなく、このアプリケーションが持つことができるコンピューティングリソースの量を強制することもできます。 この問題は、アプリケーションのコンテナ化メカニズムを使用して解決されます。 プロセスはいわゆるで始まります。 コンテナ-閉じられた動作環境。 コンテナの基盤は、OSカーネルがインストールされているイメージファイル、ルートFS、必要なすべてのシステムライブラリが展開されているなどです。 コンテナが起動すると、システムのカーネルがイメージから起動されます。 その後、アプリケーション自体は、専用の事前に準備されたオペレーティング環境で起動されます。 1つのプロセスに対して一種の仮想マシンになります。 コンテナ化を使用すると、各コンテナに一定量のRAMと一定数のCPUコア（たとえば、1〜0.5未満のコアを含む）を割り当てることができることが重要です。







したがって、3番目の条件も確実に満たすことができます。共通のセットから特定の量のコンピューティングリソースを各タスクに割り当てることができます。 最初、Apache MESOSは独自のアプリケーションコンテナ化アルゴリズムを使用して上記の問題を解決しましたが、ドッカー製品が市場に登場した後、後者は組み込みのApache MESOSコンテナ化ツールを完全に置き換えました。 いずれにせよ、現時点では、Apache MESOSとのdocker統合は広く普及しており、事実上の標準です。 この分野におけるDockerの地位は、よく知られているgit-hubサービスとイデオロギー的に類似したコンテナー化アプリケーションの無料配布システムであるdocker hubサービスのおかげでさらに強化されました。 このサービスを使用すると、開発者は、多くの人が最近積極的に使用している既製のドッカーコンテナの形式でアプリケーションを公開できます。



現在、mesos-slaveノードでリソースが使い果たされると、mesos-masterノードはすぐに「認識」し、そのようなスレーブノードでアプリケーションを実行できません。 この場合、mesos-masterは、負荷の少ない別のmesos-slaveを探すことを強制されます。 これにより、コンピューティングリソースの可用性をより厳しく要求するタスクは、負荷の少ないクラスターノードに「ポスト」されます。 したがって、一般化されたリソースを備えた本格的なクラスターを取得します。これにより、作業用にアプリケーションに割り当てられた一定量のリソースを設定できます。



残念ながら、Apache MESOSベースのソリューションの明らかな欠点は、アプリケーションの状態を監視せず、長期的にパフォーマンスを維持せずに、アプリケーションの1つのコピーを別のクラスターノードで同時に起動することに焦点を当てていることです。 ただし、この問題は最近MESOSPHEREによって解決されました。 マラソンとクロノスの製品が市場に導入されました。 これらの製品を使用すると、Apache MESOS環境でのアプリケーションの起動を制御できます。 Apache zookeeperを介してmesos-masterと対話し、フレームワークとしてその構造に組み込まれ、システムに新しい機能を提供します。 MARATHONは、長時間連続して実行する必要があるアプリケーションを実行するように設計されています。 それは、その助けを借りて起動されたアプリケーションの操作性のスケールアップと監視の機能を実装します。 標準の一連のMARATHON機能には、すべてのクラスターノードでアプリケーションインスタンスを同時に起動する機能、クラスターノードの特定の部分でアプリケーションを起動する機能、1つのクラスターノードで実行されるアプリケーションのコピー数を制御する機能などが含まれます。 同様に、同様の機能を備えたCHRONOSは、スケジュールに基づいて1回限りのタスクを起動することに重点を置いています。







これらのアプリケーションは両方とも、HTTPプロトコルとREST APIテクノロジーを使用して実装される独自の管理インターフェースを備えています。 実際、MARATHONはユーザーとmesos-masterの間に位置し、JSON形式のREST APIを使用してアプリケーションを実行する要求を受け入れます。 リクエストでは、特に、ユーザーはクラスター規模で起動されたアプリケーションのインスタンスの総数、ノードごとのアプリケーションインスタンスの数、各アプリケーションインスタンスに発行されるシステムリソースの数などを構成できます。



前述のように、多くの開発者がアプリケーションをdockerコンテナとして配布し始めています。 特に、MESOSPHEREはこのアプローチの使用に成功しており、その結果、この記事で説明するMARATHONおよびCHRONOSアプリケーションは、既製のコンテナとして現在利用可能です。 これらを使用すると、これらのサブシステムの処理プロセスが簡素化され、クラスターノード間で簡単に移動したり、バージョンの更新プロセスを大幅に高速化したりすることができます。 自社開発の経験とサードパーティ企業の経験により、このアプローチをこの業界で最も可能性の高い技術開発トレンドと見なすことができます。



要約すると、記事の冒頭で定式化されたタスクを解決し、3つの主な要件を満たすことができるテクノロジーを自由に使用できると言えます：ITシステムの一般化されたコンピューティングリソースを透過的に使用する能力を提供し、システムの任意のノードで任意のタスクを実行する能力を提供し、共通のクラスターセットから特定の量のコンピューティングリソースを各タスクに個別に割り当てるメカニズムを確立します。



結論として、この記事で説明されているアプローチの有効性は、サンクトペテルブルクの複数のIT企業が上記の技術を使用して開発したソリューションの実装および運用の成功により確認されていることに注意してください。



より詳細には、この記事で説明した技術が記載されているここに 。