CloudEventsがCloud Native Computing Foundationを卒業：Clemens Vasters氏とのQ&A

原文リンク

今年初め、Cloud Native Computing Foundation（CNCF）はCloudEventsが卒業したことを発表した。CloudEventsは、標準化された方法でイベント・メタデータを公開するように設計された仕様であり、プラットフォーム、サービス、システム間の相互運用性を確保するのに役立つ。

CNCF CloudEventsは、主要なメッセージング・プロトコルやエンコーディングに対応した、IT業界唯一のイベント・メタデータ・モデルである。これにより、それぞれのプロトコルの機能を抽象化することなくイベントを転送でき、同時にメタデータ情報を失うことなく、混合プロトコルのルートを通じてイベントを移動させることができる。

CNCF CloudEventsの概要（出典：LinkedIn Post）

InfoQは、マイクロソフトでメッセージングとストリーム処理のプリンシパルアーキテクトを務め、CloudEventsの推進者の一人であるClemens Vasters氏に話を聞いた。

InfoQ: CloudEventsの立ち上げからCNCFによる卒業までの道のりについて、何か洞察を聞かせてもらえるだろうか？

Clemens Vasters氏：

このプロジェクトは、2017年後半にシアトルの会議室で、相互運用可能なイベンティングのあり方について共通の基盤を見つけるという目的で、Googleのイニシアチブで多くの人々が集まったときに始まりました。多くの大企業を巻き込んだ取り組みにありがちなことですが、ガバナンス・モデルやスコープを把握することで、産みの苦しみがありました。私たちは最終的に、2つの基本原則について合意できました。まず、もっとも最小限でありながら有用なルールのセットを定義します。第二に、すでに発明されているものは何も発明しないこと、具体的には、新しいプロトコルやエンコーディングを発明せず、既存のものと統合することです。

ワーキンググループのメンバーの何人かは、SOAPと WS-*の標準化努力の盛衰と、それに続くSOAP対RESTの議論をまだ鮮明に覚えていました。我々は、イベントデータのためのエンベロープモデルを定義する目的において、いくつかの類似点があることを認識しており、非常に意図的に当時の失敗のいくつかを回避することに目を向けました。SOAP/WS-*は単一のデータエンコーディング（XML）に賭け、アプリケーションプロトコルを純粋なトランスポートチャネルに抽象化し、そのレベルでの「致命的な」エンドツーエンドのセキュリティを含む、新しいセマンティクスを最上位に階層化しようとしました。

CloudEventsでは、これらすべてのケースで反対の決定を下しました。私たちは、ユーザーが選択したエンコーディングでイベントとイベントデータを表現できるべきだと信じており、そのため最小限の抽象型システムを持っています。CloudEvent は、必要に応じてエンコードされた自己完結型のデータグラムとして「ネットワーク上で」表現できます。そして、JSON、XML、Apache Avro、Google Protobuf、AMQPエンコーディングのための正式な 「フォーマット」仕様があります。私たちはこれらの自己完結型データグラムを「構造化イベント」と呼んでいます。あるいは、既存のアプリに CloudEvents サポートを追加するもっともスムーズな方法ですが、CloudEvent を既存のアプリケーション プロトコルのメッセージ モデルに直接マッピングすることもできます。これにより、CloudEventのメタデータ属性がそのプロトコルの拡張ヘッダーになります。HTTP、MQTT、AMQP、NATS、Kafkaバインディングがあり、さらにベンダー固有のバインディングもあります。つまり、使用しているプロトコルやプラットフォームの長所や機能をすべて活用しながら、標準化されたイベントを伝送することができるということです。

InfoQ: CloudEvents仕様の開発と設計、特にMQTT、HTTP、Kafka、AMQPのような異なるイベントルーティングプロトコル間の相互運用性を確保する上で、どのような考慮事項と原則が指針となったのだろうか？

Vasters氏：

イベントは、MQTTやHTTPで送信するデバイスから始まり、Kafkaにコピーされ、AMQPのキューに移動するなど、複数のホップを経由してルーティングされることが多くなっているため、情報の損失や曖昧さなしに、イベントが常にネイティブ・プロトコルのメッセージや構造化フォーマットとマッピングできるよう、特別な注意を払った。CloudEventsの属性名がセパレータを許可せず、小文字のラテン文字のみであるようないくつかの決定は、単にこれらのオプションすべてにわたって相互運用可能な文字セットを徹底的に分析した結果である。

最終的に、私たちはCloudEventのメタデータにたどり着き、以下の質問に答えました。

• それはどんな種類か？「type」
• どこから来たのか？「source」
• 何についてのイベントか？「subject」
• どのイベントか？「id」
• いつ提起されたか？「time」
• イベントデータはどのようにエンコードされているか？「datacontenttype」
• イベントデータはこのコンテントタイプのどのスキーマに準拠するか？「dataschema」
• CloudEventsのバージョンは？「specversion」

