こんにちは！Shinonです。

DjangoやRenderを使ってポートフォリオサイトを公開し、順調に運用していると思っていた矢先……ある日突然、僕のサイト（shinotech78.com）が「503 Service Unavailable」を吐いて応答しませんでした。

今回は、僕が個人開発でハマった「無料枠データベース（Neon）の通信量パンク事件」の全貌と、その原因だった「Base64の罠」、そしてCloudinaryとSupabaseを使ったアーキテクチャ変更でサイトを爆速化させた解決策を共有します。

ブログ機能などを自作している初心者〜中級者の方は、明日は我が身かもしれません。ぜひ最後まで読んでみてください！

 

1. 悲劇の始まり：突然の503エラーとNeonの通信量制限

ある日、自分のサイトにアクセスすると画面は真っ白。無慈悲な「503エラー」が表示されていました。

慌ててRenderのログを確認し、連携していたデータベース（Neon）のダッシュボードを開くと、そこには絶望的な事実が。なんと、Neonの無料プランの上限である「ネットワーク転送量（5GB/月）」をあっという間に使い切り、接続が完全にシャットアウトされていたのです。

「個人開発のブログで、ひと月に5GBも通信するわけがない……」

原因は身近で、僕自身の「無意識の行動」に潜んでいました。

 

2. 犯人は「画像の直接コピペ」、Base64の罠

調査の結果、すべての元凶はブログ記事を執筆する際に使っていたリッチテキストエディタ（TinyMCE）にありました。

僕は記事を書くとき、スクリーンショットなどの画像を「エディタに直接コピペ」して貼り付けていました。実はこれ、裏側では画像ファイルとして保存されているわけではなく、「Base64」という形式に変換されていたのです。

Base64とは？（数百万文字の暗号）

Base64とは、画像などのバイナリデータを「文字の羅列（テキスト）」に変換する技術です。 これの何がヤバいかというと、たった1枚の画像をコピペしただけで、約200万〜300万文字にも及ぶ巨大な暗号のような文字列に変換され、それがそのままデータベース（PostgreSQL）のテキストカラムに保存されてしまうのです。

つまり、読者がブログの記事を1ページ開くたびに、データベースから「数百万文字の巨大なテキストデータ」を引っ張り出して通信していたことになります。記事に画像を3枚貼れば、およそ1000万文字の通信です。

これでは、無料枠の5GBなんて一瞬で溶けてしまうのも当然でした。

 

3. 解決策：データベースの引っ越しとCDNの導入

原因が分かれば、あとは技術で殴る（解決する）だけです。通信量を劇的に減らし、サイトのアーキテクチャを根本から見直すことにしました。

① データベースの引っ越し（Neon → Supabase）

まずはロックされてしまったNeonからなんとかデータを救出（ダンプ）し、接続がより安定しているSupabaseへ移行しました。Supabaseも強力な無料枠を提供している優秀なPostgreSQLホスティングサービスです。

② 画像管理のCDN化（Cloudinaryの導入）

ここからが本題です。「画像を直接エディタにコピペする」という最悪の運用をやめ、画像専用のホスティングサービス（CDN）であるCloudinaryを導入しました。

運用フローを以下のように変更しました。

  1. ブログに載せたい画像は、まずCloudinaryへ手動でアップロードする。

  2. Cloudinaryから発行された「画像URL」をコピーする。

  3. エディタ（TinyMCE）には、その画像URLだけを貼り付ける。

 

4. 圧倒的な改善効果：文字数は数百万から「80文字」へ

このアーキテクチャ変更による効果は、まさに劇的でした。データベースに保存されるデータ量と通信量の違いを見てください。

 

  • 【改良前（Base64）】：1枚あたり約3,000,000文字（通信量が爆発、DBがパンク）

  • 【改良後（Cloudinary URL）】：1枚あたりたったの約80文字（DBの負担はほぼゼロ）

 

データベース側は「https://res.cloudinary.com/.../image.png」という短いURL文字列を返すだけになり、実際の重い画像データはCloudinaryの強力なサーバーが配信してくれるようになりました。

 

おまけの恩恵：自動WebP化でサイトが爆速に！

さらに、Cloudinaryを使うことで最高の恩恵がありました。発行されたURLの途中に q_auto,f_auto というパラメータを付与するだけで、読者のブラウザ（スマホやPC）に合わせて、自動的に画質を最適化し、最軽量なフォーマット（WebPなど）に変換して配信してくれるのです。

結果として、ネットワーク制限の恐怖から解放されただけでなく、ブログ全体の画像読み込みスピードが爆速になりました。

 

5. まとめ：エディタへの画像コピペは絶対にやめよう

今回の503エラーでの挫折を通して学んだ最大の教訓はこれです。

「リッチテキストエディタへの画像の直接コピペ（Base64化）は、初心者が陥りやすい最悪の罠」

個人開発でDjangoなどのフレームワークを使い、無料枠のPaaS（Render等）やDB（Neon, Supabase等）を活用するなら、「テキストデータ」と「画像データ」の保管場所は絶対に分けるのが鉄則です。

最初はエラー画面を見て青ざめましたが、こうしてアーキテクチャを見直し、CDN（Cloudinary）の強力さを身をもって体験できたのは、エンジニアとして非常に大きな成長に繋がりました。

もしあなたが自作ブログで画像を直接コピペしているなら、今すぐデータベースの容量と通信量を確認してみてください。そして、手遅れになる前にCDNを活用した画像配信に切り替えることを強くおすすめします。