サーバーが止まってもサービスを続ける

Webサイトを一台のサーバーだけで動かすと、そのサーバーを更新したり、故障で停止したりした間はページを表示できません。 同じWebサイトを複数台で動かし、動いているサーバーへ通信を送れれば、一台の停止中もサービスを続けられます。

このように、故障しても処理を続けられるよう同じ役割を複数用意することを冗長化と呼びます。 台数を増やすだけでなく、同時に止まる原因を共有していないかも確認します。

サービスの停止をどれくらいの時間まで許容するか

サービスを使えた時間や、成功したリクエストの割合を可用性と呼びます。 利用者がサービスを必要とする時間を基準に、許容できる停止時間を決めます。

可用性の目標を上げると、予備のサーバー、監視、自動的な切り替え、復旧訓練に費用がかかります。 すべてのサービスへ同じ数値を使わず、停止したときの利用者への影響から目標を決めます。

複数台が同時に止まる原因

同じ電源やネットワーク機器を使う二台は、その共有部分が故障すると同時に停止します。 一緒に止まる可能性がある範囲を障害領域と呼びます。

クラウドでは、電源やネットワークを分けた設備の単位をアベイラビリティゾーン（AZ）と呼ぶことがあります。 異なるAZへサーバーを置く場合は、片方の停止を検知して通信を切り替え、必要なデータを両方から使えるようにします。

Webサーバーが複数あっても、両方が使うデータベースやDNSが一つだけなら、その接続先の停止でサービス全体が止まります。 サービスが処理を続けるために必要な接続先を図にし、故障時の切り替え方を決めます。

遅い接続先を待ち続けない

Webサーバーが遅くなったデータベースを待ち続けると、待機中の処理がメモリや接続を使い続けます。 待てる時間の上限を決めて処理を中止する仕組みがタイムアウトです。

通信の一時的な失敗に対して、同じ処理をもう一度試すことを再試行と呼びます。 再試行の回数が多いと、故障中の接続先へさらに多くのリクエストを送ってしまいます。 回数と間隔を決め、同じ操作を二回行ってもデータが重複しないことを確認します。

復旧手順は、試験用の環境で実際にサーバー停止や接続の遅延を起こして確かめます。 停止を検知し、別のサーバーへ切り替わり、利用者が再び使えるまでの時間を測ります。