ElasticON FY26 決済サービスを支えるElastic Cloud

決済サービスを支える Elastic Cloud SBペイメントサービス システム運用統制部 鈴木順也 @suzukij , 今井健太 @shiba_dog 2026年03月10日

今井 健太 @shiba_dog SB Payment Service システム本部 運用統制部 Elasticsearch ＋ Kibanaで可視化利用を7年間 JavaプログラマでWebシステムの開発・運用歴が長い 現在の主な業務 ● 新規サービス開発・運用 ● 運用の改善

会社紹介 – SBペイメントサービス ソフトバンクグループの 決済分野 における中核事業会社 決済・金融 通信 インターネット SoftBank Group 海外投資 コンテンツ その他

SBペイメントサービスの事業内容 決済代行からカード事業まで幅広く展開 決済代行 キャリア決済 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算請 求「ソフトバンクまとめて支払い」の 開発・運営をしています。 EC/ネット店舗 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟店 契約会社）としての加盟店審査や管理事業、 端末決済サービスを提供しています。 実店舗/訪問販売 カード発行業務 ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、Visa加盟店で 利用できるプリペイドカードです。ご 利用金額に応じてTポイントが貯ま ります。

SBペイメントサービスの事業内容 決済代行からカード事業まで幅広く展開 決済代行 キャリア決済 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算請 求「ソフトバンクまとめて支払い」の 開発・運営をしています。 EC/ネット店舗 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟店 契約会社）としての加盟店審査や管理事業、 端末決済サービスを提供しています。 実店舗/訪問販売 カード発行業務 ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、Visa加盟店で 利用できるプリペイドカードです。ご 利用金額に応じてTポイントが貯ま ります。

システム概要 オンライン決済サービス 加盟店 通販サイト ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 当社 決済サービス 全て一本化 決済機関 クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

システム概要 オンライン決済サービス 加盟店 通販サイト 多彩な決済手段を一括で導入可能 ECサイト向けに様々な決済手段を提供 加盟店に決済画面や決済APIを提供するシステム 加盟店の手続きコスト、開発コストを削減 当社 決済サービス 全て一本化 決済機関 クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

システム概要 オンライン決済サービス 加盟店 通販サイト ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 導入実績当社 21.6 万店 決済サービス (2021年 実績) 全て一本化 決済機関 クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

システム概要 オンライン決済サービス 加盟店 通販サイト ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 決済手段 当社種類に対応 39 決済サービス （2021年 実績） 全て一本化 決済機関 クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

システム概要 オンライン決済サービス 加盟店 通販サイト ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 当社 決済サービス 全て一本化 9.8 決済取扱高 兆円 決済機関 (2024年実績) クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

システム概要 オンライン決済サービス 加盟店 通販サイト 加盟店と決済機関の間に位置する ECサイト向けに様々な決済手段を提供 自社だけでは完結しない Webシステム 加盟店に決済APIを提供するシステム 当社 決済サービス 全て一本化 決済機関 クレジット ゲーム 携帯キャリア決済 電子書籍/動画 コンビニ支払い 画面リンク型 チケット プリペイドカード 教育 口座振替 不動産 その他 API型 ポイント支払い アカウント連携決済

今日お話すること 今井 健太 鈴木 順也 SBペイメントサービス システム運用統制部 プロジェクト推進課 SBペイメントサービス システム運用統制部 前半パート Elastic Cloudの導入と移行推進 後半パート 決済サービスの Observability SBペイメントサービスで進めている、ログ基盤の Elastic Cloudへの段階的な移行についてご紹介しま す。移行の背景や進め方、プロジェクトの中で直面した 課題とその対応についてお話しします。 前半でご紹介するログ基盤の上で、どのように監視や 可視化を行っているのかをご紹介します。Elastic AgentやAPMを活用したダッシュボードを例に、決済 サービスにおけるオブザーバビリティの実践をお伝え します。

Elastic Cloud導入/移行

アジェンダ 01 ログ基盤の再設計 02 Elastic Cloudの採用 03 データの保持期限 04 中央管理の採用

ElasticCloud 移行を通じた ログ基盤の再設計

顕在化した課題 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった データ増加 増え続けるシステム ログ種増加

顕在化した課題 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった データ増加 増え続けるシステム ログ種増加 取り込み遅延 保持期間の圧迫 性能限界の兆候 ログ大容量化の影響 コスト増加

