SREが向き合う大規模リアーキテクチャ〜信頼性とアジリティの両立〜 by 守屋邦昭

SRE Kaigi 2026
セッション(30分)

SREが向き合う大規模リアーキテクチャ〜信頼性とアジリティの両立〜

Zepprix 守屋邦昭 Zepprix
1

■ 発表カテゴリ
Architecture: SREの視点からのシステム設計
Practices: SREの実践例と得られた教訓

■ 発表概要(400字程度)
Web アプリケーションとバッチ処理で構築された金融機関向けプロダクトを、本番稼働を止めることなく大規模にリアーキテクチャした実践事例を紹介します。成長に伴い複雑化する顧客要件に対応するため、DB スキーマレベルから再設計することを決断しました。SRE としては、信頼性を高める設計と、顧客影響を最小化する移行戦略の両面に取り組みました。

信頼性を高めるシステム設計

  • DB パフォーマンスの改善
  • 異常時に再実行で修正可能なバッチ実装
  • ドライランモードの導入
  • 処理時間 SLO を守るための監視と運用

顧客影響を最小限に抑える移行戦略

  • 本番相当データを用いた性能検証と QA
  • 新旧バッチ並行稼働して差分を確認

また、バッチ処理に ETL ライクな段階的データフローを導入することで拡張性を高めることにも成功しました。設計・移行・運用の各局面で、SRE がどのように信頼性を担保し、移行を成功に導いたのかを余すことなく共有します。

■ 発表の詳細(1000字程度)
以下の内容でお話します。

イントロダクション

  • 法人のあらゆるリスク情報の変化を追跡するプロダクト、「SimpleMonitor」について
  • モニタリングしたい法人を登録するとリスク評価に関わる重要な情報・属性に変化が生じた際にアラートを上げる
  • シンプルフォーム社が収集した独自データを元に様々な検知項目でアラートを上げることができる
  • 金融機関を中心に導入が進む中、より複雑な条件や複数の検知項目を組み合わせたアラート設定のニーズが高まっていた

既存アーキテクチャが機能開発のボトルネックに

  • DB スキーマ的に検知項目 x 顧客毎に細かいパラメータを設定することができず、複雑な検知条件を記述できない
  • 検知項目毎にクラスを切ってロジックを実装しており、複数の検知項目を組み合わせたアラートの実装が非常に困難
  • アプリケーションはデータの流れに応じて 3 層構造で実装されており、検知項目を新規で追加する場合は 3 層分のロジックを新規実装する必要があり、拡張性が低かった
  • 1 週間スプリントで毎週リリースする体制にも関わらず、新規の検知項目を実装するのに 1 ヶ月かかることもあった

新アーキテクチャの設計

  • 顧客毎に使いたい検知項目とパラメータを自由に設定できる DB スキーマを導入
  • バッチ処理を「イベントの抽出」と「検知条件に応じたイベントのフィルタリング」の二段構えの ETL 型のデータフローに変更
  • バッチ基盤に ECS、Ruby on Rails、Sidekiq を選んだ理由

信頼性を高めるための設計・運用

  • 新アーキテクチャのパフォーマンス上の利点
  • 異常発生時のロールバック及び再実行をやり易くするバッチ構成
  • dry-run モードを実装してリハーサル実行を行う
  • バッチの処理時間に SLO を設けて監視を導入

顧客影響を最小限に抑える移行戦略

  • できるだけ本番環境に近づけた検証環境を用意し、より精緻な QA や負荷検証を実施
  • 過渡期は新旧バッチを並行稼働させ、作成されたアラートの差分を確認してバグを検知
  • 旧基盤からのデータ移行

リアーキテクチャ後の成果、まとめ

  • 移行の経緯と結果
  • 移行前と比べて拡張性がどう改善したか
  • 失敗談、得られた教訓

■ 対象聴衆とその人たちが得られるもの

  • プロダクトの設計レベルから信頼性を高めていきたい SRE エンジニア
  • バッチ処理の運用や設計に携わっているエンジニア
  • プロダクトのリアーキテクチャを検討しているエンジニア

聴講者は具体的な事例から以下のような知見を持ち帰ることができます。

  • SRE 観点でのバッチ処理の設計・運用の工夫
  • 拡張性の高い ETL ライクなデータ処理フローの設計事例
  • 稼働を止めずにデータやシステムを移行したノウハウ

■ なぜこのトピックについて話したいのか(モチベーション)
一般的に、SRE がインフラや非機能面に関わることはあっても、アプリケーション設計にまで踏み込む機会はそれほど多くないかもしれません。実際、多くの開発組織では SWE と SRE の役割がある程度分かれており、アプリケーションレイヤーを SWE が主導するのは自然なことだと私も考えています。
一方で、もし設計段階から SRE が積極的に関与できれば、アジリティと信頼性の両立が可能になるのではないかとも思います。
本セッションでは、プロダクトのリアーキテクチャを契機として、SRE が設計レベルから参画することで得られた成果を紹介します。SRE が自らのコンフォートゾーンを越えて挑戦することの価値について、ぜひ具体的な事例を元にお伝えできればと考えています!