タランツールのケーススタディ

Tarantoolは、オープンソースのデータベース管理システムです。 誰でもGitHubからダウンロードして、商用アプリケーションと非商用アプリケーションの両方で使用できます。 本日、メールのテクニカルディレクターであるデニスアニキンが、このデータベースの使用例についてお話します。 この資料は、FailOver Conferenceでの講演に基づいています。



Tarantoolは 、Mail.Ru Groupで7年以上開発されています。 このDBMSは、負荷の高いシステム向けに設計されています。 主な違いは、トランザクション、レプリケーション、信頼性に関連するすべてなど、実際のデータベースのプロパティを組み合わせたデータベースですが、MemcachedやRedisなどのキャッシュと同じくらい高速です。



Mail.Ru Groupでは、製品のかなりの半分がTarantoolを使用しています。 DBMSがキャッシュプロパティを必要とする場合、つまり、1秒あたり10万回の更新を実行できる必要がある場合、非常に優れた待機時間（1ミリ秒以下）などが必要な場合に適しています。 多くのDBMSはこれらの基準を満たしていません。 多数のシャードを使用する場合、これは良くありません。トランザクションが機能しなくなり、整合性が失われ、他の問題が発生します。 そして、キャッシュには、多くの有用なデータベースプロパティがありません。ディスク上のデータストレージの信頼性、トランザクションなどです。 たとえば、キャッシュには通常、ストアドプロシージャのような重要なものはありません。 これにより、ロジックをデータウェアハウス側に転送できます。

DB +キャッシュ=？

もちろん、Tarantoolを使用しなくても、負荷の高いプロジェクトに耐えることができます。 1つのボトルにデータベースとキャッシュの両方のプロパティが必要だとしましょう。 次に、非常に一般的なスキームを適用できます。データベースの上にキャッシュを配置します。 次に、すべての要求が最初にキャッシュに送られ、必要なデータがあれば、それらはユーザーに渡されます。 それらが存在しない場合、リクエストはデータベースにリダイレクトされます。 データベースに保存せずにキャッシュに何かを保存することはできないため、すべての更新はすぐにデータベースとキャッシュに送信されます。そうしないと、このデータが失われる可能性があります。



このスキームにより、データベースのプロパティの一部を取得できます。 たとえば、2つのシステム、特にキャッシュが表示される場合、トランザクションの問題はないため、トランザクションとプロシージャのストレージはありません。 ある意味では、データベース内のデータとキャッシュ内のデータがレプリケートされるため、レプリケーションも失われます。 また、ストアドプロシージャやその他のデータベースプロパティも失われます。 キャッシュプロパティも部分的に保持されます。 このようなシステムは、読み取り要求の処理速度が向上するため、より高速に機能しますが、同時に、たとえば、書き込みアクセスが高速になることはありません。 データベースにテーブルバキュームなどが原因でデータベースの速度が低下すると、データベースがないと記録が機能しないため、システムの記録速度が低下します。



一般的に、これはワークフロー図です。 これにより、1つのシステムでベースとキャッシュの両方のプロパティの一部を取得できます。 これで十分な場合は、そのようなスキームを使用する必要があります。



確かに、この場合、2つの一般的な問題があります-一貫性のないデータとコールドスタート。 「不整合」とは、キャッシュとデータベースが互いのレプリカではなく、2つの別個のエンティティであるため、キャッシュとデータベースのデータが異なる可能性があることを意味します。 「コールドスタート」とは、キャッシュが開始されたときにまだ空であり、データが存在しないため、すべての要求がデータベースに送信され、システムパフォーマンスが期待どおりにならない状況です。



これらの点に混乱していない場合、「データベース上のキャッシュ」スキームは完全に機能するオプションです。 そうでなければ、これらの問題はすべて最初に解決されるため、Tarantoolに注意することをお勧めします。 その開発の理由の1つは、複数のストレージで構成されるこのような複雑な異種システムをより高価にするのではなく、1つで簡単に管理し、その中にすべてのホットデータを格納することです。

エンジン

Tarantoolには2つのストレージエンジンがあります。 それらの1つは、インメモリエンジンです。 すべてのデータはメモリに保存され、データのコピーはディスクに保存されます。 各トランザクションは単純にログでディスクに書き込まれ、時々、データベース全体のスナップショット全体がディスクにフラッシュされます。 バックグラウンドで非同期的にリセットします。 リセットされている間は、すべての新しい更新が別々の場所に送られるため、データベースは機能します。 つまり、すべてがブレーキなしで機能します。 トランザクションログは常に書き込まれます。



