스프링 기반의 웹 어플리케이션을 만들다 보면 요청을 처리하는데 맨 처음에 위치하고 있는 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의 정보를 한곳에서 우아하게 로깅하는 방법에 대해 알아보고자 한다.

요구사항

투우사가 흔드는 빨간 천을 보며 돌진하는 황소처럼 (쓰고보니 너무 TMI 같다….) 당장 코딩을 시작하며 개발을 할 수도 있지만 정작 원하는 기능이 무엇인지 천천히 정리하고 넘어갈 필요가 있는 것 같다. (어쩔땐 오히려 후자가 더 빠른 개발을 하게 되는것 같다.)

1. GET, POST 등 다양한 http method 로 구현된 모든 컨트롤러의 파라미터와 기타 Request 정보가 로깅이 되야 한다.
2. 컨트롤러, 메소드가 늘어날때마다 별도의 코드 추가 없이 한곳에서 공통적으로 로깅이 되야 한다.
3. URL 중 특정 패턴으로 들어오는 요청은 다른 방식으로 로깅을 하거나, 로깅에서 제외할 수 있어야 한다.
4. 앞서 말했듯 다른 비지니스 로직에 영향을 주지 않아야 한다.

구현하기 - Request 의 파라미터 정리

Request 의 모든 로깅을 한곳에서 처리하기 위해서 filter(필터)를 활용하였다. 필터는 Dispatcher servlet의 앞단에 위치하고 있기 때문에 모든 정보를 확인할 수 있는데 용이하다. 물론 인터셉터를 활용해서도 방법이 있겠지만 본 포스팅 에서는 필터를 활용해서 구현하는것을 목적으로 한다. (사실 인터셉터로 몇번 시도해보다가 실패해서…유유 )

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

회사일을 하다 보면 시키는 대로 혹은 팀의 목표에 부합하기 위해 어쩔 수 없이 해야 하는 일을 하게 된다. 그러한 일이 재미있고 결과물에 대한 만족도가 100% 라면 다행이지만 간혹 재미도 없고 시켜서 하는 일은 밤을 꼬박 새 가면서 완성을 해도 썩 그렇게 만족스럽지 못한 경우가 대부분인 것 같다. (물론 회사일에서 자신만의 인사이트를 찾는다면 금상첨화겠지만… + 매번 회사일이 재미없고 하기 싫은건 아님) 언제부터인지 필자도 이러한 부분에 갈증을 느끼며 회사와는 별도로 무언가를 만들어 보고 싶은 마음이 무럭무럭 생겨날 즈음 facebook 타임라인에서 개발자와 디자이너가 약 7주간 프로젝트를 진행하는 D.light 투게더톤 이라는 행사가 있다는 것을 발견하고 나름 정성스레 지원서를 작성 후 합격 메일을 받게 된다. (GDG Facebook 해당 게시글) 이번 포스팅에서는 해커톤과는 살짝 성격이 다른 D.light 투게더톤을 진행하면서 느꼈던 부분들과 진행한 결과물에 대해 간략히 리뷰를 해보며 정말 급행처럼 지나간 약 7주간을 돌이켜 보는 시간을 갖고자 한다.

팀 빌딩

총 6개 팀 중에 필자는 여자 디자이너 두 분, 남자 안드로이드 개발자 두 분을 포함한 팀에 속하게 되었다. 5명 중 해커톤 참여 경험이 있다는 이유만으로 여자 디자이너 분께서 팀장이 되시고, 7주라는 시간이 정말 급하게 지나갈 것 같다는 억지(?) 이유를 들먹여 그팽이라는 팀 이름이 정해졌다. 그렇게 “우리가 정말 무엇을 만들 수 있을까?” 하는 의구심 속에 프로젝트가 시작이 되었다.

프로젝트 진행 전반

신기하게도 우리 5명은 각각 사는 지역이 전부 달랐다. (심지어 한 분은 매주 저 멀리 충청남도 천안에서 올라오셔야 하는 수고를 ㅠㅠ) 매 주말마다 오프라인으로 만나서 회의를 진행했다. 그래야 길다면 길고 짧다면 짧은 7주 안에 완성도 높은 결과물을 만들 수 있을 것 같아서였다. 프로젝트의 주제를 정하는 아이디어 회의에서 정해진 우리의 목표는 “동네 마트 할인 정보를 알려주는 앱"을 만들기로 하였다.

