小さく始めるBCP ― 多プロダクト環境で始める最初の一歩

by kekke-n

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介 2 中間啓介（なかまけいすけ）株式会社SmartHR / SRE ・2022/5〜バックエンドエンジニア・2024/1〜 SRE @kekke-n

Slide 3

Slide 3 text

SmartHRとは

Slide 4

Slide 4 text

1. BCPの基礎知識 2. BCPに取り組む背景 3. BCPを実現するための課題 4. ⼩さく始めるBCP 5. 今後の⽅針 6. まとめアジェンダ 4

Slide 5

Slide 5 text

● ⼩さくBCPを始めるためのヒント ● 最⼩限のコストでDRを実装するアプローチ本⽇お持ち帰りできること 5

Slide 6

Slide 6 text

BCPの基礎知識

Slide 7

Slide 7 text

BCPとは ● Business Continuity Plan、事業継続計画 ● ⼤きな災害や障害が起きても、事業を継続できるように、あらかじめ準備しておく計画 ● システムの観点では、DR（Disaster Recovery）がBCPの⼀環 7 BCP 従業員の安全確保防災用品の備蓄 DR

Slide 8

Slide 8 text

● Disaster Recovery、災害復旧 ● 災害等でダウンしたシステムを復旧させること ● DRは復旧⽬標を決めてから、戦略を⽴てていくのが⼀般的 DRとは 8 BCP 従業員の安全確保防災用品の備蓄 DR

Slide 9

Slide 9 text

引⽤元: AWS - 事業継続計画 (BCP) https://docs.aws.amazon.com/ja_jp/whit epapers/latest/disaster-recovery-workloa ds-on-aws/business-continuity-plan-bcp. html 復旧⽬標とは ● RPO（Recovery Point Objective：⽬標復旧時点） ○ 「いつまでのデータを復旧させるか」の⽬標 ○ 例）RPO=1⽇の場合、障害発⽣の1⽇前までのデータを復旧できる必要がある ● RTO（Recovery Time Objective：⽬標復旧時間） ○ 「いつまでにシステムを復旧させるか」の⽬標 ○ 例）RTO=12時間の場合、障害発⽣から12時間以内に復旧させる必要がある 9

Slide 10

Slide 10 text

DRの実装パターン 10 実装パターン説明実現できる RPO/RTO※ コストホットスタンバイ本番環境と同等の予備環境を稼働させ、障害時に即座に切り替える数秒〜数分高いウォームスタンバイ予備環境を最小限のリソースで稼働させ、障害時に切り替える数分〜数十分やや高いコールドスタンバイ予備環境を停止状態にして、障害時に起動・構築する数時間低い ※目安の時間です

Slide 11

Slide 11 text

復旧⽬標とコストの関係 11 ● 即時で復旧できるようにしたい ○ ウォームスタンバイ‧ホットスタンバイ ○ インフラコストが⾼くなる ● 復旧対策のコストを抑えたい ● コールドスタンバイ ● 復旧時間、復旧時点が遅くなる理想的な復旧⽬標とコストにはトレードオフの関係がある復旧⽬標を決めるのは⼀概に簡単ではない

Slide 12

Slide 12 text

BCPに取り組む背景

Slide 13

Slide 13 text

SmartHRのアーキテクチャ 13 現在のSmartHR: プロダクトは約40、エンジニアは約200名

Slide 14

Slide 14 text

SREチーム「開発チームの⾃律性と能⼒向上」を重視したイネイブリング型の組織です。信頼性における課題に対して先回りして解決していける開発組織を⽬指しています。 ● メンバー数は4名 ● 全プロダクト‧チームに対して横断的に活動 ● 主な取り組み ● SLOの運⽤⽀援 ● インフラ構築⽀援‧インフラコスト管理 ● BCPの策定‧⾒直し ● etc.. 14

Slide 15

Slide 15 text

● SmartHRは以前からBCPに取り組んでいた ● 社会インフラになることを⽬指しているため、これまで以上にプロダクトの信頼性を⾼めていくことが必要 BCPに取り組む背景 15

Slide 16

