서비스를 처음 만들기 시작할때면 각 직군별로 생각하는 포인트가 다양하다. 설계, 기획, 디자인, 개발. 여기서 개발은 프로젝트 셋팅을 어떻게 해야하지? 하는 고민을 하기 마련이다. 아주 간단하게 하나의 모듈로 모든 기능을 담당하도록 만들 수 있지만 기능별로 모듈을 나눠서 셋팅하는게 관리측면에서 장점이라 생각한다.예를 들어보자. 도서관의 들어온 책 정보를 외부에 제공하는 “API”, 주기적으로 책 정보를 업데이트 하는 “Batch”. 이렇게 크게 두가지의 모듈이 있어야 한다고 가정했을때 어떤식으로 모듈을 설계할 수 있을까? 이번 포스팅에서는 스프링 부트와 메이븐을 활용해서 하나의 프로젝트(컴포넌트)에서 여러 모듈을 관리할 수 있는 Spring Multi Module을 셋팅하는 방법에 대해 알아보고자 한다. 필자도 셋팅하기 전에는 “그냥 하면 되는거 아니야?“라며 우습게 보다 아주 사소한 부분들에서 엄청난 삽질을 해서 그런지 꼭 포스팅으로 남겨놔야 겠다고 다짐했고 이렇게 정리를 할 수 있게 되어서 다행이라 생각한다. 어쩌면 우리가 있는 팀도 멀티모듈이 아닐까? 출처 : https://bcho.tistory.com/813" 어쩌면 우리가 있는 팀도 멀티모듈이 아닐까? 출처 : https://bcho.tistory.com/813 왜 멀티모듈로 셋팅할까? 위에서 예시로 이야기 한것처럼 현재 우리가 셋팅해야할 모듈은 크게 두가지 이다. API : 외부에 도서관에 들어온 책 정보를 알려주는 모듈 Batch : 주기적으로 도서관의 책 정보를 갱신하는 모듈 한번 생각을 해보자. 위에서 말한 모듈들 중에 동시에 사용할것만 같은 정보가 있다. “책 정보”. 각 모듈마다 “책 정보"를 가져오는 로직을 작성하는것 보다 한곳에서 해당로직을 구현하고 이를 여러곳에서 사용하는게 사용하는게 중복코드를 방지할수 있는 방법이란건 쉽게 알아차릴수 있다. 그렇다면 어떻게 모듈을 분리할수 있을까? 필자의 경험으로 미루어 볼때 크게 두가지 방법이 있는것 같다. 공통으로 사용하는 모듈을 jar로 만들고 이를 메이븐 원격 저장소에 deploy, 사용하는 모듈에서 디펜던시에 추가하여 사용 멀티모듈로 구성하고 사용하는 모듈에서 디펜던시에 추가하여 사용 첫번째 방법의 가장 큰 단점은, 공통으로 사용하는 모듈이 변경될때마다 버전을 바꿔주고 (안바꿔도 되지만 사용하는 모듈에서 캐시 갱신을 해야하는 불편함이 생긴다.) 메이븐 원격 저장소에 deploy를 해줘야 한다. 그에 반해 두번째 방법은 이런과정없이 함께 빌드만 해주면 끝나고 IDE에서 개발시 한 모듈에서 동시에 수정과 사용이 가능하기 때문에 훨씬 편리하다. 은총알은 없다 라는 말처럼, 정답은 없다. 하지만 이런저런 방법들을 미리 알아두면 적시적소에 사용할 수 있는. 필자가 다른글들에서도 언급을 자주하던 “나만의 무기"가 되지 않을까? 멀티모듈 셋팅하기 위에서 이야기 했던 “API”, “Batch"와는 별도로 공통으로 사용하는 모듈인 “Core” 이렇게 총 3개의 모듈을 만들예정이다. 다른 이야기지만, 공통으로 사용할 것 “같아서” 미리 공통로직을 작성하는 습관은 좋지 않는것 같다. 그러다보면 쓸데없이 공통로직이 무거워지므로 실제로 사용하면서 중복코드가 발생할때 그때 공통로직으로 리펙토링 해도 늦지 않는것 같다. (꼰데인가…) 구현하는 환경은 다음과 같다. Spring Boot 2.2.3 Maven IntelliJ 우선 IDE의 힘을 빌려 하나의 스프링 부트 프로젝트를 생성해본다. 다음 > 다음 > 다음" 다음 > 다음 > 다음 그 다음 만든 프로젝트에서 우클릭 후 새로운 모듈을 선택. Maven 모듈을 선택하고 적당한 이름을 적어준다. 다음 > 다음 > 다음 222" 다음 > 다음 > 다음 222 “API”, “Batch”, “Core” 라는 모듈을 추가하고 실제 모듈이 되는 “API”, “Batch"에 parent 와 dependencies 을 설정해주자. 그렇게 하고 각 Pom.xml을 보면 아래와 같다. (“API” 모듈에 대해서만 집중적으로 이야기 하려 한다. “Batch” 모듈도 동일한 형식으로 작성하기 때문.) 최 상위 Pom.xml (library) modules 하위에 멀티모듈로 설정한 모듈들의 이름이 들어가 있는것을 확인할 수 있다. <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <packaging>pom</packaging> <modules> <module>api</module> <module>core</module> <module>batch</module> </modules> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.2.3.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.taetaetae</groupId> <artifactId>library</artifactId> <version>0.

