최신이야기 | 브레인즈컴퍼니

[부산SW마이스터고 현장 실습] 기본기, 그리고 함께의 가치를 깨달았던 시간 [부산SW마이스터고 현장 실습] 기본기, 그리고 함께의 가치를 깨달았던 시간 지난 1월, 앳된 얼굴의 여고생 한 명이 브레인즈컴퍼니에 모습을 드러냈습니다. 저 먼 곳 부산에서 상경한 미진님은 중학생 시절부터 개발자의 꿈을 꾸다, 소프트웨어마이스터고로 진학을 했다는데요. 올해 고3이 되는 미진님은 학기 시작 전, 방학기간 동안 잠시 브레인즈컴퍼니에서 현장실습할 기회를 얻었습니다. 미진님은 짧은 기간이었지만 새로운 경험에 많은 것을 얻어갈 수 있었고, 브레인즈컴퍼니에서 다시 일할 기회가 있길 바란다는 말을 남기며 다시 부산으로 돌아갔습니다. 미진님이 브레인즈에서 어떤 생활을 했을지 함께 보러 가실까요? -------------------------------- Q. 안녕하세요, 미진님. 자기소개 부탁드릴게요. 안녕하세요. 저는 부산소프트웨어마이스터고에 재학중인 심미진입니다. 체험형 현장실습으로 브레인즈컴퍼니 ITSM팀에서 약 5주간 인턴생활을 했습니다. 시작한 게 엊그제 같은데 벌써 5주나 지나갔네요.ㅎㅎ Q. 실습 기간 동안 ITSM팀에서 어떤 교육을, 어떻게 받았나요? 총 5주동안 교육이 진행됐는데요. 첫 주에는 ITSM에 대한 리뷰를 했습니다. 사용자가 쉽게 따라올 수 있도록 가이드된 매뉴얼을 보고 다른 부분이나 결함, 개선점에 대해 찾았습니다. 개발하고 있는 제품에 대한 개발 환경 구축도 해보고, 어떤 기능이 있는지 하나하나 확인하면서 리뷰를 진행했습니다. 그 결과 결함 4개, 개선의견 5개를 찾았습니다. 2주차에는 제가 찾은 결함과 개선의견을 일감으로 정하고, 첫 PR(Pull Request)을 날린 경험을 했습니다. 사내 시스템 중 ‘레드 마인’이라는 것이 있는데, 그곳에서 해야 할 일을 기록하고 공유하고 있었습니다. 보통 해야 할 일을 ‘일감’이라고 부르고 있습니다. 제 사수가 어떻게 사용하는지에 대해 알려주시고 이를 따라할 수 있도록 도와주셨습니다. 사실 학교에서는 작은 프로젝트만 진행해왔고, 자주 모여서 이야기했기 때문에 이렇게까지 꼼꼼하게 기록한 적 없었는데 이번 기회를 통해서 문서 작성 그리고 공유에 대한 중요성을 배웠습니다. 또 처음 일감을 받아 PR을 날렸을 때 코딩 컨벤션의 중요성을 알게 됐습니다. 3주차에는 팀장님께서 저에게 주신 일감을 하나씩 처리하는 일을 시작했는데요. 지난 주에 날렸던 PR에 대한 피드백을 받고 이에 맞게 수정도 했습니다. 이 과정에서 학교에서와 달리 리뷰와 의견에 대해 빠른 피드백을 주셔서 좋았던 것 같아요. 처음 맡은 일감은 HTML을 이용해 구조를 수정하는 일이었어요. 내용적인 부분에 있어서는 학교에서 배운 부분이라 어려움이 없었어요. 4주차와 5주차에는 해결하는 시간이 조금 더 걸리는 일감을 받았어요. 이 과정에서 제일 중요하게 배운 것은 ‘깔끔한 코드’를 짜야한다는 것과 작은 결함일 줄 알았지만, 사실은 더 크거나 혹은 더 작은 결함이 발생할 수 있다는 것이었습니다. 서비스는 만드는 것보다 유지보수를 하는게 더 중요하기 때문에 깔끔한 코드를 짜는 것이 중요한데요. 깔끔한 코드에 대한 정의는 사람마다 조금씩 다를 수 있겠지만, 제 생각엔 유지 보수가 쉽게 가능하고 의도가 명확히 드러나는 코드라고 생각합니다. 또 제가 생각했던 것 보다 결함이 큰 경우도 있었는데, 저도 그동안 개발하면서 놓친 부분은 없는지 되돌아보는 계기가 됐습니다. 5주동안 개발적인 부분뿐만 아니라 다른 사람들과 '함께’ 코딩하는게 어떤 것인지 명확한 경험을 한 것 같아 좋았습니다. Q. 개발자로서 사용해 본 ITSM을 평가한다면? 제가 사용해 본 ITSM은 장단점이 확실히 구분되는 제품이었습니다. 먼저 장점은 편리한 기능이 다 갖춰져 있다는 것인데요. 문서 관리부터 자산 관리, 시스템 관리, 공지 등등 회사에게 필요한 기능이 다 갖춰져 있습니다. 또 회사에서 사용하는 문서들을 사용자(고객)가 원하는 대로 커스텀이 가능하다는 것인데요. 회사마다 절차도 다르고 사용해야 할 문서 형식도 다르게 나타나기 때문에 ‘폼 디자인’ 기능을 통해 구현되고 있었습니다. 그것뿐만 아니라 개인이 처리해야 할 문서에 대한 현황판을 대시보드로 한눈에 볼 수 있어 좋았던 것 같아요. 하지만 조금 아쉬운 점이 있다고 한다면 기능이 많은 만큼 고려해야 할 부분도 많이 생긴다는 것입니다. 아무래도 UI가 비슷하다면 같은 코드를 재사용하는 경우가 있습니다. 그런데 똑같이 적용을 했음에도 불구하고 생각치 못한 결함이 발생할 수 있다는 것인데요. 기능이 많으면 많을수록 재사용하는 코드는 늘어나기 때문에 결함을 수정하면서도 고려해야 할 부분이 많다는게 신경 쓰였습니다. 그리고 작은 프로젝트가 아니기 때문에 어쩔 수 없는 부분이라는 걸 알지만, 수정하는 것이 쉽지 않았다는 점이 조금 아쉬웠어요. Q. 브레인즈컴퍼니의 근무 환경은 어땠나요? 브레인즈컴퍼니에서의 근무 환경은 만족할 정도였습니다. 8층 라운지에는 매일 아침마다 간편한 식사가 준비돼 있었는데 덕분에 아침에 든든하게 있을 수 있었어요. 회사를 다닌다는 것 자체가 처음이라 긴장도 많이 하고, 실수할까봐 걱정도 많이 했는데 팀원분들께서 이해하기 쉽게 또 꼼꼼하게, 잘 알려주셨던 부분이 가장 좋았던 것 같아요. Q. 브레인즈컴퍼니에서 근무하며 가장 좋았던 점은 무엇인가요? 다른 사람이 짠 코드에 대해 결함을 찾고 이를 해결하는 과정이 가장 좋았습니다. 지금까지 제가 직접 코드를 짜고 고치고 하는 경우는 많았지만, 다른 사람이 미리 짜 놓은 코드를 고쳐본 적은 잘 없었어요. 처음에는 조금 이해하기 어려운 부분도 있었지만 그 과정에서 제가 스스로 공부하면서 해결해 나가는 과정이 좋았습니다. Q. 첫 직장생활을 해보며, 가장 힘들었던 점은 무엇인가요? 학교에서는 별도로 쉬는 시간이 주어지기 때문에 주기적인 리프레쉬가 가능했지만, 회사는 학교와 다르게 자유롭다 보니 쉬는 시간을 스스로 조절하는 게 쉽지 않았어요. 다른 분들이 열심히 하는 모습을 보고 “이렇게 열심히 하시는 데 내가 쉬어도 괜찮은 걸까?”라는 생각을 했던 것 같아요. 처음에는 쉬는 시간에 대해 생각도 않고 계속 일을 했지만, 그 덕분에 제 집중력도 많이 늘어난 것 같아요. Q. 학교로 돌아가면 졸업까지 1년 남짓 남았는데, 이번 현장 체험을 통해 세운 계획이나 결심이 있다면 이야기해주세요. 이번 기회를 통해서 무엇보다 기본이 중요하다는 것을 알게 됐어요. 사실 그동안 제가 짠 코드에 대해 동작 원리에 대한 생각을 깊이 있게 해본 적이 없었던 것 같은데, 이곳에 오면서 그게 가장 중요하다는 것을 알게 됐어요. 또 일은 혼자 하는게 아니고, 개발도 혼자 하는게 아니니까 제가 무엇을 하려고 했는지 의도가 잘 드러나는 코드를 짜는 게 중요하다는 생각을 하게 됐습니다. 그래서 돌아간 후에는 기본적인 내용들을 보충해 나가며 제가 부족했던 부분들을 채워 나갈 예정입니다.ㅎㅎ 2023.03.03

