2022년 4월 26일 화요일

Prometheus 와 Grafana 로 시스템과 애플리케이션 모니터링

Prometheus 와 Grafana 로 시스템과 애플리케이션 모니터링

들어 가며

분산 환경에서 많은 시스템의 자원과 애플리케이션의 상태를 모니터링 하는 것은 시스템 운영자에게 중요한 임무입니다. 그러나 분산된 많은 시스템을 모니터링 하는 것은 결코 쉬운 일이 아닙니다. 그래서 지금까지도 기업은 전문 회사가 제공하는 고가의 모니터링 솔루션을 사용하는 경우가 많았습니다. 그러나 몇 년 전 오픈 소스 커뮤니티에서 Prometheus 와 Grafana 프로젝트가 등장하고 모니터링 기능을 좀 더 잘 사용할 수 있는 확장 오픈 소스 들도 지속적으로 발전하면서, 오픈 소스로도 기업 분산 환경의 많은 시스템과 애플리케이션을 모니터링 할 수 있는 길이 열리고 있습니다.

위와 같은 상황에서 필자는 분산 환경의 시스템 자원과 애플리케이션 상태를 모니터링 할 수 있는 기술을 오픈 소스로 구성하는 실험을 이 글에서 공유합니다.

실험 환경 개요

실 분산 시스템을 모니터링 하기 위해서, 우선 실험 환경을 구성해야 합니다. 실험 환경은 또한 실 분산 환경으로 확장될 수 있게 구성해야 합니다.

실험 의도와 가정

필자는 분산 시스템을 모니터링 하기 위해서 아래와 같은 실험 환경을 구성했습니다.

  • 실험에 사용된 VM 은 분산 시스템의 모니터링 대상 시스템에 대응됩니다.
  • 실험은 대상 VM 에 node-exporter 와 process-exporter 를 프로세스로 실행했습니다.
  • 실제 운영 시스템 환경에서 node-exporter 와 process-exporter 는 시스템 서비스로 실행될 것입니다.
  • 실험에서 Prometheus 와 Grafana 의 실행은 Docker 컨테이너 기술을 사용했습니다. 실험 실행 환경에 최소의 자원을 사용하면서 실험 환경을 실 환경과 유사하게 꾸미고, 독자들에게 컨테이너 기술도 소개하려는 의도였습니다.
  • Docker 컨테이너 기술은 이후 OpenShift/kubernetes 플랫폼에 Prometheus 와 Grafana 를 실행하게 확장될 수 있을 것입니다.
  • 실험은 도메인 이름 기반 시스템 아키텍처를 권장하기 위해 dnsmasq 를 이용한 DNS 서비스 기술을 포함했습니다.

실험 환경 구성도

분산 시스템을 모니터링 하기 위한 최소 실험 환경을 로컬 PC 에 다음과 같이 구성했습니다.
enter image description here
위 구성도는 각 요소들이 사용하는 tcp 포트와 접속 정보를 보입니다. 그러므로 위 정보를 잘 숙지하면 이후 설명을 이해하는 데, 도움이 될 것입니다. 각 요소들의 자세한 설명은 이후 내용을 참조해 주십시오.

참고) VM 을 실행하는 로컬 PC 의 hosts 파일에도 VM 도메인 이름을 등록한다는 점 주의해 주십시오.

실험 환경 준비

VM 환경

실제 분산 환경을 준비하기는 어렵습니다. 그러므로 분산 환경으로 확장할 수 있는 최소의 실험 환경을 구성해야 합니다. 최소의 실험 환경은 1 개의 Linux 가상 머신입니다. 이 가상 머신의 OS 는 Red Hat Enterprise Linux 8 의 커뮤니티 버전인 Rocky Linux 를 사용했습니다. Rocky Linux 를 사용한 이유는 필자가 docker 기술을 테스트할 때 사용하는 머신이라 선택됐습니다. 시스템 모니터링에 사용하는 node_explorter 가 동작하는 Linux 환경이면, 어떤 Linux 버전도 특별히 문제되지 않을 것입니다. 요즈음 Linux 들은 설치가 어렵지 않으니, 독자들도 가상 머신에 설치해 테스트할 수 있을 것입니다. 필자가 사용한 Linux 는 다음과 같습니다.

enter image description here
실험을 편하게 하기 위해, 고정 ip 를 사용했습니다. 그리고 이 실험은 도메인 이름 기반 시스템 아키텍처를 사용하므로, 호스트 이름을 monitoring 란 이름으로 지정했습니다. 실험에 사용한 도메인 이름을 다른 이름으로 변경하는 것으로 어렵지 않을 것입니다. CPU 나 메모리는 실험 VM 치고는 큽니다. 그 이유는 다른 실험도 하는 VM 을 이번 실험에 사용했기 때문입니다. 실험을 위한 사양으로는 1 CORE, 4 GB 도 가능할 것으로 보입니다. 문서 후반 부에 시스템 모니터링 결과를 보면 이점을 좀더 잘 이해할 수 있을 것입니다.

Docker 와 docker-compose 설치

Docker 를 설치하는 이유는 Prometheus 와 Grafana 를 Docker 컨테이너로 실행하기 위해서 입니다. 두 프로세스를 컨테이너로 실행하는 이유는 분산 모니터링을 위한 실험을 편리하게 하기 위해서 입니다. 컨테이너를 사용하면 기동 종료가 손쉬울 뿐 이나라, 실험이 끝난 후, 자원 회수도 간단하기 때문입니다. 실제 운영 환경에서는 컨테이너를 사용할 지, 패키지를 설치할 지, 아니면 전용 VM 에 설치할 지 등, 분산 환경의 규모나, 안정성 확보 등, 여러가지 영향도를 파악해 구성해야 할 것입니다. 필자는 이 실험에서 사용한 컨테이너 기술을 OpenShift/Kubernetes 로 확장할 것을 고려하고 있습니다.

Rocky Linux 는 Red Hat Enterprise Linux 8 의 호환 OS 이므로, 컨테이너 엔진을 기본적으로는 podman 으로 설치합니다. 그런데 인터넷에서 참조하는 문서의 Docker 기술은 Docker 컨테이너 엔진을 사용할 때, 더 잘 동작합니다. 그래서 필자의 Rocky Linux VM 에 podman 이 아닌 docker 커뮤니티 버전을 설치했습니다. 설치 절차는 다음과 같습니다.

sudo dnf update -y
sudo reboot
sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install docker-ce --allowerassing -y
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER
docker run hello-world

sudo dnf install -y curl
sudo curl -L "https://github.com/docker/compose/releases/download/v2.4.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

Dnsmasq 설치와 VM 도메인 이름 등록

도메인 이름 기반 시스템 아키텍처를 사용하는 테스트 환경을 꾸밀 때 설정할 수 있는 네임 서버가 필요합니다. 네임 서버 중 dnsmasq 네임 서버를 설치하면 손쉽게 분산 시스템의 도메인 이름을 설정할 수 있습니다. 다음은 이번 실험에서 사용하는 VM 호스트 이름을 도메인 이름으로 사용하기 위해 Rocky Linux VM 에 dnsmaq 를 설치하고 docker 도메인 이름을 등록하는 절차입니다.

sudo dnf -y install dnsmasq

sudo vi /etc/dnsmasq.conf
# 다음 두줄을 추가합니다. 
no-resolv
server=8.8.8.8

sudo vi /etc/hosts
# 다음 줄을 추가합니다.
192.168.181.100 monitoring

sudo systemctl enable dnsmasq
sudosystemctl start dnsmasq

# 필요 시, 방화벽 개방 
sudo firewall-cmd --add-service=dns
sudo firewall-cmd --runtime-to-permanent

# dnsmasq 설정 다시 읽기
sudosystemctl restart dnsmasq

로컬 PC hosts 등록

VM 을 실행하는 로컬 PC 에도 VM 의 도메인 이름을 hosts 파일에 등록해야 합니다.

# Rocky Linux VM
192.168.181.100 monitoring

실험 전 도메인 이름 점검

실험자는 Rocky Linux VM 과 로컬 PC 에서 ping 등을 이용해, Rocky Linux VM 의 ip 주소가 정상적으로 반환되는 지 확인합니다.

$ ping monitoring
PING monitoring (192.168.181.100) 56(84) bytes of data.
64 bytes from monitoring (192.168.181.100): icmp_seq=1 ttl=64 time=0.055 ms
64 bytes from monitoring (192.168.181.100): icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from monitoring (192.168.181.100): icmp_seq=3 ttl=64 time=0.062 ms

모니터링 에이전트 설치 및 실행

Prometheus 로 시스템 자원이나 애플리케이션 정보를 수집하기 위해서는 VM 에 Prometheus 에이전트를 설치해야 합니다. 다음 절차에 따라 에이전트를 설치하고 설정하고 실행하고 수집한 측정값을 확인합니다.

실험 디렉토리

실험자는 아래와 같이 monitoring 이라는 디렉토리를 생성하고, 이 디렉토리를 실험 root 디렉토리로 시작합니다.

mkdir -p monitoring
cd monitoring

node_exporter 설치와 실행

node_exporter 는 Prometheus 프로젝트에서 시스템 모니터링을 위해 진행하는 서브 프로젝트입니다. node_exporter 를 이용하면 시스템 자원(CPU/Disk/Mem/Network)을 상세히 모니터링 할 수 있습니다.

설치에 사용된 node_exporter 버전입니다.

  • node_exporter-1.3.1.linux-amd64.tar.gz

설치와 실행 절차는 아래와 같습니다.

cd monitoring
# node_exporter 가 시스템 정보를 수집할 수 있게, 커널 패러미터 조정
sudo sysctl -w kernel.perf_event_paranoid=0

# node_exporter 설치 실행
wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.3.1.linux-amd64.tar.gz
cd node_exporter-1.3.1.linux-amd64
sudo mv node_exporter /usr/bin/
sudo chmod +x /usr/bin/node_exporter
node_exporter --web.listen-address=:9100 

node_exporter 는 유저 권한 실행이 가능하다고 문서에 나오므로 유저 모드로 실행했습니다.

process-exporter 설치와 실행

process-exporter 는 시스템에서 실행되는 애플리케이션 프로세스를 모니터링할 수 있게 합니다. process-exporter 실행하면, Prometheus 는 top 명령 등으로 확인할 수 있는 정보들을 수집할 수 있습니다.

설치에 사용된 node_exporter 버전입니다.

  • process-exporter-0.7.10.linux-amd64.tar.gz

설치와 실행 절차는 아래와 같습니다.

wget https://github.com/ncabatoff/process-exporter/releases/download/v0.7.10/process-exporter-0.7.10.linux-amd64.tar.gz
tar xvf process-exporter-0.7.10.linux-amd64.tar.gz
sudo mv process-exporter-0.7.10.linux-amd64/process-exporter /usr/bin/
sudo chmod +x /usr/bin/process-exporter
sudo curl -o /etc/process-exporter.yml https://gist.githubusercontent.com/hinunbi/7efd77affeb09b9947bff2fd29806f87/raw/a2e1e314ccf4e85a64da13db90277897142dfb94/process-exporter.yml
sudo process-exporter --config.path /etc/process-exporter.yml \
  --web.listen-address=:9256

process-exporter 는 실행에 권한 문제가 있을 수 있어 sudo 를 사용해 실행했습니다.

위 명령 실행 중 다운로드하는 process-exporter.yml 파일의 내용은 다음과 같습니다.