“회고"는 비단 개발 블로그 뿐만 아니라 어떠한 과정의 마지막에는 꼭 해야할 중요한 시간인 것 같다. 앞만보고 달려가자! 닥공! 라는 말이 있지만 사실 이 말이 성립되기 위해선 지난 과거에 대한 정리와 반성 그리고 무엇을 하려고 했는데 어떤 이유로 못했는지와 그 동안의 나 자신을 바라볼 수 있는 이 “회고” 시간이 필요하다. 벌써 2019년도 마무리가 되어간다. 작년보다 더 정신없이 달려온 올해. 내년엔 올해보다 더 멋지고 힘차게 출발하기 위해 필자의 한 해를 돌아보고자 한다. 그렇다면 회고는 어떻게 하는게 가장 좋을까? 무작정 타임라인 기반으로 1월엔 뭐했고 2월엔 뭐했고… 이 방법이 틀린건 아니지만 타임라인 기반으로 정리를 한 뒤 키워드별로 다시 정리하는 방식이 가장 맞을것 같다는 생각이다. 무엇을 했고, 뭐가 좋았고 어떤건 아쉬웠고. 그래서 내년엔 어떻게 할 것이고. 각자의 회고 방식에는 차이가 있겠지만 회고를 하는 이유, 그리고 회고라는 목표 중에 공통점은 “뒤를 돌아보고, 앞을 보기위한 힘을 찾는것” 이 아닐까 싶다. 내년 회고를 할때는 흑백이 아닌 컬러 사진을 넣을 수 있는 분위기가 될까?… 출처 : http://www.nanum.com/site/poet_walk/820914" 내년 회고를 할때는 흑백이 아닌 컬러 사진을 넣을 수 있는 분위기가 될까?… 출처 : http://www.nanum.com/site/poet_walk/820914 회사는 성장의 공간이 아닌것을 깨닳는 순간. (이야기에 앞서 필자는 현재 서비스 개발자임을 밝힌다.) 내년이 되면 컴퓨터쟁이가 된지 벌써 8년차. 매년 성장의 그래프를 그려보면 작년까지만 해도 우상향이었다. (그래프의 기울기는 매년 달랐지만) 허나 올해는 기울기가 0 이거나 오히려 마이너스가 된 것 같은 느낌이다. 왜일까. 키는 왜 더이상 성장을 안할까? (쓰읍…) 출처 : http://www.guro1318.or.kr/bbs/board.php?bo_table=data&wr_id=1723" 키는 왜 더이상 성장을 안할까? (쓰읍…) 출처 : http://www.guro1318.or.kr/bbs/board.php?bo_table=data&wr_id=1723 회사를 다니다 보면 아주 일반적으로 “시키는 일"을 하곤 한다. 주어진 업무를 정해진 기간 안에 스펙에 맞춰 개발하는. 아주 극단적으로 나쁘게 말하면 “도구"로 전락되어버릴 수도 있는 시간들. (개발자가 도구가 된다는 말은 너무나도 듣기 싫은 말중에 하나.) 흔히 말하는 CRUD(Create, Read, Update, Delete) 성의 개발 업무를 하곤 한다. 하지만 꼭 성과에 align(더 좋은 한국말을 찾고 싶은데…) 하는 일 말고도 허드렛일(일종의 서스테이닝?)을 할 경우도 있는데 그게 만약 재미없는 일이라면 어떨까? 필자는 그렇게 “시키는 일만 하며 재미없는 회사생활” 보다 “재미있게 개발하며 성장을 할 수 있는 회사생활” 이라는 기준을 가지고 한 해를 지내온 것 같다. 즉, “시키는 일"이 아닌 “시키지도 않은 일"을 찾아서 해가며. 예컨대, 처음에 잡았던 서비스 구조가 사용자가 많아지고 요구사항이 많아짐에 따라 복잡하고 성능을 저해하는 상황을 발견하고 미리 구조개선을 통해 성능과 효율이라는 두마리의 토끼를 잡는다거나. 지난 외부 세미나에서 듣고 인사이트를 얻어 팀내에도 적용해본 배치 무중단 배포 기능. 팀 내 코드리뷰의 활성화와 수동으로 해야할 업무들을 메신저 봇을 활용하여 자동화 한다거나. 서비스 지표 대시보드를 만들어 한눈에 서비스 상황을 볼 수 있게 별도의 개발 페이지를 만들어 보는 등. 다양한 업무 내/외 적으로 일을 찾아가며 + 필자의 개인 시간을 할애해 가면서 정말 재미있게 보내온 것 같다. 하지만 뒤를 돌아보면 “성장 했는가?” 라는 질문이 있다면 “그렇게 하고있는것 같아서 신나게 해왔는데 돌아보니 막상 뭘했나 하는 느낌이 든다” 라고 말할 수 있을 정도로 여러가지를 많이 하며 다양한 “경험"을 얻긴 했지만 실질적인 “성장"은 아쉽지만 부족한 한 해 였던것 같다. 회사가 원하는, 연차에 맞는 업무 역량과 개발 팀에서의 위치를 충족시키기엔 회사 안에서 성장하기엔 한계가 있다고 판단이 들었다. (이 생각이 왜 이제서야 들었을까.) 오픈소스나 새로운 언어를 회사 밖에서 혼자서 공부 하던지 여러명이서 스터디를 통해 습득을 해야하고 토이프로젝트 또한 회사와 별도로 진행하며 개발 스킬을 늘려야 할것 같다. 그 이유는 회사에서의 성장이 결국 나의 성과로 잡힐 수는 없는데 괜시리 기대를 하게 되기도 하고 특히 서비스를 운영하는 팀에서는 요즘 핫 하다는 개발 방법론이나 솔루션을 도입하기에는 다소 무리가 있기 때문이다.

신입시절. 배워야 할 것도 회사 업무도 많아 허우적대던 때가 있었다. 그렇게 하루에 3~4시간 자며 정신없이 하루를 보내던 날 문득 동기 형이 “개발자는 기술 블로그를 해야 돼!“라는 전혀 이해가 안 되는 말을 해온다. 이렇게 바빠 죽겠는데 블로그에 글까지 쓰라고? 말이 되는 소릴 하라며 반박하다 못내 이기는 척 하나 둘 글을 쓰기 시작했고, 다른 유명 블로거처럼 엄청나진 않지만 하루에 1,000~2,000명 정도 들어오며 점점 성장해 가는 나만의 기술 블로그가 되었다. 미약하지만 처음보다는 성장하고 있는 블로그 PV(Page View)" 미약하지만 처음보다는 성장하고 있는 블로그 PV(Page View) 또한 필자의 개발자 경력(?)을 돌이켜 보자면 기술 블로그를 하기 전과 하고 난 후로 나뉠 만큼 기술 블로그는 개인적으로 엄청난 영향력이 되었다. 이 기회를 빌어 동기 형에게 감사의 인사를 전하고 싶다. 형. 보고 있죠? ;] 이번 포스팅은 꼭 “블로그를 하자” 라기 보다 “글을 왜 써야 하고 어떻게 써야 하는지"에 대해 이야기해보고자 한다. 처음 이 글을 쓰려고 마음먹었을 땐 개발자라는 직군에 국한되지 않고 누구에게나 적용될 정도의 범용적인 글을 쓰려 했으나 “S"의 조언으로 독자(타깃)을 최대한 개발자에 맞춰 써보고자 한다. thanks to “S” 사실 조금만 검색을 해보면 특히 개발자에게 글쓰기가 얼마나 중요한지 찾아볼 수 있을 정도로 다양한 글들에서 “개발자가 왜 글을 써야 하는가"에 대한 내용이 언급이 되곤 했었다. 글을 쓰지 않던 개발자. 하지만 지금은 글쓰기가 정말 중요하다고 느끼며 적어도 2주에 하나 이상의 글을 쓰려는 현업 개발자의 시선에서 정리를 해보고자 한다. 그리고 마침 멘토링 해주고 있는 분께도 글 쓰는것에 대한 중요성을 알려주고 싶었고, 팀 내에도 공유를 하고 싶어 겸사겸사. 왜 글을 써야 할까? 비로소 내 것이 되기 위한 과정 프로그래밍 언어를 처음 배울때 꼭 만나는 문구 Hello World를 출력하시오. 이게 의미하는 의미가 무엇일까? 정말 새로운 세계를 알려주려 하는 것 일까?(그럴수도 있다…) 우리가 살아가며 “배움"이라는 과정은 대부분 비슷하겠지만 특히 IT 기술은 책을 다 읽었다든지, 동영상 강의를 다 들었다고 해서 내 것이 되었다고 말하기는 어려울 것 같다. 직접 키보드를 두드려 가며 거기서 얻을 수 있는 또 다른 “인사이트” 가 생길 수도 있기 때문이다. 다른 예로, 운영하던 시스템이나 서비스에서 장애를 맞았다고 가정해보자. 하지만 우리는 늘 그래왔듯 어떻게든 장애를 해결할 것이다. 이러한 상황에서 분명 “문제의 원인"이 있었을 테고 “해결 과정"이 있기 마련인데 이곳에서도 “인사이트"가 분명 있을 것이다. 이러한 “인사이트"를 글로 적다 보면 그냥 “아~ 그렇구나, 그랬었지” 하는 머릿속에서의 기억보다는 훨씬 더 오래 남을 것이고 혹여 글에서 정리를 잘못해 다른 사람들의 피드백이 있다면 더할 나위 없이 좋은 효과라고 생각이 된다. (이것이 바로 공유의 힘!) 더불어 글을 쓸 때 올바른 정보에 기반하여 쓰는 습관이 중요한데 그러다 보면 원래 쓰려고 했던 내용보다 더 깊게 알아가는 과정 속에서 또 다른 배움을 얻을 수 있는 반강제적 기회가 생길 수 있다. 누가 시키지 않았어도 배운 것에 대한 활용을 하고 싶은 생각이 들고 이를 또 글로 쓰고. 긍정적인 순환 속에 생겨나는 작은 발자국일지라도 성장해가는 자신을 느낄 수 있을 것이다. 몸이 기억하는 정리하는 습관 개발을 하다 보면 정말 간단한 “CRUD”(Create, Read, Update, Delete) 부터 시작해서 엄청나게 복잡한 도메인 지식에 기반하여 개발을 해야 하는 상황이 생긴다. 그럴 때면 머릿속으로 정리하는 것보다 그림이나 글을 써가면서 정리하는 게 좋다는 건 굳이 말하지 않아도 아는 사실. 글을 쓰다 보면 기승전결의 정리 방법과 목적이 무엇이고 근거가 무엇인지에 대해 구분하는 스킬이 늘어나는 것 같다.(적어도 필자는 기술 블로그를 운영하면서 정리하는 스킬이 그전보다 엄청나게 늘어났다고 자부한다.) 중국 속담중에 하나, 머릿속에 박혀 나오질 않는다.

