企業が経済活動を行う上で、欠かせない存在となっているITの力。しかし、ITの力を活用したサービスの展開やインフラの整備を進める上で、さまざまな課題が現れることも事実です。
そこで今回は、ITの力を活用する上で現れる課題解決と、ユーザーからの信頼性向上のために欠かせない「SRE(サイト信頼性エンジニアリング)」の存在について解説。近ごろ耳にする機会も増えてきたSREの特徴やメリットに迫ってみましょう。
SREとは
SERは、Googleが自社の検索エンジンであるGoogle.comを安定的に稼働させるために実施したアプローチのこと。「Site Reliability Engineering」を略してSREと呼ばれており、日本語に置き換えると「サイト信頼性エンジニアリング」という意味になります。
Googleでエンジニアの職に就いていたBen Treynor氏が、SREの手法について提唱。その定義について、自身の著である「Site Reliability Engineering」で触れています。Ben Treynor氏によるSREの定義は、以下の通り。
SRE is what happens when you ask a software engineer to design an operations team.
『SREとはソフトウェアエンジニアに運用チームの設計を依頼したときに起こるものです』
our Site Reliability Engineering teams focus on hiring software engineers to run our products and to create systems to accomplish the work that would otherwise be performed, often manually, by sysadmins.
『サイト信頼性エンジニアリングチームは、ソフトウェアエンジニアを雇って製品を動かし、システム管理者が手動で行っている作業を達成するためのシステムを作成することに重点を置いています』
これまでエンジニアは、開発と運用とでチームが分けられていました。しかしこのチームの在り方では、それぞれの目的が異なり負担のかかり方も大きく違ってきます。開発チームは利便性を追求するあまり、運用チームにかかる保守・管理の負担を顧みないケースが後を絶ちませんでした。
そこで、開発段階から保守・管理しやすいシステム生み出すために、チームの在り方を見直し。SREチームを組み、そこで先に保守・管理しやすいシステムを設計することで、信頼性の高いシステムを生み出し続けることに成功したのです。
現在では広範囲に渡るソフトウェア開発を行うのはもちろん、組織の中でも独自の働きを担う存在として、SREに注目が集まっています。
SREの考え方
開発チームと運用チームの垣根をなくす存在であるSRE。どのような考え方をもとに、その役割を果たしていくのでしょうか。
エラーバジェットの設定
エラーバジェットの設定は、SREの特徴として挙げられる項目の一つ。エラーバジェットとはわかりやすく言えばエラーに対する予算のことであり、SREはエラーバジェットの設定が適度であるかどうかを重視しなければなりません。
ITシステムを構築する場合、エラーを起こさないことは大きな目標の一つとなります。しかしその目標を達成するために膨大な時間とコストを費やしてしまえば、結果的に組織としてのパフォーマンスは低下してしまうのです。
現実的ではないダウンタイムゼロを目指すのではなく、現場の負担とエラーに対する費用対効果のバランスを取るという考えは、SREならではだと言えるのではないでしょうか。
トイルの削減
SREにとっての大きな目標の一つが、トイルの削減。トイルとは、「労力」という意味を持つ言葉であり、トイルの削減は「機械で自動化できる手作業」のことを指します。
ソフトウェアエンジニアによって、IT運用担当者の通常業務を効率化・自動化することがSREの役割。日々トイルを洗い出し、トイルにかける労力を削減するための体制を構築するというは、SREの役割を果たすために欠かせない考え方であると言えます。
SLIの計測とSLOの設定
SLIとSLOも、SREにとって重要な役割を果たす存在の一つ。サービスレベル指標を指すSLIと、サービスレベル目標を指すSLOを測定・管理し、サービスの品質を維持できるように導きます。
サービス品質は、高すぎても低すぎてもいけないもの。適度なサービス品質を保つためには、SLIとSLOの計測・管理が欠かせません。SLI・SLOの計測・管理の結果、SLOが達成すればSREは加速していきます。
ポストモーテムの徹底
ポストモーテム（事後検証）は、SREの定着に欠かせないプロセス。アクシデントが起こった際の原因を究明し、文書化します。さらに、部署の垣根を超えてレビューを実施することで、さらなるSREの加速が期待できます。
SREを取り入れるメリットと注意点
GoogleやMetaと言った大企業で取り入れられているケースの多いSRE。中小企業にとっては、SREを取り入れるメリットを見出せないところも少なくないのが現実です。しかし落ちないシステムを生み出すSREは、企業の大きさ関係なく取り入れるメリットがあると言えます。
SREを取り入れることで得られるメリットは、「パフォーマンスの向上」・「生産性の向上」・「運用業務の負担軽減」など。SREは開発・運用という垣根なくシステムの開発に関わるため、これまで以上に安定したサイトやサービスを作り上げることができるようになります。結果、ユーザーからの信頼度が上がり利益もアップするのです。
また、SREを取り入れることで人為的なミスを減らすことにも直結。トイルの削減によってエンジニアの対応コストも抑えることができ、生産性の向上にもつながっていきます。
SREは開発と運用の垣根だけでなく、事業部門とIT部門の垣根をなくすことができる存在であるため、さまざまなプロジェクトに対してメリットをもたらすのです。
しかし一方で、中途半端な意図でSREをと入れることは危険だという考えがあるのも事実。SREのメリットを最大限に引き出すには、“明確な目的”と“何をもってSREのメリットとするのか”をはっきりさせておくことが大切です。
SREを取り入れたからその恩恵が受けられるという考えではなく、SREを何のために取り入れたいのかを明確にして初めてそのメリットが見えてくるという考えを持っておかなければいけません。
SREとDevOpsの違い
Googleで生まれたSREという考え方ですが、実は同じような意味で使われている言葉がもう一つあります。それは、「DevOps」という言葉。DevOpsは、Development（開発）とOperations（運用）を組み合わせて作られた言葉で、開発と運用の担当者それぞれが協力し合う開発方法のことを意味しています。
SREもDevOpsも開発と運用の垣根をなくすという意味では、ほぼ同じように使える言葉。しかし、厳密にはそれぞれ違いがあるのです。
SREとDevOpsの違いについては、Googleが提唱したclass SRE implements DevOpsの考え方がわかりやすいとされています。class SRE implements DevOpsとは、日本語に訳すと「SREはDevOpsを実装します」という意味になります。つまり、DevOps＝思想であり、SREはそれを具体化・実装したものであるということです。
DevOpsの主な目的は、開発担当者と運用担当者がお互いに協力して、リリースサイクルの短縮を目指すこと。一方SREの主な目的は、インフラを整備したり自動化ツールを開発したりして、サイトやサービスの信頼性を高めてそれを維持することです。
それぞれのニュアンスの違いからわかるように、SREはDevOpsがあってこそ実現できる考え方。それぞれ概念的な部分が多いですが、同じ意味で使われている言葉ではないということはきちんと認識しておきましょう。
まとめ
ITサービスのインフラ運用や改善は、企業にとって欠かせないプロセスの一つ。DevOpsと同じく、SREは今後のトレンドとなる分野です。
従来のシステム運用が抱える課題を解決するためには、SREの考え方が有効。今後ますますの広がりが期待されるSREは、企業の経営に大きなインパクトを与える存在となることでしょう。
