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

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

상황파악부터

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

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

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

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

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

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

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

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

가장 간단하게는 기존 데이터를 보고 수동으로 설정하는 방법이 있을수 있다. 예로들어 자정 즈음에는 결제량이 가장 많기때문에 약 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로 설치해준다.

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

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시간 아파치 엑세스 로그)

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

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

위키백과에서는 아파치 응답코드 중 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 응답이 주루룩(?) 발생하는것을 알수 있었다. (사실 맨위에 엑세스 로그가 재현한 엑세스 로그이다.)

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

User-Agent가 뭐야?

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

기존의 방법

그럼 어떻게 내 서버에 들어온 사용자들의 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라는 모듈이 그나마 잘 파싱이 되어서 사용하게 되었다.

• 모듈별 비교

• 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를 넣어야지만 볼수있는 부분 등 약간 아쉬운 감이 있다. 뭔가 더 좋은 방법이 없을까? 깔끔하면서도 우아한 방법. 짱구를 열심히 더 굴려보자.

내가 운영중인 웹서비스의 응답속도를 보다 더 빠르게 하기 위해서는 어떤 방법이 있을까? 웹 서비스를 위해 서버를 구성할 경우 일반적으로 앞단에 웹서버를 두고 그뒤에 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 사용 전

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

• gzip 사용 후

1. 브라우저가 서버측에 /index.html을 요청한다.
2. 서버는 Request를 해석한다.
3. Response에 요청한 내용을 담아 보낸다. 여기서 해당 내용을 압축하는 과정이 추가가 된다.
4. 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

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

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 하고난 다음 응답 코드를 받아서 처리하는 방법이 있을수 있겠다. (물론 이러한 방법 말고 다양한 방법이 있을것 같다.)

코드 정적분석이라 함은 실제 프로그램을 실행하지 않고 코드만의 형태에 대한 분석을 말한다. 이를테면 냄새나는 코드(?)라던지, 위험성이 있는 코드, 미리 정의된 규칙이나 코딩 표준을 준수하는지에 대한 분석을 말하는데 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에 댓글로 달리도록 설정을 해보겠다. (코드리뷰를 봇(?)이 자동으로 해주는게 얼마나 편한 일인가…)

기본 컨셉

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

1. IDE에서 코드수정을 하고 remote 저장소에 commit & push를 한다. 그 다음 github에서 master(혹은 stable한 branch)에 대해 작업 branch를 PullRequest 올린다.
2. 미리 등록한 github의 web-hook에 의해 PullRequest 정보들을 jenkins에 전송한다.
3. 전달받은 정보를 재 가공하여 SonarQube로 정적분석을 요청한다.
4. SonarQube에서 분석한 정보를 다시 jenkins로 return 해준다.
5. 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 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정보를 등록해준다.