process_names:
  - name: "{{.Comm}}"
    cmdline:
    - '.+'

위 설정은 모든 프로세스를 모니터링하는 것입니다.

수집 테스트

위 절차에 따라 node_exporter 와 process-exporter 가 정상적으로 설치 및 실행되면 각 아래 명령으로 각 수출자가 시스템에서 수집하는 저수준 측정 값들을 확인할 수 있습니다.

node_exporter 시스템 정보 조회

	open http://monitoring:9100/metrics

enter image description here

process-exproter 프로세스 정보 조회

	open http://monitoring:9256/metrics

enter image description here

Prometheus, Grafana 실행 준비 및 실행

수출자들이 모두 정상적으로 실행되면, 각 시스템 측정값들을 수집할 Prometheus 와 측정값들을 대시보드로 시각화 할 Gafana 를 설치합니다.

Prometheus 설정

이 글에서 사용하는 Prometheus 설정(prometheus.yml)은 다음과 같습니다.

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers: 
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"


# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  - job_name: 'node monitoring'
    static_configs:
    - targets: ['monitoring:9100']
    - targets: ['monitoring:9256']

참고) https://gist.github.com/hinunbi/d20a020ba4f1b31b74d15c40299ed945

targets 항목에 node_exporter 접속 정보와 process-exporter 접속 정보를 포함합니다. 아래 명령들은 위 설정 파일을 포함해, Prometheus 컨테이너가 실행 할 수 있는 환경을 구성합니다.

cd monitoring
# Prometheus 실행 준비 
sudo rm -rf data/prometheus
sudo mkdir -p data/prometheus/etc/prometheus
sudo curl -o data/prometheus/etc/prometheus/prometheus.yml https://gist.githubusercontent.com/hinunbi/d20a020ba4f1b31b74d15c40299ed945/raw/46bb4686fedee6c744dc4c240c033d2468730fe4/prometheus.yml
sudo chmod -R a+w data/prometheus

Grafana 설정

Grafana 는 GUI 환경으로 접속 정보를 설정할 수 있으므로, grafana.ini 파일은 Grafana 컨테이너 이미지 내 파일을 그대로 사용했습니다. 대신 Grafana 가 구성한 디렉토리와 파일을 호스트로 노출시키게, 볼륨 마운트를 시도했습니다. 그런데 호스트 유저가 생성해 마운트한 디렉토리 권한과 Grafana 컨테이너에서 내부 유저(grafana)가 접근하려는 디렉토리의 기대 권한이 서로 다릅니다. (Docker 가 호스트 볼륨 마운트 시 사용한 유저와 기동 후 해당 디렉토리에 접근하는 컨테이너 유저가 달라저셔 생기는 문제입니다.) 그 결과 Grafana 이미지는 컨테이너로 실행하는 데, 호스트 파일 디렉토리에 Grafana 사용 파일을 마운트 하는 경우, 권한 부족 오류가 발생합니다. 실제 운영 환경에서는 좀더 섬세한 제어를 포함한 방법을 사용해야 할 것이지만, 실험 관점에서는 실행될 수 있는 우회 방법을 찾아 적용했습니다. 그럼에도 필자가 보기에는 Grafana 프로젝트가 언제부터인가 변경되어 사용하고 있는 사용자 실행 권한 처리는 문제가 있다고 보여집니다. 현재 기준으로 Grafana 가 제공하는 문서의 해결책으로는 해결되고 있지 않습니다. 그러므로 커뮤니티 사용자들은 Grafana 컨테이너 실행 시, 호스트 디렉토리를 마운트 하는 경우, 접근 권한 문제를 만나는 한바탕 고생을 해야 하고, 또 찾은 방법도 이후 Grafana 버전이 업그레이드 되면 계속 동작한다는 보장도 할 수 없습니다. 필자도 이런 점을 고려해 현재 기준으로 가장 최신이지만 특정 버전의 Grafana 컨테이너 이미지를 사용하게 Docker Compose 파일 설정을 구성했습니다. 다음은 Grafana 컨테이너를 실행하기 전에 Grafana 컨테이너에 마운트할 호스트 디렉토리를 먼저 생성하고 권한을 설정하는 명령입니다.

cd monitoring
sudo rm -rf data/grafana
sudo mkdir -p ./data/grafana/etc/grafana/provisioning
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/datasources
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/plugins
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/notifiers
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/dashboards
sudo mkdir -p ./data/grafana/var/lib/grafana
sudo chmod -R a+w ./data/grafana

Docker Compose 설정

Prometheus 와 Grafana 컨테이너는 Docker Compose 를 이용해 실행합니다. 실행을 위한 Docker Compose 설정(docker-compose.yml)은 아래와 같습니다.

version: '3'
services:
  prometheus:
    image: prom/prometheus:v2.35.0
    container_name: prometheus
    command:
      - '--web.listen-address=0.0.0.0:9099'
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=168h'
      - '--web.enable-lifecycle'
    volumes:
      - ./data/prometheus/etc/prometheus:/etc/prometheus
      - ./data/prometheus:/prometheus
    ports:
      - 9099:9099
    networks:
      - monitoring-network

  grafana:
    container_name: grafana
    image: grafana/grafana:8.5.0
    environment:
      - GF_SECURITY_ADMIN_USER=cat
      - GF_SECURITY_ADMIN_PASSWORD=meow
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - ./data/grafana/etc/grafana/provisioning:/etc/grafana/provisioning
      - ./data/grafana/etc/grafana/provisioning/datasources:/etc/grafana/provisioning/datasources
      - ./data/grafana/etc/grafana/provisioning/plugins:/etc/grafana/provisioning/plugins
      - ./data/grafana/etc/grafana/provisioning/notifiers:/etc/grafana/provisioning/notifiers
      - ./data/grafana/etc/grafana/provisioning/dashboards:/etc/grafana/provisioning/dashboards
      - ./data/grafana/var/lib/grafana:/var/lib/grafana
    ports:
      - 3000:3000
    depends_on:
      - prometheus
    networks:
      - monitoring-network

networks:
  monitoring-network:

참고) https://gist.github.com/hinunbi/426ee6792ad25dd9a210c2d89a87334a

위 설정에서 Grafana 의 호스트 디렉토리 마운트 목록은 Grafana 컨테이너 실행 후 발생하는 여러 로그를 분석해, 위 Grafana 설정에서 언급한 내용과 더불어, 정상적으로 실행될 수 있게 구성한 것입니다. Grafana 컨테이너 실행 메커니즘을 좀더 분석한다면 개선된 구성을 찾을 수 있을 것으로 보입니다. 그러나 실험은 기능과 가능성을 입증하는 관점에서 컨테이너가 정상 실행되는 정도에서 구성을 맞췄습니다.

Prometheus 와 Grafana 컨테이너 실행

위 설정 과정을 정상적으로 실행했으면, 마지막으로 docker-compose.yml 파일을 다운로드 해서, docker-compose 명령으로 Prometheus 와 Grafana 컨테이너를 실행합니다.

cd monitoring
sudo curl -o docker-compose.yml https://gist.githubusercontent.com/hinunbi/7efd77affeb09b9947bff2fd29806f87/raw/9fbb4fe1d1290654d0f606b39e9c09df69ce458c/docker-compose.yml
docker-compose up

# 아래는 정상적으로 실행한 콘솔 로그입니다. 
Starting prometheus ... done
Starting grafana    ... done
...

# backgroud 로 실행 시
docker-compose up -d

Prometheus 를 이용한 모니터링

위와 같이 모든 요소들이 실행되면, 웹브라우저를 이용해 Prometheus 에 접속할 수 있고, 모니터링 중인 시스템에 대한 상태와 수집된 측정값들도 확인할 수 있습니다.

Prometheus 접속

위 과정에서 Promheus 컨테이너가 잘 실행되면, 다음 접속 URL 을 이용해 Prometheus 에 로그인 할 수 있습니다.

open http://monitoring:9099

enter image description here
위 화면에서 PromQL 을 이용해 여러 시스템에서 수집된 측정값을 조회할 수 있습니다.

시스템 모니터링 측정값 확인 예

다음은 시스템에서 동작 중인 시스템의 애플리케이션 프로세스의 CPU 사용 시간을 아래 측정 이름을 이용해 확인한 예입니다.

  • namedprocess_namegroup_cpu_seconds_total

enter image description here
위 결과는 Grafana 를 이용해 시각 정보로 표현될 수 있습니다.

시스템 모니터링 대상 시스템 확인

아래 접속 정보로 Prometheus 에 접속하시면 Prometheus 가 현재 모니터링하는 시스템을 확인할 수 있습니다.

open http://monitoring:9099/targets

enter image description here
위 화면은 node_exporter (9100) 와 process-exporter(9256) 에서 정상적으로 수집이 일어나고 있다는 보여줍니다.

Grafana 를 이용한 모니터링

이 실험의 최종 목표는 시스템 측정값을 시각화 하는 데 있다고 해도 과언이 아닙니다. 이제 그 과정을 단계 별로 설명합니다.

Grafana 접속

위 docker-compose 를 실행해, Grafana 컨테이너가 잘 실행되면, 다음 접속 URL 을 이용해 Grafana 대시보드에 로그인 할 수 있습니다.

open http://monitoring:3000 2  3username: cat, Password: meow

enter image description here
참고) username 과 Password 는 docker-compose.yml 설정에서 지정했습니다. 수정이 필요하면 docker-compose.yml 파일을 수정하면 됩니다.

Data Source 연결 설정

로그인 후, 왼쪽 아래에서 두번째 버튼을 선택하면 Data Source 를 추가할 수 있습니다. 추가할 Data Source 는 위에서 실행한 Prometheus 컨테이너입니다. 아래 화면에서 “Add data source” 버튼을 클릭합니다.
enter image description here
“Add data source” 버튼을 클리해 나온 아래 화면에서 “Prometheus” 를 선택합니다.

enter image description here
아래 Data Sources/Prometheus 설정에서 HTTP/URL 입력 값을 다음 접속 정보로 입력합니다. 이 접속 정보는 앞서 Prometheus 접속에서 사용한 접속 정보입니다.

enter image description here
위 화면 아래 “Save & test” 버튼을 클릭해 접속이 성공하면 아래와 같은 화면을 볼 수 있습니다.
enter image description here위 과정을 마치면 정상적으로 Prometheus 데이터 소스가 성공적으로 연결된 것입니다.

시스템 CPU/Mem/Disk/Network 자원 모니터링

시스템 CPU/Mem/Disk/Network 자원 모니터링 정보는 node_exporter 가 제공합니다. 이 정보는 이미 Grafana 대시 보드로 잘 표현되고 있습니다. 이 모니터링 과정은 다음 몇 번의 클릭으로 완성됩니다.

우선 Grafana 대시 보드의 왼편 “+” 메뉴를 선택해 나온 화면에 “Import via grafana.com” 에 다음 숫자를 입력하고 “Load” 버튼을 클릭합니다.

  • 1860

enter image description here
Load 하는 과정에서 Data Source 를 앞서 만든 값을 지정합니다. 그러면 아래와 같은 멋진 대시보를 를 확인할 수 있습니다.

enter image description here
위 화면을 보면 이 실험에서 모니터링되는 VM 의 CPU 사용률은 1 % 미만이고, 메모리도 위 그림에서는 잘 보이지 않지만 1GB 이하임을 확인할 수 있습니다. 즉 필자가 이 실험에서 사용한 VM 보다 적은 VM 으로도 실험이 가능할 것으로 예상할 수 있습니다. 현재 모니터링 되는 VM 에는 node_exporter, process-exporter, Prometheus, Grafana 가 모두 실행되고 있습니다. 이런 점을 참고해 독자들은 실험에 사용할 VM 자원을 설정해 주시면 될 것입니다.

