待つか、待たないか──同期と非同期の使い分け

仕事の流れを自動化するとき、最初に決めなければならないことがある。それは「待つか、待たないか」だ。ある処理を頼んだあと、その結果が返るまでじっと待ってから次へ進むのか。それとも、頼むだけ頼んで先に進み、結果は後で受け取るのか。前者を同期、後者を非同期と呼ぶ。技術的な用語に聞こえるが、実は私たちの日常の段取りにも、同じ二つのやり方がある。

窓口の比喩

役所の窓口を思い浮かべるとわかりやすい。書類を出して、その場で受理印を押してもらい、確認してから帰る。これが同期だ。手続きはその場で完結し、結果を持って次へ動ける。一方、書類を出すと「審査して、後日郵送します」と言われる。これが非同期だ。あなたは待たずに帰れるが、結果はいつ届くか分からず、届いたことを自分で確かめる必要がある。

どちらが優れているという話ではない。受理印のように即座に終わる処理を郵送にすれば、かえって遅くなる。逆に、時間のかかる審査をその場で待たされたら、窓口に行列ができ、後ろの人まで足止めを食う。流れの性質に応じて、待つべき場面と待つべきでない場面がある。

同期の強みと弱み

同期のいちばんの美点は、流れが追いやすいことだ。頼んで、待って、結果を得て、次へ。因果が一本の線でつながっているので、どこで何が起きたかが見通せる。プログラムも素直に書ける。利用者がその場で結果を見たい処理──たとえばログインの可否や、入力内容の確認──は、ほぼ同期が正解だ。

弱みは、待ち時間が連鎖することにある。途中の一か所が遅れると、その手前のすべてが止まって待たされる。窓口の比喩でいえば、一人の手続きに時間がかかると、後ろの全員が動けない。処理が重いほど、つながりが長いほど、この詰まりは深刻になる。

非同期の強みと弱み

非同期は、この詰まりをほどく。頼んだ側は待たずに進めるので、重い処理が混じっていても全体が止まらない。大量の依頼を一度にさばくときも、列に溜めて少しずつ処理できる。本サイトで扱ったメッセージキューは、まさにこの非同期を支える仕組みだ。処理の波を平らにならし、片方が止まっても全体を巻き込まない。

ただし、非同期には影がある。「頼んだけれど、終わったかどうか分からない」状態が生まれることだ。郵送を待つように、完了を別途確かめる必要がある。途中で失敗したら、どこまで進んでいたのか、やり直すのか、通知するのか──同期なら一本道で済んだ後始末が、非同期では枝分かれする。さらに、結果が二度届いたり、順序が前後したりもしうるため、受け手は冪等に作っておく必要がある。流れをほどいた分だけ、見えにくさと後始末が増える。

「速さ」ではなく「待てるか」で選ぶ

同期か非同期かを、処理の速さで選ぶ人が多い。だが本当の判断軸は速さではなく、「利用者や後続が、その結果を待つ必要があるか」だ。待つ必要があるなら同期、待たなくてよいなら非同期。たとえば決済の可否はその場で要るから同期、領収書のPDF生成は後で届けばよいから非同期、というふうに切り分ける。

もっとも、現実のワークフローは、この二つがまだら模様に混在している。全体を一律にどちらかへ寄せようとすると、たいてい無理が出る。即時性の要る区間まで非同期にすれば体験がもたつき、待ってよい区間まで同期にすれば全体が詰まる。設計とは、流れのどこに切れ目を入れ、どちらの流し方を割り当てるかを、一区間ずつ見極める作業にほかならない。待つことと待たないこと──そのどちらを選ぶかではなく、その境目をどこに引くかこそが、ワークフロー設計の本題なのである。

参考資料

1. Gregor Hohpe, Bobby Woolf『Enterprise Integration Patterns』（同期・非同期の連携モデル）
2. Martin Fowler によるソフトウェア設計の解説（非同期処理のトレードオフに関する一般的な議論）— martinfowler.com