LINE의 인프라 비용을 절감한 6가지 사례

들어가며

안녕하세요. LINE에서 미디어 플랫폼의 개발과 운영을 담당하고 있는 박동진입니다. 미디어 플랫폼은 LINE 내에서 유통되는 콘텐츠(이미지, 비디오, 라이브 스트림 등을 포함한)를 각 서비스 요구 사항에 맞춰서 가공하고 저장한 뒤 사용자에게 전달하는 역할을 하는데요. 이런 역할을 하기 위해서 LINE 서비스에서 발생하는 막대한 트래픽을 처리하고 있습니다. 덕분에 서버와 전용 회선, 스토리지, CDN 등 LINE의 인프라 비용을 산정할 때 미디어 플랫폼이 늘 1순위로 고려 대상이 되었습니다(한때 ‘장비 깡패’라는 별명이 있었을 정도로 규모가 크기도 합니다).

따라서 LINE 각 서비스의 기능 지원은 물론 비용 효율적이면서 사용자 경험을 해치지 않도록 빠르게 전달하는 역할을 하는 것이 저희 팀의 미션이라고 볼 수 있습니다. 이 미션을 어떻게 달성했는지 몇 가지 사례를 통해 살펴보도록 하겠습니다.

 

미디어 플랫폼의 구성 및 동작 방식

사례 소개에 앞서 미디어 플랫폼이 어떻게 구성되어 있는지 간단히(정말 간단히!) 설명드리고자 합니다.

미디어 플랫폼은 크게 프론트엔드와 백엔드로 구성됩니다. 프론트엔드는 LINE 클라이언트가 이용할 수 있는 접점 역할을 하며 5개의 PoP(Point of Presence)에 배치하여 운영하고 있습니다. 또한 송수신된 미디어에 대한 캐시와 요청 프록시를 담당합니다. 백엔드는 미디어를 스토리지에 저장하고 이미지 섬네일 생성과 비디오 트랜스 코딩 등의 후처리를 담당합니다.

미디어 플랫폼이 지원하는 LINE 서비스는 수십 가지가 있지만, 그중 가장 많은 트래픽이 발생하는 서비스는 LINE 채팅입니다. 따라서 인프라 비용 절감 사례도 채팅 서비스 기준으로 설명하려고 합니다.

 

첫 번째 사례: 업스트림 캐시

첫 번째 사례는 업스트림 캐시(Upstream Cache) 적용 사례입니다. LINE 채팅 서비스에서 주고받는 이미지나 비디오의 기준(해상도, 포맷, 비트 전송률 등)은 미리 정해져 있습니다. 하지만 모든 LINE 사용자들이 채팅 서비스 기준에 맞춰서 사진이나 영상을 보내지는 않습니다. 따라서 사용자로부터 어떤 해상도나 포맷으로 송신이 되더라도 서비스의 기준에 맞춰 수신자에게 전송해 주어야 하며, 이 기준에 맞지 않는 미디어 파일은 미디어 플랫폼에서 별도의 후처리 과정을 거치게 됩니다. 서비스 기준에 맞지 않는 이미지는 해상도나 품질을 조정하는 형태로 재가공하며, 하나의 원본 이미지로 다양한 형태의 섬네일을 생성하기도 합니다. 비디오나 오디오의 경우엔 트랜스 코딩 작업을 거치게 됩니다. 이 작업은 이미지 후처리 작업보다 더욱 연산량이 많습니다.

만약 LINE 채팅 서비스를 통해 유통되는 모든 미디어 파일에 위와 같은 과정이 필요하다면 상당히 많은 컴퓨팅 파워가 필요할 것입니다. 아래 그림은 1:1 대화방에서 사진이나 영상을 주고받는다고 가정한 상황입니다. 송신자는 미디어 플랫폼으로 미디어 파일을 업로드하고, 수신자는 미디어 플랫폼으로부터 미디어 파일을 수신합니다. 다른 복잡한 과정들이 있지만 생략했습니다.

업스트림 캐시 적용 전의 메시지 송수신 흐름: 항상 오리진(origin) 서버에서 미디어를 가져온 후에 캐시하는 방식을 사용

