小さく始めるBCP ― 多プロダクト環境で始める最初の一歩

Transcript

1. © SmartHR, Inc. ⼩さく始めるBCP 多プロダクト環境で始める最初の⼀歩 中間 啓介 株式会社SmartHR / SRE 2026/01/31 2026.1.31 SRE Kaigi 2026@中野セントラルパークカンファレンス
2. ⾃⼰紹介 2 中間 啓介（なかま けいすけ） 株式会社SmartHR / SRE ・2022/5〜 バックエンドエンジニア ・2024/1〜 SRE @kekke-n
3. SmartHRとは
4. 1. BCPの基礎知識 2. BCPに取り組む背景 3. BCPを実現するための課題 4. ⼩さく始めるBCP 5. 今後の⽅針 6. まとめ アジェンダ 4
5. • ⼩さくBCPを始めるためのヒント • 最⼩限のコストでDRを実装するアプローチ 本⽇お持ち帰りできること 5
6. BCPの基礎知識
7. BCPとは • Business Continuity Plan、事業継続計画 • ⼤きな災害や障害が起きても、事業を継続できるように、あらかじめ準備 しておく計画 • システムの観点では、DR（Disaster Recovery）がBCPの⼀環 7 BCP 従業員の 安全確保 防災用品 の備蓄 DR
8. • Disaster Recovery、災害復旧 • 災害等でダウンしたシステムを復旧させること • DRは復旧⽬標を決めてから、戦略を⽴てていくのが⼀般的 DRとは 8 BCP 従業員の 安全確保 防災用品 の備蓄 DR
9. 引⽤元: 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
10. DRの実装パターン 10 実装パターン 説明 実現できる RPO/RTO※ コスト ホットスタンバイ 本番環境と同等の予備環境を稼働させ、障害時 に即座に切り替える 数秒〜数分 高い ウォームスタンバイ 予備環境を最小限のリソースで稼働させ、障害時 に切り替える 数分〜数十 分 やや高い コールドスタンバイ 予備環境を停止状態にして、障害時に起動・構築 する 数時間 低い ※目安の時間です
11. 復旧⽬標とコストの関係 11 • 即時で復旧できるようにしたい ◦ ウォームスタンバイ‧ホットスタンバイ ◦ インフラコストが⾼くなる • 復旧対策のコストを抑えたい • コールドスタンバイ • 復旧時間、復旧時点が遅くなる 理想的な復旧⽬標とコストにはトレードオフの関係がある 復旧⽬標を決めるのは⼀概に簡単ではない
12. BCPに取り組む背景
13. SmartHRのアーキテクチャ 13 現在のSmartHR: プロダクトは約40、エンジニアは約200名
14. SREチーム 「開発チームの⾃律性と能⼒向上」を重視したイネイブリング型の組織です。 信頼性における課題に対して先回りして解決していける開発組織を⽬指しています。 • メンバー数は4名 • 全プロダクト‧チームに対して横断的に活動 • 主な取り組み • SLOの運⽤⽀援 • インフラ構築⽀援‧インフラコスト管理 • BCPの策定‧⾒直し • etc.. 14
15. • SmartHRは以前からBCPに取り組んでいた • 社会インフラになることを⽬指しているため、これまで以上にプロダ クトの信頼性を⾼めていくことが必要 BCPに取り組む背景 15
16. BCPを実現するための課題
17. SmartHRが直⾯した課題 17 • 復旧⽬標の決めづらさ ◦ ⼀般的な課題 • 各プロダクトで異なる復旧レベル ◦ マルチプロダクトであるSmartHR特有の課題
18. 復旧⽬標の決めづらさ
19. ちょうどよい復旧⽬標は決めづらい 19 • 理想的な復旧⽬標とコストはトレードオフの関係があるため、簡単に は決められない • 予期せぬ事態への対策について費⽤対効果を判断する材料が少ない • 災害頻度は予測できない • 災害時のユーザからの期待値はわからない ◦ ユーザーがどこまでデータ損失を許容してくれるのか？ ◦ どれだけの復旧時間を待てるのか？
20. 各プロダクトで異なる復旧レベル
21. 求められる復旧レベルの具体例 21 SmartHRはマルチプロダクトであるため、求められる復旧レベルが異なる キャリア台帳 タレントマネジメント系は分析に使われる 事が多く、⼀時的に業務が⽌まっても致命 的ではないことがある 勤怠‧給与関連のプロダクトは従業員に給 与の⽀払いができなくなる可能性がある 勤怠管理 給与計算 スキル管理 すぐ復旧しなくて⼤丈夫 即時に復旧させたい！ 復旧レベルに応じた対策をそれぞれ⽤意する必要がある
22. 意思決定をする材料も少ない…… 検討することも多い…… どのようなアプローチとればいいのか……🤯 22 複雑な課題に直⾯して、⽴ち⽌まってしまった
23. SmartHRの経験を振り返ると...🤔 23 「⼩さく始めて、フィードバックを受けながら、軌道修正していく」やり⽅を取 ることが多かった • プロダクト開発の場合 ◦ ⼩さな機能を少しずつリリースしユーザーの反応を⾒ながら次の開発 アイテムを決めていく • SLI（サービスレベル指標）/SLO（サービスレベル⽬標）の運⽤の場合 ◦ まずSLIを可視化し、得られたデータをもとに少しずつ最適なSLOを⾒ つけていく BCPでも「⼩さく始める」ことに挑戦💪
24. ⼩さく始めるBCP
25. 実現⽅法
26. ⽅針 26 • 完璧な復旧⽬標は求めない • DRの実装を進めていき、現実的なDRをベースとして復旧⽬標 を考える
27. 実装⼿順 27 • 復旧を最優先すべきプロダクトの特定 • 現状構成のままDR実装 • 最⼩限の労⼒で訓練実施
28. 復旧を最優先すべき プロダクトの特定
29. • 各プロダクトの復旧優先度を決めるために「業務の影響度」、「プロダ クト間の依存度」を評価 各プロダクトの復旧優先度を決める 29
30. 業務の影響度 30 影響度 基準 プロダクト例 大 災害時に業務に支障がでる可能性が高い 勤怠・給与計算等... 中 災害時に業務に支障がでる可能性が高いが、代替 案が考えられる xxxx 小 災害時に業務に支障がでない可能性が低い タレントマネジメント関 連のプロダクト • そのプロダクトがダウンすると業務に影響がでる度合い • 影響度が⾼いプロダクトは復旧優先度を⾼くする
31. プロダクト間の依存度 31 • そのプロダクトがダウンした際に他のプロダクトに影響がでるものを特定 • 対象のプロダクトは復旧優先度を⾼くする 他プロダクトから 参照されているプロダクト
32. • 「業務の影響度」「プロダクトの依存度」を加味してプロダクトの復旧優先 度を決める • 開発者‧ビジネスサイドのメンバーにレビュー依頼 開発者‧ビジネスサイドのメンバーにレビュー依頼 32 プロダクトの復旧優先度 XXは災害時でも必 要だから優先度上 げたほうよさそう ビジネスサイド 開発者 XXは他のプロダク トに依存してるよ 業務の影響度 プロダクトの 依存度
33. • 最終的に最優先となったプロダクトを直近のスコープとした • 他のプロダクトは段階的に対応する⽅針としました 最優先のプロダクトを選定 33
34. 現状構成のままDR実装
35. • インフラはGoogle Cloud • Terraformで管理 • 復旧のシナリオは東京リージョン（asia-northeast1）が使えなくなっ た時に⼤阪リージョン（asia-northeast2）へ移⾏することを想定 前提 35
36. 復旧⽅針 36 • インフラアーキテクチャは現状構成を維持する • DRの実装パターンはコールドスタンバイを採⽤ • 障害発⽣時に⼤阪リージョンにインフラリソースを構築
37. # 東京リージョン用 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 擬似コード ⼤阪リージョンに変更 東京⽤のコードをコピー それ以外の値はそのまま
38. • DB ◦ 定期バックアップ取得し障害時にリストアして復旧 • それ以外のデータ系（オブジェクトストレージ、シークレット等） ◦ 可能なものはマルチリージョン構成を採⽤（低コストかつ構築が容易） ◦ Terraformのstateファイルもマルチリージョン構成を取る データの復旧⽅法 38
39. 復旧⼿順が必要なインフラリソースの特定 39 • Terraformのstateファイルからインフラリソースを洗い出す ◦ terraform pull stateを活⽤ • 東京リージョンにしかないリソースを特定し復旧⼿順のスコープとする
40. 復旧⼿順書の作成 40 • インフラリソースの依存関係を整理して復旧順序を明確にする • 各インフラリソースの復旧⽅法を記載
41. • ⼿順が完成したら検証環境で⼀通り復旧できるか確認 ◦ ⼿順のヌケモレを⾒つけられる • 各⼿順の時間を計測しておき復旧全体の時間を概算する ◦ ここで現実的な復旧時間が明らかになる ◦ 精度の⾼いRTO（⽬標復旧時間）を決めるための材料となる 復旧⼿順の検証 41
42. 最⼩限の労⼒で訓練実施
43. • 新しい復旧⼿順書に従って復旧できるのは当時⾃分１⼈... • 開発者が復旧できるように、⼿順書をブラッシュアップしたかった 訓練を実施する背景 43
44. • 単にドキュメントの読み合わせ ◦ 復旧⼿順のイメージがつかない可能性がある • 実際に環境を壊して検証をする ◦ 時間が膨⼤にかかるため現実的ではない 訓練をどうやろうか悩んだ.. 44
45. 訓練の⽬的‧実施スコープを設定 「⼩さく始める」ことを意識しつつ、効果が期待できる⽬的‧スコープを設定 • ⽬的 ◦ 復旧できる開発者を1⼈以上に増やす ◦ ⼿順書の改善点を洗い出す • 実施スコープ ◦ プロダクトの復旧作業のみ ◦ それ以外はスコープ外 ▪ 関係各所との連携等 45
46. 訓練の実施要領 • 参加者 ◦ 復旧対象のプロダクトに所属する開発者5⼈ ◦ ただし、東京23区に住んでいない⼈ • 実施内容 ◦ 参加者が実際に⼿を動かして、インフラの修正箇所を確認する ▪ 例）Terraformの修正箇所をローカルのエディターで確認 ◦ 訓練中に⼿順の改善点があれば参加者からフィードバックをもらう • やらないこと ◦ 実際にインフラを壊したり、作ったりすること 46
47. 訓練の振り返り • 良かったこと ◦ ⼿を動かすことで、復旧作業のイメージができた ◦ ⼿順書を読むだけより理解を深められた • 改善点 ◦ インフラの最適化が⾏われていないので、⼿順が煩雑だった 47 最⼩限のコストで、復旧できる⼈を増やすことができた！
48. ⼩さく始めてよかったこと
49. • 「完璧な復旧⽬標は求めない」⽅針にしたことで、BCPの最初の⼀歩 を踏み出すことができた 前に進めない状態から抜け出せた 49
50. • 現実的な復旧時間‧バックアップのコストが⾒えてきたので、精度の ⾼い復旧⽬標を議論する⼟台ができた • DRのノウハウが蓄積されたので、他プロダクトへの展開できるよう になった ◦ 復旧対策の観点や必要⼯数などが明確化 ◦ 他プロダクトのチームへ対策を依頼しやすくなった 次の改善に繋げることができた 50
51. • インフラアーキテクチャは現状を維持しているため、インフラに対す る運⽤負荷は増やさずに済んだ ◦ Terraformのコードベースも増やさずに済んだ • ⽬的を⼩さく設定したことで、少ない⼯数で効果的な訓練ができた 開発者の負担を最⼩限に抑えることができた 51
52. 今後の⽅針
53. ⼩さく始めて、⼤きく成⻑ 53 ⼩さく始めたBCPをベースとして、BCPをより強固のものにしていく💪 • 精度の⾼い復旧⽬標（RTO/RPO）の⾒直し • 他の優先すべきプロダクトのDRのアップデート • 関係部署との連携を加味した全体訓練
54. DBのバックアップコスト思ったより⾼かった • 利⽤していたDBの仕様上、他リージョンにバックアップを取るにはフルバッ クアップしか選べなかった • この状況で定期的なバックアップを実⾏すると、⼤阪リージョンへの転送コ ストが想定以上に⾼くなった • 現在、コストとRPO（復旧⽬標時点）を天秤にかけて経営陣と議論している が、最適な結論はまだでていない • ウォームスタンバイ‧ホットスタンバイなどの選択肢も含めて、改めて検討 する余地が⾒えてきた 今後の改善に繋げていく💪 54 新たに⾒えてきた課題
55. まとめ
56. 不確実な状況を超える「⼩さく始めるBCP」 • BCPは最初から完璧を⽬指さず、「⼩さく始める」だけでも ⼗分価値がある • ⼤切なのは継続的に改善を続けていくこと • 不確実な部分を少しずつ減らしながら、BCPを最適な状態に していくのが良いアプローチ 56
57. 宣伝
58. SmartHRの樋⼝も登壇します！！！ 58 Room A‧15:05 - 15:35 こちらのセッションも是⾮ご覧ください！！！
59. スポンサーブースもあります！！！ 59 「SREと開発チームのエンジニア⽐率」をテーマにした シール投票をやってます！ 投票に参加いただいた⽅には、SmartHRの増えてくアク キーをプレゼントしてます！ 是⾮お⽴ち寄りください！
60. ご清聴ありがとうございました! 60