SOA, MSA 아키텍처란?

SOA, MSA 아키텍처란?

📌SOA

• SOA(Service Oriented Architecture)는 1990년대에 정의되어, 2008년에 유행했던 아키텍처 스타일이다.
• 현대의 서버 아키텍처는 SOA 사상에 많은 영향을 받았고 많은 분산 아키텍처가 거의 이 SOA 사상에 기인한다고 해도 될 만큼 중요한 아키텍처이다.

SOA의 기본 개념

• SOA란 기존 애플리케이션들의 기능을 비즈니스적인 의미가 있는 기능 단위로 묶고, 표준화된 호출 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트 단위로 재조합한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍처이다.
• 기존의 시스템이 각각 독립된 업무 시스템으로 개발되어왔던 반면에 SOA는 기업의 전체 업무가 하나의 거대한 SOA 시스템으로 구성이 된다.
• 각 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스(예를 들어 XML/HTTP, CORBA, SOAP)를 구현하여 외부 서비스로 제공한다.
• 이렇게 제공된 서비스 이벤트를 조합하여, 새로운 기능을 개발할 때, 시스템을 신규 개발하는 것이 아니라, 기존에 제공된 서비스들을 조합하여 하나의 업무를 구현할 수 있다.

특징

• 수직적 분할(Vertical Slicing) : 수직적 분할이란 애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 말한다. 따라서 각 서비스간의 의존성이 최소화 된다.
• 표준 인터페이스 기반(Has Standard Interface) : 서비스가 제공하는 인터페이스는 표준 기술로 구현되어야 한다. 서비스를 사용하고자 하는 사람이 ‘서비스 규약’ 만을 가지고도 해당 서비스를 호출 할 수 있어야 한다.
• 느슨한 결합(Loosely Coupled) : 수직적 분할에서도 설명하였듯 각 서비스 컴포넌트들은 다른 서비스에 대해서 의존성이 최소화되어 있어서 서비스의 구현 내용을 변경하였을 때 다른 서비스는 이에 거의 영향을 받지 않는다.
• 조합 가능(Composable) : 서비스형 컴포넌트들은 서로 연결되어 하나의 조합된 형태의 애플리케이션을 구성해야하기 때문에, 서비스 간에 연결 및 조합이 가능해야한다.

---

Monolithic 아키텍처

기존 legacy System의 경우 monolithic 아키텍처를 따르는 large 어플리케이션들은 다음과 같은 개발/운영상의 문제들에 직면하게 됩니다.

• 기존의 전통적인 웹 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직이 들어가있는 ‘통짜 구조’이다.
• 전체 애플리케이션을 하나로 처리하기 때문에 개발 도구에서 하나의 애플리케이션만 개발하면 되고, 배포 역시 간편하며 테스트도 하나의 애플리케이션만 수행하면 되므로 간편하다.

문제점

• 작은 크기의 애플리케이션에서는 유리하지만, 규모가 큰 애플리케이션에서는 불리한 점이 많다.
• 크기가 커서 빌드 및 배포시간, 서버의 가동 시간이 오래 걸린다.(서버 가동에만 2시간까지 걸리는 경우도 있다)
• 시스템 컴포넌트들이 서로 로컬 콜 기반으로 타이트하게 연결되어 있으므로, 전체 시스템의 구조를 제대로 파악하지 않고 개발을 진행하면 특정 컴포넌트나 모듈에서의 성능 문제나 장애가 다른 컴포넌트에까지 영향을 주게 된다.
• 이러한 문제를 해결하려면 개발자가 대략적인 전체 시스템의 구조를 이해햐야하는데 시스템의 구조가 커질 수록 이해하기 힘들다.
• 특정 컴포넌트를 수정할 때, 컴포넌트 재배포 시 수정된 컴포넌트만 재배포 하는 것이 아니라 전체 애플리케이션을 재컴파일해서 전체를 다시 통을 재배포 해야한다.
• 이 때문에 잦은 배포가 있는 시스템은 불리하며 컴포넌트 별로 기능/비기능에 특성에 맞춰서 다른 기술을 도입하고자 할 때 유연하지 않다.

