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

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

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