.NETで記述されたサーバーアプリケーションの主要なデータウェアハウスとしてのTarantool

こんにちは、Habr！ 本日、2017年3月2日にMail.Ru Groupで開催されたTarantool Meetupで発表されたレポートのテキスト版を共有したいと思います。誰がパフォーマンスを見ましたか。 私は、オンライン調査サービスを開発するeVoteで働いています。 製品でWindowsおよび.NETテクノロジを積極的に使用しています。この投稿では、Tarantool DBMSをテクノロジスタックに追加した方法について説明します。

この記事の執筆に協力してくれたMail.Ru Groupの同僚、友人、従業員に感謝します。

DBMSの選択

すべてのプロジェクトの寿命において、遅かれ早かれ、すべてのデータを保存するDBMSを選択する必要があるときに転換点が生じます。 この観点から、私たちのプロジェクトは単純です：ユーザー、投票、回答、途中で収集された何らかの情報-これらはすべて、キーバリューストレージに完全に保存できます。 したがって、最初に、Redis、Tarantool、およびhandlersocketを備えたMySQLの3つのオプションを検討しました。 最初からのお気に入りはRedisでした。 それは高速に動作し、Stack Overflowチームによって作成されたすばらしい.NETコネクタを備えています。 ちなみに、Stack Overflow自体は.NETで記述され、Windows上で実行され、Microsoft、RedisなどのSQL Serverがあります。 Redisには優れたドキュメントがあります 。 Redisと一緒に仕事したことのない新しいプログラマーを雇ったら、彼をそこに送ります。3日後には、Redisを使用するために知っておく必要があることをすべて知っています。

2番目の数字はTarantoolでした。 残念ながら、彼はRedisのような便利なサイトを持っていませんでした。 .NETのコネクタと同様。 彼はRedisとそれほど違いがなかったので、スピードにおいて彼は完全に私たちに合っていました。 先読みログを有効にすると、すべてのレコードがディスクに保存されます。 また、コントローラー、ディスク、または他のハードウェアにバグがない場合、非常に確実になります。 Tarantoolにはセカンダリインデックスもあります。 場合によっては、これは非常に重要な機能です。 Redisではそうではなく、手動で行う必要があります。

Handlersocketは部外者であることが判明しました。 RedisおよびTarantoolよりも低速です。 ただし、ACIDモデルは、MySQLのエンジンがサポートしている場合に使用できます。 MySQLのインフラストラクチャ全体（レプリケーション、モニタリング、エクスプロイト、バックアップ）を利用できます。 プレーンSQLで複雑なレポートを作成できます。 .NET用のコネクタもありませんでした。

その結果、Redisを選択し、クローズドアルファで起動しました。 しかし、しばらくすると、セカンダリインデックスの欠如が、私たちが思っていたよりも深刻な問題であることが明らかになりました。 作成者が作成したすべての投票を選択する必要がある場合は、ストレージ用の追加リストを作成する必要があります（もちろん、徹底的な検索を実行できますが、これは私たちの場合ではありません）。 さまざまな障害の結果として、データの一貫性が失われるリスクがあります。 Luaスクリプトまたはトランザクションを介してこれを修正しようとすると、Redisが約3〜4倍遅くなるという事実に至りました。 私の意見では、これはRedis自体の問題ではなく、誤用の結果です。

TarantoolとWindows

次に、Tarantoolに切り替えることにしました。 そして、すぐに2つの問題に直面しました。 TarantoolにはWindows用のバイナリがまだありません（いつ表示されるかは不明です）。 .NET用のコネクタはありませんでした-2。 一般的に言えば、これは議論の余地のある質問ですが、Windowsでのストレージのバージョンの欠如を不利と呼ぶことはできますか？ これは利点だと思います。 実際、実稼働環境ではLinuxが存在する可能性が高く、Windows用のバージョンがないため、プログラマはすべてが実際にどのように機能するかを理解する必要があります。 デバッグと監視のプログラマは、本番環境と同じツールを使用します。 私の観察によると、これにより、エラーなしで高品質のコードを記述する可能性が高まり、災害時のダウンタイムが短縮されます。

