【フォースタテックブログ】SREエンジニアとして入って一ヶ月でやったこととこれからやりたいこと

最近焼酎の美味しさに目覚めた、テックラボSREチームの @tossy_yukky です。
フォースタートアップス（以下フォースタ）初のSREポジションとして、今年の6月にジョインしました。
経歴としては、SES > Web広告系企業でインフラ周りをやりつつ新規サービス立ち上げを何個か > マッチングサービスやECサービスでなんでも屋さん、からのフォースタジョインとなります。

今回は、半沢直樹でも「SREチーム呼んで！」で話題になった、SREという立場・業務内容の紹介をすると同時に、社内での立ち位置も明確にしておこうという、一石二鳥を狙っていきます。

SREとは

『SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム』
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田武男、関根達夫、細川一茂、矢吹大輔　監訳、Sky株式会社玉川竜司　訳
https://www.oreilly.co.jp/books/9784873117911/

まずはここからです。
昨今では知名度も高いので、これがSite Reliability Engineering（サイト信頼性エンジニアリング）の略であることを知っている方も多いのではないでしょうか。
そしてこれは同時にSite Reliability Engineerの略でもあります。

それではサイト信頼性とはどういうことでしょう。

ITサービスは、サーバやネットワークなどのインフラ部分があり、サービスで使う＆貯めるデータがあり、その上で動くアプリケーションがあります。
それらのどれかに問題があれば、ユーザにとっては満足にサービスを利用することができないでしょう。

そうならないための全てのことを行うのがSRE、というわけです。

一般的に SRE＝インフラ担当 のように思われている節があるのも事実ですが、有名なSRE本によれば、SREチームの50％ほどはソフトウェアエンジニアであり、SRE業務のうちでも50％は開発業務である、とあります。
機能開発そのものではないですが、バグの改修からログ出力、アラートの仕組み、CI / CD、パフォーマンスチューニングまで、とても単なるインフラ担当とは言えないほどの業務範囲です。

加えて、サービスにはそれを作る人・運用する人もいます。
その人達の組織がうまく回っていなければ、サイト（サービス）の信頼性を損なうことにもつながりかねません。
つまり、開発・運用組織というシステムに対する設計 / 実装 / 運用も、SREの業務には含まれていると言えます。

まとめると、SREとは「サービスを利用することができる状態を維持し続けるために必要な全てのシステムを理想的な状態に持っていく」仕事、ということになります。

フォースタでのSRE

それを踏まえて、フォースタでの具体的なSRE業務を挙げてみましょう。

フォースタには、社内で利用されるタレントエージェンシー支援システム（SFA/CRM）と、社外に向けた国内の成長産業領域に特化した情報プラットフォーム「STARTUP DB」の2つのサービスがあり、それぞれに開発チームがいます。
どちらのチームもサーバサイドエンジニア、フロントエンドエンジニア、デザイナーなど含め4〜6名ほどの規模です。

ただインフラに関してはCTOの戸村（@KenjiTomura）が中心となり、色々な人が都度対応という形で、
メイン業務としてインフラだけを担当する人はいませんでした。
なので、実際問題として現在、フォースタでのSREのメイン業務はインフラ周りということにはなります（いきなり前節で言っていたことをひっくり返すようですが）。

そしてエンジニア組織として。
フォースタはスタートアップ企業に対して支援を行っていますが、フォースタ自身も上場こそしているものの、母体であるウィルグループから分社して4年程、まだまだ組織として成熟しているとは言えないのが現状です。
エンジニアの人数も、正社員だけで言えばCTOを含めて6人。
組織というシステムに対して、制度、仕組み、文化、どれもこれから醸成していく必要があります。

ジョインしてからやったこと

ここでは、私がフォースタにジョインしてからおよそ2ヶ月の間にやってきたことを並べてみます。

Infrastructure as Code

まずはインフラっぽいところ。
フォースタではサービスが大きく2つあるというのを前述しましたが、開発自体はマイクロサービス化が進んできており、管理すべきリソースはもっと多いです。
なので、それらを全てコンソールから管理するのも辛いということで、Terraformを用いたInfrastructure as Code(以下、IaC)化を進めました。
既にいくらかはTerraformのコード化されているリソースもあり、Github / Circle CI / Terraform Cloudを連携させてplanコマンドの出力をブラウザ上で確認できるような仕組みはできていました。その基盤に対して、まだコード化されていないリソースをひたすらimportしていくという作業になります。

Terraform公式のimportだけでは作業量がとんでもないことになっていたので、最初はOSSのterraforming( https://github.com/dtan4/terraforming )を使おうとしていたんですが、これも対象となるリソースの種類が足りず、GoogleのOSSであるterraformer( https://github.com/GoogleCloudPlatform/terraformer )を利用して作業を進めました。
ただ、これもtfstateがTerraform Cloudにある場合が考慮されていなかったため、TypeScriptでterraformerでのimport > ファイル整理しつつterraform importまでを行うツールを自作しています。

監視・アラート

SREの業務を行うに辺り、指針となるSLI（Service Level Indicator）、SLO（Service Level Objective）を設定する必要があります。
これはそのサイト（サービス）がユーザに対して「どの程度使われているか」「どの程度満足に使ってもらえているか」を見るもので、SLIは何を軸として見るか、SLOはそれがどれくらいの値であればいいのか、を示しています。

以前はインフラリソース単位でのメトリクス（CPU使用率、メモリ使用率、ディスク使用率、Load Averageなど）は取得していたものの、それぞれがユーザに対してどういった影響が出ているのかわかりにくいため、SRE本を参考に新たな指標を作ってみました。

ツールとしては、フォースタでは基本的にインフラは全てAWSで構築していることもあり、一旦Amazon CloudWatch上のダッシュボードを使います。単純に他の監視サービスを別に使うよりは料金も安く、取得期間も長いという理由です。
指標としては、Golden Signalsと呼ばれるメトリクスがそれに当たります。これはレイテンシ / エラー(5xx数） / トラフィック / サチュレーションの4つなんですが、サチュレーションに関しては一旦外しています。理由としては、サチュレーションの対象となるリソースを選定するのがまだ難しかったというのがあります。
一方でアラートに関してもそのGolden Signalsを基に見直しを行いました。
夜中に起こされる理由として、CPU使用率が90％であることではなく、500エラーが大量に起こっているという方が納得感もありますし、より緊急度が高いはずだからです。

ポストモーテム

こちらもSRE本からになりますが、インシデントが起こった際、その振り返りを行うためにポストモーテムを導入しました。
単なる障害報告と言ってしまえばそうかもしれませんが、ポストモーテムの価値は、これを使って開発者全員が認識を合わせること、他のチームの障害だからで済ませず自分事として捉えられるようにすることだと思っています。

具体的な内容で言うと、報告書のフォーマット、インシデントの報告基準、報告書のレビューを行うにあたっての仕組み作り、がそれに当たります。

この辺りは、エンジニアというよりは半分マネジメントに近いものがある気がします。