3つのシステム間でデータ突合を繰り返す、泥臭い異常検知バッチの仕組み
どれほど堅牢にアーキテクチャを設計しても、実行時に外部システムとの連携で100％エラーが発生しないことを保証するのは難しい。ブルーモ証券では、顧客の注文窓口である自社システムに加え、米国の現地の取次先であるアルパカ証券、そして日本国内の正確な平均取得単価や源泉徴収税額を計算する外部の証券基幹システムという、異なる3つのシステムが常時連携している。小林氏は「この3社の間で整合性が保たれているかということを、念入りにチェックするようにしています」と説明。システム実行時に期待通りの結果になっているかを走査する異常検知プログラムを複数実装し、Kubernetes上のバッチ処理として定期的に実行している。
この検証処理は多角的に行われている。第1に、市場が閉じた翌朝にすべての約定データを取り込んだ後、全注文のレコードステータスをチェックし、約定処理が完全に取りこぼしなく完了しているかを自動検証する。第2に、顧客口座における累計入金額、未徴収手数料、残余現金といった各種金額フィールドにおいて、意図しないバグによって値が負数（マイナス）になっていないかを検証する不正残高検知だ。そして第3に、「全ユーザーの保有数量の総和」「ブルーモ証券が取引所に出した注文の合計数量」「外部の証券基幹システム内で実際に保有されている数量」の3点が完全に一致しているかを突合する保有数量不一致検知である。これらの網の目のような検証バッチの多くは、過去に発生したトラブルの経験から、再発防止策として実直に組み上げられてきたものだ。
アクセス急増への対応と、そこから定着したインシデント対応のプロセス
プロダクトの正式リリース直後、ブルーモ証券はテレビ経済番組「ワールドビジネスサテライト（WBS）」に取り上げられた。しかし、放映が始まった瞬間に想定を超える大量のリクエストがシステムに殺到。「いざ放送が始まったら、とんでもないリクエストが一気に来て、短期間でアクセスが集中し、サーバー負荷でつながりづらい状態が続きました」と小林氏は当時を振り返る。このとき、現場のエンジニアが取った応急処置は、コンテナ数だけでなくデータベースも含めたインフラリソースを一気に「10倍」へと引き上げる判断だった。
このトラブルをきっかけに、同社はエンジニア主導によるインシデント対応プロセスとポストモーテム（事後分析）の仕組みを定着させた。システムアラートや目視チェックで異常が検知されると、即座に重大インシデントかどうかのトリアージが行われる。重大インシデントと判断された場合は専用のプライベートチャンネルが開設され、インシデントコマンダー（IC）、領域専門家（SME）、コンプライアンス責任者（RCO）が明確に役割分担し、チームで復旧にあたる体制が敷かれた。
今回のセッションで示されたように、証券システムをゼロから内製開発する道筋は、制約条件の適切な分解とそれに応じたアーキテクチャ境界の設計、そして実行時の不整合を防ぐ継続的なデータ突合バッチや仕組み化されたインシデント対応といった「コードの外側」の泥臭い運用の積み重ねによって支えられている。各言語のエコシステムや特性を適材適所で活かし、発生した課題を確実に再発防止策へ落とし込んでいく実直なプロセスこそが、高い信頼性が求められる領域でミッションクリティカルなシステムを安定稼働させるための確固たる鍵となっている。