지난 포스팅, 그러니까 우아한 형제들에서 초대를 받아 Spring batch 에 대한 테크세미나에 다녀 왔다. 그 중 가장 인상깊었던 부분이 바로 무중단 배포. 차일피일 미루다 필자가 속한 팀에서도 배포때마다 가장 불편을 느끼고 있었던 부분이었기도 했고, 그런가보다 하며 개념만 알고 넘어가기엔 무언가 양심에 찔려 직접 무중단 배포를 할 수 있도록 구성을 해보고 테스트까지 해보고자 한다. 상황 및 문제점 리눅스 서버에 Jenkins가 설치되어 있고, Spring batch 모듈을 실행시키고 있다. 수동으로 실행을 하거나, Jenkins RestApi를 이용해서 실행을 할 수 있지만 주로 정해진 시간 즉, 스케쥴링에 의해 실행되곤 한다. 스케쥴링의 가장 작은 단위는 1분단위 배치도 있기 때문에 24시간 멈추지 않고 실행되고 있다고 무방하다. 하지만 배치 모듈이 수정되고, 배포를 하기 위해서는 다음과 같은 시나리오로 진행이 된다. Jenkins 설정의 끄기전 준비 를 실행하여 더이상 Jenkins에 의해 Spring batch 모듈(이하 Job)이 실행되지 않도록 한다. 새로운 Job은 더이상 실행되지 않지만 이미 실행중이였던 Job 은 강제로 중단을 하거나 Job 이 끝날때까지 기다린다. 실행중인 Job이 없을 경우 이제 배포를 진행한다. 배포가 완료되면 Jenkins 설정의 끄기전 준비를 해제한다. 실행중인 Job이 안끝나면 마냥 기다릴텐가? 출처 : https://m.post.naver.com/viewer/postView.nhn?volumeNo=14100660&memberNo=2032633" 실행중인 Job이 안끝나면 마냥 기다릴텐가? 출처 : https://m.post.naver.com/viewer/postView.nhn?volumeNo=14100660&memberNo=2032633 실행되는 Job을 중단하지 못하는 상황 즉, 실행중에 중단하면 트랜잭션이 깨져 무조건 기다려야만 하는 상황이라면 배포 또한 계속 지연될 수 밖에 없는 상황인 것이다. Spring boot에 java config 를 활용하고 딱 jar 파일 하나를 실행하는 방식이라면 jar파일을 바꿔치기 하는 식으로 고민을 해볼수도 있을것 같다. 하지만 Legacy 코드가 아직 존재하여 일반 Spring 에 xml 로 config 하는 방식으로 운영중이라 jar파일 하나만 바꿔치기 하기엔 무리가 있는 상황. 은총알처럼 어디에서나 사용이 가능한 만병통치약 같은 방법은 없다. 언제나 그랬듯 현재 시스템(xml config 방식)에 가장 최적화된 방법, 그리고 java config 방식에서도 사용이 가능할것 같은 방법을 생각해 보았다. 무중단 배포를 가능케 하는 3가지 핵심 1. 배포를 매번 새로운 경로에 배포한다. 각 회사마다, 그리고 서비스마다 정말 다양한 배포 시스템이 있다. 그들의 공통점은 원격서버의 특정 경로에 빌드된 파일들을 밀어 넣어준다는 것. 시나리오는 다음과 같다. 배포할때마다 별도의 디렉토리를 생성한뒤 심볼릭 링크를 연결해준다. 배포는 1에서 연결한 심볼릭 링크에 배포되도록 설정, 결국 매번 만들어지는 디렉토리에 배포가 되게 된다. 여기서 중요한점은 “배포할 때마다 새로운 디렉토리에 배포가 된다” 와 배포시에는 항상 심볼릭 링크에만 배포를 하면 되기 때문에 “배포시스템이 새로 만들어지는 디렉토리의 경로를 몰라도 무방하다"는 점이다. #!/bin/sh cd /~~~/deploy/ # 임시 디렉토리 DIRECTORY_NAME=batch_$(/bin/date +%Y%m%d%H%M%S) mkdir $DIRECTORY_NAME 위 쉘 스크립트를 실행하면 batch_20191012205218 와 같은 디렉토리가 생성이 된다. 심볼릭 링크 관련해서는 바로 아래 이어서 설명하겠다. 2. 심볼릭 링크의 원래 링크를 즉시 변경 보통 심볼릭 링크 (즉, 바로가기) 의 경로를 변경하기 위해서는 아래처럼 지웠다가 삭제하는 식으로 했었는데 $ mkdir directory_a $ mkdir directory_b $ ln -s directory_a asdf $ ll asdf -> directory_a directory_a directory_b # directory_a 에서 directory_b 로 바꾸는 경우 (심볼릭 링크 자체를 삭제하고 다시 심볼릭 링크 생성) $ rm asdf $ ln -s directory_b asdf $ ll asdf -> directory_b directory_a directory_b 이렇게 되면 삭제하고 ~ 다시 만들어지는 타이밍에 배포가 되거나 실행이 되는 즉, 해당 경로에 엑세스 하는 경우 이전의 경로를 바라본다거나 의도했던 방식으로 실행이 되지 않는 상황이 발생한다. (찰나의 타이밍 이지만 필자는 이러한 문제로 이전의 경로를 바라보는 문제가 발생했었다.) 그래서 ln 의 옵션중인 -Tfs옵션으로 즉시 변경을 해주도록 하자. (ln man 참고) # 만든 임시 디렉토리로 배포될수 있도록 설정한다.

