はじめに
こんにちは。みんなの銀行 インフラチームの石井です。
あっという間に2025年も終わりが近づいてきました。
私自身、昨年よりは忙しくなかったと言いつつも、やはりハードに感じた一年でした。
中でも今年はみんなの銀行と提携先とのBaaS提携や、その準備がとても多い一年だったと思います。
1年ぶりの執筆になりますが、今回は現在のNew Relicを用いた監視運用における取り組みや課題、そしてBaaS提携先が増えていく中で、New Relicを活用した監視やスケールアウト設計等について、少しだけご紹介させてください。
監視運用における取り組み
New Relicを導入して早一年半が経過しました。
昨年の投稿で書かせていただいたNew Relicを活用したオブザーバビリティを実現すべく、日々模索しながらNew Relicの活用改善に日々取り組んできました。
昨年の記事 ▼
ようやくWAFやCDNなどのフロント側のデータや、APMデータを活用して日々のパフォーマンス監視を実施し、みんなの銀行の中でもユーザの期待するサービスに近づこうとするプロセスであるクリティカル・ユーザー・ジャーニー（CUJ）やサービスレベル（SLO/SLA）を策定して、監視データをビジネス指標に設定し、活用していこうという動きがでてきました。
昨年のNew Relic導入から、最近の監視運用においては以下のような取り組みが進んでいます。
- 主要な監視データをCPUやメモリなどのインフラデータから徐々にCDNやAPMのユーザ体験データにシフト
- アラートの影響有無を調査し、不要と判断したものは引き続き積極的に削減
- New Relicのサービスレベル機能を使用し、CUJやSLO/SLAのテスト導入を実施
New Relic導入後の監視における課題について
一方で以下のような課題と直面しており、日進月歩といかない部分もあります。
<金融サービスにおけるSLA策定の難しさ>
SLO/SLA策定を進める中で、信頼性を最重要とする金融サービスがサービスレベルを策定し、それを公開することには、特有の難しさがあると感じています。
その背景には、個人や企業への影響が大きい金融業界では障害に対する許容度は狭く、経営陣やエンドユーザーが、現実的なSLA（サービスレベル合意）を受け入れてくれるのか、という根本的な疑問が浮かび上がります。
いかなるシステムにおいても絶対はなく、ハードウェア障害やバグ、人的なミスや災害など障害も多岐に渡ると思いSLAを100%とすることは現実ではありません。しかし仮にSLAを99.9%とすると0.1%の障害を受け入れるという考えになってしまい、ユーザーの不利益だけでなく、会社の信用失墜にも繋がりかねないという不安があります。
ゆえに、私たちはこの根本的な課題に対し真摯に向き合う必要があると考えており、少しずつではありますが勉強会などを実施し、サービスレベルの重要性、考え方を社内に浸透させております。
<ビジネスチームと開発チームの相互認識の違い>
システム監視運用をしていく中で課題は、ビジネス側とシステム側の監視やSLOの指標やそのメリットなどの相互認識が違うということです。
この解決には何度もビジネスサイドと会話を重ね、すり合わせを行い考え方や方向性、閾値をアップデートし続けることでゴールに近づくのではないかと思い、現在取り組んでおります。
私はNew Relicを用いてビジネスサイドとシステムサイドのメンバー間の共通言語や指標を作りたいと考えております。
日々増えていくBaaS連携におけるNew Relic活用
さて、ここからが本題ですが、今年は様々な提携先とみんなの銀行とのBaaS連携を実施しました。
提携先が増えるという事は利用者が増えるという事であり、我々インフラチームに課された課題は、提携先の保有する大規模なユーザに耐えられるようインフラ基盤のリソースを増強すること、そのリソースを監視する仕組みの設計と構築が急務でした。
そこで、大規模ユーザのリクエストを受け入れるインフラ資源を構築、そして今までにない利用率を想定した高負荷テストを実施し、その結果をもとにスケールアウト設定を見直すことになりました。
インフラ構成と監視基盤の作成
みんなの銀行で提携先からのリクエストを受け入れるためのゲートウェイとなるBaaS(B2B)基盤と、そのリクエストを捌くコアの勘定系(B2C)基盤、そしてNew Relicを用いた監視基盤における全体構成イメージは以下のようなイメージになります。
<みんなの銀行インフラ資源とNew Relicでの監視構成>
今回はNew Relicが出すアラートなどを設定する監視資源においては標準化および効率化の観点に基づき、テンプレート化（Terraformコードでモジュール呼び出し構成）していることで新規の構築の際は横展開が容易なので、設計から構築までスムーズに対応できたと思います。
また、今回構築していく中で、既存のアラートの閾値改善やダッシュボード項目拡充等のアップデートを実施していくなど、より監視の精度を向上させていきました。
New Relicを活用したテスト
みんなの銀行では単体テスト、性能テスト、長期負荷テストなど様々なテストにおいてNew Relicを活用しております。
下図は長期負荷テストを実施した際のAPMを用いたマイクロサービスの負荷状況を示すレイテンシ（Duration）のグラフを表しております。
今回実行したテストではボトルネックになっている処理やAPIなどが見つかったり、思いがけない箇所で負荷の上昇傾向が見られたりと、多くの学びがあり処理改善のきっかけとなりました。
※画像では断続的かつ緩やかに上がり続けるAPI処理が見受けられ、アクセスが集中すると特定のDBのクエリ応答に時間を要していることが判明しました。
New Relic指標をベースにしたスケールアウト設計
ここからはリソース増強を意識した、性能テストについてお話しさせてください。
みんなの銀行はシステム基盤の根幹をGKEで構成しておりますが、Google Cloudマネージドでありながらも無制限にオートスケールできるわけではなく、想定以上の課金がされないように最大スケール数の設定などがあります。
GKEオートスケーラーには、クラスタのノード数とノードあたりのPod数の上限が設定できます。ノードプール毎のノード数上限は最大1,000台まで割り当て可能であり、そのノードあたりのPod数上限はフレキシブルPod CIDRの構成で最大256台まで設定可能です。
クラウドコスト上昇を防ぐため際限なくPodが増え続けたりしないよう、またデータベースなどのバックエンドの性能を考慮し、上限を設定する必要があります。
そして、みんなの銀行CIOの宮本からの 「システム起因で絶対にサービスを落とすな」 という指令をもとに余裕のあるスケール数を見積もることになります。
＜ 想定ユーザ数の試算と対象資源の洗い出し ＞
まず提携先のアクティブユーザを試算し、みんなの銀行への想定流入数を推測しました。その結果現在のみんなの銀行のユーザ数の10倍近いユーザ数での試験を実施することになりました。
次に増強が必要とされる全てのリソースを洗い出し、現状の設定パラメータを調査していきました。その上で増強が可能なリソースとその増強量を机上で試算しました。
＜ Podのスケール数 ＞
GKEにはPodのHorizontal Pod Autoscaler（HPA）において、Podの数の自動スケーリングを制御するパラメータが用意されています。
これは、自動スケーリングが効率的かつ安全に行われるためのガードレールのようなものであり、サービスの安定性、リソース効率、コスト管理において重要な役割を果たします。
minReplicas：Podのレプリカ数をこれ以下には減らさないという下限値
maxReplicas：Podのレプリカ数をこれ以上には増やさないという上限値
そして、先ほどの説明にある負荷を想定したリクエストを検証環境に流して、New RelicのダッシュボードにてGKEにおける各Podのスケール数を計測しました。
上図の通り、Podによってばらつきはあるものの、ほぼ全てのPodで、机上で試算したmaxReplicasの最大値までのスケールアウト（増加）が見られました。
負荷テストとそのテストに基づくスケール数の試算を繰り返していく中で、余裕を持たせる意味で大胆なスケール設定を実施することになり、設定をしていきました。
また、下限においては起動時間の遅延回避や、急激な高負荷へのバッファのために設定する必要があるため最低ラインの設定を入れていきました。
＜ Nodeのスケール数 ＞
上記のGKEのPod数増加に伴い、Nodeのスケールアウト設定も見直す必要があります。
性能テストのHPAのトリガーとなっているCPUの上昇率から、余裕を持ったスケール数を割り出し、ゾーン単位でパラメータを設定していきました。
これまでNew Relicを活用してGKE資源のスケールアウト設計の見直しについて述べていきましたが、それ以外でもAkamaiのCDN流量制御や、AuthleteなどのIDaaSの処理性能の増強など、New Relicで計測できるさまざまなインフラ資源の増強を図りました。
苦労した点や工夫に関して
今回のスケーリング設計で苦労した点ですが、リクエスト要件やネットワーク経路でトラフィック量が変わっていき、正確な値が見積もれない状態で、テストを行いスケール設定を設定していくといった点です。トラフィックの的確な試算を行った上でテストを実施し、その検証結果に基づいて適切なスケール数の試算を繰り返すことで、精度を向上させていきました。
下記イメージのように試算したスケール設定の値を、New Relicダッシュボードにある『Thresholds』に閾値を設定することで、現状のスケール数とその上限数を視覚的に表示し、トラフィック急増時の急なスケールも運用メンバーが、即座に把握できるようなダッシュボードを新たに作成しました。
トラフィック急増時の監視
ダッシュボード監視
キャンペーンや口座連携開始時のラッシュにおいて、急激なトラフィック上昇などを懸念しており、スケーリング設定と合わせて、New Relicのダッシュボード監視で、より詳細な負荷状況などを把握できるように構築を実施しました。
下記イメージは今回新規で作成したダッシュボードですが、アクセス状況やリソース負荷状況などを詳細に把握すべく、Loggingのリクエストデータから口座連携、ATM振替、口座参照などの処理数を取得、そしてそれに連動するようにAPMでMSのトランザクション数やレイテンシ等のパフォーマンスを計測することで、多角的かつ立体的にリソースを監視できるようにしました。
監視体制の構築と受け入れ準備
直近の大型提携では、New Relicでのアラート発報後の障害調査手順、エスカレーションフロー、リカバリ手順や、日々の運用監視における詳細なドキュメントを作成して、仮にその領域の担当者以外が対応をした場合でも、同じ水準の対応ができるように準備しております。また、定点観測として1時間単位でのリソース状況をNew Relicのダッシュボードから取得し、運用報告を実施するようにしました。
システムの運用担当者として当たり前の話ですが、これからもサービスの安定稼動を最優先にして、システムの運用の精度向上と、それらを監視するデータの整合性にこだわり、エンドユーザへのより良いサービスを提供できるよう努めていきたいと思います。
まとめ
まとめになりますが、増え続けるリクエスト量に合わせて、様々なテストでNew Relicを活用し、GKEのみならずあらゆるインフラ資源の増強を図ることで、万全の体制でリクエストを受け付けていこうと思っております。
今後も提携先とのBaaS連携も増えてくると予想しており、よりNew Relicを活用したインフラの監視運用やテストが重要になってくると思っております。
直近では株式会社メルペイ様とのBaaS連携を開始しました。
プレスリリース ▼
今回の記事では、みんなの銀行のNew Relic監視とインフラのスケーリング設計について述べてきましたが、今後も継続してNew Relicにおける監視運用の改善を繰り返し、インフラ予測の指標やスケーリングにおけるノウハウが充実していくことで、来年はもう少し余裕のある一年になるのではないでしょうか。
以上、ご清覧いただきありがとうございます。