그림처럼 프론트엔드와 백엔드가 각각 다른 국가의 IDC(Internet Data Center)에 위치해 있다고 가정해 보겠습니다. (A) 국가의 송신자가 업로드한 미디어는 프론트엔드와 백엔드를 거쳐 (B) 국가의 스토리지에 저장됩니다. 대화방에 참여하고 있는 수신자는, 프론트엔드의 캐시에 미디어가 없을 경우 프론트엔드가 오리진 서버에서 미디어 파일을 가져와서 캐시한 후에 응답을 받게 되는데요. 이 과정에서 많은 대역폭을 사용합니다(많은 대역폭 = 많은 인프라 비용). 또한 1:1 대화에서는 수신자가 항상 위와 같은 방식으로 메시지를 읽을 수밖에 없었기 때문에 수신 체감 속도도 다소 떨어졌습니다.

 

업스트림 캐시 적용

개선된 버전에서는 업로드와 동시에 미디어 파일의 헤더를 분석할 수 있도록 구현했습니다. 분석 결과를 확인하여 서비스에 사용할 수 있는 미디어 파일인지 확인합니다. 사용 가능하다고 판단되면 따로 크기 조정이나 트랜스 코딩하지 않고 프론트엔드에 캐시합니다. 그렇지 않은 경우만 후처리를 하도록 개선했습니다. 그 결과 송신되는 미디어의 약 80%가량이 서비스에서 사용하기에 적합했기 때문에 바로 캐시할 수 있었습니다. 또한 전용 회선, 인코딩 서버 및 이미지 처리 서버의 부하를 줄일 수 있었습니다.

업스트림 캐시 적용 이후의 메시지 송수신 흐름: 업로드되는 미디어를 실시간 분석해 서비스 기준에 맞으면 곧바로 캐시하는 방식을 도입

 

두 번째 사례: 스토리지 레이어링

두 번째 사례는 저장 비용을 경감하기 위한 스토리지 레이어링(storage layering)입니다. LINE 채팅에서 송수신되는 미디어 파일은 ‘송신 후 N일이 지나면 접근 빈도가 크게 떨어지는 특성’을 가지고 있습니다. 메시지 수신 후 수일 내로 읽고, 이미 읽은 메시지는 다시 잘 읽지 않는다는 의미로 해석할 수 있습니다. 저희는 이 접근 패턴에 착안해 접근이 잦은 N 일치의 미디어 파일을 저장할 수 있는 공간만을 고성능 스토리지로 구성하고, N 일이 지난 미디어 파일은 저가의 스토리지로 심리스(seamless)하게 이동시키고 있습니다. LINE 서비스 초기에는 모두 고성능 스토리지로 구성했었는데요. 이 개선 방법을 적용해 비용을 아낄 수 있었습니다.

사용자 접근이 잦은 수일 동안의 미디어만 고성능 스토리지에 저장하도록 하고 나머지는 저비용 스토리지에 저장하도록 설계

 

세 번째: 섬네일 생명주기 관리

세 번째는 섬네일을 일정 기간만 보관하도록 구현하여 저장 비용을 절감시킨 사례입니다. 사용자가 LINE을 통해 생산한 이미지는 서비스에 따라, 혹은 단일 서비스에서도 다양한 클라이언트(앱, 웹, 데스크톱 …)를 지원하기 위해 다양한 크기의 섬네일을 사용합니다. 섬네일을 많이 사용하는 서비스는 100개 이상을 사용하기도 합니다. 원본과 섬네일의 크기가 같다고 단순하게 가정했을 때, 사용자가 1MB 이미지를 업로드했다면 100MB 이상의 섬네일이 생성될 수도 있다는 의미입니다. 여기에 더해 미디어 플랫폼은 고가용성(High Availability)을 보장하기 위해 ‘3 copy 정책’을 사용하기 때문에 실제로는 더욱더 많은 용량을 차지하게 됩니다. 섬네일은 스토리지를 과다 사용하게 되는 원인 중의 하나이며 반드시 관리해야 할 대상입니다.

 

섬네일 생성

섬네일을 생성하는 방식은 생성 시점에 따라 두 가지로 나눌 수 있습니다.

