개발

무중단 배포와 자동화 배포얼마전에 유튜브 영상을 보는데 CI/CD 라는 말이 오용되는 케이스가 있다는 이야기를 들었다. 최근 신입 개발자 이력서에 Jenkins 나 Github Actions 를 이용해서 자동으로 프로젝트를 배포하는 구조를 모두 CI/CD 라고 칭하는 경향이 있는데, 사실 자동화 배포 툴로 배포를 진행한다고 해도 프로젝트가 빌드되는 시간동안 배포가 중단된다면 이는 엄밀히 말해 중단없이 연속적으로 배포된다는 의미의 CD(Continuos Deploy) 라 할 수 없으며 단순히 자동화 배포라고 이야기 해야한다는 말이었다. 그렇게 보니 우리 프로젝트 또한 빌드 시간 동안 배포가 끊기게 되는 자동화 배포 구조로 동작하고 있었다.  최근에 내 이력서를 보고 공부가 웹어플리케이션 개발에 치중되어 웹..

의 여러 서비스는 위치 정보를 기반으로 동작하게 되어있다. 예를 들어 매칭 기능 같은 경우 내가 원하는 위치를 지정하여 창고를 등록해두면 해당 위치를 기준으로 특정 반경 내에서 수요가 맞는 아이템이 있는지를 검색한다. 기획 단계에서 이런 위치 정보 기반의 서비스를 구상할 때는 실질적으로 어떻게 구현할 것인지에 대한 기술적 고민을 거의 하지 않았었기 때문에, 막상 구현하려고 하니 어떻게 할지 머리속이 깜깜했었다. 프로젝트 초반부였어서 사실 간단한 부분인데도 많은 시도와 실패 끝에 겨우 기능 구현에 성공했는데, 이미 몇 달 지난 일이지만 기억나는 대로 정리해서 올려본다. 1. 초기 아이디어 비지니스 로직을 처음 작성하기 시작 했을 때, 가장 먼저 Storage(창고) 도메인의 기능 구현을 하려고 했었다. 는..

