반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
AI 인공지능
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
APM Solution
애플리케이션 관리
URL 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
기술이야기
검색
기술이야기
NMS(네트워크 관리 시스템)에 대해서 꼭 알아야 할 네 가지
기술이야기
NMS(네트워크 관리 시스템)에 대해서 꼭 알아야 할 네 가지
산업 분야를 통틀어서 최근 모든 기업과 공공기관들의 ‘네트워크’ 활용도와 의존도가 빠르게 증가하고 있습니다. 따라서 이제 ‘안정적인 네트워크 관리 = 성공적인 비즈니스 운영’이라고도 할 수 있는데요. 오늘은 네트워크를 안정적으로 유지해서 성공적인 비즈니스 운영을 도와주는, NMS(Network Management System, 네트워크 관리 시스템)에 대해서 자세히 알아보겠습니다. NMS의 등장 배경, 시대별 변화, 그리고 핵심 개념과 실제 사례까지 NMS에 대해서 꼭 알아야 할 네 가지는 무엇일까요? 。。。。。。。。。。。。 │NMS(네트워크 관리 시스템)의 기본 개념과 등장 배경 NMS란 다양한 이기종 네트워크 장치(Network device)를 중앙에서 관리하고 감시할 수 있는 시스템입니다. 즉 전체 네트워크를 중앙 시스템을 통해 모니터링, 진단, 분석, 가용성을 유지하기 위해 만들어진 시스템을 말합니다. NMS의 필요성과 등장 배경은 OSI의 SMFAs(Specific Management Functional Areas)의 다섯 가지 영역(FCAPS)로 정리할 수 있습니다. 장애관리(Fault Management): 경보 감시, 고장 위치의 측정 시험 등 NMS의 첫 번째 관심사는 네트워크의 가용성을 보장하는 것입니다. 네트워크에서 발생하는 장애를 감지·격리·복구하는 과정으로, 네트워크 가동 시간을 최대화하고 서비스 중단을 최소화하는 것이 목적입니다. 구성 관리(Configuration Management): 설비제공, 상태 제어, 설치 지원 등 네트워크의 구성 요소(하드웨어, 소프트웨어, 네트워크 설정 등)를 관리하는 과정으로, 네트워크의 변경 사항을 추적하고 일관된 네트워크 성능과 안정성을 유지하는 데 중요합니다. 계정관리(Accounting Management): 계정(과금) 정보의 수집/저장/제어 등 네트워크 자원의 사용량을 추적하고 기록하는 과정이며, 자원의 할당과 과금에 사용됩니다. 사용량, 사용시간, 서비스 품질, 장비 사용률 등 네트워크 관리 및 운영에 관한 비용 할당 시 필요합니다. 성능 관리(Performance Management): 성능감시/트래픽 관리/품질관리/통계관리 네트워크의 트래픽이 특정 시간에 급증하는 것을 성능 관리 시스템이 감지했을 때, 이 정보를 사용하여 네트워크 용량을 적절히 조정하거나 트래픽을 분산시킬 수 있습니다. 보안 관리(Security Management): 보안/안전/기밀 관리 등 보안 관리 시스템은 사용자의 무단 엑세스 시도를 감지하며 즉시 차단할 수 있는 접근 제어, 인증, 암호화, 키관리 등을 관리하는 것과 관련이 있습니다. 네트워크 인프라의 로그 모니터링을 통해 잠재적인 보안 문제를 사전에 예방할 수 있습니다. 위와 같은 등장 배경과 필요성을 가진 NMS, 시대별로는 어떻게 변해왔는지 살펴보겠습니다. │NMS(네트워크 관리 시스템)의 시대별 변화 1980년대 초부터 현재에 이르기까지 NMS의 시대별 변화를 간략히 살펴보면 다음과 같습니다. 1980년대 ~ 2010년대 초 1980년대에 등장한 초기 NMS는 단순한 모니터링과 제어에 둔 간단한 형태였고, 특정 벤더의 하드웨어에 종속되고 표준화가 제대로 이루어지지 않았었습니다. 1990년대에 들어서 네트워크의 복잡성이 커지면서 NMS의 필요성도 증가했습니다. 이때 보안 기능이 향상된 SNMPv2와 같은 표준 프로토콜이 도입되면서, 다양한 제조사의 장비를 하나의 시스템으로 통합 관리할 수 있게 되었습니다. 또한 네트워크뿐만 아니라 서버까지 같이 관리하기 위한 SNMS(Server and network Management System)와, 더 나아가 EMS(ITIM)도 나오게 되었습니다. 이후 2000년대 초반에 웹 기반 NMS 솔루션이 등장하면서, 사용자 친화적인 인터페이스와 원격 접근 기능 등을 통해 효율적인 네트워크 관리가 가능해졌습니다. 2010년대 중반 ~ 2010년대 후반 NMS는 2010년대 중반부터 등장한 클라우드 컴퓨팅, 빅데이터, 인공지능(AI) 등의 기술과 함께 더욱 고도화되었습니다. 점점 더 다양한 네트워크와 서비스를 통합 관리하며, 자동화된 분석과 의사결정을 지원하게 되었습니다. 최신 동향 최근에는 AI와 머신러닝을 활용하여 예측 분석, 네트워크의 자동 최적화, 사이버 보안 통합 등이 NMS의 중요한 요소로 강조되고 있습니다. 또한 새로운 네트워크 기술인 5G의 도입으로 NMS는 더욱 복잡해지고 다양한 네트워크 환경을 관리하게 되었습니다. 이처럼 NMS는 네트워크 기술의 발전과 산업의 변화에 발맞추어, 지속적이고 빠르게 발전하고 있습니다. 이제 NMS의 구조에 대해서 자세히 알아보겠습니다. │NMS(네트워크 관리 시스템)의 3-Tier 아키텍처 NMS는 3-Tier 아키텍처(수집-저장-표출)로 구성되어 있습니다. 각각 독립된 계층으로 구분되어 있는데요. 특정 부분의 업그레이드가 필요할 때 해당 계층만 영향을 주기 때문에 시스템을 보다 쉽게 관리할 수 있습니다. 다시 정리한다면 NMS Manager에서 SNMP · ICMP · RMON 등 다양한 네트워크 프로토콜을 활용하여, 네트워크 자원의 성능 데이터를 수집합니다. 만약 Managed Device 장비들이 한계치에 도달하거나 장애가 발생했을 경우, 즉각적으로 User Interface를 통해 사용자에게 알립니다. 그렇다면 NMS의 핵심 기능은 무엇일까요? │NMS(네트워크 관리 시스템)의 핵심 기능 네트워크 장애에 대한 신속한 파악과 대응이 반드시 필요한 NMS의 핵심 기능에는 어떤 것들이 있는지 자세히 살펴보겠습니다. 장애 관리 네트워크 인프라의 결함이나 오류를 탐지하고 경고 및 알림을 생성하여, 관리자가 신속하게 대응할 수 있도록 지원합니다. 이를 통해 다운타임을 최소화하고 서비스 지속성을 보장합니다. 예를 들어 네트워크의 라우터가 다운될 경우, NMS는 즉시 관리자에게 경고를 보내 신속한 문제 해결을 도와줍니다. 성능 관리 네트워크 구성 자원인 트래픽 가용성, 응답시간, 사용량, 오류량, 처리 속도 등을 추적하고 최적화합니다. 또한 부하가 발생하지 않도록 문제점을 미리 검출해 안정적인 네트워크 운영이 될 수 있도록 합니다. 예를 들어 특정 애플리케이션이 과도한 대역폭을 소비할 경우, NMS가 문제를 정확히 찾아내서 관리자가 네트워크를 최적화할 수 있도록 돕습니다. ▲ 제니우스(Zenius)를 활용한 성능 모니터링 화면 예시 구성 관리 관리자는 NMS를 통해 분산된 네트워크 장치 구성 프로세스를 자동화하여, 네트워크 전반에 걸쳐 일관성과 정확성을 보장할 수 있습니다. 이러한 핵심 기능을 하는 NMS의 구체적인 활용 사례를 살펴보겠습니다. │NMS(네트워크 관리 시스템)의 활용 사례 IT 분야뿐 아니라 제조업, 금융, 여행, 유통 및 물류 등 전 분야에 걸쳐서 NMS가 사용되고 있습니다. 특히 처리 속도, 가용성, 보안 등이 중요한 금융산업의 경우에 NMS를 통한 안정적인 관리가 중요한데요. 브레인즈컴퍼니의 제니우스(Zenius) EMS를 사용하고 있는 S금융사의 사례를 자세히 살펴보겠습니다. S금융사, Zenius NMS를 통해 완벽하게 네트워크를 관리하게 되다 S금융사는 서버만 800ea, NW 14,000ea 이상의 대규모 인프라를 보유하고 있었습니다. 하지만 Zenius NMS 도입 전까지는 서비스 장애에 영향을 준 네트워크 장애 원인 파악을 위한 장기간 투자하고 있는 상황이었고, 네트워크 운영 현황 데이터 수집과 분석에 많은 시간이 소요되고 있었습니다. 무엇보다 신속한 장애 인지와 처리가 어려워서 큰 고민이 있었는데요. 위 도표에서도 살펴본 것처럼 Zenius NMS 도입을 통해, 이전에 고민과 단점을 극복하고 안정적으로 네트워크 관리를 할 수 있게 되었습니다. 특히 Zenius NMS는 고성능의 Manager를 제공하고 있어 대규모 환경에서도 장애를 신속하게 판단하여, 타사 대비 많은 자원을 효율적으로 관리할 수 있습니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼 NMS는 네트워크 인프라를 효율적으로 관리하는데 가장 중요한 역할을 합니다. 제니우스(Zenius) NMS처럼 고성능의 Manager를 기반으로 네트워크 상태를 신속하게 판단하며, 유저 중심의 통합 UI를 제공하는 NMS 솔루션을 꼭 선택하시기 바랍니다!
2024.01.31
기술이야기
가트너부터 딜로이트까지, 2024 IT트렌드 총정리
기술이야기
가트너부터 딜로이트까지, 2024 IT트렌드 총정리
지난해는 AI를 중심으로 IT 전 분야에서 혁신적인 변화가 있었고, 올 2024년에는 변화의 속도가 더 빨라질 것으로 예상됩니다. 따라서 이와 같은 빠른 변화를에 얼마나 잘 대처하는지가 점점 더 중요해지고 있는데요. 변화를 더 자세하고 빠르게 파악하기 위해서 가트너, 딜로이트, 포레스터 리서치가 발표한 2024 IT 트렌드의 핵심 내용을 모아봤습니다. 。。。。。。。。。。。。 가트너, AI가 가져올 구체적인 변화에 주목하다 가트너는 AI TRiSM부터 Machine Customers까지 총 10개의 주제로 2024년 IT 트렌드를 정리했습니다. 특히 AI와 클라우드를 통한 산업에서의 구체적인 변화에 주목했는데요. 자세한 내용을 살펴보겠습니다. [1] AI TRiSM: AI의 신뢰, 위험 및 보안 관리 AI TRiSM(AI Trust, Risk, and Security Management)은 인공지능 시스템의 신뢰성, 위험, 보안을 관리하는 프레임워크입니다. AI가 윤리적이고 공정하며 투명해야 함을 의미하며, 잠재적 위험을 식별하고 완화하는 데 중점을 둡니다. 보안 관리는 AI 시스템을 사이버 공격과 데이터 유출로부터 보호합니다. AI TRiSM은 의료·금융·자율주행 차량 등, 다양한 분야에서 AI의 안전하고 책임 있는 사용을 보장하는 데 필수적입니다. 이를 통해서 AI 기술의 지속 가능한 발전과 사회적 신뢰를 유지할 수 있습니다. [2] CTEM: 지속적인 위협 노출 관리 Continuous Threat Exposure Management(CTEM)은 사이버 보안 분야에서 조직의 지속적인 위협 노출을 관리하는 전략입니다. 이 방법론은 실시간 모니터링, 자동화된 위험 평가, 적응적 대응 전략을 포함하며 장기적으로 비즈니스의 연속성을 보장하는데 기여합니다. 예를 들어 금융 서비스 회사는 네트워크와 시스템을 지속적으로 스캔하여 취약점을 탐지하고, 감지된 위협에 대해 우선순위를 매겨 신속하게 대응해야 합니다. 또한 소프트웨어 개발 회사는 개발 중인 소프트웨어와 인프라를 모니터링하여 보안 취약점을 조기에 발견하고, 자동화된 도구를 사용해 코드의 취약점을 수정해야 합니다. [3] Sustainable Technology: 지속 가능한 기술 지속 가능한 기술은 환경 영향을 줄이고 지속 가능성을 촉진하는 혁신 및 관행을 포함합니다. IIoT(산업용 사물 인터넷) 센서와 AI를 사용하여 공급망 작업을 최적화하고, 탄소 배출을 줄이며 전반적인 장비 효율성을 향상시키는 산업이 좋은 예입니다. 또한 자급자족 LED 조명, 전기 교통, 태양 에너지, 탄소 포집 및 저장 기술 등의 지속 가능한 기술과 관행도 포함됩니다. 가트너는 또한 지속 가능한 기술이 위험 감소, 운영 효율성 향상, 경쟁 우위 획득, 인재 유치, 환경 및 사회적 책임 강화와 같은 비즈니스 이점을 제공한다고 강조합니다. [4] Platform Engineering: 플랫폼 엔지니어링 플랫폼 엔지니어링은 개발자와 사용자가 쉽게 사용할 수 있는 도구, 기능 및 프로세스 세트를 제공하는 방식입니다. 사용자의 생산성을 높이고 부담을 줄이는데 중점을 둡니다. 플랫폼 엔지니어링은 사용자의 특정 요구와 비즈니스 요구에 맞게 플랫폼을 수정합니다. 전담 제품 팀은 재사용 가능한 도구와 적절한 기능을 제공하며, 사용자 친화적인 인터페이스 솔루션을 제공합니다. 자동화된 프로세스 및 의사 결정을 위한 기초를 제공하며, 복잡한 상황에서도 디지털 개발을 가속화하게 하는 Be Informed 플랫폼이 좋은 예입니다. [5] AI-Augmented Development: AI 증강 개발 소프트웨어 개발 과정에서 AI를 활용하여 개발자의 작업을 돕고, 테스트 플랫폼과 문서 작성을 지원하는 것을 뜻합니다. GitHub Copilot, Replit GhostWriter, Amazon CodeWhisperer와 같은 AI 기반 코드 생성 서비스가 좋은 예입니다. 이러한 AI 기반 코딩 도우미를 사용하여 업무의 효율을 높일 수 있지만, AI가 오류를 발생시킬 수 있고 독창적인 코드를 생성할 수 없기에 개발자의 역할은 여전히 중요합니다. [6] Industry Cloud Platforms: 산업 클라우드 플랫폼 Industry Cloud Platforms은 특정 산업에 특화된 기능을 제공하는 클라우드 서비스입니다. SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service)를 결합하여 업계별 맞춤형 기능을 제공합니다. 구체적으로 네 가지의 서비스를 예로 들 수 있습니다. ◾ AWS for Healthcare AWS는 의료 산업에 특화된 클라우드 서비스를 제공하여 의료 데이터 관리, 환자 관리, 의료 연구 등을 지원합니다. ◾ Microsoft Cloud for Financial Services 금융 산업에 맞춤화된 클라우드 솔루션을 제공하여 은행업, 보험 업계에서 사용되고 있습니다. ◾ GCP for Retail Google은 소매 산업에 특화된 클라우드 서비스를 통해 고객 데이터 분석, 재고 관리, 전자상거래 솔루션 등을 지원합니다. ◾ IBM Cloud for Telecommunications 통신 산업에 최적화된 클라우드 서비스를 제공하여 네트워크 운영, 고객 서비스 향상, 신기술 적용 등을 지원합니다. 이러한 산업별 클라우드 플랫폼은 기업이 보다 효율적으로 운영하고 혁신을 가속화하는 데 도움을 줍니다. [7] Intelligent Applications: 지능형 애플리케이션 Intelligent Applications은 인공지능(AI)과 머신러닝 기술을 활용하여 데이터를 분석하고, 사용자 행동을 예측하는 등의 기능을 제공합니다. 자동화된 의사결정, 사용자 맞춤형 경험 제공, 그리고 비즈니스 프로세스의 효율성 향상을 위해 설계되었습니다. 예를 들어 고객 서비스를 위한 AI 기반 챗봇, 데이터 분석을 통해 사용자에게 맞춤형 추천을 제공하는 소매 애플리케이션, 또는 실시간 의료 데이터 분석을 제공하는 헬스케어 애플리케이션 등이 있습니다. Salesforce Einstein, Google Cloud AI, IBM Watson, Microsoft Azure AI가 지능형 애플리케이션에 해당합니다. [8] Democratized Generative AI: 민주화된 생성 AI Democratized Generative AI는 인공지능의 생성 능력을 널리 사용할 수 있게 하는 개념으로, 비전문가도 쉽게 사용할 수 있는 AI 도구와 플랫폼을 의미합니다. 창작물 생성, 데이터 분석, 예측 모델링 등 다양한 분야에서 사용됩니다. 구체적인 서비스나 회사로는 OpenAI의 GPT-, Google의 DeepMind, Adobe의 Sensei와 같은 플랫폼들이 이에 해당합니다. 이러한 도구들은 사용자가 복잡한 알고리즘을 직접 다루지 않고도 AI의 혜택을 누릴 수 있게 해줍니다. [9] Augmented Connected Workforce: 증강 연결된 노동력 기술을 활용하여 직원들의 작업 능력을 향상시키고 원격 협업을 강화하는 전략입니다. 가상 현실, 증강 현실, 인공지능 등을 포함하는 다양한 기술을 활용하여 직원들이 더 효율적이고 효과적으로 협업하고 작업할 수 있도록 지원합니다. Microsoft의 HoloLens와 같은 증강 현실 기기나 Slack, Microsoft Teams와 같은 협업 플랫폼이 좋은 예입니다. 이러한 기술들은 직원들이 시간과 장소의 제약 없이, 효과적으로 협업하고 작업할 수 있는 환경을 만들어줍니다. [10] Machine Customers: 기계 고객 기계나 소프트웨어가 독립적으로 결정을 내리고 트랜잭션을 수행하는 시나리오를 말합니다. 예를 들어 IoT(사물 인터넷) 기기나 자동화 시스템이 소비자 역할을 수행하여 자동으로 주문하거나, 서비스를 요청하는 것입니다. Amazone Dash의 예시 소모품의 사용량을 체크하여 필요할 때 자동으로 주문하는 Amazon의 Dash Service가 대표적인 예입니다. 이러한 기술은 자동화된 공급 체인 관리와 효율적인 재고 관리 등에 기여하며, 비즈니스와 소비자 모두에게 편리함을 제공합니다. 딜로이트, 6가지 트렌드에 주목하다 딜로이트(Deloitte)는 2024 IT 트렌드를 아래와 같은 여섯 개의 주제로 정리했습니다. [1] 공간 컴퓨팅과 메타버스 메타버스는 기업의 주요 도구로 자리 잡고 있으며, 공간 컴퓨팅 기술도 점점 더 중요한 역할을 할 예정입니다. 디지털 트윈, 5G, 클라우드, 엣지, AI 기술에 대한 투자가 이 변화를 주도하고 있습니다. [2] 생성형 AI 생성형 AI는 비즈니스를 개선하고 혁신을 촉진하는 강력한 도구로, 전략적 계획과 특정 비즈니스 요구에 초점을 맞추어 구현되고 있습니다. 기업은 이 기술을 통해 각 분야에서 높은 경쟁력을 확보할 수 있습니다. 사용자의 시청 패턴과 선호도를 분석하여, 개인화된 추천 콘텐츠를 제공하는 Netflix와 Spotify가 가장 기본적이고 좋은 예입니다. [3] 새로운 컴퓨팅 방식의 도입 비즈니스는 기존 인프라를 더 효율적으로 활용하고, 최첨단 하드웨어를 추가하여 프로세스를 가속화하고 있습니다. 일부 기업은 이전 컴퓨팅을 넘어서 클라우드, 엣지, 양자 컴퓨팅 등 새로운 컴퓨팅 방식을 모색하고 있습니다. [4] 개발자 경험 강화(DevOps를 넘어 DevEx로) 기술 인재를 유치하고 유지하기 위해 회사들은 개발자 경험에 초점을 맞추고 있습니다. Github Copilot 같은 코드 자동 완성 및 분석 도구의 도입, 통합 개발 환경(IDE) 최적화, 컨테이너화 및 오케스트레이션 도구 도입 등이 이에 해당합니다. 이러한 노력은 결국 최종 사용자의 경험을 향상시켜 비지니스 성과를 높여줄 예정입니다. [5] 합성 미디어 시대의 진실 방어 AI의 부상으로 인해 악의적인 딥페이크 콘텐츠가 증가함에 따라, 각 기업과 조직들은 유해 콘텐츠를 식별하고 잠재적 공격을 예측하기 위한 방법을 도입하고 있습니다. 특히 2024년은 미국 대통령 선거 등 중요한 이벤트가 많기에 중요한 이슈로 떠오를 예정입니다. [6] 기술적 부채에서 기술적 웰니스로 각 회사와 조직은 기존 코어 시스템, 인프라, 데이터, 애플리케이션을 포함한 노후화된 시스템을 현대화해야 합니다. 이를 위해 정기적인 점검과 예방적 관리에 중점을 두는 새로운 접근 방식이 필요합니다. 포레스터 리서치, 생성형 AI와 디지털 혁신에 주목하다 포레스터 리서치에 따르면 전 세계 기술 분야에 대한 투자는 5.3% 증가할 것으로 예상됩니다. 이 중 금융 서비스와 헬스케어가 가장 빠른 성장세를 보일 것이고, 클라우드 컴퓨팅을 포함한 IT 서비스와 소프트웨어 분야는 2027년까지 가장 높은 비중을 차지할 예정입니다. 또한 기업이 위험을 줄이고 경쟁력을 확보하기 위해선 생성형 AI, 그리고 녹색 및 디지털 혁신 등에 주목해야 합니다. 생성형 AI 생성형 AI는 2024년에 중요한 역할을 할 것으로 예상됩니다. 대형 컨설팅 회사들은 생성형 AI에 큰 규모의 투자를 할 것이며, 해당 기업들은 경쟁력을 높이기 위해 AWS, Microsoft Azure, GCP 등과 파트너십을 맺을 것으로 예상됩니다. 이제 각 기업이 생성형 AI를 활용하여 실질적인 이윤을 추구하기 시작할 것이기 때문에, 2024년을 '의도적 AI 시대(era of intentional AI)의 원년'이라고도 말할 수 있습니다. 녹색 및 디지털 혁신 데이터 센터의 에너지 효율을 높이기 위한 노력이 진전을 보이고 있습니다. 2030년까지 데이터 센터를 탄소 중립으로 만들겠다는 약속이 강화되고 있습니다. 이는 지속 가능하고 환경친화적인 기술로의 전환의 시작을 뜻합니다. 기술 리더들의 도전 기술 분야의 리더들이 인재를 발굴하고 비즈니스 전략과 기술을 조화시키는데 어려움을 겪을 것으로 예상됩니다. 또한 AI와 관련된 기술의 수요가 빠르게 증가할 것이기에, 관련된 기술과 경험을 기르는 것도 매우 중요해지고 있습니다. 마지막으로 포레스터는 기업들의 경쟁력 유지와 성장 촉진을 위해 위와 같은 트렌드를 빠르게 받아들여야 한다고 강조했습니다. 매튜 구아리니 포레스터 리서치 부사장은, "전체 기술 전략을 핵심까지 현대화하고 조직과 운영을 크게 향상시켜야 성과를 얻을 수 있다"라고 말했습니다. 。。。。。。。。。。。。 가트너, 포레스터 리서치, 딜로이트가 전망한 2024 IT 트렌드를 살펴봤습니다. 트렌드를 아는 것에서 그치는 것이 아니라 발 빠르게 대응하는 것이 가장 중요합니다. 브레인즈컴퍼니는 트렌드에 빠르고 효과적으로 대응할 수 있도록, 제니우스(Zenius)를 통해 쿠버네티스(Kubernetes)를 비롯한 프라이빗/퍼블릭/하이브리드 클라우드 환경, 온-프레미스 환경 모두를 완벽하게 관리할 수 있는 서비스를 제공하고 있습니다. 또한 브레인즈컴퍼니의 자회사인 에이프리카는 AI 비즈니스를 위한 쿠버네티스 기반의 AI 개발 통합 플랫폼 솔루션과, 멀티 클라우드 통합 관리 플랫폼(CMP) 솔루션을 제공하고 있습니다(🔍에이프리카 솔루션 자세히 보기). 힘차게 시작한 2024년, 올 한 해는 또 얼마나 큰 변화가 있을까요? 이 글을 읽으시는 모두가 변화에 앞서가서 성공 스토리를 만들 수 있기를 기원합니다.
2024.01.19
기술이야기
클라우드 전환과 하이브리드 클라우드가 성공하려면?
기술이야기
클라우드 전환과 하이브리드 클라우드가 성공하려면?
정부와 공공기관, 그리고 금융권과 대기업 등 모든 분야에서 클라우드 전환이 가속화되고 있습니다. 이에 따라서 가트너(Gartner)는 2018년 약 2.1조 원이었던 국내 클라우드 시장 규모가 2024년에는 약 '6조 원'에 이를 것으로 내다봤습니다. 。。。。。。。。。。。。 1. 클라우드 전환 단계 ▪초창기: 소규모 Workload가 시범적으로 전환되는 시기 ▪과도기: 인프라, 네이티브 앱 등 주요 Workload가 전환되는 시기 ▪정착기: 모든 Workload가 클라우드에서 개발/구축되는 시기 클라우드 전환은 크게 세 단계로 나누어서 진행됩니다. 대부분의 기업과 기관이 현재 '클라우드 전환 과도기'에 접어든 가운데, 몇 가지 작지 않은 이슈로 인한 어려움을 겪고 있습니다. 2. 클라우드 송환? 클라우드에서 On-Premise로 복귀?! IDC는 최근, "향후 2년 내 프라이빗 클라우드(Private Cloud) 또는 비 클라우드 환경으로의 이전을 계획하고 있는 기업의 비중이 70%가 넘는 것으로 나타났으며, 이러한 현상은 더욱 심화될 전망이다"라고 발표했습니다. '클라우드 송환(Cloud Repatriation)'이라고도 부를 수 있는 이 같은 현상은, 주로 클라우드의 높은 비용·성능 문제·보안 및 규제·공급자 Lock-in 등이 주요 원인으로 지적되고 있습니다. 이와 같은 클라우드 전환 과도기에서의 어려움을 극복하고 효율성을 높이기 위해, '하이브리드 클라우드'로의 전환이 새로운 트렌드로 자리 잡았습니다. 3. 유연하게 활용한다! ‘하이브리드 클라우드’로의 전환 트렌드 하이브리드 클라우드(Hybrid Cloud)는 퍼블릭·프라이빗 클라우드와 대형 IDC 센터와 같은, 온프레미스(On-Premise) 환경을 조합하여 사용하는 것을 말합니다. ⓒ디지털 서비스 이용 지원 시스템 현재 87% 이상의 기업이 2가지 이상의 멀티 클라우드를 사용하며, 72% 이상은 하이브리드 클라우드를 사용하는 것으로 나타났습니다. 하이브리드 클라우드의 장점 ▪다양한 환경을 조합하여 유연하게 리소스를 확장하거나 축소 가능 ▪민감정보를 프라이빗 클라우드에 유지하여 보안성 강화 ▪서로 다른 클라우드 환경의 장점의 조합 및 활용 가능 하이브리드 클라우드는 위와 같은 분명한 장점이 있기에, 계속해서 많은 기업과 기관이 사용할 것으로 예상됩니다. 하지만 하이브리드 클라우드도 반드시 극복해야 할 한계와 문제점이 있습니다. 하이브리드 클라우드의 한계는 크게 세 가지로 나눠볼 수 있는데요. 4. 하이브리드 클라우드의 세 가지 한계, 그리고 극복 방안 관리의 복잡성 Complexity On-Premise, 하이브리드 클라우드, 퍼블릭 클라우드 등은 모두 서로 다른 인프라 구성과 특성을 보유하고 있습니다. 따라서 다양한 CSP와 Legacy 시스템 등을 종합적으로 관제하기 위한 모니터링 기술이 필요합니다. 정책의 분산화 Decentralization 각 CSP의 독자적인 기술과 운영환경에 따라, 기업의 IT 인프라 관리 정책이 분산화될 우려가 있습니다. 따라서 서로 다른 API 환경에 대응할 수 있는 중립적인 모니터링 접근 방식이 필요합니다. 서비스 품질 이슈 Quality 이기종 환경에서의 실시간 성능 모니터링 부재로, 서비스 품질 및 성능 문제가 발생할 수 있습니다. 따라서 실시간 상태 및 성능 지표 모니터링을 통한 최적의 프로비저닝 역량 확보가 중요합니다. 결국 하이브리드 클라우드의 세 가지 한계를 극복할 수 있는 '성공적인 모니터링 전략'이 필요합니다. 5. 하이브리드 클라우드 환경에서의 성공적인 모니터링 전략 앞서 살펴본 것처럼 하이브리드 클라우드의 효율을 높이고 한계를 극복하기 위해선, 성공적인 클라우드 & On-Premise 통합 모니터링이 필요합니다. 통합 모니터링을 통해서 다양한 관리 Point를 단일화하고, 일관된 IT 정책을 적용하며, 다양한 관점별 View를 통한 데이터 가시성을 확보할 수 있습니다. 또한 각 환경에 대한 실시간 성능 지표 모니터링과 신속한 장애 감지 및 원인 분석을 통해, 높은 서비스 품질을 유지할 수 있습니다. 주요 Point에 대해서 자세히 살펴본다면 다음과 같습니다. l 단일 Framework 기반의 통합 모니터링 환경 구성 성공적인 모니터링을 위해서는 Public/Private 클라우드와 On-Premise를 아우르는 단일 Framework 기반의 통합 모니터링 환경을 구성해야 합니다. 다양한 환경에 대한 통합 모니터링 시스템을 구축하여, 대시보드와 토폴로지 맵 등을 통해 분산된 IT 리소스와 서비스 정보를 한눈에 볼 수 있어야 하는 것이죠. l 퍼블릭 클라우드 모니터링: 통합 관리 및 운영 가시성 확보 제니우스(Zenius)의 클라우드 서비스 맵 이용 중인 클라우드 서비스 전체 및 개별 단위의 주요 지표 상세 모니터링으로, 가시성을 확보해야 합니다. 이를 통해서 다양한 서비스의 주요 지표를 관리, 이용 서비스 간의 연관관계 관리, 과금(Billing) 관리, 즉각적인 장애 관리를 할 수 있습니다. l 프라이빗 클라우드 모니터링: 개별적인 구성 환경을 고려한 모니터링 각 기업과 공공기관 개별적인 클라우드 구성 환경을 고려하여, 클라우드 인프라 자원을 관리하고 활용도를 높이기 위한 모니터링 전략도 필요합니다. 위의 설명처럼 쿠버네티스(Kubernetes), 컨테이너(Container), SDN 등 프라이빗 클라우드 환경을 구성하는 요소를 다각적으로 관리하여 IT 인프라 자원의 활용도를 향상시켜야 합니다. l MSA 기반 애플리케이션 모니터링 IDC에 따르면 2025년에 출시되는 앱의 90% 이상이 '클라우드 네이티브'로 구현될 전망이라고 합니다. 클라우드 네이티브의 핵심은 'MSA(Micro Service Architecture)' 방법론으로의 전환입니다. 애플리케이션을 효과적으로 실행·배포·활용하기 위한 핵심요소는 'Container'이죠. 따라서 MSA 환경에서의 성공적인 애플리케이션 관리를 위해서는 실시간 모니터링, 분산 시스템 관제, 서비스 수요 변화 대응 이 세 가지가 가장 중요합니다. 위 도표에 정리된 것처럼 컨테이너 기반의 마이크로 서비스 모니터링, 복잡화된 시스템 간 트랜잭션 분석 및 가시화, 오토스케일링 자동 대응을 통한 관제 연속성 확보 전략을 구축한다면 성공적으로 MSA 기반의 애플리케이션 모니터링을 할 수 있습니다. l 레거시 환경 모니터링 마지막으로 On-premise로 자체 보유하고 있는 레거시 장비와 프라이빗 클라우드 장비가 있는 전산실의 성공적인 모니터링을 위해서는, 먼저 On-premise 환경을 고려한 최적의 포인트 솔루션과 통합 플랫폼 기반 모니터링이 확보되어야 합니다. 또한 안정적인 On-Premise 환경 운영을 위해 전산실 부대설비(UPS, 항온 항습기 등), 환경감시(온/습도, 누수 등)에 대한 레거시 환경 맞춤형 관리가 가능해야 합니다. 물리/가상 자원 간의 그룹화 관리 기능, 다양한 자원 간의 이벤트 연관 설정 및 분석 기능도 성공적인 레거시 환경 모니터링을 위한 필수조건입니다. 6. 성공적인 모니터링 솔루션 선택 기준은? 클라우드 전환기, 하이브리드 클라우드 환경에서 성공적인 모니터링을 위한 루션 선택 기준은 1) 기술력이 있는지 2) 검증된 솔루션인지 3) 믿을 수 있는 기업인지 이렇게 세 가지로 정리할 수 있습니다. 하나, 기술력이 있는 솔루션인가? 클라우드와 레거시 통합을 위한 프레임워크 기반의 솔루션인지, 그리고 여러 환경에 존재하는 IT 자원을 통합적으로 가시화할 수 있는지, 변화에 쉽게 대응할 수 있는 사용자 맞춤 설계형 대시보드를 제공하는지를 꼭 살펴봐야 합니다. 브레인즈컴퍼니 제니우스(Zenius)의 퍼블릭 클라우드 서비스 관제 예시 또한 AI 기술을 통해 장애를 사전에 예방하는 제니우스(Zenius) 처럼, 서비스 장애로 인한 손실을 방지하기 위한 사전 장애 감지 및 대응도 지원하는지 꼭 살펴봐야 합니다. 업무 효율과 편의성을 높이기 위한 오토스케일링 자동 대응, 장애/이벤트 오토리커버리 등 운영 자동화 기능도 필수 요소입니다. 둘, 검증된 솔루션인가? 클라우드 서비스 보안인증(CSAP), 마켓플레이스 등록 등 클라우드 환경에서의 성능 검증 절차 등 거친 솔루션인지도 중요하게 살펴봐야 합니다. 또한 다수의 공공기관 및 다양한 산업군에서 사용되고 있는지도 중요한 판단 기준입니다. 셋, 믿을 수 있는 기업의 솔루션인가? 마지막으로 모니터링 서비스를 개발 및 운영한 업력, 재무 상태 안정성, 전문 인력 보유 등으로 지속적인 지원이 가능한 기업의 솔루션인지를 검토해 봐야 합니다. 。。。。。。。。。。。。 브레인즈컴퍼니는 전통적인 IT 인프라 모니터링 시장에서의 경험을 바탕으로, 하이브리드 환경에서의 성공적인 모니터링을 수행하고 있습니다. 이제 필수가 된 클라우드 전환, 제대로 된 솔루션 선택을 통해 성공적으로 진행하시기 바랍니다!
2024.01.18
기술이야기
테라폼(Terraform)의 모든 것, 그리고 AWS EC2 생성하기
기술이야기
테라폼(Terraform)의 모든 것, 그리고 AWS EC2 생성하기
클라우드 환경이 도래하면서 CSP(Cloud Service Provider)에서는 콘솔을 통해 클라우드 자원에 쉽게 접근할 수 있게 되었습니다. 하지만 서비스를 운영하며 발생하는 다양한 이슈를 콘솔에서 전부 관리하기에는 무리가 있습니다. 반복적인 작업과 휴먼에러가 발생하기 때문이죠. 이러한 문제를 한 번에 해결할 수 있는 방법이 바로 IaC(Infrastructure as Code)입니다. 인프라를 코드로 관리하는 컨셉으로, 효율적인 데브옵스와 클라우드 자동화 구축을 위해 ‘꼭’ 필요한 기술로 각광받고 있죠. 그중에서도 ‘테라폼(Terraform)’은 가장 강력한 IaC 도구로 꼽힙니다. “테라폼(Terraform)이란?” 테라폼은 하시코프(Hashicorp) 사에서 Go 언어로 개발한 오픈소스 IaC 도구입니다. 테라폼에서는 HCL(Hashicorp Configuration Language, 하시코프 설정 언어)을 사용해 클라우드 리소스를 선언합니다. *쉽게 설명한다면 코드로서 클라우드 인프라 서버를 더 효율적으로 구축하고, 운영할 수 있는 오픈소스 소프트웨어죠. 따라서 이번 시간에는 테라폼의 기본동작방식, 특장점, 명령어의 종류, 구체적인 활용 예시에 대해서 살펴보겠습니다. 。。。。。。。。。。。。 테라폼의 기본동작방식 테라폼은 Write, Plan, Apply 기본동작방식으로 이루어져 있는데요. Write 단계에서는 HCL 언어로 필요한 리소스를 선언하고, Plan 단계에서는 앞에서 선언된 리소스들이 생성 가능한지 테스트 및 예측 실행을 수행하며, Apply 단계에서는 선언된 리소스들을 CSP에 적용하는 과정을 거칩니다. *쉽게 설명한다면 Write 단계는 코드 기반으로 선언하고, Plan 단계는 코드 기반으로 검토하며, Apply 단계는 코드 기반으로 리소스를 생성하는 것이죠. 테라폼의 기본개념 테라폼의 주요 기본개념이자 구성요소입니다. 전부 필수적인 내용이지만 특히 Resource, Provider, State는 많이 쓰이는 중요 개념이며 하단 예시에도 나오니 꼭 기억해 두세요! 테라폼의 장점 테라폼은 다양한 장점들이 있는데요. 그중 가장 큰 장점은 자동화를 통해 코드 기반으로 서버 운영 및 관리가 가능한 점입니다. 초보자도 쉬운 코드 재사용을 통해, 효율적인 협업이 가능하고 생산성도 향상시킬 수 있죠. 또한 테라폼은 AWS, GCP(구글), Azure(MS), Naver Cloud(네이버클라우드) 등 다양한 환경에서 지원이 가능한데요. 즉 테라폼만으로도 멀티 클라우드 리소스들을 선언하고 코드로 관리할 수 있습니다. 테라폼의 명령어 테라폼에서 자주 쓰이는 명령어입니다. 그중에서도 코드를 통해 실행될 내용을 미리 확인하는 Plan, 코드 기반으로 리소스를 생성하는 Apply, 그리고 상태를 확인하는 State가 핵심 명령어로 많이 사용되고 있습니다. 테라폼의 활용예시 테라폼을 통해 많은 것을 할 수 있지만, 이번 시간에는 테라폼을 이용하여 AWS에 가장 중심이 되는 서비스인 EC2(AWS에서 제공하는 서버)를 생성해 보겠습니다. 또한 제니우스(Zenius) 모니터링까지 살펴봅시다! 우선 앞서 [테라폼의 기본동작방식]에서 설명했던 것처럼 테라폼은 Write, Plan, Apply 단계를 거치게 되는데요. 테라폼 명령어가 어떤 방식으로 쓰이고 반응하는지, 예시를 통해 확인해 볼까요? > Write 단계: Provider 및 Resource 선언하기 Writer 단계에서는 [테라폼의 기본개념]으로 언급된 *Provider, Resource를 코드 기반으로 선언한 부분을 확인할 수 있습니다. > Plan 단계: Terraform plan Plan 단계에서는 *Terraform plan을 통해 검증을 하게 되는데요. 위 사진 하단에 나와있듯 1개가 추가되고, 0개가 변하고 0개가 없어진다는 의미입니다. 이처럼 +을 통해 추가되는 인프라의 상세정보를 확인할 수 있습니다. > Apply 단계: Terraform apply Apply 단계에서는 앞서 구축 계획에 문제가 없다면 *Terraform apply를 통해 검증된 결과를 바탕으로 실제 인프라에 적용하는 단계입니다. apply 명령을 이용하여 리소스를 생성·수정·삭제하는 것이죠. > State로 확인해 보기 State list 명령어를 통해서도 확인해 보니, 1개의 인스턴스(instance, 클래스의 현재 생성된 오브젝트)가 확인 되네요. 앞서 State list 명령어를 통해 생성된 ‘부분’만 확인했다면, 이번에는 State show 명령어를 통해 어떻게 생성이 됐는지 ‘상세’하게 확인해 봅시다. State 명령어뿐만 아니라 State는 terraform.tfstate 파일로도 확인 가능해 인스턴스 Name 또한 비교해 보았습니다. 테라폼을 이용해 최종 목표였던 AWS에 EC2 인스턴스가 잘 생성이 되었는지 확인해 봐야겠죠? *빨간색 네모 박스에 표기되어 있는 것처럼 잘 생성 되었습니다. 여기서 다시 주목할 점은 AWS의 인스턴스를 생성하기 위해선, 여러 가지 절차를 거쳐야 하는데요. 테라폼을 이용하면 ‘코드’ 하나로 바로 생성이 가능하다는 점입니다. 코드 기반으로 서버운영 및 관리의 자동화라는 특장점 또한 다시 한번 상기해 볼 수 있겠죠? 이처럼 인프라 서버를 효율적으로 구축하는 테라폼을 이용하여, AWS에 EC2를 생성해 보았습니다. 하지만 ‘생성’만 중요한 게 아닌, 효율적인 클라우드 인프라 관리를 극대화하기 위해 ‘모니터링’하는 점도 매우 중요한데요. 테라폼처럼 매우 쉽고 효율적인 방법을 소개하겠습니다. 바로 AWS EC2 모니터링이 가능한 클라우드 서비스 모니터링 시스템인 제니우스-CMS(Zenius-CMS) 예시를 통해, 다양한 환경에서 인프라 모니터링을 어떻게 하고 있는지 살펴보겠습니다! Zenius에서 AWS 모니터링하기 Zenius-CMS는 API를 통해 AWS 계정 기반으로 자동 모니터링을 제공하고 있는데요. 테라폼을 통해 AWS에서 EC2가 코드 기반으로 쉽게 생성했던 것처럼, CMS도 간편한 AWS 모니터링 실행이 가능합니다. 위 사진처럼 EC2 클라우드 서버에 대한 성능도 모니터링이 가능하죠. 여기서 새로운 인스턴스를 추가하면, 이 또한 자동으로 모니터링이 됩니다. Zenius-CMS는 EC2뿐만 아니라 RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있는데요. AWS 콘솔에 접속하지 않고도, AWS 주요 성능 지표에 대한 모니터링 추이도 확인할 수 있습니다. 。。。。。。。。。。。。 이번 시간에는 인프라 서버를 효율적으로 구축하는 테라폼에 대해 학습하고, AWS에 EC2를 생성해 보며 활용 예시까지 살펴보았습니다. 또한 제니우스-CMS(Zenius-CMS) 예시를 통해, AWS EC2 모니터링뿐만 아니라 다양한 환경에서 인프라 모니터링 방법을 알 수 있었는데요. 앞으로도 클라우드 환경에서의 인프라 관리뿐만 아니라, 다양한 환경에서의 모니터링이 가능한 제니우스 제품에 많은 관심 부탁드릴게요! 📚참고 자료 모두의 Terraform(테라폼) PART1 - 개념(230313) Terraform(테라폼)이란? 간단 사용기(220711) 테라폼(Terraform) 기초 튜토리얼(200314)
2024.01.11
기술이야기
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
기술이야기
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
지난 포스팅을 통해 정리한 것처럼 CNCF는 클라우드 네이티브 생태계의 활성화를 위해, 다양한 오픈소스 프로젝트를 개발하고 공급하고 있습니다. 또한 프로젝트 채택 단계부터 사용 빈도까지의 성숙도를 관리하기 위한, 프로세스 체계를 보유하고 있는데요. 이번 시간에는 CNCF의 주요 프로세스인 쿠버네티스(K8s), Helm 등과 CNCF 프로세스에 대해서 알아보고자 합니다. 。。。。。。。。。。。。 CNCF 프로젝트 프로세스 2023년 10월 기준으로 약 170여 개의 CNCF 프로젝트가 진행 중인데요. 이들 프로젝트는 성숙도에 따라서 샌드박스(Sandbox), 인큐베이팅(Incubating), 졸업(Graduated)으로 나뉩니다. 성숙도 수준에 대한 평가는 CNCF 위원회 멤버들에 의해서 결정되며, 졸업(Graduated) 단계의 프로젝트로 인정받기 위해서는 3분의 2 이상의 찬성 표가 필요합니다. ▲프로젝트 성숙도 단계 Step1. 샌드박스(Sandbox) CNCF의 새로운 프로젝트가 채택되면 Sandbox 단계에서 시작합니다. 이 단계에서는 프로젝트가 CNCF의 가이드라인과 정책에 부합되는지를 확인하는 절차를 주로 거칩니다. Step2. 인큐베이팅(Incubating) Sandbox를 통과한 프로젝트는 Incubating 단계로 집입하며, 이 단계에서는 프로젝트의 커뮤니티와 기술적 성숙도를 더욱 강화하도록 합니다. 해당 프로젝트의 커뮤니티의 규모와 다양성을 평가하고 기능들의 안정성을 검증합니다. Step3. 졸업(Graduated) Incubating 단계를 성공적으로 통과한 프로젝트는 Graduated 단계로 올라갑니다. 높은 수준의 품질과 안정성이 보장되어야 이 단계에 올라갈 수 있는 거죠. 커뮤니티가 활발하게 유지되고 관련자의 참여가 적극적으로 이루어져야 하며, 실제 사용 사례에서 성공한 경험들이 존재해야 합니다. Step4. 사용 사례 검증 Graduated 프로젝트 중 실제로 다양한 산업에서 사용되고, 기업과 조직이 해당 프로젝트를 많이 채택하는지를 평가하여, 지속적인 성장 가능성과 성숙도를 평가합니다. CNCF에서 관리하는 프로젝트 영역은 꽤 넓고 다양한데요. 애플리케이션 개발을 위한 도구부터 컨테이너 오케스트레이션, 서비스 프로비저닝, 모니터링 도구 등 소프트웨어 개발부터 운영까지를 위한 도구들이 존재합니다. 이제부터는 가장 성공적인 프로젝트인 쿠버네티스를 포함하여, Incubating 단계 이상의 프로젝트를 알아보고자 합니다. CNCF의 주요 프로젝트 쿠버네티스(kubernetes) 쿠버네티스는 CNCF에서 최초로 Graduated 단계에 진입한 프로젝트입니다. 컨테이너 오케스트레이션 기능을 통해, 애플리케이션 컨테이너 기반으로 자동화하고 확장할 수 있는 플랫폼을 제공합니다. A. 컨테이너 오케스트레이션 기능 컨테이너화된 애플리케이션을 자동으로 배포·확장하고 관리하는 기능을 제공합니다. 애플리케이션의 변경이 필요할 경우, 개발자가 애플리케이션을 빠르게 수정 및 배포하고 운영할 수 있게 합니다. B. 스케일링 기능 리소스 사용량이나 사용자 트래픽 증가에 따라 자동으로 애플리케이션을 확장·축소하는 오토 스케일링 기능을 제공합니다. C. 롤백 기능 문제가 발생된 애플리케이션의 경우, 롤백 기능을 제공하여 서비스 장애에 신속히 대응합니다. Helm Helm은 쿠버네티스 환경에서 애플리케이션을 관리하기 위한 도구로 사용됩니다. Helm은 차트라고 불리는 패키지로 애플리케이션을 패키징 하는데요. 이 차트에는 애플리케이션의 설치부터 관리에 필요한 모든 것을 포함합니다. 쉽게 말하면 이 차트라는 기능을 통해 애플리케이션을 탬플릿화하고, 배포하며, 롤백 및 공유하는 역할을 하는 프로젝트입니다. Envoy ▲Envoy를 사용하는 주요 업체 리스트 ⓒenvoyproxy.io Envoy는 클라우드 네이티브 환경에서 애플리케이션의 네트워크 트래픽을 관리하고, 제어하기 위한 프로젝트입니다. 프록시 기능을 수행하고, 클라이언트 서버 간의 통신을 관리하며, 애플리케이션 간의 통신의 보안 향상시킵니다. 여러 애플리케이션 사이에서 부하 분산을 자동화하여 가용성과 성능을 향상시킬 수 있도록 합니다. 부하 분산을 함에도 불구하고 특정 시스템에 부하가 생겨 장애 발생이 생길 경우, 트래픽을 가중치에 따라 다른 시스템으로 분산시키는 역할을 합니다. Containerd Containerd는 쿠버네티스 환경에서 컨테이너를 만들고 실행하는 데 도움을 주는 프로젝트입니다. 개발자가 컨테이너를 만들고 실행시키는 역할을 하며, 필요할 때는 중지하거나 삭제하는 작업을 지원합니다. 컨테이너 실행에 필요한 파일과 설정을 모아 놓은 이미지를 다운로드하고, 저장하며, 불러오는 역할과 같은 이미지 관리 기능도 제공하고 있습니다. Prometheus Prometheus는 시스템이나 애플리케이션의 동작을 실시간으로 모니터링하고, 이상 상황이 발생할 경우 알림을 줄 수 있는 도구입니다. 다양한 데이터를 수집하고 기록하여 차후 분석 용도로 활용할 수 있습니다. 또한 핵심 지표들을 유형 및 종류별로 제공하여, 다각적인 관점에서의 관찰을 지원합니다. 시스템의 리소스부터 애플리케이션의 동작 및 응답 상태를 적시에 확인하게 해줍니다. Fluentd ▲Fluentd 개념 설명 ⓒfluentd.org Fluentd는 다양한 시스템에서 발생되는 로그 데이터를 수집·처리·전송하는 데이터 수집 도구로서, 스플렁크(SPLUNK)와 유사한 역할을 수행하는 프로젝트입니다. 다양한 소스에서 발생되는 로그를 수집할 수 있을 뿐만 아니라, 원하는 목적지의 저장소까지 전송하는 역할을 수행합니다. 예를 들어 Syslog 등을 실시간 수집하고, 이를 Elasticsearch나 Amazon S3 등의 원하는 저장소로 목적지를 설정할 수 있게 합니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼, CNCF에서 클라우드 네이티브 생태계 활성화를 위해 다양한 프로젝트를 진행하고 있는데요. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능 등을 속속 출시하고 있습니다. 대표 제품인 제니우스(Zenius)를 통해 클라우드 네이티브의 핵심요소인 컨테이너(Docker)의 상태와 리소를 실시간으로 모니터링할 수 있습니다. MSA 환경을 만들기 위한 필수 도구인 쿠버네티스(K8s)의 Cluster·Node·Pod 등의 구성과 변화를 관찰하며, 이상 상황 알림을 통해 선제적 장애 대응 또한 가능합니다. Zenius에 대해 더 자세히 알고 싶으시다면, 바로 아래 링크를 클릭해 주세요! 🔍더보기 Zenius로 클라우드 네이티브 모니터링하기 CNCF 세 가지 핵심가치(1탄)도 있어요
2024.01.03
기술이야기
클라우드 네이티브의 핵심! 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
기술이야기
서버 모니터링의 두 가지 방식
기술이야기
서버 모니터링의 두 가지 방식
이번 블로그에서는 일반적으로 서버 모니터링 소프트웨어들이 널리 쓰고 있는 서버 모니터링의 두 가지 방식에 대해서 논의하고 그 차이점을 알아보겠습니다. 지난 블로그에서 언급했듯이, 서버 모니터링은 컴퓨터 서버의 성능을 관찰하고 분석해 최적의 상태로 실행되고 있는지 확인하는 작업입니다. 이 프로세스에는 일반적으로 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
기술이야기
옵저버빌리티 향상을 위한 제니우스 대표 기능들
기술이야기
옵저버빌리티 향상을 위한 제니우스 대표 기능들
이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다.
2023.04.19
기술이야기
클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로
기술이야기
클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로
다시 온프레미스로 복귀하려는 움직임 2022년 발표된 IDC 조사 결과에 의하면, 미국 기업의 71%가 향후 2년내에 ‘클라우드 송환’ 계획이 있다고 합니다. 실제 일부 애플리케이션을 클라우드에서 빼내 자체 데이터센터로 다시 가지고 오는 기업이 늘고 있습니다. 우리나라의 경우 ‘클라우드 전환’이 업계의 화두가 되고 있지만, 클라우드 전환을 10년 넘게 경험하고 있는 미국의 경우에는 이제 ‘클라우드 송환’이 또 다른 화두가 되고 있습니다. 클라우드 송환(Cloud repatriation)은 기업이 클라우드 환경에서 운영하던 애플리케이션, 데이터, 서비스 등을 온프레미스 환경으로 되돌리는 것을 말합니다. 이는 퍼블릭 클라우드가 비즈니스 민첩성을 향상시킬 수 있지만, 특정한 상황에서 온프레미스보다 퍼블릭 클라우드의 지출 비용이 더 크다는 사실을 기업이 깨달으면서 해당 애플리케이션 등을 온프레미스로 복귀시키려는 IT 전략입니다. 클라우드 송환 현상은 IT 비용과 성능을 비롯한 여러 측면에서 클라우드가 항상 최선의 해결책은 아니라는 인식을 바탕으로 확대되는 추세이며 이제 기업이 비용, 성능, 보안의 극대화를 위해 기존 환경과 새로운 환경 사이에서 자연스러운 워크로드 분산을 시작했다는 의미이기도 합니다. 미처 몰랐던 클라우드 서비스의 문제점 클라우드를 채택한 기업이 클라우드 송환을 선택하는 이유는 다음과 같은 문제가 있기 때문입니다. 첫째, 클라우드 비용 문제입니다. 2022년 클라우드 현황(Flexera 2022 State of the Cloud Report) 보고서에 따르면, 클라우드 비용의 30% 정도가 낭비되고 있습니다. 클라우드 서비스가 표면적으로 내세우는 클라우드의 가장 큰 장점이 비용 절감임에도 불구하고, 클라우드 전환 OPEX(operational expenses)가 기존 CAPEX(capital expenses) 대비 더 낫다고 단정하기 어렵습니다. 초기에는 클라우드의 비용이 저렴하게 느껴지지만, 가상머신(VM)과 컨테이너 인스턴스에서 처리하는 작업이 늘어날수록 비용도 더해지기 때문입니다. 워크로드가 증가하는 스타트업은 클라우드를 통해 유연성을 확보하는 것이 비용면에서 유리하겠지만, 예측 가능한 수준의 워크플로우를 갖고 있는 기업이라면 얘기가 달라집니다. 특히, 클라우드에서는 인터넷 대역폭 및 스토리지 요금 등 추가적인 비용이 발생할 수 있습니다. 둘째, 보안 문제입니다. 기업은 클라우드 제공자가 제공하는 기본적인 보안 기능 외에도 보안 문제에 대한 책임을 직접 지게 됩니다. 또, 기업은 자체 보안 정책을 준수해야 하며, 이를 클라우드 환경에 적용하는 것이 쉽지 않습니다. 특히 복잡한 멀티클라우드 환경에서는 견고하게 클라우드 보안 아키텍처를 구축하기 어렵고 외주 처리에 따라 많은 비용이 듭니다. 셋째, 성능 문제입니다. 클라우드에서는 다른 기업과 리소스를 공유하기 때문에 성능 문제가 발생할 수 있습니다. 또, 클라우드 환경에서 애플리케이션 및 데이터를 조작하는 데 필요한 대역폭이 충분하지 않을 경우 성능 문제가 발생할 수 있습니다. 따라서 기업은 성능 문제로 인해 클라우드 송환을 선택할 수 있습니다. 넷째, 제어 문제입니다. 클라우드에서는 기본적으로 클라우드 제공자가 인프라 관리와 보안을 담당합니다. 이는 기업이 클라우드 환경에서는 많은 경우 애플리케이션, 데이터, 서비스 등을 직접 제어할 수 없다는 것을 의미합니다. 따라서, 기업이 직접 컨트롤하지 못해서 문제가 발생한다고 느낄 때에는 클라우드 송환을 선택할 수 있습니다. 클라우드 송환의 이점 클라우드 송환(Cloud repatriation)은 기업에게 여러 가지 이점을 제공합니다. 첫째, 기업은 애플리케이션, 데이터, 서비스 등을 직접 관리할 수 있습니다. 이는 기업이 보안 및 규정 준수와 같은 중요한 문제를 직접 다룰 수 있도록 해주며, 제어력을 높임으로써 IT 부서가 잠재적 문제에 대비해 인사이트와 더 나은 계획을 수립할 수 있게 해줍니다. 클라우드에서는 기본적으로 클라우드 제공 업체가 인프라 관리와 보안을 담당하기 때문에, 이를 직접 제어할 수 없습니다. 클라우드 송환에 적합한 케이스는 정적인 기능을 제공하며 사용량이 많은 애플리케이션입니다. 비용이 고정되고 예측 가능한 애플리케이션은 온프레미스 환경에서 관리하는 편이 더 효과적입니다. 둘째, 기업은 클라우드 비용을 절감할 수 있습니다. 한때 퍼블릭 클라우드가 모든 문제의 해답이라고 생각했다가 퍼블릭 클라우드의 비용 특성과 이점이 기업의 상황과는 맞지 않는다는 사실을 깨닫게 됩니다. 2~3년에 걸쳐 추가되는 비용을 감안하면 퍼블릭 클라우드를 계속 사용할 만한 매력은 시간이 갈수록 희석됩니다. 기업은 반복적으로 발생하는 클라우드 운영 비용을 줄이거나 없애는 방법으로 많은 비용을 절감할 수 있습니다. 예를 들어, 어떤 기업의 데이터가 여러 사이트에서 발생하고 그 양이 많다면 클라우드 환경에서 데이터를 보관하고 이동시키는 데 많은 비용이 발생할 수 있습니다. 또 다른 예로 영상을 불러오고 저장하는 작업이 빈번한 영상 제작 기업의 경우, 클라우드 서버에서 병목현상이 발생할 수 있고 내부 LAN처럼 10Gbps 속도로 데이터를 옮기려면 그 비용이 저렴하지 않을 수 있습니다. 비용 외에도 데이터 이동에 많은 시간이 소모되며 이로 인해 데이터를 필터링해 최소한의 데이터만 저장해야 하는 불편함이 있습니다. 한편, 메모리와 디스크 리소스 비용이 계속 하락하면서 기업의 온프레미스 투자가 유리해지고 있습니다. 더불어 클래스 메모리 및 SDN(소프트웨어 정의 네트워크)과 같은 비용에 도움을 주는 솔루션을 활용하면, 한때 퍼블릭 클라우드의 큰 매력이었던 유연성, 확장성, 중복성의 간극이 상당부분 사라집니다. 셋째, 기업은 데이터 보호와 백업을 더욱 쉽게 할 수 있습니다. 클라우드 업체도 데이터 프라이버시에 대해 엄격하지만 온프레미스 환경에서 데이터를 저장하고 백업 받고 복구하는 것보다 더 안전할 수 없습니다. 물론 민감한 정보를 로컬 환경에 저장하는 것 역시 문제 제기가 있겠지만 최소한 고객 데이터가 사라졌을 때 무엇을 어떻게 해야 하는지 알 수 있습니다. 규정 준수 측면에서도 각 국마다 개인정보보호 규정이 달라 우발적인 규정 위반 가능성이 있습니다. 이러한 우려를 줄이는 방법은 애플리케이션을 특정 위치의 온프레미스 환경에서 실행하는 것입니다. 넷째, 대역폭 문제에서 자유로운 장점이 있습니다. 클라우드 환경에서 빅데이터 시스템을 활용하는 기업은 빅데이터 시스템에서 생성되는 데이터가 높은 대역폭을 요구하면서 자사 데이터 센터보다 훨씬 더 많은 운용 비용을 지불합니다. 컴퓨팅은 온디맨드이므로 탄력적인 클라우드가 유리할 수 있지만 스토리지는 매일 매초 비용이 계속 증가하고 있는 사실을 알아야 합니다. 클라우드냐 온프레미스냐 고려할 점 클라우드 송환은 비용면에서 매력적이지만 매우 도전적인 과제입니다. 클라우드 서비스 공급자는 일반적으로 클라우드에서 빠져나오기 상당히 어렵게 계약하고, 해체됐거나 아예 존재하지 않던 온프레미스 환경을 준비하기 위해 기업의 재무와 조직 운영에 큰 영향을 미치기 때문입니다. 게다가 애플리케이션을 온프레미스 데이터센터로 마이그레이션하는 경우 기업은 클라우드의 확장성, 유연성, 가용성, 탄력성을 유지하기 힘들고 자체 데이터센터가 클라우드에 비해 더 안전하다는 보장을 하기도 어렵습니다. 따라서 이런 경우에는 애플리케이션에서 실행 중인 환경에 대한 종속성이 있는 부분과 단순히 데이터를 관리하는 부분을 분리하면 혼란을 최소화할 수 있습니다. 처음부터 클라우드 환경을 고려해 서비스를 설계했다면, 워크로드를 다시 데이터센터로 되돌리기 위해서는 어느 정도의 재설계가 필요하며 빅데이터에 의존하는 기업은 상당한 마이그레이션 작업을 각오해야 합니다. 이처럼 클라우드 송환은 매우 어려운 과제입니다. 따라서 처음부터 워크로드를 퍼블릭 클라우드로 이전하는데 매우 신중한 입장을 취하는 것이 가장 중요합니다. 그래서 최근에는 기업들이 클라우드 환경을 고수하는 것보다는 필요한 경우 클라우드와 온프레미스 환경을 융합하는 하이브리드 클라우드 전략을 선택하는 경향이 있습니다. 모든 서비스를 클라우드로 전환하는 것이 아니라, 단기간에 트래픽이나 사용자가 급속히 늘어날 가능성이 있거나, 클라우드 서비스를 활용해 서비스를 빠르게 런칭해야 하는 경우로 한정하는 것이 필요합니다. 우리나라에서도 많은 기업들이 이미 클라우드가 갖고 있는 단점들을 경험하고 온프레미스로 전환하고 있습니다만, ‘클라우드 전환’이라는 큰 물결 아래 ‘클라우드 송환(Cloud Repatriation)’에 대한 논의는 제한적입니다. 우리나라의 클라우드 전환율이 세계시장과 비교해 볼 때 현저히 낮지만, 오히려 클라우드 환경의 문제를 이미 경험한 나라들의 교훈을 미리 받아들인다면 학습비용을 줄일 수 있을 것으로 기대합니다. Zenius-EMS는 고객들이 레거시 시스템에서부터 클라우드 네이티브 시스템에 이르기까지 다양한 관점의 서버모니터링을 할 수 있도록 지원합니다. 대규모 인프라가 존재하는 데이터센터 및 클라우드 환경에서 대용량 데이터 처리에 대한 높은 성능을 확인할 수 있습니다. 고유의 특허 기술을 통해 수천대의 장비에서 발생되는 데이터들을 안정적으로 수집하고 빠르게 처리할 수 있습니다. [출처] John Edwards, "클라우드의 온프레미스 송환이 타당한 5가지 경우", IT WORLD, 2019.04.16 Steven J. Vaughan-Nichols, "모두가 '클라우드' 외칠 때 '로컬 서버' 선택해야 하는 이유, IT WORLD, 2022.07.27 Andy Patrizio, "기업 71%, 2년 이내 클라우드에서 온프레미스로 복귀할 것", IT WORLD, 2022.06.29 Clint Boulton, "'전진 위한 후퇴'··· 클라우드서 온프레미스로 송환하는 기업들", CIO Korea, 2020.03.30 Brian Adler, "Cloud Computing Trends: Flexera 2022 State of the Cloud Report", flexera, 2022.03.21
2023.04.07
기술이야기
서버 모니터링 트렌드 살펴보기
기술이야기
서버 모니터링 트렌드 살펴보기
기업이나 조직의 IT 인프라 모니터링은 서버 모니터링에서 출발합니다. 통상적으로 서버 모니터링부터 네트워크, 데이터베이스, 웹애플리케이션, 전산설비 등으로 모니터링의 범위를 확장해 나가는 것이 일반적입니다. 서버는 초창기 메인 프레임부터 유닉스 서버, 리눅스 서버를 거쳐 최근의 가상화 서버에 이르기까지 물리적 및 논리적으로 그 성격이 변화해 왔습니다. 그에 따라 서버 모니터링의 관점도 많이 변모해 왔습니다. 기껏해야 1~2대 규모로 운영하던 메인 프레임의 시대와 수천, 수만대의 서버팜을 관리해야 하는 시대의 모니터링 개념은 달라야 합니다. 또, 가상화 시대를 맞아 물리적 서버 개념보다는 논리적 서버 개념이 중요해지고, 서버 1~2대의 장애 상황보다는 서버팜이 이루고 있는 서비스의 영속성이 중요해졌습니다. 이처럼 서버라는 인프라가 기술 발전에 따라 변모하고 있고, 그에 대응해 모니터링 콘셉트나 방법도 변화하고 있습니다. 이번 블로그에서는 서버 관련 새로운 인프라 개념 및 기술들이 대두되면서 변화하는 서버 모니터링의 새로운 트렌드에 관해 논의해 보고자 합니다. 1. 클라우드 네이티브 모니터링 더 많은 기업이나 조직이 전통적인 레거시 시스템에서 클라우드로 이동함에 따라 클라우드 모니터링의 필요성이 급격히 증가했습니다. 클라우드 네이티브 모니터링 도구는 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)과 같은 클라우드 환경에서 애플리케이션과 클라우드 인프라를 모니터링하도록 설계됐습니다. 또, 클라우드 인프라의 성능, 가용성 및 보안에 대한 실시간 인사이트를 제공해, IT운영부서가 문제를 신속하게 발견하고 해결할 수 있도록 지원합니다. 일반적인 클라우드 모니터링은 메트릭과 로그를 사용해 클라우드 인프라 및 애플리케이션 성능을 하나의 통합된 화면에 제공합니다. 또한 통합 IT 환경 측면에서는 컨테이너 오케스트레이션 플랫폼 및 서버리스 컴퓨팅과 같은 다른 클라우드 환경과 통합해 모니터링할 수도 있습니다. 클라우드 기반 모니터링의 최신 추세는 하이브리드 모니터링입니다. 조직은 하이브리드 모니터링을 통해 클라우드와 온프레미스에서 각각 실행 중인 서버 및 애플리케이션 모두를 단일 플랫폼에서 모니터링할 수 있습니다. 2. 인공지능과 머신러닝 서버 모니터링의 또 다른 트렌드는 인공 지능(AI)과 머신 러닝(ML)을 사용해 모니터링 과정을 자동화하는 것입니다. AI 및 ML 알고리즘은 모니터링 과정에서 생성된 방대한 양의 데이터를 분석하고 패턴을 식별해 이상 징후를 감지할 수 있습니다. 이는 실시간으로 수행될 수 있으므로 운영관리자는 발생하는 모든 문제에 신속하게 대응할 수 있습니다. ML 알고리즘은 과거 데이터를 분석해 트래픽이 가장 많은 시기나 잠재적 장애와 같은 미래 추세를 예측할 수 있습니다. 이를 위해 서버의 성능과 관련된 대규모 데이터 세트에서 ML 알고리즘을 교육해야 합니다. 이 데이터는 서버 로그, 시스템 메트릭, 애플리케이션 로그 및 기타 관련 정보가 해당됩니다. 다음으로 알고리즘을 학습해 다양한 메트릭 간의 패턴과 상관 관계를 식별하고 이상 징후와 잠재적 문제를 감지합니다. 머신 러닝 모델이 훈련되면 서버를 실시간으로 모니터링하도록 배포할 수 있으며, 모델은 지속적으로 서버 메트릭을 분석하고 이를 학습한 패턴과 비교합니다. 편차나 이상을 감지하면 문제를 해결하기 위해 경고 또는 자동화된 작업을 트리거할 수 있습니다. 예를 들어, 트래픽이 갑자기 증가하는 경우 리소스를 자동으로 Scaling 하거나 다운 타임을 방지하기 위해 다른 조치를 취할 수 있습니다. 전반적으로 인공 지능과 머신 러닝을 사용해 서버 모니터링을 자동화하면, 문제해결에 시간을 절약하고 인적 오류의 위험을 줄일 수 있습니다. 또, 심각한 문제로 번지기 전에 잠재적 문제를 식별해 서버 인프라의 전반적인 안정성과 가용성을 향상할 수 있습니다. 3. 컨테이너 모니터링 컨테이너가 애플리케이션 배포에 점점 더 많이 사용되면서, 컨테이너 모니터링은 서버 모니터링의 중요한 측면이 됐습니다. 컨테이너란 애플리케이션을 모든 인프라에서 실행하는데 필요한 모든 파일 및 라이브러리와 함께 번들로 제공하는 소프트웨어 배포 도구입니다. 컨테이너를 사용하면 모든 유형의 디바이스 및 운영 체제에서 실행되는 단일 소프트웨어 패키지를 만들 수 있습니다. 뿐만 아니라, 단일 시스템에서 한 컨테이너는 다른 컨테이너의 작업을 방해하지 않으므로 확장성이 뛰어나고, 결함이 있는 서비스가 다른 서비스에 영향을 주지 않아 애플리케이션의 복원력과 가용성이 향상되는 장점이 있습니다. 컨테이너 모니터링은 CPU 및 메모리 사용량과 같은 컨테이너 리소스 사용률에 대한 실시간 메트릭을 제공할 수 있습니다. 또, 애플리케이션이 의도한 대로 실행되고 있는지 확인하기 위해 Kubernetes(쿠버네티스)와 같은 컨테이너 오케스트레이션 플랫폼을 모니터링하고, 컨테이너 및 기본 인프라에 대한 실시간 가시성을 제공합니다. 4. 서버리스 모니터링 서버리스 컴퓨팅은 사용량에 따라 백엔드 서비스를 제공하는 방법으로, 개발자가 서버를 관리할 필요없이 애플리케이션을 빌드하고 실행하는 것을 가능하게 합니다. 서버리스 컴퓨팅은 벤더 종속성(Vendor lock-in), 콜드 스타드와 DB백업이나 영상 인코딩 등 단시간에 많은 컴퓨팅 용량이 필요한 경우, 효율적이지 않음에도 불구하고 최근 몇 년 동안 주목을 받아오며 서버리스 모니터링이 서버 모니터링의 새로운 트렌드가 됐습니다. 서버리스 모니터링은 CPU, 메모리, 디스크 사용량 등 리소스 사용률, 애플리케이션 성능, 호출 시간 및 오류율과 같은 기능 성능에 대한 실시간 인사이트를 제공합니다. 서버리스 모니터링은 데이터베이스 쿼리 성능과 같은 서버리스 함수의 종속성에 대한 인사이트도 제공합니다. 5. 마이크로서비스 모니터링 마이크로서비스는 하나의 큰 애플리케이션을 여러 개의 작은 기능으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처로, 각 서비스를 다른 서비스와 독립적으로 개발, 배포 및 확장할 수 있는 장점이 있습니다. 하지만 마이크로서비스는 일반적으로 분산된 환경에 배포되므로 성능을 추적하고 문제를 찾아내기가 어렵고, 독립적으로 설계됐으므로 호환성에 어떤 문제가 있는지 감지할 필요가 있어 마이크로서비스 모니터링이 필요합니다. 마이크로서비스 모니터링은 개별 마이크로서비스 및 전체 애플리케이션의 성능과 상태를 추적하는 프로세스로 로그, 메트릭 및 트레이스와 같은 다양한 소스에서 데이터를 수집하고 분석해 문제를 식별하고 성능을 최적화하는 작업입니다. 마이크로서비스 모니터링은 각 마이크로서비스 별 가용성, 응답 시간, 가동 시간, 지연 시간, 오류율을 포함합니다. CPU, 메모리, 디스크 사용량과 같은 리소스 사용률을 추적해 잠재적인 성능 병목 현상이나 리소스 제약을 식별할 수 있고, 마이크로서비스 간의 데이터 흐름을 추적하고 서비스 간의 종속성 추적을 모니터링합니다. 또, 마이크로서비스 모니터링은 애플리케이션 전체의 전반적인 상태와 성능뿐만 아니라 타사 서비스 및 API의 성능과 상태도 모니터링할 수 있습니다. ----------------------------------- 브레인즈컴퍼니는 꾸준히 연구개발에 매진해 상기와 같은 새로운 트렌드를 반영한 Zenius-EMS를 개발, 출시했습니다. Zenius-EMS는 고객들이 레거시 시스템에서부터 클라우드 네이티브 시스템에 이르기까지 다양한 관점의 서버모니터링을 할 수 있도록 지원합니다. *이미지 출처: Unsplash, flaction
2023.03.29
기술이야기
Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기
기술이야기
Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기
옵저버빌리티는 "무슨 일이 일어났는가?", "왜 그런 일이 일어났는가?"와 같은 질문에 답하는 것을 목표로 합니다. 옵저버빌리티는 IT시스템 전체적인 관점에서 문제를 신속하게 식별하고 근본 원인을 분석할 수 있습니다. 최근 IT 인프라의 종류가 다양해지고, 수가 기하급수적으로 많아지고, 복잡도가 급격히 증가함에 따라 IT 인프라의 가용성을 보장하기 위해서 전통적으로 행해지던 모니터링의 범주를 넘어서는 옵저버빌리티라는 개념이 등장했습니다. 모니터링과 옵저버빌리티라는 두 용어들은 때로는 비슷한 개념으로 서로 바꿔서 사용되기도 하지만, 시스템 관리에 대한 다른 접근 방식을 나타냅니다. 이번 블로그에서는 모니터링과 옵저빌리티의 차이점을 알아보겠습니다. Monitoring이란? 모니터링은 IT 시스템에서 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 데이터를 수집하고 분석해 성능과 동작을 파악하는 것입니다. 모니터링의 목표는 시스템에 문제가 있는 것으로 추정되는 이상한 동작이나 조건을 감지하고 경고하는 것입니다. 모니터링은 종종 문제를 나타낼 수 있는 특정 메트릭이나 이벤트에 대한 알람 설정을 포함합니다. 이 접근 방식은 일반적으로 예측 가능한 개별 시스템에 사용합니다. 전통적인 모니터링 방법은 일정한 간격으로 수집되는 사전 정의된 메트릭이나 로그에 의존합니다. 예를 들어, 서버의 CPU 사용량을 1분마다 확인하고 사용량이 특정 임계값을 초과하면 알람을 보낼 수 있습니다. 이러한 방식은 특정 유형의 문제를 감지하는 데 효과적이지만, IT 시스템 동작을 전체적으로 파악하거나 근본 원인 분석에 대한 심층적인 인사이트는 제한적일 수 있습니다. Observability란? 옵저버빌리티는 IT 시스템 관리에 대한 새로운 접근 방식으로, 시스템의 내부 동작을 이해하는 것에 중점을 둡니다. 옵저버빌리티의 목표는 시스템의 동작을 깊이 이해하고 발생 가능한 모든 문제의 근본 원인을 파악하는 것입니다. 옵저버빌리티는 메트릭, 추적, 로그 등을 실시간으로 수집하고 분석하는 것을 포함합니다. 참고로 메트릭은 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 시스템 성능과 관련된 정량적 정보를, 추적은 요청의 호출 순서 및 응답 시간과 같은 시스템 동작에 대한 정보를, 로그는 사용자 작업 및 오류를 포함해 시스템 활동을 제공합니다. 옵저버빌리티가 필요한 이유 옵저버빌리티는 복잡하고 동적인 시스템에서는 문제를 빠르게 찾고 해결하기 위해 시스템의 동작과 성능을 측정하고 분석할 필요가 있습니다. 옵저버빌리티를 통해 다음과 같은 이점을 얻을 수 있습니다. 옵저버빌리티가 필요한 이유 1. 문제 해결 속도 향상: 옵저버빌리티를 사용하면 복잡한 시스템에서 발생하는 문제를 더욱 빠르게 파악할 수 있습니다. 이를 통해 시스템 장애나 성능 저하와 같은 문제를 빠르게 해결할 수 있습니다. 2. 전체 시스템 이해도 증가: 옵저버빌리티를 사용하면 전체 시스템의 내부 동작을 쉽게 이해할 수 있습니다. 이는 문제를 예방하거나 빠르게 대처할 수 있도록 도와줍니다. 3. 대규모 시스템 관리 가능: 대규모 분산 시스템에서는 옵저버빌리티가 필수적입니다. 이를 통해 수많은 서버, 네트워크, 애플리케이션 등에서 발생하는 다양한 데이터를 수집하고 분석할 수 있습니다. 4. 문제 예방 및 최적화: 옵저버빌리티를 사용하면 시스템의 성능을 지속적으로 모니터링하고 문제를 예방할 수 있습니다. 또한 시스템의 최적화를 위해 데이터를 분석하고 개선할 수 있습니다. 따라서, 옵저버빌리티는 복잡한, 여러 개의 세분화된 시스템으로 구성된 전체 시스템에서 필수적인 도구로, 시스템의 성능 개선과 장애 대응 등 다양한 측면에서 가치를 제공합니다. Monitoring vs Observability 모니터링과 달리, 옵저버빌리티는 사전에 정의된 메트릭과 알람에 의존하는 대신, 시스템 동작의 더욱 전체적인 관점을 제공합니다. 옵저버빌리티는 여러 소스에서 수집한 데이터를 같이 분석함으로써 쉽게 찾을 수 없는 어떤 패턴과 상관관계를 발견하는 데 도움을 줄 수 있습니다. 이 접근 방식은 예측할 수 없는 동작을 가진 복잡한 시스템에서 특히 유용합니다. 모니터링과 옵저버빌리티의 또 다른 중요한 차이점은 사람의 개입 수준입니다. 모니터링은 특정 이벤트 또는 조건을 감지하고 해당 이벤트 또는 조건이 발생할 때 경고를 트리거하도록 설계되므로 모니터링을 설정하고 구성하는데 사람의 개입이 필요할 수 있지만 일단 도구가 셋업되면 사람의 개입 없이 자동으로 작동하는 편입니다. 반면에, 옵저버빌리티는 데이터를 해석하고 결정을 내리고 조치를 취하는데 IT 운영자의 전문 지식을 사용해 프로세스에 관여합니다. 이러한 접근 방식은 시간이 더 많이 소요될 수 있지만, 문제의 근본 원인에 대한 더 많은 인사이트를 제공할 수도 있습니다. 올바른 어프로치 선택하기 모니터링과 옵저버빌리티는 각각 장단점이 있으며, 시스템의 특정 요구사항에 따라 어떤 접근 방식을 선택할지 달라져야 합니다. 비교적 상황 파악이 어렵지 않은 간단한 시스템의 경우, 전통적인 모니터링 도구로 충분할 수 있습니다. 그러나 복잡하고 시스템이 분산된 경우, 시스템 동작을 완전히 이해하기 위해 옵저버빌리티가 필요할 수 있습니다. 결국, 효과적인 시스템 관리의 핵심은 문제를 빠르게 감지하고 해결하기 위한 적절한 도구와 프로세스를 갖추는 것입니다. 모니터링 또는 옵저버빌리티를 선택하든, 시스템과 조직의 요구에 부합하는지 정기적으로 검토하고 개선하는 것이 중요합니다. 적절한 도구와 프로세스에 투자함으로써, 시스템의 신뢰성과 성능을 개선하고 비용이 많이 드는 다운타임과 서비스 중단을 피할 수 있습니다. Zenius EMS 브레인즈컴퍼니는 20년 이상 축적된 노하우를 바탕으로 레거시 환경은 물론 최근 더욱 복잡해지고 있는 클라우드 네이티브 시스템까지 모니터링과 옵저버빌리티 모두를 제공함으로써 고객이 원하는 방식으로 사용이 가능합니다. Zenius EMS는 SMS, NMS, APM 등 각 인프라별 모니터링을 통합해 시스템을 더욱 안정성 있게 관리하고 자동화된 장애대응 환경을 제공하며 객관적인 데이터 기반으로 리포팅이 가능한 지능형 IT 성능 모니터링입니다. 또한 쿠버네티스, 오픈 스택을 지원하는 클라우드 환경을 모니터링합니다. 국내 공공분야 관제 SW 1위, 제니우스의 상관관계 분석, 인공지능을 활용한 성능예측 등 옵저버빌리티 기술을 통해 다양한 시스템 레이어에서 성능, 장애, 구성에 대한 인사이트를 얻으시기 바랍니다.
2023.03.28
1
2
3
4