MOMENT™

Solution Descriptions

1

Contents

• Features of MOMENT™ • Archtecture • System Topology • Performance • Roadmap

2

Features of MOMENT™

3

4

Features

- In-memory computing

■ As fast as possible

- Auto scaling based on cloud system - Auto aging data - Auto load balancing

■ Easy scalable

- Direct query from cluster - Easy query language - Streamming data query

■ Real-time query

- Replication

■ Failover

5

As fast as possible

우리가 사용할 수 있는 시스템이 Von Neumann Architecture 라면, Process 가 수행하는 연산은 결국, CPU 와 Memory 사이에 일어나는 것이다. 따라서, Process 가 가장 빠르게 연산을 수행하려면, 연산하려는 그 순간, 데이터의 위치는 File system 이 아닌 Memory 이어야 한다. 그럼에도 불구하고, 여전히 File system 을 사용해야 하는 이유는 확실하다. Memory 상에 로딩된 데이터는 Process 중단과 동시에 사라져 버리기 때문이다. 하지만, 현실적으로 판단해보자. 서비스가 안정화 단계로 진입했다는 가정은 반드시 필요하겠지만, 서비스를 운영하면서 데이터베이스 시스템을 시시때때로 중단했는가? 메모리에 데이터를 다시 로딩하는 초기화 시간을 감수할 수 있다면, 연산 대상이 되는 모든 데이터를 Memory 에 올리는 것은 속도를 위한 최선의 선택이다. 메모리에 데이터를 로딩하는 초기화 시간은 실제 이 시스템을 사용하는 사람은 인지하지 못하는 시간이다. 그들은 데이터 로딩 시간을 감내하는 시스템 운영자의 지루함에는 관심이 없다. 얼마나 빠르게 연산을 수행하는지가 그들이 관심을 가지는 것이다.

■ Overview

(1/5)

File System

6

As fast as possible

Data #1

Process

Data Memory

Data #2 Data #n-1 Data #n

File I/O

Operating Data #1 Operating Data #N

File I/O

File system 에 기반하는 경우, 데이터의 개수 만큼의 File I/O, 즉, File System 에서 Process 의 Data Memory 로 로딩하는 과정이 수행된다. Big data 분석에서, 연산해야하는 데이터의 수는 대부분 전체 데이터 이다. 즉, 아래의 식에서 n 은 대부분 전체 데이터의 수이다.

…

𝐿𝑇 = 𝐷𝑇(𝑖)

𝑛

𝑖=1

+ 𝑃𝑇(𝑖)

𝑛

𝑖=1

LT : lead time DT : data loading time PT : data processing time

■ Base on file system

(2/5)

File System

7

As fast as possible

Data #1

Process

Data Memory

Data #2 Data #n-1 Data #n …

𝐿𝑇 = 𝑃𝑇(𝑖)

𝑛

𝑖=1

IT : Initializing time LT : lead time DT : data loading time PT : data processing time

𝐼𝑇 = 𝐷𝑇(𝑖)

𝑛

𝑖=1

Data #1 Data #2 Data #N-1

Data #N

…

Loading all data into memory

Initializing 단계에서는 File System 의 데이터를 메모리로 로딩하는 시간이 필요하지만, 데이터를 연산할 때에는 그 시간이 필요하지 않게 된다.

■ In-memory type

(3/5)

8

■ Memory is expensive?

64bits system 의 등장과 더불어 시스템의 메모리 가용 용량은 증가하였고, 그 가격은 이전과는 비교할 수 없을 정도로 저렴해졌다. 하지만 여전히, 모든 데이터를 메모리에 로딩할 경우, 우려되는 것은 바로 Cost 이다. 아직까지 Memory 는 Disk 보다 100배, SSD 와 비교하면 약 10배 비싸다. 하지만, 목표하는 성능을 충족하는 조건에서 비용에 대한 비교가 되어야 한다. 현재 10배 저렴한 SSD 디스크는 약 500Mbps 의 성능을 낸다. 즉, 최대 1초에 500 M 를 처리할 수 있는데, Tera bytes 급의 데이터를 처리하기에는 부족한 성능이기 때문에 불가피하게 분산 처리를 선택할 수 밖에 없다. (1T 의 데이터를 1대의 시스템으로 처리하기 위해서는 최소 2,097 sec 가 필요하다. 1T / 500Mbps = 2,097 sec) 64bits system 이라면, 이론상 16 Exabytes 의 Memory 를 사용할 수 있으나, 실제로 OS 에서 제공하는 최대 메모리는 1-2TB 이고, Cloud 서비스에서 제공하는 장비당 Max memory 크기는 200GB (AWS case.) 정도이다. 따라서, Memory 에 1TB 의 데이터를 로딩하려면 불가피하게 시스템 장비를 여러대 운영할 수 밖에 없다. 1T 데이터를 1분안에 처리하는 분산 시스템을 목표로 할 경우 필요한 분산 시스템 수는 다음과 같다.

In-Memory 방식의 경우 시간당 약 $ 1.5 의 시스템 비용이 더 발생하고 있다. 물론, 이 수치는 데이터 처리 시간을 고려하지 않은 분산 시스템 수이고, 각각의 상황에서 필요한 CPU 수준을 고려하지 않았기 때문에, 정확한 산정은 아닐 수 있다. 하지만, Disk 의 처리 능력을 고려했을 때, Memory 라는 resource 가 훨씬 비싼 것만은 아니라는 결론은 얻을 수 있다. 게다가, AWS 의 경우, File I/O 회수에 따라 과금이 되기 때문에, File system 에 의존하는 것이 결코 저렴하지 않다.

As fast as possible

Base on file system In-Memory

필요 대수 1T / 500Mbps / 60 = 30, AWS m3.xlarge 사용 1T / 200G = 5, AWS r3.8xlarge 사용

시스템 비용 30 * $ 0.532 (/h) = $ 15.96 / hour 5 * $ 3.5 (/h) = $ 17.5 / hour

(4/5)

9

As fast as possible

𝐿𝑇 = 𝐷𝑇(𝑖)

𝑛

𝑖=1

+ 𝑃𝑇(𝑖)

𝑛

𝑖=1

LT : lead time DT : data loading time PT : data processing time

𝐿𝑇 = 𝑃𝑇(𝑖)

𝑛

𝑖=1

Base on file system In-memory type

>

Big data 분석이라는 것은 많은 양의 데이터에서 의미있는 결과를 얻어내는 과정이다. 즉, system 이 수행해야되는 일의 n 의 값이 항상 크다는 것을 의미한다. 시스템이 보유한 데이터의 개수가 1억개라면, 매번 시스템이 연산해야되는 데이터의 개수는 1억개에 가까울 것이다. 따라서, 데이터를 미리 메모리에 로딩해두는 것이 메모리 낭비가 아닌 연산 속도를 위한 최적의 선택이라고 할 수 있다. 예를 들어, 데이터 1개를 메모리에 로딩하는 시간을 0.00001 초 라 하자. (아마도 대부분, 이 시간보다는 훨씬 더 걸릴 것이다.) 만약 1억개의 데이터를 연산해야한다면, 0.00001 * 100000000 = 1000 (sec), 즉, 16 분이 매번 더 필요하게 되는 것이다. 시스템이 초기화 되는데 16분을 기다릴 것인가? 아니면, 매번 시스템의 응답을 기다리는데 16분을 더 기다릴 것인가? 결론적으로, MOMENT™ 는 데이터 연산 속도를 위해, In-Memory computing 을 적용하고 있다.

■ Conclusion : In-memory computing for performance

(5/5)

10

Easy Scalable

■ Overview

Big data 를 처리하는 시스템을 운영할 때 힘든 부분 중의 하나는 데이터 크기와 원하는 성능에 맞는 시스템 규모를 sizing 하고, 적절한 시점에 시스템 크기를 조정하는 것이다. 대부분 이러한 시스템 증설 (혹은 감설) 작업에는 데이터를 옮기거나 삭제하는 작업이 수반되는데, 다루는 데이터가 크고 개수가 많기 때문에, 운영자의 리소스에 의존하여 운영하기 보다는 자동화를 통한 관리가 반드시 필요하다. 데이터를 에이징 작업의 경우, 에이징할 데이터의 수와 양이 크기 때문에 필요한 작업 시간이 길 수 있는데, 서비스를 중단할 수 있는 시간은 그 보다 훨씬 짧을 수 있다. 서비스 중단 없이도 에이징이 가능한 구조가 반드시 필요하며, 에이징 주기는 시스템 성능에 영향이 없는 범위에서 짧을 수록 좋다. Auto scaling 을 위해서는 기본적으로 시스템 투입 및 제거가 자동화 되어야 된다는 뜻이므로, cloud system 을 활용하는 것이 필요해진다. 데이터 aging 을 자동화 한다는 것은 자동으로 데이터를 삭제하는 정책을 적용한다는 것이고, 기술적으로 그것은 어려운 구현이 아니다. 다만, 데이터가 자동으로 지워진다는 것은, 분산 시스템에서 데이터가 한쪽으로 몰릴 수 있다는 것이고, 데이터를 고르게 재 분배하는 것이 자동화 되어야 한다는 것을 뜻한다. 따라서, 자동으로 load balancing 이 될 수 있는 시스템 구조가 필요하게 된다.

