Observability Conference Tokyo 2025 では 世界のオブザーバビリティコミュニティの第一人者でもある Liz Fong-Jonesさん（以降 Liz）をキーノートスピーカーとしてお迎えします。そこで Liz さんについて深掘りするために事前インタビューをしました！
- Liz Fong-Jones: キーノートスピーカー、 現在は Honeycomb の Field CTO を務めていて、世界中でオブザーバビリティに関するコミュニティ活動を行なっている。
- Kenta Yokota (tomkenta): 当カンファレンスのキーノート担当、 普段は決済サービスにてSRE的なことを行なっている。
- Kazunori Otani (katzchang): 当カンファレンスのオーガナイザーの1人。Liz が共著者の Observability Engineering の 日本語訳版 の翻訳者の1人でもある。
Google でのキャリアについて - SREからDeveloper Advocateへ
katzchang: 最初にあなたを知ったのは、SREトピックのトレーニング動画でした。そのとき、あなたはGoogleではSREの役割だったのでしょうか？
Liz: その頃は、Yoshi Yamaguchi (@ymotongpoo) さんと一緒にGoogle CloudのDeveloper Relations チームで同僚として働いていました。その前はGoogle Cloud Bigtable のSREチームのマネージャーをしていました。Bigtableは大規模なプロダクションサービスで、NoSQLのデータストレージとクエリを提供しています。 SREのメンバー比率についてよく話しますが、通常は開発者5〜10人に対してSREが1人というイメージですよね。しかし私のチームではSREと開発の区別があまりありませんでした。Bigtableの開発者が20人、SREが20人という構成で、コアのインフラサービスを運用することに非常にフォーカスした一つのチームでした。
katzchang: BigtableのSREチームは通常よりずっと大きいですね。
Liz: その通りです。通常よりもずっと大きなチームです。私はニューヨークのBigtable SREの半分を管理していました。ニューヨーク、マウンテンビュー、ダブリンの開発者とSREなど、大きな組織の一部でした。役割をDeveloper Adovocateに切り替えたきっかけは、Googleでのさまざまなチームの経験から得た知見を、USENIXのSREconで発表したことです。その後、SREconで何度も発表し、プログラム委員長も何度か務めました。自分のチームやBigtable全体の40人のチームをできる限り良くすることで業界に影響を与えられると感じましたが、さらに業界全体を底上げしたいと思いました。当時の業界ではSREとは何か、どう実践するか、良いSREとは何か、といった混乱がありました。そこでGoogle Cloudの顧客と働くCRE(カスタマーリライアビリティエンジニア)やデベロッパーアドボケイトの役割に移ったのは、影響をより広げられるからです。もともとカンファレンスでの発表や人と話すのが好きでしたし、やってみようと思いました。
katzchang: そうしてSREチームからDeveloper Relationsチームへ移ったのですね。そうしてトレーニング動画にも出演したのですね。
Liz: おそらくSREとDevOpsの違いについての動画ですね。
tomkenta: 興味深いです。私もオペレーションチームを約20人ほど管理しています。今ではシステム同士が内部サービスだけでなく外部サービスとも接続されています。私のチームはSREを実践していますが、他のチームはそうではないため、うまく調和しません。自チーム内だけでなく他チームへも影響を与えていくという観点は非常に示唆に富んでいます
Google SREチームでの課題とCREについて
katzchang: BigtableチームでのSREの働き方について教えてください。Google Cloudのプロダクトは非常に複雑で多くのサーバーがあります。どのデータセンターやどのサーバーで動いているかは分からず、私たちは結果だけを見ます。時々うまく動かないことがあります。GoogleのCloudプロダクトのSREチームでは、どんな課題や問題がありますか。
Liz: Bigtableチームで最も興味深かったのは、業界で「マルチシングルテナント」と呼ばれる種類の問題を担当していたことです。規制や顧客のワークロード分離の理由から、異なるクライアントのワークロードを混在させることはできませんでした。最大の課題は、リソース計画を私たちが完全には制御できないことでした。顧客が送るトラフィック量や、プロビジョニングするサーバー数を顧客側が決めるのです。Bigtableはサーバーレスではありません。事前に必要なキャパシティを指定する必要があります。
katzchang: 顧客がキャパシティを事前にリザーブしてからクエリを流したりデータを投げるのですね。
Liz: その通りです。ではサービスが正しく動いているかどうかをどう判断するのか、という課題が生まれます。原因は私たち側のビルドのパフォーマンス問題で、あなたに悪影響を与えているのかもしれない。それは私たちの問題です。一方で、顧客があるBigtableのパーティションに設計の2〜3倍のトラフィックを叩き込んでいるなら、それはあなたのリソース計画の問題です。これはクラウドサービス特有の問題です。顧客にキャパシティを提供するが、どれだけ支払うかは顧客が選ぶ。私たちはサービスを動かし続け、キャパシティ不足のときはそれを顧客に伝えなければなりません。
katzchang: オブザーバビリティの観点では、GoogleのSREチームがプロダクトの運用を監視・観察し、顧客も何が起きているかを理解する必要がありますね。
Liz: その通りです。そこでCRE(カスタマーリライアビリティエンジニアリング)というチームを作りました。Google Cloudでは膨大なトラフィックを送ってくるとても大きな顧客が多いので二つのことが起きました。
- NDAのもとで内部の仕組みの詳細を共有したほうが双方にとって安全だと感じること
- 最大限にBigtableを活用するため顧客が我々の実装を理解する必要があり、それが十分にできるほどでであったこと
そうしてCREのチームはクエリオプティマイザの動作や、メモリとCPUの比率をどう考えるべきかなど、より良いインサイトを顧客に提供しました。このようにCREはBigtableに限らず顧客が使うすべてのサービスについて、その顧客のインターフェースとして機能し、サービスチームと話をし、顧客のビジネス要件と基盤サービスの仕組みを理解した上で、一緒に問題を解決します。「Google VS 顧客」ではなく、顧客チームの一員として働きます。
katzchang: 古典的な技術サポートでは、顧客が「動かない」と言い、サポートは「こちらは問題ありません」と答えるだけで、協調していません。顧客も何が起きているか分からず、誰の責任か分からない。
Liz: その通りです。だからこそ、推測させるのではなく、仕組みを伝えて理解してもらうことが重要です。単にレスポンスを返すだけでなく、顧客やユーザーは何が起きているか、どう動いているかを知る必要があります。それに加えて、私たちがシステムをどう運用しているかも理解してもらう必要があります。サービスレベル目標が何で、私たち自身のサービスをどうSLOで運用しているか、そして顧客が自分のサービスのSLOを私たちのSLOにどうネストさせるかを理解してもらうためです。99.9（スリーナイン） のサービスの上に99.99 (フォーナイン）のサービスを載せようとする、といった誤解を避けるためです。
Google での経験からオブザーバビリティへ
katzchang: Googleには多くのオブザーバビリティのプラクティスがありますよね。
Liz: さまざまなプラクティスがありました。11年間で8〜9つのチームを経験しましたが、基本的にはどのチームもそのトラフィック量のためメトリクス中心でした。ログは数時間から1〜2日で消えてしまい、中央集約なインデックスはありませんでした。ログが必要なら個々のタスクから取得する必要がありました。
そして、BigtableのSREやSREマネージャーをしていた頃にオブザーバビリティに非常に関心を持ちました。 顧客のキャパシティプラニングの問題だけならアラートしないが、キャパシティの範囲内で問題が起きたときだけトリガーするアラートの設計と、 そしてそのアラートが鳴った時のデバッグ時間をどう短縮するかを追求していました。しかし、チームは苦戦していました。なぜならチームはいろんな成熟レベルのメンバーがいるからです。シニアは何か問題を見たらすぐに「あーこれね、前どうやって動いて対応したか覚えているよ」とすぐに当たりを付けられますが、経験のない新卒が6ヶ月でこのシステムのオンコールに入って同じことを期待できるでしょうか？。当時のアプローチは全てのダッシュボードと全てのメトリクスを準備して新卒でも一体どんな問題がいつから起きているのかを分かるようにすることでした。
katzchang: Wikiページにすべて書かれていて、優れたダッシュボードもある。問題が見つかったらWikiを見てトラブルシュートする。これはSREチームのよくある環境ですね。
Liz: Google Cloud や Google 監視チームが作った新しいツールをどう活用すれば新しい開発者がオンコールに参加しやすくなるのか？ Googleの監視におけるベストプラクティスについて、私たちが抱える非常に興味深い規模や課題を踏まえたうえで、何が一般化されて業界の他の人たちに役立てるのか？ これらの問いが私がオブザーバビリティを探求する一歩となりました。
オブザーバビリティをどう評価するか
tomkenta: 私は日本のある決済サービス企業のオペレーションチームでSRE的なことをしています。非常に大量なトラフィックがあります。競合他社に負けないように速く多くの変更をデリバリーする必要があります。アラートはしきい値などがありますが、サービスの成長とともに陳腐化して、従来のアラート設定だけでは問題に対応できません。オブザーバビリティが十分であるかどうかをどのように評価し、より良くするのかを詳しく教えて欲しいです。
Liz: オブザーバビリティは本質的に投資です。
tomkenta: 投資ですか？
Liz: 投資つまり費用対効果が大事です。十分なオブザーバビリティがあっても、コストが高すぎる場合があります。逆に、もっとお金を使えば、すぐにより良いオブザーバビリティが得られる場合もあります。つまりオブザーバビリティは費用対効果で評価する必要があります。多くの場合、ダッシュボードだけを見ていても、インシデント解決時間や状況把握に数時間かかるのなら、既存のツールがサービスの複雑性に追いついていない兆候です。とはいえ、私としては言いにくいですが、誰もが高度なオブザーバビリティを持つべきだとは言いません。もしいわゆるLAMPスタックを運用して半年に1回だけ更新して後は放置されるならば、高度なオブザーバビリティは不要でしょう。私は3つの観点がオブザーバビリティの投資の妥当性に影響すると考えています。
- コードベースに何人の人がコードを貢献しているか
- どれだけのトラフィックを受けているか
- 同時にいくつの変更をプッシュするか
コードベースに貢献する人が増えるほど、問題を調査する人が自分でその変更を書いていない可能性が高くなります。トラフィック量やユニークユーザー数は、遭遇しうる挙動の種類の多さに相関します。そして変更数は、障害が起きた時の影響範囲をどう限定するかという話に行き着きます。つまり同時に変更が多いほど、その障害の影響が把握できるまで全てを停止すると言うことが難しくなります。
katzchang: 日本の巨大組織では、エラーが発生すると全トランザクションが停止するようなことも起こります。
Liz: そうです。そしてトレーシングの話になります。2014年から2017年にかけて、業界内でトレーシングの導入を試みては実装に失敗することが波のようにありました。Googleの中でさえ、私のチームは数少ないトレーシングの導入ができた成功チームの一つでした。なぜなら当時のトレーシングは、全体を上から下まで完全にトレースするための巨大な投資が必要でした。単一のモノリスなら、フックや情報を全体に組み込めたかもしれません。しかし、マイクロサービスを追加した瞬間に、そのサービスは、ばらばらになります。
ここに私がGoogleからHoneycombに働き先を切り替えた理由があります。それはいくらSLOについて伝道をしても、人々がSLOを使ってデバッグできる能力、つまり「あるSLOアラートがなったときに、何が起きたかを突き止める」ことができなければ、SLOは使われないと気づいたからです。単にノイズのように「何かが悪い」と言うだけでは、どうやって、なぜ悪いのかを突き止められない。人々はそのSLOアラートを使わなくなります。だから、SLOの採用とSLOを使ってデバッグするメカニズムは一体になって導入される必要がありました。SREcon Europe 2018だったと思いますが、Bigtableチームがトレースを例に使ってどうデバッグするかという話をしました。なぜなら、トレーシングとメトリクスがうまく共存でき、95パーセンタイルの閾値から見つけたスロークエリーの1サンプルにジャンプして調べるという優れたワークフローを示したかったのです。
katzchang: SREまたは開発チームの状況には2フェーズあります。第1フェーズは、メトリクスとログしかなく、それらだけで本番で何が起きているかを調べないといけない。日本の多くの会社はまだこの段階です。第2フェーズは、一部の日本企業は様々なAPMツールを使い、必要なお金を払って効果的なオブザーバビリティを達成しようとしています。この投資対効果があるオブザーバビリティについてキーノートセッションではその話をする予定ですよね。
Liz: はい、そうです。だから、あなたが私に話してほしいテーマとしてそれを選んでくれてうれしいです。今の日本市場に合っていると思います。
Observability Conference Tokyo 2025 に期待すること
tomkenta: Observability Conference Tokyo 2025に何を期待していますか？では、日本のコミュニティに対して、特に伝えたいことはありますか？
Liz: 先ほど話したように、多くの日本企業が主にメトリクスとログに頼っているというのはわかります。ただ、それが普遍的に真実だとは思いません。日本にもトレースファーストのアプローチで成功している日本企業がいくつもあります。つまり、ログやメトリクスが日本市場に特別に適しているというわけではありません。分散トレーシングなど、よりモダンなオブザーバビリティをうまく活用している例があります。私は、日本の皆さんがどのようにオブザーバビリティを実践しているのかを聞き、どう改善できるかを手助けしたいです。何が響いて何が響かないストーリーなのかを知りたいですね。
tomkenta: なぜ彼らは日本企業でオブザーバビリティをうまく活用できているのでしょうか。私の感覚では、彼らは新しく、社長がテック出身だと思います。それが大きな違いを生んでいるのでは。どう思いますか。
Liz: その通りです。過去の欧米市場でも同様に、モダンなオブザーバビリティを早く採用するのは、テック指向の企業です。テクノロジーをコストセンターではなくプロフィットセンターとして見ています。その考え方が浸透すると、オブザーバビリティを最低限のコストとして扱うのではなく、投資として考えるようになります。日本市場でも同じことが起きていくでしょう。スタートアップ的なマインドを持つ企業、あるいはテックに前向きな企業が新しいことを先に試します。それでいいのです。人材の移動やObservability Conference Tokyo 2025 のようなカンファレンスでのベストプラクティスの共有と交流を通じて、「これはスタートアップだけでなく大企業でも機能する」と気づくようになります。特に、問題が起こるとリスクが大きい企業では尚更です。
katzchang: 私もオブザーバビリティ業界で働いていますが、日本市場にはチャンスがたくさんあると見ています。多くのエンタープライズがモダンなオブザーバビリティプラクティスを持っておらず、マネージドされたSREの役割もありません。チャンスは大きいです。今回の参加者は、インターネットサービス企業、ストリーミングサービス企業、銀行や大企業、システムインテグレーターなど、さまざまな方面から来る予定です。何が起きるのか、とても楽しみにしています。
Liz: 私もです。講演がどう受け止められるか、そして皆さんと話せるのが楽しみです。
最後にメッセージ
Liz: 最後に伝えたいことは、あなた方が私から学ぶために呼んでくれたのはわかっていますが、私も皆さんから学ぶために来ています。これは双方向の関係です。私は日本の皆さんから学べることにとてもわくわくしています。日本の皆さんと話し、何が関係するのか、日本のプラクティスがどうなっているのかを理解したい。そしてそこから、オブザーバビリティの改善に向けて、より良いガイダンスをどう作るかを考えたいです。
編集後記
引き続き、Observability Conference Tokyo 2025ではチケット好評販売中です。
今回のLizのインタビューの内容に少しでも興味を持った方はぜひ下のバナーのリンクから参加登録お願い致します!
