クラウドネイティブへのシフトで顕在化している、システムインフラ運用の課題。これを解消するためのアプローチとして注目されているのが「Site Reliability Engineering（SRE）」です。

　ではSREは従来型のインフラ運用と、どのような違いがあるのでしょうか。そしてそのメリットや、スムーズに実現するための方法は？

　今回はこれらについて解説します。

▼ 目次
１．運用と人材不足の課題を解決できる　SREというアプローチ
２．SREと従来型運用の違い（1）信頼性の考え方
３．SREと従来型運用の違い（2）素早い復旧とポストモーテム
４．SREと従来型運用の違い（3）自動化推進によるToilの削減
５．SRE型運用のメリット
６．SREへのハードルを下げる　「C-Native SRE Support Service」
７．まとめ

１．運用と人材不足の課題を解決できる
　　SREというアプローチ

　コンテナやマイクロサービスの活用、イミュータブルインフラストラクチャの実装・運用などによって、企業システムをクラウドネイティブ化する取り組みが加速しています。CTCが独自に調査した結果によれば、クラウドネイティブへの取組率は54％に達しており、そのうち26.3％は「実際に社内サービスで取り組んでいる」と回答しています。

　しかしそこにはいくつかの課題も存在します。そのトップ3は「セキュリティ対策」「投資・運用コスト」「マネジメント（運用）」ですが、ここでぜひ注目したいのが、4～6位の課題です。4位は「障害問題発生時の対応策」、5位は「クラウドネイティブ技術がわかるITスタッフの確保・育成」、6位は「モニタリング/パフォーマンス/オートスケーリング管理」となっており、合計すると1位の「セキュリティ対策」よりもはるかに大きな割合となります。そしてこれらは「インフラ運用の具体的な内容」を示しており、3位の「マネジメント（運用）」を含め、多くのクラウドネイティブ化への取り組みが、運用の問題に直面していることがわかります。

　これらの技術を活用していくことはビジネス変革の推進につながる一方で、セキュリティの観点では従来の考え方やソリューションでは十分な対応ができないことが多く課題となっています。

図1. クラウドネイティブへの取り組みを進める上での課題

　これらの問題の背景としては、現行のITシステム運用メンバーが多忙で、新技術を受け入れる時間的余裕を確保できないことが挙げられます。クラウドネイティブ環境の運用を内製化したいと考えても、そのために必要な「有識者」の確保が難しいのです。しかし運用を内製化できなければ、クラウドネイティブ化のメリットを十分に享受することはできません。アプリケーションの提供・改善をスピーディに行えることこそがクライドネイティブの大きなメリットであり、そのためには内製化によるインフラの素早い提供が欠かせないからです。

　このような問題を解決できるアプローチとして、近年大きな注目を集めるようになったのが、「Site Reliability Engineering（SRE：サイト信頼性エンジニアリング）」です。これは2004年にGoogle社のBenjamin Treynor Sloss 氏によって提唱されたものであり、従来のインフラ運用とは、基本的な考え方が大きく異なっています。

２．SREと従来型運用の違い
　（1）信頼性の考え方

　SREには主要なポイントが3つあります。第1は、信頼性の定義が従来の運用とは異なっている、ということです。

　従来のインフラ運用では、信頼性を確保するためにログや各種メトリック（CPU使用率やメモリ使用率などの数値データ）を取得し、システムを「監視（モニタリング）」していました。目的は問題が発生した場合に「その発生を迅速に検知する」ことにあります。そのためには当然ながら、検知に漏れが生じないように網羅的な監視を行う必要があります。

　しかしこのような「監視」中心の信頼性確保では、監視の負担が大きい上、問題は発生してからその事実を知ることになるため、問題を事前に回避することが困難です。また問題発生後の対策も、「チェック項目を増やす」「ダブルチェックを行う」といった、対症療法的なものになりがちです。その結果、チェック作業が膨大になり、現実的に機能していない状況に陥る危険性があります。

　これに対してSREでは信頼性を評価する手段として、「監視」ではなく「可観測性（オブザーバビリティ）」というアプローチを採用しています。これは信頼性の評価を、システム自体の観点から行うのではなく、ユーザー体験の観点から行うためです。

　システム監視ツールで問題が発生していなくても、ユーザーから見て問題があれば、それは信頼性の低下とみなします。逆にシステム管理ツールで問題が検知されても、それがユーザー体験に影響がなければ、信頼性は損なわれていないと考えます。またエラーや問題の発生を検知するだけではなく、その原因を探るための情報を収集することも、可観測性の重要な特徴です。

