月間数億レコードのアクセスログ基盤を無停止・低コストでAWS移行せよ！アプリケーションエンジニアのSREチャレンジ💪

テックブログ
https://moneyforward-dev.jp/entry/2026/01/30/143450

SRE Kaigi 2026
https://2026.srekaigi.net/session/roomb-1420

Transcript

1. 2026.1.31 月間数億レコードのアクセスログ基 盤を無停止・低コストで AWS移行 せよ！アプリケーション エンジニアの SREチャレンジ 💪 miyamu
2. Money Forward, Inc. 2 自己紹介
3. Money Forward, Inc. 3 miyamu / 宮村紅葉 経歴 • 2019年: 面白法人カヤックに新卒入社 ◦ Golang, Perl5 • 2021年: マネーフォワード福岡開発拠点CRE ◦ Ruby on Rails • 2024年: テックリード ▪ 出身 熊本 🏯 ▪ 推しの言語 Elixir koyo-miyamura @koyo-miyamura
5. Money Forward, Inc. 5 今回お話しすること
6. Money Forward, Inc. 6 月間数億レコードの アクセスログ移行の実例 • オンプレDB → AWS • Parquet+Snappy圧縮 • 無停止移行設計 • データ重複・欠損対策 今回お話しすること 1. 技術的知見 2. 領域を超えた SRE精神 アプリケーションエンジニアが 組織を巻き込み ケイパビリティを拡張し SREチャレンジした 実践プラクティス
7. Money Forward, Inc. 7 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
8. Money Forward, Inc. 8 背景① 複数プロダクト横断アクセスログ DB • 対象システム ◦ EKS上で稼働するRuby on Rails製SaaS（稼働10年） • アクセスログ ◦ 「月間数億レコード」 をプロダクト間共有RDBに記録 ◦ 1日1回BigQueryにETL • 運用コストが非常に高い
9. Money Forward, Inc. 9 背景② アクセスログ DB運用上の課題 ログDB運用チーム マネージドでない DBサーバー パーティション管理 DB/OSパラメータ 定期的に発生する DiskFull対策 全社データ基盤 1日1回のETLの 仕組みが古い 障害対応が困難 ⚠ 数ヶ月以内に共有オンプレサーバーの廃止 ⇨ 各プロダクトでアクセスログ基盤移行 プロダクト アクセスログのみ オンプレDB 障害対応が困難 Railsアプリから見た DBが2種類存在
10. Money Forward, Inc. 10 背景③ プロダクトにおけるアクセスログの使用 ログの実体は uuid付きの1行JSON {"uuid": "xxxx", ...} 　CSチーム：問い合わせ対応のため管理画面で使用 　エンジニア：障害対応時の調査で日々活用 　データ基盤：全社 BigQueryへのETL・データ提供 ⇨「欠損は許されない、かつ無停止移行が必須」
11. Money Forward, Inc. 11 背景④ 移行難易度の高さ ➢ 広範なステークホルダー CS / 2プロダクトのエンジニア / SRE / [1] CRE 全社横断のログDB移行チーム / 全社横断のデータ基盤チーム ➢ 高い実装ハードル 全領域を把握しつつ、アプリ・インフラ両面の実装が必要 ➢ リソース不足 プロダクトSREチームのリソース不足 [1] Customer Reliability Engineer
12. Money Forward, Inc. 12 背景⑤ Challenge SRE！ ➢ 筆者の既存ケイパビリティ ✅ プロダクト側の元CREでログ運用・CS対応に精通 ✅ テックリードでRailsアプリを熟知 & SREと良好な関係 ➢ 不足しているケイパビリティ ❌ 組織の役職としてSREではない ❌ インフラ (Terraform/k8s) は触ったことはあるが初心者 ⇨このままでは「システムの信頼性」担保に重要な 　アクセスログが失われる・・・ Challenge SRE !
13. Money Forward, Inc. 13 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
14. Money Forward, Inc. 14 要件定義① 情報収集 CS/CRE/SRE/全社ログDB移行チーム/データ基盤チーム...etc 「何が変わるか（技術）」 を「どう影響するか（ビジネス）」 に翻訳することを意識（特にCSチームとの会話） ✖ 技術的な事実のみ アクセスログ基盤がRDBから AWSに変更され、仕様変更が発 生します ✔ ビジネス要件への翻訳 アクセスログの内部的仕組み移行が 予定されています。なるべく 互換性を保ちますが難しい点もあり ますので、仕様変更の際は事前に相 談させてください
15. Money Forward, Inc. 15 要件定義② 組織におけるコミュニケーションと信頼性 🤝 Win-Winな連携を目指す 各部門の目標を深く理解し、互いにメリットのある形で繋ぐ 🗣 日々の関係構築 Slackでの何気ない雑談や、些細なサポートの積み重ね ⇨ いざという時に円滑な調整が可能 📝 コンウェイの法則 [1]「組織のコミュニケーション構造が、システム設計に反映される」 ⇨ 信頼関係が強い組織は、信頼性の高いシステムを構築できる [1] https://www.melconway.com/Home/Conways_Law.html
16. Money Forward, Inc. 16 要件定義③ 移行要件まとめ 項目 要件 データ保存 共有RDB廃止 命名規則に従いS3へ保存 可用性 無停止での移行 コスト 運用・金銭的コスト共になるべく抑える 互換性 月間数億レコードに耐えられる設計 管理画面の検索機能をなるべく維持 （リアルタイム性・パフォーマンスなど）
17. Money Forward, Inc. 17 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
18. Money Forward, Inc. 18 設計 （アクセスログ書き込み）
19. Money Forward, Inc. 19 アクセスログ書き込み設計① 現状構成
20. Money Forward, Inc. 20 アクセスログ書き込み設計② 新構成の設計 設計案 メリット デメリット Aurora DB （新規） • 既存実装そのまま • DBの運用コスト /金銭的コスト大 • パーティション運用コスト大 FluentBit -> S3 • 一般的手法 • 社内実績あり • 新規構築・運用コスト大 • 既存のCloudWatchエージェントと の二重運用コスト大 アプリ ->Firehose ->S3 aws-sdk-firehose • インフラコンポーネ ント最小限 • アプリケーション実装が複雑化（特に エラー処理） • アクセスログ送信の自前実装の 運用コスト大 CloudWatch エージェント ->Firehose ->S3 • アプリログで同様の仕 組みがあり 追加運用コストなし • CloudWatchログストリームを経由 する（若干の追加転送コスト ） • 月間数億ログに耐えられるか不明
21. Money Forward, Inc. 21 アクセスログ書き込み設計② 新構成の設計 設計案 メリット デメリット Aurora DB （新規） • 既存実装そのまま • DBの運用コスト /金銭的コスト大 • パーティション運用コスト大 FluentBit -> S3 • 一般的手法 • 社内実績あり • 新規構築・運用コスト大 • 既存のCloudWatchエージェントと の二重運用コスト大 アプリ ->Firehose ->S3 aws-sdk-firehose • インフラコンポーネ ント最小限 • アプリケーション実装が複雑化（特に エラー処理） • アクセスログ送信の自前実装の 運用コスト大 CloudWatch エージェント ->Firehose ->S3 • アプリログで同様の仕 組みがあり 追加運用コストなし • CloudWatchログストリームを経由 する（若干の追加転送コスト ） • 月間数億ログに耐えられるか不明 将来の運用を見越して 現在の実装コストを払ってでも 将来の金銭的・運用コストを下げたい
22. Money Forward, Inc. 22 アクセスログ書き込み設計③ データ形式と圧縮 [1] https://parquet.apache.org/ [2] https://www.databricks.com/jp/glossary/what-is-parquet [3] https://github.com/google/snappy 形式 メリット デメリット json.gz • 一般的でみやすい • データサイズ大 = スキャン量大 （Athenaはスキャン量課金） Parquet + Snappy • Glue + Firehoseで フルマネージドに変換可 • スキャン量大きく削減 • データを直接見る場合 特殊なツールが必要 • [1] Apache Parquetはビッグデータで主に使用される列指向データ形式 ◦ [2] Databricks のレポートによると、対CSVでデータサイズが87%削減 • [3] Snappy 圧縮は Parquet でよく使われる圧縮方式
23. Money Forward, Inc. 23 アクセスログ書き込み設計④ 新アクセスログ構成
24. Money Forward, Inc. 24 設計 （管理画面）
25. Money Forward, Inc. 25 アクセスログ管理画面① 現状構成
26. Money Forward, Inc. 26 アクセスログ管理画面② 新構成の設計 ➢ 互換性維持の要件 リアルタイム性・大量のログ検索・検索パラメータ指定 ➢ AWS Athena を採用 1TBあたり5ドルの料金がかかるがパーティションでカバー Parquet形式 + Snappy圧縮によりスキャン量削減
27. Money Forward, Inc. 27 アクセスログ管理画面③ 新構成の設計
28. Money Forward, Inc. 28 設計 （リリース戦略）
29. Money Forward, Inc. 29 無停止を実現するため 新旧両方の基盤を 一定期間並行稼働し 差分なし確認後切り替える ⇨ 段階的移行戦略 リリース戦略の設計① リリース方針 新旧共存の段階的移行 ドキュメント化と周知 段階的リリースについて詳細な ドキュメントを執筆 CS含む全ステークホルダーへ 方針を周知 合意形成を得た上で 移行ステップを一つずつ踏む
30. Money Forward, Inc. 30 リリース戦略の設計② アクセスログ書き込み
31. Money Forward, Inc. 31 リリース戦略の設計③ アクセスログ管理画面
32. Money Forward, Inc. 32 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
33. Money Forward, Inc. 33 インフラ・アプリ実装 （アクセスログ書き込み） ※詳細はテックブログ にて公開
34. Money Forward, Inc. 34 Terraform記述 （AI/SREの助けを借りる） stg 環境から有効化 count = var.environment == "stg" ? 1 : 0 既存のログ転送用 Terraformモジュール拡張 アクセスログ書き込み実装① インフラ実装 AWSリソース定義・修正 k8s マニフェスト修正 cwagentconfig修正 SREチームに依頼して CWエージェントコンテナを [1] Sidecar Containers 化 ⇨ 起動順調整 [1] https://kubernetes.io/ja/docs/concepts/workloads/pods/sidecar-containers/
35. Money Forward, Inc. 35 新旧実装を両方保ちつつ 「旧実装を消しやすく 先にリファクタリング」 ⇨ 無停止でのリリース戦略実現 リファクタは先にリリース ⇨ビッグバンリリースを避ける cwagentconfig で指定したファイ ルにアクセスログを書き込む stg環境だけ書き込みを行う ⇨ 確認後prod環境にも適用 AppAccessLog::Logger の定義 インスタンス生成コストを抑えるため シングルトンで実装 アクセスログ書き込み実装② アプリケーション実装 Railsアプリ修正 先行してリファクタリング
36. Money Forward, Inc. 36 インフラ・アプリ実装 （管理画面） ※詳細はテックブログ にて公開
37. Money Forward, Inc. 37 [1]IRSAの適切な定義 Athenaが内部的に使用する 権限も付与必須 ⇨ 最小の権限は...？ Athena/アクセスログS3/ クエリ結果を格納する S3/Parquetカラム定義Glue 管理画面実装① インフラ実装 Pod -> Athena アクセス Athenaテーブル定義 Parquet形式のデータを読み 込めるよう定義 パーティションの定義 ⇨ 丸1日検索しても2GB以下 ⇨ データ量を鑑みて1日単位 [1] IAM Roles for Service Accounts
38. Money Forward, Inc. 38 管理画面実装② 実装都合で管理画面の仕様調整 変更点 理由 検索期間最大1ヶ月 Athenaのコストと 利便性のバランスを担保 ページネーション廃止 最大1000件 Athenaの特性に合わせるため スキャン量表示 （10GB目安の注意書き） Athenaに詳しくないCS向け 特定日付以前データ 検索不可 移行のため事前に1~2ヶ月分確保し 影響を最小限に留めた
39. Money Forward, Inc. 39 aws-sdk-athenaを採用 非同期実行・ポーリング などの詳細を隠蔽 管理画面実装③ アプリケーション実装 AthenaClient 実装 クエリビルダー実装 Athena は Presto ベース （ActiveRecord の MySQL アダプ タではエスケープ差異発生） 枯れたRuby gemがない！ ⇨最小限のクエリビルダーを自作
40. Money Forward, Inc. 40 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
41. Money Forward, Inc. 41 データ欠損・重複との戦い ※詳細はテックブログ にて公開
42. Money Forward, Inc. 42 データ欠損・重複との戦い① リリース後 ➢ BQの新データと Athenaの新データの不一致 😨 データ欠損と重複 が同時に発生していた😨 数週間の戦いの始まり... ➢ 初のAWSサポート問い合わせ 初めてだったのでSREチームに起票内容のサポートを依頼
43. Money Forward, Inc. 43 [1] Amazon Data Firehose はデータの重複があり得る 設計時に考慮漏れしていた >< データ欠損・重複との戦い② 重複の原因と対策 原因: Firehose の特性 対策: 重複排除 ETL取り込み時にログ中のuuidで 重複排除 管理画面の検索時にuuid で重複排除 [1] https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/basic-deliver.html
44. Money Forward, Inc. 44 データ欠損・重複との戦い③ 欠損との戦い ➢ 2週間ほど試行錯誤するも解決しない ✅ Sidecar Containers化済み → 起動・終了順は問題なし ✅ [1] バッファリング設定(force_flush_interval)調整 ✅ [2] CloudWatchエージェントのソースコード調査 ❌ それでも欠損が発生 ➢ 🔍 欠損パターン発見 アクセスログを書き込むSidekiq Podの再起動時に欠損発生 ⇨ Sidekiq の Graceful Shutdown に問題がある ...？ [1] https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html [2] https://github.com/aws/amazon-cloudwatch-agent
45. Money Forward, Inc. 45 データ欠損・重複との戦い④ Sidekiqコンテナの安全な終了 ➢ [1] SidekiqはGraceful Shutdownをサポートしている ✔ TSTPシグナルで新規ジョブ受付停止 ✔ TERMシグナルで25秒既存ジョブの終了を待ち、終わらなかったらRedisにプッシュ バックして終了 ✔ 再起動時にTSTP->TERMシグナルの送信が推奨 ➢ [2] k8sはPod終了時、各コンテナのメインプロセス (PID 1)にTERMシグナル送信 ✔ シェルスクリプト経由で起動する場合execを使わないとシェルがPID 1になりTERM シグナルが届かない ✔ TERMシグナルで終了しない場合KILLシグナルが送信され強制終了 [1] https://github.com/sidekiq/sidekiq/wiki/Signals [2] https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination
46. Money Forward, Inc. 46 データ欠損・重複との戦い⑤ Sidekiqコンテナ修正 [1] https://github.com/sidekiq/sidekiq/wiki/Reliability ➢ 原因① SidekiqがGraceful Shutdownしていなかった 😱 preStopでTSTPシグナルが送信してるつもりがコマンド不備 ✅ コマンドを修正して正しくシグナルを送信 ➢ 原因② SidekiqにTERMシグナルが届いていなかった 😱 シェルスクリプト経由で起動しておりexecコマンドなしで起動していた [1] Sidekiq Proは強制終了されてもジョブロストしないためKILLシグナルで強制 終了されても大きな問題にならず、これまで気づけなかった ✅ exec bundle exec sidekiq … に修正して PID1でTERMを受け取る ⇨ 上記2つを修正したところ、欠損がなくなった 🎉🎉🎉
47. Money Forward, Inc. 47 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
48. Money Forward, Inc. 48 移行結果 ✅ 約2ヶ月かけて月間数億レコードを無停止で移行完了 ✅ アクセスログ検索はRDBに比べ高速化するなど改善 ✅ 副次的にSidekiq PodのGraceful Shutdownも改善！ ✅ 運用コストが大幅に削減 （例: オンプレDBサーバ廃止・障害頻度激減・フルマネージド） ✅ 金銭コストも月数万円前半程度に抑えた
49. Money Forward, Inc. 49 1 背景 2 要件定義 3 設計 4 インフラ・アプリ実装 5 データ欠損・重複との戦い 6 移行結果 7 まとめ 目次
50. Money Forward, Inc. 50 • 月間数億レコード規模での アクセスログ無停止移行 （CloudWatch エージェン ト,Firehose,Athena,AWS Glueを用いたParquet形式 +Snappy圧縮） • (反省) データ重複・欠損対策 は設計段階で考慮すべき まとめ① 本セッションのまとめ 1. 技術的知見 2. 領域を超えた SRE精神 • 組織でSREの役職でなくても SRE活動は可能 • 足りないケイパビリティは各分野の エキスパートやAIを活用 • 日頃の関係構築が複雑な プロジェクトの成功を左右する • コンウェイの法則 組織の信頼関係が、システムの信 頼性を生む
51. Money Forward, Inc. 51 まとめ② SREに求められる領域横断スキル、そして魂 ➢ 現実の問題は複雑化、単一領域だけではシステムの信頼性 を高く保つことは困難 「CS・CREの業務理解」「インフラ設計・構築」 「アプリケーション実装」「ステークホルダーマネジメント」 ➢ 組織でSREでない人の SRE活動にも大きな価値がある！ SREは役職ではなく魂！ SREじゃなくても Challenge SRE！