CloudNativeな決済サービスの開発と2年間の歩み #sf_A4

1. な決済サービスの開発と年間の歩み

2. ペイメントサービス株式会社シニアアーキテクト鈴木順也自己紹介主な業務・新規サービスの開発・運用の効率化改善システムの開発に従事元々はのプログラマフリーランスを経て年前に現在の会社に転職

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

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

5. 今日お話すること ● 決済サービスシステム概要 ● 安定した開発運用を支える取り組み ○ プラットフォーム全体のアーキテクチャ ○ アーキテクチャ ○ パイプライン ○ ● これまでの歩み

6. SpringFest 2018 登壇資料決済システムの内製化への旅 SpringとPCFで作るクラウドネイティブなシステム開発 https://www.slideshare.net/makingx/springpcf-jsug-sfh1 関連資料 Pivotal.IO 2019 登壇資料決済システム内製化に向けたプラットフォーム構築 PCF・BOSHによるオブザーバブルプラットフォーム https://www.slideshare.net/DaichiKimura3/pcfbosh-156082821 アプリケーション開発チームプラットフォームチーム

7. 今日お話すること ● 決済サービスシステム概要

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

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

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

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

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

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

14. ● 安定した開発運用を支える取り組み ➢ プラットフォーム全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢

15. syslog+TLS Logstash Elasticsearch Kibana cf push Concourse PrometheusGrafana git push 全体のアーキテクチャ cf create-service cf bind-service Tanzu Application Service

16. 決済システムの内製化への旅とで作るクラウドネイティブなシステム開発 ● 安定した開発運用を支える取り組み ➢ プラットフォーム全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢

17. アプリケーション構成（同期加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service

18. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C オンラインショッピングサイト通販サイト、ゲーム、電子書籍、チケット、不動産、その他アプリケーション構成（同期加盟店 ➡ 決済機関）

19. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 当社決済システムアプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

20. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関システムクレジット、コンビニ支払い、キャリア決済、プリペイドカード、その他アプリケーション構成（同期加盟店 ➡ 決済機関）

21. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Appはマイクロサービスの構成ですべてTAS上に配置アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

22. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C すべてのAppは Java/Spring Boot で実装アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

23. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service 決済機関毎のビジネスロジックが実装されているへルーティング

24. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

25. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 加盟店や決済機関は当然、コントロール範囲外アプリケーション構成（同期加盟店 ➡ 決済機関）

26. Hystrix API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service システム間通信には Hystrix という Circuit Breakerを導入

27. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breakerがない状態で決済機関Aで障害が発生した場合…

28. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service レスポンス遅延、タイムアウト

29. アプリケーション構成（同期加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Service A に障害が伝播処理のブロック、スレッド枯渇

30. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application ServiceAPI Gateway に障害が伝播処理のブロック、スレッド枯渇

31. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application ServiceAPI Gateway に障害が伝播処理のブロック、スレッド枯渇

32. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関A起因の障害にも関わらず関係のない決済機関BCへ影響が出てしまうアプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

33. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breaker があれば特定の決済機関で障害が発生しても

34. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix 障害の伝播を防いでくれるため他の決済機関へ影響を及ぼす心配がないアプリケーション構成（同期加盟店 ➡ 決済機関）

35. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Circuit Brakerにより耐障害性に優れたアプリケーションを実現アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

36. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C

39. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 非同期を実現するために RabbitMQ + Spring Cloud Stream を使用

41. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 特定の加盟店で障害が発生した場合

42. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Dead Letter Queue と呼ばれるキューに退避して、後に再送

43. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Circuit Breakerにより、他の加盟店に影響を及ぼさない Hystrix

44. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix 2年間の運用後年に数回DLQ行きが発生対象メッセージのケース毎に何をしなければいけないか運用を固めていなかったため対応が煩雑に。頻度が低いとはいえ再送の自動化対応等を事前にしておけばよかったと反省…

45. アプリケーション構成（非同期決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix RabbitMQの運用は初だったが2年間トラブルゼロノードダウンやメッセージパブリッシュの停止等は全く発生せず安定して稼働している。 2年間の運用後

46. ライブラリの移行について

47. 2018/11から maintenance mode Resilience4JHystrix ● CircuitBreaker ● Bulkhead ● RateLimiter

48. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service CircuitBreaker 決済機関のシステムエラー率が100%の状態で2分継続したらサーキットオープン

49. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service

50. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service エラーしきい値がデフォルト50%だが弊社は100%に設定

51. どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー決済機関障害発生

52. どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー決済機関障害発生サーキットオープンサーキットオープンによる機会損失が発生

53. 決済サービスでは1件でも正常に取引されているトランザクションがある限りサーキットオープンにはしたくない ◆決済完了　◆決済機関システムエラー決済機関障害発生

