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

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

Transcript

1. 日経電子版SREチーム立ち上げ中 日本経済新聞社 髙安 伯武 SRE NEXT 2020 IN TOKYO #srenextA #srenext 1
2. • 名前 ◦ 髙安 伯武(Takayasu Osamu) ◦ @osamunmun • 所属 ◦ 日本経済新聞社 デジタル編成ユニット • やっていること ◦ 日経電子版の開発 ◦ 最近は、技術戦略、エンジニア組織作りなどがメイン about me 2
3. • 2010/3月サービスローンチ • 有料ユーザー60万人以上 • 月4,277円のサブスクリプションモデル • 毎日約1,000記事を配信 • API 2,000req/sec 日経電子版 3
4. アジェンダ 1. SRE立ち上げ前の状況(2018年) 2. 何が課題だったのか 3. SREチーム結成 4. できなかったこと/できたこと 5. 今後の取り組み 4
5. 1. SRE立ち上げ前の状況(2018年) 5
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
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
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
9. チーム体制 概略図 各開発チームの役割 Infra ServiceA Prometheus Grafana ServiceB Deploy Pipeline Infra ServiceC ES Kibana Logging Monitoring Availability... Deploy Pipeline Logging Monitoring Availability... • 各チームがそれぞれインフ ラ〜アプリ、機能開発〜運用 を頑張っている • 内製/外注開発チームがある ・・・ 9
10. Takeaway • 内製開発チーム、外注開発チームが混在する • 各チームが縦割りで閉じて各システムを開発、運用する • モダンなシステム、レガシーなシステムが混在する こういう組織でどうやって横断的にSREを実践していくのか 10
11. 2. 何が課題だったのか 11
12. 何が課題だったのか a. サービスレベルがバラバラ b. システムの安定性が後回しにされがち c. 事業成長の足枷になるリスク 12
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
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
15. b. システムの安定性が後回しにされがち • 機能開発〜運用を一つのチームが担当 • 事業への貢献度が見えやすい機能開発が 優先されがち。安定性の向上へのタスクの 優先度が上がらない 安定性向上 機能開発 事業成長 ユーザー増/利益増 15
16. • 電子版の進化を加速したい • 電子版以外のデジタルサービスもどんどんチャレンジしたい c. 事業成長の足枷になるリスク • 技術スタックがバラバラ、属人化が進んでいて柔軟にアサインできない • 新規にサービスを立ち上げるたびにシステムを0から検討しないといけない 16
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
18. 3. SREチーム結成 18
19. SREチーム SREチーム APIチーム モバイルWeb チーム データチーム 兼務 • 責務 ◦ 電子版全体の「安定性」と「アーキテ クチャ」に責任を持つ • 特徴 ◦ 既存システムのオペレーション業務を 持ってない ◦ 全員SRE未経験者 電子版に関わるエンジニアは 約50名 ・・・ 19
20. 4. できなかったこと/できたこと 20
21. できなかったこと 21
22. SLI/SLOの設定 22
23. 最初に何から手を付けるか Objective: 電子版の可用性と信頼性がコントラールブルになっている! • まずは、今の電子版の可用性、信頼性を把握しないと始まらない • SLI/SLOの設定と計測から着手 23
24. SLI/SLOの設定にチャレンジするものの... • すべてのAPIにSLI/SLOを！ ◦ internalなapiも含めるとAPIたくさん... ◦ pathによってSLO変わってくるのでは...? ◦ アクセスログの保管場所が散らばってるシステムも... ▪ システム自体に手を入れないと... • リクエストベースでのSLI/SLOへの固執 ◦ 細かく設定しないとサービスレベルを測れないという思い込み ◦ 個別に設定しようとして途方に暮れる 24
25. SLI/SLOの設定にチャレンジするものの... • やっていることが本当に意味のあることか疑い始める ◦ モチベーションの低下 • 度重なる障害対応 ◦ こっちを先になんとかしないと... • 具体的な成果がイメージできる課題の誘惑 ◦ デプロイ速度遅い問題 ◦ アーキテクチャ刷新 25
26. SLI/SLOから逃避した... 26
27. SLI/SLOの設定 反省 • もっとシンプルに考えればよかったのでは ◦ 時間ベースの稼働率でスタートすれば良かった ▪ 各リクエストベースよりは測りやすい ◦ 設定した指標で漏れがあればSLIを追加 ◦ より信頼性の解像度を上げる必要が出てきてから細分化 27
28. できたこと 28
29. 組織内での啓蒙活動 29
30. SREチーム発足時の組織的状況 SREチーム 内製開発チーム ・・・ 非エンジニアのマネージャー レガシーシステムのチーム 非エンジニアのメンバー • 困ってない。あんまり関心ない • 一部メンバーはSREチームにコ ミット • 楽になるのか？ • 様子見 • SREのことを知らない • 解決しようとしている課題 もよくわからない • SREのことを知らない • 解決しようとしている課題 もよくわからない 30
31. SREチーム発足後 内製開発チーム ・・・ 非エンジニアのマネージャー レガシーシステムのチーム 非エンジニアのメンバー 障害頻発 ペイン ペイン SREチーム 啓蒙 啓蒙 障害対応、改善をサポート リアーキテクチャ、改善に 一緒に取り組む 31
32. 現在のSREチームの立ち位置 内製開発チーム ・・・ 非エンジニアのマネージャー レガシーシステムのチーム 非エンジニアのメンバー SREチーム 期待 理解 リアーキテクチャの相談、協働 相談、依頼 • SREのことを知らない • 解決しようとしている課題 もよくわからない • 解決しようとしている課題と 重要性を理解 32
33. 障害対応プロセスの改善 33
34. 障害対応プロセスの改善 • 障害対応時のコミュニケーション ◦ Slackのopenなチャンネルでやりとり ◦ リモートからSlackで連携しながら障害対応する訓練の実施 • 各チーム内に閉じていた障害のふりかえりへの参加 ◦ 担当チームとポストモーテムを書く ◦ 改善アクションを協働 • 障害報告フォーマットの統一化、集約 34
35. 電子版全体のアーキテクチャ検討、改善 35
36. • Mobile WebのBFFをリアーキテクチャ ◦ デプロイ速度と運用の複雑さが課題になっていた • 固有の課題の解決だけではなく他システムにも適用できるような リファレンスアーキテクチャを念頭において設計 • アーキテクチャの統一のための技術投資的な側面 電子版全体のアーキテクチャ検討、改善 AWS ElasticBeanstalk Google Kubernetes Engine 36
37. 1年やってみて... 37
38. コレはSREなのだろうか？ 38
39. システム横断でDevOpsチームとして動けたが... • 結局SLI/SLOを運用できてない ◦ 信頼性を計測できてない ◦ 計測できていないから制御できているかもわからない • 啓蒙活動と各システムの改善を通して、組織内でのSREチームのプレゼンスは上 がってきた 39
40. 5. 今後の取り組み 40
41. もう一度SLI/SLOに 向き合おう 41
42. 今後の取り組み • SLI/SLOに再チャレンジ ◦ 前回の反省をもとに稼働率を使うところから ◦ チームのプレゼンスは上がってきた ▪ 各チームと協力して動けるようになってきた ◦ レガシーシステムがクラウド移行するタイミング 42
43. 日経はエンジニアの仲間を募集中 • SREチームは中途/フリーランスどち らも募集中 • エンジニアが1名ジョインすることの 効果がとても大きい状況 • Techブログ ◦ https://hack.nikkei.com/ • エンジニア向けTwitter ◦ @nikkeideveloper ◦ DMお待ちしてます • オフィス見学歓迎 43