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

Spring Fest 2020登壇資料

Transcript

1. CloudNativeな決済サービスの 開発と2年間の歩み Spring Fest 2020 #jsug #sf_A4 Dec 17 2020 Junya Suzuki (@suzukij), SB Payment Service, junya.suzuki03@g.softbank.co.jp
2. SBペイメントサービス株式会社 シニアアーキテクト 鈴木順也(@suzukij) 自己紹介 主な業務 ・新規サービスの開発 ・運用の効率化/改善 Java, Webシステムの開発に従事 元々は SIer のプログラマ フリーランスを経て4年前に現在の会社に転職
3. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカード機能 を有しております。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 SBペイメントサービスの事業内容
4. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカード機能 を有しております。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 SBペイメントサービスの事業内容
5. 今日お話すること • 決済サービス/システム概要 • 安定した開発/運用を支える取り組み ◦ プラットフォーム / 全体のアーキテクチャ ◦ アーキテクチャ ◦ CI / CD パイプライン ◦ Observability • これまでの歩み
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. • 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
15. syslog+TLS Logstash Elasticsearch Kibana cf push Concourse Prometheus Grafana git push 全体のアーキテクチャ cf create-service cf bind-service Tanzu Application Service
16. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 • 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
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 API Gateway 決済機関毎のビジネスロジックが実装さ れている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 Service API Gateway に障害が伝播 処理のブロック、スレッド枯渇
31. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service API 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
37. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
38. アプリケーション構成（非同期 決済機関 ➡ 加盟店） 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 を使用
40. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
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. CircuitBreaker (Hystrix -> Resilience4J) 2018/11から maintenance mode Resilience4J Hystrix • CircuitBreaker • Bulkhead • RateLimiter
48. CircuitBreaker (Resilience4J) API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J CircuitBreaker 決済機関のシステムエラー率が100%の 状態で2分継続したらサーキットオープン
49. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J CircuitBreaker (Resilience4J)
50. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J エラーしきい値がデフォルト50%だが弊社 は100%に設定 CircuitBreaker (Resilience4J)
51. どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定 たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー 決済機関障害発生 CircuitBreaker (Resilience4J)
52. どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定 たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー 決済機関障害発生 サーキットオープン サーキットオープンによる 機会損失が発生 CircuitBreaker (Resilience4J)
53. 決済サービスでは1件でも正常に取引されているトランザクションがある限りサーキッ トオープンにはしたくない ◆決済完了　◆決済機関システムエラー 決済機関障害発生 CircuitBreaker (Resilience4J)
54. 決済サービスでは1件でも正常に取引されているトランザクションがある場合はサー キットオープンしたくない とはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社へ の障害の伝播を防ぎたい 決済機関障害発生 ◆決済完了　◆決済機関システムエラー　 タイムアウトやレスポンス遅延に よる障害伝播の恐れ CircuitBreaker (Resilience4J)
55. 決済サービスでは1件でも正常に取引されているトランザクションがある場合はサー キットオープンしたくない とはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社へ の障害の伝播を防ぎたい ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー 決済機関障害発生 サーキットオープンにより即エラーを 返すことで障害伝播を防ぐ CircuitBreaker (Resilience4J)
56. Bulkhead (Resilience4J) API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J Bulkhead（並列処理数の制限） 同時接続数が設定値を超過したらリジェクト
57. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J Bulkhead 同時接続数が設定値を超過したらリジェクト Bulkhead (Resilience4J)
58. Tanzu Application Service Bulkhead (Resilience4J) Service A 決済機関 A Bulkhead 1 2 3 4 5 reject
59. Tanzu Application Service Bulkhead (Resilience4J) Service A 決済機関 A Bulkhead 1 2 3 4 5 reject ウチのシステムは負荷に弱いので 同時接続数 5 でお願いします
60. Tanzu Application Service Bulkhead (Resilience4J) Service A 決済機関 A Bulkhead Bulkheadの並列実行数に5を設定した場合、 決済機関Aへの同時接続数 5本が上限となる 同時接続数が5以上はリジェクトとして扱われる Bulkhead 1 2 3 4 5 reject
61. Tanzu Application Service Bulkhead (Resilience4J) Service A 決済機関 A Bulkhead 1 2 3 4 5 reject Bulkheadの設定を導入し 決済機関に限界以上の負荷を与えないように
62. 追加開発の新規アプリケーションから WebClientで実装、リリース済 Http Client (RestTemplate -> WebClient) RestTemplateのJavadoc 「メンテナンスモードのためWebClientの使 用を検討してください」 ※RestTemplateはまだ非推奨とはなっていない
63. 移行で発生した問題1 • 接続タイムアウト、Read/Writeタイムアウトの設定 ◦ reactor-nettyのTcpClientにそれぞれタイムアウトを設定 Http Client (RestTemplate -> WebClient)
64. Http Client (RestTemplate -> WebClient) 移行で発生した問題2 • レスポンスのサイズが256KBを超過すると例外が発生 ◦ codecsのmaxInMemorySizeを設定 org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer
65. Http Client (RestTemplate -> WebClient) 移行で発生した問題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. Http Client (RestTemplate -> WebClient) 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 外部ベンダさんの協力を得ながらサービスを横展開す ることができた。 自分達は新規技術や新方式を採用したアプリケーショ ンの検証/開発に注力することができた。
72. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 • 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
73. CI / CD パイプライン Concourse https://concourse-ci.org/
74. https://concourse-ci.org/ Concourse CI / CD パイプライン
75. Concourse - ジョブ一覧画面
76. Concourse - パイプライン画面
77. パイプライン全体のジョブ構成 ジョブ設定は YAMLファイル で管理 Concourse - パイプライン画面 - 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. リポジトリの更新がトリガ Concourse - パイプライン画面
79. Concourse - パイプライン画面
80. Concourse - パイプライン画面
81. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境
82. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 各種ブランチへの更新がトリガ
83. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 Javaの各種バージョンでテスト アップデートの弊害を早めに検知
84. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 SonarQubeによるコード解析 コードの品質をいつでも確認できるようにしておく
85. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境
86. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境
87. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境 CIによる開発サイクル
88. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境 masterブランチへのマージで Nexus RELEASEリポジトリへデプロイ 本番環境リリースへの準備が完了
89. Concourse 開発から本番リリースまでのパイプライン 本番環境 ワンクリックリリースによるCD Nexusのリリースリポジトリの成果物が本番環境に適用される Blue-Green Deployによってサービスへの影響なくリリースが可能
90. Concourse 開発から本番リリースまでのパイプライン 本番環境 トラブル時の切り戻しの際も数クリックのみの対応 ※幸いにも まだやったことないです
91. Concourse 開発から本番リリースまでのパイプライン 本番環境 リリースや切り戻し手順がシンプルなため テレワークで自宅からもリリースが可能
92. によるパフォーマンステスト API Gateway Service A Service B Service C 決済機関 B Mock 決済機関 A Mock 決済機関 C Mock Tanzu Application Service
93. • Load test • Soak test によるパフォーマンステスト
94. Load Test - 想定の20倍のスループットを目標 問題 原因 Webスレッドプールが枯渇 Webスレッドプール数の設定ミス HTTP送信時にスループットが上がらない HttpClient4 の PoolingHttpClientConnectionManager のプール数の設定漏れ SQLの実行時のスループットが上がらない HikariCP DBコネクションプールの設定ミス Circuit Breakerの想定外のサーキットオープン Hystrixのチューニングミス RabbitMQのメッセージキューイングが停止 RabbitMQのメモリ枯渇（スケールアップ対応） RabbitMQのConsumerのスループットが上がらない StreamListenerのワーカースレッド数が不足 アプリケーション全体の負荷限界 アプリケーションインスタンス数の不足 ※PaaSというかBuildpackのおかげでJVMのチューニングは不要だった 　（いつも必ず対応するやつ）
95. Soak Test (1週間, 168時間)
96. Load test and E2E test by 開発期間中にはJMeterによるロードテストとE2Eテストを毎日自動で実行 し、結果のスクリーンショットをSlackで通知 Report html cf push
97. Load test and E2E test by During development, JMeter tests are automatically executed every day. Notify Slack of report screenshot. パフォーマンステストは開発期間中に何度も繰り 返し実行して改善を続けることが大事
98. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 • 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
99. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
100. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
101. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
102. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
103. Platformの監視 • 全VMのメトリクス • 全コンテナのメトリクス • TASの各コンポーネントのメトリクス • ミドルウェアのメトリクス ◦ RabbitMQ / MySQL / Concourse / Elastic Stack Applicationの監視 • 全Spring Bootアプリ(Micrometer)のメトリクス Grafanaでの監視対象 Metrics 30種以上のダッシュボード
104. Grafana(Micrometer) Metrics
105. Grafana(Micrometer) Metrics Micrometer <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>
106. 開発者はPrometheusの設定を意識することは なくリリースしたら自動でアプリケーションを監視 する仕組み Grafana(Micrometer) Metrics 今までログから可視化していた情報が Grafanaでいつでも確認可能に ・CPU ・ヒープ（各領域ごと） ・スレッド ・GC（回数、時間） ・クラスローダ ・DBコネクションプール
107. Kibana（アクセスログ） Logging
108. アクセスログ一覧 レスポンスタイム Percentile アプリ別 アクセス数 ステータスコード別 アクセス数 レスポンスタイム AVG Kibana（アクセスログ） Logging
109. Kibana（アプリケーションログ） Logging
110. ログレベル別 ログ出力数 アプリケーションログ一覧 アプリ別 ログ出力数 Kibana（アプリケーションログ） Logging
111. 開発者は Elastic Stack を意識せず、標準出力にログを出力 するだけで良い。 Kibana（アプリケーションログ） Logging
112. Kibana（ECSロギングの活用） Logging Elastic Common Schema（ECS）で アプリケーションログのフォーマットを統一 / 構造化 ECSはElasticsearchで管理しやすいログの定義/仕様のこと Spring Bootアプリの場合、依存を追加するだけでアプリケーション ログをいい感じに構造化したJSONフォーマットのログにしてくれ る。 あとはそのままログをElasticsearchに突っ込むだけ。 ※ECS Logging Java Reference　 https://www.elastic.co/guide/en/ecs-logging/java/current/index.html
113. Kibana（ECSロギングの活用） Logging Elastic Common Schema（ECS）で アプリケーションログのフォーマットを統一 / 構造化 ECSはElasticsearchで管理しやすいログの定義/仕様のこと Spring Bootアプリの場合、依存を追加するだけでアプリケーション ログをいい感じに構造化されたJSONフォーマットのログにしてくれ る。 あとはそのままログをElasticsearchに突っ込むだけ。 ※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>
114. Kibana（ECSロギングの活用） Logging 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だと構造化ロギングに対 応してるので良さそう。
115. Kibana（ECSロギングの活用） Logging 例外情報もきちんと構造化 タイムスタンプ ホスト名 ログレベル ログメッセージ スレッド名 例外クラス 例外メッセージ スタックトレース
116. Kibana（ECSロギングの活用） Logging
117. ログレベル別 ログ出力数 ログレベル別 Kibana（ECSロギングの活用） Logging アプリケーション別 ログ出力数 アプリケーション別
118. Kibana（ECSロギングの活用） Logging Exceptionクラス別 ログ出力数 Exceptionクラス別 開発中のDB failoverテスト
119. Kibana（ECSロギングの活用） Logging WARNレベル/ERRORレベルのロ グ出力数が増加 一時的に例外が発生 その後、自動的に復旧 その後、例外の発生なし 開発中のDB failoverテスト
120. Kibana（ECSロギングの活用） Logging
121. Kibana（ECSロギングの活用） Logging 決済結果別 HTTPステータス別 決済手段別 加盟店別 ユーザエージェント別 API別 リモートIP別 処理時間 エラーコード別
122. Kibana（ECSロギングの活用） Logging リッチなダッシュボードを実現 求めるダッシュボードから逆算してロギン グ設計をする
123. Zipkin Tracing
124. Zipkin Tracing Spring Cloud Sleuthによって アプリログに出力される トレースIDで検索可能
125. 複数のサーバにまたがる処理でも、 どこの通信やSQLに時間がかかっていたか一目でわ かる Zipkin Tracing
126. Zipkin Tracing 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
127. 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 Tracing Zipkinにトレースを送信する割合 本番環境でも 1.0 (100%) を指定している
128. Zipkin Tracing Zipkinのデータストアに Elasticsearchを指定してKibanaで 独自ダッシュボードを作成
129. Zipkin Tracing 処理時間がかかっているリクエストを特定
130. Zipkin Tracing 特定したリクエストのトレースIDをクリックすると Zipkinへジャンプ
131. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム トレース情報
132. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム 内部システムがAPI-Gatewayを呼び出して応 答されるまでの時間が長い（6.98秒）
133. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム API-GatewayがServiceAを呼び出して応答さ れるまでの時間が長い（6.56秒）
134. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム ServiceAが決済機関を呼び出して応答を待つ 時間が長い（6.53秒）
135. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム 原因は決済機関のレスポンス待ち 全体の処理時間 6.98秒に対して6.53秒を要 していたことが視覚的に把握できる
136. Zipkin Tracing API Gateway Service A 決 済 機 関 内 部 シ ス テ ム Zipkinのおかげで分散してしまっている各アプリケー ションのログからトレースを追わずに済み、効率良く調 査ができるようになった
137. サービス目線のモニタリング Biz 決済手段毎の OK数 / NG数を表示
138. サービス目線のモニタリング Biz 決済手段毎の OK数 / NG数を表示
139. サービス目線のモニタリング Biz 決済数 取扱高 前日比・傾向 内訳 分類 xx,xxx xxx,xxx xx,xxx,xxx,xxx x,xxx,xxx,xxx
140. サービス目線のモニタリング Biz 決済数 取扱高 前日比・傾向 内訳 分類 XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX
141. サービス目線のモニタリング Biz 決済数 取扱高 前日比・傾向 内訳 分類 XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX 加盟店の システム障害 加盟店の システム障害
142. XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX 加盟店へリアルタイムに状況を共有、 さらには加盟店自身も見落としていた障害を検知 サービス目線のモニタリング Biz
143. サービス目線のモニタリング 決済数 取扱高 前日比・傾向 内訳 分類 xx,xxx xxx,xxx xx,xxx,xxx,xxx x,xxx,xxx,xxx アプリをリリースするだけで プラットフォームが自動で監視対象に Metrics Logging Tracing + Biz
144. • これまでの歩み
145. プラットフォーム導入の効果 Before After Release リリース作業 手作業 ワンクリック リリース品質 人為的なミスの可能性あり 自動化によりミスなし リリース時間 45分 5分 Observability ログ調査 ログファイルから調査 Kibanaダッシュボード サーバメトリクス調査 ログファイルから調査 Grafanaダッシュボード トレース調査 なし Zipkinダッシュボード Resilience 障害時の自動復旧 なし 自動再起動 スケールアウト 手作業 管理画面から数クリック
146. アーキテクチャのアップデート サービス開始時 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
147. サービスの広がり サービス開始時 2年経った現在 システム数 1システム 3システム ⤴ App数 12アプリケーション 22アプリケーション ⤴ Appインスタンス数 45インスタンス 57インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 15名（開発ベンダ2社 6名含む） ⤴ このシステムの障害件数 - 0件
148. 本日のまとめ
149. 技術的なアップデートをしながらサービスの拡張や機能追加がで きている。 まとめ 自分たちのシステムをプラットフォームから構築しサービスの運 用開始から2年間、大きな障害もなく運用することができた。 リリース作業やログ調査も非常に効率良く運用できている。
150. さいごに サービス開始から2年間、大きな障害もなく運用することができ ましたが、歩みを止めることなく加盟店/エンドユーザの方々に 高い品質のサービスを提供したい。 堅牢、安全、1件1円間違えのない、 障害に強いシステムを目指して
151. We are hiring! ご清聴ありがとうございました SBペイメントサービスは エンジニアを募集しています 興味がある方は　　 @suzukijまで