카카오페이지 웹 서비스는 graphql을 활용해 BFF를 운영하고 있습니다. 팀 내부에서는 graphql을 사용하는 방법에 대한 노하우들이 적립되어 DX(Developer Experience) 향상과 타 팀과의 커뮤니케이션에 많은 도움을 받으며 BFF를 사용하고 있었는데요. 유명 스트리머 우왁굳의 버추얼 걸그룹 이세계 아이돌의 웹툰이 카카오페이지에 런칭하는 날 트래픽이 3배 이상 몰리게 되며 BFF 서버의 CPU가 100%를 찍는 장애가 발생하게 됩니다. 저희가 문제를 겪으며 알아낸 해결책이 어떤 분께는 도움이 될 수 있을 것 같아 이 글을 쓰게 되었습니다. 문제를 찾아 나가며 알게 된 꿀팁들도 적어 볼 테니 재밌게 봐주셨으면 좋겠습니다.이세계 아이돌 웹툰 런칭 서비스 장애2023년 6월 21일 22시 이세계 아이돌의 웹툰 마법소녀 이세계 아이돌 이 카카오페이지와 카카오웹툰에 런칭하게 됩니다. 스트리머 우왁굳과 버추얼 아이돌 그룹 이세계 아이돌 멤버들이 트위치에서 실시간 생중계를 하며 런칭을 기다렸고, 많은 시청자들이 웹을 통해 작품에 접속하게 되면서 서버가 응답을 내려주지 못하는 장애가 일어나게 됩니다. 수분 정도 페이지가 뜨지 않는 현상이 있었고, 리소스 대비 생각보다 TPS가 안 나오고 있는 것을 발견하여 성능 개선을 우선 과제로 보고 여러 가설을 세워 문제를 찾아나가기 시작했습니다.BFF는 백엔드 API를 호출해서 응답을 가공해 클라이언트로 내려주는 역할 정도만 하고 있어서 CPU가 올라갈 만한 문제의 원인에 감이 안 오는 상황이었는데요. 저희 팀은 여러 가지 가설을 세워 문제의 원인을 찾아내고자 했습니다. 원인이 확실하게 떠오르지 않아 생각나는 대로 가설 리스트를 만들고 하나씩 넣어보며 원인을 찾아 나섰습니다. 가설을 말씀드리기 전에 일단 저희 구성도를 간단히 설명해 드리겠습니다.저희는 서비스 운영에 쿠버네티스를 활용하고 있고, 서버사이드 렌더링을 하는 next.js pod들과(인스턴스라 생각해 주시면 되겠습니다.) BFF를 담당하는 pod들이 따로 떠 있는 상황입니다. BFF에 요청이 들어오면 그에 맞는 백엔드 API를 호출하고, API 응답을 받은 후에는 클라이언트가 요청한 gql 포맷에 맞게 응답을 가공해 내려주는 작업을 진행합니다. BFF 환경은 node.js express에 apollo server를 사용해 띄우고 있었는데요. REST API로 데이터를 받아와 가공 정도만 하는 BFF 서버가 서버사이드 렌더링을 하여 html을 그려주는 next.js 서버보다 성능이 안 나오는게 이해가 안 되는 상황이었죠.제일 간단하게 생각을 해봤을 때 장애 당시 백엔드 응답이 늦어서 BFF도 응답을 내려주기까지 시간이 오래 걸려 타임아웃이 발생한 게 아닐까 하는 생각이 들었습니다. 하지만 당시 백엔드 팀의 모니터링 결과로는 응답 중에서는 특이하게 느린 응답이나 생각보다 부하가 없었다는 얘기를 전달받게 됩니다. 그렇다면 저희 쪽 BFF 서버에서 뭔가의 문제가 있는 것인데.. 정확한 확인을 위해 현 상황에서 nGrinder를 통해 부하 테

