오래된 SW 엔지니어의 평생 공부

[1]은 웹 성능 최적화에 이야기 하고 있지만, 네트워크를 사용한 성능과 관련된 이론적인 부분을 많이 다루고, 여러 프로토콜에 대해 설명도 잘 되어 있어, 살펴 보고자 한다. 네트워크 성능에 가장 기본적인 지연시간(Latency)와 대역폭(bandwidth, 혹은 troughput)에 대해 이야기 한다.

레이턴시와 대역폭:

레이턴시는 데이터가 출발지에서 도착지까지 이동하는 데 걸리는 시간이다. 대역폭은 네트워크 경로에서 전송 가능한 최대 데이터 용량을 나타낸다. 이 두 요소는 웹 성능 최적화의 핵심 요소로, 서로 상호작용하며 웹 애플리케이션의 속도에 영향을 미친다. 아래 그림에서 볼 수 있듯이 레이턴시는 송신단과 수신단의 거리, 대역폭은 가장 성능이 낮은 링크의 영향이 큰 것을 예상할 수 있다. 

레이턴시의 구성 요소:

• 전파 지연: 신호가 전송 매체를 통해 이동하는 데 걸리는 시간. 예를 들어 광섬유를 거치는 경우 빛의 속도.
• 전송 지연: 패킷이 링크를 통해 전송되는 시간. 전송할 데이터양과 연결하는 링크의 처리량에 따라 달라진다.
• 프로세싱 지연: 라우터 등이 패킷을 처리하는 데 걸리는 시간. 패킷 헤더의 정보를 처리하는데 필요한 시간.
• 큐잉 지연: 패킷이 처리 대기열에서 기다리는 시간. 

이러한 것들이 합쳐져 전체 지연 시간이 된다.

광섬유와 네트워크 속도:

광섬유는 네트워크의 핵심 전송 매체로, 높은 대역폭을 제공하며 장거리 데이터 전송에서 중요한 역할을 한다.
빛의 속도가 빠르지만, 현실적 제약으로 인해 이상적인 속도에 도달하기 어렵다. 네트워크는 기술 발전으로 대역폭은 점차 증가하고 있으나, 레이턴시는 물리적 한계로 인해 큰 개선이 어려운 상황이다. 이를 극복하기 위해 프로토콜 최적화 및 캐싱, 프리페칭 등의 기술을 활용해야 한다. 대표적으로 이러한 상황에서 최적화 전략으로 Content Delivery Network(CDN)와 같은 기술을 활용해 데이터 전송 거리와 레이턴시를 줄이는 방법을 사용하고 있다. 

라스트 마일

인터넷 트래픽의 대부분의 레이턴시는 대륙이나 바다를 건너는 메인 네트워크 구간이 아니라, 집이나 사무실에서 인터넷 서비스 프로바이더(ISP) 네트워크로 연결되는 마지막 구간(최종 몇 킬로미터)에서 발생한다. ISP의 연결 방식, 네트워크 토폴로지, 기술적 제한으로 인해 이 구간에서 지연이 크며, 네트워크 성능의 병목 현상이 자주 발생한다.

참고문서

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] https://docs.google.com/presentation/d/1ZgF4MQ-7BBS92Zlz3mB52APRmyoSyaXprwltw5y3VJg/edit#slide=id.p9

Machine Learning(ML) 기술이 발전하면서 빠르게 기존 시스템과 통합이 이루어 지고 있다. LLM도 단순히 사람들이 ChatGPT와 같은 서비스를 사용하는 것을 넘어서서 Cloud를 통해서 여러 시스템과 통합이 이루어 지고 있다. 아래 그림데로 많은 ML 시스템에서 실제로 학습이나 예측에 사용되는 코드가 극히 일부에 불과하다는 것이 이미 알려져 있다[1]. 이러한 관점에서 기존의 여러 기술들이 ML 기술들과 통합되어야 한다. 이러한 관점에서 숨겨진 기술 부채(Hidden Technical Debt in Machine Learning)가 많을 수 있다.

특히, 기존의 성능과 관련된 항목에서도 이러한 부분을 살펴 볼 수 있다. 여기서는 성능 관점의 지연 시간(Latency)와 규모확장성(Scalability)에 대해서 잠시 살펴 보자.

기존 기술의 경우에도 Cloud를 기반으로 하게 되면 최종 사용자의 위치에 따라서 실재 연산을 처리하는 서버의 위치(Region)은 중요한 부분 중에 하나이다. 간단히 말하자면, 한국에 있는 사용자가 미국에 있는 서버에 접속해야 하는 경우라면 결국 요청을 미국 서버에 보내고 처리한 결과를 다시 한국에 있는 사용자에게 보내려면 시간이 걸릴 수 밖에 없다. 그렇다면, LLM의 Foundation Model을 운영하는 Cloud의 Region을 최종 사용자에 맞게 최적화 할 필요가 있다.

규모 확정성(Scalability)의 경우도 사용자가 많아 지면 하나의 LLM 인스턴스로 처리하는 것은 문제가 될 수 있을 것이다. 이것도 결국에는 Load balancing 이슈에 해당한다고 할수 있다. 결국 이러한 전통적인 문제는 기존과 같이 요청을 잘 분배해서 처리하는 구조가 필요하다[2].

참고 문헌

[1] D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems",  https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf

[2] https://aws.amazon.com/ko/blogs/tech/multi-rag-and-multi-region-llm-for-chatbot/