Search
🌐

DevOps & Develop

AWS 운영 / 설계 / 개발환경 구축 및 CI/CD
Search

지표 설명

•
% Stmts (Statements - 구문 커버리지):
•
% Branch (Branches - 분기 커버리지):
•
% Funcs (Functions - 함수 커버리지):
•
% Lines (Lines - 라인 커버리지):

jest script

jest.config.js

nestJS 프로젝트 테스트(Jest)

JSONB 데이터

위와 같이 JSONB 데이터를 저장하는 postgresql 컬럼이 있다고 가정해보자.
일반적으로 JSONB 데이터타입에서 특정 키나 경로에 대해 효율적으로 설계된 타입은 GIN(Generalized Inverted Index)이다.
해당 컬럼을 조회하는 로직은 평균적으로 1초 내 외이며 isActivated = true와 같은 방식으로 쿼리가 작성된다.

GIN 인덱스 생성

JSONB 인덱싱

도입 배경

타이어픽 서비스는 현재 .env 파일을 통해 환경변수를 관리하고 있다.
문제는 DB 정보와 연동 서비스의 API Key들도 .env를 통해 관리를 하고 있다는 점으로 Private Repository라고 해도 유출이 걱정되는 부분이 존재한다. 최근 독일 및 러시아에서 불법적인 접근이 시도 된 것을 확인하였고 DDOS를 당해 서비스가 잠시 마비가 된 사례가 존재했다.
이러한 가운데 .env 파일의 민감정보가 유출되어 고객정보까지 새어나간다면 굉장히 문제가 될 수 있다.
따라서 유출 걱정 없이 환경변수를 문제없이 관리 할 수 있도록 AWS에서는 Secret Manager 서비스를 운영하고 있다.

aws-cli 설치

가장 먼저 해야할 것은 Secret Manger 연동을 위해 PC에 aws-cli 설치 후 아래 커맨드와 함께 aws-cli 설정을 진행한다.
설정이 완료되면 아래 커맨드를 통해 현재 Secret Manager에 설정된 보안 암호들을 가져올 수 있게 된다.
AWS Secert Manager 도입

개요

캐시란 데이터를 메모리에 저장하여 빠르게 접근할 수 있는 고속 저장소이다.
자주 사용되는 데이터를 캐시에 저장하면 데이터베이스를 호출하지 않고 데이터를 빠르게 반환해줄 수 있어 조회 속도가 매우 빠르며, 데이터베이스가 크게 줄어들게 되고 서비스 성능이 향상된다.
타이어픽 서비스는 고가용성을 위해 Scale-Out하여 동일한 서버를 2대 이상 운영하고 있다.
하지만 로컬 캐시만을 사용하게 된다면 데이터 정합성 문제로 인해 서비스 운영에 문제가 발생할 여지가 있다.
이런 문제로 인해 글로벌 캐시를 사용하게 되며, 서버 내에 캐시를 저장하지 않고 모든 서버가 글로벌 캐시를 바라보게 되며 데이터 정합성 문제를 해결 할 수 있게 된다.
그렇다면 무조건 로컬 캐시가 아닌 글로벌 캐시가 유리하다라고 할 수 있는가? 라고 했을 때 다음과 같은 장점을 가지기 때문에 그렇다고도 할 수 없다.
1.
빠른 응답속도 - 글로벌 캐시도 결국 별도의 서버이기 때문에 네트워크 트래픽을 사용하게 된다.
2.
의존도가 감소한다.
그리고 어떤 저자는 이렇게 얘기하기도 한다. 굳이 글로벌 캐시를 사용하지 않아도 Eventual Consistency(최종적 일관성)으로 인해 일시적으론 불일치하지만 결과적으로 서버의 데이터는 동일하게 맞춰진다는 것
다만 Scale-In-Out 되는 분산처리 시스템 상 서버 상의 로컬 캐시가 분실될 수 있으며 배포로 인해 Task가 재배치된다면 Rolling에 의해 로컬 캐시는 분실된다.
잦은 배포와 기획전, 이벤트 등을 진행하는 타이어픽 서비스 특성상 로컬 캐시와 글로벌 캐시를 혼합하여 사용하기보다는 글로벌 캐시를 채택하게 되었다.
Cache 도입 건 - AWS Redis, Memcached, ValKey

