ここから本文です

SREの現場はどうなっているのか――従来型の運用との決定的な違いとは

11/2(木) 7:30配信

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

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

 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%のウィンドウでエラー率が○%以下」「ある期間を数分のウィンドウに分割し、各ウィンドウのエラー率を平均したものが○%以下」などが考えられる。サービスに応じて、適切な目標を選択する。

 では、定めたSLOが達成できなかった場合、どのようなアクションを取るべきか。

 まず、障害の多くは、新たな変更に付随して発生することが多いため、新規リリースをフリーズすることが考えられる。また、信頼性に関する改善の優先順位を上げ、一定期間(例えば1カ月間)、改善にリソースを集中することもできる。あるいは、目標そのものを見直す必要があるかもしれない。

●SLOを「エラーバジェット」で管理する

 「SLOを実際に管理し、サービス提供に生かすには、『エラーバジェット』というコンセプトが役立つ」と、GoogleのSRE Advocateであるポール・ニューソン(Paul Newson)氏は説明した。

 「エラーバジェット」は「エラーの予算」。ある一定の期間に、SLOに照らしてどれくらいのエラー時間が許されるかを示す言葉だ。1からSLOを引くと、エラーバジェットになる。

 例えばSLOとして可用性を99%に定めれば、エラーバジェットは1%。SLOを単純に「ある期間内のエラー時間」と定義しているのであれば、30日間でSLOを定めている場合エラーバジェットは43.2分、365日間で定めている場合は8.76時間となる。

 「『エラーバジェット』を考えた方がいい理由は、顧客や自社のCEOにとって、理解しやすい数字だからだ」とニューソン氏は話した。

 SLO上、あとどれくらいエラー時間が発生しても許されるのかが把握できていれば、行動の判断基準として使える。

 例えば「この新機能をリリースすべきか」「変更をどれくらいの頻度で実施するべきか」「検証をもう少し行うべきか」「機能と信頼性のどちらにどのように力を入れて開発すべきか」などだ。

 「コストおよび開発スピードと、信頼性はトレードオフの関係」だが、エラーバジェットを把握していれば、特定の行動によって生じるエラーの確率を勘案し、「今それをやるべきかどうか」「全体的にスピードを現在よりも高められる余地があるか」などを、共通の情報に基づき、関係者間で合意しやすい。

●「トイルの撲滅」とはどういうことか

 SREでは、「トイルの撲滅」も、日常的なテーマの1つという。

 英語で「toil(トイル)」といえば、一般的には「苦労」を意味する言葉だ。SREの文脈では、「プロダクションサービスを動作させるのに必要な作業で、自動化できるにもかかわらず、手作業で行われている、それ自体に価値のないもの」を示すと、澤田氏は話した。トイルはサービスの成長とともに作業量を増加させ、生産性を引き下げる要因になる。

 トイルには例えば、リリース作業、障害対応、バックアップ、仮想マシンの設定/追加/削除、データベースのクリーンアップなどが該当する。

 トイルが多すぎると、「ポジションの魅力が下がり、エンジニアの採用が難しくなる」「生産性が低下する」「手作業によるミスが発生する」といった問題が起こる。従って、トイルを減らす努力を積極的にすべきだという。とはいえ、トイルをゼロにするのは難しく。また、ゼロにすることが必ずしも最善とはいえない。グーグルでは50%を目標としているという。

最終更新:11/2(木) 7:30
@IT