技術

CloudI：Erlangのフォールトトレランスを多言語開発にもたらす

クラウドは、有用なフォールトトレランスとスケーラビリティを提供するために効率的である必要がありますが、使いやすいものでなければなりません。

awsアソシエイトソリューションアーキテクト認定

CloudI （「cloud-e」/klaʊdi/と発音）は、Erlangに組み込まれているオープンソースのクラウドコンピューティングプラットフォームです。密接に関連しているにサービスとしてのプラットフォーム（PaaS）クラウド。 CloudIは、いくつかの重要な点で異なります。最も重要なのは、ソフトウェア開発者が特定のフレームワークを使用することを強制されない、遅いことです。ハードウェア仮想化、または特定のオペレーティングシステム。 CloudIは、仮想化なしでクラウドデプロイメントを実行できるようにすることで、開発プロセスとランタイムパフォーマンスを妨げずに、サービス品質を明確な説明責任で制御できます。

何が雲を雲にするのですか？

「クラウド」という言葉はユビキタス過去数年にわたり。そして、その真の意味はやや失われました。最も基本的な技術的意味では、これらはクラウドコンピューティングプラットフォームが持つ必要のある特性です。

そして、これらは私たちがしたいプロパティです お気に入り 持つべき雲：

簡単な統合
簡単な導入

CloudIの構築における私の目標これらの4つの属性をまとめることでした。

スケーラビリティを備えた実際のフォールトトレランスを提供できるプログラミング言語はほとんどないことを理解することが重要です。実際、この点でアーランはおおよそ一人だと思います。

私は最初に Erlangプログラミング言語（その上にCloudIが構築されています）。 Erlang仮想マシンは フォールトトレランス機能 と 高度にスケーラブルなアーキテクチャ 一方、Erlangプログラミング言語は、必要なソースコードを小さく、簡単に理解できるようにします。

スケーラビリティを備えた実際のフォールトトレランスを提供できるプログラミング言語はほとんどないことを理解することが重要です。実際、この点でアーランはおおよそ一人だと思います。回り道をして、その理由と方法を説明しましょう。

フォールトトレランスは、クラウドコンピューティングにおける重要な考慮事項です。

クラウドコンピューティングのフォールトトレランスとは何ですか？

フォールトトレランスは、エラーに対する堅牢性です。つまり、フォールトトレラントシステムは、（できれば分離された）エラーが発生した場合でも、比較的正常に動作し続けることができます。

ここでは、サービスCがサービスAとBにリクエストを送信しているのがわかります。サービスBは一時的にクラッシュしますが、システムの残りの部分は比較的妨げられずに続行します。

初心者向けのErlangチュートリアル

アーランは達成することで知られています 9x9の信頼性（99.9999999％の稼働時間、つまり年間31.536ミリ秒未満のダウンタイム）実際の本番システム（電気通信業界内）で。通常のウェブ開発技術は達成するだけです 5x9sの信頼性（99.999％の稼働時間、つまり年間約5.256分のダウンタイム）、運が良ければ、更新手順が遅く、システム障害が完全に発生するため。 Erlangはどのようにこの利点を提供しますか？

Erlang仮想マシンいわゆる「アクターモデル」、並行計算の数学モデル。アクターモデル内では、Erlangの軽量プロセスは言語自体の並行性プリミティブです。つまり、Erlang内では、 すべてが俳優です 。定義上、アクターはアクションを同時に実行します。したがって、すべてがアクターである場合、固有の並行性が得られます。（Erlangのアクターモデルの詳細については、より長い議論がありますここに。）

その結果、Erlangソフトウェアは多くのもので構築されています軽量プロセス極端なスケーラビリティを提供しながら、プロセス状態を分離します。 Erlangプロセスが外部状態を必要とする場合、メッセージは通常別のプロセスに送信されるため、メッセージキューイングはErlangプロセスに効率的なスケジューリングを提供できます。 Erlangプロセスの状態を分離しておくために、Erlang仮想マシンはプロセスごとに個別にガベージコレクションを実行し、他のErlangプロセスが中断されることなく同時に実行を継続できるようにします。

