FOLIOにおけるAWS活用事例 - SBI Tech Day 2025

Transcript

1. Copyright © 2019 FOLIO Co., Ltd. All Rights Reserved. 株式会社FOLIOにおけるAWS活用事例 2025/03/07 SBI Tech Day 2025
2. 2 本日の流れについて • 自己紹介 • 株式会社FOLIOについて • SBIグループの一員としてのFOLIO • 証券会社としてのFOLIO • 証券システム提供会社としてのFOLIO • FOLIOにおけるAWSの活用事例 • 全体構成について • 2C領域・2B領域におけるクラウドインフラ利活用について • 主として2B領域における内容を中心に • プラットフォームが提供する価値提供
3. 3 自己紹介 • 海津 研 / Ken Kaizu • 株式会社FOLIO • 執行役員CTO • フィナンシャルテクノロジー本部 • 共通基盤部（SREユニット含） • 株式会社FOLIO ホールディングス • 情報戦略部 部長 • 2018年1月より株式会社FOLIO • バックエンド・インフラがメイン
4. 4 証券サービス・証券システムについて 投資一任運用を支えるシステム 1日の中でライフサイクルが存在している • 顧客注文受注 • お客様からの注文をQueueing • 注文締め • 当日注文の確定処理 • 約定処理 • 市場に向けた発注及び約定 • 評価額算出 • 証券残高・現金残高計算 重厚長大なバッチシステム 責務毎に分離されたサービス間連携
5. 5 開発・運用体制について AWSを中心とした基盤の提供 サービスを支える開発・運用 プラットフォーム アプリケーションチーム毎の開発 契約管理システム 口座管理システム … 契約管理システムの アプリケーションに関するもの • サーバー、デーモン、バッチ • Docker Image • サービス上のデータ管理 • 論理DB・DBユーザー • 監視設定 • CI・CD設定 • 運用上のロール 口座管理システムの アプリケーションに関するもの • サーバー、デーモン、バッチ • Docker Image • サービス上のデータ管理 • 論理DB・DBユーザー • 監視設定 • CI・CD設定 • 運用上のロール ※ 本日のメインの話
6. 6 ケース）AWSアクセス管理システムの構築と運用 要件 • AWSのアクセス権限を一時的に払い出す • 最小権限に近づけたアクセス権限付与 • 必要期間に限りアクセス権限を付与 • 適切な業務遂行者にのみ権限を付与 • 承認フローによる権限取得 提供されている機能の利用としては、以下の通り 1. 事前に権限を分離したIAM Role / Entra Groupの作成 2. Slack Workflowを用いた運用担当者による申請 3. Entra Id PIMによるEntra Groupアクセス申請 4. 承認者による内容確認及び承認 5. 一時的な権限の取得 6. 各種リソースへのアクセス SaaSの組み合わせによる利便性向上 IdPを中心とした権限制御
7. 7 AWS 全体構成について AWS Account について • AWS Control Tower相当の構成 • 検証環境・本番環境等において、 AWS Accountが分離 • 4RAPはSaaSとして提供する中で、 共用テナント・専用テナント等、 AWS Accountをさらに分離 ※ 全体像を表すものであり、こちらに記載されていないOU・Accountも存在しています
8. 8 4RAPにおけるAWS Accountの利用 SaaSによる共通基盤のため、 クライアントが増えると機能も拡張される
9. 9 4RAPにおけるAWS Accountの利用 SaaSによる共通基盤のため、 クライアントが増えると機能も拡張される 環境は分離されており、AWS Accountを多用 コア機能はバージョニングされてアップグレード
10. 10 4RAPの個社向けインターフェース 以下のインタフェースを提供 • Amazon API Gateway • HTTPを利用したリアルタイムAPIの提供 • OAuthによる認可（Custom Authorizer） • OpenAPI Specificationによる仕様提供 • Transfer Family • SFTPを利用したファイル連携 • OpenAPI Specificationによる仕様提供 • jsonl によるストリーム処理可能なファイル形式 SaaSである4RAP側からの仕様提供 ファイル連携についてもpathでversioning
11. 11 個社希望に応じたいくつかの接続要件にも対応 • IP制限 • API GatewayにIP制限 • VPN接続 • Site to Site VPN • API Gateway x VPC Endpoint x NLB • Transfer Family x VPC Endpoint • AWS間接続 • PrivateLink 4RAPにおける接続要件 AWSの技術により、ネットワーク要件をアプリケーションまで持ち込まない
12. 12 Feature Flagによる環境差異管理 個社環境毎の環境差異管理 • AWS Resourceは全てTerraformにてIaC • 環境毎にterraform workspaceを設定 • 環境が増えた場合にも並列で適用 • 環境差異はFeature Flagによる管理 • use_vpn • use_ec2_ondemand_instances • … • 設定方法 • 環境毎のworkspaces.tfvarsで設定 • 推奨する本番環境は何も設定をしなく て良い状態としている 全ての環境の構成は一元管理 環境差異は環境毎に用意された設定ファイルでフラグ管理
13. 13 EKS構成・リソース管理について 基盤の提供 サービスを支える開発・運用 プラットフォーム アプリケーションチーム毎の開発 契約管理システム 口座管理システム … 契約管理システムの アプリケーションに関するものを helm chartでリソース管理 • Service • ConfigMap • Deployment • Job • HorizontalPotAutoscaler • PodDistritruptionBudget • WorkflowTemplate • CronWorkflow 口座管理システムの アプリケーションに関するものを helm chartでリソース管理 • Service • ConfigMap • Deployment • Job • HorizontalPotAutoscaler • PodDistritruptionBudget • WorkflowTemplate • CronWorkflow TerraformによるEKS管理 • EKS • Plugin / IRSA等 helm chartによるリソース管理 • Argo CD • Argo Workflows • HashiCorp Vault • Cluster Autoscaler プラットフォーム側では 任意のリソースを作成可能
14. 14 ケース）Argo CDで実現するリソース権限分離 要件 • 開発チームで作成可能なリソースを制限 • 利用可能なnamespaceも制限したい Argo CD で GitOps による CD を提供する中で、 プラットフォームが提供する制限下において 許可された namespace / kind しか作成できない • 事前にプラットフォーム側でAppProjectを作成 • 開発側では提供されたAppProjectを用いてk8s resourceを作成可能 • AppProjectでは namespace / kind の制限を付与 • 結果として開発チームではSecretを作れないなど ClusterRole のような k8s クラスタ全体に 影響を及ぼせる仕組みはプラットフォームのみで管理
15. 15 ケース）プラットフォームとしてのk8sリソース制約 要件 • k8sリソースに対する細かな制約 • docker hubを参照させたくない • node-typeを制限したい • 監視のためにlabelを強制 • … Polaris を利用した、静的検査と動的検査の双方を提供 • 独自ルールをJSON Schemaにて定義 • 静的検査 • CIにおいてPolarisのルール用いてチェック • デプロイ前の開発時において気がつける仕組み • 動的検査 • Polarisをk8sで動かすことで、Admission ControllerのValidating Webhookからチェック • クラスタ上でルールに合致しないプロセスを立ち 上げさせない 静的・動的双方のチェックによる制約 ※ open-policy-gent/gatekeeper, conftest のようなツールも存在しています
16. 16 EKS on EC2 を利用する際の費用効率化 • Cluster Autoscalerで必要なインスタンスのみを利用 • SPOTインスタンスの活用により費用削減 • priority-expanderによるfallback • SPOTインスタンスは枯渇しうる • 立ち上がらなければOnDemandを利用 • Cluster Autoscalerの注意点 • 類似InstanceTypeを利用する必要がある • AZに対してそれぞれNodeGroupを作成 • InstanceTypeの変更はNodeGroup再作成 • ※ Karpenter 検討中 Spotインスタンスを利用した費用削減
17. 17 EKSでサーバを安定稼働させる際に、 いくつかの仕組みを事前に導入する必要がある • Readiness gate / preStop sleep • LBからのリクエスト制御 • 常時2台以上稼働させるためのpdb • AZ分散のためのTopologySpreadConstraints • リソース不足回避のためのClusterAutoscaler • Podの偏りを解消させるためのDescheduler • NLBリクエスト接続安定化のためのALB GracefulなAPI運用に向けて プラットフォームとして必要な機能を 技術で解決する
18. 18 ©FOLIO Co., Ltd. Mission Keep Innovating The Financial Industry Vision 技術と創造で“未来の金融”の礎となる
19. THANK YOU