New Relic Advent Calendar 2017 14日目。
デジカの宮澤です。
先日予告したように、本日からこのアドベントカレンダーを今年もやることにした理由である New Relic の使い方をまとめた入門書的なものを目指した記事を書いていく。
理論編、基本編、応用編の3部構成。各部だいたい2-3記事を予定。
- 理論編: アプリケーションパフォーマンス監視とは何か？なぜ必要なのか？ New Relic とは何かを説明する。具体的な使い方は説明しない。
- 基本編: New Relic アカウントの作成から、最低限のインストール手順、最初に導入後にやっておくべき設定やアラート、各種チャートの読み方を説明。
- 応用編: 横断的なパフォーマンス分析から独自データを送信したサービス固有のパフォーマンス分析のやり方を説明。New Relic Insights を使ったより詳細なデータ分析など。
初回の今回は、アプリケーションパフォーマンス監視とは何か？なぜ必要なのか？ 導入することのメリットを説明していく。
理論編
アプリケーションパフォーマンスの監視とは何でしょうか？ なぜ必要なのでしょうか？ サーバー監視はどこの企業もやっています。ツールやサービスも非常に多くあり、何もしていない企業の方がすくないのではないでしょうか。しかし、アプリケーションパフォーマンス監視は、現状そこまで浸透してはいません。アプリケーションに関する監視はしていても、ログ監視やエラー監視くらいの企業が多いのではないでしょうか。
まずは、アプリケーションパフォーマンス監視を導入することの魅力を語っていく。
アプリケーションパフォーマンス監視はなぜ必要なのか？
現在のビジネスにおいてインターネット上でサービスを展開していない企業の方が少ないのではないでしょうか。今後も増加の一方でしょう。昔は、インターネット上でサービスを展開している事自体で競争に勝てた時代もありましたが、現在はそうではありません。ある製品を買いたい場合やある情報が欲しい場合に、あるサイトでしか手に入れられないという状況はあまりありません。競合は至るところにいます。そうなってくると、他で手に入らない情報や製品、価格が安いなどのビジネス的な側面はもちろんですが、サイトの使い勝手やパフォーマンスも競合に打ち勝つための非常に重要な要素になってきます。
特にスピードに関しては、Google によるとサイトの表示が0.5秒遅くなるとアクセス数が20％低下するそうです。かなり昔の調査結果ですが、Amazon では0.1秒の表示の遅れで1%の売上が減少したそうです。このようにスピードはユーザー満足度に直結するものであり、ビジネスにとって非常に重要なのです。最近では、日経電子版のパフォーマンス改善が話題になりましたが、スピードが重要であるという認識はもはやあたり前の状況になりつつあります。インターネットビジネスにおいて、速さが正義なのです。
では、そのスピードを速くするにはどうすべきなのでしょうか？ そもそもあなたが運営しているサービスはユーザーが満足するパフォーマンスを出しているでしょうか？ そのためには、まずは現状を知る必要があります。『Don't guess, measure!（推測するな、計測せよ！）』の精神です。
現状を知るためにアプリケーションパフォーマンス監視が必要なのです。アプリケーションパフォーマンス監視の導入によって、現在を知り、そして改善を行った場合に、その結果も知ることができます。また、異常が発生した場合も素早く検知することができます。では、アプリケーションパフォーマンス監視とは具体的に何でしょうか？ 次からこの問いに答えていきます。
アプリケーションのパフォーマンス監視とは？
アプリケーションのパフォーマンス監視が何であるかは、New Relic の戦略アーキテクトである Lee Atchison 氏の著書「Architecting for Scale - High Availability for Your Growing Applications」が参考になります。(ここから一部抜粋の無料版が読めます。)
この本の副題は「成長し続けるアプリケーションを高い可用性で維持する方法」です。如何に安定した(高可用性）状態でアプリケーションをスケールさせていくためのノウハウを Amazon や New Relic での自身の経験を元に記しています。(Lee 氏の前職は Aamazon)
アプリケーションのパフォーマンス監視に関係の深い内容として、この本の "Five Focuses to Improve Application Availability "という章で、アプリケーションの可用性を改善するためにフォーカスすべき5つのこととして、以下を挙げています。
- Build with failure in mind (故障を想定して構築する)
- Always think about scaling (常にスケール化を意識する)
- Mitigate risk (リスクを軽減する)
- Monitor availability (可用性を監視する)
- Respond to availability issues in a predictable and defined way (事前に問題を想定し、対策を決めておく)
この中の4つ目「可用性を監視する」をさらに見ていくと、可用性の監視とは以下ことだと述べています。
アプリケーションに問題があったとしても、それを認識できない限り、問題に気付くことはできません。ソフトウェアが外部からどう見えているかだけでなく、内部の監視も適切に行う必要があります。
アプリケーションにベストな監視内容は、アプリケーションの仕様やニーズによって異なりますが、概ね以下の機能は必須です。
- サーバー監視: サーバーの健康状態を監視し、運用が効率的に維持できるようにする
- 設定変更の監視: システムの設定を監視し、いつ変更されたのか特定できるようにする
- アプリケーションパフォーマンスの監視: アプリやサービスを監視し、期待どおりに動作していることを保証できること
- 外形監視: ユーザーが問題に気づく前に問題を把握できるように、アプリがユーザーの期待どおりに機能しているかを調査できるようする
- アラート: 問題発生時に適切な対応者へ連絡できること
-- 中略 --
アプリケーションやサービスの監視を始めたら、パフォーマンスの傾向を確認してください。傾向を把握できたら、外れ値(異常値)を認識できるようになります。この外れ値は潜在的な問題となる可能性があります。アプリケーションが障害を起こす前に、外れ値を発見したら監視ツールのアラート通知の設定を行っておきましょう。さらに、システムの成長を監視し、継続的にスケールできる状況を維持しましょう。
一口にアプリケーションのパフォーマンス監視といってもいろいろ監視が必要だと分かって頂けたかと思います。つまり、アプリを安定した状態(パフォーマンスも含め)で成長させていくには、常に現在の状態を知ることができること。そして、異常が発生したときにそれを迅速に検知し、対応できる環境が整っていることが重要なのです。
ここで上げた監視内容を New Relic を使ってどのように行うかは後で説明します。
アプリケーションパフォーマンス監視製品を導入しないことのデメリット
上記でアプリケーションのパフォーマンス監視とは何を監視するかは分かっていただけかと思います。では、そういった機能を提供するサービスなり製品を導入していない場合はどのようなデメリットがあるでしょうか？逆説的ですが、デメリットを説明することで、アプリケーションのパフォーマンス監視製品を導入するメリットを感じてくれたらと思います。
上記でも述べましたが、アプリケーションのパフォーマンス監視をしていないということは、現状を知るすべを持たないということです。
パフォーマンスに関する問題がアプリケーションで起きているとします。しかし、サービス自体はダウンはしていません。運用チームは気づきません。ある時ユーザーからカスタマーサポートあてにクレームが入ります。そのとき、運用チームは何ができるでしょうか？ログを確認したり、クレームで言われたページにアクセスして、再現するくらいしかできないのではないでしょうか？ログを見るにしても、大量にあるため、どこが原因なのかあたりを付けるだけでも、時間がかかることがあるでしょうか。サービスで再現を試みても環境が違ったりと再現しないかもしれません。機能的なバグなら再現するかもしれませんが、パフォーマンスの問題は後からの再現は難しいことが多いと思います。
このように、パフォーマンスの問題は気づきづらく、原因の特定や追求がバグなどに比べてしづらい問題です。それに加えて、パフォーマンスが悪い状態が続けば、ユーザーからの信頼度は下がり離れていってしまうでしょう。一旦、遅いサイトと認識されたら、また戻ってくる可能性は低いです。このように、パフォーマンス問題に早期に対応できない環境というのは、ビジネス的にも機会損失、ユーザー満足度の低下につながってしまいます。
SaaS のような外部サービスを利用するメリットは？
アプリケーションのパフォーマンス監視製品の導入メリットが分かってもらえたところで、じゃあ、導入してみようか。となったとします。では、自前でアプリケーションのパフォーマンス監視の環境を構築するのと SaaS のような外部サービスを使うかのどちらを選ぶべきでしょうか？
以下でメリットとデメリットを挙げています。だた、自分たちの組織にどちらが合っているかを検討する際は、それだけでなく、現在のソフトウェアを取り巻く現状も考慮したほうがよいでしょう。現在のシステム開発は非常に複雑になりつつあります。近年は特にインフラ周りの技術進歩がめざましく、マイクロサービス、コンテナ、サーバーレスなど開発環境が日々進化しています。また、マイクロサービスまでいかなくても、昔のようにモノリシックな大きなアプリでビジネスが完結する時代でもありません。そうなると、アプリケーションの監視も様々な環境(OS、言語、フレームワーク等)、組織に柔軟にそして迅速に対応できる必要があります。そうしないと、一旦、導入したみたはいいが、結局使い物にならないという状況になってしまいます。
では、それぞれのメリットとデメリットを挙げてみます。
自前で環境を構築する場合
メリット
- 柔軟な監視が可能。
- 外部にデータを出さなくて良い (セキュリティをあまり気にしなくて良い。社内を説得する必要がない)。
デメリット
- 構築コストがかかる。
- メンテコスト(サーバー費用、人件費)がかかる。
- 特にサービスが成長に合わせてインフラの構成や仕組みを見直す必要がある。
SaaS を利用した場合
メリット
- すぐに使える。
- 機能やインフラのメンテが不要。
- (サービスにもよるが）最新のフレームワークや言語、技術トレンドに追随した機能の監視が可能(今だと Docker とか)。
- 環境(オンプレとかクラウドとか）を考慮する必要がない。
デメリット
- 費用がかかる。
- 外部にデータを送信する必要がある(セキュリティ懸念がある。社内の説得が難しい。めんどくさい。)。
- カスタマイズが限定的。
すぐに使えるのは非常に大きなメリット
SaaS 型を利用する最大のメリットのひとつは、すぐに使えることです。製品にもよりますが、New Relic のような製品であれば、使おうと思ったら、その日から使えます。自前で構築するとなると、そもそも仕様を決めたり、環境を用意したりとそこそこの構築コストがかかります。
トータルのコストは SaaS に軍配
もう一つの大きなメリットは、中長期的なコストは SaaS の方が安くなるということです。なぜなら、最初に自前で OSS などで低コストで環境を構築できたとしても、サービスが成長するに連れ、それらをカバーできるように監視環境もメンテが必要となります。特に、インフラの技術トレンドが急速に変化している現在において、それらのトレンドにサービスだけでなく、監視環境も追随するのは余計なコストになるでしょう。追随できないようであれば、それはもはや価値のない監視となります。正確な情報を出さない監視製品は、誤った判断をくだす可能性があるため、むしろ有害です。また、専門の人がいた場合に、その人が退職したりしたときの引き継ぎなどのコストもばかになりません。
SaaS を使っていれば、メンテコストは SaaS 側が取ってくれます。そのため、監視機能自体のパフォーマンスを気にすることなく本業のアプリ開発に集中できるようになります。
まとめ
以上でアプリケーションのパフォーマンス監視についての説明は終わりです。明日は、New Relic とは何か、本日説明したアプリケーションのパフォーマンスを New Relic を使ってどのようにできるかを紹介します。