11

Easy Scalable

■ Auto scaling based on cloud system

Cloud Service 를 활용하면, 데이터의 양에 따라 시스템 규모를 자동으로 조절할 수가 있다. MOMENT™ 는 AWS (Amazon Web Services) 와 연동해 자동으로 시스템 규모를 결정하고, 그에 필요한 장비를 투입하여, 가장 효율적인 시스템 운영이 가능하도록 한다. MOMENT™ 시스템은 크게 Central Server 와 Node Server 로 이루어지며, Central 서버는 Node Server 의 Memory Usage Table 을 관리한다. 각 Node 의 Memory Usage 에 따라 시스템 증설 혹은 감소를 결정하게 된다.

Data Manipulation

Queue Data Allocator

Central Server

Table Manager

Partition Manager

Table Manager

Partition Manager

Node Server #1

Insert, Update, Delete Data

Node Server #10

…

Node Memory Usage

Node#1 54%

Node#2 51%

…

Node#10 48%

Memory Usage Table

AWS EC2 SDK

12

Easy Scalable

■ Auto aging data

항상 모든 데이터를 유지하면서 분석을 하면 좋지만, 시스템 자원은 항상 제한적이다. 따라서, 의미없는 오래된 데이터는 주기적으로 삭제해주는 것이 필요하다. MOMENT™ 는 데이터 저장소와 데이터 조회 영역이 분리되어있기 때문에, 데이터 에이징을 시스템 중지 없이 처리할 수 있다. 메모리에서의 데이터 에이징 작업은 File system 보다 훨씬 빨리 처리할 수 있고, 부하도 크지 않기 때문이다. Auto aging 설정은, 데이터들을 관리하는 Table 단위로 지정이 가능하다. 메모리 상의 데이터 에이징은 1) 데이터가 추가될 때, 2) 데이터가 업데이트 될 때, 그리고 3) 주기적인 Batch 작업에 의해 이루어진다. 파일 시스템상의 Raw Data 에이징은 메모리 데이터 에이징시 발견된 대상을 에이징 큐에 기록한 뒤, 주기적인 Batch 작업에 의해 삭제 처리한다.

Table Manager

Partition Manager

Data Manipulation

Queue File System

Data Aging Queue

for File system

Insert, Update Data

Aging?

Aging data from file system

Batch Job

Aging data from memory

13

Easy Scalable

■ Auto load balancing

메모리의 사용량에 따라 데이터를 Node 서버에 분산하지만, 데이터의 Update 가 일어나고, 데이터 에이징이 반복되면, 특정 Node 의 메모리 사용량이 올라가는 현상이 발생할 수 있다. 또한, 데이터의 업데이트가 반복되면서 할당된 Node 의 가용 용량을 초과하여 다른 Node 로 데이터를 이전해야되는 경우도 발생할 수 있다. MOMENT™ 는 자동으로 데이터의 Location 을 다시 할당하는 기능을 제공한다. Central 서버는 각 노드들의 메모리 사용량을 모니터링하고, 전체 Node 의 평균 메모리 사용량보다 특정 Node 의 메모리 사용량이 일정 비율을 초과할 경우, 자동으로 해당 Node 의 일부 데이터를 다른 Node 로 재할당하는 작업을 수행한다.

Data Allocator

Central Server

Node Memory Usage

Node#1 54%

Node#2 90%

…

Node#10 48%

Memory Usage Table

Table Manager

Partition Manager

Node Server #2

Broken balance?

[Batch job] Checking the balance of memory usage

Give up your data!

Request re-allocation

14

Real-time Query

■ Overview

