그간 회고를 작성하지 않았는데, 회고를 작성하지 않으니 뭘 했는지 도무지 기억이 나지 않았다. 그래서 오랜만에 회고를 작성해본다.
요즘은 JVM책을 읽고 있다. [JVM성능튜닝이야기]라는 책인데 어려울거란 걱정이 무색하게 책은 정말 이해하기 쉽게 쓰여져있다.
더 자바 강의도 완강했다. JVM 책 읽기 전에 들었는데 그 덕에 JVM 책 읽기가 한층 수월했다.
중간에 해커톤도 나가서 상을 타왔다. 올해는 코로나때문에 해커톤을 못할 줄 알았는데 온라인 해커톤을 할 수 있어서 좋았다.
요즘은 지인들이랑 릴리즈를 목표로 한 토이프로젝트를 만들고있다. 오랜만에 여러 사람들과 하는 토이프로젝트고 토이프로젝트인만큼 자유도도 높고 즐겁게 하고있다.
알고리즘 스터디를 8월 초 부터 시작했다. 중간에 한계를 느끼고 프로그래머를 위한 기초 수학이라는 책을 샀다.
하반기에 한 학습 및 개발
- ELK 구축
- ECS with Netflix OSS to EB
- 이팩티브 자바, 오브젝트
- 더 자바 강의 완강
- 스프링 핵심원리 강의
- JVM 성능튜닝 이야기
- 엔젤핵 해커톤
- 토이프로젝트
- 알고리즘 스터디
ELK 구축
회사에서 ELK 로 로깅 시스템을 구축했다.
우리 서비스들은 ecs + fargate로 되어있으며 ec2처럼 직접 접근할수 없었기 때문에 그간 papertrail 라는 cloud 로깅 서비스를 이용하고있었는데 한달 200기가에 160만원정도로 굉장히 비쌌다.
물론 EFS를 사용하면 컨테이너 내부의 스토리지에도 접근할수 있지만 이 또한 100기가에 30달러로 굉장히 비싸다.
우리 서비스는 한달에 약 400GB 정도 로그가 쌓이기 때문에 비용적인 측면에선 적절하지 않았다.
그리고 ELK도 managed 로 구축하면 비쌌기때문에 ec2에 직접구축했다(사이즈는 t3 xlarge로 했는데 널널했다)
구글링해보면 구축하는 방법에 대한 내용은 많지만 구축한 뒤 최적화 하는 내용은 별로 없었다.
우선 우리 서비스 컨테이너 내부에서 로그를 파일로 쌓도록 했다. 처음엔 tcp 포트를 열어서 웹서버에서 tcp 스트림으로 logstash 로 로그를 보내주는 방법을 하려고 했으나 그렇게 구성하면 웹서버가 받는 부하가 크기때문에 파일로 쌓고 filebeat가 중앙 수집기(logstash)로 보내도록 했다.
로그는 logstash 에서 정규식으로 메세지를 분석해서 필드화 하는 방법이 있는데, 정규식은 비용이 비싸기 때문에 logstash 가 받는 부하를 줄이고자 웹서버에서 파일로 쌓을때 json 형식으로 쌓도록 하고 logstash 에선 간단한 데이터 후처리나 필드 제외 작업만 하도록 구성했다.
이렇게 하니 logstash가 처리해야할 연산이 복잡하지도 않았고 작업량도 아주 많진 않았기 때문에 logstash가 받는 부하가 적었다. 그리고 filebeat에서 send 딜레이를 줬기 때문에 중간에 redis같은 버퍼를 둘 필요도 없었다.
es에도 부하가 크진 않았기 때문에 굳이 es 노드를 3개 둘 필요는 없어서 한개만 사용하도록 했는데, 나중에 인덱싱 부하가 커지면 세개로 늘릴 예정이다.
웹 서비스 특성상 request response를 다 남기게 되는데 단순 get 요청같은 경우 es에 넣을만큼 중요한 데이터는 아니기 때문에 그러한 full log 는 일정 주기로 s3로 보내고, 중요한 데이터만 es로 보내고 시각화를 했다.
처음엔 팀원의 요청으로 request, response를 다 es로 보내고 kibana에서 시각화했는데 es에서 인덱싱은 문제가 없었으나 kibana로 보려고 하니 웹 브라우저가 뻗어버렸다.
당시 로그가 1 row 당 50만 byte 그러니까 50kb였고 브라우저에선 한번에 몇백개씩 로그를 렌더링해야했기 때문에 브라우저가 뻗는건 당연한것이었다.
이쯤되면 최초 구축할땐 보이지 않았던것들이 보였다. 가령 웹서버에 aws log agent를 붙이고 cloudwatch로 로그를 받아서 es로 로그를 보내줄수도 있고, efs를 쓰고 그 로그를 s3 + lambda => es 로 보내줄수도 있다.
전자는 fargate 를 사용할시 log agent 에 직접 configuration 을 적용할수없어서 못했으며(ec2에선 직접 log agent를 설치하고 설정을 할 수 있었다. 만약 fargate에 log agent 사용시 설정을 하는 방법을 아는 분은 댓글로 알려주시면 감사합니다) efs + s3 + lambda 방법은 비싸다.
여러가지 시도와 고민끝에 나는 logstash multi pipeline communication 을 하기로 결정했다.
웹서버와 filebeat의 부하가 최대한 적어야했기 때문에 logstash 쪽에 부하를 주는 방법을 선택했다.
파이프는 총 세개로 구성했다. 로그를 수신받아 두 가상주소에 나눠주는 메인 파이프, 가상 주소로부터 받은 로그를 주기적으로 s3로 전송하는 파이프, logstash 필터를 거쳐 es에 인덱싱하기 좋게 가공해 es로 보내주는 파이프 이렇게 세개로 구성했다.
그렇게 최종적으로 filebeat + logstash + elasticsearch + kibana + s3 로 로깅 시스템을 구축할수 있었다.
웹서버에서 로깅을 위해 logging filter 를 만들고 리팩토링하고 로깅 전략을 세우기도 했는데 많은 삽질을 하긴 했지만 재미있었다.
시행착오를 많이 겪었기 때문에 최소한의 최적화나 고생했던 부분등을 포스팅할 생각을 하고있다.
이팩티브 자바, 오브젝트
이팩티브 자바를 2/3정도, 오브젝트를 반정도 읽었다.
오브젝트는 도메인 설계하는데에 아주 좋았다. 책임을 나누고 응집도 높고 유연한 아키텍쳐를 설계하는데에 도움이 됐다.
특히 객체를 의인화해서 본다는 부분에서 충격을 받았고, 객체와 행위의 주체를 생각하며 도메인을 설계할수 있었다.
웹 서비스 특성상 변경이나 기능 추가가 잦은데, 이렇게 책임과 역할을 나누면서 설계하니 도메인이 꽤 깔끔하고 유연해졌었다.
더 자바 강의 완강
백기선님의 [더 자바] 강의를 완강했다. 목차에 JVM 내용이 있어서 JVM 책 읽기 전에 수강했는데, JVM 동작원리와 함께 간단한 예제가 있어서 좋았다.
엔젤핵 해커톤
작년에 이어 올해도 엔젤핵 해커톤을 나갔었다. [후기 글]
JVM 성능튜닝 이야기
올해 읽은 책중 가장 좋았다. 이 책은 올해의 책이다.
토이프로젝트
지인들끼리 일반 유저에게 서비스 할 목적으로 만들고있다. 처음엔 MSA로 설계했는데 비용때문에 모노레포가 되어버렸다.
도메인 지식이 있는 상태에서 설계하니 확실히 과거에 하던 개인 프로젝트와는 다르다는 생각이 들었다.
나는 유저 및 인증쪽을 전부 담당했다. 인증전략을 직접 세우고 플로우를 짰다. 처음부터 설계하면서 구현하는데 요 일년간 꽤 배운게 많았었다는 생각이 들었다.
빨리 완성해서 서비스해보고싶다.
다음달에 할 학습
- 알고리즘
- 토이프로젝트
- 웹서버 로깅 포스팅
총평
올해가 2개월밖에 남지 않았다. 신입땐 난 이런것도 할수있어요 였다면 지금은 당연하고 능숙하게 해야한다는 느낌이다.
그래서 요즘 내가 너무 서툴고 모르는게 많은것 같다는 생각도 들었다.
과거엔 그래도 다 할수있다는 근거없는 자신감이 있었는데 요즘 없어진걸 보면 더닝크루거 곡선의 우매함 꼭대기에 있다가 뚝 떨어진게 아닐까 싶기도하다.
그래도 막상 토이프로젝트를 밑바닥부터 만들어보니 요 일년간 배운게 꽤 많았었다는 생각이 들었다.
아무튼, 남은 2개월은 밀린 기술 포스팅도 하고 알고리즘하고 토이프로젝트도 하면서 보낼 예정이다.