デジタル庁クラウドチームの「非同期処理」の説明が混乱している件

デジタル庁が詳細設計をするわけではないのでプログラマ的には問題ではないが、その説明が拙いために役所の情シスの皆さんを困惑させている気がするので指摘したい。デジタル庁クラウドチームの「非同期処理」の説明は混乱している。

デジタル庁クラウドチームはモダン化されたシステムの要件として、非同期処理を勧めて来る。

GCASガイドでは、

非同期処理とする

• 時間がかかる業務処理の場合、API呼び出しは一度処理を終了させ、後でポーリングして結果を取得する。
• APIフロント側は、API呼び出しのエラーを適切なメッセージにしてユーザに示し、リトライ後、適切なメッセージをユーザに提示したり次の処理につなげたりするロジック（サーキットブレーカー）を実装する。
• APIバック側で処理に時間がかかる場合は、APIで受け付けたデータを永続化し、イベントドリブンに順次処理して結果を永続化する。

上記のようにAPI利用時は非同期処理とすることで、フロントエンドとバックエンド双方の非機能要件（性能、信頼性など）を別々に考えればよくなり、ユーザー体験とコスト最適化を両立できる。

としており、Techブログでは、

非同期処理とする

非同期処理とは、複数のシステムが互いの処理完了を待たずに、それぞれが独立して処理を進める方式です。

一方のシステムで処理に時間がかかる場合でも、呼び出し元は待機せずに、次の処理を継続できます。処理が完了しなかった場合に備えて、APIの呼び出しを一度終了させてリトライすることも必要です。

と説明している。

技術的な理解が怪しまれるほど、作文がおかしい。

1. GCASガイドとTechブログで話が異なる。GCASガイドではサーバーの業務処理とレスポンスの非同期化なのだが、TechブログではブラウザーのJavaScriptの(RESTful)API通信の非同期化となっている。
2. GCASガイドは「時間がかかる業務処理の場合」と条件付きの導入としているのに、「非同期処理とする」と必須条件のような見出しにしている。ブラウザーのJavaScriptの(RESTful)API通信は原則非同期なのだが、引きずられていないであろうか。
3. サーキットブレーカーの説明がおかしい。サーバーがリクエスト過多で機能停止しないように、サーバー状態に応じてリトライを完全または部分的に抑制する仕組みを指すはずだ。
4. 「API呼び出しは一度処理を終了させ」は、サーバーがリクエストに対してレスポンスを返すという意味で「処理を終了させ」になるとは言えるが、国語的には「業務処理を終了させ」と読解される。
5. 「APIで受け付けたデータを永続化し、イベントドリブンに順次処理して結果を永続化する」は誤りではないが、言葉の意味がわかっているのか疑わしい。呼び出されたら処理をするのがイベントドリブン。同期処理でもイベントドリブンになるわけで、言いたいことはそれではないはずだ。非同期処理と永続化は直接関係ない。
6. 「フロントエンドとバックエンド双方の非機能要件（性能、信頼性など）を別々に考えればよくなり…」は、フロントエンドとバックエンドを分割で達成される話で、非同期化とは関係ない。
7. Techブログの「処理が完了しなかった場合に備えて、APIの呼び出しを一度終了させてリトライする」は、「に備えて、APIの呼び出しを一度終了させて」が意味不明である。「サーバーが応答しなくなった場合はコネクションを切断して、リトライする」と書きたかったのであろうか。

私ならば「サーバーサイドの適時非同期化：サーバーは、時間がかかる業務を処理するAPIがリクエストされた場合、キューにメッセージを入れるだけで処理の完了を待たずにレスポンスを返し、バッチが順次、イベントドリブンで呼び出されて業務を処理していく。ブラウザーなどクライアントは、（ロング）ポーリングにより結果を取得する。」とでも説明した。

ところでメッセージキュー（バッチ処理のイベントドリブン化）が有用になる場面を説明しておいたので、参考にして頂きたい。