Oct 30, 2021

By Geon Son

Facebook Infra scaling 관점에서 살펴보기

facebook
infra
scaling

나의 패킷이 페이스북에 닿기까지

방학을 맞이한 대학생이 할 일이라곤 🍚, 🛏, 🕹,📱페이스북과 인스타그램 밖에 없다. 페이스북은 속도라도 답답하게 느껴지면 덜하기라도 하겠지만 매우 쾌적하게 작동 하면서 수 많은 사람들의 시간을 뺏어간다. 그렇다면 페이스북은 어떻게 인프라를 구성했기에 쾌적한 글로벌서비스를 운영할 수 있는건지 한 번 알아보자.

닿기... 전에... 네트워크 복습🗃

인프라에서 어떻게 패킷을 효율적으로 전송할 것인지는 중요한 부분 중 한 개 이기 때문에 네트워크 이론이 조금 필요하다. 이 글에서는 매우 생략된 설명만 할 것 임으로 다들 모니터, 🍜 냄비 받침으로 쓰던 네트워크 책을 한번 살펴보자.

OSI 7 LAYER

어떤 책으로 시작하던 대부분 시작은 이 계층 모델과 함께 한다.

이 계층을 보면 일반적으로 쓰는 Layer7 Application에서 각 계층을 거칠 때 어떤 정보들이 붙는지를 볼 수 있다. 패킷을 보내는 입장에서 먼저 생각해보자. 페이스북 서버로 HTTP GET 요청을 보내게 될 경우 웹 브라우저에서 작성하는 데이터는 아래와 같다.

GET / HTTP/1.1
HOST: www.facebook.com

보통 Layer 5,6,7을 Application Layer로 묶어서 본다(정확히는 TCP/IP model에서 지만 자세하게는 생략). 이 단계에서는 우리가 보낼 데이터를 넣고 HTTP, SSH등 다양한 프로토콜 중 어떤 걸 사용할 것 인지 그리고 어떻게 표현 할 것 인지에 대한 데이터를 추가 해준다.

하지만 위 데이터만 가지고 우리의 요청은 페이스북에 닿을 수 없다. 우리의 컴퓨터 안에 존재하는 많은 프로그램 중 어떤 프로그램으로 이 데이터가 가야 하는지에 대한 정보를 적어야 한다.이 정보는 Layer 4에서 정의가 된다.

TCP Header wikipedia

Layer 4에서는 어떤 포트로 갈지 어떻게 연결을 할지에 대한 프로토콜을 정의한다. 주로 널리 알려져 있는TCP, UDP가 여기에 해당된다. 위 표에서는 Source Port, Destination Port 가 어떤 포트를 통해 가는지에 대한 정보를 알려준다. 하지만 어떤 포트로 가야 하는가에 대한 정보가 있다 하더라도 우리의 요청이 페이스북에 닿을려면 아직 부족하다. 어떤 컴퓨터로 가야하는지에 대한 정보인 IP가 없기 때문이다.

IP Header wikipedia

Layer 3에서는 어떤 IP로 가야하는지 출발지와 목적지에 해당하는 정보를 담고 있다. 위 표에서는 Source Address , Destination Address 가 있다. Layer 2, 1 에서도 위 과정과 같이 필요한 정보를 붙이는과정을 거친다. 이렇게 보내는 입장에서 하위 레이어로 갈 수록 필요한 내용들이 붙는 것을 Encapsulation이라 부른다. 필요한 정보가 캡슐을 씌우듯이 계속 붙는다. 반대로 받는 입장에서는 하위 레이어부터 시작해서 필요한 내용을 읽어나간다. Layer 3에서는 출발 도착지 IP를 Layer 4에서는 포트정보를. 이렇게 하위 레이어에서 상위레이어로 필요한 정보를 얻으면서 올라가는 과정을 Decapsulation이라고 부른다.

인프라 단에서 다루게 되는 레이어는 보통 이렇게 Layer 3, 4, 7정도가 되니 각각 Encapsulation과 Decapsulation과정에서 어떤 데이터를 읽을 수 있을지를 생각 해 보면 아래 글을 이해할 때 조금 도움이 될 것이다.