생성 방식섬네일 생성 시점장점단점
Precreation원본 업로드 직후 서비스에서 사용할 섬네일을 모두 생성중복된 섬네일 요청이 들어와도 스토리지에 저장된 섬네일을 전달하므로 부수적인 처리 불필요섬네일을 먼저 생성하기 위해 컴퓨팅 비용과 스토리지 용량 증가
Ondemand섬네일 다운로드 요청을 받았을 때 요청받은 섬네일만 생성섬네일 다운로드 요청이 발생해야 섬네일을 생성하므로 Precreation 방식에 비해 스토리지 용량을 아낄 수 있음동시에 대량의 특정 섬네일 요청 발생 시 부담됨
섬네일 생성이 완료될 때까지 클라이언트와 세션을 유지해야 함

미디어 플랫폼은 두 방식을 혼용해서 사용하고 있습니다. 업로드와 섬네일 다운로드 사이의 간격이 짧은 서비스(채팅)나 집중적인 섬네일 다운로드가 예상되는 서비스(뉴스 서비스의 기사, 배너 이미지)의 섬네일은 Precreation 방식을 적용하고 있습니다. 그 밖에 섬네일 다운로드 요청이 발생하지 않을 수도 있는 서비스(앨범)는 Ondemand 방식을 적용하고 있습니다.

 

섬네일 보관 정책

미디어 플랫폼은 일정 기간이 지난 섬네일은 스토리지에서 자동으로 삭제하고 최근 며칠 간의 섬네일만 유지합니다. 섬네일 다운로드 요청이 보관 기간 내의 섬네일이면 스토리지에 저장된 섬네일로 응답하고, 그렇지 않으면 Ondemand 방식으로 응답하도록 구현되었습니다. 섬네일도 원본과 마찬가지로 며칠이 지나면 사용자가 잘 접근하지 않습니다. 보관 기간이 지난 섬네일의 요청량은 보관기간 내의 요청량보다 현저히 적기 때문에 그때그때 생성해도 컴퓨팅 자원 관리에 큰 문제가 없는 수준입니다. 반면에 보관 기간이 지나면 무조건 삭제되기 때문에 스토리지 절감에는 많은 도움이 됩니다. 원본은 사용자가 저장했기 때문에 삭제할 수 없지만, 섬네일은 생성과 삭제를 모두 미디어 플랫폼에서 처리하기 때문에 가능한 구현이었습니다.

보관 기간 내 섬네일은 스토리지에서 가져오고 보관 기간이 지난 섬네일은 Ondemand로 응답 후 스토리지에 저장하지 않는다

 

네 번째: 메시지 전달 기능 최적화

다른 메신저와 마찬가지로 LINE 채팅에서도 내가 수신한 메시지를 친구들에게 전달(forward)할 수 있는 기능이 있습니다.

때때로 실시간으로 화제가 되는 메시지가 이 ‘전달’ 버튼을 통해 급속하게 퍼지기도 합니다. 특히나 전달되는 메시지의 종류가 텍스트가 아닌 이미지나 비디오일 경우 다음과 같은 이슈가 있었습니다.

  • 동일한 파일이 전달되면서 스토리지에 엄청나게 많이 중복 저장됩니다. 더군다나 위에서 언급했듯이 미디어 플랫폼의 스토리지는 3 copy 정책이기 때문에 물리적 저장 공간은 전달 횟수의 수배 씩 증가합니다.
  • 이렇게 전달된 메시지들은 캐시 효과도 기대하기 어렵습니다(캐시하지 않는 게 좋습니다). 따라서 캐시 히트율이 하락하고 전용 회선 사용량(이라고 쓰고 비용이라고 읽는)에도 영향을 줍니다.
  • 전달된 미디어 파일은 스토리지 쓰기를 마친 다음에야 응답을 주는 것이 가능하므로 응답 속도도 떨어집니다.
매번 파일을 만들던 때의 ‘전달’ API 작업 흐름

