ハイブリッドクラウドに対応したログ集約・解析プラットフォームのためのHEC活⽤法

Transcript

1. ハイブリッドクラウドに対応したログ集約・解 析プラットフォームのためのHEC活⽤法 牧垣 秀⼀朗 (makigaki_shuichiro@cyberagent.co.jp) Shuichiro MAKIGAKI 株式会社サイバーエージェント 全社システム本部 GOJAS 2019-06
2. はじめに
3. はじめに • 好きです、Splunk 「⼀度Splunkに⼊れさえすれば、あとはなんとでもなる」という安⼼感 ログのパース・検索・データの統合・統計処理が強⼒ 運⽤する上で気にすることが少ない（ディスク容量とライセンス使⽤量くらい︖） グラフもアラートも作れる • 思考停⽌⽒「んーと……もうSplunkでいいんじゃね︖︖︖」
4. ご時世 • ハイブリッドクラウド • IBM「ハイブリッド・クラウドとは何か」https://www.ibm.com/blogs/solutions/jp-ja/what-is-hybrid-cloud/ 広く⼀般のユーザーと同じ環境を利⽤するパブリック・クラウド、専⽤の環境を利⽤するプライ ベート・クラウド、そしてすでに保有している⾃社のIT資産（オンプレミス）を組み合わせて最 適なITインフラを構築するという考え⽅を指します。 • RedHat「ハイブリッドクラウドとは」https://www.redhat.com/ja/topics/cloud-computing/what-is-hybrid-cloud パブリッククラウドとプライベートクラウド環境を 1 つまたは複数組み合わせたものです。これ は、サードパーティ企業が所有し管理するハードウェアと、クラウドを使⽤する企業が所有して いるハードウェアからなる仮想リソースのプールです。
5. オンプレ＋AWS • オンプレのActive Directory • オンプレのファイルサーバー • バッチ的なLambda • 社内サービスを集約したECSクラスタ ちょっとしたもの、を動かすのに便利 SSOパスワード変更、サービスステータスページ、IPAM、など ……だけだったはずが、慣れてきて、社内端末のRadiusサーバーまでECSに乗せはじめる始末︕ • 多様な場所からログを集める必要がでてきた 認証周りのAuditとか、バッチのアラートとか
6. 問題点1︓データの前処理 • データ解析でもっとも⼤変なのは「前処理」 クレンジング（表記揺れや誤記の修正）＋フィルタリング（不要データの削除） ⼯数の9割が前処理（※個⼈の感s） • Splunkは「たった⼀つの重要なデータ」を発⾒できるてしまうので、 変なデータが混じっていて欲しくない 前処理しなくても⼊れちゃえばSplunkがなんとかしてくれるてしまう のだけれど、sourcetypeとfield extractionがカオス化します（経験） 最初からJSONとかで⼊れてくれると全員の仕事が楽になる
7. 問題点2︓データの⼊⼒ • データの冗⻑化と負荷分散 Indexerクラスタを作ってデータを冗⻑化したい ＋データ読み込み負荷を分散したい • Splunkフォワーダーの設定は難しい ⼝で⾔えない・テンプレ化が難しい・情報が少ない（vs. fluentd/logstash）・Splunk固有の単語が 多い・ドキュメントが英語か、または英語 • CloudWatch Logsも⼊⼒したい Lambdaが便利すぎて、ちょっとしたバッチもLambdaで書いていたらすごく増えてしまった が、CloudWatch Logs単体では検索・可視化・アラートの機能はイマイチ しかも意外とお⾼い（EBSを使う感覚）ので、Splunkに⼊れたものは削除したい
8. 問題点3︓プラットフォーム化 • あまり質問されても困る ログ⼊れていいですか︖ → その量ならライセンス⾜りるしいいんじゃない︖としか…… → あ、でもIndexerへの転送が必要だからinputs.confとoutputs.conf書いて再起動しないと…… → え︖⼊れたのDebugレベルのログですか︖それ使います︖ このAppどう使うんですか︖ → 僕も知らないのでググっていただいて…… こういうのどうやったらできるんですか︖ → ちょっと僕もわからないです…… ゴミ⼊れすぎてわけがわからなくなったよ → つらい…… • 安全に「好きにデータ⼊れていじってもらっていいですよ」 と⾔いたい 使ってみてもらわないことには布教が進まない（布教したい）
9. やりたいこと • データ前処理の脱職⼈芸 • 簡単で安全なデータ⼊⼒ • プラットフォーム化による脱⼿運⽤ • ……による⼯数の削減と諦めの防⽌を狙う
10. これ、HTTP Event Collectorでなんと かできるのでは︖
11. Splunk側の実装 2
12. 全体図（シンプル） Indexer Search Head
13. HTTP Event Collector (HEC) • HTTPでログ（イベント）を⼊⼒できる 既定のJSONフォーマットでエンドポイントにHTTP POSTする トークン認証 • HTTPなので（⻑） HTTPバランサで冗⻑構成と負荷分散が可能 Fluentd、Logstash、AWS Kinesis Firehoseなど、HEC対応のログソースが多数 • HTTPなので（短） 速度はHTTPの程度 圧縮はできない（たぶん）
14. Indexer • 実Indexが置かれるインスタンス つまり実データが保管される、ディスクが⼤きめのインス タンス • データは3冗⻑ データのロストは意外と痛い（Audit⽬的だから） クラスタな形態は奇数がベター（2冗⻑でも稼働はする） データ読み取りを並列化したい • 実装 EC2 c5d.large: 2 vCPU・4GB RAM・NVMe 50GB（速い） と、500GBのEBS（速くない）をアタッチ 必要な速度に応じて、NVMeとEBSでIndexを分離 Indexer Search Head
15. Search Head • いわゆる「Splunkの画⾯」 Indexer Clusterの⾯倒をみるCluster Masterを兼務 ここを冗⻑化・並列化することも可能 だが、Indexerより可⽤性は低くてよいため、1インスタンス でまかなう ケチるべきところはケチる。が、もちろん要件による。 • 実装 c5.xlarge: 4 vCPU・8GB RAM・64GB EBS ケチ構成と思いきや、運⽤してみると意外と余裕アリ 実際にはHECと同じALBを介する構成 HECとWebでホスト名を分けて、SNIで振り分け Search Head
16. Index構成 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme1n1 259:0 0 500G 0 disk /mnt/splunk-cold nvme2n1 259:1 0 46.6G 0 disk /mnt/splunk-warm nvme0n1 259:2 0 64G 0 disk !"nvme0n1p1 259:3 0 64G 0 part / #"nvme0n1p128 259:4 0 1M 0 part splunk-coldを「silver」インデックス splunk-warmを「gold」インデックス と命名し、必要要件に応じて使い分け 実際には、Summary Indexはgold、それ以外はsilverに⼊れちゃってます
17. AWS側の実装 3
18. 全体図（やっぱりシンプル） Firehose CloudWatch Logs Transform HEC Endpoint
19. AWS CloudWatch Logs • AWSで出るログはほとんどここに集まる Lambdaからも マネージドサービスのログも Subscription Filterという機能で、特定のログをFirehoseに転送 できる そしてFirehoseからSplunkへ転送できる（後述） ログのライフサイクルは短めに設定する Firehose CloudWatch Logs Transform HEC Endpoint
20. AWS Kinesis Firehose • Firehoseとは︖ （ストリーム型の）データを集めて、S3やSplunkなどに転 送・保管してくれるサービスです Splunkへの転送にはHECを使います • Lambdaによるデータ変換を組み込めるのが強い 1. CloudWatchにログイベントが⽣成 2. CloudWatchからFirehoseにデータを転送 3. FirehoseでデータをSplunk互換に変換 4. Splunkに転送 がシンプルな仕組みでできてしまいます Firehose Transform HEC Endpoint
21. ⼯夫 4
22. Loggerライブラリを⾃作 • Firehoseからの転送時にindexやsourcetypeの指定ができない なので、データはデフォルトIndexに⼊ります が、イベントにメタデータ（JSONのキー）として追記すれば指定が可能です • ということをするログライブラリを書きました Python⽤ 通常のインターフェースにログを書き出すだけで、Splunkに⼊る形にしてくれます pip install splunk-hec-stream (https://github.com/shuichiro-makigaki/splunk_hec_stream) Lambda Layer化しており、layerを使うだけでライブラリが使えるようにしてます リポジトリにはTerraform、processorが含まれているので、同じ仕組みはすぐに作れます︕お試しを︕
23. Loggerライブラリを⾃作 from splunk_hec_stream.logging import SplunkHECStreamHandler logging.basicConfig(level=logging.INFO, handlers=[ SplunkHECStreamHandler("main","splunk-logger-test", "aws:lambda", "_json") ]) logging.info({"key1": "value1"}) logging.info("test") {“loggingHandler”: "SplunkHECStreamHandler", “time”: 1557301830.617483, "host": "aws:lambda", "index": "main", "source": "splunk-logger-test", "sourcetype": "_json", "event":{"key1": "value1"}}
24. App Homeをリッチ化
25. Sandboxの提供 • お試し⽤Index • 容量1G＋保管期間7⽇というゴミ箱仕様 • 「あれやこれをしたい」→「いったんSandboxに⼊れてごにょごにょしてみる」 • 「承認」的な仕組み（Splunk使うの︖確認など）を省略できる やってみないとわからないことは、やってみるしかない
26. Terraform + Ansible • *.confの書き換え問題 Indexerが別ホストなので、転送設定が必要 Indexerクラスタ内のsilver indexを使って欲しい（Search Head内には保管しない） ⼿作業では変更履歴が追えない → 運⽤が属⼈化 → システムの維持可能性が低下 • そこでTerraformとAnsibleで構成を管理 • 設定変更︓Ansible書き換えて流すだけ • 構成管理︓トラブル時の差分チェック＋修正＋⾮常時の作り直し • ⼿運⽤が減り、本来の解析に集中できる
27. 現在の様⼦ 5
28. 例 • HEC経由 MACアドレス認証ログ Radius認証ログ テレビ会議端末監視（Zoom Rooms） • その他も ActiveDirectory認証ログ Infoblox DHCPログ、など • AWS Appも使⽤ EC2インスタンス情報との統合検索が可能に
29. 使⽤量
30. お⾦ 0 2 4 6 8 10 12 2019/6/17 2019/6/18 2019/6/19 2019/6/20 USD Kinesis Firehose EC2 その他 EC2 ELB EC2 インスタンス
31. まとめ 6
32. 作ってみて • やりたかったことはおおむね実現 データの前処理の脱職⼈芸・簡単で安全なデータ⼊⼒・プラットフォーム化で脱⼿運⽤ • なにより、ログの集約や解析という⾏為が浸透した（と思う） 「ログ……︖は、特に⾒てないですね……。」といったことはなくなりつつある 作った物の使われ具合を⾒える化できるようになった • 解決できていない課題 検索クエリの書き⽅⾃体の助けにはなっていない もはやSplunkから抜け出せない︕
33. ありがとうございました