顕在化した課題 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった データ増加 増え続けるシステム ログ種増加 取り込み遅延 保持期間の圧迫 性能限界の兆候 ログ大容量化の影響 コスト増加 → この構造は、今後も成立続けるのか？

再設計の判断 拡張か、再設計か検討した結果、再設計と判断した 拡張 再設計 オンプレミス増強 構造そのものを見直す 部分的な性能改善 将来増加を前提にする 既存構造の延長 運用体制と整合させる → 一時的な改善 → 持続可能な構造へ

再設計の判断 拡張か、再設計か検討した結果、再設計と判断した 拡張 再設計 オンプレミス増強 構造そのものを見直す 部分的な性能改善 将来増加を前提にする 既存構造の延長 運用体制と整合させる → 一時的な改善 → 持続可能な構造へ

再設計の判断 拡張か、再設計か検討した結果、再設計と判断した 拡張 再設計 オンプレミス増強 構造そのものを見直す 部分的な性能改善 将来増加を前提にする 既存構造の延長 運用体制と整合させる → 一時的な改善 → 持続可能な構造へ

Elastic Cloudの採用

これまでのログ基盤構成 ログ基盤・メトリクス基盤は別プロダクトで、可視化基盤として Elasticを運用 ログ基盤 メトリクス基盤 可視化基盤 別プロダクトを利用 別システムで収集 オンプレ ElasticStack

これまでのログ基盤構成 ログ基盤・メトリクス基盤は別プロダクトで、可視化基盤として Elasticを運用 ターゲット！ こっちを採用 ログ基盤 メトリクス基盤 可視化基盤 別プロダクトを利用 別システムで収集 オンプレ ElasticStack

これまでのログ基盤構成 ログ基盤・メトリクス基盤は別プロダクトで、可視化基盤として Elasticを運用 取り込み遅延！ こっちを採用 ログ基盤 メトリクス基盤 可視化基盤 別プロダクトを利用 別システムで収集 オンプレ ElasticStack - データ増加 - 保持圧迫 - 容量限界 保持期間圧 こっちを採用 迫！ - 構成肥大化

これまでのログ基盤構成 連携効果が高い Elasticを運用 ログ基盤・メトリクス基盤は別プロダクトで、可視化基盤として こっちを採用 → 統合 ログ基盤 メトリクス基盤 可視化基盤 別プロダクトを利用 別システムで収集 オンプレ ElasticStack - データ増加 - 保持圧迫 - 容量限界 - 構成肥大化 役割が異なるため別 こっちを採用 運用

私たちが必要としたもの 制約を踏まえて持続可能な基盤を構築することを目的とした 運用的制約 戦略的制約 技術的制約 ・少人数運用 ・柔軟な拡張性 ・維持可能な構成

私たちが必要としたもの 制約を踏まえて持続可能な基盤を構築することを目的とした 運用的制約 戦略的制約 技術的制約 ・少人数運用 ・柔軟な拡張性 ・維持可能な構成 既存の構成では満たせない

私たちが必要としたもの 制約を踏まえて持続可能な基盤を構築することを目的とした 運用的制約 戦略的制約 技術的制約 ・少人数運用 ・柔軟な拡張性 ・維持可能な構成 既存の構成では満たせない ログ基盤 Elastic Cloud

私たちが必要としたもの コンソールからの拡張や、バージョンアップが容易に行えた Cloudサービスなので、 こっちを採用 サーバの増減はリアルタイム

私たちが必要としたもの コンソールからの拡張や、バージョンアップが容易に行えた バージョンアップは こっちを採用 コンソールからワンタッチ

データの保持期限

保持期間と必要性 ログの用途を整理し、 アクセス頻度 × 保持期間 で分類した - データ量小 - アラート監視 - 調査用途 保持期間 頻繁×短い 稀×短い - 特になし アクセス頻度 頻繁×長い 稀×長い - データ量少 - メトリクス - 傾向分析 - データ容量大 - 障害調査 - 傾向分析

保持期間と必要性 ログの用途を整理し、アクセス頻度 × 保持期間で分類した - データ量小 - アラート監視 - 調査用途 保持期間 頻繁×短い 稀×短い - 特になし アクセス頻度 頻繁×長い - データ量少 - メトリクス - 傾向分析 稀×長い 過去データはあまり重用ではない こっちを採用 リアルタイム性が重要 - データ容量大 - 障害調査 - 傾向分析

