テクノロジーとインフラストラクチャ→クラウドアーキテクチャとSLA
クラウドアーキテクチャとSLA
1） SLAの理由と管理方法
SLA （Service Level Agreement）-サービスの可用性、スピード、正確性に関するビジネス/パートナーへの外部約束。
SLO （Service Level Objective）-コマンドの内部ターゲットレベル。
SLI （Service Level Indicator）-評価されるSLOに基づいて測定可能な指標。
iGaming/fintechは、厳格なピークウィンドウ（トーナメント、ライブベッティング、レポート期間、「給与」日）、PSP/KYCプロバイダと地理への強い依存が特徴です。SLAはこの動作を考慮する必要があり、アーキテクチャは媒体だけでなくパーセンタイルも保証する必要があります。
2）基本的な用語
「可用性」（Availability）-間隔ごとの成功リクエストの割合。
レイテンシー-キー操作のP50/P95/P99。
エラー-正確に判断します（5xx、タイムアウト、ビジネスエラー？）。
RTO （Recovery Time Objective）-回復の時間はどれくらいですか。
Recovery Point Objective （RPO）-災害時にどれだけのデータが失われるか。
エラー予算-1 − SLO、変更やインシデントの「予約」。
3） SLAのためのクラウドアーキテクチャのフレームワーク
3.1マルチエリア（マルチAZ）
ステート（DB、キャッシュ、キュー）を少なくとも2-3 AZに複製します。
冷たい/暖かいスタンバイ、自動フェイルオーバー。
ローカルバランサー（L4/L7）とAZあたりの健康チェック。
3.2マルチレジオン
資産対資産：低いRTO/RPO、より困難な一貫性とコスト。
資産責任（ホット/ウォーム）：安価でRTOが多く、しかしデータ管理が容易です。
地理的ルーティング（GeoDNS/Anycast）、「ブラスト半径」分離。
3.3ストレージとデータ
トランザクションデータベース：地域内の同期レプリケーション、非同期地域間。
キャッシュ：クロスリージョナルレプリカ、「local reads+async warmup」モード。
オブジェクトストレージ：バージョン管理、ライフサイクル、クロスリージョンのレプリケーション。
キュー/ストリーミング：Mirror Clusters/Multi-Region Streams。
3.4ループ絶縁材
重要なサービス（決済/財布）と「重い」分析タスクの分離。
レポートがprodを"食べないように、輪郭の間のレート制限/クォータ。
4）高可用性パターン
隔壁とプールの分離-接続とリソースプールを分離します。
サーキットブレーカー+タイムアウト-外部インテグレーションのフリーズから保護します。
Idempotency：二重書き込みオフなしでリクエストを繰り返します。
Graceful Degradation-劣化した場合、基本的でない機能（アバター、高度なフィルタ）を無効にします。
Backpressure-着信フローを制御し、「地平線に」キューを許可しないでください。
Chaos/Failure Injection-信頼性の仮説をテストするための計画された「失敗」。
5） DR（災害復旧）戦略
選択：支払/財布-最低ホットスタンバイ；content/directory-Warm；レポート-クリアウィンドウでバックアップと復元。
6） SLI/SLOについて： 正しく測定する方法
6.レベルごとの1つのSLI
クライアントSLI：エンドツーエンド（ゲートウェイおよび外部プロバイダを含む）。
サービスSLI：「純粋な」サービスレイテンシー/エラー。
ビジネスSLI： CR （registratsiya→depozit）、 T2W （time-to-wallet）、 PSP低下率。
6.2 SLOの例
コアAPIの可用性：≥ 99。30日で95％。
ペイアウト遅延：P95 ≤ 350ミリ秒、P99 ≤ 700ミリ秒。
Webhooks PSPの配信：≥ 99。60秒間9％（レトラ付き）。
データ鮮度レポート：時間の95％の≤ 10分の遅れ。
6.3エラーバジェットポリシー
予算の50％-変更（リリース/実験）、50％-インシデント。
予算燃焼→フリーズ機能、唯一の安定化。
7）性能およびスケーリング
SLO指向の信号を持つHPA/VPA （CPUだけでなく、キュー/レイテンシも）。
スケジュールと履歴のピークに基づいた予測スケーリング。
トーナメント前にDB/PSPへの暖かいプール/予熱接続。
キャッシュとエッジ-特にゲームカタログや静的資産のRTTを削減します。
8）ネットワーク層および全体的な交通
待ち時間を最小限に抑え、クラッシュをローカライズするAnycast/GeoDNS。
フェイルオーバーポリシー：地域の健康検査、しきい値、TTLによる「粘着性」。
mTLS/WAF/Rateエッジの制限、ボットトラフィックに対する保護。
allow-listとSLA対応の後退によるPSP/KYCへの出力制御。
9）データと一貫性
一貫性のレベルを選択します。strict （payment） vs eventual （catalog/ratings）。
CQRSは、クリティカルコマンドの読み込みと垂直をオフロードするためのものです。
Outbox/Inbox for 「percently once」イベント配信。
ダウンタイムのない移行：expand-migrate-contract、 MAJOR変更時の二重エントリ。
10） SLAの下の観察可能性
ゲートウェイを介したトレース：'trace_id'とパートナー/リージョン/APIバージョンとの相関。
バーンレートのSLOダッシュボード、地域とプロバイダによる「天気」。
プロキシ症状ではなく、症状による警告（CPUではなくP99/エラー）。
合成：ターゲット国からの外部チェック（TR、 BR、 EU……）。
監査とレポート：SLI/SLOをパートナーポータルにエクスポートします。
11）安全性とコンプライアンス
ネットワークセグメンテーションと秘密管理（KMS/Vault）。
機内/残りの暗号化、PAN/PIIトークン化。
管理者/オペレータのロールアクセスポリシー。
監査のために不変（WORM）と保持を記録します。
規制：地域のストレージ、レポート、SLA実行の証明。
12） FinOps： コストドライバーとしてのSLA
SLO偏差に価格を置く：どのくらいですか+0。01％の可用性？
プロフィールのピークの窓は、一定した力を膨脹させません。
バックグラウンドタスクの右サイジングと「できる場所」。
輪郭のためのクォータと予算は、「自由な」劣化を許可しません。
13）信頼性試験
GameDay/Chaosセッション：AZ/PSPをオフにし、キューの遅延、BGPの休憩を行います。
DR-drili： RTOの目標を持つスイッチング領域の定期的なトレーニング。
Load&Soak：実際の賭け/トーナメントプロファイルでロングランを実行します。
リプレイインシデント：有名なファイルと再生スクリプトのライブラリ。
14） SLAプロセス側
SLOディレクトリ：所有者、数式、メトリック、ソース、アラート。
RFC/ADRによる変更：エラー予算への影響の評価。
死後：建築とランブックの改善、SLOの調整。
パートナーとのコミュニケーション：郵送物、状態ページ、計画された維持。
15） SLI/SLO/レポートの例
15.1つの数式
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15.2 コアAPI SLOセット例
空室状況（30日）： 99。95%
エンドポイントP95 '/v2/payouts/create'： ≤ 350ms
5xxエラー（ローリング1時間）： <0。3%
Webhook配信≤ 60SB （P99）： ≥ 99。9%
財布のRPO： ≤ 60秒、RTO ≤ 5分
15.3 SLAレポート（絞り）
完成： 99。97％ （SLO 99。95%) +
違反：PSPタイムアウト（累積8分）によるBR地域あたり2エピソード。
対策：障害コードによるスマートルーティングの追加、PSP-Bへの接続のウォームプールの増加。
16）実装チェックリスト
1.重要なユーザーパスと対応するSLIが定義されています。
2.30/90日間のSLO+エラー予算ポリシー。
3.RTO/RPO目標、定期的なドリルによるマルチゾーニングとDR計画。
4.地理ターゲット、リージョンごと/PSPごとのダッシュボードからの合成。
5.安定性パターン：遮断器、背圧、idempotency。
6.無効機能の劣化ポリシーとフィーチャーフラグ。
7.FinOps：輪郭予算、ピーク予測、暖かいプール。
8.セキュリティ：セグメンテーション、暗号化、監査。
9.パートナーのためのSLAドキュメント、コミュニケーションプロセス。
10.レトロスペクティブとSLOは1-2四半期ごとに改訂します。
17）アンチパターン
測定可能なSLIと透明なカウント技術なしのPromise SLA。
ゲートウェイ/プロバイダを無視して、「サービスの入り口で」可用性をカウントします。
中遅延のみに依存し、P99テールを無視します。
DR「紙に」、実際の訓練の欠如。
限界のない「永遠の」リソース：1つのレポートはprodをもたらします。
食品と重量分析を1つのクラスタ/データベースにミックスします。
18）ボトムライン
SLAのためのクラウドアーキテクチャは、テクニカルパターン（マルチAZ/リージョン、絶縁、フォールトトレラントデータ）、プロセス（SLO、エラー予算、DRドリル）および経済学（FinOps）の組み合わせです。フォールトトレランスのテスト、パーセンタイルによる測定、「爆発半径」を制限し、公然と通信します。その後、SLAの約束はマーケティングではなく、マネージドエンジニアリングの実践になります。