Observability Conference 2022、利用者目線のオブザーバビリティ実装をドコモのSREが解説

Observability Conference 2022から、NTTドコモのSREがドコモ社内のサービス開発者とインフラストラクチャーの間に存在するAPI Gatewayを担うチームとして、自身のシステムに関するオブザーバビリティからサービスの開発を行うデベロッパーが必要とするオブザーバビリティとは何か？ を解説したセッションを紹介する。

動画：日2億リクエストを越えるNTTドコモのAPI基盤で開発者と利用者にオブザーバビリティを提供する話

セッションを担当したのは、NTTドコモのAPI GatewayチームのSREである宮川倫氏と玉置理沙氏だ。宮川氏はCloud Operator Days Tokyo 2021でもプレゼンテーションを行っているが、その時もオブザーバビリティのサービスであるNew Relicと一緒にオブザーバビリティのユースケースを解説している。

参考：Cloud Operator Days Tokyo 2021開催、New Relicとドコモのセッションを振り返る

セッションを行った宮川氏と玉置氏

RAFTELと名付けられたAPI Gatewayは、ドコモのビジネスを実装するサービスとそれが実装されるインフラストラクチャーの間に位置するシステムである。現在のシステムの構成に関しては深く説明されなかったが、Cloud FoundryをベースにしてAPI Gateway自体はGoogleが買収したApigeeを利用していると思われる。

サービスとインフラの中間に位置するシステムがRAFTEL

RAFTEL登場以前は、サービス開発者は社内のインフラストラクチャーに対してそれぞれが直接接続することでサービスを実装していた。しかしRAFTELを間に置くことで、インフラストラクチャー側の変更をRAFTELで吸収したり、複数のAPIをマッシュアップによって利用者側に利便性を向上させたりすることができたという。

RAFTEL導入の効果

RAFTELの特徴として説明されたのは、利用されているサービスの数やトランザクションの総数などで、「65のサービス、一日の処理量が2億トランザクション」であることが紹介された。同様の数字は、2021年7月に行われたCloud Operator Days Tokyo 2021でも「40以上のサービス、4億トランザクション／日」と紹介されていた。API Gatewayを利用するサービス自体は40から65に増えてはいるもののトランザクション数が減っているというのは不思議な傾向だ。マッシュアップが進んでサービス側からのAPI Callの回数が減っているということだろうか。

RAFTELの定量的な特徴

次のスライドで解説されたRAFTELチームの構成にはDevRelチーム、開発チーム、運用チームという名称が見えるが、DevRelチームが利用者側からの問い合わせ対応などのサポート業務とAPI Gatewayへの設定作業を請け負っているというのもリアリティがある。単に使い方を教えるという役割を超えたサポートチームという位置付けだろう。

RAFTELチームの構成

RAFTELが抱えていたオブザーバビリティの課題として、PrometheusやZipkinなど利用するOSSがバラバラだったこと、アプリケーションが出力するログをベースにしていたために影響範囲やエラーレートなどが即座にはわからなかったこと、そしてリアルタイム性に欠けていたことなどを挙げた。

課題を解決したのはNew Relic

結果としてNew RelicをRAFTEL全体に導入することでそれらの課題は解決されたという。

そして実際にRAFTELチームが利用しているダッシュボードを見せて、定量的にシステムの運用が行われていることを解説した。ここでは認証機能と決済機能の数値が紹介されている。

RAFTELのダッシュボードを見せて解説

そしてRAFTELとしては「高い信頼性」を目標に掲げていたにも関わらず、定量化ができていなかったとして、SLI（Service Level Indicator）とSLO（Service Level Objective）を提示することにしたと説明。SLIにはRAFTEL APIの外形監視、SLOにはエラーバジェットを使って定量化が行われていると解説した。

SLI/SLOを使ってサービスの定量化を実現

New RelicによってSLI/SLOが定量化できたことを評価した上で、さらにその先を目指すというのがこのセッションのキモだ。つまりAPI Gateway運用の定量化だけではまだ足らなかったということで、2022年3月から始まったという利用者目線での見える化を目指しているという部分を解説した。

ユーザーからの問い合わせを減らすためには何が必要かを考えた

RAFTEL内部ではダッシュボードを見れば何が起こっているのか理解できたとしても、RAFTELの利用者、つまりサービス開発者目線ではすぐに理解できない可能性が高いと考えた。そしてAPM（Application Performance Monitoring）を使ったAPIのTAT（Turn Around Time）を可視化したこと、RAFTELとインフラストラクチャー側に対する外形監視から見えるエラー数などをダッシュボードとして提示することを実装したと説明した。

利用者が理解できるようにエラー数などをダッシュボード化

理解を助けるためのヘルプドキュメントをダッシュボードの中に埋め込んでいるところに、細かい配慮が行われていると言える。

ダッシュボードの中にヘルプとなる情報も埋め込まれている

結果として、エラーが起こってもRAFTELに問い合わせをせずに、利用者側が能動的に何が起こっているのかを確認できるようにしているという。ただしこれは仮説に基づいて実装された機能なので、実際にこれがサービス利用者にとって本当に効果があるかどうかは今後の評価を待ちたいそうだ。

次のステップを紹介

次のステップとしてログなどのより詳細に状況を理解できるためのデータを公開することで、利用者側が原因の特定が行えるようにしたいと語った。

プレゼンテーションのスライドも語り口も自然体、同僚に語りかけるようなスタイルで行われた宮川氏と玉川氏のセッションだった。単に担当している領域のオブザーバビリティだけではなく、連携するシステムのデベロッパーにも「どうやったら理解してもらえるのか？」という観点で何が必要かを考えている姿勢は高く評価されるべきだろう。