見出し画像

SRE NEXT 2023 に参加してきました

こんにちは、Azukaritaiの小松です。先月、2023/9/29 (金) に、SRE NEXT 2023 というカンファレンスに参加してきました。

SRE NEXT は、コミュニティベースのSRE勉強会である SRE Lounge のメンバーが中心となって、運営・開催されるカンファレンス形式のイベントで、2020年に初回開催され、今回で3回目の開催となるようです。私は今回初めて参加してきました。

コロナ禍前はこういう大きなカンファレンスも度々開催され、足を運んでいたのですが、そもそも開催されなくなったり、再開されても、リモート慣れでなかなか会場まで足を運んで参加するというところまでできなかったりというのもあり、個人的にも久しぶりのリアル会場の大規模カンファレンスへの参加でした。

会場は九段会館テラスというビルの中にある、貸し会議室・宴会場でした。以前(といっても、15年以上前)飯田橋に弊社のオフィスがあった時に、九段会館の近くは何度か通っていて、あそこかな、となんとなく場所のあたりをつけながら会場に向かいましたが、すごく綺麗な新しい建物に変わっていてびっくりしました。

今回のSRE NEXTは、会期が9月29日(金) のまる一日(朝10時から18時まで+懇親会)で、現地&オンラインのハイブリッド開催となっていました。後半のクロージングキーノート中に発表されていた数字によると、現地参加者227人、オンライン参加者743人、セッション数30ということでした。私は、予定を1日開けて、午前中から夕方まで、ひたすらSRE関連のセッションを聴き続けるということで、色々な刺激を受けることができました。この記事では、自分が聞いたセッションのうちのいくつかについて、そこで特に印象深かったことを備忘録かねて、簡単にまとめておきたいと思います。

セッションの内容の詳細は、パネルディスカッション以外はアーカイブ映像&スライドがまとめられて公開されています(すごい)。

