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

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. Pivotal Advisory Solutions Architect 槙俊明(@making) ソフトバンク・ペイメント・サービス株式会社シニアアーキテクト鈴木順也(@suzukij) Cloud Foundry、Kubernetesの導入・運用支援およびそのプラットフォーム上でのSpringを使った開発の支援。主な著書:「はじめてのSpring Boot」、「Spring徹底入門」、「パーフェクトJava EE」自己紹介 Java, Webシステムの開発に従事。元々は SIer のプログラマ。フリーランスを経て 2年前に現在の会社に転職。主な業務・業務の改善・運用業務の効率化・新規サービスの開発

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

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

5. 今日お話すること ● 内製化に至る道のり ● Pivotal Cloud Foundry を選んだ理由 ● 手に入れた開発のカタチ ○ アーキテクチャ ○ ビルド CI / CD ○ Observability

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

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

8. 2016年: システム運用の効率化を自分たちで課題運用の手作業が多い手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製運用作業を自動化

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

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

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

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

13. 2017年: ①サービス監視の質を高めるシステムやサービスの状況を共有したいサービスの可視化監視用ダッシュボードを作成導入したもの Elasticsearch Logstash Kibana https://www.slideshare.net/JunyaSuzuki1/elastic-stack-84302320

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

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

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

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

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

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

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

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

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

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

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

25. 2018年: 決済システムの内製へチーム体制改善活動PJ

26. 2018年: 決済システムの内製へチーム体制改善活動PJ さらに2名のエンジニアがJoin 現在は7名のチーム体制

27. 2018年: 決済システムの内製へチーム体制改善活動PJ 開発PJ

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

29. 2018年: 決済システムの内製へチーム体制槙 (週1の技術支援) 改善活動PJ 開発PJ

30. Pivotal Cloud Foundryを選んだ理由決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

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. 製品毎の抽象化レイヤーの違い 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. 製品毎の抽象化レイヤーの違い 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. テストされ、ビルドされたコード cf push -p app.jar ~ 1 min ~15+ Days 利用可能なホストの選択ランタイムのインストールと設定ミドルウェアのインストールと設定アプリケーションソースコード準備依存性ライブラリの取得アプリケーションパッケージの作成サービスやミドルウェアのインストールと設定ホストへコンテナのデプロイ環境変数などの設定ロードバランサ設定ファイアーウォール設定モニタリングツールの設定ロギング設定 2日 1日 1日 ¼ 日 ¼ 日 ¼ 日 2 日 ½ 日 ¼ 日 2 日 2 日 3 日 1 日テストされ、ビルドされたコード本番環境へのデプロイ完了各設定がプラットフォーム側で自動で行われる通常かかる時間

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

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

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

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

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

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

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

42. Why PaaS? https://twitter.com/doctor_julz/status/1053022686832721922 これ

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

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

45. 全体アーキテクチャ Dev Prod PAS以外のコンポーネント(VM)はBOSHで管理 DevOpsDevとProdの2環境

46. 手に入れた開発のカタチ ➢ アーキテクチャ決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

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 オンラインショッピングサイト通販サイト、ゲーム、電子書籍、チケット、不動産、その他アプリケーション構成①（同期加盟店 ➡ 決済機関）

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 決済機関システムクレジット、コンビニ支払い、キャリア決済、プリペイドカード、その他アプリケーション構成①（同期加盟店 ➡ 決済機関）

51. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C AppはすべてPCF上に配置アプリケーション構成①（同期加盟店 ➡ 決済機関）

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

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

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

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

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

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

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

62. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①（同期加盟店 ➡ 決済機関）決済機関A起因の障害の影響で関係のない決済機関Cへのアクセスができなくなる

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

64. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix アプリケーション構成①（同期加盟店 ➡ 決済機関）他の決済機関へのアクセスに影響を及ぼさない障害の伝播を防ぐ

65. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②（非同期決済機関 ➡ 加盟店）

67. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 非同期を実現するために RabbitMQ + Spring Cloud Stream を使用アプリケーション構成②（非同期決済機関 ➡ 加盟店）

69. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 特定の加盟店で障害が発生した場合アプリケーション構成②（非同期決済機関 ➡ 加盟店）

70. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②（非同期決済機関 ➡ 加盟店）Dead Letter Queue と呼ばれるキューに退避して、後に再送

71. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix HystrixCircuit Breakerにより、他の加盟店に影響を及ぼさない Hystrix アプリケーション構成②（非同期決済機関 ➡ 加盟店）

72. アプリケーション構成③（非同期加盟店 ➡ 決済機関） API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix

73. API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix 同期決済が求められないケースではなるべく非同期パターンを適用アプリケーション構成③（非同期加盟店 ➡ 決済機関）

74. API Gateway Service D Service E Service F 加盟店 X 加盟店 Y 加盟店 Z 決済機関 D 決済機関 E 決済機関 F Hystrix Hystrix Hystrix Hystrix 決済機関の障害時に、復帰後のエラー処理が可能アプリケーション構成③（非同期加盟店 ➡ 決済機関）

75. PCF App Autoscaler API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix

76. PCF App Autoscaler API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix 特定の加盟店や決済機関の急なリクエスト増

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. 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. 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. 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. 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. 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. 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. 手に入れた開発のカタチ ➢ ビルド CI/CD 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

85. ビルド CI / CD Concourse CI https://concourse-ci.org/

86. ビルド CI / CD Concourse CI https://concourse-ci.org/

