このようなアーキテクチャの欠点は何ですか？ このようなアーキテクチャのフレームワーク内の問題を解決するために、多くの質問に直面しています：どの言語（および？）を取るか、どのI / Oフレームワークを選択するか、キャッシュとストレージを同期する方法は？ インフラストラクチャの問題の束。 問題を解決する必要があるのに、なぜインフラストラクチャの問題を解決するのですか？ もちろん、特定のテクノロジーXとYが好きで、これらの欠点をイデオロギーに変換すると言うことができます。 ただし、データがコードから一定の距離にあるという事実（上の写真）を否定することはできません。これはレイテンシを追加し、RPSを削減する可能性があります。
この記事の目的は、Webサーバー、バランサーとしてのNginxと、アプリケーションサーバー、キャッシュ、ストレージとしてのTarantoolに基づいて構築された代替案について話すことです。
キャッシュとストレージの改善
Tarantoolにはいくつかの興味深い特性があります。 Tarantoolは効果的なメモリ内DBであるだけでなく、本格的なアプリケーションサーバーでもあり、アプリケーションはLua（luajit）、C、C ++、つまり 任意の複雑さのロジックを作成できますが、1つの制限があります：ファンタジー。 使用可能なメモリよりも多くのデータがある場合、一部のデータはSophiaエンジンを使用してディスクに保存できます。 Sophiaが適合しない場合は、何か他のものを取り込んで「冷たい」データをドロップすることができます。 タランツールから別のストレージに現在必要のないデータ、および「ホット」部分はタランツールに保存されます。 メモリ内。 これにはどのような利点がありますか？
- 仲介者はいません。 少なくともデータのホットな部分はコードと同等です。
- メモリ内のホットデータ。
- Luaについて説明している場合、コードは非常にシンプルで簡単に更新できます。
- トランザクション、レプリケーション、シャーディング、およびその他の多くのTarantool機能。
Webサーバーの改善
データのエンドユーザーはユーザーです。 通常、ユーザーはNginxを介してバランサー/プロキシとしてApplication Serverからデータを受け取ります。 TarantoolとHTTPの両方と通信できるデーモンを作成するオプションは適切ではありません。最初の描画につながり、再び開始点に戻るからです。 したがって、私たちは反対側から状況を見て、別の質問をします：「データとユーザーの間の仲介者を取り除く方法？」 この質問に対する答えは、Tarantool Nginx Upstream Moduleの実装でした。
Nginxアップストリーム
Nginx Upstreamは、パイプ/ソケットを介したバックエンドへの永続的な（アップストリームキープアライブを参照）接続です。以降、これを「プロキシ」と呼びます。 Nginxは、アップストリームルールを記述するための多くの多様な機能を提供します。TarantoolでHTTPをプロキシするには、次の機能が特に重要です。
- Nginxが負荷を分散する複数のバックエンドを指定する機能。
- バックアップを指定する機能、つまり アップストリームが機能しない場合の行き先を示します。
これらの機能により、次のことが可能になります。
- たとえば、シャーディングと組み合わせて、N Tarantoolに負荷を分散すると、ノード全体で均一な負荷を持つクラスターを構築できます。
- レプリケーションを使用してフォールトトレラントシステムを作成できます。
- アイテムa）とアイテムb）を使用して、フェールオーバークラスターを取得します。
オプションを部分的に示すNginxの設定例：
# Tarantool upstream tnt { server 127.0.0.1:10001; # localhost server node.com:10001; # - server unix:/tmp/tnt; # unix socket server node.backup.com backup; # backup } # HTTP- server { listen 8081 default; location = /tnt/pass { # Nginx Tarantool Upstream Module # Upstream tnt_pass tnt; } }
Nginx Upstreamの設定の詳細については、 http ： //nginx.org/en/docs/http/ngx_http_upstream_module.html#upstreamをご覧ください。
Nginx Tarantoolアップストリームモジュール（v0.1.4安定）
主な機能：
- モジュールは、ディレクティブ-tnt_pass UPSTREAM_NAMEを使用してNginx.confでアクティブ化されます。
- 高速ストリーム変換HTTP + JSON <-> Tarantoolプロトコル、最小限のロック（解析用）Nginxワーカー。
- 双方向の非ブロッキングI / O Nginx。
- 素敵なボーナスとして：Nginx、Nginx Upstreamのすべての機能。
- モジュールでは、JSONベースのプロトコルを介してTarantoolストアドプロシージャを呼び出すことができます。
- データはHTTP（S）POSTを介して配信されます。これは、現代のWebAppだけでなく便利です。
入力データ
[ { "method": STR, "params":[arg0 ... argN], "id": UINT }, ...N ]
「方法」
ストアドプロシージャの名前。 名前は、Tarantoolのプロシージャの名前と一致する必要があります。 たとえば、lua関数
do_something(a, b)
を呼び出すには、
“method”: “do_something”
が必要です。
「パラム」
ストアドプロシージャの引数。 たとえば、引数をlua関数
do_something(a, b)
に渡すには、
“params”: [ “1”, 2 ]
が必要です。
Id
クライアントによって設定された数値識別子。
インプリント
[ { "result": JSON_RESULT_OBJECT, "id":UINT, "error": { "message": STR, "code": INT } }, ...N ]
「結果」
ストアドプロシージャによって返されるデータ。 たとえば、lua関数
do_something(a, b)
は
return {1, 2}
返し
return {1, 2}
次に
“result”: [[1, 2]]
返します
“result”: [[1, 2]]
Id
クライアントによって設定された数値識別子。
「エラー」
エラーが発生した場合、このフィールドには理由に関するデータが含まれます。
プロトコルの詳細はこちら： https : //github.com/tarantool/nginx_upstream_module/blob/master/README.md
ハローワールド
Nginxを起動します
ソースからnginxを収集します：
$ git clone https://github.com/tarantool/nginx_upstream_module.git $ cd nginx_upstream_module $ git submodule update --init --recursive $ git clone https://github.com/nginx/nginx.git $ cd nginx && git checkout release-1.9.7 && cd - $ make build-all-debug
build-all-debugの目標はデバッグバージョンです。 Nginxの構成が少なくなるようにします。 すべてをゼロから設定したい人には、
build-all
を
build-all
目標があります。
ファイル
test-root/conf/nginx.conf
http { # Tarantool backend upstream echo { server 127.0.0.1:10001; } server { listen 8081 default; # Nginx *:8081 server_name tnt_test; location = /echo # *:8081/echo 'echo' Tarantool Upstream { tnt_pass echo; } } }
$ ./nginx/obj/nginx # nginx
タランツールを起動する
Tarantoolは、パッケージから配送するか、組み立てることができます。
hello-world.lua
-- , Tarantool DB. -- - 1- . function echo(a) return {{a}} end box.cfg { listen = 10001; -- Tarantool }
パッケージからTarantoolをインストールした場合、次のように起動できます。
$ tarantool hello-world.lua # lua-.
ストアドプロシージャを呼び出します
任意のHTTPコネクタでechoストアドプロシージャを呼び出すことができます。必要なのは、127.0.0.1 / echoでHTTP POSTを実行し、本文に次のJSONを渡すことです（入力データを参照）。
{ "method":"echo", // , Tarantool "params":[ {"Hello world": "!"} // 1- - ], "id":1 // ID }
このプロシージャをwgetと呼びます
$ wget 127.0.0.1:8081/echo --post-data '{"method":"echo","params":[{"Hello world": "!"}],"id":1}' $ cat echo {"id":1,"result":[[{"hello world":"!"}]]}
さらにいくつかの例：
https://github.com/tarantool/nginx_upstream_module/blob/master/examples/echo.html
https://github.com/tarantool/nginx_upstream_module/blob/master/test/client.py
まとめると
Nginx Tarantoolアップストリームモジュールを使用する長所：
- 原則として、同じレベルで仲介者、コード、データはありません。
- 比較的単純な構成
- N Tarantoolの負荷分散。
- 高速、低遅延;
- バイナリではなくJSONベースのプロトコル。TarantoolDriverを探す必要はありません。JSONはどこにでもあります。
- Tarantool Sharding / ReplicationおよびNginx =クラスター化ソリューションですが、これは別の記事のトピックです。
- ソリューションは本番環境で使用されます。
短所：
- よりコンパクトで高速なMsgPackの代わりにオーバーヘッドJSON。
- ソリューションはボックス化されておらず、構成する必要があり、展開方法を考える必要があります。
計画：
- OpenRestyおよびnginScriptのサポート。
- WebSocketおよびHTTP 2.0のサポート。
ベンチマーク結果は非常に興味深いものであり、別の記事に掲載されます。 Tarantoolは、アップストリームモジュールのように、すべてを試してみたい、使用したい、または新しいアイデアを表現したい場合は、常に新しいユーザー向けに開いています。github、googleグループに連絡してください。
参照資料
Tarantool Webサイト-http : //tarantool.org
Git Tarantool- https://github.com/tarantool/tarantool
Git Tarantool Nginxアップストリームモジュール-github.com/tarantool/nginx_upstream_module
Googleグループ-https://groups.google.com/forum/#!forum/tarantool
PS次の記事では、Tarantoolを使用して解決できるタスクを示します。