SOA 및 MSA 개념

문서 내 토픽

1. SOA(Service Oriented Architecture)

SOA는 기존 애플리케이션들의 기능을 비즈니스적 의미가 있는 기능단위로 묶고 표준화된 호출 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트 단위로 재조립한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍처입니다. SOA의 주요 특징은 프로세스 중심, 플랫폼 독립적, 어플리케이션 통합, Loosely-Coupled(느슨한 결합) 등입니다.
2. MSA(Micro Service Architecture)

MSA는 대용량 웹 서비스가 많아짐에 따라 정의된 아키텍처로 SOA에 근간을 두고 있습니다. SOA가 엔터프라이즈 시스템을 중심으로 고안된 아키텍처라면 MSA는 SOA 사상에 근간을 두고 대용량 웹 서비스 개발에 맞는 구조로 사상이 경량화되고 대규모 개발팀의 조직구조에 맞도록 변형된 아키텍처입니다. MSA의 주요 구성요소는 API Gateway, API Server, Persistence, User/Client 등입니다.
3. MSA vs. 모놀리틱 아키텍처

MSA와 모놀리틱 아키텍처를 비교하면, MSA는 DevOps 자동화, 개발 독립성, 유지보수 용이성, 확장성 등의 장점이 있습니다. 반면 모놀리틱 아키텍처는 배포/서버 가동시간 소요, 전체 서비스간 영향 높음, 전체 코드이해 필요, 확장성/유연성 낮음 등의 단점이 있습니다.
4. SOA vs. MSA

SOA와 MSA를 비교하면, SOA는 서비스 단위라는 큰 개념을 가지고 있고 ESB(Enterprise Service Bus)를 사용하는 반면, MSA는 SOA에 비해 경량화되고 API Gateway를 사용합니다. 또한 SOA는 동기식 메시지 타입과 대용량 RDBMS를 주로 사용하지만, MSA는 비동기식 메시지 타입과 RDBMS, NoSQL 등 다양한 DB를 지원합니다.
5. MSA 도입시 고려사항

MSA 도입시 고려해야 할 사항은 아키텍처 관점(Legacy 연계/전환 전략, 서비스 단위 정의, API Gateway 도입, 트랜잭션 관리, 서비스 가시화 등)과 조직 관점(조직 문화, Cross Functional Team 구성 등)입니다.
6. MSA 도입/운영시 예상 이슈 및 해결 방안

MSA 도입/운영시 예상되는 이슈로는 개발 관점(Micro 서비스 설계 복잡성, Legacy 시스템과의 복잡한 연계, 서비스별 테스트 어려움, 서비스별 프로그램 코드/데이터 중복), 운영 관점(다양한 마이크로서비스 운영 오버헤드, 분산시스템 복잡성/비동기성 증가), 관리 관점(마이크로서비스 단위 개발/운영 관리 복잡성, 마이크로서비스 조직 구조간 불일치) 등이 있습니다. 이에 대한 해결 방안으로는 DDD 설계기법 활용, API Gateway 구성, Reactive Architecture 도입, DevOps 운영체계 도입, Agile/Scrum 방법론 활용 등이 있습니다.

Easy AI와 토픽 톺아보기

1. SOA(Service Oriented Architecture)

SOA(Service Oriented Architecture)는 기업의 비즈니스 프로세스를 독립적인 서비스로 구현하여 유연성과 재사용성을 높이는 아키텍처 패턴입니다. SOA는 서비스 간 느슨한 결합을 통해 비즈니스 요구사항의 변화에 신속하게 대응할 수 있으며, 서비스 간 상호운용성을 높여 시스템 통합을 용이하게 합니다. 또한 서비스 기반 설계로 인해 기존 시스템의 재사용이 가능하여 개발 비용을 절감할 수 있습니다. 그러나 SOA는 서비스 간 복잡한 의존관계로 인해 시스템 전체의 복잡도가 증가할 수 있으며, 서비스 간 통신 오버헤드로 인한 성능 저하 문제가 발생할 수 있습니다. 따라서 SOA 도입 시 이러한 단점을 고려하여 적절한 서비스 설계와 통신 최적화 등의 대책이 필요합니다.
2. MSA(Micro Service Architecture)