その仕様の現在のバージョンは「1.0」であり、そのバージョンを終えた後、私たちは現在、そのコアの拡張とさらなるフォーマットとバインディングに集中しています。私たちは明確に「2.0」を作ることを避けていますが、コアとなる仕様を守ることで、誰にとっても信頼できる基盤にしています。

すべての標準化作業において、忍耐と安定は不可欠であり、CNCFの卒業は、この忍耐が実を結ぶことを示しています。

InfoQ:このマイルストーンを達成した後、CloudEventsに対する業界の評価はどうだったか？

Vasters氏：

https://cloudevents.io/ホームページの採用者ギャラリーでは、CloudEventsを採用したもっとも著名なプラットフォーム・ユーザーを紹介しています。マイクロソフトでの私の仕事では、より多くの企業顧客が、ソリューションのある側面について私たちに相談する前から、彼らの設計にCloudEventsを取り入れているのを目にしますが、それは素晴らしい兆候です。マイクロソフトにとって、CloudEventsは、まだそうなっていないすべてのプラットフォームでのイベントにおいて、一般的に収束していくイベントモデルだと言えます。

InfoQ: これらのエコシステムの中で、CloudEventsの継続的な成長と進化をどのように想定しているか？

Vasters氏：

CloudEventsは、イベント駆動型アプリケーションのための相互運用可能なエコシステムの基盤だと考えています。

• その旅における次のステップは、CloudEventとそのペイロードを宣言し、それらのCloudEvent宣言をアプリケーション・エンドポイントに関連付けるためのメタデータ・モデルです。ゴールは、イベント・プロデューサーが、アプリケーションをそれに基づいて構築できるように、どのようなイベントを発生させるかを前もって正確に宣言できるようにすることです。我々は、イベントフローが「タイプセーフ」になり、コンシューマがストリームやトピックから期待できるイベントのタイプを理解できるようになることを望んでいます。私たちは、一般的なプログラミング言語のコレクションにジェネリックとテンプレートが追加されるような、イベント・フローのタイプセーフ・レベルを作ることを目指しています。

• 私たちは、「xRegistry」と呼ばれるこの取り組みに数年を費やしており、ある種の副産物として、非常に汎用的で、バージョンを意識し、拡張可能なメタデータ・レジストリ・モデルを定義するに至りました。このモデルは、ドキュメント・フォーマットとリソース指向APIの間に完全な対称性を提供するという特筆すべき特徴を持っています。ここでは、CloudEventsと同様に、抽象的なモデルを定義しています。APIは現在OpenAPIに投影されており、ドキュメントフォーマットはJSONとAvroスキーマで表現されています。ドキュメント・フォーマットをXMLで表現することを期待しています。また、APIをRPCバインディングやその他の方法で表現することも絶対に可能です。

• xRegistryで定義されている具体的なレジストリは、直列化と検証スキーマ（JSONスキーマ、Avroスキーマ、Protosなど）のためのバージョン対応スキーマ・レジストリ、CloudEventやMQTT、AMQP、Kafka、NATS、HTTPメッセージのテンプレートを宣言できるメッセージ・メタデータ・レジストリ、メッセージ定義レジストリにバインドされている抽象的および具体的なアプリケーション・ネットワーク・エンドポイントをカタログできるエンドポイント・レジストリです。OpenAPIや AsyncAPIのようなAPIコントラクト定義ドキュメントを持つ別のレジストリのスケッチもあります。

このワーキンググループで行ってきたすべてのことと同様に、原則は、発明する必要があるものだけを発明することです。私たちはまた、対象範囲についても非常に慎重です。一つのイベントチャネルを正確に記述する前に、イベントチャネル間の関係を標準化する時期ではないと考えます。そのため、チャネルAにイベントを送信した場合、チャネルBから何が出てくるかを記述するような、上位レベルのコントラクト・モデルは今のところ残しています。

最終的には、いくつかの柱にまたがるイベントフロー・アクティビティ図を反映した正式な契約モデルができればクールだと思います。ITUにはこのための古い先行技術がいくつかありますが、私たちはまだそこに到達していません。

LFのAsyncAPIの取り組みは、即座に接続された当事者の視点から、イベント・フローのためのシンプルな契約モデルを提供します。私たちが仕様作業を検証するために使用しているプロトタイプのコードジェネレーターは、xRegistryのエンドポイントやメッセージグループの定義から、テンプレート化されたAsyncAPIドキュメントやOpenAPIドキュメントを生成できます。我々は、xRegistryが基盤を提供することで、これらの取り組みを補完するものと考えています。