NIKKEI Tech Talk #4 日経電子版BCP環境の紹介/nikkei-tech-talk-20230216-2

Nikkei Tech Talk #4 で発表した際の資料です
https://nikkei.connpass.com/event/272705/
セッション2　日経電子版BCP環境の紹介

Transcript

1. #nikkei_tech_talk
   NIKKEI Tech Talk #4
   日経電子版 BCP 環境の紹介
   株式会社 日本経済新聞社
   千葉 尚彬
   1
   

   View Slide

2. #nikkei_tech_talk
   アジェンダ
   1. 自己紹介
   2. 日経電子版 BCP 環境の紹介
   a. 取り組みの概要
   b. BCP 環境の構成
   c. データレプリケーション
   d. BCP 環境の維持・管理
   e. BCP 環境の検証
   3. まとめ
   2
   

   View Slide

3. #nikkei_tech_talk
   自己紹介
   - 名前: 千葉 尚彬（Chiba Naoaki）
   - 所属: サブスクリプション事業 デジタル編成ユニット
   API・バックエンドチーム
   - 経歴:
   - 以前は SIer に所属
   - 主にCloud Native と呼ばれる分野を担当
   - 本格的なバックエンド開発は日経に入社してから
   - 技術ブログ記事:
   - GKE + Locust で構築された社内負荷試験基盤「 Cage」を改善した話
   - 日経の次世代アプリケーション基盤「 Vessel」の紹介
   この猫は旅先にいた猫
   （飼っているとかではない）
   3
   

   View Slide

4. #nikkei_tech_talk
   取り組みの概要
   4
   

   View Slide

5. #nikkei_tech_talk
   社会インフラとしてのメディアたるには
   「緊急時」ほど情報ニーズは高い
   - 東日本大震災、新型コロナ、ウクライナ侵攻 ...
   「緊急時」において常に情報を提供できるか？
   　　- 東日本大震災のときは、多くの現地市町村が Web サイトがダウン [1]
   あらためて「緊急時」について考えると・・・
   - 世界情勢の変化、大災害、サイバー攻撃、 etc…
   ⇒ 緊急時というのが何か、いつ来るかやはりわからない
   [1] https://www.iij.ad.jp/interview/09.html 5
   しかし、社会インフラとしてあるためには、
   何かが起きても対処できるようになる必要がある
   

   View Slide

6. #nikkei_tech_talk
   BCP
   Business Continuety Planning（事業継続計画）
   - `企業が自然災害、大火災、テロ攻撃などの 緊急事態に遭遇した場合において、 ....、平常時に行うべ
   き活動や緊急時における事業継続のための方法、手段などを取り決めておく計画のことです。 `[2]
   - 一般の企業では操業回復を早め損害を最小化するために計画する
   - 日経のBCPとして日経電子版を緊急時にも
   稼働させることが必要
   - 日経電子版のBCPは弊チームのみによる
   ものではないが今回は弊チームが担当する
   範囲でのBCPについて紹介
   [2] https://www.chusho.meti.go.jp/bcp/contents/level_c/bcpgl_01_1.html 6
   

   View Slide

7. #nikkei_tech_talk
   BCP 環境の構成
   7
   

   View Slide

8. #nikkei_tech_talk
   現在の稼働環境及びBCPの前提・要件
   現在の稼働環境
   - 日経電子版は AWS の東京リージョンで稼働している
   - AWS東京リージョンはある程度離れた複数のDCで構成されている
   前提
   - （とは言っても）関東全域が被災し、東京リージョンも利用できない場合
   要件
   - 物理的に離れた場所（他リージョン）で稼働
   - 新規記事の入稿、既存記事も含めた記事表示（簡易電子版）を実現
   8
   

   View Slide

9. #nikkei_tech_talk
   BCPの対象コンポーネント
   9
   

   View Slide

10. #nikkei_tech_talk
    BCP対象コンポーネントの役割
    10
    コンポーネント 役割
    API Gateway 認証・認可、リクエスト受付、
    レート制限
    検索 API 検索用 Elasticsearch から記事を返却
    記事格納システム 記事管理システムから記事データを受
    け取り格納
    

    View Slide

11. #nikkei_tech_talk
    データのレプリケーション
    11
    

    View Slide

12. #nikkei_tech_talk
    レプリケーション - RDS
    Amazon Auroraを活用したレプリケーション機構を構築
    レプリケーション手法 メリット 採用したコンポーネント
    Aurora Global DB レプリケーション遅延が少ない
    AWS推奨
    記事 DB
    Cross Region Replication
    (CRR)
    小規模インスタンスタイプが使える
    (Aurora Global DB の場合、 db.r5 以上)
    API クライアント管理 DB
    12
    クライアント DB ではそこまでマシンパワーが必要ないので CRR を採用
    

    View Slide

13. #nikkei_tech_talk
    レプリケーション - RDS
    2 段階のフェイルオーバー
    - 障害発生直後では API クライアント管理 DB は昇格させない
    - 基本的に API クライアントの認証・認可ができればいいので、書き込める必要はない
    - 一度昇格させたあとに、元の構成に戻すのが結構大変
    - 障害が長期化し、BCP 環境でも新しく API クライアントを作成する必要が出てき
    て、初めて昇格させる
    13
    

    View Slide

14. #nikkei_tech_talk
    余談: Aurora Global DB の Headless 運用
    - Aurora Global DB の場合、セカンダリクラスターに一台もインスタンスが
    いなくてもデータがレプリケーションされる
    - この機能を活用することで、コストを抑えつつ可用性を向上
    - もちろん、インスタンスがある場合と比べると
    フェイルオーバー時の切り替え作業時間は伸びるので、
    その部分とのトレードオフ
    - 現状、開発環境の記事 DB でのみ Headless 構成を採用
    14
    画像: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-headless-secondary.png
    インスタンスが0
    

    View Slide

15. #nikkei_tech_talk
    レプリケーション - S3
    S3 Cross Region Replication を利用
    - 記事画像以外にも紙面画像や制御情報をレプリケーションしている
    15
    東京リージョン
    のバケット
    他リージョン
    のバケット
    レプリケーション
    制御情報
    紙面画像
    記事画像
    

    View Slide

16. #nikkei_tech_talk
    BCP 環境の維持・管理
    16
    

    View Slide

17. #nikkei_tech_talk
    アプリケーションデプロイの自動化
    東京リージョンと同じ様に、他リージョンでもアプリケーションを簡単に
    デプロイできる仕組みを構築
    - 既存のアプリケーションは GitHub Actions + 設定テンプレートで自動化済み
    - 設定テンプレート: Elastic Beanstalk 向けのよく設定される項目が記載済みのファイル
    - 他リージョン向けの設定テンプレートを新たに作成し自動化へ対応
    17
    

    View Slide

18. #nikkei_tech_talk
    BCP 対象コンポーネントの管理に Terraform を導入
    - BCP 対象のコンポーネントは古くから存在しており、IaC 化されていなかった
    - 一方で、BCP 対象コンポーネントのような重要なコンポーネントは
    IaC 管理したい
    - 変更内容のレビュー、ヒューマンエラー回避、共通の変更を全ての環境にもれなく反映
    ⇒ BCP 環境構築時に Terraform を導入
    18
    

    View Slide

19. #nikkei_tech_talk
    余談: 進む Terraform 活用
    - 東京リージョンにある BCP 対象コンポーネントも Terraform で
    管理されるようになってきた
    - Terraform Registry を介しておすすめの DB Parameter をデジタル部署
    全体に共有
    - BCP 環境構築時に既存の DB Parameter を改めて見直し Terraform Module 化
    - 現在では他案件、別 AWS アカウントでも活用中
    19
    

    View Slide

20. #nikkei_tech_talk
    BCP 環境の検証
    20
    

    View Slide

21. #nikkei_tech_talk
    障害訓練の実施
    - API・バックエンドチームだけではなく Web 、記事管理システム等
    関連システム全体で定期的に実施
    - フェイルオーバー -> 動作確認 -> フェイルバックの一連の作業を実施
    - 訓練後、チームレベル及び全体レベルで振り返りを実施
    21
    

    View Slide

22. #nikkei_tech_talk
    振り返りの内容及び改善活動
    切り戻し先環境の正常性確認のために、
    E2E テストを実行する手順があるが、
    もっと手軽に実行できるようにしたい
    チーム内でも手順書の理解にムラがある
    BCP 環境構築に携わっていない人が
    ちゃんと手順を実行できるか怪しい
    22
    - E2E テストを実行する GitHub Actions を
    作成
    - GitHub のページからクリックひとつで実行
    できるようになった
    - 共有会を開催し、手順書の内容を改めて
    インプット
    - 次の訓練では共有会参加者に主作業者
    として手順を実行してもらう
    

    View Slide

23. #nikkei_tech_talk
    まとめ
    23
    

    View Slide

24. #nikkei_tech_talk
    まとめ
    - 緊急時においても報道を続行する仕組みとして、API・バックエンドチーム
    における電子版の BCP 環境を紹介
    - AWS の機能を活用したデータのレプリケーション
    - Terraform を利用したコンポーネントの管理
    - また、障害訓練を繰り返し実施することで、BCP 環境及びその運用の改善
    を続けている
    24
    

    View Slide