안녕하세요. 오토피디아의 서비스개발팀장을 맡고 있는 김승수 입니다. 오토피디아의 모놀리틱 GraphQL 서버의 기능들이 하나 둘 씩 별개의 마이크로서비스로 분리되어 나감에 따라 서비스개발팀에서 GraphQL Federation의 도입을 고민하게 되었습니다. 그 과정에서 GraphQL Federation의 이론과 Apollo Federation을 이용한 구현 방법에 대해 조사한 내용을 공유하려고 합니다.GraphQL Federation의 목적프론트엔드 개발자 입장에서 GraphQL의 가장 큰 장점은 하나의 요청으로 원하는 모든 데이터를 over/under-fetching 걱정 없이 쿼리할 수 있다는 것 입니다. 서버의 GraphQL schema와 GraphQL 쿼리문을 작성하는 방법만 안다면 REST API를 하나하나 호출하는 것보다 데이터를 훨씬 쉽게 가져올 수 있습니다. 이러한 특성 때문에 GraphQL은 BFF(Backend for Frontend)를 대체하는 방법이기도 합니다.하지만 서버가 모놀리틱에서 여러 마이크로서비스로 쪼개진다면 어떨까요? 각 마이크로서비스를 관리하는 팀이 자신들이 담당하는 컨텍스트 개발에만 집중할 수 있게되므로, 이는 분명 백엔드 개발자에게는 좋은 방향입니다. 그러나, 프론트엔드 개발자 입장에서는 아닙니다. 한 서버, 즉 한 GraphQL schema에 요청하던 것을 여러 마이크로서비스의 GraphQL schema에 각각 쿼리를 작성해 요청하고, 요청 받은 데이터들을 프론트엔드에서 취합해야 합니다. 하나의 요청으로 원하는 모든 데이터를 쿼리할 수 있다는 GraphQL의 장점이 사라진 것 입니다.GraphQL Federation이란?GraphQL Federation이란 여러 GraphQL 마이크로서비스의 GraphQL schema를 조합하여 하나의 큰 GraphQL schema로 만드는 방식을 말합니다. 하나의 router가 각 마이크로서비스에서 제공하는 GraphQL schema(subgraph)를 합친 통합 GraphQL schema(supergraph)를 제공하고, 클라이언트는 이 supergraph를 보고 쿼리를 작성해 요청하면 됩니다. Router는 요청된 쿼리문을 분리하고, 각 분리된 쿼리문을 담당하는 마이크로서비스에 보낸 뒤, 돌아온 데이터들을 합쳐 클라이언트에게 돌려줍니다.이러한 특성으로 GraphQL Federation은 위에서 언급한 문제를 해결할 수 있습니다. GraphQL Federation을 잘 활용하는 기업은 Netflix가 대표적입니다. Netflix에서 GraphQL Federation을 활용하는 방법에 대한 유투브 동영상 도 있으니 시간 되실때 한 번 시청하시면 좋을 듯 합니다.GraphQL Federation의 예시. 사용자, 상품, 리뷰 마이크로서비스의 schema를 router에서 조합하여 클라이언트에 제공한다. 출처: https://www.apollographql.com/docs/federation/GraphQL 기본 개념이 글에

요즘 MSA(Micro Service Architecture)를 많이 사용하게 되는데, 개발하다 보면 다음과 같은 상황들이 펼쳐질 수 있습니다.여러 플랫폼(Web, Android, iOS …)을 지원하게 되면서 각각 특정 데이터가 필요한 상황원하는 데이터 형태에 도달하기 위해 여러 API 호출의 응답을 조작, 혼합, 일치시키는 상황이런 상황들이 겹쳐 프론트엔드에서 복잡한 계산이나 비즈니스 로직을 작성하는 상황코드 베이스가 커지고 복잡해짐에 따라 정리하기가 어려워지고, 그때쯤이면 코드 베이스가 통제 불능 상태가 되며 버그가 숨어 있는 복잡성을 발견하게 됩니다. 특히 프론트엔드에서 복잡한 계산을 수행하는 경우 렌더링이 느려질 수 있습니다. UI 스레드에서 렌더링과 비즈니스 로직 수행이 경합을 벌이기 때문입니다.그렇다면 이를 개선하기 위한 방법은 무엇이 있을까요? 일반적으로 사용되는 API 형식과 BFF 구조를 비교하며 살펴봅시다.일반적인 API 구조일반적인 API 구조다양한 플랫폼을 지원하는 API는 때로 애플리케이션에서 사용하지 않는 불필요한 데이터가 포함될 수 있습니다.그림과 같이 여러 플랫폼이 있을 경우, 프론트엔드에서는 동일한 API를 호출하게 됩니다. 백엔드 개발자는 여러 플랫폼의 모든 요구사항들을 충족시키기 위해 모든 데이터를 내려주도록 API를 구현하게 됩니다. 이외에도 백엔드 쪽에서 데이터를 처리하기 위해 필요했던 부가적인 것들을 내려주거나, 단일 페이지에서 여러 API를 호출하는 경우도 발생합니다.또한, 직접 API에 의존할 때 여러 가지 이슈가 발생할 수 있습니다.MSA(Micro Service Architecture) 환경에서 API 엔드포인트가 분리될 때 팔로업 이슈브라우저의 숙명인 CORS 이슈API 입장에서 여러 플랫폼과 스펙을 맞출 때의 커뮤니케이션 비용플랫폼별로 다를 수밖에 없는 인증 방식을 통합하려는 무리한 시도클라이언트의 꿈인 ‘화면에 필요한 데이터만 받는’ partial response를 하기 어려운 이슈BFF 구조각 플랫폼에 BFF를 적용한 구조API를 다이렉트로 의존할 때의 이슈들을 해결하고자 BFF가 등장합니다. Backend For Frontend라는 말 그대로 프론트엔드를 위한 중간 서버를 구현하는 것이라고 생각하면 됩니다.그림과 같이, 하나의 프론트엔드에 대해 하나의 BFF가 있어야 하며 BFF를 프론트엔드 요구사항에 맞게 구현할 수 있습니다. 따라서, 여러 플랫폼을 지원하지 않을 경우에는 BFF가 의미 없을 수 있습니다.참고로 카카오페이지는 iOS, Android, Web을 지원하고 있고, Web에서만 BFF를 적용을 하고 있습니다.BFF에서는 프론트엔드 생선성을 더욱 높이기 위해, 데이터를 통합하는 처리를 담당합니다. 또한, BFF를 구현하여 프론트엔드를 백엔드에서 분리된 상태로 유지할 수 있습니다. BFF는 프론트엔드 요구사항을 충족하기 위해 존재하며, 이상적으로는 프론트엔드 개발자가 빌드해야 합니다.결론적으로, 앞서 얘기했던 API 의존성 이슈들을 BFF 쪽에서 처리를 해줄 수 있습니다.M

