1773757469
2026-03-17 14:15:00
QConロンドン2026では、 イアン・クーパーJust Eat Takeaway のシニア プリンシパル エンジニアが語りました。 本番環境での非同期 API の管理では、エンドポイント定義がコード生成、スキーマ登録、メッセージング インフラストラクチャの自動化をどのように推進できるかを示しています。
クーパー氏はセッションの冒頭で、イベント駆動型アーキテクチャが初期段階で非公式に進化することが多く、どのサービスがイベントを発行し、どのサービスがイベントを消費するか、メッセージがシステムをどのように流れるかを理解するためにチームは通常、共有された知識に依存していることを強調した。
しかし、組織が拡大するにつれて、この非公式なアプローチはますます脆弱になります。クーパー氏は、統合ポイントの発見が難しく、消費者が生産者に知られていないこと、下流システムを破壊する文書化されていないスキーマ変更により、「大規模になるとアドホックな破壊が発生する」と主張しました。
生産者として消費者を見つけるにはどうすればよいでしょうか?すべてのリポジトリを検索してメッセージ名を探しますか?誰かが私のイベントを利用したかどうかを Slack で尋ねますか?
これらの課題に対処するために、Cooper 氏は、大規模組織における非同期 API を管理するための一連の新たなプラクティスを概説しました。これらは、ディスカバリー (非同期 API の発見と理解)、ガバナンス (スキーマの一貫性と安全な進化の確保)、プロビジョニング (仕様からデプロイへの移行) の 3 つの柱を中心に構成されています。
このアプローチの中心となるのは、メッセージング インターフェイスの明示的な仕様の使用です。 非同期API、次のような代替手段と並行して、イベント駆動型のアーキテクチャを構築するように設計されています。 xレジストリ、イベント コントラクトを記述する機械可読な方法を提供します。これらの仕様には、トピック、ペイロード スキーマ、メッセージ メタデータが含まれており、チームが所有権を文書化し、分散システム全体での発見可能性を向上させることができます。
Cooper 氏は、「バイナリ バインディングは実際にはバイナリではないし、構造化バインディングは実際には構造化されていない」と冗談を言いながら、標準化されたイベント メタデータとスキーマ ガバナンスの重要性について議論しました。などの形式 クラウドイベント スキーマ レジストリを使用すると、チームはイベント構造を検証し、スキーマの進化に応じて互換性を管理できます。
Cooper 氏は、さまざまな互換性モードを比較し、開発者がチーム間の人による調整に単純に依存できない理由を説明し、これらのメカニズムがプロデューサーとコンシューマーの互換性を長期にわたって維持することで、より安全な変更管理をどのようにサポートしているかを説明しました。
文書化とガバナンスを超えて、クーパー氏は自動化と考え方の変化の重要性を強調しました。「ツールと導入は依然として非常に困難です。チームに仕様を作成して維持させるには、ツールだけでなく文化の変化も必要です。」
成熟したイベント駆動型プラットフォームでは、エンドポイント仕様が信頼できる情報源として機能し、これらの定義に基づいて、AsyncAPI などのツールがコード アーティファクトを生成し、スキーマを自動的に登録し、メッセージング インフラストラクチャをプロビジョニングできます。
クーパー氏は、次のようなツールの利点を強調しました。 イベントカタログ 非同期 API とイベント駆動型システムを大規模に可視化、検出可能、管理可能にすることです。この新しいアプローチにより、チーム間の手動調整 (「チケットではなく仕様!」) が軽減され、アーキテクトは運用環境での複雑なイベント フローの可視性と制御が向上します。
講演者は以下を使用したデモでセッションを締めくくりました。 マーモット オープンソースの例として説明し、非同期 API を同期 API と同じ厳密さで扱うことの重要性を聴衆に思い出させました。
#QCon #London #大規模な非同期 #API #の管理