Tweet
Tweet

Slide 1

Slide 1 text

© 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)

Slide 2

Slide 2 text

© PayPay証券 自己紹介 2 ● 小森 知亮（Tomoaki Komori） ● Cloud Infrastructure Team / Sub Leader ● SIerで金融システムのBE エンジニアとして開発運用を担当 した後、2021年にPayPay証券にジョイン ● システム運用やサーバリプレース作業を経て、 現在の Cloud Infrastructure Team に所属し Cloud Infra 全般の運用・改善業務に従事

Slide 3

Slide 3 text

© PayPay証券 PayPay証券 会社概要 3 会社名 PayPay証券株式会社 設立 2013年10月31日 代表者 代表取締役社長 番所 健児 所在地 東京都千代田区内幸町2-1-6 日比谷パークフロント（wework内） 資本金 1億円 事業内容 スマートフォン専業証券※ 主要株主 PayPay株式会社 みずほ証券株式会社 ソフトバンク株式会社 LINEヤフー株式会社 子会社 PPSCインベストメントサービス株式会社 ※日本初のスマートフォン専業証券として2015年に「第一種金融商品取引業者」として登録、2016年にサービス提供開始。 なお、「スマホ証券」はPayPay証券株式会社の商標登録です。

Slide 4

Slide 4 text

© PayPay証券 PayPay証券 サービス全体像 ポイント運用 資産運用 証券アプリ 6,600万人超 登録ユーザー数 ポイントで擬似運用体験 PayPayアプリで気軽に資産運用 専用アプリで本格資産運用 日本株、米国株、 投資信託、ETF、NISA 日本株、米国株、CFD、 投資信託、ETF、NISA ETFに連動する 8コース 4 ※ポイント運用はPayPay証券の子会社であるPPSCインベストメントサービス社提供のサービスになります。 ※数値は2024年9月末時点の公表値やPayPay証券社保有情報より作成 累計口座数123万口座 累計運用者数 1,800万人

Slide 5

Slide 5 text

© PayPay証券 PayPay証券 直近の口座数 2024年 新規NISA口座開設数 No.3 5 https://www.paypay-sec.co.jp/news/20241101_1.html

Slide 6

Slide 6 text

© PayPay証券 PayPay証券 システムコンポーネント 6 ● 設立当初から AWS を利用 ● 証券システムは全て内製 ● その全てが AWS 上で稼働中 ● オンプレのリソースは存在するが 一部の外部接続に関連するもののみ ● 証券コア機能は EC2 や ECS で稼働

Slide 7

Slide 7 text

© PayPay証券 急成長していますが、 そこに至るまでは様々な課題が・・・ 7

Slide 8

Slide 8 text

© PayPay証券 それらの課題に対して どのように対応していったか お話します 8

Slide 9

Slide 9 text

© PayPay証券 AGENDA 9 01. AWS運用内製化までの道のり 02. さらなる効率化を求めて 03. 安定稼働させるために 04. まとめ

Slide 10

Slide 10 text

© PayPay証券 01. AWS運用内製化までの道のり 10

Slide 11

Slide 11 text

© PayPay証券 AWS運用内製化までの道のり 11 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 設立当初のシステム規模が小さいうちは問題なかったが・・・・

Slide 12

Slide 12 text

© PayPay証券 AWS運用内製化までの道のり 12 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる

Slide 13

Slide 13 text

© PayPay証券 AWS運用内製化までの道のり 13 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる

Slide 14

Slide 14 text

© PayPay証券 AWS運用内製化までの道のり 14 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる 拡張性 ・契約の都合で、利用可能な AWS機能は一部に制限 ・新たに利用したい機能があれば 事前に委託先との確認が必要

Slide 15

Slide 15 text

© PayPay証券 AWS運用内製化までの道のり 15 なぜ、内製化が必要であったか AWS の 構成管理・監視運用を外部に委託 急激なユーザ増 ・2024年1月からの新NISA 取扱開始でユーザ数増は明らか ・大幅な機能改修やリソース増強 が求められる リードタイム ・構成変更を行う際は、委託先 との事前調整が必要 ・リソースの兼ね合いもあり 最短３日はかかる 拡張性 ・契約の都合で、利用可能な AWS機能は一部に制限 ・新たに利用したい機能があれば 事前に委託先との確認が必要 2023年5月より 事業成長を加速させるためにも AWS運用の内製化を決意！

Slide 16

Slide 16 text

© PayPay証券 AWS運用内製化までの道のり AWS運用管理内製化のスケジュール 16 2023/6 2023/7 2023/8 2023/9 AWS アカウント管理 構築業務 運用業務 監視業務 セキュリティ運用 譲渡準備 自社管理 委託先プラン 自社構築・管理 業務移管準備 [Stg] 自社運用 [Prod] 自社運用 委託先プラン（一部監視のみ） 旧サービス（委託先提供） 移行作業 新旧並行稼働 自社監視（NewRelic） 旧サービス（委託先提供） 移行作業 自社運用 ● 7/3 AWS アカウント譲渡 ● 8/31解約

