Yandexクラウドプラットフォーム。 コカイン

少し前に、Yandexの基本的なクラウドテクノロジーの1つであるEllipticsについて詳しく説明し始めました 。 今日は、「エルフ」が機能し、クラウドの夢を現実に少し近づける、他の何かについて話す番です。 コカインについてです。



Cocaine（設定可能な全能カスタムアプリケーション統合ネットワークエンジン）は、オープンソースPaaSシステム（Platform-as-a-Service）であり、本質的にアプリエンジンであり、Google AppEngine、OpenShift、 CloudFoundryまたはHeroku。







クラウドはすべてのインフラストラクチャの問題を解決し、コストを利益に変え、永遠の喜びと幸福であなたの人生を永遠に飽和させることができることを誰もが知っています。 これらの目標に対する唯一の障害は、実際には雲です。 IaaS 、 PaaS 、 SaaS ？ サービスとしては何ですか？ すべてが最終的に良くなるように、どのような種類の神秘的な文字を選択する必要がありますか？



私たちは、これらの問題の調査に多くの時間を費やし、私たちの意見、アイデア、概念を選択して、すぐにインストール、構成、正常に使用したいクラウドプラットフォームを構築しました。

物語

このテクノロジーの誕生の歴史は、Herokuと密接に関連しています。 昔々、クラウドテクノロジーはそれほど人気が​​なかったが、Herokuがすでにあったので、私たちのプロジェクトの創設者であるAndrei Sibiryovは彼女に興味を持ちました。







当時のHerokuは、Rubyだけがサポートするアプリエンジンでしたが、アイデア自体は革新的でした。 考えてみてください。独自の鉄道アプリケーションを作成してクラウドにアップロードし、インフラストラクチャの問題についてまったく考えないようにすることができます。 データベースが必要ですか？ 問題ありません-アドオンがあります！ ログを取得するには？ 再び問題ありません！ 負荷分散の問題も魔法のように解決されました。 サイトは若くて発展中ですか？ まあ、彼はリソースを持っています。 このサイトはすでに人気がありますか？ まあ、クラウドは彼が負荷の下で「膨張」し、生き残るのに役立ちます。 さらに、Gitに参加するように教えられた最も早い時期からgitを介して迅速に展開します。



かっこいいですね。 いずれにせよ、これがHerokuの位置付けです。 現実には、もちろん、すべてがより暗かったです。



彼らは素晴らしいアイデアを持っていて、実装はありましたが、実際にそれが一般的にどのように機能するかを説明していませんでした。 ご存知のように、未知の新しい何かを理解したい場合は、開発者の立場に身を置いてください。 あなたはパンや欠陥を見ながら書きますか？ そのため、クラウドアプリエンジンのオープンソースプロジェクトが開始されました。 将来的には、外国の開発者が同じロジックに導かれた可能性が高いと思います。これにより、OpenShiftとCloudFoundryのような類似の製品の開発が促進されました。 それらについては少し後で説明します。



コカインはもともと楽しいガレージプロジェクトでしたが、Yandexが内部用に「多分10、多分100,000 RPS」の負荷を処理できる膨張したアプリケーションプラットフォームを必要としたときに、すべてが変わりました。目標。 一方、J。Browserは同じニーズに近づいており、プロジェクトがガレージから抜け出す時であることが明らかになりました。



しばらくの間、話をさておき、乾燥した統計と議論の余地のない声明の世界に飛び込みましょう。

Yandexがコカインを使用する場所

Yandex.Browser-ブラウザのバックエンド全体がコカインを介して機能します。 たとえば、「Smart Line」、「Quick Links」、「Favorite Sites」。 Yandexの内部インフラストラクチャ。

サポートされているプラ​​ットフォーム

現在、コカインは次のLinuxディストリビューションのパッケージから展開できます。

• Ubuntu 12.04（Precise Pangolin）およびそれ以前
• RHEL 6および派生物。

残念ながら、Windowsのサポートはなく、計画もされていませんが、これは、たとえばC＃などのユーザーが他の場所でスピンしているクラウドサービスを使用できないことを意味するものではありません-適切なフレームワークを記述するだけです（これについては後述します） 。

ソースから、Cocaineは、boost 1.46+およびC ++ 11標準レベルGCC 4.4をサポートする （つまり、ほとんどなし）コンパイラーを備えたほぼすべての* nixシステムで構築できます。



おまけとして、コカインはMac OS Xのソースから正常にビルドされます。Dockerテクノロジーのサポート（後述）には、3.8年以上のLinuxカーネルが必要です。

