전체 글

상황 1. 트래픽의 일정 비율을 새로운 버전으로 라우팅 같은 서비스에 대해 2개의 버전 (v1, v2)를 배포해서 v2에 10%의 유저 트래픽을 보내 canary 테스트를 하는 상황이라 가정해보자. apiVersion: v1 kind: Service metadata: name: helloworld labels: app: helloworld spec: selector: app: helloworld ... v1과 v2는 라벨로 버전을 구분짓는다. apiVersion: apps/v1 kind: Deployment metadata: name: helloworld-v1 spec: replicas: 1 template: metadata: labels: app: helloworld version: v1 spec: c..

Overview Local 환경에서 개발 및 테스트를 진행할 때 많이 사용하는 Minikube에서 istio를 addons로 제공한다. minikube 공식 문서를 살펴보면 minikube addons enable istio-provisioner, minikube addons enable istio 명령어로 활성화 시키라는 설명밖에 없어서 addon을 파악하고 사용하기에는 가이드 라인이 부족하다. 이 문서에서는 istio control plane을 minikube의 addon으로 설치하는 방법에 대해 알아본다. 설치 방법 요약 minikube addons enable istio-provisioner --images="IstioOperator=istio/operator:1.18.1" # reference ..

Overview MSA 시장이 커지면서 서비스들은 서로 통신해야 했는데 여기에는 HTTP, gRPC, MongoDB 등 L7 프로토콜이 핵심적으로 사용됐다. L3, L4 기반의 기존 프록시들은 위와 같은 요구사항을 처리하기 어려웠고, 그에 따라 L7 기능을 포함하는 프록시가 점차 필요하게 됐다. 이런 상황에서 만들어진 Envoy 프록시의 기본 개념에 대해 알아본다. Envoy란? 네트워크는 애플리케이션에 투명해야 하며 장애가 발생하면 어디에서 문제가 발생했는지 쉽게 파악할 수 있어야 한다. Envoy는 Lift사에서 위와 같은 목적을 갖고 만들어진 클라우드 네이티브 애플리케이션용 서비스 프록시 오픈 소스이다. CNCF에서 Kubernetes, Prometheus 다음 세번째 Graduated Projec..

Sidecar 패턴은 서비스 메시, metric 수집, secret 가져오기 등에서 많이 쓰여왔다. 하지만 사이드카 컨테이너를 구현하기는 쉽지 않았다. 1.28버전 이전까지는 컨테이너가 사이드카 컨테이너임을 쿠버네티스에게 알려줄 방법이 없었다. 이는 사이드카 컨테이너가 메인 컨테이너 종료 전에 종료될 수 있거나, 작업이 실패하더라도 살아있을 수 있다는 의미이다. 따라서 몇가지 문제가 발생했다. Job의 경우 기본 컨테이너가 완료 되었지만 사이드카 컨테이너가 계속 실행되면 pod가 성공적으로 종료 됐는지 올바르게 판단할 수 없다. 사이드카 컨테이너가 너무 늦게 시작되어 기본 컨테이너 시작 시 이를 사용할 수 없게 되어 컨테이너가 다시 시작될 때까지 기다려야 한다. Istio 사이드카 컨테이너가 기본 컨테이..

개요 코틀린 + 스프링으로 서버를 개발하는 사례가 많아지면서 자연스럽게 JPA와 코틀린을 함께 사용하는 사례도 증가하고 있다. 하지만 JPA (Java Persistence API)는 이름에서도 알 수 있듯이 자바를 기준으로 한 ORM이기 때문에 코틀린으로 엔티티를 정의하다보면 서로 궁합이 좋지 않다는 것을 알 수 있다. 이 글에서는 JPA를 사용하여 코틀린 기반의 도메인 모델을 만들 때 발생하는 여러 문제점들 및 해결법, 엔티티의 컨셉을 해치지 않으며 모델링하는 고민을 다룬다. 자주 볼 수 있는 안티 패턴 사례 @GeneratedValue 사용시 이슈 및 대안책 equals() 구현시 이슈 및 해결 연관관계 collection 불변 설정시 이슈 및 해결 유용한 플러그인 및 라이브러리 엔티티 정의 팁 자..

