- 本番サーバーが障害やアクセス集中で応答不能になったとき、代わりにユーザーへ「現在メンテナンス中です」などの謝罪ページを見せるための待機サーバーのこと
- ロードバランサーやDNSが障害を検知すると、自動的にソーリーサーバーへトラフィックを切り替えるフェイルオーバーの仕組みが動く。ユーザーは真っ白なエラー画面を見ずに済む
- 静的なHTMLしか返さないため、超軽量なサーバーで十分機能する。大規模障害時でもソーリーサーバー自身は落ちにくい構成が重要だ
【深掘り】これだけ知ってればOK！
ソーリーサーバーの動作原理は「平常時は待機、異常時に出番」という構成だ。平常時、ユーザーのリクエストはすべて本番サーバー群へ送られる。ソーリーサーバーは待機状態にあり、直接リクエストを受けることはない。しかし本番サーバーが障害やアクセス集中で応答不能になると、ロードバランサーがその異常を検知し、リクエストをソーリーサーバーへ自動的に振り向ける。この切り替えをフェイルオーバーと呼ぶ。
ソーリーサーバーが返すコンテンツは意図的にシンプルに設計される。静的なHTMLとCSSだけで構成され、データベースへの接続も画像の動的生成もない。これは「障害時に最も信頼できるのは最もシンプルな構成」という原則に基づいている。本番サーバーが重い処理で落ちているとき、同じく重い処理を持つソーリーサーバーもつられて落ちてしまっては意味がない。
設置コストが低いこともソーリーサーバーの特徴だ。さくらのクラウドやAWSなどのクラウド環境では、最小スペックのインスタンスにApacheとシンプルなHTMLを置くだけで構築できる。年間のほとんどの時間は待機しているため、費用対効果が高い保険として機能する。障害対応マニュアルと同じ棚に「ソーリーサーバーの存在」を置いておくことが重要だ。
よくある誤解
ソーリーサーバーとメンテナンスページは同じだという誤解
メンテナンスページは計画的な作業前に手動で切り替えるものだが、ソーリーサーバーは障害発生を自動検知して自動切り替えする点で異なる。手動切り替えか自動フェイルオーバーかという違いが本質だ。メンテナンスページはソーリーサーバーに乗せることが多いが、それはあくまで同じ仕組みを流用しているだけだ。
ソーリーページをHTTP 200で返してしまうケース
ステータスコード200で謝罪ページを返すと、検索エンジンはそのページを通常コンテンツとして扱う。結果として本番ページが検索インデックスからソーリーページに差し替えられるSEO被害が起きることがある。503＋Retry-Afterヘッダーの組み合わせが正しい設定で、これは障害対応マニュアルに明記しておく価値がある。
会話での使われ方
本番サーバーが落ちました。ソーリーサーバーへの切り替えは自動で動いてますか？確認をお願いします。
深夜の障害対応でインフラリーダーが担当者にSlackで緊急確認している場面。フェイルオーバーが正常動作しているかを真っ先に確認する状況だ。
ソーリーサーバーのステータスコード、200で返してませんか？SEOに影響が出るので503に変えてください。Retry-Afterも合わせて設定が必要です。
エンジニアがインフラ担当にコードレビュー後の1on1で指摘している場面。謝罪ページのステータスコード設定ミスはSEO被害につながるため重要だ。
今回のリニューアルでソーリーサーバーのデザインも一新したいです。障害中でもブランドらしい謝罪ページを出したいので。
Webリニューアルの要件定義ミーティングでブランドマネージャーがエンジニアに要望を伝えている場面。ユーザー体験の観点からソーリーページのデザインにも投資する方針だ。
【まとめ】3つのポイント
- 本番障害時の顔として機能する待機サーバー：ソーリーサーバーはロードバランサーが障害を検知すると自動的に前面に出て、ユーザーに状況を伝える役割を担う
- 503＋Retry-Afterが正しいステータス設定：200で返すと検索エンジンに誤認されSEO被害が起きるため、503とRetry-Afterヘッダーのセット設定がインフラの常識だ
- シンプルな構成こそ最強の耐障害性：静的HTMLだけで動く軽量構成にすることで、本番障害に引きずられずソーリーサーバー自身が生き残れる設計が求められる
よくある質問
- Qソーリーサーバーは自分で用意しないといけませんか？
- A
クラウドサービスによっては標準機能として提供されているケースがあります。AWS Application Load Balancerではターゲットが全台ダウンした際にカスタムのエラーレスポンスを返す設定が可能です。さくらのクラウドのGSLBでもソーリーサーバー設定に対応しています。自前のオンプレミス環境では最小スペックのサーバーに静的HTMLを置いてロードバランサーのフェイルオーバー先に指定するのが一般的です。
- Qソーリーサーバーへの切り替えにどのくらい時間がかかりますか？
- A
ロードバランサーのヘルスチェック設定次第です。一般的にはヘルスチェックが失敗した回数が閾値を超えた時点でフェイルオーバーが発動するため、数秒〜数十秒程度かかります。ヘルスチェック間隔を短く・失敗回数の閾値を小さくすれば切り替えを速くできますが、誤検知が増えるトレードオフがあります。
- Qソーリーページにお問い合わせフォームを設置しても良いですか？
- A
避けた方が賢明です。ソーリーサーバーはシンプルな静的ページであることが信頼性の源泉で、フォームを動かすにはPHPやデータベース接続が必要になり、障害連鎖のリスクが高まります。代わりにSNS公式アカウントのURLや、別ドメインで運営するステータスページへのリンクを記載するのが実務での定石です。
- Qソーリーサーバーとロードバランサーの違いは何ですか？
- A
役割がまったく異なります。ロードバランサーは複数のサーバーへトラフィックを振り分ける交通整理係で、ソーリーサーバーは振り分け先が全滅したときに出動する最後の砦です。ロードバランサーがソーリーサーバーへの切り替えを判断・実行し、ソーリーサーバーがユーザーへ謝罪ページを返すという連携で機能する関係にあります。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| サーバー | サーバーを押さえると本記事の理解がさらに深まります。ネットワークを通じて情報やサービスを提供する側のコンピューターのこと。レストランで料理を運んでくれる給仕係（server）をイメージするとわかりやすいよ |
| フェイルオーバー | フェイルオーバーを押さえると本記事の理解がさらに深まります。システムや機器に障害が発生したとき自動的にスタンバイ機・バックアップシステムに切り替えてサービスの継続を実現する仕組みのこと |
| 検索エンジン | 検索エンジンとの関係を知ると全体像がつかみやすくなります。調べたい言葉を入れると、世界中のWebページから関連するものを探し出して一覧で示してくれる仕組み、それが検索エンジンだ |
| アイコン | アイコンを押さえると本記事の理解がさらに深まります。アプリやファイル、操作ボタンなどをひと目でわかる小さな絵で表したもの、それがアイコンだ |
| データベース | データベースは関連分野でよく登場する重要キーワードです。データを効率よく蓄積・検索・更新・削除できるよう構造化して管理する仕組みの総称。専用エンジンを持ち大量データを高速操作できる |
【出典】参考URL
https://e-words.jp/w/Sorry%E3%82%B5%E3%83%BC%E3%83%90.html ：IT用語辞典 e-Words「Sorryサーバ」
https://app.engr-sng.com/glossary/detail/sorry-server ：ソーリーサーバーの動作原理の詳細解説
https://knowledge.sakura.ad.jp/5466/ ：さくらのナレッジ「ソーリーサーバの設定方法」
コメント