이 문제를 해결하기 위해 전달 API에 심볼릭 링크(symbolic link) 개념을 적용하여 보다 빨리 동작할 수 있도록 개선했습니다. 전달 API가 호출되면 스토리지에 물리 파일을 만들지 않고 심볼릭 링크 정보(전달 대상 파일의 위치)를 메타 데이터에 기록합니다. 이후 전달된 메시지에 대한 다운로드 요청이 발생하면 메타데이터를 확인해서 심볼릭링크 정보가 기록되어 있을 경우 이 위치의 원본 파일을 참조하도록 구현했습니다. 참조 대상인 원본 파일은 특정 캐시 서버와 스토리지에만 저장하므로 캐시 히트율을 높이는 데도 도움이 됩니다. 참조 대상 원본 파일이 캐시되어 있다면 전달을 통해 수신자에게 노출되는 미디어 파일들 또한 함께 캐시 효과를 누릴 수 있습니다. 아래 그림처럼 ‘User A’와 ‘User C’는 서로 친구가 아님에도 논리적으로 동일한 전달 대상 파일에 접근하게 되는데요. 이 과정에 앞서 각 사용자가 요청한 파일에 접근 권한이 있는지 확인하는 인증 과정이 존재합니다. 이 부분은 내용이 길어져서 생략했습니다.

심볼릭 링크 개념을 도입한 이후의 전달 API 작업 흐름

이 방법에도 문제는 있습니다. 상당히 많이 전달되어(예를 들어 100만 번) 하나의 미디어 파일에 100만 개의 심볼릭 링크가 생성된 상황이라면, 또 해당 미디어 파일에 동시에 접근하려는 사용자가 많다고 한다면, 전달 대상의 원본 파일을 저장하고 있는 특정 캐시와 스토리지에 엄청난 읽기 부하가 발생합니다. 이런 읽기 부하를 분산하기 위해 N 번의 심볼릭 링크 생성 이후에는 하나의 물리 복제본을 생성합니다.

N 회의 심볼릭 링크 생성 이후에는 원본과 동일한 파일을 생성한 후 이 파일에 대한 심볼릭 링크를 만드는 방식으로 트래픽을 분산

 

다섯 번째: 비디오 트래픽 제어

인터넷 환경이 점점 발전하면서, 텍스트나 이미지보다는 비디오 메시지 송수신이 증가하고 있는 추세입니다. 그만큼 미디어 플랫폼에서 처리해야 할 트래픽도 증가하고 있는데요. LINE 채팅의 비디오 트래픽을 처리하면서 적용했던 비용 절감 사례를 소개하겠습니다.

비디오 캐시 서버팜(server farm) 구축 및 운영

LINE이 서비스하고 있는 국가 중 비디오 공유와 소비가 특히 많은 국가들이 있습니다. 그런데 만약 해당 국가에 아직 스토리지가 없다면, 비디오를 재생하기 위해서 오리진 서버로 대량의 트래픽이 발생하게 되고, 이에 따라 트래픽을 수용하기 위한 인프라 투자 비용이 지속적으로 증가합니다. LINE에서 발생하는 거대한 비디오 트래픽을 감당하기 위해서는 LINE 내부 인프라를 확장하는 것뿐 아니라 관련 외부 인프라도 트래픽을 수용할 수 있도록 확장해야 하는데요. 이런 비용을 줄이기 위해 저희는 해당 국가에 NGC(New Global Cache)라는 캐시 서버팜을 구축했습니다. 결과는 성공적이었습니다. NGC는 특정 국가에서 피크 타임 기준으로 90Gbps의 비디오 트래픽을 처리하는 등 많은 양의 비디오 트래픽을 소화하며 90% 이상의 캐시 히트율을 유지하고 있습니다. 이를 통해 사용자의 비디오 메시지 재생 요청에 보다 빠르게 응답할 수 있었고, 상당량의 비디오 트래픽을 NGC를 통해 처리함으로써 네트워크 인프라 투자 비용을 절감할 수 있었습니다.

미디어 플랫폼의 PoP에서 멀리 떨어진 지역의 사용자는 NGC를 통해 보다 빠른 비디오 재생 가능

 

비디오 트래픽 셰이핑(shaping)

