A Complete Work of SmartNews's SRE

Transcript

1. 1.

   SRE大全 スマートニュース編 Nobutoshi Ogata @nobu666 2018/12/06

2. 2.

   Agenda • 自己紹介 • SmartNews の SRE • システムアーキテクチャ •

   運用 • 監視 • 障害対応 • 他チームとのコミュニケーション • 採用 • 今後
3. 3.

   Nobutoshi Ogata｜尾形暢俊 Engineering Manager, SRE and Corporate Engineering

4. 4.

   About me • メタラー • 巨大な猫を3匹飼育 • シガーと酒 • オンラインゲーム

   • 料理と包丁と靴磨き • 車 • カメラ • プロレス
5. 5.

   About me 〜2011: 受託開発 • 医療系のシステムを開発したり • 2005年くらいに MySQL でひぃひぃ

   • 2007年くらいに Hadoop でひぃひぃ • ついっぷるという Twitter クライアント • 企画・設計・開発・運用・プロジェクトマネジメント 全部
6. 6.

   About me 2011〜: グリー • インフラの基盤チーム • Web ベースのオンプレサーバ構築自動化シス テム

   (PHP/MySQL/ActiveMQ/Chef) • データ分析基盤構築 (DDD/Scala/Hive/Netty) • 全文検索サービス (Java/Solr) • SREっぽいなにか ◦ DB Schema, SQL Review / Architecture Review ◦ 障害対応
7. 7.

   About me 2014〜2015: ハッチ • Talentio • インフラ周り全部 (AWS) ◦

   ChatOps ◦ セキュリティ ◦ Spot Instance 自動入札システム • Crawler並列化 (PHP) 2015〜: スマートニュース
8. 8.

   最近の活動 • Think IT で PagerDuty の連載をちょろっと ◦ https://thinkit.co.jp/series/7350 •

   他社でインフラアドバイザー的なことをしたり • 来週 Slack のセミナーイベントに登壇したり
9. 9.

   SmartNews

10. 10.

    現在SmartNews 使ってる人?

11. 11.

    過去使ったけど やめてしまった人?

12. 12.

    Sma w • 世界中の良質な情報を必要な人に送り届ける / Delivering the world’s quality information

    to the people who need it
13. 13.

    None
14. 14.

    None
15. 15.

    None
16. 16.

    None
17. 17.

    余談ですが • 吉岡里帆さんのときも、今回の白石麻衣さんと 齋藤飛鳥さんのときも、社員向けにメッセージを 送ってくれました • 正直かわいい

18. 18.

    SmartNews の SRE

19. 19.

    SmartNews の SRE • チームとしては 2016 年 1 月から •

    グリー時代も一時期 Service Reliability という チーム名をつけていたこともある ◦ 覚えてないけど2012年くらい…? ◦ まぁその名前考えたのは自分ではないですが
20. 20.

    SmartNews の SRE • チーム名は割と悩んだ • DevOps というチーム名を打診されて、それは 手法や文化の名前なので…と断った記憶 •

    メルカリさんが一足先に SRE チームを発足させ たという影響ももちろんあった
21. 21.

    SmartNews の SRE • SRE チーム内に 2 つのロール SRE SRE

    Data Engineer
22. 22.

    Data Engineer?

23. 23.

    Data Engineer? • スマニューの現状で言うと ◦ Spark / Hive / Presto

    / Airflow あたりのコンポーネント の、堅牢化・高速化・安定化 ◦ 主に分析用途で使われる各種データストアのスキーマ管 理・変更フローの構築と運用 ◦ クエリの Optimization
24. 24.

    SRE の業務範囲 • 雑多な運用作業全般 • 各開発チームとの Sync • 自動化 •

    障害対応 • 開発・監視・分析の基盤整備 • フロー構築 • リソース管理 • コスト管理 • Incident Review とそれに伴う Action Item の Tracking • Architecture Review • セキュリティの担保
25. 25.

    Engineer 人員構成 Engineer

26. 26.

    Engineer 人員構成 Engineer 49名

27. 27.

    Engineer 人員構成 Engineer 49名 SF

28. 28.

    Engineer 人員構成 Engineer 49名 SF 5名

29. 29.

    Engineer 人員構成 Engineer 49名 SF 5名 Tokyo

