基幹業務システムへのAPMツール導入

ツール導入前の課題

基幹システムにおいて、フロントエンド／バックエンド両面の障害時調査や改善計画を立てる際に​取れる選択肢を増やすため、モニタリングシステムの導入を検討した。​

＜主な課題＞​

• アプリケーションが RESTful WebAPI 化されたことに伴い、​サーバ側のみの監視ではクライアント⇔サーバ間通信のボトルネックを検出することができない。​
• フロントエンドがSPAとなったことにより、パフォーマンス計測／UIエラー内容を検出することができない。​
• バックエンドのログ収集アーキテクチャがサーバーにファイル出力される形となっているため、​障害発生時の調査では、複数台のサーバから大量のテキストデータのログ収集を行うことになり、手間がかかっている。

どのような状態を目指していたか

• 導入したアプリケーションにおいて、APM(Application Performance Management)が行える状態であること​。
• フロントエンドのエラー収集／分析およびパフォーマンス測定が可能な状態であること​。
• インフラ監視、API結果（レイテンシ含む）監視、他CI/CD等の結果等をまとめてダッシュボードで確認できること​。
• モニタリングで見える化したボトルネックの検出、および課題化と解決の段取りまで改善サイクルとして確立していること​。
• 開発プロジェクトにおけるKPIをAPMから観測可能な結果で確認できること。

• Datadog
• Prometheus
• Azure Monitor​
• JENNIFER

• フロントエンドモニタリング
  • エラー分析
    • エラーログからエラー原因が特定可能な情報が確認できるか（再現できる情報があるか）
  • レスポンス計測
    • パフォーマンスNG箇所の特定および計測ができるか（JS/レンダリング）
  • 分散トレーシング
    • ソリューション単位での分散トレーシングが確認可能か
  • ログ収集
    • ERROR以外の任意ログ出力が可能か
  • トレース
    • フロントでのアクション起因のトレースが可能か（パフォーマンス劣化特定後）
• バックエンドモニタリング
  • エラー分析
    • エラーログからエラー原因が特定可能な情報が確認できるか（再現できる情報があるか）
  • レスポンス計測
    • パフォーマンスNG箇所の特定および計測ができるか
  • ログ収集
    • ERROR以外の任ログ出力が可能か
  • トレース
    • APM,エラーログから発信元（画面/他シス/ユーザ）の特定ができるか
• インフラモニタリング
  • ハードチェック
    • CPU/Disk/メモリ等の基本的なインフラ監視が可能か
  • NW通信量
    • クライアント側のNW情報を収集・確認可能か
  • クラウド連携
    • アプリケーションがクラウドに移行しても利用できるか（AWS/Azureが主要なターゲット）
  • DB監視
    • DB状態（CPUやセッション状態等）の監視が可能か
• 構築
  • インストール
    • インストール時の制約の少なさ（必要ライブラリ／NW等）
  • アプリ改修
    • 期待値を満たすために必要なアプリ改修のコスト見合い
  • クラウド移行
    • アプリケーションがクラウド移行する際の手間はどのくらいか
• 機能性
  • 導入影響
    • 導入したことによるアプリ影響（パフォーマンス等）
  • ログ保持
    • ログの保持期間は1年以上か（または代替手段があるか）
  • ダッシュボード
    • ダッシュボードの使いやすさ、見やすさ、作りやすさ
  • セキュリティ
    • IP制限できるか（もしくは代替方法があるか）
  • 権限管理
    • 適切な権限管理が管理者権限で出来るか
• その他
  • 他シス連携
    • 他システムで収集したデータの回収、他システムへ収集したデータの送信機能の有無
  • サポート
    • 問い合わせの際の手間やコスト
  • ライセンス体系
    • 通信料／台数／ページ数等、アプリケーションに相性の良いライセンス体系になっているか
  • コスト
    • 金額

検証観点において他ツールと比較し、総合的に有用性を確認できたため。

• フロントエンドモニタリング観点
  • フロントエラーやPageViewの速度評価など、求めてる確認点についてはあらかた確認可能。​
  • エンドツーエンドの分散トレーシングも可。
• バックエンドモニタリング観点
  • API別集計／エラー詳細／ログ関連付け全て対応可。​
  • カスタマイズでリクエストのBodyやHeaderを属性として取得／集計が可能。
• インフラモニタリング観点
  • 標準的なインフラ機能確認、およびクラウド化は可能。​
  • integration機能でDBやAWS関連の監視も可能。
