インメモリデータベース：アプリケーション、スケーリング、重要な追加

私たちは、会議の形式を実験し続けています。 最近、ボクシングリングで、集中データバスとService Meshに衝突しました 。 今回は、より穏やかなもの、つまりスタンドアップ、つまりオープンマイクを試すことにしました。 トピックはメモリ内データベースに選択されました。



どのような場合にインメモリに切り替える必要がありますか？ スケーリングの方法と理由 そして、何に注意を払う価値がありますか？ 答えはスピーカーのスピーチにあります。これについてはこの投稿で説明します。

しかし、最初に、スピーカーを想像してください：

• Andrey Trushkin、Promsvyazbankの技術革新および先端技術センター長
  
• Vladislav Shpileva、Tarantool開発者
  
• GridGainソリューションアーキテクト、Artyom Shitov
  

インメモリに切り替える

金融市場の現在の傾向は、一般にプロセス自動化の応答時間と操作により厳しい要件を課しています。 さらに、今日ではほとんどすべての主要な金融機関が独自のエコシステムを構築しようとしています。

この点で、インメモリソリューションの2つの主要なアプリケーションがあります。 1つ目は、統合データのキャッシュです。 古典的なシナリオによると、大企業には、ユーザーの要求に応じてデータを提供する自動化されたシステムがいくつかあります。 または外部システム-ただし、この場合、ほとんどの場合、イニシエーターはユーザーです。 従来、これらのシステムはデータベースに特定の方法で構造化されたデータを保存し、オンデマンドでアクセスしていました。

今日、このようなシステムは、負荷の観点から要件を満たしていません。 ここでは、コンシューマシステムによるこれらのシステムのリモート呼び出しを忘れてはなりません。 これは、ユーザー、自動化されたシステム、または個々のサービスに対して、データの保存と表示のアプローチを検討する必要があることを意味します。 論理出力-インメモリレイヤーレベルでサービスが使用する関連データのストレージ。 市場には多くの同様の成功事例があります。

これが最初のケースでした。 2つ目は、ビジネスプロセス管理の技術的な観点から効果的です。 従来のBPMシステムは、事前定義されたアルゴリズムに従って特定の操作の実行を自動化します。 そして多くの場合、疑問が生じます。なぜこれらのシステムは十分に効率的でなく、十分に高速ではないのですか？

通常、このようなシステムは、各ステップ（またはビジネストランザクションとして設計された小さなステップセット）をデータベースに書き込みます。 したがって、これらは応答時間とこれらのシステムとの相互作用に関係しています。 現在、リアルタイムで同時に実行されているビジネスプロセスインスタンスの数は、10年以上前の規模です。 そのため、最新のビジネスプロセス管理システムでは、パフォーマンスが大幅に向上し、分散アプリケーションの実行が保証されます。 さらに、今日、すべての企業は大規模なマイクロサービス環境の形成に向かっています。 課題は、ビジネスプロセスの異なるインスタンスが運用データを共有し、効率的に使用できることです。 オーケストレーションのフレームワーク内で、それらをインメモリソリューションに保存することは理にかなっています。

和解の問題

膨大な数のノードとサービスがあり、多数のビジネスプロセスが実行され、そのアクションがマイクロサービスの形で実装されているとします。 パフォーマンスを向上させるために、それぞれがローカルメモリインスタンスへの状態の書き込みを開始します。 多数のローカルインスタンスを取得します。 すべての関連性と一貫性を確保する方法は？

ゾーニングのインメモリ領域を使用します。 たとえば、ビジネスドメインに応じて。 ビジネスドメインをカットするとき、特定のマイクロサービス/ビジネスプロセスは、対応するドメインを担当するゾーンのフレームワーク内でのみ機能すると判断します。 この方法により、キャッシュの更新とインメモリソリューション全体を高速化できます。

同時に、ドメインを担当するキャッシュは完全なレプリケーションモードで動作します。ドメイン間の分散によりノード数が制限されるため、このモードでのソリューションの速度と正確さが保証されます。 ゾーニングと最大の断片化は、同期、クラスター操作などの問題の解決に役立ちます。 ノードの総数が多い場合。

