Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Meet up to the Aerospike

No description
by

Makoto Uehara

on 30 October 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Meet up to the Aerospike

Aerospike in the
CyberZ

Aerospike速度性能
OSでirqbalance有効
ハードウェア選定(ここが一番重要)
aerospike.confのこの辺をCPUコア数に応じて設定(service-threads、transaction-queues)
benchツールは提供されてます
3台のサーバーでクラスタ組みました
クラスタ構成
XDR
cross(X)DatacenterRepricationを使
ってクラスタ間コピーを実施しています。
バックアップがイケてない部分のカバー
メリットは、クラスタ単位での障害が発生した場合、図のとおりクラスタの向き先を移すことでサービス継続
デメリットはサーバーが倍必要
マスタクラスタ側へのサーバー追加のタイミングでレプリ件数ずれます><、そもそもHadoopと一緒でバックアップ必要なの?という話もあると思いますが、asdとxdrのプロセスを統合することで改善を期待しています。
The pilot is a
Makoto Uehara (Infra)
& Akira Torii (App)

What's Aerospike
バーチ早く書いて・・!
Aerospike is ...
Migration
(クラスタ内のサーバー間データコピーのことになります)
アーキテクチャの一部
スキーマレス
 
RDBMSで言う
database = namespace
table = set
row = record
colum = bin


カラム指向のデータ層を持っている。
bin,bin,bin..(binを複数持てますが弊社はシンプルに1binです)
setは2つ使ってます

 
Partition
データは、クラスタ内に4096のパーティションに分割され均等に配置されます。
例えばノード4つであれば1ノードに1024のパーティションが存在します。

 
データへのアクセスは?可用性は??
だいたいの状況でデータへのアクセスを1ホップであることを保証します。
パーティションの情報を常にクライアント側に送ります。この情報をパーティションマップと呼びます。
1台サーバーが故障し、マスタデータがいなくなった場合、レプリカデータの位置をパーティションマップから割り出せます。

Kumofsを使っていました
kumofsの開発は5年前に止まってる><
kumofsngも候補でした
実際比較したのはRedis。ディスクにフラッシュするタイミングでの遅延が無視できなかった。あとクラスタが時期尚早すぎて、アプリ側でシャーディング制御が必要だったなど。
Aerospike検証して運用面で楽だと感じた。
Hardware optimize
データ部分は、各bin属性により若干のオーバーヘッドを追加し、全て併せて128バイトブロック単位でSSDに保存します。ブロックサイズは変更不可。
SSDをブロックデバイスとして使う。
SSDのデフラグを定期実行。
HWM(HighWaterMark)が50%で結構低いです。
SWは90%
HWM、SW共に超えた場合の挙動はMemoryと同様。
さらにSSDはベンダーがOP(OverProvisioning)済みかどうかの確認が必須です。ベンダーにもよりますが20%程度を推奨しています。Aerospike的にもOP済みでないSSDは21%のOPを入れるようドキュメントにあります。
CPUは1つでOK、オフィシャルでもそう言ってる。(けどうちは2つ)
SSD(Aerospike的に適合するもの)
Memoryに何を入れるか?
Networkは1G、規模によっては10Gも
Memory
SSD&Memoryタイプの利用時
キーそのものはメモリにもSSDにも保存されない。キーはハッシュ化され、1レコード64バイトのインデックスとしてメモリ上に保存
要するにMemory使用量は(レコード数*64バイト)なので、Memoryは設計しやすい。
気にしなければいけないHWM(HighWaterMark)、デフォルト60%でこれを超えることはソフトウェア的に性能を保障しません。超えると古いものを消していきます。古いものを消してでも動き続けようとします。
超えてはいけないSW(StopWrite)、超えた場合それ以降書き込みできません。ReadOnly状態です。
上原 誠(@pioho07)

~2012 某SIer
2012~ Cyberagent
Amebaスマホプラットフォーム
Ameba統合ログ監視基盤のミドルインフラ、Hadoopとか

2013~ CyberZ
またHadoopとか、ネットワーク、
Aerospike、AWS、Ansible
鳥居 英()

~2013 某人材紹介会社