페이스북은 얼마나 많은 트래픽을 받을까?

페이스북은 우리가 생각하는 페이스북 뿐만아니라 양대산맥 SNS 인스타그램, 외국에서 많이 쓰이는 What's App 그리고 MZ세대들이 많이쓰는 메신저인 FB Messanger까지 대충 듣기만해도 트래픽 많이 받을 것 같은 서비스들만 모아놓은게 페이스북이다. 그렇기 때문에 아래와 같은 😈무시무시한 수치들을 볼 수 있다.

2015년 기준 공개된 FB 트래픽

📈 1+ Tb/초 egress
🎥 동영상 40억뷰/일
🏃🏻 100만 Request/초

이렇게는 잘 감이 안온다면 좀더 일반유저 관점에서 나온 통계들을 보자

24억 - 전세계 사람들이 월간 페이스북에 접근하는 횟수의 합
10억 - Instagram의 월간 활성 사용자 수
15억 - WhatsApp을 월간 사용하는 횟수

숫자들이 동방의 작은 소국에서는 경험할 수 없는 스케일이긴 하다. 각각 15년 19년에 발표된 자료라 지금은 저것보다 훨씬 많을껄로 추정된다

스케일을 키우는 방법

자 잠깐 눈을 감고 나는 페이스북을 만든 주커버그다 생각해보자. 페이스북을 처음 만들어서 서비스를 하게 됐고 약 300명정도의 사용자가 생겼다. 집에 굴러다니는 라즈베리파이가 슬슬 버거워해서 서버를 한 대 뒀고 웹서버에(위 사진에서는 HHVM) 페이스북 도메인을 물려놨다. 이렇게 해서 몇달 버티다가 입소문이 났는지 점점 서버가 버거워 한다. 결국 눈물을 머금고 서버를 몇대 더 띄우기로 했다😭.

그냥 서버만 여러대 더 띄우면 될까? 도메인에 접속했을때 여러서버로 DNS는 여전히 서버 한대의 ip만 알려줄 수 있을꺼고 다른 서버로는 요청이 가지 않을꺼다. 이렇게 서버가 여러대 있을때 각 서버로 요청을 나눠주기 위해 Load Balancer(LB)를 쓰게 된다. LB의 경우 위에서 봤던 OSI 7 Layer 중 어느 단계에서 트래픽을 로드밸런싱 해주는지에 따라 L4, L7 LB라고 부른다.

일반적으로 여러 웹서버를 대상으로 트래픽 로드밸런싱이 필요할 경우 Host나 HTTP Request URL의 Path에 따라 어느 서버로 갈지 결정해주는 라우팅이 필요해 해당 정보를 알수 있는 L7 LB를 사용하게 된다. L7 LB 같은경우 우리가 일반적으로 개발할 때 쓰는 오픈소스 LB인 Nginx가 있고 AWS상의 서비스로 생각해보면 Application Load Balancer(ALB)가 해당 역할을 한다.

L7 LB의 경우 비지니스 로직을 처리하지 않고 트래픽을 어느 서버로 보낼지 결정만 해주니깐 웹서버에 비해 상대적으로 더 많은 rps를 버틸 수 있다. 되면 기존에 약 한대당 300rps를 웹서버가 버틸수 있었다고 하면 L7 LB를 사용해 5대의 서버로 로드밸런싱을 해주면 약 1500 rps를 견딜 수 있게 된다.하지만 모든 서버에 수용량의 한계가 있는 것 처럼 L7 LB도 결국 어느순간 처리하지 못할 만큼에 Connection을 가지고 있게될수도 있다. 만약 여기서 사용자가 더 몰리게 되면 어떻게 해야할까?

정답은 L7 LB도 더 띄우고 웹서버도 더 많이 띄우는 것이다. 이전에 웹서버에 트래픽 로드밸런싱 하기 위해 L7 LB를 사용한 것처럼 여러대가 된 L7 LB로 가는 트래픽을 로드밸런싱 하기위해 이번엔 L4 LB를 사용하게 된다.

