OpenTelemetryを採用した一番の理由は？
司会者：宮﨑さん、発表をありがとうございました。このセッションはインフラ寄りのキーワードも多く、僕はインフラ畑の人間なのでそこを突っ込みたいんですが、ちょっと我慢してGoに焦点を当てた質問をさせていただければなと思います。
宮﨑大芽氏（以下、宮﨑）：お願いします。
司会者：まず「計測するとなって、OpenTelemetryを採用した一番の理由は何だったのか？」というのを教えていただければなと。
宮﨑：採用したのは実際は僕ではないのですが、思う部分がちょっとあります。完全に選定した回答ではないんですけど。
もともと僕たちは「GCP」だけじゃなく「AWS」とかも使っています。トレーシングするにあたってAWSやGCPなどを複数で使う場合があります。そう考えた時に、将来的にはトレーシング情報などをきちんと一元管理したい、Grafana Tempoを使って1個にまとめたいなど、考えているので、OpenTelemetryを使ったほうが将来的に実現したいことに直結するだろうと、OpenTelemetryを採用したと思います。
司会者：ほかのサービスとのインテグレーションとかも考慮して。
宮﨑：そうですね、おっしゃるとおりです。
司会者：たぶんほかの選択肢としては、たぶん「Datadog」とか「New Relic」みたいなサービスがあると思いますが、そこらへんも鑑みて。あとはコストの問題とかもたぶんあると思うんですが、そういった点を考えてOpenTelemetryにされたということですかね。ありがとうございます。
「計装」というキーワードについて
司会者：堅い質問の後にちょっとおもしろい質問も来ているので。（質問を見て）「計装」というキーワードが出ていましたが、確かにあんまり聞かないなと思って。
宮﨑：聞かないですよね。
司会者：感じとしてはたぶん、「計る」に、実装の「装」ですよね。
宮﨑：そうです、そうです。おっしゃるとおりです。
司会者：ちょっと僕も今、この質問が来ていて「確かにな」と思って調べてみたら、これは測定の時に使う用語なんですかね？
宮﨑：僕もよくわかって使っては……（笑）。
司会者：なんとなくで使っている（笑）。
宮﨑：OpenTelemetryを導入するにあたって僕も調べて、「計装」という言葉がすごく使われていて、なんかこれはちょっと一般的な言葉なのかなと思って使わせていただきました。
司会者：そうですよね。でも確かに仕事をしていてもなかなか聞かないキーワードですよね。
宮﨑：使わないですよね。
司会者：要は、OpenTelemetryみたいな計測するものを導入する時に使われるキーワードとしてある感じですかね。ありがとうございます。ちょっと雑談みたいな質問になっちゃいましたけど（笑）。
宮﨑：（笑）。
OpenTelemetryの導入はどう進めたのか？
司会者：次はこれもまた一風変わった質問で、技術面というよりは、ちょっとチーム的なお話なんですけど。
先ほどみたいなトレースの導入だと、もちろんいろいろな技術的選択もそうですし、コードも書き換えなきゃいけないと思うんですけど、全体的な導入をチームで進めていくにあたって、どういうふうに進めたのか。結局、「泥臭くみんなでやろうぜ」と言って進めたのか、というのはどういう感じなんですか？
宮﨑：進め方としては、そもそも僕がいたチームが負荷試験をしていました。負荷試験をするにあたって先ほども言ったとおり、ちょっとボトルネックの把握に時間がかかっているというところで、Anthos Service Meshを導入していることもあり、それを使ってトレースを実現したいとなったので。
パブリッククラウドとかインフラを管理しているCloud PlatformチームがABEMAにはあるんですけど、そのチームと、アプリケーション側の実装というかたちでCloud Platformチームが協力して進めるかたちになりました。
進め方としては、それぞれが実際にAnthos Service Meshでトレーシングを有効にしたり、こちら側でトレーシングのアプリケーション側の実装をしたり、それぞれで進めて実現したかたちになりますね。
司会者：そのお話を僕は社内にいて初めて聞いたんですけど、個人的にはすごくいい話だなと思っています。
なんでかというと、まさにDevOpsみたいなものを体現しているなと個人的には思っていて。今回導入されたTelemetryの実際のデータも、たぶんアプリを作る人というよりは、それを見て改善するSREの方々が実際に使うメトリクスなのかなと思うんですけど、そこもきちんとCloud Platformの方々と開発の方々で一丸となって取り組めたということですよね？
宮﨑：そうです、そうです。
司会者：ありがとうございます。すごくいい話だなと思います。そういった感じで取り組んでもらったんですかね。ありがとうございます。
コンテキストが伝播していない部分をどう探し出したのか？
司会者：では次ですが、Goの話題にちゃんと戻って、コンテキストが伝播していない箇所。レガシーのコードですね。僕も経験があって、「あっ、この関数、コンテキストが渡ってないやん」みたいな時があったんですけど（笑）。たぶんコードベースもそんなに小さくはないと思うのですが、どうやって伝播していない箇所を探し出したんですか？
宮﨑：今回、トレーシングを導入するにあたって、トレーシングを導入したいサービスというのがそもそも負荷試験をしている段階でけっこう見えていたんですよ。そのサービスを調査するにあたって、そもそもトレーシングを導入する前に、例えばタイムアウトを設定したいとかそういうことがけっこうあって。そのサービスはコンテキストがそもそも伝播されていないということを、けっこう負荷試験を通して知っていたんですよね。
それもあってコンテキストの伝播がされていないことを知ることができて、対応したかたちになります。負荷試験を経験して知ることができたという感じになりますね。
司会者：それもそれで、やはり実際の開発という感じがしていいですね。なんか単純にgrepとか目grepで探すわけじゃなくて、計測した上で「あぁ、ここが怪しい」となって当たりをつけて探していったみたいな。
宮﨑：そうですね。
司会者：なるほど、ありがとうございます。
メトリクスのトレースはサンプリングレートで計測している
司会者：次が、メトリクスの……トレースですね。実際に先ほどのトレースのコードを挟んで、データをバックエンドに送ると思うんですが、たくさん送るとやはりデータ量が増えたり、課金の額が増えていったりすると思います。全件トレースを取って送るのか、もしくはサンプリングをしたりしているのかという質問ですね。
宮﨑：まさに、サンプリングをしています。どれぐらいのレートでサンプリングをしているかはちょっと述べられないのですが、ABEMAなのでリクエスト数もかなり多いというのもあって、できる限り少ないサンプリングレートで計測をしていますね。
司会者：サンプリングとかも、やはりやってみないとわからないところはありますよね。
宮﨑：そうですね、はい。
司会者：そこもけっこうトライアル・アンド・エラーでやって、というところですかね？
宮﨑：いったん決め打ちで入れたかたちになります。
司会者：なるほど、なるほど。ありがとうございます。
トレーシングの導入における負荷の問題はないのか？
司会者：次もトレース情報のお話です。要はネットワークの通信が発生すると思うのですが、そういった処理によってアプリケーションへの負荷になることがあったりは……さすがにそれは大丈夫だったんですかね？
宮﨑：トレーシングを導入する時に、一応それは話題にはなったんですが、導入したのが負荷試験をやっている最中だったというのもありますし、そのトレースを導入した後にさらに負荷を上げて負荷試験をやるということもわかっていたので、実際にトレーシングを導入したことが負荷になったかどうかはちょっとわからないんですけど。負荷試験をするから導入しても問題ないんじゃないかという、問題があったら見えてくるだろうというかたちで導入しました。
司会者：ありがとうございます。
ABEMAのサービスは基本的にGoで実装されている
司会者：ちょっとインフラ寄りの質問が多くて答えられなさそうなものも多いんですが、ちょっとこれをお聞きしようかな。
ABEMAとして、いろいろなクラウドプラットフォームや外部のサービスを使っていると思います。OpenTelemetryはOpenという名が付いているとおり、どんなプラットフォームでも使えると思うのですが、実際にベンダーに依存しないもののモチベーション、たぶん技術選定の理由ですかね。ここらへんは、先ほどのインテグレーションとかのお話と一緒ですかね？
宮﨑：そうですね。先ほどもまだ理想の形ではないという話をしたと思いますが、今後、すべてのログとかも集約して、トレースからログを紐付けたりしていきたいなと思っているので、そういうのも踏まえてOpenTelemetry、先ほどのインテグレーションもそうですが……選んでいる感じになりますね。
司会者：ありがとうございます。（質問を見て）そうですね。じゃあ、この質問を拾おうと思います。ちょっとABEMAの全体のお話になっちゃうので、あくまでも宮﨑さんがご存じの範囲で大丈夫なんですが。
宮﨑：わかりました。
司会者：今までのセッションでもABEMAのサービスがいろいろ出てきていたと思うんですけど、基本的にGoで実装されているという認識でよろしいですか？
宮﨑：はい、そうだと思います。僕は中途入社なんですが、僕が入社してから関わったサービスはすべてGoで実装されていました。
司会者：だからこそ、先ほどのトレースとかもチーム一丸で進めて、たぶん言語が違ったらまたトレースのライブラリとかも考えたりしなきゃいけなくて、さらに工数が増えたりすると思うんですけど（笑）。そこは全チームとしてGoを選択しているからこそ、先ほどの施策としても進めやすいし、改修としてもわりと簡単に入れられたみたいな感じですかね。
宮﨑：そうですね。トレーシングをする、先ほどの実装も、内製のライブラリみたいなもので実装されているので、実際Goに、ほかのサービスとかを導入するのは比較的やりやすかったですね。それはやはりGoを全体的に採用しているからだと言えますね。
司会者：なるほど、ありがとうございます。
OpenTelemetry RedisやOpenTelemetry MongoDBは、何をトレース情報として含められるのか？
司会者：（質問を見て）ちょっとこれを拾おうかな。「RedisのOpenTelemetryやOpenTelemetry Mongoでは、トレース情報として何を含めることができるのでしょうか？」と。
宮﨑：まず導入の仕方としては、イニシャライズする時にMongoだったらモニタリングみたいな、初期化の設定をするコードがあって、そこに入れ込みます。見えるものとしては、Mongoだったらまさにクエリのfindだったり、そういうものがトレース情報として出てきます。findした部分の名前とその時間がきちんと出てきます。
Redisもまさに同じようなかたちでsetしたりgetしたものがトレース情報として出てきます。
司会者：じゃあ、実際にそのアプリで、例えばユーザーをgetする処理のキャッシュから引っ張ってきた時に、叩いたgetのトレース情報とかがきちんとパッと出てくるみたいな。
宮﨑：そうです。おっしゃるとおりです。
司会者：それは便利ですね。ありがとうございます。
宮﨑：ライブラリで実装できるので、特に僕らが計装する必要はなくて、もう非常に便利ですね。
司会者：そうですね、確かに。ありがとうございます。
実装にかかった期間は？
司会者：お答えできなかったらこれは大丈夫なんですが、実装にかかった期間。先ほどのトレースのコードを入れるって、やはり大規模な工事じゃないですか。それは実際、どれぐらいの期間でやったのかはお聞きしても大丈夫ですか？
宮﨑：たぶん、具体的なことを言うのもアレなのかもしれませんが、「今週お願いします」ぐらいです（笑）。
司会者：あ～。これは大丈夫ですか（笑）？
宮﨑：（笑）。わからないですが、それぐらいの……負荷試験をやっていたこともあって、けっこう温度感を高く対応したというのはあります。なので、全部理想の形にするんじゃなくて、やれる分だけでやりましょうという。
司会者：なるほど、ありがとうございます。すみません、ちょっとセンシティブな話題だったかもしれませんが（笑）、ありがとうございます。ちょっとお時間も来ましたので、いくつかまだご質問があるんですが、申し訳ありません。ちょっとここで打ち切らせていただこうと思います。
あらためて宮﨑さん、発表をありがとうございました。
宮﨑：ありがとうございました。
（会場拍手）
