백패커의 Amazon EKS 운영 최적화 여정 1부: 운영 핵심 요소 최적화

백패커는 국내 최대 핸드메이드 마켓 플레이스인 아이디어스와 크라우드 펀딩 플랫폼, 텀블벅을 운영하고 있습니다. 2022년, 백패커는 지속적으로 성장 중인 서비스를 안정적이고 유연하게 운영하기 위하여 안정성, 확장성, 보안성, 비용절감, MSA 환경에 보다 친화적인 컨테이너 환경을 제공하는 Amazon EKS를 도입하여 현재까지 사용자에게 안정적으로 서비스를 제공하고 있습니다.

특히 아이디어스는 한국 서비스에서 글로벌 서비스로 확장되면서 인프라 서비스의 유연성이 점점 더 중요해지고 있습니다. 이에 대응하기 위해 Amazon Elastic Kubernetes Service(Amazon EKS) 멀티 클러스터를 구축했지만, 운영 과정에서 다양한 문제와 어려움에 직면했습니다. 백패커 역시 Amazon EKS 운영 중 여러 도전과제를 경험하며 이를 해결하기 위해 많은 시간과 노력을 투자했습니다. 이 게시글에서는 저희가 직면했던 주요 문제점들과 그 해결 방안을 공유하여, Amazon EKS를 더욱 안정적으로 운영하는 데 도움이 되는 실용적인 팁을 제공하고자 합니다.

Amazon EKS 를 선택한 이유와 당면 과제

Amazon EKS는 AWS와 온프레미스 데이터 센터에서 Kubernetes를 원활하게 운영할 수 있는 완전관리형 서비스입니다. 클라우드 환경에서 EKS는 Kubernetes 클러스터 인프라 관리를 자동화하여 컨테이너 예약, 애플리케이션 가용성 관리, 동적 리소스 확장, 컴퓨팅 최적화, 클러스터 데이터 저장 등 핵심 기능을 효율적으로 처리합니다. EKS를 통해 AWS 인프라의 뛰어난 성능, 확장성, 신뢰성 및 가용성을 활용할 수 있으며, AWS의 네트워킹, 보안, 스토리지 서비스와도 원활하게 통합됩니다.

그러나 이러한 광범위한 자동화에도 불구하고, 실제 운영 환경에서는 여전히 세심한 관리와 지속적인 모니터링이 필요합니다. 특히 프로덕션 환경에서는 AWS가 제공하는 관리 영역을 넘어서는 예기치 못한 복잡한 문제들이 자주 발생합니다. 이러한 문제들은 성능 저하, 네트워크 불안정성, 리소스 병목 현상 등 다양한 형태로 나타나며, 신속하고 정확한 트러블슈팅 능력이 필수적입니다.

이 게시글에서 소개해드릴 EKS 운영 최적화 과정에서 직면하고 해결한 주요 과제들은 다음과 같습니다.

1. CoreDNS 부하 분산 및 고가용성 확보
2. MySQL Connection Reset 이슈
3. istio 환경에서 MSA 서비스 간 호출 시 Connection Reset 이슈

CoreDNS 부하 분산 및 고가용성 확보

CoreDNS는 Kubernetes 클러스터 내에서 서비스 디스커버리의 핵심이 되는 DNS 서버입니다. 컨테이너화된 마이크로서비스 아키텍처에서 서비스 간 통신을 위한 이름 해석을 담당하며, 클러스터 내 모든 네트워크 요청의 시작점이라고 할 수 있습니다. 유연한 플러그인 아키텍처를 통해 다양한 기능을 제공하며, Kubernetes의 공식 DNS 솔루션으로 채택되었습니다.

Amazon EKS 클러스터를 생성하면 기본적으로 CoreDNS는 단순히 2개의 Pod로 구성됩니다. 이는 소규모 클러스터나 개발 환경에서는 충분할 수 있으나, 대규모 프로덕션 환경에서는 심각한 병목 현상을 초래할 수 있습니다. DNS는 서비스 운영에서 단일 장애점(Single Point of Failure)이 될 수 있는 매우 중요한 요소로, 고가용성과 확장성을 갖춘 안정적인 동작이 필수적입니다.

