Javaの特性を考慮してこれらの要求を考察してみる。
まず、最も大きな違いは、JITコンパイルを伴った中間コード(バイトコード)による実行にある。
システムが、VoIP呼処理での使用に耐えるような十分なパフォーマンスを狙うのであれば、種々 の改善が必須である。JITコンパイラは重要な役割を果たしている。JITコンパイラは、頻繁にア クセスされるメソッドを、ネイティブコード(機械語)にコンパイルすることにより、処理の重いバ イトコードの逐次実行(interpretation)を避けるものである。実質的には、メインルートにおける全 てのJavaメソッドは、ネイティブコードに変換される。さらに、JITコンパイラは、頻繁に使用さ れるメソッドを、サブルーチン呼出形式ではなく、インラインに展開する。インライン展開された メソッドに修正の必要がある時、修正済みのコードをいかにリンクするかは、Javaオンラインプラ グイン機構として解決しなければならない課題である。
5.4. 既存の部分プログラム入れ換え技術 59
added data ( only ref erred to b y new task s) f u nc tion
c all ( method c all)
memory area
management online address resolu tion f u nc tion
modif ied ( old instru c tion
sec tion) resident
high-lev el langu age
. . . modif ic ation
. . .
instru c tionnew sec tion
new read-write data sec tion
initialization f u nc tion
initialization management
data setting, initiali-zation
hardware other programs sy mb ol-address c orrelation data
trigger plu g-in f ile
c o-ex ist
of f line tool ( c ompilation, f ile mak ing. . . )
old read-write data sec tion ob j ec t c lass
plu g-in loader
alloc ation link age
j u mp program proc essing f low
図27: 既存のオンラインプラグイン機構
この置き換えにより、置き換えられた関数を呼び出す関数は、古い関数を呼び出すことで、間 接的に新しい関数の命令コードを実行することになる。
• 古いリードライトデータセクションはそのまま残され、新たな命令セクションは、古いリード ライトセクションとリンクされる。
従来存在しなかった、新しいリードライトデータセクションや、新しいクラスが追加されるこ ともある。
• 最近インストールされたクラス、または、データセットが初期化の必要があるならば、プラグ インローダは、リンクを行なう前に初期化ルーチンを起動する。
• オンラインプラグイン実行後に重大な障害が発生するならば、プラグインローダは、追加ある いは修正されたプログラムを削除し、元の状態に復帰する(プラグアウト)。
この機構は、(2)〜(6)の要求条件を満足する。
5.4.3 J2EEの場合
Javaは、記述されたプログラムのポータビリティが保証されるように、元々設計・開発された。
この考え方を更に推し進め、プログラムコンポーネントレベルでの移植を用意にするためにJ2EE アーキテクチャは制定された[64, 65]。
図 28に示すように、J2EEにおいては、アプリケーションプログラムはEJB(Enterprise Java
Beans)と呼ばれるコンポーネントの形で作られる。
EJBは、EJBコンテナの中で実行される。EJBコンテナは、コンポーネントの実行制御を行なう ものである。
既存のEJBを修正する場合、J2EEはEJBの実行を停止し、もし実行中のジョブが残っていれば それを終了させる。
そして、既存のEJBをアンロードし、修正された新たなEJBをロードする。
同様に、EJBではないJavaプログラムであっても、上記のようなローディング機構を用意してあ れば、同じような手順によってプログラムの入れ替えが可能である。
Active Xと同様に、この機構は、(1)、(4)、(5)の要求条件を満たすことができる。
ここまでに示されたように、この機構は、実行を中断できるようなコンポーネントのみに適用可 能である。修正対象のコンポーネントが24時間ノンストップ状態で走行しているならば、それは新 しいものとは入れ換えられない。例えば、VoIPの基本呼処理ルーチンは、システム内で最も重要 なルートである。このような部位に対してのサービス機能の追加は少ないが、バグの修正はシステ ム全体において非常に重要である。バグ修正のためにしばしば一時中断されるシステムは、ネット ワークサービスプロバイダの競争のために不利となる。
5.4.4 ルータの場合
ルータにおいて、“graceful restart”あるいは”non-stop forwarding” と呼ばれる技術が提案され
ている(RFC3623)。これは、ルーチングを行なうコントロールプレーンに障害が発生した場合にも、
5.4. 既存の部分プログラム入れ換え技術 61
EJB container
EJB EJB EJB
JA A S JA X P JT A
Jav a M ail
JA F JM S JD BC Connector
J2 S E
JAAS = Java Au th entication and Au th oriz ation Service JAXP = Java API for XML
Processing
JTA = Java Transaction JAF = JavaBeans API
Activation Framework JMS = Java Messag e API
Service API
JDBC = Java JDBC API
EJB container
( 1 ) J2 EE arch itectu re
( 2 ) EJB rep l acem ent J2 EE
ol d EJB new EJB
l oad and d ep l oy u n-d ep l oy and
u nl oad
new ev ents
図 28: J2EEによる部分プログラム入れ換え
データプレーンがパケットのフォワーディングを続ける技術である。コントロールプレーンが停止 している間もパケットのフォワーディングは継続されるが、ルーチング処理は停止しているため、
headless forwardingという状態である。
non-stop forwardingの問題点は以下の2点である。
• headless forwarding状態は、ルーチングのループや、ブラックホール(ダウンしたルートへの パケット送信によるパケット紛失)が発生するなど、危険が大きい。計画的(planned)なコン トロールプレーンの停止であれば、周囲の環境が変化しないようにオペレーションすることは 不可能ではないが、オペレーションコストがかかるのが問題である。
• ステートレスなパケット中継であればデータプレーンによるパケット転送が可能であるが、SIP のようなステートフルなパケット処理ではコントロールプレーンの介在が必須である。
以上の理由により、ルータにおいても、オペレーションコストや信頼性の観点から、コントロー ルプレーンの停止を伴わないプログラム更新機能が求められている。
5.4.5 Linuxのプラグイン
Linuxにおいても、ライブパッチと呼ばれるC++のプラグインと同様の技術が存在する。我々は、
OSDLで検討されているCGL(Carrier Grade Linux) [66]の機能として、Pannusと呼ばれるLinux のライブパッチ機能を実装した [67]。
Pannusの実装は、C++のプラグイン同様、旧関数の先頭にジャンプパッチを当てて新関数にジャ
ンプさせる方式である。適用性や制限事項についてもC++のプラグイン同様である。また、同様の 実装として、鵜飼氏のライブパッチも存在する[68]。
5.4.6 既存の機構のまとめ
上記から、交換機のようなシステムにおいて、オンラインプラグイン機構が最も修正パターンの カバー率が高い。その他の機構は、Javaを扱うことができるが、適用範囲やパフォーマンスの点で 不十分である。従って、これらの機構の利点を考察し、筆者は、Javaオンラインプラグイン機構を 考案した。