オープニングキーノート ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜(イオンネクスト 樽石さん)

  • 発表タイトルはエンジニアっぽい緩い感じを狙ってあえてつけてみたとのこと(と冒頭説明されていた)

  • 企業の経営(あるいは組織設計)に、ソフトウェアシステムのアーキテクチャのベストプラクティスを当てはめて、Micro Companies Architecture という形にして、事業の要素機能ごとの組織分社化、子会社(?)間のAPIの定義をやって炎上しそうだった新事業(Green Beansというネットスーパー専業のネットスーパー事業)立ち上げをオンスケでやったよ、というお話だった

  • SREの絡みは「スーパーマーケットのReliability」という切り口で、少し触れていたけれどもあっさり目だった。

  • 樽石さん、お話聞くまで存じ上げなかったのだけど、RedHat -> Google -> Retty CTO -> イオンネクスト CTO という方ですごい方(https://techplay.jp/column/1557

勘に頼らず原因を見つけるためのオブザーバビリティ(Sansan 上司さん)

  • 名刺のサービスで有名なSanSan社の、請求書のサービスBill One のSREチームの上司さんという方の発表

  • オブザーバビリティ本に書いてあるような教科書的なオブザーバビリティの導入を実践した経験談という感じだった

  • 「Observabilityの導入ができている状況=プロダクトについての長年の経験や直感に頼らず、デバッグや障害対応ができる状況」というのを強調して話されていたが印象的だった

  • プロダクトの運用規模・エンジニアチームが小さいうちは、ベテラン頼みのトラブルシュートの方がコスパいいしそこまで困らないけれども、長期的に見ると、若手が成功体験を積む機会を奪うことになり、人材が育たない、面白くなくてやめていく、ベテランがずっとかかりっきりにならないといけなくて、そこがプロダクトの成長のボトルネックになる、というパターンの原因になる、というような説明をされていて、オブザーバビリティ本にもそういうストーリーが書かれていたけれども、より具体的にわかりやすくそこの必要性のロジックを聞けて腹落ちした。

  • Observability がある状況ってどんな状況?というのの説明の一例として「ベテランじゃなく、一番モチベーションが高いエンジニアが一番早くデバッグ・障害対応できるようになっている状況」という説明をしていて、なるほど、と思った。

【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜(パネルディスカッション)

  • https://sre-next.dev/2023/schedule/#pd01

  • 配信なし

  • CloudNative Daysの運営をやっている青山さん、Platform Engineering Meetupの発起人の草間さん、DevOpsDays Tokyo実行委員の岡本さんがパネラーになって、SREのお隣(?)のコミュニティ・カンファレンス運営の人たちと、コミュニティ・カンファレンス運営のよもやま話をするスタイルのパネルディスカッションだった。メタな感じで面白い。

  • それぞれのコミュニティ、カンファレンス知らなかったので、興味持つことができた。

  • 実行委員の人数とか、そのマネジメントとかの話で、それぞれの違いや工夫どころなどの話をして盛り上がっていた。

  • 発表内容を公募で集める時に、CFPというのを出してもらって選考するフローが一般的になっているのを知った。(参考:https://note.com/ayatokura/n/n5fb7aebc781d

  • DevOps Daysは海外からのゲストスピーカー招聘を行うというのを軸に持っている。海外のゲストスピーカーが来たがるシーズンが、桜の時期なので春にやっているらしい、など。

プロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例(はてな Mackarelプロデューサー 渡辺さん)

  • はてな社のモニタリング・ダッシュボードのサービスのMackarelのプロデューサーの渡辺さんによる、MackarelのSLOの話

  • Mackarel自体ちゃんと使ったことなかったので、今こんな感じなんだ、と認識できてよかった。精力的にサービスの改善などやられている印象。

  • Mackarel のユーザーの使い方としては、ダッシュボードみたり、対象サービスの監視(外形監視&エージェントによるメトリクス収集?)をしたり。

  • ダッシュボードが遅いと辛い、サーバー/APIで多少エラー発生してもクライアントがリトライするので許容できる、など。

  • SLOを設計する上ではユーザーの声を聞くのが重要、どうやるか -> 直接インタビューしたり、アンケート取ったり、X(旧Twitter)でなんて言われてるかみたりする。

  • SLOの良いところは、数値化して、チームと意思決定の理由を共有できるというところ。ないと、大変。もう一つは、改善が実際に効果を出したかをSLIの変化で確認できるということ。

SREの組織類型に応じたリーダーシップの考察(Topotal 菱田さん)

  • SREのコンサルティングなどをやられているTopotal社の営業の菱田さんの発表。

  • 冒頭に、こういうの初めてで緊張しているという前置き。(ほんと?)

  • 発表の内容は、MBAの授業に出てきそうな、リーダーシップ論の話と、SREの組織への導入の話の重ね合わせの話だった。

  • リーダーシップ理論の1940年代から現代に至るまでの変遷の話がここで出てくると思ってなかった。

  • 冒頭の、インシデント対応のSaaSのWaroomが近々正式リリースされたり、AIがポストモーテムの下書きしてくれる機能が入るという話が自分的にはセンセーショナルだった。ベータ期無料利用させていただいたけれども、スタートアップ向けの試しやすいプライシングやフリーミアム的なプライシングも用意してもらえたらよかったのにと思ってしまった。

  • もう一度読むSREというPodcastをTopotalのCEOの高村さんと二人でやられているという紹介もされていたのでそのPodcast聴き始めた。

クロージングキーノート 信頼性目標とシステムアーキテクチャー(グーグル 山口さん)

  • Google社(日本)の山口さんという方。SRE関連のオライリー本の訳・監訳をいろいろされているすごい方。

  • SRE Nextは、初回から、毎回何かしら登壇して話をされているとのこと。

  • クロージングキーノートの内容の前半は、割とベーシックなSLOについての説明。でも非常にわかりやすかった。

  • 山口さん、SLO本の監訳もされている。

  • 後半が本題?高いレベルのSLOを設定しようとすると、単に頑張るのではなく、システムのアーキテクチャーをそれに合わせて変更する必要があるというメッセージ。

  • それに応じて、コストも、インフラ、ハードウェア、人員、プロセス、全てに関連して、増加するというのを具体的に説明いただいた。

  • https://r9y.dev/ というサイトにこの辺りがまとまっている。

  • デモ:90%, ベータ版:99%、安定版:99.9%、拡大期:99.99% という目安がある。

  • デモやベータ版の頃は、信頼性よりもプロダクトの機能開発が優先される。安定版や拡大期は、機能はいじらずにより多くの人に使ってもらえるようにすることの優先度が上がったり、そもそも可用性が大きな収益に直結したりするということと理解した。

感想とおまけ

久しぶり(10年ぶりぐらい??)に丸一日エンジニアカンファレンスに、しかもオンラインではなく、参加するというのをやってみたのですが、まとまったインプットを、いっぺんにすごいボリュームで、直接浴びるというのは、いろいろと普段と違う刺激を受けられて良いな、と思いました。予定調整して行った甲斐がとてもありました。来年もまた開催されるのかなと思うので、その時には、CFP出してみたり、実行委員に応募してみたりもできたらいいなと思いました。

会場の九段会館テラスは、お堀端の解放感のあるカフェとか屋上庭園とかのスペースも充実していて、コワーキングスペースもあったりするので、また何かの機会に使いたいなと思いました。屋上庭園からはお隣の武道館(行ったことない)がよく見えます。カバーの写真はカフェのテラス席に迷い込んできたカマキリさんです。

この記事が気に入ったらサポートをしてみませんか?