非機能要件の中の可用性の説明です。
可用性とは、システムが停止することなく稼働し続ける能力のことで、稼働率で表すことができます。
ここでは、この可用性を要求定義や要件定義でどのように決めていくのかを説明していきます。
１．サービス提供時間
稼働率を決める前に、サービス提供時間を決める必要があります。
２４時間提供なのか、１時間だけシステム停止をして２３時間提供なのか、あるいは８時から２２時などの日中帯だけの提供なのか、さらには土日祝日は終日停止して平日日中帯のみの提供なのか、といったことを決めます。
２．稼働率
どの程度のサービス停止に耐えられるのかを、ユーザー部門と合意します。
丸１日耐えられるのか、半日なら耐えられるのか、１時間なら耐えられるのか、といった障害１回に耐えられる時間と、年に１回なら許容できるか、月に１回でも許容できるか、といった頻度の２つの観点で、サービス停止許容時間を決めます。
そのサービス停止許容時間とサービス提供時間から稼働率が求められます。
その稼働率（目標稼働率）によって、システムの冗長構成が決まってきます。
以下のケース１の場合、目標稼働率が９９．５％です。復旧作業に４時間かけられるので、コールドスタンバイかウォームスタンバイ程度の冗長構成で十分です。
以下のケース２の場合、目標稼働率が９９．９％です。復旧作業に１時間しかかけられないので、冗長構成はホットスタンバイが必要となります。
以下のケース３の場合、目標稼働率が９９．９８％です。復旧作業にかけられる時間はケース２と同じですが、夜間であっても休日であっても１時間しかかけられないので、２４時間体制で復旧できるオペレーターが常駐するか、そうでなければクラスタリングが必要となります。
またこの目標稼働率は、年間なのか月間なのかで大きく違います。
上記例は年間ですが、ケース１の目標稼働率９９．５％でも、それが月間だった場合、休日であっても４．３５時間での復旧が必要となり、ホットスタンバイ、あるいはクラスタリング構成が必要となります。
このように目標稼働率が同じでも、それが月間の場合には一般的に年間より１段階上の冗長構成が必要となります。
そして、これらがSLAやSLOの重要な指標となり、受入テストもこの時間を目安に合否判定することになります。
３．回復性
バックアップとその復旧について、RPO（目標復旧時点）とRTO（目標復旧時間）という指標で、どのレベルのバックアップ方式とするかを決めます。
そしてこのRTOは、受入テストでの合否判定の目安にもなります。
以下のケース１の場合、バックアップの対象がデータベースのデータだけであれば毎日深夜にデータをEXPORTすれば要件を満たすことができます。
以下のケース２の場合には、データベースの更新ログ等からの復旧が必要となるので、OracleであればRMANによるバックアップ等が必要となります。
またバックアップについては、何世代保持するかも決める必要があります。
バックアップデータは大容量となるため、世代数によって必要なDISK容量が大きく変わります。
サポート体制が３６５日であれば、バックアップの世代は３世代もあれば十分ですが、ゴールデンウィークや年末年始を休むような体制だと７〜１０世代は必要となります。システムで障害を検知できるケースは、ゴールデンウィークや年末年始であっても速やかな復旧が可能ですが、ユーザーからの問合せで発覚する障害の場合、ヘルプデスクが休みだと営業日に初めて障害を認識するという事態が想定されるためです。
４．災害対策
大規模災害が発生し、データーセンターが倒壊や通信不能に陥った場合について、DR（Disaster Recovery）環境の有無を決めます。
大規模災害の場合、１週間から１ヶ月程度はデーターセンターが復旧できないと想定されるので、その間、業務運用で耐え凌ぐことができればDR環境を用意する必要はありません。逆に頑張っても数日レベルであればDR環境が必要となります。
DR環境を用意する場合には、RPO（目標復旧時点）とRTO（目標復旧時間）、RLO（目標復旧レベル）で、対策のレベルを決めます。
RPO（目標復旧時点）が発災時点であれば、リアルタイムに同期を取る仕組みが必要です。DR環境を用意する場合、通常はリアルタイム同期となります。
RTO（目標復旧時間）は復旧時間のスタートをいつにするかを明確にする必要があります。通常、DR環境への切り替えは人手で行うため、大規模災害では人命救助を優先させるため、切替判断には時間がかかります。常識的に考えれば、RTOは切替判断が出てからの復旧時間となりますが、それを明記しておかないとユーザー部門が勘違いする可能性があります。
例えばRTOが２４時間の場合、ユーザー部門は１日だけ辛抱すれば良いと思ってしまいますが、実際には切替判断までに数日を要することが多いため、業務運用で凌ぐのは４、５日となります。ユーザー部門は大規模災害が発生すると、すぐにDR環境に切り替ると勘違いしているケースが多いので、注意が必要です。
RLO（目標復旧レベル）はバックアップの際にも用いることがありますが、通常のバックアップからの復旧は全面復旧なので、あまりRLOを使うことはありません。この指標は例えば復旧時に何らかの縮退運転を許容する場合に、例えば50%のユーザー数に耐えられるレベルまで復旧、バックアップオフィスでの業務再開まで復旧といった指定をします。
RLOはDR環境のスペックに影響します。50%の縮退運転が許容されるのであれば、CPIUやメモリーを削減することができます。
またDR環境を構築する場合、外部システムの制約を明らかにしておく必要があります。自分たちがDR環境に切り替っても、外部システムが切り替らない場合には、連携部分で制約が発生します。また外部システムもDR環境に切り替ったとしても、同じタイミングで切り替る保証がないため、その点も設計時に考慮が必要となります。
DR環境に切り替った後のことも決める必要があります。元の環境に戻す仕組みとするか、一方通行とするかで、前者は後者よりも費用がより多く発生します。
BCPをシステム部門主導で進めると、DR環境のことだけに目がいってしまいますが、人の命に関わるような社会インフラでない限り、DR環境無しで耐え凌ぐ方法を考える方が現実的です。
単純なシステム環境だけであれば、AWS等のクラウドを利用すれば比較的簡単に実現できますが、それを運用するシステム部員の作業環境は自分たちで用意しないといけません。ましてやオンプレの場合には、DR環境を構築する費用は膨大なものになります。
東日本大震災クラスでもDR環境は不要であったことを考えると、利用するかどうか分からないDR環境にお金をかけるよりも、その分の費用を災害が発生した場合の補填にすることを考える方が建設的だと思います。
【振り返り】
今回は可用性の説明でした。次回は性能の説明をしていきたいと思います。
①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ／アクセシビリティ
⑧システム環境
