CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
•
4 likes•4,380 views
Spring Fest 2020 CloudNativeな決済サービスの開発と2年間の歩み SBペイメントサービスではSpringとTanzu Application Serviceを使用して、決済システムを運用、開発しております。 以前SpringFest2018で登壇した際は、プロダクション環境で稼働するまでのストーリーをご紹介しましたが、今回はその後の運用や開発についてお伝えしたいと思っています。 本セッションでは導入の背景や、Spring Boot/Cloudを利用したアーキテクチャの説明、CI/CDやロギング・モニタリング、高レジリエンスへの取り組み内容を改めてご紹介します。 またプラットフォームの導入が開発や運用にどのような効果をもたらしたのか、プロダクションでの運用を安定化させるために行ってきた施策や、運用/開発する中で発生した事象とその対処についてもご紹介する予定です。 #jsug #sf_A4
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
Similar to CloudNativeな決済サービスの開発と2年間の歩み #sf_A4 (20)
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
- 2. ペイメントサービス株式会社 シニアアーキテクト 鈴木順也 自己紹介 主な業務 ・新規サービスの開発 ・運用の効率化 改善 システムの開発に従事 元々は のプログラマ フリーランスを経て 年前に現在の会社に転職
- 5. 今日お話すること ● 決済サービス システム概要 ● 安定した開発 運用を支える取り組み ○ プラットフォーム 全体のアーキテクチャ ○ アーキテクチャ ○ パイプライン ○ ● これまでの歩み
- 6. SpringFest 2018 登壇資料 決済システムの内製化への旅 SpringとPCFで作るクラウドネイティブなシステム開発 https://www.slideshare.net/makingx/springpcf-jsug-sfh1 関連資料 Pivotal.IO 2019 登壇資料 決済システム内製化に向けた プラットフォーム構築 PCF・BOSHによるオブザーバブルプラットフォーム https://www.slideshare.net/DaichiKimura3/pcfbosh-156082821 アプリケーション開発チーム プラットフォームチーム
- 10. 決済サービス 全て一本化 当社当社 API型 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 導入実績 約 120,000 店舗 (2019年12月実績) システム概要 オンライン決済サービス
- 12. 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電子書籍/動画 チケット ECサイト向けに様々な決済手段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ支払い プリペイドカード 口座振替 ポイント支払い アカウント連携決済 取扱高 3兆5,361 億円 (2019年実績) システム概要 オンライン決済サービス 決済サービス 全て一本化 当社当社 API型
- 14. ● 安定した開発 運用を支える取り組み ➢ プラットフォーム 全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢
- 15. syslog+TLS Logstash Elasticsearch Kibana cf push Concourse PrometheusGrafana git push 全体のアーキテクチャ cf create-service cf bind-service Tanzu Application Service
- 16. 決済システムの内製化への旅 と で作るクラウドネイティブなシステム開発 ● 安定した開発 運用を支える取り組み ➢ プラットフォーム 全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢
- 17. アプリケーション構成（同期 加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service
- 18. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C オンラインショッピングサイト 通販サイト、ゲーム、電子書籍、 チケット、不動産、その他 アプリケーション構成（同期 加盟店 ➡ 決済機関）
- 19. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 当社 決済システム アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 20. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関システム クレジット、コンビニ支払い、キャリア決済、 プリペイドカード、その他 アプリケーション構成（同期 加盟店 ➡ 決済機関）
- 21. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Appはマイクロサービスの構成です べてTAS上に配置 アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 22. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C すべてのAppは Java/Spring Boot で実装 アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 23. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service 決済機関毎のビジネスロジックが実装さ れている へルーティング
- 24. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 25. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 加盟店や決済機関は当然、コントロール範囲外 アプリケーション構成（同期 加盟店 ➡ 決済機関）
- 26. Hystrix API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service システム間通信には Hystrix という Circuit Breakerを導入
- 27. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breakerがない状態で 決済機関Aで障害が発生した場合…
- 28. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service レスポンス遅延、タイムアウト
- 29. アプリケーション構成（同期 加盟店 ➡ 決済機関） API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Service A に障害が伝播 処理のブロック、スレッド枯渇
- 30. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application ServiceAPI Gateway に障害が伝播 処理のブロック、スレッド枯渇
- 31. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application ServiceAPI Gateway に障害が伝播 処理のブロック、スレッド枯渇
- 32. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関A起因の障害にも関わらず 関係のない決済機関BCへ影響が出てしまう アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 33. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Hystrix アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service Circuit Breaker があれば 特定の決済機関で障害が発生しても
- 34. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix 障害の伝播を防いでくれるため 他の決済機関へ影響を及ぼす心配がない アプリケーション構成（同期 加盟店 ➡ 決済機関）
- 35. API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix Hystrix Hystrix Circuit Brakerにより耐障害性に優 れたアプリケーションを実現 アプリケーション構成（同期 加盟店 ➡ 決済機関） Tanzu Application Service
- 36. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
- 37. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
- 38. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
- 39. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 非同期を実現するために RabbitMQ + Spring Cloud Stream を使用
- 40. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C
- 41. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 特定の加盟店で障害が発生した場合
- 42. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Dead Letter Queue と呼ばれるキューに 退避して、後に再送
- 43. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Circuit Breakerにより、他の加盟店に影響を 及ぼさない Hystrix
- 44. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix 2年間の運用後 年に数回DLQ行きが発生 対象メッセージのケース毎に何をしなければいけないか 運用を固めていなかったため対応が煩雑に。 頻度が低いとはいえ再送の自動化対応等を事前にして おけばよかったと反省…
- 45. アプリケーション構成（非同期 決済機関 ➡ 加盟店） Notification Gateway Receiver A Receiver B Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix RabbitMQの運用は初だったが2年間トラブルゼロ ノードダウンやメッセージパブリッシュの停止等は全く発生せず安定して 稼働している。 2年間の運用後
- 46. ライブラリの移行について
- 47. 2018/11から maintenance mode Resilience4JHystrix ● CircuitBreaker ● Bulkhead ● RateLimiter
- 48. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service CircuitBreaker 決済機関のシステムエラー率が100%の 状態で2分継続したらサーキットオープン
- 49. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service
- 50. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service エラーしきい値がデフォルト50%だが弊社 は100%に設定
- 51. どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定 たとえば以下のエラー率が60%の状態の場合 ◆決済完了 ◆決済機関システムエラー 決済機関障害発生
- 56. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Bulkhead（並列処理数の制限） 同時接続数が設定値を超過したらリジェクト
- 57. API Gateway Service A Service B Service C 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Bulkhead 同時接続数が設定値を超過したらリジェクト
- 58. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5
- 59. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5 ウチのシステムは負荷に弱いので 同時接続数 5 でお願いします
- 60. Tanzu Application Service Service A 決済機関 A Bulkhead Bulkheadの並列実行数に5を設定した場合、 決済機関Aへの同時接続数 5本が上限となる 同時接続数が5以上はリジェクトとして扱われる 1 2 3 4 5
- 61. Tanzu Application Service Service A 決済機関 A 1 2 3 4 5 Bulkheadの設定を導入し 決済機関に限界以上の負荷を与えないように
- 64. 移行で発生した問題2 ● レスポンスのサイズが256KBを超過すると例外が発生 ○ codecsのmaxInMemorySizeを設定 org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer
- 65. 移行で発生した問題3 ● ファイルディスクリプタのリークが発生 ○ Spring Boot v2.2.8 / v2.3.1の問題（Reactor Netty v0.9.8の不具合） ⇒ Spring Bootのv2.2.9 / v2.3.2のアップデートで解消 https://github.com/spring-projects/spring-boot/issues/21923 Caused by: io.netty.channel.ChannelException: io.netty.channel.unix.Errors$NativeIoException: newSocketStream(..) failed: Too many open files 2.3.2 2.3.1
- 66. WebFluxは一切使用しておらずWebClientはブロッキングして使 用しているものの RestTemplate と同等のパフォーマンスが出て いることが確認できたため移行した。 2020/8から現在まで本番環境で稼働しているが 問題は一切発生していない状態。 Spring MVCを使っている場合、並行リクエストが多用されていな いのであれば移行の恩恵はあまりないためRestTemplateが非推 奨にならない限りは急ぐ必要はない印象。
- 67. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service 新規機能は方式検討から 実装、テストまで内製
- 68. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C
- 69. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は 外部ベンダさんに依頼
- 70. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は 外部ベンダさんに依頼 Service D 決済機関 D
- 71. 開発体制 API Gateway Service A Service B 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C Service D 決済機関 D 外部ベンダさんの協力を得ながらサービスを横展開す ることができた。 自分達は新規技術や新方式を採用したアプリケーショ ンの検証/開発に注力することができた。
- 72. 決済システムの内製化への旅 と で作るクラウドネイティブなシステム開発 ● 安定した開発 運用を支える取り組み ➢ プラットフォーム 全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢
- 75. ジョブ一覧画面
- 76. パイプライン画面
- 77. パイプライン全体のジョブ構成 ジョブ設定は YAMLファイル で管理 パイプライン画面 - task: mvn-test config: platform: linux image_resource: type: registry-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 test
- 79. パイプライン画面
- 80. パイプライン画面
- 92. によるパフォーマンステスト API Gateway Service A Service B Service C 決済機関 B Mock 決済機関 A Mock 決済機関 C Mock Tanzu Application Service
- 94. 想定の 倍のスループットを目標 問題 原因 スレッドプールが枯渇 スレッドプール数の設定ミス HTTP送信時にスループットが上がらない の のプール数の設定漏れ の実行時のスループットが上がらない コネクションプールの設定ミス Circuit Breakerの想定外のサーキットオープン のチューニングミス のメッセージキューイングが停止 のメモリ枯渇（スケールアップ対応） の のスループットが上がらない のワーカースレッド数が不足 アプリケーション全体の負荷限界 アプリケーションインスタンス数の不足 ※ というか のおかげで のチューニングは不要だった （いつも必ず対応するやつ）
- 95. 週間 時間
- 98. 決済システムの内製化への旅 と で作るクラウドネイティブなシステム開発 ● 安定した開発 運用を支える取り組み ➢ プラットフォーム 全体のアーキテクチャ ➢ アーキテクチャ ➢ パイプライン ➢
- 99. ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 100. ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 101. ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 102. ※Metrics, tracing, and logging https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
- 103. の監視 ● 全 のメトリクス ● 全コンテナのメトリクス ● の各コンポーネントのメトリクス ● ミドルウェアのメトリクス ○ の監視 ● 全 アプリ のメトリクス での監視対象 30種以上のダッシュボード
- 107. （アクセスログ）
- 109. （アプリケーションログ）
- 112. （ ロギングの活用） （ ）で アプリケーションログのフォーマットを統一 構造化 は で管理しやすいログの定義 仕様のこと アプリの場合、依存を追加するだけでアプリケーション ログをいい感じに構造化した フォーマットのログにしてくれ る。 あとはそのままログを に突っ込むだけ。 ※ECS Logging Java Reference https://www.elastic.co/guide/en/ecs-logging/java/current/index.html
- 113. （ ロギングの活用） （ ）で アプリケーションログのフォーマットを統一 構造化 は で管理しやすいログの定義 仕様のこと アプリの場合、依存を追加するだけでアプリケーション ログをいい感じに構造化された フォーマットのログにしてくれ る。 あとはそのままログを に突っ込むだけ。 ※ECS Logging Java Reference https://www.elastic.co/guide/en/ecs-logging/java/current/index.html ecs-logging-java <dependency> <groupId>co.elastic.logging</groupId> <artifactId>log4j2-ecs-layout</artifactId> <version>${ecs-logging-java.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j2</artifactId> </dependency>
- 114. （ ロギングの活用） ecs-logging-java <dependency> <groupId>co.elastic.logging</groupId> <artifactId>log4j2-ecs-layout</artifactId> <version>${ecs-logging-java.version}</version> </dependency> ※実装がLogback, Log4j2, Log4j, JUL, JBoss Log Manager から選択できるがLog4j2だと構造化ロギングに対 応してるので良さそう。
- 116. （ ロギングの活用）
- 120. （ ロギングの活用）
- 121. （ ロギングの活用） 決済結果別 HTTPステータス別 決済手段別 加盟店別 ユーザエージェント別 API別リモートIP別 処理時間エラーコード別
- 126. Zipkin, Spring Cloud Sleuth <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> ※Spring Boot v2.4.0以降は spring-cloud-sleuth-zipkin spring.sleuth.sampler.probability: 1.0
- 127. Zipkin, Spring Cloud Sleuth <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> ※Spring Boot v2.4.0以降は spring-cloud-sleuth-zipkin spring.sleuth.sampler.probability: 1.0 Zipkinにトレースを送信する割合 本番環境でも 1.0 (100%) を指定している
- 129. 処理時間がかかっているリクエストを特定
- 135. APIGateway ServiceA 決 済 機 関 内 部 シ ス テ ム 原因は決済機関のレスポンス待ち 全体の処理時間 6.98秒に対して6.53秒を要 していたことが視覚的に把握できる
- 141. サービス目線のモニタリング 決済数 取扱高 前日比・傾向 内訳 分類 XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX加盟店の システム障害 加盟店の システム障害
- 142. XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX 加盟店へリアルタイムに状況を共有、 さらには加盟店自身も見落としていた障害を検知 サービス目線のモニタリング
- 143. サービス目線のモニタリング 決済数 取扱高 前日比・傾向 内訳 分類 アプリをリリースするだけで プラットフォームが自動で監視対象に Metrics Logging Tracing + Biz
- 144. ● これまでの歩み
- 145. プラットフォーム導入の効果 Before After Release リリース作業 手作業 ワンクリック リリース品質 人為的なミスの可能性あり 自動化によりミスなし リリース時間 45分 5分 Observability ログ調査 ログファイルから調査 Kibanaダッシュボード サーバメトリクス調査 ログファイルから調査 Grafanaダッシュボード トレース調査 なし Zipkinダッシュボード Resilience 障害時の自動復旧 なし 自動再起動 スケールアウト 手作業 管理画面から数クリック
- 146. アーキテクチャのアップデート サービス開始時 2年経った現在 PaaS Platform Java Java 8 Java 11 Spring Boot v2.1.2 v2.3.5 Spring Cloud Greenwich. RELEASE Hoxton.SR8 ライブラリ Http Client RestTemplate WebClient ライブラリ CircuitBreaker Hystrix Resilience4J
- 147. サービスの広がり サービス開始時 2年経った現在 システム数 1システム 3システム ⤴ App数 12アプリケーション 22アプリケーション ⤴ Appインスタンス数 45インスタンス 57インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 15名（開発ベンダ2社 6名含む） ⤴ このシステムの障害件数 - 0件
- 148. 本日のまとめ