24時間止められないシステムのためのアーキテクチャ：こんな時にはこのITアーキテクチャ （4）

システムのメンテナンス時でもユーザーに対するサービスが停止せず24時間365日システムが利用可能なことを連続可用性（continuous availability）という。メンテナンス時でもサービスを停止させないためには代行システムを用意するか、システムを2系列持つことが必要になるが、複数システム間でデータをいかに同期させるかがポイントとなる。

[河野紀昭，日本IBM ICP-エクゼクティブI/Tアーキテクト]

　高可用性とは計画停止以外ではユーザーに対するサービスを止めないということだったが、連続可用性（continuous availability）ではメンテナンス時でもサービスを止めないことが要求される。これは、「言うは易く行うは難し」で、ハードウェアを増強する、OSやミドルウェアをバージョンアップする、アプリケーション・プログラムを入れ替えるといった保守作業ではサーバを止めて作業することが多い。

　連続可用性を実現するために、まず採用される保守方式がローリング・メンテナンスだ。ローリング・メンテナンスでは、保守対象サーバを一斉に止めるのではなく、図1のように、クラスタリングされているサーバを1つずつ止め、残りのサーバでサービスを継続しながら、保守作業を行う。

図1 ローリング・メンテナンス

勘所：ローリング・メンテナンスを活用して連続可用性を実現しよう

　ローリング・メンテナンスを行う場合の注意点は、クラスタ構成では新旧バージョンの混在が起こることだ。ハードウェア増強やソフトウェアのFIX適用などでは、新旧混在しても問題ない場合が多いが、アプリケーション・ロジックの変更の場合、図2のようにユーザーAが新ロジックで動いているのに、ユーザーBは旧ロジックでは困る場合があるだろう。

図2 ユーザーAが新ロジックで動いているのに、ユーザーBは旧ロジックでは困る

　このような場合、アプリケーション・ロジックが決められた日時で切り替わる仕組みを組み込んでおき、指定日時までは以前と同じロジックで稼働するようにしたうえで、ローリング・メンテナンスにより事前に新ロジックを組み込んでいけばよい（図3）。

図3 事前に新ロジックを組み込んでいけばよい

　これ以外の方法としては、例えば4台のサーバを2台ずつに分け、旧2台のペアから新2台のペアに一斉に切り替えるという方法もある。いずれにしても、新旧バージョンの混在をどのように扱うかがローリング・メンテナンス実施上のポイントとなる。

勘所：ロジック切り替えタイミングを意識してローリング・メンテナンスを実施しよう

　DBMSをバージョンアップしたいとか、データベースの構造を大きく変えたいといった場合にはデータベースを止める必要があり、ローリング・メンテナンスでは対応が難しい。このような場合でも連続稼働を実現したい場合には、代行システムを用意し、メンテナンス中は代行システムを動かすといった仕組みが必要になる（図4）。

図4 代行システムを用意し、メンテナンス中は代行システムを動かすといった仕組みが必要

　代行システムを構築するうえで重要なのはデータの引き継ぎである。代行開始時に必要なデータを本番から代行側にコピーすることと、代行終了時に代行システムで実施した処理結果を本番に反映させることが必要である。

　口座残高を扱う場合など、本番システムと代行システムでデータが食い違ってはいけないケースでは、本番を停止させてから、本番から代行にデータを反映させ、データ反映後に代行でのサービスを開始する。この手順では、データ反映中はサービスが停止することになるが、サービス停止中にデータの全量をコピーするのは時間がかかる。停止時間を短くするために、本番の稼働中のある時点でデータをいったんコピーしておき、コピー時点から代行切り替え時点までの更新ログを保管して、代行切り替え時に代行側にログのみを適用する方式を用いるとよい。

勘所：ログ反映方式により、代行切り替え時間を短縮しよう

　上記の方法でも、ある程度の切り替え時間が生じるのは避けられない。切り替えのための停止時間を限りなくゼロに近くするためには、システムを２つに分け、リアルタイムに更新内容を送り合って、どちらか一方のシステムでも最新のデータで処理を行うことができるようにする 工夫が必要だ。センターを地理的に離れた場所に2つ設置し、災害対策を兼ねた設計とする方法もある（図5）。

図5 センターを地理的に離れた場所に2つ設置

　2センター方式は連続可用性の観点では優れているが、データベースを2重に更新する処理コストや更新内容を送り合う通信コストが掛かる。前回の高可用性の議論と同様に、エンドユーザー・サービスの観点から、システムを連続可用性が必要な部分とそうでない部分とに分離し、必要な部分で連続可用性を実現することを考えたい。

勘所：連続可用性の必要性に応じてシステムの構造化を行おう

「こんな時にはこのITアーキテクチャ」バックナンバー

• 変化に強いシステムのためのアーキテクチャ
• 使いやすいシステムのためのアーキテクチャ
• 24時間止められないシステムのためのアーキテクチャ
• 高可用性システムのためのアーキテクチャ
• 大量トランザクション処理に適したアーキテクチャ
• 良好なレスポンスを実現するアーキテクチャ