개요

새로운 시스템과 시스템이 결합하게 되면서 MSA로의 전환이 절실히 필요해진 문제들이 다수 발생하였다. 다만 최초부터 MSA로 설계된 시스템이 아니기 때문에 전환에는 많은 공수가 들 수 밖에 없고, 각 시스템 개발 담당자들로부터의 반대 여론이 굉장히 강한 편이다. 현재 시스템이 동기적으로 연결되어 있어 의존중인 시스템이 DDOS나, 장애 발생 시 동일한 장애가 발생하게 된다. 문제는 타이어픽 서비스의 경우 고객들의 재이용률이 굉장히 낮은데다, 그 텀이 굉장히 길다 (타이어의 경우 2-3년, 엔진오일의 경우 1년 내외).
한 번 고객이 이탈하면 다시 돌아오지 않을 가능성이 굉장히 높은데. 타이어픽 서비스의 자체 장애가 아닌 외부의 장애에도 영향을 받게 되면 매출에 영향이 없을 수가 없다.
투자자들에 빠르게 결과를 보여줘야하는 스타트업의 생태계상 설계 및 기획 개발이 느슨하게 될 순 없었지만 그 당시 전반적인 아키텍처를 구성 할 수 있는 사람도 없었고, 모두의 role 자체가 굉장히 불안정할 수 밖에 없었다. 서로의 시스템에 대해 나서서 왈가왈부 할 수 없는 애매한 상황이 처했다.
그런 연유에서 당장 시스템 담당자들간의 협의를 통해 가장 위험하지만 가장 빠른 방법을 통해 두 시스템의 주문 시스템을 연동하게 되었다.
하지만 시스템을 담당하고 있는 입장에서 자식이 이미 위험한 길을 갔다고해서 방치하는 것은 개발자의 올바른 태도는 아니다.

왜 MQ를 도입해야는지?

현재 주문 프로세스를 간단하게 표현하자면, 아래와 같다.
소비자가 결제완료된 시점에 타 시스템의 API를 호출하고, 그에 대한 응답에 맞게 처리해주는 아주 간단한 프로세스로 되어있으며 타 시스템이 장애가 발생하지 않는다면 문제가 없는 구조
문제는 아래와 같이 장애가 발생한 경우 주문생성이 되기 위해서는 반드시 타 시스템 Server의 응답을 받아야한다.
이 경우는 타 시스템이 장애 대비를 얼마나 잘했느냐에 따라 무난히 넘어갈 수 있는 부분이다.
MQ 도입 건 - Kafka, Redis, RabbitMQ, SQS
Jenkins 설정완료 화면

도입배경

간단하게 설명하자면 젠킨스는 빌드 및 배포를 자동화해주는 툴이다.
AWS에서도 비슷한 역할을 하는 서비스를 제공하고 있지만, 모든 것은 유료로 제공된다.
개인적으로 사이드 프로젝트를 위해 AWS를 유지하고 사용하기가 어렵다고 판단이 되어서 모든 운용중인 서버를 로컬 서버로 옮기게 되었다.
이러한 과정에서 기존의 GitHub와 AWS 연동을 통해 CI/CD를 구성해두었던 부분은 전부 들어내고 젠킨스를 도입하게 되었다.

목적