카프카를 통한 로그 관리 방법 카프카를 통한 로그 관리 방법 안녕하세요! 저는 개발4그룹에서 제니우스(Zenius) SIEM의 로그 관리 기능 개발을 담당하고 있는 김채욱 입니다. 제가 하고 있는 일은 실시간으로 대용량 로그 데이터를 수집하여 분석 후, 사용자에게 가치 있는 정보를 시각화하여 보여주는 일입니다. 이번 글에서 다룰 내용은 1) 그동안 로그(Log)에 대해 조사한 것과 2) 최근에 CCDAK 카프카 자격증을 딴 기념으로, 카프카(Kafka)를 이용하여 어떻게 로그 관리를 하는지에 대해 이야기해 보겠습니다. PART1. 로그 1. 로그의 표면적 형태 로그(Log)는 기본적으로 시스템의 일련된 동작이나 사건의 기록입니다. 시스템의 일기장과도 같죠. 로그를 통해 특정 시간에 시스템에서 ‘어떤 일’이 일어났는지 파악할 수도 있습니다. 이렇게 로그는 시간에 따른 시스템의 동작을 기록하고, 정보는 순차적으로 저장됩니다. 이처럼 로그의 핵심 개념은 ‘시간’입니다. 순차적으로 발생된 로그를 통해 시스템의 동작을 이해하며, 일종의 생활기록부 역할을 하죠. 시스템 내에서 어떤 행동이 발생하였고, 어떤 문제가 일어났으며, 유저와의 어떤 교류가 일어났는지 모두 알 수 있습니다. 만약 시간의 개념이 없다면 어떻게 될까요? 발생한 모든 일들이 뒤섞이며, 로그 해석을 하는데 어려움이 생기겠죠. 이처럼 로그를 통해 시스템은 과거의 변화를 추적합니다. 똑같은 상황이 주어지면 항상 같은 결과를 내놓는 ‘결정론적’인 동작을 보장할 수 있죠. 로그의 중요성, 이제 조금 이해가 되실까요? 2. 로그와 카프카의 관계 자, 그렇다면! 로그(Log)와 카프카(Kafka)는 어떤 관계일까요? 우선 카프카는 분산 스트리밍 플랫폼으로서, 실시간으로 대용량의 데이터를 처리하고 전송하는데 탁월한 성능을 자랑합니다. 그 중심에는 바로 ‘로그’라는 개념이 있는데요. 좀 더 자세히 짚고 넘어가 보겠습니다. 3. 카프카에서의 로그 시스템 카프카에서의 로그 시스템은, 단순히 시스템의 에러나 이벤트를 기록하는 것만이 아닙니다. 연속된 데이터 레코드들의 스트림을 의미하며, 이를 ‘토픽(Topic)’이라는 카테고리로 구분하죠. 각 토픽은 다시 *파티션(Partition)으로 나누어, 단일 혹은 여러 서버에 분산 저장됩니다. 이렇게 분산 저장되는 로그 데이터는, 높은 내구성과 가용성을 보장합니다. *파티션(Partition): 하드디스크를 논리적으로 나눈 구역 4. 카프카가 로그를 사용하는 이유 로그의 순차적인 특성은 카프카의 ‘핵심 아키텍처’와 깊게 연결되어 있습니다. 로그를 사용하면, 데이터의 순서를 보장할 수 있어 대용량의 데이터 스트림을 효율적으로 처리할 수 있기 때문이죠. 데이터를 ‘영구적’으로 저장할 수 있어, 데이터 손실 위험 또한 크게 줄어듭니다. 로그를 사용하는 또 다른 이유는 ‘장애 복구’입니다. 서버가 장애로 인해 중단되었다가 다시 시작되면, 저장된 로그를 이용하여 이전 상태로 복구할 수 있게 되죠. 이는 ‘카프카가 높은 가용성’을 보장하는 데 중요한 요소입니다. ∴ 로그 요약 로그는 단순한 시스템 메시지를 넘어 ‘데이터 스트림’의 핵심 요소로 활용됩니다. 카프카와 같은 현대의 데이터 처리 시스템은 로그의 이러한 특성을 극대화하여, 대용량의 실시간 데이터 스트림을 효율적으로 처리할 수 있는 거죠. 로그의 중요성을 다시 한번 깨닫게 되는 순간이네요! PART2. 카프카 로그에 이어 에 대해 설명하겠습니다. 들어가기에 앞서 가볍게 ‘구조’부터 알아가 볼까요? 1. 카프카 구조 · 브로커(Broker) 브로커는 *클러스터(Cluster) 안에 구성된 여러 서버 중 각 서버를 의미합니다. 이러한 브로커들은, 레코드 형태인 메시지 데이터의 저장과 검색 및 컨슈머에게 전달하고 관리합니다. *클러스터(Cluster): 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합 데이터 분배와 중복성도 촉진합니다. 브로커에 문제가 발생하면, 데이터가 여러 브로커에 데이터가 복제되어 데이터 손실이 되지 않죠. · 프로듀서(Producer) 프로듀서는 토픽에 레코드를 전송 또는 생성하는 *엔터티(Entity)입니다. 카프카 생태계에서 ‘데이터의 진입점’ 역할도 함께 하고 있죠. 레코드가 전송될 토픽 및 파티션도 결정할 수 있습니다. *엔터티(Entity): 업무에 필요한 정보를 저장하고 관리하는 집합적인 것 · 컨슈머(Consumer) 컨슈머는 토픽에서 레코드를 읽습니다. 하나 이상의 토픽을 구독하고, 브로커로부터 레코드를 소비합니다. 데이터의 출구점을 나타내기도 하며, 프로듀서에 의해 전송된 메시지를 최종적으로 읽히고 처리되도록 합니다. · 토픽(Topic) 토픽은 프로듀서로부터 전송된 레코드 카테고리입니다. 각 토픽은 파티션으로 나뉘며, 이 파티션은 브로커 간에 복제됩니다. 카프카로 들어오는 데이터를 조직화하고, 분류하는 방법을 제공하기도 합니다. 파티션으로 나눔으로써 카프카는 ‘수평 확장성과 장애 허용성’을 보장합니다. · 주키퍼(ZooKeeper) 주키퍼는 브로커를 관리하고 조정하는 데 도움을 주는 ‘중앙 관리소’입니다. 클러스터 노드의 상태, 토픽 *메타데이터(Metadata) 등의 상태를 추적합니다. *메타데이터(Metadata): 데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터 카프카는 분산 조정을 위해 주키퍼에 의존합니다. 주키퍼는 브로커에 문제가 발생하면, 다른 브로커에 알리고 클러스터 전체에 일관된 데이터를 보장하죠. ∴ 카프카 구조 요약 요약한다면 카프카는 1) 복잡하지만 견고한 아키텍처 2) 대규모 스트림 데이터를 실시간으로 처리하는 데 있어 안정적이고 장애 허용성이 있음 3) 고도로 확장 가능한 플랫폼을 제공으로 정리할 수 있습니다. 이처럼 카프카가 큰 데이터 환경에서 ‘어떻게’ 정보 흐름을 관리하고 최적화하는지 5가지의 구조를 통해 살펴보았습니다. 이제 카프카에 대해 조금 더 명확한 그림이 그려지지 않나요? 2. 컨슈머 그룹과 성능을 위한 탐색 카프카의 가장 주목할 만한 특징 중 하나는 ‘컨슈머 그룹의 구현’입니다. 이는 카프카의 확장성과 성능 잠재력을 이해하는 데 중심적인 개념이죠. 컨슈머 그룹 이해하기 카프카의 핵심은 ‘메시지를 생산하고 소비’ 하는 것입니다. 그런데 수백만, 심지어 수십억의 메시지가 흐르고 있을 때 어떻게 효율적으로 소비될까요? 여기서 컨슈머 그룹(Consumer Group)이 등장합니다. 컨슈머 그룹은, 하나 또는 그 이상의 컨슈머로 구성되어 하나 또는 여러 토픽에서 메시지를 소비하는데 협력합니다. 그렇다면 왜 효율적인지 알아보겠습니다. · 로드 밸런싱: 하나의 컨슈머가 모든 메시지를 처리하는 대신, 그룹이 부하를 분산할 수 있습니다. 토픽의 각 파티션은 그룹 내에서 정확히 하나의 컨슈머에 의해 소비됩니다. 이는 메시지가 더 빠르고 효율적으로 처리된다는 것을 보장합니다. · 장애 허용성: 컨슈머에 문제가 발생하면, 그룹 내의 다른 컨슈머가 그 파티션을 인수하여 메시지 처리에 차질이 없도록 합니다. · 유연성: 데이터 흐름이 변함에 따라 그룹에서 컨슈머를 쉽게 추가하거나 제거합니다. 이에 따라 증가하거나 감소하는 부하를 처리할 수 있습니다. 여기까지는 최적의 성능을 위한 ‘카프카 튜닝 컨슈머 그룹의 기본 사항’을 다루었으니, 이와 관련된 ‘성능 튜닝 전략’에 대해 알아볼까요? 성능 튜닝 전략 · 파티션 전략: 토픽의 파티션 수는, 얼마나 많은 컨슈머가 활성화되어 메시지를 소비할 수 있는지 영향을 줍니다. 더 많은 파티션은 더 많은 컨슈머가 병렬로 작동할 수 있음을 의미하는 거죠. 그러나 너무 많은 파티션은 *오버헤드를 야기할 수 있습니다. *오버헤드: 어떤 처리를 하기 위해 간접적인 처리 시간 · 컨슈머 구성: *fetch.min.bytes 및 *fetch.max.wait.ms와 같은 매개변수를 조정합니다. 그다음 한 번에 얼마나 많은 데이터를 컨슈머가 가져오는지 제어합니다. 이러한 최적화를 통해 브로커에게 요청하는 횟수를 줄이고, 처리량을 높입니다. *fetch.min.bytes: 한 번에 가져올 수 있는 최소 데이터 사이즈 *fetch.max.wait.ms: 데이터가 최소 크기가 될 때까지 기다릴 시간 · 메시지 배치: 프로듀서는 메시지를 함께 배치하여 처리량을 높일 수 있게 구성됩니다. *batch.size 및 *linger.ms와 같은 매개변수를 조정하여, 대기 시간과 처리량 사이의 균형을 찾을 수 있게 되죠. *batch.size: 한 번에 모델이 학습하는 데이터 샘플의 개수 *linger.ms: 전송 대기 시간 · 압축: 카프카는 메시지 압축을 지원하여 전송 및 저장되는 데이터의 양을 줄입니다. 이로 인해 전송 속도가 빨라지고 전체 성능이 향상될 수 있습니다. · 로그 정리 정책: 카프카 토픽은, 설정된 기간 또는 크기 동안 메시지를 유지할 수 있습니다. 보존 정책을 조정하면, 브로커가 저장 공간이 부족해지는 점과 성능이 저하되는 점을 방지할 수 있습니다. 3. 컨슈머 그룹과 성능을 위한 실제 코드 예시 다음 그림과 같은 코드를 보며 조금 더 자세히 살펴보겠습니다. NodeJS 코드 중 일부를 발췌했습니다. 카프카 설치 시에 사용되는 설정 파일 *server.properties에서 파티션의 개수를 CPU 코어 수와 같게 설정하는 코드입니다. 이에 대한 장점들을 쭉 살펴볼까요? *server.properties: 마인크래프트 서버 옵션을 설정할 수 있는 파일 CPU 코어 수에 파티션 수를 맞추었을 때의 장점 · 최적화된 리소스 활용: 카프카에서는 각 파티션이 읽기와 쓰기를 위한 자체 *I/O(입출력) 스레드를 종종 운영합니다. 사용 가능한 CPU 코어 수와 파티션 수를 일치시키면, 각 코어가 특정 파티션의 I/O 작업을 처리합니다. 이 동시성은 리소스에서 최대의 성능을 추출하는 데 도움 됩니다. · 최대 병렬 처리: 카프카의 설계 철학은 ‘병렬 데이터 처리’를 중심으로 합니다. 코어 수와 파티션 수 사이의 일치는, 동시에 처리되어 처리량을 높일 수 있습니다. · 간소화된 용량 계획: 이 접근 방식은, 리소스 계획에 대한 명확한 기준을 제공합니다. 성능 병목이 발생하면 CPU에 *바인딩(Binding)되어 있는지 명확하게 알 수 있습니다. 인프라를 정확하게 조정할 수도 있게 되죠. *바인딩(Binding): 두 프로그래밍 언어를 이어주는 래퍼 라이브러리 · 오버헤드 감소: 병렬 처리와 오버헤드 사이의 균형은 미묘합니다. 파티션 증가는 병렬 처리를 촉진할 수 있습니다. 하지만 더 많은 주키퍼 부하, 브로커 시작 시간 연장, 리더 선거 빈도 증가와 같은 오버헤드도 가져올 수도 있습니다. 파티션을 CPU 코어에 맞추는 것은 균형을 이룰 수 있게 합니다. 다음은 프로세스 수를 CPU 코어 수만큼 생성하여, 토픽의 파티션 개수와 일치시킨 코드에 대한 장점입니다. 파티션 수와 컨슈머 프로세스 수 일치의 장점 · 최적의 병렬 처리: 카프카 파티션의 각각은 동시에 처리될 수 있습니다. 컨슈머 수가 파티션 수와 일치하면, 각 컨슈머는 특정 파티션에서 메시지를 독립적으로 소비할 수 있게 되죠. 따라서 병렬 처리가 향상됩니다. · 리소스 효율성: 파티션 수와 컨슈머 수가 일치하면, 각 컨슈머가 처리하는 데이터의 양이 균등하게 분배됩니다. 이로 인해 전체 시스템의 리소스 사용이 균형을 이루게 되죠. · 탄력성과 확장성: 트래픽이 증가하면, 추가적인 컨슈머를 컨슈머 그룹에 추가하여 처리 능력을 증가시킵니다. 동일한 방식으로 트래픽이 감소하면 컨슈머를 줄여 리소스를 절약할 수 있습니다. · 고가용성과 오류 회복: 컨슈머 중 하나가 실패하면, 해당 컨슈머가 처리하던 파티션은 다른 컨슈머에게 자동 재분배됩니다. 이를 통해 시스템 내의 다른 컨슈머가 실패한 컨슈머의 작업을 빠르게 인수하여, 메시지 처리가 중단되지 않습니다. 마지막으로 각 프로세스별 컨슈머를 생성해서 토픽에 구독 후, 소비하는 과정을 나타낸 소스코드입니다. ∴ 컨슈머 그룹 요약 컨슈머 그룹은 높은 처리량과 장애 허용성 있는 메시지 소비를 제공하는 능력이 핵심입니다. 카프카가 어떤 식으로 운영되는지에 대한 상세한 부분을 이해하고 다양한 매개변수를 신중하게 조정한다면, 어떠한 상황에서도 카프카의 최대 성능을 이끌어낼 수 있습니다! ------------------------------------------------------------ ©참고 자료 · Jay Kreps, “I Hearts Logs”, Confluent · 위키피디아, “Logging(computing)” · Confluent, “https://docs.confluent.io/kafka/overview.html” · Neha Narkhede, Gwen Shapira, Todd Palino, “Kafka: The Definitive Guide” ------------------------------------------------------------ 2023.09.19

