Amazon Elasticsearch serviceの無料枠だとsplapiのアクセスログは捌き切れない。

t2.micro/インスタンス数1/Single-AZ だとsplapiのログは捌き切れないというのがわかったのでとりあえずメモとして残しておきます。
具体的にいうと503が頻発して、最大2時間半程度復帰しない状態になります。td-agentのログ見るとこういうのがわんさか出てます。どこぞの世紀末バスケ覇者よろしく送れなかったログは投げ捨てるものなのです。スタックトレースは割愛。

2016-07-09 05:22:47 +0900 [warn]: failed to flush the buffer. error_class="Elasticsearch::Transport::Transport::Errors::ServiceUnavailable" error="[503] " plugin_id="object:3feb7fd1d6d4"
2016-07-09 05:22:47 +0900 [warn]: retry count exceededs limit.
2016-07-09 05:22:47 +0900 [warn]: suppressed same stacktrace
2016-07-09 05:22:47 +0900 [error]: throwing away old logs.

使い始めて3日くらいは順調だったのですが、だんだん503が発生するようになって、503の発生する頻度と、復帰までの時間が日ごとに長くなるという感じです。ちゃんと解析したかったらお金出してノード増やすなりVPS借りるなりしないとだめですね。そこまでする気ないのでとりあえずこのままの運用で行こうと思います。
あんまり参考にならなさそうですが、splapiの最大アクセス量はこんな感じなので、これを超えるドキュメントをElasticsearch serviceに処理させたい場合はお金払うことを推奨します。1秒間の同時接続数は出したことないのでわかんないです。逆に、これでも普通捌けるという事例があるなら私の運用の仕方が悪いのかも。

  • 15分間の最大アクセス量:6000前後
  • 1分間の最大アクセス量:200前後
    算出方法間違ってて30秒間隔で出してたので倍の400が正解。6000/15=400なので妥当ですね。
  • 1日の最大アクセス量;13万程度

コメントを残す

お手数ですが半角数字で計算結果を入力してください。 *