New Relic Game Dayに参加してきました

こんにちは。ゼロバンク・デザインファクトリー（以下、ZDF）の鈴木良です。
普段は主にみんなの銀行の新サービス開発や法対応案件でのインフラレイヤーの担当をしています。

先日参加したNew Relic社のGame Dayの体験談や得た気づきについて書かせていただきます。
※代表して鈴木良の記事として記載していますが、執筆内容は下記参加メンバーでの共著となっています。
参加メンバー：櫻井拓海、鈴木佑一、張逸しん、山口拓郎、鈴木良


# みんなの銀行システムとNew Relic
はじめに、みんなの銀行とNew Relicについて簡単に触れます。

みんなの銀行システムの開発・運用をになうZDFでは、マルチクラウド環境の統合システム監視サービスとしてNew Relicの導入を進めています。

導入の背景としては、2021年5月のみんなの銀行サービス開始から2年半が経過し、その間も積極的な機能改善や新規サービス追加、利用者獲得のための施策をビジネスサイドと共同しながら日々進めており、お陰さまでお客さまも増え、システム規模も継続して拡張されてきました。

そういった中で、ある課題に対応するため、New Relicに移行することにしました。

（課題が何なのか等は、本記事の主題ではないため、あえて伏せさせて頂きますｗ
金融システムでありながらたった2年ほどでメインの監視システムをリプレースする決断をするのも”みんなの銀行らしさ”というか、他の金融機関ではなかなか踏み切れない決断ではないかと思います）


New Relic導入は、主要トピックの一つとして、システムを構成するメインサービスの一つの初リプレースというチャレンジングな取り組みとして注力している案件となっています。
（New Relic導入、現行マイグレーションのトピックについては担当メンバーが今後記事を投稿してくれる事を期待します！）




# Game Day

2023年9月13日(水)にNew Relic社のコーポレートカンファレンス「FUTURE STACK 2023」が東京汐留で開催され、その中のプログラムである「Game Day」に当社メンバーで参加してきました。

恥ずかしながら、はじめチームメンバーから「Game Dayに参加しません？」と誘われた時は一瞬「みんなでマリオカートでもするんか？」と想像しましたがそうではなく、Game Dayとは現実世界で起こり得るシステムトラブルをシミュレートし、チームで協議・対処を進めることによりシステム環境の理解やトラブルシューティング力の強化を図る実践型トレーニングを指します。

New Relic社としてのGame Dayの考えはこちらが参考になりますね。

https://newrelic.com/jp/blog/best-practices/how-to-run-a-game-day

記事冒頭の「"火について学ぶ"、その最高のタイミングはまさに"火がついている"ときです。」は多くのエンジニアが身をもって（時には自分自身も灰になりかけながら）体験された事が簡潔に表現されています。

今回我々が参加したGame Dayプログラムは、我々を含めて15チーム、休憩を挟みながら実働5時間ほどでチーム間で得点を競い合うWorkshop形式で進行されました。
優勝チームには商品として、イベント特性New Relicロゴ入りのHappy Hacking Keyboard（HHKB）ということで、これまたエンジニア心をくすぐるチョイスです。




Game Dayのストーリーの詳細はネタバレとなりますので割愛しますが大まかに言うと下記の通りです。

- 参加者は、これからとあるWEBサービスの運営を開始しようとしている企業のエンジニアという設定。
- プログラムは前半/後半で大きく分かれている。

    前半
    - 自社システムに関して質問に出された情報（ログやメトリクス等）がNew Relicのどの機能で確認できるかの検索と実装。一問一答形式で得点が加算される。
    - また、WEBサービス開始の事前準備として、サービス開始後の安定運用に役立ちそうなダッシュボードを作成する。

    後半
    - サービスイン後の状況において発生するトラブルの原因をNew Relicを利用して特定し、実際に修正したアプリをビルドしてサービス改善を図る。獲得したビジネスの収益（＝得点）で競い合う。


前半の部では、New Relicに触れながら、「こんなこともできるんだ、思ったより簡単だな」と一利用者としてNew Relicに感心しながらお題の解決に取り組みました。
途中経過での順位発表では我々のチームが1位となる場面もあり、「もしかして、HHKBいけるんじゃない？」と若干の余裕をかますシーンもありました。（今思えば、この時の慢心で勝敗が決まっていたのかもしれません…）

後半の部では、次々にNew Relicから挙がってくるアラートに対し、何が優先的に対処すべき事象なのか、ログやアプリケーションソースを確認し、チームで仮説を立て協議しながら解決策を打っていきました。
前半の部では曖昧だった役割分担も、次第にチームメンバーが主体的に調査対象を分担できるようになり対策についても多角的な観点から議論できるようになっていきました。

最終的には、チーム成績は7位となり、惜しいとは言えない結果に終わりましたが、参加メンバーそれぞれ充実感を得たイベントとなりました。





# 振り返り
Game Dayに参加し、得られた気づきについて5点記載します。