なぜそんなにコカニーなのか？

コカインが主要な競合他社とどのように異なるかを詳しく見てみましょう。

Herokuから始めましょう。



Herokuは、主に独自の価格設定ポリシーを備えたオープンソーステクノロジーではありません。 しかし、明示的な収益化により、Herokuのサポートがさらに強化され、写真付きの優れた（現在の）ドキュメントがあります。 最初から最も便利なgitベースのアプリケーションデプロイメントシステムは、コードのクリーンアップを強制し、fakapの場合にロールバックを可能にします。

多数のアドオンにより、さまざまなデータベース、キャッシュ、キュー、同期、ロギングなどのアプリケーションのニーズに簡単に対応できます。



起動時のアプリケーション自体は、dynoと呼ばれるプロセスで互いに完全に分離されています。dynoは、複数のサーバーで構成される特別なdynoグリッドに分散されています。 Dynoは負荷に応じて必要に応じて起動し、存在しない場合は強制終了されます。したがって、Herokuでは、負荷分散とフォールトトレランスが保証されます。

Rubyのみの初期サポートにもかかわらず、Herokuは現在、Java、Closure、Node.js、Scala、Python、および（突然の）PHPなどの言語でアプリケーションを作成する機能を提供します。



CloudFoundryとOpenShiftの開発は、コカインとほぼ同時に始まりました。 どちらも大企業（それぞれVMwareとRedHat）から強力なサポートを受けているオープンソースプロジェクトです。 CloudFoundryは、現時点ですでに1つの再生を生き延びています。 ただし、言語サポートはJava、Scala、Groovy、Ruby、およびJavaScriptに限定されています。

OpenShiftはこれにより優れています。Python、Perlに加えてサポートされており、必要な言語を自分でサポートする機会があります。 残念ながら、アプリケーションはhttpを介してのみ相互に通信できるため、クラウドの範囲が多少制限されます。



コカインは同時にそれらと比較して有利です：

• さまざまな言語（フレームワーク）へのアダプターの存在。クラウドでの作業を大幅に簡素化します。
• httpだけでなく、アプリケーション間の相互通信機能。これにより、たとえば、独自のクラウドコンピューティングプラットフォームを構築できます。
• アプリケーション分離の強力なサポート-Dockerテクノロジーは、私たちを除き、OpenShiftのみを公式にサポートしています。

簡単な動作原理

次に、クラウドの実際の動作を見てみましょう。同時に、ソリューションの選択に影響を与えた理由を説明します。



クラウドはインフラストラクチャの問題を解決するように設計されています。



これらのタスクの1つは、フォールトトレランスを確保することです。 1台のマシンでのみ実行されるクラウドプラットフォームに誰もが感心することはまずありません。 この場合、クラウドはマシンとともに消滅します。 コカインのクラウドは、コカインランタイムサーバーがインストールされている1つ以上の独立したマシンで構成されています。 実際、プラットフォームの最小機能に必要なのはこれだけです。







CloudFoundryを経由せず、クラウドの論理部分ごとに個別のプログラムを開始することにしました。 したがって、たとえば、他のクラウドでHealthManagerと呼ばれるもの-実行中のアプリケーションの寿命を監視する-は、単一のエンティティに統合されています。 このようなソリューションは、一方ではノードの管理を簡素化し、障害ポイントの数を減らしますが、一方では、コカインランタイムが「落ちた」場合、ノード全体がしばらくリストから削除されます。 しかし、時間と負荷のテストにより、このようなソリューションの選択が成功したことが示されました。



コカインランタイムを実行するマシンが12台あるとします。 しかし、これらの車はお互いについて何も知りません。 クラウドトポロジ設計スキームを選択するためのオプションを検討する際、2つのオプションが考慮されました。 最初のケースでは、すべてのノードのIDが保証されます。ノードが死んだ場合、重要なものは何も変わりません。 しかし同時に、ロジックが混在しています。なぜなら、 基本的に2つのエンティティが関係します。1つ目はノードの集約とその管理です。 2番目はノードの管理です。 2番目の場合、ノードを集約するコカインランタイムロジックは他のノードから完全に分離されていますが、このノードは特別な方法で構成する必要があります。 最終的に、2番目のオプションが選択されました。



ユーザーは、アクセスするサービスまたはアプリケーションの場所については何も知りません-集約ノードのアドレスとアプリケーションの名前のみが知られています。 野田自身がリクエストに最適なマシンを選択し、リクエストを実行します。



