CloudNativeな決済サービスの開発と2年間の歩み

CloudNativeな決済サービスの開発と2年間の歩み Spring Fest 2020 #jsug #sf_A4 Dec 17 2020
Junya Suzuki (@suzukij), SB Payment Service, [email protected]

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

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

今日お話すること • 決済サービス/システム概要 • 安定した開発/運用を支える取り組み ◦ プラットフォーム / 全体のアーキテクチャ ◦
アーキテクチャ ◦ CI / CD パイプライン ◦ Observability • これまでの歩み

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

今日お話すること • 決済サービス/システム概要

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

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

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

加盟店に決済APIを提供するシステムクレジット携帯キャリア決済コンビニ支払いプリペイドカード口座振替ポイント支払いアカウント連携決済当社システム概要オンライン決済サービス決済サービス全て一本化当社当社 API型決済手段 40 種以上に対応

加盟店に決済APIを提供するシステムクレジット携帯キャリア決済コンビニ支払いプリペイドカード口座振替ポイント支払いアカウント連携決済取扱高 3兆5,361 億円 (2019年実績) システム概要オンライン決済サービス決済サービス全て一本化当社当社 API型

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

• 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢ アーキテクチャ ➢ CI/CD
パイプライン ➢ Observability

syslog+TLS Logstash Elasticsearch Kibana cf push Concourse Prometheus Grafana git
push 全体のアーキテクチャ cf create-service cf bind-service Tanzu Application Service

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 • 安定した開発/運用を支える取り組み ➢ プラットフォーム / 全体のアーキテクチャ ➢
アーキテクチャ ➢ CI/CD パイプライン ➢ Observability

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

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

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 当社決済システムアプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 決済機関システムクレジット、コンビニ支払い、キャリア決済、プリペイドカード、その他アプリケーション構成（同期加盟店 ➡ 決済機関）

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Appはマイクロサービスの構成ですべてTAS上に配置アプリケーション構成（同期加盟店 ➡ 決済機関） Tanzu Application Service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 非同期を実現するために RabbitMQ + Spring Cloud Stream を使用

Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C

Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C 特定の加盟店で障害が発生した場合

Receiver C Hystrix Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Dead Letter Queue と呼ばれるキューに退避して、後に再送

Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Circuit Breakerにより、他の加盟店に影響を及ぼさない Hystrix

Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix 2年間の運用後年に数回DLQ行きが発生対象メッセージのケース毎に何をしなければいけないか運用を固めていなかったため対応が煩雑に。頻度が低いとはいえ再送の自動化対応等を事前にしておけばよかったと反省…

Receiver C Hystrix Hystrix Hystrix Tanzu Application Service 加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Hystrix RabbitMQの運用は初だったが2年間トラブルゼロノードダウンやメッセージパブリッシュの停止等は全く発生せず安定して稼働している。 2年間の運用後

ライブラリの移行について

CircuitBreaker (Hystrix -> Resilience4J) 2018/11から maintenance mode Resilience4J Hystrix •
CircuitBreaker • Bulkhead • RateLimiter

CircuitBreaker (Resilience4J) API Gateway Service A Service B Service C
加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J CircuitBreaker 決済機関のシステムエラー率が100%の状態で2分継続したらサーキットオープン

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J CircuitBreaker (Resilience4J)

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J エラーしきい値がデフォルト50%だが弊社は100%に設定 CircuitBreaker (Resilience4J)

どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー決済機関障害発生 CircuitBreaker (Resilience4J)

どうしてエラー率50%でサーキットオープンではダメなのか？ ※サーキットオープンになりにくい設定たとえば以下のエラー率が60%の状態の場合 ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー決済機関障害発生サーキットオープンサーキットオープンによる機会損失が発生 CircuitBreaker
(Resilience4J)

決済サービスでは1件でも正常に取引されているトランザクションがある限りサーキットオープンにはしたくない ◆決済完了　◆決済機関システムエラー決済機関障害発生 CircuitBreaker (Resilience4J)

