一つの拠点が止まっても、全体は止まらない
連載の最後は、拠点を増やす話です。一つの拠点で形ができたら、別の地域にも拠点を作り、拠点どうしを結びます。
拠点が一つしかなければ、その地域の災害、停電、回線の障害で、すべてが止まります。拠点が離れた場所に二つあれば、一方が止まっても、もう一方で動き続けられます。一つが止まっても、全体は止まらない。それが、拠点を増やす一番の理由です。
最初の「別の拠点」は、手元にある
いきなり二軒目の物件を買うわけではありません。最初の別の拠点は、手元にある、自宅とは別の場所です。第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回に書いたとおり、収益がなければ、何も始まらない。この連載の順番は、そのまま投資の順番です。次の段階に進むのは、前の段階で稼げるようになってから。実際に進んだら、各回の記録を書き足していきます。
その前提になる「なぜ自前でインフラを持つのか」については、考察の記事にまとめています。