팀워크가 중요한 투게더톤 임에도 불구하고 여느 천재 디자이너, 천재 개발자처럼 일당백 스타일로 뚝딱 만드는 그런 프로젝트의 진행 방식은 피하려고 우리 모두가 노력하였다. 되도록이면 이렇게 모인 다섯 명이 한마음 한뜻으로 각자가 생각하는 크기와 양은 다르겠지만 이 프로젝트를 통해 무엇이라도 배울 수 있었으면 했다. 디자이너 분들은 서로 디자인하신 시안에 대해 공유를 하면서 개선해 나가는 모습과, 안드로이드 개발자 두분은 (거의 매일) 밤마다 서로 슬랙에서 개발 방법론에 대해 스터디를 하는 모습이 보기 너무 보기 좋았다. 물론 필자도 아무것도 없는 환경에서 백엔드 서버를 구축하고 API를 만드는 과정 속에서 정말 많은것을 배울 수 있었다. 그렇게 시간이 흘러 마지막 발표하는 전날엔 팀원 몇 분과 함께 꼬박 밤을 새우며 프로젝트 결과물의 완성도를 높이는데 노력하였고 필자 개인적으로 아주 성공적으로 프로젝트를 마무리할 수 있었다.

개발 진행

안드로이드 개발자분들은 코틀린 기반으로 개발을 하였다. 여러 디자인 패턴과 다양한 기술들을 사용하였다고 들었는데 필자는 아쉽게도 백엔드 개발을 하다 보니 전부를 이해하지는 못하였다. 예전에 토이 프로젝트를 파이썬 기반으로 해본 경험이 있어서 Flask 또는 Django 기반으로 API 서버를 구축해볼까 하고 고민하였다. 하지만 (Spring Boot 기반으로도 해보고 싶었고) 파이썬보다는 자바 기반으로 다양한 어플리케이션의 요구 사항을 개발하는데 조금 더 능숙할 것 같아서 Spring Boot 기반으로 개발 환경을 구성하였다. 서버는 AWS 프리티어의 EC2를 발급받고 DB 또한 AWS에서 제공해주는 RDS(mysql)을 발급받아 구성하였다. 그리고 DNS는 예전에 무료 도메인을 찾다가 알게 된 http://mooo.com/ 라는 서비스에서 발급받아 연결하였고, 프로젝트 기능 중에 서버에서 앱으로 푸시를 하는 기능이 있었는데 Firebase를 활용해서 구성할 수 있었다.

실무에서 자바 기반으로 개발을 하고 서비스를 운영을 하다보면 처음엔 아무런 문제가 없다가 사용자가 몰리는 등 이벤트성으로 트래픽이 많아질 경우 꼭 문제가 생기기 마련이다. 그럴때면 뒤늦게 부랴부랴 원인을 찾고 개선하기 바빠지게 된다. (아마 윗분들에게 혼나면서?ㅠㅠ) 평소에 이런 성능문제를 개선하고 미리 모니터링 할수있는 부분에 대해 관심을 갖고 있었던 찰나, 우아한 형제들에서 5월 우아한 테크 세미나를 한다기에 부랴부랴 장문의 글로 신청을 하였고 운이 좋아 당첨이 되었다. 한창 회사에서 새로운 서비스 출시, 그리고 잠을 줄여가며 별도로 진행하고 있던 토이프로젝트 등 여러가지로 바쁜 시기였지만 특히 예전부터 뵙고싶던 이상민님께서 직접 강의를 해주신다기에 피곤한 심신을 이끌고 세미나에 참석하였고 그 후기를 적어보고자 한다.

두레이로 만드신 발표자료를 공유해 주셨지만 저작권 문제도 있고 해서 필자기준에서 이해한 부분에 대해서만 공유하고자 한다. 더불어 그냥 듣고 앵무새처럼 발표내용 그대로를 공유하는건 의미가 없다고 생각되어…

성능

구글에서 작성한 성능이 중요한 이유 라는 아티클을 공유해 주셨다. (시간이 된다면 한번 읽어보길 강추, 무려 한글!) 어플리케이션에서 성능은 사용자의 증가, 이탈율, 응답속도에 영향이 있고 이는 결국 추구하는 가치(이를 테면 수익)에 직면한다고 한다. 사용자는 어느 관점에서 바라보는가에 따라 달라지고 각 관점에 따라 성능을 챙겨야 하는 부분이 달라진다. 수강신청을 하는 시점에서의 사용자와 뉴스 페이지를 읽는 시점에서의 사용자는 각 성격이 엄연히 다른것처럼.

• 시스템 관리자
  • 등록된 / 등록되지 않은 사용자
• 서버 관점
  • 로그인된 / 로그인 하지 않은 사용자
• 성능 테스터 관점
  • Active User
    • 서버에 부하를 주는 사용자
    • 메뉴나 링크를 누르고 결과가 나오기를 기다리는 사용자
    • 성능테스트시 Vuser와 거의 동일 ( Vuser : 가상사용자(virtual user) )
  • Concurrent user
    • 서버에 부하를 주고 있거나, 줄 가능성이 매우높은 서비스에 접속중인 사용자
    • 웹 페이지를 띄워놓은 사용자

