Elastic Agent × 構造化ログにより 実現した決済監視ダッシュボード

Transcript

1. Elastic Agent × 構造化ログにより
 実現した決済監視ダッシュボード
 2022-07-21
 SB Payment Service Corp.
 今井 健太(@shiba_dog)

2. 自己紹介
 今井 健太（@shiba_dog） Elasticsearch ＋ Kibanaで可視化利用を5年間
 JavaプログラマでWebシステムの開発・運用歴が長い
 現在の主な業務
 • 新規サービス開発・運用
 • 運用の改善
 2 アプリケーション開発者
3. 3 会社紹介 – SBペイメントサービス
 ソフトバンクグループの決済分野における中核事業会社 SoftBank Group 決済・金融 インターネット コンテンツ その他 海外投資 通信
4. SBペイメントサービスの事業内容
 ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 4
5. SBペイメントサービスの事業内容
 ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 5
6. 決済代行サービス
 6 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 オンライン決済サービス 画面リンク型
7. API型 画面リンク型 決済代行サービス
 7 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 オンライン決済サービス 導入実績 約 15.7万 店舗 (2020年度実績)
8. API型 画面リンク型 決済代行サービス
 8 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携 当社 当社 オンライン決済サービス 決済手段 40 種以上に対応
9. API型 画面リンク型 決済代行サービス
 9 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携 当社 当社 オンライン決済サービス 取扱高 5兆3,027 億円 (2021年実績)
10. 決済代行サービス
 10 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携 当社 当社 オンライン決済サービス API型 画面リンク型 加盟店システムと決済機関システムの間に位置す る自社だけでは完結しない Webシステム
11. もくじ
 ✓ ElasticStackを導入したシステムとその構成
 ✓ ダッシュボードの紹介
 ✓ ダッシュボードを作るにあたって行ったこと
 ◦ アプリケーションログの構造化
 ◦ ミドルウェアの情報収集
 ✓ まとめ
 11
12. 非同期
 キューシステム
 12 今回導入を行ったシステムの構成
 カード会社 A
 加盟店 X
 決済オンライン
 システム
 加盟店 Y
 決済バッチ
 加盟店 Z
 カード会社 B
 カード会社 C

13. 13 今回導入を行ったシステムの構成
 カード会社 A
 加盟店 X
 加盟店 Y
 加盟店 Z
 カード会社 B
 カード会社 C
 バッチで決済処理を行うために、
 カード会社が許容する最適な流量でリクエストすること
 を目的とするシステム。
 オンプレミスで構築
 決済バッチ
 非同期
 キューシステム
 決済オンライン
 システム

14. データシッパーはどちらを使う？
 14 Elastic Agent
 Filebeat
 Metricbeat

15. データシッパーはどちらを使う？
 15 Elastic Agent
 Filebeat/Metricbeatは使い慣れている。 さらに、細かいチューニングが可能 しかし、複数のサーバに導入する場合、管理が大変。 Filebeat
 Metricbeat

16. データシッパーはどちらを使う？
 16 Elastic Agent
 今回は、Grokは単純で収集元サーバでの加工は不要。 ログ収集で煩わされたくない！ Filebeat
 Metricbeat

17. データシッパーはどちらを使う？
 17 Elastic Agent
 Elastic Agent
 Elastic Agent
 Elastic Agent
 Elastic Agent
 Elastic Agent
 Elastic Agent
 今回は、Grokは単純で収集元サーバでの加工は不要。 ログ収集で煩わされたくない！ こっちを採用
 Filebeat
 Metricbeat

18. 18 今回導入を行ったシステムの構成
 カード会社 A
 加盟店 X
 加盟店 Y
 加盟店 Z
 カード会社 B
 カード会社 C
 Elastic Agentを導入
 Fleet Serverは各自で起動する設定とした
 決済バッチ
 非同期
 キューシステム
 決済オンライン
 システム

19. これまでのElastic活用履歴
 19 2017/12/14 Elastic {ON} TOUR Tokyo 2017 
 2019/10/04 Elastic Tokyo User Group 

20. 可視化・検知の状況
 20 決済トランザクションのデータをもとに、
 決済サービスの正常性の把握
 アプリケーションログをもとに、
 アプリケーションのログ分布を把握

21. 運用での困りごと
 アプリケーションとサービスでの可視化の観点が異なっていたため、
 サービスの状況をアプリケーションから把握することが難しかった。
 21 開発者 プロダクトオー ナー WARNログが たくさん出ている！ つまり、どういう影響 だろう？
22. 求めているもの
 システムの開発者以外の人が
 見たとしても、
 状況を把握できるダッシュボード
 22 プロダクトオー ナー 影響を把握したい！
23. 決済リクエストの状況の把握
 23