2番目のディスクエンジン。 これにより、すべてをディスクに保存できます。 さらに、SSDとハードドライブの両方を使用できます。 このエンジンは、最適化されたGoogleのLevelDBから生まれました。

長所と短所

Tarantoolにはキャッシュ固有の機能があります。

• ホットデータ。
• 可用性99.99％。
• 高並列負荷での最適なパフォーマンス。
• レイテンシー：
  
  
  • リクエストの99％<1 ms
  • リクエストの99.9％<3 ms
• 書き込み負荷-単一のCPUコアで1秒あたり最大100万トランザクション。
• 多くのサーバーは必要ありません。
• 最適なメモリ使用量。
• システムは常に動作し、メンテナンス作業のために休憩を取る必要はありません。

基本的に、すべてが高速で接続されています。 従来のDBMSにはこれらの機能がありません。 同時に、Tarantoolには従来のDBMSのプロパティもあります。

• 永続性（ディスク上のデータストレージの信頼性）。
• ACIDトランザクション
• レプリケーション（マスタースレーブおよびマスターマスター）。
• ストアドプロシージャ。
• ノンブロッキングサーバースクリプト。
• 便利なバックアップ。
• 要求のフルフィルメントカーソル、範囲、およびフルスキャン。
• 一次および二次インデックス。
• テーブル。

繰り返しますが、キャッシュにはこれらのプロパティはありませんが、Tarantoolには存在します。



最新のデータベースの中には、高い信頼性を目的とするものもあれば、作業速度を重視するものもあります。 これらは、基本的に交差しない2つの異なる世界です。 Tarantoolは、両方の世界を1つのソリューションに統合するという非常に成功した試みです。







Tarantoolの欠点は次のとおりです。

• 彼にはまだ大きなコミュニティはありません。 テクノロジーを適用する前に、誰もが常に考えます。 誰に尋ねますか？」 Tarantool開発者は、FacebookやStack Overflowなど、あらゆる場所で質問に答えようとします。 しかし、多数のユーザーの観点からは、コミュニティの数が少ないために回答が得られないリスクがあります。
• 一貫したシャーディングはありません。 私たちは現在、トランザクションのサポートにより、すでに通常の状態であるようにこれに取り組んでいます。
• 独自のプロトコル。

タランツールの使用例

すべての例は、Mail.Ru Groupプロジェクトの経験から取られています。 実際、それらは多数ありますが、認証システム、プッシュ通知システム、広告表示システムの3つだけを検討します。 通常、それらは最高の負荷です。

認証システム

一見矛盾する要件がいくつかあるはずです。

• 最も高い需要 ：Webサイトまたはモバイルアプリケーションでヒットするたびに認証を確認する必要があります。 ユーザーを単に入れることはできないため、パスワード、Cookie、トークンなどを確認する必要があります。 ポータルMail.Ruおよびモバイルアプリケーションでは、認証システムへの要求の数は1秒あたり数百万と推定されます。
• レイテンシー -データベースからのリクエストとレスポンスの間の時間。 できるだけ小さくする必要があります。そうしないと、認証を使用するWebサーバーなど、すべてが遅くなります。 データベースからの応答を待機している間、スレッドまたはプロセスが必要になり、データがメモリでハングし、これもサーバーリソースを消費します。 つまり、認証システムが遅いと多くの問題が発生する可能性があるため、すぐに機能するはずです。
• 高可用性 。 認証システムが1％のケースで機能しない場合、サイト全体が1％のケースで機能しません。
• リポジトリーへの常時アクセス 。 認証システムでの各ヒットは、セッション、パスワード、トークンの検証です。
• ブルートフォース攻撃および詐欺に対する保護 。 彼らは常に認証システムを破壊しようとしています。
• ほとんどすべての呼び出しは、トランザクションに関連付けられています。つまり、一部のデータを変更する必要があります。 たとえば、認証を実行する場合、入力されたデータを確認し、認証の場所と時刻、および総当たり攻撃保護システムのその他のパラメーターを更新する必要があります。 これはすべて、データベース内の直接トランザクションです。 このエントリは失わないでください。
• 多くの避けられない余分な仕事 。 誰もがシステムを破壊しようとしているとき、舞台裏では、ユーザーではなくハッキングツールによって生成される多くの呼び出しがあります。 これらの呼び出しは、有用なトラフィックや利益をもたらしません。 これは余分な負荷です。 しかし、それらは処理および検証する必要があります。
• ビッグデータサイズ 。 当然、ユーザーベース全体を認証システムに保存する必要があります。
• ユーザーが入力したデータの有効期間（有効期限） 。 セキュリティ上の理由から、ユーザーがしばらくアクティブでない場合、セッションは終了します。 これを行うには、セッションの開始時間とアクティビティの存在を確認する必要があります。
• データストレージの信頼性（永続性） 。 明らかに、認証システムが資格情報の損失の結果として一部のユーザーを「忘れる」場合、これは評判に対する直接的な損害です。

