「SREはDevOpsを実現するための具体的なプラクティス」　モバイルアプリの価値を迅速にエンドユーザーに届けるには

SLI/SLOとは何か

中尾俊介氏：それでは「モバイルアプリのSLI/SLOについて」の発表を始めます。よろしくお願いします。

（会場拍手）

ありがとうございます。（スライドを示して）まず簡単に自己紹介をします。合同会社DMM.com プラットフォーム開発本部でiOSエンジニアをしている、中尾と申します。「Twitter（現X）」などのSNSではnaoという名前でやっています。DMMでは「DMMポイントクラブ」というアプリのiOS開発をリードしています。先日あったtry! Swift TokyoではDMMのブースの運営をしていました。

今回のイベントのビラをその時に配りまくっていたので、try! Swift Tokyoで今回のこのDMM.swift #2のことを知って来てくださった方がいたら、とてもうれしく思います。

（スライドを示して）今回私の発表で話すのは、モバイルアプリ開発におけるサービスのモニタリングで、特にSLI/SLOについてモバイルアプリ開発ではどうやるのがいいんだっけ？　という話をこちらの3本立てで話していきます。

最初にSLI/SLOって何だっけ？というところを確認します。次にモバイルアプリのサービスレベルについてどう捉えていくかを考えていきます。最後にモバイルアプリの信頼性を確保するためにどうしたらいいのかという流れで話していきます。

まずはSLI/SLOについての確認からやっていきます。SLI/SLOという単語や概要を聞いたことがある方も多いんじゃないかなと思っていますが、モバイルエンジニアが関わる世界ではあまり馴染みがなかったりすると思うので、あらためて、どういうものなのかの定義の確認をしていきます。

（スライドを示して）SLI/SLOは、Googleが提唱するSite Reliability Engineering、通称SREという概論の中で出てくるサービスを正しく管理するための指標を指しています。「SLI/SLOをある程度知っているよ」という方だったら、だいたい本番環境にデプロイされているサービスの品質や状態をモニタリングするためのものという認識を持っているんじゃないかなと思っています。

そのSLI/SLOの一方でSite Reliability Engineering、SREについてはモバイルアプリ開発の世界であまり話されていないと思うので、あまりピンとこないかなと思っています。SREはだいたいインフラ、クラウドまわりのバックエンドの世界でよく出てくるテーマだとは思いますが、これの中身や歴史を深掘りして見ていくと、実はモバイルアプリ開発でも扱えるテーマなんですよね。私はそう思っています。

なので今回の話は、SLI/SLOを始めとして、SREとは何なのか。また、その歴史や成り立ち。そしてそれをどうモバイルアプリ開発に応用できるのかを話していきます。

SREはDevOpsを実現するための具体的なプラクティス

さっそく、SREとは何なのかというところですが、SREはDevOpsを実現するためのGoogleが提唱した具体的なプラクティスです。DevOpsとSREの関係は、アジャイルとスクラムの関係に似ているかなと思っています。具体的には、その方針や思想と、それを実現するための具体的な手段という関係に近いかなと思っています。

これに関して、Googleがわかりやすい表現を出してくれているので、次のスライドで示します。

（スライドを示して）その表現というのが、class SRE implements DevOpsですね。SREはDevOpsというインターフェイスの実装であるということですよね。プログラマティックな表現かなと思います。ここに貼っているYouTube動画で詳細な話はDevOpsとSREの関係をGoogleのエンジニアが詳しく話しているので、詳細はそちらに譲りますが、興味がある方は見てみるといいかなと思います。

今言ったとおり、SREとDevOpsの関係は規約とその実装の関係なので、誕生した時系列としてはDevOpsのほうが先になります。DevOpsという言葉は、一昔前に流行ったと思うので「知っているよ」という方もいるかもしれません。DevOpsが生まれた歴史的なところを話すと、かつては企業はソフトウェアを運用するために、開発者と運用者を組織体制として分けていました。

この頃はまだクラウドの技術が一般的ではなかった時代で、2000年代とか、それ以前の時代の話になります。今ではクラウド技術が発達して、自社でマシンを調達してオンプレとしてサーバーを立てて運用してみたいな、そのへんの運用作業をする必要が、クラウドが浸透したことによってなくなってきているので、開発者が運用もカバーできる時代になってきています。

ですが、それまではソフトウェアの開発のスキルを持つ人は貴重な存在だったので、その人たちがソフトウェアを作ってそれ以外がマニュアルに沿ってソフトウェアを運用する構図だったんじゃないかなと認識しています。こうした開発者と運用者を分かつ組織体制は、責任がそれぞれの組織で分割されるので衝突を生んだんですよね。

