私はこの7月(2019/07)、自宅サーバーを辞めました。その自宅サーバーではブログや細かいBOT系のサービスなどを動かしていましたが、それらはNetlifyやAWSに移行しました。
この記事では、自宅サーバーを辞めた理由と私の自宅サーバーに対する意見を軽く述べた後、それぞれについてさらに詳しく述べます。なお、本文中に登場する「クラウド」とはfully managedなクラウドサービス(AWS Lambdaなど)を想定しています。
概要
自宅サーバーを辞めるに至った一番大きな理由は、単純ですが、サーバーの管理が面倒だったからです。自宅サーバーではクラウドにおいて意識することのないシステムレベルやハードウェアレベルの管理もしなければなりません。多くの時間をそういったサーバーの管理に費やさなければなりません。結果として、アプリケーション本体に費やすことのできる時間は減ります。AWS (Lambda)などのクラウドを利用したほうが、アプリケーションの本質的な部分に注力できるのは明らかです。
それでも、自宅サーバー運用の経験は私にとっては無駄ではありませんでした。自宅サーバーを管理する過程で得られたスキルがあったからです。具体的に言うと、それはLinuxやネットワークの知識です。クラウドはそれらを意識することなく使える、言い換えれば、意識する機会がありません。自宅サーバーの運用を通じてこのような知識を実践的に身に着けられたという点で、自宅サーバー構築の経験は無意味でなかったと考えています。
それでは、各項目についてより詳しく書きます。
自宅サーバーの何が面倒だったか
前述の通り、自宅サーバーを辞めたのは管理が面倒だったためですが、具体的にどのようなことが面倒だったのか述べます。人によっては、全然面倒じゃない、むしろそれが自宅サーバーの醍醐味だといった意見があるかもしれません。ここで書くことはあくまで私の主観的な意見であることに留意してください。 クラウドにはない、自宅サーバー特有の問題となるのは、主にハードウェアとシステムの管理です。まず、ハードウェアの管理について述べます。
ハードウェアの管理
自宅サーバーでは当然、サーバーマシンが壊れたときの対処も自分で行う必要があります。最もよくあるのはデータの消失です。補助記憶装置としてよく用いられるHDDは消耗品であり、ある日突然壊れるものです。SMARTを用いれば、ある程度の内部状況を知ることはできますが、それでも故障の予測をするのは難しく、常に故障に備えておく必要があります。
HDD故障に備えるとは、単にバックアップを取っておくだけではありません。手順を明確にしておき、故障したときは速やかに復旧作業に着手できる体制を整えておく必要があります。それを怠れば、ダウンタイムが長引いたり、最悪の場合にはリストアを試みて初めてバックアップのミスに気づいたりすることもあり得ます。
そのような面倒を避けるなら、ストレージについてはRAIDを利用したり、他のハードウェアについては冗長系を用意したりする必要があります。しかし、それには多くの費用がかかります。
以上より、自宅サーバーを安定的に運用したいのならば、いつ故障してもすぐに復旧できるよう備えておくか、多くの費用をかけて冗長性を確保する必要があります。私の場合は自宅サーバーにそこまでお金をかける余裕は無かったので、必然的に前者を選びました。確かに、費用は安く済ませることができましたが、常に自宅サーバーに気を配っておくのは精神的に楽ではありませんでした。
システムの管理
AWSなどのクラウドでは、サービスの起動や停止、ログの閲覧やスペックの変更などをわずか数クリックで行うことができます。そして、各サービスの状態をグラフィカルにモニターできます。しかし、自宅サーバーではそうは行きません。起動や停止を行う際には、それぞれのサービスが動いている技術に応じて、適切なコマンドで操作を行う必要があります。その上、サービスの状態を俯瞰するのはクラウドと比べて困難で、障害発生時は、nginxのリバースプロキシやuWSGIなどの複数のレベルでの問題を調査しなければなりません。
また、HDD容量やメモリ容量を増やしたいときには、自分でパーツを購入し増設する必要があります。増設作業自体は自作PCの好きな人にとっては苦ではありませんが、パーツの購入(あるいは売却)を伴うため、気軽にスケールアップやスケールダウンを行うことができないというのはデメリットです。
自宅サーバーはクラウドと比較して非効率的なのか
以上から、自宅サーバーの管理は手間がかかるということがお分かりいただけたかと思います。では、Webサービスなどを運用する際に自宅サーバーを用いるというオプションはクラウドを用いる場合と比較して非効率的なのでしょうか。
残念ながら、多くの場合その通りだと考えます。クラウドは自宅サーバーに比べて信頼性が高く、(その信頼性の割には)意外にも低コストです。その上、クラウドの管理画面はグラフィカルなので、多くの人にとっては自宅サーバーで使うようなCUI画面より使いやすく感じるはずです。
しかし、サーバーについて学びたいのなら、自宅サーバーはクラウドよりも適しているでしょう。クラウドではあらゆる部分をユーザーに意識させることなくよしなに設定してくれますが、サーバーの仕組みを学ぶ上では妨げとなります。反面、自宅サーバーは基本的にすべての設定を自分で行う必要があるので、その意味を理解しながらサーバーを構築できます。
重要なのはサーバーかサービスか
要するに、あなたにとってより重要なのはサービスを運用することなのか、あるいは、サーバーについて学ぶことなのかということです。そういった意味で、私は自宅サーバーが無意味であるとは思いません。アプリケーションの開発を通じて、フレームワークを学ぶのと同様に、実際のサーバー構築を通じてサーバーについて学ぶのは理にかなっていると思うからです。
傾向として、ビジネス上はアプリケーションのほうが本質とされ、ゆえにサーバー運用は非本質的であるから、近年はオンプレミスよりもクラウドを用いることが多いように思います。しかし、趣味で開発をする上では、個々人の考え方に基づいてどちらを優先するかを決める自由があるはずで、その経験により得られる知識を勘案すれば、その選択には合理性が認められると考えられます。
私が自宅サーバーを始めたとき―もっともその頃のクラウドは今ほど浸透していたわけではないのですが―私はサーバー運用に重点を置いていました。そして狙い通り、サーバー運用について実践的な知識を身につけることができました。しかし、次第にアプリケーション開発にも強い興味を抱くようになり、サーバー運用に割けるリソースは減少していきました。さらに、自宅サーバーを始めた当初、学びたいと思っていたことも概ね学ぶことができ、自分の中では既にある程度満足していました。したがって、今度はアプリケーションのほうに集中したいと思い、自宅サーバーからクラウドへ移行することにしました。
終わりに
近頃、個人開発者でも容易に使えるクラウドの台頭により、自宅サーバーは衰退傾向にありますが、私としては自宅サーバーは試して見る価値のあるものだと思います。自宅サーバーまで行かなくとも、fully managedではなくVPS上でサービスを運用してみるのは、サーバーに関する知識を身につけるためのとても良い経験になると思います。
しかしながら、その運用を続けるとなると多くの時間あるいは費用を要することになります。クラウドは集中的に管理されているため、アプリケーション開発に重点を置くなら、クラウドを用いるほうが効率的だと考えます。
結論として、趣味開発の場合は、自分が何に重点を置くのかに応じて自宅サーバーとクラウドを使い分けるのがベストだと思います。
余談: 実体から抽象へ
振り返って考えてみると、私が自宅サーバーにこだわっていた理由の1つに所有感があると思います。日々の作業スペースのすぐそばにサーバーマシンがあり、そこで自分のアプリケーションが動いており、私のブログへのアクセスもそのマシンに届いているという感覚です。私は、数年前まではGitHubのアカウントすら所持しておらず、自宅サーバーでGitLabをホスティングしていましたし、ブログも自宅サーバーでWordPressを使って動かしていました。クラウドのサービスを使うのは、自分のアプリケーションや文章が自分の手から離れてしまうような気がして抵抗を感じていました。物質的なモノに価値を感じていたのだと思います。
しかし、物質的なモノを管理するのは、前に述べたように手間がかかります。その苦労を重ねるうちに考え方が180度変わり、物質的ではなく仮想的なモノに魅力を感じるようになりました。具体的には、故障をほとんど無視できて、必要に応じて増やしたり減らしたりできる、そして実際に使った分だけ料金を支払えば良いという性質がとても魅力的に感じられるようになったのです。
最近では、クラウドの管理すらも自分で操作して作るのではなく、コードとして記述しインスタンスを生成するという考え方(AWS SAMなど)が好きです。なぜなら、サーバーの構成のほぼ全てがコードに書かれているため、見通しが良く、再現性も担保されるからです。そうなると、私の関心はもはや仮想的なモノにすらなく、モノの定義に向いているようにも思えます。自宅サーバーの大変さを知った結果、クラウド特有の魅力に気づいたのだと思います。