TPS(Transaction Per Seconds)는 초당 얼마나 많은 요청을 처리할수 있는지에 대한 시스템의 절대적인 수치로 볼수있다. (개발자는 어느상황에서든지 대충 감으로 이야기 하지말고 정확한 수치로 이야기 해야한다는 뼈를 때리는 조언과 함께…) TPS는 Scale out/up을 통해 증가시킬수 있지만 Response Time 은 불가능하다. 물론 어플리케이션을 튜닝하면 두 수치 모두 개선이 가능하다. 이러한 TPS와 Response Time의 최대치는 출시전에 반드시 테스트를 통해 알고 있어야 이슈발생시 대응하는데 유용하다. Bottleneck 즉 병목은 장비, 어플리케이션, 저장소, 설정 등 다양한 상황에서 발생할수 있다. 그중에 “아주 일반적"으로 가장 병목이 많이 발생하는 구간은 DB이고 그 다음으로 클라이언트(Web page, App), Network이 있을 수 있다. 결론은 Performance engineering is “Composite Art” of IT 라는 하나의 문장으로 정리를 해주셨다. 아무리 이쁜 디자인과 어렵고 복잡한 기능이 있을지라도 성능이 뒷받침 안된다면 대용량 트래픽 상황에서는 무의미해지기 때문이라고 생각한다.

자바

