【若手エンジニア】SREが何かを改めて考えて理解を深める

　自社で開発しているプロダクトのSREをしている私だが、今までSREをふわっとでしか理解できていなかったので、改めて復習を行い、理解を深めようと思う。
　SREという言葉自体は聞いたことがあるが、DevOpsやPFEのそれぞれとの違い等がわかる人も少ないのではないだろうか。
　この記事は１年目から３年目をターゲットにしてSREが何なのか、何を行っているのかを概念的に解説するため、若手エンジニアでも読みやすい記事になるのではと考えている。

当記事で話すこと

• SREとは
• SREの必要性について
• SREと類似の言葉の違いについて
• SREは何を行うのか

当記事で話さないこと

• SRE技術のベストプラクティス（Kubernetes, APMの設定方法など）
• SREの実践例や具体例

SREとは？

RedHatさんがGooogleで提唱されたSREを解説している。

SRE (Site Reliability Engineering：サイト信頼性エンジニアリング) は、IT 運用におけるソフトウェア・エンジニアリング・アプローチです。SRE チームはソフトウェアツールを使用してシステムの管理、問題解決、および運用タスクの自動化を行います。
　SRE は、運用チームが多くの場合手作業で行ってきたタスクを、ソフトウェアと自動化を活用するエンジニアと運用チームに担当させ、ソフトウェアと自動化によって問題を解決し、本番システムを管理します。
　SRE は、スケーラブルで信頼性の高いソフトウェアシステムを構築する際に効果を発揮します。コードを使用して大規模システムの管理を支援するため、数千台や数万台に及ぶマシンを管理するシステム管理者により多くのスケーラビリティと持続性をもたらします。

　SRE自体はGoogleのエンジニアリングチームのBen Treynor Sloss 氏が提唱したもので、このように述べられている。

My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.
SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです。

　つまり、SREは既存のシステムから学び、新しいシステムを構築する際に大切な信頼性を高めていくことを行っている。

SREが生まれた背景

Google公式SREハンドブックより引用

　SRE（Site Reliability Engineering）が生まれた背景は、主に大規模なシステム運用の複雑性が増したことに起因する。2000年代初頭、Googleをはじめとするインターネット企業は、急速なサービス拡大とともにシステムの信頼性やスケーラビリティを維持するための新しいアプローチを必要としていた。当時、運用業務は伝統的なシステム管理者（SysAdmin）が担当しており、システムの保守や障害対応が主な業務だった。しかし、サービスの成長速度や複雑なアーキテクチャに対応するのが困難になってしまった。

　Googleでは、エンジニアリング手法を活用してシステム運用を効率化する必要性を感じ、2003年頃にソフトウェアエンジニアを運用業務に配置するという新たな試みを始めた。これがSREの起源である。SREチームは、ソフトウェア開発の手法を用いて運用業務を自動化し、システムの信頼性向上を目指した。具体的には、モニタリング、インシデント管理、自動リカバリ、キャパシティプランニングなどの分野でエンジニアリング技術を駆使して実現した。

　SREが注目されたもう一つの理由は、DevOpsの台頭である。DevOpsは開発（Dev）と運用（Ops）の壁を取り払うことを目指しますが、SREはその考え方を具体的な実践方法として具現化する役割を担った。SREはエラーバジェット（Error Budget）やSLO（Service Level Objective）といった概念を導入し、開発と運用のバランスを取りながらシステムの品質を管理する方法論を提供したのである。

　つまり、SREは大規模システム運用の複雑化に対応するため、Googleが2003年頃に導入した手法で、運用業務の自動化や信頼性向上を目的とした手法の一つである。DevOpsの思想を具体化し、エラーバジェットやSLOなどを通じて開発と運用のバランスを取り、効率的な運用を実現したのだ。

似たの言葉の意味の違い

　ここでは、DevOpsとPFEとの違いについて述べていく。

SREとDevOpsの違い

1. アプローチの違い

   • DevOps: 文化的な概念が中心であり、開発と運用チームが連携するためのマインドセット、プロセス改善を強調する。CI/CD（継続的インテグレーション・デリバリー）などが典型的な実践例となる。
   • SRE: エンジニアリング手法に基づいた具体的な実装ガイドラインを提供する。エラーバジェットやSLO（Service Level Objective）といった具体的な数値指標でシステムの品質管理を行うことが特徴である。

2. 目的の違い

   • DevOps: 納期短縮やビジネスの俊敏性向上が主な目的。
   • SRE: 信頼性（Reliability）向上を第一に掲げつつ、リリース速度のバランスも重視する。

3. 組織的な位置付け

   • DevOps: 組織全体の文化として取り入れることが目指される。
   • SRE: 具体的な役割を持った専門チームが存在することが多い。

---

SREとPFEの違い

1. 役割の違い

   • SRE: 主にバックエンドやインフラに焦点を当て、システムの可用性や信頼性を確保します。データベース、クラウドインフラ、API管理などが主な領域となる。
   • PFE: フロントエンドエンジニアリングを通じて本番環境のパフォーマンスや信頼性を維持する役割です。ブラウザパフォーマンス、ユーザーエクスペリエンス（UX）の改善などが業務の中心となる。