CI/CD 자동화를 통해 배포와 빌드를 자동화하는 것은 좋지만
모든 것을 자동화하는 것은 적지않은 공부가 필요하다.
사이드프로젝트 수준에서만 자동화 할 목적이고, 처음 세팅은 간결하기 위해 아래의 구성만 진행하기로 하였다.
•
Jenkins-GitHub 연동을 통해 커밋된 Repository를 불러와 시스템에 지속적인 배포 설정
•
Jenkins-Docker 연동을 통해 특정 Repository는 Docker Container로 배포되도록 설정
Docker, Jenkins, GitHub를 활용한 CI/CD 파이프라인 구성
스트리밍 영상을 텍스트로 바꾸기 위해서는 많은 밑작업이 필요한데.
가장 먼저 대상이 되는 스트리밍을 골라야한다.
대표적으로 Youtbue, Netflix, Watcha 등 수많은 스트리밍이 있지만, 네이버 스트리밍 플랫폼인 치지직의 영상을 받아와 스트리머의 목소리를 텍스트로 표현하는 간단한 태스크를 진행해보려고 한다.
네이버의 경우 스트리밍을 HLS 프로토콜을 사용하여 주고받고 있다.
여기서 HLS란게 무엇인지 알아야 효율적으로 원하는 오디오를 추출해올 수 있다.

그래서 HLS가 뭔데?

HLS는 HTTP LIVE STREAMING의 약자로서 Adaptive Bitrate Streaming을 지원하는 기술이다.
현대에 들어서 가장 많이 사용하는 비디오 스트리밍 프로토콜로서 라이브 환경에서의 최적화가 되어있는 프로토콜이다.
과거에 이 프로토콜이 없을 시절은 Progressive Download 방식을 사용했다.
이 방식은 이름 그대로 동영상 파일 전체를 통으로 받아서 다운로드가 완료되면 시청이 가능한 방식이다. 가장 쉬운 예로는 토렌트, 토렌트는 다운로드 받는 중에는 동영상을 시청 할 수 없다. 가장 원시적인 형태의 다운로드 방식으로 이러한 방식은 전체 파일을 다운로드하기 때문에, 네트워크 트래픽을 많이 발생시키는 문제와 실시간으로 영상을 시청하기에는 무리한 구조로서 HLS라는 방식을 사용하게 되었다. (그 와 비슷한 구조로 RTSP, RTMP 등의 프로토콜이 있으나 현재 기술적 한계와 보안 등 이슈로 HLS는 가장 널리 사용되고 있다)

HLS의 구조와 방식

HLS 파일의 구조는 크게 primary playlist(index file)와 media playlist(alternate index file), 그리고 segmented file로 나눈다.
스트리밍을 텍스트로 (치지직, openai-whi)

Docker Pipeline 플러그인 설치

Docker Pipeline을 찾아서 설치해준다.
Jenkins Docker Build 자동화
Mac Studio를 메인으로 서버 구성을 하고 있는데
재부팅이 될 때마다 서버 내의 Docker가 중단되는 이슈가 있다.
아래와 같이 재부팅 시에도 Docker가 실행되도록 변경
아래 명령어를 통해 현재 실행중인 컨테이너에도 restart 옵션을 추가해줄 수 있다.
[mac] Docker Container 자동실행

Dockerfile이란?

Docker에서 Image를 Build하고 Container를 생성하면 우리는 해당 Container 에 필요한 라이브러리들을 설치하게 된다. 이미지 종류에 따라 내장되어있는 라이브러리가 다르기 때문에 설치해야하는 라이브러리도 매 번 다르다.
나의 경우에도 컨테이너를 생성하고나면 항상 하는 일이 있다.
docker에서 제공하는 Dockerfile을 사용하면 반복되는 작업을 image 빌드단계에서 미리 설정해둘 수 있다.
위 명령어를 자동화하기 위해서는 아래와 같이 Dockerfile을 작성해준다.

Dockerfile 작성

Dockerfile을 작성하면 그 경로로 이동 후 아래 명령어를 입력하면 이미지가 생성되어 있고
실제로 컨테이너를 생성하고 접속해보면 위의 명령어로 이미 라이브러리들이 설치된 것도 확인 할 수 있다.
Dockerfile을 통해 Build하기

