ハニカムのCTO兼共同創設者、チャリティー・メイジャーズ – インタビュー・シリーズ

チャリティーは、ハニカムのオペレーションエンジニアであり、偶然のスタートアップ創業者です。以前は、Parse、Facebook (META ) 、Linden Labでインフラストラクチャーと開発者ツールに従事し、常にデータベースを管理する役割に就いていました。她は、O’ReillyのDatabase Reliability Engineeringの共著者であり、自由な言論、自由なソフトウェア、シングルモルトウイスキーが好きです。

あなたはFacebook（現Meta）のプロダクションエンジニアリングマネージャーを2年以上務めました。その期間の中で、どのようなハイライトがありましたか？また、この経験から得た主な教訓は何ですか？

私は、モバイルアプリのバックエンドであるParseに取り組みました。Herokuのモバイル版のようなものでした。私は大きな会社で働くことに興味がなかったのですが、Facebookに買収されました。私が得た主な教訓の1つは、買収は非常に難しいものであるということです。私が他の創業者にいつもアドバイスするのは、買収される場合は、エグゼクティブスポンサーがいて、戦略的整合性があるかどうかを慎重に検討することです。Facebookは、Instagramを買収する少し前にParseを買収しました。Instagramの買収は、全く楽しいものではありませんでしたが、最終的には成功しました。なぜなら、戦略的整合性があり、強力なスポンサーがいたからです。

私はFacebookでの仕事が簡単ではなかったですが、そこで過ごした時間は非常に感謝しています。私は、組織構造、管理、戦略などについて学んだ教訓なしに会社を創業できなかっただろうと思います。また、VCから注目されるペディグリーを得たこともあります。私はこれについて少しイライラしていますが、受け入れるしかありません。

ハニカムを立ち上げる背後にある創業ストーリーを共有してください。

もちろん。アーキテクチャーの観点から見ると、Parseは先駆者的でした。マイクロサービスを使用していました。データレイヤーは大量にシャーディングされていました。プラットフォームとして、100万以上のモバイルアプリを提供していたので、非常に複雑なマルチテナント問題がありました。私たちの顧客は開発者でした。彼らは常に任意のコードスニペットや新しいクエリを書き込んでアップロードしていました。私たちはそれらすべてを受け入れて、うまく機能させる必要がありました。

私たちは、現在主流となっている多くの変更の先駆者でした。以前は、ほとんどのアーキテクチャーは比較的簡単で、予測可能な方法で繰り返し失敗していました。Webレイヤー、アプリケーション、データベースがあり、ほとんどの複雑さはアプリケーションコードにありました。したがって、失敗を監視するためにモニタリングチェックを書き、メトリクスとモニタリングデータの静的なダッシュボードを作成していました。

この業界は、過去10年でアーキテクチャーの複雑さの爆発的な増加を見ています。モノリシックな構造を破壊したので、現在は数百から数千のマイクロサービスがあります。ポリグロット永続性が一般的です。データベースが1つではなく、多くの異なるストレージタイプがあり、水平シャーディング、キャッシングの層、サービスごとのデータベース、キューイングなどがあります。また、サーバーレスコード、ブロックストレージなどがあります。

以前、コードのデバッグが難しかったのですが、現在は、システム内でコードをデバッグする必要がある場所を見つけるのが難しいのです。以前は、繰り返し予測可能な方法で失敗していましたが、現在は、ページングされるたびに、新しいものを見ることが多いです。

Parseでの状況は、毎日プラットフォームがダウンし、毎回異なる新しいものでした。別のアプリがiTunesのトップ10に達したり、別の開発者が悪いクエリをアップロードしたりしていました。

これらの問題を最初からデバッグするのは非常に難しいです。ログとメトリクスでは、探しているものが何であるかを知っている必要があります。しかし、ScubaというFacebookのツールに一部のデータセットを入力し始め、任意の次元と高次元データをリアルタイムでスライスしてダイスできるようになると、問題を特定して解決するのにかかる時間が、時間から分、秒にまで短縮されました。もはやエンジニアリングの問題ではなくなり、サポートの問題になりました。毎回、答えにたどり着くためのパンくずの跡をたどるだけでした。

それは驚くべきことでした。不確実性と労力と不幸な顧客と2時のページングの巨大な源が、ただ消えました。Facebookを離れた後で初めて、私たちがソフトウェアとやり取りする方法をどれほど変えたかがわかりました。古いモニタリングチェックとダッシュボードの悪い古い日々に戻るという考えは、考えられませんでした。

しかし、当時は、本当にこの解決策がニッチなものであると思っていました。巨大なマルチテナントプラットフォームが抱える問題を解決するものだと思っていました。開発をほぼ1年間行った後で初めて、実はこれは誰でも抱える問題になっているのだと気づきました。

