왈왈이의 기술블로그

gRPC 알아보기

왈왈디 — Mon, 16 Mar 2026 01:27:57 +0900

gRPC란 무엇인가

서버 개발을 하다 보면 결국 같은 문제에 부딪힌다.

“서버끼리 어떻게 대화할까?”

앱 → 서버

서버 → 다른 서버

서버 → 분석 시스템

이 모든 통신에는 방식이 필요하다. 우리가 가장 익숙한 방식은 REST API다.

하지만 규모가 커지면 REST가 조금 버거워지는 순간이 온다.

이때 자주 등장하는 기술이 gRPC다.

먼저 REST부터 생각해보자

대부분의 서비스는 이런 식으로 동작한다.

앱이 서버에 요청을 보낸다.

POST /login
{
  "email": "user@email.com",
  "password": "1234"
}

서버는 JSON을 읽고 처리한 뒤 응답을 보낸다.

{
  "success": true,
  "user_id": 1234
}

이 방식의 특징은 다음과 같다.

HTTP 사용
JSON 데이터
URL 기반 API

이게 바로 REST API다.

많은 서비스가 이 방식으로 잘 돌아간다.

그런데 서비스가 커지면 문제가 하나 생긴다.

서버끼리 통신이 많아진다.

예를 들어 이런 구조다.

API 서버
  ├ 유저 서비스
  ├ 결제 서비스
  ├ 포인트 서비스
  └ 어뷰징 탐지 서비스

이 모든 서버가 서로 REST API로 통신하면 다음 문제가 생긴다.

JSON이 커서 느림
HTTP 요청 비용 증가
API 관리 복잡

그래서 등장한 것이 gRPC다.

gRPC를 한 문장으로 설명하면

gRPC는

“다른 서버의 함수를 직접 호출하는 것처럼 통신하는 기술”이다.

REST는 이런 느낌이다.

URL 요청 → 서버 처리

gRPC는 이런 느낌이다.

함수 호출 → 서버 실행

예를 들어 서버에 이런 기능이 있다고 생각해보자.

Fraud 검사

REST 방식이라면 이렇게 호출한다.

POST /fraud/check
{
  "user_id": 123,
  "ip": "1.2.3.4"
}

gRPC에서는 이렇게 된다.

FraudService.Check(user_id, ip)

마치 다른 서버의 함수를 호출하는 느낌이다.

그래서 이름도 RPC (Remote Procedure Call)다.

Remote = 원격

Procedure Call = 함수 호출

즉

원격 서버의 함수를 호출하는 방식

gRPC가 빠른 이유

여기에는 기술적인 이유가 있다.

1. JSON 대신 Protobuf 사용

REST는 보통 JSON을 사용한다.

{
  "user_id": 123,
  "ip": "1.2.3.4"
}

gRPC는 Protocol Buffers (protobuf) 라는 형식을 사용한다.

이건 바이너리 데이터다.

장점은

데이터 크기가 작다
파싱 속도가 빠르다

즉 네트워크 비용이 줄어든다.

2. HTTP/2 사용

REST는 보통 HTTP/1.1을 사용한다.

gRPC는 HTTP/2를 사용한다.

HTTP/2는 다음 기능이 있다.

하나의 연결에서 여러 요청 처리
헤더 압축
스트리밍

그래서 대량 요청 처리에 유리하다.

gRPC는 어떻게 사용하는가

gRPC는 먼저 서비스 정의 파일을 만든다.

이 파일을 proto 파일이라고 한다.

예시:

service FraudService {
  rpc CheckFraud (FraudRequest) returns (FraudResponse);
}

message FraudRequest {
  string user_id = 1;
  string ip = 2;
}

message FraudResponse {
  int32 risk_score = 1;
}

이걸 보면 구조가 보인다.

FraudService
   └ CheckFraud()

즉

CheckFraud라는 함수를 원격 서버에서 실행한다.

그리고 놀라운 부분이 하나 있다.

이 proto 파일을 기반으로

서버 코드
클라이언트 코드

를 자동 생성한다.

그래서 개발자는 이렇게 사용한다.

fraudClient.CheckFraud(request)

이렇게 하면 내부적으로 gRPC 요청이 날아간다.

gRPC는 언제 사용하는가

gRPC는 주로 서버끼리 통신할 때 사용한다.

대표적인 예는 마이크로서비스 구조다.

API Server
   ├ User Service
   ├ Payment Service
   ├ Point Service
   └ Fraud Service

이 서비스들이 서로 통신해야 한다.

이때 gRPC를 사용하면

빠르고
타입 안전하고
관리가 쉽다

그래서

대형 서비스들이 많이 사용한다.

예를 들어

Google
Netflix
Square
Cloudflare

같은 회사들이 내부 통신에 사용한다.

어뷰징 방지 시스템에서 gRPC

어뷰징 탐지는 속도가 중요하다.

예를 들어 이런 상황이다.

유저가 포인트를 적립한다.

유저 행동
   ↓
API 서버
   ↓
어뷰징 검사
   ↓
허용 / 차단

이 과정이 느리면 서비스가 느려진다.

그래서 보통 어뷰징 로직을 별도 서비스로 분리한다.

API Server
   ↓
Fraud Detection Service

이때 gRPC를 사용하면

응답 속도 빠름
많은 요청 처리 가능
서비스 구조 분리

장점이 생긴다.

특히 이런 작업에 잘 맞는다.

Risk score 계산
IP 평판 검사
디바이스 검사
이메일 위험도 검사

정리

gRPC를 한 문장으로 다시 정리하면 이렇다.

“서버끼리 빠르게 함수 호출 방식으로 통신하는 기술”

REST와 비교하면

항목	REST	gRPC
데이터	JSON	Protobuf
속도	보통	빠름
통신 방식	URL	함수 호출
주 사용처	외부 API	내부 서비스

그래서 대부분의 시스템은 이렇게 구성된다.

외부 API → REST
내부 서비스 → gRPC

즉

외부에는 REST, 내부에는 gRPC

이 구조가 가장 흔하다.

흥미로운 사실 하나.

Google 내부에서는 오래전부터 RPC 기반 시스템을 사용해왔다.

gRPC는 그 연구의 공개 버전이다.

대규모 시스템에서는 결국 같은 결론에 도달한다.

“네트워크가 느리다.”

그래서 사람들은 계속해서

더 빠른 통신 방법을 발명한다.

gRPC도 그 진화의 한 단계다.

K집안 기술 탐구 - Kafka, Kubernetes, Kinesis

왈왈디 — Sun, 4 Jan 2026 22:48:05 +0900

K로 시작한다는 점 외에는 공통점이 없는 세 기술.

Kafka
Kubernetes
Kinesis

직접 사용해본 적이 없고, K로 시작하는 이름때문에 자꾸 헷갈려서

각 기술들의 정의, 운영 주체, 등장 배경, 역할, 사용 사례, 유사 경쟁 기술을 정리해보려고 한다.

Apache Kafka

정의

Kafka는 분산 이벤트 스트리밍 플랫폼이다.

대량의 이벤트를 순서대로, 오래, 안전하게 저장하고 전달하는 로그 시스템이다.

Kafka의 핵심 아이디어는 "시스템에서 일어난 모든 일을 로그로 남기자."

이 로그를 여러 소비자가 각자 필요에 맞게 읽는다.

운영 주체

오픈 소스 프로젝트로, Apache Software Foundation이 관리한다.

Confluent 등 다수의 기업이 상용 배포와 운영 지원을 하고 있다.

등장 배경

Kafka는 LinkedIn 내부 문제에서 출발했다.

2010년대 초반, Linked In은 아래와 같은 문제에 직면했다.

서비스 곳곳에서 이벤트 로그가 폭발적으로 발생
각 팀이 각자 로그 파이프라인을 만들어 관리
데이터 유실, 순서 꼬임, 재처리 불가능 문제 반복

이로 인해 모든 "이벤트를 하나의 신뢰 가능한 로그로 모으자"는 니즈가 발생했다.

이에 따라 Kafka는 처음부터

메시지 큐가 아니라, 분산 커밋 로그(distributed commit log)로 설계되었다.

이게 지금 kafka가 "재처리 기능", "순서 보장"에 집착하는 이유다.

역할

Kafka의 역할은

이벤트를 append-only 로그로 저장
이벤트 순서 보장
여러 consumer가 독립적으로 읽을 수 있게 제공
장애 발생 시 데이터 유실 없이 복구 가능

Kafka는 처리를 하는 것이 아니라, 기록하고 전달하는 역할이다.

사용 사례

Kafka는 백엔드와 데이터팀의 경계면에 자주 위치된다.

클릭, 노출, 결제 포인트 적립 등의 이벤트 로그 수집
하나의 이벤트를 아래 서비스들이 각각 다르게 소비해야 할 때
- 정산 시스템
- 어뷰징 방지
- 통계 집계
- 실시간 알림
재처리(replay)가 필요한 데이터 파이프라인

유사 경쟁 기술

RabbitMQ

전통적인 메시지 브로커로 작업 큐에 강점이 있다.

Apache Pulsar

Kafka 대체를 목표로 하는 스트리밍 플랫폼이다.

Amazon MSK

Kafka를 AWS가 관리해주는 형태다.

Kafka는 지금도 가장 널리 쓰이는 이벤트 로그 표준에 가깝다.

Kubernetes

정의

