サイト信頼性エンジニアリング(SRE) の適用可能性

テクノロジーコンサルティング本部　 シニア・マネジャーの青柳雅之です。金融サービスグループに所属しています。

Accenture Google Business Group (AGBG) Solution Architectでもあります。

さる6月29日、Jagu'e'r(Google Cloudのエンタープライズユーザー会)　の金融分科会 第４回 Meet Upにて、金融機関のSRE 適用可能性を探るというパネルディスカッションを行いました。私もパネラーの一人として参加させていただきました。今回のブログでは、パネルディスカッションで議論された内容を振り返りながら、Googleが考えるSRE(Site Reliability Engineering、サイト信頼性エンジニアリング)の考えをベースに、金融機関以外の組織も含めた一般的なSREの適用可能性の論点をいくつかピックアップしたいと思います。実際のパネルディスカッションの内容については、Jagu'e'rのブログを参照してください。

GoogleにおけるSREとは

SREの最終目標は、サービスを改善し、ユーザーエクスペリエンスを向上させることです。ユーザーエクスペリエンスはアプリケーションの可用性などのサービスレベルに依存します。そのため、SLI(サービスレベル指標)を確立してモニタリングすることが重要です。SLIとしては、可用性、レイテンシなどが利用されます。SLIで計測されるサービスレベルの目標値がSLO(サービスレベル目標)です。Google内では、希少なエンジニアリソースを最も重要なサービスの特性に投資し、サービスが過剰なサービスレベルを持ちすぎてエンジニアの運用負荷が高まらないように、定期的なダウンタイムを実装しています。このようなユーザーエクスペリエンスにネガティブな影響を与えない許容されたダウンタイムはエラーバジェットと言えます。以前から使われているSLA（サービスレベル合意）は、ユーザーとの間の契約で定義されているSLOが提供できなかった場合にペナルティが運用側に課せられるものです。SRE BooksにはGoogleにおけるSREが詳細に述べられています。

• SREは何から始めるのか

まずはゆとりを作ります。ゆとりがなければ、SREや他のいかなる目的の新しい施策は実行出来ません。そのため、無駄な会議をなくし、手作業の自動化を促す最適なツールを入れるなど、ゆとりを作る施策を最初に行うべきだと考えます。そこで生まれたゆとりの一部を、SRE導入のための施策に使うのです。ゆとりは全部使い切ってはいけません。昔、トム・デ・マルコの「ゆとりの法則」を読みました。書籍には15パズルの絵が出てきます。15パズルは駒を一つ抜くことで、その他の駒を動かせることを示しています。もう１つ駒を足す、つまりゆとりなしで作業をメンバーに実施させると作業は効率化できますが、変化に対応できなくなるとトム・デ・マルコは主張しています。

15パズル

• エラーバジェットをいかにクライアントに許容してもらうか

クライアント（ここではユーザーにサービスを提供する組織とするとわかりやすいでしょう）は、可能な限り高いSLOを要求するかもしれません。SREの目標はユーザーエクスペリエンスの向上ではありますが、コストも最適化する必要があります。次のように考えてはどうでしょうか。

• エラーバジェットを積んで、取りうる最大のSLOよりも目標を下げたとしても、ユーザーエクスペリエンスは変わらないのではないか?
• SLOを下げた分、エンジニアリソースの割り当ても減らすことができて、サービスの他の重要な特性にそのリソースを振り分けられるのではないか？

過去にダウンタイムが発生した際の、ユーザーの利用時間やサービスに払うコストを計算します。一定のダウンタイム内であれば、それらが大きく低下しないこと、つまり、ユーザーエクスペリエンスに影響がないことが導出できないでしょうか。その際の一定のダウンタイムは、エラーバジェットの最大値と言えます。クライアントにはその考えを時間、コストといった数字を用いて説明します。

SREを適用するために、既存の組織モデルの問題にどのように挑むか

• ピラミッド型組織の問題

SREではメンバーの自発的な参画が望まれますが、階層の深いピラミッド型組織では、階層の下にいるメンバーほど上位の管理職に作業の指示を仰ぎ、あらかじめ定められた内容を実行するマインドになっています。SREでは常に改善に取り組みことが重要ですが、ピラミッド型組織では、SREのための改善案を階層の下のメンバーが上位階層に対して自発的に出すには勇気が要ります。そして、組織批判につながりかねない改善案が自らの評価を下げるような組織では誰も前向きな意見を言えなくなります。これは心理的安全性にも関わってきます。加えて、ピラミッド型組織では意思決定や技術判断が管理職層に集中しやすく、管理職のみが改善案を出すためのアイデアを持ちやすくなります。しかし、彼らの負荷は非常に高く、改善のための施策を行う時間はないはずです。このような場合は、どうすればよいでしょうか。例えば、ピラミッド型組織とは別の仮想組織（SREの問題を解決できるスキルを持ったメンバーを各チームから招集）を作り、短期間で様々な問題を解決したり横断的に使える標準を用意するロールを持たせ、既存のピラミッド組織を支援する形もあると思います。

• コンウエイの法則に関わる問題

システムのアーキテクチャは、その組織構造を反映されたものになるというのが、コンウエイの法則です。組織の境界を職能ベースで決めてしまうケースはよくあると思います。例えば、アプリ、インフラ、運用、移行と言った形でチーム分けをしてしまうようなケースです。ある特定の領域はスキルを持った人がいないので職能別でチームを分けて様々なシステムを横串で見させたいという理由かがここにあります。１つの同じシステムに対して、これらスキル別、職能別の別のチームが関わる場合、チームの境界とシステムの境界が異なりますのでコンウエイの法則との矛盾が出てきます。そして、それぞれのチームの間の作業スコープに入らないグレーゾーンが出きて重要な事項を見落とす、チーム間の情報交換のための会議時間が増加するといった問題があります。一方で、Googleではチームは製品もしくはFeatureにチームが分離されており、チーム間のコミュニケーションの量は最適化されています。私も職能よりはサービスでチームを分け、各チーム内に様々なスキルセットを持つメンバーを配置することに賛成です。このようなチームモデルでは、サービス別のチームで必要なスキルセットを定義し、そこに到達するための技術習得のためのロードマップも定義する必要があります。アサインされたメンバーはそのロードマップに従い、学習を行い、新しいスキルを身に着けることができます。これがないと、現時点でそのスキルを持つ人を探さねばならなくなり、それが希少なスキルであるほど、いつまでも人がアサインできない、という状況になります。

• SREは運用フェーズだけでなく、新規開発でも適用できるか

SREを実践する組織として適切なSLOを実現するには、システムの品質を高めるために、運用するシステムを構成する複数のサービス間のアーキテクチャ上の整合性が取られている必要があります。そして、新規開発では後続フェーズで手戻りが発生しないように、上流フェーズからこのアーキテクチャの整合性を強く意識する必要があります。これを実現するにはアーキテクチャの不整合を起こしづらいチームモデルや、チーム間の十分なコミュニケーションを考える必要があります。つまり、SREの考えは新規開発でも適用できると考えます。

最後に

以上を振り返ると、SREの実現は、テクノロジーの寄与だけでなく、組織の諸問題を解決するチームモデルと、心理的安全性で担保される働く人の前向きなマインドセットに大きく依存すると考えます。