InfoTalk  springbreak_2012
Upcoming SlideShare
Loading in...5
×
 

InfoTalk springbreak_2012

on

  • 1,070 views

 

Statistics

Views

Total Views
1,070
Views on SlideShare
1,070
Embed Views
0

Actions

Likes
1
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

InfoTalk  springbreak_2012 InfoTalk springbreak_2012 Presentation Transcript

  • 分散型 KVS 「okuyama」の活用事例 InfoTalk Spring Break 2012(NoSQL) 株式会社リンク ディベロッパーサポート部 文屋 宏
  • 講演内容 ・自己紹介&会社紹介 ・ okuyama とは ・ at+link の活用事例(キャッシュサーバ) ・ at+link の活用事例(画像ストレージ) ・ 神戸デジタル・ラボの活用事例
  • 自己紹介 ○氏名 文屋 宏(ぶんや ひろし) Twitter:bun_hiroshi ○所属 株式会社リンク at+link 事業部 ディベロッパーサポート部 Twitter:@appliplatform(ハッシュタグ:#appliplatform) ○担当業務 プロジェクトマネジメント,広報活動,営業活動,ユーザサポート, 他社との協業,たまに現地作業,面白いネタ探し ○活動 日本 Red5 ユーザー会メンバー, tokyoLinuxStudy 企画
  • at+link とは
  • at+link とは ディベロッパーサポート ◇開発者のためのサービス開発 at+link の営業窓口 ◇開発者の悩み相談 ◇新しい技術・面白い技術の 研究・サービス化 データセンター常駐 マシン製造 現場担当 24/365 サポート
  • ノベルティ 「あっとりんく」 じゃありません(笑)
  • 担当サービス
  • 担当サービス
  • 担当サービス
  • okuyama とは
  • okuyama とは ○ 神戸デジタル・ラボ 岩瀬氏が Java で開発 ○ NoSQL の1つ(分散 KVS) ○ オープンソース版 2010年1月リリース 商用版 2011年9月リリース ○ 最新バージョン 0.9.3
  • CAP 定理 Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 okuyama SimpleDB CouchDB Vertica Riack Partition Tolerance CConsistency P 分割耐性一貫性 カラム指向 CP キー・バリュー型 ドキュメント指向 BigTable Scalaris MongoDB Hypertable BerkeleyDB Terrastore HBase MemcacheDB Redis
  • CAP 定理 Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 okuyama SimpleDB CouchDB Vertica Riack 一貫性レベルの 選択で補強!! Partition Tolerance CConsistency P 分割耐性一貫性 カラム指向 CP キー・バリュー型 ドキュメント指向 okuyama では BigTable Scalaris 一貫性のレベルを MongoDB Hypertable BerkeleyDB 3段階選択可能! Terrastore HBase MemcacheDB Redis
  • okuyama の構成イメージ Data Node Data Node Data Node Master Node Data Node Data Node Data NodeClient Client Master Node Data Node Data Node Data Node Client Data Node Data Node Data Node Client → Master Node → Data Node(×3) (以降 okuyama 関連資料 神戸デジタル・ラボ 岩瀬高博 氏 提供)
  • okuyama クライアント Client okuyamaへの問い合わせを実現 Client 専用クライアントはJavaと、PHPを実装 Client
  • okuyama マスターノード・クライアントからのI/F ・データノード管理・サポートプロトコル >データ入出力>オリジナル サポート分散アルゴリズム Master Node>Memcached 1. Mod ・set ・get ・add 2. ConsistentHash ・delete Master Node >生存監視 ・gets ・cas 起動時のデータリカバリ>HTTP ・制限台数なしに冗長化可能 ・GET
  • okuyama データノード Data Node Data Node Data Node ・データの保存を実現 ・データ保存方式を選択可能 Data Node Data Node Data Node ・最大3ノードにデータを保存 ・アクセスバランシング Data Node Data Node Data Node ・連鎖的ダウンの予防 Data Node Data Node Data Node
  • データ保存方式の選択1.全てのデータをメモリに保存 >非永続型 (key=メモリ、value=メモリ)2.データ操作履歴のみファイルに保存 >永続型(key=メモリ、value=メモリ)+操作記録 =ファイル3.データ本体をファイルに保存 >永続型(key=メモリ、value=ファイル)+操作記録 =ファイル4.全てをファイルに保存 >永続型(key=ファイル、value=ファイル)+操作記録 =ファイル
  • データの一貫性について 複数のノードに同一の値を保持していると、 データに異なる時間が発生する データ保存 保存 保存 未保存 DataNode DataNode DataNode データ取得 != データ取得
  • データ一貫性レベルの選択 1.弱一貫性 >全てのデータノードにランダムにアクセス 2.中一貫性 >常に最後に保存したデータノードからアクセス 3.強一貫性 >データノードの値を検証
  • okuyama に単一障害点は無い! データノード障害発生 もう一つのノードから取得 データ保持 ノード割り出し Data Ndoe DataNode MasterNode Data Node DataNode データ取得Client MasterNode Data Node DataNode Data Node DataNode
  • okuyama に単一障害点は無い! マスターノード障害発生 障害発生!! Data Ndoe DataNode データ取得 MasterNode Data Node DataNode Client MasterNode Data Node DataNode 別のマスターノードに Data Node DataNode 再接続して処理続行
  • 参考文献 ○ 岩瀬氏ブログ http://d.hatena.ne.jp/okuyamaoo/ ○ 岩瀬氏 Slideshare http://sliwww.slideshare.net/okuyamaoo ○ Think IT 連載記事 http://thinkit.co.jp/story/2011/02/03/1990(全4回) http://thinkit.co.jp/story/2011/10/12/2303(全3回) ○ WEB+DB PRESS Vol.65 ~Vol.67(全3回)
  • at+link の活用事例
  • okuyama キャッシュサーバ
  • ターゲット ・ DB の負荷が高くキャッシュを有効活用したい人 ・ メモリが欲しいだけなのに、専用のサーバを 用意するのは嫌だという人 ・ memcached ・TokyoTyrant を使っているけど 障害が不安な人 ・ memcached・TokyoTyrant を使っているけど 分散させたい人 ・ キャッシュの拡張性が欲しい人
  • okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノードクライアントアクセス メイン VIP LVS マスターノード データノード データノード LVS マスターノード データノード データノード スタンバイ マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  • okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノードクライアントアクセス メイン 障害! VIP LVS マスターノード データノード データノード LVS マスターノード データノード データノード スタンバイ マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  • okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノード 障害対応 LVS マスターノード データノード データノードクライアントアクセス VIP LVS マスターノード データノード データノード メイン マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  • okuyama キャッシュ 実際の構成 クライアントアクセス メイン スタンバイ LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード マスターノード:8GB メモリ搭載×2台 データノード :16GB メモリ搭載×4台 完全二重化構成 実効メモリ容量:32GB
  • データノード設定のツボ L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード フロントエンド バックエンド フロントエンド バックエンド KeyManagerJob1.memoryMode=false KeyManagerJob1.dataMemory=true データノード(バックエンド)の KeyManagerJob1.keyMemory=true 「DataNode.properties」で指定 KeyManagerJob1.keySize=5000000 KeyManagerJob1.memoryLimitSize=95 データの圧縮 DataSaveMapType=serialize SerializerClassName=okuyama.imdst.util.serializemap.ObjectStreamSerializer フロントエンドがメモリいっぱいになってもバックエンドは生き残る
  • データノード設定のツボ ただし、データ登録時に圧縮、データ取り出し時に解凍するので遅くなる LoadBalanceMode=true マスターノードの BalanceRatio=8:2 「MasterNode.properties」で指定 フロントエンドとバックエンドのアクセス比率を 8:2 に設定
  • okuyama キャッシュ LVS障害発生時 クライアントアクセス メイン スタンバイ 障害! LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード
  • okuyama キャッシュ LVS障害発生時 クライアントアクセス 障害機 メイン LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード
  • okuyama キャッシュ LVS障害発生時 クライアントアクセス 障害機 メイン LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード なぜか切り替わりに、どうしても数秒かかってしまう・・・
  • okuyama キャッシュ LVS障害発生時 クライアントアクセス 障害機 メイン LVS LVS VIP:192.168.1.1 VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード L2 スイッチのキャッシュ?こんな状態??
  • okuyama キャッシュ LVS障害発生時 クライアントアクセス メイン スタンバイ 障害! LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード
  • okuyama キャッシュ LVS運用のツボ クライアントアクセス 障害機 メイン LVS LVS VIP:192.168.1.1 L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード
  • okuyama キャッシュ LVS運用のツボ クライアントアクセス 障害機 メイン LVS LVS VIP:192.168.1.1 192.168.1.10 にログイン arping L2 スイッチ L2 スイッチマスターノード データノード データノード マスターノード データノード データノード192.168.1.10 192.168.1.1 で実行 ssh -i /root/.ssh/id_rsa_10 root@192.168.1.10 "arping -c 10 192.168.1.1" 192.168.1.1 までの経路上の arp キャッシュをクリア!
  • okuyama キャッシュの事例 ・ ソーシャルアプリ ピーク時秒間1,000~3,000アクセスのアプリ複数 ピーク時トータル秒間約10,000アクセス
  • okuyama 画像ストレージ
  • ターゲット ・ 消せない画像がどんどん増えて困っている人 ・ ディスク容量が欲しいだけなのに、わざわざ サーバを借りるのは嫌だという人 ・ アプリと画像データのネットワークを分けたい人 ・ okuyama を使ってみたい人
  • 旧画像ストレージ 実際の構成 クライアントアクセス メイン スタンバイ ロードバランサ ロードバランサ LVS L2 スイッチ L2 スイッチ Web アプリ Web アプリ Web アプリ Web アプリ マスターノード マスターノード マスターノード マスターノード データノード データノード データノード データノード API を受け付ける Web アプリ、マスターノード、データノードを 全て1台にまとめる LB でクライアントからのアクセスをロード場ランシング
  • 実際に起こった障害 について語ります
  • 悩みどころ ・ データを分割保存するチャンクサイズ ・ メモリ容量の確保 ・ バックアップの取り方 ・ リカバリの仕方 ・ 物理的なマシン設置の仕方 ・ コストとの兼ね合い
  • 教訓 ・ チャンクサイズの設計をしっかり ・ ユーザ側のサービスの性質によって 環境を分けよう ・ マスターノードとデータノードは物理的に 分けよう ・ データノードは三重化しよう (更新は1号機、2号機のみ、参照は3台に) ・ 独立した2つの環境を用意しよう (万が一のときに、影響範囲を少なくする) ・ コストとの兼ね合い
  • 新画像ストレージ 構想 メイン スタンバイ ロードバランサ ロードバランサ LVS L2 スイッチ L2 スイッチWeb アプリ Web アプリ Web アプリ Web アプリ Web アプリ Web アプリマスターノード A マスターノード B マスターノード C マスターノード D マスターノード E マスターノード F L2 スイッチ L2 スイッチデータノード A データノード B データノード C データノード D データノード E データノード Fデータノード A’ データノード B’ データノード C’ データノード D’ データノード E’ データノード F’データノード D’’ データノード E’’ データノード F’’ データノード A’’ データノード B’’ データノード C’’
  • 新画像ストレージ 構想 メイン スタンバイ ロードバランサ ロードバランサ LVS L2 スイッチ L2 スイッチWeb アプリ Web アプリ Web アプリ Web アプリ Web アプリ Web アプリマスターノード A マスターノード B マスターノード C マスターノード D マスターノード E マスターノード F L2 スイッチ L2 スイッチデータノード A データノード B データノード C データノード D データノード E データノード Fデータノード A’ データノード B’ データノード C’ データノード D’ データノード E’ データノード F’データノード D’’ データノード E’’ データノード F’’ データノード A’’ データノード B’’ データノード C’’
  • 新画像ストレージ 構想 メイン スタンバイ ロードバランサ ロードバランサ LVS L2 スイッチ L2 スイッチWeb アプリ Web アプリ Web アプリ Web アプリ Web アプリ Web アプリマスターノード A マスターノード B マスターノード C マスターノード D マスターノード E マスターノード F L2 スイッチ L2 スイッチデータノード A データノード B データノード C データノード D データノード E データノード Fデータノード A’ データノード B’ データノード C’ データノード D’ データノード E’ データノード F’データノード D’’ データノード E’’ データノード F’’ データノード A’’ データノード B’’ データノード C’’
  • 画像ストレージの事例 ・ ブログサービス ・ 写真共有サービス ・ 広告配信サービス ・ EC サイト ・ 短期キャンペーンサイト
  • デモンストレーション
  • okuyama 画像ストレージのデモ① ブラウザで体感! okuyama v.s. Apache
  • デモ環境 アプリプラットフォーム okuyama v.s. Apache! okuyama http://demo.at-link.ad.jpdemo.at-link.ad.jp okuyama 画像ストレージ Apache サーバ それぞれから画像を Apache 300枚読み込む (ファイルサイズ:60KB弱)
  • okuyama 画像ストレージのデモ② 画像ストレージを操作してみよう
  • 開発中サービス ・ ログストレージ ・ 大容量データストレージ ・ KDL 岩瀬氏開発 CEP(Complex Event Processing) エンジン「Setsuna」と連携した サーバのリアルタイム監視サービス
  • KDL の活用事例
  • MashUpFactory
  • MashUpFactory
  • MashUpFactory
  • MashUpFactory
  • MashUpFactory
  • コミュニティ ○ 公式サイト http://okuyama-project.com/ ○ SourceForge http://sourceforge.jp/projects/okuyama/ ○ facebook アカウント Okuyama-日本語 http://www.facebook.com/#!/okuyama.jp
  • オープンソース版 okuyamaぜひ使ってみてください!
  • ご清聴ありがとうございました!