図2. SRE が提供する価値①

　そのためにSREでは、まずユーザー体験の指標となる「Service Level Indicator（SLI）」と、その目標値である「Service Level Objective（SLO）」を明確にします。SLOが満たされていれば、そのシステムは十分な信頼性がある（健全な状態でサービスを提供している）とみなすわけです。そしてこのSLIを継続的に観測し、SLOを満たしているか否かを評価し続けます。

　またSLIとSLOの設定では、コストとのバランスを考えることも重要です。例えば、システムの「可用性」を高めるには、冗長化のための投資やその運用負担が大きくなり、コストが急上昇する傾向があります。しかしユーザー体験への影響が小さいのであれば、あえて高い可用性を追求する必要はありません。ユーザー体験を軸にシステムの信頼性を見直すことで、従来とは異なる観点から、コストの最適化を実現することが可能になります。

３．SREと従来型運用の違い
　（2）素早い復旧とポストモーテム

　第2のポイントは、素早い復旧とポストモーテムを重視していることです。

　素早い復旧が重要であることは、ユーザー体験の維持が目的であることを考えれば、当然のことだといえます。たとえ「可用性」が高くなくても、ユーザー体験に問題が発生した際に「素早く復旧」できれば、ユーザー体験の毀損を最小限に抑えられるからです。

　それでは「ポストモーテム」とは何でしょうか。これはインシデント（発生した問題）から学びを得るためのプロセスの一部です。

図3. SRE が提供する価値②

　ポストモーテムでは、インシデントの内容やそのインパクト、その際の対応策として実施したアクションなどの情報を共有し、根本原因を探ると共に、再発防止策や今後のアクションを検討・立案します。ここで重要なのは「チェックを増やす」といった対症療法的な対策ではなく、根本的な対策を論理的な根拠にもとづいて作り上げることです。

　またこのような活動を行うことで、新たな課題が顕在化することも少なくありません。そして関係者がこの活動から学びを得ることで連携が強化され、よりオープンな姿勢でインシデントへの対応を行えるようになる、といった効果も期待できます。

４. SREと従来型運用の違い
　（3）自動化推進によるToilの削減

　そして第3のポイントが、自動化推進によるToilの削減を目指すということです。「Toil」とは、サービスに直接結びつかない、人手による作業を意味します。これを自動化で徹底的に排除していくことで、生産性向上と運用コスト削減を実現していきます。

図4. SRE が提供する価値③

　もちろん従来型運用でも自動化は重要な課題であり、多くの運用現場が各種ツールによってその領域を拡大しようとしています。しかしそれでも運用の中心は、手順書ベースの人的作業だというのが現状です。その根本的な要因の1つは、システムインフラの構築・提供が、人の手に委ねられていることです。

　しかしクラウドネイティブなシステムインフラであれば、この根本要因を解消できます。クラウドネイティブ環境で利用可能な各種テクノロジーツールを活用することで、ソフトウェアによってシステムインフラを構築・展開できる「Infrastructure as Code（IaC）」を実現できるからです。

　これに加えてSREでは、AIで運用を行う「AIOps」や、ソフトウェアロボット、SLI監視のためのダッシュボードなども活用し、徹底的な自動化を継続的に推進していきます。これによって運用主体のウェイトはソフトウェアへと次第にシフトし、人間は補助的な役割を担うことになるのです。

　これら3つのポイントをまとめると、以下のようになります。

図5. SRE（Site Reliability Engineering）とは

５．SRE型運用のメリット

　SRE型の運用を導入すれば、インフラ運用の人的負担は時間とともに低減していきます。これによって人件費が削減されると共に、結果が予測しやすい環境をソフトウェアで再現しやすくなることで、同じ操作を何度繰り返しても同じ結果が得られるという「冪等性」も実現しやすくなります。これは当然ながら、インフラ品質の担保に大きな貢献を果たすことになります。

図6. 『 SRE 型サービスデリバリー 』 モデルのメリット

　インフラ運用の人的負担が削減されれば、人はより本質的な仕事に集中できるようになります。例えば、インフラ運用のさらなる自動化や、SLI/SLOの継続的な見直しによるユーザー体験の向上、ポストトーテムによるよりオープンな文化醸成などに、多くの時間を費やせるようになります。

