インフラ
「落ちない」金融クラウドの作り方── 可用性目標から逆算する設計
金融システムの可用性は、しばしば「九が何個並ぶか」で語られます。ただ、この数字を目標として掲げるだけでは設計は決まりません。何をもって停止とみなすのか、どの範囲を対象とするのか、そして超過したときに何をするのかまで含めて初めて、アーキテクチャの選択に接続されます。
本稿では、可用性目標を出発点として、そこから冗長化、データ整合性、依存関係の扱いをどう決めていくかを整理します。あわせて、目標を高く置いたことによって別のリスクが増える構造についても触れます。
目標値の前に定義を決める
可用性を測るには、まず何を停止とみなすかを定義する必要があります。プロセスが生きていても業務が回っていない状態はよくあり、ヘルスチェックが通ることと利用者が取引できることは別です。
実務では、利用者から見た成功率と応答時間を指標に置くのが現実的です。たとえば残高照会 API について、成功率と一定時間内に応答した割合を組み合わせ、その計測値をサービスレベル指標として扱います。インフラの死活ではなく業務の成否で測ることで、目標が設計に接続されます。
対象範囲も明示します。計画メンテナンスを含めるか、上流の金融ネットワーク側の障害を含めるか、片方の機能だけが縮退した状態をどう数えるか。ここが曖昧なままだと、事後に「あれは停止に当たるのか」という不毛な議論になります。
冗長化はどの粒度で効くのか
冗長化の議論は、単一障害点を潰すという方向で進みがちですが、実際には障害の相関を見るほうが有益です。同一のアベイラビリティゾーンに置いたインスタンスを増やしても、ゾーン全体の障害には効きません。同じ設定変更を全ノードへ一斉に配れば、冗長化は無力です。
金融システムでとくに見落とされやすいのが、変更に起因する障害です。ハードウェア故障よりも、設定変更やデプロイをきっかけとする障害のほうが件数として多くなります。したがって、冗長化と同じ比重で、段階的な変更の適用と即座の切り戻しを設計に入れる価値があります。
マルチリージョン構成は強力ですが、コストと複雑さが跳ね上がります。とくに、データの整合性を保ったままリージョンをまたぐ書き込みを行うと、応答時間が悪化します。まずは単一リージョン内のゾーン分散で目標に届くかを検討し、規制やBCPの要求から必要な場合に限ってリージョン分散へ進むのが順当です。
マルチリージョンを採る場合、切り替えを自動にするか手動にするかは慎重に決める必要があります。自動切り替えは復旧時間を短くする一方で、誤検知による不要な切り替えのリスクを伴います。金融の記帳系では、切り替え自体が事故になりうるため、判断を人に残す構成も合理的な選択です。
いずれの構成でも、切り替え後に元へ戻す手順まで含めて設計します。フェイルオーバーは訓練していても、フェイルバックは手順が曖昧なまま残っていることが多く、切り替えたまま長期間運用するという状態を招きます。
整合性と可用性のどちらを取るか
分散システムでは、ネットワーク分断が起きたときに整合性と可用性の両方を保つことはできません。金融システムでは、勘定に関わる処理は整合性を優先し、分断時は受付を止める判断が基本になります。二重記帳を許すくらいなら止めたほうが被害は小さいためです。
一方、参照系や通知系は可用性を優先して構いません。残高照会が数秒前の値を返すことは、多くの場面で許容されます。ここを一律に扱うと、本来止める必要のない機能まで巻き込んで停止させることになります。
# 機能ごとに整合性の要求が違う。停止の判断も分ける。
services:
ledger: # 記帳。分断時は受付を停止する
consistency: strong
on_partition: reject
slo: { availability: 0.9995, latency_p99_ms: 800 }
balance-query: # 参照。多少の遅れは許容する
consistency: eventual
on_partition: serve_stale
max_staleness_seconds: 30
slo: { availability: 0.9999, latency_p99_ms: 200 }
依存関係が可用性の上限を決める
自社の設計をどれだけ丁寧に作っても、依存先の可用性を超えることはできません。直列に依存する要素が増えるほど、全体の可用性は下がります。したがって、依存関係の棚卸しは可用性設計の中核作業になります。
ここで効くのが、依存を必須依存と縮退可能な依存に分類する作業です。認証基盤のように落ちたら何もできないものと、レコメンド機能のように落ちても本体は動くものを分け、後者は呼び出しに短いタイムアウトとサーキットブレーカを入れて切り離せるようにします。
外部の金融ネットワークへの依存は、そもそも自社では制御できません。相手方のメンテナンス時間帯や障害を前提に、受付だけ継続して後で処理する方式が取れるかを業務側と合意しておくと、全体の停止時間を短くできます。
見落とされやすいのが、制御系への依存です。設定配布の仕組み、名前解決、証明書の発行、コンテナイメージの取得といった要素は、平常時には意識されませんが、障害時にはこれらが動かないと復旧作業そのものが進みません。復旧手順が外部サービスに依存していないかは、事前に確認しておく価値があります。
依存の可視化には、実際の通信から関係を起こす方法が有効です。設計図に描かれた依存関係と、稼働中の実態はしばしば食い違います。分散トレーシングで観測された呼び出し関係を定期的に出力し、想定と違う経路が生まれていないかを確認すると、いつの間にか増えた依存に気づけます。
データの保護と可用性は別の問題
可用性の設計とデータ保護の設計は、しばしば混同されます。冗長構成があればデータは守られると考えがちですが、複製は誤った書き込みも忠実に複製します。アプリケーションの不具合や誤操作でデータが壊れた場合、冗長化は助けになりません。
必要なのは、時間をさかのぼれる仕組みです。バックアップの取得間隔は、失っても許容できるデータ量から逆算します。ここで復旧できることを実際に確認する工程が要ります。取得できていても復元できないバックアップは珍しくなく、定期的な復元試験を運用に組み込んでおく必要があります。
金融システムでは、記帳の追記のみを許す設計にして、状態を導出可能にしておく方法も有効です。過去の状態を再構成できるため、誤った処理の影響範囲を特定しやすく、訂正も追記として記録できます。監査への説明もしやすくなります。
復旧時間を短くする投資
可用性は、障害の発生頻度と復旧時間の積で決まります。発生をゼロにはできない以上、復旧時間の短縮への投資は費用対効果が高くなります。
効くのは地味な要素です。障害を検知するまでの時間、原因の切り分けにかかる時間、切り戻しの実行時間。このうち検知と切り分けは、ログとメトリクスとトレースが相関して追えるかどうかで大きく変わります。取引の識別子が全レイヤのログに乗っていれば、どの工程で失敗したかを短時間で特定できます。
切り戻しは、実際にやってみないと所要時間が分かりません。定期的に本番相当の環境で切り戻しを実行し、手順書と実態のずれを潰しておくことが、いざというときの差になります。
あわせて、エラーバジェットの考え方を運用に持ち込むと、可用性と開発速度の綱引きが数値で扱えるようになります。目標を下回るまでに許容される停止時間を予算とみなし、予算が残っているうちは変更を進め、使い切ったら安定化を優先する。この運用は、可用性の議論を精神論から切り離す効果があります。
障害の振り返りでは、個人の不注意に原因を求めない姿勢を明示しておきます。手順を誤ると事故になる仕組みが残っていること自体が問題であり、そこを直さない限り同じ事象は再発します。振り返りの結論が再発防止策として仕組みに落ちているかを、次の振り返りで確認する運用にすると、対策が形骸化しません。
まとめ
可用性の目標は、数字を掲げるところではなく定義を決めるところから始まります。業務の成否で測り、機能ごとに整合性と可用性の優先順位を分け、依存関係を必須と縮退可能に切り分ける。そのうえで、発生の抑制と同じだけ復旧時間の短縮に投資する。この積み重ねが、結果として高い可用性につながります。
金融テクノロジー総合研究所では、クラウド・マイクロサービス構成の設計レビュー、SRE とオブザーバビリティの導入支援、金融システムの開発伴走を受託しています。現行構成の評価からご相談いただけます。お問い合わせよりご連絡ください。
FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。
