Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
© Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Spring Fest 2018 #jsug #sf_h1
October 31 2018
Tos...
Pivotal
Advisory Solutions Architect
槙 俊明(@making)
ソフトバンク・ペイメント・サービス株式会社
シニアアーキテクト
鈴木順也(@suzukij)
Cloud Foundry、Kubernetes...
ソフトバンク携帯ユーザー向けの
「ソフトバンクカード」のカード発行・
運営をしています。
ソフトバンクカードは、 Visa加盟店
で利用できるプリペイドカードです。
ご利用金額に応じて Tポイントが貯
まります。
カード発行業務
決済代行
EC...
ソフトバンク携帯ユーザー向けの
「ソフトバンクカード」のカード発行・
運営をしています。
ソフトバンクカードは、 Visa加盟店
で利用できるプリペイドカードです。
ご利用金額に応じて Tポイントが貯
まります。
カード発行業務
決済代行
EC...
今日お話すること
● 内製化に至る道のり
● Pivotal Cloud Foundry を選んだ理由
● 手に入れた開発のカタチ
○ アーキテクチャ
○ ビルド CI / CD
○ Observability
内製化に至る道のり
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
2016年当時...
サービス開発はベンダに任せており、
コードを書く自社のエンジニアは 0人だった。
開発のための環境も整っていない状態だった。
2016年: システム運用の効率化を自分たちで
課題
運用の手作業が多い
手作業ゆえのミス Spring Boot
Selenium / Selenide
支援ツールを内製
運用作業を自動化
2016年: システム運用の効率化を自分たちで
Spring Boot
Selenium / Selenide
課題 支援ツールを内製
導入したもの
運用の手作業が多い
手作業ゆえのミス
運用作業を自動化
必要な環境を整える
2016年: システム運用の効率化を自分たちで
課題
導入したもの
運用の手作業が多い
手作業ゆえのミス Spring Boot
Selenium / Selenide
支援ツールを内製
運用作業を自動化
3名のエンジニアがJoin
チームとし...
2017年: ①サービス監視の質を高める
サービス状況をすば
やく把握、共有ができ
ていなかった
課題
2017年: ①サービス監視の質を高める
サービス状況をすば
やく把握、共有ができ
ていなかった
課題 監視用ダッシュボードを作成
導入したもの
Elasticsearch
Logstash
Kibana
2017年: ①サービス監視の質を高める
システムやサービスの
状況を共有したい
サービスの可視化 監視用ダッシュボードを作成
導入したもの
Elasticsearch
Logstash
Kibana
https://www.slideshar...
2017年: ②開発プロジェクトの支援を開始
課題
古いアーキテクチャ
開発/リリースが高コスト
システム監視が困難
2017年: ②開発プロジェクトの支援を開始
課題 アーキテクチャをSpringベースに
導入したもの
モダンな開発 / 運用
 Spring Boot
 Spring Cloud
古いアーキテクチャ
開発/リリースが高コスト
システム監視が困...
2017年: ②開発プロジェクトの支援を開始
課題
導入したもの
アーキテクチャをSpringベースに
モダンな開発 / 運用
 Spring Boot
 Spring Cloud