kubernetes는 컨테이너 기반 애플리케이션 오케스트레이션 시스템이다.

컨테이너를 대규모로 안정적으로 운영하기 위한 플랫폼이다.

Kubernetes로 관리할 수 있는 것은 "이 애플리케이션을 언제, 어디서, 몇 개로, 어떻게 살려둘 것인가" 이다.

운영 주체

오픈 소스 프로젝트로 처음 만든 회사는 Google이지만, 현재는 CNCF(Cloud Native Computing Foundation)가 공식 관리 주체이다.

CNCF는 리눅스 재단 산하의 중립적인 오픈소스 재단으로, 특정 기업이 마음대로 끌고 갈 수 없게 하는 장치다.

등장 배경

Google 내부에서 10년 이상 검증된 운영 철학의 공개판이라고 할 수 있다.

Google은 오래전부터 Borg, Omega 라는 내부 컨테이너 관리 시스템을 운영하고 있었다.

이 시스템들이 해결한 문제는 수십만 개의 프로세스를 사람이 관리할 수 없다는 것이었다.

Kubernetes는 Borg의 개념을 정리해

컨테이너
선언형 상태 관리
자동 복구

라는 형태로 외부에 공개한 결과물이다.

즉, Kubernetes는 처음부터 개발 도구가 아니라 운영 도구였다.

역할

Kubernetes의 관심사는 운영이다.

컨테이너 실행 및 종료
장애 발생 시 자동 재기동
트래픽 분산
오토스케일링
무중단 배포

Kubernetes는 애플리케이션 내부 로직을 전혀 모른다.

HTTP 서버든, 배치 작업이든, Kafka Consumer든 그냥 컨테이너로 취급한다.

사용 사례

Kubernetes가 필수인 팀은 아래와 같다.

마이크로서비스 구조
트래픽 변동이 큰 서비스
수십~수백 개의 서버를 사람 손으로 관리하기 어려운 환경
배포 안정성이 중요한 서비스

Kubernetes는 개발 속도보다 운영 안정성을 극적으로 높이는 도구다.

유사 경쟁 기술

Docker Swarm

Docker 자체 오케스트레이션이다.

Apache Mesos

범용 클러스터 리소스 관리자다.

Nomad(HashiCorp)

단순한 워크로드 오케스트레이터다.

현재는 사실상 Kubernetes가 표준이 되었다.

Amazon Kinesis

정의

Kinesis는 AWS에서 제공하는 완전관리형 실시간 데이터 스트리밍 서비스다.

Kafka와 같은 문제를 풀지만, 운영을 AWS가 대신한다는 점이 핵심이다.

서버를 띄우지 않고,

클러스터를 관리하지 않아도,

바로 스트림을 쓸 수 있다.

운영 주체

Amazon Web Services에서 운영하는 완전 관리형 서비스(Closed source)다.

등장 배경

AWS의 문제 의식은

고객들이 로그를 실시간으로 모으고 싶어한다.
Kafka의 운영 난이도가 높다.
AWS 서비스와 자연스럽게 연결되어야 한다.

그래서 아래와 같이 설계되었다.

서버 관리 없음
AWS IAM, S3, Redshift와 즉시 연동
운영 세부 사항은 사용자에게 숨김

즉, Kinesis는 스트리밍을 쓰고 싶지만 스트리밍 시스템을 운영하고 싶진 않은 사용자를 위해 탄생했다.

역할

대량 이벤트 스트림 수집
실시간 처리 또는 저장소로 전달
AWS 서비스와 즉시 연동

Kinesis는 내부적으로 여러 컴포넌트로 나뉜다.

Data Streams: 실시간 스트림 처리
Firehose: S3, Redshift 등으로 자동 적재

사용 사례

인프라가 100% AWS인 경우
운영 인력이 제한적
로그를 바로 S3 혹은 Redshift로 쌓고 싶은 경우
빠른 구축이 중요한 프로젝트

Kinesis는 유연성보다 관리 편의성에 최적화된 선택이다.

유사 경쟁 기술

Google Pub/Sub

GCP의 완전관리형 메시징/스트리밍 서비스다.

Azure Event Hubs

Azure의 스트리밍 플랫폼이다.

Apache Kafka

자유도가 높고 책임도 크다.

Kinesis는 AWS 생태계 최적화형 선택지다.

IP주소로 알 수 있는 정보

왈왈디 — Sun, 21 Dec 2025 23:31:13 +0900

IP 주소는 인터넷 세계의 “발신 흔적”이다.

하지만 흔적이라고 해서 지문처럼 정확하다고 생각하면 곤란하다.

어뷰징 방지 관점에서 IP는 강력한 단서이면서도 단독 증거로는 항상 부족한 신호다.

IP 주소로 무엇을 알 수 있고, 무엇은 알 수 없는지를 정리해보자.

IP주소로 알수 있는 정보와 알 수 없는 정보

IP 주소로 확실히 알 수 있는 것

국가·대륙 단위의 위치

IP 주소는 대체로 국가 수준의 위치 정보를 제공한다. MaxMind, IP2Location 같은 상용 DB 기준으로 보면 국가 정확도는 꽤 높은 편이다.

다만 “서울/부산” 같은 도시 단위는 통계적 추정일 뿐이며, 모바일 환경에서는 오차가 급격히 커진다.

어뷰징 방지에서는 이 정보를 이렇게 쓴다.

서비스 허용 국가 / 차단 국가 판단
비정상 트래픽 국가 급증 감지
계정 생성 국가와 이후 행동 국가 불일치 탐지

네트워크 유형 (모바일 / 고정 / 데이터센터)

IP를 보면 대략적인 네트워크 성격은 파악 가능하다.

통신사 LTE/5G
가정용 ISP
클라우드·데이터센터

어뷰징 방지에서 이건 꽤 쓸모 있다.

예를 들어 “모바일 앱인데 데이터센터 IP에서 대량 요청”은 그 자체로 이상 징후다.

반대로 모바일 IP라고 해서 무조건 안전하다고 믿는 것도 위험하다. 프록시·테더링·에뮬레이터는 항상 이 경계를 흐린다.

ASN (Autonomous System Number)

ASN은 IP가 어떤 네트워크 사업자 소속인지를 알려준다.

이건 국가 정보보다 더 안정적인 신호인 경우가 많다.

실무에서는 이런 패턴을 자주 본다.

특정 ASN에서만 반복적으로 어뷰징 발생
국가가 달라도 동일 ASN 클러스터 형성
신규 ASN 등장 후 비정상 트래픽 급증

그래서 IP 문자열 자체보다 ASN 단위 집계가 더 의미 있는 경우도 많다.

IP 주소로 추정할 수는 있지만 위험한 것

실제 사용자 위치

IP 위치 = 사용자 위치는 아니다.

특히 모바일 환경에서는

기지국 위치
통신사 NAT
트래픽 라우팅 경로
이런 요소 때문에 물리적 위치와 쉽게 어긋난다.

어뷰징 분석에서 “IP가 한국이니까 한국 사용자”라는 결론은 단독으로 쓰면 거의 항상 오판으로 이어진다.

동일인 여부

같은 IP = 같은 사람

이 공식은 거의 항상 틀린다.

회사·학교·카페 Wi-Fi
통신사 NAT
가족 단위 네트워크

반대로, 같은 사람인데 IP는 계속 바뀌는 경우가 모바일에서는 훨씬 흔하다.

그래서 IP는 “동일인 판별”이 아니라 동시성·군집성 신호로 쓰는 게 맞다.

IP 주소로 알 수 없는 것

개인 신원

이름, 전화번호, 정확한 주소는 IP만으로 알 수 없다.

IP는 개인 식별 정보라기보다 네트워크 식별자에 가깝다.

법적 요청이나 통신사 협조 없이는 개인 단위 추적은 불가능하고, 일반 서비스에서는 시도할 이유도 없다.

디바이스 고유성

IP는 디바이스를 식별하지 않는다.

디바이스 단위 어뷰징 탐지는 IP가 아니라

디바이스 지문
OS/앱 무결성 신호
계정 행동 패턴

같은 것들의 조합 문제다.

어뷰징 방지에서 IP를 사용하는 방식

IP는 1차 필터가 아니라 보조 신호다
단일 IP 차단은 효과보다 부작용이 크다
국가/ASN/네트워크 유형 단위의 집계와 패턴이 핵심이다
계정, 디바이스, 행동 로그와 항상 결합해야 한다

IP만 보고 “이건 어뷰저다”라고 말하는 순간, 정상 유저도 함께 맞는다.

반대로 IP를 완전히 무시하면, 값싼 대량 공격을 초기에 걸러낼 기회를 잃는다.

VPN 사용 여부 판별법

vpnapi.io 같은 서비스는 IP를 보고 vpn 사용 여부를 어떻게 판별할까.

IP 하나만 보고 ‘확정’하는 게 아니라, 여러 간접 신호를 겹쳐서 확률적으로 판단한다. IP는 단서 묶음의 출발점일 뿐이다.

아래는 실제로 쓰이는 방법들이다.

ASN·네트워크 소속 분석 (가장 기본)

IP는 항상 특정 ASN(Autonomous System) 에 속한다.

문제는 VPN 사업자들이 정체를 숨기지 않는 경우가 많다는 점이다.

예를 들면:

“이 ASN은 역사적으로 VPN/Proxy 트래픽이 90% 이상”
“데이터센터 전용 ASN인데 모바일 앱 요청이 계속 옴”

