freee 株式会社 freeeにおける Kubernetes監視基盤の紹介 2019.02.23 JAWS Days 

- 大学卒業後、メーカ研究所でストレージの研究/開発に従 事 - 昨年1月にfreeeにSREとしてJoin - サービスインフラ構築、監視・アラート基盤構築、障害対 応、生産性改善、マイクロサービス化推進、色々やってま す。 Github: at-k Twitter: at_k Atsushi Kawamura 河村 篤志 freee株式会社 2 

3 前半スライドはこちら 

4 これまでのお話を３行+αで ● freeeは順調にサービスを拡大しており、社会的責任も大きくなってきている ● スピード感ある開発と、セキュアかつ高い信頼性のサービスの両立が求められる ● マイクロサービス化によるスケーラブルな開発体制、そしてそれを支えるマイクロサービス基盤が必要 そうKubernetes(EKS)だ！ 

5 アジェンダ 本セッションではfreeeのKubernetesクラスタ監視システムについて説明します ● 監視システム一般論 ● Elastic Stackの紹介 ● freeeでのKubernetes監視システム 

6 監視とは 

7 監視とはなにか 監視とは、あるシステムやそのシステムのコンポーネントの振る 舞いや出力を観察しチェックし続ける行為である。 入門監視より 

8 なぜ監視をするのか ● 予防保守 ○ 近い将来起こり得る問題を監視システムで救い上げる ● 異常検知 ○ サービス・ビジネスの継続に係る障害の場合、最速で復旧させる必要がある ○ そして少なくとも、発生している問題にすぐに気づけることが重要 ● 改善指標 ○ 何か新しい施策を入れたとしても、metricsが取れていなければ効果を測れない 

9 監視システムに求められるもの ● 必要なコンポーネント ○ データ収集 ○ ストレージ ○ 可視化 ○ 分析 ○ アラート ● 正しい監視をする ● コスト ● 継続的改善が可能 

10 Kubernetesでの監視要件 ● 監視対象 ○ クラスタ、クラスタノード、pod ● 多様性 ○ podが大量(pod ≒ process)かつ多様 ○ 個別に設定をいちいち入れていくのは無理 ● 自動スケール ○ ノードもpodも自動でスケールする ○ 監視システムも自動で追従しないとつらい 

11 Elastic Stackをつかった Kubernetes監視 

12 Elastic Stack https://www.elastic.co/products Elastic社が開発・展開するElasticsearchを中心とした ログ・メトリクス管理のためのOSSプロダクト群 

13 Elastic Stack - コンポーネント ● Data store … Elasticsearch ● Visualize … Kibana ● Etl tool … Logstash ● Data Collector … Elastic Beats 

14 Elastic Stack - 開発状況 ● 6.0のGAが2017年12月で最新releaseの6.6が先月 ● 7.0が現在beta ● 以下はElastic BeatsのGithub Insights 

15 Elastic Stack - SaaS ● Elastic提供のElastic Cloud ○ 最新のreleaseに追従、新機能をすぐ使える ○ 3rd Party pluginが使える ○ X-Pack(有償機能)が使える ■ 全機能の有効化は追加ライセンス必要 ● AWS提供の Elasticsearch Service ○ 上記のElastic Cloudのメリットがない代わりに低コスト ○ IAMやSG、CognitoといったAWSの機能を活用できる ■ freeeでは現状こちらを利用 

16 freeeでの監視基盤 

17 全体構成 

18 全体構成 アラート データ長期保存・分析 データ短期保存 検索 可視化 データ収集 

19 filebeat ● Lightweight Log Shipper ● sourceとログ送付先のoutputが基本設定項目 ● k8sクラスタでは`kubectl logs`コマンドで取得できるログを簡単にoutput先に送れる https://kubernetes.io/docs/concepts/cluster-administration/logging/ Kubernetes公式のlogging architecture解説図 - filebeatはログエージェントとして各ノードにdaemonset で配置 - ノードが増えたら自動で配置 - 各podのログファイル(標準出力先)を監視し、設定さ れたバックエンドに送付する - アプリケーション側は特に設定不要 - 個別設定不要(入れても良い) 

20 filebeat 設定と導入 ● helm chartあります $ helm upgrade --install filebeat stable/filebeat -f values.yaml $ helm list | grep filebe filebeat ● 簡単！ ○ elasticsearchのsetupは省略 config: filebeat.prospectors: - type: log enabled: true paths: - /var/log/*.log - type: docker containers.ids: - '*' processors: - add_kubernetes_metadata: in_cluster: true - drop_event: when: equals: kubernetes.container.name: filebeat output.file: enabled: false output.elasticsearch: hosts: ["https://"] username: “xxx" password: "yyy" rbac: create: true values.yaml 

21 filebeat + Kibana k8s由来の メタデータ ログ 

22 metricbeat ● Lightweight Shipper for Metrics ● 基本的にはfilebeatと同じくnode毎に配置にエージェントとして配置され、メトリクスを収集する ● クラスタメトリクスの採取は別途`kube-state-metircs`のデプロイが必要 ● メトリクスとしてはnode/pod単位のcpu/memory/network/storage、などが取得できる 

23 metricbeat 設定と導入 ● helm chartあります $ helm upgrade --install filebeat stable/metricbeat -f values.yaml ● 簡単！ ○ values.yamlは取得metricsに応じて設定がだいぶ膨ら むのでかなり省略しています ○ クラスタメトリックを取る場合は ■ kube-state-metricをhelmでインストール ■ deploymentのmodules設定に取得設定を追加 daemonset: config: json.keys_under_root: true json.ignore_decoding_error: true output.file: enabled: false output.elasticsearch: hosts: ["https://"] username: “xxx" password: "yyy" modules: modules: system: enabled: true config: - module: system period: 10s metricsets: - cpu - ... deployment: config: modules: <取得対象metrics設定> values.yaml 

24 metricbeat + Kibana ● filebeatと同じくk8sメタデータ付きで設定したmetricsが取得できる 

25 metricbeat + Kibana Dashboard作例 

26 metricbeat + Kibana Dashboard作例 

27 Kinesisでの中継 ● Kinesisの役割 ○ ログを確実に送るための中継 ○ ログの送付先選択・加工に拡張性をもたせる ■ ここではElasticsearchとS3に送付する構成 ■ 必要であれば送付先を増やしたり、lambdaを間に挟んで加工したりすることも可能 ● Kinesis送付のための設定 ○ filebeat/metricbeatの送付先としてkinesisはデフォルトに含まれていない ○ 追加のログ送付先(output)はpluginとして拡張可能 ○ ここではawsbeatsというOSSを使用 

28 アラート ● ログを取るだけでは片手落ち、アラートを設定しましょう ● AWS Elasticsearch Serviceで提供されるElasticsearch, KibanaにはAlert機能がない ○ Elastic社の提供する有償パッケージ(X-Pack)にはKibanaに統合されたAlert機能あり ○ Elastic Cloudを契約すれば使えます ● 一旦OSSでできることを模索 ○ ElastAlertを導入 28 

29 elastalert ● developed by Yelp ○ https://github.com/Yelp/elastalert ● 何ができるのか ○ elasticsearchに対してクエリを投げて、条件にマッチした場合にアラートを投げる ○ 通知方法は色々。とりあえずslackへ 

30 elastalertの構築 ● 構築方法1: k8s cluster内にdeployする ○ helm chartがあるので導入は容易 ○ 課題 ■ cluster単位障害で巻き込まれる ■ ruleの管理・渡し方 ● CRDを定義し、operatorごしに渡すなど検討 ● 構築方法2: AWS lambdaにデプロイし定期起動 ○ https://github.com/beezz/elastalert-lambda ○ 課題 ■ ルール数に合わせて起動頻度の見直しが必要 ■ 新しいルールを追加するのにlambdaをbuildしなおす必要 ● 構築方法3: AWS ECSにデプロイ ○ https://hub.docker.com/r/bitsensor/elastalert/ ■ 半公式のrest api付きelastalertのdockerfileが公開 ○ これを元にECS上で動作させる ○ 今はこちらを検証しています アラート 

31 elastalert 例 ● 一定頻度以上に指定のwordがログにあればalert ● filterにはKibanaのquery（lucene）が使える ● alert先はslackを始めいくつか用意されている 公式のrest api付きdocker imageだと、 ● ルールのテスト、投入 ● 存在するルールやステータス確認 ...などができます # Alert when the rate of events exceeds a threshold name: OutOfMemoryError type: frequency index: logstash-%Y.%m.%d* use_strftime_index: true num_events: 1 timeframe: hours: 1 filter: - query_string: query: "message: OutOfMemoryError OR log: OutOfMemoryError" alert: - "slack" rules.yaml 

32 振り返り 

33 良かったこと ● 導入が楽 ○ agentはhelm chartが用意されており、環境に合わせて設定を書き換えればすぐ入れられる ○ バックエンドは共通なので、一度構築すれば同じデータフローに乗ってくれる ● logとmetrics管理を共通化 ○ バックエンドが同じ(elasticsearch + kibana)なので、同じ感覚で参照できる ● Kibanaの柔軟なクエリ(lucene)で大体のVisualizeはできる ● 同じくluceneを使ってフィルタをかけるelastalertも、大体のことはできる 

34 微妙だったところ ● Kibanaのvisualizeはまだexperimentな機能がいくつか ● Visualize/Dashboardのアイテムを作るのがなれるまで難しい ○ luceneが自由度高すぎて逆に難しい ○ metricbeatからsetupコマンドで作れるが、必要十分でない（おおすぎ） ○ ダッシュボードのexport/import機能でなんとか乗り切れるか ● ElastAlertは設定難易度高い ○ 単純に複雑 ○ 正しく書けているか検証し辛い、testコマンドあるが遅い（ログ検査範囲が1日単位） ○ ルールの管理方法は検討要 ● beats系でたまにバグを踏む（修正は早い ○ kinesis送付plugin(awsbeats)を公式が取り込んでくれると嬉しいlogstashからkinesisはある) ● 監視システム自体の監視 ○ elasticsearchの容量枯渇や、kinesisの設定ミスによる詰まり ○ ログ基盤の死活監視もまた必要 

35 今後 ● elasticstackをそのまま使うかもしれないし、他の方法に変えるかも知れない ○ 導入が簡単で、かつ、コンポーネント単位での置き換えが容易な構成の強み ○ 運用中での改善・試行錯誤がしやすい ● 他のデータ収集ツールの導入 ○ apm serverやheart beat等を入れて監視を強化 ○ 基本的に今のアーキテクチャ(elasticsearch + elastalert)であればスムーズに組み込める ● 権限委譲の仕組みをすすめる ○ ダッシュボードやアラートルールなどをテンプレ化して、新規作成を容易にする ○ CIを整備して、誰でも簡単に機能追加できるようにする 

36 終わり 

スモールビジネスに携わる すべての人が「創造的な活動」に フォーカスできるよう 

38 メモ 

39 他のソリューションとの比較 ● Elastic Cloud ○ 少し高い、アラートついてる、最新機能使える、plugin入れられる ● fluentd ○ ログだけ ○ ログに色々加工ができる ○ helmある ○ バックエンドは選択可能(s3なりelasticsearchなり) ● mackerel ○ helmない ○ kubernetesは最近対応 ○ 有料、バックエンドは固定(マネージドサービス) 

40 他のソリューションとの比較 ● prometheus ○ helmある ○ ログはとれない ○ exporterだけprometheusにしてバックエンドはelasticsearchとかもできる ■ metricbeatがprometheus end pointに対応している ■ grafanaやprometheus serverを用意する場合は自前運用必要 ● grafanaはプリセットの設定がいい感じな気がする ● それぞれについてもhelmある。k8sクラスタ内で導入するなら案外楽かも ● data dog ○ fluentd + data dog logs使えばログとメトリックの統合管理も可能 ○ agentはhelmある ○ 有料 ○ ちゃんと触れていないので、後日トライアル版触ってみたい… ありふれた教訓ではあるが、無料であることは必ずしもメリットではない（最終的に何にコストを払うか 

41 Elastic Stack vs. Prometheus ● push / pull ○ agentとexporter ● 導入はどっちも簡単 ○ helm chartあり ● 高い汎用性 vs. メトリクス監視特化 ● マネージドサービスあり、なし ● lucene、PromQL ● elastalertでのalert作成は結構しんどい(グラフを見ながら設定したりできない) grafana お試し https://play.grafana.org/d/000000012/grafana-play-home?orgId=1