開発の現場において「SRE」というワードを聞いたことはないでしょうか。よく耳にはするものの、「詳しく説明はできない」「DevOpsとの違いが分からない」という人は多いかもしれません。

本記事では、SREの基本的な知識を解説するとともに、DevOpsとの違いやSRE導入によるメリットなどを紹介します。

SRE（Site Reliability Engineering）とは

SREはSite Reliability Engineeringの略で、日本語では「サイト信頼性エンジニアリング」と訳します。SREとは、Googleが提唱したシステム管理とサービス運用のアプローチ方法を指します。

GoogleエンジニアリングチームのBen Treynor氏によって提唱されたSREの最大の特徴は、「システムの信頼性」を重要視している点が特徴です。

従来は、開発段階ではサービス運用の視点が二の次になっていることが多く、リリースまでのスピードを重視するあまり運用工程の業務量が膨大になってしまう点が課題でした。さらに、運用工程ではほとんどの作業が手作業となっており、属人化によるトラブルが発生することも珍しくなかったのです。

そこでGoogleでは、スピーディーなリリースによってサービスの利便性を担保するのはもちろん、「安定性」もシステムの価値と捉え、それらを総合的に向上するための手法としてSREを提唱しました。

SREに重要な三つの指標

SREでは、「一切トラブルが無く、信頼性が100％のシステムは存在しない」という点を大前提として、信頼性をより高めるために必要な指標として以下の三つが定義されています。

1.SLO（Service Level Objective）

SLOは「サービスレベル目標」です。SLIで計測される値の目標値を指します。そのサービスが目的を実行できているかどうかを計るために設定する目標です。サービス提供者が自己評価や品質向上のために設定する内部指標であり、外部には公開されないことがほとんどです。

2.SLA（Service Level Agreement）

SLAは「サービスレベル契約」で、サービス提供者とクライアント間で交わされるサービスレベルに関する合意のことです。SLAを達成できなかった場合は、返金や減額などに対応する必要があります。

3.SLI（Service Level Indicator）

SLIは「サービスレベル指標」を指します。サービスのパフォーマンスを定量的に測定したもので、サーバーの稼働率やエラー率などが含まれます。例えば「99.9%の稼働時間」や「100ミリ秒以内の応答時間」など、具体的な数値が目標値をどれくらい満たしているかを判断する指標です。

SREで実現できること

ここでは、SREを導入することで実現できることやメリットについて解説します。

運用の安定性の向上

SRE導入による最も大きなメリットは、運用の安定性が高くなることです。SREは運用時における作業の自動化を推奨しているため、これまで手作業で行っていたことで生じていた人為的なミスやエラー、不具合の発生率を大きく減らすことができます。

またSLIにより、サービスのパフォーマンスを常時監視できるため、エラーを事前に察知したり、新機能リリース直後の初期不良などを察知したりしやすく、迅速な対応が可能となります。

運用工程の効率化

先ほども述べた通り、SREは運用作業の自動化を推奨しているため、運用作業の効率化やスピードアップに貢献します。運用作業に充てる時間を短縮化できるため、運用チームは空いた時間で運用方法の設計・構築業務に取り組むことができ、さらなる効率化が実現します。

運用タスクの属人化回避

従来の開発方法では運用工程を手作業で行うケースが多く、安定したサービス運用を行うためには優秀な人材を確保する必要がありました。

SREにより運用作業を自動化すれば、誰でも実行することができ、そのノウハウは組織内で横展開することも可能です。誰が作業をしても同じアウトプットが出せることで、サービスの安定性を高めることにも貢献します。

システム開発・アジリティーの向上

運用作業の効率化・標準化が進むことで、開発からサービスリリースまでのスピードが格段に上がります。それにより新たな機能追加にも着手しやすく、サービスのアジリティー向上に寄与することは間違いありません。

頻繁にリリースを行うことは開発チームと運用チームのコミュニケーション量の増加にもつながります。それにより両者の連携はさらにスムーズになり、サービスの価値向上やさらなるスピードアップにも直結するでしょう。

SREが昨今注目されている背景

SREが注目されるようになった大きな要因は、アジャイル開発が一般化してきた点にあります。ウォーターフォール開発と比較して、アジャイル開発は柔軟でスピーディーな開発を得意とします。一方、効率化を重視することで、安定性の低下などシステムとして価値が損なわれる危険性もありました。

