1. SOA란?
기존 어플리케이션들로 구현한 업무기능들을 비즈니스적인 의미를 지닌 기능 단위로 묶고, 표준화된 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트 단위로 재 조합하여, 필요한 업무 기능을 때맞춰(신속하게)만들어낼 수 있는 서비스 지향적인 소프트웨어 아키텍처를 말합니다.
IT업계의 요구사항이 많아지고 변화가 빨라짐에 따라 이에 대처하기 위해 나타난 Architecture이고, 구성요소를 3가지로 분류합니다.
1-1.service Consumer
서비스의 사용자. 서비스 제공자에 의해 제공되는 하나 이상의 서비스를 이용합니다. 사용자는 실제 클라이언트(End-User)또는 다른 서비스가 될 수 있습니다.
1-2. Service Provider
서비스 사용자의 요청에 맞는 서비스를 제공하며, 사용자가 입력한 데이터를 처리하여 결과를 제공합니다. 다른 서비스를 이용할 경우 Provider는 다른 Service의 Consumer가 될 수도 있습니다.
1-3. Sercvice Registry
서비스의 정보를 저장한다. Provider가 Registry를 통해 Consumer에게 서비스를 제공합니다. 서비스 제공자에 의해 서비스되는 서비스를 등록하고, 서비스 사용자가 서비스를 발견할 때 사용합니다.
SOA 는 비즈니스적으로 구분된 Service 들을 느슨하게 연결하며, 각 컴포넌트를 독립적으로 운용하여 조립이 가능하게 합니다.일반적으로 Service 를 위해 서비스 기능별로 모듈을 분리하고, 각 모듈이 다른 모듈과 상호작용할 수 있도록 만들어진 Architecture 입니다.
▶ SOA는 서비스와 이를 조합하여 어플리케이션을 구성하는 것
2. SOA가 주목 받는 이유
3. SOA에서의 서비스
플랫폼에 종속되지 않는 표준 인터페이스를 통해서 기업의 업무를 표현한 '느슨하게 연결되고(Loosely Coupled) 상호 조합 가능한 소프트웨어‘입니다.
현대의 SOA에서 서비스의 플랫폼 종속성은 SOAP 기반의 Web Service 또는 XML을 통해서 구현됩니다. 서비스를 표현하는데 있어서 가장 중요한 특징은 ‘기업의 업무를 표현한다’입니다.
4. 서비스의 구성
서비스 인터에이스 : EJB나 Java Object의 비즈니스 메서드 서비스 규약 : 서비스를 사용하기 위한 규약, 데이터 포맷, 변수형 서비스를 호출하기 위한 인자, 인터페이스 이름 등의 정의되는 Contract 서비스의 구현체 : Implementation, 데이터와 비즈니스 로직을 모두 포함
5. 서비스의 종류
5-1 비즈니스 서비스
- 일반적으로 SOA예서 정의하는 서비스
- Task centric service → EJB Session Bean
- Data centric service → EJB Entity Bean
5-2 비즈니스 서비스
- Routing
- Transformation
- Functinal adding
- Facade etc
- 채널 시스템
5-3 Process Centric 서비스
- 비즈니스 서비스를 조합(Orchestration)
- 업무 프로세스를 구현
- 상태 정보가 있을 수 있음 (StateFul)
5-4 Application 서비스
- 테크니컬한 기능을 구현한 서비스
5-5 Public Enterprise 서비스
- 타기업이나 외부 시스템으로 서비스를 제공하고자 할 때 정의 됨
- 보안, 과금, 성능 등이 고려됨
6. 서비스의 특징
수직적 분할 애플리케이션을 개발할 때 전체 애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 말합니다. 이전에는 애플리케이션을 각 데이터계층, 비즈니스 계층, 뷰 계층과 같이 수평적으로 분리하였지만 SOA에서는 다음과 같이 각각의 서비스가 데이터 계층, 비즈니스 로직, 뷰에 대한 모듈을 모두 가지고 있고, 각 서비스 간의 의존성이 최소화 됩니다.
7. SOA 아키텍처 모델
SOA는 시스템의 규모와 업무적 요구 사항에 따라 다음 3단계 순서로 발전할 수 있다.
7-1 Fundamental SOA[통합]
- 가장 기본적인 형태의 SOA
- 비즈니스 서비스와 어플리케이션 서비스만 존재
- 서비스들의 조합들은 어플리케이션 Front End에서 이루어짐
- 목적 : 기존의 시스템을 각각 서비스화, 독립되었던
시스템들을 통합하여 하나의 시스템으로 운영
Fundamental SOA의 문제점
-
시스템의 크기가 증가함에 따라 서비스와 서비스, 서비스와 Application Front End단 연결이 매우 복잡 (거미 줄식 P2P연결)
-
시스템의 유연성이 떨어짐
-
관리 및 중앙 통제에 있어서 문제가 발생
7-2 Networked SOA[유연성과 통제 추가]
서비스화하여 통합된 SOA 시스템은 시간이 갈수록 크기가 커지게 되고 서비스 간의 호출 관계는 날이 갈수록 복잡해집니다. 또한 서비스의 내용이 변경 또는 보완되어 의존성에 의해 서비스 간의 수정이 필요한 경우가 발생합니다. 이러한 문제들로 모든 서비스를 하나의 중앙 버스를 통해 관리하여 서비스 간 연결의 복잡도를 해결하고 중재 서비스를 추가 함으로서 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 합니다. 다음의 그림에서 중앙 버스 역할을 하는 것이 Enterprise Service Bus(ESB)이다.
7-3 Process Oriented SOA(프로세스 지향 SOA)[민첩성의 추가]
- 비즈니스 플로우(Business Flow)가 있을 경우에만 적용
- 서비스의 조합을 통한 업무의 구현을 BPM을 이용함
- 업무(기능) 변화에 매우 민첩하게 반은 가능(Agility)
- 기술 조직과 비즈니스 조직간의 의사 소통이 원할 함
8. SOA 아키텍처 구현 시 고려사항
8-1 서비스화
▶ Service Adaptor 고려 기존의 서비스를 손쉽게 웹 서비스화 하기 위해서는 Service Adaptor의 도입을 고려 Ant Task들을 이용한 EJB, POJO의 자동 웹 서비스화 Adaptor를 이용한 Tuxedo, SAP등의 Legacy 자동 웹 서비스화
▶ 서비스 인터페이스 표준 결정 웹 서비스? CORBA? XML/HTTP? → 확장성, 기술 도입 편의성, 호환성 웹 서비스의 경우) 웹 서비스의 확장 규격인 WS*(WS-Transaction, WS-Coordination, WS-Security etc)를 사용할 경우 Service Adaptor별로 지원하는 수준이 다름
8-2 Transaction 처리
▶ 표준 Web Service 스펙으로는 서비스 간 트렌젝션 관리가 불가
▶ 전체 서비스 중 트렌젝션 연계가 필요한 업무는 10%미만
▶ 방안
- WS중 WS-Transaction & WS-Coordination을 통해서 구현 가능→ 아직 솔루션들이에서 완벽하게 지원하지 않음
- EAI를 통한 Transaction이 보장되는 Tightly coupled service 구성
- Compensation Transaction (보장 트렌젝션)등 대한 구현
- 서비스 별 Logging
8-3 보안
▶ 인증과 권한
분산된 서비스에 대한 통합된 사용자 인증과 권한 관리 필요
▶ 암호화
- 암호화 방법(대칭 키, 비대칭 키) 결정
- 암호화 범위 결정 – 전체 메시지를 암호화 할 것인가? 메시지 내용중 중요 데이터만 암호화 할 것인가?
- 암호화 할 내용을 메시지 헤더에 넣을 것인가? Body에 넣을 것인가 ?
##### 8-4 모니터링
▶ 모니터링
- 각 서비스의 성능/용량 데이터 필요 - 서비스들을 조합하여 새로운 업무를 구현하고자 할 때 업무의 수행 시간과 가용 사용자를 예측할 수 있어야 함/ 성능 데이터 수집이 필요
- 서비스 간 연동 시 병목 구간 추적 필요 : 장애 시 병목 구간에 대한 원인 추적 위해
▶로깅
- 어느 수준(단위)까지 로그를 남길 것인가? 업무? 서비스?
- 어디에 로그를 저장할 것인가? 각각 시스템? 중앙 집중형?
##### 8-5 서비스 검색
▶ 서비스를 조합하여 업무를 구현하고자 할 때 서비스를 검색할 수 있어야 함 운영 시 서비스 검색(UDDI)
- 서비스의 위치와 서비스 명세(WSDL)
- 그외 메타 정보(과금, 권한, 보안 규약 etc)
개발 시 서비스 검색 (Enterprise Repository)
- 개발 시에 서비스를 개발이나 수정할 경우, 서비스 구현에 필요한 Resource를 찾을 수 있어야 함
- 분석, 설계 명세, LIB, source code, DB정보
- 서비스 버전 관리
9. SOA의 장점
9-1다양한 클라이언트에게 서비스 가능
SOA는 표준화된 기술(XML, SOAP, WSDL)을 사용하기 때문에 어떤 플랫폼, 프로그래밍 언어 환경, Device에서도 호환성을 가집니다.
9-2 서비스의 재사용이 가능
한번 만들어진 서비스는 컴포넌트화되어 재사용이 가능합니다. 즉, 서비스는 단 하나의 어플리케이션을 위해 만들어지는 것이 아니라 여러 어플리케이션에서 동시에 사용이 가능합니다. 그 이유는 서비스와 클라이언트(서비스 소비함)는 독립되어 있어 서비스가 변경된다고 하더라도 클라이언트에는 아무런 영향을 주지 않기 때문입니다.
9-3 빠른 개발 시간, 적은 비용으로 개발이 가능
이미 제공되고 있는 서비스를 재개발할 필요가 없습니다. 개념적으로 하나의 서비스는 다수의 서비스를 스스로 사용할 수 있고, 이러한 서비스 역시 또 다른 서비스가 가져다가 사용할 수 있는 구조로 이러한 구조를 복합 서비스라고 합니다.
10. SOA의 기대효과
- 통합관리 : 서비스, 프로세스, 어플리케이션 통합관리 용이
- 유연성 : 기술 및 플랫폼 변화에 유연하게 대응
- 민첩성 : Time to Market 신속히 대응
- 협업 강화 : 비즈니스 협업 강화 및 신규 비즈니스 창출
- 생산성 향상 : IT 성능과 생산성 향상
11. SOA의 문제점
- 성공사례부족, 구축비용과다 → 전문인력 양성
- 성능문제, 보안문제 취약 → 성능개선 및 보안강화 방안 연구
- 서비스도출, 방법론 부재 → 체계화된 방법론 및 적용사례 확보
12. SOA의 적용분야
우체국 우편번호 서비스, 기상청 날씨 서비스 등 공공성이 큰 공통적 서비스에 SOA 적용 효과가 큽니다.
13. SOA와 MSA의 차이점
13-1 SOA는 모듈의 의존성을 줄이되 모듈 내에서 공유할 수 있는건 최대한 공유하는 정책을 사용합니다.
반면 , MSA는 가능한 공유하지 않고 모듈들이 독립적으로 운용될 수 있도록 아키텍처를 디자인 합니다.
13-2 SOA는 서비스의 Flow를 유지하려 하지만, MSA는 Flow의 구별을 요구합니다.
서비스 내에서 결제를 하고자 할 때, SOA는 관련된 루틴을 수행하여 결제를 지원함으로서, 유저에게 제공해 주는 ‘서비스’를 1차 목적으로 합니다. 반면, MSA는 유저에게 관련된 륌과 결제 루틴을 별도로 이용하게 합니다. 즉 서비스 내의 독립이 아닌 독립된 서비스를 지향합니다. 따라서 SOA 아키텍처는 대게 어느 정도 엄격한 Protocol과 Message 체계를 운용하게 되고, MSA의 경우 별도의 체계가 없이 경량화된 프로토콜을 통해 운용되게 됩니다.
13-3 SOA는 서비스들의 재사용에 중점을 두지만 MSA는 서비스들의 독립을 추구합니다.
'Metabuild LAB > Dev Study' 카테고리의 다른 글
| Docker 란 ? (0) | 2020.11.26 |
|---|---|
| Spring AMQP (0) | 2020.11.25 |