こんにちは、GIGでバックエンドエンジニアをやらせていただいている庄子です。

最近、私が所属しているチームでは、SRE（サイトリライアビリティエンジニアリング：Google社が提唱、実践しているシステム管理とサービス運用の方法論）を学んでいこうという流れが大きくなっています。

しかし「SREについて精通しまくっているぜ！」という人材は残念ながらおらず、とりあえずみんなで認識合わせのために輪読会を行っています。

その中で、SREとはどういったものなのか、実際にSREを遂行していくためにはどのようなことから始めればよいのかと考えるようになりました。

SREを学んでいこうとなった背景

GIGではクライアントワークの部署があり、その中でもざっくり「開発チーム」と「運用チーム」に分かれています。私が所属している運用チームでは、複数のクライアント様の運用を担当。その中でも、毎月対応するタスクや繰り返し手作業で行うもの、パッケージのバージョンアップデート等を対応するときに、作業が煩雑になりがちでした。

その点に気づいてはいるものの、日々の運用作業に追われ、なかなか改善する時間はとれない状況になっています。なんとかこの状態を打破できないものかとなり、その解決策として浮かび上がったのがSREという考え方でした。

私自身は、SREという言葉自体は知っていたものの、「サービスをダウンさせないようにどうにか頑張る人」というイメージでした。そのざっくりとしたイメージを具体的なものにするために、O'Reilly様から出版されている『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』を輪読会して、SREとはなんぞやを学びました。

SREとは？

まず最初に思ったのは、SREとは何をする人なのかということです。上でも書いているように、「サービスをダウンさせないようにどうにか頑張る人」というイメージがありました。

この本を読んでみて、今感じるSREへのイメージは「エンジニアリングの力で、手作業を効率化する。効率化してできた時間でサービスの安定稼働に寄与することを遂行する。失敗したときは共有する」となりました。かなり長くなってしまいましたが、抽象的な言葉ではなく、具体的な言葉を使って説明するとこうなると思います。

SREがやること

SREがやることとして下記のことが挙げられます。

• SLO、SLI、SLAを決める
• トイル（手作業）を撲滅する
• サービスのモニタリング、適切なアラートを徹底する
• 安全なリリースをする
• サービスを単純に保つ

それぞれについて簡単に説明をしていきます。

SLO、SLI、SLAを決める

SLO、SLI、SLAという言葉を聞いたことがありますか？ SLAは比較的なじみがある言葉だと思いますが、私はSLO、SLIに関してはあまりイメージできませんでした。

SLI（Service Level Indicator）、日本語で言えばサービスレベル指標です。SLIはサービスの状態を測るための指標になります。レイテンシや可用性といった具体的な数値を指定します。

【SLIにすべき代表的な指標】

• サーバーシステム：可用性、レイテンシ、スループット
• ストレージシステム：レイテンシ、可用性、耐久性
• ビッグデータシステム：スループット、E2Eレイテンシ

SLO（Service Level Objective）、日本語で言えばサービスレベル目標です。決めたSLIに対して目標を決めたものを指します。レイテンシで言えば5ms以内に返すなど、可用性で言えば4半期の稼働時間が99.9%といったものです。有名なSLOの例としては、Amazon S3の耐久性は99.999999999％（イレブンナイン）となっています。

また、内部のSLOを外部公開しているSLOより厳しくすることで、安全マージンをとるべきです。SLOを過達成することで、実際のサービスパフォーマンスが基準となってしまうため、公開しているSLOより過剰に達成しないようにしましょう。

SLA（Service Level Agreement）、日本語で言えばサービスレベル合意です。ユーザー間で結ぶ明示的あるいは、暗な契約。また契約が守られた場合、守られなかった場合の規定が含まれています。

ここで、ビジネスに大きく関わるので、SREはSLAの構築には関わらないほうが良いとは言われています。しかしSLI、SLOの構築にはSREが大きく関わってくるので、SLAに対してSREの意見が関係してくることにはなりそうです。

