섹션2에 관해

안녕하세요 "공부하는 이"님

지식 공유자 빌리 리 입니다.

많이 놀라셨을 겁니다. 아마 인프런 서비스 차원에서 AI가 도와준 듯 보입니다.
저의 의지와 상관 없음을 미리 알려드립니다.

아래 내용을 차근 차근 알려드리죠.

1) No better SLAs가 무슨 뜻인지 궁금합니다.
과거 2000년 전후 기점으로 Client/Server 구조가 대세였음은 개발자 입장에서는 이해됩니다. 이를 모니리스 어플리케이션이라고 하죠. 예를 들어 2000년 전, CD/책방 대여하는 프로그램은 사용자 클라이언트 그리고 데이터 관리하는 서버 구조로 되어 있었습니다. 단순히 그 어플리케이션은 오늘날 말하는 "서비스 레벨 동의"로운 것이 아니었다는 말입니다.

"더 낳은 고객 지향 서비스 동의서" (Better SLAs)가 당시 아니었다는 말이죠. 지금은 스프링과 마이크로넛 프레임워크가 있어서 고객 지향 서비스 중심의 어플리케이션을 말하는 것입니다.

============= ~ 2000 년 ======== | ~ 2024년 현재

No Better SLAs | Better Service-Level Agreements

2) 과거에 Server-client 의 구조에서 Monolithic Application으로 넘어간 건가요?

2000년대까지 만해도 클라이언트 사이드 /서버 사이드 구조는 단순했습니다. 이를 모노리틱 어플리케이션이라고 오늘날 명칭하였습니다.

그 이후로는 모노리틱 어플이 아닌 마이크로서비스 지향 중심 어플리케이션으로 발전 되었다는 의미입니다. 질문은 반대로 하신 셈이죠.
Monolitic Application ---> Microservice Application (and Serverless Applications)
============= ~ 2000 년 ======== | ~ 2024년 현재

Clients & Server Architecture (Monolithic Application) | Enterprise-grade web services with Service-Level Agreements (Modern Full-stack framework for testable Microservice

3) SLAs 가 Server-client 구조에 사용되는 거고 Monolithic Application 구조가 SLAs의 문제점을 해결하면서 등장한걸로 이해하면 될까요?

반대로 이해하신 겁니다.

1번 2번을 읽어 이해하셨다면 반대로 이해하신 부분을 공감하실 겁니다. Client-Server 구조가 Monolithic Application 구조이고, SLAs 문제가 있던 겁니다. 이를 대안하여 Microservice Application 구조로 옮긴 거죠.

============= ~ 2000 년 ======== | ~ 2024년 현재

Clients & Server Architecture (Monolithic Application) - No SLAs | SLAs

4) SOA가 서비스 지향 아키텍쳐이고 이것을 구현한 구현체가 SOAP 로 이해하면 될까요?

"SOAP는 SOA(Service-Oriented Architecture)를 구현하는 데 사용될 수 있는 프로토콜 중 하나입니다. SOA는 서비스 지향 아키텍처의 총체적인 개념이고, SOAP는 그 구현 방법 중 하나입니다. "가 맞습니다. 다만 구체적으로

컴퓨터 시스템의 변화 속도는 과거에도, 현재에도, 그리고 앞으로도 압도적입니다. 현대 컴퓨터 시대가 시작된 1945년부터 1985년까지 컴퓨터는 크고 비쌌습니다. 또한, 연결할 방법이 없어서 이 컴퓨터들은 서로 독립적으로 작동했습니다.

그러나 1980년대 중반부터 두 가지 기술 발전이 이러한 상황을 변화시키기 시작했습니다. 첫 번째는 강력한 마이크로프로세서의 개발이었습니다. 초기에는 8비트 기계였지만 곧 16비트, 32비트, 64비트 CPU가 일반화되었습니다. 멀티코어 CPU가 도입되면서 이제는 병렬 처리를 활용하기 위해 프로그램을 적응시키고 개발하는 도전에 직면하고 있습니다. 어쨌든 현재 세대의 기계는 30~40년 전의 메인프레임과 동일한 컴퓨팅 파워를 가지고 있지만 가격은 1/1000 이하입니다.

