「SRE Meetup Tokyo」レポート

Googleがおススメするシステム運用管理手法「SRE」「SLO」のメリット（1/2 ページ）

Googleが膨大なシステムを開発、提供する中で生み出したシステム管理手法「SRE」（サイトリライアビリティエンジニアリング）。本稿ではSREやそのメリット、SREと併せて取り入れたいSLOについて紹介する。

公開 2017年10月24日 05時02分

[著]

印刷する

　Google日本法人は2017年9月25日、書籍『SRE サイトライアビリティエンジニアリング　～Googleの信頼性を支えるエンジニアリングチーム』の出版を記念し、「SRE Meetup Tokyo」を開催した。会場となったのは東京都内にある同社のオフィス。Googleで培われたシステム管理の新手法を学ぼうと、多くのエンジニアが参加し、席は埋め尽くされていた。本レポートを通じて、「SRE」（サイトリライアビリティエンジニアリング）とはどのようなものなのか、ユーザー企業が取り入れる際の肝はどこにあるのか、感じ取ってほしい。

併せて読みたいお薦めの記事

SLO／SLAとは何か

クラウドのSLAについて

開発者がシステム管理をするSRE、そのメリットとは

　SREとは、Googleが膨大なシステムを開発、提供してきた中で生み出したシステム管理手法だ。Google日本法人でDeveloper Advocateを務めるイアン・ルイス氏は、SREについて次のように説明する。「開発者がシステム管理をするというのがSREの基本的な考え方です。一般開発者はエンドユーザーが要求する機能を実現するために開発し、SREの開発はアプリケーションやシステムの信頼性を高めるために開発します」（ルイス氏）

Google日本法人のイアン・ルイス氏

　サービスをスケールさせるには、運用をできるだけ自動化する必要がある。SREでは、そのために開発リソースを投じる。とはいえ、やり過ぎては意味がないとルイス氏は言う。SREに開発者を多く割けば、それだけアプリケーション開発のリソースを減らすことになるからだ。「SREはオプションの1つであり、開発リソースのトレードオフであることを忘れてはなりません」（ルイス氏）

　運用がうまくいっていれば、開発リソースを運用に当てるのは無駄に思えるかもしれない。しかしシステムが複雑になればなるほど運用も複雑化し、問題も発生しやすくなる。運用担当者だけで解決できない問題が発生すれば開発チームにリクエストがきて、開発者は予定にない作業に当たり、結局は運用に時間を割くことになる。そのような事態を避けるためのシステム管理手法がSREなのだ。

SLOを定義することによりさまざまなメリットが得られる

　具体的には、どのようなことに気を付けながらSREに取り組んでいけばいいのか。その一端を解説してくれたのが、澤田武男氏だ。現在は他社でSREを推進している澤田氏は、数カ月前まではGoogle日本法人に在籍し、SREに携わっていた。

　Google日本法人ではローンチ調整エンジニアリングやSLO（Service Level Objective）の策定、PRR（Production Release Review）などを担当してきたという澤田氏。今回はその中でも、システムの信頼性を左右するSLOとトイル（詳細は後述）を取り上げた。

澤田武男氏

　SLOは「サービスレベル目標」と訳される。サービスレベルを保証するSLA（Service Level Agreement）はよく耳にしても、SLOは知らないという読者もいるかもしれない。簡単に説明すると、SLAで保証するサービスレベルのことをSLOと呼び、それを確認するために用いられるのがSLI（サービスレベル指標）だ。例えばSLAに「99.99％の稼働を保証し、満たせなかった場合には規定に基づき返金する」とあれば、SLOは99.99％の稼働率ということになる。

　SLOを定義するメリットは「“高い信頼性”という曖昧な目標を数値化することでチームメンバーが明確に目標を共有できるようになることと、過剰な要求から開発チームを守れるようになることです」と澤田氏は説明する。

　信頼性は、コストや時間とのトレードオフだ。曖昧な目標に向かってリソースを投じ続けてもゴールは永遠に訪れず、過剰な投資を余儀なくされる。SLOを明確な数値目標として定めることで、適したアーキテクチャやチーム体制、モニタリング感度、障害対応速度などを決める際の指標を共有できる。またSLOをステークホルダーとも共有しておくことで、過剰に期待されたり、依存されたりすることを避けられると澤田氏は言う。

SLOを定義することでさまざまなメリットが得られる

　SLOの定義にもいろいろある。「アップタイム99.9％と言っても、リクエストのエラー率が0.1％以下なのか、サービスの停止時間が0.1％以下なのかによって監視方法も目標達成へのアプローチも変わります」（澤田氏）

　その後、話題はトイルへ。トイルとはシステムの稼働を維持するために必要な手作業のことで、澤田氏は「撲滅すべき」と言う。システム管理に手作業が多ければ、スケールした際に負担が大きくなるだけではなく、生産性が下がり、手作業によるミスが発生する恐れもある。こうしたことからGoogleでは、トイルが50％以下になることを目標としているとのこと。澤田氏はGoogleから現職に移ってもトイル撲滅のために戦っているそうだ。

　「基本的には、コツコツと1つずつトイルをなくしていく以外に方法はありません。自分たちが手作業でやっていることを見直し、地道に自動化や改善を続けます」（澤田氏）

次ページへモニタリングの落とし穴