Reference[https://c-king.tistory.com/entry/N1-detector-%EB%A7%8C%EB%93%A4%EC%96%B4%EB%B3%B4%EA%B8%B0] 가끔씩 다른 개발 블로그들을 보면서 다른 사람들이 어떤 생각을 하고 어떤 코딩 스타일을 가지고 있는지 구경을 한다. 아무래도 랜덤한 블로그들을 다 뒤지고 다니진 않고 나와 비슷한 위치에 있지만 조금 더 실력이 좋고 나은 사람들을 위주로 구경하려고 하는데, 우테코 같은 유명한 코스를 밟고있는 사람들이 자극 받기 딱 좋다. 위 레퍼런스는 AOP 에 대해서 아예 모르던 때에 처음 본 포스팅인데 글 솜씨나, 아이디어에서 큰 자극을 받았고 본 프로젝트에도 AOP 를 적용해보자 는 생각으로 프로젝트에 도입했었다. (N+1 Detecto..

이전글[https://techforme.tistory.com/34] 이전 글에서 프록시객체를 자동으로 생성해주는 ProxyFactoryBean 에 대해서 썼는데, 이로써 인터페이스로 추상화하고 구현하는 지루한 과정을 하지 않아도 되게 되었다. 그러나 이 방식에는 한계가 있었는데, 또 다른 인터페이스에 부가기능을 추가하고 싶은 경우 다른 ProxyFactoryBean 을 다시 추가해야 한다는 점이었다. 이번 글에서는 한번에 여러가지 클래스, 여러 메서드를 맵핑하여 일괄적으로 부가기능을 부여하는 BeanPostProcessor (빈 후처리) 기술에 대해서 소개하고, 나아가 AspectJ 프레임워크를 이용하여 AOP 를 적용하는 것 까지 이야기하여 주제를 마치려고 한다. 1. 개념 정리 1) BeanPost..

지난 글 [https://techforme.tistory.com/33] 지난번 트랜잭션 테스트를 위해 의도적으로 예외를 던지는 테스트 스텁을 Proxy 패턴, Decorator 패턴을 통해 구현하였다. 이 때 프록시가 적용되는 대상의 interface 를 구현 하거나 구현체를 상속하는 방식으로 프록시 객체를 생성하였는데, 상당히 번거로운 작업이었다. 만약 인터페이스의 구현체가 아니라면 해당 작업은 더욱 번거로워질 것이다. 이번 포스팅에서는 자동으로 프록시 객체를 생성하여 스프링 빈으로 등록해주는 ProxyFactoryBean 을 사용하여 이 문제를 해결해 볼 것이다. 개념 정리 FactoryBean 우선 FactoryBean 에 대한 설명이 선행되어야 할 것 같다. FactoryBean은 Bean 을 추..

지난 주 Redis 에서 Transaction 을 주제로 포스팅 했는데, 오늘은 해당 트랜잭션이 잘 동작하고 있는지 테스트를 작성해 보았다. 트랜잭션에서 가장 중요하게 다뤄져야 할 부분은 원자성이므로, 테스트 대상은 트랜잭션 중간에 예외가 발생했을 시 롤백의 여부가 되겠다. 강제로 예외를 발생시키는 부분을 코드 중간에 넣어서 테스트를 해봐도 되지만 그렇게 되면 테스트 시에는 기존의 멀쩡한 비지니스 코드를 건드렸다가 배포시에는 다시 해당 예외 코드를 지워야 하는 번거로움이 생기며, 테스트의 자동화라는 목적도 무색해진다. 어떻게 기존의 코드를 건드리지 않고 예외를 던지게 할 수 있을까? 를 고민하다가, Decorator 패턴 / Proxy 패턴에서 그 답을 찾았다. Decorator 패턴 / Proxy 패턴..

어제 토비의 스프링 5장 챕터를 읽으면서 Transaction 의 원자성 에 대해서 처음 알게 되었다. 사실 Transaction 을 선언함에 있어서 가장 중요하고 핵심적인 이야기로 보이는데, 이걸 이제서야 개념적인 지식으로 습득했다는 데서 다소 충격적이었다. 가끔씩 Service 단에 Transaction 이 진행되는 메서드를 작성하면서 뚜렷한 이유는 없지만 왠지 모를 불안감, 다소 완성도가 떨어지는 듯한 느낌이 들곤 했는데, 바로 원자성에 대한 보장이 없다는 점이 그 원인임을 알게되었다. 이걸 깨닫고 TIL 에 Transaction 의 특성 4가지를 정리해서 아주 그럴듯하게 정리해놓고 싶었지만 솔직히 원자성 이외의 특성들에 대해서 잘 알지도 못하면서 떠드는 것은 기만같다. 그래서 간단하게 원자성에 대..

개발자는 코드를 작성할 때 언제나 런타임 시 발생하는 예외 상황에 대해 고려 해야한다. 코드가 항상 의도대로 동작하는 것은 아니기 때문이다. 예상하지 못한 상황들을 적절하게 핸들링 함으로써 원하는 대로 로직이 작동하지 않은 경우에도 어플리케이션을 올바르게 작동하게 한다거나, 아니면 예외를 의도적으로 발생시켜 여러가지 시나리오를 핸들링 하게 만들 수 있다. 1. RestControllerAdvice 예외 처리를 위해서는 기본적으로 RestControllerAdvice 어노테이션을 사용 할 수 있다. RestControllerAdvice 어노테이션은 Controller 계층의 예외를 전역적으로 처리하는 AOP 기술의 일종이다. Advice 라는 단어에서 프록시 객체를 생성하거나 바이트 코드 조작하는 AOP ..

이전 글 : 채팅 서비스에 Redis 도입 (1) [ https://techforme.tistory.com/16 ] 이전 글 : 채팅 서비스에 Strategy Pattern 적용 [ https://techforme.tistory.com/15 ] 구독 정보 Repository 로서 Redis 도입 이전 글에서 채팅 서비스에 Message Broker 로서 Redis 를 도입했던 글을 썼었는데, 이번에는 구독 정보 Repository 로서 Redis 를 적용한 부분에 대해서 쓰려고 한다. 구독 정보 Repository 는 이전에 인메모리 캐시를 이용한 ConcurrentHashMap 으로 구현하면서 Strategy 패턴을 적용했었는데, 그렇기 때문에 아래와 같이 인터페이스만 구현하고 yml 파일 설정만 변경..

파사드 패턴이란? 파사드(Facade)는 '건축물의 외관, 겉면'을 뜻하는 단어로, 프랑스어(façade)에서 건너온 단어이다. 원래 어원은 라틴어에서 얼굴(Face)을 뜻하는 facies(파시에스) 라고 하는데 건출물 외관 = 얼굴 로 이해해볼 수 있다. 디자인 패턴에서 말하는 파사드 패턴은 내부의 코드를 가려놓고 전면에 단순화된 인터페이스를 내세우는 구조가 마치 내부의 인테리어나 구조를 덮어놓은 건축물의 외벽과 유사하다는 데서 차용되었다. 여러 클래스들을 직접 가져와서 쓰게 되면 가독성도 떨어지고 의존관계도 복잡해지니, 하나의 단순화된 클래스를 만들어서 이를 쉽게 이용할 수 있도록 만드는 것이다. 아래 그림과 같이 말이다. 언뜻 듣기에 너무 쉬운 개념이라서 '이걸 따로 배울 필요가 있었나?' 라는 생..