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万程度