Eraser's ProjectLog

[3] Nginx를 이용한 이미지 서버 ⎻ Nginx 기본 설정 파일 작성

eraser — Mon, 6 Jun 2022 18:45:38 +0900

업로드, 다운로드, 삭제 기능 등을 구현하기 전에 이미지 서버의 웹 서버인 Nginx의 설정을 해 준다.

# Nginx 설정 파일 디렉토리 확인

/etc/nginx 디렉토리에서 Nginx 설정을 위해 사용할 디렉토리 및 폴더는 다음과 같다.

/etc/nginx# ls -al
total 88
drwxr-xr-x 1 root  root  4096 Apr 21 17:22 .
drwxr-xr-x 1 root  root  4096 Apr 26 19:06 ..
drwxr-xr-x 1 nginx nginx 4096 Apr 26 19:06 conf.d # include될 config 파일들
-rw-r--r-- 1 root  root  1077 Apr 21 17:22 fastcgi.conf 
-rw-r--r-- 1 root  root  1077 Apr 21 17:22 fastcgi.conf.default
-rw-r--r-- 1 root  root  1007 Apr 21 17:22 fastcgi_params # 업로드, 다중 업로드, 삭제 fastcgi
-rw-r--r-- 1 root  root  1007 Apr 21 17:22 fastcgi_params.default
-rw-r--r-- 1 root  root  2837 Apr 21 17:22 koi-utf
-rw-r--r-- 1 root  root  2223 Apr 21 17:22 koi-win
-rw-r--r-- 1 root  root  5231 Apr 21 17:22 mime.types # 다운로드 시 필요한 미디어 타입
-rw-r--r-- 1 root  root  5231 Apr 21 17:22 mime.types.default
-rw-rw-r-- 1  1000  1000  547 Apr 26 19:55 nginx.conf
-rw-r--r-- 1 root  root  2656 Apr 21 17:22 nginx.conf.default
-rw-r--r-- 1 root  root   636 Apr 21 17:22 scgi_params
-rw-r--r-- 1 root  root   636 Apr 21 17:22 scgi_params.default
-rw-r--r-- 1 root  root   664 Apr 21 17:22 uwsgi_params
-rw-r--r-- 1 root  root   664 Apr 21 17:22 uwsgi_params.default
-rw-r--r-- 1 root  root  3610 Apr 21 17:22 win-utf

## fastcgi.conf

설정 파일 중 fastcgi.conf 파일을 볼 수 있는데, Nginx에서 fastcgi 모듈을 사용할 때 필요한 FastCGI 관련 설정이 모여 있다. fastcgi_param은 Nginx ngx_http_fastcgi_module이 FastCGI 규약에 따라 FastCGI 프로세스(실제 구현 상에서는 fcgiwrap 프로그램)에 전달해야 할 변수를 나타내는 지시자이다. 이후 fcgiwrap 프로세스에서 이 변수 값들에 접근할 수 있다.

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

## mime.types

확장자별 미디어 타입을 규정하는 mime.types 파일도 볼 수 있다. 업로드 및 다운로드 시 확장자를 보고 미디어 타입을 추론할 때 사용할 것이다. 특히, 다운로드 시 응답 헤더의 Content-Type이 확장자에 맞게 설정된다.

types {

    (...)
    image/png                                        png;
    image/svg+xml                                    svg svgz;
    image/tiff                                       tif tiff;
    image/vnd.wap.wbmp                               wbmp;
    image/webp                                       webp;
    image/x-icon                                     ico;
    image/x-jng                                      jng;
    image/x-ms-bmp                                   bmp;
    (...)
}

# Nginx.conf

Nginx 웹 서버 구동 시 기본적으로 필요한 설정 항목들을 작성한다.

worker_processes: Nginx master process가 관리할 worker process의 수를 설정한다. auto로 설정하면 자동으로 할당된다. 보통 Nginx 웹 서버 성능 튜닝에 관한 글을 보면, CPU core 수의 80~90% 정도로 설정하는 것이 좋다고 한다
error_log: nginx 웹 서버 error log 레벨을 설정한다. 개발 시 편의를 위해 debug 레벨로 설정해 뒀는데, 로그 출력량이 info 레벨 수준과 비교가 안 되게 많아진다(;;). 성능 튜닝 시 로그 레벨도 중요한 포인트가 될 듯하다
worker_connections: 이벤트 처리 시 최대 동시 접속 수라고 하는데, 기본값으로 뒀다
http: http 어플리케이션 특정 도메인이나 IP 주소로의 요청을 처리할 블록으로, 여기서 다른 설정 값들을 include한다
- mime.types: 업로드, 다운로드 시 파일 미디어 타입 처리를 위한 값들이 미리 규정되어 있는데, 이를 포함한다
- http.conf: http 어플리케이션 설정 파일을 포함하도록 설정한다

user  nginx; # nginx user 설정
worker_processes auto; # nginx worker process 수 설정

error_log /var/log/nginx/error.log debug; # nginx 에러 로그 설정

events {
    worker_connections  1024; # nginx worker process 1개 당 최대 동시 접속 수
}

http {    

    # 미디어 타입 설정
    include mime.types;
    
    # 하위 설정
    include conf.d/http.conf;
}

## http.conf

실제 요청 처리에 필요한 설정을 작성한다. 이후 개발을 통해 API 엔드 포인트 별로 설정되어야 할 항목들을 빈 칸으로 남겨 둔다. 다만, 실제 개발 시 빈 칸으로 남겨 두고 파일을 실행하면 오류가 날 수 있으므로, listen 블록 외에 채워지지 않은 설정 항목은 주석 처리하는 것이 좋다.

listen: 이미지 서버는 ipv4, ipv6 8888 포트로 오는 요청을 대기한다
location: 요청을 처리할 서버 블록
- ~ \.py$: .py로 끝나는 엔드포인트에서는 이미지 서버 동적 요청 처리를 위한 python script를 실행한다. python script 실행을 위한 fastcgi.conf 항목을 포함해 준다.
- /images/upload: 이미지 단건 업로드록를 처리할 서버 블록이다. upload module을 이용해 파일을 디스크에 저장한 뒤, 이미지가 저장될 디렉토리의 계층화, 이미지 id 발급 등을 위한 스크립트를 호출할 것이다.
- /images/upload_many: 이미지 다중 업로드를 처리할 서버 블록이다. upload module을 이용해 파일을 디스크에 저장한 뒤, 각각의 이미지가 저장될 디렉토리의 계층화, 이미지 id 발급 등을 위한 스크립트를 호출할 것이다.
- /images/download/: 이미지 다운로드를 처리할 서버 블록이다. /images/{image_id} 엔드 포인트로 image_id를 path variable로 하여 요청을 보내면, path variable을 디렉토리 계층별로 분리하고, 파일시스템의 해당 디렉토리에서 이미지 파일을 찾아 반환할 것이다.
- /images/delete/: 이미지 삭제를 처리할 서버 블록이다. /images/delete/{image_id} 엔드 포인트로 image_id를 path variable로 하여 요청을 보내면, path variable을 디렉토리 계층별로 분리하고, 파일 시스템의 해당 디렉토리에서 이미지 파일을 찾아 삭제하는 스크립트를 호출할 것이다.

server {
    listen 8888;
    listen [::]:8888;

    # CGI python scripts
    location ~ \.py$ {
        include conf.d/fastcgi.conf;
    }

    # 이미지 단건 업로드 엔드포인트
    location /images/upload {
        # 단건 업로드 처리를 위한 설정 항목
    }

    # 이미지 다중 업로드
    location /images/upload_many {
       # 다중 업로드 처리를 위한 설정 항목 
    }

    # 이미지 다운로드
    location /images/download/ {
       	# 다운로드 처리를 위한 설정 항목
    }

    # 이미지 삭제
    location /images/delete {
        # 삭제 처리를 위한 설정 항목
    }
}

[2] Nginx를 이용한 이미지 서버 ⎻ Nginx(w/ upload module), fcgiwrap 설치

eraser — Mon, 6 Jun 2022 13:46:17 +0900

개발을 위해 이미지 서버 구축에 필요한 스택을 설치한다. 개발 환경은 Ubuntu 20.04.이다.

# Nginx 설치

Nginx 소스 코드로부터 nginx-upload-module을 함께 컴파일해서 설치한다. Nginx는 C로 개발되어 있으므로, gcc 등 C 컴파일 관련 라이브러리가 설치되어 있어야 한다.

## Nginx 의존 라이브러리 설치

Nginx를 실행하기 위해서는 기본적으로 pcre, openssl, zlib 등의 라이브러리가 필요하다. 패키지 매니저를 통해 설치해도 되지만(추후 Dockerfile 작성 시에는 이 방법을 사용하였다), 애초에 컴파일해서 설치하는 김에 의존 라이브러리도 컴파일하는 방식으로 설치해보기로 하였다.

Nginx 설치 시 빌드 경로 설정을 쉽게 하기 위하여, /usr/src/temp 경로 밑에서 진행했다.

1. pcre

perl 정규식 관련 라이브러리라고 한다. Nginx에서 정규식이 필요한 부분(url 관련 설정?)에서 사용하는 듯하다. 소스코드를 다운받고 실행 파일을 만들어 설치하면 되는데, Nginx 공식 문서에 나와 있는 것과는 pcre 소스코드 위치가 달라진 듯하다.

$ cd /usr/src/temp
$ wget https://sourceforge.net/projects/pcre/files/pcre/pcre-8.44.tar.gz
$ tar -zxf pcre-8.44.tar.gz
$ cd pcre-8.44
$ ./configure
$ make
$ sudo make install

2. zlib

C로 작성된 데이터 압축 관련 라이브러리라고 한다. Nginx에 gzip 등 컨텐츠 압축 설정을 할 수 있다고 하는데, 이 때 사용하는 듯하다. Nginx 공식 문서를 따라 진행하면 된다.

$ cd /usr/src/temp
$ wget http://zlib.net/zlib-1.2.11.tar.gz
$ tar -zxf zlib-1.2.11.tar.gz
$ cd zlib-1.2.11/
$ ./configure
$ make
$ sudo make install

3. openssl

TLS, SSL 등 네트워크 데이터 통신에 쓰이는 프로토콜의 오픈소스 구현 라이브러리라고 한다. Nginx에서 HTTPS 프로토콜을 사용하기 위해 필요하다고 한다.

$ cd /usr/src/temp
$ wget http://www.openssl.org/source/openssl-1.1.1g.tar.gz
$ tar -zxf openssl-1.1.1g.tar.gz
$ cd openssl-1.1.1.g
$ ./Configure linux-x86_64 --prefix=/usr # /usr 디렉토리 밑에 openssl 헤더 파일 위치
$ make
$ sudo make install

## upload module 소스 코드 다운

Nginx-upload-module 소스 코드를 받은 후, 압축 해제한다. 아래 명령어를 따를 경우, 압축 파일은 2.3.0.tar.gz라는 이름으로 다운로드되고, 해당 파일을 tar 명령어를 통해 압축 해제하면 nginx-upload-module-2.3.0 이름의 폴더가 생성된다.

$ cd /usr/src/temp
$ wget ttps://github.com/vkholodkov/nginx-upload-module/archive/2.3.0.tar.gz
$ tar -xzvf ${pwd}/2.3.0.tar.gz # 압축 파일은 버전명만으로 다운로드됨

## Nginx 설치

Nginx 1.20.2. 버전의 소스 코드를 다운로드한 후, 의존 라이브러리 및 upload module의 경로와 함께 빌드 옵션을 설정한다. 의존 라이브러리 및 upload module 경로가 핵심이지만, 다른 빌드 옵션을 설정할 수도 있다(Nginx path 관련 설정, gcc 컴파일러 옵션 등을 모두 설정할 수 있다).

아래 설정을 따르면, Nginx를 pcre, zlib, ssl, upload module과 함께 설치하게 되며, Nginx 에러 로그 출력 시 debug 옵션을 설정할 수 있게 된다. 또한, Nginx 프로그램 소유자 및 소유 그룹이 모두 nginx로 설정된다.

