高可用化のためのソフトウェア修正

多くのソフトウェアには設計ミスやバグ等の不具合が存在し，これはネットワークサービス を提供するソフトウェアも例外ではない．不具合の修正にはプロセスやOSの再起動が必要な ためサービスが停止し可用性が低下する．

本来ソフトウェアに一切不具合がなければ修正の必要はない．電話サービスのように広範な ユーザに対してライフラインたるサービスを提供するソフトウェアにおいては，開発時の品質 を十分高くしている．

しかし今日の高度なサービスを提供するために，ソフトウェアが大規模化・複雑化しており 不具合が数多く潜在する．また実サービスでは設計時とは想定外の入出力・負荷・機能追加が 生じるケースが多く，数多くの修正が必要となる．これら修正を実施する方法として次に示す 二つの修正手法が存在する．

オフライン修正 広く使用されるソフトウェアの修正方法として，修正した新たなロードモ ジュールを再度ロードする方法が存在する．修正した新たなロードモジュールを作成するため にソースパッチとバイナリーパッチによる修正が行われる．

ソースパッチによる修正とは，ソフトウェアに不具合が存在した場合，ソースコード自体に 修正を施し，コンパイル，リンクを経由することで修正した新たなロードモジュールを作成す るものである．

バイナリーパッチによる修正とは，問題を含むロードモジュールを直接書き換えることで修 正した新たなロードモジュールを生成する方法である．

上記いずれの修正方法においても，システムは現在動作しているプロセスやOSを終了し，

修正した新たなロードモジュールを再度ロードすることで，修正済みのソフトウェアを実行す る．これら修正手法をオフライン修正と呼ぶ．

ちなみにオフライン修正を用いているシステムでの高可用化の方法として，修正済みのロー ドモジュールを冗長化されたシステムの待機系に適用し，稼動系の切換を実施する方法が考え られる．しかしこの方法では電話サービスの可用性を保つことができない．

これは呼処理を行うソフトウェアは膨大なセッション情報を即時アクセス可能なメモリ上に 保持することに起因する．稼動系の切換の際には既に提供中のサービスを漏れなく引き継ぐた めに，メモリ上に存在するセッション情報の同期が必要となる．このため稼動系の切換に長時 間を要し，サービスの停止時間が増加する．

また稼動系と待機系を同時に稼動し，新規の呼を待機系に割り当て，稼動系の呼がすべて解 放された時点で，稼動系を停止し修正を行う方法も考えられる．しかし稼動系と待機系を同時 に稼動させるためには複雑なシステム構成と処理ロジックをとる必要があり，システム構成へ の制約が大きい．そこで次に示すオンライン修正が必要となる．

オンライン修正 電話サービスのようにライフラインたるサービスでは24時間365日連続 してサービスを提供し，年間のサービス可用性が99.999%以上であることが要求される[2]． このためソフトウェアの不具合修正によるサービス停止時間が多大になることは許容されず，

サービスのタイムアウト値以内でソフトウェアの修正を行い，可用性を低下させない手法が必 要となる．

事前に修正したロードモジュールを準備し，修正対象プロセスやOS等のプログラムを終了 し，修正した新たなロードモジュールを再ロード，かつサービス再開まで状態遷移がサービス のタイムアウト値以内に可能であれば前述したオフライン修正でも問題はない．もしくは冗長 化構成のシステムにおいて，あらかじめソフトウェア修正を施したシステムへの稼動系切換処 理によるサービス中断時間が，タイムアウト値以内であれば問題はない．しかしソフトウェア の大規模化・複雑化により，サービス再開までの一連の状態遷移は，数秒から数分オーダの時 間を要する．

このため修正対象プロセスやOSを終了することなく，修正対象プロセスや，OSの根幹た るカーネルのメモリ上の実行コードを直接修正し，サービスの停止時間を極小化するソフト ウェア修正方法が要求される．この修正方法をオンライン修正と呼ぶ．

3.2.1 既存のオンライン修正方法及び関連技術

本項においては，既存のオンライン修正方法及び関連技術について示す(表3.1)．

専用コンピュータを用いる交換システムのオンライン修正

専用コンピュータを用いる交換システムのソフトウェアのオンライン修正方法として，専用 のOSで実現されるC++言語のオンライン修正[3]が存在する．本機能は次のステップから 実行される．

• 一つ以上の修正されたC++のクラスを有するプログラムが一つの再配置可能な修正用 ロードモジュールとしてコンパイルされる．

• 修正用ロードモジュールが，交換機上に存在するオンライン修正用の専用ローダに渡さ れる．

• オンライン修正用のローダでは，修正用ロードモジュールを読み込む新たな固定メモリ 領域を確保する．次に確保された固定アドレスを先頭アドレスとするよう修正用ロード モジュールのアドレス再配置を行い，確保されたメモリ領域へ修正用ロードモジュール をロードする．

• オンライン修正用のローダは，メモリ上に存在する既存の修正されるべきクラスのシン ボルのアドレスに，修正用ロードモジュールに含まれる新たなクラスのシンボルへの jump命令，ポインタ，値へと書き換える．これにより新たなクラス，メンバは既存の クラス，メンバを経由して呼び出される(図3.1)．

このjump命令は修正用の関数に実行アドレスを遷移させる．またjump命令はスタッ クをプッシュしないため修正用の関数が終了する際には，スタックをポップし，jump 命令が上書きされた関数を呼び出した処理に復帰する．

C++言語のオンライン修正が適用された交換機では，サービス処理部分及びカーネル部分 等，サービスに使用されるソフトウェアの全域を修正可能である．

しかしC++言語のオンライン修正の前提となる交換機のOSは仮想記憶を使用しておら

ず，Linuxとはメモリ管理方式が異なる．またシングルプロセッサの専用ハードウェアを使用

しており，汎用マルチプロセッサを利用するためのスケジューリング機能や排他機構等のカー ネル機能を有しておらず，汎用マルチプロセッサシステムへの適用が困難である．

Java Hotswapによるオンライン修正

Javaでのソフトウェアのオンライン修正方法として，プログラム実行中に Javaのバイ トコードを変更することが可能な Hotswap機能 [38] が存在する．Hotswap 機能はJava Platform Debugger Architecture(JPDA)の一部であり，主に開発時の効率的なデバッグを 実現する目的の機能である．またHotswapの機能をベースに実運用への適用を目的に改善を 行った研究[39]も存在する．

表3.1.既存のオンライン修正方法の比較

方式 既製コンピュータへ

の適用

高速性 修正可能エリア

専用コンピュータを 用いる交換システム のオンライン修正

×:専用コンピュータ のみで実現可能

○:オンライン修正で あり高速

○:ユーザソフトウェ ア，カーネルに適用 可能

Java Hotswap

○:Linuxで使用可能 ○:オンライン修正で あり高速

×:JavaVMプロセス 内のユーザタスクの み適用可能

kexec による kenrel の高速再起動

○:Linuxで使用可能 ×:高速再起動である が初期化が必要

△:カーネルへのみ適 用可能

Hotswap機能は既製コンピュータに適用可能であるが，修正可能なソフトウェアがJavaVM

上で動作するプログラムに限定される．JavaVM自体及びOS等，サービスに使用されるソフ トウェア全域を修正することができない．

kexecによるカーネルの高速再起動