開発者は機能のリリースによる価値提供をもって、ソフトウェアのビジネス価値の向上に責任を持つので、作ったものを早くリリースしたいという思いがあります。一方で運用者はソフトウェアの運用を任されているので、ソフトウェアを安定して動かし続けるところに責任を持っています。機能のリリースにはソフトウェアの変更が加わるわけなので、その動作や品質には影響が当然出てきます。

なので運用者としてはリリースされるものの品質を保証した上でリリースしたいというのが常だと思うんですよね。ですが、それには当然品質の保証に時間はかかるので、運用者は開発者の希望するスピードに追従できず否定するみたいな状況が生まれていました。これを俯瞰して見ると、実装は速いけどリリースで開発速度にブレーキをかけているという構図になっているのがわかるかなと思います。

（スライドを示して）俯瞰して見ると、開発者の持つ価値の提供という責任と、運用者の持つ信頼性の担保という責任は、それぞれ目指すミッションは違うのですが、それぞれのミッションの行きつく先は同じところのはずなんですよね。作った製品のビジネス価値を向上させるところが共通の目的として存在しているはずです。

そこの価値の提供と信頼性の担保は対立するものじゃなくてビジネスの価値の向上という共通のミッションを目指して、DevとOpsはお互いに協調しようという方針を示したのがDevOpsになります。これがDevOpsという概念であり、実践であり、文化かなと思っています。

モバイルアプリにおいてもDevOpsやSREは重要

コラム的な話をすると、DevOpsの成り立ちはけっこう曖昧だと思っていて、具体的にどこで誰がその方針を定義して宣言したものなのかは、私の知る限りだと明確にはないと思っています。アジャイルでいう、アジャイルソフトウェア宣言みたいなものがDevOpsにはないんじゃないかなと思っています。

2009年にベルギーで初めて開催されたDevOps Daysというイベントで、「DevOps」というワードが初めて出てきて、それをきっかけに普及したみたいです。具体的にはそのDevOpsという定義や原則は、そこから生まれたDevOpsという方針を支持する人がいくつか出しているみたいな感じの認識です。そのへんに詳しい方がいたら、後の懇親会とかでお話を聞ければなと思っています。

ここでちょっと話を戻しますが、DevOpsのエッセンスである価値提供と信頼性の担保の協調と、それによって達成する製品のビジネス価値の向上はモバイルアプリにおいてもソフトウェアなので同じだと思っています。なので、モバイルアプリ開発の世界でDevOpsやSREの話は出てくることは少ないのですが、私個人としては重要な話かなと思っています。

今回のイベントに参加いただいている方々はモバイルアプリ開発、特にiOS開発に携わっている方が多いと思います。ぜひその自分の携わっているアプリについて次のことを考えてみていただきたいと思います。

開発しているアプリの開発速度を維持できていますか？バグや不具合対応に押されて機能開発が遅くなったりしていませんか？というところですね。

開発しているアプリの品質は適切に管理できていますか？　本番に上がっているアプリの信頼性をモニタリングできていますか？というところです。そのへんを正しく監視・計測するための方法がSREだと思っています。特にSLI/SLOは、SREの中のコアとなるプラクティスだということが、この章で伝えたいことです。

具体的なプラクティスの全体像

（スライドを示して）補足として、SREの中で具体的に語られているプラクティスの全体像を、ここで載せておこうと思います。DevOpsは先ほど話したとおり、具体的な原則は存在しなくて、DevとOpsが協調しようという運動のようなものです。このDevOpsの協調のエッセンスをどう実現するかをGoogleが解釈したのが、その真ん中に書いてある5つになります。

具体的にここに書いてあることをそのまま読み上げると、組織のサイロを削減しよう、エラー発生を普通と捉えよう、段階的変更を実施しよう、ツールと自動化を活用しよう、すべてを測定しようですね。これを具体的にどんなことをすればいいのかという実践のところは、それぞれSREの中で対応する実践が定義されています。

組織のサイロの削減に関しては、所有権の共有ですね。エラー発生を普通と捉えるのは、エラーバジェットによる許容。段階的変更を実施するに関しては、カナリアリリース。ツールと自動化の活用に関しては、手作業の自動化。すべてを測定することに関しては、苦労と信頼性の計測になります。今回はこの中でもモニタリングとオブザーバビリティに関する話なので、ハイライトしている2つにフォーカスして、次から話をしていきます。

ここまでの話をいったんまとめると、DevOpsとSREは方針とそのプラクティスの関係です。その目的は迅速に価値をエンドユーザーに届けるためにSREのプラクティスを実践しようというところですね。今回の話でいくと、SLI/SLOを用いてどこまでなら失敗を許容できるかを定めようということをお伝えしました。

先ほどチラッとワードが出ましたが、エラーバジェットもSLI/SLOに密接する重要な概念になるのですが、そのへんまで話すと時間が足りないので、今回は割愛します。

（次回へつづく）