Web ブラウザを 用 いた 長 距 離 データ 転 送 の 高 速 化 井 口 義 己 谷 田 直 輝 稲 葉 真 理 平 木 敬 近 年 10Gbps の 広 帯 域 の 高 速 ネットワークが 普 及 してきたが, 一 般 的 な TCP を 用 い たアプリケーションは, 特 に 長 距 離 の 高 速 ネットワークにおいて 満 足 なスループット 性 能 を 出 せないことが 知 られていた. 我 々のチームはこの 問 題 を 解 決 し LFN 上 で 高 速 なデータ 通 信 を 成 功 させ,ネットワークの 有 効 利 用 の 道 を 開 いた.さらに,その 成 果 を 応 用 し, 高 速 なデータ 転 送 を 行 える Web ブラウザとして UsadaFox (Ultra-High-Speed file-acquisition-system over Distance with Apache and firefox) を 設 計 実 装 し, 日 米 間 LFN 上 で 高 速 なデータ 転 送 を 行 えることを 示 した.UsadaFox の 開 発 を 通 して,ネット ワークアプリケーションを LFN 向 けに 高 速 化 するためにはメモリ 上 のデータの 扱 いが 重 要 だということを 示 した. 高 速 データ 通 信 を 行 う 際 に 扱 うデータは 非 常 に 大 きいた め,バッファ 間 のデータコピーを 行 う 際 には 注 意 を 払 って 実 装 を 行 う 必 要 がある. 本 論 文 では UsadaFox で 実 際 にデータ 通 信 を 行 った 際 のバッファの 挙 動 を 計 測 し. 適 切 な メモリ 操 作 やバッファ 量 についての 考 察 を 行 った.さらに, 一 般 的 なアプリケーショ ンを 長 距 離 高 速 通 信 に 対 応 させる 際 の 指 針 を 示 した. Performance Optimization of HTTP Data Transfer over Long Distance with Web Browser Yoshiki IGUCHI, Naoki TANIDA, Mary INABA, and Kei HIRAKI With the rapid progress of high-bandwidth network technology, high-speed networks cover the entire world. It is well known that, in general, efficiency of data transfer between two points drastically drops as their distance grows. In our previous work, we proposed UsadaFox, which accelerates long distance data transfer. UsadaFox consists of modified Firefox browser and tuned Apache HTTP server. UsadaFox attained more than 6.5Gbps for file download between U.S. and Japan where round trip time was 136ms. We found it is important to reduce memory operations in the development process of UsadaFox. In this paper, we observed the behavior of buffers in UsadaFox. Based-on our observation, we show proper memory operations and appropriate size of the buffers for the network applications to support high-speed data transfer on high-speed large-delay networks. 1. はじめに * 近 年 のネットワーク 技 術 の 向 上 に 伴 うネットワークの 広 帯 域 化 は 著 しい.10Gbps のネットワークは, 当 初 は 大 量 のデータを 扱 う 研 究 機 関 や 大 企 業 などごく 限 られた 領 域 でのみ 使 用 されていたが,ネットワーク 需 要 の 増 加 に 伴 いそれ 以 外 の 領 域 にも 急 速 に 普 及 しつつある. 高 遅 延 高 帯 域 ネットワークは LFN(Long Fat-pipe Network)と 呼 ばれる.ここ 数 年 のネットワーク 技 術 の 発 展 とクラウド 技 術 の 普 及 に 伴 い,データをローカルではなく ネットワーク 上 のストレージに 保 存 するケースが 増 えているが, 海 外 のサーバなどか らの LFN を 経 由 したデータ 転 送 は, 幾 つかの 原 因 により 転 送 速 度 が 上 がらないことが 知 られている.そのため,LFN 上 での 高 速 データ 転 送 への 要 求 は 高 まっている. 我 々は,2007 年 に 10Gbps ネットワークにおける TCP を 用 いたデータ 転 送 において, 理 論 限 界 に 近 い 99%の 帯 域 利 用 率 を 達 成 した[1].さらに,ストレージ 間 の 転 送 におい ても LFN を 通 して 高 速 に 通 信 が 行 えることを 示 した[2]. 次 なる 目 標 として,データ 転 送 に 特 化 した 軽 量 なアプリケーションではなく, 一 般 的 なネットワークアプリケーションで 高 速 通 信 を 実 現 することに 挑 戦 した.この 目 標 を 達 成 するため, 高 速 なデータ 転 送 を 行 える Web ブラウザベースのシステムとして UsadaFox を 設 計 実 装 した[3]. 我 々は,UsadaFox を 用 いて 実 際 の 日 米 間 LFN 上 で 6.5Gbps の 速 度 でデータ 転 送 が 行 えることを 示 した. UsadaFox は Firefox と Apache を 長 距 離 高 速 通 信 向 けに 最 適 化 した,Linux 上 で 動 作 するシステムである.LFN 上 におけるデータ 通 信 の 高 速 化 を, 高 速 なストレージを 用 意 し,MAC レイヤでの 制 御 [1]や TCP レイヤのチューニング[4]を 行 い,メモリ 操 作 を 最 適 化 することによって 実 現 した. 高 速 データ 通 信 では 大 量 のメモリ 帯 域 が 消 費 され る.メモリ 操 作 だけでメモリバス 及 びプロセッサ 時 間 を 占 有 してしまわないために, メモリ 操 作 に 関 して 注 意 を 払 い 実 装 を 行 う 必 要 があった.さらに, 高 速 データ 通 信 を 行 う 際 はバッファにも 着 目 する 必 要 があった. 高 速 データ 転 送 においては 僅 かな 時 間 で 大 量 のデータを 受 信 するため, 不 適 切 なバッファ 設 定 はバッファの 詰 まりを 生 じさせ,さらにパフォーマンス 低 下 につながる.そこで, 実 際 にバッファがどのよ うに 使 われてどのようにデータが 流 れているか 調 査 を 行 い, 適 切 なバッファ 量 の 選 択 やメモリ 操 作 を 行 う 必 要 があった. 本 論 文 では UsadaFox を 用 いて LFN 上 で 高 速 通 信 を 行 い,バッファの 使 用 量 や 通 信 速 度 について 計 測 を 行 った.そしてネットワークアプリケーションにおける 最 適 なパ ラメータについての 考 察 を 行 った. 東 京 大 学 The University of Tokyo 1
二 章 では, 一 般 的 なアプリケーションが LFN において 高 速 データ 転 送 を 行 う 上 の 障 害 となりうる 原 因 について 述 べる. 三 章 では, 我 々が 開 発 した UsadaFox が 採 用 し ている 3 バッファモデルとその 性 質 について 述 べる. 四 章 では,UsadaFox を 用 いてバ ッファの 挙 動 を 調 査 し 高 速 にデータを 扱 うことができるバッファの 性 質 について 考 察 した. 続 く 五 章 にて, 関 連 研 究 と UsadaFox の 比 較 を 行 ない, 六 章 で 本 論 文 の 総 括 を 行 った. 2. LFN における 高 速 データ 転 送 実 現 への 障 害 2.1 TCP レイヤの 問 題 長 距 離 LFN 上 での 伝 送 では, 距 離 に 比 例 したパケットの 遅 延 や 中 間 スイッチでの 遅 延 が 累 積 し, 短 距 離 に 比 べ RTT が 長 くなる.たとえば 東 大 との 往 復 遅 延 時 間 を 計 測 し た 場 合, 状 態 がよければ 国 内 本 州 においては 30ms 以 下 の RTT で 通 信 できているが, 海 外 に 目 を 向 けるとアメリカの 西 海 岸 では 80ms 程 度,ヨーロッパでは 200ms 程 度, 国 や 地 域 によっては 250ms を 超 えることもある. 長 距 離 の 高 速 TCP 通 信 を 行 うためには, 送 受 信 側 共 に 大 きなバッファが 必 要 である ことは 知 られている.TCP は 送 信 データが 確 実 に 受 信 側 に 届 いたことを 確 認 すること ができる. 送 信 したデータが 受 信 側 に 届 くと, 受 信 側 は ACK パケットを 送 信 側 に 返 す. 送 信 側 は ACK パケットを 受 け 取 ることによって, 送 信 したデータが 無 事 に 到 達 したことを 確 認 できる.もし ACK を 受 け 取 ることが 出 来 なかった 場 合 は,そのデー タが 失 われたと 判 断 し,データを 再 度 送 信 する.そのため, 送 信 側 はデータの 送 信 後 にも ACK を 受 信 するまで 再 送 用 にデータを 保 持 しておかなければならない.ACK を 受 信 していないデータ,つまり 送 信 側 が 無 事 到 着 したことが 認 識 されていないデータ をインフライトデータ(in-flight data)と 呼 ぶ.インフライトデータの 最 大 値 は BDP (bandwidth-delay product, 帯 域 遅 延 積 )と 呼 ばれ, 帯 域 と RTT の 積 で 表 される.たと えば,RTT が 200ms の 経 路 において 1Gbps = 125MB/s で 通 信 する 場 合 の BDP は 25MB となる.RTT が 長 いほど, 帯 域 が 広 いほど,そのネットワークの BDP は 大 きくなる. そのため 高 速 な 通 信 を 行 うためには, 送 信 側 には 大 きいバッファが 必 要 である. さらに, 送 信 側 は 受 信 側 から 通 知 された 受 信 可 能 データ 量 に 応 じて 送 信 速 度 をコン トロールする 働 きがある. 受 信 側 から 送 信 側 に 通 知 される 受 信 可 能 データ 量 のことを RWIN(Receive Window, 受 信 ウィンドウ)と 呼 ぶ. 送 信 側 は,インフライトデータを 通 知 された RWIN の 値 以 下 に 抑 える.たとえば,RTT が 200ms の 経 路 において RWIN が 1MB の 場 合, 送 信 速 度 は 5MB/s = 40Mbps に 制 限 されてしまう.RWIN は 受 信 側 の ソケットバッファの 一 部 が 割 り 当 てられるため,RWIN を 制 限 しないためにも, 受 信 ソケットバッファの 値 も 多 く 確 保 しなくてはいけない. 2.2 アプリケーションの 問 題 アプリケーションの 実 装 に 関 しての 問 題 点 も 存 在 する. 大 きな 問 題 として 挙 げられ るのは,メモリとプロセッサ 間 のバス 幅 は 有 限 であり,データを 読 み 書 きするたびに このバスが 使 われるということである. 高 速 データ 通 信 でメモリに 対 して 操 作 を 行 う ためには, 短 時 間 に 大 量 のデータを 処 理 しなくてはならず,バスを 圧 迫 する. 高 速 な データ 転 送 を 維 持 するためはメモリへの 読 み 書 き 回 数 を 減 らし,バスが 飽 和 しないよ うにしなくてはいけない. 図 1は Firefox を 用 いてファイルのダウンロードを 行 った 時 のデータフローである.メモリコピーが 複 数 回 行 われていることが 示 されている. 無 駄 なメモリコピーはリソースを 無 駄 に 消 費 し,ボトルネックの 原 因 となる. 3. UsadaFox とその 設 計 図 1:Firefox のデータフロー 3.1 UsadaFox UsadaFox は,HTTP サーバとブラウザで 構 成 された 高 速 データ 転 送 システムである. 改 造 Firefox と 最 適 化 Apache を 組 み 合 わせた,LFN の 帯 域 を 有 効 活 用 したデータ 転 送 を 行 えるシステムである.Web ブラウザをベースにしているため,ワンクリックで 高 速 なデータ 転 送 を 行 うことができる.UsadaFox は,Linux 上 で 動 作 し, 特 殊 なパーツ やハードウェアではなく 一 般 的 な 汎 用 PC パーツで 構 成 されたサーバ 上 で 性 能 を 発 揮 することができる( 表 1). UsadaFox ブラウザでは,ソフトウェア 内 部 のデータフローとして 3 バッファモデル 2
表 1 UsadaFox を 構 成 するハードウェア CPU Intel Core i7 940 マザーボード ASUS Rampage II GENE チップセット Intel X58 chipset メモリ 6 GB DDR3 SDRAM NIC Chelsio S310E-CR NIC RAID Controller Adaptec ASR-51245 SSD Intel X25-E Extreme 32 GB 6 RAID0 にて 使 用 ( 図 2)を 採 用 した.ネットワークより 受 け 取 ったデータは,3 つのバッファを 経 由 し てからストレージに 保 存 される. データ 入 力 時 のソケットバッファ アプリケーシ ョン 内 部 のバッファ データ 保 存 時 のファイルページキャッシュ である. 一 般 的 に 経 由 するバッファ 数 が 少 ないとバッファ 間 のコピーのためのメモリ 操 作 が 減 るため, パフォーマンスが 上 がる.しかし,ネットワークアプリケーションが 何 らかの 処 理 や 保 存 を 受 信 データに 対 して 行 うことを 考 えると, 極 端 に 少 ないバッファで 設 計 を 行 う のは 保 守 性 の 面 から 難 しくなる. 我 々は,UsadaFox にて,3 つのバッファ 数 で LFN に て 高 速 通 信 が 出 来 ることを 実 証 した. 入 力, 処 理, 保 存 の 3 つのバッファを 持 つこと は,アプリケーションの 保 守 性 とパフォーマンスを 両 立 させた 妥 当 な 設 計 である. そのバッファ 構 成 をそれぞれどのように 設 計 するかは,パフォーマンスを 大 きく 左 右 する. 本 論 文 では,LFN 上 で 大 量 のデータを 扱 うネットワークアプリケーションを 対 象 に,この 3 バッファモデルを 用 いた 際 の 最 適 な 構 成 を 検 討 する.3.2 節 から 3 バ ッファモデルの 特 性 を 検 討 したのち, 次 章 にて 3 バッファモデルの 挙 動 を 実 験 にて 確 かめる. 3.2 ソケットバッファ 入 力 時 の 第 一 のバッファは,カーネル 空 間 内 に 配 置 されるソケットバッファである. ネットワークから 受 信 したデータを 一 時 的 に 溜 め, 受 信 データの 揺 らぎを 吸 収 する 役 割 を 持 つ.また,このバッファは 入 力 の 緩 衝 領 域 としての 役 割 だけではなく,TCP の RWIN として 使 われる 領 域 も 兼 ねる.そのため,ソケットバッファには BDP の 値 にさ らに 緩 衝 領 域 として 必 要 である 容 量 を 加 えた 値 を 必 要 である.このように, 長 距 離 通 信 においては 送 信 速 度 が 制 限 されることのないようにソケットバッファのサイズを 決 める 必 要 がある. 図 2 セグメントバッファ 3.3 アプリケーションバッファ アプリケーションはカーネル 空 間 上 のソケットバッファの 内 容 を 直 接 読 めないた め, 送 られたデータを 扱 うためには,ユーザ 空 間 内 のアプリケーションバッファに 存 在 する 必 要 がある.recv などのシステムコールを 通 じて,カーネル 空 間 内 のソケット バッファ 内 のデータをユーザ 空 間 のバッファへコピーする. UsadaFox 内 部 において,このバッファはセグメントバッファ( 図 3)として 実 装 さ れており, 複 数 個 のセグメントの 集 合 をバッファとして 扱 う.セグメントは 必 要 にな った 時 点 でメモリ 内 に 確 保 され, 不 要 なセグメントは 随 時 解 放 する.この 方 式 には, 必 要 なセグメントのみメモリ 上 に 確 保 されるため, 省 メモリであるという 利 点 がある. ただし, 読 み 書 きはセグメント 境 界 を 跨 いで 行 えないため,セグメントサイズを 小 さ くした 場 合 は 読 み 書 きの 際 のオーバーヘッドの 負 荷 が 高 くなる. アプリケーションバッファは,コンピュータ 内 部 で 完 結 しているため, 瞬 間 的 なブ ロックが 発 生 してもパフォーマンスロスに 繋 がらない.しかし,このバッファの 制 御 は OS ではなくアプリケーション 側 で 行 うため,アプリケーションの 開 発 においては 長 時 間 のブロックが 発 生 しないように 留 意 して 設 計 を 行 う 必 要 がある. 3.4 ページキャッシュ ストレージへファイルとしてデータを 書 き 出 す 際 には,ページキャッシュを 経 由 し てストレージに 書 き 込 まれる.このページキャッシュは 出 力 時 のバッファとしての 役 割 を 果 たし,OS によって 非 同 期 にストレージに 書 き 込 まれる. アプリケーションバッファからページキャッシュへは,mmap を 用 いてアクセスを 行 う.mmap は Linux のシステムコールであり,ページキャッシュ 領 域 に 対 してユー ザ 空 間 からのアクセスを 可 能 にする[5].アプリケーションは,アプリケーションバッ ファのデータを 読 み 出 し,データに 対 して 処 理 を 行 ない, 処 理 済 みのデータをページ キャッシュに 書 き 出 す. 書 き 出 されたデータは,OS が 非 同 期 にストレージへのフラッシュを 行 う. 高 速 デ ータ 通 信 では, 短 時 間 に 大 容 量 のデータを 書 き 込 む 必 要 がありこのキャッシュへも 随 時 大 量 のデータが 保 存 される.そのため,ページキャッシュをフラッシュするアルゴ 3
図 3 実 験 環 境 でのデータの 流 れ リズムが 適 切 ではないとストレージへの 書 き 込 み 速 度 が 劣 化 してしまう 可 能 性 が 考 え られる. 特 にストレージへの 書 き 込 みがボトルネックとなっている 場 合 は,ストレージに 対 して 随 時 書 き 出 しを 行 わせないと,ページキャッシュが 滞 って 後 続 する 入 力 をブロッ クしてしまうため,パフォーマンスが 出 ない.その 対 策 として,UsadaFox では,madvise を 用 いてカーネルに 対 して 書 き 込 みを 行 ったページキャッシュを 随 時 フラッシュする ように 指 示 を 行 った.madvise も Linux のシステムコールであり,mmap を 使 用 してマ ッピングしたメモリ 領 域 の 使 い 方 をカーネルに 対 して 予 告 し,キャッシュの 扱 い 方 を 指 示 することができる[6].たとえば, 今 回 のようなダウンロードしたデータをストレ ージに 書 き 出 すような 用 途 では, 一 度 mmap を 使 って 書 き 込 んだ 領 域 に 対 して 再 度 ア クセスすることはない.その 場 合 は,madvise を 用 いてストレージに 対 して 連 続 的 な アクセスを 行 うことを 予 告 する.それを 受 け 取 ったカーネルは,その mmap 領 域 に 対 しては, 書 き 込 みが 行 われたページをすぐにフラッシュする 挙 動 を 示 すようになる. 4. 実 験 以 上 のような 各 バッファの 特 性 を 踏 まえて,UsadaFox を 用 いて 各 バッファの 実 際 の 使 用 状 況 の 計 測 を 行 った.さらに, 以 下 の 点 に 関 して 検 証 を 行 った. LFN 上 での 高 速 なデータ 転 送 時 におけるバッファの 挙 動 の 調 査 パフォーマンスが 劣 化 する 条 件 の 検 証 実 験 は,ネットワークエミュレータを 用 いて 構 成 した 擬 似 LFN 上 で 行 った. UsadaFox のサーバとクライアントをネットワークエミュレータを 経 由 させて 繋 ぎ,そ の 上 でデータ 転 送 実 験 を 行 った( 図 3).ネットワークエミュレータには Anue H-Series Network Emulator を 用 いた.このエミュレータはネットワークに 人 工 的 な 遅 延 を, 片 方 向 ずつそれぞれ 約 0-800ms の 範 囲 で 任 意 に 設 定 することができる. 今 回 の 実 験 では 遅 延 量 は 100ms ずつ, 往 復 で 200ms に 設 定 した. 40GB/s のファイルの 転 送 を 行 ったときの 転 送 速 度 およびソケットバッファ 及 びア プリケーションバッファの 使 用 量 を 測 定 した. 転 送 時 には, 送 信 側 NIC においてペー 図 4 ソケットバッファの 使 用 量 の 推 移 表 2 ソケットバッファを 変 化 させた 時 の 受 信 速 度 の 推 移 SO_RCVBUF の 設 定 [MB] 25 50 75 100 125 150 平 均 速 度 [MB/s] 235.42 470.36 701.95 806.78 811.66 811.68 RWIN サイズ [MB] 46.87 93.75 140.62 187.50 234.37 281.24 RWIN / RTT [MB/s] 234.35 468.75 703.10 937.50 1171.35 1406.20 シング[1][3]を 行 ない,ストレージの 最 大 速 度 である 6.5Gbps で 送 信 速 度 に 制 限 をかけ ている. 4.1 ソケットバッファの 実 験 と 結 果 ソケットバッファはネットワークから 受 信 したデータが 格 納 される.RWIN が BDP を 下 回 るとスループット 低 下 につながる. 最 大 限 のパフォーマンスを 発 揮 させるには, 緩 衝 領 域 として 必 要 なバッファサイズに 加 え,BDP サイズを 加 えたサイズを 受 信 バッ ファに 確 保 する 必 要 がある.この 実 験 では,setsockopt システムコールを 用 いて SO_RCVBUF のパラメータの 値 に 余 裕 をもたせた 600MB を 設 定 した.そうすること により, 受 信 ソケットバッファには,SO_RCVBUF で 指 定 した 値 の 倍 である 1200MB から, 管 理 領 域 を 引 いた 領 域 が 割 り 当 てられる[7].RWIN はその 受 信 ソケットバッフ ァのうち, 未 使 用 部 分 の 一 部 が 割 り 当 てられる. ソケットバッファの 使 用 量 の 推 移 を 調 べた.ソケットバッファの 使 用 量 を 求 めるた めに,Linux の TCP ソケットのパラメータである copied_seq, rcv_nxt という 2 つのパ ラメータを 読 み 取 った.copied_seq は,バッファ 中 のアプリケーションにすでにコピ ーされたデータの 終 端 を 示 し,rcv_nxt は 受 信 済 みのデータの 終 端 を 示 す.この 2 つの 値 の 差 を 計 算 することによってソケットバッファの 使 用 量 を 求 めることができる. 測 定 は,カーネルがパケットを 受 信 した 際 に 呼 び 出 される 内 部 関 数 である tcp_recvmsg 4
図 5 アプリケーションバッファの 使 用 量 の 推 移 にフックを 掛 け,この 関 数 が 呼 び 出 される 度 に 目 的 のパラメータの 値 を 記 録 すること により 行 った. ソケットバッファの 使 用 量 の 推 移 を 測 定 した. 図 4 がその 結 果 である.113 秒 で 40GB のデータの 転 送 を 完 了 した.バッファ 使 用 量 は 低 い 値 で 安 定 しているが, 瞬 間 的 なバ ースト 状 態 が 観 測 された.その 中 で 最 も 大 きいものは 開 始 後 43 秒 地 点 で, 約 68.8MB 弱 のバッファを 使 用 していた.このケースでは 6.5Gbps のスループットを 得 るために は, 理 論 上 BDP は6.5Gbps 200ms 162.5MBであるため,231.3MB 以 上 のソケット バッファが 確 保 されていればよいと 考 えられる. また, 同 様 の 実 験 を 何 度 か 行 ったところ,このような 瞬 間 的 なバーストがソケット バッファにはしばしば 現 れた. 後 半 の 速 度 が 出 た 段 階 でのバーストが 多 いが, 図 4 の 43 秒 地 点 のケースと 同 様 の 加 速 段 階 のバーストも 発 生 するケースも 存 在 した. ソケットバッファサイズと 最 大 速 度 の 関 係 を 得 るために,ソケットバッファサイズ を 変 更 しながらスループットを 計 測 した.スループットは 速 度 が 最 大 速 度 付 近 で 安 定 している 転 送 後 期 の 30 秒 の 平 均 を 計 測 した.また, 転 送 開 始 時 (バッファにデータが 含 まれていない 状 態 )の RWIN も 記 録 した.RWIN は TCP パラメータの rcv_wnd の 値 を 取 得 した. 実 験 の 結 果 が 表 2 である.RWIN のサイズは SO_RCVBUF で 指 定 した 値 の 約 1.88 倍 が 設 定 されることがわかる.6.50Gbps 時 の BDP である 166.4MB より 大 きい RWIN が 設 定 されていれば,6.49Gbps で 転 送 が 行 えることがわかった.また,SO_RCVBUF が 小 さい 場 合 は,RWIN/RTT の 値 に 速 度 が 制 限 されることがわかった. 4.2 アプリケーションバッファの 実 験 と 結 果 アプリケーションはカーネル 空 間 のソケットバッファ 上 を 直 接 操 作 できないので, recv などのシステムコールを 通 してアプリケーションバッファにコピーを 行 う. UsadaFox 内 にバッファの 使 用 量 を 調 査 するために,アプリケーションバッファに 対 する 書 き 込 み 読 み 込 みにフックを 掛 け, 使 用 量 の 記 録 を 行 った.アプリケーション 図 6 転 送 時 のスループット バッファのサイズは 64.0MB に 設 定 した. 図 5 は, 図 4 を 記 録 した 際 に 同 時 に 記 録 し たアプリケーションバッファの 使 用 量 のグラフである. 開 始 後 43 秒 地 点 にてバーストが 発 生 し, 最 大 時 で 58MB のバッファが 使 われてい る.これは,ソケットバッファ 内 での 43 秒 地 点 から 始 まるバーストとの 関 連 性 が 考 え られる. また,49 秒 地 点 から 56 秒 地 点 のあたりまでバーストが 発 生 している.アプリケー ションバッファの 最 大 容 量 である 64.0MB と 60.0MB を 使 用 量 が 激 しく 上 下 している. バッファの 最 大 容 量 である 64.0MB に 到 達 した 後, 最 大 の 読 み 出 し 単 位 である 4.0MB を 読 み 込 む,という 動 作 を 連 続 して 繰 り 返 しているためである. この 転 送 実 験 では, 同 時 にスループットも 計 測 した( 図 6).0.5 秒 毎 に 受 信 したデ ータ 量 を 測 定 した. 速 度 の 増 加 時 ( 約 10-79 秒 地 点 )にスループットが 0.5 秒 単 位 で 上 下 している.これは,RTT が 200ms であるため 200ms 周 期 でバーストが 発 生 してい るのが 原 因 である.バッファのバーストが 発 生 している 時 においても,スループット への 影 響 はみられないことがわかる. 4.3 考 察 制 限 速 度 である 6.5Gbps 以 下 では,スループットは RWIN/RTT にほぼ 抑 えられてい るということがわかった. RTT:200ms のネットワークにて 6.5Gbps の 性 能 を 出 すため には,BDP である 162.5MB 以 上 を RWIN に 指 定 するために,162.5/1.88 86.44 MB 以 上 のサイズを SO_RCVBUF に 指 定 する 必 要 がある.また, 少 なくとも 今 回 の 実 験 範 囲 ではそれ 以 上 のバッファサイズを 指 定 しても,パフォーマンスへの 影 響 はほとんどな かった. ソケットバッファで 発 生 しているバーストは,RWIN を 考 えても 余 裕 があるためス ループットへの 影 響 が 出 ないことがわかった.また,アプリケーションレイヤのバー ストはソケットバッファにて 吸 収 され,スループットへの 影 響 がないことがわかった. 5
アプリケーションバッファにおいてバーストが 発 生 し,バッファを 埋 めてしまう 場 合 でも 軽 微 な 程 度 であればパフォーマンスに 影 響 を 与 えないことがわかった.また, ソケットバッファにおいて 瞬 間 的 なバーストが 発 生 した 場 合 でも,すぐにアプリケー ションバッファ,さらにファイルキャッシュへとデータが 流 れ,バーストが 吸 収 され ることがわかった. 軽 微 なバーストは 日 常 的 に 発 生 しているが, 次 のバッファにすぐ に 吸 収 されるため, 前 のバッファを 詰 まらせる 問 題 やパフォーマンスに 対 する 影 響 は 発 生 しないことがわかった.つまり,バッファ 間 のメモリコピーが 頻 繁 に 行 われてい る 場 合 は,バッファのサイズを 小 さくすることができる. 逆 に,バッファ 間 のメモリ コピーの 頻 度 が 少 ない 場 合 には,バッファを 大 きく 取 る 必 要 があると 推 察 できる. また,43 秒 付 近 でソケットバッファのバーストが 発 生 しているが,このバーストは その 時 点 の 転 送 レートを 考 えると 不 自 然 に 大 きい.NIC からソケットバッファへのコ ピーにおいて 数 十 MB 程 度 の 何 らかのバーストが 発 生 している 可 能 性 が 考 えられる. また,アプリケーションバッファの 49-57 秒 付 近 のバーストに 関 しては,ソケット バッファの 様 子 を 見 ても 詰 まった 様 子 はないため,おそらくファイルキャッシュ 側 に 何 らかの 問 題 があるのだと 考 えられる. 5. 関 連 研 究 GridFTP [8] は,グリッドコンピューティング 環 境 向 けのデータ 共 有 システムである. FTP を 拡 張 したプロトコルを 用 いて, 複 数 の TCP ストリームを 用 いた 並 列 データ 転 送 を 行 う.GridFTP は 並 列 TCP ストリームを 用 いてストリーム 全 体 での 速 度 向 上 を 図 る 試 みであるが, 我 々は UsadaFox を 用 いて, 単 一 ストリームの 転 送 においても,バッ ファに 対 して 適 切 な 設 計 を 行 うことで 高 速 なデータ 転 送 が 行 えることを 示 した. FastSoft E シリーズ [9] は,FastSoft 社 による 長 距 離 データ 転 送 のためのアプライア ンスである.サーバ 側 にハードウェアを 置 くことによって 通 常 の TCP を FastTCP [10] に 変 換 して 長 距 離 においてもデータ 転 送 を 行 うことができる. 我 々は,UsadaFox にお いてソフトウェアレベルでの 変 更 を 適 切 に 施 せば, 通 常 の TCP においても 高 速 なデー タ 転 送 を 行 うことができることを 示 した.UsadaFox には,ハードウェアの 用 意 やネッ トワーク 構 成 の 変 更 を 行 う 必 要 がないというメリットがある. Fast And Secure Protocol (FASP) [11] は Aspera 社 による 長 距 離 データ 転 送 のためのプ ロトコル,およびそのプロトコルを 用 いた 長 距 離 データ 転 送 を 高 速 に 行 うソフトウェ アのアプライアンスである.ブラウザ 等 の 既 存 ソフトウェアと 連 携 し,FASP に 対 応 したサーバからのダウンロードを FASP ソフトウェアが 代 行 し 高 速 なダウンロードを 行 ことができる. 転 送 には,UDP 上 にて 独 自 の 輻 輳 制 御 と 信 頼 性 を 付 加 したプロトコ ルを 用 い, 長 距 離 において 高 速 なデータ 転 送 を 行 うものである.しかし 我 々は UsadaFox では,バッファ 等 に 対 して 適 切 な 改 善 を 行 えば 通 常 のブラウザソフトウェア からでも 十 分 な 高 速 データ 通 信 が 行 えることを 示 した.サーバに 関 しても Apache 等 の 一 般 的 な HTTP サーバを 流 用 することができ, 特 別 なソフトウェアを 用 意 しなくと もブラウザ 単 体 で 高 速 なダウンロードを 行 うことができる. 6. まとめ 本 論 文 では,UsadaFox の 開 発 を 通 して,ネットワークアプリケーションが LFN を 用 いて 性 能 を 出 すための 方 法 論 を 示 した. 高 速 データ 通 信 を 行 う 際 に 重 要 であるメモ リ 上 のデータの 扱 いに 着 目 し,UsadaFox のバッファの 挙 動 を 測 定 しながらパフォーマ ンスへの 影 響 を 調 べた.そして,アプリケーションが LFN においてパフォーマンスを 維 持 するために 必 要 なバッファの 条 件 について 考 察 を 行 った. 今 後 は, 擬 似 LFN ではなく 実 際 の LFN 上 でも 実 験 を 行 い, 実 環 境 に 近 いネットワ ークでの 挙 動 についても 調 査 していきたい.また,ページキャッシュの 挙 動 について も 調 査 を 行 ない,バッファの 相 互 関 係 をより 深 く 調 べていきたい. 謝 辞 UsadaFox を 使 用 した 実 験 を 行 う 際 において 多 くの 助 言 や 支 援 を 頂 きました, 慶 應 大 学 の 加 藤 朗 氏,NICT の 長 谷 部 克 幸 氏, 東 京 大 学 の 玉 造 潤 史 氏, 下 見 淳 一 郎 氏, 石 井 康 雄 氏, 小 泉 賢 一 氏 にこの 場 を 借 りてお 礼 申 し 上 げます.なお, 本 研 究 は 科 研 費 基 盤 (S)21220001 の 助 成 を 受 けて 行 われた. 参 考 文 献 1) Yoshino, T., Sugawara, Y., Inagami, K., Tamatsukuri, J., Inaba, M. and Hiraki, K.: Performance optimization of TCP/IP over 10 gigabit ethernet by precise instrumentation, In Proc. of the 2008 ACM/IEEE conference on Supercomputing, IEEE Computer Society, pp. 1-12, (2008). 2) 谷 田 直 輝, 稲 葉 真 理, 平 木 敬 : TCP による 長 距 離 ディスク 間 データ 転 送 の 高 速 化, 情 報 処 理 学 会 研 究 報 告, Vol.2009-ARC-184 No.23, pp. 1-7, (2009). 3) Iguchi, Y., Tanida, N., Koizumi, K., Inaba, M., Hiraki, K.: USADAFOX: Ultra-High-Speed file-acquisition-system over Distance with Apache and firefox, In Proc. of TERENA NETWORKING CONFERENCE 2010, (2010). 4) 玉 造 潤 史, 吉 野 剛 史, 稲 上 克 史, 菅 原 豊, 稲 葉 真 理, 平 木 敬 : 10 ギガビットネットワーク 上 で の 高 効 率 TCP/IP 通 信 の 実 現, 情 報 処 理 学 会 研 究 報 告, Vol.2006-HPC-107 No.87, pp. 299-304, (2006). 5) Linux manpage of mmap(2). 6) Linux manpage of madvice(2). 7) Linux manpage of TCP(7). 8) Bill A., Joe B., John B., Ann L. C., Ian F., Carl K., Sam M., Veronika N., Darcy Q., Steven T.: Data Management and Transfer in High-Performance Computational Grid Environments, Parallel Computing Journal, Elsevier, pp.749-771, (2002). 6
9) E Series TCP optimization products - FastSoft, Inc. http://www.fastsoft.com/software-appliances/ 10) Wei D., Jin C., Low H. S., Hedge S.: FAST TCP: Motivation, Architecture, Algorithms, Performance, IEEE/ACM Transactions on Networking, IEEE Press, pp. 1246-1259, (2006). 11) High-speed file transfer software Aspera - fasp technology overview http://www.asperasoft.com/en/technology/fasp_overview_1/fasp_technology_overview_1 7