Slide 16 text

BCPを実現するための課題

Slide 17

Slide 17 text

SmartHRが直⾯した課題 17 ● 復旧⽬標の決めづらさ ○ ⼀般的な課題 ● 各プロダクトで異なる復旧レベル ○ マルチプロダクトであるSmartHR特有の課題

Slide 18

Slide 18 text

復旧⽬標の決めづらさ

Slide 19

Slide 19 text

ちょうどよい復旧⽬標は決めづらい 19 ● 理想的な復旧⽬標とコストはトレードオフの関係があるため、簡単には決められない ● 予期せぬ事態への対策について費⽤対効果を判断する材料が少ない ● 災害頻度は予測できない ● 災害時のユーザからの期待値はわからない ○ ユーザーがどこまでデータ損失を許容してくれるのか？ ○ どれだけの復旧時間を待てるのか？

Slide 20

Slide 20 text

各プロダクトで異なる復旧レベル

Slide 21

Slide 21 text

求められる復旧レベルの具体例 21 SmartHRはマルチプロダクトであるため、求められる復旧レベルが異なるキャリア台帳タレントマネジメント系は分析に使われる事が多く、⼀時的に業務が⽌まっても致命的ではないことがある勤怠‧給与関連のプロダクトは従業員に給与の⽀払いができなくなる可能性がある勤怠管理給与計算スキル管理すぐ復旧しなくて⼤丈夫即時に復旧させたい！復旧レベルに応じた対策をそれぞれ⽤意する必要がある

Slide 22

Slide 22 text

意思決定をする材料も少ない…… 検討することも多い…… どのようなアプローチとればいいのか……🤯 22 複雑な課題に直⾯して、⽴ち⽌まってしまった

Slide 23

Slide 23 text

SmartHRの経験を振り返ると...🤔 23 「⼩さく始めて、フィードバックを受けながら、軌道修正していく」やり⽅を取ることが多かった ● プロダクト開発の場合 ○ ⼩さな機能を少しずつリリースしユーザーの反応を⾒ながら次の開発アイテムを決めていく ● SLI（サービスレベル指標）/SLO（サービスレベル⽬標）の運⽤の場合 ○ まずSLIを可視化し、得られたデータをもとに少しずつ最適なSLOを⾒つけていく BCPでも「⼩さく始める」ことに挑戦💪

Slide 24

Slide 24 text

⼩さく始めるBCP

Slide 25

Slide 25 text

実現⽅法

Slide 26

Slide 26 text

⽅針 26 ● 完璧な復旧⽬標は求めない ● DRの実装を進めていき、現実的なDRをベースとして復旧⽬標を考える

Slide 27

Slide 27 text

実装⼿順 27 ● 復旧を最優先すべきプロダクトの特定 ● 現状構成のままDR実装 ● 最⼩限の労⼒で訓練実施

Slide 28

Slide 28 text

復旧を最優先すべきプロダクトの特定

Slide 29

Slide 29 text

● 各プロダクトの復旧優先度を決めるために「業務の影響度」、「プロダクト間の依存度」を評価各プロダクトの復旧優先度を決める 29

Slide 30

Slide 30 text

業務の影響度 30 影響度基準プロダクト例大災害時に業務に支障がでる可能性が高い勤怠・給与計算等... 中災害時に業務に支障がでる可能性が高いが、代替案が考えられる xxxx 小災害時に業務に支障がでない可能性が低いタレントマネジメント関連のプロダクト ● そのプロダクトがダウンすると業務に影響がでる度合い ● 影響度が⾼いプロダクトは復旧優先度を⾼くする

Slide 31

Slide 31 text

プロダクト間の依存度 31 ● そのプロダクトがダウンした際に他のプロダクトに影響がでるものを特定 ● 対象のプロダクトは復旧優先度を⾼くする他プロダクトから参照されているプロダクト

Slide 32

Slide 32 text