지난주 우아한 형제들에서 진행하였던 “9월 우아한 테크 세미나 - 우아한 스프링 배치” 에 다녀왔다. 필자에게 이번 9월은 정신이 어디에 있는지 모를만큼 바쁘고 힘들었지만 예전부터 궁금하기도 했고 요즘들어 관심을 갖던 “배치 어플리케이션"을 어떻게 하면 “우아한 방법"으로 사용할 수 있을지에 대해 여러 생각들이 있었기에 큰 기대를 가지고 지옥철을 견디며 잠실 근처에 있는 우아한 형제들 작은집으로 가게 되었다. 어떤 내용을 발표하였는지에 대해 기억잘하는 똑똑한 앵무새가 되어 정리하기 보다 주요 포인트에 대한 생각과 함께 참여를 못한 분들 위해서라기 보다 내 스스로 정리를 하기 위해 포스팅을 작성해 보고자 한다. (이번에도 불러주셔서 감사합니다 ^=^) 인트로 연사자 분은 워낙에 유명하신 분이라 별도의 설명이 필요 없이 운영하시는 블로그 주소로 대체를 해본다. 이번 행사에 초대되신 분들은 한번이라도 스프링 배치를 써분 분들을 대상으로 진행하게 되었다고 했는데 마침 필자도 팀 내에서 운영하고 있는 배치 어플리케이션을 보다 효율적이고 우아하게 바꿔보고자 하는 니즈가 있었기에 아마 초대된게 아닐까 싶다. 아기자기한 우아한 형제들 건물 내부" 아기자기한 우아한 형제들 건물 내부 더불어 발표전에 간략히 회사가 원하는 인재에 대하여 언급해주셨는데 그게 어찌나 공감이 가던지. 역시 생각이 남다른 회사구나 하고 다시한번 생각을. 자기보다 경험이 “적은” 사람에게 “설득을 당할 수” 있어야 하고, 자기보다 경험이 “많은 사람을 설득” 시킬 수 있어야 한다. 기본편 배치 어플리케이션이란 컴퓨터에서 사람와 상호작용없이 이어지는 프로그램(작업)들의 실행이라고 위키피디아에 간결&명료하게 정리되어 있다. 그만큼 일반적인 웹 어플리케이션과의 차이가 있는데 웹 어플리케이션은 실시간 처리가 기본이고 요청에 대한 응답을 제공해야 하니 아무래도 속도가 상대적이며 QA시 편한 부분이 있다. 그에 반해 배치 어플리케이션은 웹 어플리케이션에서 말하는 요청이라는 개념보다 후속처리에 가깝고, 속도 또한 절대적이며 QA가 복잡하다는게 특징이다. 따라서 테스트코드는 웹 어플리케이션 보다 배치 어플리케이션이 더 필요하다고 볼 수 있다. 배치 어플리케이션이 필요한 상황은 크게 두가지로 나눠 볼 수가 있다고 한다. 일정 주기로 실행 되어야 할 때 실시간 처리가 어려운 대량의 데이터를 처리 할때 평소 첫번째 상황만 생각하고 배치 어플리케이션을 작성하곤 했었는데 두번재 상황에 대해 생각에 생각을 더 해보니 스프링 배치를 간단하게만 (Tasklet) 사용하고 있는건 아닌가 하는 반성을 해보곤 했다. (Reader, Processor, Writer 등 다양한 레이어가 있는데도…) 특히 스프링 배치에서는 기본적으로 모든 데이터를 메모리에 쌓지 않는 조회방식라고 한다. (DB기준) Paging 혹은 Cursor로 pageSize만큼만 읽어오고 chunkSize만큼만 commit 하는 형태. 이러한 각 레이어별 size를 잘 조정하기만 해도 적은 노력으로 큰 성능을 얻을 수 있는 부분이 프레임워크를 사용하는 이유 아닐까 라고 생각해본다. 또한 @JobScope 나 @StepScope는 Late Binding 즉 배치 어플리케이션이 실행되는 시점이 아니라 Job 이 실행될때 생성이 되기 때문에 이를 활용하여 동적으로 reader / processor / wirter 레이어를 만들 수 있다고 한다. 활용편 스프링 배치를 이용한 배치 어플리케이션이 있고 이를 스케쥴링 등 관리를 해주는 도구들에 이야기를 해주셨다. Cron 리눅스를 어느정도 사용해봤다면 알만한 리눅스 기본 스케쥴링 프로그램인 Cron. 필자도 Cron 으로 주기적으로 실행하도록 설정해보기도 하였지만 배치 어플리케이션의 특성상 로그 및 실행/종료 등 제한사항이 많은 건 사실인것 같다. Spring MVC + API Call 주변에서 사용하고 있다고 하던 방식. 이 방식의 장점은 항상 떠있기 때문에 어플리케이션 구동시간이 별도로 필요 없다는 장점이 있지만 전반적인 관리가 어려운 단점이 있는것 같다. 물론 울며 겨자먹기 식으로 단점을 극복할 방법은 여러가지가 있겠지만 모든건 항상 Trade off Spring Batch Admin (Deprecated) 예전 팀분이 알려주셔서 잠깐 봤던 부분이긴 한데 어느사이에 Deprecated 되었다고 한다. Quertz + Admin http://www.quartz-scheduler.org/ 아주 오래전에 써본 기억이 있지만 배보다 배꼽이 더 큰 상황같았던 힘들었던 기억들만 남아있는 구현방법인것 같다.

