필자는 평소 개발자에게 가장 중요한 덕목 중 하나가 글쓰기라고 생각하고 있다. 마침 글쓰기와 기술의 접점을 고민하고 이야기하는 “Write The Docs 서울 밋업”(링크) 이 있다고 하여 쉬고 싶던 주말이지만 만사를 집어치우고 참석하게 되었다. 사실 연예인 개발자분들을 직접 만날 수 있다는 기대감도 있었기 때문이다. (발표하시는 바로 앞자리에 앉았는데 정작 한마디도 못 건넸지만…)

발표에 앞서 “이 발표 자료는 공개할 예정이니 필기하실 필요가 없다"라고 하셨다. 하지만 뒤통수를 (좋은 의미) 몇 대 아니 몇십대 맞은 느낌이라 정리를 하지 않을 수가 없었고 오늘 느끼고 배운 마음을 쭉 유지하고 싶어(내 것으로 만들고 싶어) 후기를 작성해 본다. 더불어 제목에 감히 개발자 강추!라고 적을만큼 최근 밋업 행사 중에 손꼽을 정도로 좋았기 때문이다.

변성윤(소카) - 글쓰는 개발자 모임, 글또

필자도 가입만 하고 활동은 안 하는 중인 “글 쓰는 개발자 모임 - 글또” 모임에 대해 소개해주셨다. 글을 꾸준히 작성하기 위해 만들었고, 일정에 예치금을 내고 정해진 규칙에 의해 블로그에 글을 올리면 다시 돈을 환급받는 반강제적인 모임이라고 한다. 그뿐만 아니라 다른 분들이 글을 써서 공유를 하면 성윤님이 직접 피드백을 주며 개발 시 리팩토링을 하듯 더 나은 품질의 글을 쓸 수 있도록 도움을 주고 있다고 하신다. 이러한 피드백 문화가 1:N이 아닌 N:N이 되면 또 다른 동기부여가 될 것 같은데 … 하는 아쉬움을 느꼈다. 사실 “글을 꾸준히 작성"하는 부분이 필자도 매우 공감이 된다. 바쁘고, 귀찮고, 글을 쓰려면 욕심이 생기고 그러다 미루고… 그 동기부여가 “돈” 일수밖에 없는 현실이 아쉽긴 한데 오히려 그 “돈"만큼 동기부여가 잘 되는 것도 없을것 같다. (헬스장 1년 권 계약하고 돈이 아까워서라도 나가는 느낌으로…) 올해 새로운 기수를 모집한다고 하니 그때는 꼭 지원해서 글을 꾸준히 쓰는 습관을 길러보고 싶다.

김대권(당근마켓) - 기술 블로그 생존 전략 : 구글 시대의 글쓰기

