#1 ではNew Relicの導入検討に関してお伝えさせていただきましたが、続いてのセクションでは開発に関してお話しさせてください。

開発にあたって

正式にNew Relic社との契約締結に至り、いよいよNew Relicの導入構築が始まることになりました。
そこでまず、おおまかな開発スケジュールやタスクの洗い出しを行い、各種設定イメージを膨らませていきます。

開発手法

開発手法につきまして、みんなの銀行の開発環境で、New Relic資源の作成からスタートとなり、その後他環境へ展開していきます。
以下のイメージは、みんなの銀行の各環境断面におけるNew Relicの展開方法になります。

開発環境：基本設計・詳細設計で実施した設計をもとに、ベースとなる資源を作成
システムテスト環境：開発環境で作成した資源を水平展開し、システムテストや運用テストなどを実施
擬似本番環境：擬似本番環境ではリリース手法だったり手順を明確にし、移行リハーサルを実施
プロダクション環境：手順に基づいたリリースを実施
※各環境は、役割に応じて作成されたみんなの銀行の既存の基盤

New Relic全体構成イメージ

みんなの銀行システム基盤は、Google Cloudをメインの基盤で使用しておりますが、その他にAWS、Azure、オンプレミス基盤も使用しており、それぞれNew Relicとの統合機能が存在し、各種データを連携をしております。

New Relicを使用したメトリクス、イベント、ログ、トランザクションの連携方法

以下のイメージは、MELTと呼ばれる監視で必要なメトリクス、イベント、ログ、トランザクションデータ(APM)のNew Relicでの連携方法を表しており、PaaS側のVMやGKE等のKubernetes Resource等のコンポーネントに対し、New Relicエージェント連携やインテグレーション機能等の、連携機能があります。

アラート発報時の各種通知方式

通知機能に関しては、New RelicのWorkflow機能を使用して細やかな通知設定を実現いたしました。
また、即時対応、翌営業日対応、静観対応の対応レベルに分けそれぞれ通知を実装いたしました。

導入スケジュール

スケジュールは以下のとおりで、昨年7月から設計に入り最終的にリリース完了したのが今年の5月となり、前監視システムをクロージングまで持っていくのに約1年を要しました。
また、テスト工程中に、メンバー間で設計理解度にバラツキが生じていることが判明したため、一度一呼吸置いて設計再確認と設計ドキュメントの追加作成を行い、監視基盤の構成理解度を底上げしました。

少しテクニカルな話

StatsD AgentへのSecretManagerからのAPIキー注入
以下イメージのとおり、New Relicの公式Yamlには、Google CloudのSecretManagerに格納しているAPIキーをPodにマウントするパラメータがなかったため、公式Yaml(Helmテンプレート)を直接Secretオブジェクトを呼び出すように修正することでStatsD Pod(Agent)にAPIキーをマウントすることができました
<キーマウントイメージ>
※StatsD Podは、Secret値(APIキー)をSecret Objectから直接取得
資源のTerraformモジュール化
New Relicの資源にあるWorkflowやAlert、Syntheticsなどの資源のほとんどをTerraformでコード管理し、そのTerraform資源もモジュール呼び出し構造にすることで、必要なパラメータをセットするだけで資源が作成できるようになり、前監視システムの資源と比べて、大幅にコード削減を実施することができました。
<モジュール構造イメージ(一部抜粋)>
※下記イメージの通り、モジュールをメインのモジュール、中間モジュール、そのモジュールを呼び出すパラメータ群でツリー構造に

課題とその対処

続いて今回のマイグレーション中に浮き彫りとなった課題と、それらをどう克服していったかを簡単にご紹介させてください。

開発者メンバーに監視システムのマイグレーション案件の経験がなく、キャッチアップに時間を要しました。この解決法として、設計レビューとペアプロをひたすら繰り返し、メンバー間ですり合わせを密にすることで認識齟齬を防ぎました
みんなの銀行のCorebank(BtoC基盤)とBaaS(BtoB基盤)で開発チームを2つに分けたことで、要件や設計等の共通認識にズレが生じた状態で開発に入ってしまいました。この解決法として、開発がひと段落した段階で、両チーム合同で設計再確認、レビューを再度行うことで開発メンバーの構成理解度と品質を上げました
New Relicの標準仕様では通知内容が不十分であり、初動対応などに時間を要す可能性がありました。この解決法として、New Relicのエンリッチメント機能によるログなどの詳細情報の追加を行うことで、通知内容の充実を図ることができました
New Relic標準で取得できる、Google Cloud関連のメトリクスが、少ないことに課題を感じていました。この解決法として、New Relic社から提供いただいたメトリクス取得スクリプトを活用し、メトリクスを別途取得することで不足を補うことができました

以上が開発編になりますが、次回の『#3 運用と今後のオブザーバビリティ編』はオブザーバビリティ強化に向けたみんなの銀行の取り組みや、今後の展望などをお話させていただければと思います。

#3 運用と今後のオブザーバビリティ編へ続く