目次

• 自己紹介と課題
• データドック APM とは？
• 導入手順
• データドック APM ダッシュボードの紹介
• データドック APM のまとめ
• ドロー部での活用事例
• チームでの運用と改善サイクル
• 全体のまとめ

自己紹介と課題

データドック APM で始めるラベルアプリケーションのパフォーマンスチューニングというタイトルで発表させていただきます。よろしくお願いいたします。

簡単に自己紹介をさせていただきます。私、小倉キロと申します。株式会社ドローグという会社で、主にPHPとLaravelを使って開発をしているエンジニアです。パーソナルスタイリングサービスの「ドロー部」というサービスを作っています。ご興味ある方は是非「ドロー部」で検索してみてください。

突然ですが、Laravelで開発していると、こんなコードに遭遇することがあるのではないでしょうか。こんな感じで、$resultに6つのプロパティを混ぜるために、$resultに定義を追加していて、そのプロパティがデータベースアクセスが必要な可能性があるような記述になっているということです。この$resultを使って一覧取得APIを作る場合、こんな感じの実装になると思うのですが、この実装だと若干問題があります。どんな問題かと言うと、$resultで指定したプロパティを取得する時に10回クエリ発行してしまう、いわゆるN+1問題が発生してしまうという問題です。もちろんeager loadingをすればいいだけなので修正自体は容易ですが、$resultがクエリを発行しているという状態に気付かずに、このような実装になってしまうこともあるのではないでしょうか。

上記の例からもわかるように、Laravelを使った開発では、$resultがDBに行ってくれすぎて、呼び出し先のことをかなり意識しないと簡単にN+1問題を起こしてしまいます。先ほどのようなレベルであれば開発中に気付くことは可能かもしれませんが、リレーションがたくさんあるような場合だったりすると、気づけないこともあります。Laravelデバッガーを使ったとしても、データ数の少ないローカル環境だと開発中に気づけないこともあるのではないでしょうか。

あまりLaravelを使った開発において、開発中にN+1問題を完全に排除することは難しいのではないかなと思っています。開発中に気づけないので、パフォーマンスの悪いAPIをリリースしていたり、過去にリリースしたAPIがデータの増えることによってパフォーマンスが悪くなったりということが起き得るのではないでしょうか。実際ドロー部でも、こういったパフォーマンスの悪いAPIをリリースしてしまっていたことがあり、自分で本番を触ることで気が付いたり、PDM経由で「なんか表示まで遅いよ」と言われて初めて気づくなどがありました。APIが増えてくると、体感速度が遅くなることからユーザの離脱を招いたり、サービス劣化につながる可能性もあるので、リリースされたAPIのパフォーマンスやボトルネックを確認できるようにしておいて、問題の発見・修正を瞬時に行えるような環境を作っておくべきなのではないかと思っています。

同じような課題感を抱えている方もいらっしゃるんじゃないかなと思うんですけれども、どう実現するべきか悩まれている方もいらっしゃるんじゃないかなと思います。

実際のドロー部でもどうしようかという話をしていまして、実際どうしたかというと、タイトルにもある通りのDataDog APMを導入してみました。DataDogを元々使っていたこともあり、とりあえず入れてみたのですが、非常に良かったので、今日はこの話をしていければと思っております。

前置きが長くなってしまいましたが、このセッションではDataDog APMについて、機能や導入手順、実際の画面で見える内容などについてお話しした後に、ドロー部での活用事例についてお話ししていきたいと思います。このセッションのゴールとしては、同じ課題感を持っている人が自分のプロダクトにDataDog APMを入れてみたいと思えるようになることとしたいと思います。DataDog APMを全く使ったことがない人向けの内容になりますので、普段からDataDog APMを使っているような人には若干退屈な内容かもしれません。それでは早速DataDog APMについてお話ししていきます。

データドック APM とは？

そも、APMって何ですかというおさらいなんですけれども、Application Performance Monitoring もしくはManagementの略語です。アプリケーションのパフォーマンスを監視・管理すること、や監視を行うツール自体を指している言葉です。APMを導入することで、本番で運用されているアプリケーションのパフォーマンスが可視化され、原因の特定や修正結果の確認が容易になります。例えば、N+1問題や遅いクエリ、遅いロジックなどが一目瞭然になります。

じゃあDataDog APMとは何かというところなんですけど、名前の通りDataDogの一機能として提供されているAPMのことです。DataDogのウェブサイトによると5つほど特徴がありまして、順番に説明していきます。