2. 技術的焦点

   • SRE: インフラ自動化、モニタリング、アラート設定、自動回復など。
   • PFE: JavaScriptパフォーマンス最適化、CDN構成、ブラウザキャッシュ戦略、A/Bテストなど。

3. 連携の重要性
   SREとPFEはそれぞれ異なる技術領域を担当しますが、モニタリングやパフォーマンス指標の共有を通じて密接に協力することが求められる。フロントエンドの不具合がサービス全体の信頼性に影響を与えるため、両者の連携が重要となる。

---

　つまり、SREはDevOpsの具体的な実践形態であり、エンジニアリング手法に強く依存することがあげられ、一方、PFEはフロントエンド領域に特化して本番環境の信頼性を高める役割を担うという違いがある。
　それぞれ異なる焦点を持ちながらも、サービス全体の品質向上に寄与する重要な役割を果たしているため、似た単語ながらもやっていることは全く別物となる。

SREがやっていること

SREが行う業務内容

　SRE（Site Reliability Engineering）は、サービスの信頼性、可用性、パフォーマンス、スケーラビリティを維持・向上させるためのエンジニアリング手法を取り入れた職種のためやることも実は様々存在する。SREの具体的な業務は多岐にわたるため、以下のようなカテゴリに分けて説明する。

---

1. モニタリングとアラート設定

　SREの基本業務の一つは、システムの監視です。サービスの健全性をリアルタイムで把握するために、ログ収集、メトリクス収集、ダッシュボード構築を行う。

• モニタリング: NewRelic、Datadog、Prometheus、Grafanaなどのツールを用いて、リソース利用率、エラー率、レスポンス時間などを可視化する。
• アラート設定: 重要なメトリクスに基づいてしきい値を設定し、異常が発生した際に即座に通知を受ける仕組みを構築する。

2. インシデント対応と障害復旧

　システムに障害が発生した際、SREは迅速に対応し、サービスの復旧を図る。

• インシデント対応: インシデント発生時には、影響範囲の把握、暫定的な対処（ワークアラウンド）の実施、根本原因の特定を行う。
• ポストモーテム（事後分析）: 障害後に詳細な分析を行い、再発防止策を策定する。

3. 自動化

　手動の作業はヒューマンエラーを引き起こしやすく、運用コストも高いため、SREは運用タスクの自動化に力を入れる必要がある。

• デプロイ自動化: CI/CDパイプラインを構築し、ソフトウェアのリリース作業の自動化。
• インフラ管理: Infrastructure as Code（IaC）ツール（TerraformやAnsibleなど）を使い、スケーラブルなインフラ構成をコードで管理を行う。
• 障害対応の自動化: オートヒーリング機能の導入により、特定の障害に対して自動で回復処理を行う仕組みを構築する。

4. パフォーマンスとキャパシティプランニング

　サービスがスケールし続けるためには、適切なリソース管理が不可欠となる。

• キャパシティプランニング: トラフィックの予測に基づいて、サーバリソースの増減を計画する。
• パフォーマンス最適化: アプリケーションのボトルネック分析を行い、レスポンス時間やスループットを向上させる。

5. SLOとエラーバジェット管理

　SREはサービスレベル目標（SLO）を設定し、品質を定量的に管理します。

• SLO（Service Level Objective）: サービスが達成すべき目標値（例えば「99.9%の稼働率」）を設定する。
• エラーバジェット（Error Budget）: 許容可能な失敗率を定義し、開発スピードと信頼性のバランスを取る。

6. セキュリティ対策

　セキュリティもSREの重要な役割です。

• アクセス制御: 適切な権限管理とネットワークセキュリティ対策を行う。
• 脆弱性管理: ソフトウェアのセキュリティパッチ適用や脆弱性スキャンを自動化する。

7. ドキュメント整備

　運用の効率化には高品質なドキュメントが不可欠となる。

• 運用手順書: トラブル対応やシステム設定手順を明文化する。
• ポストモーテムレポート: インシデント対応後に原因と対応策を記録する。

8. 開発チームとの協力

　SREは開発チームと緊密に協力し、信頼性を高めるアーキテクチャ設計やコードレビューを行う。

• 信頼性のための設計レビュー: 新機能の導入時に障害リスクを評価する。
• 開発支援: パフォーマンス最適化やCI/CDパイプラインの改善をサポートする。

9. 文化的な役割

　SREは単なる技術的役割ではなく、信頼性向上に対する文化を組織に根付かせる。

• 信頼性文化の醸成: 障害対応や改善のためのオープンな議論を推進させる。
• データドリブンな意思決定: 定量データに基づく運用改善を行う。

---

　つまり、SREはシステム運用と開発をエンジニアリング手法で統合し、自動化、モニタリング、障害対応、パフォーマンス管理などを通じてサービスの信頼性を高める重要な役割を担うのである。
　信頼性と開発速度のバランスを取りつつ、継続的な改善を推進することで、ユーザーに高品質なサービスを提供し続けることがSREの使命となるのだ。

SREにおけるToilの削除