　しかしSRE型運用への移行は、そう簡単に行えるものではありません。従来型のインフラ運用を継続しながらSREにも取り組むには、当然ながら人員を追加しなければならないからです。長期的に見れば人的負担が軽減することがわかっていても、最初の一歩を踏み出すことが難しいのです。実際にCTCの独自調査でも64.4％が、SREに取り組むには「人で不足である/増員の必要がある」と回答しています。

６．SREへのハードルを下げる
 　「C-Native SRE Support Service」

　この問題を解決するためにCTCが提供しているのが「C-Native SRE Support Service」です。CTCではクラウドネイティブ化を支援する各種サービスを「C-Native」として体系化していますが、これはその中に含まれるものです。

　まず「クリティカルユーザージャーニー（主要なユーザー導線）」を明確にし、その中でどこが重要なポイントになるのかを見出します。その上で、SLIとSLOをどう設定するのか、それらをいかにして継続的に可視化していくのか、といった検討を行います。

　次に、インシデント発生時の対応に参加し、インシデント対応の役割を整理/確認すると共に、ポストモーテムのリードを担当します。ここで、インシデント対応フローの見直しや、新たなToilの発見、必要に応じたSLI/SLOの見直し、障害発生前に問題を把握するための自動化手段の検討などを行います。

　そして第3に、可観測性（o11y：observability）や自動化に必要なツールの要件整理、設計、検証、本番環境への導入などを実施します。これによって可観測性の最適化や、Toilの削減を進めていくのです。

図7. C-Native SRE Support Service概要

　このような活動のサイクルを回していくことで、SREを効果的に推進していくことが可能になります。またそのためのサポートに加えて、SRE推進に効果のある各種テクノロジー製品を積極的に活用していることも、C-Native SRE Support Serviceの大きな特徴となっています。

　例えば、可観測性の主要コンポーネントとしては、ガートナーからリーダーと評価されている「Dynatrace」を活用。IaCやセキュリティに関しては、充実した機能をマルチクラウドに展開できる、HashiCorp社の「Vault」「Terraform」を使っています。さらにクラウドネイティブな基盤としては、Red Hat OpenShiftなどに対応しています。

　クラウドネイティブなインフラを構築するには、実に多岐にわたるツールが必要であり、その使いこなしが欠かせません。これはSREの実現でも同様です。ここで最適なツールを選択することは、SRE推進を長期的に成功に導くための、重要なポイントとなります。

　CTCが上記のように、業界で最も高い評価を受けているツールを採用できるのは、長年にわたってマルチベンダーでITサービスを提供してきた実績とノウハウがあるからです。C-Native SRE Support Serviceの構築でも、1年以上にわたって国内外の情報を収集しながらサービスコンセプトを作り上げると共に、そこで活用すべきツールの選択も慎重に行ってきたのです。

　なおC-Native SRE Support Serviceは、2022年11月にリリースされています。この時点でSREに関するサポートサービスを明確に提供しているのは、CTCだけです。

　もちろんCTCは、すべての運用がSRE型になるべきだとは考えていません。レガシーシステムの運用は、今後も従来型運用が踏襲されることになるでしょう。しかしクラウドネイティブ環境での信頼性を担保するには、SRE型運用へのシフトが欠かせません。これら両方を同時にサポートし、それらの最適なバランスを見出す支援を行えることも、CTCならではの優位性だと言えるでしょう。

７．まとめ

　本記事のポイントをまとめると以下のようになります。

• 企業システムのクラウドネイティブ化では、運用と人材不足が大きな課題になっている。これを解消できるアプローチとして注目されているのがSREである。
• SREには、従来型運用とは異なるポイントが、大きく3点ある。
  • 信頼性の考え方
  • 素早い復旧とポストモーテム
  • 自動化推進によるToilの削減
• SREへとシフトすることで、運用の人的負担は時間とともに軽減され、人はより本質的な仕事に注力できるようになる。しかしSREを検討している多くの企業では、現状の人員不足が大きなハードルとなり、その第一歩を踏み出せていない。
• この問題を解決するため、CTCは「C-Native SRE Support Service」を提供。これによって顧客のSREの導入と継続的な改善を支援している。
• またマルチベンダーでの経験を活かし、SRE推進に最適なツールの選定・活用も行っている。

　SREについての用語解説については以下よりご覧いただけます。

• 「SREとは｜サイトリライアビリティエンジニアリングに必要な人材やスキルとは

• 「C-Native SRE Support Service」の詳細