Webアーキテクチャ設計の基本を学ぼう2（可用性編） - 低空飛行記録　fly or die autonomically

可用性の向上・理論編

　Webシステムはサーバー無しでは何もできない“サーバー頼み”のシステムである。そのためWebシステムを構築する際には，サーバーの「可用性（availability：サービスを継続して提供する能力）」について，十分な検討が必要となる。
・可用性とは何か
・どんな指標で表されるか
・それらの指標とシステム要件をどう結び付けるか
――などの理論面から考える

　可用性を十分に検討していないWebシステムでは，様々なトラブルが発生する。ユーザビリティに悪影響が出たり，二重更新などの異常動作を引き起こしたりする。
たとえばECサイトで商品を購入しようとして決済画面で納品先やクレジットカード番号などを入力し送信したところ，サーバがダウンしていて、エラーになってしまう。
数分後にはシステムが復旧したが、セッション情報が消滅してしまったため、初期画面に飛ばされてしまった。

　利用者にこうした不便を強いないように，Webシステムでは，ネットワーク，ハードウエア，ミドルウエア，アプリケーションの相関関係に配慮しながら，可用性を検討することが欠かせない。

■可用性について考える前に
　システムの状態を表す「稼働」「停止」という言葉について整理
一般的にカットオーバー後のシステムは，稼働か停止のどちらかの状態にあるはずだが，それぞれの状態はさらに二つに分類できる。
　

「通常運転」予定されている機能や実装をすべて使える状態
「縮退運転」一部が使えない状態

「計画的停止」事前の計画や予告に基づいて意図的に停止させること
「計画外停止」事前の計画や予告無しで異常停止した場合

■定量化できる可用性の指標
　厳密には可用性には
「継続的可用性（CA：Continuous Availability）」と「高可用性（HA：High Availability）」の二つがある。

　・継続的可用性（計画的であるか否かに関係なく，サービスが停止しない性質）を示す指標
　「無停止時間」＝システムが停止しなかった時間
　「平均故障間隔（MTBF）」＝総稼働時間/総停止回数

　・高可用性（サービスが停止することもあるが，稼働している時間的な割合が高いという性質）を示す指標
　「稼働率」＝カットオーバー後の経過時間に対して総稼働時間が占める割合「平均故障間隔/（平均故障間隔＋平均修理時間）×100」
※平均修理時間（MTTR）とは，障害発生から復旧までにかかった平均時間「総停止時間/総停止回数」

要はいかにMTBFを長くし稼働率を高めるか

■可用性にかける妥当な費用
予算規模を勘案し，可用性の要件のレベルを引き下げなければならないこともある。その際にも，指標値を使って定量的に意見交換すれば，交渉はスムーズにまとまりやすい。

可用性を高めるためにかける費用は，サービス停止によって発生するビジネス上の損失を上回るべきではない。

■システムの信頼度を計算
機器の平均故障間隔の情報を開示していることがあるので，その情報から故障率を求める。

信頼度＝e^（−故障率×期間）

※平均故障間隔（MTBF）の逆数が，故障率

ただし，このような計算が成立するのは，ハードウエアだけと考えた方がよい。それに，同じハードウエアでも，現実には設置状態（温度，湿度，振動など）によって故障率は変わってくる。ましてソフトウエアに起因する計画外停止を考慮に入れると，一般的にハードウエアは無停止か，あるいは年間1回程度の故障で済むように設計すべき。

可用性の向上・実装編

可用性の高いシステムを実装する
⇒平均故障間隔（MTBF）を長く，平均復旧時間（MTTR）を短くする
⇒平均故障間隔の短い単一故障個所を減らす
⇒その実装方法は単純に「単一故障個所となる構成要素を並列に複数並べ，単一故障個所とならないようにすること」つまり「冗長化」となる。
　Webシステムにおける冗長化設計では，内部的に冗長化されたハードウエアを採用することと，ソフトウエアやネットワークを含むシステム全体を冗長化することの両面を検討する。

■内部を冗長化したハードウエア
　平均故障間隔の短い単一故障個所がハードウエアであれば，内部的に部品を冗長化したものを選ぶ。
　例えば，最近ではミッドレンジ以上のサーバー機はファンや電源ユニットなど壊れやすい部品を冗長化していることがある。
　信頼度をさらに向上させる必要があれば，筐体内部のあらゆる部品を冗長化したハードウエア（FTサーバーetc）を選定する方法もある。
　ただしFTサーバーは，通常と比べて価格は数倍になる。このためWebシステムで利用する場合は，一般的にDBMSなど重要度の高いサービスの提供や，シングル・サーバー構成のときに用いる。それ以外の場合は，FTサーバーを採用して単体の信頼度を上げるよりも，システム全体の冗長化と絡めて検討した方が，拡張性とコスト・パフォーマンスが上がる。

■システム全体の冗長化
　Webシステムは，HTTPD，APコンテナ，DBMSを別々のサーバー機に実装することが多いため，ネットワークやソフトウエアの障害も考慮に入れつつ，システム全体としての冗長化を検討する必要がある。
　ポイントになるのは，データや状態の再現が可能かどうか
・データや状態の再現が完全にはできない「負荷分散クラスタリング技術」
・データや状態の完全な再現が可能な「HA（High Availability）クラスタリング技術」

・負荷分散クラスタリング技術
　サーバー機を複数設置し，それぞれで異なるリクエストを同時並行で受け付ける技術
「分散制御ソフト」で集中管理しており，分散制御ソフトは同じクライアントからのリクエストを同じサーバー機に振り分けるなどの調整を行う。サーバー機は，それぞれ別々に異なるデータや状態を保持している。
　障害が発生したサーバー機で処理した内容（データや状態）を，ほかのサーバー機に引き継ぐことはできない。復旧の完全性に欠けるという弱点はあるが，簡易な仕組みで平常時の処理の高速化やスループット向上を実現できる利点もある。そのためWebシステムでは，WebサーバーやAPサーバーの可用性向上に負荷分散クラスタリング技術を適用することが多い。
　
ケースとして「障害が発生しても，できるだけサービスを止めたくない」「障害が生じたサーバーで処理中のリクエストを送ったユーザーには，エラーを返して再処理を求めても構わない」「安価に性能と可用性を向上したい」といったリクエストに対応して採用する。

・HAクラスタリング技術
　復旧の完全性を求められるときに利用する。Webシステムでは，DBサーバーの可用性向上に多用される。障害で停止したサーバー機のセッション情報を失わないことを目的に，WebサーバーやAPサーバーに適用されることもある。

　障害が発生したサーバーの情報を引き継いで作業を継続することを，「フェールオーバー」と呼ぶ。
　HAクラスタリング技術の代表的な実装形態が，「Active-Standby構成」＝「複数台のサーバーの中から1台以上を待機系として休眠状態にする方法」

　HAクラスタリング技術でサーバー機のデータや状態を保持する共有ディスクは，SANやNASといったネットワーク共有型の物理ディスクを使うことが多い。しかし，ミラーリング（同期）を設定した複数の物理ディスクや，レプリケーション（複製）している複数のデータベースなどを，共有ディスクの代わりに使うこともできる。クラスタリング・ソフトによっては，各サーバー間のメモリー間通信を利用して，メモリー空間を共有ディスクの代わりにするケースもある。

- - - - 続く