인사이트

인사이트리포트

디지털프렌스포메이션 최신 정보 및 트렌드를 제공합니다.

오픈소스 SW

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

2021.05.31이민우
다운로드

들어가며

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

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

사람이 노트북 컴퓨터를 이용하는 모습의 그림입니다. 하단에는 다음 문구가 기재되어 있습니다. 오픈소스를 활용하는 기업은 시스템을 안정적으로 운영관리 할 수 있는 기술 역량을 확보하는 것이 중요하다.

 

 

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, 컴파일러·링커·시스템 라이브러리 등)이 달라지면서 소스코드가 변경되거나 사용자 라이브러리가 호환되지 않는 경우가 발생할 수 있어 유의해야 한다.

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

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

회사에서 여러 사람이 컴퓨터를 사용하는 모습의 그림입니다. 하단에는 다음 문구가 기재되어 있습니다. 오픈소스 커뮤니티를 잘 활용하면 기술 역량을 높일 수 뿐만 아니라 문제 해결을 위한 도움을 받을 수도 있다.

 

 

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 플랫폼이 단종될 예정임에 따라 앞으로 대안을 마련해야 하는 상황이다. 이와 같이 오픈소스는 플랫폼의 다양성 뿐만 아니라 지속 가능성까지 항상 예의 주시해야 한다.

검은 바탕에 초록색으로 0과 1이 나열된 그림입니다. 하단에는 다음 문구가 기재되어 있습니다. 다른 IT 분야와 마찬가지로 오픈소스 소프트웨어 시장도 끊임없이 변화하고 있다. 기업은 오픈소스 생태계를 예의 주시해야 한다.

 

 

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

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

하지만 비기능적인 측면에서 이슈가 발생하였는데 특정 커넥션 에러가 발생할 경우 기존의 예외(Exception) 처리 종류가 바뀌어 오동작하는 문제가 나타났다. (향후 이 문제를 방지하기 위해 에러를 유발하는 단위 테스트를 만들어 보강하였다.)

제디스의 경우 초기 API 설계 시 예외를 포함하지 않아서 그 후에 런타임 예외(Runtime Exception)로 추가하였기 때문에 컴파일러가 감지하지 못해 걸러지지 못한 점도 있다. 자바 애플리케이션에서 라이브러리를 선정할 때에도 이 점을 중요하게 고려해야 한다. 이와 같이 간단한 업그레이드라고 하더라도 빈번하게 호출되고 오류 발생 시 장애를 유발할 가능성이 높은 경우는 비기능 검증을 충분히 수반해야 한다.

 

 

마치며

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

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

 

# References

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

이민우 프로

이민우 프로

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

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

연관 아티클

  • Redis를 활용한 안전하게 동시성 이슈 제어하기
    SW 테크놀로지2024.02.21

    Redis를 활용한 안전하게 동시성 이슈 제어하기

    자세히 보기
  • MariaDB 서버 모니터링 및 성능 최적화: InnoDB Buffer Pool 2부
    데이터 관리2023.11.23

    MariaDB 서버 모니터링 및 성능 최적화: InnoDB Buffer Pool 2부

    자세히 보기
  • MariaDB 서버 모니터링 및 성능 최적화: InnoDB Buffer Pool 1부
    SW 테크놀로지2023.11.10

    MariaDB 서버 모니터링 및 성능 최적화: InnoDB Buffer Pool 1부

    자세히 보기