Kubernetes上へのElastic APMサーバの自動デプロイについて

はじめに

KCS部の辻下(tjst-t)です。

KCS部は、KADOKAWAグループ向けプライベートクラウド(以下KCS)を提供しており、主な利用者は株式会社ドワンゴがサービスを提供している『niconico』です。

私の所属しているDSREチームでは、MySQLやRedis、Elasticsearch/KibanaといったDatastore関連のミドルウェアをマネージドサービスとして、KADOKAWAのグループ会社に提供しています。

今回は弊社のElasticsearch基盤であるElastic Stack as a Service(ESaaS)で、APMサーバをKubernetesクラスタ上に自動デプロイするシステムを作った事例について紹介します。

概要

ESaaS は KCS が提供する Elasticsearch のマネージドサービスです。Elastic社が提供している Elastic Cloud をオンプレミスにホスティングする製品の Elastic Cloud Enterprise (以下 ECE) を利用しています。RDB基盤やCache基盤は VM でしたが、ESaaS ではログ閲覧を主なユースケースに定義しており、Diskスループットが必要なため VM ではなくベアメタルサーバで利用しています。

ESaaSの詳細につきましては、0.1 人月未満で運用する Elasticsearch 基盤をご参照ください。

ESaaSが提供するElasticsearchとKibanaによって、利用者はシステムのログやメトリクスをモニタリングすることが簡単にできるようになりました。しかし一部の利用者からはログやメトリクスだけではなく、アプリケーションモニタリングを利用して、アプリケーションのより詳細なメトリクスを取りたいという要望が出てきました。

アプリケーションモニタリングのソリューションとして、Elastic StackではElastic APMを提供しています。Elastic APMではアプリケーション内に組み込んだElastic APMのライブラリからAPMサーバを経由してElasticsearhにアプリケーションのメトリクスを取り込むことで、ElasticsearchとKibanaの強力な検索能力、ビジュアライゼーション機能を利用した、高度なアプリケーション監視を実現することができます。

そこでESaaSでは、Elastic APMのコンテナイメージをKubernetesにデプロイして利用者に提供することにしました。デプロイ先のKubernetesクラスタとして、KCS部で運用しているマネージドKubernetesサービスであるDKSを利用しています。

APMサーバをなぜECE上にデプロイしないか

ECEではAPMサーバもElasticsearchやKibanaのNodeと同様にデプロイと管理が可能です。単純な運用や開発のコストの観点からはECEでAPMサーバをデプロイするのが最良です。それにも関わらずESaaSではKubernetes上でAPMサーバを運用する理由は大きく2つあります。Real User Monitoring(RUM)のためと、リソース利用の最適化です。

Real User Monitoring(RUM)

RUMを実現する場合、クライアントアプリケーションからAPMサーバへの到達性が必要となります。しかし様々なログが格納してあるElasticsearchやKibanaがインターネット上からアクセスできることはセキュリティの観点から望ましくないため、ESaaSのECEノードは社内ネットワークからしかアクセスできないように設定してあります。

APMサーバを、インターネットからアクセス可能なKubenetesクラスタ上にデプロイすることで、上記の問題を解決することができます。

リソースの最適化

ECEはベアメタルサーバにデプロイしているため、仮想環境のようにユーザの利用状況に合わせて、CPUやメモリといったリソースを柔軟に増設する事はできません。APMサーバはデータを保持しないためElasticsearchに対してネットワークで接続できれば運用できます。APMサーバをECEの外にデプロイすることで、ベアメタルサーバのリソースをElasticsearchなどのデータを持つプロセスに最大限使うことができます。

以上の2点から、APMサーバをECEとは別にKubernetes上にデプロイする構成にしました。

設計

Elastic APMを組み込んだESaaSの構成図は次のようになります。ESaaSではElastic APMサーバ(以下APMサーバ)をKubernetes上にデプロイしています。APMサーバのコンテナイメージはElasticがDocker Hubで提供している公式イメージを使用しています。

ESaaSではクラスタの作成などはすべてユーザがセルフサービスで管理することで、運用コストを下げています。そのため、APMサーバのKubernetes上へのデプロイもユーザがセルフサービスでデプロイできるようになっています。

デプロイの大きな流れは以下のとおりです。

1. ユーザがJenkins経由でAPMサーバを有効にする
2. Jenkinsがキックしたesaas-toolsが管理情報にあるフラグを有効にする
3. Kubernetes上に動いている管理モジュールが管理情報を読み込んで、APMサーバをKuberenetes上にデプロイする

ESaaSの持つ管理情報

ESaaSではECE上のElasticsearchクラスタであるesaas-infoにユーザに払い出したクラスタの情報を管理しています。クラスタの情報にはクラスタ名や利用しているユーザの情報などがあるのですが、そこにAPM関連として以下の情報を追加しました。

エントリ名	説明
外部APM有効フラグ	APMサーバが有効になっているかのフラグ
外部APMシークレットトークン	APMサーバのシークレットトークン

ユーザがJenkinsからAPM付きのクラスタを払い出したときや、払い出し済みのクラスタでAPMを有効にしたとき、esaas-toolsがこれらの情報を追記します。シークレットはesaas-toolsが自動生成します。

シークレットの情報とAPMサーバのエンドポイント情報は、slack経由でユーザに通知されます。

Kubernetes上の管理モジュールの動作

管理情報を読み込んでAPMサーバをデプロイするKubernetes上の管理モジュールとして、esaas-apm-managerを新規に実装しました。esaas-apm-managerは大きく分けて、APMサーバのデプロイと不要になったAPMサーバの削除という2つの役割を持っています。

esaas-apm-managerはKubernetes上に常駐し以下の動作をします。

1. esaas-infoを読み込み
2. APMが有効になっているクラスタの一覧を取得
3. Kubernetes上で動いているAPMサーバの一覧を取得
4. 有効になっているAPMサーバの設定を適用
   esaas-toolsのアップデートやelasticsearchクラスタのVersionupなどの設定変更に追随が必要なケースのため、無条件で適用しています。
5. 有効ではないが、Kubernetes上に稼働しているAPMサーバを削除
6. 15秒 Waitして1.に戻る。

上記のフローにより、新規APMの払い出しや不要になったAPMの削除、またAPMサーバのバージョンアップや設定変更などを15秒周期というほぼリアルタイムで行っています。

まとめ

ESaaSでElastic APMサーバを提供するに当たり、Kubernetes上にAPMサーバをデプロイすることで、インターネット越しのRUMを可能にし、かつベアメタルサーバのリソースを有効に使うことが可能となりました。また、Kubenetes上に管理モジュールを稼働させることで、実装コストを最小にしつつ、利用者からは、ECE上のElasticsearchとシームレスな利用体験ができています。

現在のところ上記でデプロイされたAPMサーバは非常に安定して稼働しており、既存のESaaSの運用工数の範囲内で運用できています。

DSREチームでは引き続きESaaSの機能拡張と運用工数の削減に取り組んでいく予定です。