개요 API 서버를 개발하다보면 협업을 위해 API 문서화를 진행하게됩니다. Spring 기반의 프로젝트에서 API 문서화 도구로 Swagger와 RestDocs를 가장 많이 사용하게 되는데요, 각 문서화 도구의 장단점은 다음과 같습니다. 구분 장점 단점 Swagger • 아름다운 문서 • 문서에서 API Test 가능 • Swagger 어노테이션이 비즈니스 코드와 섞임 • 테스트 코드가 강제되지 않음 Rest Docs • 문서화를 위해 테스트코드가 강제됨 • 테스트 기반으로 문서화되므로 비즈니스 코드가 깔끔해짐 • 아름답지 않은 문서 • 문서에서 API Test 불가능 저는 API 문서화를 위해 두 기술을 모두 사용해봤는데요, 확실히 각각의 장단점이 뚜렷했습니다. 그러던 도중, 카카오페이 기술 블로그..
개요 서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 지난 포스팅에서 APM 도구인 Scouter를 설치하고 프로젝트에 적용해보는 방법에 대해 다뤘었다. 이후 운영환경에 적용하여 잘 사용하고 있지만 Connection/Thread Pool 등 애플리케이션에 대한 보다 세부적인 지표를 모니터링 할 수 있으면 좋겠다는 생각이 들었다. Prometheus는 2012년 출시된 오픈소스 모니터링 플랫폼이다. 기존 모니터링 플랫폼과는 다르게 Pull 방식을 사용하여, 각 모니터링 대상의 Exporter 또는 ..
개요 지난 9월 서비스 출시이후 사용자들의 데이터를 수집하고 애플리케이션의 가용성을 측정하는 방법에 대한 관심이 커졌다. 특히 로그 모니터링에 대한 관심이 커졌는데, 관련 내용을 찾아보는 과정에서 APM 이라는 키워드를 알게 되었다. APM 은 Application Performance Management의 약자로, 애플리케이션 및 코드의 성능 문제를 신속하게 식별하고 해결하기 위한 프로세스이다. 대표적인 APM 으로는 Dynatrace, New relic, AppDynamics, WhaTap 오픈소스로는, Naver의 Pinpoint, LG CNS의 Scouter 가 있다. 우리는 비용과 관리, 운영 측면에서 최소한의 리소스로 사용할 수 있는 도구를 원했기때문에 Scouter를 선택하게되었다. GitH..
🔹 github action - submodule 옵션 일반 git clone이나 git pull 명령어로 슈퍼 프로젝트의 하위에 있는 서브 모듈 코드까지 가져올 수 없다. git clone에는 --recurse-submodule 옵션을 붙여주어야 하고, git submodule update --remote 를 통해 서브 모듈의 변경 사항을 가져와야한다. github action에서도 마찬가지이다. github repository를 checkout 하기 위해서 checkout action을 사용하는데, submodule 에 대한 속성 값을 설정해주어야 서브 모듈까지 checkout 할 수 있다. checkout 에 대한 공식 문서를 보면 다음과 같이 설명하고 있다. - uses: actions/check..
도커는 docker engine 위에서 '컨테이너'라는 단위로 가상 실행 환경을 제공해주는 오픈 소스 플랫폼이다. 도커는 리눅스 커널 위에서 동작하여 가볍고 빠르다는 특징과 이식성, 보안 등 여러가지 장점을 가지고 있는 기술이다. 하지만, 도커는 CRI (Container Runtime Interface) 라는 표준 인터페이스를 지원하지 때문에 쿠버네티스에서 도커에 대한 지원을 중단하는 등 그 위상이 예전같지 않다는 것은 사실이다. 하지만, 현재까지도 많은 서비스와 개발자 사이에서는 도커를 적극적으로 사용하고 있다는 것을 다음의 통계를 통해 확인할 수 있다. 평소, 도커에 대한 관심이 많았기 때문에 관련 문서나 강의를 통해 지속적으로 학습을 이어나가고 있었지만 제대로 정리해야할 필요성을 느끼게 되어 이번..
SW 마에스트로에 합격하기 전부터 진행했던 팀 프로젝트가 벌써 마무리 단계에 있다. 마무리 작업을 진행하면서 여러가지 문제와 요구사항이 발생했다. 이러한 부분들을 코드에 반영할 때마다 EC2에서 매번 서버를 내리고 다시 jar 파일을 실행시키곤 했는데, 이 과정이 배우 비효율적이라 생각했기 때문에 최근에 배웠던 Github Actions를 사용한 CI/CD 파이프라인을 프로젝트에 적용시키기로 했다. Github Action을 최근에 사용해보았기 때문에 별 문제 없이 빠르게 적용할 수 있을 것이라 생각했지만.. 뭐든 호락호락하게 넘어가는 법이 없다. 팀 프로젝트에 Github action을 적용하면서 이 전까진 볼 수 없었던 다양한 문제와 마주쳤고 이에 대한 해결 과정에 대해 기록하려 한다. 🔨 1. su..
