기술이야기 | 브레인즈컴퍼니

메인 페이지로 이동
블로그
기술이야기

블로그

에이프리카 타운홀 미팅

최순정 2022.12.06

지난 주 브레인즈컴퍼니는 클라우드•AI 플랫폼 전문기업인 에이프리카를 인수한 바 있습니다.

선근님은 지난 5일 가산에 위치한 에이프리카를 방문해, 에이프리카 구성원들에게

이번 인수를 진행하게 된 배경과 브레인즈컴퍼니 및 선근님 소개, 향후 운영방향에 대해 공유하는 시간을 가졌습니다.

에이프리카에 도착하니, 이규정 대표를 비롯한 에이프리카 직원들이 라운지에 모여 브레인즈컴퍼니를 반겨줬습니다.

이규정 대표가 선근님을 소개하며 PT가 시작됐습니다. 선근님은 먼저, 브레인즈와 에이프리카가 함께

하게 된 배경에 대해 설명했습니다.

브레인즈컴퍼니와 에이프리카 각각이 갖고 있는 장단점에 대해 설명하고,

함께 했을 때 어떤 시너지를 내며 동반성장할 수 있을지에 대해 이야기를 나눴습니다.

다음으로는 브레인즈컴퍼니에 대한 소개를 이어갔습니다.

IT 인프라 통합관리 소프트웨어 업계의 최강자인

브레인즈컴퍼니의 조직, 연혁, 주요 제품 등을 비롯한 에이프리카 직원들이 궁금해할만한 내용들을 전달했습니다.

그리고 가장 집중도가 높았던, 선근님의 본인 PR 타임!

과학고 조기졸업 후 카이스트에 진학했지만, 당구를 즐겨치다 뒤늦게 학업에 열중했던 학창시절 이야기,

브레인즈컴퍼니 합류 전 사회 생활과 합류 후 겪었던 고난,

또 본인의 MBTI와 좌우명 등 많은 이야기를 전했습니다.

선근님의 입담 덕에 에이프리카 직원들은 중간중간 웃음꽃을

피우며 즐겁게 미팅에 참여할 수 있었습니다.

마지막으로, 향후 회사 운영 방향성에 대한 장•단기 계획과 비전을 이야기했습니다.

앞으로 각 대표들이 어떤 부분을 맡아 업무를 해나갈지, 또 조직 및 프로세스는 어떻게 정비해나갈지 등에 대해 친절하게 설명을 이어갔습니다.

1시간여 간의 PT가 끝난 후 질의응답 시간을 가지며 미팅은 종료됐습니다.

에이프리카 사옥을 나서며, 브레인즈컴퍼니와 에이프리카 대표의 기념 사진!

앞으로 브레인즈컴퍼니와 에이프리카가 클라우드 및 인공지능(AI) 분야에서 시너지를 내며 동반 성장해나가길 바라며,

많은 관심과 응원 부탁드립니다!

최순정경영기획실(PR매니저)

브레인즈컴퍼니의 소식, 조직문화, 브레인저 이야기를 대내외에 전파하고 있습니다.

필진 글 더보기

추천 콘텐츠

eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링 eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링 예전에는 네트워크 성능을 모니터링할 때 tcpdump로 패킷을 캡처하거나, netstat으로 연결 상태를 확인하거나, NetFlow/sFlow 기반 분석을 많이 사용했습니다. 하지만 네트워크 환경이 복잡해지고 암호화 트래픽이 늘어나면서, 그리고 컨테이너·MSA 환경으로 서비스가 쪼개지면서 기존 방식의 패킷 기반 모니터링은 점점 한계를 드러냈습니다. 성능 부하는 커지고, 세부 가시성은 부족했습니다. 이 문제를 해결해 준 게 바로 eBPF(extended Berkeley Packet Filter)입니다. eBPF는 커널 내부 함수에 직접 훅(Hook)을 걸어서 데이터를 가져올 수 있기 때문에, 서비스에 큰 영향을 주지 않고도 운영 환경에서 실시간 성능 분석이 가능합니다. 쉽게 말해, 예전에는 netstat으로 “포트가 지금 어떤 상태인지”만 볼 수 있었다면, eBPF를 쓰면 “그 포트의 상태가 어떻게 변하고 있는지”까지 관찰할 수 있습니다. 그래서 최근 클라우드 네이티브 환경이나 초저지연 서비스 운영에서는 eBPF가 차세대 네트워크 모니터링 기술로 주목받고 있습니다. eBPF란? eBPF는 커널 안에서 안전하게 실행되는 작은 프로그램으로, 네트워크·시스템 동작을 실시간으로 추적하는 데 강점을 가집니다. 네트워크 모니터링 관점에서 자주 쓰이는 기능은 다음과 같습니다. • kprobe/kretprobe: 커널 함수 진입·종료 시점 후킹 • tracepoint: 커널 이벤트 발생 시점 후킹 • BPF Map: 커널과 사용자 공간 간 데이터 공유 • BPF Helper 함수: 커널 리소스 접근 API eBPF는 Verifier(검증기)가 프로그램의 안전성을 보장하지 못하면 로드를 거부합니다. 과거에는 Verifier가 루프의 종료를 판별하지 못해 루프 사용이 전혀 허용되지 않았지만, 최근에는 단순 반복문은 사용할 수 있게 되었습니다. 또한 BTF(BPF Type Format)와 CO-RE(Compile Once – Run Everywhere) 기술 덕분에, 커널 버전이 달라져도 동일한 eBPF 프로그램을 별도 빌드 과정 없이 그대로 운용할 수 있습니다. eBPF 사용 방법 제가 공부하면서 가장 흥미로웠던 예제는 BCC 툴셋에 포함된 **tcpstates**입니다. TCP 연결 상태 변화를 추적하는 예제인데, 구조를 간단히 정리하면 다음과 같습니다. • bpf.c: 커널에서 실행되는 함수 중 “어떤 걸 관찰할지”와 “관찰 시 어떤 데이터를 수집할지” 정의 • .h: 커널과 유저 공간이 공유하는 데이터 구조체 정의 • .c: 수집된 데이터를 가공해서 사용자에게 출력 예를 들어, tcpstates.bpf.c에서는 커널 tracepoint inet_sock_set_state를 후킹해서 TCP 상태 변화를 잡아냅니다. 아래 코드를 보면 이해가 쉬우실 겁니다. int handle_set_state(struct trace_event_raw_inet_sock_set_state *ctx) { struct sock *sk = (struct sock *)ctx->skaddr; __u16 family = ctx->family; __u16 sport = ctx->sport; __u16 dport = ctx->dport; __u64 *tsp, delta_us, ts; struct tcpstates_t tcpstates = {}; if (ctx->protocol != IPPROTO_TCP) return 0; ts = bpf_ktime_get_ns(); tcpstates.skaddr = (__u64)sk; tcpstates.ts_us = ts / 1000; tcpstates.pid = bpf_get_current_pid_tgid() >> 32; tcpstates.oldstate = ctx->oldstate; tcpstates.newstate = ctx->newstate; tcpstates.family = family; tcpstates.sport = sport; tcpstates.dport = dport; bpf_get_current_comm(&tcpstates.task, sizeof(tcpstates.task)); if (family == AF_INET) { bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_rcv_saddr); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_daddr); } else { /* family == AF_INET6 */ bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_v6_rcv_saddr.in6_u.u6_addr32); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32); } // 상태가 변경되면 유저 공간에 알리는 부분 bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &tcpstates, sizeof(tcpstates)); return 0; } 핵심 로직은 단순합니다. 커널에서 inet_sock_set_state가 호출되면 handle_set_state 함수가 실행되고, 이때 변경된 TCP 상태를 잡아내 사용자 공간으로 전달합니다. 언뜻 보면 복잡해 보일 수 있지만, 사실 bpf.c의 역할은 데이터를 가공하는 것이 아니라 수집하는 것입니다. 결국 중요한 것은 “내가 원하는 값이 구조체의 어디에 들어 있는지”를 정확히 찾아내는 일입니다. 그 값을 Map에 담아 사용자 공간으로 넘기면 됩니다. netstat으로 보이는 출력은 아래와 같죠. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.0.10:22 192.168.0.55:54321 ESTABLISHED 2048/sshd: user@pts/0 netstat은 사용자가 명령어를 실행한 시점의 상태만 스냅샷 형태로 보여줍니다. 그래서 LISTEN, ESTABLISHED, CLOSE_WAIT처럼 비교적 오래 유지되는 상태만 주로 확인할 수 있습니다. 반면 tcpstates를 활용하면 커널 내부에서 발생하는 모든 TCP 상태 변화를 이벤트 단위로 추적할 수 있습니다. 덕분에 기존 툴로는 관찰하기 어려웠던 3-way handshake와 4-way handshake 과정까지 실제로 확인할 수 있다는 점이 흥미로웠습니다. 조금 더 실무적으로 활용하자면, CLOSE_WAIT이 비정상적으로 쌓이는 경우 커넥션 누수를 빠르게 탐지할 수 있고, TIME_WAIT이나 FIN_WAIT2 패턴을 분석하면 리소스 사용량 문제를 조기에 파악할 수 있습니다. 관측용 예제지만, 확장하면 운영 환경에서도 충분히 유용한 진단 도구가 될 수 있습니다 다음으로 유저 공간의 tcpstates.c는 커널 eBPF 프로그램이 보낸 이벤트를 받아서 보기 좋게 출력하는 역할을 합니다. 흐름은 단순합니다. ①eBPF 오브젝트 열기 (tcpstates_bpf__open()) ②프로그램 커널 로드 (tcpstates_bpf__load()) ③훅 부착 (tcpstates_bpf__attach()) ④필요 시 cgroup 필터 등록 (open(), bpf_map_update_elem()) ⑤주기적으로 Map을 읽거나 이벤트를 받아 상태 출력 현재는 TCP 상태 변경 이벤트가 발생할 때마다 화면에 출력하는 방식으로 동작하지만, 필요하다면 일정 주기마다 netstat을 호출하듯이 현재 상태를 스냅샷 형태로 출력하도록 구현할 수도 있습니다. 마무리하며 이처럼 간단한 코드만으로도 tcpdump나 netstat보다 훨씬 세밀하게 네트워크 흐름을 분석하는 프로그램을 만들 수 있습니다. tcpstates 같은 예제는 단순하지만, eBPF의 장점을 잘 보여줍니다. • 저부하 eBPF는 패킷 전체를 캡처하지 않고, 연결 상태나 세션 정보 같은 핵심 메타데이터만 선택적으로 수집합니다. 이로 인해 CPU와 메모리 사용 부담이 최소화되며, 운영 중인 서비스에 성능 저하를 거의 일으키지 않습니다. 즉, 실서비스 환경에서도 안정적으로 적용 가능한 경량 모니터링 방식입니다. • 높은 가시성 단순히 IP와 포트 수준의 정보만 보여주는 데 그치지 않고, 프로세스명·PID·서비스 단위까지 트래픽을 구분할 수 있습니다. 이를 통해 “어떤 서비스가 얼마만큼의 네트워크 자원을 소비하는지”를 즉시 파악할 수 있으며, 서비스별 자원 사용 현황을 보다 세밀하게 모니터링할 수 있습니다. • 확장성 기본적인 송·수신량 분석을 넘어, RTT(왕복 지연시간), 재전송률, 패킷 드롭률 등 다양한 지표를 손쉽게 확장할 수 있습니다. 필요한 메트릭을 커널 훅(Hook)에 연결해 Map에 저장하기만 하면, 곧바로 시각화와 분석에 활용할 수 있습니다. 이 덕분에 환경 변화나 분석 요구에도 유연하게 대응 가능한 구조를 제공합니다. 브레인즈컴퍼니 역시 이 기술을 Zenius NPM(Network Performance Monitoring)에 적용하면서 기존 방식으로는 확인하기 어려웠던 세밀한 성능 데이터를 확보할 수 있었습니다. 이를 통해 단순한 모니터링을 넘어 서비스 간 통신 병목을 실시간으로 파악하고, 장애 분석 시간을 크게 줄일 수 있는 솔루션을 완성할 수 있었던 점이 큰 성과였습니다. 앞으로도 이러한 경험을 바탕으로 eBPF 활용을 더 넓혀가고자 합니다. 2025.09.18