こんにちは。GCI本部の屋田と申します。
今回は「システム保守がもっと楽になればいいのに」と願う３人の3年目社員が、
保守業務を効率化してくれるDynatrace（ダイナトレース）というツールをご紹介します！
皆さま、システムの保守ってどういったイメージがありますか。
私はサーバーシステムの保守を担当しているのですが、これがなかなか大変です。
インシデントが発生したら、原因を調査する為にログを漁り、データを漁り、、
経験がまだまだ浅い私は、原因は掴めないのに時間だけが過ぎていく切ない体験を何度か味わいました、、。
どうにかして、もう少し楽に早く調査ができないものかと思っていたところ、
Dynatraceという便利ツールがあるとのこと。
どうやらログの情報を集約してくれて、グラフでわかりやすく可視化してくれて、
しかも経験者に属人化しない。
とっても素敵ですね。
実際にDynatraceを触っている石谷・佐々木のもと、どういった調査ができるのか検証を実施しましたので、ご紹介させてください。
1. そもそもDynatraceとは
Dynatraceとは、WEBサイトやアプリケーションをリアルタイムで監視し、
システムの安定稼動と問題の早期発見を目的としたツールになります。
分析したいサーバーにOneAgentを導入しておくことで、監視対象の各ホストで実行され、様々なログやリソースの情報をAIが自動的に収集してくれます。
つまり、問題が発生している箇所・根本原因を提示してくれるので、原因調査の工数を削減できるのです。
また、Dynatraceのレイヤーは次の通りになっています。
各階層によって監視している要素が異なっているため、保守の目的に応じた調査が可能になります。
実際に各レイヤーの画面も見てみます。
まずはApplicationの画面です。
ここから確認したいアプリケーションを選択することで、各アプリの使用ユーザーがどのような操作をしたのか、レスポンスなどのパフォーマンス分析、ユーザーの満足度等の詳細な分析結果を確認することができます。
次にServiceの画面です。
こちらの画面では、対象アプリやサイトごとに、リクエスト数やエラー発生率を提示してくれます。
また、どのサービスでエラーが発生しているのかも提示してくれる為、原因調査の効率化が期待できます。
最後にProcessesとHostの画面です。
ホスト毎のCPUやメモリ数を管理、分析する画面になります。
Host画面で確認できるメトリクスを、Processesではさらに詳細に確認することができます。
ソフトウェア、ハードウェアの管理/分析が一つのツールで確認できるので便利です。
簡単にどういった分析ができるのかご紹介しましたが、いかがだったでしょうか。
とても便利そうですよね。
Dynatraceの特長は特許技術「PurePath」により全てのトランザクションを可視化してくれることです。
これによって、トランザクションに遅延が発生したときなど、どこがボトルネックになっているのかをピンポイントで・素早く特定することができます。
ぱっと見で何となく用途が掴めるGUIも含め、誰でも使いやすそうですね・・！
その他にもAWSサーバー上でデプロイできたり、分析結果を元にダッシュボードを作成できたりと、様々な便利機能を備えているようです。
※下記サイトを参照させていただきました。
https://www.iim.co.jp/products/apm/dynatrace/
2. Dynatraceで原因調査をしてみよう
2-1. 従来の調査だと・・
それでは実際にDynatraceを使用して、サービスにインシデントが発生した際の原因調査をしていきたいと思います。
例えば、システムに通信障害が発生し、数分間利用できなくなるといった障害が発生したとします。
ちなみに、このインシデントの調査を従来の方法で実施した場合、ログを確認する作業から始まります。
大変ですね。目がちかちかします。
このログから短時間で必要な情報を収集し、原因を特定するのは、ある程度経験が無いと厳しそうです。
また、ログから得られる情報は限られており、サーバー環境やCPUの確認等は別途調査が必要になります。
2-2. Dynatraceで効率的に調査できるのか
Dynatraceはインシデントの検知自体もしてくれます。
「Problems」に表示されたインシデントをドリルダウンしていくことで、根本原因を探っていきます。
まずは、「Problems」をクリックし、「Root cause」が記録されている場合は内容を確認します。
緑色で表示されている箇所に注目すると、該当の時間にレスポンスタイムが延伸していたプログラムが2つあることがすぐに把握できます。１つずつ詳細を見ていきましょう。
①まずはアプリAの詳細です。
緑色のボタンを押下すると、そのプログラムに対するリクエスト数、レスポンスタイムがグラフで表示されます。
さらに下にスクロールすると、より細かく分析できるメニューが複数表示されます。
例えばView top web requestsを押下してみると、、
リクエスト数に絞った棒グラフが表示されます。（メトリクスは色々変更もできます。）
ここから、12:29-12:30頃にリクエスト数が急増していることが分かります。
時間幅を広くして、同日の他の時間帯と比較してみます。
やはり、12:30頃のリクエスト数が突出していることが分かります。
Details画面に戻って、今度はView PurePathsというメニューを選択してみます。
ここでは、リクエスト1件1件の詳細を確認することができます。
しかし、パラメータはマスクされていることが多いので、アクセス元までは特定できません。
②次に、アプリＢを見ていきましょう。
こちらも同様に、問題の時間帯のリクエスト数、レスポンスタイムをチェック。
しかし、こちらに関しては同日の他の時間帯と比較しても特別リクエスト数が多いわけではないようです。
①の大量アクセスによりサーバーに負荷がかかり、それに引きずられて、同時間帯に稼働していたこちらのレスポンスも悪化したのではないかと推測することができます。
改めて調査結果をまとめると、インシデントの発生原因は、12:30頃の、アプリAのリクエスト数の大幅な増加でした。ここまでの情報は、かなり短時間で把握することができました。ここからアクセス元などさらに詳細な情報をたどって行くには、別途アクセスログやアプリログを確認する必要があります。しかし、膨大なログだけを頼りに調査するよりも、まずDynatraceで原因箇所のあたりをつけてから、プログラム名・時間帯等でログを絞り込んでいくことで、格段に調査効率がアップしました！
★おまけの便利機能紹介★
Compare機能を使用すると、1日前、1週間前等の状況と比較することができます。
今回は、ちょうど1週間前の同時間帯と比較してみましょう。
リクエスト数、レスポンスタイムが平時より突出していることが一目で分かります。
3. 最後に
3-1. Dynatraceでのインシデント調査を通して
Dynatraceを使用してのインシデント調査、いかがだったでしょうか。
前章では検証方法を中心に説明してきましたが、ここでは今回の検証を通して私たちが感じた、Dynatraceの良かった部分をまとめました。
■良かった点
- ひたすらログを確認する場合と得られる情報は同じでも、データが自動で可視化されることで調査が容易で、データの示す傾向が理解しやすい。
- 上記に伴い、調査時間の短縮にも繋がった。
- 勘や経験に頼らずとも、誰でも容易に問題箇所を特定できる。また、ツール自体も直感的に操作できる。
属人化の傾向が低く、短時間である程度の原因が特定できる点が、経験が浅い私たちには特に便利だと感じました。
また、データの可視化については、自チーム以外の方に調査結果をお渡しするときや、顧客にシステムの使用傾向を提示する場合なんかも便利そうですね。
以上が今回の検証を通しての私たちの所感になります。
Dynatraceを使用することで、間違いなく保守調査が楽になりました。
3-2. 今後の展望
弊社では3～4年ほど前からDynatraceを導入し、インシデント調査に活用しています。
まだ一部WEBサーバーでの運用にとどまっていますが、今後、DBサーバーなど他サーバーへの導入も検討しています。
Dynatraceは複数サーバーにまたがったシステムの場合、各サーバーにAgentの導入をすれば、まとめて管理・分析をしてくれます。
つまり、下記のような保守の効率化が期待できるのです・・！
-
システム全体を俯瞰することができる
環境の差異なく一元的に稼働状況の確認をすることができます。 -
障害発生時の原因切り分けがSQL側かDBリソース側かを確認できる
例えば、DBサーバーで処理が遅いリクエストを発見した場合、該当SQLに時間がかかっているのか、
リソース高負荷等による処理遅延なのかを切り分けすることが可能です。
個人的には原因SQLの特定と、原因切り分けを自動で実施してくれるというのは、ソースを確認しながらの調査ですと時間がかかってしまう為、大変ありがたいです。
統括的に管理できるということは、より迅速な調査に繋がりますね。
上記以外にも、Dynatraceの運用範囲の拡大によって期待できる効果については、まだまだあると思っています。
今後の運用拡大に伴う効果については、実際の保守業務を通して、引き続き研究していきたいです。
最後までお読みいただき、ありがとうございました。