はじめに
2024年10月にログラスのクラウド基盤チームで働いている中井 (elmo) です。
早いものでログラスに入社して、半年経ち、すこしずつ会社やチームにも馴染んできました。
私が所属するクラウド基盤チームは、各プロダクトのクラウドインフラの構築・運用を担っているチームです。
最近では、インフラ運用にとどまらず、SREとしてのプラクティス推進にも取り組み始めており、チームとしての活動の幅が広がってきています。
この辺りの背景やSREとして目指すべき将来像は、チームメンバーの見形さんが以下のブログで詳しく紹介してくれています。
興味のある方はぜひご覧ください！
一方で、クラウド基盤チームの仕事内容や将来像については、ブログやカジュアル面談を通じてある程度お伝えできていると感じる一方で、ログラスという組織でSREを実践する面白さについては、まだ十分に伝えきれていないのではないか、という課題感もありました。
そこで今回は、私自身がログラスでSREとして働く中で、どんなところに面白さを感じているのか、という視点にフォーカスしてご紹介します。
少しでもその魅力が伝われば幸いです！
クラウド基盤チームはどんなチームなのか？
まずは、クラウド基盤チームがどのようなチームなのか、その背景や現在地、そして少し先の展望について簡単に紹介します。
ログラスのクラウド基盤チームは、先述の通り、各プロダクトのクラウドインフラの構築・運用を行うことを目的で設立されました。
現在はメンバーも増え、SREの領域にも活動を広げています。
現状のクラウド基盤チームとプロダクト開発チームの関係を図にまとめてみました。
このように、現状のクラウド基盤チームは、クラウドインフラエンジニア と SRE を兼任しているようなチームになります。
- クラウドインフラエンジニアとしての活動 : 各プロダクトのインフラ構築・運用, CI/CDの整備
- SREとしての活動 : モニタリング・アラート整備, インシデントフロー整備, 各プロダクトや組織内のセキュリティ領域の強化
活動領域を広げることで、プロダクト開発チームの開発生産性の向上、プロダクトの信頼性の向上を支援していっています。
一方で、少し先の展望として、クラウドインフラエンジニアとしての活動(=プロダクトのインフラ構築・運用)を徐々に減らしていこうと考えています。
ログラスは2年間で10個の新規事業が立ち上げるという目標を掲げており、並行して様々なプロダクトが開発されています。
このような状況で、全てのプロダクトに対して、クラウド基盤チームがインフラ構築・運用を行うのはリソース的にも非常に厳しく、これまでのアプローチからやり方を変えていく必要があります。
なので、今後のクラウド基盤チームとしては、以下のような形を目指し、SREとしてプラットフォームの整備と信頼性担保のための活動を行っていきます。
- クラウド基盤チームが行っていたインフラの運用を各プロダクト開発チームへ委譲
- プロダクト開発チームがインフラの運用をしやすいように、クラウド基盤チームはプラットフォームの整備に注力する
ログラスでSREを実践する面白さ
ここからは、今回のブログの本題である「ログラスでSREを実践する面白さ」についてお伝えできればと思います。個人的には、以下の3つのポイントがあるかなと考えています。
- 自発的なメンバーとSRE文化を醸成していくことができる
- 様々なフェーズのプロダクトに関われる
- 技術的な守備範囲が広く、挑戦もしやすい
それぞれについて説明していきます。
自発的なメンバーとSRE文化を醸成していくことができる
ログラスには、課題を自分ごととして捉え、よりよくするために自発的に動ける人がとても多く在籍しています。
採用でも、職種に関係なく、困難な状況でも自ら考え、動ける姿勢を重視しており、自然とそのような人たちが集まる文化が形成されています。
この文化は、SREにとっても非常に面白いフィールドだと考えています。
SREの大きな役割の1つは、システムの信頼性を担保する文化を組織に醸成することです。
SREがいなくても、組織全体が自律的にシステムの信頼性を担保できるような状態を作っていくことが大事であると思っています。
ログラスでは、先述のように自発的なメンバーが多いため、組織全体でSREを実践するための土壌があると考えています。
実際に、最近もクラウド基盤チームからの小さな働きかけをきっかけに、プロダクト開発チーム側で主体的に改善が進んだ事例がいくつもあります。
-
OOMを起こしうるAPIエンドポイントの改善
クラウド基盤チームで不用意にメモリ量を使ってしまっているAPIエンドポイントを発見し、複数回叩かれると簡単にOOMを起こせてしまうので、改善して欲しいとSlackで伝えたところ、すぐさまレスポンスがきて対応者が決定。爆速で原因特定し、2日で修正が完了した。 -
アラート改善と整理
アラートの誤発火が頻発し、本来気づくべきアラートに気づかないという問題が発生した。これに対して開発チームのメンバーが自ら「改善したい」と手を挙げ、アラートの見直しがスタートした。すぐさまクラウド基盤チームに相談を投げかけ、アラートの考え方の共有や都度軽い相談を行った結果、実践的な改善が進んだ。
このように組織の全員が自発して動く土壌があるため、SREが一方的に主導するのではなく、開発者や時にはビジネス職とも連携して信頼性文化を育てていけることが、ログラスのSREの面白さだと感じています。
様々なフェーズのプロダクトに関われる
現状のログラスには、様々なフェーズのプロダクトが同時並行で存在しています。
- PMFしたプロダクト
- 新規事業としてリリースはされ、PMFに向けて走っているプロダクト
- 新規事業としてこれから立ち上がるプロダクト
このような環境では、求められる信頼性や向き合う課題が、プロダクトのフェーズによって異なるため、SREとしては面白い環境なのではないかと考えています。
すごく簡単な例で恐縮ですが、監視/Observabilityという分野ひとつとっても、プロダクトの状態によってアプローチは大きく変わります。
- PMFしたプロダクトの場合
- ある程度アラートの整備が完了しているが、顧客影響を気にしすぎるあまり、全てのエラーやレイテンシ悪化に反応してしまっていて、疲弊してしまっている課題がある
- 適切なレベルでアラートの対応ができるように、SLI/SLOを整備していこう
- 新規事業としてリリースはされ、PMFに向けて走っているプロダクトの場合
- そもそもPMFするかわからないし、フル装備の監視体制はまだ早い
- なので、必要最低限のアラートを作っておき、運用しながら必要なアラートを取捨選択をしていく柔軟さが求められる
このようにプロダクトのフェーズに合わせて、どこまでの信頼性を目指すかを都度考えることが、SREの重要な役割だと思っています。
1つの組織にいながら、複数フェーズのプロダクトでのSREを実践できるというのは、2年で10個の事業を作るという挑戦をしているログラスならではの魅力です。
技術的な守備範囲が広く、挑戦もしやすい
先述した見形さんのブログにて、以下の図のように5本柱でSREプラクティスを推進していくという話がありました。
組織全体がこれらの改善を自発的にできるように、SREがリードしていくことから、
SREはこれらの領域に関して、組織の誰よりも詳しくなる必要があると考えています。
そして、クラウド基盤チームの紹介のセクションで先述したように、これらを推進しやすくするように、プラットフォームの整備にも注力していく(=Platform Engineeringを推進していく)必要があり、SRE組織の守備範囲はかなり広くなることが想定されます。
ただ、私を含めて、今のクラウド基盤チームのメンバー全員が上記の領域に詳しいわけではなく、やっていきながら、学んでいけばいいと考えています。
私自身、経験したことがない領域にこれから挑戦できるのはすごく楽しみにしています。
また、会社としてもFail Fastという早く挑戦し失敗から学ぶ文化を推進しており、(最低限、なぜやりたいか/どのような効果があるのか説明は必要ですが)、手を挙げれば、技術的な挑戦ができる体制が整っていることも魅力の1つです。
まとめ
今回のブログでは、ログラスのクラウド基盤チームについて、ログラスでSREを推進していく上で、魅力に感じている点をまとめてみました。
私自身、魅力に感じている部分が多いものの、現状のログラスで信頼性担保の文化作りをしていくには、本当にまだまだやらないといけないことが多いです。
事実、この半年間働いて、「なんでこんな運用になっているの？」と疑問視する部分もかなり多く、どうにかできないかなと何度も思うこともありました。
ただ、これは組織が急成長する上で、仕方なかった選択肢なのかなと思い、現実を受け止めて、これから、負債解消や文化醸成に取り組んでいければと考えています！
We Are Hiring!
ログラスでは一緒に働くエンジニアを大募集中です！興味をもっていただいた方はカジュアル面談でぜひお話ししましょう！
Discussion