고딩왕 코범석

Before Kafka 데이터를 전송하는 Source Application, 데이터를 받는 Target Application이 하나씩 있다고 가정하고, 추후에 애플리케이션의 덩치가 커지면서 여러 개의 Source, Target App 들이 굉장히 많아질 것이다. 문제는 이 Source, Target이 많아질수록 각각을 연결하는 라인들이 많아지게 되고, 이들을 배포하고, 이슈에 대해 추적하고, 유지보수하는 등등 관리하기가 굉장히 복잡할 것이다. 이를 해결하기 위해 링크드인에서 Kafka를 개발하였고, 현재는 오픈소스화 되어있다. Kafka Features Kafka를 사용할 경우, Source App들은 Kafka에 데이터를 전달하기만 하면 되고, Target App들은 Kafka에서 데이터를 받기만 하면..

기존의 Spring Cloud Config가 변경되었을 경우 해당 마이크로 서비스에 적용하는 방법 각 마이크로서비스 서버와 Config 서버를 재기동하는 방법 서버를 재기동 하는 것 자체가 굉장히 불편하다. Actuator를 활용하여 POST refresh를 요청해 애플리케이션을 재기동 하지 않고 적용하는 방법 http로 call하여 변경을 감지해 적용하는 것은 좋으나, 마이크로서비스가 많을 경우 이것도 불편하다. 각각의 마이크로서비스 마다 refresh를 호출해야 하기 때문이다. Spring Cloud Bus 분산 시스템의 노드(마이크로서비스)를 경량 메세지 브로커와 연결 각각의 시스템 상태 및 구성에 대한 변경사항을 연결된 노드(마이크로서비스)에게 전달 순수 Actuator만 적용하면 각 마이크로서비..

Spring Cloud Config 분산 시스템에서 서버, 클라이언트 구성에 필요한 설정 정보(application.yml or application.properties)를 외부 시스템에서 관리 하나의 중앙화 된 저장소에서 구성요소가 관리 가능하다. 각 서비스를 다시 빌드하지 않고, 바로 적용이 가능하며, 동적으로 환경 변경이 가능하다. 또한, 애플리케이션 배포 파이프라인을 통해 환경에 맞는 구성 정보를 사용한다. 그럼 이러한 Config 설정들의 우선순위는 어떻게 될까? Spring Cloud Config에서 우선순위들을 설정할 수 있다. 위의 그림 처럼 application.yml > application-name.yml > application-name-profile.yml 순서로 설정된다. app..

Reverse Proxy 리버스 프록시는 요청을 대신해서 보내는 것이다. 클라이언트의 요청을 받아 적절한 웹 서버로 요청을 전송한다. 요청을 받은 서버는 응답을 전송할 떄, 다시 이 리버스 프록시에게 전달하여 그 응답을 클라이언트에게 제공한다. 대표적으로는 nginx가 우리가 잘 알고있는 리버스 프록시 서버이다. Api Gateway? 사용자가 설정한 라우팅 설정에 따라서 각 엔드 포인트로 클라이언트 대신해서 요청을 하고 응답받으면 다시 클라이언트에게 전송하는 reverse proxy 역할 클라이언트가 마이크로서비스를 직접 호출하는 구조는 별로 좋지 않음 시스템의 내부 구조는 숨기고 외부의 요청에 대해 적절한 형태로 가공하여 응답을 클라이언트에게 전달하는 장점을 갖고 있다. 클라이언트와 각 마이크로서비스..

외부의 다른 서비스들이 마이크로 서비스를 검색하기 위한 개념 Key, Value로 저장된다고 가정할 때 Key Value 서비스 명들... 서비스의 위치들... 각각의 마이크로서비스가 어디에 누가 저장되어있는지, 요청 정보에 따라 서비스의 위치를 알려주는 역할이다. 스프링에서는 Spring Cloud Netflix Eureka가 있다. 클라이언트가 요청한 것을 load balancer나 api gateway로 전달되고, 요청 정보가 서비스 디스커버리에 전달되어 필요한 서비스가 어디있는지 확인한 후, 해당 마이크로 서비스에 전달한다. @EnableEurekaServer @SpringBootApplication을 실행시킴 서버의 자격으로 등록을 해주는 @EnableEurekaServer. 메인 메서드 실행 ..

안녕하세요! 이번 포스팅에서는 제가 어떻게 서비스 레이어를 분리했는지 포스팅해보았습니다. 그럼 바로 가보시죠! 기존의 코드 우선, 제 프로젝트의 서비스 레이어에서는 흔히 스프링 예제에 돌아다니는 것처럼 DomainService, DomainServiceImpl로 명명했습니다. 그에 따라 모든 비즈니스 로직들이 서비스 인터페이스에 모두 담겨져있었고 그걸 구현해서 로직을 작성했습니다. // Account > 회원 도메인 // 모든 비즈니스 로직들이 다 담겨있는 구조 public interface AccountService { SignUp.Response signUp(SignUp.CommonRequest signUpRequestDto); Account saveAccount(SignUp.CommonRequest..

안녕하세요! 이번시간에는 비동기 이벤트 로직을 테스트하는 방법에 대해 알아볼까 합니다. 제가 진행하고 있는 프로젝트에서 회원가입시, 인증 메일을 보내는 기능을 구현해야했습니다. 예전 스터디올레를 클론코딩하면서 비동기 방식을 스프링에서는 어떻게 구현하는지 공부해서 그렇게 어렵지 않았고, 그럼에도 불구하고 구글링해가면서 알아봤습니다... 구현 예제들을 쉽게 찾을 수 있었습니다. 하지만... 이 부분을 테스트하는 방법을 알기 쉽지 않았습니다. 다들 테스트하는 방법이 서버를 올린 다음, 해당 로직이 잘 동작하는지 하는 테스트가 전부였어요. 그러다 구글링을 해보고, docs를 참조한 결과 테스트하는 방법을 알게 되었습니다! 우선, 저의 프로젝트에서 회원가입 및 인증메일을 보내는 과정을 그림으로 표현해보겠습니다. ..

안녕하세요! 이번 시간에는 OSI 7계층을 정리해보려고 합니다. 포스팅이이 아주 단촐하고 정리 수준이라서 정확한 정보가 아닐 수 있기 때문에, 잘못된 정보에 대한 피드백은 항상 감사히 받습니다! 물리계층 상위 계층으로부터 전달 받은 데이터를 하드웨어에서 하드웨어로 다른 장비에 전기적 신호를 전송하는 역할을 담당합니다. 또한, 전달을 받았을 경우 전기적 신호를 처리하고 상위 계층에 bit 형태로 전송합니다. 네트워크 어댑터, 리피터, 네트워크 허브, 모뎀 등이 물리 계층을 담당하는 하드웨어 장비의 대표적인 예라고 할 수 있습니다! 참고로 이 bit는 전기적 신호(0 또는 1)를 의미합니다. 데이터링크 계층 물리 계층의 데이터를 신뢰성 있게 전송하는 계층입니다. 물리 주소를 참조하여 각 장비간 전송을 하고,..