Tech on

공모주 알리미 개발 후기 - 3부

Sun, 04 Apr 2021 18:54:00 +0900

　공모주 알리미라는 토이 프로젝트 개발기의 마지막 포스팅이다. 토이 프로젝트를 왜 시작하게 되었고 어떻게 설계하게 되었으며 데이터는 어떤 식으로 수집하고 그 데이터를 어떤 방법으로 사용자들에게 알림을 보내기까지 알아보았다. 이제는 이러한 일련의 ‘파이프라인’을 자동화해야 할 시간이다. 사람이 직접 수동으로 로컬 컴퓨터에서 위 파이프라인을 실행하는 것이 아니라 별도의 서버에 해당 애플리케이션이 등록되어 있고 이를 어떤 무언가에 의해 트리거링을 해주는 방식으로 말이다.

서버 선정

　1부에서 이야기했던 것처럼 heroku라는 PaaS(Platform as a service)를 사용하면 될 것 같았다. 무료 플랜으로도 설계했던 서비스 내용을 모두 소화 가능했기 때문이다. 앞서 만든 Spring Boot Application 을 heroku에 배포를 해보자.

　heroku에서 새로운 ‘App’을 생성한다. 아래에서 보여주고 있는 화면대로 App name을 지정하고 만들기만 하면 끝. 그러면 배포 방법이 여러 가지가 나오는데 heroku에서 제공하는 CLI를 사용하는 방법, 그리고 Github 과 연동하거나, 컨테이너 레지스트리를 활용하는 방법 총 3가지가 있다. 여기서 필자는 Github을 활용해서 연동하는 방법을 소개해 보고자 한다.

heroku 에서 app을 생성하자.

　로컬에서 만든 애플리케이션을 Github에 push 하면 Github Repository 가 생기고 작업 파일들이 정상적으로 업로드된 것을 확인할 수 있다. 그다음 heroku에서 만들었던 App 페이지에서 Deploy 탭을 클릭하면 아래와 같이 3가지 방법으로 Deploy를 할 수 있다고 나오고, 이 중에 “Connect to Github"을 선택하면 Github 과 연동할 수 있는 버튼이 생기고 이를 누르면 자동으로 본인의 Github 내 Repository를 등록할 수 있도록 화면이 바뀐다.

heroku 와 github 연동

　그다음 위에서 Github에 push 했던 Repository 이름을 적고 검색하면 조회가 되고 ‘Connect’를 누르면 자동으로 연결이 된 것을 확인할 수 있다. 연동된 Repository 브랜치에 코드가 푸시 되면 자동으로 heroku에 배포가 되도록 자동화 설정도 가능하고 그 아래에 보면 브랜치를 선택해서 배포를 수동으로 할 수 있기도 하다. 수동으로 푸시를 눌러보면 이런저런 빌드 로그가 나오고 최종적으로 배포가 되어 {Appname}.herokuapp.com 을 접속해보면 서버에 배포가 되어있는 것을 확인할 수 있다.

sample Github Code : taetaetae@heroku#HelloWorldController.java#L11
sample heroku app : https://taetaetae-test.herokuapp.com/

수동으로 배포를 해보자.

　heroku에서는 이렇게 몇 번의 클릭만으로 간단하게 애플리케이션을 배포할 수 있는 기능을 제공하고 있고 서버 내 로그도 아래 화면처럼 보여주고 있기 때문에 쉽고 간단하게 서버를 구성하고 싶은 사용자들에게 매력적으로 보이는 것 같다. 단, 무료 플랜의 제한사항들을 자세히 살펴보고 사용할 것을 추천한다.

서버 로그도 볼 수 있다!

호출 테스트, 문제의 시작

　앞서 만들었던 텔레그램 채널에는 아무도 가입을 하지 않았기에 배포한 heroku web endpoint를 호출하면 텔레그램 봇을 통해 알림이 오는 걸 테스트하고 싶었다. 그런데 아무리 호출을 해도 서버는 타임아웃이라는 에러 응답을 뱉기 일쑤였고, 로직이 문제인지 한참을 리팩토링하며 원인을 파악하는데 꽤 오랜 시간을 삽질하였다. 왜 타임아웃이 발생할까? heroku는 web에서 바로 실행할 수 있는 console 페이지를 제공하고 있었다. 그래서 ‘크롤링을 하기 위한 페이지’와 ‘구글’을 비교하기 위해 단순하게 curl 해서 가져오는 테스트를 해보니 아래처럼 확연히 결과가 달랐다. 결국은 heroku 와 크롤링 하는 서버 간의 네트워크 타임아웃이 문제였던 것.

오류가 나고 원인을 찾는 과정이 가장 어려운 것 같다. 어플리케이션의 문제가 아닌 네트워크 자체의 문제

그래서 어떻게 해결 했나?

　heroku에서 타임아웃이 발생하는 문제를 해결하려 여러 구글링을 통해 찾아봤지만 방법을 찾을 수 없어서 결국 heroku를 사용하는 것을 포기하고 다른 방법을 찾아봐야만 했다. 앞서 이야기했지만 토이 프로젝트를 무료로 운영하고 싶었기 때문에 이런저런 방법을 찾다 보니 AWS 와 비슷하게 Google에서도 GCP라는 서비스를 알게 되었다. 이곳에서도 1년 동안은 무료이지만 이후 AWS처럼 과금이 드는 문제가 아쉬워서 좀 더 찾아보니 아주 작은 서버에 특정 조건을 맞춘다면 평생 무료로 사용이 가능하다는 걸 알게 되었고 이를 사용하기로 마음먹는다. (참고 사이트 : https://nhj12311.tistory.com/317)

공모주 알리미 개발 후기 - 2부

Sun, 28 Mar 2021 11:41:33 +0900

　혹시 이 포스트를 처음 읽는 독자라면 지난 포스팅을 읽고 오는 것을 추천한다. 정리하자면, 지난 포스트에서는 토이 프로젝트를 시작하게 된 계기와, 어떤 식으로 만들지에 대한 설계. 그리고 데이터를 수집하는 과정에 대해 이야기했었다. 지난 포스팅에서 수집한 데이터를 이제 사용자들에게 알려주는 부분에 대해 정리하고자 한다.

데이터 정의

　java 라이브러리 중에 jsoup라는 것을 사용하여 웹사이트를 크롤링 하였고, 필요한 데이터를 파싱을 하였다. 아래는 ‘공모주’라는 자바 모델을 정의해 보았다. 이렇게 자바 ‘모델’로 정의를 하는 이유는 필요한 데이터가 무엇인지 다시 한번 정리를 하기 위함이기도 하고 map 같은 형태의 임시 변수(?)보다 더 직관적이기에 이후 코드를 작성하는데 가이드 역할의 효과도 얻을 수 있을 것 같았기 때문이다.

public class PublicOffering {

 private String name; // 종목명
 private LocalDate startDate; // 일정 시작일
 private LocalDate endDate; // 일정 마감일
 private LocalDate listingDate; // 상장일
 private String publicOfferingPrice; // 확정 공모가
 private String expectedOfferingPrice; // 희망 공모가
 private List<String> Underwriter; // 주간사
 private String detailUrl; // 상세URL
 private String competitionRate; // 청약경쟁률
}

　초기에는 위에서 정의한 모델처럼 공모주의 기본 정보만을 서비스해야겠다 생각했고, 관련 뉴스라든지 기타 추가적인 정보나 다른 분들의 요구 사항(?)들이 추가될 경우 점진적으로 설계를 하고서 확장시켜 나가는 방향으로 계획했다. 우선은 기능들이 부족하더라고 돌아가는 서비스를 만들고 싶었기에.

애자일 방법론!
출처 : https://m.blog.naver.com/keycosmos3/221267522930

텔레그램 봇/채널 생성

　텔레그램 봇을 만드는 과정은 가볍게 검색을 해보면 너무나 쉽게 찾을 수 있지만, 보다 하나의 글 안에 모든 내용을 담고 싶어 텔레그램 봇을 만들고 → 텔레그램 채널을 만든 다음 → 텔레그램 봇을 이용해서 텔레그램 채널에 메시지를 보내는 걸 이야기해 보고자 한다.

아, 여기서 왜 꼭 ‘텔레그램’을 선택했는가에 대한 이유는 개인적으로 다른 메신저 (카카오톡, 라인 등)보다도 api를 활용하여 메시지를 보내는 과정이 단순하면서도 빠르고 쉽게 느껴졌기 때문이다. 혹시 텔레그램 이 아닌 다른 메신저로 보내달라는 요청이 있을 경우 그때 가서 고민해 보려 한다.

텔레그램 봇 생성

　먼저 텔레그램 메신저에서 ‘BotFather’라는 사용자를 찾고 ‘/start’를 누르면 아래와 같이 사용할 수 있는 명령어가 나온다.

　그다음 우리는 봇을 만들 것이기 때문에 ‘/newbot’을 누르고 봇의 이름을 작성하고 그 봇의 사용자 이름을 지정한다. ‘_bot’으로 끝나야 한다고 하기에 이름 뒤에 붙여서 만들면 그걸로 끝. 다음으로 친절하게 HTTP API를 사용할 수 있는 토큰이 발급되는데 이 토큰으로 봇을 컨트롤 가능하기 때문에 잘 간직하고(?) 있어야 한다.

친절한 봇 아버지

　이후 해당 토큰을 이용해서 봇의 상태를 확인해보자. 아래의 url에 토큰 경로만 변경하여 입력하면 json 응답을 받을 수 있다.

https://api.telegram.org/bot{token}/getUpdates
e.g. https://api.telegram.org/bot17...42:AAH...cQU/getUpdates

텔레그램 채널 생성

　1:N으로 채널에 가입한 사람들에게 메시지를 일방적으로 보내야 하기 때문에 사용할 채널을 만들어 보자. 텔레그램 UI만 봐도 간단하게 생성하기 쉽게 되어있다. 더불어 이 채널에 메시지를 보내야 하기 때문에 위에서 만들었던 봇을 추가하고 관리자로 승격 시키자.

채널 생성 > 봇을 관리자로

텔레그램 봇으로 텔레그램 채널에 메시지 보내기

　이 부분에서 약간 헤맸는데 결국 위에서 얻은 토큰과 채널의 특정 id를 알아야 메시지를 보낼 수 있다. 앞서 만들었던 채널에 아무 메시지나 작성을 하고 위에서 호출했던 ‘getUpdates’ api를 다시 호출해보면 아래처럼 채널의 id를 구할 수 있게 된다.

공모주 알리미 개발 후기 - 1부

Sun, 21 Mar 2021 19:13:49 +0900

　작년부터 시작된 ‘동학 개미 운동’에 언제부터인가 필자도 주린이로써 동참을 하게 되었다. 최근에는 ‘공모주 청약’이라는 걸 알게 되었는데 따라 해보고 정신 차려보니 치킨 한 마리 정도의 수익을 얻는 기적이 일어났다. 공모주란 정해진 일자에 청약을 하고 배정을 받으면 해당 주식이 상장을 하기 전에 미리 살 수 있다는 ‘기회’로 이해했다. (주린이라 이해의 범위가 여기까지다…) 공모주 배정이 로또처럼 엄청난 큰 수익률을 가져다주는 건 아니지만 앞서 이야기 한 것처럼 언제 있을지 모르는 공모주 청약을 꼬박꼬박 챙겨서 하게 된다면 맛있는 치킨을 먹을 수 있겠다는 기대감이 부풀었다. (치킨은 역시 교촌 허니콤보…)

주린이는 계속 자야 할까 싶다.
출처 : https://b-s-d.tistory.com/8

　치킨이 머릿속에 맴도는 시간도 잠시. 필자의 머리를 스치는 하나의 생각. 그러면 공모주 청약은 언제 하는 거지? 청약하니까 준비하라고 누가 알려주면 좋을 텐데… 그러면서 이런저런 검색을 해보니 안드로이드 앱은 이미 있었고, IOS 앱은 없었다. 음? 그럼 이걸 내가 만들어보면 어떨까?

　결론부터 말하자면, 텔레그램을 활용하여 자동화 공모주 알림봇을 만들게 되었다. 혹시 공모주에 관심이 있다면 필자가 만든 텔레그램 채널을 가입하는 것도 좋을 것 같다.

　이번 글에서는 필자의 새로운 토이 프로젝트인 ‘공모주 알리미’를 만들게 된 배경과 설계, 그리고 개발부터 릴리즈까지에 대해 이야기를 해보고자 한다. 크게 아래의 목차로 이야기하게 될 것 같다.

　자칫 너무 간단한데~, 이런 걸 굳이 왜 만들어?라는 시각이 있을 수 있겠지만 토이 프로젝트를 해야지 하고 마음을 먹었지만 막상 시작을 못하고 있는 어느 누군가에게는 도움이 될 내용인 것 같아서 꽤 자세히 정리를 하려 한다. 물론 이러한 정리는 필자 자신을 위해서가 더 크긴 하다.

프로젝트 설계

　과거에 토이 프로젝트로 진행했던 기술블로그 구독 서비스의 경험을 되새기면서 처음부터 황소처럼 달려드는 것보단 충분에 충족을 더해 충만해질 때까지 고민을 오랫동안 해보기로 했다. (그래봤자 하루 정도…?^^) 　 우선 데이터를 어딘가에서 가져오고 가져온 데이터를 DB에 저장할 것인지 아니면 저장하지 않고 휘발성으로 조회후 버리는(?) 형태로 할 것인지를 고민해야 했다. 공모주라는 데이터의 특성상 한번 정해진 메타 데이터가 상황에 따라 변경이 될 수도 있다고 했기에(일정이 변경되거나 공모가가 변경되거나 등) DB에 저장을 하게 되면 이를 동기화(Sync) 하는 비용이 추가로 생길 것 같아서 알림을 보내기 직전에만 조회하고 버리는 형태를 생각했다.

　그렇게 데이터를 조회했다면 이를 입맛에 맞게 가공하고서 사용자에게 알림을 줘야 한다. 알림을 발생시키는 방법은 매우 다양한데 뭔가 적은 비용으로 구성하고 싶었다. 즉, 알림을 받는 사용자가 10명, 100명, 1000명 이 되어도 (그렇게 될지는 모르겠지만;;) 내가 만든 서비스에서 알림 수신인이 늘어나는 경우를 고려하지 않아도 되었으면 했다. 그에 생각한 게 메신저 API. 그중에서도 텔레그램 API가 뭔가 이런 형식으로 딱일 것 같았기 때문이다. 결국 데이터를 메시지 형태에 맞춰 한 번만 발송하게 되면 1:N 형식(Broadcast)으로 텔레그램 채널을 구독하고 있는 사용자들에게 전송이 될 테니 안성맞춤이었다.

　그럼 언제 어떤 정보를 알려주는 게 좋을까? 청약이 보통 오전에 시작하기 때문에 대략 매일 오전 9시에 관련 정보들을 보내주면 될 것 같았다. 3일 전에 청약을 시작하게 되니 미리 준비하라는 알림. 그리고 청약 날짜가 도래해서 잊지 말고 청약을 신청하라는 알림. 마지막으로 공모주가 상장을 하게 되는 알림. 이 세 가지 알림만 잘 챙긴다면 필자 같은 주린이들도 충분히 공모주 청약으로 치킨을 먹을 수 있을 거라 생각했다.

　마지막으로 이 모든 내용을 개발한 어플리케이션을 어느 곳에 배포해야 하는지를 결정해야 했다. 항상 머릿속에는 있었지만 한 번도 안 해본 클라우드 Paas 인 heroku가 딱일 거라 생각했다. (실제로 해보지 않았던 지금까지는 그랬다…) 다들 토이 프로젝트 서버로 잘 활용한다는 소리를 들었고 가장 큰 장점은 ‘무료’라는 점에서 heroku를 선택하지 않을 수 없었다.

Elastic Stack으로 코로나19 대시보드 만들기 - 2부 : 대시보드

Wed, 17 Feb 2021 16:53:49 +0900

　지난 포스팅에서는 데이터를 수급하며 전처리 과정을 거쳤고, Filebeat와 Logstash를 거쳐 Elasticsearch에 인덱싱 하는 것까지 알아보았다. 앞선 포스팅에서 이야기했지만 단순하게 데이터를 시각화 도구를 이용해서 대시보드를 만드는 게 아니라 데이터가 추가되면 만들어둔 대시보드에 자동으로 반영되는 흐름을 만들고 싶었다. 마침 파이프라인을 이틀 전에 만들었기 때문에 그동안의 빠진 데이터를 추가해야 하는 상황이다. 이 경우 Filebeat-Logstash-Elasticsearch 가 실행 중이라면 앞서 작성했던 파이썬 스크립트만 한번 실행해 주면 이틀 치 데이터가 파이프라인을 거쳐 Elasticsearch로 인덱싱이 된다. 즉, 별도로 데이터를 가져와서 재 가공하고 추가하는 다소 까다로운 작업이 미리 만들어둔 파이프라인 덕분에 한 번의 스크립트 실행으로 손쉽게 처리가 됨을 알 수 있다.

　이제는 쌓여있는 데이터를 가지고 시각화를 해볼 차례이다. ElasticStack에서는 Kibana라는 강력한 시각화 도구를 제공하는데 이번 포스팅에서는 Kibana를 이용해서 대시보드를 만드는 방법에 대해 알아보려 한다.

Visualize

　Elasticsearch에 인덱싱 되어있는 데이터들은 기본으로 제공되는 REST API를 통해서 조회할 수 있고 JSON 형태로 결과가 나오기 때문에 이를 가지고 다양하게 시각화를 할 수도 있다. 하지만 Kibana에서는 데이터를 조회하고 UI로 표현하는 일련의 모든 행위를 클릭 몇 번으로 할 수 있게 해주기 때문에 전문가가 아니더라도 조금만 만져보면 누구나 만들 수 있다.

New Visualizaion!!

　버전업이 되면서 비쥬얼라이즈를 만드는 첫 화면 또한 변화가 생겼다. 기존에는 어떤 유형의 비쥬얼라이즈를 선택할 것인지에 대해 선택하는 화면부터 나왔는데 만드는 걸 보다 편리하게 도와주는 Lens, TSVB 같은 기능들이 먼저 반겨준다. 이 기능을 통해서 만드는 방법도 괜찮지만 보다 명시적으로 만들고 싶으니 하단에 Aggregation based을 선택해서 원하는 비쥬얼라이즈의 타입을 선택해 보자. 이후 생성되어 있는 인덱스를 선택하면 본격적으로 비쥬얼라이즈를 그릴 수 있는 화면이 나오는데 대시보드 화면 기준으로 만들어야 할 항목별로 살펴보자.

전체 수

　확진자, 사망자, 격리 해제의 총합을 표현하려 한다. 이렇게 ‘숫자’를 표현하려 하는 경우 Metric을 활용하곤 한다. 우측에서 Aggregation 방법을 ‘sum’으로 설정하고 필드는 유형별로 각각 선택해 주자. 아래 ‘Add’버튼을 눌러 확진, 사망, 격리 해제 수를 모두 표시한 다음 저장을 눌러준다. Label을 지정하지 않으면 어떤 형태로 Aggregation을 했는지를 Label 영역에 보여주는데 그게 보기 싫다면 원하는 텍스트로 지정해 주는 것도 방법이다.

최근 수

　확진자, 사망자, 격리 해제의 ‘최근 데이터’를 보여주는 게 목적이다. 이 경우 Aggregation을 Top Hit으로 선택하면 필드를 선택할 수 있게 되는데 하루의 데이터가 총 18 row이기 때문에 (서울, 부산, …, 제주, 검역) 18 row 을 전부 더한 값이 하루 기준의 합계가 된다. 여기서 정렬을 날짜 기준 내림차순으로 해줘야 가장 최근 데이터의 합계가 되는 점도 신경 써야 한다.

각 타입별 합계

　지역별로 타입별 수를 보기 위해 Pie 타입으로 선택하여 진행한다. 타입별(예로 들어 확진이면 confirmed)로 합계를 구하기 위해 Aggregation을 ‘sum’으로 설정하면 빈 원이 나오지만 각 지역별로 차트를 잘라서 봐야 하기에 하단의 Buckets의 Add를 누르고 regieon의 필드를 Terms Aggregation 한다. 18 row의 데이터가 전부 보여야 하기에 정렬 개수를 늘리고 option 탭에서 보는 취향에 알맞게 설정값들을 바꿔준다.

타입별 추이

　확진, 사망, 격리 해제 중에 사망을 제외하고 나머지 둘은 데이터의 크기가 크고 변화량이 비슷하기 때문에 x축은 시간으로 설정해두고 사망은 막대로, 나머지 둘은 라인으로 한 화면에서 표현하면 이 3가지 데이터를 한눈에 보기 좋을 것 같았다. Vertical bar 을 선택하고 x축(Buckets > X-axis)은 데이터 타입인 convert_date로 설정한다. 다음으로 사망은 매일 몇 명 사망했는지 뚜렷하게 보기 위해 그냥 sum으로, 나머지 둘은 누적 합계가 더 의미 있어 보일 것 같아 Cumulative Sum으로 Aggregation을 한다. 한 화면에서 3가지의 데이터를 보여주기엔 다소 y 축의 크기가 맞지 않으므로 확진, 격리 해제를 별도의 y 축(Y-axes)으로 ‘Metrics & axes’탭에서 설정해 준다. 다음으로 각 항목의 범례를 위로 표시하여 보다 보기 편하게 배치한다.

Elastic Stack으로 코로나19 대시보드 만들기 - 1부 : 파이프라인 구성

Mon, 15 Feb 2021 17:50:12 +0900

　얼마 전에 필자의 블로그를 보고 어느 교육 기관에서 ElasticStack에 대한 강의 요청이 들어왔다. 사실 관련 기술에 대해 지식이 아주 깊고 해박한 게 아니라서 약간의 반감부터 들었지만 ElasticStack을 전혀 모르는 사람들 기준으로 어떻게 돌아가는지에 대해서만 간단하게 소개하는 정도로 하면 된다고 하여 조심스럽지만 떨리는 마음으로 열심히 준비를 하기 시작했다. 그런데, 이런저런 이유로 갑자기 강의를 할 수 없게 되었고 그간 준비했던 내용들이 너무 아쉽지만 아무 소용이 없게 되어버렸다. 그냥 중단하기엔 아쉬운 마음이 너무 커서 준비했던 내용 중에 ‘데이터를 가지고 대시보드를 만드는 부분’은 누군가에겐 도움이 될까 싶어 블로그에 정리를 해보려 한다.

강의를 준비한 올해 1월 중순엔 Elasticsearch 버전이 7.10.2이었는데 블로그를 쓰고 있는 지금은 벌써 7.11으로 버전 업 되었다. 내가 아는 오픈소스 중에 버전업이 가장 빠른데 그렇다고 기능이 확 바뀌거나 습득하기 어렵게 바뀌진 않았다. 그만큼 사용자가 무엇을 원하는지 명확히 알고 작은 단위로 조금씩 바뀌어 가는 모습이 꽤 인상적이다.

　작년 초부터 코로나19 바이러스가 전 세계적으로 퍼지기 시작했고 아직까지도 진행 중이다. 나도 전염되는 건 아닐까 하는 두려움에 어디에서 얼마나 발생했는지를 확인하기 어렵던 시절 우리나라의 뛰어난 개발자들은 누가 시키지도 않았는데 정말 감사하게도 그 현황을 한눈에 볼 수 있도록 여러 유형으로 코로나19 바이러스 대시보드를 만들기 시작한다. 그 덕분에 좀 더 현황을 보기에 편해졌고 더욱 조심하게 되는 계기가 되었다고 생각한다. 이제는 포털사이트나 각종 매체를 통해 손쉽게 코로나19 바이러스의 현황을 볼 수 있지만 이러한 데이터를 가지고 검색엔진이지만 대시보드를 구축하는데 훌륭한 기능을 가지고 있는 ElasticStack을 활용해서 ‘나만의 대시보드’를 만드는 걸 정리해보고자 한다. 본 포스팅의 일회성으로 데이터를 가지고 대시보드를 만드는 것에서 끝나는 게 아니라 지속적으로 데이터가 업데이트된다는 가정하에 전반적인 “파이프라인"을 구축한 뒤 대시보드를 만들어 두고 데이터만 갱신하면 자동으로 대시보드 또한 업데이트되는 것을 목적으로 한다.

전체 흐름

글을 모두 작성하고 보니 양이 생각보다 길어져서 데이터를 조회하고 필터링하여 Elasticsearch에 인덱싱 하는 대시보드를 만들기 위한 일종의 “데이터 파이프라인"을 구성하는 부분과 만들어진 데이터 기반으로 Kibana의 다양한 기능을 활용하여 대시보드를 만드는 2개의 포스팅으로 나누어 정리해보겠다.

　최종적으로 만들게 될 대시보드의 모습은 다음과 같다.

최종 목표!

대시보드 구성 준비

　예전에는 Elasticsearch, Logstash, Kibana 3가지를 가지고 ELK라 불리다 Beat라는 경량 수집기 제품이 등장하며 이 모든 걸 ElasticStack라 부르기 시작했다. (공식 홈페이지 참고) 먼저 어떤 목표와 어떤 순서로 대시보드를 구성할 것인지에 대해 정리해봐야겠다.

데이터

　데이터는 공공데이터 포털에서 가져오려다 조회를 해보니 누락되는 날짜도 있었고 원하는 데이터의 품질이 생각보다 좋지 않아서 다른 곳을 찾아봐야 했다. 그러다 간결하게 정리한 데이터가 깃헙에 공개가 되어 있어서 그것을 사용하려 한다. 해당 데이터는 https://coronaboard.kr/ 에서도 사용되는 데이터라고 한다.

데이터 전처리(preprocessing)

　원하는 데이터는 위 깃헙에서 제공하는 데이터 중에 지역별 발생 현황. 해당 데이터를 살펴보면 요일별로 데이터가 ‘누적’되어 저장되어 있다. 즉, 서울지역 기준으로 2020년 2월 17일에 14명이 발생했고 2020년 2월 18일에 한 명도 발생하지 않았는데 14명으로 ‘누적’되어 저장되어 있다. 사실 이대로 해도 큰 문제는 없지만 어디까지나 별도의 가공 없이 최대한 원본 데이터(raw) 가 있어야 데이터 분석 시 다양하게 활용이 가능하기에 데이터를 분석하기 전에 전처리 과정이 필요했다. 정리하면, 집계 수가 누적되지 않고 날짜 기준으로 집계된 수만 있는 데이터를 원했다.

　필자는 주로 java를 가지고 개발을 하지만 가끔 간단한 스크립트성 개발은 python을 활용하는 편이기에 다소 이쁜 코드는 아니지만 데이터를 조작하려 아래와 같은 코드를 작성하였다.

Swagger와 Spring Restdocs의 우아한 조합 (by OpenAPI Spec)

Tue, 22 Dec 2020 10:41:40 +0900

　MSA 환경에서의 API 문서화는 어떤 식으로 구성하는 걸까? 예컨대, 모듈이 10개 있다고 하면 각 모듈마다 API 문서가 만들어질 테고 API 문서를 클라이언트에 제공하기 위해서 각각의 (10개의) URL를 전달해야 할 텐데 이게 과연 효율적일까? 물론 기능별로 URL이 분리된다는 장점이 있고 굳이 모아보자면 각 API 문서를 다시 한번 크롤링 하여 검색할 수 있도록 제공하는 것도 하나의 방법이 될 수 있다. 하지만 이러한 방법들은 요구 사항을 위한 별도의 작업을 하게 되니 일을 위한 일이 되는 것 같아 뭔가 아쉬웠다. 좋은 방법이 없을까?

고민의 시작

　한창 궁금증이 머릿속에서 지워지지 않았을때 Spring 한국 스프링 사용자 모임 페이스북 그룹에 문의도 해가며 방법을 찾아가고 있었다.

닉네임이나 프로필 사진은 그들의 개인 정보를 위해 임의로 지정하였다.

　필자와 함께 개발자의 인생을 시작한 멋진 친구들에게 정확히 올해 6월 초에 고민을 털어놓으며 좋은 방법이 없을지에 대한 논의를 했던 적이 있다. 그런데 친구 중 한 명이 잊고 있었던 그 이슈에 대해서 다시 꺼내며 URL 하나를 던져준다. 참 고마운 친구들.

Shout out 34. asuraiv, black9p

언 반년이 지났으나 필자도 잊고 있었던 이슈를 그는 기억하고 있었다.

　올해 NHN FORWARD에서 진행했던 세션 중에서 MSA 환경에서 API 문서 관리하기: 생성부터 배포까지라는 제목의 내용이었고, 정확하게 필자가 고민했던 부분을 콕! 집어서 해결해 준 사례였다. 역시 세상엔 엄청난 고수들이 내가 고민했던 부분들을 이미(혹은 이후에라도) 고민하고 해결한 경우가 많다는 것을 느끼고 공유의 힘이 이렇게도 대단하구나 하며 놀라움을 금치 못하였다.

　이번 포스팅에서는 OpenAPI Spec 을 활용하여 Spring Restdocs로 만들어지는 문서를 Swagger UI에서 보는 흐름을 실제로 구현해 보고자 한다. 즉, Swagger 나 Spring Restdocs 뭐로 만들든 간에 OpenAPI Spec에 맞춰서만 만든다면 한곳에서 볼 수 있겠다는 희망이 보였다. 며칠 전 작성한 OpenAPI 와 Swagger-ui 포스팅을 본 독자들은 지금의 포스팅을 작성하기 위한 밑거름이었다는 사실을 눈치챘을 수도 있을 것 같다.

좋은 내용을 공유해 주신 (저의 고민을 완벽하게 해결해 주신) NHN FORWARD 발표자분께 이 포스팅을 빌어 감사의 인사를 보냅니다. :) 당장 팀 내에도 적용해봐야겠어요!!

Spring Restdocs에서 OpenAPI Spec 추출

　누가 또 친절하게 오픈소스로 만들어놨다. https://github.com/ePages-de/restdocs-api-spec 에서 관련 내용을 확인할 수가 있는데 해당 링크에서는 gradle 버전이고 https://github.com/BerkleyTechnologyServices/restdocs-spec 는 maven 버전이라고 한다. 마침 필자의 Github에 Maven 버전으로 SpringRestdocs를 세팅해둔 Repository 가 있어서 이를 활용해보고자 한다.

pom.xml 추가

　관련 dependency를 추가하자. jcenter라고 bintray.com 에서 운영되는 Maven Repository에 올려진 오픈소스이니 repository 도 추가해 주자.

<properties>
	<restdocs-api-spec.version>0.10.0</restdocs-api-spec.version>
	<restdocs-spec.version>0.19</restdocs-spec.version>
</properties>

<repositories>
	<repository>
		<id>jcenter</id>
		<url>https://jcenter.bintray.com</url>
	</repository>
</repositories>

<dependency>
	<groupId>com.epages</groupId>
	<artifactId>restdocs-api-spec</artifactId>
	<version>${restdocs-api-spec.version}</version>
	<scope>test</scope>
</dependency>

<dependency>
	<groupId>com.epages</groupId>
	<artifactId>restdocs-api-spec-mockmvc</artifactId>
	<version>${restdocs-api-spec.version}</version>
	<scope>test</scope>
</dependency>

위의 dependency에서 제공해 주는 모듈로 테스트의 SpringRestdocs를 만들었다면 OpenAPI Spec 을 만들어 주는 plugin 또한 추가해 주자

<pluginRepositories>
	<pluginRepository>
		<id>jcenter</id>
		<url>https://jcenter.bintray.com</url>
	</pluginRepository>
</pluginRepositories>

<plugin>
	<groupId>com.github.berkleytechnologyservices.restdocs-spec</groupId>
	<artifactId>restdocs-spec-maven-plugin</artifactId>
	<version>${restdocs-spec.version}</version>
	<executions>
		<execution>
			<goals>
				<goal>generate</goal>
			</goals>
			<configuration>
				<specification>OPENAPI_V3</specification>
				<format>JSON</format>
				<outputDirectory>${project.build.directory}/classes/static/docs</outputDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>

위 plugin 설정을 보면 format 을 JSON으로 한 것을 볼 수 있는데 YAML로도 만들 수 있다. 자세한 사용방법은 위에서 명시한 링크를 참고해보는 게 좋을 것 같다.

OpenAPI 와 Swagger-ui 적용하기

Sun, 20 Dec 2020 11:42:40 +0900

