New Relicを「全員で見るインフラ」へ。askenが挑んだ、脱・属人化と少人数チームでのオブザーバビリティ民主化
累計会員数が1,300万人を超えるヘルスケアアプリ『あすけん』。食事記録を通じてカロリーや栄養素を自動表示し、管理栄養士監修のアドバイスをフィードバックするサービスとして、多くのユーザーに利用されています。特に食事の時間付近には、アクセスが一気に集中する特性を持つアプリです。
同社が直面したのは、急成長に伴うシステムのレガシー化とアラート対応の属人化という課題でした。New Relicを導入したものの、当初は一部のインフラ担当者だけが使用する状態が続いていました。しかし、ある転機をきっかけに「全員でアラートを見る」体制へと移行。その結果、エンジニアが自発的にダッシュボードを作成し、品質改善に取り組む文化が醸成されました。
なぜaskenは、New Relicを組織全体で活用するツールへと変革できたのか。その背景には、属人化リスクへの危機感と、地道な教育活動がありました。
ヘルスケアアプリとして、AI時代に挑む「変革期」
写真左:西秀和氏 株式会社askenプロダクト開発本部プロダクト開発部エンジニアリングマネージャー
写真右:鈴木一帆氏 株式会社askenプロダクト開発本部プロダクト開発部インフラエンジニア
──はじめに、asken様の事業の現在地についてお聞かせください。
西氏：『あすけん』は、今「変革期」にあると考えています。当初はBtoB向けのWebサービスとして提供を開始しましたが、想定していたほどのユーザー獲得には至りませんでした。そんな中、BtoC向けにWebサービスを提供したところ、大きな反響があり、その後、アプリをリリースしたことで累計会員数が1,300万人を超えるサービスへと成長しました。
そして現在、『あすけん』はさらなる「変革期」にあります。技術の進化に伴い、食事記録やカロリー計算確認といった機能は、今やAIでも実現可能になりつつあります。
この市場で勝ち残るには、これまで『あすけん』に蓄積された100億件を超える食事記録データをはじめとする独自データを活用し、ユーザーに、さらに価値のあるフィードバックを提供するアプリへと進化させることが必要です。まさに、AIとデータを組み合わせたプロダクトを構築するフェーズです。
「属人的なアラート対応」からの脱却、組織の持続可能性から導き出した意識改革
──New Relicを導入する以前、現場ではどのような課題感を持たれていたのでしょうか。
西氏：アプリの急成長により技術的負債が多く貯まりシステムの複雑度が高まったことで、機能追加・変更をすることの影響範囲が見えづらくなり変更容易性が急激に落ちました。アプリとしては10年以上提供する中で変化をし続けているのですが、問題が特に顕著化したのは内製化へ踏み出した2022年頃からです。
本来はアプリの変化の速度を上げるための取り組みだったのですが、既に熟練者以外には変更が難しいシステムと化しており、影響範囲がわからずに新しい機能の追加に期間を要する、障害が発生しても原因の特定に時間を要するなど、システムの内部構造が見えない事で変更も保守も難しい状態になっていました。
──New Relicを選んだ理由は何だったのでしょうか。
西氏：当初からNew Relicありきで導入を決めたわけではありません。先ほどお話したシステムの内部構造を可視化する目的で、New Relic、Datadog、Dynatraceといったオブザーバビリティツールを比較検討し、選定しました。New Relicを選んだ理由の一つは、ユーザーベースの課金体系が弊社のエンジニア体制に合っていたからです。
弊社のエンジニアは現在20名程度ですが、当時はさらに少ない人数でした。こうした少人数体制で大規模なシステムを運用する場合、ホスト数やサーバー台数に応じた従量課金型のツールでは、サービスの成長に合わせてコストが膨らむ可能性がありました。
一方、ユーザー数に応じた課金体系であるNew Relicは、システム規模が拡大してもコストへの影響が少なく、少人数チームにとって大きなコストメリットがあり、弊社のエンジニア体制に非常に適していました。
──全員にアカウントを配布するきっかけは何だったのでしょうか。
西氏：もともとはインフラチームがアラートを検知して対処したり、サーバーサイドが一人でアラートの対処をしていたりという時期がありました。すると極端な属人性が発生してしまいますし、その人たちだけがシステムの良くない点を課題だと感じていて、他の人たちは課題だとすら思っていない。
同じプロダクトを保守しているのに、非常にアンバランスな状態になっていました。主要メンバーの交代を機に、将来的な組織の持続可能性を見直したことが大きな転機になりました。「個人に依存し続ける体制は、事業成長のボトルネックになる」という強い危機感を持ち、これを機に「アラートを全員で監視する」自律的な体制への移行を決断するに至りました。
そこから、アラートを輪番制で回していく体制にしようという一環で、New Relicを使ってアラートを見られるようにしないと対処できないよねという話になりました。
監視からオブザーバビリティへ——設計思想の変化
──New Relicを入れたことで、「監視」から「オブザーバビリティ」への変化を実感されていますか。
西氏：何かアラートが上がってきてわからないことがあるときは、New Relicを見に行って、特にトレーサビリティを見に行って、どこで落ちたのかを確認する。そういう意味では「見える化したいときはNew Relicを見に行こう」という状態はできています。
感覚論になりますが、監視（異常の検知）からオブザーバビリティ（原因の解明）への変化は、「システムをコントロールできているか」だと思っていて、そのコントロールできている範囲は上がったなと感じています。
──具体的にはどのような変化がありましたか。
西氏：オブザーバビリティのツールを導入する前は、監視するメトリクスと閾値を決めて、そのメトリクスをサーバーに送りアラートを設定するという開発でした。現在は、まずNew Relicにすべてのデータを送信するようにしています。そのため、何か問題が発生した際には、その問題を可視化するためのダッシュボードを作成し、後から分析できる環境が整いました。
ツールを導入したことで、設計に対する考え方自体が変化しました。「何かあっても対応できる」「安心して開発に取り組める」という心理的な安心感も得られています。
「全体的な遅延」を解消し、ピンポイントな性能改善のフェーズへ——ボトルネック解消の道のり
──信頼性向上の取り組みで、具体的な成果はありましたか。
西氏：もともとはアクセスが集中したときに、全てのレスポンスが遅くなっていたんです。システムとして限界を迎えていて、全体としてさばききれていない、みんな遅いという世界でした。
原因としては、データベースにボトルネックがあって、ユーザーのアクセスが一番集中するときにリソースが限界を迎え、システム全体が極めて不安定な状態に陥る場面もありました。しかし、New Relicによってボトルネックが「見える化」されていたため、場当たり的な対応ではなく、抜本的な対策が必要であると即座に判断・実行することができました。
その後はエンジニア全員で「どこに原因があるのか？」をNew Relicを使って原因を突き止めました。多くの重い処理を特定して、優先度をつけて倒していきました。
今はデータベースのボトルネックを解消してきて、そういう事態は発生しなくなりました。今は0.1％〜0.01％といった本当に限られた一部のユーザーさんだけが例外的にレスポンスが遅いことが発生するという状態です。99%タイルのグラフでは見えてこないイレギュラーな性能劣化に、今後はより一層挑んでいかないといけないところです。
当事者意識の醸成——「自分たちで見て、自分たちで対応する」文化
──全員にアカウントを配布したことで、組織にどのような変化がありましたか。
西氏：みんなでアラートに対応するため、まず意味のないアラートが通知されないようにする、いわゆるオオカミ少年アラートをなくす取り組みが進みました。無駄にエラーレートを上げているようなアラートを消して、本質的に挑むべきエラーだけをエラーとして対処できるようにする。その結果、日々出てくるアラートが減って、アラートに対処している時間は圧倒的に減っています。
あるチームでは機能を作ったら、合わせてダッシュボードを作ってその機能の監視をするようになりました。エンジニアリングマネージャーとしては、すごくいい意味で楽になりました。何も言わなくても、自分たちで監視体制を作ってくれて、自分たちで対応してくれる。インフラチームがずっと監視して頑張る必要がなくなって、負担が目に見えて減りました。
昔は順番にアラート対応をやっていたので、「今週は自分の番だな」と嫌がっている人もいましたが、最近はアラートが減っているため担当になっている人が対応しなくても、誰かが先に対応しているケースが多いです。担当になっても嫌がられない環境になりました。
「使うのが怖い」を超えるための工夫——ダッシュボードコンテストと学習会
──全員にアカウントを配布しても、すぐに活用されたわけではなかったのですね。
西氏：アカウントを全員に配布してから、ちゃんと活用されるまで1年から2年くらい期間がかかりました。その間は本当に一部の人たちが自分たちの監視とアラートに気づくために使っていたという状態で、属人化を防ぐという目的で導入したにも関わらず、有効活用できる体制が整えられていない状態でした。
鈴木氏：New Relicが導入されていたことを知らなかったというメンバーがいるくらいでした。また、アカウントを配布したのですが、みんな使わないんです。「なぜ使わないのか」と尋ねてみると、「操作するのが怖い」「使い方がわからない」という声がありました。
──その壁をどのように乗り越えたのでしょうか。
西氏：ダッシュボードコンテストという形でイベントを企画しました。どのツールにも言えることですが、全員が使いこなせるようになるのは容易ではありません。導入時には各ツールの学習コストが発生します。強制的に使わせるのではなく、使うモチベーションになる機会を提供し、体験してもらえれば使ってもらえます。「知る」というハードルをいかに超えるかが重要です。
また、インフラチームの企画から始まったメトリクスの解説会も開催しています。インフラのメトリクスでは1個のグラフが何を表現しているのかがわからないということがありますが、モバイルのエンジニアがサーバーサイドのCPUやメモリの仕様を詳しく理解している訳ではありません。
なぜここでグラフが跳ねているのか、このグラフは下がった方がいいグラフなのか？そういったことを説明して、メトリクスに関する知識のレベルを上げる取り組みを2年ほど続けました。その結果として、システムの各レイヤーのメトリクスを理解することで、みんながNew Relicでメトリクスを見るという状況まで成長することができました。
経営層への説明——ツールへの投資価値をどう伝えるか
──経営層に対して、ツールのコストについてはどのように説明されていますか。
西氏：アラートや障害が発生した時に問題の場所の特定に時間がかかるということは、その時間はエンジニアの工数が溶けていっていることと一緒です。問題特定にかかる時間が短くなることで、エンジニアがすぐに問題の解消に向かい、解消したら次の開発に入れる。いわゆる人件費が無駄にならないという意味で、メリットがあると説明しています。
どれくらい改善できたかは定量化が難しいので、どれくらいみんなが使っているかを機能ごとに見える化して伝えています。アカウントを渡しているエンジニアがこんなに毎日使っている、このツールがないとアラートや障害への対処が立ち行かなくなるという形で説明しています。
マルチクラウド時代の集約先として——New Relicへの期待
──今後の展望や、New Relicへの期待についてお聞かせください。
西氏：今後特にAIを活用していく意味だと、マルチクラウドが避けられないと思っています。AWSのAmazon Bedrockを使ったり、GCPのVertex AIを使ったりすると、New Relicのような集約ツールがなければ、システム全体の状況を把握することができません。
また、AIを活用する際には、プロダクトに対してより最適なモデルが登場したら、その特性に合わせて最適な技術を選択できる「柔軟なアーキテクチャ」を維持したいと考えています。複数のクラウドやAIサービスを柔軟に使い分けることが前提となる中、それらを横断的に把握するプラットフォームとしてNew Relicを採用しています。情報の集約先として、今後もNew Relicを選び続けるだろうなと考えています。
「自立的なエンジニア組織」のためのアドバイス
──最後に、オブザーバビリティを武器にしたいエンジニア組織へアドバイスをお願いします。
西氏：システムは、事業が成長し、利用者が増えれば増えるほど必ずどこかがボトルネックに直面します。また、そのボトルネックを解消しても、次のボトルネックが必ず現れます。だからこそ、事業の方向性に合わせた先回りの対応をするためにも、オブザーバビリティは欠かせません。この状態が整って初めて、事業の成長とシステムの改善の両輪を回していけるのだと考えています。
鈴木氏：自分たちが作ったものが動いたときに、自分たちでシステムの状況を見れるようにしておかないと結局苦労することになるのは自分達です。発生した問題に対して誰か対処してくれる人がいるわけではありませんから、問題が返ってくる前に先手としてオブザーバビリティな状態にしておくことが大切だと、実体験を通じて強く感じています。
制作協力：New Relic株式会社