메모리 누수 위험있는 FinalReference 참조 분석하기 메모리 누수 위험있는 FinalReference 참조 분석하기 Java에서 가장 많이 접하는 문제는 무엇이라 생각하시나요? 바로 리소스 부족 특히 ‘JVM(Java Virtual Machine) 메모리 부족 오류’가 아닐까 생각해요. 메모리 부족 원인에는 우리가 일반적으로 자주 접하는 누수, 긴 생명주기, 다량의 데이터 처리 등 몇 가지 패턴들이 있는데요. 오늘은 좀 일반적이지 않은(?) 유형에 대해 이야기해 볼게요! Java 객체 참조 시스템은 강력한 참조 외에도 4가지 참조를 구현해요. 바로 성능과 확장성 기타 고려사항에 대한 SoftReference, WeakReference, PhantomReference, FinalReference이죠. 이번 포스팅은 FinalReference를 대표적인 사례로 다루어 볼게요. PART1. 분석툴을 활용해 메모리 누수 발생 원인 파악하기 메모리 분석 도구를 통해 힙 덤프(Heap Dump)를 분석할 때, java.lang.ref.Finalizer 객체가 많은 메모리를 점유하는 경우가 있어요. 이 클래스는 FinalReference와 불가분의 관계에요. 나눌 수 없는 관계라는 의미죠. 아래 그림 사례는 힙 메모리(Heap Memory)의 지속적인 증가 후 최대 Heap에 근접 도달 시, 서비스 무응답 현상에 빠지는 분석 사례인데요. 이를 통해 FinalReference 참조가 메모리 누수를 발생시킬 수 있는 조건을 살펴볼게요! Heap Analyzer 분석툴을 활용하여, 힙 덤프 전체 메모리 요약 현황을 볼게요. java.lang.ref.Finalizer의 점유율이 메모리의 대부분을 점유하고 있죠. 여기서 Finalizer는, 앞에서 언급된 FinalReference를 확장하여 구현한 클래스에요. JVM은 GC(Garbage Collection) 실행 시 해제 대상 객체(Object)를 수집하기 전, Finalize를 처리해야 해요. Java Object 클래스에는 아래 그림과 같이 Finalize 메서드(Method)가 존재하는데요. 모든 객체가 Finalize 대상은 아니에요. JVM은 클래스 로드 시, Finalize 메서드가 재정의(Override)된 객체를 식별해요. 객체 생성 시에는 Finalizer.register() 메서드를 통해, 해당 객체를 참조하는 Finalizer 객체를 생성하죠. 그다음은 Unfinalized 체인(Chain)에 등록해요. 이러한 객체는 GC 발생 시 즉시 Heap에서 수집되진 않아요. Finalizer의 대기 큐(Queue)에 들어가 객체에 재정의된 Finalize 처리를 위해 대기(Pending) 상태에 놓여있죠. 위 그림과 같이 참조 트리(Tree)를 확인해 보면, 많은 Finalizer 객체가 체인처럼 연결되어 있어요. 그럼 Finalizer 객체가 실제 참조하고 있는 객체는 무엇인지 바로 살펴볼까요? 그림에 나온 바와 같이 PostgreSql JDBC Driver의 org.postgresql.jdbc3g.Jdbc3gPreparedStatement인 점을 확인할 수 있어요. 해당 시스템은 PostgreSql DB를 사용하고 있었네요. 이처럼 Finalizer 참조 객체 대부분은 Jdbc3gPreparedStatement 객체임을 알 수 있어요. 여기서 Statement 객체는, DB에 SQL Query를 실행하기 위한 객체에요. 그렇다면, 아직 Finalize 처리되지 않은 Statement 객체가 증가하는 이유는 무엇일까요? 먼저 해당 Statement 객체는 실제로 어디서 참조하는지 살펴볼게요. 해당 객체는 TimerThread가 참조하는 TaskQueue에 들어가 있어요. 해당 Timer는 Postgresql Driver의 CancelTimer이죠. 해당 Timer의 작업 큐를 확인해 보면 PostgreSql Statement 객체와 관련된 Task 객체도 알 수도 있어요. 그럼 org.postgresql.jdbc3g.Jdbc3gPreparedStatement 클래스가 어떻게 동작하는지 자세히 알아볼까요? org.postgresql.jdbc3g.Jdbc3gPreparedStatement는 org.postgresql.jdbc2.AbstractJdbc2Statement의 상속 클래스이며 finalize() 메서드를 재정의한 클래스에요. Finalize 처리를 위해 객체 생성 시, JVM에 의해 Finalizer 체인으로 등록되죠. 위와 같은 코드로 보아 CancelTimer는, Query 실행 후 일정 시간이 지나면 자동으로 TimeOut 취소 처리를 위한 Timer에요. 정해진 시간 내에 정상적으로 Query가 수행되고 객체를 종료(Close) 시, Timer를 취소하도록 되어 있어요. 이때 취소된 Task는 상태 값만 변경되고, 실제로는 Timer의 큐에서 아직 사라지진 않아요. Timer에 등록된 작업은, TimerThread에 의해 순차적으로 처리돼요. Task는 TimerThread에서 처리를 해야 비로소 큐에서 제거되거든요. 이때 가져온 Task는 취소 상태가 아니며, 처리 시간에 아직 도달하지 않은 경우 해당 Task의 실행 예정 시간까지 대기해야 돼요. 여기서 문제점이 발생해요. 이 대기 시간이 길어지면 TimerThread의 처리가 지연되기 때문이죠. 이후 대기 Task들은 상태 여부에 상관없이, 큐에 지속적으로 남아있게 돼요. 만약 오랜 시간 동안 처리가 진행되지 않는다면, 여러 번의 Minor GC 발생 후 참조 객체들은 영구 영역(Old Gen)으로 이동될 수 있어요. 영구 영역으로 이동된 객체는, 메모리에 즉시 제거되지 못하고 오랜 기간 남게 되죠. 이는 Old(Full) GC를 발생시켜 시스템 부하를 유발하게 해요. 실제로 시스템에 설정된 TimeOut 값은 3,000초(50분)에요. Finalizer 참조 객체는 GC 발생 시, 즉시 메모리에서 수집되지 않고 Finalize 처리를 위한 대기 큐에 들어가요. 그다음 FinalizerThread에 의해 Finalize 처리 후 GC 발생 시 비로소 제거되죠. 때문에 리소스의 수집 처리가 지연될 수 있어요. 또한 FinalizerThread 스레드는 우선순위가 낮아요. Finalize 처리 객체가 많은 경우, CPU 리소스가 상대적으로 부족해지면 개체의 Finalize 메서드 실행을 지연하게 만들어요. 처리되지 못한 객체는 누적되게 만들죠. 요약한다면 FinalReference 참조 객체의 잘못된 관리는 1) 객체의 재 참조를 유발 2) 불필요한 객체의 누적을 유발 3) Finalize 처리 지연으로 인한 리소스 누적을 유발하게 해요. PART2. 제니우스 APM을 통해 Finalize 객체를 모니터링하는 방법 Zenius APM에서는 JVM 메모리를 모니터링하고 분석하기 위한, 다양한 데이터를 수집하고 있어요. 상단에서 보았던 FinalReference 참조 객체의 현황에 대한 항목도 확인할 수 있죠. APM 모니터링을 통해 Finalize 처리에 대한 문제 발생 가능성도 ‘사전’에 확인 할 수 있답니다! 위에 있는 그림은 Finalize 처리 대기(Pending)중인 객체의 개수를 확인 가능한 컴포넌트에요. 이외에도 영역별 메모리 현황 정보와 GC 처리 현황에 대해서도 다양한 정보를 확인 할 수 있어요! 이상으로 Finalize 처리 객체에 의한 리소스 문제 발생 가능성을, 사례를 통해 살펴봤어요. 서비스에 리소스 문제가 발생하고 있다면, 꼭 도움이 되었길 바라요! ------------------------------------------------------------ ©참고 자료 ◾ uxys, http://www.uxys.com/html/JavaKfjs/20200117/101590.html ◾ Peter Lawrey, 「is memory leak? why java.lang.ref.Finalizer eat so much memory」, stackoverflow, https://stackoverflow.com/questions/8355064/is-memory-leak-why-java-lang-ref-finalizer-eat-so-much-memory ◾ Florian Weimer, 「Performance issues with Java finalizersenyo」, enyo, https://www.enyo.de/fw/notes/java-gc-finalizers.html ------------------------------------------------------------ 2023.10.12