두 번째 발전은 고속 컴퓨터 네트워크의 발명이었습니다. 로컬 영역 네트워크(LAN)는 건물이나 캠퍼스 내의 수천 대의 기계를 연결하여 소량의 정보를 몇 마이크로초 내에 전송할 수 있게 합니다. 더 많은 양의 데이터는 초당 수십억 비트(bps)의 속도로 기계 간에 이동할 수 있습니다. 광역 네트워크(WAN)는 전 세계 수억 대의 기계를 연결하여 수만에서 수억 bps의 속도로 데이터를 전송할 수 있게 합니다.

강력하고 네트워크화된 기계의 발전과 병행하여, 우리는 컴퓨터 시스템의 소형화도 목격할 수 있었습니다. 아마도 스마트폰이 가장 인상적인 결과일 것입니다. 센서, 많은 메모리, 강력한 CPU를 탑재한 이 장치들은 완전한 컴퓨터입니다. 물론 네트워킹 기능도 갖추고 있습니다. 이와 같은 맥락에서 플러그 컴퓨터와 기타 소위 나노 컴퓨터가 시장에 등장하고 있습니다. 이 작은 컴퓨터들은 종종 전원 어댑터 크기로, 직접 콘센트에 꽂아 사용할 수 있으며 거의 데스크탑 성능을 제공합니다.

이러한 기술의 결과로 이제 많은 네트워크 컴퓨터로 구성된 컴퓨팅 시스템을 구성하는 것이 가능할 뿐만 아니라 쉽습니다. 이 컴퓨터들은 일반적으로 지리적으로 분산되어 있어 분산 시스템을 형성한다고 합니다. 분산 시스템의 크기는 몇 대의 장치에서 수백만 대의 컴퓨터까지 다양할 수 있습니다. 연결 네트워크는 유선, 무선 또는 둘의 조합일 수 있습니다. 또한, 분산 시스템은 컴퓨터가 가입하고 탈퇴할 수 있어 네트워크의 토폴로지와 성능이 거의 지속적으로 변화하는 매우 동적인 경우가 많습니다.

그리하여 SOA 작동 방식이 등장한 것이죠

SOA의 작동 방식

SOA를 이해하기 위해 대학 캠퍼스에서 흔히 볼 수 있는 데이터 지향 시스템을 고려해보세요. 데이터 지향 시스템에서는 캠퍼스 부서들이 배치 파일 전송을 통해 정보를 공유합니다. 예를 들어, 도서관은 자료를 대출하려는 개인이 정규 학생인지 확인하기 위해 학생 기록 부서에 질의할 수 있습니다. UW–매디슨의 경우, 학생 기록 부서는 45,000명의 학생 기록을 배치로 전송합니다. 도서관은 필요한 소수의 학생 데이터를 찾기 위해 이 배치를 시스템 데이터베이스에 로드합니다.
예제 문서
https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1796&context=iatul

연구 회사 Adventure는 대학 부서들이 배치 전송된 데이터를 쉽게 오해할 수 있다고 지적합니다. 이는 부서들이 고유한 요구에 맞게 다른 비즈니스 규칙이나 데이터 버전을 사용하기 때문입니다. 예를 들어, 레크리에이션 시설은 현재 학생을 등록하고 모든 대학 수업료를 납부한 학생으로 정의할 수 있습니다. 반면, 도서관은 현재 학생을 등록했지만 모든 수업료를 납부하지 않은 학생으로 정의할 수 있습니다. 이러한 차이점은 데이터 정확성 문제를 일으키고 정보의 유용성을 최소화할 수 있습니다.

배치 파일 방법이 필요할 수 있는 모든 데이터를 포함한다는 사실은 보안 위험을 증가시키고 이미 과부하된 컴퓨팅 리소스에 큰 부담을 줍니다. 배치 파일 전송은 본질적으로 번거롭고, 시간이 많이 걸리며 오류가 발생하기 쉬운 프로세스입니다. 부서들이 캠퍼스 전역에서 배치 파일을 전송할 때, 서로 다른 "진실의 버전"이 순환하기 시작합니다. 반면, SOA는 서비스 소유자(소스)와 서비스 소비자 간의 서비스 수준 계약에 기반합니다. 두 당사자 간의 거래는 모든 지점에서 추적됩니다.
SOA 해석은 이러합니다.

