決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #jsug #sf_h1
•
18 j'aime•36,664 vues
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 Spring Fest 2018
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #jsug #sf_h1
Similaire à 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #jsug #sf_h1 (20)
Plus de Toshiaki Maki
Plus de Toshiaki Maki (20)
Dernier
Dernier (9)
決済システムの内製化への旅 - 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年前に現在の会社 に転職。 主な業務 ・業務の改善 ・運用業務の効率化 ・新規サービスの開発
- 5. 今日お話すること ● 内製化に至る道のり ● Pivotal Cloud Foundry を選んだ理由 ● 手に入れた開発のカタチ ○ アーキテクチャ ○ ビルド CI / CD ○ Observability
- 8. 2016年: システム運用の効率化を自分たちで 課題 運用の手作業が多い 手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製 運用作業を自動化
- 9. 2016年: システム運用の効率化を自分たちで Spring Boot Selenium / Selenide 課題 支援ツールを内製 導入したもの 運用の手作業が多い 手作業ゆえのミス 運用作業を自動化 必要な環境を整える
- 10. 2016年: システム運用の効率化を自分たちで 課題 導入したもの 運用の手作業が多い 手作業ゆえのミス Spring Boot Selenium / Selenide 支援ツールを内製 運用作業を自動化 3名のエンジニアがJoin チームとして改善活動も加速
- 15. 2017年: ②開発プロジェクトの支援を開始 課題 アーキテクチャをSpringベースに 導入したもの モダンな開発 / 運用 Spring Boot Spring Cloud 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難 CIをあたり前に
- 16. 2017年: ②開発プロジェクトの支援を開始 課題 導入したもの アーキテクチャをSpringベースに モダンな開発 / 運用 Spring Boot Spring Cloud さらに1名のエンジニアがJoin 古いアーキテクチャ 開発/リリースが高コスト システム監視が困難
- 17. 2016 - 2017年 ● エンジニアチームの立ち上げ ● 運用業務の改善を通してツールの内製化 ● 開発案件にも支援として参加 2018年 いよいよ決済システムの内製がスタート
- 22. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダのチカラを借りて構築 （見積もり/契約/要件定義から検収まで長い道のり）
- 23. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 （見積もり/要件定義から検収まで長い道のり） 開発ベンダに頼りきっていてはスピード感のある 開発、小さな改善のサイクルが作れない。
- 24. 2018年: 決済システムの内製へ 新システムに求めるモノ ● スピード感のある開発/リリース ● 継続的な改善のサイクル ● 監視が容易で障害に強いシステム 今までは… 案件毎に開発ベンダさんのチカラを借りて構築 （見積もり/要件定義から検収） 内製化によるスピード感のある開発 内製化による継続的な改善
- 28. 2018年: 決済システムの内製へ 導入したもの Pivotal Cloud Foundry を中心とした クラウドネイティブなプラットフォーム Concourse
- 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 日 テストされ、ビルドされたコード 本番環境へのデプロイ完了 各設定が プラットフォーム側で 自動で行われる 通常かかる時間
- 38. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application プラットフォームの構築 / 管 理 に専念 プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 3名
- 40. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 12 Factor App 契約事項は12 Factor App。 ベンダーロックインはなし。 プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 3名
- 43. 手に入れた開発のカタチ ➢ プラットフォーム / 全体のアーキテクチャ 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
- 44. syslog+TLS Logstash Elasticsearch Kibana cf pushConcourse PrometheusGrafana git push 全体アーキテクチャ cf create-service cf bind-service
- 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 アプリケーション構成①（同期 加盟店 ➡ 決済機関） 障害の伝播 処理のブロック、スレッド枯渇
- 60. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成①（同期 加盟店 ➡ 決済機関） 障害の伝播 処理のブロック、スレッド枯渇
- 61. 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 アプリケーション構成②（非同期 決済機関 ➡ 加盟店）
- 66. 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 を使用 アプリケーション構成②（非同期 決済機関 ➡ 加盟店）
- 68. Notification Gateway Receiver A Receiver B Receiver C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成②（非同期 決済機関 ➡ 加盟店）
- 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/
- 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
- 97. テスト環境リリース 本番環境リリース Concourse 開発から本番リリースまでのパイプライン 本番リリースのパイプラインはあくまで一例 ● 開発チームによる判断 ● プラットフォームチームによる判断 ● ビジネス的な判断
- 98. テスト環境リリース 本番環境リリース Concourse 開発から本番リリースまでのパイプライン CI による開発サイクル ワンクリックリリースによる CD
- 99. による負荷テスト、E2Eテスト(HTMLレポート) 開発中はJMeterによるテストを毎日継続的に自動で実行 レポートのスクリーンショットをSlackに通知 レポートのHTMLは cf push
- 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
- 107. OpenJDK 11でユニットテスト Java Buildpack 4.16でJava 11も対応 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン
- 108. OpenJDK 12でもユニットテスト 次のLTS(17)へ向けて準備 Javaの複数バージョンでのユニットテスト Java 11 リリース後のパイプライン
- 109. Javaアップデートの弊害を早期に検知
- 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
- 117. Observability ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 118. Observability ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 119. 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（回数、時間） ・クラスローダ
- 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（アクセスログ）
- 131. Kibana（アプリケーションログ）
- 135. Zipkin
- 136. トレースIDで検索可能 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 ）
- 144. 本日のまとめ ここまでの歩み ● 開発チームの立ち上げ ● 運用業務の改善活動 ● PCFを中心としたプラットフォームの導入 / 構築 ● 決済システム内製 ○ 耐障害性に優れたシステム ○ 監視の容易なシステム ○ 継続的なビルド/リリース パイプライン
- 145. 本日のまとめ これから ● リリースの建て付け ● 運用 - 障害検知/障害対応の明確化 ● 追加の開発を容易にするルール、仕組み
- 148. We are hiring! ソフトバンク・ペイメント・サービスは エンジニアを募集しています 興味がある方は @suzukij まで Pivotalジャパンは プラットフォームアーキテクト、ソリューションズアーキテクト を募集しています 興味がある方は @making まで https://pivotal.io/locations/tokyo ご清聴ありがとうございました
- 149. Transforming How The World Builds Software © Copyright 2018 Pivotal Software, Inc. All rights Reserved.