Upgrade to Pro — share decks privately, control downloads, hide ads and more …

システム成長を止めない!本番無停止テーブル移行の全貌

 システム成長を止めない!本番無停止テーブル移行の全貌

PHP Conference Japan 2025
https://phpcon.php.gr.jp/2025/

もうすぐデータ件数10億件!そうなればテーブル構造を変更したくても怖くて触れない…!
そんな状況から始まった打刻テーブル移行。

大規模リリースを避け、ベイビーステップで毎日少しずつ
内側のテーブルをすげ替えるためにやったこと、その軌跡をお話しました。

※ 閲覧用に整理しました

https://fortee.jp/phpcon-2025/proposal/37ecfd03-226b-4212-9f77-bde1b91db599

・"小さくリリース"する
・フィーチャートグル
・ログの活用
・パーティションテーブル

Avatar for さかうぇ

さかうぇ

June 28, 2025
Tweet

More Decks by さかうぇ

Other Decks in Programming

Transcript

  1. 2 新潟生まれ、新潟育ち。.NET → TypeScript → PHP SIerで東京暮らし約10年、Uターン後、2024年3月 コドモン入社 以来、新潟からフルリモート勤務 &

    PHPデビュー 請求系ドメイン担当チームで開発・運用保守に携わっている。 自己紹介 さかうぇ ひかる 経歴 そろそろ運転の練習をしてペーパードライバーを卒業したい… 最近の気になり @sakawe_ee
  2. 5

  3. 7 打刻テーブルのユースケース ユーザーは保護者の方、子ども、職員の方々 • 朝、職員が出勤時に打刻する • 朝、保護者が登園時に打刻する • 朝、施設と保護者向けに登園済チェックをする •

    夕方、保護者がお迎えで打刻する • 夕方、小学生が学童で退室打刻する • 職員が入室時刻を一括入力する • 職員が誤入力を修正する • 夜、職員が退勤時に打刻する
  4. 10 打刻データの制約 データ保持の制約 • 施設は監査の都合で 10年間は保持 & 5年間は修正できる必要がある 変更容易性の確保 •

    いつでもテーブルの構造変更ができる状態にしたい • 保持期間を過ぎたらさくっと削除したい (データ量の影響を受けたくない)
  5. 11 打刻データの特性 ほぼ毎日利用されている • 朝は6時台から、夜は23時台まで • 休日保育もあるため土日も • 利用できない場合の代替手段が "紙"

    ピークタイム • 朝7:30〜9:00に一番スパイクするピークタイム • 夕方も朝ほどではないが山ができる
  6. 13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 システム成長を止めない! プロダクト開発部の基本方針

    • 小さく進める、リリースは少しずつ流れ続ける ◦ from エクストリームプログラミングの原則 • 改修は毎日のリリースフローの中で進める ◦ 極力、夜間対応はしない ◦ 仮に計画停止しても 夜22時〜朝6時の 約8時間まで • できるなら改善も成長もどちらもやっていく!が基本姿勢
  7. 14 CONFIDENTIAL - © 2022 CoDMON Inc. 14 今日の話 "リリースを小さく"とは聞くけれど、勘所が掴めないあなたに

    毎日稼働しているシステムでも、影響を抑えて成長させたいあなたに 保管し続けなければいけない大量データに悩んでいるあなたに ベイビーステップで、ユーザー影響無く 内側のテーブルをすげ替える試み の全貌をお話しします
  8. 19 テーブル分割方法の選択肢 •A.物理テーブルに分割する メリット ・テーブルメンテナンスを並列で実行可能 デメリット ・日付をキーにテーブルを切り替える  対応が必要 ・テーブルをまたがる検索の場合は結果を  マージする必要がある

    ・定期メンテナンスの負荷が大きい •B.パーティションテーブルの採用 メリット ・現状の仕組みのままデータ参照可能 ・定期的なメンテナンスの負荷が低い ・不具合やミスが起こりにくい  (DBの仕組みを使うためリスク低) デメリット ・レコード数に応じて特定操作を行った際  のメンテナンスの時間が長くなる ・コドモンで運用実績がない
  9. 20 テーブル分割方法の選択肢 •A.物理テーブルに分割する メリット ・テーブルメンテナンスを並列で実行可能 デメリット ・日付をキーにテーブルを切り替える  対応が必要 ・テーブルをまたがる検索の場合は結果を  マージする必要がある

    ・定期メンテナンスの負荷が大きい •B.パーティションテーブルの採用 メリット ・現状の仕組みのままデータ参照可能 ・定期的なメンテナンスの負荷が低い ・不具合やミスが起こりにくい  (DBの仕組みを使うためリスク低) デメリット ・レコード数に応じて特定操作を行った際  のメンテナンスの時間が長くなる ・コドモンで運用実績がない 決定
  10. 24 CONFIDENTIAL - © 2022 CoDMON Inc. 24 "システム成長を止めない"ために? 常にリスクを下げる選択をする

    • いきなり切り替えない • いつでも変更前に戻せるようにしておく ➡フィーチャートグル • 必要に応じて検証期間を挟む • ユーザー影響が少ない環境・機能からリリースする コドモン コドモングリーン ph.1 出退勤データ 9,400万件 25万件 ph.2 入退室データ 7億4,000万件 1,800万件 ① ② ③ ④
  11. 27 進め方 1) 新テーブルを作成 ◦ 責務分割済みのパーティションテーブル 2) 更新系機能の更新先テーブルを変更 ◦ 現行・新テーブルの両方同時に書き込むように

    アプリケーションを変更する 3) 過去データを新テーブルに移行 ◦ 現行テーブル・新テーブルに同じデータがある状態にする
  12. 28 進め方 1) 新テーブルを作成 ◦ 責務分割済みのパーティションテーブル 2) 更新系機能の更新先テーブルを変更 ◦ 現行・新テーブルの両方同時に書き込むように

    アプリケーションを変更する 3) 過去データを新テーブルに移行 ◦ 現行テーブル・新テーブルに同じデータがある状態にする 4) 参照系機能の参照先テーブルを変更
  13. 33 念のため、同時書き込み処理だけをカナリアリリース • 影響を抑えつつ対処の妥当性を検証 ◦ 引き続き、フィーチャートグルですぐ停止できる状態 • 重複データが発生しても値が一致することを確認 • 今度こそ

    現行テーブルと新テーブルに同じ値が書き込まれるはず! そして、改めて入退室データ移行! • 移行結果検証の結果は、問題なし ➡ 入退室データの移行も完了! 同じ轍は踏みたくない!入退室データの移行検証
  14. 36 "ベイビーステップでリリースする"とは? ウォーターフォール的な流れ • がっつり対象機能調査 • テスト計画 • プログラム修正 •

    がっつりテスト実施 • リリース計画 • 本番リリース 要件定義 設計 開発 テスト リリース
  15. 39 参照先テーブル切り替えの進め方 比較検証期間を設けて細く長く切り替えていこう! • テストはハッピーパスのみ • 動いているものの中で検証する ◦ 現行テーブルと新テーブルの両方からデータ取得 ◦

    結果セットを比較して不一致の場合にログ出力 ※ パフォーマンス影響を考慮して件数が少ない場合のみ アプリ上は現行データを返している ➡ ユーザー影響なし
  16. 47 実際、どんな単位でリリースしていたのか 例 • 登降園のdriver差し込み • 登降園の 重複データのテスト追加 • 出退勤の更新ロック対応

    • トランザクションを入れる • 出退勤一覧画面APIのテスト追加 • 出退勤一覧画面APIのデータ比較検証追加 • 出退勤一覧画面APIの参照先テーブルを切り替える メソッドアウトするだけ テスト足しただけ(影響なし) 制御入れただけ テスト足しただけ(影響なし) 検証するだけ 分岐するだけ
  17. 48 ほぼ毎日リリース • GitHub の contributions も増えました • 半年間 で

    約1年分の contributions 実績 【通常モード】 【テーブル分割集中期間】 マージ ≒ リリース
  18. 49 CONFIDENTIAL - © 2022 CoDMON Inc. 49 "リリースを小さく"とは? 一気に作りきらない

    • メソッドアウトするだけ • テストを追加するだけ 修正の前にログを活用して検証してもよい • パラメータ追加しようとしている値が取れているか検出するだけ • それは使われているブロックなのか検証するだけ 細く長く変更していくという選択肢 • このテーブル分割・移行作業も主に2名で進めてきた フィーチャートグルを活用