はじめに

SREとは？

SREとは、Webサービスなどを安定して運用するための考え方の一つです。SREを提唱したのは、Google社のGoogleエンジニアリングチーム担当のBen Treynor Sloss氏です。日本語でSREは「サイト信頼性エンジニアリング」と表記します。サービスの安定運用を支える方法として長年利用されています。

SREの目的と役割

SREは、Webサービスの信頼性や可用性確保を目的とします。近年のWebサービスは複雑なものが多く、安定動作は重要な課題の一つです。また、SREは開発チーム（システムやソフトウェアの開発を行うチーム）と、運用チーム（本番の運用環境に問題がないかをチェックするチーム）の間をつなぐ役割もあります。開発チームと運用チームのWebサービスなどの信頼性や可用性などの目標が違うなど、チームの対立を避けるためにSREではシステムの問題発生に対応できる予算を決めるのです。これをエラーバジェットと呼びます。問題の発生が少ない場合は、開発チームは新機能の追加などを行います。エラーバジェットを使い果たすほど問題が発生している場合には新機能の開発を中断し、問題の修正を優先するのです。
また、SREではシステムが安定して動作しているかのモニタリングも行います。常にモニタリングを行い、Webサービスの状態を把握します。問題発生時は問題を正確に捕捉して学習し、再発防止につなげるのです。

SREの来歴

1990年代から2000年代初頭にインターネットが急速に広がりました。その結果、多くのWebサービスに信頼性評価の課題が表出しました。2003年頃にGoogle社がSREを考案します。当初SREはGoogle社におけるチームの名前でした。Webサービスを支えるために従来の運用方法を見直したいというニーズがあったため、Googleのみならず、他の会社もSREを使うようになったのです。2014頃年からは「SREcon」というSREのイベントも開始されます。2016年頃には、GoogleのSREチームのメンバーよりSREの専門書が出版されました。日本では、2015年頃からSRE導入をはじめる企業が現れました。

SREに必要な指標とは？

SREは、Webサービスを安定的に動作させるために指標を利用するのです。指標を基にサービスの改善や障害の予防に対応できます。
ここでは、システムの信頼性を向上させるために、必要な情報を得られる指標について紹介します。

SLI（Service Level Indicator）

SLI（Service Level Indicator）は、サービスがどの程度安定して動作しているかを教えてくれる指標です。SLIは通常サービス利用者側で測定され、0％から100％までの数で算出されます。0％はサービスの状態が最悪で、100％は完璧な状態を示します。SLIの数値は多すぎても少なすぎても好ましくないため、ある程度の数値を目安とする場合が多いです。後述するSLOを決める際の基礎となる数値です。SLIがないと、サービスの何が問題か、どう改善すればいいかがわからなくなるでしょう。一般的なSLIの指標としては、サービスが要求に対する応答を返すのにかかる時間や、データを長期にわたって保持できる割合などの複数の指標が利用されます。また、ユーザーからのリクエストに対してかかった所要時間などもユーザーのページ離脱につながりやすいため、SLIに利用されます。

SLO（Service Level Objective）

SLO（Service Level Objective）は、サービスの信頼性に関する目標です。SLOはサービスが利用者にとって見合った価値を提供しているかを確認する指標です。サービスを提供する側が決める指標で、後述するSLA（Service Level Agreement）で、決められた内容を達成するために設定されます。SLOはサービス提供者と利用者が話し合って決定される場合が多いです。理想的な値ではなく、現実的かつ実用的な最低限必要な値が設定されるのです。SLOとSLIは混同されている場合もあります。SLOは期待される可用性の目標、SLIは目標を達成しているかの測定値という関係性があります。

SLA（Service Level Agreement）

SLA（Service Level Agreement）は、サービスを提供者と利用者間で交わされる約束です。サービスについての誤解を防ぎ、トラブルを避ける目的があるのです。具体的なサービスの基準と、その基準を満たせなかった場合の罰則が設定されているケースもあります。サービスがどの程度安定して動作するか、どのようなサービスを提供するかを決めるのです。
SLAを確認するとSLOや、問題への対処方法がわかります。SLAはサービスがどれだけ安定しているかを測る基準になるため、複数のサービスの安定度がSLAを利用して比較できます。

SREとDevOpsの違いは？

SREでは複雑なシステムの安定動作を最重要としていました。一方、早く柔軟に小単位で実装とテストを繰り返して、開発を進めていくアジャイル開発の考え方を、システム運用に転用したDevOpsという考え方もあります。Googleは「class SRE implements DevOps（SREはDevOpsという、interfaceの実装）」という発信をしています。SREはDevOps概念を実現するための方法といえるでしょう。DevOpsではシステムの信頼性のみならず、スピードや柔軟性も重要視します。SREでは専門のSREチームを設置し、開発チームとは別の組織として動く場合が多いです。DevOpsでは開発と運用のチームが一緒に働きます。

SREとDevOpsの活用方法とは

SREの活用方法はSLAやSLO、SLIを設定して管理し、エラーバジェットの機能を利用してエラーの許容度の管理を行うことです。自動化を進め、人間のミスを減らした効率のよい運用が重要です。SREの活用方法の例としては、SLIを活用し問題が起きた後の振り返りをよく行い、再発防止策を実施するといった方法があります。
例として、SREチームを発足させた企業があるとします。インシデント管理ツールを活用し、重要な情報をすぐに開発者に届く仕組みを整備した結果、緊急対応時の対応をスピーディに行えるようになりました。効果的にSREを活用するためにはSREチームの目標を明確にし、組織全体への情報共有が重要なポイントとなります。また、チームメンバーの考え方や行動の指針となるガイドラインを製作することも、SREを活用する際には重要なポイントになるでしょう。
DevOpsの活用方法としては、開発と運用を一緒にするという点が重要になってきます。開発チームと運用チームが一緒に課題に取り組みます。モニタリングツールなどでシステムの状態を見守りながら、問題があった場合に早く対応できる仕組みを構築し、常にシステムを改善していくのです。DevOpsでも手作業を減らし、効率よく作業ができるように作業の自動化が重要になるのです。大規模にDevOpsを実践して成功している企業の例をあげましょう。映像配信を行っている某社ではデータベースのテストに、リリース前にかなりの時間を割いて徹底的に行っています。人為的に障害自動発生ツールを導入し、開発を邪魔する形で障害対策にエンジニアを巻き込み訓練しています。障害対応訓練のおかげで、大規模障害を乗り越えました。

まとめ

SREはシステムの信頼性を高めるための方法です。インフラ管理と継続的な改善を通じて、開発と運用の効率化を図ります。DevOpsは開発と運用の統合を目指し、迅速かつ安定したソフトウェアのリリースの実現を目指す考え方であることがわかりました。理解を深めて、日頃の業務にお役立てください。