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

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

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

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

5.
今日お話すること
● 内製化に至る道のり
● Pivotal Cloud Foundry を選んだ理由
● 手に入れた開発/運用のカタチ
○ アーキテクチャ
○ 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型
導入実績 約 111,742 店舗
(2019年5月実績)
ECサイト向けに様々な決済手段を提供
加盟店に決済APIを提供するシステム
開発対象
オンライン決済サービス
取扱高 2兆9,453 億円
(2018年実績)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

42.
syslog+TLS
Logstash
Elasticsearch
Kibana
cf pushConcourse
PrometheusGrafana
git push
全体アーキテクチャ
cf create-service
cf bind-service

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

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

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

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

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
Appはマイクロサービスの構成です
べてPCF上に配置
アプリケーション構成（同期 加盟店 ➡ 決済機関）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

66.
Concourse - トップ画面

67.
Concourse - パイプライン画面

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

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

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

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

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

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

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

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

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

77.
Grafana(Micrometer)Metrics

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

79.
Kibana（アクセスログ）Logging

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

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

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

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

84.
ZipkinTracing

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

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

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

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

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

90.
本日のまとめ

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

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

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

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

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