반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
디자인 시스템이 필요한 이유와 핵심요소는?
[전시회] 브레인즈컴퍼니가 소프트웨이브2023에서 주목받은 이유
이화정
2023.12.14
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치
지난번 시간에는
「소프트웨이브2023」
전시회에 브레인즈컴퍼니가 참가하여, 전반적인 현장 스케치를 담았었는데요.
두 번째 이야기에서는
1) 브레인즈컴퍼니와 제니우스(Zenius)를 구체적으로 어떻게 알렸는지 2) 참관객분들의 반응은 어땠는지
를 자세하
게 살펴보려고 합니다.
브레인즈컴퍼니가 참가하여
대성황을 이루었던
소프트웨이브2023
.
그날의 생생한 사진과 리얼한 후기도 있으니 주목해 주세요!
。。。。。。。。。。。。
선근님 인터뷰
국내 바이어 VIP 그룹 투어
전시회 첫날이었던 29일(수), 과기부 장관·국회의원·주요기업 임원진 등 주요 VIP 대상으로 브레인즈컴퍼니를 소개하는 시간이 있었습니다. 소개는 브레인즈 그룹 대표인 선근님께서 진행해 주셨어요!
선근님께서는 브레인즈컴퍼니·에이프리카 회사와 제품 소개를 시작으로,
“앞으로 인공지능(AI)와 클라우드 분야를 선두하는 기업으로 거듭나겠다."
라는 멋진 포부도 밝혀주셨습니다.
이번 소프트웨이브2023에서 브레인즈컴퍼니는, 다양한 콘텐츠로 참관객분들께 다가가려고 노력했는데요. 특히
프론트월, 백월 공간
으로 나누어 설명한 부분이 좋은 반응을 얻었습니다.
참관객분들의 이목을 사로잡은 대시보드
제품별 브로슈어, 대시보드, 구축사례 안내
“대시보드가 너무 예뻐요”
프론트월에서 가장 많이 언급된
Best 답변 1위
랍니다! 많은 참관객분들께서 제니우스의 통합 대시보드와 서비스 종합상황판 대시보드 등을 요리조리 살펴보셨는데요.
“통합관제는 가시성이 무엇보다 중요하다고 생각해요. 그런 의미에서 제니우스의 대시보드는 가시성도 뛰어나고, 고객사 성격에 맞는 커스터마이징도 가능하며, UI적인 면도 우수하네요. 무엇보다 대시보드가 너무 눈에 띄어서 홀린 듯 부스에 들어올 수밖에 없었어요(웃음)”
라며 브레인즈컴퍼니와 제니우스 제품에 칭찬을 아낌없이 해주셨습니다!
이처럼 제니우스의 대시보드는
고객사 IT 업무 및 서비스 운영 현황을 한눈에 파악할 수 있도록 구성하고 시각화했으며, 고객사별 최적의 관제 화면을 구현
해 드리고 있어요.
공공기관·대기업·금융권 등 1,000여 개의 성공적인 구축사례
안내를 통해 제니우스 제품에 신뢰성을 더했답니다!
제니우스 핵심제품을 한눈에
제니우스 제품별 소개, 시연 안내
백월 공간에서는 브레인즈컴퍼니의 4가지 핵심 제품을 직관적으로 확인할 수 있었는데요.
제니우스 EMS, APM, ITSM, SIEM
을 파트별 담당자 엔지니어분들께서 제품 안내를 도와드렸습니다.
제니우스 EMS 제품을 통해 참관객분들께 통합관리 관제의 중요성, 실제 사례, 각 인프라별 관제의 중요성 등을 전달드렸었는데요.
“실제 사례를 직접 눈으로 확인해 보니, 우리 회사에 도입하면 장애 예측이나 장애 시 대응에 편리할 것 같아요.”
와 같은 반응이 대부분 차지했을 정도로 호응도가 좋았습니다.
제니우스 APM 또한, 사용자 관점에서 응답 시간관리가 점점 중요해지고 있음에 따라 EMS와 연계해서 사용할 수 있다는 ‘접근성’ 면에서 좋은 반응을 보여주셨는데요.
“여러 제품을 쓰지 않아도, 제니우스 하나면 모든 관제가 가능하네요! APM을 도입해서 사용하면 한눈에 관리가 편할 것 같아요.”
와 같은 뿌듯한 피드백을 주셨답니다.
。。。。。。。。。。。。
3일 동안 소프트웨이브2023 전시회를 통해 많은 참관객·고객 사분들과 마주하고 소통하며, 브레인즈컴퍼니와 자사 제품을 더 널리 알릴 수 있던 기회였습니다. 특히 브레인즈컴퍼니와 제니우스 제품에 대해 이미 관심을 갖고 방문해 주신 참관객분들이 많다는 점에서 뿌듯하기도 했답니다.
다시 한번 브레인즈컴퍼니와 제니우스 제품에 뜨거운 관심 주셔서 감사드립니다🙇♀️ 앞으로도 브레인즈컴퍼니는 고객분들께 좀 더 적극적으로 다가가기 위한 행사, 콘텐츠 등을 보여드릴게요. 여러분들의 많은 기대와 성원 부탁드리겠습니다!
🔍더보기
소프트웨이브2023 1탄도 있어요
#소프트웨이브2023
#전시회
#브레인즈컴퍼니
#제니우스
#Zenius
#에이프리카
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
EMS, NPM, AIOps까지! NMS의 진화 자세히 보기
EMS, NPM, AIOps까지! NMS의 진화 자세히 보기
앞선 글들을 통해서 NMS의 기본 개념, 구성요소와 기능, 정보 수집 프로토콜에 대해서 알아봤었는데요. 이번 글에서는 NMS의 역사와 진화 과정, 그리고 최근 트렌드에 대해서 자세히 알아보겠습니다. EMS, NPM, 그리고 AIOps에 이르기까지 네트워크의 빠른 변화에 발맞추어 진화하고 있는 NMS에 대해서 하나씩 하나씩 살펴보겠습니다. ㅣNMS의 역사와 진화 과정 우선 NMS의 전반적인 역사와 진화 과정을 살펴보겠습니다. [1] 초기 단계 (1980년대 이전) 초기에는 네트워크 관리가 수동적이었습니다. 네트워크 운영자들은 네트워크를 모니터링하고 문제를 해결하기 위해 로그 파일을 수동으로 분석하고 감독했습니다. [2] SNMP의 등장 (1988년) SNMP(Simple Network Management Protocol)의 등장으로 네트워크 장비에서 데이터를 수집하고 이를 중앙 집중식으로 관리하는 표준 프로토콜을 통해 네트워크 관리자들이 네트워크 장비의 상태를 실시간으로 모니터링하고 제어할 수 있게 됐습니다. [3] 네트워크 관리 플랫폼의 출현 (1990년대 중후반) 1990년대 후반부에는 상용 및 오픈 소스 기반의 통합된 네트워크 관리 플랫폼이 등장했습니다. 이러한 플랫폼들은 다양한 네트워크 장비와 프로토콜을 지원하고, 시각화된 대시보드와 경고 기능 등을 제공하여 네트워크 관리의 편의성을 높였습니다. [4] 웹 기반 NMS (2000년대 중반) 2000년대 중반에는 웹 기반의 NMS가 등장했습니다. 이러한 시스템은 사용자 친화적인 웹 인터페이스를 통해 네트워크 상태를 모니터링하고 관리할 수 있게 했습니다. [5] 클라우드 기반 NMS (2010년대 이후) 최근 몇 년간 클라우드 기반 NMS의 등장으로 네트워크 관리의 패러다임이 변화하고 있습니다. 또한 빅데이터 기술과 인공지능(AI) 기술을 활용하여 네트워크 성능을 최적화하고, 향후 성능을 예측할 수 있는 성능 예측 기능까지 NMS에서 제공하고 있습니다. ㅣNMS에서 EMS로의 진화 네트워크 환경은 빠르게 변화하게 되고, 이에 따라서 NMS도 EMS로 진화하게 됩니다. NMS의 진화는 총 세 가지 세대로 나눌 수 있습니다. 1세대: 디바이스 관리 시스템 기존의 NMS는 외산 제조사에서 제공하는 전용 네트워크 솔루션이 주를 이루었습니다. CISCO의 시스코웍스(CiscoWorks), IBM의 넷뷰(NetView) HP의 네트워크 노드 매니저(Network Node Manager) 등 다양한 벤더들이 자사의 제품에 대한 모니터링 서비스를 제공하기 위해 특화된 디바이스 관리 솔루션을 내놓았죠. HP Network Node Manager 예시 화면(출처ⓒ omgfreeet.live) 물론 자사의 제품을 관리하기 위한 목적에서 출발한 솔루션이었기에, 대규모 이기종 IT 인프라 환경에 대한 모니터링 기능은 제공하지 못했습니다. 2세대: IT 인프라 관리 시스템 EMS의 등장 1세대의 NMS의 경우 빠르게 급변하는 네트워크 트렌드를 따라갈 수 없었습니다. 가상랜(VLAN), 클라이언트-서버 기술이 발달하게 되자, IP 네트워크 관계만으로 실제 토폴로지를 파악하기 어려웠습니다. 또한 네트워크장비 및 회선의 상태뿐 아니라, 서버 등의 이기종 IT 인프라 통합 모니터링에 대한 니즈와 함께 EMS(Enterprise Management System)의 시대가 시작됩니다. 이에 따라 서비스 관리 차원의 통합 관제 서비스가 등장합니다. 기존의 네트워크 모니터링뿐 아니라 서버, DBMS, WAS 등 IT 서비스를 이루고 있는 모든 인프라들에 대한 통합 모니터링에 대한 관심과 니즈가 증가했기 때문입니다. 3세대: 클라우드 네이티브 환경의 EMS 2010년 중 이후 서버, 네트워크 등 IT 인프라에 대한 클라우드 네이티브로의 전환이 가속화되었습니다. 기존의 레거시 환경에 대한 모니터링과 함께 퍼블릭, 프라이빗 클라우드에 대한 모니터링 니즈가 증가하면서 모든 환경에 대한 통합적인 가시성을 제공해 줄 수 있는 EMS가 필요하게 되었죠. 이외에도 AI의 발전을 통해 AIOps, Observability라는 이름으로 인프라에 대한 장애를 사전적으로 예측할 수 있는 기능이 필요하게 됐습니다. ㅣ네트워크 환경 변화(가상화)와 NMS의 변화 이번에는 네트워크 환경 변화에 따른 NMS의 변화에 대해서 알아보겠습니다. 네트워크 환경 변화(네트워크 가상화) 네트워크 구성 방식은 지속적으로 변화해왔습니다. 클라이언트-서버 모델부터 중앙 집중식 네트워크, MSA 환경에서의 네트워크 구성까지 이러한 변화는 기술 발전, 비즈니스 요구 사항, 보안 요구 사항 등 다양한 요인에 의해 영향을 받았는데요. 무엇보다 가장 중요한 변화는 전통적인 온 프레미스 네트워크 구조에서 네트워크 자원이 더 이상 물리적인 장비 기반의 구성이 아닌 가상화 환경에서 구성된다는 점입니다. ▪소프트웨어 정의 네트워킹(SDN, 2000년대 후반 - 현재): 네트워크 관리와 제어를 분리하고 소프트웨어로 정의하여 유연성과 자동화를 향상시키는 접근 방식입니다. SDN은 네트워크 관리의 복잡성을 줄이고 가상화, 클라우드 컴퓨팅 및 컨테이너화와 같은 새로운 기술의 통합을 촉진시켰습니다. ▪네트워크 가상화 (NFV, 현재): 기존 하드웨어 기반 전용 장비에서 수행되던 네트워크 기능을 소프트웨어로 가상화하여 하드웨어 의존성과 장비 벤더에 대한 종속성을 배제하고, 네트워크 오케스트레이션을 통해 네트워크 환경 변화에 민첩한 대응을 가능하게 합니다. ㅣ클라우드, AI 등의 등장에 따른 NMS의 방향 클라우드 네이티브가 가속화되고, AI를 통한 인프라 관리가 주요 화두로 급부상하면서 네트워크 구성과 이를 모니터링하는 NMS의 환경 역시 급변하고 있습니다. 클라우드 내의 네트워크: VPC VPC(Virtual Private Cloud)는 퍼블릭 클라우드 환경에서 사용할 수 있는 전용 사설 네트워크입니다. VPC 개념에 앞서 VPN에 대한 개념을 단단히 잡고 넘어가야 합니다. VPN(Virtual Private Network)은 가상사설망으로 '가상'이라는 단어에서 유추할 수 있듯이 실제 사설망이 아닌 가상의 사설망입니다. VPN을 통해 하나의 네트워크를 가상의 망으로 분리하여, 논리적으로 다른 네트워크인 것처럼 구성할 수 있습니다. VPC도 이와 마찬가지로 클라우드 환경을 퍼블릭과 프라이빗의 논리적인 독립된 네트워크 영역으로 분리할 수 있게 해줍니다. VPC가 등장한 후 클라우드 내에 있는 여러 리소스를 격리할 수 있게 되었는데요. 예를 들어 'IP 주소 간에는 중첩되는 부분이 없었는지', '클라우드 내에 네트워크 분리 방안' 등 다양한 문제들을 VPC를 통해 해결할 수 있었습니다. ▪서브넷(Subnet): 서브넷은 서브 네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위망을 말합니다. AWS, Azure, KT클라우드, NHN 등 다양한 퍼블릭 클라우드의 VPC 서브넷을 통해 네트워크를 분리할 수 있습니다. ▪서브넷은 크게 퍼블릿 서브넷과 프라이빗 서브넷으로 나눌 수 있습니다. 말 그대로 외부 인터넷 구간과 직접적으로 통신할 수 있는 공공, 폐쇄적인 네트워크 망입니다. VPC를 이용하면 Public subnet, Private subnet, VPN only subnet 등 필요에 따라 다양한 서브넷을 생성할 수 있습니다. ▪가상 라우터와 라우트 테이블(routing table): VPC를 통해 가상의 라우터와 라우트 테이블이 생성됩니다. NPM(Network Performance Monitoring) 네트워크 퍼포먼스 모니터링(NPM)은 전통적인 네트워크 모니터링을 넘어 사용자가 경험하는 네트워크 서비스 품질을 측정, 진단, 최적화하는 프로세스입니다. NPM 솔루션은 다양한 유형의 네트워크 데이터(ex: packet, flow, metric, test result)를 결합하여 네트워크의 성능과 가용성, 그리고 사용자의 비즈니스와 연관된 네트워크 지표들을 분석합니다. 단순하게 네트워크 성능 데이터(Packet, SNMP, Flow 등)를 수집하는 수동적인 과거의 네트워크 모니터링과는 다릅니다. 우선 NPM은 네트워크 테스트(Synthetic test)를 통해 수집한 데이터까지 활용하여, 실제 네트워크 사용자가 경험하는 네트워킹 서비스 품질을 높이는데 그 목적이 있습니다. NPM 솔루션은 NPMD라는 이름으로 불리기도 합니다. Gartner는 네트워크 성능 모니터링 시장을 NPMD 시장으로 명명하고 다양한 데이터를 조합하여 활용하는 솔루션이라고 정의했습니다. 즉 기존의 ICMP, SNMP 활용 및 Flow 데이터 활용과 패킷 캡처(PCAP), 퍼블릭 클라우드에서 제공하는 네트워크 데이터 활용까지 모든 네트워크 데이터를 조합하는 것이 핵심이라 할 수 있습니다. AIOps: AI를 활용한 네트워크 모니터링 AI 모델을 활용한 IT 운영을 'AIOps'라고 부릅니다. 2014년 Gartner를 통해 처음으로 등장한 이 단어는 IT 인프라 운영에 머신러닝, 빅데이터 등 AI 모델을 활용하여 리소스 관리 및 성능에 대한 예측 관리를 실현하는 것을 말합니다. 가트너에서는 AIOps에 대한 이해를 위해 관제 서비스, 운영, 자동화라는 세 가지 영역으로 분류해서 설명하고 있습니다. ▪관제(Observe): AIOps는 장애 이벤트가 발생할 때 분석에 필요한 로그, 성능 메트릭 정보 및 기타 데이터를 자동으로 수집하여 모든 데이터를 통합하고 패턴을 식별할 수 있는 관제 단계가 필요합니다. ▪운영(Engine): 수집된 데이터를 분석하여 장애의 근본 원인을 판단하고 진단하는 단계로, 장애 해결을 위해 상황에 맞는 정보를 IT 운영 담당자에게 전달하여 반복적인 장애에 대한 조치 방안을 자동화하는 과정입니다. ▪자동화(Automation): 장애 발생 시 적절한 해결책을 제시하고 정상 복구할 수 있는 방안을 제시하여, 유사 상황에도 AIOps가 자동으로 조치할 수 있는 방안을 마련하는 단계입니다. 위의 세 단계를 거쳐 AIOps를 적용하면 IT 운영을 사전 예방의 성격으로 사용자가 이용하는 서비스, 애플리케이션, 그리고 인프라까지 전 구간의 사전 예방적 모니터링을 가능하게 합니다. 또한 구축한 데이터를 기반으로 AI 알고리즘 및 머신 러닝을 활용하여 그 어떠한 장애에 대한 신속한 조치와 대응도 자동으로 가능하게 합니다. Zenius를 통한 클라우드 네트워크 모니터링 참고로 Zenius를 통해 각 퍼블릭 클라우드 별 VPC 모니터링이 가능합니다. VPC의 상태 정보와 라우팅 테이블, 서브넷 목록 및 서브넷 별 상세 정보 (Subnet ID, Available IP, Availability Zone 등)에 대한 모니터링 할 수 있습니다. Zenius-CMS를 통한 AWS VPC 모니터링 이외에도 각 클라우드 서비스에 대한 상세 모니터링을 통해 클라우드 모니터링 및 온 프레미스를 하나의 화면에서 모니터링하실 수 있습니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼, 네트워크의 변화에 따라서 NMS는 계속해서 진화하고 있습니다. 현재의 네트워크 환경과 변화할 환경을 모두 완벽하게 관리할 수 있는 NMS 솔루션을 통해 안정적으로 서비스를 운영하시기 바랍니다.
2024.04.03
Helm과 Argo의 개념과 통합 활용법?!
Helm과 Argo의 개념과 통합 활용법?!
애플리케이션을 클라우드 네이티브 환경에서 효율적으로 관리하고 운영할 수 있는 플랫폼인 쿠버네티스(kubernetes)를 활용하는 기업들이 점점 더 늘어나고 있습니다. 이에 따라 효율적인 애플리케이션 관리를 통해 패키징 배포, 관리를 자동화하고 일관된 상태를 유지하는 것이 중요해지고 있습니다. 이번 글을 통해서는 애플리케이션 개발 및 도구 중 최근 많이 사용되는 Helm과 Argo에 대해서 자세히 알아보겠습니다. ㅣHelm의 등장 쿠버네티스를 활용한 애플리케이션 배포에 가장 기본이 되는 단위는 yaml 파일로, 주로 쿠버네티스 object(리소스)들을 정의하고 다루는데 활용됩니다. 쿠버네티스를 통해 애플리케이션을 배포하다 보면 비슷한 틀과 내용을 공유하고, 내부 값(configuration)만 일부 변경하는 작업을 하게 되는데요, 이 과정에서 애플리케이션마다 모두 yaml 파일을 만들어야 하나 보니 매우 번거로웠습니다. 위 이미지를 보면, A 애플리케이션은 정적 파일인 yaml을 오브젝트별(Service, Pod, ConfigMap)로 만들어서 생성하고 배포합니다. 그러다가 프로젝트의 확장에 따른 기능 추가로 인해 B와 C 애플리케이션으로 쪼개어 각각의 yaml 파일을 복사해서 사용합니다. 하지만, 팀 단위로 인프라가 확장될 경우는 어떻게 할까요? 개별 오브젝트에 대한 yaml 개별적으로 관리할 수 있을까요? 만약, 개별적으로 관리한다면 파일의 갯수와 코드량의 증가로 인해 개발자들은 매우 혼잡하게 될 것입니다. 이러한 문제점을 해결하기 위해, 쿠버네티스에서 애플리케이션을 배포하기 위해 사용되는 대표적인 패키징 툴인 Helm이 등장하게 됐습니다. Helm을 활용하면 컨테이너 배포뿐 아니라 애플리케이션을 배포하기 위해 필요한 쿠버네티스 리소스를Node의 npm, Ubuntu의 APT, Mac의 Homebrew처럼 모두 패키지 형태로 배포할 수 있습니다. ㅣHelm의 역사 Helm은 v1부터 v3에 이르기까지 아래와 같은 변화의 과정을 거쳐왔습니다. Helm v1 ◾ [2015년 11월] DEIS의 내부 프로젝트로 시작되어 KubeCon에서 발표 ◾ [2017년 04월] MS에서 DEIS를 인수 Helm v2 ◾ [2016년 01월] Google 프로젝트에 합류 ◾ [2016년 ~ 2018년] Helm v2 고도화, 2.15.0 릴리스 발표에서 v2 향후 계획 세부사항 공유 Helm v3 ◾ [2018년 06월] CNCF 프로젝트에 합류, MS, 삼성 SDS, IBM 및 Blood Orange의 구성원 등이 참여 ◾ [2019년 11월] 릴리스 발표 v2에서 v3로 고도화되면서 가장 눈에 띄는 변화는 Tiller(클러스터 내에서 Helm 패키지 및 배포 상태를 관리하는 서버 구성요소)의 제거입니다. Helm v2에서는 클러스터에 Tiller를 설치하여, API Server와 REST*1 통신을 하고, Client와 gRPC*2 통신을 진행했었는데요, Helm v3부터는 Tiller가 제거되면서 Client에서 바로 REST 통신을 통해 API Server로 요청하는 방식으로 변경되었습니다. 그 외에도 Helm v3으로 업그레이드되면서 보안 취약점이 줄어들었으며, 설치 및 관리 과정이 단순화되었습니다. 또한 사용자에게 보다 더 안전하고 효율적인 배포 및 관리 환경을 제공할 수 있게 되었습니다. *1 REST (Representational State Transfer) : 웹 기반 애플리케이션에서 자원을 관리하기 위한 아키텍처 스타일, 데이터를 고유한 URL로 표현하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 해당 자원에 대한 행위를 정의함 *2 gRPC (google Remote Procedure Call) : 구글에서 개발한 오픈소스 프레임워크, 원격지에 있는 다른 시스템 또는 서버에 있는 함수를 호출하는 방식 ㅣHelm의 주요 개념 Helm은 애플리케이션을 배포해 주는 툴이라고 앞서 살펴봤는데요, Helm과 같이 사용되는 주요 개념들을 살펴보겠습니다. ◾ Helm Chart: 쿠버네티스 리소스를 하나로 묶은 패키지입니다. 이는 yaml 파일의 묶음(패키지)으로, 이 묶음 public 혹은 private registry에 push 해두고, helm 명령어를 통해 Helm Chart를 설치하여 쿠버네티스 리소스를 배포하는 역할을 합니다. ◾ Repository: Helm Chart 들의 저장소 ◾ Release: kubernetes Cluster에서 구동되는 차트 인스턴스이며, Chart는 여러 번 설치되고 새로운 인스턴스는 Release로 관리됩니다. ㅣHelm의 주요 기능 Helm의 두 가지 주요 기능을 살펴보겠습니다. [1] Helm Chart를 통한 손쉬운 배포 Helm을 사용하면 어떻게 되는지 그림으로 살펴보겠습니다. 개발 클러스터가 있고 앱 2개를 배포한다고 가정했을 때, Helm Chart Template을 만들면 변수 처리를 통해 yaml 파일을 하나하나 수정할 필요 없습니다. kubectl 명령어를 통해 yaml 파일의 동적 값을 치환하여 템플릿 형태로 편리하게 배포할 수 있다는 장점이 있습니다. [2] Helm Package를 이용한 오픈소스 설치 및 배포 Helm을 통해서 쿠버네티스에서 가동할 수 있는 아래와 같은 다양한 오픈소스들의 제품들을 쉽게 설치/배포할 수 있습니다. 위제품들 외에도 Helm Chart는 총 14,376개의 패키지와 281,373개의 릴리스를 오픈소스로 제공합니다. 이를 통해 사용자들은 자신의 요구에 맞는 가장 적합한 솔루션을 선택하여 개발할 수 있습니다. 또한 많은 사용자들이 검증하고 사용함에 따라 안정성 있는 운영도 가능하죠. 다양한 Helm Chart 패키지는 커스터마이징이 가능한 경우가 많은데요, 사용자는 필요에 따라 구성을 조정하고 수정해서 사용할 수 있는 장점이 있습니다. 다음으로는 Helm 못지않게 많이 활용되는 ArgoCD에 대해서 살펴보겠습니다. ㅣ ArgoCD란?! 기존의 kubernetes 애플리케이션을 배포하고 관리하는 방식은 수동적이었습니다. yaml 파일을 직접 편집하고, kubectl로 변경사항을 클러스터에 적용하는 수동 배포 방식은 실수를 많이 유발했죠. 또한 여러 개발자나 팀이 각자의 방식대로 배포 및 관리를 수행하는 경우, 클러스터 상태의 일관성이 저하되었는데요. 이로 인해 개발 및 운영팀 간의 협업이 어렵고 생산성이 감소되는 문제가 발생하기도 했습니다. 이러한 기존 접근 방식에 대한 대안으로 GitOps가 탄생했는데요, GitOps는 Git 저장소를 사용하는 소프트웨어 배포 접근 방식입니다. GitOps는 인프라와 소프트웨어를 함께 관리함으로써, Git 버전 관리 시스템과 운영환경 간의 일관성을 유지할 수 있도록 합니다. ArgoCD는 GitOps를 구현하기 위한 도구 중 하나로 kubernetes 애플리케이션의 자동 배포를 위한 오픈소스 도구입니다. kubernetes 클러스터에 배포된 애플리케이션의 CI/CD 파이프라인에서 CD 부분을 담당하며, Git 저장소에서 변경사항을 감지하여 자동으로 kubernetes 클러스터에 애플리케이션을 배포할 수 있습니다. kubernetes 애플리케이션 배포 과정을 살펴보겠습니다. ① 사용자가 개발한 내용을 Git 저장소에 Push(이때, kubernetes 배포 방식인 Helm 배포 방식의 구조로 Git 저장소에 Push 할 수 있습니다.) ② ArgoCD가 Git 저장소의 변경 상태를 감지 ③ Git 저장소의 변경된 내용을 kubernetes에 배포하여 반영 ㅣ ArgoCD의 주요 기능 ◾ 애플리케이션을 지정된 환경에 자동으로 배포 ◾ 멀티 클러스터 관리기능 제공 ◾ OCI, OAuth2, LDAP 등 SSO 연동 ◾ 멀티 테넌시와 자체적인 RBAC 정책 제공 ◾ 애플리케이션 리소스 상태 분석 ◾ 애플리케이션 자동 및 수동 동기화 기능 제공 ◾ Argo가 관리하고 있는 쿠버네티스 리소스 시각화 UI 제공 ◾ 자동화 및 CI 통합을 위한 CLI 제공 위 내용은 ArgoCD가 제공하는 주요 기능을 나열한 것인데요, 이 중에서도 대표적인 다섯 가지 기능에 대해서 자세히 살펴보겠습니다. ① 쿠버네티스 모니터링 ArgoCD는 쿠버네티스를 항상 추적하고 있다가 저장소의 변경사항이 감지되면, 자동으로 클러스터의 상태를 저장소의 상태와 동기화합니다. 또한 문제가 생기면 이전 상태로 롤백 할 수 있으며, 이를 통해 시스템 복구 및 문제 해결을 용이하게 합니다. ② 멀티 클러스터 관리 다중 클러스터 환경에서도 배포를 관리할 수 있어 복잡한 인프라 환경에서의 효율적인 작업을 가능하게 합니다. ③ ArgoCD 대시보드 Argo에서는 클러스터 상태를 효과적으로 관리하고 모니터링할 수 있는 대시보드를 제공합니다. ArgoCD 대시보드를 통해 애플리케이션의 실시간 상태와 동기화 상태와 같은 전체적인 배포 파이프라인을 자동화하여 시각적으로 확인할 수 있고, 롤백 및 이력 추적 기능도 동시에 제공하고 있습니다. ④ 안전한 인증 및 권한 관리 역할 기반 액세스 제어(RBAC) 및 권한 제어기능을 통해 민감한 정보에 대한 접근을 제어할 수 있습니다. ⑤ GitOps 지원 ArgoCD는 GitOps 방법론을 따르므로 애플리케이션의 배포를 Git Repository와 동기화할 수 있습니다. 이를 통해 코드와 인프라의 일관성을 유지하고 변경사항을 추적할 수 있습니다. ㅣ Helm과 ArgoCD의 통합 활용 프로세스 Helm과 Argo를 함께 사용하면 개발, 테스트, 배포 프로세스를 효과적으로 관리할 수 있습니다. Helm으로 애플리케이션을 패키징하고 버전을 관리하며, Argo를 활용하여 GitOps 워크플로우를 통해 지속적인 통합 및 배포를 자동화할 수 있습니다. ① develop: Helm을 사용하여 애플리케이션을 Helm Chart로 패키징 합니다. 이후 개발된 Helm Chart를 저장하기 위한 Git 저장소를 설정합니다. ArgoCD에서 저장한 저장소를 특정 배포 대상 Kubernetes 클러스터와 연결하여, Git 저장소의 변경사항을 감지하고 새로운 배포를 시작하여 클러스터에 적용합니다. ② git push: 개발자가 로컬 저장소 내용을 원격 저장소에 배포합니다. ③ Observe(GitOps): ArgoCD는 Git 저장소의 변경 사항을 감지하여, 변경사항이 발생하면 새로운 버전의 애플리케이션을 배포하여 자동화 및 일관성을 유지합니다. ④ 운영/테스트/개발 ㅣ마무리 오늘 함께 살펴본 Helm과 ArgoCD 두 가지 강력한 도구를 함께 이용한다면 CI/CD 통합, 버전 관리, 자동화 등의 이점을 활용해서 kubernetes 환경에서 애플리케이션을 더 효율적으로 관리할 수 있습니다. 한편 애플리케이션을 효과적으로 개발하는 것도 중요하지만, kubernetes 환경의 프로세스를 실시간 모니터링하고 추적하여 관리하는 것도 매우 중요합니다. 브레인즈컴퍼니의 kubernetes 모니터링 솔루션 Zenius-K8s는 다양한 CI/CD 도구를 이용하여 개발한 kubernetes 애플리케이션의 전체 클러스터 및 구성요소에 대한 상세 성능 정보를 모니터링하고, 리소스를 추적함으로써 시스템의 안정성과 성능을 높여주고 있습니다.
2024.03.08
다음 슬라이드 보기