2025/09/11 18:58 Rails on SQLite: new ways to cause outages
やっほー、ロボ子！今日のITニュースはSQLiteについてじゃ。RailsアプリでSQLiteを使うのがアツいらしいぞ！
博士、こんにちは。SQLiteですか！データベース、Redis、ファイルストレージサービスが不要になるのは魅力的ですね。
そうじゃろ？データベース接続エラーも発生しないし、Webサーバープロセスに組み込まれてるから、個別のプロセスもポートもいらない！データも単一のファイルに保存されるからの。
なるほど。でも、記事には注意点も書かれていますね。HerokuやFly.ioのような環境だと、データが消える可能性があるとか。
そうなんじゃ！コンテナ環境では、データベースが一時的なファイルシステムに保存されるから、再起動時に消えちゃうんじゃ。AWSのEBSとか、Fly.ioのVolumesみたいな永続ストレージに保存する必要があるぞ。
ふむふむ。RailsのキャッシュやActiveJobのジョブも同じSQLiteファイルに保存されるんですね。バックグラウンドジョブはどうすれば良いんですか？
バックグラウンドワーカーはWebサーバーと同じデータベースファイルにアクセスする必要があるからの。ワーカーをWebプロセスと同じVMかコンテナ内で実行するか、Webプロセス内のスレッドで実行するのが良いぞ。
スケーリングについても書かれていますね。小規模アプリケーションなら良いけど、大規模だとどうすれば？
大規模アプリケーションでは、従来の水平スケーリングじゃなくて、CPUコアとRAMをたくさん積んだ単一のサーバーへの垂直スケーリングが必要になるんじゃ。
同時書き込みの問題もあるんですね。競合が発生する可能性があると。
そうじゃ！Write-Ahead Log (WAL) を使って、書き込みを順次処理すると良いぞ。でも、WALを使うとデータベースが複数のファイルに分割されるから、バックアップと復元の戦略を考えないといけないんじゃ。
データベースファイルを分割するのも一つの手みたいですね。システムごととか、アクセスパターンごとに分けるとか。
そうそう！顧客ごとにSQLiteデータベースファイルを分割するアプリケーションもあるらしいぞ！
単一サーバーだと、サーバーがダウンしたら全部ダウンしちゃいますね。
ローカルプロキシを使って複数のプロセスをバックエンドとして追加することで、ロードバランシングをするんじゃ。でも、アプリケーションは1つの地理的な場所でのみ実行できるぞ。
データベースの移行はどうすれば良いですか？
sequel gemとかduckdbコマンドラインツールを使うと、SQLiteと他のデータベース間での移行が楽になるぞ。
バックアップとレプリケーションには、LitestreamやLiteFSが使えるんですね。
LitestreamはWALのエントリをS3互換のファイルストアに転送して、バックアップと復元を簡単にするんじゃ。LiteFSはFUSEを使ってSQLiteデータベースのレプリケーションを提供するけど、データの不整合やデータ損失のリスクがあるから注意が必要じゃ。
Feed Your Emailというサービスでは、SQLiteを使ってメールサブスクリプションをRSSフィードに変換しているんですね。月間100万リクエストを処理して、Fly.ioでのホスティングコストが約14ドル/月とは、すごい！
そうじゃろ？SQLite、侮れないぞ！ところでロボ子、SQLiteって、石器時代のデータベースって意味らしいぞ！
えっ、そうなんですか？
うそじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。