애플리케이션 모니터링

애플리케이션 모니터링 정보는 process-exporter 가 제공합니다. 이 정보도 이미 Grafana 대시 보드로 잘 표현되고 있습니다. 이 과정은 다음 몇 번의 클릭으로 완성됩니다.

우선 Grafana 대시 보드의 왼편 “+” 메뉴를 선택해 나온 화면에 “Import via grafana.com” 에 다음 숫자를 입력하고 “Load” 버튼을 클릭합니다.

  • 1860
    enter image description here
    Load 하는 과정에서 Data Source 를 앞서 만든 값을 지정합니다. 그러면 아래와 같은 멋진 대시보를 를 확인할 수 있습니다.

enter image description here
위 화면을 보면 애플리케이션 프로세스가 개수, CPU, Memory 등 표준 상태 값을 확인할 수 있습니다.

맺음말

이 글에서는 분산 환경에서 시스템의 자원과 애플리케이션 프로세스를 오픈소스 모니터링 도구인 Prometheus 와 Grafana 를 이용해 모니터링 하는 기술을 실험했습니다. 오픈 소스로 시스템과 애플리케이션 모니터링에 관심을 갖는 독자는 이 글을 따라하면 큰 문제 없이 기대한 결과를 맛볼 수 있을 것입니다.

분산 시스템 모니터링을 위해 고가의 상용 제품을 사용하는 기업에게 오픈 소스를 이용한 모니터링의 가능성을 제공하면서 필자가 하고 싶은 이야기는, 2016 년 SpaceX 에서 팔콘 로켓을 발사할 때 모니터링 대시 보드로 Grafana 가 사용돼 화제된 이야기입니다. 우주 항공 기술이 오픈 소스를 활용한다는 점에서 시사점이 큰 사건이었습니다. 바꿔 말해, 일반 기업이 오픈 소스 기술을 도입하지 못할 이유에 대해서도 고민해야 할 것이라고 말할 수 있을 것입니다. SpaceX 사례는 아래 참고 자료 링크로 확인할 수 있습니다.

오픈 소스는 사용하기에 따라, 상용 제품을 대체할 수 있는 강력한 가능성을 제공한다는 점에서 엔지니어라면 꾸준히 탐색하고 공부해야 할 영역입니다. 그러나 항상 부딪치는 문제는 오픈 소스 문서의 모호성, 불일치성, 문서화되지 않는 정보와 같은 것들입니다. 그 결과 원하고자 하는 목표를 달성하기 위해 오픈 소스를 이용하려면 생각보도 많은 노력을 기울여야 하는 경우도 빈번합니다. 그래도 소스가 공개돼 있으니, 노력하면 문제 해결 뿐만아니라, 구현 노하우도 습득할 수 있을 것입니다. 그 과정을 즐기는 것도 엔지니어로서 좋은 태도일 것입니다. 그러나 기업이나 기업 내 엔지니어 입장에서 모든 것을 스스로 하지 않고, 주변의 오픈 소스 전문 회사나 전문가의 도움을 받은 것도 현명한 생각일 것입니다. 기업은 자사의 엔지니어가 오픈 소스 전문 기업 또는 전문가와 협업해 기업의 IT 환경을 가치있게 만들면서 서로가 기술을 공유한다면, 오픈 소스가 추구하는 가장 이상적인 협업 모델일 것입니다. 이를 위해 오픈 소스 기업이 발전 성장할 수 있는 생태계도 반드시 지속돼야 할 것입니다.

이 글이 분산 환경에서 시스템과 애플리케이션을 모니터링을 하려는 분들에게 조금이나마 도움이 됐으면 합니다.

참고 자료

  1. Rocky Linux 8에 Docker 및 Docker-Compose를 설치하는 방법
  2. Monitoring Linux host metrics with the Node Exporter | Prometheus
  3. Node Exporter Full dashboard for Grafana | Grafana Labs
  4. Named processes dashboard for Grafana | Grafana Labs
  5. Grafana- It’s Rocket Science

2022년 2월 7일 월요일

Apache Camel 애플리케이션 만들기

Apache Camel 애플리케이션 만들기

들어가며

일반적으로 애플리케이션에서 프레임워크를 이용하려면, 개발 소스 프로젝트에 프레임워크가 요구하는 의존, 설정, 코드 등을 입력해야 합니다. 그러므로 새로운 프레임워크를 이용하려는 개발자는 반드시, 이 내용을 프레임워크 관련 자료나 책 등을 학습해 애플리케이션 프로젝트에 적용해야 합니다. Java 애플리케이션 프레임워크로 가장 장 알려진 Spring 프레임워크나 Spring Boot 프레임워크도 오류 없이 기대하는 동작을 실행시키려면, Java 메인 클래스, 설정, 클래스, 메서드, 애노테이션, application.properties 나 application.yaml 등 애플리케이션 개발에 필요한 여러 가지 “관례(convention)” 와 “설정(configuration)”을 이해하고 올바르게 입력해야 합니다.

이런 과정은 Apache Camel 프레임워크를 사용할 때도 동일하게 적용됩니다. 그런데 Apache Camel 프레임워크를 처음 접한 개발자들이 올바른 Apache Camel 애플리케이션을 만들기는 그렇게 간단하지 않습니다. 그 이유는Apache Camel 프레임워크도 “관례(convention)”와 “설정(configuration)”을 정확하게 사용해야 하는데, 이런 “관례(convention)”와 “설정(configuration)” 은 해당 기술을 깊은 이해해야 체득되는 것이기 때문입니다.

Apache Camel 프레임워크를 접한 개발자들이 “관례(convention)”와 “설정(configuration)” 이 잘 구성된 애플리케이션 프로젝트부터 개발을 시작하는 것은 굉장히 중요한 출발점입니다. 그럼에도 책이나 문서들은 이 출발점에 대해 다양하게 설명하지만 선택할 수 없는 차림표처럼 제시할 뿐, 어떤 것이 최선의 “관례(convention)”와 “설정(configuration)” 인지는 잘 설명하고 있지 않습니다.

이런 점에서 이 글 Apache Camel 프레임워크 개발자들에게 유용한 Apache Camel 애플리케이션 프로젝트의 출발점을 제공합니다. 이를 위해 이 글은 Apache Camel 애플리케이션 개발을 시작하는 다양한 방법 중 주요 방법을 설명하고, 그 중 일관된 “관례(convention)”와 “설정(configuration)” 를 포함한 Apache Camel 애플리케이션 프로젝트를 생성하게 해주는 필자의 Spring Boot Apache Camel XML Archetype 을 설명합니다.

Apache Camel 이란?

  Apache Camel 은 잘 정립된 기업 통합 패턴(Enterprise Integraion Patterns) 개념을 이용해, 쉽고 표준적인 방법으로 애플리케이션을 통합할 수 있게 하는 Java로 작성된 프레임워크입니다. Apache Camel 의 컴포넌트는 데이터베이스, 메시지 브로커, HTTP 애플리케이션, 파일 시스템 등 다양한 기술의 엔드포인트를 통합(접속)시킬 수 있습니다. 이미 이런 컴포넌트가 300 개 이상 구현되어 있습니다. 예를 들어, Twitter, AWS, Azure, Kafka, Google, File, FTP, SOAP, Rest API, DBMS, No Sql 등등 대부분의 주요 플랫폼과 기술들의 컴포넌트를 포함합니다. 이런 점에서 Apache Camel 은 기업 통합(Enterprise Integration)을 위한 완벽한 스위스 칼(Swiss knife)입니다.

Apache Camel 프로젝트 만들기

Apache Camel 은 독립적으로 실행될 수도 있으나, 다양한 애플리케이션 프레임워크와 결합해 실행하는 내장형 통합 프레임워크 입니다. 그 중 가장 현대화된 방식으로 Spring Boot 나 Quarkus 애플리케이션에 Apache Camel 을 내장해 애플리케이션을 실행하는 것입니다. 그 외 더 다양한 방식으로 실행할 수 있으나, 실무적으로 이 두 방식이 가장 유용성이 높을 것으로 보입니다. 이 글은 Spring Boot 나 Quarkus 와 결합한 Apache Camel 애플리케이션 프로젝트를 만드는 법을 소개합니다. Apache Camel 애플리케이션 소스 생성하는 방법으로 웹 기반 생성과 Maven Archetype 을 이용한 방법을 소개합니다. 다른 방법에 관심있는 독자는 독자 자신의 탐구 과제로 남기겠습니다.

실행 환경

Apache Camel 애플리케이션 생성 환경은 다음과 같습니다. 사전에 설치돼 있어야 합니다.

  • Linux 또는 macOS 권장
  • JDK 8+
  • Maven 3.5+

Spring initaializr 를 이용한 프로젝트 만들기

