Upload
intimate-merger-inc
View
1.293
Download
4
Embed Size (px)
Citation preview
elasticsearchの使われ方
約4億のユニークIDに対して様々な属性情報を付与
• 閲覧履歴に基づくキーワード
• 各メディアより提供されるセグメント
• User Agent
• アクセス元IPに基づく住所や企業情報
任意の条件でIDを絞り込むために、 を
利用しています。
������
全体構成
• 全て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アップデート)
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 が1を超えると激しくパフォーマンスが劣化
※ shard/nodeではなく、shard/cpuの方が重要かもしれない・・
Instance Size
• インデクシング高速化のため、ローカルSSDの性能を重視
→ Ephemeral Diskを2つ積めるc3ファミリーから選択
• データ量が多い場合はxlarge以上の方がCPに優れる
→ 基本的に価格が倍になると、容量も倍になるが、
large→xlargeの時のみ30GB→80GB
• JVMへのメモリの割当量は全体の2~3割(doc_value)
Why AutoScaling ?
AutoScalingさせている理由
• 100台規模のサーバを1台1台管理して運用することが、人数的に厳しかった
• terminateすれば元の環境が再現可能
• スポットインスタンスが利用可能になる
• パラメータをいじるだけでスケールアウト可能
recoveryのチューニング
• LifeCycleにより定期的にインスタンスが入れ替わることがある
• 帯域や同時移動可能なシャード数を調整し、recoveryにかかる時間を短縮している
• レプリカ数は1で運用(0でやると時々データが無くなります)
indices: recovery: max_bytes_per_sec: 500mb concurrent_streams: 4
クラスタリングの高速化
• elasticsearch-cloud-awsプラグインを利用
• タグ指定でdiscoveryを行い、master nodeにのみタグを設定する
• SG指定では対象が多すぎて時間がかかる
discovery: type: ec2 ec2: tag: es_cluster: production
冗長化
• 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
監視
監視の3本柱(オートスケールとの相性重視)
• ELBのヘルスチェック
• Mackerel(リソース・プロセス監視)
• Papertrail(ログ監視)
• (起動/停止時のSlackへのwebhook)
まとめ
• スケールアウトのし易さで、AWSとESは相性が良い
• 設定次第ではあるが、AutoScallingは本番での運用に耐えうる
• Cluster Sizeは一定数以上が必要
• ノードの入れ替わりを考慮することが必要
• 1つのindexが億件レベルであっても、elasticsearchは実用に耐えられる