次のデータ視覚化ツールのどれが定量的データを整理するために使用されますか？

ザ・ Erlang仮想マシンのガベージコレクション Java仮想マシンのガベージコレクションと比較した場合の重要な違いは Javaは単一のヒープに依存しています、Erlangによって提供される分離状態を欠いています。 ErlangガベージコレクションとJavaガベージコレクションの違いは、Java仮想マシン上にライブラリまたは言語サポートが開発されたとしても、Javaは、仮想マシンのガベージコレクションのために基本的なフォールトトレランス保証を提供できないことを意味します。があった Javaでフォールトトレランス機能を開発しようとしていますおよびその他のJava仮想マシンベースの言語ですが、Java仮想マシンのガベージコレクションが原因で引き続き障害が発生します。

ErlangとJVMのガベージコレクション方法を比較すると、フォールトトレランスへの影響がわかります。

基本的に、JVM自体はフォールトトレラントではないため、JVM上にリアルタイムのフォールトトレランスサポートを構築することは定義上不可能です。

Erlangプロセス

低レベルでは、Erlangプロセスでエラーが発生するとどうなりますか？言語自体が使用するメッセージパッシングプロセス間で、エラーの範囲が並行プロセスによって制限されるようにします。これは、データ型を不変オブジェクトとして格納することで機能します。これらのオブジェクトは、プロセス状態の範囲を制限するためにコピーされます（大きなバイナリは、メモリを節約するために参照カウントされるため、特別な例外です）。

つまり、変数Xを別のプロセスPに送信する場合は、Xを独自の不変変数X ’としてコピーする必要があります。現在のプロセスからXを変更することはできないため、エラーが発生した場合でも、2番目のプロセスPはその影響から分離されます。最終的には、Erlangプロセス内の状態の分離に起因するエラーの範囲を低レベルで制御できます。さらに技術的になりたい場合は、Erlangの可変性の欠如がそれをもたらすと言います参照透過性たとえば、Javaとは異なります。

このタイプのフォールトトレランスは、try-catchステートメントと例外を追加するだけではありません。ここで、フォールトトレランスとは予期しないエラーの処理に関するものであり、例外が予想されます。ここでは、変数の1つが予期せず爆発した場合でも、コードを実行し続けようとしています。

初心者のためのAngular5チュートリアル

Erlangのプロセススケジューリングは、最小限のソースコードに対して非常に高いスケーラビリティを提供し、システムをよりシンプルで保守しやすくします。他のプログラミング言語が模倣することができたのは事実ですが スケーラビリティ 並行計算用の独自のアクターモデルを実装するためのユーザーレベルのスレッド化（カーネルレベルのスレッド化と組み合わせられる可能性があります）とデータ交換（メッセージパッシングと同様）をライブラリに提供することでErlang内でネイティブに検出されたため、フォールトを再現できませんでした- Erlang仮想マシン内で提供される許容値。

これにより、プログラミング言語の中でErlangは両方であるとして単独になります スケーラブル そして 耐障害性 、クラウドの理想的な開発プラットフォームになります。

Erlangを利用する

とはいえ、CloudIはErlangのフォールトトレランスとスケーラビリティを他のさまざまなプログラミング言語（現在はC ++ / C、Erlang（もちろん）、Java、Python、Ruby）にもたらし、サービスを実装していると主張できます。サービス指向アーキテクチャー（SOA）。

このシンプルさにより、CloudIはポリグロットソフトウェア開発のための柔軟なフレームワークになり、プログラマーがErlangコードの行を記述したり理解したりすることなく、Erlangの長所を提供します。

