VTRyo Blog

一歩ずつ前に進むブログ

TD Presents！SRE勉強会に参加しました!

勉強会 sre

f:id:vtryo:20180716121046p:plain

今宵はこちらに参加してきました！

【TD Presents】「信頼性×大規模」サービスを運営する会社が語る！ サービスを安定的、かつ、スケーラブルに運営するための技術事例勉強会 ～インフラ/SRE編～

（多分最速で）ざざっとまとめました。メモ取れなかったり（リスニング能力がなくて英語が聞き取れなかったり）したところは公開されるであろう資料をあとで貼ります（泣）

開始前のぼく↓

概要

安定性・信頼性をキーワードに、サービスをスケーラブルに運用するための技術をさまざまな角度から語るトークシリーズ。 今回は、まさにサービスの安定性や信頼性の屋台骨を支える「インフラ」や「SRE (Site Reliability Engineering」方面からの取り組みや技術について、事例紹介を交えながら語っていただきます！

Building reliable services

Reliability is the quality of being trustworthy or of performing consistently well. With standards, exceptions are hard; without standards, everything is hard. At Treasure Data we are improving and standardizing our services across hundreds of deployments to improve overall service and system reliability.

  • 400,000+ Queries / Day
  • 15Trillion Record / Day
  • using AWS

（はずかしい。その場で必死に聞くので手一杯だった。もっと英語がんばろう・・・）

prismatix SREチーム立ち上げからの1年間

クラスメソッド事業開発部では「ECとCRMのためのAPIプラットフォーム」をコンセプトに、prismatixという製品開発に携わっており、日々多くのリクエストを捌いています。SREチームが発足した2017年1月から、サービスの安定化と運用自動化のためにどういう取り組みをしてきたかをお話しします。

prismatix SREチーム

2017年1月に発足。当時1名。
現在は3名に。

SRE的に主にやっていること

  • AWSマネージドサービスで運用コストを削る
  • 再現可能なインフラに改善する
  • デプロイ方法の見直し（誰か実行しても同じようになる→完全自動化ということ）
  • テスト時だけ環境を構築して、それ意外はリソースがない状態にする（それくらいの再現性を保つ）

Datadogのintegrationが便利

  • 複数のAWSアカウントに対応しているのがよい

  • 環境がどれだけ増えても管理コストは増えない

  • 基本的なCloudWatchメトリクスとOS上メトリクスを取得

  • SLAとSLO
  • API可用性

障害調査で使われるログは全体の１％未満しかない

ECS→fluentd→ALB→fluentd→CloudWatch Logsという流れで送信しつつ、S3にも退避。

しかし膨大なログ全てをCloudWatch logsに送っていると値段がかなり膨れる。
Athenaを使って必要なログを必要なときに取り出すように。

  • AthenaならS3上のデータに対してSQLで検索できる！（Athenaのパーティションきらないと値段で死ぬ。月初にパーティションを切るバッチを作成、ECSスケジュールで動かす）
  • アプリログは全てJSONで出力
  • Athenaなら他のAWSアカウントのバケットにもアクセスして読みに行けるのでDB名だけかえればいい

Prometheusで監視導入

  • リアルタイム性向上
  • 今はS3からしか見れない

スマートニュースの進化の歴史

2012年12月にリリースしたスマートニュースは、昨年10月には世界で2500万ダウンロードされるまでに成長しました。 ここに到達するまで色々な課題にぶつかり、それらをひとつひとつ乗り越えることで組織として成長してきました。今回は、わたしたちが成長の過程で学んだことのうち、「日米のマルチリージョンで開発をするために必要なこと」と「スケールする開発体制を 作るために必要なこと」についてお話をしようと思います。

スマートニュース特有の取り組み

  • 割り込み作業がないよう漫画喫茶みたいになった部屋がある（創業者が漫画喫茶でプログラミングしていたなごり）
  • Slackには言語別（日本語、英語）のチャンネルが有る
  • Slackのリアクションに国旗を用意して国旗の言語に翻訳させるBotをつくってある

SREな取り組み

  • DevとOpsで戦争はしたくない
  • Devはコード化されたインフラを設定を
  • Opsはコードをレビューすることで安定化を

使ってるツール

  • terraform
  • itamae, fablic(タグ単位とか)

コード化のよきこと

Dev「.tf更新したで」
SRE「変更内容とdrytun結果をちょうだい」
Dev「ぷるりくに書いたで」

ぷるりくにDryrun結果を貼る。

  • 前もって変更内容をレビューできる
  • SREの負荷軽減
  • 実際の作業はDevに委譲
  • Gitに履歴が残る
  • 差し戻しが楽

Devと同じ土俵にいるのがSRE

一定の規模になったらIaasとのエンタープライズ契約する

  • 契約するとめっちゃ雑なことも聞ける

こちら側の設定ミスやエラーだと思っていたことを、気軽に聞いたら「すまんハードウェア障害だったわ」ということがある。

こっちは絶対判断できないのであって損はない

マイクロサービス

最近良く聞くマイクロサービス。いい話と悪い話どっちから聞きたい？

●いい話

  • サービスごとに違う技術を選択可能
  • サービスごとにチームを分割可能
  • サービスごとにスケール可能
  • 小さい単位でのリリースが可能

●悪い話

  • サービス間での流用が困難

  • チーム間でナレッジが分断

  • サービス数がエンジニア数を超える現象

あるときエンジニアがやめる→レガシーコード発生！

●おとしどころ

  • 新サービスの作成がベストか疑う
  • サービス＆エンジニアを１：１にしない
  • サービスごとにチームを閉じない

コミュニケーションHack

Work Out Loud

読書会勉強会は・・・

  • ひと目につくとこでやれ！
  • ひと目につくとこで資料公開！
  • 寿司とビールがあると良いね！（ひかれてくるよ！）

チームビルディング費用として勉強会に予算をつける！

スマートニュースはオフィスもうまくコミュニケーションとれるように設計してある。何かをするにはオフィスを横断しなければならない。

バリスタのコーヒーを貰いに行くにも、会議するにもオフィスを横断する！

システム障害に強いシステム

  • メトリクス
  • アラート
  • インシデントアサインメント
  • インシデント処理

障害対応、すごいひとが全部やっちゃってめっちゃ大変になる問題。

オンコールローテーションで解決？

  • ドキュメントの整備
  • 秘密鍵を持ってるPCを持ち帰れるか
  • HRとしてのサポートはあるか（深夜対応とか）

世界最大のレシピ動画サービス「クラシル」を支えるインフラ

1000万ダウンロードを突破したクラシルの急成長を支えるSite Reliability Engineering

元料理人SRE

最初のクラシル

  • WEBやDBはシングル構成
  • 監視なし
  • 分析基盤なし

限られたリソースで信頼性と大規模を実現刷る必要があった。

現場で使えるSRE

設計

  • スケーラビリティ（スケールアウト）
  • 負荷テスト
  • サイジング（RDB、ジョブ、ディスクサイズは一年分くらい確保）

スケールするほど処理Requestが伸びる＝スケーラビリティの確保。

一年後の規模感でも行ける設計に。

可用性

  • 単一障害点をなくす（冗長構成）
  • バックアップ
  • 自動復旧
  • モニタリング
  • サービス/リソース監視
  • 監視メトリクス
  • サチュレーション
  • CPUメモリIO空き容量nado

キャッシュ

  • memcached
  • nginx

プロトコル

  • SSL必須
  • gzip（application/json)
  • HTTP/2
  • パフォーマンス＆コストに影響

