はじめに
レバテック開発部、SREチームに所属している金澤です。
弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。
そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。
今回はこのADRの内容を公開します！
※本記事はNewrelic、Datadogを肯定、否定するものではございません。
ADR
コンテキスト
事業軸
- レバテックの事業戦略は事業ポートフォリオ構想に従っている
- 既存の事業を拡大させながら新規サービスを生み出し続ける
事業ポートフォリオ構想
- 既存の事業を拡大させながら新規サービスを生み出し続ける
開発軸
- 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化
- スケーラビリティとアジリティの担保が困難になってきた
- バグ、障害の発生
- レビュー工数の増加
- 新規参画者の参画ハードルの高まり
現状の課題と懸念
- 既存システムの運用負荷の高さ
- リアーキテクト対象の既存レガシーシステムの運用負荷がもともと高い
- 障害対応や機能開発軸以外の工数が多くとられている
- これによりリアーキテクトプロジェクトに工数を回すことが難しい状態
- 分散トレーシングなどマイクロサービスアーキテクチャでのトラブルシューティングを十分にできる計測基盤がないことも運用負荷を上げている要因となっている
- リアーキテクトのリリースによるサービス影響の不確実性の大きさ
- リアーキテクトした変更や新規マイクロサービスのリリースによる影響が社内外ユーザーにどう出るかが今のメトリクス、ログ中心のモニタリングで把握が難しい
- リリースによって品質が下がり、下がった品質の修正に時間がかかることで新しい負債につながる可能性がある
案
以上の懸念をSRE軸から解決する手段としてオブザーバビリティの導入を進める方針で決定。
既存のモニタリングでは、各システムのメトリクスやログからしか必要な情報が得られず、マイクロサービス間の通信状態やエンドユーザーへの影響を計測しづらい状況であり、開発者に負担なく運用してもらうにはオブザーバビリティが必須である。
そのうえでオブザーバビリティツールとして採用するものを選定する。
| 内容 | |
|---|---|
| 案1 | 既存の監視ツール、Datadogを使ってオブザーバビリティを実現していく |
| 案2 | Newrelicをオブザーバビリティツールとして採用してDatadogから監視を移行する |
| 案3 | OpenTelemetryなどOSSを利用して自前で計装する |
比較
今回、レバテック開発部ではNewrelicを採用し、オブザーバビリティ体制を整えていくことで決定。
ここでは、採択に至った理由を記録する。
比較内容
ツール選定における主要な軸
- 機能において、レバテック開発部としてオブザーバビリティで実現したいことができるか
- コストにおいて、課金体系、初期コスト、長期的なコストの比較
- サポート面の比較
Newrelic
| 分類 | 評価 | 内容 |
|---|---|---|
| 機能 | ○ | APMやBrowserモニタリング等、課題を解決するのに機能は十分である |
| 機能 | ○ | 機能事の課金でないため、様々な機能を試しながら使用することが出来る |
| コスト | ○ | アカウントごとの課金であり、コスト管理が比較的容易。ダッシュボードを見るだけなら無料ユーザーでも運用可能 |
| コスト | ○ | ３ヶ月間のライセンス数、データ転送量増加分の補填をしてくれる（True-Upモデル） |
| コスト | △ | Datadogからの移行を含めて初期導入コストが大きい(開発チームのキャッチアップ等含む) |
| コスト | △ | 不要な機能をカットしてコストを抑えることはできない |
| サポート | ○ | 追加コスト無しで社内勉強会の開催や普段の運用でのサポートがあり、開発チームへのインプットがやりやすい |
| その他 | ○ | ユーザーグループの活動が活発で、定期的なイベントや本の出版がされている ユーザーグループ含め技術広報活動の場が広い オブザーバビリティツールのシェア率が日本の中ではNewrelicが１番 |
Datadog
| 分類 | 評価 | 内容 |
|---|---|---|
| 機能 | ○ | 機能面でNewrelicとの違いはあまりなく、レバテック開発部の課題を解決することは実現可能 |
| コスト | ○ | 移行コストがなく、オブザーバビリティに必要な機能を追加するだけで対応できる |
| コスト | ○ | 機能ごとの課金体系なので各機能を段階的に試すことができる |
| コスト | △ | 機能ごとの課金、従量課金の幅、開発規模が拡張したときのコスト増が懸念 |
| サポート | △ | オブザーバビリティ導入に対するサポート受けるには別途プランに入る必要がある（Datadog Services and Support） |
| その他 | △ | ツールの思想としてあくまで監視の延長線上にあるところが気がかり |
OpenTelemetry
| 分類 | 評価 | 内容 |
|---|---|---|
| 機能 | ○ | 計装すれば不足はない |
| コスト | ○ | ツール導入自体にお金はかからないのでスモールスタートに最適 |
| コスト | △ | 運用コストが高く開発者の工数が割けるかも怪しい |
| サポート | ✕ | 無し |
| その他 | ○ | オブザーバビリティ界隈のOSSのデファクトスタンダードになっていきそうなのでキャッチアップをするメリットが大きい NewrelicやDatadogとの連携も可能 |
| その他 | △ | 自分たちで計装が必要なため実現までのスピードがおそい |
検討
機能面についてはDatadog、Newrelic、OpenTelemetryのいずれにおいても明確な差は見受けられなかった。しかし、直近抱えている運用課題に対してオブザーバビリティ導入というアプローチをするうえで、一定のスピード感と新しい運用課題を生み出さないことは優先度が高いと考えている。社内にオブザーバビリティの知見はなく、ゼロからのスタートとなるため、サポートは必須であるとして、OpenTelemetryは断念。
DatadogではDatadog Services and Supportとして4つのサポートプランがあるが、一部は英語のみであったり、複数のプランを契約する必要がでた場合のコストに懸念がある。対して、Newrelicは追加プラン無しで担当のチームが配置され、社内のハンズオン研修の企画・実施やオブザーバビリティ、サービスレベルマネジメントの導入サポートなど幅広くサポートを受けることができる。このことから、現時点でレバテック開発部が必要とするサポートを、スピード感をもって受けられるのはNewrelicであるといえる。
また、従来の監視は本番環境のみを対象としていたが、オブザーバビリティの導入は検証環境も対象に含む方針であること、新規/リプレイスを含めてオブザーバビリティの対象となるシステム自体が今後も増えていくこと、サービス規模の拡大によりデータ転送量が増加することが可能性としては高い。一方、採用計画から、開発者が急増するとは想像しにくい状況である。このため、移行コストがかかることを考慮しても、ユーザー課金であるNewrelicの方が、現状の開発部の方針から判断すると長期的にコスト面で有利であると考えられる。
決定
以上の検討からオブザーバビリティの導入はNewrelicを採用して、監視をDatadogから移行していく方針に決定。
オブザーバビリティツールの料金が高額のため、いきなりすべてのサービスに導入していくのではなく、比較的ビジネスクリティカルなものを優先して適用させていく。
障害発生率など開発体験を測る指標で既存のモニタリング体制と比較して効果が出たと判断できたら、他のサービスにも順次入れていく予定。
さいごに
事業のフェーズや開発組織の体制、システムの構成によって、検討時の評価や最終的な意思決定の結論は異なってくるかと思います。
数年後、Datadogに戻したり、OpenTelemetryに運用を切り替える時が来るかもしれません。その際に、ADRが残っていれば、「体制も整備されてきたし、サポートよりも必要な機能だけに絞り込めた方がコストの面でメリットが大きいから〇〇に移行しよう」とか、「このシステムには全ての機能は必要ないから、一部の機能のみ必要なシステムは〇〇で管理しよう」といった、今回の決定に対して矛盾しない、正しい意思決定に繋がると考えています。
開発部内で意思決定の透明性が高いことは、それだけでも組織にとって価値があります。ぜひ皆さんもADRを活用してみてください！
Discussion