HAN STORY

💡 개요이전 글: [싹틔움] 에러로 인한 Kafka Message 전송 실패 시나리오 대비 안전 장치 고민💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형hanstory33.tistory.com 메인서버에서 Kafka 를 전송 시에 생기는 에러는 Redis 와 Outbox 패턴을 변형해 대비를 해놓았다.추가로 Kafka Message 는 전송이 되었지만 Consumer 인 알림서버에서 이 Message 를 소비하지 못 했을 때의 시나리오를 대비해 안전 장치가 필요하다고 판단했고, 이를 DLQ 와 수동 재처리 API 를 통해 해결하고자 했다. 💡 DLQ ..

💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형 구조 구현 고민2 : 재전송을 시도해도 계속해서 Sent 값이 False 인 경우는 어떻게 처리하면 좋을까?고민2 해결: Redis 도입을 통해 각 데이터별 Count 및 Webhook 연결을 통한 운영 처리 고민3 : DLQ Topic 도입을 하는 것이 좋을까?이전 글: [싹틔움] API Gateway 도입을 통한 인증 역할 분담💡 개요이전 글https://hanstory33.tistory.com/318 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요..

💡 개요이전 글 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMappinhanstory33.tistory.com 기존 클라이언트에서 알림서버에 구독을 요청하고, Feign Client 를 이용해서 메인서버로 회원 정보를 가져올 때 매 번 요청마다 인증을 하기 위해서 메인서버에 요청을 하는 방식이 오버헤드가 발생하는 부분이라고 판단했다.메인서버와 알림서버 상단에 API Gateway 를 두어서 인증을 담당하는 서버를 따로 분리하도록 설정하고자 했다. 💡 아키텍처 수정🌱 ..

💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMapping(value = "/v1/notifications/{userId}/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter subscribe(@PathVariable Long userId) { SseEmitter emitter = notificationService.subscribe(userId); 기존 방식에서는 단순히 userId 값을 param 으로 받아서 구독하고 해당 userId 로 들어오는 알림 ..

💡 목표싹틔움 서버에 Kafka 를 도입해 메인서버와 알림서버 사이에서 데이터들이 성공적으로 주고 받을 수 있고자 했다.📚 메인서버 Kafka 설정KafkaConfig더보기@Configuration@EnableKafkapublic class KafkaConfig { @Value("${app.kafka-brokers}") private String kafkaBrokers; @Bean public KafkaTemplate kafkaTemplate() { return new KafkaTemplate(producerFactory()); } @Bean public ProducerFactory producerFactory() { Map produce..

🌱 개요싹틔움 메인서버에서 알림 기능을 구현하는 서버를 따로 분리해 MSA 방식으로 구현하고자 했다. 🌱 왜 굳이 서버를 분리할까?1. 독립적인 확장성알림 기능은 사용량이 급격하게 늘어날 수 있는 부분이다. 그렇기 때문에 MSA 로 분리하면 알림 서버만 별도로 스케일 업/아웃할 수 있어 유연성이 증가한다. 2. 장애 격리알림기능에 트래픽이 몰리거나, 카카오 등 외부 API 알림 기능을 구현할 때 이 기능에서 문제가 생겨도 메인 서버에 영향을 주지 않아 안정성이 증가한다. 3. 독립적인 배포 및 개발알림 서버는 다른 주기로 배포하거나, 다른 언어나 프레임 워크로 개발이 가능해진다.  4. 유지보수 용이성관심사가 명확하게 분리되어 집중적으로 관리할 수 있고 다른 팀원들과 협업시에도 수월하다. 코드베이스가..

🌱 개인 KPT 회고KEEP, 다음 프로젝트로 가져갈 - 팀원들과 소통하는 자세, 상대방 의견을 존중하고 나와 의견이 다르다면 그냥 부정하기 보다 나의 의견을 정확하게 전달한 점- 1달 동안 개발자들의 리더의 자리에서 책임감 있게 주어진 역할을 다 해낸 점, 다음 프로젝트에서 구성원이라면 리더의 책임감을 이해할 것- Github Actions 를 활용한 CI/CD 자동화 부터 AWS 환경 구축까지 진행하며 개발 뿐만 아니라 개발 이후에 배포까지의 단계를 넓은 시야로 경험해 볼 수 있었던 점- 맡은 부분이 아니더라도 팀원들이 공부한 내용인 Kafka, elastic search 에 대한 지식을 쌓은 점 PROBLEM, 버려야 할- 처음에는 프로젝트 마일스톤을 통해 서로 진행도를 공유하고 회의를 할 때에도..

💡 목표우리 프로젝트의 인프라를 한 눈에 파악할 수 있도록 인프라 설계도를 작성해보았다.🌱 Github Actions개발자가 github 을 통해 main 브랜치에 pull request 를 하면 Github Actions 를 활용한 CI/CD 자동화를 통해 Docker hub 에 이미지가 push 되고 인스턴스에서는 이를 pull 로 당겨와 업데이트를 반영한다. 🌱 EC2메인 서버 두 대를 비롯한 알림서버, 프로젝트에 사용된 Redis, Kafka, Elastic search 는 각 각 EC2 로 띄워 Port 를 연결해주었다.데이터베이스는 AWS 에서 제공하는 RDS 서비스를 활용해서 연결해주었다. 🌱 파일 저장싹틔움 서비스에 저장되는 파일 이미지 등은 S3 에 저장된다. 🌱 Applicat..

💡 목표내 프로젝트에 ALB 설정을 했고, DNS 이름으로 접속을 하는데에는 불편함이 있기 때문에 도메인을 구매해 Amazon Route 53 서비스를 이용해 연결하기로 했다. 저렴한 도메인을 구매하고자 했기 때문에 가비아에서 .site 도메인을 구매했고 연결하려 한다. https://hanstory33.tistory.com/224 [CS] DNSppt : DNS - 프레젠테이션 (canva.com) youtube : [CS발표] DNS (youtube.com)hanstory33.tistory.com 이전에 DNS 에 대한 개념을 공부했던 경험이 있어서 이해하는데에 도움이 많이 되었다.ALB 를 연결하면 위처럼 DNS 이름이 나온다.이를 내가 구매한 도메인과 연결을 해야한다.  Route 53 서비스에..

💡 목표AWS 에서 제공하는 로드 밸런서 유형 중에 Application Load Balancer 는 들어오는 트래픽을 여러 서버로 분산시켜 서비스의 가용성과 확장성을 보장한다. 또한, HTTP/HTTPS 기반 요청의 라우팅 및 유연한 트래픽 관리 기능을 제공하기 때문에 나는 2개의 서비스 서버를 열었고, 이를 ALB 를 통해 트래픽을 분산시키고자 했다.🌱 로드 밸런서 생성 필자는 Application Load Balancer 를 생생하고자 했기 때문에 ALB 를 선택했다. 네트워크 매칭은 본인의 인스턴스가 열려있는 가용 영역에 해당하는 것을 선택해야한다.요구사항대로 2 개 이상 선택했다.  내 메인 서버 인스턴스 두 개가 8080 포트로 트래픽을 받고 있기 때문에 프로토콜 포트를 HTTP 8080 ..