　Toil（トイル） とは、反復的で手動の作業や、価値を生まない作業を指す。SRE（Site Reliability Engineering）では、Toilを最小限に抑えることが重要な目標の一つとなっている。具体的には、システムの運用で必要な作業のうち、手動で繰り返し行われる作業や非効率的な作業、改善の余地がなく、チームが成長する上で無駄となる部分を「Toil」と呼ぶのである。

　SREの目的の一つは、このToilを削減することで、チームがより価値のある作業（例：システムの信頼性を向上させるための改善や新しい技術の導入）に集中できるようにすることが挙げられる。Toilを削減することで、SREチームは本来の目標であるシステムの信頼性向上に焦点を当てることができる。

---

Toilの特徴

Toilは、以下の特徴を持つ作業を指す：

• 繰り返しの作業: 定期的に繰り返される運用タスク（例えば、バックアップの手動実行やサーバーの再起動など）
• 自動化できる: 自動化することで、手動作業を減らし、効率化が図れる作業
• 価値を生まない: ビジネスやユーザーへの直接的な価値を生まない作業
• 手動でエラーを引き起こすリスクが高い: ヒューマンエラーを引き起こしやすい作業
• スケーラビリティが低い: 手動作業や非効率な作業は、システムがスケールするにつれて大きな負担となる

---

Toil削減の方法

SREでは、Toilを削減するために様々な手法が採用されます。主に以下のような方法がある。

1. 自動化の推進

   • CI/CDパイプライン: ソフトウェアのデプロイやテストを自動化することで、手動で行っていた作業を削減させることができる。
   • インフラのコード化（IaC）: インフラの設定や管理をコードとして記述し、自動化します。これにより、手動でのサーバー構築や設定ミスが減少する。
   • オートヒーリングと自動修復: 障害が発生した際に、システムが自動で修復できる仕組みを作ることで、手動での障害対応を減らすことができる。

2. ツールの活用

   • 監視とアラートシステム: モニタリングツールを使用して、異常を迅速に検知し、手動で対応する必要を減らす。
   • インシデント管理ツール: インシデント対応をスムーズに行えるようなツール（例: ServiceNow）を使って、素早い対応を可能にします。

3. プロセスの改善

   • ワークフローの改善: 定期的に行われる手動作業を見直し、どの部分を自動化できるか、効率化できるかを検討する。
   • 運用手順書の整理: 明確な手順書やドキュメントを整備し、スタッフが迅速に作業を進められるようにする。

4. エラーバジェットの活用

   • エラーバジェット: SREでは「エラーバジェット」という概念を用い、開発と運用のバランスを取る。Toilを削減するためには、システムの可用性や信頼性に集中し、エラーバジェットを管理することが大切となる。

5. 継続的な改善とリファクタリング

   • Toil削減は一度だけ行うものではなく、継続的に行う必要がある。新たな手動作業が発生しないよう、システムの設計や運用プロセスを定期的に見直し、改善を行う必要がある。

---

Toil削減の重要性

SREがToilを削減する理由は、次のような点で重要である：

1. エンジニアの生産性向上

   • Toilを削減することで、エンジニアは反復的で単調な作業から解放され、より創造的で価値の高い仕事に集中できるようになる。これにより、チームの全体的な生産性を向上させることができる。

2. 信頼性の向上

   • 手動で行う作業はエラーを引き起こすリスクが高いため、自動化を進めることで、システムの信頼性が向上する。

3. スケーラビリティの向上

   • 手動作業が多いと、システムがスケールするにつれて作業量が増加し、運用の負荷が大きくなってしまう。自動化することで、スケールに合わせて効率的に運用できるようになる。

4. 改善のサイクルを加速

   • Toilが減ることで、エンジニアは運用の改善や新技術の導入に集中できるようになり、サービスの進化を加速させることができる。

---

　SREは、Toilの削減を重要な目標としており、そのために自動化やツールの活用、プロセス改善などの手法を積極的に導入する。つまり、SREはToilの削除のために様々なことを行なっているのである。
　Toilを削減することで、SREチームはより効率的にシステム運用を行い、信頼性を向上させ、エンジニアの生産性も向上させることができるだろう。

総括

　以上がSREについてざっくり理解するために必要なTipsである。
　これまでに説明してきた内容のSREは実はまだ入り口の段階で、他にもやることはたくさんある。
　私自身がSREとしてエンジニアをしているのだが、この記事を書いていて知らなかったこともたくさんあったし、これからもたくさん出てくると思われる。
　大事なこととしては、SREの目的を果たすために何を行えばいいのかというのを逆算して考え、プラクティスに則った行動をすることだと思案している。
　SREのベストプラクティスを施行することも大切だが、それ以上に、「イノベーションと信頼性の両立を実現するためには？」 という観点を失ってはならないとも思案している。
　私自身、SREに携わるエンジニアとして、もっと成長していけたらなと思った。

　最後までお読みいただきありがとうございました。それではまた次回。

参考文献

https://sre.google/sre-book/introduction/
https://clouddirect.jp.fujitsu.com/service/navi-tech-sre
https://www.redhat.com/ja/topics/devops/what-is-sre
https://qiita.com/shin7446/items/58c173d30a08955f0a0d