SRE（Site Reliability Engineer）と聞くと、まだ身近に感じることができず「海外の大企業が取り入れているサービス運用方法」と考えている方も多いかと存じます。確かにGoogleやNetflix、Amazonといった海外の大企業の導入事例が取り挙げられることが多く、そう感じてしまうのも仕方無いのかもしれません。
しかし2016年頃から、日本国内の企業においてもSREの導入は急速に広まっています。本記事では「日本企業でSREをうまく取り入れた事例をもとに、成功するためのポイントを3つ紹介」いたします。よりSREを身近に感じられるよう解説していきますので、最後までお付き合いください。
関連記事：SREとインフラエンジニアの違いを3つのポイントで理解する
SREを実施した国内企業の事例
以下、日本国内企業でSREを導入した事例を3つ紹介していきます。自分の会社に照らし合わせながら見ることで、よりSRE導入が具体化するのではないでしょうか。
株式会社メルカリ
フリマアプリとして国内で根強い人気を誇るメルカリ。個人間でのやり取りが頻繁に発生するアプリのため、ダウンタイムの削減を目的として2015年、SREの導入に踏み切りました。
当初は「メルカリ」の信頼性向上を目的として作られたため、主な作業範囲は以下のように限定的でした。
- APIサーバ、ミドルウェアの可用性の維持・向上
- APIサーバ、ミドルウェアのパフォーマンスの向上
- ログ収集・分析基盤の構築、運用
- サーバプロビジョニング・デプロイの整備
- セキュリティの担保
- 開発環境などの整備
サービスの発展にSREチームは大きく貢献していたものの、2018年から「メルカリ」のマイクロサービス化や決済サービスの「メルペイ」の運用開始に伴い、当初のチーム編成および作業領域ではカバーできない領域が生まれてきました。
そこで、メルカリ・メルペイを横断した基盤チームの再編を行い、見事SREチームを復活させました。具体的には「マイクロサービスSRE：各チームに運用上のオーナーシップ制」と「エンベデッドSRE：職能横断的なプロダクトチームの一員として品質改善に取り組む」を発足することで、チームを横断した管理体制と信頼性の向上、品質改善を可能にしました。
参考：インフラチーム改め Site Reliability Engineering (SRE) チームになりました
株式会社エウレカ
マッチングアプリ「pairs」を運営する株式会社エウレカも、運用品質改善の為にSREを導入している企業のひとつです。エウレカのSREチームの発足は2016年、技術基盤チームとインフラチームが融合したことで生まれました。
SREチームを発足する際にチームの存在意義と課題感を考えることで、意味のあるSREチームを構成することから始まりました。
- 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす
- ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する
- 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する
- 適切なキャパシティプランニングを行い、利益率向上へ寄与する
- 顧客価値提供を最速化するためのリリースエコシステムの改善と安定化を行う
- 事業価値最大化にむけた施策の技術サポートを行う
また、具体的な取組みも明確化させました。
- SLO/SLIの定義
- 全サービスへのIaC (Infrastructure as Code) の適用
- VM→コンテナへの移行
- サブシステム・関連システムのサーバーレス化
- クエリ修正・コード修正（サーバー負荷軽減目的）
- トラフィックのスケーラビリティ確保
- Datadogによる監視・モニタリング
- ポストモーテム文化の醸成
- 障害対応のフロー構築
- リード・テンプレートの作成
- 障害チケット発行からのスタッフ招集の仕組み
上記の業務に取り組みますが、結果として「業務範囲が広がりすぎて注力できない」「SREチームに責務が集中しすぎる」といった問題が起こりました。もう一度「SREのエッセンスを大事にしつつ、常に変化・改善し続けること」を見直しています。
- どういう価値を企業に提供するのか？の再定義
- リソース配分に一定のポリシーを持つ（後述する50%ルールの採用）
- やらないことの定義
決して過去のSREが間違っていたわけではなくプロダクトのフェーズによって常に変化し続けること、そのために定期的にSREの見直しをかけることに目を向け、SREチームのあるべき姿を模索し続けています。
参考：エウレカ SREチームの2021年までの取り組みとこれから
株式会社ヌーラボ
プロジェクト管理ツール「Backlog」や、ビジュアルコラボレーションツール「Cacoo」などを開発・販売するIT企業である株式会社ヌーラボもSREを導入している企業のひとつです。
ヌーラボにおけるSREの始まりは、2015年にインフラ専任のエンジニアが入社したことがきっかけでした。
- SREを開発チーム所属にするか、開発チームとは別のSREチーム所属にするか？
- SREをプロダクトチーム所属にするか、全プロダクト共通のチーム所属にするか？
当初は上記のような悩みを抱えながら試行錯誤した末、「各サービスを開発する課」とは独立した形で「SRE課」が発足されました。この体制は自らが担当するプロダクトを抱えながらも他チームとも横断的に連携することを目的として作られました。
SREチームとプロダクト開発チームが分かれていることで、各プロダクトの詳細が追えなくなるという問題を解決するために、定期的な問題点の共有・進捗共有を行う場を設けているのもヌーラボのSREの特徴を言えるでしょう。
- スケーラビリティ：Amazon ESの機能で、無停止でのスケールアップ・スケールアウトが可能になった
- 可用性：インデックスファイルの同期がなくなり、インデックス更新の遅延・失敗が起こらなくなった。3 AZで冗長化されて、耐障害性が向上した
- ハードウェアコスト：AZ間通信、および巨大なEBSボリュームの費用が削減された（50万円〜/月の削減）
- 運用コスト：インデックスファイルの破損・同期失敗が起こらなくなり、サポートチームとSREの稼働が減った
定期的なミーティングと棚卸を行いながらSREによる業務改善に成功したヌーラボは、結果としてスムーズな新サービスの追加やマイクロサービス化に成功しています。
参考：ヌーラボのSREは歴史の長いプロダクトをどのように改善しているか？
SRE導入を成功させるための3つのポイント
- Googleが提唱するSREの概念を理解する
- 常にSREのあるべき姿を模索し変化し続ける
- 技術的な取組みと組織としてのあり方の両方を意識する
先に挙げたSRE導入に成功している企業3社に共通することは、Googleが提唱しているSREの概念を理解しつつ、自社の状況やプロダクトのフェーズにあわせて常にSREのあるべき姿を変化させていることです。「SREはこうでなくてはいけない」という固定概念にとらわれず、常に柔軟に変化する意識を持つと良いでしょう。
また、SREを実装するうえで技術的な要素はもちろん大切ですが、SREの組織として「どのようにすればうまく状況が共有されるのか」「どのようにすれば横断的な運用管理ができるのか」を考えて行動することも大切です。技術のみに囚われすぎず、定期的なミーティングや組織体制の見直しを行うことで、より良い体制作りができるのではないでしょうか。
SREの導入から改善まで弊社にお任せください
SREの事例や情報は少なく、導入のハードルが下がったとは言いにくいのが現状です。「サービスの信頼性を保つために、可能な限り運用を自動化し可用性を上げる」というGoogleが提唱するSREの概念が浸透してもなお、実際にどのようなスキルと人員、体制をもって実装に落とし込めば良いのかわからないというケースが多いようです。
もし貴社が、社内のエンジニアリソースを活用して、SREチームの立ち上げを検討しているのであれば、当社がご支援させていただきます。SREチームの立ち上げはもちろん、改善すべき運用部分の選定もお手伝いさせていただきます。
ぜひ一度お問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。