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

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

메인 페이지로 이동
블로그
최신이야기

블로그

최신이야기

기술이야기 디자인 시스템이 필요한 이유와 핵심요소는? 기술이야기 디자인 시스템이 필요한 이유와 핵심요소는? “우리나라 금융 유니콘 기업이 개발과정에서 1,000시간을 아낀 비결” “애플과 구글이 제품을 기획하고 개발할 때 가장 중요하게 생각하는 것” 디자인 시스템은 무엇일까? 위에 있는 두 문장의 답은 바로 ‘디자인 시스템’이에요. 고객이 하나의 브랜드를 접하는 순간부터 끝까지 지속적으로 동일한 경험을 하게 해주는 디자인 시스템의 중요도는, 점점 더 커지고 있죠. 디자인 시스템은 시맨틱 컬러, 컴포넌트 디자인, 디자인 토큰 등을 구축하여 제품 전반에서 사용자가 일괄적인 시각적 경험을 할 수 있도록 도와주고 있어요. 제품을 더 빠르고 효율적으로 만들어주기도 해요. 그리하여 이번 시간에는 1) 디자인 시스템은 구체적으로 무엇이고 2) 브레인즈컴퍼니는 어떤 노력을 하고 있는지 살펴볼게요! 디자인 시스템의 요소1 : 시맨틱 컬러 ▲Zenius ITSM 버튼에 적용된 컬러 시스템 디자인 시스템의 중요 요소 중 하나인 '시맨틱 컬러'는, 사용 방법에 따라 색상 이름을 지정하는 방법이에요. 브레인즈컴퍼니의 제니우스(Zenius)도 시맨틱 컬러를 사용하고 있는데요. Primary, Secondary, Tertiary, Ghost, Gray, Severity Color 등으로 구성되어 있어요. 여기서 Primary 컬러는 UI 전체의 주요 구성 요소에 대한 역할을 해줘요. 가장 중요한 액션에 사용하며, 화면에서 가장 강력한 클릭 유도 문안인 CTA(call to action)을 강조하기 위해 사용하기도 하죠. ▲Zenius ITSM Primary 컬러의 변천사 Zenius ITSM은 BI 컬러를 보완한 Primary 색상을 사용 중이며, Secondary와 Tertiary는 이와 어울리는 색상을 지정해 사용하고 있어요. 브레인즈컴퍼니의 컬러는 선명한 파란색이지만, 제품 화면에 사용하기에는 채도가 너무 높아 두 번의 GUI 테스트를 거쳐 위와 같이 보완한 색상이 나왔어요. Secondary와 Tertiaty 사용 시 화면 구성의 위계질서에 따라 색상을 설정하여 중요도(중요, 보조, 부가)를 표현하기도 해요. [잠깐의 TMI🤭] 브레인즈컴퍼니 브랜드 색상인 Blue는 한국에서 가장 선호도가 높은 색상이며, 신뢰·젊음·성실·책임감 등의 이미지를 지닌 색상이에요. ▲컬러 팔레트 디자인 시스템의 요소2 : 심각도 컬러 ▲심각도 컬러 팔레트 '심각도 컬러'는 Zenius에서 사용하는 시맨틱 컬러의 일종이에요. Zenius에서 발생한 이벤트를 알려주는 색상으로 총 6단계의 색상을 구축하여서 사용하고 있답니다. 정상, 무해, 주의, 위험, 긴급, 치명의 6단계이며 위와 같은 컬러를 사용하고 있어요. 디자인 시스템의 요소3 : 디자인 토큰 '디자인 토큰'은 디자인 시스템의 시각적 디자인 요소이며, 디자인 관련 변수를 저장하는 데 사용하는 기본 요소에요. 기존에는 피그마(Figma)에서 컬러나 폰트 등을 Style로만 지정할 수 있었어요. 같은 색상을 여러 개의 항목에 적용할 경우, 토큰 별로 사용할 수 없는 점이 굉장히 불편했죠. 하지만 Figma의 Variable 기능이 업데이트된 후, 토큰을 만들 수 있게 되었어요! 브레인즈컴퍼니의 메인 제품 Zenius는 총 세 개의 테마를 사용 중이라, 디자인 토큰 시스템을 테스트하고 있답니다. ▲컬러 토큰 시스템 위와 같이 속성이 다른 두 개의 디자인에 동일하게 Neutral-500 컬러를 사용했는데요, 토큰별로 색상을 적용할 수 있는 시스템이라, 같은 색상을 지닌 다른 속성이어도 개별로 컬러 관리가 가능한 장점이 있어요. 개발자와의 협업에도 굉장히 좋은 시스템이랍니다! 。。。。。。。。。。。。 제니우스(Zenius) 제품이 태어난 지 오래된 만큼, 제품 디자이너가 여러 번 바뀌었어요. 컬러 시스템에 대한 가이드도 중간중간 변경되었죠. 브레인즈컴퍼니 디자인팀은 컬러 시스템을 다시 재정비하기 위해, 여러 가지 테스트 과정을 거치고 있어요. 아직은 구축 단계에 있어 디자인 팀 내의 규칙이나, 개발자들과 네이밍 규칙 등 협의해야 할 일이 적진 않아요. 그래도 구축이 완료된다면 정말 소통하기 편해질 거 같아요! 이제 곧 완성될 '디자인 시스템'을 통해 한층 더 성숙해질 Zenius! 많은 기대 부탁드려요😊 2023.12.12
회사이야기 [전시회] ‘공공용 민간 SaaS 서비스 제공기업’으로 선정된 브레인즈컴퍼니 회사이야기 [전시회] ‘공공용 민간 SaaS 서비스 제공기업’으로 선정된 브레인즈컴퍼니 브레인즈컴퍼니가 행정안전부와 한국정보사회진흥원(NIA)가 선정한 ‘공공용 민간 SaaS 서비스 제공기업’에 선발되었습니다. 。。。。。。。。。。。。 공공용 민간 SaaS 시범이용 사업은? 공공용 민간 SaaS 시범 이용 사업이란, 중앙정부·지자체·공공기관이 업무처리를 위한 정보시스템이나 소프트웨어를 직접 구축하거나 구매하지 않고 민간 클라우드(SaaS)서비스 이용을 장려하는 사업입니다. 쉽게 요약한다면, 업무상 필요한 모든 서비스를 이제 SaaS 형태로 이용한다는 의미입니다! ‘디지털 플랫폼 정부’ 혁신활동의 일환인 이번 사업을 위해, 행정안전부와 NIA는 엄격한 심사를 거쳐서 제공기업을 선정했는데요. 서비스 제공기업 주요 심사기준 ▪CSAP(클라우드 보안인증) 획득 여부 ▪높은 등급의 기업신용평가 등급 ▪행정·공공 기관이 이용 가능한 SaaS 서비스 보유 여부 등 브레인즈컴퍼니는 위에 있는 내용을 중심으로 심사를 거쳐 네이버클라우드, 더존비즈온, 가비아 등과 함께 서비스 제공기업으로 선정되었습니다👏 공공용 민간 SaaS 매칭데이 진행 서비스 제공기업 선정 이후에 사업 활성화를 위해, 지난 24일 부산 벡스코에서 ‘2023 대한민국 정부 박람회의 부대행사’로 「매칭데이」가 진행되었는데요. 현재 정부가 디지털 플랫폼 정부를 표방하는 만큼 박람회의 열기는 뜨거웠습니다! 매칭데이는 총 2부로 진행되었는데요. 1부는 SaaS 활용 촉진 사업 안내와 기업별 SaaS 소개, 2부에서는 ‘맞춤 상담’으로 구성되었습니다. 1부ㅣ브레인즈컴퍼니의 특장점이 주목받다 1부에서는 기업별 SaaS 소개 순서에서 저희 브레인즈컴퍼니도 발표를 진행했습니다. 연속적인 기술 지원으로 높은 만족도의 고객서비스 제공, IT 인프라 서비스 관리를 위한 20여 종의 플랫폼 서비스, 높은 신용평가 등급 및 다수의 고객 등! 발표를 통해 소개된 브레인즈컴퍼니와 서비스의 특장점에 대해서 많은 참관객분들께서 관심을 가져주셨습니다. 2부ㅣ기업별 맞춤 상담에도 이어진 관심 2부에서는 벡스코 회의실에 위치한 전담 부스에서, 고객별 상황에 따른 ‘맞춤 상담’ 시간을 가졌는데요. 비록 약 100분의 길지 않은 시간이었지만, 많은 분들이 저희 부스를 찾아주셨습니다. 부스에서는 제니우스(Zenius) EMS의 실제 데모 화면을 기반으로 자세히 설명을 드리고, 고객 상황별 맞춤 안내를 진행하여 좋은 반응을 얻을 수 있었습니다! 。。。。。。。。。。。。 공공용 민간 SaaS 서비스 제공 업체로 선정된 브레인즈컴퍼니는, 이번 매칭데이를 시작으로 보다 많은 행정기관 및 공기업에 IT 인프라·서비스 통합 모니터링 서비스를 제공하는데 속도를 낼 예정입니다. 브레인즈컴퍼니가 공공용 관제 서비스 시장에서 지속해서 선두를 유지하고, ‘디지털 정부 플랫폼’으로의 혁신에 기여할 수 있도록 많은 관심과 응원 부탁드립니다! 감사합니다🙇‍♀️ 2023.12.07
회사이야기 [전시회] 브레인즈컴퍼니 ‘소프트웨이브 2023’에서 새로운 비전 제시 회사이야기 [전시회] 브레인즈컴퍼니 ‘소프트웨이브 2023’에서 새로운 비전 제시 브레인즈컴퍼니가 11월 29일(수)부터 12월 1일(금)까지 삼성동 코엑스에서 국내 최대 소프트웨어(SW) 전시회인 「소프트웨이브 2023(소프트웨어 대전)」에 참가했어요. 자회사인 AI 전문기업 ‘에이프리카’와 함께 “AI, 클라우드 네이티브의 창을 열다. 디지털 플랫폼을 위한 Brainz Group”이라는 슬로건 아래 IT 분야의 새로운 비전을 제시하기 위해 참가한 것인데요. 「소프트웨이브 2023」 전시회는 참관객 3만 명, 국내외를 대표하는 320개 사, 557개 홍보 부스가 참가할 정도로 뜨거운 관심 아래 진행되었어요. 브레인즈컴퍼니와 에이프리카는 참관객분들께 자사 핵심 제품을 다채롭고 직관적으로 보여드리기 위해 세미나, 이벤트, 이 밖에도 다양한 콘텐츠를 마련했답니다. 3일 동안 많은 참관객분들과 마주하는 자리여서 더더욱 설레었던 소프트웨이브 2023 전시회. 그 현장감을 담은 후기 바로 시작할게요! 。。。。。。。。。。。。 브레인즈컴퍼니 부스 탐험 브레인즈컴퍼니와 에이프리카의 부스는 멀리서 봐도 한눈에 띨 정도로 웅장했는데요! 부스 곳곳에 브레인즈컴퍼니와 에이프리카의 제품을 다양한 형태로 구성해 보았어요. 참관객분들과 가장 처음 마주하는 안내데스크, 핵심 제품인 데모 영상과 대시보드 영상, 세미나 공간까지! 무엇보다 브레인저가 여러분들을 기다리고 있었답니다😌 특히 데모 영상과 대시보드 영상을 통해 제니우스(Zenius)의 핵심제품인 EMS·APM·ITSM·SIEM을 직관적으로 소개해 드릴 수 있었는데요. 제품별 담당 엔지니어가 제니우스를 데모화면과 함께 직접 설명해 드리고 시연해 드리는 자리를 마련해서, 참관객 분들께 좋은 반응을 얻었어요! 브레인즈컴퍼니 x 에이프리카 세미나 Brainz Group Tech Talk 2023 브레인즈컴퍼니는 에이프리카와 함께 「Brainz Group Tech Talk 2023」 이름으로 세미나를 진행하기도 했는데요. ‘인공지능(AI) & 클라우드(Cloud)’를 성공적으로 디지털 전환하기 위한 네 가지 주제를 선보여드렸습니다. ▲광주과학기술원 사례로 본 대규모 AI 플랫폼 구축방안 ▲MLOps와 DevOps를 활용한 프라이빗 LLM 구축방안 ▲클라우드 전환기의 성공적인 IT 인프라 모니터링 방안 ▲디지털 플랫폼 정부의 클라우드 네이티브 구현 사례를 참관객분들께 보여드리는 자리를 가졌답니다. 이 밖에도 QR코드를 통해 온라인 설문 참여를 해주신 참관객분들에 한해, 스타벅스 커피 쿠폰 이벤트도 진행했어요. 이처럼 다양한 콘텐츠로 채워진 브레인즈컴퍼니 부스에 많은 참관객들이 몰리며 대 성황을 이루었습니다! 。。。。。。。。。。。。 소프트웨이브 2023 전시회를 통해 많은 고객분들과 마주하고, 저희 제품을 다양한 각도에서 알릴 수 있어 뿌듯하고 행복했던 시간이었어요. 자회사인 에이프리카와 함께해서 더더욱 뜻깊었답니다. 3일 동안 브레인즈컴퍼니와 에이프리카 큰 관심 보내주셔서 감사드리며, 앞으로도 IT 인프라 통합모니터링 분야뿐만 아니라 인공지능(AI) & 클라우드(Cloud) 분야에서 지속적으로 차별화된 서비스를 보여드릴게요! PS. 3일 동안 진행한 소프트웨이브 2023 전시회인 만큼 아직도 못다 한 얘기가 아직도 많아요. 다음에는 소프트웨이브 2023 못다 한 이야기 시즌2 콘텐츠로 돌아올게요-! To be continued… 2023.12.06
회사이야기 [전시회] ‘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
기술이야기 클라우드(Cloud) 관리와 AWS가 뭔가요? 기술이야기 클라우드(Cloud) 관리와 AWS가 뭔가요? 오늘날 IT 인프라 운영환경은 매우 복잡해졌어요. 갑작스러운 환경 변화에 따라 신속한 대응도 필요한 시점이죠. 이러한 현상으로 많은 기업들이 온프레미스(On-premise) 환경에서 클라우드(Cloud) 환경으로 전환하는 추세이기도 해요. 클라우드 컴퓨팅 서비스 중에는 여러 벤더가 있는데요. 대표적으론 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)가 있어요. 그중 ‘AWS’는 국내 클라우드 시장에서 3년 간 70% 내외의 시장점유율로, 1위를 차지했는데요(*클라우드 서비스 분야 실태조사(2022), 공정거래위원회) 이처럼 높은 점유율을 가진 1) AWS의 주요 서비스를 살펴보고 2) 하이브리드 클라우드 모니터링이 필요한 이유는 무엇인지 3) AWS의 각종 서비스를 모니터링할 수 있는 제니우스(Zenius)도 함께 소개해 드릴게요! AWS(Amazon Web Services)란? AWS는 ‘Amazon Web Services’의 약어로, 아마존 닷컴이 제공하는 클라우드 컴퓨팅 플랫폼 및 서비스의 집합이에요. AWS에서 제공하는 여러 가지 서비스를 이용하면, 기업 및 개인이 필요한 컴퓨팅 리소스를 유연하게 확장하고 관리할 수 있죠. AWS 주요 서비스는 다음과 같아요! AWS 주요 서비스 ▪Amazon VPC(Amazon Virtual Private Cloud) 격리된 네트워크 환경을 구성하게 해주는 서비스예요. AWS의 동일 계정이나, 서로 다른 계정 간에 격리된 네트워크를 연결할 수 있도록 다양한 옵션들을 제공해 줘요. ▪Amazon EC2(Amazon Elastic Compute Cloud) AWS에서 가장 많이 사용되는 컴퓨팅 서비스예요. 가상 서버를 호스팅 할 때 사용하죠. 리눅스나 윈도우 환경 등 다양한 인스턴스 유형을 지원하고, 필요에 따라 성능을 조정할 수 있어요. 생성 가능한 인스턴스 타입은 리전 별 차이가 있으나, 100개~300개에 이를 정도로 방대하답니다. ▪AWS Lambda AWS에서 제공하는 서버리스 컴퓨팅 플랫폼이에요. 여기서 ‘서버리스’란 개발자가 서버의 존재를 신경 쓸 필요가 없다는 뜻이에요. AWS에서는 서버 인프라에 대한 프로비저닝, 유지관리 등을 대신 처리해 주죠. 이처럼 개발자가 비즈니스 로직에 집중하여 코드를 실행하게 해줘요. ▪Amazon S3 AWS에서 제공하는 스토리지 서비스예요. S3는 파일시스템이 아닌 오브젝트 스토리지 서비스로, 모든 파일에 API를 통해 접근 가능해요. 무제한적인 확장성, 높은 가용성과 내구성을 제공하며 단일 파일을 최대 5TB까지 업로드할 수 있어요. ▪Amazon EBS(Amazon Elastic Block Store) EC2 인스턴스에 장착하여 사용할 수 있는 가상 저장 장치에요. EBS를 연결하여 파일을 저장하면, EC2 인스턴스와 관계없이 데이터를 영구적으로 보관 가능해요. 이 밖에도 AWS에서 제공하는 서비스는 매우 방대한대요. 아래 URL로 접속 시, 필요한 서비스 목록 확인이 가능하답니다! 🔍 더 많은 AWS 서비스가 궁금하다면? 온프레미스와 AWS의 차이 온프레미스 방식은, 클라우드 컴퓨팅 서비스가 나오기 전까지 기업에서 전통적으로 사용한 ‘일반적인 인프라 구축 방식’이에요. 온프레미스 환경에서 서버를 운영하면, 호스팅 서비스를 이용하거나 서버를 직접 구매 또는 임대하죠. 그다음 데이터 센터(IDC, Internet Data Center) 또는 기업 전산실에 설치하여 운영해요. 하지만 물리적인 서버를 직접 설치할 경우, 많은 시간과 비용이 소모되어 이를 위한 운영 공간과 인력이 필요할 수 있어요. 예시를 들어 볼게요. 대형 콘서트 예매, 대학교 수강신청, 입시 원서 접수 등 단기간에 트래픽이 급증했다가 감소되는 경우를 생각해 볼까요? 이때 ‘온프레미스 방식’으로 시스템을 구축한다면, 매우 많은 비용 낭비가 발생하게 될 거예요. 반면 AWS의 경우는 어떨까요? 인터넷이 연결된 어디에서든 쉽게 인프라를 구축하고, 사용한 만큼 비용을 지불할 수 있어요. 큰 이벤트를 처리한 후 생성된 리소스를 간편하게 삭제할 수 있죠. 이처럼 온프레미스 방식과 대비한다면, 남는 자원에 대한 비용 고민이 없어지겠죠? 하이브리드 클라우드 모니터링이 필요한 이유 이처럼 AWS는 매우 유연하고 확장성 있는 클라우드 서비스예요. 하지만 모든 서비스를 AWS를 이용해서 서비스하는 것은 한계가 있는데요. 이유는 다음과 같아요. ▪보안 및 규정 준수 민감한 데이터나 규정 준수가 필요한 업무의 경우, 사설 클라우드나 온프레미스 환경의 자체 데이터 센터를 통해 운영하려는 경향이 있어요. ▪비용 효율 AWS는 사용한 만큼 비용을 지불하기 때문에, 예측할 수 없는 트래픽 증가 등에 대응하기에 좋아요. 하지만 서비스에 따라 온프레미스 환경에서 운영하는 것이 비용 측면에서 더 효율적인 경우가 있죠. 이처럼 많은 기업이 AWS를 이용한 클라우드 서비스로 전환하는 추세지만, 당분간 온프레미스 방식과 결합한 하이브리드 클라우드 운영환경이 많은 편이에요. 그렇다면 이러한 하이브리드 클라우드 운영 환경을 모니터링할 수 있는 방법이 없을까요? 바로 ‘제니우스’를 활용한다면 가능해요! 제니우스를 이용한 하이브리드 클라우드 모니터링 구성도 제니우스 하이브리드 클라우드 모니터링 프로세스를 간략히 소개할게요! 우선 클라우드 환경 단계에서는 AWS 서비스를 이용하여 구축된 클라우드 환경 정보를 RestAPI 방식으로 수집해요. CMS Manager는 AWS 클라우드 환경에서 수집한 정보를 취합 후 스토리지에 저장해 주죠. EMS Manager는 온프레미스 환경에서 수집한 정보를 취합 후 스토리지에 저장해 줘요. Web UI에서는 스토리지에 저장된 데이터를 이용하여, 사용자에게 모니터링 정보를 제공한답니다! 제니우스에서 AWS 모니터링하기 제니우스를 이용한 ‘하이브리드 클라우드 모니터링 구성’을 좀 더 자세히 살펴볼까요? ▪CMS > 모니터링 > 요약 : 위 그림은 AWS 통합 요약 페이지인데요. EC2, RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있어요. ▪EMS > 토폴로지 > 클라우드 맵 : 리전 별 자동 구성형 클라우드 맵 페이지에서는, AWS 리전 별 이용하는 서비스와 연관관계를 클라우드 맵이 자동으로 구성해 줘요. ▪CMS > 클라우드서비스 > EC2 > 주요 성능 지표 : 주요 성능지표 모니터링 페이지에서는 AWS 콘솔에 접속하지 않고, AWS 주요 성능 지표에 대한 모니터링 추이를 확인할 수 있어요. ▪EMS > 오버뷰 : 오버뷰를 통한 온프레미스 + AWS 통합 모니터링 페이지에서는, AWS 모니터링 항목과 온프레미스 환경 모니터링 항목의 통합 현황판을 확인할 수 있어요. 이처럼 AWS와 온프레미스 환경은 물론, 더 다양한 환경의 인프라 모니터링을 위해 제니우스를 사용을 해보는 건 어떨까요? 2023.11.16
회사이야기 브레인즈컴퍼니 ‘2023 소프트웨어대전’ 참가 회사이야기 브레인즈컴퍼니 ‘2023 소프트웨어대전’ 참가 브레인즈컴퍼니가 「2023 대한민국 소프트웨어대전」에 참가하여 IT 인프라 통합관리의 새로운 비전을 제시할 예정이에요. 자세한 내용은 다음과 같아요! 2023 대한민국 소프트웨어대전은요 2023 대한민국 소프트웨어대전은 2016년에 첫 개최된 대표적인 소프트웨어 ICT 비즈니스 박람회인데요. 올해는 총 330개사가 패키지SW·IT서비스·융합SW·인터넷SW·게임콘텐츠SW의 큰 분류에 맞춰 참가할 예정이에요(*총 570개 부스 규모) [2023 대한민국 소프트웨어대전] ▪일시: 2023년 11월 29일(수) ~ 12월 1일(금), 10:00~17:00 ▪장소: 삼성동 코엑스 A홀(*브레인즈컴퍼니 부스 C32번) ▪후원: 과학기술정보통신부, 교육부, 행정안전부, 산업통상자원부, 중소벤처기업부, 서울특별시 ▪홈페이지: 바로가기 --------------------------------------------------------------- 2023 소프트웨어대전에서 브레인즈컴퍼니는요 브레인즈컴퍼니는 이번 2023 소프트웨어대전에서 “AI, 클라우드 네이티브의 창을 열다. 디지털 플랫폼을 위한 Brainz Group”이라는 슬로건으로, 자회사인 AI전문기업 '에이프리카'와 함께 참가해요. 온프레미스, 클라우드 그 어떤 IT 환경도 완벽하게 통합관리할 수 있는 ‘제니우스(Zenius)’ 또한 선보일 예정인데요. 제니우스의 핵심 제품인 EMS·APM·ITSM·SIEM의 세부적인 특장점을 다양한 콘텐츠를 통해 직접 경험하실 수 있어요! [Brainz Group Tech Talk 2023] ▪장소: 삼성동 코엑스 A홀(*브레인즈컴퍼니 부스 C32번) ▪주제(세부내용 변동 가능) > 클라우드 네이티브 정보시스템 구축 방안 > Private LLM 모델 구축 방안 > 클라우드 네이티브 애플리케이션 구축 방안 > 성공적인 IT 인프라 모니터링 방안 --------------------------------------------------------------- 에이프리카와 함께 성공적인 AI&Cloud, 디지털 전환을 위한 'Brainz Group Tech Talk 2023' 세미나 또한 진행할 예정이에요. 2023 소프트웨어대전 참관 방법은 아래와 같아요. 2023 소프트웨어대전 참관 방법 하단 링크를 통해 [사전등록] 하시면 ‘무료’로 참관하실 수 있어요. 2023 소프트웨어대전 브레인즈컴퍼니 x 에이프리카 부스에 방문하셔서 IT 기술의 현재와 미래를 만나 보세요🙌 📌2023소프트웨어대전 무료로 참가하기 2023.11.15
회사이야기 2023년 하반기 ‘고객사 및 파트너사’ 상생 세미나 회사이야기 2023년 하반기 ‘고객사 및 파트너사’ 상생 세미나 지난 10월 25일, 브레인즈컴퍼니 본사에서 「2023 하반기 ‘고객사 및 파트너사’ 상생 세미나」를 진행했어요! 브레인즈컴퍼니는 매 반기마다 고객사 및 파트너사 분들을 대상으로 상생 세미나를 진행하고 있는데요. 저희 브레인즈컴퍼니의 제니우스 EMS를 더욱 친숙하게 사용하는 것을 돕기 위해 기획되었어요. 이번 2023 하반기 상생 세미나에서는 우진·서울바이오허브·에스이랩·마이티시스템 등 산업용 장비를 만드는 제조기업부터, 바이오산업을 투자해 주는 공공기관까지! 다양한 산업 군의 고객사분들이 적극 관심을 보여주셨는데요. 교육 내용은 제니우스 EMS 패키지 설치, 모니터링 View를 구성하는 단계, 실무적인 모니터링에 초점을 맞춰 실시했답니다. 그럼 바로 2023 하반기 상생 세미나 후기를 들려드릴게요! Zenius SMS와 Zenius NMSㅣ김선효(TC팀) ‘제니우스 SMS(서버 모니터링 솔루션)’와 ‘제니우스 NMS(네트워크 모니터링 솔루션)’부터 교육을 시작했는데요. 우선 전반적인 성능 정보 수집 방식과 설치 방식을 배웠어요. 그다음, 화면을 통해 이벤트 분석하는 방법까지 세세한 교육이 이루어졌답니다. Zenius Overviewㅣ김기현(TC팀) ‘제니우스 EMS 오버뷰’는, 고객의 니즈와 운영 환경에 최적화된 서비스 관제 환경을 구현해 드리고 있어요. 웹과 CS방식의 토폴로지 맵을 통해 관제하는 IT 인프라들 간의 상호 관계도 표현 또한 가능하죠. 이 밖에도 IT 인프라와 네트워크 연결 관계에 대한 컴포넌트 지원, 사용자 니즈에 최적화된 연결 관계도 기반의 View를 제공해 드린답니다. 마무리하며 이번 2023 ‘고객사 및 파트너사’ 상생 세미나를 통해, 핵심적인 IT 인프라인 서버와 네트워크 모니터링 방안을 소개해 드렸는데요. 고객사 및 파트너 사분들께 교육을 진행하며, 브레인즈컴퍼니 또한 ‘IT 인프라 모니터링’ 인사이트를 넓힐 수 있었어요. 오는 11월 29일부터 12월 1일까지 「소프트웨이브 2023」가 진행되는데요. 클라우드 네이티브, 쿠버네티스, MSA 등! 급변하고 있는 IT 인프라 환경 변화를 브레인즈컴퍼니는 어떻게 준비하고 있는지 함께 이야기할 수 있는 자리를 마련했어요. 여러분들의 많은 관심과 참여 부탁드릴게요. 다시 한번 참여해 주신 모든 분께 감사 인사를 드려요! 앞으로도 IT 모니터링의 최전선에서 함께 고민하고, 최적의 관제 환경을 제공하는 브레인즈컴퍼니가 될게요🙇‍♀️ 2023.11.10
기술이야기 메모리 누수 위험있는 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
기술이야기 카프카를 통한 로그 관리 방법 기술이야기 카프카를 통한 로그 관리 방법 안녕하세요! 저는 개발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
회사이야기 'Zenius-SIEM v2.0' GS인증 1등급 획득 회사이야기 'Zenius-SIEM v2.0' GS인증 1등급 획득 브레인즈컴퍼니는 지난 8월 22일 한국정보통신기술협회(TTA)로부터 Zenius-SIEM v2.0에 대한 GS인증 1등급을 획득했습니다. GS인증은 Good Software의 약자로 양질의 품질을 갖춘 SW 제품에 국가가 부여하는 인증 제도 입니다. ISO 국제표준을 기반으로 기능 적합성, 성능 효율성, 보안성 등 여러 테스트를 거쳐 결과가 우수한 제품에 인증이 부여됩니다. GS인증을 받은 제품은 공공기관 우선 구매 대상으로 지정할 수 있습니다. 이번에 GS인증 1등급을 받은 Zenius-SIEM v2.0은 다양한 대용량 로그의 수집, 분석 및 통합 관리 시스템으로, 컴플라이언스(Compliance)를 준수하고 보안 위협에 대한 감시 · 대응 체계를 수립할 수 있는 통합로그 관리 시스템입니다. CC인증에 이어 GS인증 1등급을 획득한 Zenius-SIEM v2.0은 제품의 보안성이 강화되고 안정성을 검증받아 제주특별자치도청과 한국금형산업진흥회에 구축을 완료하였습니다. Zenius-SIEM v2.0은 SaaS(Software as a Service) 형태의 서비스를 제공하기 위해 개발 중에 있으며, On-Premise와 클라우드 환경에서 더 많은 고객들이 안정적으로 대용량 로그를 관리하고 보안 환경을 유지하도록 지원할 예정입니다. 2023.08.30
회사이야기 [브레인즈 소식] 브레인즈컴퍼니, ‘REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법’ 특허 취득 회사이야기 [브레인즈 소식] 브레인즈컴퍼니, ‘REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법’ 특허 취득 지난 6월에는 브레인즈컴퍼니가 '원격 서비스 응답 블로킹 대기 상태의 트랜잭션 제어 시스템 및 방법' 특허를 획득한 사실을 알려드렸습니다. 이번 7월 31일 'REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법' 특허도 취득했어요. 이번에 출원한 특허의 핵심은 AWS나 GCP와 같은 클라우드 서비스를 활용하는 개발 과정에서 가상 REST API 서비스를 자동으로 생성하는 소스 자동 제너레이션 기술입니다. 클라우드 환경을 이용한 개발 과정에서는 주로 REST API(Application Program Interface)를 주로 사용하는데, 이는 웹의 컴퓨터 시스템 간에 표준을 제공하여 시스템이 서로 쉽게 통신할 수 있도록 하는 아키텍처의 하나로, 현재는 공기업 및 사기업의 대부분이 API 서비스를 제공하고 있어, 웹 서비스의 표준 기술로 자리 잡고 있습니다. 클라이언트 개발자들은 개발 단계에서 REST API 서비스를 통해 데이터를 수시로 요청하고 테스트하는 과정을 필수적으로 거치게 되는데, 이 과정에서 서버 개발자들은 각 API에 대한 소스 파일을 일일이 작성하고 추가하는 등의 업무가 가중되고 있습니다. 브레인즈컴퍼니는 이러한 과정에서 특허 기술인 소스 자동 생성 기능을 적용하여, 개발 환경을 개선시키는 데 중점을 두었습니다. 소스 코드의 작성·빌드·배포 과정에서 반복되는 단순 작업들을 절감시키고, API를 이용하는 데 소요되는 비용을 최소화하여 결과적으로는 개발 경쟁력을 확보할 수 있기 때문입니다. 이번에 취득한 특허 기술은 클라우드 서비스 모니터링 시스템인 Zenius-CMS 개발 과정에서 이미 적용되어 성공적으로 검증되었습니다. 이번 특허 기술을 통해 클라우드 환경에서의 개발 속도를 높일 수 있었고, 브레인즈 개발자들은 더욱 효율적이게 업무에 몰두할 수 있는 환경이 마련된 상태입니다. 또한, 향후 REST API를 활용하는 프로젝트가 있을 때에도 신속하고 쉽게 개발이 이루어지고 효율적인 개발과 비용 부담 없는 테스트 과정을 거쳐 기능의 안정성을 확보할 것으로 전망하고 있습니다. 그리고 궁극적으로는 신규 기능을 빠르고 안정적으로 배포하여 고객 만족도가 향상될 것으로 기대하고 있습니다. 2023.08.28
기술이야기 시련이 많았던 경험자의 CI/CD 간략 소개 기술이야기 시련이 많았던 경험자의 CI/CD 간략 소개 과거에는 근로자 1명이 기획/설계/구현 테스트까지 진행이 가능했다고 합니다. 하지만 최근에는 근로자 1명이 기획부터 테스트까지 진행하는 일은 거의 드물다고 볼 수 있습니다. OLD SCHOOL 지금 이 시간에도 많은 회사 내의 개발자들은 자신에게 주어진 기능 구현을 훌륭하게 완수하기 위해서 모니터를 째려보고 있습니다. 모니터를 째려보다가 자신이 작성한 내용을 다른 팀원에게 공유하고자 혹은 반대로 다른 팀원이 작성한 내용을 공유받고자 '형상 관리 시스템'을 사용하고 있습니다. CVS와 SVN으로 대표되는 이 시스템은 최근들어 Git을 많이 사용하는 추세라고 합니다. 필자 역시 여러 프로젝트에서 해당 시스템을 사용도 해보았고, 연동하여 다른 시스템을 구현한 경험이 있습니다. 하지만 프로젝트 마다 해당 시스템 사용에 있어서 몇몇 시련이 있었습니다. "차주에 전체 기능 리뷰가 있습니다. 각 파트 별로 코드 커밋해주세요." 라고 PM(Project Manager) 또는 PL(Project Leader)이 요청을 하면, 각 하위 PL(Part Leader)은 파트(Part)에 돌아가 파트원들에게 이 내용을 공유하고, 개별 개발자들은 자신이 작성한 코드를 관리 시스템에 커밋하게 됩니다. 잠시 후 형상 관리 시스템에서 작성 코드를 내려 받은 PL(Part Leader)은 아래와 같은 상황에 직면하게 됩니다. - 동료의 작성 코드에는 관심 없이, 본인의 작성물만 커밋하는 경우 - 별도의 공지 없이 이미 작성된 파일 등을 삭제하여 커밋하는 경우 - 약속되지 않은 환경이나 lib으로 작성한 코드를 커밋하는 경우 프로젝트에 따라 기간이 길어지거나 다른 여러 상황이 발생하면 위의 문제보다 더 많은 문제를 경험하게 됩니다. 각 파트 단위로 위와 같은 문제가 해결되고 정상적으로 컴파일, 빌드까지 완료되면, PL(Part Leader)들은 파트별로 단위테스트를 완료하고 결과가 정상적이면 결과를 품질관리자에게 통보합니다. 각 파트별로 완료 통보를 받은 품질관리자는 다시 관리 시스템에서 전체 작성물을 수동으로 내려받아 통합테스트를 진행합니다. 통합테스트까지 완료되었다면 해당 내용을 릴리즈관리자에게 통보합니다. 릴리즈관리자는 바뀐 부분만 찾아서 변경하면 시간적으로 적용이 빠르겠지만 '바뀐 부분만 변경하면 될까?'라는 의심으로 전체 작성물을 수작업으로 전처리(컴파일 & 빌드)하고 다시 수작업으로 릴리즈하게 됩니다. 만약 진행상의 이슈가 없다면 이제 기능 리뷰 준비가 완료됩니다. 단계별로 문제 없이 진행되고 모든 기능을 확인하였다고 하지만 기능 리뷰 혹은 데모만하면 꼭! 오류가 발생하여 난처한 상황이 종종 발생하곤 합니다. 필자 역시 이런 경우가 많았으며 그때마다 문제 부분을 찾기 위해 많이 고생했습니다. 아래의 개념은 아마도 저 같은 경험을 하고 있는 많은 사람들을 위한 것이 아닌가 싶습니다. CI (Continuous Integration, 지속적인 통합) '지속적인 통합'이란 개발 과정에서 생산되는 코드의 관리와 코드의 문법적인 오류 확인 및 기능 점검(=테스트)을 특정한 일정에 진행하는 것이 아니라 날마다 혹은 특정 시간마다 진행하여 코드 및 기능에 대한 품질을 유지하는 개념이라고 말할 수 있을 것입니다. 앞에서 언급했던 과거 모습을 개선하는 노력은 CI 라는 개념이 나오기 이전부터 많은 개발사 혹은 팀에서 그들만의 문화나 관습으로 처리하는 경우가 있었을 것입니다. 하지만 문제는 새로운 구성원이 생겼을 때 입니다. 조직 문화를 새로이 접하는 이들에게는 이를 설명하고 이해시키는 일은 시간과 노력이 드는 일이니까요. 하지만 이젠 일반적인 Java 개발팀에서는 SVN(or GitHub)+Jenkins+Maven+JUnit으로 구성하는 개발 환경을 사용하고 있습니다. 다만, 프로젝트 목표나 목적되는 환경에 따라 약간씩 다른 환경을 구성하기도 합니다. 그러나 대부분의 경우 Open Source 기반으로 CI 개념을 구성하는 경우가 많습니다. 이는 일단 무료라는 큰 장점과 많은 레퍼런스가 있어 구성하기 편리하고 "우린 Open Source인 SVN과 Jenkins를 사용합니다. 일단 자세한 개념과 동작 원리는 너트뷰 선생님께..." 라고 하며 짧은 노력으로 교육을 끝낼 수 있어 그런 것이 아닌가 합니다. CI 개념을 활용하는 개발 프로젝트에서는 UI 메뉴 혹은 구현 단위 기준으로 구분하여 개발파트나 개발자를 할당하고는 합니다. 각각의 개발자는 할당받은 구현 범위에 대한 문제를 개별적으로 개발 도구를 활용하여 구현하고 구현 내용을 형상 관리 시스템에 커밋합니다. 이런 과정을 다른 개발자들도 같이 수행한 후에 빌드 자동화 환경에서 컴파일 및 빌드 스크립트에 맞춰서 문법적으로 확인된 결과물을 만들고 이를 다시 기능이 확인이 가능한 테스트 스크립트에 맞춰서 테스까지 진행합니다. 만약 테스트 과정에서 비정상적인 결과가 발생할 경우, 해당 내용 수정 후 위의 작업을 다시 진행하게 됩니다. 이런 일련의 절차는 일정 시간 준위 단위로 수행되어 구현하고 있는 기능을 주기적으로 확인하는 과정을 수행합니다. 올바른 진행을 위하여 개발자 개개인에게 분장되는 업무의 크기가 비슷해야 한다고 생각됩니다. 개발자별로 업무의 크기가 서로 다른 겨우, 결과물이 정상적이라고 볼 수 없게 될 것이고 그렇게 된다면 테스트 결과 역시 믿을 수 없는 경우가 발생할 것입니다. CD (Continuous Delivery/Deploy, 지속적 제공/배포) 지속적인 통합(CI)을 사용하던, 기존의 개발 환경을 사용하던, 결국 작성된 결과물은 최종적으로 운영환경에 적용되어 사용작 혹은 타 시스템과 연결되어야 합니다. 그래야 제품 개발 또는 프로젝트가 완료됩니다. CD는 결과물을 운영환경에 적용하는 방식을 나타내는 환경으로써 결과물 적용 여부를 판단하는 행위를 담당하는 주체가 누구냐에 따라, Continuous Delivery와 Continuous Deploy로 구분됩니다. Continuous Delivery는 CI 환경을 통하여 자동으로 컴파일 및 빌드가 되고, 테스트된 결과물에 대해서 릴리즈 관리자가 적용 시점마다 테스트 결과 및 서비스 영향도를 판단하여 수동으로 적용하는 방식이며, Continuous Deploy는 결과물은 항상 옳고 서비스 영향도는 없다고 미리 판단하여 자동으로 적용하는 방식입니다. 아마도 대부분의 개발 환경에서는 Continuous Delivery로 적용하고 있기에 CD라고 표기되는 경우 Continuous Delivery를 의미하는 경우가 많을 것입니다. 소프트웨어 솔루션을 제작하는 개발팀에서는 아마도 Continuous Delivery로 또한 MSA 기반의 서비스를 제공하는 개발팀에서는 Continuous Deploy를 사용하는 편이 여러 관계를 보았을 때 유리하다고 판단합니다. 하지만, 개발팀의 업무 성격과 제품 혹은 서비스의 출시 시기 등이 CD 방식을 결정하는 가장 중요한 요소가 될 것입니다. 지금까지 CI/CD 도입 배경과 내용을 필자의 경험을 바탕으로 간략하게 정리하였습니다. 개발자들이 자기가 맡은 기능 혹은 프로세스에만 전념할 수 있는 훌륭하고 편리한 개발 환경 및 적용 환경이 언제 어떻게 나타나게 될지 궁금합니다. 가능하다면, 많이 바꿔서 따라가기 귀찮은 시니어들과 새롭게 따라가야하는 주니어 개발자 모두에게 즐거운 환경이 등장했으면 합니다. 감사합니다. 2023.08.22

1 2 3 4 5 6