pub:2016.2.21/upd:2016.8.9

Amazon Elasticsearch Serviceのはまりポイント

おれの屍を超ry

やったこと

EC2でfluentdを稼働して、RDS(mysql)の内容を整形しながら同期。

RDS(mysql) -> EC2(fluentd) -> Amazon Elasticsearch Service(およびkibana)

上の状態が完成するまでに、はまった点と対応をメモ。

ネットワーク疎通

EC2からfluentdし、自宅ののPCからkibana見たかったが、ネットワークの設定をどこで行うのか不明であった。

以下、設定手順。

  1. AWSコンパネ
  2. Elasticsearch Service
  3. 設定するドメイン名
  4. modify access policy
  5. “Condition”: { “IpAddress”: { “aws:SourceIp”: [ “”で括った自宅ipをカンマ区切りで指定

設定を適用してから反映されるまで、10分程度かかる。

クラスタステータスがyellow

Elasticsearchのデフォルトでは、プライマリシャードとレプリカシャードを同クラスタ内の別のノードに作ろうとする。

従ってノードが1つしかないと、レプリカシャードが作れずにクラスタのステータスがyellowになる。

無料枠ではじめた場合にはノードは1つしか無いのでyellowになる。

レプリカが使えるように2ノード以上にしても良いが、1つでやる場合は、
インデックスのオプションを設定するとレプリカ無しでgreen稼働も出来る。

EC2からのアクセスがタイムアウト

Elasticsearchが標準で用いるportは9200。AWS版では80。
当然、9200にアクセスしようとするとタイムアウトする。

すでに稼働しているElasticsearchを移植する場合に、はまりがちと思う。

余談

できれば任意のポートを使って、暗号化した上でデータを送りたいが、2016/02/11現在はそのような設定を行うことはできない模様。

個人情報やアクセスログを含むデータを扱いたい時には、致命的欠点になりうると感じる。

折角SaaSとしてのElasticsearchがあるのに、結局EC2にElasticsearch入れて使うという不毛な流れにつながると全員が不幸なので、対応あくしろよ感がある(´・ω・`)

バルク登録時エラー

RDSとの同期には、y-ken/fluent-plugin-mysql-replicatorを使わせてもらった。超感謝(・∀・)

ところが、リクエストボディーを10M以下にしないとElasticsearch側でリクエストを受け付けてもらえないことを知らずに30分ほどはまる。

fluentdでリクエストボディーが5MBになるように分割して登録を行うようにしたところ無事登録できた。

Leave a Reply

Your email address will not be published.