可用性を高める

 図1上は,可用性を配慮していないシステム構成だ。サーバー機は1台しかなく,そのサーバー機が壊れるとシステム全体が停止する。このような場合のサーバー機のことを「単一障害点」と呼ぶ。システムの停止時間は,故障個所を修理して復旧するまでの間であり,この時間を「故障修理時間」という。

図1●2台以上のサーバーで運用すれば可用性が上がる
図1●2台以上のサーバーで運用すれば可用性が上がる
サーバー1台で運用すると,故障修理時間分だけサービスが停止する。だが,2台以上で運用すれば,全サーバーで同時に障害が発生しない限り,サービスは継続できる
[画像のクリックで拡大表示]

 これに対して,図1下で表すように2台以上のサーバーを配置して冗長化すれば,単一障害点はなくなる。故障修理時間中は「縮退運転(処理能力などを小さくして運転を続けること)」となるものの,システム全体を停止させずに済む。つまり,可用性は高まる。

 サーバー数を増やして冗長化すると可用性は高まるが,システム停止の可能性がゼロになるわけではない。だが,文字通りに“止まらないシステム”を目指すとコストが高くつきすぎて(数億円必要なケースもある)現実的ではない。

 可用性においては,サービス停止に伴う機会損失額を把握し,それに見合う対策方法を設計することが肝要だ。実際には障害から障害までの平均時間を示す「平均故障間隔(MTBF)」を長くすることと,「平均修理時間(MTTR)」を短くすることを意識し,システム設計することが必要になる。ハードウエアの選定ではベンダーに平均故障間隔を問い合わせ,その時間の長いものを選ぶといったことを実施したい。そのほか,ミドルウエアやアプリケーションの設計次第で,平均修理時間が変わることにも注意を払いたい。

 今回の要件では,「1時間以内のサービス停止は認める」とのことなので,単一障害点があってもかまわない。ただし,機材調達などの時間を考えると,予備のサーバー機と合わせて2台以上は必要だろう。

パフォーマンスを向上させる

 パフォーマンスの向上策は,システムの特性を考慮して決定する。一般に,参照主体のシステムと更新主体のシステムでは,要件がトレードオフの関係にあることが多い。

データの一貫性をとる方法に気を配る

 参照系システムの場合は,多くのサーバーで分散処理することで,パフォーマンスを高められる。このため,参照系のWebシステムでは,サーバー機の台数を増やす「スケールアウト」が向いている(図2左)。これに対して更新系の場合は,多くのサーバーにデータが点在すると,データの一貫性をとるためのオーバーヘッドの方が大きくなる。つまり,データを集中管理した方がパフォーマンスを高められる可能性が高い。システム構成としては,サーバー機の単体性能を上げる「スケールアップ」が向いている(図2右)。

図2●要件に適したパフォーマンス向上策
図2●要件に適したパフォーマンス向上策
パフォーマンスを向上させるには,参照系と更新系とで要件が異なる。一般には,参照系の場合は「スケールアウト」,更新系の場合は「スケールアップ」が向いている
[画像のクリックで拡大表示]

 データの一貫性をとるには複数の方法がある。主DB(マスター)から従DB(スレーブ)に一方向でデータを更新する「マスター/スレーブ方式」と,すべてのDBが等しくデータを更新し合う「マルチ・マスター方式」がある。それぞれの方式には,更新データを即座に転送する「同期型」と,定期的に転送する「非同期型」がある。

 マスター/スレーブ方式の場合,更新負荷は(マスターに集中し)分散できないので,更新の多い業務には向かない。マルチ・マスター方式は,参照負荷も更新負荷も分散できるが,マスター間で整合性を保ってデータを更新するメカニズムが複雑になり,マスター/スレーブ方式よりもパフォーマンスは劣化する。同期型は,トランザクションの一環として変更内容をスレーブにコピーするのでデータの保全性は高いが,レスポンス時間が長くなる。非同期型はその逆である。

「参照系がほとんど」なのでマスター/スレーブに

 パフォーマンスについて利用者から明確な要件が示されることは少ない。だがシステム構成を決める際は,漠然とした要件では不十分で,単位時間に処理すべき件数(=スループット)を把握することが必要になる。その基になるのは,利用者の数,ピーク時にアクセスする利用者の割合,利用者のページ遷移間隔(思考時間や入力時間を含む)などである。これらを基にピーク時のアクセス数を試算し,システムに求められるスループットを求める。

 今回の要件では,「ピーク時の同時利用者は100人」「ページ遷移の平均時間は5秒」なので,同時アクセス数は100÷5=20件程度と推測できる。この程度のスループットなら最近のサーバー機では1台で十分だが,「古いPCサーバーを再利用したい」という要件があるので,各層のサーバー機をそれぞれ2台とする。

 そのほか,「参照系がほとんど」「障害時に数件程度のデータ欠落は許容範囲」という要件なので,DBサーバーのデータ同期には,非同期型のマスター/スレーブ方式であるオープンソースのミドルウエア「Slony-I」を用いる。パフォーマンスを高めるために,参照系はマスターDBとスレーブDBの両方に振り分けるが,更新系はマスターDBにのみ振り分ける。

 こうして完成したシステムの全体像が図3である。Web/AP/DBの各サーバーは複数台用意することになったが,「できるだけコストを抑えたい」「障害時の数件程度の再入力は許容範囲である」という要件があるので,負荷分散装置は導入せず,Webサーバーに対するリクエストは「DNSラウンドロビン」で振り分ける。APサーバーへの振り分けには,Apache HTTP Serverの負荷分散モジュールである「JK2」を用いる。図3が唯一の解ではないので,読者ごとに考えた自分なりの解と見比べてみてほしい。

図3●参照と更新のDBを分けたシステム構成例
図3●参照と更新のDBを分けたシステム構成例
参照系のリクエストが多い,データ保全性の要件が厳しくない――という二つの要件から,非同期にDBのデータを同期させる「Slony-I」を採用した
[画像のクリックで拡大表示]

高安 厚思(たかやす あつし) オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト
銀行系シンクタンクでオブジェクト指向技術の研究に携わった後,大手SI業者でアーキテクチャ構築やプロセス研究を担当。現職ではSOA(Service Oriented Architecture)を中心とする研究開発とアーキテクチャ構築に従事している