クラウドアプリエンジンは、アプリケーションの実行方法がわからない場合、そのようには呼び出されません。 実際、コカインランタイムは何を実行するかを実際に気にしません。 唯一の要件は、ファイルが実行可能であることです。 もう1つは、このアプリケーションがほぼすぐに終了することです。 単純なハンドシェイクメッセージに返信することはできません。また、原則として、外部からアプリケーションを制御する一般的な手段はありません。 動作する場合、これは、たとえば、ハングしないという意味ではありません。 そして、ここでアプリケーション（またはワーカー）の寿命を制御するトピックに近づきます。



実行中のアプリケーションは何らかの方法で制御する必要があります。 実際、最小限の要件が必要です。アプリケーションは、ハートビートコマンドを使用してサーバーが生きていることをサーバーに通知し、終了コマンドを使用して美しく終了する必要がある場合があります。 アプリケーションの応答が長すぎない場合、アプリケーションは停止していると見なされ、SIGKILLが送信されて終了します。 つまり、ワーカーは特別なシンプルなプロトコルを実装する必要があります 。 アプリケーション開発の利便性のために、 フレームワークと呼ばれるさまざまな言語用のアダプターが作成されました。

5分間の履歴

フレームワークは、特定の言語がクラウドと通信するための最もネイティブな方法を実装する特別なAPIです。 たとえば、内部プロトコルの実装はフレームワークの下に隠されているため、クラウドサービスを呼び出して操作するのは非常に簡単です。 また、非同期呼び出しでの作業を簡素化するツールが実装されています。 現時点では、サポートはすでに実装されています。

• C ++
• Java
• Python
• ルビー
• Node.js
• 行く

コンソールインターフェースとWebの両方を介して、このすべてのクラウドを管理するツールがあります 。 それらの実装は、多くの点で類似のHerokuまたはCloudFoundryツールと非常によく似ています。アプリケーションのデプロイ、起動、停止、管理、構成、および統計の収集とログの表示が可能です。 ここで何か新しいものを思い付くのは本当に難しいですが、Amazon EC2ツールはシンプルさと便利さの点で私たちの例ですが、私たちはそれを目指して努力しています。

建築

一歩下がって、クラウドインフラストラクチャを見てみましょう。 クラウドとは何ですか？ 通常、リソースを提供するマシンがいくつかあります。 これらのマシンは、何らかの制御要素によって何らかの形で単一のエンティティに接続されています。 提供される共有リソースは、さまざまなサービスとユーザーアプリケーションを整理するために使用されます。 何にも似ていませんか？

1つの（通常）コンピューターのインフラストラクチャを管理し、そのリソースをユーザーに提供するプログラムを含むソフトウェアのカテゴリがあります。 モジュールには明確な区分があり、コントロールエンティティがあり、ユーザースペースがあります。 もちろん、 オペレーティングシステムに関するものです 。 クラウドインフラストラクチャの場合、同様のことをしてみませんか？



それがコカインの作り方です。



すべての中心にあるのは、 サービス 、 ドライバー、およびAPIの基本階層を含むコアです。 このサービスは、本質的にC ++で記述されたライブラリであり、カーネルに接続され、クラウドに特定のサービスを提供します。 サービスはコカインランタイムと同時に起動され、動作中は常に単一のコピー内の別のスレッドで実行されます。







メインサービスはNodeサービスで、 アプリケーションの開始、停止、および操作を制御できます。 最初に起動されたアプリケーションにはワーカーがありません-このアプリケーションのインスタンス-は、アプリケーションの時点で生成を開始し、アプリケーションの負荷を増やします。



各アプリケーションには、ワーカーとクライアント間でメッセージキューをディスパッチするエンジンがあり、これらのワーカーの数を管理および分散します。



Locatorサービスを使用すると、独立したノードを単一のクラスターに接続し、クラウド内のクライアントから要求されたアプリケーションまたはサービスを検索できます。 たとえば、一部のアプリケーションがロガーサービスを要求する場合、ロケーターはどのエンドポイントに提供するかを決定します。 エンドポイントとともに、サービスメソッドディスパッチテーブルも提供されます。 それについて言えば、 CORBAやThriftの RPCメカニズムとは異なり、サービス（およびアプリケーション） のインターフェイス （IDL）の必須の記述を取り除くことにしました。 代わりに、各解像度でメソッドのテーブルをロードすると、フレームワークは各言語をネイティブに操作する方法を実装します。 これに必要なのは、要求されたサービスの名前と、場合によってはバージョンだけです。



