RiakMeetupTokyo3.md

Riak Meetup Tokyo #3

RiakCSとmixiプライベートクラウド環境

mixi 古城さん

プライベートクラウドとRiakCS

• プライベートクラウドとは？
  • 自社DC内に設置するサーバ設備の仮想化環境
  • よりサーバのライフサイクルを管理しやすくしたもの
  • メリット
    • 計算リソースが安い
    • 自社設備の有効利用
    • AWSへのリハビリ
  • デメリット
    • AWSより自前で用意するものが多く、運用コストがかかる
• 何故プライベートクラウド？
  • 小さなチームで複数のプロダクトを作成したい
  • 開発者が好きにサーバリソースを使える環境
  • 運用者もチケット処理に追われなくてすむ
• mixiのプライベートクラウド環境
  • OpenStack + Chef + 独自のdeploy tool
  • 社内での名前はgizmo
  • インスタンスの中にデータを残さない
    • いつ死んでもいいように
  • プロダクトごとに権限を分ける
    • 機密保護とログ閲覧権限との兼ね合い
• ストレージの選定
  • データ取得をAPIで
  • S3とのAPI互換性が欲しい
    • →それRiakCSで出来るよ！
• RiakCS
  • Riak上に作られたS3互換の分散ファイルストレージ
  • 3つのプロセス
    • Riak
      • 実際のデータ保存
    • Stanchion
    • RiakCS
• RiakCSの検証
  • 容量的なオーバーヘッドは少ない
  • consistent hashingされる
  • Cephよりは更新性能が綺麗にスケールする
  • 気になった点
    • lsが遅い
      • サービスから叩けないレベル
    • nodeごとのデータ容量の違いが許容されない
      • 一番小さいディスクサイズがボトルネックに

RiakCSの運用について

• mixiでの構成
  • 10Gスイッチの下に
  • Stanchionはシリアライズする必要があるので、VIPの下に
• モニタリング
• 死活監視
• 障害時対応
  • nodeが落ちた時に自動でデータ移動をしない
  • デメリットのようだけど、悪いことだけではない。
    • どうせ手動で見るし
    • 一時的な上位障害でリバランシングは怖いし
  • 取れる対応
    • そのままリバランシング
    • ノードを複数まとめて追加して、データ移動
    • 壊れたノードの代わりに新しいnodeを移行

実際の使用例

• プライベート・クラウドとRiakCS
  • データ内容で3つのクラスタを用意
    • ログ保存用のクラスタ
    • サービス利用（画像アップロード）のクラスタ
    • バックアップ保存用のクラスタ
• ログ用クラスタ
  • 権限管理
    • RiakCS Control
      • あまり使えない
    • Fogが便利
  • fluent-plugin-s3を使う上で注意すること
    • ファイル名が日付情報までだけだと、結構な数のheadリクエストが飛ぶ
  • ログの利用
• サービス用クラスタ
  • 特別なことは何もしてない
• バックアップ保存用クラスタ
  • MySQLのバックアップ
    • 遠隔地DCへ
  • Redisのsnapshotバックアップ

まとめ

• 思っていたよりRiakCSは安定してる
• storageにAPIでアクセスできるのは便利
• 今後もオレンジの会社では積極的にRiakを使っていきたい！

Q&A

OpenStackのSwiftは検討しなかった？

評判がわるかったので。。

クラスタの論理容量は？

4T*50台

クラスタ間のレプリケーション

商用版を買ってください。

===

Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ

BashoJapan 篠原さん

RIak 2.0.pre5

Riak 1.x + アプリ向け機能強化 + さらなる運用の容易さ

Riakの設計ポリシー

• 運用の容易さ
• 高可用性
• 水平拡張性

Riak 2.0

• アプリ向け機能強化

  • 全文検索
  • データ型(CRDT)
  • 強い整合性

• さらなる運用の容易さ

  • バケットタイプ
  • セキュリティ
  • 設定ファイル刷新

• バケットタイプ

  • 同種のバケットをまとめて管理
  • 効率的なクラスタ内情報共有

• データ型(CRDT)

  • 問題点
    • Riakにはトランザクションがない
    • 並列アクセス、並列更新をアプリで考慮する必要があった
    • 単純な後勝ちまたはVector Clocks（内部で持っている論理的な時刻）以外の対処はアプリの責任だった
  • 解決策
    • データ型を指定するだけで、自動的に衝突解決
      • カウンター、フラグ(Boolean)、セット、レジスター、およびそれらの入れ子（マップ）

• セキュリティ：認証／認可

  • Authenticate: 誰がアクセスしてきたか
  • Authorize: なににアクセスできるのか
  • Audit: 誰がどうアクセスしたか
  • Encryption: MITM排除

• 強い整合性

  • レプリカごとにリーダーを選出、整合性を課す
  • 条件付き更新(CAS)、単一レコード、アトミック
  • 並列更新は失敗する、部分更新は発生しない
  • 参照では最新が見えることを保証（ダーティリードがない）
  • 「強い」≠「良い」に注意。Riak内で結果整合性とトレードオフ可能に

• 設定ファイル刷新

  • 1ファイルに統合

Q&A

障害時などにErlangでアタッチするのが面倒です

設計思想なので…。よくあるパターンはコマンド化したいです。

===

Yokozuna: Riak 2.0の新しい全文検索機能

BashoJapan 鈴木さん

Yokozunaとは

• RiakSearch(1.4以前)
• Yokozuna
  • Apache Solr
    • query indexing
  • Riak
    • データの永続化など

Riakの基礎

• スケールする
• HA
• 運用にフォーカス

Yokozunaの概要

• Apache Solrと統合
• Riakへ保存したデータの全文検索
• マルチランゲージ対応
• 2013末リリース予定
• 簡単に使える
• 1ノードにRiak, Solrが1プロセス
• 検索インデックスもRiakが管理

Yokozunaの詳細

• Apache Solrの分散検索を使っている
• Active Anti-Entropy

Yokozunaのまとめ

• Riakに保存したデータの手軽な全文検索
• Apache Solrと統合
• Solrの面倒はRiakが見てくれる

デモ

時間がないので略