분산 환경에서의 장애 전파 문제 분산 환경에서 개발을 하다 보면 외부 API를 호출해야 하는 경우가 있을 것입니다. 특히나 아키텍처가 MSA로 구성되어 있다면 다른 서비스 호출이 매우 빈번합니다. 하지만, 다른 서비스에 문제가 생겼을 때 장애가 전파되기가 매우 쉽습니다. 즉 A 서비스가 B 서비스를 호출하는 상황일 때 B 서비스에 장애가 발생한다면 A 서비스까지 정상적으로 동작하지 않게 되는 것이죠. 이런 상황에서는 장애가 발생한 서비스를 탐색하고 요청을 차단할 필요가 있습니다. 그렇지 않으면 하나의 서비스에 생긴 장애가 전체 서비스의 장애로까지 이어지기 때문입니다. 재시도(Retry) 패턴 만약 네트워크가 일시적으로 끊겨 요청이 처리되지 않는 경우는 간단한 재시도로 해결할 수 있습니다. 재시도 패턴(R..

서론 톰캣 구현 미션을 마무리할 겸 그동안 공부한 간단한 톰캣 내부 구조, Request와 Response, parser를 알아보겠다. 우선 톰캣 만들기 미션 자체의 난이도는 체감상 높았다. 워낙 관련 지식이 없기도 했고, 로우 레벨을 개발하다 보니 새로운 문법들도 많이 보였다. 필자는 원래 CS나 너무 로우 레벨의 개념들에 대해서는 내가 개발하는 서비스와 관계가 별로 없을 거라고 생각했다. 실제로 여태 그랬다. 그런데 이번 미션을 진행하면서 정말 많이 느낀 점이 기본 지식, 즉 Java, CS 등을 더 자세히 공부해야겠다는 생각이 들었다. 괜히 시니어 개발자분들이 화려하고 트렌디한 기술보다 기본을 중시하는 이유도 알 것 같았다. 또한 미션을 진행하면서 톰캣 오픈소스에 총 2개의 PR을 기여했다. 톰캣의..

평소 젠킨스를 잘 사용하고 있었지만, 눈에 띄게 불편한 점이 있었다. 바로 빌드 시간이 미국시간(UTC)으로 설정되어 시간 차이가 꽤 나는 것이었다. 계속 구글에 서치를 해보았는데, 대부분 실행할 때 타임존을 서울로 설정해주었다. 하지만 나는 젠킨스 컨테이너를 이미 실행시키고 있다. 만약 이걸 삭제한다면 나의 수고가 물거품이 되어버릴 것이다. 그래서 포기하지 않고 찾은 결과를 여기에 정리한다. 많은 사람들에게 도움이 되면 좋겠다. 젠킨스 컨테이너 접속 우선 실행중인 컨테이너의 타임존을 변경하려면, 젠킨스 컨테이너에 직접 접속해야 한다. 처음 시도한 명령어 처음에 컨테이너로 접속할 때 아래의 명령어로 접속했었다. 하지만 이내 명령어를 바꾸게 되었는데, 배경은 아래에서 설명하겠다. sudo docker ex..

CI/CD 파이프라인을 구축해 보는 글에 이어 모니터링 시스템을 도입해보고자 하는 사람들에게 도움이 되고자 모니터링 구축기까지 이어서 작성해 본다. 모니터링 구축기라고 말은 했다만, CI/CD 파이프라인 글처럼 친절하게 설명하진 않을 것이다. 모니터링이라는 것은 자신의 상황에 맞게 어느 서버에 어떠한 옵션들을 설정해서 어떻게 보고 판단할 건지마다 천차만별이기 때문이다. 그래서 그런 모니터링 구축 가이드라인 글도 되려면 될 수는 있겠지만, 내가 모니터링 툴을 직접 도입해 보면서 헷갈렸던 과정들을 위주로 글을 작성하겠다. 모니터링이란? 시스템, 서비스, 네트워크 또는 애플리케이션의 상태와 동작을 지속적으로 감시하고 평가하는 프로세스다. 주요 목적은 시스템의 성능, 가용성, 안정성 및 보안을 확인하여 문제를 ..

이번에 프론트엔드와 협업을 하는 미션을 했다. 백엔드와 프론트엔드 모두 이전에 한 번씩 했던 미션 + @의 기능을 만들어 배포까지 하는 미션이다. 백엔드가 할 태스크는 CORS 해결, SSL 배포, + @ 기능 정도인 것 같았다. 백엔드보다 프론트엔드가 할 일이 비교적 많아 보였다. 기능에 따른 UI도 만들고 기존에 있던 것도 바꾸고 해야 할 테니 말이다. 특히 상태관리가 힘들다고 들었다. 그래서 백엔드 페어인 에단한테 간단한 CI/CD 파이프라인을 구축해보는게 어떻겠느냐는 제안을 했다. 그리고 너무 고맙게도 흔쾌히 받아주었다. 파이프라인을 구축한게 무언가를 더 해보자는 취지도 있지만, 무엇보다 AWS 인스턴스 자체가 한정된 네트워크로만 들어갈 수 있어서 외부에서 개발할 때는 어떠한 기능을 추가해도 인스..

요즘 어떠한 서비스를 만드려고 하면 대부분 팀 단위로 진행할텐데요. 팀 단위로 프로젝트 진행 시 백엔드 배포 환경 구축이 안되었을 때 프론트엔드 개발자들이 API를 어떻게 테스트 해볼 수 있을까요? 프론트엔드를 담당하시는 분들은 대개 VSC를 사용하고 IntelliJ가 노트북에 설치되어 있지 않을 확률도 높습니다. 물론 VSC에서도 스프링부트가 잘 동작할테지만, IntelliJ가 익숙하니까요. 그럼 프론트엔드 개발자들이 맨날 IntelliJ에 들어가서 DB 설정을 하고, 서버를 키고 API를 테스트 해봐야하는 걸까요? 그렇지 않습니다. 요즘엔 도커에서 좋은 기능도 많이 제공해주더라구요. 이번 포스팅에서는 "공통 환경 설정"이라는 주제를 가지고 포스팅하려고 합니다. 현업에서는 어떻게 할지 모르지만 우선 제..

준비물 : ec2(ubuntu), jdk 11, docker, jenkins, github 들어만 보고 실제로 사용은 못해본 녀석들.. 오늘은 진짜 해봅시다!! 작고 소중한 EC2 프리티어 프리티어 인스턴스의 메모리는 너무나 작고 소중합니다. 따라서 스왑메모리를 적용해서 조금이나마 숨통을 트이게 해줄텐데요. 만약 본인이 프리티어를 사용하는데 스왑 메모리를 사용하지 않는다면, 젠킨스 빌드할 때 서버가 죽습니다. $ sudo dd if=/dev/zero of=/swapfile bs=128M count=16 $ sudo chmod 600 /swapfile $ sudo mkswap /swapfile $ sudo swapon /swapfile $ sudo swapon -s 파일 열어주고 $ sudo vi /etc..