レンタルサーバとVPSにおけるCGIの差は大きい

サービスの維持費を最初から極限まで切り詰める事を意識し、 レンタルサービスでサービスインできないか考えていたのですが、結局諦めてVPSにしました。 どのへんでレンタルサーバに詰まるかという事を、今後ハマらないようにメモしておきます。

まず今回のサービスはスタートからデータ容量が20GBくらいあってそれが結構増える予想だったので、 まずはそれを載せられるサーバでないといけなかった。VPSはディスク容量が弱いので意外と高く付く。 一番安かったのはロリポップ/スターサーバーの250円/月。 ちなみにクラウドストレージは容量だけでこれらの代金を超えかねない。


ただレンタルサーバによる運用は様々なつらみを伴う。さっそくサーバを設定しようとして、ハマりにハマったのがCGI。 普段はVPSしか使ってないため、もうCGIとかまったく使ってないので勘所を忘れていました。 最近はリバースプロキシでアプリを作るのが常識になってるので、その切り替えの簡単さから、手元のアプリもCGIにすぐ書き換えられるだろーとか思ってしまった。 しかし全然そんな事はなかった。

まず最初にハマったのは、PythonはCGIでHTTPヘッダを(たぶん)見れないという事でした。 RubyのCGIは環境変数にHTTPを入れるというトリッキーな実装をして回避してるけど、Pythonはたぶんそういうのない。 この実装差があるのでCGIを書くならまだRubyのほうが複雑な事に対応しやすい気がする。 HTTPヘッダを見れないと、例えば事前にgzip圧縮したファイルをCGI経由で表示できない。
ただHTTPヘッダを見ても事前にgzip圧縮したファイルのロードが難しいんだよなあ。 毎回ファイルI/Oを発生させるのは流石にあり得ず、生データをApacheにgzip化してもらうほうがマシである。 ようするにCGIじゃ駄目じゃん…と気が付いたり、久々のCGIには様々な苦行があった。 他にも安いプランのレンタルサーバではSSH, gcc, brotli, C/C++が使えないなど、つらみの連続である。


圧縮効率に話を戻すと、今回のサービスでは幸いにもCGIで送受信したいデータは小さく、 全体の静的データの通信量から見れば事前圧縮しないでもたいした問題は生じない事がわかった。 なのでライブラリはFastCGIでメモリに載る事を意識しながら、その他はファイルI/Oが発生しないように気を付ければ、 何とかならない気もしないでもなかった。

しかしまだまだ道程は遠い。CGIで少し高機能な事をしようとすると、当然ながらモジュールのロードが必要になってくる。 安いレンタルサーバにはSSHもホームディレクトリも存在しないため、ようするにWebルート上にライブラリを配置せざるを得なくなる。 これは当然セキュリティ的にアウトだし、そもそも実行できないようになってるんじゃないかな。 さて困ったという事になってしまう。
Rubyでも当然同じ事は起きるのだけど、Rubyのモジュール定義はディレクトリに依存しないので、 ライブラリをすべてシングルファイルに書き出して実行すればいけるのではと一瞬頭をよぎったのですが、そのようなライブラリがない状況下では悪魔的手法過ぎて、地獄感が半端なかったのでやめておきました。
一応少し高機能なCGIをでっち上げて動くかだけ確認してみたのですが、すぐに500エラーが出てしまって、うーんと思いながらこの辺りで利用を諦めました。 CGIのようにローカルで動いてもサーバの仕様に左右され過ぎて、リモートで動くかわからないのはちょっとな…。 SSHでホームディレクトリを弄れればもう少しまともな気がしますが、それだとディスク以外の点ではVPSと価格的に大差がないしなあ。


250円/月の魅力が強過ぎて無駄に時間を掛けてしまいましたが、結局はCGIがつら過ぎて私は最終的に諦めてしまいました。 ただ最初にも書きましたが、レンタルサーバはディスク容量と通信容量から見るととにかく安い。 今回のサービスはVPSで提供するならどんなに安くしても600円/月掛かります。 ネットワークに不安がある100円/月とかのVPSは使えないし、600円以下のプランも在庫がなかった。 時間を掛けて調査した割には微妙な結論に…。

レンタルサーバももう少し制約が緩ければなあ。 今回ハマりまくった理由の大半はリバースプロキシが使えないせいにある。 Google App EngineみたいなリバースプロキシAPIを用意してくれれば、 たいていの設定がかなり簡単にできて割と流行る気がするんですが、どこか実装してくれないかなあ。