【ITニュース解説】My SaaS Infrastructure as a Solo Founder

SaaS（Software as a Service）と呼ばれるWebサービスを、たった一人で開発・運用するエンジニアが、その裏側にあるシステム構成、すなわちインフラストラクチャーについて公開した。この事例は、特にこれからシステムエンジニアを目指す人々にとって、現実的で堅牢なシステムをいかに効率的に構築・運用するかの優れた手本となる。対象のサービスは「UserJot」という、企業がユーザーからのフィードバックを収集・管理するためのツールであり、月間5万人以上のユーザーが利用するなど、決して小規模ではないトラフィックを処理している。

このシステムの構成は、ユーザーが直接目にする「フロントエンド」と、裏側でデータを処理する「バックエンド」に大別される。フロントエンドは、Cloudflare Workersというサーバーレスプラットフォーム上で動作している。サーバーレスとは、開発者がサーバーの存在や管理を意識することなくプログラムを実行できる仕組みで、アクセス数に応じて自動的に処理能力が調整される利点がある。ここでは、サービスの紹介ページなどの静的な部分はAstroという技術で、ユーザーが操作するダッシュボードなどの動的な部分はTanStack Startという技術で構築されており、これらが全てCloudflareの世界中に分散したエッジサーバー上で実行される。これにより、世界中のどこからアクセスしても、ユーザーの最も近くにあるサーバーから素早く画面が表示されるようになっている。

一方、アプリケーションの本体であり、データの保存や複雑な処理を担うバックエンドは、ドイツのホスティング会社Hetznerの物理サーバー上に構築されている。ここでは、Node.jsとTypeScriptで書かれたアプリケーションが、Docker Swarmというコンテナ管理技術の上で動いている。コンテナとは、アプリケーションを実行環境ごと一つのパッケージにまとめる技術であり、どこでも同じように動かすことができる。そして、すべてのデータはPostgreSQLというリレーショナルデータベースに集約されている。このフロントエンドとバックエンドの構成は、GitHub Actionsという仕組みを使って自動的にデプロイされるようになっており、開発者がコードを変更すると、テストから本番環境への反映までが自動で行われる。

この構成で最も注目すべき点は、その徹底した「シンプルさ」の追求にある。特にデータベースの使われ方が特徴的だ。通常、Webサービスでは用途に応じて複数のデータベースやミドルウェアを使い分けることが多い。例えば、高速なデータアクセスが必要なキャッシュにはRedisを、非同期処理（時間のかかる処理）を実行するためのジョブキューにはRabbitMQを、といった具合だ。しかし、このシステムでは、これらの役割のほぼすべてをPostgreSQL一つで賄っている。PostgreSQLは本来、構造化されたデータを格納するためのデータベースだが、近年は機能が大幅に拡張されている。この事例では、PostgreSQLの拡張機能である「pg-boss」をジョブキューとして、「JSONB」というデータ型をキーバリューストア（キャッシュのような使い方）として、さらにはベクトル検索機能を持つ「pg-vector」を類似データの検索に活用するなど、その多機能性を最大限に引き出している。

なぜ、このように一つのデータベースに多くの役割を集約するのか。それは、一人でシステムを運用するという制約が大きく関係している。使用するサービスの数が増えれば、それぞれについて監視、バックアップ、アップデート、障害対応を行う必要が生じ、運用コストは飛躍的に増大する。システム全体の安定性は、構成要素の中で最も弱い部分に依存するため、コンポーネントを減らすことは、故障する可能性のある箇所を減らすことに直結する。この選択は、最新の流行技術を追い求めるのではなく、管理しやすく、安定して稼働するシステムを最優先するという、現実的な判断に基づいている。

また、バックエンドサーバーがアメリカ東海岸という単一の地域にしか存在しないにもかかわらず、グローバルなユーザーに快適な体験を提供している点も興味深い。これを実現しているのは三つの工夫だ。一つ目は、Cloudflareのネットワークを活用して通信経路を最適化し、物理的な距離による遅延を削減していること。二つ目は、「オプティミスティックUI（楽観的UI）」という手法。これは、ユーザーがボタンを押すなどの操作をした際、サーバーからの処理完了の応答を待たずに、まず画面上では成功したかのように即座に表示を更新する技術で、体感速度を大幅に向上させる。三つ目は、ユーザーが次にクリックしそうなリンク先のデータをあらかじめ読み込んでおく「プリフェッチ」という技術だ。これらの工夫により、データ本体が遠くにあっても、ユーザーは遅延をほとんど感じることなくサービスを利用できる。

この事例は、流行りの技術であるサーバーレスをフロントエンドに採用しつつも、バックエンドには従来のサーバー構成を選ぶという、適材適所の判断も示している。フロントエンドのように状態を持たない処理にはサーバーレスが適しているが、データベースとの接続を常に維持したり、長時間にわたるバックグラウンド処理を行ったりする必要があるバックエンドには、安定して稼働し続ける従来型のサーバーの方が適している。さらに、AWSのような大手クラウドが提供するマネージドサービスを使わず、自前でサーバーを管理する「セルフホスティング」を選択している点も特徴だ。これには、コストが利用量に比例して増えることなく予測可能であることや、データベースの細かな設定や拡張機能を自由に使えるというメリットがある。もちろん、その代わりにバックアップやアップデートといった管理の手間は自身で負う必要がある。

この個人開発者の経験は、システム構築における数多くの教訓を教えてくれる。まず、PostgreSQLのような「退屈」とも言われる枯れた技術が、実は非常に多機能で強力なツールとなり得ること。そして、システムの構成要素を減らし、シンプルさを保つことが、特にリソースが限られた状況下では極めて重要であること。また、サーバーの性能に十分な余裕を持たせておくことは、予期せぬアクセス増に対する備えとなり、精神的な安定にも繋がる。このシステム構成は、将来的に数百万ユーザー規模までスケールする可能性を秘めており、多くのSaaSにとって十分すぎるほどの能力を持っている。最新技術の導入に目を奪われがちだが、目の前の課題を解決するために最もシンプルで堅牢な方法を選択することこそが、優れたエンジニアリングの本質であることを、この事例は示している。