HAN STORY

🐷 문제 상황사용자가 지역을 검색했을 때 현재 로직은 Kakao 를 통해 해당 지역의 카페 리스트를 불러오고 이를 기반으로 OpenAI 가 추천 카페 리스트를 반환한다. 하지만 매번 Kakao api, OpenAI api 호출을 하면 비용적인 문제와 응답속도 면에서 아쉬움이 있었다.사용자가 매번 검색을 할 때마다 추천 리스트가 바뀌는 것 역시 사용자 입장에서 이 리스트가 진짜로 추천이 된 리스트일까? 하는 의문이 들 수 있다고도 판단했고, 7일의 TTL 설정이라면 주변 카페 최신화에도 문제가 없을 것이라 생각해 이를 구현해보았다. 동일한 키워드로 여러 사용자가 검색할 때도 매번 Kakao, OpenAI 호출OpenAI 응답 시간: 평균 2.5~5초하루 500~1000건 이상의 검색 발생 → 비용 증가,..

🐷 UpstashRedis 를 프로젝트에 붙이기로 했을 때 여러 선택지가 있었다. ( Docker, 로컬 설치 등등 )하지만 기존 배포 환경을 고려했을 때 서버리스 환경에서 vercel 로 배포가 되어있는 만큼 Redis 를 HTTP 기반 서버리스 환경에서도 쓸 수 있도록 최적화 되어있는 Upstash 를 이용해 Redis Cloud 를 사용하기로 했다. 🐷 TLS 에러인기 검색어 기능을 위해 Redis 를 연결했는데, npm run dev 후 서버에서 검색 API 를 호출하자마자 에러가 발생했다. ❗ 원인처음에 Redis 연결을 위해 .env.local 파일에 아래와 같이 접속 주소만 넣었다.REDIS_URL=redis://:비밀번호@gorgeous-wren-38298.upstash.io:6379..

💡 개요이전 글: [싹틔움] 에러로 인한 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. 유지보수 용이성관심사가 명확하게 분리되어 집중적으로 관리할 수 있고 다른 팀원들과 협업시에도 수월하다. 코드베이스가..

📚 개요기존에 구현했던 방식인 아티클 생성 후에 태그들이 생성되어도 사용자 관심도를 계산하기 위해서 태그들간의 유사도를 계산하는 로직이 들어가지 않는 한 사용자가 그 전에 게시글과 상호작용을 하여도 관심도를 계산할 수가 없다.그렇다고 유사도를 측정하는 로직을 넣자니, 시간이 오래 걸리기 때문에 한계가 있었다. 📚 고민* 클러스터링 기반 접근 태그를 사전에 클러스터링해서 새 태그를 클러스터에 매핑. 사용자 관심도도 클러스터 단위로 관리 (?)세부 과정:초기 클러스터링:태그를 메인 카테고리(예: "스포츠")별로 나눠 클러스터 생성(예: "축구 클러스터", "농구 클러스터").Tag_Clusters에 저장.새 태그 처리:기존 클러스터와 비교 → 유사하면 배정, 아니면 Temp_Tags에 임시 저장.새벽에 ..

📚 Article 작성 로직 고민  💡 현재 로직:아티클 생성 (3.62s) → 태그 5개 및 아티클과의 연관성 분석 및 테이블 생성 (9.16s)   → 기존 태그들과의 유사도 분석 및 테이블 생성 (1m 30s) 문제: 시간이 많이 걸린다. 1. 우선 태그를 5개에서 3개로 줄여야겠다. ai 가 5개를 뽑으면서 태그가 너무 다양해지고 의미는 같고 단어만 조금 다른 태그들이 생겼다. 2. 연관성 분석을 꼭 해야할까? 라는 생각을 했다. 어차피 연관이 있는 태그를 ai 가 뽑아주는건데 그걸 수치화로 더 자세히 할 필요가 있을까. 3. 기존 태그들을 전체 조회하면서 생성된 태그들과의 유사도를 분석하고 저장하는 로직을 게시글 등록과는 분리시켜야겠다. 시간이 많이 걸리고 이는 점점 태그가 많아질수록 증가될..