オブザーバビリティを使って分散されたモノリスをぶっ飛ばすための武器をつくる

レバテック開発部SREチームの蒲生です。
最近うちの開発部でZennのPublicationができて 「記事を書きなさい」と命令をされたので「テックブログ盛り上げたいので手伝ってください🙏」とお願いされたので
記事を書くしかない状況になってしまいました（記事書きやすい環境になっていってて嬉しい）

今回は弊社開発部で初めてオブザーバビリティへの挑戦をすることが決まったので
そちらの経緯と色んな人の意見を聞いて僕なりに噛み砕いた意見を書こうかなと思います。

この記事で伝えたいこと

ちょうど僕が世代だったモン◯ンを例にして書いてみます。

• モニタリングは初期武器
• オブザーバビリティはモニタリングの強化武器
• オブザーバビリティ化（武器強化）にかけるコストの考え方

立ち向かうモンスターと己の武器を見定める

パーティとマップ、そしてクエスト内容

自分が戦うフィールドといっしょに戦う仲間、そして勝利条件の確認からしていきましょう。

開発体制

人数

正社員のエンジニア約５０名
業務委託のエンジニア約３０名

チーム編成

レバテックの中での各事業ごとに開発チームを配置し、チーム横断的にSREとイネイブリングチーム、最後に各事業のサービスから参照するマイクロサービスを管理するプラットフォームチームがあります。

システム概要

運用しているシステム群

レバテックの各サービス・事業を支えるシステムは上記のようになっています。
各システム間の連携や営業支援システム、外部サービスとの連携があり、レバテックに関連したレポジトリだけでも200個以上あり、大規模なシステムになりつつあります。

モニタリング体制

CloudWatchによる監視からDatadogを使った監視体制に切り替えて、アラート設定やダッシュボード作成を開発チームで運用している状態
参考記事

各チームによるDevOpsのサイクルがだんだん固まってきたような感触がありつつも
大きい運用課題を抱えてもいました。

既存の運用課題

• 分散されたモノリス状態
  • 運用コストの増大につながっている
    • 毒状態が続いてHPがどんどん減ってったりスタミナ少なくて全力疾走ぜんぜんできない
• サービスの信頼性を測る指標がない
  • 増大した運用作業に対して機能開発軸のタスクとの優先度調整が難しい
    • ユーザー影響に関して共通の認識を持てていないのが原因っぽそう
      • お互いがお互いのHPを把握してなくて、HPまだいっぱい余ってるのに粉塵使いまくったり、逆に死にそうなのに全然粉塵使ってくれない

クエスト内容

【分散モノリス状態を脱却するためのリニューアルプロジェクトを完遂させること】

運用課題の根本原因である分散モノリスの状態から、それぞれのシステムとデータが”独立化”し”疎結合化”された状態を目指して全体のリニューアルを進めていっています。

今持っている武器を確認してみる

さて、壮大なクエストが幕を開けたのですがここで僕たちが持っている武器を確認してみましょう。
開発における武器は色々なものが考えられると思うけど、ここではモニタリングに関して見てみます。

Q. モニタリングができているとは？
A. アラートが鳴ったら対応するフローができているか
（インシデントに対して事後対応になってしまう体制であったとしても、これができていない状態でオブザーバビリティを導入してもうまくいかない）

これは外部のエンジニアさんと話した時に出てきたものなんですが
「モニタリングができている状態」の定義と、まずモニタリングの体制を作ることの重要性が現れています。

弊社ではクラウドやインフラのメトリクスやログを取得することで「モニタリングができている状態」は十分に作れているなと思いました。

なので初期武器としてちゃんとしたものを持てています。
次に、まずモニタリングの体制を作ることの重要性です。

モン◯ン的に言うと、武器強化を始める前に強い武器に鍛え上げられる初期武器を作っておく必要があります。
オブザーバビリティがどんなに優れている武器で手に入れたいものだったとしても、進化元となるモニタリングがないと、その武器を作り出すことはできないというのが感覚としてわかりました。

オブザーバビリティは全く別のものではなく、モニタリングを内包しているということを念頭に動き始める必要がありそうです。

クエストに立ち向かえるか

では、今のモニタリング体制（武器）が今回のクエストレベルにあった力を備えているかについて考えてみます。

