A Complete Work of SmartNews's SRE

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Agenda ● 自己紹介 ● SmartNews の SRE ● システムアーキテクチャ ● 運用 ● 監視 ● 障害対応 ● 他チームとのコミュニケーション ● 採用 ● 今後

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

About me ● メタラー ● 巨大な猫を3匹飼育 ● シガーと酒 ● オンラインゲーム ● 料理と包丁と靴磨き ● 車 ● カメラ ● プロレス

Slide 5

Slide 5 text

About me 〜2011: 受託開発 ● 医療系のシステムを開発したり ● 2005年くらいに MySQL でひぃひぃ ● 2007年くらいに Hadoop でひぃひぃ ● ついっぷるという Twitter クライアント ● 企画・設計・開発・運用・プロジェクトマネジメント全部

Slide 6

Slide 6 text

About me 2011〜: グリー ● インフラの基盤チーム ● Web ベースのオンプレサーバ構築自動化システム (PHP/MySQL/ActiveMQ/Chef) ● データ分析基盤構築 (DDD/Scala/Hive/Netty) ● 全文検索サービス (Java/Solr) ● SREっぽいなにか ○ DB Schema, SQL Review / Architecture Review ○ 障害対応

Slide 7

Slide 7 text

About me 2014〜2015: ハッチ ● Talentio ● インフラ周り全部 (AWS) ○ ChatOps ○ セキュリティ ○ Spot Instance 自動入札システム ● Crawler並列化 (PHP) 2015〜: スマートニュース

Slide 8

Slide 8 text

最近の活動 ● Think IT で PagerDuty の連載をちょろっと ○ https://thinkit.co.jp/series/7350 ● 他社でインフラアドバイザー的なことをしたり ● 来週 Slack のセミナーイベントに登壇したり

Slide 9

Slide 9 text

SmartNews

Slide 10

Slide 10 text

現在SmartNews 使ってる人?

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

SmartNews の SRE

Slide 19

Slide 19 text

SmartNews の SRE ● チームとしては 2016 年 1 月から ● グリー時代も一時期 Service Reliability というチーム名をつけていたこともある ○ 覚えてないけど2012年くらい…? ○ まぁその名前考えたのは自分ではないですが

Slide 20

Slide 20 text

SmartNews の SRE ● チーム名は割と悩んだ ● DevOps というチーム名を打診されて、それは手法や文化の名前なので…と断った記憶 ● メルカリさんが一足先に SRE チームを発足させたという影響ももちろんあった

Slide 21

Slide 21 text

SmartNews の SRE ● SRE チーム内に 2 つのロール SRE SRE Data Engineer

Slide 22

Slide 22 text

Data Engineer?

Slide 23

Slide 23 text

Data Engineer? ● スマニューの現状で言うと ○ Spark / Hive / Presto / Airflow あたりのコンポーネントの、堅牢化・高速化・安定化 ○ 主に分析用途で使われる各種データストアのスキーマ管理・変更フローの構築と運用 ○ クエリの Optimization

Slide 24

Slide 24 text

SRE の業務範囲 ● 雑多な運用作業全般 ● 各開発チームとの Sync ● 自動化 ● 障害対応 ● 開発・監視・分析の基盤整備 ● フロー構築 ● リソース管理 ● コスト管理 ● Incident Review とそれに伴う Action Item の Tracking ● Architecture Review ● セキュリティの担保

Slide 25

Slide 25 text

Engineer 人員構成 Engineer

Slide 26

Slide 26 text

Engineer 人員構成 Engineer 49名

Slide 27

Slide 27 text

Engineer 人員構成 Engineer 49名 SF

Slide 28

Slide 28 text

Engineer 人員構成 Engineer 49名 SF 5名

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

いっぽう

Slide 34

Slide 34 text

SRE 人員構成 SRE

Slide 35

Slide 35 text

SRE 人員構成 SRE 4名

Slide 36

Slide 36 text

SRE 人員構成 SRE 4名 Data Engineer

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

人不足 SRE に起ること

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

自動化の難しい作業 ● トラブルシューティング ● 負荷状況に応じた Instance Type に合わせる・Reserved Instance の調整 ● OS や JDK などのバージョンアップに伴う動作確認 ○ どうあがいても自動テストだけでは確認しきれない部分がでてくる

Slide 46

Slide 46 text

仕方ないからやってもらう ● スマニュー SRE は障害一次対応を業務範囲としない（On-call なし） ● 各サービスに担当者を1-3次割り振って各自対応 ● 無論ヘルプはする ● Terraform や Deploy はお任せ ○ Review はするが基準を決めて任せられるものはしない

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

