1. 늦은 후기
지난 9.12일 코엑스에서 toss 기술 개발 conference인 toss slash24를 관람했다. 참가는 무료였고, 사전에 신청하여 후루룩 입장했다.
늦은 후기를 전달하자면, 사람이 매우 많아서 힘들었다. 쉴 공간도 별로 없었고 세미나 좌석 간격도 너무 좁아서 옆에서 노트북하고 소근소근 떠들던 사람들 말이 다들렸다. 그래서 그런지 조금 부산스러웠다. 그리고 매너 없는 사람들도 있었는데, 발표자 앞에두고 별로 중요하지도 않아보이는 슬랙 메시지 바쁜 척 보면서 코드 왔다갔다하면서 키보드 소리 내고 있으니 같이 듣는 입장으로서 몹시 불편했다.
이것 말고는 정말 재밌었던 세미나였다. 채용 상담부스도 있었고 각종 기업들도 많이 와주셔서 이벤트도 해주셔서 재미난 상품들을 많이 받았다.
그리고 가장 좋았던 것은 미리 소규모 테크세션을 예약해두면 발표자 분과 이야기를 할 수 있는 기회가 있었다. 필자는 해당 세션 발표자분들과 이야기 할 수 있는 시간을 가졌다.
발표자인 두 분과 30~40분 동안 재밌게 이야기 할 수 있어서 좋았다. SRE, Devops 개발자로서 서로 공감하고 어려웠던 점들에 대해 공유하며 뭔가 힐링(?)이 되었던 것 같다.
추후에 toss slash를 참여하실 분들은 소규모 테크세션에 무조건 참여하기를 추천한다. 관심있는 분야의 전문가분들과 이야기 할 수 있는 시간은 인생에서 그렇게 많지 않다. 더군다나 무료? 무조건 추천한다.
2. 기억에 남는 발표
위의 '미처 알지 못했던 kernel까지 Observability 향상시키기'를 중점으로 봤다. 그 외에는 친구 따라 data관련된 발표들을 보다가 지쳐서 집으로 돌아갔다. 따라서, 기억에 남았던 '미처 알지 못했던 kernel까지 Observability 향상시키기'에 대해서 후기를 남겨보려고 한다.
영상은 아래 링크를 들어가면 된다.
https://www.youtube.com/watch?v=e8cEDhAPm-E&t=3s
올해 초에 eBPF에 대해 관심이 많아져서 Cilium의 수장인 Liz Rice(밥누나)님의 eBPF책을 읽어보고 있었다.
이건 여담이지만 Cloud관련 개발을 하시는 분들은 Liz Rice님을 알게 모르게 많이 마주쳤을 것이다. Cilium의 호카게이기도 하고, 그 유명한 '밑바닥부터 container 만들기'의 발표자이다.
https://www.youtube.com/watch?v=8fi7uSYlOdc
그런데 책을 절반쯤 읽다가 포기했었다. 이유는 다음과 같았다.
1. 내 Linux 지식이 너무 짧았다...
2. 막상 eBPF를 배워서 도입하려고 하니, 제약사항도 있고 이미 활발하게 구현되고 있는 것들이 많다.
생각보다 eBPF 기술 자체에 대한 이해를 위해서는 좀 더 깊은 linux지식도 필요하고 경험도 필요하다는 것을 깨닫게 되었다. 또한, eBPF로 뭔가 tool을 만드려고 생각해도, 이미 만들고 있는 것들이 많았다.
그렇게 내 머리 속에서 점점 희미해지던 중에 toss에서 eBPF를? 하는 생각으로 테크 세션을 등록했다. 아쉽게도 발표 내용은 eBPF의 kernel mode, user mode code들을 모두 작성하여 하나의 eBPF tool을 만드는 것이 아닌 eBPF 모니터링을 툴을 사용하여 kernel parameter를 분석했다는 내용이었다.
기대했던 내용은 아니였어도 꽤나 흥미로웠다. 그 중에 '이재성'님의 발표 내용을 요약하면 다음과 같았다. 필자의 얕은 지식으로 풀어쓴 것이기 때문에 잘못 이해한 부분이 있을 수 있다.
- eBPF 툴을 사용하여 kernel을 편리하게 분석 할 수 있게 되었다.
- 그 중 Numa에서의 remote memory hit이 많아져서 시스템이 비효율적으로 동작하고 있다는 것을 알게되었다.
- 이를 해결하기 위해 kubelet을 custom하게 수정하여 Numa의 local memory hit이 되도록 하였다.
- eBPF로 local memory hit이 늘어난 것을 확인하고, 그래프로 결과를 확인하니 시스템 효율이 꽤나 좋아졌다.
numa?? 뭔가 예전에 들어봤는데, 기억이 가물가물했다.
차 살때 딜러가 썬팅해주겠다고 하면 루마 썬팅을 추천한다.
발표를 들으면서, '아 저거 어디서 봤더라...'하다가 딱! 생각이 났다.
'DevOps와 SE를 위한 리눅스 커널 이야기'라는 책에서 봤구나! 라는 생각이 났다. 정확히는 책의 이름이 아니라, 표지가 생각나서 호다닥 이름을 찾아봤었다.
개발자든 infra담당자든 모두 읽어봤으면하는 좋은 책이다. 특히나 외국도서를 번역한 책이 아니라, 한국인이 만든 국내도서는 손에 꼽는다.
numa에 대한 내용을 정리하면 다음과 같다.
https://ko.wikipedia.org/wiki/%EB%B6%88%EA%B7%A0%EC%9D%BC_%EA%B8%B0%EC%96%B5_%EC%9E%A5%EC%B9%98_%EC%A0%91%EA%B7%BC
어렵게 이해할 필요없다. 각 CPU마다 전용 Memory를 연결해두는 것이다. 그리고 메모리끼리는 또 다른 bus를 사용해서 연결하는 것이다. 이렇게두면 CPU는 전용 memory로 바로 연결할 수 있는 bus가 있기 때문에 빠르게 메모리에 접근해 CPU와 Memory사이의 속도 차이에 의한 병목 현상을 줄 일 수 있다. 전용 memory에 접근하게되면 이를 'local memory hit'라고 한다. 그러나 내가 원하는 데이터가 전용 memory에 없고 다른 memory에 있다면 다른 memory로 접근하는 bus를 사용한다. 이를 'remote memory hit'이다.
numa 구조를 사용하면 메모리의 지역성을 이용하게되어 'local memory hit'이 많아져 성능이 더 향상된다. 그러나 'remote memory hit'이 발생하면 이에 대한 overhead가 일반적인 memory bus 구조에 비해서 느릴 수 밖에 없다.
그래서 toss에서는 kubelet을 커스텀하게 수정하여 'local memory hit'를 높이고 'remote memory hit'를 줄였다는 것이다.
eBPF로 kernel 파라미터 모니터링으로 썼다는 점도 재밌었고, numa를 다루어 kubelet을 수정했다는 내용도 재밌었다. 개인적으로 toss 컨퍼런스 발표 중 가장 인상깊었다.
한 가지 아쉬운 점은 어떻게 수정했는지도 알려줬으면 좋았을 것 같다. 물론 업계비밀(?)이겠지만 kubernetes에서도 numa에 대해서 어느 정도 논의가 있었기 때문에, 기존의 해결 방법이 아니라 새로운 해결 방법을 도입한 것인지 너무 궁금했다.
https://kubernetes.io/docs/tasks/administer-cluster/memory-manager/
또한, 굳이 kubelet 자체를 custom하게 바꿨어야 했는 지도 궁금했다. 새로운 update code와 merge도 해야하고, 잘 동작하는 kubelet을 건드려 문제가 발생할 수 있는 가능성이 생긴다는 것은 큰 부담이라고 생각한다.
additional한 application이나 operator pattern을 사용하거나 plugin를 사용하여 의존성을 줄이는 방법이 더 괜찮지 않았을까 생각한다.
여담이지만 내 옆자리 분들은 다음 세션인 '보상 트랜잭션으로 분산 환경에서 안전하게 환전하기'를 기다리던 분들이었는데, 위 테크 세션 내용을 들으면서 '뭐 저딴걸 하냐~, 개발자 아니라 저런거 하나?' 하면서 큭큭 거렸다.
어린 친구들이었고 보나마나 자신이 개발하는 세상이 전부라고 생각하는 친구들 같았다. 이번 컨퍼런스를 와서 크게 느끼고 배운건 저런 친구들과 같이 삶을 살면 안되겠구나를 많이 느꼈다.