決済サービスでは1件でも正常に取引されているトランザクションがある場合はサーキットオープンしたくないとはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社への障害の伝播を防ぎたい決済機関障害発生 ◆決済完了　◆決済機関システムエラー　タイムアウトやレスポンス遅延による障害伝播の恐れ CircuitBreaker (Resilience4J)

決済サービスでは1件でも正常に取引されているトランザクションがある場合はサーキットオープンしたくないとはいえ最悪の状態(100%システムエラー、レスポンスタイムアウト)では当社への障害の伝播を防ぎたい ◆決済完了　◆決済機関システムエラー　 ◆サーキットオープンによるトランザクションエラー決済機関障害発生サーキットオープンにより即エラーを返すことで障害伝播を防ぐ CircuitBreaker
(Resilience4J)

Bulkhead (Resilience4J) API Gateway Service A Service B Service C
加盟店 A 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J Bulkhead（並列処理数の制限）同時接続数が設定値を超過したらリジェクト

加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service Resilience4J Resilience4J Resilience4J Resilience4J Bulkhead 同時接続数が設定値を超過したらリジェクト Bulkhead (Resilience4J)

Tanzu Application Service Bulkhead (Resilience4J) Service A 決済機関 A Bulkhead
1 2 3 4 5 reject

1 2 3 4 5 reject ウチのシステムは負荷に弱いので同時接続数 5 でお願いします

Bulkheadの並列実行数に5を設定した場合、決済機関Aへの同時接続数 5本が上限となる同時接続数が5以上はリジェクトとして扱われる Bulkhead 1 2 3 4 5 reject

1 2 3 4 5 reject Bulkheadの設定を導入し決済機関に限界以上の負荷を与えないように

追加開発の新規アプリケーションから WebClientで実装、リリース済 Http Client (RestTemplate -> WebClient) RestTemplateのJavadoc 「メンテナンスモードのためWebClientの使用を検討してください」
※RestTemplateはまだ非推奨とはなっていない

移行で発生した問題1 • 接続タイムアウト、Read/Writeタイムアウトの設定 ◦ reactor-nettyのTcpClientにそれぞれタイムアウトを設定 Http Client (RestTemplate -> WebClient)

Http Client (RestTemplate -> WebClient) 移行で発生した問題2 • レスポンスのサイズが256KBを超過すると例外が発生 ◦ codecsのmaxInMemorySizeを設定
org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer

Http Client (RestTemplate -> WebClient) 移行で発生した問題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

Http Client (RestTemplate -> WebClient) WebFluxは一切使用しておらずWebClientはブロッキングして使用しているものの RestTemplate と同等のパフォーマンスが出ていることが確認できたため移行した。
2020/8から現在まで本番環境で稼働しているが問題は一切発生していない状態。 Spring MVCを使っている場合、並行リクエストが多用されていないのであれば移行の恩恵はあまりないためRestTemplateが非推奨にならない限りは急ぐ必要はない印象。

開発体制 API Gateway Service A Service B 加盟店 X 加盟店
Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service 新規機能は方式検討から実装、テストまで内製

Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C

Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は外部ベンダさんに依頼

Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C 似た機能の展開は外部ベンダさんに依頼 Service D 決済機関 D

Y 加盟店 Z 決済機関 A 決済機関 B Tanzu Application Service Service C 決済機関 C Service D 決済機関 D 外部ベンダさんの協力を得ながらサービスを横展開することができた。自分達は新規技術や新方式を採用したアプリケーションの検証/開発に注力することができた。

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

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

Concourse - ジョブ一覧画面

Concourse - パイプライン画面

パイプライン全体のジョブ構成ジョブ設定は YAMLファイルで管理 Concourse - パイプライン画面 - 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

リポジトリの更新がトリガ Concourse - パイプライン画面

Concourse - パイプライン画面

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

Concourse 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境各種ブランチへの更新がトリガ

Concourse 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境 Javaの各種バージョンでテストアップデートの弊害を早めに検知

Concourse 開発から本番リリースまでのパイプラインテスト環境開発環境本番環境 SonarQubeによるコード解析コードの品質をいつでも確認できるようにしておく

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

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

