はじめに

オフィスの上のビジネス資料


大規模サイトの信頼性担保の手法としてよく耳にするSRE

SREはSite Reliability Engineeringの頭文字で、サイト信頼性エンジニアリングのことを指します。

ソフトウェアエンジニアがシステムの運用まで設計する体制のことで、後にGoogleのSREチームの創立者となるBen Treynor氏が提唱した言葉です。

SREを実際に行うソフトウェアエンジニアのこともまたSREといい、この場合はSite Reliability Engineerの頭文字を取っています。

従来手法やDevOpsとの違いと、SREの仕事内容および必要とされるスキル・資格についてまとめました。


SREと従来運用の違い

まず、SREは従来の運用方法とどう異なるのでしょうか。

大規模サイトを実現するためのシステムは開発して終わりではなく、ユーザーに問題なく使用してもらえるよう運用していく必要があります。

運用のために必要な作業は多岐にわたり、例えばサーバーマシンやネットワークのセットアップ、ソフトウェアのアップデート、障害対応等です。

従来は、ソフトウェアエンジニアが開発(Dev)を行い、これらの運用作業(Ops)はシステム運用部門の作業者が行う体制となっていました。

これらの部門の橋渡しとしてソフトウェアエンジニアがシステム運用まで設計するのがSREの考え方で、従来手法とは下記の違いがあります。


システム運用作業の自動化

ラップトップPC


従来のシステム運用作業では人手による作業がメインであり、膨大な手間とコストがかかっていました。

エンジニアリングによりこれらの作業を自動化することで作業量の削減が可能です。

これによりコスト削減に繋がるのみならず、人為エラー防止作業品質の均一化にも役立ちます。


エラーバジェットによる優先順位付け

審査する チェック


SREでは予めエラーの発生見込み量を「エラーバジェット」として設定します。

従来の組織体制でありがちだったのが、開発側はどんどんリリースをしたい、運用側はシステムを安定化させたい、と対立してしまうことでした。

エラー数の予算(目標)を持つことで、それを下回っていればリリース作業、上回っていれば既存エラーの優先対応、と機械的に決定することができます。


SREとDevOpsの違い

DevOpsコンセプト


ここまで読まれて「SREがDevとOpsの橋渡しならば、DevOpsの考え方とはどう違うの?」と思われたかもしれません。

実際にこれらの2つにおいて実現したいこと、目指すことは同じと考えて問題ありません。なぜなら、Google社が発表した説明によれば、

class SRE implements DevOps

  出典元:https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends

つまりSREはDevOpsの実装である、具体的には「DevOpsは思想でありSREはその実践方法の1つである」との考え方を示しているためです。

詳しくはGoogle社が上記の考え方を説明している下記リンクも参考にしてください。

What’s the Difference Between DevOps and SRE?(YouTube)


SREの具体的手法

それでは、SREでは具体的にどんな手法でシステム運用の設計を行うのでしょうか。


トイル(Toil)の制限

苦労する人


人による判断・作業のことをGoogleではトイル(Toil:「苦労」の意)と呼び、これを極力少なくするのが基本方針です。

具体的には、SREの仕事のうちトイルが占める割合を50%以下に制限しており、超過した場合はタスクの優先順位変更や他部門への差戻しが行われます。

改善が見られず、トイルの割合が高いままならば必要に応じ組織を解体する場合もあるようです。

このように、徹底してトイルの割合を下げることでSREの本来業務である自動化サービス安定化に重点を置くのが狙いとなっています。


SLO・SLI・SLAによる目標定量化

チャートとグラフが出力されている近代コンピュータ


先述の通り、SREではエラーバジェットを定めることで実施する施策の判断を行います。

ここで出てくるのが下記の指標です。

  • SLO(Service Level Objectives):サービスレベル目標
  • SLI(Service Level Indicator):サービスレベル指標
  • SLA(Service Level Agreement):サービスレベル合意

エラーバジェットを決めるにはまずSLIを決定する必要があり、例えば「リクエストの成功率」とします。

