Download Architecture and Scaling Capability

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
Transcript
+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