해석

서비스 지향 아키텍처(SOA)는 컴퓨터 소프트웨어 설계에서 애플리케이션 구성 요소가 네트워크를 통해 통신 프로토콜을 사용하여 다른 구성 요소에 서비스를 제공하는 아키텍처 패턴입니다. 서비스 지향의 원칙은 특정 제품, 공급업체 또는 기술에 의존하지 않습니다. SOA는 다양한 네트워크에서 소프트웨어 구성 요소가 서로 쉽게 작업할 수 있도록 합니다.

SOA 아키텍처에 따라 구축된 웹 서비스는 더 독립적으로 작동합니다. 이러한 웹 서비스는 서로 데이터를 교환할 수 있으며, 기본 원칙에 따라 인간의 개입이나 코드 수정 없이도 상호 작용할 수 있습니다. 이는 네트워크 상의 웹 서비스가 원활하게 상호 작용할 수 있도록 보장합니다.

SOA의 주요 원칙

표준화된 서비스 계약: 서비스는 서비스 설명을 준수합니다. 서비스는 서비스가 무엇인지 설명하는 설명서를 가져야 합니다. 이는 클라이언트 애플리케이션이 서비스가 무엇을 하는지 이해하기 쉽게 만듭니다.
느슨한 결합: 서로 간의 의존성을 최소화합니다. 웹 서비스의 주요 특성 중 하나로, 웹 서비스와 이를 호출하는 클라이언트 간의 의존성을 가능한 한 줄여야 합니다. 따라서 서비스 기능이 변경되더라도 클라이언트 애플리케이션이 중단되지 않아야 합니다.
서비스 추상화: 서비스는 외부 세계로부터 로직을 숨깁니다. 서비스는 기능을 어떻게 실행하는지 노출하지 않고, 클라이언트 애플리케이션에 무엇을 하는지만 알려야 합니다.
서비스 재사용성: 로직은 재사용을 극대화하기 위해 서비스로 나뉩니다. 개발 회사에서는 재사용성이 중요한 주제입니다. 한 번 작성된 웹 서비스 코드는 다양한 애플리케이션 유형에서 작동할 수 있어야 합니다.
서비스 자율성: 서비스는 자신이 캡슐화한 로직을 제어해야 합니다. 서비스는 제공하는 모든 기능을 알고 있으며, 따라서 포함된 코드에 대한 완전한 제어권을 가져야 합니다.
서비스 무상태성: 이상적으로, 서비스는 무상태여야 합니다. 이는 서비스가 한 상태에서 다른 상태로 정보를 유지하지 않아야 함을 의미합니다. 예를 들어, 쇼핑 사이트에서 주문이 이루어질 때, 특정 항목의 가격을 제공하는 웹 서비스가 있을 수 있습니다. 그러나 항목이 장바구니에 추가되고 결제 페이지로 이동할 때, 항목의 가격을 결제 페이지로 전달하는 책임은 웹 서비스가 아닌 웹 애플리케이션에 있어야 합니다.
서비스 발견 가능성: 서비스는 발견될 수 있어야 합니다(일반적으로 서비스 레지스트리에서). UDDI 개념에서 본 것처럼, 웹 서비스에 대한 정보를 보유할 수 있는 레지스트리가 있습니다.
서비스 조합 가능성: 서비스는 큰 문제를 작은 문제로 나눕니다. 애플리케이션의 모든 기능을 하나의 서비스에 포함시키지 말고, 각기 다른 비즈니스 기능을 가진 모듈로 나누어야 합니다.
서비스 상호 운용성: 서비스는 다양한 구독자가 서비스를 사용할 수 있도록 표준을 사용해야 합니다. 웹 서비스에서는 XML과 HTTP를 통한 통신과 같은 표준을 사용하여 이 원칙을 준수합니다.
SOAP 구조 이해

해석

