この記事では、SRE サービスである「Sreake」について解説します。SREの導入に際しての注意点や難易度についてもあわせて紹介しています。
SREサービス「Sreake」についての解説
SREという言葉を耳にする機会は増えてきたと思いますが、実際にSREを導入している企業は日本だとさほど多くはありません。SREの導入難易度は高く、実践できるほどの経験や知識を持っている人が少ない、という問題があるからです。
そこで本記事では、どのような点でSREの導入が困難なのかを説明していきます。あわせて、企業のSREを外部からサポートする弊社サービス「Sreake」をもとに、SREを効果的に取り入れ、実践する方法について解説いたします。
サービスの信頼性の向上を目指しているという企業様は、ぜひ最後までお付き合いください。
一般的なSREの定義について
まずは一般的なSREの定義について振り返ります。SREは「Site Reliability Engineering」の略で、スケーラブルで信頼性の高いサービスを実現するための設計やアプローチ、またはこれらを行うチームを指します。従来のDevOpsが抽象的な概念であるのに対し、それを詳細まで落とし込み実装したものがSREであると言われています。
SREの扱う領域はインフラエンジニアの枠を超え、「トイル（手作業で繰り返される長期的な価値のない作業）の制限および自動化」「SLI・SLO・SLAによる目標定量化」を軸に、サービスの信頼性を高める運用すべてに責任を持ちます。
SREを導入するのが難しい理由
SREの定義について簡単に説明しましたが、ここからはSREを導入しようとしたときに障壁となるポイントに触れていきます。
SLIの計測を行うための環境構築
SREの手引書である『The Site Reliability Workbook』によれば、SREにおいて重要なSLIの計測を行うにはリクエストログなどのデータを保存し、解析できる環境を構築する必要があります。信頼性を計測するためには既存のデータベース環境を対応させる必要があり、この点でSREの参入障壁をぐっと押し上げてしまっています。
サービス開発前からSREの導入を検討しているというケースであればまだしも、、ローンチ後の改善となると骨の折れる作業であり、SRE導入の難易度を引き上げる要因となります。
SLOの適正設定の難しさ
SREを導入するうえで、SLOの適正設定の難しさも存在します。SLOを高くすればするほど予算が削減され、リスクをとった革新的な施策が取れなくなってしまい、サービスがスケールしにくいという問題が起こります。
SLOの設定にはこれといった正解はないため、初期の設定がまとまらず、SREの導入を諦めてしまう企業も多いのではないでしょうか。
トイルの判別と自動化
SREの大本であるグーグルは、SREの原典である『Site Reliability Engineering』において、トイルについて以下のように定義しています。
「トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。」
ただ、多くの組織において「トイルを削減し自動化するという目的は理解できるが、そもそもトイルの判別と計測が難しい」という問題も存在します。トイルは繰り返し発生する人的タスクに加え、突発的に起こる人的作業も含むため、全体にかかる工数に対するトイルの工数を算出するのが難しいです。
そのため、自動化を進める前に、まずはトイルの定義付けをしっかり行う必要があります。そのうえで必要に応じて自動化を進め、改善サイクルを回すことが重要になります。
人材面での難しさも
SREの導入難易度という意味で言うと、「人材」という点でも問題があります。特に日本ではソフトウェアエンジニアにシステム運用させるような文化や組織的土壌はなく、エンジニア知識を持ちながら運用知識を同時に持った人材をかき集めるのは至難の業です。
そのためSREチームを構成する際は、Googleが推奨する以下の構成を意識すると良いでしょう。
50～60%：「Googleの正規エンジニア」
40～50%：「グーグルの正規エンジニア『予備軍』だが、他のメンバーが持っていないスキルがあるメンバー」
SREは多様なバックグラウンドを持つメンバーによって構成されることで、複数のスキルセットをかけ合わせ、高品質なシステム運営を可能にします。SREを導入する際は、高いエンジニアリングスキルと運用スキルの両方を求めず、チーム全体で不足しているスキルを補うことを念頭に進めていくことが大切なのではないでしょうか。
このようにSREの導入にはいくつもの導入障壁が存在します。また、SREに対する正しい知識が無いまま進めてしまうと期待していたような効果が出ない、といった懸念もあります。
これらの問題を解決するには、まずは外部からSREの知識に富んだプロをチームに参画させ、一つずつ課題の整理に取り組んでいくということも良いアプローチではないでしょうか。弊社のSRE支援サービスである「Sreake」はSREに対する豊富な知識と経験で、いかなるサービスもサポートすることが可能です。
Sreake = SREスペシャリストチームとともに、貴社の運用品質改善を実現
画像：https://stg.sreake.com/service-sre/
弊社のSREサービスである「Sreake」では以下のようなサービスメニューをもって、SRE導入の支援を行っております。
・SRE導入/定着化支援
大手からベンチャーまで、様々な組織規模でのSRE導入実績のあるメンバーが、貴社のSRE組織の組成/SRE文化の定着化の支援を行います。
・AWS/Google Cloud/Azure構築支援：
プロフェッショナルチームがAWS/Google Cloud/Azureの主要プラットフォームで導入を支援します。
・Kubernetes構築運用支援：
AWS/Google Cloud/Azureなどを活用したクラウド戦略の策定を、Sreakeのノウハウを用いて支援します。
・ハイブリッドクラウド構築支援：
エンタープライズシステムならではの高管理性、可観測性、高可用性、高セキュリティを満たしつつ、Kubernetesをフル活用したスピード感あるアジャイル開発を支える基盤の構築を支援します。
・PagerDuty構築運用支援：
監視ツール集約、通知システムであるPagerDutyの導入、構築を支援します。
・MetricFire導入支援：
国内初のMetricFire社のパートナーとして、導入実績を誇るSREチームが導入を支援いたします。
一般的なSREの定義は「自社サービスの信頼性を高めるために、自社のエンジニアが行う取り組み」です。しかし、SREの知識や経験が豊富ではない企業様の場合、まずは「外部からSREをサービスとして受ける」ことで、自社のSRE組織の基盤を作っていくことが大切です。
「Sreake」はこれまで、NTTデータ様、JCB様をはじめとする大きなクライアント様の「貴社の新規クラウドサービスの企画・設計・構築支援・運用を含む包括的なサポート」から「貴社SREの部分的な支援」まで、様々なケースでご支援を行ってきました。お客様のシステム運用環境を外部の目から客観的な把握することで、日々のシステムの改善のお手伝いをさせていただければと考えております。
SREに興味がある企業様は、お気軽にお問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。
