今回は初めて CfP を出して(そして予定どおり落選して)、うっかりしているうちに個人スポンサー枠を逃して一般枠での参加でした(DAY 1 のみ現地)。
(後で見たら個人スポンサー 5 人くらいしか枠がなかった?)
DAY 1 オフライン参加…の前にちょっと寄り道
今回は午後からの開催で少し余裕があったので、渋谷駅周辺で気軽に立ち寄れそうな場所ということでヒカリエ 8F の川本喜八郎人形ギャラリーへ。
ある種の「技芸」の成果物を見て楽しんできました。
(今回は違うけどからくり人形だったら「工学をベースにした技芸」かな?)
来る前に立ち寄ってた。 pic.twitter.com/IrR6LyArSR
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
今回のブログを書くにあたって見返していた 2020 年の参加ブログにも「ちょっと寄り道」があって「4 年経っても行動が変わらないな」という感想が。
DAY 1 オフライン参加
今回は以下のセッションに参加してきました。
- Reliable Systems through Platform Engineering
- 工学としての SRE 再訪
- 巨大インフラ産業で戦う SRE
- 日本最大口座数を保有する SBI 証券の AWS マイグレーションを支えたサービスとソリューション
Reliable Systems through Platform Engineering については、残念ながら内容を十分に理解するには至らず。
実は「日本語の(キーワードと図で構成された)資料を見ながら英語の話を聞く」のは意外と難しいのかもしれない、と感じました(耳から入ってくる「聞き覚えのあるキーワード」が視覚として捉えた日本語の資料と頭の中でうまく結び付かず…)。
「いつも少し壊れている」をネガティブに捉えるかポジティブに捉えるか、みたいなのは感覚というかそれまでの経験→考え方の違いとしてありそう。
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
(なお話の内容はよくわかってないw)#srenext pic.twitter.com/6kfu2GK6Zv
たぶん「どこか少し壊れている状態で全体では正常に運用されているのが現代の分散システム」と言いたいのだろうな、と思いながらポストしてましたw
メンテナンスの許容度とか時代の流れで変わってきた印象。#srenext pic.twitter.com/FnnaZsCI4Y
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
これに関しては世の流れで計画停止メンテナンスが許容されなくなってきているのを感じる一方、「サービスの目的やユースケースを考えたらそこまでシビアじゃなくても良いシステムもあるのでは?という思いが。
段階的な変更!(あの障害を思い出しつつ)#srenext
— maru (@maruloop) 2024年8月3日
クラウドストライクの Falcon の件については、翌日(8/4)の朝に参加した(SRE NEXT ではない)立命館大学の上原哲太郎先生のオンライン講座の中で、「セキュリティ機能だからこそ段階的ロールアウトやカナリアリリースが適さない(そんなことをしていると攻撃者にやられてしまう)」という話を聞いて「段階的な処理がリスクを下げると思い込んでたけどそういう観点もあるのか!」と目から鱗でした。
工学としての SRE 再訪は、4 年前を思い出しつつ聞いていました。
コロナ禍直前の2020年回の基調講演を思い出す。
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
(その前にヨガやってたのも)#srenext #srenext_a pic.twitter.com/Cw4U0pmlMH
エンジニアリングと工学の話。
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
今回は工学#srenext #srenext_a pic.twitter.com/gomrQ3vYa3
「SRE の E は Engineering」というのは意識していたものの、「エンジニアリング」と「工学」の違いについては意識していませんでした。
いまの生成AIブーム(システム管理等への応用)はどう捉えるんだろう?
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
(黒魔術?)#srenext #srenext_a pic.twitter.com/vnhYlHWVCU
生成 AI・LLM は当たり前にさまざまなジャンルに受け入れられていますが、ちょっと前までは AI 将棋など「黒魔術」とか言われていた時代がありましたから…。
やっぱり出てきたLLM。
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
「工学的なアプローチ」として捉えていいんだろうか?
(個人的には可能だとは思うけど)#srenext #srenext_a pic.twitter.com/JsA2MLsY8n
個人的には「工学の上に成り立つもの」と捉えていますが、「学習対象が何か」を考えると違うイメージで捉える余地があるのもわかります。
障害が発生するまではいい感じに隠蔽されていたものがいざ障害が発生したときにその解決に高度な知識と能力が必要、みたいなのもあったり#srenext #srenext_a pic.twitter.com/s41nsWdApy
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
話の内容から連想する「話とはちょっとズレた話」をポストしたつもりだったのに、なんか地味に RP といいねが…?
わたしは技芸も大好きです
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
(「技芸」が指すもののイメージがちょっと違うかもしれないけど)#srenext #srenext_a pic.twitter.com/pqXwkjBC6U
冒頭の寄り道の話につながりますが。
巨大インフラ産業で戦う SREは、ちょっと遅れて参加しましたが、(サービスの対象業種や選択したツールこそ違えど)自分が経験してきたことと近い話が多くあった印象です。
SRE NEXT 2020が開催された頃だ#srenext #srenext_c pic.twitter.com/VRyudQmWLW
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
遅れたため最後列の席でズームしながら写していました。
(話の内容に懐かしさを感じながら)
このへんは(プロファイリングされる内容は)参考になるけど鵜呑みにしてはいけない、という印象(大方サンプリングだし)#srenext #srenext_c pic.twitter.com/99qmkHVGi8
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
このあたりは対象言語は違いますが最近力を入れて取り組んでいます(鵜呑みにするな、という注意をしながら)。
SREとしてどこまで踏み込むか悩む組織は割とありそう#srenext #srenext_c pic.twitter.com/YmcrXXI9x8
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
悩みながらもわたし自身は少し踏み込んでいます(SRE 以外に兼任しているチームもあるので、そちらの立場で)。
「プラクティスありきではなくチームにフィットさせる」わかる。#srenext #srenext_c
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
一方で「俺たちのやり方サイコー」みたいにならないことも大事
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
メンバーが口に出すか否かは別として、一旦チームが「天狗」になってしまうと現実を知って軌道修正するのに長い時間と大きなエネルギーが必要なんですよね。
日本最大口座数を保有する SBI 証券の AWS マイグレーションを支えたサービスとソリューションは、(規模は違いますが)自社のクラウドリフト&シフトを思い出しながら聞いていました。
個人的に「DLT」から想起するのはバックアップ用テープ…(LTO派のほうが多そうだけど)。#srenext #srenext_a pic.twitter.com/0b5j8eOjgp
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
もちろん負荷試験用のコレも知ってました。
「オートスケールがあるから負荷試験しなくても良いんじゃないか」と考える向きもあるけど(一見)同じ理由で判断が逆になるの面白い#srenext #srenext_a
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
今はおそらく「オートスケールがあるから不要」という人は少なくなったとは思いますが(スケールの速度がアクセスの波に追いつくか?やスパイクに対応できるか?は確認する必要があるので)、一方で「想定される上限のさらに上まで負荷をかけてテスト」というのはケースによっては(現在も)あまり現実的ではないし意味がない、ということも。
AZ障害もテストが必要だけど、S3やSQSみたいにいろんなサービスの基盤に使われてるサービスの障害も影響範囲が分かりづらいやつ(2021/4に東京でSQS障害が起きたけど)#srenext #srenext_a
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
こっちのほうは「AZ 冗長化」では対処できない問題が生じることも(2021/4 の障害はそうだった)。
机上で想像、でフルカバーしないといけないよりはツールが使えると楽かも#srenext #srenext_a pic.twitter.com/2TSuJAnyXW
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
これは思いますね。
スタンプラリーでブースめぐり
普段、わたしはあまり積極的にスタンプラリーには参加しないのですが、「スポンサーあってのイベント開催」という面もあるので、今回は頑張ってブースめぐりしました。
結果、
名古屋を経由して帰宅。
— hmatsu47(まつ) (@hmatsu47) 2024年8月3日
いろいろいただきました!
(未開封ですが)
ありがとうございました!#srenext pic.twitter.com/i9zSQRrrVg
開封した中身と写し忘れたもの。
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
BASE Cookiesのさつまいも🍠今秋で提供終了らしいのでいただいてきた。#srenext pic.twitter.com/sdqcuR82bH
こうなりました。
(今回、遠征に PC 持って行かなくてよかった…持ち物が重くならなくて)
懇親会
写真はすっかり撮り忘れましたが、クラブで開催、という新鮮な懇親会でした。
(わたしは行きませんでしたが先日ボランティアスタッフ参加した大吉祥寺.pm の懇親会後に DJ イベントをやっていたのでもしかして IT 界隈でブームになってる?)
SRE NEXT でしたが、わたしはずっと DB の移行の話とかニッチな仕様の話ばかりしていましたw
おまけ:DAY 2 オンライン参加
先に書いたとおり午前中は立命館大学上原先生のオンライン講座を聞いていたのとお昼に実家の買い出しをしていたのとで参加時間帯・セッションは限られました。
- 宇宙科学研究所の探査機運用システムにおける SRE のプラクティスの導入と月着陸実証機 SLIM での利用(途中まで)
- プロダクト全体で取り組む SREing:イシューから始める信頼性/生産性向上の実践
- 500 万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善
- SRE の考えをマネジメントに活かす
- スタートアップの急成長に寄り添う On-Call 体制構築とその変遷
- LT
- SREが考えるハイブリッド開催の技術イベントのライブ配信における信頼性
- SRE NEXT Chairs Talk
「人の興味を惹くような可視化」はSREには不要なように見えてステークホルダーに関心を持ってもらうには必要なことかも。
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
#srenext
宇宙関連事業でなくてもそうかもしれない、と思いました。
昨日の懇親会でもDBの話をずっとしてたんだけど、やっぱりどこもDBAは絶滅危惧種なんだろうなあ、と(わたしもDBAじゃないけど)。#srenext #srenext_c
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
DB 関連を扱った 2 本のセッションを聞きながら。
経験豊富な人が率先して社内留学に手をあげるのは良い#srenext #srenext_c
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
「開発手伝ってよ」「生成AIやってよ」あるある話だw#srenext #srenext_c
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
以上、LT を聞きながら。
みんな個人の装備が逸般の誤家庭…#srenext #srenext_b
— hmatsu47(まつ) (@hmatsu47) 2024年8月4日
配信班のみなさん大体これ。
全体の感想
自分が選択したセッションがたまたまそうだっただけかもしれませんが、プラクティスに関する話は組み込みつつも、プラクティスにとどまらない・プラクティスにとらわれすぎない話が増えた印象を受けました。
個人的には割と望んでいた方向に進みつつあります(行き過ぎると「これははたして SRE のカンファレンスなのか?」という疑問を持ちそうですが)。
来年から SRE Kaigi も始まりますし、それぞれのカンファレンス・イベントがどういう方向に向かうのか楽しみです。
関係者のみなさま、ありがとうございました!
おまけ 2:8/30(金)のゆる SRE 勉強会(1 周年記念!)に「SRE 怖い話発表枠」参加します!
これを書いている時点でブログ枠以外埋まっていますが(ブログ枠も「0」で確定?)、キャンセル待ちで OK、という方は参加枠の待機列(?)にどうぞ!