24. 決済リクエストの状況の把握
 24 各ダッシュボードへのリンク 決済リクエストの失敗理由 決済リクエストの成功・失敗 決済リクエストの応答コード 決済リクエストの応答時間
25. 決済リクエストの状況の把握
 25
26. 決済リクエストの状況の把握
 26 決済処理消化実績 カード会社別 処理量 接続先別 処理量 通信回数
27. 決済リクエストの状況の把握
 27 各ダッシュボードへのリンク 決済リクエストの失敗理由 決済リクエストの成功・失敗 決済リクエストの応答コード 決済リクエストの応答時間 決済リクエストが成功したか・失敗したかを シンプルに把握できる。
 SUCCESS: 成功
 ERROR: 失敗

28. 決済リクエストの失敗理由 決済リクエストの状況の把握
 28 各ダッシュボードへのリンク 決済リクエストの成功・失敗 決済リクエストの応答コード 決済リクエストの応答時間 この場合、一時的にネットワーク障害が発 生してHTTP通信ができない状態になってい たことがわかる

29. 決済リクエストの失敗理由 決済リクエストの状況の把握
 29 各ダッシュボードへのリンク 決済リクエストの成功・失敗 決済リクエストの応答コード 決済リクエストの応答時間 HTTP通信ができていない状況だったため、 応答時間は早くなっていることがわかる

30. 決済リクエストの状況の把握
 30 決済処理消化実績 カード会社別 処理量 接続先別 処理量 通信回数 特定の外部接続先で事象が発生しており、リト ライは４回まで実施しているが
 改善していないことがわかる

31. 決済リクエストの状況の把握
 31 決済処理消化実績 カード会社別 処理量 接続先別 処理量 通信回数 カード会社別の処理量から、特定のカード会 社による障害ではないことがわかる

32. 流量コントロールの状況把握
 32
33. 流量コントロールの状況把握
 33 決済トランザクションの状態 決済失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量
34. 流量コントロールの状況把握
 34 バッチの処理結果 バッチの失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量 決済がNGになっており、決済NGの理由が特 定の理由コードであることがわかる

35. 流量コントロールの状況把握
 35 バッチの処理結果 バッチの失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量 流入が止まった時点から徐々に、
 決済リクエストが消化されている。

36. バッチの処理結果 バッチの失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量 流量コントロールの状況把握
 36 この時点では、特定のキューに
 決済リクエストが残っていることがわかる

37. バッチの処理結果 バッチの失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量 流量コントロールの状況把握
 37 決済リクエストの消化状況から、
 それぞれのカード会社へのリクエストが行わ れていることがわかる

38. これらのダッシュボードを作るにあたって
 38 • アプリケーションで把握している情報の可視化が必要
 ◦ ログメッセージを構造的に入れる必要がある。
 
 • ミドルウェアの情報と合わせたダッシュボードとしたい
 ◦ 絞り込みも容易に行えるように、データのフィールドが統一されている必要が ある。

39. これらのダッシュボードを作るにあたって
 39 • アプリケーションで把握している情報の可視化が必要
 ◦ ログメッセージを構造的に入れる必要がある。
 
 • ミドルウェアの情報と合わせたダッシュボードとしたい
 ◦ 絞り込みも容易に行えるように、データのフィールドが統一されている必要が ある。

40. これらのダッシュボードを作るにあたって
 40 • アプリケーションで把握している情報の可視化が必要
 ◦ ログメッセージを構造的に入れる必要がある。
 
 • ミドルウェアの情報と合わせたダッシュボードとしたい
 ◦ 絞り込みも容易に行えるように、データのフィールドが統一されている必要が ある。
 アプリケーションによる構造化ログで解決！

41. 2022-07-21T10:00:00Z [INFO] 普通のログ。ステータスは200! アプリケーションの構造化ログとは？
 41 LOG -----
 -----

42. 2022-07-21T10:00:00Z [INFO] 普通のログ。ステータスは200! アプリケーションの構造化ログとは？
 42 通常、アプリケーションのログは、
 時間・ログレベル・メッセージなどを
 スペースで区切ったものを出力する。
 -----
 -----
 LOG
43. アプリケーションの構造化ログとは？
 43 2022-07-21T10:00:00Z [INFO] 普通のログ。ステータスは200! メッセージ部分に可視化したい情報を
 出すことができるが、ログ一つ一つに合わせたGrok を作らなければならない！
 -----
 -----
 LOG
44. { "@timestamp": "2022-07-21T10:00:00Z", "log.level": "INFO", "message": "構造化されたログ", "http.response.status_code": 200 } アプリケーションの構造化ログとは？
 44 構造化されたログを出力することで以下の利点がある
 • Grokを容易にすることができる
 • ログ情報を可視化することが容易になる
 {;}
 JSON