まず1つ目が、end to end トレーシングと呼ばれる特徴で、端末で動くアプリ上の挙動からデータベースに発行されるクエリまでが全て紐づくログだとかメトリクスなども含めて全てが自動的に付くという特徴です。2つ目が、サンプリングがないという特徴です。データは全て保存されていて、検索や分析が可能な状態になっています。3つ目が、コードレベルの可視性です。ソースコードレベルでの処理のどこがパフォーマンスが悪いかということを確認することができます。ただし、PSPはまだまだベータ版でして、利用できるまでに少し時間がかかりそうです。4つ目は、デプロイメントの追跡です。パフォーマンスだとかエラーレートといった様々なデータをリリースバージョンごとに比較することができます。最後が自動インスツルメンテーションです。様々な環境・言語・フレームワークに対応していて、導入が非常に簡単になっています。もっと詳細が気になるという方は公式のWebサイトを確認ください。

導入手順

次に導入手順についてお話します。導入は非常に簡単でして、2ステップで完了します。まず、DataDog Agentと呼ばれる、DataDogにデータを送信するデーモンを動かします。こちらはLaravelが動いている環境からアクセスできる環境で動かす必要があります。次に、Laravelを動いている環境にDataDog PHP Tracerと呼ばれる、いい感じにデータを収集するPHP拡張を入れます。基本的にはこれだけで完了するほど簡単です。動作環境に合わせてセットアップ手順がかなり丁寧に記述されておりますので、詳しくは公式のWebサイトをご参照ください。

データドック APM ダッシュボードの紹介

次に実際のダッシュボードについてお話ししていきます。こちらはドロー部の本番環境とつながっているダッシュボードなのですが、諸事情で一部モザイクをかけさせていただいております。ご了承ください。

まずこちらのエリアですが、時間毎の秒間のリクエストを見ることができます。こちらは時間毎のエラーの数が見れます。リリースバージョンごとに色が違っており、どのリリースでエラーが多かったかということが一目瞭然になっています。こちらでは時間毎のレイテンシが見れるようになっていまして、どこでボトルネックがあったかということがわかるようになっています。サービスの割合も分かるようになっていまして、データベースアクセス、PHPの処理の割合などが見えます。レイテンシの分布も見れるようになっています。リリースバージョンごとのパフォーマンスを見れるようになっていまして、そのバージョンでどれくらいのリクエストがあって、どれくらいのエラーレートで、どれくらいのレイテンシだったという情報をリリースバージョン間で比較することができます。エンドポイント毎のパフォーマンスも見れるようになっておりまして、レイテンシをソートしてパフォーマンスの悪いAPIを抽出したり、文字列で検索して特定のAPIを確認したりできます。単純な平均だけでなく、パーセンタイル統計と呼ばれる「全体の99パーセントのリクエストはこれくらい」みたいなデータも見れます。エンドポイント毎のダッシュボードも当然用意されておりまして、先ほどのダッシュボードと同じ情報が見えてきます。すべてのリクエストが保存されているので、一つ一つのリクエストの結果を確認することも可能です。詳細画面では、どのタイミングでどういう処理が呼ばれているかというところまで見ることができます。この画面では、2.37秒のタイミングで特定のテーブルに対して特定の条件でSELECT文を発行しようとしているというところまで見ていることが分かるかと思います。「Span」と呼ばれる、DataDog APMが自動で区切った特定の期間における作業単位一覧を見ることも可能です。こちらでSpanの実行時間や実行回数、実行間隔などを確認することも可能です。もちろん各項目でソートも可能なので、やたら実行回数の多い処理や実行に時間かかっている処理を抽出することも可能です。こちらにあるように、ログやメトリクスと紐付けることも可能です。以上がダッシュボードの紹介でした。DataDog APM、いい感じということがわかっていただけたのではないかと思います。

データドック APM のまとめ

この章のまとめです。APMを入れると、APIのパフォーマンスやボトルネックを把握できるようになります。DataDog APMは機能豊富で簡単に導入可能なツールです。DataDog APMダッシュボードでは、問題の発見・特定を行うための様々な情報を確認することができます。以上、ご理解いただけたのではないかと思っています。DataDog APM、皆さんのプロダクトにもすぐにでも入れたいという気分になってきたのではないでしょうか。

次はより具体的な利用イメージを持っていただくために、ドロー部での利用事例などお話ししていきたいと思います。

ドロー部での活用事例

