반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
서버 모니터링의 두 가지 방식
제 6회 브레인즈컴퍼니 패밀리데이
최순정
2023.05.26
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] Picnic with BRAINZER
브레인즈컴퍼니는 2015년부터 따뜻한 봄이 오면, '패밀리데이
'를 개최하고 있습니다.
패밀리데이는 브레인저들의 가족을 초청해 1박2일 간 함께 연휴를 즐기는 행사입니다.
한 번 참석한 가족들은 다음 패밀리데이를 손꼽아
기다릴 정도로 만족도가 높은 행사인데요.
코로나로 인해 잠시 중단됐던 패밀리데이가
지난 5월 20~21일 양일간 홍천 대명 비발디파크에서 열렸습니다!
가족들이 도착하기 전, 도우미로 나선 브레인저들이 행사장을 세팅했습니다.
헹사장에 도착한 가족들은 간식박스와 음료를 비롯한 웰컴키트를 수령하고,
뽑기를 통해 상품도 함께 받아갔습니다.
또, 차후에 진행될 로또 게임과 행운권 추첨을 위해 사전 등록도 진행했습니다.
브레인즈에서 준비한 웰컴키트와 선물을 한 아름씩 안고 가족사진도 찰칵!
2인 가족부터 3대가 모두 총출동한 가족까지, 약 100여명의 브레인저와 가족들이 참석했습니다.
모두 빠짐없이 추억을 남길 수 있도록 폴라로이드로도 사진을 제공했어요.
본격적인 행사를 시작하기 앞서, 브레인저와 그 가족들이 함께 단체사진을 촬영했습니다.
환한 표정의 참가자들! 기분좋게 행사가 시작됐습니다.
이번 행사는 영업그룹의 막내, 석빈님이 진행했습니다.
행사장 앞 무대에 잔뜩 쌓인 경품들 보이시나요?
첫 번째로, "사회자를 이겨라, 가위바위보!" 게임이 진행됐습니다.
많은 경쟁자를 물리치고 20여명이 무대 앞으로 나와 사회자와 겨뤘고, 최후의 4인이 남았습니다.
그 중 미모를 한껏 뽐내던 꼬마숙녀가 우승해 가족들의 환호를 받으며 상품을 차지했습니다!
다음으로 '청기백기' 게임이 진행됐는데요.
초등학교 입학 전 유아들이 먼저 참여했습니다.
아이들이 참여하다 보니, 마음 약한 사회자는 탈락을 쉽게 외치지 못해 곤혹을 치뤘습니다.
이어, 초등부 게임이 진행됐고 치열한 경쟁 끝에 경품을 차지할 수 있었습니다.
다음으로 중고등부!
이전 게임들에 비해 월등한 실력을
보여줘 우승자를 가리기 어려웠는데요.
결국 최후의 2인이 가위바위보를 통해 상품을 가져갔습니다.
마지막으로 남녀를 나눠 성인부 게임이 진행됐습니다.
한치의 양보도 없
이
진행된 게임의 승자는 브레인저들이 차지했습니다.
성인 여성부 게임에서는 브레인저의 가족들이 우승하며 경품을 나눠갔습니다.
다음으로, 가족이 모두 함께 즐길 수 있는 '파스타면&마시멜로우 탑 쌓기
' 게임이 진행됐는데요.
5분 간 파스타면과 마시멜로우를 잘 조합해 가장 높이 탑을 쌓은 가족 3팀에게 경품을 증정했습니다.
이어서, OX
퀴즈를 풀었습니다.
어린 아이들 눈높이에 맞춰 다양한 문제가 출제됐고,
패자부활전을 거쳐 최후의 4인이 남았는데요.
승자는 ITSM 팀장인 희찬님이 차지했습니다.
이번에는 가족들의 단합력을 높여줄 다각 달리기!
2, 3, 4인 가족으로 나눠 게임이 진행됐습니다.
1그룹 브레인저들이 모두 승리를 거머쥐었네요.
행사장 입장 때 제출했던 로또를 맞히기 위해,
자녀들이 나와 각 번호의 풍선을 터뜨리는 게임이 진행됐습니다.
브레인저들이 옆에서 원하는 번호를 부르며 코치하고, 아이들이 열심히 다트핀
을 던졌습니다.
총 3팀의 가족들이 경품을 가져갔어요.
마지막 게임은 아이들이 가장 기다린 '보물찾기'였는데요.
도우미들이 행사 시작 전 건물 근처에 많은 보물을 숨겨뒀고,
한 명도 빠짐없이 상품을 가져갈 수 있었습니다.
평소 갖고 싶던 선물이 나오자, 활짝 웃음 짓던 아이들!
행사 중 가장 행복한 모습을 보여, 보는 이들도 절로 미소가 나왔네요.
게임이 끝난 후, 행운권 추첨이 시작됐습니다.
최연소 참가자인 인프라웹팀 보람님의 쌍둥이 딸도 추첨에 참여해 눈길을 끌었습니다.
APM팀의 진광님 가족이 1등 및 여러 상품을 휩쓸어가며 부러움을 샀어요.
행사가 끝난 후, 가족별로 모여
브레인즈에서 제공한 한우 불고기를 먹으며
오붓한 시간을 보냈습니다.
이후 각자 숙소에서 자유시간을 갖고,
다음날 오전 역시 브레인즈 측에서 마련한 조식을 먹은 후 집으로 돌아갔습니다.
이번 행사에 참석한 브레인저들이 마음 따뜻해지는 이야기
를 전해왔습니다.
"사춘기에 접어든 큰 아이와 서먹했는데, 기분 전환이 됐는지 좀 나아졌네요.
즐거운 시간이었어요."
"매년 아주 만족하며 행사에 참석하고 있습니다.
준비해주신 도우미분들께 감사드리고, 좋은 행사 계속 됐으면 해요."
"동료들의 가족들을 보니, 무엇인가 알 수 없는 책임감이 더 생기는 것 같아요.
예전에는 나만 잘하면 되지라고 생각
했는데
저와 협업하는 분이
누군가의 아버지이고 어머니라는 것을 느끼며, 더 많이 배려해야 겠다는 생각을 했습니다."
"코로나로 잠정 중지됐다 오랜만에 다시 열려서 기뻐요.
1박 2일 동안 가족들이 행복해하는 모습을 보며 저도 행복
했어요.
맛있는 음식과 깔끔한 숙소 그리고 멋지게 행사 준비한
도우미들이 있어 더욱 즐거운 시간을 보낼 수 있었어요."
#브레인즈컴퍼니
#사내행사
#패밀리데이
최순정
경영기획실(PR매니저)
브레인즈컴퍼니의 소식, 조직문화, 브레인저 이야기를 대내외에 전파하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
디자이너를 그만두고 개발 일을 하는 이유
디자이너를 그만두고 개발 일을 하는 이유
브레인즈컴퍼니에는 5개의 개발그룹이 있습니다. 그 중 브레인즈 대표 제품인 Zenius EMS의 웹 개발을 총괄하고 있는 개발2그룹의 그룹장, 성준님을 만나봤습니다. 성준님은 학석〮사로 산업디자인을 전공했는데요. 디자인 전공자가 어떻게 개발그룹장을 맡게 됐을까요? 성준님이 개발 일을 하게 된 사연 그리고 다양한 팀이 모여 있는 개발2그룹의 일하는 방식 등에 대해 이야기를 나눠봤습니다. ---------------------------------------------------------------------------- Q. 안녕하세요, 성준님. 자기소개 부탁드립니다. 연구개발본부 개발2그룹 그룹장으로, Zenius EMS의 웹개발을 책임지고 있습니다. 브레인즈컴퍼니에는 2010년 12월부터 근무하기 시작해 현재 12년째네요. 브레인즈에 오기 전에도 주로 웹개발을 했고, 때에 따라 SI프로젝트 PM도 했습니다. Q. 전공이 산업디자인이라고 들었습니다. 디자인 전공으로 석사까지 하신 후 개발자로 전향하신 계기가 있을까요? 대학교 1학년 때는 디자인 전공이 아니었고, 당시 학부별로 신입생을 뽑아서 자연과학부로 입학했어요. 2학년 때부터 산업디자인을 해야겠다는 마음을 먹고 겨울방학 때 한두 달 정도 미술학원에서 드로잉의 기초적인 것들을 배운 후, 대학 3년과 대학원 2년 동안 산업디자인 공부를 했습니다. 당시에 사용자 인터페이스에 관심이 많았고, 석사 논문도 사용자 인터페이스가 주제였어요. 석사 2년차 때, 대우전자와 삼성SDS에서 근무하던 선배를 통해 입사제안을 받았습니다. 그런데 행운인지 불행인지 두 회사의 면접일이 같아, 한 곳을 선택해야만 했어요. 대우전자에 가게 된다면 제품 디자인을, 삼성SDS는 소프트웨어 개발 관련 디자인 업무를 할 수 있었어요. 저는 사용자 인터페이스와 같은 소프트웨어 개발 쪽의 디자인 업무를 하고 싶어 삼성SDS로 면접을 갔고 삼성에 입사하게 됐습니다. 당시 삼성SDS(前 삼성데이터시스템)는 SI 사업도 하고 삼성 그룹 계열사의 SM 업무도 했습니다. 또 하이텔, 천리안과 같은 유니텔이라는 PC 통신 서비스도 제공하고 있어서, 입사 전에는 유니텔의 GUI를 담당하거나 UI 관련 업무를 할 것이라고 예상했어요. 그런데 제가 병역특례 전문연구요원으로 근무하는 것이라서, 제 예상과는 다르게 연구소 소속으로 소프트웨어 연구 및 개발 업무를 하게 됐습니다. 당시 삼성SDS에 입사하면 수 개월 동안 PowerBuilder, Oracle 같은 개발 교육을 받은 후에 부서로 배치됐고, 이런 교육 덕분에 소프트웨어 개발 업무에 쉽게 적응할 수 있었죠. 또, 학부 때 컴퓨터 프로그래밍 과목을 여러 개 수강하면서, 디자인보다는 소프트웨어 개발이 제 적성에 더 맞는다고 생각하고 있었고, 이렇게 첫 직장 생활을 소프트웨어 개발자로 시작하게 됐습니다. 이후 27년 동안 쭉 소프트웨어 개발을 하고 있습니다. Q. 이제 부서 이야기를 해볼게요. 개발2그룹에서는 어떤 업무를 진행하고 있나요? 개발2그룹은 인프라웹팀, ITSM팀, 디자인팀으로 구성돼 있습니다. 먼저 인프라웹팀은 우리 회사매출의 90% 이상을 차지하고 있는 Zenius EMS의 웹 업무를 담당하고 있어요. 신규 인프라 혹은 장비의 성능을 모니터링하는 기능을 추가하거나, 사용자 편의성 개선 등의 고도화 업무, 보고서/대시보드 같은 고객사별 커스터마이징 개발 등의 업무를 주로 하고 있습니다. ITSM팀은 IT 부서에서 IT 서비스를 운영하는데 필요한 업무 프로세스를 돕는 Zenius ITSM 제품을 개발하고 이를 기반으로 고객사에 구축하는 프로젝트를 수행하는 팀입니다. ITIL이라는 표준을 바탕으로 장애처리, 서비스요청과 같은 업무를 IT 부서에서 원활하게 수행할 수 있도록 프로세스를 구축하고 이를 시스템으로 처리할 수 있게 합니다. 최종적으로 IT서비스 수준을 한 단계 높이는 일을 하고 있어요. 마지막으로 디자인팀은 브레인즈의 모든 제품과 솔루션의 디자인을 책임지고 있습니다. 고객사별 대시보드 디자인을 하고, 모든 브레인즈 제품의 GUI 디자인, UI/UX 기획, 정보시각화 등의 업무를 합니다. Q. 팀마다 분위기가 다를 것 같은데요. 각 팀별 일하는 방식에 대해 설명해주세요. 아무래도 팀별로 업무가 아주 다르다 보니, 일하는 방식도 업무에 맞춰서 변하는 거 같습니다. 인프라웹팀은 코드리뷰와 공유 회의를 통해서 업무가 진행됩니다. 다양한 고객사로부터 다양한 요구사항이 들어오기 때문에 이전에 했던 유사한 개발 업무가 무엇이었는지, 어떻게 개발했는지 개발자끼리 공유하는 일이 매우 중요해요. 회의를 통해서도 공유하지만, 다음 개발자를 위해 개발 이력도 문서화를 잘 해놓고 있어요. ITSM팀은 팀장이 주도적으로 제품 개발을 리딩하면서, 개발자 모두가 하나의 목표로 똘똘 뭉칠 수 있게 개발자 한 명 한 명을 독려하면서 일하고 있습니다. 디자인팀의 경우, 결과물은 눈에 보이지만 고객의 요구사항은 눈에 보이지 않고 설명하기 어렵기 때문에, 타 부서 및 팀 내에서도 커뮤케이션이 활발하게 이뤄지고 있어요. 또, 브레인즈의 디자인 아이덴터티를 견고하게 만들기 위해서 디자인 크리틱도 자주 합니다. Q. 개발2그룹에 신규 입사자가 들어온다면, 어떤 스타일의 동료가 합류했으면 하는지 궁금합니다. 신뢰할 수 있는 동료. 제가 지금까지 직장생활을 하면서 가장 중요하다고 생각하는 것은 신뢰입니다. 항상 솔직하게 말하고, 자기 말에 책임지는 행동을 하는 동료였으면 좋겠어요. 아무리 실력이 좋더라도 신뢰할 수 없다면, 그 실력도 신뢰하기 어렵게 되는 거 같아요. 모든 인간이 완벽할 수 없기 때문에 조금 실력이 부족하더라도 신뢰할 수 있는 사람이라면, 동료와 서로 부족한 부분을 채워 나가며 무슨 일이든 해낼 수 있다고 생각합니다. Q. 신규 입사자는 브레인즈컴퍼니에서 어떤 성장을 기대할 수 있을까요? 인프라웹팀에서 일하게 되면 1,000여 개의 레퍼런스를 가진 제품은 어떤 모습이어야 하는지를 배울 수 있습니다. 많은 고객들의 다양한 요구사항을 어떻게 제품에 녹여야 하는지, 그리고 그 많은 사이트를 어떻게 관리해야 하는지를 배울 수 있어요. 또, 성능상의 문제없이 방대한 양의 성능 데이터를 어떻게 다뤄야 하는지도 배울 수 있습니다. ITSM팀에서는 다양한 회사에서 IT서비스를 어떻게 관리하는지 직접 경험하고, 이를 제품에 어떻게 포함하는지 배울 수 있어요. 현재 최신 버전의 Zenius ITSM이 고객을 하나씩 늘려가고 있는데요. 새 버전의 제품이 어떻게 업그레이드돼 가는지, 고객의 요구사항은 무엇이고 이것을 제품에 어떻게 녹이는지도 경험하면서 제품과 함께 자신도 성장해 나가는 경험을 할 수 있습니다. 디자인팀에서는 패키지 소프트웨어의 GUI 디자인을 직접 경험할 수 있고, UI/UX 기획도 해 볼 수 있습니다. 다양한 고객들이 원하는 디자인은 무엇인지, 고객과 커뮤니케이션은 어떻게 하는지 등도 경험해 볼 수 있어요. 아무래도 대시보드 디자인 업무를 많이 하다 보니, 다양하고 많은 정보를 어떻게 시각화해야 하는지 연구하고 디자인할 수 있습니다. Q. 브레인즈에 장기근속 중이신데요. 입사 초와 현재를 비교해 보자면? 입사 초기의 브레인즈가 중학생이었다면, 현재는 대학생이 된 것 같습니다. EMS가 성공하면서 상장한 회사가 됐다는 점이 가장 큰 변화라고 생각해요. 또, 상장을 했다는 건 기업이 갖춰야 할 투명성과 성장성이 검증된 것이라고 봅니다. 지금까지 그래 왔듯이 브레인즈는 앞으로도 꾸준히 발전할 것이라고 믿습니다. Q. 그동안 가장 힘들었던 순간과 보람을 느꼈던 순간은요? Zenius EMS 7.0을 개발하고 오픈할 시점이 가장 힘들었습니다. 일이 정말 많았거든요. (웃음) 개발해야 할 인프라가 열 개가 넘었고, 프리랜서 개발자까지 포함해서 30여 명 정도가 매달려서 일했습니다. 개발 업무가 많아 야근하는 것도 힘들었지만, 그룹장이기 때문에 많은 개발자를 관리하는 일이 개발 업무보다 더 힘들었어요. 또, “새 버전이 이전 버전처럼 많은 매출을 울릴 수 있을까”하는 걱정도 한몫 했습니다. 정말 정신없던 때였네요. 반대로 가장 보람찼던 순간은 상장했을 때입니다. 우리 회사가 상장하는 데 제가 5% 정도는 기여하지 않았을까 생각합니다. (웃음) 사실 다니던 회사가 상장한다는 건 일생에 한 번 경험할까 말까 한 일이라고 생각합니다. 단지 운이 좋아서 입사하자마자 상장한 게 아니라, 10년 동안 브레인즈에서 열심히 일해왔고, 그래서 상장하는 데 작은 기여를 했다고 생각하기 때문에 더 기뻤어요. 그 밖에도, 우리 제품이 장애를 미리 발견해 큰 사고가 발생하는 것을 막았다는 이야기를 들을 때면, “내가 한 일이 다른 누군가에 실질적인 도움이 되는구나”라는 성취감을 느껴요. 고객사 기사에서 우리 제품이 기사 사진에 보이거나, 간접적으로 소개되는 것을 볼 때도 보람을 느낍니다. Q. 앞으로 브레인즈컴퍼니에서 꼭 이뤄보고 싶은 목표가 있을까요? 공개할 수 없지만, 현재 브레인즈에서는 새로운 기술로 새로운 제품을 만들고 있는데요. 제가 작게나마 기여를 했으면 좋겠고, 이왕이면 그 제품이 대박을 터트리면 더욱 좋겠습니다. (웃음) 그리고 소박한 목표가 하나 더 있어요. 브레인즈에서 정년까지 일하고 싶습니다. (웃음)
2022.09.16
[통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기
[통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기
Filebeat는 Elastic Stack에서 사용하는 경량(light-weight) 데이터 수집기로 logstash 대비 상대적으로 리소스(CPU와 RAM)를 상당히 적게 소모한다는 장점이 있습니다. 또, Filebeat는 간단한 필터 기능도 제공합니다. 하지만 말 그대로 간단한 필터 기능이라 한번에 대용량의 파일을 관리해야 하는 경우 호스트 서버에 부담이 갈 정도로 많은 리소스를 사용할 수 있습니다. 따라서 브레인즈컴퍼니가 운영하는 통합로그관리 에이전트는 호스트의 서버 환경에 따라 filebeat 에이전트의 설정 파일을 수정해서 안정성을 제공하고 있습니다. 본 내용은 Filebeat 리소스 점유율이 높을 때 트러블슈팅 관련 설정 수정사항입니다. 수정에 필요한 기본 파일 위치 linux : /etc/filebeat/filebeat.yml docker: /usr/share/filebeat/filebeat.yml filebeat 프로세스 메모리 확인하는 방법 top -d 1 | egrep "PID|filebeat" 수정에 앞서 filebeat의 메인 컴포넌트인 harvester의 개념을 간략하게 설명하겠습니다. 하나의 harvester는 하나의 파일을 읽어드립니다. harvester가 실행 중인 경우 파일을 한 줄씩 읽습니다. 각 파일 당 하나의 harvester가 실행됩니다. 상단의 이미지를 보면 filebeat의 컴포넌트인 input과 harvester가 보입니다. 또한 filebeat이 harvester를 관리하며 어느 파일을 읽을지 관리하는걸 알 수 있습니다. harvester가 실행 중인 경우 파일 설명자(File Descriptor) 열린 상태로 유지됩니다. 이는 파일이 삭제되거나 파일명이 변경된다 하더라도 파일을 계속 읽게 해줍니다. 하지만 파일 설명자는 harvester가 닫힐 때까지 디스크 공간을 예약합니다. 1. filebeat.inputs: 2. - type: filestream 3. id: my-filestream-id 4. paths: 5. - /var/log/system.log 6. - /var/log/wifi.log 7. - type: filestream 8. id: apache-filestream-id 9. paths: 10. - "/var/log/apache2/*" 11. fields: 12. apache: true 13. fields_under_root: true <filebeat에서 제공하는 input example> 1. scan_frequency 파일비트가 설정된 filebeat_inputs의 path에 있는 파일들의 갱신 여부를 체크하는 주기입니다. 너무 길게 설정하면 한번에 많은 파일들을 수집하게 됩니다. 반대로 너무 짧게 설정하면 스캔을 너무 잦게 해서 CPU점유율이 올라갑니다. 적당한 조절이 필요합니다. 기본값은 10초입니다. Scan_frequeny가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency 만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 2. backoff Backoff 옵션은 파일비트가 얼마나 더 적극적으로 크롤링 하는지 지정합니다. 기본값은 1인데 1일 경우 새 줄이 추가될 경우 1초마다 확인한다는 의미입니다. Backoff가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 → 파일 갱신 시 Backoff 시간 마다 다시 확인 3. max_procs 파일비트에서 동시에 사용 가능한 최대의 cpu코어의 숫자를 설정합니다. 예를 들어32 CPU코어 시스템에서 max_procs를 1로 설정한다면 cpu사용률은 3.2%(1/32)를 넘지 않습니다. max_procs 설정돼 있으면 harvester가 아무리 많이 생성돼도 cpu의 코어 수만큼 CPU를 점유합니다. 4. harvester_limit harvester의 수가 OS가 감당할 수 있는 파일 핸들러 개수를 초과할 때 사용합니다. 한 input마다 설정되므로 inputs이 5개 선언돼 있으면 해당 input 컴퍼넌트의 harvester 개수 최대치는 5개입니다. 기본값은 0인데, 0일 경우 harvester가 무제한으로 생성 가능합니다. 리소스 관리 최적화에도 유용한데 예를 들어, input1이 input2보다 파일 개수가 3배 많고 중요성이 높을 때 3배 높은 값을 설정하는 것이 좋습니다. 5. close_eof harvester에 의해 파일이 수집되고 있을 때, EOF(End of File)에 도달하는 즉시 파일을 닫습니다. 파일이 계속 갱신된다면 데이터가 유실될 수 있는 여지가 있습니다. [참조] https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html
2022.11.17
카프카를 통한 로그 관리 방법
카프카를 통한 로그 관리 방법
안녕하세요! 저는 개발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
디자인 시스템이 필요한 이유와 핵심요소는?
디자인 시스템이 필요한 이유와 핵심요소는?
“우리나라 금융 유니콘 기업이 개발과정에서 1,000시간을 아낀 비결” “애플과 구글이 제품을 기획하고 개발할 때 가장 중요하게 생각하는 것” 디자인 시스템은 무엇일까? 위에 있는 두 문장의 답은 바로 ‘디자인 시스템’이에요. 고객이 하나의 브랜드를 접하는 순간부터 끝까지 지속적으로 동일한 경험을 하게 해주는 디자인 시스템의 중요도는, 점점 더 커지고 있죠. 디자인 시스템은 시맨틱 컬러, 컴포넌트 디자인, 디자인 토큰 등을 구축하여 제품 전반에서 사용자가 일괄적인 시각적 경험을 할 수 있도록 도와주고 있어요. 제품을 더 빠르고 효율적으로 만들어주기도 해요. 그리하여 이번 시간에는 1) 디자인 시스템은 구체적으로 무엇이고 2) 브레인즈컴퍼니는 어떤 노력을 하고 있는지 살펴볼게요! 디자인 시스템의 요소1 : 시맨틱 컬러 ▲Zenius ITSM 버튼에 적용된 컬러 시스템 디자인 시스템의 중요 요소 중 하나인 '시맨틱 컬러'는, 사용 방법에 따라 색상 이름을 지정하는 방법이에요. 브레인즈컴퍼니의 제니우스(Zenius)도 시맨틱 컬러를 사용하고 있는데요. Primary, Secondary, Tertiary, Ghost, Gray, Severity Color 등으로 구성되어 있어요. 여기서 Primary 컬러는 UI 전체의 주요 구성 요소에 대한 역할을 해줘요. 가장 중요한 액션에 사용하며, 화면에서 가장 강력한 클릭 유도 문안인 CTA(call to action)을 강조하기 위해 사용하기도 하죠. ▲Zenius ITSM Primary 컬러의 변천사 Zenius ITSM은 BI 컬러를 보완한 Primary 색상을 사용 중이며, Secondary와 Tertiary는 이와 어울리는 색상을 지정해 사용하고 있어요. 브레인즈컴퍼니의 컬러는 선명한 파란색이지만, 제품 화면에 사용하기에는 채도가 너무 높아 두 번의 GUI 테스트를 거쳐 위와 같이 보완한 색상이 나왔어요. Secondary와 Tertiaty 사용 시 화면 구성의 위계질서에 따라 색상을 설정하여 중요도(중요, 보조, 부가)를 표현하기도 해요. [잠깐의 TMI🤭] 브레인즈컴퍼니 브랜드 색상인 Blue는 한국에서 가장 선호도가 높은 색상이며, 신뢰·젊음·성실·책임감 등의 이미지를 지닌 색상이에요. ▲컬러 팔레트 디자인 시스템의 요소2 : 심각도 컬러 ▲심각도 컬러 팔레트 '심각도 컬러'는 Zenius에서 사용하는 시맨틱 컬러의 일종이에요. Zenius에서 발생한 이벤트를 알려주는 색상으로 총 6단계의 색상을 구축하여서 사용하고 있답니다. 정상, 무해, 주의, 위험, 긴급, 치명의 6단계이며 위와 같은 컬러를 사용하고 있어요. 디자인 시스템의 요소3 : 디자인 토큰 '디자인 토큰'은 디자인 시스템의 시각적 디자인 요소이며, 디자인 관련 변수를 저장하는 데 사용하는 기본 요소에요. 기존에는 피그마(Figma)에서 컬러나 폰트 등을 Style로만 지정할 수 있었어요. 같은 색상을 여러 개의 항목에 적용할 경우, 토큰 별로 사용할 수 없는 점이 굉장히 불편했죠. 하지만 Figma의 Variable 기능이 업데이트된 후, 토큰을 만들 수 있게 되었어요! 브레인즈컴퍼니의 메인 제품 Zenius는 총 세 개의 테마를 사용 중이라, 디자인 토큰 시스템을 테스트하고 있답니다. ▲컬러 토큰 시스템 위와 같이 속성이 다른 두 개의 디자인에 동일하게 Neutral-500 컬러를 사용했는데요, 토큰별로 색상을 적용할 수 있는 시스템이라, 같은 색상을 지닌 다른 속성이어도 개별로 컬러 관리가 가능한 장점이 있어요. 개발자와의 협업에도 굉장히 좋은 시스템이랍니다! 。。。。。。。。。。。。 제니우스(Zenius) 제품이 태어난 지 오래된 만큼, 제품 디자이너가 여러 번 바뀌었어요. 컬러 시스템에 대한 가이드도 중간중간 변경되었죠. 브레인즈컴퍼니 디자인팀은 컬러 시스템을 다시 재정비하기 위해, 여러 가지 테스트 과정을 거치고 있어요. 아직은 구축 단계에 있어 디자인 팀 내의 규칙이나, 개발자들과 네이밍 규칙 등 협의해야 할 일이 적진 않아요. 그래도 구축이 완료된다면 정말 소통하기 편해질 거 같아요! 이제 곧 완성될 '디자인 시스템'을 통해 한층 더 성숙해질 Zenius! 많은 기대 부탁드려요😊
2023.12.12
다음 슬라이드 보기