[Architecture] 모놀리식 아키텍처와 마이크로서비스 아키텍처란?

모놀리식 아키텍처 장점

• 하나의 WAS(Web Application Server)에서 모든 기능을 처리하도록 구성한다.
• 간단한 구조 덕분에 시스템 운영과 개발이 편리한 장점이 있다,
• 네트워크로 인한 지연이나 데이터 유실을 걱정할 필요가 없다.
• 시스템 장애나 기능에 버그가 있다면 개발자는 하나의 애플리케이션에서 원인을 파악하면 된다.
• 여러 클래스에서 발생하는 로그를 하나의 파일에 기록할 수 있기 때문에 쉽게 원인을 파악할 수 있다.
• 데이터 저장소가 하나이므로 RDB의 트랜잭션 기능을 쉽게 사용 할 수 있다.

모놀리식 아키텍처 단점

• 하나의 애플리케이션 서버에서 여러 기능을 제공하므로 서비스 기능이 많아지면 더욱 복잡해질 수 있다,
• 성질이 다른 두 코드가 하나의 파일에 존재하기도 한다.
• 서버 기능과 크라이언트 긴으이 뒤섞인 채 개발할 수밖에 없다.
• 상황에 따라 클라이언트 코드에 버그를 수정할 때도 서버를 다시 실행해야 하는 상황이 발생한다.
• 서비스의 규모가 커지고 제공하는 기능도 많아지면 서로의 충돌이 많이 발생 할 수 밖에 없다.
• 비지니스 영역의 수평적 확장 (스케일 아웃 Scale-out)이 힘들다.

마이크로서비스 아키텍처의 특징

• 잘 분리된 마이크로서비스로 인한 탈중앙화
• 대규모 시스템을 위한 아키텍처
• 가벼운 네트워크 프로토콜
• 느슨한 결합
• 서비스 지향 아키텍처

마이크로서비스 아키텍처의 장점

• 하나의 마이크로서비스는 하나의 비지니스 기능을 담당하므로 다른 마이크로 서비스와 간섭이 최소화 된다. 즉, 각 마이크로서비스는 독립성을 갖게된다.

  • 특히 하나의 마이크로 서비스는 독립된 데이터 저장소를 갖고 있으므로 데이터 간섭에도 자유롭다.

• 대용량 데이터를 저장하고 처리하는데 비교적 자유롭다.

  • 마이크로서비스는 독립된 데이터 저장소를 갖고 있기 때문에 대용량 데이터를 마이크로서비스마다 나누어 저장할 수 있다.
  • 기본적으로 마이크로서비스 숫자만큼 데이터가 분산 저장된다.
  • 또한 데이터 샤딩이나 서비스에 적합한 캐시를 마이크로서비스 단위로 각각 적용할 수 있다.

• 시스템 장애에 견고하다.

  • 마이크로서비스는 서로 느슨하게 결합되어 있고, 각각 독립되어 있기 때문에 서로 간에 미치는 영향이 적다.
  • 마이크로서비스들이 느슨하게 결한된 경우 하나의 마이크로서비스에 장애나 버그가 발생하더라도 다른 마이크로서비스는 이상 없이 서비스 된다.

• 서비스 배포 주기가 빠르다.

  • 모놀리식 아키텍처는 모든 기능이 하나의 코드베이스에서 개발된다. 그러므로 일정 기한동안 모두 개발하고 한번에 배포한다.
  • 하지만, 마이크로서비스 아키텍처는 모든 기능이 분리되어 있으므로 필요한 기능만 먼저 개발하고 배포할 수 있어, 서비스 배포 주기가 빨라진다.
  • 만약, 배포한 서비스가 장애를 이르킨다 하더라도, 느슨한게 결합된 마이크로서비스 특성상 추가된 해당 서비스만 롤백하거나 수정 후 배포하면 된다.

• 마이크로서비스 단위로 확장할 수 있어 서비스 전체적으로 확장성이 좋아진다.

  • 거기에 클라우드 시스템과 결합하면 시스템 컴포넌트들을 동적으로 확장할 수 있다.
  • 또한 필요한 마이크로서비스만 확장할 수 있어 효율적으로 시스템 자원을 사용할 수 있다.
  • 이는 마이크로서비스 아키텍처의 독립성과 더불어 최고 장점이라 할 수 있다.

