出力を入力へ

プログラミングに関する自分が考えた事を中心にまとめます

SRE NEXT 2020 に参加しました

2020-01-25 に開催された SRE NEXT 2020 に参加しました.

sre-next.dev

現在自分はインフラエンジニアとして働いており, 運用も合わせて行っているので勝手に自分もSREを名乗れるかな?と考えて 自分が今後目指すべきキャリアを見極めようと考えて参加しました.

以下自分が聴講したセッションとその感想です.

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

さくらインターネットにおける(というより発表者の?)SREを研究に昇華させた取組み.

speakerdeck.com

単なるアプリケーションの信頼性に限らず,クラウドを構築・提供する事業者としてのサービスの信頼性を どのように取組むかといった将来のSREに向けた取組みであると,まさにSRE NEXT だった.

一方で,これは今自分が取組む内容とはかけ離れていて,同じSREでもここまで違うんだな,と他人事に思えた. 最後のパネルディスカッションの中で,将来のSREはアプリ開発の中に原則は残りつつも, 究極的にはクラウド事業者だけが気を付ければいい職掌になる,といった内容の話があり, この基調講演の他人事のように思えた感じはクラウド事業者とクラウド利用者の差なのだなと感じた. だとすると,この発表のようなクラウド事業者としてのSRE NEXT ではなく, サービス開発者側のSRE NEXT を探さないといけない.

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

メルカリおよびメルペイにおけるSREを組織化するに向けて取り組んできた成果.

speakerdeck.com

メルカリとメルペイで (マイクロサービス化できているかという視点から)組織構成や取組みが異なることは初めて知ったし, これだけ技術的に優れているメルペイであってもSREがチームとして動くようになるまでには大きな苦労を伴うことは, どこでも簡単ではないんだなと現実を知った感じ.

ただ,どちらの発表もなぜそうなったのか,どうやってそうしたのかというプラクティスがあまり共有されなかったのが残念だった. メルカリのマイクロサービス移行の過去の取組みとしてchocon開発移行の状況は紹介されていても, SREがボトルネックになりそうという問題があまり理解できなかったし,組織編成でどうして解決できるのかも伝わらなかった. 時間があれば聞いてみたかったところ. メルペイもToilを受け入れて戦う必要があるし採用は辛い,チーム化も辛いと,課題はよくわかるのだけれど, サービスがリリースされたら採用できました,人が増えたら解決できました,と聞こえてしまい, どのようにToilを対処したのか,どのように頑張ったのかがわからなかった.

[C2] 成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

Voyage におけるアラートや監視の取組み.

speakerdeck.com

ユーザ視点でサービスが正常であるかを判断し,サービスの外側から重点的に監視するというのは, あたりまえではあるけどその通りだと思った.実際,自分のところではできていないから対処しないといけない. アラートも目的に応じて通知先をふりわけるというのも必要なこと. それでSREが楽になるだけでなく開発者も気にしてくれるようになるのであればこれ以上はない. アラートの見直しは障害が起きたとき,監視システムを置き換えたとき,人が増えたとき,というのはなるほどと思った. 障害が起きたときの見直しは当然だけど,人が増えたときにそれを切っ掛けにするというのは 大変だけど効果がありそうなので取組みたい.

ツール選択には複数の指標をもとに,ツールと仲良くなって判断するというのも, なかなかできていないので耳が痛い話.もっと普段からいろいろ挑戦してみないと.

[D3] Practices for Making Alerts Actionable

グリーにおける静観対応となるアラートの問題と, アラートの計測とふりかえりによるアラートの見直し,自動復旧の検討の取組み紹介.

speakerdeck.com

最近自分のところでもアラートの対応に課題があることは認識しており, どのように対応すべきか考えていたのでとても参考になった.

アラートに問題があるならアラートを計測してふりかえるという, あたりまえのことにきちんと取組めているのはすばらしいと思うしぜひ真似していきたい. 自動復旧も,既に障害で動いていない場合などこれ以上悪くならない場合には 導入しやすいというプラクティスもその通りなのでぜひ取組みたい.

[D4] 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践

ソラコムにおけるOpsDev (=SRE)の取組み.

www.slideshare.net

開発者も運用をするし,開発者もSREもサポートをするし,インシデント通知はエンジニア以外の全社員に通知するのは,すごい取組みだと思った. これがきちんと実践できているのであれば,サービスの信頼性や顧客満足度を全員が意識するようになるので, カルチャーとしてはすばらしいと思う.

