개발 기록

서문 이번에 회사에서 서비스 중인 앱의 AWS 인프라 비용을 절감했다. 결과부터 말하면 월간 비용을 3000만원 -> 1700만원으로 43% 감소에 성공했고, 이를 위해 쿼리 개선, 캐싱 도입, 쓸모없는 리소스 삭제 등 여러 방법을 사용했다. 물론 위 액션들을 하기 위해 어떤 부분에서 비용이 많이나오고 있고 줄일 수 있는지 분석이 필요했다. 이번 글에서는 어떻게 분석했고 계획을 수립했는지 적어보겠다. 본문 비용 절감을 위해 아래 과정들이 필요했다. 1. 회사의 전체 인프라 비용 중, 목표로 하는 서비스가 차지하는 비용 파악 2. 파악 된 비용 중, 절감이 가능한 부분 판단 3. 절감 액션 수립 단계별로 겪었던 문제와 해결한 방법을 정리해본다. 1. 회사의 전체 인프라 비용 중, 목표로 하는 서비스가 차지..

뉴스피드 시스템이란? SNS에서 팔로우중인 다른 유저가 만든 여러 피드들을 발행된 순서대로 볼 수 있는 시스템을 의미한다. 여기서 피드는 다른 유저가 생성한 스토리 뿐 아니라, 광고, 유저 상태 등 넓은 범위의 컨텐츠를 포함한다. 우선, 뉴스 피드 시스템은 피드 발행과 뉴스 피드 생성으로 나눌 수 있다. 이 글에서는 뉴스피드 시스템의 핵심인 피드 발행 부분을 살펴본다. 피드 발행 유저가 피드를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 이렇게 포스팅된 정보는 친구 목록의 뉴스 피드에 전송돼야 한다. 다음은 개략적인 피드 발행 시스템 설계안이다. 포스팅 저장 서비스 새 포스팅을 DB와 캐시에 저장하는 서비스 포스팅 전송 서비스 새 포스팅을 친구의 뉴스 피드에 푸시하는 서비스 알림 서비스 새 ..

서문 회사의 쌓여있는 기술 부채를 해결하던 중, 모든 API 응답을 Intercept 해서 transform하는 함수의 성능을 개선하는 작업을 맡게 되었다. 응답 속도가 느린 특정 API가 평균 473ms, transform은 251ms 시간을 잡아먹고 있어, 고객 경험에 불편함을 주고있었다. 또한, 응답하는 데이터가 커질수록 더욱 응답속도가 느려질 것으로 보여 시급히 해결해야하는 기술 부채였다. 개선한 결과부터 공개하면 P99 API 기준, 평균 응답속도 933.5ms 에서 495.3ms로 188% 정도 개선되었다. 이제 개선 과정에 대해 알아보자. 분석 서문에 적은 모든 API 응답을 Intercept 해서 transform하는 함수의 이름을 global interceptor라고 정의하겠다. glob..

nestJS를 써보면서 느낀점을 적어보자. 기존에 express를 사용했으므로, 자연스럽게 express와 비교해 느낀점이 많다. 토이프로젝트를 위한 속성 공부를 했고, 실무에서 사용해보지 않았기에 잘 모르거나 잘못 느낀점이 있을 수 있다. 먼저 느낀점을 나열하고 각자 상세 설명을 하겠다. 느낀점 1. 아키텍쳐 고민을 안할 수 있다. 2. 의존성 주입, 데코레이터 3. 클래스 기반 4. 작은 크기 프로젝트에 적합한가? 1. 아키텍쳐 고민을 안할 수 있다. 공식문서를 보면, nestJS의 철학 자체가 아키텍쳐에 대한 고민을 효과적으로 해결하기 위함이라고 적혀있다. 직접 사용해보면 이 철학을 몸소 체험할 수 있다. express를 사용해 개발하다보면 의 경우 가볍고 기본 기능들을 빠르게 구현하는데 목적이라는..

서문 이전 글에서 log forwarder를 마무리했다. 이번 글은 log forwarder가 포워딩한 데이터를 받아 실제로 DB or S3와 같은 오브젝트 스토리지에 저장하는 역할을 수행하는 log aggregator 구현한 경험을 기록한다. 본문 aggregator config aggregator의 config 파일을 살펴보겠다. @type forward port 24224 @type json # Mysql @type mysql_bulk host ${host} port ${port} database ${db} username ${mysqlUserName} password ${mysqlUserPassword} column_names id, datetime table ${tableName} flush_i..

서문 이전 글에서 log forwarder에서 사용하는 config 파일을 작성하는 법에 대해 알아보았다. 이번 글에서는 도커로 log forwarder를 서비스하기 위한 dockerfile 작성에 대해서 알아보자. 도커파일만 다루기에 짧은 글이 될 것이다. 본문 Dockerfile : FROM fluent/fluentd:v1.14.6-debian-1.0 USER root //install git RUN apt-get update && apt-get install -y git //clone custom plugin RUN git clone https://github.com/SehyeonGil/fluent-plugin-split-array.git //install custom plugin RUN mkdir..

서문 이전 글에서 fluentd를 도입하게 된 발단부터 설계까지 알아보았다. 이번 글에서는 설계에 나온 부분 중, log forwarder 부분을 도입하는 부분에 대한 과정을 기록하였다. forwarder는 서버내에서 생성되는 로그 및 통계 데이터를 수집하여 1차 가공하고, log aggregator로 전송하는 역할을 한다. 본문 fluentd config forwarder를 구현하기 위하여, fluentd config 파일에 관한 간단한 설명을 먼저 진행한다. fluentd는 config 파일을 수정하여 동작을 제어한다. (nginx와 유사) config 파일은 plugin들의 집합으로 이루어져 있으며, 여기서 plugin은 크게 Input, Output 두가지 종류로 구분되고, 이를 보조하는 Filt..

서문 이전 글에서 특정 시간(배치작업 실행 중)에 DB Cpu 로드율이 100%에 도달하는 현상과 이에 대한 해결책으로 단일 row insert를 bulk insert로 변경하는 것에 효과에 대해 알아보았다. 이번 글엔 bulk insert를 어떻게 서비스 내에 구현할지에 대해 고민한 과정을 기록하였다. 발단 bulk insert를 구현하는 방법을 고민해보니, 크게 2가지로 정리되었다. redis와 같은 in-memory db에 올려놨다가, 특정 시간마다 batch 작업으로 db에 bulk 로 insert log file로 object storage(s3) 또는 서버 내 저장해두었다가, 특정 시간마다 마지막 insert된 row 이후 부터 bulk insert 위의 2가지 방법에서 한가지를 선택하려고 고..