• 構築観点
  • サーバにはエージェントインストールとNW疎通対応のみで構築可能。
  • アプリケーションにはLogger拡張とカスタム属性設定を行うことで拡張性が高い対応が可能。
• 機能性​（管理コンソール・ダッシュボード）
  • NW依存かもしれないが表示速度に若干の課題感あり、時々バグも発見されるが問合せ連絡すれば数週間で直してくれる。
  • ダッシュボードに関しては、定着化までエンジニアサポートがついてるので実現性は高い。​
  • クエリベースの検索／チャート表示のため、再現性の担保が容易。但し、習熟が必要。​
  • ログ保持については、長期保管は不可。（延長課金で一定の延長は可能）
• その他​（サポート・コスト面）
  • ユーザー数依存でのライセンス体系のため、ユーザ管理運用が発生するが、適切に管理していけばコストコントロールは可能。​
  • 課金が不要なBasicユーザーでは、ダッシュボードの作成・確認ができるため、あらかじめシナリオを考慮したプリセットダッシュボードを作成しておけば、過度なFullユーザ増加は不要。
  • サポートに関しては他ツールより優位性があり、問題や課題に対する誠実度は高い。

改善したかった課題はどれくらい解決されたか

• 分散トレーシング機能により、クライアント⇔サーバ間通信のボトルネックを検出することができるようになった。
• フロントエンドのパフォーマンス計測／UIエラー内容を検出することができるようになった。
• バックエンドのログ収集が検索性の高いダッシュボードを利用することで容易にログ確認ができるようになった。

どのような成果が得られたか

• システムの可視化と監視の向上
  • New Relicの導入により、システム全体のパフォーマンスと稼働状況をリアルタイムで監視できるようになった。
  • 障害発生時には迅速に問題の特定と対応が可能となり、サービスダウンタイムを最小限に抑えることができた。
• 開発プロセスの効率化
  • 開発チームがアプリケーションのパフォーマンスデータを詳細に分析できるようになり、ボトルネックの特定と解消が迅速に行えるようになった。
  • コードの品質向上とリリースサイクルの短縮が実現できた。
• ユーザーエクスペリエンスの向上
  • エンドユーザーの利用状況や行動をモニタリングすることで、ユーザーエクスペリエンスを向上させるための具体的な改善点を見つけることができた。
• データ駆動の意思決定
  • データに基づくインサイトを活用することで、より精度の高い意思決定が可能となった。
  • ビジネスの成長と効率化に繋がる戦略的な判断がデータを基準に迅速に行えるようになった。

• 導入初期（PoC等）では、NewRelicへうまく通信できていない場合の原因分析が困難であったこと。
  • 社内のNW起因や、設定（実装）不備が混在しており、ログ等を見ても解析が厳しかったが、セールスエンジニアの協力があり解決した。
• UIが基本英語なので細かい設定をする際に、都度どういった設定なのかをドキュメントと照らし合わせながら行う必要があったこと。
  • アラート設定などは一部直感的ではない設定項目があった
• UIが頻繁にアップデートされるため、手順を確立しても操作方法が変わってしまうことが多々あり、運用保守の引継ぎに手間取ったこと。
• 導入後に有用性を証明するため、開発チームにKPIを提供したり、保守チームの定型作業をダッシュボード化したりと浸透活動をしばらく続けていたこと。

• 導入後、有用性は日々の業務内で各所に証明し続ける必要がある。
  • 導入しただけでは利用してくれないケースもあるため、利用することでどういったメリットがあるのかを実際に効果を出してみることが大事。
• 課金体系がユーザータイプ依存なので、事前にユーザータイプごとのできること／できないことを確認したのち、利用想定に基づいたユーザー管理設計をして予算策定をする必要がある。
• NewRelicの活用は、開発に近いメンバが推進したほうが全体の浸透率は高くなる可能性がある。
  • 開発拡張性が高かったり、取得する方法（NRQL）がSQLライクな構文を利用するため、従来の監視ツールを利用していた運用チームより、開発チームのほうが柔軟にツール活用方法を思いつく傾向がある
  • 運用チームが運用に落とし込んだ結果、ダッシュボードを作りすぎると、「ダッシュボードを見るだけ」のメンバが増え、データ活用の促進が行われない可能性がある。

• 利用するシステムの増加
• コンテナに対する導入
• DBメトリクスの収集と活用