当然、インメモリソリューションの信頼性について疑問が生じることがよくあります。 はい、すべてをそこに置くことはできません。 信頼性を確保するために、インメモリの隣に常にデータベースがあります。 たとえば、多数のノードでは困難になる可能性のあるレポートをまとめる重要な問題の場合。 それで、今日のビジョンは何ですか ： 2つのアプローチの相乗効果です 。

また、これら2つのアプローチは、対比するだけでは完全に正しいわけではないことにも注意してください。 そして同時に、それらに焦点を合わせます。 Kubernetesなどの高度なコンテナー化仮想化システムのメーカーと貢献者は、すでに長期的に信頼できるストレージのオプションを提供しています。 ソリューションを実装するための優れた産業事例がすでに登場しており、ストレージはこのような仮想化形式で実行されます。

米国最大の新聞の1つは、19世紀にこの新聞の発行が開始されてから発行された問題を、読者がオンラインで受け取る機会を提供しています。 負荷のレベルを想像できます。 ストレージは、Apache Kafkaプラットフォームを通じて実装され、Kubernetesに展開されます。 情報を保存し、多数の顧客に大きな負荷がかかったときに情報へのアクセスを提供する別のオプションを次に示します。 新しいソリューションを設計するとき、このオプションも注意する価値があります。

Tarantoolを使用したインメモリデータベースのスケーリング

サーバーがあるとします。 要求を受け入れ、データを保存します。 突然、リクエストとデータが増え、サーバーは負荷に対処しなくなります。 より多くのハードウェアをサーバーにアップロードでき、より多くの要求を受け入れます。 しかし、これは一度に3つの理由で行き止まりになります。高コスト、限られた技術的能力、耐障害性の問題です。 代わりに、水平スケーリングがあります。「友人」がサーバーに来て、タスクの実行を支援します。 水平スケーリングの2つの主なタイプは、レプリケーションとシャーディングです。

レプリケーションとは、多数のサーバーがあり、それらすべてが同じデータを保存し、クライアント要求がこれらすべてのサーバーに分散している場合です。 これは、データではなくコンピューティングのスケーリング方法です。 これは、データが1つのノードに配置されている場合に機能しますが、1つのサーバーが処理できないほど多くのクライアント要求があるためです。 また、フォールトトレランスが大幅に強化されています。

シャーディングは、データをスケーリングするために使用されます。多くのサーバーが作成され、異なるデータを保存します。 したがって、計算とデータの両方をスケーリングします。 ただし、この場合のフォールトトレランスは低くなります。 1つのサーバーに障害が発生すると、データの一部が失われます。

3番目のアプローチがあります-それらを組み合わせる。 クラスターをサブクラスターに分割し、それらをレプリカセットと呼びます。 それぞれが同じデータを保存し、データはレプリカセット間で交差しません。 その結果、データのスケーリング、コンピューティング、およびフォールトトレランスが実現します。

複製

レプリケーションには、非同期と同期の2つのタイプがあります。 非同期とは、データがレプリカに分散するまでクライアント要求が待機しない場合です。1つのレプリカに書き込むだけで十分です。 データがディスク、ログに到達するとすぐに、トランザクションは成功し、いつかバックグラウンドでこのデータが複製されます。 同期-トランザクションが準備とコミットの2つのフェーズに分かれている場合。 コミットは、データが一定数のレプリカに複製されるまで成功を返しません。

ネットワーク上に何も置かれていないため、非同期レプリケーションは明らかに高速です。 データはバックグラウンドでネットワークに送信され、ログに記録されているトランザクション自体が完了します。 ただし、問題があります。レプリカが互いに遅れて、同期がとれていない可能性があります。
同期レプリケーションはより信頼性が高くなりますが、実装がはるかに遅くなります。 複雑なプロトコルがあります。 Tarantoolでは、タスクに応じて、これらの種類のレプリケーションを選択できます。



