기술적 고민

KTX의 빈자리 알림을 보내주는 서비스를 개발하고 있습니다.  개요저희 서비스에서는 KTX의 열차 시간표를 공공 API를 통해 가져옵니다.공공 API의 제약 조건은 다음과 같습니다.1. 요청 날짜로부터 일주일 후 열차 시간표 까지 가져올 수 있습니다.2. 출발 기차역, 도착 기차역, 출발 날짜가 모두 같은 경우 한꺼번에 데이터를 가져올수 있습니다. 그래서 저희는 매일 새벽마다 그 다음 날 열차 정보를 가져와서 DB에 삽입 해야했고, 이 작업은 배치 서버에서 수행되었습니다.  첫번째 시도 : 최대한 많은 데이터를 한번에 공공 API를 통해 가져옴먼저 공공 API와 통신에 드는 시간인 IO 비용을 최대한으로 줄이기 위해, 출발 기차역, 도착 기차역, 출발 날짜가 모두 같은 경우 데이터를 한번에 다 가져오도록..
Flyway란?Flyway는 데이터베이스 스키마를 버전 관리하고 마이그레이션을 관리하는 도구입니다.(저는 간단하게 Git의 데이터베이스 버전이라고 생각했습니다.)SQL 파일로 마이그레이션 스크립트를 정의하고, Flyway가 이를 순차적으로 실행하여 데이터베이스 구조를 업데이트 합니다. Flyway를 통해 변경 사항을 추적하거나, DB 구조 변경 과 롤백을 보다 쉽게 할 수 있습니다. Flyway를 적용한 이유지금 프로젝트에 Flyway를 적용한 이유는 다음과 같습니다. (개요)저희 서비스는 서버가 실행 함과 동시에 약 10만개의 데이터를 DB에 넣는 배치 작업이 이루어지는데, DB 구조가 변경될때 마다 ddl-auto를 create로 설정하여 모든 데이터를 날리고 다시 삽입 하는 것은 굉장히 비효율적이었..
KTX의 빈자리 알림을 보내주는 서비스를 개발하고 있습니다.  개요사용자가 즐겨찾기 한 열차 티켓의 여석이 생겼을 때, 알림을 보내는 기능은 저희 서비스의 핵심 기능입니다.또한 성능과 안정성이 굉장히 중요합니다. 알림 속도가 몇 초만 늦어도 다른 사용자에게 좌석을 빼앗길 수 있기 때문입니다. 그래서 성능을 최대한 좋게 하기 위한 방법들을 생각해 냈습니다. 기능 동작 방식여석 알림을 보내주는 기능은 다음과 같은 순서로 이루어 집니다. 1. 현재 시각 이후, 아직 유저에게 알림을 보내지 않은 모든 즐겨찾기 티켓을 조회합니다. 2. 같은 티켓을 여러명이 즐겨찾기 한 경우, 동시에 사용자들에게 알림을 보내야 공정하다고 생각하여 티켓과 해당 티켓을 즐겨찾기한 사용자 목록을 매핑하는 데이터 구조인 Map>을 만듭니..
KTX의 빈자리 알림을 보내주는 서비스를 개발하고 있습니다.  개요크롤링을 해서 데이터를 가져 온 후 어떻게 하면 사용자에게 빠르게 전달 할수 있을까 고민하며 쓴 글입니다.  서버 분리우선 나는 크롤러 서버와 일반 서버를 분리 해야한다고 생각했다. 그 이유는1. 크롤러는 많은 네트워크 IO 작업과 CPU 리소스를 소비 함으로 일반 서버와 함께 하면 크롤러로 인한 서버 성능 저하가 전체 서비스 성능 저하로 이루어질수 있다.2. 크롤러 서버를 분리 하고, 만약 크롤러 서버가 죽는다면 서비스에 직접 보여지는 부분은 타격을 입지 않게 할수 있다. 왜냐하면 서비스에 직접 보여지는 부분은 DB에 저장된 열차 정보이기 때문이다. 크롤러 서버가 죽음으로써 생기는 이슈는 실시간으로 가져오던 여석 정보를 못가져와서 내부 ..
개요작년 SW마에스트로를 통해 개발자 사이드 프로젝트 팀 매칭 플랫폼을 만들었는데, 유저가 모이지 않고 클라우드 비용이 만만치 않아 운영을 중지 했었다. 그런데 최근에 프로젝트 기획을 조금 바꾸어 다른 방향으로 서비스를 하자는 좋은 제안이 들어왔고 SW마에스트로의 지원이 중지 된 지금 클라우드 비용 최적화를 하고자 한다. + 현재 AWS에서 스타트업 창업 패키지로 1000$을 2년동안 지원 받은 상태이고, 한정된 비용으로 최대한 오래 서비스를 유지하기 위해 작년에 비용이 저렴할 것이라고 예상했지만 통수를 씨게 맞았던 DynamoDB 부터 마이그레이션 하기로 결정 하였다. 아래 링크는 내가 작년에 했던 고민이다.2023.10.21 - [SW마에스트로] - [SW마에스트로] 채팅 기능을 만들면서 하는 고민(..
개요현재 개발자 사이드 프로젝트 팀 매칭 플랫폼을 리뉴얼 하고 있으며 SW 마에스트로의 금전 지원이 끊긴 지금 AWS 비용 을 최적화 해야 했다.  Github Action 선정 이유작년 SW 마에스트로의 지원이 빵빵 할때는 Jenkins를 이용하여 팀원분께서 CI/CD를 구축 하셨었다.하지만 지원이 없는 지금 Jenkins는 EC2 한대를 더 올려야 사용이 가능했기 때문에 이 가격을 줄이고자 나는 다른 CI/CD 툴을 찾아 나섰다.CI/CD 툴에는 여러가지가 있었다.Github ActionsJenkinsCircle CITravis CI등등난 이중에서도 현업에서 많이 사용하고, 무료로 사용할 수 있고, 빌드용 서버가 따로 필요없는 Github Actions를 활용하기로 결정하였다. 프로젝트 파일의 최상..
현재 개발자 사이드 프로젝트 팀 매칭을 하고 매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 개요 1차 배포때 모니터링 시스템이 없어서 EC2 콘솔로 로그를 확인하였었는데 너무 불편하였다. 똑같은 실수를 방지하고자 최종 배포 때는 모니터링 시스템을 부착하고자 한다. 모니터링 서비스 종류 모니터링 서비스에는 엄청 여러가지가 있었다. ELK (ElasticSearch + LogStash + Kibana) Sentry DataDog Prometheus + grafana cloudwatch 등등.. 엄청 많았다. 이중에서 현 상황에 적합한 기술을 찾고자 한다. 모니터링 서비스 비교 우선 모니터링 서비스는 크게 로그 모니터링과 서버 모니터링 으로 나뉘는것 같았다 로그 모니터링은 에러나 사용자가 남기..
- 문제 상황 - 원래는 MySQL을 사용하고 있었는데 채팅 메세지를 적재하기 위해서 NoSQL인 DynamoDB를 연결했다. 그런데 연결만 했을 뿐인데 에러가 빵빵 터졌다. 에러 메세지를 보니 약간 Bean이 중복(?)되는 느낌인거 같았다. - 해결 - 구글링 결과 JPA의 경우 default로 SpringBoot가 실행되면 컴포넌트 스캔으로 전체 패키지를 돌아 Entity와 Jpa를 사용하는 DAO단을 빈에 올린다. 그런데 DynamoDB랑 충돌이 일어난 것이었다. 그래서 우선 JPA를 사용하는 패키지와 DynamoDB를 사용하는 패키지를 분리하였다. @RequiredArgsConstructor @Configuration @EnableJpaRepositories(basePackages = {"com...
생선묵김치찌개
'기술적 고민' 카테고리의 글 목록