保持期間と必要性 ログの用途を整理し、アクセス頻度 × 保持期間で分類した - アラート監視 - 調査用途 保持期間 頻繁×短い 応答速度は気にしない こっちを採用 抽出自体ができることが重要 - データ量小 稀×短い - 特になし アクセス頻度 頻繁×長い 稀×長い - データ量少 - メトリクス - 傾向分析 - データ容量大 - 障害調査 - 傾向分析

Data Tier の利用検討 通常は HOT → WARM → COLD → FROZEN と段階的に移行 r e nt is pr e E HOT WARM COLD FROZEN

Data Tier の利用検討 両極端な構成にする設計判断 r e nt is pr e E HOT WARM COLD FROZEN 小 大 速 遅

Data Tier の利用検討 両極端な構成にする設計判断 r e nt is pr e E HOT WARM COLD FROZEN 小 大 速 遅

Data Tier の利用検討 FROZENはノードにデータを持たないため、実質どこまでも保持が可能 r e nt is pr e E HOT WARM COLD FROZEN フルデータを ローカル保持 ローカル保持 ノードに データ保持 保持なし SSD・高速I/O HDD中心 検索可能 スナップショット 検索可能 スナップショット

Data Tier の利用検討 FROZENはノードにデータを持たないため、実質どこまでも保持が可能 r e nt is pr e E HOT WARM COLD FROZEN フルデータを ローカル保持 ローカル保持 ノードに データ保持 保持なし SSD・高速I/O HDD中心 検索可能 スナップショット 検索可能 スナップショット 過去データの調査や 長期間の傾向分析が こっちを採用 低コストで可能 になった

Data Tier の利用検討 Index Managementで見ると、 Storageが0になっている

中央管理の採用

中央管理 運用体制の拡張制約に対して 管理方式を検討 Beats 設定個別管理 こっちを採用 Fleet Elastic Agent

中央管理 運用体制の拡張制約に対して 管理方式を検討 Beats 一元管理 こっちを採用 Fleet Elastic Agent

中央管理 運用体制の拡張制約に対して 管理方式を検討 Beats https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 Fleet Elastic Agent

• https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1

中央管理 運用体制の拡張制約に対して 管理方式を検討 Beats https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 Fleet Elastic Agent

• https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1

中央管理 運用体制の拡張制約に対して 管理方式を検討 Beats https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 こっちを採用 こっちを採用 Fleet Elastic Agent

• https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1

データの収集設定 当初は、 namespaceやdatasetでデータの分類を行っていた アプリA Logs アプリB Logs namespace logs-sys01-gp01-app-* SYS01  GP01 logs-sys01-gp01-access-* SYS01  GP02 logs-sys01-gp01-error-* logs-sys01-gp02-app-* dataset app ミドルA Logs ミドルB Logs access logs-sys01-gp02-access-* logs-sys01-gp02-error-* : :

データの収集設定 当初は、 namespaceやdatasetでデータの分類を行っていた アプリA Logs namespace logs-sys01-gp01-app-* SYS01  GP01 logs-sys01-gp01-access-* SYS01  GP02 logs-sys01-gp01-error-* Inde x数増 性能 ！ 劣化 ！！ アプリB Logs dataset app ミドルA Logs ミドルB Logs access logs-sys01-gp02-app-* logs-sys01-gp02-access-* logs-sys01-gp02-error-* : :

データの収集設定 フィールドで管理する方針に変更 namespace SYS01 SYS02 アプリA Logs アプリB Logs logs-sys01-access-* dataset app access ミドルA Logs ミドルB Logs logs-sys01-app-* metadata 役割 グループ logs-sys01-error-* : :

Agent Policiesにて設定 各システム側で設計は不要 こっちを採用 基盤側で制御が可能

ダッシュボード例 ステージングや商用などの環境 役割 その他グルーピング

ダッシュボード例 ステージングや商用などの環境 横串可視化 同じ観点での 絞り込み実現 役割 その他グルーピング

ダッシュボード例 ステージングや商用などの環境 横串可視化 同じ観点での 絞り込み実現 役割 改善スピード 中央管理ならでは の一括管理 その他グルーピング

ダッシュボード例 ステージングや商用などの環境 横串可視化 同じ観点での 絞り込み実現 役割 改善スピード 中央管理ならでは の一括管理 その他グルーピング 運用効率 少人数運用

決済サービスの Observability

