일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 익명 객체 @transactional
- spring mongoTemplate
- java 백준 1509
- java 1509
- Java Call By Refernce
- spring mongoTemplate switch
- 백준 연결요소 자바
- java 팩토리얼 개수
- 자바 1676
- mongodb lookup
- kotiln const val
- ipfs bean
- 백준 특정한 최단 경로
- nodejs rabbitmq
- 백준 1504 java
- spring mongodb switch
- spring mongodb
- 백준 2252 줄세우기
- 안정해시
- go
- java 1238
- ipfs singletone
- kotiln const
- kotiln functional interface
- javav 1676
- 전략 패턴이란
- 자바 백준 팩토리얼 개수
- Spring ipfs
- java 파티
- rabbitmq 싱글톤
- Today
- Total
목록MSA & Arcitecture (11)
공부 흔적남기기
Axon을 사용해서 EDA 구현중 계속해서 저 에러가 발생했다.저 에러의 원인은 Event를 저장하기 위해서 Sequence 번호 1을 기대하는데 계속해서 0이 나온다는 말이다.즉 이미 Axon Event 저장소에 해당하는 AggregateId에 Sequence 번호 0 이 존재하는데 계속해서 0이 나온다는 말이다. 나의 실수를 update를 할때 @CommandHandler를 계속 생성자를 통해서 만들었다.Axon은 생성자일떄는 항상 Sequence 번호를 0으로 주는 것 같다.생성자를 handle 함수로 변경하니 잘 진행되었다. 즉 해당 에러가 뜰떄는 하나의 AggregateIdentifer에 대해 생성자를 여러번 호출하는 것이 아닌지 확인해보아야한다.
EDA란 Event Driven Architecture로 Event Sourcing을 기반으로한 아키텍쳐이다.일반적으로는 Persistence Database를 사용해서 Sync하게 Request를 받고 Processing을 한후 Response를 주는 Flow 였다. 이와 달리 EDA에서는 Request가 들어오면 Queue 에 Event를 Produce 한 후 Consume Service가 이를 처리하는 방식이다. Event 관리를 위한 데이터베이스가 존재하며 실제 Domain DB에는 가장 최신 Version의 이벤트가 들어간다. EDA를 사용하면 서비스간 강결합이 낮아지고 서비스간 응집도가 올라가며 데이터 정합성 undo에 대해 관리하기 용이해지고 이벤트에 대해서 일괄 연산도 가능하며, 오류가..
SAGA 패턴은 MSA와 같은 분산 서비스에서 하나의 트랜잭션으로 묶어서 연산을 수행하고 싶을 때 사용한다. Event 기반이며 Kafka와 같은 Message Queue를 이용하여 Async하게 Event를 주고 받는다. Sync로 동작하게 되면 특정 서비스의 장애나 대기로 인한 Data Lock, Transcation Context 소실 등 문제가 발생할 수 있고각 서비스간 강결합이 생기게 되어 관리가 어려워진다. SAGA Pattern은 각 서비스에서 다른 서비스의 성공/실패를 판단하지 않고 먼저 commit 하는데 그 이유는 위와 같이 Data Lock과 Transaction Context 소실 문제 때문이다. 다른 서비스가 실패 하게되면 보상 트랙재션을 통해서 RollBack 하게 된다. 이때 ..
1. Partition 의 개수하나의 Topic은 여러개의 Partition 을 가질 수 있는데 충분한 브로커가 있다는 전제하에서 Partition을 증가시키면 Consumer가 병렬로 처리하기 때문에 cosume 속도가 상당히 올라갈 수 있다.예를들어 하나의 Topic에 대해 기존에는 1개의 Partition만 사용했다면 속도가 1이였을 것이다.하지만 Partition의 개수를 n개로 조정한다면 cosumer가 동시에 n개에 partion에 병렬로 연결하여 처리하므로 최대 n배가 빨리질 수 있는 것이다. 2. Partition Replication FactorKafka는 고성능도 중요하지만 고가용성도 중요하다. 적절한 Replica개수를 조정해서 고가용성을 가능하게 만들자.이때 Replica를 많이 만..
헥사고날 아키택쳐란클린 아키텍쳐의 일종으로 Adapter와 Port를 통해서 내부 비즈니스로직이 외부의 영향을 받지 않도하고 항상 저수준 모듈이 고수준 모듈에 의존하게 하는 아키텍쳐이다. 즉 개발자는 외부 infra에 상관없지 비즈니스 로직만 잘 짜면 되는 관심의 분리를 높이고 응집도를 높이는 아키텍쳐이다. 구현Adpater를 통해 Request가 들어오면 해당 Adapter는 Port를 호출하고 Port의 구현체인 비즈니스 로직이 핵심 로직을 처리한다.또한 비즈니스 로직에서 외부 API나 DB를 호출할때역시 Port를 통해 호출하고 Apdater를 통해 나간다.Domain을 분리하고 DIP를 통해 외부와의 결합을 떨어뜨리고 외부의 변화가 내부에 영향을 미치지 않도록 한다. 고민근데 고민인게 이것 또한 ..
Microservice ArcitectureMSA란최근에 독립적으로 배포가능한 서비스들을 디자인하는 아키텍쳐로 MSA가 떠오르고 있다.MSA에 대해 정확한 정의는 내리기 어렵지만비즈니스 능력(capability), 배포 자동화(automated deployment), 엔드포인트의 지능(intelligence in the endpoints) (dump pipeline), 데이터와 개발 언어의 분산화(decentralized control of language and data)라는 특정 공통 특징이 있다. MSA의 근황MSA라는 새로운 용어가 등장했다. 우리는 이러한 새로운 것들을 대해 경멸적인 태도로 지나가는게 본래 성향이지만,MSA는 용어적으로 우리에게 좀 더 찾아보게하고 어필하는 소프트웨어 시스템을 ..
MSA를 채택하여 서비스를 운영시 여러가지 단점 및 관리해야하는 포인트가 있다. 서비스간 결합도가 낮아지고 각 서비스의 응집력이 높아짐는 장점이 있겠지만 오류 추적, 한 서비스에서의 에러 전파, 트랜잭션 관리( 데이터 동기화 ) 에 대한 고려가 필요하다.1. 오류 추적 서비스가 많아지고 각 서비스가 다른 서비스를 호출하고 Depth가 점점 높아짐에따라 어디서 에러가 났는지 어떤 흐름으로 진행되는지 파악하기 어렵다. 어떤 에러가 발생했을 경우 해당하는 서비스가 호출하는 다른 서비스를 확인하고 DFS 마냥 계속 계속 에러를 확인해야할 수 있다. 이러한 문제를 보완하기 위해 ZipKin을 통해 분산 서비스를 추적할 수 있다. Sentry를 통해서도 어떤 서비스에서 에러가 떨어졌는지 확인해볼 수 있을 것이다. ..

