最初から20台は要らない
構想の最終形では、NASを何台も並べて、処理を分散させるつもりです。でも、最初から何台も買う必要はありません。
1台から始めて、必要になったら増やす。支出を、サービスの伸びに合わせて増やしていく。今回は、NASの台数ごとに何ができて、何が足りないのかを整理します。
1台：まず全部を載せて、測る
1台目のNASには、アプリケーションも、データベースも、トンネルも、Gitも、全部載せます。Docker Composeでまとめておけば、1台でも十分に動きます。
この段階でいちばん大事なのは、何が最初に足りなくなるかを測ることです。CPUが詰まるのか、メモリが足りないのか、ディスクの読み書きが遅いのか、回線が細いのか。それによって、2台目に何を任せるべきかが変わります。
弱点は明らかで、この1台が止まれば、サービスも止まります。だから、第4回のバックアップを先にそろえておきます。
2台：本番と予備
2台目は、まず予備として置きます。本番のNASのデータを、予備のNASへ常に複製しておき、本番が壊れたら予備に切り替えます。
ただし、2台では「どちらが正しいか」を機械に自動で決めさせるのが難しくなります。回線が切れて2台が互いを見失うと、両方が「相手が止まった」と判断して、両方が本番として動き出すおそれがあるからです。2台の段階では、切り替えは人が判断して行うくらいに考えておくのが安全です。
3台：1台が壊れても、自動で続く
3台になると、多数決が取れるようになります。3台のうち2台が「この1台は止まった」と判断すれば、残りの2台で処理を続けられます。1台だけが孤立しても、それが勝手に本番を名乗ることはありません。
ここで初めて、1台が壊れても自動で動き続ける、いわゆる高可用性の構成が組めます。コンテナをまとめて管理する軽量なKubernetes（k3sなど）を使うのも、この段階からで十分です。
| 台数 | できること | 足りないこと |
|---|---|---|
| 1台 | サービスを動かし、負荷を測る | 止まれば全部止まる |
| 2台 | データを複製し、予備に切り替えられる | 自動の切り替えは難しい |
| 3台 | 多数決で、1台の故障を自動で乗り切る | 処理の量はまだ限られる |
| それ以上 | 処理を分散させ、量をこなす | ネットワークと管理の手間が増える |
それ以上：容量ではなく、処理のために増やす
私の用途では、ストレージの容量はそれほど要りません。NASを増やすのは、保存場所を広げるためではなく、処理を分散させるためです。
同じ機種でそろえる
台数を増やすときは、できるだけ同じ機種でそろえます。設定を使い回せるうえ、1台が壊れたとき、別の1台の部品で直す、いわゆるニコイチの修理もしやすくなります。第4回でGitに入れた設定を流し込めば、新しい1台は同じ作業の繰り返しで仲間に加わります。
ネットワークが先に詰まる
台数が増えると、NAS同士の通信が増えます。データの複製や、処理の受け渡しです。このとき、NASをつなぐスイッチが先に詰まりがちです。NAS同士の通信用と、外とのやり取り用とで、ネットワークを分けておきます。
高耐久な中古HDDを使う
ストレージには、データセンター向けに作られた高耐久のHDDを、中古で安く使うつもりです。もともと24時間の稼働を前提に作られた製品です。ただし中古である以上、次の点は守ります。
- 使用時間やエラーの記録を確かめてから使う。
- 同じ時期に作られたものばかりでそろえない。同じロットは、同じ頃に壊れやすい。
- RAIDや複製は、壊れても止まらないための仕組みで、バックアップではない。バックアップは別に取る。
この段階でやること
- 1台で全部を動かし、CPU・メモリ・ディスク・回線のどれが先に詰まるかを記録する。
- 2台目を予備として置き、データを複製する。切り替えの手順を書いて、一度試す。
- 3台そろったら、多数決で動く構成に移る。
- それ以上は、測った数字をもとに、必要な台数だけ足す。
TODO：実際に使っている機種と台数、測った負荷の数字をここに追記する。