기술이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 DB 관리 툴, Zenius DBMS의 주요기능과 특장점 기술이야기 DB 관리 툴, Zenius DBMS의 주요기능과 특장점 대다수의 기업들이 정형 데이터와 비정형 데이터를 모두 효과적으로 처리하기 위해 RDBMS(Relational Database Management System, 관계형 데이트베이스 관리 시스템)와 NoSQL(Not Only SQL, 비관계형 데이터베이스)을 함께 활용하는 경우가 많아지고 있습니다. 하지만 두 시스템 간의 구조적 차이로 인해 데이터 동기화, 쿼리 최적화, 리소스 과다 사용 같은 문제가 발생하기 쉽습니다. 특히, 실시간으로 상태를 모니터링하고 장애를 예측하는 작업은 생각보다 까다롭고 많은 시간과 노력을 요구합니다. 이런 복잡한 문제를 해결하려면 다양한 DBMS를 통합적으로 관리하면서 잠재적인 문제를 사전에 식별할 수 있는 체계적인 DBMS 모니터링 솔루션이 필요합니다. Zenius DBMS는 RDBMS와 NoSQL을 포함한 여러 이기종 데이터베이스를 한 플랫폼에서 관리할 수 있도록 돕는 솔루션으로, 성능 저하나 장애 발생 시 원인을 빠르게 파악하고 대응할 수 있게 해줍니다. DB 관리 툴, Zenius DBMS가 구체적으로 어떤 기능과 장점을 가지고 있는지 자세히 살펴보겠습니다. DB 관리 툴, Zenius DBMS 주요 기능 세 가지 1. 이기종 DBMS 통합 모니터링 다양한 DBMS(Oracle, MySQL, MongoDB 등)를 사용하는 기업 환경에서 각 데이터베이스를 개별적으로 관리하는 것은, 많은 시간과 자원을 소모하게 만듭니다. 관리자는 각 DBMS의 상태를 따로 점검하고 문제 발생 시 여러 시스템을 오가며 원인을 찾아야 하기 때문에 장애 대응 속도 또한 느려질 수 있습니다. 이러한 문제를 해결하기 위해 Zenius DBMS는 Oracle, MongoDB, Tibero 등 국내외 주요 벤더사의 주요 DBMS를 포함해 다양한 데이터베이스를 단일 플랫폼에서 통합적으로 모니터링할 수 있는 기능을 제공합니다. 이러한 통합 기능을 통해 데이터베이스 상태를 한눈에 파악할 수 있고, 장애 대응 시간도 크게 단축할 수 있습니다. 2. DBMS 별 상세 성능 모니터링과 특화 View DB관리 툴, Zenius DBMS는 RDBMS와 NoSQL 환경 모두에서 성능, 세션, 저장장치 상태를 깊이 분석할 수 있는 상세 정보를 제공합니다. 그러나 관리 화면이 각 DBMS의 고유 특성을 반영하지 못할 경우, 중요한 정보를 놓치거나 문제 상황에서 빠르게 대처하기 어려워질 수 있습니다. 이와 같은 한계를 극복하기 위해 Zenius DBMS는 DBMS별로 최적화된 상세 정보 UI를 지원하여 직관적이고 효과적인 관리 환경을 제공합니다. 예를 들어 Oracle 환경에서는 테이블스페이스 사용량과 글로벌 캐시(Global Cache) 상태를, MySQL은 세션과 메모리 사용량을, MongoDB와 Redis는 데이터베이스 상태와 세션 정보를 실시간으로 확인할 수 있습니다. 이처럼 Zenius DBMS는 데이터베이스별 특성을 반영한 화면 구성을 통해 관리자는 각 데이터베이스의 주요 지표를 빠르게 파악하고, 데이터 처리 과정에서 발생할 수 있는 문제를 사전에 감지하여 신속히 대응할 수 있습니다. 특히 Oracle RAC(Real Application Cluster) 환경은 다수의 서버가 하나의 데이터베이스를 공유하며 작업을 분산 처리하는 특성상 데이터 동기화와 자원 관리의 복잡성이 매우 높습니다. 이러한 복잡성이 높은 환경을 효율적으로 관리하기 위해 Zenius DBMS는 글로벌 캐시(Global Cache), I/O, 잠금(Lock) 상태를 실시간으로 추적하고, 클러스터 인스턴스를 체계적으로 매핑하여 잠재적인 문제를 조기에 발견하고 신속히 대응할 수 있도록 지원합니다. 이러한 기능은 클러스터 환경에서 발생할 수 있는 병목 현상이나 동기화 문제를 조치할 수 있게 하며, 장애로 인한 데이터 손실 위험을 줄이고, 운영 안정성을 높이는 데 도움을 줍니다. 3. 장애 관리 및 감시 설정 장애 관리는 데이터베이스 관리자에게 가장 큰 부담 중 하나입니다. 느린 쿼리나 세션 과부하로 인해 발생한 성능 저하가 즉시 해결되지 않으면, 서비스 중단이나 데이터 손실로 이어질 위험이 커질 수 있습니다. 이러한 문제를 해결하기 위해 Zenius DBMS는 데이터베이스 운영 중 발생할 수 있는 느린 쿼리, 세션 과부하, Lock 문제와 같은 주요 장애를 설정된 임계 값에 따라 자동으로 감지하며, 관리자에게 알림을 제공하여 신속하게 조치할 수 있게 도움을 줍니다. 또한 데이터베이스의 저장공간이 부족하면 새로운 데이터를 추가하지 못하는 상황이 발생할 수 있습니다. 이를 방지하기 위해 Zenius DBMS는 테이블스페이스 사용량을 지속적으로 모니터링하여, 저장공간 부족으로 인한 문제를 미리 예방합니다. DB 관리 툴, Zenius DBMS가 가진 특별한 장점은?! IT 인프라를 구성하는 네트워크, 서버, 애플리케이션, 데이터베이스는 데이터 전달, 자원 관리, 성능, 안정성, 보안 등 여러 측면에서 상호 유기적으로 연동되어 작동합니다. 예를 들어, 네트워크 트래픽 과부하로 서버 응답 시간이 지연되면 데이터베이스의 처리 속도가 감소할 수 있고, 반대로 데이터베이스의 과도한 쿼리는 네트워크와 서버 자원을 과도하게 소모하여 전체 시스템 성능에 병목 현상을 초래할 수 있습니다. 이러한 상황에서 클라우드 도입이 가속화되고, 가상머신(VM)과 마이크로서비스 아키텍처(MSA)의 활용이 증가하면서 IT 인프라 구성 요소 간의 상호 의존성과 복잡성은 점점 더 높아지고 있습니다. 따라서 DBMS 관리에만 초점을 맞출 경우, 네트워크와 서버에서 발생하는 문제나 데이터베이스 간 상호작용을 효과적으로 파악하기 어려워 근본적인 장애 원인 분석과 대응에 한계가 생길 수 있습니다. 이는 운영 효율성을 저하시킬 뿐만 아니라, 장애 대응 시간 증가로 인해 비즈니스 연속성에도 큰 영향을 미칠 위험이 있습니다. 이러한 문제를 해결할 수 있도록 Zenius DBMS는 Framework 구조로 구성되어 있습니다. 이를 통해 데이터베이스와 연관된 서버, 네트워크, 애플리케이션 등의 모든 IT 인프라를 단일 플랫폼에서 통합해서 모니터링 할 수 있습니다. 따라서 운영자는 Zenius DBMS를 통해 데이터베이스 성능 병목 현상을 신속히 식별하고, 장애 발생 시 근본 원인을 정확히 분석하며, 서버와 네트워크를 포함한 IT 인프라 전체의 성능을 한눈에 파악할 수 있습니다. 이번 시간에 살펴본 것처럼 RDBMS와 NoSQL을 혼합해 사용하는 기업 환경이 증가하면서, 다양한 DBMS 상태를 통합적으로 관리할 수 있는 모니터링 솔루션의 필요성이 더욱 커지고 있습니다. 이러한 요구에 맞춰 Zenius DBMS는 이기종 DBMS를 한 화면에서 통합해서 모니터링 할 수 있을 뿐 아니라 각 데이터베이스의 특성을 반영한 최적화된 뷰를 통해 주요 성능 데이터를 실시간으로 파악할 수 있는 기능을 갖추고 있습니다. 특히 타 솔루션과 비교하여 Zenius DBMS의 큰 장점 중 하나는 IT 인프라 전반을 통합해서 관리할 수 있다는 것입니다. 이를 통해 네트워크, 서버, 데이터베이스 간의 상호작용을 효과적으로 관리할 수 있어, 복합적인 장애의 원인을 신속히 분석하고 문제에 빠르게 대응할 수 있습니다. 이제 Zenius DBMS를 활용해 복잡한 데이터베이스 환경에서도 안정적이고 효율적인 관리를 경험해 보시길 바랍니다! 2024.12.31
기술이야기 JPA 도입을 위한 고민_ORM 기술을 써야 하나? 기술이야기 JPA 도입을 위한 고민_ORM 기술을 써야 하나? 몇 해전에 새로운 버전의 ITSM을 개발하기 시작하면서 JPA 기술 도입을 두고 고민했던 내용을 이제는 한 번쯤 정리해야 할 시점이라고 생각했다. 비단 JPA뿐 아니라 Spring Boot, Thymeleaf, Kotlin과 같은 새로운 개발 기술이나 Git, Gradle, Slack, PR처리 등 새로운 업무 환경까지 상당한 변화를 시작한 프로젝트였기 때문에 고민되는 것이 한두 개가 아니었지만 가장 길고 심각하게 고민했던 부분이라 따로 기록을 남겨본다. 이 글은 기술적인 내용은 아니고 어떻게 보면 당연하고 일반적인 내용이지만 다음 기회에 새로운 기술, 환경, 프로세스에 대한 도입을 검토할 때 조금이나마 도움이 됐으면 하는 마음이다. 여기에선 기술적인 내용에 대한 설명을 덧붙이지 않는 것은 관련된 내용은 'JAVA', 'ORM', 'JPA' 등으로 검색만 해도 비슷한 글들이 넘쳐나는 상황에 하나 더 덧붙이는 건 별로 의미가 없어 보이기 때문이다. 1. ORM에 대한 갑을논박 ORM에 대한 검색을 해보면 정말 여기서 다시 얘기하고 싶지 않을 정도로 오랜 시간동안 많은 사람들의 많은 의견들이 쏟아져 나온다. 게다가 더욱 혼란스러운 점은 구구절절 옳은 말들이라는 점이다. 여기서 뭔가 딱 부러진 결론을 내는 것은 불가능하고 너무 많은 의견들을 접하면서 점점 혼란스러워졌다. 대표적으로 참고 삼아 [자바 ORM 표준 JPA 프로그래밍]을 쓰신 김영한님의 글로 추정되는 링크 하나 투척~ https://okky.kr/article/286812 2. 우리에게 중요한 것 2.1. 진입장벽 : 진입장벽… 이 높다한들 하늘 아래 뫼… 일까? 어떤 기술이든 진입장벽은 그 도입 여부를 결정하는 가장 중요한 요소이다. 개인적으로 스터디를 하거나 한번 써보고 싶은 마음에서라면 진입장벽이 높을수록 구미가 당기는 변태적인 성향이 있는 사람도 있겠지만 이게 업무적인 접근이고 다른 팀원들과 함께 해야 하는 것이라면 진입장벽이 높이에 따라서는 그 기술의 효과가 인정되어도 도입이 쉽지 않은 것이 사실이다. JPA는 많은 사람들이 진입장벽이 높은 편이라고 입을 모아 말한다. 검토를 위해 살짝 들여다 보았을때도 쉬워 보이진 않았다. 말 그대로 ORM을 잘 쓰기 위해서는 Object와 Model에 대한 깊이 있는 사전 지식과 그 둘을 Mapping하는 개념적인 체계가 머리 속에 있어야 충분히 활용할 수 있을 것 같았다. 진입장벽이란 것도 사실 상대적인데 당시에 판단으로 우리 팀에서 도입하기에 진입장벽은 중상(中上)이라고 생각했다. 잘 자리잡기 쉽지 않을 것이고 시간도 오래 걸리리라 생각이 들었다. 이러한 점을 만회할 장점이 있는지 고민이 필요했다. 2.2. 제품 특징 : 우리가 만드는 제품/프로젝트의 특징에 맞는가? 당시에 새롭게 시작되는 프로젝트에서 만드는 제품은 기존 Zenius ITSM 시스템의 새로운 버전이다. 업무적으로 여러가지 특징이 있지만 Model과 관련되어서는 상대적으로 복잡한 구조라 할 순 없었고 극단적인 성능과도 거리가 좀 있다. 상대적으로 깔끔하고 명확한 모델링이 훨씬 더 중요하다고 판단했고 이러한 면은 JPA도입에 대한 긍정적인 입장을 가지게 했다. 쿼리와 관련되어서 수많은 간단한 작업들을 효과적으로 할 수 있을거란 기대감… 만약 만들려고 하는 제품이 특정 RDBMS에 의존적이거나, 혹은 인수인계나 유지보수가 어려울 정도로 비즈니스부터가 복잡한 형태라서 JPA를 쓰면서도 많은 성능 튜닝과 Native Query를 사용해야 하는 상황이거나 한다면 상황은 약간 달라졌을 것이다. 제품의 특징과 더불어 현재 프로젝트의 특성도 같이 살펴봐야 한다. 레거시 시스템의 업그레이드인지, 이번 프로젝트처럼 완전히 새 판에서 시작하는 게 가능한 상황인지… 새로운 제품을 만드는 프로젝트가 납기일이 정해진 프로젝트보다 나은 점은 그나마 초기 학습과 관련된 투입을 감안하기가 좀 더 수월하다는 점이다. SI같은 성격의 프로젝트라면 내부 고객뿐 아니라 상대방 고객도 설득해야 하는 문제점이 더 크다. 그런 면에서 이번 프로젝트는 JPA를 도입하거나 적용하기엔 괜찮은 상황이라는 게 결론이었다. 2.3. 조직/인력 구조 : 바로 우리가 쓰는 기술이다. 기술도 중요하지만 우리도 중요하다. 제목처럼 아무리 좋은 기술이라도 우리에게 맞냐는 게 결정적이다. 아래와 같은 질문들을 던져 보았다. • 현재 구성원들의 사전 지식은 어느 정도인가? • 우리 회사나 우리 팀에서 향후 관련된 개발자를 계속 충원할 수 있는가? • 우리 팀은 새로운 기술을 공부하며 도입할 의지를 가졌는가? • 회사는 관련된 교육과 초기에 벌어질 삽질을 감내할 수 있는가? 결론적으로 반반이었다. 우리 팀은 JPA에 대해서 아는 바가 거의 없는 상태였다. 게다가 지금이야 JPA를 사용하는 사람들도 더 늘어난 것 같고 우리 회사의 위상도 달라졌지만 당시의 우리 회사의 규모나 채용 형태를 봤을 때 관련된 개발자를 충원하는 것도 쉽지는 않을 것 같았다. 반대로 새로운 기술 도입에 대해서 강한 의지까지는 아니라도 긍정적은 자세를 가진 팀원과 초기 삽질에 대해서 어느 정도 감내할 수 있는 회사라는 것이 당시의 생각이었다. 그래도 반이 어디냐…는 게 최종 결론이었다. 2.4. 재미 : 그래서 땡기냐? 이성적이고 객관적인 여러 사실들을 매트릭스화해서 평가를 하면서도 스스로에게 던지는 마지막 질문은… 그래서 땡기냐는 거다. 모든 수치가 부정적인데도 끝까지 미련을 버리지 못하고 하고 싶은 경우가 있고, 모든 결과가 긍정적인데도 뭔가 하기 싫은 경우가 많은데, 결국 그것들은 결과로 이어지더라. 리누스 토발즈가 커널을 업그레이드할 때 가장 중요한 점으로 “얼마나 재미”가 있냐는 점이라고 얘기 했다는데, 우리는 그 정도 레벨의 개발자는 아직(!) 아니지만 우리에게도 “재미”는 가장 중요한 결정요인 중 하나이다. 스스로에게 물어보자. 재미있어 보이나? 그리고, 당시에 나에게는 무척 설레었던 일이었음을 고백해야겠다. 3. 염려스러운 점 3.1. 회귀본능 아직 익숙하지 않은 상태에서 개발을 진행하다 보면 도무지 JPA에서 왜 이런 쿼리를 만들어내는지 이해하기 어려운 경우를 종종 만난다. 혹은 익숙한 SQL이 머리속에서 막 떠오르는데 JPA로 적용하기 위해서 이런저런 삽질을 하다 보면… 아… 그냥 쿼리를 직접 짤까? Native Query도 Mybatis도 지원한다던데… 분명 이런 순간이 올 것이라고 예상했다. 공부를 하는 것도 좋지만 회사에서 업무로 일정에 맞춰 무언가를 만들어내야 하는 압박감은 따로 누가 주지 않아도 가지고 있는 것이니… 침착하자. 익숙하지 않고 힘들다고 나도 모르게 무언가 자꾸 길을 벗어나고 있는 건 아닌지 계속 주의 깊게 들여다 봐야 한다. 결론적으로 지금에 와서 돌이켜보면 초반에는 의도대로 생성되지 않는 쿼리들에 당황하긴 했지만, 약간의 삽질 후에는 왜 그런 상황이 발생되는지 알기가 어렵지는 않았다. 언젠가는 복잡한 통계나 로직 때문에 Native Query를 쓰게 될 날이 오겠지만 아직은 아니다. 3.2. 학습곡선 도입하려는 기술에 따라, 혹은 구성원의 사전 지식에 따라 학습곡선은 상당히 다양한 형태로 나타나는데, 평균적으로 JPA의 학습곡선은 전반적으로 경사가 아주 완만하다고 판단했다. 즉 도입 검토 시점의 진입장벽은 그 자체로 염려스러운 점이었다. 그 얘기는 수준을 일정수준 이상으로 끌어올리기 위해서 많은 시간과 노력이 팀 차원에서 필요하다는 얘기였고 필요로 하는 사전지식도 꽤 있을 듯 했다. 게다가 여러 가지 이유로 개인별로 나타나는 학습곡선도 많이 다르리라 예상했다. 뭔가 기막힌 해결책이 있으면 좋겠지만, 책을 구매해서 읽고 유료 강의, 무료 강의들을 공유하고… 서로서로 도와가며 공부하는 클래식한 정공법을 택했다. (그만큼 사실 효과는 기대하기 힘들다는 것도 알지만…) 지금 생각해보면 어떤 기술이나 프로세스든 누군가 소수의 인원이 먼저 출발해서 끌어줄 수 있는 형태가 되는 것이 제일 나은 것 같다. 서로서로 도움을 주면서 같이 커가는 모양새가 될 수 있을 듯 한데 우리는 그렇지는 못했고 모두가 공평(?)하게 모르는 상태에서 스타뜨~ JPA의 도입에 대한 학습곡선은 최종적으로 도입을 결정하는데 마지막까지 고민을 하게 했던 점이었다. 3.3. Mapper는 누가? 자, 우리는 Object도 Model도 이제까지 다 개발자가 했다. Object야 당연히 개발자가 만들어야 하겠지만 큰 기업에서처럼 DBA가 있거나 화면을 퍼블리싱해주거나 하지 않는다. 우리는 우리가 화면, 미들웨어, DB까지 직접 만들고 컨트롤 해왔다. 그게 좋은 것이냐의 문제를 여기서 얘기하자는 게 아니라 현실이라는걸 얘기하는 거다. 우리 팀원 모두가 JPA 초보이다. Mybatis를 사용하고 Spring을 사용해봤다고 하지만 ORM이나 SQL Mapper에 대한 심도있는 고민은 부족한 상황. 앞으로 JPA에서 Object와 Model은 그렇다고 해도 Mapper역할은 또 필요하지 않을까? 그런 가이드는 또 누가 해야 하나… 모든 개발자에게 알아야 한다고 말할 수 있지만 모든 개발자에게 팀에서 잘하는 메인이 되라고 하기엔 좀 애매한 영역이란 게 항상 있다. 프로그램의 오브젝트와 DB의 모델을 연결하는 Mapper를 잘 구성할 경험이 많은 개발자가 없다는 점은 학습곡선과 더불어 JPA 도입을 망설이게 했던 주요 고민이었다. 결론적으로 선임 개발자를 중심으로 착실히 스터디를 잘 해주었고 제품의 특성상 그렇게 복잡한 관계를 매핑할 일이 많지 않아서인지 초반에 몇 번 팀원들이 같이 머리를 싸매고 논의했던 것 외에 문제는 없었다. 4. 결론(현재까지는…) 도입 결정 후 꽤 긴 시간 제품을 만들고, 이제는 고객사에 납품도 하면서 기능을 계속 추가하고 있는 이 시점에서 돌아보면, 어떤 부분은 팀원들이 너무 잘해주고 있고, 어떤 부분은 전혀 예상하지 않은 형태로 진행이 돼서 난감한 경우도 있지만 전체적으로는 아주 만족하고 있다. 정확하게 측정을 하진 못했지만 쿼리를 직접 짜면서 개발을 진행하는 것보다 생산성 측면에서 확실히 나아졌다고 느끼고 있고 그 효과는 초반에 투입된 시간에 비례해 앞으로 더욱 더 기대된다. 만족하고 있다고는 했지만 여기서 만족이라는 게 성과나 기술적인 완성도에 대한 절대적인 만족은 아니다. 다만 아직 우리 제품에 대한 아쉬움을 가지는 것이 JPA 때문은 아니라는 점은 확실하다. JPA가 유행에 따라 생긴 기술이라고 하기엔 너무 오래된 기술이지만 그래서인가 ORM 자체에 대한 흥미도 점점 더 해가고 있다. JPA도 ORM에 대한 가장 최근의 시도중 하나겠지만, 앞으로 어떤 식으로 발전해 나갈지, 그에 따른 개발 업무는 또 어떤 식으로 변화가 있을지도 궁금하고… 어쨌든, 지금으로서는 다시 돌아가진 않을 생각이다. 2023.01.03

1