システムアーキテクチャ

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

基本的なアーキテクチャ DNS: Route53 CDN: Akamai / CloudFront ELB / ALB ASG + EC2/ECS Reverse Proxy Application Server Database / Cache

Slide 51

Slide 51 text

AWS のサービスたち

Slide 52

Slide 52 text

基本的なアーキテクチャ ● 1台だけでも ASG を使う ● New Relic は料金がお高いので、ASG を別にしてその配下1-2台だけ有効にする ● td-agent / dd-agent あたりは default 設定 ● sysctl のパラメータや JVM のオプションあたりはサービス特性に応じてよしなに

Slide 53

Slide 53 text

基本的なアーキテクチャ ● EC2 Instance Type は基本 On Demand ○ Staging とか、EMR の Worker とかは Spot も ● Reserved Instance のカバー率は安定して 80%+ ● c3 は徐々に減ってきてだいぶ c4 になってきている ○ 一部 Ephemeral Disk への依存が… ● 殆どが c3 / c4 / m4 / r4 ○ i3 / p2 / x1も稀に

Slide 54

Slide 54 text

運用

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

ピークと号外 ● 4回の定時プッシュ = ピーク ○ 予測が立てやすいのでさばくのは楽 ● 号外 ○ 号外検知システムから Scale-out ○ あるいは管理画面からオペレータが操作

Slide 57

Slide 57 text

タグの運用 ● Cost ○ コストの按分用 ● Env ○ production / staging / development ● Group ○ サービスグループ。デプロイの単位 ● Datadog ○ Datadog の Integration 用 ● Newrelic ○ 前述した New Relic 入れるとき用

Slide 58

Slide 58 text

タグの運用 ● Ref ○ provisioning 時に特定の branch を当てたいとき用 ● Restrict ○ 所謂 IT 統制用 ○ 特定の IAM Group に所属していないと、このタグがついた instance への SSH を許可しない ○ 主に Ads と audit log を集める instance に使用

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

IT統制 ● ec2-user 廃止 ○ 各インスタンスで AWS IAM と同期してユーザ作成 ○ sudo 権限の制限 ○ SSH の制限 ● 監査ログの取得 ○ とりあえず踏み台と Ads 周りのインスタンスのみ ○ auditd から NLB 経由して rsyslog へ ● IAM 権限 ○ 「全員 Administrator」運用からの脱却

Slide 61

Slide 61 text

監視

Slide 62

Slide 62 text

Datadog ● Server metrics ● Custom app metrics w/JMX

Slide 63

Slide 63 text

New Relic ● Application performance

Slide 64

Slide 64 text

Chartio ● Data exploration & Visualize

Slide 65

Slide 65 text

Runscope ● API performance, Data validation

Slide 66

Slide 66 text

VAddy ● Vulnerability scan w/CI

Slide 67

Slide 67 text

CloudWatch + Lambda ● AWS Service Limit

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Email + Zapier ● AWS Retirement and Maintenance

Slide 71

Slide 71 text

Email + PagerDuty ● Airflow SLA miss ● Google Security Warning

Slide 72

Slide 72 text

API + Jenkins ● Presto slow query

Slide 73

Slide 73 text

GitHub + Spreadsheet + GAS ● Pull Request の Review 依頼をアカウントマッチングして Slack で通知

Slide 74

Slide 74 text

/deep_ping ● 今までは各 Endpoint に /ping を実装 ● これだとそのサービスのアプリケーションサーバに対する生存確認しかできない ● 該当サービスが依存している、すべての他サービスやコンポーネントとのコミュニケーションが正常かまで確認する

Slide 75

Slide 75 text

障害対応と振り返り

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

#incident の様子

Slide 78

Slide 78 text

#incident ● とにかく雑多に、やろうとしていること、やったこと、その結果などすべて共有 ○ 事実と推測を混ぜないように注意してやりとり ● 目の前で一緒に作業している場合も、口頭のやりとりとは別にここで共有する ● 可能であれば情報をサマライズする人を、実対応者とは別に専任で立てる ○ 特に影響範囲の大きい（ステークホルダーの多い）障害になるほどいたほうがよい ○ いわゆる Incident Command System もどき

Slide 79

Slide 79 text

#status の様子

Slide 80

Slide 80 text

#status の様子

Slide 81

Slide 81 text

