SRE NEXT 2020 参加レポート

SRE NEXTというイベントに参加してきました。 https://sre-next.dev/

簡単にこれを書いた人のバックグラウンドを説明すると、スマートフォンアプリのバックエンドをGoで書いているプレイングマネージャーです。SREともインフラとも言えるレベルでSRE本も積んでしまっているのですが、会社にバックエンドのエンジニアが10名強でインフラも兼務しています。SREチームを作れる段階ではないのですが、個人としても会社としてもインフラなんとかしたいと思い今回参加してみました。

結果として参加してとても良かったです。SREの事がまだまだでも十分に楽しく、ためになる話がたくさんありました。強い会社が強いエピソードエピソードを披露するイベントと思いきや、すぐに使えそうなノウハウだったり初心者向けのセッションもあり良かったです。この記事では、私がみたセッションについて感想をまとめていきます。

一番最初のヨガのセッションの途中から参加し、セッションは全てA室のものを聞きました。これは聞きたいのの半分以上がA室だった事、最初にA室でそこそこいい席が取れてしまった事、途中他の部屋に写ろうとしたのですが満室だったり、また入り直すために並ぶ必要があり席を取り直すのが大変なため結局全部A室のを聞いてしまいました。

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

https://speakerdeck.com/yuukit/a-study-of-sre

SREの研究についての話でした。 話の中で出てきた地理も考慮したコンピューティングというのがダイナミックですごいなと思いました。 今回の主題ではないですが、超個体型データセンターというのも初めて聞いた言葉で、確かに今はAWSで言えば2リージョンあって そこで動かすのを当たり前になっていますが、それををも地域レベルでどんどん分割していって問題が起きないようにしていくのはすごいなと思います。

こんな浅い感想ではなく、もっと色々な事が述べられていていて濃厚なセッションでした。 またもう少し知識を得た上で見返したいと思います。

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

https://techblog.yahoo.co.jp/entry/20191222793763/ NTT社でのSRE全般に関する網羅的な話でした。 PrivateなPaaSがある事も、40000コンテナある事も、それを安定させて動かすための監視体制やテストも 流石大手だ、、、という感想しかでません。ただ、40000コンテナのものを何年も運用させていたわけではなく、ここ二三年でコンテナ数が急激に伸びていたことは興味深かったです。そんな短期間でありつつもこれだけの仕組みを作れることは流石ですが。 大手はこうやっているというケースとして頭に入れておこうと思います。

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

https://speakerdeck.com/tkuchiki/sre-next-2020 SRE中途採用者に向けてのメルカリ社でのオンボードについてでした。 私としてなるほどなと思った所としては、 - オンコールが担当できるようになるのを目標とする - 技術知識だけでなく、ドメイン知識も重視する - ペアオペレーションやシャドウイングを用いて教えていく といった感じです。

余談ですが、シャドウイングというと医療系や語学学習では聞きますが、 エンジニアリングの文脈で聞いたのは初めてなように思います。今まで近い事はやってきたのですが、名前がついたように思います。オンコールも検索すると最初に出てくるのは医療系で、他の業種のノウハウを取り入れている感がありますね。

また、オンコールとされている正直自分が対応してしまう事が多く、これはちゃんとノウハウの伝搬ができていないなと再認識しました…。

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

https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures freee社が障害に対してどうやった向き合ってきたかと言う等身大かつ実直なセッションでした。 今の私の会社の規模がもし順調に伸びていったとしたら、同じような状況になることは目に見えていて 対策の必要性を実感させられました。会社の全サービスが2h止まるとか想像を絶します。 ちゃんとポストモーテム作るところから始まり、様々なアクションを起こされているのが非常に参考になりました。

今の自分の現場と照らし合わせると、失敗を共有して高あう文化ってまだできていないように思います。 参考にしつつ、自分の組織にあった障害対応フローを作っていきたいです。

[A4] 日経電子版SREチーム立ち上げ中

https://speakerdeck.com/osamunmun/ri-jing-dian-zi-ban-sretimuli-tishang-gezhong 日経電子版のSREについての話でした。 システム構成図が複数サービス、複数システム、インフラもクラウドやオンプレ、技術スタックもバラバラで苦労を窺い知れます。この中でSLI/SLOを設定しようとしてうまくいかなかったが、SREとしてシステムや組織をより良いものにできたし、そうなった上でもういちどSLI/SLOを考えてみようという内容で、SRE本の内容を理解しつつも時にはシンプルに考えたり現状に即した導入をしていこうというのが学びでした。

[A5] 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka エウレカ社のSREについてでした。 スライドがわかりやすくまとまっていて、参考になります。 現在に至るまでの流れ、SREチームのビジョン、ミッション、やっている事がクリアです。 SREの業務内容以上に、ここまでクリアに打ち出せているのが良いなと思います。

