公式資料
「デジタルオペレーションの現状」独自調査レポート
公式資料 エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）
ユーザーニーズの変化が激しい現代において、アジャイル開発を導入するなどして開発スピードを向上させることが重要です。しかし、スピーディーな開発をめざす一方で、システムの安定性の維持が難しいと悩んでいる方もいるのではないでしょうか。そこで注目されているのが、開発の高速化とシステムの安定性を両立するための方法論である「SRE（Site Reliability Engineering・サイト信頼性エンジニアリング）」です。この記事では、SREの基本を知りたい方に向け「概要」「主要な指標」「DevOpsとの違い」「SRE実践におけるポイント」といったポイントをわかりやすくご紹介します。
目次
SREとは
「SRE（Site Reliability Engineering）」とはシステム運用方法の一つで、日本語では「サイト信頼性エンジニアリング」と言います。Webサイトの安定的な運用を支えるための方法論として、Google社が2004年に提唱しました。SREの大きな特徴として、「信頼性」をシステムの重要な機能の一つとしてとらえている点が挙げられます。システムの信頼性を確保し、より良いサービス提供につなげるためのツールやアプローチ方法を常に模索します。例えば、繰り返しの作業や煩雑な手作業の削減、ソフトウェアを使用したITインフラにおけるシステムの自動化などに注力します。
SREが必要とされる背景
SREが提唱される以前は、Google社をはじめとしたIT企業でアプリケーションの開発が活発になる一方、運用業務における負担の増大が課題となっていました。当時、開発チームと運用チームは独立した存在であることが多く、開発業務は自動化が進んでいたものの、運用業務は未だ手作業が中心でした。そのため、アプリケーションをリリースすると運用作業の手間が増え、開発スピードに対して運用面での十分な対応が難しい状況になっていたのです。運用面での負担の増加が、システムの不安定さや問題を発生させるリスクにもつながっていました。
そこで、Google社はシステムの利便性や安定性を価値としてとらえ、安定性を向上するためのSREという方法論を提唱しました。SREは2004年に提唱されたものの、昨今再び注目されていますが、その背景にはウォーターフォール開発からアジャイル開発への転換があります。従来のウォーターフォール開発は、品質確保を重視して、工程を段階的に区切って一つずつ進める開発手法です。一方、アジャイル開発は開発スピードを重視した開発手法で、ニーズの変化が激しい昨今では採用する企業が増えています。しかし、開発スピードの向上を重視するあまり、システムの利便性や安定性が損なわれてしまうケースが少なくありません。これではユーザーが安定してサービスを使えず、サービスの価値低下にもつながります。現代において、価値の高いサービス提供には安定したシステムの存在が欠かせず、このような背景からSREに取り組む企業が増えています。
DevOpsとSREの違い
SREとともに注目されているのが「DevOps」です。DevOpsとは、開発と運用の担当者が密に連携し、柔軟でスピーディーな開発・運用を実現する考え方を指します(関連記事：DevOpsとは？超基本からメリット・実践ポイントを解説)。SREとDevOpsは、注目される背景や思想が似ていることから混同されやすく、違いがよくわからないという方もいるかもしれません。両者とも、自動化や全体最適化に取り組むといった点が類似しています。「SREとDevOpsの差異」については、SREを提唱したGoogle社の表現が参考になります。同社はSREとDevOpsの関係について、プログラミングの記法で以下のように示しています。
“class SRE implements interface DevOps”（引用元）
これは、直訳すると「SREはDevOpsというinterfaceを実装する」という意味になりますが、DevOpsの実現方法の一つがSREである、という意味を示唆する表現です。また、DevOpsとSREは重視するポイントが異なります。DevOpsでは「何を」すべきかを重視して具体的な実践方法は実践者に委ねられているのに対し、SREでは「どのように」すべきかを重視して具体的な方法が示されています。つまり、DevOpsはSREの上位概念であり、SREはDevOpsを実践するための方法論だといえるでしょう。
SREの主要な指標である「SLO」「SLA」「SLI」
SREでは、サービスの信頼性を担保する指標を定め、それをモニタリングし続けることが重要です。その指標としては、主に「SLO」「SLA」「SLI」の3つが用いられています。それぞれの用語の意味と、指標を決める際のポイントをご紹介します。
SLO
SLOは「Service Level Objective」を略したもので、日本語だと「サービスレベル目標」と言います。自社のサービスレベルに関する目標値のことです。開発において、スピードと信頼性の両立は簡単ではありません。例えば、信頼性を高めるためにはテストを追加して開発を遅らせる必要があったり、逆に開発スピードを上げるために信頼性を下げる必要があったりします。この判断において重要となるのがSLOです。例えば、サーバーの稼働率を重視するサービスでは、SLOを「月間の稼働率99.99％以上」と設定します。SLOの値は、高く設定すれば良いものではありません。サービスの信頼性をより高く確保・維持しようとするほど運用コストがかかるからです。そのため、ユーザーへの価値提供に必要のないようなレベルまでSLOの値を高めることは、過度な目標といえます。サービスにおいてユーザーが最低限許容できるレベルの信頼性を定義し、SLOとして規定しましょう。
SLA
SLAは「Service Level Agreement」を略したもので、日本語だと「サービスレベル契約」と言います。提供されるサービスレベルについて、企業と顧客との間で交わされる合意内容を指します。SLAは顧客との契約上の取り決めであるため、SLAが達成されない場合には、返金や追加サポートの提供といったペナルティが発生します。また、SLAでは対外的にその達成を明示する必要があるため、達成状況を判断できるよう、稼働率のようにシステムのモニタリングによって測定できる指標を用いることが重要です。加えて、責任範囲に応じた算出条件の検討も必要になります。例えば、SLAに稼働率を用いる場合、その算出においてはユーザーの誤操作による停止は除外する、といった条件を検討します。
SLI
SLIは「Service Level Indicator」を略したもので、日本語だと「サービスレベル指標」と言います。例えば、サーバーの稼働率など、サービスの品質を判断するための指標そのものを指します。SLO・SLA・SLIでは、同様の指標を用いることも多くあります。ただし、SLOとSLAは目標や約束に向けた「設定値」であるのに対し、SLIは「実測値」である点が異なります。SLIを定期的に測定して、SLOを下回る場合は問題が発生していると判断し、システムの可用性を高める取り組みを実施します。
SLA SLO SLIについては以下の記事でも詳しく解説しています。ぜひ併せてご覧ください。
＞ SLA SLO SLIとは？違いと適切に活用するためのポイント
SRE実践、4つのポイント
SREにおける取り組みは、企業の規模や状況に応じて進めることが大切です。ここではSREを実践する上で知っておきたいポイントを解説します。
システムの監視とアラートのノイズ削減
システムの可用性を維持するためには、システム状況をリアルタイムでモニタリングし、パフォーマンスが低下した際に対応する必要があります。そのためには、DatadogやNew Relic、Splunkといった監視ツールの活用が有効です。監視ツールの導入により「レイテンシ（応答速度）」「トラフィック」「エラー」「サチュレーション（システムの飽和度）」などを常時モニタリングし、アラートにより異常を検知できます。監視ツール導入の際には、大量のアラート発生に注意しましょう。システムを広く監視する必要はあるものの、大量のアラートが発生してしまうと、エンジニアがアラートに対応しきれないといった状況が起こります。監視ツールのアラートの中には、対応が不要なものも含まれます。このように、業務にとってノイズとなるアラートが多くあると、重要なアラートが埋もれてしまい、対応の遅延にもつながるため対策が必要です。その対策の一例としては、インシデント管理ツールを活用してアラートを削減する方法が挙げられます。近年は、AIを用いてノイズとなるアラートを削減する機能も登場しています。
オペレーションの自動化
保守・運用作業は、手作業や繰り返し作業で成り立っているケースが少なくありません。しかし、システムの安定稼働をめざす上では、可能な限り自動化によって手作業を減らし、ヒューマンエラーのリスクを抑える必要があります。例えば、インフラの構築・運用には「IaC（Infrastructure as Code）」と呼ばれる、インフラ構成のコード化が有効です。人手でのインフラ構築は、設計書に従ってひたすらコマンドを打つ作業であるため、規模が大きいほど手間やヒューマンエラーが発生しやすくなります。IaCを導入するとソフトウェアでインフラ環境を操作できるため、ヒューマンエラーの回避や自動化による迅速な環境構築が可能です。そのほかにも、繰り返し発生する手作業には「ランブック（手順書）」の活用がおすすめです。ランブックの作成・活用は作業品質の均一化につながるほか、ワークフローの自動化推進にも役立ちます。
ポストモーテムと継続的改善
システムの信頼性は利用状況に応じて常に変化するため、継続的な改善が求められます。特にシステム障害の対応では一時的な対処が講じられることもありますが、加えて、根本原因の解消と再発リスクの低減に取り組むことも重要です。改善に向けた有効な取り組みの一つに「ポストモーテム」があります。ポストモーテムとは、システム障害などの問題が発生した後に、再発を防止するために振り返りを実施することです。担当者やチームを非難することなく、問題が起因するアクションを特定し、再発防止のための対応をドキュメント化します。障害発生や失敗の隠蔽を防ぐために、担当者やチームを責めない姿勢が重要です。日々の業務が多忙な中では、振り返りを実施するための工夫も求められます。定期的にスケジューリングしたり、ドキュメントテンプレートを活用したりして、効率的な振り返りの実施を検討しましょう。
SREチームの構築
SREの担当者は、単に運用管理のためのコーディングをするメンバーではないため、SREの活動では顧客体験と信頼性の向上を念頭に取り組むことが大切です。担当者にその意識を持たせるためには、SREチームの構築も重要なポイントになります。SREチームを構築する場合は、チームの目標を明文化して、組織全体に明確に示しましょう。さらに、チームメンバーの考え方や行動の指針となるガイドラインを設定します。具体的なガイドラインを設けることで、担当者はより目標に向けたアクションをしやすくなります。また、組織におけるSREの役割や目標を明確にすることは、自社に最適なSREチームの運用体制を決める上でも役立ちます。SREチームの構築についての詳細は、こちらのBlog記事「サイト信頼性エンジニアリング（SRE）チームの構築とスケーリング」を参考にしてください。
SREの実現には「インシデント対応」の効率化が重要
事前にさまざまな対策をしていても、実際にシステムを運用してみると、計画や想定とは異なる事象が起きてしまうものです。例えば、予期しないシステム障害やパフォーマンスの低下といった望ましくない変化、いわゆるインシデントがデプロイ後に発生することがあります。インシデントとして取り扱う事象の定義は企業によって異なりますが、PagerDutyでは「システム障害に際して何らかの対応が必要な課題」をインシデントとして定義しています。インシデントはSLIを低下させる要素であり、企業のサービスにおける信頼性を脅かす存在です。さらに、24時間365日のサービス提供が当たり前の現代では、システム停止による損失は莫大な規模になっています。SREの目的であるシステムの信頼性確保を行ない、問題の影響を低減して最悪の事態を回避するためには、迅速なインシデント対応が欠かせません。
一方で、現代のシステム構成は複雑化しており、それにともないインシデントの発生件数も増加傾向にあります。数多くのインシデントに迅速に対応するためには、インシデント対応の効率化が必要です。しかし、インシデント対応において、エスカレーションや煩雑な手作業に時間を要している企業もあることでしょう。そこで、対応の効率化に向けておすすめなのがインシデント管理ツールの活用です。インシデント管理ツールとは、インシデントを適切に管理して、迅速にシステムやサービスを復旧するためのものです。具体的には、さまざまな監視ツールからのアラートを一元管理し、チーム間のスムーズなコミュニケーションを実現できます。また、インシデント対応で発生するさまざまな手作業の自動化も可能です。インシデント対応プロセス全体を対象としたツールであれば、包括的にインシデント対応を見直せる上、使い続けるほどに大きな効果やコストメリットを得られます。
インシデント対応ツール活用によるSREの成功事例
SREの実践には業務の変化やツール導入への投資などがともなうため、不安を覚える方もいるかもしれません。しかし、日本でもSREへの取り組みで成功している企業は増えてきています。ここでは、インシデント対応の効率化を含めたSREの実践によって成功している2社を紹介します。
事例1：LINE株式会社(現: LINEヤフー株式会社)
コミュニケーションアプリを中心に、さまざまなサービスを提供するLINE株式会社。同社は、ユーザーにとってより便利なサービス提供の実現を目的とし、プライベートクラウド「Verda」を使ってDevOps体制でサービスの開発や提供を行なっています。同社では開発の担当者がデプロイや監視を担うため、サーバー確保やシステム管理の仕組み作りに手間と時間がかかることが課題となっていました。そこで、その課題を解決すべくSRE活動を専門とするチームが発足されます。SREチームでは、Verdaに関する問い合わせ対応や物理的なマネジメントを担い、開発チームがサービスに関する対応に集中できるようにしています。また、インシデント管理ツールを活用してノイズとなるアラートを削減し、重要なアラートが開発者に届く仕組みを整えています。このような取り組みは、Verdaの規模拡大にともなって増える緊急対応へのスピーディーな対応にもつながっています。（参考記事：LINEのプライベートクラウド「Verda」のDevOpsを支えるPagerDutyによるインシデント管理）
事例2：オイシックス・ラ・大地株式会社]
オイシックス・ラ・大地株式会社は、「Oisix」をはじめとした食品宅配のサブスクリプションサービスなどを提供する企業です。同社では、システム本部の中にSREの部門を設置し、各サービスの運用最適化に取り組んでいます。SREに取り組む以前、Oisixの主要なデータベースはオンプレミス構成でした。しかし、リソースの増強にサービス停止が必要など、サービスが成長するにつれて拡張性が課題となっていました。そこで、専門で対策を行なうプロジェクトを立ち上げ、入念な調査と準備を通じてAWSへのシステム基盤の移行を遂げます。また、マニュアル整備による属人化防止やマイクロサービス化にも取り組むことで、スケールアップできるシステム環境の整備がなされています。インシデント対応についても、MSP事業者への委託からインシデント管理ツールに移行することで、対応の効率化とコスト削減に成功しています。例えば、MSP事業者との細かいコミュニケーションや煩雑なチケット管理が不要になり、MTTA（平均確認時間）は約30～50％改善したとされています。（参考記事：オンプレミスにもPagerDutyを活用!MSPからの移行でMTTA短縮化とコスト削減を実現したオイシックス・ラ・大地）
SREを取り入れて高品質で安定的なサービス提供をめざそう
あらゆるサービスがWebで提供される現代において、ITシステムの安定稼働や信頼性はより重要性を増しています。そのため、今やSREは企業にとって欠かせない取り組みの一つとなっています。SREは方法論が提示されているため取り組みやすく、システムの一部の自動化から取り組んで、活動の幅を徐々に広げていくといったことも可能です。ぜひSREを取り入れて、高品質なサービスを安定的に供給できる環境を整えましょう。一方で、SREの活動はさまざまなツールを活用して進めていく側面があります。特に活動の基本となる監視ツールの導入では、アラートを制御しきれず、逆に非効率を招くケースがあるため注意が必要です。
また、インシデント対応プロセスの見直しや自動化といった点も、システムの信頼性向上には欠かせません。そこでおすすめなのが、インシデント管理プラットフォームの「PagerDuty」です。PagerDutyには世界で2万社を超えるユーザーが存在する信頼性の高いプラットフォームです。モニタリングツールやコラボレーションツールなど700以上のサービスと連携してインシデント対応プロセス全体を改善するほか、インシデント対応の自動化を推進できます。PagerDutyのサービス内容や機能にご興味のある方は、お気軽にお問い合わせください。
インシデント管理やシステム障害に関するダウンロード資料はこちら
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
関連ブログ記事
人気記事
検索
タグ目次
