サーバーを2台にすれば予約業務は止まらない？可用性設計で確かめる場所

可用性は、必要な予約の仕事を続けられるかで考える

可用性は、必要なときにシステムを利用できる性質です。ここでは、予約担当が空きを調べ、予約を記録し、受付結果を確かめる仕事を対象にします。サーバーが動いているかだけでなく、その仕事の終点まで進めるかを考えます。

「単一障害点」は、そこ一つが故障すると、必要な仕事が止まり得る場所です。「冗長化」は、故障に備えて代わりの処理先などを用意すること。「切替」は、故障などの条件に応じて処理先を変えることです。代わりが存在しても、そこへ移れる条件と、同じ予約を扱える状態が整っていなければ、継続できるとは判断できません。

MicrosoftのAzure設計資料は、重要な処理経路の各部分、切替、業務要件と費用・複雑さ・運用能力を合わせて確認する観点を示しています。本稿はこの観点を使います。Azure固有の構成をこの会社の採用方式にしたり、未確認の構成から稼働率を計算したりはしません。Microsoft公式：冗長性と切替を設計・検証する観点。

公開相談では、小さな家族事業のサーバーを考える投稿者本人が、機器故障時に現地へ行けない場合の継続と、待機する別サーバーへ状態をそろえる難しさを質問しています。海外の一個人の相談で、本稿のレンタル会社の実話や国内需要の実績ではありません。本人の質問と本人の追加説明。

予約の一件を、画面から記録と受付結果までたどる

IT発注担当は、予約担当へ「お客様から予約を頼まれたとき、何を開き、どこで受付済みと判断しますか」と聞きます。機器名や構成図から始めるより、困る操作と、止まって困る理由を説明しやすくなります。

1. 空き状況を開く

   予約担当が、貸し出せる機器を探す入口です。

2. 予約内容を送る

   予約する内容をアプリ側へ渡す操作です。

3. 予約記録へ書き込む

   受付の元になる予約を、記録先へ残す処理です。

4. 受付結果を担当が確かめる

   送った内容と受付結果を同じ一件として確かめる終点です。

空き状況を開けても、予約を送れない場合があります。送信できても、記録先へ書き込めているか分からない場合があります。記録が残っていても、受付結果が担当へ返らず、同じ予約を再送したくなる場合があります。これらは想定する状態の違いで、この架空例で障害を観測した結果ではありません。

開発会社には、各操作がどのアプリと記録先を使い、ログイン確認や通信へどこで依存するかを説明してもらいます。二つのアプリが同じ認証先や記録先を使うなら、その部分の故障が両方へ及ぶ可能性を、別の確認事項として残します。構成がまだ分からない段階では、共通点があるともないとも決め付けません。

アプリ1台案と2台案を、同じ予約経路で比べる

二案は、構成を選ぶ前の未構築の提案です。アプリ側を増やす案にも、一つの予約記録先という仮案が残っています。実構成や故障試験の結果を表したものではありません。

図で確かめる問い：アプリを二台にした案でも、一つのまま残る予約記録先は、どこにあるでしょうか。

図を原寸で開く

図は、二案で同じ位置にある処理を対応させて読みます。アプリ側を増やすことと、予約記録先・認証・通信も故障へ備えられることは、別の説明が必要です。IT発注担当は、アプリの台数だけで案を選ばず、共通部分の扱いを開発会社へ質問してください。

未確認は「できない」という試験結果ではありません。同時に「たぶんできる」と補ってよい状態でもありません。未承認・未構築・未試験という表示は、この二案の現在の検討状態です。不採用の決定や、試験失敗を示すものではありません。

止められる時間と、失えない予約を業務側から確かめる

必要な備えは、予約が止まったときの仕事への影響で変わります。予約担当は、受付が必要な時間帯、待ってもらえるか、別の方法で受けられるかを説明します。IT発注担当は、その条件と技術案の前提をそろえます。この記事から一律の停止時間や稼働率を選ばないでください。

停止を待てないなら、共通故障点を残した案で条件を満たせるかを問い直します。条件付きで代替受付が使えるなら、その作業量と引継ぎも含めて比較します。どちらも不明なら、必要な観測と回答先を決めて案の採用を保留します。「高い方が安心」「台数の多い方なら合格」とは選びません。

要求を業務条件から書く全体像は、発注前の非機能要求を整理する方法で扱っています。稼働率の目標や測る境界を合意する段階では、SLA・SLOと測定条件の違いへ進めます。

切替の担当・判断条件・途中の予約を、構成と一緒に決める