変更に強い設計

  • ログ収集基盤（データ設計に伴う変更が不要。）
  • 構成管理でコード化。DRY原則
  • 半年で作り直す覚悟

運用

  • SLOがなぜ重要か
  • 全アラートに対応？
  • 信頼性を上げる作業には終わりがないから線引する
  • 減点方式から目標達成方式に転換。
  • ユーザにとってどうかという線引する

どうやってSLOを決めるか

  • ユーザ目線
  • すでに取得できている指標や習得しやすい指標を使う
  • 今のパフォーマンスを基準にしない（トラフィックが増えたときとかに対応できないため、あくまでユーザ目線）

Infrastructure as code

  • DRY原則
  • ツールやFWは任意
  • タグで管理
  • 論理名と物理名（役割をタグにつけてあとで変えられるように）

devops

  • デプロイは自動化し開発者がする
  • ロールバック
  • カナリアリリース
  • Chatops

webトップページを守る理由

  • 予期せぬ数十万UU
  • 新規ユーザ獲得

  • 遅いページで全体が詰まる

  • Nginxのキャッシュ（今考えればCDNでよかった）

インシデント対応

  • オンコール担当がインシデント責任者に連絡→トリアージ
  • 重大な場合は専用チャンネルを作成しタイムラインでわかるようにする

ポストモーテムにかくこと

  • タイムライン
  • よかったこと
  • わるかったこと
  • 幸運だったこと

ポストモーテムのポイント

  • 根本分析は必要な分だけ（人が足りないので全部は無理）
  • 再発防止策はIssue追加
  • 犯人探しはしない

TODO管理

  • Issue作成（Redmine)
  • タスクは自分から拾う
  • SREミーティングで棚卸し

マネジメント

  • SRE principles（主体的に行動できるようにしたい、得意分野を活かして生産性を、細かく決め過ぎない心理的安全）
  • ミーティング
  • リスクマネジメント
  • 障害対応訓練（SRE育成）
  • 本番と同じ環境を環境せよ
  • 実際の障害を再現させる

はい！ということで

終わりです。。。あの、英語まじで聞き取れなくてスキル不足を感じました。。。

最近英語セッションを聞く機会が爆裂に増えていて、その度に泣きたくなってTEDずっと聴いて訓練してます。

今回私が一番印象に残ったのはクラシルさんですね。
SREの青本の原則をしっかり守りつつ（特にSLO）、信頼性を構築しているようでした。

「ユーザにとってCPUがどれくらい使われているかは関係ない。ならそのアラートもいらない」

おっしゃるとおりですよね。だからこそ、「余計なアラートを飛ばさない」という思想のPrometheusが生まれるわけですから。

可用性100%はありえないですし、可用性99.99%を保っていたとしてもユーザが使いたいときにダウンしていたら信頼はされません。

完璧主義になりすぎず、かといってスピード感を損なわずに、ユーザ満足度を高めていきたいものです。

参考

Site Reliability Engineering