みんなの銀行のシステム監視からオブザーバビリティへの道 #3 運用と今後のオブザーバビリティ編

#2 ではNew Relicの開発に関してお伝えさせていただきましたが、続いてのセクションでは今後のオブザーバビリティに関してお話しさせてください。
## New Relic導入完了
ということで、一年という年月をかけNew Relicのリリースが完了しました。
まだ見てないよという方は以下リンクに飛んでください。
- [#1 導入検討編](https://qiita.com/t-ishii-zdf/items/19d8b72335b1c9204809)
- [#2 開発編](https://qiita.com/t-ishii-zdf/items/5e955d330829879cde35)

### まずは、『New Relicを導入してよかった＼(^_^)／』　
と言いたいです。

そして、いくつか導入後の感想をまとめたのでご紹介します。
### <助かっている事>
- みんなの銀行が導入前からたくさんのFeatureRequestを出してますが、それらが早期に取り込まれ、継続して改善が実施されています
- New Relicではデータ取得や設定に、NRQLというSQLに近いクエリを利用したデータ抽出を行いますが、普段からSQLを触っている人間にとって馴染み深く、運用メンバーの早期習得ができました
- New RelicのTerraformプロバイダによって、資源のほとんどをインフラコード化できていることで、環境別の比較が容易だったり、リリースまでの時間やコストを短縮できました
- New Relic社の技術支援や手厚いサポートにより、内製メンバーによる設計構築ができたため、課題の解消や改善アップデートを実施する上で、アジリティが向上しました（個人的にはこれが一番嬉しい）

### <苦労している事>
- 前監視システムと比較し、運用者側でのカスタマイズ要素の多いことが挙げられます（しかし、裏を返せば自由度が高く細やかな監視要件の実現が可能で、今後の機能アップデートにも期待が持てるので、大きく不安視はしておりません）

## 開発時の工夫点
続いて、今回New Relic開発時に工夫した点をご紹介いたします。
#### Nri-Flex/StatsDを利用したカスタムメトリクスの取得
- 標準で取得できなかったメトリクスについては、New Relic社から公開されているNri-Flexツールをカスタマイズすることで取得可能になりました
- APIから独自発信するビジネスメトリクスはStatsDを実装することで取得可能になりました

#### コンポーネントのTerraform資源のモジュール化
- 主要コンポーネントの資源を全てTerraformコード化、さらにモジュール呼び出し構造にすることで、必要なパラメータを環境別の資源にセットするだけで、各種コンポーネントの作成が容易に可能になりました

#### 条件に合わせたヘルスチェック用スクリプトを作成
- Synthetics Scripted APIを活用し様々なリクエスト条件に合わせたヘルスチェックスクリプトを作成しました
-- 例）パラメタの中にクライアント証明書を入れて認証を通すスクリプト
-- 例）200以外のステータスコードを正とするスクリプト

## SRE体制導入
ここで少し本題から外れますが、みんなの銀行は開業4年目に入り、SREチームの体制構築を進めております。
- 選抜されたメンバーにて、SRE本格導入に向けたチームが発足しました
- SREチームが、みんなの銀行のMVV（Mission・Vision・Value）も踏まえて、SREにおけるMVVを定義しました
- 今後はSREとして組織だって、開発スピードやサービスの品質の向上に取り組んでいきます

### SREの目標
- システムの信頼性に焦点を置き、その性質を向上させるため、ソフトウェア・エンジニアリングを通じて設計と運用の改善し、プロダクト・サービスの可用性・信頼性に対して責任を負うこと
- 最終的な目標としてはエンジニアがプロダクトに集中し、開発速度を向上できるようにすること

## SREの定めるValue
SREの定めるValueのひとつに、こんなものがありますのでご紹介させてください。
### 『指標をベースにしたオブザーバビリティ』
その内容について具体的にご説明いたします。
- システムの状態を明確な「指標」でとらえ、問題や障害を未然に防ぎます
- その「指標」をもとにSLI / SLOを設定して、健全な監視設定やリリースを実施します
- SLI / SLOについては定期的に継続して見直していくことでオブザーバビリティを強化していきます

## オブザーバビリティ強化に向けた目標
みんなの銀行はSREを主導とし、先ほどの『指標をベースにしたオブザーバビリティ』の他に、以下のテーマを掲げ、オブザーバビリティの強化を図ろうと考えております。
- マイクロサービス間の通信におけるボトルネックや障害ポイントの早期発見
- ビジネスサイドとシステムサイドが共通認識できるデータの可視化

## 今後のオブザーバビリティにおけるロードマップ
![スクリーンショット 2024-12-19 10.42.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3489170/04799c43-c81b-e0d5-ab29-51fd24e3e372.png)

みんなの銀行のSRE、システム運用チームはNew Relicを活用しながら、具体的にどうやってオブザーバビリティ強化を進めていくかを考えました。
その中で、上図の通り３ステップに分けたロードマップを作成いたしました。
現在みんなの銀行は、ステップ１のところを実施しており、導入後の課題消化やモバイルデータ、APMによるバックエンドのデータ収集に明け暮れてるところです。

## 最後に
今回の監視基盤構築を通じて、私自身初めての大規模な監視基盤の構築を経験することができ、監視運用業務を深く理解し、また新たな課題も見つけることができ、とても得難い経験ができました。
みんなの銀行はNew Relicにおいて、一部の機能しかまだ実装できておらず、New Relicを使って運用改善活動やSRE活動を推進できることが沢山あると思ってます。
今後はNew Relic社の技術知見もお借りしながらオブザーバビリティを強化してまいりますので、今後ともみんなの銀行を安心してご利用頂ければ幸いです。

以上、ご清覧いただきありがとうございました。

## 参考資料
- [[New Relic Flex] カスタムメトリクスの取得 公式ドキュメント](https://docs.newrelic.com/jp/docs/infrastructure/host-integrations/host-integrations-list/flex-integration-tool-build-your-own-integration/)
- [[StatsD] メトリクスの取得 公式ドキュメント](https://docs.newrelic.com/jp/docs/infrastructure/other-infrastructure-integrations/statsd-monitoring-integration/)
- [[Synthetics] Scripted API 公式ドキュメント](https://docs.newrelic.com/jp/docs/synthetics/synthetic-monitoring/scripting-monitors/introduction-scripted-browser-monitors/)