30. 30.

    Engineer 人員構成 Engineer 49名 SF 5名 Tokyo 44名

31. 31.

    Engineer 人員構成 Engineer 49名 SF 5名 Tokyo 44名 Data Scientist

32. 32.

    Engineer 人員構成 Engineer 49名 SF 5名 Tokyo 44名 Data Scientist

    5名
33. 33.

    いっぽう

34. 34.

    SRE 人員構成 SRE

35. 35.

    SRE 人員構成 SRE 4名

36. 36.

    SRE 人員構成 SRE 4名 Data Engineer

37. 37.

    SRE 人員構成 SRE 4名 Data Engineer 2名

38. 38.

    SRE 人員構成 SRE 4名 SRE Data Engineer 2名

39. 39.

    SRE 人員構成 SRE 4名 SRE 2名 Data Engineer 2名

40. 40.

    SRE 人員構成 SRE 4名 SRE 2名 Data Engineer 2名 人が足りない

41. 41.

    適切な人数バランス • 正解は多分組織によってことなる • 完全に私見ですが、SRE ロールの人数はエン ジニア数の 10% くらいは必要なんじゃないかと

42. 42.

    人不足 SRE に起ること

43. 43.

    人不足 SRE に起ること Toil の嵐

44. 44.

    Toil • 手作業で繰り返し行われ • 自動化することが可能で • 戦術的で長期的な意味を持たず • 作業量がサービスの成長に大してO(n)

45. 45.

    自動化の難しい作業 • トラブルシューティング • 負荷状況に応じた Instance Type に合わせる ・Reserved Instance

    の調整 • OS や JDK などのバージョンアップに伴う動作 確認 ◦ どうあがいても自動テストだけでは確認しきれない部分 がでてくる
46. 46.

    仕方ないからやってもらう • スマニュー SRE は障害一次対応を業務範囲と しない（On-call なし） • 各サービスに担当者を1-3次割り振って各自対 応

    • 無論ヘルプはする • Terraform や Deploy はお任せ ◦ Review はするが基準を決めて任せられるものはしない
47. 47.

    自由と統制の狭間 • かつて AWS の権限は全員 Administrator • さすがに人も増えて、自由さよりも危険さのほう が増してきた •

    徐々になくてもいい権限は落とし中
48. 48.

    システムアーキテクチャ

49. 49.

    基本的なアーキテクチャ DNS: Route53 CDN: Akamai / CloudFront

50. 50.

    基本的なアーキテクチャ DNS: Route53 CDN: Akamai / CloudFront ELB / ALB

    ASG + EC2/ECS Reverse Proxy Application Server Database / Cache
51. 51.

    AWS のサービスたち

52. 52.

    基本的なアーキテクチャ • 1台だけでも ASG を使う • New Relic は料金がお高いので、ASG を別に

    してその配下1-2台だけ有効にする • td-agent / dd-agent あたりは default 設定 • sysctl のパラメータや JVM のオプションあたり はサービス特性に応じてよしなに
53. 53.

    基本的なアーキテクチャ • EC2 Instance Type は基本 On Demand ◦ Staging

    とか、EMR の Worker とかは Spot も • Reserved Instance のカバー率は安定して 80%+ • c3 は徐々に減ってきてだいぶ c4 になってきている ◦ 一部 Ephemeral Disk への依存が… • 殆どが c3 / c4 / m4 / r4 ◦ i3 / p2 / x1も稀に
54. 54.

    運用

55. 55.

    ざっくりの Traffic / day 単位とモザイクの長さでお察しください（なお時間は UTC表示）

56. 56.

    ピークと号外 • 4回の定時プッシュ = ピーク ◦ 予測が立てやすいのでさばくのは楽 • 号外 ◦

    号外検知システムから Scale-out ◦ あるいは管理画面からオペレータが操作
57. 57.

    タグの運用 • Cost ◦ コストの按分用 • Env ◦ production /

    staging / development • Group ◦ サービスグループ。デプロイの単位 • Datadog ◦ Datadog の Integration 用 • Newrelic ◦ 前述した New Relic 入れるとき用
58. 58.

    タグの運用 • Ref ◦ provisioning 時に特定の branch を当てたいとき用 • Restrict

    ◦ 所謂 IT 統制用 ◦ 特定の IAM Group に所属していないと、このタグがつ いた instance への SSH を許可しない ◦ 主に Ads と audit log を集める instance に使用
