DC/OS 설치 후 성능 이슈

안녕하세요.

D2IQ(Mesosphere) 의 DC/OS 설치 후 성능 이슈에 대한 설명을 하려고 합니다.

이 성능 이슈는 아래와 같은 버전에서 모두 발생했었습니다.

 

• DC/OS 버전 : 1.11.10, 1.12.0, 1.13.3

DC/OS 서비스에 의해 문제가 발생한건 아니지만 DC/OS의 설치 환경에 의해 발생한 것이니 카테고리를 DC/OS에 포함시켰습니다. 

 

· 문제점

Java 로 구동되는 어플리케이션이 있었는데 DC/OS가 아닌 서버에서 Docker(network는 host, bridge 둘다 테스트) 컨테이너로 구동 시 nGrinder 에서 보여지는 TPS가 약 1200~1500 이 발생.

 

하지만 동일한 장비로 DC/OS에 투입 후 테스트 시 TPS는 400-600 으로 떨어지는 현상이 발생.

DC/OS에서는 동일하게 Core/메모리를 모두 할당했었고, nGrinder의 테스트 방식도 동일했다.

 

이 외 Marathon-LB 가 아닌 Agent 로 직접 호출을 했음에도 문제는 해결되지 않았다.

 

· 문제 확인

문제점을 확인하기 위해서 단계적으로 테스트를 진행을 했었다.

 

1. 운영체제 설치 후 도커 컨테이너를 구동하여 테스트 (정상)
2. DC/OS 환경 설정 (NTP 설정, /etc/hosts 파일 편집, 패키지 등 설치) (정상)
3. DC/OS 에이전트 노드로 투입 후 테스트 (비정상)

 

3번 진행 후 테스트 했을 때 문제가 발생했었고 설치 스크립트를 모두 뜯어서 분석하고 확인하기에는 너무나 오랜 시간이 걸릴 것 같았다. 이때 운영체제 재설치가 아닌 DC/OS Uninstall을 하면 어떻게 될까? 라는 생각으로 진행했었다.

그리고 DC/OS Uninstall은 동일한 장비에서만 진행을 했다.

1. systemctl stop dcos*
2. rm -rf /var/run/mesos /var/lib/mesos /opt/mesosphere/ /etc/mesosphere/ /run/dcos/ /var/lib/dcos/ /etc/systemd/system/dcos* /etc/profile.d/dcos.sh /etc/systemd/journald.conf.d/dcos.conf /etc/systemd/system/multi-user.target.wants/dcos-setup.service /etc/systemd/system/multi-user.target.wants/dcos.target && systemctl daemon-reload
3. sync ; reboot

(현재는 DC/OS 자체적으로 uninstall 스크립트를 제공하고 있음 : 링크)

 

3번까지 한번에 모두 완료했을 때 TPS은 정상적으로 1200 - 1500 을 유지했다.

역시 문제는 DC/OS 라고 판단했었다.

 

1. systectl stop dcos*
2. rm -rf /etc/systemd/system/multi-user.target.wants/dcos.target && systemctl daemon-reload
3. rm -rf /etc/systemd/system/multi-user.target.wants/dcos-setup.service && systemctl daemon-reload
4. rm -rf /etc/systemd/journald.conf.d/dcos.conf && systemctl daemon-reload
5. ...

1번부터 진행하면서 테스트를 진행했고 DC/OS 서비스에 의해 자원 사용량이 제한 될꺼라 예상했지만 실패했다.

1번 진행 후 2번부터 삭제 할 대상을 순서대로 정리했고, 순서는 /opt/mesosphere 패키지 같은 것들이 아닌 단일 파일부터 DC/OS와 크게 관련이 없는 파일 단위부터 삭제를 시작했다. (이미 DC/OS 서비스가 종료되어있음에도 불구하고 성능이 나오지 않는다는건 DC/OS 패키지와 관련이 없다고 판단했었다)

정확한 테스트를 위해 각 단계 진행 시 재부팅을 진행했었다.

 

