SRE というポジションを(兼務で)やることになった。何も知らずに担当することになり、苦労している様子を記録していく。
SREの分野
キャパシティマネジメントとキャパシティプランニング
サービスを安定して稼働させ続けるために必要なインフラまわりの要件を見積もるタスク。必要以上にコストをかけすぎていないか、今後予想される負荷に対してシステムが耐えられるかを判断する。
一度待ち行列をつかってシステムのキャパシティを計算したことがある。
SLA/SLI/SLO
Service Level Agreement / Indicator / Objective のこと。サービスの信頼性を評価するための合意、指標、目標である。
可用性やレイテンシが目標とする値を満たしているかどうかを観測して、状況に応じてオペレーションチームと開発チーム、あるいはビジネスチームが次のクォーターでやることを決めるというようなもの。
プロビジョニング
Infrastructure as Code というフレーズが広まったように、インフラ系の設定もコードとして管理しようという動きが主流になった。背景にはクラウドサービスの浸透もあるだろう。Ansible のように事前に書いた設定を再現できるものが登場し、今ではクラウド環境のプロビジョニングに Terraform などが使われている。設定を書き、コマンドを実行することでいつでもクラウド環境を構築できるまでになった。
監視・モニタリング
サービスが正常に稼働しているか、ヘルスチェックを使った外形サービスはこれまでにも存在した。最近では Datadog を導入していて、ヘルスチェックに留まらず、ログやステータス、レイテンシはもちろん、どのエンドポイントがまずいかや SLO までサービスを通して一括で管理できるようになっている。
SRE に関する用語
- Terraform: HashiCorp 社が提供するプロビジョニングツール。クラウドのプロビジョニングに強い。
- プロビジョニング: 日本語では「準備」だろうか。インフラ環境のセットアップをすることを意味する。
- モノリス: モノリシックな環境のこと。マイクロサービスと対になる概念
- IAM: Identity and Access Management: 権限を管理する AWS のサービスのひとつ。
- IaC: Infrastucture as Code のこと
原典となる書籍
SRE の概念は Google で生まれた。Google の SRE チームが書いた書籍があり、SRE 本としてはこれが教科書的存在になっている。雑に説明するとすれば1冊目は理論編、2冊目は実践編になっている。1冊目だけでは最初に何をすれば良いかイマイチわからなかったが、2冊目では順を追ってやるべきことが例と共に乗っていて非常に役に立った。
関連記事を漁ってみた
適当にググって見つけた記事で雰囲気を掴むやつ。SREってなんだ?哲学と習慣、そしてツール。という記事を読んでみる。
SRE ってのは重要だしこれから需要も高まっていきそうだって話にはじまり、じゃあ SRE にとっての成功とは? どんなことを習慣にする? 使えるべきツールは? と SRE の概要について書かれている。
自動化する、
そして、リソース管理・セルフサービスプロビジョニングなども重要であると。プロセスとツールも標準化しないとねって言っている。
SRE にとっての成功?
SRE が使うツール
SRE が使うツールとして次のようなものが挙げられている。この一覧を見ると SRE の職務範囲がなんとなくわかるのではないだろうか。
- 計画 – アジャイルプロジェクト管理、トラッキングツール
- 開発 – IDE、エディタ、GitHub
- 確認 – CI/CD ツール
- パッケージ – ビルド、パッケージング、リリースステージング、承認プロセスを管理するツール。Rake や JFrog
- リリース – アプリケーションのリリースとライフサイクルを管理する
- 構成 – Terraform や Ansible など。コンテナの使用が増えるとこれらのツールの必要性は減少する。Docker などのコンテナプラットフォームや Kubernetes などのオーケストレーションサービスが不可欠になってくる
- 監視 – ログまたは分析データでアプリケーションおよびインフラストラクチャからメトリクスを収集し、ダッシュボードを介してデータに関するアラートを収集する
信頼性の指標
信頼性を高める仕事ということだが、その信頼性を測る指標には SLI/SLO のほかに次のようなものもある。次に挙げるのは障害・インシデント対応に関わるものだ。
- MTBF, Mean Time Between Failure – 平均故障間隔。障害と障害の間隔。大きい方がいい
- MTTR, Mean Time To Resolution – 平均修復時間。障害から復旧するまで。小さい方がいい
- MTTD, Mean Time To Detection – 平均検出時間。障害発生から検知するまでの時間。小さい方がいい