Riak Meetup Tokyo #3聴講メモ

近くでRiak Meetup Tokyo #3がされるということで、Riakが何か知らなかったが参加してきた。 正直よくわからなかったので、勉強せねば。

イベント概要

  • connpass
    http://connpass.com/event/3600/
  • 開催日時
    2013/11/06(水) 19:00 〜 21:00
  • 会場
    ヤフー株式会社 11Fセミナールーム
  • ハッシュタグ
    #riakjp
  • アジェンダ
    1. 19:00 オープニング
    2. 19:05-19:45 古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」
    3. 20:00-20:30 篠原＠Basho 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」
    4. 20:30-20:50 鈴木@Basho 「Yokozuna: Riak 2.0の新しい全文検索機能」

Talk

(スライドメモっただけなので意味はない。しかも下書き)

古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」

  • プレイベートクラウドとは
    • 自社内の仮想化環境
    • よりサーバのライフサイクルを管理しやすくしたもの⭐️
    • メリット
      • 計算リソースが安い
        • ストレージは微妙
    • デメリット
      • 運用コスト
  • なぜプライベートクラウドにしたか？
    • 小さなチームで複数のプロダクト
    • 好きにサーバ環境を構築
  • mixiのプライベートクラウド
    • OpenStack + Chef + 独自のDeployTool
    • gizmoと呼んでいる
    • インスタンスの中にデータを残さない
    • プロダクト毎に権限を分ける
      • ログイン
      • 課金情報などまたぐのは良くない
    • ストレージの選定
      • データの取得はAPI経由で行いたい
      • RiakCSでできるということで採用
  • RiakCS概要
    • Riak上に作られたS3互換の分散ファイルストレージ
    • Riak+Stanchion+RiakCSという3つのプロセス
    • 実際のデータはRiakが受け持っている
      • セカンダリインデックスが使えるlevelDBにkey情報を保存
    • nodeを順番に~
  • RiakCSの検証
    • V1.3のころの話
    • 2Mのファイルを4000万個
    • 少ない追加容量でデータが格納されている
    • PUT性能
      • 5台で80req/sくらい食えていた
      • Cephは特定のノードに負荷が掛かる症状が出た
    • lsが遅い
      • nodeをまたぐため
      • 1.4系では大分改善 3m -> 15s
    • nodeごとのデータ容量の違いが許容されない
      • vnodeの分配率を個別に決められないので、、、
  • mixiでの構成
    • LBの下に並べている
    • モニタリング
      • Riakのstats
      • RiakCSのstats
    • 死活監視
      • riak ping, stanchion ping, riak-cs ping
      • clusterのnode状態監視
        • 念のため
    • 障害時対応
      • nodeが落ちた時に自動でデータ移動をしない
      • リバランシング
        • 壊れたノードだけreplace
    • データ内容で3つのクラスタを用意
      • ログ保存
      • 画像アップロード
      • バックアップ保存用
    • ログ構成
      • 以前はローカルにログを吐いて定期的にrsyncで移動
      • fluentd
        • fluentd-plugin-forest
        • fluentd-for-s3
      • hive(hadoop)
      • 現在検証中
    • 画像ストレージ
    • mysqlのバックアップ
      • DC
    • Redisのsnapshopバックアップ
      • gizmo-redisコマンド
  • まとめ
    • 思ったよりRiakCSは安定
    • storageにAPIでアクセスできるのは便利
  • Q&A

Bashoジャパン 篠原さん 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」

  • スライド
    http://www.slideshare.net/shino/riak-meetup-3-20131106-riak-meetup3riak20pre5
  • 来年頭にリリース予定
  • アプリ向け機能強化
  • さらなる運用の容易さ
  • 設計ポリシー
    • 運用の容易さ
    • 高可用性
  • Riak 1.x
  • Riak 2.0で追加されるもの
    • アプリ向け
    • 運用の容易さ
      • バケットタイプ
      • セキュリティ
      • 設定ファイル刷新
  • バケットタイプ
    • 動機
      • キーの名前空間としてのバケット
      • カスタム設定が個別のバケット毎に必要
      • O(1000)のバケットのカスタム設定はネットワークを圧迫
    • 解決策
      • 同種のバケットを。。。
    • 明示的に作成し、有効化する
  • データ型(CRDT)
    • 動機
      • 並列アクセス、並列更新をアプリで考慮する必要があった
      • 単純な後がちかv~~~
    • 更新の衝突
    • 解決策
      • データ型を指定するだけで自動的に衝突解決
    • riak-admin bucket-type create bt-sets '{"props":{"datatype": "set"}}'
    • 現在対応しているのはErlangのみ
  • セキュリティ：認証・認可
    • 誰がアクセスしてきたか
    • 何にアクセスできるか
  • 強い整合性
    • 動機
      • これまでは結果整合性の参照＋更新のみ。可用性が第一
    • 解決
      • レプリカごとにリーダーを選出、整合性を課す
      • 条件付き更新(CAS)、単一レコード、整合性を課す
  • 設定ファイル刷新
    • 動機
      • あまり一般的ではない
    • 解決
      • 1ファイル
      • 1行1設定

Bashoジャパン 鈴木さん 「Yokozuna: Riak 2.0の新しい全文検索機能」

  • 以前
    • 英数字のみ
  • Apache Solr + Riak
  • Apache Solr
    • 豊富な言語さぽーと
    • 多彩な検索クエリ
  • Yokozuna
  • Riakの特徴
    • スケールする
    • 簡単にRead/Write
    • Key/Valueストア
  • Yokozunaの特徴
    • 全文検索機能
    • Apache Solr
      • バンドル済み
    • configで有効化するだけで利用可能
    • Riakが実データを保存、そlrはインデックスを保存
    • SolrプロセスはRiakが管理
    • 検索インデックスもRiakが管理
      • サーバ追加時にデータだけでなくインデックスも再配置
  • Yokozunaの詳細
    • Solrの分散検索
      • 複数サーバにまたがった検索結果の取得
    • Read Repair
      • レプリカ間の不整合を検出
      • Active Anti-Entropy
        • バックグラウンドで不整合を検出
    • データの投入
      • RiakへのデータPUTと同じ
      • X-Riak-Metaもインデキシング
    • Extractor
      • POSTデータをSolrが処理できるフォーマットへ変換
  • Yokozunaまとめ
  • FAQ
    • SolrCell未対応
    • カスタムスキーマupdate,インデックスの再構築は未対応
    • SolrCloud連携ではない
    • インデキシングはw,dwに連動
    • Handoff中のノードも検索対象になりうる