今回の記事は主にFIT2024で登壇させていただいた内容を掲載させていただいております
ゼロバンク・デザインファクトリー株式会社(ZDF)で、みんなの銀行BaaS基盤の運用、構築を担当している石井と申します。

はじめに

『みんなの銀行はNew Relicを導入します』

という情報が耳に入った方もいるかと思います。
みんなの銀行は、既に開業から3年が経過しており、金融システムのほとんどをGoogle Cloudなどを用いてクラウドサービス上に構築しており、延べ数十個のマイクロサービスと、サーバー、その他PaaS・SaaSの全てを別の監視システムで運用しておりました。
そんな中、みんなの銀行では新規サービスや機能が連日追加され、日に日にシステム規模が大きくなるため、前システムの課金体系では利用料が膨れ上がる事を懸念し、将来的な経費削減をしたいとの要望が持ち上がりました。
その中の一つとして、システム規模に比例しない課金体系のNew Relicに興味を抱くことになりました。

記事のテーマ

私の自己紹介になりますが、実はみんなの銀行に入行するまで、クラウド上のシステム運用構築経験があまりなく、サーバルームで凍えそうになりながら、ルータやオンプレサーバを少年気分でガチャガチャ触っているような人間でした。 そんな私が、手を動かしながら試行錯誤を繰り返し、それなりに大変だったよ！でも楽しめたよ！といったところをほんの少しだけご紹介させていただければと思います。
振り返ると、2022年10月にみんなの銀行に入社した私へ最初に与えられたミッションが、監視基盤をどうにかしたいといった課題でした。
今回のセッションでは、New Relicの導入に至った経緯と、開発前の導入検討に関して記載しておりますので、まだ導入されてないという方には参考になるかと思います。

みんなの銀行のシステム運用が抱えていた課題

当初、みんなの銀行が抱えていた監視システムの課題は、大きく３つありました。

1. 前監視システム利用料の上昇

前監視システムの課金体系が、システム規模に比例して増加する形となっており、利用料が上昇し続けていたため、将来を見据えたコストカットが必要でした。

2. 内製メンバーの監視システムに関するナレッジ不足

前監視システムは主に外部ベンダにより構築されたため、要件定義から携わった内製メンバーが少なく、ナレッジが蓄積できておらず、内製化を進める私たちにとっては、課題となっていました。

3. サポートの体制不足

前監視システムを運用時、サポートへの問い合わせに対する迅速な回答や、情報共有が少なく、障害発生時の即時対応などが難しい、コミュニケーションを密にできるサポート体制がほしいという課題を抱えておりました。

監視要件について内製メンバー間の共通認識

そこでまず初めに、PoCを始めるにあたり私たちの期待する監視要件について内製メンバー間の共通認識を持たせるところからスタートしました。
下記イメージのとおりみんなの銀行システム基盤から取得したデータを、どう活用してアラートやダッシュボードに落とし込むか、またそれらのデータをどう運用していきたいか見直しました。

PoC検討

そして監視システムのSaaSツールの中でシェアを伸ばしているNew Relicで、先述の課題や要件を解決できるのではと考え、机上検討、実際の環境を使っての検証の順にPoCを開始することになりました。

みんなの銀行の監視項目・監視要件にフィットするか机上でのフィジビリティ確認を実施
- 前監視システムとNew Reicのメトリクスの対応表作成
- 転送データ量の机上測定
- 基本的な機能要件の実現方法確認
さらに重要度が高い機能に絞り、実際の環境を使っての検証で設定動作確認を実施
- 開発環境にNew Relicを導入し、インテグレーションの手法等を確認
- 収集したデータの項目やその計測値の整合性を確認
- アラートやヘルスチェックの動作確認

PoC観点

今回実施するPoCは以下の観点で進めました。

1. コストメリット

New Relic導入後の想定費用の概算を計算し、現状の費用と比較して効果が見込めるか（利用ユーザー、蓄積データ量を算出し、New Relicの課金体形と照合）

2. 機能

監視要件の中から重要とされる項目について、実際の環境を用いた検証を実施した上で、ノックアウトとなるような項目はなく、現状の監視業務の維持が可能か

3. ナレッジ蓄積

内製チームメインで構築する事で、監視/マイグレーション案件/運用面において、技術ナレッジが蓄積できるか

PoCの成果

まず導入メリットとして、以下のようなメリットが確認できました。

メリット

1. コストメリット

課金体系が変わることで、下のグラフのようにコスト削減が可能になります。

2. 機能比較

前監視システムと比較して遜色ない監視運用ができ、さらに監視資源のTerraformによるIaC化することでレビューや、Terraformからの実行により各環境への適応が容易になることがわかりました。

3. ナレッジ蓄積

内製チームメインで構築する事で、監視運用やマイグレーション案件において、技術ナレッジが蓄積可能できると考えました。

一方で、導入した場合のデメリットも挙がりました。

デメリット

1. 運用負荷上昇の可能性

New Relicの仕様上カスタマイズ要素が多いため、実際のマイグレーション後に運用負荷がどれくらい上がるか、全容が見えず、予測がつかなかったことです。

2. Google Cloud関連のメトリクスの取得が不十分

みんなの銀行がメインで使用している、Google Cloud関連の標準で取得できるメトリクスが、New Relicだとまだまだこれからなところもあり、前監視システムと比較して少ないところです。

しかしNew Relic社が上記デメリットに対する対応を確約してくれたのもあり、致命的なデメリットもなくなったため、開発に踏み切ることとなったのです。

採用コンポーネントの決定

みんなの銀行が定めた機能要件に沿って、New Relicでの実現方法を選定しました。また、当初我々が期待していた基本的な監視機能について、New Relicで全て実現可能ということもわかりました。
<監視要件とNew Relicのコンポーネントとの対応表> 

New Relic導入チーム発足

以下テーマを掲げアーキテクチャ部門より、計6名からなるNew Relic導入チームが結成されました。

開発の完全内製化を図る
監視要件を再定義し、設計時のドキュメントやナレッジを充実させる

チームメンバーほとんどが30代前半で、今回のような監視基盤を１から更改するという業務経験があるメンバーはいない構成となりました。

ということでチームはCoreBankと呼ばれるBtoC基盤と、BaaSと呼ばれるBtoB基盤とで分かれて、開発が始まることとなったのです。

移行時の徹底ポイント

今回の移行に向けて以下ポイントを徹底して開発を進めました。

ユーザー管理
設定変更可能なユーザー数での課金となるため、ユーザー、ライセンス管理を担当ロールによって分割し管理
開発ドキュメントの充実
基本設計、詳細設計レベルで設計書を作成し、運用メンバーに展開
共通認識を深める
日々、課題や進捗状況を共有し合いコミュニケーションを密にすることで、メンバー間での共通認識を徹底

以上が導入検討編になりますが、次回『#2 開発編』は実際の開発時のお話をさせていただければと思います。

#2 開発編へ続く