切替方法の説明では、「自動か手動か」だけでは足りません。何を異常と見なし、誰またはどの仕組みが処理先を変え、その間の予約と結果をどう追うかを確認します。自動方式が常に正解とも、手動方式なら担当がすぐ対応できるとも決めません。

画面が開くことと、予約を保存できることを分ける

アプリの起動だけを見て正常とする仕組みでは、記録先への書込みができない状態まで分かるとは限りません。一方、監視のために実予約を勝手に作ることも避けたい作業です。どこまでの処理を、どのデータと権限で確かめるかを開発会社へ聞き、利用者が困る場所と監視の範囲を対応させます。

送った直後に結果が返らない予約をどうする？

「保存できなかった」のか、「保存されたが結果が届かなかった」のかを分けて調べる必要があります。担当が再送した場合に同じ予約が重なるおそれも、設計時に確認する問いです。元の受付と記録を何で特定するか、再送をどう扱うか、担当がどこへ問い合わせるかを決めます。この例には識別子の実値や具体的な再送方式はありません。

代替受付を使う案では、元の受付を残す人、システムへ取り込む人、同じ予約か確かめる人の役割を相談します。「紙で受ければよい」と決めて終わらず、貸出可能数の確認や、再開後の重複・漏れの照合まで行えるかが判断材料です。代替受付自体が許可されていなければ、実施済みとして描きません。

Microsoftの資料も、冗長な部分の正常・異常を見分け、切替を含む動作を検証する必要を示しています。複製や切替の設定が存在することだけを、途中の処理と記録が保たれる証拠にはできません。公式資料の検証観点。

開発会社の回答を、案の修正と未決事項へ戻す

回答は、構成案・運用の役割・検証方法へ反映して初めて比較に使えます。「対応できます」という短い返答なら、対象の故障と、予約のどの結果までを含むかを聞き直してください。

IT発注担当は、回答を受けた箇所だけでなく、影響する切替・途中記録・運用と試験条件を対応させて更新します。例えば記録先の方式が変われば、アプリ切替だけの試験計画のままでよいかを見直します。案の変更、業務上の了承、実装完了、試験で確認できた結果を、一つの「対応済み」にまとめないことが大切です。

許可された試験で、切替後も同じ予約を追えるか確かめる

構成と運用条件が決まったら、その案を検証する計画を作ります。実行してよい環境と対象の版、使ってよいデータ、想定する故障、試験を始める権限、中止・復旧を判断する人を先に決めます。本記事を根拠に本番のサーバーや通信を止めないでください。

1. 通常時の一件をそろえる。予約担当が空きを調べ、送信し、記録と受付結果を確認する始点・終点を決めます。どの情報で同じ予約と照合するかも、試す前にそろえます。
2. 対象の故障点を一つずつ計画する。アプリの片方、共通記録先、認証や通信などから、実構成と目的に合う対象を選びます。すべて同時に止める前提にはせず、安全に再現できる方法を技術担当へ確認します。
3. 処理の途中と、その後を分ける。送信中の予約がどう残るか、切替後の新しい予約を記録できるかを別々に確かめます。代替受付を採用したなら、その記録を重複・漏れなく照合できるかも試します。
4. 期待と実際と根拠を並べる。構成の版、故障条件、実施時の操作、対応する記録、観測した時間と担当の確認を残します。未実施・失敗・根拠不足を分け、見ていない範囲を合格へ足しません。
5. 修正後は、変わった条件へ戻る。切替方法や記録先が変われば、その影響範囲を再確認します。元の系へ切り戻す方式を選ぶなら、その後の記録と仕事も確認対象へ含めます。

障害後に注文を失わず仕事へ戻せるかという詳しい試験の組立ては、記録の照合から業務再開までの復旧テストで扱います。バックアップの保存から別環境への復元を確かめる作業は、バックアップの復元テストへ分けます。稼働中の故障へ備える設計、過去の状態へ戻す材料、実際に戻せるかの試験は、それぞれ役割が違います。

まとめ：台数を選ぶ前に、予約経路の共通部分を確かめる

予約を続けるための可用性設計では、サーバーの台数だけでなく、空き確認から記録・受付結果までの経路をたどります。アプリ側を二台にする案にも共通記録先などの確認が残るなら、その扱いと切替条件が必要です。

業務側は必要な時間と止まったときの影響を説明し、IT発注担当は同じ条件で二案を比べます。開発会社には、故障点、切替、途中の予約、代替受付、検証方法を答えてもらいます。回答がそろった案について、費用・運用とともに判断し、許可された環境で必要な結果を確かめてください。