Slide 17

Slide 17 text

© PayPay証券 AWS運用内製化までの道のり 17 内製化を行ったことで以下を実現 AWS の 構成管理・監視運用を内製化 急激なユーザ増 ・急激なユーザ増加や アプリケーションの大幅な変更 などの、変化に耐えうる Agility を確保 リードタイム ・AWS 構成変更作業が 社内で対応が完結 ・最低３営業日かかっていた ところを、最短即日で対応可能 拡張性 ・全てのAWS機能が利用可能に ・ECS や Fargate など、 契約の都合で制限されていた ものが無くなった

Slide 18

Slide 18 text

© PayPay証券 02. さらなる効率化を求めて 18

Slide 19

Slide 19 text

© PayPay証券 19 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ 内製化を行ったが課題は山積 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・

Slide 20

Slide 20 text

© PayPay証券 20 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ そのうちの２つをピックアップして説明 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・

Slide 21

Slide 21 text

© PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 21

Slide 22

Slide 22 text

© PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 22

Slide 23

Slide 23 text

© PayPay証券 さらなる効率化を求めて 23 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 インフラ基盤が手動管理のままで非効率

Slide 24

Slide 24 text

© PayPay証券 さらなる効率化を求めて 24 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 インフラ基盤が手動管理のままで非効率

Slide 25

Slide 25 text

© PayPay証券 さらなる効率化を求めて Atlantis を利用した Terraform Apply の例 25

Slide 26

Slide 26 text

© PayPay証券 さらなる効率化を求めて Atlantis を利用した Terraform Apply の例 26 Approve 後に コメントを打つことで apply 可能 Github の PR で plan 結果が確認可能 →そのままレビューを行える 問題なければ apply 後に 自動マージ

Slide 27

Slide 27 text

© PayPay証券 さらなる効率化を求めて 27 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 既存リソースの import ・既存のリソースはどうしても 手動でimport が必要 ・TerraCognita などのツールを 使って効率化 ・主要リソース（EC2/SG/ELB/S3…） は import 済 インフラ基盤が手動管理のままで非効率

Slide 28

Slide 28 text

© PayPay証券 さらなる効率化を求めて 28 IaC の導入 Terraform の導入 ・IaCとして Terraform を採用 ・人気度や拡張性の高さを評価 ・新規リソース作成から徐々に 活用、現在はTerraform 利用を 基本 Terraform の自動化 ・Terraform の自動化のために Atlantis を同時に導入 ・GitHub Apps として動作 ・複数人での apply での競合回避 ・レビューや適用 を GitHub 上で完結 既存リソースの import ・既存のリソースはどうしても 手動でimport が必要 ・TerraCognita などのツールを 使って効率化 ・主要リソース（EC2/SG/ELB/S3…） は import 済 インフラ基盤が手動管理のままで非効率 IaCの導入により AWS運用管理の効率化を実現

Slide 29

Slide 29 text

© PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 29

Slide 30

Slide 30 text

© PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 30

Slide 31

Slide 31 text

© PayPay証券 さらなる効率化を求めて 31 アプリ基盤が手動管理のままで非効率 スケールが手動 ・キャンペーンなどでアクセス増 が見込まれる場合は、事前に 手動でサーバを増設 ・増設後は頃合いを見計らって 手動でサーバを削除 設定が秘伝のタレ化 ・当初構築の手順が残っていない ・既存サーバをコピーして作成 動くには動くが、全体の設定が どうなっているか把握しづらい デプロイが手動 ・踏み台サーバから手動で デプロイシェルを実行 ・単純なデプロイだけだとしても 本番環境へのアクセスが必要

Slide 32

Slide 32 text

© PayPay証券 さらなる効率化を求めて 32 アプリ基盤が手動管理のままで非効率 スケールが手動 ・キャンペーンなどでアクセス増 が見込まれる場合は、事前に 手動でサーバを増設 ・増設後は頃合いを見計らって 手動でサーバを削除 設定が秘伝のタレ化 ・当初構築の手順が残っていない ・既存サーバをコピーして作成 動くには動くが、全体の設定が どうなっているか把握しづらい デプロイが手動 ・踏み台サーバから手動で デプロイシェルを実行 ・単純なデプロイだけだとしても 本番環境へのアクセスが必要 Web/APIサーバを対象に Docker化を行いECSに移行

Slide 33

Slide 33 text

© PayPay証券 さらなる効率化を求めて 33 Web/APIサーバを Docker化 ECSによりスケールが容易 ・EC2 + ECS 構成を採用し、 App の修正を少なく Docker化 ・ECS によりスケールが容易に ・AutoScaling も設定可能 設定の明確化 ・App 側は Dockerfile などで 必要な設定を明確に定義 ・EC2 側は直近の公式イメージ を利用して必要な設定を 起動時に実行 デプロイの自動化 ・CodePipeline を導入し デプロイを自動化、実行が容易に ・承認プロセスを挟むことで 安全なデプロイが可能

