cybozu.com のデータバックアップとリストア、それを活用したリハーサル

SRE Tech Talks #2サイボウズ株式会社

深谷敏邦

自己紹介

▌深谷敏邦 (@toshi_pp)▌運用本部・サービス運用部・ SRE▌弊社クラウドサービスネイティブ世代

新卒５年目

アジェンダ

▌SRE とオペレーション

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

▌アップデートリハーサルの取り組み

SRE とオペレーション

SRE とオペレーション

▌SRE 本曰く、 SRE とはソフトウェアエンジニア オペレータとは違う

▌しかし、 Google でさえ最大 50% はオペレーションを行っている

▌現実は厳しい

なぜオペレーションを避けるのか

▌オペレーションはスケールしない

▌オペレーションは繰り返しで退屈

▌オペレーションはミスを生む

▌しかしそれでもオペレーションしないといけない

SRE とバックアップ

▌やらなければならないならできるだけ安全にやりたい 事前レビュー ペアオペレーション バックアップ

▌バックアップがあれば最悪の事態でも復旧できる 安心感

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

cybozu.com について

▌企業向けクラウドアプリケーションサービス 契約社数 17,000 社以上 契約ユーザー数 65 万人以上

▌データ量は 270TB 程度

アーキテクチャ

▌マルチテナント

▌マルチアプリケーション

▌マルチバックエンド MySQL Solr Blob server 独自データベース

heysha.cybozu.com

onsha.cybozu.com

cybozu.com の運用環境

▌ハウジングによる自社 DC 東日本にメイン環境 西日本にバックアップサイト

▌ベアメタルサーバーの利用

▌自社開発のクラウド基盤 KVM LVM+iSCSI

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

▌ディスクイメージレベルのオンラインバックアップ（物理バックアップ）

▌インクリメンタルフォーエバー 14 日分の増分を保持してその間の任意の時点がリストア可能

▌メリット ミドルウェア非依存

▌デメリット バックアップ時間がかかる リストアが遅い

fullimage …

restore restore

バックアップシステムについて

▌ベアメタルに最適化

▌高速なスキャン HDD はシーケンシャルにアクセスすれば速い ディスク 10 本の RAID6 ならシーケンシャルリードが 1GB/s

でる

▌ハッシュを使った高速な増分検出

▌高速な圧縮 snappy

010101010010101001

…

Backup server

Backup client

disk image hash

incremental diff

storage server backup server

遠隔レプリケーション

▌バックアップが 1 個しかないのは怖い オペミス 地震雷火事おやじ

▌DC 間データレプリケーション データ回線が細い (10Gbps v.s. 1Gbps)

▌CPU を活用して帯域を節約 並列 gzip 圧縮 LZMA は重すぎた…

東西の壁

東日本 DC 西日本 DC

replication server

replication client

backup server replication server

snappydiff

gzipdiff

リストアの工夫

▌増分バックアップはリストアが遅い 1 ボリュームのリストアに数十分～数時間かかる

▌データ量の観点で pre-restore はコストが大きい

▌増分だけ保持するブロックデバイスがあれば、リストアがそもそも不要 ⇒ dm-thinp

DM Thin Provisioning (dm-thinp)

▌ Linux kernel 3.2 から導入されたデバイスマッパー docker のストレージにも利用されている

▌ 書き込んだ部分だけ実容量を使用するブロックデバイス B 木によって論理ブロック↔実ブロックをマッピングする

▌ Incremental Diff を Thin デバイスとして保持する 保存容量を抑えることができる 利用時にリストアする必要がない

▌ スナップショットのスナップショットが作れる 利用前にスナップショットを作ることで任意のバックアップを自由に書き換

え可能

DM-thinp の失敗談

▌ マッピング用のメタデータデバイスが最大 16GB までしか利用できない 大量のマッピングを保持できない

▌ kernel 3.13 (Ubuntu trusty) ではいくつかバグを持っている B 木の操作が間違っていてデータ破損が起こる

upstream からバックポート済み

メタデータスナップショットを使ったときメタデータが破損する場合がある 原因不明

▌ 東日本のバックアップでは使わず、西日本のレプリケーション先でのみ使用

バックアップデータの活用

▌バックアップの運用環境への書き戻しは 99% 起こらない データを完全に破損してしまうほどのバグやオペミスはまれ

▌バックアップはコストではない 安全にお客様データに触れる手段

▌活用法障害調査 アップデートリハーサル

アップデートリハーサルの取り組み

アップデートリハーサル

▌データを更新するアップデート前に、本番手順を使ったリハーサルを行う想定外のデータがあることでアップデートが失敗しないか

まれによくある

アップデートに時間がかかりすぎないか

▌すべては安心のため

リハーサルの流れ

▌本番環境のコピーを作成 バックアップデータから本番環境のスナップショットをリ

ストア

▌アップデートスクリプトを流す

▌成功ならリリースへ

▌失敗なら開発チームにフィードバック データ依存ならリハーサル環境を使って調査

リハーサルに求められるリストアの要件

1. 環境全体のリストア

2. リソースアロケーションの自動化

3. グローバルに存在するサービスの扱い

①環境全体のリストア

▌データのリストアがあってもアプリケーションは動かない

▌データのバックアップ時点のアプリケーションの構成情報が必要

▌構成情報のリストアは単純ではない オリジナルのデータを向かないように、リストア先を見る

ようにする VM などの ID をオリジナルとかぶらないようにする

▌リストアというよりも当時の構成情報を基にした再構築

マルチテナント環境のリストア

▌1 つのアプリケーションをリストアすると、オリジナル、リストアの 2 つができる⇒マルチテナント

▌cybozu.com は最初からマルチテナント

▌マルチテナント環境をリストアすると？

① マルチテナント

② マルチテナントのマルチテナント

▌ オリジナルとリストア環境を区別したいので②

①

②

ワールドライン (WL)

▌マルチテナントのマルチテナントの名前元ネタは某ゲーム

▌あるタイミングの環境全体を一意に特定する ID 本番環境は現在を示す特別な WL を割り当てている

▌アプリケーションは WL とテナントの複合キーで識別される (WL, tenant) -> application

②リソースアロケーションの自動化

▌本番は職人 (SRE) による温かみのあるリソース割り当て

▌リストア環境構築ツールで使用メモリを元に貪欲法で割り当て まれにリソースが足りずにリハーサルが失敗する

その場合は手動で割り当てなおす

VM VM

VM VM

VM VM

③グローバルに存在するサービスの扱い

▌全テナントが共通に使うサービスがいくつか存在する画像変換サービス添付ファイルからの文章抽出サービス

▌WL が後づけでサービスはリクエスト元のテナントが識別できない

▌特定の WL だけを扱うように設定少なくともリハーサルはできる

(w1, a)

(w2, a)

imageconverter

tenant:a

tenant:a

喜びの声

今後に向けて

▌バックアップやリストアの仕組みを各サービスでネイティブに持つ後づけは大変

▌バックアップの高速化 ラボで開発した WalB の導入

https://github.com/walb-linux/walb-driver▌リソーススケジューラの導入

オペレーションやコードの複雑さを低減させる

まとめ

▌サイボウズのバックアップの仕組みを紹介しました ベアメタル環境でのバックアップ、リストア

▌安心してオペレーションできる仕組みを作ろう バックアップツールの整備 アップデートリハーサル

We are hiring!サイボウズでは一緒にサービスを育てていく仲間を

募集しています