決済サービスを支えるElastic Cloud - Elastic Cloudの導入と推進、決済サービスのObservability

Elastic{ON} Tokyo 2026年3月10日

SBペイメントサービスでは、増大するログ量や運用負荷といった課題を背景に、決済サービスを支えるログ基盤をElastic Cloudへ段階的に移行しています。本セッション前半では、移行に至った背景や進め方、移行プロジェクトで直面した課題とそれに対する工夫についてご紹介します。後半では、実際に決済サービスの監視で活用しているダッシュボードを例に、Elastic AgentやAPMを用いたオブザーバビリティの実践的な取り組みをお伝えします。

Transcript

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

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

3. ソフトバンクグループの 決済分野における中核事業会社 会社紹介 – SBペイメントサービス SoftBank Group 決済・金融 インターネット コンテンツ その他 海外投資 通信
4. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、Visa加盟店で 利用できるプリペイドカードです。ご 利用金額に応じてTポイントが貯ま ります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟店 契約会社）としての加盟店審査や管理事業、 端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算請 求「ソフトバンクまとめて支払い」の 開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 SBペイメントサービスの事業内容 決済代行からカード事業まで幅広く展開
5. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、Visa加盟店で 利用できるプリペイドカードです。ご 利用金額に応じてTポイントが貯ま ります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟店 契約会社）としての加盟店審査や管理事業、 端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算請 求「ソフトバンクまとめて支払い」の 開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 SBペイメントサービスの事業内容 決済代行からカード事業まで幅広く展開
6. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 システム概要 オンライン決済サービス 画面リンク型
7. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済画面や決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 システム概要 オンライン決済サービス 画面リンク型 多彩な決済手段を一括で導入可能 加盟店の手続きコスト、開発コストを削減
8. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 画面リンク型 導入実績 21.6 万店 (2021年 実績) システム概要 オンライン決済サービス
9. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 画面リンク型 決済手段 39 種類に対応 （2021年 実績） システム概要 オンライン決済サービス
10. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 画面リンク型 決済取扱高 9.8 兆円 (2024年実績) システム概要 オンライン決済サービス
11. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 画面リンク型 加盟店と決済機関の間に位置する 自社だけでは完結しない Webシステム システム概要 オンライン決済サービス
12. 前半パート 
 Elastic Cloudの導入と移行推進 
 SBペイメントサービスで進めている、ログ基盤の Elastic Cloudへの段階的な移行についてご紹介しま す。移行の背景や進め方、プロジェクトの中で直面した 課題とその対応についてお話しします。 今日お話すること 今井 健太
 SBペイメントサービス 
 システム運用統制部 プロジェクト推進課 
 後半パート 
 決済サービスの Observability
 前半でご紹介するログ基盤の上で、どのように監視や 可視化を行っているのかをご紹介します。Elastic AgentやAPMを活用したダッシュボードを例に、決済 サービスにおけるオブザーバビリティの実践をお伝え します。 鈴木 順也
 SBペイメントサービス 
 システム運用統制部 

13. Elastic Cloud導入/移行

14. アジェンダ 
 ログ基盤の再設計
 01 Elastic Cloudの採用
 02 データの保持期限
 03 中央管理の採用
 04
15. ElasticCloud 移行を通じた ログ基盤の再設計
16. 顕在化した課題 増え続けるシステム ログ種増加 データ増加 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった
17. 顕在化した課題 性能限界の兆候 取り込み遅延 ログ大容量化の影響 コスト増加 保持期間の圧迫 増え続けるシステム ログ種増加 データ増加 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった
18. 顕在化した課題 性能限界の兆候 取り込み遅延 ログ大容量化の影響 コスト増加 保持期間の圧迫 → この構造は、今後も成立続けるのか？ 増え続けるシステム ログ種増加 データ増加 システムやその利用数が増加した結果、データ増加に伴う顕在化した課題があった
19. 再設計の判断 拡張か、再設計か検討した結果、再設計と判断した 拡張 オンプレミス増強 部分的な性能改善 既存構造の延長 → 一時的な改善 再設計 構造そのものを見直す 将来増加を前提にする 運用体制と整合させる → 持続可能な構造へ
20. 再設計の判断 拡張か、再設計か検討した結果、再設計と判断した 拡張 オンプレミス増強 部分的な性能改善 既存構造の延長 → 一時的な改善 再設計 構造そのものを見直す 将来増加を前提にする 運用体制と整合させる → 持続可能な構造へ
21. 再設計の判断 拡張 オンプレミス増強 部分的な性能改善 既存構造の延長 → 一時的な改善 再設計 構造そのものを見直す 将来増加を前提にする 運用体制と整合させる → 持続可能な構造へ 拡張か、再設計か検討した結果、再設計と判断した
22. Elastic Cloudの採用

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

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

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