아이디어스 서비스 초기 Amazon EKS 클러스터 구성 시에는 CoreDNS에 대한 특별한 최적화 없이 기본 설정만 적용되어 있었습니다. 단순히 nodeSelector를 통해 운영용 노드 그룹(On-Demand 타입)에 배치하고 Pod 2개로 운영했습니다. 이러한 기본 구성은 트래픽이 급증하는 상황이나 대규모 클러스터 환경에서 DNS 병목 현상을 야기했고, 다음과 같은 심각한 문제를 초래했습니다.

1. DNS 요청 급증 시 도메인 쿼리 응답 지연 및 쿼리 실패 발생
2. 리소스 압박 상황에서 CoreDNS Pod의 CrashLoopBackOff로 인한 서비스 전면 장애

문제 발생 원인

1. ndots 기본 설정 문제

ndots는 Kubernetes 환경에서 DNS 조회 방식을 결정하는 중요한 매개변수입니다. 이 값은 도메인 이름에 포함된 점(.)의 개수를 기준으로 DNS 조회 순서와 방식을 제어합니다. Kubernetes에서는 기본적으로 모든 Pod의 /etc/resolv.conf 파일에 ndots:5 옵션이 설정되어 있습니다. 이 설정의 의미는 다음과 같습니다.

• 도메인 이름에 포함된 점(.)의 개수가 ndots 값(5)보다 적으면, 시스템은 해당 도메인을 ‘불완전한 이름’으로 간주합니다.
• 불완전한 이름으로 간주된 도메인은 먼저 검색 도메인 목록(search domains)에 나열된 모든 suffix를 차례로 붙여 조회를 시도한 후, 그래도 실패하면 마지막에 원래 이름 그대로 조회합니다.

이러한 ndots 기본값(5)은 대부분의 일반적인 외부 도메인(예: aws.amazon.com)이 점 개수가 5개 미만이기 때문에, 불필요한 DNS 조회 시도를 여러 번 하게 만듭니다.

이 문제는 소규모 트래픽의 개발(Dev)이나 스테이징(Stage) 환경보다는 대규모 트래픽이 발생하는 프로덕션(Production) 환경에서 더 두드러지게 나타납니다. 백패커 역시 서비스 초기에는 간헐적으로 원인을 명확히 파악하기 어려운 서비스 에러가 발생했습니다.

트러블 슈팅 과정에서 처음에는 애플리케이션 코드, Node 리소스, Pod 상태, Container 설정 등 다양한 시스템 요소를 점검했습니다. 하지만 RDS나 Redis 등의 외부 서비스 호출 시 간헐적인 연결 실패가 발생했으며, 면밀한 조사 결과 DNS Resolve 실패가 근본 원인임을 확인했습니다. 그래서 초기에는 CoreDNS의 캐시 설정이나 버퍼 크기(bufsize) 등을 튜닝하여 문제를 해결하려 했으나, 이는 증상을 일시적으로 완화할 뿐 근본적인 해결책이 되지 못했습니다.

결국 문제의 핵심은 Kubernetes의 기본 ndots 설정으로 인한 과도한 DNS 조회 요청이었습니다. 예를 들어 idus.com과 같이 점이 1개인 도메인을 조회할 경우, 다음과 같은 순서로 최대 5번의 DNS 조회가 이루어집니다.

- idus.com.idus-backends.svc.cluster.local
- idus.com.svc.cluster.local
- idus.com.cluster.local
- idus.com.ap-northeast-2.compute.internal
- idus.com

이처럼 단일 외부 도메인에 대해 실제로는 마지막 시도에서만 성공하는 불필요한 조회가 반복됩니다. 결과적으로, 특정 서비스에서 idus.com을 호출할 때마다 1번이 아닌 5번의 질의가 발생하므로, 서비스 트래픽이 급증하는 상황에서는 CoreDNS에 과도한 부하가 집중되어 전체 클러스터 성능에 영향을 미치게 됩니다.

