일년만에, 블로그에 새 글을 올려봅니다. 그동안, 많은 주제가 있었지만, (주관적인 판단이지만) 좋은 주제일지 예전같은 확신이 서지 않아서, 많은 시간 망설이며 잠시 블로그를 멈추었습니다.
그러나, 제가 알던 경험이. 나만의 아련한 기억이 되고 점차 소멸되기 전에. 잊기 전에. 블로그 하나를 올려봅니다. 멀티DC 환경을 고려하면서, 몇가지 테스트를 하던 중. 노드간 네트워크 레이턴시를 고민을 했었는데. TC(Traffic control)를 활용하였고 나름 의미있는 결과를 도출했었는데.. 오늘은 tc에 대해서 이야기를 해보고자 합니다.
Traffic control (TC)?
동일 네트워크 상에서, DC간의 레이턴시를 고려하여 성능 변화를 테스트하고 싶은 경우가 있습니다. 특히나, 과거와는 다르게 서비스가 여러개의 DC 또는 Zone에서 분산 구동될 수 있다는 상황을 고려해본다면. 이런 테스트는 필수 입니다. 참고로, 아주 오래 전, 서울/부산 레이턴시 14ms로 인하여 대형 서비스 장애를 경험해본 입장으로. 서비스 오픈 전 이런 검증은 필수라 생각합니다.
그렇다면, Linux에서는 동일 네트워크 상에서 레이턴시를 어떻게 부여해볼 수 있을까요?
Linux에는 TC(Traffic Control)라는 좋은 유틸이 있습니다. 이 유틸은 iproute에 포함된 것으로, 아래와 같이 패키지를 설치하면 간단하게 사용해볼 수 있습니다.
$ yum -y install iproute
Redhat8 버전에서 tc로 netem 을 사용하기 위해서는 추가 커널 모듈 설치가 필요합니다. 모듈 설치에는 서버 재시작은 굳이 필요 없습니다. ^^
아래와 같이 현재 IP가 192.168.56.101로 서버가 구동 중입니다. 그리고, 192.168.56.102 / 192.168.56.103 모두 레이턴시가 0.3ms 입니다.
$ ifconfig
.. skip ..
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.101 netmask 255.255.255.0 broadcast 192.168.56.255
.. skip ..
$ ping -c 1 192.168.56.102 | grep ttl
64 bytes from 192.168.56.102: icmp_seq=1 ttl=64 time=0.360 ms
$ ping -c 1 192.168.56.103 | grep ttl
64 bytes from 192.168.56.103: icmp_seq=1 ttl=64 time=0.320 ms
자, 이 상태에서, 192.168.56.103 에만, 추가로 30ms레이턴시를 부여해봅니다. 102번 서버는 여전히 0.3ms 정도로 레이턴스 변화가 없는 반면, 103서버만 30ms가 레이턴시가 증가된 것을 확인해볼 수 있습니다.
$ tc qdisc add dev eth1 root handle 1: prio
$ tc qdisc add dev eth1 parent 1:1 handle 10: netem delay 30ms
$ tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.56.103 flowid 1:1
$ ping -c 1 192.168.56.102 | grep ttl
64 bytes from 192.168.56.102: icmp_seq=1 ttl=64 time=0.280 ms
$ ping -c 1 192.168.56.103 | grep ttl
64 bytes from 192.168.56.103: icmp_seq=1 ttl=64 time=30.4 ms
TC commands
이것 외에 유용한 명령어 몇개를 모아봅니다. TC를 처음 접했을 때, 개인적으로는 상당히 유용했습니다. ^^;;
## qdisc 리스트
$ tc qdisc list
qdisc noqueue 0: dev lo root refcnt 2
qdisc prio 1: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc netem 10: dev eth1 parent 1:1 limit 1000 delay 10ms
## filter 상태
$ tc filter show dev eth1
filter parent 1: protocol ip pref 1 u32 chain 0
filter parent 1: protocol ip pref 1 u32 chain 0 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 not_in_hw
match ac104371/ffffffff at 16
filter parent 1: protocol ip pref 1 u32 chain 0 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:1 not_in_hw
match ac104371/ffffffff at 16
$ ping -c 1 192.16.56.100
PING 192.16.56.100 (192.16.56.100) 56(84) bytes of data.
64 bytes from 192.16.56.100: icmp_seq=1 ttl=64 time=10.2 ms
## 정책 삭제
$ tc qdisc del dev eth1 root
Conclusion
멀티DC 기반 클러스터 구성 시 영향도를 사전에 검증해볼 수 있습니다.
위에서는 단순히 레이턴시 정도만 지정해보았지만, 사실 대역폭을 비롯하여 패킷드랍 환경 등 아주 많은 설정들이 있습니다. 저는 Kafka를 Stretch cluster (여러 DC에 분산 구성한 클러스터)로 구성을 하였을 때. 각 DC간 레이턴시를 부여하는 식으로 환경을 마련하였고. 이로 인해 상당히 많은 의미있는 결론을 도출해보기도 했습니다. ^^
데이터 복제 구성이라면. 비동기 복제 시간에 따른 영향도도 사전에 파악해볼 수 있겠고. 저장소 클러스터 환경 구성 외에도. 캐시 아키텍처 검토를 위한 노드간 레이턴시 환경도 구성해볼 수 있겠습니다.
생각을 해보면. 서비스 오픈 전. 나름 레이턴시로 인한 영향도를 사전에 상당 부분 tc로 검증해볼 수 있다고 봅니다.
그동안 업무적으로 많은 변화도 있던 격동의 시기였던지라, 제 삶의 가장 중요한 요소 중 하나라 생각하던 공유의 가치를 그만 간과하고 말았네요. 물론 포스팅을 멈춘 시간동안 놀지 않고 많은 경험을 쌓아보았습니다.
오늘은 그중 하나, 인메모리 데이터베이스인 Apache Ignite에 대해 이야기를 해보고자 합니다.
Apache Ignite?
이미 많은 분들이 Ignite 를 사용해보셨을 수도 있겠습니다만, 저는 DBA로 일을 하면서도 늘 제대로된 캐시 용도로 써보고 싶었던 분산 인메모리 데이터베이스가 Apache Ignite입니다.
Server 기반 클러스터링 구성도 가능하고, Application 기반 클러스터링도 가능합니다. 참고로, 이 포스팅에서 이야기할 내용은 Server 기반 클러스터링 구성이고, 인메모리가 아닌 파일 기반 분산 캐시 형태로 사용합니다. SSD로 인해 디스크 Random I/O가 과거 대비 압도적으로 향상된만큼, 캐시 데이터 또한 디스크에 저장하지 않을 이유는 없습니다.
저는 개인적으로 하단 세가지 특성을 Ignite의 가장 큰 강점이라 생각합니다.
Persistence Mode
SQL(JDBC) 지원
분산 캐시
스케일 인/아웃
Quick Start
도커 기반으로 로컬에서 기능적으로 간단하게 테스트해볼 수 있는 환경을 구성해봅니다.
## 도커에서 사용한 데이터 영역 마운트를 위해 디렉토리 생성
$ mkdir -p $HOME/ignite/storage
## persistenceEnabled만 들어간 설정을 생성하기
$ echo '<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="ignite.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
<property name="dataStorageConfiguration">
<bean class="org.apache.ignite.configuration.DataStorageConfiguration">
<property name="defaultDataRegionConfiguration">
<bean class="org.apache.ignite.configuration.DataRegionConfiguration">
<property name="persistenceEnabled" value="true"/>
</bean>
</property>
</bean>
</property>
</bean>
</beans>' > $HOME/ignite/storage/config.xml
## 도커 시작
$ docker run -d \
-p "10800:10800" \
-v $HOME/ignite/storage:/storage \
-e IGNITE_WORK_DIR=/storage \
-e CONFIG_URI=/storage/config.xml \
--name ignite \
apacheignite/ignite
## 클러스터를 ACTIVE로 전환
$ docker exec ignite bash -c 'yes | /opt/ignite/apache-ignite/bin/control.sh --set-state ACTIVE'
Warning: the command will change state of cluster with name "fc4636efa81-50c9c9bd-a798-46a0-992b-c821b80f623f" to ACTIVE.
Press 'y' to continue . . . Control utility [ver. 2.15.0#20230425-sha1:f98f7f35]
2023 Copyright(C) Apache Software Foundation
User: root
Time: 2023-10-05T05:50:44.866
Command [SET-STATE] started
Arguments: --set-state ACTIVE
--------------------------------------------------------------------------------
Cluster state changed to ACTIVE.
Command [SET-STATE] finished with code: 0
Control utility has completed execution at: 2023-10-05T05:50:45.445
Execution time: 579 ms
## 클러스터 상태 확인
$ docker exec ignite bash -c 'yes | /opt/ignite/apache-ignite/bin/control.sh --state'
Control utility [ver. 2.15.0#20230425-sha1:f98f7f35]
2023 Copyright(C) Apache Software Foundation
User: root
Time: 2023-10-05T05:51:54.598
Command [STATE] started
Arguments: --state
--------------------------------------------------------------------------------
Cluster ID: e6f53c11-62a4-4fec-8259-ae2a43ce29d5
Cluster tag: busy_burnell
--------------------------------------------------------------------------------
Cluster is active
Command [STATE] finished with code: 0
Control utility has completed execution at: 2023-10-05T05:51:54.902
Execution time: 304 ms
이제, 간단한 기능테스트를 해볼 수 있는 환경을 구성하였습니다.
How to use?
JAVA thin client로 캐시로 사용하는 방법과, Ignite JDBC를 통해 SQL데이터를 처리할 수 있는 방안 두 가지를 간단하게 살펴보겠습니다. maven 기준 하단 의존성이 필요합니다.
단순하게 캐시를 하나 만들고, put/get/count 정도를 해주는 로직입니다. 하단은 단순한 데이터 처리처럼 보이지만, 실제 운영 환경에서 초당 수만건 처리도 별다른 CPU 리소스 사용 없이도 너끈히 가능합니다. 개인적인 선호도에 따라, 오퍼레이션 실패 시 Retry 기능도 적절하게 구현해서 첨가한다면 더욱 강력한 프로그램이 되겠죠? ^^
SQL기반으로 데이터 처리하는 영역은 갈수록 광범위해지고 있습니다. 특히나, JAVA에서는 JDBC라는 강력한 인터페이스를 제공하며, 이를 잘 구현해놓으면 다양한 데이터처리를 SQL로 쉽게 접근하여 처리 가능합니다. Ignite에서도 JDBC 드라이버를 제공하고, 이를 기반으로 SQL로 데이터 질의가 가능합니다.
구현 자체는 기존 SQL 서버들과 붙는 것과 크게 다르지 않습니다. 단지, UPSERT 구문 및 각 데이터베이스별로 제공하는 일부 특이한 쿼리 패턴을 제외하고는.. ^^
import java.sql.*;
public class IgniteJDBCTest {
public static void main(String[] args) throws ClassNotFoundException, SQLException {
Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1:10800");
Statement stmt = conn.createStatement();
stmt.execute("create table if not exists person (\n"
+ " name varchar, \n"
+ " details varchar, \n"
+ " primary key(name)\n"
+ ") with \"backups=1\"");
stmt.execute("MERGE INTO person (name, details) VALUES ('key1', 'abcde1')");
stmt.execute("MERGE INTO person (name, details) VALUES ('key2', 'abcde2')");
stmt.execute("MERGE INTO person (name, details) VALUES ('key3', 'abcde3')");
stmt.execute("MERGE INTO person (name, details) VALUES ('key4', 'abcde4')");
{
ResultSet rs = stmt.executeQuery("select * from person");
while (rs.next()) {
System.out.println(rs.getString(1) + "=>" + rs.getString(2));
}
rs.close();
}
{
ResultSet rs = stmt.executeQuery("select count(*) from person");
while (rs.next()) {
System.out.println("Total=>" + rs.getString(1));
}
rs.close();
}
stmt.close();
conn.close();
}
}
오늘 이 포스팅에서는 Apache Ignite에 대한 간단한 기술 맛보기 정도만 소개를 했습니다. 물론, Ignite 혹은 Gridgain(상용버전)을 서비스에서 잘 사용하고 있는 분들도 분명 많을 것입니다. 일부는 Ignite에 대해 효율성을 공감하실 분도 계실 것이고, 일부는 아직은 아리송한 생각을 가지고 계실 수도 있습니다.
앞서 이야기를 했었지만, 저는 개인적으로 Apache Ignite에 대해서 하단 정도를 가장 큰 강점으로 뽑고 싶습니다. 물론 Ignite가 인메모리데이터이고, 다양한 기능을 제공해주기는 하지만, (개인적인 생각으로는) 결과적으로는 캐시서버일 분, 그 이상의 의미를 부여할 필요는 없다고 봅니다.
Persistence Mode
SQL(JDBC) 지원
분산 캐시
스케일 인/아웃
다음 포스팅에서는 위에서 소개를 했던 두가지 내용에 이어서, 분산 캐시 구성 방법에 추가로 모니터링 구성 방안을 이야기해보도록 하겠습니다. 아, 추가로, Thin Client 와 JDBC의 두 가지 퍼포먼스를 간단하게 로컬에서 테스트를 해서 공유를 하는 것도 좋겠네요.
MySQL을 쓰시는 분들, 아니 RDBMS를 써오시던 분들의 가장 가려운 부분은 개인적으로 통계 쿼리 수행 속도라고 봅니다. 특히나 데이터 사이즈가 하루가 다르게 폭발적으로 증가해가는 상황에서 너무나도 반가운 소식이라고 봅니다. HTAP(Hybrid transactional/analytical processing) 구현이라 하는데..
오늘 이 포스팅에서는 서비스 활용 관점으로 Heatwave를 이야기해보도록 하겠습니다.
MySQL Heatwave는?
Oracle Cloud에서 제공하는 OLAP 분산 클러스터로, MySQL의 InnoDB데이터를 자동으로 Heatwave 클러스터로 동기화하여, 제공하는 스토리지 엔진 플러그인입니다.
그림을 보면. 결국 HeatWave는 HeatWave Cluster와 HeatWave storage engine 두 가지로 분류해볼 수 있겠네요. 마치. MySQL ndb cluster와 같이. 🙂
HeatWave storage engine
스토리지 엔진(SECONDARY 엔진)으로, MySQL서버와 HeatWave Cluster간 데이터의 통신 역할
사용자의 쿼리가 실행되는 이것을 Heatwave쪽으로 Query pushdown 하여 쿼리를 실행
HeatWave Cluster
데이터를 저장 및 프로세싱하는 분산 노드의 집합.
Oracle cloud 내부에 구성된 HeatWave Storage 레이어에 데이터에 저장.
InnoDB 데이터와 다른 저장소에 저장이 됨.
MySQL을 통해 들어온 쿼리를 HeatWave Storage 엔진을 통해 HeatWave Cluster에 Query pushdown하여 전달하여 분산 컴퓨팅을 한 후 쿼리 결과를 사용자에게 다시 제공을 해주는?? 기본적으로 모든 데이터 변경은 InnoDB Only라는 측면에서는 다른듯 하네요. 구조상으로는 ndb cluster와 유사한것 같은데.. 트랜잭션 상으로는 미묘하게 다른 느낌이 오네요.
MySQL InnoDB 스토리지 엔진과 직접적으로 연계하여 데이터를 처리해볼 수 있는 분석 용도의 분산 Column-Oriented Database 이라고 봐도 무관해보이네요.
Using HeatWave
거창하게 별도의 테이블을 만들어서 진행한다기 보다는.. 아래와 같이 ALTER 구문을 통해서 설정을 해볼 수 있다 하네요.
## 64KB 넘는 컬럼 제외
mysql> ALTER TABLE orders MODIFY description BLOB NOT SECONDARY;
## SECONDARY_ENGINE 엔진 지정
mysql> ALTER TABLE orders SECONDARY_ENGINE = RAPID;
## 데이터 복사(InnoDB->Heatwave)
mysql> ALTER TABLE orders SECONDARY_LOAD;
이 일련의 과정을 거치면, 이후부터는 서비스에서 사용하는 InnoDB변경 내역이 백그라운드에서 자연스럽게 Heatwave 데이터노드로 동기화 될 것이고, 이 내용을 기반으로 바로 OLAP쿼리를 수행해볼 수 있습니다. 만약 Heatwave에서 지원하는 쿼리만 사용한다고 했을 시에.. 사용자는 분석을 위해 별도의 데이터소스를 통하지 않고도, MySQL 데이터 소스 하나만으로도 원하는 결과를 깔끔(?)하게 도출해볼 수 있겠습니다.
## secondary 사용할래~ (Heatwave 사용할래)
SET SESSION use_secondary_engine=ON;
## secondary 사용할래~ (InnoDB에서 데이터 처리할래)
SET SESSION use_secondary_engine=OFF;
HeatWave에서 데이터를 제거하고 싶으면, 아래와 같이 SECONDARY_UNLOAD를 실행하면 됩니다.
깔끔하게 테이블도 그냥 InnoDB로만 변경하고자 한다면, 아래와 같이 SECONDARY_ENGINE을 NULL로 지정해야 합니다. 만약 Truncate 혹은 DDL작업이 필요하다면. 반드시 SECONDARY_ENGINE을 NULL로 변경해야 작업 수행할 수 있습니다.
## HeatWave Cluster에서 데이터 제거
mysql> ALTER TABLE orders SECONDARY_UNLOAD;
## SECONDARY_ENGINE 사용 비활성화
mysql> ALTER TABLE orders SECONDARY_ENGINE = NULL;
Workload Optimization
Heatwave에서는 데이터를 저장하는 방식(Encoding)과 인덱싱(Placement Key)을 하는 두가지 방법으로 워크로드에 맞는 설정을 해볼 수 있습니다. 기본적으로 모든 옵션은 각 칼럼들의 COMMENT내용을 활용하고 있으며. 대소문자를 구분하기에, 반드시 모두 대문자로 명시를 해야한다고 하네요. ex) COMMENT 'RAPID_COLUMN=ENCODING=VARLEN'
1. Encoding
Variable-length Encoding, Dictionary encoding 두가지 타입을 제공하며. 각각 다른 특성을 가집니다.
1.1. Variable-length Encoding
기본 인코딩 타입으로, NULL을 허용하며, 문자열 컬럼 저장에 효율적이라고 합니다.
MySQL에서 제공해주는 캐릭터셋을 지원하며, 무엇보다 데이터 처리 시 MySQL의 메모리가 크게 필요치 않기 때문에 자원 활용이 좋다고 하네요. Group by, Join, Limit, Order by 등을 지원합니다.
ALTER TABLE orders
MODIFY `O_COMMENT` VARCHAR(79) COLLATE utf8mb4_bin NOT NULL
COMMENT 'RAPID_COLUMN=ENCODING=VARLEN';
1.2. Dictionary encoding (SORTED)
데이터 가짓수(Distinct)가 적은 스트링 저장에 효율적이라 합니다.
예를 들면.. 코드와 같은? 메모리 사용을 MySQL 엔진 쪽을 활용하기 때문에. 관련 리소스 소모가 있을 수 있다고 하고.. 특성만 보면. B-map 인덱싱과 왠지 유사한 느낌적인 느낌도.. ^^
Join, Like 등을 비롯한 문자열 연관 오퍼레이션에 제약이 있다고 합니다. 마찬가지로, 컬럼 레벨로 아래와 같이 코멘트에 인코딩 옵션을 넣어서 설정해볼 수 있겠습니다.
ALTER TABLE orders
MODIFY `O_COMMENT` VARCHAR(79) COLLATE utf8mb4_bin NOT NULL
COMMENT 'RAPID_COLUMN=ENCODING=SORTED';
2. Data Placement Keys
기본적으로 PK 기반으로 데이터가 분산되어 관리되지만.. 성능 또는 기타 목적을 위해 별도로 생성하는 키라고 되어있고. 마치 여러개의 Clustering Key를 설정하는 듯한 개념으로 보이네요. Variable-length 인코딩만 지원합니다.테이블당 1~16까지 지정할 수 있으며. 하나의 숫자는 하나의 컬럼에만 할당 가능합니다. (복합 인덱싱 불가!)
ALTER TABLE orders
MODIFY date DATE COMMENT 'RAPID_COLUMN=DATA_PLACEMENT_KEY=1',
MODIFY price FLOAT COMMENT 'RAPID_COLUMN=DATA_PLACEMENT_KEY=2';
지금까지 나름 메뉴얼 기반으로 HeatWave에 대해서 퀵하게 훑어보았습니다. 그러나, 역시 직접 해보는 것이 특성을 알아볼 수 있는 제대로된 접근이기에. 개인적으로 의문나는 부분 위주로 몇가지 테스트해보았습니다.
Setup HeatWave
앞에서 이야기를 한 것처럼, HeatWave는 Oracle Cloud에서만 사용할 수 있습니다. 테스트를 위해, 일단 가입을 하고 무료 테스트 코인을 받아서 아래와 같이 HeatWave 용도의 데이터베이스를 생성해봅니다.
생성을 완료했을지라도, 정작 해당 스토리지 엔진이 존재하지 않는데. 아직 HeatWave 클러스터를 생성하지 않았기 때문이죠.
mysql> show engines;
+--------------------+---------+--------------+------+------------+
| Engine | Support | Transactions | XA | Savepoints |
+--------------------+---------+--------------+------+------------+
| FEDERATED | NO | NULL | NULL | NULL |
| MEMORY | YES | NO | NO | NO |
| InnoDB | DEFAULT | YES | YES | YES |
| PERFORMANCE_SCHEMA | YES | NO | NO | NO |
| MyISAM | YES | NO | NO | NO |
| MRG_MYISAM | YES | NO | NO | NO |
| BLACKHOLE | YES | NO | NO | NO |
| CSV | YES | NO | NO | NO |
| ARCHIVE | YES | NO | NO | NO |
+--------------------+---------+--------------+------+------------+
MySQL 인스턴스를 누르고, Heatwave 클러스터 구성을 하면. (위 위치에 메뉴가 있음) 클러스터 생성으로 변경이 되면서. 한참을 기다리다보면. HeatWave State:Active 상태로 변경됩니다.
MySQL에 접속을 해서 엔진을 확인해보면, 아래와 같이 RAPID 엔진이 정상적으로 올라와 있네요.
mysql> show engines;
+--------------------+---------+--------------+------+------------+
| Engine | Support | Transactions | XA | Savepoints |
+--------------------+---------+--------------+------+------------+
| FEDERATED | NO | NULL | NULL | NULL |
| MEMORY | YES | NO | NO | NO |
| InnoDB | DEFAULT | YES | YES | YES |
| PERFORMANCE_SCHEMA | YES | NO | NO | NO |
| RAPID | YES | NO | NO | NO | <<== 올라옴
| MyISAM | YES | NO | NO | NO |
| MRG_MYISAM | YES | NO | NO | NO |
| BLACKHOLE | YES | NO | NO | NO |
| CSV | YES | NO | NO | NO |
| ARCHIVE | YES | NO | NO | NO |
+--------------------+---------+--------------+------+------------+
Loading Test Data
Oracle 메뉴얼에 Airport 샘플 데이터를 공개해놓았기 때문에. 이것을 적극 활용해봐야겠죠? 큰 테이블 만들기도 참 귀찮았는대.. 아. 일단. 이 전에. MySQL에 붙기 위한.. Compution instance를 하나 생성부터 해야겠군요. 이 부분은 스킵!
MySQL클라이언트를 설치하고, 추가로 데이터 로딩에서 mysql shell을 쓰기에 같이 설치!
실행계획을 보면, 별다른 옵션없이 옵티마이저가 이 쿼리를 RAPID엔진을 사용하는 것으로 Extra부분에서 정보를 확인해볼 수 있겠습니다. 그런데 실제 가격별 카운팅 결과는 0.09초에 마무리가 되는.. 굉장히 좋은 성능을 보여주네요.
mysql> SET SESSION use_secondary_engine=ON;
mysql> explain
-> SELECT booking.price, count(*)
-> FROM booking WHERE booking.price > 500
-> GROUP BY booking.price
-> ORDER BY booking.price LIMIT 10;
+----+----------+----------+--------------------------------------+
| id | rows | filtered | Extra |
+----+----------+----------+--------------------------------------+
| 1 | 54202876 | 33.33 | Using ..Using secondary engine RAPID |
+----+----------+----------+--------------------------------------+
mysql> SELECT booking.price, count(*)
-> FROM booking WHERE booking.price > 500
-> GROUP BY booking.price
-> ORDER BY booking.price LIMIT 10;
+--------+----------+
| price | count(*) |
+--------+----------+
| 500.01 | 860 |
| 500.02 | 1207 |
| 500.03 | 1135 |
| 500.04 | 1010 |
| 500.05 | 1016 |
| 500.06 | 1039 |
| 500.07 | 1002 |
| 500.08 | 1095 |
| 500.09 | 1117 |
| 500.10 | 1106 |
+--------+----------+
10 rows in set (0.09 sec)
3. Query InnoDB
InnoDB로만 데이터를 처리했을 시 결과입니다. 실행계획을 보면, 앞에서 명시되었던 RAPID 엔진 사용이 사라졌고. 실제 카운팅 쿼리를 수행해보면. 10초 이상.. 무려 1000배의 시간이 더 걸리는 성능을 보이죠. 일단, 이런 효율면에서는 확연하게 성능차가 나오네요.
mysql> SET SESSION use_secondary_engine=OFF;
mysql> explain
-> SELECT booking.price, count(*)
-> FROM booking WHERE booking.price > 500
-> GROUP BY booking.price
-> ORDER BY booking.price LIMIT 10;
+----+----------+----------+--------------------------------------+
| id | rows | filtered | Extra |
+----+----------+----------+--------------------------------------+
| 1 | 54202876 | 33.33 | Using where; Using..; Using filesort |
+----+----------+----------+--------------------------------------+
mysql> SELECT booking.price, count(*)
-> FROM booking WHERE booking.price > 500
-> GROUP BY booking.price
-> ORDER BY booking.price LIMIT 10;
+--------+----------+
| price | count(*) |
+--------+----------+
| 500.01 | 860 |
| 500.02 | 1207 |
| 500.03 | 1135 |
| 500.04 | 1010 |
| 500.05 | 1016 |
| 500.06 | 1039 |
| 500.07 | 1002 |
| 500.08 | 1095 |
| 500.09 | 1117 |
| 500.10 | 1106 |
+--------+----------+
10 rows in set (10.66 sec)
이것 외에도 다른 다양한 쿼리가 몇몇 샘플로 더 공개되어 있지만, 이것은. 스킵하는 것으로..
Operational Test
아무리 엔진이 좋아도, 운영 측면에서 준비가 안되어있다면, 이것은 빛좋은 개살구일뿐입니다. 만약 서비스에서 사용을 한다면, 좋을만한 포인트가 무엇일지 기준으로 추가로 테스트해보았습니다.
1. Online DDL
아쉽게도… Heatwave로, 아니 SECONDARY_ENGINE=RAPID 으로 정의된 테이블에는 ALTER구문이 동작하지 않습니다. 만약, 테이블 구조 변경이 필요하다면. SECONDARY_ENGINE속성을 없앤 후에 ALTER를 수행해야합니다,
mysql> alter table heatwave_test add c10 varchar(10);
ERROR 3890 (HY000): DDLs on a table with a secondary engine defined are not allowed.
mysql> truncate table heatwave_test;
ERROR 3890 (HY000): DDLs on a table with a secondary engine defined are not allowed.
mysql> alter table partition_test secondary_engine = null;
mysql> truncate table heatwave_test;
Query OK, 0 rows affected (0.01 sec)
테이블 칼럼 추가 삭제 시에는 이런 부담을 안고 가야하기에. DDL이 절대 변하지 않을만한 상황에서 활용을 하는 것이 좋을 듯 하네요.
2. Partitioning
앞선 이야기에서처럼. SECONDARY_ENGINE=RAPID 으로 정의된 테이블에는 ALTER구문이 동작하지 않습니다. 이것은 파티셔닝 추가/삭제에 대해서도 마찬가지입니다.
사실 테이블에서는 디비에 부담없이 오래된 데이터를 정리하는 목적으로 파티셔닝을 많이 활용하기 때문에.. 아쉬운점이 많네요. 특히나. 이 테이블은 아무래도 분석 관련된 쿼리가 많이 활용될 것이라, 데이터도 많아지게 될 것이고. 아주 오래된 데이터를 효율적으로 제거하는 방안도 있어야할텐데..
무엇보다, 파티셔닝 테이블로 로딩을 했을지라도. RAPID 내부적으로는 의미가 없기도 하고요. 사실. Heatwave쪽에 별도의 데이터가 존재하기에. 당연한 결과이기는 합니다만..
mysql> SET SESSION use_secondary_engine=OFF;
+----+---------------------------------+---------+-------------+
| id | partitions | rows | Extra |
+----+---------------------------------+---------+-------------+
| 1 | p2017,p2018,p2019,p2020,p999999 | 9533500 | Using where |
+----+---------------------------------+---------+-------------+
mysql> SET SESSION use_secondary_engine=ON;
+----+------------+---------+---------------------------------------+
| id | partitions | rows | Extra |
+----+------------+---------+---------------------------------------+
| 1 | NULL | 9533500 | Using .. Using secondary engine RAPID |
+----+------------+---------+---------------------------------------+
파티셔닝이 안되는 것은 아니지만, 우선 파티셔닝을 했을지라도 파티셔닝 구조변경을 위해서는 HeatWave재구성을 해야한다는 측면에서는 매리트가 없습니다. 이럴꺼면 그냥 테이블 단위 파티셔닝을 개발 레벨에서 구현을 해서 사용하는 것이 훨씬 유리해보이네요.
그냥 파티셔닝은 비효율적이다라는 정도로 정리!
Performance TEST
사실 Cloud에서 동작을 하는 것이라. 성능적으로 기하 급수적으로 변화시킬만한 파라메터가 없는 것은 사실입니다. 그러나, 적어도 Heatwave 테이블과 InnoDB로만 구성된 테이블간의 성능차이는 확인해봐야겠죠?
mysql> create database bmt;
mysql> use bmt;
mysql> create table tb_innodb_only(
-> i int not null primary key auto_increment,
-> c1 varchar(100) not null,
-> c2 varchar(100) not null,
-> c3 varchar(100) not null,
-> c4 varchar(100) not null,
-> c5 varchar(100) not null,
-> c6 varchar(100) not null,
-> c7 varchar(100) not null,
-> ts timestamp
-> );
mysql> create table tb_innodb_rapid(
-> i int not null primary key auto_increment,
-> c1 varchar(100) not null,
-> c2 varchar(100) not null,
-> c3 varchar(100) not null,
-> c4 varchar(100) not null,
-> c5 varchar(100) not null,
-> c6 varchar(100) not null,
-> c7 varchar(100) not null,
-> ts timestamp
-> );
mysql> alter table tb_innodb_rapid secondary_engine=rapid;
mysql> alter table tb_innodb_rapid secondary_load;
1. InnoDB VS HeatWave
InnoDB와 HeatWave 양쪽으로 두 벌의 데이터가 존재하기 때문에. SELECT와 같이 둘중 하나 담당하는 쿼리 테스트는 의미없을 듯 하고. 양쪽 모두 영향을 미치는 데이터 변경으로 테스트를 해보겠습니다. 테스트 트래픽은 쉽게쉽게 mysqlslap 유틸을 활용하여 생성해보도록 하겠습니다.
1.1 InnoDB performance
10건 데이터를 100개 프로세스가 나눠서 넣는 것으로. 총 10번 수행합니다.
mysqlslap \
-u chan -p -h 10.0.0.143 \
--concurrency=100 \
--iterations=10 \
--number-of-queries=100000 \
--create-schema=bmt \
--no-drop \
--query="insert into tb_innodb_only values (null, uuid(), uuid(), uuid(), uuid(), uuid(), uuid(), uuid(),now());"
Benchmark
Average number of seconds to run all queries: 20.136 seconds
Minimum number of seconds to run all queries: 18.896 seconds
Maximum number of seconds to run all queries: 20.851 seconds
Number of clients running queries: 100
Average number of queries per client: 1000
이번에는 동일한 트래픽을 Heatwave로 구성된 테이블에 줘보도록 하겠습니다. 마찬가지로, 10건 데이터를 100개 프로세스가 나눠서 넣습니다.
mysqlslap \
-u chan -p -h 10.0.0.143 \
--concurrency=100 \
--iterations=10 \
--number-of-queries=100000 \
--create-schema=bmt \
--no-drop \
--query="insert into tb_innodb_rapid values (null, uuid(), uuid(), uuid(), uuid(), uuid(), uuid(), uuid(),now());"
Benchmark
Average number of seconds to run all queries: 20.271 seconds
Minimum number of seconds to run all queries: 19.184 seconds
Maximum number of seconds to run all queries: 21.355 seconds
Number of clients running queries: 100
Average number of queries per client: 1000
유입 쿼리량을 보니.. 대략 초당 6,000 정도 쿼리를 처리하네요. 차이가 거의 없다고 해야하나.. -_-;
서비스에서 많이 사용하는 쿼리 중 제일 컨트롤이 어려운 부분은 사실 페이징입니다. 데이터가 폭발적으로 증가할수록 언제나 늘 고민을 해야하는 것도. 바로 게시판 타입의 서비스이기도 하죠. 물론 오프셋 기반의 페이징(특정 ID값 이전의 10건씩 가져오는 방식)은 소셜 서비스의 방대한 데이터를 처리하기 위해 많이들 사용하는 추세이기는 합니다만.. 모든 요구사항을 이런식으로 구현하기에도 명백히 한계가 있습니다.
그런데. Heatwave를 태우게 되면. 단순 카운팅 뿐만 아니라. 아래와 같이 별도의 검색조건을 추가로 준다고 할지라도. 큰 무리없이 데이터 카운팅 결과를 가져옵니다. (0.05초 VS 10.84초)
#####################################
# Heatwave
#####################################
mysql> SET SESSION use_secondary_engine=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT count(*)
-> FROM booking
-> WHERE booking.price > 500
-> AND seat like '24%';
+----------+
| count(*) |
+----------+
| 1407 |
+----------+
1 row in set (0.05 sec)
#####################################
# Without heatwave
#####################################
mysql> SET SESSION use_secondary_engine=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT count(*)
-> FROM booking
-> WHERE booking.price > 500
-> AND seat like '24%';
+----------+
| count(*) |
+----------+
| 1407 |
+----------+
1 row in set (10.84 sec)
의외로. 제 개인적으로는 워드프레스와 상당히 궁합이 맞을 수 있겠다는 생각이…?? 새로운 발견!!
Conclusion
지금까지 몇가지를 추가로 살펴본 HeatWave는.. 이렇게 정리를 해보고싶네요.
Oracle Cloud에서만 사용 가능
InnoDB 데이터와 별개의 분산 스토리지에 저장된다. (InnoDB first)
Online DDL은 불가하고. DDL시에도 secondary_engine을 비활성 필요
InnoDB는 파티셔닝 구성해도, HeatWave는 내부적으로 파티셔닝 구성 안되어 있음. 파티셔닝의 관리 역시 순탄치 않음
InnoDB와 성능 차이(INSERT)가 없음.
게시판 카운팅 쿼리에 나름 적합(?)
무엇보다 Oracle cloud에서만 사용할 수 있다는 점이 아쉽기는 하지만.
OnPremise로 가능할지라도. Heatwave 클러스터 구축 및 관리가 필요할 것이니. 이것이 꼭 단점으로만 부각할만한 것은 아니라고 봅니다. 그리고. Oracle cloud에서는 의외로.. MySQL binlog가 활성화되어있고, Replication 계정을 추가할 수 있기에.. 데이터 핸들링 측면에서는 꽤나 좋은 환경이라는 생각도 문득 드네요. ㅎㅎ (DBaaS인데 이 점은 정말 매력적인 포인트입니다. 데이터의 흐름을 가두지 않는 것. 아 근데 나중에 막힐라나?? -_-;;)
