SRE入門編 SREとは何か？コア技術と日本における事例
DevOpsを具現化する取り組みであるSRE（Site Reliability Engineering）への注目が高まっています。
この記事では、そもそもSREとは何か？それを支える技術とは？日本における事例とは？について、解説します。
目次
SREとは何か？
SREを一言で表すと「ソフトウェアエンジニアリングを軸に、フルスタックの迅速な継続的改善を、組織ぐるみ・組織横断で実現し続けること」です。
2016年、O’Reilly Mediaから書籍「Site Reliability Engineering」が発売され、SREの考え方が世に広く紹介されました。
本書は、GoogleにおけるSRE（Site Reliability Engineering）とSREs（Site Reliability Engineers）の取り組みをまとめた書籍で、巷では「SRE本」と呼ばれています（日本語訳である「SRE サイト リライアビリティ エンジニアリング―Googleの信頼性を支えるエンジニアリングチーム」は翌2017年発売）。
Googleは「class SRE implements DevOps」とも言っており、SREはDevOpsの実践スタイルのひとつといえます。
この「SRE本」で語られるSREは、結構過激です。
●モチベーション：
複雑で大規模なコンピュータシステムを運用する際、システムの成長・拡大に比例してOps（運用系エンジニア）がどんどん増えていかないようにしたい
●コンセプト：
ソフトウェアエンジニアリングで、運用を再定義する
●コアプラクティス：
伝統的オペレーションを行うOpsを全廃する。そのために…
- ソフトウェアエンジニアがソフトウェアエンジニアリングを用いて伝統的オペレーション*を破壊・再定義・置換する
- 実現のために会社が、SREを支持・支援する
*伝統的オペレーション･･･手作業など、システムの成長・拡大に比例して手間や量が増える手法のこと。Sysadminアプローチとも呼ばれる
システム運用において、ソフトウェアエンジニアリングを用いて課題解決する取り組みは2000年代後半ごろから数多く登場していましたが、SREはこの取り組みを強く全面に打ち出して名前をつけたことから、「概念」として一気に広まりました。
「SRE本」が示すSREは、テクニカル・現場レベルだけに留まらず、組織構造や人事・評価制度も含めた、包括的なアプローチを含むエンジニアリングをスコープにしています。
SREの軸はソフトウェアエンジニアリング
SRE（Site Reliability Engineering）は、ソフトウェアエンジニアがソフトウェアエンジニアリングすることが軸になっており、大前提です。
これはソフトウェアのもつ特性＝処理の再現性がある、複製できる、常時待機し即時稼働できる、複製しスケールできる、指定したとおりに動作する、といった点が、システム運用において効果的に作用するためです。
SREs（Site Reliability Engineers）は、自分自身でソフトウェアエンジニアリングを為します。解決すべき課題を確定し、ソフトウェアエンジニアリング能力を前提として課題を解決する方法を検討し、ソフトウェアで解決するのであればアーキテクチャを設計し、プログラムを実装し、継続的に改善します。
SREsは「ソフトウェアエンジニアリングを一気通貫で為せる」からこそ、迅速に適切な試行錯誤ができるのです。
「自分は設計だけ行い、プログラミングは他の人に委託する」のでは、高い効果が得られません。
コアプラクティスを支える技術：モニタリング
SREのコアプラクティスは、前述のとおり以下です。
- ソフトウェアエンジニアがソフトウェアエンジニアリングを用いて伝統的オペレーションを破壊・再定義・置換する
- 実現のために会社がSREを支持・支援する
これらを適切に成すためには多くの意思決定が必要で、意思決定の判断材料として、定性的な指標と定量的な指標が必要です（システム運用は人間の営みですので、定性的な指標は外せません）。
とはいえ、現代は変化が早く予測が困難なため、定量的な指標を適切に扱うことが重要になります。この定量的な指標を獲得する技術が、モニタリングです。
SREの取り組みでのモニタリング対象は、多岐にわたります。ほんの一例ですが、以下のような指標があります。
- システムリソースメトリクス
- CPU利用率
- トラフィック
- ディスク使用量
- サービスメトリクス
- アクセス数
- ログインユーザ数
- ビジネスメトリクス
- 売上高
- 解約数
- 問い合わせ数
- 問い合わせ〜初回回答所要時間
- 初回回答〜close所要時間
- アプリケーションプロファイル
- 呼び出し回数
- 所要時間
- アプリケーションスタッツ
- 静的解析結果
- 自動テスト結果
- コード量
- 開発者体験
- 自動テスト所要時間
- プルリクエスト作成〜マージ所要時間
テクニカルな指標だけでなく、システムを運営しユーザに価値を提供するために、さまざまな観点のデータを取得し活用します。
日本におけるSRE事例
日本ではメルカリがEarly Adoperで、2015年にSREチームの取り組みを紹介しました。2016年以降は、Webサービス提供会社を中心に、SRE職を設ける会社が増えてきました。
日本では伝統的オペレーションによって解決する課題を担当していたのがインフラエンジニアであったことが多いため、もともとのフェーズによる区分け（Dev/Ops）ではなく、レイヤによる区分け（アプリケーションエンジニア/インフラエンジニア）で語られることが多いです。
近年、SREを冠した採用活動が活発となっていますが、各社難航しているようです。
その理由は、2000年代までインフラ領域はSysadminアプローチが主流であったことから、インフラ領域に知見がある中堅〜ベテランのソフトウェアエンジニアが少なく、それに伴って育成が難しい、という背景があるようです。
まとめ
SREを一言で表すと「ソフトウェアエンジニアリングを軸に、フルスタックの迅速な継続的改善を、組織ぐるみ・組織横断で実現し続けること」。
そのためにソフトウェアエンジニアがソフトウェアエンジニアリングでシステム運用を再定義し実現する。
SREはDevOpsの実践スタイルのひとつ。
SREsは、SREを実践するエンジニアのこと（日本では一括りにSREとされることもある）。
【追記】更新版を公開しました！
[2023年夏版] SRE入門編 SRE とは何か？コア技術と日本における事例や課題
＞関連記事
- DevOpsについて基本を知りたい方→DevOps入門編
- SREについて実践的な話を知りたい方→SRE実践編
[PR] X-Tech5のSREサービスで『今日より、一歩前へ』
SREに取り組み始めたいものの、いまいち最初の一歩が難しいなぁという場合は、弊社X-Tech5のSREサービスをご検討ください。
まずは無料相談から！。直接ご支援・相談できます。
弊社エンジニアがSREとしてチームに参加し、チームの一員として動きSREを実現します。
