120万口座を支える証券システムのクラウド運用内製化とクラウドネイティブへの挑戦 / The challenge of making the cloud in-house and cloud-native in PayPay Securities

イベント名：CloudNative Days Winter 2024
URL：https://event.cloudnativedays.jp/cndw2024/talks/2448
日付：2024年11月28日(木)
タイトル：「120万口座を支える証券システムのクラウド運用内製化とクラウドネイティブへの挑戦」
登壇者：小森知亮（Komori Tomoaki）

PayPay証券は、証券会社としては後発ですが、現在120万を超える口座を抱えています。2016年の開始当初からAWSを利用していますが、運用は外部へ委託しており、クラウドネイティブな作りではありませんでした。
2023年より、新NISAの取り扱い開始のタイミングもあり、ユーザ増加を見越してサービス改善を図るため、クラウド運用の内製化や組織改革を始め、IaCの導入、コンテナ化、コスト最適化、セキュリティ強化などに取り組み、モダン化を進めています。これらの取り組みについての発表資料です。

Transcript

1. © PayPay証券 CloudNative Days Winter 2024 2024/11/28 120万口座を支える証券システムの クラウド運用内製化と クラウドネイティブへの挑戦 1 PayPay Securitys Corp. Product Div, Technology Dep, Cloud Infrastructure Team Tomoaki Komori (komori@paypay-sec.co.jp)
2. © PayPay証券 自己紹介 2 • 小森 知亮（Tomoaki Komori） • Cloud Infrastructure Team / Sub Leader • SIerで金融システムのBE エンジニアとして開発運用を担当 した後、2021年にPayPay証券にジョイン • システム運用やサーバリプレース作業を経て、 現在の Cloud Infrastructure Team に所属し Cloud Infra 全般の運用・改善業務に従事
3. © PayPay証券 PayPay証券 会社概要 3 会社名 PayPay証券株式会社 設立 2013年10月31日 代表者 代表取締役社長 番所 健児 所在地 東京都千代田区内幸町2-1-6 日比谷パークフロント（wework内） 資本金 1億円 事業内容 スマートフォン専業証券※ 主要株主 PayPay株式会社 みずほ証券株式会社 ソフトバンク株式会社 LINEヤフー株式会社 子会社 PPSCインベストメントサービス株式会社 ※日本初のスマートフォン専業証券として2015年に「第一種金融商品取引業者」として登録、2016年にサービス提供開始。 なお、「スマホ証券」はPayPay証券株式会社の商標登録です。
4. © PayPay証券 PayPay証券 サービス全体像 ポイント運用 資産運用 証券アプリ 6,600万人超 登録ユーザー数 ポイントで擬似運用体験 PayPayアプリで気軽に資産運用 専用アプリで本格資産運用 日本株、米国株、 投資信託、ETF、NISA 日本株、米国株、CFD、 投資信託、ETF、NISA ETFに連動する 8コース 4 ※ポイント運用はPayPay証券の子会社であるPPSCインベストメントサービス社提供のサービスになります。 ※数値は2024年9月末時点の公表値やPayPay証券社保有情報より作成 累計口座数123万口座 累計運用者数 1,800万人
5. © PayPay証券 PayPay証券 直近の口座数 2024年 新規NISA口座開設数 No.3 5 https://www.paypay-sec.co.jp/news/20241101_1.html
6. © PayPay証券 PayPay証券 システムコンポーネント 6 • 設立当初から AWS を利用 • 証券システムは全て内製 • その全てが AWS 上で稼働中 • オンプレのリソースは存在するが 一部の外部接続に関連するもののみ • 証券コア機能は EC2 や ECS で稼働
7. © PayPay証券 急成長していますが、 そこに至るまでは様々な課題が・・・ 7
8. © PayPay証券 それらの課題に対して どのように対応していったか お話します 8
9. © PayPay証券 AGENDA 9 01. AWS運用内製化までの道のり 02. さらなる効率化を求めて 03. 安定稼働させるために 04. まとめ
10. © PayPay証券 01. AWS運用内製化までの道のり 10
11. © PayPay証券 AWS運用内製化までの道のり 11 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 設立当初のシステム規模が小さいうちは問題なかったが・・・・
12. © PayPay証券 AWS運用内製化までの道のり 12 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる
13. © PayPay証券 AWS運用内製化までの道のり 13 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる
14. © PayPay証券 AWS運用内製化までの道のり 14 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる 拡張性 ・契約の都合で、利用可能な AWS機能は一部に制限 ・新たに利用したい機能があれば 事前に委託先との確認が必要
15. © PayPay証券 AWS運用内製化までの道のり 15 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる 拡張性 ・契約の都合で、利用可能な AWS機能は一部に制限 ・新たに利用したい機能があれば 事前に委託先との確認が必要 2023年5月より 事業成長を加速させるためにも AWS運用の内製化を決意！
16. © PayPay証券 AWS運用内製化までの道のり AWS運用管理内製化のスケジュール 16 2023/6 2023/7 2023/8 2023/9 AWS アカウント管理 構築業務 運用業務 監視業務 セキュリティ運用 譲渡準備 自社管理 委託先プラン 自社構築・管理 業務移管準備 [Stg] 自社運用 [Prod] 自社運用 委託先プラン（一部監視のみ） 旧サービス（委託先提供） 移行作業 新旧並行稼働 自社監視（NewRelic） 旧サービス（委託先提供） 移行作業 自社運用 • 7/3 AWS アカウント譲渡 • 8/31解約
17. © PayPay証券 AWS運用内製化までの道のり 17 内製化を行ったことで以下を実現 AWS の 構成管理・監視運用を内製化 急激なユーザ増 ・急激なユーザ増加や アプリケーションの大幅な変更 などの、変化に耐えうる Agility を確保 リードタイム ・AWS 構成変更作業が 社内で対応が完結 ・最低３営業日かかっていた ところを、最短即日で対応可能 拡張性 ・全てのAWS機能が利用可能に ・ECS や Fargate など、 契約の都合で制限されていた ものが無くなった
18. © PayPay証券 02. さらなる効率化を求めて 18
19. © PayPay証券 19 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ 内製化を行ったが課題は山積 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・
20. © PayPay証券 20 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ そのうちの２つをピックアップして説明 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・
21. © PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 21
22. © PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 22
23. © PayPay証券 さらなる効率化を求めて 23 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 インフラ基盤が手動管理のままで非効率
24. © PayPay証券 さらなる効率化を求めて 24 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 インフラ基盤が手動管理のままで非効率
25. © PayPay証券 さらなる効率化を求めて Atlantis を利用した Terraform Apply の例 25
26. © PayPay証券 さらなる効率化を求めて Atlantis を利用した Terraform Apply の例 26 Approve 後に コメントを打つことで apply 可能 Github の PR で plan 結果が確認可能 →そのままレビューを行える 問題なければ apply 後に 自動マージ
27. © PayPay証券 さらなる効率化を求めて 27 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 既存リソースの import ・既存のリソースはどうしても 手動でimport が必要 ・TerraCognita などのツールを 使って効率化 ・主要リソース（EC2/SG/ELB/S3…） は import 済 インフラ基盤が手動管理のままで非効率
28. © PayPay証券 さらなる効率化を求めて 28 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 既存リソースの import ・既存のリソースはどうしても 手動でimport が必要 ・TerraCognita などのツールを 使って効率化 ・主要リソース（EC2/SG/ELB/S3…） は import 済 インフラ基盤が手動管理のままで非効率 IaCの導入により AWS運用管理の効率化を実現
29. © PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 29
30. © PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 30
31. © PayPay証券 さらなる効率化を求めて 31 アプリ基盤が手動管理のままで非効率 スケールが手動 ・キャンペーンなどでアクセス増 が見込まれる場合は、事前に 手動でサーバを増設 ・増設後は頃合いを見計らって 手動でサーバを削除 設定が秘伝のタレ化 ・当初構築の手順が残っていない ・既存サーバをコピーして作成 動くには動くが、全体の設定が どうなっているか把握しづらい デプロイが手動 ・踏み台サーバから手動で デプロイシェルを実行 ・単純なデプロイだけだとしても 本番環境へのアクセスが必要
32. © PayPay証券 さらなる効率化を求めて 32 アプリ基盤が手動管理のままで非効率 スケールが手動 ・キャンペーンなどでアクセス増 が見込まれる場合は、事前に 手動でサーバを増設 ・増設後は頃合いを見計らって 手動でサーバを削除 設定が秘伝のタレ化 ・当初構築の手順が残っていない ・既存サーバをコピーして作成 動くには動くが、全体の設定が どうなっているか把握しづらい デプロイが手動 ・踏み台サーバから手動で デプロイシェルを実行 ・単純なデプロイだけだとしても 本番環境へのアクセスが必要 Web/APIサーバを対象に Docker化を行いECSに移行
33. © PayPay証券 さらなる効率化を求めて 33 Web/APIサーバを Docker化 ECSによりスケールが容易 ・EC2 + ECS 構成を採用し、 App の修正を少なく Docker化 ・ECS によりスケールが容易に ・AutoScaling も設定可能 設定の明確化 ・App 側は Dockerfile などで 必要な設定を明確に定義 ・EC2 側は直近の公式イメージ を利用して必要な設定を 起動時に実行 デプロイの自動化 ・CodePipeline を導入し デプロイを自動化、実行が容易に ・承認プロセスを挟むことで 安全なデプロイが可能
34. © PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 App を Docker 化し ECS で稼働させ効率化 内製化後の課題を順次解決 34
35. © PayPay証券 35 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ まだまだ課題は存在 IaC の導入・自動化 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ Docker 化・ECS 導入
36. © PayPay証券 36 さらなる効率化を求めて 36 運用監視を更に 効率化するにはどうすれば・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ それぞれの課題に対応していった Zabbix の廃止・ New Relic への移行 PagerDuty の導入 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ システム部門の再編 Dev/Ops の統合 Savings Plan / Reserved Instance の利用 Cost anomaly によるチェック AWS管理を内製化したものの 相変わらず手動管理のまま・・・ アプリの改修スピードを 更に向上させるには・・・ IaC の導入・自動化 Docker 化・ECS 導入
37. © PayPay証券 03. 安定稼働させるために 37
38. © PayPay証券 安定稼働させるために 38 DB の性能限界 ・DB の CPU 不足による障害が発生 ・その都度、スペックアップで対応 ・最終的には選択できる最大スペック まで拡張、後が無い状況 App のボトルネック ・App によるスロークエリが多発 ・ログ出力が十分でなく、原因調査に 行き詰まることが多く改善に 時間がかかる ユーザ数増加を迎えるための安定性の課題
39. © PayPay証券 安定稼働させるために 39 問題の可視化を実施 New Relicの活用拡大 ・AWS 運用内製化により監視業務の 移行先として利用していた New Relic の活用を拡大 ・全てのサーバに対して Agent を導入 APM の活用 ・APM を各サーバに導入 ・APM の機能で、ボトルネックとなっている クエリやAPIの特定が容易に ・パフォーマンス検証環境で改善・検証
40. © PayPay証券 安定稼働させるために APM の表示例 40
41. © PayPay証券 安定稼働させるために APM の表示例 41 API毎に実行回数や処理時間の 情報が表示可能 →ボトルネックとなっている処理の特定が容易に
42. © PayPay証券 安定稼働させるために APM の表示例 42
43. © PayPay証券 安定稼働させるために APM の表示例 43 Transaction のデータから 実行しているDBのクエリも確認可能 →Slow Query となっている対象が見つけられる
44. © PayPay証券 安定稼働させるために DB の CPU 使用率が改善 44
45. © PayPay証券 安定稼働させるために DB の CPU 使用率が改善 45 App を改善しスロークエリを解消 通常ピークの３倍のトラフィックを 処理できるまで改善 上記改善により、インフラ面のキャパシティも最適化 ３０％を超えるシステムコストの削減も達成
46. © PayPay証券 46 安定稼働させるために 46 AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ それぞれの課題に対応していった Zabbix の廃止・ New Relic への移行 PagerDuty の導入 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ システム部門の再編 Dev/Ops の統合 Savings Plan / Reserved Instance の利用 Cost anomaly によるチェック New Relicを活用し ボトルネックを検知 パフォーマンスを改善 IaC の導入・自動化 Docker 化・ECS 導入
47. © PayPay証券 03. まとめ 47
48. © PayPay証券 まとめ 48 業容拡大に伴い AWS 運用を内製化、Agility を確保 IaC の導入や Docker 化などのクラウドネイティブ化により さらなる効率化を実現 New RelicのAPM を活用したパフォーマンス改善により 通常ピークの３倍までの性能を確保 ２ １ ３
49. © PayPay証券 今後の更なるユーザ増に向けて ユーザの皆様に良い体験ができるよう 改善し続けます！ 49
50. © PayPay証券 Thank you! 50