$ cd /usr/src/temp
$ wget https://nginx.org/download/nginx-1.20.2.tar.gz
$ tar -zxf nginx-1.20.2.tar.gz
$ cd nginx-1.20.2
$ .configure \
--with-pcre=../pcre-8.44 \
--with-zlib=../zlib-1.2.11 \
--with-openssl=../openssl-1.1.1g \
--add-module=../nginx-upload-module-2.3.0 \ # upload module 추가
--with-debug
--user=nginx
--group=nginx

빌드 옵션 설정까지 완료되면, 설치하면 된다. 설치 과정 중간에 addon으로 upload 모듈이 들어가는 것이 보이면 된다.

$ make
$ make install

>> (...)
>> objs/src/http/modules/ngx_http_upstream_random_module.o \
>> objs/src/http/modules/ngx_http_upstream_keepalive_module.o \
>> objs/src/http/modules/ngx_http_upstream_zone_module.o \
>> .objs/addon/nginx-upload-module-2.3.0/ngx_http_upload_module.o \
>> objs/ngx_modules.o \
>> -ldl -lpthread -lcrypt ../tmp/pcre-8.44/.libs/libpcre.a -lssl -lcrypto -ldl -lpthread ../tmp/zlib-1.2.11/libz.a \
>> (...)

설치 후 nginx 명령어를 통해 Nginx를 실행한다. 오류 없이 실행되고, 브라우저에서 http://localhost로 접속했을 때 다음과 같은 화면이 나오면 된다.

$ nginx

ㅎㅇㅎㅇ

## nginx 설정 파일 위치

설치 후 /etc/nginx 디렉토리에 가면 nginx 설정 관련 파일들이 모여 있는 것을 확인할 수 있다. 앞으로 이미지 서버를 개발하며 필요한 nginx 관련 설정 파일들은 이 아래에 작성하게 될 것이다.