レプリカの遅れは、非同期化だけでなく、マスターの無知の問題も引き起こします。マスターに変更をレプリカに渡す方法がわかりません。 通常、変更は段階的に適用されます。変更は適用され、同じ形式でレプリカに移動します。 しかし、レプリカが利用できない場合はどうしますか？ たとえば、すべてをTarantoolで構成でき、ウィザードは非常に柔軟になります。

別の課題：トポロジを複雑にする方法？ たとえば、Mail.ruには、数百のTarantoolがあるトポロジがあります。 バックアップ用のレプリカタランチュラが円で結ばれたtarantoolカーネルがあります。 Tarantoolでは、完全に任意のトポロジを作成でき、これを使用した複製は完全に機能します。

シャーディング

次に、データのスケーリングであるシャーディングに移りましょう。 範囲とハッシュの2種類があります。 範囲分割は、すべてのデータが分割キーによってソートされ、この大きなシーケンスが範囲に分割され、各範囲がほぼ同じ量のデータを持つようにする場合です。 また、各範囲はすべて1つの物理ノードに完全に保存されます。 ただし、通常、このようなシャーディングは必要ありません。 さらに、それは常に非常に複雑です。

ハッシュによるシャーディングもあります。 タランツールで紹介されたばかりです。 実装、使用がはるかに簡単で、シャーディング範囲の代わりにほぼ常に適切です。 これは次のように機能します。レコードからハッシュ関数を検討し、保存する物理ノードの番号を返します。 問題があります。まず、複雑なクエリをすばやく完了することが困難です。



第二に、リシャーディングの問題があります。 キーを保存する必要がある物理シャードの番号を返すシャード関数があります。 また、ノードの数が変わると、シャード関数も変わります。 これは、クラスター内のすべてのデータについて、再計算して再度検証する必要があることを意味します。 さらに、従来のシャーディングでは、一部のデータは新しいノードに転送されず、単に古いノード間でシャッフルされます。 古典的なシャーディングでは、無駄な転送をゼロに減らすことはできません。



Tarantoolは仮想シャーディングを使用します。データは物理ノードではなく、仮想ノードに分散されます。 仮想クラスター内の仮想バケット。 そして、仮想のストーリーは物理的なストーリーに基づいています。 そしてすでに、各仮想階が完全に1つの物理階にあることが保証されています。

これは再販の問題をどのように解決しますか？ 実際、バケットの数は固定されており、物理ノードの数を大幅に超えています。 したがって、クラスターをどれだけ物理的にスケーリングしても、データを保存して均等に分散するには、バケットで常に十分です。 また、シャード関数は変更されていないため、クラスターの構成が変更されたときにシャード関数を再計算する必要はありません。

その結果、 範囲、ハッシュ、仮想バケットの3種類のシャーディングを取得します 。 範囲とバケットの場合、物理的な検索の問題があります。

解決方法は？ 最初の方法：リシャーディングを禁止します。 次に、リシャーディングのために、新しいクラスターを作成し、そこにすべてを転送する必要があります。 2番目の方法：常にすべてのノードに移動します。 しかし、これは意味がありません。なぜなら、スケーリングする必要があり、計算はそのようにスケーリングしないからです。 3番目のオプション：バケットの一種のルーターとして機能するプロキシモジュール。 それを実行し、そこにバケットの番号を示すリクエストを送信すると、リクエストをプロキシとして目的の物理ノードに送信します。

GridGainプラットフォームを使用した高度なインメモリの例

ビジネスには追加のデータベース要件があります。 彼はこれらすべてをフォールトトレラントで破滅的なものにしたいと考えています。 彼は高可用性を望んでいます。そのため、何も失われず、すぐに回復できます。 また、簡単で安価な拡張性、簡単なサポート、プラットフォームへの信頼、効率的なアクセスメカニズムも必要です。

これらのアイデアはすべて新しいものではありません。 これらの多くは、ある程度まで、古典的なDBMS、特にデータセンター間のレプリケーションに実装されています。