　API를 개발하고 사용방법에 대한 명세를 작성하는 방법은 여러 가지가 있다. 가장 심플하게 개발 코드와는 별도로 직접 수기로 작성하여 파일 혹은 문서 링크를 전달하는 방법이 있다. 하지만 개발 코드와 별도로 직접 작성을 한다는 점에서 오타/실수가 발생할 수 있고 최신화가 안되는 여러 가지 문제가 발생한다. 그에 등장한 API 문서화 자동화 툴의 양대 산맥인 SpringRestDocs 와 Swagger.

　과거 SpringRestDocs 에 대한 포스팅을 했기에 이번엔 Swagger에 대한 사용방법에 대해 정리해보고자 한다. 이 둘의 장단점은 너무 뚜렷하기에 API문서를 제공하는 상황에 따라 적절하게 선택하여 사용할 수 있었으면 좋겠다.

SpringBoot에 Swagger 적용

　기본 SpringBoot 가 셋팅되어 있다는 가정하에 Swagger 관련 dependency를 추가해주자. 아참, 이제부터의 프로젝트 셋팅은 Gradle로 하려한다. (물론 Maven으로 해도 무방하지만…)

dependencies {
 implementation "io.springfox:springfox-boot-starter:3.0.0"
}

　이후 JavaConfig 을 아래와 같이 설정하는데 아래 내용은 아주 기본 세팅이니 자세한 내용은 공식 도큐문서를 참고해 보면 좋을 것 같다. (물론 샘플 프로젝트를 만들며 필요할 것 같은 내용은 아래에서 설명하겠다.)

@EnableSwagger2
@Configuration
public class SwaggerConfig {

	@Bean
	public Docket api() {
		return new Docket(DocumentationType.SWAGGER_2)
			.select()
			.apis(RequestHandlerSelectors.any())
			.paths(PathSelectors.any())
			.build();
	}
}

　테스트할 컨트롤러를 아래처럼 심플하게 작성하고(사칙연산…) 실행을 시킨 후 /swagger-ui/에 접속을 해보면 swagger 관련 javaConfig 하나만 추가했는데 문서가 만들어진 것을 확인할 수 있다. (http method는 편의상 다양하게 작성했으니 왜 DELETE 인가라는 의문은 접어두자.)

@RestController
public class SampleController {

	@GetMapping(value = "/addition")
	public Integer addition(Integer num1, Integer num2) {
		return num1 + num2;
	}

	@PostMapping(value = "/subtraction")
	public Integer subtraction(Integer num1, Integer num2) {
		return num1 - num2;
	}

	@PutMapping(value = "/multiplication")
	public Integer multiplication(Integer num1, Integer num2) {
		return num1 * num2;
	}

	@DeleteMapping(value = "/division")
	public Integer division(Integer num1, Integer num2) {
		return num1 / num2;
	}
}

기본 셋팅만 했는데 이런 화면이 나타났다.

　위에서 했던 설정들 중 몇 가지만 좀 더 자세히 살펴보자.

설정	설명
Docket	Springfox 프레임 워크의 기본 인터페이스가 될 빌더로 구성을 위한 여러 가지 기본값과 편리한 방법을 제공하고 있다. 이후 `select()`로 ApiSelectorBuilder를 반환받아 사용할 수 있도록 해준다.
apis	어떤 위치에 있는 API들을 가져올 것인가에 대한 정의. `RequestHandlerSelectors.any()`이라고 했으니 SpringBoot에서 기본으로 제공하는 `basic-error-controller` 도 API 문서로 만들어진 것을 확인할 수 있다. 특정 패키지만 적용하기 위해서는 `RequestHandlerSelectors.basePackage("com.taetaetae.swagger.api")` 와 같은 형식으로 지정하면 해당 패키지 하위에 있는 Controller를 기준으로 문서를 만들어 준다.
paths	이름에서도 눈치를 챌 수 있듯이 특정 path만 필터링해서 문서를 만들어 준다.
useDefaultResponseMessages	기본 http 응답 코드를 사용해야 하는지를 나타내는 플래그

이외에도 security 나 공통으로 사용되는 파라미터 등 다양한 옵션을 설정할 수 있으니 가능하면 상황에 맞게 설정을 변경해 보는 것도 좋을 것 같다. 다른 설정들을 추가시켜서 좀 더 친절하게 만들어 보면 아래처럼 만들 수 있고 해당 코드는 Github에서 확인 가능하다.

API 문서화는 최대한 친절하게!!

OpenAPI

　Swagger 공식 홈페이지를 이리저리 둘러보면 OpenAPI라는 내용이 많이 나온다. 그렇다면 OpenAPI는 무엇일까? 문서에 나와있는 내용을 직역해보면 Swagger 사양으로 알려져 있으며 RESTful 웹 서비스를 설명, 생성, 소비 및 시각화하기 위한 기계 판독 가능 인터페이스 파일에 대한 사양이라고 한다. 즉, API 자체를 설명하는 인터페이스 스펙이라고 이해를 해볼 수 있다. 위에서 만들어졌던 Swagger를 보면 http://localhost:8080/v2/api-docs?group=Test API 라고 나와있는데 이를 클릭해보면 아래와 같이 json 형태로 보인다. 다시 보면 우리가 이제까지 Swagger으로 만든 API 문서를 설명하는 인터페이스 스펙으로 이해할 수 있다. (꽤 길어서 덧셈 API를 제외하고 지웠다.) 그렇다면 이 JSON 파일을 어떻게 활용할 수 있을까?

Jenkins Job을 병렬로 실행해서 속도를 개선해보자. (by. Pipeline)

Sun, 06 Dec 2020 20:19:47 +0900

　관리하는 URL이 200응답을 주고 있는지 모니터링을 한다고 가정해보자. 다양한 방법이 생각나겠지만 가장 처음으로 떠오른 건 단연 Jenkins. 간단하게 사용할 언어에 맞춰 Execute Script를 작성하고 스케줄링을 걸어 놓으면 큰 수고 없이 모니터링을 구성할 수 있게 된다. 아래는 python script로 작성해 보았다.

import requests
url="http://모니터링url"
status_code = requests.get(url).status_code
if status_code != 200:
	print(f'응답 실패 :{url}, status : {status_code}')
	exit(1)

　하지만 모니터링을 해야 하는 URL이 1개에서 여러 개로 늘어난다면 어떻게 될까? 단순하게 작성한 Script를 아래처럼 약간 수정하면 되긴 하지만 URL마다 응답속도가 다를 경우 순차적으로 실행하다 보니 실행 속도는 느릴 수밖에 없다.

import requests
urls = [
	"http://모니터링url-1",
	"http://모니터링url-2",
	"http://모니터링url-3"
]

for url in urls:
	status_code = requests.get(url).status_code
	if status_code != 200:
		print(f'응답 실패 :{url}, status : {status_code}')
		exit(1)

　이러한 경우, 빠른 속도를 보장하기 위해서는 병렬로 실행을 해야 한다는 건 누구나 다 알지만 그렇다고 Thread를 사용하기엔 벌써부터 덜컥 부담이 된다. 그렇다고 Job을 URL 개수만큼 늘리기에는 배보다 배꼽이 더 커버리고… 그러다 발견한 기능이 바로 Jenkins Pipeline!

　이번 포스팅에서는 Jenkins Job을 동시에 여러 번 사용해야 하는 경우를 Pipeline을 통해서 개선한 내용에 대하여 공유해보려 한다. Jenkins Pipeline에 대해 들어만 봤는데 이번에 실제로 사용해보니 생각보다 쉽게 개선할 수 있었고 옵션들을 상황에 맞게 조합을 잘 한다면 상당히 활용성이 높아 보이는 기능인 것 같다.

기존상황

　테스트를 위해 임의로 느린 응답을 생성하도록 URL을 구성하고 위에서 이야기했던 것처럼 Job 하나에 아주 심플하게 Python script를 작성하고 실행해보도록 하자. 임의로 느린 응답은 http://slowwly.robertomurray.co.uk/ 에서 제공하는 기능을 활용하였다.

import requests
urls = [
	"http://slowwly.robertomurray.co.uk/delay/0/url/https://www.naver.com/",
	"http://slowwly.robertomurray.co.uk/delay/100/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/200/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/500/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/1000/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/2000/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/5000/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/10000/url/https://www.naver.com/",
 "http://slowwly.robertomurray.co.uk/delay/20000/url/https://www.naver.com/"
]

for url in urls:
	status_code = requests.get(url).status_code
	if status_code != 200:
		print(f'응답 실패 :{url}, status : {status_code}')
		exit(1)
	print(f'응답성공 : {url}')

그래서 실행해보면 50초가 소요되었다. 자, 이제 개선을 해보자!

개선을 해보자

　전체적인 개선의 흐름은 하나의 Job에 모니터링하고자 하는 url을 파라미터로 받아서 처리할 수 있도록 설정하고, 이를 Jenkins Pipeline 을 통해 여러 URL을 동시에 모니터링하게 구성하는 것이다. 그러면 두 개의 Job(파라미터로 받아 모니터링하는 Job, Jenkins Pipeline Job) 만으로 보다 빠르고 효율적인 구성을 할 수 있을 것으로 상상을 하고.

Job을 범용적으로 (Jenkins paramters 활용)

　위에서 샘플로 작성하였던 Python script는 url 이 늘어날수록 Job 안에 script를 수정해야 한다. 그렇게 해도 무방하지만 이번 개선의 목표는 하나의 Job을 Pipeline 이 병렬로 컨트롤하도록 설정해야 했기 때문에 Jenkins Job에 파라미터를 받을 수 있도록 아래처럼 Jenkins Job 설정에 파라미터를 설정하고 Python script 또한 수정해 주자.

Job > 구성 > 이 빌드는 매개변수가 있습니다

import requests, os
url = os.environ['url']
status_code = requests.get(url).status_code

if status_code != 200:
 print(f'응답 실패 :{url}, status : {status_code}')
 exit(1)
 
print(f'응답성공 : {url}')

병렬 실행을 위한 Jenkins 설정

　Jenkins Job 을 생성하면 기본적으로 Job마다의 대기열(Queue)이 있어 Job이 실행 중이라면 시작된 시간 순서대로 기다렸다가 앞선 Job이 종료가 되면 이어서 실행되는 구조이다. 하지만 우리는 Job을 병렬로 실행해야 했기에 Job 설정 중 필요한 경우 concurrent 빌드 실행 옵션을 켜줘서 기다리지 않고 병렬로 실행될 수 있도록 해준다.

Job > 구성 > 필요한 경우 concurrent 빌드 실행

　또한 Jenkins Job 자체는 병렬로 실행되도록 설정되었다 해도 기본적으로 Jenkins 자체의 대기열은 한정되어 있기 때문에 적당히 늘려줘서 여러 개의 Job이 대기 열 없이 동시에 실행될 수 있도록 해준다.

Jenkins > Jenkins 관리 > 시스템 설정 > of executors

Jenkins Pipeline

　Job 을 Pipeline으로 만들고 Pipeline scirpt를 작성하는데 눈여겨봐야 할 옵션들을 짚고 넘어가고자 한다.

기술블로그 개편기 (by HUGO)

Sun, 29 Nov 2020 18:12:15 +0900

　웹서비스 개발자라면 나만의 블로그쯤은 있어야지 하며 기술 블로그를 시작한 지도 어느덧 4년이 되었다. 처음엔 그저 새로 알게 된 기술이나 삽질하며 경험한 것들 중에 핵심만을 적어놓는 수준이었다. (지금 다시 보면 뭔가 오글거리는 건 기분 탓이겠지…) 그렇게 계속 글을 써오면서 글쓰기라는 것에 관심을 갖게 되고 내 글이 누군가에게 도움이 될 거라는 기대에 조금이라도 글을 잘 써보고자 단순 기록 용이 아닌 하나의 ‘글’을 쓰려고 노력해 온 것 같다.

　일주일에 한 개는 써야지. 한 달에 한 개는 써야지. 하며 자꾸 나 자신과의 타협을 하다가 최근에는 회사에서 운영하는 서비스 개편 때문에 정신없이 바쁘다는 핑계로 ‘블로그’에 ‘ㅂ’자도 생각하지 못하게 된다. 무엇이 문제일까?라는 생각은 결국 내 기술 블로그도 회사 서비스처럼 ‘개편’을 해보자는 생각으로 도달하게 되었고 간단할 것만 같았던 기술 블로그 개편 작업은 꽤 오랫동안 + 다양한 삽질들로 작업을 하게 된다.

　이번 포스팅에서는 기술 블로그를 개편하며 겪었던 내용들에 대해 정리해보고자 한다. 기존에 기술 블로그를 운영하시는 분들이나 이번에 새롭게 시작하시는 분들께 도움이 될 거라 기대한다. 더불어 서비스 ‘출시’ 가 아닌 개편’이라는 과정 속에서 느끼게 되었던 인사이트도 간략하게 작성해볼까 한다.

기술블로그 플랫폼 선택

　처음 블로그를 쓰기 시작했을 때 포털서비스의 글쓰기 플랫폼을 사용하지 않은 이유는 단 하나다. ‘글쓰기’ 뿐만 아니라 개발자이기에 웹사이트(블로그)를 내 입맛에 맞게 커스터마이징 하기 위해서. 그 이유로 hexo 라는 프레임워크에 github의 호스팅을 사용하여 운영을 해왔다. 그렇게 블로그를 운영해오면서 느꼈던 불편했던 부분들과 개편을 하며 기대하는 부분들을 정리하면 아래와 같다.

테마(UI)가 이뻐야 하고 기능들이 많으면 좋겠다.
기술 블로그인 만큼 코드가 많이 삽입되니 코드 표현 또한 이뻐야 한다.
테마 또는 프레임워크의 커뮤니티가 활발해야 한다.
페이지 생성 또는 만들어진 웹페이지의 성능이 좋아야 한다.
글을 작성하고 배포하는 과정이 심플하고 깔끔해야 한다.

　위와 같은 이유를 기반으로 검색을 해보다 SSG(쓱 쇼핑몰 아님, Static site generators)를 깔끔하게 정리해 놓은 사이트를 발견한다. 정말 다양한 플랫폼들을 살펴보며 필자에게 맞는 게 어떤 건지 고민하다 결국 hugo 를 선택하게 된다. hugo를 선택한 이유는 go라는 언어를 사용한다는 것과 (간접적으로라도 다른 언어를 경험해보고 싶어서 + go 언어가 빠르다는 소리를 어디선가 들어서) 테마들이 너무 다양했기 때문이다.

아주 대놓고 빠르다고 하니… 쓰고 싶어진다.

　결국 hugo에 hugo-ranking-trend라는 사이트에서 상위에 랭크가 되어있고 기술 블로그 성격에 적합할 것 같은 LoveIt이라는 테마를 사용하기로 결정하였다. 자 그럼 시작해볼까?!

hugo 는 어떻게 쓰는거야?

　대부분의 오픈소스는 hello world 혹은 quick start 같이 처음 접하는 사람들을 위한 도큐먼트가 있기 마련. hugo도 마찬가지로 quick-start가 있었고 이를 천천히 따라 하면 생각보다 쉽게 초기 세팅을 할 수 있었… 을꺼라 기대했지만 약간 초기 설정 과정이 어려워서 남겨 두고자 한다.

참고로 필자는 윈도 10 환경에서 구성하였다. mac이라면 더 쉽게 설정할 수 있는 것 같은데 이 부분은 OS의 차이에서 생겨나는 어쩔 수 없는 약간의 장벽이라 생각한다. 이쁜 테마와 새로운 환경을 사용할 수 있다는 기대감으로 꾹 참아본다.

기본설정

　git이 설치되어 있다는 가정하에 우선 hugo는 go 언어기반으로 돌아가기에 우선 go를 설치해야 한다. 다운로드페이지에서 환경에 맞는 설치 파일을 다운로드하고 설치를 해준다. 다음으로 패키지 관리자인 chocolatey 또한 설치가 필요하다. 공식 홈페이지페이지에서 나와있는 순서대로 진행하면 설치 완료. 필자는 여기서 진행이 잘 안됐었는데, ‘관리자 권한’으로 PowerShell 을 실행시켜야지만 성공을 할 수 있었다.

　위 설정이 완료되었으면 드디어 hugo를 설치해 주고 초기화를 해준 뒤 샘플로 글 하나를 만들고 서버를 띄우면 끝.

빌드/테스트는 내가 해줄게. 너는 코딩에 집중해 (by GitHub Pull Request Builder)

Mon, 07 Sep 2020 10:09:56 +0000

　git 은 분산 버전 관리 시스템 중 가장 잘 알려져 있다고 해도 과언이 아닐 정도로 대부분의 시스템에서 사용되고 있는 것 같다. 이를 웹서비스에서 보다 편하게 사용할 수 있도록 한 시스템이 Github. Github 을 사용하는 이유 중에 가장 큰 이유를 하나만 이야기해보자면 바로 온라인상에서 코드 리뷰를 할 수 있는 pullRequest라는 기능 때문이 아닐까 조심스럽게 생각을 해본다.

　pullRequest는 work branch에서 작업한 내용을 base branch로 merge 전 꼭 코드 리뷰가 아니더라도 작업한 내용에 대해서 다양한 검사를 자동화할 수 있는 강력한 기능들이 많다. 이러한 자동화는 CI(지속적 통합) 관점에서 매우 중요한데 코드에 대해 체크해야 할 부분들(빌드, 테스트, 정적 분석 등)을 “알아서” 해준다면 작업자는 오롯이 비즈니스 로직 개발에 대해서만 신경 쓸 수 있으니 생산성 절약 측면에서 엄청난 효과를 볼 수 있다.

내가 하는일에만 집중할 수 있게!
출처 : https://www.clien.net/service/board/park/10453442

이번 포스팅에서는 그중에서도 아주 간단한 설정만으로 work branch의 빌드 상태를 검사해 볼 수 있는 Jenkins의 Github Pull Request Builder를 설치 및 활용해 보고자 한다.

사실 최근 팀에서 CI 서버를 이전해야 했었다. 머릿속에서는 어떻게 하면 되겠지 싶었지만 막상 해보려니 Jenkins 버전업도 되었고 뭐부터 해야 할지 허둥대는 필자가 부끄러웠다. 이참에 정리를 해보며 다시 한번 리마인드 하는 시간을 가져보고자 한다. (이래서 기억보다 기록이 중요하다.)

준비물

　전체적인 흐름은 아래 그림처럼 흘러가기 때문에 당연히 서버에 Jenkins 가 설치되어 있어야 한다. Jenkins 설치는 필자의 포스팅(Jenkins 설치 치트키)를 참고해 보는 것도 좋을 것 같다.

전체적인 흐름

　참고로 필자는 GitHub Enterprise 버전에서 사용했는데 일반 Github에서도 동일한 방법으로 사용 가능하다.

Github과 Jenkins의 연동을 위한 2가지 설정

　Github 과 Jenkins 가 통신이 되도록 설정해 줘야 한다. 그래야 Github의 코드를 받아서 Jenkins 가 빌드를 하고 그 빌드 결과를 다시 Github에 리포트가 가능해지기 때문이다. 먼저 첫 번째로 ssh 설정으로 Github의 코드를 가져오도록 ssh 설정을 해두자. ssh 설정하는 방법은 필자의 포스팅(Github과 Jenkins 연동하기)편을 확인해보면 될 것 같다.

　그다음으로 아래에서 이야기할 GitHub Pull Request Builder라는 Jenkins plugin 이 빌드가 끝난 뒤에 결과를 리포팅 해줄 수 있는 인증 토큰을 발급받아두자. Github > Settings > Developer settings > Personal access tokens 화면에서 키를 생성하고 만들어진 키를 저장해 둔다. (이 키는 보안에 유의해야 하고, 화면 경고(?)에서도 볼 수 있듯이 키는 생성 시 한 번밖에 볼 수 없기 때문에 미리 저장해 둬야 한다.)

인증토큰을 미리 받아두자.

Jenkins 설정

　Jenkins > 관리 > pluginManager에 들어가 GitHub Pull Request Builder를 검색 후 설치해 준다. 그러고 나서 Jenkins > 관리 > 환경설정에 들어가 보면 아래와 같이 GitHub Pull Request Builder 항목이 생긴 것을 확인할 수 있고 위에서 설정한 인증토큰을 아래처럼 등록 후 저장을 한다.

credentials 을 위에서 발급받은 인증토큰으로 등록해준다.

　Jenkins job을 하나 만들고 pullRequest 가 발생했을 때 자동으로 실행될 수 있도록 설정을 해준다. 먼저 General 탭에 Github project에 Github url 을 적어주고

