📈 초당 100만 요청을 처리하기 위해 Go 백엔드를 확장한 과정

How I Scaled a Go Backend to Handle 1 Million Requests per Second

처음에는 단순한 API였습니다.
사용자 인증과 결제 처리를 담당하는 가벼운 Go 서비스였고,
하루에 몇 천 건 정도의 요청만 처리하면 되었기에 문제없이 잘 돌아갔습니다.

하지만 트래픽이 점점 늘어나면서,
한때 빠릿하던 백엔드는 점점 느려지기 시작했습니다.
지연 시간은 급격히 늘었고, 데이터베이스 쿼리는 병목이 되었으며,
서버는 높은 부하를 견디지 못하고 점점 지쳐갔습니다.

그러던 어느 날,
저희 서비스가 한 유명 뉴스 사이트에 소개되면서 상황이 급변했습니다.
단 몇 분 만에 트래픽이 10배 이상 폭증했고,
Go 백엔드는 간신히 버티고 있었으며, 인프라 팀은 외쳤습니다.

“서버를 더 늘려야 해요!”

그때 저는 결심했습니다.
지금이야말로 이 시스템을 진짜로 최적화할 때다.

결국, 저는 이 백엔드를
초당 100만 요청(RPS)을 처리할 수 있는 수준까지 확장시켰습니다.

그리고 지금,
그 과정을 여러분께 공유하려 합니다.

---

⚙️ 1. 진짜 병렬성을 위한 고루틴 최적화

처음에는 Go의 고루틴이 마법 같다고 생각했습니다.
“가볍다! 무한히 스케일된다!” — 그렇게 믿었죠.

하지만 곧 깨달았습니다.
무제한으로 고루틴을 생성하면 오히려 CPU 컨텍스트 스위칭이 과도하게 발생하고, 메모리도 금방 고갈된다는 사실을요.

고루틴 과부하 해결: 워커 풀 도입
무작정 고루틴을 띄우는 대신,
고정된 수의 워커가 큐에 쌓인 요청을 처리하는 워커 풀(worker pool)을 직접 구현했습니다.

이 방식은 다음과 같은 이점을 줬습니다:
요청 수가 많아도 고루틴 수가 일정하게 유지됩니다.
CPU 자원을 예측 가능하게 사용할 수 있어 안정적인 처리 성능을 유지합니다.
메모리 사용량도 급격히 늘어나지 않아, GC에 의한 지연도 줄어듭니다.

package main

import (
    "fmt"
    "sync"
    "time"
)

const maxWorkers = 100 // Controls concurrency level
const numJobs = 1000000
type Job struct {
    ID int
}

func worker(id int, jobs <-chan Job, wg *sync.WaitGroup) {
    defer wg.Done()
    for job := range jobs {
        // Simulating CPU-intensive processing
        time.Sleep(1 * time.Millisecond)
        fmt.Printf("Worker %d processed job %d\n", id, job.ID)
    }
}

func main() {
    jobs := make(chan Job, numJobs)
    var wg sync.WaitGroup
    for w := 1; w <= maxWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, &wg)
    }
    for j := 1; j <= numJobs; j++ {
        jobs <- Job{ID: j}
    }
    close(jobs)
    wg.Wait()
}

✅ 왜 효과가 있었을까?
수백만 개의 고루틴을 무작정 생성하는 대신,
동시성 수준을 maxWorkers로 제한함으로써
👉 컨텍스트 스위칭을 줄이고, CPU 효율을 크게 향상시킬 수 있었습니다.

---

🚀 2. REST에서 gRPC로의 전환: 번개처럼 빠른 API를 위하여

처음에는 HTTP 기반의 REST API로 시스템을 구축했습니다.
하지만 트래픽이 많아지자 다음과 같은 문제들이 나타났습니다:

• JSON 직렬화/역직렬화 오버헤드
• HTTP 요청당 하나의 연결과 응답
• 다수의 라운드 트립으로 인한 지연