#status ● #incident は主に Engineer のやりとり ● #status は各種メディアとの窓口担当者であったり、オペレータであったり、カスタマーサポートであったりという人たちへ、わかりやすく現状を伝える役目

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

Incident Review ● 失敗を繰り返さないための議論を行う ○ より良い検知方法はないのか ○ 開発や運用のフローに問題はないのか ○ より良いツールが必要か ○ 自動化できないか ● 人を責めない ○ 「なんで○○しなかったんですか?」とかいうやり取りは無意味 ○ しっかり根本まで原因を探る ● アクションアイテム・担当・期限を決める

Slide 84

Slide 84 text

Template of Incident Report # Description // 障害概要 # Area of Influence // 影響範囲 # Operation // 対応内容 ## Timeline // 流れ # Cause // 発生原因 ## Root Causes // 根本原因 # Recurrence Prevention Measure // 再発防止策 ## Action Items # Supporting information // 補足

Slide 85

Slide 85 text

アクションアイテムTracking

Slide 86

Slide 86 text

他チームとの Sync

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

SRE の採用

Slide 90

Slide 90 text

Minimum Qualifications ● 一つ以上の習熟度の高いプログラミング言語 ● Linux/Unix のミドルウェア設定・トラブルシュート経験 ● 分散システム・ジョブキュー・Microservicesなどのシステムアーキテクチャに関する知識 ● 日本語か英語のどちらかが、Fluentもしくは Native ● 日本勤務

Slide 91

Slide 91 text

Minimum Qualifications ● 一つ以上の習熟度の高いプログラミング言語 ○ さすがにここは譲れない ○ まぁなんか一つちゃんとやってりゃほかもイケるでしょという考え ● Linux/Unix のミドルウェア設定・トラブルシュート経験 ○ トラブルシュート能力は特に重要 ○ 未知との遭遇・論理的なトリアージ・止血・証拠集め

Slide 92

Slide 92 text

Minimum Qualifications ● 分散システム・ジョブキュー・Microservicesなどのシステムアーキテクチャに関する知識 ○ ここがわからないと Architecture Review ができない ● 日本語か英語のどちらかが、Fluentもしくは Native ○ 日本語出来なくてもいいけど、そのかわり英語は話せないとこまる ○ ただし、日本語出来ない場合は採用のハードルは必然的に上がる

Slide 93

Slide 93 text

Minimum Qualifications ● 日本勤務 ○ 唯一ここは譲歩してもいい ○ ただ最初の一人はかなりハードルが上がるだろう ○ ここはいずれやっていかなければ立ち行かないし、タイムゾーンが分散するほうがむしろメリットもある ○ どのみち SVP of Product が日本語話者じゃないし ○ 英語圧の高まり

Slide 94

Slide 94 text

隠れ Qualifications ● コミュ力 ○ まぁこれは SRE じゃなくてもそうか ● 自走力 ○ なんせ人足りないので… ● オーナーシップ ○ 言い換えると球拾い力ともいう

Slide 95

Slide 95 text

球拾い力 ● 実はこれは弊害も強い ○ どうせ○○さんがやってくれるという雰囲気 ○ いうて誰かがやらないといけないというジレンマ ● グリー時代も ○ 自分含む3-4人だけが深夜や休日の障害対応をするという状況に陥った ○ これはまさに球拾いの弊害である ● 地道にトランスファー ○ 1に共有 2に共有

Slide 96

Slide 96 text

今後の SRE

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

という夢を見たのさ

Slide 99

Slide 99 text

現実的に ● まずは採用 ○ ただしハードルは下げない ○ CEO の Referral だろうが容赦なく落とす ● ちゃんとした Microservices ○ 今はサービス自体は多くあるが、問題も多い ● 加速する Global 化への対応 ○ Multi Region ○ Disaster recovery ○ SRE 自体の Multi timezone 化

Slide 100

Slide 100 text

現実的に ● スキルコンバート ○ 少なくとも Backend の Software Engineer とは双方向に可換でありたい ○ 「こればっかりは経験だからね…」をなくしていく ● プロダクトへの積極関与 ○ 主にパフォーマンスの改善 ○ SaaS や OSS で解決できない問題の内製 ● コストパフォーマンス ○ 札束で殴らない Engineering による改善 ● PRRの徹底

Slide 101

Slide 101 text

More automate ● 自動 Rollback ● 証跡の自動取得 ● Alert とタスク管理システムの連携 ● Incident management の BOT 化 ● Middleware や Kernel の安全な半自動 update ● Reserved Instance 管理の効率化