Hardoop 의 분석 Framework 인 Map, Reduce 는 개념적으로 매우 훌륭한 framework 이다. 하지만, Raw Data 의 형태에 따라, Map 을 구현하고, Reduce 구현하는 과정이 필요하다. 요구 사항 변경에 따라 Map, Reduce 모듈에 대한 구현을 변경하고 Deploy 하는 과정을 거쳐야 하기 때문에 사용하기에 불편한 점이 있다. 또한, 전체 데이터를 대상으로 Map, Reduce 를 거쳐야 원하는 결과를 추출할 수 있는 상황이 되기 때문에, 실시간† 처리는 불가능한 것이었다. 이를 보완하기 위해, Hardoop framework 을 활용하면서 컬럼 기반 NoSQL 인 Hbase 가 등장하였고, 비로소 실시간 처리가 가능한 구조가 되었다. MOMENT™ 에서도 비슷한 고민을 하였고, 우선 Memory Map 을 활용한 컬럼 방식으로 데이터 저장할 수 있도록 설계되었다. 실시간 쿼리가 가능하도록 클러스터 간 데이터 조회를 최소화 하기 위해, 각 클러스터 마다 데이터 분석 모듈을 배치했고, 각 클러스터의 데이터 분석 모듈은 로컬의 데이터를 조회하여 쿼리에 대한 결과를 생성하게 된다. MOMENT™ 의 Real-time Query 와 관련된 구현 사항은 다음과 같다. 1) 효율적인 데이터 분석을 위해 클러스터간 통신으로 데이터를 조회하지 않고, 로컬 데이터를 직접 읽도록 함 2) 프로그래밍 구현에 의한 Query 가 아닌 SQL 과 유사한 Query language 를 통한 데이터 조회 가능 3) 스트리밍으로 들어오는 데이터를 반복해서 쿼리할 수 있는 기능 제공

[실시간] 실시간 이라는 것은 어느 정도의 시간을 뜻하는 것일까? Impala 의 Architect 는 다음과 같이 이야기했다. “It's when you sit and wait for it to finish, as opposed to going for a cup of coffee or even letting it run overnight. That's real time”

15

Real-time Query

■ Direct query from cluster

전체 데이터 View 에서 Query 를 수행하는 것이 아니라, 여러 개의 Node 로, 그리고 내부에는 Table 별로 구성된 Partition 에서 Query 를 병렬로 수행한 뒤, 상위로 결과를 합치는 작업을 반복한다. 이 방식을 통해 응답시간을 실시간 수준으로 올릴 수 있게 된다. 이를 위해서 최종적인 데이터 조회는 Partition 레벨에서 이루어져야 하며, 그러기 위해서는 각각의 Node에 Query 를 수행하는 모듈이 있어야 만 한다. 클러스터에서 로컬에 있는 데이터를 직접 조회하면서 쿼리를 수행하기 때문에, 클러스터간 네트워크 통신을 최소화 할 수 있게 된다.

Central Server

Table #1

Partition #1

Node Server #1

Partition #100 …

Synthesizer

Query job for each partition

Query Processor (Thread pool)

Synthesizer Query Processor

Synthesizer Query Processor

Synthesizer Query Processor

Node Server #2

Node Server #3

Synthesizer Query Processor

Node Server #10

Broadcast query job to sub nodes

…

16

Real-time Query

■ Easy query language

MOMENT™ 는 SQL 과 유사한 형태의 Query Syntax 를 지원해, 실시간 Query 기능을 제공한다. 현재 버전은 ANSI/ISO SQL Standard 와의 Compliance 를 확보할 수 있는 기본 모듈이 구현되어 있으며, JSON 형태로 작성해 전송할 수 있다.

{ “query”: { “select” : [ { … } , { … } ], “from” : “ Table Name “, “where” : “ Retrieving condition “ }, “receiver” : { “data_format” : “json_array”, “type” : “direct_http”, “url_format” : “ … “ } }

데이터를 조회 하고자 하는 Table 이름은 from object 에 지정하고, where object 에는 조회하는 조건을 지정한다. 논리 연산자 (|, &), 비교 연산자 ( >, <, =, <=, >=) 를 지원하며, 우선 순위는 괄호로 묶어 지정할 수 있다. 동일한 from 과 where 로 여러 개의 조회 내용을 한꺼번에 지정할 수 있다. select object 은 크게, 목록을 조회할 수 있는 list, 목록 내 값의 개수를 셀 수 있는 count, 생성된 목록에서 값의 합을 구할 수 있는 sum type 으로 정의된다.