54. 決済サービスでは1件でも正常に取引されているトランザクションがある場合はサーキットオープンしたくないとはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社への障害の伝播を防ぎたい決済機関障害発生 ◆決済完了　◆決済機関システムエラー　タイムアウトやレスポンス遅延による障害伝播の恐れ

55. 決済サービスでは1件でも正常に取引されているトランザクションがある場合はサーキットオープンしたくないとはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社への障害の伝播を防ぎたい ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー決済機関障害発生サーキットオープンにより即エラーを返すことで障害伝播を防ぐ

56. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Bulkhead（並列処理数の制限）同時接続数が設定値を超過したらリジェクト

57. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Bulkhead 同時接続数が設定値を超過したらリジェクト

58. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5

59. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5 ウチのシステムは負荷に弱いので同時接続数 5 でお願いします

60. Tanzu Application Service Service A 決済機関 A Bulkhead Bulkheadの並列実行数に5を設定した場合、決済機関Aへの同時接続数 5本が上限となる同時接続数が5以上はリジェクトとして扱われる 1 2 3 4 5

61. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5 Bulkheadの設定を導入し決済機関に限界以上の負荷を与えないように

62. 追加開発の新規アプリケーションから WebClientで実装、リリース済 RestTemplateのJavadoc 「メンテナンスモードのためWebClientの使用を検討してください」 ※RestTemplateはまだ非推奨とはなっていない

63. 移行で発生した問題1 ● 接続タイムアウト、Read/Writeタイムアウトの設定 ○ reactor-nettyのTcpClientにそれぞれタイムアウトを設定

64. 移行で発生した問題2 ● レスポンスのサイズが256KBを超過すると例外が発生 ○ codecsのmaxInMemorySizeを設定 org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer

65. 移行で発生した問題3 ● ファイルディスクリプタのリークが発生 ○ Spring Boot v2.2.8 / v2.3.1の問題（Reactor Netty v0.9.8の不具合） ⇒ Spring Bootのv2.2.9 / v2.3.2のアップデートで解消 https://github.com/spring-projects/spring-boot/issues/21923 Caused by: io.netty.channel.ChannelException: io.netty.channel.unix.Errors$NativeIoException: newSocketStream(..) failed: Too many open files 2.3.2 2.3.1

66. WebFluxは一切使用しておらずWebClientはブロッキングして使用しているものの RestTemplate と同等のパフォーマンスが出ていることが確認できたため移行した。 2020/8から現在まで本番環境で稼働しているが問題は一切発生していない状態。 Spring MVCを使っている場合、並行リクエストが多用されていないのであれば移行の恩恵はあまりないためRestTemplateが非推奨にならない限りは急ぐ必要はない印象。

67. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service 新規機能は方式検討から実装、テストまで内製

68. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C

69. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は外部ベンダさんに依頼

70. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は外部ベンダさんに依頼 Service D 決済機関 D

71. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C Service D 決済機関 D 外部ベンダさんの協力を得ながらサービスを横展開することができた。自分達は新規技術や新方式を採用したアプリケーションの検証/開発に注力することができた。

73. パイプライン Concourse https://concourse-ci.org/

74. https://concourse-ci.org/ Concourse パイプライン

75. ジョブ一覧画面

76. パイプライン画面

77. パイプライン全体のジョブ構成ジョブ設定は YAMLファイルで管理パイプライン画面 - task: mvn-test config: platform: linux image_resource: type: registry-image source: repository: maven tag: 3-jdk-11 inputs: - name: repo caches: - path: repo/m2 run: path: bash args: - -c - | set -e cd repo rm -rf ~/.m2 ln -fs $(pwd)/m2 ~/.m2 mvn test

78. リポジトリの更新がトリガパイプライン画面

81. 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境

82. 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境各種ブランチへの更新がトリガ

83. 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境 Javaの各種バージョンでテストアップデートの弊害を早めに検知

84. 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境 SonarQubeによるコード解析コードの品質をいつでも確認できるようにしておく

85. 開発から本番リリースまでのパイプライン開発環境本番環境テスト環境

86. 開発から本番リリースまでのパイプライン開発環境本番環境テスト環境

87. 開発から本番リリースまでのパイプライン開発環境本番環境テスト環境 CIによる開発サイクル

88. 開発から本番リリースまでのパイプライン開発環境本番環境テスト環境 masterブランチへのマージで Nexus RELEASEリポジトリへデプロイ本番環境リリースへの準備が完了

89. 開発から本番リリースまでのパイプライン本番環境ワンクリックリリースによるCD Nexusのリリースリポジトリの成果物が本番環境に適用される Blue-Green Deployによってサービスへの影響なくリリースが可能