모니터링은 서비스 로직 개발 만큼 한번씩 고민해보고 경험해 봤을 중요한 영역이라 할 수 있다. 그중 웹서버에서 제공해주는 엑세스 로그는 운영하고 있는 웹서비스에 대해 여러가지 측면에서 분석할 수 있는 가장 강력한 아이템 중에 하나라고 생각한다. 이를 통해 사용자들이 어떤 url을 많이 호출하고, 어떤 user-agent형태를 사용하는지 알게 되면 그에 따라 서비스 전략을 변경할수도 있고 악의적으로 공격적인 요청에 대해 웹서버단에서 차단을 할 수 있기 때문이다. 이렇게 inbound 트래픽(외부에서 들어오는 요청)에 대해서는 엑세스 로그를 잘 분석하면 기존의 웹 어플리케이션과는 전혀 무관하게 모니터링이 가능하지만 반대로 outbund 트래픽(외부로 나가는 요청)에 대해서는 어떤식으로 모니터링을 할 수 있을까? 월급통장의 inbound 트래픽보다 outbound 트래픽이 너무 많은 요즘…이미지 출처 : https://www.app24moa.com/feedDetail/2/2002" 월급통장의 inbound 트래픽보다 outbound 트래픽이 너무 많은 요즘… 이미지 출처 : https://www.app24moa.com/feedDetail/2/2002 예컨데, 날씨 서비스를 하기 위해 외부에서 서울날씨라는 페이지를 조회했을 경우 기상청 API에서 넘겨받은 데이터를 가공하여 보여준다고 가정해보자. 이때 기상청에서 제공해주는 특정 API중에 어느 하나가 늦게 응답이 온다거나, 특정시간대에 에러응답을 받을경우 과연 이를 어떤식으로 모니터링 할수 있을까? 어플리케이션 코드에 모니터링을 위한 코드를 추가할 것인가? 혹 하나의 서버에서 A모듈은 java로, B모듈은 python으로 개발되었을 경우 각각 모듈마다 모니터링을 위한 코드를 추가하는 식으로 하다보면 비지니스 로직을 방해하거나 오히려 추가한 코드 또한 관리해야 하는 배보다 배꼽이 더 커져버릴 상황도 생길수 있다. 어플리케이션의 비지니스 로직과는 무관하게 서버 자체에서 외부로 나가는 네트워크 트래픽에 대해 모니터링을 할 수 있는 가벼우면서도 심플한 모듈을 찾고 싶었다. 어플리케이션의 개발언어가 무엇이든 상관없이 별도의 에이전트 형식으로 띄워두기만 하면 네트워크 트래픽을 수집 및 분석, 나아가서는 모니터링까지 할수있는… 그래서 찾다보니 역시나 이러한 고민을 누군가는 하고 있었고 오픈소스까지 되어있는 Elastic Stack 의 Beat중 Packetbeat라는 데이터 수집모듈을 알게 되었다. 역시 내가 하고있는 고민은 이미 누군가 했던 고민들… 이러한 고민에 대해 해결하는 방법을 보다 빨리 찾는게 경쟁력이 될텐데… 이번 포스팅에서는 Packetbeat 에 대해 간단히 알아보고 이를 활용하여 outbound 트래픽에 대해 모니터링을 해보며 어떤식으로 활용할 수 있는지에 대해 알아보고자 한다. Packetbeat ? ElasticStack 중에 데이터 수집기 플랫폼인 Beats중 네트워크 트래픽 데이터에 대해 수집을 할 수 있는 데이터 수집기를 제공하고 있다. pcap라이브러리를 이용하여 서버의 네트워크 레벨에서 데이터를 수집 및 분석한 후 외부로(Elasticsearch, Logstash, Kafka 등) 전송해주는 경량 네트워크 패킷 분석기라고 공식 홈페이지에 소개되고 있다. 몇번 사용해보면서 느낀 장점들은 다음과 같다. 설치 및 실행이 너무 간단하다. 설정값 튜닝을 통해 간단하지만, 그러한 간단함에 비해서 너무 강력한 수집이 가능하다. 앞서 이야기 했던 어플리케이션 코드와는 전혀 무관하게 작동한다. 무엇을 해볼것인가?! (a.k.a. 목표) 필자가 운영하는 Daily-DevBlog 라는 서비스가 있다. (갑분 서비스 홍보) 여러 사람들의 rss를 조회하고 파싱해서 메일을 보내주는 서비스 인데, packetbeat 사용 예시를 들기위해 조금 변형하여 모든 rss를 접근하고 가장 최신글의 제목을 출력하는 아주 간단한 python 스크립트로 outbound 트래픽을 발생시켜 보고자 한다. 그리고 packetbeat 를 이용하여 외부로 호출되는 트래픽을 수집하고 Elasticsearch 로 인덱싱 하여 최종적으로는 어느 rss의 속도가 가장 느린지 실행되는 python코드와는 전혀 관련없이 모니터링 해보고자 한다. python 코드는 다음과 같다. 참고로 필자는 awesome-devblog의 운영자분께 해당 데이터 사용에 대해 허락을 받은 상태이다. import requests, yaml, feedparser blog_info_list_yml_url = 'https://raw.githubusercontent.com/sarojaba/awesome-devblog/master/db.yml' blog_info_list_yml = requests.get(url=blog_info_list_yml_url).text blog_info_yaml_parse_list = yaml.load(blog_info_list_yml) for blog_info in blog_info_yaml_parse_list : if 'rss' not in blog_info.keys() or not blog_info['rss']: continue rss_url = blog_info['rss'] try : parse_feed = feedparser.parse(rss_url) except : continue parse_feed_data = parse_feed.entries[0] print(blog_info['name'], '|', parse_feed_data['title'], '|', parse_feed_data['link']) 위 코드를 실행하면 아래처럼 아주 간단하게 블로그 주인의 이름과 최신글 제목, 링크가 출력이 된다.

