インフラ

パイプの太さ。数字が大きいほど一度に送れるデータ量が多い。水道管が細いと少ししか流れないように、帯域幅が小さい回線は速度が出ない。大容量の動画やファイルを送りたいなら太いパイプが要るってわけ。

普通より重い負荷や長時間の使用を想定し、システムに無理させて不具合が出ないかを見るテスト。スポーツ選手が筋トレで限界近くまで頑張るみたいな感じ。どこが弱い部分かを見極めて補強すれば、本番でも安心して耐えられるんだ。

実際にどれくらいのデータが流れたかの結果。「1秒に何MB送れました」という数字で、テストしてみると回線の理論値より下がる場合も多い。高速道路の最大速度は100km/hでも渋滞して50km/hしか出なかったらスループットは50km/hになる感...

長い間動かしっぱなしで不具合やメモリ漏れが起きないかを確かめるテスト。マラソン選手が延々と走り続けるイメージで、最初は元気でも途中でバテるかもしれない。そういう隠れた問題を発見するために、夜通し動かして状態を観察するんだ。

データを送り始めてから相手が受け取るまでの“時間の遅れ”。ピンポーンと鳴らしてから家の人が出てくるまでの時間ってイメージ。距離が遠いほど長くなりがちで、オンラインゲームや通話ではこれが大きいとカクカクしてストレスになるんだ。

全体のパフォーマンスを下げる原因となる「詰まっている部分」のこと。たとえば高速道路で一か所だけ1車線になる区間があると、そこだけ大渋滞になるよね。システムでもCPUが限界だったり、ディスクが遅かったりすると全部が遅くなってしまうんだ。

レイテンシが毎回変わっちゃう現象。さっきは1秒で届いたけど次は3秒かかった、みたいなバラつき。ラジオの音が時々途切れるのと同じ感じで、映像通話だと映像や音が飛び飛びになる原因になる。

将来の利用者数やデータ量を見越して、どのくらいのサーバー・回線が必要かを計画すること。大きなパーティーを開くなら、食事の量やテーブルの数を事前に考えるでしょ？足りなければ困るし、多すぎると無駄になるので、適切な見積もりが大事なんだ。

SLA（これくらいサービスが動くよと約束）を本当に守れているか、ずっと見張ること。約束通りに動いているかデータをとって、もし守れなかったら補償したり原因を調べたりする。お店で「1時間以内にピザ届けます」って言うなら、それを実際に測るみたいな...

1台を“先生（マスター）”としてデータ更新の中心に置き、他のサーバー（スレーブ）が先生の内容をまねる仕組み。学校の先生のノートをみんなが同じに書き写すイメージ。これで読み込み負荷を分散しながら、データは同期が保たれるんだ。