얼마 전에 한번 쓱 보고 정독할 수밖에 없던 포스팅인 [좋은 기술 블로그를 만들어 나가기 위한 8가지 제언](https://www.44bits.io/ko/post/8-suggestions-for-tech-programming-blog 을 작성하시고, 해당 기술블로그 를 운영하시고 계시는 김대권 님께서 글을 왜 쓰는지, 그리고 어떻게 하면 사람들에게 잘 읽힐 수 있을지에 대해 구글 검색엔진 관점에서 정리해주셨다. 우리는 보통 읽히기 위해 공개된 글을 쓰기 때문에 좋은 글을 쓰는 게 선행되어야 하지만 반대로 어떻게 하면 잘 읽힐 수 있을지에 대해 고민이 필요한 부분 같다. 요즘은 소셜미디어나 검색을 통해 글이 공유되고 검색되는데 장기적으로 봤을 때는 검색엔진에 노출이 돼야 한다고 하신다. 또한 검색엔진은 백과사전처럼 정답을 알려주는것이 아닌 “거대한 추천 시스템"의 관점으로 접근해야 하며, 글의 양이 너무 크거나 적으면 안 되고 적당한(?) 수준을 지켜야 이를 검색엔진이 알아서 판단한다고 한다. 또한 [What nobody tells you about documentation (번역본)](http://blog.weirdx.io/post/60414 이라는 것도 소개해주시며 결국엔 글 내용의 자체가 좋아야 한다고 재차 강조하셨다. (매우 공감, SEO 아무리 잘 설정해봤자 내용이 안 좋으면 말짱 꽝)

홍연의(LINE) - To. 지식 공유를 시작하려는 개발자, From. 당신의 든든한 서포터 Developer Relations팀

다소 생소한 Developer Relations 팀에 대해 소개를 해주시며 꼭 기술 관점이 아닌 다양한 분야에서 해당 팀이 어떤 지원을 해주고 있는지에 대해 알려주셨다. 기술 블로그 운영, 소셜 페이지 관리, 개발 컨퍼런스, 세미나, 커뮤니티 후원 등등 개발자와 개발 문화를 알리는 모든 일을 하고 있다고 한다. 옆 회사(?)이지만 저런 개발자의 문화를 만드는 팀이 있다는 게 부럽기도 하였고, 가끔 세미나가 있는 걸로 아는데 공개적으로 하면 어떨까 하는 아쉬움이 있지만… 점차 private에서 public으로 확대될 꺼라 기대를 해본다. 발표를 내가 직접 들으며 이러한 문화를 만들 수도 있겠구나 하는 생각도 해봤다. 작게는 팀 단위부터 시작해서 서버/앱 등 개발자들을 모아두고 관심 있는 사람들끼리 공유하는 자리를 정기적으로 만드는… 중요한 건 “정기적"으로… 일단 나부터라도 시작을 해보자.

어떠한 작업(Job)이 있다고 가정해보자. 이를 “정해진 시간에 주기적” 이나 “필요할때” 작업을 수행하고 싶다면 어떤 툴(Tool)이 떠오르는가? 그리고 이 작업(Job)들의 실행이력 등 전체적으로 관리하고 필요에 따라 다양한 플러그인을 활용하여 입맛에 맞는 작업(Job)으로 구성하고 싶을때 가장 첫번째로 떠오르는 툴은 바로 “Jenkins” 다. (극히 필자 개인적인 생각일수도 있지만… ) 물론 리눅스 기반의 crontab 이나 다른 스케쥴러를 활용할수도 있다. 다만 필자 개인적인 느낌으로 나만의 Jarvis(?)처럼 내가 원하는데로 설정만 해두면 정해진 시간에 수행하고 그 결과를 로그로 남겨놓고 문제가 발생했을때 알림도 받을수 있으니 너무 좋은 툴이라 생각이 든다.

지난 포스팅에서는 Jenkins 를 설치하는 방법에 대해 알아보았다. (정확히 말하면 치트키 수준의… ) 이번 포스팅에서는 Jenkins에 노드를 추가하여 master-slave 분산환경으로 구성하는 방법과 Jenkins 버전을 업그레이드 하는 방법에 대해 정리해보고자 한다.

마침 필자의 팀에서 젠킨스를 분산환경으로 운영하고 있었는데 버전은 1.x … 간헐적으로 Jenkins 버전 이슈로 에러가 발생해서 업그레이드를 해야하는 상황이 생긴것이다. 시키지도 않은 일을 하면서 팀에 도움도 될겸, 포스팅도 할겸, 1석 2조 효과. 서버 환경은 CentOS 7.4 64Bit 에서 테스트 하였다.

Jenkins 버전 업그레이드 하기

Jenkins를 업그레이드 하게되면 기존에 있었던 Jenkins의 환경설정은 어떻게 마이그레이션 할까? Job 실행기록들은 그냥 날려버려야 하나? 걱정을 하며 구글링을 해본다. 그러면 “안해본것에 대한 두려움” 을 갖는 필자의 마음이 무색할 정도로 너무 간단하게도 그냥 기존에 있던 war 파일을 최신버전으로 교체하고 재시작 하라고 나온다. 읭? 뭐이리 간단해? 대부분의 문제들은 지레 겁부터 먹고 실행에 옮기지 못해서 않아서 해결을 하지 못하는게 절반 이상같다. 자, 바로 실행에 옮겨보자. 우선 버전 업그레이드를 테스트 하기 위해 일부러 낮은버전으로 설치를 해둔다. (필자는 1.609.1로 설치해봤다.) 그리고 버전 업그레이드 후 설정이 그대로 옮겨지는지를 확인하기위해 Security 설정을 해서 Jenkins 접근시 로그인 여부를 물어보록 설정해둔다.

설정이 완료되었으면 최신버전의 war를 다운받아 교체하고 재시작을 해준다. 그러면 너무나도 간단하게 버전이 업그레이드가 된것을 확인할수 있다. 그리고 처음에 설정한 Security 설정까지 그대로 유지되는것 또한 확인이 가능하다. 물론 구 버전에서 설치되었던 플러그인들이 버전업이 되며 그에 따라 지원하지 않는 문제들이 생길 수 있는데 이 부분은 플러그인을 업그레이드를 해준다거나 각 상황에 맞는 대응을 해줘야 한다. 이렇게 해서 생각보다(?) 너무 간단하게 버전업이 완료되었다.

Jenkins 분산환경 구성하기 (노드 추가하기)

이번엔 Jenkins를 분산환경으로 구성해보고자 한다. 이렇게 노드를 추가하며 분산환경을 구성하는 이유는 마스터-슬레이브(Master-Slave) 패턴의 장점을 얻고자 함이다. 마스터는 작업을 쪼개고 슬레이브로 구성된 노드에게 분배를 하게되면 슬레이브 서버는 마스터의 요청을 처리하고 리턴하게 된다. 마치 스타크래프트에서 일꾼을 늘려서 미네랄과 가스를 더 빨리 얻는것처럼 말이다.

여기서 필자가 가장 많이 삽질한 부분. 슬레이브 서버를 추가하는데 슬레이브 서버가 되는 서버에 동일하게 젠킨스를 설치하고 그들을 모두 연결하려 했던것… 마치 클러스터링 하는것처럼… 당연히 Jenkins 들의 묶음형태(?) 가 되야 할것같은 생각으로 시도하였지만 엄청난 삽질의 연속이 되어버렸다. 알고보니 마스터 Jenkins에서 슬레이브 서버에 작업을 전달할수 있도록 연동만 시켜주면 자동으로 Agent를 마스터 Jenkins가 슬레이브 서버에 설치/실행을 하고 작업을 분할하는것을 확인할 수 있었다. 자, 그럼 시작해보자.

1. 마스터 서버에서 공개키와 개인키 생성 먼저 마스터 서버와 슬레이브 서버를 SSH로 통신할수 있도록 SSH 키 설정을 해준다. 통상 홈 디렉토리 하위 .ssh 폴더에서 생성한다.

ssh 키 생성
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/~/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /~/.ssh/id_rsa.
Your public key has been saved in /~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ user@hostname
The key's randomart image is:
+---[RSA 2048]----+
|oo. .            |
|o... o  +        |
|. .o  o+.o       |
|.++++. +o+o..    |
|o.+*=.o.SEoo=    |
| .  o+.*...+ +   |
|   .. + +.  +    |
|     + .     .   |
|      ...        |
+----[SHA256]-----+

공개키 확인
$ cat id_rsa.pub
ssh-rsa AAAAB3Nza~~~~~~~~eQKcx8B6uAflRm1J8In1 user@hostname

2. 슬레이브 서버에서 마스터 서버에서 만든 공개키를 등록 슬레이브 서버에서는 마스터 서버에서 SSH 접속을 허용해야 하기때문에 마스터 서버에서 생성한 공개키를 등록해준다. 슬레이브 서버의 홈 디렉토리 하위 .ssh 폴더아래 파일을 만들고 위 공개키를 넣어주자.

$ vi authorized_keys
ssh-rsa AAAAB3Nza~~~~~~~~eQKcx8B6uAflRm1J8In1 user@hostname

3. Jenkins 에서 Credentials 을 만들때 Private Key 설정을 “From the Jenkins master ~/.ssh"으로 설정한다. 나중에 이 정보로 인증을 처리한다.

4. 노드를 추가하고 조금 있으면 마스터 노드가 슬레이브 서버에 에이전트를 설치/실행하고 연동이 된것을 확인할수 있다.

실제로 슬레이브 서버에서 프로세스를 확인하면 아래처럼 에이전트( slave.jar )가 설치/실행되고 있는것을 확인할수 있다.

작년 7월 12일부터 시작한 필자의 첫 토이프로젝트인 기술블로그 구독서비스. 오픈할 때까지만 해도 “AWS 프리티어를 사용하고 있는 1년 안에 구독자가 설마 1,000명이 넘겠어?” 라고 생각을 했었는데 오픈을 하고 220일째 되는 바로 어제 어느덧 벌써 구독자가 1,000명을 달성하게 되었다. 그 기념으로 그동안 미뤄두었던 기술블로그 구독서비스 개발 후기 시리즈의 3부를 쓰고자 한다.

혹시 전에 내용을 보고자 하면 아래 링크에서 확인할 수 있다.

• 1부 : 왜 만들게 되었는가 그리고 어떤 구조로 만들었는가
• 2부 : 문제발생 및 Trouble Shooting
• 3부 : 앞으로의 계획과 방향성

그간 어떤 식으로 서비스를 운영했는가?

(한마디로 정리할 순 없는 지난 220일이었지만…) 딱 한마디로 정리하자면 엄청나게 많은 것을 배우고 경험할 수 있었으나 그만큼 힘들었던 시간들이라고 말할 수 있을 것 같다. 2부에서 이야기한 문제 발생에 따른 Trouble Shooting들도 있었지만 운영을 해오다 보니 사전에 생각하지도 못한 부분에서 문제가 생기는 정말 다양한 경험을 할 수 있었기 때문이다.

• 블로그 포스팅을 수집하는 과정에서의 문제 일부 블로그 RSS url에 접근을 할 때 요청에 대한 응답이 무한대로 멈춰버리는 현상이 간헐적으로 있었다. 이는 별도의 타임아웃을 설정하지 않았기 때문이다. 그래서 어느 정도의 타임아웃을 두고 시간 내에 응답이 없을 경우 다음 포스팅으로 넘어가도록 하였다. (타임아웃은 아주 기본적인 부분인데…)

requests.get(rss_url, timeout=10.0)

• 메일 발송하는 과정에서의 문제 가끔 메일이 오지 않는다고 친절하게 필자 개인 메일로 연락이 오는 경우가 있었다. 그때마다 서버의 상태를 보면 서버에 직접 접속조차 안 될 정도로 메모리 사용량이 너무 많아서 그때마다 AWS 웹 콘솔에서 강제로 서버를 재부팅을 하곤 했었다. 예전에도 이야기한 것처럼 AWS 프리티어를 사용하고 있다 보니 서버의 메모리가 1기가밖에 되지 않아서 … 제한된 시스템에서 서비스 운영을 할 수밖에 없는 상황이었다. 그래서 수집/발송 상태를 로깅으로 쉽게 볼 수 있고 스케줄링을 하기 위해 띄워둔 Jenkins(tomcat)를 중단하고 crontab으로 스케줄링을 하도록 하였고, 로깅은 별도의 파일로 로깅하도록 변경하였다.

/usr/bin/python3.6 /home/~~~/email_send.py > /home/~~~/logs/job/email_send_`date +\%Y\%m\%d\%H\%M\%S`.log 2>&1

또한 기존에는 빠르게 발송하기 위해 냅다 스레드로 돌렸는데 구독자 수가 많아지다 보니 RuntimeError: can't start new thread 라고 스레드를 만들 수 없다는 에러가 발생하기도 했다. 그래서 Pool을 사용하는 방식의 multiprocessing 을 도입하여 스레드로 발송할 때보다는 엄청나게 빠른 속도는 아닐지라도 효율적인 메모리 사용으로 2분 안에 1,000명에게 안정된 메일을 보낼 수 있게 되었다. (여담이지만 메일이 안 온다고 알려주셨던 분들께 이 자리를 빌려 감사의 인사를 전하고 싶다.)

from multiprocessing import Pool

...

pool = Pool(20)
pool.map(sendMail, email_list)

Heroku 나 Netlify 같이 서버를 직접 들어가지 않고 앱 형태로 배포하는 식으로 할 수도 있다. 하지만 초기에 이 토이프로젝트를 시작할 때 실 서비스와 최대한 동일한 시스템으로 운영해보고 싶었기 때문에 라즈베리파이에 설치하는 것까지 알아보다 결국 AWS를 사용하기로 하게 되었다. 그렇다면 AWS 프리티어를 사용하지 않고 별도의 서버를 구매하면 안 될까? 하는 생각도 해봤지만 최소한의 인프라로 최대한의 성능을 내보고 싶은 욕심(?) 때문에 1년간은 프리티어로 운영하고 그다음엔 (혹은 소프트웨어적으로 한계까지 도달한다면) 서버를 구매해서 운영하게 될 것 같다. (적어도 이후에도 이 서비스를 유지한다는 가정하에…)

아침 10시가 되면 자동으로 메일이 잘 발송되었는지, 혹 어제 수집된 것이 아니라 예전에 수집된 내용이 중복 발송된 건 아닌지, 발송은 구독한 사람 전부에게 잘 보내졌는지… 거의 매일같이 Daily-DevBlog 서비스를 살피며 지낸 것 같다. (하루라도 문제가 생기면 밤을 새워서라도 원인을 파악하고 다음 발송에는 정상적으로 발송되도록 수정하기도 했다.)

필자가 Elastic Stack을 알게된건 2017년 어느 여름 동기형이 공부하고 있는것을 보고 호기심에 따라하며 시작하게 되었다. 그때까지만 해도 버전이 2.x 였는데 지금 글을 쓰고있는 2019년 2월초 최신버전이 6.6이니 정말 빠르게 변화하는것 같다. 빠르게 변화하는 버전만큼 사람들의 관심도 (드라마틱하게는 아니지만) 꾸준히 늘어나 개인적으로, 그리고 실무에서도 활용하는 범위가 많아지고 있는것 같다.

그래서 그런지 최근들어 (아주 코딱지만큼 조금이라도 더 해본) 필자에게 Elastic Stack 사용방법에 대해 물어보는 주변 지인들이 늘어나고 있다. 그리고 예전에 한창 공부했을때의 버전보다 많이 바꼈기에 이 기회에 “그대로 따라만 하면 Elastic Stack을 구성할 수 있을만한 글"을 써보고자 한다. 사실 필자가 예전에 “도큐먼트를 보기엔 너무 어려워 보이는 느낌적인 느낌” 때문에 삽질하며 구성한 힘들었던 기억을 되살려 최대한 심플하고 처음 해보는 사람도 따라하기만 하면 “아~ 이게 Elastic Stack 이구나!”, “이런식으로 돌아가는 거구나!” 하는 도움을 주고 싶다.

+ 그러면서 최신버전도 살펴보고… 1석2조, 이런게 바로 블로그를 하는 이유이지 않을까? 다시한번 말하지만 도큐먼트가 최고 지침서이긴 하다…

Elastic 공식 홈페이지에 가면 각 제품군들에 대해 그림으로 된 자세한 설명과 도큐먼트가 있지만 이들을 어떤식으로 조합하여 사용하는지에 대한 전체적인 흐름을 볼 수 있는 곳은 없어 보인다. (지금 보면 도큐먼트가 그 어디보다 설명이 잘되어 있다고 생각되지만 사전 지식이 전혀없는 상태에서는 봐도봐도 어려워 보였다.) 이번 포스팅에서는 Apache access log를 Elasticsearch에 인덱싱 하는 방법에 대해 설명해보고자 한다.

전체적인 흐름

필자는 글보다는 그림을 좋아하는 편이라 전체적인 흐름을 그림으로 먼저 보자.

1. 외부에서의 접근이 발생하면 apache 웹서버에서 설정한 경로에 access log가 파일로 생성이 되거나 있는 파일에 추가가 된다. 해당 파일에는 한줄당 하나의 엑세스 정보가 남게 된다.
2. fileBeat에서 해당 파일을 트래킹 하고 있다가 라인이 추가되면 이 정보를 logstash 에게 전달해준다.
3. logastsh 는 filebeat에서 전달한 정보를 특정 port로 input 받는다.
4. 받은 정보를 filter 과정을 통해 각 정보를 분할 및 정제한다. (ip, uri, time 등)
5. 정리된 정보를 elasticsearch 에 ouput 으로 보낸다. (정확히 말하면 인덱싱을 한다.)
6. elasticsearch 에 인덱싱 된 정보를 키바나를 통해 손쉽게 분석을 한다.

한번의 설치고 일련의 과정이 뚝딱 된다면 너무 편하겠지만, 각각의 레이어가 나뉘어져있는 이유는 하는 역활이 전문적으로(?) 나뉘어져 있고 각 레이어에서는 세부 설정을 통해 보다 효율적으로 데이터를 관리할 수 있기 때문이다.

beats라는 레이어가 나오기 전에는 logstash에서 직접 file을 바라보곤 했었는데 beats가 logstash 보다 가벼운 shipper 목적으로 나온 agent 이다보니 통상 logstash 앞단에 filebeat를 위치시키곤 한다고 한다.

전체적인 그림은 위와 같고, 이제 이 글을 보고있는 여러분들이 따라할 차례이다. 각 레이어별로 하나씩 설치를 해보며 구성을 해보자. 설치순서는 데이터 흐름의 순서에 맞춰 다음과 같은 순서로 설치를 해야 효율적으로 볼수가 있다. (아래순서대로 하지 않을경우 설치/시작/종료 를 각각의 타이밍에 맞추어 해줘야 할것 같아 복잡할것같다.)

elasticsearch → logstash → kibana → filebeat

이 포스팅은 CentOS 7.4에서 Java 1.8, apache 2.2가 설치되어있다는 가정하에 보면 될듯하다. 또한 각 레이어별 설명은 구글링을 하거나 Elastic 공식 홈페이지에 가보면 자세히 나와있으니 기본 설명은 안하는것으로 하고, 각 레이어의 세부 설정은 하지 않는것으로 한다.

Elasticsearch

공식 홈페이지

다운받고 압축풀고 심볼릭 경로 만들고 (심볼릭 경로는 선택사항)
$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.6.0.tar.gz
$ tar zxvf elasticsearch-6.6.0.tar.gz
$ ln -s elasticsearch-6.6.0 elasticsearch

설정 파일을 열고 추가해준다.
$ cd elasticsearch/conf
$ vi elasticsearch.yml
path.data: /~~~/data/elasticsearch (기본경로에서 변경할때추가)
path.logs: /~~~/logs/elasticsearch
network.host: 0.0.0.0 # 외부에서 접근이 가능하도록 (실제 ip를 적어줘도 됨)

elasticsearch 의 시작과 종료를 조금이나마 편하게 하기위해 스크립트를 작성해줌 (이것또한 선택사항)
$ cd ../bin
$ echo './elasticsearch -d -p es.pid' > start.sh
$ echo 'kill `cat es.pid`' > stop.sh
$ chmod 755 start.sh stop.sh

혹시 아래와 같은 에러가 발생할경우 공식문서 대로 진행해준다.

초창기 신입시절에 배우거나 사용했던 기술적인 방법들이 있다. 시간이 지날수록 왠만해선 다른방법은 사용하지 않으려 하고 습관처럼 기존에 사용했던 방법을 고수하는 버릇이 있다. 그 이유는 과거에 사용했을때 아무 탈 없이 잘 되었기 때문에, 그리고 빠른 구현 때문이라는 핑계일 것 같다. 이러한 버릇은 비단 이 글을 적고있는 필자 뿐만이 아니라 대부분의 개발자들이 가지고 있을꺼라 조심스레 추측해본다. (아니라면…더욱 분발 해야겠다…ㅠ) 최근 운영하고 있는 서비스에서 장애 상황까지 갈수있는 위험한 상황이 있었는데 팀내 코드리뷰를 통해 문제점을 파악할 수 있었다. 그 원인은 Spring MVC Controller 레벨에서 redirect 처리를 할때 return값의 Cardinality가 높을경우 다음과 같이 사용하면 안된다고…

@RequestMapping(value = "/test", method = RequestMethod.GET)
public String test() {
	String url = "어떠한 로직에 의해 생성되는 url";
	return "redirect:" + url; // <- 위험 포인트!
}

이 코드가 왜? 어디가 어때서? 이제까지 Controller 레벨에서 redirect 처리를 할때 아무생각없이 위에 있는 코드 형태로 구현을 했는데 저러한 코드 때문에 OOM이 발생하여 fullGC 가 여러번 발생하고, 일시적으로 서비스가 지연되는 현상이 발생했다고 한다. 자주 사용하던 방법이였는데 장애를 유발할수 있는 위험한 방법이였다니… 이번 포스팅에서는 이러한 방법이 왜 잘못되었는지 실제로 테스트를 통해 몸소(?) 체감을 해보고, 그럼 어떤 방법으로 redirect 처리를 해야 하는가와 개선을 함으로써 기존방식에 비해 어떤점이 좋아졌는지에 대해서 정리해보고자 한다.

뭔가 내것으로 만들기 시리즈물이 나올것만 같은 느낌이다…

기존방식의 문제점 재현 및 다양한 원인분석

기존방식으로 했을때 왜 OOM이 발생했을까? 우리는 개발자이기 때문에 이런저런 글들만 보고 추측 할것이 아니라 직접 재현을 해보고 다양한 시각에서 원인분석을 해보자. 먼저 기본적인 Spring MVC 뼈대를 만들고 redirect 하는 return 값의 Cardinality가 높도록 random string 을 만들어 주도록 한다. 즉, /random을 호출하면 /result/ETmHfowFkU처럼 random string 이 만들어 지며 redirect 처리가 되는 매우 심플한 구조이다.

// Spring 버전은 4.0.6.RELEASE
@Controller
@RequestMapping("/")
public class TestController {
	@RequestMapping(value = "random", method = RequestMethod.GET)
	public String random() {
		return "redirect:result/" + UUID.randomUUID();
	}

	@RequestMapping(value = "result/{message}", method = RequestMethod.GET)
	public String result(ModelMap model, @PathVariable String message) {
		model.addAttribute("message", message);
		return "result";
	}
}

또한 해당 프로젝트에서는 AOP를 사용하고 있었기 때문에 그때와 동일한 상황으로 재현을 하기 위해 AOP관련 설정도 추가해준다.

@Configuration
@EnableWebMvc
@EnableAspectJAutoProxy
@ComponentScan
public class HelloWorldConfiguration {
	
	@Bean(name="HelloWorld")
	public ViewResolver viewResolver() {
		InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
		viewResolver.setViewClass(JstlView.class);
		viewResolver.setPrefix("/WEB-INF/views/");
		viewResolver.setSuffix(".jsp");

		return viewResolver;
	}
}

이렇게 한뒤 tomcat으로 최대/최소 메모리를 256m으로 설정후 해당 모듈을 띄워준다. 그다음 메모리 상태를 보기 위해 tomcat에 pinpoint를 연동하고 마지막으로 호출테스트를 위해 nGrinder을 설정해준다. 특별한 설정은 없고 위 컨트롤러의 url (/random) 을 여러번 호출하도록 하였다. nGrinder을 설정하는대에는 이 블로그 포스팅을 참고해서 설정하였다.

자, 이제 테스트를 시작해보자. (마치 수술 집도하는것 같은 기분으로…간호사~ 칼!)

1. nGrinder nGrinder의 기본 스크립트에서 url만 해당 서버로 호출되도록 바꿔주고 총 가상 사용자는 2,000으로 시간은 5분으로 설정후에 테스트 시작을 하였더니 다음과 같은 그래프를 볼수 있었다.

TPS가 불안정해지다가 어느시점부터 낮아지는것을 확인할 수 있다. 이게 서비스 였다면 사용자가 접속하는데 불편을 느꼈을꺼라 추측을 해본다. 또한 아주 간단한 random string 을 리턴하는 페이지 임에도 불구하고 에러 응답이 적지 않은것을 확인할 수 있었다.

2. pinpoint 메모리 상태는 어떤지 확인하기 위해 pinpoint를 확인해보면 다음과 같은 그래프를 볼수 있었다.

보기만해도 심장이 벌렁벌렁(?) 뛸 정도로 무서운 그림이다. 실제로 서비스에 (이정도까진 아니였지만) 비슷한 상황이 발생했었다. 메모리가 테스트를 점점 하면 할수록 올라가다가 fullGC가 발생하더니 대나무 숲에 있는 대나무마냥 fullGC가 빼곡히 발생하였다. (이러니… 페이지 접근에 지연이 생긴것 같다.)

만약 1번부터 10번까지 번호표가 있는 사람들 총 열명에게 혼자서 동일한 내용의 메일을 보낸다고 가정해보자. 그리고 메일 발송시 한번에 한명에게만 보내야 하는 제한사항이 있을때 과연 당신은 어떤식으로 보내겠는가? 이어서 읽지말고 한번 생각해보자. 아무것도 고려하지 않고 단순하게 생각한다면 1번 보내고 > 2번 보내고 … 9번 보내고 > 10번 보내는 방법이 먼저 떠오르게 된다. (for loop 1 to 10 … ) 하지만 보내야 할 사람들이 많아져서 백명, 천명 많게는 천만명에게 보내야 할 경우 방금과 같은 순차적인 방법을 사용하면 너무 늦게 발송된다는건 코드를 작성하지 않아도 알 수있는 문제… 그렇다면 어떤 방법으로 보내야 보다 빨리 보낼수 있을까? 이번 포스팅에서는 필자가 운영하고 있는 서비스에서 기존에 있던 병렬프로세스를 어떤식으로 최적화 했는지, 그래서 결국 얼마나 빨라졌는지에 대한 과정을 정리해 보고자 한다. 비단 메일 발송이나 앱 푸시 등 특정 도메인에 국한되지는 않고 전반적인 프로세스에 대해 이해를 한다면 다른 곳에서도 비슷한 방법으로 활용할 수 있을꺼라 기대 해본다.

상황파악 및 목표

(원할한 이해를 돕기 위하여) 먼저 필자가 운영하고있는 서비스를 간략히 소개부터 해야겠다. (그렇다고 필자 혼자 다 하는건 아님^^;…) 셀럽의 방송이 시작되면 구독한 사용자에게 각 모바일 기기에 설치되어있는 앱으로 알림을 보내어 예정에 없던 깜짝 라이브 방송이나 VOD 영상 오픈을 보다 빠르게 확인할 수 있도록 제공하고 있다. 여기서, 알림이 늦게 발송되면 셀럽은 방송을 시작하고 팬들이 들어오기까지 기다려야 한다거나 반대로 팬들은 방송 시작하고 뒤늦게 방송을 보게되는 불편함이 생기게 된다. 그리고 중복으로 알림이 발송되거나 특정 사용자들에게 발송이 누락되면 안 되는 등 “알림” 이란 기능은 서비스에 있어서 중요한 기능 중에 하나라고 할수 있다.

여기서 “발송 시간"은 처음 발송작업 시작부터 마지막 사용자에 대해 사내 발송 플랫폼으로 발송 요청을 하기까지의 시간을 의미

그리고 “채널” 이라는 샐럽단위의 그룹이 있는데 영상과 채널의 관계는 1:N이다. 즉, 하나의 영상을 여러 채널에 연결시킬수 있어서 하나의 영상에 대해 여러 채널들에게 연결을 시켜놓으면 채널을 구독하고있는 각각의 사용자에게 모두 알림을 발송 할수가 있게 된다.

우선, 알람이 사용자에게 전달되기까지의 큰 흐름은 다음과 같다.

1. 서비스에서 보낼 대상과 보낼 정보를 조합하여
2. 사내 푸시 발송 플랫폼인 사내 발송 플랫폼에게 전달을 하면 플랫폼에 따라 발송이 되고
3. 최종적으로는 사용자의 모바일 기기에 노출이 됨

간단하게 “병렬로 발송하면 되지 않을까?“라는 필자의 생각이 부끄러워질 정도로 이미 redis, rabbitMQ 를 활용해서 아래 그림처럼 병렬 프로세스로 구성되어 있었다.

1. 라이브가 시작되거나 VOD가 오픈될 경우 api가 호출이 되고 다시 배치 서버에게 영상의 고유번호를 전달
2. 전달받은 영상의 고유번호를 rabbitMQ의 수신자 조회 Queue에 produce
3. 수신자 조회 Queue의 consumer인 수신자 조회 모듈에서 영상의 고유번호를 consume 후 아래 작업을 진행 3-1. 영상:채널 은 1:N 구조이기 때문에 여러 채널의 사용자들에게 알림을 발송할 수 있고, 영상에 연결된 채널들의 user를 db에서 가져온다. 3-2. 가져온 user를 (중복으로 알림이 발송되지 않기 위해) java set에 담고 모든 채널을 조회했다면 redis에 sorted set으로 담는다. 3-3. 적당한 크기로 분할하고 이 분할정보를 발송 Queue에 produce
4. 발송 모듈에서 분할 정보를 consume 하고 아래 작업을 진행 (병렬처리) 4-1. redis 에서 user 모음을 가져오고 4-2. 조회한 user에 해당하는 deviceId를 db에서 가져옴
5. deviceId와 컨텐츠 정보를 활용하여 적절한 payload를 구성 후 사내 발송 플랫폼 에게 전달

기존 구조에서 발송 시간은 서비스에서 구독자 수가 가장 많은 채널 기준으로 약 1.1천만 명에게 최종 11분 정도 소요되고 있었다. (맨 처음에 이야기 한 순차적인 방법이였다면… 훨씬더 오래 걸렸을꺼라 예상해본다…)