Web サービスのインメモリ アーキテクチャ: テクノロジの基礎と原則

インメモリは、データがアプリケーションの RAM に保存され、ディスクがバックアップに使用されるときに、データを保存するための一連の概念です。 従来のアプローチでは、データはディスクに保存され、メモリはキャッシュに保存されます。 たとえば、データを処理するバックエンドを備えた Web アプリケーションは、データをストレージにリクエストします。データを受信して​​変換し、大量のデータがネットワーク経由で転送されます。 インメモリでは、計算はデータ、つまりストレージに送信され、そこで処理され、ネットワークの負荷が軽減されます。

そのアーキテクチャのおかげで、In-Memory はデータ アクセスを数倍、場合によっては桁違いに高速化します。 たとえば、銀行アナリストは、分析アプリケーションで、過去 XNUMX 年間の発行済みローンの日ごとの動態レポートを確認したいと考えています。 従来の DBMS ではこのプロセスに数分かかりますが、インメモリではほぼ即座に表示されます。 これは、このアプローチにより、より多くの情報をキャッシュできるようになり、情報が「手元」の RAM に保存されるためです。 アプリケーションはハード ドライブからデータを要求する必要はありませんが、ハード ドライブの可用性はネットワークとディスク速度によって制限されます。

In-Memory には他にどのような可能性がありますか?また、これはどのようなアプローチですか? ウラジミール・プリギン - GridGain のエンジニア。 このレビュー資料は、In-Memory を使用したことがないが試してみたいと考えている Web アプリケーション バックエンド開発者、またはソフトウェア開発とアーキテクチャ設計の最新のトレンドに興味がある Web アプリケーション バックエンド開発者に役立ちます。

注意。 この記事は、#GetIT Conf でのウラジミールのレポートの書き起こしに基づいています。 自主隔離が導入される前、私たちはモスクワとサンクトペテルブルクで開発者向けのミートアップやカンファレンスを定期的に開催し、トレンド、現在の開発上の問題、問題とその解決策について話し合いました。 今はカンファレンスを開催することはできませんが、過去のカンファレンスからの有益な資料を共有する時が来ました。

In-Memory を誰がどのように使用するか

インメモリは、高速なユーザー操作や大量のデータの処理が必要な場合に最もよく使用されます。

• 銀行 たとえば、クライアントがアプリケーションを使用する際の遅延を軽減したり、ローンを発行する前にクライアントを分析したりするために、インメモリを使用します。
• フィンテック は、In-Memory を使用して、データ処理と分析をアウトソーシングする銀行向けのサービスとアプリケーションのパフォーマンスを向上させます。 
• 保険会社: 数年間にわたる顧客データを分析するなどして、リスクを計算します。
• 物流会社。 たとえば、数千のパラメータを使用して貨物と旅客の輸送に最適なルートを計算したり、出荷状況を追跡したりするために、大量のデータを処理します。
• 小売り。 インメモリ ソリューションは、顧客への対応を迅速化し、出荷、請求書、取引、倉庫内の数千の商品の存在、分析レポートの作成などの大量の情報を処理するのに役立ちます。
• В IoT インメモリは従来のデータベースを置き換えます。
• 医薬品 企業は、たとえば、医薬品組成の組み合わせを分類するためにインメモリを使用します。 

当社のクライアントがインメモリ ソリューションをどのように使用しているか、またお客様自身でインメモリ ソリューションを実装する方法について、いくつかの例を説明します。

プライマリストレージとしてのインメモリ

当社のクライアントの XNUMX つは、米国の医療科学機器の大手サプライヤーです。 彼らは、メインのデータ ストレージとしてインメモリ ソリューションを使用しています。 すべてのデータはディスクに保存され、アクティブに使用されるデータのサブセットは RAM に保持されます。 ストレージ アクセス方法は標準で、GDBC (汎用データベース コネクタ) と SQL クエリ言語です。

これを総称して、インメモリ データベース (IMDB) またはメモリセントリック ストレージと呼びます。 このクラスのソリューションには多くの名前がありますが、これらが唯一のものではありません。 

IMDBの特徴:

• インメモリに保存され、SQL を通じてアクセスされるデータは、他のアプローチと同じです。 それらは同期していますが、表現方法と対処方法が異なるだけです。 データ間でトランザクション性が機能します。

• IMDB は、ディスクからよりも RAM から情報を取得する方が速いため、リレーショナル データベースよりも高速です。 
• 内部最適化アルゴリズムの命令数は少なくなります。
• IMDB は、アプリケーション内のデータ、イベント、トランザクションの管理に適しています。

IMDB は、ACID (原子性、一貫性、分離) を部分的にサポートします。 ただし、「耐久性」はサポートされていません。電源がオフになると、すべてのデータが失われます。 この問題を解決するには、スナップショット (ハード ドライブ上のデータベース バックアップに似たデータベースの「スナップショット」) を使用するか、再起動後にデータを復元するためにトランザクション (ログ) を記録します。