• 사용자 반응에 민첩하게 대응할 수 있다.

마이크로서비스 아키텍처 단점

• 개발하기 어려운 아키텍처이다.

  • 다른 시스템이 네트워크상에 분산되어 있기 때문이다.
  • 가장 큰 이유는 각각의 마이크로서비스는 독립된 데이터 저장소를 갖는데, 이는 RDB의 최대 장점인 트랜잭션을 사용할 수 없다.
  • 물론 분산 트랜잭션을 사용할 수 있지만, 분산 트랜잭션은 시스템 전체의 리소스를 많이 사용하므로 권장하지 않는다고 한다.
    • 분산 트랜잭션에는 Two-Phase Commit, 과 Saga Pattern 두가지 패턴이 존재한다.
    • https://microservices.io/patterns/data/saga.html
  • 또한 네트워크의 장애, 패킷 누락, 요청한 응답을 받지 못하는 상황, 네트워크 지연이 발생할 수 있다.
  • 이외에도 마이크로서비스를 운영함녀서 발생하는 많은 어려움이 있고, 이는 모놀리식 아키텍처 어플리케이션을 개발하는 것보다 난이도가 높다.

• 운영하기 어려운 아키텍처이다.

  • 각 서비스는 유연하게 연결되어야 하고, 그 서비스에는 복잡한 로직들이 많이 존재한다.
  • 이 복잡한 과정의 모든 요청이 이상 없이 처리되어야 해당 애플리케이션이 이상없이 동작이 될 것이다,
  • 즉, 수 많은 마이크로서비스가 통합되어야 한다.
  • 또한 요청이 정상적으로 처리되지 않았다면 개발자는 어느 단계에서 에러가 발생했느지 찾아야 한다.
  • 수 많은 마이크로서비스 사에서 어떤 요청이 에러였는지 찾아내기는 쉽지 않다.
  • 또한, 데이터가 분산되어 있기 때문에 분산 트랜잭션을 사용하지 않는다면 데이터 일관성을 유지하기 어렵다.

• 설계하기 어려운 아키텍처다.

  • 잘 설계된 마이크로서비스 아키텍처 시스템은 복잡한 비지니스 로직을 개발해서 보다 쉽게 유지 보수할 수 있고, 동시에 많은 사용자 요청을 처리할 수 있다.
  • 하지만, 수많은 이유로 잘못된 방향으로 설계한다면 오히려 유지보수 하는데 더 많은 시간이 소모된다.
  • 각 마이크로서비스가 관리하는 데이터들이 중복될 수 있다. 이런 경우 데이터의 파현화 현상 때문에 일관성 있는 데이터를 유지하기 어렵다.
  • 과도한 네트워크 통신으로 인한 성능 저하, 하나의 서비스 영역이 너무 크면 모놀리식 아키텍처화, 이러한 서비스 다시 분리 등의 어려운 설계 방식이다.

• 마이크로서비스 아키텍처로 설계된 서비스 운영에는 여러 가지 자동화된 시스템이 필요하다.

  • 마이크로서비스 아키텍처를 도입하는 이유는 빠른 서비스 개발과 운영, 대규모 서비스 처리를 위함이다.
  • 이러한 경우 빠른 배포를 위한 CI/CD, 수 많은 인스턴스를 모니터링 해주는 모니터링 시스템, 각 서비스에서 나오는 로그를 관리해주느 시스템 등이 필요하다.
  • 이런 자동화된 시스템들을 운영하고 유지 보수하는 것도 쉬운 일이 아니다.

• 마이크로서비스를 운영하고 개발하는 개발자의 기술력이 좋아야 한다.

  • 하나의 마이크로서비스 개발 속도는 개발자 숫자와 비례해서 선형적으로 증가하지 않는다.
  • 오히려 사람이 많을 수록 사람 사이에서 발생하는 커뮤니케이션 시간과 노력은 기하급수적으로 증가한다.
  • 각 팀원의 기술 성숙도가 낮은 팀은 마이크로서비스를 하기에 부적합하며, 오히려 개발 속도와 서비스 안전성 면에서 역효과가 발생할 수 있다.