본문 바로가기

프로젝트 삽질기23 (feat Transactional) 들어가며NestJS와 PostgreSQL, TypeORM을 활용하여 프로덕트를 만들고 있습니다. 저번 글에서 커넥션 풀 누수 문제가 발생한 장애를 해결하는 과정을 공유했는데요. 장애를 해결한 후, 팀에서 커넥션 풀 누수 문제를 더 이상 겪지 않으려면 어떻게 해야 할까 고민했습니다. 이 글을 통해 팀 내에서 트랜잭션 제어 방식을 다르게 구성한 방법을 공유하고자 합니다.            문제 원인TypeORM을 활용하면서 API를 구성할 때마다 매번 반복적으로 아래의 코드를 반복해서 작성했습니다.  constructor(private readonly dataSource?: DataSource) {}const queryRunner = this.dataSource.createQueryRunner();awai..
프로젝트 삽질기22 (feat 커넥션 풀 누수) 들어가며AWS Aurora PostgreSQL를 활용해서 서비스를 운영하고 있습니다. 성능 테스트를 하면서 Writer DB의 Connections 수가 특정 숫자 이상이 되면 커넥션을 더 이상 맺을 수 없어서 장애가 발생한다는 것을 파악했습니다. 장애를 겪을 것을 대비하여 RDS의 connections 수를 트래킹 하며 커넥션 수가 특정 개수 이상이 넘으면, slack으로 알림을 받도록 구성했습니다.  얼마 전, max connections 수가 특정 수를 넘었다는 알림을 받았습니다. 알림을 받은 이후 시간이 지나도, 커넥션 수가 떨어지지 않는 문제가 생겼습니다. 그 과정에서 팀에서는 어떤 문제를 겪었고, 이 문제를 어떻게 해결했는지 공유하고자 글을 씁니다.              RDS 커넥션 풀 누..
프로젝트 삽질기21 (feat firestore, bigQuery, functions) 들어가며NestJS와 TypeORM을 활용하여 프로덕트를 만들고 있습니다. 제가 개발하고 있는 서비스에는 채팅 기능이 존재합니다. 유저가 서비스 내에서 채팅을 할 때 생성된 데이터는 Firebase의 Firestore에 저장하고 있습니다.  한 번은, 사용자들이 언제, 어느 시간대에 채팅을 하는지와 관련된 행동 데이터를 분석하고 싶었습니다. 데이터를 분석하려면 Firestore의 데이터를 모두 조회해야 했는데, 전체 데이터를 조회하는 과정이 상당히 번거로웠습니다. 만약 Firestore에 저장된 데이터를 BigQuery로 옮긴다면, 보다 빠르고 효율적으로 채팅 데이터를 분석할 수 있다고 판단했습니다. Firestore의 데이터를 BigQuery로 옮기는 과정에서 Cloud Functions를 사용했습니다..
프로젝트 삽질기20 (feat 검색 로그 구축 4) 들어가며저번 글에서 적재한 로그 데이터를 분석하기 위한 방식에 대해 알아봤습니다. 이번 글에서는 추출한 데이터를 시각화하는 방식에 대해 정리해보려 합니다. 바로 시작하겠습니다.           데이터 시각화데이터 시각화는 위처럼 구성했습니다. Athena를 활용하여 데이터를 조회하고, 조회한 데이터를 QuickSight에서 시각화하는 방식을 구성했습니다. 그럼 QuickSight로 어떻게 데이터를 시각화하는지에 대해 알아보겠습니다.             QuickSightQuickSight는 AWS에서 제공하는 serverless managed BI 상품입니다. 여기서 BI란, Business Intelligence의 줄임말로, 데이터를 통합하고 분석해서 기업 활동에 연관된 의사결정을 돕는 프로세스입니..
프로젝트 삽질기19 (feat 검색 로그 구축 3) 들어가며저번 글에서 검색 로그 구축을 위한 AWS 환경 세팅 방식과 로그 적재 방식에 대해 알아봤습니다. 이번 글에서는 적재한 로그 데이터를 분석하기 위한 방식에 대해 정리해보려 합니다. 바로 시작하겠습니다.            데이터 분석 아키텍처데이터 분석 아키텍처는 위처럼 구성했습니다. AWS Glue Crawler를 활용하여 데이터가 모여 있는 S3버킷에 저장된 로그의 스키마를 생성했습니다. 그 후 AWS Athena를 활용하여 Glue Crawler를 활용해서 카탈로그화 한 데이터를 SQL문을 활용하여 조회하는 과정을 구축했습니다.  그럼 Glue를 활용하여 스키마를 생성하고, Athena를 활용하여 데이터를 조회하는 과정을 어떻게 구현할 수 있는지에 대해 알아보겠습니다.             ..
프로젝트 삽질기18 (feat 검색 로그 구축 2) 들어가며저번 글에서 검색 로그 구축을 위해 필요한 사전 지식을 정리했다면, 이번 글에서는 검색 로그 구축을 어떻게 할 수 있는지와 관련된 내용을 정리해보려 합니다. 바로 시작하겠습니다.              Kinesis Streams데이터 수집 아키텍처는 위와 같이 구성했습니다. 그럼 먼저 Kinesis Streams, Kinesis Firehose를 구축하고, EC2에 연결하여 데이터를 전송하는 부분에 대해 알아보겠습니다.      먼저 AWS에서 검색창에 Kinesis라고 검색하여 들어가면 위와 같은 화면이 나올 것입니다. 여기서 데이터 스트림 생성 버튼을 클릭합니다.   그 후 data stream 이름을 설정합니다. 저는 검색 로그를 저장할 것이기 때문에 search_log라고 입력하고, 용량..
프로젝트 삽질기17 (feat 검색 로그 구축 1) 들어가며육아크루 서비스가 고도화되면서, 검색 기능을 통해 동네 육아 친구를 찾고 싶어 하는 고객들이 늘었습니다. 고객이 서비스 이용에 불편함을 겪지 않도록 검색 기능을 구현해야 했습니다. 검색 기능을 구현하면서 만약 유저들이 검색 기능을 어떻게 사용하는지 분석할 수 있다면, 유저들에게 더 좋은 서비스를 만들 수 있겠다고 판단했습니다. 이를 위해 실시간으로 저장되는 검색 로그 데이터를 수집하고 저장, 가공, 분석하고 시각화하는 단계를 구축하여 팀 내에서 데이터 드리븐하게 의사결정할 수 있도록 구성했습니다.  이번 글을 시작으로 로그란 무엇이며, 팀에서는 어떻게 로그 데이터를 수집하고, 분석하며, 시각화하는지에 대한 과정에서 겪은 삽질의 경험이 담긴 글을 정리하려 합니다.         로그고객에 대한 새로..
프로젝트 삽질기16 (feat PostgreSQL 검색) 들어가며NestJS와 TypeORM을 활용하여 프로덕트를 만들고 있습니다. 특정 유저를 멘션 하는 기능을 만들기 위해, 특정 유저의 닉네임을 검색하는 시스템을 구축해야 했습니다. 검색 시스템을 구축하기 위해 ElasticSearch를 활용하여 검색 기능을 개발하고 싶었습니다. 하지만 개발 마감 기한이 촉박했고, 대량의 데이터를 검색하는 시스템이 아니었기 때문에, 당장 ES 구축을 하는 것은 오버 엔지니어링이라 판단했습니다. 오버 엔지니어링하지 않으면서 보다 빠르고, 안정적으로 검색 시스템을 구축하려면 어떻게 해야 할까 고민하면서 postgresql로 full text search를 구현했습니다. 이번 글은 PostgreSQL을 활용한 검색 시스템 구축 과정과 전략 패턴을 활용한 코드 구성 과정에서 겪은 ..
프로젝트 삽질기15 (feat 전략 패턴 활용) 들어가며NestJS와 TypeORM을 활용하여 프로덕트를 만들고 있습니다. 비즈니스 로직을 구성하는데, if else if 문이 계속해서 추가되다 보니 코드의 가독성이 좋지 못한 문제가 발생했습니다. if - else 문을 개선하기 위해 노력하면서 전략 패턴에 대해 알 수 있었습니다. 이번 글은 전략 패턴을 NestJS에 적용하기 위해 노력하면서 작성된 글입니다.        요구 사항 분석유저를 멘션 할 수 있는 기능을 개발해야 했습니다. 멘션 기능을 구성하기 위해선, 먼저 유저 닉네임 검색 시스템을 개발해야 했습니다.      예를 들어 "@검색어"를 입력했을 때, 검색어와 관련된 유저의 닉네임의 목록들이 노출되어야 했습니다. 만약 검색어를 포함하지 않고, "@"만 입력했을 경우엔, 한 번이라도 검색..
프로젝트 삽질기14 (feat 전략 패턴) 들어가며NestJS와 TypeORM을 활용하여 프로덕트를 만들고 있습니다. 비즈니스 로직을 구성하는데, if else if 문이 계속해서 추가되다 보니 코드의 가독성이 좋지 못한 문제가 발생했습니다. if - else 문을 개선하기 위해 노력하면서 전략 패턴에 대해 알 수 있었습니다. 이번 글은 전략 패턴에 대해 공부하고, 전략 패턴을 적용하기 위해 노력하면서 작성된 글입니다.        If문의 증가API를 개발하면서, 기획의 요청이 들어오면 API의 동작 방식을 계속해서 변경해야 했습니다. if문을 사용하여 API 동작을 제어했는데, 추가적인 조건들이 계속해서 들어올 때마다 if-else if 문이 점점 쌓여가는 문제가 발생했습니다. 예를 들어 조종석 Class에서 조종석의 종류에 따라 방어력이 바..