59. 59.

    設定変更とか • コンテナ化されていないものは、基本はインス タンス自体を作り直し • 前述の Group 単位で操作 ◦ 一台だけ試したい、みたいなものは

    Group 自体分ける 運用にしている
60. 60.

    IT統制 • ec2-user 廃止 ◦ 各インスタンスで AWS IAM と同期してユーザ作成 ◦

    sudo 権限の制限 ◦ SSH の制限 • 監査ログの取得 ◦ とりあえず踏み台と Ads 周りのインスタンスのみ ◦ auditd から NLB 経由して rsyslog へ • IAM 権限 ◦ 「全員 Administrator」運用からの脱却
61. 61.

    監視

62. 62.

    Datadog • Server metrics • Custom app metrics w/JMX

63. 63.

    New Relic • Application performance

64. 64.

    Chartio • Data exploration & Visualize

65. 65.

    Runscope • API performance, Data validation

66. 66.

    VAddy • Vulnerability scan w/CI

67. 67.

    CloudWatch + Lambda • AWS Service Limit

68. 68.

    ELB/ALB logs w/Presto • アクセスログなどの検索・集計 $ presto --server presto.smartnews.internal:8081 --user

    $USER --catalog hive --schema default --execute "select count(*) from raw_elb_access_log where dt = '2018-05-04' and name = 'ELB-Name' and elb_status_code = '200'" --output-format TSV 187130322
69. 69.

    AWS Config • 付いてて欲しいタグとか • 開けてほしくないポートとか

70. 70.

    Email + Zapier • AWS Retirement and Maintenance

71. 71.

    Email + PagerDuty • Airflow SLA miss • Google Security

    Warning
72. 72.

    API + Jenkins • Presto slow query

73. 73.

    GitHub + Spreadsheet + GAS • Pull Request の Review

    依頼をアカウントマッ チングして Slack で通知
74. 74.

    /deep_ping • 今までは各 Endpoint に /ping を実装 • これだとそのサービスのアプリケーションサー バに対する生存確認しかできない

    • 該当サービスが依存している、すべての他 サービスやコンポーネントとのコミュニケーショ ンが正常かまで確認する
75. 75.

    障害対応と振り返り

76. 76.

    障害対応フロー 1. PagerDuty call 2. Ack 3. 調査と対応 a. #incident

    というチャンネルですべての情報をやりとり b. #status というチャンネルにサマリした現状を逐次報告 4. Incident Report の作成 a. 担当チームの EM が書く書かないか、誰が書くかを決定 5. Incident Review の招集 a. 担当チームの EM が日時と参加者を決定。必須の参加者は該当 サービスの主担当者 + 尾形
77. 77.

    #incident の様子

78. 78.

    #incident • とにかく雑多に、やろうとしていること、やったこ と、その結果などすべて共有 ◦ 事実と推測を混ぜないように注意してやりとり • 目の前で一緒に作業している場合も、口頭の やりとりとは別にここで共有する •

    可能であれば情報をサマライズする人を、実対 応者とは別に専任で立てる ◦ 特に影響範囲の大きい（ステークホルダーの多い）障 害になるほどいたほうがよい ◦ いわゆる Incident Command System もどき
79. 79.

    #status の様子

80. 80.

    #status の様子

81. 81.

    #status • #incident は主に Engineer のやりとり • #status は各種メディアとの窓口担当者であっ たり、オペレータであったり、カスタマーサポー

    トであったりという人たちへ、わかりやすく現状 を伝える役目
82. 82.

    None
83. 83.

    Incident Review • 失敗を繰り返さないための議論を行う ◦ より良い検知方法はないのか ◦ 開発や運用のフローに問題はないのか ◦ より良いツールが必要か

    ◦ 自動化できないか • 人を責めない ◦ 「なんで◦◦しなかったんですか?」とかいうやり取りは無 意味 ◦ しっかり根本まで原因を探る • アクションアイテム・担当・期限を決める
84. 84.

    Template of Incident Report # Description // 障害概要 # Area

    of Influence // 影響範囲 # Operation // 対応内容 ## Timeline // 流れ # Cause // 発生原因 ## Root Causes // 根本原因 # Recurrence Prevention Measure // 再発防止策 ## Action Items # Supporting information // 補足
