読者です 読者をやめる 読者になる 読者になる

俺の報告

RoomClipを運営するエンジニアの日報(多分)です。

スループットとレイテンシ - 日報 #143

日々色々なことが起きております。

スループットとレイテンシについて、ちょっと考える機会があったのでさわりだけ共有。

スループットとレイテンシ」と聞くと、、、 なんだか愉快な小動物の兄弟がチーズ工場で大立ち回りをするような欧風昔話タイトルのようですが、
全く違います。
wikipediaを見てみます。
スループット
基本的な定義は、

単位時間あたりの処理能力のこと

であり、ネットワークにおいては、

単位時間あたりのデータ転送量を指す。

んだそうです。
依存するのはバスラインの抵抗とか、対応する帯域幅とかになるんでしょうか。
特に記載がないのでわかりませんね。

一方、レイテンシ
基本的な定義は、

デバイスに対して、データ転送などを要求してから、その結果が返送されるまでの遅延時間

だそうです。
データ転送とか言ってるので、スループットが深く関わってきそうですね。
でもよくわかりません。
ただ結局、スループットは「転送量」で、レイテンシは「時間」という単位みたいです。
これはどちらも「能力」の基準のように見えるのでごちゃごちゃするのかもしれません。
この掛け算を運動量のように考えることもできそうですが、
その話は一旦置いといて、
じゃぁ例えば「むちゃくちゃデカイファイルをとあるLANケーブル越しに転送して、受取側は受信し切った後に、そのファイルが正しいファイルかを判定して、その旨を返す」とします。
勿論物凄い時間がかかります。
つまり、レイテンシがとんでもなく大きいということですね。
この時、何が原因でレイテンシが高くなったのか?と言われた時、
いくつか要因が考えられます。
一番手前側から列挙していくと、

  1. 送信側のDisk Readがへちょい
  2. データ転送の速度がへちょい
  3. 受信側のDisk Writeがへちょい
  4. 受信ファイルの判定がへちょい

という感じです。
この時、2番の「データ転送の速度がへちょい」に該当するのが、
スループットと思われます。
このよくありそうな「へちょい」連鎖のうち、
僕がよく遭遇していたのが3番とか1番あたりのDisk I/Oの話でした。
正直2番に悩まされることが殆どなかったのですが、
この度2番に引っかかるという事態に遭遇し、
中々勉強になっております。

CPU的意味で負荷分散しているクラウド設計において、 スループット減少のボトルネックを発見した時は結構気持ちがなえます。
だってどんなに計算能力を向上させたとしても、
LBとサーバ間とか、VPCルータとLB間とか、
ひいてはクラウド全体の利用bpsに完全に依存してしまっているからです。
「しょぼいCPUでもいくつも並べれば凄い計算ができるんやで!」
と思っていましたが、
例えば画像のような「そこそこデカイファイル」を扱う場合は、
当たり前のようにスループットについて精密に考える必要があるわけです。
いやもう書いてて本当当たり前ですよね。
デカイ荷物運ぼうぜ!っていう目標をたてて、 すごい沢山人数集めたけど、 運ぶ道が細くて渋滞してたら、何の意味もないもんね。

いやもう、
なんか1個1個ですね、、、