27. 私たちが必要としたもの ・柔軟な拡張性 ・少人数運用 ・維持可能な構成 戦略的制約 運用的制約 技術的制約 制約を踏まえて持続可能な基盤を構築することを目的とした
28. 私たちが必要としたもの 既存の構成では満たせない ・柔軟な拡張性 ・少人数運用 ・維持可能な構成 戦略的制約 運用的制約 技術的制約 制約を踏まえて持続可能な基盤を構築することを目的とした
29. 私たちが必要としたもの ログ基盤 Elastic Cloud 既存の構成では満たせない ・柔軟な拡張性 ・少人数運用 ・維持可能な構成 戦略的制約 運用的制約 技術的制約 制約を踏まえて持続可能な基盤を構築することを目的とした
30. 私たちが必要としたもの こっちを採用 
 Cloudサービスなので、 
 サーバの増減はリアルタイム 
 コンソールからの拡張や、バージョンアップが容易に行えた
31. 私たちが必要としたもの コンソールからの拡張や、バージョンアップが容易に行えた こっちを採用 
 バージョンアップは 
 コンソールからワンタッチ 

32. データの保持期限 

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

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

36. Data Tier の利用検討 HOT WARM COLD FROZEN Enterprise 通常は HOT → WARM → COLD → FROZEN と段階的に移行
37. Data Tier の利用検討 大 小 速 遅 HOT WARM COLD FROZEN Enterprise 両極端な構成にする設計判断
38. Data Tier の利用検討 大 小 速 遅 HOT WARM COLD FROZEN Enterprise 両極端な構成にする設計判断
39. Data Tier の利用検討 HOT WARM COLD FROZEN Enterprise フルデータを ローカル保持 ローカル保持 ノードに データ保持 保持なし SSD・高速I/O HDD中心 検索可能 スナップショット 検索可能 スナップショット FROZENはノードにデータを持たないため、実質どこまでも保持が可能
40. Data Tier の利用検討 HOT WARM COLD FROZEN Enterprise フルデータを ローカル保持 ローカル保持 ノードに データ保持 保持なし SSD・高速I/O HDD中心 検索可能 スナップショット 検索可能 スナップショット FROZENはノードにデータを持たないため、実質どこまでも保持が可能 こっちを採用 
 過去データの調査や 
 長期間の傾向分析が 
 低コストで可能 になった

41. Data Tier の利用検討 Index Managementで見ると、 Storageが0になっている
42. 中央管理の採用 

43. 中央管理 Beats Fleet Elastic Agent こっちを採用 
 設定個別管理 
 運用体制の拡張制約に対して 管理方式を検討
44. 中央管理 Beats Fleet Elastic Agent こっちを採用 
 一元管理
 運用体制の拡張制約に対して 管理方式を検討
45. 中央管理 Beats Fleet Elastic Agent https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 運用体制の拡張制約に対して 管理方式を検討
46. 中央管理 Beats Fleet Elastic Agent https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 運用体制の拡張制約に対して 管理方式を検討
47. 中央管理 Beats Fleet Elastic Agent https://www.docswell.com/s/shibadog/5M1WJJ-2023-03-10-222018/1 こっちを採用 
 こっちを採用 
 運用体制の拡張制約に対して 管理方式を検討
