Amazon Web Searvice で実現する elasticsearchの大規模運用

×

株式会社インティメート・マージャー　松田和樹

自己紹介

松田 和樹

株式会社インティメート・マージャー（社員数９名）

開発本部

• パブリックDMP「AudienceSearch」の開発

• 主にインフラ周りを担当

アジェンダ

• IMにおけるelasticsearchの使われ方

• elasticsearchの構成

• 構成の決め方

• AutoScalingのポイント

• その他設定のポイント

elasticsearchの使われ方

約４億のユニークIDに対して様々な属性情報を付与

• 閲覧履歴に基づくキーワード

• 各メディアより提供されるセグメント

• User Agent

• アクセス元IPに基づく住所や企業情報

任意の条件でIDを絞り込むために、　　　　　　　　　　　　を

利用しています。

������

AudienceSearchについて

������

メディア来訪者 ネットリサーチ 広告配信ツール

※　図は一例です

旅行に興味

年収1000万

横浜市役所

30代女性

全体構成

• 全てAWS環境

• Cluster: 1, Type: 1, Node: 86 • master: 3 (master:true, data: false)

• data: 80 (master:false, data:true)

• searcher: 2 (master:false, data: false)

• indexer: 1 (master:false, data: false)　※バッチ処理

• version: 1.3.8 → 1.5.2 (5/26アップデート)

全体構成

masterdatasearcherx2

indexer

indexer以外は、全台AutoScalingで運用

x3x80

ELB

構成決定について

Cluster Size

• Shard数 = Node数 に固定して検証

• 10 ～ 200 と台数を変更し、応答時間を比較

• ～100台位までは台数に応じてパフォーマンスが向上

• 200台規模ではAggregationのパフォーマンスが劣化

→　集計結果のマージコストの増加？

• データ容量を加味し、80台でスタート

Shard

• Node数 = 80 に固定して検証（c3.large）

(1) shard: 40, replica: 1 （shard/node = 0.5）

(2) shard: 80, reprica: 1 （shard/node = 1）

(3) shard: 160, replica:1 （shard/node = 2）

• shard/node が１を超えると激しくパフォーマンスが劣化

※ shard/nodeではなく、shard/cpuの方が重要かもしれない・・

Instance Size

• インデクシング高速化のため、ローカルSSDの性能を重視

→　Ephemeral Diskを２つ積めるc3ファミリーから選択

• データ量が多い場合はxlarge以上の方がCPに優れる

→　基本的に価格が倍になると、容量も倍になるが、

　　large→xlargeの時のみ30GB→80GB

• JVMへのメモリの割当量は全体の２～３割（doc_value）

AutoScallingのポイント

Why AutoScaling ?

AutoScalingさせている理由

• １００台規模のサーバを１台１台管理して運用することが、人数的に厳しかった

• terminateすれば元の環境が再現可能

• スポットインスタンスが利用可能になる

• パラメータをいじるだけでスケールアウト可能

recoveryのチューニング

• LifeCycleにより定期的にインスタンスが入れ替わることがある

• 帯域や同時移動可能なシャード数を調整し、recoveryにかかる時間を短縮している

• レプリカ数は１で運用（0でやると時々データが無くなります）

indices: recovery: max_bytes_per_sec: 500mb concurrent_streams: 4

recoveryのチューニング

• LifeCycleにより追加されたインスタンスの負荷

• データ量: 40GB で10分程度（c3.xlarge）

クラスタリングの高速化

• elasticsearch-cloud-awsプラグインを利用

• タグ指定でdiscoveryを行い、master nodeにのみタグを設定する

• SG指定では対象が多すぎて時間がかかる

discovery: type: ec2 ec2: tag: es_cluster: production

クラスタリングの高速化

• master nodeのオートスケールの設定時にタグを指定

• 「aws:autoscaling:groupName」タグも利用可能？

ELBによる監視

• 直接検索を受けないノードに関しても、死活監視用にELBとの紐付けを設定（master, data）

• 監視対象は9200番ポート（9300の方がいいかも）

その他のポイント

冗長化

• Multi-AZ構成で構築（※3拠点以上の場合は不明）

• 下記設定で、自ノードの保持するshardのreplicaを、異なるAZのノード上に配置する

cluster: routing: allocation: awareness: attributes: aws_availability_zone

冗長化

• ”aws_availability_zone”に自ノードの配置されているAZがパラメータとして与えられる（elasticsearch-cloud-aws）

• 一度、半壊した際も無事でした

{ "attributes" : { "aws_availability_zone" : "ap-northeast-1c", "master" : "false" }}

ノード名をhostnameにする

• 自動で設定されるhostname(ip-10-0-0-1)に、ES上のノード名を合わせる

• 忘れてAMIに固めたりすると、全ノード同じ名前に・・

node: name: ${HOSTNAME}

export HOSTNAME=$(hostname -s)

/etc/sysconfig/elasticsearch

/etc/elasticsearch/elasticsearch.yml

監視

監視の３本柱（オートスケールとの相性重視）

• ELBのヘルスチェック

• Mackerel（リソース・プロセス監視）

• Papertrail（ログ監視）

• （起動/停止時のSlackへのwebhook）

（参考）Papertrail

master

data

searcherx2

x3

x80

サーバにSSH不要で、対象のログをtail可能

syslog

まとめ

• スケールアウトのし易さで、AWSとESは相性が良い

• 設定次第ではあるが、AutoScallingは本番での運用に耐えうる

• Cluster Sizeは一定数以上が必要

• ノードの入れ替わりを考慮することが必要

• 1つのindexが億件レベルであっても、elasticsearchは実用に耐えられる

エンジニア募集

最新の技術に興味のある新メンバーを募集中です！

採用技術 開発基盤

ありがとうございました