TIP: 도메인 호출 시 마지막에 점(.)을 붙이면(예: idus.com.) 시스템은 해당 도메인을 ‘완전한 도메인 이름(FQDN)’으로 인식하여 검색 도메인을 붙이지 않고 단일 조회만 시도합니다. 하지만 이 방식은 애플리케이션 코드나 설정 파일에서 모든 도메인 참조를 수정해야 하므로, 각 서비스 환경과 개발 상황에 맞게 적용하는 것이 좋습니다. 백패커에서는 유지보수성을 고려하여 이 방식을 채택하지 않았습니다.

2. CoreDNS 고가용성 설정 부족

클러스터 초기 운영시 CoreDNS Pod가 On-Demand 노드 그룹에 배치되었으며, 특정 시점에 모든 CoreDNS Pod가 한 Node에 몰리는 상황이 발생했습니다.

이 때 문제가 된 Node의 메모리 사용률이 급증했고, 해당 Pod는 메모리 제한(Limit)이 없는 BestEffort QoS Class로 설정되어 있었습니다. 결과적으로 Node 메모리가 고갈되면서 OOM(Out of Memory)이 발생했고, Kubelet 데몬이 동작하지 않으면서 해당 Node의 모든 Pod가 CrashLoopBackOff 상태에 빠졌습니다. 이로 인해 CoreDNS도 응답하지 못하며 서비스 전면 장애로 이어졌습니다.

문제 해결 방법

백패커는 아래와 같은 설정을 통해 문제를 해결했습니다. 핵심은 CoreDNS 부하 분산과 고가용성 확보입니다. 아래와 같은 방법들을 통해 CoreDNS의 부하 분산과 고가용성을 확보할 수 있었습니다. 각 회사의 환경에 맞춰 적절히 조정해 적용하시길 추천드립니다.

1. NodeLocalDNS Cache 사용

NodeLocalDNS Cache는 Kubernetes에서 제공하는 공식 솔루션으로, CoreDNS 앞단에서 DNS 질의를 처리하는 서비스입니다. DaemonSet 형태로 배포되며 각 Node에서 DNS 캐싱을 수행해 CoreDNS의 부하를 줄일 수 있습니다.

2. Pod 고가용성 설정

최신 Amazon EKS 버전에서는 기본적으로 아래와 같은 고가용성 설정이 적용됩니다:

• PodDisruptionBudget (PDB):

{
    "podDisruptionBudget": {
        "enabled": true,
        "maxUnavailable": 1
    }
}

• TopologySpreadConstraints:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

과거 Amazon EKS 버전에서는 이러한 설정이 없었으나 현재는 기본 제공됩니다. 추가적으로 CoreDNS Pod를 별도 노드 그룹이나 Fargate 환경으로 분리하면 리소스 공유로 인한 부하를 최소화할 수 있습니다.

TIP: Affinity와 PriorityClassName 등을 활용해 우선순위를 설정하면 안정성을 더욱 강화할 수 있습니다.

3. ndots 값 조정(5 → 2)

ndots 값을 낮추면 불필요한 DNS 조회 횟수를 줄일 수 있습니다. 다음은 Deployment에서 dnsConfig 옵션을 통해 설정하는 예시입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  namespace: example
spec:
  containers:
  …
  …
  dnsConfig:
    options:
    - name: ndots
      value: "2"
  …
  …

하지만 이 설정은 여러 레퍼런스에서 1이나 2로 낮추는 걸 권장하지만 각 회사의 상황에 맞춰 설정하는 걸 추천드립니다. 또한 운영 중인 환경에서 Helm 차트를 통해 일괄 설정하기 어려운 경우, 별도의 Controller를 만들어 Pod 생성 시 CRD 설정을 Patch하는 방법도 고려할 수 있습니다.

4. Istio DNS Proxying 기능 사용

Istio DNS Proxying은 서비스 메시 환경에서 DNS 해결을 최적화하는 기능입니다. 이 기능을 활성화하면 istio 사이드카 컨테이너가 Pod 내의 DNS 쿼리를 가로채어 직접 처리할 수 있습니다. 따라서 istio 사이드카 컨테이너를 활용해 DNS 질의를 직접 처리하도록 설정하면 CoreDNS 부하를 줄일 수 있습니다. 백패커에서는 NodeLocalDNS Cache와 중복되는 기능이라 사용하지 않았지만, 테스트 시 DNS 응답 속도가 개선될 가능성이 있었습니다.

