🛠️

CentOS6短縮URLをK8sに移した夜、キャッシュデータ移行なしで50podスケールした失敗談

に公開
2025/12/18
Docker
Redis
Rails
Kubernetes
マイグレーション
tech

当時年収400万の底辺IT派遣エンジニアが経験したリアル失敗談です

2025年現在も現役の短縮URLサービスを底辺派遣エンジニアがたった一人で全部やった結果、寿命が5年縮んだ話。

旧環境（2015年の化石）

  • CentOS 6（EOL 2020年）
  • VM57台（web50台）
  • Ruby 2.2 → 3.0
  • Rails 4.2 → 6.1
  • Passengerインストーラー版
  • memcached（データ移行なし方針）

新環境（2022年）

  • SaaSの安いK8s（2cpu-4GB guaranteed）
  • web 10→50pod（HPA CPU20%）
  • Redis Cluster（SaaS版がドラフトすぎて自前VM残駆動）
  • MariaDB Galera

地獄ポイント全部盛り（派遣一人で対応）

  • ログローテ → rufus-schedulerで日付ローテート

  • filebeat → 1pod 2コンテナ（daemonSet禁止）

  • DB → Rails6.1でstrict: false知らずに1回目全死

    production:
  variables:
    sql_mode: traditional
    strict: false   # これ知らなかったら死ぬ

  • 負荷試験 → Gatlingで5000RPS（キャッシュあり）／1500RPS（キャッシュなし）実施済み
    → キャッシュデータ移行しない方針だったので「キャッシュなし」も想定していた

  • 本番リリース当日
    1回目（2:00）：strictで全死 → ロールバック
    2回目（4:30）：成功……からのHPA即50pod（原因：Redis接続先切り替え忘れ）
    → キャッシュヒット率0%でDB直撃 → 12分後にFeature Flagで救出

  • ローカル開発環境 → Docker Desktop有料化 → Colima移行 → alpine全滅 → slimに統一

教訓（血文字）

  • リファクタ？ 0（触ったら爆発するから）
  • Feature Flagは命
  • キャッシュは命
  • 年収400万でも5000RPSは守れる（震え声）

今も毎晩CloudWatchグラフを拝んでる。
誰も触れないコードが本番で動いてる。
俺は派遣だから責任取らなくていいのが唯一の救い。

（現在進行形で生きてる）

Discussion