Serverlessで始める証券取引所OrderAnalytics.pdf

Transcript

1. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Serverlessで始める 証券取引所 Order Analytics ⼤阪デジタルエクスチェンジ株式会社 システム開発本部システム開発部⻑ 紙本哲也
2. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 本⽇お話する内容 • ⾃⼰紹介・会社紹介 • ODXのシステム概略 • ODXでのデータ分析の課題とPoCで実施した内容 • Lessons Learned • 最後に
3. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. ⾃⼰紹介 ⽒名︓ 紙本哲也（かみもとてつや） 所属︓ ⼤阪デジタルエクスチェンジ株式会社 システム本部・システム開発部⻑ （2021/08より現職） 好きなAWSサービス︓ Lambda, Route53, Redshift
4. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 会社紹介 何をやっている会社なの︖ • 現時点では私設取引所の運営を⾏って います（⽇本で3社ある私設取引所の うちの1つです） • 今後セキュリティトークン（ST）の 流通市場を開設する予定です 社員はどれくらいいるの︖ • 現在（2022年9⽉時点）、22名の社 員で運営を⾏っています ⼤阪って名前につくけど⼤阪にあ るの︖ • オフィスは六本⽊にあります︕ 会社名︓ • ⼤阪デジタルエクスチェンジ株式会社 （略称︓ODX） 事業内容 • 株式の私設取引所（PTS）運営 • 2022/06/27開業︕ • セキュリティトークン取引所運営（予定） 所在地 • 東京都港区六本⽊三丁⽬1番1号 • ⼤阪府⼤阪市北区中之島三丁⽬2番18号 （SBIグループ⼤阪本社）
5. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. ODXシステム概略 Back Applications Analytical environment AWS Cloud ODX DC(On Prem) ODX Office VPC(Back) VPC(Common) Private Internal subnets(Prod) Matching Engine Servers Order/Trade Receiving Container (Fargate) Historical DB (Aurora) Batch Lambdas ODX DL S3 AWS Glue ODX DL S3 Redshift (Serverless) AWS Direct Connect TSE Flex Converter (AWS Batch) IntraApp ODX DL S3 Quicksight AppServer (Fargate) ODX users AWS Glue Corporate HP DynamoDB API Gateway Amazon CloudFront S3(Contents) 今日はこの部分 MDCL (Fargate)
6. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 本題に⼊る前その前に・・・ODXシステムの特徴 • 基本すべてマネージド・サーバーレス • EC2インスタンスは運⽤⽤（ログインしてコマンド打ちたい⽤）の インスタンスとBATCHのSPOT fleetのみ • サーバーレスを採⽤しているおかげで特別な考慮をあまりせずに⾼ 可⽤性の恩恵を享受 • 90%以上IaC • HP周りのACMやクライアントVPNなどのごく⼀部を除いてすべて SAM&CFn • セキュリティ • ストレージはすべてCMKで暗号化 • 認証は基本すべてOIDC/SAMLでのSSO(マネコン・開発アプリ・ ClientVPN・QuickSight）
7. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 総開発数（2022/01〜2022/9/13現在） •Lambda関数︓110ファンクション •Containerアプリケーション︓10 •Jobフロー(StateMachine)︓67 •画⾯︓23
8. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. メインで使⽤しているAWSサービス Amazon SNS Amazon Simple Queue Service AWS Step Functions Amazon EventBridge Amazon API Gateway Amazon Simple Email Service (Amazon SES) AWS Lambda Amazon Elastic Container Registry (ECR) Amazon Elastic Container Service (ECS) AWS Fargate Amazon Aurora Amazon DynamoDB AWS CodeBuild AWS CodeCommit AWS CodePipeline Amazon CloudWatch AWS CloudFormation AWS Config AWS CloudTrail AWS Transfer Family Amazon CloudFront AWS Transit Gateway Amazon Route 53 Amazon Virtual Private Cloud (Amazon VPC) AWS Direct Connect AWS Client VPN Elastic Load Balancing Amazon GuardDuty Amazon Inspector AWS Certificate Manager (ACM) AWS Key Management Service (AWS KMS) AWS Secrets Manager AWS Security Hub AWS Shield AWS WAF AWS Single Sign-On Amazon Elastic File System (Amazon EFS) Amazon Simple Storage Service (Amazon S3) AWS Application Auto Scaling AWS Organizations AWS Identity and Access Management (IAM) 45サービス + more Amazon Redshift Amazon QuickSight AWS Batch AWS Glue
9. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. ODXでのデータ分析の課題 とPoCで実施した内容
10. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 本題に⼊る前その前に・・・⽤語集 • PTS • Proprietary Trading Systemの略で、証券取引所（東証など）を経由せずに上場株式を売買で きる「私設取引システム」。ODXのほかにJNX/Cboeが存在。 • DLP • DLP（Designated Liquidity Provider︓指名流動性提供者）のこと。ODXではDLP制度を導⼊ し、取扱い銘柄に対してDLPが可能な限りマーケットメイクを⾏うことで、投資家の皆さまの 注⽂が執⾏され易い環境を⽤意しています。 • Maker/Taker • Maker︓マーケットメイクを⾏う参加者（基本DLP） • Taker︓Makerが形成しているマーケットに対し注⽂を⾏ってくる参加者（投資家など） • BBO(Best Bid Offer) • 最良の売り（Offer）・買い（Bid）気配 参考：https://www.odx.co.jp/column/post/pts-history/
11. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 東証売り気配株数 ODX売り気配株数 気配値 ODX買い気配株数 東証買い気配株数 1000 5470 1100 5460 500 5450 100 5449 100 5448 100 5447 100 5446 100 5445（約定） 100 5444 100 5443 100 5442 100 5441 200 5440 400 5430 1200 5420 1400 前振り︓ユーザー要件 • 価格改善率の評価（Tradeデータ） • DLPが東証のBBOの範囲内に注⽂を出 してきてくれているかの評価 • 東証(TSE)の板をリアルタイムで持ってい るわけではないので、ヒストリカルなデー タから分析する必要あり • TSEのヒストリカルデータの⼊⼿が必要 • TSEのデータはヒストリカルデータを購⼊ （中⾝はPCAP形式） • 上記データ量は1⽇分で以下 • ODXのTradeデータ︓平均7.5万レコード • ODXのOrderデータ︓平均6000万レコード 強（2022年9⽉時点で最⼤8000万弱） • 東証の気配︓7000万レコード前後 売り気配株数 東証気配値 買い気配株数 1000 5470 1100 5460 500 5450 5440 400 5430 1200 5420 1400 Best Bid Best Offer 価格改善率 価格改善率 BBO
12. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. ユーザー要件からのデータ分析の課題 • 現状のデータ基盤ではそもそも耐えられない • ヒストリカルにデータをストアする⽬的ではAuroraを採⽤。⽤途的に7000万レコードを超える 分析には耐えられそうにない • 注⽂のヒストリカルテーブルは30GB/dayで増加中。SQL投げてもかえってこないね・・・ • ⽤途的にはRedshiftがベター︖しかしコストが・・・ • 分析の結果としてコスト⾯で価値を⽣み出す内容ではないため、コストを投⼊しづらい。 • Redshiftのインスタンスを建てるには⽉額のコストがかかりすぎる（例えばra3.4xlarge 2nodeでも$6000弱）。 • 特に弊社の場合は利⽤ユーザーが少ないため(可視化は当初想定では⽉次で数名が使う程度) 、 分析データを作成した後の可視化部分でのコストがもったいない（昼間は暇なんです） そうだRedshift serverlessを使おう！ ちょうどいいタイミングでGAになってくれたし
13. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 最も重そうな集計処理 file_date key_date_time stock_code ask_value1 bid_value1 7/1/2022 8:00:18.774 1360 1009 1009 traderid tradergrpid tradername POXX0Z 8XXXX orderdate status entrydatetime updatedatetime seccode traderid buysell price 20220701O 8:21:28.366 8:21:28.366 1357POXX02 B 413.5 20220701O 8:21:38.972 8:21:38.972 1360POXX27 S 1010.1 20220701A 8:40:40.001 8:40:40.003 1360POXX05 B 1012.6 20220701A 8:39:53.855 8:40:40.001 1458POX28 S 15265 • 各注⽂（Order表/:現状7000万レコード）に関して、status=ʻOʼのものは entrydatetime, ʻAʼのものはupdatetimeをベースにseccodeがtse-bboの stock_codeに⼀致し、かつ直近の時間のask_value1(buysell=ʻSʼ) and bid_value1(buysell=ʻBʼ)を検索 • 約定(Trade表)の場合はシンプルに直近のBBOを検索 • 東証側の⾦額とODX側の⾦額の乖離を計算(約定) • この集計処理を1⽇のコストを5千円以内（⽉額10万程度）に抑えることが⽬標 Order表/Trade表 東証BBO表 traderid_master
14. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 分析での課題 • レコード数の多さ（ODX:平均6300万、JPX︓7000万前後） • 直近という概念の難しさ︓ • 薄い板では値が動かず、寄り付き近辺のBBOが直近ということもありえる • DLP側の発注ロジックもわからないため、結果としては全くBBOが動いていないタイミングでも注⽂ が発⽣することもありえる • 理論的には最も古いBBOの時間は前場・後場開始の時間となるため、開始（各々9:00,12:30）から 終了（各々11:30,15:00）までの時間、9,000,000msec以前までが最⼤となる 売り気配株数 東証気配値 買い気配株数 1000 5470 1100 5460 500 5450 5440 400 5430 1200 5420 1400 9:00:00.000 11:29:59.999 東証売り気配株数 ODX売り気配株数 気配値 ODX買い気配株数 東証買い気配株数 1000 5470 1100 5460 500 5450 100 5449 100 5448 100 5447 100 5446 100 5445（約定） 100 5444 100 5443 100 5442 100 5441 200 5440 400 5430 1200 5420 1400
15. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 処理アーキテクチャ AWS Glue S3 (Raw data) S3 (Modified) AWS Batch Amazon Redshift (Serverless) Load files to redshift Amazon QuickSight Batch query Store RAW pcap and converted raw csv files Store HIVE partitioned , reduced and modified files(Parquet/Snappy) (ODX order/trade CSV files also stored) Spectrum （60日を超え る過去分） Download RAW pcap files from JPX site Spot instance(s) 10本値→BBOのみ へデータ削減 1. Download (1 container) ↓ 2. Convert (18 containers) AWS Cloud
16. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 検証した内容 1. Order/TradeともにBBOを検索する時間の範囲（レンジパラメータ）を変更し、 その実⾏時間を計測 2. Orderに関してはTableのSortKey/DistKeyを変更しそのパフォーマンスを計測 3. RPUについても32〜256まで計測しコストパフォーマンスの良いRPUを選択 4. Orderのレコードでは時間を分割（前場・後場）し、処理を並列化してそのパ フォーマンスを計測 5. 上記の検証で最もコストパフォーマンスがよい構成で、今回のクライテリアを満 ⾜できるかの判断
17. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Trade集計 初期性能検証結果 No RPU Time range [s] Error rate [%] Time [s] Cost [USD] (Ohio) Cost [USD] (Tokyo) 1 32 -9000 0 94 0.30 0.41 2 32 -900 0.06 86 0.27 0.38 3 32 -90 0.93 86 0.27 0.38 4 32 -9 6.2 85 0.30 0.37 • テーブル定義・Time rangeを変え4パターン計測 • ⼤きなチューニングなしでも⼗分なコスト・パフォーマンス。Traed集計のTime rangeは過去 9000秒に決定
18. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Order集計︓レンジパラメータの⽐較 No Time range [s] Error rate [%] 1 -1 27.0 2 -10 3.4 3 -50 0.67 4 -100 0.47 • 注⽂7800万件 vs 板7600万件の結合は現実的ではないため、注⽂に対して結合する板のレン ジを限定するパラメータ（Time range）を導⼊ • 注⽂に対応するBBOがない確率が0.5%以下となるレンジを少量データで調査 → 過去100秒 とする
19. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Order集計︓分散スタイル・ソートキーの⽐較 No 分散スタイル ソートキー Time [s] 1 • EVEN • EVEN • N/A • N/A 126 2 • KEY (seccode) • KEY (stock_code) • orderdate, orderno, ordernosuffix • file_date, key_date_time, stock_class, stock_code, sequential_no 136 3 • KEY (seccode) • KEY (stock_code) • orderno, ordernosuffix • key_date_time, stock_class, stock_code, sequential_no 154 4 • EVEN • EVEN • seccode, orderno, ordernosuffix • stock_code, key_date_time, sequential_no 120 • 分散スタイル・ソートキーを変え少量データで4パターン計測 • 分散スタイル→EVEN、ソートキー→PK（証券コードが先頭）とする • 上︓ODX注⽂表 • 下︓TSE BBO に対応
20. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Order集計︓性能検証結果 No RPU 並列度 Time [s] Cost [USD] (Ohio) Cost [USD] (Tokyo) 1 128 1 3946 50.5 69.3 2 128 2 2781 35.6 48.8 3 256 1 2508 64.2 88.1 4 256 2 1661 42.5 58.3 • Orderに関しては128RPUまではコストの減少が⾒られたが256RPUで増⼤ • そのためRPU（128・256）× クエリ並列度（1・2並列）を⽐較 ※2並列はデータを時刻で分割 • 128RPU、2並列が最も低コストとなり、かつクライテリアを満⾜できる結果となった
21. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. これからさらに検証したいこと・残課題 • そもそもRedshiftではなくてAthenaとかでTryしてみる︖ • Orderの分析を、BBOの範囲中に注⽂が⼊っている時間の算出に • 昼間のQueryは軽いので、運⽤で昼間32RPU→夜間128RPUとしたいが不具合で実 装ができていない • 特にTradeのデータは（それほど⼤きくないため） SPICEにインサートして RedshiftへのQueryを減らしたい
22. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. Lessons Learned • Redshift Serverlessは（Redshiftのもともとのコストがお⾼めなこともあり）、ま ずは簡単に使い始めることができるDWHとして⾮常に有効。特に弊社のような⼀ 般利⽤するユーザーが少ない環境ではそのコスト効率は⾮常に良好 • 当初銘柄コードを分散キーにすることに何も疑いをもっていなかったが、結果とし ては分散スタイルはEVENが最良の結果となった。何事も思い込みは危険と再認識 • コストパフォーマンスを最適にするためには処理の並列化が重要 • Redshift Serverlessは使いやすいサービスであるが、コストのコントロールが難し いため、どうしても予算を超過しやすくなってしまう。実運⽤ではAWS Budgets などでアラートを出す仕組みを導⼊することが必須（あとはAWS Cost Anomaly Detectionとか）
23. © 2022, Osaka Digital Exchange Co., Ltd. All rights reserved. 最後に・・・ • 検証のPoCで多⼤なるご⽀援をいただいた、SA 濱岡さん、SA⼤薗さん、本当にあ りがとうございました︕ • ODXでは⼀緒に働ける⼈を⼤募集しております︕（特にデータ分析） ⾦融でのデータ分析に興味のあるかたはぜひお声かけください︕