📈 Meta 는 수십억 건의 비동기 요청을 어떻게 처리할까?

Meta 에서는 여러 엔지니어링 팀에서 수행해야하는 비동기 처리를 통합적으로 관리하기 위해 이벤트 중심 비동기 컴퓨팅 플랫폼(aka. Async)을 자체적으로 구축하여 운영하고 있다고 합니다. 사실 이벤트 중심 비동기 컴퓨팅 플랫폼이라는 거창한 단어를 썼지만, AWS 의 Lamda 나 네이버 클라우드 플랫폼의 Cloud Functions 와 같은 서버리스 컴퓨팅과 비슷하다는 느낌이 드네요. 초기 버전의 Async 는 비동기 요청을 중앙 집중식 데이터베이스에 저장하고 Dispatcher 라는 모듈에서 간단한 우선순위 전략으로 요청을 정렬하고 비동기 처리서버로 전달하는 단순한 구조였는데, 서비스가 커지면서 다양한 유즈케이스와 트래픽의 증가를 시스템이 따라잡을 수 없었고 개선이 필요하게 되었다고 합니다. Async 는 총 2번의 개선이 진행되었는데요, 첫번째는 수많은 엔지니어링 팀이 요청하는 트래픽을 처리할 수 있게끔 확장성 있고 신뢰도 높은 시스템을 구축하기 위한 개선이 있었고, 두번째는 다양한 워크로드로 인해 증가하는 시스템의 복잡성을 줄이기 위한 개선이었습니다. 개인적으로 흥미로웠던 점은 첫번째 개선에서 비동기 처리에 대한 우선순위를 지연 허용 시간이라는 기준을 두어 비즈니스 요구 사항에 세분화된 우선순위를 지정할 수 있게 하고 예측할 수 없는 트래픽 상황에서 컴퓨팅 리소스를 최대한 효율적으로 사용하기 위한 용량 최적화 방법과 두번째 개선에서 다양한 워크로드를 대응하기 위해 Tailer(Data 를 읽기 위한 Agent)를 도입하고 pull 방식에서 push 방식으로 변화했을 때 얻은 장점이었습니다. Meta 의 비동기 요청 처리에 대해 관심있으신 분들은 공유드린 원문 내용을 참고해주세요. 📚 원문 - 초기 Async 의 문제점과 개선 내용: https://engineering.fb.com/2020/08/17/production-engineering/async/ - 두번째 Async 개선: https://engineering.fb.com/2023/01/31/production-engineering/meta-asynchronous-computing/