ETS 모델 기반 시계열 예측

GraalVM 소개

로그프레소 빅데이터 플랫폼은 복잡한 사용자 분석 기능 확장을 지원하기 위하여 2014년 이래 그루비, 자바스크립트 엔진을 내장하여 지원하고 있습니다. 지금까지는 자바스크립트를 구동하는데 Nashorn 엔진을 사용했는데요. 자바 11이 출시되면서 Nashorn은 제거 예정 상태로 변경되었고 GraalVM으로 대체를 권고하고 있습니다. 이번 글에서는 GraalVM에 대한 전반적인 개요를 소개합니다. ## GraalVM 개발 배경 GraalVM은 2005년에 썬 마이크로시스템즈에서 Maxine 가상머신 프로젝트로 시작되었습니다. 자바 가상머신(JVM)은 C++ 언어로 구현되어 있는데, 이 프로젝트의 목표는 자바 가상머신 전체를 자바 언어로 다시 작성하는 것이었습니다. 그러나 모든 코드를 한 번에 다 갈아엎는다는 것이 현실적으로 매우 달성하기 어렵기 때문에, 기존 핫스팟 런타임을 최대한 재사용하면서 플러그인으로 JIT 컴파일러를 끼워넣는 방향으로 선회하여 오늘에 이르렀습니다. ## GraalVM 구성  GraalVM JIT 컴파일러는 자바 9 버전에 추가된 JVMCI (JVM 컴파일러 인터페이스)를 이용하여 기존 핫스팟 런타임에 플러그인 되는 구조로 동작합니다. 자바나 스칼라 같은 JVM 기반 언어는 GraalVM JIT 컴파일러의 최적화를 통해 성능 향상을 기대할 수 있습니다. 그 위에 Truffle 프레임워크가 올라가는데, 이는 자바스크립트, R, 파이썬, 루비 등 JVM 기반이 아닌 기존 언어의 새로운 구현을 지원합니다. ## GraalVM 활용 분야 * 기존 자바 응용 프로그램의 성능 향상 * 트위터의 경우 GraalVM을 적용해서 기존 Scala 코드에 대해 약 20%의 성능 향상 달성 * 다양한 언어 확장 * 자바 코드에서 자바스크립트, R, 파이썬, LLVM IR, 웹 어셈블리 실행 가능 * 각 언어별 라이브러리 활용 가능 (예: R이나 파이썬에서 데이터 분석 후 자바스크립트로 출력) * 고성능이 필요한 모듈을 C/C++로 구현 * 호스트 접근 필터링 기능으로 스크립트 실행 시 보안성 향상 * 네이티브 이미지 생성 * AOT 컴파일을 통해 부팅 시간 단축, 이미지 크기 최소화 * 특히 최근의 컨테이너 기반 마이크로서비스 아키텍처에 활용성 높음 * 기존 언어의 대량 메모리 사용 지원 * 자바 가상머신은 수십 년간 GC를 개선하여 테라바이트 단위의 힙 메모리까지 지원 가능 * GraalVM 기반으로 구현된 기존 언어는 대량 메모리 사용 시나리오도 지원할 수 있음 ## GraalVM 구동 방법 OpenJDK 11 버전 이상을 사용하고 있다면 아래와 같이 부팅 스위치를 추가하여 GraalVM JIT을 활성화 할 수 있습니다. 아래 구성은 Graal JIT만 사용하는 최소 구성입니다: ``` -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI --module-path=graalvm --upgrade-module-path=graalvm/compiler.jar ``` 아래 3개의 파일이 graalvm 위치에 있어야 합니다. (20.0.0 버전 기준으로 약 21MB) * [compiler.jar](https://repo1.maven.org/maven2/org/graalvm/compiler/compiler/20.0.0/compiler-20.0.0.jar) * [graal-sdk.jar](https://repo1.maven.org/maven2/org/graalvm/sdk/graal-sdk/20.0.0/graal-sdk-20.0.0.jar) * [truffle-api.jar](https://repo1.maven.org/maven2/org/graalvm/truffle/truffle-api/20.0.0/truffle-api-20.0.0.jar) 시스템 프로퍼티에 아래 속성들이 추가되면 정상적으로 GraalVM이 핫스팟 런타임에 플러그인 된 것입니다. ``` jdk.internal.vm.ci.enabled=true jdk.module.path=graalvm jdk.module.upgrade.path=graalvm/compiler.jar ``` 다음 글에서는 자바스크립트, 파이썬 코드를 실제 구동하는 방법에 대해 알아보겠습니다. ### 레퍼런스 * [Maxine Virtual Machine](https://en.wikipedia.org/wiki/Maxine_Virtual_Machine) * [Running GraalJS on stock JDK11](https://github.com/graalvm/graal-js-jdk11-maven-demo) * [Understanding How Graal Works - a Java JIT Compiler Written in Java](https://chrisseaton.com/truffleruby/jokerconf17/)

