dev を普段使いにしたら、dev を安くする戦いになった — 個人で多サービスのコンピュートを振り分ける
本番ではなく dev 環境を普段使いにしたら、コストの重心が dev 側に移った。dev を本番の「安い使い捨てミラー」にするために、環境やサービスごとにコンピュート基盤を振り分けた話。一番効いたのは「dev では計算させない」こと。ただし技術的制約が下限を決める例外もある。
はじめに
個人開発のサービス群を、自分は最近本番ではなく dev 環境を普段使いにしている。動作確認や回帰検証で日常的に触るのは dev の方だ、という運用にした。
すると、コストの重心が変わる。よく言われるのは「本番は本気、開発は安く」だが、自分が一番アクセスするのは devになったので、dev をどれだけ安く回せるかが効いてくる。本記事は、dev を本番の「安い使い捨てミラー」にするために環境やサービスごとにコンピュートを振り分けた話。単一のテクニックではなく、いくつかの判断の集合だ。
一番効いたのは「dev では計算させない」
コンピュートを安くする前に、そもそもdev で重い計算を回さないのが一番効いた。
たとえば資産・株価管理サービスには、定期実行のバッチが何本かある。そのうち AI で集計や採点を回す重いもの——日次サマリーの生成や、予測精度の評価——を dev でもわざわざ回す意味はあるか？と考えて、答えは No だった。dev が欲しいのは「計算した結果」であって、計算そのものじゃない。
そこで dev-sync という仕組みを作った。本番の DynamoDB のデータを dev にコピーする専用の基盤だ。これがあるので、dev では該当バッチのスケジュールを止めている（実際、summary・evaluation 系の EventBridge Rule は dev で enabled: false）。二重に計算させず、無駄な実行コストも消える。dev は本番の「仕事」を再現するのではなく、「状態」を映すだけでいい——これがこの運用の背骨になっている。
コンピュートは「検証に足りる最低限」に落とす
そのうえで、実行基盤そのものも dev では軽い方に振り分ける。ポイントは一律に落とさないこと。「本番でそれが要る理由」がサービスごとに違うので、その理由を dev が落とせるかどうかで決める。
- リブトーク：音声合成に VOICEVOX を使う都合上、常駐コンテナが要るので ECS は必須（Lambda には載せられない）。ただし dev はあくまで検証用なので Fargate Spot で十分。本番は、合成中にユーザーを中断させたくないのでオンデマンドを維持する。「Spot の中断を許容できるか」が dev と prod の分かれ目。
- Portal：本番は速度が要る。理由は明確で、AdSense の審査・評価で表示速度が効くため、prod は ECS（+ ALB + CloudFront）にした。dev はその速度が要らないので Lambda + Function URL に落としている。
- AZ の使い方：ネットワーク自体は環境ごとに 1 本の共有 VPC で、dev にも 2 つの AZ にサブネットを用意してある。そのうえで、可用性の要らないサービスは dev では 1 つの AZ しか使わない（Lambda 系や Portal の dev がこれ）。ただしリブトークだけは dev でも 2 AZ を使う。VOICEVOX で ECS + 専用 ALB が必須で、ALB は最低 2 つの AZ の Subnet を要求するため、ここは dev でも 1 AZ に落とせない。技術的な制約が「どこまで削れるか」の下限を決めている好例だ。
一方で、単純な Web サービス（auth・tools 等）は dev と prod で基本同じ形にしている。落とす理由が無いところまで無理に分けると、かえって管理が増える。「本番に固有の要求があるサービスだけ」分ける、という線引きだ。
振り分けの判断軸
こうして並べると、振り分けの軸は「dev を安く」ではなく、「本番のこの要求を、検証用の dev は落とせるか？」だと分かる。
- 速度（Portal → AdSense）→ dev は落とせる → Lambda
- 無中断（リブトークのユーザー体験）→ dev は落とせる → Spot
- 計算結果（株価の AI バッチ）→ dev は再計算不要、コピーで足りる → スケジュール停止 + dev-sync
- 可用性 → 落とせるなら dev は 1 AZ しか使わない。ただし ALB を持つサービス（リブトーク）は最低 2 AZ が必須で、ここは落とせない
技術的制約で下限が決まるところ（VOICEVOX → ECS → 専用 ALB → 最低 2 AZ）はあるが、その制約の中でも「検証に足りる最低」まで落とす、というのが一貫した動きだ。
おわりに
この運用が成立するのは、個人で複数サービスを回していて、かつ自分が dev を普段使いしているからだ。dev のコストが常時のしかかるからこそ、「安い使い捨てミラー」に振り切る意味がある。
一番の学びは、コンピュートの単価を下げること以上に、「dev に本番の仕事をさせない」（結果をコピーして計算を省く）という発想だった。dev は本番の劣化コピーである必要はなく、本番の状態を映す薄い鏡でいい。そう割り切れると、どこを落としてどこを残すかの判断がぶれなくなる——落とせないのは、ユーザー体験や技術的制約という「本番に固有の要求」が残っているところだけだ。