MSA(Micro Service Architecture)는 단일 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 분할하는 아키텍처 패턴입니다. MSA는 각 서비스가 독립적으로 개발, 배포, 확장될 수 있어 시스템의 유연성과 확장성을 높일 수 있습니다. 또한 기술 스택의 다양성을 허용하여 최적의 기술을 선택할 수 있으며, 서비스 간 느슨한 결합으로 인해 시스템 전체의 복잡도를 낮출 수 있습니다. 그러나 MSA는 서비스 간 통신, 서비스 검색, 서비스 모니터링 등 분산 시스템 관리의 복잡성이 증가할 수 있으며, 서비스 간 데이터 일관성 유지, 트랜잭션 관리 등의 과제가 있습니다. 따라서 MSA 도입 시 이러한 문제점을 해결할 수 있는 적절한 기술과 프로세스가 필요합니다.
3. MSA vs. 모놀리틱 아키텍처

모놀리틱 아키텍처와 MSA(Micro Service Architecture)는 애플리케이션 구조의 차이가 있습니다. 모놀리틱 아키텍처는 단일 애플리케이션 내에 모든 기능이 통합되어 있는 반면, MSA는 독립적으로 배포 가능한 작은 서비스들로 구성됩니다. 모놀리틱 아키텍처는 개발과 배포가 상대적으로 단순하지만, 시스템 전체의 복잡도가 높고 확장성이 낮습니다. 반면 MSA는 서비스 간 느슨한 결합으로 인해 시스템 복잡도가 낮고 확장성이 높지만, 서비스 간 통신, 모니터링, 트랜잭션 관리 등의 분산 시스템 관리 복잡성이 증가합니다. 따라서 프로젝트의 특성과 요구사항에 따라 모놀리틱 아키텍처와 MSA 중 적절한 아키텍처를 선택해야 합니다.
4. SOA vs. MSA

SOA(Service Oriented Architecture)와 MSA(Micro Service Architecture)는 모두 서비스 기반 아키텍처 패턴이지만, 서비스의 단위와 구현 방식에 차이가 있습니다. SOA는 비즈니스 프로세스 단위의 서비스를 구현하는 반면, MSA는 더 작은 단위의 기능 서비스를 구현합니다. SOA는 서비스 간 느슨한 결합을 통해 유연성을 확보하지만, 서비스 간 복잡한 의존관계로 인해 시스템 전체의 복잡도가 증가할 수 있습니다. 반면 MSA는 더 작은 단위의 서비스로 인해 시스템 복잡도가 낮지만, 분산 시스템 관리의 어려움이 있습니다. 따라서 프로젝트의 특성과 요구사항에 따라 SOA와 MSA 중 적절한 아키텍처를 선택해야 합니다.
5. MSA 도입시 고려사항

MSA(Micro Service Architecture) 도입 시 고려해야 할 주요 사항은 다음과 같습니다. 첫째, 서비스 설계 및 분할 전략이 중요합니다. 서비스 간 적절한 경계를 설정하고, 서비스 간 의존관계를 최소화해야 합니다. 둘째, 서비스 간 통신 및 데이터 일관성 유지를 위한 기술 선택이 필요합니다. 메시징 큐, API Gateway, 트랜잭션 관리 등의 기술을 적절히 활용해야 합니다. 셋째, 서비스 배포, 모니터링, 장애 관리 등 분산 시스템 운영을 위한 프로세스와 도구가 필요합니다. 넷째, 개발자의 역량 강화와 조직 문화 변화가 필요합니다. MSA는 개발자의 자율성과 책임감을 요구하므로, 이에 맞는 조직 문화 조성이 중요합니다. 이와 같은 고려사항을 바탕으로 MSA를 단계적으로 도입하고, 지속적인 개선 활동이 필요합니다.
6. MSA 도입/운영시 예상 이슈 및 해결 방안

MSA(Micro Service Architecture) 도입 및 운영 시 예상되는 주요 이슈와 해결 방안은 다음과 같습니다. 첫째, 서비스 간 통신 및 데이터 일관성 유지 문제입니다. 이를 해결하기 위해 메시징 큐, API Gateway, 트랜잭션 관리 기술 등을 활용할 수 있습니다. 둘째, 서비스 검색 및 서비스 간 의존성 관리 문제입니다. 서비스 레지스트리, 서비스 메시 등의 기술을 활용하여 서비스 검색과 의존성 관리를 자동화할 수 있습니다. 셋째, 서비스 모니터링 및 장애 관리 문제입니다. 분산 트레이싱, 로깅, 알람 등의 기술을 활용하여 서비스 상태를 실시간으로 모니터링하고, 장애 발생 시 신속한 대응이 가능합니다. 넷째, 배포 자동화 및 인프라 관리 문제입니다. CI/CD 파이프라인, 컨테이너 기술, 오케스트레이션 도구 등을 활용하여 배포 자동화와 인프라 관리를 효율화할 수 있습니다. 이와 같은 기술적 해결책과 더불어 조직 문화 변화, 개발자 역량 강화 등의 노력이 필요합니다.