これの恩恵を受けましたか？ 間違いなくはい！ 各アプリケーションのIDLを定義する必要性を排除することにより、RubyやPythonなどの動的言語の開発を大幅に促進しました。 アプリケーションのAPIが変更された場合、すべてのフレームワークのスタブを書き換える必要はありません。動的に型付けされた言語の場合、メソッドは通常動的に作成されます。

サービスについて続けます

ログを記録する手段のないクラウドが少なくとも1つあることはほとんどありません。ノード全体からのログ転送の単一ポイントであるLoggerサービスとして実装しています。



最後に、 ストレージサービスは、アプリケーション自体、マニフェスト、プロファイル、およびアプリケーション自体を含む必要なその他の情報など、何でも保存するための抽象的なインターフェースです。



サービスアーキテクチャは拡張が可能であり、Linuxカーネルモジュールに似ています。 独自のサービスを記述したり、既存の階層を展開したりできます。







ドライバーはスタンドアロンであり、その目的はクラウドによって処理されるイベントを生成することです。 たとえば、このようなイベントは、ファイルまたはディレクトリの変更、タイムアウト、またはその他のイベントです。 （オプションとして）ADC用のドライバーを作成できます。これにより、信号が到着すると処理のためにリセットされます。



アプリケーションとサービスがHTTPを介してのみ互いに​​通信できる多くの同様のPaaSとは異なり、コカインはRPCメカニズムを介してバイナリHTTP / 2.0のようなプロトコルを介して通信します。 これにより、たとえば、フレームワークが提供するツールを使用して、異なるアプリケーション間で直接対話する機会が得られます。 詳細については、 こちらをご覧ください 。 もちろん、HTTPインターフェース自体はまだここにあります。 各フレームワークには、HTTPアプリケーションの開発を簡素化するネイティブツールが用意されています。 たとえば、Pythonの場合、フラスコのようなデコレーターがあります。



外部では、HTTPインターフェイス（このオプションが提供されますが）だけでなく、たとえばZeroMQまたは独自の拡張機能を介してアプリケーションにアクセスすることもできます。

スケーリングと分離

Cloudディストリビューションが実際にどのように実装され、負荷の下でどのように生きようとしているのかを詳しく見てみましょう。



クラスターが開始されると、個々のノード（コカインランタイムを実行しているマシン）は、各マシンをマルチキャストグループに登録する内部Locatorサービスを使用して相互に学習し、それにより、すべてのノードとMetalocatorの入力ポイントである別のノード間の通信を整理しますクラウドと基本的な負荷分散の実行。 別のマシンで新しいアプリケーションが表示されたり、既存のアプリケーションが増えたりすると、金属スキャナーはすぐにそのことを認識し、負荷をそれに向けます。



また、クラウドは前述のエンジンを使用して、メッセージキューと負荷制御を監視します。 アプリケーションの負荷が増加すると、プラットフォームは、ノードの負荷とさまざまなマシンのスロットの可用性に関する内部的なアイデアに基づいて、このアプリケーションの必要な数のインスタンスを自動的に起動します。 この状況のスロットは、マシンの何らかの統合リソースとして理解されます。



アプリケーションを生成および分離するためのシステムは、 Isolateと呼ばれる別のエンティティになります。 標準構成では、クラウドは通常のプロセスを使用して新しいアプリケーションインスタンスを起動します。 Dockerサポートがプラグインとしてインストールされている場合、クラウドは新しいアプリケーションを個別の隔離されたコンテナーで起動します。

分離？ 簡単！

Dockerは、任意のアプリケーションから軽量でポータブルで自己完結型のコンテナーを作成するためのシンプルで効率的な方法を提供するオープンソーステクノロジーです。 作成されたコンテナは、開発者やテスターのラップトップから数千台のサーバーのクラスターまで、ほぼすべての環境で同様に機能します。 これにより、たとえば、アプリケーションをバイナリの依存関係とともに分離し、ライブラリの他のバージョンが原因でクラウド内でアプリケーションが異なる動作をしたり、まったく起動しないと思うことを防ぐことができます。



Dockerテクノロジーは、通常のLinuxコンテナ（LXC）に基づいており、ネームスペースとcgroupを使用して、隔離された環境でアプリケーションを実行する機能を提供します。 XenやKVMなどの完全仮想化環境とは異なり、コンテナは共通のコアを使用し、デバイスをエミュレートする機能を提供しませんが、同時にそれらを使用すると追加のオーバーヘッドが発生せず、ほぼ瞬時に起動します。 コンテナ化自体に加えて、Dockerは、アプリケーションイメージのネットワーク構成、配布、および展開を簡素化するツールを提供します。 そのようなツールの1つは、複数の独立したレイヤーからアプリケーションイメージを作成することです。