[A6] SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system mixi社の家族アルバム みてねのSREの方が語るセキュリティについての話でした。 セキュリティに関連するSREConの発表の紹介から始まり、実践できそうな内容がチェックリストにできる粒度にまとまっていて非常に良かったです。これと照らし合わせて今のシステムやAWSの運用をチェックするところをまず始めたいと思います。 ポストモーテムに対する取り組みも良かったです。作成者を称賛する文化を作ったりであったりとか、SRE以外のメンバーも巻き込むであったりとか、見習いたい所がたくさんありました。

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

GoogleのStackdriver担当であり、私としてはGoのカンファレンスの方で拝見する事が多い@ymotongpooさんのセッションでした。 このセッション非常に良かったです。SREの基本事項や原則を具体例と共に説明されていて、自分自身SREに対して誤解していた事も分かったし、SREをよく知らないメンバーがSREを深く理解していく助けになるのではと思います。

資料は現状出ていなさそうなので、個人的に印象に残った部分をピックアップすると

  • GoogleのSREチームのマークにはspes consilim non estと書かれている
    • これはhope is not a strategyという意味
    • これ以上細かい説明はなかったように思うが、「願望は戦略にあらず。望んでいるだけでなく、proactiveに対処していこう」という解釈で正しいはず
  • 複雑性はコスト
    • 柔軟性よりも一貫性のほうが価値があることがある。例外はコストが高い
    • 避けられないケースもあるが、必要もなく言語を変える他複雑性をとっていく必要はない
    • 一貫性と単純性は大事
  • モニタリングは二つ以上のやり方で行う
    • ホワイトボックスは内部からのテスト。例えば /varz,NSMP
    • ブラックボックスは外部からのテスト。例えば Ping, HTTP, IP SLA
  • アラートに思いやりを！
    • SLO違反になる危険性がなければページしてはだめ
    • ページしない、って初めて聞いたけどpageは名詞である本とかのページとは別にto call a person using a loudspeaker (= an electric device for making sounds louder) in a public placeという意味があり、つまりページングとはアラートで呼び出すという事らしい
    • 呼び出しちゃいけない例として冗長構成のクラスタが落ちた、ディスク95%フルかつ直近で変化が軽微(1w前に94.5%とか）、対応しようがない障害とか
  • メールでは対応しない方がいい
    • 追跡できない
    • オーナー不在
    • 低SN比
    • 人間による外部的な用心に依存
  • エラーバジェットとは定めたSLOで許容される時間のこと
    • SLOは結果としてxx%でした、というのを見るための喪ではない
    • 落としていい時間はどれだけか？その落としていい時間で何をやるかに注視する
    • 戦略的に落とそうというアプローチができる
    • 落としていい時間にできるアプローチとして以下のようなものがある
      • メンテナンス・デプロイ
      • 耐障害性テスト
      • よりシンプルなアーキテクチャにする
    • 厳しいSLOは変更速度を遅くする
    • SLOがないと対応するかしないかの判断基準が曖昧になる
  • ポストモーテムの良い例と悪い例
    • 悪い例、nginxの間違った設定をあげた。エンジニアはもっと注意する。金曜にリリースをしない
    • 良い例、間違った設定のファイルがテストなしに上がった。それを防ぐための対応は〜〜
    • もっと注意するのもっとって曖昧。事実と明確な対応を記載する。
    • 具体的な対応の例としては以下
      • gracefulな退役
      • 差分による予防(20%以上の行変更)でない時のみ自動リリース

長くなりましたが、それだけ内容が詰まっていて自分の中に残る部分も多かったです。

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

https://speakerdeck.com/fujiwara3/sre-next-2020 面白法人カヤックのSREに関しての発表でした。 まさに歴史の積み重ねと技術の結晶といった感じで、非常に楽しいセッションでした。 スライドにもしっかり書かれており、詳細は省くのですが、良いなと思ったプラクティスは以下のような感じです。

  • リリースログをgoogleカレンダーに投稿
  • githubの差分をsongmu/ghchで出力する
  • 祝前日のリリース禁止をリリースした後は対応できる人員を事前確保するというルールで防ぐ
  • circle ciのPerformance Planで遅い問題を一気に解決する
  • circle ciはverginiaで動いているのでイメージもそこに置く（でないと転送量が大変なことに）
  • エラー検知のアプローチ

自社でもこうやって仕組みを作っていきたいという気持ちが湧いてきました。

[A9] パネルディスカッション

パネルディスカッションでした。SRE本の訳者の方がいて、SRE本のプラクティスはGoogle他大規模だからワークするものと、今すぐに使えるプラクティスと両方ある。やれる所からやった方が良いという話をされたり、SREをやっていて良かった事としてGoogleではたらかれていた@tsekineさんが書いたコードは-10万行(それだけいらない設定を消せた）という話をされていたり、このセッションも非常に良かったです。

まとめ

さらっと書こうとしたらもうすでに2hこれを書いています。それほど密度の濃いイベントでした。次回は会社の誰かを連れてきたいです。インフラというのは技術だけでなく、組織の理解やメンバーの協力が必要であって、文化を作り上げていくものなんだというのをひしひしと感じました。

最後に運営のみなさま、発表者のみなさま非常に刺激的で楽しいイベントをありがとうございました！！！