個人で運用している Web サービスをどう管理しているか 2018年版
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。
実験には Heroku を利用
習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。
メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほどでもないけど、良い体験になる機会が失われる）。nippo は一時的に Heroku で動かしているけれど、やはり遅いのが気になるので、全体公開時には AWS に移行しようと考えている。
Read の多いサービスだからキャッシュして高速に動けば US にサーバがあっても大丈夫かもしれないということで、クライアントサイドで IndexedDB を使ってかなり細かくキャッシュするサービスをつくって動かしてみたことがあるけれど、やっぱり初めてアクセスしたときの (キャッシュが無い状態での) レスポンスが遅いのが露骨に気になるし、いいねみたいな機能を付けてリクエストを飛ばすと時間が掛かるし、キャッシュによって Read がめちゃくちゃ速くなった結果 Write の遅さが目立つしで、やはり速度差が体感できてしまった。CDN キャッシュフレンドリーなサービスや、国外向けのサービス、お金を稼げる見込みの高いサービスであれば、まだ Heroku を検討する余地があるかもしれない。
※後述するけれど、AWS に移行する場合は Terraform のファイルを適当にコピーして git push するだけで済むので、自分にとって AWS に移行するコストがわりと低く、インフラ構築コストの低さが Heroku の選択理由になりにくいという事情もある。
検証環境にも Heroku を利用
Pull Request ごとに検証環境をつくるために、Heroku の Review Apps を利用している。Review Apps みたいなやつを個人で運用するには相当な労力が居るので、これのおかげでとても助かっている。しかも Review Apps は無料で使えるのですごい。現時点では Review Apps は Docker で動かせないので、本番環境は Docker で動いていても Heroku では Docker で動いていないという状況になってしまっているが、それを鑑みても Review Apps の恩恵は大きい。業務用途でも、可能なら Review Apps を検証環境に使うと思う。
一般向けに公開しているサービスには AWS 利用
一般に向けて公開しているまともなサービスには、すべて AWS を利用している。例えば amakan や wikihub は AWS で動かしていて、nippo もこれから AWS に移す予定。
AWS を利用しているのは、業務でよく使うので学習しておきたかったということと、テナントごとにサブドメインを分けるようなマルチテナントな Web サービスを運用することが多く、AWS であればワイルドカード対応の SSL 証明書を実質無料で利用できるということが理由。個人で使っているおかげで業務で役に立ったシーンが多かったので、個人開発で学んでおいて良かったと思う。
他の方法で実現するのに比べて、AWS を利用すると少し高くついてしまうなあと感じることもあるけれど、この「高い」という感覚は、個人でやっている Web サービスとしてマネーフロー的にスケールするかどうかという話（広告費と運用費が釣り合えば理論上は放置しておいても動き続けられるとかそういう話）の上での「高い」であって、プログラマとしての勉強代や、個人の支出という話の上で考えると、別に高い金額では無いと思う。
AWS は Terraform で管理
ドメインの購入以外は Terraform で管理していて、個人の AWS アカウントを管理するための Terraform のコードを置いたプライベートリポジトリが、GitHub に存在している。Circle CI と連携されていて、Pull Request で実行計画が表示されて、master に merge されるとそれが適用される、という仕組みになっている。
Terraform の流儀をほとんど覚えていないので、久しぶりに動かそうとすると思い出すところから始まる。1年ほど放置していたが、さっき nippo 用に少し動かしてみたところ、まともに動いて助かった。最初に CI の環境つくっておいて本当に良かった。新しいサービスの環境を用意するときに、既存の似ているサービスのやつをコピーするだけで動くのはありがたい。Terraform のコードはあまり抽象化していなくて、毎度コピーして少し置換したりしている。
通知は個人用 Slack に集約
個人用の (自分しか所属しない) Slack チームを用意して、サービスからの通知はそこにまとめている。例えば、定期的なジョブの実行完了通知や、エラー通知 (Sentry をよく使っている)、お問い合わせやご意見、サービス用のメール、毎日のアクセス数などが通知される。Slack はチャンネルごとにミュートするかどうか切り替えられるので、通知の重要度や、サービスの種類などで分けている。基本的に #general はミュートにしていて、デフォルトでは #general に通知を投げるようにして、数が多かったり、重要なものは別のチャンネルに分けたりしている。
個人開発でのサービスの管理方法について振り返りました。他の人がどう運用しているのかについても知りたい。