みなさんこんにちは。
虎の穴ラボのY.Fです。今回の記事は久しぶりの書評になります。
筆者は普段、虎の穴ラボの中の、アーキテクトチームと言うチームで働いています。現状のアーキテクトチームのお仕事としては、
- 虎の穴ラボの技術ブランディング
- 新規システム構築時の技術選定
- 新規システム構築時の全体的な設計の確認
- 継続的な技術レベルの向上
- インフラ等のコスト削減
- 全般的なセキュリティ強化
アーキテクトチームの具体的な内容は以下を御覧ください。
今回の書評は、上記アーキテクトチームで働いている筆者が、オライリー社から出版されている『SRE サイトリライアビリティエンジニアリング』を読んだ感想になります。
読んだ動機
SLO(Service Level Objectives)/SLI(Service Level Indicators)の具体的な内容及び、設定方法が知りたかったので一番の目的になります。
さて、ではなぜアーキテクトチームの筆者がSREについて興味を持ち、いわゆるSRE本と呼ばれる『SRE サイトリライアビリティエンジニアリング』を読んだかと言うと、インフラ関連の仕事も度々行っているという点があります。
現状虎の穴ラボにはSRE専門チーム/部署は存在していません。なので、インフラ面のIaC化や、コスト削減、安定化などの一部をアーキテクトチームで行う場合があります。
そこで、どのくらいシステムが安定稼働しているかを、SLO/SLIという指標で知りたかったというのが一番大きい部分になります。 もともと、SLAについては計測されていましたが、具体的な可用性の指標はあまりありませんでした。
なので、SLO/SLIという指標で、システムのレイテンシ(≒レスポンス速度)がどのくらいなら許容できるか、既知のユーザー影響が無いエラーであってもどのくらいの頻度であれば許容できるか、などの設定方法やどうやって指標を作っていくかを知りたいと思ったのが動機となります。
読んだ感想
SLO/SLIについて具体的に触れられている、4章を中心に読みました。
最初は、SLO/SLI、エラーバジェットについてのイメージがわかない状態でしたが、ざっと読むだけでも具体的にどういうものを指し示すのかのイメージはできたかなと思います。
以下筆者の理解です。
- SLI: 具体的に計測に利用するもの(レイテンシとか可用性とかエラー率とか)
- ユーザーに与える影響で考える。ユーザーから見て満足できるレイテンシはいくらか、など(0.5秒で大満足、2秒で普通、5秒以上で離脱、であれば1秒以下で返されたレスポンスの比率、など)
- SLO: 具体的な数値目標
- 例：SLIとしてレイテンシ1s以内→99.5%満たすなら一ヶ月とかのパーセンタイルでそれが満たされているかの基準がSLO
- エラーバジェット: SLOがどのくらい満たされているかの基準。あとどのくらい違反していいかの余力になる。
- GCPとかでは100%スタートで減っていく。全期間違反してると-100%になる
実際にGCPなどの各クラウドサービスで設定しようと思っても、用語が何を指し示していて、何を設定させようとしてきているのかすぐにはわからなかったのがわかるようになりました。
ただ、書籍にも書いてありましたが、実際にどのくらいの数値を設定し、どのくらいでアラートとするかは難しいと思いました。
- 計測対象にしたい指標の継続的な収集が必要
- 設定したSLI/SLOが本当にユーザーからして満足か
- アラートが上がったとして、開発案件としてすでにあるスケジュールとどうやって折り合いをつけるか
まだまだこのあたりは勉強中なので、今後も書籍等で学んで行きたいなと思いました。
次に、書籍全体で気になった箇所の感想を軽く紹介したいと思います。
3章：リスクの受容
この章はリスクの計測はどうすればよいか？コストをかければリスクは減らせるが、コストとの兼ね合いをどうするか？などについて書かれていました。
次の4章が一番知りたかったSLO/SLIについての章ですが、この3章はその前段になる話が書かれているなと思います。実際にエラーバジェットなどの具体的なことについてはこちらの章で触れられていました。
計測に関しては、アクセスが多いサービスの場合超大量データの収集と解析を行うことになると思います。なので、やはりDatadogなどの各種クラウドサービスや、GCPなどに付随している監視サービスを使わないと難しそうだなと思いました。
8章：リリースエンジニアリング
昨今ではCI/CDを利用して自動テストやデプロイの自動化を行うことも一般的になってきているかと思います。
この章では、信頼性を担保しつつ、どのようにリリースプロセスを実現するかについて、その手の整備全般を行う役職としてのリリースエンジニアの提案がされています。
リリース時の操作ミスなどは起きた場合記憶に頼らざるを得ない場合もあり、しっかり自動化しておかないと危険だなと、実体験としても思いました。
また、QAチーム等がある場合、より複雑なリリースプロセスになることも考えられ、そのためにも専任もしくは詳しい人がいたほうがいいのかなと思いました。
11章~16章
11章から16章は主に実際に障害が起きた場合にどうするか、について書かれています。
具体的な各章のタイトルは以下のようになっています。
- 11章 オンコール対応
- 12章 効果的なトラブルシューティング
- 13章 緊急対応
- 14章 インシデント管理
- 15章 ポストモーテムの文化：失敗からの学び
- 16章 サービス障害の追跡
個人的に前職でも現職でもオンコール系の対応は経験があり、実感とともに読むことができました。11章ではオンコールのバランスなどについても触れられています。
実際、システムに詳しい人が駆り出されたりすることが多いと思いますが、そこら辺のバランスを取るのもよく考えないといけないなと思います。
障害発生時のコミュニケーションなどについても触れられています。個人的には障害発生時はステークホルダーに対する情報プッシュが何より大事だと思っているので、どのようなコミュニケーションを取るべきか考え直す機会になりました。
まとめ
今回は『SRE サイトリライアビリティエンジニアリング』について書いてみました。
主にはSLO/SLIなどの指標及び設定について書きましたが、本全体を通して、システムの安定稼働について書かれています。 SREやインフラを専門としているエンジニアだけでなく、筆者のようにどちらかというとアプリケーション寄りのエンジニアにとってもためになるかと思います。
まだざっと読んだだけなので、気になる部分は今後も読んでみたいと思います。
また、付随する書籍として、『サイトリライアビリティワークブック』という本もあります。こちらは、SREの実践編といった内容なので、また機会があれば読んでみたいと思います。
P.S.
採用
虎の穴では一緒に働く仲間を募集中です！
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
yumenosora.co.jp
今回関連する職種として、セキュリティエンジニアやインフラエンジニアも募集していますので、興味がある方はぜひご応募ください。
