안녕하세요! NewCodes입니다.
DAN 25 네이버 컨퍼런스 DAY2
후기를 남겨보려 해요.
2025.11.07(금) 코엑스에 다녀왔습니다!
네이버 부스트캠프 웹모바일 수료생에게
티켓을 나눠주셔서 다녀올 수 있었어요.
덕분에 정말 좋은 경험 하고 왔습니다!!
함께 살펴보시죠!
DAN25 둘러보기!
처음에 입장하면 큰 배너가 반겨줍니다.
연결의 진화, 경험의 확장
플랫폼으로서의 역할을 지속하되 새로운 도전을 계속해서 한다는 문구 같네요!
DAN25에서 이 문구가 어울리는 건 '네이버지도'가 있었어요. 이번에 리브랜딩을 하면서 새로운 기능들을 많이 추가했더군요.
가장 인상 깊었던 건 AR 기술을 통해서 실내에서도 길을 찾을 수 있다는 점이에요. 코엑스와 같이 넓은 실내 공간일 경우 길을 찾기 어렵곤 한데요. 이러한 문제를 해결하는 기능을 도입했더군요!
마치 카트라이더처럼 가는 길을 알려줍니다! 포켓몬고가 떠오르기도 하네요.
아직 많은 장소를 지원하고 있진 않지만, 코엑스에서는 된다고 하니 갈 일 있으면 사용해보셔요!
아래처럼 많은 인파 속에서도 길을 찾는 데 네이버지도가 도움이 되어줄 겁니다 ㅎㅎ
NFT 이벤트에 참여해서 커피를 받기도 했어요!
NFT 이벤트는 DAN 25 행사장 3군데에서 NFT를 모아오면 참여할 수 있어요.
그 중에 하나가 네트워킹 존에서 받은 NFT인데요.
네트워킹 존에서는 아래와 같이 메모지를 통해 질문과 답변을 주고받을 수 있어요.
인상 깊었던 질문과 답변을 찍어봤어요. 핵심 키워드는 문제해결, 사용자 입장, 협업이네요!
신입 공채를 지원한다면 '신입들 사이에서 내가 이것만큼은 정말 자신있다'라고 생각하는 게 있으면 좋겠군요. 노력해봐야겠어요 ㅎㅎ
세션 듣기! - What’s In Our Infra: 대규모 트래픽을 수용하기까지
각종 활동 및 부스에 참여한 뒤에는 세션을 들었는데요. 저는 총 3개의 세션을 들었습니다. 그 중에서 가장 인상 깊었던 세션에 대해 소개해보려 해요. 'What's In Our Infra: 대규모 트래픽을 수용하기까지'입니다.
NAVER Cloud IT service의 강은영 Tech Lead님께서 세션을 진행해주셨어요.
목차는 아래와 같습니다.
이 중에서도 2번 목차에 대해 자세히 남겨볼게요.
대규모 트래픽을 처리하기 위해서는 당연히 많은 서버가 필요할 겁니다.
그런데 서버를 무작정 늘리는 건 좋지 않습니다. 스케일아웃 혹은 스케일업을 하기 전에 항상 주어진 상황에서 해결하려 하는 게 중요합니다. 근본적인 문제를 해결하고, 서버 비용을 절감할 수 있으니까요!
네이버 실시간 스트리밍 서비스, 치지직에서는 어떤 식으로 최적화를 했는지 살펴봅시다.
왜 크기가 작은 파일들을 다룰까요? 스트리밍 서비스에서는 실시간으로 영상을 보여줘야 합니다. 그렇기에 영상 데이터를 작은 세그먼트로 쪼개어 실시간으로 전송합니다. 그렇기에 크기가 작은 파일을 다뤄야 합니다.
LL-HLS 프로토콜 도입
치지직에서는 LL-HLS 프로토콜을 사용한다고 합니다. 이를 이해하기 위해서는 우선 HLS를 알아야 합니다.
HLS(HTTP Live Streaming) 프로토콜은 HTTP를 통해 미디어를 스트리밍하는 프로토콜입니다. 2009년에 애플이 개발했습니다. HTTP를 쓸 수 있는 환경이라면 그대로 해당 HLS를 사용할 수 있기에 호환성이 좋습니다.
HLS는 하나의 비디오를 여러 세그먼트로 나누어서 보냅니다. 한 번에 모든 영상 데이터를 보내는 게 아니라 작은 세그먼트로 나눠서 보내기에 사용자는 더 빠르게 영상을 재생할 수 있습니다.
또한, Adaptive Bitrate Streaming을 지원하여 안정성을 높입니다. 사용자의 네트워크 속도에 따라 영상의 화질을 자동으로 조정하여 끊김 없이 플레이되도록 합니다. 이게 가능한 이유는 작은 세그먼트 단위로 보내주기 때문입니다.
LL-HLS(Low Latency HLS)는 HLS를 조금 더 실시간에 가깝게 만든 버전의 프로토콜입니다. HLS의 안전성을 유지하되, 지연시간을 2초 이내로 단축하는 게 목적입니다.
이를 위해 세그먼트를 더 작은 단위로 쪼갭니다. HLS에서는 6초일 수 있었던 세그먼트를 250ms 이내로 세그먼트를 나눕니다. 이 더 잘게 나눈 세그먼트를 Part라고 합니다.
정리하자면 치지직에서는 LL-HLS 프로토콜을 통해 더욱 낮은 레이턴시로 실시간으로 방송을 송출합니다. LL-HLS는 HLS의 확장 버전으로 2초 이내의 레이턴시를 지원합니다.
실시간 스트리밍에서 캐시는 어떻게?
대규모 트래픽에서 캐시는 필수입니다. 캐시는 어떻게 해야할까요?
LRU는 전통적인 캐시 교체 알고리즘 중 하나입니다. 가장 오래동안 사용되지 않은 캐시부터 교체하는 알고리즘입니다.
하지만 LRU의 단점은 캐시 생성과 삭제에 있어 오버헤드가 존재한다는 점입니다. 접근했던 순서를 갱신해야 하기 때문입니다. 또, 병렬 요청 시 동시성 처리도 신경 써줘야 합니다.
실시간 스트리밍이면서 동시에 대규모 트래픽인 서비스에서는 LRU를 그대로 사용하기에는 무리가 있어 보입니다.
여기서 또 하나의 문제가 있습니다. 처리해야 하는 Unique Contents가 많다면 어떨까요?
메모리의 크기는 한정되어 있고, 모든 컨텐츠를 캐시에 올릴 순 없습니다. 특히, 유니크한 컨텐츠가 많다면 캐시에 올리지 못하는 컨텐츠의 비율이 높아집니다. 이에 따라 캐시 적중률을 자연스레 낮아지게 됩니다.
캐시 적중률이 낮아지면 Disk I/O가 늘어나기 마련이고 이는 시스템에 부하를 줍니다.
특히 CPU 자원이 크게 소모됩니다.
I/O가 늘어날 때 CPU 자원이 크게 소모되는 이유는 무엇일까요?
I/O 횟수를 줄이는 게 왜 중요할까요?
이 질문에 대한 답이 명확히 떠오르지 않는다면 아래 글을 추천드립니다.
1초에 80,000번 I/O를 하면 생기는 병목을 분석해보자!
1초에 80,000번 Network I/O를 하면 생기는 병목을 분석해보자!
안녕하세요! NewCodes입니다! 저번 글에서 실시간 퀴즈 게임 프로젝트에 대해부하테스트와 성능최적화 글을 다루었습니다. Artillery를 통한 Socket.io 게임 서버 부하테스트 경험기실시간 게임 서버
newcodes.tistory.com
Memory Cache를 보면 여러 방송 part를 묶어서 저장한 걸 볼 수 있습니다. 이렇게 저장한 이유는 무엇일까요? 바로 I/O 횟수를 줄이기 위함입니다. 여러 컨텐츠를 하나로 묶음으로써 유니크함을 낮췄습니다. 유니크함을 낮추고 하나로 묶었기에 캐시를 생성하고 삭제할 때 I/O를 줄일 수 있습니다.
3개의 방송을 하나의 블록으로 묶어서 캐시로 저장하고 삭제한다면 I/O를 1/3로 줄일 수 있게 됩니다. 이로써 Unique한 컨텐츠가 많다는 단점을 해소했다고 볼 수 있습니다. I/O 작업이 비용이 높은 이유를 알면 Memory Cache에서 블록 단위로 묶어서 저장한 의도를 이해하실 수 있습니다.
그리고 캐시를 묶어서 저장했다면 이에 접근하기 위해 hash function이 필요합니다. 각각의 블록에 방송의 메타데이터에 따라 고유한 해시값을 사전에 부여합니다. 그러면 조회할 때 방송 메타데이터를 통해 캐시에 접근할 수 있습니다.
정리
앞에서 언급했던 일반적인 캐시 교체 알고리즘인 LRU를 그대로 적용했다면 위험했을 겁니다.
CS가 중요한 이유가 여기에 있습니다. 대규모 트래픽, 라이브 스트리밍과 같은 특수한 환경에서 안정적으로 빠르게 서비스하기 위해서는 기반이 되는 CS 지식을 알아야 합니다. 아는 것뿐만 아니라 상황에 맞게 응용할 줄 알아야 합니다.
위에서 알아본 최적화에서는 I/O 작업이 비싼 이유, 캐시 교체 알고리즘, DB Index의 원리, 자료구조에 대한 이해도가 있었어야 구현이 가능했을 겁니다. 또, 이를 직접 설계하고 구현하기 위해서는 해당 글에서 언급했던 것보다 훨씬 더 구체적이고 많은 CS 지식과 디테일을 알고 있어야 합니다.
요새 NewCodes 프로젝트에서 캐시 관리에 대해 고민을 많이 했어서 그런지 가장 몰입도 있게 들었던 부분이었습니다. CS의 중요성을 다시 한 번 체감하면서 군대에서도 더 꾸준히 CS를 학습해야겠다고 다짐했습니다.
좋은 세션 열어주신 강은영 테크 리드님과 네이버, 부스트캠프 관계자 분들께 감사드립니다.