SREエンジニアとは？職場の様子や仕事内容は？必要なスキルや将来性を解説

近年は、一言でITエンジニアと言っても、様々な職種が存在します。
 ・インフラエンジニア
・サーバーサイドエンジニア
・フロントエンドエンジニア
・フルスタックエンジニア
 それぞれが得意とする業務に特化した知識や経験を持ち、その他の部分は他のエンジニアに任せる。

そういった分業がされるようになってきました。 そんな中で、SREエンジニアという言葉を聞いたことがあるでしょうか。 このSREエンジニアは、一言で言うと 「WEBサイトやサービスを安定稼働させる役割を持ったエンジニア」 になります。 24時間年中無休のWebサイトやサービスは、どのようにシステムメンテを行っているか疑問に思ったことはありませんか。

SREエンジニアは、このような運用を支える職種で、Web系システムの ・安定稼働と新サービスなどの迅速なリリースが両立できるように運用 ・運用業務の人手作業を自動化 する役割を担っているのです。 ここでは、SREエンジニアの生まれた背景や、職場のミッションや役目、仕事内容、求められるスキルや知識、:経験、将来性などについて解説します。

SREエンジニアとは

SREエンジニアとは、Googleが提唱する、システム管理とサービス運用の方法論です。 Web系システムの高い信頼性と価値を向上させる方法論として注目されています。 SREエンジニアは、SREに従ってシステムの運用業務を行う一方で、運用の自動化や効率化にも注力するソフトウェアエンジニアの職種です。 運用の自動化や効率化、及び信頼性やパフォーマンス改善に関係しないアプリケーションの開発などはSREエンジニアの仕事に含まれていません。

SREが注目される背景

コロナ禍で、多くの企業は業績が悪化しています。 しかし、そんな中でも顧客ニーズに直結したサービスを『迅速に』展開する企業は業績を伸ばしています。 24時間年中無休の大規模なWebサイトやサービスを運営する企業もその中の1つです。 このような企業は、市場ニーズの変化に機敏に対応して、顧客からの信頼性を得ることに成功しているからです。 しかし、多くの企業は 「新しいサービスの開発が求められる一方で、24時間稼働しているからリリースタイミングが難しい」 という悩みを抱えています。 そこで、 「システムの安定稼働と新サービスなどのリリースを両立させる」 というSREの考え方を取り入れれば解決できるという期待があり、大規模なWebサイトやサービスを運営する企業ではSREが注目されています。

SREの概要

SREという方法論が誕生した契機は、Googleが検索エンジンサイト「google.com」を安定稼働させるために、運用担当者でなく開発担当のソフトウェアエンジニアを投入したことです。 SRE（Site Reliability Engineering）のSiteはこれにちなんだものですが、Webサイトやサービスを指すと考えて良いでしょう。 従って、今ではSREは 「Webサイトやサービスの信頼性向上に向けた取り組みを行い、価値の向上を進める」 考え方および方法論とされています。 つまりSREとは 「システムの安定稼働と顧客のニーズに応えた新サービスなどの迅速なリリースを両立させる」 ものと言えます。 これ以外に、SREでは 「運用業務における、手作業や人による判断の多い作業を自動化することによるコスト削減」 も行います。

SREエンジニアという職種が必要とされる背景

次に、SREエンジニアという職種が必要とされる背景について見ていきましょう。

インフラエンジニアやシステム運用エンジニアに欠けているもの

インフラエンジニアの仕事内容はインフラの設計や構築、運用です。 また、システム運用エンジニアの任務はシステムを正常に稼働させることです。 そのために、サーバーの障害やシステムの不具合に備えて、 ・システム監視や予防措置を講じる ・バックアップをとる ・障害が発生した場合には復旧する といった業務をします。 インフラエンジニア・システム運用エンジニアとも、 「システムの安定稼働と新サービスなどのリリースを両立させる」 という視点はありません。 これが、SREエンジニアが必要とされる理由の1つです。

DevOpsエンジニアに欠けているもの