一般に、このプロパティのセットは矛盾しているように見える場合があります。 それらの一部は通常キャッシュによって実装され、一部はデータベースによって実装されます。 認証システムは、トラックのような信頼性と耐久性を備えている必要がありますが、同時にスポーツカーと同じくらい高速でなければなりません。 ここでタランツールが役に立ちました。



ログインとパスワードによるMail.Ru認証システムの操作スキーム：







Mail.Ruでログインとパスワードをチェックする場合のみ、1秒あたり5万件のトランザクションが実行されます。 ブルートフォース保護および認証システムは、毎回Tarantoolを読み書きします。 この合計負荷は、ポータル全体、すべてのモバイルアプリケーション、すべてのAjaxおよび非Ajaxリクエストから、毎秒約100万のリクエストに達します。







このセッションでは、4つのサーバーとユーザープロファイル（8つのサーバー）のみを提供します。 ブランドの特別なサーバーではなく、通常のプロセッサーを搭載した最も一般的なサーバーです。 宇宙的なものは何もありません。

プッシュ通知システム

ご存知のように、モバイルアプリケーションは、ユーザーにプッシュ通知を送信して、ユーザーがより長く滞在することを好みます。 つまり、それはとても良いことであり、ありがたいことです。



Mail.Ruの通知システムはどのように配置されていますか？







サーバーでイベントが発生すると-手紙が届き、メッセージがメッセンジャーに送信され、ニュースが表示されます-エンドユーザーの携帯電話に通知を送信する必要があります。 これを直接行うことはできません。 そのため、AppleとGoogleはiOSとAndroid用のAPIを提供しており、これらを使用してモバイルアプリケーションをプルできます。



ただし、サーバーからこれらのAPIに直接アクセスすることはできません。 なぜ-その詳細については以下。 さらに、イベントが生成されるたびに、ストアにアクセスして、このイベントを配信するユーザーを把握する必要があります。 APIはトークンで機能するため、トークンを読むことを忘れないでください。 そして、これはすべて非常に迅速に行わなければなりません。



また、イベントは多数の異なるコンテキストおよびサーバー環境から生成されるため、非常に低いレイテンシを維持することも非常に重要です。 サーバーの速度を落とすことはできません。1、2秒待つ必要があります。そうしないと、チェーン内の他のすべてのプロセス参加者がゆっくりと動作を開始します。 このため、サーバーから直接ではなく、Tarantoolで実行されるキューを介してAPIにアクセスします。 このDBMSは、永続サービスと複製サービスの両方のキューサービスも提供できます。 つまり、マシンがクラッシュしたとき、ドライブがクラッシュしたとき、サーバーが再起動したとき、誰も何も気づきません。



サーバーは高速ストレージでのみ直接動作し、低速なものはすべてキューの背後にあることがわかります。 このスキームにより、すべてを迅速に処理できます。このシステムのリクエストの総数は、1秒あたり約20万です。

広告配信システム

これはおそらくTarantoolの最も負荷の高い使用例であり、Mail.Ru Groupが所有する最大のファームです。 システムは、巨大なポータルのほぼすべてのページに広告を表示する役割を担っており、通常、ページ上の広告ユニットは少なくとも10個あります。



各広告ユニットを表示するには、一般にユーザーに表示する必要があるものを理解する必要があります。 このため、彼に関するデータはいくつかの異なるソースから収集されます。 これらはすべて集約され、結果が形成されます。 これはすべてブロックごとに行われ、1ミリ秒未満をブロックに費やす必要があります。 この要件はどこから来たのですか？ ユーザーは広告が原因でサービスの速度が低下することを望まないため、誰もが迷惑をかけますが、それは必要な悪です。







広告表示システムの負荷は、1秒あたり約300万リクエストです。 さらに、広告の表示は多くの場合、ユーザープロファイルの更新につながるため、それらの100万は変更です。

簡単な結論

データベースとキャッシュのプロパティ（信頼性と速度）を組み合わせる必要があり、通常行う単純な方法でこれを達成できない場合は、Tarantoolをご覧ください。 おそらく、彼はこの問題を解決するでしょう。