Juno's daily

저는 8월 12일 부로 협업툴 B2B 서비스를 운영하는 회사에 근무하게 되었습니다.근황에 대해 짧게 이야기 하자면, 2주간의 온보딩을 마치고 과제를 받아 진행중입니다.✔️ Overview저는 개발을 학습해 오면서 널리쓰이는 DBMS인 MySQL을 주로 사용/학습을 진행 해 왔습니다.제 회사에서는 단일 DB로 PostgreSQL을 사용하는데, 이때 까지 학습한 RDBMS인 MySQL과의 차이점에 대해 기술해 보고자 합니다! :) [차이점 1️⃣] INDEX🐬 MySQLMySQL은 primary index를 테이블 당 반드시 하나 존재합니다. (지정 하지 않으면 MySQL InnoDB 스토리지 엔진이 자동 생성합니다)primary key를 기준으로 primary index가 생성되며, 이는 clusered..

금칙어 필터링 기능을 분석하고 리팩토링 해보자!(1)지난 포스팅에서 나는 기존 팀원이 짜놓은 코드를 리팩토링 했다.단순 라이브러리를 이해하고 리팩토링 한 것 뿐아니라, 파일로 읽던 금칙어 목록들을 DB로 이전시켰다. 📂 파일로 금칙어를 읽어 처리하는데의 문제점파일로 금칙어를 읽으면 몇가지 불편한 문제점이 발생했다. [문제점 1] 금칙어 목록을 Continuous Delivery 과정에서 jar 파일 뿐 아니라 금칙어 파일도 S3에 같이 저장해줘야 했다. 그래야 application 실행 시점에 메모리에 읽을 수 있으니깐.[문제점 2] 금칙어를 추가하거나, 삭제하려면 다시 배포를 해야한다. 그러면, 서브모듈 관리도 해야하고, 버전 관리에 금칙어 텍스트 파일 관리가 포함되게 된다.따라서, 코드가 아닌 단순..

👀 OverviewSpace club 프로젝트를 진행할 당시, 각 클럽 별 게시글을 작성하거나 공지, 댓글등을 작성할 때 금칙어가 포함되어 있을 경우 아래 그림과 같이 작성에 실패했다는 모달을 보여주며 작성에 실패하게 처리를 했었다.이때, 입력받는 값에 금칙어를 찾는 과정에 있어서 Trie 자료구조를 사용했는데, 그때의 생각프로세스를 정리해 보고자 한다.또한, 현재 프로젝트 코드레벨에서의 문제점은 없는지 고쳐 보려 한다.🔭 자료구조 / 알고리즘 선택하기!먼저 우리는 지금 구현해야하는것이 특정 문자열이 주어졌을 때, 해당 문자열에 금칙어가 포함되어 있는지 여부를 확인하고 싶다.먼저, 금칙어를 List 자료구조로 저장해 놓고 비교를 한다면, 금칙어 List 크기가 N이고, 입력받는 문자열의 길이가 M일때..

진행한지 꽤 되었지만, 늦은 프로젝트 회고를 진행해 보려고 한다.늦게 진행하는 이유는 조금씩 리팩토링을 진행한게, 이제서야 거의 끝맺음을 지은 것 같기 때문이다.1️⃣ 프로젝트는 어떤 프로젝트였는지?https://github.com/Space-Club/Backend GitHub - Space-Club/Backend: Backend Repository For Space ClubBackend Repository For Space Club. Contribute to Space-Club/Backend development by creating an account on GitHub.github.com누구나 동아리를 쉽게 만들고, 관리하며, 행사를 주최할 수 있는 서비스를 만들었다.https://spaceclub...

Overview 현재 space club 프로젝트를 리팩토링 하며 하나하나 뜯어 고치는 중이다. 프로젝트때 나는 인프라 부분을 맡지 않았다. 팀원 중 한명이 인프라에 관심을 가지고 있던 친구여서 모든 백엔드 환경을 잘 구성해 줬었기에 스프링 애플리케이션 개발에만 집중할 수 있었다. 하지만 리팩토링을 진행하면서 좀 더 나은 방식을 적용할 수 있겠다는 생각이 들었고 이 모든 것을 바로잡고 블로그 글을 쓰기 까지 총 일주일이 넘는 시간이 걸렸다. 내가 이번에 프로젝트 리팩토링을 진행하면서 겪은 문제점은 두 가지이다. 1️⃣ HTTPS 설정 시, EC2에 Application Load Balancer를 통한 과금 문제 2️⃣ CI/CD 중 배포 문제 2-1. CI/CD 중 불필요한 파일이 S3에 업로드 되는 문..

👀 Overview Shared Lock과 Exclusive Lock은 S-Lock, X-Lock이라고도 하며, (읽기 락, 쓰기 락), (공유 락, 배타 락)이라고 불리기도 한다. 하지만 이 lock에 대한 내용을 학습하면서 여러 블로그들을 찾아봤는데, 잘못된 내용들이 정말 많았다! 그래서 그 내용들을 실제 내가 MySQL 쿼리를 통해 비교하면서 바로잡고, 파헤쳐 보기 위해서 글을 써야겠다는 결심을 했다. 🔐Shared Lock과 Exclusive Lock 먼저 앞 글에서도 언급했지만, InnoDB 스토리지 엔진 레벨에서의 Lock을 설명하면서 Shared Lock, Exclusive Lock의 개념이 나왔다. 특정 row에 lock을 걸면 레코드락, 여러 row에 range로 lock을 걸면 넥스크 ..

👀 Overview스페이스 클럽 프로젝트를 진행하면서, 아래와 같이 클럽에서 행사를 개최할때, 공연 카테고리의 행사를 신청하면 선착순 기능을 제공해야 했다.그래서 아래와 같이 행사 개최자가 최대 정원(아래는 100명)을 설정해 놓으면, 예매 장수를 선택해 신청을 해야 했다.그리고 정원이 없는 행사인 경우 최대 999명까지 받을 수 있도록 정책을 설정했었다.이때 발생할 수 있는 문제점이 동시성 문제가 발생할 수 있었다.따라서 행사를 신청하고 취소할때 동시성문제가 발생하지 않도록, 비관적 락(Pessimistic lock)을 사용해 동시성 문제를 해결하였다.그리고 api 호출 시 신청이 불가한 경우 발생한 스프링 예외를 변환해서 프론트에게 전달해 주었다. 프로젝트를 진행할 때는, 일단 lock의 여러 방법..

👀 Overview 나는 포민(포장의 민족) 프로젝트에서 사장님 서버에서 가게 도메인과 메뉴 도메인을 맡았다. 포장의 민족 프로젝트에서의 특이점이라고 한다면, 고객팀과 사장팀이 각각 서버를 나누고, 서버를 나눴으니 DB 또한 각각 나눠 진행을 했다. 그랬기 때문에, 해당 사장 서버의 DB와 고객 서버의 DB의 정합성을 맞추는 것이 핵심이였고 항상 사장 서버에서 자원이 생성되거나 변경될 때 마다 고객팀 서버로 정보를 전송해 주어야 했다. 따라서 아래와 같이 InfoSender 빈을 통해서 RestTemplate을 통해 정보를 고객팀 서버로 전달했다. @Component @RequiredArgsConstructor public class InfoSender { private final RestTemplate..