Apache Camel 애플리케이션 프로젝트는 Spring initaializr(https://start.spring.io/) 사이트를 이용해 만들 수 있습니다. 이 사이트를 이용하면, 생성한 애플리케이션 프로젝트에서 아마치 카멜과 Spring Boot 프레임워크를 함께 이용할 수 있습다. Apache Camel 은 Spring 프레임워크와 잘 결합되고, Spring 프레임워크에서도 Apache Camel 을 이니셜라이져 사이트에서 내장할 수 있게 지원합니다. Spring 이니셜라이저 사이트에서 다음 정보를 입력해 Apache Camel 의존을 포함하면 Apache Camel 애플리케이션을 만들 수 있습니다.

이 글에서는 Spring Initializr 에서 생성하는 프로젝트 형식은 Java Maven 프로젝트로 지정했습니다. Gradle 프로젝트로도 생성할 수 있으나, Apache Camel 프로젝트는 Maven 프로젝트를 선호하기 때문입니다. 그 이유는 “Simple is Better” 원칙을 따르기 때문일 것입니다.

  • Project : Maven Project

  • Spring Boot: 2.6.3

  • Project Metadata

    • Group: org.example
    • Artifact: camel-sprig-hello
    • Name: camel-spring-hello
    • Description: Demo project for Spring Boot
    • Package name: org.example.camel-spring-hello
    • Packaging: Jar
    • Java: 11
  • Dependencies: Spring Web, Apache Camel

    camel-spring-hello

위 값들을 입력 후, “GENERATE” 버튼을 클릭하면 camel-hello.zip 파일로 Apache Camel 애플리케이션 프로젝트 소스를 다운로드 합니다.

생성된 camel-spring-hello 프로젝트 구조는 다음과 같습니다.

camel-spring-hello  
├── HELP.md  
├── mvnw  
├── mvnw.cmd  
├── pom.xml  
└── src  
 ├── main 
 │   ├── java 
 │   │   └── org 
 │   │       └── example 
 │   │           └── camelspringhello 
 │   │               └── CamelSpringHelloApplication.java 
 │   └── resources 
 │       └── application.properties 
 └── test 
     └── java 
         └── org 
             └── example 
                 └── camelspringhello 
                     └── CamelSpringHelloApplicationTests.java

Spring Initializr 가 생성한 Apache Camel 프로젝트의 Apache Camel 프레임워크 버전은 Spring Boot 버전에 따라 결정됩니다. 그러므로 원하는 Apache Camel 프레임워크 버전을 맞추려면 Spring Boot 버전을 조정할 필요가 있습니다.

생성된 Apache Camel 프로젝트는 Spring Boot Maven 프로젝트로 생성됐으므로, 다음 명령으로 실행할 수 있습니다.

mvn spring-boot:run

그러나 생성된 프로젝트는 필요한 의존 라이브러리만 포함되었을 뿐, 로직이 구현되어 있지 않았으므로 실행 결과를 기대할 수 없습니다.

Code with Quarkus 를 이용한 프로젝트 만들기

Apache Camel 애플리케이션 프로젝트는 Code with Quarkus(https://code.quarkus.io) 사이트를 이용해 만들 수 있습니다. 이 사이트를 이용하면, 생성한 애플리케이션 프로젝트는 Apache Camel 프레임워크와 Quarkus 프레임워크를 함께 사용할 수 있습니다. Quarkus 프레임워크가 커뮤니티에 소개된 기간을 길지 않으나, Red Hat 이 Red Hat 제품에서 Spring Framework 을 대체하고, Apache Camel 을 사용하게 하는 방향으로 발전하고 있습니다.

  • CONFIGURE YOUR APPLICATION
    • Group: org.example
    • Artifact: camel-quarkus-hello
    • Build Tool: Maven
    • Extentions: Camel Core

camel-quarkus-hello

생성된 camel-quarkus-hello 프로젝트 구조는 다음과 같습니다.

camel-quarkus-hello  
├── README.md  
├── mvnw  
├── mvnw.cmd  
├── pom.xml  
└── src  
    ├── main 
    │   ├── docker 
    │   │   ├── Dockerfile.jvm 
    │   │   ├── Dockerfile.legacy-jar 
    │   │   ├── Dockerfile.native 
    │   │   └── Dockerfile.native-distroless 
    │   ├── java 
    │   │   └── org 
    │   │       └── example 
    │   │           └── GreetingResource.java 
    │   └── resources 
    │       ├── META-INF 
    │       │   └── resources 
    │       │       └── index.html 
    │       └── application.properties 
    └── test 
        └── java 
            └── org 
                └── example 
                    ├── GreetingResourceTest.java 
                    └── NativeGreetingResourceIT.java

생성된 소스 구조는 Spring Boot 와 유사합니다. 추가로 Docker 이미지 생성 관련 설정도 포함됩니다. 그런데 생성된 애플리케이션 소스는 Apache Camel 관련 의존만 포함하므로, Apache Camel 소스를 어떻게 구현할 것인가 에 대해서는 개발자가 결정해야 합니다. Quarkus 프레임워크는 개발자들에게 생소하므로, 사용하기 위한 사전 학습 또는 Red Hat 컨설팅의 도움이 필요합니다. 좀더 자세한 소개는 아래 참고 사이트를 방문해 주십시오.

생성된 Apache Camel 프로젝트는 Maven 프로젝트로 생성됐으므로, 다음 명령으로 실행할 수 있습니다.

./mvnw compile quarkus:dev

그런데 필자가 Code with Quarkus 2.7 에서 다운로드한 camel-quarkus-hello 는 컴파일이 잘 되지 않았습니다. 어떤 이유가 있을 텐데… 이런 문제는 오픈 소스를 사용하는 경우 빈번히 발생하는 문제입니다. 이 글은 Apache Camel 프로젝트를 만드는 방법을 소개하는 글이므로, 관심있는 독자께서는 직접 컴파일을 시도해 보시고, 문제가 있을 경우 문제 원인을 찾아 해결할 수 있을 것입니다.

Apache Camel Archetype 을 이용한 프로젝트 만들기

Apache Camel 은 Maven Archetype 을 이용해 Apache Camel 애플리케이션 프로젝트를 생성하는 방식도 지원합니다. 이 방식의 장점은 웹 환경이 없어도 간단히 Maven 명령을 이용해 Camel 애플리케이션 프로젝트를 생성할 수 있다는 점입니다. 다음은 명령은 Apache Camel 3.14.1 버전과 Spring Boot 프레임워크가 결합된 Apache Camel 애플리케이션 프로젝트를 생성합니다.

mvn archetype:generate \
 -B \
 -DarchetypeGroupId=org.apache.camel.archetypes \
 -DarchetypeArtifactId=camel-archetype-spring-boot \
 -DarchetypeVersion=3.14.1 \
 -DgroupId=org.example \
 -DartifactId=camel-spring-archetype-hello

Spring Boot 외 다양한 프레임워크나 기술 기반의 프로젝트를 생성할 수 있습니다. 아래 참고 사이트를 참조해 주십시오.

생성된 camel-spring-archetype-hello 프로젝트 구조는 다음과 같습니다.

camel-spring-archetype-hello  
├── pom.xml  
└── src  
 ├── main 
 │   ├── java 
 │   │   └── org 
 │   │       └── example 
 │   │           ├── MySpringBean.java 
 │   │           ├── MySpringBootApplication.java 
 │   │           └── MySpringBootRouter.java 
 │   └── resources 
 │       ├── META-INF 
 │       │   ├── LICENSE.txt 
 │       │   └── NOTICE.txt 
 │       └── application.properties 
 └── test 
     ├── java 
     │   └── org 
     │       └── example 
     │           └── MySpringBootApplicationTest.java 
     └── resources

생성된 소스는 Apache Camel Java DSL 라우트 정의는 포함되어 있으나, XML DSL 은 포함되어 있지 않습니다. XML DSL 을 포함한 애플리케이션 생성은 Red Hat Fuse 에서 만 제공하기 있습니다. 최근들어 커뮤니티에서는 Java DSL 을 선호하는 측면이 있으나, XML DSL 이 갖는 장점도 분명하므로, Apache Camel 애플리케이션은 XML DSL 과 Java DSL 을 함께 사용하는 것을 권장 드립니다. 그리고 생성된 파일 이름에 MySpring 이 붙고, 라이선스 파일이 META-INF 디렉토리 아래 위치하는데… 이런 것들을 애플리케이션 생성 후, 수정이 필요한 부분 들입니다.

Red Hat Fuse Maven Archetype 을 이용한 프로젝트 만들기

Apache Camel 프로젝트는 Red Hat 이 주도하는 오픈 소스 프로젝트입니다. 그러므로 Red Hat 은 Apache Camel 을 포함한 상용 오픈 소스 통합 제품으로 Red Hat Fuse 를 판매합니다. Red Hat Fuse 는 커뮤니티 오픈 소스인 Apache Camel 에 확장된 개발 도구, 개발 문서, 라이브러리, 레지스트리, 컨설팅 서비스, 기술 지원 서비스 등을 추가적으로 제공합니다. 그 중 Red Hat Fuse Maven Archetype 를 이용해 Apache Camel 애플리케이션 프로젝트를 만드는 방법을 제공합니다. 이 방법을 이용해 만들어진 프로젝트 소스는 커뮤니티 Apache Camel 기반이 아닌 Red Hat Camel 프로젝트가 만들어지나, 온전히 동작되는 소스 구조를 갖고 있으므로, Red Hat Fuse 를 구매한 고객의 개발자는 이 기능을 유용하게 이용할 수 있습니다. 다음은 Red Hat Fuse spring-boot-camel-xml-archetype 을 이용해 Red Hat Camel 애플리케이션을 생성한 예입니다.

wget https://gitlab.com/hinunbi/spring-boot-camel-xml-archetype/-/raw/main/configuration/settings.xml   

mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
 -B \
 -s settings.xml \
 -DarchetypeCatalog=https://maven.repository.redhat.com/ga/io/fabric8/archetypes/archetypes-catalog/2.2.0.fuse-sb2-780040-redhat-00002/archetypes-catalog-2.2.0.fuse-sb2-780040-redhat-00002-archetype-catalog.xml \
 -DarchetypeGroupId=org.jboss.fuse.fis.archetypes \
 -DarchetypeArtifactId=spring-boot-camel-xml-archetype \
 -DarchetypeVersion=2.2.0.fuse-sb2-780040-redhat-00002 \
 -DgroupId=org.example \ -DartifactId=fuse-hello

위 명령 실행에 settings.xml 파일 필요한 이유는, Red Hat Fuse 애플리케이션을 생성하기 위한 Archetype 이 Apache Maven Central 저장소에는 등록되어 있지 않고, 상용 제품이다 보니, Red Hat Maven 저장소에만 등록되어 있기 때문입니다.

생성된 fuse-hello 프로젝트 구조는 다음과 같습니다.

fuse-hello/  
├── LICENSE.md  
├── configuration  
│   └── settings.xml  
├── pom.xml  
└── src  
 ├── data 
 ├── main 
 │   ├── fabric8 
 │   │   └── deployment.yml 
 │   ├── java 
 │   │   └── org 
 │   │       └── example 
 │   │           ├── Application.java 
 │   │           └── MyTransformer.java 
 │   └── resources 
 │       ├── application.properties 
 │       ├── logback.xml 
 │       └── spring 
 │           └── camel-context.xml 
 └── test 
     └── java 
         └── org 
             └── example

Red Hat Fuse Camel 애플리케이션은 개발자가 애플리케이션을 개발할 때 필요한 Spring Boot Undertow WAS 와 Camel Java DSL, XML DSL 과 최근 보안 취약점이 발견된 log4j 가 아닌 logback.xml 을 포함하고, Red Hat OpenShift 플랫폼에 컨테이너 이미지로 배포하기 위한 파일과 설정 들도 포함되어 있습니다. 단위 테스트 소스가 포함되어 있지 않은 점을 제외하면 개발자들이 개발을 시작할 때 가장 좋은 Camel 애플리케이션 소스 구조를 갖고 있습니다. 그러나 Red Hat Fuse 를 구매하지 않은 경우, 생성된 소스와 라이브러리 사용 시, 저작권 문제가 걸릴 수 있습니다.

Apache Camel 애플리케이션 만들기

Apache Camel 애플리케이션은 위와 같은 방식으로 최초 프로젝트 소스를 생성한 후, 프로젝트에 300 개 이상의 통합 컴포넌트 의존을 추가함으로, 현대 애플리케이션의 통합에 필요한 대부분의 기능을 지원할 수 있습니다. 그러나 위 생성 방법들을 이용해 생성된 Apache Camel 애플리케이션은 오픈 소스 결과물의 불완전성, 생성된 소스의 불합리한 구조, 상용 오픈 소스가 갖는 저작권 등을 때문에, 개발자는 생성된 소스를 다시 정비해 사용해야 합니다. 그리고 이렇게 정비한 소스로 Apache Camel 애플리케이션 개발 출발점을 삼아야 합니다. 그런데 이 과정은 반복되나 사람이 하는 일이라 일관되지 않는 경우가 빈번합니다. 그렇다고 계속 정비해 이용 하자니, 불편함이 따릅니다.

이런 문제점을 해결하기 위해, 필자는 위 방법을 종합한 Apache Camel 애플리케이션 Archetype 을 새로 개발했습니다. 필자가 개발한 Apache Camel Archetype 은 커뮤니티 오픈 소스에 기반한 Apache Camel 애플리케이션을 생성함에도, 소스 구조는 Red Hat Fuse 구조로 생성되고 Camel Java DSL과 XML DSL 을 모두 사용하고, Red Hat OpenShift(Kubernetes) 플랫폼에 배포될 수 있는 설정과 Maven 플러그인 등을 자동으로 포함합니다. 사용 방법은 위에서 설명한 Maven Archetype 을 이용한 Apache Camel 애플리케이션 생성과 유사합니다. 필자의 Archetype 을 사용해 Apache Camel 애플리케이션을 생성하는 명령은 다음과 같습니다. 좀더 자세한 설명은 필자의 spring-boot-camel-xml-archetype Git 저장소 를 참고해 주십시오.

git clone https://gitlab.com/hinunbi/spring-boot-camel-xml-archetype.git  
cd spring-boot-camel-xml-archetype  
git checkout tags/0.0.1
mvn install archetype:update-local-catalog  
  
mvn org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate \  
 -B \
 -DarchetypeGroupId=hinunbi.camel.archetypes \
 -DarchetypeArtifactId=spring-boot-camel-xml-archetype \
 -DarchetypeVersion=0.0.1 \
 -Dspring-boot-version=2.5.4 \
 -Dcamel-version=3.14.1 \
 -Dfabric8-version=5.12.0 \
 -Djkube-version=1.5.1 \
 -DgroupId=org.example \
 -DartifactId=camel-hinunbi-hello  

필자가 테스트한 Apache Camel 애플리케이션 생성에 사용한 Apache Camel 버전과 Spring Boot 버전 등, 이 글을 쓰는 시점에서 유효합니다.
오픈 소스들은 역동적으로 발전함으로, 이 글을 읽는 독자가 실행하는 시점에 프레임워크들의 버전이 업그레이드 된 경우, 업그레이드 버전으로 테스트 할 수 있을 것입니다. 다만 Apache Camel 이 의존하는 Spring Boot 버전에 따라 위 명령에 -Dspring-boot-version=* 값을 정확히 입력해야 점은 유의해야 합니다.

생성된 camel-hinunbi-hello 프로젝트 구조는 다음과 같습니다.

camel-hinunbi-hello/  
├── LICENSE.txt  
├── NOTICE.txt  
├── ReadMe.adoc  
├── pom.xml  
└── src  
    ├── main 
    │   ├── java 
    │   │   └── org 
    │   │       └── example 
    │   │           ├── Application.java 
    │   │           ├── MySpringBean.java 
    │   │           └── MySpringBootRouter.java 
    │   └── resources 
    │       ├── application.properties 
    │       ├── logback.xml 
    │       └── spring 
    │           └── camel-context.xml 
    └── test 
        ├── java 
        │   └── org 
        │       └── example 
        │           └── ApplicationTest.java 
        └── resources

필자가 개발한 Apache Camel Maven Archetype 을 이용해 생성한 Apache Camel 프로젝트 소스는 Red Hat Fuse Camel 애플리케이션 소스와 같은 구조이면서 순수하게 Apache Camel, Spring Boot 오픈소스로만 구성된 소스가 생성된 것을 볼 수 있습니다.

생성된 Apache Camel 프로젝트는 Spring Boot maven 프로젝트로 생성됐으므로, 다음 명령으로 실행할 수 있습니다.

mvn spring-boot:run

맺음말

일련의 애플리케이션들은 협업을 하기 위해, 좋은 아키텍처가(모노리스/마이크로서비스) 필요하듯이,
좋은 애플리케이션은 소스 구조가 좋아야 합니다.
소스 구조가 좋으려면, 소스는 사용하는 프레임워크들의 관례를 일관되게 지켜야 합니다.
그래야 개발자들은 소스 구조에 대한 공통의 이해를 갖고 개발자들 사이 의사 소통(communication)이 원할해 질 수 있습니다.
Apache Camel 애플리케이션도 이런 소스 구조 관례를 잘 지켜야 개발 생산성이 올라갈 수 있습니다.

이 글에서는 여러 프레임워크에서 Apache Camel 을 포함한 소스를 생성하는 방법과 생성된 소스 구조를 설명했습니다.
그리고 필자가 생각하는 최선의 관례를 포함한 필자의 Archetype 을 소개했습니다.
Apache Camel 에 관심을 갖고 통합 업무에 Apache Camel 프레임워크를 적용해 보려는 개발자들이 이 글을 읽고, 따라 실행해 Apache Camel 애플리케이션을 만들어 본다면,
Apache Camel 애플리케이션 개발을 시작할 때 그 출발점을 어떻게 해야할 지 결정하는데, 도움이 될 것입니다.

참고 자료

  1. Enterprise Integration Patterns
  2. 기업 통합 패턴
  3. Spring Boot Camel XML Archetype
  4. Spring Boot Initializr
  5. Code with Quarkus
  6. Apache Camel Archetype
  7. Apache Maven Archetype
  8. Quarkus + Apache Camel 소개

2020년 5월 12일 화요일

Quarkus + Apache Camel 소개

Quarkus + Apache Camel 소개

들어 가며

최근 Red Hat 은 GraalVM 기술의 등장에 발맞춰 Quarkus 오픈소스 프로젝트를 시작했습니다. 현재 GraalVM 과 함께 지속적으로 발전하는 Quarkus 는 자바 언어의 실행 방식을 확장합니다. 이 글에서는 Quarkus 를 이용해 Apache Camel 자바 애플리케이션이 어떻게 개선되는지 실험해 보고자 합니다.

Quarkus 소개

Red Hat 이 주도하는 오픈소스 프로젝트인 Quarkus 는 자바 오픈소스 및 자바 표준을 기반으로 JVM 및 native image 환경에 최적화된 애플리케이션을 개발 및 빌드할 있게 하는 Kubernetes 를 위한 자바 프레임 워크입니다. Quarkus는, Serverless, Microservice, Container, Kubernetes, FaaS 와 Cloud 를 염두에 두고 설계되어, 자바 애플리케이션을 실행하기 위한 효과적인 해결책을 제공합니다. Quarkus 는 자바 애플리케이션의 메모리 사용량을 줄여주고, 시작 시간을 빠르게 합니다. 이로써 C 나 Golang 등 native image 로 빌드되는 언어 만이 가질 수 있었던 장점을 자바 언어로 손쉽게 구현할 수 있게 합니다.

Red Hat 은 Quarkus 를 Red Hat Runtimes 에 포함해 GA 했습니다.

Apache Camel 소개

Red Hat 이 주도하는 오픈소스인 Apache Camel 은 기업 통합 패턴(EIP, Enterprise Inrgration Patters) 구현체로 경량의 통합 프레임워크입니다. 그러므로 Apache Camel 은 애플리케이션에 함께 패키징이 가능합니다. Apache Camel 은 내부에 라우터 엔진, 프로세서, 컴포넌트, 메시징 시스템을 포함해, 애플리케이션의 내부를 외부 세계와 손쉽게 인터페이스할 수 있게 해줍니다. 즉 Apache Camel 은 애플리케이션, 시스템, 서비스들 사이에서 데이터(Data)와 기능(Function)을 통합(인터페이스)하는 중재자(Mediator)로서 역할합니다.

Red Hat 은 Apache Camel 을 Red Hat Fuse 에 포함해 GA 했습니다.

Quarkus Apache Camel 프로젝트 준비

두 오픈소스 프로젝트 Quarkus 와 Apache Camel 은, Red Hat 주도로, 컨테이너 기반 MSA(Microservice Architecture)와 통합(Integration)을 손쉽게 구현할 수 있게 서로 협력하고 발전하고 있습니다. 그러므로 Quarkus Apache Camel 프로젝트의 생성도 두 기술이 함께 잘 녹아 있는 절차를 따릅니다.

이 문서의 실행 명령들은 필자의 MacBook(macOS) 에서 실행하고 검증했습니다. 그러므로 이 문서를 따라 테스트 하는 독자는 Linux, macOS, Windows 10(WSL 2 설치) 환경에서 테스트할 것을 권장드립니다.

Quarkus Apache Camel 애플리케이션도, 자바 애플리케이션이므로, 자바 애플리케이션 빌드 도구가 필요합니다.

  • JDK 11+ 과 JAVA_HOME 경로 등록
  • Apache Maven 3.6.2+

Quarkus 로 native image 를 빌드할 경우, 추가로 다음의 플랫폼 환경과 도구가 필요합니다.

  • 64 bit OS (Linux 64bit x86 or ARM, Mac OS X 64bit, Windows 64bit)
  • 시스템 메모리 14 GB+
  • GraalVM Community Edition 20.0.0 과 GRAALVM_HOME 경로 등록
  • GraalVM Native image generator (native-image)

GraalVM 은 아래 사이트에서 플랫폼에 맞는 실행 바이너리를 다운로드 합니다.

GraalVM 설치 후, GraalVM native image generator 는 다음 명령을 실행해 설치합니다.

$ cd $GRAALVM_HOME/bin
$ ./gu install native-image

주의

GraalVM 설치 후, 각 플랫폼 별로 native image 빌드를 위한 추가 개발 도구를 설치해야 합니다. 다음 사이트를 참고해 추가 개발 도구를 설치합니다.

위 사이트에 설명이 없는 CentOS 7 나 RHEL 7 플랫폼의 추가 개발 도구는 다음 명령을 실행해 설치합니다.

$ sudo yum group install -y "Development Tools"
$ sudo yum install -y zlib-devel

유스케이스

이 글의 Apache Camel 애플리케이션은 아래와 같은 통합 유스케이스의 구현을 실험했습니다. 이 통합 유스케이스는, CSV 파일을 읽어 JSON 포맷으로 Rest API 에 전달하는 절차로, 기업에서 실무적으로도 사용할 수 있을 것입니다. 실무적 유스케이스를 사용한 이유는 Apache Camel의 실무적 통합 컴포넌트와 의존 라이브러리들이 Quarkus 를 이용해 Native image 로 잘 전환되는 지를 검증하기 위해서였습니다.

  1. CVS 데이터 생산자는 5초마다 실행됩니다.
  2. 실행된 데이터 생산자는 두 줄의 CSV UserInfo 레코드를 애플리케이션 실행 디렉토리 아래 input 디렉토리에 userinfo.csv 파일로 기록합니다.
  3. 파일 소비자는 input 디렉토리에서 생성된 userinfo.csv 파일을 읽고 분할기를 이용해 두 줄의 레코드를 두 개의 UserInfo 자바 객체로 변환 (unmarshal) 합니다.
  4. 파일 소비자는 UserInfo 자바 객체의 readCount 멤버 변수 값을 파일 소비자가 읽은 순서로 갱신합니다.
  5. 파일 소비자는 웹서비스의 Rest API(http://localhost:8080/userinfo) 를 호출해 UserInfo 정보를 JSON 메시지로 전송합니다.
  6. 웹 서비스는 수신한 JSON 메시지를 콘솔 로그로 기록합니다.
  7. 콘솔 로그에서 CSV 파일 레코드 생성 시각과 파일 소비자가 읽은 순서 등을 확인합니다.

이 유스케이스의 기업 통합 패턴(EIP, Enterprise Integration Patterns) 다이어그램은 다음과 같습니다.

Quarkus Apache Camel 프로젝트

지금까지 기본 설명을 마쳤으므로, 이제 Quarkus Apache Camel 프로젝트 생성 절차를 설명합니다. Apache Camel Quarkus 프로젝트를 가장 손쉽게 시작하는 방법 중 하나는 다음 사이트에서 필요한 컴포넌트를 선택해 Qurkus 기능이 포함된 자바 프로젝트를 생성하는 것입니다.

위 사이트에 접속해 다음과 같이 생성할 프로젝트의 정보를 입력하고, 옵션을 선택합니다. 애플리케이션 상세 (Configure your application details) 에서 다음과 같이 입력합니다.

  • Group : com.demo
  • Artifact : quarkus-camel-demo
  • Build Tool : Maven

확장 선택 (Pick your extensions) 에서 다음의 확장을 선택합니다.

  • RESTEasy Jackson
  • Camel Quarkus Core
  • Camel Quarkus Timer
  • Camel Quarkus File
  • Camel Quarkus Gson
  • Camel Quarkus Bindy
  • Camel Quarkus Rest
  • Camel Quarkus Http
  • Camel Quarkus Log
  • Camel Caffeine LRUCache

"Generate your application" 버튼을 클릭해 프로젝트를 생성합니다.

다음과 같은 프로젝트 생성 화면에서 생성된 프로젝트 ZIP 파일을 다운로드합니다.

좀더 간편한 방법으로 Quarkus Code Starter 사이트에서 프로젝트를 생성하지 않고, Quarkus Maven plugin 을 이용해 다음과 같이 명령 행에서 프로젝트를 생성하는 방법도 있습니다. 이 방법을 사용하면 좀더 신속하게 프로젝트를 생성할 수 있습니다.

$ mvn io.quarkus:quarkus-maven-plugin:1.4.1.Final:create \
  -DprojectGroupId=com.demo \
  -DprojectArtifactId=quarkus-camel-demo \
  -DprojectVersion=1.0.0 \
  -DclassName="com.demo.UserInfoResource" \
  -Dpath="/userinfo" \
  -Dextensions="
    quarkus-core,
    quarkus-resteasy-jackson,
    camel-quarkus-timer,
    camel-quarkus-file,
    camel-quarkus-gson,
    camel-quarkus-bindy,
    camel-quarkus-rest,
    camel-quarkus-http,
    camel-quarkus-log,
    camel-quarkus-caffeine-lrucache"

위 과정을 마친 후, 선호하는 통합 개발 환경(IDE) 에 프로젝트를 임포트해 개발을 시작합니다.

이 과정을 통해 완성된 프로젝트와 추가된 소스를 확인하려면 필자의 소스를 참조해 주십시오.

Apache Camel DSL

위 통합 유스케이스는 Apache Camel Java DSL 로 다음과 같이 구현할 수 있습니다. (Apache Camel DSL 은 필자의 바른모 블로그Camel in Action 을 참조해 주십시오.)

package com.demo;  
  
import org.apache.camel.Exchange;  
import org.apache.camel.Processor;  
import org.apache.camel.builder.RouteBuilder;  
import org.apache.camel.dataformat.bindy.csv.BindyCsvDataFormat;  
import org.apache.camel.model.rest.RestBindingMode;  
  
import java.util.concurrent.atomic.AtomicInteger;  
  
  
public class CamelRouteBuilder extends RouteBuilder {  
  
  static AtomicInteger readCount = new AtomicInteger();  
  
  public void configure() {  
  
  BindyCsvDataFormat biindy = new BindyCsvDataFormat(com.demo.UserInfo.class);  
  
    restConfiguration()  
      .host("localhost")  
      .port(8080)  
      .jsonDataFormat("json-gson")  
      .bindingMode(RestBindingMode.json);  
  
    from("timer://csv?period=5000")  
      .routeId("csvProducerRoute")  
      .setBody(simple("Gildong,Hong,${date:now}\nWoochi,Jun,${date:now}"))  
      .to("file://input?fileName=userinfo.csv")  
      .log("New userinfo.csv saved.");  
  
    from("file://input?fileName=userinfo.csv&delete=true")  
      .routeId("csvConsumerRoute")  
      .log("Loaded userinfo.csv records\n${body}")  
      .unmarshal(biindy)  
      .split(body())  
      .parallelProcessing()  
      .process(new Processor() {  
        @Override  
        public void process(Exchange exchange) throws Exception {  
          UserInfo userInfo = exchange.getIn().getBody(UserInfo.class);  
          userInfo.setReadCount(readCount.incrementAndGet());  
        }  
     })  
     .log("Call Rest API using ${body} ...")  
     .to("rest:post:userinfo");  
  }  
}

Quarkus 는, 위와 같이 Camel DSL 클래스를 구현만 하면, 애플리케이션 시작 시 Camel DSL 자바 클래스를 자동으로 찾아 실행합니다. Spring Boot 의 경우, 애플리케이션 시작에 Camel DSL 을 실행하기 위해서는, @Service 나 @Component 애노테이션을 Camel DSL 클래스에 지정해 Spring Bean 임을 선언해야 합니다. 그런데 Quarkus 는 이런 애노테이션 지정 없이 클래스가 RouteBuilder 를 상속하면 자동으로 실행됩니다. Quarkus 의 이런 관례는, 처음 Quarkus 를 경험하는 개발자들에게 도리어 혼란을 야기할 수도 있을 것 같습니다. 관례의도 가 조화롭게 잘 정의된 프레임워크가 좋은 프레임워크이기 때문입니다.

Rest API 서비스

위 통합 유스케이스의 Rest API 서비스는 Java EE JAX-RS 표준 애노테이션을 이용해 다음과 같이 구현합니다. (참고로 Lombok 프레임워크도 Quarkus 에서 native image 로 잘 빌드되는지 실험하기 위해 일부러 사용했습니다.)

package com.demo;  
  
import lombok.extern.slf4j.Slf4j;  
  
import javax.ws.rs.Consumes;  
import javax.ws.rs.POST;  
import javax.ws.rs.Path;  
import javax.ws.rs.Produces;  
import javax.ws.rs.core.MediaType;  
  
@Slf4j  
@Path("/userinfo")  
public class UserInfoResource {  
  
  @POST  
 @Consumes(MediaType.APPLICATION_JSON)  
  @Produces(MediaType.APPLICATION_JSON)  
  public UserInfo hello(UserInfo userInfo) {  
 log.info("Received : " + userInfo);  
    return userInfo;  
  }  
}

Quarkus 가 사용하는 Java EE JAX-RS 애노테이션은, Spring Web 애노테이션과 다르지만, 가급적 표준을 따르는 것이 올바른 방법일 것 같기도 합니다. 그럼에도 Quarkus 프로젝트에서 조만간 Spring 호환 애노테이션도 제공할 것으로 보이는 데, 그렇게 되면 두 애노테이션 중 편리한 애노테이션을 사용할 수 있을 것입니다. 참고로 Quarkus 는 기본적으로 Vert.x 기술을 기반해 웹 서비스를 제공한다는 점도 알아두면 유용할 것입니다.

애플리케이션 빌드

Quarkus 를 이용하면 자바 애플리케이션을 세 가지 실행 형태로 빌드할 수 있습니다. 하나는 전통적인 Jar 실행 패키지고, 하나는 Native image 실행 바이너리입니다. 그리고 Container image 로도 빌드합니다.

Jar 빌드

Jar 빌드는 전통적인 자바 빌드 방법으로 아래와 같이 maven 명령을 이용합니다. (-DskipTests 로 테스트 단계를 건너뛰는 옵션을 지정했습니다. 이 옵션을 사용하지 않으면 테스트가 진행됩니다.)

$ ./mvnw package -DskipTests
$ ls -alh target
...
-rw-r--r--    1 jcha  staff   290K  5  5 01:38 quarkus-camel-demo-1.0.0-runner.jar
-rw-r--r--    1 jcha  staff    22K  5  5 01:38 quarkus-camel-demo-1.0.0.jar
drwxr-xr-x  129 jcha  staff   4.0K  5  5 01:38 lib
...
$ du -sh lib
 37M	lib
...

빌드가 성공하면 실행 jar 파일(*-runner.jar), 클래스를 포함한 jar, 그리고 의존 라이브러리를 포함하는 lib 디렉토리가 생성됩니다. 생성된 실행 jar 파일의 크기는 290 KB 크기로, 실제 소스가 컴파일된 jar 22 KB 와 Quarkus 클래스 268 KB 가 포함됩니다. Quarkus 클래스 영역은 애플리케이션이 커져도 동일한 크기를 가질 것입니다. Quarkus 클래스들은 실행 jar 를 실행하면 실제 애플리케이션을 탑재하고 시작시킵니다. 실행은 아래 Jar 패키지 실행을 참조해 주십시오.

Native image 빌드

Native image 빌드는 자바 애플리케이션이 JVM 의존 없는 단일 실행 바이너러로 빌드되는 것을 의미합니다. 즉 단일 실행 바이너리가 JVM 기능을 포함합니다. 빌드 방법은 아래와 같이 Maven 을 이용해 빌드합니다. Jar 빌드와 다른 점은 Maven 빌드에 native 프로파일 옵션인 -Pnative 을 추가로 지정했다는 점입니다. Native image 빌드에 사용하는 Maven native 프로파일은 Quarkus Code Starter 나 Quarkus maven plugin 이 프로젝트 생성할 때 Maven pom.xml 에 자동으로 구성합니다.

$ ./mvnw package -Pnative -DskipTests
...
[quarkus-camel-demo-1.0.0-runner:6453]      [total]: 147,334.21 ms, 11.75 GB
...
$ ls -alh target
drwxr-xr-x    4 jcha  staff   128B  5  5 10:29 quarkus-camel-demo-1.0.0-native-image-source-jar
-rwxr-xr-x    1 jcha  staff    87M  5  5 10:29 quarkus-camel-demo-1.0.0-runner
...
$ file target/quarkus-camel-demo-1.0.0-runner
target/quarkus-camel-demo-1.0.0-runner: Mach-O 64-bit executable x86_64

$ otool -L target/quarkus-camel-demo-1.0.0-runner
target/quarkus-camel-demo-1.0.0-runner:
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.22.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1675.129.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)

Native image 빌드는 상당하 많은 시스템 메모리를 요구합니다. 필자의 개발 PC(MacBook) 빌드에서는 최종적으로 11.75 GB의 시스템 메모리가 사용됐다고 기록이 남았습니다. GraalVM native image 문서를 보면 Native image 빌드를 위해서는 시스템 메모리가 14 GB 이상이 필요하다고 합니다. GraalVM 팀은 빌드 과정 메모리 최적화를 안한 것인지 못하는 것인지 궁금합니다. (이런 이유로 필자의 라즈베리 파이에서는 빌드 환경은 구성 가능했지만 직접적으로 Native image 빌드는 수행할 수 없었습니다. )

빌드가 성공하면 실행 바이너리 파일(*-runner)과 자바 애플리케이션 클래스를 포함한 jar 파일이 생성됩니다. Native image 빌드로 생성된 실행 바이너리는 87 MB 크기로 JVM 기능을 포함합니다. 실행 바이너리는 jar 패키지, 의존 jar, 그리고 JVM 영역을 모두 포함하므로, 애플리케이션 클래스 jar 와 lib 37 MB 을 빼면, 실행 바이너리에서 순수 JVM 영역은 약 50 MB 정도로 볼 수 있을 것입니다.

실행 바이너리 실행 시, 모든 실행 바이너리가 실행 메모리에 적재되지는 않으므로, 실제 시스템 메모리 사용은 실행 바이너리 크기보다 훨씬 적습니다.

필자는 개발 PC 는 MacBook 이므로, 생성된 실행 바리너리를 file 명령을 확인해 본 결과, 파일 형식이 Mach-O 64-bit executable x86_64 인 Native image 파일(*-runner)임을 확인한 수 있었습니다.

CentOS 7 에서도 빌드를 해 보았는데, 이 경우 실행 바이너리의 의존은 다음과 같았습니다.

$ ldd target/quarkus-camel-demo-1.0.0-runner
        linux-vdso.so.1 =>  (0x00007ffdc6f93000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007faa18c05000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007faa189e9000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007faa187e5000)
        libz.so.1 => /lib64/libz.so.1 (0x00007faa185cf000)
        librt.so.1 => /lib64/librt.so.1 (0x00007faa183c7000)
        libc.so.6 => /lib64/libc.so.6 (0x00007faa17ff9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007faa17cf7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007faa18f0c000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007faa17ae1000) 

위 결과로 Native image 로 빌드된 자바 애플리케이션은 플랫폼의 기본 라이브러리들에 의존하고 있음을 알 수 있었습니다. 그런데 만약 자바 애플리케이션의 Native image 영역 중 반드시 최적화가 필요하지 않은 JVM 영역이 플랫폼에 맞도록 공유 라이브러리로 분리될 수 있다면, 자바 애플리케이션의 Native image 크기를 더 줄일 수 있지 않을까 생각해 봅니다.

Container image 빌드

Container image 빌드는 Native image 빌드를 실행한 플랫폼 OS 의 실행 바이너리가 아닌 컨테이너 실행 환경인 Linux 의 실행 바이너리를 생성한다는 점이 다릅니다.
필자는 필자의 개발 PC 에서 Container image 빌드를 하기 위해 Mac 용 “Docker desktop” 을 설치했습니다. 다음은 필자가 사용한 “Docker desktop” 버전은 다음과 같습니다.

Container image 빌드는 Native image 빌드에 -Dquarkus.native.container-build=true 옵션을 추가하면 됩니다.

$ ./mvnw package -Pnative -Dquarkus.native.container-build=true -DskipTests
...
[quarkus-camel-demo-1.0.0-runner:24]      [total]: 181,112.75 ms
[INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 191029ms
...
$ ls -alh target
drwxr-xr-x    4 jcha  staff   128B  5  7 18:57 quarkus-camel-demo-1.0.0-native-image-source-jar
-rwxr-xr-x    1 jcha  staff    89M  5  7 18:57 quarkus-camel-demo-1.0.0-runner
...
$ file target/quarkus-camel-demo-1.0.0-runner
target/quarkus-camel-demo-1.0.0-runner: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=b951368d112bf5a6589d0c6fe8e67712cd9ce87f, with debug_info, not stripped

$ otool -L target/quarkus-camel-demo-1.0.0-runner
llvm-objdump: error: target/quarkus-camel-demo-1.0.0-runner': object is not a Mach-O file type.

위 콘솔 로그에서 보듯이 필자의 개발 PC 에서는 Conatiner image 빌드가 약 3분 정도 소요됐습니다. 그리고 필자의 개발 PC 가 MacBook(macOS) 임에도 불구하고, 생성된 실행 바이너리(*-runner)의 파일 형식은 ELF 64-bit LSB executable 로 컨테이너 이미지에 포함할 수 있는 Linux 용 바이너리가 생성됐습니다. 기대한 대로 생성된 실행 바이너리는 macOS 의 otool 로도 읽을 수 없습니다.

생성된 컨테이너 용 실행 바이너리는 다음 절차를 수행해 최종적으로 컨테이너 이미지로 빌드합니다.

$ docker build -f src/main/docker/Dockerfile.native -t quarkus/quarkus-camel-demo .
...
Successfully built 7a6b92b9eaa3
Successfully tagged quarkus/quarkus-camel-demo:latest
$ docker images                                                                    
REPOSITORY                                                           TAG                 IMAGE ID            CREATED              SIZE
quarkus/quarkus-camel-demo                                           latest              7a6b92b9eaa3        About a minute ago   294MB
registry.access.redhat.com/ubi8/ubi-minimal                          8.1                 91d23a64fdf2        5 weeks ago         107MB

...

최종적으로 생성된 자바 애플리케이션 컨테이너 이미지는 294MB 크기입니다. 이 컨테이너 이미지의 베이스 이미지인 레드햇 유니버셜 베이스 이미지(ubi-minimal:8.1)는 107 MB 입니다.

애플리케이션 실행

이 글에서 자바 애플리케이션은 세 가지 형태로 빌드됐습니다. 하나는 전통적인 Jar 패키지이고 다른 하나는 Native image 이고, 마지막으로 Container image 입니다. 각각의 실행 방법은 다음과 같습니다.

Jar 애플리케이션 실행

다음은 필자의 개발 PC 에서 빌드된 jar 실행 패키지 자바 애플리케이션을 실행한 결과입니다.

$ java -jar target/quarkus-camel-demo-1.0.0-runner.jar
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2020-05-05 01:38:39,595 INFO  [org.apa.cam.sup.LRUCacheFactory] (main) Detected and using LURCacheFactory: camel-caffeine-lrucache
2020-05-05 01:38:39,800 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) is starting
2020-05-05 01:38:39,802 INFO  [org.apa.cam.imp.eng.DefaultManagementStrategy] (main) JMX is disabled
2020-05-05 01:38:39,889 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2020-05-05 01:38:40,056 INFO  [org.apa.cam.com.htt.HttpComponent] (main) Created ClientConnectionManager org.apache.http.impl.conn.PoolingHttpClientConnectionManager@6724cdec
2020-05-05 01:38:40,115 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvProducerRoute started and consuming from: timer://csv
2020-05-05 01:38:40,120 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvConsumerRoute started and consuming from: file://input
2020-05-05 01:38:40,125 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Total 2 routes, of which 2 are started
2020-05-05 01:38:40,127 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) started in 0.325 seconds
...

Quakus 로 빌드한 Jar 실행 패키지 자바 애플리케이션의 시작 시간은 0.325 초였습니다. 일반적으로 자바 애플리케이션의 시작은 JVM 의 실행 초기화와 프레임워크의 초기화를 포함합니다. 그러므로 최소한 수 초 정도 시작 시간이 필요합니다. 그런데 이 과정도 Qurkus 는 최적해 실행 패키지의 시작 시간이 개선됐음을 볼 수 있었습니다.

Native image 애플리케이션 실행

다음은 필자의 개발 PC 에서 Native image 자바 애플리케이션을 실행한 결과입니다.

$ ./target/quarkus-camel-demo-1.0.0-runner              
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2020-05-05 12:51:21,838 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) is starting
2020-05-05 12:51:21,838 INFO  [org.apa.cam.imp.eng.DefaultManagementStrategy] (main) JMX is disabled
2020-05-05 12:51:21,842 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2020-05-05 12:51:21,844 INFO  [org.apa.cam.com.htt.HttpComponent] (main) Created ClientConnectionManager org.apache.http.impl.conn.PoolingHttpClientConnectionManager@1127f7828
2020-05-05 12:51:21,851 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvProducerRoute started and consuming from: timer://csv
2020-05-05 12:51:21,851 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvConsumerRoute started and consuming from: file://input
2020-05-05 12:51:21,851 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Total 2 routes, of which 2 are started
2020-05-05 12:51:21,851 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) started in 0.013 seconds
...