Slide 34

Slide 34 text

© PayPay証券 さらなる効率化を求めて AWS の 構成管理・監視運用を外部に委託 AWS の 構成管理・監視運用を内製化 内製化により Agility を確保するも課題は山積 インフラ基盤が手動管理のままで非効率 アプリ基盤が手動管理のままで非効率 自動化された IaC を導入し効率化 App を Docker 化し ECS で稼働させ効率化 内製化後の課題を順次解決 34

Slide 35

Slide 35 text

© PayPay証券 35 さらなる効率化を求めて AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ まだまだ課題は存在 IaC の導入・自動化 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ Docker 化・ECS 導入

Slide 36

Slide 36 text

© PayPay証券 36 さらなる効率化を求めて 36 運用監視を更に 効率化するにはどうすれば・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ それぞれの課題に対応していった Zabbix の廃止・ New Relic への移行 PagerDuty の導入 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ システム部門の再編 Dev/Ops の統合 Savings Plan / Reserved Instance の利用 Cost anomaly によるチェック AWS管理を内製化したものの 相変わらず手動管理のまま・・・ アプリの改修スピードを 更に向上させるには・・・ IaC の導入・自動化 Docker 化・ECS 導入

Slide 37

Slide 37 text

© PayPay証券 03. 安定稼働させるために 37

Slide 38

Slide 38 text

© PayPay証券 安定稼働させるために 38 DB の性能限界 ・DB の CPU 不足による障害が発生 ・その都度、スペックアップで対応 ・最終的には選択できる最大スペック まで拡張、後が無い状況 App のボトルネック ・App によるスロークエリが多発 ・ログ出力が十分でなく、原因調査に 行き詰まることが多く改善に 時間がかかる ユーザ数増加を迎えるための安定性の課題

Slide 39

Slide 39 text

© PayPay証券 安定稼働させるために 39 問題の可視化を実施 New Relicの活用拡大 ・AWS 運用内製化により監視業務の 移行先として利用していた New Relic の活用を拡大 ・全てのサーバに対して Agent を導入 APM の活用 ・APM を各サーバに導入 ・APM の機能で、ボトルネックとなっている クエリやAPIの特定が容易に ・パフォーマンス検証環境で改善・検証

Slide 40

Slide 40 text

© PayPay証券 安定稼働させるために APM の表示例 40

Slide 41

Slide 41 text

© PayPay証券 安定稼働させるために APM の表示例 41 API毎に実行回数や処理時間の 情報が表示可能 →ボトルネックとなっている処理の特定が容易に

Slide 42

Slide 42 text

© PayPay証券 安定稼働させるために APM の表示例 42

Slide 43

Slide 43 text

© PayPay証券 安定稼働させるために APM の表示例 43 Transaction のデータから 実行しているDBのクエリも確認可能 →Slow Query となっている対象が見つけられる

Slide 44

Slide 44 text

© PayPay証券 安定稼働させるために DB の CPU 使用率が改善 44

Slide 45

Slide 45 text

© PayPay証券 安定稼働させるために DB の CPU 使用率が改善 45 App を改善しスロークエリを解消 通常ピークの３倍のトラフィックを 処理できるまで改善 上記改善により、インフラ面のキャパシティも最適化 ３０％を超えるシステムコストの削減も達成

Slide 46

Slide 46 text

© PayPay証券 46 安定稼働させるために 46 AWS管理を内製化したものの 相変わらず手動管理のまま・・・ 運用監視を更に 効率化するにはどうすれば・・・ アプリの改修スピードを 更に向上させるには・・・ AWSの機能は自由に使えるが、 費用増が心配・・・ それぞれの課題に対応していった Zabbix の廃止・ New Relic への移行 PagerDuty の導入 安定稼働を実現するには なにか良い方法がないか・・・ システム部門が 開発と運用で別れて非効率・・・ システム部門の再編 Dev/Ops の統合 Savings Plan / Reserved Instance の利用 Cost anomaly によるチェック New Relicを活用し ボトルネックを検知 パフォーマンスを改善 IaC の導入・自動化 Docker 化・ECS 導入

Slide 47

Slide 47 text

© PayPay証券 03. まとめ 47

Slide 48

Slide 48 text

© PayPay証券 まとめ 48 業容拡大に伴い AWS 運用を内製化、Agility を確保 IaC の導入や Docker 化などのクラウドネイティブ化により さらなる効率化を実現 New RelicのAPM を活用したパフォーマンス改善により 通常ピークの３倍までの性能を確保 ２ １ ３

Slide 49

Slide 49 text

© PayPay証券 今後の更なるユーザ増に向けて ユーザの皆様に良い体験ができるよう 改善し続けます！ 49

Slide 50

Slide 50 text

© PayPay証券 Thank you! 50