「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の開発はアプリケーションやシステムの信頼性を高めるために開発します」(ルイス氏)
サービスをスケールさせるには、運用をできるだけ自動化する必要がある。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の定義にもいろいろある。「アップタイム99.9%と言っても、リクエストのエラー率が0.1%以下なのか、サービスの停止時間が0.1%以下なのかによって監視方法も目標達成へのアプローチも変わります」(澤田氏)
その後、話題はトイルへ。トイルとはシステムの稼働を維持するために必要な手作業のことで、澤田氏は「撲滅すべき」と言う。システム管理に手作業が多ければ、スケールした際に負担が大きくなるだけではなく、生産性が下がり、手作業によるミスが発生する恐れもある。こうしたことからGoogleでは、トイルが50%以下になることを目標としているとのこと。澤田氏はGoogleから現職に移ってもトイル撲滅のために戦っているそうだ。
「基本的には、コツコツと1つずつトイルをなくしていく以外に方法はありません。自分たちが手作業でやっていることを見直し、地道に自動化や改善を続けます」(澤田氏)
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
3
生成AIが普及しても「技術書」を手放せないエンジニアの本音
-
4
“アジャイルの壁”に挑むオリックス生命がIBMの開発管理ツールを選んだ理由
-
5
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
6
「テザリング依存」に潜む落とし穴 “遅いVPN”を解消するネット構築術
-
7
ライオンが挑む「守りのIT」脱却:Google Cloudで加速させるデータ駆動型経営
-
8
IT製品の導入に関するアンケート「セキュリティ」編
-
9
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
10
Claude利用8割のGMO、AI人材の評価軸が「トークン管理」に変わった
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
7
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
「標的型攻撃メール」事例・サンプル集
-
10
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー