$30 off During Our Annual Pro Sale. View Details »

日経電子版SREチーム立ち上げ中

osamunmun
January 25, 2020

 日経電子版SREチーム立ち上げ中

日経電子版を支えるSREチームが2019/1に発足しました。メディアとして安定したサービスを実現し、いつでもニュースをユーザーに届けられるようにすることは重要だと考えています。しかし、開発チームの体制は電子版を構成するシステムごとに分かれており、電子版全体の可用性、信頼性、アーキテクチャに責任を負うチームはありませんでした。また、各開発チームは機能開発と可用性、信頼性の担保の両方の責務を負っていて、必ずしも安定稼働上の課題に注力できない環境にあります。この課題を解決するべく、SREチームを発足しました。まだ、道半ばではありますがこれまでの取組を共有します。

osamunmun

January 25, 2020
Tweet

More Decks by osamunmun

Other Decks in Technology

Transcript

  1. 日経電子版SREチーム立ち上げ中
    日本経済新聞社 髙安 伯武
    SRE NEXT 2020 IN TOKYO #srenextA #srenext
    1

    View Slide

  2. ● 名前
    ○ 髙安 伯武(Takayasu Osamu)
    ○ @osamunmun
    ● 所属
    ○ 日本経済新聞社 デジタル編成ユニット
    ● やっていること
    ○ 日経電子版の開発
    ○ 最近は、技術戦略、エンジニア組織作りなどがメイン
    about me
    2

    View Slide

  3. • 2010/3月サービスローンチ
    • 有料ユーザー60万人以上
    • 月4,277円のサブスクリプションモデル
    • 毎日約1,000記事を配信
    • API 2,000req/sec
    日経電子版
    3

    View Slide

  4. アジェンダ
    1. SRE立ち上げ前の状況(2018年)
    2. 何が課題だったのか
    3. SREチーム結成
    4. できなかったこと/できたこと
    5. 今後の取り組み
    4

    View Slide

  5. 1. SRE立ち上げ前の状況(2018年)
    5

    View Slide

  6. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    日経電子版システム概要図
    創刊時からあるシステム
    比較的新しいシステム
    6

    View Slide

  7. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    日経電子版システム概要図
    創刊時からあるシステム
    比較的新しいシステム
    AWS
    オンプレ
    7

    View Slide

  8. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    開発チームの構成
    創刊時からあるシステム
    比較的新しいシステム
    チーム
    8

    View Slide

  9. チーム体制 概略図
    各開発チームの役割
    Infra
    ServiceA
    Prometheus Grafana
    ServiceB
    Deploy
    Pipeline
    Infra
    ServiceC
    ES Kibana
    Logging
    Monitoring
    Availability...
    Deploy
    Pipeline
    Logging
    Monitoring
    Availability...
    ● 各チームがそれぞれインフ
    ラ〜アプリ、機能開発〜運用
    を頑張っている
    ● 内製/外注開発チームがある
    ・・・
    9

    View Slide

  10. Takeaway
    ● 内製開発チーム、外注開発チームが混在する
    ● 各チームが縦割りで閉じて各システムを開発、運用する
    ● モダンなシステム、レガシーなシステムが混在する
    こういう組織でどうやって横断的にSREを実践していくのか
    10

    View Slide

  11. 2. 何が課題だったのか
    11

    View Slide

  12. 何が課題だったのか
    a. サービスレベルがバラバラ
    b. システムの安定性が後回しにされがち
    c. 事業成長の足枷になるリスク
    12

    View Slide

  13. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    a.サービスレベルがバラバラ
    創刊時からあるシステム
    比較的新しいシステム
    ● 5人で運用
    ● 障害を5分以
    内に検知
    ● 2人で運用
    ● 障害検知
    に30分
    13

    View Slide

  14. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    a.サービスレベルがバラバラ
    創刊時からあるシステム
    比較的新しいシステム
    ● 5人で運用
    ● 障害を5分以
    内に検知
    ● 2人で運用
    ● 障害検知
    に30分
    そもそも電子版全体のサービスレ
    ベルが
    ● 定義されていない
    ● 計測されてない
    ● 目標がない
    14

    View Slide

  15. b. システムの安定性が後回しにされがち
    ● 機能開発〜運用を一つのチームが担当
    ● 事業への貢献度が見えやすい機能開発が
    優先されがち。安定性の向上へのタスクの
    優先度が上がらない
    安定性向上
    機能開発
    事業成長
    ユーザー増/利益増
    15

    View Slide

  16. ● 電子版の進化を加速したい
    ● 電子版以外のデジタルサービスもどんどんチャレンジしたい
    c. 事業成長の足枷になるリスク
    ● 技術スタックがバラバラ、属人化が進んでいて柔軟にアサインできない
    ● 新規にサービスを立ち上げるたびにシステムを0から検討しないといけない
    16

    View Slide

  17. チーム体制 概略図
    BFF for Mobile Web
    (r.nikkei.com)
    BFF for Native App
    (iOS/Android)
    PC System
    (www.nikkei.com)
    APIGateway
    NikkeiID
    Billing System
    APIs(MicroServices)
    search paper
    image
    save
    articles
    …..
    Data Platform
    CMS for Digital Mail System
    Ads System
    Fastly
    電子版全体の安定性/アーキテクチャを誰が考える?
    創刊時からあるシステム
    比較的新しいシステム
    17

    View Slide

  18. 3. SREチーム結成
    18

    View Slide

  19. SREチーム
    SREチーム
    APIチーム
    モバイルWeb
    チーム
    データチーム
    兼務
    ● 責務
    ○ 電子版全体の「安定性」と「アーキテ
    クチャ」に責任を持つ
    ● 特徴
    ○ 既存システムのオペレーション業務を
    持ってない
    ○ 全員SRE未経験者
    電子版に関わるエンジニアは
    約50名
    ・・・
    19

    View Slide

  20. 4. できなかったこと/できたこと
    20

    View Slide

  21. できなかったこと
    21

    View Slide

  22. SLI/SLOの設定
    22

    View Slide

  23. 最初に何から手を付けるか
    Objective: 電子版の可用性と信頼性がコントラールブルになっている!
    ● まずは、今の電子版の可用性、信頼性を把握しないと始まらない
    ● SLI/SLOの設定と計測から着手
    23

    View Slide

  24. SLI/SLOの設定にチャレンジするものの...
    ● すべてのAPIにSLI/SLOを!
    ○ internalなapiも含めるとAPIたくさん...
    ○ pathによってSLO変わってくるのでは...?
    ○ アクセスログの保管場所が散らばってるシステムも...
    ■ システム自体に手を入れないと...
    ● リクエストベースでのSLI/SLOへの固執
    ○ 細かく設定しないとサービスレベルを測れないという思い込み
    ○ 個別に設定しようとして途方に暮れる
    24

    View Slide

  25. SLI/SLOの設定にチャレンジするものの...
    ● やっていることが本当に意味のあることか疑い始める
    ○ モチベーションの低下
    ● 度重なる障害対応
    ○ こっちを先になんとかしないと...
    ● 具体的な成果がイメージできる課題の誘惑
    ○ デプロイ速度遅い問題
    ○ アーキテクチャ刷新
    25

    View Slide

  26. SLI/SLOから逃避した...
    26

    View Slide

  27. SLI/SLOの設定 反省
    ● もっとシンプルに考えればよかったのでは
    ○ 時間ベースの稼働率でスタートすれば良かった
    ■ 各リクエストベースよりは測りやすい
    ○ 設定した指標で漏れがあればSLIを追加
    ○ より信頼性の解像度を上げる必要が出てきてから細分化
    27

    View Slide

  28. できたこと
    28

    View Slide

  29. 組織内での啓蒙活動
    29

    View Slide

  30. SREチーム発足時の組織的状況
    SREチーム
    内製開発チーム
    ・・・
    非エンジニアのマネージャー
    レガシーシステムのチーム
    非エンジニアのメンバー
    ● 困ってない。あんまり関心ない
    ● 一部メンバーはSREチームにコ
    ミット
    ● 楽になるのか?
    ● 様子見
    ● SREのことを知らない
    ● 解決しようとしている課題
    もよくわからない
    ● SREのことを知らない
    ● 解決しようとしている課題
    もよくわからない
    30

    View Slide

  31. SREチーム発足後
    内製開発チーム
    ・・・
    非エンジニアのマネージャー
    レガシーシステムのチーム
    非エンジニアのメンバー
    障害頻発
    ペイン
    ペイン
    SREチーム
    啓蒙
    啓蒙
    障害対応、改善をサポート
    リアーキテクチャ、改善に
    一緒に取り組む
    31

    View Slide

  32. 現在のSREチームの立ち位置
    内製開発チーム
    ・・・
    非エンジニアのマネージャー
    レガシーシステムのチーム
    非エンジニアのメンバー
    SREチーム
    期待
    理解
    リアーキテクチャの相談、協働
    相談、依頼
    ● SREのことを知らない
    ● 解決しようとしている課題
    もよくわからない
    ● 解決しようとしている課題と
    重要性を理解
    32

    View Slide

  33. 障害対応プロセスの改善
    33

    View Slide

  34. 障害対応プロセスの改善
    ● 障害対応時のコミュニケーション
    ○ Slackのopenなチャンネルでやりとり
    ○ リモートからSlackで連携しながら障害対応する訓練の実施
    ● 各チーム内に閉じていた障害のふりかえりへの参加
    ○ 担当チームとポストモーテムを書く
    ○ 改善アクションを協働
    ● 障害報告フォーマットの統一化、集約
    34

    View Slide

  35. 電子版全体のアーキテクチャ検討、改善
    35

    View Slide

  36. ● Mobile WebのBFFをリアーキテクチャ
    ○ デプロイ速度と運用の複雑さが課題になっていた
    ● 固有の課題の解決だけではなく他システムにも適用できるような
    リファレンスアーキテクチャを念頭において設計
    ● アーキテクチャの統一のための技術投資的な側面
    電子版全体のアーキテクチャ検討、改善
    AWS ElasticBeanstalk Google Kubernetes Engine
    36

    View Slide

  37. 1年やってみて...
    37

    View Slide

  38. コレはSREなのだろうか?
    38

    View Slide

  39. システム横断でDevOpsチームとして動けたが...
    ● 結局SLI/SLOを運用できてない
    ○ 信頼性を計測できてない
    ○ 計測できていないから制御できているかもわからない
    ● 啓蒙活動と各システムの改善を通して、組織内でのSREチームのプレゼンスは上
    がってきた
    39

    View Slide

  40. 5. 今後の取り組み
    40

    View Slide

  41. もう一度SLI/SLOに
    向き合おう
    41

    View Slide

  42. 今後の取り組み
    ● SLI/SLOに再チャレンジ
    ○ 前回の反省をもとに稼働率を使うところから
    ○ チームのプレゼンスは上がってきた
    ■ 各チームと協力して動けるようになってきた
    ○ レガシーシステムがクラウド移行するタイミング
    42

    View Slide

  43. 日経はエンジニアの仲間を募集中
    ● SREチームは中途/フリーランスどち
    らも募集中
    ● エンジニアが1名ジョインすることの
    効果がとても大きい状況
    ● Techブログ
    ○ https://hack.nikkei.com/
    ● エンジニア向けTwitter
    ○ @nikkeideveloper
    ○ DMお待ちしてます
    ● オフィス見学歓迎
    43

    View Slide