NTTドコモ｜監視からオブザーバビリティへー 統合API 基盤のサービスレベル向上を目指すNTTドコモの選択

NTTドコモのサービスデザイン部は、様々なB2Cデジタルサービスの企画・開発と、これを実現するシステム（アプリケーション、開発・検証環境、サービス基盤など）の開発・運用を担う200名規模のチーム。NTTドコモの多様なサービス群は、APIを介して共通の「認証基盤」や「決済基盤」などと連携し、安心・安全なデジタルサービスを7,800万のドコモユーザーに提供している。

「2019年初頭から統合API基盤『RAFTEL』の開発に着手しました。これまで、ドコモのサービスは多種多様な API をぞれぞれ個別に呼び出しており、処理の複雑性が増していました。そこで、

あらゆる ドコモのサービスが使う 各API を一箇所に集約し共通基盤化し、開発者はRAFTELのAPI仕様を理解すればすべてのAPI利用が可能になるという次世代API基盤をRAFTELとして構築したのです」と加藤氏は話す。

従来の環境でたとえば「決済」を利用するには、複数の基盤にアクセスして複数のAPIを呼び出す必要があったという。また、基盤ごとにAPIへの接続方法や仕様が異なり、そのAPIを呼び出すためには、学習や検証にも多くの工数を要していた。

「統合API基盤『RAFTEL』では、サービス開発のスピード化の足枷になっていたこれらの課題を一挙に解決することを目指しました。統一された仕様で、シンプルかつ容易にアクセスでき、一度のアクションで連携可能になれば、サービス開発の生産性とスピードを大きく向上させることができます」（加藤氏）

「RAFTEL」は、AWS上にPaaS（VMware 社のTanzu Application Services）を利用して構築されている。Google 社のApigee EdgeをAPI管理に採用し、VMware 社のBOSHがAWS上へのアプリケーション展開とサービス結合を実行するモデルだ。同部 第一クラウド推進担当 主査であり、RAFTELチームのリーダーを務める吉田悦郎氏は次のように話す。

「クラウドネイティブなテクノロジーを全面的に採用し、アプリケーション開発の生産性向上と高速リリースが可能な環境を実現しました。アーキテクチャを効率化する一方で、開発チームの高い生産性を維持するためにはRAFTELそのものの安定稼働、つまりサービスの信頼性の維持が不可欠です。RAFTELの立ち上げ当初、私たちは複数のOSSツールを組み合わせた監視システムを利用していました」

吉田氏らは当初OSSツールの組み合わせにより、メトリクス収集にPrometheus/GrafanaとZabbix、ロギングにELKスタック (Elasticsearch, Logstash, Kibana)、トレーシングにZipkinを採用し、コンテナ単位のパフォーマンスからAWS上のインスタンスメトリクスやログまでを監視するとともに、ボトルネックを特定するための仕組みも整えた。

「しかし、この方法はすぐに大きな壁にぶつかりました。複数ツールを個別に運用することが現実的でないとわかったのです。サービスレベルの維持・改善どころか、ツールの運用に時間をとられてしまいました。また、私たち『API基盤チーム』の他に、『サービス開発チーム』『インフラチーム』それぞれが自分たちの視点でRAFTELを見られるようにしたいと考えていましたが、3画面方式でそれを実現するのは困難でした」（吉田氏）

加藤氏は、「複数のOSS監視ツールの情報を統合的に参照するためのツールを模索する過程で『オブザーバビリティ』に着目し、New Relicに行き着いた」と言う。特に New Relic のアプリケーションパフォーマンス管理（APM）機能は、複雑に連携し合うクラウド環境の可視化に大きな威力を発揮することがわかった。

「オブザーバビリティを実現する代表的なソリューションを検討したところ、『複数の監視ツールの情報を統合的に表示させる機能』に関しては大きな差がないことがわかりました。しかし、開発・インフラ・運用それぞれの視点で『ダッシュボードの表示内容を柔軟に変更する機能』では、New Relicが明らかに優れていました」（吉田氏）

