ユーザーの幸福度を定量化――SLI、SLO実践の4ステップ:SREの文化を組織にどう定着させるか
SREは計測、自動化など取り組むことが多く、求められる知識量も少なくない。また周囲の理解が得られなければ、組織でSLI、SLOを定義してSREを実践するのも容易ではない。組織でSREに取り組む最初の一歩をどう踏み出せばいいのか。
企業がITを通じて新たな価値を提供することが必須要件となる中、顧客接点となるアプリケーションやサービスの重要性はさらに高まっている。価値提供を通じて競合優位性を保つには、新たなアプリケーションや機能の開発はもちろん、注目を集める「クラウドネイティブ技術」などを試していくことが不可欠だ。だが、その裏ではアプリケーションやサービスの安定稼働も求められる。
つまり、組織には新しい変化への取り組みが評価される開発者と、安定稼働を実現することで評価される運用管理者が存在する。相反する目標を持つ開発者や運用管理者に対し、「DevOps」という考え方も広まったが、実際にどう意思決定を進めればいいのか。
そこで注目されてきたのが、アプリケーションの信頼性を保証することを目標とし、可観測性を高めたり、サービスの堅牢(けんろう)性を高めたりするために取り組むSRE(Site Reliability Engineer/Site Reliability Engineering)だ。
2020年1月に開かれた「SRE NEXT 2020」に登壇したQuipperの近藤健司氏(@chaspy_)は、「SLI(Service Level Indicator)とSLO(Service Level Objective)を定義してSREを実践するには、組織やプロジェクトメンバーの理解が不可欠だ」と話す。近藤氏は、なぜSREが重要視されているのかをあらためて振り返りつつ、開発者を含むプロダクトチームに、SLI、SLO、エラーバジェットの考え方を浸透させていった方法や、その取り組みの中でどのような失敗を経験してきたのか紹介した。
今さら聞けないSLI、SLO、エラーバジェットの基本――なぜエラーを許容するのか
近藤氏は冒頭、SLI、SLO、エラーバジェットの基本に立ち返り、これらが求められる理由を説明した。
SLIとはサービスの信頼度を定量化する指標、数値のことだ。SLOとは端的に言うと目標のことだ。例えば、「アプリケーションのリクエスト成功率」(http success rate)をSLIとした場合、SLOはリクエスト成功率の目標を示す。Webアプリケーションやサービスの利用者から送信されたHTTPリクエストに対し、成功を示す「2xx」が返されたのか、サーバエラーを示す「5xx」が返されたのか、その割合を求めることでSLIとSLOを計測できる。
1万回の「2xx」と5回の「5xx」が計測されたと仮定すると、SLIは「99.95%」(エラー率は0.05%)になる。SLOを99.9%としていた場合、あと5回分の「5xx」のリクエストが発生するとSLIはSLOを下回る。視点を変えれば、あと5回分の「5xx」を許容できる。これがエラーバジェット(エラー予算)の考え方だ。エラーバジェットとは、SLIとSLOを基にエラーの発生を許容するという概念だ。
SLIやSLOを基にエラーの発生を許容することで、開発者はエラーバジェットの制約の中で新たなアプリケーションや新機能を開発する自由を得られる。運用管理者はエラーバジェットを基に「安定稼働」を具体化することで開発者に自由を与えることができる。
「俊敏性を持って新しい機能を実装したい開発者と、障害リスクを減らしたい運用管理者が対立してきた。それを解決するために『DevOps』という考え方が生まれた。信頼性と俊敏性、どちらに投資するかは、SLI、SLO、エラーバジェットといったファクトベースの意思決定が必要だ」(近藤氏)
「マイクロサービスアーキテクチャではSLI、SLOが不可欠」
さらに、近藤氏は「マイクロサービスアーキテクチャにおいてSLI、SLOは必要不可欠なものになってきている」と説明を続けた。
マイクロサービスアーキテクチャを採用すると、アプリケーションの可用性は機能ごとに分割された各サービスから影響を受ける。分割された各サービスのSLOが定義されていなければ、アプリケーション全体のSLIとSLOを定義することが難しくなってしまう。
「どこでどのように計測するかも重要だ。クライアントサイドからデータストアまで複数の選択肢がある。計測する範囲に限界があるため、どのメトリクスを収集していればアプリケーションの信頼度を計測できるかという視点で考える必要もあるだろう」(近藤氏)
組織にSLIとSLOの考え方を浸透させる4ステップ
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- コロナ禍で企業はDXを避けられない状況に――生き残るための選択肢とは
経済産業省の「DXレポート」では、2025年にはIT人材が国内で約43万人不足し、企業に残されたレガシーシステムの老朽化によって膨大な経済的損失が生まれるという「2025年の崖」が大きな問題として挙がっている。このような時代に企業が生き残るためにすべきことは何か、開発者不足を補い、生産性を向上させるための具体的な施策とは何か、有識者の提言や先行企業の事例を基に現実解を探る特集。初回は、現在の課題と企業が生き残るための選択肢を整理する。 - 重要なのは、コーディングの速さではなく「価値創出の速さ」
DX(デジタルトランスフォーメーション)トレンドを背景に、「ニーズに応えるアプリケーションをいかにスピーディーに届けられるか」がビジネス差別化のカギとなっている。これを受けて内製化に乗り出す企業も増えつつある中、その実践手段としてローコード開発ツールが注目を集めている。だが従来のノンコード開発ツールとは、受け止められ方、使われ方は全く異なる――本特集ではローコード開発ツールの意義、成果、そして開発者とIT部門の役割を考える。 - Fluentd+Elasticsearch+Kibanaで作るログ基盤の概要と構築方法
ログ基盤を実現するFluentd+Elasticsearch+Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について。