애플리케이션 실행 결과, Native image 형식으로 빌드한 자바 애플리케이션의 시작 시간은 0.013 초였습니다. 즉 Native image 자바 애플리케이션은 약 13 밀리초 만에 시작을 완료했습니다. 일반적인 자바 애플리케이션은 시작 시간이 수 초 이상입니다. 이 결과로 Native image 로 빌드된 자바 애플리케이션은 기존의 자바 애플리케이션보다 약 100 배 시작 시간이 빨라짐을 확인할 수 있었습니다.

애플리케이션의 실행 시간 (및 종료 시간) 이 빨라지면 신속한 배포가 가능하고, 배포에 따른 중단 시간을 단축할 수 있습니다. 이런 기술적 특징은 Serverless 등 컨테이너 기술에 필수적 조건입니다.

Container image 애플리케이션 실행

다음은 필자의 개발 PC 에서 빌드된 자바 애플리케이션 컨테이너 이미지를 실행한 결과입니다.

$ docker run -i --rm -p 8080:8080 quarkus/quarkus-camel-demo
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2020-05-07 10:19:24,690 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) is starting
2020-05-07 10:19:24,690 INFO  [org.apa.cam.imp.eng.DefaultManagementStrategy] (main) JMX is disabled
2020-05-07 10:19:24,692 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2020-05-07 10:19:24,693 INFO  [org.apa.cam.com.htt.HttpComponent] (main) Created ClientConnectionManager org.apache.http.impl.conn.PoolingHttpClientConnectionManager@7f9091eb2868
2020-05-07 10:19:24,699 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvProducerRoute started and consuming from: timer://csv
2020-05-07 10:19:24,699 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvConsumerRoute started and consuming from: file://input
2020-05-07 10:19:24,700 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Total 2 routes, of which 2 are started
2020-05-07 10:19:24,701 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: camel-1) started in 0.010 seconds
2020-05-07 10:19:24,707 INFO  [io.quarkus] (main) =quarkus-camel-demo 1.0.0 (powered by Quarkus 1.4.1.Final) started in 0.027s. 
...

