古城さん
http://www.slideshare.net/hidetakakojo/riak-meetup3-upload
バケット作成とかユーザー作成はスタンチョンがやってる 5 nodes 20MByte 40万個 10Gbps環境でベンチマークした vnode 16 だったのでばらつきでた
riakの削除はフラグで論理削除してる
writeback barrier0 noatime でフォーマット
900MByteくらいスループットでた(使用帯域?)
'RiakCSで5nodeに2Mのファイルを40万個アップロードで、データ量各node500Mぐらい。SAS 15rpm * 6 で 80req/s くらい。'
https://twitter.com/yamashiro/statuses/398031581559799808
CPU, I/Oは平気だが403ぽつぽつでてた
cephは台数増やしてもputがすけーるしなかった
lsが遅いのが気になった ノードまたぐから トラフィックとreadがたくさんでる 1.4で3分なのが15秒に 管理者ようでユーザには公開できない
nodeごとにデータ容量ちがくできないのがきになる vnodeの分配を個別にできないから
mixiは10GのLB以下にノードを配置 stanchionはvipで落ちたら変える感じで運用
riakにcurlでstatしたものをrrdにいれてる get/put数とか
get/put/head/deleteとかlistリクエストへのlatencyを監視してる
Riak CSは監視サーバ毎にキーおくのがめんどかった
snmmpdのextend mibに登録してpingを監視してる あとstatのconnected_nodesの数も監視してる
riakは自動でデータ移動しないのは運用的に悪い面だけでないと思ってる データ移動すると負荷とかやばそうだから
障害のときの対応3つ
- そのままリバランシング
- どうせなので新しいノードをたくさんいれて、トータルのリバランス量を減らす
- おなじノードをreplaceコマンドで戻す、データコピーは落ちたノードだけになる(基本これ)
3つクラスタ運用的にしてる
- ログ保存用
- サービスの画像よう
- バックアップ保存用
権限管理されててapiでアクセスできるもの、ということで使ってる
ローカルのlogをrsyncで定期的にいれてる そこからさらにrsyncしたり 本番にssh基本できないようになってる fluendt ltsv errolog,syslog,msgpack?も 各プロダクトのキーを持っている
Fogが便利
アカウント管理する必要がある バケット作ったりacl操作したり riakcs controlはつかいづらい
s3curlがcuiだとべんり
解析チームがアクセス横断するため、特定のファイルへの権限付与ほしい
capped control のmongodbにデータいれてる
fluent plugin forestつかったり、kibana,elastic searchつかってる
fluent-plugin-s3で注意すること 末尾の連番確認のためheadなげまくる timesliceformatには時刻いれたほうがいい 頻繁になげるとおもい？
hiveにパッチ当ててつかってる mysqlからhiveでriack csいれたりしてる sqoopつかったり
river pluginでbulk insertしたい riak csからelastic searchへ 大量のデータインサートはまだやっていない
varnishの間にいれてつかってる これからはある程度固めて、gracierにいれようかと考えている
遠隔地でバックアップしてる replica数は少ない guiからスケジューラくんでバックアップしてる
extra backupでtar吐かせてマルチパートで直接アップロード xtrabackup --stream=tar
redisのばっくあっぷにもつかってる snapshotを保存してる ここでもfogが便利
やはりstorageにapiでアクセスできrの便利 fogが便利
クラウドの標準はawsでs3なのでswiftは使わなかった(A) 昔からswiftはs3あるがメンテナンス微妙なんで(Q) riakも1.4からはswift APIもある(Basho)
4TBのディスク(ノード?)で50台
そこまで考えてない
できるがOSS版だったし、いまは使ってないが考えてはいる あとriack cs自体のデータバックアップは考えてない
=======================================
BashoのSuzuki-san
もともとriaksearchというerlangでできて、英字だけが対象で、性能問題あった それをsolrへ変更
ノードごとにインデックスつくる 実データはriakでsolrにインデックス
solrはよく死ぬが、yokozuna(riak?)が叩き起こす riak死んだらsolrも死ぬようになっている riakがsolrの面倒をみてくれる
サーバ追加時はインデックスも再配置される インデックスの不整合も検知して自動的に修復する
solrの分散検索をつかってる クエリ受け取ったノードが分散検索に変換してる
read repairあるが、よまれないと治らない active anti entropyはバックグラウンドでなおしていく
データはputは通常通りおなじ x-riak-metaもインデックスされる
extractorというのがsolrにあうかたちへ変換している text/plain, application/jsonとかに対応してる
solrcellは未対応 カスタムスキーマupdate,インデックス再構築は未対応 near realtime searchは有効 インデックスはquorumに従うので過半数が同期なかんじ ノード追加中もけんさく対象になる
========================================
shinohara-san
http://www.slideshare.net/shino/riak-meetup-3-20131106-riak-meetup3riak20pre5
- アプリ向け機能強化
- 運用簡単に(もともとの目玉)
- 運用簡単に
- 可用性
- 水平拡張性
- バックプレッシャー
- ボトルネック判断してべつのとこにふかにがしたり
- capabilityネゴシエーション
- 準々にアップデートして揃ったら昨日使えるよとか
- 全文検索
- crdtというデータ型
- eventual consistencyだけでなく強い整合性も
- バケットタイプ
- セキュリティとして認証・認可
- 設定ファイルかわったり
バケットごとにレプリケーションとか個別に設定
毎回わけなきゃいけなかったけど、同種のバケットはまとめて管理できるようにしたり、クラスタ 名前空間の拡張性、バケットタイプのしたにバケットがいる感じ
そーすこーどりーでぃんぐ会がこれからある
crdtは並列アクセスや並列更新での齟齬対策 これまではアプリ任せだった
たとえば同時に更新かけたり、じつは1台応答してなかったときに更新して齟齬が起きた後・・ 片方には123, 124 ほんとは1234がはいっていてほしい
crdt指定するとriak側で自動解決 使う前にadd-elementというのをバケットに行うと使える
認証・認可はいる もともとネットワークは閉じてる前提でいらないと思ってた だれがどのデータにアクセスしたか見たいという要望があった
ユーザ名のみ、パスワード、ユーザ名と証明書、PAMとかに対応する
レコード単位での指定 同時にリクエストきたら片方には蹴られたり 可用性とのトレードオフ ダーティリードがない リーダ選出する cas(compare and swap)みたいなかんじ
1ファイルに統合 1行に1項目に grep, sedしやすくなった
erlangぽくなくなった 1wって書いたりとか postfixみたいな雰囲気
runtimeで設定可能 メモリ内の特定の場所にもたせるようにしてる attachへの配慮はしてる また過去の事例からコマンドに落とし込んでいる
あぷり作成者と運用者は違うことあるはずなので改善欲しい(Q) できるだけコマンド化していきます