大規模災害時でも高い信頼性を維持するアプリケーション基盤の実現/nikkei-tech-talk46

大規模災害時でも高い信頼性を維持するアプリケーション基盤の実現 というタイトルで日本経済新聞社のSREチーム 石上 椋一 さんが発表しました。
NIKKEI Tech Talk #46
https://nikkei.connpass.com/event/391773/

Transcript

1. 2026/5/28 日本経済新聞社　SREチーム 石上 椋一 大規模災害時でも高い信頼性を 維持するアプリケーション基盤の実現 NIKKEI TECH TALK #46 1
2. ハッシュタグ #nikkei_tech_talk 自己紹介 2 石上 椋一(いしがみ りょういち) 日本経済新聞社 2025年入社 技術戦略ユニット SREチーム所属 社内共通基盤・社内 SRE実践の推進
3. ハッシュタグ #nikkei_tech_talk 本日話すこと • 報道機関に求められる事業継続性 • 共通基盤の Vessel とは • 大規模災害時のサービス継続手順と課題 • 改善アプローチとその効果 • まとめ・今後の展望 3
4. ハッシュタグ #nikkei_tech_talk 4 各チームに 便利なシステム基盤 を提供する SREの実践を助ける 指南書や確認ポイント を提供する プラットフォーム SRE イネーブルメント SRE 日経 SRE ー２つの活動分野 Vessel:アプリケーション基盤 Cage: 負荷試験の基盤 Titan: 可観測性の基盤 SREガイドライン SREトレイルマップ SREクライテリア
5. ハッシュタグ #nikkei_tech_talk 5 各チームに 便利なシステム基盤 を提供する プラットフォーム SRE 日経 SRE ー２つの活動分野 Vessel:アプリケーション基盤 Titan: 可観測性の基盤 Cage: 負荷試験の基盤 Vessel(ベッセル)とは • 自社開発の共通基盤 • アプリケーションコンテナを載せている ◦ 日経電子版サービス • コンテナ船(container vessel)
6. 報道機関の事業継続性に求められるシステム 6
7. ハッシュタグ #nikkei_tech_talk 報道機関として • 様々な媒体で情報を発信 ◦ 本紙朝刊/夕刊、日経MJ ◦ 電子版アプリ/Webサイト/メール/Push通知/SNS • いついかなる時でも情報を提供する役目がある ◦ 正確で中立な情報を発信 7
8. ハッシュタグ #nikkei_tech_talk 「有事」の時こそ、確実に届ける 8 皆さんもニュー スなどで確認し たのでは？
9. ハッシュタグ #nikkei_tech_talk 新聞印刷のトラブル回避例 • 機械などが故障した際、他の自社工場で印刷/輸送を実現 9 自社工場A 自社工場B 紙面データ送信 故障連絡 本社
10. ハッシュタグ #nikkei_tech_talk 日本経済新聞の購読者 10 媒体 購読数 購読数合計 約231万人 朝刊販売部数 約125万人 電子版有料会員数 約106万人 デジタル購読数 約120万人 日経電子版 有料会員数 年数 2010 2017 2025 約10万人 約50万人 約106万人 朝刊: 2025年12月時点 その他: 2026年1月時点
11. ハッシュタグ #nikkei_tech_talk 報道機関の事業継続性に求められるシステム • 信頼性・可用性の高い基盤が必要 11 日経電子版を稼働し続けるために必要なこと
12. SREチームが提供する共通基盤の概要 12
13. ハッシュタグ #nikkei_tech_talk 共通アプリケーション基盤 Vessel について • SREチームが管理/運用する信頼性の高い基盤 ◦ 基盤としてサービスの信頼性を担保 ▪ 開発チームが意識せずとも高い信頼性を実現 13 Vessel アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ 開発チーム
14. ハッシュタグ #nikkei_tech_talk Vesselの信頼性の担保 • 通常時から高い信頼性の実行環境を提供 ◦ 基盤のアップデート作業でも、ダウンタイムを発生させない ▪ →東京リージョンに2クラスタ構築 • 大規模災害時のリージョン障害でも事業継続性を考慮 ◦ 基盤のサービス継続手順を確立 14
15. ハッシュタグ #nikkei_tech_talk SREチームが提供する共通基盤の概要 15
16. ハッシュタグ #nikkei_tech_talk Vesselの詳細 • 日経の次世代アプリケーション基盤「Vessel」の紹介 • GKEベースのアプリケーション基盤 Vessel での障害訓練の取り組み 16
17. 従来の大規模災害時のサービス継続手順とその課題 17
18. ハッシュタグ #nikkei_tech_talk 【現在】　障害時＝リージョン切り替え TOKYO US Cluster-1 Cluster-2 GCLB Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB Cluster-BCP ①障害発生 ②USリージョンに クラスタ構築 ③トラフィック 切り替え 18 TOKYO US TOKYO
19. ハッシュタグ #nikkei_tech_talk 【現在】　障害時＝リージョン切り替え TOKYO US Cluster-1 Cluster-2 GCLB Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB Cluster-BCP ①障害発生 ②USリージョンに クラスタ構築 ③トラフィック 切り替え 19 TOKYO US TOKYO
20. ハッシュタグ #nikkei_tech_talk クラスタ構築フェーズでの作業内容 • 全リソースを一から新規構築 GKE クラスタ・ノード、Pod作成に該当 • 基盤コンポーネントのセットアップ ◦ IstioやArgoCDを手作業でインストールする • 60 を超えるアプリケーションの起動確認 20 調査 コンポーネントのセット アップ アプリの起動確認 ①障害の検知&調査 ②USリージョンにクラスタ構築 ③トラフィック切り替え クラスタ作成 GCLB切り替え
21. ハッシュタグ #nikkei_tech_talk 従来のサービス継続手順の課題 • 全体作業の完了に2時間 • クラスタ構築完了に1時間22分 ※2025年8月に検証した結果 21 1時間22分 2時間 調査 コンポーネントのセット アップ アプリの起動確認 クラスタ作成 GCLB切り替え
22. ハッシュタグ #nikkei_tech_talk ダウンタイム 2時間弱 発生するかもしれない基盤って、 信頼性低くね？ 22 構築フェーズで 改善が必要じゃん …
23. 改善アプローチとその効果 23
24. ハッシュタグ #nikkei_tech_talk Cluster-1 Cluster-2 GCLB 24 Cluster-1 Cluster-2 GCLB 変更前 変更後 東京-大阪マルチリージョンアクティブ構成 TOKYO TOKYO OSAKA
25. ハッシュタグ #nikkei_tech_talk Cluster-1 Cluster-2 GCLB Cluster-1 Cluster-2 GCLB Cluster-1 Cluster-2 GCLB ①通常時の運用 ②東京で障害発生&検知 ③東京を切り離す 25 東京-大阪マルチリージョンアクティブ構成の 　　　　　　　　　　　　　　　　　　　　　　　サービス継続手順 TOKYO OSAKA TOKYO OSAKA TOKYO OSAKA
26. ハッシュタグ #nikkei_tech_talk • ダウンタイムがほぼ発生しない • 作業工数を大幅に削減可能 ◦ クラスタの構築→トラフィック切り替えのみ 26 削減 調査 コンポーネントのセット アップ アプリの起動確認 クラスタ作成 GCLB切り替え 東京-大阪マルチリージョンアクティブ構成の利点 調査 GCLB切り替え
27. ハッシュタグ #nikkei_tech_talk 東京-大阪マルチリージョン構成の課題 • 通常時にアクセスの偏りが発生 ◦ 適切なアプリケーションのキャパシティプランニングが必要 27 Cluster-1 Cluster-2 GCLB リソース不足により リクエストを捌けない 余剰リソースが発生し 無駄なコストが発生 TOKYO OSAKA
28. ハッシュタグ #nikkei_tech_talk • Vesselは全クラスタが同じ設定で稼働する設計 • クラスタごとに割り当てリソースを調整できない • 復旧時間を短縮するための構成変更が難しい ◦ クラスタの設計自体、大幅に変更する必要がある →このアプローチは、断念 28 キャパシティプランニングが困難
29. ハッシュタグ #nikkei_tech_talk BCP クラスタ常時稼働 29 Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB 変更前 変更後 TOKYO TOKYO US
30. ハッシュタグ #nikkei_tech_talk BCP クラスタ常時稼働の課題 • 常時稼働のクラスタが1つ増加 • コストが 1.5 倍になり、許容できない ※BCPクラスタは、復旧時に構築するクラスタである 30 ¥ cost Cluster-BCP Cluster-1 Cluster-2 Cluster-1 Cluster-2 TOKYO TOKYO US
31. ハッシュタグ #nikkei_tech_talk ゼロスケール構成 • GKE クラスタは構築し、ノードとPodは起動していない状態 • 通常時はコンピュート料金が発生しない 31 クラスタ ノード ノード Pod Pod Pod Pod … … ¥ cost
32. ハッシュタグ #nikkei_tech_talk ゼロスケール構成におけるサービス継続手順 Cluster-1 Cluster-2 GCLB ①通常時の運用 (USに常時クラスタ起動) ②東京で障害発生&検知 ④トラフィック変更 32 Cluster-BCP Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB Cluster-BCP ③ノード(Pod)を起動 ゼロスケール ゼロスケール US TOKYO US TOKYO US TOKYO US TOKYO
33. ハッシュタグ #nikkei_tech_talk ゼロスケール構成の作業内容 33 • GitHub Actionsでノードの起動(Podの起動) ◦ 従来は、手作業で実施 クラスタ(USリージョン) ノード ノード Pod Pod Pod Pod … … 起動 ②災害時、ノードを起動 クラスタ(USリージョン) ノード ノード Pod Pod Pod Pod … … ①通常時、ノードを起動しない
34. ハッシュタグ #nikkei_tech_talk ゼロスケール構成の利点 • 作業工数を削減可能 ◦ クラスタセットアップが完了した状態で作業開始 ▪ IstioやArgoCDがインストール済み ◦ ノードとPodの起動のみでサービスが復旧 • 現在のクラスタ設計を変更する必要がない →復旧時間の短縮を迅速に実現可能 34 クラスタ作成 コンポーネントの セットアップ アプリの起動確認 アプリの起動確認 ノード起動
35. ハッシュタグ #nikkei_tech_talk 従来の手順との比較 35 旧復旧手順 ゼロスケール構成 USクラスタ 災害時のみ起動 常時起動 クラスタセットアップ 手作業で実施 完了済み 復旧方法 クラスタを1から構築 ノード(Pod)を起動のみ 作業内容 手作業でクラスタ構築 GHAで自動的に起動
36. ハッシュタグ #nikkei_tech_talk 時間短縮 • 1時間22分 → 33分 ◦ クラスタ構築完了までの作業時間短縮 • 自動化実現 ◦ 作業者のスキルに左右されない 36 クラスタ作成 コンポーネントの セットアップ アプリの起動確認 ノード起動 1時間22分 33分 アプリの起動確認
37. まとめ・今後の展望 37
38. ハッシュタグ #nikkei_tech_talk まとめ • 共通アプリケーション基盤を提供 • 大規模災害時の基盤復旧には、2時間を要する • 基盤をゼロスケール構成に変更し、解消 ◦ USにクラスタを常時起動 ◦ ノード数をゼロにスケール • 結果：約1時間の復旧時間短縮に成功 38
39. ハッシュタグ #nikkei_tech_talk 今後の展望 • さらなるダウンタイムの削減を継続的に検討 ◦ 東京-大阪構成の検討継続 ▪ ダウンタイムの発生をほぼゼロに抑えることが可能 ▪ アクセス分散の偏りに対応可能な設計を考慮 • キャパシティプランニング可能な設計 39