ウェルズファーゴSFベイエリアテクノロジー
スケーリング .NET Core 極限のパフォーマンスを実現するアプリとマイクロサービス
.NET、Java、および Node.js の場合
イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト
今日のサーバー アプリケーションは、多くのトランザクションを非常に高速に処理する必要があります。 これらの多くは、毎日何百万ものユーザーにサービスを提供する Web アプリケーションです。 その他には、数百万のモバイル アプリやモノのインターネット (IoT) スマート デバイスにサービスを提供するマイクロサービスがあります。
これらのアプリケーションのほとんどは、デプロイメント、スケーリング、管理を簡素化および自動化するために、現在 Kubernetes などのコンテナーにデプロイされています。 そして、導入環境の選択肢は、オンプレミスから AWS、Azure、Google Cloud などの主要なクラウドに移行しています。
データ ストレージとデータベース、さらにはマイクロサービス アプリケーションのさまざまな部分間の通信に関連するパフォーマンスのボトルネックを取り除くことで、今日の極端なパフォーマンス要件を満たすアプリケーションを開発する方法を学びます。
概要
ウェルズ・ファーゴのこのような重要なグループであるサンフランシスコ・ベイエリア・テクノロジー・グループと話す機会を与えてくれたマイクとジェイソンに感謝します。 マイクが言ったように、私はで働いています Alachisoft そして、アラチという言葉は、私がマイクとジェイソンに説明していましたが、ヒンディー語のエラチ、またはスパイス名カルダモンのエライチに由来するものです。 それで、私たちは何年も前に会社に名前を付けたばかりで、何かユニークなものを考え出したかったので、次のことを思いつきました。 Alachisoft.
実は弊社の商品は、 NCache。 だから、私はそれについて話すつもりはありません NCache。 今日の話は、「Web アプリケーションとマイクロサービスを最高のパフォーマンスに拡張するにはどうすればよいですか?」についてです。 これらのアプリケーションを Java、.NET で開発している場合、 .NET Core または Node.js の場合は、正しい話に行き着きます。
スケーラビリティとは何ですか？
それでは、実際の話に入る前に、いくつかの定義を理解しましょう。 5 つ目は、スケーラビリティとは何ですか? スケーラビリティとは、実際にはピーク負荷下でのアプリケーションのパフォーマンスが高いことを指します。 したがって、アプリケーションがわずか 5000 ユーザーで超高速に実行されている場合、50,000、500,000、または XNUMX ユーザーの速度で同じ超パフォーマンスが得られない限り、実際には拡張性がありません。 あなたのアプリケーションがそれを行うことができれば、それはスケーラブルであるということになります。そして、明らかに私たちはアプリケーションの多くがスケーラブルであることを望んでおり、それについて詳しく説明します。
線形スケーラビリティとは何ですか?
次の定義は「線形スケーラビリティとは何ですか?」です。 これは、アプリケーションのアーキテクチャと展開に関する用語です。 アプリケーションが正しく設計されていれば、直線的にスケーラブルになります。つまり、XNUMX 秒あたりのトランザクション容量を増やす必要がある場合、何人のユーザーを処理できるかということになります。 どれくらいのアプリケーションリクエストを処理できますか? これを増やしたい場合は、サーバーを追加するだけで、サーバーを追加するたびに XNUMX 秒あたりのトランザクション容量が直線的に増加します。
したがって、障害やボトルネックはありません。 明らかに、読み取り曲線と書き込み曲線は異なりますが、どちらも線形です。 それができれば、アプリケーションは直線的にスケーラブルになり、これは私たちが間違いなく望んでいることです。
非線形スケーラビリティとは何ですか?
これは私たちが望まないことであり、何らかのボトルネックがあるような方法でアプリケーションを設計した場合に起こります。そのため、アプリケーションの負荷が増加し、さらにボックスを追加すると、何かが低下し始め、アプリケーションが起動します。速度が低下するため、実際にはクラッシュすることさえあります。
したがって、アプリケーションが非線形にスケーラブルになるように設計されることは絶対に望んでいません。
スケーラビリティが必要なのは誰ですか?
さて、スケーラビリティの意味を理解したところで、次に理解しなければならないのは、それを必要とするのは誰でしょうか? スケーラビリティが必要なアプリケーションはどれですか?
- Web Apps
最も一般的なアプリケーションは Web アプリケーションです。 これらは、ウェルズ・ファーゴのような銀行、またはシティ・グループ、バンク・オブ・アメリカ、バークレイズ、東京銀行など、当社と提携している他の銀行向けです。 これらは顧客向けアプリケーションであり、wellsfargo.com などは消費者向け銀行業務や中小企業向けであり、これらの Web アプリケーションは速度を落とすことなく多くのユーザーを処理できる必要があります。 したがって、これらのアプリケーションが極度の負荷の下で超高速に動作することが非常に重要です。
- Webサービス / Web API
XNUMX 番目は Web サービス、Web API アプリケーションです。 これらは通常、多くのモバイル アプリケーションや、特定のタスクを実行するためにそれらを呼び出すその他のアプリケーションにサービスを提供するために存在します。 たとえば、ウェルズ ファーゴには消費者向けバンキング用のモバイル アプリケーションがあり、そのモバイル アプリケーションはバックエンドと通信する必要があり、今日のバックエンドはおそらく Web サービスであるとします。 もちろん、それはわかりませんが、おそらくそうだろうと思います。なぜなら、私たちが取引している他の銀行の多くでは、Web サービスがこのモバイル アプリケーションのリクエストを処理している状況にあるからです。 そして、それらはまったく同じ感度を持っています。 速度を落とさずに大量の負荷を処理できる必要があります。
- Microservices
マイクロサービスは、最近非常に注目されているバズワードです。これについては後ほど詳しく説明しますが、本質的には、Web サービスをより良い新しい方法で再構築するということです。このときはそう言ってください。
- サーバーアプリ
XNUMX 番目の種類のアプリケーションは、その他のサーバー アプリです。 これらは、サーバー アプリがバッチ処理を実行している可能性があります。 これらはライブ トランザクションも処理している可能性がありますが、他のカテゴリに分類されます。 ただし、同じタイプの XNUMX 秒あたりのトランザクション スループット要件もあります。
つまり、これら XNUMX 種類のアプリケーションのいずれかを開発している場合です。 他にもいくつかあります。たとえば、ライブ機械学習や AI を行っているかもしれませんが、この講演ではそれについては触れません。時間がありません。 ただし、これら XNUMX つのアプリケーションがある場合、それらは間違いなくスケーラブルである必要があるとします。 そして、これはそれらについての話です。 テクノロジーに関する限り、Web アプリケーションは一般的に Java または ASP.NET、ASP で開発されます。.NET Coreは、ASP.NET と Node.js の新しいバージョンであり、他の XNUMX つのタイプはすべて Java または .NET/ です。.NET Core、マイクロサービスは Java または .NET Core それは新しい技術だからです。
マイクロサービスの概要
マイクロサービスがどのようなものかを知らない人のために、そのアーキテクチャの概要を簡単に説明したいと思います。 そして、そんなことをする人は、ちょっと我慢してください。 マイクロサービスがこれほど人気になっている理由は、モノリシック アプリケーションをバイト サイズのマイクロサービスに分割でき、すべてのマイクロサービスが他のマイクロサービスから分離されるためです。 そして、その切り離しとは、彼らがお互いに電話をかけないことを意味します。 通常は独自の論理データベースを持っています。 物理データベースを分離する必要はありませんが、少なくとも論理的には、通常は独自のデータベースを持っています。 一部のマイクロサービスでは、 NoSQL database、MongoDB など。 それらの中には、リレーショナル データベース、SQL Server、Oracle、DB2 を使用するものもあります。 それらの一部はレガシー メインフレーム データに移行する可能性があります。
そのため、切り離すには、ある種のイベント バスを介して相互に通信する必要があります。これが右側のパイプです。 また、モバイル アプリケーション、シングル ページ Web アプリケーション、または Java、.NET、または Node.js の標準 MVC Web アプリケーションによって、API ゲートウェイを介して呼び出されます。 つまり、これはマイクロサービスとは何かをよく理解したものです。 そして、それらのアプリケーションであっても、他のアプリケーションが従来抱えていたのと同じスケーラビリティの問題をどのように抱えているかについて説明します。
アプリ導入環境
これから説明する内容の背景を説明したかったので、すぐに基礎に触れておきたかったもう 15 つの点は、私たちが長年にわたって取り組まなければならなかったさまざまな種類の展開環境についてです。 私はこれを XNUMX 年以上行ってきましたが、最も長い間、すべてオンプレミスのデータセンターで完全に制御されていました。 私たちが取引している銀行の多くは今でも独自のデータセンターを持っています。 しかし、ほぼ全員がクラウドに移行しているか、少なくとも移行を計画しています。 一部の中小企業はパブリック クラウドに移行しています。 多くの大企業、特に金融サービスや銀行は一般的にプライベート クラウドの導入を好みます。 実際、私たちが取引している一部の銀行は、Pivotal Cloud Foundry または Red Hat Open Stack タイプのフレームワーク上のプライベート クラウドを好みます。これにより、プライベート クラウド環境を完全に制御できるようになります。プライベートクラウドは存在します。 それがリースされたスペースとしてパブリック クラウド内に存在するか、現在所有しているデータセンター上に存在するか、あるいはその他のものであるかに関係なく、自由が与えられます。 しかし、どちらにしてもクラウドに移行することになります。
また、Kubernetes についても後で触れますが、マイクロサービスと同じように、まさに別のバズワードになりつつあります。 なぜなら、これは開発運用を簡素化する非常に強力なテクノロジーだからです。 また、環境の移植性も得られます。 したがって、一度やったことはすべて、あらゆる環境で機能します。 オンプレミスであっても、クラウドのいずれであっても、同じデプロイ環境が機能します。 また、Kubernetes に関しても、私たちが取引している銀行の多くは、Tanzu Kubernetes や Red Hat OpenShift のような、よりクラウド プラットフォームに中立な製品を好んでいます。 したがって、私たちが話しているスケーラビリティのトピックの一部として、これらの概念については後ほど説明することにします。
スケーラビリティの問題
さて、それでは、先ほどお話しした実際の問題に戻りましょう。つまり、解決する必要があるスケーラビリティの問題はあるのでしょうか? はいあります。 ただし、それはアプリケーション層にはありません。 それはアプリケーションのアーキテクチャにはありません。 それはデータストレージにあり、それがボトルネックになります。 また、データ ストレージという言葉は、リレーショナル データベースやメインフレームのレガシー データベースやデータを意味します。 NoSQL databases、同じ種類のボトルネックはなく、ますます使用されています。 しかし、残念ながら、これらはこのスケーラビリティの問題全体に対する解決策にはなりません。
スケーラビリティのボトルネック
この図を見ると、リレーショナル データベースと従来のメインフレームがボトルネックになっている理由が、アプリケーション層とは異なり、サーバーを追加できるためであることがわかります。 たとえば、ここにある Web アプリがマルチサーバーの負荷分散環境にデプロイされており、Web サービスとマイクロサービスも同じように配置されているとします。
繰り返しますが、今回は環境について話しているのではなく、複数のサーバーであることの論理的な内訳を説明しているだけです。 したがって、サーバーを追加できるということは、アプリケーション層がボトルネックになることがないことを意味します。 しかし、その層のサイズが大きくなるにつれて、データ ストレージがますますボトルネックになります。 そして、たとえ NoSQL ボトルネックにはなりませんが、それがすべての問題の解決策ではない理由は次のとおりです。 NoSQL データをリレーショナルやメインフレームから移動する必要があります。 理想的な世界では、これは大したことではないはずですが、これは非常に大きな問題です。 ほとんどの企業はリレーショナルから完全に離れることはできません。 メインフレームから完全に離れることはできません。 彼らは使用できます NoSQL いくつかのデータを組み合わせて入れることができるため、 NoSQL database しかし、多くのデータは引き続きリレーショナル データベースとメインフレームに存在し続ける必要があります。 そして、それが真実である限り、それが意味するのは、私たちが考え出さなければならないスケーラビリティ ソリューションはどれも、 NoSQL database。 それは何か他のものでなければなりません NoSQL database。 リレーショナル データベースおよび従来のメインフレーム データベースと連携する必要があります。
マイクロサービスのボトルネック
マイクロサービスは、アーキテクチャを示したように、スケーラビリティが組み込まれているわけではありません。 これらにも、Web サービスや Web アプリケーションと同じパフォーマンスのボトルネックがあります。 を使用していない限り、 NoSQL databaseもちろん、そんなことはありませんが、レガシー データについてはメインフレームと通信する必要があり、その多くは引き続きリレーショナル データベースと通信することになります。 さらに、相互に通信するために存在するイベント バスという追加の潜在的なボトルネックもあります。
トランザクションが非常に多い環境の場合、イベント バスがボトルネックになる可能性もあります。 イベント バスに適切なソリューションを導入していない場合。
スケーラビリティ ソリューション
したがって、幸いなことに、これに対する解決策があり、それがメモリ内分散キャッシュです。 そして、その理由を説明します。 ただし、いくつか主張させてください。 これが解決策である理由は、非常に高速だからです。 線形のスケーラビリティと高可用性を実現します。 以上が、これがスケーラビリティ問題の解決策となる XNUMX つの理由です。 また、インメモリ分散キャッシュを使用することで得られる追加の利点もあります。ウェルズ ファーゴのような大企業では、実際に複数のアプリケーションにわたるデータ共有プラットフォームとして使用できます。 これについてはもう少し詳しく説明しますが、これは一種の付加的な利点、またはこれを使用することによる副次的な利点のようなものです。 主な理由はスケーラビリティです。
インメモリ分散キャッシュ
では、インメモリ分散キャッシュはどのようにしてこの答えを提供するのでしょうか? その問題はどのように解決されるのでしょうか？ これが解決策である理由は、インメモリ分散キャッシュはまずメモリ内にあるため、超高速であるためです。 インメモリは偶数よりも高速です NoSQL databases. そして、4番目に配布されます。 インメモリ分散キャッシュは、実際には複数の低コスト キャッシュ サーバーの集合です。 また、各キャッシュ サーバーはデータベース タイプのサーバーではありません。 これらは Web サーバーに似ており、8 ～ 16 コア、場合によってはそれ以上のコアです。 32 ～ XNUMX GB の RAM。 アプリケーションごとに必要なだけそれらを取得し、アプリケーション用の超高速で拡張性の高いインフラストラクチャとして作成します。 Web アプリ、Web サービス、マイクロ サービス、データベースを含むアプリケーション層を作成したら、これらはリレーショナルかどうかに関係なく、レガシーまたはレガシーになります。 NoSQL。 偶数 NoSQL前述したように、メモリ内の分散キャッシュほど高速ではありません。
では、メモリ内分散キャッシュはどのような役割を果たしているのでしょうか? これらのキャッシュ サーバーのクラスターを作成し、そのクラスターがこれらすべてのキャッシュ サーバーのメモリ、CPU、さらにはネットワーク カードの容量をプールします。 アプリケーション層と同様に、 NoSQL database、より簡単ではありますが、 NoSQL database、トランザクション容量が増加するにつれて、キャッシュ サーバーを追加し続けるだけです。 したがって、突然冗長性があり、その上に、メモリ内にあるため、スマートな方法でデータ レプリケーションを提供する必要があります。これについては、後で少し説明して、キャッシュ サーバーが XNUMX つでも存在するかどうかを確認します。ダウンしてもデータは失われません。 そうしないと、メモリ内ストアに価値がないからです。 XNUMX 台のサーバーがダウンしただけで何ギガバイトものデータが失われるのであれば、それはあまり魅力的なソリューションとは言えません。そのため、インメモリ分散キャッシュはデータを分散するだけでなく、パフォーマンスを損なうことなくスマートな方法でデータを複製します。そしてスケーラビリティ。
したがって、インフラストラクチャの一部としてインメモリ分散キャッシュを導入することで、突然そのボトルネックを解消できるようになり、データ読み取りの 80% が分散キャッシュに送られるようになります。 データベースは依然としてマスター データ ソースであるため、20% は実際のデータベースに使用されます。 したがって、そのデータを更新する場合は、レガシー メインフレームのリレーショナル データベースに対して行う必要があります。 NoSQL。 ただし、読み取りまたは書き込みトラフィックの 80%、90% 以上が分散キャッシュに制限される場合もあります。 そして、突然アプリケーションにボトルネックが感じられなくなります。
したがって、これは、現在では必須のアプリケーション アーキテクチャ パターンのようなもので、アプリケーションを拡張できるようにするには、メモリ内に分散キャッシュが必要になります。
分散キャッシュのスケーラビリティ
これらはいくつかの スケーラビリティベンチマークの数値 NCacheわずか 4 ～ 5 個のノードで 2 秒あたり 4 万回の操作を実行できることがわかります。 また、これは線形スケールであるため、5 万に達したい場合は、さらに 2 つのノードを追加するだけです。 そして、ご存知のとおり、90 秒あたり XNUMX 万操作というトランザクション負荷はかなり高く、ほとんどのアプリケーションがその負荷に耐えることができれば、アプリケーションの XNUMX% はその種類の負荷内で問題なく動作することになります。 おそらくそうでない人もいるでしょうし、もっと必要な人もいます。 さらに必要な場合は、サーバーを追加するだけです。
分散キャッシュの一般的な使用法
アプリケーション アーキテクチャに関しては、インメモリ分散キャッシュが素晴らしいアイデアであることを、ここまででご理解いただけたと思います。 それで、その次に頭に浮かぶ最初の疑問は、アプリケーション開発者としてそれをどのように活用するかということです。 なぜなら、これらはすべてアプリケーションに関するものだからです。 分散キャッシュを活用するにはどうすればよいですか?
- アプリのデータキャッシュ
したがって、分散キャッシュを使用できる一般的な方法は XNUMX つあります。 XNUMX番は アプリのデータキャッシュ。 これは私が今話した最も一般的な方法です。 つまり、データベースから読み取るデータが何であれ、それをキャッシュに保持するので、次回はキャッシュから読み取るだけで済みます。非常に簡単です。 そして、何を更新しても、キャッシュとデータベースの両方が更新されます。
ここで、すぐに理解する必要があるのは、アプリケーション データのキャッシュには特有の問題が存在するということです。それは、データが XNUMX つの場所に存在し、XNUMX つはマスター データベース (リレーショナル データベースである可能性があります) であることです。 NoSQL またはレガシー メインフレームで、10 つはキャッシュです。 したがって、最初に問題が発生する可能性があるのは、キャッシュが古くなることです。 データを更新すると、キャッシュと通信していないアプリケーションがあり、データベース内のデータを更新します。すると、突然キャッシュに古いデータが入ります。古いデータは非常に悪いものです。 皆さんもご存知かと思いますが、古いデータが非常に悪いということは銀行が誰よりも知っています。 一部の古いデータは問題ありませんが、多くの古いデータは非常に悪いです。 これが、キャッシュについて考えるとき、ほとんどの人が「わかった、読み取り専用データのみをキャッシュするつもりだ、決して変更されない、または少なくともアプリケーションの存続期間中などは変更されない」という反射的な反応をする理由です。 、非常に長い間、それは変わらないでしょう。 そうですね、それがデータ全体の 15% か 10% にすぎない場合。 15%、5% しかキャッシュしない場合は、分散キャッシュを実際には活用していません。 おそらく 5 秒ごとに変化するデータをキャッシュできる必要があります。 あるいは、それよりも早く。 なぜなら、その10～10秒でもXNUMX回は読めるかもしれないからです。 そして、これにアプリケーションが毎日処理する何百万ものトランザクションを掛けると、データベースへのアクセス回数が節約され、スケーラビリティが得られることになります。
したがって、この課題に対処しない分散キャッシュは、キャッシュが古くなってはならず、常に最新である必要があるため、完全には使用できなくなります。 したがって、それが最初に心に留めておくべきことです。
- Web アプリ固有のキャッシュ
XNUMX 番目のユースケースは Web アプリケーションです。 そして、Web アプリケーションの最も一般的な用途は次のとおりです。 セッション。 Java、ASP.NET、ASP を使用しているかどうか.NET Core Node.js など、すべてのユーザーはセッションを高速でスケーラブルなストアに保存したいと考えています。 そして、分散キャッシュは、他のキャッシュよりもはるかに優れたストアです。 それが Java であろうと .NET であろうと、Node.js であろうと。 他にもこんなページがあります 出力キャッシュ。 ライブ Web アプリケーションもあります。 .NET の場合、これは呼び出されます SignalR、イベントを共有するためのプラットフォームとして分散キャッシュを使用できます。
ただし、Web アプリケーションがアプリ データのキャッシュ以外の場合、Web アプリケーションがそのデータを分散キャッシュに保存している場合は、別の種類の問題に取り組む必要があります。 つまり、現在、そのデータのコピーを保持するデータベースは存在しません。 キャッシュはマスター ストアです。 また、キャッシュがマスター ストアであるということは、キャッシュ サーバーがダウンすると、そのデータが失われることを意味します。 これは受け入れられません。キャッシュ サーバーや Web サーバーがダウンしたからといってユーザー セッションが失われることは望ましくありません。 高可用性を実現したい場合は、そのデータを複数のサーバーにインテリジェントに複製する機能をキャッシュに持たせる必要があります。 そのため、キャッシュ サーバーがダウンしても、そのデータは失われません。 それが重要な部分です。 アプリデータのキャッシュには別の課題があります。 Web アプリケーション固有のキャッシュには別の課題があります。
- パブ/サブメッセージング、CQ、イベント
そして XNUMX 番目の使用例は、これは多くの人がまったく知らないことですが、分散キャッシュを Pub / Subメッセージング プラットフォームとイベント。 私たちは話し合ったので、マイクロサービスであっても Pub/Sub を行う必要があることを説明します。 したがって、分散キャッシュをアプリケーション データ キャッシュに使用するだけでなく、Pub/Sub メッセージング プラットフォームとしても使用すれば、Pub/Sub メッセージングがボトルネックになることはありません。
多くのメッセージング機能を備えたメッセージング製品は他にもたくさんあります。 分散キャッシュはこれらの機能のすべてに適合するわけではありませんが、分散キャッシュが行うことは、マイクロサービスまたは Web アプリケーション環境内で共有する必要があるメッセージ用の非常に高速なメモリ内メッセージング プラットフォームを作成することです。 したがって、これらのメッセージを何時間も保持する必要がない、はるかにシンプルな環境になります。 おそらく次の数ミリ秒以内に共有する必要があるだけです。 ただし、トランザクション アクティビティが非常に多いため、真のメモリ内分散アーキテクチャがなければ、メッセージング プラットフォーム自体がボトルネックになります。 したがって、データ ストレージがボトルネックになっているだけでなく、メッセージング プラットフォームもボトルネックになっています。 覚えておいてください。 そして、やはりメッセージング プラットフォームには、Web アプリケーション固有のキャッシュと同じ問題があります。つまり、通常、メッセージとして保持されているものはすべて、データベースにバックアップ コピーが存在しないということです。 そうですね、それはデータベースにすでに存在するデータの変換バージョンである可能性があり、再作成できるかもしれませんが、再作成したくないのです。 したがって、そのデータやメッセージを失いたくありません。 そのため、優れた分散キャッシュは高速でスケーラブルである必要があるだけでなく、Web 固有のキャッシュだけでなく Pub/Sub メッセージングにもインテリジェントなレプリケーションを提供する必要があります。
Kubernetes と分散キャッシュ
ここでは、Web アプリケーションとマイクロサービスの両方を実行し、分散キャッシュを使用する Kubernetes 環境を構築する方法を示します。 つまり、この緑色の領域は Kubernetes クラスターです。 そして、Kubernetes にはクラスターという概念があります。 各クラスター内には複数のデプロイメントがあります。 したがって、これら XNUMX つのボックスの長方形はそれぞれ展開です。 つまり、Web アプリのデプロイメントがあり、XNUMX つのマイクロサービスのデプロイメントがあり、分散キャッシュのデプロイメントがあり、マイクロ サービス用の API ゲートウェイがあります。
Kubernetes がどのように動作するかについては詳しく説明しませんが、基本的に、このような環境では、マイクロサービスはアプリケーション データのキャッシュと Pub/Sub メッセージングの両方に分散キャッシュを使用します。 一方、Web アプリケーションは、アプリケーション データのキャッシュと Web セッションに分散キャッシュを使用します。
ほとんどの Web アプリケーションには Pub / Subメッセージング なぜなら、Pub/Sub メッセージングでは通常、相互に通信するためにある種の安定したサーバー プロセスが必要になるからです。 しかし、いずれにしても、一部の人はそうするかもしれませんが、ほとんどの人はそうではありません。 ただし、アプリケーション データ キャッシュ用に用意されているのと同じキャッシュ インフラストラクチャは、Web セッションにも使用でき、Pub/Sub メッセージングにも使用できます。この場合、ご覧のとおり、これらは Pod としての Docker インスタンスです。 。 これらは Windows ボックスまたは Linux ボックスになる可能性があり、どちらを選択するかは好みに応じて異なります。 最近のほとんどの銀行はすべてを Linux に移行しており、 .NET Core Linux をサポートしているからです。 これで、.NET アプリケーションと Java アプリケーションの両方、そしてもちろん Linux 上で Node.js を使用できるようになりました。
つまり、これは、サービスと Web アプリケーションの両方、および分散キャッシュをホストする Kubernetes 環境の様子です。 ここで指摘しておきたいことの XNUMX つは、Kubernetes で稼働する分散キャッシュは Kubernetes と互換性がある必要があるということです。 Kubernetes Operator と呼ばれるものを実装している必要があります。 NCache それはあります。 したがって、どの分散キャッシュに注目する場合でも、それが Kubernetes と互換性があることを確認してください。
アプリデータキャッシングの概要（API）
したがって、これが私の唯一のコーディング スライドです。 これ以上コーディングについては説明しません。 これの全体的な考え方は、アプリケーション データ キャッシュが分散キャッシュの主な使用例であり、開発中のすべてのアプリケーションでこれを利用する必要がある、ということです。 それが Web アプリケーション、Web サービス、マイクロサービスであっても。 そして、これは分散キャッシュが持つ非常に単純な API であることがわかります。
- キャッシュ接続
ICache cache = CacheManager.GetCache(“myDistributedCache”); cache.Dispose(); - データの取得
Employee employee = cache.Get<Employee>("Employee:1000"); bool isPresent = cache.Contains("Employee:1000"); - データの書き込み
cache.Add("Employee:1000", employee); cache.AddAsync("Employee:1000", employee); cache.Insert("Employee:1000", employee); cache.InsertAsync("Employee:1000", employee); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
キャッシュ ハンドルがあるので、cache.Get、cache.Contains を実行します。 通常は文字列であるキーがあり、値が返されます。値はオブジェクト、.NET オブジェクト、Java オブジェクト、JSON ドキュメントのいずれかになります。 Node.js は明らかに JSON で動作します。 ただし、.NET および Java アプリケーションにオブジェクトやデータを JSON として保存させることもできます。 そして、実際には、これをデータ共有プラットフォームとして使用することもできます。これは、たとえば、Java 顧客オブジェクトである顧客オブジェクトを格納する Java アプリケーションがあるためです。 分散キャッシュに保存されると、次のようになります。 NCache それは JSON ドキュメントに変換され、その後 Node.js または .NET アプリケーションまたは .NET Core アプリケーションはそれを取得したいと思っています、彼らはそれを取得します…としましょう、 .NET Core アプリケーションはそれを .NET 顧客オブジェクトまたは JSON ドキュメントとして取得し、Node.js はおそらくとにかく JSON ドキュメントを取得するだけでしょう。 つまり、取得、追加、挿入、削除が可能な限りシンプルになりました。 したがって、分散キャッシュの使用方法の習得は非常に早くなります。
アプリデータキャッシュの機能
分散キャッシュを使用する場合、最大の使用例はアプリ データ キャッシュであるため、アプリ データ キャッシュの主要な領域のいくつかを簡単に説明します。 そして、注意しなければならないことは何ですか? XNUMX つ目は、先ほども述べたように、データのコピーが XNUMX つあり、XNUMX つはデータベースに、もう XNUMX つはキャッシュにあります。では、キャッシュをどのように最新の状態に保つのでしょうか?
- 有効期限 (絶対およびスライディング)
XNUMX つ目は、と呼ばれる機能です。 満了 これは、ほぼすべての分散キャッシュに機能として備わっており、通常は 絶対有効期限。 これを TTL または Time to Live 有効期限と呼ぶ人もいます。 もう XNUMX つの有効期限は次のように呼ばれます。 スライド式の有効期限 これはアプリ データ キャッシュ用ではなく、一定時間誰もオブジェクトを使用しない場合にオブジェクトを期限切れにするセッション タイプ用です。 しかし、絶対有効期限とは、キャッシュしているこのデータが今後 24 分間、あるいは今後 XNUMX 時間、あるいは XNUMX 時間変更されないことをキャッシュに伝えていることを意味します。 データの性質が何であれ、それを指定できます。 そして、その時間が終了すると、キャッシュは自動的に期限切れになります。 したがって、アプリケーションはそれを追加するだけで次に進むことができます。 アプリケーションは、すべてのデータを追跡することを心配する必要はありません。 つまり、これはすべてのキャッシュに最低限必要なことであり、ほとんどのキャッシュにはそれが存在します。 しかし、有効期限の問題または制限は、知識に基づいた推測だけを行っていることです。 データがそれほど頻繁に変更されないため問題ない場合もありますが、前述したように、本当の利点はトランザクション データをキャッシュすることにあります。 したがって、トランザクション データでは、より正確なデータを取得できるようにする必要があります。
- キャッシュをデータベースと同期する
分散キャッシュが持つべきもう XNUMX つの機能は、分散キャッシュがデータベースをある程度認識して、キャッシュしたデータと同期できるようにすることです。そのデータ、つまりデータベース内の対応するデータが変更された場合、キャッシュは、その項目をキャッシュから自動的に削除して、次回アプリケーションがその項目を必要とするときに、その項目がキャッシュ内に見つからずにデータベースから強制的に取得されるようにするか、キャッシュがそのコピーを再ロードする必要があります。それ。 そして、リロードは、これから説明する別の機能を介してのみ可能です。 リードスルーとライトスルー。 ただし、キャッシュをデータベースと同期できれば。
したがって、同期するには XNUMX つの方法があります。 XNUMX つはイベントベースです。 そのため、最近のほとんどのデータベースにはデータ変更イベントが組み込まれています。 SQL Server、Oracle、MongoDB、Cosmos DB はすべて備えています。 Cosmos DB では変更フィード、MongoDB では変更ストリーム、SQL Server では SQL 依存関係、Oracle ではデータベース通知か何かと呼ばれていると思います。
したがって、分散キャッシュがデータベース内のこれらの機能を利用している場合、キャッシュされたアイテムとデータベース レコード セットの間にある種の関係を作成できます。 したがって、そのデータが変更されると、データベースは分散キャッシュに、このデータは変更されましたが、そのデータのコピーを自分で管理してくださいと通知します。 したがって、キャッシュはキャッシュを削除するかデータベースからリロードすることができ、データベースに機能としてイベントがない場合は、別のメカニズムとしてポーリングを使用できます。
- リレーショナルデータの処理
XNUMX 番目に必要なことは、リレーショナル データをキャッシュしている場合、XNUMX 対多、XNUMX 対 XNUMX の関係に関連するデータの整合性の問題がいくつかあることです。 したがって、このアイテム、この顧客オブジェクト、そしてこの注文オブジェクトがあることをキャッシュに伝えることができれば、それらは関連しています。 したがって、アプリケーションが顧客オブジェクトを削除すると、キャッシュはすべての注文を自動的に削除します。 したがって、そうすることで、いわゆるダングリング参照がキャッシュ内に存在しなくなります。 それができれば、キャッシュは常に最新の状態になります。
- SQLクエリ
したがって、これらの機能を使用して、キャッシュに少なくとも最初の XNUMX つの機能があれば、自信を持ってあらゆる種類のデータをキャッシュに入れることができます。 そして、その自信を持てるようになると、大量のデータをキャッシュに保存し始めるでしょう。 そして、大量のデータをキャッシュに入れると、キーに基づいてデータを検索するだけでは十分ではないという別の問題が発生します。 したがって、データベース内でデータを検索するのと同じように、データを検索できるようにする必要があります。これが SQL クエリです。 .NETの場合、 .NET Core LINQもあります。 したがって、オブジェクトの属性に基づいてデータを検索できればよいのです。 「すべての顧客オブジェクトを渡してください。都市はサンフランシスコです」などと言うことができます。 そうすれば、データベースのように動作します。 検索できる参考データもあります。 検索できる検索データはたくさんあります。 したがって、データを検索できれば、キャッシュはより使いやすくなります。 データを見つけることができるため、より多くのデータをキャッシュすることに自信が持てるようになります。 なぜなら、SQL クエリを実行できなくなると、アプリケーションが突然非常に複雑になってしまうからです。 保存したすべてのキーを追跡する必要があります。
- グループ、タグ、名前付きタグ
もう XNUMX つの側面も同じ関係にあり、関連するデータをグループ化して、一度にすべてフェッチできるようにする必要があります。 したがって、さまざまな分散キャッシュがグループ、タグ、および名前タグの概念を提供し、この XNUMX つのタグに一致するすべてのものを取得できます。 または、キャッシュからすべて削除するか、キャッシュから取得します。 したがって、より多くのデータをキャッシュし始めると、キー以外のデータをすばやく検索できることが非常に重要になります。
- リードスルーとライトスルー
これが私が話していた機能、つまりリードスルー、ライトスルー機能です。 この機能の重要性は、たとえば… まずこれが何であるかを説明しましょう。 したがって、分散キャッシュがある場合、この機能がない場合、アプリケーションはすべてのデータを読み取ってキャッシュに入れ、そのデータでデータベースも更新します。 しかし、キャッシュを複数のアプリケーションにますます関連付けるようにすると、キャッシュは次のようになります。キャッシュがより自立できるようになり、キャッシュ自体が処理できるようになると、アプリケーションが簡素化されます。 この場合、複数のアプリケーションがそのキャッシュを、マスター データ ソースが何であれメモリ内表現として扱っているだけであるとします。 ご存知のように、私が言ったように、メインフレーム、リレーショナル、または NoSQL。 したがって、このメモリ内の分散キャッシュにキー値ストアとしてアクセスします。これは非常に簡単で、すべてメモリ内にあるため、非常に高速であり、データを読み取ることができない場合でも、分散キャッシュはデータを読み取ることができます。 -through は、分散キャッシュに登録されるコードです。 したがって、分散キャッシュはコードを呼び出してデータベースにアクセスし、対応する項目を読み取ります。 そこで、キャッシュを実行するとします。特定のキーを取得し、その項目がキャッシュになかった場合、キャッシュはリードスルーを呼び出してデータベースからその項目を取得します。
- 後書き
同様に、キャッシュを使用してキャッシュ内のデータを更新するだけでなく、データベース内のキャッシュを更新することもできます。 また、ライトビハインドはそれのより高度なバージョンで、キャッシュの更新は同期的に行われますが、データベースの更新は非同期的に行われます。
- キャッシュローダー/リフレッシャー
キャッシュ ローダーとリフレッシュは、キャッシュをウォームアップできるもう XNUMX つの方法です。 キャッシュを開始すると、常に必要になることがわかっているすべてのデータがキャッシュに設定されます。 したがって、こうすることで、毎回 read-through を呼び出す必要がなくなります。 したがって、たとえば数百万のオブジェクトをキャッシュにロードすると、指定したビジネス ルールに基づいて、そのデータの特定のサブセットを定期的に更新できるもう XNUMX つの機能がキャッシュ リフレッシャーです。 これらは、ビジネス ロジックが何であれ、イベント ベースの場合もあれば、時間ベースの場合もあります。 「よし、マスター データ ソースからデータの最新のコピーを取得してみよう」と言うことができます。
さて、これらの状況の多くでは、データがビジネス上の機密性がそれほど高くない場合、遅すぎたり遅すぎたりしない限り、データの古いコピーがあっても問題ないというシナリオになります。 しかし、リードスルー、ライトスルー、キャッシュ ローダー/リフレッシュという XNUMX つの機能をすべて備えているため、突然、非常にスマートなキャッシュが手に入ります。 すでに述べたように、複数のデータ ソースにアクセスして自身をロードし、アプリケーション内だけでなく、複数のアプリケーション間で利用できるようにすることができます。
データ共有プラットフォーム
したがって、先ほど述べたように、複数のアプリケーションがあることが副次的な利点です。 インメモリ分散キャッシュを使用することの付加的な利点。 それで、それは何を意味するのでしょうか？ これが意味するのは、分散キャッシュが複数のアプリケーションにわたる共通のインフラストラクチャになるということです。 したがって、アプリケーションが相互にデータを共有する必要がある場合、相互に呼び出したり、データベースにアクセスしたりするのではなく、メモリ内にある、非常に簡単に理解できるキー値ストアにデータを置くだけで、超高速でスケーラビリティが高くなります。 また、リードスルー、ライトスルー、キャッシュ ローダー、リフレッシャー、その他すべての SQL 検索など、私が言及したすべての機能により、これはデータベースに似たものになりますが、マスター データ ソースではありません。
したがって、データ共有プラットフォームでは、キャッシュはマスターではありません。 これは他のマスターのコピーにすぎませんが、共有目的のみを目的としています。 そして、最近の多くの企業は、複数のアプリケーションを統合して XNUMX つの共通のビュー、XNUMX つの共通の機能を持たせることに重点を置いていると私は知っています。
私たちが話をした銀行の多くは、複数のアプリケーションにわたってカスタマー ジャーニーを理解したいと考えていることを私は知っています。 では、これらのアプリケーションはどのように相互に通信するのでしょうか? 相互にデータを共有できる中心点は何でしょうか? それは記憶にあるものでなければなりません。 メモリ内にない場合は、さらに別のボトルネックが発生します。 また、インメモリの利点は、いつでも再起動でき、データの損失がないことです。 なぜなら、マスター データ ソースからデータをリロードするだけだからです。 ただし、それ自体が利用可能になります。 また、冗長性があるため、複数のサーバーにレプリケートされます。 分散キャッシュが完全に失われる可能性は非常に低いです。 また、同じキャッシュを複数のリージョン、複数のデータセンター (サンフランシスコに XNUMX つ、ニューヨークに XNUMX つなど) にわたって実際に稼働させることができる他の機能についてもいくつか説明します。 そうすれば、災害復旧の状況にある場合、数年前にかなり大規模な閉鎖に直面したことをニュースで見たと思います。 このような状況では、真の災害復旧が必要です。 したがって、すべてを複数のリージョンにレプリケートする必要があります。 また、データ共有の目的で分散キャッシュを使用する場合、その分散キャッシュも複数の理由で複製する必要があります。これについては後ほど説明します。 しかし、これは、特にウェルズ・ファーゴのような大企業にとって、複数のアプリケーションを統合する非常に非常に重要な付帯利益です。 そして、やはり、これらのマスターを複数持つことができます。なぜなら、あなたは大企業なので、会社全体に XNUMX つのマスターを持っていないかもしれないし、持っているかもしれないからです。 または、データを共有するために社内の特定の部分にこれらを複数配置することもできます。
分散キャッシュアーキテクチャ
分散キャッシュを使用するすべての方法について説明しましたが、アーキテクチャの観点から、優れた分散キャッシュには何を期待すべきでしょうか?
高可用性
XNUMX つは高可用性です。 分散キャッシュは実際の運用環境で使用されているため、真の高可用性が得られていない場合は、分散キャッシュに対して非常に懐疑的になる必要があります。高可用性とは、分散キャッシュが作成するクラスターにピアが必要であることを意味します。ツーピアアーキテクチャ。 ピアツーピア アーキテクチャがなく、マスター スレーブ機能がある場合、マスターが停止すると、スレーブは読み取り専用になるか、操作不能になります。 したがって、実行時にサーバーを追加または削除できる機能は非常に重要です。
線形スケーラビリティ
XNUMX 番目は線形スケーラビリティであり、これはデータをパーティション分割することによって実現されます。 次のスライドに進んでお話します。 したがって、パーティショニングには XNUMX つの方法があり、XNUMX つはレプリケーションを行わずにパーティショニングするだけであり、XNUMX つ目はレプリケーションを使用してパーティショニングすることです。 つまり、分散キャッシュは、先ほど述べたように、冗長性とスマートなレプリケーションを提供します。
そのスマート レプリケーションとは何ですか? スマート レプリケーションとは、すべてのデータがパーティション分割され、すべてのパーティションが別のサーバーにバックアップされ、そのすべてが動的であることを意味します。 つまり、自己修復です。 したがって、新しいサーバーを追加すると、新しいパーティションが作成され、新しいレプリカが作成され、データが自動的にバランスされます。
ここで例を示します。 XNUMX つのサーバー キャッシュ クラスターで開始し、トランザクションの負荷が増大したため XNUMX つ目のキャッシュ クラスターを追加したいと考えたとします。 XNUMX 番目のサーバーを追加するとすぐに、XNUMX 番目のパーティションが自動的に作成されます。 これで XNUMX つのパーティションができました。 そのため、レプリカも再調整する必要があります。 すべては動的または自動的に行われます。
そして、同じように、あなたがそれを望んでいる、または何らかの理由で 3 つのサーバーがダウンしたとします。 サーバー 3 がダウンし、パーティション 3 がダウンしたとします。 パーティション 3 がダウンするとすぐに、レプリカ XNUMX がアクティブになります。 そして、XNUMX つのサーバーと XNUMX つのパーティションがあるという異常事態が発生しました。 したがって、今度はそれ自体を自動的にマージして XNUMX つのパーティションと XNUMX つのレプリカに戻す必要があります。 これらすべては人間の介入なしに自動的に行われる必要があります。 人間の介入が必要な場合は、真の高可用性とは言えません。 NoSQL databaseこれらは永続ストレージの大量のデータを処理する必要があるデータベースであるため、この動的な再パーティション化は提供されません。 そして、それは大丈夫です NoSQL database。 ただし、インメモリ ストアでは問題ありません。 インメモリ ストアは、サーバーの数の増減において、より迅速かつ機敏である必要があります。
WANレプリケーション
複数のサイトがある場合の高可用性は次のとおりです。 したがって、サイト 1 (たとえばサンフランシスコ) に分散キャッシュがあり、サイト 2 を使用したい場合は、アクティブ/パッシブまたはアクティブ/アクティブを使用できます。 以前はアクティブ/パッシブの方が多かったですが、今ではクラウドのおかげでほとんどの人がアクティブ/アクティブに移行しています。 インフラストラクチャを稼働させるのははるかに簡単です。 つまり、人々はアクティブ/アクティブなサイトを持っているだけです。
また、アクティブ/アクティブ チャレンジでは、両側が同じデータを更新する可能性があるため、より多くの競合が発生するため、分散キャッシュに何らかの競合解決機能を組み込む必要があります。 NCache ただし、真の高可用性を実現するには、XNUMX つのデータセンターを超えて複数のデータセンターにアクセスする必要があることに注意する必要があります。
多くの状況では、XNUMX つのデータセンターでは十分ではない可能性があるため、XNUMX つ以上のデータセンターがある場合でも、同じアクティブ/アクティブ レプリケーション機能が必要です。 したがって、XNUMX つのデータ センターがダウンした場合でも、他の XNUMX つのデータ センターが負荷を引き継ぐことができ、その後、その XNUMX つのデータ センターをバックアップして再接続できるようにする必要があり、ユーザーには中断が発生しないはずです。
分散キャッシュを使用して、人間を介さずにすべて動的にその目標を達成できる場合は、当然のことながら、データ センターのバックアップには人間の介入が必要です。 ただし、高可用性を真に高めるには、データセンターがダウンしたときに人間の介入があってはならない。 たとえXNUMX分でも遅れたら、それは受け入れられません。
これで私の話は終わりです。 少しだけ時間があるように、できるだけ早く終わらせようとしました。 簡単にまとめた感想を述べさせていただきます。 私が伝えたかった主な点は、開発中のすべてのアプリケーションで、これまでに説明した XNUMX つの使用例に対して、メモリ内分散キャッシュを持たせることを強くお勧めするということです。 そして、理想的には、複数のアプリケーション間でのデータ共有にも使用する必要があります。 また、いずれの場合でも、同じアプリケーション内であっても、災害復旧が確実に行われるように複数のサイトを用意する必要があります。
そして、私は15年の経験からこれについて話しています。 私たちはこれを行ってきました。 NCache は 15 年以上市場に参入しており、多くの銀行と協力してきました。 当社は伝統的に .NET ショップでしたが、 NCache .NET、Java、Node.js を完全にサポートするようになりました。 .NET と Java のクライアント側コードとサーバー側コードの両方、および Node.js はクライアント API のみです。 これで私の話は終わりです。
ありがとう、イクバル。 ウェルズ・ファーゴで近代化の道を歩む私たちにとって、このプレゼンテーションがいかに時宜を得た適切なものであったかは、どれだけ強調してもしすぎることはありません。 それでは、よろしくお願いします。 チームの皆様、ご質問がございましたら、チャットで質問してください。 イクバルさん、一連の質問があります。 チームには多くの質問がありますが、このプレゼンテーションとビデオは公開されるのでしょうか? 答えは「はい」です。 プレゼンテーション後、オンデマンドでご利用いただけるようになります。 リンクをお送りします。 それで、イクバル、ここに寄せられた質問のいくつかを紹介します。
分散キャッシュは機密データをどのように処理しますか? 同様に、透過的な暗号化も疑問です。
そうですね、それについて詳しく話す時間がなかったと思いますが、それも非常に重要な側面です。 のような製品 NCacheたとえば、次のようになります。 セキュリティ 複数のレベルで。 認証、認可、セキュリティがあります。 暗号化があります。 つまり、複数の暗号化アルゴリズム。 一部の 128 ビット暗号化、一部の 256 ビット暗号化。 TLS、トランスポートセキュリティがあります。 したがって、ウェルズ・ファーゴのような銀行のキャッシュはセキュリティを提供する必要があり、それが私たちが銀行と協力しているためです。 それは私たちが長い間持っていた機能です。 したがって、データを暗号化することができます。 繰り返しますが、これらはすべて自動的に行われます。 これを行うためにプログラミングは必要ありません。 これらは単なる構成です。 ただし、分散キャッシュは、これらのさまざまな機能を通じてセキュリティに対処する必要があります。
次の質問は、Oracle などのデータベースにオブジェクトとメモリをキャッシュすることと、Oracle の前に別のメモリ キャッシュを置くことの違いは何でしょうか。 基本的に、Oracle により多くのメモリを割り当てることで同じ結果を達成できますか?
キーワードは「分散」だと思います。 分散されていないものは高速ですが、スケーラブルではありません。 そのため、私の最初のスライドはスケーラビリティという言葉の定義でした。 展開として 1 ボックスから 10 ボックス、さらには 50 ボックスに移行できますか? 当社の顧客の中には、150 以上のアプリケーション サーバーからなるアプリケーション サーバー ファームを所有している人もいます。 そして、ご存じのとおり、当社はまた、… とも連携しています。ちなみに、State Street Bank も当社の顧客であり、そのため、単一のデータベース サーバーによるメモリ内キャッシュではこれを処理できる方法はまったくありません。 はい、これは Oracle や SQL Server などを高速にするための非常に重要な機能ですが、スケーラブルではありません。 スケーラビリティは分散によってのみ実現できます。
どのように NCache と比較したパフォーマンス Redis、Coherence およびその他の市場製品。 そして、質問のもう 10 つの部分は、ロードマップに Scala や Python などの追加のプログラミング言語をサポートする計画があるかということです。 実は、最初に XNUMX 番目の質問に答えさせてください。 はい、私たちは Scala と Python を積極的にサポートする予定です。 実際、今年もそうする予定です。 私たちは過去 XNUMX 年近くにわたって Java をサポートしてきました。 ご利用されるお客様のほとんどが NCache、大企業であれば、Java と .NET の両方にそれを使用します。 ただし、.NET の観点から購入する可能性もあります。 それで、それが最初です。
XNUMX番目の質問は、どうやって行うのかということでした。 NCache パフォーマンスとの比較 Redis その他？ つまり、みんな速いんです。 誰かを悪く言うつもりはありませんし、皆さんも自分で比較してみてください。しかし、彼らは皆速いです。 私が皆さんに警告したい唯一のことは、一部のプレイヤーがベンチマークを行うことについて間違った印象を与えているということです。 たとえば、私たちが提供するベンチマークには、完全な往復が含まれています。 したがって、cache.Get または cache.Insert を実行している場合、その挿入操作がアプリケーションに返されない限り、その操作は完了しません。 しかし、他のベンダーの中には、実際には当社のベンチマークよりもはるかに大きなベンチマークを示しているところもありますが、彼らはいわゆる「終わったら忘れる」ことを行います。 したがって、送信するだけで気にしないのであれば、明らかにもっと多くのことができるはずです。 そして実際、Java 側では Hazelcast と Redis 研究室はまったく同じ点で互いに追求し続けています。 ということで、このままにしておきます。
あなたは他の銀行などと協力し、PCI データをキャッシュ領域内の機密データに戻す際のコンプライアンス問題に取り組んできました。 そこで法規制遵守の問題に遭遇したことがありますか?
実は違う。 まず第一に、さまざまなセキュリティ機能の暗号化をすべてデータ レベルで提供しているという事実です。 データをキャッシュする前に、またトランスポート レベルでも暗号化できるためです。 サーバー側でも認証と認可を行いますが、これはキャッシュ サーバー側です。 そして、これで十分だと思います…さらに、安全なデータセンター内でキャッシュが実行されます。 キャッシュは、外部エンティティがアクセスできるものではありません。 したがって、これらすべてを内部でキャッシュが実行されるという事実と組み合わせると、キャッシュは存在しませんでした。 NCache XNUMX年以上経ちましたが、何の問題もありませんでした。
メインフレーム データベースではどのように動作しますか?
メインフレームとは、あなたが所有するものだと思います... たとえば、おそらく皆さんはそうなるでしょう... あなたはおそらく今日 Web サービスを持っており、アプリケーションがメインフレームにアクセスできるようにするためのマイクロサービスを開発することになるでしょう。 メインフレームは、メインフレームからデータを取得するのに非常にコストがかかるもう XNUMX つのケースです。 速度の点でも、メインフレームが外部でホストされている場合には、トランザクションごとまたは旅行ごとに料金を支払う必要がある場合もあります。 したがって、先ほど述べたように、Kubernetes またはマイクロサービス層内でより多くのデータをキャッシュでき、メインフレームへのアクセスを減らすことができれば、パフォーマンスが向上するだけでなく、おそらく大幅なコストも節約できるでしょう。
ノードの追加や削除時に、メモリ内分散キャッシュ全体でのデータの一貫性と可用性はどのように確保されるのでしょうか?
それで、少なくとも私が話すことができるのは、 NCache それ NCache ノードを追加または削除するときに、行われている更新や行われている変更が、状態転送を行っているという事実によって完了することを保証します。たとえば、パーティショニングなどを移動しています。 NCache ノードが追加され、状態転送と呼ばれるものを確認しながら、すべての更新が正しく適用されていることを確認する必要があることを認識しています。これは、あるパーティションから別のパーティションにデータを移動するためのデータバランシングです。も起こり続けています。 それで、 NCache それを保証します。
図で見たように、マイクロサービスが独自のデータベースとともに分散されている場合、これらはどのようにして顧客にオムニチャネル エクスペリエンスを提供できるのでしょうか?
分散データベースの部分については、データベースがどのように分散されるかについては結論が出ていないと思います。 これらのデータベースがどのように分割されるか。 なぜなら、講演で述べたように、物理的には同じデータベース サーバー上に存在するとしても、少なくとも理論上はすべてのマイクロ サービスが独自の論理データベースを持つことができるからです。 100 個の異なるデータベース サーバー (各マイクロ サービスに XNUMX 台ずつ)。 いくつかの統合データベース サーバーを使用することになります。 あなたが分離しているという事実は、おそらくあなたにもう少し柔軟性を与えます。 NoSQL しかし、リレーショナル データベースの制限を実際にどの程度回避できるかについては、まだ結論が出ていません。 私の予測では、最終的には同じリレーショナル データベース サーバーを使用することになるでしょう。 論理的な分離がある場合もあれば、ない場合もあります。 別々のスキーマを持つことも、同じスキーマを持つこともできます。異なるテーブルと通信しているだけですが、データベース サーバーは同じままです。 つまり、これは Web サービスでも取り組んでいるのと同じ問題であり、マイクロサービスでも取り組もうとしているのです。 時間がなくなりつつあると思います。 感謝してもしきれません。 これは非常に興味深いものでした。 質問は殺到し続けていますが、すべてに答えることができないことは明らかです。 それでは、これをあなたにお返しします。