決済システムの内製化への旅- SpringとPCFで作るクラウドネイティブなシステム開発 / A Journey to Developing an In-House Payment System

Slide 1

Slide 1 text

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 CloudNative Days Tokyo 2019 #CNDT2019 July 23 2019 Junya Suzuki (@suzukij), SB Payment Service, junya.suzuki03@g.softbank.co.jp

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

今日お話すること ● 内製化に至る道のり ● Pivotal Cloud Foundry を選んだ理由 ● 手に入れた開発/運用のカタチ ○ アーキテクチャ ○ CI / CD パイプライン ○ Observability

Slide 6

Slide 6 text

内製化に至る道のり

Slide 7

Slide 7 text

2016年当時... サービス開発は全てベンダに任せており、コードを書く自社のエンジニアは０人だった。当然開発のための環境も整っていない状態だった。

Slide 8

Slide 8 text

2016年: システム運用の効率化を自分たちで課題運用の手作業が多い手作業ゆえのミス体制

Slide 9

Slide 9 text

2016年: システム運用の効率化を自分たちで Spring Boot Selenium / Selenide 課題支援ツールを内製導入したもの運用の手作業が多い手作業ゆえのミス運用作業を自動化開発に必要な環境を整える体制

Slide 10

Slide 10 text

2016年: システム運用の効率化を自分たちで課題導入したもの運用の手作業が多い手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製運用作業を自動化体制 3名のエンジニアがJoin チームとして改善活動も加速

Slide 11

Slide 11 text

2017年: ①サービス監視の質を高めるサービス状況をすばやく把握、共有ができていなかった課題体制

Slide 12

Slide 12 text

2017年: ①サービス監視の質を高めるサービス状況をすばやく把握、共有ができていなかった課題監視用ダッシュボードを作成導入したもの Elasticsearch Logstash Kibana 体制

Slide 13

Slide 13 text

2017年: ②開発プロジェクトの支援を開始課題古いアーキテクチャ開発/リリースが高コストシステム監視が困難体制

Slide 14

Slide 14 text

2017年: ②開発プロジェクトの支援を開始課題アーキテクチャをSpringベースに導入したものモダンな開発 / 運用　Spring Boot 　Spring Cloud 古いアーキテクチャ開発/リリースが高コストシステム監視が困難 CIをきちんと回す支援体制

Slide 15

Slide 15 text

2017年: ②開発プロジェクトの支援を開始課題導入したものアーキテクチャをSpringベースにモダンな開発 / 運用　Spring Boot 　Spring Cloud 古いアーキテクチャ開発/リリースが高コストシステム監視が困難体制さらに1名のエンジニアがJoin

Slide 16

Slide 16 text

2016 - 2017年 ● エンジニアチームの立ち上げ ● 運用業務の改善を通してツールの内製化 ● 開発案件にも支援として参加 2018年いよいよ決済システムの内製がスタート

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

2018年: 決済システムの内製へ新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム今までは… すべての案件毎に開発ベンダのチカラを借りて構築（見積もり/契約/要件定義から検収まで長い道のり）

Slide 22

Slide 22 text

2018年: 決済システムの内製へ新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム今までは… 案件毎に開発ベンダさんのチカラを借りて構築（見積もり/要件定義から検収まで長い道のり）開発ベンダに頼りきっていてはスピード感のある開発、小さな改善のサイクルが作れない。

Slide 23

Slide 23 text

2018年: 決済システムの内製へ新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム今までは… 案件毎に開発ベンダさんのチカラを借りて構築（見積もり/要件定義から検収）内製化によるスピード感のある開発内製化による継続的な改善

Slide 24

Slide 24 text

2018年: 決済システムの内製へチーム体制内製開発PJ さらに1名のエンジニアがJoin 6名のチーム体制

Slide 25

Slide 25 text

2018年: 決済システムの内製へ導入したもの Pivotal Cloud Foundry（PCF）を中心としたクラウドネイティブなプラットフォーム Concourse CI

Slide 26

Slide 26 text

Pivotal Cloud Foundry (PCF) を選んだ理由

Slide 27

Slide 27 text

プラットフォームに求めるものリリースの改善・リリース時間の短縮・ゼロダウンタイムリリース・ワンクリックリリース・人的ミスの撲滅クラウドのフル活用・スケーラブル/オートスケール・セルフヒーリング　　コンテナの動的な配置　　障害時のコンテナ/アプリ自動再起動

Slide 28

Slide 28 text

やっぱりKubernetes？？エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ・プラットフォーム構築までの期間・数人のチームでは体制的にも厳しそう OR PaaS

Slide 29

Slide 29 text

やっぱりKubernetes？？エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ・プラットフォーム構築までの期間・数人のチームでは体制的にも厳しそう OR PaaS 既に確立されたプラットフォームが欲しい・業務コードの実装に集中したい・コードをすぐに実行できる環境が欲しい