---

📌마이크로 서비스 아키텍처(MSA)

• 마이크로 서비스 아키텍처(MSA)는 근래의 웹 기반 분산 시스템의 디자인에 많이 반영되어 있는 스타일로, 특정 사람이 정의한 아키텍처가 아니라 분산 웹 시스템과 비슷한 구조로 설계 되면서 개념적으로만 존재하던 개념이다.
• 마이크로 서비스 아키텍처는 대용량 웹 서비스가 많아짐에 따라 정의된 아키텍처인데, 그 근간은 SOA(Service Oriented Architecture)에 두고 있다. SOA가 엔터프라이즈 시스템을 중심으로 고안된 아키텍처라면, 마이크로 서비스 아키텍처는 SOA 사상에 근간을 두고, 대용량 웹 개발 서비스 개발에 맞는 구조로 사상이 경량화 되고 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처이다.

MSA 특징

• 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.
• 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.
• 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
• 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
• 작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.

MSA 아키텍처 구조

• 배포 구조 관점에서도 각 서비스는 독립된 서버로 타 컴포넌트와의 의존성 없이 독립적으로 배포된다.
• 확장을 위해서 서비스가 배치된 톰캣 인스턴스는 횡적으로 스케일(인스턴스를 더함으로써)이 가능하고, 앞단에 로드 밸런서를 배치하여 서비스 간의 로드를 분산 시킨다.
• 애플리케이션 로직을 분리해서 여러 개의 애플리케이션으로 나눠서 서비스화하고 서비스 별로 톰캣을 분산 배치한 것이 가장 큰 특징이다.

 

데이터 분리

• 데이터 저장 관점에서는 중앙 집중화된 하나의 데이터베이스를 사용하는 것이 아니라, 서비스 별로 별도의 데이터베이스를 사용한다.
• 데이터베이스의 종류 자체를 다른 데이터베이스로 사용할 수도 있지만, 같은 데이터베이스를 사용하더라도 DB를 나누는 방법을 사용한다.
• 이 경우 다른 컴포넌트에 대한 의존성 없이 서비스를 독립적으로 개발 및 배포 / 운영 할 수 있다는 장점을 가지고 있으나, 다른 컴포넌트의 데이터를 API 통신을 통해서 가지고 와야하므로, 성능상의 문제를 일으킬 수 있고, 또한 이 기종 데이터베이스 간의 트랜잭션을 묶을 수 없다는 문제점이 있다.

 

API GATEWAY

마이크로 서비스 아키텍처의 문제점 중 하나는 각 서비스가 다른 서버에 분리, 배포 되기 때문에 API의 엔드포인트, 즉 서버의 URL이 각기 다르다는 것이다. 사용자 컴포넌트는 http://user.server.com, 상품 컴포넌트는 http://product.server.com과 같은 분리된 URL을 사용하는데 이는 API 사용자 경험 관점에서도 사용하기 불편하다.

API GATEWAY를 이용하여 이러한 토폴로지의 문제점을 해결하기 위해서, 중앙에 서비스 버스와 같은 역할을 하는 채널을 배치 시켜서 전체 토폴로지를 Hub & Spoke 방식으로 변화시켜서 서비스 간 호출을 단순화 시킬 수 있다.

• 마이크로 서비스 아키텍처 설계에서 가장 많이 언급되는 컴포넌트 중에 하나가 API GATEWAY라는 컴포넌트이다.
• API GATEWAY는 마치 프록시 서버처럼 API들 앞에서 모든 API에 대한 엔드 포인트를 통합하고, 몇 가지 추가적인 기능을 제공하는 미들웨어로, 다음과 같은 기능을 제공한다.
• API에 대한 인증(Authentication)이나 로깅과 같은 공통 기능에 대해서 서비스 컴포넌트 별로 중복 개발해야 하는 비효율성을 유발할 수 있다. API GATEWAY에서 이러한 공통 기능을 처리하게 되면, API 자체는 비즈니스 로직에만 집중하여 개발중에 발생할 수 있는 중복을 방지할 수 있다.