Query 결과를 전송하는 방법을 정의하는 object 이다. Query 결과의 size 가 클 수 있다는 것을 고려해 크게 4가지의 receiver 를 지원한다. 1) 결과를 File system 에 저장한 뒤, 파일을 조회할 수 있는 정보를 HTTP 방식으로 호출 2) 결과를 File system 에 저장한 뒤, 파일을 조회할 수 있는 정보를 Queue 에 Push 3) 결과를 HTTP Parameter 로 직접 전송 4) 결과를 TCP / IP Packet 으로 전송하는 방식

17

Real-time Query

■ Query Syntax

select Object Type JSON Array 로 Multi query 를 지정 가능

query_key String Query 내에서의 Unique 한 값. 결과를 리턴받을 때 어떤 쿼리에 대한 결과인지를 구분하기 위한 값.

type list column String Array 결과를 탐색할 컬럼 정보

order_by String Sorting 을 수행할 컬럼

sort Number 오름차순, 내림차순

limit Number 조회할 결과의 최대 수

count group_by column String Grouping 할 컬럼 정보

sort Number Grouping 할 때의 Sorting 옵션

limit Number Grouping 할 최대 수

target String Array Grouping 할 값의 목록. 해당 값만 Counting 함.

distinct String distinct 처리할 컬럼명

sum group_by column String Grouping 할 컬럼 정보

sort Number Grouping 할 때의 Sorting 옵션

limit Number Grouping 할 최대 수

distinct String distict 처리할 컬럼명

column String 합을 구할 컬럼명

18

Real-time Query

■ Streaming data query

MOMENT™ 는 축적된 데이터의 빠른 조회 뿐만 아니라, 지속적으로 투입되는 데이터의 Filtering 기능도 제공한다. Filter 의 등록, 삭제, 수정, 시작, 중지에 대한 인터페이스를 제공하며, 수신되는 데이터에서 원하는 조건에 맞는 데이터를 필터링해 타 시스템으로 전달할 수 있다.

Data Queue

Streaming data source Streaming Filter Processor

Synthesizer

Table Manager

Query Processor

Data Allocator

Filter Client Regist, Unregist, Modify filters Start filter, Stop filter

Query Processor

Synthesizer

① Data Allocation

② Processing Query

③ Filtered result notification

④ Clearing data

②

Central Server

Node Server #1 (Extensible)

19

Failover

■ Overview

MOMENT™ 는 raw data storage 가 별도 존재하고, 시스템 초기화 시에 Memory 에 로딩되기 때문에, raw 데이터에 대한 replication 은 고려하지 않고 있다. (AWS 의 S3 의 경우, data integrity 를 보장하고 있다.) MOMENT™ 내부 시스템에서 데이터 유실시 시스템 초기화가 불가능한 부분에 대해서는 별개의 system 에 replication 함으로써 Failover 되도록 하고 있다. 또한, In-Memory computing 방식이기 때문에, 할당된 데이터를 로딩해 시스템을 초기화 하는데에는 시간이 오래 걸리는 단점을 가지고 있다. 이런 단점을 극복하기 위해, 로딩할 데이터를 Local File DB 에도 저장하며, 이 File DB 는 별개의 시스템에 replication 되도록 설정할 수 있다. Failover 를 위해 replication 을 구성하는 곳은 다음과 같다. 1) Central Server 의 Data allocation 정보 2) 로딩할 데이터의 Raw data 경로 3) 로딩된 데이터의 Hash value (CRC32) 4) 로딩된 데이터의 Local Cache DB

20

Failover

■ Replication

MOMENT™ 에서 사용하는 Local File DB 는 Oracle Berkeley DB 를 사용하고 있으며, Berkeley DB 를 online relication 이 가능하도록 구현되어 있다. Master 로 들어온 Event 는 Replication Manager 에 의해 Remote system 의 Event queue 로 전달되며, Slave 의 처리에 대한 응답을 받고 난 뒤, local database 에 반영한다. 만약 Master 가 동작하지 않는 경우, Database Access module 은 Slave 로 Client 의 요청을 보낸다. Slave 는 Replication Event 가 아닌 일반 Insert, Update, Delete Event 가 들어온 경우에는 Master sync를 위해 해당 Event 들을 큐잉한다.