이건 추측이 아니라 누적 관측 결과다.

vpnapi.io 같은 서비스는 “이 ASN은 VPN 성향”이라는 사전 확률(prior) 을 이미 갖고 있다.

중요한 점:

→ IP 하나가 아니라 ASN 전체가 신호다.

데이터센터 IP 여부 (Residential vs DC)

VPN 서버 대부분은:

AWS / GCP / Azure
Hetzner, OVH, DigitalOcean
같은 데이터센터 IP 대역에 있다.

그래서 이런 판단이 가능해진다.

모바일 앱인데 → 데이터센터 IP
개인 유저 행동인데 → 서버형 네트워크

이건 오탐도 있다.

회사 Wi-Fi, 학교, 일부 ISP는 DC처럼 보이기도 한다.

그래서 단독 판단은 안 쓰고 점수로만 반영한다.

IP 재사용 패턴 (강력한 신호)

VPN IP의 특징:

짧은 시간에 수십~수백 명이 공유
국가·디바이스·OS가 뒤섞임
계정 생성/로그인 이벤트가 몰림

vpnapi.io는 이런 패턴을 본다.

동일 IP에서 서로 다른 국가 계정 생성
동일 IP에서 User-Agent 다양성 폭증
세션 길이가 비정상적으로 짧거나 균일

이건 “IP가 VPN 같다”가 아니라

“이 IP는 사람이 쓰는 방식이 아니다”라는 판단이다.

포트·라우팅·네트워크 지문

좀 더 네트워크 쪽으로 들어가면:

특정 포트 패턴 (OpenVPN / WireGuard 계열)
RTT(왕복 지연) 분포
TTL(Time To Live) 특성
라우팅 경로의 비정상적인 단순화

이건 단일 서비스가 직접 측정한다기보다,

여러 소스에서 수집된 네트워크 관측 데이터를 결합한 결과다.

상호 참조 데이터 (Crowd Intelligence)

vpnapi.io 같은 서비스는 보통 단독으로 판단하지 않는다.

다른 보안 업체
봇 방어 서비스
광고 트래픽 필터
과거 고객들의 차단 결과

즉, “우리 고객 300곳 중 180곳에서 이 IP를 VPN으로 봤다”

와 같은 집단 지성이 작동한다.

이건 기술이라기보다 통계와 네트워크 효과다.

왜 “100% 정확”하지 않은지

이 구조상 한계가 명확하다.

통신사 NAT + 해외 로밍 → VPN처럼 보임
회사 VPN → 개인 VPN과 구분 어려움
신규 VPN IP → 초반엔 탐지 안 됨
주거용 프록시(residential proxy) → 거의 정상처럼 보임

이건 판결문이 아니라 참고 자료다.

어뷰징 방지 관점에서의 정리

VPN 여부는 차단 조건이 아니라 가중치
IP 기반 VPN 판별은 단독 사용 금지
디바이스 무결성, 계정 히스토리, 행동 패턴과 결합 필수
“VPN 쓴다 = 어뷰저”는 거의 항상 잘못된 명제

ASN 더 알아보기

ASN이란

ASN(Autonomous System Number) 은

“이 IP 대역을 내가 운영한다”고 인터넷 전체에 선언한 네트워크 사업자의 고유 번호다.

통신사, 클라우드 사업자, 대형 기업 네트워크는 각자 ASN을 갖고 있고

IP는 항상 어떤 ASN 소속인지가 정해져 있다.

그걸 누가, 어떻게 정하나

이건 중앙집권적 데이터가 아니다.

인터넷은 BGP(Border Gateway Protocol) 라는 분산 합의 시스템으로 돌아간다.

과정은 대략 이렇다.

네트워크 사업자가 IP 대역을 확보
“이 IP들은 우리 ASN이 라우팅한다”라고 BGP로 전 세계에 광고
다른 네트워크들이 그 광고를 받아 라우팅 테이블에 반영
결과적으로
IP → ASN 매핑이 전 세계적으로 합의됨

그래서 ASN 정보는:

실시간에 가깝고
위조가 거의 불가능하며
VPN 업체도 마음대로 숨기기 어렵다

IP로 ASN을 알아내는 방법

기술적으로는 매우 단순하다.

IP를 입력한다
BGP 라우팅 테이블을 조회한다
그 IP를 광고한 ASN을 반환한다

이 데이터는:

글로벌 라우터
RIR(지역 인터넷 등록 기관)
BGP 수집 프로젝트

같은 곳에서 공개적으로 수집된다.

vpnapi.io 같은 서비스는

“IP → ASN”을 직접 계산하거나, 신뢰 가능한 BGP 스냅샷 DB를 사용한다.

ASN으로 구별 가능한 것

여기서부터 어뷰징 방지에 의미가 생긴다.

통신사 vs 데이터센터

모바일/가정용 ISP ASN
→ 사용자 네트워크 성격
클라우드·IDC ASN
→ 서버 네트워크 성격

이건 IP 문자열보다 훨씬 안정적이다.

IP는 바뀌어도 ASN은 잘 안 바뀐다.

“VPN 냄새” 나는 ASN

VPN 사업자들은 보통:

자체 ASN을 갖거나
특정 데이터센터 ASN을 장기간 사용한다

그래서 이런 히스토리가 쌓인다.

이 ASN에서 나오는 트래픽의 80%가 VPN 판정
이 ASN은 여러 국가 IP를 동시에 광고
일반 사용자 서비스에서 비정상 비율 과다

이건 “의심”이 아니라 관측 통계다.

국가보다 강한 신호가 되는 이유

국가는 바뀔 수 있다.

해외 로밍
위성 인터넷
라우팅 우회

ASN은 훨씬 덜 흔들린다.

한국 통신사 ASN은 계속 한국 통신사다
AWS ASN은 어디서 써도 AWS다

그래서 실무에서는:

"국가 + ASN 조합"이

국가 단독보다 훨씬 강한 신호다.

그런데 왜 ASN만으로도 부족한가

중요한 한계가 있다.

주거용 프록시는 정상 ISP ASN을 그대로 쓴다
회사 VPN은 정상 ASN처럼 보인다
대기업 내부 트래픽은 데이터센터처럼 보일 수 있다

즉, ASN은 “정체”를 말해주지 “의도”를 말해주진 않는다.

그래서 ASN은:

차단 조건 ❌
가중치 신호 ⭕
집계·군집 분석 ⭕

이 포지션이 가장 안전하다.

빅쿼리 알아보기

왈왈디 — Sun, 7 Dec 2025 21:45:47 +0900

빅쿼리(BigQuery)는 어떤 DB인가?

서비스가 성장할수록 데이터는 폭발적으로 늘어난다.

트랜잭션 처리(DB에 기록하는 것)는 MySQL·PostgreSQL 같은 RDB로 충분하지만,

데이터 분석(대량 데이터 집계·리포팅)을 같은 DB에서 처리하기 시작하면 금방 한계가 보인다.

이 지점에서 등장하는 대표적인 선택지가 Google BigQuery다.

SQL 문법을 사용하지만, 내부 구조와 목적은 우리가 익숙한 RDBMS와 다르다.

BigQuery는 트랜잭션 DB가 아니다

가장 먼저 짚어야 하는 사실:

BigQuery는 MySQL/PostgreSQL 같은 트랜잭션 DB(OLTP)가 아니다.

BigQuery는 대규모 데이터 분석을 위해 설계된 컬럼 기반 데이터 웨어하우스(OLAP)다.

목적 자체가 다르다.

목적도구

사용자 로그인/주문/결제 등 실시간 트랜잭션 처리	MySQL, PostgreSQL
수억·수십억 건 데이터에서 집계/패턴 분석/리포팅	BigQuery

업무적으로 구분하면 이렇게 된다:

애플리케이션은 MySQL에서 데이터를 기록하고
분석 플랫폼은 BigQuery에서 데이터를 읽고 요약한다

BigQuery가 빠른 이유: 컬럼형 저장과 병렬 처리

BigQuery는 데이터를 컬럼 단위로 저장한다.

예를 들어 country, created_at, revenue 3개의 컬럼이 있을 때,

revenue만 집계하는 쿼리는 해당 컬럼만 읽는다.

일반 RDBMS(행 기반 저장)와 다르게

불필요한 컬럼 읽지 않아도 되므로 속도도 빨라지고 비용도 줄어든다.

또한 BigQuery는 기본적으로 병렬 분산 처리가 자동이다.

노드 수를 설정하거나 확장할 필요가 없다.

데이터가 많아질수록 내부에서 그냥 더 큰 클러스터를 붙여 처리한다.

집약하면 BigQuery의 성능 비밀은 두 가지다:

컬럼 기반 저장
자동 병렬 처리

서버를 운영할 필요가 없다

MySQL을 운영하면 고민해야 하는 것:

CPU/메모리 스펙
인덱스 최적화
쿼리 튜닝
샤딩 확장
스토리지 관리

BigQuery는 전부 필요 없다.

서버리스다. 스토리지도 컴퓨팅도 구글이 알아서 확장한다.

사용자가 신경 쓸 건 오직 두 가지:

데이터를 넣는다
SQL을 날린다

BigQuery 비용 모델: 저장은 싸고, 조회가 비싸다

다른 DB들과 확연히 다른 부분.

저장 비용 → 저렴함
쿼리 비용 → 스캔한 데이터 양 기준으로 과금

