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

by 日本経済新聞社エンジニア採用事務局

Embed

Start on current slide

Slide 1

Slide 1 text

2026/5/28 日本経済新聞社　SREチーム石上椋一大規模災害時でも高い信頼性を維持するアプリケーション基盤の実現 NIKKEI TECH TALK #46 1

Slide 2

Slide 2 text

ハッシュタグ #nikkei_tech_talk 自己紹介 2 石上椋一(いしがみりょういち) 日本経済新聞社 2025年入社技術戦略ユニット SREチーム所属社内共通基盤・社内 SRE実践の推進

Slide 3

Slide 3 text

ハッシュタグ #nikkei_tech_talk 本日話すこと ● 報道機関に求められる事業継続性 ● 共通基盤の Vessel とは ● 大規模災害時のサービス継続手順と課題 ● 改善アプローチとその効果 ● まとめ・今後の展望 3

Slide 4

Slide 4 text

ハッシュタグ #nikkei_tech_talk 4 各チームに便利なシステム基盤を提供する SREの実践を助ける指南書や確認ポイントを提供するプラットフォーム SRE イネーブルメント SRE 日経 SRE ー２つの活動分野 Vessel:アプリケーション基盤 Cage: 負荷試験の基盤 Titan: 可観測性の基盤 SREガイドライン SREトレイルマップ SREクライテリア

Slide 5

Slide 5 text

ハッシュタグ #nikkei_tech_talk 5 各チームに便利なシステム基盤を提供するプラットフォーム SRE 日経 SRE ー２つの活動分野 Vessel:アプリケーション基盤 Titan: 可観測性の基盤 Cage: 負荷試験の基盤 Vessel(ベッセル)とは ● 自社開発の共通基盤 ● アプリケーションコンテナを載せている ○ 日経電子版サービス ● コンテナ船(container vessel)

Slide 6

Slide 6 text

報道機関の事業継続性に求められるシステム 6

Slide 7

Slide 7 text

ハッシュタグ #nikkei_tech_talk 報道機関として ● 様々な媒体で情報を発信 ○ 本紙朝刊/夕刊、日経MJ ○ 電子版アプリ/Webサイト/メール/Push通知/SNS ● いついかなる時でも情報を提供する役目がある ○ 正確で中立な情報を発信 7

Slide 8

Slide 8 text

ハッシュタグ #nikkei_tech_talk 「有事」の時こそ、確実に届ける 8 皆さんもニュースなどで確認したのでは？

Slide 9

Slide 9 text

ハッシュタグ #nikkei_tech_talk 新聞印刷のトラブル回避例 ● 機械などが故障した際、他の自社工場で印刷/輸送を実現 9 自社工場A 自社工場B 紙面データ送信故障連絡本社

Slide 10

Slide 10 text

ハッシュタグ #nikkei_tech_talk 日本経済新聞の購読者 10 媒体購読数購読数合計約231万人朝刊販売部数約125万人電子版有料会員数約106万人デジタル購読数約120万人日経電子版有料会員数年数 2010 2017 2025 約10万人約50万人約106万人朝刊: 2025年12月時点その他: 2026年1月時点

Slide 11

Slide 11 text

ハッシュタグ #nikkei_tech_talk 報道機関の事業継続性に求められるシステム ● 信頼性・可用性の高い基盤が必要 11 日経電子版を稼働し続けるために必要なこと

Slide 12

Slide 12 text

SREチームが提供する共通基盤の概要 12

Slide 13

Slide 13 text

ハッシュタグ #nikkei_tech_talk 共通アプリケーション基盤 Vessel について ● SREチームが管理/運用する信頼性の高い基盤 ○ 基盤としてサービスの信頼性を担保 ■ 開発チームが意識せずとも高い信頼性を実現 13 Vessel アプリコンテナアプリコンテナアプリコンテナアプリコンテナアプリコンテナ開発チーム

Slide 14

Slide 14 text

ハッシュタグ #nikkei_tech_talk Vesselの信頼性の担保 ● 通常時から高い信頼性の実行環境を提供 ○ 基盤のアップデート作業でも、ダウンタイムを発生させない ■ →東京リージョンに2クラスタ構築 ● 大規模災害時のリージョン障害でも事業継続性を考慮 ○ 基盤のサービス継続手順を確立 14

Slide 15

Slide 15 text

ハッシュタグ #nikkei_tech_talk SREチームが提供する共通基盤の概要 15

Slide 16

Slide 16 text

ハッシュタグ #nikkei_tech_talk Vesselの詳細 ● 日経の次世代アプリケーション基盤「Vessel」の紹介 ● GKEベースのアプリケーション基盤 Vessel での障害訓練の取り組み 16

Slide 17

Slide 17 text

従来の大規模災害時のサービス継続手順とその課題 17

Slide 18

Slide 18 text

ハッシュタグ #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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

ハッシュタグ #nikkei_tech_talk クラスタ構築フェーズでの作業内容 ● 全リソースを一から新規構築 GKE クラスタ・ノード、Pod作成に該当 ● 基盤コンポーネントのセットアップ ○ IstioやArgoCDを手作業でインストールする ● 60 を超えるアプリケーションの起動確認 20 調査コンポーネントのセットアップアプリの起動確認 ①障害の検知&調査 ②USリージョンにクラスタ構築 ③トラフィック切り替えクラスタ作成 GCLB切り替え

Slide 21

Slide 21 text

ハッシュタグ #nikkei_tech_talk 従来のサービス継続手順の課題 ● 全体作業の完了に2時間 ● クラスタ構築完了に1時間22分 ※2025年8月に検証した結果 21 1時間22分 2時間調査コンポーネントのセットアップアプリの起動確認クラスタ作成 GCLB切り替え

