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

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

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

블로그

최신이야기

기술이야기 클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치 기술이야기 클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치 최근 디지털 트랜스포매이션(Digital Transformation)이 IT 트렌드로 자리 잡았습니다. 기업과 조직은 빠르게 변화하는 환경에 대응하고 경쟁에서 앞서기 위해 '클라우드 네이티브 컴퓨팅' 기술을 채택하고 있는데요. 여기서 클라우드 네이티브 컴퓨팅 기술을 연구 및 발전시키고, 생태계를 촉진하는데 중추적인 역할을 하는 커뮤니티가 바로 'CNCF(Cloud Native Computing Foundation)'입니다. 현재 CNCF에서는 Google, Intel, Azure 등 700여 곳 이상의 회원사들이 활동에 참가하고 있습니다. 이번 시간에는 CNCF가 정확히 무엇이고, 추구하는 핵심가치와 주요 프로젝트에 대해 자세히 알아보겠습니다. 。。。。。。。。。。。。 CNCF(Cloud Native Computing Foundation)란 CNCF는 2015년 12월에 리눅스 재단에 의해서 출범된 비영리 단체로, 네이티브 컴퓨팅 기술의 채택을 촉진하는 오픈소스 소프트웨어 재단입니다. CNCF는 클라우드 네이티브 컴퓨팅 플랫폼에서 사용하며, 확장 가능한 애플리케이션을 개발하는데요. 이와 관련된 기술인 컨테이너, 마이크로서비스, 서비스 메쉬 등의 발전을 촉진하여 이러한 기술 패턴을 누구나 이해하고 활용할 수 있도록 하는 것이 목표입니다. ▲총 24개의 CNCF Platinum Members 이러한 클라우드 네이티브 컴퓨팅 환경을 대중화하기 위해 Google Cloud, AWS, MS Azure, Cisco, IBM, Apple, Oracle, Red Hat, VMware, SAP 등 유수의 기업들이 플래티넘 회원사로 참여하여 뜻을 같이 하고 있습니다. CNCF의 세 가지 핵심 가치 CNCF의 핵심가치는 1) 클라우드 네이티브 기술의 촉진 2) 오픈소스 프로젝트 생태계 육성 3) 기술의 표준화 수립으로 정리할 수 있습니다. 이 세 가지 핵심 가치를 더 자세하게 살펴볼까요? CNCF 핵심가치1 : 클라우드 네이티브 기술의 촉진 CNCF는 현대적이고 미래 지향적인 '클라우드 네이티브 기술의 촉진'을 중요한 핵심 가치로 규정하고 있는데요. 이는 CNCF가 오늘날의 IT 생태계의 중심에 서서, 클라우드 네이티브 기술을 지속적으로 연구 및 개발하여 새로운 디지털 전환의 시대를 선도하고자 하는 의지가 담겨 있다고 볼 수 있습니다. CNCF는 기존 온 프레미스(On-Premise) 환경, 그리고 모놀리식(Monolithic)한 개발 환경에서 탈피한 컨테이너, 마이크로서비스, 서비스 메시, 서버리스 등. 보다 혁신적이고 미래지향적인 기술 영역을 보급하고 대중화하기 위한 노력과 지원을 아끼지 않습니다. ▲기존 모놀리식 아키텍처와 마이크로서비스 아키텍처 비교 또한 디지털 트랜스포메이션 과정에서 클라우드 환경으로의 전환이 더욱 효율적으로 이루어질 수 있도록, 클라우드 네이티브 기술과 기업들의 서비스 모델을 재구성하기 위한 방법들을 안내하고 있습니다. 이렇게 새로운 서비스 모델 구축을 통해 민첩성과 효율성을 강화하여, 빠르게 변화하는 IT서비스의 수요에 기민하게 대응하고 고객 요구에 부응할 수 있도록 지원합니다. 여기서 계속 언급되고 있는 '클라우드 네이티브'는 정확히 무엇을 뜻할까요? CNCF의 활동에 대한 이해도를 높이기 위해, 클라우드 네이티브의 의미를 짚어보겠습니다! ?클라우드 네이티브(Cloud Native)란? 클라우드 네이티브는, 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축·배포·관리할 때의 소프트웨어 접근 방식입니다. 기업과 조직은 고객의 요구를 충족하기 위해 신속하게 업데이트할 수 있는 확장성과 유연성, 그리고 복원력이 뛰어난 애플리케이션을 구축하고자 합니다. 이를 위해 클라우드 네이티브에서 사용되는 기술들은, IT 서비스에 영향을 미치지 않고 애플리케이션을 신속하게 변경합니다. 또한 리소스를 효율적으로 활용하여 빠르게 변화에 대응할 수 있도록 지원하고 있습니다. 위의 개념을 '클라우드 컴퓨팅'과 비교한다면 보다 더 쉽게 이해할 수 있는데요. 클라우드 컴퓨팅은, 클라우드 서비스 제공 업체가 단순히 리소스와 인프라를 클라우드 형태로 제공하는 방식입니다. 여기서 서비스 제공 방식은 기존 '모놀리식' 방식과 크게 다르지 않습니다. ▲클라우드 네이티브의 핵심요소 ⓒPivotal 클라우드 네이티브는 마이크로서비스 아키텍처(MSA)와 컨테이너를 기반으로, IT 서비스의 확장·변경 등에 대응이 용이한 환경입니다. 예를 들어 Ex1) 서비스 수요가 폭증하거나 장애가 생겼을 경우 Ex2) 자동적으로 애플리케이션을 확장하거나 장애가 발생했을 경우에는 대체 가능한 모델을 바로 적용하여 Fail-Over가 손쉽게 이루어질 수 있도록 합니다. CNCF에서는 위 그림과 같이 클라우드 네이티브의 핵심 요소를 마이크로서비스, 컨테이너, 애플리케이션의 개발·통합·배포의 의미를 내포하는 DevOps, CI/CD의 개발 방법론을 포함하여 설명하고 있습니다. CNCF 핵심가치2 : 오픈소스 프로젝트 생태계 육성 CNCF는 다양하고 혁신적인 '오픈소스 프로젝트'를 개발·공급·대중화하여, 클라우드 네이티브 생태계를 활성화하는데 큰 기여를 하고 있습니다. 또한 클라우드 네이티브 컴퓨팅 환경을 구성하고 효율적으로 운영하기 위해, 다양한 오픈소스를 개발하고 있는데요. 누구나 이와 같은 기술들을 이용할 수 있도록 지원합니다. 가장 성공적인 프로젝트는 2018년 8월에 컨테이너 오케스레이션 플랫폼인 'Kubernetes' 프로젝트이며, 컨테이너 생성·실행·종료 등의 역할을 하는 'Containerd', 시스템 모니터링 및 경고 역할을 하는 'Prometheus' 그리고 여러 시스템의 트래픽을 균등하게 분배하여 로드밸런싱을 제공하는 'Envoy' 등이 있습니다. 이처럼 클라우드 네이티브 생태계 활성화를 위한 다양한 프로젝트를 실행하며 배포하고 있습니다. ▲CNCF 개발 완료된 프로젝트 이외에도 클라우드 네이티브 커뮤니티인 이벤트·웨비나·워크샵 등을 활성화하여, 온오프라인 영역에서 개발자들 간의 교류를 원활하게 합니다. 개발자들이 오픈소스 프로젝트를 효과적으로 활용할 수 있도록, 사용법에 대한 교육과 튜토리얼을 제공하기도 합니다. 이를 통해 많은 기업과 이용자들이 클라우드 네이티브 환경에 손쉽게 접근할 수 있도록 지원하고 있습니다. CNCF 핵심가치3 : 기술의 표준화 수립 CNCF는 클라우드 네이티브 관련 기술의 무분별한 확장과 사용으로 인한 혼란을 방지하고자, 기술의 표준화를 촉진하고 정책의 일관성을 확보하는 노력 또한 지속하고 있는데요. 기술의 안정성과 품질 확보를 위해 재단 자체적으로 테스트와 벤치마킹 등을 수행하고, Best Practice를 공유하여, 기술의 표준화와 성숙도를 유지합니다. 이 외에도 CNCF는 새로운 기술의 적용 가능성과 성숙도를 평가하고, 클라우드 관련 기술을 보유한 회원사 및 파트너와의 협력을 촉진합니다. 이처럼 다양한 형태로 클라우드 네이티브 생태계의 지속적인 발전을 지원하고 있습니다. 。。。。。。。。。。。。 이번 시간에는 CNCF의 정의와 핵심가치를 알아보았는데요. CNCF는 앞에서 소개해 드린 내용처럼, 클라우드 네이티브 생태계 활성화를 위해 다양한 노력을 기울이고 있습니다. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능들을 속속 출시하고 있으니, 많은 관심 부탁드립니다. 다음 시간에는 [CNCF의 핵심 프로젝트] 주제로 돌아오겠습니다! 2023.12.27
기술이야기 클라우드(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년 하반기 ‘고객사 및 파트너사’ 상생 세미나 지난 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
기술이야기 카프카를 통한 로그 관리 방법 기술이야기 카프카를 통한 로그 관리 방법 안녕하세요! 저는 개발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
기술이야기 [브레인저가 알려주는 IT#1] 네트워크 관리, SNMP가 뭔가요? 기술이야기 [브레인저가 알려주는 IT#1] 네트워크 관리, SNMP가 뭔가요? 1. SNMP(Simple Network Management Protocol)란? 컴퓨터 네트워크 장치를 관리하고 모니터링하기 위해 사용되는 네트워크 관리 프로토콜이에요. 네트워크 장치, 서버, 라우터, 스위치, 프린터 등과 같은 네트워크 장치들의 상태를 모니터링하고 구성할 수 있는 표준 방법 또한 제공하고 있어요. 요약한다면 네트워크에 있는 장비들을 관리하기 위한 프로토콜이라고 이해하시면 된답니다! (1) SNMP의 역사 • SNMPv1(1988)초기 SNMP 버전으로 RFC 1067에 정의되었어요. 간단한 모니터링과 설정 변경 기능을 제공했으나, 보안 측면에서 취약점이 있었어요. 커뮤니티 문자열(Community String)을 사용하여 인증을 수행했어요. • SNMPv2(1993) SNMPv1의 한계와 보안 이슈를 개선하기 위해 개발되었어요. 여러 개의 추가 기능을 제공하려 했으나, 규격이 복잡해졌고 보안 문제로 인해 널리 채택되지 않았어요. • SNMPv2c(1996) SNMPv2의 복잡성을 줄이고 보안을 개선한 버전이에요. 커뮤니티 문자열을 계속 사용하여 보안적인 취약성은 여전히 존재했어요. • SNMPv3(1998) 현재까지 널리 사용되고 있는 최신 버전이에요. 보안 기능을 크게 강화하여 데이터 암호화, 사용자 인증, 데이터 무결성 검사 등을 제공하고 있어요. 비동기적인 알림 메커니즘으로 Trap 메시지와 함께 메시지의 암호화 및 보안 기능을 지원해요. • SNMPv3의 보안 개선(2002 이후~) SNMPv3에서 시작된 보안 향상이 계속 발전되어 왔어요. 데이터 암호화와 사용자 인증 등의 기능이 더욱 강화되고, 다양한 보안 솔루션과 표준이 제안되었어요. 2. SNMP의 주요 특징과 역할 (1) 클라이언트-서버 모델 SNMP는 관리자의 명령을 수행하는 에이전트와, 에이전트의 정보를 수집하는 매니저 간의 통신을 기반으로 해요. (2) MIB(Management Information Base) 네트워크 장치의 정보를 계층 구조로 정의한 데이터베이스입니다. 각 정보 항목은 OID(Object Identifier)로 식별되며, 매니저는 OID를 통해 특정 정보를 요청하고 수집할 수 있어요. (3) 동작 방식 • GET: 매니저가 에이전트에게 특정 정보의 값을 요청해요. • SET: 매니저가 에이전트에게 특정 정보의 값을 변경하도록 요청합니다. • TRAP: 에이전트가 이벤트 발생 시 매니저에게 알림을 보내요. (4) 보안 • SNMPv1: 초기 버전으로, 보안에 취약한 프로토콜이었어요. • SNMPv2c: SNMPv1을 확장한 버전으로, 여전히 보안에 취약했어요. • SNMPv3: 보안 강화 버전으로 데이터 암호화, 사용자 인증, 데이터 무결성 검사 등을 지원하여 보안을 강화했어요. (5) 확장 가능성 SNMP는 다양한 버전과 확장 프로토콜을 지원하여 새로운 기능을 추가하거나 보완할 수 있어요. (6) 주요 용도 • 네트워크 장치 모니터링: 장비의 성능, 상태, 트래픽 등 정보를 수집하여 네트워크를 모니터링해요. • 구성 관리: 장치의 설정 변경 및 관리를 원격으로 수행할 수 있어요. • 이벤트 알림: 장애나 이상 상태가 발생하면 즉시 알림을 받을 수 있어요. 이처럼 SNMP는 네트워크 관리에 필수적인 프로토콜 중 하나로, 네트워크의 안정성과 성능을 유지하며 문제를 신속하게 해결하는 데 도움을 준답니다! 3. Zenius에서의 SNMP 활용 안내 (1) NMS 모니터링 SNMP GET 방식으로 데이터를 수집할 수 있어요. SNMP를 활용하여 장비모니터링 화면, 등록된 장비의 장비명, IP, 성능데이터 등을 확인 할 수 있어요. 장비의 상세한 데이터를 모니터링 할 수 있어요. IF 포트의 UP/DOWN과 트래픽 데이터를 수집하여 확인 가능해요. • NMS in/out bps 전일 대비 In/Out bps의 데이터 확인 및 추이 분석기능도 제공하고 있어요. 사진과 같이 초 단위 실시간 데이터를 통한 상세 트랙픽 분석도 가능하답니다! 성능 데이터를 수집하여 그래프 형태로 보관하고 제공하고 있어요. 수집 시간대별 데이터도 제공해요. 해당 데이터를 통하여, 트래픽사용량이 많이 발생한 시간을 찾을수 있어요. • 장비등록 화면 SNMP 모든 버전에 대해서 모니터링을 제공하고 있어요. 장비 설정에 따라서, 버전 및 정보 입력하여 등록하여 모니터링 할 수 있어요. (2) TRAP 모니터링 • 네트워크 장비와 시스템에서 발생하는 이벤트나 상태 변화를 실시간으로 알려주기 위한 SNMP의 비동기적인 메시지에요. 이벤트 발생 시, 장치가 주도적으로 SNMP 매니저에게 알림을 보내는 방식으로 작동해요. Trap은 장애 상황이나 경고 상태 등에 대한 신속한 대응을 가능하게 해요. • Trap은 네트워크 관리자에게 실시간 정보를 제공해요. 장비나 시스템의 이상 상태를 빠르게 감지하고 대응하여, 서비스의 가용성과 신뢰성을 유지하는 데 중요한 역할을 하고 있죠. • Trap의 활용✅ 장애 관리: 장비나 시스템의 고장이나 다운 상태 등의 이벤트가 발생하면 즉시 Trap이 생성되어 매니저에게 알려줘요.✅ 경고 및 알림: 주의가 필요한 상황에서도 Trap을 활용하여 관리자에게 알림을 제공해요.✅ 보안 이벤트: 불법 로그인 시도나 보안 위반 등의 이벤트가 발생하면, 해당 정보를 Trap으로 매니저에게 전송하여 보안 조치를 취할 수 있어요. Trap 발생시, 모니터링 화면을 통해서 내용을 확인 할 수 있어요. Trap 받은 내역을 저장하여, 기간 검색 등을 통하여 활용할 수 있어요. 이제 Zenius를 활용하여 네트워크 장비를 모니터링 해보는 것은 어떨까요? 2023.09.05
회사이야기 [브레인즈 소식] 브레인즈컴퍼니, ‘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
기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 평온한 오후 퇴근 준비가 한창인데 불길한 전화가 걸려 옵니다. “서비스가 먹통이어서 확인 좀 해야 하는데 서버가 엄청 버벅거리고 반응이 느려요!! 이거 왜 이러죠??” 왜!! 도대체 왜!! 한 번쯤은 겪어보았을 급작스러운 Linux 서버의 상태 이슈! 불행하게도 무척이나 다양한 원인으로 인해 발생하게 됩니다. 우리의 목표는 이 다양한 원인 중 실제 발생 원인을 빠르게 특정하는 것! 기본적인 항목들의 체크리스트를 통해 빠르게 원인을 파악 해 봅시다. Linux 서버 상태 이슈 체크리스트 1. 서버의 CPU 부하 확인하기 2. BUFFER, CACHE, SWAP 상태 확인하기 3. 디스크 상태 확인하기 Zenius를 통한 데이터 추이 분석!! 장애의 발생은 순식간에 일어나지만, 장애 발생 시점의 데이터만을 확인해서는 원인을 파악하기가 쉽지 않은 경우가 많습니다. Zenius를 활용하여 앞서 정한 체크리스트를 빠르게 확인해 봅시다. 1. 서버의 CPU 부하 확인하기 - CPU 부하 확인의 Point는 Load Average Load Average는 CPU 사용 대기 중인 프로세스와 I/O 완료를 대기하고 있는 프로세스의 수를 의미합니다. 따라서, Load Average가 높다는 것은 CPU가 바쁘며 시스템에 걸리는 부하가 있다는 뜻입니다. 화면과 같이 1분, 5분, 15분의 로드 평균을 확인 해 보도록 합시다. 1분 로드 평균은 순간적으로 증가하는 경우가 있지만, 5분 15분 데이터상에도 이전과 비교하였을 때 높은 수치를 보인다면, CPU의 부하가 의심스러운 상황입니다. 그렇다면 CPU의 사용률과 I/O 대기율은 어떨까요? user가 사용한 CPU 사용률은 일정하지만, Iowait 수치가 올라간 것을 볼 수 있습니다. 이 경우 CPU의 리소스 부족이기보다는 I/O로 인한 부하로 판단할 수 있고, 자세히는 메모리나 프로세스의 현황 확인이 필요한 경우입니다. 반대로 user 수치가 높은 경우에는 물리적인 CPU 자체의 리소스 부족이라 볼 수 있습니다. 2. BUFFER, CACHE, SWAP 상태 확인하기 - 메모리 사용률과 Swap, Buffer, Cache 메모리 사용률이 높다 = 서버에 부하가 있다?? 답은 No !! Linux 서버의 메모리 사용률은 Buffer/Cache의 사용량이 포함되어 표현되게 됩니다. 따라서, 우리는 그 추이를 통하여 이슈를 확인하는 것이 중요합니다. 위의 검은 바탕의 그래프는 메모리 사용률이 높지만, 일정한 수치를 유지하고 있습니다. 이런 경우 서버의 메모리 사용은 안정적인 영역에서 이루어진다고 판단이 가능합니다. 그 이유는 실제 메모리 사용량과 Buffer/Cache에 할당량의 수치가 할당 가능한 수치 내에서 이루어지기 때문에 사용률이 유지된다고 볼 수 있기 때문입니다. 반면 흰 바탕의 그래프는 메모리 사용률이 점차 증가하며 결국 100%까지 도달한 것을 확인할 수 있는데요, 이경우에는 프로세스가 연산에 필요한 공간을 할당받지 못하여 프로세스 행이 발생하게 됩니다. 그렇다면 Buffer Cache Swap은 어떨까요? 먼저 Buffer Cache에 관해 확인 해 보도록 하겠습니다. *Buffer – 메타데이터를 메모리에 저장. *Cache – Page Cache, Slab을 메모리에 저장. 쉽게 말해, 둘 다 용도에 맞는 정보를 저장하여 수행 속도에 도움을 주는 영역입니다. 메모리 사용량이 늘어나면 이 Buffer, Cache 영역이 줄어들게 되고, 저장 영역이 줄어든다는 것은 속도가 떨어져 성능 저하로 이어지게 됩니다. 아래 그래프는 메모리 사용률이 올라가고 있는 상태의 서버 데이터입니다. 다음으로 이 시점의 Buffer, Cache의 영역을 확인해 보겠습니다. 추이 그래프를 통해 메모리 사용률이 올라갈수록 Buffer, Cache 영역이 줄어드는 것을 확인할 수 있습니다. 그렇다면 이 시점의 I/O는 어떨까요? 보시는 바와 같이 Iowait 수치가 급격히 올라갔음을 확인 할 수 있으므로, “메모리 사용률의 상승은 Buffer, Cache 영역을 줄어들게 하여 속도 저하를 발생시킨다.” 라는 결론을 도출할 수 있습니다. 또한, 메모리 사용률의 상승은 Swap에도 영향을 끼치게 됩니다. *Swap – 디스크 공간에 할당하여 메모리 역할로 사용하는 공간. 따라서, Swap 영역의 사용은 실제 메모리가 아닌 디스크를 사용하기 때문에 속도 저하가 발생 됩니다. 위 그래프는 Swap 사용률이 증가하고 있는 서버의 데이터입니다. 이 시점의 디스크의 상태를 보면 Read와 Write가 점차 Swap과 동일하게 상승하는 것을 볼 수 있습니다. 이렇게 메모리 대신 디스크 영역을 사용하면서 속도가 저하하게 되는 것입니다. 3. 디스크, 확인하기 - Mount Point 별 디스크 사용량, 작업량 추이 확인 디스크의 여유 공간이 없으면 시스템이 파일 생성을 못 하게 되고 결국엔 서버의 운영에 영향을 끼치게 됩니다. 각각의 마운트 지점의 사용률을 체크하여 여유 공간을 확보하는 것이 필요합니다. 디스크의 사용량이 급작스럽게 늘어난 경우는 신규 파일이 업로드되었다거나, 로그파일이 급작스럽게 많이 쌓이는 경우가 있습니다. 그렇기에 각 Mount Point의 사용률을 확인하고 해당 지점의 이슈 사항을 파악하는 것이 가장 좋습니다. 위 그래프와 같이 1시간 이내에 /data 지점의 사용률이 급등하였다면, 해당 지점에 쌓이는 데이터나 로그파일이 급격하게 증가한 것이므로 확인이 필요합니다. 다음으로는 디스크 사용 추이를 확인 해 보도록 하겠습니다. 서버에서 사용하는 물리 디스크는 각각의 성능의 한계가 있습니다. 이 한계를 직관적으로 확인할 수 있는 데이터로는 Disk Busy Rate(작업률)와 Disk Wait Rate(대기율)이 있는데요, Read 및 Write의 양이 한계치까지 치솟게 된다면 Busy Rate 값이 증가하게 되고, 이에 따른 Wait Rate 가 늘어나면서 서버의 성능 저하를 불러오게 됩니다. 어떻게 관리해야 할까? 앞서 확인한 서버의 상태 이슈들, 물론 급작스럽게 발생하는 경우는 어쩔 수 없지만 미리 대비가 가능한 것들은 Zenius-EMS를 이용하여 임계치 기반의 사전 모니터링과, 모니터링 페이지를 통한 직관적인 관리가 가능합니다. 각각의 항목들에 세부적으로 단계별 임계치를 걸어서 서버의 상태 이슈를 사전에 인지하고, 요약 페이지를 통해 빠르게 상태를 파악하여 우리의 퇴근 시간을 사수해 보는 건 어떨까요? 2023.08.08
기술이야기 서버 모니터링 데이터의 3가지 활용 방법 기술이야기 서버 모니터링 데이터의 3가지 활용 방법 서버는 기업의 핵심 시스템과 데이터를 보관하고, 애플리케이션과 서비스를 호스팅하며, 비즈니스에 필요한 작업을 수행합니다. 이러한 서버가 원활하게 작동하지 않거나 성능 이슈가 발생할 경우, 업무 중단, 데이터 손실, 고객 서비스 저하 등 심각한 문제가 발생할 수 있습니다. 따라서 서버의 안정적인 운영과 성능 관리는 비즈니스의 지속 가능성과 경쟁력에 직결되는 중요한 요소입니다. 서버 모니터링은 이러한 서버의 상태와 동작을 지속적으로 감시하고, 성능 및 이상 상황을 식별하는 프로세스입니다. 이를 통해 시스템 관리자나 운영팀은 잠재적인 문제를 사전에 감지하고 조치를 취할 수 있습니다. 서버 모니터링을 통해 수집하는 데이터는 다양합니다. CPU 사용률, 메모리 사용량, 디스크 공간, 응답 시간, 서비스 가용성, 로그데이터 등 다양한 데이터를 통해 서버의 상태와 동작을 감시합니다. 앞에 언급한 데이터들 외에도 네트워크 연결 상태, 서비스 상태, 프로세스 실행 상태 등 다양한 데이터를 모니터링할 수 있으며, 서버의 운영 환경과 요구사항에 따라 수집되는 데이터의 종류가 달라질 수 있습니다. 이렇게 수집한 데이터들은 어떻게 활용할 수 있을까요? 먼저 병목 현상 식별, 리소스 확장 등을 통해 성능 최적화를 하는 데에 활용될 수 있습니다. 관리자는 수집한 모니터링 데이터를 분석하여 병목 현상을 식별할 수 있습니다. CPU 사용률이 지나치게 높거나 메모리 사용량이 극단적으로 증가하는 경우에는 해당 자원에 대한 최적화가 필요하다는 사실을 인지할 수 있습니다. 또 데이터를 분석하여 서버 리소스의 부족을 파악하고, 필요한 경우 리소스를 확장할 수 있습니다. 예를 들어, CPU 부하가 높다면 CPU를 추가로 할당하거나, 메모리 부족이 발생하면 메모리 용량을 늘릴 수 있습니다. 리소스뿐만 아니라 프로세스의 동작 또한 최적화할 수 있습니다. 특정 프로세스가 많은 CPU 사용량을 차지하고 있다면 해당 프로세스를 최적화하여 자원 사용을 줄일 수 있습니다. 디스크 I/O의 경우 역시 성능을 분석하여 디스크 병목 현상을 확인할 수 있습니다. 그 후 필요에 따라 디스크 용량을 확장하거나 디스크 성능을 향상시킬 수 있습니다. 디스크 공간이 부족한 경우 쓰기 작업을 최적화하여 디스크 공간을 효율적으로 활용할 수 있습니다. 두 번째로 용량 계획에 참고할 수 있습니다. 예를 들어, 서버 모니터링 데이터를 사용하여 트래픽 패턴을 분석하고 예측할 수 있습니다. 특정 시간대에 트래픽이 증가하는 경향을 발견할 수 있다면 해당 시간대에 필요한 용량을 예측하여 서버 리소스를 적절히 조정할 수 있습니다. 이를 통해 예상되는 트래픽 증가에 대비하여 서버의 용량을 조정하고 성능을 유지할 수 있습니다. 또 서버 모니터링 데이터를 사용하여 서버의 성능 패턴을 분석할 수 있습니다. 예를 들어, 특정 시간대에 서버의 응답 시간이 급격히 증가하는 경향을 발견할 수 있다면 해당 시간대에 용량이 부족한 것으로 예상할 수 있습니다. 이를 기반으로 용량을 조정하거나 추가 리소스를 할당하여 성능을 최적화할 수 있습니다. 예비 용량 계획 역시 수립할 수 있습니다. 예를 들어, 서버의 CPU, 메모리, 디스크 사용량 등을 모니터링하고 기준치를 설정한 후, 해당 기준치에 도달하거나 근접할 때 추가 용량을 확보하는 계획을 세울 수 있습니다. 이를 통해 예상치 못한 용량 부족 상황을 방지하고 서버의 안정성과 성능을 유지할 수 있습니다. 마지막으로 장애 예측 및 대응에 활용할 수 있습니다. 서버 모니터링 데이터를 실시간으로 분석하여 이상 상황을 감지하고 경고를 발생시킬 수 있습니다. 예를 들어, CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등을 모니터링하고 미리 설정한 임계값을 초과하는 경우에는 이상 상황으로 판단하고 관리자에게 경고 알림을 보내도록 설정할 수 있습니다. 이를 통해 잠재적인 장애 상황을 사전에 인지하고 대응할 수 있습니다. 혹은 서버 모니터링 데이터를 사용하여 이전의 장애 패턴을 분석하고 예측할 수 있습니다. 예를 들어, 특정 작업이나 트래픽 패턴에 따라 일정한 주기로 장애가 발생했던 경우, 해당 패턴을 파악하여 동일한 상황에서 장애가 발생할 가능성을 예측할 수 있습니다. 이를 기반으로 예방적인 조치를 취하거나 대응 전략을 수립하여 장애를 예방하거나 대응할 수 있습니다. 로그 분석을 통해 서버 모니터링 데이터와 로그 파일을 연계하여 장애 분석 및 대응이 가능합니다. 로그 파일에는 서버 동작 상태, 오류 메시지, 경고 등이 기록되어 있으므로, 장애 발생 시 해당 로그를 분석하여 장애의 원인을 찾고 대응할 수 있습니다. 로그 분석을 통해 예상치 못한 동작, 오작동, 예외 상황 등을 식별하여 이에 대한 조치를 취할 수 있습니다. 서버 모니터링 데이터는 다양한 방식으로 수집되고, 성능 최적화, 용량 계획, 장애 예측 및 대응 등 여러가지 방식으로 활용됩니다. 이를 바탕으로 IT 인프라 관리자와 서버를 사용하는 이용자들이 원활하고 안정적으로 서버를 이용할 수 있도록 도와줍니다. 2023.07.04
회사이야기 강선근 대표이사, ‘중소기업인 대회’ 산업포장 수상 회사이야기 강선근 대표이사, ‘중소기업인 대회’ 산업포장 수상 강선근 브레인즈컴퍼니 대표이사가 20일 중소기업DMC타워에서 열린 ‘중소기업인 대회’에서 산업포장을 수상했습니다. 올해 34회째를 맞은 중소기업인 대회는 일자리, 수출, 사회기여 등 한국경제 발전에 공헌한 중소/벤처기업인의 성과를 되짚어 보고, 자긍심을 높이는 중소 기업계 최대 축제입니다. 중소기업인 대회는 기술력 뿐만 아니라 재무적 실적과 사회 공헌에 얼마나 이바지 했는지를 종합적으로 평가하며 일회성 공적이 아닌 얼마나 꾸준한 업적이 쌓았는지를 보고 수상자를 선발합니다. 강선근 대표이사는 IT 인프라 통합관리 솔루션, Zenius(제니우스)의 우수한 기술력으로 관제 분야의 국산화 및 국내 SW산업 수준을 향상시킨 공로를 인정 받았습니다. 또한 교육 기관에 기부금 전달 및 산학 협력 업무협약을 체결해 소프트웨어산업 인재 양성에 힘쓰고 있는 점을 인정받아 산업포장을 수상하게 되었습니다. △기술력: 다양한 이기종 IT 인프라에 대한 통합관리 시스템 Zenius EMS를 기반으로, 웹 애플리케이션 성능 모니터링 Zenius APM, 통합로그관리 Zenius SIEM , IT서비스 관리 Zenius ITSM 등으로 구성된 소프트웨어 발전 기여 △실적: 공공기관, 관제부분 실적 1위 △사회공헌: 산학 협력 등 일자리 창출 이번 행사는 서울지방중소벤처기업청과 중소기업중앙회 서울지역본부가 공동 주최하고 서울시가 후원하였습니다. 2023.06.21
기술이야기 서버 모니터링의 두 가지 방식 기술이야기 서버 모니터링의 두 가지 방식 이번 블로그에서는 일반적으로 서버 모니터링 소프트웨어들이 널리 쓰고 있는 서버 모니터링의 두 가지 방식에 대해서 논의하고 그 차이점을 알아보겠습니다. 지난 블로그에서 언급했듯이, 서버 모니터링은 컴퓨터 서버의 성능을 관찰하고 분석해 최적의 상태로 실행되고 있는지 확인하는 작업입니다. 이 프로세스에는 일반적으로 CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 및 응용 프로그램 성능과 같은 다양한 메트릭에 대한 데이터를 수집하는 소프트웨어 도구의 사용이 포함됩니다. 서버 모니터링 소프트웨어는 데이터 수집 후 추세, 패턴 및 이상 현상을 식별하기 위해 데이터를 분석합니다. 분석을 통해 잠재적인 문제가 심각해지기 전에 식별하고 서버 관리자가 시정 조치를 취할 수 있도록 합니다. 예를 들어, CPU 사용률이 지속적으로 높은 경우 서버의 성능이 부족해 더 많은 리소스를 할당해야 할 수 있음을 나타낼 수 있습니다. 또는 디스크 I/O가 느린 경우 서버의 저장소가 과부하됐거나 최적화가 필요함을 나타낼 수 있습니다. 서버 모니터링 소프트웨어에는 관리자가 서버 성능을 파악하는데 도움이 되는 대시보드, 경고 및 보고 기능이 포함되는 경우가 많습니다. 대시보드는 핵심 성과 지표의 실시간 보기를 제공하는 동시에 특정 임계값을 초과하거나 문제가 감지되면 관리자에게 알림을 보냅니다. 서버 관리자는 보고 기능을 통해 시간 경과에 따른 성능 추세 및 문제에 대한 보고서를 생성할 수 있으며, 이를 통해 용량 계획 및 리소스 할당 결정을 알리는데 사용할 수 있습니다. 서버 모니터링은 일반적으로 에이전트 없는 서버 모니터링과 에이전트 기반 서버 모니터링, 이 두 가지 주요 접근 방식이 있습니다. 두 가지 모두 장단점이 있으며 어떤 것을 선택하느냐는 특정 요구 사항과 선호도에 따라 달라집니다. 에이전트 기반 서버 모니터링 에이전트 기반 서버 모니터링에는 모니터링하려는 각 서버에 ‘에이전트’라고 하는 별도의 서버용 모니터링 소프트웨어를 설치해 데이터를 수집하는 방식을 말합니다. 에이전트는 서버에서 다양한 성능 메트릭에 대한 데이터를 수집해 모니터링 시스템으로 다시 보냅니다. 이 접근 방식은 에이전트 없는 모니터링보다 더 상세하고 세분화된 데이터와 기능을 제공합니다. 또, 데이터를 암호화하고 보안 채널을 사용해 데이터를 전송하므로 일반적으로 에이전트 없는 모니터링보다 더 안전합니다. 에이전트 기반 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 성능 모니터링: 에이전트는 CPU, 메모리, 디스크 사용률, 네트워크 트래픽 등의 정보를 수집할 수 있습니다. 이를 이용해 서버의 성능을 모니터링하고, 부하가 높아지면 적시에 대처할 수 있습니다. ∙ 로그 모니터링: 에이전트는 서버에서 발생하는 로그를 수집할 수 있습니다. 이를 이용해 서버에서 발생한 이벤트의 원인 파악에 도움을 줄 수 있습니다. ∙ 보안 모니터링: 에이전트는 서버 내부의 보안 상태를 모니터링할 수 있습니다. 예를 들어, 악성 코드 감지, 사용자 로그인 상태, 파일 권한 등을 체크해 보안 위협을 조기에 감지할 수 있습니다. ∙ 애플리케이션 모니터링: 에이전트는 서버에 설치된 애플리케이션의 상태를 모니터링할 수 있습니다. 예를 들어, 웹 서버에서는 HTTP 요청, 응답 코드, 응답 속도 등을 모니터링해 애플리케이션의 상태를 파악할 수 있습니다. ∙ 자동화된 조치: 에이전트는 모니터링 데이터를 기반으로 자동화된 조치를 수행할 수 있습니다. 예를 들면, CPU 부하가 높아지면 자동으로 스케일 업 또는 스케일 아웃을 수행할 수 있습니다. 에이전트 리스 서버 모니터링 에이전트가 없는 서버 모니터링은 서버 자체에 소프트웨어를 설치할 필요가 없습니다. 대신 모니터링 소프트웨어가 별도의 서버나 워크스테이션에 설치되고, SNMP 또는 WMI와 같은 네트워크 프로토콜을 사용해 대상 서버에서 데이터를 원격으로 수집합니다. 이 접근 방식은 각 서버에 소프트웨어 에이전트를 설치하고 관리할 필요가 없어 일반적으로 설정 및 유지 관리가 더 쉽고 빠릅니다. 또, 에이전트 기반보다 같은 자원을 이용해서 더 많은 수의 서버를 모니터링할 수 있어 경제적입니다. 대신 기능이 제한적이고 프로토콜이 의존해 데이터를 수집하기 때문에 보안 문제가 발생할 수 있습니다. 에이전트 리스 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 원격 모니터링: 에이전트 없는 모니터링 도구는 원격 데이터 센터, 지사 또는 클라우드 환경에 있는 서버를 포함해 모든 곳에 있는 서버를 원격으로 모니터링할 수 있습니다. 이러한 유연성을 통해 조직의 전체 서버 인프라를 중앙집중식으로 모니터링하고 관리할 수 있습니다. ∙ 확장성: 에이전트 없는 모니터링은 서버 인프라 또는 워크로드 요구사항의 변화를 수용하기 위해 쉽게 확장 또는 축소할 수 있습니다. 추가 에이전트 소프트웨어 설치 또는 구성 없이 모니터링 시스템에 추가 서버를 추가할 수 있습니다. ∙ 포괄적인 모니터링: 에이전트 없는 모니터링은 서버 성능 메트릭을 추적하고 문제를 식별하며, 실시간 경고를 제공함으로써 관리자가 서버 인프라의 상태를 유지하고 중요한 애플리케이션과 서비스가 원활하게 실행되도록 합니다. ∙ 손쉬운 유지 관리 및 업데이트: 에이전트 없는 모니터링을 사용하면 모니터링 되는 각 시스템에서 에이전트 소프트웨어를 관리하고 업데이트할 필요가 없습니다. 이는 유지보수를 단순화하고 모니터링 시스템을 항상 최신 상태로 유지합니다. Zenius(제니우스)의 서버 모니터링 브레인즈컴퍼니의 지능형 IT 인프라 통합관리 소프트웨어 ‘Zenius(제니우스)’는 고객의 시스템 상황에 따라 에이전트 기반 및 리스 방식 모두 가능합니다. 에이전트 기반의 통합 모니터링 소프트웨어 ‘Zenius SMS’는 HTML5 기반 Web UI와 토폴로지 맵을 통해 서버 성능과 상태 및 서버 간 연관관계를 직관적으로 파악합니다. 특히, Zenius SMS는 애플리케이션 단위에 성능이나 로그를 세밀하게 모니터링 및 분석이 가능합니다. Zenius SMS의 주요 기능은 아래와 같습니다. Zenius SMS의 주요 서버 모니터링 기능 1. 프로세스: 프로세스 상태(Up/Down) 및 성능 모니터링(CPU/MEM) 2. 로그: 프로세스나 시스템 로그와 같은 각종 로그 모니터링 3. GPU: GPU의 상태 및 성능 모니터링 4. 보안: 서버의 보안 취약점 점검 5. 자동화: 모니터링 데이터를 기반으로 자동화된 조치 수행 6. 기타: 코어별 온도 모니터링, 서비스 포트별 네트워크 상태, S/W 목록, 환경변수, 계정, 그룹, 스케쥴링, 공유폴더 현황 등 ‘Zenius SMS’ 도입을 통해 체계화된 서버 통합관리를 할 수 있습니다. 반복적이고 수동적인 업무는 자동화돼 업무 효율성을 향상시키며, 객관적인 데이터를 기반으로 정확한 성능 현황 및 비교분석이 가능합니다. 이는 곧 서비스 연속성 확보로 이어지며, 향후 고객 만족도 향상을 기대할 수 있습니다. 반면, 고객 서버에 에이전트 탑재가 불가능한 경우에는 에이전트 리스 방식으로도 사용 가능합니다. 브레인즈컴퍼니의 에이전트 리스 제품으로는 ‘Zenius VMS’가 있습니다. ‘Zenius VMS’는 VMware, Citrix Xen Server, Hyper-V와 같은 서버 가상화 환경에서 호스트 서버와 게스트 서버의 리소스 할당 및 사용 현황, 관계 등을 통합적으로 관제합니다. ‘Zenius VMS’는 프라이빗 클라우드 환경을 모니터링하는데 효과적입니다. Open API로 프라이빗 클라우드 인프라와 통신해, 가상머신의 상태 및 성능, 스토리지 활용도 및 네트워크 트래픽과 같은 환경의 다양한 측면에 대한 데이터를 수집합니다. 수집된 데이터를 분석해 잠재적 문제를 나타낼 수 있는 경향, 패턴 및 이상 현상을 식별하고, 크게 CPU, 메모리, 디스크, MIB 이 4가지 정보를 기본적으로 제공합니다. ‘Zenius VMS’는 VM 상세 관리를 위해 SMS 추가 확장이 용이한 제품입니다. VMS를 통해 호스트-게스트 간 연관관계 기반의 모니터링을 시행하고, 별도로 가상화 서버에 SMS 모듈을 추가해 보다 다양한 모니터링 항목으로 정밀하게 관리함으로써 효과적인 통합관리 환경을 조성할 수 있습니다. 2023.05.09
기술이야기 서버 모니터링, 서버 관리, 서버 관리자 기술이야기 서버 모니터링, 서버 관리, 서버 관리자 서버는 기업의 IT 인프라를 구성하는 필수 요소입니다. 서버는 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템으로, ▲파일 저장 및 공유 ▲웹사이트 및 애플리케이션 호스팅 ▲프린터 및 스캐너와 같은 네트워크 리소스 관리 ▲이메일 서비스 제공 등 다양한 기능을 수행합니다. 일반적으로 Microsoft Windows Server, Linux 또는 Unix와 같은 다양한 운영 체제를 실행하며, 가동 중지 시간을 최소화하면서 지속적으로 실행되도록 설계됐습니다. 오늘날과 같이 급변하는 비즈니스 환경에서의 서버 중단은 상당한 수익 손실과 평판 손상으로 이어질 수 있습니다. 이에 따라 기업은 서버 모니터링 및 관리를 위해 문제를 신속하게 식별하고 해결할 수 있는 강력한 서버 모니터링 시스템을 필수적으로 갖춰야합니다. 서버 모니터링과 서버 관리는 서버의 성능을 최적화하고 가용성을 보장하는데 중요한 관련이 있습니다. 이 블로그에서는 서버 모니터링과 서버 관리에 대해서 알아보고, 마지막으로 서버관리자가 어떤 일을 하는지 논의해 보고자 합니다. 먼저, 서버 모니터링과 서버 관리의 차이점은 다음과 같습니다. ------------------------------------------ 서버 모니터링이란? 서버 모니터링에는 도구와 소프트웨어를 사용해 서버의 성능, 상태 및 가용성을 추적하는 작업이 포함됩니다. 여기에는 CPU 사용량, 메모리 사용량, 디스크 공간, 네트워크 트래픽 및 애플리케이션 성능과 같은 모니터링 지표가 포함됩니다. 서버 모니터링의 목표는 문제가 발생하기 전에 잠재적인 문제를 감지하고, 문제가 발생할 때 문제 해결을 위한 데이터를 제공하는 것입니다. 서버 모니터링은 일반적으로 특수 도구를 사용해 자동화되는 프로세스입니다. 서버 관리란? 서버 관리는 서버가 최적으로 작동하도록 서버를 능동적으로 유지∙관리하고 구성하는 프로세스입니다. 여기에는 운영 체제, 소프트웨어 및 응용 프로그램의 설치 및 구성, 사용자 계정 및 사용 권한 관리, 백업 및 복원 수행, 서버 환경의 보안 및 규정 준수 보장 등의 작업이 포함됩니다. 서버 관리의 목표는 서버가 최고의 효율성으로 실행되고 안전하며, 사용자에게 필요한 서비스를 제공할 수 있도록 하는 것입니다. 요약하면, 서버 모니터링은 관찰 및 경고에 중점을 두는 반면, 서버 관리는 성능을 최적화하고 가용성을 보장하기 위해 서버를 능동적으로 구성하고 유지∙관리하는데 중점을 둡니다. 서버 모니터링은기업의 서버 관리자가 담당합니다. 서버 관리자는 기업의 비전과 전략을 달성하기 위해 서버를 비롯한 IT 시스템의 방향을 수립하는 IT 전문가입니다. 서버 관리자는 높은 수준의 가동 시간과 가용성을 보장하고 서버, 시스템 및 애플리케이션의 소프트웨어 및 하드웨어 기능과 같은 구성 요소를 평가합니다. 서버 관리자의 주요 업무는 조직의 규모와 특정 요구 사항에 따라 다를 수 있지만, 일반적으로 아래와 같습니다. 서버 관리자의 주요 업무 1. 서버 설치 및 구성 서버 설치 및 구성은 서버 관리자의 필수 업무로, 서버 하드웨어, 소프트웨어 및 네트워크 인프라에 대한 기술적 전문 지식, 세부 사항에 대한 주의 및 철저한 이해가 필요한 복잡한 작업입니다. 서버 관리자는 최적의 성능, 보안 및 안정성을 제공하는 동시에 서버가 조직의 요구사항을 충족하도록 올바르게 설치 및 구성됐는지 확인해야 합니다. 2. 서버 모니터링 및 유지보수 서버의 안정성과 성능을 유지하기 위한 핵심 업무입니다. 서버 관리자는 서버 하드웨어 및 소프트웨어를 유지∙관리해, 서버가 효율적이고 안전하게 실행되도록 하고 시스템 성능을 모니터링해 잠재적인 문제를 식별합니다. 3. 서버 보안 서버 보안 관리는 서버에 저장된 데이터의 기밀성, 무결성 및 가용성을 손상시킬 수 있는 잠재적인 보안 위협으로부터 서버를 보호하는 것과 관련된 업무입니다. 서버 관리자는 서버가 잠재적인 보안 위협으로부터 보호되고 서버가 관련 규정 및 표준을 준수하는지 확인하기 위해 적극적으로 노력합니다. 4. 서비스 제공 및 지원 서비스 제공 및 지원은 서버 서비스 및 응용 프로그램의 배포, 유지 및 지원 관리와 관련 있습니다. 이 업무는 서버 가용성을 유지하고 사용자 요구 사항을 충족하는데 중요하며, 서버 관리자는 사용자가 필요할 때 시기 적절하고 효과적인 지원을 받을 수 있도록 합니다. ------------------------------------------ 이처럼 서버 관리자는 서버가 원활하고 안전하며 효율적으로 실행되도록 하는데 중요한 역할을 합니다. 서버 관리자는 복잡한 기술적 지식을 보유해야 하고 빠른 대처 능력을 요구받으며, 보안 대응 및 최적화 작업 등에서 많은 어려움을 겪습니다. 더욱이 서버가 기능에 따라 세분화돼 일반 서버, 웹 어플리케이션 서버, 데이터베이스 서버 등으로 나뉘게 되면 각 기능별로 웹 애플리케이션 서버관리자나 데이터베이스 서버관리자 등으로 관리자의 역할이 세분화되기도 합니다. 서버의 수나 종류가 많아지고 구성이 복잡해지면 모니터링과 관리가 어려워집니다. 이를 돕기 위해 브레인즈컴퍼니의 Zenius(제니우스)와 같은 통합 서버 모니터링 및 관리 소프트웨어가 필요하게 됩니다. 2023.05.09
회사이야기 통합보안관리 솔루션 'Zenius SIEM' 국내 CC인증 획득 회사이야기 통합보안관리 솔루션 'Zenius SIEM' 국내 CC인증 획득 브레인즈컴퍼니(099390)는 차세대 통합보안관리 솔루션 'Zenius(제니우스) SIEM v2.0’이 국내 CC(Common Criteria)인증 EAL(Evaluation Assurance Level) 2등급을 획득했다고 19일 밝혔다. 국내 CC인증은 IT보안인증사무국이 IT 제품의 보안성, 안정성, 신뢰성을 검증하고 이를 인증하는 제도다. 'Zenius SIEM v2.0'은 이기종의 다양한 장비에서 발생되는 대용량 로그를 수집 및 분석하고, 개인정보보호, 개인정보처리스템의 접속기록관리 등 각종 컴플라이언스에서 로그를 안전하게 저장하고 관리하는 소프트웨어다. 제품은 162만 EPS(Event Per Second)의 인덱싱과 1TB에 0.02초 이내 검색 성능을 바탕으로 로그 수집 현황을 실시간으로 모니터링하고, 수집된 로그에 대한 위/변조 감시 기능을 제공한다. 특히 HTML5 기반 반응형 웹 환경 지원, 26종의 차트 및 컴포넌트 등 사용자 중심의 대시보드와 편리한 보고서 기능을 제공한다. 또, 'Zenius SIEM v2.0'은 SQL(Structured Query Language)에서 제공하는 함수를 이용해 이상 탐지가 가능하고, 서버 증설 시 서비스 중단없이 병렬확장 할 수 있다. 브레인즈컴퍼니는 2020년에 'Zenius SIEM v1.0'을 처음 개발한 후, 이번 업그레이드로 빅데이터 기반의 다양한 로그 수집 및 연관분석을 통해 관리 효율을 증대하고, 국내 네트워크 환경의 규제를 준수하기 위해 CC인증을 획득했다. 강선근 브레인즈컴퍼니 대표는 "향후 ChatGPT와 같은 LLM(Large Language Model)기술을 활용해 고객에게 보다 편리한 인터페이스를 제공하고, SaaS(Software as a Service, 서비스형 소프트웨어)버전을 준비하고 있다"고 말했다. 2023.04.19

1 2 3 4 5 6