Container image 실행 결과도 Native image 형식으로 빌드한 자바 애플리케이션의 시작 시간은 0.013 초과 유사하게 0.027 초 였습니다. 즉 Container image 자바 애플리케이션은 약 27 밀리초 만에 시작을 완료했습니다. Native image 를 컨테이너 이미지로 빌드하면서 컨테이너 시작 단계가 포함돼 순수 Native image 시작 시간보다 길어지긴 했지만, Quarkus 를 이용해 Native image 을 Container image 로 전환한 자바 애플리케이션은 초 당 40 개 정도 실행 할 수 있다는 가능성을 확인할 수 있었습니다.

애플리케이션 실행 시간 비교

Quarkus 를 이용한 자바 애플리케이션 빌드 실행 시간 실험은 다음과 다음 결과로 요약됩니다.

빌드 결과물 시작 시간 설명
Jar 패키지 0.325 초 초당 3 개 애플리케이션 실행 가능
Native image 0.013 초 초당 80 개 애플리케이션 실행 가능
Container image 0.027 초 초당 40 개 애플리케이션 실행 가능

Qurakus 프로젝트 웹 사이트 설명

Quarkus 프로젝트에서 설명한 응답 시간 자료도 이번 실험 결과와 유사한 결과를 설명하고 있었습니다.

