AWSのAutoScalingを利用して、td-agentクラスタを準備する #AWS

検証を思いついた経緯

appサーバ側のforward設定で複数の<server>タグを管理したくない
td-agentのconfigに影響されず、AWSメンテナンスやインスタンス障害の対応を行いたい
アプリケーションが乗るappサーバと違い、td-agentクラスタは純粋に負荷を見極めやすいため、AutoScalingに適している
fluentdのコミュニティで「TCPロードバランシングはユーザ側で試して欲しい」という状況で更新が止まっていた https://groups.google.com/forum/#!topic/fluentd/3ZuG_1dPovE

td-agentクラスタ環境準備

1.環境構成

今回、VPC,SecutityGroup,AMIの作成方法は割愛。
以下の環境を準備する。

2.appインスタンスのtd-agent設定

<source>
  type forward
</source>

<match *.**>
  type copy
  <store>
    type forward
    heartbeat_type tcp
    <server>
      host td-agent-elb-internal-1234567890.ap-northeast-1.elb.amazonaws.com
      port 24224
    </server>
  </store>
</match>

heartbeat_type tcp ここが今回の一番の肝。
fluentdのハートビートはデフォルトでUDPだが、ELBのListers設定はTCPで行う必要があるため、fluentdのハートビートをTCPで行う。

3.内部ELB

aws elb create-load-balancer \
    --load-balancer-name td-agent-elb-internal \
    --listeners Protocol=TCP,LoadBalancerPort=24224,InstanceProtocol=TCP,InstancePort=24224 \
    --subnets subnet-aaaaaaaa \
    --security-groups sg-bbbbbbbb \
    --scheme internal

ELBのLisners設定できるのは、TCP,HTTP,HTTPS,SSLのみ。
Lisners側でtd-agentインスタンスの24224ポートへの連携を設定する。

4.td-agentインスタンスのtd-agent設定

<source>
  type forward
</source>

#下記は環境によって変更する。
<match *.**>
  type stdout
</match>

今回の<match *.**>配下はテスト用。
実運用上はここに各種設定を記載する。

5.AutoScaling

Launch Configuration

aws autoscaling create-launch-configuration \
    --launch-configuration-name fluent-as-configuration \
    --image-id ami-cccccccc \
    --key-name xxxx \
    --security-groups sg-bbbbbbbb \
    --instance-type t2.micro \
    --associate-public-ip-address

--image-id ami-ccccccccは、td-agentインスタンスのAMIを指定する。
chkconfig --listなどでtd-agentが自動起動することをお忘れなく。

Auto Scaling Group

aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name fluent-as-group \
    --launch-configuration-name fluent-as-configuration \
    --min-size 1 \
    --max-size 2 \
    --desired-capacity 1 \
    --availability-zones ap-northeast-1b \
    --load-balancer-names td-agent-elb-internal \
    --health-check-type EC2 \
    --vpc-zone-identifier subnet-aaaaaaaa \
    --tags Key=Name,Value=fluent-as

Scaling Policies

aws autoscaling put-scaling-policy \
    --auto-scaling-group-name fluent-as-group \
    --policy-name ScaleOut \
    --scaling-adjustment 1 \
    --adjustment-type ChangeInCapacity

td-agentクラスタ検証

1.td-agentクラスタのスケールアウト

テスト用に以下のようにCPU使用率を0%以上になったら、スケールアウトするように設定する

こんな感じで、ELB配下に追加のtd-agentインスタンスが準備される

2.appインスタンスから、ログを送信

appサーバからfluent-catを使って、td-agentクラスタに1万件のログ送信を試してみた結果は以下の通り

検証内容	結果	備考
2台のtd-agentインスタンスをぶら下げる	td-agent1:5,012件 td-agent2:4,988件
1台のtd-agentを落として、復帰させる	td-agent1:8,200件 td-agent2:1,800件	障害などでELBのヘルスチェックにひっかかったケース
ログ送信中にDesiredCapacityを増やす	td-agent1:326件 td-agent2:351件 td-agent3:9,323件	AutoScalingでインスタンスが増えたケース

まとめ

td-agent(fluentd)は、tcpでもロードバランシングしてくれることが確認できた。
今回の検証ではAutoScalingで追加したインスタンスにログ送信が偏ってしまったが、これはELBの振り分けルールによるものと考えられる（新規追加されたインスタンスは、負荷が少ないと認識される？）
ログの欠損もない模様なので、ひとまず実運用に耐えられそうかなと。