SRE NEXT 2020 へ参加してきた #srenext

2020-01-26雑記Tech

SREのカンファレンス「SRE NEXT 2020」に参加してきました。
学びが多かったので忘れないうちにメモしておきます。

参加したセッション

参加したセッションのメモをベタ書き。
スライドが公開されているセッションであれば、スライドのリンクも貼っておきます。

なお、発表資料はさっそくQiitaにまとめている方がいました。ありがたい。

【SRE Next 2020】発表資料まとめ #インフラ - Qiita

2020/01/25 に行われた SRE Next の資料まとめです。資料が公開され次第、内容を更新します。分散アプ ...

https://qiita.com/Hassan/items/6f7fb1c206f77716ee2a

40000コンテナを動かすSREチームに至るまでの道

40,000コンテナのPrivate PaaSを実現するために必要だったこと - Yahoo! JAPAN Tech B

ヤフーのPaaSチームがどのように数万コンテナのシステムを本番環境で稼働させる仕組みを作ったのか

https://techblog.yahoo.co.jp/entry/20191222793763/

ヤフー社内のエンジニア向けに提供しているPaaS基盤
本番環境として40,000コンテナ以上稼働している
アラート対応は「利用者に影響があるか」を重視している
- 仮にメモリ使用量が増加してもユーザ影響がなければ急ぎの対応は不要
各アプリの稼働率が見えるSLOダッシュボードを用意
- 「ユーザ影響の有無」が分かるテストツールを作っている
- ブラックボックステストを数分間隔で各サービスに実行
SLO駆動でアラート対応、SREチーム内の評価指標にもSLOを使う
SREメンバ育成には障害対応のロールプレイを実施している
- クラスタが複数落ちた→何のコマンドを打つ？誰に連絡する？など
マネージャ主導ではなく自己管理型のチームを目指している

大規模なPaaS基盤を運用しているSREチームのお話。
数あるVMのメトリクス異常だけで通知を飛ばしているとキリがないので、「ユーザ影響のある事象に限り急いで通知→対応する」という方針は良いなと感じました。

パフォーマンスを最大化するためのSREのオンボーディング事例

SREオンボーディングのゴールを「オンコール対応ができる状態」と定義した
オンコール担当に求められる項目は大きく3つ
- 技術知識: メトリクスやログを調査できる
- ドメイン知識: サービスの機能やお客様への影響度が分かる
- コミュニケーション: 機能担当者の把握、SRE外と連携しての対応
ドメイン知識やコミュニケーションの習得が課題になりがち
ペアオペレーションとしてオンコール当番の対応を一緒にやる
オンコール対応のシャドウイング（実際の障害事例で慣れる）
実作業がイメージができる状態にして心理的負担を下げた
オンボーディング専用Slackチャンネルを作った
- ノイズが少ない＆質問しやすい
- メンター以外でもサポートしやすい
- 振り返りに使いやすい

入社後のフォローアップ、技術知識なら個人でもある程度は拾っていけますが、ドメイン知識（業務知識）や組織面の把握って確かに難しいですよね。
OJTに近い形で依頼タスクや障害対応に触れられると早く身につけられそうです。

グループウォレットアプリ、6gramの運用をはじめてみた

6gramは複数人で財布を共有できるウォレットアプリ、iOS版はもうすぐ
クレジットカード情報を取り扱うため「PCI DSS」の準拠が必要
- アカウント要件がやや古かったり、セキュリティ要件が厳しかったりする……
運用負荷を下げつつPCI DSSに準拠するために工夫してみた
- EC2を使わずFargateにする→サーバ内のアカウント管理が不要
- コンテナをreadonlyにする→改ざん検知の仕組みが不要
- データはDynamoDBに入れてKMSを使う→暗号化と運用をマネージドで完結
- バッチをCodeBuildで実行する→EC2を建てない、Lambdaでは時間が足りない
実際に↑の構成でPCI DSSに準拠することができた（審査が通った）
インシデント対応のシミュレーションを定期的に実施している
課題としては、可観測性が低くトレーシングやログがやや不十分
SREとしての専任はおらず、全員で開発・運用を行っている

決済というお固い領域で、PCI DSSに準拠させつついかに運用負荷を下げるか、というお話でした。
難解な要件に対して次々と解決策を打ち出すテンポの良い発表で、「PCI DSSはパズルゲーム」という名言も登場。個人的には一番印象に残ったセッションでした。

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