SOAP는 주로 HTTP 요청/응답 모델을 사용합니다. 클라이언트는 메서드 호출을 SOAP/XML로 래핑하여 HTTP를 통해 서버로 전송합니다. 서버는 XML 요청을 파싱하여 메서드 이름과 전달된 매개변수를 읽고 처리합니다. 그런 다음 XML 응답을 클라이언트로 다시 보내며, 여기에는 메서드 호출의 반환 값 또는 오류 데이터가 포함됩니다. 마지막으로 클라이언트는 응답 XML을 파싱하여 반환 값을 사용합니다.
추가 설명
HTTP는 SOAP가 지원하는 유일한 전송 프로토콜이 아닙니다. SOAP 버전 1.1에서는 사양이 확장되어 SMTP(단순 메일 전송 프로토콜), FTP(파일 전송 프로토콜) 또는 텍스트를 전송할 수 있는 기타 프로토콜을 포함한 다른 전송 프로토콜도 지원합니다. 이러한 다른 프로토콜은 비동기 SOAP 호출을 가능하게 하여 클라이언트 애플리케이션이 SOAP 서비스를 호출할 수 있지만 서버의 응답을 기다릴 필요는 없습니다

5) SOAP 의 예시로 WSDL, HTTP, HTTPS 등이 있는건가요?

SOAP(단순 객체 접근 프로토콜)은 분산된 환경에서 구조화된 메시지를 교환하기 위한 표준 프로토콜입니다. SOAP는 인터넷을 통해 메시지를 교환하기 위해 XML을 기반으로 한 프로토콜입니다. SOAP는 송신자와 수신자 간에 교환되는 정보의 메시지 형식과 처리 규칙을 정의하고 설명하는 일련의 규칙을 가지고 있습니다. SOAP는 메시지를 교환하기 위해 두 가지 전송 프로토콜을 사용할 수 있습니다: HTTP(하이퍼텍스트 전송 프로토콜)와 SMTP(단순 메일 전송 프로토콜)입니다. 그러나 SOAP 서비스에서 가장 많이 사용되는 프로토콜은 HTTP입니다.

SOAP 요청 메시지 및 메시지 구조 예시

SOAP 요청 메시지와 메시지 구조는 다음과 같습니다: OST /soap/event HTTP/1.1

Content-Length: 309

SOAPAction: ”getEvent”

Content-Type: text/xml;charset=utf-8

Host: ems-sv258:1774

Connection: Keep-Alive
<?xml version="1.0" ?>

<soapenv:Envelope

    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

    xmlns:xsd="http://www.w3.org/2001/XMLSchema"

    xmlns:ns1="http://soap.com/act">

    <soapenv:Body>

       <ans:getNote xmlns:ans="http://soap.com/act">

          <eventID>1000</eventID>

       </ans:getNote>

    </soapenv:Body>

</soapenv:Envelope>

SOAP 요청 메시지:
- SOAP 액션(SOAPAction): 클라이언트가 메서드 호출을 SOAP/XML로 래핑하여 HTTP를 통해 서버로 전송합니다.
- SOAP 봉투(SOAP Envelope ,이는 선택 사항): SOAP 메시지를 감싸는 구조입니다.
- SOAP 본문(SAP Body): 메서드 이름과 전달된 매개변수를 포함합니다.
SOAP 응답 메시지:
- SOAP 봉투(선택 사항): 응답 메시지를 감싸는 구조입니다.
- SOAP 본문: 메서드 호출의 반환 값 또는 오류 데이터를 포함합니다
  아래 그림을 참고하시면 이해가 빠를 듯 합니다.
  
  SOAP(단순 객체 접근 프로토콜)은 XML을 기반으로 한 메시지 교환 표준을 사용하고, 일반적으로 HTTP를 전송 프로토콜로 사용하기 때문에 서로 다른 운영 체제를 사용하는 애플리케이션 간의 통신이 가능합니다.
  SOAP의 주요 특징
  1. 엄격한 계약:
    - SOAP는 서비스 제공자(서버)와 서비스 소비자(클라이언트) 간의 강한 결합을 특징으로 합니다.
    - 서버와 클라이언트 간에 엄격한 계약이 있으며, 소비자는 서버에 보낼 정확한 메시지 구조를 알아야 합니다.
    - 어느 한쪽에서라도 변경이 발생하면 통신이 중단될 수 있습니다.
  2. WSDL과의 연관성:
    - SOAP는 웹 서비스 설명 언어(WSDL)와 연관되어 있습니다.
    - WSDL은 SOAP 서비스의 설명과 작동 방식을 포함하고 있습니다.
    - 이는 IDE와 프레임워크를 사용하여 WSDL을 기반으로 구현을 자동화할 수 있어 클라이언트 빌딩 프로세스를 쉽게 만듭니다.
  3. 내장된 오류 처리:
    - SOAP는 내장된 오류 처리 기능을 가지고 있습니다.
    - 메시지에 오류가 있거나 필요한 정보가 누락된 경우, 오류 응답 메시지에는 무엇이 잘못되었는지에 대한 정보가 포함됩니다.
    - 이는 서비스 소유자가 아닌 소비자에게 매우 중요합니다. 그렇지 않으면 클라이언트는 요청에 무엇이 잘못되었는지 이해할 수 없습니다.
      참고 내용 : https://jfsmeena.medium.com/soa-soap-rest-api-6fa8a98a71d8

