非同期と並行

100 件の API を順に叩いたら 100 秒かかった

1 件 1 秒で返る API を 100 件呼びます。素直に for 文で書けば 100 秒です。その 100 秒間、CPU が何をしているかというと、ほとんど何もしていません。リクエストを送ってから返事が届くまで、やることが無いのです。

1 秒という待ちは、CPU にとって途方もない長さです。ナノ秒単位で動く側から見れば、10 億回分の仕事ができる時間を、ただ座って過ごしていることになります。

スレッドを 100 本立てる、では届かない

待っている間に他の仕事をさせればよい、という方針は正しいです。素直な実装は、100 件それぞれに 1 本ずつスレッドを割り当てることで、実際これで 100 秒は 1 秒あまりまで縮みます。

では 10,000 件ならどうか。ここで頭打ちになります。OS スレッドは 1 本ごとにスタック用の領域を抱え、既定では 8MB 分の番地が確保されます。加えて OS がスレッドを切り替えるたびに、レジスタの退避と復元が必要です。1 回あたりはわずかでも、待っているだけのスレッドが 1 万本あると、切り替えのために CPU を使う割合が無視できなくなります。

そもそも、やりたいのは「返事が来た人から順に処理する」だけです。それ専用の道具として、スレッドは重すぎます。

待ちに入るところで、自分から譲る

非同期処理は、待ちが発生する場所をコード上に明示させます。

async def fetch(session, url):
    async with session.get(url) as resp:
        return await resp.text()

results = await asyncio.gather(*[fetch(s, u) for u in urls])

await と書いた行で、この関数は「ここから先は返事待ちなので、他の人にどうぞ」と中断します。中断した関数の状態は数 KB のオブジェクトとして残るだけで、OS スレッドは 1 本のまま次に進める関数へ移ります。返事が届いた関数は、中断した行から再開します。

スレッドの切り替えを OS が勝手に行うのに対し、こちらは書いた本人が譲る場所を決めています。譲る場所が分かっているぶん切り替えは桁違いに軽く、同じ 1 スレッドで数万件を抱えられます。

同時に進むことと、同時に走ることは違う

ここまでの話に、CPU コアを増やす要素は 1 つも出てきません。1 コアでも 100 件を「進行中」にはできます。これが 並行 です。対して、複数のコアで物理的に同時に計算するのが 並列 です。

シェフが 1 人でフライパン 3 つを順に振るのが並行、シェフが 3 人いるのが並列、という例えがよく使われます。非同期処理が効くのは前者、つまり待ち時間が支配的な仕事です。

裏を返すと、待ちのない計算では逆効果になります。await を挟まない重いループを書くと、その関数は誰にも譲らないので、同じスレッドに乗っている全タスクがその間まったく動きません。画像の変換や巨大な集計は、別のスレッドかプロセスへ逃がすのが定石です。