In-Memoryはもはやスタートアップテクノロジーではなく、世界中の大企業（バークレイズ、シティグループ、マイクロソフトなど）で使用されている成熟した製品です。 これらの要件はすべて満たされていると想定されています。

そのため、突然大災害が発生した場合、バックアップから回復する機会があるはずです。 金融組織について話している場合、すべてのドライブからのコピーだけでなく、このバックアップが一貫していることが重要です。 ノードの一部でXの時点でデータが復元され、Yの時点で他の部分でデータが復元されないようにするために、ポイントインタイムリカバリを行うことが非常に重要です。これにより、データの破損や特に重大な事故が発生した場合でも、損失の量を最小限に抑えることができます。

データをディスクにプッシュできることが重要です。 そのため、クラスターが過負荷に陥ることなく、さらに低速で動作し続けます。 そして、ディスクから素早く立ち上がり、それからデータをメモリに送り込みました。


GridGainフォールトトレランスコンポーネントの有無にかかわらず、クラッシュに対するメモリ内の応答

フェールオーバークラスターは、水平および垂直に簡単に拡張できる必要があります。 サーバーにお金を払って、リソースの半分がアイドル状態になっているのを見ている気がしません。 管理する必要がある何百ものプロセスの中から地獄に行きたくありません。 サポートの観点から、クラスターからのノードの簡単な入出力と開発された成熟した監視システムを備えたシンプルなシステムが欲しいです。

この観点でMongoDBを検討してください。 MongoDBで作業したことのある人は誰でも、多数のプロセスを知っています。 5つのシャードの影付きMongoDBがある場合、各シャードには3つのプロセスのレプリカセットがあります（冗長性比は3）。 そして、これはデータ自体でのみ15プロセスです。 クラスター構成ストレージはもう1つプラス3プロセスで、合計で18になります。これにはルーターは含まれません。 20個のシャードが必要な場合は、63個以上（たとえば、8個、合計71個）のプロセスから地獄へようこそ。



Cassandraと比較してください。 すべて同じ5つのシャードを使用します。これらは5つのプロセスと5つのノードであり、同じ冗長係数3を持ちます。これは制御の観点からはるかに単純です。 20個のシャードが必要です-これらは20個のプロセスです。 クラスターを任意の数のノードにスケーリングできますが、必ずしも3の倍数（または冗長係数の別の値）にする必要はありません。 レプリカセットよりも実装と保守がはるかに簡単で安価です。



さらに、システムを信頼し、各製品の背後にある人々を理解する必要があります。 理想的には、ライセンスはオープンソースまたはオープンコアでなければなりません。 ベンダーが死亡した場合、何かができるように。 また、ソースコードが独立したコミュニティによって管理されている場合も有効です。MongoDBとRedisが管理会社の要求に応じてライセンスを変更した方法をすべて覚えています。 Aerospikeが年初に「オープンソース」コミュニティエディションに制限を導入した方法。

データへの効果的なアクセスが必要です。 ほとんどすべてが、何らかの形で構造化照会言語を持っています。 ほとんどの場合、SQLを使用しますが、この言語での適応はできるだけ簡単にする必要があります。 これは、各ノードに個別にリクエストを送信する必要はありませんが、「シングルウィンドウ」のようにクラスターと通信できる場合に、分散クエリの実行に役立ちます。 APIの観点から考えると、これは一連のノード（複雑なSQLクエリが発生する可能性がなく、最も単純なput / getレベルでも大容量でMemcacheを使用するのがいかに難しいかを思い出してください）、分散DDLおよびACIDの保証です。

そして最後に、サポート。 何かが突然機能しない場合、会社は単にお金を失います。 一部の分野ではこれは重要ではありませんが、多くの場合、誰かが製品とその作業に責任を持つことが重要です。 そのため、いつでも申し立てを行うことができ、すぐに解決されました。

この投稿で、HamsのPromsvyazbankの年が完了しました。 ハブロフスクの住民に対する新年の願いを短いビデオで集めました。