Duolingo は世界をリードする語学学習アプリであり、毎月何百万人もの学習者に、魅力的なレッスン体験を提供しています。ミッションはシンプルです。世界最高の教育をつくり、誰もが利用できるようにすること。
舞台裏では 200以上のマイクロサービスと、1日に複数回のデプロイを伴う高速なリリースサイクルがこれらの体験を支えています。これほど複雑なシステムを運用する以上、Duolingo は見逃されたバグや遅い問題解決がプラットフォームや「学習者第一」のミッションを損なわないようにする必要がありました。
暫定対応、分断されたデバッグ、生産性のボトルネック
Sentry 導入前、Duolingo は同社のスケールに対応できるよう設計されていない従来型のエラー監視ツールに依存していました。その結果、煩雑なデバッグワークフローとUIがエンジニアの不満を招き、生産性を制限していました。
- 遅いデバッグ： 情報の検索は1回のクエリでも最大30分かかることがありました。さらに同時にクエリできるのは1人のエンジニアだけで、チーム全体に強いボトルネックが生まれていました。
- ノイズ過多： 有効なフィルタリングやグルーピングがなく、無関係なデータが大量に流れ込み、重要な問題に集中することが難しくなっていました。
- 検索機能の制約： 短期的なスパイクのような細かなエラートレンドは、特定がほぼ不可能でした。エンジニアは手作業に頼ったり、勘に頼って原因を探したりすることがよくありました。
- 使いにくさと属人化： UIが扱いづらく、利用は経験豊富な少数のエンジニアに限られていました。その結果、「パワーユーザー」への依存が生まれ、他のメンバーは貢献に必要なツールやコンテキストを得られない状態でした。
- コンテキストと可視性の不足： 取得できるメタデータが最小限で、エラーと根本原因の相関も弱かったため、開発者は複数の情報源からコンテキストを寄せ集める必要がありました。こうしたコンテキストの切り替えが解決までの時間を延ばし、生産性を下げていました。
さらに悪いことに、この従来ツールでは課題をすべて解決できず、ワークフローに重要な穴が残っていました。チームは暫定対応を素早く出せてはいましたが、それは場当たり的な対症療法になりがちで、根本原因は未解決のまま残り、同じ問題が後から何度も再発することがありました。
「単純なデバッグですらマラソンのように感じました。ツールが分かりにくく、デバッグできるのはパワーユーザーだけで、他の人は簡単に理解できなかったのです。全員にとってデバッグを効率化するためのツールがありませんでした。」と、Duolingo の Staff Site Reliability Engineer である David Amin 氏は言います。「単に時間を無駄にしていたという話ではありません。すべてのエンジニアが、素早く問題を解決できるという自信と能力を持つためのツールがなかったのです。」
システムとチームの複雑さが増すにつれ、Duolingo は、よりスケーラブルで開発者にやさしいエラー監視とデバッグのアプローチを求めるようになりました。
Duolingo が Sentry を選んだ理由：実装の簡単さ＆インサイトまでの時間の短縮
選択肢を評価した結果、Duolingo は最小限のセットアップで最大の課題に対処できることから Sentry を選びました。分かりやすい導入と開発者中心の設計により、チームは採用しやすく、すぐに効果を得られました。
- 200以上のマイクロサービスを2週間未満で移行： Sentry のAPI、Terraform 対応、分かりやすい設定により、200以上のマイクロサービスをわずか2週間で移行できました。
- 解決までの時間を12倍高速化： リアルタイムクエリ、直感的なダッシュボード、深いコンテキストにより、エンジニアはノイズを素早く絞り込み、トレンドを可視化し、問題箇所を特定できました。すべてを1つのツール内で完結できます。以前は原因の特定がほぼ不可能で、何時間、場合によっては何日もかかっていました。いまは数分の話です。
- ノイズ削減： 組み込みのグルーピング、フィルタリング、Spike Protection、オーナーシップルールにより、ノイズを取り除き、重要な問題だけを検知して適切なチームへルーティングします。これによりアラート疲れが軽減され、重要なエラーに集中できます。さらに明確さを得たことで PagerDuty とも直接統合し、緊急アラートを即時対応につなげています。
- より高度なコンテキスト： ブラウザ、リリース、ユーザーといった標準メタデータに加え、実験IDやフィーチャーフラグのようなカスタムタグも活用し、デプロイ文脈や個々のユーザー単位でデバッグできる詳細な見え方を得ました。
- 誰でも使えるデバッグ： 直感的なUIによって、すべての開発者がデバッグに参加できるようになり、自分のコードにオーナーシップを持って先回りして問題を解決できるようになりました。分かりやすいデバッグフローと、既存ツールとの統合により、Sentry は Duolingo のエンジニアリングツールキットの中核になりました。
ロールアウト以降、DuolingoのWebおよびバックエンドのエンジニアの50%以上（400人中およそ240人）が、リリース管理のためにほぼ毎日 Sentry を使っています。
「以前のツールでは、デバッグは一部のパワーユーザーに限られていました。Sentryはプロセスを民主化しました。いまは、どのエンジニアでも、深い学習やトレーニングなしに参加して、洞察を見つけ、素早く修正できま。」ー David Amin（オブザーバビリティチームリード）
結果：より速いデバッグ、稼働率の改善、チームの自走
Duolingo の開発者は問題を数時間ではなく数分で解決できるようになりました。
いくつかの例を紹介します。
データベース障害の解決
Sentry 導入から数週間以内に、Duolingo はこれまで特定が難しかった重大なデータベース問題を診断しました。カスタムタグと時間単位まで追える可視性を備えた Sentry のダッシュボードと強力なクエリ機能により、最重要データベースの1つで起きた異常をすばやく特定できました。チームは即座にクラウドプロバイダーへ連絡し、インシデント調査時間を大幅に短縮しました。
「Sentry が根本原因に導いてくれたことで、データベース側の問題だと自信を持って確認でき、適切な人に確信を持ってすぐページできました。以前は、このレベルの明確さは得られませんでした。」とエンジニアリングマネージャーの Maggie Hewitt 氏は言います。
さらに重要なのは、その後に起きた別のインシデントでは、Sentry により「データベースが原因ではない」と自信を持って切り分けられ、リソース配分を効率化できたことです。
10分未満でスパマーを特定して遮断
Slack でエラー急増の通知を受けた後、あるエンジニアは当初、start_time の扱いに問題があるのではないかと疑いました。
しかし Sentry の JSON を確認したところ、コードは None 値を正しく考慮していることが分かりました。関連イベントを見ていくと、同じユーザーIDに対して複数のセッション終了イベントがあり、しかもそれぞれ別のセッションIDで、回答済みの問題が一つもないことに気づきました。状況はボット活動を示していました。9分以内に Sentry はこの問題を素早くデバッグし、ボット行為だと確認し、システムに影響が出る前に対処するために必要なコンテキストを提供しました。
「Sentry はエラーとソースコードを直接結び付ける数少ないツールの1つです。特定の Sentry エラーを参照して、コードの該当行を正確に指しているエンジニアを何度も見てきました。全員がより速く修正できるようになり、開発者体験も大幅に改善しました。」ー Tim Kirdy（シニアバックエンドエンジニア）
先回りのアラート
Sentry の異常検知は、Duolingo のスタックに新たな可観測性のレイヤーを加えました。従来のアラートが発報しなかったインシデントの際も Sentry がモノリスのデプロイにおける微細な問題を検知し、見逃される可能性があった事象を可視化しました。これによりモノリスチームは素早く対処し、問題が拡大する前に解決できました。
Sentry は Duolingo の開発者が自分のコードに先回りして責任を持てるようにし、デバッグと問題解決の進め方を変えました。組織全体に Sentry を広げたことで、オブザーバビリティチームは、個々の開発者が独力で問題を特定し、解決できるようにしました。場合によっては、オブザーバビリティチームが気づく前に解決されています。この変化により中央集権的な指揮への依存がなくなり、「You build it, you run it（作った人が運用まで責任を持つ）」の文化が根づきました。エンジニアは Sentry を直接使って自分のサービスをデバッグし、トリアージできるようになり、応答速度、説明責任、ワークフロー効率が向上しました。
「Sentry のおかげで、傾向やエラーをより速く見つけられるようになり、人生の『数年分』を節約できました。ツール間を行き来して何時間もかかっていたことが、いまは一瞬でわかります。」ー Maggie Hewitt（エンジニアリングマネージャー）
次にやること
ユーザー体験とクライアントサイド可観測性の改善に部門全体で取り組む中、Duolingo は Sentry の利用を iOS と Android アプリへ拡大しています。モバイル領域は歴史的に、デバッグが遅く、分断されがちでした。フロントエンドとバックエンドの両方に Sentry を統合することで、サイロをなくし、フルスタックでの可視性を高めたいと考えています。
「バックエンドでSentryができることは見てきました。」とシニアバックエンドエンジニアの Tim Kirdy 氏は言います。「いまは、その同じ明確さとスピードをモバイルアプリにも持ち込むのが楽しみです。」
主要な成果
- 移行の成功： 200以上のマイクロサービスを影響を最小限に抑えつつ2週間で移行。
- 定着： エンジニアの50%以上が日常的に Sentry を利用。
- 効果： 主要ワークフローでデバッグ時間が2〜3倍短縮。サイロが減り、チーム参加が改善。
- 稼働率99.9%を維持： より速い問題検知と根本原因に対処するためのコンテキストを提供することで、Sentry はダウンタイムに発展する前にエラーを修正できるよう支援します。これは Duolingoが掲げる厳格な稼働率 99.9% 目標の維持において重要でした。
Original Page: How Duolingo debugs issues 12x faster while reducing alert fatigue and empowering engineers
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
