ソフトバンクの開発チーム直面した「属人化の壁」
New Relicを導入したのは、新しい生成AIチャットサービス「satto workspace」の開発チームである。これは資料作成業務などに特化したサービスで、AIと人間が協調することでスライド作成といった業務を効率化できる。
satto workspaceの開発には、モダンなフレームワークを採用しており、開発者体験を最優先した技術選定が行われている。GitHubを基盤に、さまざまなAIツールを活用して開発生産性の向上や自動化を図っているのが特徴だ。
同開発チームがNew Relicを導入したきっかけは、伊藤氏が指摘した「障害対応の属人化」という課題に直面していたからである。
パイロット検証の段階で障害通知が届くようになったが、その都度、原因の特定と対応に追われることとなった。しかし、ソフトバンクの厳格なセキュリティポリシーにより、AWSコンソールのログを閲覧できるのは、CTOの田口氏に限られていた。
結果として、すべての障害対応が田口氏に集中し、負担が増大した。他の開発メンバーはAWSの本番環境の状況が一切把握できず、システムがブラックボックス化していたのである。satto workspaceの正式リリースに向けてこの課題を解消するべく、オブザーバビリティツールの導入を決定した。
田口氏は、数あるオブザーバビリティツールの中でもNew Relicを採用した決め手を次のように説明した。
「さまざまなAIツールと連携して開発者のEX（Employee Experience）を向上させ、CI/CD全体を観測できる点。そして、ソフトバンクの厳しい社内ポリシーにも適合し、シングルテナントかつスケールに強い料金体系であったことが決め手となりました」（田口氏）
New Relicを導入したことで、開発メンバーがダッシュボードを閲覧できるようになったものの、すぐには全員が障害対応をできる状態にはならなかった。開発メンバーの一人である亀田氏は、3つの課題を挙げた。
1つ目は、度重なる仕様変更によるダッシュボードの陳腐化。2つ目は、パイロット検証の段階のため本番データが不足し、アラートの閾値設定が形骸化していたこと。3つ目が、モダンな技術スタックを使用しているためにNew Relicとの連携に独自の処理が求められることである。
これらの課題に対し、亀田氏は次のように対処した。
1つ目の「ダッシュボード陳腐化」の問題には、「薄く作って育てる」アプローチを採用した。 当初は詳細なダッシュボードを作り込んだが、仕様変更ですぐに使い物にならなくなったためだ。そこで、ALB（Application Load Balancer）などサービスの基本となる指標の監視に絞り、小さく始める方針に転換した。要件が固まるにつれ、必要な機能を順次追加する運用に切り替えた。
2つ目の「本番データ不足」については、閾値を仮説に基づいて設定し、一定の運用期間を設けて誤検知を抑制することで対処した。
また、3つ目の「モダンスタックとNew Relicの連携」には、分散トレーシングを導入して対応した。Honoや独自のロガーを使用していたため、New Relic上でエラーが「その他」に分類され、前後の文脈が途切れてしまうという問題があった。
そこで分散トレーシングを導入し、アプリケーション側に直接手を加え、New Relicに適したログ構造化を実施したのである。これにより、エラーを「点」ではなく「線」として監視することが可能となった。
