서비스 지향 아키텍처란 무엇인가요?
서비스 지향 아키텍처(SOA)는 서비스라는 소프트웨어 구성 요소를 사용해 비즈니스 애플리케이션을 생성하는 소프트웨어 개발 방식입니다. 각 서비스는 비즈니스 기능을 제공하며, 플랫폼과 언어를 넘나들며 서로 통신할 수 있습니다. 개발자는 SOA를 사용해 서로 다른 시스템 내의 서비스를 재사용하거나 독립적인 여러 서비스를 결합하여 복잡한 태스크를 수행합니다.
예를 들어 조직 내의 여러 비즈니스 프로세스에서 사용자 인증 기능이 필요할 경우, 모든 비즈니스 프로세스에 대해 인증 코드를 재작성하는 대신에 단일 인증 서비스를 생성해서 모든 애플리케이션에 재사용할 수 있습니다. 마찬가지로, 어떤 의료 기관 내에 있는 환자 관리 시스템 및 전자 건강 기록(EHR) 시스템과 같은 거의 모든 시스템에서 환자를 등록해야 하는 경우 해당 시스템들이 하나의 공통 서비스를 호출하여 환자 등록 태스크를 수행할 수 있습니다.
서비스 지향 아키텍처의 이점은 무엇인가요?
서비스 지향 아키텍처는 모든 프로세스가 단일 단위로 실행되는 기존의 모놀리식 아키텍처에 비해 여러 가지 이점이 있습니다. SOA의 몇 가지 주요 이점은 다음과 같습니다.
출시 기간 단축
개발자는 시간과 비용을 절약하기 위해 다양한 비즈니스 프로세스에서 서비스를 재사용합니다. 새로 코드를 작성하고 통합을 수행하는 것보다 SOA를 사용하여 훨씬 빠르게 애플리케이션을 어셈블할 수 있습니다.
효율적인 유지 보수
모놀리식 애플리케이션의 큰 코드 블록보다 작은 서비스를 생성, 업데이트 및 디버그하는 것이 더 쉽습니다. SOA에서 서비스를 수정해도 비즈니스 프로세스의 전체 기능에는 영향이 없습니다.
더 뛰어난 적응성
SOA는 기술 발전에 더 잘 적응합니다. 효율적이고 경제적으로 애플리케이션을 현대화할 수 있습니다. 예를 들어 의료 기관은 최신 클라우드 기반 애플리케이션에서 기존 전자 건강 기록 시스템의 기능을 사용할 수 있습니다.
서비스 지향 아키텍처의 기본 원칙은 무엇인가요?
서비스 지향 아키텍처 구현을 위한 잘 정의된 표준 지침은 없습니다. 그러나 일부 기본 원칙은 모든 SOA 구현에서 공통적입니다.
상호 운용성
SOA의 각 서비스에는 서비스의 기능과 관련 이용 약관을 지정하는 설명 문서가 포함되어 있습니다. 기본 플랫폼이나 프로그래밍 언어에 관계없이 모든 클라이언트 시스템에서 서비스를 실행할 수 있습니다. 예를 들어, 비즈니스 프로세스는 C#과 Python으로 작성된 서비스를 사용할 수 있습니다. 직접적인 상호 작용이 없기 때문에 한 서비스의 변경 사항이 서비스를 사용하는 다른 구성 요소에 영향을 미치지 않습니다.
느슨한 결합
SOA의 서비스는 느슨하게 결합되어야 하며 데이터 모델이나 정보 시스템과 같은 외부 리소스에 대한 종속성이 최대한 낮아야 합니다. 또한 과거 세션이나 트랜잭션의 정보를 유지하지 않는 상태 비저장 서비스여야 합니다. 이렇게 하면 서비스를 수정해도 서비스를 사용하는 클라이언트 애플리케이션과 기타 서비스에 큰 영향이 없습니다.
추상화
SOA의 클라이언트 또는 서비스 사용자는 서비스의 코드 논리 또는 구현 세부 정보를 알 필요가 없습니다. 그들에게 서비스는 블랙박스와 같습니다. 클라이언트는 서비스 계약 및 기타 서비스 설명 문서를 통해 서비스의 정의와 사용 방법에 대한 필수 정보를 얻습니다.
세분화
SOA의 서비스는 서비스당 하나의 개별 비즈니스 기능을 이상적으로 패키징하는 적절한 크기와 범위를
가져야 합니다. 그러면 개발자는 여러 서비스를 사용하여 복잡한 작업을 수행하기 위한 복합 서비스를 만들 수 있습니다.
서비스 지향 아키텍처의 구성 요소는 무엇인가요?
서비스 지향 아키텍처에는 다음과 같은 네 가지 주요 구성 요소가 있습니다.
서비스
서비스는 SOA의 기본 구성 요소입니다. 조직의 내부 사용자만 사용할 수 있는 프라이빗 서비스이거나 인터넷을 통해 누구나 액세스할 수 있는 퍼블릭 서비스일 수 있습니다. 개별적으로 각 서비스에는 세 가지 주요 기능이 있습니다.
서비스 구현
서비스 구현은 사용자 인증 또는 청구서 계산과 같은 특정 서비스 기능을 수행하기 위한 논리를 구축하는 코드입니다.
서비스 공급자
서비스 공급자는 다른 이들이 사용할 수 있는 하나 이상의 서비스를 생성, 유지 및 제공합니다. 조직은 자체 서비스를 생성하거나 타사 서비스 공급업체로부터 서비스를 구매할 수 있습니다.
서비스 소비자
서비스 소비자는 서비스 공급자에게 특정 서비스를 실행하도록 요청합니다. 이는 전체 시스템, 애플리케이션 또는 기타 서비스일 수 있습니다. 서비스 계약은 서비스 공급자와 소비자가 서로 상호 작용할 때 따라야 하는 규칙을 지정합니다. 서비스 공급자와 소비자는 서로 다른 부서, 조직, 심지어 산업에 속할 수 있습니다.
서비스 레지스트리
서비스 레지스트리 또는 서비스 리포지토리는 사용 가능한 서비스의 네트워크에 액세스할 수 있는 디렉터리입니다. 여기에는 서비스 공급자의 서비스 설명 문서가 저장됩니다. 설명 문서에는 서비스에 대한 정보 및 서비스와의 통신 방법이 들어 있습니다. 서비스 소비자는 서비스 레지스트리를 사용하여 필요한 서비스를 쉽게 찾을 수 있습니다.
서비스 지향 아키텍처는 어떻게 작동하나요?
서비스 지향 아키텍처에서 서비스는 독립적으로 작동하고 소비자에게 기능 또는 데이터 교환을 제공합니다. 소비자는 정보를 요청하고 입력 데이터를 서비스에 보냅니다. 서비스는 데이터를 처리하고 태스크를 수행한 다음 응답을 다시 보냅니다. 예를 들어 애플리케이션에서 이 인증 서비스를 사용하는 경우 서비스에 사용자 이름과 암호를 제공합니다. 서비스는 사용자 이름과 암호를 확인하고 적절한 응답을 반환합니다.
통신 프로토콜
서비스는 네트워크를 통한 데이터 전송을 결정하는 설정된 규칙을 사용하여 통신합니다. 이러한 규칙을 통신 프로토콜이라고 합니다. SOA를 구현하기 위한 일부 표준 프로토콜은 다음과 같습니다.
• Simple Object Access Protocol(SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java 메시지 서비스(JMS)
SOA 구현에서 둘 이상의 프로토콜을 사용할 수도 있습니다.
서비스 지향 아키텍처에서 ESB란 무엇인가요?
엔터프라이즈 서비스 버스(ESB)는 여러 서비스가 있는 시스템과 통신할 때 사용할 수 있는 소프트웨어로서, 기술에 관계없이 서비스와 서비스 소비자 간의 통신을 설정합니다.
ESB의 이점
ESB는 재사용 가능한 서비스 인터페이스를 통해 통신 및 변환 기능을 제공합니다. ESB는 서비스 요청을 적절한 서비스로 라우팅하는 중앙 집중식 서비스에 비유할 수 있습니다. 또한 요청을 서비스의 기본 플랫폼 및 프로그래밍 언어에 허용되는 형식으로 변환합니다.
서비스 지향 아키텍처 구현의 한계는 무엇인가요?
제한된 확장성
서비스가 많은 리소스를 공유하고 기능 수행을 위해 조정해야 하는 경우 시스템 확장성이 큰 영향을 받습니다.
상호 종속성 증가
서비스 지향 아키텍처 시스템은 시간 경과에 따라 더 복잡해지고 서비스 간에 여러 상호 종속성을 개발할 수 있습니다. 여러 서비스가 루프에서 서로를 호출하는 경우 서비스 지향 아키텍처 시스템을 수정하거나 디버깅하기 어려울 수 있습니다. 중앙 집중식 데이터베이스와 같은 공유 리소스도 시스템 속도를 저하시킬 수 있습니다.
단일 장애점
ESB를 사용한 SOA 구현의 경우 ESB는 단일 장애점을 생성합니다. ESB는 SOA가 지지하는 탈중앙화 개념에 반대되는 중앙 집중식 서비스입니다. ESB가 중단되면 클라이언트와 서비스는 서로 통신할 수 없습니다.
마이크로서비스란 무엇인가요?
마이크로서비스 아키텍처는 마이크로서비스라는 매우 작고 완전히 독립적인 소프트웨어 구성 요소로 이루어지며, 이들 구성 요소는 하나의 태스크만 전문적으로 처리하고 집중합니다. 마이크로서비스는 다른 소프트웨어 시스템이 마이크로서비스와 통신할 수 있도록 개발자가 만드는 규칙인 API를 통해 통신합니다.
마이크로서비스 아키텍처 스타일은 최신 클라우드 컴퓨팅 환경에 가장 적합합니다. 최신 클라우드 컴퓨팅 환경은 모든 종속 항목과 함께 코드를 패키징하는 독립 소프트웨어 단위인 컨테이너에서 작동합니다.
마이크로서비스의 이점
마이크로서비스는 독립적으로 확장 가능하고 빠르고 이식 가능하며 플랫폼에 구애받지 않습니다. 이는 클라우드 고유의 특성입니다. 또한 마이크로서비스는 분리되어 있습니다. 즉, 다른 마이크로 서비스에 대한 종속성이 없는 것으로 제한됩니다. 이를 위해 마이크로서비스는 다른 시스템도 액세스하고 사용하는 중앙 집중식 데이터에 대한 원격 액세스 대신 필요한 모든 데이터에 대한 로컬 액세스 권한을 갖습니다. 이는 성능과 민첩성 측면에서 마이크로서비스가 보완하는 데이터 중복을 만들어냅니다.
마이크로서비스와 비교한 SOA
마이크로서비스 아키텍처는 SOA 아키텍처 스타일이 발전한 것입니다. 마이크로서비스는 SOA의 단점을 해결하여 소프트웨어가 최신 클라우드 기반 엔터프라이즈 환경과 더 잘 호환되도록 합니다. 데이터 공유와 반대로 마이크로서비스는 세분화되고 데이터 복제를 선호합니다. 이로써 경량 API를 통해 노출되는 자체 통신 프로토콜로 완전한 독립성을 갖추게 됩니다. API를 통해 마이크로서비스를 사용하는 것은 본질적으로 소비자의 작업이므로 중앙 집중식 ESB가 필요하지 않습니다.
AWS는 마이크로서비스 구현을 어떻게 지원하나요?
AWS는 모듈식 아키텍처 패턴, 서버리스 운영 모델 및 민첩한 개발 프로세스로 현대적 애플리케이션을 구축하기에 최적입니다. AWS는 모든 범위와 규모의 최신 애플리케이션을 지원하는 고가용성 마이크로서비스를 구축하기 위한 가장 완벽한 플랫폼을 제공합니다. 예를 들어 다음을 수행할 수 있습니다.
• 관리형 컨테이너에서 보안 마이크로서비스를 구축, 격리 및 실행하여 운영을 단순화하고 관리 오버헤드를 줄입니다.
• AWS Lambda를 사용하여 서버를 프로비저닝 및 관리하지 않고 마이크로서비스를 실행합니다.
• 15개의 관계형 및 비관계형 목적별 AWS 데이터베이스 중에서 선택하여 마이크로서비스 아키텍처를 지원합니다.
• AWS App Mesh를 사용하여 AWS에서 실행 중인 마이크로서비스를 손쉽게 모니터링하고 제어합니다.
• AWS X-Ray와의 복잡한 마이크로서비스 상호 작용을 모니터링하고 문제를 해결합니다.
AWS 기반 마이크로 서비스로 더 빠르게 혁신하고, 위험을 낮추고, 출시를 가속화하고, 총 소유 비용을 줄일 수 있습니다. 지금 AWS 계정을 생성하여 AWS에서 SOA와 마이크로서비스를 시작하세요.
