CNCFがDocker Notary(セキュリティ)、Lyft Envoy(サービスメッシュ)、Uber Jaeger(トレース)各プロジェクトを新たにホスト

Cloud Native Computing Foundation(CNCF)は先月、新たにホスト対象とした４つのプロジェクトを発表した。DockerのNotaryは、強力な暗号署名を使用して、コンテナイメージなどのディジタルコンテンツの信頼性を提供するようにデザインされたプロジェクトである。NYU Tandon School of EngineeringのThe Update Framework(TUF)は、Notaryを実装したオープンソースの信頼仕様(trust specification)であり、LyftのEnvoyサービスメッシュは、マイクロサービス通信のためのデータプレーンプロキシだ。UberのJaegerトレースプロジェクトは、マイクロサービスベースのアプリケーションのような分散システム内の要求/データフローの監視を可能にする。

Dockerが2015年6月に立ち上げたNotaryプロジェクトは、強力な暗号署名を使用して、ディジタルコンテンツを高い信頼性レベルで提供することを目的とする。例えば、暗号署名されたコンテナイメージや関連メタデータなどだ。ソフトウェアの出所保証に加えて、サプライチェーン上のいずれかの場所において、著作者の許可なくコンテンツの修正が行なわれていないことも保証する。これにより、Docker Content Trust(Notaryを使用)を採用することでコンテンツ利用に関する明確なポリシを確立したDocker Enterprise Edition(EE)のような、よりレベルの高いシステムが実現する。

The Update Framework(TUF)は、2009年にJustin Cappos博士が作成したオープンソース仕様であり、NYU Tandon School of EngineeringにあるCappos博士のSecure Systems Labのメンバによって開発が続けられている。NotaryがTUFの最も完成度の高い実装であったため、このプロジェクトはNotaryとのパートナシップの下でCNCFに移管された。Notary/TUFはクライアント、およびサーバアプリケーションとのペアを提供して、署名付きメタデータをホストし、限定的なオンライン署名機能を実行する。

図１. Notary/TUFによる署名および検証のシーケンス図

現時点でのNotaryの使用例には次のようなものがある – Dockerでは、Docker Content Trustと、docker trustサブコマンドのすべての実装にNotaryを使用している。コンテナレジストリSaaSであるCentOSのQuayでは、コンテナイメージとメタデータの信頼性と検証を行なうフレキシブルなライブラリとしてNotaryを採用している。またLinuxKitでは、カーネルとシステムパッケージの配布にNotaryを使用している。Notaryはコンテナ配布以外の実運用環境でもすでに使用されている。Cloudflareは同社のPALツールにNotaryを統合して、コンテナアイデンティティのブートストラップに使用している。またKolideでは、osqueryツールの自動アップデータのセキュリティのためにNotaryを用いている。

CNCFは先月、Envoyが11番目のホスト対象プロジェクトになることも発表した。自社のアーキテクチャを非モノリス化する目的でLyftが開発したEnvoyは、アプリケーションに対してネットワークを透過的なものにする、ハイパフォーマンスなオープンソースのエッジおよびサービスプロキシである。ソフトウェアエンジニアのMatt Klein氏が自身のチームを率いて、ネットワークの複雑性の大半をアプリケーション開発者に対して抽象化するテクノロジを設計した。Envoyはパフォーマンス上の理由からC++で記述されているが、プロセスの外部アーキテクチャは、HTTP2/ gRPCプロキシやMongoDBフィルタリング、レート制限など、あらゆる言語およびランタイムのアプリケーションで利用可能である。

図２. LyftにおけるEnvoyの使用状況

Klen氏は先日のブログ記事で、Lyftのビジネスはほぼ完全にオープンソース技術に基づいている、と説明している。

今日私たちが愛用するサービスは、[オープンソースなしには]そのほとんどが存在し得ません。Envoyに費やされた多大な開発努力を考え、モノリシックからマイクロサービスアーキテクチャへの移行において、多くの企業が同じような問題に直面していることを理解する上で、私たちは、当社の成長を育んだより大きなコミュニティに報いたいと願ってきました。そこでEnvoyのオープンソーシングを進めて、コミュニティの構築を図ることを決定したのです。

現在Envoyには、少なくとも10企業から78名のコントリビュータが参加している。メンテナの主体はLyftとGoogleの社員だ。“テクノロジとしてのEnvoyには、現代的サービスアーキテクチャの中心的なビルディングブロックになるチャンスがある”、とKlein氏は考えている。この考えはすでに現実になりつつある – Verisonなどの企業では、Nelson自動コンテナ配信プラットフォームでEnvoyを活用している。サービスメッシュコントロールプレーンのIstioプロジェクトは、業界内で急速にその勢いを増している。さらにはDatawireなどのスタートアップ企業が、Envoy上にAmbassadorなどオープンソースツールを開発中である。Envoyは、Buoyantが開発した既存のCNCFサービスメッシュプロジェクトのLinkerdを補完する。

プロジェクトのホスティングに関して実施された最近の発表の最後は、分散トレースプロジェクトのJaegerである。Uberが立ち上げた同プロジェクトは、CNCFがホストする12番目のプロジェクトになる予定だ。JaegerはOpenTracing互換のデータモデルを使用して、Go、Java、Node、Python用の測定ライブラリを提供する。OpenTracingはCNCFの既存プロジェクトで、分散トレースに関するベンダニュートラルなオープンスタンダードを定義するものだ。

図２. JaegerアーキテクチャとUberでの運用状況

Uberは2015年にJaegerの導入を社内的に開始した。現在は数千のマイクロサービスが統合されており、毎秒数千件のトレースを記録している。同トレースシステムはBase CRMやStagemonitor、Symantecなどの企業でも使用されている。さらにRed Hatなどの企業も、プロジェクトに対して積極的に貢献している。CNCF技術監督委員会代表でプロジェクトスポンサのBryan Cantrill氏は、先日のブログ記事で、分散型トレースはマイクロサービスベースのシステムに監視性を実現する中核的技術である、と述べている。

マイクロサービスベースのアーキテクチャに対する批判のひとつとして、分散モノリス – 不測なインタラクションひとつでフェールするような、複雑な相互依存システムが出来上がる可能性があります。この問題に対処するためには、サービス間のコードフローを監視可能であることが必要です。

Jaegerに関する詳細は、Yuri Shkuro氏によるUberの記事“Evolving Distributed Tracing”にあります。この記事ではJaegerの歴史や、アーキテクチャ上の選択に関する理由が説明されています。

CNCFに関しては、プロジェクトのWebサイトに詳細な定款や現在のメンバシップ、ホストするプロジェクトなどが紹介されている。Webサイトの発表(announcement)セクションでは、今回の記事で取り上げたホスト対象プロジェクトに関する詳細も見ることができる。