今週、Appleがスペシャルイベントを計画しています。私も日本で開催されるイベント (衛星録画ですけどね) に出席しますので、なにか報告できればと思います。

さて、今回は「iDisk」。MobileMe (旧.Mac) の中核をなすオンラインストレージサービスで、Finderとの親和性も高く扱いやすいが、お世辞にもスピーディーとは言い難い。"遅さ"はOS XのWebDAV実装に起因しているのでは? との仮定のもと、その原因を探ってみよう。

船出早々荒波にもまれる「MobileMe」

「.Mac」の後継としてMobileMeのサービスが開始されたのは、iPhone 3Gが発売される直前の7月第2週。看板の「プッシュ」機能も、当初謳われていたMac OS XとiPhone(のカレンダーやアドレスブックスデータ)との迅速な同期は行われず、Macでの変更が「クラウド」に届くまでの時間は以前と変わらぬ15分間隔 (iPhoneで行った変更はすぐに通知されるが)。AppleがMobileMeのサービスを語るとき、限定的にしか「プッシュ」という表現を使わなくなったことが、その難航ぶりを露呈している。

前宣伝の反動からか、その「プッシュ」ばかり悪者扱いされているMobileMeだが、筆者はそう感じていない。もっとイライラするサービスがあるじゃないか! そう、その名は「iDisk」。容量は10GBから20GBに倍増したものの、肝心の転送速度が遅くては、とてもじゃないが20GBなど使い切れない……正確には使う気になれない。米国内はいざ知らず、この極東の地では「プッシュ」より「iDiskのスピードアップ」が喫緊の課題だ。

iDiskはなぜ"遅い"のか?

お世辞にも速いとは言えない、本音で言えば"遅い"iDiskだが、その理由の1つは地理的な問題。ここ日本からidisk.mac.com (サーバは米カリフォルニア州に設置) にアクセスする場合、必然的に日米間の回線を利用することになり、経路の長さや経由するルータの数など日本国内にサーバがある場合と比べて不利になるため、速度にも影響が出てくる。しかし、pingなどで反応を見るかぎり、こればかりが原因とは考えにくい。

もう1つの原因は、共有に使用されるプロトコル「WebDAV」だ。HTTPの拡張によりファイルアクセスを実現するという仕様から、ファイアウォールを越えてインターネット上でファイル共有できるという利点がある一方、制御情報をやり取りする都合上通信のオーバーヘッドは避けられず、FTPなど他の方式に比べパフォーマンスは劣るとされる。

Appleの見解によれば、iDiskの"遅さ"はOS X / FinderのWebDAV実装によるものではなく、正味の時間はサードパーティーのWebDAVクライアントと変わらないという。他のWebDAVサーバより遅い理由も、数千件におよぶMobileMeメンバーのアクセスを同時処理しているためだという。

disk.mac.comへpingしたときの様子

少なくともOS XのWebDAVクライアント機能には責任なし?

はいそうですか、と鵜呑みにするほど素直ではないので、自分で調べることにした。行ったテストは、WebDAVクライアントによりファイル転送速度に差があるかどうかの確認。利用したクライアントは、Leopardに付属のFinder (v10.5.4) と、CUIベースのWebDAVクライアント「cadaver」だ。同時に行うことは物理的に難しいため、iDiskのサーバが比較的空いていると思われる日本時間の午前に実施した。ちなみに、利用する回線はNTT東日本Bフレッツ (マンションタイプ / VDSL方式、実測68Mbps程度) 、使用したファイルはFirefox 3.0.1のディスクイメージ (約17.8M) だ。

なお、cadaverはOS Xに標準装備されていないため、Finkに収録されているバージョン0.22.2を利用した。インストールは「fink install cadaver-ssl」を実行するだけでOK。ちなみに、unstableツリーに収録されているため、はじめて利用する場合はこちらのページを参考にするといいだろう。iDiskへの接続手順は、以下のとおり。

$ cadaver http://idisk.mac.com/honyarara/
Authentication required for idisk.mac.com on server `idisk.mac.com':
Username: honyarara
Password: 
dav:/honyarara/>

結果だが、Finderとcadaverでは大差ない結果となった。アップロードはcadaverに軍配があがったものの、Finderの場合ファイルコピーのダイアログが消えた時点でコピー完了とみなしているため、コピーに要した正味の時間はかなり近いと考えられる。ダウンロード時間は、誤差の範囲と言ってもいいだろう。ダウンロードはHTTP経由で行えるため、curlコマンドでも試してみたが、時間はほぼ同一だった。

表:iDiskへ約17.8MBのファイルをアップ / ダウンロードするテスト

アップロード ダウンロード
Finder 4分15秒9 37秒8
cadaver 4分05秒4 37秒4
curl - 37秒1

となると、考えられる原因は……iDiskサーバ側の処理能力の問題か。そういえば、前掲したAppleの見解にも、「iDiskの同時使用ユーザ数が多くなると、アップロードのパフォーマンスが低下する場合があります」とあった。AppleがMobileMeの準備不足を素直に認めていることから、状況が悪化することはなさそうだが、メールなど他にトラブルを抱えている現状では、iDiskを最優先に設備の増強が図られるとは考えにくい。サーバが混雑していない時間を見計らって利用する、という自衛策が当面もっとも効果的なのかもしれない。