L4 LB의 경우 L7LB와 다르게 OSI 4계층에서 트래픽을 로드밸런싱 해준다. 4계층에서 알 수 있는 정보는 7계층보다 제한돼있어 IP와 Port로만 로드밸런싱 할 수 있지만 훨씬 더 많은 양의 트래픽을 버틸 수 있게 된다. 오픈소스로 된 L4 LB엔 HAProxy가 있고 AWS service에는 Network Load Balancer(NLB)가 존재한다. 이 전에 L7 LB 한 개만 쓸때보다 훨씬 더 많은 웹서버를 운용할 수 있게 된다.

꽤 괜찮아졌지만 여전히 현재 페이스북의 무시무시한 트래픽을 받기에는 부족하다. 여기서 한 번 더 트래픽을 많이 받을 수 있게 하려면 어떻게 해야할까? 이미 예상했겠지만 L4 LB를 더 띄워야 한다.

L4 LB를 더 띄우기 위해 이번에는 Switch를 사용한다. 위 사진에서 나오는 ECMP라는건 Equal-cost multi-path routing의 약자로 하나의 목적지로 패킷 라우팅을 수행하면서 여러 개의 경로를 선택하는 라우팅 기법이다. 즉 여러개의 경로를 선택하면서 여러 L4 LB로 트래픽을 라우팅 시켜줄 수 있는 것이다. 여기까지 왔으면 아래 사진과 같이 Facebook에서 쓰고 있는 서버 클러스터 한개가 완성됐다고 생각하면 된다.

이후 여기서 한 번...더! 를 외치면 서버 클러스터를 늘려 데이터 센터를 만드는거고 이걸로도 모자라 한 번더! 를 외치면 여러개의 데이터센터를 운영한다 생각하면 된다.

페이스북 사이즈로 수평적 확장(Scale-Out)을 지속적으로 하려면 눈물을 한번 머금는걸로는 안되고 쉴세없이 흘려야 가능할까 말까가 되지 않을까 싶다.

Edge Networking

데이터 센터는 매우 크기가 크기도 하고 많은 💸이 필요하기 때문에 비교적 적은 수 만 있다. 페이스북의 데이터 센터는 2018년 기준으로 총 15개가 운영되고 있다. 데이터센터 대부분은 미국에서 운영되고 있고 스웨덴이나 아일랜드 쪽에 일부 존재한다. 미국이나 북유럽 유저들은 데이터센터와 물리적 거리가 까깝기 때문에 한국에서 네이버 접속하는 것 처럼 빠르게 접근할 수 있을것이다. 하지만 페이스북은 전체 트래픽에 82% 가량이 미국 밖에서 발생하는 글로벌 서비스 회사이다. 일부 지역에 몰려있는 데이터센터 만으로는 많은 국가에서 서비스를 할 때 latency문제를 감당하기 힘들다는 문제점이 있다.

위 그림의 시나리오는 서울에서 유저가 미국 Oregon에 있는 데이터 센터에서 Dynamic Resources들을 받아 올 때를 가정한 상황이다. 요즘 웹이던 앱이던 보안을 위해 HTTPS를 사용한다. HTTPS를 쓰기 위해서는 먼저 TCP Conneciton을 맺어야한다. 이때 TCP connection을 맺기위해 3-way handshake 과정을 거친다. 이후 SSL session을 맺기 위해 4-way handshake를 추가적으로 해야한다. 손이 닳도록 악수한 후에야 SSL session 이 맺어지고 드디어 본론인 http request를 보낼 수 있게된다. (자세한 내용은 생략한다)

