HAN STORY

[싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결

💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @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 ..

💡 목표우리의 프로젝트에 쓰인 Redis, Kafka, elasticsearch 를 EC2 에 띄워서 메인 서버와 연결시켜야했다.기존 메인 서버에 Docker compose 를 설치해서 메인 서버와 함께 Redis, Kafka, elasticsearch 를 실행시키고자 했다.🌱 Docker compose 설치sudo su관리자 모드 실행 apt-get update인스턴스 패키지 목록 업데이트 sudo curl -L "https://github.com/docker/compose/releases/download/v2.20.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composeDocker compose 바이너리 다운로드 chmo..

💡 목표기존에 싹틔움 서버를 EC2 에 띄웠었다.하지만 이후 서비스를 배포하다가 그 하나의 서버에 문제가 발생하면 사용자들은 나의 서비스를 사용하지 못할 것이다.때문에 확장성, 고가용성, 안정성을 위해 동일한 서버 하나를 더 열기로 했다.🌱 인스턴스 생성인스턴스 이름을 설정해준다. 기존 서버와 동일하게 ubuntu 환경의 인스턴스를 만들기로 했다.  기존에 사용한 키페어와 보안그룹을 사용했다.기존 서버와 동일하게 다른 Redis, Kafka, Elasticsearch 서버와 연결되어야하기 때문에 동일하게 설정을 해주었다.  인스턴스가 정상적으로 열렸다.  메모장 파일을 끌어서 git bash 에 넣어도 해당 EC2 로 접근이 되게 하기 위해서 해당 명령어를 넣은 메모장을 만들었고위 처럼 접근을 했다...

💡 목표CI/CD 자동화를 통해 main 브랜치로 Pull Request 가 이루어지면 자동으로 배포까지 되도록 설정하고자 했다.  DockerFileFROM amazoncorretto:17-alpine-jdkEXPOSE 8080ARG JAR_FILE=build/libs/*.jarCOPY ${JAR_FILE} app.jarENTRYPOINT ["java", "-jar", "app.jar"] Github Actions 를 사용하기 위해서 Docker File 을 만들어준다. CICD.ymlname: CI/CDon: pull_request: branches: ["main"]jobs: build: runs-on: ubuntu-latest steps: - name: Checkout..