웹서버 하나만 사용하거나 WAS 하나만을 사용하며 웹서비스를 운영하는 경우는 극히 드물다. 웹서버의 장점과 WAS의 장점 그 두마리의 토끼를 다 잡기 위해 보통 앞단에 웹서버를 두고 그 뒤에 WAS를 두며 서비스를 운영하곤 한다. 헌데 운영하는 서비스가 인기가 많아져(?) 사용량이 많아지다면 그만큼 응답이 느려 (TPS 등) 서버를 늘려야 하는 상황이 생긴다고 가정해보자.(물론 서버를 늘리는 것보다 캐시를 적용하거나 로직을 바꿔보는 노력이 선행되야 하겠지만…) 당연히 서버부터 구매하며 “Scale Out"을 하려고 할것이다. 만약 원래 운영하던 서버가 너무 좋아서 CPU나 메모리 사용률이 거의 바닥이여도 서버를 구매해야 할까? 서버를 구매하게되면 결국 두개 이상의 서버가 운영될텐데 그 서버들을 앞에서 묶어주며 트래픽을 분산시켜주는 무언가가 필요하다. 그러한 기술을 바로 로드밸런싱 이라고 한다. 통상 L4 스위치를 활용하여 요청을 여러 서버들로 분산시키며 산술적으로는 서버 대수만큼 성능이 좋아지는 효과를 볼 수 있다. 하지만 앞서 말했듯 서버의 자원 사용률이 바닥일 정도로 거의 사용을 안할경우 서버를 구매하는건 너무나 비효율적이다. 이번 포스팅에서는 서버를 늘리지 않으면서 웹서버 중 아파치를 활용하여 여러 WAS를 운영하는 방법에 대해 알아보고자 한다. 서버 늘려야 하는 상황에서 사용해 볼 수 있는 나만의 좋은 무기(?)가 생긴게 아닐까 생각이 든다. 아파치는 EOL이 되었기 때문에 2.4버전으로 설치하고, WAS는 편의상 톰켓 최신버전으로 설치해서 동일한 서버에 아파치 한대와 톰켓 3대를 연동하는것을 목적으로 한다. 로드밸런싱이 어떤식으로 이루어 지고 하위에 연결된 톰켓을 컨트롤 하는 방법 또한 알아볼 예정이다. 서버 환경 및 설치하게 될 각 버전은 다음과 같다. 서버 : CentOS 7.4 64Bit apache : httpd-2.4.39 tomcat : apache-tomcat-8.5.43 tomcat-connectors(mod_jk) : 1.2.46 Apache 와 Tomcat 설치 필자의 포스팅에서 종종 나오는 부분이기도 하고, 구글링 해보면 바로 설치 방법을 쉽게 찾을 수 있겠지만 그렇다고 언급을 안하고 넘어가기엔 너무 불친절하니… 치트키처럼(?) 빠르게 정리해보자. Apache $ wget http://apache.tt.co.kr//httpd/httpd-2.4.39.tar.gz $ tar -zxvf httpd-2.4.39.tar.gz $ ./configure --prefix=/home/~~~/apache $ make && make install $ cd /home/~~~/apache/bin $ sudo chown root:계정명 httpd $ sudo chmod +s httpd $ vi /home/~~~/apache/conf/httpd.conf User 계정명 Grop 계정명 $ /home/~~~/apache/bin/apachectl start ← 실행 이렇게 설치를 한뒤 실행을 시키고 서버의 ip를 접속해보면 아래와 같은 화면을 볼 수 있다. Tomcat $ wget http://mirror.apache-kr.org/tomcat/tomcat-8/v8.5.43/bin/apache-tomcat-8.5.43.tar.gz $ tar -zxvf apache-tomcat-8.5.43.tar.gz $ /home/apache-tomcat-8.5.43/bin/start.sh ← 실행 톰켓의 기본 http 포트인 8080으로 접속을 해보면 귀여운 고양이가 있는 톰켓 기본화면을 볼 수 있다. 아파치와 톰켓 연동하기 아파치와 톰켓의 연동은 mod_jk 와 mod_proxy 등 다양한 모듈로 연동을 할 수 있는데 이번 포스팅에서는 mod_jk 를 활용하는 방법에 대해 알아보고자 한다. 우선 mod_jk 를 설치하자. 간단히 mod_jk 는 컴파일, 설정 등 복잡하지만 톰켓 전용 바이너리 프로토콜인 AJP를 사용하기 때문에 높은 성능을 기대할수가 있다. mod_proxy 는 반면 기본으로 아파치에 탑재되어있는 모듈이기 때문에 별도의 모듈 설치가 필요 없고 설정도 간단하다는 장점이 있다. 각 연동방식의 장단점이 있기 때문에 본인이 운영하는 서버 상황에 맞추어 적용 할 필요가 있다. mod_jk 설치 $ wget http://apache.tt.co.kr/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz $ tar -zxvf tomcat-connectors-1.2.46-src.tar.gz $ cd tomcat-connectors-1.2.46-src/native $ ./configure --with-apxs=/home/~~~/apache/bin/apxs $ make && make install $ /home/~~~/apache/modules 하위에 mod_jk.so가 생김 mod_jk 를 활용하면 AJP라는 통신으로 아파치와 톰켓이 연동되는데 톰켓의 기본 AJP 포트는 8009번임을 알고 다음처럼 설정을 해주자. apache/conf/workers.properties worker.list=tomcat1 worker.tomcat1.port=8009 worker.tomcat1.host=localhost worker.tomcat1.type=ajp13 worker.tomcat1.lbfactor=1 apache/conf/httpd.conf LoadModule jk_module modules/mod_jk.so <IfModule jk_module> JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /* tomcat1 </IfModule> 이렇게 하고서 아파치와 톰켓을 재시작 후에 서버의 ip로 접속해보면 (별도의 port 없이) 톰켓 설정페이지로 랜딩이 되는것을 확인할 수 있다.

