モノリシックなプロダクトのSRE

マイクロサービスの話ばかり

SREについて書いた文書のほとんどがマイクロサービスを前提としています。
SREがいかに複数のサービスをカバーし監視していくか、各サービスの担当者とどのようなコミュニケーションをとるか、といった議論が展開されます。

では、モノリシックなシステムを抱える場合、何を参考にして、何に気を付けるべきでしょうか？

モノリスの課題

多くの監視、イベントに関するプラクティスはそのまま導入できます。

エラーバジェットやSLOを導入し、ポストモーテムを実施することで、定量的な指標に基づく合意形成や、自浄作用のある組織文化の醸成が可能です。しかしSLO策定の際や、SLO違反やバーンレートによる予兆の検知後の緊急対応の際に、課題が浮き彫りになります。

主な課題は以下のようなものが挙げられそうです。

• 監視対象のリソースを多くの機能が共有し最小限の監視が難しい。
• 機能とチームが紐づいておらず問題箇所に対処できる人員が不透明である。

監視対象のリソースを多くの機能が共有し最小限の監視が難しい。

データベースなど共有するため単一障害点となりやすく、特定の機能が起因でシステムに負荷がかかった際に芋づる式に次々と不具合を起こし、原因となっている処理の発見が困難になります。ユーザに近い指標で検知できた異常の原因を探るのに、かなりの詳細なメトリクスやログを必要としてしまいます。
小さく始めて効果を体感したくても、土台が出来上がるまでに多くの時間を要しメリットを得られづらいと感じてしまうかもしれません。

機能とチームが紐づいておらず問題箇所に対処できる人員が不透明である。

巨大なシステムを大きなひとつのチームでメンテナンスします。そのため、開発者によって機能ごとに理解度に差があるけれど、組織として責任分界点はなく機能単位での明確な担当者がいない状態になります。すると、有事の際には人探しから始める必要があり、トップダウンに広く開発者全員に呼びかける形をとるはめになってしまいます。ボールの所在が明確でないコミュニケーションは不安も大きく、善意の人への依存を生む原因にもなります。

SLOの策定時も多機能なシステムの機能ごとに対し、どういった指標を見るべきか、妥当な目標値はどの程度なのかといった知識が分散していて誰が所有しているのかわからず、人探しから始めることになります。また、1つのプロダクトをみる大きすぎるチームにおいてはボトムアップな合意形成が難しく、結果として多くの開発者に対し突然制約を押し付けられたような印象を与えてしまう懸念もあります。

どう立ち向かうか

1つ目については時間をかけてシステムを紐解き、時にはコンポーネントを切り出しながら、可観測性をあげるしかないでしょう。がんばりましょう。

2つ目の課題の解決には広くメンバーを集めたワークショップが効果的だと考えています。
目的は2つです。

• SLOの検討・ブラッシュアップで顧客体験との関連を意識づける
• SLO違反など緊急対応の際に誰がどう動くべきかを議論する

自身で検討する場を持つことで課題を認識しつつ、その解決を図る機会になります。意見は拾い上げられ組織の知見として共有されます。
結果として、体制に緊急対応をうける役割が生まれたり、各機能の重要性やSLOの意義が浸透したりすると期待しています。

SLOのワークショップはGoogleからThe Art of SLOsが公開されています。
こういったものを参考にしつつ実際の組織の実態に合わせたストーリーにすべきでしょう。

いまは試行錯誤の段階で明確に結果は出ていませんが、引き続きこのテーマに取り組みます。
ご意見いただけるとうれしいです。