### ①オブザーバビリティの必要性
New Relic社でも重要性を唱えているオブザーバビリティ（可観測性）の重要性について実体験を通じて感じることができました。
リアルタイムに刻一刻と変化するシステム内部の状況にて異常が起きた際に、エラーメッセージのような表面的な事象だけを捉えるに留まらず、「それがなぜ起きているのか」「どのような対策が必要なのか」を瞬時に捉えることは障害発生時に不可欠である一方、特にみんなの銀行システムのようなクラウドネイティブな分散型システムにおいてはそれを素早く正確に特定することは重要なものとなっています。

システムの稼働率の改善、もう少し具体化するとMTTR（平均復旧時間）・MTBF（平均故障間隔）を低減するためにどのような情報を収集・分析し、アラート設定し、どのようにトラブルシュートすれば良いかを改める考える良い機会となりました。

また、ビジネスの現場や業務要件へしっかりと向き合いSLA・SLOなどを整備しながら、実際のNew Relic導入にしっかりと生かしていき、オブザーバビリティを高めた監視・運用ライフを過ごしていきたいと感じました。







### ②ビジネス戦術の指針としてのシステム監視
上記のオブザーバビリティの強化とも繋がる話ですが、システム監視サービスをビジネス戦術を練るための指標として活用することは新鮮でした。

従来のシステム運用では定常的にシステム運行状況の監視を行うのは運用保守に関わるエンジニア、とりわけインフラエンジニアの事が多く、またそれらの人はビジネスから一番遠い視点になりがちです。

しかし今回のイベントでは「眼前のエラーに対処しつつ、且つビジネス価値を最大化する」というお題であったため、ただエラーを確認するだけでなくシステム内部の状況がどうビジネスに影響しているのか（当社でいえば、口座開設や資金の移動などへの影響でしょうか）をデータから拾い出し、復旧の優先度を決めていくという、ビジネス主眼での分析に取り組みました。

我々のようなインフラエンジニアも、監視にて収集する情報や分析の仕方によってビジネスに関する指針も示す事ができるという気づきは、エンジニアとして新たなモチベーションにも繋がる要素ではと感じました。



### ③トラブル対応力の重要性
当たり前の事ですが、改めて、トラブルが発生した際の状況把握から対処まで完遂するスキルとスピード感の重要性を痛感しました。

Game Dayではないですが、弊社でも定期的に障害訓練と呼ぶものは実施しています。
私自身も参加した際は大変学びが多いものの、一方で下記のような課題を感じています。

- 実施にあたり環境確保（他案件との利用調整）が難しい
- 障害想定シナリオが断定的
- 障害に対する対処パターンが柔軟でない（予め用意された定形的な対処しかできない）
- 対処手順が実施した事がある人しか分からない（本番での大規模障害時に突然実施しろと言われてもハードルが高い）

Game Dayのように実践的ながらもカジュアルにテスト環境に不具合や変更を加えれられる仕組みが必要であることを改めて実感しました。
柔軟かつオンデマンドなテスト環境構築ができる仕組み作り、同様に疑似的なトラブルを簡易に発生できる仕組みの構築が今後の課題です。それらが可能になれば次はカオスエンジニアリングに取り組む等、より高い耐障害性の確保に繋げていけると思います。


### ④チーム結束力の強化
たまたまですが、弊社から参加したメンバーは組織的には同じグループ所属であるものの、普段の業務ではなかなか仕事を一緒にする機会がないメンバーの集まりでした。
Game Dayを通じてあれこれ議論しながら一緒に課題に取り組むことでチームとしての結束力の強化に繋がる良い機会となりました。

実際に本番障害がいつ発生するかは当然予測できず、その日障害対応にアサインされているメンバーがトラブルシューティングのスキルや経験を備えられているかというと、現状は必ずしもそうではありません。

対応するメンバーがどのようなメンツであれ、その中で適切に役割分担しながら共同してトラブル対応に挑むことができるチームであることは、それだけ強いチームになり、対応するメンバーの精神的負担の緩和(心強さ)にも繋がります。そしてそれはシステム稼働率の改善にも直結する要素だと思います。


### ⑤Game形式の訓練の効率性
「習うより慣れろ」とはよく言いますが、目的も無く一人でとりあえず触ってみて身につくもので無いことは多くのエンジニアは経験済みかと思います。
Game Dayのチーム間で得点を競わせるという形式はエンジニアに限らずとも参加者の意欲を奮い立たせ、積極的な取り組みに繋がるで結果としてスキル定着にも寄与する良い要素だと思いました。
前述の通り、今回参加した我々のチームメンバーはほぼNew Relic未経験者でしたが、大まかにどの機能で何ができるかの概要は掴むに至ったのではと思います。
未経験者だからと言って臆することなく、むしろ未経験者だからこそ参加する意義があるイベントではないかと思います。
（おそらくNewRelic未経験の大抵の人は”自分のあまりのできの悪さ”に直面することになると思います。それはそれで今後取り組むべき課題の炙り出しとしてはよいかと）



# まとめ
楽しみながら競い合う事で学びも気づきも多い良いイベントでした。
得た知見は日々の監視運用や障害対策の取り組みとして活用していきたいと思います。

また、今回チーム対抗戦という点では残念ながら結果は振るいませんでしたが、次回開催時にはリベンジを果たして豪華賞品を持ち帰りたいと思います。