CortexとThanosが共に過ごした情熱的な一年
はじめに
クラウドネイティブ界隈では昨今、チーム間で協力したり、知見を出し合うコラボレーションが重要視されるようになったが、残念ながら自分のところまではまだ降りてくるレベルにないようだ。
今年のクリスマスの日もまた仕事とコラボレーションを組んだ自分は、その代わりに推しOSSsを見守ることで心の隙間を埋めようと思う。
CortexとThanosが共に過ごした情熱的な一年を振り返ってみた。
📘【note】
この記事はKubernetes2 Advent Calendar 2020の25日目です。
先日はysakashitaさんのKubernetesにおけるContainer Object Storage Interface (COSI)の概要という記事でした。
きっかけ
技術書を英語で読む会/ReadingParty でSoftware Engineering at GoogleというGoogleのマネジメント本を輪読する中で、最近PrometheusConで聞いた話だけど...と藤原さんが紹介してくれたとあるコラボレーションにまつわる事例を広めたいと思う。
CortexとThanosという、Prometheusの冗長性、データの永続性を目的として開発された、機能面から見れば完全に競合するプロダクトがある。
PrometheusCon2019を通じて生まれた関係は、とあるPRを通して大きく飛躍し、やがてプロジェクトの成り立ちや技術的思想の違いを乗り越えてコラボレーションに繋がった。
このコラボレーションは一年をかけて大きな成果を生んだ。
- 一例: Cortexは、Prometheusを通じて収集したメトリクスデータをCassandraなどNoSQLデータベースに加えて、Amazon S3などのブロックストレージに保存できるようになった
- このコンポーネントにはThanosの同じ機能のコンポーネントがほぼそのまま使われている
- 一例: Thanosは、e2eをCortex流に変えることでGitHub Actionsを使った高速なe2e環境を得られるようになった
彼らがコラボレーションすることが決まって一年、両プロジェクトの開発はそのスピードを緩めることなく今も成長を続けている。
彼らの成功を見ているとこういう疑問が浮かぶだろう。
- なぜ、ライバル同士にあたる彼らはコラボレーションし続けることができたのか？
- きっかけなんて振り返れば取るに足らない些細なものだ。
大事なのは関係が持続することである😭
- きっかけなんて振り返れば取るに足らない些細なものだ。
- そして技術的にどういった課題を解決するに至ったのか？
- ディテールを深めれば、今後、運用する上で気づくことがあるかもしれない
今年の初夏、PromCon2020というバーチャルイベントでCortextとThanosMetricsのメンテナーが二人でコラボレーションの内容を説明する機会があった。今更だがその内容を紹介したい。
CortexとThanosのコラボレーションが、如何にしてPrometheusのスケーリングをすべての人にとってより良いものにしたか
原題: How the Cortex and Thanos projects collaborate to make scaling Prometheus better for all
上記ブログ、PromCon Online 2020で話されたSharing is Caring: Leveraging Open Source to Improve Cortex & Thanos、KubeConで話されていたScaling Prometheus: How We Got Some Thanos Into Cortex - Thor Hansen, HashiCorp & Marco Pracucci、各社のテックブログなどを参考にした。
そもそもPrometheusとは？
PrometheusはSoundCloud社によって2012年から開発が始まり、多くの開発者と企業を引き付ける、クラウドネイティブなシステム監視&アラートツールである。特にKubernetesと相性がよく、PrometheusはKubernetesとともに開発の歴史を歩んできたといっても過言ではないだろう。[1]
一方で、Prometheusが開発された当時はなかった贅沢な悩みも最近は出てきた。モニタリングのSaaSを展開していることで著名なDatadogがHighlights from KubeCon + CloudNativeCon 2020で述べているように近年は冗長性やエッジクラウドを意識して、マルチクラウド、マルチクラスタ構成の事例が多くなっている。
そのような環境に対応するためPrometheusのアーキテクチャには Hierarchical federation や Cross-service federation といった多段でPrometheusを組むことにより、メトリクスを一か所で確認するための仕組みが備わっているものの、実は全体最適解ではない。
Hierarchical federationの図。
Prometheus Federation-Prometheus 1.x VS Prometheus 2.xより引用
課題の一つが[2][3]、同じようなメトリクス情報を集約する機能がないことである。マルチクラスタ環境、マルチホスティング環境に個々のPrometheusが入った場合、クラスタA、クラスタBと複数のクラスタから連携されるデータは個別に可視化される。これではクラスタを一括して監視したい場合に、ユーザビリティを損なうことになる。
また、Prometheusのtsdb=時系列データベースは大容量のデータを効率よく保存するには不向きだということもポイントだ。メトリクス情報を長期間保存することは、年間を通じたキャパシティプランニング[4]や障害発生時におけるポストモーテム=振り返りで参照するために欠かせない。天文学レベルのメトリクス情報を信頼性が高く費用効果の高い方法で保存するには、時系列データベースに頼らない別のストレージ手段を使用したほうがいい。
そのあたりのモチベーションを踏まえて登場したのがCortexとThanosである。
Prometheusの課題を解決するプロダクト
Cortex
Cortexは元々Grafana LabsのTom Wilkie氏とJulius Volz氏(元SoundCloud社。Prometheusプロジェクトを始めた一人)によって2016年に誕生したOSSである。
The Cortex project was started by Tom Wilkie and Julius Volz in June 2016, joining the CNCF Sandbox in September 2018. It was promoted to CNCF’s Incubation level in August 2020. Cortex lets users to query metrics from many Prometheus servers in a single place, without any gaps in the graphs due to server failure. Cortex also allows users to store Prometheus metrics for long term capacity planning and performance analysis.
Cortexプロジェクトは、2016年6月にTom WilkieとJulius Volzによって開始され、2018年9月にCNCFのサンドボックスに参加しました。2020年8月にCNCFのインキュベーションプロジェクトに昇格しました。Cortexを利用することで、ユーザーは多くのPrometheusサーバーからのメトリクスを一箇所でクエリすることができ、サーバーの障害によるグラフのずれもありません。また、Cortexは長期的なキャパシティプランニングやパフォーマンス分析のために、ユーザーがPrometheusのメトリクスを保存することを可能にします。
引用元: https://grafana.com/oss/cortex/
補足すると、Cortexは当初Weaveworksが運営するWeaveCloudのPrometheusメトリックのストレージを提供するために開発が始められたプロジェクトだった。[5] しかし、同じようなモチベーションに支えられてCortexは広く利用されることとなる。
現在ではGrafana Labs、Microsoft、Splunk、Weaveworksの4つの異なる企業から8人のメンテナがいる大きなOSSプロジェクトに成長した。[6]
今、Cortexプロジェクトの中で中心となっている企業はGrafana Labsだ。現在CortexのContributor Top5のうち、4人はGrafana Labs、1人はWeaveworksであり、彼らの活躍を抜きにして、Cortexを説明することはできない。
Grafana Labsは、自社のGrafana CloudでPrometheusのメトリクスに対応した信頼性の高いプラットフォームを提供するために、プロジェクト開始当初より三年以上Cortexを活用している[7]。 その過程でクエリパフォーマンスの大幅な向上、水平方向にスケーラブルなアラートとルール評価サービス、GoogleBigtableとGoogleCloudStorageのバックエンドなど様々な機能を開発し、Prometheusにも知見を還元している。
How the Cortex and Thanos projects collaborate to make scaling Prometheus better for allで、登壇したCortexとThanosのメンテナーであるMarco PracucciさんもGrafana Labsの所属だ。
2020年8月にCNCFのインキュベーションプロジェクトに昇格したCortexは、現在EA、Gojek 、Rowe Digital などの組織で巨大なスケールで活用されており、1,500 万以上の時系列データを取り扱っている[8]。
Thanos
Thnosは2018年にImprovable社[9]によって公開されたOSSである。元Improbable社のBartlomiej Plotka氏やFabian Reinartz氏(Prometheusの現在内部で使われているtsdbのデザインをした人[10])らによって開発された。
当初の開発モチベーションは、自社のゲームのクラウドプラットフォームの運用監視機能を拡張し、Cortexと同じでPrometheusに関して抱えていた課題を解決することだった。
Introducing Thanos: Prometheus at scaleより引用する。
As you might guess from our flagship product SpatialOS, Improbable has a need for highly dynamic cloud infrastructure at a global scale, running dozens of Kubernetes clusters. To stay on top of them, we were early adopters of the Prometheus monitoring system. Prometheus is capable of tracking millions of measurements in real time and comes with a powerful query language to extract meaningful insights from them.
当社の主力製品であるSpatialOSからご想像いただけるかもしれませんが、Improbableは、数十台のKubernetesクラスタを稼働させているグローバル規模の高度に動的なクラウドインフラストラクチャのニーズを持っています。それらを常に把握するために、当社はPrometheus監視システムを早期に採用しました。Prometheusは何百万もの測定値をリアルタイムで追跡することができ、そこから意味のある洞察を抽出するための強力なクエリ言語が付属しています。
Prometheus’s simple and reliable operational model is one of its major selling points. However, past a certain scale, we’ve identified a few shortcomings. To resolve those, we’re today officially announcing Thanos, an open source project by Improbable to seamlessly transform existing Prometheus deployments in clusters around the world into a unified monitoring system with unbounded historical data storage.
プロメテウスのシンプルで信頼性の高い運用モデルは、その大きなセールスポイントの一つです。しかし、ある一定の規模を超えると、いくつかの欠点があることが判明しました。これらを解決するために、世界中のクラスタにある既存のPrometheusをシームレスに変換し、無制限の履歴データストレージを備えた統合監視システムに変換する、Improbable社によるオープンソースプロジェクト、Thanosを本日正式に発表します。
CNCFでのsandboxプログラムを経て、奇しくもCortexより一日早い2020年8月19日に、Thanosはインキュベーションプロジェクトに昇格した。AdForm、Grafana Labs、Red Hat、UtilityWarehouseの4つの異なる企業から7人のメンテナがいる。
ここにCortexでも中心企業として活躍しているGrafana Labsの名前があるのはさておき、中心企業と言えるのはRed Hatだろう。ThanosのContributor Top6のうち、4人はRed Hat、1人はAdFrom、もう一人はプロジェクト当初にImprobable社兼CoreOS社員としてPrometheusの開発、Thanosのローンチに大きく貢献したFabian Reinartz氏[11]であり、彼らの活躍を抜きにして、Cortexを説明することはできない。
Red Hat社がThanos Projectで重要な役割を果たすようになったルーツは、Red Hat社が買収したCoreOS社まで遡る。Metrics関連でCoreOS社が手がけたプロダクトに Prometheus Operator がある。OperatorはKubernetes上へのプロダクトの導入から運用までを自動化し、運用上の関心事をソフトウェア開発に移すべく、2016年にCoreOS社によってはじめて導入された。[12]
その際に理論実証として同じくCoreOS社が開発していたetcdをetcd-operator化したわけだが、同じ年に Frederic Branczyk氏によって Prometheus もまたOperator化することになる[13]。 その後もCoreOS社は積極的にPrometheusプロジェクトにコントリビュートし[14]、 PrometheusはKubernetesの次にCNCFのインキュベーションプロジェクトを卒業するまでに成長する。
その成果は同じく元CoreOS社のメンバが精力的に携わったRed Hat社のKubernetesプロダクトであるOpenShiftのモニタリングスタックに生かされている[15]。
この流れを加速するかのように、Thanosのプロジェクトのローンチから携わり、現在もメンテナーとして活躍されているTop ContributorのBartlomiej Plotka氏がImprobable社から、Red HatがOpenshift Observability Platform TeamのTechnical Team Leadとして加わり、OpenShiftのモニタリングスタックはPrometheus+Thanos+Grafanaの現在の構成に至る。
もちろん、ThanosはRed Hat社だけのものではない。Alibaba Cloud、Banzai Cloud、HelloFresh、Monzo等、他にもたくさんの商用環境で使用されており、今後も活躍が期待されるプロダクトだ。
両者の違いはなにか？
CortexとThanos、開発された経緯も用途も非常によく似たプロダクトは、実に共通点が多い。
- Prometheusのメンテナーによって開始されたプロジェクト
- gRPCをコミュニケーションのために利用している
- Go言語で書かれている
- 同じExternal API(Rules, Alerting, Querying, Metaデータ)
- Prometheusのソースコード及びパターンを再利用している
- 水平方向でのスケールが可能
- CNCFのホスティングプロジェクト
だがしかし、実装に限って言えば全く違うアプローチを採用している。
Two Households, Both Alike in Dignity: Cortex and Thanos(格式も同じ、二つの名家: CortexとThanos) という2019年にRed HatのBartlomiej Plotka氏とGrafana LabsのTom Wilkie氏によって行われた共同セッションから引用しよう[16])。
両社の違いは大きく三つある。
- アーキテクチャデザインの違い
- HA構成を組んだPrometheusから取得したメトリクスが重複、欠損していた場合、それを補完して一つの時系列にするときの時間合わせの基準点の違い
- メトリクスの長期間における保持方法の違い
このうち、最も特色があるのは1番のアーキテクチャデザインの違いだ。詳しく説明しよう。
アーキテクチャデザインの違い
運用監視ツールにおいて、監視対象のデータをどのように取得するのか、よく説明されるが「プッシュ型」か「プル型」かという違いだ。
- プル型
プル型では、サービスがリモートノードに対して、ノードの情報を送りつけてくるよう要求を出します。中央サービスは、いつリクエストが起きるかスケジュールすることに責任を持ちます。[17]
- プッシュ型
プッシュ型では、クライアント（サーバやアプリケーションなど）はデータを他の場所に、一定間隔あるいはイベントが発生したタイミングでプッシュします。[17:1]
Push vs. Pull Monitoring Configsで述べられているように、両者ともに甲乙つけがたい、良い面と悪い面が存在する。
Prometheusはプル型を採用しているが、そのメリットについて次の通り、説明している。[18]
Pulling over HTTP offers a number of advantages:
You can run your monitoring on your laptop when developing changes.
You can more easily tell if a target is down.
You can manually go to a target and inspect its health with a web browser.
Overall, we believe that pulling is slightly better than pushing, but it should >not be considered a major point when considering a monitoring system.
For cases where you must push, we offer the Pushgateway.HTTP通信を通じたデータの取得方法(プル型)は下記のアドバンテージがあります。
監視対象のサービスで開発時に修正が入った場合、ラップトップからモニタリングすることができます。(補足: プッシュ型の場合、運用監視サーバーを建てるところから始めないといけない)
監視対象のサービスを手動で捕まえて、ウェブブラウザでヘルスチェックを行うことができます
全体的には、プッシュ型よりもプル型の方が若干優れていると考えていますが、監視システムを検討する際には大きなポイントとは考えない方が良いでしょう。
どうしてもプッシュ型を使いたい場合、Pushgatewayを提供しています。
要はプッシュ型の方がどのような監視データを出力すればよいか、開発時に確認するのが楽ってことであるが、もちろん課題もある。Prometheus用の監視用エンドポイントはそのままではリクエストを送りさえすれば情報が取得できてしまうので、その口にベーシック認証などのキャップは欠かせない。また、どのデータを監視用として差し出すかは各サービスの裁量によるので、プッシュ・プル混在型のZabbixのエージェントなどと違い、メトリクス情報を中央集権的に制御するすべもない。
そのあたりを踏まえた上で、CortexとThanosを見てみよう。
Pull型のThanos, Push型のCortex
Thanosの場合
ThanosはPrometheusと同じ、Pull型のアーキテクチャを採用している。
- リモートクラスタのPrometheusでそれぞれThanos sidecarが動いており、
- そこからThanos Querier がメトリクス情報を収集している[19]。
- メトリクス情報をGrafanaなどのクライアントを通じて確認したい場合は、
Thanos Queryを通じて透過的に——要するにThanosを意識せず——Prometheus Query APIによって行うことができる。
より粒度を細かくして、どのようにメトリクス情報が保存されるか見てみよう。
s3のようなオブジェクトストレージで、メトリクス情報は長期保管される。その際にThanosはCompactorを通じてデータの圧縮を行っている。
Thanos QuerierはThanos sidecarに直接アクセスして最新情報を取得することもできるし、オブジェクトストレージに保存した古いデータにThanos Gatewayを通じてアクセスすることもできるため、メトリクス情報の集計結果への反映が早い特徴がある。
Cortexの場合
CortexはPush型のアーキテクチャを採用している。
- 各リモートクラスタにインストールされたPrometheusは、自身のRemote Write APIを通じて、Cortexにメトリクス情報の書き込みを行う[21]。
- Cortexクラスタは各Prometheusサーバーより収集したメトリクス情報を保存する。
- メトリクス情報をGrafanaなどのクライアントを通じて確認したい場合は、このCortexクラスタにアクセスすることで行う。
Cortexクラスタとざっくりまとめられた部分を細かくしたのが下記の図だ。
注目すべきはPrometheusのデータの保存先である。ここにさらっと書いてあるindexとChunksの意味を知るには、Prometheusのデータ構造を追う必要がある。
Prometheusのデータ構造は一定の時間ごとにブロックという単位で保存される。
Zラボの@tkusumiさんによるPrometheus 2.0 のストレージ (TSDB) の構造より引用
このブロックの中で特に重要なデータが Chunks と index だ。
- chunks
- 時系列データが保存されているディレクトリ名。転じて時系列データそのもの。
- 参考: Chunks Disk Format
- index
- Prometheusのラベルと 時系列データ の転置インデックス。
- 参考: Index Disk Format
Cortexプロジェクトでは、このブロックを保存、索引する仕組みを総称してCortex block storage と呼んでいる。
2019年の発表時、index情報の保存先としてCortexはNoSQLデータベースしか選択することができなかった。のちにThanosプロジェクトの協力を得てオブジェクトストレージも利用可能になる。次の章で詳細を説明する。
プッシュ型のCortexの場合、メトリクス情報を中央集権的に管理することができるため、エンプラ系なら求められるデータアクセスに関する権限管理や分割統治がしやすい特徴がある。
さて、両者の違いについて、設計から理解を深めたところで、CortexとThanosがいかにしてコラボレーションを実施したのかみてみよう(やっと本題...)。
CortexとThanosのコラボレーションのきっかけ
2019年当時、CortexはThanosに対抗すべく、ユーザーエクスペリエンスの向上を目指して色々な施策をしていた。ノードの可用性を支えるGossip hashring[22] の依存関係を減らしたり、商用環境のリリースやメンテナンスを簡易化するために行ったSingle binary modeの実装もそのうちの一つである。
同じ頃、コミュニティサイド、HashiCorp社のThor Hansen氏によって突然、新たなPRが起票される。Cortex block storageのindex情報の格納先として、S3を利用できるようにするものだった。
元々、メトリクス情報の本体であるchunksはオブジェクトストレージに格納できたが、後から検索するときに必要となるindex情報はNoSQLデータベース+カスタマイズされたindex storeを利用していた。
このため、Cortexはセットアップをする際にApache CassandraなどNoSQLデータベースを新たにセットアップする必要があった。このPRはその構築の手間を省いたわけだ。
...だが、そのソースコードはCortexのライバルとも言えるThanosから流用したものだった。
The motivation behind this PR was to be able to store larger sized objects into the S3 storage backend. It leverages a lot of code from the thanos project to accomplish that.(hodahgiにより強調)
このPRの動機は、より大きなサイズのオブジェクトをS3ストレージのバックエンドに格納できるようにすることでした。これを達成するために thanos プロジェクト の多くのコードを活用しています。
このPRが起票された時、やがてCortexとThanosの行く先を大きく変えるきっかけになるとは当時誰も思わなかった。
Thor Hansen氏の格闘と成果
Instead of building it from scratch, why not collaborate with Thanos?
#1695 を提案したThor Hansen氏にとって車輪の再発明の代わりに、当時既にオブジェクトストレージを使って動いていたThanosプロジェクトのコンポーネントを利用したのは自明の理だった。
最初の起票から9か月と多くの人の助けを得て、Thor氏はアイディアをソリューションに昇華させる。
ブロックストレージの安定化とスケールアウトができるようになり、
新しく2つのcortexサービスである compactor と store gateway を追加し、
chunks, index, metadataのキャッシュ機能を実装し、
当初の素直な実装にはなかったデータの保持期間などのlimitterやオプション機能を追加し
最適化やたくさんのバグ修正を行った。
...そして、実際にGrafana Labsの一部の商用環境で使われるまでになった。
Object Storeを利用したCortexアーキテクチャ図だ。
ここで特筆すべきはObject Storeを取り巻く三つのコンポーネント、 ingester 、 store-gateway、 compactor である。これらは全てThanosのコンポーネントから来ている。
ingester (Thanosの名称 Shipper ) はObject Storeにメトリクス情報を設定する。
store-gateway (同Thanos: Thanos Store Gateway) はObject Storeからメトリクス情報を引っ張ってくる。
compactor (同Thanos: Thanos Compact) はブロックストレージに格納された重複データを圧縮、ダウンサンプリングすることでデータサイズを小さくする[23]。
Upsteam: 相手を尊重するということ
Cortexは、index storeの周辺部をThanosのコンポーネント由来の実装をしたのは先に説明した通りだが、実装にあたりCortexプロジェクトは大きな決断を下すことになる。CortexはThanosのコンポーネントを採用するにあたって、Thanosのソースコードをforkして改造するのではなく、 upstreamとすることを選んだのだ。
どういうことか? 具体的に知りたい場合、Cortexプロジェクトで Update Thanos でIssueを探せば答えが自然とわかると思う。
Thanosのバージョンが更新されるたびにCortexプロジェクトのThanosコンポーネントも追随して更新していることがわかる。Cortex側の独自要件で、例えば compactor に新たなデータ圧縮アルゴリズムを組み込みたいって思ったらどうなるのか？まずThanosプロジェクトに機能追加の提案を行うところから始めるのだ。
その真意をMarco Pracucci氏は次のように説明している。
Collaborating and sharing are also tough sometimes, and the specter of competition is always around the corner.
共同作業や共有も時には厳しく、常に競争の脅威にさらされています。
Reaching a consensus takes a long time, and you have to convince a wider group of people. The two projects also have some differences in strategy, so any changes we propose to Thanos must make sense for both projects, without bringing any significant downside in terms of performance or maintenance burden.
コンセンサスを得るには長い時間がかかりますし、より多くの人々を納得させなければなりません。2つのプロジェクトには戦略の違いもありますので、Thanosに提案する変更は、パフォーマンスやメンテナンスの負担の面で大きなマイナスをもたらすことなく、両方のプロジェクトにとって理にかなったものでなければなりません。
Moreover, some changes end up being a two-step process: You first submit changes into Thanos, and then, once they’re merged, you backport these changes into Cortex. Not to mention any contribution to Prometheus, where the chain is one step longer. And you know that Grafana Loki depends on Cortex? The chain for them is even longer, and yes, I feel their pain sometimes.
さらに、一部の変更は2段階のプロセスになっています。最初にThanosに変更点を提出し、それをマージした後、Cortexにバックポートするのです。プロメテウスへのContributionは例えどんなものであっても言うまでもなく、この連鎖を一段階長くします。Grafana LokiもCortexに依存してるいることをご存じですか？この連鎖はさらにさらに長くなり...ええ、そのことが時々苦痛になります。
It is very tempting to pick the shortest path. Maybe you get things done without upstreaming your improvements or fixes. Maybe you will just postpone them (and we all know that once you postpone something you will never do it). Or maybe you take the extreme approach of forking an entire package to move faster.
最短の道を選びたくなります。おそらく、あなたは改善したり修正した内容をupstreamに流さなくてもやり遂げられるでしょう。もしかしたら、先延ばしにしてしまうかもしれません (そして、一度先延ばしにしてしまうと絶対にやらなくなることは誰もが知っています)。あるいは、より速く動かすためにパッケージ全体をforkするという極端なアプローチを取るかもしれません。
But we’re not collaborating for the sake of collaborating. We are collaborating and sharing because we care for each other, and we believe that what each project gets back is greater than the sum of our individual contributions.
しかし、私たちはコラボレーションという目的のためにコラボレーションをしているわけではありません。私たちが協力し、共有しているのは、お互いを気遣っているからです。それぞれのプロジェクトが得られるものは個々の貢献の総和よりも大きいと信じています。
そして、共有は学習であるとし、成功も失敗も原則もお試しもテクニックも全てをコラボレーション相手と共有することがより大きな学びであると彼はつづける。
その成果がCortexにおけるObject Storage Storeの実装とThanos由来の三つのコンポーネント ingester 、 store-gateway、 compactor であることは先に述べたとおりだ。
CortexとThanosは協力し合い、この一年間で数えきれないほどの成果を生み出すことに成功する。
:::messages
Cortex側の目線ばっかり説明したが、もちろんThanos側もCortexからたくさんのものを受け取っている。詳しくはThanosプロジェクトでCortexのIssueを探してみるといいだろう。
:::
両プロジェクトのコラボレーションのきっかけとなった#1695で対応方針が決まった後にMarco Pracucci氏は次のようなツイートを残している。
半年後、CortexのメンテナーでありGrafana Labsの社員でもあるMarco Pracucci氏はThanosのプロジェクトのメンテナーに加わることになる[24]。
あのPRが競争を超えたコラボレーションの誕生の瞬間なら、これは今後もコラボレーションが続いていくことを約束するものだ。
競争を超えたコラボレーション
オープンソースとはテクノロジーに関するものではない。
オープンソースとはすべてはひとのためにある。
オープンソースとはコラボレーションであり、還すものだ。[25]
PromCon Online 2020 - Sharing is Caring: Leveraging Open Source to Improve Cortex & Thanosの冒頭と最後でMarcoとBartłomiejによって繰り返し述べられていたメッセージだ。
コラボレーションの成果は単純に機能だけではない。Prometheus, Cortex, Thanos、全てのミーティングに同じ開発者が集うことで、さらに多くのフィードバックやアイディアを得て、汎用的な問題を話し合い、意見を交換した。垣根を越えてコミュニティやダイバーシティなどたくさんのものを学びあったのだ。
オープンソースとはひとのためにある。開発者が集うことで、協力し、限界を押し上げたのだ。それは車輪の再発明という孤独の道では決して得られない成果だった。再利用は容易ではないが、最終的にはかけがえのないものになるのだ。
Bartlomiej Plotka氏は、力強く断言した。
"One does not change a winning team"
競争を超えたコラボレーションは今後も続いていくだろう。
所感
Open source is collaboration and giving back.
ええ言葉や。繰り返し胸の内に返したい。
この事例はオープンイノベーションという最近の時勢にあってオープンソースの可能性をまた一つ信じるに足りる事例だと思う。ぶっちゃけ、人が仲良さそうにしているのを見るのはいいものだ。
Upstreamというのが、お互いを尊重するための手段だという考えは非常に胸を打たれた。もしもバグに直面したら、Agilityを考えたらフォークした上でちゃっちゃと独自に修正するショートカットの道を選びそうなものだけど、あえてそうしないことがコラボレーションの相手に対する考えられる限り最高の敬意の表し方なわけだ。そういうきめ細やかな配慮が、CortexとThanosの両プロジェクトのメンテナーにGrafana LabsにMarco Pracucci氏が加わるという強い結束を生んだ。このあたり、凄く共感したし、言葉にならないエモい感情があふれるセッションだった。オープンソースとは人が全てなのだというのが非常に伝わる内容だった。
蛇足その1-ビジネスモデルとしてみた場合
ただし、プロプライエタリソフトウェアならまず考えられないだろうけど、オープンソースが万能薬だと盲目的に信じられる話でもない。なぜなら機能面で見れば一緒でも、ビジネスモデルで見れば両者の思惑が違うからだ。
CoretexはGrafana Labsを中心として開発されており、Enterprisedなサポートチケットを対企業向けに発行することで、収入を得ている。事業モデルとしてはRed HatのRHELに近いだろう。
一方でThanosは、Improbableが自社のゲームプラットフォームの監視ツールとして使用するために開発された。現在は、既にImprobable社出身のメンテナは誰もおらず、完全に手を離れている。代わりにCNCFメンバの複数企業からなるエンジニアによって開発が続けられている。つまり、過去も今もThanosがImprobableの収益の中心にはいなかった。多くのManagedなCloud Serviceの裏側を支えているのもそんなしがらみの無さだろう。
両者にはそんな健全なすれ違いが存在する。
それでもなお、このコラボレーションはオープンソースの持つ無数の可能性の一つであり、エンジニアが世俗に流されることなく、協調できる成果だと信じたい。
蛇足その2-CortexとThanosの行く先は？
先ほどのPromCon2020のセッションでも、OpenTelemetryのようにプロジェクトが一緒になるのか?という質問があった。結論としてはNoであり、しかしコラボレーションの在り方は変わらないとの説明であった。
https://signoz.io/blog/opentelemetry-kubernetes/ より抜粋した系譜
質問で例として話の俎上に上がったOpenTelemetryはCNCF管轄のOpenTracingとOpenCensusが融合して誕生した分散トレーシングのプロダクトだ。
来歴を見ればわかるが、両者は全然違うところから誕生したプロダクトで、それにもかかわらず、分散トレーシングという要件を満たすためのコンセプト Context Propagation とそれを実現するための技術要素——リクエストごとにヘッダーにCorrelation IDを含めることで追跡可能にするやり方——は非常に似ていた。だからこそ、用語の擦り合わせ等のささいな壁を乗り越えて、一緒になることができたわけだ。
一方で、CortexとThanosに限っては素直に一緒になるのは構造上、難しい。Prometheusの機能拡張という目的は一緒でもそれを実現するためのアーキテクチャデザインが異なるからだ。CortexはPush型のアーキテクチャを採用しており、ThanosはPull型のアーキテクチャを採用していることは先に述べたとおりである。
そのように考えると、コラボレーションにおいて最終的に一緒になることを期待しなくてもいいのではないのかなと思う。Marco Pracucci氏がCortexとThanos両方のメンテナーを務めているように、人材を通した両プロジェクトの交流、そして技術要素の解決において両者が被るところがあれば共同して解決していく今の姿を尊重すべきだろう。
蛇足その3-人が集まることはそれだけで資産になる
最近、Saskia Sassen氏による世界都市論に関する議論を、放送大学の西澤氏経由で知った。
インターネットが十分に普及して地理的制約が取り外された現在でも、東京圏のような都心部への人の流入は止まず、依然として人を集めているのはなぜか？
この問いかけへの答えとして、世界都市論に基づく説明では、都市の社会的構造的要因が大きいと指摘する。知的財産や情報の集積を糧とする金融や工事ビジネス・サービスを行う企業とその企業で働いている人たちが中心にいることで経済圏が成り立っているために、人が集まれば集まるほど利益は増大し、都市圏は成長するのだという。
『コロナ禍の状況下で、タバコの喫煙所のような対面チャンネルが失われたことでアイディアが生まれづらくなっている。代わりとなるコミュニケーションツールが必要だ。』
Twitterでこんな議論が繰り返し行われてきた一年であったと思うけど、結局その地理的制約から完全に逃れられたという話をOSS界隈で寡聞にして耳にすることは少ない。Remote Culture を標榜するHashiCorpやGitLabのような企業は例外的存在だ。
プロジェクトに参加する人が多ければそれだけで情報資産を生む。それはプロジェクトに限らず、例えば勉強会も同じことだ。技術レベルに関わらず、集合知が新たな発見を呼び、勉強をする機会となる。@tzkoba さんの Database Internalsの勉強会に時折参加することで、Databaseのコミッターの方たちが白熱して圏外に行ってしまうのを目にして思い知らされた。そして人を集める単純な手立ては、居住地といった地理的な共通点を作り出すことなのだ。
翻って、CortexとThanosはUKと特に関係が深いようだ。Improbable社はUKの企業で、Bartlomiej Plotka氏もUK出身。Cortexの主メンバもGrafana LabsのTom Wilkies氏、WeaveworksのBryan Boreham氏等、UK出身だ。つまり、プロジェクトがコラボレーションとしての発芽に至ったのはUK閥ともいえる関係が大きいと思う。(あ、CortexとThanosの両プロジェクトのメンテナーであり、懸け橋の象徴ともいえるMarco Pracucci氏はItaly在住です。多分。後、ThanosがOpenshift Observability Platform Teamの中核を担うようになってからドイツ・ベルリン勢も多い。)
Improbable社は最近JetStack社(CertManagerで有名なコンサルティング会社)とコラボして、etcd-operator を再開発していたが、これもまた同じUKの会社同士の取り組みから生まれたプロジェクトだ[26]。
クラウドネイティブといえばUSの西海岸を想像しがちな中、この発見は地味に興味深かった。UKでITと言えば、自分はBlack Mirrorしか浮かばないので、是非詳しい方にこの辺りのスタートアップ事情を紹介してほしい。
英語を日本語みたいに扱えるようになりたい。
参考文献
- https://www.cncf.io/blog/2020/08/19/toc-approves-thanos-from-sandbox-to-incubation/
- https://www.cncf.io/blog/2018/09/20/cncf-to-host-cortex-in-the-sandbox/
-
実際、CNCFに登録されたOSSプロダクトは最初がKubernetes、その次がPrometheusだったと概要に記載がある ↩︎
-
情報システムを開発・改修する際に、機材の台数や処理性能、記憶容量、回線容量などの計画を立てること ref: http://e-words.jp/w/キャパシティ.html#Section_%25E3%2582%25AD%25E3%2583%25A3%25E3%2583%2591%25E3%2582%25B7%25E3%2583%2586%25E3%2582%25A3%25E3%2583%2597%25E3%2583%25A9%25E3%2583%25B3%25E3%2583%258B%25E3%2583%25B3%25E3%2582%25B0 ↩︎
-
CNCFが支援するプロジェクトとしてメンテナーが複数企業から参画していることは欠かせない条件だ。過去にはこれを理由としてCNCFへのjoinを一度蹴られたOSSプロジェクトも存在する。Keycloa... ↩︎
-
Improbableは、オンラインゲームのクラウドプラットフォームであるSpatialOSの開発元で知られる会社。自社サービスの開発の過程でPrometheusを拡張させるOSSであるThanosを開発し、公開したが、現在ではOpenShiftなど、Packaged Kubernetesにも採用されるまでに成長した。今年巨人をぶち抜いたあの会社も出資しているが、最近本業の業績が... ↩︎
-
https://github.com/prometheus/prometheus/tree/v2.18.1/tsdb のリンク先参照 ↩︎
-
現在はGoogle Researchにいらっしゃるようなんだけど、Prometheusを含めたOSS活動から完全にリタイアしているみたい。彼が何をしていらっしゃるのか消息をご存知の方はいらっしゃいませんか？ ↩︎
-
この辺をテーマにして会社のテックブログを書いたけど全く読まれていないのでリンクだけでも踏んでください。 https://natic.nissho-ele.co.jp/insight/techreport-openshift/ ↩︎
-
シェイクスピアのロミオとジュリエットの有名なプロローグである。この後、
From ancient grudge break to new mutiny, Where civil blood makes civil hands unclean.と続く。もちろん、両プロジェクトは今も昔も仲良しだ ↩︎ -
もちろん、Prometheusを経由せずに監視対象のサービスから直接Cortexに情報を受け渡すこともできる。例えばAWSのインターン生!?が開発したOpenTelemetry-GoSDK Cortex Exporterを使うと、分散トレーシングツールのOpenTelemetryから直接Cortexにメトリクス情報をExportできる。 ↩︎
-
関連記事: https://grafana.com/blog/2020/03/25/how-were-using-gossip-to-improve-cortex-and-loki-availability/ ↩︎
-
この圧縮手法としてshuffle sharding等の技法がとられているとのこと。気になった人はhttps://www.youtube.com/watch?v=Z5OJzRogAS4 の動画を見てください。凄く細かい技術粒度のガチエンジニア向けの説明で非常に参考になる。 ↩︎
-
Open source is not about technology. Open source is all about people. Open source is collaboration and giving back. ↩︎
Discussion