一つの拠点が止まっても、全体は止まらない

連載の最後は、拠点を増やす話です。一つの拠点で形ができたら、別の地域にも拠点を作り、拠点どうしを結びます。

拠点が一つしかなければ、その地域の災害、停電、回線の障害で、すべてが止まります。拠点が離れた場所に二つあれば、一方が止まっても、もう一方で動き続けられます。一つが止まっても、全体は止まらない。それが、拠点を増やす一番の理由です。

最初の「別の拠点」は、手元にある

いきなり二軒目の物件を買うわけではありません。最初の別の拠点は、手元にある、自宅とは別の場所です。第5回の予備のNASをそこに置けば、それだけで「建物ごと失っても戻せる」構成になります。

そのうえで、田舎の物件のデータセンター(第6回)ができたら、それが主な拠点になり、自宅側が予備に回る。さらに必要になれば、別の地域に拠点を足す。この順番で進めます。

拠点どうしを、どうつなぐか

つなぎ方は、第3回のトンネルと同じ考え方です。各拠点のNASから、入口のVPSへトンネルを張ります。拠点どうしも、WireGuardでつなぎます。

入口のVPSは、奥にある各拠点が生きているかを定期的に確かめ、生きている拠点へリクエストを流します。ある拠点が応答しなくなったら、その拠点へは流さない。入口と奥を分けておいたおかげで、奥の拠点を足しても外しても、外から見た入口は変わりません。

いちばん難しいのは、データ

アプリケーションは、同じものを各拠点で動かせば済みます。難しいのはデータです。

拠点Aで書き込んだデータを、拠点Bにも写す方法は、大きく二つあります。

データの写し方
方法よいところ弱いところ
書き込むたびに、両方に書き終えてから完了とするどちらかが止まっても、データは失われない拠点が離れているほど、書き込みが遅くなる
先に手元に書き、あとから相手に写す速い写し終える前に止まると、その間のデータを失う

失わないことと、速いことは、両立しにくい。拠点を分けても「データが1つも失われない」とは言い切れず、どちらを優先するかを、データの種類ごとに決める必要があります。

だから最初は、欲張りません。片方の拠点を本番、もう片方を待機にして、あとから写す方式で始めます。切り替えも、最初は人の判断で行います。失ってはいけないデータがどれかを見極めてから、少しずつ自動にしていきます。

1拠点目を、パッケージにする

拠点を増やすときに一番効くのは、1拠点目の作り方を、そのまま繰り返せる形にしておくことです。

  • 機材の一覧(NASの機種、スイッチ、UPS、電池)
  • 設定一式(第4回でGitに入れたもの)
  • 組み立てと接続の手順書
  • 電気・回線・届出の確認項目(第6回)

これがそろっていれば、2拠点目は、新しい挑戦ではなく、同じ作業の繰り返しになります。

太陽を追って、計算を動かす

拠点が複数あると、面白いこともできます。晴れていて電気が余っている拠点に、重い処理を寄せる。第6回の「GPUは晴れた昼に」を、拠点をまたいでやるわけです。これは、拠点が増えてからの楽しみにとっておきます。

連載のおわりに

250円のサーバーから始まって、VPS、トンネル、自前のGit、NASのクラスタ、オフグリッドのデータセンター、そして複数の拠点。ここまでが、いま描いている計画の全体です。

ただ、第1回に書いたとおり、収益がなければ、何も始まらない。この連載の順番は、そのまま投資の順番です。次の段階に進むのは、前の段階で稼げるようになってから。実際に進んだら、各回の記録を書き足していきます。

その前提になる「なぜ自前でインフラを持つのか」については、考察の記事にまとめています。