加藤氏・吉田氏は、RAFTELのサービス信頼性を向上させるために「問題が発生してから対処するリアクティブ型」から、「予兆を把握して問題が発生する前に手を打つプロアクティブ型」の運用へと変革することを目指していた。

「私たちがRAFTELで設定した『サービスレベル目標（SLO）』に対して、New Relicではその達成度をダッシュボードで参照できることも評価しました。SLOを起点にパフォーマンスの傾向を把握し、低下している場合はその原因を速やかに特定して、ユーザーである開発者の生産性に悪い影響を及ぼす前に対処できます。New Relicには、まさにプロアクティブ型の運用を実践するための環境が整っていました」（吉田氏）

監視からオブザーバビリティ（可観測性）へ――New Relicは業界を代表するオブザーバビリティプラットフォームであり、デジタルサービスにおけるあらゆる重要指標を観測可能にする。アプリケーション、インフラ、ユーザー体験の観測を通して、障害やサービスレベルの低下、潜在的な問題・ボトルネックを可視化。開発と運用が一体となって目標に向かうDevOpsチームのパフォーマンスを最大化することができる。

「New Relicのエンジニアから提案を聞き、『オブザーバビリティ』があってこそプロアクティブ型の運用が可能であり、RAFTELの信頼性を継続的に高めていくことが可能なのだと確信しました。従来型の運用監視チームから、システムの信頼性に重きを置いて変更速度を最大化する『SRE（Site Reliability Engineering）チーム』に変わらなければならない、という私たちの志向にもNew Relicはマッチしていました」（吉田氏）

●プロアクティブ型の運用を通して、開発チームにより良い体験をもたらすサービスレベルを実現すること

●システム拡張時でもサービスレベル低下や運用負荷増大を起こさず、継続的な改善と信頼性向上が可能なこと

この2つが、New Relicから加藤氏・吉田氏への提案の軸であり評価されたポイントだ。一般に、システム規模が拡大するほど運用負荷は増大し、問題発生時の原因特定は難しくなる。しかし、運用コストの増加、サービスレベルの低下、サービス開発の遅延、といった事態は回避しなければならない。

「2020年9月時点で、RAFTELに接続しているドコモのサービスは5つ。テスト中のものを含めると35に達します。今後のシステムの進化と拡大を考えると、トランザクション量の増大とともにエラー数も増大することは明らかです。私たちはNew Relicの技術者と話し合いながら、たとえサービス規模が数倍に拡大しても、サービスレベル目標（SLO）を順守しながら、サービス開発チームの生産性向上に貢献し続けることができる準備を整えました」（吉田氏）

New Relicは、クラウド上でサービスを提供する多様なコンポーネント間の複雑な接続関係をすべて把握し、強力なエラートレース機能により問題の原因を速やかに特定できる。ビジネスの成長とともにシステムの規模と複雑さが増しても、サービスレベルの改善・維持をスケールできることが大きな特長である。

「New Relic の採用によってRAFTEL構築時の構想であった、開発・インフラ・運用チームに対してそれぞれの視点で参照できるダッシュボードを用意できる目処が立ちました。New Relicの導入プロジェクトには、開発チームのメンバーにも参画してもらいながら具体的な要望を採り入れています。これにより、開発と運用が一体化したDevOpsチームとしての意識も高められました」（吉田氏）

New Relicの本格的な活用はまもなく始まる。NTTドコモのB2Cサービスの開発を加速させる統合API基盤「RAFTEL」は、New Relicのオブザーバビリティによってサービスレベル目標を遵守しながら進化し続けることができる。加藤氏は次のように話す。

「New Relicの導入プロジェクトを通して、サービスレベル目標（SLO）を起点にした運用と、これを支えるプロアクティブ型の運用、継続的な改善の重要性への理解が深まったことを実感しています。開発そのものを外部のパートナー企業に任せても、サービスレベルの指標管理を私たちが行うことで、RAFTEL運用の主導権と意思決定を持てることは極めて重要です。プロジェクトの過程は、私たちの意識変革のプロセスでもあったと感じています」