オフロード (コンピュータ用語)
コンピュータ用語のオフロード(英: offloadあるいはoffloading、表記ゆれで off-loadやoff-loadingも)は、基本的にはあるシステムの負荷(英語のload。仕事、タスクなど)を軽減させることを意味し、通常は、あるシステムの負荷(仕事)を軽減させるために他のシステムにその仕事を分担させることを指す。また、その技術。文章中ではしばしば「負荷の軽減」や「負荷軽減」と訳されている。
この用語は、ネットワーク通信の負荷を軽減させる場面で、特に頻繁に用いられる。また、3DCG処理を行う際にCPUの負荷を軽減させる場面や、分散コンピューティングを行う場面や、CPUのデータ転送の負荷を軽減させるためにDirect Memory Accessを使用する場面でも用いられることがある。
なお稀に、「オフロード」がシステムで実行中のジョブを"停止"させることを意味する場合もある。たとえば、システム入替時などに使われる。アルファベットではOFF-LOADなどと表記される。
概説[編集]
システムの受け持つ機能の一部を外部システムに受け渡すことで、本体システムの負荷を軽減することは、パフォーマンス向上を目的としてしばしば用いられる手法である。負荷軽減の手法としてはロードバランシング(負荷分散)などもあるが、ロードバランシングは同等機能の機器を並列稼動させ、負荷を均等に分散する手法であるのに対し、オフロードは一部の機能だけに特化したシステムを本体システムから切り出して外部システムとする手法であり、その向かう方向は大きく異なる。この手法をオフロードと呼ぶ。
ネットワークアダプタ[編集]
近年、1000BASE-Tなどのような高速ネットワークが登場することで、以下に示されるような様々な処理がOSに負荷を与えていた。この負荷を軽減することを目的に、ネットワークアダプタにある程度の処理を任せるという手法がオフロードである。近年では、安価なネットワークアダプタでも標準的に行われている手法である。
チェックサムオフロード[編集]
インターネットの基盤プロトコルであり、事実上の標準であるIPを用いた通信はネットワーク通信の中心である。この状況下では、IP通信の負荷を下げることは、ネットワーク負荷を下げることとほとんど同じといえる。
IPv4では、パケットがビット化け等によって破壊されているかを検査するために、IPヘッダ内にチェックサムフィールドを持っている(参考:IPv4#パケット)。また、IP通信の約9割を占めるといわれているTCPのヘッダ内にもチェックサムフィールドが設けられている。すなわち、IPv4では大抵の場合、1つのパケットを送受信する際には、送信側と受信側でそれぞれ2回、チェックサムの算出が必要となる。
IPv6にはチェックサムフィールドは設けられていない(参考:IPv6#ヘッダ)。これはエラーチェックを上位層に任せているためであり、エラー訂正機能を持つTCPでのチェックサム算出はIPv6でも必要である。すなわち、IPv6では大抵の場合、1つのパケットを送受信する際には、送信側と受信側でそれぞれ1回、チェックサムの算出が必要となる。
このように、IP通信ではほとんどのケースにおいてパケットごとに1度以上、チェックサムの算出が必要となる。このチェックサム算出を、OSで行わずにネットワークアダプタに任せることで、OSの負荷を下げるというのがチェックサムオフロードである。IP層とTCP層、送信と受信によって、以下のように分かれる。
- TCPチェックサム・オフロード(TCOとも略される)
- 受信TCPチェックサム・オフロード
- 送信TCPチェックサム・オフロード
- IPチェックサム・オフロード
- 受信IPチェックサム・オフロード
- 送信IPチェックサム・オフロード
ネットワークアダプタが各オフロードに対応している場合、データ送信の際、OSはチェックサム算出を行わずネットワークアダプタに算出を任せる。ネットワークアダプタは、チェックサムの算出を行ってチェックサムを補いながら各パケットを送出する。データ受信の際、ネットワークアダプタはチェックサム算出を行い、その正否を別の形でOSに通知する。OSは、チェックサムを算出せずにネットワークアダプタから別の形で得られたチェックサム正否を用いてパケットの非破壊性を確認する。
Windowsでは、Windows 2000(NDIS 5)から実装され、Windows 2003 Server(NDIS 5.1)でデフォルト機能となった。Microsoft社が行ったテストでは、TCPチェックサムオフロードだけで、CPU使用率ベースで最大30%のパフォーマンス向上が得られたとしている[1]。
なお、通常運用では問題とはならないが、WiresharkなどのLANアナライザを用いてパケットをキャプチャすると、チェックサムが誤っていないにもかかわらずチェックサムエラーが示されることがある。これは、送信パケットのチェックサム算出をネットワークデバイスに任せている関係で、キャプチャリングされるタイミング、つまりOSからパケットが送出される直前の段階では、チェックサムフィールドにチェックサム計算結果が含まれていないことによるものである。このような環境では、LANアナライザのチェックサムエラー検出機能を無効化しておく必要がある。受信パケットの場合はこのような事情はないため、パケットそのものが欠損していない限り、チェックサムエラーとなることはない。
TCPセグメンテーションオフロードとLarge Receiveオフロード[編集]
ネットワーク通信では、使用するプロトコルや下位層(通信機器など)に応じて、一度に送出できるサイズに制約が生じる。例えば、イーサーネットを使う上では一度に1500オクテットまでのデータしか扱うことができないなどである。TCPにおいて、送出データを一度に送出可能なサイズに分割することをセグメンテーションと呼んでいる。TCPセグメンテーションオフロードとは、この分割処理をネットワークアダプタに任せるというものである。TSOと略される。また、TCP Large Send(略称はLSO)やGeneric Segmentation Offload(略称はGSO)と呼ぶこともある。
対して、受信側はセグメント化されたパケットを結合する必要がある。Large Receiveオフロードとは、この結合処理をネットワークアダプタに任せるというものである。LROと略される。
フルTCPオフロードエンジン[編集]
上記のような仕組みを含めて、TCPの処理のほとんどをネットワークアダプタに任せ、OSは単にネットワークアダプタに送信データを渡すのみとする手法も近年では行われている。これをフルTCPオフロードエンジンと呼び、TOEと略される。
IPSecオフロード[編集]
この節の加筆が望まれています。 |
IPsecの暗号化および復号の部分をネットワークアダプタによって実現させる手法があり、これをIPSecオフロードと呼んでいる。
デメリット[編集]
ネットワーク分野でのオフロードは、必ずしもメリットばかりではない。以下のような点がデメリットとして挙げられる。
- フィルタリングの困難さ
- 例えば、セグメント化された先頭でないパケットにSYNフラグが立っていることは通常運用ではありえないパケットである。このようなパケットをルールベースのパケットフィルタリングで破棄したいという要求は容易に考えられる。しかし、そのような柔軟性はネットワークアダプタには通常設けられていないため、TCPセグメンテーションオフロードが有効な環境下では、左記のようなパケットを破棄することは困難である。
- 脆弱性対処の困難さ
- オフロードを有効にすることが、侵入系の脆弱性という観点での影響を与えるとは考えにくいが、DoS攻撃系の脆弱性という観点での影響はありえる。RFC 4953が中心に扱っている、セグメント化されたパケットの再構築時の脆弱性が現実のものとなった場合に、オープンソース系のOSを使っていればOSによる緊急対処も容易であるが、ネットワークアダプタではメーカーによるドライバアップデートを待つことしかできなくなる。メーカーが既にサポートしなくなったネットワークアダプタの場合は、アップデートも期待できないことになる。
SSL[編集]
SSLオフロードはサーバ/クライアントネットワークでのTLSまたはSSLによる通信において、サーバをSSLエンコード/デコード負荷から解放してパフォーマンスを上げるために、SSL処理を専門に行うノードを設置したシステムのことである。
SSLオフローダーが、クライアントとサーバ間に設置されるトポロジーと、サーバロードバランスのシステム内で、SSLオフローダーにリダイレクトするトポロジーで利用される。SSLオフローダーはリバースプロキシの一種として動作する。
- 通常のフロー:クライアント (SSL) →サーバ (SSL)
- SSLオフロードのフロー:クライアント (SSL) →オフローダー (SSL) →サーバ
- 負荷分散 + SSLオフロード:クライアント (SSL) →負荷分散→オフローダー(SSL)→負荷分散→サーバ
SSL証明書はサーバではなくSSLオフローダーにインストールされることになるが、通常、SSLオフローダーの台数はサーバより少ない。このことから、SSL証明書のライセンス数について、証明書発行会社により解釈が若干異なる。
GPU[編集]
並列計算能力の極めて高いGraphics Processing Unit(GPU)にグラフィックス処理などをオフロード(委譲)することが多い。グラフィックス処理は、画面解像度や描画内容の複雑度が増大するにつれ、膨大な量の計算が必要となっていくため、CPUでリアルタイムに実行するのは難しいことから、もともとグラフィックス処理専用チップにラスタライズや塗りつぶしなど一部の処理をオフロードすることが普通に行なわれていた。オペレーティングシステムのデスクトップ画面描画、ゲームやCADの3次元コンピュータグラフィックス(3DCG)描画、動画再生といった様々なグラフィックスタスクの快適性は、もはやGPUなしでは実現不可能となっている。また、汎用計算に対応したGPUが登場してからは、グラフィックスだけでなく科学技術計算や、機械学習あるいは深層学習による人工知能(AI)関連の高負荷処理をオフロードすることも頻繁に行なわれるようになっている(GPGPU)。GPUへのオフロードをアプリケーションソフトウェアやライブラリに組み込むには、CUDAやOpenCLといったプログラミング環境やAPIが使われることが多いが、OpenMPやOpenACCのようなAPIでは、より抽象化されたGPUオフロード機能が提供されている[2]。
ジョブの停止[編集]
ジョブの停止については、ジョブ、ジョブ管理システム、killなどを参照のこと。
脚注[編集]
注釈[編集]
出典[編集]
- ^ “Windowsのネットワークタスクオフロード”. 2010年4月3日閲覧。
- ^ OpenMP* オフロードの最良の事例 | iSUS