87. Concourse - トップ画面

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

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. developブランチへの更新がトリガ Concourse - パイプライン画面

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

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

95. developブランチユニットテスト snapshotビルド Nexusアップロードテスト環境デプロイテスト環境リリース本番環境リリース Concourse 開発から本番リリースまでのパイプライン

96. masterブランチユニットテストバージョンタグの取得本番環境デプロイ releaseビルド Nexusアップロードバージョンの更新 (次の開発へ) テスト環境リリース本番環境リリース masterへマージ (手動クリックによる起動) Concourse 開発から本番リリースまでのパイプライン

97. テスト環境リリース本番環境リリース Concourse 開発から本番リリースまでのパイプライン本番リリースのパイプラインはあくまで一例 ● 開発チームによる判断 ● プラットフォームチームによる判断 ● ビジネス的な判断

98. テスト環境リリース本番環境リリース Concourse 開発から本番リリースまでのパイプライン CI による開発サイクルワンクリックリリースによる CD

99. による負荷テスト、E2Eテスト(HTMLレポート) 開発中はJMeterによるテストを毎日継続的に自動で実行レポートのスクリーンショットをSlackに通知レポートのHTMLは cf push

100. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン

101. Javaの複数バージョンでのユニットテスト Java 11 リリース前のパイプライン

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. 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. 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. 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. Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン

107. OpenJDK 11でユニットテスト Java Buildpack 4.16でJava 11も対応 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン

108. OpenJDK 12でもユニットテスト次のLTS(17)へ向けて準備 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン

109. Javaアップデートの弊害を早期に検知

110. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知テスト失敗の原因特定のTLS証明書でHTTPSのハンドシェイクに失敗してしまうJDKの不具合

111. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知特定のTLS証明書でHTTPSのハンドシェイクに失敗してしまう不具合 Fixed 12 Backports Fix Version 11.0.2

112. https://bugs.openjdk.java.net/browse/JDK-8209965 Javaアップデートの弊害を早期に検知特定のTLS証明書でHTTPSのハンドシェイクに失敗してしまう不具合 Fixed 12 Backports Fix Version 11.0.2 Javaバージョン毎のテストをCIで回すことによりアップデートの弊害を早期に検知

113. Javaの更新に付いていく ● 複数バージョンを同時にテスト可能なCI環境 ● 簡単にデプロイ可能なDev/Staging/Prod環境塩漬けするのではなく、アップデートし続けられる環境を準備。

114. Javaの更新に付いていく ● 複数バージョンを同時にテスト可能なCI環境 ● 簡単にデプロイ可能なDev/Staging/Prod環境塩漬けするのではなく、アップデートし続けられる環境を準備。

115. 手に入れた開発のカタチ ➢ Observability 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

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

120. Grafanaダッシュボードでの監視対象 ● 全Spring Bootアプリ(Micrometer)のメトリクス ● 全コンテナのメトリクス ● 全VMのメトリクス ● Cloud Foundryの各コンポーネントのメトリクス ● RabbitMQのメトリクス ● MySQLのメトリクス ● Concourseのメトリクス ● Elasticsearchのメトリクス ● など BOSHでインストールするとダッシュボードやアラートはプリセット済み

121. Grafana(Micrometer)

122. Grafana(Micrometer) 今までログから可視化していた情報が Grafanaでいつでも確認可能に・CPU ・ヒープ（各領域ごと）・スレッド・GC（回数、時間）・クラスローダ

123. Grafana(Micrometer) Micrometer <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>

124. Grafana(Micrometer Hystrix)

125. Grafana(Micrometer Hystrix)

126. Grafana(Micrometer Hystrix) タイムアウトイベント数特定の決済機関がダウンし、タイムアウト発生(図はデモ) ショートイベント数 Circuit BreakerがOpenしてショートし、他の決済機関への経路には影響を与えないオープンサーキット数処理の異常が発生した場合にオープンするサーキットの数

127. Grafana(Micrometer Hystrix) Micrometer @Bean public HystrixMetricsBinder hystrixMetricsBinder() { return new HystrixMetricsBinder(); } ※Spring Cloud GreenwichからはAuto-Configured

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. Kibana（アクセスログ）

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

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

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

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

134. Elastalertでログのキーワード監視 ➡ Slack通知 Kibanaダッシュボードへのリンク付き https://elastalert.readthedocs.io

135. Zipkin

136. トレースIDで検索可能 Zipkin

137. 複数のサービスに跨って、どこの処理で時間がかかっていたか一目でわかる Zipkin

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. Zipkin（Brave MySQL ）

140. Zipkin（Brave MySQL ）

141. 実行されたSQLと所要時間を確認可能 Zipkin（Brave MySQL ）

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. 本日のまとめ決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

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

145. 本日のまとめこれから ● リリースの建て付け ● 運用 - 障害検知/障害対応の明確化 ● 追加の開発を容易にするルール、仕組み

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

147. さいごに開発チームの組織を立ち上げ、まだまだようやく走り始めた段階で今後もリリースと運用が控えている。 Spring, PCFのある開発を通して加盟店/エンドユーザの方々に高い品質のサービスを提供したい。堅牢、安全、1件1円間違えない、障害に強いシステムを目指して

148. We are hiring! ソフトバンク・ペイメント・サービスはエンジニアを募集しています興味がある方は　　@suzukij まで Pivotalジャパンはプラットフォームアーキテクト、ソリューションズアーキテクトを募集しています興味がある方は　　@making まで https://pivotal.io/locations/tokyo ご清聴ありがとうございました