サーバーを止めずに海外へ移設，“距離の壁”を仮想化技術で越える

2007.11.13

　距離にして約8700km，通信遅延は約200ミリ秒──。これは，東京都とオーストラリアのメルボルン市との間を隔てる絶対的な“距離の壁”だ。

　アクサ生命保険など，日本におけるアクサ・グループの情報システムを開発・運用するアクサテクノロジーサービスジャパン（以下「アクサテック」）はこの壁を乗り越え，東京で運用していた業務サーバー群をメルボルンにあるインターネット・データセンター（IDC）に移管し始めた（図1）。

図1●海外のデータセンターにサーバーを移管するうえで二つの問題に直面
（1）サービス停止時間を最短に抑えてサーバーを移設する，（2）クライアントとサーバー間の距離が延びたことで生じる200ミリ秒もの通信遅延を克服する――という難問の解決が必要だった。

「サービスは停止できない」

　2007年2月時点で約300台中の半数を移管済みだが，そのきっかけは日本のグループ本社が2006年1月に移転したこと。それまでは東京・渋谷の本社と四谷のホスティング拠点に情報系やファイル共有などのサーバー約300台が分散していた。それを移転先の白金高輪に集約すると，ビルには耐荷重や電源拡張など大がかりな工事が必要になる。本格的なデータセンターを整備するとなれば，数億円規模の投資が必要だろう。移管プロジェクトを指揮した飯島寛氏（サービスデリバリテクニカルサービスヘッド）は，「時間と費用を勘案するとワールドワイドの（＝仏AXAグループの）IDCにサーバー群を移設し，運用を任せる方が現実的だった」と話す。2005年3月，アジア圏のIDCがあるメルボルンにサーバー群を移管する方針を決めた。

　問題は，約8700kmという距離の壁をどう乗り越えるかだった。本社移転までの時間は限られている。プロジェクトのメンバーは，「基本的にはサーバーを塩漬けにして現地に送り込むしかない」という考えで一致していた。サーバー移設を担当した冨田勝氏（サービスデリバリオープンシステムテクニカルサービスシニアシステムエンジニア）は，「最初は航空便か何かでサーバー機を現地に送り込もうかと思った」（図2の方法1）という。だが飯島氏は，「サービス停止時間はできるだけ短くしなければならない」と別の方策の必要性を感じた。

図2●本番系に影響を与えずに短時間で移設する方法を考えた
（1）サーバー機を搬送，（2）ストレージ間で同期，（3）バックアップ・データを送信，（4）仮想化したイメージを送信──という四つの方法を検討。テスト検証を踏まえて，本番系に影響を与えず短時間で移設できる（4）を選択した。

仮想化技術で停止時間を最短に

　サーバー機の搬送に代わって考えた方法は，「現地にサーバーやストレージを準備し，データをネットワーク経由で送り込む」こと。それならば，「アプリケーションの種類やシステム形態を問わずに統一した方法で移設できる可能性が高い」（飯島氏）。そこで，ストレージ間で同期（図2の方法2），バックアップ・データを送信（同3），仮想化したイメージを送信（同4）──という三つの方法を検討した。

　採用したのは，仮想化したイメージを送信する方法である。これは，まず物理サーバー上のソフトウエアや構成・設定情報をサーバー仮想化ソフト「VMware ESX Server」上の仮想サーバーに抽出。その仮想サーバーのイメージ・ファイルをFTP（File Transfer Protocol）で転送する。「サーバーの停止時間は少ないし，本番系への影響もない。何より，仮想サーバー化してしまえば，サーバー集約も自在」（冨田氏），というのが採用の理由だ。

　実は同社では，2004年ごろから冨田氏らが社内の開発/テスト環境をVMware ESX Serverに移行済み。Xeon 3GHzを2基とメモリーを8Gバイト搭載したサーバー（HP DL360）2台に10台程度の仮想サーバーを構築・運用した経験がある。「最初にある程度のスペックのサーバーを買っておけば，後からちまちまとサーバーを買い足す必要がない。サーバーの納品を待たずともシステム構築できるので便利。信頼性も実用に耐えると思っていた」（冨田氏）。仮想化技術の活用はこうした評価の延長線上にあった。

200ミリ秒の遅延が立ちふさがる

　移設方法の検討が進む中，ネットワーク担当の茂木英郎氏（サービスデリバリネットワークオペレーションシステムエンジニア）は通信遅延の解決策を探っていた。新社屋のクライアントPCからメルボルンのサーバーにアクセスすると，約200ミリ秒もの遅延が生じてしまうからだ。

　移設により応答性能が悪くなると，利用者から不満が出かねない。しかも，「ネットワーク経由で仮想サーバーのイメージを送る今回の計画では，遅延がそのまま移設の所要時間に上乗せされる。高速化は迅速な移設にとっても不可欠だった」（冨田氏）。

　そこで茂木氏が目を付けたのが，WAN（Wide Area Network）経由のTCP通信を高速化する「WAN高速化装置」である。この装置をWANの両端に設置すると，送受信したデータに含まれるビット列が装置上にキャッシュされる。以降，同じビット列が送られてきたら，ビット列を示す符号だけを送ることでWAN上の伝送データ量を削減する。独自プロトコルを使い通信回数も削減されるので，実効スループットの向上が期待できた。茂木氏は，必要とするプロトコルの多くを当時からサポートしていた米Peribit Networks（2005年4月に米Juniper Networksに買収された）「WXC500」を検証することにした。

高速化装置の効果を測定

　まず，移設対象となるサーバー群をシステム形態やプロトコルなどで数種類に分けた。タイプごとに代表的なトランザクションを実行し，実効スループットなどを調べた（図3）。すると，Webサーバー，ターミナル・サーバー（Citrix），FTPサーバーなどでは，「実効スループットは最大で2倍近くに達した。物理的には48Mビット/秒なのに，常時50M～75Mビット/秒は出ている」（茂木氏）。10Gバイト級の仮想サーバーのイメージ・ファイルは，1時間～1時間30分で転送できた。

図3●通信遅延を軽減するWAN高速化装置の効果を検証
システムを五つのタイプに分類し，代表的なトランザクション処理の実効スループットを測定した。一部のサーバーでは実効スループットが最大で2倍近くに達した。しかし，再送処理をTCPに頼らず独自に実現するシステムや，小さなファイルやデータを頻繁にやり取りするシステムでは，十分に高速化できないことが分かった。
[画像のクリックで拡大表示]

　だが，検証を重ねるうちに，一つのウィンドウに収まる小さなデータを頻繁に送受信するサーバーや，TCPの再送機構に頼らず独自に再送制御するOracle Databaseサーバー，暗号通信を用いるサーバーでは，かえって遅くなることも分かってきた。これは，古いWindowsでファイル共有などに使う「NetBIOS」，データベース間接続に使う「DBLink」，Oracleのクライアント/サーバー型システムで使う「SQL＊Net」，HTTPを暗号化する「SSL（Secure Sockets Layer）」などが原因だ。検証結果から飯島氏は，「高速化できるものをメルボルンに移設し，高速化できないものは東京に残す」と決断を下した（図4）。