【要約】NewRelicのService Levels機能でSLI/SLOをTerraform管理する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
ゼロバンク・デザインファクトリーのインフラチームは、BaaSサービスの運用においてSLI/SLOの導入と継続的な改善という課題に直面した。機能開発が活発な環境では、SLOの更新頻度が高まり、手動運用が大きな負担となる。具体的には以下の問題が発生する。
- ・GUIでの手動設定は変更作業が煩雑で、CI/CDの恩恵を受けられない。
- ・変更履歴が残らず、dev/stg/prodなどの環境間で設定の差異が生じる。
- ・運用作業が定型化・肥大化し、SREにおける「トイル」を増大させる。
// Approach
チームはSLI/SLOの定義をTerraformによってコード管理するアプローチを採用した。これにより、変更の可視化と環境間の一貫性を確保する。具体的な手法は以下の通りである。
- ・SLIを「可用性」「レイテンシ」「エラー率」の3種に分類し、Terraformモジュール化した。
- ・
newrelic_service_levelリソースを用い、valid_eventsとgood_events（またはbad_events）で条件を定義した。 - ・API単位でモジュールを呼び出し、環境ごとに変数で目標値を管理するディレクトリ構成とした。
- ・APMが利用できないケースでは、Logイベントをデータソースとして活用する柔軟性を確保した。
// Result
現在はPoC段階であるが、SLO管理の自動化に向けた基盤を構築した。これにより、SLOの変更をコードとして扱い、安全かつ迅速な運用が可能となる。期待される成果は以下の通りである。
- ・GitLabのMerge Requestを通じて、SLO目標値の変更をコードレビュー可能にした。
- ・共通モジュールの利用により、環境間の一貫性を担保する仕組みを整えた。
- ・今後はError Budget Burn Rate Alertとの連携や、ダッシュボードのTerraform管理への拡張を予定している。
Senior Engineer Insight
> SLOをIaCで管理する判断は極めて合理的だ。SLOは計測データに基づき継続的に調整すべき「動的な指標」である。これを手動で行うのは、スケーラビリティの観点から見て運用ミスを誘発する。特に、APIごとに異なるレイテンシ閾値を設定する設計は、実戦的で妥当だ。ただし、Terraformのコード肥大化を防ぐため、モジュール設計の抽象度をどこまで上げるかが、長期的な運用の鍵となるだろう。