Concourse 開発から本番リリースまでのパイプライン開発環境本番環境テスト環境 masterブランチへのマージで Nexus RELEASEリポジトリへデプロイ本番環境リリースへの準備が完了

Concourse 開発から本番リリースまでのパイプライン本番環境ワンクリックリリースによるCD Nexusのリリースリポジトリの成果物が本番環境に適用される Blue-Green Deployによってサービスへの影響なくリリースが可能

Concourse 開発から本番リリースまでのパイプライン本番環境トラブル時の切り戻しの際も数クリックのみの対応 ※幸いにもまだやったことないです

Concourse 開発から本番リリースまでのパイプライン本番環境リリースや切り戻し手順がシンプルなためテレワークで自宅からもリリースが可能

によるパフォーマンステスト API Gateway Service A Service B Service C 決済機関
B Mock 決済機関 A Mock 決済機関 C Mock Tanzu Application Service

• Load test • Soak test によるパフォーマンステスト

Load Test - 想定の20倍のスループットを目標問題原因 Webスレッドプールが枯渇 Webスレッドプール数の設定ミス HTTP送信時にスループットが上がらない HttpClient4
の PoolingHttpClientConnectionManager のプール数の設定漏れ SQLの実行時のスループットが上がらない HikariCP DBコネクションプールの設定ミス Circuit Breakerの想定外のサーキットオープン Hystrixのチューニングミス RabbitMQのメッセージキューイングが停止 RabbitMQのメモリ枯渇（スケールアップ対応） RabbitMQのConsumerのスループットが上がらない StreamListenerのワーカースレッド数が不足アプリケーション全体の負荷限界アプリケーションインスタンス数の不足 ※PaaSというかBuildpackのおかげでJVMのチューニングは不要だった　（いつも必ず対応するやつ）

Soak Test (1週間, 168時間)

Load test and E2E test by 開発期間中にはJMeterによるロードテストとE2Eテストを毎日自動で実行し、結果のスクリーンショットをSlackで通知 Report html
cf push

Load test and E2E test by During development, JMeter tests
are automatically executed every day. Notify Slack of report screenshot. パフォーマンステストは開発期間中に何度も繰り返し実行して改善を続けることが大事

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

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

Grafana(Micrometer) Metrics

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

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

Kibana（アクセスログ） Logging

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

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

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

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

Kibana（ECSロギングの活用） Logging Elastic Common Schema（ECS）でアプリケーションログのフォーマットを統一 / 構造化 ECSはElasticsearchで管理しやすいログの定義/仕様のこと Spring
Bootアプリの場合、依存を追加するだけでアプリケーションログをいい感じに構造化したJSONフォーマットのログにしてくれる。あとはそのままログをElasticsearchに突っ込むだけ。 ※ECS Logging Java Reference　 https://www.elastic.co/guide/en/ecs-logging/java/current/index.html

Kibana（ECSロギングの活用） Logging Elastic Common Schema（ECS）でアプリケーションログのフォーマットを統一 / 構造化 ECSはElasticsearchで管理しやすいログの定義/仕様のこと Spring
Bootアプリの場合、依存を追加するだけでアプリケーションログをいい感じに構造化されたJSONフォーマットのログにしてくれる。あとはそのままログをElasticsearchに突っ込むだけ。 ※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>

Kibana（ECSロギングの活用） Logging 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だと構造化ロギングに対応してるので良さそう。

Kibana（ECSロギングの活用） Logging 例外情報もきちんと構造化タイムスタンプホスト名ログレベルログメッセージスレッド名例外クラス例外メッセージ
スタックトレース

Kibana（ECSロギングの活用） Logging

ログレベル別ログ出力数ログレベル別 Kibana（ECSロギングの活用） Logging アプリケーション別ログ出力数アプリケーション別

Kibana（ECSロギングの活用） Logging Exceptionクラス別ログ出力数 Exceptionクラス別開発中のDB failoverテスト

Kibana（ECSロギングの活用） Logging WARNレベル/ERRORレベルのログ出力数が増加一時的に例外が発生その後、自動的に復旧その後、例外の発生なし開発中のDB failoverテスト

