こんにちは、アソビューでバックエンドエンジニアを担当しています、佐藤です。
Javaのアプリケーションをメインで開発をしています。
今回、Embedded SREという役割を任されることとなったインフラまわりにあまり詳しくなかった人間のお話になります。

Embedded SREとは

開発チームとSREチームの橋渡しの役割を担っており、
各開発チーム内に基本1名存在しています。

アソビューには、独立した専門のSREチームが存在します。
このチームは、複数ある開発チームを横断して、開発組織全体のさまざまな課題を解決しています。
しかし、SREチームが独立しているがゆえに、開発者の課題を深く理解して最適な解決策を見つけるのが難しい場面もありました。
また、開発チーム側からは、インフラやCI/CDの仕組みがブラックボックスになりやすい状態でもありました。

このような経緯でEmbedded SREが橋渡し役として存在しています。
一般的なEmbedded SREとは異なり、アソビューでは専任というわけではなく、開発者がEmbedded SREの役割を兼任します。

今回私はEmbedded SREを担当していたメンバーの異動により任命されることになりました。
アソビューは組織の変更が多いため、人の異動も多く、それにより新しいことにチャレンジできる、チャレンジすることになる機会が多いと思います。

お仕事紹介

SLOの週次チェック

アソビューではSLO、主にLatency、AvailabilityやUptimeに対して目標を定めています。チームごとにアプローチは異なるのですが、私のチームでは週次でミーティングを開催しています。 Embedded SRE（私）がバジェットの枯渇しているものを中心に事前に原因の詳細を調査・整理してチーム内に共有しています。

緊急で対応が必要なものはスプリントに差し込みですぐに対応するなどしています。

SRE定例会議への参加

週次でSREチームとEmbedded SREが参加するミーティングがあります。
各開発チームから集まり以下のような内容をSREチームと話しています。

SLOの枯渇状況の確認
通知されたエラーの共有、内容確認
開発からSREに確認事項・要望事項の確認
ESREとSREで実施しているタスクのUpdateの共有
SREから開発に展開していきたい事項の進め方の相談など

負荷テストの実施

アソビューには繁忙期というものが存在し、ゴールデンウィークと夏休みにトラフィックが大幅に増える傾向があります（遊びを提供するサービスなのでこれは納得です）。
この繁忙期に合わせて、負荷テストを実施しています。
SREチームとの連携を円滑に進めるため、自チームではEmbedded SREである私が負荷テストを担当しました。

SREチームと連携してテスト環境のインフラ構築、テストの実施をおこないました。

インフラの設定修正

横断的なインフラの設定変更などがあった場合にSREチームが方針や手順をまとめて実際の修正は各開発チームがおこなうことがあります。インフラの設定はTerraform、Helmでコード管理しているため主にこの修正となります。

失敗小話

以前IRSAへの対応というタスクがありました。
IRSAとは、AWSのIAMロールをKubernetesのサービスアカウントに紐付けることで、Podに最小限の権限を安全に付与し、AWSのリソースへアクセスできる仕組みです。以前はAWSのリソースへのアクセスのためのアクセスキーやシークレットキーをアプリケーション上のコード（propertiesファイル）に書いていたものを、このIRSAへの移行の対応で撲滅しました。これはSREチームで方針を決めて各チームで実施しました。

手順どおりにリリースを進めたつもりでしたが、実際には失敗してしまい、当初は原因もまったく分かりませんでした。
そこでSREチームと連携してミーティングを行い、一緒にログを詳しく確認した結果、原因を特定し、何とかリリースまでこぎつけることができました。
この経験を通じて、Kubernetesのイベントログ調査方法の勘所を学ぶことができました。

インフラまわりの知識が乏しく任命早々のタスクだったのですが、自分にとってSREチームからの協力がとても心強く学びの多い体験となりました。