名前はまだない

インフラとバックエンドの間を彷徨っているエンジニア…の卵

SRE NEXT 2020参加記

sre

ブログを書くまでがSRE NEXT
ということで、SRE NEXT 2020に参加してきたのでブログを書くことにする

SRE NEXT 2020とは

sre-next.dev

公式サイトによると

SRE によるコミュニティベースのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。

だそうです。

SREとは

じゃあそもそもSREとはなんぞやって話なんですが、こちらもサイトに書いてあるので抜粋

Googleにより提唱された、システム管理とサービス運用における考え方または方法論であり、それらを実践するエンジニアを指します。 SREは、サービスやインフラの信頼性をソフトウェアエンジニアリングによって実現することを目指します。 サービスの信頼性を重視する多くの企業において取り入れられており、近年ますますその広がりを見せています。

会社や個人によって解釈は違うと思いますが、要は開発を加速させつつ、既存のサービス提供に対しても責任を持とうねという話。(だと個人的に理解している)

0次会

とりあえず会場が豊洲って事で朝活してきた。

f:id:tetlv11:20200126222411j:plain
ネギトロ丼

講演

気合を取り直して会場に行ったら早期入場特典としてエンジニア向けヨガやってた
めっちゃ僕写ってるツイート見つけたので拝借。

そしていよいよ講演だったけど全部上げるとキリがないので特に印象に残ったものを抽出して書く

基調講演 : 分散アプリケーションの信頼性観測技術に関する研究

speakerdeck.com

  • さくらインターネット研究所の方が基調講演をしていた
    • ネットワーク遅延をどの様に改善していくかに対して地理分散コンピューティングの提案
      • 都市レベルで超個体型データセンタの開設(エッジコンピューティング)
      • データセンタ間の通信オーバヘッドをどうするか
    • 可観測性に関する研究(知識不足で理解出来なかった)
      • 時間軸的可観測性
      • 空間時間軸的可観測性
    • トレーシング技術
      • 既存のトレーシングだと漏れやオーバヘッドが発生する
      • Linuxカーネルを使ってL4レベルでパケットログを監視したりソケット通信の部分はソケット監視も
        • ソケット監視はプロセスに入り込まないのでオーバヘッドや漏れなく監視出来る

最後のトレーシング技術に関しては、データセンタまで考えているさくらだからこその発想という感じがあった。
個人的にも最近低レイヤーやオンプレの勉強をしているのでこの考え方は面白かった。

絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

speakerdeck.com

さくらインターネットの石狩とGKEの東京リージョンでレイテンシが問題になるのでライブラリを作った

github.com

学生個人だとこのレベルで通信や3way handshakeを気にすることがない…笑

  • またメルカリではスケールしたときにSREがボトルネックになってはいけないということで組織改編でSREを3チームに分けた
    • Core : Database, Mail, etc
    • Edge: CDN, Load balancer, etc
    • Advocacy : 開発チームの一員

どの組織でもSREがボトルネックにならないようにそれぞれのアプローチで組織改編などで対応しているイメージがあった

freeeのエンジニアは障害から何を学び、どう改善しているのか？

speakerdeck.com

  • 障害が起きたときの初動対応を改善
    • 障害が起きたときにslackbotで誰を呼んで誰が何をするかのドキュメントが自動生成される
      • 後のNewRelicのセッションでも同じようなことをしていた
    • 物理的に1箇所に集まるのも効率的
  • 割れ窓理論で普段から対応する文化を作っていく

blog.hokkai7go.jp

New ReilcのSREに学ぶSREのためのNew Relic活用法

speakerdeck.com

  • NewRelicでは最低でも四半期に一度Game Dayと言われるイベントを設けて、自分たちで攻守のチームに別れて攻撃 & 障害対応を行う

blog.newrelic.com

  • NewRelicのSREがどの様な業務をやっているのかもブログが公開されていたので是非

blog.newrelic.com

  • ちなみにNewRelicが扱うデータは 20億リクエスト / 分。クエリ対象は1兆イベント超。

ZOZO MLOpsのチームリーディングとSRE@sonots

docs.google.com

  • SREチームリーダーとして気にしていること
    • チームとしての方向性を定義する
    • プロ意識を持つ
    • 調整ごとは早めに
    • 心理的安全性
    • リーダーがボトルネックにならないように
    • KPT(A)
    • 技術力でぶん殴る

このセッションでは割とチームマネジメント的な話をされていた。
個人的にはSREに限らずエンジニアの組織として上に立つ人がこんな人だったら働きやすいんだろうなと凄く共感した。
KPTもやっているが、実際にActionまで持って行けてなかったり、調整ごとが先延ばしされて他の作業に支障が出たりする事もよくある。これらを解決出来る環境をチームとして作れればより個人でプロ意識を持つの事にも繋がると思う。
そして、個人的には最後の技術力でぶん殴るがツボ。
エンジニアなんだから最後はソースコードを見て自分で理解・改善していくのが仕事である。まさにその通り。

SRE Practices in Mercari Microservices

speakerdeck.com

  • サービスチーム > SREチーム > プラットフォームチーム
    • SREはサービスチームが自分たちでサービスをコントロール出来る様にプラットフォームとの間に入って手助けをする。なるほどなぁと言う感じ。
  • アラートは意味のあるアラートに
    • RED(Rate, Error, Duration)でアラートに、USE(Utilization, Saturation, Error)で調査
      • 顧客に影響のあるものだけをアラートに設定する
    • Actionableなアラート設定
      • アラートが鳴ったときに誰が何をすればいいかを明確にしておくべき
    • 他のセッションでも言っていたがアラートがオオカミ少年になるのが1番危険
    • アラートは冬休みの午前3時に起こされても自分が許せるかどうか

改めてSREと言う概念を色々な会社から聞けたのも今回SRE NEXTに来て良かったなと思った。

Webサービスを1日10回デプロイするための取り組み

speakerdeck.com

  • 誰でもいつでもデプロイ出来る環境に
    • コマンドを叩くだけでデプロイ出来るように

www.rundeck.com

github.com

  • ロールバックに備える
    • リバート→CI→デプロイは時間がかかるのでデプロイ時に使用しているtarボールをばら撒く機構を作った

前のセッションでも言われてたが、まさにサービスチームがサービスに責任を持てるための橋渡しをするためのSREチームというような仕事内容だった。
余談だが、Elastic Transcoderで毎月家が立つくらいコストかかっていた はまじで衝撃。

最後に

  • 流石に1日10セッションを休みなしで聞くと疲れる。帰って9時前には爆睡してた
  • 最近のカンファレンスは生中継したり後で資料公開されていたりするから行かなくてもいいかぁと思うこともあるけど、やっぱり現地に行って話を聞くことでモチベーション上げれたり出来るので個人的には出来る限り参加したい
    • 次はDevelopers Summit行きます
    • 今年は自腹でGoogleIOかAmazon re:Invent行こうと画策中…
      • せめてチケット手に入らないかな…
  • SREとかに興味のある学生ってどれくらいいるのかな？
    • 今回のイベント行っても思ったんだけどSREってあんまり学生いないイメージ
  • 今回の発表資料はQiitaにまとまっていたので気になる人は是非

qiita.com