A Complete Work of SmartNews's SRE

A Complete Work of SmartNews's SRE

hbstudy #86 SRE大全 スマートニュース編

D93fb300519f17800d3fbc8119ed4bed?s=128

Nobutoshi Ogata

December 06, 2018
Tweet

Transcript

  1. 2.

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

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

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

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

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

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

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

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

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

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

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

    他社でインフラアドバイザー的なことをしたり • 来週 Slack のセミナーイベントに登壇したり
  7. 13.
  8. 14.
  9. 15.
  10. 16.
  11. 19.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    GitHub + Spreadsheet + GAS • Pull Request の Review

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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