Master Slave

Berkeley DB

Event Handler

Replication Manager

Berkeley DB

Event Handler

Replication Manager

Replication Event 인 경우 Skip

Replication 요청

Replication 완료 Put Data Put Data

Event queue Event queue

Database Acess Module Put data Event queue

Architecture

21

22

Layers - Data

Data Source

Data Management

AWS S3 AWS DynamoDB MySQL MongoDB

Job Queue Service Berkeley DB Library

Data Allocator Table Manager Partition Manager Aging checker Load checker

Data Sync. Client

Data Source Gateway

SGW MyGW DyGW

AWS SDK JDBC

MoGW Remote BDB

Service

Data Allocator : Data 를 memory 에 Loading 할 Node Server 할당 Load checker : Memory Usage 를 체크해 Node 서버의 부하를 균일하게 관리 Table Manager : Schema 정보를 관리하고, 데이터를 Partition 에 할당. Data 의 Insert, update, delete 처리 Partition Manager : Memory map 관리. Aging checker : 데이터의 변화 시점에 aging 대상여부 확인. 변화가 없는 데이터의 경우 주기적으로 check. Remote BDB Service : Local DB 인 BDB 의 Network 을 통한 접근을 위한 service. Fail over 를 위한 BDB 의 replication 도 함께 처리함. SGW, MyGW, DyGW, MoGW : raw data 에 접근하기 위한 gateway server Job Queue Service : 순차적인 처리를 위한 Queue 서비스. Local access 는 물론, 네트워크를 통한 remote access 가능. JSON format 으로 정의된 Job 의 Push / Pop 기능 제공

23

Layers - Query

Query Management

Application Query Client C/C++ Lib. Java Lib. TCP/IP

Job Queue Service Thread Pool Berkeley DB Library

Query Processor Synthesizer

Filter Client C/C++ Lib. Java Lib. TCP/IP

Cache Manager Query Parser

Query Client : 데이터 조회를 위한 Query 를 전송하고, 그 결과를 받는 client. Filter Client : Streaming Data 에 filter 를 지정하고, filtering 된 결과를 받는 client. Query Processor : 하위 노드에 query 를 broadcasting 하고, synthesizer 를 이용해 결과를 merge 한 뒤, query 혹은 filter requestor 에게 결과를 전송함. Synthesizer : Partition 혹은 Node 단위로 수행된 Query 결과를 Merge 해 최종 결과를 생성해내는 모듈. Cache Manager : Query 결과에 대한 cache 를 생성. cache 의 만료 기간을 관리하고, cache 의 존재 여부를 판단. 동일한 Query 에 대해 불필요한 반복 처리를 피하기 위함. Query Parser : JSON 형태로 구성된 Query Syntax 를 확인하고, 수행해야될 Query 정보를 추출하는 모듈 Thread Pool : Multi-Job 을 동시에 처리하기 위한 framework

System topology

24

25

MOMENT™ System

CMM

Central Server

MM

Node Server #1

MM

Node Server #2

MM

Node Server #n

QM

Queue Manager Server

MC

MOMENT Cache (Remote BDB Service)

…

Data Source Query Client

MC-Replica

MOMENT Cache (Remote BDB Service)

SGW

Amazon S3

Sub node query

Request query

Send query result

Save raw data to S3

Push jobs for inserting data with parameter of Amazon S3 path.

Pop jobs of inserting data.

Save data location information, data hash value.

Extensible node

Alloc. Modify Delete Data

Performance

26

27

Query response time & System cost

■ Query response time

[Test Environment] Total record count : 1,000,000,000 Total record size : 235.39 GB Column Count : 15 Node Server Count : 10

Query type Response time

Calc. Count without group-by 11.75sec.

Calc. Count with group-by 70.64 sec.

Calc. Sum. 57.75 sec.

■ System Cost ($ per month, base on AWS)

Instance Instance type Count Cost ($)

CORE (CMM, QM) m3.large On-Demand 1 201.6

MM r3.xlarge Spot 10 2030.4

MC m3.medium On-Demand 2 (include replica.) 201.6

SUM. 2433.6

Roadmap

28

29

Our next plans

• Security • ANSI/ISO SQL standard compliance • Interactive tools • Package for 1-time installation

Thank you

30