반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
무선 AP를 WNMS를 통해 올바르게 관리하는 방법
Helm과 Argo의 개념과 통합 활용법?!
강예원
2024.03.08
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
지속적인 성과를 내기 위한 첫걸음, '이것'부터 관리 하라?!
애플리케이션을 클라우드 네이티브 환경에서 효율적으로 관리하고 운영할 수 있는 플랫폼인 쿠버네티스(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 애플리케이션의 전체 클러스터 및 구성요소에 대한 상세 성능 정보를 모니터링하고, 리소스를 추적함으로써 시스템의 안정성과 성능을 높여주고 있습니다.
#쿠버네티스
#Helm
#Argo
#K8s
#kubernetes
#ArgoCD
#ZeniusK8s
강예원
프리세일즈팀
고객에게 특화된 Zenius를 제공하기 위해, 비즈니스 요구에 알맞은 전략적 컨설팅을 제안합니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?!
SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?!
지메일, 유튜브, 구글맵스, 구글 클라우드까지.. 구글은 자사의 다양한 서비스들이 어디에서나 원활하게 돌아갈 수 있도록, 전 세계 곳곳의 수많은 데이터 센터를 운영하고 있습니다. 구글의 한 데이터 센터 전경(출처ⓒ google.com) 그리고 이 데이터 센터간의 효율적이고 안정적인 '네트워크' 구축을 위해, 다양한 노력을 펼치고 있습니다. 사용자에게 빠른 서비스를 제공하기 위해선 데이터 센터간의 높은 연결성과 효율성이 필수조건이기 때문이죠. 구글의 네트워크 운영은 2012년에 큰 전환점을 맞이합니다. 이 변화의 중심에는 SDN(Software Defined Network, 소프트웨어 정의 네트워크)이란 기술이 있는데요. 구글의 네트워크 운영 효율과 안정성을 극적으로 개선시킨 SDN은 과연 무엇일까요? 우선 SDN의 주요 특징부터 살펴보겠습니다. ㅣSDN의 두 가지 핵심특징 SDN은 네트워크 관리를 간소화하고 네트워크 구성의 유연성을 높이기 위해 고안된 기술입니다. SDN에는 두 가지 핵심적인 특징이 있는데요. 첫 번째 특징, 컨트롤 플레인과 데이터 플레인의 분리 SDN을 대표하는 첫 번째 특징은, 네트워크 장비의 전반적인 데이터를 중앙 집중적으로 관리할 수 있는 컨트롤 플레인(Control Plane)과, 트래픽 전송 역할을 하는 데이터 플레인(Data Plane)이 분리된 것입니다. 이러한 분리에 따른 두 가지 효과를 살펴보겠습니다. (1) 최적의 로드밸런싱이 가능해짐 기존에는 라우터와 스위치 등의 네트워크 장비가 경로를 결정했었습니다. 이 장비들은 주로 최단 경로 알고리즘을 통해 패킷을 전달하기 때문에, 네트워크 관리자가 특정 경로를 원하는대로 설정하기엔 어려움이 있었습니다. 즉 '로드밸런싱'이 어려웠었죠. 하지만 SDN은 이러한 상황의 변화를 가져왔습니다. [그림] SDN 로드밸런싱 예를 들어 보겠습니다. 기존에는 경로 정보가 있을 때 U에서 나가는 트래픽을 V와 X에 각각 분산시키고 싶을 경우, 기존의 최단 알고리즘을 통하면 항상 최단의 경로로만 라우팅할 수 있었습니다. 하지만 위 [그림]처럼 SDN을 사용하면 네트워크 관리자는 전체 네트워크의 상태를 실시간으로 파악하고, 트래픽을 V와 X로 균등하게 분산시키는 등 세밀한 조정을 할 수 있습니다. 이를 통해 네트워크의 효율성을 극대화하고, 트래픽 과부하나 장애 발생 시 빠르게 대응할 수 있게 되었죠. (2) 비용 절감과 효율성 증대 SDN을 통해 기업들은 고가의 전용 네트워크 장비를 사용하지 않고도, 필요한 네트워크 기능을 구현할 수 있게 되었습니다. 이에 따라서 초기 장비 투자 비용(CapEx)과 네트워크의 운영 비용(OpEx)을 모두 줄일 수 있습니다. 또한 네트워크 관리의 자동화와 최적화로 운영의 효율성을 높여주며, 장기적으로는 인적 자원에 대한 비용 절감으로도 이어집니다. 두 번째 특징, 중앙 집중식 관리 시스템 SDN을 대표하는 또다른 특징은 소프트웨어(SDN 컨트롤러)가 중앙에서 제어한다는 것입니다. 이 소프트웨어가 네트워크의 '두뇌' 역할을 하며, 네트워크의 각 기능이 어떻게 동작할지 지시합니다. 이러한 특징으로 인한 대표적인 효과를 살펴보겠습니다. (1) 유연성과 신속한 대응 기존 네트워크 시스템은 하드웨어 중심으로 돌아가기 때문에, 이 변화에 적응하기 위해선 실제 장비를 교체하거나 수동으로 설정을 변경해야 했습니다. 하지만 SDN에서는 모든 제어 기능이 '중앙'에서 소프트웨어로 이루어지기 때문에, 변경 사항이나 새로운 요구 사항이 발생했을 경우 관리자는 물리적 장비에 접근하거나 개별 설정을 조정할 필요없이 소프트웨어를 통해 네트워크를 즉시 업데이트할 수 있게 되었습니다. 이 덕분에 기존에 며칠이나 몇 주가 걸리던 네트워크 변경 작업을 몇 분 안에 할 수 있게 됐습니다. (2) 보안과 성능 최적화 기존의 전통적인 네트워크 관리 방식에서는, 네트워크의 각 부분에 대해서 심층적으로 들여다 보는 것이 어려웠습니다. 네트워크 장비와 시스템이 서로 다른 플랫폼과 프로토콜을 사용했기 때문에, 전체적인 네트워크 상태의 모니터링이 사실상 불가능했었죠. 하지만 SDN은 소프트웨어를 통한 중앙집중식 관리 시스템으로 이루어져 있기에, 네트워크의 모든 부분에 대한 실시간 통합 관리가 가능합니다. 이를 통해서 보안 위협을 빠르게 식별하고 대응할 수 있게 되었죠. 또한 트래픽 패턴을 정밀하게 분석하여 재분배하고, 트래픽 병목 현상을 예방하여 전반적인 네트워크 성능도 개선할 수 있게 됐습니다. SDN의 두 가지 특징과 그로 인한 효과를 알아봤는데요. 이제 SDN의 아키텍처와 구현 방식에 대해서도 한번 살펴보겠습니다. ㅣSDN의 아키텍처와 구현 방식 SDN 아키텍처: 세 가지 주요 계층 SDN은 네트워크 관리를 더 유연하고 효율적으로 만들기 위해, '세 가지' 주요 계층으로 구성되어 있습니다. 세 가지 계층은 앞서 언급했던 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인), 그리고 Application Plane(응용 프로그램 계층)입니다. 각 계층은 네트워크를 관리하고 운영하는데 있어 중요한 역할을 하는데요. 각 계층별 역할과 연관성에 대해서 알아보겠습니다. 우선 아래 [그림]에 가장 하단에 위치한 Data Plane(데이터 플레인)은 Control Plane(컨트롤 플레인)이 내린 결정에 따라 실제 데이터 패킷(Data packet)을 전송하는 역할을 합니다. 데이터 플레인은 스위치, 라우터 같은 물리적 장비를 통해 구현되며, 이들 장비는 데이터 패킷을 처리하고 전달하죠. [그림] SDN 아키텍처 중간에 위치한 Control Plane(컨트롤 플레인)은 네트워크에서 어떤 데이터가 어디로 가야 하는지 결정하는 역할을 합니다. 즉 Control Plane(컨트롤 플레인)은 네트워크 트래픽을 어디로 보낼지 결정하는 역할을 합니다. 가장 위에 위치한 Application Plane(응용 프로그램 계층)은 사용자에게 서비스를 제공하는 소프트웨어 애플리케이션을 말합니다. 이 계층은 SDN의 나머지 두 계층 위에 있으며, 네트워크의 다양한 리소스를 활용해 실제 사용자에게 서비스를 제공합니다. 클라우드 스토리지 서비스나 스트리밍 서비스 같은 것이 여기에 해당됩니다. 이 서비스들은 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인)을 통해 데이터를 주고 받으며, 사용자에게 콘텐츠를 제공하죠. 이처럼 세 계층은 서로 밀접하게 연결되어 있습니다. 다시 말해 Control Plane(컨트롤 플레인)이 네트워크의 전반적인 관리와 결정을 담당하면, Data Plane(데이터 플레인)은 그 결정을 바탕으로 실제 데이터를 전송하죠. 그리고 Application Plane(응용 프로그램 계층)은 이 모든 네트워크 인프라 위에서 동작하며, 최종 사용자에게 서비스를 제공합니다. SDN의 구현 방식 위에서 살펴본 것 처럼 SDN은 세 개의 층으로 이루어져 있는데요. 이 각각의 층이 '제대로' 역할을 수행하기 위해서 꼭 필요한 것이 SDN Controller, OpenFlow 프로토콜입니다. OpenFlow 프로토콜은 SDN 컨트롤러와 네트워크 장비 사이에서 동작하는 프로토콜입니다. 컨트롤 플레인과 데이터 플레인 사이의 소통을 담당하고 있죠. OpenFlow 프로토콜은 컨트롤 플레인이 네트워크 장비에 구체적인 지시를 내리고, 그 지시에 따라 트래픽을 어디로 보낼지 결정할 수 있게 해줍니다. [그림] SDN 컨트롤러, OpenFlow 프로토콜 SDN 컨트롤러는 이 모든 과정을 조율하는 '중앙 집중식 지휘소'라 할 수 있는데요. 컨트롤러는 네트워크의 전반적인 상황을 파악하고, 데이터 플로우를 최적화하기 위한 결정을 내리며, OpenFlow를 통해 그 결정을 네트워크 장비에 전달합니다. 컨트롤러가 없다면 마치 중앙 교통 관리 시스템이 없이 각자의 판단에 따라 움직이는 차량들처럼 혼란스러워 지겠죠. 이처럼 SDN 컨트롤러와 OpenFlow 프로토콜을 통해 구현된 중앙 집중식 네트워크 관리는 효율적이고 유연한 트래픽 조정을 가능하게 합니다. 이제 마지막으로 맨 앞에서 잠시 살펴 본 구글(Google)의 사례를 자세히 들여다보겠습니다. ㅣ사례를 통해 보는 SDN: 구글의 G-Scale 구글의 'G-Scale SDN 프로젝트(2012)'는 SDN을 가장 효과적으로 활용한 대표적인 사례입니다. 이 프로젝트는 구글이 2010년부터 진행한 OpenFlow 프로젝트의 일환으로, 구글 데이터센터 백본(BackBone)1 구간을 SDN 기반으로 전환하는 대담한 시도였죠. 구글 이 프로젝트를 통해 성취한 결과는 인상적인 수준을 넘어, 네트워크 관리 방식에 혁신을 일으켰다고 평가받고 있습니다. 구글은 얻은 대표적인 세 가지 이득을 살펴보겠습니다. *1: 백본: 전산망 속에서 근간이 되는 네트워크를 연결시켜주는 대규모 전송회선 [그림] 구글 G-Scale 프로젝트를 통해 구축된 데이터 센터(2012) 1. 인프라 리소스의 최적 활용 구글은 OpenFlow를 기반으로 한 SDN을 적용해 기존에 40~50% 수준에 머물렀던 네트워크 인프라의 활용도를 거의 100% 가까이 끌어올렸습니다. 기존 네트워크 시스템에서는 다양한 벤더의 장비들이 서로 완벽하게 호환되지 않은 문제로 인해, 전체 네트워크 장비의 효율성이 제한되곤 했었죠. 하지만 구글의 SDN 구현은 이러한 한계를 넘어서, 네트워크 자원을 훨씬 유연하게 관리할 수 있는 방법을 제시할 수 있게 했습니다. 2. WAN 대역의 경로 최적화 WAN(Wide Area Network)에서의 데이터 전송 속도와 효율성은, 전 세계 사용자들에게 고품질의 서비스를 제공하는 데 핵심적인 요소인데요. 구글은 SDN을 통해 이러한 WAN 대역의 데이터 전송 경로를 최적화하여, 사용자 경험을 크게 향상시킬 수 있었습니다. 이는 전 세계 서비스를 제공하는 구글에게 있어 대단히 중요한 성과였죠. 3. 네트워크 구축 비용의 절감 구글은 SDN 컨트롤러와 화이트박스 스위치의 조합을 통해, 데이터센터 내 네트워크 구축 비용을 대폭 낮출 수 있었습니다. 화이트박스 스위치는 사용자가 네트워크 장비의 동작방식을 직접 결정할 수 있게 하는 개방형 장비로, 구글은 이를 통해 더 효율적이고 경제적인 네트워크 인프라를 구축할 수 있게 됐습니다. 또한 구축 비용의 절감 뿐 아니라 전반적인 서비스 품질의 향상 효과도 거둘 수 있었습니다. [그림] 구글의 다양한 SDN 기술 이처럼 구글의 'G-Scale SDN 프로젝트'는 단순히 기술적 성공을 넘어서, 전 세계 통신사와 네트워크 장비 제조사들이 SDN을 도입하고 네트워크 가상화에 뛰어들게 만든 결정적 계기가 되었습니다. 구글은 여기서 한 발자국 더 나아가 BGP, Espresso, B4, Andromeda, Jupiter 등 다양한 SDN 기술을 적극적으로 활용하고 있습니다. 이러한 노력은 네트워크의 효율성을 극대화하고, 비용을 최적화하여, 데이터 중심의 세계에서 경쟁력을 유지하고, 사용자에게 더 나은 서비스를 제공하는 성과를 만들어내고 있습니다. 구글의 G-Scale 프로젝트라는 큰 성공을 만들어낸 SDN도 '어떻게 하면 안정적으로 네트워크를 관리하고 운영할 수 있을까?'라는 고민에서 시작됐습니다. 네트워크 관리의 중요성은 더욱 더 커지고 있습니다. SDN이라는 혁신적인 기술을 바로 도입하는 것도 물론 좋지만, 그 전에 현재의 네트워크를 제대로 모니터링 하고 있는지 부터 점검해봐야 합니다. 여러분의 네트워크는 제대로 관리되고 있나요?
2024.05.09
브레인즈컴퍼니의 사내 뉴스레터, 브레인즈뉴스를 소개합니다!
브레인즈컴퍼니의 사내 뉴스레터, 브레인즈뉴스를 소개합니다!
브레인즈컴퍼니의 사내 뉴스레터 '브레인즈뉴스' 50호가 발행되었습니다! 2012년 4월부터 분기마다 꾸준히 발행한 브레인즈뉴스(BrainzNews)는, 사내의 최신 주요 소식을 알릴 뿐만 아니라 브레인즈컴퍼니 구성원들 서로 알아가고 소통하자는 취지로 만들어졌는데요. 이번에 발행된 50호를 통해 어떤 이야기가 담겨있는지 살-짝 소개해 드리겠습니다. │ 브레인즈뉴스 좀 더 자세히 보기 우선 이번 브레인즈뉴스의 가장 메인 콘텐츠부터 살펴보겠습니다. BRAINZ LENS 이번 호에는 브레인저가 어떻게 일하는지 구체적으로 들여다볼 수 있는 '브레인즈렌즈'라는 새로운 코너를 준비했어요. 이번에 첫 번째 주인공은 전략사업본부에 프리세일즈팀이었는데요. 프리세일즈 구성원분들은 어떻게 일하고 있는지, 한 고객사의 최초 인입부터 설치까지의 과정을 생생히 소개했습니다. RELAY 숏터뷰 브레인즈뉴스는 매호 릴레이식으로 'RELAY 숏터뷰'를 진행하고 있습니다. 릴레이 숏터뷰는 브레인저가 애정 하는 아이템뿐만 아니라 좋아하는 관심사, 취미, 자기 계발 등! 다양한 이야기를 통해 '브레인저'분들을 더 폭넓게 알아 갈 수 있는 코너입니다. 이번 50호에는 인프라웹팀의 6인 6색의 매력을 확인할 수 있었습니다! 목적 있는 수다 각 분야 전문가가 소개하는 보고, 읽고, 듣고, 맛보고, 가보면 좋을 다양한 정보들을 소개하는 '목적있는 수다' 코너도 새롭게 준비했습니다. 브레인저의 퇴근 후와 주말이 더욱 풍성해질 수 있을 것 같아요! 이 밖에도 브레인즈뉴스에는 다양한 콘텐츠들이 있습니다. 매 분기 부서 간의 소식을 전하는 '팀뉴스'를 비롯해서, 신규 입사자를 알아가는 '뉴-브레인저' 인터뷰, 브레인저에게 감사한 마음을 전하는 '하트 투 하트', 매 호마다 주제를 던지고 브레인저의 목소리를 들을 수 있는 '보이서 오브 더브레인즈' 등! 구성원 모두가 조금이라도 더 가까워질 수 있는 콘텐츠를 만들기 위해 최선을 다하고 있습니다. 브레인즈뉴스는 내부 온라인 커뮤니티와 전체 메일에서 확인할 수도 있고, 인쇄본은 8층 카페테리아와 각 팀별로 두어서 언제든지 편하게 확인할 수 있습니다. 아무리 뛰어난 지성이나 전략을 가지고 있어도 혼자 게임을 한다면, 항상 팀에게 지게 될 것입니다 리드 호프만(링크드인의 공동 창립자) 브레인즈뉴스를 통해 활발하게 소통하여 최고의 팀워크를 만들고, 그 팀워크를 바탕으로 최고의 가치를 만들어내는 브레인즈컴퍼니가 되겠습니다.
2024.05.09
꼭 알아야 할 비즈니스 매너 세 가지는?!
꼭 알아야 할 비즈니스 매너 세 가지는?!
# 함께 일하고 싶은 동료 유형 Top5 # 성격유형검사로 알아보는 나와 맞는 동료 유형 # 직장 상사 유형별 대처 방법은?! SNS나 커뮤니티를 통해 자주 접할 수 있는 인기 클립의 주제입니다. 내가 '어떤 일'을 하는지 못지않게 내가 '어떤 사람들'과 함께 일하는지가 점점 더 중요한 요소로 자리 잡고 있습니다. 모두가 생각하는 좋은 상사와 동료의 필수조건이자, 나 스스로도 직장에서 좋은 평가를 받을 수 있는 기본 중의 기본이 바로 '비즈니스 매너'입니다. 비즈니스 매너와 에티켓을 지키는 것이 한편으로는 쉽게 느껴지지만, 의외로 어렵고 막막할 때도 많은 것이 사실입니다. 처음 직장에 들어와 눈치로 익혀둔 '눈칫밥(?)'과, 틈틈이 어깨너머로 익혀둔 스킬들을 기반으로 회사 생활을 하지만, 가끔씩은 '이런 질문까지 해도 될까?' 혹은 '내가 지금 어떻게 말하고 행동하는 게 맞을까?'하는 생각이 들기도 하는데요. 이러한 고민들을 해결하고, 조금 더 수월한 직장 생활을 만들기 위한 '비즈니스 매너 세미나'가 지난 4월 8일 진행되었습니다. 한국 CS 경영연구소의 도영태 이사님을 초청하여 진행된 이번 세미나에서 나온 내용 중, '꼭 알아야 할 비즈니스 매너와 에티켓 세 가지'를 함께 알아보겠습니다. 효과적인 의사소통을 위한 방법, BMW?! 꼭 알아야 할 비즈니스 에티켓 첫 번째 직장 내 동료들과 소통할 때에는 꼭 지켜져야 할 기본 언어 예절이 있습니다. 특히 업무를 위해 모인 직장에서는 내가 하는 말이 성과와 직결되고, 잘못된 언행은 오해를 부를 수 있기에 올바른 언어 예절은 무엇보다 중요한 비즈니스 요소입니다. 따라서 효과적인 의사소통을 위해서는 Body(자세)-Mood(분위기)-Word(말의 내용) 줄여서 B.M.W 소통 방법을 체크해 보고 실행 보는 것이 중요합니다. 이날 세미나에서는 브레인저 분들과 BMW 소통 방법을 바탕으로 1:1 역할극을 진행했는데요. 짧은 시간이었지만 이 과정을 통해 서로 존중하는 대화의 기본인 상대방을 공감하는 것이며, 이를 바탕으로 소통하는 것이 얼마나 중요한지 체감할 수 있었던 의미 있는 시간이었습니다. 보고서에 꼭 담아야 할 핵심 키워드! 꼭 알아야 할 비즈니스 에티켓 두 번째 직장에서의 '문서 작성'은 원활한 의사소통만큼이나 중요하고 필수적인 기본 소양입니다. 회의록부터 기획서, 보고서, 견적서, 작업 결과물까지. 직장 생활의 처음과 끝이라고도 할 수 있죠. 물론 문서 작성이 그 사람의 모든 능력을 평가하는 유일한 요소는 아니지만, 직장 내에서 좋은 평가를 받고 성과를 만드는 중요한 요소인 것은 확실합니다. 그렇다면 보고서에 담겨야 할 핵심 키워드는 무엇일까요? 기본적으로 총 5가지 핵심적인 키워드가 들어가야 하는데요. 이 중에서도 '결론(핵심), 근거(논리적 장치), 어떻게(방향성)' 이 3가지 필수 요소는 꼭 들어가야 합니다. 첫 단계에서 전체 내용을 요약하면서도 핵심적인 메시지를 명확하고 간결하게 전달해야 하며, 이를 보완하기 위해서는 신뢰할 수 있는 데이터와 통계/사례연구/전문가 의견 등을 포함시켜야 하죠. 또한 제안된 결론을 실제로 구현하기 위한 구체적인 계획을 설명할 수 있어야 합니다. 이메일 잘 쓰는 7가지 수칙! 꼭 알아야 할 비즈니스 에티켓 세 번째 이메일은 업무를 진행하는 데 있어 매우 중요한 커뮤니케이션 툴 중 하나입니다. 출근하자마자 '메일함 확인'으로 업무를 시작하는 직장인분들이 많으실 거라 생각합니다. 내가 작성한 보고서를 첨부하여 보고하거나 공유할 때, 협업 부서와 프로젝트 관련 내용을 공유할 때, 그리고 다른 회사 직원들과 소통할 때 등 정말 다양한 상황에서 메일이 사용되는데요. 이렇게 직장인들의 귀와 입이 되어주는 업무 메일을 잘 쓰는 방법을 7가지로 나눠볼 수 있습니다. 특히 4번에 '제목 부분은 심사숙고해서 써라' 항목 같은 경우는 용건을 정확히 밝히고 인사말을 쓰지 않은 것이 중요합니다. 예를 들어 '안녕하세요. 영업팀 홍길동입니다'라는 제목은 지양해야 하죠. 이 외에도 리스트에 있는 부분들을 꼭 참조하셔서 효과적으로 이메일을 활용하시기 바랍니다. 기본적인 커뮤니케이션 방법부터 보고서와 이메일 작성 방법, 그리고 그 외에 그동안 놓치고 있었던 디테일한 직장 생활 팁까지! 이번 '비즈니스 매너와 기본 소양' 세미나는, 직장인으로서의 기본 매너를 익힐 수 있는 시간이었습니다. '동료와 함께 협력하여 성과를 만드는 것'이 더욱 중요해지는 가운데, 기본 비즈니스 매너를 갖추도록 노력하면서 아래의 질문을 끊임없이 스스로 해보는 것도 중요하다고 생각합니다. 지금 나는 함께 일하고 싶은 좋은 동료인가? [ 붙임 ] 브레인즈컴퍼니는 교육비/자격증 취득 지원, 외부 강사 초빙 강연, 사내 도서관, 세미나 진행 등 직원들의 역량을 높이기 위한 다양한 지원을 하고 있습니다. 또한 전 직원 해외연수, 해외 연수단 파견, 인센티브 제도 등 다양한 제도를 운용하며 함께 성장하고 보람을 느낄 수 있도록 노력하고 있습니다.
2024.06.21
[ZNG 개발기] #1. ZNG와 Vue.js
[ZNG 개발기] #1. ZNG와 Vue.js
안녕하세요. 브레인즈컴퍼니 개발 3그룹에서 ZNG의 프론트엔드를 개발하고 있는 1년차 신입 개발자 김현수입니다. ZNG란 Zenius New Generation의 약자로, 브레인즈컴퍼니의 핵심 서비스인 제니우스의 차세대 버전을 말합니다. ZNG는 데이터베이스를 제외한 프론트엔드와 백엔드는 완전히 제로베이스에서 시작하는 장기 프로젝트이기에, 프로젝트를 진행하는 과정에서 새롭게 배운 것, 개발자로서 성장, 팀 개발 경험 등을 기록하고자 ZNG 개발기를 작성하게 됐습니다. ZNG 개발기는 달마다 개발과정에서 있었던 이슈들, 경험, 공부한 내용 등을 기술적인 내용과 함께 작성할 예정입니다. 다 함께! <사진 설명: 펭수, "렛츠고!"> 1. ZNG가 무엇인가요? ZNG는 기존 제니우스에서 발생하는 불편함을 해소하고자 탄생한 프로젝트입니다. 기존 제니우스에는 어떤 불편함이 있었고, 이를 해소하고자 ZNG는 어떤 컨셉을 목표로 개발할 것인가에 대해 알아보겠습니다. 같은 부서 선배 동료들을 쫄래쫄래 따라다니며 물어보고 배워가며 정리한 내용을 바탕으로 작성하는 글입니다. 혹시라도 틀린 부분이 있다면 알려주시면 감사하겠습니다! <사진 설명: 자환님은 아니라고 하셨다...> 제니우스는 B2B 솔루션 서비스 상품으로 사용자의 요구사항에 맞게 유연한 변경이 가능해야 합니다. 새로운 컴포넌트를 추가 한다거나, 여러 기능을 합치는 등 다양한 요구사항에 대응해야 합니다. 당연히도 현재 제니우스는 사용자의 요구사항에 맞춰 조금씩 커스텀해 서비스되고 있습니다. 그러나 효율적이지 못한 상황이 생기기도 합니다. 대체로 같은 내용의 코드를 반복해서 작성하는 상황이 그러합니다. 같은 형태를 가진 컴포넌트여도 출력하고자 하는 데이터의 종류가 다르다면 컴포넌트를 통째로 다시 만들어야 했습니다. 반복적인 작업은 개발자에게 피로감을 주게 되고 단순히 피로감을 넘어, 개발자에게 목표 의식을 저하시킬 우려가 있습니다. <사진 설명: 다양한 종류의 컴포넌트가 있다. 사용자마다 원하는 컴포넌트, 데이터가 다를 수 있다.> 이런 불편함을 해소하는 방법으로, ZNG는 코드의 재사용성을 높이기 위해 노력합니다. 각 기능끼리의 의존도는 낮추고, 독립성을 높여서 반복적인 작업을 최소화합니다. 같은 형태를 가진 컴포넌트에 대해서 데이터만 다르다면 데이터만 바꿔주면 됩니다. 사용자마다 다른 종류의 데이터를 출력하기를 원할 경우 더 빠르고 효율적인 대처가 가능합니다. 이러한 컨셉과 Vue.js의 Component를 관리하는 방법이 일치해 ZNG는 Vue.js로 개발하게 됐습니다. 2. ZNG와 Vue.js Vue.js에는 여러가지 특징이 있습니다. 그 중에서도 Vue Component에 대해서 자세히 알아보겠습니다. Vue Component Vue Component란 화면을 구성하는 하나의 블록입니다. Component는 하나의 전체 화면일수도 있고 전체 화면 중 일부분을 차지하는 또 하나의 작은 화면일수도 있습니다. 따라서 화면을 구현할 때 화면 전체를 한 번에 구현하지 않고, 부분적으로 구현해 관리하는 것이 가능합니다. Component를 활용하면 화면을 구조화해 직관적으로 개발할 수 있으며 코드의 재사용성이 올라갑니다. <사진 설명: 화면의 영역을 블록으로 쪼개 재활용 가능항 형태로 관리하는 것이 Vue Component> ZNG 기능 중 모니터링은 추출한 데이터를 그래프, 표 등을 통해 다양한 형태의 컴포넌트로 보여줍니다. 각각의 컴포넌트는 서로 다른 모양을 통해, 서로 다른 데이터를 보여줍니다. 반대로 말하면 하나의 컴포넌트에 대해서 모양, 데이터만 다르게 준다면 여러 종류의 컴포넌트를 만들 수 있습니다. 다음은 ZNG 코드 일부입니다. PCContainer는 컴포넌트를 감싸는 블록입니다. component 태그 안에 있는 ‘is’옵션에 ‘컴포넌트의 이름’을 넣어 그리고자 하는 컴포넌트를 선택할 수 있습니다. PCLineChart는 그래프를 그리는 컴포넌트입니다. highchartsOptions에 어떤 데이터를 넣느냐에 따라 원하는 그래프를 그릴 수 있습니다. <사진 설명: PCContainer> 하나의 PCContainer로 여러 모양의 컴포넌트를 그리고, 하나의 컴포넌트(PCLineChart)로 다양한 데이터를 표현할 수 있습니다. 컴포넌트를 만들기 위해 새로운 코드를 작성하지 않고, Vue Component를 통해 코드를 재사용함으로써 효율적이고 직관적인 코드를 개발할 수 있습니다. 부모와 자식 컴포넌트 관계 각 Vue Component는 데이터를 주고받을 때 부모-자식 관계를 갖는 것이 일반적입니다. <사진 설명: 부모-자식 컴포넌트> 부모는 자식에게 데이터를 전달할 수 있어야 하며, 자식은 부모에게 일어난 일을 알려야 합니다. 부모는 props를 통해 자식에게 데이터를 전달하며, 자식은 emit로 이벤트를 호출해 부모에게 데이터를 알립니다. 부모 컴포넌트와 자식 컴포넌트는 분명히 구분된 컴포넌트지만 props와 emit을 통해 의사소통이 가능합니다. ZNG는 최상단 레이아웃에서 서버로부터 데이터를 받아와 props를 통해 각 컴포넌트로 데이터를 보내줍니다. 하위 컴포넌트에서 발생한 이벤트를 통해 다시 상위 컴포넌트로 데이터를 전달해 데이터를 관리합니다. 다음은 ZNG 코드 중 일부입니다. 자식 컴포넌트는 props를 통해 부모 컴포넌트로부터 데이터를 받고, emit을 통해 부모 컴포넌트로 이벤트를 통해 알립니다. props와 emit을 통해 컴포넌트 간 의사소통을 수행하지만, 각 컴포넌트마다 코드를 분리하기 때문에 관리가 편하고 쉽게 재사용할 수 있습니다. 3. 마치며 ZNG의 개발 방향성과 이와 관련해 Vue.js의 Component 특징을 정리해봤습니다. Vue Component는 이전부터 알고 있던 개념이지만 직접 개발한 코드와 비교해보니 머릿속에 명확하게 정리되는 느낌이었습니다. 특히 코드를 다시 보면서 개념을 리마인드하는 과정이 좋았습니다. ZNG 개발기는 이제 시작입니다! 앞으로도 계속될 ZNG 개발기에 많은 관심 부탁드리며 ZNG 프로젝트를 성공적으로 수행할 때까지 응원해주세요! <사진 설명: 개발의 신이시여... 지켜봐 주세요!> [출처] https://kr.vuejs.org/ https://ko.wikipedia.org/wiki/Vue.js https://www.instagram.com/waterglasstoon/
2022.08.03
다음 슬라이드 보기