Tarantool カートリッジ: XNUMX 行の Lua バックエンド シャーディング

Mail.ru Group には Tarantool があります。これは Lua のアプリケーション サーバーであり、データベースとしても機能します (またはその逆?)。 高速で優れていますが、XNUMX つのサーバーの機能は依然として無制限ではありません。 垂直スケーリングも万能薬ではないため、Tarantool には水平スケーリング用のツール、vshard モジュールが用意されています。 【1]。 これにより、複数のサーバー間でデータをシャード化できますが、データを設定してビジネス ロジックを接続するには、データをいじる必要があります。

良いニュース: 私たちはいくつかの大物を集めました (例: 【2], 【3]) を作成し、この問題の解決策を大幅に簡素化する別のフレームワークを作成しました。

タランツール カートリッジ は、複雑な分散システムを開発するための新しいフレームワークです。 これにより、インフラストラクチャの問題を解決するのではなく、ビジネス ロジックの作成に集中できます。 このカットの下では、このフレームワークがどのように機能するか、およびそれを使用して分散サービスを作成する方法について説明します。

そして実際、何が問題なのでしょうか？

タランチュラもいますし、vshard もいます - これ以上何を望むでしょうか?

まず、利便性の問題です。 vshard 構成は、Lua テーブルを通じて構成されます。 複数の Tarantool プロセスからなる分散システムが正しく動作するには、構成がどこでも同じである必要があります。 これを手動でやりたい人は誰もいません。 したがって、あらゆる種類のスクリプト、Ansible、およびデプロイメント システムが使用されます。

カートリッジ自体が vshard 構成を管理します。これはカートリッジの構成に基づいて行われます。 独自の分散構成。 これは本質的に単純な YAML ファイルであり、そのコピーが各 Tarantool インスタンスに保存されます。 単純化すると、フレームワーク自体がその構成を監視し、どこでも同じであることを確認します。

第二に、これも利便性の問題です。 vshard 構成はビジネス ロジックの開発とは何の関係もなく、プログラマーの作業の注意をそらすだけです。 プロジェクトのアーキテクチャについて議論するとき、ほとんどの場合、個々のコンポーネントとその相互作用について話します。 クラスターを 3 つのデータセンターに展開することを考えるのは時期尚早です。

私たちはこれらの問題を何度も解決し、ある時点で、作成、開発、テスト、CI/CD、メンテナンスといったアプリケーションのライフサイクル全体を通しての作業を簡素化するアプローチを開発することができました。

Cartridge では、Tarantool の各プロセスにロールの概念が導入されています。 ロールは、開発者がコードの作成に集中できるようにする概念です。 プロジェクトで利用可能なすべてのロールは XNUMX つの Tarantool インスタンス上で実行でき、テストにはこれで十分です。

Tarantool カートリッジの主な特徴:

• 自動化されたクラスター オーケストレーション。
• 新しい役割を使用してアプリケーションの機能を拡張します。
• 開発および展開用のアプリケーション テンプレート。
• 組み込みの自動シャーディング。
• Luatest テスト フレームワークとの統合。
• WebUI と API を使用したクラスター管理。
• パッケージ化および展開ツール。

こんにちは世界！

フレームワーク自体を紹介するのが待ちきれないので、アーキテクチャの話は後回しにして、簡単なことから始めます。 Tarantool 自体がすでにインストールされていると仮定すると、あとは次のことを行うだけです。

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

これら XNUMX つのコマンドによりコマンド ライン ユーティリティがインストールされ、テンプレートから最初のアプリケーションを作成できるようになります。

$ cartridge create --name myapp

そして、これが得られるものです:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

これは、既成の「Hello, World!」が含まれる Git リポジトリです。 応用。 依存関係 (フレームワーク自体を含む) を事前にインストールしたので、すぐに実行してみましょう。

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

したがって、将来のシャード アプリケーション用に XNUMX つのノードが実行されています。 好奇心旺盛な一般人でも、すぐに Web インターフェイスを開いて、マウスを使用して XNUMX つのノードのクラスターを構成し、その結果を楽しむことができますが、喜ぶのは時期尚早です。 ここまでのところ、アプリケーションは何も役に立つことはできません。デプロイメントについては後ほど説明しますが、ここでコードを記述します。

アプリケーション開発

想像してみてください。XNUMX 日に XNUMX 回、データを受信して​​保存し、レポートを作成する必要があるプロジェクトを設計しているとします。

図の描画を開始し、その上にゲートウェイ、ストレージ、スケジューラという XNUMX つのコンポーネントを配置します。 私たちはアーキテクチャのさらなる開発に取り組んでいます。 ストレージとして vshard を使用するため、vshard-router と vshard-storage をスキームに追加します。 ゲートウェイもスケジューラーもストレージに直接アクセスしません。ルーターはそのために存在し、そのために作成されました。