요즘 MSA(Micro Service Architecture)를 많이 사용하게 되는데, 개발하다 보면 다음와 같은 상황들이 펼쳐질 수 있습니다. * 여러 플랫폼(Web, Android, iOS )을 지원하게 되면서 각각 특정 데이터가 필요한 상황 * 원하는 데이터 형태에 도달하기 위해 여러 API 호출의 응답을 조작, 혼합, 일치시키는 상황 * 이런 상황들이 겹쳐 프론트엔드에서 복잡한 계산이나 비즈니스 로직을 작성하는 상황 코드 베이스가 커지고 복잡해짐에 따라 정리하기가 어려워지고, 그때쯤이면 코드 베이스가 통제 불능 상태가 되며 버그가 숨어 있는 복잡성을 발견하게 됩니다. 특히 프론트엔드에서 복잡한 계산을 수행하는 경우 렌더링이 느려질 수 있습니다. UI 스레드에서 렌더링과 비즈니스 로직 수행이 경합을 벌이기 때문입니다. 그렇다면 이를 개선하기 위한 방법은 무엇이 있을까요? 일반적으로 사용되는 API 형식과 BFF 구조를 비교하며 살펴봅시다. 일반적인 API 구조 일반적인 API 구조 다양한 플랫폼을 지원하는 API는 때로 애플리케이션에서 사용하지 않는 불필요한 데이터가 포함될 수 있습니다. 그림과 같이 여러 플랫폼이 있을 경우, 프론트엔드에서는 동일한 API를 호출하게 됩니다. 백엔드 개발자는 여러 플랫폼의 모든 요구사항들을 충족시키기 위해 모든 데이터를 내려주도록 API를 구현하게 됩니다. 이외에도 백엔드 쪽에서 데이터를 처리하기 위해 필요했던 부가적인 것들을 내려주거나, 단일 페이지에서 여러 API를 호출하는 경우도 발생합니다. 또한, 직접 API에 의존할 때 여러가지 이슈가 발생할 수 있습니다. * MSA(Micro Service Architecture) 환경에서 API 엔드포인트가 분리될 때 팔로업 이슈 * 브라우저의 숙명인 CORS 이슈 * API 입장에서 여러 플랫폼과 스펙을 맞출 때의 커뮤니케이션 비용 * 플랫폼별로 다를 수 밖에 없는 인증 방식을 통합하려는 무리한 시도 * 클라이언트의 꿈인 화면에 필요한 데이터만 받는 partial response를 하기 어려운 이슈 BFF 구조 각 플랫폼에 BFF를 적용한 구조 API를 다이렉트로 의존할 때의 이슈들을 해결하고자 BFF가 등장합니다. Backend For Frontend라는 말 그대로 프론트엔드를 위한 중간 서버를 구현하는 것이라고 생각하면 됩니다. 그림과 같이, 하나의 프론트엔드에 대해 하나의 BFF가 있어야 하며 BFF를 프론트엔드 요구사항에 맞게 구현할 수 있습니다. 따라서, 여러 플랫폼을 지원하지 않을 경우에는 BFF가 의미 없을 수 있습니다. 참고로 카카오페이지는 iOS, Android, Web을 지원하고 있고, Web에서만 BFF를 적용을 하고 있습니다. BFF에서는 프론트엔드 생선성을 더욱 높이기 위해, 데이터를 통합하는 처리를 담당합니다. 또한, BFF를 구현하여 프론트엔드를 백엔드에서 분리된 상태로 유지할 수 있습니다. BFF는 프론트엔드 요구사항을 충족하기 위해 존재하며, 이상적으로는 프론트엔드 개발자가 빌드 해야 합니다. 결론적으로, 앞서 얘기했던