애플리케이션 메모리

Jar 애플리케이션

애플리케이션 메모리 상태를 확인하기 위해 Quarkus 를 이용해 빌드한 Jar 애플리케이션의 실행합니다.

$ java -jar target/quarkus-camel-demo-1.0.0-runner.jar
...

다른 실행 창에서 Jar 애플리케이션 메모리 사용을 확인합니다.

$ ps x -o pid,rss,vsz,command | grep quarkus-camel-demo-1.0.0-runner.jar
28338 342832 25454416 /usr/bin/java -jar target/quarkus-camel-demo-1.0.0-runner.jar

상주 메모리는 약 334 MB, 가상 메모리는 약 24 GB 정도 사용하는 것으로 표시됐습니다.

아래는 필자의 개발 PC 자원 모니터링 화면에서 본 Jar 애플리케이션의 메모리 사용 현황입니다.

위 결과는 271.9 MB 로 표시됐습니다.

Native image 애플리케이션

애플리케이션 메모리 상태를 확인하기 위해 Quarkus 를 이용해 생성한 생성한 Native image 애플리케이션을 실행합니다.

$ target/quarkus-camel-demo-1.0.0-runner
...

다른 실행 창에서 Native image 애플리케이션 메모리 사용을 확인합니다.

$ ps x -o pid,rss,vsz,command | grep quarkus-camel-demo-1.0.0-runner
28521  51016  4746796  target/quarkus-camel-demo-1.0.0-runner