6) WEB 1.0 에서 WSDL같은 SOAP 를 이용하고, WEB 2.0로 넘어가면서 ajax를 사용한건가요?

2010년대 부를 이룬 SOAP 구조는 Ajax를 이용한 SOAP 웹 서비스 호출을 시작한 전성기 였습니다.
아래 블로그 참조해주세요.
https://blog.naver.com/kjjiskjj1/10168968610
시대가 넘어가면서 2000년 이후 2010년까지 유명한 웹 어플리케이션에서 사용된 서비스 아키텩처는 Ajax를 사용하여 비동기식 XML 메시지 유형을 사용합니다. SOAP 서비스는 웹 서비스를 자바스크립트로 구성된 라이브러리를 사용했다고 하니 질문한 대답은 이를 이해하지 못한 내용에서 출발한 겁니다.

곧 WEB 1.0 에서 WSDL같은 SOAP 를 이용하고, WEB 2.0로 넘어가면서 ajax를 사용한 것이 아니라 SOAP 안에 자바스크립트가 녹아 있었고 다만 ajax가 웹 개발자들 사이에 XML 방식을 접목시킨 것뿐이죠. 제가 2000년도 개발할 때 자바 스크립트는 웹 브라우저와 호환하여 클라이언트 UI 조정 및 구현하는 단계로 작성한 것이 이제 자바스크립트 라이브러리화 되어 누구나 쉽게 사용하게 되고, 그 안에서 유사한 구조인 Ajax 역시 라이브러리화되어 HTTP 프로토콜 내에서 자유롭게 라이브러리되어 개발자는 손쉽게 사용되어졌다고 생각하시면 됩니다.

7) SOA, WEB1.0, WEB2.0 등의 개념은 server-side 개념이 아니라 Monolithic Application 구조에서 사용되는건가요?

정답은 아닙니다. 또한 반대로 이해하신 겁니다. 물론 AI가 대답한 내용은 다음과 같이 맞다고 생각됩니다. "AJAX는 주로 웹 2.0 시대에 등장한 비동기 JavaScript와 XML/JSON을 이용한 기술이며, SOAP와는 다른 목적의 기술입니다."
다만 시대적 착오로서 시대별로 진화한 내용보다는 다음 같죠..

시대가 변하면서 Server-side 개념은 여전히 존재합니다. 마치 2000년 전에는 프론트앤드 및 백엔드 개발자를 나누지 않고 모두 알아서 프론트부터 백엔드까지 개발에 참여했죠.

시대가 변하면서 2010년 이후 점차 클라이언트 개발자 곧 프론트앤드 개발자 & 서버 개발자 곧 백엔드 개발자로 나뉘어 개발한 개발자 개념 범위를 나눈 것뿐입니다.

