インフラをやってきた話

この記事はpyspa advent calendarの6日目として書かれました

どうもfeizです。前回の投稿日が2013年とかでちょっと引きました。

好きな牛丼屋は吉野家です。

去る7月より、20台の大半を過ごした株式会社ビープラウドを退職し、BASE株式会社に入社していました。

現在はPAY.JPというサービスでインフラをメインに担当しています。

長いこと勤めた会社を辞めて一区切りついたところで、とりとめもなくポエムでも書いてみようと思います。

ここ数年、webサービスのインフラの仕事を担当することが増えた。増えたどころか、ほぼ全案件インフラ担当を兼任していたように思う。

新卒の頃から数えても、「サーバーをインフラの人に頼んで工面してもらう」みたいな経験自体があんまりなく、大体自分で作ったり管理したりしていた。小さなチームでばかり仕事をしていればまあ当然かもしれない。

そんな環境に置かれていると、どうしてもインフラに真剣に取り組まざるを得なくなる。サービスが落ちたとき治すのは当然自分だし、インフラが壊れたときの被害はコードのバグの比ではないからだ。

ぱっと思いつくだけでも、mysqlのdatadirとreplicationがぶっこわれて15時間ぶっ続けでリカバリしたり、本番系インスタンスが14台中10台ぐらい壊れて死にそうになりながら直した記憶がよみがえる。もちろんどちらも朝までコースだった。

こんなことばかりしていては早晩カロウシしてしまうわけで、落ちないインフラについて考え始めることになる。自分が死なないために。

一言に落ちないインフラと言っても、実現するのは難しい。ソースコードの文字が勝手に変わることはないが、インフラは平気で経年劣化したり何もしてないのに突然プロセスが死んだりする。

これを並列化してあれにバックアップを用意して…などと考えているだけで日が暮れる。

コードなんか触ってる場合ではない。コードを書くのは好きなのだが、それ以上に夜安心して眠れるようにしたかった。

考えたインフラ構成を実際に作るのも大変なので、必然にfabricやらansibleやらのプロビジョニングツールにどっぷり浸かることになったりして、どんどんインフラに関わる時間が増えていった。

ある程度詳しくなってくると、チームを組んでも大抵インフラ仕事をやることになる。

自分の勉強にはいいのだが、逆にそれ以外の人がアプリの人(というかnotインフラの人)になってしまうという問題があったように思う。

かといって無理やり誰かにやらせても良い結果にならないのは明白なので、どんどんインフラの人化が加速していくことになる。

今思えば、あのあたりで技術継承の一つもできていればよかったのだろうなと思う。

そういう仕事を続けた結果、feizはインフラの人になった。

必要に駆られて取り組み始めたことではあるが、なんやかんやで結構楽しんでやってはいる。

耐障害性の確保やら無停止メンテナンスの計画作りはパズルめいた面白さがある。

コードを書く時間は減ってしまった(今はほぼ0)が、書いたときに出せるものの質は上がったように思う。

インフラの限界がどこかを分かってコードを書くと、障害を未然に防げたり、パフォーマンス問題で詰んだりしなくなる。

何より、サービスのあらゆる場所を把握して手出しができるというのは、ストレスが無くて良い。

今は決済代行サービスのインフラという、字面だけ見れば結構シビアなポジションに就いているが、まだ成長途中ということもあってなんとかやっていけている。

課題は山積みだが、おかげでしばらくは飯の種と勉強のネタには困らなさそうだ。

何年後かに続く。明日は岡野先輩です