1.5 地理分割型アーキテクチャ
ここまでで、サーバーを垂直または水平に分割するアーキテクチャを説明しました。これらのアーキテクチャを組み合わせることで、より目的に適した構成を取ることができます。
本節では、業務継続性およびシステム可用性を高めるための方式として、地理的な分割を行なうアーキテクチャについて説明します。
1.5.1 スタンバイ型アーキテクチャ
図1.10は、スタンバイ構成、HA（High Availability）構成、アクティブスタンバイ構成などと呼ばれる形です。物理サーバーを最低2台用意し、1台が故障した場合に、稼働していたソフトウェアをもう一方の物理サーバーで再起動させる方式です。
この再起動を自動で行なう仕組みを「フェイルオーバー」とも言います。格好つけて「フェイル」「F/O」と呼ぶ人もいます（フェイルオーバーについては、第7章でも詳しく説明します）。
この方式では物理サーバーの故障からは保護されますが、普段はフェイルオーバー先のサーバー（スタンバイ）は空いているので、リソース面で無駄が生じます。
投資対効果が低いと、CIO（最高情報責任者）から怒られる原因ともなります。これを解消するため、スタンバイを用いず、両方のサーバーを同時利用し、たすき掛けにする（一方が故障した場合には、他方で両方の処理を行なう）ことも多くあります。
なお、物理サーバーではなく、仮想化されたサーバーを利用している場合は、サーバー上のソフトウェアだけでなく、仮想サーバーごと別の物理サーバーにフェイルオーバーさせるような方式も選択肢の1つとなります。
1.5.2 災害対策型アーキテクチャ
激甚災害は、昨今では現実的なものとなりました。インフラアーキテクチャにおいても、災害に備えたディザスタリカバリ（Disaster Recovery）構成を取ることが多くなっています。
具体的には、特定のデータセンター（サイト）にある本番環境が利用できなくなった場合に、別サイトにある災害対策環境で業務処理を再開できるようにすることを指します。
図1.11のようにサーバー機器を、最小構成～同等構成で別サイトに配置し、ソフトウェアも本番環境と同等に設定します。災害が発生した際には、図1.12のように、完全に別サイト側の情報を利用することになります。
ここで課題となるのは、アプリケーションの最新化と、データの最新化です。特にデータは日々更新されるものなので、ある程度のリアルタイム性を持って、サイト間の同期処理を行なう必要があります。
ストレージ装置の機能、OSの機能、データベースの機能など、同期を行なう手段はいくつもあります。それぞれのコスト、対象となるデータ、同期遅延特性などを考慮して、決めていく必要があります。
Column
技術は受け継がれている
ハードウェアやソフトウェアにおいて日々新しい技術が登場してきますが、意外と基本的な仕組みは変わっていないように思います。
たとえば、マルチプロセスシステム、仮想記憶システム、ファイルシステムといった機能は特に意識せずに空気のように使っていますが、元々は汎用機の時代に開発された仕組みです。
汎用機のOS、商用UNIX、Linux、Windowsなどの各OSは使い勝手や見た目は異なりますが、そのコアには共通点が見られ、過去から技術を継承してきたのがわかります。
現代のコンピュータは75年前にノイマン氏［※2］らが考案した原理から基本的には変わっていないと言われています。筆者は古い技術書などを読んでルーツや設計思想を調べるのが好きです。やや趣味の世界ではありますが、元々の設計思想などを知ると視野が広がり意外なところで役に立つこともあります。
