一、災害対策の要件#
1. サービスレベル契約（SLA）の要件#
SLA の要件は通常、一定期間内にサービスを復旧する必要があることを規定しています。SLA の要件を満たせない場合、顧客に対して適切な補償や説明が必要であり、そのリスクは比較的管理可能です。
2. トランザクションの正確性の要件#
トランザクションには ACID と呼ばれる 4 つの特性があります。それらは原子性（Atomicity）、一貫性（Consistency）、分離性（Isolation）、永続性（Durability）です。金融システムでは、特に原子性の要件が厳しいです。つまり、トランザクションに含まれるすべての操作がすべて成功するか、すべて失敗してロールバックする必要があります。トランザクションの正確性の要件を満たせない場合、システムは大きな混乱を引き起こし、そのリスクは比較的高くなります。たとえば、ATM での引き出し時に引き落とし成功と表示されますが、ATM が突然停電し、現金を吐き出すことができない場合、引き出し前の状態に復元する必要があります。
災害対策の要件は、上記の 2 つの要件に対応するために、SLA レベルとトランザクションの正確性レベルをコストとのバランスで組み合わせる必要があります。たとえば、災害対策の要件がトランザクションの正確性の要件を満たせず、SLA の要件のみを満たすが、そのコストが SLA に必要な補償予算よりも大きい場合、そのような災害対策は意味をなしません。この場合、日常の利益の一部を災害対策の補償基金として使用することで要件を満たすことができます。また、一部の金融取引は取引量が少なく、顧客数が少ない（ただし、金額が高い可能性があります）ため、SLA の要件は比較的低く、数日または数ヶ月である場合があります。この場合、災害対策のコストは高くなりません。
二、災害対策の監視#
災害対策を実施するためには、まず監視が必要です。金融機関、特に銀行では、複数のデータセンター間での災害対策監視を使用しています。
1. 監視データのローカル非同期バックアップ#
監視データはローカルで非同期にバックアップされ、異なるデータセンターの監視システムが互いに監視します。
2. リアルタイムおよび遅延監視#
プッシュ（push）：ビジネスシステムがビジネス指標を監視システムにアクティブに送信することにより、リアルタイムな監視を実現します。これにより、リアルタイム性が高くなりますが、リソースの要件も高くなります。
プル（pull）：監視システムが定期的にビジネスシステムから監視指標を取得することにより、監視を実現します。たとえば、AnyRobot というログオペレーションツールは、Syslog、SNMP、SSH、JDBC などの標準プロトコルを使用してビジネスシステムから監視指標を取得できます。
3. 監視自体もエラーが発生する可能性がある#
監視がエラーを検出すると、災害対策が開始されますが、監視自体もエラーが発生する可能性があります。この場合、災害対策時には誤報の問題を考慮する必要があります。
三、災害対策処理#
1. サービスの災害対策処理#
状態を持つサービスと状態を持たないサービスは異なるサービスアーキテクチャです。判断基準は、同じ送信元からの 2 つのリクエストがサーバーサイドでコンテキスト関係を持っているかどうかです。
状態を持たないサービスでは、リクエストを任意のサーバーに送信し、負荷分散などの手段を使用して水平スケーリングを実現できます。たとえば、トークンを cookie に保存してリクエストデータを転送する方法があります。
出典：CSDN ブロガー「༺鲸落༻」のオリジナル記事
オリジナル記事リンク：https://blog.csdn.net/nsx\_truth/article/details/108917851
一方、トランザクションの処理には状態を持つサービスが必要です。たとえば、電子商取引の購入プロセスでは、ショッピングカートから注文入力、支払いなどの一連の操作があります。この場合、セッションを使用してログインユーザーのコンテキスト情報を維持することができます。HTTP プロトコルは状態を持たないですが、セッションを使用することで、HTTP 状態レスサービスを状態を持つサービスに変換することができます。
出典：CSDN ブロガー「༺鲸落༻」のオリジナル記事
オリジナル記事リンク：https://blog.csdn.net/nsx\_truth/article/details/108917851
状態を持たないサービスの災害対策は比較的簡単であり、サービスのスケジューリングアルゴリズムによってサービスが異なるノードにスケジュールされます。状態を持つサービスの災害対策は、データノードにサービスノードをマッピングすることによって実現されます。
2. データの災害対策処理#
1）単一ノードの災害対策
単一ノードのデータ書き込み操作は、アプリケーションキャッシュ、OS キャッシュ、ハードウェアコントローラーキャッシュ、ディスクストレージの順に行われます。このプロセスで電源が断たれると、書き込みは失敗します。現在の解決策は 2 つあります。1 つはバッテリー付きハードディスクを使用して電源断の時間を遅らせ、最終的なディスクストレージの完了を保証することです。もう 1 つはクラスター + ロードバランシングを使用してビジネスの高可用性を確保することです。（ここで注意する必要がありますが、クラスターのみであり、分散型ではありません。両者の違いについては、分散型とクラスターの違いと利点を参照してください。）
2）複数ノードの災害対策
銀行のシステムでは、2 つのデータセンターまたは 3 つのデータセンターなど、2 つ以上のデータセンターを使用することがよくあります。どちらの場合でも、共有アルゴリズム（共有アルゴリズム）を使用しています。最も有名なのは Raft 共有アルゴリズムです。Raft はマスターとスレーブノードに分かれており、少なくとも 2 つのノードが必要です。1 つのノードだけでは分散型にはなりません。Raft の展開には通常、3 つのバックアップノードまたは 5 つのバックアップノードの 2 つのオプションがあります。少なくとも半数以上のノードがオンラインである必要があります。
まず、2 つのデータセンター（3 つのバックアップ）の場合を見てみましょう。つまり、1 つのデータセンターに 1 つのノードがあり、もう 1 つのデータセンターに 2 つのノードがある場合です。この場合、単一ノードの障害が発生した場合、残りの 2 つのノードが正常に動作するため、システムは正常に動作します。ただし、2 つのノードを持つデータセンターで障害が発生した場合、1 つのノードしか残っていないため、半数以上のノードがオンラインでないため、システム全体が正常に動作しません。この設計は単一ノードの災害対策を満たすことができますが、データセンターレベルの災害対策を満たすことはできません。
次に、2 つのデータセンター（3 つのバックアップ）の場合を見てみましょう。つまり、3 つのデータセンターがあり、それぞれに 1 つのノードがあり、2 つのデータセンターが同じ都市にある場合です。この場合、上記の 2 つのデータセンターレベルの障害が発生しても、システムは正常に動作します。ただし、都市レベルの障害が発生した場合、たとえば地下鉄の工事で都市の光ファイバーが切断された場合、1 つのノードしか残っていないため、半数以上のノードがオンラインでないため、システム全体が正常に動作しません。** この設計はデータセンターレベルの災害対策を満たすことができますが、都市レベルの災害対策を満たすことはできません。** このような設計は、現在多くの銀行で使用されている設計です。国家は銀行の災害復旧能力に要件を設けており、一定の資産を超える場合は 2 つのデータセンターと 3 つのバックアップの設計を行う必要があります。
最後に、3 つの都市に 5 つのノードを設置する 3 地域 5 センターを見てみましょう。この設計は、おそらく金融システムで最も高度な災害対策設計であり、都市レベルの災害対策を満たすことができます。アントフィナンシャルは以前、これを披露しました。ただし、このようなソリューションは現在ほとんど使用されておらず、銀行は通常、2 つのデータセンターと 3 つのバックアップで十分です。証券会社の多くはデュアルアクティブであり、大規模な多ノードの災害対策システムを構築するためのリソースがないため、ほとんど使用されていません。
四、容災と災害復旧#
容災と災害復旧は単純に同じものではありません。後者はより広範な範囲をカバーし、バックアップと容災を含みます。ただし、バックアップの目的は引き続き容災のためであり、バックアップが成功しても、システムが障害を起こし、復旧が必要な場合にバックアップからの復旧に数日かかる場合、つまり RTO が長い場合、この場合のバックアップは実質的に意味をなしません。または、データ量が多すぎて、毎日のバックアップ時間が足りない場合、多くの銀行のデータベースシステムは 1 晩ではバックアップが完了しないため、容災は考えられず、災害復旧は言及することさえできません。
以前に「バックアップ技術の概要」という記事を書いたことがあります。CDP バックアップと CDM バックアップについて説明しました。これらのバックアップ技術はいずれも容災に適しています。前者の RTO はほぼ 0 であり、後者の RTO も短く、デュアルアクティブを実現できます。これらは優れた選択肢です。国内の災害復旧リーダーである爱数（アイシュー）は、タイムリーなバックアップ、CDP バックアップ、CDM バックアップを銀行の 2 つのデータセンターと 3 つのバックアップの災害復旧に同時に適用しています。
出典：爱数学院
参考文献：#
任杰，《正しいクロスデータセンターリアルタイム災害対策の実現方法》