그래서 아래가 실무에서 흔한 최적화 포인트다:

SELECT * 금지
파티션 / 클러스터 사용
필요한 컬럼만 스캔
FILTER 조건을 파티션키에 맞춰 설계
미리 집계한 마트(mart) 테이블 운용

MySQL처럼 CPU 점유율로 장애가 오는 게 아니라

BigQuery는 비효율적인 쿼리 = 비용 폭탄의 문제가 생긴다.

파티션과 클러스터는 선택이 아니라 필수

BigQuery 성능/비용을 결정하는 가장 핵심 개념.

파티션(partition): 테이블을 날짜/범주 기준으로 물리적으로 잘라두는 기능
클러스터(cluster): 파티션 내부를 특정 컬럼 기준으로 정렬해두는 기능

예시:

created_at 기준으로 파티션
파티션 내부를 country, platform으로 클러스터링

이렇게 설계하면

WHERE created_at >= '2025-12-01'
AND country = 'US'

같은 쿼리는 스캔량이 극적으로 줄어든다.

BigQuery를 쓰면 좋은 시나리오

아래 중 하나라도 해당하면 BigQuery는 적합하다.

GA(Google Analytics)4 로그 분석
플레이어/유저 행동 데이터 분석
광고/매출 리포팅
리텐션/코호트 분석
통합 로그 데이터 레이크 구축
머신러닝/추천 시스템용 대량 데이터 피쳐 생성

일반 RDBMS는 데이터를 기록하기 위한 DB이고

BigQuery는 규모가 커진 데이터를 읽고 가공하기 위한 DB다.

BigQuery를 적대적으로 대해야 하는 상황도 있다

장점만 있는 건 아니다.

실시간 트랜잭션 업데이트·JOIN이 많으면 부적합
UPDATE/DELETE가 상대적으로 느리고 비용도 큼
조인 테이블 수가 지나치게 많을 때 비효율적
개발자가 비용 개념 없이 쿼리 작성하면 바로 폭탄

빅쿼리는 도구가 아니라 _전략_이다.

“그냥 SQL 비슷하네”라고 접근하면 손해보기 쉽다.

결론

빅쿼리는 MySQL을 대체하는 DB가 아니다.

MySQL 이후 데이터가 커졌을 때 해결하는 DB다.

SQL을 지원하지만 내부 방식은 완전히 다르다
저장은 싸고, 읽는 게 비싸다
파티션/클러스터 제대로 설계하면 비용과 속도가 갈린다
분석/리포팅/머신러닝 기반 데이터 파이프라인에 최적화된 플랫폼이다

데이터 기반 비즈니스를 운영한다면

어느 시점에서든 BigQuery를 이해하고 활용할 줄 아는 능력은 선택이 아니라 필수가 된다.

구글 Play Integrity API로 안드로이드 악성 사용자 차단하기

왈왈디 — Sun, 12 Oct 2025 23:32:51 +0900

배경

모바일 리워드 앱은 사용자 보상 구조상 “정상 사용자 vs 자동화/매크로/다계정 유저 등의 어뷰저” 간의 싸움이 항상 존재한다.

특히 글로벌 시장(예: 미국, 캐나다 등)에서는

한국과 달리 본인 인증 수단이 약하기 때문에 디바이스 단위의 보안 중요하다.

구글 Play Integrity API는 구글에서 제공하는 안드로이드 보안 도구로, 앱과 디바이스의 무결성을 확인해 악성 사용자(루팅 디바이스, 클론 앱 사용자 등)를 식별하고 차단하는 데 활용할 수 있다.

서비스에 이 API를 어떻게 활용해 어뷰저를 차단하고, 어떤 값들을 어떤 방식으로 활용할 수 있는지 알아보자.

Play Integrity API란?

Play Integrity API는 사용자의 디바이스와 앱이 정상적인 환경에서 실행되고 있는지 확인할 수 있도록 구글이 제공하는 보안 API이다.

디바이스 루팅 여부, 앱 위변조, 인증 상태 등을 체크할 수 있으며, 클라이언트가 발급한 토큰을 서버에서 검증하는 구조입니다.

주요 기능

디바이스 무결성 검사 (루팅, 에뮬레이터 등)
앱 무결성 검사 (APK 위변조, 비공식 설치 등)
앱 라이선스 상태 확인
요청 유효성 검증 (nonce, timestamp)

사용 흐름 요약

클라이언트 앱에서 integrityToken을 생성
해당 토큰을 백엔드 서버에 전달
서버는 Google API에 토큰 검증 요청
Google이 반환한 Payload(JSON) 을 바탕으로 유저 차단 여부 판단

응답 Payload 주요 프로퍼티

1. deviceIntegrity

디바이스의 무결성 수준

각 값의 의미

MEETS_DEVICE_INTEGRITY	정상 디바이스 (루팅/에뮬 아님)
MEETS_BASIC_INTEGRITY	기본 무결성은 충족 (루팅 추정됨)
NO_INTEGRITY	루팅/에뮬레이터/위조 환경일 가능성 높음

2. appIntegrity

앱의 설치 상태 및 서명 정보

각 값의 의미

PLAY_RECOGNIZED	Play 서명으로 설치된 앱
UNRECOGNIZED_VERSION	비공식 빌드 or 변경된 APK
UNEVALUATED	평가 불가 (일시적 오류)

3. accountDetails.appLicensingVerdict

앱 라이선스 검증 결과

각 값의 의미

LICENSED	정상 사용자
UNLICENSED	Play Store 외부 설치 사용자 (불법 복제 가능성 포함)
UNKNOWN	평가 불가

4. requestDetails

요청의 상세 정보

requestPackageName: 클라이언트에서 설정한 패키지명
nonce: 요청 위변조 방지를 위한 임의 문자열
timestampMillis: 토큰 발급 시각 (UTC)

실무 적용 시 고려할 것들

1. 어떤 시점에 API를 호출할 것인가?

로그인 시점 또는 앱 실행 초기
- 너무 잦은 호출은 비용 낭비
- 신뢰 수준 높은 시점에 1회 호출하는 것이 일반적

2. 차단 기준 설정하기

예시:

if (
  response.deviceIntegrity.includes("NO_INTEGRITY") ||
  response.appIntegrity === "UNRECOGNIZED_VERSION"
) {
  blockUser("Integrity policy violation")
}

블락 외에도 모니터링, 기능 제한, 추가 인증 요구 등 유연한 대응이 가능

3. 비용 정책

계정별 일일 무료 호출 한도가 정해져 있음
초과 시 비용 청구됨

4. 보안 강화 팁

nonce는 서버에서 생성하여 클라이언트에 전달 (Replay 방지)
결과 토큰은 반드시 서버에서 검증
검증 실패 시(유효하지 않거나 디코드 불가) → 차단 or 로깅

흔한 실수 & 주의사항

클라이언트에서만 검증	무의미. 반드시 서버에서 검증해야 함
nonce를 사용하지 않음	동일 토큰 재사용 가능성 생김
결과 로그 저장 안 함	분석/이슈 대응 시 어려움
모든 NO_INTEGRITY를 블락	오탐 가능성 있음 (기업용 디바이스, 일부 개발자 환경 등)

테스트 방법

루팅된 디바이스, 에뮬레이터, 클론 앱 등 다양한 환경에서 테스트 필요
Play Integrity 응답은 Google 서버에서 평가되므로, 일부 결과는 수 분 지연 가능

분석에 활용 가능한 항목

일일 무결성 실패율 (NO_INTEGRITY 비율)
앱 무결성 위반률 (UNRECOGNIZED_VERSION)
requestHash, IP, Device ID 기반 다계정 시도 탐지
Integrity 응답 결과 기반 사용자 클러스터링

참고 자료

Google Play Integrity API 공식 문서

Play Integrity API 개요 | Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. Play Integrity API 개요 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Play Integrity API를 사용하면 사용자

developer.android.com

Promise.all() VS Promise.allSettled() 비동기 작업 실행하기

왈왈디 — Sun, 14 Sep 2025 23:19:35 +0900

배경

배치 작업에 작업 실패 시 경보를 추가하는 작업을 진행했다.

그런데 Promise.allSettled() 메서드를 실행하면서 이 구문을 try catch로 묶어 처리하는 코드를 발견했다.

Promise.allSettled()는 병렬 작업 중 에러가 발생하더라도 호출부에서 에러가 throw 되지 않는다.

비동기 작업 처리를 위해 흔히 사용되는 Promise.all()과 Promise.allSettled()에 대해 알아보자.

Promise.all()

Promsie.all()은 일반적으로 다음 코드를 실행하기 전에, 서로 연관된 비동기 작업 여러 개가 모두 실행되어야 할 때 사용된다.

결과값으로 실행된 프로미스들의 결과값을 담은 배열을 반환한다.

결과값의 순서는 매개변수로 전달된 프로미스 순서와 동일하다.

// 비동기 함수 예시
function fetchUser(id) {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve({ id, name: `User${id}` });
    }, 1000 * id); // id에 따라 응답 속도를 다르게
  });
}

// 여러 유저 정보 가져오기
async function getUsers() {
  const promises = [fetchUser(1), fetchUser(2), fetchUser(3)];

  try {
    // 모든 요청이 끝날 때까지 기다림
    const results = await Promise.all(promises);
    console.log("모든 유저 정보:", results);
	// 모든 유저 정보: [ {id:1, name:"User1"}, {id:2, name:"User2"}, {id:3, name:"User3"} ] 
  } catch (error) {
    console.error("에러 발생:", error);
  }
}