개발을 하다보면 실제로 직접 구현을 해본적은 없지만 여기저기서 들어본 지식과 그 동안의 짬밥(?)으로 추측해볼수 있는 부분들이 있다. 물론 모든일에 정답은 없겠지만 요즘 느끼는건 책에서 공부만 해본것과 다른 블로그들에서 눈으로만 보고 넘어가는것들 그리고 직접 손가락을 움직여가며 왜 여기서는 이 방법을 사용하지 고민하면서 구현을 해본다는건 정말 엄청나게 큰 차이가 있는것 같다. 웹 어플리케이션을 개발하다보면 한번 쯤 만나게 되는 파일 업로드 기능. 필자도 몇번 구현은 해봤지만 그냥 단순히 구현만 해본 상태였다가 최근에 그냥 파일 업로드가 아닌 대용량 파일 업로드에서의 문제가 발생하여 여기저기 삽질을 하게 되었고 정리도 해볼겸 스프링에서의 대용량 파일 업로드시 한번쯤 고려해봐야 할 부분에 대해 정리를 해보려고 한다. 물론 구글에서 검색을 해보면 아마 필자가 쓴것 보다 더 자세하고 좋은 글들이 있겠지만 필자는 보다 대용량에 집중에서 작성해 보고자 한다. 명심하자. “아무리 흐린 잉크라도 좋은 기억력보다 낫다” 라는 말이 있듯이 스프링을 활용한 파일 업로드 구현 우선 완전 초기상태에서 시작하기 위해 스프링 부트 프로젝트를 만들고 간단하게 파일 업로드를 할 수 있는 form 페이지와 업로드 버튼을 눌렀을때 작동하게 되는 컨트롤러를 만들어 보자. import java.io.File; import java.io.IOException; import java.io.InputStream; import org.apache.commons.io.FileUtils; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.multipart.MultipartFile; import lombok.extern.slf4j.Slf4j; @Slf4j @Controller public class FileUploadController { // 너무 간단 ... @RequestMapping("/form") public String form() { return "form"; } @RequestMapping(value = "/upload", method = RequestMethod.POST) public String upload(@RequestParam("file") MultipartFile multipartFile) { log.info("### upload"); File targetFile = new File("/home1/irteam/" + multipartFile.getOriginalFilename()); try { InputStream fileStream = multipartFile.getInputStream(); FileUtils.copyInputStreamToFile(fileStream, targetFile); } catch (IOException e) { FileUtils.deleteQuietly(targetFile); e.printStackTrace(); } return "redirect:/form"; } } upload 요청이 들어오면 file이라는 이름의 파라미터로 MultipartFile을 받고 파일의 이름을 확인 후 스트림을 읽어 특정 경로에 파일로 저장하는 로직이다. 그다음 /form을 접속하게 되면 나오는 폼 화면을 만들자. 이것도 아주 심플하게! <h1>파일 업로드</h1> <form action="/upload" method="post" enctype="multipart/form-data"> <input type="file" value="파일 선택" name="file"/> <input type="submit" value="업로드"/> </form> multipart/form-data 라는 Content-Type 을 명시해주고 파일을 선택하면 /upload로 POST요청을 하도록 설정한다. 이렇게 되면 너무 간단하게 + 이상없이 파일이 업로드가 잘 되니 이게 이야기 할 꺼리인가(?) 싶을정도로 심플하다. 그런데 파일 크기가 크다면? 설마 파일 업로드 하는 용량이 크겠어?… 왠지 파일의 용량이 크면 문제있을것 같은데… 출처 : https://m.blog.naver.com/naibbo0407/30170815180" 설마 파일 업로드 하는 용량이 크겠어?… 왠지 파일의 용량이 크면 문제있을것 같은데… 출처 : https://m.blog.naver.com/naibbo0407/30170815180 개발을 하다보면 항상 생각해야 할 부분중에 하나가 바로 확장성인것 같다. 이 부분에서 역시 문제가 되었던 것. 평소보다 용량이 큰 파일이 업로드가 되면서 (평소 3~400MB 였다가 3~4GB정도의 파일이 업로드가 되는 매직) 업로드가 안되는 상황이 발생하였다. 당연히 문제가 발생하면 누군가 말했듯 로그부터 살펴보았는데 Apache - (AJP) - Tomcat 으로 구성된 환경에서 tomcat 로그에 ### upload라는 로그가 없고 아파치 로그엔 502 에러가 발생한 것이었다. 왜 톰켓 로그도 안남고 그전에 에러가 발생하였을까? 이때부터 (근거없는 추측을 하며…) 고난과 역경의 삽질을 하기 시작하게 된다. 톰켓 버전이 문제일까? 로그가 안찍혔다면 다른 필터나 인터셉터에서 무언가를 먹고(?)있는건 아닐까? 잠깐, 근데 원래 대용량 업로드가 되긴 해? 파일 업로드/다운로드 하는 사이트 보면 별도 프로그램으로 하던데… 꼬불꼬불 미로속을 헤메는것만 같았던 삽질의 문제는 결국 메모리에 있었다. 파일을 업로드 하게 되면 해당 내용을 우선 메모리에 담게 되고 다 담은 후 메모리에 있는 내용을 was에 전달한 뒤 HttpServletRequest 로 넘어오게 된다.(Apache > Tomcat) 그런데 파일을 업로드 하면서 메모리에 파일이 써지다가 메모리 부족으로 OOM이 발생하게 되버린 것이었다. 또한 스프링 파일 최대크기를 별도로 지정하지 않고 있었기 때문에 메모리가 충분했다 하더라도 에러가 발생했을 상황이었다.

누구나 어렸을 땐 빨리 어른이 되고 싶어 하는 것 같다. 시간이 빨리 지나가길 바라고, 빨리 어른이 되고 싶다는 간절함이 있지만 이상하게도 그땐 시간이 천천히 가는 것처럼 느껴졌다. 반면, 시간이 천천히 갔으면 하는 때가 있다. 딱 지금. 남들은 워어어어얼화아아수우우모옥금퇼 이라고 부르며 시간이 느리게 간다고 빨리 주말이 왔으면 좋겠다고 하지만 요즘의 필자는 정 반대다. 방금 출근한 것 같은데 어느샌가 퇴근인사를 주고받고 있다. 무언가에 홀린 것 같다. 벌써 올해도 절반이 지나가고 뜨거운 여름과 함께 후반전이 시작되었다. 그래서 빨리 지나갔나…출처 : https://m.blog.naver.com/kong6482/220584667861" 그래서 빨리 지나갔나… 출처 : https://m.blog.naver.com/kong6482/220584667861 이제까지는 12월 말 즈음에 한 해를 바라보고 리뷰를 했었는데 글또라는 글쓰기 모임에 가입을 하게 되어 상반기 리뷰를 해보려 한다. 글또 모임의 첫 숙제가 상반기 리뷰 포스팅이다. 사실 리뷰를 상반기에 하던 연 말에 한 해 기준으로 하던 정해진 건 없지만 나를 다시 바라보고 다잡는 시간이 많을수록 보다 더 앞으로 가는데 힘이 될 거라는 데에는 이견이 없다. 회사 속에서의 나 회사에서는 회사일이 최우선!출처 : https://m.blog.naver.com/hwee__/221191852972" 회사에서는 회사일이 최우선! 출처 : https://m.blog.naver.com/hwee__/221191852972 최근에 팀장님과 면담 중에 나온 이야기다. 신기하게도 군 시절 장기를 꿈꾸던 필자를 어서 전역하라고 권유하시던 대대장님께 매일같이 들었던 이야기와 비슷하다. “이제는 단순 개발만 하고 기능구현만 하는 것이 아니라 그 이상을 해야 할 시기가 다가온다.” “사람들 관리가 될 수도 있고 어느 한 분야에 전문가가 되어야 할 수도 있고, 선택은 본인의 몫” 사실 기능 구현이야 누구나 다 할 수 있다. 단지 경험에 따른 구현의 속도나 안정성의 차이가 아닐까 생각해본다. 그렇다면 그 이상은 어떻게 해야 할까? 정답은 없겠지만 필자는 그 이상을 해보려 우선 팀에 도움이 되기 위해 여러 가지 자동화 툴 들을 만든 것 같다. 보다 기능 개발에 집중하고 단순 반복적인 업무는 시스템이 할 수 있도록. 그렇게 툴들을 만들어 가며 생각하지 못한 부분들을 배우게 되고 나중에 그걸 또 사용하게 되는, 미래의 나를 위해 강제로 배우고 있는듯한 느낌이랄까. 아, 물론 회사 본연의 업무가 최우선이지만 말이다. 어쨌든 시킨 일은 우선 차질 없이 잘 하고 시키지도 않은 일을 찾아서 하려고 노력했던 것 같다. 팀을 위해서, 곧 나를 위해서. 적어도 회사에서 있는 시간 속에서는 다른 곳에 한눈 안 팔고 회사 업무에 전념하려고 노력했던 것 같다. 외부 활동 부족한 시간을 쪼개면서 밋업이나 세미나에 참여하곤 했었다. 그리고 마냥 듣고만 오진 않았고 “행사에 참여하면 무조건 질문 하나는 하자"라는 나와의 약속을 지키며 정리한 내용을 블로그에 포스팅하기도 하였다. 올해 첫 발표!" 올해 첫 발표! 디자이너와 개발자가 함께하는 투게더톤을 진행하기도 했었다. 투게더톤은 약 한 달 동안 진행되는 해커톤으로 하루 또는 무박 2일 동안 하는 기존 해커톤과 다르다. 이 기간 동안 팀 내에서 자유롭게 일정을 조정할 수 있다. 우리 팀은 약 7주에 걸쳐 “동네 마트 할인 정보를 알려주는 앱” 을 만들게 되었다. 필자는 API 전반에 대해 담당을 하였고 작은 부분이었지만 웹사이트도 간단하게 만들어 보았다. 아무것도 없는 백지상태에서 시작하려니 막막했지만 후기에서도 적었듯이 다시 해보라고 하면 머릿속에 전체 아키텍처가 그림으로 그려질 만큼 자신감이 생겼다. 특히 정말 좋은 팀원들과 함께 협업할 수 있어서 너무 좋았다. 내공 연마 한 달에 2개 이상 블로그 글을 작성하는 목표가 있었다. 그런데 지난달에 이사를 하다 보니 (핑계…) 목표를 달성 할 수가 없었다. 하지만 나름 퀄리티가 있는 글을 쓰려고 노력했고 PV도 작년보다 조금씩 오르고 있는 것 같아 내심 기분이 좋다. 그리고 작년 말부터 시작한 필자의 첫 토이프로젝트 인 기술블로그 구독서비스 에 이런저런 기능을 추가하였다. 설마 1000명이 넘게 구독 하겠어?

스프링 기반의 웹 어플리케이션을 만들다 보면 요청을 처리하는데 맨 처음에 위치하고 있는 Controller(이하 컨트롤러)라는 레이어를 만들게 된다. 그럴때면 사용자가 어떤 요청(Request)을 하였는지에 대해 확인이 필요할 수 있다. 물론 확인을 안해도 무방하지만 가급적 로깅은 시스템 로직에 영향을 주지 않는 범위에서 최대한 다양하게 미리 해두는게 나중에 유지보수시 편할 수 있다. (예전 조직장님께서 말씀하신게 아직도 머릿속에 꽉 자리잡고 있다…) 아~주 일반적으로, 컨트롤러에서는 다음과 같이 메소드 단위로 파라미터를 직접 로깅하게 된다. @Slf4j @RestController public class SampleController { @GetMapping("/test1") public String test1(@RequestParam String id) { log.info("id : {}", id); return "length : " + id.length(); } } 이렇게 되면 사용자가 GET /test1 이라는 요청을 보낼때 어떤 파라미터로 호출하였는지에 대해 로깅이 남게 되는데 항상 log.info("id : {}", id); 과 같이 수동으로 로깅을 남겨야 하는 불편함이 생긴다. 물론 꼼꼼하게 메소드마다 로깅을 적어주면 전혀 문제될게 없지만 이러한 컨트롤러 ~ 메소드가 한두개가 아닌 수십 또는 수백개일 경우엔 그때마다 로깅을 적어줘야 하는 불편함이 있을 수 있다. 또한 자칫 깜박하고 로깅을 빼먹고 배포를 하게 된 경우 모니터링시 로깅을 하지 않아서 다시 로깅하고 배포를 하는, 별것도 아닌데(?) “정말 불편한” 상황이 있을 수 있다. 이번 포스팅에서는 사용자의 요청을 모니터링 하기 위해 컨트롤러마다 코드를 작성해가며 로깅을 하는것이 아니라 HttpServletRequestWrapper 라는 것과 Filter, AOP를 이용하여 Request의 정보를 한곳에서 우아하게 로깅하는 방법에 대해 알아보고자 한다. 요구사항 와 개발하자아!출처 : https://gfycat.com/ko/brightevilaoudad" 와 개발하자아! 출처 : https://gfycat.com/ko/brightevilaoudad 투우사가 흔드는 빨간 천을 보며 돌진하는 황소처럼 (쓰고보니 너무 TMI 같다….) 당장 코딩을 시작하며 개발을 할 수도 있지만 정작 원하는 기능이 무엇인지 천천히 정리하고 넘어갈 필요가 있는 것 같다. (어쩔땐 오히려 후자가 더 빠른 개발을 하게 되는것 같다.) GET, POST 등 다양한 http method 로 구현된 모든 컨트롤러의 파라미터와 기타 Request 정보가 로깅이 되야 한다. 컨트롤러, 메소드가 늘어날때마다 별도의 코드 추가 없이 한곳에서 공통적으로 로깅이 되야 한다. URL 중 특정 패턴으로 들어오는 요청은 다른 방식으로 로깅을 하거나, 로깅에서 제외할 수 있어야 한다. 앞서 말했듯 다른 비지니스 로직에 영향을 주지 않아야 한다. 구현하기 - Request 의 파라미터 정리 Request 의 모든 로깅을 한곳에서 처리하기 위해서 filter(필터)를 활용하였다. 필터는 Dispatcher servlet의 앞단에 위치하고 있기 때문에 모든 정보를 확인할 수 있는데 용이하다. 물론 인터셉터를 활용해서도 방법이 있겠지만 본 포스팅 에서는 필터를 활용해서 구현하는것을 목적으로 한다. (사실 인터셉터로 몇번 시도해보다가 실패해서…유유 ) Spring MVC Request Life Cycle출처 : https://justforchangesake.wordpress.com/2014/05/07/spring-mvc-request-life-cycle/" Spring MVC Request Life Cycle 출처 : https://justforchangesake.wordpress.com/2014/05/07/spring-mvc-request-life-cycle/ Filter를 만들기 전에 Filter에서 사용할 주요 핵심(?) 클래스가 필요한데 HttpServletRequest 를 Wrapping 해서 사용하기 위해 HttpServletRequestWrapper를 상속받는 클래스를 만들자. Request 에 담겨있는 param 과 body로 요청이 들어올 경우 body에 있는 내용을 param 에 담는 로직이다. 주요 설명은 코드 안에서 주석으로 설명하겠다. public class ReadableRequestWrapper extends HttpServletRequestWrapper { // 상속 private final Charset encoding; private byte[] rawData; private Map<String, String[]> params = new HashMap<>(); public ReadableRequestWrapper(HttpServletRequest request) { super(request); this.params.putAll(request.getParameterMap()); // 원래의 파라미터를 저장 String charEncoding = request.getCharacterEncoding(); // 인코딩 설정 this.encoding = StringUtils.isBlank(charEncoding) ? StandardCharsets.UTF_8 : Charset.forName(charEncoding); try { InputStream is = request.getInputStream(); this.rawData = IOUtils.toByteArray(is); // InputStream 을 별도로 저장한 다음 getReader() 에서 새 스트림으로 생성 // body 파싱 String collect = this.getReader().lines().collect(Collectors.joining(System.lineSeparator())); if (StringUtils.isEmpty(collect)) { // body 가 없을경우 로깅 제외 return; } if (request.getContentType() != null && request.