『本文が全部消えました』を撲滅〜18年続くサービスに変更履歴機能を実装〜

『本文が全部消えました』を撲滅〜18年続くサービスに変更履歴機能を実装〜 Tech Talks ! @Studio #1 田中湧大 - @Romira915

田中湧大自己紹介株式会社PR TIMES 事業ユニット第一開発部ソフトウェアエンジニア（24卒入社） @Romira915 @Romira915
主にバックエンド仕事ではPHP, 趣味でRustを書く

PR TIMES / エディター PR TIMESは18年続く歴史あるサービス 2023年12月にエディターをリニューアルしUI/UXが大きく変わるそのエディターに変更履歴機能を実装

なぜ変更履歴が必要だったか

「お客様から『同時編集してたら本文が全部消えました』とお問い合わせです」「エンジニアの方、対応お願いできますか？」「わかりました、スナップショットから復元して対応します」とある日のSlackのやり取り

というやり取りが数件発生

問い合わせのたびにエンジニアの工数がかかっていた・・お客様からいつ頃、どのリリースが消えたか正常に保存されていたタイミングはいつかヒアリングから該当時刻を特定してAWS RDSの機能「Point-in-time recovery」を使ってスナップショットから復元当然本番DBを全て丸ごと復元するので時間がかかる復元したDBから本文を取ってきて本番へ復元 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html

お客様は待たされ、エンジニアの時間も奪われる・・・

そこで変更履歴機能を実装してお客様自身で復元できるように

何を？どのタイミングで？いつまで？

何を保存するか？タイトル・サブタイトル・本文画像（最大30枚 × 10MB） PDFなどのドキュメントファイル（最大４つ × 5MB）メタデータ（ビジネスカテゴリ、キーワード、位置情報、配信先）プレスリリースを構成する要素

何を保存するか？プレスリリースを構成する要素今回は「本文が消えた」という課題を解決するために本文に関わる要素のみを履歴保存の対象にするタイトル・サブタイトル・本文画像（最大30枚 × 10MB） PDFなどのドキュメントファイル（最大４つ ×
5MB）メタデータ（ビジネスカテゴリ、キーワード、位置情報、配信先）

画像を保存することによる課題履歴保存する度に画像をアップロードして保存するとレスポンス低下に繋がる → 負荷・高頻度に呼び出せない懸念ファイルパスだけを保存することに画像（最大30枚 × 10MB） PDFなどのドキュメントファイル（最大４つ ×
5MB）

履歴保存する度に画像をアップロードして保存するとレスポンス低下に繋がる → 負荷・高頻度に呼び出せない懸念ファイルパスだけを保存することにプレスリリースを配信すると使われていない画像は全て削除される → 削除された画像が復元できなくなる！画像を保存することによる課題そこで、履歴を保存する対象の状態を「下書き」
「予約配信」に限定

どのタイミングで保存するか？自動保存API呼び出し間隔現在：3秒ごと変更履歴：2分に1回過去1ヶ月の自動保存の頻度を分析してこの頻度で問題ないかを調査

どのタイミングで保存するか？１ヶ月あたりの保存回数：約820,000（開発開始当時）１記事あたりの保存回数：ほとんどのプレスリリースが20回以下月約2万件のINSERT

どのタイミングで保存するか？２分に１回復元する前保存ボタンを手動で押したとき最終的に以下のタイミングで履歴を保存することにただし、前バージョンと差分がない場合は保存しない

テーブル設計の工夫

正規化されていないテーブルプレスリリースを管理する１つのテーブルに全ての情報が集約画像だけで60カラム SQLの見通しが悪く、拡張性が乏しい releasesテーブル 10回以上スクロールしないと全体が読めない！

正規化した履歴用テーブル画像枚数の上限変更が必要になった場合も容易に SQLが管理しやすく NULL列の無駄な領域が発生しない　（画像３枚なら３レコード） bulk insertでシンプルに

【余談】パーティションを切ったテーブルに外部キーを設定しようが断念した話

仕様として直近30日以内のデータのみを表示する古いデータは定期的に削除するパーティションテーブルを採用し、月単位でテーブルを分割バッチ処理でテーブルを定期的にDROP パーティションテーブルを活用

release_history_imagesに外部キーを張る外部キー自体は作成できる

release_history_imagesに外部キーを張る月次のパーティションテーブルを作り、保存期間がすぎたら削除することを考える外部キー制約によりDROPできない外部キーは貼らない方針で行う

履歴から復元するフローをどうするか？

復元フローの選択方法１ → 復元処理APIを実装（バックエンドで復元を行う）方法２ → 復元処理はフロントエンド（State更新）保存は既存の保存用APIを叩く

方法１復元処理APIを実装 PROS CONS APIが独立しているため、復元機能に関するAPI監視や、利用数の追跡が容易 APIをCallするだけなのでフロントエンドが簡素になる APIを実装する必要があるため方法２と比べて工数が上がる「保存」という同じ処理が複数存在することになる

方法２復元処理はフロントエンド（State更新）　　　　　保存は既存の保存用APIを利用 PROS CONS 保存APIを再利用できるため工数削減保存フローを統一できるためバグが発生しにくい文字数制限を超えた履歴も柔軟に復元可能（Stateのみ更新、保存はユーザー判断）復元機能を利用したログ情報を保存するAPIを実装する必要がある
フロントエンドのState更新 → APIリクエストの流れになり複雑度が上がる

方法２復元処理はフロントエンド（State更新）　　　　　保存は既存の保存用APIを利用保存APIを再利用できるため工数削減保存フローを統一できるためバグが発生しにくい文字数制限を超えた履歴も柔軟に復元可能（Stateのみ更新、保存はユーザー判断）復元機能を利用したログ情報を保存するAPIを実装する必要があるフロントエンドのState更新 →
APIリクエストの流れになり複雑度が上がる両者を比較した結果、方法２を採用し実装 CONS PROS

まとめ実装後の効果リリース後本文消失のお問い合わせは1件のみ DBから復元するエンジニアの対応時間もほぼ０にやったこと既存APIを活用しながら変更履歴機能を実現レガシーなテーブルはそのまま、履歴テーブルで正規化を実現仕様をシンプルに絞り込み、3ヶ月で完遂

『本文が全部消えました』を撲滅〜18年続くサービスに変更履歴機能を実装〜

『本文が全部消えました』を撲滅〜18年続くサービスに変更履歴機能を実装〜

Yudai Tanaka

Other Decks in Programming

Featured

Transcript