次にSLIについての目標値を例えば「99.95%」としましょう。これがSLOです。エラーバジェットはこの残りの「0.05%」が該当します。

SLAは必要に応じ形成される目標達成に関した合意の事で、例えば「目標達成できない場合は半額返金」等です。

これらの指標を決めておくことで、タスクの優先順位付けを機械的に行い判断スピードを速めることができます。


Infrastructure as Codeによる自動化

ハッカー


従来のシステム運用におけるインフラ管理では、OS・ソフトウェアのバージョン管理システムの構成を人が行っており、台帳等に記録していました。

台帳といってももちろん紙ベースとは限らず、エクセルファイルやメモなど、その運用形態は様々と予想されます。

これはシステムの拡張や変更をあくまで人が実施する前提の運用方法であり、自動化に適していません。

SREではIaC(Infrastructure as Code)という考え方に基づき、マシンが読み込んで自動実行できるよう、これらをコードとして記録します。


SREの仕事内容

実際にSRE(サイト信頼性エンジニア)はどのような役割を持つのでしょうか。仕事の内容を見てみましょう。


サービスの可用性を担保

プラス記号の仮想を持っている手は、コピースペースで肯定的なもの(特典、個人的な開発、ソーシャルネットワーク、健康保険など)を提供することを意味します


システム運用において最も重要なのは、その上で動いているサービスを安定的・継続的に稼働させることです。

何かしらの異常発生や急なリリースに備える保険として冗長構成の設計や実装を行う必要があります。


プロダクト開発のスピード最大化

爆速 インターネット


サービスの安定と対極的に見られがちですが、ビジネス面で成功するにはプロダクトの新機能リリースも怠れません。

先述のエラーバジェットの考え方を元に、可用性担保ばかりに重きを置かず、変更リリースのタイミング設計を行うことも仕事の1つです。


異常の早期検知と復旧

虫眼鏡


冗長構成によりダウンタイムを短縮できるとはいえ、ハードウェアトラブルやソフトウェア変更による性能低下は発生し得ます。

こうした異常を早期に検知するため、システムを構築し定期的に監視する必要があります。

Googleでは検知した異常の順位付けを行うことで、緊急度の高いものについてより早く対応し早期復旧を実現しています。


障害対応やシステム構成の自動化

インターネットプロバイダ


自動化はSREの一番の腕の見せ所で、主に障害対応システム構成の場面で活きてくる業務です。

Googleでは、SREが疑似障害を一通り対応後、自動化しておけばより早く対応できたと思う項目を選定、実際に自動化するという訓練方式で行われています。

システム構成についても先述のIaCの考えに基づきコード化しておく、必要なツールを準備しておくといった内容がメインです。


SREに必要とされるスキル

ここまで見てきた業務をこなすために、どのようなスキルセットが必要とされるのかを確認しましょう。


サーバーの構築・運用技術

ビッグデータサーバルーム


システム運用がSREのメイン業務となるため、インフラに関する知識、特にサーバーの構築・運用技術は必須です。

Linux系OSを使いこなせることはもちろん、クラウドサービスネットワークプロトコルに関する知識があると良いでしょう。

実際にクラウドサービスを運用した経験があればさらに歓迎されやすいです。


Webアプリ開発・運用技術

マシンコード言語


アプリ性能の異常を検知し適切に修正していくには、もちろんアプリに関する知識が必要になってきます。

サーバーサイドの代表的なスクリプト言語であるRuby・PHP・Java・Python等が理解できると良いでしょう。

こちらも実際にWebアプリを開発・運用した経験があればさらに歓迎されやすいです。


セキュリティ知識

インフラエンジニア


Webサービス開発と運用に関わるにあたり、基本的なセキュリティに関する知識は必要です。

攻撃を防ぐために最低限これだけは押さえておくべき、という内容が分かっていれば良いでしょう。


SREが取得すべき資格

実際にSREになるために必要な資格というものは現在のところ存在しません。

しかし、この資格があれば「SREとしての役割が十分果たせる」とみなされるものがいくつかあります。

