 |
インターネットを利用したBtoCシステムでは，24時間稼働が要件となる場合が多い。24時間稼働システムとはいえ，すべての部位が24時間稼働するものだと思ってはいけない。ユーザーが語る「24時間稼働」という要件の裏に隠された「非24時間稼働部位」の必要性に注意すべきである。これに注意しないと，安定稼働するシステムを作るのは難しい。
インフラを開発・運用する立場から見ると，まずは保守性の問題がある。「止められない」という制約の中，どのようにしてリソースの拡張などの保守作業を行うか，という問題である。BtoCシステムで一般的に採用される3階層Webシステムでは，フロント寄りであればあるほどスケールアウト方式によって無停止での拡張が容易であるが，バックエンド寄りであればあるほど無停止での拡張は困難となる。コストもかかる。また，拡張が必要になるタイミングは，フロント寄りであればあるほどトラフィックが増えたときで，バックエンド寄りであればあるほどデータ量が増えたときである。すなわち，データ量増大に対する拡張対応は，無停止ではなかなか難しいということになる。
また，業務あるいはアプリケーションの観点でも，完全無停止のアプリケーション実装はハードルが高い。すべての業務がリアルタイムで処理できることはまれであり，なんらかのバッチ処理が存在することは多い。バッチ処理を開始するためにはDBのスナップショット（静止点）が必ず必要になるし，バッチ処理を行いつつオンラインを提供可能なテーブル構造（データ構造）を設計することは難しい。
バッチ処理はバックエンドで行われるため，無停止での拡張はフロントと比較して困難である。24時間稼働サーバーでバッチ処理を行うことは，保守性の観点で非常にリスクが高い。仮に実行できたとしても，バッチ処理はサーバーのリソース（CPU，ディスクI/O）利用においてピーク性が高く，バッチ稼働時間帯のオンライン・レスポンスに対して悪影響を与えかねない。
こうした問題を解消するために，バッチ処理できる部分をオンラインのシステムから分離してバッチ・サーバーを設置する場合がある。当然，バッチ・サーバーは24時間稼働の範囲ではない。このように24時間稼働部分と，そうでない部分に分けた構成を取ることで，性能や信頼を高めやすくなるのである。
ここではバッチ処理を例に挙げたが，24時間稼働部分とそうでない部分に分けた構成にする主な目的は，以下の2点に集約される。
目的（1） 無停止保守が困難な部位の保守時間の確保
目的（2） バッチ処理などによるオンライン・サービスへの無影響化
24時間稼働システムのインフラを設計する場合は，この2点を常に意識してシステム全体の構成を見渡してほしい。ユーザー要件である「24時間稼働」を実現するために必要な「非24時間稼働」部分を見極めるのだ。
ネットワークやストレージも忘れずに
このような設計を行う場合は，もう一点，注意が必要だ。ちょっとした見落としがあるだけで上記二つの目的が達成できず，システム全体を停止しなければならないような事態に陥るケースがある。
一つ例を挙げて，考えてみよう（図1）。バッチ・サーバーはバッチ稼働時間帯のみの稼働とする。ストレージはSANを利用した統合ストレージを採用している。ストレージ・メンテナンス時の影響を考え，DBサーバーとバッチ・サーバーで別筐体のストレージを準備する。オンラインを無停止のままDBサーバーからバッチ・サーバーにデータ・コピーを行う方式は，ストレージ・ユーティリティを利用した以下の方式とする。
 |
| 図1●24時間稼働システムの例 |
- ストレージ・ユーティリティの機能でDB領域をレプリカと同期
- DBサーバーのDBMSをREAD ONLY化
- ストレージのレプリカ領域切り離し（数秒）
- DBサーバーのDBMSをREAD/WRITE化
- バッチ・サーバーがレプリカをマウントして処理開始
バッチ処理などによるオンライン・サービスへの無影響化（目的（2））はこれで実現できた。ただし，構成図を見た読者は何か気づかないだろうか？SANを構成するFC（ファイバ・チャネル）スイッチがDBサーバーとバッチ・サーバーで共用されている。これでは，目的（1）の「無停止保守が困難な部位の保守時間の確保」が達成できない。バッチ・サーバーの拡張要件でFCスイッチをメンテナンスする際にDBサーバーも停止せざるを得ないからだ。せっかく高価な統合ストレージを導入して，複雑なデータ・コピー方式を検討したことが無駄になってしまう。
サーバーには目が行きやすいが，サーバー間をつなぐ共通インフラ（ネットワーク機器，ストレージ機器など）は見落としやすい。十分に注意が必要である。
|
