반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
스토리지 관리
예방 점검
APM Solution
애플리케이션 관리
URL 관리
브라우저 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
AI 인공지능
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
브레인즈컴퍼니 ‘2023 소프트웨어대전’ 참가
클라우드(Cloud) 관리와 AWS가 뭔가요?
이운형
2023.11.16
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 전략사업본부 ‘happy 호프데이’
오늘날 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와 온프레미스 환경은 물론, 더 다양한 환경의 인프라 모니터링을 위해 제니우스를 사용을 해보는 건 어떨까요?
#클라우드
#AWS
#Cloud
#브레인즈컴퍼니
#클라우드컴퓨팅
#제니우스
#AWS클라우드
#하이브리드클라우드
이운형
Technical Consulting팀
Technical Consulting팀에서 제품구축과 유지보수 업무를 수행하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
브라우저 모니터링 시스템(Zenius BRMS) 개발기
브라우저 모니터링 시스템(Zenius BRMS) 개발기
IT 시스템은 날이 갈수록 복잡해지고 있습니다. 모놀리식 아키텍처는 유연한 마이크로서비스(MSA)로 분화되었고, 정적인 서버 환경은 컨테이너와 서버리스 기반의 클라우드 네이티브로 빠르게 전환되었습니다.이러한 변화 속에서 DevOps 문화의 확산과 함께 시스템 전체의 상태를 파악하는 '옵저버빌리티(Observability)'의 중요성은 그 어느 때보다 커졌습니다. 이러한 배경에서 브레인즈컴퍼니는 고객들이 사용자 경험의 최접점인 웹 브라우저 구간까지 모니터링 범위를 확장하여 서비스 전반의 가시성을 확보할 수 있도록, 브라우저 모니터링 시스템인 'Zenius BRMS(Browser Monitoring System)'를 개발하게 되었습니다. 사용자 행동 추적과 정밀한 체감 성능 분석이 강점인 Zenius BRMS의 핵심 엔진을 구현하기 위한 내용을 정리했습니다. 우리만의 아키텍처: 중계 에이전트가 없는 통합 파이프라인 Zenius BRMS는 브라우저 데이터 수집의 핵심 도구로 표준 오픈소스 프레임워크를 채택했습니다. 이는 특정 벤더에 종속되지 않으면서 MSA 및 클라우드 네이티브 환경의 사실상 표준(De Facto Standard)으로 자리 잡은 기술이기 때문입니다. 단순히 데이터를 수집하는 기능을 넘어, 데이터의 생성부터 전송까지 수집 라이프사이클 전체를 아우르는 포괄적인 규격을 갖추었다는 점이 결정적인 도입 배경이 되었습니다. 다만, 표준 아키텍처를 그대로 따르기보다는 운영 환경에 최적화된 구조를 설계하는 데 집중했습니다. 이미 백엔드 데이터 처리의 중추 역할을 하는 자사 매니저가 존재하므로, 이를 최대한 활용하여 전체 구조를 단순화하기로 한 것입니다. 결과적으로 운영 복잡도를 높이는 별도의 오픈소스 수집 에이전트를 중간에 두는 대신, 브라우저에서 수집한 데이터를 자사 매니저로 직접 전송하는 효율적인 통합 파이프라인을 구축했습니다. “애플리케이션 -> 매니저 -> 저장소” 구조로 배치 프로세서를 사용하여 데이터를 수집한 후 매니저로 전송합니다. 이를 통해 외부 프레임워크 관리 포인트를 줄이면서도 자사 솔루션의 강력한 데이터 처리 기능을 활용하여 프로세스를 일원화할 수 있었습니다. NodeJS나 모바일 앱 환경이라도 엔드포인트만 매니저로 지정하면 즉시 연동이 가능한 구조입니다. 이제 이렇게 수집된 데이터를 어떻게 다루고 있는지 살펴보겠습니다. 세션(Session) 정의와 생명주기 수집된 데이터를 분석하기 위해서는 기준이 필요합니다. 우리는 식별 ID를 가진 특정 사용자가 아니라 브라우저에 접근한 행위 자체를 하나의 세션으로 정의했습니다. 따라서 한 명의 사용자라도 상황에 따라 여러 개의 세션을 생성할 수 있습니다. 세션은 무한히 지속될 수 없으므로, 미동작 만료 시간(15분)과 최대 지속 시간(4시간)을 두어 생명주기를 관리합니다. 사용자가 활동을 하면 만료 시간이 갱신되지만 시작 후 15분 이내 동작이 없거나 4시간이 지나면 강제로 만료되는 구조입니다. 세션 정보는 쿠키를 활용하여 데이터 수집시점에 활용합니다. 해시 기반 샘플링 (XOR 연산의 활용) 때에 따라 대량의 데이터를 모두 수집하는 것은 비효율적이므로 샘플링이 필수적입니다. 기존의 샘플링은 단편적인 데이터 손실을 유발했기에 우리는 세션 기준 샘플링을 도입했습니다. 알고리즘 핵심은 균등한 분포(Uniform Distribution)를 만드는 것입니다. 세션 ID(UUID)를 32비트 정수로 변환하여 샘플링에 활용했는데 이 과정에서 AND 연산은 0으로 OR 연산은 최대값으로 수렴하는 경향이 있습니다. 따라서 우리는 비트의 무작위성을 가장 잘 보존하는 XOR 연산을 사용하여 균등한 샘플링 확률을 보장했습니다. 데이터 유실 없는 전송: sendBeacon vs keepalive 조금 더 자세한 가시성 확보를 위해 우리는 세션의 행동이 녹화되는 기능을 추가했습니다. 세션 행동을 녹화하여 전송할 때 가장 큰 문제는 브라우저 닫기 등으로 인한 데이터 유실입니다. 보통 이 시점에 navigator.sendBeacon을 많이 사용하지만 우리는 Fetch API의 keepalive: true 옵션을 선택했습니다. sendBeacon은 헤더 커스터마이징에 제약이 있고 응답 처리가 불가능한 반면 keepalive 옵션은 훨씬 유연한 제어가 가능하기 때문입니다. 64KB 용량 제한 이슈는 전송 주기를 조절하고 자체 용량 체크 로직을 추가하여 해결했습니다. 단순 저장소를 넘어: 다차원 분석을 위한 데이터 아키텍처 전환 Zenius BRMS의 초기 설계에서는 매니저에서 가공된 데이터의 신속한 기록과 실시간 조회를 위해, 입출력 속도가 뛰어난 Key-Value 기반의 인메모리 데이터베이스가 활용되었습니다. 하지만 분석해야 할 데이터 속성이 점차 다차원적으로 고도화되고, 분산된 시스템 간의 정교한 데이터 동기화가 요구되면서 기존 Key-Value 구조를 넘어선 확장성이 필요해졌습니다. 이에 따라 대규모 데이터 검색과 복잡한 집계 연산에 최적화된 검색 엔진 기반 저장소로 아키텍처를 전환했습니다. 특히 데이터 유입 단계의 파이프라인에서 요청-응답 시간(Response Time)과 같은 주요 파생 데이터를 미리 연산하여 저장하는 방식을 도입함으로써, 조회 시점의 연산 부하를 줄이고 데이터 가공 효율을 높였습니다. 단순한 처리 속도를 넘어 데이터의 활용성과 분석의 유연성에 무게를 둔 결과, 보다 심도 있고 다각적인 모니터링이 가능한 분석 환경을 구축할 수 있게 되었습니다. 브라우저에서 실시간으로 수집된 데이터는 자사 매니저를 거쳐 분석 목적에 최적화된 저장소에 안전하게 기록됩니다. 이로써 그간 파악하기 어려웠던 사용자 경험의 최전방인 프론트엔드 구간의 가시성을 확보할 수 있게 되었습니다. 이제 남은 핵심 과제는 "사용자의 클릭 한 번이 백엔드의 구체적인 어떤 쿼리를 유발했는가?"를 단절 없이 연결하는 것입니다. 이러한 전 구간(End-to-End) 추적을 실현하기 위해 서비스 간의 연관 관계를 정의하는 컨텍스트 전파(Context Propagation) 기술을 더욱 고도화할 계획입니다. 나아가 AI 기반의 이상 탐지(AIOps) 기술을 결합하여, 단순한 수치 관찰을 넘어 시스템 스스로 문제를 진단하고 예측하는 진정한 의미의 옵저버빌리티를 완성해 나갈 예정입니다.
2025.12.23
다음 슬라이드 보기