先日ご報告した「CMS側の反応スピードが遅い」件（LRCC-2386）の原因究明レポートに続き、 増加したデータ量に対応しつつ、貴社が当初ご要望された データの鮮度もしっかり担保する形での 中長期改善案をご提案いたします。
改善案をご提案する前に、まず経緯を正しく整理させていただきます。
CMS構築時、貴社より「ダッシュボードは常に最新のデータをリアルタイムで表示してほしい」とのご要望をいただきました。 ご要望に最も忠実な形で応えるべく、画面を開く度に データベースへ直接クエリを実行する方式を採用いたしました。
この判断は正しいものでした: 当時はデータ量が小さく、重いクエリでも1〜2秒で完了し、何より「絶対的な精度の保証」が最優先事項でした。
運用1〜2年経過し、取引系テーブルが大幅に成長:
video_viewテーブル約500万行、
transactionテーブル約300万行。
同じクエリが現在は約1.5億行のスキャンを要し、 画面表示に60秒以上かかっている状況です（LRCC-2386詳細レポート参照）。
毎リクエストごとに直接クエリする方式から、2段階のバッファを挟む方式へ。 これは大規模アナリティクスダッシュボードでは事実上のデファクトスタンダードです。
高速メモリ上にクエリ結果を一時保存します。リクエストはまずキャッシュを確認し、 ミスまたは期限切れ（TTL 5〜10分）の場合のみデータベースへアクセスします。
日次集計テーブル（例: partnership_revenue_daily）を新設し、
バックグラウンドのcronジョブが15〜30分毎に更新します。
複雑な集計クエリが小さなSUM計算に置き換わります。
大規模アナリティクスダッシュボードでは、ほぼ例外なくこのアーキテクチャが採用されております。 応急処置ではなく、システム設計の教科書にも記載される正式なパターンです。
当初の貴社のご要望「データはリアルタイムであるべき」は完全に妥当なものでございました。 本提案では、データ鮮度をできる限りリアルタイムに近い状態で維持する仕組みも併せてご用意いたします。
段階的なリリースとし、各フェーズで明確な改善効果を確認いただけます。
CMS内の重い5エンドポイント (収益、統計、会員一覧等)にキャッシュ層を追加します。 初回アクセス時はキャッシュミスのため従来通り60秒、10分以内の2回目以降は <100ms となります。
*_daily形式の集計テーブルを新設し、
既存のcron-job-serviceワーカで15分毎に更新します。
重いクエリでも初回から < 1秒に短縮されます。
各集計画面に「Refresh now」ボタンと「Updated X minutes ago」ラベルを追加します。 管理者が明示的に最新データを取得できる手段を提供し、特殊なリアルタイム要件の1%のケースもカバーします。
本ご提案について、以下の3点をご検討いただけますと幸いです:
ご不明な点、ご懸念、追加でご確認されたい事項などございましたら、 お気軽にお申し付けくださいませ。本件について別途お打ち合わせのお時間をいただけますと幸いです。
何卒よろしくお願いいたします。
customer-report-jp.html| 現状応答時間 | 60秒+ |
| フェーズ1完了後 | 100ms (2回目以降) |
| フェーズ2完了後 | < 1秒 (初回から) |
| データ鮮度 | 5分以内 |