この図は、コンポーネントが抽象的に見えるため、プロジェクトで構築するものをまだ正確に表していません。 これが実際の Tarantool にどのように投影されるかをまだ確認する必要があります。コンポーネントをプロセスごとにグループ化しましょう。

vshard-router とゲートウェイを別のインスタンスに保持することにほとんど意味はありません。 これがすでにルーターの責任であるのに、なぜもう一度ネットワークをサーフィンする必要があるのでしょうか? これらは同じプロセス内で実行する必要があります。 つまり、ゲートウェイと vshard.router.cfg の両方が XNUMX つのプロセスで初期化され、ローカルで対話できるようになります。

設計段階では、XNUMX つのコンポーネントを使用すると便利でしたが、開発者としてコードを作成する際には、Tarnatool の XNUMX つのインスタンスを起動することは考えたくありません。 テストを実行して、ゲートウェイを正しく作成したかどうかを確認する必要があります。 あるいは、同僚に機能をデモンストレーションしたいかもしれません。 なぜわざわざ XNUMX つのコピーを導入する必要があるのでしょうか? こうして役割という概念が生まれました。 ロールは、ライフサイクルがカートリッジによって管理される通常の luash モジュールです。 この例では、ゲートウェイ、ルーター、ストレージ、スケジューラーの XNUMX つがあります。 別のプロジェクトではさらにあるかもしれません。 すべてのロールを XNUMX つのプロセスで実行でき、これで十分です。

そして、ステージングまたは運用環境へのデプロイメントに関しては、ハードウェアの機能に応じて、各 Tarantool プロセスに独自の役割セットを割り当てます。

トポロジ管理

どのロールが実行されているかに関する情報は、どこかに保存する必要があります。 そして、この「どこか」は、すでに上で述べた分散構成です。 これについて最も重要なことは、クラスター トポロジです。 ここでは、3 つの Tarantool プロセスからなる 5 つのレプリケーション グループを示します。

データを失いたくないので、実行中のプロセスに関する情報は慎重に扱います。 カートリッジは、XNUMX フェーズ コミットを使用して構成を追跡します。 構成を更新する場合、最初にすべてのインスタンスが利用可能であり、新しい構成を受け入れる準備ができているかどうかが確認されます。 この後、第 XNUMX フェーズで構成が適用されます。 したがって、たとえ XNUMX つのコピーが一時的に利用できなくなったとしても、悪いことは何も起こりません。 構成は単純に適用されず、事前にエラーが表示されます。

また、トポロジセクションには、各レプリケーショングループのリーダーなどの重要なパラメータが示されます。 通常、これは記録されているコピーです。 残りはほとんどの場合読み取り専用ですが、例外もあるかもしれません。 勇敢な開発者は競合を恐れず、複数のレプリカに並行してデータを書き込むことができますが、何があっても XNUMX 回実行すべきではない操作がいくつかあります。 このためにリーダーの兆候があります。

役割の寿命

このようなアーキテクチャに抽象的な役割が存在するには、フレームワークがそれらを何らかの方法で管理する必要があります。 当然のことながら、Tarantool プロセスを再起動せずに制御が行われます。 ロールを管理するためのコールバックが 4 つあります。 カートリッジ自体は、分散構成に記述されている内容に応じてそれらを呼び出し、それによって構成を特定の役割に適用します。

function init()
function validate_config()
function apply_config()
function stop()

それぞれの役割には機能があります init。 これは、ロールが有効になったとき、または Tarantool が再起動されたときに XNUMX 回呼び出されます。 たとえば、box.space.create を初期化する場合や、スケジューラーが特定の時間間隔で作業を実行するバックグラウンド ファイバーを起動できる場合などに便利です。

XNUMXつの機能 init 十分ではないかもしれません。 カートリッジを使用すると、ロールがトポロジの保存に使用する分散構成を利用できるようになります。 同じ構成内で新しいセクションを宣言し、そこにビジネス構成のフラグメントを保存できます。 この例では、これはデータ スキーマまたはスケジューラー ロールのスケジュール設定である可能性があります。

クラスター呼び出し validate_config и apply_config 分散構成が変更されるたびに。 構成が XNUMX フェーズ コミットによって適用されると、クラスターは各ロールがこの新しい構成を受け入れる準備ができているかどうかを確認し、必要に応じてユーザーにエラーを報告します。 構成が正常であることに全員が同意すると、 apply_config.

ロールにもメソッドがあります stop、ロールの出力をクリーンアップするために必要です。 このサーバーではスケジューラーが不要になった場合、スケジューラーが開始したファイバーを停止する可能性があります。 init.

ロールは相互に対話できます。 私たちは Lua で関数呼び出しを書くことに慣れていますが、特定のプロセスに必要な役割がない場合があります。 ネットワーク経由の呼び出しを容易にするために、Tarantool に組み込まれている標準のネットボックスに基づいて構築された rpc (リモート プロシージャ コール) 補助モジュールを使用します。 これは、たとえば、ゲートウェイが XNUMX 日待つのではなく、すぐにジョブを実行するようにスケジューラに直接要求したい場合に便利です。