✅ 해결책: gRPC로 마이그레이션
gRPC는 다음과 같은 특징으로 성능을 획기적으로 개선해줍니다
바이너리 직렬화 방식(Protobuf) 사용 → JSON보다 훨씬 빠름
HTTP/2 기반 멀티플렉싱 → 하나의 연결로 여러 요청 처리 가능
스트리밍 지원 → 양방향 데이터 송수신에 유리

🧪 gRPC 적용 예시: 고속 Go API
📄 payment.proto (protobuf 정의)

syntax = "proto3";
package pb;

service PaymentService {
    rpc ProcessPayment (PaymentRequest) returns (PaymentResponse);
}

message PaymentRequest {
    string user_id = 1;
    double amount = 2;
}

message PaymentResponse {
    bool success = 1;
    string transaction_id = 2;
}

🧠 Go 서버 구현

package main

import (
    "context"
    "fmt"
    "log"
    "net"

    "google.golang.org/grpc"
    pb "path/to/protobuf" // 컴파일된 프로토버퍼 패키지 import
)

// 실제 서비스 구현체
type paymentServer struct {
    pb.UnimplementedPaymentServiceServer
}

// 결제 요청 처리 로직
func (s *paymentServer) ProcessPayment(ctx context.Context, req *pb.PaymentRequest) (*pb.PaymentResponse, error) {
    // 이곳에 DB 연동, 비즈니스 로직 등을 추가할 수 있습니다.
    return &pb.PaymentResponse{
        Success:       true,
        TransactionId: "txn_123456",
    }, nil
}