인터넷의 발전과 휴대기기의 보편화에 따라 많은 사람들이 특정 서비스를 동시에 이용하기도 하고 특정 이벤트에 의해서 트래픽이 순간적으로 몰리는 현상이 잦아진다. 즉 DAU가 증가하고 QPS가 높아짐에 따라 시스템을 좀 더 안정적이고 확장가능하며 유지보수에 용이하고 가용성이 높을 필요가 생겼다. 확장성을 높임으로서 더 많은 트래픽을 감당할 수 있고 손쉬운 유지보수를 통해 빠르게 버그를 수정하거나 기능을 추가할 수 있다. 또한 가용성을 높임으로서 사용자에게 더 나은 경험을 제공할 수 있다. 이러한 요구사항을 만족하기 위해 MSA라는 아키텍쳐가 등장했고 Spring에서 MSA에 구조에 맞게 빠르게 개발할 수 있는 다양한 라이브러리를 제공한다.간단한 Ecommerce API를 만들어 보았고 사용한 Cloud li..
Spring Cloud Bus를 위해서 cloud bus amp를 추가했는데 해당 라이브러리가implementation("org.springframework.cloud:spring-cloud-starter-bus-amqp")function context 라이브러리를 가져온다."org.springframework.cloud:spring-cloud-function-context해당 라이브러리에 kotiln 버전을 제대로 인식하지 못하는 버그가 있었다.https://github.com/spring-cloud/spring-cloud-function/issues/1218 Kotlin compilation error with spring-cloud-function 4.2.0- · Issue #1218 · sprin..
안정해시안정해시는 샤드와 같이 분산서버에 골고루 트래픽이나 데이터를 분산할때 분산이 안정적이로 이루어지게 하는 기법이다. 이때 주로 사용되는게 해시링이다. 해시링은 하나의 해시값들을 하나점으로 두고 각 점들을 통해 만든 링이라고 보면된다. 클라이언트에서 요청받은 데이터를 해싱해서 해시링에 올리고 가장 가까운 분산 서버에 저장하는 방식이다. 이때 왜 해시링을 사용하는지 궁금할 것이다. 그냥 분산서버의 개수 N으로 모듈러 연산을 하면되는거 아닌가? 모듈러 연산을 하게되면 분산서버의 개수 N에 영향을 받게된다. 분산서버는 언제든지 늘어나거나 줄을 수도 있고 특정 장애에 의해서 줄어들 수도 있다. 이때마다 모듈러의 값이 변하기 때문에 캐시히트와 캐시미스에대해 관리가 불가능해진다. 해시링을 사용하게되면 최대 해..