상주 메모리는 약 51 MB, 가상 메모리는 약 4.6 GB 정도 사용하는 것으로 표시됐습니다.

아래는 필자의 개발 PC 자원 모니터링 화면에서 본 Jar 애플리케이션의 메모리 사용 현황입니다.

위 결과는 31.3 MB 로 표시됐습니다.

Native image 자바 애플리케이션은 Jar 애플리케이션보다 9 배 정도 적은 메모리로 구동되는 것을 확인 할 수 있었습니다. 그러므로 동일한 기능을 하는 애플리케이션을 Native image 로 빌드해 실행하면 동일 장비에 9 배 이상 밀집도를 갖고 실행 할 수 있으므로, Native image 빌드는 시스템 자원 효율을 9 배 이상 향상시킨다고 볼 수 있습니다.

애플리케이션 실행 메모리 비교

Quarkus 를 이용한 자바 애플리케이 빌드 메모리 사용은 실험은 다음과 다음 결과로 요약됩니다.

빌드 결과물 사용 메모리 설명
Jar 패키지 334 MB 일반적인 자바 애플리케이션 사용 메모리
Native image 51 MB 6 배 절감된 메모리 사용

Qurakus 프로젝트 웹 사이트 설명

Quarkus 프로젝트에서 설명한 메모리 자료도 이번 실험 결과와 유사한 결과를 설명하고 있었습니다.

라즈베리 파이(Raspberry PI)

자바 애플리케이션을 적은 메모리로 빠르게 실행할 수 있다면 , 라즈베리 파이 같은 사물 인터넷(IOT) 장비의 언어로 자바 언어가 상당히 매력적인 언어가 될 수 있을 것입니다. 필자는 이런 생각을 기반으로 Quarkus 개발 환경을 라즈베리 파이에 구성해 동일한 애플리케이션을 빌드해 시도해 보았습니다. 그러면서 아래와 같은 문제를 만났습니다.

  • 라즈베리 파이 32bit OS
  • ARM 프로세서
  • 시스템 메모리 한계 (최대 4 GB)

위 문제 중 32bit OS 문제는 라즈베리파이 용 Ububtu 64bit OS 를 설치해서 해결했고, ARM 프로세서 문제는 ARM 기반 Open JDK 11, GraalVM 을 설치해 해결했습니다. 그러나 시스템 메모리 부족 문제로 Native image 빌드는 라즈베리 파이 내에서 완료할 수 없었습니다. (그 이유는 Native image 빌드를 위해서는 14 G 이상의 시스템 메모리가 필요하기 때문입니다.) 그러나 ARM 기반 서버도 최근에는 쉽게 구할 수 있으므로 메모리가 충분한 ARM 기반 서버에서 Native image 를 생성해 라즈베리파이에서 실행하면 되므로 굳이 라즈베리 파이에서 Native image 빌드까지 하지 않더라도 활용하는 대는 문제가 없을 것으로 보입니다. 그러므로 자바 언어는 라즈베리 파이와 같은 IOT 영역에서도 곧 큰 힘을 발휘할 때가 올 것으로 전망합니다.

다음은 라즈베리 파이에서 Quarkus 로 통합 애플리케이션을 빌드한 결과입니다.

$ ls -alh target/
...
-rw-rw-r--  1 ubuntu ubuntu 278K  5월  4 13:25 quarkus-camel-demo-1.0.0-runner.jar
-rw-rw-r--  1 ubuntu ubuntu 8.9K  5월  4 14:12 quarkus-camel-demo-1.0.0.jar
drwxrwxr-x  2 ubuntu ubuntu  16K  5월  4 13:25 lib
...
$ du -sh target/lib
37M     target/lib

Quarkus 로 Jar 실행 패키지 빌드 결과는 macOS 나 CentOS 나 크게 다르지 않았습니다. 이 결과는 자바 언어가 플랫폼 독립적이라는 점을 잘 보이고 있는 것입니다.

다음은 라즈베리 파이에서 Jar 패키지 통합 애플리케이션을 실행한 결과입니다.

$ java -jar target/quarkus-camel-demo-1.0.0-runner.jar 
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2020-05-05 01:32:44,508 INFO  [org.apa.cam.sup.LRUCacheFactory] (main) Detected and using LURCacheFactory: camel-caffeine-lrucache
2020-05-05 01:32:49,434 INFO  [org.apa.cam.mai.BaseMainSupport] (main) Auto-configuration summary:
2020-05-05 01:32:49,438 INFO  [org.apa.cam.mai.BaseMainSupport] (main)  camel.context.name=quarkus-camel-demo
2020-05-05 01:32:49,669 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: quarkus-camel-demo) is starting
2020-05-05 01:32:49,682 INFO  [org.apa.cam.imp.eng.DefaultManagementStrategy] (main) JMX is disabled
2020-05-05 01:32:50,590 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2020-05-05 01:32:52,444 INFO  [org.apa.cam.com.htt.HttpComponent] (main) Created ClientConnectionManager org.apache.http.impl.conn.PoolingHttpClientConnectionManager@2436ea2f
2020-05-05 01:32:53,352 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvProducerRoute started and consuming from: timer://csv
2020-05-05 01:32:53,390 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Route: csvConsumerRoute started and consuming from: file://input
2020-05-05 01:32:53,416 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Total 2 routes, of which 2 are started
2020-05-05 01:32:53,428 INFO  [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.1.0 (CamelContext: quarkus-camel-demo) started in 3.749 seconds
...

라즈베리 파이에서 애플리케이션의 시작 시간은 3.749 초가 걸렸습다. 개발 PC 의 시작 시간 0.325 초에 비해 길지만 라즈베리 파이 환경에서 4초 이내 자바 애플리케이션이 완전히 실행됐다는 점에서 의미있는 시작 시간으로 볼 수 있습니다.
필자는 별도의 ARM 서버를 준비하지 못해, 라즈베리 파이에서 Native image 애플리케이션을 실행해 보지 못했지만, Native image 자바 애플리케이션을 라즈베리 파이에서 실행한다면, 시작 시간은 1초 이내고 메모리도 수십 MB 로 실행될 것을 예상할 수 있을 것입니다. 이 정도 실행 속도와 자원 사용 환경이라면, IOT 에서도 충분히 의미있는 애플리케이션을 개발, 운영할 수 있을 것입니다. 즉 자바 언어가 만든 유용한 라이브러리와 프레임워크 등을 IOT 영역에 도입하는데 큰 장애물이 사라졌다고 볼 수 있을 것입니다.

참고로 ARM 서버는 Amazon EC2 A1 인스턴스 에서 저렴하게 임대할 수 있습니다. 라즈베리 파이에서 Native image 자바 애플리케이션 실행의 검증은 관심있는 독자에게 맡깁니다.

맺음말

GraalVM 이 등장하면서, 자바 컴파일 방식에 큰 발전이 일어났습니다. 지금까지 자바 컴파일러가 바이트 코드를 생성했다면, GraalVM 컴파일러는 바이트 코드 뿐만 아니라, native image 를 생성할 수도 있게 됐습니다. 이에 따라 native image 자바 애플리케이션은 C 나 Golang 언어만큼 시작 속도와 메모리 사용이 빨라지고 작아지게 됐습니다.

지금까지 자바 언어는 JVM 에 의존하면서 서버 애플리케이션이으로서 탄탄한 상태계를 구축했지만, 컨테이너 시대가 도래하고, 새로운 언어들이 등장하고 발전하는 데, 느린 시작 시간과 많은 메모리 사용으로 유용성이 제한되는 문제가 있었습니다. 그러나 이제는 자바 언어가 native image 로 동작 가능하게 되면서, 컨테이너 시대에도 빠른 시작 시간과 적은 메모리 사용으로, 주력 언어의 지위를 계속 이어 갈 수 있게 됐습니다.

Quarkus 는 자바 언어를 컨테이너 시대에 사용하기 편리하게 해주는 프레임워크입니다. Spring Boot 가 웹 서버를 내장하면서 WAS(Web Application Server) 를 벗어나 자바 MSA(Microservice Architecture) 에 주력 프레임워크가 됐듯이, Quarkus 는 현재도 여전히 발전하는 프로레임워크로 Spring Boot 와 유사한 기능을 제공하고, native image 빌드를 위한 확장을 제공하므로, 컨테이너 MSA 환경에서 중요한 프레임워크가 될 것으로 기대해 봅니다.

Apache Camel 은 EIP(Enterprise Integration Patters) 의 구현체인 통합 프레임워크로 Spring Boot 뿐만 아니라 Quarkus 와도 잘 결합돼 컨테이너 MSA 환경에서 레거시 통합 및 MSA 통합에 주요한 프레임워크입니다. 더불어 Qurakus 기술과 결합해 MSA 통합에서 IOT 통합까지 다양한 응용 분야에서 중요한 기술로서 가능성이 있습니다.

필자가 GraalVM 기술을 처음 접했을 때, 왜 이 기술이 나올 때까지 20년 (자바 언어는 1995년 탄생) 이상이 걸렸는지 의아하기도 하고 또 반가웠습니다. 이제 자바로 Golang 처럼 빠른 실행과 적은 메모리를 사용하는 애플리케이션을 개발할 수 있다는 점은 자바 언어가 앞으로 10년 이상 건재할 것이라는 것을 의미하기 때문입니다.

GraalVM, Quarkus, Apache Camel, 그리고 Spring Boot 도 자바를 native image 세계로 인도하고 있습니다. 물론 아직은 완전히 성숙됐다고 볼 수 없어 실제 기술 검토를 하면, 여러 가지 문제를 만나게 됩니다. 그럼에도 지속적으로 발전하고 편해지고 있습니다. 그 중 Red Hat 은 Quarkus 와 Apache Camel 을 서브스크립션을 통해 기술 지원하므로 커뮤니티 오픈소스를 직접 사용함에 따른 다양한 시행착오와 기술 문제의 해결을 지원 받을 수 있다는 점은, 이 기술에 관심을 가진 기업이 비즈니스 애플리케이션에 이용하는 데 장벽을 낮춰줄 수 있을 것입니다. 이 글을 읽는 독자가 이 새로운 변화에 관심을 갖는다면 분명 이 시대 누구보다 앞선 엔지니어가 될 수 있을 것입니다.

사마천 사기 상군(商君) 열전 에 이런 말이 나옵니다.

기구일지라도 그 효용이 10 배가 되는 것이 아니면 바꾸지 않는 법이다.

끝으로 GraalVM 과 Qurakus 그리고 Apache Camel 의 결합은 10 배 이상의 효용을 줄 수 있을 것이라 감히 이야기 해봅니다.

참고 자료

  1. Quarkus Apache Camel Demo Source
  2. GraalVM
  3. GraalVM Downloads
  4. Quarkus
  5. Red Hat Qurakus
  6. Quarkus Getting Started
  7. Quarkus Code Starter
  8. Apache Camel
  9. Red Hat Fuse
  10. Camel in Action
  11. 기업 통합 패턴(Enterprise Integration Patterns)
  12. 바른모 블로그
  13. Spring Boot
  14. CentOS
  15. Raspberry PI
  16. Ubnutu server on Raspberry PI
  17. Docker desktop
  18. Windows 10 WSL2 설치 지침
  19. Amazon EC2 A1 인스턴스