48. データの収集設定 アプリA Logs アプリB Logs ミドルA Logs ミドルB Logs namespace dataset SYS01  GP01 SYS01  GP02 app access logs-sys01-gp01-app-* logs-sys01-gp01-access-* logs-sys01-gp01-error-* logs-sys01-gp02-app-* logs-sys01-gp02-access-* logs-sys01-gp02-error-* : : 当初は、namespaceやdatasetでデータの分類を行っていた
49. データの収集設定 アプリA Logs アプリB Logs ミドルA Logs ミドルB Logs namespace dataset SYS01  GP01 SYS01  GP02 app access logs-sys01-gp01-app-* logs-sys01-gp01-access-* logs-sys01-gp01-error-* logs-sys01-gp02-app-* logs-sys01-gp02-access-* logs-sys01-gp02-error-* : : 当初は、namespaceやdatasetでデータの分類を行っていた Index数増！ 性能劣化！！
50. データの収集設定 アプリA Logs アプリB Logs ミドルA Logs ミドルB Logs namespace dataset SYS01 SYS02 app access metadata 役割 グループ logs-sys01-app-* logs-sys01-access-* logs-sys01-error-* : : フィールドで管理する方針に変更
51. こっちを採用 
 Agent Policiesにて設定 
 各システム側で設計は不要 
 基盤側で制御が可能 

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

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

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

56. 決済サービスの Observability

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

58. アジェンダ 
 決済サービスの監視状況
 01 モダナイゼーション
 02 ダッシュボード活用事例
 03 今後に向けた生成AI活用
 04 まとめ
 05
59. 決済サービスの監視状況と課題
60. Logstash jdbc-input-pluginで1分間隔でSQLを実行して決済業務メトリクスを取得、 Elasticsearchに投入 今までの監視状況 ①
 Elasticsearch Kibana 決済システム Apps Database Logstash SQL実行 App App App App App App App App 決済データベース
61. サービス監視するため各決済手段毎のグラフを表示して、ひとめで状況を把握できるように サービス監視ダッシュボード

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

64. ログ、メトリクス、トレースの監視範囲を拡大し、システム全体の可視化レベルは高まった 今までの監視状況 ②
 Elasticsearch Kibana 決済システム Apps Logstash 他ツールB サーバリソース CPU / メモリ 他ツールA アプリログ 他ツールC アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC 他ツールD トレース 決済トランザクション App App App App App App App App App
65. ログ、メトリクス、トレースの監視範囲を拡大し、システム全体の可視化レベルは高まった 監視ツールが分散 / 乱立している、アプリケーションログの活用できていない 今までの監視状況 ②
 Elasticsearch 決済システム Apps Logstash 他ツールB サーバリソース CPU / メモリ 他ツールA アプリログ 他ツールC アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC 他ツールD トレース 決済トランザクション App App App App App App App App App Kibana
66. 監視ツールやサービスが分散・乱立 ツール間の行き来が煩雑 複数のツールを横断する運用となり、運用者 がスムーズに調査できない 属人化と調査品質のムラ 各ツールの知識や利用経験が担当者に依 存していることから、活用状況が属人化し、 調査品質にムラが生じている 現状の課題
 Tool A Tool B Tool C ？
67. アプリケーションログの活用ができていない 現状の課題
 ログ内容が乏しい アプリがレガシーでログの内 容が乏しく、運用に活かせて いない メトリクス取得が困難 ログ内容が人間が読む前提 となっているため、業務内容 のメトリクスを取得しづらい 傾向把握ができていない 普段の傾向が把握できておら ず、サービスの課題発見や改 善につなげられていなかった ?
68. モダナイゼーションによって 
 再構築した Observability
69. 決済機関のゲートウェイを担うレガシーなシステム モダナイゼーションプロジェクトを契機に監視基盤の刷新 今回の話の対象システム
 SBPS決済システム バックエンド アプリケーション （レガシー） フロントエンド アプリケーション 購入要求 購入結果 加盟店 （ショッピングサイト） 加盟店 （ショッピングサイト） 加盟店 （ショッピングサイト） 決済機関 決済機関 決済機関
70. 決済機関のゲートウェイを担うレガシーなシステム モダナイゼーションプロジェクトを契機に監視基盤の刷新 今回の話の対象システム
 SBPS決済システム バックエンド アプリケーション フロントエンド アプリケーション 購入要求 購入結果 加盟店 （ショッピングサイト） 加盟店 （ショッピングサイト） 加盟店 （ショッピングサイト） 決済機関 決済機関 決済機関 APM Java Agent Elastic Agent アプリをSpring Bootで刷新、 Elastic Agent、APM Java Agentを 導入して監視を強化
