빅데이터 처리를 처음 설계하는 엔지니어는 보통 "어떤 서비스를 쓸까"부터 고민한다. EMR? Glue? Athena? 하지만 이 셋은 경쟁 관계가 아니라 같은 엔진(Apache Spark)을 서로 다른 운영 모델로 감싼 것에 가깝다. EMR은 Spark를 클러스터로 직접 운영하게 해주고, Glue는 Spark를 서버리스로 추상화하며, Athena는 Spark/Presto 위에 SQL 인터페이스만 노출한다. 그래서 "무엇을 쓰느냐"의 진짜 질문은 "이 워크로드에서 클러스터를 얼마나 직접 통제해야 하는가, 운영 부담을 어디까지 AWS에 넘길 것인가"이다.
SAP-C02 시험에서 이 영역은 "수만 개 노드로 페타바이트를 처리하는 무거운 Spark 잡을 비용 최적으로 돌리는 법", "수백 개 단계가 의존성을 가진 파이프라인을 오케스트레이션하는 법", "Spot 중단·노드 장애에서 잡이 죽지 않게 하는 법" 같은 운영 아키텍처로 출제된다. 오늘은 EMR/Glue/MWAA가 내부적으로 어떻게 동작하는지, 왜 그렇게 설계됐는지를 분해해 이 시나리오들을 푸는 직관을 만든다.
빅데이터 처리의 출발점은 2004년 구글이 발표한 MapReduce 논문이다. 핵심 아이디어는 단순했다. 거대한 데이터를 작은 조각으로 쪼개 수천 대의 평범한 서버에 흩뿌리고(Map), 각 서버가 자기 조각을 독립적으로 처리한 뒤 결과를 합친다(Reduce)