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

最近は、一言でITエンジニアと言っても様々な職種に分類されます。 インフラエンジニア、フロントエンドエンジニア、サーバーサイドエンジニア・・・ その中で、SREエンジニアという言葉を聞いたことがありますか。 SREエンジニアは、 ・Web系システムの安定稼働と、アプリケーションのリリースが両立できるように運用する ・運用業務の人手作業を自動化する ことで利用者からの信頼性を得る役割を担う職種です。 ここでは、SREエンジニアの生まれた背景や、職場のミッションや役目、仕事内容、求められるスキルや知識、経験、将来性などについて解説します。

SREエンジニアとは

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

SREが注目される背景

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

SREの概要

SREという方法論が誕生したのは、Googleが検索エンジンサイト 「google.com」 を安定稼働させるために、運用担当者でなく開発担当のソフトウェアエンジニアを投入したことです。 SRE（Site Reliability Engineering）のSiteはこれにちなんだものですが、Webサイトやサービスを指すと考えて良いでしょう。 従って、今ではSREは 「Webサイトやサービスの信頼性向上に向けた取り組みを行い、価値を高める」 考え方および方法論とされています。 そのためには、前節で述べた背景を考慮すれば、 ・システムの安定稼働 ・顧客のニーズに応えた新サービスなどのリリース を両立させるものと考えて良いでしょう。

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

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

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

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

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

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

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

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

SRE組織と運営方針

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

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

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

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

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

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

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

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チームの役目の１つである「運用業務の自動化」を行うためには、自動化できるように運用業務が整備されていることが前提となります。 そこで、運用業務が整備されている／整備されていないことについて考えましょう。 運用チームに「或るサービスの運用に詳しい人が１人しかいなく、運用方法のマニュアルもない」状態が潜在しているとします。 また、「サービス稼働に問題が生じても、それを検知したり、問題を究明したりする文化がない」状態があったとします。 このような状態は、運用業務の土台が整っていない状況と言えるでしょう。 このような場合、 ・前者の場合は、複数人でできるようにしたりドキュメントを整備する ・後者の場合は、サービス稼働中に発生する問題を検知して、問題を究明して解決する文化を育てる ことが、運用業務の土台を整えることに当たります。 このようにして運用業務の土台が整え終わってから、「運用業務の自動化」を具体的に進めることになります。

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

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

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

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

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

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

SREエンジニアになるには

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

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

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

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

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

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

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

役立つ資格

SREと銘打つ資格はありませんが、Microsoftの行うDevOpsの認定試験 AZ-400：Designing and Implementing Microsoft DevOps Solution にはSRE戦略も含まれており、最もお薦めの資格です。 これ以外に、各分野の専門性を認定した資格として以下のものがあります。 ・EXIN DevOps Proffetional　資格：DevOps ・Cisco Certified DevNet Associate 認定：アプリけーションの開発・運用スキル ・AWS認定：AmazonのAWS認定試験：基礎から専門まで４レベル ・Proffesional Cloud Architect：Cloudに関する知識

SREの学習機会

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

SREエンジニアの将来性

24時間年中無休の大規模サイトを運営する企業では、 ・新しいサービスを早期に提供したいが、提供中のサービスを妨げたくない ・運用業務には人手作業が多く自動化が進んでいない などの悩みを抱えています。 SREエンジニアには、このような悩みの解消が期待できますから、 ・まだ、生まれたばかりの職種で認知度は低いですが、 ・SRE導入事例などが増えてくれば、認知度も一挙に上がる と思われます。 政府でも民間企業のDX化を推進しており、DevOpsにも言及されています。 SREはDevOpsを、企業の実態に合わせて現実的・具体的に推進する要素があります。 このため、DXを推進する企業でもSREエンジニアが活躍することも期待されます。 以上から、SREエンジニアの活躍の場は今後、もっと広がっていくと思われます。