インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。
ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。
CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。
本当に自分達でなにもサーバーを管理していません。
これでやっていけているのかというと、まあやっていけています。 Heroku 使ってるからダメ〜みたいな感じの失注があったのかどうか知りませんが、まあそういう店舗はそもそもデータの置き場がベンダー側にしかない POS レジサービスを選択しないだろうと思う。
開発体制とか社内環境とかはさておき業務ドメインとしては割とおかたい感じのことをやっていますが、 NoOps でまわってます。
というわけで Heroku/NoOps で辛かったことと辛くないこと
- Redis To Go という Heroku Add-on が極めて不安定だった
- これ由来の障害が多発したので、 Heroku Redis に移行したら解決したみたいのがあった
- Heroku Scheduler がたまに動かない
- Scheduler is a “best effort” service, meaning that execution is expected but not guaranteed. だってさ。
- Dead Man's Snitch というアプリケーションを使ってこの辺監視して、なんかあったら手動再実行という解決策がとられてる
- resque-scheduler の信頼性について現在調査中で、こっちのほうがよさそうだったら引っ越し予定
- Scheduler is a “best effort” service, meaning that execution is expected but not guaranteed. だってさ。
- サービス名わすれたけどサポートチツールみたいなやつが 5 文字以上の TLD にメール送れない
- shit@fuck.tokyo みたいなアドレスで死ぬ、この問題どうなったか忘れた
意外と辛くなかったこと
- Heroku はアメリカ/ヨーロッパにしかサーバーがないので往復で時間無駄になる
- これが嫌で Heroku 捨てる人達多いみたいだけど、これが嫌になるくらいチューニングされてんのか?
- とはいえうちではチューニングが最近進んだのでそのうちこれが嫌になるかもしれない
- これが嫌で Heroku 捨てる人達多いみたいだけど、これが嫌になるくらいチューニングされてんのか?
自分達でサーバーメンテしてる故の強みみたいな話をする人達がよくいるけど、具体的にそれがなんなのか話してくれる人は意外と少ない。ロックインされてるデメリットはあるんだけど、まあ Heroku 捨てるってなったらそれはそれで半年もあればできるでしょう。