観測可能性プラットフォームとは、伝統的なモニタリングとメトリクスとはどう違うのでしょうか？

伝統的なモニタリングは、3つの柱で有名です。メトリクス、ログ、トレースです。各ツールは、異なるユースケースに最適化されており、異なる形式で提供されます。エンジニアとしては、これらすべてをまとめて理解する必要があります。ダッシュボードを眺めてパターンを探し、ログとトレースの間でIDをコピーして貼り付けます。非常に反応的で、断片的です。通常、問題が発生したときにこれらのツールを参照します。コードを操作し、バグやエラーを見つけるのに役立ちます。

現代の観測可能性は、単一の真実源を持ちます。任意に広い構造化ログイベントから、メトリクス、ダッシュボード、ログを導き出すことができます。時間の経過をトレースとして視覚化できます。接続されているため、ツールを切り替える必要はありません。モニタリングツールは、システムを操作することだけではなく、コードを開発することにも役立ちます。コードを迅速に、自信を持って、価値をユーザーに提供することができるフィードバックループを接続する基盤となります。

あなたは、観測可能性がエンジニアリング環境で単一の真実源を提供することを信じています。AIは、このビジョンにどのように統合され、どのような利点と課題がありますか？

観測可能性は、高速道路を走る前に眼鏡をかけるようなものです。テスト駆動開発（TDD）は、2000年代初頭にソフトウェアを革命しましたが、TDDは、複雑さがソフトウェアではなくシステムにある場合、効果が低下しています。TDDの利点を得るには、実際にはコードをインストルメント化し、観測可能性駆動開発（ODD）を実行する必要があります。そこでは、インストルメント化しながら迅速に展開し、インストルメント化したコードを生産環境で観測し、コードが期待通りに動作しているか、他に何かおかしいことがないかを確認します。

テストだけでは、コードが期待通りに動作していることを確認するには十分ではありません。コードが期待通りに動作していることを知るのは、実際のユーザーがいる生産環境でコードを観測したときだけです。

このような開発方法は、テストと遅い展開サイクルに頼るよりも、実際には速く、簡単で、シンプルです。開発者がこの方法で作業した後では、古い方法に戻ることをためらいます。

AIに興奮するのは、LLMを使用して開発する場合、生産環境で開発する必要があるからです。コードを検証するためのテストセットを導き出すには、まずコードを生産環境で検証し、逆方向に作業する必要があります。LLMをバックエンドに持つソフトウェアを書くことは、MySQLやPostgresをバックエンドに持つソフトウェアを書くことと同じくらい一般的なスキルになるだろうと考えています。私の希望は、エンジニアを引きずって、よりよい生活に導くことです。

AI革命により技術負債が増加することを心配しています。AIが導入する技術負債の種類と、ハニカムがこれらの負債を管理または軽減する方法について説明してください。

私は、技術負債と、組織負債について心配しています。最も悪い種類の技術負債は、誰もが理解できないソフトウェアを持つことです。誰かがコードを拡張したり変更したりする必要があるとき、誰かがコードを学習する必要があります。

そして、誰もが理解できないコードを生産環境に投入すると、将来の技術的な問題の大きな氷山を作り出します。良いコードは、読みやすく、理解しやすく、拡張しやすいように書かれます。規約やパターンを使用し、一貫した命名やモジュール化を使用し、DRYと他の考慮事項のバランスをとります。コードの質は、人間がコードとやり取りするやすさと切り離せません。誰もが理解できないコードを投入することを決めた場合、ハニカムはそれを助けることができません。

しかし、クリーンなイテラブルなソフトウェアを投入したい場合、インストルメンテーションと観測可能性は絶対に不可欠です。インストルメンテーションは、ドキュメンテーションとリアルタイムの状態レポートを組み合わせたものです。インストルメンテーションは、ソフトウェアが期待通りに動作していることを確認する唯一の方法です。

ハニカムは、エンジニアリングチームの効率と有効性を向上させるためにAIをどのように利用していますか？

私たちのエンジニアは、内部でAIを多く使用しています。特にCoPilotです。私たちのジュニアエンジニアは、毎日ChatGPTを使用して質問に答えたり、ソフトウェアを理解したりしています。私たちのシニアエンジニアは、コードを生成するために役立つと言っています。特に、巨大なYAMLファイルを埋める必要がある場合や、通常使用しない言語でコードを生成する場合、またはAWS SDKやAPIのドキュメントからコードを生成する場合などです。

ただし、AIがコードを生成するたびに、行ごとにコードを確認して、正しいことをしていることを確認する必要があります。なぜなら、AIは、ガベージを生成することがあるからです。

AIパワードの機能、たとえばクエリアシスタントやSlack統合がチームコラボレーションをどのように強化するかについて、例を示してください。