もう XNUMX つの重要な点は、耐障害性の確保です。 カートリッジは SWIM プロトコルを使用して状態を監視します 【4]。 つまり、プロセスは UDP を介して相互に「噂」を交換します。各プロセスは隣接するプロセスに最新のニュースを伝え、プロセスはそれに応答します。 突然答えが返ってこない場合、タランツールは何かが間違っているのではないかと疑い始め、しばらくすると死を暗唱し、周囲の人々にこのニュースを語り始めます。

このプロトコルに基づいて、カートリッジは自動障害処理を組織します。 各プロセスはその環境を監視し、リーダーが突然応答を停止した場合、レプリカがその役割を引き継ぐことができ、カートリッジはそれに応じて実行中の役割を構成します。

切り替えを頻繁に行うと、レプリケーション中にデータの競合が発生する可能性があるため、ここでは注意が必要です。 もちろん、自動フェイルオーバーをランダムに有効にするべきではありません。 私たちは何が起こっているのかを明確に理解し、リーダーが復元され王冠が返還された後も複製が中断されないことを確認する必要があります。

これらすべてから、ロールはマイクロサービスに似ていると感じるかもしれません。 ある意味、それらは Tarantool プロセス内のモジュールとしてのみ存在します。 しかし、根本的な違いも数多くあります。 まず、すべてのプロジェクト ロールが同じコード ベース内に存在する必要があります。 そして、すべての Tarantool プロセスは同じコード ベースから起動される必要があるため、スケジューラを初期化しようとしたときにスケジューラが単に存在しないというような驚きが起こらなくなります。 また、コード バージョンの違いを許可しないでください。そのような状況でのシステムの動作の予測とデバッグは非常に困難です。

Docker とは異なり、単にロール「イメージ」を取得し、それを別のマシンに移動してそこで実行することはできません。 私たちの役割は、Docker コンテナーほど分離されていません。 また、XNUMX つのインスタンスで XNUMX つの同一のロールを実行することはできません。 ロールは存在するか存在しないかのどちらかであり、ある意味、シングルトンです。 そして XNUMX 番目に、役割はレプリケーション グループ全体で同じである必要があります。そうしないと不合理になります。データは同じですが、構成が異なります。

導入ツール

私は、Cartridge がアプリケーションの展開にどのように役立つかを示すことを約束しました。 他の人の作業を容易にするために、フレームワークは RPM パッケージをパッケージ化しています。

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

インストールされたパッケージには、アプリケーションとインストールされた依存関係の両方など、必要なものがほぼすべて含まれています。 Tarantool も RPM パッケージの依存関係としてサーバーに到着し、サービスを開始する準備が整います。 これは systemd を通じて行われますが、最初に少しの設定を記述する必要があります。 少なくとも、各プロセスの URI を指定します。 たとえば XNUMX つあれば十分です。

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

ここには興味深いニュアンスがあります。 バイナリ プロトコル ポートだけを指定する代わりに、ホスト名を含むプロセスのパブリック アドレス全体を指定します。 これは、クラスター ノードが相互に接続する方法を認識するために必要です。 Advertise_uri アドレスとして 0.0.0.0 を使用するのは悪い考えです。これはソケット バインドではなく、外部 IP アドレスである必要があります。 これがなければ何も機能しないため、Cartridge では単に間違った Advertise_uri でノードを起動することはできません。

構成の準備が完了したので、プロセスを開始できます。 通常の systemd ユニットでは複数のプロセスの起動が許可されていないため、カートリッジ上のアプリケーションはいわゆるプロセスによってインストールされます。 次のように動作するインスタンス化されたユニット:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

構成では、Cartridge が Web インターフェイスを提供する HTTP ポート (8080) を指定しました。それにアクセスして見てみましょう。

プロセスは実行されていますが、まだ構成されていないことがわかります。 カートリッジは誰が誰を複製するべきかをまだ知らず、自分で決定を下すことができないため、私たちの行動を待っています。 しかし、選択肢はあまりありません。新しいクラスターの寿命は最初のノードの構成から始まります。 次に、他のものをクラスターに追加し、ロールを割り当てます。この時点で、デプロイメントは正常に完了したと見なされます。

お気に入りのドリンクをグラスに注いで、一週間の長い仕事の後にリラックスしましょう。 アプリケーションは使用できます。

結果

結果は何ですか? 試して、使用し、フィードバックを残し、Github でチケットを作成します。

リファレンス

【1] Tarantool » 2.2 » リファレンス » Rocks リファレンス » vshard モジュール

【2] Tarantool に基づいて Alfa-Bank の投資ビジネスの中核をどのように実装したか

【3] 新世代の課金アーキテクチャ: Tarantool への移行による変革

【4] SWIM - クラスタ構築プロトコル

【5] GitHub - tarantool/カートリッジ-cli

【6] GitHub - タランツール/カートリッジ

出所： habr.com