2013~ CyberZ
スマートフォン向け広告効果測定ツールF.O.Xの開発
NoSQL
OSS化(2014/6/24から)
AWSではAMIもあるよ
SSD Optimize
既存NoSQLより10倍速い!?
BigtableではなくDynamoの論文参考にしたやつ
CAP 定理で言うAP型
SSD&メモリだけではなく、メモリのみ、メモリ&ディスクの3タイプある
広告業界で事例多数(Appnexux、Spacyz等)
SSD
性能はでます!
7万!いいんじゃないか!?
例えば、800GBのSSDがOPしてないと、
OPすることで20%引かれ640GB、
HWMがその50%なので、320GBになります。
これが100%の使用率と考えると、
ディスク容量の監視とかでは60%が192GBになります。800GBのSSDで320GBしか使えない、、(丸められるので実際はもっと小さいです。)
Hadoopで言うレプリケーションです。
AerospikeでレプリケーションというとXDRです。
XDR使う場合は多少異なりますが、障害時とメンテナンス時のマイグレーションに差はありません。クラスタ内からノードがいなくなったことを検知しデータ(パーティション単位)のマイグレーションが走ります。
"ACT"というSSD性能ベンチツールがあるので必ず事前に
行いましょう
マイグレーションはなるべく速やかに終わらせたい。
データのレプリケーションファクタはデフォルト2なので
運用あるある1
マイグレーションに使うスレッド数を上げる。デフォルトは1。
もちろん上げすぎ注意。
[root@svr001]# asinfo -v get-config -l | grep migrate
migrate-threads=1


すかすかのIO時、IOのutilは1スレッドあたり13%くらい上がった
asinfo -v 'set-config:context=service;migrate-threads=5'


●iostat結果↓
2014年06月01日 18時48分52秒
avg-cpu: %user %nice %system %iowait %steal %idle
2.79 0.00 1.36 6.77 0.00 89.07

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.33 0.00 1.00 0.00 0.00 8.00 0.00 0.00 0.00 0.00
sde 0.00 0.00 3392.00 0.00 1.95 0.00 1.18 1.02 0.30 0.20 67.80
sdd 0.00 0.00 3418.00 0.00 1.97 0.00 1.18 1.03 0.30 0.20 67.97
sdc 0.00 0.00 3417.33 0.00 1.96 0.00 1.17 0.97 0.28 0.19 65.63
sdb 0.00 0.00 3458.33 0.00 1.99 0.00 1.18 1.09 0.31 0.20 70.03

クラスタにノード追加
ノード追加時は適切なコンフィグを配置し、スタートするだけです。
インフラもアプリエンジニアも助かる簡単さ
/etc/init.d/aerospike start

切り離しはストップするだけ。
/etc/init.d/aerospike stop

確認はasmonitor


[root@prd-svr001 ]# asmonitor -e "info"

Enter help for help

request to 192.168.1.1 : 3000 returned error
skipping 192.168.1.2:3000
2 hosts in cluster: 192.168.1.1:3000,192.168.1.2:3000
===NODES===
2014-05-10 11:25:48.546245
Sorting by IP, in Ascending order:
ip:port Build Cluster Cluster Free Free Migrates Node Principal Replicated Sys
. Size Visibility Disk Mem . ID ID Objects Free
. . . pct pct . . . . Mem
svr001 3.2.3 2 true 99 67 (2748,0) BB918546B3ACAB8 BB948546B3ACAB8 5.690 M 65
svr002 3.2.3 2 true 99 68 (820,1) BB948546B3ACAB8 BB948546B3ACAB8 6.159 M 71
Number of nodes displayed: 2

===NAMESPACE===


メンテナンスなどで一時的に切り離しても、全体のマイグレーションが走ってしまう。
データの配置についてはクラスタ状態に変化がある度に再計算が走る。

SSDが1本故障しても再度全体のマイグレーションが必要になる。

監視はこの辺を見ています↓
運用あるある
以前弊社で書いたkumofsの記事に
kumof作者からコメントが
ウェアレベリングにより
同じセルへの書き込みの偏りを減らす。ハードウェア的にはブロックへの書き込み回数を記録しておいたり、
セルのマップ情報をずらしたりしてる(実装は様々)

アイドル時間にGCする
あるセル上の不要データを消す場合、削除のために同一ブロック内の必要データをムーブします(セル単位でけせないから)。
その後ブロック単位でデリートする。SSDはブロック単位でしか消去できないしデータの上書きできないから
(正確には上書きは遅い)

SSDに対してデータ書き込み
空きブロックがある場合、→そこにデータをセット→ブロック単位でフラッシュメモリに書き込む。
空きブロックがない場合、→ブロック全体を読み出してバッファに入れる→ブロックを消去→バッファからデータを書き戻す。
空きブロックがなかったら1回の書き込みのために"読み出し","消去","書き込み"する

ブロック消去は書き込みの何十倍も負荷がかかる
ので、適切な数の空きブロックを常に用意しておく。また、空きブロックが少ないとセルへの書き込み回数が増えるので
SSD短命化に繋がる。
なのでー、パフォーマンス劣化防止とSSD延命のためにOPしとく
OPはライトアンプリフィケーション(実際の書き込み量よりチップへの書き込みが増加する)を低減させる

OPしてない場合(空き容量がない場合)よりOPしている場合(空き容量がある場合)のほうがGCの発生頻度を減らせるって
結果がググると多く出る

SSDまめ知識
いってきます!
Full transcript