ただ,カスタマーサポートも非常に難しい職掌だし,エンジニアと兼務して取組める気がしない. エンジニアのスキルだけでもキャッチアップするのが大変な,さまざまな技術が求められる時代なのに, 加えてカスタマーサポートもは自分だったら対応できない. どのようにエンジニアがサポートを実践しているのか, どのようにバックオフィス系の社員が障害アラートを認識して対応しているのかは気になるところ.

[C5] スクラムを1年回してSREと開発組織がどう変わったのか

HAMOS(ビズリーチ)におけるSREとしてのスクラムの取組み. 特定のタスクに取組めず,割り込みの多いSREがどのようにスクラムを実践してきたか紹介があった.

speakerdeck.com

どれに取組めばいいのかわからないので,タスクの優先度を定量的に評価することで全員が合意の元で判断できるようにする,というのはすばらしい取組み. 一方で,タスクの優先度を定量化するのはそう簡単ではなく, 下手をすれば設定したい優先度に向けて定量化の式を毎回見直したくなる気がする.

開発チームとの共依存について, ペアプロ等で相互に技術移管して割り込みで他者に仕事を依頼するのではなく, 自分ごととして対処できるようにするというのは理想的な状態. 現状,自分たちではまだまだ1人がやることが多くて技術移管までできそうにないのが辛いところ. このあたりは属人化の問題と関連しているのだろうけれど, どうしてもスピードが優先されるスタートアップにおいてなかなか 長期的な運用を見据えてスピードを犠牲にする判断はできない. 自分たちの取組みが必要なところかも.

[C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

クックパッドにおける既存のアプリの信頼性を担保しつつも機械学習サービスなど新しい技術領域を取り入れていく取組み.

このあたりは自分たちも近い将来同じ課題にぶつかることが想定されるので非常に参考になった. とはいえ,機械学習エンジニア側で開発リソースや自分たちで運用することができる前提なので なかなか同じようにはいかなそう. それでも信頼性の異なるサービスをサーキットブレイカーで分けるとか, デザインドキュメントで期待値をすりあわせるとか,できれば自分たちも取り入れたい.

若干ながら機械学習チームをつき離しているようにも聞こえたが, 何が大切なのかを共有できており,相互に信頼・尊重しているからこそできる無駄のない取組みだろう. そのようなチームができるように自分たちも頑張りたい.

[B7] SRE Practices in Mercari Microservices

メルカリにおけるマイクロサービスを実践していく中での,SLI/SLOを更新し続けるための取組み,オンコールへの対応,Toil(リアクティブなタスク)への取組み.

speakerdeck.com

これまでの発表内容が随所に出てくる,まさにロングセションに相応わしくSREの個々のプラクティスが一本にまとまるようで聞いていて非常に面白かった.

SLI/SLOを始めから完璧を目指さず更新していく体制を整えること,それを実現するためのポストポーテムの実践と SLO Decision Matrixを参考にしつつも 内容に応じて自分たちで判断することこは理想的なチームであるように見える.

アラートをアクション可能として,REDでアラートしてUSEで調査するという, 障害対応とはこのように実践するんだといわんばかりの体制だった.

Toilを減らしリアクティブなタスクに対処するため, デザインドキュメントで期待値を調整し,Production Readiness Checkでチェックするというのは 開発者とサービスリリース後にもめないためのリスクを減らす仕組みとしてよさそう. 一方でこれを実践しても形骸化せずサービスの品質に落とし込めるのは メルカリの優秀なエンジニアがいてこそだろうか.

[A8]基調講演: Webサービスを1日10回デプロイするための取り組み

Lobi(面白法人カヤック)における 10 deploy per dayを実現するために, デプロイを構成するあらゆる要素の高速化と誰でも安全にデプロイできる仕組みを実現する取組み.

speakerdeck.com

デプロイを高速化するためにエラー検知やロールバックを含めて高速化するところはなるほどと気付きを得た. 安全に誰でもデプロイできるようにするために,自動化するのはもちろん,計測して管理するのも王道だしよいプラクティスだと思った.

自分のところでは,デプロイが大変だと認識していてもまだデプロイも自動化できていない. デプロイ作業を計測して,デプロイの大変さを再共有し,自動化に向けた対応を強化するのはいいかもしれない. ChangeLogの生成自動化もやりたいところなので,早めに完了させたい.

全体をふりかえって

自分にもすぐに取組めそうなプラクティスから,すぐには取組めないけど将来の目標に見据えられるようなすばらしい取組みまで, さまざまな知見を共有できたすばらしい1日だった.

今までは先進技術として面白く感じていても他人事であったのが, やっと自分もインフラエンジニア・SREエンジニアとなって自分ごととなり, 自分事という新しい視点で話を聞けて非常に刺激になった.

取り入れられるプラクティスは積極的に取り入れて 今度は自分が発表する側に立てるようになりたい.