MySQL Connection Reset 이슈

서버 로그를 점검하던 중, 간헐적으로 발생하는 Caught mysqli_sql_exception (500): MySQL server has gone away 에러 메시지에 대한 제보를 받았습니다. 이 에러는 MySQL 연결이 예기치 않게 끊어질 때 발생하는 일반적인 오류로, 여러 원인이 있을 수 있습니다. 로그를 분석한 결과, 이러한 오류가 지속적으로 기록되고 있었으며 특정 패턴 없이 간헐적으로 발생하는 것으로 확인되었습니다. APM 지표를 확인한 결과, mysqli.connect 연결 시점에서 지속적인 연결 오류가 발생하고 있음을 명확히 볼 수 있었습니다.

해당 문제 해결을 위해 다양한 접근 방식을 시도했습니다:

• APM Trace 정보를 통한 문제 발생 패턴 분석
• tcpdump를 활용한 네트워크 패킷 분석
• 시스템 로그 및 MySQL 서버 로그 검토
• 애플리케이션 코드에서의 DB 연결 관리 방식 점검

하지만 이러한 방법으로도 구체적인 해결책을 찾기 어려웠습니다. 트러블슈팅을 계속 진행하던 중, 여러 기술 블로그와 Kubernetes 관련 레퍼런스를 검토하다가 쿠버네티스 클러스터 환경에서 발생하는 Connection Reset 이슈와 관련된 글에서 문제 해결의 실마리를 발견할 수 있었습니다.

문제 발생 원인

주요 원인은 nf_conntrack_tcp_be_liberal 커널 설정 값과 연관이 있었습니다. 기본적으로 이 값이 0으로 설정되어 있는 경우, 쿠버네티스의 NAT(Network Address Translation) 환경에서 out-of-window(지연되거나 손실된) 패킷을 INVALID로 표시합니다. 이때 nf_conntrack 모듈은 해당 패킷에 대한 ACK를 받지 못했다고 판단하고 잘못된 주소로 RST(Connection Reset) 패킷을 전송하게 됩니다. 이러한 과정에서 정상적인 TCP 연결이 갑자기 끊기는 현상이 간헐적으로 발생하며, 특히 MySQL과 같은 데이터베이스 연결에서 “MySQL server has gone away” 오류로 나타나게 됩니다.

반면, 이 값을 1로 설정하면 TCP 프로토콜의 패킷 추적에 있어 더 관대한(liberal) 모드로 동작합니다. out-of-window 패킷을 INVALID로 표시하지 않고 무시하거나 정상 처리하며, 비정상적인 시퀀스 번호를 가진 패킷에 대해서도 연결을 끊지 않고 유지합니다. 이는 네트워크 지연이나 패킷 손실이 있는 환경에서도 TCP 연결의 안정성을 향상시키며, 특히 Kubernetes와 같은 컨테이너 오케스트레이션 환경에서 NAT와 로드 밸런싱을 사용할 때 발생하는 Connection Reset 문제를 크게 줄일 수 있습니다.

문제 해결 방법

이 문제를 해결하기 위해 nf_conntrack_tcp_be_liberal 값을 1로 설정하여 잘못된 패킷을 INVALID로 표시하지 않도록 변경했습니다.

• 0 설정(기본값): 모든 INVALID 패킷을 DROP
• 1 설정(수정값): INVALID 패킷도 전달

쿠버네티스 환경에서 이를 적용하기 위해 해당 커널 값을 세팅하는 데몬셋(DaemonSet)을 배포했습니다. 데몬셋은 클러스터의 모든 노드에서 실행되어 각 노드의 커널 파라미터를 일괄적으로 설정할 수 있게 해줍니다. 아래는 데몬셋 CRD와 values.yaml 예시 코드입니다.