トイル（手作業）を撲滅する

トイルとは「手作業で繰り返し行われ、自動化が可能、長期的な価値を持たず、作業量がサービスの成長に比例するもの」です。トイルはすぐに100%を埋め尽くしてしまう傾向にあります。

SREの活動は以下のように分類できます。

• ソフトウェアエンジニアリング
• システムエンジニアリング
• トイル
• オーバーヘッド（ミーティングや評価面談等の雑務） 

SREは50%以上をエンジニアリングに当てなければなりません。

トイルが増えることによる弊害は、個人の視点で見ると、プロジェクトにかけられる時間が少なくなり、キャリアの形成が難しくなります。組織の視点で見ると、トイルばかりやっている、エンジニア組織ではないと思われてしまう可能性があります。エンジニア組織ではないとわかると、トイルを回されるという悪循環を生みます。

サービスのモニタリング、適切なアラート

特定の値をモニタリングして、値が閾値を越えたらアラートを出すといった方法は効果的ではありません。そのメールを読んで対応している時点で欠陥を抱えるアプリケーションです。

Googleでは時間を元にした可用性メトリクスはとっていなく、リクエスト成功率で可用性を定義しているそうです。このメトリクスはエンドユーザーへの応答に直接寄与しないシステムに対しても、この可用性メトリクスを適用しやすくなります。

【アラートの種類】

• アラート：即座に人間が対応
• チケット：即座に人間が対応する必要はない
• ロギング：人間が見る必要がないもの

安全なリリース

高い信頼性には、信頼性の高いリリースプロセスが必要です。ソフトウェアをビルドし、リリースすることが求められます。リリースは再現性があり、自動化されている必要があります。決して「個性的」であってはなりません。

リリースの手順には、十分なドキュメント化が必要です。リリースごとに手順を確認するような、車輪の再発明は避けましょう。

サービスを単純に保つ

SREの目的はサービスの安定稼働です。しかし、開発者は機能の開発を進め積極的にリリースをしていきたいと考えます。その対立でしばしば開発者との衝突は避けられません。なのでSREのアプローチとしては「システム内でのアジリティと安定性のバランスを取る」となります。

大切なのは「SREの作業が開発者のアジリティに与える影響を最低限にする」ことです。ここでリリースの信頼性が大切になってきます。信頼できるリリースであれば、開発者のアジリティが高まります。

SREにとってプロダクション環境の想定外の複雑さは敵になります。その想定外の複雑さをどのように最低限にするのか。

• システムに想定外の複雑さが生じしていたら差し戻す
• 関わるシステムから複雑さを取り除く取り組みを継続的に行う

以上のアプローチが有効です。また、必要ないコードは積極的に削除していきましょう。システムのモジュール性を保って、部分的にリリースできるようにすると更に安全になります。

更に、複数のリリースを一気に行うのではなく、単一の機能をリリースすることで、事故が起きにくく、また起きてしまった場合でも原因究明がやりやすくなります。

まとめ

ここまで「SREとは？」「SREがやっていくこと」をまとめてきました。

私自身まだまだ実行できていることは多くはありません。最初の一歩としては、所属組織に対して、どのようなフローで開発を行っているか、トイルが発生しているかをヒアリングし、トイルを少なくしていくところから始めるとやりやすいかなと思っています。そこからSREとしてエンジニアリングを活用し、サービスの安定稼働を推進していきたいと思います。

参考文献

t-okibayashi.“監視の通知とメンテナンスについて”.Qiita. 2018年12月06日.https://qiita.com/t-okibayashi/items/efd4a8c19ac9c02f2464, (2022年02月26日)

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔　監訳、Sky株式会社 玉川 竜司　訳, SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム、 O'Reilly Japan, Inc., 2017年08月 発行

庄子肇

バックエンドエンジニア。宮城大学事業構想学部デザイン情報学科を卒業後、ベンチャー企業でエンジニアとして常駐先のシステム開発やサイト制作の経験を積んだ後、2019年10月にGIGにジョイン。