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