SREの現場はどうなっているのか――従来型の運用との決定的な違いとは：特集：情シスに求められる「SRE」という新たな役割（3）（1/2 ページ）

Site Reliability Engineering（以下、SRE）の現場はどうなっているのか。SREの日常的な仕事とはどのようなものなのか。開発エンジニアと運用担当エンジニアは、実際どのように役割分担し、協力し合っているのか。「SRE本」の監訳者などが語った。

[三木泉，＠IT]

　Site Reliability Engineering（以下、SRE）の現場はどうなっているのか。SREの日常的な仕事とはどのようなものなのか。開発エンジニアと運用担当エンジニアは、実際どのように役割分担し、協力し合っているのか。

　2017年9月25日に、書籍『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム（以下、SRE本）』の出版を記念して開催されたSRE Meetup Tokyoで、監訳者を含む現場の人々が、SREのエッセンスについて語った。

　なお、行為としての「Site Reliability Engineering」と、SREを行うエンジニアを指す「Site Reliability Engineer」は、どちらも短縮すると「SRE」であり、混同しやすい。このため、本記事ではSite Reliability Engineerを「SREエンジニア」と表現する。

「信頼性はプロダクトの機能の1つ」という考え方

　SREの原点は、「信頼性はあらゆるプロダクトの基本的な機能である」という考え方だ。「DevOpsの一形態」という説明もできなくはないが、開発と表裏一体であり、「信頼性のための機能を開発する」という側面を持っている。このため、自動化を積極的に進め、これによってスケールする運用を目指すことになる。

　Googleでは、Gmail、広告システムのバックエンドなど、大きな社内、社外向けプロダクトにSREエンジニアを配置している。単一のSREチームが、複数プロダクトを担当する場合もある。いずれにしても、開発エンジニアとSREエンジニアは、ヘッドカウントについて単一のプールを構成していて、プロダクトによって両者のバランスを考えて割り振る形になっている。

　通常、プロダクトの開発エンジニアが運用も行うが、プロダクトが大きくなってくると、それでは間に合わないため、SRE専任のエンジニアチームが構成される。

　SREエンジニアは、自分たちの負荷が高過ぎると判断した場合、開発者に運用作業を負担させていいことになっているという。サービス開発者は、自分たちが運用に関わりたくない。これが信頼性の高いソフトウェアを書くモチベーションになる。

サービスレベル目標が活動のよりどころになる

2013年からGoogleのSREとしての経験を積んできた澤田武男氏。2017年にDropboxへ転職したが、引き続きSREエンジニアとして活動している

　SREの活動のよりどころとなるのはサービスレベル目標（Service Level Objectives、以下SLO）だ。澤田武男氏（2013年からGoogleのSREエンジニアとしてディスプレイ広告システム、ソースコードコントロールシステムPiper、Gitなどを担当してきた）は、自らSLOを策定した経験もある。こうした経験から、SLOを策定、運用するやり方について語った。なお同氏は、SRE本の監訳者の1人だが、2017年にDropboxのSREとなった。

　SLOは社外向けのサービスに加え、認証などの社内向けシステムについても適用できる目標。関連して、SLOの達成のための指標は、「サービスレベル指標（Service Level Indicator、以下SLI）」と呼ばれる。

　SLOの策定は非常に重要だと、澤田氏は強調した。「信頼性とコスト、開発速度のトレードオフを、サービス開発エンジニアと議論し、合意する機会になるから」だという。

　例えばあるシステムに求める信頼性は、99％なのか、99.999％なのか。これによって冗長構成など、アーキテクチャが大きく変わる可能性がある。また、必要なSREエンジニアの人数はどれくらいか。インシデント対応はどれくらいの時間でできるようにするか。どういうイベントをアラートの対象とすべきなのか。

　無限の信頼性は得られない。信頼性には具体的な目標を定めないと、誰もが不幸になる可能性がある。あらかじめSLOをステークホルダー間で合意していれば、過剰なリクエストに対応しない理由を明確に説明でき、サービスチームを守ることができる。また、高いサービスレベルが求められる他のサービスに、不適切に組み込まれることを防げる。

SLOはどのように運用されるか

　SLOは、SLIを決め、次にSLIを使った目標を定め、これを実行することで行う。

　SLIはどのように選ぶか。ユーザーの満足度と高い相関を持つメトリクスを選択する必要がある。また、モニタリングが容易でなければならず、事実上サーバサイドのメトリクスになることが多い。また、SLIを多数設定することは避け、シンプルにすべきだ。

　SLIには、「可用性」「レイテンシ（遅延）」「耐久性」「スループット」など、多様な種類があるが、簡単なメトリクスから始めるべきだと、澤田氏は話した。

　計測はできるだけユーザーに近い地点で行い、エラーについては、原因がユーザーかサービスかを、正しく分類できなければならない。また、SLOで対応すべきサービスリクエストの種類を吟味する必要がある。

　こうした考慮の上で、SLOを定義する。ただし、定義には多様な方法がある。例えば「99.9％のアップタイム」といっても、「ある期間中の全てのリクエストに対するエラー率が0.1％以下」「ある期間を数分のウィンドウに分割し、99.9％のウィンドウでエラー率が○％以下」「ある期間を数分のウィンドウに分割し、各ウィンドウのエラー率を平均したものが○％以下」などが考えられる。サービスに応じて、適切な目標を選択する。