SREと混同されやすい言葉にDevOpsという言葉があります。 「開発チームと運用チームが互いに連携することで、価値の高いアプリケーションを迅速に届ける」 という目的では、両者は一致しています。 しかし、DevOpsが求めるのは、このような目的に沿うように開発と運用を進めることで、詳細はDevOpsエンジニアに委ねられています。 DevOpsエンジニアは、インフラ周りの構築やメンテナンス、システム開発から運用まで担い、開発チームと運用チームの橋渡し役を務めます。 このため、高いコミュニケーションスキルと幅広い技術を持つジェネラリストである必要があります。 一方で、 「システムの安定稼働と新サービスなどのリリースを両立させる」 という役割を求められていないのがSREエンジニアとの最大の違いです。

SREエンジニアが活躍する職場

SREエンジニアが活躍する職場

ここでは、Googleなどの先進事例を参考に、SREエンジニアが活躍する職場がどのようになっているか見ていきましょう。

SRE組織と運営方針

SREエンジニアに限らず、これから就職や転職を目指す方にとって、目指す職場がどのように運営されているか、事前に知っておくことは大変役立ちます。 そこで、ここではSRE組織とはどんなもので、どのように運営されているのか見ていきましょう。

開発と運用が一体となった組織

従来は、 ・ソフトウェアエンジニアは開発部門に所属してアプリケーションを開発する ・運用は運用部門の作業者に委ねる という具合に、組織が分かれていました。 Googleの作ったSRE組織は開発と運用の垣根を取り払って1つにした組織です。 ソフトウェアエンジニアとシステムエンジニアで構成されています。 この解説記事の中では、 ・SRE組織は開発チームと運用チーム、SREチームで構成されている ・SREチームが開発チームと運用チームに働きかけてSREを推進する責任を負う ・SREエンジニアはSREチームに属する ものとして説明します。

トイル対応時間に上限を設定

運用業務には手作業や人が判断する作業が多くあります。 その中には、ソフトウェアエンジニアから見れば、自動化できるものが多々あるので、SRE組織では運用業務の自動化を進めます。 運用作業のうち自動化できるのに手作業で行っている（トイルと呼ぶ）労働時間が全労働時間に占める割合の上限を、Googleでは組織全体で50%としています。 残りの時間を自動化のためのコーディングやサービスレベルの向上に関わる仕事にするようにしています。 上限の50%をオーバーした場合は、組織の見直しもあります。

エラーバジェットでサービスの停止を管理

システムの安定稼働と新サービスなどのリリースを両立させるために、エラーバジェットという考え方でサービスの停止を管理します。 そのためSRE組織では、可用性／SLI／SLO／SLA／エラーバジェットという考え方を導入し、許容された枠内ならサービス停止を許容する運用を行います。 可用性とはサービスが利用できる時間比率のことです。 サービスレベルの目標（SLOという）を99.99%とした場合、サービスを止めてよい合計時間（エラーバジェットという）は年間52分36秒となります。 また、このような目標をサービスのオーナーとの間で事前に合意（SLAという）する必要があります。 なお、SLIはサービスの信頼度を実測した指標です。 一例を挙げれば、アプリケーションのHTTPリクエスト成功率の実測値がSLIで、これに対応して目標値SLOを設定します。 例えば、1万回の成功と5回の失敗が実測された場合、SLIは99.5%となります。 SLOを99%とすると、10回までなら失敗が許されることになります。

SREチームのミッション

組織と運営方針以外に、職場のミッションが何なのかを知っておくことは、就職先や転職先での自分に対する期待を理解する上で極めて重要です。 ここでは、SREチームのミッションについて見ていきましょう。

サービスの可用性と開発速度最大化の両立

ここでは、前節のエラーバジェット年間52分36秒の例を用いて説明を続けます。 このエラーバジェットの中に、新サービスやバグをリリースしたり、メンテナンスや障害などで止まる時間などが全て収まればSLAの合意範囲ですから責任を問われません。 しかし、それを超過した場合にはSLAに反しますから責任を問われます。 そこで、サービスの新規開発や改造を行う際は、リリース時のサービス停止時間が残されたエラーバジェットに収まることをチェックし、開発内容に優先順を付ける必要があります。 このようにして、リリース時のサービス停止時間がエラーバジェットに納まる範囲内で、最大限のサービスの開発や改善を行います。

サービスの異常を早期検知する仕組みの構築

