「SRE Meetup Tokyo」レポート
Googleがおススメするシステム運用管理手法「SRE」「SLO」のメリット（1/2 ページ）
Googleが膨大なシステムを開発、提供する中で生み出したシステム管理手法「SRE」（サイトリライアビリティエンジニアリング）。本稿ではSREやそのメリット、SREと併せて取り入れたいSLOについて紹介する。
Google日本法人は2017年9月25日、書籍『SRE サイトライアビリティエンジニアリング ～Googleの信頼性を支えるエンジニアリングチーム』の出版を記念し、「SRE Meetup Tokyo」を開催した。会場となったのは東京都内にある同社のオフィス。Googleで培われたシステム管理の新手法を学ぼうと、多くのエンジニアが参加し、席は埋め尽くされていた。本レポートを通じて、「SRE」（サイトリライアビリティエンジニアリング）とはどのようなものなのか、ユーザー企業が取り入れる際の肝はどこにあるのか、感じ取ってほしい。
開発者がシステム管理をする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つずつトイルをなくしていく以外に方法はありません。自分たちが手作業でやっていることを見直し、地道に自動化や改善を続けます」（澤田氏）
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー