爆誕予定のテレメトリー集約/可視化基盤を晒してみる

この記事は、NTT Communications Advent Calendar 2023 8 日目の記事です。

はじめに

こんにちは、イノベーションセンターでノーコード分析ツール「Node-AI」開発チームの林です。

業務としては Node-AI のフロントエンドやバックエンド開発、最近では監視/可視化のプラットフォーム開発に携わっています。

本記事ではこの監視/可視化のプラットフォームについて、検討段階ではあるのですがアーキテクチャを中心にまとめていきたいと思います。

Node-AI について

Node-AI はノーコード分析ツールとなっていて「予測/異常検知モデルをすぐに・簡単に・わかりやすく作成可能」といったところを推しているツールとなっています。

インフラとしては、Google Cloud を利用しており Google Kubernetes Engine (以下、GKE)の上でアプリケーションが実行されています。

運用上の課題

現在は誰しもが同様に利用できる環境を提供していたり、個別の顧客環境としてカスタマイズしたものを提供したりと Google Cloud のプロジェクトレベルで別れた環境を複数提供しています。

そうなってくると運用する上で面倒なのがメトリクスやログといったテレメトリー情報が各プロジェクトに集約されていることです。コンソール上でプロジェクトを切り替えれば Cloud Monitoring や Cloud Logging の Explore で確認できますが、可能であれば一元的に集約して「ここを見るだけ Node-AI の現状がわかる！！」という状態にしたいと思いました。

また、各環境を横串で分析したいという時もプロジェクトごとに BigQuery に蓄積していると一工夫が必要だったりするので、こういったケースでも一元的に集約できていると嬉しいことがありそうです。

加えて、目的に応じてプロジェクトを切り出すことで権限制御の簡素化や IaC の肥大化を防ぐといったメリットもあると考えるため、その点も考慮したいと思います。

「テレメトリー集約基盤」爆誕（の予定）

「各環境のテレメトリーを集約」をテーマに新しくプロジェクトを切り出して下記のようなアーキテクチャを検討しています。よくあるログの集約/可視化パターンではあるのですが、いくつか推しポイントがあるのでその点をご紹介したいと思います。また、これらの推しポイントの裏テーマとして「極力手間をかけずに」というのもかかげていたりします。

推しポイント① Grafana + Cloud Run

可視化のツールとして Grafana を採用して Cloud Run 上にホスティングしています。Cloud Run Service でホスティングすることで「運用負荷の軽減」「コスト削減」の 2 点のメリットが得られると考えたためです。

「運用負荷の軽減」という点では、みなさんご存知の通り Cloud Run はサーバーレスサービスというところで Compute Engine など IaaS を利用した際の面倒ごと（例えば、柔軟性が高いが故の初期セットアップでのネットワークやセキュリティに関する適切な設定作業など）が少ないのが非常に嬉しいところです。「コスト削減」という点では、Cloud Run Service の最小インスタンス数を 0 にしておくことでリクエストがない間は自動スケーリング機能によりインスタンス数が 0 になります。インスタンス数が 0 のメリットとしてはその間課金されないところです、一方でリクエストを契機に起動することになるのでインスタンス数が 0 の状態での初回リクエストでは時間がかかる（コールドスタート）点がデメリットでもあります。今回のユースケースでは Grafana のダッシュボードを見られれば良いのでコールドスタートを許容できます、なので最小インスタンス数を 0 にした自動スケーリング機能を活用してコスト削減の恩恵を受けられる形になっています。

推しポイント② Cloud Run + Wildcard Certificate + Identity-Aware Proxy

Grafana on Cloud Run を運用者がアクセスするにあたって Cloud Load Balancing を利用してインターネット公開しています。公開にあたり「セキュリティ強化」と「今後の運用を見据えたドメイン紐付け」について紹介します。

Cloud Run Service でホスティングしてインターネット公開する方法はいくつかあると思いますが、「セキュリティ」を意識した時に Cloud Load Balancing や Cloud Armor を前段に置くパターンが一般的かと思います。今回はそれらに加えて、Identity-Aware Proxy（以下、IAP）というプロキシサービスを活用しています。こちらを導入すると Grafana にアクセスすると下記のように Google アカウントの認証画面に移動して、適切な権限を持っている Google アカウントでないと認証を通さない設定を簡単に入れることができます。

「今後の運用を見据えたドメイン紐付け」という点では、Cloud Run Service の便利な機能である URL マスクと Certificate Manager による Wildcard Certificate を組み合わせて 1 つの DNS 設定で複数のサブドメインとサービスを紐づけられることができまる構成をとっています。こちらの導入により、今後運用に必要なツールを採用したい時に Cloud Run Service に新たなツールをデプロイするだけで追加の IP の払い出しや Load Balancer のプロビジョニングなどが必要なくなります。

推しポイント③ Grafana Plugin + Cloud Monitoring + Cloud Logging

Grafana で Kubernetes のメトリクスやログを可視化しようとすると Prometheus, Promtail, Grafana Loki といった複数のコンポーネントが思い浮かびます。これらのコンポーネントを極力増やさない面倒をみないように工夫した「マネージドサービスと Plugin による拡張」について紹介します。

Prometheus については、Google Cloud Managed Service for Prometheus という機能があり GKE 1.27 以降の新規クラスタではデフォルトで有効化されています。名前の通り、マネージドな Prometheus となっていて利用者が新たにデプロイする必要がない点が手間がかからず嬉しいところです。

また、テレメトリーの蓄積する場所も必要になってくるかと思います。ストレージ周りの追加の管理は大変な面もあるので、この点もマネージドに寄せられたらと思いました。Grafana を漁っていると今年の 3 月に Cloud Logging に接続できるプラグインがリリースされていることがわかりました。Grafana にはデフォルトで Cloud Monitoring のプラグインも導入されていて、これらを採用することで Grafana から Cloud Operations のサービスを利用でき、新たなコンポーネントの追加や管理から解き放たれました！

まとめ

検討中のテレメトリー集約基盤について紹介しました！工夫のポイントとして 3 つ挙げています。

Grafana + Cloud Run による「運用負荷の軽減」「コスト削減」
Cloud Run + Wildcard Certificate + Identity-Aware Proxy による「セキュリティ強化」「今後の運用を見据えたドメイン紐付け」
Grafana Plugin + Cloud Monitoring + Cloud Logging による「マネージドサービスと Plugin による拡張」

この中でも「極力手間をかけない」という点も意識してマネージドサービスを採用したり置き換えたりしてみました。とはいえ、構築して終わりではなくこの基盤を使って「どのように運用を高度化するか」というのが重要だと思っています。

メトリクスやログを可視化して、実際にサービスをユーザーに使ってもらう中で何を SLI として SLO を設定した上で、運用から得られるフィードバックを開発に活かすというサイクルを回せるところまで取り組めたらと思っています！DevOps の実践、楽しみです。