func main() {
    // TCP 리스너 생성
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    // gRPC 서버 생성 및 서비스 등록
    s := grpc.NewServer()
    pb.RegisterPaymentServiceServer(s, &paymentServer{})

    fmt.Println("Payment Service running on port 50051...")

    // 서버 실행
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

🧾 왜 효과가 있었을까?
gRPC는 Protobuf를 사용해 JSON보다 약 10배 빠른 직렬화 성능을 제공합니다.
또한 HTTP/2 기반 멀티플렉싱을 통해 하나의 연결로 다수의 요청을 처리할 수 있어, 네트워크 오버헤드와 지연을 크게 줄일 수 있습니다.

---

⚖️ 3. 로드 밸런싱 & Redis 캐싱으로 응답 속도 개선하기

API 성능을 고루틴, gRPC를 통해 최적화한 후,
여러 인스턴스로 부하를 분산시키기 위해 NGINX + 라운드로빈(Round Robin) 방식의 로드 밸런서를 도입했습니다.

하지만 문제가 남아 있었습니다.
트래픽이 많아질수록 동일한 DB 쿼리가 반복되며 전체 성능을 떨어뜨리고 있던 것입니다.

✅ 해결책: Redis를 활용한 캐싱 도입
자주 조회되는 데이터(예: 최근 결제 내역)를 Redis에 캐싱하여,
매 요청마다 DB를 거치지 않도록 변경했습니다.

📦 예제 코드 (Go + Redis)

package main

import (
    "context"
    "fmt"

    "github.com/go-redis/redis/v8"
)

// Redis 명령 실행 시 사용할 Context
var ctx = context.Background()

func main() {
    // Redis 클라이언트 초기화
    rdb := redis.NewClient(&redis.Options{
        Addr: "localhost:6379", // Redis 서버 주소
        // Password, DB 등 추가 설정 가능
    })

    // Redis에 데이터 저장 (key: lastTransaction, value: txn_123456)
    err := rdb.Set(ctx, "lastTransaction", "txn_123456", 0).Err()
    if err != nil {
        panic(err) // 실무에서는 로그 처리 권장
    }

    // Redis에서 데이터 조회
    val, err := rdb.Get(ctx, "lastTransaction").Result()
    if err != nil {
        panic(err)
    }

    fmt.Println("Cached Transaction:", val)
}

💡 왜 효과적이었을까?
Redis에 결과를 캐싱함으로써 DB 요청 수를 약 80% 줄일 수 있었고,
응답 시간은 평균 50ms → 5ms 이하로 감소했습니다.

🧠 실무에서 자주 사용하는 Redis 캐싱 전략

전략	설명	예시
읽기 중심 데이터 캐싱	조회 빈도가 높은 데이터를 Redis에 저장하여 DB 부하 감소	사용자 정보, 최근 결제, 인기 상품
TTL(Time To Live) 설정	일정 시간 후 캐시를 자동 만료시켜 데이터 일관성 유지	60초 TTL 설정
Lazy-loading (Cache-aside)	캐시에 없을 경우 DB에서 조회하고 Redis에 저장하는 방식	성능과 일관성 균형
예외 처리 및 장애 대비	Redis 장애 시 DB로 대체 조회 처리 (fallback)	if err != redis.Nil 등 체크

🚀 캐싱 도입 시 실무 팁
Redis는 네트워크 비용이 거의 없고 속도가 빠르기 때문에,
DB 요청 수를 줄이고 전체 응답 지연(latency)을 획기적으로 줄이는 데 매우 효과적입니다.

단, 캐싱에 의존한 로직은 TTL 설정, 동기화 전략, 캐시 무효화 정책을 명확히 해야 합니다.

---

📈 4. Kubernetes & 오토스케일링으로 100만 RPS까지 확장하기

최적화된 API를 완전히 Docker로 컨테이너화한 후,
Kubernetes 클러스터에 배포하고 자동 확장(Auto-Scaling)을 활성화했습니다.

이 단계에서 우리는 수평 확장(Horizontal Scaling) 을 통해
트래픽 급증 상황에서도 서비스가 멈추지 않도록 탄력적인 인프라를 구성할 수 있었습니다.

🧾 Kubernetes Deployment 구성 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service  # 리소스 이름
spec:
  replicas: 10  # 초기 복제본 수 (HPA에 의해 동적으로 변경 가능)
  selector:
    matchLabels:
      app: payment-service  # 파드를 선택할 기준
  template:
    metadata:
      labels:
        app: payment-service
    spec:
      containers:
        - name: payment-service
          image: myregistry/payment-service:v1  # 컨테이너 이미지
          ports:
            - containerPort: 50051  # gRPC 포트

🔄 오토스케일링을 위한 추가 구성 (HPA)
Deployment만으로는 자동 확장이 활성화되지 않기 때문에,
HorizontalPodAutoscaler(HPA) 리소스를 별도로 생성해야 합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service
  minReplicas: 5
  maxReplicas: 100
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

✅ 왜 효과적이었을까?
Kubernetes는 트래픽 증가 시 자동으로 파드 수를 확장해주기 때문에,
트래픽이 갑자기 몰려도 서비스 중단 없이 탄력적으로 대응할 수 있습니다.

---

🏁 최종 결과: 초당 100만 요청, 다운타임 0
이 모든 최적화 과정을 거친 결과,
우리의 백엔드는 초당 1,000,000 요청(RPS) 을 안정적으로 처리할 수 있었고,
지연(latency)은 낮게 유지되었으며, 다운타임은 단 한 번도 발생하지 않았습니다.

✅ 고루틴 최적화를 통해 CPU 부하를 크게 줄였고
✅ gRPC 전환으로 REST 대비 API 성능을 비약적으로 향상시켰으며
✅ Redis 캐싱으로 DB 쿼리 수를 획기적으로 줄였고
✅ Kubernetes 오토스케일링으로 피크 트래픽에도 무중단 대응이 가능해졌습니다.

💡 배운 점

스케일링은 단순히 서버 수를 늘리는 것이 아닙니다.
진정한 확장은 시스템의 모든 계층을 정밀하게 최적화하는 것에서 시작됩니다.