Slide 30

Slide 30 text

やっぱりKubernetes？？ OR PaaS ウチはこっち既に確立されたプラットフォームが欲しい・業務コードの実装に集中したい・コードをすぐに実行できる環境が欲しい

Slide 31

Slide 31 text

PaaS Public PaaS OR 　　Private PaaS 決済サービスのエンタープライズ領域での利用であるため Public PaaS はセキュリティ的にも抵抗が強く Private PaaS一択。

Slide 32

Slide 32 text

PaaS ウチはこっち Public PaaS OR 　　Private PaaS 決済サービスのエンタープライズ領域での利用であるため Public PaaS はセキュリティ的にも抵抗が強く Private PaaS一択。

Slide 33

Slide 33 text

最終的に選んだのは… PaaS ● Java/Spring アプリケーションとの親和性 ● プラットフォームの導入/運用のサポート ● cf push コマンドによるアプリリリース

Slide 34

Slide 34 text

最終的に選んだのは… ● Java/Spring アプリケーションとの親和性 ● プラットフォームの導入/運用のサポート ● cf push コマンドによるアプリリリース Buildpack という仕組みでソースコードからコンテナイメージを作成してくれる開発者は Dockerfile を書く必要なし。 cf push と Buildpackにおまかせ。 PaaS

Slide 35

Slide 35 text

開発プロジェクトのチーム体制と責任分界

Slide 36

Slide 36 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware プラットフォーム運用者 Ops 2名 Runtime

Slide 37

Slide 37 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application アプリケーション開発者 Dev 4名プラットフォーム運用者 Ops 2名

Slide 38

Slide 38 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application アプリケーション開発者 Dev 4名プラットフォーム運用者 Ops 2名プラットフォームの構築 / 管理に専念

Slide 39

Slide 39 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 業務の設計 / 実装に集中プラットフォーム運用者 Ops アプリケーション開発者 Dev 4名

Slide 40

Slide 40 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 12 Factor App AppをPaaSに載せる制約は 12 Factor App のみベンダーロックインはなしプラットフォーム運用者 Ops 2名アプリケーション開発者 Dev 4名

Slide 41

Slide 41 text

手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability

Slide 42

Slide 42 text

syslog+TLS Logstash Elasticsearch Kibana cf push Concourse Prometheus Grafana git push 全体アーキテクチャ cf create-service cf bind-service

Slide 43

Slide 43 text

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発手に入れた開発/運用のカタチ ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD パイプライン ➢ Observability

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Concourse - トップ画面

Slide 67

Slide 67 text

Concourse - パイプライン画面

Slide 68

Slide 68 text

Concourse 開発から本番リリースまでのパイプライン

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

テスト環境リリース本番環境リリース CI による開発サイクルユニットテスト/静的コード解析/カバレッジ計測ワンクリックリリースによる CD 　サービスのゼロダウンタイムリリース Concourse 開発から本番リリースまでのパイプライン

Slide 71

Slide 71 text

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Platformの監視 ● 全VMのメトリクス ● 全コンテナのメトリクス ● Cloud Foundryの各コンポーネントのメトリクス ● ミドルウェアのメトリクス ○ RabbitMQ / MySQL / Concourse / Elastic Stack Applicationの監視 ● 全Spring Bootアプリ(Micrometer)のメトリクス Grafanaでの監視対象 Metrics 30種以上のダッシュボード

Slide 77

Slide 77 text

Grafana(Micrometer) Metrics

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Kibana（アクセスログ） Logging

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Kibana（アプリケーションログ） Logging

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

Zipkin Tracing

Slide 85

Slide 85 text

アプリログに出力されるトレースIDで検索可能 Zipkin Tracing

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

本日のまとめ

Slide 91

Slide 91 text

ここまでの歩み ● 開発チームの立ち上げ ● 運用業務の改善活動 ● PCFを中心としたプラットフォームの導入 / 構築 ● 決済システム内製 ○ 耐障害性に優れたシステム ○ 監視の容易なシステム ○ 継続的なビルド/リリースが可能なシステム

Slide 92

Slide 92 text

内製化に取り組んでみて外注に頼りきったサービス開発を積み重ねてもプラットフォームは構築できない。内製という技術の舵取りをおこなうからこそプラットフォームの構築/運用が可能となる。そしてその強力な基盤があるおかげで少人数でもサービス開発に注力できその後の安定運用ができた。

Slide 93

Slide 93 text

さいごに開発チームの組織を立ち上げ、内製開発をスタートし無事リリースを迎えたが今後も新たなサービス開発と運用は続いていく。さらなるCloudNativeなシステムを目指しつつ加盟店/エンドユーザの方々に高い品質のサービスを提供したい。堅牢、安全、1件1円間違えない、障害に強いシステムを目指して

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

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