鈴木 順也 @suzukij SB Payment Service システム本部 運用統制部 決済基盤の新規開発や信頼性向上に従事。 技術選定からアーキテクチャ設計、開発 / 運用プロセスの整備 まで幅広く担当。 ElasticON Tokyo 2017 登壇。

アジェンダ 01 決済サービスの監視状況 02 モダナイゼーション 03 ダッシュボード活用事例 04 今後に向けた生成AI活用 05 まとめ

決済サービスの監視状況と課題

今までの監視状況 ① Logstash jdbc-input-pluginで1分間隔で SQLを実行して決済業務メトリクスを取得、 Elasticsearchに投入 決済システム App App App App App App App App Apps Elasticsearch SQL実行 決済データベース Database Logstash Kibana

サービス監視ダッシュボード サービス監視するため各決済手段毎のグラフを表示して、ひとめで状況を把握できるように

サービス監視ダッシュボード（障害時の状況） サービス監視するため各決済手段毎のグラフを表示して、ひとめで状況を把握できるように クレジットカード系 A クレジットカード系 B クレジットカード系 C 携帯電話キャリア決済 A 携帯電話キャリア決済 B 携帯電話キャリア決済 C スマートフォン決済 A スマートフォン決済 B コンビニ決済 A その他決済 A その他決済 B コンビニ決済 B

サービス監視ダッシュボード（障害時の状況） 赤く表示されているグラフが障害によって影響が発生した決済手段 クレジットカード系 A クレジットカード系 B クレジットカード系 C 携帯電話キャリア決済 A 携帯電話キャリア決済 B 携帯電話キャリア決済 C スマートフォン決済 A スマートフォン決済 B コンビニ決済 A その他決済 A その他決済 B コンビニ決済 B

今までの監視状況 ② ログ、メトリクス、トレースの監視範囲を拡大し、システム全体の可視化レベルは高まった 決済システム App App App App App App Apps 決済トランザクション App Logstash Elasticsearch Kibana 他ツールA 他ツールB 他ツールC 他ツールD アプリログ サーバリソース CPU / メモリ アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC トレース App App

今までの監視状況 ② ログ、メトリクス、トレースの監視範囲を拡大し、システム全体の可視化レベルは高まった 監視ツールが分散 / 乱立している、アプリケーションログの活用できていない 決済システム App App App App App App Apps 決済トランザクション App Logstash Elasticsearch Kibana 他ツールA 他ツールB 他ツールC 他ツールD アプリログ サーバリソース CPU / メモリ アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC トレース App App

現状の課題 監視ツールやサービスが分散・乱立 Tool A Tool B Tool C ？ ツール間の行き来が煩雑 属人化と調査品質のムラ 複数のツールを横断する運用となり、運用者 各ツールの知識や利用経験が担当者に依 がスムーズに調査できない 存していることから、活用状況が属人化し、 調査品質にムラが生じている

現状の課題 アプリケーションログの活用ができていない ? ログ内容が乏しい メトリクス取得が困難 傾向把握ができていない アプリがレガシーでログの内 ログ内容が人間が読む前提 普段の傾向が把握できておら 容が乏しく、運用に活かせて となっているため、業務内容 ず、サービスの課題発見や改 いない のメトリクスを取得しづらい 善につなげられていなかった

モダナイゼーションによって 再構築した Observability

今回の話の対象システム 決済機関のゲートウェイを担うレガシーなシステム モダナイゼーションプロジェクトを契機に監視基盤の刷新 SBPS決済システム 購入要求 加盟店 加盟店 加盟店 （ショッピングサイト） （ショッピングサイト） （ショッピングサイト） 購入結果 フロントエンド アプリケーション バックエンド アプリケーション （レガシー） 決済機関 決済機関 決済機関

今回の話の対象システム 決済機関のゲートウェイを担うレガシーなシステム モダナイゼーションプロジェクトを契機に監視基盤の刷新 SBPS決済システム 購入要求 加盟店 加盟店 加盟店 （ショッピングサイト） （ショッピングサイト） （ショッピングサイト） 購入結果 フロントエンド アプリケーション アプリを Spring Bootで刷新、 Elastic Agent、APM Java Agentを 導入して監視を強化 バックエンド アプリケーション APM Java Agent Elastic Agent 決済機関 決済機関 決済機関

Observability構成 - APM Agent アプリに Elastic APM Agentを導入し、トレース、メトリクスを取得 APMサーバを経由して Elasticsearchに保存 決済バックエンド アプリケーション APM Java Agent App APM Elastic Agent Logs メトリクス トレース Elasticsearch Kibana

