Netflix API 아키텍처 진화
MSA 기술과 적용 연구 11
링크드인 2촌인 Alex Xu의 글에서 눈에 띄는 그림이 있었다. 이런 시스템 진화는 자연스러운 전개라 할 수 있어 그의 글을 일부 요약하고 메모를 덧붙여본다.
한 덩어리 시절(Monolith)
Alex xu는 이렇게 썼다.
The application is packaged and deployed as a monolith, such as a single Java WAR file, Rails app, etc. Most startups begin with a monolith architecture.
그렇다. 스타트업은 시장에 부합한다는 PMF(Product Market Fit)를 증명해야 하는데, MSA 적용까지 해가면서 응용 프로그램을 개발할 여력은 없다. 하지만 PMF 증명이 되고 투자가 들어오고 자연스레 인원이 늘고, 빠른 시장 대응 속도를 요구하면 (엉키고 혼재된) 한 덩어리 구조로는 빠른 대처가 어렵다.
마이크로 서비스 직접 접근(Direct Access)
마이크로 서비스에 클라이언트가 알아서 접근한다. 북경에서 팡팡서비스를 할 때 이 모습이었다. 비효율이 있지만, 개발자간 연관성이 적어 기능 추가는 가장 빠르다. 스타트업의 성장 시기에 채택하기 쉽다.
In this architecture, a client app can make requests directly to the microservices. With hundreds or even thousands of microservices, exposing all of them to clients is not ideal.
Alex xu는 이상적이지 않다(not ideal)고 썼는데, 수많은(hundreds or even thousands) 서비스와 이를 사용하는 클라이언트 코드가 제각각이라는 점이 문제다. 정해진 규칙이나 통일성이 없으니 개발자 개인에 의존하는 부분이 많고, 교차하여 개발 업무를 맡으면 효율이 떨어진다.
Gateway 층을 두기(Gateway Aggreation Layer)
하나로 묶는 식이다. 작년에 무턱대고 Istio를 쓰고 싶다는 사람이 있어서 논쟁을 한 일이 있다. 각각 다른 곳에서 두 차례나 그랬다. 나는 여전히 시작부터 Gateway를 두는 방법에 대해 효과적인지 의문이다. (필자는 10년 정도 개발을 직접 하고 있지 않고 있음을 염두하고 읽으시길)
Alex xu 의 글을 보면 위 그림이 적절하게 추상화 한 것인지 의문이 들기도 한다.
Some use cases may span multiple services, we need a gateway aggregation layer. Imagine the Netflix app needs 3 APIs (movie, production, talent) to render the frontend. The gateway aggregation layer makes it possible.
프로그래밍 과정에서 데이터 조작의 기준으로 자주 쓰이는 개념인 Entity가 너무 작을 때 유관한 Entity를 묶어서 Aggregate로 다루는 일은 자연스럽다. 이와 매우 유사하게 마이크로 서비스에 접근할 때도 Aggregate 층을 둘 수 있다. MSA를 적용하다보면 마치 하나의 마이크로 서비스가 하나의 독립적인 분산 Entity 처럼 느껴지기도 한다. 그런 느낌을 앞선 이미지에서는 해당 층을 하나로 묘사해서 논리적 묶음이라는 필요성 자체를 모호하게 표현해 오해의 소지가 있다.
규칙을 두고 정리한 방식(Federated Gateway)
Alex xu 의 설명에서 눈에 띄는 표현은 GraphQL 입니다.
As the number of developers grew and domain complexity increased, developing the API aggregation layer became increasingly harder. GraphQL federation allows Netflix to set up a single GraphQL gateway that fetches data from all the other APIs.
Graph 형태의 데이터를 HBR같은 경영지에서도 다룹니다. 그래서 비즈니스 (시장 요구) 측면에서는 짐작할 수 없지만, GraphQL을 써본 경험이 없는지라 추후에 그가 소개한 링크를 읽어봐야 겠습니다.
다만, 최근 CTO님이 언급한 BFF(Backend For Fronted) 패턴이 떠오르네요.
저자 Viduni Wickramarachchi는 BFF의 장점을 여섯 가지로 설명합니다.
관심사의 분리(Separation of concerns)
지속적인 API 수정이 쉬움(Easier to maintain and modify APIs)
프론트 코드에서 에러 처리에 유리(Better error handling in the frontend)
다양한 기기에서 동시에 백엔드 호출에 유리(Better error handling in the frontend)
보안 이점(Better security)
팀의 코드 공동 소유(수정)에 적합(Shared team ownership of components)
한편, BFF 패턴은 또한 아키텍처 패턴으로 보면 포트와 어댑터(혹은 헥사고널)를 구현하는 방식입니다. 다만 클라이언트와 서버라는 이분법에서 파생되어 나온 듯한 작명입니다. 다만, 포트와 어댑터는 흔히 말하는 백엔드도 유형으로 나눠볼 수 있는 관점이라 BFF와 같은 의미는 아닙니다.
MSA 기술과 적용 연구 시리즈
