【内製開発Summit 2025】内製化時代の品質向上を実現するオブザーバビリティとは？JPX総研×Splunkが語る実践ポイント
2025年2月27日、ファインディ株式会社が主催するイベント「内製開発Summit2025」が開催されました。本カンファレンスは、野村コンファレンスプラザ日本橋（東京）にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、Splunk Services Japan合同会社のシニアソリューションアーキテクトオブザーバービリティである大谷和紀さんと、株式会社JPX総研のITビジネス部 課長の若山幸市さんによるセッション「内製化時代の品質向上を実現するオブザーバビリティとは？JPX総研×Splunkが語る実践ポイント」の内容をお届けします。
以前はオンプレミス開発を基本としていたJPX総研。クラウド化が進むなかで、5年ほど前に Synthetic Monitoring （外形監視）をスタートしました。なぜ外形監視を始めようと思ったのか？ Synthetic Monitoring が役立ったケースとは？ 具体例を交えてお話いただきました。
■プロフィール
大谷 和紀（おおたに かずのり）/@katzchang
Splunk Services Japan合同会社
Senior Solutions Architect, Observability
Splunk Observabilityの導入支援の仕事をしています。それまでは業務システム業界でSEとして7年の経験を積んだ後、広告配信サービスを構築・運用をリーダー/CTOとして8年ほど経験しつつ、オブザーバビリティ製品のカスタマーサクセスも担当しつつ、スクラッチからのアプリケーション開発、DevOpsの推進、開発組織の改善などなどやってました。「オブザーバビリティ・エンジニアリング」共訳。趣味はバックカントリースキー。
若山 幸市（わかやま こういち）
株式会社JPX総研
ITビジネス部 課長
新卒で株式会社東京証券取引所に入社。2017年から現職にあたる株式会社東京証券取引所 IT開発部 情報システムに所属。現在は、2022年に設立された株式会社JPX総研において、情報系システムの開発及び維持保守案件におけるプロジェクトマネージャーを担当。取引所ではスタンダードであるオンプレミス環境のウォーターフォール開発から、SalesforceやAWS等を使ったスピード感を重視した開発等、多様なタイプの開発に対応してきた。
クラウド化を進めるタイミングで、Synthetic Monitoring をスタート
大谷：本日はよろしくお願いいたします。私はSplunkのシニアソリューションアーキテクトオブザーバービリティとして、オブザーバービリティ製品専門の導入の支援をしている大谷和紀と申します。Splunkは「デジタルレジリエンス」をキーワードとしながら、セキュリティとオブザーバビリティの統合プラットフォームを提供している会社です。本日はSplunk製品をご活用いただいているJPX総研様にお話をお伺いします。
本題に移る前に、若山さん、自己紹介をお願いいたします。
若山：JPX総研 ITビジネス部の若山幸市と申します。新卒で東京証券取引所に入社し、最初はニュース等でよく株価が回っている映像が映るマーケットセンターで株の監視や管理をしていました。そこから紆余曲折あり、2017年から現在の部署の前身となるIT開発部 情報システムに所属しています。
業務としては、グループの基幹系システムの周辺にある30程度のシステムの開発および維持保守業務を担当しています。具体的には、オンプレミス（以下、オンプレ）とクラウドが入り乱れているシステムの立ち上げと安定的な稼働に従事しています。JPX総研についても簡単にご紹介させてください。JPX総研は、日本取引所グループのデータ・デジタル事業を集約するため、2022年に設立された会社です。基幹系システムのほか、個人・法人向けのデータ配信サービスなども開発しています。
大谷：ありがとうございます。それでは早速本題に移りたいと思います。本日は下記4つのテーマでお話をお伺いしていきます。
大谷：なお、一つ目のテーマにある「 Synthetic Monitoring 」とは、外形監視とも呼ばれるもので、外部から人工的なリクエストを発生させて出力を見る手法です。JPX総研では、なぜ Synthetic Monitoring を始めることにしたのですか？
若山：はい。 Synthetic Monitoring を始めたのが5年ほど前で、私はまだ担当者ではなかったため、当時の担当者に話を聞いてきました。
前提として、5年ほど前の弊社は、基本的にオンプレで開発していました。ただ、クラウドで開発しているシステムも少しずつ稼働してきており、クラウドで構築したシステムで一部業務を行っていくという話が出るようになったタイミングでした。
オンプレで開発したシステムの場合、これまでのノウハウからCPUやメモリなどマシン単位で正確に管理して、何かあればアラートを上げる仕組みが既に構築されていました。しかし、クラウドで開発したものについては、そのオンプレで構築した仕組みに乗せることができないので、まずは可能なところだけ監視して稼働をしていくなかで出来る範囲を増やしていこうという進め方で稼働をさせていきました。
そのせいか、ユーザーの方からの「 何かいつもより動きが遅い」といった連絡で異常が発生していることに気付くこともあり、それで開発組織のなかで「 クラウドで構築したシステムでもユーザーに言われる前に内部で検知できる仕組みを作るべきでは？」という話がでて、 Synthetic Monitoring を始めることにしたそうです。
大谷：なるほど。クラウド化が進んでいるタイミングで Synthetic Monitoring が始まったということですね。社内の雰囲気として、クラウドとオンプレへの関心の高さにも差があるような感じだったのでしょうか？
若山：そうですね。特にクラウドを活用し始めたばかりの頃は運用部隊の体制が整っておらず、基本的にはメッセージはJP1で出さなければ監視ができない、などの制約がありました。
大谷： AWS だと CloudWatch 、Google Cloud であれば Cloud Monitoring を使用できますが、当時の社内体制では、そういったものを組み合わせるのが難しい状況だったのですね。
若山：ええ。ただ、そうなるとシステムの稼働がクラウドに対する運用体制が完璧に整備されないと稼働ができないということになってしまうため、運用でもアジャイル的に運用体制を構築していこう、という動きがあったのだろうと思います。
大谷：JPX総研は規模の大きな組織だと思いますし、体制が整う前にクラウドに挑戦することができていたというのは、すごいことだと思いました。
若山：思い切った取り組みではあったと思います。特に弊社の基幹系である取引を行うシステム等では、そういった取り組みはできなかったのではないかと。ただ、我々が担当しているのは周辺システムですし、そういったところから挑戦するなら良いだろう、という判断だったのではないでしょうか。
大谷：なるほど。ユーザーから「重い」「遅い」といった声が届くようになったのは、JP1や AWS CloudWatch では検知できなかったことが原因だったのでしょうか？
若山：そうですね。検知する機能がないというのもありますし、いろんなところに網を張っているものの、そこをすり抜けていってしまっている状態でした。外部の環境からアクセスすると確かにいつもよりページが開くのが遅いので、どこかに問題が発生していることはわかっているけれど、なぜか社内の環境からだと問題なく開ける。そういうパターンだとどうしても検知が遅れたりして。
大谷：エラーの再現待ちが発生していたと。 Synthetic Monitoring なら外部の挙動を確認する設定も簡単にできますし、再現待ちの時間は発生しませんよね。
若山：そうですね。中に何かを埋め込む必要もなく「このURLに◯秒単位でアクセスして、反応が返ってこなかったら、ここにアラートを上げてください」といった設定も簡単にできます。Synthetic Monitoring を始めたことで、非常にスムーズに運用体制を構築することができましたね。
外部向けシステムに絞り、オンプレとクラウドの両方で活用
大谷：続けて「どんなサービスに対してどのようにテストしていますか？」をテーマにお話を伺っても良いでしょうか。
若山：はい。社内向けのシステムもいくつかあるのですが、それらには必要ないだろうと考えていて。上場企業や証券会社、銀行にご利用いただいているシステムに網を仕掛けて、何かおかしな挙動があればアラートをあげる設定にしています。
大谷：社内向けの業務システムではなく、外部に提供しているサービスのみテストされているのですね。オンプレとクラウドのサービスが入り乱れているというお話もありましたが、全てにテストを仕掛けられているのですか？
若山：ええ。というのも、オンプレのシステムは厳重に監視できるとはいえ、監視の網をすり抜けてしまうケースもあるからです。また、クラウドであればCloudWatch などが使用できるのですが、SaaSで構築しているシステムだと用意されているサービス以外で検知する方法がないので、難しいところもありますよね。そこでSplunkさんの力を借りて、SaaSの外から異常なところがないか、見ていただくようにしています。
大谷：クラウドと聞くとAWSや Google Cloud、Azureを思い浮かべますが、SaaSサービスをベースに構築しているサービスもあるのですね。
若山：ええ。具体例を出すと、Salesforceなどをベースに構築しているものもあります。
大谷：そうなると、パフォーマンスが劣化することもある？
若山：そうですね。そういった時、SaaS側からお知らせが届く前に Synthetic Monitoring から連絡がくるため、あらかじめ体制を整えることができて非常に助かっています。
大谷：Splunkの Synthetic Monitoring にはいくつかの監視メニューがありますが、どのようにご活用いただいているのですか？
若山：私が担当している領域でいうと、URLにアクセスしてログイン画面がちゃんと出てくるか、何秒以内に出てくるか、という部分を見ていることが多いですね。
大谷：それを30のシステム全てで活用いただいているのでしょうか？
若山：いいえ。2桁いくかいかないか、ぐらいだったと思います。
大谷：なるほど。ありがとうございます。
Synthetic Monitoring によってSaaSサービスの障害をカバー
大谷：次に「実際に問題を検知した例はありますか？」に移りたいと思います。言い換えると、Splunk の Synthetic Monitoring が役に立ったことがあるか？という質問ですね。こちらはいかがでしょうか？
若山：何度も役に立ちました。直近のところで言うと、20時くらいにAWSで構築しているシステムからSaaSにデータを連携して請求書をユーザーに送付する、といった機能の部分で問題が発生したことがありました。
特にバッチ処理を注視する形で Synthetic Monitoring で定点的に監視するようにしていたら、ある日の18～19時くらいに Synthetic Monitoring から「何かがおかしい」とメッセージが来たんです。それまで見たことがなかったメッセージだったため、業務サイドと連携して、別の方法で請求書を送付できるように体制を整えていました。すると、Synthetic Monitoring からメッセージが来た約20分後に、SaaS側から障害が発生していると連絡が届いたのです。 Synthetic Monitoring を入れていたことで、早い段階で体制を整えることができたため、とても助かりました。
大谷：自分たちが公開しているサービスをテストしていたわけではなく、自分たちが依存するサービスをテストしていたという理解であっていますか？
若山：そうです。そちらの方のテストをしていました。
大谷：ありがとうございます。これもよく聞く話で、昨今は自分たちのサービスで閉じるというケースは珍しいですよね。そうなると、向こうのサービスでエラーが発生した際に、“どちらが悪いのか問題”が起こり得る。そう考えると、少しでも早く検知できるようにしておいた方が、よりスムーズに対応できますよね。
若山：そうですね。そういった観点もあるため、AWSで構築しているデータを送る方のシステムにも Splunkさんを仕掛けています。 AWS 全体が落ちて CloudWatch も使用できなくなると、AWS上に作ったシステムを監視することができなくなりますから。別の角度からもちゃんと監視しようということで、さまざまなところから網を仕掛けるスタイルを取り入れています。
大谷：ちなみに、先ほどお話いただいたエラーが発生した際、業務などに影響はあったのですか？
若山：データ連携がうまくできない場合に備えてプランBを用意していたこともあり、そこまで影響はありませんでしたね。
大谷：請求書作成が遅れると、ユーザー側に何か影響が出てしまうのでしょうか？
若山：そうですね。弊社の市場で取引していただいている買主／売主の方々に請求書を送付するというサービスですので、ユーザーは非常に困ってしまうと思います。
大谷：なるほど。お話いただいた事例では、Synthetic Monitoring を通してユーザーへの影響が出る前に検知できたため、影響はなかったということで。先ほどおっしゃられていた「ユーザーに言われる前に内部で検知できる仕組み」が実現できているというのがポイントですね。
今後はAPMも導入予定！可能な限り、手を広げていく
大谷：最後のテーマは「今後、APMで何をしようとしていますか?」です。JPX総研さんは、Splunk の Application Performance Monitoring（APM） を導入予定だと伺っています。APMはアプリケーション内部にエージェントを仕込んで、パフォーマンスを監視して問題を検出する手法であり、Synthetic Monitoring とは大きく異なるものでもあります。APMの導入を検討された背景には、方針の変化などがあったのでしょうか？
若山：そうですね。オンプレのシステムでは行っている運用の監視やキャパシティの管理など、可能な限りクラウドで構築したシステムにも積極的に手を広げていきたいと考えています。後者のキャパシティ管理についてはクラウドでどこまで考える必要があるのか、という議論もあるのですが、できるところは対応していきたいなと。
現状では、クラウドで構築したシステムのCPUの速度が徐々に落ちていて気がついたらシステムが落ちていた、というケースが起こり得るため、そういった部分に APM を入れて先々まで見越してパフォーマンスを管理できるようになれば良いなと。 ですがまだ導入前であることもあるので、まずはAPM を入れることで何が見えるようになるのか、どういった対策を立てられるようになるのか、検討していきたいなと考えているところです。
大谷：なるほど。先ほどオンプレはJP1を中心に監視運用体制を敷いてると伺いましたが、クラウドにデプロイしたアプリケーションではどのように運用されているのですか？
若山：システムによって異なるところではあるのですが、今弊社で推奨しているのはAWS環境です。そこで運用を担当している部隊と連携してクラウドで必要なものをきちんと監視できるようにする取り組みを推進していて、体制を整えているところですね。
大谷：AWSだと CloudWatch 中心になるかもしれないし。とはいえ、CloudWatch はアプリケーション内部の状態は確認できませんよね。
若山：ええ。 APM を入れることでその辺りも全部見えるようになるのであれば、AWSで仕組みを構築するよりも、Splunk さんにご相談した方が良いかもしれないね、という話が出てくる可能性もありますね。
大谷：ありがとうございます。最後に1点だけ、運用の体制を担当している部隊があるとのことでしたが、現在は運用の標準みたいなものを作ろうとされているのでしょうか？
若山：そうですね。運用の標準はもちろん既にあるのですが、 先ほど申し上げたように、 クラウドの部分については未成熟なところから始めて、どんどん成熟させようとしていますので、日々ブラッシュアップして、常に時代にあった良いものにしていく必要があるのだと思っています。
大谷：最終的な標準がどうなっていくかは、今後の様子を見ながら決まっていくということですね。
大きい会社は新しいことを始める際も標準ありきだという固定概念がありましたが、JPX総研さんは実践ベースで標準を作ろうとされているところが素晴らしいなと思いました。
若山さん、本日はお話をしていただきありがとうございました！