nginx.conf: nginx 기본 설정 파일. 로그, nginx 프로세스 관련 설정 등을 담게 될 것
conf.d/: include할 nginx config 파일 모음. 소스 코드(https://projectlog-eraser.tistory.com/65) 상 config/ 안에 들어갈 설정 파일들이 conf.d/ 아래 위치하게 된다

/etc/nginx# ls -al
total 88
drwxr-xr-x 1 root  root  4096 Apr 21 17:22 .
drwxr-xr-x 1 root  root  4096 Apr 26 19:06 ..
drwxr-xr-x 1 nginx nginx 4096 Apr 26 19:06 conf.d
-rw-r--r-- 1 root  root  1077 Apr 21 17:22 fastcgi.conf
-rw-r--r-- 1 root  root  1077 Apr 21 17:22 fastcgi.conf.default
-rw-r--r-- 1 root  root  1007 Apr 21 17:22 fastcgi_params
-rw-r--r-- 1 root  root  1007 Apr 21 17:22 fastcgi_params.default
-rw-r--r-- 1 root  root  2837 Apr 21 17:22 koi-utf
-rw-r--r-- 1 root  root  2223 Apr 21 17:22 koi-win
-rw-r--r-- 1 root  root  5231 Apr 21 17:22 mime.types
-rw-r--r-- 1 root  root  5231 Apr 21 17:22 mime.types.default
-rw-rw-r-- 1  1000  1000  547 Apr 26 19:55 nginx.conf
-rw-r--r-- 1 root  root  2656 Apr 21 17:22 nginx.conf.default
-rw-r--r-- 1 root  root   636 Apr 21 17:22 scgi_params
-rw-r--r-- 1 root  root   636 Apr 21 17:22 scgi_params.default
-rw-r--r-- 1 root  root   664 Apr 21 17:22 uwsgi_params
-rw-r--r-- 1 root  root   664 Apr 21 17:22 uwsgi_params.default
-rw-r--r-- 1 root  root  3610 Apr 21 17:22 win-utf

# fcgiwrap 설치

fcgiwrap은 패키지 매니저를 통해 설치하면 된다.

$ apt-get update
$ apt-get install fcgiwrap

설치하면 fcgiwrap 프로세스를 spawn할 수 있는 spawn-fcgi 프로그램이 같이 설치되는데, 이미지 서버에서 이 프로세스를 이용할 수 있도록 fcgiwrap 프로세스를 아래 명령어를 이용해 spawn한다.

spawn-fcgi \
-s /var/run/fcgiwrap.socket \ # fcgiwrap unix domain socket
-a "0.0.0.0" \
-u 102 -g 102 -U 102 -G 102 \ # fcgiwrap user, group 설정
-M 766 /usr/sbin/fcgiwrap

fcgiwrap의 기본 user, group은 www-data인데, 나중에 nginx와 user, group이 달라 에러가 발생하는 것을 막기 위해(https://sirzzang.github.io/dev/Dev-fcgiwrap-python/#%EA%B6%8C%ED%95%9C-%EA%B4%80%EB%A0%A8-%EB%AC%B8%EC%A0%9C) nginx user id, nginx group id를 이용해 fcgiwrap의 user, group을 변경해 준다. nginx user, nginx group의 id가 무엇인지 /etc/passwd, /etc/group에서 확인한 후 진행한다.

기타 옵션은 spawn-fcgi documentation에서 확인할 수 있다.

[1] Nginx를 이용한 이미지 서버 ⎻ 개요

eraser — Mon, 6 Jun 2022 13:43:54 +0900

회사에서 서비스에 필요한 이미지 파일의 업로드, 다운로드, 삭제 등의 기능을 담당하는 이미지 서버를 개발하는 프로젝트를 진행했다. 이미지 서빙을 WAS에서 겸할 수도 있지만, 정적 파일 서빙에 대한 것은 어플리케이션 기능과는 분리되는 것이 맞다고 보여 별도의 웹 서버를 두고 해당 웹 서버에서 이미지 업로드, 다운로드, 삭제 요청을 처리하기로 하였다.

웹 서버에서 파일 업로드, 삭제 등과 같은 동적 기능을 구현하기 위해 CGI 방식을 이용했다. ~~(아마존 S3 따라잡기라는 원대한 꿈을 가지고 시작했으나(...) 수많은 시행착오를 겪고)~~ 웹 서버를 이용해 정적 파일 업로드, 다운로드 등의 기능을 어떻게 구현할 수 있는지 고민했던 내용을 기록하고자 한다.

GitHub - sirzzang/nginx-image-server: 정적 이미지 파일 업로드, 다운로드, 삭제 서비스

정적 이미지 파일 업로드, 다운로드, 삭제 서비스. Contribute to sirzzang/nginx-image-server development by creating an account on GitHub.

github.com

# 개발 요구 사항

프로젝트에서 개발해야 하는 기능은 다음과 같다.

1. 업로드

이미지 업로드 시, 이미지는 파일 시스템에 저장
파일 시스템 저장 시, 파일 검색 성능 보장을 위한 디렉토리 계층화 정책 설계 필요
- 예컨대, 파일명을 2글자 정도씩 쪼개서 디렉토리를 짜는 설계 가능(예: 파일명이 ar213fdvxcwe.png인 경우, /ar/21/3fdvxcwe.png와 같이 저장할 수 있음)
- 말단 디렉토리 하나당 들어가는 이미지 파일의 개수가 분산될 수 있도록 디렉토리 규칙 및 depth를 고려하여야 함
업로드 시, 이미지 고유 식별이 가능한 id(예: uuid, hash)를 발급해 응답으로 반환
다중 업로드 가능

2. 다운로드

이미지 id로 다운로드 요청 시, 파일 시스템에서 해당 이미지 파일 반환

3. 삭제

이미지 id로 삭제 요청 시, 파일 시스템에서 해당 이미지 파일 삭제

위의 개발 요구 사항 중, 이미지 id 발급, 이미지 파일 삭제 등이 웹 서버가 수행해야 하는 동적인 기능이 된다.

# 기술 스택

프로젝트 진행을 위해 사용한 기술 스택은 다음과 같다.

Nginx 1.20.2: 웹 서버
fcgiwrap: FastCGI 프로세스 wrapper
nginx-upload-module 2.3.0: Nginx에서 파일 업로드를 처리할 수 있도록 하는 모듈
Python 3.9: FastCGI 스크립트 작성

각 스택을 이용해 구축될 이미지 서버 구조 개요

## Nginx

사용할 수 있는 웹 서버로 Nginx, Apache Httpd, WebtoB 등이 있다. 프로젝트 구현에 사용할 수 있는 기술 스택을 선정하면서, 예전에 웹 서버 및 CGI에 대해 공부했던 내용 중, 웹 서버에서 CGI로 동적인 서비스를 구현할 때 매번 새로운 프로세스를 fork하여 나타날 수 있는 성능 하락 문제를 복기했다. 그리고 각 스택이 해당 문제를 어떻게 해결하고 있는지 살펴 보았다.

세 스택 중 앞의 두 스택은 CGI 방식을 개선해, 하나의 프로세스에서 동적인 요청을 처리하도록 하는 FastCGI를, 관련 모듈을 제공하는 방식으로 지원한다(Nginx의 경우, ngx_http_fastcgi_module을, Apache Httpd의 경우 mod_fcgid 모듈이 제공된다). WebtoB는 앞의 두 스택과는 달리, 웹 서버가 동적 기능을 하는 서비스를 구현할 수 있도록 WBAPI를 제공한다. 이 API는 WebtoB 서버 기동 시, WBAPI 서비스를 메모리에 로딩함으로써 서비스 호출시마다 매번 새로운 프로세스를 fork하지 않도록 설계되었다고 한다.

특히 WebtoB의 경우 CGI 방식의 문제점을 개선했고, wbSaveFile, wbPutFile 등 개발 요구 사항에 알맞은 기능이 WBAPI 함수로 이미 제공되고 있었다. 다만, WBAPI가 C언어로 제공되고 있어 C를 알지 못하는 상태에서 해당 스택을 선택하기 쉽지 않았다. 결국 Nginx와 Apache Httpd 둘 중 하나를 선택하기로 하였고, 그 중 더 최신 기술이고, 성능이 더 좋다고 알려진 Nginx를 이용해 웹 서버를 구축하기로 하였다.

## Fcgiwrap

Nginx는 FastCGI 방식을 지원하기 위한 ngx_http_fastcgi_module을 기본적으로 제공한다. 한편, 이 모듈을 통해 이미지 서버가 수행해야 할 동적인 기능을 처리하기 위한 FastCGI 프로세스가 필요하다. fcgiwrap이라는 프로그램이 이 역할을 담당한다. fcgiwrap은 fgciwrap.socket(혹은 fcgiwrap.sock)이라는 유닉스 도메인 소켓을 통해 Nginx와 프로세스 간 통신을 하며 Nginx가 수행하지 못하는 이미지 id 발급, 이미지 파일 삭제 등의 기능을 한다. fcgiwrap이 동적인 요청을 처리하기 위해 필요한 스크립트는 Python으로 작성할 예정이다.

Ubuntu Community의 위키에 따르면, fcgiwrap은 FastCGI 규약에 따라 CGI 어플리케이션을 수행하는 간단한 프로세스 wrapper라고 나와 있으며, Nginx에 CGI support를 제공하기 위한 것이라고 한다. 비슷한 목적의 프로그램으로는 php로 스크립트를 작성할 때 사용하는 php-fpm이 있다.

## nginx-upload-module

Nginx에서 파일 업로드를 처리할 수 있도록 도와 주는 3rd party module이다.

엄밀히 웹 서버는 정적인 기능만을 할 수 있기 때문에, 파일을 받아 메모리에 올려서 디스크에 저장하는 것 역시 웹 서버가 할 수 없는 동적인 기능이다. 이 기능을 구현할 수도 있지만(예컨대, fcgiwrap 프로세스에서 클라이언트가 전송한 폼 데이터를 전부든, 일부든 메모리에 올려서 디스크에 저장할 수 있을 것이다), 이미 Nginx, Apache Httpd 등의 웹 서버에서는 파일 업로드 기능을 구현해 놓은 모듈이 존재하기 때문에, 이를 사용하면 FastCGI 프로세스 단까지 넘어오지 않고서도 웹 서버 단에서 업로드를 처리할 수 있다. ~~또한, 직접 구현하는 것보다 성능이 낫지 않을까...~~

다만, Nginx에서 기본으로 제공하는 모듈이 아니기 때문에, Nginx를 소스 코드로부터 컴파일하고, 이 과정에 해당 모듈을 사용할 수 있게 해 주는 설정이 필요하다.

# 소스 코드 구조

위와 같이 개요를 잡고 개발을 진행했으며, 이 때 대략적인 소스 코드 구조는 다음과 같이 구성했다.

└── (project root)
    ├── config/  : nginx 웹 서버 설정 관련 파일 모음
    ├── scripts/ : 이미지 서버 동적 요청 처리를 위한 스크립트 파일 모음
    ├── .env                
    ├── Dockerfile
    ├── docker-compose.yml
    ├── (...)

[ELK] AI 모델링 시각화

eraser — Tue, 15 Mar 2022 02:20:08 +0900

AI 모델링에 사용한 데이터를 데이터 분석을 위한 Elastic stack(https://sirzzang.github.io/dev/Dev-elk-stack-01/)을 이용해 관리하고 시각화할 수 있다. AI 모델링 서버(https://projectlog-eraser.tistory.com/64)에서 로깅을 통해 input, modeling(모델링 중간 과정에 발생하는 데이터) data를 남기고, ELK stack을 통해 이를 수집 및 가공해 적재하고, 시각화하면 된다.

# 구조

전체 구조도는 다음과 같다.

AI modeling visualization을 위해 AI app server에서 발생한 로그 데이터를 활용한다.

AI app server의 Model, Datastore에서 input, output data 및 모델링 과정을 나타내는 데이터(예컨대, 클러스터링 점수 등)를 로그로 남긴다. Elastic stack은 로그 데이터를 이용해 AI modeling 데이터를 관리 및 시각화한다.

Elastic stack을 이루는 각각의 스택이 담당하는 역할은 다음과 같다.

Filebeats: 실시간으로 발생하는 로그 데이터를 읽고, 로그 데이터에서 필요한 데이터를 추출해 Logstash로 전송
Logstash: Filebeats에서 전송한 데이터를 가공하여 Elasticsearch로 전송
Elasticsearch: 데이터 적재 및 검색
Kibana: Elasticsearch에 적재된 데이터를 시각화

이 때, 클라이언트는 Kibana를 통해 시각화된 모델링 결과를 대시보드로 확인할 수 있다.

# 구현

Model1에서 발생하는 로그 데이터의 형태는 다음과 같다.

2021-12-24 16:54:39,804 - root - Model1 - inference - INFO:['ST20000515', '20210909115502', 90.33, 70.22, 30.33, 'Good', 'Moderate', 'Bad']
2021-12-24 16:54:39,804 - root - Model2 - _get_cluster_score - INFO:['ST20000509', '20210928092810', 23.73, 59.13, 0]

Model2에서 발생하는 로그 데이터의 형태는 다음과 같다.

2021-12-24 16:54:39,804 - root - Model2 - _solution - INFO : {'type': 'optimizer', 'order': 1, 'id': 1, 'from': {'lat': '36.88563292330548', 'lon': '128.73457595862516'}, 'to': {'lat': '36.817064467622814', 'lon': '128.96344333457913'}, 'duration': '0:32:00'}
2021-12-24 16:54:39,806 - root - Model2 - _solution - INFO : Optimizer Total Time(minute): 521
2021-12-24 16:54:39,806 - root - Model3 - _solution - INFO : Ortools Total Distance(meter): 267104

Filebeats에서 로그 데이터를 읽어 필요한 데이터를 추출하고, Lostash에서 자료형을 바꾸는 방식으로 가공한다.

## Filebeats.yml

기본적으로 입력(input), 처리(processor), 출력(output)과 관련된 설정 항목을 작성하면 된다. filebeats를 설치하면 자동으로 깔리는 예시 configuration 파일(https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-reference-yml.html)을 참고하거나, Filebeats 공식 문서를 참고해 설정하면 된다.

아래 설정은 예시일 뿐, 개발 요구사항에 맞추어 작성해야 한다. 예컨대, exclude_lines, include_lines와 같은 것은 로그 패턴을 보고 수집할 것과 수집하지 않을 것을 결정해야 한다. 또한, processor dissect 모듈 등을 활용하여 로그 데이터에서 필요한 정보를 추출하는데, 추출되는 데이터가 문자열 형태임에 유의한다.

# --------------------------------- filebeats 입력 ---------------------------------
filebeat.inputs:
- type: filestream # 실시간 로그 filestream
  enabled: true
  prospector.scanner.check_interval: 30s # scan 간격
  paths:
    - /path/to/log # glob-based path 설정도 가능
  
  # 수집하지 않을 라인
  exclude_lines: ['DEBUG']
  
  # 수집할 로그 라인
  include_lines: ['inference', '_solution', '_get_cluster_score']

# --------------------------------- filebeats 설정 파일 -------------------------------
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml

  # 설정 변경시 reload 여부
  reload.enabled: true

# --------------------------------- filebeats output -------------------------------
# Kibana 설정
setup.kibana:
  host: "localhost:5601" # Kibana host

# 아래 주석 풀고 작성 시 Filebeats에서 바로 Elasticsearch로 전송
# output.elasticsearch:
#   # Array of hosts to connect to.
#   hosts: ["localhost:9200"]
  # Protocol - either `http` (default) or `https`.
  #protocol: "https"

  # Authentication credentials - either API key or username/password.
  #api_key: "id:api_key"
  #username: "elastic"
  #password: "changeme"

# logstash output
output.logstash:
  # The Logstash hosts
  hosts: ["localhost:5044"]

# --------------------------------- filebeats processor -------------------------------
processors:
  - drop_fields: # 제외할 필드. 로그 외에 자동으로 생성되는 필드들도 있으므로 확인 후 제외
      fields: ["log", "host", "architecture", "agent", "input", "ecs"]
  - dissect: # 데이터 부분만 추출
      field: "message"
      tokenizer: '%{log_timestamp->} %{+log_timestamp} - %{} - %{model} - %{method} - %{} :     %{data}'
      target_prefix: ""
  - dissect: # Model1 데이터 추출
      when:
        and:
          - equals:
              model: "Model2"
          - contains:
              message: "{"
      field: "data"
      tokenizer: "%{}: '%{type}', %{}: %{order}, %{}: %{id}, %{}: %{}: '%{from.lat}', %{}: '%{from.lon}'}, %{}: %{}: '%{to.lat}', %{}: '%{to.lon}'}, %{}: '%{duration}'"
      target_prefix: ""
      ignore_failure: "true"
  - dissect:
      when:
        and:
          - equals:
              model: "Model2"
          - contains:
              message: "Distance"
      field: "data"
      tokenizer: "%{}: %{distance}"
      target_prefix: ""
  - dissect:
      when:
        and:
          - equals:
              model: "Model3"
          - contains:
              message: "Time"
      field: "data"
      tokenizer: "%{}: %{time}"
      target_prefix: ""
  - dissect:
      when:
        and:
          - equals:
              model: "Model1"
          - equals:
              method: "inference"
      field: "data"
      tokenizer: "['%{id}', '%{date}', %{score1}, %{score2}, %{score3}, '%{grade1}', '%{grade2}', '%{grade3}']"
      target_prefix: ""
  - dissect:
      when:
        and:
          - equals:
              model: "freshnessModel"
          - equals:
              method: "_get_cluster_score"
      field: "data"
      tokenizer: "['%{id}', '%{date}', %{x}, %{y}, %{cluster}]"
      target_prefix: ""
  - drop_fields:
      fields: ["data"]

## logstash.conf

입력(input), 처리(filter), 출력(output)과 관련된 설정 항목을 작성하면 된다. 입력의 경우, beats 스택으로부터 tcp 소켓을 통해 5044 포트의 logstash로 전송된다. 앞서 filebeats.yml의 logstash output에서 설정한 부분이다.

input {
	# filebeats input
    beats {
        port => 5044
    }
}

filter {

    # Model1 데이터 가공
    if [model] == "Model1" {        
        # score 데이터 자료형 변환
        if [method] == "inference" {
            mutate {
                convert => {
                    "score1" => "float"
                    "score2" => "float"
                    "score3" => "float"
                }
            }
        }

        # x, y 좌표 데이터 자료형 변환
        if [method] == "_get_cluster_score" {
            mutate {
                convert => {
                    "x" => "float"
                    "y" => "float"
                }
            }
        }
    }

    # Model2 데이터 가공
    if [model] == "Model2" {
        mutate {
        
        	# 자료형 변환
            convert => {
                "[from][lon]" => "float"
                "[from][lat]" => "float"
                "[to][lon]" => "float"
                "[to][lat]" => "float"
                "order" => "integer"
                "id" => "integer"
                "time" => "float"
                "distance" => "float"
            }
        }
    }

    # 필요 없는 필드 제거
    mutate {
        remove_field => ["tags", "@version"]
    }
}

output {

    # Model1 elasticsearch 인덱스
    if [model] == "Model1" {
    	elasticsearch {
            hosts => ["http://localhost:9200"]
            index => "model1"
            ecs_compatibility => disabled
        }
    }

    # Model2 elasticsearch 인덱스
    if [model] == "Model2" {
        elasticsearch {
            hosts => ["http://localhost:9200"]
            index => "model2"
            ecs_compatibility => disabled
        }
    }
}

## kibana.yml

Kibana 설정은 앞에 비해서는 간단한 편이다. Kibana 웹 인터페이스를 통해서도 설정 파일의 항목을 쉽게 변경할 수 있다. Kibana 서버 포트와 쿼리를 전송할 Elasticsearch 호스트 설정에 주의한다.

# Kibana 서버 포트
server.port: 5601

# Kibana 서버 호스트
server.host: "kibana.server.host.address"

# Enables you to specify a path to mount Kibana at if you are running behind a proxy.
# Use the `server.rewriteBasePath` setting to tell Kibana if it should remove the basePath
# from requests it receives, and to prevent a deprecation warning at startup.
# This setting cannot end in a slash.
#server.basePath: ""

# Specifies whether Kibana should rewrite requests that are prefixed with
# `server.basePath` or require that they are rewritten by your reverse proxy.
# This setting was effectively always `false` before Kibana 6.3 and will
# default to `true` starting in Kibana 7.0.
#server.rewriteBasePath: false

# Elasticsearch host
elasticsearch.hosts: ["http://localhost:9200"]

# kibana pid 저장
pid.file: /path/to/kibana/kibana-7.16.0-linux-x86_64/kibana.pid

# kibana 로그
logging.dest: /path/to/kibana/kibana-7.16.0-linux-x86_64/logs/kibana.log

참고: server.basepath, server.rewritebasepath 설정
여기서는 설정하지 않았지만, K8S 환경에 ELK stack을 적용했을 때(https://projectlog-eraser.tistory.com/63), ingress를 통해 회사 앱 서버 url을 지정했는데, 이 경우 server.basepath를 설정해 주어야 한다. 또한, 설정된 basepath가 제대로 적용될 수 있도록 server.rewritebasepath를 설정해 주어야 한다. 참고

# 결론

기존에 로그 관리 시스템에 적용해 본 것 외에도 데이터 분석에 Elastic stack을 적용할 수 있음을 배웠다. 특히 그것을 AI 모델링 서버와 연결해 진행할 수 있어 더 의미가 있는 경험이었다. 그 동안 Python 기반 matplotlib, seaborn 라이브러리 등을 이용해 시각화하는 것만 경험해 왔는데, ELK stack을 활용하면 일련의 파이프라인을 통해 데이터 수집부터 시각화할 수 있음을 깨달았다. 심지어 아래와 같이 시각화된 결과를 웹 대시보드 형태로도 제공할 수 있기에, 필요한 경우 ELK stack을 활용하는 것도 좋아 보인다.

시각화에 활용된 데이터는 전부 다 Elasticsearch에 대한 쿼리 결과이다

[App Server] Flask로 AI 백엔드 서버 구축해 보기

eraser — Thu, 23 Dec 2021 17:43:13 +0900

지난 포스팅(https://projectlog-eraser.tistory.com/m/57)에서 받은 피드백을 통해, 앱 서버의 구조를 변경해 개발을 진행하였다.

# 구조

백엔드에서 따로 모델을 돌리는 프로세스를 생성하지 않고, socket 통신도 하지 않는다. 따라서 불필요하게 모델을 돌리기 위한 프로세스를 새로 생성하지 않아도 되고, Flask app 프로세스와 모델 프로세스 간에 통신으로 인해 (혹시라도 발생할 수 있는) 서버 부하를 줄일 수 있다.

또한, 모델별로 설계를 진행했던 것과 달리, 새로운 설계에서는 컴포넌트별로 레이어를 나누었다. Controller, Service, Model이 그것이다. Controller는 클라이언트의 요청을 받아, Service로 전달한다. Service는 모델링에 필요한 데이터를 Model에 input으로 전달하고, Model에서 모델링 결과를 반환하도록 inference 메소드를 호출한다. 모델마다 필요한 데이터가 다르기 때문에, 데이터베이스와 연결해서 데이터를 가져와야 하는 경우 datastore를, 미리 저장된 캐시 데이터나 외부 API를 이용해야 하는 경우, 해당 메소드를 구현하도록 한다.

이러한 설계를 통해 백엔드의 각 컴포넌트가 수행해야 하는 역할을 계층 별로 명확히 분리할 수 있다. AI 모델 서비스는 총 3가지로, 각각의 엔드포인트 별로 Controller → Service → Model ( → datastore / external API etc. ) → Service → Controller의 흐름을 거쳐 클라이언트의 요청을 처리할 수 있다.

# 구현

구현에 사용한 (주요) 라이브러리는 다음과 같다.

flask: Flask app은 Controller 역할 담당
dependency-injector: 백엔드 주요 컴포넌트(Service, Model, Datastore 등) object를 생성하고 주입. 실행에 필요한 환경 설정 정보도 함께 로드
pyodbc: Datastore의 Tibero DB 접근 담당
pandas

## Controller

Controller 역할을 하는 Flask app이다. 실제 서비스가 되고 있는 코드이므로, 전체 구조를 보여줄 수 있는 예시만 첨부한다. 예시의 API 엔드 포인트 URI는 관례에 어긋난 것으로, 예시로서만 남긴다.

from flask import Flask, request, jsonify
from model2 import APIError, NotExecutableError
from container import Container
import logging

# Flask 앱
app = Flask(__name__)

# service, datastore 등 object 주입
container = Container()
container.init_resources()

model1_service = container.model1_service()
model2_service = container.model2_service()
model3_service = container.model3_service()

model1_datastore = container.model1_datastore()
model1_model = container.model1_model()


# model1 엔드포인트
@app.route("/model1/fill", methods=['POST'])
def fill_model1_score():

    resp = {}
    
    # 클라이언트의 요청 query parameter 오지 않은 경우
    date = request.args.get('date')
    if not date:
        resp['status'] = 400
        resp['msg'] = '`date` field should be in request query'
        return jsonify(resp), 400
  	
    # model1 서비스 호출
    try:
        model1_service.fill_model1_data(date)
    except:
        # TODO: model1 에러 핸들링
        pass
    else:
        resp['status'] = 200
        resp['msg'] = f'model1 score fill task on date {date} OK'
    
    return jsonify(resp)

# model2 엔드포인트
@app.route("/model2", methods=['POST'])
def model2():

    resp = {}

    # 클라이언트의 요청 body 데이터가 json 형태가 아니거나 비어 있는 경우
    if not (request.is_json and request.json):
        logging.debug('request body data not json format or empty')
        resp['status'] = 400
        resp['msg'] = 'request body data should be json format'
        return jsonify(resp), 400

    # 클라이언트의 요청 body 데이터가 API 명세에 정의된 payload와 맞지 않는 경우
    try:
        input = request.json    
        model2_input_dao = model2DAO()
        model2_input_dao.depot = input['depot']
        model2_input_dao.start_time = input['startTime']
        model2_input_dao.maxtime = input['maxTime']
    except KeyError as ex:
        logging.debug(f'field {ex} missing in request body data')
        resp['status'] = 400
        resp['msg'] = f'request body data should have {ex} field' 
        return jsonify(resp), 400
    
    # model2 서비스 호출
    try:
        result = model2_service.get_model2_data(model2_input_dao)
    except APIError as ex:
        '''
            - 클라이언트의 요청에는 문제가 없으나,
            - 외부 서비스 API 호출 단계에서 APIError가 발생한 경우
        '''
        resp['status'] = 200
        resp['msg'] = str(ex)
    except NotExecutableError as ex:
        '''
            - 클라이언트의 요청에는 문제가 없으나,
            - 클라이언트의 요청 데이터로 모델에서 최적해를 찾아낼 수 없는 경우
        '''
        resp['status'] = 200
        resp['msg'] = str(ex)
    else:
        resp['status'] = 200
        resp['msg'] = 'OK'
        resp['data'] = result

    return jsonify(resp)

# reloader 옵션 해제
if __name__ == "__main__":
    app.run(debug=True, host='0.0.0.0', port=4000, use_reloader=False)

서비스 운영 중 로그를 확인하다 Flask reload와 관련된 문제를 알게 되었다. model1 서비스에서 똑같은 메소드가 2번씩 호출되고 있었던 것이다. Container를 통해 의존성을 주입했기 때문에 Model, Service 등 object가 2번 호출될 일이 없는데도 말이다. 서버에서 실행되고 있는 프로세스를 확인해 보니, app.py를 한 번 실행했음에도 해당 명령어로 실행한 프로세스가 2개임을 발견하게 되었다.

Flask 공식 문서(https://flask.palletsprojects.com/en/1.1.x/api/?highlight=use_reloader) 및 Stackoverflow 글(https://stackoverflow.com/questions/25504149/why-does-running-the-flask-dev-server-run-itself-twice)을 통해 문제를 해결할 수 있었다. 내가 위에서 작성했던 것과 같이, 파이썬 스크립트에서 app.run()으로 Flask app을 실행할 시, flask 라이브러리에서 개발 서버를 띄우도록 설계되어 있는데, 이 경우 개발 편의 목적으로 코드 변경 감지를 위해 child process를 하나 더 띄운다고 한다. 이 때문에 flask run 커맨드를 통해 Flask app을 실행하거나, 위와 같이 코드 내에서 실행하고자 할 경우, use_reloader=False 옵션을 주어야 한다고 한다.

## Service

Service 인터페이스는 다음과 같다. 각 모델 별로 inference 메소드를 호출할 메소드를 구현하도록 설계한다.

from abc import *


class Model2ServiceInterface(metaclass=ABCMeta):

    @abstractmethod
    def get_model2_data(self, input: object) -> object:
        raise NotImplementedError

Model2에 해당하는 Service 구현체는 다음과 같다.

from abc import *
import logging

from common.Model2ServiceInterface import Model2ServiceInterface
from common.model import Model


class Model2Service(Model2ServiceInterface):
    def __init__(self, model: Model):
        self._model = model

    def get_model2_data(self, input):
        result = self._model.inference(input)
        return result

## Model, Datastore

Model 인터페이스는 다음과 같다. 모든 Model 구현체는 이 인터페이스를 상속하는데, Service가 호출할 `inference` 메소드만 구현하면 된다. 구현체는 AI 모델링에 대한 부분으로, 서비스와 밀접한 연관이 있어 생략한다.

import abc


class Model(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def inference(self, input_data: object) -> object:
        raise NotImplementedError

Datastore 인터페이스는 다음과 같다. Model1에서만 Datastore를 이용하는데, 다음의 인터페이스를 상속해 구현한다.

from abc import *


class Model1DatastoreInterface(metaclass=ABCMeta):

    def __init__(self):
        pass

    @abstractmethod
    def update_status(self: object, sensor_id: str) -> None:
        raise NotImplementedError

    @abstractmethod
    def findall_by_date(self: object, date: str) -> object:
        raise NotImplementedError
 
    @abstractmethod
    def store_data(self: object, data: object) -> None:
        raise NotImplementedError

## Container

그 외에 의존성 주입을 위한 Container는 다음과 같이 구현한다.

import logging.config
import json
import os
import sys
from core.model1Service import model1Service
from core.model2Service import model2Service
from core.model3Service import model3Service
from core.model1Model import model1Model
from core.model2Model import model2Model
from core.model3Model import model3Model
from core.model1DataStore import model1DataStore


class Container(containers.DeclarativeContainer):

    # 모델링에 필요한 설정 정보
    config = providers.Configuration()
    config.from_yaml(f'{os.environ["APP_ROOT"]}/resource/config.yaml', required=True)

    # 로깅 설정 정보
    with open(os.path.join(sys.model2[0], "logging.json"), 'rt') as f:
        logging = providers.Resource(logging.config.dictConfig, json.load(f))

    # 백엔드 object 생성 및 주입
    model1_datastore = providers.Factory(model1DataStore)
    model1_model = providers.Factory(model1Model, config=config.model1())
    model2_model = providers.Factory(
        model2Model, url=config.model2.url(), key=config.model2.key())
    model3_model = providers.Factory(model3Model, config=config.model3())
    model1_service = providers.Factory(
        model1Service, datastore=model1_datastore, model=model1_model)
    model2_service = providers.Factory(model2Service, model=model2_model)
    model3_service = providers.Factory(model3Service, model=model3_model)

dependency-injector 라이브러리는 특정 프레임워크에 종속되지 않고 사용할 수 있는 Python의 의존성 주입 라이브러리이다. 사용법은 공식 문서(https://python-dependency-injector.ets-labs.org)에서 확인할 수 있다.

Dependency Injector — Dependency injection framework for Python — Dependency Injector 4.38.0 documentation

Dependency Injector — Dependency injection framework for Python Dependency Injector is a dependency injection framework for Python. It helps implementing the dependency injection principle. Key features of the Dependency Injector: Providers. Provides Fac

python-dependency-injector.ets-labs.org

# 배운 점

지난 피드백 이후 여러 곳에서 배우며 처음으로 AI 서비스에 활용할 수 있는 백엔드를 구축해 보았다. 백엔드 구축에 있어 계층을 어떻게 분리하여 설계할 수 있는지, 의존성 관리, 인터페이스 작성이 왜 필요한지 배울 수 있었다. 클래스 및 인터페이스의 작성에 익숙하지 않았는데, AI 서비스 백엔드 설계에도 dao, controller, service 등과 같은 백엔드 컴포넌트 개념을 적용할 수 있음을 느낄 수 있었다.

아직 구현되지 않아, 더 연구해 보고 싶은 부분은 Model에서의 에러 처리 부분이다. 위의 코드 중 #TODO로 남겨진 부분인데, 사실 해당 부분은 특별한 문제가 있지 않으면 에러가 나지 않는(나면 안 되는) 부분이기 때문에 에러 처리를 어떻게 해야 할지 모르겠어 연구가 필요할 듯하다.

[ELK] K8S 환경에 ELK stack 배포하기

eraser — Sun, 5 Dec 2021 12:01:36 +0900

회사에서 Springboot Application의 로그를 모니터링하기 위해 ELK stack을 활용해 모니터링 시스템을 개발했다. 그런데 QA 및 테스트 환경에서의 로그 모니터링이 필요해짐에 따라 해당 시스템을 사내 데이터센터의 클라우드 환경(현재 사내 QA 및 테스트는 사내 데이터 센터 클라우드 환경에서 namespace 및 리소스를 할당 받아 이루어지고 있다)에 배포할 필요성이 생겼다.

사내 데이터센터 클라우드 환경이 K8S와 거의 동일하기 때문에, docker-compose를 이용해 컨테이너 환경에서 개발했던 것을 쿠버네티스 환경에 올리기만 하면 될 것이라고 생각했는데, 어떻게 구성할 지부터 시작해, 실제 쿠버네티스 오브젝트 매니페스트를 작성하고 배포하는 것이 쉽지 않았기 때문에, 해당 과정을 정리해 두고자 한다.

GitHub - sirzzang/elk-on-k8s-tutorial: 쿠버네티스 환경에 ELK stack 배포하기

쿠버네티스 환경에 ELK stack 배포하기. Contribute to sirzzang/elk-on-k8s-tutorial development by creating an account on GitHub.

github.com

사내 데이터센터 클라우드는 쿠버네티스 API 서버 1.17.8 버전을 사용하는 쿠버네티스 환경이다. 웹에서 YAML 에디터가 제공되기 때문에 해당 에디터를 이용해 오브젝트 매니페스트를 작성하거나, 로컬에서 YAML 파일을 작성한 뒤 kubectl 명령어를 통해 오브젝트를 생성하고 업데이트할 수 있다.

다만, 현재 QA 및 테스트를 위해 할당받은 namespace에서는 노드, persistent volume 등 특정 오브젝트에 대한 접근 권한이 없다. 때문에 오브젝트 생성 후 어떤 파드를 어떤 노드에서 실행할 것인지 할당하는 등의 작업은 불가능하며, 영구 볼륨을 생성하는 것이 아니라, 영구 볼륨 클레임을 생성하여 스토리지를 사용할 수 있다. 스토리지 클래스의 경우, 할당받은 namespace에 기본적으로 제공되는 것들(hdd, ssd 등)이 있어 이것을 사용했다.

# 구조

배포 시 구조는 다음과 같이 구성했다. Elasticsearch와 Kibana의 경우에는 elastic에서 제공하는 기본 이미지를 사용했고, Logstash는 elastic에서 제공하는 기본 이미지에 로그 파싱을 위해 필요한 플러그인을 설치한 이미지를 생성해 사용했다.

쿠버네티스를 공부한 지 얼마 되지 않아, 아래와 같이 그림을 그리는 것은 옳지 않을 수 있다.  머릿속으로 생각했을 때 이러 이러한 구조로 그리면 맞겠지 하고 그린 그림일 뿐...

## Elasticsearch

Elasticsearch의 경우, 로그 데이터를 저장하고 있어야 하므로 파드가 내려가도 데이터가 사라지지 않도록 Statefulset 컨트롤러 오브젝트를 생성해 파드를 실행하도록 했다. 그리고 PVC 오브젝트를 생성해 스토리지에 데이터를 저장한다.

다만, Elasticsearch 클러스터는 구성하지 못했다. 즉, replicas를 1로 설정해 Elasticsearch 노드를 1개만 띄웠다. 처음 모니터링 시스템 개발 시 Elasticsearch 클러스터 구성 방법을 파악한 뒤 개발한 것이 아니었기 때문에, 배포 시 이 점을 반영할 수 없었다. 이렇게 한 개의 노드로만 구성했을 때 장애에 대처할 수 없고(예컨대, Elasticsearch 노드에 문제가 발생하면 그 때 발생하는 로그는 적재되지 않게 된다), Elasticsearch의 장점을 활용할 수도 없는 것이기 때문에, 추후 클러스터를 구성하도록 전체 아키텍쳐를 변경하는 것이 필요하다.

배포된 환경에서 Logstash 노드와 Kibana 노드가 Elasticsearch와 통신할 수 있어야 하므로 NodePort 타입의 서비스 오브젝트를 생성하고, 9200 포트를 열어 주었다. 그림 상에서는 9300 포트도 나와 있는데, 사실 9300 포트의 경우 Elasticsearch를 여러 개의 노드로 구성할 때 노드 간 사용하게 될 포트로, 지금은 1개의 노드로 구성해 필요가 없지만, 추후 여러 노드로 구성할 때를 대비해 지금 단계에서도 열어 두었다.

## Logstash, Kibana

Logstash와 Kibana의 경우 Elasticsearch와 달리 데이터를 저장하거나 상태를 기억해야 할 필요가 없기 때문에, Deployment 컨트롤러 오브젝트로 파드를 실행하도록 했다.

둘 모두 장애가 났을 때 굳이 여러 개의 파드가 떠 있어야 할 필요가 없다고 판단했기 때문에, replicas를 1로 설정했다. Logstash 파드의 경우 장애가 발생했을 때 나면 로그 유실 우려가 있지만, 이런 문제가 발생한다면 TCP로 로그를 바로 쏴 주는 현재 아키텍쳐에서 비롯되는 문제일 것이라 보기 때문에, Logstash 파드를 여러 개 띄우는 것이 아니라 Filebeats 파드를 띄우는 식으로 개선하고자 한다. Kibana 파드의 경우 장애가 발생할 때 대시보드를 조회하지 못할 수는 있다. 다만, Kibana Saved Objects가 모두 Elasticsearch 파드에 bound된 스토리지에 저장되기 때문에 데이터 유실 우려는 없어 가용성을 높일 필요는 없을 것이라 판단했다. (물론, Elasticsearch 파드에 문제가 생긴다면 Kibana Saved Objects도 모두 유실된다..)

Logstash 파드는 Elasticsearch 파드와 통신하면 되므로 NodePort 타입의 서비스 오브젝트를, Kibana 파드는 사내에서 접속해 로그 대시보드를 확인할 수 있어야 하므로 LoadBalancer 타입의 서비스 오브젝트를 생성해 주었다.

내용 추가

1. 해당 내용에 대해 세미나를 진행했는데, Kibana 대시보드 접속 설정은 굳이 LoadBalancer 서비스 오브젝트를 붙이지 않고, ingress 오브젝트 단에서 진행해도 될 듯하다는 피드백이 있었다.

2. 추후 서비스 오브젝트에 대해 다시 공부하면서 보니, Logstash 디플로이먼트 오브젝트와 Kibana 디플로이먼트 오브젝트에 연결할 서비스 오브젝트는 굳이 NodePort가 아니었어도 될 듯하다. 클러스터 내에서만 통신해도 되기 때문에, ClusterIP로 해도 된다.

# 배포

namespace, 스토리지 등 사내 클라우드 환경에서 기본적으로 제공되는 것은 각주로 대체했다.

## Elasticsearch

NodePort 타입의 Service 오브젝트를 작성한 뒤 적용한다.

apiVersion: v1 
kind: Service
metadata:
  name: elasticsearch
  namespace: # namespace
spec:
  ports:
    - name: http-rest
      protocol: TCP
      port: 9200
      targetPort: 9200
    - name: tcp
      protocol: TCP
      port: 9300
      targetPort: 9300
  selector:
    app: elasticsearch

아래와 같이 Statefulset 오브젝트를 작성한 뒤 적용한다. Statefulset의 VolumeClaimTemplates를 PersistentVolumeClaim 매니페스트로 따로 작성해도 된다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch
  namespace: # namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
        - name: elasticsearch
          image: 'docker.elastic.co/elasticsearch/elasticsearch:7.15.2'
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: "1"
              memory: 8Gi
            requests:
              cpu: 500m
              memory: 4Gi          
          env:
            - name: ES_JAVA_OPTS
              value: '-Xmx2g -Xms2g'
            - name: discovery.type 
              value: single-node
          ports: 
            - name: http-rest
              containerPort: 9200
              protocol: TCP
            - name: tcp
              containerPort: 9300
              protocol: TCP
          volumeMounts:
            - name: es-data-volume
              mountPath: /usr/share/elasticsearch/data
      restartPolicy: Always
  volumeClaimTemplates:
    - kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: es-data-volume
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: # storage class
        volumeMode: Filesystem

위의 두 YAML 파일을 elasticsearch.yaml과 같이 하나의 파일로 작성한 뒤 적용해도 된다.

elasticsearch.yaml

apiVersion: v1 
kind: Service
metadata:
  name: elasticsearch
  namespace: # namespace
spec:
  ports:
    - name: http-rest
      protocol: TCP
      port: 9200
      targetPort: 9200
    - name: tcp
      protocol: TCP
      port: 9300
      targetPort: 9300
  selector:
    app: elasticsearch
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch
  namespace: # namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
        - name: elasticsearch
          image: 'docker.elastic.co/elasticsearch/elasticsearch:7.15.2'
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: "1"
              memory: 8Gi
            requests:
              cpu: 500m
              memory: 4Gi          
          env:
            - name: ES_JAVA_OPTS
              value: '-Xmx2g -Xms2g'
            - name: discovery.type 
              value: single-node
          ports: 
            - name: http-rest
              containerPort: 9200
              protocol: TCP
            - name: tcp
              containerPort: 9300
              protocol: TCP
          volumeMounts:
            - name: es-data-volume
              mountPath: /usr/share/elasticsearch/data
      restartPolicy: Always
  volumeClaimTemplates:
    - kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: es-data-volume
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: # storage class
        volumeMode: Filesystem

적용

kubectl apply -f elasticsearch.yaml

## Logstash

Logstash 설정 및 파이프라인 작성을 위한 conf 파일을 ConfigMap 오브젝트로 작성한다. filter 부분은 대체.

apiVersion: v1
kind: ConfigMap
metadata:
  name: logstash-config
  namespace: elk-stack
data:
  # configuration for logstash pipeline
  logstash.conf: |
    input {
      tcp {
        port => 5000
      }
    }
    filter {
      json {
        source => "message"
      }
      mutate {
        remove_field => ["@version"]
      }
    }
    output {
      stdout {
        codec => rubydebug
      }
    }
  
  # logstash configuration
  logstash.yml: |
    http.host: "0.0.0.0"
    path.config: /usr/share/logstash/pipeline

NodePort 타입의 서비스 오브젝트를 작성한 뒤 적용한다.

apiVersion: v1
kind: Service
metadata:
  name: logstash
  namespace: # namespace
spec:
  type: NodePort
  ports:
    - name: tcp
      protocol: TCP 
      port: 5000
      targetPort: 5000
  selector:
    app: logstash

Logstash 파드의 Deployment 컨트롤러 오브젝트를 작성한 뒤 적용한다. 만약, ConfigMap을 수정했다면, Deployment를 다시 실행해 주어야 한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: logstash
  namespace: # namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: logstash
  template:
    metadata:
      labels:
        app: logstash
    spec:
      volumes:
        - name: logstash-config-volume
          configMap:
            name: logstash-config
            items:
              - key: logstash.yml
                path: logstash.yml
        - name: logstash-pipeline-volume
          configMap:
            name: logstash-config
            items:
              - key: logstash.conf
                path: logstash.conf
      containers:
        - name: logstash
          image: # logstash image from private repository
          imagePullPolicy: Always
          resources:
            limits:
              cpu: 500m
              memory: 4Gi
            requests:
              cpu: 300m
              memory: 2Gi          
          env:
            - name: LS_JAVA_OPTS
              value: '-Xmx1g -Xms1g'
          ports:
            - name: tcp
              containerPort: 5000
              protocol: TCP
          volumeMounts:
            - name: logstash-config-volume
              mountPath: /usr/share/logstash/config
            - name: logstash-pipeline-volume
              mountPath: /usr/share/logstash/pipeline

## Kibana

Kibana 설정을 위한 파일을 ConfigMap 오브젝트로 작성한다. elasticsearch.hosts 설정의 경우, 쿠버네티스의 DNS 시스템에 따라 elasticsearch라는 파드 이름을 통해 elasticsearch 서비스 오브젝트에 접속할 수 있다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: kibana-config
  namespace: # namespace
data:
  kibana.yml: |
    server.host: 0.0.0.0
    elasticsearch.hosts: ["http://elasticsearch:9200"]

LoadBalancer 타입의 Service 오브젝트를 작성해 적용한다.

apiVersion: v1
kind: Service
metadata:
  name: kibana
  namespace: # namespace
spec:
  ports:
    - name: http
      protocol: TCP
      port: 5601
      targetPort: 5601
  selector:
    app: kibana
  type: LoadBalancer

Kibana 파드의 Deployment 컨트롤러 오브젝트를 작성한 뒤 적용한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
  namespace: # namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kibana
  template:
    metadata:
      labels:
        app: kibana
    spec:
      volumes:
        - name: kibana-config-volume
          items:
            - key: kibana.yml
              path: kibana.yml
      containers:
        - name: waplpay-kibana
          image: 'docker.elastic.co/kibana/kibana:7.15.2'
          imagePullPolicy: IfNotPresent
          ports:
            - name: kibana
              containerPort: 5601
              protocol: TCP
          resources:
            limits:
              cpu: '1'
              memory: 2Gi
            requests:
              cpu: 500m
              memory: 1Gi
          volumeMounts:
            - name: kibana-config-volume
              mountPath: /usr/share/kibana/config
      restartPolicy: Always

위와 같이 각 오브젝트의 매니페스트를 작성한 뒤 배포하면, 위에서 언급한 구조와 같은 형태의 ELK stack이 클라우드 환경에 배포된다.
아래 사진의 예시와 같이 kubectl get pods, kubectl get statefulsets, kubectl get deployments, kubectl get pvc 등과 같은 명령어를 통해 각 오브젝트의 상태를 확인해 보면 된다.

글 작성 시점에서는 elasticsearch 파드가 생성된 지 14일이 지났다.

# Troubleshooting

## OOMKilled 에러

Elasticsearch 파드를 실행하는 과정에서 아래와 같은 OOMKilled 에러를 마주했다.

OOMKilled 후 CrashLoopBackOff 상태를 반복한다

메모리 관련 에러인 듯하여 찾아 보니, Elasticsearch 컨테이너에 `Xmx2g Xms2g` 옵션을 주어 JVM 힙 메모리 사이즈를 설정했는데, 파드에 할당한 자원 할당량이 2Gi 였기 때문에 발생하는 문제인 듯하였다. 파드에 할당하는 자원 할당량 중 메모리 할당량을 높여 주니 문제가 발생하지 않았다.

관련해 더 찾다 보니, LINE Engineering에서 프로메테우스를 사용해 메트릭을 모니터링하다 OOMKilled 에러를 겪었다는 글을 발견했다.

누가 Kubernetes 클러스터에 있는 나의 사랑스러운 Prometheus 컨테이너를 죽였나! - LINE ENGINEERING

안녕하세요. 이번 글에서는 CrashLoopBackoff 상태에 있는 Prometheus 컨테이너 이슈의 원인을 조사하고 해결하는 과정에서 겪은 흥미로운 경험을 공유하려고 합니다. 사실 이런 현상이 발생하는 원인

engineering.linecorp.com

## PVC bound 실수

사실 이건 해결한 문제는 아니지만, 아주 바보 같은 실수를 해서 기록한다.

ELK stack을 작성해 배포한 뒤, kubectl get pvc 명령어를 통해 PVC 상태를 확인했는데, PVC가 bound되어 있지 않음을 발견했다. Grafana 대시보드를 통해 네임스페이스 내 PVC 오브젝트들의 상태를 확인해도 bound되어 있는 Elasticsearch PVC를 찾을 수 없었다.

알고 보니 Elasticsearch Statefulset 오브젝트 매니페스트를 작성하면서 volumeMounts 부분을 작성하지 않았던 것이었다. volumeMounts 부분을 작성해서 Statefulset 컨트롤러 매니페스트를 다시 작성해서 배포했는데, 그 결과 Elasticsearch 파드가 재기동되면서 이전까지 쌓여 있었던 약 5만 개 가량의 로그 데이터가 사라지고, 인덱스가 새로 매핑되면서 Kibana 파드도 재기동해야 하는 문제가 발생했다. Kibana 서버에 장애가 발생한 것은 아니었지만, 이전 Elasticsearch 파드에 저장되어 있던 Kibana Saved Objects가 사라졌음은 말할 것도 없다...

처음 배포할 때부터 완벽하게 매니페스트를 작성했더라면 좋았겠지만, 다음에도 이런 상황이 발생한다면 무턱대고 Statefulset을 다시 작성해 배포하는 것이 아니라, 해당 파드에 있는 데이터를 클라우드 환경 내 스토리지를 사용해 저장한 뒤 다시 배포하는 방법을 찾아야 할 것이다.

로컬에서 구축한 모니터링 시스템을 클라우드 상의 운영 환경에 올린 것에 의의를 둔 초기 배포였지만, 앞으로 다음과 같은 부분을 더 연구해서 발전시켜 나가야 한다.

구조
- Elasticsearch 클러스터를 어떻게 구성해야 하며, 구성 시 클라우드 환경 상의 아키텍쳐는 어떻게 달라져야 하는가?
- 로그 모니터링 시스템에 filebeats 스택이 추가되었을 때, 클라우드 환경 상의 아키텍쳐는 어떻게 달라져야 하는가?
자원 할당
- 로그 이벤트 1건 당 용량은 얼마나 되며, 로그 발생량에 기초했을 때 Elasticsearch 파드에 bound되는 PVC의 용량은 어떻게 산정해야 하는가?
- Elasticsearch, Logstash, Kibana 각 파드의 CPU, 메모리 사용량을 Grafana를 통해 관찰했을 때 어느 정도의 추이를 보이며, 이를 기반으로 했을 때, 각 파드의 자원 할당량을 어떻게 최적화할 수 있는가?

[Tibero] Tibero에서 UPSERT 쿼리 구현하기

eraser — Mon, 18 Oct 2021 21:49:09 +0900

지난 글에서 개발하던 앱 서버를 운영하던 중, 이슈가 발생해 해당 이슈를 해결하기 위해 UPSERT 쿼리를 구현할 필요성이 생겼다. UPSERT란, 키 값이 존재하는 row에 대해서는 UPDATE를 수행하고, 그렇지 않은 row에 대해서는 INSERT를 수행하는 쿼리이다. MySQL, PostgreSQL, Oracle 등 많이 사용하는 데이터베이스에서는 UPSERT를 수행하기 위한 쿼리가 제공된다.

간략하게 ~~(전적으로 내 기준)~~ 기억하기 쉽도록 각 DBMS에서 제공되는 UPSERT 쿼리를 정리하면 다음과 같다.

MySQL: ON DUPLICATE KEY UPDATE
PostgreSQL: ON CONFLICT DO UPDATE SET
ORACLE: MERGE WHEN MATHCED THEN WHEN NOT MATCHED THEN

해당 글에서는 앱 서버 운영 중 마주친 이슈를 해결하기 위해 이슈를 해결하기 위해 앱 서버의 데이터베이스인 Tibero에서 해당 쿼리를 구현한 방법을 기록한다.

# MySQL UPSERT 테스트

Tibero에서 UPSERT를 구현하기 앞서, MySQL에서 UPSERT를 어떻게 구현할 수 있는지 테스트해 보았다. 센서 id가 존재하면 센서 상태(status)를 OFF로 update하고, 센서 id가 없으면 센서 상태가 ON이 되도록 센서 id와 상태를 insert하는 작업을 수행하고자 한다.

테스트를 위해 아래와 같이 테스트 데이터베이스, 유저를 생성해 주었다.

그리고 sensor_status라는 테스트 테이블을 생성했다. 이 때, 센서 id가 존재하는 값인지 확인해야 하므로, 센서 id에 해당하는 NAME 열을 unique index로 지정해 주었다.

CREATE TABLE UPSERT.status (
name VARCHAR(10) NOT NULL,
status VARCHAR(3) NOT NULL,
PRIMARY KEY (name),
UNIQUE INDEX name_UNIQUE (name ASC) VISIBLE);

UPSERT 쿼리는 다음과 같이 작성한다.

INSERT INTO status (NAME, status)
VALUES ('ST2000', 'ON')
ON DUPLICATE KEY UPDATE status='OFF';

해당 쿼리를 여러 번 수행하며 UPSERT 문이 잘 작동하는지 확인한다.

중복되는 키 값이 존재하는 경우, UPSERT 쿼리 수행 시 '2 rows affected'라는 메시지가 뜨는 것을 볼 수 있다. Documentation에 의하면 INSERT가 수행된 경우 '1 row affected', UPDATE가 정상적으로 수행된 경우 '2 rows affected', UPDATE가 수행되나 기존 값과 같은 경우 '0 row affected'라는 결과가 나타난다고 한다. 더 자세한 경우를 알아보고 싶으면 이 글을 참고해도 좋을 듯.

MySQL에서 이와 같이 UPSERT 쿼리를 구현할 수 있다. 찾아 보니 UPSERT를 수행해야 하는 상황에 REPLACE를 사용하는 방법도 있다고 하니, 참고.

# Tibero 데이터베이스에서 UPSERT 쿼리 구현

Tibero에서 UPSERT 작업을 수행하려면 Oracle 데이터베이스와 비슷하게 MERGE 문을 사용하면 된다. 아래 사진에서와 같이 공식 Tibero SQL 참조서는 여러 삽입, 갱신, 삭제 작업을 수행하기 위해 MERGE 문을 사용하라고 안내한다.

공식 참조서를 따라 쉽게 이슈 해결을 위한 UPSERT 쿼리를 구현할 수 있었다. 다만, 단일 테이블에서 row가 존재하는지를 판단해야 했기 때문에 USING 절에 DUAL 테이블을 사용했다.

MERGE INTO IOT.TEST_SENSOR_STATUS T
USING DUAL
ON (T.SENSOR_ID = 'ST20000509')
WHEN MATCHED THEN
	UPDATE
		SET T.STATUS = 'OFF'
WHEN NOT MATCHED THEN
	INSERT (T.SENSOR_ID, T.STATUS)
	VALUES ('ST20000509', 'ON');

UPSERT 쿼리가 잘 동작하는지 확인해 보자.

INSERT	UPDATE

위와 같은 과정을 통해 Tibero 데이터베이스에서 쉽게 UPSERT 쿼리를 구현할 수 있다. 더 알아보고 싶은 부분은 다음과 같다.

USING 절에 테이블을 사용할 때와 뷰를 사용할 때, 어떤 차이가 있는가? 성능적인 측면에서?
UPSERT 문과 연결된 API 설계를 어떻게 해야 할 것인가?

[App Server] Flask, Socket으로 앱 서버 구축해 보기

eraser — Fri, 13 Aug 2021 02:34:55 +0900

(지난 포스팅에 이어) 클라이언트의 요청이 들어 왔을 때, 요청을 처리해 모델링을 한 뒤, 해당 결과를 클라이언트에게 전송하는 앱 서버를 개발하였다. Flask와 Socket을 이용해 개발했는데, 구조를 기획하고 실제 코드를 작성하는 과정에서 배운 점이 많았기 때문에 간략하게 전체적인 과정을 기록하고자 한다.

예전에 데이터 분석, AI를 배울 때부터 꼭 해보고 싶었던 일이기에, 회사 업무를 통해 경험할 수 있다는 것 자체가 큰 성장이었다.

# 구조

개발에 앞서 다음 그림과 같은 구조를 기획했다. Flask app server는 클라이언트의 요청을 라우팅하는 router 모듈로 동작하고, backend server는 Flask app server에서 받은 요청에 따라 그에 맞는 모델을 호출해 작업을 수행한 뒤 결과를 돌려준다.

Flask app과 model, DB 부분이 모두 우리 backend지만, flask는 routing 역할만 담당하도록 구상했다.

서빙될 모델은 2개이다. 클라이언트는 model1과 model2에 대해 GET 요청을 보낸다. Flask app server는 model1에 대한 URL <server>/model1로 요청이 들어 오면 backend server에 model1에 대한 요청이 들어 왔음을 알린다. model2에 대한 경우도 마찬가지이다. 이후 model1과 model2에서 사용자가 알고자 하는 결과에 대한 inference가 끝나면, 각 모델은 inference가 끝났다는 알림(과 데이터)을 Flask app에 보내고, Flask app은 클라이언트에게 해당 결과를 전송한다.

각 모델이 동작하는 방식은 내부적으로 다르지만, Flask app으로부터 호출을 받는다는 것이 핵심이다.

model1의 경우, DB와 외부 API에서 모델링에 필요한 데이터를 로드해 전처리한 뒤, inference 로직에 전처리된 데이터를 주입한다. inference 결과를 DB의 result table에 INSERT하면, 클라이언트 앱 서버를 구축하는 쪽에서 해당 result table에 접근해 모델 inference 결과를 가져 간다. 따라서 INSERT가 완료되면 model inference가 끝났다는 response를 돌려 준다.

model2의 경우, 클라이언트가 GET 요청을 보낼 때 request body에 모델링에 필요한 데이터가 함께 전송된다. 따라서 model2는 Flask app server로부터 전송된 데이터를 전처리하고, inference 과정을 거친다. model1과 달리 inference 결과를 Flask app server에 돌려 준다.

Nginx는 Flask app server를 배포하기 위해 필요한 것으로, 구조도를 작성할 때는 집어 넣었지만, 지금 단계에서는 구현하지 않았다.

# 구현

구현에 사용한 라이브러리는 다음과 같다.

flask
socket: flask app과 backend server간 통신을 위한 용도
pyodbc: Tibero DB에 접근하기 위한 용도
requests
pandas
python-dotenv: 환경변수(Tibero DSN 설정 등)를 import해서 사용하기 위한 용도
flake8: python 린팅

전체적인 디렉토리 구조는 아래와 같다.

backend
ㄴ model1
   ㄴ loader.py
   ㄴ preprocessor.py
   ㄴ model.py
ㄴ model2
   ㄴ preprocessor.py
   ㄴ model.py
   ㄴ api.py
app.py
server.py
config.py

app.py에서 Flask app을 구현하고, server.py에서 backend server를 구현한다.

모델에 대한 구현은 내가 담당한 부분이 아니기 때문에, 상세히 기록하지는 않는다.

각 모델이 model.py에서 정의되는 Model1 혹은 Model2 클래스에서 predict 메소드를 호출하면 inference 결과가 나온다. inference 과정에서 load, preprocess, api 등 필요한 로직을 사용한다. 그리고 inference 결과로 나올 것이라 예상되는 데이터 형태에 맞추어 dummy data를 반환하도록 했다.

사실 원래 Model1의 경우 Tibero DB의 result table에 결과를 INSERT해야 하지만, 일단은 response로 dummy data를 반환하는 것으로 가정하고 개발했다.

## app.py

from flask import Flask, request, jsonify
import json
import socket

from config import HOST, PORT

# Flask app
app = Flask(__name__)

# model1 routing
@app.route('/model1'):
def model1():
	# date for model inference
    req = request.data
    req_data = json.loads(req.decode())
    date = req_data['date']
    
    # send message via socket to server
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client_socket.connect((HOST, PORT))
    client_msg = f'model1, {date}'.encode()
    client_socket.sendall(client_msg)
    
    # receive message(model result) via socket from server
    server_msg = client_socket.recv(65535)
    client_socket.close()
    response = server_msg.decode('utf-8')
    return jsonify(response)

# model2 routing
@app.route('/model2')
def model2():
    # data for model inference
    req = request.data
    req_data = json.loads(req.decode())
    
    # send message via socket to server with data in request body
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client_msg = f'model2, {data}'.encode()
    client_socket.sendall(client_msg)
    
    # receive message(model result) via socket from server
    server_msg = client_socket.recv(65535)
    client_socket.close()
    
    response = server_msg.decode('utf-8')
    return jsonify(response)
    

if __name__ == '__main__':
    app.run(debug=True)

Flask app이 라우팅 후 각 모델을 호출하기 위해 server에 알림을 보내는 부분이 중요했다. 요청이 들어 오면 client 소켓을 열어 메시지와 데이터를 server 소켓에 전송한다. server 소켓이 model inference 결과를 메시지로 전송하고, 이 메시지를 받은 후 client 소켓을 닫는다.

해당 코드를 구현할 때 주의해야 할 점은 소켓 생성이 각 url별 함수 안에서 이루어져야 한다는 것이다. 함수 밖에서 client 소켓을 생성하게 되면, Flask app server가 열려 있는 동안 계속해서 client 소켓이 열리게 된다. client 소켓은 client의 요청이 들어올 때만 열면 된다.

그렇지 않으면(예컨대, 위의 코드에서 6라인 혹은 8라인 사이에서 `client_socket = socket.socket()`과 같은 코드를 작성하는 경우이다), 아래와 같이 Flask app server를 종료한 후에야 server에 메시지가 전송되는 불상사를 겪게 된다. Flask app server가 동작하는 동안 계속해서 client 소켓을 생성하기 때문에 send를 타지 못하는 것이 아닐까 하는 추측을 해 보았지만, 좀 더 연구해 볼 필요가 있다.

분명 client socket이 연결되고, 오른쪽 Flask app server의 client socket에서 메시지를 보냈지만, 왼쪽 server 코드에서 아무 것도 받지 못한다.

## server.py

import socket
import json
from threading import Thread

from model1.loader import DataLoader
from model1.preprocessor import DataPreprocessor
from model1.model import Model1
from model2.model import Model2
from config import HOST, PORT, DSN


class ClientThread(Thread):
    def __init__(self, host, port):
        Thread.__init__(self)
        self.host = host
        self.port = port
        self.server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        # prevent WinError 10048 error 
        self.server_socket.setsockopt(
            socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        self.server_socket.bind((self.host, self.port))
        self.server_socket.listen(10)
    
    def run(self):
        while True:
            client_socket, addr = self.server_socket.accept()
            while True:
                client_msg = client_socket.recv(1024)
                if not client_msg:
                    break
                data = client_msg.decode().split()[-1]
                if b'model1' in client_msg:
                    data_loader = DataLoader(dsn=DSN)
                    rows = data_loader.fetch(data=data)
                    data_preprocessor = DataPreprocessor(rows=rows)
                    data = data_preprocessor.preprocess()
                    model = Model1(data)
                else:
                    model = Model2(data)
                
                result = model.predict()
                result_json = json.dumps(result)
                client_socket.sendall(result_json.encode())
            client_socket.close()
        self.server_socket.close()
        
 
 if __name__ == '__main__':
     thread_client = ClientThread(HOST, PORT)
     thread_client.start()
     thread_client.join()

여러 클라이언트의 요청을 실행하기 위해 쓰레드를 활용하였다. threading.Thread 클래스를 상속받아 쓰레드가 실행할 run() 메소드를 재정의하면 된다. 각각의 쓰레드에 client 소켓을 보고 있는 server 소켓이 있다. 쓰레드가 시작되기 전까지 server socket은 listen, bind 상태로 client 소켓을 바라 보고(?) 있다. 쓰레드가 시작되어 server 소켓이 client 소켓의 연결을 accept하면, client 소켓과 server 소켓이 연결되고, 이후 통신이 진행된다.

그 이후 로직은 간단하다. server 소켓은 client 소켓으로부터의 메시지를 해석하여 메시지에 'Model1'이 있으면 Model1을, 그렇지 않다면 Model2를 호출한다. ~~사실 이렇게 메시지를 해석해 분기 처리하는 것이 하드 코딩이 아닌가 싶긴 했는데, 당장 떠오르는 방법이 없었다.~~ 이후 각 모델로부터 predict 결과가 나오면 client 소켓에 다시 메시지와 predict 결과를 보내고, 소켓을 닫는다.

start()는 run 메소드를 호출해 쓰레드를 시작하는 역할을, join()은 새로 생성한 자식 스레드의 종료를 기다리는 것으로, 한 프로세스에서 여러 클라이언트의 요청을 처리할 수 있도록 했다.

이를 구현하는 과정에서 주의해야 할 점은 두 가지가 있었다. 첫째로, 소켓 메시지는 byte string이다. 따라서 server 소켓에서 client 메시지를 해석해 분기 처리를 할 때, b'' 형식의 문자열을 사용해야 한다. 둘째로, 소켓 재사용을 위해서는 socket 플래그로 socket.SO_REUSEADDR를 사용해야 한다.

특히 두 번째 경우, 플래그를 추가하지 않으면 아래 그림에서와 같이 에러가 발생한다. 위와 같이 플래그를 추가해주지 않으면, 일일이 해당 프로세스를 죽인 후 서버를 구동해야(kill [pid]) 한다.

## 테스트

테스트를 위해서 다음과 같이 클라이언트 터미널에서 curl 커맨드를 사용해 Flask app으로 요청을 보내면 된다. 아래와 같이 클라이언트 터미널에 dummy data가 response로 반환된다.

왼쪽부터 차례로 client, Flask app server, backend server

# 피드백

가장 우선적인 피드백은 구조 설계에 관한 것이었다. 애초에 Flask app server와 backend server가 나뉘어야 할 필요가 있는지, 그에 따라 둘 간에 네트워킹의 필요성이 있는지에 관한 부분이다.

데이터가 많고 모델이 무거운 경우라면, 위와 같은 구조로 Flask는 라우팅 역할을 담당하고, backend server에서 모델을 돌리는 게 필요할 수 있다. 그러나 이 서비스의 경우는 그렇게 무겁지 않기 때문에 Flask app server에서 처리하는 것이 더 나아 보인다. ~~(과하게 어렵게 짰다)~~
따라서 소켓 네트워킹 역시 필요하지 않다. 게다가 Flask가 애초에 socket listen, bind 처리를 다 해준다. ⇒ Flask의 동작 원리에 대해 제대로 알지 못한 채 구조를 설계했음을 알 수 있었다. 위의 피드백에서처럼 대용량 데이터 및 큰 모델을 돌려야 하는 경우여서 네트워킹이 필요하다면 모를까, 이 경우에는 애초에 Flask에서 처리하는 작업을 중복으로 하는 코드라고도 볼 수 있다.

모듈화에 대한 피드백도 있었다. 지금 코드에서는 model 부분에 load, 전처리 등의 코드가 모두 있는데, 이를 각 기능별로 나누어, 예컨대 데이터베이스에서 데이터를 로드하는 부분, 전처리하는 부분 등으로 나누어야 한다.

모듈화를 위해서 먼저 인터페이스부터 작성해야 한다.
각 모듈 간 이동해야 하는 데이터를 Data Access Object로 정의하는 것이 좋다.

그 외에 코드 구현 레벨에서의 피드백은 다음과 같은 것들이 있었다.

에러 핸들링이 필요하다.
아마 지금과 같이 backend server를 구현하면, 쓰레드가 생성되지 않을 것처럼 보인다.

처음 도전해 보는 서버 개발이었는데, 여러 모로 부족한 점이 많았다. 그럼에도 불구하고 처음부터 끝까지 구조를 설계해 보고, 요청과 응답이 돌아 오는 서버를 미약하게나마 구현해 본 것에 의의를 둔다. 또한, 피드백을 통해 개발에 대한 시야가 넓어질 수 있었다는 것에 매우 감사함을 느낀다.

앞으로 더 연구해 보고 싶은 부분은 다음과 같다.

인터페이스 작성 방법, 파이썬에서의 인터페이스
현재 구현된 backend/server.py 코드에서 실제 쓰레드 생성되는지 확인
Flask 쓰레드 구현 방식 확인
Flask app에서 client 소켓의 생성 위치에 따른 동작의 차이

[App Server] ODBC를 이용해 Tibero와 Python 연동하기

eraser — Fri, 30 Jul 2021 17:48:36 +0900

회사에서 애플리케이션 API 서버를 개발하며, Tibero에 적재된 데이터를 불러오는 모듈을 개발할 일이 생겼다.

Tibero 데이터 I/O 모듈의 위치는 다음 그림에서와 같고, 데이터베이스로부터 데이터를 추출해 Preparation 모듈로 넘기는 역할을 담당한다.

애플리케이션 API 서버 및 애플리케이션 내 AI 모델을 Python으로 개발할 예정이기 때문에, Tibero 데이터 I/O 모듈도 Python으로 개발하고자 한다.

Tibero의 tbCLI는 DBMS와의 연결을 지원하기 위해 ODBC, JDBC를 지원한다. 사실 Python에는 각 데이터베이스와 연동을 지원하는 라이브러리가 있는데(예컨대, mysql과 연동하기 위해서는 pymysql 등을 사용하면 된다.), 아직 Tibero와의 연동을 지원하는 라이브러리는 없다. 다만, Tibero는 ODBC 방식을 사용할 수 있도록 Tibero ODBC 드라이버를 제공하고 있고, 공식 문서에 Python과 연동하기 위해 pyodbc 라이브러리를 사용하라고 설명하고 있다.

이 글은 Tibero 데이터 I/O 모듈을 개발하는 과정에서 어떻게 ODBC 드라이버를 설정하고, pyodbc를 통해 Python과 연동할 수 있는지를 다룬다. ~~사실 며칠 동안 너무 많은 삽질을 한 게 아까워서 기억하고 싶어서..~~

Windows 10과 Ubuntu 20.04 환경에서 모두 개발을 진행해 보았다. OS는 다르지만, 모두 다음과 같은 동일한 과정을 거친다.

Tibero 클라이언트 설치
ODBC 설치
ODBC DSN 설정

처음에는 운영체제가 다른 것에 익숙하지 않아 어려움을 많이 겪었는데, 이후 정리하면서 보니 기본적으로 GUI에서 진행하는지 터미널에서 진행하는지, 파일 경로가 어디에 위치하는지 정도에서 차이가 나고, 각 단계별 진행 과정은 별반 다르지 않음을 깨달을 수 있었다.

# Windows 10

## tbCLI 설치

티베로6 클라이언트를 다운로드한 뒤, 다음과 같이 환경변수를 설정한다.

TB_HOME 환경변수를 설정한다

## tbodbc 드라이버 설치

이후 tbodbc 드라이버를 다운로드해 설치한다. Windows 10 64비트 운영체제이더라도, 32비트 클라이언트 프로그램을 다운로드 받아 설치해야 한다. ~~엄청난 삽질의 시작이었다.~~
tibero6을 64비트 버전으로 다운로드했더니, (당연히) 안에 포함되어 있는 ODBC 드라이버는 64비트 버전이었다. 그런데 이 드라이버를 설치하면, ODBC 데이터 원본(64비트)에서 Tibero 드라이버를 아예 발견할 수가 없다. 64비트 드라이버 자체가 레지스트리에 아예 등록이 되지 않았는데, 이유를 알고 싶어서 구글링해 봐도 32비트 프로그램을 받아야 된다는 글밖에 찾을 수 없었다.

64비트 드라이버를 설치한 후에도 드라이버를 찾을 수 없다

32비트 드라이버를 설치한 후, ODBC 데이터 원본 관리자(32비트)를 열어 확인하면, 다음과 같이 Tibero ODBC 드라이버가 잘 등록된 것을 볼 수 있다.

참고: ODBC 데이터 원본 관리자 위치

윈도우 검색 창에서 ODBC 데이터 원본 관리자를 검색하면 되지만, 사실 32비트와 64비트 원본 관리자는 서로 다른 경로에 저장되어 있다.

ODBC 데이터 원본 관리자(32비트): C:\Windows\SysWOW64\odbcad32.exe
ODBC 데이터 원본 관리자(64비트): C:\Windows\System32\odbcad32.exe

32비트와 64비트에서 돌아가는 프로그램은 서로 다른 경로에서 관리되는 듯하다.

어찌 되었든, 이런 이유로 Windows 10 환경에서 개발을 할 때는, 이후 Python 32비트 인터프리터로 개발해야 한다. Python 64비트 인터프리터를 사용하면, 이후 단계에서 다 성공을 했더라도 '[ODBC] 지정된 DSN은 드라이버와 응용 프로그램 간 아키텍처 불일치를 포함합니다.'와 같은 에러를 마주하게 된다.

## DSN 설정

ODBC 데이터 원본 관리자에서 Tibero ODBC 드라이버를 찾을 수 있으면, DSN을 설정하면 된다. DSN은 접근하고자 하는 데이터베이스 내 데이터 원본, 그리고 그 원본에 접근하기 위해 필요한 ODBC 연결에 대한 정보를 담고 있다.
시스템 DSN은 시스템 전체에서 사용되는 DSN으로, 권한이 있는 모든 사용자가 로그인할 수 있다. 반면, 사용자 DSN은 특정 사용자에 대해서만 만든 DSN이다. 지금은 GUI로 쉽게 구분되지만, 이후 Ubuntu에서 설정할 때는 설정 파일의 경로가 달라지므로 주의해야 한다. 일단 지금 단계에서는 사용자 별로 DSN을 다르게 설정해야 할 이유는 없으므로~~(추후 도커 이미지를 만드는 과정에서는 달라질 수 있으려나)~~, 시스템 DSN을 설정한다. DSN 설정 시 데이터베이스 접근을 위한 서버 IP, Port 등을 입력한다. 해당 정보는 이후 우분투에서 DSN을 설정할 때에도 그대로 사용된다.

설정 후, Test 버튼을 클릭해 연결이 성공하는지 확인해 보자.

# Linux(Ubuntu 20.04)

기본적으로 ODBC는 마이크로소프트에서 개발한 것이다. 이를 NIX 계열 운영체제에서 사용하기 위해서는 다른 라이브러리를 사용해야 하는데, 주로 Unix ODBC나 iODBC가 사용된다.
Tibero 공식 문서에서는 iODBC를 기준으로 설정하는 방법을 설명하고 있지만, 나는 Unix ODBC를 이용해 연결을 진행했기 때문에 해당 방법을 기록하도록 한다. 다행히(?) Linux에서는 tbCLI와 ODBC 드라이버가 동일하게 64비트여도 된다. 이 부분에서는 훨씬 간편했지만, 명령어, 커맨드 창이 익숙하지 않아 솔찬히 삽질했다.

## tbCLI 다운로드

Linux 64비트 tbCLI 프로그램을 설치한다.

## odbc 설치

apt 패키지 매니저를 통해 unixodbc, odbcinst를 설치한다.

apt install unixodbc
apt install odbcinst

설치가 잘 되었는지 확인해 보자.

eraser@eraser-desktop:/etc$ which isql
/usr/bin/isql

eraser@eraser-desktop:/etc$ odbcinst -j
unixODBC 2.3.9
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/eraser/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

## ODBC 드라이버 설정

tibero6을 설치한 경로에 보면, tibero6/client/lib에 libtbodbc.so 파일이 있는 것을 확인할 수 있다. 이 파일이 Linux 운영체제에서의 Tibero ODBC 드라이버이다.
해당 드라이버를 사용하기 위해, ODBC 드라이버 위치를 지정하는 odbcinst.ini 파일을 작성한다. 경로는 /etc/odbcinst.ini이다. "ODBC 방식으로 Tibero에 연결하고자 할 때는 이 드라이버를 사용해라" 정도로 이해하자.

odbcinst.ini 파일의 Driver, Setup에 $TB_HOME 환경변수를 사용하면, 인식하지 못한다.

odbcinst configuration 정보는 터미널에서 odbcinst -j 명령어를 통해 확인할 수 있다.

## DSN 설정

상술했듯, Linux 운영체제에서는 시스템 DSN과 사용자 DSN 설정 파일의 경로가 달라진다. 시스템 DSN은 root 디렉토리 하에, 사용자 DSN은 ~ 디렉토리 하에 존재하며, 파일 이름도 전자의 경우 odbc.ini, 후자의 경우 .odbc.ini가 된다. 즉, 시스템 DSN 설정은 /etc/odbc.ini에서, 사용자 DSN 설정은 ~/.odbc.ini에서 한다.
아래와 같이 시스템 DSN을 설정하자. [ODBC]에는 로그 파일의 추적 여부 및 그 단계, 추적 파일의 경로를 지정하고, 그 아래에 DSN 연결 시 사용할 정보를 작성하면 된다. 이 때 설정한 DSN 이름을 이후 접속 단계에서 계속 사용하게 된다. 나는 [tibero]로 설정했다.

2021.09.25. 내용 추가

간혹 dsn 연결 오류가 생기면, 설정 후 `odbcinst -i -s -f [odbc.ini 파일 경로]` 명령을 통해 Datasource를 등록해 주었는지 확인해 보자.
odbc.ini 파일을 설정할 때, 위의 사진처럼 Driver 경로를 전부 다 명시해 주어도 되지만, 아래와 같이 odbcinst.ini에 설정해 놓은 Driver 이름을 그대로 사용해도 된다.
```
[tibero]
Description=Tibero6 data source
Driver=Tibero
SERVER=
...
```

설정 후 접속이 되는지 확인해 보자. 터미널에서 isql 명령어를 사용하면 된다. 만약 위에서 DSN 정보에 사용자와 패스워드 정보를 설정하지 않았다면, 인자로 사용자와 패스워드까지 인자로 넘겨야 한다.

# Python에서 데이터 불러 오기

위와 같이 DSN 설정을 완료한 뒤, 접속에 성공하는 것까지 확인했다면, Python에서 연동할 차례다. pyodbc 라이브러리를 사용해 아래 코드를 작성하면 된다. "x"라는 데이터베이스 테이블에 접근해 각 컬럼의 정보를 출력하는 간단한 코드이다. 연결 시 연결 문자열에는 DSN 정보를 넣어 주면 된다. 위에서와 마찬가지로 DSN 정보에 사용자와 패스워드 정보가 존재하지 않는다면, 연결 문자열에 UID, PWD를 추가해주어야 한다. 또한, Windows 10 환경에서는 Python3 32bit를 설치해야 한다.

import pyodbc as odbc

conn = odbc.connect("DSN=tibero") 
cursor = conn.cursor() 

for row in cursor.columns(table="x"): 
    print(row)

위와 같은 과정을 거쳐 Tibero 데이터 I/O 모듈 개발을 위한 기본 작업을 마칠 수 있었다. 적지 않은 고생을 했는데, 돌이켜 보니 별 것 아닌데 내가 너무 몰라서 그랬던 것 같기도. 감사하게도 잘 정리된 글들 덕에 많이 배울 수 있었다.

https://jinisbonusbook.tistory.com/65

파이썬(python) 티베로 DB 접속 방법 - ODBC

이번 포스팅은 파이썬에서 데이터베이스에 연동하는 방법에 대한 내용입니다. 데이터베이스는 오라클, MS-SQL, mysql , PostgreSQL 등등 여러가지가 있습니다. 이중 국산제품인 데이터베이스인 티베로

jinisbonusbook.tistory.com

https://blog.boxcorea.com/wp/archives/2881

Ubuntu+Tibero+Python3+ODBC 연결하기

Ubuntu 18.04에서 python3과 tibero 데이타베이스 연동하기 Tibero는 python 드라이버를 지원하지 않으므로, ODBC를 통해서 연결해야한다. 우분투리눅스에 ODBC를 아래 명령어로 설치한다. [crayon-6104971033ecb5640

blog.boxcorea.com

https://blog.neonkid.xyz/179

리눅스에서 Unix ODBC를 사용해보자

안녕하세요. 2018년의 연말이 다가왔습니다. 오늘은 2018년의 마지막 포스트로 우분투에서 Unix ODBC를 설정하는 방법에 대해 알아보도록 하겠습니다. What is ODBC? Unix ODBC를 설치하기 전에, ODBC가 무엇

blog.neonkid.xyz

앞으로 모듈을 개발하는 과정에서 더 연구해 보고 싶은 부분은 다음과 같다.

사용자가 매 번 앱에 요청을 날릴 때마다 DSN을 설정해 주어야 하는가?
- DSN 설정 시 모듈에서 configuration 정보를 어디다 보관하고, 어떻게 설정해야 하는가
- DSN 설정을 위한 shell script를 어떻게 작성해야 하는가
Django에서 pyodbc를 연결해 데이터를 추출할 수 있는가?

어디다 기록할 지 몰라 여기로 온 Pandas 사용법

eraser — Sun, 2 May 2021 21:35:16 +0900

프로젝트 도중 데이터 분석이 필요할 때면, Pandas 쓸 일이 많다. 여기 저기서 자주 사용했는데, 정리하기에는 너무 사소해서 정리하지 않다 보니 자꾸 또 다시 찾아보게 된다. 사소하지만 내 기준에서 유용하고, 까먹고 싶지 않은 Pandas 사용법을 몰아 넣어 정리해 본다.

중복 답변 개수 체크

프로젝트 기획 단계에서 설문 중복 응답을 분류할 때 사용했던 코드이다.

df['앱이름_수정'] = df['앱이름'].str.replace(r"\([^()]*\)", "") # 괄호 안 설명 제거
new_df = df['앱이름_수정'].str.split(',', expand=True) # 중복 답안 각각의 컬럼으로 expand
new_df.stack().reset_index().value_counts([0]) # stack 후 개수 세기

'[서비스명 후보](서비스명 후보에 대한 설명)' 형태로, 중복 응답이 가능했던 문항에 대한 응답을 분류할 때 유용했다. 다른 건 다 괜찮고, 정규표현식을 사용해 서비스명에 대한 설명을 제거하는 과정이 좀 귀찮았기에 기록한다. ~~사실 정규표현식은 쓸 때마다 찾아봐야 해서 넘나리 어렵..~~.

$, $: `(`로 시작해서 `)`로 끝나는 문자열
[]*: `[]` 안의 패턴과 일치하는 문자열 모두
^(): `()` 안에 등장하는 문자열을 제외한 모두. 여기서는 ()안에 아무 것도 없으므로 모든 문자

처음 설문 응답 데이터의 정제