New RelicによるOSSのAPI Gateway Kongの観測方法

Kongとは

Kongはマルチクラウド、ハイブリッド環境でも利用できる、オープンソースのAPIゲートウェイです。
例えばマイクロサービスアーキテクチャを採用の場合、サービスディスカバリや認証など、全てのサービス共通で持っておかないといけない、APIの機能をKongが担います。

それでは、New Relicを使ってKongを採用しているアーキテクチャを観測するために設定をしていきましょう。

本ブログでは、以下の要素を使って設定を進めます。

分散トレーシングの設定

  • Kong: Zipkin プラグイン
  • New Relic: Trace API

メトリクスの設定

  • Kong: Prometheus プラグイン
  • New Relic: Infrastructure Flex

観測するデモアプリケーション

観測するデモアプリケーションは、Dockerとして提供されているKongを利用しており、2つのアプリケーションで通信が発生する構成となっています。

分散トレーシングの設定

分散トレーシングの設定では、すでにKongの設定が終わり、各アプリケーションにはNew Relic APMが導入されていることを前提に進めていきます。

フォーマットの仕様確認

分散トレーシングに必要なトレースコンテキストのフォーマットはNew Relicも参加し標準化が進んでいます。
以前New Relicは独自のフォーマットを利用していたのですが、先日W3C Trace Contextのサポートを開始しました。

New RelicによるW3C Trace Contextのサポートを発表:New Relic APMでの利用が可能になりました


一方、設定対象のKongはZipkinをPluginで利用できます。これまではB3フォーマットが採用されていたのですが、
先日W3C headerが対応され、仕様としてはNew Relicで分散トレーシングを観測できる状態となりました。
Kong Changelog 2.0 – Zipkin W3C header 対応
New Relic、Kong双方が分散トレーシングの標準化を進めたことで、New Relic上で非常に簡単にKongを採用している場合でも
簡単に分散トレーシングができるようになりました。

設定手順

3ステップで設定を行います。

1, New RelicのInsert API Keyの登録

Zipkinトレーシング情報をNew Relicに送信するために、New RelicのAPIキーが必要です。
こちらのドキュメントを参考に、APIキーを登録してください。
登録したキーはステップ3で利用します。

2, SSL通信の証明書の有効化(行っていない場合)

Kongから外部にAPI接続を行うので、SSL通信ができるようにしましょう。
kong.confファイルの”lua_ssl_trusted_certificate”の設定を変更してください。

lua_ssl_trusted_certificate = /etc/ssl/certs/ca-certificates.crt

参考資料

3, KongのZipkinプラグインの設定

Kong上のサービスなどはすでに設定されている前提で、Kong Zipkinプラグインを設定していきます。
Zipkinプラグインのドキュメントを確認し、デモ環境では以下のようにリクエストを投げています。
グローバル設定としてZipkinが有効となるように設定を追加しており、sample_ratio=1としているので、全てのトレースをNew Relicに送るようにしています。
設定は適宜変更の上ご利用ください。
endpointのURLはこちらのドキュメントをご参考いただけます。

curl -X POST http://localhost:8001/plugins/ -H 'Content-Type: application/json' --data '{"name": "zipkin", "config": {"http_endpoint": "https://trace-api.newrelic.com/trace/v1?Api-Key=${ステップ1で取得したAPIキー}&Data-Format=zipkin&Data-Format-Version=2", "sample_ratio": 1, "traceid_byte_count": 16, "header_type": "w3c" }}'

New Relic上で確認する

設定ができたら、New Relic上でトレース情報がどうなっているかを確認できます。
Entity数はKongを含む3となっており、分散トレーシングもUI上でKongを挟んだ内容を確認できるようになります。

また、サービスマップ上ではproxyの役目を果たしたKongは写っておらず、ビジネスロジックを確認するためのNew RelicAPMが導入されているサービスが表示されます。
何か問題のあった場合見るべきところはKongよりもビジネスロジッk側であることが多いと思われますので、それをシンプルに確認できるような
動きとなっています。

以上で分散トレーシングの設定は終わりです。
非常に簡単に分散トレーシングを導入できるので、マイクロサービス全体をトレースするためにぜひご活用ください。

メトリクスの設定

次にメトリクスを収集し、Kongからみたサービスの状況がどうなっているのかを確認しましょう。
メトリクスの設定では、すでにKongの設定が終わり、ホストにNew Relic Infrastructureが導入されていることを前提に進めていきます。

