MySQL Empowers Mission-critical Financial System Presentation 2

  • 261 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
261
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 本日ご紹介するテーマ 流れを簡単に説明。
  • 説明時間: 2 分(合計: 2 分) <対象システムに関する説明> ■ フロント業務システムについて解説  金融では、大きく、以下の 3 つの業務に分けることができる。  ⇒フロントの業務、ミドルの業務、バックの業務 ■ フロント業務とは  一般には顧客との接点を持っている「営業部門」のこと。  つまり、「確実に受注すること」、「少しでも有利な条件で取引すること」が  ポイントになる。金融では、以下の 2 つを指す。   ・(他と同様に)個人顧客、法人顧客   ・金融マーケット ちなみに、、、 ミドル業務は、フロントとバックの間に位置し、全体の業務の流れや状況を監視したり調整したりする役目。 バック業務は、勘定の起票や決算処理などの計数管理を受け持ちながら業務全体を支える役目。 <システム化の狙い(課題背景)>  ・現状、直近のポジション管理はうまくできていない。  ・前日ベースのデータに手メンテを加えて直近化している。   つまり、作業に時間がとられており、本来やるべき分析・判断の業務に専念できていない
  • 説明時間: 1 分(合計: 3 分) お城のイメージで説明 ■ 建物の部分(アプリケーション)  ・フロントポジションとは各ファンド等の現物の直近状況(ものの視点)  ・資金管理は各ファンド等の資金の直近状況(お金の視点)  ・約定管理は約定データの反映支援 ■ 石垣の部分(基盤)  ・メッセージング機能の提供(アーキテクチャは後述)  ・開発フレームワーク   -リクエストレスポンス機能   -パブリッシュ・サブスクライブ機能
  • 時間: 1 分(合計: 7 分)
  • 時間: 2 分(合計: 8 分)
  • 時間: 1 分(合計: 9 分)
  • 時間: 1 分(合計: 10 分) ポジション資金管理サーバのメモリサイズは 8GB RedHat Linux では、拡張メモリ機能があるため、 8GB まで搭載。 ただし、 1 プロセスあたりのアドレッシングは 4GB 。
  • 時間: 1 分(合計: 11 分)
  • 時間: 1 分(合計: 12 分)
  • 時間: 1 分(合計: 13 分)
  • 時間: 1 分(合計: 14 分)
  • 時間: 1 分(合計: 15 分)
  • 時間: 1 分(合計: 16 分)
  • 時間: 1 分(合計: 17 分)
  • 時間: 1 分(合計: 19 分)
  • 時間: 1 分(合計: 22 分)
  • 時間: 1 分(合計: 23 分)
  • 時間: 1 分(合計: 24 分)
  • 時間: 1 分(合計: 25 分)
  • 時間: 1 分(合計: 26 分)
  • 時間:↓
  • 時間: 2 分(合計: 28 分)
  • 時間: 1 分(合計: 29 分)
  • 時間: 1 分(合計: 30 分)
  • 時間: 1 分(合計: 31 分)
  • 時間: 1 分(合計: 32 分)
  • 時間:↓
  • 時間:↓
  • 時間:↓
  • 時間: 1 分(合計: 34 分)
  • 時間: 1 分(合計: 35 分)
  • 時間: 1 分(合計: 41 分)