1. 도입 배경

•
스트리밍 플랫폼에서 채팅을 수집하고 분석하는 시스템을 구축하고 있었다.
•
채널별 오디오 데이터도 함께 수집하여 Whisper 모델로 변환하고, 이를 기반으로 추가 분석을 하고자 했다.

2. 초기 문제 인식

•
오디오 파일이 매우 많이 쌓일 예정이었다. (하루 약 15만 건 예상)
•
파일 저장을 위해 고민했는데, NestJS 서버 로컬에 저장하는 방식은 확장성과 관리 측면에서 한계가 명확했다.
•
클라우드 스토리지(AWS S3)를 검토했지만

3. 대안 탐색

•
자체 S3 호환 스토리지를 구축할 방법을 검토했다.
•
대표적인 오픈소스 솔루션으로 MinIO를 발견했다.
•
MinIO는
S3 연동 가능한 분산 스토리지 MinIO 구축

도입 배경

1. 데이터 증가 문제

•
하루 약 400MB 수준의 채팅 데이터가 지속적으로 쌓임
•
단일 테이블에 모든 데이터를 저장할 경우:

2. 조회 패턴 최적화 필요

•
채팅 데이터는 대부분 최근 기간을 기준으로 조회
•
오래된 데이터는 조회 빈도가 급격히 낮음
•
특정 기간(1일~10일 등) 범위로 조회하는 경우가 많음
•
전체 데이터가 아니라 "필요한 기간 데이터"만 빠르게 조회해야 했다

3. 운영 및 유지보수 편의성 확보

•
오래된 데이터는 쉽게 삭제하거나 백업하고 싶었음
•
월별로 데이터 관리 단위를 나누면:

4. 대안 검토 결과

PostgreSQL 월별 파티셔닝 전략 정리
Docker + PostgreSQL을 외장 HDD에 마운트해서 운영했을 때 발생한 성능 병목과 개선 시사점 정리

실험 목적

•
실제 환경에서 외장 HDD를 Docker Volume으로 활용할 때 성능 병목을 체감
•
SSD가 아닌 조건에서도 병목을 예측/완화할 수 있는 구조적 대안 도출
•
Whisper + PostgreSQL + MinIO 조합의 실제 성능 한계 확인

실험 환경

•
Docker Compose
•
Docker Volume
•
기타 구성

체감된 병목 현상

병목 원인 분석

•
HDD는 랜덤 쓰기 성능이 극히 낮음 (IOPS 수백 수준)
•
PostgreSQL은 fsync, WAL, heap write 등 디스크 쓰기 중심
•
MinIO도 동시에 파일 쓰기를 하면서 I/O queue 충돌
HDD 환경에서 PostgreSQL 실험 기록

도입 배경

•
PostgreSQL에서 컬럼/테이블명에 camelCase를 사용하면 내부적으로 "큰따옴표"로 감싸지지 않으면 에러 발생
•
현재 코드에서 chatChannelId, createdAt 등 camelCase 컬럼명을 그대로 사용하고 있었고, 그에 따라 쿼리 작성 시 "channelChatLog"."chatChannelId" 같은 따옴표를 반드시 사용해야 하는 상황 발생

문제점 정리

•
SQL 쿼리 작성 시 항상 큰따옴표를 써야 해서 불편
•
쿼리 툴에서 자동완성/탭 완성 제대로 안 됨
•
일부 raw query 실행 시 대소문자 이슈로 휴먼에러 빈번하게 발생
•
TypeORM 마이그레이션이나 View, Index, Function 등 연동 시 혼란 ( idx_channelChatLog_chatChannelId 와 같은 혼란스러운 네이밍… )

해결 전략

•
TypeORM의 @Column({ name: '...' }) 매핑 방식으로 DB는 snake_case, 코드는 camelCase 유지
•
커스텀 NamingStrategy 도입 → SnakeNamingStrategy
TypeORM snake_case 도입 및 camelCase 회귀 결정 기록