cybozu.com のデータバックアップとリストア、それを活用したリハーサル
- 1. cybozu.com のデータバックアップとリストア、 それを活用したリハーサル SRE Tech Talks #2 サイボウズ株式会社 深谷敏邦
- 4. SRE とオペレーション
- 5. SRE とオペレーション ▌SRE 本曰く、SRE とはソフトウェアエンジニア オペレータとは違う ▌しかし、Google でさえ最大 50% はオペレーションを行っている ▌現実は厳しい
- 7. SRE とバックアップ ▌やらなければならないならできるだけ安全にやりたい 事前レビュー ペアオペレーション バックアップ ▌バックアップがあれば最悪の事態でも復旧できる 安心感
- 9. cybozu.com について ▌企業向けクラウドアプリケーションサービス 契約社数17,000社以上 契約ユーザー数65万人以上 ▌データ量は270TB程度
- 10. アーキテクチャ ▌マルチテナント ▌マルチアプリケーション ▌マルチバックエンド MySQL Solr Blob server 独自データベース heysha.cybozu.com onsha.cybozu.com
- 11. cybozu.com の運用環境 ▌ハウジングによる自社DC 東日本にメイン環境 西日本にバックアップサイト ▌ベアメタルサーバーの利用 ▌自社開発のクラウド基盤 KVM LVM+iSCSI
- 12. cybozu.com のバックアップについて ▌ディスクイメージレベルのオンラインバックアップ（物理バックアップ） ▌インクリメンタルフォーエバー 14日分の増分を保持してその間の任意の時点がリストア可能 ▌メリット ミドルウェア非依存 ▌デメリット バックアップ時間がかかる リストアが遅い full image … restore restore
- 14. 010101010 010101001 … Backup server Backup client disk image hash incremental diff storage server backup server
- 15. 遠隔レプリケーション ▌バックアップが1個しかないのは怖い オペミス 地震雷火事おやじ ▌DC間データレプリケーション データ回線が細い(10Gbps v.s. 1Gbps) ▌CPU を活用して帯域を節約 並列gzip圧縮 LZMAは重すぎた…
- 16. 東 西 の 壁 東日本DC 西日本DC replication server replication client backup server replication server snappy diff gzip diff
- 17. リストアの工夫 ▌増分バックアップはリストアが遅い 1ボリュームのリストアに数十分～数時間かかる ▌データ量の観点で pre-restore はコストが大きい ▌増分だけ保持するブロックデバイスがあれば、リストアがそもそも不要 ⇒ dm-thinp
- 18. DM Thin Provisioning (dm-thinp) ▌Linux kernel 3.2 から導入されたデバイスマッパー docker のストレージにも利用されている ▌書き込んだ部分だけ実容量を使用するブロックデバイス B木によって論理ブロック↔実ブロックをマッピングする ▌Incremental Diff を Thin デバイスとして保持する 保存容量を抑えることができる 利用時にリストアする必要がない ▌スナップショットのスナップショットが作れる 利用前にスナップショットを作ることで任意のバックアップを自由に書き換え可能
- 20. DM-thinp の失敗談 ▌マッピング用のメタデータデバイスが最大16GBまでしか利用できない 大量のマッピングを保持できない ▌kernel 3.13 (Ubuntu trusty) ではいくつかバグを持っている B木の操作が間違っていてデータ破損が起こる upstream からバックポート済み メタデータスナップショットを使ったときメタデータが破損する場合がある 原因不明 ▌東日本のバックアップでは使わず、西日本のレプリケーション先でのみ使用
- 21. バックアップデータの活用 ▌バックアップの運用環境への書き戻しは99%起こらない データを完全に破損してしまうほどのバグやオペミスはまれ ▌バックアップはコストではない 安全にお客様データに触れる手段 ▌活用法 障害調査 アップデートリハーサル
- 22. アップデートリハーサルの取り組み
- 23. アップデートリハーサル ▌データを更新するアップデート前に、本番手順を使ったリハーサルを行う 想定外のデータがあることでアップデートが失敗しないか まれによくある アップデートに時間がかかりすぎないか ▌すべては安心のため
- 25. リハーサルに求められるリストアの要件 1. 環境全体のリストア 2. リソースアロケーションの自動化 3. グローバルに存在するサービスの扱い
- 26. ①環境全体のリストア ▌データのリストアがあってもアプリケーションは動かない ▌データのバックアップ時点のアプリケーションの構成情報が必要 ▌構成情報のリストアは単純ではない オリジナルのデータを向かないように、リストア先を見るようにする VM などの ID をオリジナルとかぶらないようにする ▌リストアというよりも当時の構成情報を基にした再構築
- 27. マルチテナント環境のリストア ▌1つのアプリケーションをリストアすると、オリジナル、リストアの2つができる ⇒マルチテナント ▌cybozu.com は最初からマルチテナント ▌マルチテナント環境をリストアすると？ ① マルチテナント ② マルチテナントのマルチテナント ▌ オリジナルとリストア環境を区別したいので② ① ②
- 28. ワールドライン(WL) ▌マルチテナントのマルチテナントの名前 元ネタは某ゲーム ▌あるタイミングの環境全体を一意に特定するID 本番環境は現在を示す特別なWLを割り当てている ▌アプリケーションはWLとテナントの複合キーで識別される (WL, tenant) -> application
- 29. ②リソースアロケーションの自動化 ▌本番は職人(SRE)による温かみのあるリソース割り当て ▌リストア環境構築ツールで使用メモリを元に貪欲法で割り当て まれにリソースが足りずにリハーサルが失敗する その場合は手動で割り当てなおす VM VM VM VM VM VM
- 30. ③グローバルに存在するサービスの扱い ▌全テナントが共通に使うサービスがいくつか存在する 画像変換サービス 添付ファイルからの文章抽出サービス ▌WLが後づけでサービスはリクエスト元のテナントが識別できない ▌特定のWLだけを扱うように設定 少なくともリハーサルはできる (w1, a) (w2, a) image converter tenant:a tenant:a
- 31. 喜びの声
- 32. 今後に向けて ▌バックアップやリストアの仕組みを各サービスでネイティブに持つ 後づけは大変 ▌バックアップの高速化 ラボで開発した WalB の導入 https://github.com/walb-linux/walb-driver ▌リソーススケジューラの導入 オペレーションやコードの複雑さを低減させる
Editor's Notes
- #11: マルチテナント slack と同じようにサブドメインで分かれる