サービスが急成長、累計会員数は1000万人を突破
特性上、DB ReadだけではなくWriteの負荷もかなり高い
DB設計の見直しとともに、アプリもフルスクラッチでGo言語にした
SREチーム立ち上げ時に、ミッションを明確に定めて行動指針とした
可用性99.95％を目指して、事業の機会損失を防ぐことが目標（の1つ）
アラートレベルを再設計、ユーザ影響度を基準にした
Fargateに移行してスケーラブルなシステムに
「SREは土木作業」ビジネスの土台を整えるのが大きな役割
振り返りにはKPTを採用
- Tryの中で最重要項目を1つ決めて、次のサイクルで確実に実施する

PairsのSREチーム、組織や運用方針よりの話が多めでした。
SREは事業貢献の面での成果が見えづらい、というのはあるあるな気がしています。

信頼性向上に限らず、価値提供のスピードアップを支援するなどのミッションを定めて合意しておくことは確かに重要かもと感じました。

SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

家族アルバムアプリ「みてね」、国内外から600万ユーザ以上が利用中
Kubernetes（EKS）への移行を実施中
SREとDevOpsの違い: class SRE implements DevOps
グローバルカンファレンスの「SRECon」が参考になる
脆弱性バジェット＝依存するソフトの脆弱性が問題になるまでの期間
レガシーバジェット＝OSやミドルウェアのサポート期限切れなど
よく整備されたロギングは脅威の検出と障害への備えになる
- ログ上に個人情報を書き出さない
- でもユーザIDはトレースできるようにしておきたい
- クラウドサービスのログ機能はなるべく有効化
有事の際の指揮系統・チェックリストなどを事前に定めておく
手間の掛かることは自動化する
脆弱性パッチは素早い適用が重要
コミュニケーションが重要
- 他チームとの間に壁を作らない、タスクを押し付け合わない
- ビジネスや事業の視点も持ってみる
- 新規開発時にヒアリングをしてみる（ミドルや設計の懸念点など）
依存しているソフトウェアやライブラリは定期的にアップデートする
ポストモーテムは積極的に作る、作成者を称賛する文化を作る、批判は絶対しない
AWSの責任共有モデルやWell-Architected Frameworkに目を通す
クラウド側のセキュリティサービスを活用する

SREが担当する領域の広さを再認識したセッションでした。
なるべく設計段階からセキュリティを考慮し、問題が発見しやすい・対処しやすい・追いやすい環境を作ることが大事ですね。

あとはクラウドの機能も揃ってきているので上手く活用しましょうと。

サイト信頼性エンジニアリングの原則

Google - Site Reliability Engineering

Discover Site Reliability Engineering, learn about building and maintaining reliable engineering ...

https://google.com/sre/

SREのモットー「Hope is not a strategy」
複雑性はコストである、一貫性を保っておくこと、例外はコスト高
プログラミング言語もなるべく統一できると望ましい
ステートフルな仕組みはなるべく減らす
モニタリングには大きく2種類の方法がある
- ホワイトボックス: 内部メトリクス
- ブラックボックス: 外形監視やSLAなど
アラートへの思いやりが大事
- SLOに響かない単なるメトリクス異常は通知しない
- 緊急度が低いものは通知せず、通常業務内で対応する
- 即時対応が必要ないものはチケットで管理
メールは通知手段として適さない
- メーリス宛だと誰が主担当になるか分からない
- 同時に複数人動いたり、逆に誰も動かなかったりする
- メールを自発的に見ないと気づけない
モニタリングで信頼できる情報源を決めておく
- 複数のツールで似た値が取れる場合はどっちが正？
- 時計が1つなら時間を即答できるが、時計が2つあると判断に悩む
可用性が99.9％＝100％を達成できなかった、ではない
- 残りの0.1％を活用して改善やシステムのシンプル化に注力すること
- どちらかと言えば「0.1％までのダウンを予算として使える」という考え方
デプロイ時にはロールバック手順も用意されていること
システムにも障害耐性をつける
- 再起動コマンドの実行前に設定ファイルの不正チェック
- 変更差分が明らかに多すぎる（20％以上等）なら一旦止める
障害対策テストは、可能なタイミングでいつでも実施しておく
ポストモーテムの運用
- 非難しない
- プロセスと技術に注目する
- 人間は修正できないので、仕組みや環境の方を修正する
- ダメな例: エンジニアが設定ファイルの変更を誤った
- 正しい例: 不正な設定ファイルが検証無しでデプロイされた
障害に早く気づくために監視頻度や監視対象を見直す
障害回復を早くするために、変更直前の設定を自動保存する仕組みなど
https://google.com/sre を読みましょう
SRE本は気になる部分だけでもいいから目を通した方がいい

エラーバジェットの考え方
可用性99.9％＝100％が達成できなかった、という意味ではない。残りの0.1％は改善や機能リリースなどに使える「予算」となり、0.1％のダウンタイムを活用して積極的な変更も可能となる。#srenext #srenextA
— yuu26/えむおん@SRE (@m_on_yu) January 25, 2020