2020-05-10

쿼리는 어떤 과정을 거쳐서 실행되는가

쿼리는 사용자와 데이터베이스를 매개하는 역할을 수행합니다. 응용프로그램을 개발할 때 파일 입출력을 직접 다루는 대신 데이터베이스를 사용하는 이유는 의도하는 데이터 처리 결과를 간단하게 얻을 수 있기 때문인데요. 쿼리를 사용하면 프로그램 코드를 작성하는 것에 비해 같은 작업을 훨씬 짧게 표현할 수 있습니다. 예를 들어 웹 로그에서 클라이언트 IP별 다운로드 트래픽 총량을 계산하려면 아래와 같은 과정을 거쳐야 합니다. 웹 로그는 아래와 같은 형식으로 기록됩니다. ``` 110.70.47.162 - - [23/May/2020:13:24:22 +0900] "GET /static/images/favicon.png HTTP/1.1" 200 57692 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/81.0.4044.124 Mobile/15E148 Safari/604.1" 849 ``` 1. 웹 로그 파일을 연다. 2. IP와 정수로 구성된 해시테이블을 초기화한다. 3. 웹 로그 파일을 개행 문자로 분리해서 행 단위로 읽어들인다. 1. 웹 로그에서 클라이언트 IP와 전송량에 해당되는 문자열을 추출한다. 2. 전송량 문자열을 정수로 변환한다. 3. 해시테이블에서 클라이언트 IP를 조회한다. 4. 기존 누적값과 현재 전송량을 합산하여 클라이언트 IP와 전송량의 쌍을 다시 해시테이블에 넣는다. 4. 파일 끝을 만나면 해시테이블의 모든 클라이언트 IP 키를 순회하면서 결과를 출력한다. 5. 웹 로그 파일을 닫는다. 프로그래밍 언어에 따라 다르지만 파이썬으로는 몇 줄, 자바로는 수십 줄 정도 구현이 필요할 것이고, 클라이언트 IP가 엄청나게 많아서 메모리에 다 올릴 수 없는 상황은 고려하지 않고 있습니다. 만약 일반적인 데이터베이스 테이블에 웹 로그가 파싱되어 저장되어 있는 상태라면 일반적으로 SQL을 이용해서 간단하게 1줄로 쿼리할 수 있습니다. ``` SELECT client_ip, SUM(bytes) FROM weblog GROUP BY client_ip ``` weblog 테이블에 데이터가 정규화된 형태로 존재한다면 로그프레소 쿼리는 아래와 같이 표현합니다. ``` table weblog | stats sum(bytes) by client_ip ``` 일반 데이터베이스는 테이블에 적재되지 않은 데이터를 처리하지 못하지만, 로그프레소는 아래와 같이 추출과 형 변환을 포함하여 모든 데이터 처리를 한 줄로 표현할 수 있습니다. ``` textfile access_log | rex field=line "^(?<client_ip>\S+).* (?<bytes>\S+)$" | eval bytes=long(bytes) | stats sum(bytes) by client_ip ``` ## 쿼리 실행 단계 데이터베이스는 위와 같이 기술한 쿼리 문장을 실제 실행 가능한 코드로 변환해야 합니다. 이 과정은 크게 쿼리 파싱, 최적화, 실행으로 구분합니다. ### 쿼리 파싱  쿼리는 한 줄로 간단하게 표현하였지만 프로그램 코드를 직접 작성한 것과 동일하게 동작하려면 각 기능 단위가 사용자의 의도에 맞게 배치되어야 합니다. 데이터베이스는 이러한 기능 단위를 쿼리 연산자 (Query Operator) 라고 부릅니다. 각 쿼리 연산자는 레코드를 입력 받아서 고유의 데이터 처리를 수행한 후 출력하며, 다음 연산자는 이전 연산자의 출력을 입력으로 받아들입니다. 위의 그림에서 실행 흐름은 아래에서 위로 올라가는 방향으로 표현되어 있는데 이것이 약간 부자연스럽게 느껴질 수 있습니다. 하지만 조인 연산이 포함되는 경우에 하단이 늘어나면서 넓게 배치되고 결과는 하나로 모이게 되므로 트리 형태로 표현하는 것이 유리하고, 그에 맞춰서 실행 흐름은 아래에서 위로 표시하는 것입니다. ### 최적화 데이터베이스는 쿼리를 파싱하여 트리 형태로 만들고 난 후에 이를 논리적, 물리적으로 최적화하는 과정을 수행합니다. 예를 들어, 위의 경우에 집계를 수행하므로 테이블 혹은 파일의 레코드 순서는 중요하지 않습니다. 따라서 병렬화된 테이블 스캔 혹은 파일 스캔으로 변환할 수 있습니다. 이 외에도 타입 추론, 비용 계산, 조인 순서, 필터링 위치 결정은 쿼리 최적화에서 중요한 주제인데 이는 나중에 다시 다루도록 하겠습니다.  ### 실행 최적화를 거치고 나면 최종적으로 쿼리 실행 계획 (Query Plan) 이 완성됩니다. 데이터베이스는 이 쿼리를 실행하는데 어느 정도의 CPU, 메모리, 디스크 자원을 사용할지 결정해야 합니다. 가장 단순하게는 프로그램을 직접 구현해서 실행하듯이 단일 프로세스가 쿼리를 실행할 수 있습니다. **프로세스 모델** PostgreSQL처럼 역사가 오래된 데이터베이스는 프로세스 모델 기반으로 동작합니다.  프로세스 모델은 클라이언트가 접속하면 새로운 프로세스를 생성해서 할당합니다. 유닉스 프로그래밍 스타일의 오랜 전통이기도 하지만, 공유 메모리를 기반으로 프로세스를 분리하는 이런 실행 모델은 프로그램 오류로 크래시가 발생하더라도 해당 프로세스만 영향을 받기 때문에 상대적으로 장애에 견고합니다. 프로세스가 재시작하더라도 디스크에서 다시 읽어들일 필요 없이 공유 메모리 영역이 그대로 유지되는 장점도 있습니다. IBM DB2, Oracle (11g 이하 버전) 데이터베이스는 이러한 아키텍처로 설계되어 있습니다. 그러나 프로세스를 fork 하는 방식은 상당히 무거운 편입니다. 프로세스 풀링을 통해 어느 정도 단점을 희석시키기는 하지만, 운영체제에 실행을 맡기므로 스케줄링을 세밀하게 관리하기 어렵고 CPU 캐시 활용도 비효율적입니다. **스레드 모델** 로그프레소 쿼리 엔진은 스레드 모델 기반으로 동작합니다.  로그프레소는 쿼리마다 하나의 쿼리 스케줄러 스레드를 실행합니다. 쿼리 스케줄러는 쿼리 실행 계획에서 의존성이 해소된 실행 가능한 태스크를 선별하여 쿼리 태스크를 병렬적으로 실행합니다. 스캔이나 정렬과 같이 실행 성능에 큰 영향을 미치는 요소는 별도의 스레드 풀이 할당되어 있어서, CPU를 최대한 활용하여 빅데이터 쿼리를 실행합니다. 로그프레소 쿼리 엔진은 푸시 모델로 구성되어 있기 때문에, 스캔 스레드의 병렬화가 전체 쿼리의 수행 성능을 좌우합니다. 메모리에 캐시된 페이지를 처리하는 경우 이러한 병렬화는 수 배 이상의 성능 차이를 낼 수 있습니다. 다음 편에서는 Pull 모델과 Push 모델의 장단점을 알아보도록 하겠습니다. ## 레퍼런스 - [PostgreSQL 12 Documentation: 1.2. Architectural Fundamentals](https://www.postgresql.org/docs/12/tutorial-arch.html) - [Oracle 18c Database Concepts: 15 Process Architecture](https://docs.oracle.com/en/database/oracle/oracle-database/18/cncpt/process-architecture.html#GUID-4B460E97-18A0-4F5A-A62F-9608FFD43664)