弊社のシステムではマイクロサービスアーキテクチャを採用していてサービス間の通信が頻繁に発生しています。
オライリーのマイクロサービスアーキテクチャ本にはこう書いてあります。

モノリスをマイクロサービスに置き換えたので、あらゆる障害は殺人ミステリーのようなものになった

既存のモノリスでの監視とは違い、障害が発生している場所の特定とその原因を把握することが確かに難しい状態になっています。
今のままだと難易度はベリーハードっぽいです(´；ω；｀)

武器を育てる

では、ベリーハードに対応するために、初期装備として持っているモニタリングを、オブザーバビリティという強化武器に進化させていこうと思います。

素材集め

まずは、武器を強化するための素材集めですね。
今回はNewRelicを使って、初期のモニタリングに対して以下の強化素材を手に入れました。

• トランザクションごとのテレメトリデータ
• トレース情報（サービスごとの通信状態）

いざ武器強化

さて、得られた素材を使って武器を育て、装備を作ります。
弊社では、以下の効果を狙って装備を整えてみました（本当は整えている途中）

• ユーザー目線のアラートとSLI/SLOの設定
  • トランザクションやトレース情報を使ってユーザー体験
  • ビジネスにとって重要なテレメトリデータの特定
• サービスマップや通信状態からレガシーシステムや依存度の高いシステム同士の状況把握
  • 不具合の症状だけではなく原因の特定までの時間の短縮
  • 運用しているエンジニアのシステムへの解像度の向上

なかなか上質な装備が集まりました（シリーズ全部揃えられてないけど）

武器強化のお金と労力に対する考え方

最後に、オブザーバビリティにかけるお金と労力について考えてみます。

ここではモン◯ンにもじって書いてますが、現実のビジネスではゲームの世界以上に考えないといけないことがあります。
SRE以外のチームが持っている武器もアイテムもありますし、武器単体だけではなく立ち回りやチーム間の連携、全体のお金の管理、事業や業界の移り変わり、競争を意識しないといけない場面は多々あるでしょう。
こういった武器強化のためにかけるお金と労力の価値を見てみます。

素材集めの旅やそれにかけるお金と労力の価値

導入を考えたことのある方はわかると思うんですが、オブザーバビリティのツールの金額は高いですよね。
ログやトレースのデータ量は今まで扱ってきたものと比べると膨大なものになり、それの保存と可視化に対してかかる費用と見ると確かに高く感じます。
では、現時点と将来のそれぞれの視点から考えてみます。

現時点での視点

現時点の状態を見てみると、弊社ではマイクロサービスアーキテクチャを採用しています。

アーキテクチャやシステムの複雑さの難易度は結構高めですが、
サービス間の通信を監視しきれないまま運用するのって武器を強化しないままクエストに行くようなものなんじゃないかなあと最近思います。

オブザーバビリティを導入しない＝運用にめちゃ苦しむことを意味している（なお、スーパーエンジニアが余るほどいる組織は除く）のであれば、武器強化のための旅には時間とお金をかけるべきものと思っています。

将来を見据えた視点

次に、将来のことを考えてみましょう。

今回のクエスト内容は、分散モノリス状態を脱却するためのリニューアルプロジェクトを完遂させることですが、
物語がそこで終わるわけでもありません。次章があるわけです。

うまい具合のアーキテクチャのシステムになっても、システムそのものの全体の複雑性が下がるわけではありません（疎結合になったりテストがやりやすくなるなどして運用がしやすくはなると思います）
また、サービスの運用を長く続ければ続けるほど、出会ったことのないモンスターに立ち向かう必要が出てきます。
オブザーバビリティがそのための一助になればいいなと思います。

もちろん事業のフェーズや売上にもよると思うんですが、難易度が高く不確定要素の多いクエストに挑むのが日常になったら、武器のレベルを下げることはできないですよね。

いざG級へ

弊社では、NewRelicを用いてオブザーバビリティを成熟させていって取得したテレメトリデータを使って
開発者が難しいクエストに立ち向かえる環境を作っていきます。
実際オブザーバビリティによって生まれる効果がどのくらいかは不確実ですが、
まずは試す試す試す、そして計測するというスタンスでやっていきます。

なんだか取り留めもない文章になってしまいましたが、最後に僕の好きな名言で。
「推測するな、計測せよ」