可用性以外に、システム異常が原因でサービス品質が劣化することがありますから、システム異常を早期に検出し、手を打つ必要があります。 システム異常の原因としては、 「機器の故障や劣化による可用性の低減」 「アプリケーション更新に伴うレスポンス遅延」 などが考えられます。 Googleでは、下記の3つに分類して異常を管理しています。 (1)アラート：即時対応が必要、サービス停止などの時 (2)チケット：緊急でないが対応が必要、リソース使用量が増加している時など (3)ロギング：問題が発生した場合の分析や追跡のため

運用業務の自動化

前述のように、運用業務の自動化はSREチームのミッションの1つです。 具体的には、 ・運用チームが日常行っている業務を細かく点検 ・ソフトウェアエンジニアの目線でチェック を行い、自動化出来そうな箇所を見つけて自動化します。

SREチームの役目

SREチームがミッションを果たすために、SREチームには開発チームや運用チームを指導して実施させる役目があります。 ここではその役目について見ていきましょう。

事前対策をとって可用性SLOを運用チームに遵守させる

24時間年中無休の大規模サイトを運営する企業の場合、可用性のSLOは極めて高いです。 エラーバジェットで、極めて短時間のサービス停止は認められているといえども、運用する側の心構えとしては 「サービスが停止しないような運用」 を追求すべきです。 このため、システムに不具合が生じた場合の保険の意味で、予備として同系統のシステムを準備することも考慮すべきです。

開発チームを指導してパフォーマンスを維持・向上させる

サービスの停止には至りませんが、ユーザー数の増加など様々な原因でパフォーマンスが低下することがあります。 例えば、マイクロサービスアーキテクチャを持つアプリケーションを利用したサービスの時は、HTTP通信に関して次の3項目 ・レイテンシー：リクエストに対するレスポンス時間 ・リクエスト成功率：リクエストに対して処理が失敗した比率 ・システムスループット：単位時間あたりの処理可能リクエスト数 をSLI／SLOに設定してパフォーマンスの異常を検出し管理することが多いです。

システム変更に対応する業務の自動化を運用チームに促す

大規模システムの場合、運用チームは新しいアプリケーションや改造したアプリケーションを複数のサーバーにインストールしたり設定したりすることが必要となります。 設定内容をExcelなどで管理して人手操作でサーバーに一台ずつ設定すると、サーバー台数が多いと大変な作業量となります。 これは、前述の 「トイル対応時間に上限を設定」 で述べたトイルの典型的な例と言えます。 構成管理ツール（IaCツール）を利用することで、この作業は自動化できます。 このような自動化を促すよう指導するのもSREチームの役目です。

役目を果たすのに必要なSREチームの仕事

SREチームには、前記の役目を果たすために、次のような仕事を行う必要があります。

運用業務の土台を整える

SREチームの役目の1つである 「運用業務の自動化」 を行うためには、自動化できるように運用業務が整備されていることが前提となります。 そこで、運用業務が整備されている／整備されていないことについて考えましょう。 運用チームが 「あるサービスの運用に詳しい人が1人しかいなく、運用方法のマニュアルもない」 という状況だとします。 このような状態は、運用業務の土台が整っていない状況と言えるでしょう。 このような場合、 「複数人でできるようにしたり、ドキュメントを整備する」 ということが、運用業務の土台を整えることに当たります。 このようにして運用業務の土台が整え終わってから、「運用業務の自動化」を具体的に進めることになります。

アプリのリリースについて優先順序を設ける

新規アプリのリリース以外に障害対応でアプリを緊急にリリースしたい場合もあります。 エラーバジェットにより許されている「年間のサービス停止時間」について、 ・どのような優先順位で使うかをチーム内で合意しておくこと ・それに従って個別のリリース要求に対応すること が必要です。 この際、ビジネス上の重要性や障害の深刻さ、緊急性などから様々な観点から詰めおく必要があります。

リリースに伴うトラブルに備える

開発チームは、リリースしたアプリケーションにバグが残っていたり、想定外の動きをしたりすることを避けるために検証環境で十分なチェックをします。 それにも関わらず、チェック漏れで本番でトラブルを招く可能性もあります。 このため、目立たずに試せるカナリアリリースを行うことも考えると良いでしょう。 なお、カナリアリリースとは一部ユーザーのみに限定して公開することです。