CloudI内で実行されるすべてのサービスは、 CloudI API 。 Erlang以外のプログラミング言語サービスはすべて、同じ内部CloudIErlangソースコードを使用して処理されます。同じ最小限のErlangソースコードがすべての非Erlangプログラミング言語に使用されるため、CloudI APIの外部プログラミング言語実装を使用して、他のプログラミング言語サポートを簡単に追加できます。内部的には、CloudIAPIはリクエストとレスポンスの基本的なシリアル化のみを行っています。このシンプルさにより、CloudIはポリグロットソフトウェア開発のための柔軟なフレームワークになり、プログラマーがErlangコードの行を記述したり理解したりすることなく、Erlangの長所を提供します。

サービス構成では、スタートアップパラメータとフォールトトレランスの制約を指定して、サービス障害が制御された分離された方法で発生するようにします。起動パラメータは、実行可能ファイルと必要な引数を明確に定義し、サービスリクエストに使用されるデフォルトのタイムアウト、サービスを検索するメソッド（「宛先更新メソッド」と呼ばれる）、単純な許可と拒否の両方を定義します。アクセス制御リスト（ACL）発信サービス要求とオプションのパラメーターをブロックして、サービス要求の処理方法に影響を与えます。フォールトトレランス制約は、Erlangスーパーバイザーの動作（Erlangデザインパターン）がErlangプロセスを制御するのと同じ方法でサービスを制御する2つの整数（MaxR：最大再起動とMaxT：秒単位の最大期間）です。サービス構成は、サービスの存続期間に明示的な制約を提供し、エラーが発生した場合でもサービスの実行を理解しやすくします。

実行時にサービスメモリを分離しておくために、Erlang以外のサービス（「外部」サービスと呼ばれる）ごとに個別のオペレーティングシステムプロセスが使用され、Erlang以外のプロセスごとに（実行のErlang以外のスレッドごとに）スケジュールされます。 ErlangVM。 Erlang CloudI APIは、Erlangプロセスにも関連付けられている「内部」サービスを作成するため、「外部」サービスと「内部」サービスの両方がErlangVM内で同じ方法で処理されます。

クラウドコンピューティングインスタンスおよびErlangVMと相互作用するCloudIAPIを示す画像。

クラウドコンピューティングでは、フォールトトレランスが単一のコンピューターを超えて拡張されることも重要です（つまり、分散システムのフォールトトレランス）。 CloudIは分散Erlang通信を使用してサービス登録情報を交換するため、CloudI APIで行われたリクエストに単一のサービス名を指定することで、CloudIの任意のインスタンスでサービスを透過的に利用できます。すべてのサービスリクエストは送信サービスによって負荷分散され、各サービスリクエストは分散トランザクションであるため、別々のコンピューターに別々のインスタンスを持つ同じサービスは、CloudI内でシステムのフォールトトレランスを提供できます。必要に応じて、CloudIを仮想化オペレーティングシステム内に展開して、安定した開発フレームワークを促進しながら、同じシステムのフォールトトレランスを提供できます。

たとえば、HTTPリクエストがデータベースにアカウントデータを保存する必要がある場合、設定されたHTTPサービス（CloudIによって提供される）に対して行われ、処理のためにアカウントデータサービスにリクエストが送信されます（HTTP URLに基づいて）サービス名として使用されます）、アカウントデータはデータベースに保存されます。すべてのサービスリクエストは、ユニバーサル一意識別子（UUID）作成時に、サービスリクエストの完了を追跡するために使用でき、CloudI内の各サービスリクエストを分散トランザクションにします。したがって、アカウントデータサービスの例では、他のサービスリクエストを同期的または非同期的に作成し、データベースを利用する前にサービスリクエストUUIDを使用して応答データを処理することができます。個々のサービスリクエストを明示的に追跡することで、サービスリクエストがリクエストのタイムアウト期間内に配信されるようにし、応答データを一意に識別する方法も提供します（サービスリクエストのUUIDは、接続されているすべてのCloudIノード間で一意です）。

C ++を難しい方法で学ぶ