getUsers();

Promise.all()은 인자로 들어온 프로미스 중 하나라도 거부 당하면 (에러 발생)
Promise.all은 즉시 거부하여 catch 구문으로 넘어가게 된다.

다만 여기서 주의할 점은 Promise.all()이 reject 상태가 되었다고 해서, 인자의 프로미스 작업들이 모두 중단되는 것은 아니다.

각 작업들은 비동기적으로 여전히 진행되고, Promise.all()만 에러를 반환하며 catch 구문으로 넘어가는 것이다.

Promise.allSettled()

이와 달리 Promise.allSettled()는 인자로 들어온 프로미스들을 모두 실행하거나, 거부한 후

그 프로미스 결과 객체들을 담은 배열을 반환한다.

일반적으로 서로의 성공/실패 여부와 관계없이 여러 비동기 작업을 실행해야 하거나,

항상 각 프로미스의 결과를 알고 싶을 때 사용한다.

(Promise.all()은 서로 연관된 작업을 수행하거나, 하나라도 거부 당했을 때 즉시 거부하고 싶을 때 적합하다.)

반환된 결과 객체는 status 프로퍼티를 갖는다.

status 값에 따라서 값이 "fulfilled" 라면 value 프로퍼티를

"rejected" 라면 reason 프로퍼티를 갖는다.

value, reason을 통해서 프로미스가 어떻게 실행/거부 됐는지 알 수 있다.

Promise.allSettled([
  Promise.resolve(33),
  new Promise((resolve) => setTimeout(() => resolve(66), 0)),
  99,
  Promise.reject(new Error("an error")),
]).then((values) => console.log(values));

// [
//   {status: "fulfilled", value: 33},
//   {status: "fulfilled", value: 66},
//   {status: "fulfilled", value: 99},
//   {status: "rejected",  reason: Error: an error}
// ]

async 함수로 표현하면 아래와 같다.

async function successTask() {
  return "성공 결과"; // resolve("성공 결과")와 같음
}

async function failTask() {
  throw new Error("실패 발생!"); // reject(new Error(...))와 같음
}

async function run() {
  const tasks = [successTask(), failTask(), Promise.resolve(123), Promise.reject("단순 실패")];

  const results = await Promise.allSettled(tasks);

  results.forEach((result, index) => {
    if (result.status === "fulfilled") {
      console.log(`Task ${index + 1} 성공:`, result.value);
    } else {
      console.log(`Task ${index + 1} 실패:`, result.reason);
    }
  });
}

run();

/*
Task 1 성공: 성공 결과
Task 2 실패: Error: 실패 발생!
Task 3 성공: 123
Task 4 실패: 단순 실패
*/

결론

Promise.allSettled()를 사용하는 부분에 경보를 붙이는 코드는

try catch를 사용하지 않고,
Promise.allSettled() 결과 배열에서 status가 rejected인 객체를 필터링하여

그에 따라 경보가 작동하도록 했다.

참고 자료

Promise.all() - JavaScript | MDN

이 메서드는 여러 프로미스의 결과를 집계할 때 유용하게 사용할 수 있습니다. 일반적으로 다음 코드를 계속 실행하기 전에 서로 연관된 비동기 작업 여러 개가 모두 이행되어야 하는 경우에 사

developer.mozilla.org

HTTP ETag 응답 헤더 (+ If-Match, If-None-Match 요청 헤더)

왈왈디 — Sun, 31 Aug 2025 23:11:11 +0900

ETag란?

Etag는 http 응답 헤더의 일종으로,

특정 버전의 리소스를 식별하는 식별자이다.

ETag는 리소스의 지문과 같은 역할로,

만약 특정 URL 의 리소스가 변경된다면, 새로운 ETag 가 생성된다.

ETag를 비교하면 리소스가 동일한지 빠르게 판단할 수 있다.

리소스가 변동 없고 ETag가 동일하다면 서버는 새로운 응답을 보낼 필요가 없기 때문에

캐쉬를 더 효율적으로 사용할 수 있고, 대역폭 사용량을 줄일 수 있다.

만약 리소스가 변경되었다면,

"mid-air collisions"라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하다.

문법

ETag: W/"<etag_value>"
ETag: "<etag_value>"

Weak ETag(W/) 는 리소스가 실질적으로 같은 의미를 가진다면 동일하다고 간주하는 방식이다.

비트 단위로는 달라도 “같은 콘텐츠”라고 볼 수 있는 경우에 사용한다.

W/가 붙은 ETag는 “이 리소스는 대충 같은 거야”라는 서버의 힌트이고,
W/가 없는 건 trong validator가 사용되었다는 의미로 “비트까지 완전히 같아”라는 약속이다.

아래는 사용 예시이다.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

ETag는 응답 값을 ASCII 코드와 같이 고유한 형태로 나타낸다.

ETag 의 값을 생성하는 방법(Method)은 단순히 한가지로 정해져있진 않다.

콘텐츠의 해시, 마지막으로 수정된 타임스탬프의 해시, 혹은 그냥 개정번호를 이용한다.

예를들어, MDN은 wiki(콘텐츠)의 16진수 해시를 사용한다.

사용법1 - 충돌 피하기 (mid-air collisions)

ETag와 http 요청 헤더인 If-Match 헤더를 사용하여

리소스의 충돌을 예측할 수 있다.

예를 들어, 웹 페이지에서 사용자가 다른 사용자도 수정할 수 있는 문서를 수정하고 있는 상황이다.

이때 이 사용자가 수정한 문서를 저장하기 위해 POST 요청을 보냈다.

이 POST 요청은 If-Match 헤더로 사용자가 수정을 시작한 시점의 리소스의 Etag 값을 담아 보낸다.

서버는 요청의 If-Match 헤더에 담긴 ETag 값이 현재의 ETag값과 동일한지 확인하고,

동일하지 않다면 그 사이에 이미 리소스가 수정되었기 때문에 요청을 성공 시키지 않고,

412 Precondition Failed (전제조건 실패) 에러를 반환한다.

사용법2 - 변경되지 않은 리소스의 캐싱

또 다른 Etag의 사용 목적은 변경되지 않은 리소스를 캐시하는 것이다.

클라이언트는 ETag를 가지고 있다면 ETag를 If-None-Match 헤더 필드에 담아 요청을 전송한다.

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

서버는 클라이언트가 요청 헤더에 담아 보낸 ETag를 현재 버전 리소스의 Etag와 비교하고,

두 값이 일치하는 경우에는 304 Not Modified 상태 코드를 반환한다.

이 때 응답 body는 비어있다.

304 응답 코드를 받으면 클라이언트는 캐시된 버전이 여전히 유효하다는 것을 알 수 있다.

참고 자료

MDN ETag

Prisma 컬럼 삭제 에러 & Select문 동작 방식

왈왈디 — Sun, 17 Aug 2025 23:06:32 +0900

이슈 발생

NestJS, Prisma, MySQL 환경의 프로젝트에서 MySQL 테이블의 컬럼을 삭제하는 작업을 진행했다.

(이하에서는 해당 컬럼을 "컬럼a"라고 칭하겠다.)

애플리케이션 코드에서도 컬럼a를 참조하는 모든 코드를 확인하고,
컬럼a를 사용하지 않도록 수정했다.

수정된 코드가 포함된 API들은 배치 작업 용이었어서,

배포 도중 실시간 트래픽이 없어

DB 스키마 변경과 애플리케이션 코드 배포 사이 시간 동안의 이슈는 고려하지 않았다.

그런데 컬럼a를 전혀 참조하지 않는 실시간 트래픽이 많은 API에서

해당 시간 동안 에러가 발생했다.

원인

처음엔 컬럼a를 명시적으로 사용하는 곳이 없는 API라 에러가 발생한 이유를 이해할 수 없었다.

그런데 Prisma가 생성하는 쿼리를 확인해보니,

원인을 알 수 있었다.

이슈의 원인은 Prisma의 find 메서드 동작 방식에 있다.

Prisma의 find 메서드에서 아래와 같이 select 대상 컬럼을 명시하지 않으면,

테이블의 모든 컬럼을 조회하게 된다.

 const employee = await this.prisma.employees.findUnique({
      where: { id: employeeId }
    });

이때 DB에 전달되는 쿼리가 아래와 같을 것이라 기대했다.

SELECT *
FROM employees
WHERE id = ${employeeId};

그러나 실제로 Prisma가 생성하는 쿼리는 아래와 같다.

(정확히 이와 동일한 쿼리가 실행되는 것은 아님, 설명을 위해 단순화함)

SELECT id, name, phone_number, weight, height, age
FROM employees
WHERE id = ${employeeId};

테이블 내 모든 컬럼을 SELECT 문에서 명시하는 것이다.

이 때문에 컬럼a를 삭제했을 때,

어플리케이션 코드 상에서는 컬럼a를 사용하는 곳이 없었는데도

DB에서 컬럼a가 삭제된 후 컬럼a를 조회하는 쿼리가 실행되어

에러가 발생한 것이다.

해결 방안

해결 방안은 간단하다.

컬럼이 삭제될 것을 고려하여 find 문을 사용할 때 select 프로퍼티를 명시적으로 작성하여,