앞서 무엇을 테스트할 것인가? 에 대한 정리를 해보았다. 무엇을 테스트 할 것인가? - (1) 테스트를 작성할수록 테스트를 얼마나 자세하게, 어떤 것을 테스트 해야하는 지 등의 고민이 점점 커졌다. 그렇게 레퍼런스를 찾던 중 2019년에 진행된 스프링캠프에서 진행된 좋은 세션을 발견 dongb.tistory.com 이번에는 어떻게 테스트할 것인가에 대해 정리를 이어보겠다. 어떻게 테스트할 것인가? 1. 테스트 가능한 것, 불가능한 것 "테스트 불가능한 영역을 Boundary Layer로 올려서 테스트 가능하도록 변경" 그렇다면 우리는 위의 상황에서 어떻게 코드를 구성해야 테스트 커버리지를 키울 수 있을까? 테스트할 수 없는 메소드를 Boundary 영역까지 끌어올리면 테스트할 수 있는 영역을 많이 확보할..

테스트를 작성할수록 테스트를 얼마나 자세하게, 어떤 것을 테스트 해야하는 지 등의 고민이 점점 커졌다. 그렇게 레퍼런스를 찾던 중 2019년에 진행된 스프링캠프에서 진행된 좋은 세션을 발견했다. 개인적으로 정말 좋은 강연이라는 생각이 들었다. 강연을 듣으며 테스트에 대한 기준을 정리해보았다. 테스트로 얻을 수 있는 것 테스트 작성으로 우리는 마음의 안정과 자신감을 가질 수 있다. 그렇다면 이 안정감과 자신감을 누구에게 주어야 하는가? 바로 "현재와 미래의 나"와 "현재와 미래의 동료" 이다. 테스트를 작성할 때 나 뿐만 아니라 같이 일하는 동료를 위해 테스트를 짠다는 생각을 갖고 작성하면 더 좋은 테스트를 작성할 수 있다. 무엇을 테스트할 것인가? 만약 우리에게 로또를 구현하라고 과제가 주어진다면 우리는..

좋은 단위 테스트 판별법 (FIRST) 이전 포스팅까지 우리는 단위 테스트가 많은 장점을 갖는다는 것을 배웠다. 그렇다면 무조건 적기만 하면 좋은 것일까? 단위 테스트도 하나의 코드이기 때문에 좋은 테스트와 그렇지 못한 테스트로 나눌 수 있다. 개발자들이 보편적으로 "좋은 단위 테스트" 라고 부르는 테스트는 FIRST 규칙을 따른다고 한다. 좋은 코드를 작성하기 위한 지침서 Clean Code 에서 이 FIRST 규칙에 대해 설명하고 있어 해당 내용을 정리해보겠다. Fast Independent Repeatable Self-Validating Timely Fast 좋은 단위 테스트는 실행이 빨라야한다. 단위 테스트는 내부 코드만 테스트할 때와 외부 자원을 다룰 경우의 실행 시간 차이가 크다. 모든 외부 ..

Spring 테스트에 대해 공부하다보면 "단위 테스트가 중요하다!"라는 말을 한번쯤은 듣게 된다. 도대체 단위 테스트가 무엇이길래 그렇게 강조를 하는걸까? 단위 테스트(Unit-Test)는요 단위 테스트 : 하나의 기능 또는 메소드 기준, 독립적으로 진행되는 가장 작은 단위의 테스트 하나의 메서드를 위한 테스트 Mock, Stub 같은 방법을 이용 메서드의 경계를 제어할 수 있으므로 테스트하고자 하는 관심 대상에만 집중해 테스트할 수 있음 단위 테스트, 그래서 왜 필요한걸까? 실무에서는 거의 대부분 단위 테스트를 작성한다. 통합 테스트는 여러 컴포넌트를 연결해 테스트하기 때문에 컴포넌트가 많아질수록 테스트 시간이 늘어난다. 이외에 단위 테스트는 통합 테스트와 비교하여 많은 장점을 갖고 있다. 하나씩 알아..

Test의 종류 및 개념 테스트는 테스트를 진행하는 범위에 따라 여러가지 종류가 있다. 인수 테스트: 고객이 명세한 요구사항을 충족했는지 검증하는 테스트, 사용자 혹은 고객이 해당 서비스를 인수할것인지 결정하기 위해 수행 부하 테스트: 퍼포먼스 테스트, 시스템 특정 지점의 반응 시간 지연, 실패하는지 테스트 기능 테스트: 공개된 API의 가장 바깥쪽에서 코드 검증 (Controller 호출, Security, http) 통합 테스트: 여러 작업 단위가 연계된 워크 플로우 테스트 (객체 간, 서비스 간, 시스템 간) 단위 테스트: 하나의 기능 또는 메소드를 기준, 독립적으로 수행하는 가장 작은 단위의 테스트 Reference [Unit-Test] 하고 계신가요? 개발자 단위 테스트