Kibana（ECSロギングの活用） Logging

Kibana（ECSロギングの活用） Logging 決済結果別 HTTPステータス別決済手段別加盟店別ユーザエージェント別 API別リモートIP別処理時間
エラーコード別

Kibana（ECSロギングの活用） Logging リッチなダッシュボードを実現求めるダッシュボードから逆算してロギング設計をする

Zipkin Tracing

Zipkin Tracing Spring Cloud Sleuthによってアプリログに出力されるトレースIDで検索可能

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

Zipkin Tracing 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, 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 Tracing Zipkinにトレースを送信する割合本番環境でも 1.0 (100%) を指定している

Zipkin Tracing Zipkinのデータストアに Elasticsearchを指定してKibanaで独自ダッシュボードを作成

Zipkin Tracing 処理時間がかかっているリクエストを特定

Zipkin Tracing 特定したリクエストのトレースIDをクリックすると Zipkinへジャンプ

Zipkin Tracing API Gateway Service A 決済機関
内部システムトレース情報

内部システム内部システムがAPI-Gatewayを呼び出して応答されるまでの時間が長い（6.98秒）

内部システム API-GatewayがServiceAを呼び出して応答されるまでの時間が長い（6.56秒）

内部システム ServiceAが決済機関を呼び出して応答を待つ時間が長い（6.53秒）

内部システム原因は決済機関のレスポンス待ち全体の処理時間 6.98秒に対して6.53秒を要していたことが視覚的に把握できる

内部システム Zipkinのおかげで分散してしまっている各アプリケーションのログからトレースを追わずに済み、効率良く調査ができるようになった

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

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

サービス目線のモニタリング Biz 決済数取扱高前日比・傾向内訳分類 XX,XXX X,XXX,XXX,XXX XXX,XXX
X,XXX,XXX,XXX

サービス目線のモニタリング Biz 決済数取扱高前日比・傾向内訳分類 XX,XXX X,XXX,XXX,XXX XXX,XXX
X,XXX,XXX,XXX 加盟店のシステム障害加盟店のシステム障害

XX,XXX X,XXX,XXX,XXX XXX,XXX X,XXX,XXX,XXX 加盟店へリアルタイムに状況を共有、さらには加盟店自身も見落としていた障害を検知サービス目線のモニタリング Biz

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

• これまでの歩み

プラットフォーム導入の効果 Before After Release リリース作業手作業ワンクリックリリース品質人為的なミスの可能性あり自動化によりミスなし
リリース時間 45分 5分 Observability ログ調査ログファイルから調査 Kibanaダッシュボードサーバメトリクス調査ログファイルから調査 Grafanaダッシュボードトレース調査なし Zipkinダッシュボード Resilience 障害時の自動復旧なし自動再起動スケールアウト手作業管理画面から数クリック

アーキテクチャのアップデートサービス開始時 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

サービスの広がりサービス開始時 2年経った現在システム数 1システム 3システム ⤴ App数 12アプリケーション 22アプリケーション
⤴ Appインスタンス数 45インスタンス 57インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 15名（開発ベンダ2社 6名含む） ⤴ このシステムの障害件数 - 0件

本日のまとめ

技術的なアップデートをしながらサービスの拡張や機能追加ができている。まとめ自分たちのシステムをプラットフォームから構築しサービスの運用開始から2年間、大きな障害もなく運用することができた。リリース作業やログ調査も非常に効率良く運用できている。

さいごにサービス開始から2年間、大きな障害もなく運用することができましたが、歩みを止めることなく加盟店/エンドユーザの方々に高い品質のサービスを提供したい。堅牢、安全、1件1円間違えのない、障害に強いシステムを目指して

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

CloudNativeな決済サービスの 開発と2年間の歩み

CloudNativeな決済サービスの 開発と2年間の歩み

More Decks by suzukij

Other Decks in Programming

Featured

Transcript

CloudNativeな決済サービスの開発と2年間の歩み

CloudNativeな決済サービスの開発と2年間の歩み