ということで、ドロー部での活用事例です。まず実際に導入した時の例を用いて、チューニングの具体的なやり方をご紹介していこうと思います。この画像のように「hogehoge APIのパフォーマンス悪いからよろしく」と言われた時の話です。APIのパフォーマンスチューニングということで、まずそのAPIのダッシュボードを見に行きます。一覧から特にパフォーマンスが悪いAPIを見つけてきて、詳細を確認します。この詳細ページでは、緑がデータベース、濃い紫がPHPの処理を表しています。データベースの処理が大半を占めており、かつPHPの処理も大部分がデータベースの呼び出し処理のようなので、データベース側の処理に問題がありそうということがわかるかと思います。1を見ると999回以上呼ばれており、明らかに何かが呼ばれ過ぎているということが想像できます。ちなみに、保存するSpanの数の上限はデフォルトで999回でして、ドロー部ではデフォルトの設定をそのまま使っているため、この時は1000以上のSpanは表示されなくなってしまっています。上限値は変更可能ですので、もし999回を頻繁に超えるようになってきたら、設定を変更してもいいかもしれません。

Spanの詳細を見ていきます。呼び出し回数順にソートすると、200回以上呼び出されているクエリに気づきます。こちらは呼び出し間隔も狭く、おそらく動的プロパティが呼ばれていてN+1が発生してそうだなということが想像つくのではないでしょうか。実行時間順にソートした場合はこのようになります。こちらを見ると、やたら時間がかかっているクエリはなさそうなので、遅いクエリはなさそうだということがわかるかと思います。この実行時間は、すべてのSpanの実行時間の合計となりますので、例えば一番上のクエリで言うと、204回処理が呼ばれた時間が1.75秒ということを表しています。

以上の情報から、該当のAPIが遅いのはN+1問題によるものである可能性が高いということがわかるかと思います。実際本件に関しては、eager loadingされていないところがありましたので、eager loadingするように修正してデプロイしました。

結果の確認は、リリースバージョンごとのレイテンシのグラフを見ることで行います。新バージョンと旧バージョンの差分を見ていただけるとわかるように、50%タイルのレイテンシで2倍弱、90%タイルを超えてくると3倍以上速くなっていることがわかるかと思います。N+1が解消されているかの確認のため、Spanリストも見てみます。Spanの数を数えてみると、N+1っぽいものがなくなっていることがわかり、eager loadingを入れる修正がうまく効いていたということがわかるかと思います。以上がチューニングの流れとなります。実際パフォーマンスの悪いAPIは、遅いクエリやN+1問題となっていることが多く、見えるかさえできれば対処自体は、eager loadingしたり、インデックスを張ったりするだけで非常に簡単な場合が多いです。

チームでの運用と改善サイクル

ここまで具体的な作業手順に関してご説明させて頂きましたら、ここからはチームとしてどのような体制でパフォーマンスの悪いAPIを発見し、修正し続けているかということに関してご紹介していきたいと思います。

ドロー部では、「ミートスプリントチームでAPMを眺める会」というものを実施していまして、エンジニア全員でダッシュボードを眺める時間を取っています。具体的には、すべてのAPIをレイテンシ順にソートして、パフォーマンスが悪い、パフォーマンスの悪そうなAPIを探したり、リリースによって新しく出たエンドポイントや修正が入ったエンドポイントを個別に確認し、前バージョンと比べて遅くなっていないかなどを確認します。スプリントプランニングで、それまでに出た課題について、他の施策との優先度を相談しながら、各エンジニアに割り当てていきます。そして、各エンジニアが詳細に確認・修正を行い、デプロイし、また「APMを眺める会」で結果の確認や新しい課題がないかということをチェックしていきます。このサイクルをぐるぐると回して、パフォーマンスの悪いAPIが出ていないかということを監視しつつ、改善できるものを順番に潰していくということをやっています。

このような体制で運用した結果、4ヶ月前（計測を始めたタイミング）と比べて、すべてのAPIのレイテンシの平均を50%、レイテンシを見ても2倍以上早くすることができました。改善サイクルがうまくワークしている様子が伝わるのではないでしょうか。

全体のまとめ

全体のまとめです。Laravelで開発していると、どうしても低パフォーマンスなAPIをリリースしてしまうことは避けられません。ただし、APMを使うことで、低パフォーマンスなAPIの存在の把握、問題の特定が容易になります。問題さえわかれば、修正自体は容易なことが多いです。DataDog APMは導入簡単で効果が非常に大きいと思いますので、まずは入れてみましょう。というところで、本セッションのまとめとさせて頂ければと思います。ご静聴ありがとうございました。最後に宣伝なのですが、ドロー部でもエンジニアを絶賛募集中です。少しでもご興味ある方、お気軽にご連絡ください。