반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
SMS를 통한 서버관리는 꼭 이렇게 해야만 한다?!
네트워크 정보 수집 프로토콜의 모든 것 (SNMP, RMON, ICMP, Syslog)
임형섭
2024.03.04
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
무선 AP를 WNMS를 통해 올바르게 관리하는 방법
지난 포스팅을 통해
NMS의 기본 개념
과
NMS의 구성요소와 역할
에 대해서 살펴보았는데요. 오늘은
네트워크 정보 수집을 위한 다양한 프로토콜
에 대해서 자세히 알아보겠습니다.
네트워크 프로토콜(Network Protocol)은 네트워크에 연결된 장비 간의 메시지 흐름을 통제하고 관리하는 기본적인 절차와 규칙을 정한 규약입니다.
웹 브라우저, 파일 전송, 이메일 송수신, 미디어 스트리밍 등과 같은 모든 온라인 활동을 가능하게 하기 때문에 네트워크 정보 전달의 핵심요소라고 할 수 있죠.
이번 시간에는 주요
네트워크 프로토콜인 ICMP, SNMP
를 중점적으로 알아보겠습니다.
ㅣICMP는 무엇이고 어떻게 동작하는가?
ICMP(Internet Control Message Protocol)는 주로 네트워크의 경로상의 문제나, 호스트(단말)의 문제 등을 파악할 때 사용하는 프로토콜인데요. 대표적인 서비스가 ping입니다. 구체적인 동작원리를 살펴보면 다음과 같습니다.
오류 보고
◾ 네트워크에서 데이터를 보낼 때 오류가 발생하면, 오류를 발생시킨 장비(예: 라우터, 스위치)는 오류 정보를 담아 ICMP 메시지를 처음 보낸 사람에게 전송합니다. 이를 통해 무엇이 잘못됐는지 정확히 파악하고 문제를 해결할 수 있습니다.
◾ 예를 들어 한 컴퓨터에서 인터넷을 통해 데이터를 보내는데, 그 데이터가 목적지에 도달하지 못하면 ICMP가 '이 주소로는 데이터를 배달할 수 없어!'라고 알려주는 역할을 하죠. 이렇게 사용자나 네트워크 관리자가 문제를 알리고 대응할 수 있게 도와주는 게 ICMP의 주요 역할입니다.
[그림] ICMP 동작 방식
진단 및 테스트
◾ 네트워크의 연결 상태나 성능을 테스트하기 위해 ICMP 에코 요청과 에코 응답 메시지를 사용합니다. 이를 통해 네트워크의 지연시간(latency)이나 패킷 손실(packet loss) 등을 측정할 수 있습니다. '핑(ping, Packet INternet Groper)'을 대표적인 예로 들 수 있습니다.
◾ 쉽게 표현하면 '너 지금 연결 잘 되어 있니?'라고 물었을 경우 대상 장비가 '응, 잘 되어 있어!'라고 대답하면 연결이 잘 되어 있는 것이고, 대답이 없거나 늦는 것과 같은 문제를 식별하는 것이죠.
ICMP도 좋은 도구이지만, 네트워크의 복잡성이 빠르게 증가하고 호스트 수가 증가하면서 ICMP만으로는 네트워크 관리가 어려워지는 문제가 발생했는데요. 이를 개선하기 위해서 탄생한 것이 바로 SNMP입니다.
우선 SNMP의 히스토리부터 살펴보겠습니다.
ㅣSNMP 히스토리: 각 버전별 개념과 차이점은?
SNMP(Simple Network Management Protocol)는 1988년에 아래의 세 가지 니즈에 부합하기 위해 등장했습니다.
◾ ICMP보다 많은 기능의 탑재
◾ 네트워크 문제를 직관적이고 쉽게 해결할 수 있어야 함
◾ 표준화된 프로토콜의 사용
이후 몇 가지 버전을 거쳐서 현재는 네트워크 장비를 모니터링하기 위한 프로토콜로 자리를 잡아서 대부분의 NMS 상에서 이용되고 있습니다.
잠깐 SNMP의 처리단계를 살펴보면, SNMP는 Get/Set/Trap의 단순 명령 구조로 구성되는데요, 메시지 타입별 역할은 아래와 같이 정리할 수 있습니다.
위와 같은 처리단계를 가지고 있는 SNMP는 보안 기능 강화 및 기능 개선을 위해서 초기 v1 버전에서 v3 버전까지 업그레이드됐습니다.
각 버전은 보안, 성능, 유연성 등의 측면에서 발전되었으며 현재는 SNMPv2가 가장 많이 사용되고 있죠. SNMP 버전 별 특징에 대해서 자세히 알아보겠습니다.
SNMP v1
가장 초기에 만들어진 프로토콜로 기본적인 정보만을 주고받아서 네트워크 장비들의 상태를 확인하고, 간단한 명령 정도만 내릴 수 있습니다. 보안에 많이 약한 편이고, 정보를 주고받을 때 특별한 암호화나 보호 방법을 사용하지 않기에 정보가 노출될 위험이 있습니다.
SNMP v2
SNMPv1의 단점을 해결하기 위해 개발된 버전입니다. 보안 기능과 네트워크 과부하, 관리 효율성 등에 대한 기능이 향상되었습니다.
MIB(Management Information Base) 구조를 개선하여, 새로운 데이터 타입과 객체 식별자(프로그래밍에서 특정 객체를 식별하는 데 사용되는 값이나 이름)을 도입했습니다. 이로써 더 많은 종류의 데이터를 효과적으로 다룰 수 있게 되었지만, v1과 호환이 안되는 문제가 있어 상용화에는 실패했습니다.
SNMP v2c (Community-Based Security)
SNMPv2c는 '커뮤니티 기반' 방식을 사용하며 'Community String' (공동체 문자열)을 이용합니다. Community String은 정보를 주고받기 위해 인증 과정에서 비밀번호를 사용하는 것으로, 학교에서 특정 비밀번호를 알고 있는 사람들만 특정 정보를 볼 수 있게 하는 것과 비슷합니다.
하지만 비밀번호가 복잡하지 않은 편이라, 조금 더 높은 보안을 필요로 하는 경우에는 적합하지 않을 수 있습니다. 현재 가장 많이 사용되고 있는 버전입니다.
SNMP v3
보안과 관리 기능을 대폭 강화한 버전입니다. SNMPv3는 정보를 주고받을 때 강력한 인증과 암호화를 사용하여, 네트워크 상의 중요한 정보를 안전하게 지킬 수 있습니다.
또한 복잡한 네트워크 환경에서 사용자가 많을 경우에도, 각 사용자의 접근 권한을 관리할 수 있는 기능이 있습니다. 하지만 이전 버전들보다 더 복잡한 보안 모델과 설정 등의 이유로 널리 사용되고 있지는 않습니다.
[그림] SNMP 버전과 수를 한눈에 볼 수 있는 제니우스 EMS 화면
참고로 SNMP에는 위와 같이 다양한 버전이 있기 때문에 모든 NMS는 제니우스처럼 어떤 버전으로 수집했는지와 수를 파악할 수 있어야 합니다.
이제 SNMP에 대해서 조금 더 자세하게 살펴보겠습니다.
ㅣSNMP 자세히 보기: MIB의 개념과 구조
MIB(Management Information Base)는 관리 정보 기반이라고 불립니다. SNMP를 통해 관리되어야 할 정보나 자원들을 모아둔 것으로, Manager와 Agent 간 정보를 주고받는 정보의 집합체입니다.
MIB에는 SNMP를 통해 주고받는 정보가 어떤 의미를 가지고 어떻게 사용될 수 있는지에 대한 정의가 포함되어 있습니다. 또한 각각의 정보는 '객체'라고 불리며, 이 객체들은 계층적으로 구성되어 있기에 관리하고자 하는 정보를 쉽게 찾을 수 있게 도와주죠.
대표적으로 CPU 사용량, 메모리 사용량, 포트의 up/down 같은 상태 정보 등이 MIB에 포함됩니다. 마치 항해사가 바다를 항해하기 위해 지도를 사용하는 것처럼, MIB를 통해 네트워크의 상태를 정확히 파악하고 필요한 조치를 취할 수 있습니다.
MIB의 구조를 자세히 살펴보면 우선 큰 나무를 뒤집어 놓았다고 생각한다면 이해하기 쉽습니다. 큰 나무의 밑동(Root) → 각각의 가지(Branches) → 잎사귀(Leavers)로 나누어져 내려오는 형태인데요, 부분별로 자세히 살펴보겠습니다.
◾
밑동(Root):
모든 MIB 트리의 시작점으로, 'iso(1)', 'org(3)', 'dod(6)', 'internet(1)' 등으로 구성되어 있습니다. 여기서 'internet'은 네트워크 장비와 관련된 표준 MIB를 나타냅니다.
◾
가지(Branches):
밑동에서 나온 큰 가지들은 네트워크 장비의 다양한 부분을 나타냅니다. 예를 들어 'mgmt(2)' 가지는 일반적인 관리 정보, 'private(4)' 가지는 각 제조업체의 고유 정보 등을 의미합니다.
◾
잎사귀(Leaves):
가장 작은 단위의 정보를 나타내는 부분으로 특정 장비의 상태, 성능 지표, 설정값 등 구체적인 데이터가 저장됩니다.
MIB에서는 네트워크 장비의 정보가 여러 '분류'로 나누어져 있는데, '네트워크 인터페이스'라는 분류 아래에는 네트워크 카드의 상태, 속도, 전송된 데이터의 양과 같은 정보들이 담겨 있습니다.
MIB는 복잡해 보일 수 있지만, 네트워크 장비와 관련된 정보를 체계적으로 관리하고 접근할 수 있도록 설계되어 있습니다. 이 구조 덕분에 네트워크 관리자는 네트워크의 건강 상태를 쉽게 체크하고 필요한 조정을 할 수 있습니다.
다음으로는 MIB 내의 각 객체를 고유하게 식별하는 OID에 대해서 알아보겠습니다.
ㅣSNMP 자세히 보기: OID 확인 방법과 수집항목
OID(Object Identifier)는 MIB 내에 포함되어 있는 각 개별 정도에 대한 ID 값입니다. 아래 그림에서 볼 수 있듯이, 트리의 하단 값이 OID인데 MIB의 각 개별 정보에 대한 ID를 의미합니다.
[그림] OID Tree 구조
대형 도서관에서 원하는 책을 찾을 때 책의 번호를 확인하여 빠르고 정확하게 찾는 것처럼, 특정 오브젝트의 ID(Num)을 부여한 게 OID입니다. OID는 포함하고 있는 각 정보를 숫자로 표현합니다.
◾
Enterprise OID:
네트워크 업계에서 공통으로 사용하는 OID
◾
Private OID:
각 네트워크 벤더사에서 사용하는 독자적인 OID
예를 들어 Juniper Networks라는 네트워크 스위치 벤더에서 사용하고 있는 OID 값을 [1.3.5.6.1.9 ]라는 전용 OID 값을 사용한다고 가정하면, Juniper Networks 라우터의 경우 뒤에 라우터 제품별 OID '11'이 더 붙은 [1.3.5.6.1.9.11 ] 형태의 OID로 구성됩니다.
[그림] 제니우스 예시 화면
지금까지 네트워크 모니터링에 필요한 ICMP, SNMP 그리고 MIB, OID에 대해 살펴봤습니다. 참고로 제니우스(Zenius)-NMS에서는 OID 사전을 제공하고 있으며, 이를 통하여 관리하고 싶은 항목의 MIB 항목 및 OID 정보를 쉽게 찾을 수 있습니다.
이제 SNMP의 주요 개념 중 하나인 SNMP Trap에 대해서 알아보겠습니다.
ㅣSNMP Trap의 개념 그리고 특징은?
Manager(관리자)는 Server(Agent)로 메시지 요청(Polling)을 하게 되고, Server(Agent)는 응답(Notifying)을 하는 방식으로 진행됩니다.
그런데 Server가 비정상적인 이벤트를 감지하면 Manager의 Polling을 기다리지 않고 바로 Manager에게 메시지를 보내는데요, 이 긴급 메시지를 Trap(트랩)이라고 합니다. 우리가 날씨에 대해서 찾아보지 않아도 폭설이 예상될 때 폭설을 경고하는 자동 알림 시스템과 비슷한 개념입니다.
[그림] SNMP 프로토콜 동작 방식
SNMP Trap은 일반적으로 높은 CPU 사용량이나 디스크 공간 부족과 같이 해결해야 할 문제를 나타냅니다. 중앙 모니터링 시스템으로 전송되어 분석 및 조치를 취할 수 있죠. 이를 통해 Manager는 큰 문제가 발생하기 전에 잠재적인 문제를 신속하게 식별하고 해결할 수 있습니다.
SNMP Trap의 방식과 기능을 네 가지로 나누어 살펴보겠습니다.
(1) 비동기적 알림
SNMP Trap는 주기적인 폴링이 아닌, 이벤트 기반의 알림을 통해 즉각적으로 대응할 수 있도록 비동기적인 방법을 제공합니다.
(2) 실시간 알림
SNMP Trap은 이벤트가 발생하는 즉시 알림을 제공하여, 실시간으로 네트워크 상태 및 장치 상태를 모니터링해서 문제 발생 시 즉각적인 대응과 조치를 가능하게 합니다.
(3) 이벤트 기반 모니터링
SNMP Trap은 장치나 응용 프로그램에서 특정 이벤트가 발생했을 때만 알림을 보내기 때문에, 불필요한 트래픽을 발생시키지 않습니다. 따라서 자원을 효율적으로 사용하면서 중요한 상태 변경을 식별합니다.
(4) 자동화된 대응
SNMP Trap을 사용하면 이벤트 발생 시, 자동으로 대응 조치를 취할 수 있는 자동화 시스템을 구축할 수 있습니다. 이를 통해 관리자의 개입 없이 특정 이벤트에 대한 대응을 효과적으로 수행할 수 있습니다.
[그림] Zenius Syslog 감시 설정 등록 페이지(위), Zenius Syslog 이벤트 페이지(아래)
이와 같은 SNMP Trap을 통해 빠르게 이상을 탐지하는 것이 중요한데요. 제니우스(Zenius)-Syslog와 Trap에서는 Syslog, Trap에 각각 특정 이벤트 조건을 설정하여 이벤트를 감지하고, 장애를 통보할 수 있는 기능을 제공하고 있습니다.
이제 마지막으로 SNMP 못지않게 네트워크 관리에 중요한 역할을 하는 Syslog, RMON에 대해서 알아보겠습니다.
ㅣ Syslog, RMON의 개념과 동작원리는?
Syslog
Syslog는 컴퓨터 시스템, 네트워크 장비, 보안 장비 등에서 일어나는 모든 상황과 변화를 서버에 기록하는 프로토콜입니다. 관리 대상인 장비에서 일어나는 모든 상황을 메모리에 기록하죠. 로그/오류 관리가 주 목적이고 Unix와 Linux에서 많이 사용됩니다.
대부분의 라우터와 스위치들은 Syslog 프로토콜을 이용하여 Log들을 Syslog 서버로 보내고, 수백수천 대의 장비에 일일이 접속하여 로그를 볼 수 없기 때문에 '중앙 집중식'으로 관리합니다.
작업 방식은 주로 Client-Push 모델로 이러우지고 있고, 장비에서 일어나는 모든 상황 변화를 Layer4 프로토콜이 메모리에 기록하며, Syslog 서버는 UDP 포트 514에서 메세지를 수신합니다.
Syslog 수집항목은 시스템 운영/네트워크/보안/애플리케이션 등과 관련된 로그를 수집 및 분석하고, 각 항목별로 오류와 트랜잭션 등에 대한 내용을 확인합니다.
출처ⓒ viettelco.net
RMON
RMON(Remote Network Monitoring)은 네트워크 장비나 서버에서 발생하는 트래픽과 문제들을 원격에서 감시하기 위해 만들어진 프로토콜로, SNMP보다 확장된 개념이라고 할 수 있습니다.
네트워크 관리자는 RMON을 통해, 네트워크의 성능을 측정하고 문제가 발생했을 때 신속하게 해결할 수 있습니다. 회사에서 인터넷이 느려지거나 연결이 되지 않을 때 RMON을 사용하면 원인을 빠르게 찾아내어 문제를 해결할 수 있죠.
RMON과 SNMP의 연관성을 우선 아래 이미지를 통해 살펴보겠습니다.
출처ⓒ dpstele.com/blog/what-is-rmon.php
좀 더 자세히 살펴보면
◾ RMON은 SNMP 위에서 작동하며, SNMP 보다 더 광범위한 데이터를 수집/분석할 수 있는 기능을 제공합니다.
◾ SNMP가 네트워크의 '기본적인 통신'을 담당한다면, RMON은 그 위에서 보다 '세밀한 관찰과 분석'을 가능하게 합니다.
◾ RMON은 SNMP의 특정 데이터를 사용하여 네트워크 트래픽 패턴이나, 성능 문제, 네트워크 내의 비정상적인 활동 등을 실시간으로 감시하고 기록할 수 있게 해줍니다.
◾ RMON에서 Probe라는 수행 장비를 사용하며, 네트워크 트래픽 및 통계 수집 그리고 성능 모니터링을 위해 활용합니다.
결과적으로 RMON의 기능을 통해 네트워크의 문제를 더 빨리 발견하고, 효율적으로 대응할 수 있죠.
마지막으로 SNMP, RMON, ICMP, Syslog의 주요 내용들을 아래 표를 통해 한눈에 살펴보겠습니다.
。。。。。。。。。。。。
지금까지 네트워크 정보 수집을 위한 다양한 프로토콜의 종류와 특징에 대해서 알아보았습니다. 효과적인 네트워크 관리를 위해서 혁신적인 기술들이 많이 개발되고 있는데요, 이를 활용해서 성공적으로 네트워크를 운영하시기를 바라겠습니다!
#네트워크 프로토콜
#SNMP
#RMON
#ICMP
#Syslog
임형섭
프리세일즈팀
안정적이고 효과적인 비즈니스 운영을 위한 고객 맞춤형 IT 인프라 모니터링 시스템을 제안합니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
금융권에서 꾸준히 각광받는 제니우스(Zenius)
금융권에서 꾸준히 각광받는 제니우스(Zenius)
지난해 10월 일본의 은행 간 결제 시스템이 이틀간 '먹통'이 된 사태가 발생했었습니다. 그리고 한 달 후에는 카드 결제 데이터를 처리하는 일본 카드 네트워크의 시스템 오류로 인해 일본 각지에서 7시간 넘게 시민들이 카드 사용을 못 하는 불편이 발생하기도 했죠. 일본의 사례와 같이 은행이나 카드회사 등의 금융회사에서 네트워크/서버의 장애가 발생할 경우 궁극적으로 이익과 신뢰도의 급감으로 이어질 수 있습니다. 그렇기 때문에 '사고 없는' IT 인프라 환경 운영을 위한 노력을 이어가는 가운데, 브레인즈컴퍼니의 제니우스(Zenius)을 활용하는 금융기관이 꾸준히 증가하고 있습니다. ㅣ제니우스, 금융기관에서 꾸준히 각광받다 앞서 언급한 대로, 제니우스를 도입하고 활용하는 금융기관이 꾸준히 늘고 있습니다. 최근 수협중앙회는 '통합관제 및 운영 자동화'를 위해, 그리고 새마을금고는 '빅데이터 플랫폼 고도화'를 위해 제니우스를 도입했습니다. 또한 한국수출입은행과 한국 주택금융공사도 서버와 네트워크 관리를 위해 제니우스를 활용하고 있습니다. 이 밖에도 NH 뱅크, 신협중앙회, 광주은행, IBK 투자증권, DB손해보험 등에서도 꾸준히 제니우스를 활용하고 있습니다. 그렇다면 금융기관에서 제니우스를 꾸준히 사용하고 있는 이유는 무엇일까요? ㅣ제니우스의 네 가지 강점 금융기관에서 꾸준히 각광받는 제니우스는 크게 네 가지의 강점이 있습니다. [1] IT 인프라에 대한 통합 관리 제니우스는 금융기관의 복잡한 IT 환경을 통합 관리할 수 있는 기능들을 제공합니다. 이를 통해 IT 인프라의 성능 및 장애 정보를 빠르게 파악할 수 있어서, 운영 효율성과 안정성을 크게 높을 수 있습니다. [2] 보안 강화 금융기관에 필수적인 높은 수준의 보안을 유지할 수 있도록 제니우스는 통합 로그 관리, 보안 취약점 점검 등의 보안 기능을 제공합니다. 이를 통해 보안 위협에 대응하고 사전에 예방할 수 있습니다. [그림] 제니우스(Zenius) 오버뷰 예시화면 [3] 장애 대응 및 예방 실시간 모니터링과 자동 장애 복구 기능으로 시스템 장애에 대한 신속한 예방과 대응이 가능합니다. 이를 통해 서비스 중단을 최소화하고, 고객 만족도를 높일 수 있습니다. [4] 클라우드 서비스 지원 쿠버네티스 활용을 비롯한 클라우드 환경으로의 전환은 금융기관의 중요한 이슈로 떠오르고 있습니다. 제니우스는 모든 클라우드 환경(퍼블릭, 프라이빗, 하이브리드)에 대한 모니터링이 가능하여, 클라우드 서비스 안정성과 효율성을 크게 높여줍니다. 제니우스(Zenius)는 앞서 살펴 본 금융기관뿐 아니라, 공공기관과 기업을 포함한 1,000곳 이상에서 활발히 활용되고 있습니다. CSAP 인증과 GS 인증 1등급도 획득한 제니우스를 통해 성공적인 IT 인프라를 관리하시기 바랍니다.
2024.04.16
제니우스 SIEM(통합로그관리 시스템), 클라우드 서비스 확산 사업 서비스로 선정
제니우스 SIEM(통합로그관리 시스템), 클라우드 서비스 확산 사업 서비스로 선정
브레인즈컴퍼니의 IT 인프라 통합로그관리 시스템인 '제니우스 SIEM'이 과기부와 정보통신산업진흥원이 주관하는 '2024년 중소기업 클라우드 서비스 보급 확산 사업'의 공급 서비스로 선정됐습니다! ㅣ중소기업 클라우드 서비스 보급 확산 사업이란? 이 사업은 국내 중소기업들이 클라우드 기반의 디지털 서비스를 더 활발하게 사용하게 되는 것이 가장 큰 목적입니다. 위 이미지 상의 '수요기업'이 공급 서비스를 선택하여 이용 신청을 하면, 운영 기관에서 수요기업의 환경(산업 분야, 기업 규모 등)를 고려하여 도입 컨설팅 및 이용료를 지원합니다. 지원은 크게 두 가지 부문으로 일반지원과 집중 지원으로 나누어 진행되는데요. 일반지원으로 신청하여 최종 선정되면 최대 1,550만 원을, 집중 지원은 최대 5,000만 원을 지원받을 수 있습니다. (단, 자부담금은 20%) 브레인즈컴퍼니는 이번 사업에서 재무 건정성과, 통합로그관리 시장에서의 Zenius(제니우스) SIEM의 영향도를 높이 평가받아 제공기업으로 선정될 수 있었습니다. ㅣ제니우스(Zenius) SIEM은? 이번 사업의 공급 서비스로 등록된 제니우스 SIEM은, 이기종의 다양한 장비에서 발생되는 로그(Log)를 수집 및 분석하고 모니터링할 수 있는 솔루션입니다. AI 기술을 기반으로 한 SIEM을 통해 효율적인 실시간 모니터링과 컴플라이언스 준수, 그리고 보안 위협에 대한 대응 체계를 수립할 수 있어 시장에서 좋은 평가를 받고 있습니다. [그림] 제니우스 SIEM 예시 화면 높은 기술력과 품질을 인정받아 2023년에 CC 인증과 GS 인증 1등급을 획득하기도 한 SIEM은, 현재 인천공항공사를 비롯한 다수의 공공기관 및 기업에서 도입 후 사용 중에 있습니다. 제니우스 SIEM의 주요 특정점은 빠른 인덱싱 및 검색 속도, 무중단 스테일 아웃, 복합 이벤트 처리(CEP), 그리고 사용자 상황에 맞춘 사용자 정의 대시보드, 강력한 통계 분석 기능 등이 있습니다. 결과적으로 제니우스 SIEM을 통해 대용량 로그에 대한 통합 관리, 사이버 침해 위협에 대한 보안 대응 체계 마련, 컴플라이언스 준수 등의 목적을 이룰 수 있습니다. 다양한 기능을 탑재한 제니우스 SIEM을 통해, 대용량 로그에 대한 실시간 통합 모니터링 체계 구축하고 보안 위협에도 효과적으로 대응하시기 바랍니다.
2024.04.16
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
Java APM 기반 기술에 대한 간략한 설명
Java APM 기반 기술에 대한 간략한 설명
몇 년 전부터 미국 실리콘밸리에서 불어온 스타트업 광풍이 인플레이션과 경기 침체가 동시에 예상되는 최악의 전망 속에서 조금 사그러드는 모습입니다. 그러나 빠른 속도로 퍼지기 시작한 IT 관련 유행들은 아마 꽤 오랜 시간 우리들 근처에 남아 그 영향이 지속되지 않을까 예상해봅니다. 그 중 한 부분을 차지하는 것이 새로운 혹은 인기가 급상승한 Go, Python, R, Julia, Kotlin, Rust, Swift 등의 컴퓨터 언어들입니다. 이렇게 많은 언어들이 새로 등장해 번쩍번쩍하는 장점을 뽐내고 있는 와중에도, 아직 세상의 많은 부분, 특히 ‘엔터프라이즈 IT’라 불리는 영역에서 여전히 가장 많이 사용되는 것은 Java입니다. 절대적이지는 않지만 컴퓨터 언어의 인기 순위 차트인 TIOBE 인덱스에 따르면, 2022년 6월 현재도 Java의 인기는 Python, C의 뒤를 잇는 3위입니다. Java 역시 Java 9부터는 십 수년간 고수하던 백워드 컴패티빌리티 정책을 포기하고 여러가지 반짝거리는 장점을 받아들이면서 버전업을 계속해, 올해 9월에는 Java 19가 나올 예정입니다. 그러나 아직도 우리나라 ‘엔터프라이즈 IT’에서 가장 많이 쓰이는 버전, 그리고 작년까지는 세계에서 가장 많이 쓰이는 버전은 Java 8이었습니다. 이렇게 많은 Java 어플리케이션의 성능을 모니터링하고 관리할 수 있는 솔루션을 통상적으로 APM(Application Performance Management)이라고 합니다. 위에서 서술한 것처럼 다른 컴퓨터 언어들의 인기가 올라가고 사용되는 컴퓨터 언어가 다양해지면서 많은 APM 제품들이 Java외의 다른 컴퓨터 언어로 작성된 어플리케이션도 지원하는 경우가 늘어나고 있으나, 이 글에서는 APM을 Java 어플리케이션의 성능을 모니터링하고 관리할 수 있는 솔루션으로 한정하도록 하겠습니다. 어플리케이션의 성능을 보다 깊이 모니터링하는데 필수적인 것이 Trace[i]입니다. Trace는 어플리케이션이 실행되는 과정에 중요하다고 생각되는 부분에서 중요하다고 생각되는 어플리케이션의 상태를 기록으로 남긴 것입니다. 전통적인 어플리케이션에서는 실행 Thread를 따라가면서 순차적인 Trace가 남게 되고 유행에 맞는 MSA(Micro-Service Architecture) 어플리케이션에서는 서로 연관됐지만 직선적이지는 않은 형태의 Trace가 남게 됩니다. 이러한 Trace를 수집하고 추적하고 분석하는 것이 APM의 주요 기능 중 하나입니다. 그런데, 여기서 문제가 하나 생깁니다. Trace는 누가 남길 것인가 하는 문제입니다. 개발 리소스가 충분하고 여유가 있는 경우, 개발시 성능에 대한 부분에 신경을 써서 개발자들이 Trace를 남기며 이를 분석하고 최적화하는 것이 정례화, 프로세스화 돼있겠지만, 많은 경우 개발 리소스를 보다 중요한 목표 달성을 위해 투입하는 것도 모자랄 지경인 것이 현실입니다. 아무리 분석 툴인 APM이 좋아도, 분석할 거리가 되는 Trace가 없으면 무용지물이 돼 버립니다. 그래서 APM에는 미리 정해진 중요한 시점에 어플리케이션에서 아무 것도 하지 않더라도 자동으로 Trace를 남기도록 하는 기능이 필수적으로 필요합니다. Java 어플리케이션의 경우 이러한 기능은 Java Bytecode Instrumentation이라고 하는 기반 기술을 사용해 구현됩니다. 서론이 매우 길어졌지만, 이 글에서는 Java Bytecode Instrumentation에 대해 조금 상세히 살펴보도록 하겠습니다. Java Bytecode Instrumentation을 명확히 이해하려면, 먼저 Java가 아니라 C, C++, Rust등의 언어들로 작성된 프로그램이 어떤 과정을 거쳐서 실행되는가, 그리고 Java 프로그램은 어떤 과정을 거쳐서 실행되는가를 살펴보는 것이 도움이 됩니다. Java가 세상에 나오기 이전에는 ‘컴퓨터 학원’이나 고등학교 ‘기술’ 과목, 그리고 대학의 ‘컴퓨터 개론’ 등에 반드시 이런 내용이 포함돼 있었지만 요즘은 그렇지도 않은 것 같습니다. 컴퓨터에서 프로그램을 실행시키는 것은 CPU, 즉 Central Processing Unit입니다. 지금 이 글을 작성하고 있는 컴퓨터의 CPU는 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz입니다. CPU는 메모리의 프로그램이 있는 영역을 읽어 들여, 미리 정해진 값에 따라 정해진 동작을 수행하게 됩니다. 이때 어떤 값이 어떤 동작을 수행하는지 규정해 놓은 것을 Machine Language라고 합니다. Machine Language는 100% 숫자의 나열이므로 이를 좀더 사람이 읽기 쉬운 형태로 1:1 매핑 시킨 것이 Assembly Language입니다. (그렇다고 읽기가 많이 쉬워지지는 않습니다.) 이 글에서는 이 두 단어를 구분없이 혼동해 사용합니다. C, C++, 그리고 나온 지 벌써 10년이나 된 Go, 요즘 인기가 계속 상승하고 있는 Rust 등의 언어로 작성된 프로그램은, 이들 언어로 작성된 소스 코드를 Machine Language로 미리 변환해서[ii] 실행 파일을 만들고 이를 실행하게 됩니다. 이 변환을 수행하는 것을 Compile한다라고 하고 이 변환을 수행하는 프로그램을 Compiler라고 부릅니다. 한편, 소스 코드를 완전히 Machine Language로 변환시킨 실행 파일을 실행하는 것이 아니라 Interpreter라 불리우는 프로그램이 소스 코드를 읽으면서 그 의미에 맞게 동작을 수행시키는 언어들도 있습니다. ‘스크립트 언어’라 불리는 bash, Perl, PHP, Ruby, Python 등이 이에 해당되면, 요즘은 잘 쓰이지 않지만 그 옛날 Bill Gates가 직접 Interpreter를 만들기도 했던 BASIC 등이 이에 해당합니다. 본론으로 돌아가보겠습니다. 그렇다면, Java 프로그램은 어떤 방식으로 실행이 되는가? 기본적으로는 Interpreter 방식이라고 생각해도 이 글의 주제인 Java Bytecode Instrumentation을 이해하는 데는 무리가 없습니다.[iii] 여기에 더해 Java의 실행 방식에는 몇 가지 큰 특징이 있습니다. 첫째로, Java는 소스 파일을 직접 읽어 들이면서 실행하는 것이 아니라 소스 파일을 미리 변환시킨 Java Class File을 읽어 들이면서 실행합니다. 하나의 Java Class File에는 하나의 Java Class 내용이 모두 포함됩니다. 즉, Class의 이름, public/private/internal 여부, 부모 클래스, implement하는 interface 등의 Class에 대한 정보, Class의 각 필드들의 정보, Class의 각 메서드[iv]들의 정보, Class에서 참조하는 심볼과 상수들, 그리고 이 글에서 가장 중요한 Java로 작성된 각 메서드의 내용을 Java Bytecode 혹은 JVM Bytecode라고 하는 중간 형태의 수열로 변환시킨 결과 등이 Java Class File에 들어가게 됩니다. 이 Java Bytecode는 실제 실행 환경인 CPU 및 Machine 아키텍처에 무관합니다. 똑같은 Java 소스 코드를 Windows에서 Compile해 Java Class File로 만들건, Linux에서 Compile해 Java Class File로 만들건 그 내용은 100% 동일하게 되고 이 점은 C, C++, Rust 등 Compiler 방식의 언어와 큰 차이점입니다. Java의 가장 큰 마케팅 캐치프레이즈 “Write Once, Run Anywhere”는 이를 표현한 것입니다. 둘째, Java Bytecode는 일반적인 CPU의 Machine Language와 많은 유사점을 지닙니다.[v] 어찌 보면 Java Bytecode는 실제 존재하지는 않지만 동작하는 가상의 CPU의 Machine Language라고 볼 수 있는 것입니다. 이러한 이유에서 Java Class File을 읽어 들여 실행시키는 프로그램을 JVM이라고 (Java Virtual Machine) 부릅니다. Java 소스 파일을 Java Class File로 변환시키는 프로그램을 Java Compiler라고 부르며, 가장 많이 쓰는 Java Compiler는 JDK(Java Development Kit)에 포함된 javac라고 하는 프로그램입니다.[vi] JVM은 JDK에 포함된 java라고 하는 프로그램을 가장 많이 씁니다. 한편 사용 빈도는 그렇게 높지 않지만, Java Class File을 사람이 알아볼 수 있는 형태로 변환해서 그 내용을 보고 싶은 경우도 있습니다. 이런 일을 하는 프로그램을 Java Bytecode Disassembler[vii]라고 부르며, JDK에는 Java Bytecode Disassembler인 javap가 포함돼 있습니다. 혹은, Eclipse나 Intellij IDEA 같은 IDE에서 Java Class File을 로드하면 사람이 알아볼 수 있는 형태로 변환해 보여줍니다. Java Bytecode의 실제 예를 한번 살펴보도록 하겠습니다. 설명을 간단히 하기 위해, 클래스나 메서드 선언 등은 다 제외하고, 오직 메서드의 내용에만 집중하면, System.out.println(“Hello, World.”); 라는 Java 프로그램은 다음과 같은 Java Bytecode로 변환됩니다. (전통적으로 16진수로 표시합니다.) b2 00 0b 12 09 b6 00 0f b1 이를 javap를 사용해, 혹은 JVM Reference[viii]를 보고 좀더 사람이 보기 쉬운 형태로 표현하면 다음과 같습니다. 0: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #9 // String Hello World 5: invokevirtual #15 // Method java/io/PrintStream.println: (Ljava/lang/String;)V 8: return JVM Reference의 Chapter 7을 참고하면, Java Bytecode를 javap의 결과에 어떻게 대응되는지를 알 수 있습니다. javap의 결과를 조금 더 살펴봅시다. 먼저 콜론 앞의 숫자는 인스트럭션의 offset으로서 Bytecode 시퀀스의 0번째, 3번째, 5번째, 8번째를 의미합니다. 0번째의 getstatic은 그 다음 숫자에 해당하는 필드를 스택의 맨 위에 저장하도록 합니다. 3번째의 ldc는 “Hello, World”라는 상수값을 스택의 맨 위에 저장하도록 합니다. 5번째의 invokevirtual은 println 메서드를 호출하고, 8번째의 return은 메서드에서 리턴해 호출한 곳으로 실행을 넘깁니다. Java 프로그램은 (정확히는 Java 소스 코드로 작성된 프로그램을 Compile한 결과) 통상적으로 많은 수의 Java Class File로 이뤄집니다. JVM은 이러한 Java Class File을 한꺼번에 읽어 들이는 것이 아니라 실행을 하다가 필요한 순간이 되면 그 때 읽어 들입니다. JVM은 이 로딩 과정에 사용자가 개입할 여지를 남겨 뒀는데, 이것이 Java Bytecode Instrumentation입니다. 이에 대한 개요는 https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html에 설명돼 있습니다. 요약해서 설명하면 다음과 같습니다. (1)사용자는 미리 정해진 규약대로 Java Agent라는 프로그램을 작성하고 이를 JVM 실행시에 옵션으로 명기합니다. (2)JVM은 Java Class File을 읽어 들여서 JVM이 처리하기 좋은 형태로 저장하기 전에, 그 파일 내용을 Java Agent의 ClassFileTransformer 클래스의 transform 메서드[ix]에 전달합니다. (3)JVM은 Java Class File의 원래 내용이 아니라 (2)의 메서드가 반환하는 결과를 저장하고 실행합니다. 이 과정을 Java Bytecode Instrumentation이라고 합니다. 사용자는 Java Bytecode Instrumentation을 구현해, 즉 Java Agent를 잘 작성헤 무엇이든 원하는 바를 달성할 수 있는 것입니다![x] 이러한 Java Bytecode Instrumentation은 APM, 그리고 Aspect-Oriented Programming의 기반 기술이 됩니다. 우리나라에서 Java로 프로그래밍을 한다고 하면 누구나 다 알고 있을 것 같은 Spring Core의 핵심 요소 중의 하나가 Aspect-Oriented Programming입니다. 예를 들어 Spring에서 @Transaction 이라고 annotation된 메서드가 있으면, Spring은 그 메서드의 맨 처음에 transaction을 시작하는 코드, 정상적으로 return하기 직전에는 transaction을 commit하는 코드, 그리고 익셉션에 의해 메서드를 빠져 나가기 직전에는 transaction을 rollback하는 코드를 삽입해 주게 되는데 이를 Java Bytecode Instrumentation을 이용해 구현하는 것입니다. 그럼, Java Agent에 거의 무조건적으로 필요한 기능은 무엇일까요? Java Agent는 Java Class File 내용을 그대로 전달받기 때문에 이를 해석할 수 있어야 무언가를 할 수 있습니다. 불행히도, java 스탠다드 라이브러리에는 Java Bytecode를 직접 다루는 기능은 없습니다.[xi] 그래서 de facto standard로 사용되는 것이 asm이라는 라이브러리입니다. 이 라이브러리는 수많은 java 라이브러리와 어플리케이션에 포함돼 있습니다. 그러나 asm이 훌륭한 라이브러리이긴 하지만, 이를 직접 사용하려면 각 상황에 맞게 코드를 삽입하는 프로그램을 작성해서 사용해야 하므로 자유도가 떨어집니다. 그래서 Zenius APM에서는 asm을 사용하되 삽입될 코드를 설정 파일에서 지정할 수 있는 suji(Simple Universal Java Instrumentor)[xii]라고 이름 붙인 라이브러리를 직접 만들어 사용하고 있습니다. suji를 사용하면 yaml 형식의 설정 파일에서, 어떤 클래스의 어떤 메서드의 어느 부분에 삽입할 것인지에 대한 조건과 삽입될 코드를 yaml의 list 형태로 지정하는 것만으로 (이는 Lisp와 비슷한 방식으로, 이렇게 하면 파싱 과정을 생략하면서 쉽게 코드를 넣을 수 있습니다.) Java Bytecode Instrumentation을 손쉽게 처리할 수 있습니다. 예를 들어, Zenius APM에서 JDBC getConnection을 처리하기 위해서 다음과 같은 부분이 설정 파일에 포함돼 있습니다. JDBC.DataSource.getConnection: IsEnabled: true ClassChecker: [ HasInterface, javax/sql/DataSource ] MethodName: getConnection IsStatic: false IsPublic: true IsDeclared: false ReturnType: Ljava/sql/Connection; Locals: [ Ljava/lang/Object;, Ljava/lang/Object; ] AtEntry: - [ INVOKE, dataSourceGetConnection, l1, [] ] AtExit: - [ INVOKE, poolGetConnectionEnd, l2, [ l1, ^r, true ] ] - [ LOAD, l2 ] - [ CAST, Ljava/sql/Connection; ] - [ STORE, ^r ] AtExceptionExit: - [ INVOKE, endByException, null, [ l1, ^e ] ] 간략하게 설명하면, Class가 만약 javax.sql.DataSource를 implement하고 메서드가 스태틱이 아니고 public이면서 java.sql.Connection을 리턴하는 getConnection이라는 이름을 가진 경우에 메서드 시작 시, 리턴 시, 그리고 익셉션에 의해 메서드를 나갈 때 위의 예제에 규정된 코드를 삽입하라는 의미입니다. 이상으로 Java Bytecode Instrumentation에 대한 간략한 설명을 마칩니다. 다음에는 실제로 APM이 중점적으로 추적하고 분석하는 것은 어떤 것들인가에 대해 설명하겠습니다. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [i] Sridharan, Distributed Systems Observability, O’Reilly, 2018의 Chapter 4. The Three Pillars of Observability 참조. 번역본은 없는 듯합니다. [ii] 이 외에 여러가지 과정을 거치지만 이 글의 목적과는 무관하므로 과감하게, 자세한 설명은 생략합니다. [iii] 실제로는 Java 프로그램이 100% 이렇게 interpret되어 실행되는 것은 아닙니다. 특정 메쏘드 혹은 메쏘드의 일부분이 자주 실행돼 interpret하는 것보다 미리 컴퓨터(=CPU)가 바로 실행할 수 있는 형태(=Machine Language)로 변환(=compile)해 놓는 것이 더 낫다고 JVM이 판단하는 경우, 미리 이런 변환 과정을 한번 거쳐 그 결과를 기억해 놓고, 그 기억된 결과를 컴퓨터(=CPU)가 바로 실행합니다. 이렇게 변환하는 과정을 Just-In-Time Compile 혹은 JIT라고 합니다. 또 이 때문에 JVM을 단순한 interpreter로 부를 수는 없는 것입니다. [iv] 국립국어원은 메서드가 맞는 표기라고 합니다. [v] 물론 많은 차이점도 지닙니다. (1) JVM은 register가 존재하지 않고 오로지 stack에만 의존한다. (2) JVM은 Class, Method의 개념을 포함하고 있지만 일반적인 범용 CPU에는 그런 상위 개념은 없습니다. [vi] 보통 IDE를 써서 개발을 하기 때문에, javac를 직접 사용하거나 Java Class File을 직접 다룰 일은 잘 없고, jar 파일이 이 글을 읽는 여러분에게 훨씬 더 익숙할 지도 모릅니다. Jar 파일은 그냥 zip으로 압축된 파일이니 그 압축을 한번 풀어 보길 바란다. 확장자가 class인 수많은 파일을 찾을 수 있을 것입니다. [vii] Assembly는 Assemble의 명사형이며, Assemble의 반대말은 Disassemble입니다. [viii] JVM에 대한 모든 것은 The Java Virtual Machine Specification에 나와 있습니다. 이 중 'Chapter 6. The Java Virtual Machine Instruction Set'를 참고하면 각각의 instruction에 대해 상세히 알 수 있습니다. [ix] https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/ClassFileTransformer.html#transform-java.lang.ClassLoader-java.lang.String-java.lang.Class-java.security.ProtectionDomain-byte:A- [x] 쉽다고는 하지 않았습니다. 또 몇가지 제약 사항은 있습니다. [xi] 참고로 최근에는 asm을 대체할 수 있는 기능을 스탠다드 라이브러리에 넣을 계획이 진행되고 있습니다. https://openjdk.org/jeps/8280389 [xii] 명명이 아이돌 그룹 출신 모 여배우와 관계가 아주 없지는 않음을 조심스럽게 밝혀 둡니다.
2022.08.04
다음 슬라이드 보기