SREとして入社して半年経った感想

はじめまして、2023年4月にGO株式会社に入社した浜地といいます。SREとしてJOINし、GOアプリに関連するインフラ周りの構築・運用・改善まわりを担当しています。

時が経つのは早いもので、入社後半年が経過しました。この半年間で得られたことなどをまとめ、弊社のSREがどういう環境なのかをお伝えできればなと思っています。

入社のきっかけ

前職在職中に、以前の同僚（エンジニア）から声をかけていただいたことがきっかけでした。開発環境の状況を聞いているうちに、「自分のバリューを提供できそうだ」と思ったことで選考を進める決意をしました。

詳しくは以下の記事にまとまっていますので、ご興味のある方はこちらもご覧いただけますと幸いです。

技術とカルチャーがマッチ。「エンジニア×リファラル採用」の良さとは？【GO リファラルストーリー Vol.4】https://go-on.goinc.jp/n/ne9e9ec3abfdc

オンボーディング

GOではマイクロサービスアーキテクチャを採用していることもあり、SREのオンボーディングは「1つのアプリケーションのインフラを構築してデプロイする」という実技オンボーディングでした。おそらく今後もこの内容でオンボーディングが進められると思います。

オンボーディング用サンプルアプリケーションはGo言語で書かれています。自分はアプリケーションコードのコーディングが久々だったので最初手間取りましたが、下記にも記載する標準化されたアプリケーションコードはボイラープレートによって大半が生成される仕組みになっているため、実稼働中のアプリケーションの構成を把握することができるよいオンボーディングだと思いました。今でもオンボーディング後のアプリケーション構築もオンボーディング時の設定を参考にするケースも多々あります。

インフラのことだけではなくアプリケーションコードも学べるよいオンボーディングです。

技術スタック

以前の記事にて、会社の標準技術スタックについて解説された記事があります。

MoTのSREグループが社内に提供している標準技術スタックを紹介 https://lab.mo-t.com/blog/mot-tech-stack-standard

基本的にはほとんどがこの記事どおりの技術スタックが維持されていますが、モニタリング周りについてはNewRelicからGrafanaに変更されています。

LGTM！オブザーバビリティ基盤第1話 https://lab.mo-t.com/blog/grafana

ただし、これはあくまで標準化のための技術スタックであるため、標準化前に作成されたものなどをはじめこの記事には記載されていないものが利用されています。

とくにGOアプリは、JapanTaxiとMOVの事業統合によって生まれた事業であり、過去のシステムを一部引き継いで運用し続けているものがあるため、例えばGAEやKenos（後述）未対応のGKEが引き続き利用されていたりします。

これらの標準化から外れた技術をそのままずっと運用し続けなければならない状態かというとそうではありません。各事業と協調しながら徐々に古いものを捨てて新しいものへと置き換えている最中で、最終的にはすべてのシステムが標準化されたものになるだろうという見込みです。

弊社での技術スタックで特に注目すべきは、非機能要件の標準化・共通化のために作られたKubernetesのラッパーである「Kenos」です。Kenosによって初期構築・デプロイ・モニタリングが統一された規則によって設定されるため、少ない意識で実現されています。Kenosの概要については下記のスライドや発表をご参照下さい。

タクシーアプリ「GO」の少人数SREチームとマイクロサービス基盤【DeNA TechCon 2023】https://speakerdeck.com/mot_techtalk/sre-micro-service

実際に利用したところ、多くの設定箇所が共通化されるためPure Kubernetesを利用したときに比べて圧倒的に記述量が減ったと感じます。これについてはよくYAML職人と冗談交じりに言われますが、Kenosにおいてはその苦痛はとくに感じませんでした。

また、最近の傾向として弊社ではデータベースエンジンとしてPostgreSQLを採用する傾向が強いです。GOアプリの極めて重要なシステムでもPostgreSQLが導入されており、大規模リクエストのある環境でも運用されています。そういった中で発生するオペレーションやトラブルは貴重な情報で、PostgreSQLは自分のキャリアではほとんど触れる機会がなかった自分にとってはとてもありがたく、書籍の情報や運用内容と比較しつつPostgreSQLについて日々学べています。

働き方

SREチームは基本的にフルリモートで勤務しています。特別に用事がなければ出社はしていません。つい先日、麻布台ヒルズにオフィス移転しましたが、この記事を書いている段階ではまだ出社しておらず、移転後のオフィスがどうなっているか未だにワクワクしています。

移転前のオフィスの話になりますが、開発部門の席はフリーアドレス制になっているため、出社した場合は好きな席で作業することができます。

定常業務として、毎日11時からタスク進捗確認があり、週1回チーム内共有会、チーム外共有会がそれぞれ開かれています。

チーム内共有会ではGrafanaのデータやアラートを元に各マイクロサービスのリクエスト頻度やレスポンスタイム、エラー率、アラート回数といったSLIを確認する場が設けられているため、アラートのオオカミ少年化を防止したりシステム障害の事前予防などすることができます。

SREグループの定例ミーティングでやっていること https://lab.mo-t.com/blog/sre-weekly-meeting

少し話が逸れますが、アラートのオオカミ少年化を防ぐことはSREだけでなくアプリケーションエンジニアも意識されています。発生したエラーの対応や原因不明のエラーを解明することに協力的なアプリケーションエンジニアが多く、とてもリスペクトしています。

また、KubernetesやIstioを採用していることから、アップグレード作業を数ヶ月おきに当番制で実施しています。他にも開発に利用するシステムの権限の申請の対応も当番制で対応しています。

上述の定例等は当然いろんな開発現場で実施されているため、メンバー間での仕事の話は十分にできるが、メンバー間での雑談をする機会が少ない、という現場も少なくないと考えています。我々のチームでは、1週間に1回のペースでメンバー間総当り方式の1on1を実施しており、雑談やプライベートな話などをメインに会話する会が設けられています。他メンバーの考え方や背景を理解する重要な機会で、これによって円滑にコミュニケーションが進んでいると感じます。おすすめの施策です。

これからやりたいこと

半年間SREとして働いてきたなかで苦労した点が「各作業プロセスにおいて作業しなければならないことの量が多い」ということで、「何をしなければならないか」「どういう順序でしなければならないか」の理解に膨大な時間を費やしてしまいました。

これは上述の統合による影響も少なからずあるため仕方のないところはありますが、各メンバーの負担や抜け漏れによるトラブルをできるだけ減らしたいと感じました。とくに自分は作業ミスを起こしやすい人間であると自覚があるため、複雑な工程の環境は苦手だと感じています。プロセスを見直したり、簡易的なプロセスにするために現状の状態を変更したりすることを今後の目標として活動したいです。今後入ってくるSREから「この作業はとくに苦痛に感じなかった」と言われるような環境を目指してがんばります。

We're Hiring!

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @goinc_techtalk のフォローもよろしくお願いします！