2020-05-25

10배 빠르게 통계 처리하기

자바로 개발된 많은 엔터프라이즈 응용프로그램들은 일반적으로 데이터베이스에 의존하여 데이터를 처리하지만, 처리해야 할 데이터가 너무 크거나 실시간 집계가 필요한 경우 자바로 직접 개발하여 통계를 내기도 합니다. 현재는 데스크탑에서도 4개 이상의 멀티코어를 사용하기 때문에, 서버에서는 수십 개의 스레드가 데이터를 처리하여 집계하는 경우를 흔하게 볼 수 있습니다. 중급 이상의 개발자라면 프로세서가 지원하는 CAS (Compare-And-Swap) 인스트럭션을 기반으로 한 AtomicInteger나 AtomicLong 클래스를 이용하여 병렬 집계 처리를 하겠지만, 자바 8은 멀티코어 환경에서 성능이 더 나은 옵션을 제공합니다. 바로 LongAdder 클래스입니다. **AtomicLong 테스트 코드** ```java import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicLong; public class Benchmark { private AtomicLong counter = new AtomicLong(0); public class Counter implements Runnable { @Override public void run() { for (int i = 0; i < 10000000; i++) counter.incrementAndGet(); } } public void run() throws InterruptedException { int cores = Runtime.getRuntime().availableProcessors(); ExecutorService pool = Executors.newFixedThreadPool(cores); long begin = System.currentTimeMillis(); for (int i = 0; i < cores; i++) pool.submit(new Counter()); pool.shutdown(); pool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); long end = System.currentTimeMillis(); System.out.println(counter.get()); System.out.println((end - begin) + "ms"); } public static void main(String[] args) throws Exception { new Benchmark().run(); } } ``` **LongAdder 테스트 코드** ```java import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.LongAdder; public class Benchmark { private LongAdder counter = new LongAdder(); public class Counter implements Runnable { @Override public void run() { for (int i = 0; i < 10000000; i++) counter.increment(); } } public void run() throws InterruptedException { int cores = Runtime.getRuntime().availableProcessors(); ExecutorService pool = Executors.newFixedThreadPool(cores); long begin = System.currentTimeMillis(); for (int i = 0; i < cores; i++) pool.submit(new Counter()); pool.shutdown(); pool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); long end = System.currentTimeMillis(); System.out.println(counter.sum()); System.out.println((end - begin) + "ms"); } public static void main(String[] args) throws Exception { new Benchmark().run(); } } ``` **측정 결과 #1** - 인텔 코어 i7-4770 3.4GHz, 4 코어, 8 스레드 - AtomicLong: 1546ms, 1542ms, 1534ms - LongAdder: 155ms, 141ms, 143ms **측정 결과 #2** - 인텔 제온 E5-2687W v3 3.1GHz, 20 코어, 40 스레드 - AtomicLong: 6701ms, 7126ms, 6880ms - LongAdder: 351ms, 349ms, 332ms ### 성능 차이의 원인 멀티스레드 응용에서 AtomicLong을 이용해서 집계를 수행하는 경우, 모든 코어의 CPU 사용율이 100%에 근접하기 때문에 최대 속도로 동작하고 있다고 단순하게 생각하기 쉽습니다. 실제로는 같은 메모리 변수에 대해 다수의 코어가 경합을 벌이게 되면서, 값 변경이 성공하게 될 때까지 무한히 재시도 하는 상태가 됩니다. 스레드 수가 많을수록 더 극심한 경합이 발생하고 성능이 더 떨어집니다. LongAdder는 여러 개의 카운터로 구성된 배열을 이용해서 코어 간 경합이 발생할 확률을 떨어뜨립니다. 마지막에 각 카운터를 합산하여 최종 결과를 계산하는 방식으로, 집계를 수행할 때는 경합을 최소화하고 정확한 결과를 얻을 수 있습니다. LongAdder는 멀티스레드 집계 상황에서 성능이 좋은 대신, 메모리를 상대적으로 많이 사용합니다. 아래 코드에서 보이듯이 LongAdder는 경합이 발생하면 2배씩 카운터 배열을 확장합니다. ```java else if (cellsBusy == 0 && casCellsBusy()) { try { if (cells == cs) // Expand table unless stale cells = Arrays.copyOf(cs, n << 1); } finally { cellsBusy = 0; } collide = false; continue; // Retry with expanded table } ``` 집계 카운터가 많은 경우, 이러한 메모리 사용량은 받아들이기 어려울 수 있습니다. 로그프레소는 하드웨어 환경에 따라 적절한 메모리를 사용하면서 백오프(Backoff)를 이용해 경합을 감소시키는 알고리즘을 사용합니다.

2016-12-28