kashinoki38 blog

something like tech blog

SRE Nextに参加してきたのでメモ

 超いまさら投稿だが、1/25にSRE Nextに参加してきたのでメモ。
sre-next.dev

 そもそもSREに対してあんまりFamiliarではなかった状態で参加したが、どういうことをするのか、とか、何故SREが必要なのか、といったところについて少し理解ができるようになった。

 インフラだけの話じゃなく、開発の生産性をどう高めるかというところに踏み込んでいるのが、俺としては今までの俺のインフラというイメージと違っている部分だと感じた。

 また、自分の部署ではコンテナ、オーケストレーション自体があまり広まりきっていないしどうやって監視するのかよくわからんという世界観なのに対して、ここで登壇している企業では試行錯誤しながら生産性と信頼性の両立を目指していることに衝撃を受けた。

 今までの俺の世界観だとコンテナ入れることについてインフラ的に性能が~~という話しかできなかったけど、SREの文脈で考えていくことで信頼性をある程度以上に保ちながら生産性を上げて、ユーザに対して最大の価値を与えるというより高尚な世界に突入できるような気がした。

15:00~ [B4] 冗長性と生産性を高めるハイブリッドクラウド環境の実現

sre-next.dev

  • GCP
    • 専用線でオンプレとハイブリッドクラウドをつなぐ
      • Shared VPCで複数プロジェクトにシェア
      • 専用線を2重冗長化→99.9%のSLA + VPNでバックアップ経路を用意し、オンプレ内でBPGによってダイナミックルーティング
  • micro service化
  • オンプレもCloudもKubernetesを利用
  • 次年度はAnthos導入予定

15:30~ [B5] New RelicのSREに学ぶSREのためのNew Relic活用法

sre-next.dev

  • MMF(最小市場価値)
  • Game Day
    • 最低四半期に一度、あるいは新しいメンバのオンボーディング
    • 敵性Game Day
      • 目的を明確に
      • 攻撃側と対応側にチームを分ける
        • 攻撃側
          • 攻撃手順
          • 影響範囲を想定
          • 対応策を想定
        • 対応側

16:00~[C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

sre-next.dev

  • Takayuki Watanabe
  • Cookpadの海外チーム
  • gaps
    • テクノロジーを制限(小さな組織で多様化を防ぐ)
    • プロダクション環境に、破壊的なプロとリリースをSLA担保しつつしなkればいけない
    • on-call対応させるにはエンジニアは8人必要
  • action
    • design document → テンプレート
    • リソースを分離(別のAWSアカウント)
      • VPC Flow logsとか有効にしてわたした
    • Circuit Breaker → Traefik(envoyだとレイテンシベースの設定が難しい)一日とかで導入可能
      • closed, open, half-open
        • openがServiceがunhealthyなときで503を返す
        • half-openはヘルスチェック
      • サービスメッシュは不使用
      • SLOでしきい値設定
  • 【重要】新しいサービスを実験的に導入する場合、SLOを事前にコンセンサスを取り、SLOを下回った場合切り離す

17:00~[B7] SRE Practices in Mercari Microservices

sre-next.dev

  • Microserviceはアーキテクチャだけなじゃく組織を作ることも重要
  • SREが運用するわけじゃなく、Serviceチームが運用できるようにツールとかを提供する
    • サービスに特化したReliabilityの改善はSRE
      • productivity(生産性)とreliability(信頼性)がSLA
    • commonな部分はPlatform
  • googleのSRE work bookのテンプレートをパクってSLI/SLO doc作っている
    • 定期的に定義をレビューし改善していくことが重要
    • 更新の仕方はgoogle SRE work book
  • SLI/SLO for Spinnaker
    • Pipelineの実行時間
  • アラート
    • RequestRate, Error, Duration(RED)でアラート
    • Utilization, Saturation, Error(USE)で調査(ブレンダンクレッグが提唱)
    • アラートに1対1でplaybookを用意しておいて、Actionableにしている
  • Reactive Tasks
    • Toil
    • Developer Support
    • Bug fix
    • Security fix
  • MicroserviceのReliabilityのための取り組み
    • Microservices Design Doc (template)
      • Summary
      • Backgound
        • Goals
        • Non-goals
      • System Design
        • Interfaces
        • Traffic migration
        • expected clients / dependencies
        • SLI/SLO
        • databases
        • security considerations
    • Production Readiness Check
      • Maintainability
      • Obserability
      • Reliability
      • Security
      • Accessibility
      • Data Storage

17:55~[A8] Webサービスを1日10回デプロイするための取り組み

  • 1日に10回デプロイしたい
    • モノレポ
      • サーバーアプリ(本体API、マイクロサービス)
      • フロントエンド(Nuxt.JS)
      • EC2のプロビジョニング(Chef)
      • AWSの構成変更(Terraform)
    • 常にデプロイして、デプロイが怖くなくなる
    • ToBe
      • 1回1回のデプロイを高速化する
      • 誰でもデプロイできるように
      • いつ何がデプロイされたか管理できるように→自動で管理、可視化
  • デプロイの要素
    • CI(テスト)
      • Jenkins→Curcleci
    • ビルド/配布
    • エラー検知
      • (Norikra)1分間のエラー数をカウント、1分に1回通知
    • ロールバック