오픈소스 기반 시스템의 업그레이드 가이드
- 단종과 돌발 이슈에 기민한 대처 방안

오픈소스 기반 시스템의 업그레이드 가이드

들어가며

오픈소스 소프트웨어를 기반으로 하는 엔터프라이즈 시스템을 구축·운영할 때 고려해야 할 점은 무엇일까요? 상용 소프트웨어를 오픈소스로 대체함으로써 얻는 비용 절감 효과만큼이나 직접 혹은 외부 전문 기술서비스를 활용하여 시스템을 안정적으로 운영하는 기반을 갖추는 것도 중요합니다. 특히 시간이 흐르면서 제품수명주기에 따라 오픈소스도 단종(End of Life)되어 최악의 경우 시스템 전면 재구축에 준하는 작업이 필요할 수 있습니다. 다수의 오픈소스를 사용 중인 경우 이같은 작업이 더 빈번하고 복잡해집니다.

본 아티클에서는 필자가 장시간에 걸쳐 OS·DBMS·애플리케이션 등의 주요 오픈소스를 기반으로 엔터프라이즈 시스템을 구축 및 유지관리하면서 겪은 기술 이슈 사례를 소개하고 개발자가 유의해야 할 사항을 공유하겠습니다.

오픈소스를 활용하는 기업은 시스템을 안정적으로 운영 관리할 수 있는 기술 역량을 확보하는 것이 중요합니다.

2. OS: Linux 업그레이드

상용 메시징 솔루션을 오픈소스로 대체하는 프로젝트에서 서버 OS인 RHEL(Red Hat Enterprise Linux)의 업그레이드 사례를 소개하겠습니다. A 기업은 2014년 메시징 서버의 OS로 RHEL 6을 적용한 이후 5년 이상 해당 버전을 유지하고 있었습니다. RHEL 6의 EoS(End of Service)가 다가옴에 따라 1년여 동안 준비를 거쳐 2019년 RHEL 7로의 업그레이드를 성공적으로 마무리하였습니다.

많은 엔터프라이즈 애플리케이션이 이식성과 효율성이 좋은 자바(Java)로 개발되고 있습니다. JVM(Java Virtual Machine) 버전 업그레이드, OpenJDK로 전환 등의 작업 및 그에 따른 일부 수정은 있었으나 서버 OS 변경에 따른 부분은 JVM이 책임지므로 큰 이슈가 없었습니다. 하지만 고성능 대용량 트래픽 처리를 위해 C/C++로 개발된 모듈을 보유하고 있는 경우는 상황이 다릅니다. 기본적으로 툴체인(Tool Chain, 컴파일러·링커·시스템 라이브러리 등)이 달라지면서 소스코드가 변경되거나 사용자 라이브러리가 호환되지 않는 경우가 발생할 수 있어 유의해야 합니다.

이와 동시에 24x7 서비스가 되는 시스템이다 보니 서버 OS 역시 무중단 업그레이드를 해야 했습니다. 충분한 테스트를 진행했음에도 불구하고 운영 환경에서만 발생하는 이슈도 있기에 긴급 복구가 가능하도록 이중화 구성된 서버들을 서로 다른 버전의 OS로 병행 운영해야 합니다. 이를 위해서 호환성 검증을 중점적으로 수행하였습니다. 검증에 가장 중요한 요소는 회귀 테스트(Regression Test) 케이스가 충분히 확보되어 테스트 커버리지를 보장하는 것입니다. 단기간에 보강하기 어려운 부분으로 스프린트 통합 시점뿐만 아니라 장애 발생 시에도 테스트 케이스를 지속적으로 보강해야 합니다. 이는 안정적인 유지보수를 위해 가장 중요한 자산입니다.