さらに1名のエンジニアがJoin
古いアーキテクチャ
開発/リ...
2016 - 2017年
● エンジニアチームの立ち上げ
● 運用業務の改善を通してツールの内製化
● 開発案件にも支援として参加
2018年
いよいよ決済システムの内製がスタート
加盟店 決済機関
通販サイト
ゲーム
教育
不動産
その他
電子書籍/動画
決済サービス
全て一本化
チケット
ECサイト向けに様々な決済手段を提供
加盟店に決済APIを提供するシステム
クレジット
携帯キャリア決済
コンビニ支払い
プリペイド...
開発対象
オンライン決済サービス
加盟店 決済機関
通販サイト
ゲーム
教育
不動産
その他
電子書籍/動画
決済サービス
全て一本化
チケット
ECサイト向けに様々な決済手段を提供
加盟店に決済APIを提供するシステム
クレジット
携帯キャリ...
開発対象
オンライン決済サービス
加盟店 決済機関
通販サイト
ゲーム
教育
不動産
その他
電子書籍/動画
決済サービス
全て一本化
チケット
ECサイト向けに様々な決済手段を提供
加盟店に決済APIを提供するシステム
クレジット
携帯キャリ...
開発対象
オンライン決済サービス
加盟店 決済機関
通販サイト
ゲーム
教育
不動産
その他
電子書籍/動画
決済サービス
全て一本化
チケット
ECサイト向けに様々な決済手段を提供
加盟店に決済APIを提供するシステム
クレジット
携帯キャリ...
2018年: 決済システムの内製へ
新システムに求めるモノ
● スピード感のある開発/リリース
● 継続的な改善のサイクル
● 監視が容易で障害に強いシステム
今までは…
案件毎に開発ベンダのチカラを借りて構築
(見積もり/契約/要件定義から検...
2018年: 決済システムの内製へ
新システムに求めるモノ
● スピード感のある開発/リリース
● 継続的な改善のサイクル
● 監視が容易で障害に強いシステム
今までは…
案件毎に開発ベンダさんのチカラを借りて構築
(見積もり/要件定義から検収...
2018年: 決済システムの内製へ
新システムに求めるモノ
● スピード感のある開発/リリース
● 継続的な改善のサイクル
● 監視が容易で障害に強いシステム
今までは…
案件毎に開発ベンダさんのチカラを借りて構築
(見積もり/要件定義から検収...
2018年: 決済システムの内製へ
チーム体制
改善活動PJ
2018年: 決済システムの内製へ
チーム体制
改善活動PJ
さらに2名のエンジニアがJoin
現在は7名のチーム体制
2018年: 決済システムの内製へ
チーム体制
改善活動PJ 開発PJ
2018年: 決済システムの内製へ
導入したもの
Pivotal Cloud Foundry を中心とした
クラウドネイティブなプラットフォーム
Concourse
2018年: 決済システムの内製へ
チーム体制
槙 (週1の技術支援)
改善活動PJ 開発PJ
Pivotal Cloud Foundryを選んだ理由
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
Pivotal Function Service
Auto ScaleおよびScale to zeroを実現
するServerlessなFunction実行基盤
● OSSのKnativeおよびriffがベー
ス技術
● Coming soon...
製品毎の抽象化レイヤーの違い
DIY k8s or container stack
Embedded OS
OS Image
Runtime Layer
Service Brokerage
Application Layer
Platform
...
製品毎の抽象化レイヤーの違い
DIY k8s or container stack
Embedded OS
OS Image
Runtime Layer
Service Brokerage
Application Layer
Platform
...
テストされ、ビルドされたコード
cf push 
-p app.jar
~ 1 min ~15+ Days
利用可能なホストの選択
ランタイムのインストールと設定
ミドルウェアのインストールと設定
アプリケーションソースコード準備
依存性ライブ...
開発プロジェクトのチーム体制と責任分界
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
プラットフォーム運用者
Ops 2名
Runtime
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Data
Application
アプリケーション開発者
Dev 3名
プ...
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Data
Application
プラットフォームの構築 / 管
理 に専...
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Data
Application
業務の設計 / 実装に集中
プラットフォ...
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Data
Application
12 Factor App 契約事項は1...
開発プロジェクトのチーム体制と責任分界
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Data
Application
技術支援(週1)
プラットフォーム運用者...
Why PaaS?
https://twitter.com/doctor_julz/status/1053022686832721922
これ
手に入れた開発のカタチ
➢ プラットフォーム / 全体のアーキテクチャ
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
syslog+TLS
Logstash
Elasticsearch
Kibana
cf pushConcourse
PrometheusGrafana
git push
全体アーキテクチャ
cf create-service
cf bind-s...
全体アーキテクチャ
Dev
Prod
PAS以外のコンポーネント(VM)はBOSHで管理
DevOpsDevとProdの2環境
手に入れた開発のカタチ
➢ アーキテクチャ
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
オンラインショッピングサイト
通販サイト、ゲーム、電子書籍、
チケット、不動産、そ...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
次期決済システム
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
決済機関システム
クレジット、コンビニ支払い、キャリア決済、
プリペイドカード、そ...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
AppはすべてPCF上に配置
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
API
Gateway
Service A
Service B
Service C
加盟店 A
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
すべてのAppは Spring Boot で実装
アプリケーション構成①(同期 加...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
決済機関毎のビジネスロジックが実装され
ているAPIへルーティング
アプリケーショ...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
http://cloud.spring.io/spring-cloud-gatew...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
決済機関や加盟店は当然、コントロール範囲外
アプリケーション構成①(同期 加盟店 ...
Hystrix
API
Gateway
Service A
Service B
Service C
加盟店 A
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
システム間通信にはHystrixで
Circuit Breaker...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)Circuit Breaker...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
レスポンス遅延、タイムアウト
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
障害の伝播
処理のブロック、...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
障害の伝播
処理のブロック、...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
障害の伝播
処理のブロック、...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
アプリケーション構成①(同期 加盟店 ➡ 決済機関)
決済機関A起因の障害の影響で...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
アプリケーション構...
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
アプリケーション構成①(同期 加盟...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystr...
Notification
Gateway
Receiver A
Receiver B
Receiver C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
HystrixCircui...
アプリケーション構成③(非同期 加盟店 ➡ 決済機関)
API
Gateway
Service D
Service E
Service F
加盟店 X
加盟店 Y
加盟店 Z
決済機関 D
決済機関 E
決済機関 F
Hystrix
Hystr...
API
Gateway
Service D
Service E
Service F
加盟店 X
加盟店 Y
加盟店 Z
決済機関 D
決済機関 E
決済機関 F
Hystrix
Hystrix
Hystrix
Hystrix
同期決済が求められ...
API
Gateway
Service D
Service E
Service F
加盟店 X
加盟店 Y
加盟店 Z
決済機関 D
決済機関 E
決済機関 F
Hystrix
Hystrix
Hystrix
Hystrix
決済機関の障害時に...
PCF App Autoscaler
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystri...
PCF App Autoscaler
API
Gateway
Service A
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystri...
Hystrix
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
Serv...
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
API
Gateway
...
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
API
Gateway
...
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
API
Gateway
...
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
API
Gateway
...
PCF App Autoscaler
Service B
Service C
加盟店 X
加盟店 Y
加盟店 Z
決済機関 A
決済機関 B
決済機関 C
Hystrix
Hystrix
Hystrix
Hystrix
API
Gateway
...
The 12 Factor App
https://12factor.net/
III. Config
VI. Processes
VII. Port binding
VIII. Concurrency
XI. Logs
アプリ実装の観点で重要...
手に入れた開発のカタチ
➢ ビルド CI/CD
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
ビルド CI / CD
Concourse CI
https://concourse-ci.org/
ビルド CI / CD
Concourse CI
https://concourse-ci.org/
Concourse - トップ画面
Concourse - パイプライン画面
パイプライン全体のジョブ構成
ジョブ設定は YAMLファイル で管理
Concourse - パイプライン画面
- task: mvn-test
config:
platform: linux
image_resource:
type: doc...
developブランチへの更新がトリガ
Concourse - パイプライン画面
Concourse - パイプライン画面
Concourse - パイプライン画面
Concourse 開発から本番リリースまでのパイプライン
Concourse 開発から本番リリースまでのパイプライン
テスト環境リリース 本番環境リリース
developブランチ
ユニットテスト
snapshotビルド
Nexusアップロード
テスト環境
デプロイ
テスト環境リリース 本番環境リリース
Concourse 開発から本番リリースまでのパイプライン
masterブランチ
ユニットテスト
バージョンタグ
の取得
本番環境
デプロイ
releaseビルド
Nexusアップロード
バージョンの更新
(次の開発へ)
テスト環境リリース 本番環境リリース
masterへマージ
(手動クリックによる起...
テスト環境リリース 本番環境リリース
Concourse 開発から本番リリースまでのパイプライン
本番リリースのパイプラインはあくまで一例
● 開発チームによる判断
● プラットフォームチームによる判断
● ビジネス的な判断
テスト環境リリース 本番環境リリース
Concourse 開発から本番リリースまでのパイプライン
CI による開発サイクル ワンクリックリリースによる CD
による負荷テスト、E2Eテスト(HTMLレポート)
開発中はJMeterによるテストを毎日継続的に自動で実行
レポートのスクリーンショットをSlackに通知
レポートのHTMLは
cf push
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
- task: mvn-test
config:
platform: linux
image_resource:
type: docker-image
sou...
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
- task: mvn-test
config:
platform: linux
image_resource:
type: docker-image
sou...
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
- task: mvn-test
config:
platform: linux
image_resource:
type: docker-image
sou...
Javaの複数バージョンでのユニットテスト
Java 11 リリース前のパイプライン
- task: mvn-test
config:
platform: linux
image_resource:
type: docker-image
sou...
Javaの複数バージョンでのユニットテスト
Java 11 リリース後のパイプライン
OpenJDK 11でユニットテスト
Java Buildpack 4.16でJava 11も対応
Javaの複数バージョンでのユニットテスト
Java 11 リリース後のパイプライン
OpenJDK 12でもユニットテスト
次のLTS(17)へ向けて準備
Javaの複数バージョンでのユニットテスト
Java 11 リリース後のパイプライン
Javaアップデートの弊害を早期に検知
https://bugs.openjdk.java.net/browse/JDK-8209965
Javaアップデートの弊害を早期に検知
テスト失敗の原因
特定のTLS証明書でHTTPSのハンドシェイクに
失敗してしまうJDKの不具合
https://bugs.openjdk.java.net/browse/JDK-8209965
Javaアップデートの弊害を早期に検知
特定のTLS証明書でHTTPSのハンド
シェイクに失敗してしまう不具合
Fixed
12
Backport...
https://bugs.openjdk.java.net/browse/JDK-8209965
Javaアップデートの弊害を早期に検知
特定のTLS証明書でHTTPSのハンド
シェイクに失敗してしまう不具合
Fixed
12
Backport...
Javaの更新に付いていく
● 複数バージョンを同時にテスト可能なCI環境
● 簡単にデプロイ可能なDev/Staging/Prod環境
塩漬けするのではなく、アップデートし続けられる環境を
準備。
Javaの更新に付いていく
● 複数バージョンを同時にテスト可能なCI環境
● 簡単にデプロイ可能なDev/Staging/Prod環境
塩漬けするのではなく、アップデートし続けられる環境を
準備。
手に入れた開発のカタチ
➢ Observability
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
Observability
※Metrics, tracing, and logging 
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
Observability
※Metrics, tracing, and logging 
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
Observability
※Metrics, tracing, and logging 
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
Observability
※Metrics, tracing, and logging 
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
Grafanaダッシュボードでの監視対象
● 全Spring Bootアプリ(Micrometer)のメトリクス
● 全コンテナのメトリクス
● 全VMのメトリクス
● Cloud Foundryの各コンポーネントのメトリクス
● Rabbit...
Grafana(Micrometer)
Grafana(Micrometer)
今までログから可視化していた情報が
Grafanaでいつでも確認可能に
・CPU
・ヒープ(各領域ごと)
・スレッド
・GC(回数、時間)
・クラスローダ
Grafana(Micrometer)
Micrometer
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</a...
Grafana(Micrometer Hystrix)
Grafana(Micrometer Hystrix)
Grafana(Micrometer Hystrix)
タイムアウトイベント数
特定の決済機関がダウンし、タ
イムアウト発生(図はデモ) ショートイベント数
Circuit BreakerがOpenして
ショートし、他の決済機関へ
の経路には影...
Grafana(Micrometer Hystrix)
Micrometer
@Bean
public HystrixMetricsBinder hystrixMetricsBinder() {
return new HystrixMetric...
Promregator
Prometheus Aggregator for Cloud Foundry
https://github.com/promregator/promregator
Prometheus Promregator
Clou...
Kibana(アクセスログ)
Kibana(アクセスログ)
アクセスログ一覧
レスポンスタイム
アプリ別
アクセス数
ステータスコード別
アクセス数
Kibana(アプリケーションログ)
Kibana(アプリケーションログ)
ログレベル別
ログ出力数
アプリケーションログ
Kibana(アプリケーションログ)
開発者は Elastic Stack
を意識せず、標準出力にログを出力
するだけで良い。
Elastalertでログのキーワード監視 ➡ Slack通知
Kibanaダッシュボードへのリンク付き
https://elastalert.readthedocs.io
Zipkin
トレースIDで検索可能
Zipkin
複数のサービスに跨って、
どこの処理で時間がかかっていたか一目でわかる
Zipkin
Zipkin, Spring Cloud Sleuth
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zip...
Zipkin(Brave MySQL )
Zipkin(Brave MySQL )
実行されたSQLと所要時間を確認可能
Zipkin(Brave MySQL )
Brave MySQL
<dependency>
<groupId>io.zipkin.brave</groupId>
<artifactId>brave-instrumentation-mysql</artifactId>
<version>...
本日のまとめ
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
本日のまとめ
ここまでの歩み
● 開発チームの立ち上げ
● 運用業務の改善活動
● PCFを中心としたプラットフォームの導入 / 構築
● 決済システム内製
○ 耐障害性に優れたシステム
○ 監視の容易なシステム
○ 継続的なビルド/リリース ...
本日のまとめ
これから
● リリースの建て付け
● 運用 - 障害検知/障害対応の明確化
● 追加の開発を容易にするルール、仕組み
本日のまとめ
外注に頼りきったサービス開発を積み重ねてもプラット
フォームは構築できない。
内製という技術の舵取りをおこなうからこそ
プラットフォームの構築/運用が可能となる。
そしてその強力な基盤があるおかげで少人数でも
サービス開発に注力が...
さいごに
開発チームの組織を立ち上げ、まだまだようやく走り始めた段
階で今後もリリースと運用が控えている。
Spring, PCFのある開発を通して加盟店/エンドユーザの方々
に高い品質のサービスを提供したい。
堅牢、安全、1件1円間違えない、...
We are hiring!
ソフトバンク・ペイメント・サービスは
エンジニアを募集しています
興味がある方は   @suzukij まで
Pivotalジャパンは
プラットフォームアーキテクト、ソリューションズアーキテクト
を募集しています
...
Transforming How The World Builds Software
© Copyright 2018 Pivotal Software, Inc. All rights Reserved.
Nächste SlideShare
Wird geladen in …5
×

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

28.761 Aufrufe

Veröffentlicht am

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

Spring Fest 2018

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

  1. 1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Spring Fest 2018 #jsug #sf_h1 October 31 2018 Toshiaki Maki (@making), Pivotal, tmaki@pivotal.io Junya Suzuki (@suzukij), Softbank Payment Service, junya.suzuki03@g.softbank.co.jp 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  2. 2. Pivotal Advisory Solutions Architect 槙 俊明(@making) ソフトバンク・ペイメント・サービス株式会社 シニアアーキテクト 鈴木順也(@suzukij) Cloud Foundry、Kubernetesの導入・運用支援およびそのプラット フォーム上でのSpringを使った開発の支援。 主な著書:「はじめてのSpring Boot」、「Spring徹底入門」、 「パーフェクトJava EE」 自己紹介 Java, Webシステムの開発に従事。 元々は SIer のプログラマ。フリーランスを経て 2年前に現在の会社 に転職。 主な業務 ・業務の改善 ・運用業務の効率化 ・新規サービスの開発
  3. 3. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay(銀聯)のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー(クレジットカード加盟 店契約会社)としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 ソフトバンク・ペイメント・サービスの事業内容
  4. 4. ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay(銀聯)のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイアラー(クレジットカード加盟 店契約会社)としての加盟店審査や管理事 業、端末決済サービスを提供しています。 ソフトバンクと共同で、ソフトバンク 携帯ユーザー向けの通話料合算 請求「ソフトバンクまとめて支払い」 の開発・運営をしています。 キャリア決済 EC/ネット店舗 実店舗/訪問販売 決済代行からカード事業まで幅広く展開 ソフトバンク・ペイメント・サービスの事業内容
  5. 5. 今日お話すること ● 内製化に至る道のり ● Pivotal Cloud Foundry を選んだ理由 ● 手に入れた開発のカタチ ○ アーキテクチャ ○ ビルド CI / CD ○ Observability
  6. 6. 内製化に至る道のり 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  7. 7. 2016年当時... サービス開発はベンダに任せており、 コードを書く自社のエンジニアは 0人だった。 開発のための環境も整っていない状態だった。
  8. 8. 2016年: システム運用の効率化を自分たちで 課題 運用の手作業が多い 手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製 運用作業を自動化
  9. 9. 2016年: システム運用の効率化を自分たちで Spring Boot Selenium / Selenide 課題 支援ツールを内製 導入したもの 運用の手作業が多い 手作業ゆえのミス 運用作業を自動化 必要な環境を整える
  10. 10. 2016年: システム運用の効率化を自分たちで 課題 導入したもの 運用の手作業が多い 手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製 運用作業を自動化 3名のエンジニアがJoin チームとして改善活動も加速
  11. 11. 2017年: ①サービス監視の質を高める サービス状況をすば やく把握、共有ができ ていなかった 課題
  12. 12. 2017年: ①サービス監視の質を高める サービス状況をすば やく把握、共有ができ ていなかった 課題 監視用ダッシュボードを作成 導入したもの Elasticsearch Logstash Kibana
  13. 13. 2017年: ①サービス監視の質を高める システムやサービスの 状況を共有したい サービスの可視化 監視用ダッシュボードを作成 導入したもの Elasticsearch Logstash Kibana https://www.slideshare.net/JunyaSuzuki1/elastic-stack-84302320
  14. 14. 2017年: ②開発プロジェクトの支援を開始 課題 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難
  15. 15. 2017年: ②開発プロジェクトの支援を開始 課題 アーキテクチャをSpringベースに 導入したもの モダンな開発 / 運用  Spring Boot  Spring Cloud 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難 CIをあたり前に
  16. 16. 2017年: ②開発プロジェクトの支援を開始 課題 導入したもの アーキテクチャをSpringベースに モダンな開発 / 運用  Spring Boot  Spring Cloud さらに1名のエンジニアがJoin 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難
  17. 17. 2016 - 2017年 ● エンジニアチームの立ち上げ ● 運用業務の改善を通してツールの内製化 ● 開発案件にも支援として参加 2018年 いよいよ決済システムの内製がスタート
  18. 18. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社当社 API型 開発対象 オンライン決済サービス
  19. 19. 開発対象 オンライン決済サービス 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社当社 API型 導入実績 約 80,000 店舗
  20. 20. 開発対象 オンライン決済サービス 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社当社 API型 決済手段 40 種以上に対応
  21. 21. 開発対象 オンライン決済サービス 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 決済サービス 全て一本化 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 当社当社 加盟店システムと決済機関システムの間に位置す る自社だけでは完結しない Webシステム API型
  22. 22. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダのチカラを借りて構築 (見積もり/契約/要件定義から検収まで長い道のり)​
  23. 23. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 (見積もり/要件定義から検収まで長い道のり)​ 開発ベンダに頼りきっていてはスピード感のある 開発、小さな改善のサイクルが作れない。
  24. 24. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 (見積もり/要件定義から検収) 内製化によるスピード感のある開発 内製化による継続的な改善​
  25. 25. 2018年: 決済システムの内製へ チーム体制 改善活動PJ
  26. 26. 2018年: 決済システムの内製へ チーム体制 改善活動PJ さらに2名のエンジニアがJoin 現在は7名のチーム体制
  27. 27. 2018年: 決済システムの内製へ チーム体制 改善活動PJ 開発PJ
  28. 28. 2018年: 決済システムの内製へ 導入したもの Pivotal Cloud Foundry を中心とした クラウドネイティブなプラットフォーム Concourse
  29. 29. 2018年: 決済システムの内製へ チーム体制 槙 (週1の技術支援) 改善活動PJ 開発PJ
  30. 30. Pivotal Cloud Foundryを選んだ理由 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  31. 31. Pivotal Function Service Auto ScaleおよびScale to zeroを実現 するServerlessなFunction実行基盤 ● OSSのKnativeおよびriffがベー ス技術 ● Coming soon! Pivotal Container Service Kubernetesをフルに活用した コンテナオーケストレーションを提供 ● 自動復旧可能な Kubernetesクラ スタを動的にプロビジョニングす るAPIを提供 ● Kubernetesのエコシステムをフ ル活用しつつ運用を楽に Pivotal Application Service アプリケーションセントリックな クラウドネイティブプラットフォームを提 供 ● クラウドネイティブなアプリケー ション稼働のための機能をフル に提供 ● cf pushによる迅速なアプリリ リース ● OSSのCloud Foundryがベース 技術 Platform as a ServiceContainer as a Service Function as a Service PRACTICESPRACTICES PRACTICES
  32. 32. 製品毎の抽象化レイヤーの違い DIY k8s or container stack Embedded OS OS Image Runtime Layer Service Brokerage Application Layer Platform Provided App Team provided Embedded OS OS Image Runtime Layer Service Brokerage Application Layer Platform Provided App Team Provided Embedded OS OS Image Runtime Layer Service Brokerage Application Layer App Team Provided
  33. 33. 製品毎の抽象化レイヤーの違い DIY k8s or container stack Embedded OS OS Image Runtime Layer Service Brokerage Application Layer Platform Provided App Team provided Embedded OS OS Image Runtime Layer Service Brokerage Application Layer Platform Provided App Team Provided Embedded OS OS Image Runtime Layer Service Brokerage Application Layer App Team Provided Dockerfileを書くのではなく、 Buildpackを使うことでソースコードからコ ンテナイメージが作成される
  34. 34. テストされ、ビルドされたコード cf push -p app.jar ~ 1 min ~15+ Days 利用可能なホストの選択 ランタイムのインストールと設定 ミドルウェアのインストールと設定 アプリケーションソースコード準備 依存性ライブラリの取得 アプリケーションパッケージの作成 サービスやミドルウェアのインストールと設定 ホストへコンテナのデプロイ 環境変数などの設定 ロードバランサ設定 ファイアーウォール設定 モニタリングツールの設定 ロギング設定 2日 1日 1日 ¼ 日 ¼ 日 ¼ 日 2 日 ½ 日 ¼ 日 2 日 2 日 3 日 1 日 テストされ、ビルドされたコード 本番環境へのデプロイ完了 各設定が プラットフォーム側で 自動で行われる 通常かかる時間
  35. 35. 開発プロジェクトのチーム体制と責任分界
  36. 36. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware プラットフォーム運用者 Ops 2名 Runtime
  37. 37. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application アプリケーション開発者 Dev 3名 プラットフォーム運用者 Ops 2名
  38. 38. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application プラットフォームの構築 / 管 理 に専念 プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 3名
  39. 39. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 業務の設計 / 実装に集中 プラットフォーム運用者 Ops アプリケーション開発者 Dev 3名
  40. 40. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 12 Factor App 契約事項は12 Factor App。 ベンダーロックインはなし。 プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 3名
  41. 41. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 技術支援(週1) プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 3名
  42. 42. Why PaaS? https://twitter.com/doctor_julz/status/1053022686832721922 これ
  43. 43. 手に入れた開発のカタチ ➢ プラットフォーム / 全体のアーキテクチャ 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  44. 44. syslog+TLS Logstash Elasticsearch Kibana cf pushConcourse PrometheusGrafana git push 全体アーキテクチャ cf create-service cf bind-service
  45. 45. 全体アーキテクチャ Dev Prod PAS以外のコンポーネント(VM)はBOSHで管理 DevOpsDevとProdの2環境
  46. 46. 手に入れた開発のカタチ ➢ アーキテクチャ 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  47. 47. アプリケーション構成①(同期 加盟店 ➡ 決済機関) API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
  48. 48. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C オンラインショッピングサイト 通販サイト、ゲーム、電子書籍、 チケット、不動産、その他 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  49. 49. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 次期決済システム アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  50. 50. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関システム クレジット、コンビニ支払い、キャリア決済、 プリペイドカード、その他 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  51. 51. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C AppはすべてPCF上に配置 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  52. 52. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C すべてのAppは Spring Boot で実装 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  53. 53. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関毎のビジネスロジックが実装され ているAPIへルーティング アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  54. 54. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C http://cloud.spring.io/spring-cloud-gateway/multi/multi__building_a_simple_gateway_using_spring_mvc_or_webflux.html Spring Cloud Gatewayの ProxyExchangeでシンプルに実装 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  55. 55. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関や加盟店は当然、コントロール範囲外 アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  56. 56. Hystrix API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C システム間通信にはHystrixで Circuit Breakerを導入 Hystrix Hystrix Hystrix アプリケーション構成①(同期 加盟店 ➡ 決済機関)
  57. 57. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関)Circuit Breakerがない状態で 特定の決済機関で障害が発生した場合…
  58. 58. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関) レスポンス遅延、タイムアウト
  59. 59. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関) 障害の伝播 処理のブロック、スレッド枯渇
  60. 60. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関) 障害の伝播 処理のブロック、スレッド枯渇
  61. 61. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関) 障害の伝播 処理のブロック、スレッド枯渇
  62. 62. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①(同期 加盟店 ➡ 決済機関) 決済機関A起因の障害の影響で関係のない決済機関Cへ のアクセスができなくなる
  63. 63. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成①(同期 加盟店 ➡ 決済機関)Circuit Breaker があれば 特定の決済機関で障害が発生しても
  64. 64. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix アプリケーション構成①(同期 加盟店 ➡ 決済機関)他の決済機関へのアクセスに影響を及ぼさない 障害の伝播を防ぐ
  65. 65. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  66. 66. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  67. 67. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 非同期を実現するために RabbitMQ + Spring Cloud Stream を使用 アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  68. 68. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  69. 69. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 特定の加盟店で障害が発生した場合 アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  70. 70. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②(非同期 決済機関 ➡ 加盟店)Dead Letter Queue と呼ばれるキューに 退避して、後に再送
  71. 71. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix HystrixCircuit Breakerにより、他の加盟店に影響を 及ぼさない Hystrix アプリケーション構成②(非同期 決済機関 ➡ 加盟店)
  72. 72. アプリケーション構成③(非同期 加盟店 ➡ 決済機関) API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix
  73. 73. API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix 同期決済が求められないケースでは なるべく非同期パターンを適用 アプリケーション構成③(非同期 加盟店 ➡ 決済機関)
  74. 74. API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix 決済機関の障害時に、 復帰後のエラー処理が可能 アプリケーション構成③(非同期 加盟店 ➡ 決済機関)
  75. 75. PCF App Autoscaler API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix
  76. 76. PCF App Autoscaler API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 特定の加盟店や決済機関の 急なリクエスト増
  77. 77. Hystrix PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix Service A Service A API Gateway Service A 自動でAppインスタンス増
  78. 78. PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix API Gateway Service A API Gateway Service A API Gateway Service A
  79. 79. PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix API Gateway Service A API Gateway Service A API Gateway Service A インスタンス数の設定
  80. 80. PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix API Gateway Service A API Gateway Service A API Gateway Service A スケールのルール設定 ● CPU使用率 ● Memory使用率 ● HTTPスループット ● HTTPレイテンシ ● MQキューの長さ
  81. 81. PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix API Gateway Service A API Gateway Service A API Gateway Service A スケールアウト/インの しきい値の設定
  82. 82. PCF App Autoscaler Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix API Gateway Service A API Gateway Service A API Gateway Service A PCFに載せて設定するだけ アプリケーション側の対応は不要
  83. 83. The 12 Factor App https://12factor.net/ III. Config VI. Processes VII. Port binding VIII. Concurrency XI. Logs アプリ実装の観点で重要な5 Factors 環境に依存する設定項目は 環境変数に格納 CF、Spring Bootを使え ば自動で満たされる ログは標準出力に出力すれば プラットフォームが集約 絶対ロストしたくないログは標準 出力ではなくRDBへ保存
  84. 84. 手に入れた開発のカタチ ➢ ビルド CI/CD 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  85. 85. ビルド CI / CD Concourse CI https://concourse-ci.org/
  86. 86. ビルド CI / CD Concourse CI https://concourse-ci.org/
  87. 87. Concourse - トップ画面
  88. 88. Concourse - パイプライン画面
  89. 89. パイプライン全体のジョブ構成 ジョブ設定は YAMLファイル で管理 Concourse - パイプライン画面 - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-8 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
  90. 90. developブランチへの更新がトリガ Concourse - パイプライン画面
  91. 91. Concourse - パイプライン画面
  92. 92. Concourse - パイプライン画面
  93. 93. Concourse 開発から本番リリースまでのパイプライン
  94. 94. Concourse 開発から本番リリースまでのパイプライン テスト環境リリース 本番環境リリース
  95. 95. developブランチ ユニットテスト snapshotビルド Nexusアップロード テスト環境 デプロイ テスト環境リリース 本番環境リリース Concourse 開発から本番リリースまでのパイプライン
  96. 96. masterブランチ ユニットテスト バージョンタグ の取得 本番環境 デプロイ releaseビルド Nexusアップロード バージョンの更新 (次の開発へ) テスト環境リリース 本番環境リリース masterへマージ (手動クリックによる起動) Concourse 開発から本番リリースまでのパイプライン
  97. 97. テスト環境リリース 本番環境リリース Concourse 開発から本番リリースまでのパイプライン 本番リリースのパイプラインはあくまで一例 ● 開発チームによる判断 ● プラットフォームチームによる判断 ● ビジネス的な判断
  98. 98. テスト環境リリース 本番環境リリース Concourse 開発から本番リリースまでのパイプライン CI による開発サイクル ワンクリックリリースによる CD
  99. 99. による負荷テスト、E2Eテスト(HTMLレポート) 開発中はJMeterによるテストを毎日継続的に自動で実行 レポートのスクリーンショットをSlackに通知 レポートのHTMLは cf push
  100. 100. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン
  101. 101. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン
  102. 102. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-8 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
  103. 103. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-8 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 -Djava.version=8 - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-9 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 -Djava.version=9 -Dmockito.version=2.22.0 test
  104. 104. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-8 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 -Djava.version=8 - task: mvn-test config: &MVN_TEST_CONFIG platform: linux image_resource: type: docker-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 -Djava.version=11 -Dmockito.version=2.22.0 test - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-10 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 -Djava.version=10 -Dmockito.version=2.22.0 test
  105. 105. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン - task: mvn-test config: platform: linux image_resource: type: docker-image source: repository: maven tag: 3-jdk-8 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 -Djava.version=8 2.22.0 test - task: mvn-test config: &MVN_TEST_CONFIG platform: linux image_resource: type: docker-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 -Djava.version=11 -Dmockito.version=2.22.0 test - task: mvn-test config: &MVN_TEST_CONFIG platform: linux image_resource: type: docker-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 -Djava.version=11 -Dmockito.version=2.22.0 test - task: mvn-test config: platform: linux image_resource: type: docker-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 -Djava.version=11 -Dmockito.version=2.22.0 test
  106. 106. Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン
  107. 107. OpenJDK 11でユニットテスト Java Buildpack 4.16でJava 11も対応 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン
  108. 108. OpenJDK 12でもユニットテスト 次のLTS(17)へ向けて準備 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン
  109. 109. Javaアップデートの弊害を早期に検知
  110. 110. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知 テスト失敗の原因 特定のTLS証明書でHTTPSのハンドシェイクに 失敗してしまうJDKの不具合
  111. 111. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知 特定のTLS証明書でHTTPSのハンド シェイクに失敗してしまう不具合 Fixed 12 Backports Fix Version 11.0.2
  112. 112. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知 特定のTLS証明書でHTTPSのハンド シェイクに失敗してしまう不具合 Fixed 12 Backports Fix Version 11.0.2 Javaバージョン毎のテストをCIで回すことにより アップデートの弊害を早期に検知
  113. 113. Javaの更新に付いていく ● 複数バージョンを同時にテスト可能なCI環境 ● 簡単にデプロイ可能なDev/Staging/Prod環境 塩漬けするのではなく、アップデートし続けられる環境を 準備。
  114. 114. Javaの更新に付いていく ● 複数バージョンを同時にテスト可能なCI環境 ● 簡単にデプロイ可能なDev/Staging/Prod環境 塩漬けするのではなく、アップデートし続けられる環境を 準備。
  115. 115. 手に入れた開発のカタチ ➢ Observability 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  116. 116. Observability ※Metrics, tracing, and logging  https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
  117. 117. Observability ※Metrics, tracing, and logging  https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
  118. 118. Observability ※Metrics, tracing, and logging  https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
  119. 119. Observability ※Metrics, tracing, and logging  https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
  120. 120. Grafanaダッシュボードでの監視対象 ● 全Spring Bootアプリ(Micrometer)のメトリクス ● 全コンテナのメトリクス ● 全VMのメトリクス ● Cloud Foundryの各コンポーネントのメトリクス ● RabbitMQのメトリクス ● MySQLのメトリクス ● Concourseのメトリクス ● Elasticsearchのメトリクス ● など BOSHでインストールすると ダッシュボードやアラートは プリセット済み
  121. 121. Grafana(Micrometer)
  122. 122. Grafana(Micrometer) 今までログから可視化していた情報が Grafanaでいつでも確認可能に ・CPU ・ヒープ(各領域ごと) ・スレッド ・GC(回数、時間) ・クラスローダ
  123. 123. Grafana(Micrometer) Micrometer <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>
  124. 124. Grafana(Micrometer Hystrix)
  125. 125. Grafana(Micrometer Hystrix)
  126. 126. Grafana(Micrometer Hystrix) タイムアウトイベント数 特定の決済機関がダウンし、タ イムアウト発生(図はデモ) ショートイベント数 Circuit BreakerがOpenして ショートし、他の決済機関へ の経路には影響を与えない オープンサーキット数 処理の異常が発生した場合に オープンするサーキットの数
  127. 127. Grafana(Micrometer Hystrix) Micrometer @Bean public HystrixMetricsBinder hystrixMetricsBinder() { return new HystrixMetricsBinder(); } ※Spring Cloud GreenwichからはAuto-Configured
  128. 128. Promregator Prometheus Aggregator for Cloud Foundry https://github.com/promregator/promregator Prometheus Promregator Cloud Controller Diego Cell GoRouter Containers /metrics /actuator/prometheus アプリ情報を定期的 に取得 各アプリのメトリク スをそれぞれ取得 し集約 開発者はPrometheusの 設定を意識せず、cf pushするだけで良い。
  129. 129. Kibana(アクセスログ)
  130. 130. Kibana(アクセスログ) アクセスログ一覧 レスポンスタイム アプリ別 アクセス数 ステータスコード別 アクセス数
  131. 131. Kibana(アプリケーションログ)
  132. 132. Kibana(アプリケーションログ) ログレベル別 ログ出力数 アプリケーションログ
  133. 133. Kibana(アプリケーションログ) 開発者は Elastic Stack を意識せず、標準出力にログを出力 するだけで良い。
  134. 134. Elastalertでログのキーワード監視 ➡ Slack通知 Kibanaダッシュボードへのリンク付き https://elastalert.readthedocs.io
  135. 135. Zipkin
  136. 136. トレースIDで検索可能 Zipkin
  137. 137. 複数のサービスに跨って、 どこの処理で時間がかかっていたか一目でわかる Zipkin
  138. 138. Zipkin, Spring Cloud Sleuth <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> spring: zipkin: base-url: https://my-zipkin.example.com service.name: notification-gateway sender.type: web Zipkin
  139. 139. Zipkin(Brave MySQL )
  140. 140. Zipkin(Brave MySQL )
  141. 141. 実行されたSQLと所要時間を確認可能 Zipkin(Brave MySQL )
  142. 142. Brave MySQL <dependency> <groupId>io.zipkin.brave</groupId> <artifactId>brave-instrumentation-mysql</artifactId> <version>${brave-instrumentation-mysql.version}</version> </dependency> spring.datasource.hikari: data-source-properties.statementInterceptors: brave.mysql.TracingStatementInterceptor Zipkin(Brave MySQL )
  143. 143. 本日のまとめ 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  144. 144. 本日のまとめ ここまでの歩み ● 開発チームの立ち上げ ● 運用業務の改善活動 ● PCFを中心としたプラットフォームの導入 / 構築 ● 決済システム内製 ○ 耐障害性に優れたシステム ○ 監視の容易なシステム ○ 継続的なビルド/リリース パイプライン
  145. 145. 本日のまとめ これから ● リリースの建て付け ● 運用 - 障害検知/障害対応の明確化 ● 追加の開発を容易にするルール、仕組み
  146. 146. 本日のまとめ 外注に頼りきったサービス開発を積み重ねてもプラット フォームは構築できない。 内製という技術の舵取りをおこなうからこそ プラットフォームの構築/運用が可能となる。 そしてその強力な基盤があるおかげで少人数でも サービス開発に注力ができた。
  147. 147. さいごに 開発チームの組織を立ち上げ、まだまだようやく走り始めた段 階で今後もリリースと運用が控えている。 Spring, PCFのある開発を通して加盟店/エンドユーザの方々 に高い品質のサービスを提供したい。 堅牢、安全、1件1円間違えない、 障害に強いシステムを目指して ​
  148. 148. We are hiring! ソフトバンク・ペイメント・サービスは エンジニアを募集しています 興味がある方は   @suzukij まで Pivotalジャパンは プラットフォームアーキテクト、ソリューションズアーキテクト を募集しています 興味がある方は   @making まで https://pivotal.io/locations/tokyo ご清聴ありがとうございました
  149. 149. Transforming How The World Builds Software © Copyright 2018 Pivotal Software, Inc. All rights Reserved.

×