후후후후

무중단 배포 도입 이유진행중인 프로젝트에서 Github Actions를 통해 CI/CD를 구축한 상태이다. main 브랜치에 merge될 때마다 자동 배포가 진행되는데, 이때 필연적으로 서버가 종료되고 다시 시작되는 시간(Downtime)이 발생했다. 최소 30초에서 길면 60초 정도가 걸렸는데, 지금은 개발기간이라 큰 문제는 없지만 이후 운영 상황에서의 이 Downtime은 사용자 경험 측면에서도 안좋고 서비스가 성장할 수록 손실이 커질 것이라 판단하여 무중단배포 도입을 결정하였다.Nginx를 선택한 이유무중단 배포를 구현하는 여러 가지 방식이 있다. Kubernetes, AWS ELB, Nginx 등K8s는 학습 비용이 높고, AWS ELB는 인스턴스를 생성, 관리(과금 위험)해야 했다. Nginx는..

무중단 배포 도입 과정과 배포 전략에 관한 내용은 Nginx , Docker, Github Actions로 무중단배포 진행 를 참고하면 된다. 1. 문제 원인 파악현재 사용중인 서버는 AWS EC2 t2.micro(프리티어)이고, 메모리는 1GB이다. 배포 전략으로 선택한 Green/Blue 는 green과 blue WAS가 동시에 실행되는 시간이 발생하며 이때 RAM  프리티어 한도인 1GB를 넘어가게 되고, 이로 인해 서버의 작동 불가로 이어졌다. 그 이유는1. 모든 메모리가 사용되면 시스템은 새로운 프로세스나 기존 프로세스를 위한 충분한 메모리를 확보할 수 없게 된다.2. 이로 인해 여러 프로세스가 제한된 메모리 자원을 놓고 경쟁하게 만들고,3. 이러한 리소스 경합은 CPU가 효율적으로 프로세스를 ..

먼저 테스트 데이터 총 500만개 (caregivers=간병인), 지역은 총 20개 지역으로 나눠서 동일한 비율로 (지역당 약 25만개씩) 더미데이터를 추가한 뒤 환자 -> 간병인 찾기 기능을 진행하였습니다.  찾기 기능을 원활하게 하려면 적절한 인덱스 설정 + 페이지네이션 구현이 필수입니다.현재 프로젝트는 무한스크롤 방식인 No-Offset 방식의 페이지네이션을 채택하였고, 동적 조건 검색을 원활히 하기 위한 Querydsl을 도입하였습니다.  하지만 구현하는 과정에서 예상치 못한 상황들을 만났고, 해결해 나간 과정을 기록하려 합니다. No-Offset 적용 방식은 여기 입니다. (정렬 복합키 해결) 먼저 프로젝트 구조에 대해 설명드릴 내용이 있습니다. 진행중인 프로젝트는 JPA InheritanceT..

프로젝트를 진행하며 검색 기능을 할 때가 되었습니다. 매칭 신청을 보내기 위해서는 먼저 상대측 리스트를 검색할 필요가 있습니다.다양한 방법이 있었고, 먼저 MySQL의 Full Text Search를 적용해보기로 하였습니다.사용자의 원활한 검색을 위해 Querydsl을 이용해 동적 검색을 할 수 있게 하고 정렬 또한 최신순, 조회순, 후기순으로 가능하도록 진행하였습니다. 1. 첫 번째 문제 발생 : Full Text Search를 하기 위해서는 Match (1)... against (2)...라는 문법을 사용하여야 합니다.  (2)-검색어에 해당하는 (1)-컬럼 을 조회하는 것입니다. 하지만 JPA은 full text search 문법을 지원하지 않습니다. 만약 사용한다면 직접 NativeQuery를 날..

지역 or 이름 or 나이 or 경력 으로 진행할 전체 검색 남음. 검색 결과 정렬도 가능해야함아마 성별은 빼고 특이사항 추가하고경력 빼고 조회수 남음 (락 학습, 도입) 조회수 구현1. redis의 hyperloglog를 이용하여 구현하기로 하였다. 왜냐하면 조회수 특성상 정확도가 100%일 필요가 없고, 기존 세션, 쿠키, ip 등으로 진행하면 단점들이 각각 존재. 특히 메모리 용량을 많이 차지함. but, hyperloglog는 매우 낮은 메모리 사용 & 정확도 100은 아니지만 상당히 일치함. 하지만 redis를 이용하는 것이다보니 redis가 이용 불가능할 시, 조회수를 이용 못함. 즉, 백업을 해두어야 함.이는 rdb로 진행을 해야 한다. 스케쥴러를 통해 하는게 좋다.   ===========..

