昔の話から

私がサーバの運用をしていたのは、ユビレジではなく他の会社で、今から8年くらい前で、色んなサービスを抱えていて、サーバも一つのサーバの種類で何十台もあるなどとても多かったです。ではこのサーバ達をどう運用していたか項目に分けて説明します。

サーバのリソース、死活監視

Nagiosというオープンソースの監視ソフトを使っていました。mnodeと呼ばれる監視するサーバを立てて、snodeと呼ばれる監視されるサーバをそれぞれ全て設定して、リソース、死活監視は行っていました。

アラート対応・負荷対応

リリースにより影響からくるアラートの対応から、季節・天候などの環境からの負荷増大によりアラートなど、多くのアラートに対して対応を行っていました。どんな時でもくるため、飲み会中・夜中寝てる時に24時間監視チームから起こされることもありました。

BCP対策

私が運用をしていたのは、2011年東日本大震災後で、サーバの冗長化について考えられていました。
サーバを東日本と西日本に分けるというもので、新しくサーバを用意しながら古いものを移して除却するというとても時間のかかる作業をした記憶があります。とはいえユーザのために24時間稼働するサービスを提供することはとても重要だと思います。

サーバ増設、移設、除却対応

BCP対応と対応自体は同じですが、古いスペックのサーバをいつまでもコキを使うより、最新のサーバを使ってコストパフォーマンスをあげるのもサーバ運用の仕事の1つでした。

ハードウェア故障後の交換依頼対応

物理サーバだと切っても切れないのがこのハードウェア故障。特に読み込みだけしかほとんど使わないハードディスクでもかなりの頻度で故障した記憶があります。

アカウント管理

新入社員など、担当者が入れ替わるたびにツールからアカウントを追加したり削除したりしていました。もちろん人がやることなので、削除し忘れて結構残っていたから一気に削除するという微妙な運用もよく起きていました。

リリース作業

パッケージアップデートやインストールでリリースをしていました。私が運用していた頃はパッケージのバージョンがバラバラで、このサーバには入るけどこのサーバには入らない、アップデートできないということがありました。バージョンの違いには実は意味はなく、リリース漏れだったりなぜか入っていることが多く、この管理が一番ずさんだった気がします。バージョンが違うとかもはや別物のサーバ・・・。
しかしほぼ手動のリリースだとこんなことも当時はあったんでしょうね。

↑このリリース方法はしんどい、管理もひどくなる

Herokuを使い始めて

最近まで、そういったレガシーな環境で働くことが多かったり、iOSなどクライアントアプリの開発が多かったため、Herokuを使い始めたのはつい最近。ユビレジでも私が入る前からHerokuを利用していて、既に運用されている状態だったのですが、凄いなあと思って使っていました。
最近、プライベートで開発しているサービスもHerokuを使って開発しようということで、１からセットアップしていましたが、無料プランでも快適な点がいくつかあったので、ここに書いていきたいと思います。

セットアップが容易

まず、Herokuを使えるまでにする手順が、物理ーサーバより圧倒的に簡単ということです。
Herokuがサポートしている言語であれば、登録して少し設定をいじるだけで、ステージング環境や本番環境を用意することができます。

参考になる記事

登録からパソコンにHerokuCLIを入れるまで参考になりました
https://qiita.com/mnao305/items/71c8c9d5fd195592c1ec

開発視点でも便利

開発をしたことがある人は、ステージング環境に反映するまで、個人環境を構築した状態で動作確認をしていましたが、Githubと連携すると、各PRごとに動作環境を自動で構築してくれるように設定することもできます。これによって、各PR毎に動作確認をしてもらうこともとても簡単にできます。

参考になる記事

プルリク毎に動作環境を自動で立てるようにするのに参考になりました
https://qiita.com/kon_yu/items/6d2c0ae91d0176ceb167

ほぼ自動で安全にリリース（デプロイ）ができる

テストコードを書く習慣があれば、そのテストコードが全てOKなることを自動で確認して、デプロイ作業も自動に設定することができます。運用に合わせて自動デプロイをOFFにすることもできます。これらの環境をわざわざサーバを立てて連携せずとも簡単にできるのはHerokuの魅力に感じました。

物理的なハードウェアの故障を気にしなくって良い

全く気にしない点なので、予想ですがハードウェアの故障はデータセンター側でカバーしているため、こちらとしては一切ハードウェアの故障を意識しなくても良い状態となっています。（裏では故障したら交換してくれている素晴らしいエンジニアがいると思うのですが、それが気にならない）

【有料】自動スケーリングでアクセス集中にも継続サービス提供が可能か

これは有料プラン専用機能なので、個人的には試していないですが、物理サーバだと、アクセス集中時期を予想したり、スタンバイサーバを用意したりと多くの労力をかけないと、アクセスが増えた時に対応し切れないことが多かったです。
しかし、自動スケーリング機能を使うことで、予測のできないスケーリングも多くの工数をかけることなく、スケーリングしてくれるようです。
自動にやってくれるのは、サーバ運用観点だけでなく、ユーザにとっても優しいですね。

結論

開発途中の小規模のサービスを物理サーバで開発しているのなら、まずは体験してみるべきかと思います。
少人数の開発なら、コラボレータを登録するだけで、複数人の開発にも対応できます。
有料プランへはお財布と相談になりますが、上記のこと以外にもできることはまだありますので、まずはいじってみてはどうでしょう🤗
今まで触ったことのないサービスってワクワクしますよ！