IGamingでのフェイルオーバーとバックアップの動作

iGamingに特別なDR/BCP規律が必要な理由

カジノプラットフォームは、リアルタイムマネー（ウォレット/元帳）、ライブラウンド（RNG/ライブ）、支払い、アフィリエイト、および厳格なコンプライアンスです。アクセシビリティホールはすぐに金融および法的リスクに変わります。したがって、アーキテクチャは予測可能な回復を中心に構築されています：既知の目標、既知のシナリオ、リハーサルされた手順。

基本的な目的と条件

RTO： リカバリ時間の目標

財布/台帳の場合：≤ 60-300 sec（地域間feilover）、 ≤ 15分（地域間DR）。

Recovery Point Objective （RPO）-許容されるデータ損失。

レジャーの場合：0-5秒（同期/準同期レプリケーション）、レポートの場合：≤ 15分。

SLAとエラー予算：変更率と安定性の間のトレードオフを形式化します。

フォールトトレランス層

1）インフラ： マルチAZ/マルチリージョン

マルチAZ（最小3ゾーン）：すべての重要なサービスはゾーン、自動データベース/バスのフェイルオーバーによって分散されます。

複数地域DR：「ホット」（アクティブアクティブ）または「ウォーム」（アクティブパッシブ）第2地域で、管轄区域（データ常駐）によって隔離されています。

どのモードを決定するか：

Active-Active： 2つのリージョンのプレイヤーへのレイテンシが低く、イベント同期によるクロスリージョン台帳+計算のための厳密な単一の「真実の場所」。
能動受動（暖かい）：より簡単、より安い；パッシブはウォームインスタンス+データベースレプリカを保持しますが、トラフィックは提供しません。

2）ネットワークおよび周囲

ヘルスチェックでingress/WAF、 AnycastまたはDNSを複製。

キャッシュレジスタとプロバイダの個別の出口ゲートウェイ、両方のリージョンで許可されているIPのリスト。

3）データとキュー

リレーショナルデータベース（Postgres）： Patroni/Managed HA、 AZの同期レプリカ、DR領域の非同期レプリカ（ラグ監視付き）。N分ごとにスナップショットとPITR+WALアーカイブ。

OLAP （ClickHouse/BigQuery）：レプリケーション/シャーディング；損失は上で受諾可能です（15-30分までのRPO）。

キャッシュ（Redis）：フェイルオーバーを持つクラスタですが、真実のソースではありません。スイッチング中-ウォームアップ。

イベントバス（Kafka/NATS）：ミラークラスタおよび/またはクロスクラスタミラーリング、最低1回の保証、消費者に対する特権管理。

4）アプリケーションとドメイン

ウォレット/台帳：厳密な一貫性を持つステートフルコア、1つの「マスターライター」地域ごとに；地域間のDR-ダブルエントリロックで「選出された作家」プロシージャ。

ゲームブリッジ/API：ステートレス、健康チェックのための水平feiler；idempotencyすべての財務経路のキー。

ボーナス/通知/ETL：遅延処理を許可し、キューから再起動します。

ボックスオフィス（PSP/crypt）：マルチプロバイダ戦略（少なくとも1カ国あたり2レール）、商人/エンドポイントの高速スイッチング。

5）ライブストリーム

リージョナルエッジノードを備えたWebRTC/LL-HLSゲートウェイ。WebRTC劣化下のLL-HLSのフォールバックルート。

ストリームの再起動が計算に影響を与えないように、ベッティングロジックをプレーヤーの外に保管します。

フェイルオーバーパターン

資産資産（バイリージョナル）

長所：最小限のRTO/RPO、プレーヤーへの近さ。

短所：レジャーの複雑さと記録の競合、高価なグリッド。

実践：「ドメインごとに1人のライター」+近隣地域の状態を再現するイベントソーシング。

資産責任（ウォーム）

長所：価格/難易度のバランス。

短所：上記のRTOは、受動的な地域を「促進する」ための実証済みの計画が必要です。

練習：ウォレットを切り替えるときのオートメーション+手動確認（4目の原則）。

イントラレジオナル（マルチAZ）

データベース/キャッシュ/入力オートフェーラー。

DNS/Anycastの変更なし、RTO秒-分。

データクラスによるバックアップ

Class（クラス	例：	メソッド	Frequenc	ストレージ	Verification（検証）
マネートランザクション/元帳	Postgres（財布、元帳）	スナップショット+WALアーカイブ（PITR）、論理レプリカ	5-15分WAL、スナップショット1-4 h	オブジェクトロック付きオブジェクトストレージ（WORM）、クロスリージョン	毎週のDR Cold+チェックサム比較
イベント情報	Kafkaトピックス	階層型ストレージ+ミラー-DR	継続的に	オブジェクトストレージ	リプレイテストウィンドウ
OLAP/レポート	ClickHouse/BigQuery	スナップショット/バッチのエクスポート	1〜6時間	オブジェクトストレージ	テストサンプルを読む
静的アーティファクト	チケット、ログ、エクスポート	バージョン管理されたS3、氷河	Daily（	WORM/バージョン	定期的なリストア
シークレット/キー	KMS/HSMメタデータ	ラッパーによるエクスポート、デュアルコントロール	スケジュールに応じて	HSMのコメント	復号化試験

原則：