Slide 22

Slide 22 text

ハッシュタグ #nikkei_tech_talk ダウンタイム 2時間弱発生するかもしれない基盤って、信頼性低くね？ 22 構築フェーズで改善が必要じゃん …

Slide 23

Slide 23 text

改善アプローチとその効果 23

Slide 24

Slide 24 text

ハッシュタグ #nikkei_tech_talk Cluster-1 Cluster-2 GCLB 24 Cluster-1 Cluster-2 GCLB 変更前変更後東京-大阪マルチリージョンアクティブ構成 TOKYO TOKYO OSAKA

Slide 25

Slide 25 text

ハッシュタグ #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

Slide 26

Slide 26 text

ハッシュタグ #nikkei_tech_talk ● ダウンタイムがほぼ発生しない ● 作業工数を大幅に削減可能 ○ クラスタの構築→トラフィック切り替えのみ 26 削減調査コンポーネントのセットアップアプリの起動確認クラスタ作成 GCLB切り替え東京-大阪マルチリージョンアクティブ構成の利点調査 GCLB切り替え

Slide 27

Slide 27 text

ハッシュタグ #nikkei_tech_talk 東京-大阪マルチリージョン構成の課題 ● 通常時にアクセスの偏りが発生 ○ 適切なアプリケーションのキャパシティプランニングが必要 27 Cluster-1 Cluster-2 GCLB リソース不足によりリクエストを捌けない余剰リソースが発生し無駄なコストが発生 TOKYO OSAKA

Slide 28

Slide 28 text

ハッシュタグ #nikkei_tech_talk ● Vesselは全クラスタが同じ設定で稼働する設計 ● クラスタごとに割り当てリソースを調整できない ● 復旧時間を短縮するための構成変更が難しい ○ クラスタの設計自体、大幅に変更する必要がある →このアプローチは、断念 28 キャパシティプランニングが困難

Slide 29

Slide 29 text

ハッシュタグ #nikkei_tech_talk BCP クラスタ常時稼働 29 Cluster-1 Cluster-2 GCLB Cluster-BCP Cluster-1 Cluster-2 GCLB 変更前変更後 TOKYO TOKYO US

Slide 30

Slide 30 text

ハッシュタグ #nikkei_tech_talk BCP クラスタ常時稼働の課題 ● 常時稼働のクラスタが1つ増加 ● コストが 1.5 倍になり、許容できない ※BCPクラスタは、復旧時に構築するクラスタである 30 ¥ cost Cluster-BCP Cluster-1 Cluster-2 Cluster-1 Cluster-2 TOKYO TOKYO US

Slide 31

Slide 31 text

ハッシュタグ #nikkei_tech_talk ゼロスケール構成 ● GKE クラスタは構築し、ノードとPodは起動していない状態 ● 通常時はコンピュート料金が発生しない 31 クラスタノードノード Pod Pod Pod Pod … … ¥ cost

Slide 32

Slide 32 text

ハッシュタグ #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

Slide 33

Slide 33 text

ハッシュタグ #nikkei_tech_talk ゼロスケール構成の作業内容 33 ● GitHub Actionsでノードの起動(Podの起動) ○ 従来は、手作業で実施クラスタ(USリージョン) ノードノード Pod Pod Pod Pod … … 起動 ②災害時、ノードを起動クラスタ(USリージョン) ノードノード Pod Pod Pod Pod … … ①通常時、ノードを起動しない

Slide 34

Slide 34 text

ハッシュタグ #nikkei_tech_talk ゼロスケール構成の利点 ● 作業工数を削減可能 ○ クラスタセットアップが完了した状態で作業開始 ■ IstioやArgoCDがインストール済み ○ ノードとPodの起動のみでサービスが復旧 ● 現在のクラスタ設計を変更する必要がない →復旧時間の短縮を迅速に実現可能 34 クラスタ作成コンポーネントのセットアップアプリの起動確認アプリの起動確認ノード起動

Slide 35

Slide 35 text

ハッシュタグ #nikkei_tech_talk 従来の手順との比較 35 旧復旧手順ゼロスケール構成 USクラスタ災害時のみ起動常時起動クラスタセットアップ手作業で実施完了済み復旧方法クラスタを1から構築ノード(Pod)を起動のみ作業内容手作業でクラスタ構築 GHAで自動的に起動

Slide 36

Slide 36 text

ハッシュタグ #nikkei_tech_talk 時間短縮 ● 1時間22分 → 33分 ○ クラスタ構築完了までの作業時間短縮 ● 自動化実現 ○ 作業者のスキルに左右されない 36 クラスタ作成コンポーネントのセットアップアプリの起動確認ノード起動 1時間22分 33分アプリの起動確認

Slide 37

Slide 37 text

まとめ・今後の展望 37

Slide 38

Slide 38 text

ハッシュタグ #nikkei_tech_talk まとめ ● 共通アプリケーション基盤を提供 ● 大規模災害時の基盤復旧には、2時間を要する ● 基盤をゼロスケール構成に変更し、解消 ○ USにクラスタを常時起動 ○ ノード数をゼロにスケール ● 結果：約1時間の復旧時間短縮に成功 38

Slide 39

Slide 39 text

ハッシュタグ #nikkei_tech_talk 今後の展望 ● さらなるダウンタイムの削減を継続的に検討 ○ 東京-大阪構成の検討継続 ■ ダウンタイムの発生をほぼゼロに抑えることが可能 ■ アクセス分散の偏りに対応可能な設計を考慮 ● キャパシティプランニング可能な設計 39