Observability構成 - Elastic Agent アプリケーションログを JSONで構造化された状態でログ出力し、 Elastic Agentによって構造化された状態のまま Elasticsearchに投入 決済バックエンド アプリケーション APM Java Agent App APM ログ（JSON 構造化ログ） Elastic Agent Logs Elasticsearch Kibana

ダッシュボード活用事例 ● 全体俯瞰のためのダッシュボード ● トレースによる詳細分析 ● 活用事例の紹介

APM Agentによるアプリケーション監視 Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 監視対象 ① リクエスト ② SQL実行 Database ③ HTTPS通信 ① レスポンス 外部システム 決済アプリケーション ①②③を含むトレースを送信 APM Java Agent APM Elasticsearch Kibana

APM Agentによるアプリケーション監視 Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 監視対象 ① リクエスト ② SQL実行 Database ③ HTTPS通信 ① レスポンス 外部システム 決済アプリケーション どのAPIが、いつ・どれだけ 呼び出され、 応答にどれくらい時間がかかったのかが把握できる ①②③を含むトレースを送信 APM Java Agent APM Elasticsearch Kibana

APM Agent API監視ダッシュボード アプリケーションの APIの処理状況を可視化

APM Agent API監視ダッシュボード アプリケーションの APIの処理状況を可視化 ステータスコード別 件数 API別 件数 レイテンシ （パーセンタイル、中央値、平均値）

APM Agent API監視ダッシュボード アプリケーションの APIの処理状況を可視化 加盟店別 件数 業務結果コード 別 件数 業務結果コード 別 件数

APM Agent API監視ダッシュボード アプリケーションの APIの処理状況を可視化 API結果のログ

APM Agentによるアプリケーション監視（SQL） Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 監視対象 ① リクエスト ② SQL実行 Database ③ HTTPS通信 ① レスポンス 外部システム 決済アプリケーション どのSQLが、いつ・どれだけ 呼び出され、 応答にどれくらい時間がかかったのかが把握できる ①②③を含むトレースを送信 APM Java Agent APM Elasticsearch Kibana

APM Agent SQL監視ダッシュボード APMが収集してくれたトレース情報を利用して SQLの実行状況を可視化 結果別 件数 SQLトレース情報 応答時間（パーセンタイル） クエリ別 応答時間（積み上げ）

APM Agentによるアプリケーション監視（外部通信） Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 監視対象 ① リクエスト ② SQL実行 Database ③ HTTPS通信 ① レスポンス 外部システム 決済アプリケーション どの通信処理が、いつ・どれだけ 呼び出され、 応答にどれくらい時間がかかったのかが把握できる ①②③を含むトレースを送信 APM Java Agent APM Elasticsearch Kibana

APM Agent 外部通信監視ダッシュボード APMが収集してくれたトレース情報を利用して HTTP通信の実行状況を可視化 ステータスコード別 件数 結果別 件数 送信先エンドポイント別 件数 応答時間（パーセンタイル） 接続先別 応答時間 接続エラー /レスポンスタイムアウト件数 HTTP通信トレース情報

Elastic Agent アプリケーションログ監視ダッシュボード アプリケーションは JSONの構造化されたログを出力 しているので、そのまま Elasticsearchへ投入 ログレベルや発生した例外クラス、加盟店が構造化されているため可視化して傾向を把握可能 環境別 件数 ホスト別 件数 サービス 別 件数 ログレベル 別 件数 例外クラス 別 件数 加盟店別 件数 アプリケーションログ

アプリケーションリソース ダッシュボード Elastic APM AgentやElastic Agentが収集してくれたメトリクスをもとに アプリケーションのリソース情報（ CPU/メモリ、 GC回数、スレッド数、 DBコネクションプール）を可視化 CPU使用率 メモリ使用率 GC回数 スレッド数 非同期処理用スレッド 数 DBコネクションプール数

サービス監視ダッシュボード アプリと APMで収集したメトリクス情報をもとにサービス観点のダッシュボードを作成 業務毎のステータス別 件数 業務毎の 加盟店別 件数

ダッシュボード活用事例 ● 全体俯瞰のためのダッシュボード ● トレースによる詳細分析 ● 活用事例の紹介

トレースの紹介 各種ダッシュボードからトレースへ遷移 トレース ID（trace.id） トレース画面へのリンク

