フリーランス求人を探すSREとDevOpsの違い
IT運用における新たなアプローチとして「SRE（サイト・リライアビリティ・エンジニアリング）」が注目されています。ソフトウェアエンジニアの役割として「DevOps」と混同されることも多い「SRE」ですが、この2つの言葉に明確な違いはあるのでしょうか。
この記事では、SREとDevOpsそれぞれの定義や意味を解説します。そのうえで、SREとDevOpsの違いについて把握しましょう。
目次
SREとは
SREは、Site Reliability Engineeringの略称です。日本語に訳すと、「Webサイトやサービスの信頼性を構築する技術（エンジニアを含む）」を意味します。たとえば、その技術の1つが、システム運用作業の自動化です。ITインフラ基盤の運用や監視業務を手作業から自動化に切り替えることによって、効率性や生産性の向上を実現できます。
SREは1つのチームで活動しますが、そのメリットとして、従来のシステム運用で起こりがちだった、エンジニア間の対立を未然に防ぐことが可能な点があります。
その1つが、エラーバジェットによる優先順位付けです。SREチームでは、SLO（Service Level Objectives）やSLA（Service Level Agreements）といった明確な数値目標を設定し、エラーに対するバジェット（予算）を定めエンジニアチームで共有します。
そのように、サービスの可用性を数値で表し、優先順位付けを行うことで、開発を担当するエンジニアと、運用を担当するエンジニアによる対立を防ぐことができるのです。そして、ソフトウェアやシステムの効率的な開発・運用が実現に貢献します。
また、ユーザーへのサービス提供を安定的に行うために、可用性のほかにもログやエラー率、速度など数値指標の監視が必要となります。障害アラートやリソース使用量の増加などにも対応が必要でしょう。
自社が提供するサービスについて社会からの信頼を得ることは、企業活動にとって重要です。SREを実践することで、Webサイトやサービスに対する信頼性が高まり、その結果として企業価値の向上につながるからです。この、SREというコンセプトを初めて提唱したのはGoogleですが、現在では世界中の企業がSREを導入しています。
Googleが提唱した方法論
「サイト・リライアビリティ・エンジニアリング（SRE）」というフレーズを生み出したのは、GoogleでSREチームを構築したBenjamin Treynor Sloss氏です。SREは運用技術者ではなく、ソフトウェアエンジニアがシステム運用を行う点がポイントです。そして、SREはGoogleが提唱したIT運用の方法論として広く認知されています。
GoogleのSREチームは、世界規模の体制で24時間365日システムの安定稼働を支えており、そこで蓄積されたベストプラクティスとしてSREの概念は他のグローバル企業にも普及しました。Netflix、Amazon、GitHub、Spotifyなど著名なインターネット企業の多くが組織体制にSREを取り入れました。
SREを業務で担当するエンジニアの役割を指す「サイトリライアビリティエンジニア（SRE）」も名称として定着してきています。
SREと従来の運用との違い
SREと従来からあるシステム運用との違いとして、開発と運用のチーム編成があります。従来の運用では、ソフトウェアやシステム開発を担当する部門と、運用・保守などのインフラ業務を担当する部門で役割が分けられていることが一般的でした。開発と運用の2つでチームが分かれると、それぞれの業務に専念できノウハウが溜まりやすい点はメリットです。
ただ、このスタイルでは、両者のコミュニケーションに不足が生じがちになります。その結果として、開発担当が開発した新機能を、運用担当がスムーズに本番公開できないといった不具合が発生していました。
そこで、Googleでは、運用技術者ではなく、ソフトウェアエンジニアがシステム運用に貢献するSREというコンセプトを提唱したのです。
システム運用作業の自動化
システム運用作業の自動化は、従来の運用では人手をかけて行っていたシステム監視、障害・脆弱性への対応、新機能への更新といった多くの作業を、ソフトウェアエンジニアリングによって自動化・効率化することです。
コード実行による環境構築やエラー監視、閾値設定などのオートメーション化で、作業量やコストの大幅な削減が可能になります。また、手動実行では起こりがちなエラーが減らせますし、従来の運用ではバラバラになりがちだった作業品質の平均化も期待できます。
エラーバジェットによる優先順位付け
エラーバジェットによる優先順位付けを行うことで、開発担当と運用担当間による作業の分断を防止できます。開発担当は、より早い本番公開やシステムをリリースするための時間を少しでも多く確保したいものです。また、対する運用担当も、運営をスムーズに行うための時間的な猶予を少しでも多く確保したいと考えています。
このような理由から、社内では、しばしば両担当による意見の対立や見解の相違が起こりがちです。そこで、SREは実現したいサービスの目標を基準に必要な予算を設定します。その目標を下回っていれば、更に高機能なソフトウェアやシステムが必要と判断し、開発により多くの予算をまわします。逆に上回っている場合は「機能に問題なし」と判断して、運用により多くの予算をまわすことになるのです。
SREの基本
SREを理解するうえでは、何よりも基本を理解しておく必要があります。SREの基本は、トイル（Toil）の制限、SLO・SLI・SLAによる目標定量化、IaCによる自動化の3つです。この3つをしっかりと理解しておくことで、SREの概念を理解することにつながります。
トイル（Toil）の制限
トイル（Toil）は、日本語の苦労に当たる言葉です。つまり、トイルを制限するとは、苦労を掛けないようにするということで、Googleでは「手作業をできる限り削減」することと定義されています。
具体的には、SREが行う手作業の時間を「作業時間全体の50％」までに制限して、残りの50％を自動化やサービスの質を向上させるために活用させています。Googleでは、四半世紀に一度のペースでトイルについて棚卸しを行い、達成具合を評価しています。
もし、トイルの目標数値を達成できなかった場合は、課題の優先順位を変更したり取りやめたりすることで対応します。それでも制限を守れない場合は、組織の解体も辞さないという厳しい対応を行っています。
SLO・SLI・SLAによる目標定量化
SLO・SLI・SLAによる目標定量化は、SREがエラーバジェットの優先順位付けを行ううえで、必須の知識です。まず、SLO（サービスの信頼性の目標）は、システムを利用するユーザーからの信頼を得るために、最も重視すべきことは何かを考えることです。
SLOの数値は、システムの稼働率や可用性（ユーザーによるシステムの利用度）などのパフォーマンスから導き出します。SLI（サービスレベル指標）は、ユーザーに対するサービスの品質レベルを見極めるための指標です。
このため、数値を計測するには、ユーザーによるアプリケーションへのリクエスト成功率などを用いることが有効です。SLA（サービス合意）は、事業者とユーザーとの間で結ばれる、サービスレベルに関する合意形成のことです。
具体的には、事業者がユーザーに対して保証できるサービスレベルの水準を事前に設定しておき、達成できなければ「契約料や利用料金を10〜50％返還」するといった契約を結ぶことになります。
これら3つの指標を活用することで、エラーバジェットの評価をおこなう際に、スピーディーでより客観的な判断を下すことが可能になります。
IaCによる自動化
Infrastructure as Code （IaC：アイエイシー）とは、コードによるインフラ管理を意味します。オンプレミスでの物理的な構成から仮想環境、クラウド環境へとインフラ（サーバーやネットワークなど）構成が移りかわるなかで、システム運用も台帳管理などの手作業からコード化へと自動化が進んでいます。
従来のシステム運用では、コスト管理や環境構築などの作業を手作業で行っていました。ただ、手作業ではどうしてもミスによる修正や確認作業が必要となり、環境の構築に時間が掛かってしまいます。
また、構築作業には専門性が必要なため、運用管理のスキルを持つ人にしか作業ができませんでした。IaCは導入時に作業コストが発生するものの、従来型の運用作業によるデメリットを解消することが可能です。
SREの役割
SREには多くの役割があります。その中でも、サービスの可用性を保ち、ソフトウェアやシステムの開発スピードを向上させ、異常の早期検知を行うことは、特に重要な役割として認識されています。
サービスの可用性を保つ
サービスの可用性とは、ソフトウェアやシステムの開発や運用のレベルを維持することです。ユーザーにとって、品質の高いソフトウェアを安定的に稼働させることは、WEBサイトの信頼性に関わります。このため、ユーザーからの信頼を得るためには、サービスの可用性を保つことは、事業者にとって大切な要素になるのです。
開発スピードの向上
ソフトウェアやシステムの開発は、日進月歩の分野です。このため、ライバル企業に遅れを取らないためにも、サービスの可用性とともに重要な要素が、開発スピードの向上です。可用性だけに気を取られていると、業界全体のトレンドから取り残される可能性があるため、開発スピードの向上も追求することが大切です。
異常の早期検知
ソフトウェアには、システム上のトラブルが付きものです。もちろん、システムを運用する事業者は、こういったトラブルを防ぐために、複数のサーバーやスイッチ類を用意しておく、冗長化と呼ばれる故障対策を設けています。
とはいえ、冗長化は故障が起こってから作動するため、どうしてもサーバーが使えなくなる時間が生じます。このため、冗長化だけでなく、異常を早期に検知できる機能も装備しておくことが、SREの大切な役割の1つなのです。
DevOpsとは
DevOps（デブオプス）は、企業の開発担当（Development）と運用担当（Operations）が、協力してプロジェクトに取り組むことです。ソフトウェアやシステム開発・運用事業者にとっては、開発・運用の両担当が協力してより高品質でスピーディーなソフトウェア開発を行うことが、DevOpsの考え方です。
DevOpsの概念
DevOpsの概念は、ソフトウェアの開発担当と運用担当が一致協力しながら、ユーザーにとってより良いサービスの提供を目指そうとする意識のことです。この概念を現実化するために大切なのは、お互いの意見を尊重しながらコミュニケーションを欠かさず、共有する目標を達成するために邁進することです。
ソフトウェアのスピーディーな開発や、システムの安定稼働によるユーザーの満足度の向上は、社員同士で争っていては実現できません。社員それぞれがDevOpsの概念を大切にしながら、日々の業務に取り組むことが必要なのです。
開発担当と運用担当が連携
DevOpsでは、ソフトウェアやシステムの開発担当と運用担当の連携によって、サービス改善のサイクルを早め、システムの開発・運営に関するエンジニアの協調が可能になります。この連携によって、開発担当は運用担当の意見を取り入れた開発が行なえます。結果として、コミュニケーション不足によるプログラムの修正が減り、運用面における生産性の向上が期待できるようになるのです。
DevOpsとアーキテクチャ
DevOpsの概念は大切ですが、それだけでソフトウェアを開発して安定的に運用することはできません。DevOpsの概念を目標の達成につなげるためには、アーキテクチャの設計や理念を反映した組織体制が必要です。
アーキテクチャには、分野ごとにいくつかの意味がありますが、ソフトウェアの開発やシステム運用では、構造といった意味合いで使用されます。たとえば、アプリケーションの開発であれば、機能や性能を構成する各コンポーネントやソフトウェアの構成要素を意味しています。
また、システム運用であれば、ミドルウェア、データベース、ネットワークなどのインフラ基盤、安定・効率的な運用を行うための監視や、データの更新といった枠組みがあります。
DevOpsの基本
DevOpsの基本を理解するうえで大切なのは、アジャイルと継続的デリバリーの2点です。どちらも、スピーディーな作業が求められるソフトウェア開発に必要不可欠な手法だからです。アジャイルと継続的デリバリーを導入せずに、スピーディーなソフトウェアやシステムの開発はできないと言っても過言ではないほど、重要な手法とツールになっています。
アジャイル
アジャイルは、機敏や素早いといった意味の英語です。ソフトウェアやシステム開発におけるアジャイルは、開発までの期間が短縮される手法という意味で使われています。
アジャイル開発が登場するまでのソフトウェアやシステム開発は、設計から実装までのすべての工程を1つのパッケージとして開発するウォーターフォール手法でした。この手法のデメリットは、設計から実装までのスケジュールをあらかじめ決めてしまうため、途中でシステムに変更点が生じると柔軟に対応できず、完成までに時間が掛かることでした。
そこで開発されたのがアジャイルです。アジャイルでは、あえて厳密な設計を行わず、開発の途中であっても機敏で柔軟に設計変更ができるようにしたのです。しかも、すべてを1つのパッケージとせずに小分けに開発して、設計・開発・実装・テストを繰り返すことで、開発期間の短縮を実現しています。
継続的デリバリー
ソフトウェア開発中には、頻繁にコードの変更が発生します。このコード変更が起こった際に、実稼働環境へのリリース準備を自動的に行ってくれる機能が、継続的デリバリーです。継続的デリバリーを導入することで、コードの変更だけでなく、テストの自動化とリリースに向けた準備の自動化、手動操作の減少による生産性の向上といったメリットがあります。
DevOpsが扱う5つの領域
DevOpsは、「組織のサイロを削減」「エラー発生を前提とする」「段階的に変更」「ツールと自動化の活用」「全てを計測」といった、5つの領域を扱っています。これら5つの領域は、DevOpsを円滑に進めるための基本的な要素のようなものです。
組織のサイロを削減する
サイロというのは、チームとチームの間に溝が生じてしまい、チームワークがうまく行かない状態のことです。ソフトウェア・システム開発・運用企業にとっては、開発担当と運用担当のチームワークがうまく行かなくなることになります。そこで、このサイロを削減するために、DevOpsでは開発担当と運用担当の溝を修復し、両担当の連携を推進することになります。
エラーが発生するのを前提とする
どれほどに精密に設計してプログラミングしたシステムにも、必ずエラーは発生します。このため、開発・運用両担当のエンジニアは、この事実を前提にしてソフトウェアやシステムの開発・運用に臨むことが大切です。
段階的に変更する
ソフトウェアやシステム開発の現場では、プログラムの変更は頻繁に発生します。ただし、なるべく段階的かつ小規模な変更を行うことで、新たな機能の導入や正常時に戻すロールバックが行ないやすくなります。
ツールと自動化を活用する
効率的でスピーディーな開発を行うためにも、できる限り便利なツールや自動化システムを活用することが大切です。
全てを計測する
DevOpsで大切なのは、自社のソフトウェアやシステムのパフォーマンスの全てを計測することです。パフォーマンスを計測して数値化することは、プログラムの修正や新しい製品の開発、DevOpsを成功に導くために必要な作業になります。
SREとDevOpsの違い
SREとDevOpsとの違いは、概ね次の通りです。SREは、課題や起こりうる障害に対する対処法などのメソッドが明確で、エンジニアの役割としても定義されています。一方のDevOpsではそういった点が定かではなく、文化や方針を示す概念です。
とはいえ、いずれも開発担当と運用担当が協力して、より良いソフトウェアやシステムをユーザーに提供することが最終目標という点では共通しています。この目標を達成するには、SREチームを組成することが大切です。
チームによってSREに求められる役割にも違いはありますが、ソフトウェアエンジニアとしての経験は必須といえます。
DevOpsは思想であり、SREは役割である
SREを提唱したGoogleは、DevOpsは思想でSREは役割であると定義しています。どちらも目指す目的のために異なる担当同士が協力するのは同じですが、目的を達成するためのアプローチの方法に違いがあるのです。
DevOpsは思想ですから、チーム同士がつながるための方法を文化的・哲学的な観点から考えます。一方の、SREは役割ですから、ソフトウェアを活用した手法によって解決しようとする組織体制や機能を指すのです。
つまり、DevOpsは、複数の部門をSREという概念へつなげるための媒介装置のようなものであり、SREはつながった担当同士によるチームが、目的を達成するために用いる実装装置のようなものなのです。
SREとDevOpsエンジニアの違い
役割や職種としてのSRE（サイトリライアビリティエンジニア）とDevOpsエンジニアに違いはありません。ソフトウェアエンジニアとして、SREに必要なスキルセットが備わって入れば、DevOpsエンジニアの求人募集にも十分対応できますし、その逆も同じです。
SREやDevOpsのエンジニアに必要なスキルは、クラウド環境の構築や運用の自動化に関する知識や技能、Webアプリケーションの開発や運用、システムインフラ全般に関する知識です。また、開発スピードの向上を実現させるためにも、ある程度のコミュニケーションスキルが必要になります。
AIを仕事にするためのキャリアノウハウ、機械学習・AIに関するTopics、フリーランス向けお役立ち情報を投稿します。
