freeeにおける Kubernetes監視基盤

JAWS 2019 セッション "EC2からKubernetesへの移行をセキュリティ/モニタリングから考える"の後半部分です。

前半はこちら
https://speakerdeck.com/eijisugiura/ec2karakuberneteshefalseyi-xing-wosekiyuriteikarakao-eru

Transcript

1. freee 株式会社 freeeにおける Kubernetes監視基盤の紹介 2019.02.23 JAWS Days
2. - 大学卒業後、メーカ研究所でストレージの研究/開発に従 事 - 昨年1月にfreeeにSREとしてJoin - サービスインフラ構築、監視・アラート基盤構築、障害対 応、生産性改善、マイクロサービス化推進、色々やってま す。 Github: at-k Twitter: at_k Atsushi Kawamura 河村 篤志 freee株式会社 2
3. 3 前半スライドはこちら
4. 4 これまでのお話を３行+αで • freeeは順調にサービスを拡大しており、社会的責任も大きくなってきている • スピード感ある開発と、セキュアかつ高い信頼性のサービスの両立が求められる • マイクロサービス化によるスケーラブルな開発体制、そしてそれを支えるマイクロサービス基盤が必要 そうKubernetes(EKS)だ！
5. 5 アジェンダ 本セッションではfreeeのKubernetesクラスタ監視システムについて説明します • 監視システム一般論 • Elastic Stackの紹介 • freeeでのKubernetes監視システム
6. 6 監視とは
7. 7 監視とはなにか 監視とは、あるシステムやそのシステムのコンポーネントの振る 舞いや出力を観察しチェックし続ける行為である。 入門監視より
8. 8 なぜ監視をするのか • 予防保守 ◦ 近い将来起こり得る問題を監視システムで救い上げる • 異常検知 ◦ サービス・ビジネスの継続に係る障害の場合、最速で復旧させる必要がある ◦ そして少なくとも、発生している問題にすぐに気づけることが重要 • 改善指標 ◦ 何か新しい施策を入れたとしても、metricsが取れていなければ効果を測れない
9. 9 監視システムに求められるもの • 必要なコンポーネント ◦ データ収集 ◦ ストレージ ◦ 可視化 ◦ 分析 ◦ アラート • 正しい監視をする • コスト • 継続的改善が可能
10. 10 Kubernetesでの監視要件 • 監視対象 ◦ クラスタ、クラスタノード、pod • 多様性 ◦ podが大量(pod ≒ process)かつ多様 ◦ 個別に設定をいちいち入れていくのは無理 • 自動スケール ◦ ノードもpodも自動でスケールする ◦ 監視システムも自動で追従しないとつらい
11. 11 Elastic Stackをつかった Kubernetes監視
12. 12 Elastic Stack https://www.elastic.co/products Elastic社が開発・展開するElasticsearchを中心とした ログ・メトリクス管理のためのOSSプロダクト群
13. 13 Elastic Stack - コンポーネント • Data store … Elasticsearch • Visualize … Kibana • Etl tool … Logstash • Data Collector … Elastic Beats
14. 14 Elastic Stack - 開発状況 • 6.0のGAが2017年12月で最新releaseの6.6が先月 • 7.0が現在beta • 以下はElastic BeatsのGithub Insights
15. 15 Elastic Stack - SaaS • Elastic提供のElastic Cloud ◦ 最新のreleaseに追従、新機能をすぐ使える ◦ 3rd Party pluginが使える ◦ X-Pack(有償機能)が使える ▪ 全機能の有効化は追加ライセンス必要 • AWS提供の Elasticsearch Service ◦ 上記のElastic Cloudのメリットがない代わりに低コスト ◦ IAMやSG、CognitoといったAWSの機能を活用できる ▪ freeeでは現状こちらを利用
16. 16 freeeでの監視基盤
17. 17 全体構成
18. 18 全体構成 アラート データ長期保存・分析 データ短期保存 検索 可視化 データ収集
19. 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. 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://<elasticsearcht>"] username: “xxx" password: "yyy" rbac: create: true values.yaml
21. 21 filebeat + Kibana k8s由来の メタデータ ログ
22. 22 metricbeat • Lightweight Shipper for Metrics • 基本的にはfilebeatと同じくnode毎に配置にエージェントとして配置され、メトリクスを収集する • クラスタメトリクスの採取は別途`kube-state-metircs`のデプロイが必要 • メトリクスとしてはnode/pod単位のcpu/memory/network/storage、などが取得できる
23. 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://<elasticsearcht>"] username: “xxx" password: "yyy" modules: modules: system: enabled: true config: - module: system period: 10s metricsets: - cpu - ... deployment: config: <daemonsetと同じ設定> modules: <取得対象metrics設定> values.yaml
24. 24 metricbeat + Kibana • filebeatと同じくk8sメタデータ付きで設定したmetricsが取得できる
25. 25 metricbeat + Kibana Dashboard作例
26. 26 metricbeat + Kibana Dashboard作例
27. 27 Kinesisでの中継 • Kinesisの役割 ◦ ログを確実に送るための中継 ◦ ログの送付先選択・加工に拡張性をもたせる ▪ ここではElasticsearchとS3に送付する構成 ▪ 必要であれば送付先を増やしたり、lambdaを間に挟んで加工したりすることも可能 • Kinesis送付のための設定 ◦ filebeat/metricbeatの送付先としてkinesisはデフォルトに含まれていない ◦ 追加のログ送付先(output)はpluginとして拡張可能 ◦ ここではawsbeatsというOSSを使用
28. 28 アラート • ログを取るだけでは片手落ち、アラートを設定しましょう • AWS Elasticsearch Serviceで提供されるElasticsearch, KibanaにはAlert機能がない ◦ Elastic社の提供する有償パッケージ(X-Pack)にはKibanaに統合されたAlert機能あり ◦ Elastic Cloudを契約すれば使えます • 一旦OSSでできることを模索 ◦ ElastAlertを導入 28
29. 29 elastalert • developed by Yelp ◦ https://github.com/Yelp/elastalert • 何ができるのか ◦ elasticsearchに対してクエリを投げて、条件にマッチした場合にアラートを投げる ◦ 通知方法は色々。とりあえずslackへ
30. 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. 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. 32 振り返り
33. 33 良かったこと • 導入が楽 ◦ agentはhelm chartが用意されており、環境に合わせて設定を書き換えればすぐ入れられる ◦ バックエンドは共通なので、一度構築すれば同じデータフローに乗ってくれる • logとmetrics管理を共通化 ◦ バックエンドが同じ(elasticsearch + kibana)なので、同じ感覚で参照できる • Kibanaの柔軟なクエリ(lucene)で大体のVisualizeはできる • 同じくluceneを使ってフィルタをかけるelastalertも、大体のことはできる
34. 34 微妙だったところ • Kibanaのvisualizeはまだexperimentな機能がいくつか • Visualize/Dashboardのアイテムを作るのがなれるまで難しい ◦ luceneが自由度高すぎて逆に難しい ◦ metricbeatからsetupコマンドで作れるが、必要十分でない（おおすぎ） ◦ ダッシュボードのexport/import機能でなんとか乗り切れるか • ElastAlertは設定難易度高い ◦ 単純に複雑 ◦ 正しく書けているか検証し辛い、testコマンドあるが遅い（ログ検査範囲が1日単位） ◦ ルールの管理方法は検討要 • beats系でたまにバグを踏む（修正は早い ◦ kinesis送付plugin(awsbeats)を公式が取り込んでくれると嬉しいlogstashからkinesisはある) • 監視システム自体の監視 ◦ elasticsearchの容量枯渇や、kinesisの設定ミスによる詰まり ◦ ログ基盤の死活監視もまた必要
35. 35 今後 • elasticstackをそのまま使うかもしれないし、他の方法に変えるかも知れない ◦ 導入が簡単で、かつ、コンポーネント単位での置き換えが容易な構成の強み ◦ 運用中での改善・試行錯誤がしやすい • 他のデータ収集ツールの導入 ◦ apm serverやheart beat等を入れて監視を強化 ◦ 基本的に今のアーキテクチャ(elasticsearch + elastalert)であればスムーズに組み込める • 権限委譲の仕組みをすすめる ◦ ダッシュボードやアラートルールなどをテンプレ化して、新規作成を容易にする ◦ CIを整備して、誰でも簡単に機能追加できるようにする
36. 36 終わり
37. スモールビジネスに携わる すべての人が「創造的な活動」に フォーカスできるよう
38. 38 メモ
39. 39 他のソリューションとの比較 • Elastic Cloud ◦ 少し高い、アラートついてる、最新機能使える、plugin入れられる • fluentd ◦ ログだけ ◦ ログに色々加工ができる ◦ helmある ◦ バックエンドは選択可能(s3なりelasticsearchなり) • mackerel ◦ helmない ◦ kubernetesは最近対応 ◦ 有料、バックエンドは固定(マネージドサービス)
40. 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. 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