의도치 않은 컬럼이 SELECT 절에 포함되지 않도록 하는 것이다.

 const employee = await this.prisma.employees.findUnique({
     select: {
      	id: true,
        age: true
      },
      where: { id: employeeId }
    });

SELECT문에서 필요한 컬럼만 명시하는 것은

컬럼을 삭제할 때 의식하지 못한 에러의 발생을 방지할 뿐만 아니라 아래와 같은 장점들이 있다.

1. 성능 측면

네트워크 전송량 감소:
- 불필요한 컬럼까지 가져오지 않으니, DB에서 애플리케이션으로 넘어가는 데이터 크기가 줄어든다.
- 특히 컬럼이 많고 레코드 수가 많을 때 효과가 크다.
DB 서버의 I/O 부담 감소
- 스토리지에서 읽어야 하는 양이 줄어들어 쿼리 속도가 개선될 수 있다.

2. 애플리케이션 안정성

불필요한 데이터 노출 방지
- 민감한 컬럼(예: 비밀번호 해시, 내부 관리용 필드 등)이 의도치 않게 애플리케이션 레이어로 전달되는 것을 막을 수 있다.
스키마 변경에 대한 영향 최소화 (컬럼 삭제 등)
- SELECT *는 컬럼이 추가되면 쿼리 결과 구조가 달라지는데, 지정된 컬럼만 가져오면 이런 변경에 덜 민감하다.

3. 코드 가독성 및 유지보수

쿼리의 의도가 명확해짐
- 어떤 데이터를 쓰려는지 명시적으로 드러나서 협업 시 이해하기 쉽다.
불필요한 매핑/파싱 코드 감소
- ORM이나 DTO 매핑 과정에서 실제로 필요 없는 필드를 다루지 않아도 된다.

4. 비용 효율성 (운영 환경)

클라우드 환경에서의 비용 절감
- 네트워크 요금, DB 사용량(쿼리 실행 시간, I/O 비용)이 줄어드는 효과가 있을 수 있다.

Github Actions로 EC2 배포 자동화하기 (feat. NestJS, prisma)

왈왈디 — Sun, 3 Aug 2025 23:52:08 +0900

이슈 발생

사이드 프로젝트 배포를 수동으로 진행하고 있었다.

코드 변경 사항이 발생한다면 EC2 인스턴스에 접속하여 git pull origin main으로 코드를 내려 받아서,
npx prisma generate, npm run build를 실행하여 빌드하고, pm2로 restart 시켰다.

어느날 평소와 같이 변경 사항을 pull 받고, build를 실행하는데

cpu 사용량이 100%에 도달하여 인스턴스가 먹통이 됐다.

인스턴스를 재부팅해야 했다.

사용 중인 인스턴스 유형은 t2.micro인데, 비용 상 인스턴스 유형을 업그레이드 하고 싶지는 않았다.

결국 build는 다른 서버에서 하고,

build 산출물을 EC2 인스턴스에 업로드하여 EC2에서는 서버 실행만 하는 것이 옳다고 판단했다.

이를 Github Actions로 구현해보자.

Github Actions 배포 자동화

github의 Actions 기능은 CI/CD 등을 자동화할 수 있는 툴이다.

프로젝트 루트 디렉토리 .github/workflows 경로에 자동화 스크립트를 작성하면

조건에 따라 자동으로 실행시킬 수 있다.

예를 들어, on: 조건이 아래와 같이 작성된 경우 main 브랜치에 push가 된 경우

jobs 이하의 작업이 실행된다는 의미이다.

name: Build and Deploy NestJS App

on:
  push:
    branches: ['main']

이번 배포 자동화를 위해 작성한 스크립트는 아래와 같다.

전체를 한 번에 이해하기 보다는 단계별로 쪼개어 살펴보자.

build-and-deploy.yml

name: Build and Deploy NestJS App

on:
  push:
    branches: ['main']

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js 18.x
        uses: actions/setup-node@v4
        with:
          node-version: 18.x
          cache: 'npm'

      - name: Install Dependencies (Production)
        run: npm ci --omit=dev

      - name: Build Nest App
        run: npm run build

      - name: Generate Prisma Client
        run: npx prisma generate

      - name: Check Prisma Client generated
        run: |
          test -f node_modules/@prisma/client/index.js || (echo "❌ Prisma client not found!" && exit 1)
          test -f node_modules/.prisma/client/default.js || echo "⚠️ .prisma/client/default.js 없음 (Prisma 5.x에서는 선택적일 수 있음)"

      - name: Prepare Output Directory
        run: |
          mkdir output
          cp -r dist node_modules prisma package*.json output/
          if [ -d .prisma ]; then cp -r .prisma output/; fi

      - name: Archive Build Output
        run: |
          cd output && tar czf ../nest-app.tar.gz .

      - name: Get Public IP
        id: ip
        uses: haythem/public-ip@v1.3

      - name: Print Public IP
        run: |
          echo "GitHub Actions IP: ${{ steps.ip.outputs.ipv4 }}"

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: 'ap-northeast-2'

      - name: Add GitHub Actions IP to Security Group
        run: |
          aws ec2 authorize-security-group-ingress \
            --group-id ${{ secrets.SECURITY_GROUP_ID }} \
            --protocol tcp \
            --port 22 \
            --cidr ${{ steps.ip.outputs.ipv4 }}/32

      - name: Upload Build to Server via SCP
        uses: appleboy/scp-action@v0.1.6
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          port: 22
          source: 'nest-app.tar.gz'
          target: '~/deploy'

      - name: Execute Remote Deploy Script via SSH
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          port: 22
          script: |
            bash ~/deploy/deploy.sh

      - name: Remove GitHub Actions IP from Security Group
        if: always()
        run: |
          aws ec2 revoke-security-group-ingress \
            --group-id ${{ secrets.SECURITY_GROUP_ID }} \
            --protocol tcp \
            --port 22 \
            --cidr ${{ steps.ip.outputs.ipv4 }}/32

전체 흐름 요약

위 배포 자동화 스크립트의 전체적인 흐름은 아래와 같다.

GitHub Actions: CI 파이프라인에서 npm ci, nest build, npx prsima generate 실행
→ node_modules, prisma, dist/ 디렉토리 생성
빌드 산출물(zip/tar): dist/, node_modules, prisma, 필요한 설정파일만 포함하여 압축
서버 전송: scp로 대상 Linux 서버에 업로드
서버에서 실행: 서버에 미리 작성해둔 deploy.sh 파일로 pm2 서버 실행

1. node_modules, 빌드 산출물 생성

배포 자동화 작업의 첫 번째 단계는 서버를 구동하기 위해 필요한 파일들을 빌드하는 것이다.

1) node 설치

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js 18.x
        uses: actions/setup-node@v4
        with:
          node-version: 18.x
          cache: 'npm'

먼저 필요한 node 버전을 설치한다.

2) npm ci

      - name: Install Dependencies (Production)
        run: npm ci --omit=dev

그 다음 패키지를 install 한다.

여기서 --omit=dev 는 상용 서버 구동에 불필요한 dev dependencies 패키지를 제외한다는 의미다.

즉, 서버 구동에 필요한 패키지는 모두 dependencies로 설치되어 있어야 한다.

나는 @nestjs/cli, prisma, @prisma/client 패키지가 dev dependencies 로 설치되어 있었어서 수정해주었다.

3) npm run build

      - name: Build Nest App
        run: npm run build

npm run build( =nest build) 로 typescript 코드를 빌드한다.

4) npx prisma generate

      - name: Generate Prisma Client
        run: npx prisma generate

      - name: Check Prisma Client generated
        run: |
          test -f node_modules/@prisma/client/index.js || (echo "❌ Prisma client not found!" && exit 1)
          test -f node_modules/.prisma/client/default.js || echo "⚠️ .prisma/client/default.js 없음 (Prisma 5.x에서는 선택적일 수 있음)"

prisma를 사용하는 프로젝트여서 prisma generate 산출물도 필요하다.

처음에는 EC2에서 npx prisma를 실행하려고 했으나,

prsima 모듈을 찾을 수 없다는 에러가 계속 발생해서,

(아마 node_modules를 압축하고 해제하는 과정에서 이슈가 발생한 게 아닐까 싶다)

github actions 파이프라인에서 npx prisma generate 까지 실행하여 산출물을 서버로 전송하는 방식으로 변경했다.

generate 결과물이 잘 생성되었는지 확인하기 위해 test 절차를 추가했다.

prisma 버전에 따라 .prisma 는 없을 수 있다.

2. 산출물 압축

1) 필요한 결과물만 output 디렉토리로 이동

      - name: Prepare Output Directory
        run: |
          mkdir output
          cp -r dist node_modules prisma package*.json output/
          if [ -d .prisma ]; then cp -r .prisma output/; fi

output이라는 이름의 디렉토리를 생성하여

dist, node_modules, prisma, package.json, package-lock.json 등

서버 구동에 필요한 파일/디렉토리만 담는다.

.prisma는 버전에 따라 있거나 없을 수 있으므로 분기처리 했다.

EC2 서버로 보낼 대상 디렉토리의 구조는 아래와 같다.

output/
├── dist/
├── node_modules/
├── package.json
├── package-lock.json
├── prisma/
└── .prisma/

2) 압축

      - name: Archive Build Output
        run: |
          cd output && tar czf ../nest-app.tar.gz .

그리고 output 디렉토리로 이동하여 그 안의 모든 파일을