85. 85.

    アクションアイテムTracking

86. 86.

    他チームとの Sync

87. 87.

    プロダクションミーティング • Backend 系のチームそれぞれと30分 • テンプレを決めておく

88. 88.

    プロダクションミーティング • 以前からやっていたが、テンプレ導入してから ぐっと良くなった • 主要なトピックは事前に書いてもらう • 抜け漏れや議論の発散を防ぎ、時間通りに終 わるようになった •

    合同でやる形式に変えようと思っている
89. 89.

    SRE の採用

90. 90.

    Minimum Qualifications • 一つ以上の習熟度の高いプログラミング言語 • Linux/Unix のミドルウェア設定・トラブルシュー ト経験 • 分散システム・ジョブキュー・Microservicesな

    どのシステムアーキテクチャに関する知識 • 日本語か英語のどちらかが、Fluentもしくは Native • 日本勤務
91. 91.

    Minimum Qualifications • 一つ以上の習熟度の高いプログラミング言語 ◦ さすがにここは譲れない ◦ まぁなんか一つちゃんとやってりゃほかもイケるでしょと いう考え •

    Linux/Unix のミドルウェア設定・トラブルシュー ト経験 ◦ トラブルシュート能力は特に重要 ◦ 未知との遭遇・論理的なトリアージ・止血・証拠集め
92. 92.

    Minimum Qualifications • 分散システム・ジョブキュー・Microservicesな どのシステムアーキテクチャに関する知識 ◦ ここがわからないと Architecture Review ができない

    • 日本語か英語のどちらかが、Fluentもしくは Native ◦ 日本語出来なくてもいいけど、そのかわり英語は話せ ないとこまる ◦ ただし、日本語出来ない場合は採用のハードルは必然 的に上がる
93. 93.

    Minimum Qualifications • 日本勤務 ◦ 唯一ここは譲歩してもいい ◦ ただ最初の一人はかなりハードルが上がるだろう ◦ ここはいずれやっていかなければ立ち行かないし、タイ

    ムゾーンが分散するほうがむしろメリットもある ◦ どのみち SVP of Product が日本語話者じゃないし ◦ 英語圧の高まり
94. 94.

    隠れ Qualifications • コミュ力 ◦ まぁこれは SRE じゃなくてもそうか • 自走力

    ◦ なんせ人足りないので… • オーナーシップ ◦ 言い換えると球拾い力ともいう
95. 95.

    球拾い力 • 実はこれは弊害も強い ◦ どうせ◦◦さんがやってくれるという雰囲気 ◦ いうて誰かがやらないといけないというジレンマ • グリー時代も ◦

    自分含む3-4人だけが深夜や休日の障害対応をすると いう状況に陥った ◦ これはまさに球拾いの弊害である • 地道にトランスファー ◦ 1に共有 2に共有
96. 96.

    今後の SRE

97. 97.

    目指すところ • 究極的なことをいうと、SREという職種はいなく てもよい世界になるのが理想 • あらゆる作業が自動化され、人類は純粋に開 発だけに能力を使えばよい

98. 98.

    という夢を見たのさ

99. 99.

    現実的に • まずは採用 ◦ ただしハードルは下げない ◦ CEO の Referral だろうが容赦なく落とす

    • ちゃんとした Microservices ◦ 今はサービス自体は多くあるが、問題も多い • 加速する Global 化への対応 ◦ Multi Region ◦ Disaster recovery ◦ SRE 自体の Multi timezone 化
100. 100.

     現実的に • スキルコンバート ◦ 少なくとも Backend の Software Engineer とは双方

     向に可換でありたい ◦ 「こればっかりは経験だからね…」をなくしていく • プロダクトへの積極関与 ◦ 主にパフォーマンスの改善 ◦ SaaS や OSS で解決できない問題の内製 • コストパフォーマンス ◦ 札束で殴らない Engineering による改善 • PRRの徹底
101. 101.

     More automate • 自動 Rollback • 証跡の自動取得 • Alert とタスク管理システムの連携

     • Incident management の BOT 化 • Middleware や Kernel の安全な半自動 update • Reserved Instance 管理の効率化
102. 102.

     We want SRE more!! https://smartnews.workable.com/j/194EA2837E

103. 103.

     Any Questions?

104. 104.

     None