Mental Sketch Reflected

Defining my shape

SRE NEXT 2020に参加しました

SREによるコミュニティベースのカンファレンスである、SRE NEXT 2020に参加しました。

 

SRE NEXT 2020

https://sre-next.dev/

 

このSRE NEXTの運営・開催はコミュニティベースの勉強会であるSRE Loungeのメンバーが中心となっています。ちなみに私は個人スポンサーという形で参加させていただきました。

簡単に聴講させていただいた講演についてまとめていきます。 

KeyNote

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

speakerdeck.com

 

 SREの概念を進めて、地理分散コンピューティングの観点から、観測した内容をトラフィック・インフラストラクチャの制御に利用して最適化する仕組みについての研究という内容でした。QuorumCacheアーキテクチャについては、こちらの方がもう少し詳しく解説があります。

超個体型データセンターを目指した分散協調クエリキャッシングの構想 / QuorumCache Architecture - Speaker Deck

 最近の分散コンピューティングの技術はアプリケーションの構造を大きく変えて分散制御に対応しようとしますが、それに対して既存のアプリケーションやミドルウェアのコードを変更しないという制約つけた上での研究だという話でした。

 

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

資料が見つけられませんでしたが技術的な内容がこちらに書かれています。これに加えて、SREチームのマネジメントの話がありました。

techblog.yahoo.co.jp

SREチームのマネジメントについては個人的に興味がある分野であり興味深かったです。ミッションとして「SRE領域に責任を持つ組織を作る」を掲げており、SREと組織論の密接さを察しました。スクラムを採用し自己組織化されたSREチームを作る上でのプラクティスがいくつか紹介されていました。

 

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

speakerdeck.com

中途採用の新規SREメンバーをいかに一人前にするか。一人前とはどんな状態なのかについての発表でした。オンコール対応に不可欠な(技術的知識以外の)ドメイン知識とコミュニケーションを磨くためのプラクティスとして、ペアオペレーション・オンコールのシャドーイングなどが紹介されていました。オンボーディングの結果を(定量的に)評価する方法にまだ課題があるようです。

 

delyにおける安定性とアジリティ両立に向けたアプローチ

speakerdeck.com

SREは、プロダクト開発の速度を安全に高めることが存在意義であると置いて、開発速度を安全に高めるための方策として想定外の複雑さを最小限にするという方針をおき、それに対する具体的なアプローチをどのように取ってきたかが紹介されていました。

初期フェーズでは取らざるを得なかった複雑さを、成長フェーズでどうかえしていくかについて、実用的な方策をたくさん実施していて素晴らしいと感じました。

複雑なモノリスはある程度続いているテックな会社ならどこの会社にもあると思うので、個人的にすごく参考になりました。

 

SLO Review

speakerdeck.com

SREの立場から開発エンジニアにSREプラクティスとしてSLOを導入させ、どのようにプロセスを改善する文化を醸成するか、ビジネスサイドと交渉するための説得力を持たせるかといった話でした。必要なSLIの実装を完了させ、もう少しでエラーバジェットの導入までいけそうということで、実効的なSLOの構築を丁寧に行っていてすごいと感じました。

 

Blue Greenデプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話

speakerdeck.com

GKEを採用し、開発エンジニアの職掌範囲をコンテナ以上と規定し、それ以下の基盤としてSpinnaker, Algo Rolloutsを使った共通のデプロイメントを共通的な仕組みとして提供したという話でした。デプロイメントパイプラインの構築もCloudBuildをつかい自動化しているということで、省力化とリリースサイクルの高速化をうまく実現していると感じました。技術的な課題以外にも、リリース判定の会議体が多いという課題もあり、そちらは鋭意解消中だそうです。

 

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

docs.google.com

 

MLの研究成果を本番環境のプロダクトに引き上げるというミッションを掲げるMLOpsのチームリーダーがどのようなプラクティスを用いてチームをリードしていくかといった話でした。SREのみならず新規に発足したチームがどのように社内の信頼を得てどのように成長していくか、フェイズやメンバーによってどんなプラクティスを使っていくかのトライが紹介されていました。当たり前のレベルが高くてすごい。

 

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

資料が見当たらなかった

GoogleのSREプラクティスを紹介する発表でした。個人的に、SLO違反にならないアラートは飛ばさないこと、アラートに思いやりを持つこと、ユーザ体験が確実に損なわれそうであれば呼び出すこと、メールはよくないこと(進行がトレースできない、傍観者効果、オーナーの不在、ノイズが多い、人間が気にしていないといけない)といった内容が参考になりました。

 

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

speakerdeck.com

一日10回を実現するために、いかにリリースを高速化するかといった内容でした。CIによる自動テストを高速化するためにPerlの処理を並列化させCircleCIで8コア20並列でぶん回していたり、ソースコードを高速に同期するためにツールを作っていたりといった内容でした。ghchやescpressoなどの便利そうなツールが紹介されていて使ってみようかなという気分になりました。

 

パネルディスカッション

パネルディスカッションは事前に参加者から出された質問にパネリストが答えていくという形式でした。SREの成果とは何を期待されているのか?という点に対し、GoogleではSWEがやるよりもSREがその専門性をもちいて素早く正確に価値を発揮するという点でSREの価値が発揮されるというのが興味深かったです。また、SRE本のどこまで実践できていればSREと言えるのかといった質問がありましたが、信頼性を担保したいという思想のもと使えるプラクティスを導入していればSREといえるという回答で、そうだよなぁと思いました。こういうのはスクラムも同じようなことが言えそうです。

 

まとめ

参加してよかったです。講演がすごく多くて少し詰まり気味で、発表時間が短い、休憩時間がないといった点が気になりました。ただこれが初回のカンファレンスということで、改善すべき点はあれどとてもうまくいったカンファレンスだと思いました。SREと組織、SREと機械に関するプラクティスや研究について知見を持っている人からもっと話を聞いてみたいと感じました。

懇親会も多くの人が参加されていて楽しかったです。次回は未定だそうですが、開催は前向きに検討されているそうで、また個人スポンサーで参加したいと思いました。