日本企業のSRE事例と成功への3つのポイント

nwiizo

2021.10.1

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チームの立ち上げはもちろん、改善すべき運用部分の選定もお手伝いさせていただきます。

ぜひ一度お問い合わせください。