KKanging

서비스 간의 횡단 관심사마이크로서비스를 운영하다 보면 분산되어 있는 많은 서비스들 간의 공통된 기능을 수행해야 할 수 있다공통기능보안로깅등등이러한 횡단 관심사를 서로 다른 각 서비스에 구현하는 것은 쉽지 않다.이유는 도메인을 개발하느라 이러한 기능 구현을 잊을 수 있고 또는 일관되지 않게 구현하여 혼란을 초래할 수 있다.또한, 모든 서비스가 이러한 관심사를 구현하기 위해 공통 프레임워크를 만들어 의존하게 한다면 강한 의존이 생겨 재컴파일과 재배포 없이 공통 코드 동작 변경이나 추가는 더욱 어려워 진다.서비스 게이트웨이란?이 문제를 해결하기 위해 횡단 관심사를 독립적으로 배치할 수 있고 , 아키텍처의 모든 마이크로서비스 호출에 대한 필터와 라우터 역할을 할 수 있는 서비스로 추상화해야 한다.이러한 추상화된..

기존 아키텍처의 문제점서비스 디스커버리란분산 아키텍처는 아주 많은 호스트들로 분산되어 있어서 문리적인 호스트 이름과 머신이 위치한 IP주소를 알아야 한다.이 개념은 분산 컴퓨팅 초창기 때부터 존재했고 공식적으로 '서비스 디스커버리' 로 알려져 있다서비스 디스커버리는 애플리케이션이 사용하는 모든 원격 서비스의 주소가 포함된 프로퍼티 파일을 관리하는 것처럼 단순하거나 UDDI 저장소 처럼 정형화 되어 있는 것일 수 있다.UDDI 는 Universal Description Discovery and Integration 의 약자로 중앙에서 웹 서비스를 등록 및 검색을 위한 표준 프로토콜이다.서비스 디스커버리가 마이크로서비스에 중요한 이유수평 확장회복성1. 수평 확장서비스 디스커버리를 사용하면 애플리케이션 팀은 ..

구성(그리고 복잡성) 관리마이크로서비스에서 왜 구성을 외부에서 관리할까마이크로 서비스 인스턴스는 베포 되고 시작할 때 사람의 개입을 최소화 해야한다. 하지만 구성을 같이 배포하거나 직접 배포할 때 수동으로 관리하게 된다면, 애플리케이션 사이에 구성 불일치나 예기치 않은 장애, 확장 문제 대응을 위한 지연 시간 등이 발생할 수 있다.마이크로서비스 구성 관리에 대한 논의분리 :서비스의 물리적 배포에서 서비스 구성 정보를 완전히 분리 해야한다.애플리케이션이 시작중일 때 전달되거나 서비스가 시작할 때 중앙 저장소에서 읽어 들여야 한다.추상화 : 구성 데이터를 직접 읽어오는 코드를 작성하기 보다 REST API 같이 서비스 인터페이스를 통해 읽어 와야한다.중앙 집중화 : 수백개의 서비스가 존재할 수 있기 때문에 ..

조회수 고민하기 시작한 계기“필드에 view count를 저장하는 필드를 넣고 게시글을 조회할 때마다 count를 1증가 하면서 구현하면 되지 않나? “라고 생각할 수 있다 단순 필드에 1증가의 문제점 조회수 증가 로직을 보면 위와 같이 수행된다게시글 데이터를 읽어오고 애플리케이션에서 1을 증가해서 update 하는 방식이다.무슨 문제가 있을까?(위 그림은 모식화하기 위해 별개의 spring에서 실행된거 처럼 보이는데 같은 spring 서버 안에서 별개의 트랜잭션에서도 동일하다.)위 그림과 같이 2번의 조회에 +2가 되어야하는데 1만 증가하는 Lost Update 현상이 발생하였다.이러한 동시성 문제는 읽기의 동시성 문제를 해결하기 위한 MySQL 에서 제공하는 MVCC로도 해결할 수 없다.이러한 동시성..