バックアップは残りの部分で暗号化され、トランジットではキーはKMS/HSMで暗号化されます。
重要なバックアップ（消去保護/ランサムウェア）のための不変モード（WORM）。
メタデータを持つバックアップのカタログ（スキーマバージョン、WALウィンドウ、チェックサム）。
レジャーにはPITRが必須です。

データとアイデンポテンス： ファイラーで「穴」を避ける方法

IdempotencyKey on 'bet'リクエスト。place'、'payout。request'、'cashier。webhook'。

Ledger-append-only：繰り返しsettleは「rewrite」ではなく訂正エントリを作成します。

トランザクションロック/バランスバージョニングは、ライタの役割を切り替えるときにレースから保護します。

イベント重複除外（消費者側、キーフィールドによるハッシュ）。

レジ、PSP、 crypt： プランBは常に含まれています

支払い方法（カード/AWP）の少なくとも2つのプロバイダー、両方の地域で事前に設立された商人口座。

安定コインの場合-2つのネットワーク（TRC-20とERC-20など）と2つのオン/オフランププロバイダ。

ペイアウトルータ：障害が発生した場合、PSPは即座にバックアップに切り替え、その理由のログを保持します。

KYT/AMLストリームが複製されます。外部サービスが利用できない場合-手動エスカレーションで「劣化モード」。

運用手順（Runbooks）

［自動］

ヘルスチェックチェーンの入力→API→wallet→database→provider。

ウォレットが劣化したときの「重い」機能（トーナメント/ミッション）の自動無効化。

指数的な一時停止と厳格な締め切りでタイムアウト/リトリート。

マニュアル（確認付き）

資産へのDR領域のプロモーション：ステップ、ログ、com-templates（サポート/パートナー/レギュレータ）によるチェックリスト。

ラウンドによる補償/無効：原因コード、ビデオガイドへのリンク、責任者の署名。

ダブルコントロールで支払いを解凍します。

エクササイズと準備チェック

ゲームデー/カオスドリル毎月：AZ、データベースの劣化、プロバイダのドロップをオフにします。

完全なDRリハーサル四半期ごとに：「完全な成長で」DR領域を上げ、賭け/支払いの実際のシナリオを実行します。

リストアテスト：レジャーをタイムTに復元し、コントロールP&Lとハッシュスライスで確認します。

コンプライアンス対応表トップ：どのレポートが生成されるか（レギュレータ、PSP、アフィリエイト）を誰に通知するか。

観測可能性およびfeilover信号

SLOメトリクス：財布p95レイテンシ、share 'bet。rejected'、round settle time、 payout SLA、 database replication lag、 Kafka consumer lag。

イベントの切り替え：アラート「role change」、「replication lag> X」、「object-lock violation」。

DRダッシュボード：現在のノードロール、RPOスコア（WAL分）、PITRウィンドウステータス。

安全性とコンプライアンス

管轄区域（EU/UK/CA/……）によるデータ分離：法的制限内でのレプリケーション。

ログ（S3 Object Lock/WORM）を修正しました。

秘密：主回転、DRRのための二重制御。

すべてのスイッチオーバーとリストアの監査証跡。

DRを壊すアンチパターン

国ごとに1つのPSP/1つの安定コインネットワーク-バックアップレールはありません。

同じデータベース上のOLTPとOLAP-リカバリはライブ操作をブロックします。

idempotencyKeyなし-デビット/ペイアウトが2倍になります。

通常の復元テストのないバックアップは「Schrödinger backup」です。

WORM/不変性の欠如-インサイダー/悪意のある削除に対する脆弱性。

短いTTLと加熱エンドポイントなしのDNS feilover。

同時に2つの領域に1つの元帳ライターがステート分割されます。

緊急時の備えチェックリスト

アーキテクチャ

すべての重要なサービスのマルチAZ、文書化されたトポロジー。
役割（アクティブ-アクティブ/パッシブ）と予算を記述したDR領域。

データ

Postgres： PITR、スナップショット、ラグ監視、定期的な回復テスト。
Kafka/NATS：ミラーリング/アーカイブ、リプレイプラン。
ClickHouse/OLAP：バッチバックアップ、サンプルの復元。
S3：オブジェクトロック（WORM）、バージョン、クロスリージョン。

アプリケーション

金銭におけるIdempotency、 append-only ledger、 balance versioning。
インシデントの自動機能低下（トーナメント/ミッションオフ）。
地域を切り替える前にカナリアチェック。

チケットオフィスと暗号

メソッドごとに2つのプロバイダとステーブル用の2つのネットワーク。
ルーティングとスイッチの原因ログ。
KYT/AMLをエスカレーションで劣化モードにする。

Operations（オペレーション）

RACIとアテンダントフォンを備えたランブック。
毎月の混乱日と四半期ごとのフルDR訓練。
コミュニケーションテンプレート（サポート、パートナー、レギュレーター）。

Observability（可視性）

RTO/RPOダッシュボード、DBロールアラート、ラグ、入札/支払いの失敗。
スイッチとリストアの監査ログ。

信頼性iGamingは「feiler button」ではなく、地理的分離、予測可能なRTO/RPO、 idempotent money、マルチレールキャッシュデスク、不変バックアップ、定期的な演習、透明なコミュニケーションなどの習慣のシステムです。この規律は、元帳の損失なしに失敗を経験することを可能にします。