45. { "@timestamp": "2022-07-21T10:00:00Z", "log.level": "INFO", "message": "構造化されたログ", "http.response.status_code": 200 } アプリケーションの構造化ログとは？
 45 ECS logging プラグインを利用することで、
 ライブラリ追加とログライブラリの設定のみで
 簡単に実現することが可能。
 {;}
 JSON
46. ECS Loggingについて
 Ealstic Common Schema（ECS）互換であるJSONに簡単にフォーマットするライブラリ。
 このライブラリは複数の言語に対応している。
 • .Net
 • Go
 • Java
 • Node.js
 • PHP
 • Python
 • Ruby
 46 <dependency> <groupId>co.elastic.logging</groupId> <artifactId>logback-ecs-encoder</artifactId> <version>${ecs-logging-java.version}</version> </dependency>
47. アプリケーションの構造化ログとは？
 47 Custom Logs
 構造化されたアプリケーションログを FleetのCustom Logsを使って収集させた。 {;}
 JSON
48. 決済リクエストの状況の把握（再掲）
 48 各ダッシュボードへのリンク 決済リクエストの失敗理由 決済リクエストの成功・失敗 決済リクエストの応答コード 決済リクエストの応答時間
49. これらのダッシュボードを作るにあたって
 49 • アプリケーションで把握している情報の可視化が必要
 ◦ ログメッセージを構造的に入れる必要がある。
 
 • ミドルウェアの情報と合わせたダッシュボードとしたい
 ◦ 絞り込みも容易に行えるように、データのフィールドが統一されている必要が ある。

50. これらのダッシュボードを作るにあたって
 50 • アプリケーションで把握している情報の可視化が必要
 ◦ ログメッセージを構造的に入れる必要がある。
 
 • ミドルウェアの情報と合わせたダッシュボードとしたい
 ◦ 絞り込みも容易に行えるように、データのフィールドが統一されている必要が ある。
 Elastic Agentを使うことで解決！

51. 非同期
 キューシステム
 ミドルウェアとアプリログの統合
 51 決済オンライン
 システム
 -----
 -----
 LOG $
 決済バッチ
 HTTP
 HTTP
 DB DB
52. 非同期
 キューシステム
 ミドルウェアとアプリログの統合
 52 決済オンライン
 システム
 -----
 -----
 LOG $
 決済バッチ
 RabbitMQ HTTP
 HTTP
 Access Log DB DB
53. 非同期
 キューシステム
 ミドルウェアとアプリログの統合
 53 決済バッチ
 決済オンライン
 システム
 「Apache HTTP Server」を使っ て、出力したLogを収集する -----
 -----
 LOG $
 HTTP
 HTTP
 DB DB
54. アクセスログのダッシュボード
 54
55. アクセスログのダッシュボード
 55 パーセンタイルや最大・最小などの値 HTTPステータス別の流量 URL別 平均レスポンスタイム レスポンスタイム （パーセンタイル） アクセスログの一覧
56. アクセスログのダッシュボード
 56 パーセンタイルや最大・最小などの値 HTTPステータス別の流量 URL別 平均レスポンスタイム レスポンスタイム （パーセンタイル） アクセスログの一覧
57. 非同期
 キューシステム
 ミドルウェアとアプリログの統合
 57 決済オンライン
 システム
 「RabbitMQ Logs」を使って、 出力したログや管理APIから メトリクスを収集する -----
 -----
 LOG $
 決済バッチ
 HTTP
 HTTP
 DB DB
58. 非同期
 キューシステム
 ミドルウェアとアプリログの統合
 58 決済オンライン
 システム
 -----
 -----
 LOG $
 決済バッチ
 HTTP
 HTTP
 DB DB Jdbc input pluginを使って SQLによるデータ抽出
59. 流量コントロールの状況把握（再掲）
 59 決済トランザクションの状態 決済失敗理由 処理待ち 決済量断面 処理待ち決済量推移 決済処理消化実績 決済リクエスト流量
60. 流量コントロールの状況把握（データソース）
 60 DBで管理している 決済トランザクション状態 キューの メッセージ量 キューのメッセージ消費レート アプリケーションの 外部システムへの通信レート アクセスログ {;}
 JSON DB
61. 可視化の効果
 サービス状況を把握するダッシュボードに加えて
 システムの状態を、より深く知り得る
 ダッシュボード作成ができた。
 
 61 アプリケーションログを可視化に利用することができるようになっ たため、状態をより深く表せるようになった！

62. まとめ
 • Elastic Agentと構造化ログを組み合わせ、
 アプリケーションログを使った可視化を行った。
 • ミドルウェアのメトリクスとアプリケーションログを併せてみるこ とで、全体の状況を容易に把握することができるようになっ た。
 • システムのログから情報を可視化することで、
 より深い情報の可視化ができるようになった。
 62
63. ご清聴ありがとうございました <(_ _)>

64. 弊社はエンジニアを募集しています 興味がある方は @shiba_dog まで
 We are hiring!