開発会社から出てきた構成図に、四角が5つ並んでいる。アプリケーション、PostgreSQL、Redis、ジョブ実行基盤、全文検索エンジン。どれも妥当な選定に見えます。
引っかかるのは納品後です。この構成を運用するには、5つそれぞれについて監視項目を決め、バックアップを取り、バージョンアップを追い、障害時に切り分けられる人が要ります。社内にその人がいない場合、保守契約が切れた瞬間に誰も触れないシステムになります。
技術選定の議論は「性能が出るか」で行われがちですが、中小規模のシステムで先に効いてくるのは「壊れたとき誰が直せるか」です。ここを起点に、構成を減らす方向の判断ができるかを整理します。
ミドルウェアを1つ足すと、何が増えるか
「Redis を入れる」という判断のコストは、サーバー費用だけではありません。実際に増えるのは次の作業です。
- 監視の対象が1つ増える。 何を「正常」とみなすかを定義し、閾値を決め、アラートの宛先を決める必要があります。この定義がないまま増やすと、落ちても誰も気づかない構成要素になります（監視は「正常」を定義するところから始まる）
- バックアップと復旧手順が1つ増える。 キャッシュだから消えてもよい、という前提が本当に成り立つかは、実装を読まないと分かりません
- バージョンアップの追跡が1つ増える。 サポート期限とセキュリティ修正を追う対象が増えます
- 障害時の切り分けが1段複雑になる。 「遅い」の原因がアプリなのかDBなのかキャッシュなのかネットワークなのかを、それぞれのログを突き合わせて判断することになります
- 採用と引き継ぎの条件が1つ増える。 保守を別の会社に移すとき、扱える会社の範囲が狭まります
5つ目が、中小企業でいちばん効きます。 構成要素が増えるほど、次の担当者を見つけるのが難しくなります。
PostgreSQL で代替できる範囲
近年、この「足す前に考える」の受け皿として PostgreSQL の機能で済ませる選択が広く議論されています。実際に代替できる範囲は、おおむね次のとおりです。
ジョブキュー。 SELECT ... FOR UPDATE SKIP LOCKED を使うと、テーブルをそのままキューとして扱えます。複数のワーカーが同じ行を取り合わずに処理を分担できる仕組みで、実運用で使われている手法です。自前で書くのではなく pg-boss や river のようなライブラリを使うのが定石とされています。メール送信、帳票生成、外部APIの呼び出しといった典型的な非同期処理はこの範囲で足ります。
キャッシュ。 ログを書かない UNLOGGED テーブルを使うと通常のテーブルより速くなります。サブミリ秒の応答が要件でなければ、Redis を外せる場面があります。
全文検索。 PostgreSQL は全文検索の機能を内蔵しています。日本語の扱いには追加の設定が要りますが、サイト内検索や管理画面の絞り込み程度であれば、専用の検索エンジンを立てる必要はありません。
ジョブのスケジューリング。 単純な定期実行を超える要件でも、pg_timetable のような拡張で扱えます。
つまり、冒頭の構成図の四角のうち3つは減らせる可能性があります。 アプリケーションと PostgreSQL だけになれば、監視もバックアップも引き継ぎも1系統で済みます。
代替できない線はどこか
一方で、「全部 Postgres でよい」ではありません。 線は明確です。
| 求めるもの | Postgres で足りるか |
|---|---|
| 一般的な業務システムのキュー・キャッシュ・検索 | 足りる |
| サブミリ秒のキャッシュ応答 | Redis が要る |
| 秒間数百万件規模のメッセージ処理 | Kafka が要る |
| 複雑な言語解析を伴う分散検索 | Elasticsearch が要る |
極端なスループットか、極端な特化要件か。 このどちらかに該当しないなら、専用ミドルウェアを立てる根拠は薄くなります。中小企業の業務システムや受託開発の案件で、この2つに該当することはそう多くありません。
なお、Postgres をキューとして使う場合の注意点はあります。大量の行を作っては消す使い方になるため、不要領域の回収が追いつかないとテーブルが膨らみます。ライブラリを使うのは、この手の運用上の落とし穴が織り込まれているからです。 自前実装すると、動くものはすぐできますが、半年後に遅くなります。
「まとめる」側の主張も出てきている
構成を減らす方向は、データベース製品側でも動きがあります。2026年8月にリリースされた Harper 5.2 は、データベース・キャッシュ・ジョブ実行を別々のシステムに分ける構成そのものに反対する立場を取り、アプリケーションのコードとデータを同じランタイムに置く設計を打ち出しています。
同社が公開したベンチマークでは、プロセス内でのデータアクセスが約0.4ミリ秒、別階層へネットワーク越しに取りに行く場合が約3ミリ秒とされています。ベンダー自身による比較なので数値の扱いには注意が要りますが、「層を分けると、分けたぶんの通信が毎回発生する」という構造自体は変わりません。
分けるか、まとめるか。この2つは技術的な流行の対立というより、運用できる人数と引き継ぎの前提で決まる問題です。専任のインフラ担当が複数いる組織なら分けたほうが柔軟ですが、情シス担当が1人か、外部委託しかない組織では、まとめたほうが持ちます。
発注段階で確認する2つの質問
構成の妥当性を技術的に評価するのは発注側には難しいので、代わりに次の2つを聞くと判断できます。
1. 「この構成要素を1つ減らすとしたら、どれですか。理由も教えてください」
減らせない理由が具体的（「秒間◯件の処理が要件にあるため」）なら妥当です。「一般的な構成なので」「将来スケールするときに必要になるため」という答えが返ってきた場合、現時点の要件から出てきた選定ではありません。 将来必要になったときに足すほうが、使わないものを運用し続けるより安く済みます。
2. 「納品後、これを運用するのに必要な作業を構成要素ごとに教えてください」
監視・バックアップ・更新の作業が、四角の数だけ列挙されて出てきます。これを見てから保守契約の範囲と金額を決めると、話が具体的になります。 一覧が出てこない場合、運用まで含めた設計になっていない可能性があります。
似た構図は、非同期処理を「確実に1回だけ実行する」ための設計でも出てきます。仕組みを足すかデータベースの機能で担保するかの判断はPostgres と SQLite で処理の確実性をどう担保するかにまとめました。
次にやること
すでに稼働しているシステムがあるなら、構成図を開いて、それぞれの構成要素について「先月、これに関する作業を誰かがしましたか」を確認してください。 誰も触っていないものは、動いているのではなく放置されている可能性があります。バージョンが古いまま止まっているミドルウェアは、そこから見つかります。
これから開発を依頼する場合は、要件定義の段階で上の2つの質問を投げてください。 構成が決まってから減らす議論をすると、設計のやり直しになって費用が動きます。
システム構成の妥当性レビュー、既存システムの運用負荷の棚卸し、保守契約の範囲の見直しについては、グリームハブの開発・AI・自動化のご相談で承っています。現在の構成と社内の運用体制によって取れる手段が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- PostgreSQL for Everything — Raphael Bauer
- Harper Argues Against the Multi-System Stack and Releases 5.2 — InfoQ
- Harper 5.2: More Throughput per Node, Fewer Systems Around It — Harper
- SELECT — PostgreSQL Documentation（FOR UPDATE / SKIP LOCKED）
- Potential Consequences of Using Postgres as a Job Queue — Microsoft Community Hub
