들어가기에 앞서
Nginx와 로드밸런서라는 단어는 알고만 있었지만, 실제로 프로젝트에 도입한게 이번년도가 처음이였다. 그렇기에 여러가지 trade-off에 대해서 고민이 많았었다. 이 글을 읽고 백엔드 개발로써 이러한 걱정을 조금이나마 해소할 수 있도록 하는 것을 목표로 글을 쓰게 되었다. 내가 경험한 것을 바탕으로 쓰는 만큼 부족한 부분도 잘못된 부분도 있을 수 있다.
MSA VS Monolithic
먼저 로드밸런서를 도입하기 전에 해당 개념을 이해하고 가면 정말 좋을 것 같다는 생각이든다.
Monolithic-Architecture 방식
모노리틱 아키텍처는 전통적인 웹 시스템 개발 방식 중 하나이다. 간단히 말해서 하나의 Application 내에 모든 로직이 들어가 있는 구조를 말한다.
Monolithic에서 로드밸런싱이 굳이 필요해?
내가 찾아본 글에서 위와 같은 말을 하는 사람들이 분명 있었다. 근데 나는 이 말 자체가 대단히 오만하다고 느꼈다. 기본적은 Monolithic의 장단점을 알고있다면 할 수 없는 소리이다. 하지만 그렇다고 무조건적으로 필요하다는 것이 아니다.
이게 무슨 소리인가? 생각 들 수도 있지만, 이 것은 서버의 규모에 따라서 평가가 가능하다. 사람들이 얼마나 들어오고, 동시 접속량이 얼마고, 현재 내 서버의 스펙, 내 프레임워크의 스펙을 보면서 기준을 정할 수 있다고 생각된다.
내가 생각할 때는 Monolithic 방식에서 로드밸런싱을 필요로 하는 경우는 다음과 같다.
- 사용자의 트래픽으로 인해서 프레임워크 요청 시, 병목이 발생할 때
- 서버를 중간에 교체를 해야한다고 했을 때, 중단하지 않고 서버를 가용해야할 때
- 모니터링을 중앙에서 관제하고자 할 때 (트래픽 자체가 Nginx가 다 관리하고 받기 때문에)
- 의도적인 성능의 확장이 필요로 할 때 (Scale에 대한 목적부여)
- 장애에 대한 대응체계 구비가 필요할 때
MSA-Architecture 방식
마이크로서비스 아키텍처는 Application 하나 당 단일 서비스를 제공한다. 이를 하나로 묶어주기 위해서는 필연적으로 로드밸런싱이 필요하게 된다.
왜 필연적인지를 말해주겠다. MSA 는 각각의 독립적인 서비스이다. 이는 그저 같은 로컬 단위에서 서비스들이 분리 되어있을 수도 있으며, 완전히 지역적으로 분리되어있는 경우 또한 존재한다. 이를 하나의 서버처럼 가용하기 위해서는 중간에 proxy를 잡아서 로드밸런싱을 할 필요가 있다는 것이다. 하지만, MSA는 데이터의 관리가 굉장히 어려워진다.
해당 부분에서는 로드밸런싱보다는 데이터의 통합에 대해서 많이 고려를 해야한다.
MSA에서 데이터의 관리와 통합에 대한 고려사항
-
데이터 일관성: 각 마이크로서비스가 자체 데이터베이스를 관리하기 때문에, 서비스 간 데이터 일관성을 유지하는 것이 중요하다. 이를 위해 이벤트 기반 통합 패턴이나 CQRS 패턴을 사용할 수 있다.
-
분산 트랜잭션: 서비스 간의 데이터 일관성을 유지하기 위한 분산 트랜잭션 처리가 필요할 수 있다. 이는 시스템의 복잡성을 증가시킬 수 있으므로 신중히 접근해야 한다.
마무리하며
결론적으로 로드밸런서는 무조건적으로 좋은 것이 아니다. 해당 로드밸런서의 사용을 감당할 만큼 서버 스펙이 준비되어있어야 하며, 애초에 로드밸런싱을 사용할만큼의 트래픽 수준인가를 고려해야한다. 만약에 이를 공부삼아서 구현하고자 한다면 스트레스 테스트를 진행하면서 자신이 목표한 수준의 부하를 잘 버티는지를 생각해야한다.
다음 게시글은 간단한 시나리오를 설계하고 스트레스 테스트를 하는 내용에 대해서 올릴 것이다.
