LiveRebel 1.0 - ダウンタイムのないソフトウェア更新

作者 Ian Roughley , 翻訳者 吉田 英人 投稿日 2011年6月28日

セクション

運用/インフラ,

デベロップメント

トピック

Java ,

マネジメント ,

言語 ,

デプロイ/データセンター ,

プログラミング

共有 |

原文(投稿日：2011/06/21)へのリンク

ZeroTurnaround の LiveRebel 1.0 は，アプリケーションの自動デプロイ時に発生するダウンタイムとセッション切断の軽減を目的とした製品だ。同社 CTO の Jevgeni Kabanov 氏によると，"アプリケーションの更新作業はほとんどの場合，ダウンタイムによるサービス停止時間を伴う" 。サーバを１台ずつ更新する，というやり方は望ましいものではない。しかし作業をサポートするツールはほとんどなく，プロセスは部分的にスクリプト化されてはいるものの，ほとんどが手作業というのが実態だ。InfoQ が ZeroTurnaround に話を聞いた。

InfoQ: ユーザが実際に LiveRebel を使って行っているデプロイ作業の複雑さやサイズについて，詳しく説明して頂けますか？

現在提供されているのはベータ版ですので，ほとんどは小さな規模のものです。しかし近い将来には，100 台以上のサーバ運用を対象としたデプロイも実施する予定です。

InfoQ: LiveRebel の対象は，単一ノードのアプリケーション (WAR，EAR，JAR) が中心なのでしょうか，あるいはもっと複雑な，マルチノードを対象としたデプロイも処理できるのですか？

どのような種類のデプロイでも処理可能です。サイズ制限のないクラスタや，柔軟性を備えたクラウドにも対応します。

これまで一般的であった手法に比べて，LiveRebel が有効なのはどのようなケースでしょうか (例えば，クラスタの単一サーバを同時にアップグレードする，というように)。

概念的な理由は次のとおりです。

• 一度にひとつずつサーバを再起動するのは非常に時間がかかるため，小さな変更でも高いコストを必要とする。
• アプリケーション内で何らかの状態構造が変更されていると，セッションの移行に失敗する。アプリケーションが使用中であれば，そのセッションの内容が恒久的に失われることになる。
• データベース構造あるいはリモート API が変更されると，新旧バージョンのアプリケーションの互換性が損なわれる可能性がある。その場合，両バージョンを並行して稼働させることはできない。

InfoQ: 次回リリースを待っているのは，どのようなユーザでしょうか

LiveRebel 1.0 の機能は最小限ですが，近い将来，以下のものを追加する予定です。

• Hudson/Jenkins プラグイン
• 状態変化 (フィールドの追加など) の自動あるいは手動での処理
• データベース更新の統合，さらには各種アプリケーションライフサイクル管理製品との統合

長期的な目標としては，現状のアプリケーションライフサイクル管理製品が抱えている，複数のクリティカルな欠陥にも取り組んでいく予定です。

リリース版の機能は次のとおりだ。

• 完全にスケーラブルなサーバとWeb コンソールにより，単一ノード，クラスタ構成，あるいはクラウド構成の Java EE アプリケーションを，サイズおよびコンテナを問わず管理可能である。
• アプリケーション全体を再ロードせずに，クラスやリソースを個別にバージョン管理することによって，コンテナの再デプロイとローリングアップデートに関わる問題を回避する。
• 更新を即時に，ユーザに関知されないでロールアウトする。コードはその場で更新され，既存の状態はすべて保持される。
• すべて Java で記述された JVM プラグイン (-javaagent) をノード上で使用する。パフォーマンス上のオーバーヘッドは３～５%に抑えられている。

ただし制限もいくつかある。LiveRebel ではリソースの全変更を処理するが，以下についてはサポートされない。

• スーパークラスの置換
• インターフェース実装の追加
• liverbel.xml ファイルを含んでいない JAR の変更管理 (具体的には，サードパーティの JAR とサポートライブラリを更新する場合がほとんどである)。

さらに LiveRebel は新たなステートを生成できないため，以下のようなタイプの変更は予測しない副作用を起こす場合がある。

• インスタンスフィールドの新規追加や名称変更を行うことにより，既存オブジェクトが null に初期化される。
• コンストラクタの変更が有効なのは，変更以降に生成されるオブジェクトのみである。
• 一般的に初期化記述子に対して行う変更は，既存オブジェクトには反映されない。

ZeroTurnaround が実施した 最近の調査 では，LiveRebel の必要性が立証されている。同調査が示すのは，自動サーバデプロイは日常運用というよりもむしろ例外操作 (特に回答者の大部分を構成していた2～50台のサーバ規模では) であり，それに伴うダウンタイムやセッションの損失という事態は受容可能である，ということだ。同社の目標とするのは “脆弱な依存性に囲まれた環境で行われるユーザとアプリケーション，データベース状態の移行。これが Java アプリケーションの更新における日常的現実なのです。私たちはそれをもっとよいものにしたいのです。"