변화에 유연하게 ! 기존에는 검색 결과 리스트 반환은 Offset-Paging 방식으로 구현했었습니다. 하지만 한 주간 회의 진행 후 , 찾기는 무한 스크롤로 변경하기로 결정이 났습니다.그 이유는 검색 결과 리스트가 화면 구조상 최대 5개 정도 밖에 나오지 않는다. => 페이지를 넘길 때 무한스크롤 방식이 편리 (기존 페이징이라면 사용자가 페이지 버튼을 일일히 눌러야 하니 사용자 경험 하락 예상) 때문이였습니다. 이렇듯 기획과 요구사항은 시시각각 달라지고, 그것을 해결하기 위해 개발자가 필요하다고 생각합니다. 코드를 계속 리팩토링 하고 구조를 개선하고 이러한 과정들은 다 이런 변화에 비교적 쉽게 대처하기 위해 진행하는 것 같습니다.  우선 커서 기반 페이지네이션을 적용하는 데 있어서 그리 쉽지만은 않았습..

OneToOne 관계에서 FetchType.LAZY는 만능이 아니다 ?!  여태까지 ToOne 관계에서 무분별한 조회를 막기 위해 default인 EAGER가 아닌 LAZY로 설정하면 프록시로 호출되기 때문에, 실제 조회 쿼리가 실행되지 않는다고 알고 있었다. 하지만, @OneToOne 양방향 관계에서, 연관관계의 주인이 아닌 테이블 조회 시, LAZY는 동작하지 않는다.그 이유는 생각해보면 단순하다. JPA에서 양방향 연관관계 설정 시에 FK는 연관관계의 주인인 테이블이 보유한다. 즉, Member와 Patient가 있고 Patient가 연관관계의 주인이라면 Patient 테이블에는 member_id가 존재하지만 Member 테이블에는 patient_id가 존재하지 않는다. 그러면 여기서 LAZY 전략..

7/1리스트 불러올 때, 원본 그대로 불러오면 당연히 용량을 너무 많이 불러옴. 이미지 리사이징을 해야하는데,나는 multipart를 사용 안하고, presigned url을 사용해서, 자바 코드로 서버에서 리사이징이 불가능함. (애초에 서버리스로 설계해서 서버를 통해 리사이징 한다는게 말이 안됨.) 그래서 aws lambda@edge를 사용해 원본 origin s3버킷에 접근해서 이미지를 받아올 때, cloud front에 캐싱이 되는데, 이 받아올 때 리사이징을 해서, cloud front에는 캐싱된 이미지를 저장하면 처음 요청시에만 좀 걸리고, 이후 요청부터는 캐싱 + 리사이징으로 인한 용량 저하로 매우 대단한 효과 나타남. !그런데 계속 안되다가,온갖 재시도 끝에 aws lambda@edge와 a..

저는 환자와 간병인이 서로를 지역, 조건에 따라 검색하고, 리스트를 찾아서 매칭 신청을 보내고 응답하는 팀프로젝트를 진행중입니다.이 과정에서 매칭 신청을 보내려면 본인의 세부 프로필이 등록이 되어있어야 한다는 조건이 있습니다.그래서 세부 프로필 등록 시, 본인의 이미지를 선택사항으로 프로필에 등록할 수 있어야 한다는 기획이 있어서이미지 등록 기능을 진행하였습니다. 고려한 이미지 등록 방법은 크게 두 가지 였습니다.1. Multipart Upload를 이용한 서버에 저장 or 외부 저장소에 저장2. Presigned URL를 이용한 외부 저장소에 클라이언트에서 직접 저장 Multipart 를 이용한 이미지 처리의 경우는 DB에 저장을 하든 외부 저장소에 저장을 하든, 결국 server에서 이미지를 받아서 ..