開発用のDocker for Windowsを使用して、最初の問題を解決しました。 しかし、2番目の問題はより複雑でした。

コネクター

Tarantool用の既成のコネクタがなかったため、独自に作成しました。 このために、2つの問題を解決する必要がありました。 最初：これはTarantoolのデータ交換形式であるため、 msgpackでシリアライゼーションとデシリアライゼーションを実装します。 MsgPack.Lightプロジェクトのフレームワーク内で解決しました。これは、 msgpackにパッケージ化されたデータも保存するためです。 2番目のタスクは、文字通りTarantool iProtoでデータ交換プロトコルを実装することでした 。 progaudi.tarantoolプロジェクトの一部として解決されました。

サポートします

• .NET 4.6以降
• 新しいオープンソースフレームワーク.NET Core：netstandard 1.4以降。

コネクタはtarantool.csharpと呼ばれていましたが、 コミュニティからのフィードバックを受けて、progaudi.tarantoolという名前に変更しました。 これで、名前によって混乱が生じることはありません。F＃からのコネクタを使用できるかどうか。 それは最初から可能でした。

MsgPack.Lightの最近の改善のおかげで、コネクターはTarantulaスカラーデータ型で動作することを学びました。 将来的には、コネクタでの作業をさらに簡素化し、ユーザーオブジェクトのTarantoolTuple構造への明示的な変換を回避する予定です。

DDLはiProtoの範囲外であり、EVALコマンドのラッパーで実装する必要があるため、DDLをサポートしていません。 個人的には、プログラマーがTarantoolを使用する場合は、Luaでスキームを作成する必要があると思います。この場合、管理者とのやり取りを行い、すぐに作業環境に配布できるからです。 たぶん私は間違っており、私たちは.NETからこれを行う能力を実現しています。

現在、1つのTarantoolノードのみと接続しています。 CALL_16を完全にはサポートしていません。特定の場合、Tarantool側で奇妙なパッケージングが発生し、逆シリアル化中にエラーが発生します。 新しいCALLは完全にサポートされています。使用することをお勧めします。

Tarantoolコネクタ開発機能

残念ながら、Tarantoolでは、すべてのリクエストをログに出力するようサーバーに依頼することはできません。 状況によっては、これによりデバッグが非常に難しくなります。通常、Tarantoolサーバーのパフォーマンスは気にしません。 すべての要求をログに記録するなど、何らかのペンを取得したいと思います。

リクエストをログに記録するとき、どういうわけかそれらを互いに分離したいと思います。 このために、接続ID（box.session.id）と要求ID（box.session.sync）があります。 残念ながら、box.session.syncは同じ接続内のすべての要求と共有されます。その結果、要求が降伏点（ データベースへの書き込み、制御の手動転送など）に到達したために中断された場合、変更される可能性があります 。 原則として、これは、たとえばストアドプロシージャなど、いくつかのログポイントがある場合にのみ重要です。 そのような場合、box.session.syncはローカル変数の最初のyieldポイントまで保存されるべきです。

アプリケーションサーバー

Tarantoolの重要な部分は、アプリケーションサーバーです。 他のモジュールの自動リブート、 シャーディング 、他のDBMS（ 1、2など）のキューおよびドライバーで終わるなど、単純なものから始まる、多くの既製のモジュールがあります 。 私たちが試したすべてのモジュールは、うまく機能し、十分に文書化され、維持されています。

この多様性のうち、キューにはtarantool / queueを使用し、メトリックの収集にはtarantool / prometheusを使用します。 また、Luaのロジックもいくつかあります。 少し-私たちのチームは.NETの世界の出身だからです。 静的コード分析、段階的なデバッグ、便利なプロファイラーを使用することに慣れています。 Luaにはこれ、特に静的コード分析に関する問題があります。