[전시회] ‘CDA 컨퍼런스’를 통해 해법을 제시한 브레인즈컴퍼니 [전시회] ‘CDA 컨퍼런스’를 통해 해법을 제시한 브레인즈컴퍼니 지난 11월 29일, 브레인즈컴퍼니가 잠실 롯데호텔에서 열린 「CDA컨퍼런스」에 참가했어요. 브레인즈컴퍼니는 이번 컨퍼런스를 통해 성공적인 클라우드 전환을 위한 비전과 해법을 제시했는데요. 자세한 후기를 바로 들려드릴게요! CDA컨퍼런스는 「클라우드 데이터센터 협의회(이하 CDA)」에서 주관한 이번 컨퍼런스는, '클라우드 네이티브 및 SaaS 전환을 위한 클라우드 데이터 센터의 첫걸음'이라는 주제로 클라우드 분야별(SaaS, Cloud, Infra) 전문기업 30개사가 참여했는데요. ▲CDA 컨퍼런스 2023 개회식 ▲CDA 컨퍼런스 2023 기조강연 이번 컨퍼런스는 기업·공공·의료·교육 등 다양한 영역에서 디지털 서비스/솔루션/인프라를 제공하는 많은 회원사들이 참가하여, 클라우드에 대한 비전과 서비스의 우수성을 소개했어요. 총 천명 이상이 참가한 이번 컨퍼런스는 크게 기조강연·주제별강연·전시부스로 나누어 진행됐어요. 성공적인 클라우드 전환을 위한 모니터링 방안 강연 브레인즈컴퍼니는 강연과 부스 운영을 통해, 클라우드 전환기의 성공적인 모니터링에 대한 비전을 제시했는데요. 먼저 '성공적인 클라우드 전환을 위한 효율적인 모니터링 방안'이라는 주제로 강연을 진행했어요. 브레인즈컴퍼니의 오다인 님께서 과도기에 봉착한 클라우드 전환 현황, 클라우드 전환 과도기 하이브리드 환경에서의 모니터링 전략, 성공적인 모니터링 솔루션 선택 기준 이렇게 세 가지 이슈를 중심으로 구성하여 강연을 진행하셨어요. 이날 강연을 통해 브레인즈컴퍼니는, 과도기에 봉착한 클라우드 전환기에서 성공적으로 모니터링할 수 있는 명확한 해법을 제시해 드렸어요. 총 이백여 명 이상의 참관객들이 브레인즈컴퍼니의 강연을 경청해 주셨는데요. 강연의 뜨거운 열기는 브레인즈컴퍼니의 부스에 대한 관심으로 이어졌어요. 열띤 관심이 이어진 브레인즈컴퍼니의 부스 브레인즈컴퍼니 부스에선, 브로슈어와 제품데모(Demo) 시연을 통해 제니우스(Zenius)에 대해 자세히 알리는 시간을 가졌는데요. ▲큰 관심을 끌었던 브레인즈컴퍼니의 부스 부스에 방문한 참관객분들은 클라우드뿐 아니라, 온프레미스 환경도 모니터링이 가능한 점과 EMS·APM·SIEM·ITSM 등 핵심제품들의 기능을 모듈화하여 사용할 수 있는 부분에도 큰 관심을 보여주셨어요. 브레인즈컴퍼니의 심재걸, 김선효, 오다인, 최승훈 님께서 Zenius 제품에 대한 구체적인 설명을 진행해 주셨는데요. 기본적인 설명 이후에 참관객분들의 상황별로 다양한 문의가 이어졌어요. 이에 대해 막힘없이 답변을 해드리며 열띤 분위기를 이어갔답니다! 부스에 방문하신 한 참관객분은 "지금 회사가 클라우드로의 전환기에 있어, 모니터링 서비스가 필요했었어요. 오늘 설명을 들어보니 Zenius가 적합하다고 판단되어 도입에 대해 긍정적으로 검토할 계획이에요"라며 만족감을 나타내셨어요. 브레인즈컴퍼니는 이번 CDA 컨퍼런스를 통해, 새로운 비전을 제시하고 많은 분들께 Zenius를 알릴 수 있었어요. 앞으로 CDA 컨퍼런스뿐만 아니라 다양한 온·오프라인을 통해 IT 인프라 모니터링의 새로운 비전을 제시하고, Zenius의 우수성을 알릴 예정인데요. 여러분들의 많은 관심과 응원 부탁드릴게요🙌 2023.12.05

블로그

추천 콘텐츠