사용자가 비디오 메시지를 재생할 때 영상을 시청하는 시점보다 더 빨리 서버에서 비디오 패킷을 전송할 경우, 사용자의 비디오 플레이어는 수신한 패킷을 플레이어 버퍼에 저장합니다. 이렇게 저장된 상태에서 사용자가 영상을 끝까지 시청하지 않고 이탈한다면, 서버와 사용자 모두 패킷을 낭비하게 됩니다. 반대로 시청 시점보다 늦게 서버가 패킷을 전송할 경우, 사용자의 플레이어에서 버퍼링이 발생합니다. 따라서 사용자에게 끊기지 않는 시청 경험을 제공하면서 버퍼 크기를 최대한 작게 유지하는 것이 이 개선 방법의 핵심이라고 할 수 있습니다.

서버와 사용자 모두 다량의 패킷 낭비 발생

미디어 플랫폼은 전송하려는 영상의 비트 전송률(bit rate)을 포함한 몇 가지 항목으로 최적의 비디오 전송률을 계산합니다. 이후 이 값을 참조하여 두 구간으로 나누어 전송하고 있습니다.

  • 초기 전송 단계: 영상의 재생 시작 시점부터 N 초까지는 비디오 플레이어의 버퍼를 어느 정도 채워놓기 위해서 최대 속도로 전송합니다.
  • 제한이 적용된 전송 단계: 초기 전송이 끝난 이후부터는 계산된 비디오 전송률을 상회하지 않도록 전송합니다.

국가별로 인터넷망 상태가 다르기 때문에 비디오 전송률은 국가별로 조금씩 다르게 계산합니다. 이런 방식으로 재생 중간에 사용자가 이탈하면서 낭비될 수 있는 패킷을 최소화하고 있습니다.

미디어 플랫폼은 최대 속도로 전송하는 구간과 비디오 전송률을 적용한 구간으로 나누어서 영상을 전송

 

여섯 번째: 고효율 이미지 포맷 활용

인프라 비용 절감 마지막 사례는 고효율 이미지 포맷을 적극적으로 활용하는 것입니다. 고효율 압축 포맷인 HEIF(High Efficiency Image File Format)는 이론적으로 JPEG 대비 절반의 크기만으로 JPEG과 동일한 화질을 구현할 수 있습니다. 이미지 크기를 절반으로 줄인다는 것은 스토리지와 전용 회선 및 사용자의 패킷까지도 절반이나 줄일 수 있다는 의미이기 때문에 인프라 비용 감소는 물론, 빠른 페이지 렌더링으로 보다 좋은 사용자 경험도 달성할 수 있습니다. 

이미 JPEG으로 저장한 이미지들은 어떻게 할까요? 마이그레이션을 합니다! 미디어 플랫폼 스토리지 용량을 가장 많이 사용하는 서비스는 앨범입니다. 앨범 서비스에 저장된 사진은 모두 JPEG으로 구성되어 있었는데요. 최근에 HEIF로 마이그레이션을 진행했습니다. 그 결과 JPEG 대비 절반 이하의 크기로 서비스할 수 있게 되었습니다. iOS는 11 버전부터, Android는 9 Pie 버전부터 HEIF를 지원하고 있습니다. HEIF 렌더링을 지원하는 클라이언트의 경우 HEIF 그대로 서비스하고, 미지원 클라이언트는 미디어 플랫폼에서 HEIF를 JPEG으로 재변환해 서비스하고 있습니다. 자세한 내용은 이후에 별도 주제로 기고할 예정입니다.

 

마치며

이번에 소개한 인프라 비용 절감 사례들은 모두 처음부터 계획했던 것들은 아니었습니다. 미디어 플랫폼은 단순한 형태의 스토리지에서 출발했지만, 나날이 늘어가는 LINE의 막대한 트래픽을 처리하다 보니 어떻게 하면 API를 덜 호출하고 빨리 응답할지, 어떻게 스토리지를 덜 사용할지 늘 고민해야 했고, 그런 고민 끝에 이런 사례들이 도출되었다고 생각합니다.

마지막으로, 현재 채용을 진행하고 있습니다! We are hiring! 이런 최적화 작업에 관심이 있으신 분들은 적극 지원 부탁드립니다. 

Related Post