トレースの紹介 各種ダッシュボードからトレースへ遷移 全体 SQL

トレースの紹介 全体の処理時間、 SQL実行、外部通信の流れを視覚的に確認することが可能 全体 SQL リクエストの処理全体（ 107ms） SQL（3.6ms） 外部通信（ 90ms）

トレースの紹介 全体の処理時間、 SQL実行、外部通信の流れを視覚的に確認することが可能 全体 SQL リクエストの処理全体をクリック

トレースの紹介（リクエスト / レスポンスの値） APMライブラリを使用してアプリからトレースに業務情報を付与 リクエスト / レスポンスの パラメータの確認が可能 リクエストパラメータ 加盟店情報、決済情報、ユーザ情報 等 レスポンスパラメータ 決済結果情報、業務コード 等

トレースの紹介（センシティブ項目のマスキング処理） APMライブラリを使用してアプリからトレースに業務情報を付与 個人情報などのセンシティブ項目は アプリ側で定義しマスキング処理

トレースの紹介（SQLの確認） Elastic APMがSQLの処理を自動収集してくれるためトレースの確認が可能 全体 SQL 対象のSQLの処理時間 SQLの処理をクリック 対象のSQLの確認が可能

トレースの紹介（HTTP送信処理の確認） APMライブラリを使用してアプリからトレースに業務情報を付与 全体 SQL リクエストパラメータ 外部通信処理をクリック レスポンスパラメータ

トレースの紹介 例外が発生した場合は > View related error のラベルが表示されるので、例外の発生をひと目で確認可能

トレースの紹介 例外が発生した場合は > View related error のラベルが表示されるので、例外の発生をひと目で確認可能 クリックすると 対象の例外メッセージを確認可能

ダッシュボード活用事例 ● 全体俯瞰のためのダッシュボード ● トレースによる詳細分析 ● 活用事例の紹介

活用事例① システムエラーの調査 APIダッシュボードでシステムエラーを示す業務コードを確認

活用事例① システムエラーの調査 発生していたシステムエラーコードでフィルタをかけてトレースを確認 システムエラーとなった トレース IDをクリック

活用事例① システムエラーの調査 DBには問題がなく、決済機関への通信処理に失敗していることが確認できる

活用事例① システムエラーの調査 DBには問題がなく、決済機関への 通信処理に失敗 していることが確認できる 「View related error」をクリックす ると、発生した例外情報を確認で きる リトライ処理 リトライ処理

活用事例① システムエラーの調査 決済機関への通信処理で接続エラー（接続タイムアウト）が発生していることが確認できる

活用事例① システムエラーの調査 外部通信ダッシュボードを確認すると、特定の決済機関への通信だけが接続エラー（他社障害） 決済機関の障害連絡よりも早く把握できた。 素早い調査、検知が可能に 接続エラー 決済機関 Aのみ

Alertによる検知と活用例 障害につながる指標にアラートを設定し、 Slack通知によって決済サービスの障害を早期検知

Alertによる検知と活用例 障害につながる指標にアラートを設定し、 Slack通知によって決済サービスの障害を早期検知 特定可能な処理名 特定可能な件数 次のアクション アラート設定やダッシュボードへのリンク

Alertによる検知 従来はElasticsearchのアラート機能に使いづらさがあったが、現在は改善されたため標準機能を活用 Kibanaの操作に慣れていれば直感的に利用可能 本番環境、 ERRORレベルのログが 1件でも発生したらアラート

活用事例② 処理遅延の調査 APIダッシュボードから特定の APIについて、ある時点を境に処理時間が大きく悪化していることを確認 API別 件数 API別 処理時間（積み上げ） 加盟店別 件数 処理時間 処理時間が悪化 特定のAPIのみ悪化（緑色）

活用事例② 処理遅延の調査 トレースを確認すると特定の SQL（select）が、処理時間の大半を占めていることを確認 全体 SQL 全体の処理時間が 2.48秒間に対して SQL(select)に2.46秒かかっている

活用事例② 処理遅延の調査 SQLダッシュボードではこの SQLが、ある時点を境に処理時間が大きく悪化していることを確認 調査の結果、 DBのバッファキャッシュの影響により、パフォーマンスが急激に低下していたことが判明 SQL別 処理時間（積み上げ） 処理時間

活用事例② 処理遅延の調査 対象テーブルにインデックスを作成して解決 トレースとダッシュボードのおかげで、影響の確認から改善効果の確認まで分かりやすい SQL別 処理時間（積み上げ） 処理時間 1500ms ⇒ 30ms

