기술이야기

기술이야기 [통합로그관리] 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

기술이야기 통합로그관리가 필요한 3가지 이유 기술이야기 통합로그관리가 필요한 3가지 이유 로그는 IT 인프라에서 발생하는 모든 상황들을 기록한 데이터입니다. 쉽게 말해 사용자가 어떤 루트로 사이트에 접속했고, 접속한 시점부터 어떤 행동을 취했는지가 모두 기록으로 남게 되는데, 이 기록들이 로그입니다. 로그는 IT 환경에서 가장 많이 발생하지만, 데이터 처리 기술이 발달하지 않았던 시기에는 처리 비용에 비해 가치가 낮은 데이터로 여겨졌습니다. 하지만 최근들어 IT 서비스와 인프라가 다양해지고 디지털 트랜스포메이션이 가속화되면서, 로그의 양이 기하급수적으로 증가하고 사물인터넷(IoT), 빅데이터 등과 같은 신기술이 발전하면서 그 효용성 또한 날로 증가하고 있습니다. 그렇다면, 이 로그는 실제로 어떻게 활용될까요? 개발 영역에서는 버그 혹은 크래시율 수집 및 상시 트래킹, 이슈 발생 후 롤백 및 대응, 특정 기능에 대한 사용성 진단에 활용됩니다. 마케팅 분야는 채널별 ROI 진단 및 비용 최적화, 배너/프로모션/이벤트 효과 측정, 유저 세그멘테이션 및 타게팅에 사용합니다. 기획 및 디자인 영역은 기능 개선을 위한 A/B 테스트, 유저 Journey 경로 분석을 통한 UX/UI 최적화 등에서 쓰이고 있습니다. 이처럼 여러 영역에서 다양하게 쓰이는 로그를 관리하지 않고 방치해두면 어떤 일이 발생할까요? 통합로그관리가 필요한 이유에 대해 알아보겠습니다. ----------------------------------------------- I. 보안 대응체계 구축 저장만 하고 관리되지 않은 로그는 IT 시스템의 장애나 문제 발생 시 그 원인을 찾아내기가 어렵습니다. 또, 로그 데이터의 중요 정보가 외부로 유출될 위험도 커집니다. 끊임없이 발생하는 보안 사고에 대비하기 위해 통합로그관리는 반드시 필요합니다. 관리된 로그는 장애나 사고 발생 시에 그 원인을 파악하고 빠른 대처를 위한 근거 데이터로 사용할 수 있으며, 보안 체계를 마련하는 데에도 활용가능 합니다. 기업들은 로그관리 제품을 사용해 사이버 침해위협을 예방 및 감시하고, 정기적인 로그분석을 통해 강력한 보안대응체계를 구축하고 있습니다. 통합로그관리 솔루션은 보안장비(Firewall, IDC, IPS 등)의 로그와 해킹, 악성코드 등 보안/침해 관련 로그를 지속적으로 분석해 예방 체계를 구축합니다. 또, 대용량 로그의 상관분석을 통해 보안위협을 탐지하고 이상징후를 모니터링하는 등 강력한 보안 대응체계를 구축할 수 있습니다. II. 컴플라이언스 준수 로그는 보안 사고가 발생했을 때 가장 기본적인 증거 및 모니터링 자료로 활용됩니다. 이에 따라 정부에서는 데이터 관리에 대해 각종 법률을 규정하고 있어, 공공기관을 비롯한 개인정보를 다루는 온라인 사업자 및 기업 등은 해당 법규를 준수해야 합니다. 안전한 데이터 이용을 위해 2018년에 발의된 '데이터 3법' 개정안은 2020년 1월 9일 국회 본회의를 통과했습니다. 데이터 3법은 개인정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등 3가지 법률을 통칭합니다. 로그 관리 관련 규제의 주요 내용은 다음과 같습니다. i. 개인정보보호를 위해 접근 권한 부여, 변경 또는 말소 기록을 3년 이상 보관해야 합니다. ii. 개인정보 취급자는 개인정보처리시스템의 접속기록을 월 1회 이상 점검해야 하고, 그 활동의 증거를 남기기 위해 시스템에 접속했다는 기록을 1년 이상 보관해야 합니다. iii. 정보통신서비스 제공자는 접근 권한 내역을 5년간 보관하고, 접속 기록의 위·변조 방지를 위해 반드시 백업 보관해야 합니다. III. 빅데이터 처리 플랫폼 IT 인프라 확대 및 기타 비정형 로그 유입에 따라 대용량 로그에 대한 관리가 요구되고 있습니다. 특히 수집된 로그를 실시간으로 분석∙판단해 IT 서비스의 안정적 운영을 도모해야 하는 수요가 증대되고 있는데요. 오늘날의 데이터는 기존 데이터에 비해 양이 매우 방대해 기존 방법이나 도구로는 관리가 어렵습니다. 따라서 빅데이터 기술을 기반으로 하는 대용량 통합 로그관리 솔루션은 이제 IT 운영을 위한 필수 솔루션으로 자리잡았습니다. ----------------------------------------------- 이처럼 기업은 보안위협 및 이상징후 대응/컴플라이언스 준수/대용량 로그 관리를 위해 통합로그관리 솔루션을 필수로 갖춰야합니다. 브레인즈컴퍼니의 통합로그관리 솔루션 '제니우스(Zenius) Logmanager'는 이기종 장비에서 발생되는 정형∙비정형 로그 데이터의 수집/분석/관리 등을 위한 빅데이터 플랫폼입니다. 제니우스 로그매니저가 어떻게 구성돼 있는지 살펴보겠습니다. 제니우스 로그매니저는 정형/반정형 또는 비정형 로그에 대한 실시간 수집 및 신속한 분석 기능을 제공하며, 이러한 정보들을 다양한 차트와 대시보드를 통해 직관적으로 가시화합니다. 특히 로그매니저는 독보적인 인덱싱 및 검색 속도를 제공하며 확장성, 편의성, 효율성, 호환성 등의 특장점을 보유한 제품입니다. 로그 이벤트 발생 시 즉각적인 알람을 통해 빠른 문제 해결과 높은 가용성을 확보하도록 지원합니다. 2022.11.10

