サイトの中身が決まると、次は動かす仕組みだ。記事を出すAPI、広告を受け付ける入口、投稿された画像の置き場。役割で数えると、けっこうな数になる。
普通なら、それぞれを別のサービスに分けたくなる。前段のサイトはここ、APIはあちら、画像の配信はまた別、というふうに。けれど今回は、あえて一つにまとめた。
役割は多いが、規模は小さい
分けるかどうかを決める前に、規模を見た。
地域の情報紙のサイトだ。全国から秒間何千件も来るわけではない。記事も、一日に何十本と増えるものではない。役割こそ多いが、こなす量は小さい。この規模で仕組みを細かく分けると、つなぎ目の管理だけが増えて、得るものが少ない。
大きな構えは、大きな流量があってこそ生きる。無ければ、ただ運用が複雑になるだけだ。だから、規模に合わせて小さく作ることにした。
一つのプロセスに、全部を持たせる
結論として、一つのサーバープロセスに、全部の役割を持たせた。
同じプロセスが、サイトの画面も返すし、記事のデータも返すし、投稿された画像も配信する。前段には受け口を一つだけ置いて、暗号化の処理をさせ、その内側の一つのプロセスへ渡す。外から見れば、窓口は一つ。中でも、動いているのは一つ。
構成図が、ほとんど一枚の四角で済む。動いているものが少ないほど、どこで何が起きているかを、頭の中で追える。一人で運用するなら、この「追える」が何より大事だった。
画像だけは、扱いが違った
一つだけ、気をつけた点がある。投稿される画像だ。
広告主が画像を送ってくる。それをどう受け取り、どこに置き、どう配るか。文字のデータと同じ流れには乗せられない。受け取った画像はいったんサーバーに保存し、専用の道から配信する形にした。同じプロセスの中でも、画像の入口と出口だけは、はっきり分けて扱う。
まとめる、といっても、何でも混ぜるわけではない。性質が違うものは、同じ器の中でも、通り道を分けておく。
小さいことは、機能だ
小さく作る、というと、手を抜いたように聞こえるかもしれない。逆だった。
小さいから、止まりにくい。小さいから、直しやすい。障害が起きても、見る場所が少ない。更新も、ひとかたまりを入れ替えるだけで済む。一人で長く面倒を見ることを考えると、この身軽さそのものが、立派な機能だった。
大きくするのは、必要になってからでいい。流量が増えたら、そのとき役割を切り出せばいい。最初から大きく構えて、使わない余力を抱えるより、いま動く分だけを、確実に動かす。そういう選び方をした。
次の回は、その仕組みの上で、広告をどう安全に載せたかを書く。