● 「業務の影響度」「プロダクトの依存度」を加味してプロダクトの復旧優先度を決める ● 開発者‧ビジネスサイドのメンバーにレビュー依頼開発者‧ビジネスサイドのメンバーにレビュー依頼 32 プロダクトの復旧優先度 XXは災害時でも必要だから優先度上げたほうよさそうビジネスサイド開発者 XXは他のプロダクトに依存してるよ業務の影響度プロダクトの依存度

Slide 33

Slide 33 text

● 最終的に最優先となったプロダクトを直近のスコープとした ● 他のプロダクトは段階的に対応する⽅針としました最優先のプロダクトを選定 33

Slide 34

Slide 34 text

現状構成のままDR実装

Slide 35

Slide 35 text

● インフラはGoogle Cloud ● Terraformで管理 ● 復旧のシナリオは東京リージョン（asia-northeast1）が使えなくなった時に⼤阪リージョン（asia-northeast2）へ移⾏することを想定前提 35

Slide 36

Slide 36 text

復旧⽅針 36 ● インフラアーキテクチャは現状構成を維持する ● DRの実装パターンはコールドスタンバイを採⽤ ● 障害発⽣時に⼤阪リージョンにインフラリソースを構築

Slide 37

Slide 37 text

# 東京リージョン用 resource "google_cloud_run_v2_service" "tokyo" { location = "asia-northeast1" # 東京 cpu = "2" memory = "1024M" } # 大阪リージョン用 resource "google_cloud_run_v2_service" "osaka" { location = "asia-northeast2" # 大阪 cpu = "2" memory = "1024M" } Terraformを活⽤する ● 障害発⽣時に東京⽤のコードをコピーして、⼤阪⽤のコードを追加する ● 平時は予め⼤阪⽤のコードは準備しない ○ 普段の開発時に意識する必要がなくなる⼤阪リージョンのインフラ構築⽅法 37 擬似コード⼤阪リージョンに変更東京⽤のコードをコピーそれ以外の値はそのまま

Slide 38

Slide 38 text

● DB ○ 定期バックアップ取得し障害時にリストアして復旧 ● それ以外のデータ系（オブジェクトストレージ、シークレット等） ○ 可能なものはマルチリージョン構成を採⽤（低コストかつ構築が容易） ○ Terraformのstateファイルもマルチリージョン構成を取るデータの復旧⽅法 38

Slide 39

Slide 39 text

復旧⼿順が必要なインフラリソースの特定 39 ● Terraformのstateファイルからインフラリソースを洗い出す ○ terraform pull stateを活⽤ ● 東京リージョンにしかないリソースを特定し復旧⼿順のスコープとする

Slide 40

Slide 40 text

復旧⼿順書の作成 40 ● インフラリソースの依存関係を整理して復旧順序を明確にする ● 各インフラリソースの復旧⽅法を記載

Slide 41

Slide 41 text

● ⼿順が完成したら検証環境で⼀通り復旧できるか確認 ○ ⼿順のヌケモレを⾒つけられる ● 各⼿順の時間を計測しておき復旧全体の時間を概算する ○ ここで現実的な復旧時間が明らかになる ○ 精度の⾼いRTO（⽬標復旧時間）を決めるための材料となる復旧⼿順の検証 41

Slide 42

Slide 42 text

最⼩限の労⼒で訓練実施

Slide 43

Slide 43 text

● 新しい復旧⼿順書に従って復旧できるのは当時⾃分１⼈... ● 開発者が復旧できるように、⼿順書をブラッシュアップしたかった訓練を実施する背景 43

Slide 44

Slide 44 text

● 単にドキュメントの読み合わせ ○ 復旧⼿順のイメージがつかない可能性がある ● 実際に環境を壊して検証をする ○ 時間が膨⼤にかかるため現実的ではない訓練をどうやろうか悩んだ.. 44

Slide 45

Slide 45 text

訓練の⽬的‧実施スコープを設定「⼩さく始める」ことを意識しつつ、効果が期待できる⽬的‧スコープを設定 ● ⽬的 ○ 復旧できる開発者を1⼈以上に増やす ○ ⼿順書の改善点を洗い出す ● 実施スコープ ○ プロダクトの復旧作業のみ ○ それ以外はスコープ外 ■ 関係各所との連携等 45