EC2 서버에 전송할 nest-app.tar.gz 파일로 압축한다.

3. 산출물 서버 전송

위 단계까지 실행하면 EC2 서버에 전송할 압축 파일이 완성된다.

rsync, scp 등의 방식으로 파일을 서버로 전송할 수 있는데,

나는 scp 방식을 사용했다.

1) github actions 서버 public ip 접근 허용하기

파일을 전송하기 전에 점검해야 하는 부분이 있다.

scp는 ssh 프로토콜을 사용한다.

즉, EC2 서버의 보안 그룹에서 github actions 서버의 ssh port 접근이 허용되어 있어야 한다.

https://api.github.com/meta

응답의 actions 배열을 확인하면

github actions 서버들의 public ip 리스트를 확인할 수 있다.

매번 사용되는 인스턴스 ip는 변경될 수 있는데, 리스트의 ip 수가 매우 많아서

모두 보안 그룹에서 허용해두기에는 부담이 된다.

이 때 사용 가능한 방식이

동적으로 현재의 github actions 인스턴스의 public ip를 확인하여

이 ip를 보안그룹 허용 ip에 추가하고

배포가 완료되면 보안그룹에서 ip를 제거하는 것이다.

현재 사용 중인 인스턴스의 public ip를 확인한다.

      - name: Get Public IP
        id: ip
        uses: haythem/public-ip@v1.3

      - name: Print Public IP
        run: |
          echo "GitHub Actions IP: ${{ steps.ip.outputs.ipv4 }}"

그리고 AWS에 접근하여 보안 그룹에 현재 public ip를 추가한다.

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: 'ap-northeast-2'

      - name: Add GitHub Actions IP to Security Group
        run: |
          aws ec2 authorize-security-group-ingress \
            --group-id ${{ secrets.SECURITY_GROUP_ID }} \
            --protocol tcp \
            --port 22 \
            --cidr ${{ steps.ip.outputs.ipv4 }}/32

이 과정에서 아래 세 가지 환경 변수가 필요하다.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
SECURITY_GROUP_ID

Github Actions에서 사용되는 환경변수는

레포지토리의 Settings > Security > Secrets and variables > Actions 에서 설정할 수 있다.

아래 두 값은 AWS IAM 에서 사용자를 생성하여 발급할 수 있다.

권한 관리를 위해 github actions에서만 사용할 사용자를 별도로 발급하는 것이 좋다.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

아래 값은 EC2 인스턴스의 보안 그룹 ID이다.

SECURITY_GROUP_ID

위 step을 거치면 보안 그룹 22포트 허용 ip에 현재 github actions 서버 public ip가 추가된다.

2) 압축 파일 전송

접근이 허용되면 scp로 압축 파일을 전송한다.

      - name: Upload Build to Server via SCP
        uses: appleboy/scp-action@v0.1.6
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          port: 22
          source: 'nest-app.tar.gz'
          target: '~/deploy'

EC2 서버의 디렉토리 구조는 아래와 같이 구성했다.

따라서 ~/deploy 디렉토리로 압축 파일을 전송한다.

디렉토리 구조

~/deploy/nest-app.tar.gz        ← GitHub Actions에서 전송
~/app/nest-app/                 ← 실제 실행 위치
~/app/nest-app/dist/main.js     ← 엔트리포인트
~/app/nest-app/prisma/          ← schema 및 migrations

파일 전송 시 필요한 환경 변수는 아래 세 가지다.

SERVER_HOST: EC2 서버의 ip 또는 도메인
SERVER_USER: EC2 서버 접속 시 사용하는 user
SERVER_SSH_KEY

이 중 SERVER_SSH_KEY는 공개키-개인키 방식으로 생성 방법은 아래와 같다.

ssh key 생성 방법

1. 터미널에서 키 생성 명령어 실행

ssh-keygen -t rsa -b 4096 -C "github-deploy"

GitHub Actions는 비밀번호 없이 사용해야 하므로, 패스프레이즈는 비워둬야 한다.

생성 결과:

github_deploy_key: 개인 키 (이걸 GitHub Secret에 등록)
github_deploy_key.pub: 공개 키 (이걸 서버에 등록)

2. 서버에 공개키 등록

서버에서 ~/.ssh/authorized_keys에 공개 키 추가하거나

cat github_deploy_key.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

직접 편집할 수 있다.

vi ~/.ssh/authorized_keys

3. Github Actions Secrets에 개인키 등록

SERVER_SSH_KEY로 github_deploy_key 파일의 내용 전체를 복사한다. (예: cat github_deploy_key 결과)

4. 권한 확인(선택 사항)

GitHub Actions에서 사용할 사용자 계정이 서버에 실제로 접근 가능한지 사전에 확인 가능하다.

ssh -i github_deploy_key youruser@your.server.ip

4. 서버 실행

위 단계들을 통해 EC2 인스턴스로 서버 실행에 필요한 파일들이 모두 옮겨졌다면,

서버에 미리 작성해둔 deploy.sh 파일로 pm2 서버를 실행한다.

~/deploy/deploy.sh

#!/bin/bash

set -e

APP_DIR=~/app/nest-app
DEPLOY_DIR=~/deploy
ARCHIVE=$DEPLOY_DIR/nest-app.tar.gz

echo "[1/3] 아카이브 해제 중..."

ENV_BACKUP="$APP_DIR/.env"

if [ -f "$ENV_BACKUP" ]; then
  cp "$ENV_BACKUP" /tmp/.env.bak
fi

rm -rf $APP_DIR
mkdir -p $APP_DIR
tar -xzf $ARCHIVE -C $APP_DIR

# 복원
if [ -f /tmp/.env.bak ]; then
  mv /tmp/.env.bak "$APP_DIR/.env"
fi

cd $APP_DIR

echo "[2/3] PM2로 앱 시작 또는 재시작..."
if pm2 describe nest-app > /dev/null; then
  pm2 restart nest-app
else
  pm2 start dist/main.js --name nest-app
fi

echo "[3/3] 배포 완료!"

deploy.sh의 내용은 압축을 해제하고, pm2로 서버를 실행하는 것이다.

다만 여기서 주의할 점은 .env 파일은 미리 해당 디렉토리 내에 저장되어 있어야 하고,

삭제되면 안되기 때문에 .env 파일이 삭제되지 않도록 예외처리 해주었다.

또, PM2는 인스턴스 내에 글로벌 설치 되어 있어야 한다. (npm install -g pm2)

deploy.sh가 잘 실행되면 서버가 구동된다.

그럼 마지막으로 EC2 보안 그룹 허용 ip에 추가되었던 github actions 서버 ip를 제거해주면 끝이다.

      - name: Remove GitHub Actions IP from Security Group
        if: always()
        run: |
          aws ec2 revoke-security-group-ingress \
            --group-id ${{ secrets.SECURITY_GROUP_ID }} \
            --protocol tcp \
            --port 22 \
            --cidr ${{ steps.ip.outputs.ipv4 }}/32

MySQL 복제(레플리카) 설정하기

왈왈디 — Sun, 20 Jul 2025 20:42:37 +0900

복제란?

복제는 한 서버에서 다른 서버로 데이터가 동기화되는 것을 말한다.

소스(Source) 서버: 원본 데이터를 가진 서버
레플리카(Replica) 서버: 복제된 데이터를 가지는 서버

소스 서버에서 데이터 및 스키마에 대한 변경이 최초로 발생한다.

레플리카 서버에서는 이러한 변경 내역을 소스 서버로부터 전달 받아
자신이 가지고 있는 데이터에 반영함으로써 소스 서버에 저장된 데이터와 동기화 시킨다.

복제의 목적은 주로 다음 4가지이다.

스케일 아웃(Scale-out)
데이터 백업
레플리카 서버를 데이터 분석용 서버로 사용
데이터의 지리적 분산

복제 아키텍처

복제 아키텍처를 이해하기 위해서두 가지 로그를 알아두어야 한다.

바이너리 로그(Binary Log): MySQL 서버에서 발생하는 모든 변경 사항을 순서대로 기록한다.
데이터의 변경 내역 뿐만 아니라, 데이터베이스나 테이블의 구조 변경과 계정이나 권한의 변경 정보까지 모두 저장된다.
복제는 이 바이너리 로그를 기반으로 구현됐다. 소스 서버에서 생서된 바이너리 로그가 레플리카 서버로 전송되고 레플리카 서버에서는 해당 내용을 로컬 디스크에 저장한 뒤 자신이 가진 데이터에 반영함으로써 동기화가 이루어진다.
릴레이 로그(Relay Log): 레플리카 서버에서 소스 서버의 바이너리 로그를 읽어 로컬 디스크에 저장해둔 파일이다.

MySQL 복제는 세 개의 스레드에 의해 작동한다.

바이너리 로그 덤프 스레드(Binary Log Dump Thread): 레플리카 서버가 소스 서버에 접속해 바이너리 로그 정보를 요청한다.
소스 서버에서 바이너리 로그 덤프 스레드를 생성해서 바이너리 로그의 내용을 레플리카 서버로 전송한다.
각 이벤트를 읽을 때 일시적으로 바이너리 로그에 잠금을 수행하며, 이벤트를 읽고난 후에는 바로 잠금을 해제한다.
레플리케이션 I/O 스레드(Replication I/O Thread): 레플리카 서버에서 소스 서버의 바이너리 로그 이벤트를 가져와 로컬 서버의 파일(릴레이 로그)로 저장하는 역할이다.
복제가 시작되면 레플리카 서버는 I/O 스레드를 생성하고, 복제가 멈추면 종료된다.
레플리케이션 SQL 스레드(Replication SQL Thread): 레플리카 서버에서 작성된 릴레이 로그 파일의 이벤트들을 읽고 실행한다.