フォールト トレラントなアプリケーションを作成するには

フォールト トレラントな Web アプリケーションの古典的なアーキテクチャを想像してみましょう。 これは次のように動作します。すべてのリクエストは Web バランサーによってサーバー間で分散されます。 このシステムは、サーバーが相互に複製され、インシデントが発生した場合にバックアップされるため、安定しています。

バランサーは、XNUMX つのセッションからのすべてのリクエストを XNUMX つのサーバーに厳密に送信します。 これはスティック セッション メカニズムです。各セッションはサーバーに関連付けられ、そこでローカルに保存および処理されます。 

サーバーの XNUMX つが故障するとどうなりますか?

アーキテクチャが重複しているため、サービスには影響しません。 ただし、停止したサーバーのセッションのサブセットは失われます。。 そして同時に、これらのセッションに結び付けられているユーザー。 たとえば、顧客が注文をしたのに、突然オフィスから追い出されたとします。 再度ログインし、すべてをやり直す必要があることがわかったとき、彼は不満を抱くでしょう。

Web アプリケーションは、多数のユーザーをサポートし、速度を低下させずに快適に作業できるようにする必要があります。 ただし、拒否された場合、後続のリクエストごとにセッション ストアとの通信にかかる時間が増加します。 これにより、他のユーザーの平均遅延が増加します。 しかし、彼らはこれまで以上に待ちたくないのです。

この問題は、当社の他のクライアントである米国の大手 PASS プロバイダーと同様に解決できます。 インメモリを使用して Web セッションをクラスタ化します。 これを行うために、それらはローカルではなく、中央のインメモリ クラスターに保存されます。 この場合、セッションはすでに RAM 内にあるため、より高速に利用可能になります。

サーバーがクラッシュすると、従来のアーキテクチャと同様に、バランサーはクラッシュしたサーバーから他のサーバーにリクエストを送信します。 しかし、重要な違いがあります。 セッションはインメモリクラスターに保存されます そして、サーバーは障害が発生したサーバーのセッションにアクセスできるようになります。

このアーキテクチャにより、システム全体の耐障害性が向上します。 さらに、スティックセッションメカニズムを完全に放棄することも可能です。

ハイブリッド トランザクション分析処理 (HTAP)

通常、トランザクション システムと分析システムは分離されています。 分離するとメインベースに負荷がかかります。 分析処理の場合、分析処理がトランザクション プロセスに干渉しないように、データはレプリカにコピーされます。 ただし、コピーには遅延が発生します。遅延なく複製することは不可能です。 これを同期的に行うと、メインベースの速度も低下し、勝利を得ることができなくなります。

HTAP では、すべてが異なる動作をします。アプリケーションからのトランザクション負荷と、完了までに時間がかかる分析クエリには同じデータ ストアが使用されます。 データが RAM にあると、分析クエリの実行が速くなり、データベースを備えたサーバーの負荷が (平均して) 軽減されます。

ハイブリッド アプローチは、トランザクション処理と分析の間の壁を打ち破ります。 同じストレージ上で分析を実行する場合、RAM からのデータに対して分析クエリが起動されます。 それらははるかに正確で、より解釈しやすく、適切です。

インメモリソリューションの統合

（比較的）簡単な方法 - すべてをゼロから開発する。 データはディスク上に保持され、ホットデータはメモリに保存されます。 これにより、サーバーの再起動や停止に耐えることができます。

データがディスクに保存される場合、主に XNUMX つのシナリオが機能します。 XNUMX つ目は、クラスターまたはパーツのクラッシュや定期的な再起動に耐えられるようにすることです。これを単純なデータベースとして使用したいと考えています。 XNUMX 番目のシナリオでは、データが多すぎる場合、その一部がメモリ内に存在します。

すべてを最初から構築することができない場合は、インメモリをすでに構築されているシステムに統合することが可能です。 既存のアーキテクチャ。 ただし、すべてのインメモリ ソリューションがこれに適しているわけではありません。 必須条件がXNUMXつあります。 インメモリ ソリューションは以下をサポートする必要があります。

• その下にあるデータベース (MySQL など) に接続する標準的な方法。
• ストレージとの対話ロジックを書き換えたり変更したりしないようにするための標準クエリ言語。
• トランザクション - インタラクションのセマンティクスを保持します。

XNUMX つの条件がすべて満たされていれば、統合は可能です。 インメモリ データ グリッドをアプリケーションとデータベースの間に配置します。 これで、書き込みリクエストは基になるデータベースに委任され、データがキャッシュにない場合は読み取りリクエストも基になるデータベースに委任されるようになります。

ビジネス分析など、データへの高速アクセスとその処理が重要な場合は、インメモリの実装を検討できます。 実装に関しては、新しいアーキテクチャを設計するときに両方の方法を使用できます。

出所： habr.com