活用事例② 処理遅延の調査 対象テーブルにインデックスを作成して解決 トレースとダッシュボードのおかげで、影響の確認から改善効果の確認まで分かりやすい 全体 SQL 2468ms 30ms

活用事例③ Observabilityからサービス改善につなげた事例 ● 決済機関へのトランザクション量を可視化し、傾向を把握 ● 加盟店のセール時に、決済トランザクションの一部が決済機 関側の流量上限超過エラーとなっていることを特定 ● 決済機関と協議のうえ、加盟店の流量上限引き上げを実現 Observabilityはただの「監視」ではなく 「サービス改善の手段」

ログ / メトリクス / トレース / サービス すべての監視をKibanaで 監視ツールが分散 / 乱立 ⇒ Kibanaですべて監視を集約 アプリケーション監視が乏しい ⇒ 構造化ログとトレースで効果的なダッシュボードを整備 決済トランザクション バックエンド アプリケーション APM Java Agent Logstash Elasticsearch Kibana 他ツールA 他ツールB 他ツールC 他ツールD アプリログ サーバリソース CPU / メモリ アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC トレース Elastic Agent APM Elasticsearch Kibana

今後に向けた生成 AI活用

今後について（生成AIの活用）① AI Agent Builderを活用したシステム障害分析調査を検証中 Kibanaからチャットでアクセス可能で利用しやすい Tool設定（ES|QL） Agent設定（プロンプト） 出力結果 検証中だけど回答結果は良い感じ

今後について（生成AIの活用）② AI Agent Builderを使用せずに Claude Code（+自作skill）から直接アクセスする分析も検証中 Tool定義もMCPもなしの状態 で検証 playwrightでヘッドレスブラウザ操作 スクリーンショットと ダッシュボード情報を取得 MCPなしで直接 APIの呼び出し Agent Skills ・playwright-cli ・tracktool-monitor playwright-cli skill でサービス全体の監視ダッシュボードを参照し、スクリーンショット取得お よび各チャートのクエリ確認を行う。 その後、Kibana API 経由で Elasticsearch にクエリを実行し、決済状況を確認してレポート する。 ※Skill には具体的な手順やスクリプトは含めず、ダッシュボードで使用されるフィールドの業 務的な意味と定義のみを整理している。

今後について（生成AIの活用）② AI Agent Builderを使用せずに Claude Code（+自作skill）から直接アクセスする分析も検証中 出力結果 検証中だけど回答結果は かなり良い感じ サマリ 決済手段別 加盟店別 分析結果

今後について（生成AIの活用）② AI Agent Builderを使用せずに Claude Code（Skills作成）から直接アクセスする分析も検証中 出力結果（ 検証中だけど かなり良い感じ ） サマリ 加盟店別 ログ/メトリクス /トレースを Elastic Cloudに集約しているからこそ、 分析結果 決済手段別 AIの力を最大限に活用できる 監視 ⇒ サービス改善 ⇒ AI活用（AI Agent Builderに期待）

まとめ

まとめ Elastic Cloudによる監視基盤の統合 ■ 課題 ■ 課題 ログ基盤のログ量増加による性能問題 運用体制の制約やコスト整合への問題 ■ 解決 ■ 解決 Elastic Cloudへの移行でデータの取込遅延を 解消し、 リアルタイムな状況把握を実現 合わせてデータ保持期間の延長により、過去 の決済データの調査効率が大幅に向上 Elastic Cloudを採用することによって 運用コス トの増加が抑えられた。 さらに、 Frozen Tierの活用により 保持期限を 延長したにもかかわらずコストの大幅増を抑え られた

まとめ 決済サービスの Observability ■ 課題 ■ 課題 アプリケーションのログ /ダッシュボードが乏しい 状態だった 監視ツール /サービスが分散していた ■ 解決 ■ 解決 モダナイゼーションの際に Elastic Agent・APM Agentを導入し、サービス観点のダッシュボード を構築 システム全体の Observabilityを強化し、 障害 検知の迅速化、パフォーマンスボトルネックの 可視化を実現 ログ / メトリクス / トレースの全てを Elasticsearchに集約し、監視を Kibanaに一元 化 監視ツール / 調査ツールの統一により、 調査作 業の効率化、調査品質の向上 を実現

ご清聴ありがとうございました