これからSREを目指したいが経験面でのアピール力に自信がない方、自分のスキルが十分かどうか腕試しをしたい方はチャレンジをお勧めします。


DevOpsプロフェッショナル試験

リンククラウド技術


AWS認定のDevOps試験です。

2年以上の経験を持つDevOpsエンジニアを受験者対象としているため、既にある程度SREに近いことを実施している方向けの試験といえるでしょう。

内容も上級者向けで、AWS認定のため当然ではありますがAWSの使用を前提としています。

試験ガイドやサンプル問題については以下の公式ページをご参照ください。

AWS認定DevOpsエンジニア-プロフェッショナル


Cisco系資格(CCNA/CCNP)

サーバセンター


CCNA・CCNPはネットワークエンジニア向けのCisco技術者認定試験ですが、SRE募集案件でも歓迎スキルとして挙げられていることが多いです。

Ciscoが設けている認定試験のうちでCCNAは難易度レベル2、CCNPはその1つ上の難易度レベル3となっています。

CCNAが基礎知識、CCNPが実用向けの位置付けといえるでしょう。

いずれも複数の分野コースに分かれており、どれか1つの分野でも合格すれば資格ホルダーとなります。

また、CiscoでもDevOpsの資格である「DevNet」認定試験が開始したので、そちらの受験を検討するのも良いでしょう。

Ciscoの認定試験公式サイトでは学習のための情報が充実しているので、ぜひ一読してみることをお勧めします。


AWS・Azure・GCP等のクラウド公式認定試験

クラウドコンピューティングとビジネスマンの手の働き


SREは大規模サイトの運用を前提としているため、クラウドサービスを使いこなせると重宝されます。

そのスキル証明として、メジャーなクラウドサービス(AWS・Azure・GCP)が公式認定している試験を受けるのも良いでしょう。

AWSの認定試験は種類が多くどれを受ければいいか迷うところですが、クラウドスキルの証明であれば中級の取得で十分です。

具体的には「AWS認定アソシエイトレベル」のソリューションアーキテクト・開発者・SysOpsアドミニストレーターのいずれかになります。

詳しくはAWS認定試験公式ページをご確認ください。

Azureの試験については、中級(Associate)レベルの取得を目指すと良いでしょう。

詳しくはAzure認定試験公式ページをご確認ください。

GCPの試験はアソシエイト(初級)レベルとプロフェッショナル(中級)レベルに分かれています。

中級試験はさらにいくつかの分野ごとに分かれていますが、どれもSREと相性の良いものばかりです。

得意分野を生かしてまずは中級のうちどれか1つの取得を目指すと良いでしょう。

詳しい情報は GCP認定試験公式ページをご確認ください。


SREの年収

仕事 収入


SRE採用は増加傾向にあり、特に大きな規模のサービス運用をしている企業での募集が増えています。

提示年収については、採用募集情報によれば500万円〜800万円がメインレンジ、ポジションによっては1,000万円台のこともあるようです。

サイト運用で重要な役割を担うだけあり、通常のソフトウェアエンジニアと比較しても高めの年収が提示されるケースが多くなっています。


SREの将来性

ビジネスマン 


ここまで見てきて感じた方も多いかもしれませんが、SREは将来性のある職業といえます。

自動化」というキーワードはAI人気も相まって注目度の高いフレーズです。

システム拡張や変更、障害対応への自動化ニーズは今後もますます高まっていくことでしょう。

また、エンジニアの人手不足も追い風です。世界中でIT化が推進される中、IT人材不足の解消には目処が立っていません。

運用にかかる手間を削減し開発へのリソース集中を可能にするSREへの需要は高まること間違いなしです。


まとめ

会社 会議 スーツ 男性


SREについて、その概要や仕事内容、求められるスキルについてご紹介しました。

開発チームと運用チームの間を取り持つ新しい重要なポジションです。

これまで開発しか経験がない、逆に運用しか経験がない、という方もぜひ参考にしてみてください。