이 과정에서 걸리는 시간을 정리해 보자면 서울에서 보낸 패킷이 Oregon에 위치한 데이터 센터까지 도착하는데에 75ms가 걸린다. 일반적으로 네이버에 ping을 쐇을때 응답 받기까지 걸리는 시간이 8ms고 서울에서 일본까지 15~20ms 라는 점을 생각해보면 엄청나게 오래걸리는 것을 알 수 있다. 정리해보자면 위 그림과 같이 TCP Connection 150ms + SSL Session 300ms + HTTP 150ms 로 총 600ms가 소요된다.

Nielsen Norman Group 이라는 유명한 User Experience research group에서 말하기를 사람이 견딜수 있는 시간의 세 단계가 있다고 한다.

0.1초: UI를 눌렀을때 빠릿빠릿하게 동작한다라고 느끼는 제한시간.
1초: 사람들이 느려서 답답하다 생각하지 않고 하던 동작을 할 수 있는 제한시간. 0.2 ~ 1 초안에 동작이 끝나면 빠르진 않지만 답답할 정도는 아니라고 생각 할 수 있다
10초: 사람들의 인내심의 한계까지의 제한시간. 10초가 넘으면 기다리지 않는다

이런 UX적인 시간기준을 봤을때 0.6초는 API를 여러개 친다고 하면 슬슬 사람들이 답답하다고 느껴 사용자 경험을 해칠 가능성이있다. 또한 사용자는 이렇게 답답하다고 느낄때마다 앱에서 이탈할 확률이 크게 증가한다고 한다.

이 문제를 해결하기 위해 페이스북은 세계 곳곳에 Edge PoP(Points of Presence)를 운영하고 있다. Edge PoP는 L4, l7 Load Balancer를 가지고 있어 PoP에서 TCP Connection과 SSL session을 만든 후 페이스북 데이터 센터에 요청을 보내 Latency를 줄일 수 있게 해준다.

위 그림과 같이 바로 Oregon에 있는 데이터 센터와 연결 하는게 아니라 도쿄에 있는 Edge PoP를 거쳐 통신하게 되면 TCP Connection 30ms + SSL Session 60ms + HTTP 150ms 로 총 240ms가 소요된다. 사용하기 전과 비교하면 무려 요청속도가 60%나 개선 됐다는걸 알 수 있다.또한 Edge PoP를 사용하면서 Static Resource들을 캐싱해서 굳이 Oregon까지 가지 않아도 되도록 하게끔 해서 요청빠르게 데이터들을 받을 수 있다.

정리

페이스북의 놀라운점은 위에 나온것중 휴대폰을 제외한 모든걸 만들어서 쓴다. L4, L7 LB, DNS, 서버랙부터 스위치 그리고 스위치 안에 들어가는 OS까지 모든걸 만든다. 2015년 정도에 글로벌서비스를 하기위해 이런 인프라들을 사용 할 수 있는 회사는 자체 데이터 센터와 네트워크 인프라를 가지고 있는 소수의 회사들만 할 수 있었을 걸로 보인다.

그래도 2021년 현재 소규모 회사들도 점점 이런 스케일러블한 구조를 가지기 쉬워지는게 AWS 상에 이미 다양한 서비스들이 생겨서 유사한 구조를 가져갈 수 있게 됐다.

L4 LB - Network Load Balancer
L7 LB - Application Load Balancer
Scalable한 서버 - EC2
Edge POP - multi region + cloudfront
등등..

위에서 얘기한 Edge Networking 같은경우도 완전 동일하게 구현은 못하더라도 CloudFront를 사용해 유사하게 구현할 수 있고 여러국가에 있는 데이터센터는 multi region 서비스를 하면 비교적 큰 돈 들이지 않고 전세계에서 안정적인 서비스가 가능해진다.

소개한 자료들이 완전 최신은 아니라 페이스북(이제는 meta가 됐지만) 현재 인프라와는 많이 다르겠지만 스케일링 관점에서 어떤 기술을 쓰고 있는지 10년전 큰 기업들이 했던 고민을 커가는 스타트업들에 적용 해 볼 수 있을 것 같아서 글을 써봤다.

참고자료

Previous Feb 21, 2021
« 📱iOS 14 이야기 - 1. ATT,SKAdNetwork에 대비하는 전략