웹 서비스 아키텍처

Ginie·2021년 8월 25일

프로그래밍 기초

목록 보기

9/11

나는 원래 한 단어라도 이해가 안되면 전체가 이해가 안된다 그러니까 하나씩 뜯어보도록 하자. 물론 한 번 한다고 갑자기 없던 컴공 지식이 들어올리는 없다. 좋은 사이트를 발견했으니 천천히 해보자.

Architecture

사전적 의미 : 컴퓨터를 기능면에서 본 구성 방식. 기억 장치의 번지 방식, 입출력 장치의 구성 방식 등을 가리킴. 일반적으로 같은 아키텍처의 컴퓨터에는 소프트웨어의 호환성(互換性)이 있음.

아키텍처는 구조, 계획, 기준, 규칙 또는 설계 결과물을 뜻한다.
어디에 쓰냐에 따라 의미가 조금씩 달라지는 것 같지만... (구글링 한 결과 명확하게 아키텍처란 무엇이다! 라고 나오는게 아니라 ooo아키텍처 이렇게 앞에 단어가 더 붙은 상태로 단어 정의를 내리더라.)

웹 서비스가 동작하는 방식은 간단하다.

클라이언트 <--> 인터넷 <--> 서버 (request, response의 반복)

웹 서비스의 유형은 크게 두 가지가 있다.

SOAP (Simple Object Access Protocol)

컴퓨터 네트워크에서 웹 서비스를 구현할 때 구조화된 정보(XML 기반의 메시지)를 교환하기 위한 MS사의 메세징 프로토콜.
XML과 HTTP 통신을 기반으로 하여 네트워크상에 존재하는 각종 컴포넌트 간 호출을 효율적으로 실현 하기 위한 방법을 제시하는 규약.
네트워크상에서 Client와 Service 간에 메시지를 요청하고 이에 응답해주는 방법을 제공.

특징

주로 원격 프로시져 호출(Remote Procedure Call:RPC) 패턴을 사용한다.
웹서비스의 메세지를 전달하는 기본적인 기반
표준 공개성 : W3C의 표준 메시지 포맷으로 다중 환경에서 상호 운영 가능
유연성 : XML기반의 확장성으로 표준을 유연하게 통합/운영 가능
확장성 : HTTP 이용으로 인터넷에서 사용 가능하며 프록시와 방화벽 제약 극복 분산 컴퓨팅 분산된 환경에서의 원격 프로시저 호출, 데이터 전송 가능
독립성 : 특정 언어, OS, 플랫폼, 전송프로토콜에 독립적 저용량 미들웨어 텍스트 처리 프로세스와 메모리, 웹서버만으로 미들웨어 구성

클라이언트 --메세지 요청--> 서버 --메세지 응답--> 클라이언트

장점

프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
플랫폼과 프로그래밍 언어에 독립적. (독립성)
웹 서비스를 하기 위한 표준이 잘 정립되어 있음.
에러 처리에 대한 내용이 기본적으로 내장 되어 있음.
다른 트랜스포트 프로토콜 사용을 허용함. 융통성이 있다. (중립성)

단점

복잡한 구조로 오버헤드 발생, 이것은 SOAP의 확장을 저해함.
REST에 비해 느리고 무거움.
개발 난이도 上, 개발 환경의 지원 필요.

SOAP의 아키텍처

UDDI (Universal Description, Discovery and Integration : 전역 비지니스 레지스트리, 웹 서비스를 등록하고 검색하기 위한 저장소, 웹 서비스 전용 검색엔진) 통해서 등록(Publish), 검색(Find)하고 바인딩(Bind)하여 사용.

동작

[ 서비스 요청자 ]
메세지를 SOAP로 인코딩 후 요청

	요청(request) ↓ ↑ 응답(response)

SOAP 메세지를 디코딩 후 서비스 로직을 수행해서 결과를 얻는다.
다시 SOAP로 인코딩해서 응답.
[ 서비스 제공자 ]

※ 이때 메세지는 선택적 Header와 필수 Body를 포함함!

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope" 
                     soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
   <!--모든 SOAP 메시지의 루트 요소, 선택적 Header 요소와 필수 Body 요소 포함-->
  <soap:Header>
        <!--메시지 경로를 따라 SOAP 노드로만 처리될 애플리케이션 관련 정보를 전달하는 데 사용-->
  </soap:Header>
  <soap:Body>
       <!--필수 요소, 최종적으로 메세지를 받는 사람 정보를 기재-->
    <soap:Fault>
       <!--오류 보고에 사용-->
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

메세지를 XML 형식으로 보내는 방식
⭕ 장점
XML은 다양한 툴이 존재함, 사람이 읽기 쉽다.
❌ 단점
문법이 다소 길다. 불필요한 정보가 많아 처리 시간이 늦어질 수 있다.

reference 위키피디아, guru99

REST(Representational State Transfer)

분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 형식중 하나.
엄격한 의미로는 REST는 네트워크 아키텍처의 원리 (자원을 정의하고, 자원 주소를 지정하는 방법 전반) 모음이다.
웹상의 자료를 별도의 전송계층 없이 전송하기 위한 간단한 인터페이스.
HTTP 프로토콜로 데이터를 전달하는 프레임 워크.
REST 원리를 따르는 시스템을 RESTful이라고 함.

특징

리소스(resource : 웹에서 개방된 모든 자원을 의미) 라는 핵심 요소를 가짐.
모든 리소스는 균일하고 최소한의 명령 집합을 사용해 고유한 url을 지정할 수 있으며, HTTP의 기본 메소드 GET / PUT / POST / DELETE 만으로 접근 가능.
상태와 기능을 분산리소스로 나눔.
프로토콜은 클라이언트/서버, 상태 비저장, 계층화 밑 캐싱을 지원함.
무상태성

장점

클라이언트/서버 간의 구성 요소를 엄격히 분리하여 구현은 단순하게, 확장성과 성능은 UP ↑. (Client - Server 구조)
HTTP 프로토콜의 인프라를 그대로 사용해서 REST API 사용을 위한 별도 인프라 구축할 필요 없음. (Cacheable)
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능.
Hypermedia API의 기본을 지키며, 범용성을 보장.
REST API 메시지가 의도하는 바를 명확하게 나타내서 의도를 쉽게 파악함. (Self-descriptiveness)
여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화 할 수 있음.

단점

표준이 존재하지 않아 정의가 필요.
사용할 수 있는 메소드 GET / PUT / POST / DELETE 밖에 없고, HTTP Method 형태가 제한적.
브라우저를 통해 테스트할 일이 많은 서비스라면 Header 정보의 값을 처리해야 하므로 전문성이 요구됨.
익스플로어 호환 X, 지원해주지 못하는 동작 多.

HTTP 메소드

POST : 현재 Collection 보다 한 단계 아래의 Document 생성
GET : 현재 Collection, Document 를 조회
PUT : 현재 Document 의 정보 수정 (해당 자원의 전체를 수정)
DELETE : 현재 Document 를 삭제
PATCH : 현재 Document 를 수정 (해당 자원의 일부를 수정)