【採用担当が学ぶエンジニアリング #4】SREについて学ぶ
こんばんは、第四回のエンジニアリング勉強会です。
今回は、SREをメインテーマとして、学んでいきます。
非エンジニアがまとめている、すでにまとめられている内容を編集したりして、自分勉強用に再編しています。
参考サイトからの引用も多いですが、ご了承ください。
このテーマを選んだ理由
SREの概念は、企業によって異なり「SRE」という言語の中身が実に曖昧で、理解が浅いと感じているためです。
また、書類選考時にSRE職種で応募が来た際、スペックの図り方が、「非エンジニア」には今いち理解できず難しいからです。
「本当は、SREエンジニアとして優秀な人であるにも関わらず、見逃してしまった。」なんて悲劇を起こさないように、一度腰を据えて勉強しようと思った次第です。
今回の参考サイト
そもそも「SRE」とは何か？
SREの正式名称は、Site Reliability Engineer(ing)です 。
GoogleのBen Treynor Sloss氏が、運用チームを設計する中で作られた運用の形です。
信頼性こそが、あらゆるプロダクトの基本的な機能として位置づけます。
SREは「システムのスケーラビリティ」「信頼性」「効率性」を向上させるために、その設計と運用の改善方法を見つけることに集中します。
システムが「十分な信頼性」を持ったら、機能の追加や新プロダクトの構築のために力を注ぐとされています。
SREで大切にされる「信頼性」ってなに？
信頼性とは、
「システムが求めらている機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率」
のことです。
奇跡のような派手なことは起こさないけど、言われたことはちゃんとやるということですね。
自動化の必要性について考える
運用というのは、可用性(*)との戦いとも言えます。
システムは、障害が生じれば停止してしまいます。
その上で、メンテナンス・アップデートがあり、ユーザーの増加に伴い、適切にキャパシティを変更する必要があります。
最初は実にシンプルなので、誰でも運用することはできます。しかし、運用は時間の経過とともに大変になっていきます。
サービスが大きくなるにつれ、次第にシステムは複雑性を増し、障害ポイントは増え、複合的な要因による障害や不具合も発生するようになります。
そのような状況に比例して、人手による運用が、果てしなくスケールしていくものは非現実的です。
「システムの規模」や「システムの複雑性」に人の手が追いつかなくなる日は、必ず訪れます。
そうなると何か問題が起きても対応しきれず、システムはダウンし、ユーザーにとって不幸な結果を生み出します。
可用性を高めるには、
「人手による運用はやめ、自動化できるものを自動化し、プロダクトの運用をスケールできるようにする」
必要があります。
(*)可用性とは、システムが継続して稼働できる能力のこと。
開発効率の向上
何か不具合があったときに、修復のスピードが遅ければ、可用性を下げる要因になります。
できる限り効率的な開発ができるようにすることもSREの仕事と言えます。
DevOpsとの関係
「DevOps(*)は 文化」 で、「SREは 役割」 です。
Googleの中の人が class SRE implements DevOps と言っていますが、これは方便のようなもので、運用や開発の効率を高める上でDevOps的な形になるということだと思います。
(*)DevOps（デブオプス）とは、 開発手法やツールを使用し、開発者（Development）と運用者（Operations）が密接に連携し、 より柔軟、かつスピーディーにシステム開発すること。
補足：
Dev＝「好きなサービスを、好きなときにローンチ(*)したい。」
Ops＝「一度動いたシステムは、できるだけ変更したくない。」
このような考え方の違いから、対立が生じる場合もある。
(*)新しい商品やサービスを世に送り出すこと
SREと開発チームの関係
例えばGoogleでは、SREチームは稼働時間の50%以上を自動化等の開発に当てます。
それができなくなった場合は、開発チームがSREの仕事に加わります。また、SREはいつでも開発チームに参加することが可能です。
理想の状態は、
誰でもSREの仕事ができ、SREもアプリケーション開発ができる状態
です。
SREのいるプロダクト組織は、ひとまず目指すべき目標だと言えるでしょう。
以上になります。いかがでしたか？
これからも、エンジニア採用を成功させるために勉強を続けていきたいと思います。
サポートいただけると嬉しいです！励みになります。