HAN STORY

🌱 개인 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..

💡 이전 글https://hanstory33.tistory.com/262 [싹틔움] 11/13 개발일지 쿠폰 발급 시 동시성 문제 해결 1 : 동시성 문제 발생 및 낙관적, 비관적,💡 목표쿠폰 300 개를 유저 1000 명이 5초동안 발급을 받기 위해 테스트를 진행했는데, 중복된 쿠폰이 발급된다든지, 수량 300 개를 넘어서서 발급이 되는 문제가 발생했다.이를 해결하기 위해서hanstory33.tistory.com 💡 목표비관적 락과 분산 캐시 시스템인 Redisson 을 이용한 분산락을 걸어 기존에 락을 걸지 않았던 방식과 비교해 Test 를 진행.  + python script 를 활용해 총 발급된 쿠폰 수와 중복된 쿠폰 코드를 확인  📝 Test : DB 낙관적 락 ( Skip )매 발급 마..

💡 목표쿠폰 300 개를 유저 1000 명이 5초동안 발급을 받기 위해 테스트를 진행했는데, 중복된 쿠폰이 발급된다든지, 수량 300 개를 넘어서서 발급이 되는 문제가 발생했다.이를 해결하기 위해서 락을 걸어 동시성 문제를 해결할 필요가 있었다.   📝 Test : 락을 적용하지 않은 상태의 동시성 문제 확인Number of Threads (users) : 1000Ramp-up period (seconds) : 5Loop Count : 1발급한 유효 쿠폰 수 : 300실제 쿠폰을 발급받은 유저 수 : 595 위 이미지와 같이 남은 쿠폰 수도 잘 줄지 않고 중복으로 발급되는 쿠폰이 많이 발생.실제로 같은 코드의 쿠폰을 발급받은 유저도 많다.응답 처리속도는 평균 약 171 ms 가 나왔다. 결론많은 트래..

💡 목표기존에 학습했던 refresh token 을 프로젝트에 적용해서 사용자 경험을 상승시키고 보안도 챙기려고 한다. https://hanstory33.tistory.com/238 [CS] ACCESS 토큰과 REFRESH 토큰💡 Refresh 토큰이 뭐에요 Access 토큰과 비교해서 알아봅시다.구분액세스 토큰리프레시 토큰역할API 호출 시 인증액세스 토큰 재발급수명짧음 ( 몇 분 ~ 몇 시간 )김 ( 며칠 ~ 수개월 )사용 위치모든hanstory33.tistory.com 위 포스트를 작성하면서 개념을 공부했기 때문에 바로 적용 들어가보도록 했다. 💡 코드 적용1. 기존 createToken 메서드가 Access Token 을 생성하는 메서드인데, 이를 createAccessToken 으로 이름..