決済システムの内製化への旅- SpringとTASで作るクラウドネイティブなシステム開発

Spring Fest 2018登壇資料をベースに一部追加したもの
（2021-11-02 Springフレームワーク徹底解説セミナー）

Transcript

1. 決済システムの内製化への旅 - SpringとTASで作るクラウドネイティブなシステム開発 Springフレームワーク徹底解説セミナー Nov. 2 2021 Junya Suzuki (@suzukij), SB Payment Service, junya.suzuki03@g.softbank.co.jp
2. SBペイメントサービス株式会社 シニアアーキテクト 鈴木順也(@suzukij) 自己紹介 主な業務 ・新規サービスの開発 ・運用の効率化/改善 Java, Webシステムの開発に従事 元々は SIer のプログラマ フリーランスを経て5年前に現在の会社に転職
3. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 SBペイメントサービスの事業内容
4. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー（クレジットカード加盟 店契約会社）としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 SBペイメントサービスの事業内容
5. 今日お話すること • 内製化に至る道のり • Tanzu Application Service を選んだ理由 • 手に入れた開発/運用のカタチ ◦ アーキテクチャ ◦ CI / CD パイプライン ◦ Observability
6. 内製化に至る道のり
7. 2016年当時... サービス開発は全てベンダに任せており、 コードを書く自社のエンジニアは ０人だった。 当然開発のための環境も整っていない状態だった。
8. 2016年: システム運用の効率化を自分たちで 課題 運用の手作業が多い 手作業ゆえのミス 体制
9. 2016年: システム運用の効率化を自分たちで Spring Boot Selenium / Selenide 課題 支援ツールを内製 導入したもの 運用の手作業が多い 手作業ゆえのミス 運用作業を自動化 開発に必要な環境を整える 体制
10. 2016年: システム運用の効率化を自分たちで 課題 導入したもの 運用の手作業が多い 手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製 運用作業を自動化 体制 3名のエンジニアがJoin チームとして改善活動も加速
11. 2017年: ①サービス監視の質を高める サービス状況をすば やく把握、共有ができ ていなかった 課題 体制
12. 2017年: ①サービス監視の質を高める サービス状況をすば やく把握、共有ができ ていなかった 課題 監視用ダッシュボードを作成 導入したもの Elasticsearch Logstash Kibana 体制
13. 2017年: ②開発プロジェクトの支援を開始 課題 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難 体制
14. 2017年: ②開発プロジェクトの支援を開始 課題 アーキテクチャをSpringベースに 導入したもの モダンな開発 / 運用 　Spring Boot 　Spring Cloud 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難 CIをきちんと回す支援 体制
15. 2017年: ②開発プロジェクトの支援を開始 課題 導入したもの アーキテクチャをSpringベースに モダンな開発 / 運用 　Spring Boot 　Spring Cloud 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難 体制 さらに1名のエンジニアがJoin
16. 2016 - 2017年 • エンジニアチームの立ち上げ • 運用業務の改善を通してツールの内製化 • 開発案件にも支援として参加 2018年 いよいよ決済システムの内製がスタート
17. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 開発対象 オンライン決済サービス
18. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 導入実績 141,212 店舗 (2020年6月実績) ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 開発対象 オンライン決済サービス 取扱高 4兆0,347億円 (2020年実績)
19. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 API型 決済手段 40 種以上に対応 ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム 開発対象 オンライン決済サービス
20. 開発対象 オンライン決済サービス 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社 当社 加盟店システムと決済機関システムの間に位置す る自社だけでは完結しない Webシステム API型
21. 2018年: 決済システムの内製へ 新システムに求めるモノ • スピード感のある開発/リリース • 継続的な改善のサイクル • 監視が容易で障害に強いシステム 今までは… すべての案件毎に開発ベンダのチカラを借りて構築 （見積もり/契約/要件定義から検収まで長い道のり）
22. 2018年: 決済システムの内製へ 新システムに求めるモノ • スピード感のある開発/リリース • 継続的な改善のサイクル • 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 （見積もり/要件定義から検収まで長い道のり） 開発ベンダに頼りきっていてはスピード感のある開 発、小さな改善のサイクルが作れない。
23. 2018年: 決済システムの内製へ 新システムに求めるモノ • スピード感のある開発/リリース • 継続的な改善のサイクル • 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 （見積もり/要件定義から検収） 内製化によるスピード感のある開発 内製化による継続的な改善
24. 2018年: 決済システムの内製へ チーム体制 内製開発PJ さらに1名のエンジニアがJoin 6名のチーム体制
25. 2018年: 決済システムの内製へ チーム体制 内製開発PJ 槙さん (週1の技術支援)
26. 2018年: 決済システムの内製へ 導入したもの Tanzu Application Service（TAS）を中心とした クラウドネイティブなプラットフォーム Concourse CI Tanzu Application Service
27. Tanzu Application Service (TAS) を選んだ理由 Tanzu Application Service
28. プラットフォームに求めるもの リリースの改善 ・リリース時間の短縮 ・ゼロダウンタイムリリース ・ワンクリックリリース ・人的ミスの撲滅 クラウドのフル活用 ・スケーラブル/オートスケール ・セルフヒーリング 　　コンテナの動的な配置 　　障害時のコンテナ/アプリ自動再起動
29. やっぱりKubernetes？？ エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ ・プラットフォーム構築と検証に必要な期間 ・数人のチームでは体制的にも厳しそう OR PaaS
30. やっぱりKubernetes？？ エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ ・プラットフォーム構築までの期間 ・数人のチームでは体制的にも厳しそう OR PaaS 既に確立されたプラットフォームが欲しい ・業務コードの実装に集中したい ・コードをすぐに実行できる環境が欲しい
31. やっぱりKubernetes？？ OR PaaS ウチはこっち 既に確立されたプラットフォームが欲しい ・業務コードの実装に集中したい ・コードをすぐに実行できる環境が欲しい
32. PaaS Public PaaS OR 　　Private PaaS 決済サービスのエンタープライズ領域での利用であるた め Public PaaS はセキュリティ的にも抵抗が強く Private PaaS一択。
33. PaaS ウチはこっち Public PaaS OR 　　Private PaaS 決済サービスのエンタープライズ領域での利用であるた め Public PaaS はセキュリティ的にも抵抗が強く Private PaaS一択。
34. 最終的に選んだのは… PaaS • Java/Spring アプリケーションとの親和性 • プラットフォームの導入/運用のサポート • cf push コマンドによるアプリリリース Tanzu Application Service
35. 最終的に選んだのは… • Java/Spring アプリケーションとの親和性 • プラットフォームの導入/運用のサポート • cf push コマンドによるアプリリリース PaaS Tanzu Application Service Buildpack という仕組みでソースコードからコンテナイメージを作 成してくれる 開発者は Dockerfile を書く必要なし。 cf push と Buildpackにおまかせ。
36. 開発プロジェクトのチーム体制と責任分界
37. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware プラットフォーム運用者 Ops 2名 Runtime Tanzu Application Service
38. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 Tanzu Application Service
39. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 プラットフォームの構築 / 管 理 に専念 Tanzu Application Service
40. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 業務の設計 / 実装に集中 プラットフォーム運用者 Ops アプリケーション開発者 Dev 4名 Tanzu Application Service
41. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 12 Factor App AppをPaaSに載せる制約は 12 Factor App のみ ベンダーロックインはなし プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 4名 Tanzu Application Service
42. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 4名 Tanzu Application Service 技術支援(週1)
43. 手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
44. syslog+TLS Logstash Elasticsearch Kibana cf push Concourse Prometheus Grafana git push 全体のアーキテクチャ cf create-service cf bind-service Tanzu Application Service
45. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
46. アプリケーション構成（同期 加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service
47. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C オンラインショッピングサイト 通販サイト、ゲーム、電子書籍、 チケット、不動産、その他 アプリケーション構成（同期 加盟店 ➡ 決済機関）
48. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 当社 決済システム アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
49. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関システム クレジット、コンビニ支払い、キャリア決済、 プリペイドカード、その他 アプリケーション構成（同期 加盟店 ➡ 決済機関）
50. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Appはマイクロサービスの構成です べてTAS上に配置 アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
51. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C すべてのAppは Java/Spring Boot で実装 アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
52. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service API Gateway 決済機関毎のビジネスロジックが実装さ れているServiceへルーティング
53. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
54. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 加盟店や決済機関は当然、コントロール範囲外 アプリケーション構成（同期 加盟店 ➡ 決済機関）
55. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service システム間通信には Resilience4j という Circuit Breakerを導入 Resilience4j Resilience4j Resilience4j Resilience4j
56. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breakerがない状態で 決済機関Aで障害が発生した場合…
57. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service レスポンス遅延、タイムアウト
58. アプリケーション構成（同期 加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Service A に障害が伝播 処理のブロック、スレッド枯渇
59. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service API Gateway に障害が伝播 処理のブロック、スレッド枯渇
60. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service API Gateway に障害が伝播 処理のブロック、スレッド枯渇
61. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関A起因の障害にも関わらず 関係のない決済機関BCへ影響が出てしまう アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
62. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breaker があれば 特定の決済機関で障害が発生しても Resilience4j Resilience4j Resilience4j Resilience4j
63. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 障害の伝播を防いでくれるため 他の決済機関へ影響を及ぼす心配がない アプリケーション構成（同期 加盟店 ➡ 決済機関） Resilience4j Resilience4j Resilience4j Resilience4j
64. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Resilience4j Resilience4j Resilience4j Resilience4j Circuit Brakerにより耐障害性に優 れたアプリケーションを実現
65. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
66. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
67. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
68. アプリケーション構成（非同期 決済機関 ➡ 加盟店） 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 を使用
69. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
70. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 特定の加盟店で障害が発生した場合
71. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Dead Letter Queue と呼ばれるキューに 退避して、後に再送
72. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Circuit Breakerにより、他の加盟店に影響を 及ぼさない Hystrix
73. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
74. CI / CD パイプライン Concourse https://concourse-ci.org/
75. https://concourse-ci.org/ Concourse CI / CD パイプライン
76. Concourse - ジョブ一覧画面
77. Concourse - パイプライン画面
78. パイプライン全体のジョブ構成 ジョブ設定は 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
79. リポジトリの更新がトリガ Concourse - パイプライン画面
80. Concourse - パイプライン画面
81. Concourse - パイプライン画面
82. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境
83. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 各種ブランチへの更新がトリガ
84. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 Javaの各種バージョンでテスト アップデートの弊害を早めに検知
85. Concourse 開発から本番リリースまでのパイプライン テスト環境 開発環境 本番環境 SonarQubeによるコード解析 コードの品質をいつでも確認できるようにしておく
86. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境
87. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境
88. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境 CIによる開発サイクル
89. Concourse 開発から本番リリースまでのパイプライン 開発環境 本番環境 テスト環境 masterブランチへのマージで Nexus RELEASEリポジトリへデプロイ 本番環境リリースへの準備が完了
90. Concourse 開発から本番リリースまでのパイプライン 本番環境 ワンクリックリリースによるCD Nexusのリリースリポジトリの成果物が本番環境に適用される Blue-Green Deployによってサービスへの影響なくリリースが可能
91. Concourse 開発から本番リリースまでのパイプライン 本番環境 トラブル時の切り戻しの際も数クリックのみの対応 ※幸いにも まだやったことないです
92. Concourse 開発から本番リリースまでのパイプライン 本番環境 リリースや切り戻し手順がシンプルなため テレワークで自宅からもリリースが可能
93. 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability
94. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
95. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
96. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
97. Observability ※Metrics, tracing, and logging　 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
98. Platformの監視 • 全VMのメトリクス • 全コンテナのメトリクス • Cloud Foundryの各コンポーネントのメトリクス • ミドルウェアのメトリクス ◦ RabbitMQ / MySQL / Concourse / Elastic Stack Applicationの監視 • 全Spring Bootアプリ(Micrometer)のメトリクス Grafanaでの監視対象 Metrics 30種以上のダッシュボード
99. Grafana(Micrometer) Metrics
100. 今までログから可視化していた情報が Grafanaでいつでも確認可能に ・CPU ・ヒープ（各領域ごと） ・スレッド ・GC（回数、時間） ・クラスローダ 開発者はPrometheusの設定を意識することは なくリリースしたら自動でアプリケーションを監視 する仕組み Grafana(Micrometer) Metrics
101. Kibana（アクセスログ） Logging
102. アクセスログ一覧 レスポンスタイム Percentile アプリ別 アクセス数 ステータスコード別 アクセス数 レスポンスタイム AVG Kibana（アクセスログ） Logging
103. Kibana（アプリケーションログ） Logging
104. ログレベル別 ログ出力数 アプリケーションログ一覧 アプリ別 ログ出力数 Kibana（アプリケーションログ） Logging
105. 開発者は Elastic Stack を意識せず、標準出力にログを出力 するだけで良い。 Kibana（アプリケーションログ） Logging
106. Zipkin Tracing
107. Zipkin Tracing Spring Cloud Sleuthによって アプリログに出力される トレースIDで検索可能
108. 複数のサーバにまたがる処理でも、 どこの通信やSQLに時間がかかっていたか一目でわ かる Zipkin Tracing
109. サービス目線のモニタリング 決済手段毎の OK数 / NG数を表示 Biz
110. 決済数 取扱高 前日比・傾向 内訳 分類 xx,xxx xxx,xxx xx,xxx,xxx,xxx x,xxx,xxx,xxx サービス目線のモニタリング Biz
111. サービス目線のモニタリング 決済数 取扱高 前日比・傾向 内訳 分類 xx,xxx xxx,xxx xx,xxx,xxx,xxx x,xxx,xxx,xxx アプリをリリースするだけで プラットフォームが自動で監視対象に Metrics Logging Tracing + Biz
112. • これまでの歩み
113. プラットフォーム導入の効果 Before After Release リリース作業 手作業 ワンクリック リリース品質 人為的なミスの可能性あり 自動化によりミスなし リリース時間 45分 5分 Observability ログ調査 ログファイルから調査 Kibanaダッシュボード サーバメトリクス調査 ログファイルから調査 Grafanaダッシュボード トレース調査 なし Zipkinダッシュボード Resilience 障害時の自動復旧 なし 自動再起動 スケールアウト 手作業 管理画面から数クリック
114. アーキテクチャのアップデート サービス開始時 3年経った現在 PaaS Platform Java Java 8 Java 11 Spring Boot v2.1.2 v2.5.4 Spring Cloud Greenwich. RELEASE 2020.0.3 ライブラリ Http Client RestTemplate WebClient ライブラリ CircuitBreaker Hystrix Resilience4J
115. サービスの広がり サービス開始時 3年経った現在 システム数 1システム 4システム ⤴ App数 12アプリケーション 36アプリケーション ⤴ Appインスタンス数 45インスタンス 80インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 15名（開発ベンダ2社 6名含む） ⤴ このシステムの障害件数 - 0件
116. 本日のまとめ
117. ここまでの歩み • 開発チームの立ち上げ • 運用業務の改善活動 • PCFを中心としたプラットフォームの導入 / 構築 • 決済システム内製 ◦ 耐障害性に優れたシステム ◦ 監視の容易なシステム ◦ 継続的なビルド/リリース が可能なシステム
118. 内製化に取り組んでみて 外注に頼りきったサービス開発を積み重ねてもプラットフォーム は構築できない。 内製という技術の舵取りをおこなうからこそ プラットフォームの構築/運用が可能となる。 そしてその強力な基盤があるおかげで少人数でも サービス開発に注力できその後の3年間安定運用ができた。
119. We are hiring! ご清聴ありがとうございました SBペイメントサービスは エンジニアを募集しています 興味がある方は　　@suzukij まで
121. SpringFest 2020 登壇資料 CloudNativeな決済サービスの開発と 2年間の歩み https://www.slideshare.net/JunyaSuzuki1/cloudnative2-sfa4 関連資料 Pivotal.IO 2019 登壇資料 決済システム内製化に向けた プラットフォーム構築 PCF・BOSHによるオブザーバブルプラットフォーム https://www.slideshare.net/DaichiKimura3/pcfbosh-156082821 アプリケーション開発チーム プラットフォームチーム