開発チームとの密着を避ける

開発チームが、SREチームに密着し過ぎて自律した活動ができないような事態は避けるべきです。 開発チームが自律して活動できるように、仕組みやツールを提供しましょう。 例えば、 ・構成管理ツールで、構成をコード化して両チームで共有する ・監視アラートに関するドキュメントやルールを両者で決めて共有する などです。

SREエンジニアになるには

 

SREエンジニアになるには

ここでは、SREエンジニアという職種に就くことを目指す方に役立つ情報を紹介します。

SREエンジニアに求められる知識とスキル、経験

SREエンジニアに求められる知識とスキル、経験などについて紹介します。 なお、開発チームや運用チームを指導する立場上、コミュニケーション能力は不可欠です。

開発チームの指導に役立つもの

プログラムの何処にパフォーマンス検出の仕組み（SLI／SLOを設定）を埋め込むか判断する際に、 ・Webサービスの開発スキル ・クラウドサービスに関する知識 ・ネットワークプロトコルに関する知識 が役立ちます。 また、新規作成したアプリケーションが必要なパフォーマンスを得られない場合は、データ構造やアルゴリズムの見直しなどを開発チームに行ってもらいます。 この場合、 ・アプリケーション開発に関するスキル ・非効率なプログラムを書き換えてパフォーマンスを向上するスキル ・JavaやPHPなどのプログラミング言語やミドルウェアに関する知識 があれば、開発チームの指導に役立ちます。 なお、開発チームのソフトウェアエンジニアを指導する立場上、単なるスキルや知識だけでなく経験も必要とされる場合が多いです。

運用チームの指導に役立つもの

運用業務の土台を整えたり、自動化を行うために、 ・Webサービスの運用スキル ・クラウドサーバーの構築・運用スキル ・ネットワーク・データベースに関する知識 が役立ちます。 これらの知識やスキルは、障害発生時の対応やWebサービスの品質向上、パフォーマンス向上などの指導にも役立ちます。

SREの学習機会

SREに関する学習サイトやプログラミングスクールの講座は現在ありません。 Googleで調べると、自主的な勉強会などがあり参加を呼びかけています。 日本語の単行本としては下記の2冊あります。 最初に紹介するのは 「SREサイトリライアビリティエンジニアリング－Googleの信頼性を支えるエンジニアリングチーム」 です。 この本では、サービスの稼働と信頼性の維持がサービス設計の基本であるとし、行動の基礎となる原則と理論を述べています。 2番目に紹介するのは 「サイトリアイアビリティワークブック－SREの実践方法」 です。 この本は前記本の実践編として書かれており、SREを組織やプロジェクトで導入するにあたり、必要となる具体的な方法と手順を解説しています。

SREエンジニアの将来性

24時間年中無休の大規模サイトやサービスを運営する企業では、 ・新しいサービスを早期に提供したいが、提供中のサービスを止めたくない ・運用業務には人手作業が多く自動化が進んでいない などの悩みを抱えています。 SREエンジニアには、このような悩みの解消が期待できますが、まだ認知度は低いです。 しかし、SRE導入事例などが増えてくれば、SREおよびSREエンジニアの認知度も一挙に上がると思われます。 政府でも民間企業のDX化を推進しており、DevOpsにも言及しています。 これらに関連して、今後はSREエンジニアに関しても、注目される可能性は高く、将来性も高いと言えるでしょう。

中長期的な目線でビジネスを展開するならAMELAに

中長期的な目線でビジネスを展開するならAMELAに

今回は、少し難しい話になりましたが、SREエンジニアという職種について見てきました。 日本ではまだまだ認知度が低いですが、24時間365日動いて当たり前と考えられている現代のWEBサービスでは、こういったSREエンジニアのような仕事が重要視されていくのは当然の流れでしょう。 もしも現在、自社でWEBシステムを提供している企業様や、これから自社サービスを展開したいと考えている企業様は、是非AMELAにご相談ください。 専門のITコンサルタントが、しっかりとヒアリングし 「中長期的に成長し続けられるビジネスプラン」 をご提案させていただきます。