그럼에도 불구하고 비기능적인 측면에서 이슈가 발생하기도 합니다. RHEL 7로 업그레이드 후 메모리 사용량이 증가했는데 C/C++로 작성한 멀티스레드(Multi Thread) 프로그램에서 발생하는 현상임을 확인하였습니다. 원인은 시스템 라이브러리(glibc) 내 메모리 할당 메커니즘의 변경에 따른 것이었습니다. 구체적으로 설명하면 멀티스레드 기반의 프로그램에서 각 스레드가 동시에 메모리 할당을 수행할 때 기존의 락(Lock) 기반 메모리 할당 방식보다 처리 성능을 개선하기 위해 메모리 영역을 다중으로 나누어 관리하는 아레나(Arena) 개념이 도입되었는데 성능 개선의 반대급부로 물리 메모리 사용량이 늘어나게 된 것입니다. 이는 리눅스 메인테이너(Maintainer)의 의사결정에 따른 변경이라 지속적으로 관심 있게 보지 않으면 알기가 어렵고 벤더도 일일이 가이드해주지 않습니다. 필자를 비롯한 프로젝트 팀원들은 오픈소스 커뮤니티를 통해 이를 조정할 수 있는 방법을 찾았고 환경변수(MALLOC_ARENA_MAX)의 반복적인 튜닝을 통해 적절한 값을 선정해가는 과정을 거쳐 문제를 해결할 수 있었습니다.

오픈소스 커뮤니티를 잘 활용하면 기술 역량을 높일 수 있을 뿐만 아니라, 문제 해결을 위한 도움을 받을 수도 있습니다.

3. DB: Hadoop(HBase)

앞서 언급한 A 기업의 프로젝트에서 가장 중요한 목표 중의 하나가 고가용 분산 데이터베이스를 구현하는 것이었습니다. 이에 당시 본격적으로 활용되기 시작한 하둡(Hadoop) 에코시스템의 하나인 HBase를 선택하였습니다. 또한 호튼웍스(Hortonworks)의 HDP(Hortonworks Data Platform) 플랫폼을 선정해 유지보수 계약을 체결하여 안정적인 운영 방안을 마련하였습니다.

HDP 2.x 버전의 HBase 1.1을 기반으로 시스템을 구축했는데, SQL 온하둡(on Hadoop)이 충분히 발전되기 전 상황에서 코프로세서(Coprocessor)를 활용해 많은 기능을 구현하였습니다. HDP 2.x가 단종되어 3.x로 업그레이드하면서 HBase 2.0도 같이 업그레이드하게 되었고 아키텍처와 API 변경 등의 사유로 코프로세서도 수정사항이 발생하였습니다. 검증 과정에서 HBase 버그도 발견하여 벤더에 리포트하였으나 코프로세서 영향으로 버그가 발생할 수 있으므로 코프로세서 없이 재현 가능한 시나리오를 달라는 원론적인 답변만 받았습니다. 이에 필자를 포함한 개발 인력들은 재현을 위한 검증 및 오픈소스 커뮤니티 소통 등 다방면의 활동을 통해 벤더로부터 패치를 받아낼 수 있었습니다.

이 외에도 오픈소스 특성상 옵션의 미묘한 기능 변경까지 벤더가 전부 통제할 수 없다 보니 업그레이드 과정에서 호환성 이슈가 일부 불거졌습니다. 일단 자체 분석을 통해 대응하고 벤더에게도 병행 통보하여 근본적인 해결책을 가이드받는 과정이 필요했습니다. 데이터베이스는 재기동으로도 회복되지 않기 때문에 이관 작업에 신중을 기해야 합니다. 메이저 버전이 바뀌면서 단순 업그레이드가 되지 않아 이관 작업에 나섰고, 개발·운영 및 유지보수 인력들이 합심한 결과 서비스 중단 없이 성공적으로 이관을 완료하였습니다.

참고로 HBase는 클라우데라(Cloudera)와 호튼웍스가 합병되고 HDP 플랫폼이 단종될 예정임에 따라 앞으로 대안을 마련해야 하는 상황입니다. 이와 같이 오픈소스는 플랫폼의 다양성뿐만 아니라 지속가능성까지 항상 예의주시해야 합니다.

다른 IT 분야와 마찬가지로 오픈소스 소프트웨어 시장도 끊임없이 변화하고 있습니다. 기업은 오픈소스 생태계를 예의주시해야 합니다.