　소스 코드 관리 탭에서 ssh 주소를 적고 위에서 미리 설정한 ssh 키로 credentials 값을 넣어준다. 전에도 이야기했지만 이 부분에서 오류가 발생하면 빨간색 글씨로 오류 내용이 나오고 아래 화면처럼 오류가 없다면 아무것도 안 나온다. Refspec 에 +refs/pull/*:refs/remotes/origin/pr/* 라고 적어주고 브랜치 설정은 파라미터로 받아와서 pullRequest를 발생시킨 브랜치를 빌드 할 수 있도록 ${sha1} 라고 적어주자.

스프링 부트에 필터를 '조심해서' 사용하는 두 가지 방법

Mon, 06 Apr 2020 23:59:36 +0000

웹 어플리케이션에서 필터를 사용하면 중복으로 처리되는 내용을 한곳에서 처리할 수 있다거나 서비스의 다양한 니즈를 충족시키기에 안성맞춤인 장치인것 같다. 필터란 무엇인가 에 대한 내용은 워낙에 다른 블로그나 공식 도큐먼트에서 자세하게 그리고 다양하게 설명하고 있기에 기본 개념에 대해서는 설명하지 않도록 하려 한다. 이번 포스팅에서는 스프링 부트를 사용하면서 어노테이션이라는 간편함에 취해(?) “돌격 앞으로, 닥공” 의 자세로 개발을 하려했던 필자를 보고 “반성"의 자세로 필터를 등록하는 방법에 대해 명확하게 정리를 하고자 한다. 마지막으로는 아주 간단하면서도 엄청나게 위험한 필터 설정 사례에 대해서도 짚고 넘어가보자. 그냥 넘어가면 아쉬우니, 한번이라도 ‘spring’ 이라는 framework 를 접해본 사람이라면 봤을법한 그림을 첨부하는것으로 필터란 무엇인가 에 대한 설명을 대신하는게 좋겠다.

출처 : https://justforchangesake.wordpress.com/2014/05/07/spring-mvc-request-life-cycle/

방법을 설명하기 전에 동일하게 사용될 필터와 컨트롤러 코드를 보면 다음과 같다.

필터

@Slf4j
public class MyFilter implements Filter {

	@Override
	public void init(FilterConfig filterConfig) throws ServletException {
		log.info("init MyFilter");
	}

	@Override
	public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)
		throws IOException, ServletException {
		log.info("doFilter MyFilter, uri : {}", ((HttpServletRequest)servletRequest).getRequestURI());
		filterChain.doFilter(servletRequest, servletResponse);
	}

	@Override
	public void destroy() {
		log.info("destroy MyFilter");
	}
}

테스트 할 컨트롤러

@Slf4j
@RestController
public class SampleController {

	@GetMapping("/test")
	public String test() {
		return "test";
	}

	@GetMapping("/filtered/test")
	public String filteredTest() {
		return "filtered";
	}
}

방법 1 : FilterRegistrationBean

아주 간단하게, 일반 url 하나와 필터에 적용할 url 두개를 만들고 설정하려 한다. FilterRegistrationBean 을 이용해서 위에서 만들었던 필터를 아래처럼 등록해보자.

@SpringBootApplication
public class Method1Application {

	public static void main(String[] args) {
		SpringApplication.run(Method1Application.class, args);
	}

	@Bean
	public FilterRegistrationBean setFilterRegistration() {
		FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new MyFilter());
		// filterRegistrationBean.setUrlPatterns(Collections.singletonList("/filtered/*")); // list 를 받는 메소드
		filterRegistrationBean.addUrlPatterns("/filtered/*"); // string 여러개를 가변인자로 받는 메소드
		return filterRegistrationBean;
	}
}

위 주석에도 적었지만 filterRegistrationBean 의 “setUrlPatterns” 와 “addUrlPatterns” 의 차이는 별거 없다. list 자체를 받을건지 아니면 가변인자로 계속 추가 할것인지. 이렇게 되면 “/filtered/“으로 “시작"하는 패턴의 url의 요청이 오게 되면 등록한 필터를 통과하게 된다.

실행 : 필터 생성

 /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/ ___)| |_)| | | | | || (_| | ) ) ) )
 ' |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot :: (v2.2.6.RELEASE)

2020-04-06 23:45:01.225 INFO 14672 --- [ main] c.t.s.method1.Method1Application : No active profile set, falling back to default profiles: default
2020-04-06 23:45:02.153 INFO 14672 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
2020-04-06 23:45:02.168 INFO 14672 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2020-04-06 23:45:02.168 INFO 14672 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.33]
2020-04-06 23:45:02.361 INFO 14672 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2020-04-06 23:45:02.362 DEBUG 14672 --- [ main] o.s.web.context.ContextLoader : Published root WebApplicationContext as ServletContext attribute with name [org.springframework.web.context.WebApplicationContext.ROOT]
2020-04-06 23:45:02.362 INFO 14672 --- [ main] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 1082 ms
2020-04-06 23:45:02.391 DEBUG 14672 --- [ main] o.s.b.w.s.ServletContextInitializerBeans : Mapping filters: filterRegistrationBean urls=[/filtered/*] order=2147483647, characterEncodingFilter urls=[/*] order=-2147483648, formContentFilter urls=[/*] order=-9900, requestContextFilter urls=[/*] order=-105
2020-04-06 23:45:02.391 DEBUG 14672 --- [ main] o.s.b.w.s.ServletContextInitializerBeans : Mapping servlets: dispatcherServlet urls=[/]
2020-04-06 23:45:02.409 DEBUG 14672 --- [ main] o.s.b.w.s.f.OrderedRequestContextFilter : Filter 'requestContextFilter' configured for use
2020-04-06 23:45:02.409 DEBUG 14672 --- [ main] s.b.w.s.f.OrderedCharacterEncodingFilter : Filter 'characterEncodingFilter' configured for use

// 필터가 생성 되었다!
2020-04-06 23:45:02.410 INFO 14672 --- [ main] c.t.springbootfilter.method1.MyFilter : init MyFilter

2020-04-06 23:45:02.410 DEBUG 14672 --- [ main] o.s.b.w.s.f.OrderedFormContentFilter : Filter 'formContentFilter' configured for use
2020-04-06 23:45:02.544 INFO 14672 --- [ main] o.s.s.concurrent.ThreadPoolTaskExecutor : Initializing ExecutorService 'applicationTaskExecutor'

일반 url

2020-04-06 23:45:27.526 DEBUG 14672 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : GET "/test", parameters={}
2020-04-06 23:45:27.528 DEBUG 14672 --- [nio-8080-exec-1] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.taetaetae.springbootfilter.method1.SampleController#test()
2020-04-06 23:45:27.548 DEBUG 14672 --- [nio-8080-exec-1] m.m.a.RequestResponseBodyMethodProcessor : Using 'text/html', given [text/html, application/xhtml+xml, image/webp, image/apng, application/xml;q=0.9, application/signed-exchange;v=b3;q=0.9, */*;q=0.8] and supported [text/plain, */*, text/plain, */*, application/json, application/*+json, application/json, application/*+json]
2020-04-06 23:45:27.548 DEBUG 14672 --- [nio-8080-exec-1] m.m.a.RequestResponseBodyMethodProcessor : Writing ["test"]
2020-04-06 23:45:27.555 DEBUG 14672 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Completed 200 OK

필터링 url

// 필터에 들어온것 확인!
2020-04-06 23:45:37.455 INFO 14672 --- [nio-8080-exec-2] c.t.springbootfilter.method1.MyFilter : doFilter MyFilter, uri : /filtered/test

2020-04-06 23:45:37.456 DEBUG 14672 --- [nio-8080-exec-2] o.s.web.servlet.DispatcherServlet : GET "/filtered/test", parameters={}
2020-04-06 23:45:37.456 DEBUG 14672 --- [nio-8080-exec-2] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.taetaetae.springbootfilter.method1.SampleController#filteredTest()
2020-04-06 23:45:37.457 DEBUG 14672 --- [nio-8080-exec-2] m.m.a.RequestResponseBodyMethodProcessor : Using 'text/html', given [text/html, application/xhtml+xml, image/webp, image/apng, application/xml;q=0.9, application/signed-exchange;v=b3;q=0.9, */*;q=0.8] and supported [text/plain, */*, text/plain, */*, application/json, application/*+json, application/json, application/*+json]
2020-04-06 23:45:37.457 DEBUG 14672 --- [nio-8080-exec-2] m.m.a.RequestResponseBodyMethodProcessor : Writing ["filtered"]
2020-04-06 23:45:37.459 DEBUG 14672 --- [nio-8080-exec-2] o.s.web.servlet.DispatcherServlet : Completed 200 OK

방법 2 : @WebFilter + @ServletComponentScan

@ServletComponentScan 어노테이션을 @Configuration 어노테이션이 설정되어 있는곳에 걸어준 다음 위에서 설정한 필터에 @WebFilter 어노테이션을 설정해주면 아주 간단하게 끝이 난다.

조금 더 괜찮은 Rest Template 2부 - Circuit-breaker

Sun, 29 Mar 2020 23:09:16 +0000

지난 포스팅에서는 Retryable 를 활용해서 간헐적인 네트워크 오류를 “재시도"를 함으로써 아주 간단하면서도 강력하게 해결할 수 있는 방법에 대해 알아보았다. 실제로 필자가 운영하는 서비스 에서도 Retryable 를 이용하기 전과 후를 비교해보면 간헐적인 네트워크 오류의 빈도수가 확실히 줄어든것을 확인할 수 있었다.

이렇게 “재시도"를 해서 요청했을때 성공 응답을 받을 경우엔 문제가 안되지만 네트워크 오류가 아닌 실제로 호출을 받는 해당 서버에서 문제가 발생했다면 어떨까? 예컨대, 해당 서버에서 DB를 조회하는 API를 호출한다고 가정했을때 DB 자체에서 어떠한 오류가 난다면. 이런 경우는 단순히 “재시도"로 해결할 수 없는 문제다.

물론 Retryable 의 Recover 어노테이션을 활용했기 때문에 클라이언트 즉, 사용자에게는 오류응답이 발생을 안했겠지만 호출 받는 서버 자체에서의 에러가 발생하는데 이런식의 재시도를 계속 시도한다면 호출 받는 서버 입장에서는 이 “재시도” request 또한 “부하” 로 받게 되고 결국 2차, 3차 장애가 이어질 수 밖에 없다.

기존 한덩어리로 관리되던 Monolithic Architecture 에서는 자체적으로 관리하기 때문에 이러한 에러 컨트롤 또한 자체적으로 관리를 할 수 있지만, 모듈이 모듈을 호출하게 되는 Microservice Architecture 로 바뀌다보니 이런 “연쇄 장애(?)” 같은 현상이 발생하게 되는 경우가 있다. 호출을 받는 서버의 상태가 이상하면 (에러응답이 지정한 임계치를 벗어나는 수준으로 맞춰서 발생한다면) 적절하게 호출을 하지 않고 (2차 장애를 내지 않도록 호출 자체를 하지 않고) 어느정도 기다리다 클라이언트에게는 에러응답이 아닌 미리 정해둔 응답을 내려주고, 에러가 복구되면 다시 호출하도록 하는 “무언가” 가 필요하지 않을까?

연쇄 장애. 제발 멈춰…
출처 : http://dpg.danawa.com/mobile/community/view?boardSeq=175&listSeq=4066389

지난 포스팅에 이어 이번 포스팅 에서는 그 “무언가”. 즉, Circuit-breaker 에 대해 알아보고 직접 구현 및 테스트 하면서 돌아가는 원리에 대해 이해 해보고자 한다. 막상 개념은 머릿속에 있지만 직접 구현해보지 않으면 내것이 아니기에, 직접 구현하고 설정값들을 바꿔가면서 언젠가 필요한 순간에 꺼내서 사용할 수 있는 나만의 “무기” 를 만들어 보고자 한다.

Circuit breaker ?

(한국 발음으로) 서킷브레이커를 검색해보면 주식시장 관련된 내용이 꽤 나온다. (앗, 잠깐 눈물좀…) 서킷 브레이커. 이 용어는 다양한 곳에서 사용되는데 “회로 차단기” 라고도 검색이 된다. 해당 내용을 발췌해보면 다음과 같다.

회로 차단기는 전기 회로에서 과부하가 걸리거나 단락으로 인한 피해를 막기 위해 자동으로 회로를 정지시키는 장치이다. 과부하 차단기와 누전 차단기로 나뉜다. 퓨즈와 다른 점은, 차단기는 어느 정도 시간이 지난 뒤, 원래의 기능이 동작하도록 복귀된다.

여기서 가장 중요한 문장은 “피해를 막기 위해 자동으로 회로를 정지시키는”, “어느정도 시간이 지난뒤 원래의 기능이 동작하도록 복귀된다” 이 부분이 가장 중요한 것 같다. 시스템 구성이 점점 Microservice Architecture 로 바뀌어 가는 시점에서 이러한 “서킷브레이커"는 자동으로 모듈간의 호출 에러를 감지하고 위에서 말한 “연쇄 장애"를 사전에 막을 수 있는 아주 중요한 기능이라 생각된다.

“circuit breaker spring” 이라는 키워드로 검색해보면 이러한 고민을 이미 Netflix 라는 회사에서 Hystrix 라는 이름으로 개발이 된것을 알 수 있다. 이 core 모듈을 Spring 에서 한번 더 감싸서 Spring Boot 에서 사용하기 좋게 spring-cloud-starter-netflix-hystrix 라는 이름으로 만들어 둔 것이 있는데 이것을 활용해 보기로 하자.

구현

늘 그랬듯이 SpringBoot 프로젝트를 만들고 테스트할 Controller 를 만들어 주자. 원래대로라면 호출을 하는 모듈과 호출을 받는 모듈, 2개의 모듈을 만들어서 테스트 해야 하지만 편의를 위해 하나의 모듈에서 두개의 Controller 을 만들고 테스트 해보는 것으로 하자.

@RestController
public class MainController {

	private final MainService mainService;

	@GetMapping("index")
	public String index(String key){
		return mainService.getResult(key);
	}

	public MainController(MainService mainService) {
		this.mainService = mainService;
	}
}

@Slf4j
@Service
public class MainService {

	private RestTemplate restTemplate;

	public String getResult(String key) {
		return restTemplate.getForObject("http://localhost:8080/target?key=" + key, String.class);
	}

	public MainService(RestTemplate restTemplate) {
		this.restTemplate = restTemplate;
	}
}


@Slf4j
@RestController
public class TargetContoller {

	@GetMapping("/target")
	public String target(String key) {
		log.info("input key : {}", key);
		if (!StringUtils.equals("taetaetae", key)) {
			throw new RuntimeException("Invalid key");
		}
		return "target";
	}
}

사실 설명할 부분도 없긴 하지만 그래도 적어보면, /index라는 주소와 key라는 파라미터로 요청을 하면 /target이라는 컨트롤러가 받아서 key 값에 따라 정상 응답을 줄지 아니면 에러를 응답하는 코드이다. 목표로 하는건, 파라미터를 일부러 잘못줘서 에러를 발생하는데 Hystrix를 적용해서 설정한 기준에 따라 응답은 미리 정해둔 응답을, TargetContoller에서는 잠시동안 요청을 받지 않다가 조금있다가 다시 호출하면 요청을 받는 시나리오로 작성해 보려 한다. 우선 필요한 dependency를 추가해준다.

조금 더 괜찮은 Rest Template 1부 - Retryable

Sun, 22 Mar 2020 15:30:35 +0000

웹 어플리케이션을 만들면서 꼭 한번 쯤 만나게 되는 “RestTemplate”. 접근 가능한 외부 HTTP URL(보통 API)을 호출하는 방법중에 하나로 springframework 에서 제공해주는 모듈이다. 특히 큰 한덩어리로 관리되던 Monolithic Architecture 에서 요청을 하고(client) 응답을 주는(server) 즉, Endpoint가 작은 단위로 분리되는 Microservice Architecture 로 바뀌면서 각 서비스간 호출방식이 HTTP 일 경우 자주 사용되곤 하는 것 같다. (webClient 등 다른 여러 호출 방법들이 있다.) 만약, 요청을 하는 클라이언트 입장에서 응답을 주는 서버의 상태가 불안정 하다고 가정했을때, 어떤식으로 처리해야 할까? 예컨대, 요청 10번에 한번은 어떠한 이슈로 응답이 지연되거나 서버에러가 발생한다고 하면 클라이언트를 사용하는 사용자 입장에서는 간헐적인 오류응답에 답답함을 호소할 수도 있다. 그럼 잠시 눈을 감고 생각해보자. 가볍게 생각하면 아래처럼 아주 간단하게 “예외처리"를 이용할 수도 있다.

try {
	// http call
} catch (Exception e){
	// 서버에러가 아닌 약속된 에러응답을 리턴
}

하지만 이것도 정답이 아닐수 있는게, “간헐적인 오류"로 인해 사용자는 오류화면을 봐야하기 때문에 클라이언트에 대한 신뢰를 저버릴 수밖에 없다. 그럼 어떻게 해야할까? 여러가지 해결방법이 있겠지만 간단하면서도 강력하다고 생각되는 방법이 바로 “재시도” 라고 생각한다. 클라이언트를 사용하는 사용자가 눈치 못챌만큼 빠르게 재시도를 한다면 에러가 나도 다시한번 호출해서 성공할 수 있는 가능성이 높기 때문이다. (그치만 근본적인 원인은 해결해야…)

실제로 조금있다 해보면 되는 경우가 많으니 안될때는 조금 (천천히) 시도해보자.
출처 : http://www.segye.com/newsView/20200302504384

이번 포스팅에서는 RestTemplate 를 이용할때 “재시도” 할 수 있는 방법에 대해 알아보고자 한다. 아주 간단할지 모르지만 노력에 비해 효과가 상당하다고 생각하기 때문에 정리해 두고 싶었다.

Spring Retry

공식 Github에 소개를 빌리자면, Spring 어플리케이션에 대한 재시도 지원을 제공한다고 한다. 위에서 이야기 했던 “RestTemplate"과는 사실 무관하고, 이를 활용해서 재시도 하는 “RetryRestTemplate"를 구현해보려 하는것이다. 우선 이 “Spring-Retry"의 예제를 보면 아주 심플하게 사용할 수 있다. 우선 pom에 구현에 필요한 dependency 를 추가하고 아래 코드를 보자.

<dependency>
	<groupId>org.springframework.retry</groupId>
	<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-aop</artifactId>
</dependency>

@Configuration
@EnableRetry // 1
public class Application {

 @Bean
 public Service service() {
 return new Service();
 }

}

@Service
class Service {
 @Retryable(RemoteAccessException.class) // 2
 public void service() {
 // ... do something
 }
 @Recover // 3
 public void recover(RemoteAccessException e) {
 // ... panic
 }
}

@EnableRetry 어노테이션을 @Configuration을 지정한 클래스 중 하나에 추가한다.
재시도 하려는 메소드에 @Retryable 어노테이션을 지정해준다.
재시도가 완료되는 시점에서 실행하고 싶을때 선언하는 어노테이션, @Retryable 동일한 클래스에서 선언되어야 하고 return type 은 @Retryable을 지정한 메소드와 동일해야 한다.

Retry Rest Template

이렇게 springframework 에서 제공해주는 spring-retry 를 이용해서 이번 포스팅의 목표인 재시도를 하는 Retry Rest Template 를 구성해보자. 우선, RestTemplate 를 Bean 으로 등록하고, 위에서 이야기 한 어노테이션들로 구성해보자.

@EnableRetry
@Configuration
public class RetryableRestTemplateConfiguration {

	@Bean
	public RestTemplate retryableRestTemplate() {
		SimpleClientHttpRequestFactory clientHttpRequestFactory = new SimpleClientHttpRequestFactory(); // 1
		clientHttpRequestFactory.setReadTimeout(2000);
		clientHttpRequestFactory.setConnectTimeout(500);

		RestTemplate restTemplate = new RestTemplate(clientHttpRequestFactory) {
			@Override
			@Retryable(value = RestClientException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000)) // 2
			public <T> ResponseEntity<T> exchange(URI url, HttpMethod method, HttpEntity<?> requestEntity, Class<T> responseType)
				throws RestClientException {
				return super.exchange(url, method, requestEntity, responseType); 
			}

			@Recover
			public <T> ResponseEntity<String> exchangeRecover(RestClientException e) {
				return ResponseEntity.badRequest().body("bad request T.T"); // 3
			}
		};

		return restTemplate;
	}
}

SimpleClientHttpRequestFactory 를 만들고 각 타임아웃을 설정해준 다음 RestTemplate 파라미터로 넘겨준다.
사용하는 곳에서 exchange 메소드를 이용할 것이므로 해당 메소드를 오버라이드 해준다. 먼저 해당 메소드에서 “RestClientException"이 발생할 경우 Retry 로직을 수행한다고 정해주고, 최대 시도는 3번, backoff 설정중 delay를 1000ms(1초)로 지정해서 재시도가 진행되도록 해준다.
2 에서 지정한 재시도가 끝나면 (재시도를 전부 다 하면) 해당 메소드를 수행하게 되어있고, 임의로 응답에 지정한 문구를 넘겨준다.

이렇게 하고 실제로 사용하는 로직에서 일부러 잘못된 URL을 호출해 보도록 하자. 그리고서 로그를 자세히 보도록 application.properties 에 “debug=true” 설정을 해준다.

SpringRestDocs를 SpringBoot에 적용하기

Sun, 08 Mar 2020 23:16:59 +0000

API를 개발하고 제공하기 위해서는 그에 해당하는 API 명세를 작성해서 사용하는 곳에 전달하게 된다. 어떤 URL에 어떤 파라미터를 사용해서 어떻게 요청을 하면 어떤 결과를 응답으로 내려주는지에 대한 관련 정보들. 이러한 “API 문서” 를 제공하는 방식은 상황에 따라 다양한 방법으로 사용되곤 한다.

API 코드와 해당 문서의 동기화가 자동으로 되어야 조금 편해질것 같다는 생각이 들었다.
출처 : https://dribbble.com/shots/3386291-API-Documentation

필자는 주로 “위키”(또는 일반 문서)를 활용해서 전달하곤 했었는데 API의 형태가 달라질 때마다 해당 위키를 수정해야만 하는 번거로움이 있었다. API 수정하면 위키도 수정하고. 깜박하고 위키 수정을 안하게 될 경우 왜 API 명세가 다르냐는 문의가… 그러다 알게된 Spring Rest Docs. (아무리 좋은 기술, 좋은 툴 이라 해도 실제로 본인이 필요로 하고 사용을 해야하는 이유가 생길때 비로소 빛을 발하는것 같은 느낌이다.)

이 포스팅에서는 swegger 와 비교하는 내용은 제외할까 한다. 워낙 유명한 두 양대 산맥(?)이라 검색해보면 각각의 장단점이 자세히 나와있기에…

최근 들어 TestCode 의 중요성을 절실하게 느끼고 있었고, TestCode 를 작성하면 자연스럽게 문서를 만들어 주는 부분이 가장 매력적이라고 생각이 들었다. 이를 반대로 생각하면, TestCode 가 실패할 경우 빌드 자체가 안되기에 어쩔수 없이 TestCode를 성공시켜야만 하고, 자연스럽게 정상적인(최신화 된) API 문서가 만들어지게 된다.

이번 포스팅에서는 다음과 같은 목표를 두고 실무에서 언제든지 활용이 가능한 약간의 “가이드” 같은 내용으로 작성해 보고자 한다.

Spring Boot 최신 버전에서 Spring Rest Docs 를 설정한다.
임의의 API 를 만들고 그에 따른 TestCase 를 작성한다.
Spring.profile 에 따라 Spring Rest Docs Url 을 접근 가능/불가능 할 수 있게 한다.

물론 필자의 방법이 다를수도 있지만, 이러한 방법을 토대로 보다 더 우아하고 아름다운 방법을 알아갈수 있지 않을까 하는 기대로.

Spring Boot 에 Spring Rest Docs 셋팅하고 TestCase 작성하기

우선 Spring Boot 프로젝트를 만든다. https://start.spring.io/ 에서 만들어도 되고 IDE 에서 제공하는 툴로 만들어도 되고. 만드는 방식은 무방하다. 그 다음 필요한 dependency 를 추가해 준다.

<dependency>
	<groupId>org.springframework.restdocs</groupId>
	<artifactId>spring-restdocs-mockmvc</artifactId>
	<scope>test</scope>
</dependency>

임의로 API를 작성하고

모델

@Getter
@Setter
public class Book {
	private Integer id;
	private String title;
	private String author;
}

컨트롤러

@RestController
public class BookController {

	@GetMapping("/book/{id}")
	public Book getABook(@PathVariable Integer id) {
		Book book = new Book();
		book.setId(id);
		book.setTitle("spring rest docs in spring boot");
		book.setAuthor("taetaetae");
		return book;
	}
}

해당 컨트롤러에 대한 TestCase 를 작성하자.

@WebMvcTest(BookController.class)
@AutoConfigureRestDocs // (1)
public class BookControllerTest {

	@Autowired
	private MockMvc mockMvc; // (2)

	@Test
	public void test_책을_조회하면_null이_아닌_객체를_리턴한다() throws Exception {
		mockMvc.perform(get("/book/{id}", 1)
			.accept(MediaType.APPLICATION_JSON))
			.andDo(MockMvcResultHandlers.print())
			.andExpect(MockMvcResultMatchers.status().isOk())
			.andDo(document("book", // (3)
				pathParameters(
					parameterWithName("id").description("book unique id") // (4)
				),
				responseFields(
					fieldWithPath("id").description("book unique id"),
					fieldWithPath("title").description("title"),
					fieldWithPath("author").description("author")
				)
			))
			.andExpect(jsonPath("$.id", is(notNullValue()))) // (5)
			.andExpect(jsonPath("$.title", is(notNullValue())))
			.andExpect(jsonPath("$.author", is(notNullValue())));
	}
}

(1) Spring Boot 에서는 해당 어노테이션으로 여러줄에 걸쳐 설정해야 할 Spring Rest Docs 관련 설정을 아주 간단하게 해결할 수 있게 된다. (참고)

(2) 공식 도큐먼트 에서는 4가지 방식을 말하고 있는데 이 포스팅 에서는 “MockMvc” 을 사용하고자 한다.

(3) “book” 이라는 identifier 를 지정하면 해당 TestCase 가 수행될때 snippets 가 생성되는데 해당 identifier 묶음으로 생성이 된다.

Jupyter 설치하고 원격접속까지 (for 파.알.못)

Sun, 09 Feb 2020 20:06:15 +0000

파이썬이라는 언어는 다른 프로그래밍 언어들에 비해 쉽고 직관적이라 그런지 프로그래밍을 처음 시작하는 사람들에게 더욱이 주목을 받고 있는것 같다. 정말 다양한 모듈들이 많아 여러분야에서 활용되고 있고 특히 언제부터인가 핫! 해진 분야(?)라 해도 과언이 아닐정도인 “머신러닝” 분야에서도 다양하게 사용되고 있는것 같다.

마침 필자가 속해 있는 팀 내에 머신러닝 스터디가 시작이 되었고, 그에 파이썬을 이용하여 스터디를 해야하는 상황. 하지만 스터디를 하는 팀원 절반 이상이 파이썬을 이용한 개발 경험이 없었고, 서로 배운것을 공유를 하면서 스터디를 하면 더 좋겠다는 생각이 들때 즈음. 언제 어디선가 봤던것이 머릿속을 스쳐 지나간다. 그건 바로 Jupyter(이하 주피터).

출처 : https://jupyter.org/

주피터는 수십 개의 프로그래밍 언어에서 대화 형 컴퓨팅을위한 오픈 소스 소프트웨어, 오픈 표준 및 서비스를 개발하기 위한 툴이라고 한다. 이 포스트를 작성하기 전까지만 해도 “주피터 == 파이썬 웹 개발툴” 이라고만 알고있었는데 좀더 찾아보니 다양한 언어를 지원하는것 같다.

그럼 이러한 주피터를 특정 서버에 설치하고 로컬에 파이썬을 설치하지 않아도 원격으로 파이썬 코딩을 해보면 좀더 스터디에 도움이 되지 않을까 하는 마음이 들었다. 또한 학교에서 운동장에 잔디를 깔아서 맘껏 뛰놀수 있게 하는 느낌으로 팀원들을 위해 설치를 해두고 원격으로 접속할 수 있게 해두면 모두가 편하고 쉽게 파이썬에 대해 경험을 해볼 수 있지 않을까 하는 마음으로 주피터를 설치를 해 보고자 한다.

본 포스팅의 목표는 다음과 같다.

환경 : CentOS 7.4 64Bit, python 2.7 (기본)
목표
- anaconda 를 활용하여 시스템 기본 파이썬을 건드리지 않는 가상환경을 구축한다.
- 주피터를 설치하고 원격으로 접속할 수 있도록 설정한다.

여기까지 보면 필자가 엄청나게 파이썬에 대해 잘 아는것처럼 보일수도 있어 미리 말하지만 필자는 찐 자바 개발자이면서 파이썬 개발 수준은 기본적인 스크립트를 작성하는 정도이다. 그러니 이 포스트를 읽고 있는 필자같은 파알못(?) 분들도 충분히 설치가 가능하다. (최대한 따라할수 있을 정도의 치트키 수준으로 작성 하고자 한다.)

아나콘다 설치 (덤으로 설치되는 주피터)

우선 아나콘다를 설치하자. 아나콘다는 Anaconda(이전: Continuum Analytics)라는 곳에서 만든 파이썬 배포판으로, 수백 개의 파이썬 패키지를 포함하고 있다고 한다. 즉, 아나콘다를 설치하고 만들어진 가상환경에서 파이썬 개발을 하면 다양한 모듈이 이미 설치되어 있기 때문에 편리하다는 이야기.

출처 : https://www.anaconda.com/

더불어 시스템에 기본으로 설치되어 있는 파이썬을 건드리면 여러 복잡한 문제가 발생할 수 있기에. 아나콘다를 활용하여 파이썬 3을 사용하는 가상환경을 만들어 보자. 설치는 아주 간단하다. 아나콘다 설치파일을 다운받고 이를 실행하면 끝. (user 레벨이 root 면 sudo 명령어를 생략해도 된다.)

$ wget https://repo.anaconda.com/archive/Anaconda3-2019.10-Linux-x86_64.sh
$ sudo bash Anaconda3-2019.10-Linux-x86_64.sh

Welcome to Anaconda3 2019.10

In order to continue the installation process, please review the license
agreement.
Please, press ENTER to continue
>>>
===================================
Anaconda End User License Agreement
===================================

Copyright 2015, Anaconda, Inc.
~~~ 중략 ~~~
Do you accept the license terms? [yes|no]
[no] >>> yes # yes!!

Anaconda3 will now be installed into this location:
/root/anaconda3

 - Press ENTER to confirm the location
 - Press CTRL-C to abort the installation
 - Or specify a different location below

[/root/anaconda3] >>> /home/anaconda3 # 설치될 경로를 설정해주고 기본 설정값에 설치하려면 그냥 엔터

~~~뭐가 엄청 설치된다. 물 한잔 먹고 오자.~~~

installation finished.
Do you wish the installer to initialize Anaconda3
by running conda init? [yes|no]
[no] >>> yes # yes!!

이렇게 되면 설치는 끝. 환경변수를 설정해서 기본 파이썬 환경을 아나콘다에 의해 설정되도록 맞춰주자.

스프링 부트로 멀티모듈 셋팅하기

Sun, 19 Jan 2020 10:29:03 +0000

서비스를 처음 만들기 시작할때면 각 직군별로 생각하는 포인트가 다양하다. 설계, 기획, 디자인, 개발. 여기서 개발은 프로젝트 셋팅을 어떻게 해야하지? 하는 고민을 하기 마련이다. 아주 간단하게 하나의 모듈로 모든 기능을 담당하도록 만들 수 있지만 기능별로 모듈을 나눠서 셋팅하는게 관리측면에서 장점이라 생각한다.

예를 들어보자. 도서관의 들어온 책 정보를 외부에 제공하는 “API”, 주기적으로 책 정보를 업데이트 하는 “Batch”. 이렇게 크게 두가지의 모듈이 있어야 한다고 가정했을때 어떤식으로 모듈을 설계할 수 있을까?

이번 포스팅에서는 스프링 부트와 메이븐을 활용해서 하나의 프로젝트(컴포넌트)에서 여러 모듈을 관리할 수 있는 Spring Multi Module을 셋팅하는 방법에 대해 알아보고자 한다. 필자도 셋팅하기 전에는 “그냥 하면 되는거 아니야?“라며 우습게 보다 아주 사소한 부분들에서 엄청난 삽질을 해서 그런지 꼭 포스팅으로 남겨놔야 겠다고 다짐했고 이렇게 정리를 할 수 있게 되어서 다행이라 생각한다.

어쩌면 우리가 있는 팀도 멀티모듈이 아닐까?
출처 : 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

“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.0.1-SNAPSHOT</version>
	<name>library</name>
	<description>Demo project for Spring Boot</description>

	<properties>
		<java.version>1.8</java.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
			<exclusions>
				<exclusion>
					<groupId>org.junit.vintage</groupId>
					<artifactId>junit-vintage-engine</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
	</dependencies>
</project>

API Pom.xml parent 부분이 설정되어 있는 모습을 볼수 있고, core 모듈을 사용하기 위해 dependency 에 추가를 해준다.

<?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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<parent>
		<artifactId>library</artifactId>
		<groupId>com.taetaetae</groupId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<modelVersion>4.0.0</modelVersion>
	<packaging>jar</packaging>
	<artifactId>api</artifactId>

	<dependencies>
		<dependency>
			<groupId>com.taetaetae</groupId>
			<artifactId>core</artifactId>
			<version>0.0.1-SNAPSHOT</version>
		</dependency>
	</dependencies>

	<build>
		<finalName>library-api</finalName>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

</project>

Core Pom.xml Core 모듈은 “jar"로 패키징 되어 다른 곳에서 사용되어야 하기 때문에 packaging 만 설정해준다.

<?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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<parent>
		<artifactId>library</artifactId>
		<groupId>com.taetaetae</groupId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<modelVersion>4.0.0</modelVersion>
	<packaging>jar</packaging>
	<artifactId>core</artifactId>

	<version>0.0.1-SNAPSHOT</version>

</project>

이렇게 하고서 Core 모듈에 공통으로 사용될 로직을 작성하고, API 모듈에서 이를 사용하는 로직을 작성한뒤, 빌드를 해보면 에러 없이 정상 작동을 하는 모습을 볼 수 있다.

더이상 기다리지 않아도 되는 배치 무중단 배포

Sun, 13 Oct 2019 15:46:12 +0000

지난 포스팅, 그러니까 우아한 형제들에서 초대를 받아 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을 중단하지 못하는 상황 즉, 실행중에 중단하면 트랜잭션이 깨져 무조건 기다려야만 하는 상황이라면 배포 또한 계속 지연될 수 밖에 없는 상황인 것이다. 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 참고)

네트워크 모니터링이 궁금할땐 ? Packetbeat !

Sun, 08 Sep 2019 18:11:34 +0000

모니터링은 서비스 로직 개발 만큼 한번씩 고민해보고 경험해 봤을 중요한 영역이라 할 수 있다. 그중 웹서버에서 제공해주는 엑세스 로그는 운영하고 있는 웹서비스에 대해 여러가지 측면에서 분석할 수 있는 가장 강력한 아이템 중에 하나라고 생각한다. 이를 통해 사용자들이 어떤 url을 많이 호출하고, 어떤 user-agent형태를 사용하는지 알게 되면 그에 따라 서비스 전략을 변경할수도 있고 악의적으로 공격적인 요청에 대해 웹서버단에서 차단을 할 수 있기 때문이다. 이렇게 inbound 트래픽(외부에서 들어오는 요청)에 대해서는 엑세스 로그를 잘 분석하면 기존의 웹 어플리케이션과는 전혀 무관하게 모니터링이 가능하지만 반대로 outbund 트래픽(외부로 나가는 요청)에 대해서는 어떤식으로 모니터링을 할 수 있을까?

월급통장의 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'])

위 코드를 실행하면 아래처럼 아주 간단하게 블로그 주인의 이름과 최신글 제목, 링크가 출력이 된다.

그러고 보니 너무 오랜만에 글쓰네… (숙연)

백문이 불여일견? 백견이 불여일타!

언제 어디서부터 유래된 이야기 인지는 모르지만 “백번 듣는것이 한번 보는것보다 못하고, 백번 보는것이 한번 타자 치는것보다 못하다” 라는 개발버전 속담이 있다. 자, 위에서 정의한 목표를 이루기 위해 실제로 각종 모듈을 설치해 보도록 하자! ( 필자가 테스트 했던 서버의 환경은 CentOS 7.4 64Bit 이니 참고 )

아파치 로드밸런싱으로 여러 WAS 운영하기

Sun, 04 Aug 2019 19:50:43 +0000

웹서버 하나만 사용하거나 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 없이) 톰켓 설정페이지로 랜딩이 되는것을 확인할 수 있다.

로드밸런싱을 위한 작업

여기까지는 본 포스팅을 작성하기 위한 밑거름이라고 말할 수 있다. 이제 실제로 로드밸런싱을 해볼 차례. 앞서 톰켓 하나만 설치했는데 편의상 톰켓 3개를 설치해두자. (하나를 설치하고 cp -r 명령어를 활용하는게 빠르다.) 그 다음 각 톰켓의 모든 포트를 셋다 다르게 설정해야 하는데 겹치지 않도록 설정해 두고 (필자는 앞자리를 1,2,3 이런식으로 다르게 설정하였다.) 워커(workers.properties)를 아래처럼 설정해주자.

스프링을 활용한 대용량 파일 업로드 구현

Sun, 21 Jul 2019 22:09:58 +0000

개발을 하다보면 실제로 직접 구현을 해본적은 없지만 여기저기서 들어본 지식과 그 동안의 짬밥(?)으로 추측해볼수 있는 부분들이 있다. 물론 모든일에 정답은 없겠지만 요즘 느끼는건 책에서 공부만 해본것과 다른 블로그들에서 눈으로만 보고 넘어가는것들 그리고 직접 손가락을 움직여가며 왜 여기서는 이 방법을 사용하지 고민하면서 구현을 해본다는건 정말 엄청나게 큰 차이가 있는것 같다. 웹 어플리케이션을 개발하다보면 한번 쯤 만나게 되는 파일 업로드 기능. 필자도 몇번 구현은 해봤지만 그냥 단순히 구현만 해본 상태였다가 최근에 그냥 파일 업로드가 아닌 대용량 파일 업로드에서의 문제가 발생하여 여기저기 삽질을 하게 되었고 정리도 해볼겸 스프링에서의 대용량 파일 업로드시 한번쯤 고려해봐야 할 부분에 대해 정리를 해보려고 한다.

물론 구글에서 검색을 해보면 아마 필자가 쓴것 보다 더 자세하고 좋은 글들이 있겠지만 필자는 보다 대용량에 집중에서 작성해 보고자 한다. 명심하자. “아무리 흐린 잉크라도 좋은 기억력보다 낫다” 라는 말이 있듯이

스프링을 활용한 파일 업로드 구현

우선 완전 초기상태에서 시작하기 위해 스프링 부트 프로젝트를 만들고 간단하게 파일 업로드를 할 수 있는 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

개발을 하다보면 항상 생각해야 할 부분중에 하나가 바로 확장성인것 같다. 이 부분에서 역시 문제가 되었던 것. 평소보다 용량이 큰 파일이 업로드가 되면서 (평소 3~~400MB 였다가 3~~4GB정도의 파일이 업로드가 되는 매직) 업로드가 안되는 상황이 발생하였다. 당연히 문제가 발생하면 누군가 말했듯 로그부터 살펴보았는데 Apache - (AJP) - Tomcat 으로 구성된 환경에서 tomcat 로그에 ### upload라는 로그가 없고 아파치 로그엔 502 에러가 발생한 것이었다. 왜 톰켓 로그도 안남고 그전에 에러가 발생하였을까? 이때부터 (근거없는 추측을 하며…) 고난과 역경의 삽질을 하기 시작하게 된다. 톰켓 버전이 문제일까? 로그가 안찍혔다면 다른 필터나 인터셉터에서 무언가를 먹고(?)있는건 아닐까? 잠깐, 근데 원래 대용량 업로드가 되긴 해? 파일 업로드/다운로드 하는 사이트 보면 별도 프로그램으로 하던데… 꼬불꼬불 미로속을 헤메는것만 같았던 삽질의 문제는 결국 메모리에 있었다. 파일을 업로드 하게 되면 해당 내용을 우선 메모리에 담게 되고 다 담은 후 메모리에 있는 내용을 was에 전달한 뒤 HttpServletRequest 로 넘어오게 된다.(Apache > Tomcat) 그런데 파일을 업로드 하면서 메모리에 파일이 써지다가 메모리 부족으로 OOM이 발생하게 되버린 것이었다. 또한 스프링 파일 최대크기를 별도로 지정하지 않고 있었기 때문에 메모리가 충분했다 하더라도 에러가 발생했을 상황이었다. ( https://spring.io/guides/gs/uploading-files/ 참조 )

Spring에서 Request를 우아하게 로깅하기

Sun, 30 Jun 2019 18:39:47 +0000

스프링 기반의 웹 어플리케이션을 만들다 보면 요청을 처리하는데 맨 처음에 위치하고 있는 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

투우사가 흔드는 빨간 천을 보며 돌진하는 황소처럼 (쓰고보니 너무 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/

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.getContentType().contains(
				ContentType.MULTIPART_FORM_DATA.getMimeType())) { // 파일 업로드시 로깅제외
				return;
			}
			JSONParser jsonParser = new JSONParser();
			Object parse = jsonParser.parse(collect);
			if (parse instanceof JSONArray) {
				JSONArray jsonArray = (JSONArray)jsonParser.parse(collect);
				setParameter("requestBody", jsonArray.toJSONString());
			} else {
				JSONObject jsonObject = (JSONObject)jsonParser.parse(collect);
				Iterator iterator = jsonObject.keySet().iterator();
				while (iterator.hasNext()) {
					String key = (String)iterator.next();
					setParameter(key, jsonObject.get(key).toString().replace("\"", "\\\""));
				}
			}
		} catch (Exception e) {
			log.error("ReadableRequestWrapper init error", e);
		}
	}

	@Override
	public String getParameter(String name) {
		String[] paramArray = getParameterValues(name);
		if (paramArray != null && paramArray.length > 0) {
			return paramArray[0];
		} else {
			return null;
		}
	}

	@Override
	public Map<String, String[]> getParameterMap() {
		return Collections.unmodifiableMap(params);
	}

	@Override
	public Enumeration<String> getParameterNames() {
		return Collections.enumeration(params.keySet());
	}

	@Override
	public String[] getParameterValues(String name) {
		String[] result = null;
		String[] dummyParamValue = params.get(name);

		if (dummyParamValue != null) {
			result = new String[dummyParamValue.length];
			System.arraycopy(dummyParamValue, 0, result, 0, dummyParamValue.length);
		}
		return result;
	}

	public void setParameter(String name, String value) {
		String[] param = {value};
		setParameter(name, param);
	}

	public void setParameter(String name, String[] values) {
		params.put(name, values);
	}

	@Override
	public ServletInputStream getInputStream() {
		final ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(this.rawData);

		return new ServletInputStream() {
			@Override
			public boolean isFinished() {
				return false;
			}

			@Override
			public boolean isReady() {
				return false;
			}

			@Override
			public void setReadListener(ReadListener readListener) {
				// Do nothing
			}

			public int read() {
				return byteArrayInputStream.read();
			}
		};
	}

	@Override
	public BufferedReader getReader() {
		return new BufferedReader(new InputStreamReader(this.getInputStream(), this.encoding));
	}
}

가장 중요한 부분은 IOUtils.toByteArray(is) 요 부분인데, InputStream은 한번밖에 읽을 수 없기 때문에 이 필터에서 스트림을 읽는 대신, 래퍼 구현으로 새 스트림 생성하도록 작업을 하였다. 자칫 잘못하다간 body의 내용이 유실될 수도 있기 때문이다. 참조 : http://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once http://stackoverflow.com/questions/3769259/why-is-the-parameter-value-an-object-hash-code-for-request-getparametermap-ge

spring-boot에서 mybatis로 mysql 연동하기

Sun, 21 Apr 2019 22:47:04 +0000

실무에서 개발을 하다보면 과거 누군가 잘 구성해 놓은 밥상(legacy)에 숟가락만 얹는 느낌으로 로직 구현만 할때가 있다. 그러다보면 각종 레이어가 어떻게 구성(설정)되어있는지도 모르고 간혹 설정에서 문제가 발생하면 “아 내가 이것도 모르고 이제까지 개발을 해왔나” 하는 자괴감이 들며 몇시간을 삽질하는 경우가 있다. 그게 지금의 필자인것 같다. (눙물…)

출처 : http://blog.naver.com/PostView.nhn?blogId=ondo_h&logNo=221437452142

사이드 프로젝트 초기셋팅을 하며 호기롭게 spring boot 최신버전에서 db를 연동하려 했는데 막상 완전 바닥부터 해본 경험이 적다보니 (spring boot 2 버전에서는 더욱더…) 어디서부터 뭘 설정을 해야할지… 그리고 이럴때 보는 도큐먼트를 봐도 잘 이해가 안되어 삽질을 해가며 당황하기 일쑤였다. 이번 포스팅에서는 아래와 같은 구성을 하는데 목표를 두고자 한다.

Spring Boot 2 프로젝트를 처음 만들고
mybatis 를 사용해서
mysql 을 연동하는것 (AWS 의 RDS를 사용, 추후 RDS사용법에 대해 블로깅 예정)

위와 같은 상황을 처음 접하는 분들께 도움이 되었으면 하는 바램으로 짧게나마 필자의 삽질기를 여행해보자.

Spring boot 2 프로젝트 만들기

필자는 IntelliJ를 사용하고 있어서 새로 프로젝트를 만들려고 할때 클릭 몇번만으로 dependency 설정까지 다 해주기 때문에 편하고 좋았다. 혹 이클립스나 다른 IDE를 사용하고 있다면 https://start.spring.io/ 을 참고하면 도움이 될것같다. 여기서도 클릭 몇번으로 IntelliJ 에서 해주는 것처럼 내가 사용할 모듈을 선택하고 generate 를 누르면 프로젝트가 생성되어 다운로드 받아진다. (참 좋은 세상…) 우선 File → New → Project 를 눌러서 아래 창을 열어보자. 그리고 뭔가 다 해줄것 같은 (개발도 해주면 안되나…) Spring Initializr을 선택후 아래와 같은 설정을 적어준 뒤 다음을 눌러준다.

사용할 모듈을 선택해주자. 필자는 이것저것(?)을 도와주는 lombok과 Mybatis, MySQL을 선택하고 프로젝트를 생성하였다. 그러면 이쁜(?) pom.xml 과 함께 당장 개발을 시작할 수 있는 환경이 제공된다.

<dependencies>
	<dependency>
		<groupId>org.mybatis.spring.boot</groupId>
		<artifactId>mybatis-spring-boot-starter</artifactId>
		<version>2.0.1</version>
	</dependency>
	<dependency>
		<groupId>mysql</groupId>
		<artifactId>mysql-connector-java</artifactId>
	</dependency>	
	<dependency>
		<groupId>org.projectlombok</groupId>
		<artifactId>lombok</artifactId>
		<optional>true</optional>
	</dependency>
</dependencies>

우선 여기까지 잘 되었는제 확인해보기 위해 Controller 에 현재시간을 출력하는걸 만들어 보고

@RestController
public class ApiController {

	@GetMapping(path = "/helloWorld")
	public String helloWorld() {
		return LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_DATE_TIME);
	}
}

톰켓을 실행해보면 정상적으로 접속과 출력이 되는것을 확인할 수 있다.

MySQL 연동하기

필자가 허둥지둥 했던점 중 하나는 MyBatis와 MySQL을 동시에 연동하려고 하다보니 문제가 발생해도 어디서의 문제인지를 제대로 파악하지 못하고 삽질했다는 점이다. 여기서 정확히 짚고 넘어가면 우선 데이터를 연결해주는 ORM인 MyBatis를 셋팅해준 다음 MySQL을 연동해주는 식으로 분리해서 설정을 하면 햇갈리지 않고 (돌아가지 않고) 보다 빠르게 설정이 가능할것 같다. (여기서 순서는 중요하지 않고 별도로 설정해야 한다는 관점이 중요한것 같다.) 우선 src/main/resources폴더에 있는 application.properties 에 다음처럼 작성해주자.

spring.datasource.hikari.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.hikari.jdbc-url=jdbc:mysql://{url}:{port}/{db}
spring.datasource.hikari.username={id}
spring.datasource.hikari.password={password}

위의 jdbc-url 항목에서 AWS에서 제공하는 RDS를 사용하는 경우 RDS에서 제공해주는 엔드포인트와 포트를 적어주면 된다. (추후 AWS - RDS에 대해 블로깅 예정이다.) Spring Boot 2.0 이후부터 기본적으로 사용되는 커넥션 풀이 HikariCP로 변경되었다고 한다. (링크) 커넥션 풀 종류중 성능이 좋다고 하는데 링크를 가보면 다른 커넥션 풀 라이브러리와 성능을 비교한 벤치마크 결과를 확인할 수 있다. 위처럼 spring.datasource.hikari 가 prefix로 붙고 각종 정보들을 적어주어 config 에서 인식될수 있도록 해주자. 그 다음 DataSource 설정을 해준다.

@Slf4j
@Configuration
@PropertySource("classpath:/application.properties")
public class DatabaseConfiguration {
	@Bean
	@ConfigurationProperties(prefix = "spring.datasource.hikari")
	public HikariConfig hikariConfig() {
		return new HikariConfig();
	}

	@Bean
	public DataSource dataSource() {
		DataSource dataSource = new HikariDataSource(hikariConfig());
		log.info("datasource : {}", dataSource);
		return dataSource;
	}
}

위 내용은 DataSource 를 hikariConfig에서 설정한 정보로 만들어 준다는 의미이다. 이렇게만 하고 프로젝트를 다시 실행시켜보면 logger 에 의해 datasource 의 정보를 볼수가 있다.

AWS 프리티어 발급부터 EC2 접속까지

Sun, 14 Apr 2019 17:39:03 +0000

IT 쪽에 일을 하고 있거나 관심을 가지고 있는 사람이라면 한번쯤을 들어봤을 AWS(Amazon Web Services). 이름에서도 알수있는 것처럼 아마존에서 제공하는 각종 원격 컴퓨팅 웹서비스이다. 아마존은 이러한 서비스를 누구나 쉽게 접근해볼수 있도록 AWS 프리티어를 제공해 주는데 이 프리티어 만으로도 과금없이 (또는 최소화 하여) 웹서비스를 구성할수 있다. 필자가 운영하고 있는 기술블로그 구독서비스또한 AWS 프리티어로 운영되고 있다. 최근 GDG Seoul, P-typer, Sketch Seoul 에서 주최한 D.light 345 투게더톤에 참가하며 사이드 프로젝트를 하고 있는데 마침 AWS를 사용하게 되었다. 예전에 사용했을때는 장님 코끼리 만지듯이 설정을 했었는데 이번기회를 통해 다시한번 정리를 해본다. 본 포스팅에서는 AWS 계정을 발급받고 신용카드 확인까지 된 계정에서 EC2 서버를 발급받고 putty를 활용하여 서버에 접근을 해보는것을 목표로 둔다.

(사이드 프로젝트를 하면서) 아마도 웹서비스를 개발하면서 AWS를 활용하는 부분에 대해 시리즈물로 포스팅을 하게 될것 같다. 사실 너무 간단해서 이런걸 글로 쓰나? 라고 할수도 있지만 눈으로만 보는것과 직접 해보는 것이 다르고, 이걸 다시 글로써 정리를 하는것 또한 완전 다른 부분이기 때문에 포스팅을 해본다.

EC2 생성하기

EC2? Amazon Elastic Compute Cloud의 약자로 물리서버가 아닌 클라우드 서버를 제공하고 있다. EC2의 장점은 서버의 스펙을 쉽고 자유롭게 조정할 수 있는점이 가장 매력있게 생각한다. 우선 콘솔에 들어가 EC2를 검색후 접속을 하고 인스턴스 시작을 눌러서 인스턴스 생성 화면으로 들어간다.

AMI 즉 생성할 이미지를 선택하는 부분인데 여기서 주의할점은 잘못선택 했다간 계정 만들었을때의 카드로 생각지도 못할 금액이 결제가 되버릴수도 있다. (실제로 필자도 AWS를 처음 만져볼때 아무생각없이 좋아보이는걸로 했다가 한 30달러 정도를 지불했어야만 했다…) 좌측에 보면 프리 티어만이라는 체크박스를 체크하고 자신이 원하는 이미지를 선택하자. 일반적인 리눅스 서버를 발급받고 싶기 때문에 빨간 영역의 이미지를 선택하고 선택한 이미지의 스팩을 다시한번 확인하자. (cpu 1개에 메모리도 1기가… 너무 짜지만 무료니까…)

마지막으로 시작하기 를 누르면 키 페어를 선택 또는 생성하도록 안내가 나오는데 당연히 아무것도 안한 상태라 새 키 페어 생성을 선택해 주고 이름을 지정한뒤 키 파일을 받아준다. 이 부분에서도 조심해야할 점이 키 페어를 한번 다운 받으면 다시 동일한 키 페어를 다운받을수가 없게 된다. (나중에 다시 발급을 받아야 하는 번거로운 문제가…) 다운을 받고 잊어버리지 않도록 잘 보관해두자.

키 페어를 다운 받으면 생성중이라는 메세지와 함께 결과화면이 나온다. 여기서도 중요한 부분! 프리티어라는 달콤한 키워드 때문에 들뜬 마음으로 성급하게 빨리 서버를 받아보고 싶다고 다음다음 신공을 하다보면 자칫 간과할수가 있는데 화면을 보면 결제 알림 생성이라는 다행스러운 기능이 있다. 별 어려운 설정이 아니니 꼭 설정을 해서 필자같이 기부(?)를 하는 일이 발생하지 않았으면 한다…

EC2 인스턴스가 생성이 되었다. 인스턴스의 각종 정보를 확인할수가 있는데 public IP, public DNS 까지 제공되는것을 확인할 수 있다. (추후 DNS를 구입하게 되다면 이 IP에 연결을 시켜 도메인으로 해당 서버에 접속을 할수가 있게 된다.)

putty 로 발급받은 EC2 인스턴스에 접속을 해보자.

이제 발급받은 EC2 인스턴스에 접속을 해볼 차례이다. 다양한 서버 접속툴이 있지만 필자는 putty를 가장 선호한다. 디자인은 구닥다리처럼 보일지 모르겠지만 개인적으로 직관적인 UI에 가벼운 프로그램이라 생각이 든다. 우선 putty를 다운 받고 putty.exe를 실행시킨뒤에 바로 ssh 접속을 하면 너무 간단하게 서버 접속에 성공을 할수 있지만 위에서 받은 키 페어 파일을 다시 private key 로 전환해야 하는데 putty를 다운받으면 동일한 폴더에 puttygen.exe라는 파일을 실행시켜주자. 그다음 pem파일을 불러와서 마우스를 움직여서 게이지(?)를 다 채우고 save private key를 줄러 저장을 하는데 여기서 주의할점은 ppk파일명을 pem파일명과 동일하게 저장해야 한다는 것이다. (안그러면 서버 접속시 실패가 남… 삽질…)

Jenkins 업그레이드 및 Master-Slave 구성

Sun, 17 Mar 2019 18:23:03 +0000

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

실제로 Jarvis가 있다면 얼마나 편할까
출처 : https://gfycat.com/ko/colossalsociablebuffalo

지난 포스팅에서는 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가 슬레이브 서버에 설치/실행을 하고 작업을 분할하는것을 확인할 수 있었다. 자, 그럼 시작해보자.

마스터 서버에서 공개키와 개인키 생성 먼저 마스터 서버와 슬레이브 서버를 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

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

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

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

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

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

기술블로그 구독서비스 개발 후기 - 3부

Sun, 17 Feb 2019 01:17:27 +0000

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

오예~ 1,000명이다! 땡큐!
출처 : https://gfycat.com/ko/leafytorngroundbeetle

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

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

(한마디로 정리할 순 없는 지난 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년간은 프리티어로 운영하고 그다음엔 (혹은 소프트웨어적으로 한계까지 도달한다면) 서버를 구매해서 운영하게 될 것 같다. (적어도 이후에도 이 서비스를 유지한다는 가정하에…)

농부의 마음으로…
출처 : http://www.iwithjesus.com/news/articleView.html?idxno=2511

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

누구나 할 수 있는 엑세스 로그 분석 따라 해보기 (by Elastic Stack)

Sun, 10 Feb 2019 14:37:31 +0000

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

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

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

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

전체적인 흐름

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

외부에서의 접근이 발생하면 apache 웹서버에서 설정한 경로에 access log가 파일로 생성이 되거나 있는 파일에 추가가 된다. 해당 파일에는 한줄당 하나의 엑세스 정보가 남게 된다.
fileBeat에서 해당 파일을 트래킹 하고 있다가 라인이 추가되면 이 정보를 logstash 에게 전달해준다.
logastsh 는 filebeat에서 전달한 정보를 특정 port로 input 받는다.
받은 정보를 filter 과정을 통해 각 정보를 분할 및 정제한다. (ip, uri, time 등)
정리된 정보를 elasticsearch 에 ouput 으로 보낸다. (정확히 말하면 인덱싱을 한다.)
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 Redirect 처리중에 발생한 Out Of Memory 원인 분석하기

Thu, 10 Jan 2019 18:39:47 +0000

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

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

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

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

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

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

천만 명의 사용자에게 1분 내로 알림 보내기 (병렬프로세스의 최적화)

Wed, 02 Jan 2019 12:43:44 +0000

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

상황파악 및 목표

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

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

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

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

알림 프로세스

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

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

기존 구조

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

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

Jenkins 설치 치트키

Sun, 02 Dec 2018 04:37:59 +0000

“show me the money”, “black sheep wall”. 어렸을적 스타크래프트라는 게임이 나오고서 입에 달고 살았던 치트키. 게임이 시작되고 해당 치트키를 입력하면 돈이 들어오거나 맵이 훤하게 보여 컴퓨터를 이기는데 도움을 주곤 했었다. 개발을 하면서 Jenkins는 나 대신 어떤 업무를 수행하는데 강력한 툴 중에 하나이다. (물론 만능이라는 소리는 아니지만…) 새로운 프로젝트가 시작되거나 개발도중 무언가 자동화를 하고 싶을 경우엔 Jenkins를 찾게 되는데 그럴때마다 설치를 하고 이런저런 설정이 필요하다. 눈치를 챘을수도 있지만 이 포스트는 오로지 젠킨스 설치하는 방법을 아주 간단하고 핵심만 정리하고자 한다. 마치 치트키처럼. 나중에 다시 보기위해 + 누군가 해당 포스트를 보고 도움이 되었으면 하는 바람으로.

(물론 이 방법밖에 있는건 아니지만 필자는 아래와 방법을 사용하고 있다.)

우선 CentOS 환경에 Java가 설치되어 있는 상황이라 가정한다.

적당한 위치에 tomcat 다운 ( https://tomcat.apache.org/download-80.cgi )
```
wget {압축파일 다운경로, 필자는 apache-tomcat-8.5.35 }
```

압축 해제후 하위 폴더중 webapps로 이동

tar -zxvf apache-tomcat-8.5.35.tar.gz
cd apache-tomcat-8.5.35/webapps

Jenkins 다운 ( https://jenkins.io/download/ )

wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war

tomcat 하위폴더중 conf 폴더로 이동
```
cd ../conf
```

server.xml 수정 및 http port 확인

vi server.xml

<Host> 하위에 추가
<Context path="/jenkins" debug="0" privileged="true" docBase="jenkins.war" />

port 확인
<Connector port="8080" protocol="HTTP/1.1"/>

해당 서버의 ip와 위 port에 맞춰 url 입력후 jenkins 설치
```
http://ip:8080/jenkins
```

Jenkins에서 파이썬 출력을 실시간으로 보고싶다면?

Sun, 02 Dec 2018 01:40:11 +0000

필자가 운영하고 있는 Daily Dev Blog 라는 서비스는 매일 동일한 시간에 주기적으로 데이터를 크롤링 하고 사용자에게 메일을 발송하는 일련의 작업을 수행하고 있다. 헌데 예상하지 못한 부분에서 예외가 발생하게 되면 어떤경우는 메일 발송을 못한다거나 기존에 발송했던 데이터를 다시 보내는 등 정상적이지 못한 상황을 맞이하게 된다.

메일이 하루라도 잘못오면 여기저기서 연락이 온다. 감사한 분들…

이런저런 바쁜일들로 차일피일 미루다 마침 여유가 생겨 기존에는 Crontab 스케쥴로 파이썬 스크립트를 실행하던 것에서 Jenkins로 옮기는 작업을 했다. 젠킨스가 스케쥴링을 해주고 실행이력을 보여주며, 실시간으로 스크립트가 돌아가는걸 볼수 있을것 같다는 기대감에서이다. 위에서 이야기 했던 예외상황을 보다 빠르고 편하게 실시간으로 디버깅을 하기 위해서가 가장 컸다.

당연히 될거라고 생각했으나…

작업은 간단할꺼라 생각했다.

우선 Jenkins를 설치하고
기존에 스크립트 파일을 Jenkins Job으로 옮긴후에
적당한 코드 중간중간에 디버깅이 용이하도록 로그를 출력하게 해둔다음
스케쥴링만 걸어두면 끝이라고 생각했다.

하지만, 이렇게 간단하게 끝날것만 같았던 작업이 은근 귀찮은 작업이 될줄이야. 디버깅을 위해 로그를 출력하도록 해놨는데 모든 스크립트가 끝이 나서야 해당 로그가 출력되는 것이였다. 로그를 실시간으로 볼수 없다면 Crontab에서 Jenkins로 옮기는 이유가 크게 없게 된다. 실제로 아래처럼 코드를 작성하고 Jenkins Job을 실행시켜보면 다 끝나고서야 출력이 되는걸 볼수 있었다.

(1초에 한번씩 5초동안 로그를 찍는 간단한 코드다.)

import time

print('start')

for second in range(0,5) :
 print(second)
 time.sleep(second)

print('end')

스크립트가 다 끝나서야 출력을 볼수 있다ㅠ 실시간으로 디버깅이 어렵다.

그럼 어떻게 해야할까?

개발을 하면서 만나는 대부분의 문제들은 누군가 과거에 경험했던 문제였고, 이미 해결된 문제일 확률이 상당히 높은것들이 많다. 이번에도 역시, 갓 스택 오버플로우 : https://stackoverflow.com/questions/107705/disable-output-buffering

위 링크에서 알려준것처럼 해보면 다음과 같이 로그가 출력되는대로 젠킨스에서 볼수 있게 된다.

콘솔환경에서의 디버깅은 로깅이 최고!

정리해보면 다음과 같은 방법이 있겠다.

Execute Python script 을 활용하여 Jenkins 에 직접 코드를 작성하는 경우

print의 flush옵션을 활용 ( https://docs.python.org/3/library/functions.html?highlight=print#print )

print('hello', flush=True)

매번 print 가 될때마다 flush가 되도록 재정의

import sys

class Unbuffered(object):
 def __init__(self, stream):
 self.stream = stream
 def write(self, data):
 self.stream.write(data)
 self.stream.flush()
 def writelines(self, datas):
 self.stream.writelines(datas)
 self.stream.flush()
 def __getattr__(self, attr):
 return getattr(self.stream, attr)

sys.stdout=Unbuffered(sys.stdout)

Execute shell을 활용하여 특정경로의 Python 파일을 실행할 경우

-u 옵션을 줘서 실행시킨다. ( python -u python_module.py )

이렇게 두고보면 너무 간단한 작업인데 이런 방법을 모르는 상황에서는 작성된 Python Script를 Shell Script로 다시 감싸보거나 Python 코드를 쓰지 말까 까지 생각했었다… 삽질의 연속들… (Shell Script로 작성하면 바로바로 보였기 때문…)

다시한번 모르면 몸이 고생한다(?)라는걸 몸소 체험한 좋은…시간이였다.

2018 Pycon. 그리고 첫 발표를 하다.

Tue, 28 Aug 2018 23:43:16 +0000

IT관련 행사에 참여하면 여러가지 정보를 얻을수 있다. 개인적으로는 사실 정보를 얻기 위함보다 그곳의 분위기를 현장에서 몸소 느끼고 참여한 사람들의 눈빛을 보며 해이해진 마음가짐을 다시 다잡을수 있음이 가장 큰 목적이다. 그에 올해 Pycon도 하나의 전환점이 되길 바라는 마음으로 신청을 하게 되었다.

등록

https://www.pycon.kr 얼리버드 등록을 한다고 Facebook에서 홍보를 하길래 그런가보다 했는데 잠깐 회사일에 집중하고 다시 보니 이미 매진이 되어있었다. 사실 Pycon 은 올해가 처음 가보는거라 인기를 실감할수 없었는데 이정도일줄은 상상도 못했다. (나중에 알게 된 사실이지만 올해가 가장 인원이 많았다고…) 그래서 나중에 진행되었던 일반표 등록은 휴대폰 알람까지 걸어두며 늦지않게 등록할수 있었다. 세부 일정들이 업데이트가 되고 어떤 세션을 들을까 고민하면서 간략 소개를 하나둘씩 보게 되었는데 Python을 만지며 평소에 궁금했던거나 재밌어 보이는 세션들이 너무많아 고민을 많이 했다. 한가지 아쉬운건 로그인 기반이 아니다 보니 (임시 로그인기반?) 내 시간표 설정하는게 없었다. 나는 별도로 적어서 갔지만 나중엔 그런 기능이 생겼으면 좋겠다.

2019년 Pycon엔 크롬 익스텐션으로 기능을 만들어 로그인 여부와 상관없이 몇시에 내가 어떤 세션을 들을건지에 대한 설정을 하고 이를 이미지로 캡쳐해서 출력/다운 받을수 있는 걸 만들어 보고 싶다. (그전에 미뤄뒀던 크롬 익스텐션 개발하는 방법부터 공부하자…)

첫째날

개인적으로 아침잠이 너무 많은데 알림이 울리기도 전에 눈이 떠졌고 행사장에 도착해보니 후원사 부스는 아직 텅텅 비어있었고, 밤새가면서 준비를 하셨는지 자원봉사자 분들은 여기저기 빈백에 누워(쓰러져) 자고 있었다. 그만큼 Pycon에 대한 기대가 컸나보다. 시간이 지나니 하나둘씩 사람들이 등록을 하며 오기 시작하였고 역시나 행사에 꽃중에 꽃인 후원사 부스에서 나눠주는 이벤트 상품들을 받기 바빴다.

DIVE INTO DIVERSITY !!

키노트를 시작으로 사람들은 각자 듣고싶은 세션에 참가하며 행사는 시작이 되었다. 전체적으로 기술의 난이도는 초급 수준의 발표였던걸로 느껴졌다. (물론 나는 초초초급도 안되는 꼬꼬마 수준이지만…) 대부분 Python으로 어떤걸 해봤고, 어떤 어려움이 있었고, 이러저러한 상황들을 만났으며, 요런 경우에서는 어떻게 하며 해결을 하였다는 등 기술을 활용한 “경험기"에 대한 내용들을 들을수 있었다. Pycon의 슬로건인 DIVE INTO DIVERSITY에 걸맞게 아주 다양한 주제로 흥미있는 발표내용들이였다. 기억나는 것들중에 인상깊었던 부분들을 정리해본다.

파이썬 문화(?)중의 하나는 몰라서 물어보는 사람에게 구글링을 하라기보다 직접 알려주라는 것이다.
배우고 싶다면 다른사람들을 가르치는것부터(알려주는것부터) 시작하라.
여성 개발자, 여성 발표자들도 점점 늘어나고 있다.
파이썬을 개발 현장(?)이 아닌 다른곳에서 사용한다면 작업 속도도 빠르고 얻어내는 가치또한 훨씬 더 방대하다.
엑셀로 할수 있는 작업을 파이썬으로 할수 있다.
파이썬의 다양한 라이브러리는 일상의 도움을 준다.

행사를 들으며 꼭 질문을 해야지 하는 마음을 갖고 있었는데 (그래야 오래 기억에 남으니) 마침 어떤 세션에서 궁금한게 있어 질문을 할수 있었다. (질문을 하니 파이썬 관련 책 선물도 받았다.^^) 그리고 마지막 라이트닝 톡이라는 세션이 있었는데 여러 발표자들이 짤막하게 5분동안 하고싶은 이야기를 하는 세션이였다. 5분이라는 제한이 있기에 다들 쉽고 편하게 발표하는듯 보였으나 발표 자료나 발표내용을 보면 꼭 그렇게 간단하게 발표하는건 아니였다. 본 세션에서 말하기엔 다소 분량이 작은 알차고 깨알같은 발표도 있었고, 매년 Pycon 라이트닝톡에 발표하는게 목표이신 분도 있었다. 발표를 들으면서 난 언제 저런자리에 가서 발표를 할수 있을까 하는 마음이 스쳐 지나갈때 쯤. “왜못하지? 나 파이썬으로 만든거 있잖아?” 라고 혼잣말로 궁시렁거리며 둘째날에 있는 라이트닝톡에서 발표하기로 마음을 먹고 서둘러서 참가 신청을 보냈다. 그러고서는 저녁을 먹고 집에 늦게 돌아와 새벽 3시넘어서야 발표자료를 완성하였지만 “발표” 라는 부담감때문에 어렵게 잠에 들었다.

둘째날

어제와는 달리 오늘은 잠을 많이 못자서 인지 늦게 일어나 첫 세션이 시작하고서 거의 끝날 즈음에 행사장에 도착하게 되었다. “괜히 발표 한다고 한걸까” 라는 생각이 들며 진행위 본부에 가서 발표 순서를 확인해보니 첫번째… 슬슬 머리가 아파오기 시작했다. 그래도 듣기로한 세션은 들어보고 싶어서 집중해서 세션들을 돌아가며 들었지만 머릿속에는 온통 “발표 발표 발표"라는 생각때문에 오히려 다른분께서 하시는 발표를 집중해서 듣지 못하였다.

자바 객체 복사하기 ( feat. how to use CloneUtils? )

Tue, 21 Aug 2018 18:02:47 +0000

자바(Java)로 개발을 하다보면 한번쯤 객체를 복사하는 로직을 작성할때가 있다. 그때마다 나오는 이야기인 Shalldow Copy 와 Deep Copy. 한국어로 표현하면 얕은 복사와 깊은 복사라고 이야기를 하는데 이 두 개념의 차이는 아주 간단하다. 객체의 주소값을 복사하는지, 아니면 객체의 실제 값(value)를 복사하는지. 이 둘의 차이점을 소개하는 글들은 워낙 많으니 패스하도록 하고 이번 포스팅에서는 Deep Copy를 할때 org.apache.http.client.utils 하위에 있는 CloneUtils 사용법에 대해 정리 하고자 한다.

그냥 쓰면 되는거 아닌가? 라고 생각했지만 (별거 아니라고 생각했지만) 해보고 안해보고의 차이는 엄청컸고 사용할때 주의점이 몇가지 있어 정리 하려고 한다.

예제에 앞서 본 포스팅에서 사용할 객체를 간단히 정리하면 다음과 같다. (학교에서 학생 신상정보를 관리한다고 가정해보자.)

public class Student {
	String name; // 이름
	int age; // 나이
	Family family; // 가족
}

public class Family {
	String name; // 이름
	int age; // 나이
	boolean isOfficeWorkers; // 직장인 여부
}

public class PhysicalInformation {
	int height; // 키
	int weight; // 몸무게
}

객체는 Cloneable interface 를 implement 해야하고 clone 메소드를 public 으로 override 해야한다.

당연한 이야기가 될수도 있으나 CloneUtils를 사용하기 위해서는 해당 객체는 Cloneable interface 를 implement 해야한다. 그리고 나서 clone 메소드를 override 해야되는데 여기서 가장 중요한점은 외부에서도 호출이 가능해야하기 때문에 public 으로 override를 해야한다. (기본은 protected 로 되어있다.) 우선 간단히 객체를 생성하고 출력부터 해보자. (출력을 이쁘게 하기 위해 ToStringBuilder.reflectionToString을 사용하였다.)

PhysicalInformation physicalInformation = new PhysicalInformation();
physicalInformation.height = 180;
physicalInformation.weight = 70;

System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE));

결과는 당연히

PhysicalInformation@5d6f64b1[height=180,weight=70]

이제 Cloneable interface 를 implement 하고 clone 메소드를 public 으로 override 한뒤, CloneUtils를 사용해서 객체를 복사해보자. 테스트를 하면서 Shalldow Copy도 해보자.

// class setting
public class PhysicalInformation implements Cloneable{
	int height;
	int weight;

	@Override
	public Object clone() throws CloneNotSupportedException { // public 으로 바꿔주자.
		return super.clone();
	}
}

// test code
PhysicalInformation physicalInformation = new PhysicalInformation();
physicalInformation.height = 180;
physicalInformation.weight = 70;

PhysicalInformation physicalInformationShalldowCopy = physicalInformation;
PhysicalInformation physicalInformationDeepCopy = null;
try {
	physicalInformationDeepCopy = (PhysicalInformation)CloneUtils.clone(physicalInformation);
} catch (CloneNotSupportedException e) {
	e.printStackTrace();
}

// 원본
System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE));
// 얕은 복사
System.out.println(ToStringBuilder.reflectionToString(physicalInformationShalldowCopy, ToStringStyle.DEFAULT_STYLE));
// 깊은 복사
System.out.println(ToStringBuilder.reflectionToString(physicalInformationDeepCopy, ToStringStyle.DEFAULT_STYLE));

// 값 변경
physicalInformation.weight = 80;
physicalInformation.height = 170;

// 원본
System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE));
// 얕은 복사
System.out.println(ToStringBuilder.reflectionToString(physicalInformationShalldowCopy, ToStringStyle.DEFAULT_STYLE));
// 깊은 복사
System.out.println(ToStringBuilder.reflectionToString(physicalInformationDeepCopy, ToStringStyle.DEFAULT_STYLE));

결과는 원본과 얕은 복사를 한것은 메모리 주소(?)가 같으나 깊은 복사를 한것은 데이터는 같지만 주소가 다르고 값을 변경해도 영향을 주지 않는다. (완전히 서로다른 객체인것을 증명)

PhysicalInformation@1376c05c[height=180,weight=70]
PhysicalInformation@1376c05c[height=180,weight=70]
PhysicalInformation@1b4fb997[height=180,weight=70]

PhysicalInformation@1376c05c[height=170,weight=80]
PhysicalInformation@1376c05c[height=170,weight=80]
PhysicalInformation@1b4fb997[height=180,weight=70]

만약 위에서 clone을 기본값인 protected로 override를 하게 되면 어떤 결과를 가져올까?

Exception in thread "main" java.lang.NoSuchMethodError: com.PhysicalInformation.clone()
	at org.apache.http.client.utils.CloneUtils.cloneObject(CloneUtils.java:55)
	at org.apache.http.client.utils.CloneUtils.clone(CloneUtils.java:77)
	at com.Test.main(Test.java:16)

접근제한자에서 눈치를 챌수도 있었겠지만 접근을 할수없어 CloneUtils 이 리플렉션을 하는 과정에서 Exception을 발생한다. 꼭! public 으로 override를 해주자.

객체 내에 clone이 안되는 변수는 별도 처리가 필요하다.

객체 내에 있는 멤버 변수는 원시 변수(int, char, float 등) , Immutable Class (String, Boolean, Integer 등) 또는 Enum 형식일 때는 원본의 값을 바로 대입해도 되지만, 그렇지 않을 때는 멤버변수의 clone을 호출하여 복사해야 한다. 말로만 보면 무슨이야기 인지 모르니 예제를 보자.

public class Student implements Cloneable {
	String name;
	int age;
	Family family;

	@Override
	public Object clone() throws CloneNotSupportedException {
		return super.clone();
	}
}

Student 클래스에서 Cloneable 를 implements 하고 clone 메소드를 override 하였다. (여기서 구멍이 있다!!) 그다음 Family 클래스는 초기 그대로 두고 CloneUtils을 사용해서 객체를 복사하는 코드를 작성해보자.

기술블로그 구독서비스 개발 후기 - 2부

Thu, 09 Aug 2018 20:37:26 +0000

1부에서는 기술블로그 구독서비스(이하 서비스)를 왜 만들게 되었고 어떤구조로 만들가에 대해 이야기를 해보았다면, 이번 포스팅에서는 만들면서 만나게 된 각종 트러블슈팅 종합세트(?)를 하나씩 풀어보고자 한다. 물론 개발을 하면서 아무 문제 없이 잘 되면 당연히 좋겠으나 잘되도 이상한게 개발이라는 세계가 아니던가.

잘 안되면 문제, 잘 되도 문제 ㅠㅠ 출처 : https://www.clien.net/service/board/park/9111495

지난 1부에서 이야기 했던것처럼 문제 - 해결, 문제 - 해결 식으로 나열해보고자 한다. 다소 글의 전개가 뒤죽박죽일수도 있겠지만 말 그대로 트러블슈팅 종합세트이니 독자들의 양해를 미리 구한다.

10시에 로직이 실행되었지만 메일을 11시 넘어서 받게 된다.

👉 해결방안 : Divide and Conquer

본 서비스의 요구사항중 하나는 매일 오전 10시, 구독자들에게 어제 등록된 글을 수집하여 메일로 보내주는게 있다. 우선 로직은 다음과 같은 순서로 진행되게 개발하였고, jenkins 등 별도의 스케쥴러 관리 어플리케이션에 의해 할수도 있었으나 이 또한 심플하게 crontab 에 등록하여 매일 오전 10시에 실행되도록 하였다.

1. awesome-devblog 에서 블로거들의 RSS 피드를 조회한다.
2. 어제 등록된 글이 있다면 리스트에 담는다.
3. 조회가 끝나면 메일형식에 맞추어 html 문자열을 만든다.
4. 만들어진 문자열을 가지고 등록된 구독자들에게 메일을 보낸다.

로직은 아주 간단했다. 데이터를 파싱하는 방법이나 메일형식에 맞추어 html문자열을 만드는 등 별도의 라이브러리를 사용하는 다소 복잡한 부분만 빼면 단순히 for문과 if문을 조합해서 로직을 구성할수 있었다. 헌데, 10시에 해당로직이 실행되었지만 최대 1시간이 지나고서야 메일을 받는 경우도 있었다. 이게 무슨일일까!? 눈치를 챘을수도 있지만 RSS 피드를 조회하는 곳에서 오래걸린 것이다. 티스토리나 네이버등 다른 블로그들은 RSS를 읽고 파싱하는 속도가 그렇게 오래 걸리지 않았는데 (1초 이내) 유독 이글루스 블로그의 RSS파싱이 오래걸리는건 1분까지도 걸리던 것이였다. ( 참고로 RSS 파싱모듈, yaml 파싱모듈 을 사용했다. ) 아마 RSS의 형식이 약간 달라서 그런것 같긴 한데 그렇다고 이글루스 일 경우에 파싱을 다르게 하는건 좀 그렇고… 추후 이글루스가 아닌 또다른 파싱속도가 느린 블로그의 RSS를 만날수도 있기에 RSS 타입별로 예외처리를 하는건 좀 아닌것 같았다. 이런저런 고민끝에 아주 간단하게도 임무(?)를 나누는식으로 해결 하였다. 즉, RSS를 읽고 메일에 보낼 데이터를 만드는 job 하나와 만들어진 데이터를 가지고 이메일을 보내는 job 으로 나눈뒤 RSS를 분석하는 job은 9시에, 메일보내는 job은 10시에 보내도록 해서 생각보다 아주 심플하게 문제를 해결할수 있었다. 복잡하고 어려운 문제를 꼭 복잡하고 어렵게만 해결해야하는 법은 없는것 같다. 모로 가도 서울만 가면 된다라는 속담이 있지 않는가.

제목없는 글? 블로그 RSS파싱 오류? 간헐적으로 오류가 생긴다.

👉 해결방안 : 언제나 신경써야 하는 예외처리(try-catch)

내가 만든 코드는 언제나 내 생각대로만 돌아갔으면 하는건 모든 개발자의 마음과 같다.

흔한 IT 종사자들.deploy 출처 : https://9gag.com/gag/a0Yxw4B/operations-team-before-leaving-for-holidays

하지만 그생각도 잠시 언제나 예외는 발생하기 마련. ( 물론 전혀 예외가 발생 안할수도 있으나 만약 발생하지 않았다 할지라도 발생할수 있는 가능성은 염두해둬야 한다. ) 파싱하는 과정에서 제목이 없는글로 온다거나, 가끔 RSS url 응답이 404 또는 503 인 경우가 있었다.

기술블로그 구독서비스 개발 후기 - 1부

Sun, 05 Aug 2018 10:27:21 +0000

이번 포스팅은 약간의 자투리 시간을 활용하여 이것저것 만져보다 만들게 된 Daily DevBlog(기술블로그 구독서비스)에 대해 이야기 하려고 한다. 하나의 글에 관련 내용을 모두 담기에는 양이 많아서 읽는사람도 지루하고, 글을 쓰는 필자 또한 어불성설 할것같아 크게 3개의 시리즈로 나눠서 최대한 자세하고 현장감(?)있게 글을 써보려고 노력했다.

글에 들어가기 앞서 최종 결과는 http://daily-devblog.com 에서 확인할수 있다.

무엇이 나를 움직이게 했는가

얼마전까지 오픈소스는 정말 실력있는 개발자나 유명한 사람들 말고는 금기의 영역(?)이라고 생각했었지만 최근 오픈소스 개발자 이야기 세미나를 다녀온뒤 마음속에 있었던 벽이 사라지는듯 했다. 세미나를 들으면서 ‘나도 무언가를 만들어 볼수는 없을까?’, ‘회사라는 명찰을 떼면 난 어느 수준에서 개발을 하고 있는 것일까?’ 등 여러 생각들이 머리를 멤돌다 개발자를 위한 글쓰기라는 글에서 기술블로그들을 모아놓은 awesome-devblog를 소개하는 글을 보게 되었고 내 머릿속에 정리안되던 그 생각들은 “이 데이터를 활용해서 무언가를 만들어보자!“로 귀결되었다.

다른 이야기 이지만, awesome-devblog 을 보고 당장 내 블로그도 등록해야지 했었는데 이미 등록이 되어 있었다;; 등록해주신 분께 감사하다는 생각이 들기전에 내 블로그가 누군가에게 보여지고 있구나 하며 새삼 놀라움이 더 컸다.

요구사항과 도구 그리고 설계

만들려고 생각해봤던 요구사항은 다음과 같다. 마치 회사에서 개발전 스펙을 정리하듯…

웹페이지를 활용해서 구독하고자 하는 사람들의 이메일을 수집할수 있어야 한다.
매일 전날 작성된 글을 수집하고 조합하여 구독하고자 하는 사람들에게 메일을 보낼수 있어야 한다.

위 두가지만 보면 너무 간단했다. 또한 기존에 사용하지 않았던 기술들을 사용해보면서 최대한 심플하게 개발하는것을 첫 개인 프로젝트의 목표로 하고 싶었다. 하여 생각한 아키텍처는 다음과 같다.

최대한 심플하게 설계해보자.

데이터는 해당 github에 있길래 그냥 가져다 쓰려고 했으나 그래도 데이터를 관리하시는 분께 허락을 받고 사용하는게 상도덕(?)인것 같아 수소문끝에 연락을 해서 허락받는데 성공하였다.

데이터 사용을 허락해주신 천사같으신분…

이 자리를 빌어 데이터를 사용할수 있도록 허락해주신분 께 감사인사를 표합니다.

홈페이지를 만들기 위해서는 이제껏 삼겹살에 소주처럼(응?) Java에 Spring을 사용해 왔었지만 이번엔 좀 다른 방식을 사용하고 싶었다.

물론 삼겹살에 맥주, 치킨에 소주를 먹어도 되긴 하지만…

최근에 Flask라는 python기반 웹 프레임워크를 만져본 경험이 있어서 이렇다할 고민없이 빠른 결정을 할수 있었다. 또한 DB는 mysql 이나 기타 memory DB를 사용할까 했지만 이또한 심플하게 파일을 활용하는 sqlite3 을 사용하고자 하였다.

웹서버_최종_수정_파이널_진짜_확정

Flask를 활용하기 위해서는 당연히 웹서버가 필요했다. 처음엔 awesome-devblog에서도 사용하고 있던 https://www.heroku.com/ 를 이용해서 해보려 했으나 매일 구독자들에게 메일을 보내는 등 스케쥴러 기능같은건 구현하기 힘들었고 인스턴트 어플리케이션을 등록하는 형태라 사용자의 메일을 입력받고 저장하는 로직을 만들기는 어려워 보였다. (필자가 heroku를 너무 수박 겉핥기식으로 봐서 일수도 있다…) 좀더 찾아보니 https://www.pythonanywhere.com/ 라는 제한적이지만 무료 서비스가 있었는데 웹콘솔도 지원하고 상당히 매력있어 보여서 이거다! 하며 개발을 시작을 했으나 (나름 도메인까지 그럴싸하게 만들었지만… http://dailydevblog.pythonanywhere.com/ ) 세상에 공짜는 없다는 말을 실감하며 앞서 말했던 요구사항을 완벽하게 구현할 수 없는 상황이였다.(request 제한, 스케쥴러 등록 개수 제한 등 보다 여러기능을 사용하기 위해서는 돈을 내고 써야…) 마지막 희망으로 언제샀는지 서랍속 깊이 자고있던 라즈베리 파이를 꺼내서 공유기 DDNS설정을 하고 라즈베리안을 설치하며 웹서버를 위한 셋팅을 시도해보았으나 언제나 그렇듯 (시험공부 하기전에 책상 정리하고 괜히 방청소까지 하다가 피곤해서 자버리는듯한 느낌) 배보다 배꼽이 클것같아 이또한 진행하다가 중단하게 된다. 결국 AWS에서 1년동안은 무료로 사용할수 있는 Free Tier 라는걸 발견하고 이참에 나도한번 사용해보자라는 마음을 가지고 과금되지 않게 조심조심 셋팅을 할수 있었다. 물론 뒤에서 이야기 하겠지만 약간의 과금은 필요했다ㅠ (나름 심도깊었던 고민을 한방에 해결해버리는 AWS 짱;; 이래서 AWS~ AWS~ 하는가 싶었다.)

초간단 API서버 만들기 - 2부 (Python + Flask + Nginx)

Sun, 01 Jul 2018 02:00:00 +0000

지난포스팅에 이어 이번엔 Flask와 Nginx를 연동하는 방법을 정리해보고자 한다. Apache로 연동했는데 왜 또 Nginx로 연동하는걸 정리하지(?)하며 의문이 들수 있는데 다른 포스팅을 봐도 Apache + Flask 조합보다 Nginx + Flask 조합이 더 많고 지난 포스팅에서도 알수있었듯이 (Apache VS Nginx) 둘중 어느것이 좋다고 할수도 없고 각 상황에서 연동하는 방법을 알고 있다면 이 또한 나만의 무기가 될것같아 Nginx를 연동하는 방법을 정리해보려 한다.

1부에서 왜 Flask인가, Flask의 장점에 대해 정리를 했으니 이번 포스팅에서는 별도로 작성하진 않는다.

Nginx 설치 ( https://nginx.org/en/ )

역시 소스설치를 한다.

- 다운을 받고
$ https://nginx.org/download/nginx-1.14.0.tar.gz
- 압축을 푼 다음
$ tar -zxvf nginx-1.14.0.tar.gz
- 폴더로 이동해서 
$ cd nginx-1.14.0
- 설치할 디렉토리를 설정하고
$ ./configure --prefix=/~~~/apps/nginx
- make 파일을 만들고
$ make
- 설치를 진행한다.
$ make install

이렇게 하면 일단 Nginx는 설치가 되었다.

uWSGI 설치 ( https://uwsgi-docs.readthedocs.io/ )

앞서 Apache와 연동할때는 별도의 모듈을 Apache에게 등록하는 형태였다면 Nginx는 WSGI프로토콜을 활용하는 WSGI 어플리케이션을 실행하는 어플리케이션 서버를 활용해야 한다.

- 다운을 받고
$ wget https://projects.unbit.it/downloads/uwsgi-latest.tar.gz
- 압축을 풀고
$ tar zxvf uwsgi-latest.tar.gz
- 폴더로 이동하여
$ cd uwsgi-2.0.17
- make 명령어를 호출하면 'uwsgi'이라는 실행파일이 생성된다.
$ make

Nginx 설정

Apache와 비슷하게 uWSGI 관련 설정을 해준다.

server {
 listen 80;
 server_name localhost;

 location / { # ( / ) 경로로 들어올 경우
 include uwsgi_params; # GET/POST 등 기본적으로 필요한 환경변수를 include 해준다.
 uwsgi_pass 127.0.0.1:3031; # 요청을 IP:PORT로 전달한다.
 }
}

별도의 모듈을 사용하지 않기때문에 전달해주는 (proxy느낌) 설정을 해준다.

uWSGI 실행 및 Nginx 재시작

앞서 설치한 uwsgi를 아래처럼 IP:port 를 명시적으로 적어주고 (위에서 전달받은 IP:PORT와 동일하게) Apache 연동시 활용했던 wsgi파일을 이번에도 동일하게 사용하도록 해서 실행한다.

$ ./uwsgi -s 127.0.0.1:3031 --wsgi-file /~~~/python_app/hello_world.wsgi

이렇게 하면 background로 실행되는게 아닌 foreground로 실행되기 때문에 &을 사용한다던지 해서 background로 실행되도록 해준다. 그후 Nginx를 재시작 해주면 원하는 그토록 원했던 Hello World!를 만날수가 있게 된다.

Apache연동과 조금 다른점은 모듈을 사용하지않고 별도의 전달 어플리케이션(?)이 필요하다는점이다. 간단히 Apache처럼 모듈만 넣으면 되는게 아니라서 불편할수도 있을것 같지만 한편으로는 관리할수있는 포인트가 더 늘어난 셈이라 어떤 측면에서는 활용할수 있는 방법이 하나 늘어난것으로 볼수도 있다.

마치며

막상 정리하고 나면 아무것도 아닌데 알기 위해서 몸부림을 쳐가며 책이며 구글링을 하는 과정을 통해 점점 성장을 하는것 같다. (성장통이라고나 할까) 이렇게 단순히 Flask를 할수있다 가 아닌 웹서버를 연동할수있다. 그것도 Apache와 Nginx 두개나. 이것도 언젠간 나만의 무기가 되지 않을까?

초간단 API서버 만들기 - 1부 (Python + Flask + Apache)

Fri, 29 Jun 2018 23:00:00 +0000

Static한 HTML이 아닌 로직이 필요한 API서버를 구성한다고 가정해보자. (이제까지 지식으로)처음 머릿속에 떠오르는건 Java를 사용하고 스프링으로 어플리케이션을 만들고 apache에 tomcat을 연동한 다음 … 이러한 방법으로 API서버를 구성할수 있겠지만 프로토타이핑 또는 테스트 목적으로 만들기 위해서는 설정하는 시간이 은근 많이 소요된다. (물론 Java Config, Spring Boot 등 간소해졌지만…) 얼마전부터 Python에 대한 매력을 뼈저리게 느끼고 있다보니 Python으로 API서버를 구성할순 없을까 알아봤고 (모바일 게임 듀랑고 서버가 python이라고 하기도 하고…) Flask와 Django가 있어서 둘다 써본 결과 필자는 Flask가 맞겠다고 생각해서 정리를 해볼까 한다.

‘장고’라고도 불리는 Django에는 모든것들이 다 들어가 있어서 사용하기 너무 편리하다. (DB, 어드민 등 ) 하지만 Flask는 내가 사용할 것들만 import해서 사용하는 방식이라 어떤 측면에서는 아무것도 없다 할수 있겠으나 커스터마이징에 용이하다고 볼수 있었기에 Flask를 선택하게 되었다. (Django가 Flask보다 안좋다는 말은 아니니 오해는 하지 마시길…)

글쓰기에 앞서 본 포스팅은 2개의 포스팅에 걸쳐 시리즈(?)형식으로 작성할 예정이다. 1부에서는 Flask가 무엇이고 이를 어떻게 사용하며 Apache와 연동하는 방법을 소개하고, 2부에서는 Nginx와 연동하는 방법을 소개한다. 환경은 다음과 같다.

CentOS 7.4
Python 3.6 (기본은 2.7이였으나 추가로 설치)

Flask ( http://flask.pocoo.org/ )

공식 홈페이지에서도 보면 알수 있듯이 너~무 간단하다. 단지 아래 코드 몇줄만 작성하면 우리가 모든 프로그램 초기 작성시 항상 만나는 “Hello World"를 볼수 있다.

#hello_world.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
 return "Hello World!"

위와같이 작성하고 python hello.py로 실행해두고 브라우저에서 http://127.0.0.1:5000 을 요청하면 반가운 Hello World를 만날수 있다. (너무 간단;;) 자세한 문법은 도큐먼트를 참조하면 될듯하고 이 Flask를 잘만 활용한다면 보다 빠르고 간단하게 API서버를 구성할수 있을거라 생각한다.

Hello World를 찍었으면 된거 아닌가 라고 질문할수도 있겠으나 실제 서비스에서 사용하기 위해서는 앞단에 웹서버를 두는게 여러 측면에서 효율적이다. 주로 사용하는 웹서버는 Apache 와 Nginx가 있는데 여기서는 Apache와 연동하는 방법을 정리 해보고자 한다.

Apache 설치 ( http://archive.apache.org/ )

우선 필자는 yum 이나 apt-get처럼 패키지 관리자로 설치하는것을 그렇게 좋아하지 않는다. 이유는 커스터마이징을 할 경우 시스템 어느곳에 설치되어있는지를 한눈에 파악하기 어렵고 윈도우경우 Program Files처럼 내가 추가로 설치하고 관리하는 프로그램들을 한곳에서 관리하고 싶기에 왠만하면 소스를 직접 컴파일하여 설치하곤 한다. 이번 역시 아파치도 소스로 설치하려고 한다. 현재 아파치는 2.4버전이 Stable버전으로 되어있지만 보다 레퍼런스가 많은 2.2버전으로 설치하기 위해 어렵게 아카이빙된 경로를 통해 다운을 받고 설치를 한다.

- 다운을 받고
$ wget http://archive.apache.org/dist/httpd/httpd-2.2.29.tar.gz 
- 압축을 푼 다음
$ tar xvzf httpd-2.2.29.tar.gz
- 해당 폴더로 들어가
$ cd httpd-2.2.29
- 컴파일 후 설치 경로를 정해주고
$ ./configure --prefix=/~~~/apps/apache
- make 파일을 만든다음
$ make
- 설치를 해준다.
$ make install

이렇게 되면 /~~~/apps/apache/ 하위에 필요한 파일들이 설치가 되는데 root계정이 아닌 일반계정으로 실행하기 위해서는 /bin하위에 있는 httpd에 대한 실행/소유권한을 변경해줘야 한다. (아니면 그냥 root권한으로 시작/종료. 왜? Apache는 80port를 사용하는데 일반적으로 리눅스에서는 1024 아래 port를 컨트롤 하기 위해서는 root권한이 있어야 사용이 가능, 그게 아니라면 이처럼 별도의 설정이 필요하다.)

$ sudo chown root:계정명 httpd
$ sudo chmod +s httpd

mod_wsgi 설치 ( https://code.google.com/archive/p/modwsgi/ )

웹 서버 게이트웨이 인터페이스(WSGI, Web Server Gateway Interface)는 웹서버와 웹 애플리케이션의 인터페이스를 위한 파이선 프레임워크다. 라고 정의되어있다. 즉, 웹서버(Apache)와 위에서 만든 Flask 어플리케이션을 연동해주기 위한 프레임워크이다. 이또한 소스로 설치해보자. (위와 같은 이유로~)

- 다운을 받고
$ wget https://github.com/GrahamDumpleton/mod_wsgi/archive/3.5.tar.gz
- 압축을 푼 다음
$ tar -zxvf 3.5.tar.gz
- 폴더에 들어가서
$ cd mod_wsgi-3.5
- 아파치의 빌드툴인 apxs의 경로를 설정해주고
- 필자와 같이 기본 python 버전을 사용하지 않을꺼라면 꼭 python경로를 설정해줘야 한다! (중요)
$ ./configure --with-apxs=/~~~/apps/apache/bin/apxs --with-python=/usr/bin/python3.6
- make 파일을 만들고
$ make
- 설치~
$ make install

이렇게 설치를 하면 자동으로 아파치 하위 /modules 폴더안에 mod_wsgi.so 파일이 생긴다. (필자는 이것도 모르고 mod_wsgi.so파일을 다운 받으려고 구글링을 몇일째 했던 기억이 ㅠ)

Apache냐 Nginx냐, 그것이 알고싶다.

Wed, 27 Jun 2018 17:17:33 +0000

웹서버는 HTTP 프로토콜을 통해 읽힐수 있는 문서를 처리를 하며 일반적으로 웹 어플리케이션의 앞단에 배치되곤 한다. 동적인 리소스는 WAS에게 처리하도록 하고 정적인 리소스를 보다 효율적으로 처리하기 위한 방법일수도 있다. 크게 Apache와 Nginx가 사용되곤 하는데 이 둘의 차이는 무엇일까? 사실 필자는 사내에서 주로 Apache만 사용하다보니 Nginx는 그저 Apache와는 다른 방식의 웹서버다 또는 보다 경량화 되었다 정도로만 알고있었는데 이번기회를 통해 제대로 알고 비교를 해보면서 결국 어떤게 좋은지 알아보고자 한다.

구글링을 조금만 해보면 Apache와 Nginx를 비교하는 포스팅이 많이 나온다. 이번 포스팅의 목적 이러한 정보들을 단순히 요약/종합 하려는게 아니고, 최대한 실무 서비스를 운영하는 시각으로 정리하고자 함을 밝힌다.

Apache ( https://httpd.apache.org/ )

우리나라에서 웹어플리케이션을 개발하는 사람들은 한번쯤은 들어봤을 Apache. 국내 일반적인 기업에서 웹서버의 표준으로 자리잡았다고 해도 과언이 아닐것 같다. Client에서 요청을 받으면 MPM (Multi Processing Module : 다중처리모듈) 이라는 방식으로 처리를 하는데 대표적으로는 Prefork와 Worker방식이 있다. 간단하게 어떤식으로 처리하는지 알고 넘어가자.

Prefork MPM

Prefork MPM, http://old.zope.org/Members/ike/Apache2/osx/configure_html

실행중인 프로세스를 복제되어 처리가 된다. 각 프로세스는 한번에 한 연결만 처리하고 요청량이 많아질수록 프로세스는 증가하지만 복제시 메모리영역까지 복제되어 동작하므로 프로세스간 메모리 공유가 없어 안정적이라 볼수 있다.

Worker MPM

Worker MPM, http://old.zope.org/Members/ike/Apache2/osx/configure_html

Prefork 동작방식이 1개의 프로세스가 1개의 스레드로 처리가 되었다면 Worker 동작방식은 1개의 프로세스가 각각 여러 쓰레드를 사용하게 된다. 쓰레드간의 메모리를 공유하며 PreFork방식보다 메모리를 덜 사용하는 장점이 있다.

참고로 WAS로 tomcat을 연동하는 경우라면 mod_jk, mod_proxy, mod_proxy_ajp 방식을 Apache 자체적으로 지원해주기 때문에 다양하고 효율적으로 tomcat을 연동할수 있다. 참고링크

Nginx ( https://nginx.org/en/ )

Nginx에 대해 살펴보기 전에 구글 트랜드를 활용하여 Nginx에 대한 관심이 어느정도인지를 보고 넘어가자.

최근 5년간 구글트랜드, 파란색이 Apache이고 빨간색이 Nginx

전세계는 Nginx보다는 Apache에 대한 관심이 많은것으로 보이는데 국내는 아주 조금씩 Nginx에 대한 관심이 오르는것을 볼수있었다. (그래도 아직은 Apache가 월등히 우세한 편이다.) 그럼 Nginx는 어떤식으로 돌아가는 것일까? 가장 유명한(?) 특징이라면 Event Driven 방식을 꼽을수 있을것 같다. Event Driven 방식에 대해 잠깐 언급을 하고 넘어가면 요청이 들어오면 어떤 동작을 해야하는지만 알려주고 다른요청을 처리하는 방식이다. (Producer Consumer Pattern과 유사하다.) 그러다보니 프로세스를 fork하거나 쓰레드를 사용하는 아파치와는 달리 CPU와 관계없이 모든 IO들을 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행이 되어 1개의 프로세스로 더 빠른 작업이 가능하게 될수 있다. 이때문에 메모리적인 측면에서 Nginx가 System Resource를 적게 처리한다는 장점이 있다고 한다.

Nginx Process Model (https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale)

그래서 뭐가 좋은가?

이 포스팅을 적으면서 마지막엔 Apache가 더좋다 또는 Nginx가 더좋다로 마무리를 짓고 싶었는데 어느 시사/교양 프로그램처럼 어쩔수 없는 열린결말로 마무리를 지을수밖에 없을것 같다. (어찌보면 이게 정답일수도?)

기술의 선택에 있어서 정답은 없는것 같다.(물론 Spring 을 사용하느냐 서블릿을 직접 구현하는냐 와는 좀 다른 성격의 이야기;;) 운영하고 있는 서비스의 상황을 잘 알고 튜닝을 해가면서 가장 효율적인것을 선택하는게 정답이라고 말할수 밖에… 커뮤니티 파워를 무시 못하기 때문에 Apache를 선택할수도 있을테고, 점점 관심도가 올라간다는건 그만큼의 장점이 있고 또한 메모리 측면에서 동접자 처리시 효율적인 Nginx를 사용할수 있을것 같다.

시계열 데이터를 분석하여 미래 예측 하기(Anomaly Detection)

Thu, 31 May 2018 17:03:41 +0000

급변하는 날씨를 예측하려면 어떠한 정보가 있어야 할까? 또는 마트를 운영하는 담당자인 경우 매장 운영시간을 정해야 한다면 어떠한 기준으로? 뜨거운 감자인 비트코인 시장에서 수익을 얻으려면 어떤 정보들이 있어야 물리지(?) 않을수 있을까?

위 질문에 공통된 정답은 예전 기록들인것 같다. 날씨예측은 기상청에서 과거 기록들을 보고 비가 올지 말지를 결정하고 ( 과거 날씨 서비스를 담당해봤지만 단순히 과거 기록들로 예측한다는건 불가능에 가깝긴 하다. ) 매장 운영시간은 예전에 손님들이 언제왔는지에 대한 데이터를 보고. 비트코인이나 주식은 차트를 보고 어느정도는 상승장일지 하락장일지 추측이 가능하다고 한다. ( 물론 호재/악재에 따라 흔들리지만..ㅠㅠ..?? ) 이처럼 시간의 흐름에 따라 만들어진 데이터를 분석하는것을 시계열 데이터 분석이라 부르고 있다. 필자가 운영하는 서비스에서 시계열 데이터 분석을 통해 장애를 사전에 방지하는 사례를 공유 해보고자 한다.

상황파악부터

손자병법에는 지피지기 백전불태 라는 말이 있다. 그만큼 현 상황을 잘 알아야 대응을 잘할수 있다는것. 필자가 운영하는 서비스는 PG(Payment Gateway) 서비스로 쇼핑몰같은 온/오프라인 사업자와 실제 카드사와의 중간 역활을 해주고 있다. 이를테면 사용자가 생수를 10,000원에 XX카드로 구매해줘 라고 요청이 오면 그 정보를 다시 형식에 맞춰 카드사로 전달하여 사용자가 물건을 구매할수 있도록 해준다.

PG서비스 : 쇼핑몰과 카드사의 중간에서 릴레이 해주는 역활이라 보면된다.

요구사항 및 과거 데이터 분석

서비스를 운영해보니 감지하기 어려운 상황들이 있었다.

연동하는 쇼핑몰에서 문제가 발생하거나 네트워크 문제가 발생할경우 즉, 트래픽이 평소보다 적게 들어올 경우
정상적인 에러(e.g. 잔액부족) 가 갑자기 많이 발생할 경우

이를 분석하기위해 기존의 트래픽/데이터를 분석해봐야 했다.

결제건수 Kibana Visualize, 기영이 패턴

위 그래프는 결제데이터 카운트 인데 어느정도 패턴을 찾을수 있다.

에러건수 Kibana Visualize, 악어 패턴..(무리수..)

위 그래프는 에러카운트 인데 일정한 패턴 속에서 어느 지점에서는 튀는것을 확인할수 있다. (빨간색 영역) 그렇다면 어떤 방법으로 장애상황보다 앞서서 감지를 할수 있을까? ( 장애 : 어떠한 내/외부 요인으로 인해 정상적인 서비스가 되지 않는 상태 )

장애발생 전에 먼저 찾아보자!

가장 간단하게는 기존 데이터를 보고 수동으로 설정하는 방법이 있을수 있다. 예로들어 자정 즈음에는 결제량이 가장 많기때문에 약 xx건으로 설정해두고, 새벽에는 결제량이 가장 적기 때문에 약 yy건으로 설정해둔 후 에러 건수나 결제건수에 대해 실시간으로 검사를 해가면서 설정한 값보다 벗어날 경우 알림을 주는 방법이다. 하지만 아무리 과거 데이터를 완벽하게 분석했다 할지라도 24시간 모든 시점에서 예측은 벗어날 수밖에 없다. (예로들어 쇼핑 이벤트를 갑작스럽게 하게되면 결제량은 예측하지 못할정도로 늘어날테고…) 또한 설정한 예측값을 벗어날 경우 수동으로 다시 예측값을 조정해줘야 하는데, 이럴꺼면 24시간 종합 상황실에서 사람이 직접 눈으로 보는것 보다 못할것 같다. (인력 리소스가 충분하다면 뭐… 그렇게 해도 된다.)

지난 데이터와 비교하기

일주일 기준으로 지난 일주일과의 데이터를 비교해보는 방법또한 있다. 간단하게 설명하면 이번주 월요일 10시의 데이터와 지난주 월요일 10시의 데이터의 차이를 비교해보는 방법이다. 키바나에서 클릭 몇번만으로 시각화를 도와주는 Visualize 기능을 통해 지난 일주일과 이번주를 비교해보면 아래 그래프처럼 표현이 가능하다.

일주일 전 데이터와 단순 비교

이 경우도 지난주 상황과 이번주 상황이 다른 경우에는 원하는 비교 항목 외에 다른 요인이 추가되기 때문에 원하는 비교를 할수가 없고 위에서 수동으로 설정하는 방법과 별반 다를바 없을것으로 생각된다.

조금더 우아하게! `(언제부턴가 우아하단 말을 좋아하는것 같다..)`

개발자는 문제에 대해서 언제나 분석을 토대로 접근을 하는것을 목표로 해야한다. 언제부턴가 Hot한 머신러닝을 도입해 보고 싶었으나 아직 그런 실력이 되질 못하고… 폭풍 구글링을 통해 알게된 Facebook에서 만든 Prophet이라는 모듈을 활용해보고자 한다. https://opensource.fb.com/#artificial 이곳에 가보면 여러 Artificial Intelligence 관련된 오픈소스들중에 Prophet 모듈을 찾을수 있다. 다행히도 BSD License라서 실무에서도 다양하게 활용할수 있을것으로 보인다. 친절하게도 Quick Start을 통해 어떤식으로 예측을 하는지 보여준다. 참고로 Python 과 R 을 지원한다. (python 의 대단함을 다시금 느끼며…) 구성은 CentOS 7 + python3.6 + jenkins 를 활용한다. (python 경험이 부족하므로 코드가 허접할수도 있으니 양해바란다.) 데이터 분석시 가장 많이 사용된다는 Pandas와 대규모 다차원 배열을 쉽게 처리 할 수 있게 해주는 numpy, 그리고 bprophet를 비롯한 필요한 모듈들을 pip로 설치해준다.

아파치 엑세스 로그에 408코드가?

Sun, 29 Apr 2018 17:39:36 +0000

예전에 아파치 로그를 엘라스틱 스택을 활용하여 내 서버에 누가 들어오는지를 확인할수 있도록 구성을 해두고 몇일간 지켜보니 다음과 같은 엑세스 로그가 발생하고 있었다.

1.2.3.4 - - [26/Apr/2018:01:27:33 +0900] "GET /aaa/ HTTP/1.1" 200 6001 30788 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 28 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 12 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:50 +0900] "GET /aaa/ HTTP/1.1" 200 5999 13521 "http://www.naver.com/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:14 +0900] "GET /aaa/ HTTP/1.1" 200 5996 19437 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:15 +0900] "GET /aaa/ HTTP/1.1" 200 5997 17553 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:15 +0900] "GET /aaa/ HTTP/1.1" 200 5998 17429 "http://www.naver.com/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 32 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 38 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 29 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:30:54 +0900] "GET /aaa/ HTTP/1.1" 200 6000 17881 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 25 "-" "-"

한시간에 만건이상 응답코드는 408, referrer도 없고, useragent도 없는, ip들도 매우 다양한 이상한 녀석들이 요청되고 있었다.

이렇게 엑세스 로그를 분석할수 있는 구성을 해두고 나니 보였지 안그랬음 그냥 지나갔을 터..

이러한 데이터를 키바나에서 보면 아래처럼 볼수있는데 한눈에 봐도 과연 의미있는 요청들일까? 하는 의구심이 들정도이다. (1시간 아파치 엑세스 로그)

주황색이 408응답

그럼 이런 호출들은 도대체 뭘까? 천천히 생각좀 해보자.

정상적이지 않는 호출로 우리 서버의 취약점을 파악하려 하는것들일까?
응답코드 408은 요청시간초과 응답코드인데… 오히려 클라이언트 입장에서 문제가 있는건 아닐까?
어플리케이션 로직이 잘못되어 무한루프에 빠졌나;

위키백과에서는 아파치 응답코드 중 408에 대한 응답을 다음과 같이 알려주고 있다.

The server timed out waiting for the request. According to HTTP specifications: “The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time

즉, 아파치 단에서 타임아웃을 내버리는 상황. 여러 다양한 키워드들로 구글링을 해봐도 이렇다할 검색결과를 찾지 못하고 네트워크 관련상황인지 싶어 크롬 개발자도구를 열어 네트워크 지연 테스트를 해보았으나 별 효과가 없었다. 그렇게 범인찾는 형사의 심정으로 이것저것 알아보다 우연히 집에서 원격으로 회사 VPN 붙어서 테스트 하던도중 관련 증상을 재현 할수 있게 되었다.

# 재현상황

우선 아파치버전은 2.2이고 KeepAlive Off가 되어있는 상황. 아래그림처럼 집PC - 공유기 - VPN - Apache - tomcat jenkins 상황이였는데 젠킨스에 한번 접속후에는 항상 408 응답이 주루룩(?) 발생하는것을 알수 있었다. (사실 맨위에 엑세스 로그가 재현한 엑세스 로그이다.)

내 서버에는 누가 들어오는걸까? (실시간 user-agent 분석기)

Tue, 10 Apr 2018 23:20:19 +0000

Desktop 및 스마트폰의 대중화로 다양한 OS와 브라우저들을 사용하게 되었다. 이때, 내가 운영하는 웹서버에 들어오는 사람들은 무슨 기기로 접속을 하는 것일까? 혹여 특정 OS의 특정 브라우저에서만 안되는 버그를 잡기 위해 몇일밤을 고생하며 겨우 수정했는데… 과연 그 OS의 브라우저에서는 접속은 하기나 하는걸까? (ㅠㅠ) 만약, 접속 사용자의 Device 정보를 알고있다면 고생하며 버그를 잡기 전에 먼저 해당 Device 사용율을 체크해 볼수도 있고(수정이 아닌 간단한 얼럿으로 해결한다거나?) 비지니스 모델까지 생각해야하는 서비스라면 타겟팅을 정하는 등 다양한 활용도가 높은 것이 바로 User-Agent라고 한다(이하 UA). 일반 Apache 를 웹서버로 운영하고 있다고 가정을 하고 어떻게 분석을 할수 있었는지, 그리고 분석을 하며 좀더 우아한(?) 방법은 없는지 알아 보고자 한다.

User-Agent가 뭐야?

백문이 불여일타(?)라 했던가, 우선 http://www.useragentstring.com 를 들어가보자. 그러면 자신의 OS 및 브라우저 등 정보를 파싱해서 보여주는데 위키백과에 따르면 ‘사용자를 대신하여 일을 수행하는 소프트웨어 에이전트’라고 한다. 즉, UA만 알아도 어떤 기기/브라우저를 사용하는지 알 수 있다는것. mozilla에 가보면 스팩 등 다양한 UA를 볼수가 있는데 특히 맨 아래보면 기기/브라우저별로 지원정보가 나와있다. 여기서도 보면 모든 모바일 삼성 브라우저를 제외하고는 전부 지원이 되는걸 확인할수 있다.

출처 : developer.mozilla.org

기존의 방법

그럼 어떻게 내 서버에 들어온 사용자들의 UA를 확인할 수 있을까? (앞서 Apache를 웹서버로 운영한다고 했으니) Apache access log 에는 Apache에서 제공해주는 모듈을 이용해 접속한 클라이언트의 정보가 남겨지곤 한다. 그렇다면 이 access log를 리눅스 명령어든 엑셀로 뽑아서든지 활용해서 정규식으로 포맷팅 하고 그 결과를 다시 그룹화 시키면 얼추 원하는 데이터를 추출해 낼수 있다. ( 버거형들이 만들어둔 정규식을 가져다 사용할수도 있겠다. https://regexr.com/?37l4e ) 하지만, 우선 자동화가 안되어있어 데이터를 구하고 싶을때마다 귀차니즘에 걸릴수 있고 슈퍼 개발자 파워를 기반으로(?) 데이터 추출을 자동화 한들 실시간으로 보고싶을땐 제한사항이 많다.

좀더 나은 방법(?)

실시간 데이터를 모니터링 하는데에는 다양한 오픈소스와 다양한 툴이 있겠지만 경험이 부족한건지 아직까진 ElasticStack 만한걸 못본것 같다. 간단하게 설명을 하면 access log 를 사용하지 않고 front단에서 javascript 로 UA를 구한다음 이러한 정보를 받을수 있는 API를 만들어 그쪽으로 보내면 서버에서 해당 UA를 분석해서 카프카로 보내고 ..!@#$%^blabla… ^^; 그림으로 보자.

좀더 나은 방법

front단에서는 navigator.userAgent를 활용하여 UA를 구할수 있었고, API에서는 UA를 받고 파싱을 하는데 관련 코드는 다음과 같이 작성하였다.

private static final String VERSION_SEPARATOR = ".";

private void userAgentParsingToMap(String userAgent, Map<String, Object> dataMap) {
 HashMap browser = Browser.lookup(userAgent);
 HashMap os = OS.lookup(userAgent);
 HashMap device = Device.lookup(userAgent);

 dataMap.put("browserName", browser.get("family"));
 dataMap.put("browserVersion", getVersion(browser));
 dataMap.put("osName", os.get("family"));
 dataMap.put("osVersion", getVersion(os));
 dataMap.put("deviceModel", device.get("model"));
 dataMap.put("deviceBrand", device.get("brand"));

}

private String getVersion(HashMap dataMap) {
 String majorVersion = (String)dataMap.get("major");
 if (StringUtils.isEmpty(majorVersion)) {
 return StringUtils.EMPTY;
 }
 String minorVersion = (String)dataMap.get("minor");
 String pathVersion = (String)dataMap.get("path");

 StringBuffer sb = new StringBuffer();
 sb.append(majorVersion);
 if (!StringUtils.isEmpty(minorVersion)) {
 sb.append(VERSION_SEPARATOR);
 sb.append(minorVersion);
 }
 if (!StringUtils.isEmpty(pathVersion)) {
 sb.append(VERSION_SEPARATOR);
 sb.append(pathVersion);
 }

 return sb.toString();
}

참고로 Java단에서 UA를 파싱하는 parser가 여러가지가 있는데 그중 uap_clj라는 모듈이 그나마 잘 파싱이 되어서 사용하게 되었다.

모듈별 비교

모듈	Browser	OS	Device
eu.bitwalker.useragentutils.UserAgent	O	불명확함 (Android 5.x)	X
net.sf.uadetector.UserAgentStringParser	O	O	불명확함 (Smartphone)
uap_clj.java.api.*	O	O	O

Parsing 비교
- UA

"Mozilla/5.0 (Linux; Android 5.1.1; Nexus 6 Build/LYZ28E) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36"

결과

 - Browser : {patch=3239, family=Chrome Mobile, major=63, minor=0}
 - OS : {patch=1, patch_minor=, family=Android, major=5, minor=1}
 - Device : {model=Nexus 6, family=Nexus 6, brand=Generic_Android}

위와 같이 구성을 하면 Elasticsearch에 인덱싱된 데이터를 Kibana에서 입맛에 맞게 실시간으로 볼수있게 되었다! 하지만 API를 만드는 부분 + front에서 별도의 javascript가 들어간다는 부분 + 운영하는 모든 페이지에 해당 javascript를 넣어야지만 볼수있는 부분 등 약간 아쉬운 감이 있다. 뭔가 더 좋은 방법이 없을까? 깔끔하면서도 우아한 방법. 짱구를 열심히 더 굴려보자.

gzip 설정으로 속도를 더 빠르게!

Sun, 01 Apr 2018 17:58:11 +0000

내가 운영중인 웹서비스의 응답속도를 보다 더 빠르게 하기 위해서는 어떤 방법이 있을까? 웹 서비스를 위해 서버를 구성할 경우 일반적으로 앞단에 웹서버를 두고 그뒤에 WAS를 두는 설계를 하곤 한다. 여기서 웹서버는 대표적으로 Apache나 Nginx가 있고 WAS는 tomcat이나 기타 다른 모듈을 사용하는데 이렇게 두단계로 나누는 이유는 여러가지가 있겠지만 여기서는 앞단의 웹서버(Apache)의 설정으로 응답속도를 줄일수 있는 방법을 알아 보고자 한다.

웹페이지의 응답속도를 줄일수 있는 ‘일반적인’방법들

꼭 서버의 설정들을 건드리지 않고도 웹페이지의 응답속도를 줄일수 있는 방법은 다양하다. 가장 간단하게 코드 레벨에서 설정할수 있는 방법으로는 스타일시트를 위에 선언하거나 java script는 코드 아래부분에 넣는것만으로도 어느정도 응답속도를 줄일수 있다고 한다.

(사족) 신입시절 회사 대표님이 필수로 읽어보라고 전 직원들에게 선물해주셨던 웹사이트 최적화기법 (스티브 사우더스 저)이 생각이 난다. ~~모두 사주려면 돈이 얼마야…~~ 그만큼 웹개발자들에게 중요하면서도 한편으로는 기본이 되는 부분들이니 한번쯤 목차라도 읽어보는게 좋을듯 하다.

사실 이 포스팅을 작성하게된 가장 큰 계기는 얼마전 사내 해커톤을 하면서 경험한 부분 때문이다. ( + 들어만 봤지 실제로 해보지는 않아서… ) 서버에서 node(React)를 띄우고 그 앞단에 Apache로 단순 Port Redirect ( 80 → 3000 ) 시켜주고 있었는데 react 에서 사용하는 bundle.js의 용량이 크다보니 최초 페이지 접근시 로딩시간이 5초 이상되어버린 것이다. bundle.js를 줄여보는등 다양한 방법을 사용했다가 결국 Apache 설정을 통해 1초 이내로 줄일수 있었다.

gzip

우선 gzip이란 파일 압축에 쓰이는 응용 소프트웨어로 GNU zip의 준말이라고 한다. (참고 : 위키백과 Gzip) 이를 사용하기 위해서는 브라우저가 지원을 해야하는데 https://caniuse.com/#search=gzip 을 보면 대부분의 브라우저에서 지원하는것을 볼수 있다.

데이터 흐름

그럼 gzip 을 사용했을때와 사용하지 않았을때의 차이는 어떻게 다를까? 우선 Request/Response Flow 를 잠깐 살펴보면 다음과 같다.

gzip 사용 전

출처 : betterexplained.com

브라우저가 서버측에 /index.html을 요청한다.
서버는 Request를 해석한다.
Response에 요청한 내용을 담아 보낸다.
Response를 기다렸다가 브라우저에 보여준다. (100kb)

gzip 사용 후

출처 : betterexplained.com

브라우저가 서버측에 /index.html을 요청한다.
서버는 Request를 해석한다.
Response에 요청한 내용을 담아 보낸다. 여기서 해당 내용을 압축하는 과정이 추가가 된다.
Response header에 압축이 되어있다는 정보를 확인후 브라우저는 해당 내용을 받고(10kb), 압축을 해제한 후 사용자에게 보여준다.

정리하면, gzip을 사용하면 서버는 Client에게 보낼 Response를 압축하기 때문에 네트워크 비용을 줄일수 있어 응답속도가 빠른 장점이 있다.

무조건 사용해야 하는가?

물론 무조건 좋은 (마치 show me the money 같은)정답은 없다. 서버에서 압축을 하여 Client에게 보내면 그대로 사용자에게 보여주는것이 아니라 압축을 해제하는 과정이 추가적으로 필요하다. 이러한 과정에서 브라우저는 cpu를 사용하게 되어 오히려 랜더링 하는 과정이 느려질수 있어 자칫 응답속도는 빨라졌다 하더라도 사용자 체감상 더 느려진것처럼 보여질수 있다. 따라서 상황에 맞춰 gzip을 사용해야 할것인지 말것인지에 대해 테스트가 필요하다.

마치며

학부시절 또는 신입시절, 아파치는 정적인 리소스를 담당하고 톰켓은 서블릿 처럼 데이터 가공이 필요한 페이지를 담당한다고 주문을 외우듯 하였지만, 웹서버에서 압축을 하면 어떤 효과가 있는지 실제로 경험해보는게 가장 중요한것 같다. 적용 방법은 복붙하는 느낌이라 아파치 공식 문서를 링크 하는것으로 해당 포스팅을 마무리 하겠다.

Apache Document (사용법) : https://httpd.apache.org/docs/2.2/ko/mod/mod_deflate.html
적용 테스트 사이트
- https://developers.google.com/speed/pagespeed/insights
- http://www.whatsmyip.org/http-compression-test

RestClientException 처리

Sat, 17 Mar 2018 19:19:39 +0000

Spring 환경에서 (Spring5는 달라졌지만…) 외부 API로의 호출을 할때 자주 쓰이는 RestTemplate. 이때 request에 대해 정상적인 응답이 아닌 경우에 대한 처리는 어떻게 할까? 막연하게 생각을 해보면 Http Status Code를 받아서 판별을 하면 되지만 Http Status Code만 봐도 엄청~~많다. ( 위키피디아 참고 : https://en.wikipedia.org/wiki/List_of_HTTP_status_codes ) if~~else 로 다 나눌수도 없고… 우선 성공/실패에 대한 판별은 어떻게 할까 하고 코드를 파고파고 들어가다가 알게된 부분에 대해 정리를 해보겠다.

Http Status Code 그룹정의

Spring-project github에 가보면 HttpStatus 하위에 내부 Enum으로 아래처럼 정의되어 있다. ( 링크 )

public enum HttpStatus {
	
	...

	public Series series() {
		return Series.valueOf(this);
	}

	...

	public enum Series {

		INFORMATIONAL(1),
		SUCCESSFUL(2),
		REDIRECTION(3),
		CLIENT_ERROR(4),
		SERVER_ERROR(5);

		...

		public static Series valueOf(int status) {
			int seriesCode = status / 100;
			for (Series series : values()) {
				if (series.value == seriesCode) {
					return series;
				}
			}
			throw new IllegalArgumentException("No matching constant for [" + status + "]");
		}
	}
}

약 80여개 응답코드들을 크게 5개 묶음으로 정의해 놓은것을 볼수있다. 즉, 201 / 201 / 202 같은 녀석들은 전부 SUCCESSFUL 성공 으로 그룹핑이 되는것을 확인할수 있다.

그럼 RestTemplate 에서는 어떻게 처리하고 있나?

코드를 쭉쭉 따라가다 보면 아래처럼 4xx, 5xx 는 에러라고 판단하고 그에 따라 RestClientException 을 반환하는것을 확인할수 있다.

RestTemplate 호출 링크

try {
	ClientHttpRequest request = createRequest(url, method);
	if (requestCallback != null) {
		requestCallback.doWithRequest(request);
	}
	response = request.execute();
	handleResponse(url, method, response);
	if (responseExtractor != null) {
		return responseExtractor.extractData(response);
	}
	else {
		return null;
	}
}
catch (IOException ex) {

에러 판별 링크

protected boolean hasError(HttpStatus statusCode) {
	return (statusCode.series() == HttpStatus.Series.CLIENT_ERROR || statusCode.series() == HttpStatus.Series.SERVER_ERROR);
}

성공/실패 처리는 어떻게 할것인가

각자 정의하기 나름일것 같다. 우선 아주 간단하게 RestTemplate 를 사용할때 예외처리를 하여 정의된 대로 4xx, 5xx가 에러라고 판단할 수 있을것 같고

try {
 responseBody = restTemplate.postForObject(url, httpEntity, byte[].class);
} catch (RestClientException e) { // 에러인 경우 RestClientException 을 내뱉는다.
 log.error("##### restTemplate error, url = {}", url, e);
}

정의된 에러(?)와는 조금 다르게 처리하고 싶다면 DefaultResponseErrorHandler을 상속받고 hasError메소드를 무조건 패스하도록 Override 하고난 다음 응답 코드를 받아서 처리하는 방법이 있을수 있겠다. (물론 이러한 방법 말고 다양한 방법이 있을것 같다.)

소나큐브 이용 코드 정적분석 자동화

Thu, 08 Feb 2018 20:10:54 +0000

코드 정적분석이라 함은 실제 프로그램을 실행하지 않고 코드만의 형태에 대한 분석을 말한다. 이를테면 냄새나는 코드(?)라던지, 위험성이 있는 코드, 미리 정의된 규칙이나 코딩 표준을 준수하는지에 대한 분석을 말하는데 java 기준으로는 아래 다양한 (잘 알려진) 정적분석 도구들이 있다.

PMD
- 미사용 변수, 비어있는 코드 블락, 불필요한 오브젝트 생성과 같은 Defect을 유발할 수 있는 코드를 검사
- https://pmd.github.io
FindBugs
- 정해진 규칙에 의해 잠재적인 에러 타입을 찾아줌
- http://findbugs.sourceforge.net
CheckStyle
- 정해진 코딩 룰을 잘 따르고 있는지에 대한 분석
- http://checkstyle.sourceforge.net

이외에 SonarQube 라는 툴이 있는데 개인적으로 위 알려진 다른 툴들의 종합판(?)이라고 생각이 들었고, 그중 가장 인상깊었던 기능이 github과 연동이 되고 적절한 구성을 하게 되면 코드를 수정하는과 동시에 자동으로 분석을 하고 리포팅까지 해준다는 부분이였다. ( ~~더 좋은 방법이 있는지는 모르겠으나~~ 다른 도구들은 수동으로 돌려줘야 하고 리포팅 또한 Active하지 못한(?) 아쉬운 점이 있었다. )

지금부터 Jenkins + github web-hook + SonarQube 를 구성하여 코드를 수정하고 PullRequest를 올리게 되면 수정한 파일에 대해 자동으로 정적분석이 이뤄지고, 그에대한 리포팅이 해당 PullRequest에 댓글로 달리도록 설정을 해보겠다. (코드리뷰를 봇(?)이 자동으로 해주는게 얼마나 편한 일인가…)

기본 컨셉

전체적인 컨셉은 다음 그림과 같다.

전체 컨셉

IDE에서 코드수정을 하고 remote 저장소에 commit & push를 한다. 그 다음 github에서 master(혹은 stable한 branch)에 대해 작업 branch를 PullRequest 올린다.
미리 등록한 github의 web-hook에 의해 PullRequest 정보들을 jenkins에 전송한다.
전달받은 정보를 재 가공하여 SonarQube로 정적분석을 요청한다.
SonarQube에서 분석한 정보를 다시 jenkins로 return 해준다.
SonarQube으로부터 return 받은 정보를 해당 PullRequest의 댓글에 리포팅을 해준다.

간단히 보면 (뭐 간단하니 쉽네~) 라고 볼수도 있겠지만 나는 이런 전체 흐름을 설정하는데 있어 어려웠다.

사실 셋팅하는 과정에서 적지않은 삽질을 했었기에, 이 포스팅을 적는 이유일수도 있겠다. 더불어 검색을 해봐도 이렇게 전체흐름이 정리된 글이 잘 안보여서 + 내가 한 삽질을 다른 누군가도 할것같아서(?)

Maven 설치

기본적으로 Maven의 H2DB를 사용하므로 SonarQube를 설치하기전에 Maven부터 설치해줘야 한다.

$ wget http://apache.mirror.cdnetworks.com/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz
$ tar -zxvf apache-maven-3.5.2-bin.tar.gz
(환경변수 셋팅후 )
$ mvn -version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T16:58:13+09:00)
...

SonarQube 설치

정적분석을 도와주는 SonarQube를 설치해보자.

$ wget https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-6.7.1.zip
$ unzip sonarqube-6.7.1.zip
$ cd sonarqube-6.7.1/bin/linux-x86-64
$ ./sonar.sh start
Starting SonarQube...
Started SonarQube.

기본적으로 9000포트를 사용하고 있으니 다른포트를 사용하고자 한다면 /sonarqube-6.7.1/conf/sonar.properties 내 sonar.web.port=9000 을 수정해주면 된다. (SonarQube도 Elasticsearch를 사용하구나…) 설치후 실행을 한뒤 서버IP:9000을 접속해보면 아래 화면처럼 나온다. (혹시 접속이 안된다거나 서버가 실행이 안된다면 ./sonar.sh console로 로그를 보면 문제해결에 도움이 될수도 있다. )

SonarQube 메인화면

SonarQube Scanner 설치

소스를 연동시켜 정적분석을 하기 위해서는 SonarQube Scanner 라는게 필요하다고 한다. 아래 url에서 다운받아 적절한 곳에 압축을 풀어두자. https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

$ wget https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.0.3.778-linux.zip
$ unzip sonar-scanner-cli-3.0.3.778-linux.zip

# jenkins 설치 및 SonarQube 연동

jenkins 설치는 간단하니 별도 언급은 안하고 넘어가…려고 했으나, 하나부터 열까지 정리한다는 마음으로~ https://jenkins.io/download/ 에서 최신버전을 tomcat/webapps/ 아래에 다운받고 server.xml 을 적절하게 수정해준다.

$ wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war
$ vi tomcat/conf/server.xml
<Connector port="19001" protocol="HTTP/1.1" # 포트 변경
<Context path="/jenkins" debug="0" privileged="true" docBase="jenkins.war" /> #추가
# tomcat/bin/startup.sh

jenkins 설치를 완료 한 후 필요한 플러그인을 추가로 설치해준다.

Python Plugin
GitHub Pull Request Builder
GitHub plugin

접속 : 서버IP:19001 (참고로 한 서버에서 다 설치하다보니 port 충돌을 신경쓰게되었다. ) 처음 jenkins를 실행하면 이런저런 설정을 하는데 특별한 설정 변경없이 next버튼을 연신 눌러면 설치가 완료 되고, SonarQube를 사용하기 위해 SonarQube Scanner for Jenkins라는 플러그인을 설치해주자. (이건 각 버전마다 궁합(?)이 안맞을수도 있으니 확인이 필요할수도 있다. 내가 설치한 버전은 jenkins 2.89, SonarQube Plugin 2.6.1이다.) 설치를 하면 jenkins > configure 에서 SonarQube servers정보를 등록해준다.

Github의 WebHook을 이용하여 자동 Jenkins Job 실행

Thu, 08 Feb 2018 17:10:54 +0000

PullRequest가 발생하면 알림을 받고싶다거나, 내가 관리하는 레파지토리에 댓글이 달릴때마다 또는 이슈가 생성될때마다 정보를 저장하고 싶다거나. 종합해보면 Github에서 이벤트가 발생할때 어떤 동작을 해야 할 경우 Github에서 제공하는 Webhook 을 사용하여 목적을 달성할 수 있다. 아 당연한 이야기이지만 언급하고 넘어갈께 있다면, Github에서 Jenkins Job을 호출하기 위해서는 Jenkins가 외부에 공개되어 있어야 한다. (내부사설망이나 private 한 설정이 되어있다면 호출이 안되어 Webhook기능을 사용할 수 없다.)

Jenkins Security 설정

Jenkins Job을 외부에서 URL로 실행을 하기 위해서는 아래 설정이 꼭 필요하다. (이 설정을 몰라서 수많은 삽질을 했다.) CSRF Protection 설정 체크를 풀어줘야 한다. 이렇게 되면 외부에서 Job에 대한 트리거링이 가능해 진다.

Jenkins > Configure Global Security

Jenkins Job 설정

Github 에서 Webhook에 의해 Jenkins Job을 실행하게 될텐데, 그때 정보들이 payload라는 파라미터와 함께 POST 형식으로 호출이 되기 때문에 미리 Job에서 받는 준비(?)를 해둬야 한다. 설정은 간단하게 다음과 같이 Job 파라미터 설정을 해주면 된다.

Jenkins > 해당 Job > configure

Github Webhook 설정

이제 Github Repository 의 Hook 설정만 하면 끝이난다. 해당 Repository > Settings > Hooks 설정에 들어가서 Add webhook을 선택하여 Webhook을 등록해준다. URL은 {jenkins URL}/jenkins/job/{job name}/buildWithParameters식으로 설정해주고 Content Type 은 application/x-www-form-urlencoded으로 선택한다. 언제 Webhook을 트리거링 시킬꺼냐는 옵션에서는 원하는 설정에 맞추면 되겠지만 나는 pullRequest가 등록 될때만 미리 만들어 놓은 Jenkins Job을 실행시킬 계획이였으니 Let me select individual events.을 설정하고 Pull Request에 체크를 해준다. 아래 그림처럼 말이다.

해당 Repositroy > Settings > Hooks

이렇게 등록하고 다시 들어가서 맨 아랫 부분Recent Deliveries을 보면 ping test 가 이루어져 정상적으로 응답을 받은것을 확인할수가 있다.

Webhook 등록 결과

이렇게 설정을 다 한 뒤 PullRequest를 발생시키면 Jenkins 해당 Job에서는 파라미터를 받으며 실행이 된것을 확인할수가 있다.

Jenkins Job 실행 결과

끝~

Github과 Jenkins 연동하기

Thu, 08 Feb 2018 17:10:21 +0000

Jenkins에서 Github의 소스를 가져와서 빌드를 하는 등 Github과 Jenkins와 연동을 시켜줘야하는 상황에서, 별도의 선행 작업이 필요하다. 다른 여러 방법이 있을수 있는데 여기서는 SSH로 연동하는 방법을 알아보고자 한다.

우선 Jenkins가 설치되어있는 서버에서 인증키를 생성하자.

$ ssh-keygen -t rsa -f id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
SHA256:~~~~~ ~~~@~~~~~
The key's randomart image is:
+---[RSA 2048]----+
| o*+**=*=**+ |
| o B=o+o++o |
| E+.o+ + oo .|
| oo. * o ...|
| .+ S = o |
| . + o . |
| . . . |
| . |
| |
+----[SHA256]-----+

$ ls
id_rsa id_rsa.pub

개인키(id_rsa)는 젠킨스에 설정해준다. (처음부터 끝까지 복사, 첫줄 마지막줄 빼면 안된다… )

젠킨스에 SSH 개인키 설정

그 다음 공개키(id_rsa.pub)는 Github에 설정을 해준다.

Github에 SSH 공개키 설정

이렇게 한뒤 Jenkins 에서 임의로 job을 생성하고 job 설정 > 소스코드 관리 에서 git 부분에 아래처럼 테스트를 해서 정상적으로 연동이 된것을 확인한다. Credentials 값을 위에서 설정한 개인키로 설정하고, repo 주소를 SSH용으로 적었을때 에러가 안나오면 성공한것이다.

정상 연결되면 Jenkins 오류도 없고, github SSH 키에 녹색불이 들어온다.

끝~

linux(centOS)에서 selenium 설정하기 (feat. python)

Thu, 01 Feb 2018 14:52:10 +0000

테스트 코드로 안되는 실제 브라우저단 사용성 테스트를 하고싶은 경우가 있다. 이를테면 화면이 뜨고, 어떤 버튼을 누르면, 어떤 결과가 나와야 하는 일련의 Regression Test. 이때 활용할수 있는게 다양한 도구가 있지만 이번엔 selenium 에 대해서 알아보고자 한다.

처음부터 사실 web application 테스트를 하려고 selenium 를 알아보게 된건 아니고, 내가 참여하고 있는 특정 밴드(네이버 BAND)에서 일주일에 한번씩 동일한 형태의 글을 올리고 있는데 (일종의 한주 출석체크 같은…) 이를 자동화 해볼순 없을까 하며 밴드 API를 찾아보다 selenium 라는것을 알게되었고, 매크로처럼 어떤버튼 누르고 그다음 어떤버튼 누르고 하는 일련의 과정을 코드로 구성할수 있다는 점에 감동을 받아(?) + 별도의 API를 발급받지 않아도 되어 사용하게 되었다. (물론 UI가 바뀌면 골치아프겠지만…)

여기서는 selenium 이 무엇인지에 대한 설명은 하지 않는다. (인터넷에 나보다 정리 잘된글이 많으니…) 단, linux 환경에서 셋팅하는 정보가 너무 없고 몇일동안 삽질을 한게 아쉬워서 그 과정을 포스팅 해본다. (나같은 분이 이 글을 보고 도움이 되실꺼라는 기대를 갖으며…)

※ 주의 : 본 포스팅은 밴드 서비스에 글을 올릴수 있는 비 정상적인 방법의 공유가 아닌, selenium에 대한 사용 후기(?)에 대한 글입니다. (참고로 막혔어요 -ㅁ-)

설정하기

서버 환경은 CentOS 7.4 64Bit + Python 3.6.3 + jdk 8 이다. 우선 selenium 을 설치해준다.

$ sudo python3.6 -m pip install selenium

그 다음 CentOS에서 크롬브라우저를 설치하기 위하여 yum 저장소를 추가한다. (꼭 크롬이 아니더라도 파이어폭스나 지금은 지원이 끊긴 팬텀JS 같은것으로 활용할수도 있으나 다른것들도 해봤는데 자꾸 설정에서 걸려서 크롬에 대한 내용을 포스팅 한다.)

$ sudo vi /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

그리고는 yum 으로 크롬 브라우저를 설치한다. (내가 설치했을때의 버전은 google-chrome-stable.x86_64 0:64.0.3282.119-1)

$ yum install google-chrome-stable

크롬드라이버를 설치해야한다. 다음 url에서 받을수 있는데 https://sites.google.com/a/chromium.org/chromedriver/downloads 나는 2.35 linux64 버전을 받았다. 다운받고 unzip 하면 딱하나 파일이 있는데 나중에 selenium 을 사용할때 이용되니 path를 알아두자.

그다음 파이썬 코드를 작성한다. 내가 짠 파이썬 코드는 다음과 같은 순서로 실행이 된다.

밴드 접속 ( https://band.us/home )
로그인
특정 밴드 선택
글쓰기 버튼 누르고 양식에 맞춰 글 작성
글 등록

파이썬 코드는 아래처럼 작성하였다. (중요부분만.. 그 아래는 자유)

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

# 초기화 --------------------------------------------
chrome_options = Options()
chrome_options.add_argument("--headless")

driver = webdriver.Chrome(executable_path='home/~~~/chromedriver', chrome_options=chrome_options)
driver.implicitly_wait(3)
driver.get('https://band.us/home')

# 로그인 --------------------------------------------
driver.find_element_by_class_name('_loginLink').click()
...생략

그리고 실행을 해보면 작동이 잘~ 된다.

selenium + python 으로 자동작성된 밴드 글

마치며

selenium 에 대해 찾아보면 거의 윈도우 환경에서 돌아가는것들에 대한 포스팅이 많았다. 난 리눅스 환경에서 스케쥴러(젠킨스 같은)를 통해 자동으로 화면없이 작동시키고 싶었는데 아무리 찾아봐도 + 삽질해도 잘 안되었다. 결국 사내에도 나같은 삽질을 하신 분을 찾고 묻고 물어 크롬드라이버만 있어야 하는것이 아니라 크롬앱또한 있어야 동작을 한다는것을 알게 되었다. 역시, 내가 한 삽질은 누군가 이미 한 삽질이라는걸 다시한번 깨닳은 좋은(?) 시간이였다.

이걸로 나중에 내가 맡고있는 서비스에 대한 웹 자동 테스트 툴도 만들어 볼 생각이다.

아파치 엑세스 로그를 엘라스틱서치에 인덱싱 해보자.

Thu, 25 Jan 2018 21:18:35 +0000

apache access log 를 분석하고 싶은 상황이 생겼다. 아니 그보다 apache access에 대해서 실시간으로 보고싶었고, log를 검색 & 데이터를 가공하여 유의미한 분석결과를 만들어 보고 싶었다. 그에 생각한것이 (역시) ElasticStack.

처음에 생각한 방안은 아래 그림처럼 단순했다.

처음 생각한 단순한 구조

하지만, 내 단순한(?) 예상은 역시 빗나갔고 logstash에서는 다음과 같은 에러를 내뱉었다.

retrying individual bulk actions that failed or were rejected by the previous bulk request

request가 많아짐에 따라 elasticsearch가 버벅거리더니 logstash에서 대량작업은 거부하겠다며 인덱싱을 멈췄다. 고민고민하다 elasticsearch에 인덱싱할때 부하가 많이 걸리는 상황에서 중간에 버퍼를 둔 경험이 있어서 facebook그룹에 문의를 해봤다. https://www.facebook.com/groups/elasticsearch.kr/?multi_permalinks=1566735266745641 역시 나보다 한참을 앞서가시는 분들은 이미 에러가 뭔지 알고 있으셨고, 중간에 버퍼를 두고 하니 잘된다는 의견이 있어 나도 따라해봤다. 물론 답변중에 나온 redis가 아닌 기존에도 비슷한 구조에서 사용하고 있던 kafka를 적용. 아, 그전에 현재구성은 Elasticsearch 노드가 총 3대로 클러스터 구조로 되어있는데 노드를 추가로 늘리며 스케일 아웃을 해보기전에 할수있는 마지막 방법이다 생각하고 중간에 kafka를 둬서 부하를 줄여보고 싶었다. (언제부턴가 마치 여러개의 톱니바퀴가 맞물려 돌아가는듯한 시스템 설계를 하는게 재밌었다.) 아래 그림처럼 말이다.

그나마 좀더 생각한 구조

그랬더니 거짓말 처럼 에러하나 없이 잘 인덱싱이 될수 있었다. logstash가 양쪽에 있는게 약간 걸리긴 하지만, 처음에 생각한 구조보다는 에러가 안나니 다행이라 생각한다.

이 구조를 적용하면서 얻은 Insight가 있기에, 각 항목별로 적어 보고자 한다. ( ~~이것만 적어놓기엔 너무 없어보여서..~~ )

access log 를 어떻게 분석하여 인덱싱 할것인가?

apache 2.x를 사용하고 별도의 로그 포맷을 정하지 않으면 아래와 같은 access log가 찍힌다. 123.1.1.1 - - [25/Jan/2018:21:55:35 +0900] "GET /api/test?param=12341234 HTTP/1.1" 200 48 1144 "http://www.naver.com/" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_2 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Mobile/15B202 NAVER(inapp; blog; 100; 4.0.44)" 그럼 이 로그를 아무 포맷팅 없이 로깅을 하면 그냥 한줄의 텍스트가 인덱싱이 된다. 하지만 이렇게 되면 elasticsearch 데이터를 다시 재가공하거나 별도의 작업이 필요할수도 있으니 중간에 있는 logstash에게 일을 시켜 좀더 nice 한 방법으로 인덱싱을 해보자. 바로 logstash 의 filter 기능이다. 그중 Grok filter 라는게 있는데 패턴을 적용하여 row data 를 필터링하는 기능이다. 조금 찾아보니 너무 고맙게도 아파치 필터 예제가 있어 수정하여 적용할수 있었다. http://grokconstructor.appspot.com/do/match?example=2 그래서 적용한 필터설정은 다음과 같다.

filter {
 grok {
 match => {
 message => "%{IP:clientIp} (?:-|) (?:-|) \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:httpMethod} %{URIPATH:uri}%{GREEDYDATA}(?: HTTP/%{NUMBER})?|-)\" %{NUMBER:responseCode} (?:-|%{NUMBER})"
 }
 }
}

이렇게 하고 elasticsearch 에 인덱싱을 하면 키바나에서 다음과 같이 볼수 있다.

키바나에 내가 원하는 구조대로 이쁘게 들어가 있는 access log

각 필드가 아닌 한줄로 인덱싱이 되어버린다.

Elasticsearch 에 인덱싱이 되긴 하는데 로그 한줄이 통째로 들어가 버린다. message라는 이름으로… 알고보니 현재 구조는 logstash가 kafka 앞 뒤에 있다보니 producer logstash 와 consumer logstash 의 codec이 맞아야 제대로 인덱싱이 될수 있었다. 먼저 access log에서 kafka 로 produce 하는 logstash 에서는 output 할때 codec 을 맞춰주고

output {
 kafka {
 bootstrap_servers => "123.1.2.3:9092,123.1.2.4:9092"
 topic_id => "apache-log"
 codec => json{}
 }
}

kafka 에서 consume 하는 logstash 에서는 input 에서 codec 을 맞춰준다.

input {
 kafka {
 bootstrap_servers => "123.1.2.3:9092,123.1.2.4:9092"
 topic_id => "apache-log"
 codec => json{}
 }
}

그렇게 되면 codec이 맞아 각 필드로 이쁘게 인덱싱을 할수 있게 되었다.

파이썬 버전 업그레이드 (2.6 > 3.6)

Mon, 08 Jan 2018 13:44:50 +0000

파이썬 2.x 에서는 depreate 된 모듈도 많고 3.x에서만 지원되는 버전들이 많아지면서 실컷 개발을 해도 파이썬 버전때문에 다시 짜야하는 상황이 생긴다. 파이썬 버전업을 하고싶어 구글링을 해보면 이렇다할 정리된 문서가 잘 안나온다. (영어로된 포스트는 많이 있긴 하나, 필자의 환경과는 맞지 않는 …) 그래서 이것저것 삽질을 한 결과 파이썬 버전을 올릴수 있었고, 이를 포스팅 해보고자 한다.

그러보고니 2018년 첫 포스팅이네… 올해는 정말 적어도 한달에 1~2개는 올릴수 있는 내가 되기를…

환경

CentOS 6.9
기본으로 python 2.6 이 설치되어 있는것을 확인할수 있다. (환경마다 다를수 있음.)

$ python -V
Python 2.6

설치순서

필요한 유틸리티를 설치한다.

$ sudo yum update
$ sudo yum install yum-utils
$ sudo yum groupinstall development

yum 저장소에서는 최신 파이썬 릴리즈를 제공하지 않으므로 RPM 패키를 제공하는 IUM 이라는 추가 저장소를 설치

$ sudo yum install -y https://repo.ius.io/ius-release-el7.rpm

파이썬 3.6 버전을 설치

$ sudo yum install python36u

pip 등 패키지 관련 모듈도 함께 설치

sudo yum install python36u-pip
sudo yum install python36u-devel

여기까지 하면 기존 파이썬 2.6과 새로 설치된 파이썬 3.6 이 설치되어있다.

$ ll /usr/bin/python*
-rwxr-xr-x 1 root root 9997450 Jan 2 16:02 python
lrwxrwxrwx 1 root root 6 Jan 1 06:02 python2 -> python
-rwxr-xr-x 1 root root 9032 Aug 19 2016 python2.6
-rwxr-xr-x 1 root root 1418 Aug 19 2016 python2.6-config
-rwxr-xr-x 2 root root 6808 Oct 12 08:19 python3.6
lrwxrwxrwx 1 root root 26 Jan 2 20:48 python3.6-config -> /usr/bin/python3.6m-config
-rwxr-xr-x 2 root root 6808 Oct 12 08:19 python3.6m
-rwxr-xr-x 1 root root 173 Oct 12 08:19 python3.6m-config
-rwxr-xr-x 1 root root 3339 Oct 12 08:16 python3.6m-x86_64-config
lrwxrwxrwx 1 root root 16 Apr 25 2017 python-config -> python2.6-config

환경변수를 설정해준다.

$ sudo mv python python_backup
$ sudo ln -s python3.6 python

확인

$ python -V
Python 3.6.3

pip 를 이용한 모듈 설치

pip란 Python Package Index 의 약자로 공식홈페이지는 다음과 같다. ( https://pypi.python.org/pypi/pip )
설치할 모듈을 다음과 같이 설치해주면 된다. ex : requests 모듈인 경우

$ sudo python3.6 -m pip install requests

What is Kafka?

Thu, 02 Nov 2017 21:30:13 +0000

필자가 맡고있는 서비스에 Elastic Stack 을 도입하면서 중간에 버퍼가 필요하여 Message-Queue 시스템들을 알아보던 중 Kafka 에 대해 알아보고, 정리를 해보게 된다.

기본설명 및 기존 메세징 시스템과 다른점

메세징 큐의 일종
말 그대로 분산형 스트리밍 플랫폼, LinkedIn에서 여러 구직 + 채용 정보들을 한곳에서 처리(발행/구독)할수 있는 플랫폼으로 개발이 시작
대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템, 기존 범용 메시징 시스템대비 TPS가 매우 우수
메시지를 기본적으로 메모리에 저장하는 기존 메시징 시스템과는 달리 메시지를 파일 시스템에 저장 → 카프카 재시작으로 인한 메세지 유실 우려 감소
기존의 메시징 시스템에서는 broker가 consumer에게 메시지를 push해 주는 방식인데 반해, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작하기 때문에 consumer는 자신의 처리능력만큼의 메시지만 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.

카프카 주요 개념

producer : 메세지 생산(발행)자.
consumer : 메세지 소비자
- consumer group : consumer 들끼리 메세지를 나눠서 가져간다.offset 을 공유하여 중복으로 가져가지 않는다.
broker : 카프카 서버를 가리킴
zookeeper : 카프카 서버 (+클러스터) 상태를 관리하고
cluster : 브로커들의 묶음
topic : 메세지 종류
partitions : topic 이 나눠지는 단위
Log : 1개의 메세지
offset : 파티션 내에서 각 메시지가 가지는 unique id

카프카는 어떤식으로 돌아가는가

zookeeper 가 kafka 의 상태와 클러스터 관리를 해준다.
정해진 topic 에 producer 가 메세지를 발행해놓으면 consumer 가 필요할때 해당 메세지를 가져간다. (여기서 카프카로 발행된 메세지들은 consumer가 메세지를 소비한다고 해서 없어지는게 아니라 카프카 설정 log.retention.hours(default : 168[7일])에 의해 삭제된다.)

partition 개수와 consumer group 개념

하얀색(consumer-01) : 파티션 개수가 4개인데 비해 컨슈머가 3개, 이렇게 되면 어느 컨슈머가 두개의 파티션을 담당해야하는 상황이 생긴다.
주황색(consumer-02) : 파티션 개수가 4개인데 비해 컨슈머가 5개, 이렇게 되면 하나의 노는(?) 컨슈머가 생기는 상황이 생긴다.
가장 적절한 개수는 정해지지 않았지만 통상 컨슈머그룹의 컨슈머 개수와 파티션 개수를 동일하게 가져가곤 한다.

참고 url

Apache keepAlive

Mon, 28 Aug 2017 19:56:40 +0000

서버를 운영하다보면 간혹 문제가 발생하곤 한다. 이를테면 메모리가 다른이유없이 올라간다거나, 사용자 입장에서 응답속도가 간헐적으로 느린다거나. 그럴때마다 선배개발자분들께서 가장먼저 입에 오르내리는 단어. keepAlive.

hexo 블로그에 tranquilpeak 테마 적용하기

Sun, 27 Aug 2017 17:52:56 +0000

여러가지 hexo 테마중에 그나마(?) 영어로 된 문서가 있어서 적용해보게 된 tranquilpeak 라는 테마. 오늘은 해당 테마를 적용하면서 겪은 문제, 그리고 적용 방법에 대해서 간략하게나마 정리해보고자 한다. (다른 테마들은 거의다 중국쪽이나 일본…) 먼저 hexo 공식사이트에서 알려주는 테마들은 다음 사이트에서 확인해 볼수 있다.

https://hexo.io/themes/index.html

기존에는 hueman이라는 테마를 사용하고 있었는데 (링크), 오랜만에 블로그를 다시(?) 시작하는 느낌을 내보고 싶었고 보다 더 심플하고 유행에 안탈것 같은(순전히 필자 생각) 테마를 찾아보다 tranquilpeak이라는 테마를 선택하게 되었다.

공식홈페이지 : https://github.com/LouisBarranqueiro/hexo-theme-tranquilpeak
샘플사이트 : http://louisbarranqueiro.github.io/hexo-theme-tranquilpeak/

우선 간략하게 설치과정을 나열해보면 다음과 같다.

themes 폴더내에 테마파일을 받은후 압축 해제
테마 폴더 이름을 변경
_config.yml 파일 내에 테마 설정 부분 변경 ( theme: tranquilpeak )
hexo clean → hexo generate → hexo server(or hexo deploy)

이렇게 하면 아주 간단하게 테마가 변경이 된다. 혹여나(필자처럼) 기존 테마를 커스터마이징 하고 싶을 경우는 별도의 과정이 추가로 필요하다. 기존에는 css나 js만 변경하면 간단히 수정되었는데 이 테마는 약간의 빌드(?)를 필요로 한다. 따라서 css나 js등 html 요소들을 수정하였다면 다음과 같은 과정이 필요하다.(테마폴더 최상위에서)

npm install
bower install
css 나 js 변경
grunt build
hexo clean → hexo generate → hexo server(or hexo deploy)

나같은 경우는 테마에 적용된 폰트를 바꾸기 위해 블로그 를 참조하였다. (해당 아티클에다 댓글폭탄을 ㅎㅎ;;)

mybatis insert/update 쿼리실행후 결과 가져오기

Tue, 04 Apr 2017 11:41:28 +0000

Select문이 아닌 다른 SQL Query(insert, update 등) 를 실행하고서 결과를 봐야하는 상황이 생긴다. 정확히 잘 수행되었나에 대한 확인. 어떻게 쿼리가 잘 수행되었나를 확인하는 방법은 다음과 같다. ※ 참고 url : http://www.mybatis.org/mybatis-3/ko/sqlmap-xml.html

useGeneratedKeys, keyProperty 옵션

사용하는 데이터베이스가 자동생성키를 지원한다면(mySql 같은) 해당옵션을 이용해 결과를 리턴 받을수 있다. 예로들어 파라미터로 아래 모델객체를 넘긴다고 가정하고

public Student {
 int id;
 String name;
 String email;
 Date regist_date;
}

아래 mybatis 구문으로 insert를 시도하게되면, 파라미터로 넘긴 Student 객체의 id값에 insert 했을때의 key값(id)이 들어오게 된다.

Student student = new Student();
student.setName('bla');
student.setEmail('bla@naver.com');

mapper.insertStudents(student); // 쿼리실행
student.getId(); // 추출 가능

<insert id="insertStudents" useGeneratedKeys="true" keyProperty="id" parameterType="Student">
 insert into Students ( name, email )
 values ( #{name}, #{email} )
</insert>

selectKey 옵션

Oracle 같은 경우는 Auto Increment 가 없고 Sequence를 사용해야만 하기 때문에 위 옵션을 사용할수가 없다. 하지만 다른 우회적인(?) 방법으로 위와같은 효과를 볼수가 있다. 파라미터의 모델이나 java구문은 위와 동일하고 xml 쿼리 부분만 아래와 같이 설정해주면 된다.

<insert id="insertStudents" parameterType="Student">
 <selectKey keyProperty="id" resultType="int" order="BEFORE">
 select SEQ_ID.nexyval FROM DUAL
 </selectKey>
 insert into Students
 (id, name , email)
 values
 (#{id}, #{name}, #{email})
</insert>

위와같은 코드에서 쿼리가 실행되기 전에 id값에 Sequence에 의해 값을 셋팅하게 되고, 자동적으로 해당 값을 Student의 id에 set하게 되서 동일한 결과를 볼수가 있다.

항상 테이블의 key값에만 해당하는것이 아니다. key값과는 전혀 상관없는 값도 selectKey 구문으로 리턴할수가 있는데 order옵션을 AFTER로 주고 리턴하고자 하는 값을 명시해주면 된다. 아래 코드에서는 입력할시 id값을 Sequence에서 가져오는게 아니라 수동으로 넣어주고, 입력했던 id에 맞는 regist_date 값을 리턴받아 위에서처럼 동일하게 값를 가져올수 있다.

<insert id="insertStudents" parameterType="Student">
 <selectKey keyProperty="regist_date" resultType="java.util.Date" order="AFTER">
 select regist_date FROM students WHERE id = #{id}
 </selectKey>
 insert into Students
 (id, name , email, regist_date)
 values
 (#{id}, #{name}, #{email}, syadate)
</insert>

Oracle + Mybatis 환경에서의 Date 다루기

Thu, 23 Mar 2017 11:16:05 +0000

상황

Oracle, Java 8, mybatis3 환경
Date컬럼에 데이터가 있는데 이를 select query로 조회하여 Model에 바인딩 시키고자 함.

쿼리에 아무 기능을 추가하지 않고 Date 형태로 Model에 바인딩을 하면 시분초가 없어진 2017-01-01 00:00:00 형태로 남게됨
그래서 아래처럼 쿼리 작성할 때마다 TO_CHAR를 사용해서 포맷에 맞추어 형변환을 시키고 Date 또는 String으로 Model에 바인딩 하곤 했음.

SELECT
TO_CHAR(reg_ymdt, 'YYYY-MM-DD HH24:MI:SS') AS registDate
FROM
...

이렇게 하다보니 query 만들때마다 형변환하는 쿼리를 만들어줘야하고, 자칫 포맷형식을 다르게 적으면 엉뚱한 결과를 초래하거나, Date형을 그대로 받아 사용해야하는 상황에서는 다시 형변환하는 과정(String to Date)을 해줘야만 함. .. 귀차니즘의 시작 : 삽질

1. 삽질의 시작

1-1. `오라클의 DATE형` → `java.sql.Date` 의 경우

mybatis에서는 자동적으로 org.apache.ibatis.type.SqlDateTypeHandler를 호출하게됨 mybatis 3 문서 참고
해당 핸들러의 내부 데이터 변환 코드는 다음과 같음

@Override
public Date getNullableResult(ResultSet rs, String columnName) throws SQLException {
	return rs.getDate(columnName);
}

java.sql.ResultSet.getDate()메소드를 호출하면 실제 ‘yyyy-mm-dd’ 만 가져와 리턴하게됨 (여기서 디버깅 해보면 rs.getTimestamp(columnName)값은 시분초까지 다 들어가 있음)
따라서 시간값이 없는 yyyy-mm-dd 형태로 리턴이 됨

1-2. `오라클의 DATE형` → `java.util.Date` 의 경우

mybatis에서는 자동적으로 org.apache.ibatis.type.DateOnlyTypeHandler를 호출하게됨 mybatis 3 문서 참고
해당 핸들러의 내부 데이터 변환 코드는 다음과 같음

@Override
public Date getNullableResult(ResultSet rs, String columnName) throws SQLException {
	java.sql.Date sqlDate = rs.getDate(columnName);
	if (sqlDate != null) {
		return new java.util.Date(sqlDate.getTime());
	}
	return null;
}

위의 org.apache.ibatis.type.SqlDateTypeHandler 변환코드에서 발생한 문제점과 같이 yyyy-mm-dd 만 가져와서 java.sql.Date 객체를 만들고, 이 정보를 토대로 java.util.Date 객체를 만들게 되는데 앞서 시간값을 뺀 정보로 만들어졌기 때문에 결국 동일하게 yyyy-mm-dd 형태로 리턴이 됨

2. 삽질완료, 해결의 시작

오라클 + mybatis 환경에서 Date타입을 다루기 위해서는 타입핸들러를 명시적으로 만들어줘야 한다는걸 알게됨.

2-1. `오라클의 DATE형` → `java.sql.Date` 의 경우

아래처럼 코드를 작성하여 커스텀 핸들러를 만들어 등록을 시켜준다.
mybatis-config.xml

<typeHandlers>
	<typeHandler handler="com.naver.dbill.admin.common.handler.CustomDateHandler"/>
</typeHandlers>

CustomDateHandler.java

...
import java.sql.Date;
...
public class CustomDateHandler extends BaseTypeHandler<Date> {
	...
	@Override
	public Date getNullableResult(ResultSet rs, String columnName) throws SQLException {
		Timestamp sqlTimestamp = rs.getTimestamp(columnName);
		if (sqlTimestamp != null) {
			return new Date(sqlTimestamp.getTime());
		}
		return null;
	}
	...
}

위 코드를 작성하고 실행해보면 정상적으로 시분초 값이 있는 완전한 Date 형태를 볼수 있다.

2-2. `오라클의 DATE형` → `java.util.Date` 의 경우

아래처럼 코드를 작성하여 커스텀 핸들러를 만들어 등록을 시켜준다.
단, mybatis 3 문서를 보면 java.sql.Date 와는 다르게 기본으로 설정된 typeHandler가 JDBC에 따라 3가지가 있다.
따라서 작성한 커스텀 핸들러를 적용하기 위해서는 명시적으로 자바타입 과 JDBC타입 을 적어줘야 정상적으로 오버라이딩이 되어 해당 핸들러를 사용하게 된다.
mybatis-config.xml

<typeHandlers>
		<typeHandler handler="com.naver.dbill.admin.common.handler.CustomDateHandler" javaType="java.util.Date" jdbcType="DATE"/>
</typeHandlers>

CustomDateHandler.java 는 위와 동일하다. ( import java.util.Date; 사용으로 변경 )

삽질하며 알게된 보너스 지식

java.sql.Date 는 java.util.Date 을 상속받았다.

public class Date extends java.util.Date {
}

검색을 하다보면 알수있겠지만 java.sql.Date 는 JDBC등을 이용해서 데이터베이스의 데이터를 사용하는데 적합하고, java.util.Date 은 보다 범용적인 날짜나 시각정보를 다룰때 적합하다고 한다.
toString 메소드의 리턴 Format 형태
- java.sql.Date : yyyy-mm-dd
- java.util.Date : EEE MMM dd HH:mm:ss zzz yyyy
mybatis 에서 형변환은 mybatis 3 문서에 나와있는 자바타입과 JDBC타입이 일치할 경우에 해당 타입 핸들러를 기본으로 사용하게 된다.

정상혁 님 조언 ( http://d2.naver.com/helloworld/645609 작성하신분 )

Oracle의 JDBC 드라이버가 예상 밖으로 동작하네요. Oracle의 DATE 타입도 문서를 보니 시분초까지 저장하게 되어 있는데, Oracle JDBC 구현체가 DATE 타입의 철학을 오해한게 아닌가하는 생각도 듭니다.
참고로 java.sql.Date, java.sql.TimeStamp는 잘못된 설계라는 비판이 많습니다.
저도 Java의 날짜와 시간 API 라는 글에서 아래와 같이 적은 적이 있습니다.

java.sql.Date 클래스는 상위 클래스인 java.util.Date 클래스와 이름이 같다. 이 클래스를 두고 Java 플랫폼 설계자는 클래스 이름을 지으면서 깜빡 존 듯하다는 조롱까지 나왔다.[24]

스프링환경에서의 파라미터 관련 정리

Sun, 12 Mar 2017 18:03:01 +0000

일반적인 웹 프로젝트 구성에서는 Controller레벨에서 응답을 받고 비지니스 로직을 처리 후에 다시 View레벨로 넘어가는게 통상적인 흐름이다. 이 부분에서 파라미터 관련한 여러가지 부분에 대해 정리해보고자 한다.

httpServletRequest.getParameter()

아래소스처럼 HttpServletRequest의 getParameter() 메서드를 이용하여 파라미터값을 가져올 수 있다.

@RequestMapping("/")
public String home(HttpServletRequest httpServletRequest) {
 String id = httpServletRequest.getParameter("id");

 return "home";
}

@RequestParam

또다른 방법으로는 @RequestParam 어노테이션을 이용하면 간단하게 파라미터값을 가져올수 있다. 우선, 해당 어노테이션의 옵션값들에 대해 간략하게 확인하고 넘어가는게 좋을듯 싶다. API문서 4.3.6 기준

이름	타입	설명
name, value (Alias for name)	String	파라미터 이름
required	boolean	해당 파라미터가 반드시 필수인지 여부, 기본값은 true
defaultValue	String	해당 파라미터의 기본값

위 옵션값들을 조합하여 컨트롤러 메소드에 적용해보면 아래 소스와 같이 만들어지고, 이렇게 reqeust에서 파라미터값을 가져올수 있다.

@RequestMapping("/")
public String home(@RequestParam(value="id", defaultValue="false") String id) {
 return "home";
}

이 어노테이션을 이용하게되면 자칫 잘못하다간 에러를 만날수가 있는데 required값을 true로 해놓고 (필수 파라미터 설정) 해당 파라미터를 사용하지 않고 요청을 보내게 되면 HTTP 400 에러를 받게 되니 각 옵션들을 정확히 확인하고 사용해야 할 것 같다. 물론 컨트롤러의 메소드에서 해당 어노테이션을 사용하지 않고도 아래 코드처럼 바로 받을수 있다. 이렇게 바로 받을 경우는 필수 파라미터값이 false로 설정이 되고 변수명과 동일한 파라미터만 받을수 있게 되며 기본값 설정을 할수는 없다. 방법의 차이라서 상황에 따라 맞춰 사용하면 될듯 하다.

@RequestMapping("/")
public String home(String id) {
 return "home";
}

@RequestBody

@RequestBody어노테이션을 사용할 경우 반드시 POST형식으로 응답을 받는 구조여야만 한다. 이를테면 JSON 이나 XML같은 데이터를 적절한 messageConverter로 읽을때 사용하거나, POJO형태의 데이터 전체로 받을경우에 사용된다. 단, 이 어노테이션을 사용하여 파라미터를 받을 경우 별도의 추가 설정(POJO 의 get/set 이나 json/xml 등의 messageConverter 등)을 해줘야 적절하게 데이터를 받을수가 있다.

@PostMapping("/")
public String home(@ReqeustBody Student student) {
 return "home";
}

@ModelAttribute

@RequestParam과 비슷한데 1:1로 파라미터를 받을경우는 @RequestParam를 사용하고, 도메인이나 오브젝트로 파라미터를 받을 경우는 @ModelAttribute으로 받을수 있다. 또한 이 어노테이션을 사용하면 검증(Validation)작업을 추가로 할수 있는데 예로들어 null이라던지, 각 멤버변수마다 valid옵션을 줄수가 있고 여기서 에러가 날 경우 BindException 이 발생한다.

Spring command 객체

컨트롤러에서 파라미터로 받은 정보에 대해서는 view 에서 바로 사용이 가능하다. 예로 들어 아래그림처럼 이렇게 컨트롤러가 구성되어있고

이렇게 모델이 구성되어있을때

view 에서 이런식으로 구성되어있다고 가정해보자.

이때 /student?name=taetaetae&age=32&address=green-factory로 호출을 해보면 구지 Model에 값을 셋팅해주지 않아도 다음과 같이 정보를 읽을수 있게 된다.

마치며

스프링에서 파라미터를 받는 방법은 상당히 다양하다. 이게 정답이다 정의할수 없을정도로. 상황에 따라 맞는 방법으로 파라미터를 받아야 하겠고, 각 방법에 장/단점을 최대한 살려서 좀더 깔끔한 코드를 작성할수 있어야 하겠다.

github api 사용방법

Thu, 02 Mar 2017 11:18:05 +0000

github 에서는 레파지토리의 전반적인 상황에 대해 다양한 API를 제공해주고 있다. 이번에는 그 API를 사용하는 방법에 대해 알아보고자 한다.

Personal access tokens 발급

우선 정상적인 API를 사용하기 위해 Personal access tokens를 발급받아야 한다. github 초기화면 > 우측상단 프로필사진 클릭 > setting > Personal access tokens 에 들어가 토큰을 생성을 한다. 해당 토큰의 허용범위를 설정한뒤 생성을 하면 만들어 지는데 여기서 발급되는 문자열은 따로 보관하는게 좋다. (나중에 다시 확인하려면 새로 재 생성하는 방법말고는 없기 때문에 한번 만들때 메모해 두는게 좋다.) 아래와 같이 생성완료.

API 사용방법

권한이 없는 Repository 의 내용을 확인할수 없듯이 github에서 제공하는 API또한 권한이 있는 Repository에 대해서만 API를 제공한다. 위에서 발급한 token 을 권한 체크할때 사용하는데 다양한 방법이 있을수 있겠으나 나는 간단하게 헤더에 포함시켜서 일반 GET 호출을 하는 방식으로 하였다. 윈도우 환경에서는 헤더 셋팅하고 호출하는게 조금 어려울수 있으니 이러한 부분을 설정할수 있는 Postman이라는 프로그램으로 호출을 해본다. 아래처럼 url은 https://api.github.com/으로 설정하고 Headers파라미터에 Authorization라는 key에 value를 위에서 발급받았던 token을 이용하여 token abcd~~식으로 입력해준다음 send버튼을 눌러주면 응답을 받을수가 있는데, 아래 그림은 제공하는 api의 모든 url을 확인하는 방법이다.

아래애서는 위에서 확인된 api url을 활용하여 내가 권한이 있는 레파지토리 내에서 확인할수있는 정보에 대한 API를 호출해보았다.

API 호출시 가장 보편화되어있는(?) 스팩인 JSON으로 응답이 내려오기때문에 어떠한 환경에서도 충분히 활용할수 있을것이라 생각한다. 나는 개인적으로 팀 내에서 하나의 Organizations내에 여러 Repository가 있는데 각각의 PullRequest에 대해 코드리뷰를 해야하는 상황에서 일일히 다 찾아보기 귀찮아 github-api를 활용해 open된 PullRequest가 있으면 알림을 주는 걸 만들어 보았다.

리눅스상에서 json 파싱

Tue, 28 Feb 2017 17:50:44 +0000

리눅스 상에서 json형태의 String 을 파싱해야하는 상황이라면 아래 라이브러리를 사용해보는것을 추천해본다.

jq

사용방법은 너무너무 간단하다.

자신의 시스템에 맞는 라이브러리를 다운받고

(32-bit system)
$ wget http://stedolan.github.io/jq/download/linux32/jq
(64-bit system)
$ wget http://stedolan.github.io/jq/download/linux64/jq

실행 권한을 설정해 준 뒤

chmod +x ./jq

root 권한으로 해당 파일을 이동시킨다.

sudo cp jq /usr/bin

실행은 다음과 같이 한다. Json String 이 아래와 같이 있다고 가정했을때

{
"name": "Google",
"location":
 {
 "street": "1600 Amphitheatre Parkway",
 "city": "Mountain View",
 "state": "California",
 "country": "US"
 },
"employees":
 [
 {
 "name": "Michael",
 "division": "Engineering"
 },
 {
 "name": "Laura",
 "division": "HR"
 },
 {
 "name": "Elise",
 "division": "Marketing"
 }
 ]
}

실제 사용과 결과는 다음과 같이 이루어 진다.

$ cat json.txt | jq '.name'
"Google"

$ cat json.txt | jq '.location.city'
"Mountain View"

$ cat json.txt | jq '.employees[0].name'
"Michael"

$ cat json.txt | jq '.location | {street, city}'
{
 "city": "Mountain View",
 "street": "1600 Amphitheatre Parkway"
}

보다 자세한 사용방법은 공식홈페이지( https://stedolan.github.io/jq/ )를 참조하면 좋을듯 하다.

eclipse에서 spring-boot로 web 만들기

Mon, 27 Feb 2017 14:37:27 +0000

Spring 환경에서 웹 어플리케이션을 만들어야 한다면 pom.xml 에 이런저런 설정들을 적어줘야 했다. 하지만 이런 수고(?)를 덜어줄수 있는 방법중에 한가지가 바로 Spring Boot로 만드는 방법인데, 이클립스 환경에서 만드는 법을 정리하고자 한다.

new > Maven Project

빈 Maven Project 를 만드는 방법은 아주 간단하니 생략하고… 만들게 되면 pom.xml 은 아래처럼 아주 깔끔한(?)상태로 만들어지게 된다.

<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.example</groupId>
 <artifactId>boot</artifactId>
 <version>0.0.1-SNAPSHOT</version>
</project>

그러면 이 비어있는 pom.xml 에 Spring-Boot 에 필요한 설정들을 추가해주기로 한다.

<parent> <!--boot의 스타터를 사용하겠다고 명시적으로 설정-->
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>1.5.1.RELEASE</version>
 <relativePath />
</parent>

<dependencies>
 <dependency> <!--boot에서 스타터패키지로 제공해주는 것들중에 web 설정 부분 -->
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>
</dependencies>

<build>
 <plugins>
 <plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 </plugin>
 </plugins>
</build>

그다음 임의의 java 클래스를 하나 만들고 거기에 아래처럼 설정하면 끝

@SpringBootApplication // @Configuration + @EnableAutoConfiguration + @ComponentScan 들의 종합 어노테이션
public class TestApplication{
 public static void main(String[] args) throws Exception {
 SpringApplication.run(TestApplication.class, args);
 }
}

Spring Boot 에서는 내장WAS를 가지고 있기 때문에 main 메소드에서 우클릭후 run AS → Spring Boot App 을 선택해주면 8080포트로 띄워지게 된다.

new > Spring Starter project

(STS가 설치되어있다는 가정하에)이 메뉴를 사용하면 위에서 했던 일련의 설정들을 자동으로 해주게 된다. 간단한 내용이니 next를 해주다 마지막에 Dependencies 설정하는 부분에서 Web 을 체크해주고 Finish 버튼을 누르면 끝

Spring Initializr (start.spring.io)

http://start.spring.io/ 에 들어가보면 구지 설명하지 않아도 친절하게 Generate 해주는 페이지가 보인다. 여기서 web 을 Dependencies에 추가하고 Generate를 하면 해당 프로젝트가 압축된 상태로 다운이 받아지게 되고 이를 IDE 에서 열어보면 위에서 했던 일련의 과정들이 설정되어 있는것을 확인해볼수가 있다.

내장톰켓을 사용안하고 별도 톰켓을 사용해야 하는 경우

Spring boot는 자체적으로 내장 WAS를 가지고 있다. 하지만 관리포인트나 이런저런 이유로 내장톰켓을 사용하지 못하는 환경이라면 다음과 같은 설정을 해주면 된다.

일반적으로 빌드가 되면 jar로 만들어 질텐데 war로 빌드 되도록 수정을 해야한다. (was가 WAR를 물고 떠야하기 때문..)

<packaging>war</packaging>

dependency 에 tomcat을 추가해준다.

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-tomcat</artifactId>
 <scope>provided</scope>
</dependency>

아래처럼 main 메소드가 있는 클래스에 SpringBootServletInitializer를 상속받게 한 후 configure메소드를 오버라이딩 해준다.

@SpringBootApplication
public class TestApplication extends SpringBootServletInitializer {
 @Override
 protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
 return builder.sources(TestApplication.class);
 }
 public static void main(String[] args) throws Exception {
 SpringApplication.run(TestApplication.class, args);
 }
}

톰켓에 띄우기 위하여 프로젝트 설정(Project Facets)에서 Dynamic Web Module을 체크해준다.

참고 URL

lombok(롬복)소개 및 설치

Wed, 22 Feb 2017 17:48:42 +0000

일반적으로 자바개발을 하다보면 Model 을 만들고 각 멤버변수를 접근할수 있는 (각 요소들이 private 접근권한을 가지고 있을때) method 를 만들게 된다. IDE에서 제공하는 아래처럼… (윈도우/이클립스 기준)

get/set 메소드 : Alt + Shift + S + R
toString 메소드 : Alt + Shift + S + S
기타 등등…

public class Student {
 private int id;
 private String name;
 private int grade;
 private String department;

 public int getId() {
 return id;
 }

 public void setId(int id) {
 this.id = id;
 }

 public String getName() {
 return name;
 }

 public void setName(String name) {
 this.name = name;
 }

 public int getGrade() {
 return grade;
 }

 public void setGrade(int grade) {
 this.grade = grade;
 }

 public String getDepartment() {
 return department;
 }

 public void setDepartment(String department) {
 this.department = department;
 }

 @Override
 public String toString() {
 return "Student [id=" + id + ", name=" + name + ", grade=" + grade + ", department=" + department + "]";
 } 
}

이렇게 하는 방법도 있지만 어노테이션 설정으로 적용할수 있는 간단한 라이브러리를 소개하고자 한다. 바로 lombok, 공식 홈페이지 : https://projectlombok.org 설치 및 사용방법은 아주 간단하다. 공식 홈페이지에서 jar를 다운받고 실행, 아래처럼 이클립스 실행파일 경로를 설정해준다음에 인스톨을 누르면 된다. maven 환경에서 dependency를 가져오기 위해서는 당연히 추가설정을 해줘야 한다.

<dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <version>1.16.10</version> <!--버전은 그때 맞춰서-->
</dependency>

실제로 코드상에서 사용방법은 다음과 같다. 정말 간단히, 어노테이션만 적용해주면 끝!

import lombok.Data;

@Data
public class Student {
 private int id;
 private String name;
 private int grade;
 private String department;
}

그럼 이렇게 기본적인 method들이 생성된다. 일반적으로 @Data를 사용하고 상황에 따라 필요한 어노테이션만 지정도 가능하다고 한다.

@Getter and @Setter
@NonNull
@ToString
@EqualsAndHashCode
@Data
@Cleanup
@Synchronized
@SneakyThrows 참고 URL : http://jnb.ociweb.com/jnb/jnbJan2010.html

logback 설정하기

Sun, 19 Feb 2017 15:10:45 +0000

자바 개발자라면 한번쯤은 들어봤고, 한번쯤은 사용했을법한 logger 로 log4j가 있을것이다. 하지만 최근들어 logback이라는것을 알게되었고, 왜 logback을 사용해야 하는 이유라는 글이 있을정도로 여러 측면에서 개선이 된듯 하다. (링크) 이번에 작성할 글의 목적은 logback을 설정하고 어떻게 사용하는지에 대해 작성해 보고자 한다. ※ 공식사이트 : https://logback.qos.ch/

pom.xml

maven구조라고 가정했을때 logback Dependency를 가져오기 위해서는 아래와 같이 pom.xml 에 설정해 주면 된다.

<dependency>
 <groupId>ch.qos.logback</groupId>
 <artifactId>logback-classic</artifactId>
 <version>1.1.7</version> <!--버전은 상황에 따라 -->
</dependency>

로그레벨

ERROR, WARN, INFO, DEBUG or TRACE

# logback 설정파일

일반적으로 logback.xml 이라는 이름으로 만들어 src/main/resources/아래에 위치하게 된다. Spring-Boot 환경에서는 logback-spring.xml 이라는 이름으로 설정해야 하는데 logback.xml로 설정하면 스프링부트가 설정하기 전에 로그백 관련한 설정을 하기 때문에 제어할 수가 없게 된다. ( 공식사이트 메뉴얼 : https://logback.qos.ch/documentation.html )

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <include resource="org/springframework/boot/logging/logback/defaults.xml" />
 <include resource="org/springframework/boot/logging/logback/console-appender.xml" /> 

 <!-- 변수 지정 -->
 <property name="LOG_DIR" value="/logs" />
 <property name="LOG_PATH_NAME" value="${LOG_DIR}/data.log" />

 <!-- FILE Appender -->
 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
 <file>${LOG_PATH_NAME}</file>
 <!-- 일자별로 로그파일 적용하기 -->
 <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
 <fileNamePattern>${LOG_PATH_NAME}.%d{yyyyMMdd}</fileNamePattern>
 <maxHistory>60</maxHistory> <!-- 일자별 백업파일의 보관기간 -->
 </rollingPolicy>
 <encoder>
 <pattern>%d{yyyy-MM-dd HH:mm:ss} [%-5p] [%F]%M\(%L\) : %m%n</pattern>
 </encoder>
 </appender>

 <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
 <layout class="ch.qos.logback.classic.PatternLayout">
 <pattern>%d{yyyy-MM-dd HH:mm:ss} [%-5p] [%F]%M\(%L\) : %m%n</pattern>
 </layout>
 </appender>

 <!-- TRACE > DEBUG > INFO > WARN > ERROR, 대소문자 구분 안함 -->
 <!-- profile 을 읽어서 appender 을 설정할수 있다.(phase별 파일을 안만들어도 되는 좋은 기능) -->
 <springProfile name="local">
 <root level="DEBUG">
 <appender-ref ref="FILE" />
 <appender-ref ref="STDOUT" />
 </root>
 </springProfile>
 <springProfile name="real">
 <root level="INFO">
 <appender-ref ref="FILE" />
 <appender-ref ref="STDOUT" />
 </root>
 </springProfile>
</configuration>

java 코딩에서의 로깅

실제 사용은 다음과 같이 LoggerFactory를 이용해서 사용하거나 Lombok어노테이션을 활용하면 심플하게 사용이 가능하다.

LoggerFactory 사용

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Foo {
 static final Logger logger = LoggerFactory.getLogger(Foo.class);

 public void test() {
 logger.debug("ID : {}", "foo");
 }
}

Lombok 어노테이션 사용

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class Foo {

 public void test() {
 log.debug("ID : {}", "foo");
 }
}

마치며

일반적인 웹 어플리케이션에서는 WAS에서 로깅을 따로 관리하고 있기 때문에 file 로 로깅을 할 필요는 없을것 같다.(일반 jar 형태에서는 파일 로깅이 필요 할수도…)

참고사이트

자바 8 Date

Tue, 10 Jan 2017 20:55:33 +0000

이제까지 내 기억으로는 Date 관련 클래스를 아래처럼 점차 바꿔써온걸로 기억이 난다. java.util.Date > java.util.Calendar > org.joda.time 그런데 java 8 버전에서 기존에 있었던 문제들을 개선해서 나왔다고 한다. (네이버 HellowWorld 포스팅 참고) JSR-310 이라는 표준명세로.

지금부터는 JAVA 8 에서 제공하는 API로 날짜 연산을 어떻게 하는지에 대해 알아보고자 한다. (물론 수많은 날짜 연산 방법을이 있지만 자주 쓰이는 부분들 위주로 정리해보자.)

Date > String (format)

LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));

String > Date (format)

LocalDateTime.parse("2017-01-01 12:30:00", DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));

날짜/시간 증감

LocalDateTime localDateTime = LocalDateTime.of(2017, 1, 1, 10, 0, 0);
localDateTime.plusDays(1); // 일
localDateTime.plusMonths(1); // 월
localDateTime.plusHours(1); // 시간
localDateTime.plusWeeks(1); // 주
localDateTime.minusYears(1); // 년
localDateTime.minusMinutes(1); // 분

더 다양한 내용들은 아래 URL 에서 확인이 가능하다. https://docs.oracle.com/javase/tutorial/datetime/iso/overview.html

Spring Transactional 설정 및 주요속성

Sun, 08 Jan 2017 17:19:30 +0000

지난번에는 트랜잭션의 설정값에 대해 알아본 바 있다. [ Spring Transaction 옵션 ] 이번 포스팅에서는 실제로 스프링 환경에서 어떤식으로 설정해야 @Transactional 어노테이션을 사용할수 있는지, 그리고 어떤 속성들이 있는지에 대해 알아보고자 한다.

설정

기존 xml방식에서는 다음과 같이 설정을 한다.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
 <property name="dataSource" ref="dataSource"/>
</bean>
<tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/>

혹, JavaConfig 방식으로 설정하기 위해서는 다음과 같이 설정한다.

@EnableTransactionManagement
public class AppConfig {
 ...

 @Bean
 public PlatformTransactionManager transactionManager() throws URISyntaxException, GeneralSecurityException, ParseException, IOException {
 return new DataSourceTransactionManager(dataSource());
 }
}

위와같이 설정을 해주면 트랜잭션을 설정하고자 하는 곳 어디서든 @Transactional 어노테이션을 지정해서 적용이 가능하다.

public class UserService{

 @Transactional
 public boolean insertUser(User user){
 ...
 }
}

주요속성

@Transactional 어노테이션의 주요속성은 다음과 같다.

속성	설 명	사용 예
isolation	Transaction의 isolation Level. 별도로 정의하지 않으면 DB의 Isolation Level을 따름.	@Transactional(isolation=Isolation.DEFAULT)
propagation	트랜잭션 전파규칙을 정의 , Default=REQURIED	@Transactional(propagation=Propagation.REQUIRED)
readOnly	해당 Transaction을 읽기 전용 모드로 처리 (Default = false)	@Transactional(readOnly = true)
rollbackFor	정의된 Exception에 대해서는 rollback을 수행	@Transactional(rollbackFor=Exception.class)
noRollbackFor	정의된 Exception에 대해서는 rollback을 수행하지 않음.	@Transactional(noRollbackFor=Exception.class)
timeout	지정한 시간 내에 해당 메소드 수행이 완료되지 않은 경우 rollback 수행. -1일 경우 no timeout (Default = -1)	@Transactional(timeout=10)

마치며

자칫 잘못했다가는 원치않는 트랜잭션으로 잘못된 결과를 초래할수 있기때문에 기본값은 숙지하는게 좋을것 같다.

spring4에서 json view 활용하기(with @ResponseBody)

Sat, 07 Jan 2017 15:47:59 +0000

수많은 블로거분들의 도움을 받고자 구글링을 해서 적용을 해봤지만 너무많은 삽질을 했다.(해봤던 방식은 jsonViewResolver 를 따로 설정해보거나, @RequestMapping 옵션을 바꿔보는 수준..) 특히나 Spring설정방식이 예전 방식이였던 xml이 아닌 javaconfig였기 때문에 더욱더 자료가 없었고.. 한참을 삽질하다 해결을 하여 포스팅하게 된다. 우선 환경은 spring 4.3.4.RELEASE, Maven, jdk8임을 밝힌다.

pom.xml

jackson-mapper-asl을 이용해서 하라는 블로거들도 있었지만, 아무리해도(뭔가 Spring버전과 맞지 않는듯 했다.) 잘 안되어 아래와 같은 dependency를 주었다.

<dependency>
	<groupId>com.fasterxml.jackson.core</groupId>
	<artifactId>jackson-databind</artifactId>
	<version>2.5.1</version>
</dependency>

Controller

아래와같이 @ResponseBody 어노테이션을 설정해주고 리턴은 해당 모델을 넘기면 된다.

@RequestMapping(value="/test")
@ResponseBody
public Map<String, Object> test(){
 	Map<String, Object> map = new HashMap<String, Object>();
 	map.put("1", "111");
 	map.put("2", 222);
 	return map;
 }

그리고 호출을 해보면 기대했던것처럼 이쁘게 json형태로 나온다.

{
"1": "111",
"2": 222
}

물론, list 나 array, 일반 객체도 가능하다.

정리

삽질을 끝에 알게된 사실(?)을 정리해보자. 다른측면에서 분석을 해보면. @ResponseBody을 이용하여 view 에 json 형태로 나타내고자 할 경우 가능한 상황은 toString으로 했을때 json형태로 나올수 있으면 가능하다. 예로들어 아래처럼 클래스에 Lombok 어노테이션인 @Data가 붙으면 자동으로 toString을 오버라이딩 해주기 때문에 해당 클래스를 리턴하게되면 자동으로 json 처리가 된다.

@Data
public Student{
 private String id;
 private String name;
 ...
}

@ResponseBody을 붙이고 List<Student>를 리턴하게 되면 에러가 나는데, 이럴경우 별도 라이브러리를 추가해줘야 자동으로 변환되어 json 형태로 나올수 있게 된다. (list.toString을 하면 json형태가 아닌 이상한 문자형태로 나오기 때문… Map같은것도 마찬가지 이유로 별도 라이브러리를 추가해줘야 정상적으로 나온다.)

마치며

단순히 @ResponseBody를 사용해서 json으로 리턴하려면 어떤 라이브러리를 추가해야한다 로 생각했던것에서, 이것저것 테스트 한 결과 toString을 할수 있어야 하고 그 값이 json형태이면 가능하다 로 결론이 지어졌다. 확실히 장님 코끼리 만지듯이 ‘그런가보다’하고 넘어가면 삽질이 진짜 불필요한 삽질이 되는것 같다. 구글링을 해보고, 테스트를 해봐서, 결론적으로 내것으로 만드는 습관을 가져야 겠다.

jsp include

Wed, 04 Jan 2017 18:36:17 +0000

1. 디렉티브방식

<%@ include file="~~"%>

정적 include 방식, 인클루드 되는 내용이 단순하게 텍스트로 포함되어 컴파일이 된다. (복사된다는 느낌)

주의할점은 비록 포함되는 페이지라 하더라도 한글을 제대로 처리하기 위해서는 포함되어지는 jsp파일 상단에 인코딩 명시를 해줘야 한다.
포함되어지는 jsp 내용이 변경이 될 경우 해당 jsp를 사용하는 jsp를 강제로 변경(touch) 해줘서 다시 컴파일이 되게 해야하는 불편함이 있다.
정적 방식이기 때문에 예로들어 전역변수를 인클루드 되는 jsp에서 지정하게 되면 상위jsp에서 사용이 가능하게 된다.

2. 액션태그 방식

<jsp:include page="~~"/>

동적 include 방식, 포함하는 문서와 상관없이 동적으로 컴파일 된다. (완전히 별도로 동작하기 때문에 변수를 동시에 사용하려면 따로 파라미터로 넘겨줘야 한다.)
flush 옵션은 요청흐름이 넘어가면서 현재까지 페이지의 결과를 출력할 것인지 말것인지를 결정하는것이다. 일반적으로 false로 설정한다.
<jsp:param>를 이용하여 파라미터를 전송할수 있다.

<jsp:include page="..." flush="false">
 <jsp:param name="name" value="이름" />
 <jsp:param name="pageName" value="페이지이름"/>
</jsp:include>

3. JSTL 방식

<c:import url="~~" />

JSTL(JSP Standard Tag Library) 태그중의 하나
컴파일 되고 동작하는 방식은 액션태그<jsp:include page="~~"/>와 같음
현재 컨테이너 안에 있는 자원외에 다른 외부 자원도 포함이 가능하다.

<c:import url="http://www.google.com/"/>

아래와 같이 보다 더 다양한 옵션이 제공된다

<c:import! url="읽어올 URL"
 var="읽어올 데이터를 저장할 변수명"
 scope="변수의 공유 범위"
 varReader="리소스의 내용을 Reader 객체로 읽어올 때 사용"
 charEncoding="읽어온 데이터의 캐릭터셋 지정" />

Spring Transaction 옵션

Sat, 08 Oct 2016 18:04:19 +0000

상황

스프링 환경에서 일반적으로 DAO 나 BO 레벨에서 다음과 같이 코딩을 하게 된다.

@Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
public int method(int i) throws Exception {
	return sqlMapClient.delete("~~~~");
}

무분별하게 Ctrl+C,V 신공으로 트랜잭션 어노테이션을 가져다가 사용할수도 있겠으나, 각 값들이 어떤 역활을 아는지에 대해 알고 넘어갈 필요성이 있다.

@Transactional

우선 해당 어노테이션을 적용하면 적용된 클래스 또는 메소드에 트랜잭션이 적용된다. 따라서 로직 흐름에 맞추어 전체적으로 트랜잭션을 적용할것인지, 아니면 특정 메소드에 적용할것인지 전략을 잘 세워야 한다.

isolation

격리수준이라는 옵션이다. 트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준을 말하는데 옵션은 다음과 같다.

READ_UNCOMMITTED (level 0)

트랜잭션에 처리중인 혹은 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 B라는 아직 완료되지 않은(Uncommitted 혹은 Dirty) 데이터 B를 읽을 수 있다.

Dirty read : 위와 같이 다른 트랜잭션에서 처리하는 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 dirty read 라고 하며, READ UNCOMMITTED 격리수준에서만 일어나는 현상

READ_COMMITTED (level 1)

dirty read 방지 : 트랜잭션이 커밋되어 확정된 데이터만을 읽는 것을 허용
어떠한 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 해당 데이터에 접근할 수 없다.

REPEATABLE_READ (level 2)

트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정이 불가능하다.
선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신하거나 삭제하는 것을 불허함으로써 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴함

SERIALIZABLE (level 3)

완벽한 읽기 일관성 모드를 제공
데이터의 일관성 및 동시성을 위해 MVCC(Multi Version Concurrency Control)을 사용하지 않음(MVCC는 다중 사용자 데이터베이스 성능을 위한 기술로 데이터 조회 시 LOCK을 사용하지 않고 데이터의 버전을 관리해 데이터의 일관성 및 동시성을 높이는 기술)
트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능하다.

propagation ( 전파옵션)

REQUIRED : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 새로운 트랜잭션을 생성
REQUIRES_NEW : 부모 트랜잭션을 무시하고 무조건 새로운 트랜잭션이 생성
SUPPORT : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 nontransactionally로 실행
MANDATORY : 부모 트랜잭션 내에서 실행되며 부모 트랜잭션이 없을 경우 예외가 발생
NOT_SUPPORT : nontransactionally로 실행하며 부모 트랜잭션 내에서 실행될 경우 일시 정지
NEVER : nontransactionally로 실행되며 부모 트랜잭션이 존재한다면 예외가 발생
NESTED : 해당 메서드가 부모 트랜잭션에서 진행될 경우 별개로 커밋되거나 롤백될 수 있음. 둘러싼 트랜잭션이 없을 경우 REQUIRED와 동일하게 작동

no-rollback-for - 예외처리 (기본값 : 없음)

특정 예외가 발생하더라도 롤백되지 않도록 설정

스프링 배치에서의 트랜잭션 (내가 당했던(?) 문제)

스프링 배치에서는 Tasklet 에서 기본적으로 step 단위 트랜잭션을 지원하고 있다고 한다. 기본적으로 job이 하나의 tasklet 의 step 으로 실행하다보니 명시적이진 않지만 내부적으로 전체 트랜잭션으로 걸려있게 된다. 나같은 job 내 DAO delete 메소드에서 @Transactional 설정을 하고 그 DAO 메소드를 반복문에 의해 delete 하는 로직을 수행하는 부분이 있었는데 부모의 트랜잭션(tasklet에서 설정된 트랜잭션)으로 인해 dao 를 몇번 호출하던 job단위로 트렌젝션이 걸리게 되었다. (결국 트랜잭션은 반복문이 다 끝나야 적용이 된다는점.) 그러다보니 가끔 DB Query Lock이 걸렸는데 DB레벨에서 undolog를 남기는게 너무 무거워져 lock이 발생

따라서 전파옵션을 수정해서 해당 문제를 해결하였다.

# 기존
begin 
delete < for 반복문
commit

# 전파옵션 수정 (기존 REQUIRES 에서 REQUIRES_NEW 으로 수정)
for
 begin
 delete
 commit
for end

디자인패턴-싱글톤

Thu, 06 Oct 2016 17:03:48 +0000

디자인 패턴중에 가장 잘 알려진 싱글톤 에 대해서 알아보고자 한다. 멀티 스레드 환경에서 자주 이용되는 패턴이라고만 들었는데 이번 기회를 통해 제대로 정리해보자

싱글톤이 무엇인가

싱글톤(Singleton)은 정확히 하나의 인스턴스만 생성되는 클래스이다.

라고 이펙티브 자바에서 정의되어있다. 즉, 딱 하나만 생성하고 이를 여기저기서 사용하는 패턴이라 생각하면 될듯 하다. 싱글 스레드 환경에서는 당연히 인스턴스를 공유할 상황이 없겠지만 대부분 멀티 스레드 환경이기 때문에 싱글톤 패턴은 아주 중요한 부분이다.

아주 고전적인 방법 (위험한 방법)

public class Singleton {
	private static Singleton uniqueInstance;

	private Singleton(){}

	public static Singleton getInstance(){
		if (uniqueInstance == null){
			uniqueInstance = new Singleton();
		}
		return uniqueInstance;
	}
}

위와 같은 상황에서 if절을 도달하는 시점이 각 스레드마다 다를경우 문제가 발생할 수 있다.(교묘한 시점에 객체가 1개 이상 반환될 여지가 있음) 이를 해결하기 위해서는 다음과 같이 getInstance()를 동기화 해주면 된다. 하지만 불필요하게 동기화 하는 오버헤드만 증가하게 된다.

public class Singleton {
 private static Singleton uniqueInstance;

 private Singleton(){}

 public static synchronized Singleton getInstance(){
 if (uniqueInstance == null){
 uniqueInstance = new Singleton();
 }
 return uniqueInstance;
 }
}

public static 인스턴스로 생성

 public static final LocalCache sharedObject = new LocalCache();

 private LocalCache()
 {
 }

이코드는 간단하다는 장점이 있는 반면에 유연하지 못한 부분이 있다. (아래 이어서 설명)

private static final 인스턴스로 생성

private static final LocalCache sharedObject = new LocalCache();

 private LocalCache()
 {
 }

 public static LocalCache getInstance()
 {
 return sharedObject ;
 }

이렇게 하면 factory 메소드를 통해 객체를 반환받고, 반환 받는 시점에 다양한 작업들을 할수 있다.

enum 으로 생성

public enum LocalCacheEnum
{
 LocalCache;

 //etc another functions
}

잘 사용하지는 않지만 가장 좋은 세번째 방법인 enum으로 클래스를 만드는 방법이라고 한다. 복잡한 직렬화나 리플렉션(reflection) 상황에서도 직렬화가 자동으로 지원되고, 인스턴스가 여러개 생기지 않도록 확실하게 보장해준단다. (by effective java)

그럼 어디서 사용될까

static 으로 선언해서 공통적으로 사용되는 부분이나 환경설정
내용이 변경되면 다른 클래스에서도 그 부분이 똑같이 적용되어 실행되어야 할때
자주 사용되는 부분을 싱글톤으로 만들어 생성되는 시간을 줄일때
스프링에서의 DB커넥션 로직

hexo 환경 구축하기

Fri, 23 Sep 2016 10:26:53 +0000

개요

이전포스팅 에서 이야기 한것과 같이 어느곳에서든지(집 또는 회사 등) 블로그 포스팅을 할수 있는 환경을 만들고 싶었다. (git을 이용해서.) 그래서 git repository 를 두개를 만들었고, 하나는 실제 블로그서버로 이용하고 하나는 블로그를 포스팅하는 hexo 환경을 저장하게 된다. 지금부터 이야기 할 내용은 hexo환경을 git repository 에서 pull 받아서 환경구성하는 부분을 이야기 하려고 한다.

환경구성

hexo설치와 git설치는 되어있다고 가정. 먼저 구성할 폴더를 생성하고 이 폴더에 hexo 환경을 구성하겠다고 초기 셋팅을 한다

mkdir blog
hexo init blog

그리고 hexo환경을 저장해둔 repository를 가져와야 하므로 git설정을 한다

cd blog/
git init
git remote add origin https://github.com/taetaetae/hexo.git
git fetch

필요없는초기셋팅이 되는 파일은 지우고

rm source/_posts/hello-world.md
rm -r themes/landscape/ #해당 테마를 사용하고 있다면 지울필요가 없다.

hexo환경 repository 를 pull받는다

git reset --hard origin/master
git pull origin master

hueman테마의 검색 기능을 사용한다는 가정하에 필요한 플러그인과, 나중에 deploy 할때 필요한 플러그인을 설치해준다

npm install hexo-deployer-git --save
npm install -S hexo-generator-json-content

이렇게 되면 기존처럼 환경설정이 마무리 되고, 포스팅을 할수 있게 된다.

추가

canonical 속성 npm install –save hexo-auto-canonical
사이트맵 속성 npm install hexo-generator-seo-friendly-sitemap –save
feed 속성 npm install hexo-generator-feed –save

hexo + github + blog 연동하기

Sun, 18 Sep 2016 15:38:34 +0000

들어가기에 앞서

예전부터 블로그를 운영해야지 하구서 tistory, naver blog 등 다양한 플랫폼으로 시작을 했었지만 이렇다할 운영이 안되었고 ~~사실 열정이 부족했었다.~~ 직접 홈페이지를 만들기에는 너무 많은 허들이 있다보니 (서버구축, 호스팅, 도메인 등 …) 계속 차일피일 미루고 있었다. 그러다 github에서 제공하는 pages라는 걸 이용해서 무료로 도메인과 웹호스팅을 할수 있다는 부분을 알게되었고, 거기에다 jekyll을 이용하면 설치형 블로그를 운영할수 있다는것에 놀라웠다. 하지만 jekyll을 적용해보려고 이것저것 하다보니 ruby라는 언어로 만들어져있고 커스터마이징이 어렵다는 부분을 확인, 좀더 알아보다 hexo 라는 걸로 해당 블로그를 만들게 되었다. 필자처럼 남들과는 다른 블로그를 만들고 싶거나, git command 공부도 하면서 블로그를 운영해볼 사람들은 해당 글을 천천히 따라오면 좋을것 같다.

hexo 시작하기

hexo 라는걸 시작하기 위해 몇가지 준비물이 있다.

node 설치
git 설치
github에 블로그로 사용할 빈 repository 생성
github에 hexo 설정을 저장할 빈 repository 생성

위 4가지(?!)가 전부 설치 되었다고 가정을 하고 시작을 해보겠다.

hexo 설치

간단하다. hexo 페이지에도 나와있는것처럼 아래 명령어를 실행해주면 된다.

$ npm install -g hexo-cli

블로그로 운영할 폴더 hexo 초기화

폴더 구조로 구성이 되기 때문에 임의의 폴더를 하나 만들고 해당 폴더를 hexo 명령어로 초기화 시켜준다.

$ mkdir <디렉토리명>
$ hexo init <디렉토리명>

로컬서버 띄워보기

이제 로컬에서 서버를 띄워서 블로그가 어떻게 나오는지 확인을 해보면 된다.

$ hexo s (or server)

간혹 서버가 실행이 안되거나 오류가 발생, 수정한 부분이 반영이 안된다면 clean 명령어를 한번 해준 다음에 다시 서버를 실행해주면 되는 경우도 있다.

$ hexo clean
$ hexo s (or server)

http://localhost:4000 을 접속해서 정상적으로 페이지가 나오는지 확인을 해보자. 페이지가 정상적으로 나온다면 성공!

글 작성

아래 명령어를 실행하면 /source/_post/ 아래에 .md 파일이 생성이 된다.

$ hexo new <글 제목>

해당 파일을 사용하기 편한 에디터로 열어서 마크다운 문법에 맞추어 수정을 하면 끝!

왜 두개의 repository가 필요한가

아래에서 이야기 하겠지만, 하나는 실제 블로그 내용이 올라갈 저장소이고 다른 하나는 블로그를 운영하고 있는 hexo 자체를 저장할 저장소이다. hexo 정보를 가지고 있지 않을꺼라면(필자처럼 다양한 PC에서 업로드 환경을 구축하지 않을꺼라면) 하나의 레파지토리만 필요할수도 있다.

github 셋팅

지금부터가 알짜배기다. 즉 이글을 포스팅 하는 의미. 다른 글들에서도 hexo 사용법을 친절하게 알려 주셨으나 github와의 연동, 그리고 어떤식으로 운영해야할지는 찾기 힘들었다. 필자는 감으로 그런가보다(?)하고서 터득한 바를 공유하려한다. (이게 정답은 아니지만, 나는 이렇게 사용하는게 맞겠다 싶어..)

일반적으로 github에서 블로그로 사용할 repository를 만들게 되면 http://(github아이디).github.io/(repository이름) 으로 블로그가 만들어 지는데 뭔가 조금 이상해서 ~~간지가 안나서~~ 찾고 찾아서 아래와 같은 방식으로 하게 되었다. 필자의 github 아이디는 taetaetae 이고 도메인은 아이디 그대로를 사용하여 http://taetaetae.github.io 으로 사용하고 싶었다. 따라서 github에 repository이름을 taetaetae.github.io로 만들어야 한다. 여기까지만 하면 일단 github에 배포할수 있는 준비가 되어있는 상태

hexo로 배포하기

포스팅한 글이 정상적으로 등록이 된 것을 로컬서버에서 확인이 되었으면 이 상태를 조금전 만든 github repository으로 배포(정확히 말하면 git push)해줘야 한다. 그전에 최상위 폴더에 있는 _config.yml 파일을 열어서 github 정보를 입력해 줘야 한다. 하단 영역 Deployment 부분에 다음과 같이 작성하고 저장한다.

# Deployment
deploy:
 type: git
 repo: https://github.com/taetaetae/taetaetae.github.io
 branch: master

그 다음 hexo 에서 github로 배포할수있는 플러그인을 설치해준다.

$ npm install hexo-deployer-git --save

이제 설정한 github에 배포를 하면 끝!

$ hexo deploy

1분~3분 뒤에 도메인을 접속하여 정상적으로 페이지가 나오는지 확인하고, github에 파일들이 push가 잘 되었는지를 확인한다.

향후 관리 hexo 정보 저장

나중에 다른 PC에서도 블로그를 포스팅 할 경우가 있으니 hexo를 이용하여 포스팅 한 환경 자체를 저장 해야할 필요가 생겼다. 따라서 만들었던 폴더 또한 github에 업로드를 해놓는게 좋을것 같다 (지극히 개인적인 생각) git command 설명은 따로 정리하지 않겠다.