71. アプリにElastic APM Agentを導入し、トレース、メトリクスを取得 APMサーバを経由して Elasticsearchに保存 Observability構成 - APM Agent
 APM Elasticsearch Kibana 決済バックエンド アプリケーション APM Java Agent App Logs メトリクス トレース Elastic Agent
72. アプリケーションログを JSONで構造化された状態でログ出力し、 Elastic Agentによって構造化された状態のまま Elasticsearchに投入 Observability構成 - Elastic Agent
 APM Elasticsearch Kibana 決済バックエンド アプリケーション APM Java Agent App Logs ログ（JSON 構造化ログ） Elastic Agent
73. ダッシュボード活用事例 
 • 全体俯瞰のためのダッシュボード 
 • トレースによる詳細分析 
 • 活用事例の紹介 

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

77. アプリケーションの APIの処理状況を可視化 APM Agent API監視ダッシュボード
 ステータスコード別 件数 API別 件数 レイテンシ （パーセンタイル、中央値、平均値）
78. アプリケーションの APIの処理状況を可視化 APM Agent API監視ダッシュボード
 加盟店別 件数 業務結果コード 別 件数 業務結果コード 別 件数
79. アプリケーションの APIの処理状況を可視化 API結果のログ APM Agent API監視ダッシュボード

80. Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 APM Agentによるアプリケーション監視（SQL）
 監視対象
 APM Java Agent Database 外部システム APM Elasticsearch Kibana ② SQL実行 ③ HTTPS通信 ①②③を含むトレースを送信 決済アプリケーション 
 ① リクエスト ① レスポンス どのSQLが、いつ・どれだけ 呼び出され、 応答にどれくらい時間がかかったのかが把握できる
81. APMが収集してくれたトレース情報を利用して SQLの実行状況を可視化 APM Agent SQL監視ダッシュボード
 結果別 件数 応答時間（パーセンタイル） クエリ別 応答時間（積み上げ） SQLトレース情報
82. Webアプリケーションにとって関心の高い処理（リクエスト、 DB、外部通信）を一気通貫で可視化 APM Agentによるアプリケーション監視（外部通信）
 監視対象
 APM Java Agent Database 外部システム APM Elasticsearch Kibana ② SQL実行 ③ HTTPS通信 ①②③を含むトレースを送信 決済アプリケーション 
 ① リクエスト ① レスポンス どの通信処理が、いつ・どれだけ 呼び出され、 応答にどれくらい時間がかかったのかが把握できる
83. APMが収集してくれたトレース情報を利用して HTTP通信の実行状況を可視化 APM Agent 外部通信監視ダッシュボード
 HTTP通信トレース情報 ステータスコード別 件数 結果別 件数 送信先エンドポイント別 件数 応答時間（パーセンタイル） 接続先別 応答時間 接続エラー /レスポンスタイムアウト件数
84. Elastic Agent アプリケーションログ監視ダッシュボード
 アプリケーションは JSONの構造化されたログを出力 しているので、そのまま Elasticsearchへ投入 ログレベルや発生した例外クラス、加盟店が構造化されているため可視化して傾向を把握可能 環境別 件数 ホスト別 件数 サービス別 件数 例外クラス 別 件数 ログレベル 別 件数 加盟店別 件数 アプリケーションログ
85. Elastic APM AgentやElastic Agentが収集してくれたメトリクスをもとに アプリケーションのリソース情報（ CPU/メモリ、GC回数、スレッド数、 DBコネクションプール）を可視化 アプリケーションリソース ダッシュボード
 スレッド数 DBコネクションプール数 非同期処理用スレッド 数 メモリ使用率 CPU使用率 GC回数
86. アプリとAPMで収集したメトリクス情報をもとにサービス観点のダッシュボードを作成 サービス監視ダッシュボード
 業務毎の加盟店別 件数 業務毎のステータス別 件数