Transcript

  • 1. MySQL Empowers Mission Critical Financial Application ~ MySQL Case study in financial industry ~ Ryusuke Kajiyama MySQL Senior Evangelist, APAC Sun Microsystems / MySQL
  • 2. Agenda 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 3. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 4. Project Overview
    • Target system  
    • Front office support application for asset management companies (investment trusts/investment advisors, etc.)
    • System for fund managers
    • software-as-a-service model application
    • The purposes of systematization  
    • Timely front positions understanding and fund plannings
    • To enhance the ability to manage financial products in accordance
    • To integrate information from various sources, both in and outside the company
    • To focus on core operations as business efficiency improves
  • 5. The main functions of the system
    • Front-office position management
    • Fund and capital management
    • Contract management
    • User management
    Application functions  
    • Data integration via messaging infrastructure
    •   (used for linkage with systems of other companies)
    • Client application development framework
    •   (tailored for the individual needs of fund managers)
    Infrastructure functions
  • 6. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 7. 2. System requirements
    • Data Volume
    • The number of funds: 2,500+
    • The number of balances reported by account/brand: 250,000+
    • Transaction data volume: 1TB+
    • Function requirements  
    • Advanced user interface
      • Graphs and other GUI components as well as a high operability of drag and drop, and other functions
      • Publishing infrastructure for data to be reflected in real-time
    • Real-time/batch data linkage between systems
      • Messaging/file transfer
    • Basic requirements  
    • Small start & high scalability
      • In terms of cost
      • In terms of system configuration
    • Consideration for multi-customers
  • 8. 2. System requirements
    • Fault-tolerance requirements  
    • Avioidng single failure point (Server/network duplexing)
    • If server down: recovery time within 10 minutes
    • Operational requirements  
    • Weekdays: 6:00-20:00 (online)
    • Other days: application batch/infrastructure batch
    • All maintenance operations are automated
    • Performance requirements (online)
    • Number of transactions per second: 200/second
    • Response time:        3 seconds
  • 9. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 10. System configuration overview Orchestration Infrastructure Workflow definition Flow control Presentation Infrastructure Messaging infrastructure Service component group Position management Fund management Risk management OMS Compliance Database service group Brand Characteristics Market Benchmark Account Company Routing Database linkage Publishing Screen layout definition Screen - data map Data set definition Data load Data cache ------ ------ ------ System evidence / system audit
  • 11. Servers supporting the architecture are as follows: Server configuration overview Usage Role Presentation infrastructure Aggregation server ・ Accepting client requests, and via the EMS server requesting the service group to deal with them ・ Delivering real data on the server side to clients Messaging infrastructure EMS server ・ Serving as a messaging infrastructure to enable smooth communications between servers which are loosely coupled Service group (In this project, DB function is available in each service server.) Position management / fund management server ・ Providing business logic relating to position management/fund management ・ Using same configuration for business logic server and DB server Authentication server ・ Providing an authentication function Other (key usages) File linkage server ・ A server used for file linkage with external systems External EMS server ・ A server used for real-time linkage with external systems Shared disk ・ Storage for sharing business DB, authentication DB and others
  • 12. Hardware configuration This program exclusively employs IA-based servers. Usage CPU Memory HDD capacity Presentation infrastructure Aggregation server Dual core Xeon 5160 (3.00GHz) 4GB 146GB(RAID1) Messaging infrastructure EMS server Dual core Xeon 5160 (3.00GHz) 4GB 146GB(RAID1) Service group (In this project, DB function is available in each service server.) Position management / fund management server Quad core Xeon X535 (2.66GHz) 8GB 146GB(RAID1) Authentication server Dual core Xeon 5110 (1.60GHz) 4GB 146GB(RAID1) Others File linkage server Dual core Xeon 5110 (1.60GHz) 4GB 146GB(RAID1) External EMS server Dual core Xeon 5160 (3.00GHz) 4GB 146GB(RAID1) Shared disk The 2C2D (C: controller, D: disk enclosure) configuration with a capacity of 146GB×16 HDDs. Possible to increase capacity up to 25TB (146GB×28 HDDs). By adding enclosures, can be up to 50TB with 2C4D (56 HDDs) 1238GB (RAID 5) SAN switch - - -
  • 13. Software configuration
    • Messaging infrastructure
    • Presentation infrastructure
    RedHat Linux ES 4.0 Apache 2.0.54 JBoss AP Server 4.0.5 JDK 5.0 EMS Client API Strus In-company F/W Application Aggregation server RedHat Linux ES 4.0 Cluster middleware EMS server External EMS server TIBCO EMS 4.4.0 Scale-out configuration Scale-up + HA configuration
  • 14. Software configuration
    • Service group infrastructure
    Cluster middleware MySQL 5.0.40 JBoss AP Server 4.0.5 JDK 5.0 EMS Client API In-company F/W Application Position/fund management server Authentication server RedHat Linux ES 4.0 Scale-up + HA configuration
  • 15. Screen shots
    • User registration screen
  • 16. Screen shots
    • Front position management screen
  • 17. Screen shots
    • Transaction progress management screen
  • 18. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 19. First thoughts Commercial product ?   My SQL ?  
  • 20. Thoughts on “commercial product”
    • Points: cons
    • Cost (1)
      • Software license fees/software maintenance fees are required.
    • Cost (2)
      • Higher spec hardware may be needed to run heavy DBMS.
      • Possible higher hardware costs
    • Cost (3)
      • While existing know-how can be applied, designing and implementation tend to be time consuming
    • Points: pros
    • Both in and outside the company it has produced proven results:
      • Stable product quality
      • Many engineers with know-how are in SIer
      • More know-how of application and system design in SIer
    • The product architecture can accommodate a large-scale project
  • 21. Thoughts on MySQL
    • Points: cons
    • Proven results are relatively limited in business systems
      • Main proven results are in reference systems.
      • No proven results with NRI’s internal use in update systems.
      • It is uncertain whether the requirements and practical use conditions of this project would be met.
    • Limited design know-how
      • Not much experience in HA design
      • Difficult to find technical experts in other div of NRI
    • Points: pros
    • Expectations from simple architecture of MySQL:
      • Easier in designing and implementations phase
      • Fewer errors in designing and implementations
      • Less time for designing and implementations
    • Low costs
      • No software license fee; only an inexpensive maintenance fee
      • Easy designing means SE cost reductions can be expected.
  • 22. Final decision “MySQL”
    • Reasons behind adopting MySQL
    • MySQL meets basic requirements of this project.
      • MySQL enables a small start both in investment costs and systems scale.
      • MySQL is flexible to expand both in terms of investment costs and scale.
      • * Cost advantage is outstanding, including preparing dev environment.
    • Rapid system design and implementation
      • Ease of expansion meets requirements in this multi-user model system.
      • Simplicity of MySQL’s implementation process is impressive.
    • Advanced technical support from NRI’s OSS support team
      • Quick trouble shooting can be expected.
      • Many experienced engineers went through number of tough projects
    • Challenging something new!!
      • Using only proven technology will rust knowledge and solution capability
  • 23. Comments in executive review
    • Response measures based on the suggestions
    • For (1)
      • The lack of design know-how was complemented by support from NRI’s OSS Support team and MySQL.
      • Followed by a DBMS-related professional review
    • For (2)
      • A simple prototype application was developed to confirm that at least there was no problem with function/performance.
    • For (3)
      • As a backup plan, in the case of the system being found infeasible, replace with a commercial product.
    • Suggestions in internal design review meeting
    (1) Review by MySQL professional for system design is required, because team did not have much experience of using MySQL in mission critical and high transactional environment. (2) Feasibility test should be conducted using real environment. (3) If the system malfunctioned, backup plans should be discussed for worst case scenarios.
  • 24. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark   6. Post project review  
  • 25. System design/operation design
    • Adopting the InnoDB storage engine to handle transaction data
    • Single MySQL server instance to be shared for multiple companies, not running multiple instances for each companies on the single server
      • To reduce daily operational tasks, use partitions (backup, monitoring)
      • Minimizing downtime through server
    • Storing data/index in the common tablespace file
    Tablespace (single file viewed from the OS) DB for Company A DB for Company B DB for Company N MySQL
    • Multi-users support
  • 26. Backup with “Snapshot”
    • Adopting “Snapshot” feature of the storage device
    • 【 Processing steps 】
    •   (1) Storage management server issues a Snapshot command.
    •    A new tablespace is cloned in storage device.
    Tablespace DB for Company A Shared storage DB for Company B Tablespace Snapshot Position/fund management server Storage management server NFS media server Snapshot command Unmount Snapshot operation performed
    • Backup operations (Step 1)
  • 27. Backup with “Snapshot” (2) When Snapshot operation is done, the position/fund management server mounts the shared storage, in preparation for making service available; in addition, in preparation for backup, the NFS media server mounts the copy area. Shared storage Copied tablespace Position/fund management server Storage management server NFS media server Mount Mount Tablespace DB for Company A DB for Company B Available
    • Backup operations (Step 2)
  • 28. Backup with “Snapshot” (3)The backup server issues a backup command to the NFS media server and executes “LAN-free backup” to tape library is performed. Shared storage NFS media server Backup server Mount Copied tablespace Tape library Backup command
    • Backup operations (Step 3)
  • 29. Infrastructure test
    • The basic features as a DBMS meets the conditions of practical use.
    • New features of MySQL 5.0 was not used in this project. e.g. view , stored procedure and trigger
      • Avoiding the use of brand-new features to reduce risks: the application can be implemented without such features
      • Preparing for performance tuning: View will not be used
      • Facilitating operations and maintenance: Avoiding using s tored procedure and trigger
    • After series of tests, stability of products, ease of restore + recovery and simplicity of restore + recovery process met our requirements.
    • TIPS: When configuring HA cluster, do NOT use `mysqld_safe` shell script to start the server.
    •   -> In case of failure , both mysqld_safe and clustering tool will try to restart MySQL server and won’t make proper fail-over or cause unstable condition.
    • Evaluation of features
  • 30. Performance tests
    • Doing benchmark tests to find out basic performance of MySQL server.
    •   Tests included Import, Export and Create Index performance.
    • Using production environment to find “real” performance.
    • Evaluation of performance
    Tests Purposes Select (FULL Scan) - To obtain basic performance values for full-table scan in MySQL - To find the difference of execution time and resources usage on: data size; concurrency; existence of cache in InnoDB buffer pool. Select (Index Scan) - To obtain basic performance values in index search in MySQL - To find the difference of execution time and resources usage on: data size; concurrency; existence of cache in InnoDB buffer pool. Insert - To obtain basic performance values in data insert in MySQL - To find the difference of execution time and resources usage on: data size; concurrency; existence of cache in InnoDB buffer pool.
  • 31. Performance tests
    • Data size: 1GB, 5GB
    • Concurrency: 1, 4, 8, and 16
    • Rebooting OS before each test case
    • Issuing two sets of queries in a row per concurrency
      • 1st : Right after booting the MySQL server
      • 2nd: After a 60-second interval following the first query
    • The SQL statement issued is shown below. Full table scan is forced by the HINT
    • SELECT SUM(gid) FROM http_auth IGNORE INDEX (primary key) ;
    • To assess the execution time, the date command was executed before and after processing and the difference was measured.
    • Select (FULL Scan) performance
  • 32. Performance tests
    • Data transfer rate of storage : 14.5[MB/sec].
    • With 5GB, data transfer rate was accelerated to 59.7[MB/sec] with smart storage controller.
    • No difference was found relating to concurrency, probably because of one-table access.
    • The effectiveness of the cache mechanism was confirmed.
    • Select (FULL Scan) performance : results
    Data size Concurrency Trial Execution time (hh:mm:dd) 1GB 1 1st 0:01:37 2nd 0:00:00 4 1st 0:01:37 2nd 0:00:00 8 1st 0:01:36 2nd 0:00:00 16 1st 0:01:39 2nd 0:00:00
  • 33. Performance test
    • CPU utilization (1GB, 1 concurrency pattern)
    • In the 1st trial, the process proved to be I/O bound.
    • In the 2nd trial, CPU utilization proved to be close to zero.
    The 2nd trial The 1st trial
    • Select (FULL Scan) performance : results
  • 34. Performance test
    • Available memory size (1GB, 1 concurrency pattern)
    • In the 1st trial, approximately 1.4 GB memory was used, probably because the retrieval data was cached.
    • In the 2nd trial, no change was found.
    The 2nd trial The 1st trial
    • Select (FULL Scan) performance : results
  • 35. Performance test
    • Disk read size: 1GB, 1 concurrency pattern
    • In the 1st trial, a disk read was found to have occurred with an average of approx 15[MB/s].
    • In the 2nd trial, no disk read was found.
    The 2nd trial The 1st trial
    • Select (FULL Scan) performance : results
  • 36. Performance test
    • Data size: 1GB, 5GB
    • Concurrency: 1, 4, 8, and 16
    • Rebooting OS before each test case
    • Issuing two sets of queries in a row per concurrency
      • 1st : Right after booting the MySQL server
      • 2nd: After a 60-second interval following the first query
    • The SQL statement issued is shown below. Executing the program by specifying a unique and random number for the WHERE statement
    • SELECT * FROM http_auth WHERE uid = ‘ xxx’ ;
    • To assess the execution time, the date command was executed before and after processing and the difference was measured.
    • Select (Index Scan) performance
  • 37. Performance test
    • Retrieval performance is processed at the high speed of 10[ms/sec]. A 5GB item of data is processed at a speed of 20-30 [ms/sec].
    • An increase in concurrency results in almost no decrease in retrieval speeds.
    • It was confirmed that the cache mechanism functions effectively.
    • Select (Index Scan) performance : results
    Data size Concurrency Trial Execution time (hh:mm:dd) Ave. throughputs (TPS) Ave. response time (ms/process) 1GB 1 1st 0:00:01 100 10 2nd 0:00:00 - - 4 1st 0:00:01 400 10 2nd 0:00:00 - - 8 1st 0:00:01 800 10 2nd 0:00:00 - - 16 1st 0:00:01 1600 10 2nd 0:00:00 - -
  • 38. Performance test
    • CPU utilization (1GB, 1 concurrency pattern)
    • In the 1st trial, it was found that only a minimal amount of resources was required to complete the process.
    • In the 2nd trial, CPU utilization proved to be close to zero.
    The 2nd Trial The 1st Trial
    • Select (Index Scan) performance : results
  • 39. Performance test
    • Available memory size (1GB, 1 concurrency pattern)
    • In the 1st trial, a memory of approx. 11MB was utilized. Index and retrieved data are considered to have been cached.
    • In the 2nd trial, no reduction in free memory and no increase in cache was found.
    The 2nd trial The 1st trial
    • Select (Index Scan) performance : results
  • 40. Performance test
    • Disk read size (1GB, 1 concurrency pattern)
    • In the 1st trial, a disk read was found to have occurred (approx. 13[KB/s] on average).
    • In the 2nd trial, no disk read was found.
    The 2nd trial The 1st trial
    • Select (Index Scan) performance : results
  • 41. Performance test
    • Data size: 1GB, 5GB
    • Concurrency: 1, 5, and 10
    • Rebooting OS before each test case
    • Inserting one record = 1KB
    • In the case of 5 or 10 multiplexes, a specified data size is to be built in throughout the entire number of processes operated in parallel.
    • Example) in the case of a 5 GB data size
    •   1 concurency : 1 thread (5GB/thread) Insert
    •   5 concurency : 5 threads (1GB/thread) Inserts
    •   10 concurency : 10 threads (500MB/thread) Inserts
    • To assess the execution time, the date command was executed before and after processing and the difference was measured.
    • Inserts performance
  • 42. Performance test
    • Insert performance of 450-480[processes/second] with single thread. In 5GB test case, 500+ [processes/second]
    • Particularly noteworthy was that regardless of multiplex or DB size, there was no change in throughputs. Although in this test, commit processing was performed for each insert, the performance in this method is considered to be reaching the processing limit.
    • Inserts performance : results
    Data size Concurrency Execution time (sec.) Throughputs/thread Ave. throughputs per threads (TPS) Total throughputs (processes/second) 1GB 1 2212 452.1 452.1 452.1 5 2089 96.0 95.9 478.7 96.0 95.8 95.8 95.8 10 2095 47.8 47.8 477.2 47.8 47.8 47.8 47.8 47.8 47.7 47.7 47.7 47.7
  • 43. Performance test
    • CPU utilization (1GB, 1 concurrency pattern)
    • An average CPU utilization is 13% with a maximum utilization of 37%.
    • It was confirmed that programmatically, a delayed write occurred even after the completion of the Insert process. It can be assumed that the MySQL system performs commit processing.
    Delayed write
    • Inserts performance : results
  • 44. Performance test
    • Available memory size: 1GB, 1 concurrency pattern
    • It is considered that through the Insert processing, the data for Insert was cached.
    A reduction of approx. 1GB due to caching
    • Inserts performance : results
  • 45. Performance test
    • Disk read/write size: 1GB, 1 concurrency pattern
    • Few disk reads occurred.
    • An average disk read speed was 14[MB/s] with maximum 17[MB/s].
    • The bottleneck can be caused by the disk I/O to the Binlog.
    • It was confirmed that a delayed write occurred in disk I/O.
    Actual DB is updated in bulk?
    • Inserts performance : results
  • 46. 1. The project background   2. System requirements   3. System architecture   4. DBMS selection 5. Detailed design and benchmark 6. Post project review  
  • 47. Benefits of using MySQL
    • No license fees for MySQL
    • Minimum investment: Low initial investment costs in this service delivery business model is important
      • In most of projects, license fee of DBMS is relatively large portion in hardware and software costs.
    • No additional fees: No fee for options, No uplift
    • Lower cost of expansion: No additional fee for more CPUs, memory or clients
    • Stable and high product quality
    • MySQL showed high data processing performance not only in data reference application, but also in writing application.
    • With no product deficiency detected during development and production phase.
    • Easy to confirm “real” performance in early stage, because MySQL does not require high spec servers and testing on dev server shows similar results on production server
  • 48. Conclusion
    • There were no technical problems in functions of MySQL
    • Stable and high product quality
    • High quality technical support from Sun
    • Now we are seeing more use of MySQL in multiple industry including Telco, Finance, Manufacturing, Healthcare and Government.
    • MySQL is now better than commercial products in both quality and performance.
    • With the accumulation of best-practice and know-how, better professional services and technical support are available.
    “ You can find many systems which you don’t have to pay expensive “DBMS Tax” and you can get a lot of benefits with understanding MySQL more.” “ Do feasibility tests before jump into project with MySQL.”
    • MySQL is more than cheap & easy-to-use!
    • Time to use MySQL in mission critical
  • 49. MySQL Empowers Mission Critical Financial Application ~ MySQL Case study in financial industry ~ Ryusuke Kajiyama [email_address] MySQL Senior Evangelist, APAC Sun Microsystems / MySQL