그리고 4번을 진행했을 때 TPS가 1200 ~ 1500 으로 정상적으로 나오기 시작했다.

확인해보니 DC/OS가 설치되면서 /etc/systemd/journald.conf.d/dcos.conf 이 생성되고 journald 에 의해 성능 이슈가 발생한 것이다. (CentOS 7 설치 시  /etc/systemd/journald.conf의 모든 설정 값은 주석처리 되어있습니다.)

 

/etc/systemd/journald.conf.d/dcos.conf

[Journal]
MaxLevelConsole=warning
RateLimitInterval=1s
RateLimitBurst=20000

옵션을 확인했을 때 warning 레벨 이상 (notice, info, debug)가 매 1초마다 Journal에 기록되는 내용이다.

 

Journal은 RHEL 7 에서 새로운 로깅 데몬이고 아래와 같은 메시지를 저장한다. (Journal이란?)

- syslog 메시지
- 커널 메시지
- 초기 RAM 디스크 및 초기 부팅 메시지
- 표준 출력 및 표준 오류 출력으로 전송되는 메시지

Journald 서비스의 CPU 사용량

현재 Java로 개발된 어플리케이션은 모든 로그가 stdout(표준 출력)되기 때문에 nGrinder 같은 부하 발생기를 사용 할 경우 Journal 서비스의 CPU 사용량 및 디스크 IO가 발생하며 이에 따라 어플리케이션이 사용할 자원까지 나눠서 사용하기 때문에 문제가 발생했었다.

 

· 문제 해결

문제점 해결은 매우 간단했다.

일반적인 시스템 로그 및 stdout(표준 출력)이 /var/log/message에도 기록하기 때문에 굳이 Journal 을 사용하여 성능 이슈를 감안하고 이중으로 사용 할 필요는 없었다.

rm -rf /etc/systemd/journald.conf.d/dcos.conf
systemctl restart systemd-journald.service
systemctl status systemd-journald.service 

위와 같이 진행했을 때 DC/OS 에서도 동일한 TPS을 보여줬으며 문제는 해결이 되었다.

 

· 마무리

journald은 DC/OS 뿐만 아니라 성능 이슈로 많이 언급이 되었던 서비스이고, 

이번에 처음 겪게 되었고 역시나 DC/OS은.. 문제 발생 했을 때 구글링하는 것보다 직접해결하는게 제일 빠르다고 느꼈습니다.

 

nGrinder 처럼 자원을 모두 사용 할 정도가 아니라면 DC/OS에서 기본적으로 제공해주는 /etc/systemd/journald.conf.d/dcos.conf 을 지울 필요는 없어보이지만 Journald 사용하지 않는다면 굳이 활성화 시킬 필요는 없을 것 같기도 합니다.

 

운영 환경에 따라서 판단을 알아서 하시면 될 것 같습니다.

 

· 추가

mesos_container_log_sink

https://docs.d2iq.com/mesosphere/dcos/1.13/installing/production/advanced-configuration/configuration-reference/?fbclid=IwAR0ZoC7X3DNAICiYnRuWZonYBXrZcl3-Ltmp5d76Q06JlyPjcTTZlbU2bwc#mesos-container-log-sink

Configuration Reference - D2iQ Docs

위 설명과 같이 systemd 버전을 업데이트 함으로써 해결 될 수 있으며

 

https://github.com/dcos/dcos-mesos-modules/blob/master/journald/README.md?fbclid=IwAR3uyr0m2shGnWgnUPNSrV7oVbBeJVKvYc1gjf7RSp8OZMkK3LomnsdsHmo

dcos/dcos-mesos-modules

모듈 변경으로도 방법을 회피 할 수 있습니다.

 

제가 설명한 것과 같이 dcos.conf 를 삭제함으로써 DC/OS log API에서 로그를 받지 못하는 부분이 발생 할 수도 있을 것 같은데 해당 부분은 직접 판단하시고 결정하시면 될 것 같습니다.

 

 

 

추가 조언을 해주신 민영근님에게 감사드립니다.