# node-optimizer.yaml
{{- if eq .Values.nodeOptimizer.enabled true }}
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-optimizer
  namespace: kube-system
  labels:
    app: node-optimizer
spec:
  selector:
    matchLabels:
      name: node-optimizer
  template:
    metadata:
      labels:
        name: node-optimizer
    spec:
      priorityClassName: system-node-critical
      hostNetwork: true
      hostPID: true
      hostIPC: true
      initContainers:
      - name: init-config
        image: "{{ .Values.account }}.dkr.ecr.ap-northeast-2.amazonaws.com/idus/iptables-for-eks:{{ .Values.nodeOptimizer.image.version }}"
        imagePullPolicy: Always
        securityContext:
          privileged: true
          capabilities:
            add:
            - NET_ADMIN
        resources: {}
        command:
        - sh
        - -c
        - {{ toYaml .Values.nodeOptimizer.command | nindent 10 }}
        volumeMounts:
          - name: modifysys
            mountPath: /sys
      containers:
      - name: sleepforever
        image: "{{ .Values.account }}.dkr.ecr.ap-northeast-2.amazonaws.com/idus/iptables-for-eks:{{ .Values.nodeOptimizer.image.version }}"
        resources:
          requests:
            cpu: 0.01
        command: ["/bin/sh", "-c"]
        args:
        - >
          while true; do
          sleep 100000;
          done
      {{- with .Values.nodeOptimizer.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.nodeOptimizer.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      volumes:
      - name: modifysys
        hostPath:
          path: /sys
{{- end }}

# values.yaml
nodeOptimizer:
  enabled: true
  image:
    version: "latest"
  nodeSelector: {}
  command: |
    …
    …
    sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1
    …
    …
  affinity: {}

위와 같이 설정하여 데몬셋을 배포하면, 모든 노드에서 데몬셋 파드가 실행됩니다. 해당 파드의 hostNetwork가 true로 설정되어 있기 때문에, initContainer가 실행되면서 전체 노드의 커널 설정(nf_conntrack_tcp_be_liberal=1)이 적용됩니다.

설정을 적용한 이후, 기존에 간헐적으로 발생하던 MySQL Connection Reset 문제가 완전히 해결되었습니다(위 그림 참고). 적용 전에는 주당 약 200-250건의 에러가 발생했으나, 적용 후에는 에러 건수가 0건으로 감소했습니다. 이러한 방식으로 MySQL Connection Reset 이슈를 효과적으로 해결할 수 있었으며, 유사한 문제가 발생하는 다른 환경에서도 동일한 접근법을 활용할 수 있을 것입니다.

Isito 환경에서 MSA 서비스 간 호출시 Connection Reset 이슈

아이디어스는 현재 50개 이상의 마이크로서비스(MSA)를 운영하고 있으며, 이들 서비스 간의 통신 관리를 위해 Istio Service Mesh를 활용하고 있습니다. 서비스 간 통신은 두 가지 방식으로 이루어집니다. 하나는 서비스들이 서로 직접 API를 호출하는 방식이고, 다른 하나는 Aggregation 서비스를 통한 방식입니다.

Aggregation 서비스는 메인 API Gateway 역할을 담당하며, 클라이언트의 요청을 받아 필요한 여러 MSA 서비스들에 분산하여 처리합니다. 이를 통해 클라이언트는 단일 엔드포인트로 요청을 보내고, Aggregation 서비스가 여러 백엔드 서비스의 응답을 취합하여 반환함으로써 클라이언트의 부담을 줄이고 시스템의 확장성을 높입니다.

문제는 이 Aggregation 서비스가 각 MSA 서비스로 API를 호출하는 과정에서 발생했습니다. 시간당 약 300-500만 건 이상의 API 호출 중 약 0.001% 미만의 확률로 Connection Reset 오류가 발생했으며, 이는 시간당 약 10-50건의 에러에 해당합니다. 다행히 Istio의 자동 재시도(retry) 메커니즘 덕분에 이러한 일시적인 오류가 최종 사용자에게 영향을 미치지는 않았습니다.

문제 발생 원인

이 문제는 오랜 기간 지속되었지만 우선순위가 낮아 다양한 트러블슈팅을 진행하면서도 명확한 원인을 찾기 어려웠습니다. Container, Pod, Node 레벨에서 tcpdump를 수행하고, 각 서비스의 TCP 및 HTTP 설정(timeout, idle timeout, keepalive), NLB, istio 설정 등을 점검했지만 뚜렷한 해결책을 찾지 못했습니다.

그러던 중 우연히 다른 장애 건을 조사하던 과정에서 관련 메트릭을 확인하게 되었고, istio 사이드카 컨테이너에서 TCP 연결 시 간헐적으로 Connection Reset 오류가 발생한다는 사실을 발견했습니다. 특히 istio_tcp_connections_opened_total 지표에서 “UF, URX”라는 response_flags가 발생할 때 애플리케이션에서 Connection Reset 에러가 발생한다는 점을 확인했습니다. 로그 발생 시간과 해당 “UF, URX” 플래그가 일치하는 것을 아래 그림에서 확인할 수 있었습니다.

istio 공식 문서(아래 그림 참고)에 따르면, UF는 TCP 연결 실패를 의미하며, URX는 TCP 연결 시도 횟수가 초과되었음을 나타냅니다. 기본적으로 istio의 최대 연결 시도 횟수는 1회로 설정되어 있어, TCP 연결에 문제가 발생하면 단 한 번만 시도하고 실패하는 구조입니다.

문제 해결 방법

결국 istio의 최대 연결 시도 횟수를 1회에서 5회로 상향 조정하여 문제를 해결했습니다. 아래는 istio의 EnvoyFilter CRD 예시 코드입니다.

{{- if .Capabilities.APIVersions.Has "networking.istio.io/v1alpha3/EnvoyFilter" }}
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: max-connect-attempts
  namespace: istio-system
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.tcp_proxy
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          max_connect_attempts: 5
{{- end }}

설정을 적용한 후 약 4시간 동안 로그를 조회한 결과, Connection Reset 에러가 단 한 건도 발견되지 않았습니다. 기존에는 1시간당 약 10-50건의 에러가 발생했지만, 이 패치를 통해 문제를 완전히 해결할 수 있었습니다.

이 문제는 네트워크 사용량이 많은 API 서비스에서 간헐적으로 TCP 연결 문제가 발생했던 것으로 결론 내렸습니다. 그러나 해당 설정은 재시도 횟수를 증가시키는 방식이므로, 실제 프로덕션 환경에서는 보수적으로 세팅할 것을 권장합니다. 백패커는 현재까지 이 설정을 유지 중이며, 추가적인 이슈 없이 안정적으로 운영되고 있습니다. 유사한 문제가 발생하는 환경에서도 이 해결책을 효과적으로 활용할 수 있을 것입니다.

마무리

이번 글에서는 백패커가 Amazon EKS를 운영하면서 마주한 세 가지 주요 문제와 그 해결책을 공유해 드렸습니다. CoreDNS 부하 분산 및 고가용성 확보, MySQL Connection Reset 이슈, 그리고 Istio 환경에서 MSA 서비스 간 호출 시 발생하는 Connection Reset 이슈 등 실제 프로덕션 환경에서 발생한 문제들에 대한 트러블슈팅 과정과 해결 방법을 상세히 설명했습니다.

다음 게시글 “백패커의 Amazon EKS 운영 최적화 여정 2부: 운영 심화 및 장애 대응 사례”에서는 보다 실전적인 EKS 운영 상황과 실제 장애 대응 사례를 다룰 예정입니다. Spot 인스턴스 활용에 따른 장애 사례와 대응 방안을 심도 있게 살펴보며, 비용 효율성을 높이면서도 안정성을 확보하는 전략을 소개합니다. 또한 실제 대규모 트래픽 급증 상황에서 발생했던 전면 서비스 장애 사례와 극복 과정을 상세히 공유합니다. 갑작스러운 트래픽 증가로 인한 시스템 병목 현상, 실시간 대응 전략, 그리고 장기적인 시스템 개선 방안까지 백패커의 생생한 경험을 바탕으로 한 실용적인 인사이트를 제공해 드리겠습니다.