はじめに
SRE NEXTの1日目に参加してきました。
自分は新卒2年目のプラットフォームエンジニアです。普段は、認証基盤やサービス間の同期処理など、複数のサービスから利用される共通基盤を開発しています。
今回参加したきっかけは、社内のSREチームから声をかけてもらったことでした。プラットフォーム開発とSREは同じ仕事ではありませんが、複数のサービスを横断して支えるという点では近い領域にあります。
とはいえ、参加前の自分はSREに対して、かなりインフラ寄りのイメージを持っていました。
- オブザーバビリティを整える
- コンテナやインフラを構築する
- サービスが止まらないように監視する
ざっくり言えば、こうした仕事を担当する人たちだと思っていました。
実際に参加してみると、このイメージ自体が間違っていたわけではありません。ただ、ブースを回り、セッションを聞く中で、それらはSREの目的ではなく、信頼性を支えるための手段なのだと感じるようになりました。
この記事では、SREではない自分がSRE NEXTに参加して感じたことを書いていきます。
ブースとセッションで見たSRE NEXT
ブースを回って感じた面白さ
当日はスタンプラリーがあったので、すべてのブースを回りました。
会場全体に活気があり、企業の方と話しながら回るだけでも楽しかったです。
企業ブースというと、サービス紹介や採用案内が中心というイメージがありました。しかし実際には、それだけではありませんでした。
各社が、自社のサービスでどのように信頼性を担保しているのか。どのような課題に対して、どのようなアーキテクチャを採用しているのか。そうした具体的な事例を聞くことができました。
「信頼性を支えるために、そんな設計の仕方があるのか」と思う事例もあれば、自分たちの共通基盤と似た構成もありました。
良し悪しを判断するというより、信頼性を支える方法にはさまざまな選択肢があると知れたことが面白かったです。
普段は他社の設計判断を直接聞く機会が少ないので、ブースを回るだけでも、自分の設計の引き出しが少し増えたように感じました。
セッションで印象に残ったこと
セッションにも2つ参加しました。
SREのカンファレンスということもあり、内容はインフラや分散システムに近いものでした。ただ、印象に残ったのは個別の技術よりも、その背景にある考え方です。
システムは、壊れないように作るだけでは足りない。
壊れたときに影響を広げないこと。壊れたことに早く気づけること。できるだけ早く復旧できること。
そうしたところまで含めて、信頼性を考える必要があります。
この考え方自体は、SRE NEXTで初めて知ったものではありません。自分も過去のインシデントを通じて、性能や非機能要件の重要性は学んでいました。
ただ、会場でさまざまな事例に触れる中で、それらがすべて「サービスの信頼性をどう支えるか」という一つのテーマにつながっているのだと整理できました。
自分の仕事と信頼性がつながった
過去のインシデントを思い出した
自分は年始に、各サービスをつなぐ同期処理のリファクタリングを担当しました。
開発環境では、画面から操作すると期待どおりの結果が返っていました。そのため、問題なく動いていると判断していました。
しかし、本番規模のデータで動かすと処理性能が大きく悪化し、同期処理が滞留しました。その影響が後続処理にも連鎖し、サービス内の複数機能が一時的に使えなくなりました。
調査を進めて分かったのは、開発環境と本番環境のデータ量の差です。
開発環境ではデータ量が少なかったため、性能が悪化していても、UIを操作するだけでは気づけませんでした。
このインシデントを受けて、チーム内では振り返りと恒久対応を行いました。本番規模で性能を確認することや、非機能要件を事前に考える重要性も、その時点で学んでいます。
個別の課題が「信頼性」というテーマでつながった
SRE NEXTへの参加によって新しく得たのは、性能の重要性そのものではありません。
それまで個別の課題として見ていたものを、信頼性という枠組みで整理できたことです。
- 性能が悪化しないようにする
- 問題が起きたときに影響を広げない
- 異常を早く検知する
- 復旧しやすい状態にする
これらは別々の話ではなく、すべてサービスの信頼性を支えるための設計です。
過去のインシデントで自分たちが向き合っていたことと、SREが向き合っていることは、思っていたよりも地続きでした。
SREへの見え方が変わった
「何をする人か」から「何を支える人か」へ
参加前の自分は、SREを具体的な業務で捉えていました。
ログを取る人。
アラートを出す人。
監視やインフラ構築をする人。
もちろん、それらもSREの重要な仕事です。
ただ、今回参加して感じたのは、それらは目的ではなく手段だということでした。
ログを取るのは、問題に早く気づくためです。アラートを出すのは、障害の影響時間を短くするためです。システムを分離するのは、一部の問題を全体に広げないためです。
そう考えると、SREは特定の技術や作業を担当する人というより、幅広くサービスの信頼性を支える役割なのだと思います。
「何をする人か」ではなく、「何を支える人か」で見るようになりました。
自分も信頼性を支える側にいた
この見方で考えると、自分も信頼性を支える側にいるのだと気づきました。
もちろん、自分の職種はSREではありません。監視基盤やインフラ全体を担当しているわけでもありません。
ただ、自分が開発している認証基盤やサービス間の同期処理は、サービス内の複数機能を支えています。
そこに問題が起きれば、影響は一つの機能だけにとどまりません。
共通基盤を安全に提供すること。問題の影響を必要以上に広げないこと。異常に気づける状態にすること。
これらも、サービスの信頼性を支える仕事です。
SREと同じ仕事をしているわけではありません。ただ、職種は違っても、目指しているものには重なる部分があります。
自分はSREではない。それでも、信頼性を担う一員ではある。
今回の参加を通して、そのことを言葉にできたのが一番大きな学びでした。
おわりに
SRE NEXTに参加する前は、SREやインフラエンジニア向けのイベントというイメージを持っていました。
実際に参加してみると、ブースでは各社の信頼性を支える設計や運用を知ることができ、セッションではサービスをどう信頼できる状態に保つかという考え方に触れられました。
その中で、自分の過去の経験や現在の業務も、信頼性というテーマと深くつながっていると気づきました。
SRE NEXTは、SREという職種の人だけのイベントではないと思います。
アプリケーションエンジニアでも、プラットフォームエンジニアでも、サービスを作り、支えているのであれば、自分の仕事につながる学びがあります。
自分はSREではないから、と参加を迷う必要はありません。
少なくとも自分にとっては、SREではない自分でも参加できるイベントではなく、SREではない自分だからこそ参加する意味のあるイベントでした。