Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
+7 (499) 399 3361 [email protected] www.visionlabs.ru VisionLabs LUNA Architecture and Scaling Capability 8, bld. 1, Tvardovskogo Street, Moscow 123458 VisionLabs LLC, OGRN 1127746276470, INN/KPP 7701954054 / 773401001 Table of Contents Introduction..................................................................................................................................................... 3 1 Overview ....................................................................................................................................................... 4 2 LUNA Architecture .................................................................................................................................... 5 2.1 Broker ..................................................................................................................................................... 5 2.2 Queue Manager RabbitMQ ............................................................................................................ 6 2.3 Extractor ................................................................................................................................................ 6 2.4 Matcher ................................................................................................................................................. 7 2.5 Aerospike Database Management System ............................................................................... 9 3 Data Replication ....................................................................................................................................... 10 4 Scaling and Clustering ........................................................................................................................... 12 Vision Labs LLC page 2 | 12 Introduction This manual describes VisionLabs LUNA Software architecture, scaling capabilities and fail-safe system principles. Vision Labs LLC page 3 | 12 1 Overview LUNA is the data management system for biometric information extracted from portrait photographs. LUNA primary objective is face identification and verification. LUNA Software is based on algorithms using deep neural networks and has the following functions: facial image quality scoring, extracting key face features as a unique descriptor packed in a biometric template, biometric template matching. Vision Labs LLC page 4 | 12 2 LUNA Architecture LUNA has the following main components: Broker – a module implementing API; Extractor – a handler extracting biometric template from images; Matcher – a handler matching biometric templates. The software is also uses the following optional components: RabbitMQ – Queue Manager (QM); Aerospike – Database Management System. LUNA component interaction diagram is shown in Figure 1. Biometric template list handling Extractor 1 Req Resp . . . Extractor N HTTP REST API Req Biometric template handling Rabbit MQ Broker Get, Put Put Resp Request data, Response data, Protocol amqp Resp Req Matcher 1 . . . Get Aerospike DB Matcher N LUNA Software Figure 1 - LUNA Component Interaction Diagram 2.1 Broker Broker module is a web-server that implements protocol HTTP/HTTPS providing interfaces with external systems. Data is communicated using RESTful API that is described in Luna API v5 manual. Broker gets API requests from external systems and performs initial query data validation. Broker refers to Aerospike database directly if it receives a query for handling template identifier list. Vision Labs LLC page 5 | 12 If a handler (Extractor, Matcher) is called, Broker prepares data required for a particular handler and queues it up in the queue manager (RabbitMQ). Idle handler receives query from the queue; when data is processed the handler returns a respond to Broker that in its turn responds to query via API. Thus, Broker executes API request from external systems in synchronous mode, and data handlers – in asynchronous mode. 2.2 Queue Manager RabbitMQ Queue manager arranges communication between Broker module and Extractor and Matcher data handlers. This component realizes a configurable network queue of messages with guaranteed delivery. The queue is implemented based on AMG protocol using RabbitMQ as a queue manager. 2.3 Extractor Extractor handler receives tasks for extracting a biometric template from images. Interaction of LUNA components when extracting biometric template from images is shown in Fig. 2. Client Broker MQ Extractor DB API request Task queuing Task is in queue Task is accepted by handler Processing Waiting for result Template saving Obtaining result from the queue Task processing result Result saving API response Figure 2 – Biometric Template Extraction Process Diagram Vision Labs LLC page 6 | 12 Broker creates tasks for biometric template extraction when it receives API queries to ‘templates’ vehicle from external systems. Biometric data extraction is realized via VisionLabs FaceEngine library. Data extracting is a one-way process that means that biometric data cannot be converted to the original image. The result of biometric data extraction is as follows: success response; biometric metadata; biometric template with biometric data. Success response and biometric metadata are transferred to Broker via the queue manager; and Broker generates API response to the external system. Extractor stores a complete biometric template (if data extraction is successful) directly in Aerospike database. Except for the template, no other data is stored in the database enabling specific person (full name, original photo, etc.) identification. 2.4 Matcher Matcher handler receives tasks for biometric template matching. Interaction of LUNA components when matching biometric templates is shown in Fig. 3. Vision Labs LLC page 7 | 12 Broker MQ Matcher 1 . . . Client Matcher N DB API request Request segmenting to tasks Task 1 queuing . . . Task 1 accepted for processing Data request Tasks in queue Obtaining data Task N queuing Task N accepted for processing Processing Waiting for result Data request Obtaining data Processing result Obtaining segment 1 of the result Processing Processing result Obtaining segment N of the result Result concatenation API response Figure 3 – Biometric Template Matching Process Diagram Broker generates this type of tasks when it receives API requests to similar_templates vehicle. Biometric template matching is realized via VisionLabs FaceEngine library. Upon receiving a task, Matcher requests the necessary data from Aerospike database, processes data and returns the result. The result of the biometric template matching is as follows: success response; matching result data. Success response and matching results are transferred to Broker via the queue manager; Broker generates API response to the external system. Vision Labs LLC page 8 | 12 2.5 Aerospike Database Management System Database Management System is used to create a reliable, fail-free storage for biometric templates and their identifier lists. NoSQL Aerospike is used for speeding up that enables high read and write rates. Aerospike solution follows ACID paradigm and support database replication and clustering. Vision Labs LLC page 9 | 12 3 Data Replication Data replication is performed at Aerospike level by clustering two or more Database Management Systems with data replication. DB data replication is aimed at baking up the data in case of production server hardware failures. Data replication at Aerospike DB level requires to: provide for network server connectivity with the database ensuring minimum delays and maximum capacity; configure DB data exchange mechanism for replication purposes; specify all the DB server nods participating in data replication for each server configuration; specify certain parameters defining the number of data copies for back up within a cluster. Example 1: Cluster Configuration Settings: heartbeat { mode multicast address 239.1.99.222 port 9918 interval 150 timeout 10 } This configuration ensures operation of the replication mechanism via multicast addressing. The given configuration introduces the server into the cluster where nodes automatically detect the cluster and start communicating replication data. Example 2: Configuration Settings of Two-Server Cluster with Explicit Reference to IP Addresses of Data Replicating Nods: heartbeat { mode mesh address _SERVER1_IP_ Vision Labs LLC page 10 | 12 port 3002 mesh-seed-address-port _SERVER1_IP_ 3002 mesh-seed-address-port _SERVER2_IP_ 3002 interval 150 timeout 10 } This configuration indicating two server IP addresses ensures operation of the replication mechanism. Vision Labs LLC page 11 | 12 4 Scaling and Clustering LUNA system is capable of horizontal linear scaling. Scaling is performed with LUNA server stacked having unified settings and linking Aerospike DB into the cluster with data replication. Figure 4 shows LUNA component interaction during the setting for linear scaling operation. Extractor 1 Req Req Broker Resp . . . Extractor N Rabbit MQ Get, Put Put Resp Resp HTTP REST API Req . . . Get Aerospike DB Server 1 Matcher N Server 1 Bus \ Request handler Client Matcher 1 Aerospike DB replication Matcher 1 Server N Req Req Broker Resp . . . Get Aerospike DB Server N Matcher N Rabbit MQ Put Resp Extractor 1 Resp Req Get, Put . . . Extractor N Figure 4 – LUNA Linear Scaling Process Diagram Server loading is balanced by an external balancer that reallocates API requests to the server stack assigned to provide for LUNA operation under productivity scaling scheme. Balancing is performed by proxying API queries from Clients from query balancer to LUNA server addresses. There is a possibility to track error response codes and decide on request forwarding to other servers that enables backing up. Vision Labs LLC page 12 | 12