はじめに
こんにちは。DevOps Enablementチームの福本です。 今回はバイセルで構築しているリユースプラットフォーム Cosmosのオブザーバビリティを担っているNewRelic ダッシュボードの説明を通して、 使いやすいモニタリング用ダッシュボードをどのように作っていくかについて観点をいくつかご紹介させていただきます。
- はじめに
- 背景・課題
- 課題解決のための仮説・アプローチ 1
- API GatewayダッシュボードVer1について
- Ver2に向けたアプローチ
- API GatewayダッシュボードVer2について
- まとめ
- 最後に
背景・課題
みなさんは「モニタリングダッシュボード」と聞いてどのようなものを想像されるでしょうか？ よくあるものとしては、グラフが方眼状に並んだようなものを思い浮かべるかもしれません。
例えばあるデータベースサーバ。そのリソースについて知見のある人が詳細を見るような使い方であれば充分なこともありますが、 サーバの台数が多くなると1枚のグラフでは線が煩雑になり見づらくなります。 一方で各サーバごとに見られるように作ると切り替えが面倒で使いづらいものとなりがちです。
このような課題は、特にマイクロサービスアーキテクチャを採用している場合に顕著になります。 弊社のCosmosもその例に漏れず、サービス間の連携やエンドツーエンドの可観測性を確保する上で、 適切なモニタリング基盤の選定と活用が重要な課題となっていました。
そこで弊社ではNew Relicをオブザーバビリティ基盤として採用し、アプリケーションのパフォーマンスやインフラストラクチャの監視を行っています。 特に今回題材とするAPI Gatewayは、Cosmosにおいてバックエンド通信の起点となる機構であり、 認証やリクエストの各マイクロサービスへの振り分けを担っています。
どこのサービスで異常が起きているか、他のサービスへの影響があるかなどを素早く判断できるダッシュボードとするためには、 情報を整理してレイアウトや表現に工夫をこらすことで見やすいものとする必要があります。
いくつか検討・対策を採ってみましたので、その内容について見ていきましょう。
課題解決のための仮説・アプローチ 1
どのようにパネルを配置するか
Webページの閲覧においての視線の動きにFの法則と呼ばれるものがよく知られています。 この視線の動きは左上から右、次の段の左からまた右へ...と動くもので、下に行くほど右へ行く量は減っていく傾向を示します。
現実世界ではよく券売機などで用いられる知見で、おすすめメニューは上段左側に置くといった形で使われています。
ダッシュボードのパネル配置においても左上を原点として右下方向へ展開していくように重要度が高いものを配置していくことで、 知るべき指標が目に入りやすいように構成することとしました。
API Gatewayにおいては各マイクロサービスで生じた事象が全体に影響を及ぼしていないかを検知したいため、 「リクエスト数の変動」「レイテンシの変動」「エラーリクエスト」といった順で優先度が高いといえます。
ヒートマップの活用
NewRelicの特徴的な表現手法の一つにヒートマップが挙げられます。 これは２つの系と１つの値を持つデータセットの分布を色の濃淡で表現する手法です。
今回、これをマイクロサービスごとのレイテンシ表示に用いることとしました。 縦にマイクロサービス横にレイテンシを採り、色の濃淡でアクセス数を表すようにすることで、 ロングテール傾向や複数のピークがある状態といった単純な平均・中央値のみではわかりづらい状態を 視覚的に確認できるようにしました。
API GatewayダッシュボードVer1について
上記のような仮説・アプローチを元に作成したのがこのダッシュボードとなります。
パネル配置について
左から順に、「リクエスト数」「エラー系(4xx,5xx)リクエスト数」「レイテンシ」を並べる形を採りました。
上述の通り、優先度の高さではレイテンシがエラーリクエスト数よりも高いですが、リクエスト数との相関が現れやすいエラー数を2番目としました。
これは、「よくあるインフラダッシュボード」の観念から抜けきっていなかったためです。
不満・不足のあった箇所
API Gatewayから得られない情報がある
Ver1の実装時期において、API Gatewayから出力されるアクセスログの情報は少なく、レイテンシやエラー情報は載っていませんでした。
このため傾向把握に使えるよう、各マイクロサービスのCloudRunなどから収集したリクエスト数を元に合成した指標を２段目に配置していましたが、 実際の利用者からは「どちらを見ればいいのかわからない」「数値のズレをどう認識すればいいのか」といった意見が多く見られました。
合成した指標のため各メトリクスの取得・計算タイミングのズレ、 またAPI Gateway側でタイムアウトしたリクエストは反映されないこともあり API Gateway単独のメトリクスと誤差が生じる事が多くありました。
パネル配置の統一性がない
3,4段目は左側に表、右側にグラフを配置しましたが、上2段と構成が真逆なため混乱しやすい状態でした。
そして5,6段目と階段状に左にグラフが増えていくため、Fの法則と真逆の構成となってしまっています。
その他
多様なデータソースを扱い、１パネルあたりの系列数も多くなりがちだったためダッシュボードの描画は高負荷なものとなっていきました。 特にモバイル環境で表示しようとすると度々クラッシュすることもあり、PCにおいても描画に数秒かかるものとなっていました。
また、合成した指標を用いるパネルはNRQL(NewRelicにおける図表描画のためのクエリ言語)も複雑になっており、メンテナンス性も低くなっていました。
Ver2に向けたアプローチ
Ver1のダッシュボードはその運用に伴って「あれも見たい。これも見たい」へ応えようと様々な情報を表示するように改修されていました。 「どこのサービスで異常が起きているか、他のサービスへの影響があるかなどを素早く判断できるダッシュボードとする」事が目的だったにもかかわらず、 パネル数が多く描画も重たい「素早く確認できない」ダッシュボードとなってしまっていたのです。
これではいけないと感じたため、概略を表示するダッシュボードとしての用途に絞ったVer2の制作をすることとしました。
Ver2の制作においては、下記の事項を改善として取り込みました。
API Gatewayからの情報収集強化
Ver2の実装にあたっては、各マイクロサービスへのリクエスト転送の状況を詳細に残すようAPI Gateway自体のロギングを強化しました。 これにより、Ver1のように合成した指標を用いること無くAPI Gateway自体のメトリクス・ログのみでダッシュボードを構築することが可能となりました。
ダッシュボードの軽量化
API Gatewayの機能改善に伴いNRQLをシンプルに構成できるようになり、各パネルの軽量化が果たされました。
また、前週比のパネルについては利用することが殆ど無く、利用するのも自分のみだったため都度NRQLを実行する形を採ることとしました。 他にもトラフィック、API Gateway単独のレイテンシについても同様に利用頻度が低いため、別のダッシュボードに配置することとしました。
これによりダッシュボードの縦幅が圧縮され、ダッシュボード全体の軽量化が大きくなされました。
情報の整理
マイクロサービスの増加はグラフ系統の増加を招き、グラフは見づらいものとなっていました。 特にエラーリクエストの表示においては酷いものとなっていたため、この点の改善を目指しました。
具体的には、エラー種別ごとにパネルを分けることで各パネルにおける情報量の低減を図りました。
優先順位の変化
マイクロサービスとユーザ数の増加に伴い、各マイクロサービスのレイテンシ変動が他サービスへ影響を及ぼす事が増えてきました。 これはAPI GatewayがReverse Proxy型の構造をとっているため、高いレイテンシのリクエストはAPI Gatewayのリソースを圧迫することに直結するためです。
このため、Ver2においては各マイクロサービスのレイテンシの変動を捉えやすくする事に重きをおきました。
また、グラフ形式の表示では横軸が時間軸となりますが、上下にグラフを並べる事で同時間における他の指標をチェックしやすくなります。 一方、形状に相関の強いものについては左右に並べても見比べやすいため、そのように配置しました。
API GatewayダッシュボードVer2について
そしてこれがVer2のAPI Gatewayダッシュボードとなります。
パネルレイアウト
前述したアプローチを組み入れつつ、横のパネル数を等幅3パネルから1+横長1の2パネル構成に変更しました。 これにより情報量を意図的に減らし「多様な情報が得られるダッシュボード」から「今、異常が起きているかどうかにフォーカスしたダッシュボード」へと変容させました。
2段目以降は左に棒グラフ、右に同一の情報をリスト表示しています。 これにより、異常が発生したときに特定のURLに偏っているかどうかを別画面でチェックする必要がなくなりました。
F字型の意識
視線の動きに沿って優先度の高いパネルを配置しました。 上段左から、「リクエスト数変化の異常」「異常なレイテンシを出しているBackend service」 2段目に移り「サーバエラーの発生状況」を示しており、最初の仮説どおりの順で並ぶこととなりました。
また、ガンマ(Γ)状にグラフを配置することで視線の誘導を図りました。
まとめ
評価
Ver1からVer2への変更を経て、主観的ではありますが見やすさが向上したと感じています。 やはりVer1は情報過多で混沌としており、慣れていてもパッと見での情報取得が難しい部分がありました。
特に各種のリクエスト状況をプロダクトごとに表示できるようになったことは大きく、 全体的に異常が発生しているのか特定のプロダクトだけなのか、 またURLの偏りがあるのかどうかの判別が行いやすくなったと感じます。
やはりパネルレイアウトは重要であり、見て欲しいものにフォーカスさせるために思考を凝らすべきなのだろうと考えています。
今後の展望について
レイテンシ傾向について
利用時刻によって使われる機能が変化し、レイテンシ変化が発生することは容易に想像されます。 ただし現在、レイテンシはヒートマップのみでの表示としていますが、 この表示方法では時系列での変化を知ることはできません。
例えば、Cloud Monitoringにおいては下図のようなヒートマップ表示が実装されています。 これは時系列変化を捉える事も可能な表現方法になっていますが単一の系列についての表現に留まっており、 マイクロサービスごとのヒートマップを表示するとなると混沌としたパネルになってしまうだろうと考えています。
何かいい方法を考えていきたいと思っています。
色使いについて
New Relicでは2022/11よりグラフの各系列の色指定が可能となりました。
各マイクロサービスごとに色を割り当て、各々のパネルで同一の色とすることで視認性の向上が期待できます。
まだダッシュボード単位での色指定という形は取れないため設定を各パネル毎に行う必要がありますが、機を見て実施したいと考えています。
最後に
ダッシュボードの構築において見せたいものを全て羅列するのではなく、 そのダッシュボードのユースケースを考えて情報を絞り、配置を思案することが大事であることがわかりました。
異常時にひと目見て何が異常かを認識しやすくすることは障害対応の速度向上にも繋がります。 情報を絞ることは日々のモニタリング活動の容易化にも繋がり、適切にフィルタされた指標は変化を迅速に表現します。
うまくダッシュボードを作る。それもまた一つのスキルといえるのではないでしょうか。 この記事が皆様の一助になれば幸いです。
バイセルではエンジニアを募集しています。少しでも気になった方はぜひご応募お待ちしています。