---

MSA 장점

장점	설명
1. 독립적으로 배포 가능하고 개발자의 자율성 증가	모놀리식의 경우에는 서버를 내린 후 변경사항을 한번에 적용하기 때문에 내가 A 부분을 다 개발했는데 다른 사람이 B 부분을 개발하지 못했다면 다른 사람들이 모두 완성할 때까지 그냥 놀고 있으면 된다.  반면 MSA의 경우에는 파트별로 다 프로젝트가 따로 돌아가기 때문에 남이 만들건 말건 언제든지 내가 만든 내용을 적용시킬 수 있으니 전체 일정과는 별개로 내 파트를 계속 개발 가능하다
2. 장애나는 서비스 격리를 통한 서버 재기동 시간 단축	모놀리식의 경우에는 A-Z 까지의 기능 중 A 하나만 고장이 나도 모든 기능이 한 서버에 연결되어 있어서 전체 서버를 내렸다가 다시 올려야 한다서비스가 커지면 커질수록 뭔가를 바꾸려면 결국 서버를 내려야 하기 때문에 서비스의 변화 자체가 매우 느려진다.  반면 MSA의 경우에는 장애나는 서비스만 서버를 내린 뒤 문제를 고치고 다시 올려주면 되기 때문에 서비스 전체가 멈추는 일이 없어지고 뭔가 에러가 나도 그 부분만 막아버리면 되기에 서비스 자체를 안정적으로 계속 사용할 수 있게 된다
3. 팀별 코드 이해도 증가 및 유지보수 난이도 저하	모놀리식의 경우에는 뭐 에러 하나 발생하면 디버그를 타고 프로젝트 전체를 쑤시고 다녀야 한다. 하지만 MSA의 경우에는 API만 문제가 없으면 본인들 프로젝트만 확인하면 되기때문에 유지보수 난이도가 확 떨어지고 다른 프로젝트들과는 API를 이용해 통신하기 때문에 내 코드만 이해하면 되서 전체 코드를 더 쉽게 이해할 수 있다

MSA 단점

단점	설명
1. 테스팅이 어려움	마이크로 서비스 아키텍처는 서비스들이 분리되어 있고, 다른 서비스에 대한 종속성을 가지고 있어서, 특정 사용자 시나리오나 기능을 테스트하고자 할 경우 여러 서비스에 걸쳐서 테스트를 진행해야 한다. 이 때문에 테스트 환경 구축이나, 문제 발생시에 분리된 여러 개의 시스템을 동시에 봐야 하기 때문에 테스팅의 복잡도가 올라간다.
2. API 관리의 중요성 증가	MSA는 API를 이용해 각 서비스들을 연결해 주는데 문제는 API를 변경할 경우 수십~수백개의 프로젝트들과 호환이 되는지 확인해 줘야하고 호환이 안되면 바로 대참사가 벌어지게 된다. 애초에 한 서비스가 고장나도 전체 서비스에는 문제가 없도록 하려고 만든게 MSA인데 그걸 연결해주는 API에서 에러가 발생하면 전체 서비스가 마비된다
3. 서비스간 트랜잭션 처리	구현상의 가장 어려운 점 중에 하나가 바로 트랜잭션 처리이다. 이를 해결하기 위한 방법으로 SAGA 패턴을 사용한다.

---

참고

https://wakestand.tistory.com/480

MSA(Microservices Architecture) 개념 및 장단점 정리

https://dongwooklee96.github.io/post/2021/03/27/soa-%EB%AA%A8%EB%86%80%EB%A6%AC%ED%8B%B1-%EA%B7%B8%EB%A6%AC%EA%B3%A0-msa-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98/

SOA, 모놀리틱, 그리고 MSA 아키텍처 | 개발자 이동욱