S3上のログを分析したいだけなのに

Transcript

1. S3上のログを分析したいだけなのに Mitsuo
2. NAME: Mitsuo(みつお) COMPANY: アイレット株式会社 クラウドインテグレーション事業部 INTEREST: 音楽鑑賞、演奏、体を動かすこと CREDENTIALS: 2022 - 2024 APN ALL AWS Certifications Engineer AWS Community Builder(Networking Content Delivery) iret テクニカルアンバサダー(Advanced) 自己紹介
3. はじめに ・ 構築済みのシステムの運用設計、運用を担当 ・ OSやAWSサービスから出力されるログの分析を行えるようにしたい ・ 顧客で分析ができるようにしたい ※ 実装の話を含みます どうぞ、よろしくお願いします。
4. 分析ならやっぱりOpenSearch!? ログアカウントのS3バケットにある ログデータを分析したい！ OpenSearch Serverlessで実装出来るか 検討してみます！
5. OpenSearch Severlessとは VPC上に配置しなくても OpenSearchが使えるなら 顧客の希望にも合致するよね？ 引用：Amazon OpenSearch Serverless AWS Black Belt Online Seminar https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black- Belt_2023_AmazonOpenSearchServerless_0131_v1.pdf
6. アーキテクチャ 3面のログ情報を ログアカウント側に集約させるような アーキテクチャです 右図以外にも複数AWSサービスの ログを集約していました (WAF、SESなど)
7. アーキテクチャ S3にあるデータを OpenSearch Serverlessに 取り込む必要があるね
8. そもそも・・・？ あれ？そもそもOpenSearchが取り込める データ形式ってなんだっけ
9. データ形式について 引用：Amazon OpenSearch Serverless AWS Black Belt Online Seminar https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black- Belt_2023_AmazonOpenSearchServerless_0131_v1.pdf
10. あれ？ AWSサービスから出力するログは 須くJSON形式なんだよね？ えっ・・・
11. VPCフローログは・・・？ 引用：Flow log record examples https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records- examples.html
12. CloudFront、ALBのアクセスログは・・・？ CloudFront 標準ログ ALBアクセスログ 引用： Configure and use standard logs (access logs) https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#AccessLogsFile Naming Access logs for your Application Load Balancer https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
13. うおおおおおおおおおお うおおおおおおおおおおおおおおおお JSON以外のログはJSON形式に変換しないと ダメやん？！？！ OSのログとかもJSONじゃない奴あるよね？？
14. データ加工するには？ そうなんだけど ログの出方も多種多様だし、 それを1から準備するのかなり辛くない？ 僕に任せたらええやん 15分以上かかるなら Python Shellとかも 使えるワイでも ええんやで
15. 提案あり SIEM on Amazon OpenSearch Serviceを 検討してみるのが良いんじゃない？
16. SIEM on Amazon OpenSearch Serviceとは？ AmazonがOSSとしてGitHubに公開してるコード CloudFormation、CDKにて提供 引用：SIEM on Amazon OpenSearch Service https://github.com/aws-samples/siem-on-amazon-opensearch- service/blob/main/README_ja.md
17. 調べてみたところ・・・ ・ 良いものではある・・・！ ・ 集約するS3バケットを既に構築済みのため、カスタマイズが必要 ・ コードの量も多く修正箇所が見えづらい ・ 問題が生じた時、どこに手を加えればいいのか ・ かつOSSなので、サポートを受けづらいのではないか ・ そもそも顧客が使うにはハードルが高いのではないか ・ そこはSIerの腕の見せ所！！ 気合いで手順を整備すれば・・・いや、厳しいって
18. 導入を断念 さよなら、SIEM on Amazon OpenSearch Service
19. 気を取り直して Amazon OpenSearch Ingestionを 検討してみるのが良いんじゃない？
20. Amazon OpenSearch Ingestionとは ・ Open Searchドメイン、コレクションにリアルタイムでログ、メトリック、トレースデータを連携できる サーバレスなコレクタのこと ・ データ収集、変換、配信を担うLogstashやJaegerが不要で利用可能 ・ 実際の取り込みの設定をOpenSearch Ingestion Pipelineという 引用：SIEM on Amazon OpenSearch Service https://github.com/aws-samples/siem-on-amazon-opensearch- service/blob/main/README_ja.md
21. これは来たんじゃね？ ログを取り込む設定はYAMLで記述が可能 IaCにCloudFormationを使っていたので、顧客にとっても相性が良いのではないか？
22. Ingestion Pipelineによるログ取り込み とりあえずCloudTrailのログ取り込みを試してみる
23. Koreha… ・ Ingestion Pipelineの取り込みの際に、CloudWatch Logsへエラーを 大量に吐き続ける ・ ログ全体の7、8割がエラーログで気づいたら数万件に・・・笑
24. 原因 Dynamic Mappingという機能があり、取り込んだレコード に対して、自動でフィールドを定義可能 取り込めるフィールド数のデフォルト値(1,000)を 超えてしまったエラーだった 参考： Elastic(Approaches to deal with “Limit of total fields [1000] in index has been exceeded”) https://discuss.elastic.co/t/approaches-to-deal-with-limit-of-total-fields-1000-in-index-has-been- exceeded/241039/1
25. フィールドについて JSONフォーマットのKeyの種類＝フィールド数 CloudTrailは多種多様なパラメータがある CloudTrailのデータ構造とOpenSearchの相性が悪い
26. やれることやってみる？ フィールド値のデフォルト数を 増やせば良いのでは？
27. Huh?
28. 無理じゃね？ ・ とある技術ブログにて8,000件で運用している猛者を確認 ・ フィールド種の数に応じてメモリの負担が増える ・ Dynamic Mappingの有無に関わらず、そもそも一部パラメータが OpenSearch側でパースできない事象を確認 ・ 正常取り込みに向けて奮闘するも・・・ ・ 新しいパラメータが登場する度に怯える事になるのでは？
29. 2週間経過・・・
30. 導入を断念 さよなら、OpenSearch Ingestion
31. Athenaが好きになったきっかけ OpenSearchは導入するハードルが 高いです・・・ 具体的な要件がなければ Athenaでスモールスタートしましょう 了解です！ 可視化の要件もないので、 Athenaで構いませんよ！
32. Athenaをスーパーざっくり クエリ実行の分析基盤を構築する必要がないサーバレスサービス S3に分析するデータを格納してクエリを実行するだけ！！ ※ Federated Queryの説明はしません
33. これでようやく解放されるね Athenaなら取り込みも不要だし、 何度か使ったことあるから安心だ！！
34. 嘘やろ・・・？ と思ってクエリを書いたら上手くいかない・・・
35. 何が上手くいかなかったのか ALBのアクセスログの分析が出来ない Data Firehose経由のログが分析できない
36. ALBのアクセスログの分析が出来ない 列情報は持っているのに、 null値で返ってくる
37. nullのデータを確認した結果
38. 原因 シリアライズ「RegexSerDe」では正規表現を使用して、 データを抽出するが、実際のデータと正規表現の値が一致しない場合、 データがNULLとして返されてる仕様がある 2024年5月中旬にドキュメントの更新があり、クエリが変更されていた クエリの見直しにより問題が解決
39. Data Firehoseによってデータが集約される
40. なぜ？ ・ Data FirehoseはCloudWatch Logsのデータを指定した期間あるいは データ量のいずれかを超えた場合にログをバッファリング(1つのファイルに集約) してS3に送出する仕様がある ・ 集約したログは１レコードとして扱われるため、ログ分析ができなくなる
41. これ、1レコードです(見やすいように手で改行)
42. 解決策 Data Firehoseの機能で「ログイベントからのみメッセージフィールドを抽出」を有効化する CloudWatch Logsのログイベント情報のみS3に転送する
43. 簡単にログ分析が出来る JSON形式ではなく１行１レコードとなる 改行済み
44. 急ですが 無事にAthenaでログ分析できるようになりました その後、たくさんクエリを書きました
45. 最後に宣伝 Amazon Athenaの概要はご存知な方ばかりだと思います。 初学者向けのブログを書いてみたのでよろしければ！ 澤田先輩と優しく学ぶAmazon Athena https://iret.media/110241
46. おしまい アイレット株式会社 Mitsuo