Cocaine'a用のアプリケーションを開発し、バイナリ依存関係（たとえば、C ++またはPythonのアプリケーション）を引き出す場合、Dockerテクノロジーはこれらのバイナリ依存関係を分離するのに非常に役立ちます。

耐侵食性

アプリケーションを作成し、サーバーにアップロードし、構成し、運命に任せたとします。 1週間後、それがどのように機能するかを確認し、悲しいことに、まったく異なる理由でアプリケーションがかなり前にクラッシュしたことを発見します。

• オペレーティングシステムまたは依存ライブラリの自発的な更新。
• ディスクフルログ;
• アプリケーションがフリーズまたはクラッシュする。
• サーバーハードウェア自体の問題。

これらの効果は「 ソフトウェア侵食 」として知られています。



コカインは侵食に強い技術です。 分離システムは、自発的なライブラリおよびOSの更新からアプリケーションを保存します。 アプリケーションがクラッシュまたはフリーズした場合、クラウド自体によって、または他のクラウドプラットフォームでヘルスマネージャーと呼ばれるシステムによって自動的に再起動されます。 鉄自体の問題は、雲自体によって平準化されます。

プラグインとサービス

プラグインとサービスは、プラットフォームコアのコンテキストで既に簡単に説明されています。 プラグインは、アーキテクチャの拡張モジュールです。 たとえば、Dockerのサポートはプラグインを使用して実装されました。 彼らはに分かれています：

• 分離 -アプリケーション分離システム
• ドライバー -アプリケーションの外部イベントを生成するシステム
• ストレージ -ストレージシステム。
• ロギング -ロギングシステム。
• ゲートウェイ -バランスシステム
• サービス -その他のユーザーサービス

プラグインを使用して、システムの上記の部分の実装を変更し、構成ファイルのみを変更できます。 ロギングシステムをSyslogからLogstashに置き換えたいですか？ 構成内の3行を変更しても、コードは同じままです。 たぶんデフォルトのバランスシステムはあなたに合わず、あなたはIPVSが欲しいですか？ 簡単！ さて、プリインストールされたプラグインが十分になく、何か新しいものを実装したい場合はどうでしょうか？ まあ、それらを書くことは完全に簡単であり、リクエストのプールに非常に満足しています。



プラグインの最後の項目はサービスです。 厳密に言えば、サービスはインフラストラクチャのさまざまな部分の抽象的なフロントエンドです。



たとえば、一般的な場合、セキュリティ上の理由からアプリケーションがコンテナの外に出ることは許可されていないため、 UrlFetchサービスを使用すると、アプリケーションでhttpリクエストを作成し、これらのリクエストを制御できます。



Logstashプラグインを使用して、クラスター全体からのログの集約、同じElasticsearchでの統合処理、インデックス作成、ストレージを構成し、 Kibana （Yandexで行います）での便利な表示を設定できます。



Ellipticsプラグインを使用すると、同じ名前のシステムにすべての情報を保存できます。 別の方法として、MongoDBプラグインとElasticsearchサービスが実装されており、これらのテクノロジーをストレージシステムとして使用できます。

おわりに

この紹介記事では、コカインクラウドプラットフォームに関する一連の記事を開始します。 将来的には、プラットフォームのアーキテクチャ、その長所と短所（すでにそれらが存在しない場合）は、さらに詳細に検討されます。



ソースまたはパッケージから独自のクラウドを展開する方法と、それを構成する方法を示します。 これに続いて、実際のアプリケーションの例を使用して記述されたフレームワークの説明が続きます。 これに続いて、すでに記述されたプラグインとサービスの説明が続き、独自のプラグインまたはサービス（あるいはその両方）を記述する例が考慮されます。 結論として、Cocaine'ovyプロトコルの詳細と、別の言語のサポートを追加する方法、つまり独自のフレームワークを作成する方法を検討します。



githubで開発しています。 最も関連性の高い情報はすべてここから入手できます 。 Wikiセクションには、ソースからコカインを迅速にアセンブルする方法に関するドキュメントがあり、内部の詳細の説明があります。 このプラットフォームに興味がある場合は、既製の浮浪者の画像を使って実際に試してみてください。 ご質問がある場合は、お問い合わせください。