20200125 SRE NEXT 2020 参加メモ
2020/1/25 SRE NEXT 2020 参加のメモです
昨年のSRE Lounge で今回のカンファレンスの開催をしりました。11月に先行販売が開始後、数時間で完売すると言う注目度の大きさが感じられていました。どの講演も聴きたいと思われるようなタイトルが並んでおり、各セッションは20 - 40 分でテンポよく開催されました。また、（疲れた時の？）サテライトブースも併設されるなど、聞いている側への配慮も感じられる素晴らしい運営だったと思います。
カンファレンス情報
- 日時：2020/1/25 11:50 - 21:30
- 公式: https://sre-next.dev/
- Twitter #srenext
- 会場：豊洲フロント
- 参加人数感：300人程度か?
「まとめ」られている資料一覧
各セッションから得られた共通的なキーワード
- 組織論（マイクロサービス、SREチーム構成）
- SLO/SLI の取り決め、定義
- 可観測性の重要性
- オンコールの取り組み
各セッションのメモ
[A0] 分散アプリケーションの信頼性観測技術に関する研究(さくらインターネット)
- 研究内容をわかりやすく説明されていた
- 自動化の皮肉
- 人は認知的な高度な訓練が必要となってしまう
- 失敗を許容するような設計を行うことが重要
- SRE とは
- リスクの事前予測とリスクの事後最小化
- 地理的分散コンピューティング → 可観測性が重要になってくる（時間軸、空間軸）
- 超個体型データセンタは、今後の進展を長い目で期待
[C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長(株式会社メルカリ)
- マイクロサービスを問い入れるに当たって組織面での役割明確化を進められた内容
- マイクロサービス化を進める
- マイクロサービスは組織のプラクティスでもある
- 開発チームとの融合化ポイント
[B2] 計画的に負荷リスクを排除するためのキャパシティプランニング(タップル)
- 実際に発生したキャパシティ問題に対して、その対策、SREの関わりや文化的側面をわかりやすく解説されている
- 継続的な把握が必要
- 本番と同様な試験環境策定
- 試験環境のAWSアカウントを別として安全性確保
- 誰でも使えるように
- スクリプト実行で
- レイテンシSLO
- API遅延体験会を実施
- 今後は、負荷環境でのスペック調整をできるようにしていきたい
[B3] グループウォレットアプリ、6gramの運用をはじめてみた(mixi)
- 業界規格に合うようにかつ、運用負荷を低減させる対応策を練りに練ったというお話
- 開発・運用のリアル感がすごく伝わってきて、聞いて良かったと思ったセッション
- 講演者さんから懇親会で多くのお話もしていただいた
- 6gram
- 招待制（ミクシィらしい？）
- 決済サービス
- PCI DDs準拠
- 内製化がポイント
- インシデント対応計画シミュレーション
- 可観測性道半ば
- 開発環境をより本番環境に近づけることができるとよい
[B4] 冗長性と生産性を高めるハイブリッドクラウド環境の実現(UZABASE)
- SPEEDA というプロダクトをご担当
- ハイブリッドクラウド
- オンプレのみで事業スピード落ちた
- パブリック使うけど、オンプレは無くさない選択
- マイクロサービス
- 疎結合になる恩恵を受けている
- ハイブリッドクラウドでの冗長性・生産性
- Anthos 使ってみる予定
- キューブスプレイ？
[B5] New RelicのSREに学ぶSREのためのNew Relic活用法
- New Relic サービスの全体像が少し見えた
- SRE 50人
- 20ー70デプロイ／日
- NRDB → インサイト
- 1兆のイベントへのクエリ！
- SRE の日常
- game day
- いわゆる避難訓練のようなもの
- 四半期に一回、オンボーディング時
- game day
- New Relic
[B6] ZOZO MLOps のチームリーディングとSRE(Engineering)
- ZOZO TOWN にMLを入れるときの人のお話
- （研究段階で）モデルはできているがプロダクト化できていないので、講演者がJoinしたとのこと
- MLOpsチーム
- 研究所がプロト作成、このチームがプロダクト化
- EMとtech lead
- チームリーディングの話が参考になった
- 方向性
- 心理的安全性
- The TEAM 本
- 1on1 １ページの説明であったが、参考になった
- プロ意識
- 社内の期待を裏切らない
- とか
- 「技術力でぶん殴る」
- 技術力があってなんぼ（同意！）
[B7] SRE Practices in Mercari Microservices(メルカリ)
- マイクロサービス基盤テックリードの方
- マイクロサービスに関する考え方を理解するために非常に参考になる話であった
- 資料の３ページ目の三角の図、イメージとして参考になる
- 基盤のリライアビリティ
- SLI SLO基盤の設定
- 開発に重点を置きがち
- カスタマーの視点に立つ
- 最初から完璧なものを目指さない。改善ループ回す
- SRE workbook 参考にしている
- SLOの責任者を決める
- SLOを更新する日を明確に
- スペックwhatとインプリhowを分けて考える
- spinnaker マルチクラウドデリバリーツール
- これに SLO入れている。パイプラインの実行時間とか
- SLIの変更 見直し SLOが満たせない場合
- オンコール
- オンコールは誰がやるの？ 組織定義がポイント。基本はサービス側
- PfはSRE
- サービスごとにnamespace定義。システムnamespace もある
- オンコールは週ごとにアサイン
- 大量のアラート。狼少年
- REDでならす。rate, error, duration
- use utilization, satisuration error
- アラートをアクショナブルにする
- 意味のないアラートが飛ばなくなってきている
- Toil
- reactive task と呼んでいる
- プロアクティブタスクに影響
- 初期 → ローテーション → dedicated team へ
- コンテキストスイッチが大きい
- オンサポートチーム性とした
- SLI SLO基盤の設定
- マイクロサービスのリライアビリティ
- プラクティスを展開
- デザインドック書く
- コード書く前に仕様を書く
- テンプレートあり
- SLO SLIも書く
- production readiness check
- 非機能の情報をチェックする仕組み
- 自動化が追いついていない
- (質問)外部サービスのSLOに引きずられないか
- それ以下にする必要がある
- (質問)デザインドックは開発者に嫌がられなかったのか？
- みんなで決めた
- checkは、最初から使っているがチェック項目が多く、自動化したいと思っている
懇親会
テーブルではどなたも一度もお話したことなどがない、講演者の方、スタッフさん、一般参加者の方々と会話ができました。懇親会が２時間もあるのは長いかな、と思っていましたが、気が付くと21時をまわっており「ウィークタイズ」を実感できる有意義な時間となりました。
その他
スタッフのホスピタリティが素晴らしい！
- ビル内の誘導
- 各会場での裏方に徹した動き
- （大変であったであろう）事前準備
- 入場の分散対策と思うが、ヨガのセッションは新鮮で本当に良かった
会場もGood！
- 移動距離が少なくて済むルーム配置
- 空調問題なし
- ちょっとした休憩場所が絶妙に用意されている
- 電源が机に用意されている
- 懇親会会場が（参加者に対して）適切な広さと椅子もあり
SREを調査・研究している立場として、現状の課題感・将来にむけた直近の対策・長い目での方向性などがみえ、業務にいかせることができる有益なカンファレンスでした。
