出典：株式会社はてな エンジニア採用資料 https://speakerdeck.com/hatena/engineers-recruitment
多くの出版社に採用され、Webとスマートフォンアプリの両方で多彩なマンガコンテンツを届ける、株式会社はてなのマンガビューワ「GigaViewer」。人気作品の更新時には1分間で数百万リクエストものアクセスが集中しますが、そのような高負荷な状況下でも裏側では高い安定稼働が求められます。
頻繁な機能開発を進めながら、いかにしてサービスのパフォーマンスを維持し、ユーザーに快適な読書体験を提供し続けているのか。同サービスの開発チームを率いるテックリードの太田氏に、Mackerel APMを導入した背景と、それによってチームにもたらされた文化的な変化について、Mackerelプロデューサーの渡辺起が詳しくお話を伺いました。
― まず、太田さんが担当されている「GigaViewer」と、チームの役割について教えてください。
太田氏: 「GigaViewer」は、複数の出版社様のマンガサイトをホスティングしているマルチテナント型のマンガビューワです。Webブラウザ向けとスマートフォンアプリ向けの両方に、単一のバックエンドでサービスを提供しているのが特徴です。皆さんが普段読んでいるマンガも、実はGigaViewerで動いているかもしれません。
私の役割はテックリードとして、このGigaViewerの安定稼働と、お客様である出版社様からのご要望を反映した機能開発を迅速に進めることです。特に、人気サービスの『少年ジャンプ＋』では、週刊少年ジャンプが配信される月曜日の深夜0時にアクセスが集中します。「0時0分になった瞬間に一気にキュっと上がる」という非常に特徴的なトラフィックで、バックエンドには1分間で数百万以上のリクエストが届きます。こうした大規模なアクセスを安定して処理し続けることが、我々の重要なミッションです。
― 多くのユーザーが楽しみにしているサービスですね。APMを導入する前は、どのような課題があったのでしょうか？
太田氏: 正直に言うと、APMの領域で「明確に困っていた」わけではありませんでした。GigaViewerはAWS上で稼働しており、そのスケーラビリティを活かすことで、インフラ起因の大きな障害はほとんど起きていませんでした。 もちろん、パフォーマンス分析が不要だったわけではありません。リリース時や負荷が高いインシデントが発生した際には、AWS X-Rayを使ってトレース情報（リクエストがシステムを通過する際に処理する過程を追跡するための情報）を取得し、ボトルネックの特定などを行っていました。ただ、これはあくまで「緊急手術」のようなもので、日常的な「健康診断」にはなっていなかったんです。
X-RayはAWSコンソールの奥まったところにあり、日常的には見ていなかったんです。何かあった時に記録が役に立つ場面はありましたが、定期検診のようなことはやっていませんでしたね
頻繁に機能開発とリリースを繰り返しているため、一番多いトラブルはやはりアプリケーションのバグです。テスト環境では見つからなかった問題が、本番のトラフィックに晒されて初めて顕在化することもあります。パフォーマンスの劣化もその一つで、いつの間にか発生し、ユーザー体験を損なう「静かなるインシデント」になり得ます。何か問題が起きてから調査するのではなく、日常的にシステムの健康状態を把握し、問題の“兆候”を捉える仕組みが必要だと感じていました。
― そこでMackerel APMの導入を検討されたのですね。選定の決め手は何だったのでしょうか？
太田氏: 社内で提供しているサービスだからというのももちろんありますが、決め手は大きく二つあります。一つは、チームが日常的に使っている場所に、パフォーマンスという新しい視点を追加できることでした。
GigaViewerチームでは、サーバーのメトリック監視に以前からMackerelを利用していました。インシデントが発生すれば、まずMackerelのアラートを確認します。その慣れ親しんだ場所にAPMのタブが加わることで、パフォーマンス分析への心理的、物理的なハードルが劇的に下がると考えました。
メトリック見てる隣にAPMも出てるので、じゃあ見てみようか、となる。このハードルの低さは大きなメリットでした。タブを押せば見えますからね。
もう一つの決め手は、Mackerel APMがOpenTelemetryという標準規格に準拠していることでした。これは5年、10年先を見据えたサービス開発を行う上での「未来への投資」です。
OpenTelemetryは、比較的新しいミドルウェアやソフトウェアでの対応が進んでいます。今後我々が新しい技術を導入する際に、テレメトリ情報の収集をスムーズに行える可能性が高い。特定のベンダーにロックインされることなく、将来にわたってシステムの可観測性を担保できる標準規格の力は非常に魅力的でした。計測はサービスのコアロジックではないので、最悪差し替えが効くという安心感もありましたね。
― 実際にMackerel APMを導入してみて、チームにどのような変化がありましたか？
太田氏: 一番の変化は、チーム内にパフォーマンスを「定点観測」する文化が生まれたことです。X-Rayを使っていた頃にはなかった「定期的なパフォーマンスレビュー会」が自然と始まりました。
今では月に一度、各開発ユニットの代表者が集まり、MackerelのAPM画面を一緒に眺めて「先週と比べて大きく傾向が変わっている部分はないか」「新しく上位にきている処理はないか」などを確認する時間を設けています。
この活動がきっかけとなり、開発者一人ひとりが「自分たちがリリースした機能のトレースを、リリース後に確認してみよう」という活動も起き始めています。これは良い変化でしたね。
本番じゃないものは、本番じゃないんですよ、本当に。テスト環境では見えない部分も本番トラフィックが発生すると出てくるので、やっぱりリリース後にもちゃんと見るっていうのは大事だなと思いますね。
定点観測を始めたことで、これまで見過ごされていたかもしれない問題をいくつか発見できました。
特に印象的だったのは、CDNのキャッシュ設定が意図した通りに機能していなかった点を発見した事例です。月次レビュー会でAPMの画面を見ていたところ、あるエンドポイントのトレース数が桁違いに多いことに気づきました。本来、そのリクエストはCDNでキャッシュされ、バックエンドにはほとんど届かないはずだったのです。
本来トレースで取れちゃいけないはずのもののトレース数がやたら多かったので、これ怪しいな、と。キャッシュが効いていなかったら、人気コンテンツの公開時にシステムが落ちていた可能性もありました。
他にも、データベース接続時に毎回3回発行されていたSQLを1回にまとめることで、全てのリクエストを10ms高速化した事例もあります。また、開発者なら誰しも経験がある「N+1問題（データベースクエリがアクセスが増え、アプリケーションの応答が遅延する問題の一種）」も、トレース画面を見れば視覚的に分かりやすいため、レビューをすり抜けてしまった場合でも迅速に発見し、修正するのに役立っています。
APMによって、パフォーマンスに関する議論の質も変わりました。以前は「なんだかこの機能、遅い気がする」といった感覚的な話になりがちでしたが、今では具体的なデータをもとに会話ができるようになりました。
もちろん、課題が見えたからといってすぐに改善できるわけではありません。日々の開発タスクとの優先順位付けはまた別の課題です。
余裕があればその遅いねって言っている箇所のボトルネック解消のタスクを消化できるといいなと夢見ながら数ヶ月過ごしてるところですね。
それでも、チームとしてどこにパフォーマンス上の課題があるかを共通認識として持てるようになったのは、大きな進歩です。
太田氏: 理想としては「本番環境にも開発環境と同様にリリースできる体制」を構築したいと考えています。今でも開発環境にはGitHub上でPull Requestをマージしたらデプロイされるようにしています。本番環境でも同様のフローが実現されているということは、テストやレビュー、そしてリリース後の状態監視といった、開発運用に関わる様々なフローが高度に整備されている証です。
運用環境への変更を安定して行うには、リリース後の状態を即座に、かつ正確に把握できる仕組みが不可欠です。Mackerel APMは、そのための有効なツールの一つになるでしょう。
Mackerelチームには、今後もAPMの機能開発を加速させ、我々のようなユーザーからのフィードバックを迅速にプロダクトへ反映してくれることを期待しています。実際に、GigaViewerのようなマルチテナントサービスで「特定のテナントに絞ってトレースを見たい」という要望がすぐに実装され、新規テナントのリリース後の確認が非常に楽になりました。これからも、現場の声を反映した開発を続けてほしいですね。