はじめに
SRE kaigiという技術イベントに初めて参加してきました。自分が聞いたセッションの中でかなり学びがあったので、振り返りながら記載していこうと思います。
セッション
ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡
さくらのクラウドからAWSに移行をすすめつつ新規サービスを進行。インフラ領域を担当していたtech Leadの方が、退職により責任集中。属人化を脱却しつつ、技術以外の負債も抱えながらきっちり取捨選択をして進めていくストーリーが展開されていました。
- エンジニア採用での魅力の苦戦
- ビジネススピードを落とせない
- アプリケーション・インフラともにレガシー環境
- 経営層を説得させる
これらの状況に対して戦略をとりながら、アプローチをとっていくところが印象的でした。
- SLOが下回った際の監視アラート体制（slack検知）
- 情報を可視化できるdashboardの作成
- AWSセキュリティ成熟度モデルからの現在地の明確化
- IaCのコードで再現性を構築
SREを実施するまでの過程もとんでもない寸劇だなと思ったのですが、上記4つを進めて基盤をつくっていくところも爽快で。SREとしてのアプローチも徹底されて感動しました。
自分がいま担当している開発領域でも業務要件の優先順位を明確に整理していきたいなと思いました。
SRE とプロダクトエンジニアは何故分断されてしまうのか
組織拡大に伴う「SREとプロダクトエンジニア（実際にアプリケーションを開発している人）」間での課題を構造的に解釈し、アプローチを提示していました。
- 「分断」が起きるのはどうして？
- 「バウンダリー・スパニング」
- ⭐️「視座」
SREとエンジニア間での分断がおきること自体、すごく違和感というのか、プロダクトエンジニア側から、口を出さない方がいいのかな🤔と思っていたのですが、その境目もコミュニケーションを図りながら構築していく必要があるのだと強く感じました。
最後の「視座」の観点は、全エンジニア必読の内容になりそうです。
刷新のプロジェクトに携わっている自分にとってはリリースすることが最優先事項ですが、今後は機能面だけではなく非機能面の課題感や意識を持っておこうと思いました。
とても痺れました。
月間数億レコードのアクセスログ基盤を無停止・低コストでAWS移行せよ！アプリケーションエンジニアのSREチャレンジ💪
- uuidのアクセスログ
- 月間数億レコード
縛りの強い中でのAWS移行の話が語られていました。要件を整理したうえでデータのフロー図だったり、システムフロー図を使いながら全体を整理して段階的に移行を進めていてたのが残りました。
rubyでの実装も包含しているので、rubyを使われている方には話が共感できる内容なのかなと思いました。
データ欠損しても原因を掴んで、EKSを扱い倒してリリースのクローズまでもっていく精神がカッコ良すぎました。
開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦
データ基盤の観点でさまざまな設計パターンを用いて、アプリケーション・インフラレイヤそれぞれで仕組みを検討していくところがわかりやすかったです。
設計パターンは「選ぶ」だけではなく、「育てる」ことが重要
ユーザー側の可用性ってすごくありがたいことを実感するセッションでした（笑）
（もう一度データ指向アプリケーションデザインの本を読もうかな....）
クレジットカード決済基盤を支えるSRE - 厳格な監査とSRE運用の両立
そもそも監査のスコープを最小化することや、セキュリティチェックで怪しい問題があったらissueに自動記載する仕組みを構築していたりなど、Toilを減らしていく姿勢（SREの精神）が随所に散りばめられていて印象的でした。
Cognitoを多要素認証の強制で使うであったり、KMSを機密情報保持の暗号化に使うであったり.....
AWS各種サービスを目的ベースでまとめており、技術選定の意図がクリアになりました。
これをきにドキュメントの整備やアーキテクチャ図など、見直す機会になりそうです笑
まとめ
とっても充実したイベントでした。これまでに技術イベント参加した際には、スタンプラリーに毎回参加していたのですが、今回はいっさいやらず、sessionをききまくりました。
"SRE"という言葉は知っていますが、具体的にどういうことをやるのか？どんな概念があるのか？を知らなかったので、「知る」という歩みを得られただけでもかなり大きな収穫です。
他のsessionも参加したいのがいくつかあったので、発表資料を見にいこうかなと思いました。