1. cybozu.com のデータバックアップとリストア、
それを活用したリハーサル
SRE Tech Talks #2
サイボウズ株式会社
深谷敏邦

2. 自己紹介
▌深谷敏邦 (@toshi_pp)
▌運用本部・サービス運用部・SRE
▌弊社クラウドサービスネイティブ世代
 新卒５年目

3. アジェンダ
▌SRE とオペレーション
▌cybozu.com のバックアップについて
▌アップデートリハーサルの取り組み

4. SRE とオペレーション

5. SRE とオペレーション
▌SRE 本曰く、SRE とはソフトウェアエンジニア
 オペレータとは違う
▌しかし、Google でさえ最大 50% はオペレーションを行っている
▌現実は厳しい

6. なぜオペレーションを避けるのか
▌オペレーションはスケールしない
▌オペレーションは繰り返しで退屈
▌オペレーションはミスを生む
▌しかしそれでもオペレーションしないといけない

7. SRE とバックアップ
▌やらなければならないならできるだけ安全にやりたい
 事前レビュー
 ペアオペレーション
 バックアップ
▌バックアップがあれば最悪の事態でも復旧できる
 安心感

8. cybozu.com のバックアップについて

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

13. バックアップシステムについて
▌ベアメタルに最適化
▌高速なスキャン
 HDDはシーケンシャルにアクセスすれば速い
 ディスク10本のRAID6ならシーケンシャルリードが1GB/sでる
▌ハッシュを使った高速な増分検出
▌高速な圧縮
 snappy

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. アップデートリハーサル
▌データを更新するアップデート前に、本番手順を使ったリハーサルを行う
 想定外のデータがあることでアップデートが失敗しないか
 まれによくある
 アップデートに時間がかかりすぎないか
▌すべては安心のため

24. リハーサルの流れ
▌本番環境のコピーを作成
 バックアップデータから本番環境のスナップショットをリストア
▌アップデートスクリプトを流す
▌成功ならリリースへ
▌失敗なら開発チームにフィードバック
 データ依存ならリハーサル環境を使って調査

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
▌リソーススケジューラの導入
 オペレーションやコードの複雑さを低減させる

33. まとめ
▌サイボウズのバックアップの仕組みを紹介しました
 ベアメタル環境でのバックアップ、リストア
▌安心してオペレーションできる仕組みを作ろう
 バックアップツールの整備
 アップデートリハーサル

34. We are hiring!
サイボウズでは一緒にサービスを育てていく仲間を
募集しています