기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 지원 이유와 여정 대학교 졸업 후, 부족한 웹개발 역량을 쌓기 위해 5달간의 풀스택 부트캠프 교육을 수료하고 1달간의 기업 협업 인턴을 마쳤습니다. 이후, 제 역량을 마음껏 펼쳐내며 지속적으로 성장할 수 있는 회사에서 일하고 싶다는 생각이 들었습니다. 그러다 풀스택 기술뿐만 아니라, 빅데이터 및 AI 기술을 활용해 차세대 기술을 개발하는 브레인즈컴퍼니의 채용공고를 발견했습니다. 이 회사에서라면 많은 것을 배워 역량을 키우고 성장하며 일할 수 있겠다는 생각에 지원했고, 면접 끝에 첫 직장에 취업하게 됐습니다. 웹개발도 재밌지만 개발자로서 지속적으로 새로운 기술들을 습득하며 성장하는 것에서 성취감과 보람을 느끼는 것이 컸고, 그럴 수 있는 부서에서 첫 회사 생활을 시작할 수 있다는 생각에 기뻤습니다. 채용 과정 면접에서 기억에 남는 질문은 "우리 부서는 프론트엔드 보다 백엔드를 더 추구하는 편이라 함께 일을 하게 된다면, 프론트엔드와 백엔드 모두를 아울러 사용할 것인데 할 수 있습니까?"였습니다. 풀스택 개발자로서 일을 하게 된다는 질문이었고, 저는 이 부분에 대해 긍정적이었기 때문에 자신 있게 할 수 있다고 대답했습니다. 백엔드 개발자보다 많은 영역에서 발전하며 성장할 수 있다는 생각에 더욱 기대되고 설렜던 기억이 있습니다. 그렇게 저의 첫 직장 생활이 시작됐습니다. 입사 후, 지난 3달간의 일대기 채용이 된 후, 출근까지 2주간의 자유 시간이 주어졌습니다. 졸업 후 부트캠프 교육을 이수하면서 줄곧 달려왔고, 즐겁게 공부했지만 지쳐있는 심신을 달래기 위해 여행도 다녀오고 친구들과 가족들과 시간을 보내면서 출근 준비를 했습니다. 그렇게 2주 후 첫 출근을 하는 날이 됐고, 본격적으로 사원으로 근무하는 날이 다가왔습니다! 브레인즈컴퍼니의 개발 그룹은 1~5그룹으로 나눠져 있으며, 저는 개발4그룹에 소속됐습니다. 개발4그룹은 프론트엔드와 백엔드 개발뿐만 아니라, 빅데이터 및 AI 기술을 동원한 신기술 개발을 담당하고 있어, 배울 점도 많고 나아가야할 길도 멀리 펼쳐져 있다고 느꼈습니다. 1st Month_적응기 입사 첫 달은, 개발4그룹에서 집중적으로 개발 진행 중인 로그매니저와 Zenius AI의 제품 매뉴얼과 웹페이지에서 실제로 사용되고 있는 각각의 기능들을 학습하며 제품을 파악하고 익숙해지는 기간을 가졌습니다. 그렇게 한 달 간은 개발에 투입되기보다는 제품 및 사용된 기능들에 대한 학습과 공부를 하는 기간이었습니다. 단순히 제품의 매뉴얼만을 보며 학습을 했다면 집중도가 떨어졌을 수 있지만, 제품에서 사용하고 있는 다양한 기술들, Elasticsearch, Kibana, Kafka, Cluster 등 스택들에 대해 공부하면서 흥미와 재미를 느끼며 학습을 이어갈 수 있었습니다. 잘 몰랐던 신 기술들을 접하면서, 앞으로도 배우게 될 다양한 기술들에 대해 기대감이 부풀었던 한달이었습니다. 이외에도 학습을 진행하면서 원래 사용하던 스택인 JavaScript와 Linux의 Base부터 차근차근 다시 복습하며 결점을 보완하고, 제 자신을 Refactoring하기도 했던 한 달이었습니다. 2nd Month_개인정보 마스킹 기능 개발 입사 두 달째 부터는, 로그매니저와 Zenius AI의 기능들과 매뉴얼에 대해 전반적인 이해를 갖게 됐고, 각 사이트 기능들의 동작 원리 등을 대략적으로 파악할 수 있었습니다. 두 달이 된 이 시점부터 프론트엔드와 백엔드 모두를 사용하는 프로젝트가 주어졌습니다. 주어진 프로젝트는 ‘개인정보 마스킹 기능 개발’ 이었습니다. 로그매니저 내에서 수집되는 대용량의 로그들 안에 개인 정보가 포함될 경우가 있는데, 개인정보가 그대로 노출되는 것을 방지하기 위해 개인정보에 해당하는 정보는 마스킹처리를 자동적으로 진행하는 기능 개발을 진행하게 됐습니다. 예를 들어, 로그에 ‘961219-1234567’, ‘서울시 성동구 성수이로’, ‘010-1234-5678’ 등과 같은 주민등록번호, 주소, 연락처 뿐만 아니라 다양한 개인정보들을 지정한 특수문자(Default로는 *을 사용) 로 마스킹 처리를 해주는 기능을 개발하는 과정이 중점이 되는 프로젝트였습니다. 풀스택 공부를 하면서, 백엔드는 Node.js와 MySQL, PrismaOrm 등을 사용해 기능 개발을 진행했지만, 이번 프로젝트는 Elasticsearch, Kafka.js, Cluster.js 및 커스텀마이징된 다양한 메소드와 함수들을 통해 진행했기 때문에 배울 점이 매우 많았고, 성장하는 것을 느낄 수 있었습니다. 이외에도 프론트엔드에서 Ace.js를 통한 텍스트 편집기를 개발하고, 개인정보유형에 해당하는 정보가 입력되면 Syntax Highlighting 기능을 통해 해당 부분에 형광펜 효과를 적용시켜주는 기능의 개발을 진행했습니다. 개인정보 유형에 해당하는 정보에 대응되는 정규표현식, 그리고 백엔드에서 마스킹 처리될 특수문자 타입의 데이터 등은 Elasticsearch의 Index를 통해서 데이터의 저장과 반환작업 처리를 진행해줬으며, 이 데이터들을 기반으로 프론트엔드와 백엔드에서 모두 정상적인 마스킹 기능과 Syntax Highlighting 기능을 개발할 수 있었습니다. 새로운 기술을 활용해 프로젝트를 진행하면서 어려운 점도 많았고 시행착오도 겪었지만, 그만큼얻어가고 배워가는 것이 많았던 첫 업무였습니다. Elasticsearch, Kibana, Cluster, Kafka 등 새로운 기술 스택에 대해 배우고 적용할 수 있었다는 점이 매우 흥미로웠고 뿌듯한 경험이었습니다. <사진 설명: 개인정보 유형과 마스킹 여부, 정규표현식 관리와 마스킹 기능 ON/OFF가 가능한 페이지> <사진 설명: 선택한 개인정보 정규표현식에 해당되는 데이터 Syntax Hilighting 기능 구현> 3rd Month_데몬프로세스 그룹화 작업 및 테스트케이스 입사 세 달째 부터는, 어느 정도 회사 생활에 적응이 된 상태가 됐습니다. 아침 일찍 일어나는 것에도 적응이 됐고, 초반에는 어색했던 업무회의와 주간업무보고서 작성도 이제는 자연스럽게 하고 있는 모습을 발견할 수 있었습니다. 첫번째 프로젝트를 마친 후, 두번째로는 로그매니저의 데몬프로세스 기능을 그룹별로 정렬하는 업무를 맡게 됐습니다. 데몬프로세스가 각각의 그룹 속성을 지니고 있지만, 이를 그룹별로 나눠서 보여준다면 좀 더 가독성과 가시성이 높아질 것이기 때문에, Elasticsearch에서 반환 받는 데이터를 그룹의 조건에 따라 분류해주는 작업이 주가 됐습니다. 두번째 개발 후에는 로그매니저의 각 기능들에 대한 테스트 케이스 및 오류 사항 확인의 과정을 거쳤고, 제가 개발한 ‘개인정보 관리’ 기능에 대한 테스트 케이스 작성도 진행했습니다. 개발자가 개발을 잘하는 것도 중요하지만, 이렇게 자신이 개발한 기능에 대해 테스트케이스를 작성하면서 유저가 해당 테스트케이스를 확인하고, 개발한 기능을 자연스레 사용할 수 있게 해야 하는 것은 개발만큼이나 중요하다고 생각하기 때문에 기분 좋게 테스트케이스 작성을 진행할 수 있었습니다. 또, 로그매니저 제품 각 기술들의 테스트케이스들을 확인하며 각각의 기능들을 모두 테스트해볼 수 있는 기회가 됐으며, 개발하고 서비스되고 있는 기술들에 대해 좀더 명확하게 인지하고 확인할 수 있어 제품 이해에 큰 도움이 됐습니다. 이를 기회로 개발만이 중요한 것이 아닌 테스트케이스의 중요성을 절실히 깨닫고, 제가 개발하는 기술들에 대한 테스트케이스 작성이 필수불가결하다는 것을 느끼게 됐습니다. 느낀 점 브레인즈컴퍼니 개발4그룹에 입사 후, 3달간 근무하며 느낀 점은 제가 만족하며 회사를 다니고 있다는 점입니다. 그룹의 모든 구성원분들이 잘 적응할 수 있도록 도와주고 챙겨주셨고, 문제가 될 수도 있는 실수가 발생해도 모든 그룹원들이 다 잘 다독여 주셨습니다. 또, 좋은 피드백을 줘서 지속적으로 배워가고 성장할 수 있는 회사의 성장할 수 있는 부서라고 생각합니다. 그룹의 상래님, 신후님, 천웅님, 태민님 모두 제게 좋은 피드백과 도움을 주시고, 개선돼야할 점과 공부해야 할 부분, 그리고 개발을 하면서 고쳐야 할 습관들을 알려주셔서 점차 앞으로 나아갈 수 있다고 생각합니다. 일을 하면서 빼놓을 수 없는 게 워라밸일 것이라고 생각합니다. 첫 회사에서 일과 삶의 밸런스가 매우 적절하다고 생각하고 만족하며 근무를 하고 있습니다. 퇴근을 한 뒤에도 운동을 할 수 있고, 식단 관리도 병행하며 몸을 기르고 있습니다. 만약, 워라밸이 좋지 않았더라면 이렇게 삶을 유지할 수 없을 거라는 생각이 듭니다. 글을 마치며 면접에서 제가 했던 말이 있습니다. 저는 앞에 벽이 있다면 돌아가 다른 길을 찾으려 하기보다는 그 벽을 넘을 수 있는 방법을 생각합니다. 앞으로 나아갈 수 있고 성장할 수 있는 삶을 추구하고 있습니다. 비록 그 벽을 넘지 못하더라도, 다음에 그 벽보다 낮은 벽은 넘을 수 있을 것입니다. 시도조차 하지 않으면 당연히 발전도 없다고 생각합니다. 매번 도전하고 또 도전하며 발전하는 개발4그룹의 일원이 돼, 신기술 개발에도 큰 보탬이 되는 개발자로 성장하고 싶습니다. 그리고 브레인즈컴퍼니 개발4그룹에서 반드시 실현 가능하다고 생각합니다. 다양한 기술들을 배우고 학습해 제 것으로 만들고, 그룹과 회사에 보탬이 되는 개발자로 성장하겠습니다! [출처] https://twitter.com/gom_translate https://me2.kr/wvu3p http://jjaltoon.gallery/?p=11311 https://me2.kr/eq144 2022.08.25

블로그

기술이야기