通常の展開では、各CloudIノードにアカウントデータサービスの構成済みインスタンス（それぞれがCloudI APIオブジェクトを持つ複数のスレッドを持つ複数のオペレーティングシステムプロセスを利用する場合があります）とHTTPサービスのインスタンスを含めることができます。外部ロードバランサーはHTTPリクエストをCloudIノード間で簡単に分割し、HTTPサービスは各リクエストをCloudI内のサービスリクエストとしてルーティングするため、アカウントデータサービスはCloudI内で簡単に拡張できます。

CloudIの動作

CloudIを使用すると、スケーラブルでないレガシーソースコードを取得し、それをシンCloudIサービスでラップしてから、明示的なフォールトトレランス制約を使用してレガシーソースコードを実行できます。この特定の開発ワークフローは、マルチコアマシンを完全に活用すると同時に、リアルタイム要求の処理中にフォールトトレラントな分散システムを提供するために重要です。 CloudIで「外部」サービスを作成することは、サービス構成内で構成されたすべてのスレッドでCloudI APIオブジェクトをインスタンス化するだけなので、各スレッドはCloudI要求を同時に処理できます。簡単なサービスの例では、次のPythonソースコードのように、単一のメインスレッドを利用して単一のCloudIAPIオブジェクトを作成できます。

import sys sys.path.append('/usr/local/lib/cloudi-1.2.3/api/python/') from cloudi_c import API class Task(object): def __init__(self): self.__api = API(0) # first/only thread == 0 def run(self): self.__api.subscribe('hello_world_python/get', self.__hello_world) self.__api.poll() def __hello_world(self, command, name, pattern, request_info, request, timeout, priority, trans_id, pid): return 'Hello World!' if __name__ == '__main__': assert API.thread_count() == 1 # simple example, without threads task = Task() task.run()

サンプルサービスは単に「HelloWorld！」を返します。最初にサービス名とコールバック関数でサブスクライブすることにより、HTTPGETリクエストに追加します。サービスがCloudIAPIポーリング関数内で着信CloudIサービスバスリクエストの処理を開始すると、サブスクリプションのため、HTTPサーバーを提供する「内部」サービスからの着信リクエストはサービス名に基づいてサンプルサービスにルーティングされます。リクエストがパブリッシュ/サブスクライブ機能を提供する一般的な分散メッセージングAPIのパブリッシュメッセージに類似している必要がある場合、サービスは応答としてデータを返さなかった可能性もあります。サンプルサービスは、HTTPサーバーがHTTPクライアントに応答を提供できるように応答を提供する必要があるため、要求は一般的な要求/応答トランザクションです。データまたはデータなしのいずれかのサービスからの可能な応答の両方で、サービスコールバック関数は、呼び出しサービスの代わりに使用されるメッセージングパラダイムを制御するため、要求は必要な数のサービスをルーティングして、必要なときに応答を提供できます。リクエストが発生するように指定されたタイムアウト内。タイムアウトはリアルタイムのイベント処理にとって非常に重要であるため、各リクエストは、任意の数のサービスをルーティングするときにリクエストに続く整数のタイムアウトを指定します。その結果、フォールトトレランス制約とともにリアルタイムの制約が適用され、ソフトウェアエラーがいくつあっても信頼できるサービスが提供されます。

ソフトウェアにソースコードのバグが存在することは、フォールトトレランスの制約によってのみ軽減される明確な事実として理解する必要があります。ソフトウェア開発は、ソフトウェアが維持されるときにバグの存在を減らすことができますが、ソフトウェア機能が追加されるときにバグを追加することもできます。 CloudIは、リアルタイムの分散システムソフトウェア開発におけるこれらの重要なフォールトトレランスの懸念に対処できるクラウドコンピューティングを提供します。このCloudIとErlangのチュートリアルで示したように、CloudIが提供するクラウドコンピューティングは最小限であるため、クラウドコンピューティングのメリットのために効率が犠牲になることはありません。