はい、もちろん。クエリアシスタントは、素晴らしい例です。クエリビルダーを使用するのは複雑で難しいです。テレメトリに数百または数千の次元がある場合、最も価値のある次元の名前をすべて覚えることはできません。パワーユーザーでも、グラフを生成する方法の詳細を忘れることがあります。

したがって、私たちのクエリアシスタントは、自然言語で質問を許可します。たとえば、「最も遅いエンドポイントは何ですか？」または「最後のデプロイの後には何が起こりましたか？」そして、クエリを生成し、それにドロップします。ほとんどの人は、新しいクエリをスクラッチから作成するのが難しいと考えているようですが、既存のクエリを調整するのは簡単です。つまり、既存のクエリを使用して、スタートするための優位性を得ることができます。

ハニカムは、インシデントの解決を迅速化することを約束しています。ログ、メトリクス、トレースを統一されたデータ型に統合することで、デバッグと問題解決を迅速化する方法について説明してください。

すべてが接続されています。推測する必要はありません。ダッシュボードが同じ形をしていることを目視で確認したり、メトリクスのスパイクがログのスパイクと同じであると推測したりする必要はありません。データはすべて接続されており、推測する必要はありません。ただし、データを要求するだけで済みます。

データは、コンテキストによって価値が決まります。前の世代のツールは、書き込み時にすべてのコンテキストを削除することで機能しました。コンテキストを破棄した後は、もう取り戻すことができません。

また、ログとメトリクスでは、探しているものが何であるかを知っている必要があります。現代の観測可能性では、探しているものを知る必要はありません。

この豊富なコンテキストデータを保存することで、魔法のようなことができます。バブルアップというツールがあり、興味深いものや異常なものを囲むバブルを描くことができます。私たちは、バブル内の次元とバブル外の基準、差を計算します。つまり、「このバブルはおかしい」と思うと、私たちはすぐに、「これはX、Y、Zの点で異なっている」と伝えることができます。デバッグの多くは、「これは私が気になることですが、気になる理由は何ですか？」ということです。リクエストがAndroidデバイスから来ていること、特定のビルドIDを使用していること、特定の言語パックを使用していること、特定のリージョンにいること、アプリIDが大きいこと、ペイロードが大きいことなど、すぐにわかります。

これは、統一されたデータだけの問題ではありません。高次元データ、たとえば一意のID、ショッピングカートID、アプリID、名前、姓、などを、非常に簡単に処理します。前の世代のツールは、豊富なデータを処理することができません。これは、信じられないことですが、豊富な高次元データは、すべての最も貴重で特定のデータだからです。

観測可能性の向上は、ビジネス成果にどのように影響しますか？

これは、前の世代と新しい世代の観測可能性ツールの間のもう1つの大きな変化です。以前は、システム、応用、ビジネスデータがすべて別々のツールに分離されていました。これは、馬鹿げています。現代のシステムについて尋ねたいすべての興味深い質問には、すべての3つの要素が含まれます。

観測可能性は、バグやダウンタイム、停止についてだけではありません。正しいことを行っているか、ユーザーが素晴らしい体験をしているか、ビジネス成果を達成しているかを確認することについてです。価値を構築することについてです。運転する途中でどこに行こうとしているかがわからない場合、速く進むことはできません。ユーザーがコードを使用している方法についての可視性が高ければ高いほど、エンジニアとして強く、自信を持って仕事ができます。

観測可能性の未来は、特にAIの開発についてどう見ていますか？

観測可能性は、チームがタイトで速いフィードバックループを接続できるようにすることについてです。そこで、開発者は迅速に、自信を持って、生産環境で、無駄な時間とエネルギーを浪費せずに作業できます。

ビジネス成果と技術的手法を結び付けることについてです。

そして、世界に出すソフトウェアを理解することについてです。ソフトウェアとシステムがますます複雑になり、特にAIが混ざるようになると、人間の基準で理解し、管理できるようにすることは、より重要になります。

観測可能性の観点からすると、データパイプラインのレベルで、機械学習や高度なサンプリング技術を使用して、価値とコストのバランスをとることが見られるようになるでしょう。アウトライアーリベントについては、できるだけ多くの詳細を保持し、残りについては、サマリーを安価に保存します。

AIベンダーは、ソフトウェアをあなたよりもよく理解できる、またはデータを処理して人間にアクションを指示できるという、過熱した主張をしています。私が見た限りでは、これは高価な夢想です。誤った陽性は非常に高価です。システムとデータを理解することは、AIに代替することはできません。AIはエンジニアを支援できます！しかし、エンジニアを置き換えることはできません。

素晴らしいインタビュー、詳しく知りたい読者は、ハニカムを訪問してください。