New Relic Advent Calendar 2017 12日目。
今日は、実践的な内容ではなく、アプリエンジニアとインフラエンジニアにおけるコミュニケーションの話。
New Relic APM を組織で使うことで、アプリエンジニアとインフラエンジニアのコミュニケーションが促進され、よりよい関係を築けるようになるよという、ちょっとエモい話。
サービスを開発している組織では、(サーバーサイド)アプリ開発とインフラでチームが分かれていることがよくあると思う。特に規模が大きくなればなるほど。最近は DevOps とかの関係もあって昔ほどは両者の分断はなくなった気がするけど、チームが分かれていれば、多少は壁はある。役割が違うからね。これはしょうがない。
で、どういうときにコミュニケーションが必要かというと、例えば、本番サービスのパフォーマンスが低下してきたときに、それが、サーバーリソースの問題なのか、アプリコードのロジックや SQL の問題なのか調べてなくはいけない。大概パフォーマンス低下や監視の責務はインフラチームにある。でもインフラチームは当たり前だけど、そんなにアプリ自体の細かいコードについては詳しくない。で、パフォーマンス低下したとき、サーバーリソースには問題なさそうだと分かり、どうやらアプリの何かがおかしいのでは？とあたりを付けたとする。でも、アプリの細かいところまでは知らないので、調査はアプリチームに依頼することになるよね。で、アプリチームはほんとかなぁ。とか思いつつ調べたりする。で、最終的に、アプリには問題が見当たらず、サーバーの問題だっとわかったとする。これは気まずいよね。一回くらいならしょうがないと思うかもしれないけど、数ヶ月、数年運用してたら、それはそれなりに起こるよね。すると、段々、インフラチームも頼みづらくなるし、両者の関係も良くなくなっていく。ホントは協力して解決すべき問題なんだけどね。（そんなことはみんな分かってはいると思うけど）
こういったことが起こる原因の一つは、両者が情報を共有する場がないこと。同じ情報を見て、議論できれば、そこまでギスギスしないかもしれない。情報が一方方向で行ったり来たりするのが問題。この情報を共有できる場が、New Relic APM なんです。New Relic APM があれば、アプリの状態SQL レベルまで、ウェブ UI 上で見ることができる。アプリのどの処理にどれくらい時間がかかっているかは、インフラチームでも知ることができる。そのため、パフォーマンス低下の原因になってそうな処理はインフラチームが New Relic APM を見て、あたりをつけ、具体的にどの処理が、何秒掛かっていて、遅いから原因を調べてみて、とアプリチームに依頼できる。アプリチームも、具体的に情報がわかっているから、納得できるし、調査もスムーズにできる。で、修正した結果、パフォーマンスが改善したかも、New Relic APM を見れば知ることができる。こんな感じで、New Relic APM がアプリチームとインフラチームの情報共有の場となって円滑なコミュニケーションが行えるようになる。
さらに、SQL までわかるので、インフラチームだけでも、SQL を見て、Index がないので遅くなっているとか、SQL の組み方が悪いから遅いとかまであたりを付けることができる。
こういった感じで、コミュニケーションをしていくと、本番でのパフォーマンスにそこまで意識してなかったアプリチームも、パフォーマンスを意識せずにはいられないし、ブラウザで、New Relic にアクセスすればすぐにパフォーマンスわかるので、開発時にもパフォーマンスを意識するようになっていく。そうると、パフォーマンス品質は上がっていき、そもそもパフォーマンスに関する問題が減って行くというサイクルになる。
このように、New Relic APM を導入することで、インフラチームとアプリチームのコミュニケーションの場にもなるし、ただそこにあってパフォーマンスが可視化されているだけで、パフォーマンス向上に役立つという状況にもなり得るのだと知ってもらえたと思う。(なんでみんな New Relic APM 使おう)
番宣
ここでした話はどこの企業にも起き得ると思うけど、そんな話をしてくれたのがクラウド名刺管理サービスの Sansan さんの Sansan チーム。New Relic の Sansan さんの事例紹介は New Relic のケーススタディページ にあるので是非、ご覧ください。