AWS S3上のデータを SQS と組み合わせて Splunkに取り込む

8121 ワード
Splunk AWS sqs S3 AWS テキストリンク

(追記) SNSは特に不要でしたので記事を修正しました。

はじめに

先日、AWS S3上のデータを Splunkに取り込む記事を書きましたが、シンプルな設定のためスモール環境には適しておりますが、Bucket内のデータ量が増えてくると処理が追いつかずにリアルタイムな分析が出来なかったり、取り込めないなどのデータ欠損の可能性が出てきます。また耐障害性という観点でも弱い構成です。

そこでSplunkが推奨しているSQSと組み合わせた方法で、スケール問題とデータ信頼性問題を解決していきたいと思います。

このような構成にしておくことで、データの配信に関してはSQSが受信確認まで行ってくれますし、Splunk側のInputを増やす事で取り込み速度もスケールさせることができます。つまり信頼性と性能をカバーすることができます。

AWS SQS サービスについては、こちらの解説が詳しくて参考にさせていただきました。
https://www.slideshare.net/AmazonWebServicesJapan/aws-31275003

SQS based S3 構成時の注意点

以下のマニュアルをまずはご覧ください。
https://docs.splunk.com/Documentation/AddOns/released/AWS/SQS-basedS3

特に注意する点は、新規に追加されたデータのみ対象となるという点です。つまりすでにS3上にあるデータは対象外となってしまいます。過去のデータを取り込むためには前回説明したGeneric S3 取り込みを最初に行ったうで、今回のSQS baseの取り込みを設定する必要があります。

またS3上に保存されているデータの種類毎にSQSを作成する必要があります。これはソースタイプが異なるためInput設定を別に作る必要があるためです。データの種類毎にSQSとSplunk Inputがセットで必要と覚えておいてください。

設定の流れ

AWS側の設定
1. IAMユーザーへのポリシー設定
2. SQS作成 (通常のものと、Dead Queueの２つ) & アクセスポリシーの変更
3. S3にてSQSへの通知設定

Splunk側の設定
4. Input設定

(*) 今回は Add-On for AWS App のインストールや、IAMユーザーの登録は省略します。詳しくは前回の記事を参照ください。

1.IAMユーザーへのポリシー付与

IAMユーザーに対して、新規にポリシーを作成して付与します。適用するポリシーはこちらになります。

コピペして利用できます
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sqs:GetQueueUrl",
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes",
        "sqs:ListQueues",
        "s3:GetObject",
        "kms:Decrypt"
      ],
      "Resource": "*"
    }
  ]
}

ユーザーに作成したポリシーを付与

2. SQS作成 (通常のものと、Dead Queueの２つ)&アクセスポリシーの変更

次にSQSを作成します。作成するのは２つになります。
1. メインキュー ( Splunkと連携するキュー)
2. Dead letter queue : 正常に処理できないメッセージの送信先として設定するキュー

  1. メインキューの作成 (jmaru-sqs)

  2. Dead letter queue の作成
    同様に新規のキューを作成します。

メインキューに対して、dead letterキューを設定します。メインキューにチェックをいれて、「キューの設定」を選択します。

先ほど作成した dead letter キューを入力します。

次にアクセスポリシーを修正します。これはS3からSQSに対してイベント通知ができるように許可を与えるものです。

詳細はこちらをご覧ください。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ways-to-add-notification-config-to-bucket.html#step1-create-sqs-queue-for-notification

メインキューを選択して、「アクセス許可」 - 「ポリシードキュメントの編集（高度）」をクリック

下の内容をコピペして上書きします。

こちらをコピペして上書き
{
 "Version": "2012-10-17",
 "Id": "example-ID",
 "Statement": [
  {
   "Sid": "example-statement-ID",
   "Effect": "Allow",
   "Principal": {
    "AWS":"*"  
   },
   "Action": [
    "SQS:SendMessage"
   ],
   "Resource": "SQS-queue-ARN",
   "Condition": {
      "ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:bucket-name" }
   }
  }
 ]
}

"bucket-name" を対象のS3 Bucket名に変更します。

3. S3のイベント通知設定（SQSへの通知)

最後にS3側に新規書き込みがあった際のイベント通知設定を行います。ここではSQSを登録します。

S3サービス画面から、対象となるS3 Bucketを選択し、以下のように「プロパティ」タブを開き、下の方にある「イベント」を開きます。

「すべてのオブジェクト作成イベント」にチェックを入れて、送信先をSQSトピックにします。

保存して終了です。AWS側の設定はすべて完了しました。これで今回設定したS3上にデータが追加されると、SQSに通知が飛んでキューに保存されます。あとはSplunk側から通知を取りにくるのを待つだけです。

Splunk側の設定

4. Input設定

すでに、Splunk側のAppの追加やIAMユーザの登録が完了した状態で設定を進めます。
まだ完了していないかたは、こちらの記事をご確認ください。

「Splunk Add-On for AWS」App ー「Inputs」　に移動して「Custom Data Type」から、[SQS-Based S3]をクリック

必要項目を入力します。ソースタイプなどは保管されるデータタイプに合わせて変更してください。インデックスも保存したいIndexを指定してください。

Intervalの300秒は、SplunkからSQSに対してメッセージが届いていないか確認しにいく時間間隔です。つまりこの方法は、PULL型であり完全なリアルタイム処理ではありません。この時間はキューの大きさやデータサイズ、取り込みスピードなどを考慮して設定してください。

以上で設定は完了です。

取り込み確認

それでは、S3上に新規ファイルを追加して取り込みがされているか確認します。

新規に[access_sqs.log]を追加してみます。

あとはデフォルト設定のまま取り込みます。

Splunk側からもすぐに取り込みを確認できました。

最後に

今回はInput設定が一つでしたが、Heavy Forwarderを複数立ててSplunk側のInputを増やすことで取り込みスピードを向上させることが出来、さらに可用性も向上できます。将来的なスケール構成を見据えてこちらの設定が推奨とのことです。