Monolithic Application에서 이제 Microservices Architecture로 넘어가면서 클라이언트 서버를 안고 개발자가 개발하는 모노리틱 관점이 아닌 서비스를 잘게 쪼개어 마이크로 세부적인 서비스로 나뉘어 개발한다는 것으로 이해하셨으면 합니다.

다시 말씀드려 Monolithic Application 구조에서 사용된 개발자들의 이해도는 이제 마이크로서비스 지향적인 개념으로 이해를 하면서 개발해야 한다는 것이죠.

8) Monolithic Application에서 Microservices Architecture 넘어간 이유가 분산처리, 확장성이 더 좋기 때문이죠?
대답은 반반입니다. Microservices Architecture는 분산처리와 확장성이 더 좋고, 독립적인 배포와 유지보수가 용이하기 때문에 Monolithic Application의 대안으로 많이 채택되는 것인 맞습니다. 다만 질문처럼 Microservices Architecture 로 넘어간 이유가 그 구조가 단순 분산처리 확장성이 좋아서 그런 것이 아니라 시대가 빅데이터 시대로 점차 변화하면서 데이터가 서비스 중심으로 바뀌고 있기 때문입니다. 소셜 사이트는 개발자 중심이 아니라 고객서비스지향 중심으로 개발되어 UI 인터페이스 프로토콜이 바뀌었기 때문에 그 아키텩처가 변화 및 진전되어 발전되니 Monolithic Application는 고물덩어리가 된 것입니다. 이 소셜 네트워크 중심의 에어비엔비나 페이스북처럼 고객이 직접 수 만건의 고객 정보 (빅데이터)를 매일 올리면서 생기는 병목 현상과 유지보수에 Monolithic Application 아키텍쳐는 쓸모없는 아키텩처가 되니 당연히 SLAs 지향성은 아니었습니다 그러니 SLAs 곧 서비스 지향 SOA/SOAP/AJAX 같은 프로토콜이 스탠다드 프로토콜로 그 자리를 물려준 셈이죠.

그리하여 웹 1.0세대에서 2.0 세대 지금은 3.0 세대에 웹은 Asynchronous JavaScript And XML로 이동한 것입니다. 제 강의 일부 내용 중 말하는 것처럼 "중앙집중형 모노리스틱 어플리케이션에서 인스턴스 방식의 독립적인 서비스로 변모한 마이크로서비스 아키텍쳐"로 자동으로 변한 겁니다. 고객을 충족시키려면 개발자가 고객이 되고, 고객 또한 개발자가 되니 커다란 빅 데이터를 분산처리할 수 밖에 없고, 확장성이 거대해질 수 밖에 없죠. 우버, 에이비엔비, 넥플릭스도 그에 버금가야 기업은 살아 남게 됩니다. 최고속 처리 아키텩처 디자인은 이러한 관점에서 빠르게 혹은 천천히 진화한 겁니다. HTTP를 사용하여 데이터를 텍스트 중심으로 서로 상호작용을 빠르게 데이터를 전송하고 가공, 원하는 형태로 변경할 수 밖에 없답니다. 복잡성은 더욱 거대하여 개발자들은 더욱 이러한 내용을 알고 개발해야 합니다. 마이크로 서비스 중심의 개발자만이 지금 살아남습니다. 유념하시길 기대합니다.

9) 마지막으로 SOA가 서비스 지향 아키텍처라는 의미인데 그 시절에 서비스 지향 아키텍쳐라고 불릴만큼 큰 이유가 있나요? SOA 가 그 당시 어떤 문제나 환경으로 생겨난 건지 궁금합니다.

9번의 대답은 바로 8번 대답 속에 녹아 있으니 참고하여 주세요. 다시 소개 부분을 들으시면 이제 이해할 수 있을 겁니다. 감사합니다. 제 강의를 들어주시고, 이제 서비스 지향 중심의 개발자로 모노리틱 아키에서 마이크로 아키텍쳐로 남기를 기대합니다. 혹은 그런 개발 리드자로 남기를 기대합니다. 읽어주셔서 감사해요....

빌리 올림

인프런 커뮤니티 질문&답변

SOA의 주요 원칙

추가 설명

SOAP 요청 메시지 및 메시지 구조 예시

SOAP의 주요 특징