【Spring Fest 2018 レポート】決済システムの内製化への旅 – SpringとPCFで作るクラウドネイティブなシステム開発 #jsug #sf_h1

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

セッションの概要

ソフトバンク・ペイメント・サービス株式会社ではSpringとPivotal Cloud Foundryを使用して、次期決済システムを内製で構築しています。本セッションでは導入の背景や、Spring Boot/Cloudを使用したアーキテクチャの説明、CI/CDやロギング・モニタリングなど取り組み内容のご紹介とあわせて、プラットフォームの導入が開発にどのような効果をもたらすのかをお伝えします。Cloud Foundryを使用した事例となりますが、セッションの内容は他のプラットフォームについても当てはまることが多いため、Spring + クラウドネイティブなプラットフォームの導入を検討をされている方はぜひご参加ください。

SPRING FEST 2018

スライド

レポート

内製化に至る道のり

2016年

チームを作った。

2017年

• 監視の質を高めるためElasticStackによるダッシュボードを導入
• 開発プロジェクトの支援を始める
  • 古いシステムだけではなく、新規で作るシステムもアーキテクチャが古かったりした
    • プロジェクトによってCI入れてたり入れてなかったりした
      • CI入れることを当たり前にした

2018年

• 内製はじまった。

新システムについて

• ベンダの力を借りると開発そのもの以外のところで時間がかかりすぎる問題があった。
  • 内製化
  • Pivotal Cloud Foundry導入

なぜPivotal Cloud Foundryか

Pivotal Cloud Foundryとは

以下の3つがある。

• Pivotal ApplicationService
  • サービスとして提供されるCloud Foundry
  • PaaS
• Pivotal Container Service(PKS)
  • マネージドKubernetes
• Pivotal Function Service(PFS)
  • Knativeベースのサーバーレスプラットフォーム
  • 未リリース

決済システムではPivotal Application Serviceを使っている。

Pivotal Application Service

PaaSを使うことでアプリ開発に集中できる。

開発者視点で色々したくない

• ビジネス的にメリットのあることをしたい
  • とにかくアプリ書いてデプロイ
• コンテナのプラットフォームごと管理できる環境はなんでもできるが、なんでもやらないといけない

jar作ってコマンド打つだけでデプロイされる

• モニタリングとかロギングとかはよしなに色々してくれる
• ベンダーに依頼するとこから含めると、この辺りの整備だけで1ヶ月〜2ヶ月かかってた

12 Factor Appに則って作ればPaaS上で動く

• ベンダーロックインしない
• 基本的に他のプラットフォームでも動く

アーキテクチャ

PaaSで動くものと、プラットフォームの管理でチームが分かれている。前者はアプリケーションに集中できる。

アプリケーションの構成

同期処理（加盟店からのリクエスト→API Gateway→各サービス→決済機関）

Circuit Breaker（Hystrix）を導入している。Circuit Breakerがないと障害が伝播する。 例えば決済機関(連携している外部システム）の障害が各サービスの障害に繋がり、それがAPI Gatewayに伝播することで関係ない内部サービスに障害が伝播してしまう。

決済機関は外側の世界なのでコントロールできない。ここの影響でサービスの影響を広げてはいけない。

非同期

• 決済機関→各サービス→API Gateway→加盟店のようなケース
  • RabbitMQ+Spring Cloud Stream
  • 加盟店側が通知を受け取れなかった場合、DeadLetterQueue経由で後から再送
  • ここもircuit Breakerで他の加盟店に影響を与えないようにする

• 加盟店から決済機関への非同期処理の場合
  • 加盟店→APIGateway→Queue→各サービス

Pivotal Cloud Foundry App Autoscale

• オートスケールのための機能
• インスタンス数設定したりスケールのルールを指定しておいて、条件に合わせてインスタンスの数をコントロールできる
  • 管理コンソールだけで操作できる

12 Factor Appの実装面における重要な5つの項目

12 Factor Appにおいて、実装において重要なのは以下の５つ。

• III.設定
  • 設定を環境変数に格納する
• V. ビルド、リリース、実行
  • ビルド、リリース、実行の3つのステージを厳密に分離する
• VI. プロセス
  • アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
• VII.ポートバインディング
  • ポートバインディングを通してサービスを公開する
• XI. ログ
  • ログをイベントストリームとして扱う

（The Twelve-Factor App （日本語訳） より。）

このうちV、VI、VIIはCloud FoundryとSpring Bootで開発すれば満たされる。

• XI.ログは標準出力に出すとプラットフォームが集約するようになっている。
  • ただしロストがあるので、絶対に落としたくないものはRDBへ
    • トランザクションデータとして考える

CI/CD

GitHubをトリガーに→Concourseをキックして→PaaSにデプロイ

Concourse

• ステータスが視覚的にわかりやすい（成功、失敗、実行中）
• パイプラインの流れも図示されてわかりやすい
  • パイプラインの各タスクのステータスも視覚的にわかる
• 設定はyamlで管理
• デプロイはNexus→PaaS
• トリガーはGitHub

負荷テスト

• 毎日継続的にJmeterで負荷テストをしている
  • レポートのスクリーンショットをSlackに通知

Javaのバージョンアップについて

• Java 8でテストしつつ、9,10,11も同時にテストしていた
• Concorceは簡単に並列で複数のバージョンテストできる
• これやることで、事前にJava 11にした時何が起こるのかあらかじめわかる
• Java 8, Java 12で成功して、Java 11で失敗するケースがあった
  • JDKの不具合
    • Java 12では修正されてたけどJava 11のバックポートではまだfixしてなかった
• Java 11リリース後はJava 12と並列でテストをしている
• アップデートで何が起きるのか早く気づける
• アップデートし続けられる環境を準備する

Ovservability

それぞれ以下を利用している。

• metrics
  • Grafana, Prometeus, Micrometer
• Logging
  • Elastic Stack
• trasing
  • Zipkin

Grafana

• BOSHで入れるとダッシュボードとかアラートがプリセットで入ってる
  • ログで見てたメトリクスがダッシュボードで見れるようになった

Zipkin

• トレースIDで検索するとサービス間連携のどのサービスでどれくらい時間かかってるかわかる
• Brave MySQL
  • ZipkinにSQLの内容と所要時間をレポートできる

感想

個人的には以下のあたりが気になりました。

• 負荷テストを毎日動かしている
• CIでのテストを複数のJavaのバージョンで行うことで、アップデートできる環境を準備
• Brave MySQLによるSQLの内容と所要時間のレポート

CIで担保できるものはなんでも担保していく、という方向性がすごく良いなと思います。

私からは以上です。