AIX 환경에서 동작하는 상태 수집기가 필요해요

Gunjoo Ahn·2024년 7월 6일
0

회고

목록 보기
11/11
post-custom-banner

AIX 환경에서 동작하는 상태 수집기가 필요해요

Tibero를 모니터링하는 제품인 만큼 기존 Tibero가 배포된 머신에 수집기 바이너리를 배포하여 실행시키고 있었다. 지금까지 AIX 환경에 바이너리를 배포한 경험이 없어서 단지 Unix 계열이라는 점만 믿고, C++ 빌드 다 되겠지라는 안일한 생각으로 빌드를 시도하였는데 생각보다 빌드가 번거로웠다(AIX 7.1에서 xlc 16.1 버전이 c++11를 부분지원해서 xlclang++로 빌드 시도). 빌드는 어찌저찌 겨우겨우 해냈지만 결국 실행을 실패하였다.

  • C++11
  • Boost 1.78
  • Avro 1.11.0

위 C++11 스펙에서 Boost와 Avro 라이브러리를 빌드하여 수집기 바이너리에 링킹하여 빌드하고 실행하면 되는 것이었는데, 어떻게 어떻게 빌드는 성공하였다. 그런데 실행을 하면 바로 죽는 것 아니겠는가. dbx 명령어로 확인해보니 첫 main 함수 들어가기도 전에 Boost 1.78 asio 라이브러리를 로드하다 죽는 것이었다. Boost 1.78 코드를 보고 고치자니 여기서부터는 더이상 유지보수가 불가능한 수준일 수 있겠다는 생각이 들어 AIX 환경 전용으로 아예 새로 개발하는 것이 좋을 것같다고 보고하였다.

새로 만드는 것 OK, 어떤 언어로?

결과적으로 새로 수집기를 동일한 로직 & 다른 언어로 구현하는 것으로는 협의가 되었다. 물론 그전에 다른 분들의 검증은 거쳤다. 더욱 실력 좋은 분들이 빌드 및 실행을 시도하였으나 쉽게 빌드하고 실행하는 것은 힘들 것같다고 개발하고 유지보수해야하는 담당자인 내가 새로 구현해서 대응하자는 의견을 존중해주셨다.

그래서 바로 생각나는 세 가지 언어(Java, Rust, Golang)를 검토하고 결국 Java를 선택하게 되었다.

선택을 위해 오래 고민하지 않았다. 아주 현실적인 문제가 있었기 때문이다. 선택한 이유는 다음과 같다.

  • 새로 만드는 것으로 협의를 하기까지 너무 오랜 시간이 걸려 실제 구현하고 테스트하는데 시간이 2달 밖에 안남아서 모르는 언어를 시도할 수가 없었다(이게 가장 큰 문제.. 그래서 kotlin으로도 못했다).
  • Golang, Rust는 결국 네이티브 바이너리를 만들어내는데, 계속 늘어나는 다양한 OS 환경별로 바이너리 만드는 것이 너무 머리아프다.
  • C++에 비해 성능 느릴 수 있지만 그래도 Java JIT를 믿었다.

Java 8을 선택하였는데 가장 많은 환경에서 쉽게 사용할 수 있는 것이 Java 8 이라 생각해서였다. 다양한 환경에 배포되는 바이너리인 만큼 최대한 많은 환경에서 동작하는게 맞을 것같아 일단 Java 8로 선택하였다. (나중에 알고보니 32bit 지원이 마지막이라는 것을 듣고 일단 Java 8로 하는 것이 다양한 환경에 배포되는 수집기로써 호환성 측면에서는 나은 선택일 수도 있었겠다 생각했다.)

구현하고보니 보이는 장단점

Java 8, Spring Boot, Netty, JNI 를 사용하여 구현하였다. 구현을 하고 보니 보이는 장단점들이 있었다.

JNI가 필요한 이유는 관제 DB인 Tibero 데이터 수집하기 위해서 TIbero에서 제공해주는 C 라이브러리 함수를 사용해야하기 때문이다. 제공된 C 라이브러리를 통해서 조회한 데이터는 바로 Java 객체로 담아서 return하는 식이다.

장점

Java를 선택하게된 결정적인 이유가 구현 전보다 구현 후에 더 큰 장점으로 느껴졌다. 직접 구현하고 서로 다른 환경에서 서로 다른 JVM 위에서 같은 애플리케이션을 실행시켜보니 호환성과 편리함을 여실히 실감하게 되었다.

그리고 다양한 라이브러리를 중앙 저장소인 maven 으로부터 쉽게 로드하여 사용할 수 있다는 것이 엄청난 장점이라는 것을 다시 한번 느꼈다. 유저가 많은 언어라는 것 자체가 확실히 장점으로 다가왔고, 그만큼 탄탄한 라이브러리들을 기반으로 편리하게 구현을 진행할 수 있었다.

단점

이렇게 쉽게 선택하고 구현을 마치고 보니 즉각적인 단점이 눈앞에 보였다.

Realtime 수집기인데 GC로 인해서 수집 주기가 지켜지지 못하고 뜰쑥날쑥한 현상이 간헐적으로 발생한 것이다

물론 현재는 1초가 최소 수집 주기이기에 실제 화면에서는 실시간이 기존 것과 큰 차이가 없다. 1초 안에는 대부분 데이터 수집하고 메시지를 만들어 serialize하고 TCP로 보내기는 하는 것이다.

그래도 확실히 C++에 비해 Java가 느리고 GC로 인해 불안한 수집 주기를 가지게 된다는 것을 느끼게 되었다.

그래서 GC를 최대한 하지 않도록 코드 개선 진행중

GC가 최대한 발생하지 않도록 개선을 진행하고 있다.

코드 레벨에서는 GC가 최대한 발생하지 않도록 새로 만드는 인스턴스들이 정말로 필요한지, 재사용할 수는 없는지 테스트하고 개선하는 중이다.

JVM 메모리 설정으로도 GC를 덜 할 수 있도록 할 수 있을 것처럼 보인다. 다만 JVM 메모리 설정은 각 배포된 환경이 천차만별이기에 그 환경에 맞게 진행하는 것이 맞을 것으로 보인다.

profile
Backend Developer
post-custom-banner

0개의 댓글