設定手順

3ステップで設定を行います。

1, KongのPrometheusプラグインの設定

Kong Prometheusプラグインのドキュメントを参考に、
Prometheus プラグインを設定してください。

2, New Relic Infrastructure Flexの設定

New Relicは多くのサービスやフレームワークとのインテグレーションを提供しているのですが、独自に設定を行ういことができます。
ここではNew Relic Infrastructure Flexを利用してメトリクスを収集してみます。

New Relic Infrastructureが導入されている場合、設定ファイルを追加するだけでPrometheus exporterから情報収集を始められます。
設定ファイル:/etc/newrelic-infra/integrations.d/kong-prometheus.yml

integrations:
  - name: nri-flex
    # interval: 30s
    config:
      name: kongPrometheusMetrics
      apis:
        - name: kongMetrics
          url: http://localhost:8001/metrics
          prometheus:
            enable: true

また、Prometheus exporterだけでなく、Kongに標準的に用意されているエンドポイントからも情報を収集できます。
設定ファイル:/etc/newrelic-infra/integrations.d/kong.yml

integrations:
  - name: nri-flex
    # interval: 30s
    config:
      name: kongFlex
      global:
        base_url: http://localhost:8001/
        headers:
          accept: application/json
      apis:
        - event_type: kongStatusSample
          url: status
          snake_to_camel: true
        - event_type: kongUpstreamSample
          url: upstreams
          snake_to_camel: true
          remove_keys:
            - healthchecks.active.unhealthy.http_statuseSamples ### these 4 are just an array of status codes, that are deemed to fall into each category, so no need to be added
            - healthchecks.passive.healthy.http_statuseSamples
            - healthchecks.passive.unhealthy.http_statuseSamples
            - healthchecks.active.healthy.http_statusesPrometheusSamples

他にも多くの設定サンプルが用意されていますので、併せてご確認ください。

ダッシュボード作成

Prometheus プラグイン経由で収集したデータを利用してダッシュボードを作成しました。
こちらの記事通りの設定をした場合にコピペで利用できるNRQLですので、ご活用ください。

応答速度(秒)
FROM kongMetricsSample SELECT derivative(kong_latency.histogram.sum, 1 minute)/derivative(kong_latency.histogram.count, 1 minute)/1000 WHERE type IN('upstream', 'kong') TIMESERIES FACET service, type
スループット(分間)
FROM kongMetricsSample SELECT derivative(kong_http_status.counter, 1 minute) TIMESERIES
利用帯域(GB)
FROM kongMetricsSample SELECT derivative(kong_bandwidth.counter, 1 minute)/1024/1024 TIMESERIES FACET service
レスポンスコード別比較
FROM kongMetricsSample SELECT derivative(kong_http_status.counter, 1 minute) TIMESERIES FACET code
リクエストドロップ数
FROM kongMetricsSample SELECT filter(latest(kong_nginx_http_current_connections.gauge), where state = 'accepted') - filter(latest(kong_nginx_http_current_connections.gauge), where state = 'handled') as 'accepted - handled' TIMESERIES
upstream処理欠損
FROM kongMetricsSample SELECT filter(derivative(kong_latency.histogram.count, 1 minute), where type = 'request') - filter(derivative(kong_latency.histogram.count, 1 minute), where type = 'upstream') as 'request - upstream' TIMESERIES

まとめ

KongのNew Relicでの観測として、分散トレーシング、メトリクスの設定を解説しました。
マイクロサービスアーキテクチャで効果を発揮するKongのAPIゲートウェイですが、New Relicをご利用いただければ、
トレース全体が観測できることをご理解いただけたと思います。
アプリケーションのコードや既存の設定に手を入れることなく、少ない手順でえご利用いただけますので、ぜひご活用ください。

NewRelicソリューションコンサルタント。ERPパッケージベンダーにてSaaS製品を開発。SREも担当し運用自動化に励む。その後総合系コンサルティングファームに転職し、BtoCサービスの構築支援としてモバイルアプリを主としたサービスの開発リーダーを担当。 アーキテクチャの設計からCICD、バックエンド・フロントエンド開発という全領域の開発に加え、SREで経験した運用も踏まえたアプリケーションを中心としたパフォーマンス管理・チューニングを得意とする。 業務上経験が多いのはJava、Javascript。 View posts by .