創業者と語るGrafana 12：デザイン、スケール、そして次なる章へ
エンジニアリングにおける最も興味深いストーリーは、必ずしもロードマップやリリース計画から始まるわけではありません。それは個人の嗜好、優れたデザインへのこだわり、使いにくいツールへの不満、あるいは「すべてを一箇所で見たい」という切実な願いから始まります。
ポッドキャスト「Grafana’s Big Tent」の今回のエピソードでは、Grafana LabsのプリンシパルソフトウェアエンジニアであるMat RyerとCTOのTom Wilkieが、Grafanaの創設者であるTorkel ÖdegaardとディスティングイッシュドエンジニアのRyan McKinleyを迎え、幅広い対談を行いました。 内容はGrafanaの原点から、12回のメジャーリリースを経た進化、そしてGrafana 12を支えるアーキテクチャの基盤にまで及びます。
対談では、なぜGrafanaのUIが初日から重要だったのか、プラットフォームがいかにして従来のオブザーバビリティの枠を超えて拡張したのか、12年続くオープンソースのコードベースを維持する苦労、そして「スキーマファーストAPI」「Dashboards-as-code」「ダイナミックレイアウト」といった新機能がいかに次の10年に向けた備えとなっているかについて語られています。
エピソードの全編は以下のYouTube、またはSpotifyやApple Podcastsで視聴いただけます。
（注：以下はポッドキャスト「Grafana’s Big Tent」シーズン3・エピソード5のハイライトです。本書き起こしは、読みやすさを考慮して編集されています。）
背景：Grafanaの始まりと、当初の目的
Torkel Ödegaard: 始まりはアプリケーションレベルのメトリクスでした。 自分が構築していたマイクロサービスの状態、例えばパフォーマンスやキュー、メッセージの処理状況やキューの滞留数といったシンプルな情報を把握したかったのです。しかし、すぐにビジネスレベルのメトリクスにも使い始めました。
私が本当に魅了されたのは「相関関係」を見られることでした。当時はオークションサイトを手掛けていたので、ユーザーの入札数やその金額、ログイン人数を確認し、それらをシステムのパフォーマンスと関連付けて見られるようにしました。サイトに変更を加えた際、コードの変更やパフォーマンスの変化、あるいは障害がビジネスにどのようなリアルタイムの影響を与えるかを可視化できるようになったのです。
なぜデザインが重要だったのか、そして「クールな見た目」が偶然ではなかった理由
Torkel: 面白いことに、最も普及の決め手となったのは、使いやすさと「見た目の格好良さ」だったと思います。当時の他のオブザーバビリティツールは、操作性のない小さな画像ベースのグラフが主流で、設定に時間がかかる上に制約も多かったのです。誰でも比較的簡単に作成でき、かつテレビ画面に映したくなるような美しい「カラフルなダッシュボード」を実現したこと。これこそが、社内のどのチームも、他のチームのダッシュボードを通りすがりに見て「お、俺たちもこれが欲しい！」となるきっかけを作りました。見た目がクールで、自分たちでも簡単にできると思わせたことが大きかったですね。
12回のリリースを経て：大規模スケールでのGrafanaの維持
Torkel: Grafanaを始める前、私が一つの会社やプロジェクトに携わった最長期間はせいぜい2年半ほどでした。ですから、12年後も同じものに取り組んでいるとは、当時は夢にも思っていませんでした。
Mat Ryer: これほど多くの人に届くソフトウェアを開発するのは、とてもやりがいがあることでしょう？業界でこれほど広く使われているソフトウェアに携わる機会は、そうそうありません。
Torkel: そうですね。最新の数字では、アクティブユーザーの数え方にもよりますが、2,500万人から5,000万人の間と言われています。とにかく「とてつもない数」であることは実感しています。
Grafanaが成長した「唯一の理由」
Tom Wilkie: コミュニティとの高いエンゲージメントや、ここまでの利用拡大につながった「これだ」という要因を一つ挙げるとしたら何でしょうか？
Ryan McKinley: 私にとっては、見た目が良く、かつ自分のシステムがどうであれ拡張できる点です。システムは時代とともに変わるものです。Grafanaはプラグイン可能なオープンフレームワークとして始まり、当初はGraphiteが中心でしたが、やがてPrometheusの重要性が高まりました。現在は約200種類のデータソースに対応しており、チームは外部データの連携を自在に行い、データがどこにあっても活用できるようになっています。
Git sync、ガバナンス、そして安全なダッシュボードワークフロー
Tom: 12番目のリリースとなるGrafana 12での改善点は何でしょうか？
Ryan: 内部的なものを含め多岐にわたりますが、最も重要な基盤の変化はAPI構造の見直しです。長年議論してきた「Dashboards-as-code」がついに現実味を帯びてきました。私たちは現在、スキーマファーストのアプローチを採用しており、Grafanaで読み書きするすべての要素に対して一貫したAPIを提供しようとしています。その鍵となるのがダッシュボードです。
長年取り組んできたGit syncプロジェクトも、スキーマファーストのアプローチがなかったために足踏みしていましたが、今後はダッシュボードを外部の静的リポジトリ（GitHubなど）で読み書きできるよう構成できます。これにより、独自のバージョン管理やデプロイのガバナンスを効かせることが可能になります。
Tom: この機能には本当に期待しています。多くのユーザーが経験していると思いますが、既存のダッシュボードを壊したくないために「コピー」を100個も作ってしまうような状況が、これで解消されますからね。
今後の展望：次の10年に向けた礎
Tom: 今後の予定について、少しだけ先行情報を教えてもらえますか？あるいは、オープンソースなのだからリポジトリを見ればわかるのでしょうか？
Torkel: すべてオープンソースなのでリポジトリで見られますが、ヒントはすでに出ています。私たちが今やっていることの多くは、これから構築するものへの土台作りです。現在、ダッシュボードAPIの「バージョン1」がありますが、すべてのオブジェクトを共通構造のAPIへ移行する「バージョン2」への取り組みが、今チームが最も注力している大きな仕事です。
Ryan: 私が関心を持っているのは、AIがダッシュボード構築やワークフローにいかにフィットするかという点です。また、Grafanaの見た目（ルック＆フィール）をどう進化させるかも重要です。Grafanaの外観はこの8年ほど大きく変わっていませんが、AIアシスタントの登場により、UIの構造やワークフローの考え方そのものを再考する時期に来ているかもしれません。
もう一つ大きなテーマは、真のマルチテナンシーを実現し、大規模運用をより容易に、かつコンポーザブル（構成可能）にすることです。これはGrafana Cloudの運用において重要ですが、オープンソースユーザーにとっても、さまざまなシナリオでGrafanaを柔軟に組み合わせられるようになるというメリットがあります。
Tom: そうですね。私たちはGrafana Cloudで数万件のGrafanaインスタンスを運用しており、それをよりスケーラブルなマルチテナント・マイクロサービスアーキテクチャへと移行させるのが長期的な目標です。この話だけで、また一エピソード分語れそうですね。
Torkel: ええ、おそらくあと数回は必要でしょう。
ポッドキャスト「Grafana’s Big Tent」では皆様からの声をお待ちしています。共有したいストーリーやフィードバックがありましたら、bigtent@grafana.com までご連絡ください。