복제가 시작되면 레플리카 서버는 총 세 가지 유형의 복제 관련 데이터를 생성하고 관리한다.

릴레이 로그(Relay Log): 레플리케이션 I/O 스레드에 의해 작성되는 파일로, 소스 서버의 바이너리 로그에서 읽어온 이벤트(트랜잭션) 정보가 저장된다.
커넥션 메타데이터(Connection Metadata): 레플리케이션 I/O 스레드에서 소스 서버에 연결할 때 사용하는 DB 계정 정보 및 현재 읽고 있는 소스 서버의 바이너리 파일명과 파일 내 위치 값등이 담겨 있다.
mysql.slave_master_info 테이블에 저장된다.
어플라이어 메타데이터(Applier Metadata): 레플리케이션 SQL 스레드에서 릴레이 로그에 저장된 소스 서버의 이벤트들을 레플리카 서버에 적용(Relay)하는 컴포넌트를 어플라이어(Applier)라고 한다.
최근 적용된 이벤트에 대해 해당 이벤트가 저장돼 있는 릴레이 로그 파일명과 파일 내 위치 정보 등을 담고 있고, 이 정보들을 바탕으로 레플리카 서버에 나머지 이벤트들을 적용한다.
mysql.slave_relay_log_info 테이블에 저장된다.

복제 타입

복제는 소스 서버의 바이너리 로그에 기록된 변경 내역들을 식별하는 방식에 따라 두가지로 나뉜다.

바이너리 로그 파일 위치 기반 복제
글로벌 트랜잭션 ID 기반 복제

이번엔 바이너리 로그 파일 위치 기반 복제에 대해서만 살펴보자.

바이너리 로그 파일 위치 기반 복제

복제 기능이 처음 도입됐을 때부터 제공된 방식으로,
레플리카 서버에서 소스 서버의 바이너리 로그 파일명과 파일 내에서의 위치(Offset 또는 Position)로
개별 바이너리 로그 이벤트를 식별해서 복제가 진행되는 형태이다.

복제를 처음 구축할 때 레플리카 서버에 소스 서버의 어떤 이벤트부터 동기화를 수행할 것인가에 대한 정보를 설정해야 한다.

레플리카 서버는 소스 서버의 어느 이벤트까지 로컬 디스크로 가져왔고 또 적용했는지에 대한 정보를 관리하며
소스 서버에 해당 정보를 전달해 그 이후의 바이너리 로그 이벤트들을 가져온다.

따라서 소스 서버에서 발생한 각 이벤트에 대한 식별이 반드시 필요하고,
바이너리 로그 파일 위치 기반 복제 방식에서는 파일명과 파일 내에서의 위치 값(File Offset)의 조합으로 식별한다.

또 중요한 점은 복제에 참여한 MySQL 서버들이 모두 고유한 server_id 값을 가지고 있어야 한다.

server_id는 시스템 변수 중 하나로, 사용자가 설정할 수 있으며 기본값은 1이다.

복제 구축

바이너리 로그 파일 위치 기반의 복제 구축 방식에 대해 알아보자.

1. 설정 준비

복제를 사용하려면 소스 서버에서 반드시 바이너리 로그가 활성화돼 있어야 하며,

복제 구성원이 되는 각 MySQL 서버가 고유한 server_id를 가져야 한다.

MySQL 8.0에서는 바이너리 로그가 기본적으로 활성화돼 있다.

바이너리 로그 파일 위치나 파일명을 따로 설정하고 싶다면 log_bin 시스템 변수를 통해 원하는 값으로 설정할 수 있다.

동기화 방식이나, 캐시를 위한 메모리 크기, 파일 크기, 보관 주기 등도 지정할 수 있다.

아래 명령으로 소스 서버에서 바이너리 로그가 정상적으로 기록되고 있는지 확인할 수 있다.

SHOW MASTER STATUS;

레플리카 서버가 소스 서버로 승격될 수 있음을 고려하면 log_slave_updates 시스템 변수를 명시하는 것이 좋다.

기본적으로 레플리카 서버는 복제에 의한 데이터 변경 사항은 자신의 바이너리 로그에 기록하지 않는데,

log_slave_updates 시스템 변수를 설정하면 복제에 의한 데이터 변경 내용도 자신의 바이너리 로그에 기록하게 된다.

2. 복제용 계정 준비

레플리카 서버가 사용할 복제용 계정이 필요하다.

복제에 사용되는 권한만 주어진 별도의 계정을 생성해 사용하는 것이 좋다.

이 계정은 반드시 REPLICATION SLAVE 권한을 가지고 있어야 한다.

3. 데이터 복사

복제를 시작하기 전에 소스 서버의 데이터를 레플리카 서버로 가져와서 적재해 두어야 한다.

MySQL 엔터프라이즈 백업이나 mysqldump 같은 툴을 이용해서 데이터를 복사하면 된다.

4. 복제 시작

데이터 복사까지 완료되면 복제를 시작하면 된다.

mysqldump를 이용해 소스 서버의 데이터를 백업 받아 11:20 쯤에 레플리카 서버에 모두 적재된 경우,

복제를 시작하는 시점이 11:45이라면
레플리카 서버 데이터가 11:20 부터 11:45까지의 데이터에 대해 소스 서버보다 지연된 상태라고 할 수 있다.

복제를 설정하여 복제를 시작하자.

CHANGE REPLICATION SOURCE TO (또는 CHANGE MASTER TO) 명령으로 mysqldump로 백업 받은 파일의 헤더 부분에서

해당 명령어를 참조할 수 있다.

대략 24번째 줄에 있는 "CHANGE MASTER"로 시작하는 줄만 텍스트 편집기에 복사해둔다.

linux> less /tmp/source_data.sql
...

-- Position to start replication or point-in-time recovery from
--

-- CHANGE MATSER TO MASTER_LOG_FILE='binary-log.000002', MASTER_LOG_POS=2708;

이제 편집기에 복사해 둔 내용에

소스 서버 MySQL 서버의 호스트명
포트
복제용 사용자 계정
비밀 번호

등을 다음과 같이 추가해 복제 설정 명령을 준비한다.

-- // MySQL 8.0.23 이상 버전
CHANGE REPLICATION SOURCE TO
	SOURCE_HOST='source_server_host',
    SOURCE_PORT=3306,
    SOURCE_USER='repl_user',
    SOURCE_PASSWORD='repl_user_password',
    SOURCE_LOG_FILE='binary-log.000002',
    SOURCE_LOG_POS=2708,
    GET_SOURCE_PUBLIC_KEY=1;
    
-- // MySQL 8.0.23 미만 버전
CHANGE MASTER TO
	MASTER_HOST='source_server_host',
    MASTER_POST=3306,
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_user_password',
    MASTER_LOG_FILE='binary-log.0000002',
    MATSER_LOG_POS=2708,
    GET_MASTER_PUBLIC_KEY=1;

SOURCE_HOST는 소스 서버를 의미하고 소스 서버의 IP 혹은 도메인 정보를 넣으면 도니다.

GET_SOURCE_PUBLIC_KEY는 RSA 키 기반 비밀번호 교환 방식의 통신을 위해 공개키(Public Key)를 소스 서버에 요청할 것인지 여부를 나타낸다. 에러가 발생할 수 있으므로 반드시 설정해야 한다.

이 명령을 그대로 레플리카 서버의 MySQL에 로그인해서 실행한 뒤 아래 명령을 실행해보면

복제 관련 정보가 레플리카 서버 MySQL에 등록돼 있는 것을 확인할 수 있다.

SHOW REPLICA STATUS;
-- 또는 SHOW SLAVE STATUS

하지만 Replica_IO_Running, Replica_SQL_Running 컬럼값이 "No" 로 되어있는데

아직 복제 관련 정보 등록만 된 것이지 동기화가 시작되지 않았음을 의미한다.

이 상태에서 아래 명령을 실행하면 두 값이 "Yes"로 바뀌면서
동기화가 지연된 기간의 변경 사항들을 소스 서버로부터 가져와 적용하게 된다.

START REPLICA;
-- 또는 START SLAVE

복제 중 소스 서버로부터 넘어온 트랜잭션이 제대로 실행되지 못하고
에러가 발생해 복제가 멈추는 현상이 발생하기도 한다.

대부분은 사용자의 실수로 인한 경우가 많고, 대표적인 에러가 중복 키 에러다.

바이너리 로그 위치 기반 복제에서는 sql_slave_skip_counter 시스템 변수를 이용해 문제되는 트랜잭션을 건너뛸 수 있다.

아래와 같이 복제를 중단한 후 sql_slave_skip_counter 변수의 값을 1로 지정해 레플리케이션 SQL 스레드를 재시작하면

레플리카 서버는 에러가 발생한 INSERT 쿼리를 건너뛰고 정상적으로 복제를 재개하게 된다.

STOP SLAVE SQL THREAD;
SET GLOBAL sql_slave_skip_counter=1;
START SLAVE SQL_THREAD;

참고 자료

Real MySLQ 8.0 2권 - 16. 복제