자바의 역사에 대해 설명해 주셨다. ( 역사에 대한 보다 자세한 설명은 https://www.whatap.io/blog/12/ 참고 ) 언제부터인가 JDK 라이센스 이슈가 많았었는데 실무에서 개발하는 입장에서는 java 8 에서는 문제가 안되고 java 11부터 라이센스 문제가 복잡하게 생길수 있다고 한다. 이부분은 공식문서(?)를 찾아보는게 좋을듯 하다. (개인 또는 회사에서 사용할 경우 상황에 따라 법적 이슈가 생길수도, 안생길수도 있는 복잡한 문제가 있어보여서… 필자도 제대로 이해하지는 못했다ㅠ)

그리고 각 자바 버전에서 발표한 새로운 기능에 대해 설명해주셨다.

• Java 8
  • lambda, stream, default method, LocalDate / LocalTime 추가
  • stream 과 foreach 의 성능은 거의 차이 없음 (오히려 가독성이 나빠질수도 있다.)
  • ParallelStream 은 해당 장비의 cpu 개수만큼 스레드 풀을 만들어 사용 (오히려 독이 될수 있으니 잘 알아보고 사용할것)
• Java 9
  • Compact Strings : char[] > byte[]
  • G1 default GC : https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
  • Collections of (불변) : List.of, Set.of, Map.of
• Java 10
  • var 의 등장
  • Application Class-Data Sharing(AppCDS)
• Java 11
  • Oracle JDK의 유료화
  • Http Client. 기본 설정값들을 제대로 알고 써야한다. ( https://golb.hplar.ch/2019/01/java-11-http-client.html )
• Java 12
  • Switch expressions
  • Shenandoah : https://www.youtube.com/watch?v=E1M3hNlhQCg

모니터링

유명한 상용 APM들을 설명해 주셨다. 각각의 장점에 대해 설명해 주셨는데 정말 회사에 요청해 구매할수만 있다면 사서 해보고 싶을정도로 신기한 기능이 많았다. 그중 dynatrace 는 에이전트만 설치해두면 별도의 설정 필요없이 알아서 해준다고…

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

사이드 프로젝트 초기셋팅을 하며 호기롭게 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 의 정보를 볼수가 있다.

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파일명과 동일하게 저장해야 한다는 것이다. (안그러면 서버 접속시 실패가 남… 삽질…)

필자는 ElasticStack을 사용하면서 처음 카프카를 접하게 되었다. 메세징 큐 라는 개념도 전혀 모르는 상태에서 설치부터 ElasticStack 연동까지 사용하며 정말 강제로 카프카에 대해 공부를 하게 되었다. 카프카를 자주 다루고 메커니즘에 대해 자세히 살펴보다 잠깐 해이해질 무렵 카프카 한국 사용자 모임에서 밋업을 한다고 하길래 빛의 속도로 신청, 아마도 1등으로 신청했지 않았을까 싶다. 사실 작년 카프카 밋업을 못간게 너무 한(?)이 되어 이번엔 회사 업무 등 여러가지로 한창 바쁘지만 “지금이 아니면 안돼” 라는 생각으로 밋업을 다녀왔고, 짧지만 후기를 작성해 보고자 한다.

(요즘 왜 이렇게 바쁜지 모르겠지만… 신기하게도 그 바쁜 일정들이 하나도 겹치지 않는게 더 신기하다… )

참고로 필자는 카프카에 대해 아주 조금 건드려본 수준이라 발표하시는 분들의 전부를 습득하기엔 다소 그릇이 작아서 일부 세션은 거의 “그런가보다~” 하고 들을 수 밖에 없었다. 후기도 아마 그런 맥락으로 작성할듯 싶다.

• Kafka 한국 사용자 모임 링크 : https://www.facebook.com/groups/kafka.kru

카프카를 활용한 캐시 로그 처리 - 김현준(카카오)

• 이미지 등 캐시서버의 로그를 분석하기 위한 시스템을 구축하는데 ElasticStack 을 활용
• Elasticsearch 로 늦게 들어와서 사례를 찾아보니 대용량 로깅 처리시 앞단에 메세징 큐를 둬야 한다고 했고 그게 카프카
• 카프카 모니터링은 그라파나로 활용
• lag이 자꾸 생김
  • 파티션을 쪼개거나, 컨슈머를 늘리는 방법이 있음
  • auto.commit.interval.ms 와 enable.auto.commit=true 로 조정
  • interval을 줄이니 lag이 줄어듬
• 현재는 수백대 캐시서버의 로그를 초당 15만건 이상 처리중

질문을 했다. 필자도 lag이 높아지면 어쩌지 하는 불안감과 높아지면 컨슈머를 늘리면 되겠지 하는 막연함이 있었는데 commit interval을 줄이면 lag이 줄어든다고 해서 무조건 줄이면 좋은가에 답변은 카프카를 관리하는 주키퍼쪽에 무리가 간다고 설명해 주셨다. 역시 만병통치약은 없고 상황에 따라 적절하게 시스템 관리자가 조정해가며 운영해야 하는점을 느꼈다.

• 참고 URL : https://kafka.apache.org/documentation/#adminclientconfigs

카프카를 활용한 엘라스틱서치 실무프로젝트 소개 - 이은학(메가존)

• 카드사의 프로젝트를 약 3개월간 개발하였고 전체 아키텍쳐 중에 일부분을 kakfa를 활용
• Elasticsearch 데이터를 hadoop에 백업 형태로 옮기며 관리
• filebeat > kafka > spark streaming 을 활용하여 데이터의 검증처리가 가능 (특정 상황에서의 관리자에게 알림 등)
• logstash 의 ruby 필터를 활용하여 일정의 작업을 해주는 데이터 파이프라인 구성 가능 (개인정보 식별 등)
• logstash 는 cron형태의 배치로도 가능

또 질문을 하였다. (카프카 밋업과는 무관했지만…) logastsh 를 사용하면서 필터쪽에 로직이 들어가면 성능상 괜찮냐는 질문에 하루에 15억건을 처리하고있고 문제가 없었다고 한다. 필자는 아파치 엑세스 로그를 logstash로 처리하면서 간혹 뻗거나 에러가 발생했는데 아마 파일을 logstash가 직접 바라보고 처리도 하게해서 그런것 같다. (지금은 filebeat가 shipper 역활을 수행하고 있고 큰 무리 없이 운영중)

카프카를 활용한 rabbitMQ 로그처리 - 정원빈 (카카오)

• 레빗엠큐는 erlang으로 구현된 AMQP 메시지 브로커이고 TCP기반으로 구성
• Kafka 는 게으르지만 메우 효율성이 뛰어남, 반면 RabbitMQ 는 똑똑하지만 보다 느림
• Kafka 에서 Elasticsearch 로의 ingset 는 NIFI를 활용
• 레빗엠큐와 카프카의 차이

  	Kafka	RabbitMQ
  컨슈머 추가	여러 컨슈머가 하나의 메세지를 동시에 할수 있어 확장에 용이함	확장할때마다 큐를 추가 생성해야함
  메세지 저장	로그기반으로 디스크에 저장, 리텐션 이후 삭제	큐 기반으로 메모리에 저장 컨슈머가 메세지 수신시 즉시 삭제
  메세지 처리	발송확인 가능 / 수신확인 불가능	발송확인/수신확인 가능

카프카를 마이크로서비스 아키텍쳐에 활용하기 - 이동진 (아파치 소프트웨어 파운데이션)

• 카프카 스트림즈 소개 (Interactive Query)
• 카프카를 활용하여 마이크로서비스에서 사용하려면 데이터를 임시 공간에 넣어두고 (redis 같은?) 빼서 사용하는 형태가 아니라 Interactive Query 또는 Queryable Store 로 활용 가능

사실 이부분은 필자가 제대로 못따라간 세션중에 하나이다. 용어나 메커니즘도 다소 생소했고 대략 어떤 부분을 발표해주시는지 느낌은 있었으나 제대로 이해를 못해서 … 부끄럽지만 카프카 스트림즈의 공식링크로 대체한다.