4. 애플리케이션: Redis Client Library(Jedis)

레디스(Redis)는 가장 널리 쓰이는 인메모리(In-Memory) 시스템입니다. 자바에서 제디스(Jedis, 레디스의 클라이언트 라이브러리)를 통해 연동이 가능한데 이는 가장 기본적인 라이브러리입니다. 프로젝트 초기에 2.4.2 버전을 적용해 운영하고 있었는데 커넥션 풀(Connection Pool) 관리의 버그가 있어 상위 버전(2.10.2)으로 업그레이드하였습니다. 엔진 서버가 아닌 클라이언트 라이브러리가 바뀌었고 마이너 버전 변경이므로 호환성이 보장되고 영향도가 적을 것으로 간주하여 업그레이드 작업과 시스템의 회귀 테스트를 완료한 후 운영 환경에 바로 적용하였습니다.

하지만 비기능적인 측면에서 이슈가 발생하였는데 특정 커넥션 에러가 발생할 경우 기존의 예외(Exception) 처리 종류가 바뀌어 오동작하는 문제가 나타났습니다. (향후 이 문제를 방지하기 위해 에러를 유발하는 단위 테스트를 만들어 보강하였습니다.) 제디스의 경우 초기 API 설계 시 예외를 포함하지 않아서 그 후에 런타임 예외(Runtime Exception)로 추가하였기 때문에 컴파일러가 감지하지 못해 걸러지지 못한 점도 있습니다. 자바 애플리케이션에서 라이브러리를 선정할 때에도 이 점을 중요하게 고려해야 합니다. 이와 같이 간단한 업그레이드라고 하더라도 빈번하게 호출되고 오류 발생 시 장애를 유발할 가능성이 높은 경우는 비기능 검증을 충분히 수반해야 합니다.

5. 마치며

앞서 오픈소스 기반의 엔터프라이즈 시스템과 관련된 주요 기술 이슈 케이스를 살펴보았습니다. 이 외에도 JDK(Java Development Kit) 및 개별 오픈소스의 업그레이드 시 발생하는 이슈도 존재합니다. 이같은 케이스들이 공통적으로 시사하는 바는 오픈소스 도입 이후 유지보수와 업그레이드를 진행함에 있어 유료구독 서비스만으로는 해결할 수 없는 영역이 있다는 것입니다. 따라서 오픈소스를 전략적으로 활용하고자 하는 기업은 구축·운영 경험을 차곡차곡 쌓으면서 자체 인력을 육성하거나 경험 많은 전문 기술파트너와의 협력 관계를 모색해야 합니다.

앞서 언급한 문제들에 대한 대응 체계를 갖추면 오픈소스를 잘 다루는 기업으로 거듭날 수 있습니다. 이렇게 되면 전 세계의 훌륭한 소프트웨어 개발자들이 기여하는 빛나는 기술과 새로운 기능들을 자연스럽게 흡수하여 고객에게 글로벌 선도 서비스를 제공할 수 있게 될 것입니다.


# References
[1] https://siddhesh.in/posts/malloc-per-thread-arenas-in-glibc.html
[2] https://developers.redhat.com/blog/2017/03/02/malloc-internals-and-you
[3] https://www.ciokorea.com/news/39756
[4] https://www.datanami.com/2018/10/24/new-cloudera-plots-a-course-toward-a-unified-future/
[5] https://github.com/redis/jedis/wiki/Getting-started#using-jedis-in-a-multithreaded-environment
[6] https://github.com/redis/jedis/blob/8a87c55aa71c97f87b82f61a4c15887da3cb0266/src/main/java/redis/clients/jedis/exceptions/JedisExhaustedPoolException.java



▶  해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶  해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


공유하기 열기
이민우
이민우 IT 테크놀로지 전문가

에스코어㈜ 소프트웨어사업부 컨버전스SW그룹

에스코어에서 오픈소스 기반 메일 시스템 구축, Backend 엔진 개발 및 유지보수 프로젝트를 이끌고 있습니다.