LT3: オブザーバビリティの ベストプラクティスと 弥生の現状 弥生株式会社 牛尾哲朗

目次 • オブザーバビリティとは • オブザーバビリティの重要性 • オブザーバビリティのベストプラクティス • 弥生の現状

オブザーバビリティとは • システム内部の状態を推測・把握する能力のこと • 主な監視対象は以下の３つ • メトリクス • ログ • トレース • これらをモニタリング（把握）し、問題の原因を推測する • CPUやメモリの使用率から、リソースに過不足ないか • エラーログの出力状況から、システムが期待通りに稼働している • APIの応答時間から、ストレスなく利用できているか

オブザーバビリティの重要性 • モノリシックアプリケーションからマイクロサービスへの変化 • モノリシックの監視は比較的簡単 • 単一の言語 • 単一のサービス • 単一のプラットフォーム • マイクロサービスの監視は複雑 • 複数の言語 • 複数のサービス • 複数のプラットフォーム（ECS、EKS、Lambda、etc） • 複数のAZ、クロスリージョン • 複数のデータストア

オブザーバビリティのベストプラクティス 最初に行うこと コスト最適化 アラート疲れの軽減 分断したトレースの回避

最初に行うこと • ツールやサービスの導入が必要 • AWS CloudWatch • AWS X-Ray • New Relic • Datadog • Grafana • AWS上で運用する場合、以下のそれぞれに対して対応 • AWS管理の部分 • サービス提供者管理の部分

最初に行うこと • AWS管理の部分について • メトリクスやログについては、ほぼ自動で CloudWatch で可視化される • トレースについては、X-Ray の機能をONにすればよい

最初に行うこと • サービス提供者管理の部分について • Lambda • メトリクスについては、aws-embedded-metrics ライブラリを用いるのがよい • CloudWatch Logs 経由でメトリクスが保存できるとのこと • メトリクスデータAPIは非推奨 • ログについては、console.log メソッドなどを用いれば CloudWatch で可視化 できる • トレースについては、X-Ray SDK を用いるのがよい • ECS / EKS • メトリクスやトレースについては、AWS Distro for Open Telemetry (ADOT) を用いて可視化するのがよい • ログについては、CloudWatch か FireLens agent を選択する • Open Telemetry の仕様で、ログはまだドラフトであるため • 将来は ADOT に一本化できるかも

コスト最適化 • マイクロサービスの場合、メトリクスの数が膨大になりがち • 例えば • モノリシックの場合、5サービス×10インスタンス=50メトリクス • マイクロサービスの場合、100サービス×10タスク=1,000メトリクス • モノリシックでは多少コストをかけて全てのメトリクスを可視化すること ができたが、マイクロサービスの場合は現実的ではない • メトリクスではなく、ログで記録する選択肢もある • コスト効率はログの方が高い • ただ、視認性は劣る

コスト最適化 • メトリクスかログのどちらかではなく、両方を採用すべき • CloudWatch Embedded Metrics Format を用いると容易に可能 • CloudWatch Logs から自動的にメトリクスを作成できるJSON仕様 { "_aws": { "Timestamp": 1574109732004, "CloudWatchMetrics": [ { "Namespace": "lambda-function-metrics", "Dimensions": [["functionVersion"]], "Metrics": [ { "Name": "time", "Unit": "Milliseconds" } ] } ] }, "functionVersion": "$LATEST", "time": 100, "requestId": "989ffbf8-9ace-4817-a57c-e4dd734019ee" }

コスト最適化 • メトリクスかログのどちらかではなく、両方を採用すべき • ログでフルデータを残す • 高カーディナリティの属性を除いたデータでメトリクスを作成する • ビジネス的に意味のあるメトリクスのみを作成する

アラート疲れの軽減 • 効果的なアラートのみを発砲する • KPI達成度を測定するワークロードメトリクスについてアラートを発砲する • CPU使用率とメモリ使用率が共に高い場合のみ、アラートを発砲する • どちらかだけ高い場合は問題でない可能性がある • 統計アルゴリズムや機械学習アルゴリズムを使用する • 静的閾値ではなく、動的閾値を用いる • 異常値の自動検出 • Amazon CloudWatch Anomaly Detection • 複合アラーム • Amazon CloudWatch Composite Alarm

分断したトレースの回避 • 全てのコードを一貫してトレースする必要がある • AWS X-Ray を導入しても自動ではトレースされないサービスがある • Amazon MQ • Amazon MSK • AWS Step Functions の一部処理（Amazon ECS や AWS Batch の呼び出し等） • 呼び出し元と呼び出し先で明示的にコンテキストを受け渡すことでトレース 可能 Amazon ECS Amazon ECS Amazon MQ Trace ID: 100 Trace ID: 200

弥生の現状 • 数年前からオブザーバビリティへ力を入れ始めている • 運用中の全サービスに New Relic の導入を進めている • サーバーアプリケーションのモニタリング • インフラストラクチャのモニタリング • リアルユーザーモニタリング • 外形監視 • など

弥生の現状 • ベストプラクティスの対応状況 • 最初に行うこと • New Relic はドキュメントが充実している • 不明点についてはサポート問い合わせで解決 • コスト最適化 • カーディナリティを意識せず、ログやトレースに情報を出力している • 重要なメトリクスについては、ダッシュボードで可視化

弥生の現状 • ベストプラクティスの対応状況 • アラート疲れの軽減 • 運用開始時は大量のアラートに悩まされた • New Relic では柔軟なアラート設定が可能なので、試行錯誤の上で解消 • AI技術を用いた機能も充実しているので、そちらの活用も進めている • Proactive Detection（異常値の検出） • Incident Intelligence（同じ原因のアラートの統合） • 分断したトレースの回避 • 現状は未対応の個所が多数 • メッセージングサービスを利用している個所での分断が主 • 現状はユーザーからの同期通信を中心に監視しているので、あまり課題感はなかった • 非同期通信も含めて適切にトレーシングするのは今後の課題

まとめ • オブザーバビリティのベストプラクティス • 最初に行うこと • コスト最適化 • アラート疲れの軽減 • 分断したトレースの回避 • New Relic 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた