$30 off During Our Annual Pro Sale. View Details »

Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

StudySapuri Product Meetup #1 〜脱スタートアップフェーズにおける開発チームの現在と未来。少数精鋭の運用体制からデザイン・アーキテクチャまで~ における SRE チーム @yuya-takeyama の発表です。
https://techplay.jp/event/680406

Yuya Takeyama

July 19, 2018
Tweet

More Decks by Yuya Takeyama

Other Decks in Programming

Transcript

  1. Product Meetup #1
    Quipper における SRE チームの紹介
    ~僕が SRE になった理由~
    @yuya-takeyama

    View Slide

  2. #sapurimeetup

    View Slide

  3. 01
    02
    03
    Agenda | 自己紹介
    SRE チームの紹介
    僕が SRE になった理由

    View Slide

  4. 01 自己紹介

    View Slide

  5. @yuya-takeyama
    2009 年新卒で音楽系事業を行う IT ベンチャーに入社
    エンジニア 10 年目

    View Slide

  6. View Slide

  7. @yuya-takeyama
    2015 年 9 月 Quipper に転職
    Web Developer として Rails, Backbone.js, React.js,
    React Native など
    2018 年 4 月
    SRE チームに異動
    絶賛弱くてニューゲーム中

    View Slide

  8. 02 SRE チームの紹介

    View Slide

  9. ➔ サイトの信頼性に責任を持つ
    ◆ 可用性、パフォーマンス、キャパシティプランニング...
    ➔ インフラの構築、運用
    ➔ そのためにソフトウェアによる自動化を行う
    ◆ Infrastructure as Code, GitOps
    Site Reliability Engineering

    View Slide

  10. ➔ Kubernetes による Microservices 基盤の構築
    ◆ Kubernetes クラスタの構築・運用・デプロイ自動化
    ◆ 旧環境からのアプリケーションの移行
    SRE チームの最近の取り組み

    View Slide

  11. 03 僕が SRE になった理由

    View Slide

  12. Kubernetes
    やりたかった

    View Slide

  13. Kubernetes とは?

    View Slide

  14. コンテナ
    オーケストレーション
    システム

    View Slide

  15. コンテナ
    オーケストレーション
    システム
    とは?

    View Slide

  16. たくさんのコンテナを
    いい感じに
    動かし続ける

    View Slide

  17. たくさんのコンテナを
    いい感じに
    動かし続ける

    View Slide

  18. ➔ アプリケーションのあるべき状態を YAML で宣言的に定義
    ◆ 使用するイメージ、必要なリソース、コンテナ数...
    ➔ 障害が起きても、「あるべき状態」に自動的に復旧
    ➔ 使用リソースに応じて、複数サーバに均等に配置 (スケジューリング)
    ➔ 更新時にはコンテナを少しずつサーバを入れ替えて行く
    いい感じとは?

    View Slide

  19. Kubernetes は
    Microservices に最適

    View Slide

  20. Kubernetes
    楽しいよ!

    View Slide

  21. でももっと
    大事なのは...

    View Slide

  22. Quipperの
    プロダクト開発を
    最高にしたい

    View Slide

  23. Quipperの
    プロダクト開発を
    最高にしたい

    View Slide

  24. 最高の
    プロダクト開発
    とは?

    View Slide

  25. ➔ Ownership
    ➔ Borderless
    ➔ Agility
    ➔ Reliability
    僕が思う最高のプロダクト開発

    View Slide

  26. ➔ 現状: 1 つのソースを数十人のエンジニアで開発している
    ◆ 境界が曖昧だと空気の読み合い・お見合いになりがち
    ● それでは Ownership を持つのは難しい
    ➔ 各 Service Unit が個別の Service を所有し、責任を持つようにしたい
    ➔ サービス間のインターフェイスだけ決めて、あとはよろしくやる
    ◆ 制約があるからこそ自由になれる
    ➔ それ、Microservices じゃん
    Ownership

    View Slide

  27. ➔ なんでもやりたい人はなんでもできるように
    ➔ 権限の制限をできる限り取り払う
    ◆ アプリケーションエンジニアだってインフラをいじりたい
    ◆ ネイティブエンジニアも API を作りたい
    ➔ Monorepo にすることで複数領域を一気にガッとやれる状態
    ◆ 依存関係のある複数サービスを 1 Pull Request でまとめて変更
    Borderless

    View Slide

  28. View Slide

  29. ➔ 仮説検証のサイクルを高速に回せる
    ◆ 個別アプリでなく、サービス群全体でのステージングデプロイ
    ◆ 本番へのデプロイも各 Service Unit の裁量で
    ➔ 本番環境で、柔軟に少しずつ検証するための仕組みが必要
    ◆ Feature Flag, Canary Release
    ◆ ダメだったらすぐに戻せる
    ➔ ユーザーに高速に価値を届け続ける
    Agility

    View Slide

  30. ➔ 基本的にはアプリケーションの開発に集中してほしい
    ➔ サービスは安定稼働させなければならない
    ➔ そのためにはあらゆる自動化が必要
    ◆ メトリクス、アラート、オートスケール...
    ➔ オンコール対応の移譲
    ◆ 障害からの復旧時間の最小化
    ◆ Dev も SRE も同じメトリクスを見て、同じテーブルで会話する
    Reliability

    View Slide

  31. Quipperの
    プロダクト開発を
    最高にしたい

    View Slide

  32. Quipperの
    プロダクトを
    最高にしたい

    View Slide

  33. ユーザーに
    最高の教育を
    届けたい

    View Slide

  34. 最高の技術で
    最高の教育を

    View Slide

  35. Thank you
    For
    Listening!

    View Slide