QCon London 2026:大規模な非同期APIの管理
QCon London 2026において、Just Eat TakeawayのシニアプリンシパルエンジニアであるIan Cooperが、エンドポイント定義によるコード生成、スキーマ登録、メッセージングインフラの自動化を通じて、本番環境での非同期API管理の方法について議論した。
キーポイント
非同期APIの本番管理
Ian Cooperが、本番環境における非同期APIの管理に関する課題とアプローチについて発表した。
エンドポイント定義の活用
エンドポイント定義を起点として、開発プロセスを自動化する方法が示された。
自動化の3つの側面
エンドポイント定義から、コード生成、スキーマ登録、メッセージングインフラの自動化が可能であることが示唆された。
影響分析・編集コメントを表示
影響分析
この記事は、大規模システムにおける非同期API管理の実践的な知見を提供しており、特にマイクロサービスやイベント駆動アーキテクチャを採用する組織にとって参考になる。発表内容が広く採用されれば、API開発と運用の効率化に寄与する可能性がある。
編集コメント
カンファレンスでの実践事例紹介であり、特定の新技術発表ではないが、大規模システムを運用するエンジニアにとっては有用な知見が得られる内容。
QCon London 2026において、Just Eat TakeawayのシニアプリンシパルエンジニアであるIan Cooperは、本番環境における非同期APIの管理について議論し、エンドポイント定義がコード生成やスキーマ登録、そしてメッセージングインフラストラクチャの自動化をどのように駆動するかを示しました。
Cooperはセッション冒頭で、イベントドリブンアーキテクチャは初期段階ではしばしば非公式に発展し、チームは通常、どのサービスがイベントを公開し、どのサービスがそれらを消費し、メッセージがシステム内をどのように流れるかを理解するために共有知識に依存していると指摘しました。
しかし組織がスケールするにつれて、この非公式なアプローチは次第に脆弱化します。"スケールすると、場当たり的な方法では破綻します」とCooperは主張し、統合ポイントの発見が困難で、プロデューサーにはコンシューマーが不明であり、ドキュメント化されていないスキーマ変更が下流システムを破壊すると指摘しました:
プロデューサーとして、どのようにしてコンシューマーを見つけられますか?メッセージ名を探してすべてのリポジトリを検索しますか?Slackで誰かが私のイベントを消費しているかと尋ねますか?
これらの課題に対処するため、Cooperは大規模組織における非同期APIの管理に関する一連の新興プラクティスを提示しました。これらは3つの柱を中心に構成されています:ディスカバリー(非同期APIの発見と理解)、ガバナンス(スキーマの一貫性の確保と安全な進化)、そしてプロビジョニング(仕様からデプロイメントへの移行)です。
このアプローチの中核は、メッセージングインターフェースのための明示的な仕様の使用です。イベント駆動型アーキテクチャの構築を目的とした AsyncAPI や、xRegistry などの代替技術は、イベント契約を記述するための機械可読な手段を提供します。これらの仕様にはトピック、ペイロードスキーマ、およびメッセージメタデータが含まれており、チームが所有権を文書化し、分散システム全体での検索性を向上させることを可能にします。
「バイナリバインディングは実際にはバイナリではなく、構造化バインディングも実際には構造化されていない」と冗談めかして述べた後、クーパー氏は標準化されたイベントメタデータとスキーマガバナンスの重要性について議論しました。CloudEvents などのフォーマットは、メッセージングシステム全体で一貫したメタデータを提供でき、一方、スキマレジストリ(schema registries)を使用することで、チームはイベント構造を検証し、スキーマが進化しても互換性を管理することができます。
異なる互換性モードを比較し、なぜ開発者が単にチーム間の人間的な調整に頼ることができないのかを説明したクーパー氏は、これらのメカニズムが生産者と消費者の長期的な互換性を確保することで、より安全な変更管理をどのように支えるかを解説しました。
文書化とガバナンスを超えて、クーパー氏は自動化とマインドセットの変化の重要性を強調しました。「ツールと導入は依然として非常に困難です。チームに仕様を書き維持させるには、単なるツールの導入ではなく、文化の変革が必要です。」
成熟したイベント駆動型プラットフォームでは、エンドポイント仕様が真の信頼源(ソース・オブ・トゥルース)として機能し、これらの定義から AsyncAPI などのツールがコードアーティファクトを生成し、スキーマを自動的に登録し、メッセージングインフラストラクチャをプロビジョニングします。
Cooper は、EventCatalog といったツールの利点を強調しました。これらは、大規模な環境において非同期 API やイベント駆動型システムを可視化可能にし、発見可能かつガバナンス可能にします。この新しいアプローチは、チーム間の手動調整を削減し(「チケットではなく仕様!」)、生産環境における複雑なイベントフローに対してアーキテクトにより高い可視性と制御権を提供します。
スピーカーはセッションを終える際、オープンソースの例として Marmot を用いたデモを行い、非同期 API にも同期 API と同じ厳格なアプローチを適用する重要性を聴衆に再認識させました。
著者について
Renato Losio
Renato は、クラウドアーキテクト、技術リーダー、およびクラウドサービススペシャリストとして豊富な経験を持っています。現在、彼はベルリンに住み、リモートでシニアクラウドアーキテクトとして勤務しています。彼の主な関心領域はクラウドサービスとリレーショナルデータベースです。彼は InfoQ の編集者であり、認定された AWS Data Hero です。LinkedIn で彼に連絡することができます。
原文を表示
At QCon London 2026, Ian Cooper, senior principal engineer at Just Eat Takeaway, discussed managing asynchronous APIs in production, showing how endpoint definitions can drive code generation, schema registration, and the automation of messaging infrastructure.
Cooper began the session by highlighting how event-driven architectures often evolve informally in their early stages, with teams typically relying on shared knowledge to understand which services publish events, which services consume them, and how messages flow through the system.
As organizations scale, however, this informal approach becomes increasingly fragile. "At scale, ad-hoc breaks," argued Cooper, with integration points difficult to discover, consumers unknown to producers, and undocumented schema changes breaking downstream systems:
As a producer, how do I find consumers? Do I search all the repos looking for my message name? Do I ask on Slack if anyone consumes my events?
To address these challenges, Cooper outlined a set of emerging practices for managing asynchronous APIs in large organizations, organized around three pillars: discovery (finding and understanding the async API), governance (ensuring schemas are consistent and evolving safely), and provisioning (going from a specification to a deployment).
Central to this approach is the use of explicit specifications for messaging interfaces: technologies such as AsyncAPI, designed to build event-driven architectures, alongside alternatives such as xRegistry, provide machine-readable ways to describe event contracts. These specifications include topics, payload schemas, and message metadata, enabling teams to document ownership and improve discoverability across distributed systems.
Joking that "binary binding is not really binary and structured binding is not really structured," Cooper then discussed the importance of standardized event metadata and schema governance. Formats such as CloudEvents can provide consistent metadata across messaging systems, while schema registries allow teams to validate event structures and manage compatibility as schemas evolve.
Comparing the different compatibility modes and explaining why developers cannot simply rely on human coordination among teams, Cooper described how these mechanisms support safer change management by ensuring producers and consumers remain compatible over time.
Beyond documentation and governance, Cooper emphasized the importance of automation and a change of mindset: "Tooling and adoption is still very hard: getting teams to write and maintain specifications requires cultural change, not just tooling."
In mature event-driven platforms, endpoint specifications can serve as the source of truth, and from these definitions, tooling like AsyncAPI can generate code artifacts, automatically register schemas, and provision messaging infrastructure.
Cooper highlighted the benefits of tools such as EventCatalog in making asynchronous APIs and event-driven systems visible, discoverable, and governable at scale. This new approach reduces manual coordination between teams ("Specifications, not tickets!") and provides architects with greater visibility and control over complex event flows in production environments.
The speaker closed the session with a demo using Marmot as an open-source example, and reminded the audience of the importance of treating async APIs with the same rigour as sync APIs.
About the Author
Renato Losio
Renato has extensive experience as a cloud architect, tech lead, and cloud services specialist. Currently, he lives in Berlin and works remotely as a principal cloud architect. His primary areas of interest include cloud services and relational databases. He is an editor at InfoQ and a recognized AWS Data Hero. You can connect with him on LinkedIn.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み