クラウドベースのバンキング アプリケーションの高可用性を確保する

クラウド サービス プロバイダーが重要なクラウドベースのバンキング アプリケーションの高可用性を保証すると考えがちです。 問題は、実際にはそうではないということです。

クラウド プロバイダーは、複数のデータ センターまたはアベイラビリティ ゾーン (AZ) で実行される仮想マシン (VM) のクラスターの構成を支援している場合があります。 プライマリ VM が突然オフラインになった場合に、構成内のスタンバイ VM がすぐに引き継ぐことができるように、自動フェイルオーバー システムが実装されている可能性があります。 高可用性を提供する必要があるように思えますよね?

ただし、高可用性の概要を示すサービス レベル アグリーメント (SLA) をよく見てください。SLA は、システム内の少なくとも 99.9 つの VM に少なくとも 99.99% または XNUMX% の時間アクセスできることを保証します。 ただし、これはアプリケーションまたはデータの可用性を保証するものではありません。 残りの VM が銀行アプリケーションとデータが存在するストレージ インフラストラクチャにアクセスできない場合、重要なアプリケーションは事実上オフラインになります。

クラウドへのアクセシビリティの確保

複数の AZ にまたがる自動フェイルオーバーの基盤となるテクノロジーを構成するだけでは不十分な場合、重要な銀行アプリケーションとデータがクラウドまたはハイブリッドのオンプレミス/クラウド構成で高いアクセス性を維持できるようにするにはどうすればよいでしょうか?

まず、クラスター化された VM を複数の AZ に分散させることは、主要なアプリケーションとデータの高可用性 (HA) を確保するために重要です。 ただし、さらに必要なのは、それらの VM のそれぞれが、実行し続けたい重要なアプリケーションとデータに確実にアクセスできるようにするための戦略です。 クラウドに関して言えば、HA に対する従来のアプローチが分岐するのはこの点です。

従来の (オンプレミスを意味する) HA 構成では、複数のサーバーまたは VM と、アプリケーションとデータが存在するストレージ エリア ネットワーク (SAN) で構成されるフェールオーバー クラスターを作成する場合があります。 クラスター内の任意のサーバーまたは VM は、SAN 内のアプリケーションおよびデータと対話できます。そのため、主要なアプリケーションをアクティブに実行している VM が突然オフラインになった場合、クラスターは、SAN と対話できる別の VM に自動的にフェールオーバーし、SAN の実行を開始します。以前のマシンが使用していたのと同じデータベースを更新します。

クラウドの構成

ただし、クラウドでは、共有 SAN を作成する実際のオプションはありません。 いくつかの共有ストレージ オプションがありますが、それらは重要なバンキング アプリケーションが必要とするパフォーマンスやレベルの HA を提供するようには構築されていません。 代わりに、クラウドベースの HA 構成は、クラスター内の各 VM に接続された高性能ストレージに依存します。 特定の VM がアプリケーションを実行している場合、VM は、その VM に接続されたストレージに存在するデータベースに格納されているデータと対話しています。

したがって、クラウドベースのバンキング アプリケーションの HA の鍵は、クラスター内の各 VM が常に同じアプリケーションと同じデータを持つようにすることです。 こうすることで、クラスター内のプライマリ VM が突然停止した場合、クラスターは自動的にスタンバイ VM にフェールオーバーできます。いずれの VM も、アプリケーションの実行とデータの操作をすぐに開始できます。独自の付属ストレージ。

クラウド プロバイダーは、重要なアプリケーションが要求するレベルのパフォーマンスと可用性を提供する VM を簡単に構成できます。 また、高性能ストレージ システムをそれらの VM に接続することもでき、複数の AZ にわたる自動フェイルオーバー用にクラスターを構成することもできます。 次に、フェールオーバー クラスター内の VM に接続されているすべてのストレージ システム間でデータの同期レプリケーションを自動化するメカニズムをデプロイする必要があります。

データ複製ソリューション

データ複製ソリューションに関しては、多くの選択肢があります。

クラスターが Windows ベースで、Microsoft SQL Server を使用している場合は、SQL Server の組み込みの可用性グループ (AG) 機能を使用できます。これにより、ユーザーが名前を付けた SQL データベースがクラスター内の各ノードに自動的にレプリケートされます。 このアプローチの欠点は、ストレージ内のすべてのデータ ブロックではなく、SQL データベースのみをレプリケートすることです。 複数の SQL Server データベースを複数のスタンバイ VM にレプリケートすると、SQL Server Enterprise Edition を使用して複数のデータベースをレプリケートするか、データベースを複数の VM にレプリケートする必要があるため、アプリケーションが SQL Server Standard Edition を使用して完全に正常に動作する場合でも、非常にコストがかかる可能性があります。 .

または、クラスタ内のアクティブなプライマリ VM から各セカンダリ VM へのデータの自動ブロック レベル レプリケーションを提供する SANless クラスタリング ソリューションを使用することもできます。 SANless クラスタリング ソリューションを使用する利点は、アプリケーションやデータベースにとらわれないことです。 あるストレージ システムから別のストレージ システムにデータのブロックを複製するだけで、プライマリ ストレージ システム内のすべてのデータが他の各 VM に複製されるようになります。 SAN レス クラスタリング アプローチの欠点は、IT チームがライセンスを取得して学習する必要のある別のソフトウェアがあることです。SQL Server の AG 機能を追加料金なしで使用できる場合、これは面倒に感じるかもしれません。

SQL Server などのソリューションに組み込まれた機能を使用するか、独立した SANless クラスタリング ソリューションによって提供される機能を使用するかに関係なく、データ レプリケーションはクラウドベースのバンキング システムの HA を確保するための鍵となります。

クラウド プロバイダーは、アプリケーションが要求する高性能インフラストラクチャを提供できますが、必要なときに HA ソリューションが期待どおりに機能する場合、そのクラスター内の各 VM で使用できるデータとアプリケーションが最新であることを確認する必要があります。そうすることです。

Todd Doane は、SIOS Technology のソリューション アーキテクトです。 主に金融サービスの世界で 20 年以上を費やし、高可用性リファレンス アーキテクチャとアプリケーション固有の設計パターンと原則を作成してきました。

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
• 情報源： https://bankautomationnews.com/allposts/core-cloud/ensuring-high-availability-for-cloud-based-banking-applications/