日記：Chatty vs Chunky
よわよわエンジニアが知ったことのメモ日記です
Chatty vs Chunky
ある本を読んでいて「Chatty Design vs Chunky Desgin」という文言を見かけた。API設計の文脈で登場した言葉である。
聞き馴染みがなかったので調べてみたが、日本語のサイトがこちら*1くらいしか見つからなかったのでちょっとまとめておく。
検索でトップに出てきたワシントン大学のページによれば、以下のような定義らしい。
Chatty services tend to be ones that return simplified information and use more fine-grained operations.
Chunky services tend to return complex hierarchies of information and use coarse operations.
In other words, the difference is that chatty services require more calls than chunky services to return the same information but allow more flexibility to return only the information that is actually required.
またある学習サイトでは、以下のように説明がある。
Chatty API is one that requires consumer to make tremendous (subjective matter) amount of distinct API calls to get needed information about a resource.
雑にChattyとChunkyを日本語で再定義すると以下のような感じだと思う。
Chatty（おしゃべり）
サーバで最低限の処理のみ実行し最低限の出力を返す
ChattyなAPIでは目的を果たすためのリクエスト回数が多くなる
Chunky（かたまり）
サーバでまとまった処理を実行し最終的な出力を返す
ChunkyなAPIでは目的を果たすためのリクエスト回数は少ない
単純な例としては、100万件のデータを持つシステムがあったときに
などが考えられると思う。
Chattyだと1万回もリクエスト投げなきゃいけない。そりゃもはや攻撃だよねと思いつつ、
Chunkyだと100万件のデータを一気に取得するのもそれはそれでどうなの？
ということで、常にChattyがいいとかChunkyがいいとかではないよう。
当然ながらどちらの設計が良いのかはアプリケーションに依存するし、リクエストレート制限やデータ量制限などと併用して設計する必要があるよねということが前提。
とはいえ、MiscroSoftのページでも、以下のように言及がある。
Network calls and other I/O operations are inherently slow compared to compute tasks. Each I/O request typically has significant overhead, and the cumulative effect of numerous I/O operations can slow down the system. Here are some common causes of chatty I/O.
要するにChattyなAPIは、ネットワークコールやI/Oの回数が増えるとオーバーヘッドが増え、ネットワークにもシステムにも負荷がかかるということ。
極度なChattyはシステムに負荷を掛けかねないので、一般的には避ける傾向にあるようだ。
最近のハードウェアはある程度のデータチャンクに耐えうるCPUやメモリを搭載しているので、Chunkyでもリクエストの待ち時間はそこまで大した時間にはならない。その一方でネットワークは高帯域を備えていないことも多く問題になることも多いのかもしれない。
