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

SRE Kaigi 2026

Transcript

1. SREが向き合う大規模リアーキテクチャ 〜信頼性とアジリティの両立〜 SRE Kaigi 2026 シンプルフォーム株式会社 守屋邦昭
2. 自己紹介 守屋邦昭 (もりやくにあき) 経歴 2017-2020 アカツキ(サーバーエンジニア) 2020-2024 GA technologies (SRE) 2024- シンプルフォーム 1992年生まれ 33 歳 シンプルフォーム株式会社の一人目の SRE Embedded SRE としてプロダクト開発やSRE活動に従事 2025年10月からは「SRE・プラットフォームチーム」を立ち 上げ、エンジニアリングマネージャーに就任 2
3. 3 シンプルフォームについて 目指す世界 全ての法人がフェアに繋がれる世界 届ける価値 この国を支える審査統合基盤 信念 面倒を愛する 存在意義
4. シンプルフォーム株式会社 30秒で法人調査 ~ レポート提供 ~ 適時×確実なアラート ~ モニタリング提供 ~ 非対面で不明瞭になった 存在や事業内容を確認 数百万社の管理を自動化 真に見るべき情報のみ通知 一気通貫の取引マネジメント 4 法人の審査を支えるプロダクトを開発しています プロダクトについて 

5. シンプルフォーム株式会社 行政への 架電 請求書類 郵送 現地/ポスト 実査 大量の紙 取込 正確なデータ入力 目検/アノテーション 5 面倒を愛して集める法人定性データ 導入企業様（一部抜粋） 独自データを武器に社会の裏側で審査を支えています
6. シンプルフォーム株式会社 本日お話すること 6 1. 法人のリスク変化を追従するということ 2. 既存のアーキテクチャの課題 3. 新アーキテクチャの詳細 4. 顧客影響を最小限にする移行戦略 5. リアーキテクチャの成果 法人のリスク変化を検知するプロダクト SimpleMonitor を大規模に リアーキテクチャした舞台裏、SREとしてどう向き合ったのかをご紹介します！ アジェンダ
7. シンプルフォーム株式会社 第一章 7 法人のリスク変化を追従するということ
8. シンプルフォーム株式会社 法人は常に変化していく 8 2017年 法人設立 2020年 新役員就任 2025年 代表者逮捕 • 法人は設立後、住所や役員、事業形態などその状態は変化していくが、例えば金融機関にとって、 取引先に変化が生じた際に何かしらのリスク低減措置を取る必要が生じる場合がある • SimpleMonitor は法人の変化を追従し、顧客にとってリスクとなる変化を検知した際にアラート を通知するプロダクト 変化を追跡 アラート発火
9. シンプルフォーム株式会社 SimpleMonitorのビジネス上の課題 9 • 数百万の法人を同時にモニタリングできるため、利用者は日々の情報収集から解放されるという恩 恵を得ることができる • しかし、重要なのはリスクを検知した後の対応 (例) 倒産を検知 → 取引を停止、マネーロンダリングの疑い → 担当者にヒアリング • アラートを上げる条件や閾値を適切に設計しないと通知がノイズとなり、かえって業務の効率を下 げてしまう ノイズとなるアラートの削減(先鋭化) リリース以後、ノイズを削減してアラートを先鋭化するためのチューニングを繰り返してきた
10. シンプルフォーム株式会社 SimpleMonitorのビジネス上の課題 10 • 利用顧客が増えるにつれて、顧客によって価値あるアラートの筋は全く異なる実態が浮き彫りに なってきた • 特に単一のリスク変化だけではなく、その他の変化と同時期に発生した場合にリスクが上昇すると いうケースも見られるようになってくる 地道なチューニングも限界を迎えるように (例) 休眠法人を買収して持続化給付金を不正に請求する詐欺を検知したい - 廃業寸前で活動実績がない = 社員数がゼロ - 法人の代表者や住所が変わった → それぞれの変化単体ではリスクではないが、複合条件で疑いが増す！ → しかし現状のアーキテクチャでは上記を実現することは困難(後述)
11. シンプルフォーム株式会社 第二章 11 既存のアーキテクチャの課題
12. シンプルフォーム株式会社 SimpleMonitorのアーキテクチャ 12 • ユーザーがアラートの確認をするための Web UI と、アラートを作成するバッチで構成 • 監視する法人と各種リスク情報の照合やアラートデータの作成といったビジネスロジックはバッチ に集約 • アラート発出ロジックはバッチ側、画面の見た目等は Web UI 側を改修する Web UI バッチ
13. シンプルフォーム株式会社 アラートが作成されるまでの処理フロー 13 step① ユーザーは監視したい法人の一覧を SimpleMonitor に登録する 法人A 法人B 法人C … step② 日次バッチで法人情報データベースと登録された法人を照合する step③ 重要な変化を検知した場合にアラートとしてユーザーに通知 法人A 法人B 法人C … 通知 法人B OOのリスクが検知されました Pythonバッチ Rails web UI アラート閲覧
14. シンプルフォーム株式会社 バッチ処理のソフトウェアアーキテクチャ 14 • 検知項目(データソース)毎に専用ディレクトリを切っている • 各データソース、レイヤー間の依存関係は最小限に抑えられている レイヤー名 責務 Repository データソースを検索して ORM でオブ ジェクトを生成 Domain Repository 層で取得したデータを画面 での表示用に加工 Controller 他レイヤーのロジックを呼び出して一連 処理を記述 個別の項目を低リスクで改修できる設計
15. シンプルフォーム株式会社 アーキテクチャ上の制約が機能開発のボトルネックに 15 一方で以下のデメリットも抱えている • 検知項目を新規で追加する場合の改修コストが大きい ◦ Repository、Domain、Controllerの3層分のファイルやテストの追加が必要 ◦ 1週間スプリントに収まらず、リリースまで1ヶ月近くかかることも • 複数の検知項目を組み合わせた複合的な条件でのアラート作成が困難 ◦ 一連の処理がディレクトリ(項目)ごと分離されているため 項目1 項目2 • アラートを上げる閾値がほぼハードコーディングされている ◦ ユーザー毎に細かく条件をカスタマイズすることを想定してい なかった ◦ 顧客への導入が進む中で多様なニーズが出現！
16. シンプルフォーム株式会社 第三章 16 新アーキテクチャの詳細
17. シンプルフォーム株式会社 リアーキテクチャで目指す要件 17 • 新しい検知項目をより少ない開発工数で追加できること • 複数の検知項目を組み合わせた複合条件でアラートを作成できること • ユーザー毎にアラートを上げる条件(閾値)をカスタマイズできること データモデリングから再考が必要
18. シンプルフォーム株式会社 既存のデータモデリング 18 ユーザー アラート 設定 監視対象 法人 アラート • ユーザー毎に「アラート設定」を設定 • 「アラート設定」は検知項目のON/OFFのみを管理 • アラート設定に「監視対象法人」を複数紐付ける • アラートは一つの法人に対して、検知項目の数だけ複数作成されることがある 条件や閾値をユーザー毎にカスタマイズすることを想定していない
19. シンプルフォーム株式会社 データモデリング改善案 19 ユーザー アラート 設定 監視対象 法人 アラート • 「検知項目」に対して細かい条件や閾値を設定できるように「条件」と「検知項目」を追加 • 上記を束ねる「シナリオ」という概念を新設 • 既存の「アラート設定」はあえて残し、全体的に変更ではなく追加で対応する方針とした 条件 シナリオ 検知項目 シナリオという新概念を追加 → 既存の運用からシームレスに移行できる
20. シンプルフォーム株式会社 新データモデルの課題 20 • 「シナリオ」という概念が誕生し、アラートを上げる条件や検知項目がユーザー毎に可変に なった • 条件 x 検知項目の組み合わせが掛け算で増えていくことになり、ロジックをどう実装するか が課題となった 条件 シナリオ 検知項目 シナリオ 条件 検知項目 社員数減少 x人以下 社員数 社員数及び住所の 変化 x人以下 & 1回変更 社員数 住所 組み合わせ爆発となる検知ロジックをどう実装するか
21. シンプルフォーム株式会社 既存のアラート作成フロー 21 法人データA テーブル 法人データB テーブル 検索 表示用に加工 アラート 作成 アラート テーブル 検索 表示用に加工 アラート 作成 アラート テーブル 次の検知項目へ ・ ・ ・ • 対象となるマスターデータを検索してヒットしたレコードを加工してアラートテーブルに書 き込む • 上記を検知項目の数だけ順次実行するという手続き型で実装されており、新データモデルで 表現される検知項目や条件を複数組み合わせた処理の実装はこのままでは不可能 例) 社員数 例) 住所
22. シンプルフォーム株式会社 中間処理テーブルを追加 法人データA テーブル 法人データB テーブル 検索 表示用に加工 中間処理 テーブル (イベント) ・ ・ ・ • 新たに「イベント」という中間処理用のテーブルを追加 • 各マスタテーブルから検索した結果を一旦、イベントテーブルに書き込む • バッチは日次で動かすため、前日に追加されたマスタデータを全量取り込むイメージ • アラートを上げるための細かい条件はここでは無視するため、各マスタテーブルを created_at = 昨日の日付で検索するだけのシンプルな検索クエリとして実装できる 22 アラート テーブル ←には書き込まない
23. シンプルフォーム株式会社 中間処理テーブルに対して細かい条件で検索を適用 • シナリオ毎に設定された検知項目・条件に応じてイベントテーブルを検索 • ヒットしたイベントレコードをアラートテーブルに書き込めばアラート作成が完了 • 検索対象のテーブルが1種類であるためロジックを簡単に記述できる上、検索に利用される カラムが固定されるため、DBのインデックスが効いてパフォーマンス上も有利！ 23 シナリ オ毎に 検索 アラート 作成 アラート テーブル 23 中間処理 テーブル (イベント) (例) 「社員数が50人以下かつ住所が1回変更」 を検知したいシナリオの場合、 同じ法人に対して右記のような2レコード がヒットしたらアラートを作成 id corporate_id category_id value 1 333 4 (社員数変化) 50 2 333 5 (住所変更) null イベントレコード
24. シンプルフォーム株式会社 アラート作成フローの変更点まとめ 法人データA テーブル 法人データB テーブル 検索 表示用に加工 中間処理 テーブル (イベント) シナリ オ毎に 検索 アラート 作成 アラート テーブル 前半 後半 ・ ・ ・ • マスタデータの検索→加工→アラート作成を検知項目の数だけ手続き的に繰り返す処理を、前半 と後半に分割 • イベントという中間処理テーブルを用いた ETL 型のフローにしたことで、各ステップのロジッ クはシンプルでありながら、ユーザー毎に異なる検知項目と条件で柔軟にアラートを作成できる 24
25. シンプルフォーム株式会社 バッチ実行基盤を Rails + Sidekiqに • 歴史的経緯からバッチは Python スクリプト、アラートを表示する Web UI は Ruby on Rails で 実装されており、開発時のコンテキストスイッチが辛かった • Web UI 側は他プロダクトの表示ロジックも入ったモノリス構成となっており、Rails 側に集約す るのが自然な流れだった • Rails で非同期処理を実現する「Sidekiq」にバッチ実行基盤を移行することでコードベースを Web UI と統一 Before After
26. シンプルフォーム株式会社 SRE観点での設計の工夫① 26 • マスタデータを修正したりバグ等で不備のあるアラートが作成された場合、バッチを再 実行することでデータを修正できるようにしたい 異常発生時は再実行することで安全に復旧できる • イベント・アラートテーブルに「対象日」カラムを追加してインデックスを作成 • 日次バッチ実行時にまず、対象日に該当するレコードを全削除してから新規作成 • バッチ実行時に「対象日」をパラメータとして渡すことで、過去に実行された分のレ コードも再作成できる
27. シンプルフォーム株式会社 SRE観点での設計の工夫② 27 • バッチは毎朝 4:00 に起動し、通常であれば 1 時間ほどで処理が完了 • 毎朝 7:00 に顧客の始業時間に合わせてアラートをメールで通知している • 何らかの原因でバッチの処理時間が伸びて 7:00 のメール送信までに完了しなかった場 合、顧客の業務に影響を与えてしまう バッチの実行時間にSLOを設定 • バッチの実行時間に超えてはならない閾値を設定し、違反した場合は Slack 通知する監 視を導入 • AM 4〜7 時の 3 時間に SLO を引くのではなく、90 分辺りに引くことで、平常時から の悪化を検知し、障害になる前に対応ができる体制ができた
28. シンプルフォーム株式会社 SRE観点での設計の工夫③ 28 • 毎朝 4:00 開始のバッチ実行するもデータの不備などでバッチがエラーを起こし、異常 終了することがある • その場合、7:00 に顧客にメールを送信するまでの3時間足らずで緊急修正を行う必要が あり、早朝ということもあって非常に辛い障害対応となる • ドライランというフラグを True にしてバッチを実行すると、レコードの作成だけをス キップするロジックを実装しておく(バッチの最後にトランザクションをロールバックす る) • 前日にドライランモードでバッチを実行すること、データ不備やパフォーマンス悪化を 事前に検出できるようになった ドライランモードによる前日のリハーサル実行
29. シンプルフォーム株式会社 第四章 29 顧客影響を最小限にする移行戦略
30. シンプルフォーム株式会社 移行に際しての課題 30 SimpleMonitorは既に多くの顧客で利用中のプロダクトである • 新規で実装したアラート作成バッチにダウンタイム無しで移行できるか？ • 膨大な量のロジックのバグやパフォーマンス劣化をどう検知するか？
31. シンプルフォーム株式会社 新旧バッチを並行稼働 31 • 旧環境のバッチと新規実装したバッチを本番環境で並行稼働させる • 新環境で作成したアラートレコードを内部用の別画面に表示 • QAと開発メンバーが毎朝両方の画面を比較し、バグを検出 旧バッチ 新バッチ
32. シンプルフォーム株式会社 ひたすらバグ検出と修正を繰り返す日々 32 • 新バッチが初日から SQL が遅すぎて落ちる • 作成されたアラートレコードの件数が数万件単位で合わない...！ • staging 環境でQAした際は検知できなかった表示のズレなどが多発 SQL チューニングやバグ修正して hotfix リリース & 翌朝再チェックする日々
33. シンプルフォーム株式会社 約1ヶ月間の並行期間を経て無事に切り替えが完了！ 33 並行稼働期間を設けた成果 • 並行期間中に多くのデグレを検知したが、旧環境を利用する顧客への影響は一切出な かった • 切り替え前から新バッチが常時稼働することで、切り替え時にメンテナンスを入れて データ移行する必要がなくなる • ダウンタイムゼロで顧客影響を出さずに新環境への切り替えが完了！ 得られた教訓 • 並行期間中は連日のバグ修正で大変だったが、顧客影響無しという安心感は大きかった • 検出したデグレは検証環境と本番環境のデータの量と質の差分によるとこらが大半であ り、検証環境での QA の精度に課題が見つかった！
34. シンプルフォーム株式会社 第五章 34 リアーキテクチャの成果
35. シンプルフォーム株式会社 新機能開発のリードタイムや柔軟性が改善 35 検知項目を増やしてアラートの種類を増やしたい場合 旧アーキテクチャ 新アーキテクチャ ディレクトリを追加して3レイヤー分のロ ジックを記述する必要があり、1ヶ月近く かかることも 前半の対象テーブルから検索し、イベント を作成するモデルレイヤーの実装のみ。 1~2週間ほどでリリース可能 アラートを上げる条件のチューニング(閾値の変更や指標の追加) 旧アーキテクチャ 新アーキテクチャ 検知項目毎にロジックが独立しているので 個別に改修することはできるが、ユーザー ごとのカスタマイズは不可能 後半のイベントテーブルを検索するロジッ クだけ改修すれば済む。また、シナリオ毎 に異なる条件設定が可能
36. シンプルフォーム株式会社 バッチの運用も楽に 36 • Sidekiq の管理画面からジョブ(バッチ)をマニュアル実行したり、失敗したバッチのエ ラーを確認できる • 有料版の Sidekiq Pro を導入することでジョブ実行中に ECS が落ちても自動で再実行す る機能が追加され、ECS のスケールインに強くなる • 自動リトライやリトライ失敗後のコールバック処理など異常発生時のハンドリングも豊 富 • 各種ジョブのメトリクスを Datadog に送信し、例えばジョブキューの詰まり具合に応じ て ECS をスケールアウトさせる workflow を構築することも可能らしい(現在検証中) Sidekiq管理画面
37. シンプルフォーム株式会社 ビジネスサイドへの貢献 37 • 顧客毎にアラートを上げる条件を細かくチューニングすることで、ノイズとなるアラー トを削減し、重要なリスクのみ注視するという SimpleMonitor のあるべき姿に近づく • 複数の検知項目を組み合わせた複合条件でのアラートをエンジニア工数無しで実現でき るようになり、より高度なリスク検知を実現 • ダウンタイム無しで移行したにも関わらず、従来とは抜本的に異なる新機能が実現され たことで顧客に感動を与えることができた 業務効率が実際に改善された、人力では不可能な業務の高度化 に利用できる等の Good FB に繋がった
38. シンプルフォーム株式会社 38 運用を見据えたソフトウェア設計 SREがプロダクトのリアーキテクチャに関わる意義 • 障害が発生することを前提に復旧の仕組みを予め仕込んでおく(再実行によるデータ再作 成) 顧客影響を最小化する移行戦略 • 可能な限り本番に近い場所で入念に動かしておく(本番環境での並行稼働) 障害を事前に検知する監視 • ドライランモードによるバッチのリハーサル実行 • 実行時間に SLO を引いて通知を設定 アジリティだけ考えていたらこれらは実現できていなかったかもしれない
39. シンプルフォーム株式会社 おわりに 39 この国を支える審査統合基盤を一緒に創っていく SRE・ SWE を大募集中！ • 今後マルチプロダクト化を加速させるため新規プロダクトを続々と開発中！ • 既存のリアーキテクチャの余地もまだ存分に残っている • これらのニーズに組織横断で応えるため、「SRE・プラットフォームチーム」の立ち上げ を推進中 シンプルフォームにおける開発のこれから
40. シンプルフォーム株式会社 40 ご清聴ありがとうございました！