このような背景から、開発スピードだけでなくシステムの品質を向上するアプローチ方法の一つとして、SREへの注目度が高まっているのです。

SREとDevOpsとの違い

SREと混同されやすい方法の一つにDevOpsがあります。DevOpsは「開発（Development）」と「運用（Operations）」を組み合わせた言葉であり、開発チームと運用チームが連携を行うという点でSREと共通しています。どちらも標準化・自動化を推奨しており、使用するツールも似るため違いが分かりづらい印象を受けますが、実は両者は目的が異なります。

SREの主目的は「開発者と運用者が連携することで、高い信頼性のもとサイトやシステムの安定稼働を目指す」こと。一方でDevOpsの主目的は「開発者と運用者が連携することで、リリースサイクルの短縮化を目指す」ことです。どちらかというと。SREはサービス運用者寄り、DevOpsはサービス開発者寄りのアプローチ方法といえるでしょう。

SREを提唱したGoogleは「class SRE implements DevOps（SREはDevOpsというinterfaceの実装である）」と述べており、「DevOpsを実現するための一つの方法がSREである」という考え方が一般的です。

SREチームの役割

多くの企業やプロジェクトでは、SREエンジニアは数人がチームを組んで業務にあたります。SREチームの業務範囲には運用面だけでなく開発面も含まれるのが特徴で、運用チーム、開発チーム双方の舵取り役として機能するのがSREの主なミッションです。SREチームがどのような業務を行うかを以下で詳しく解説します。

新機能の開発・運用のサポート

SREの主な目的は「システムの信頼性を向上すること」にあるため、運用面に焦点が当たることが多いですが、実際は開発面における比率が多いのが特徴です。Googleが提唱する「SREのベストプラクティス」によると、SREエンジニアが運用業務に充てられる時間は最大50％とされており、その他の時間は新機能の作成や自動化の実装など開発業務に割り当てることと定義されています。

エラーやトラブル発生時に適用するパッチを準備するのもSREチームの業務範囲です。もちろん、その際も運用面を考慮した開発を行う必要があります。

運用業務の環境整備

SREの目的である「安定性向上」のためには、運用業務の環境整備は欠かせません。SLIを計測してSLOを設定する、モニタリング出力方法を検討する、トラブル発生時のマニュアルや予防策の作成などもこの作業に含まれます。SREチームには、トラブルが発生しにくい環境づくりや、不具合を早急に検知しスピーディーに対応できるような仕組みづくりが求められるのです。

システムの自動化

サービスの安定稼働には「ミスの起こりにくい環境」が必要であり、そのためには自動化・標準化が不可欠です。SREチームは開発・運用工程における定型作業を割り出し、自動化することで業務を創造的なものへと再定義します。

問題発生時の対応

リリース前に発見した細かなバグやエラーを取り除くのもSREチームの役割の一つです。SREエンジニアの業務範囲には開発工程も含まれるため、コーディングの改善も業務に含まれます。またトラブル発生後に、再発防止に向けた対策導入もSREチームのミッションの一つ。ポストモーテム（事後検証）を行い、インシデントをまとめた文書の作成等も行います。

SREエンジニアに必要なスキル

これまで述べてきた通り、SREの主な目的はシステムやサービスの安定稼働です。システムやサービスを安定的に稼働するには、開発段階のうちから運用工程について考慮しておく必要があります。また、自動化のためのコーディングや運用環境構築に必要なセキュリティー、データベース、クラウドなどの知識・スキルも求められます。

開発チーム・運用チームの連携を促すためのコミュニケーションスキルも大切です。SREエンジニアは開発作業と運用作業のバランスを維持する「舵取り役」としての、非常に幅広いスキルや知識が必要となります。

まとめ：システム・サービスの信頼性向上に貢献するSRE

SREはGoogleが提唱した、システムやサービスの品質維持に欠かせないアプローチ方法の一つです。まだ日本での導入事例は少ないですが、政府によるDX推進の後押しに伴い、SREの重要性も高まっていくことは間違いありません。SREエンジニアには開発・運用における幅広い知識やスキルが求められるため、興味がある方はぜひ積極的なインプットに取り組んでみてください。

文／赤池沙希