EKS Fargate 를 기본사양으로 약 1달 정도 사용해 봤다. Fargate 의 기본사양(최소사양)은 vCPU 0.25 / memory 0.5GB 이다. 1개의 CPU 코어가 2 vCPU 니까 0.25면... Spring Jar 파일 돌리는데 부팅시 스프링 로그가 2초에 1줄 정도씩 나왔나. 당연히 부팅시간도 상당히 늘어난다. ALB 의 health check 도 길어지고... 부팅된 후에는 Lazy 설정 때문에 Slave DataSource 가 처음 세팅될 때도 10초 이상의 응답으로 Timeout 이 발생하기도 했다. 그것 빼고는 단일 어플리케이션 돌아가는데 큰 문제는 없어보였다. 이것저것 다 빼다보면 어디다 써야할지... t2.nano 보다도 낮은 사양... 우선 xms / xmx 을 확인해 봤다.

public static void main(String[] args) {
    int mb = 1024 * 1024;
    MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
    long xmx = memoryBean.getHeapMemoryUsage().getMax() / mb;
    long xms = memoryBean.getHeapMemoryUsage().getInit() / mb;
    logger.info("xms: {}", xms);
    logger.info("xmx: {}", xmx);
}

// print
xms: 8
xmx: 123

오마이... 저런 단위는 처음보는 수치이다. 이 상태로 잘도 돌아갔다. 일단 컴퓨팅 사양부터 높였다.

vCPU 1개(1000m) 당 : 월 $1.2
memory 1GB 당 : 월 $1.3

pod 를 정의한 deployment yaml 파일에서 cpu 와 memory 를 수정하였다.

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

$ vi my-deployment.yaml
...
spec:
  containers:
  - name: web
    image: 1234567890.dkr.ecr.ap-northeast-2.amazonaws.com/web:latest
    resources:
      limits:
        cpu: 1
        memory: 2048Mi
      requests:
        cpu: 1
        memory: 2048Mi

$ kubectl describe pods podname -n mynamespace
...
Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB

재배포하였으나 cpu / memory 는 변경되지 않았다. 어딘가에 제한이 걸려있는 느낌.

LimitRange 를 사용하여 namespace 레벨에서 cpu 와 memory 를 설정해 보았다.

$ my-usage-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: low-usage-range
spec:
  limits:
  - max:
      cpu: 2
      memory: 4G 
    min:
      cpu: 1
      memory: 1G
    type: Container
    
$ kubectl apply -f my-usage-range.yaml -n my-namespace

다시 재배포해보니 잘 바뀌었다.

$ kubectl describe pods podname -n mynamespace
...
Annotations:          CapacityProvisioned: 1vCPU 3GB
...
    Limits:
      cpu:     1
      memory:  2048Mi
    Requests:
      cpu:     1
      memory:  2048Mi

뭔가 바뀌었지만 memory 2048Mi 를 설정했는데 3GB 로 세팅됐다. Fargate 는 각 pod 의 메모리 예약에 256MB 를 추가하기 때문에 기본 단위상 1G가 더 늘어났다. 256MB 를 제외하고 1792Mi 로 설정하면 2G로 뙇!

Dockerfile 에 Xms / Xmx 설정도 뙇!

ENTRYPOINT ["java","-Xms1024m","-Xmx1792m","-jar","/app.jar"]

톰캣 재부팅 실패. STOP 실패. 시작할 때 실패는 많이 해봤어도 중지하는데 실패하는 건 처음;

catalina.out 파일를 보았다.

메모리가 부족하여 JRE 를 계속 진행할 수 없다는...

/tmp/jvm-8091/hs_error.log 파일을 보니 머가 머라머라 쥘쥘 많다.

암튼 Out of memory.

원인

- 시스템의 물리적 RAM 또는 스왑 공간이 부족.

- 프로세스 크기 제한에 도달.

해결 방법

- 시스템의 메모리 로드 줄이기.

- 물리적 메모리 또는 스왑 공간 늘리기.

- 스왑 백킹 저장소가 가득 차 있는지 확인.

- 64 비트 OS에서 64 비트 Java 사용.

- Java 힙 크기 줄이기 (-Xmx / -Xms).

- Java 스레드 수 줄이기

- Java 스레드 스택 크기 줄이기 (-Xss)

- -XX:ReservedCodeCacheSize= 를 사용하여 더 큰 코드 캐시 설정

위에서 아무것도 수정할 수 없다면!

overcommit_memory 를 일시적으로 1로 설정하여 커널의 memory overcommit 처리를 수행하지 않도록 수정한다.

기본값은 0으로, 커널이 사용 가능한 메모리 양을 추정하고 잘못된 요청을 실패시켜 휴리스틱 메모리 오버커밋 처리를 수행하지만, 메모리가 오버로드될 수 있다.

관리자 권한으로 해야 한다.

docker 설치 후 docker info 를 확인하자 마자 보이는 경고.

에러를 안나타나게 하려면, 시스템에서 cgroup 에 메모리와 스왑 메모리 관리를 사용할 수 있게 하면 된다.

메모리와 스왑 메모리를 사용 가능하게 하면 Docker 를 사용하지 않을 때도 메모리 오버헤드(약 1%), 성능 저하(약 10%)를 유발한다.

GNU GRUB(GRand Unified Bootloader)을 수정하여 cgroup 에 메모리와 스왑메모리를 가능하게 할 수 있다.

변경된 GRUB 을 적용하고 재부팅한다.

여기까지가 문서에 있는 얘기고...

현재 커널이 cgroup swap 메모리 제한을 하고 있지 않다는 것인데.

이것을 가능하게 세팅하고 나면 성능 저하가 생긴다는게 말인가 방구인가.

Docker 를 위해서 시스템의 성능을 저하시킨하는게 말인가 방구인가.

Docker 돌리는데는 이러나 저러나 지장은 없지만 이게 무슨 말인지 정말 궁금하긴 하다.

이것때매 cgroup 까지 찾아보기는 좀...ㅜ