90. 開発から本番リリースまでのパイプライン本番環境トラブル時の切り戻しの際も数クリックのみの対応 ※幸いにもまだやったことないです

91. 開発から本番リリースまでのパイプライン本番環境リリースや切り戻し手順がシンプルなためテレワークで自宅からもリリースが可能

92. によるパフォーマンステスト API Gateway Service A Service B Service C 決済機関 B Mock 決済機関 A Mock 決済機関 C Mock Tanzu Application Service

93. ● ● によるパフォーマンステスト

94. 想定の倍のスループットを目標問題原因スレッドプールが枯渇スレッドプール数の設定ミス HTTP送信時にスループットが上がらないののプール数の設定漏れの実行時のスループットが上がらないコネクションプールの設定ミス Circuit Breakerの想定外のサーキットオープンのチューニングミスのメッセージキューイングが停止のメモリ枯渇（スケールアップ対応）ののスループットが上がらないのワーカースレッド数が不足アプリケーション全体の負荷限界アプリケーションインスタンス数の不足 ※ というかのおかげでのチューニングは不要だった　（いつも必ず対応するやつ）

95. 週間時間

96. 開発期間中にはJMeterによるロードテストとE2Eテストを毎日自動で実行し、結果のスクリーンショットをSlackで通知 Report html cf push

97. パフォーマンステストは開発期間中に何度も繰り返し実行して改善を続けることが大事

99. ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

103. の監視 ● 全のメトリクス ● 全コンテナのメトリクス ● の各コンポーネントのメトリクス ● ミドルウェアのメトリクス ○ の監視 ● 全アプリのメトリクスでの監視対象 30種以上のダッシュボード

104. Micrometer <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>

105. 開発者はPrometheusの設定を意識することはなくリリースしたら自動でアプリケーションを監視する仕組み今までログから可視化していた情報が Grafanaでいつでも確認可能に・CPU ・ヒープ（各領域ごと）・スレッド・GC（回数、時間）・クラスローダ・DBコネクションプール

106. （アクセスログ）

107. アクセスログ一覧レスポンスタイム Percentile アプリ別アクセス数ステータスコード別アクセス数レスポンスタイム AVG （アクセスログ）

108. （アプリケーションログ）

109. ログレベル別ログ出力数アプリケーションログ一覧アプリ別ログ出力数（アプリケーションログ）

110. 開発者は Elastic Stack を意識せず、標準出力にログを出力するだけで良い。（アプリケーションログ）

111. （ロギングの活用）（）でアプリケーションログのフォーマットを統一構造化はで管理しやすいログの定義仕様のことアプリの場合、依存を追加するだけでアプリケーションログをいい感じに構造化したフォーマットのログにしてくれる。あとはそのままログをに突っ込むだけ。 ※ECS Logging Java Reference　 https://www.elastic.co/guide/en/ecs-logging/java/current/index.html

112. （ロギングの活用）（）でアプリケーションログのフォーマットを統一構造化はで管理しやすいログの定義仕様のことアプリの場合、依存を追加するだけでアプリケーションログをいい感じに構造化されたフォーマットのログにしてくれる。あとはそのままログをに突っ込むだけ。 ※ECS Logging Java Reference　 https://www.elastic.co/guide/en/ecs-logging/java/current/index.html ecs-logging-java <dependency> <groupId>co.elastic.logging</groupId> <artifactId>log4j2-ecs-layout</artifactId> <version>${ecs-logging-java.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j2</artifactId> </dependency>

113. （ロギングの活用） ecs-logging-java <dependency> <groupId>co.elastic.logging</groupId> <artifactId>log4j2-ecs-layout</artifactId> <version>${ecs-logging-java.version}</version> </dependency> ※実装がLogback, Log4j2, Log4j, JUL, JBoss Log Manager から選択できるがLog4j2だと構造化ロギングに対応してるので良さそう。

114. （ロギングの活用）例外情報もきちんと構造化タイムスタンプホスト名ログレベルログメッセージスレッド名例外クラス例外メッセージスタックトレース

115. （ロギングの活用）

116. ログレベル別ログ出力数ログレベル別（ロギングの活用）アプリケーション別ログ出力数アプリケーション別

117. （ロギングの活用） Exceptionクラス別ログ出力数 Exceptionクラス別開発中のDB failoverテスト

118. （ロギングの活用） WARNレベル/ERRORレベルのログ出力数が増加一時的に例外が発生その後、自動的に復旧その後、例外の発生なし開発中のDB failoverテスト

119. （ロギングの活用）

120. （ロギングの活用）決済結果別 HTTPステータス別決済手段別加盟店別ユーザエージェント別 API別リモートIP別処理時間エラーコード別