複製

同期レプリケーションを取得したいです。 私たちはすでにそれなしで生きる方法を知っていますが、とても楽しみにしています。 これまでのところ、利用可能なマスターマスタ非同期レプリケーションを使用しています。 当社のサービスの1つは写真を使用します。 ランダムなキーがそこに表示され、キーに一致する確率は非常に小さいため、任意のノードに書き込むことができます。 写真とSHA256の生成されたGUIDを一致させる必要があります。 すぐにはこれに至らなかったため、コネクタはまだいくつかのノードへの接続方法を知りません。 今年は間違いなく修正します。

古いバージョンのクラスターアセンブリ

非常に古いビルド1.7.3-0では、クラスターがアセンブルされない場合があります。 3つのマスターノードがあるとします。 それらを同じ構成に向けて実行します。 そして、ノードのいずれかがデータを収集するソースを見るまで、他のクライアントからのリクエストを受け入れません。 残念ながら、これらのソースはそれらの顧客です。 その結果、3つのノードすべてが要求に応答せず、30秒待機します。 この時点で、彼らはソースを検索し、見つけられず、ログに書き込みます：「ソースがありません、私はオフにしました。」 そして、クラスターは行きません。 手動で収集する必要があります。 一般的な構成なしで1つのノードを開始します。 上昇し、残りのノードをそれに接続してから、構成を単一のものに変更します。 新しいバージョンでは、このバグはすでに修正されています。

tarantool / tarantool dockerのイメージのバージョン管理

イメージのバージョンが1.7.3だとしましょう。 そして、どのバージョンのTarantoolが入っていますか？ 1.7.3はわかっていますが、ビルド番号は不明です。 唯一のオプションは、ソースを表示することです。 114にはまだ私たちを傷つける問題があり、116には存在するかどうかわからないため、Tarantoolバージョン1.7.3-115が必要だとしましょう。 どのバージョンの画像を使用しますか？

この問題は単純に解決しました。自分でイメージを収集し、特定のビルド番号を指定すると、すべてが正常に機能します。 しかし、全体的にこれは小さな問題です。 デフォルトのイメージは正常に機能し、ほとんどの要求をカバーします。これには、Tarantoolを使用するために必要なすべての基本モジュール（監視、キューなど）が含まれています。

インタラクティブクエリ

Tarantoolでインタラクティブクエリを作成するには、Luaを理解し、コマンドラインを使用できる必要があります。 テスターと管理者はコマンドラインを処理できますが、Luaに対処することに熱心ではありません。 彼らはすぐにSQLスクリプトを書き、カウンターやタイムスタンプをチェックしたい。 したがって、発表されたSQLite方言のサポートを本当に楽しみにしています。

監視とログ

それらはすべて問題ありません。 タランツール/プロメテウスモジュールがあり 、これはプロメテウスの Webサイトで公開されています。 本番ドッカーを使用するので、Fluentd（ 1および2 ）を使用してログを収集し、 ElasticSearchに入れます。

結論

.NETは単なるWindowsにはほど遠い：.NET Coreはすべてのプラットフォームで実行されます。 Linuxで正常に動作する実稼働環境の.NETアプリケーションがあります。 オープンソースプロジェクトは、Windows、Mac OS、Linuxで問題なくビルドして実行できます（Windows 10、Max OS X、Ubuntu 16.04のみがテストされています）。 同時に、開発およびデバッグでは、.NETの世界で利用可能なすべての豊富なツールを使用することができます。多くの場合、商用開発でも無料です。

新しい.NETソリューションのクロスプラットフォームの性質により、以前はアクセスできなかったツール、たとえばTarantoolを使用することが可能になります。 速度、セカンダリインデックス、DBMSをアプリケーションサーバーまたはタスクキューとして使用する機能が重要な場合、今日Tarantoolは非常に良い選択です。