Slide 46

Slide 46 text

訓練の実施要領 ● 参加者 ○ 復旧対象のプロダクトに所属する開発者5⼈ ○ ただし、東京23区に住んでいない⼈ ● 実施内容 ○ 参加者が実際に⼿を動かして、インフラの修正箇所を確認する ■ 例）Terraformの修正箇所をローカルのエディターで確認 ○ 訓練中に⼿順の改善点があれば参加者からフィードバックをもらう ● やらないこと ○ 実際にインフラを壊したり、作ったりすること 46

Slide 47

Slide 47 text

訓練の振り返り ● 良かったこと ○ ⼿を動かすことで、復旧作業のイメージができた ○ ⼿順書を読むだけより理解を深められた ● 改善点 ○ インフラの最適化が⾏われていないので、⼿順が煩雑だった 47 最⼩限のコストで、復旧できる⼈を増やすことができた！

Slide 48

Slide 48 text

⼩さく始めてよかったこと

Slide 49

Slide 49 text

● 「完璧な復旧⽬標は求めない」⽅針にしたことで、BCPの最初の⼀歩を踏み出すことができた前に進めない状態から抜け出せた 49

Slide 50

Slide 50 text

● 現実的な復旧時間‧バックアップのコストが⾒えてきたので、精度の⾼い復旧⽬標を議論する⼟台ができた ● DRのノウハウが蓄積されたので、他プロダクトへの展開できるようになった ○ 復旧対策の観点や必要⼯数などが明確化 ○ 他プロダクトのチームへ対策を依頼しやすくなった次の改善に繋げることができた 50

Slide 51

Slide 51 text

● インフラアーキテクチャは現状を維持しているため、インフラに対する運⽤負荷は増やさずに済んだ ○ Terraformのコードベースも増やさずに済んだ ● ⽬的を⼩さく設定したことで、少ない⼯数で効果的な訓練ができた開発者の負担を最⼩限に抑えることができた 51

Slide 52

Slide 52 text

今後の⽅針

Slide 53

Slide 53 text

⼩さく始めて、⼤きく成⻑ 53 ⼩さく始めたBCPをベースとして、BCPをより強固のものにしていく💪 ● 精度の⾼い復旧⽬標（RTO/RPO）の⾒直し ● 他の優先すべきプロダクトのDRのアップデート ● 関係部署との連携を加味した全体訓練

Slide 54

Slide 54 text

DBのバックアップコスト思ったより⾼かった ● 利⽤していたDBの仕様上、他リージョンにバックアップを取るにはフルバックアップしか選べなかった ● この状況で定期的なバックアップを実⾏すると、⼤阪リージョンへの転送コストが想定以上に⾼くなった ● 現在、コストとRPO（復旧⽬標時点）を天秤にかけて経営陣と議論しているが、最適な結論はまだでていない ● ウォームスタンバイ‧ホットスタンバイなどの選択肢も含めて、改めて検討する余地が⾒えてきた今後の改善に繋げていく💪 54 新たに⾒えてきた課題

Slide 55

Slide 55 text

まとめ

Slide 56

Slide 56 text

不確実な状況を超える「⼩さく始めるBCP」 ● BCPは最初から完璧を⽬指さず、「⼩さく始める」だけでも⼗分価値がある ● ⼤切なのは継続的に改善を続けていくこと ● 不確実な部分を少しずつ減らしながら、BCPを最適な状態にしていくのが良いアプローチ 56

Slide 57

Slide 57 text

宣伝

Slide 58

Slide 58 text

SmartHRの樋⼝も登壇します！！！ 58 Room A‧15:05 - 15:35 こちらのセッションも是⾮ご覧ください！！！

Slide 59

Slide 59 text

スポンサーブースもあります！！！ 59 「SREと開発チームのエンジニア⽐率」をテーマにしたシール投票をやってます！投票に参加いただいた⽅には、SmartHRの増えてくアクキーをプレゼントしてます！是⾮お⽴ち寄りください！

Slide 60

Slide 60 text

ご清聴ありがとうございました! 60