87. ダッシュボード活用事例 
 • 全体俯瞰のためのダッシュボード 
 • トレースによる詳細分析 
 • 活用事例の紹介 

88. 各種ダッシュボードからトレースへ遷移 トレースの紹介
 トレースID（trace.id） トレース画面へのリンク
89. 各種ダッシュボードからトレースへ遷移 トレースの紹介
 SQL 全体
90. SQL 全体 全体の処理時間、 SQL実行、外部通信の流れを視覚的に確認することが可能 トレースの紹介
 リクエストの処理全体（ 107ms） SQL（3.6ms） 外部通信（ 90ms）
91. SQL 全体 全体の処理時間、 SQL実行、外部通信の流れを視覚的に確認することが可能 トレースの紹介
 SQL　 リクエストの処理全体をクリック
92. APMライブラリを使用してアプリからトレースに業務情報を付与 トレースの紹介（リクエスト / レスポンスの値）
 リクエストパラメータ 加盟店情報、決済情報、ユーザ情報 等 レスポンスパラメータ 決済結果情報、業務コード 等 リクエスト / レスポンスの パラメータの確認が可能
93. APMライブラリを使用してアプリからトレースに業務情報を付与 トレースの紹介（センシティブ項目のマスキング処理）
 個人情報などのセンシティブ項目は アプリ側で定義しマスキング処理
94. SQL 全体 Elastic APMがSQLの処理を自動収集してくれるためトレースの確認が可能 トレースの紹介（SQLの確認）
 SQLの処理をクリック 対象のSQLの確認が可能 対象のSQLの処理時間
95. SQL 全体 APMライブラリを使用してアプリからトレースに業務情報を付与 トレースの紹介（HTTP送信処理の確認）
 外部通信処理をクリック リクエストパラメータ レスポンスパラメータ
96. 例外が発生した場合は > View related error のラベルが表示されるので、例外の発生をひと目で確認可能 トレースの紹介

97. 例外が発生した場合は > View related error のラベルが表示されるので、例外の発生をひと目で確認可能 トレースの紹介
 クリックすると 対象の例外メッセージを確認可能
98. ダッシュボード活用事例 
 • 全体俯瞰のためのダッシュボード 
 • トレースによる詳細分析 
 • 活用事例の紹介 

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

100. 発生していたシステムエラーコードでフィルタをかけてトレースを確認 活用事例① システムエラーの調査
 システムエラーとなった トレースIDをクリック
101. DBには問題がなく、決済機関への通信処理に失敗していることが確認できる 活用事例① システムエラーの調査

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

104. 外部通信ダッシュボードを確認すると、特定の決済機関への通信だけが接続エラー（他社障害） 決済機関の障害連絡よりも早く把握できた。 素早い調査、検知が可能に 活用事例① システムエラーの調査
 決済機関Aのみ 接続エラー
105. 障害につながる指標にアラートを設定し、 Slack通知によって決済サービスの障害を早期検知 Alertによる検知と活用例

106. 障害につながる指標にアラートを設定し、 Slack通知によって決済サービスの障害を早期検知 Alertによる検知と活用例
 特定可能な処理名 特定可能な件数 次のアクション アラート設定やダッシュボードへのリンク
107. 従来はElasticsearchのアラート機能に使いづらさがあったが、現在は改善されたため標準機能を活用 Kibanaの操作に慣れていれば直感的に利用可能 Alertによる検知
 本番環境、 ERRORレベルのログが 1件でも発生したらアラート
108. APIダッシュボードから特定の APIについて、ある時点を境に処理時間が大きく悪化していることを確認 活用事例② 処理遅延の調査
 処理時間が悪化 API別 件数 加盟店別 件数 処理時間 API別 処理時間（積み上げ） 特定のAPIのみ悪化（緑色）
109. SQL 全体 トレースを確認すると特定の SQL（select）が、処理時間の大半を占めていることを確認 活用事例② 処理遅延の調査
 全体の処理時間が 2.48秒間に対して SQL(select)に2.46秒かかっている
110. 活用事例② 処理遅延の調査
 SQLダッシュボードではこの SQLが、ある時点を境に処理時間が大きく悪化していることを確認 調査の結果、 DBのバッファキャッシュの影響により、パフォーマンスが急激に低下していたことが判明 SQL別 処理時間（積み上げ） 処理時間
