Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

NAME: Mitsuo(みつお) COMPANY: アイレット株式会社 クラウドインテグレーション事業部 INTEREST: 音楽鑑賞、演奏、体を動かすこと CREDENTIALS: 2022 - 2024 APN ALL AWS Certifications Engineer AWS Community Builder(Networking Content Delivery) iret テクニカルアンバサダー(Advanced) 自己紹介

Slide 3

Slide 3 text

はじめに ・ 構築済みのシステムの運用設計、運用を担当 ・ OSやAWSサービスから出力されるログの分析を行えるようにしたい ・ 顧客で分析ができるようにしたい ※ 実装の話を含みます どうぞ、よろしくお願いします。

Slide 4

Slide 4 text

分析ならやっぱりOpenSearch!? ログアカウントのS3バケットにある ログデータを分析したい！ OpenSearch Serverlessで実装出来るか 検討してみます！

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

アーキテクチャ 3面のログ情報を ログアカウント側に集約させるような アーキテクチャです 右図以外にも複数AWSサービスの ログを集約していました (WAF、SESなど)

Slide 7

Slide 7 text

アーキテクチャ S3にあるデータを OpenSearch Serverlessに 取り込む必要があるね

Slide 8

Slide 8 text

そもそも・・・？ あれ？そもそもOpenSearchが取り込める データ形式ってなんだっけ

Slide 9

Slide 9 text

データ形式について 引用：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

Slide 10

Slide 10 text

あれ？ AWSサービスから出力するログは 須くJSON形式なんだよね？ えっ・・・

Slide 11

Slide 11 text

VPCフローログは・・・？ 引用：Flow log record examples https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records- examples.html

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

うおおおおおおおおおお うおおおおおおおおおおおおおおおお JSON以外のログはJSON形式に変換しないと ダメやん？！？！ OSのログとかもJSONじゃない奴あるよね？？

Slide 14

Slide 14 text

データ加工するには？ そうなんだけど ログの出方も多種多様だし、 それを1から準備するのかなり辛くない？ 僕に任せたらええやん 15分以上かかるなら Python Shellとかも 使えるワイでも ええんやで

Slide 15

Slide 15 text

提案あり SIEM on Amazon OpenSearch Serviceを 検討してみるのが良いんじゃない？

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

調べてみたところ・・・ ・ 良いものではある・・・！ ・ 集約するS3バケットを既に構築済みのため、カスタマイズが必要 ・ コードの量も多く修正箇所が見えづらい ・ 問題が生じた時、どこに手を加えればいいのか ・ かつOSSなので、サポートを受けづらいのではないか ・ そもそも顧客が使うにはハードルが高いのではないか ・ そこはSIerの腕の見せ所！！ 気合いで手順を整備すれば・・・いや、厳しいって

Slide 18

Slide 18 text

導入を断念 さよなら、SIEM on Amazon OpenSearch Service

Slide 19

Slide 19 text

気を取り直して Amazon OpenSearch Ingestionを 検討してみるのが良いんじゃない？

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

これは来たんじゃね？ ログを取り込む設定はYAMLで記述が可能 IaCにCloudFormationを使っていたので、顧客にとっても相性が良いのではないか？

Slide 22

Slide 22 text

Ingestion Pipelineによるログ取り込み とりあえずCloudTrailのログ取り込みを試してみる

Slide 23

Slide 23 text

Koreha… ・ Ingestion Pipelineの取り込みの際に、CloudWatch Logsへエラーを 大量に吐き続ける ・ ログ全体の7、8割がエラーログで気づいたら数万件に・・・笑

Slide 24

Slide 24 text

原因 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

Slide 25

Slide 25 text

フィールドについて JSONフォーマットのKeyの種類＝フィールド数 CloudTrailは多種多様なパラメータがある CloudTrailのデータ構造とOpenSearchの相性が悪い

Slide 26

Slide 26 text

やれることやってみる？ フィールド値のデフォルト数を 増やせば良いのでは？

Slide 27

Slide 27 text

Huh?

Slide 28

Slide 28 text

無理じゃね？ ・ とある技術ブログにて8,000件で運用している猛者を確認 ・ フィールド種の数に応じてメモリの負担が増える ・ Dynamic Mappingの有無に関わらず、そもそも一部パラメータが OpenSearch側でパースできない事象を確認 ・ 正常取り込みに向けて奮闘するも・・・ ・ 新しいパラメータが登場する度に怯える事になるのでは？

Slide 29

Slide 29 text

2週間経過・・・

Slide 30

Slide 30 text

導入を断念 さよなら、OpenSearch Ingestion

Slide 31

Slide 31 text

Athenaが好きになったきっかけ OpenSearchは導入するハードルが 高いです・・・ 具体的な要件がなければ Athenaでスモールスタートしましょう 了解です！ 可視化の要件もないので、 Athenaで構いませんよ！

Slide 32

Slide 32 text

Athenaをスーパーざっくり クエリ実行の分析基盤を構築する必要がないサーバレスサービス S3に分析するデータを格納してクエリを実行するだけ！！ ※ Federated Queryの説明はしません

Slide 33

Slide 33 text

これでようやく解放されるね Athenaなら取り込みも不要だし、 何度か使ったことあるから安心だ！！

Slide 34

Slide 34 text

嘘やろ・・・？ と思ってクエリを書いたら上手くいかない・・・

Slide 35

Slide 35 text

何が上手くいかなかったのか ALBのアクセスログの分析が出来ない Data Firehose経由のログが分析できない

Slide 36

Slide 36 text

ALBのアクセスログの分析が出来ない 列情報は持っているのに、 null値で返ってくる

Slide 37

Slide 37 text

nullのデータを確認した結果

Slide 38

Slide 38 text

原因 シリアライズ「RegexSerDe」では正規表現を使用して、 データを抽出するが、実際のデータと正規表現の値が一致しない場合、 データがNULLとして返されてる仕様がある 2024年5月中旬にドキュメントの更新があり、クエリが変更されていた クエリの見直しにより問題が解決

Slide 39

Slide 39 text

Data Firehoseによってデータが集約される

Slide 40

Slide 40 text

なぜ？ ・ Data FirehoseはCloudWatch Logsのデータを指定した期間あるいは データ量のいずれかを超えた場合にログをバッファリング(1つのファイルに集約) してS3に送出する仕様がある ・ 集約したログは１レコードとして扱われるため、ログ分析ができなくなる

Slide 41

Slide 41 text

これ、1レコードです(見やすいように手で改行)

Slide 42

Slide 42 text

解決策 Data Firehoseの機能で「ログイベントからのみメッセージフィールドを抽出」を有効化する CloudWatch Logsのログイベント情報のみS3に転送する

Slide 43

Slide 43 text

簡単にログ分析が出来る JSON形式ではなく１行１レコードとなる 改行済み

Slide 44

Slide 44 text

急ですが 無事にAthenaでログ分析できるようになりました その後、たくさんクエリを書きました

Slide 45

Slide 45 text

最後に宣伝 Amazon Athenaの概要はご存知な方ばかりだと思います。 初学者向けのブログを書いてみたのでよろしければ！ 澤田先輩と優しく学ぶAmazon Athena https://iret.media/110241

Slide 46

Slide 46 text

おしまい アイレット株式会社 Mitsuo