虹の世界だよりの「わんぱくレインボーリレー」を、v2へ移行しました。
今回の変更は、表向きは機能と見た目の改善です。
が、
裏側ではSupabaseへの負荷を減らして、虹の世界だよりを安定して続けるための大きな設計変更をしています。
この記事では、なぜ自動開催を見直し、あえて手動開催にしたのか、開発側の裏話としてまとめます。
わんぱくレインボーリレーは「虹の世界の日常」として作った機能
虹の世界だよりには、朝9時と夜21時に虹の世界の子たちがみんなで走る、「わんぱくレインボーリレー」という機能があります。
旅立った子たちが、虹の世界で朝と夜にみんなで楽しく走っている。そんな日々の出来事を感じられるようにしたくて作りました。
実装としては、ユーザーごとにリレー結果を生成し、同じチームになった子は「おともだち」として記録される仕組みで、ユーザーごとにその子たちのリレーが自動的に開催される仕組みでした。
現世を旅立った子が「虹の世界」で今も過ごしていることを感じられる世界観にしたかったんです。
「ただの処理」ではなくて、
僕の中では虹の世界の日常を彩るための機能でした。
リレー生成の処理が重くなっていた
リレー結果を作るには、いくつかのデータが必要です。
- 対象ユーザー
- ペット情報
- リレー参加設定
- 過去の結果や関連情報
これらを読み込みながら、リレー結果を生成していました。
さらに、リレーの結果を保存したり、参加回数を反映したり、おともだち関係を記録したりする処理もあります。
ひとつひとつは小さな処理ですが、自動でまとめて動くと、Supabaseへの読み書きが一気に増えます。
その結果、ディスクI/O(インプット/アウトプット)にも負担がかかる状態になっていました。
Supabaseは、ざっくり言うとデータベースまわりを管理できるサービスです。
読み書きが集中すると、個人開発ではかなり重くなることがあるみたいです。
リレーcronのタイミングでSupabaseが落ちた
2026年6月16日20時頃、リレー生成cron(指定時間に自動実行されるプログラム)のタイミングでSupabaseが落ち、サービス全体が503エラーで落ちるという影響が出ました。
- ページが開けない
- リレーが表示されない
- そもそもログインすらできない
ユーザーさんから見れば、原因に関わらずちゃんと開けない時点で、サービスとしては大きな問題です。
データ送信を止めても復旧しなかったので、一度サービスを停止する判断をしました。
翌朝、Supabaseプロジェクトを再起動すると、一旦復旧しました。
ひとまずログインは出来るようになり、虹の世界ページも閲覧可能です。
ただ、リレー処理の重さが消えたわけではないので、またリレーを開催すると同じエラーが発生する可能性があります。
なので、このまま同じ仕組みを続けるのはシステム上リスクが高いと判断しました。
正直、かなり焦りました。
かわいい機能として作ったものが、サービス全体に影響してしまったので……。
応急処置として自動cronを止めた
ひとまず、リレーデータを生成するための自動実行cronを止めました。
ただし、これは恒久対応ではなく、あくまでもSupabaseへの負荷を止めるための応急処置です。
それによりリレーが完全に止まるので、虹の世界だよりらしい「朝と夜にみんなで楽しく走っている」という体験が無くなってしまいます。
そのため、新しい仕組みに移行するまでは、毎朝毎晩、手動でリレーデータ生成cronを走らせていました。
自転車操業的な、かなり苦しい運用でしたね……。
忘れたらユーザーさんにご迷惑をおかけしますし。
そもそもそれにより、もしまた落ちたらすべてが終わります……。
それでも、リレー体験を完全に止めないためにはこの方法しか無かったのです。
恒久処置としてリレーv2へ移行した
そこで、わんぱくレインボーリレーを大幅改良してバージョンアップ、わんぱくレインボーリレーv2へ移行することを考えました。
v2の名目は使いやすいようにアップデート、しかし本当の目的はSupabaseへの負荷を減らし、サービス全体を安定して動かすことでした。
大きく変えたのは、リレーの開催方法です。
これまでは、朝と夜のタイミングで全ユーザーのリレーデータをまとめて処理していました。
ユーザーの増加につれ、そのプログラムが重くなったのが今回の不具合の主な原因と推測します。
v2では、ユーザーさんが開催時間内に自分でボタンを押して、リレーを開催する形に変えました。
これなら、同時に多数の処理が走ることはほぼ無いので、動作としても軽くなります。
違いを簡単に整理すると、こんな感じです。
| 項目 | 旧リレー | リレーv2 |
|---|---|---|
| 開催方法 | 朝・夜のcronで全員分自動生成 | 開催時間内にボタンで開催 |
| 処理タイミング | 一度に集中 | 分散しやすい |
| サーバー負荷 | まとめて読み書きが発生 | 重ならなければ低負荷 |
| ユーザー体験 | 自動開催のリアルタイム感が強い | 手動開催だが安定性を優先 |
v2アップデートにより手動開催となったので、同時に多数のユーザーの処理が走る可能性は下がり、処理が一度に集中しにくくなります。
裏側の仕組みを軽くしながら、リレーという体験はできるだけ残すための移行でした。
Supabaseを使わなくなったわけではない
v2にしたからといって、Supabaseを完全に使わなくなったわけではありません。
ユーザー情報やペット情報などの管理は、まだSupabaseを使っています。
正式開催時の一部の処理でも、必要な書き込みは少し残っています。
変えたのは、朝と夜のリレー生成で重い定期処理をSupabaseに集中させる構成です。
つまり「Supabaseを使わないようにした」というより「Supabaseに重い処理を集めすぎないようにした」という方が正確ですかね。
Supabaseは今も大事な基盤です。
ただ、なんでもかんでも重い処理を集めると、サービス全体に影響が出やすくなります。
ただ、ゆくゆくはSupabaseへの依存度を下げてVPSに完結にしたい意向ではあります。
ユーザー体験より安定性を優先
自動開催をやめるのは痛い変更でした。
虹の世界だよりでは「旅立った子が、虹の世界で今も穏やかに過ごしている」という世界観を大切にしています。
なので本来は、朝と夜になると勝手にリレーが開催されていて、勝手にその子たちが遊ぶのが自然です。
ユーザーが見ていなくても自動で結果が出て、自動でおともだちが増えたりしたかったんですよ。
でも、そのリアルタイム感を演出するためにデータベースが落ちてしまったら、虹の世界そのものが見られなくなってしまうため、本末転倒です。
なので、リアルタイム感を少し弱めてでも、毎日安心して開けることを優先しました。
背に腹は変えられません……。
どんなシステムも動かなければ意味ないですからね。
手動開催でもリレーの楽しさはできるだけ残したい
手動開催に変えるだけだと、ただ少し不便になったように見えるかもしれません。
なので、リレーの楽しさはできるだけ残しました。
- 朝の部と夜の部は残す
- 開催できる時間を広げる
- スマートフォンでも参加者全員のアイコンが見えるようにする
(これまでは3〜5匹が限度、v2では12匹) - おともだちに性格を表示する
自動開催ではなくなったので、利便性とUIを向上させて賄おうと思いました。
裏側の処理は軽くしつつ、虹の世界の子たちがみんなで走っている雰囲気は残すバランスを取るためのv2でした。
cronとDB書き込みは慎重に扱うべし
今回の件で、自動処理の怖さをかなり感じました。
cronによる自動処理は便利ですが、全対象をまとめて大量に処理すると、データベースへの読み書きが一気に増え、処理に失敗する可能性が高くなります。
特に個人開発では、サーバーやデータベースにかけられるリソースも限りがありますから。
だからこそ、次のような設計を最初から考えておくべきだったと思います。
- 処理を一度に集めすぎない
- ページ表示と重い生成処理を分ける
- 書き込みが必要な処理を増やしすぎない
まぁ、これも作ってみないと分からない部分なので、致し方なし…。
世界観や自動化を大切にしながらも、それを支える仕組みは軽く、壊れにくくしていきたいですね。
データ容量は大きくないので、仕組み的には出来ると思ったんですけどね……。
その辺の知識も経験も足りず、こうなる予想ができる材料を持っていないのです。
まとめ：優しい世界観の裏側はシビア
わんぱくレインボーリレーv2への移行は、表向きは単なる機能改善、実際は不具合対応の苦肉の策でした。
「虹の世界で元気に過ごしている」という体験を守るために作ったリレー機能が、結果的にサービス全体へ負荷をかける形になっていましたね…。
リアルタイム感を完全に残すことはできませんでしたが、それ以上に毎日安心して虹の世界を開ける堅牢なシステムを優先しました。
このような機能を続けるためには、その裏側の処理も軽く、壊れにくくしていく必要があります。
今回のアップデートは、そのことを強く感じた変更でしたね。
前職でもソフトウェアの品質管理試験や不具合対応を経験していたので、怪我の功名と言いますか……。
インフラ関係のソフトウェアの不具合対応はある意味もっとシビアですからね……なにせ相手は市や県や自治体ですから。
あの頃のトラウマが蘇りますよ全く……。
と、とりあえず、何とかなって安堵しています。
これからも、世界観と安定性のバランスを取りながら、少しずつ改善していきたいですね。