111. 活用事例② 処理遅延の調査
 対象テーブルにインデックスを作成して解決 トレースとダッシュボードのおかげで、影響の確認から改善効果の確認まで分かりやすい SQL別 処理時間（積み上げ） 処理時間 1500ms ⇒ 30ms
112. SQL 全体 活用事例② 処理遅延の調査
 対象テーブルにインデックスを作成して解決 トレースとダッシュボードのおかげで、影響の確認から改善効果の確認まで分かりやすい 2468ms 30ms
113. • 決済機関へのトランザクション量を可視化し、傾向を把握 • 加盟店のセール時に、決済トランザクションの一部が決済機 関側の流量上限超過エラーとなっていることを特定 • 決済機関と協議のうえ、加盟店の流量上限引き上げを実現 活用事例③ Observabilityからサービス改善につなげた事例
 Observabilityはただの「監視」ではなく 「サービス改善の手段」
114. 監視ツールが分散 / 乱立 ⇒ Kibanaですべて監視を集約 アプリケーション監視が乏しい ⇒ 構造化ログとトレースで効果的なダッシュボードを整備 ログ / メトリクス / トレース / サービス すべての監視をKibanaで
 Elasticsearch Kibana Logstash 他ツールB サーバリソース CPU / メモリ 他ツールA アプリログ 他ツールC アプリリソース スレッド数、DBコネク ションプール、ヒープ、 GC 他ツールD トレース 決済トランザクション バックエンド アプリケーション APM Java Agent Elastic Agent APM Elasticsearch Kibana
115. 今後に向けた生成 AI活用
116. 今後について（生成AIの活用）①
 AI Agent Builderを活用したシステム障害分析調査を検証中 Kibanaからチャットでアクセス可能で利用しやすい Agent設定（プロンプト） 出力結果 検証中だけど回答結果は良い感じ Tool設定（ES|QL）
117. 今後について（生成AIの活用）②
 
 AI Agent Builderを使用せずに Claude Code（+自作skill）から直接アクセスする分析も検証中 Tool定義もMCPもなしの状態 で検証 Agent Skills ・playwright-cli ・tracktool-monitor playwright-cli skill でサービス全体の監視ダッシュボードを参照し、スクリーンショット取得お よび各チャートのクエリ確認を行う。 その後、Kibana API 経由で Elasticsearch にクエリを実行し、決済状況を確認してレポート する。 ※Skill には具体的な手順やスクリプトは含めず、ダッシュボードで使用されるフィールドの業 務的な意味と定義のみを整理している。 playwrightでヘッドレスブラウザ操作 スクリーンショットと ダッシュボード情報を取得 MCPなしで直接 APIの呼び出し
118. 今後について（生成AIの活用）②
 
 AI Agent Builderを使用せずに Claude Code（+自作skill）から直接アクセスする分析も検証中 出力結果 検証中だけど回答結果は かなり良い感じ 分析結果 加盟店別 決済手段別 サマリ
119. 今後について（生成AIの活用）②
 
 AI Agent Builderを使用せずに Claude Code（Skills作成）から直接アクセスする分析も検証中 出力結果（ 検証中だけど かなり良い感じ ） ログ/メトリクス /トレースを Elastic Cloudに集約しているからこそ、 AIの力を最大限に活用できる 監視 ⇒ サービス改善 ⇒ AI活用（AI Agent Builderに期待）
120. まとめ
121. Elastic Cloudによる監視基盤の統合 ▪ 課題 ログ基盤のログ量増加による性能問題 ▪ 解決 Elastic Cloudへの移行でデータの取込遅延を 解消し、リアルタイムな状況把握を実現 合わせてデータ保持期間の延長により、過去 の決済データの調査効率が大幅に向上 ▪ 課題 運用体制の制約やコスト整合への問題 ▪ 解決 Elastic Cloudを採用することによって 運用コス トの増加が抑えられた。 さらに、Frozen Tierの活用により 保持期限を 延長したにもかかわらずコストの大幅増を抑え られた まとめ

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

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