121. （ロギングの活用）リッチなダッシュボードを実現求めるダッシュボードから逆算してロギング設計をする

122. Spring Cloud Sleuthによってアプリログに出力されるトレースIDで検索可能

123. 複数のサーバにまたがる処理でも、どこの通信やSQLに時間がかかっていたか一目でわかる

124. Zipkin, Spring Cloud Sleuth <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> ※Spring Boot v2.4.0以降は spring-cloud-sleuth-zipkin spring.sleuth.sampler.probability: 1.0

125. Zipkin, Spring Cloud Sleuth <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> ※Spring Boot v2.4.0以降は spring-cloud-sleuth-zipkin spring.sleuth.sampler.probability: 1.0 Zipkinにトレースを送信する割合本番環境でも 1.0 (100%) を指定している

126. Zipkinのデータストアに Elasticsearchを指定してKibanaで独自ダッシュボードを作成

127. 処理時間がかかっているリクエストを特定

128. 特定したリクエストのトレースIDをクリックすると Zipkinへジャンプ

129. APIGateway ServiceA 決済機関内部システム

130. APIGateway ServiceA 決済機関内部システム内部システムがAPI-Gatewayを呼び出して応答されるまでの時間が長い（6.98秒）

131. APIGateway ServiceA 決済機関内部システム API-GatewayがServiceAを呼び出して応答されるまでの時間が長い（6.56秒）

132. APIGateway ServiceA 決済機関内部システム ServiceAが決済機関を呼び出して応答を待つ時間が長い（6.53秒）

133. APIGateway ServiceA 決済機関内部システム原因は決済機関のレスポンス待ち全体の処理時間 6.98秒に対して6.53秒を要していたことが視覚的に把握できる

134. APIGateway ServiceA 決済機関内部システム Zipkinのおかげで分散してしまっている各アプリケーションのログからトレースを追わずに済み、効率良く調査ができるようになった

135. サービス目線のモニタリング決済手段毎の OK数 / NG数を表示

136. サービス目線のモニタリング決済手段毎の OK数 / NG数を表示

137. サービス目線のモニタリング決済数取扱高前日比・傾向内訳分類

138. サービス目線のモニタリング決済数取扱高前日比・傾向内訳分類 XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX

139. サービス目線のモニタリング決済数取扱高前日比・傾向内訳分類 XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX加盟店のシステム障害加盟店のシステム障害

140. XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX 加盟店へリアルタイムに状況を共有、さらには加盟店自身も見落としていた障害を検知サービス目線のモニタリング

141. サービス目線のモニタリング決済数取扱高前日比・傾向内訳分類アプリをリリースするだけでプラットフォームが自動で監視対象に Metrics Logging Tracing + Biz

142. ● これまでの歩み

143. プラットフォーム導入の効果 Before After Release リリース作業手作業ワンクリックリリース品質人為的なミスの可能性あり自動化によりミスなしリリース時間 45分 5分 Observability ログ調査ログファイルから調査 Kibanaダッシュボードサーバメトリクス調査ログファイルから調査 Grafanaダッシュボードトレース調査なし Zipkinダッシュボード Resilience 障害時の自動復旧なし自動再起動スケールアウト手作業管理画面から数クリック

144. アーキテクチャのアップデートサービス開始時 2年経った現在 PaaS Platform Java Java 8 Java 11 Spring Boot v2.1.2 v2.3.5 Spring Cloud Greenwich. RELEASE Hoxton.SR8 ライブラリ Http Client RestTemplate WebClient ライブラリ CircuitBreaker Hystrix Resilience4J

145. サービスの広がりサービス開始時 2年経った現在システム数 1システム 3システム ⤴ App数 12アプリケーション 22アプリケーション ⤴ Appインスタンス数 45インスタンス 57インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 15名（開発ベンダ2社 6名含む） ⤴ このシステムの障害件数 - 0件

146. 本日のまとめ

147. 技術的なアップデートをしながらサービスの拡張や機能追加ができている。まとめ自分たちのシステムをプラットフォームから構築しサービスの運用開始から年間、大きな障害もなく運用することができた。リリース作業やログ調査も非常に効率良く運用できている。

148. さいごにサービス開始から2年間、大きな障害もなく運用することができましたが、歩みを止めることなく加盟店/エンドユーザの方々に高い品質のサービスを提供したい。堅牢、安全、1件1円間違えのない、障害に強いシステムを目指して

149. ご清聴ありがとうございました SBペイメントサービスはエンジニアを募集しています興味がある方は　　 @suzukijまで

CloudNativeな決済サービスの開発と2年間の歩み #sf_A4

Junya Suzuki

CloudNativeな決済サービスの開発と2年間の歩み #sf_A4