• 예전에 UNIX였음
  • RPC
  • Remote Procedure Call
  • 이것을 기반으로 Distribute Architecture 설계
• 클라이언트 서버
  • 혹은 Consumer - Provider
  • 원격으로 떨어져 있다.

Distrubte system 서비스 절차

1. 사용자는 서비스가 어디있는지 알아야하므로 광고해야 함(인터넷에)
2. 여러개의 서비스를 카테고리화해서 제공
   • 이 각 서비스들을 registry라고 표현
   • 프록시에서 필요한 서비스 처리하도록 함
3. 사용자는 해당되는 서비스를 찾고 받음(인터넷에서)
4. 이후 클라언트와 서버에서 요청 응답 수행

• 여기서 서버와 클라이언트는 서로를 알아선 안됨

  • 그래서 클라이언트와 서버 모두 프록시를 통해 요청하고 응답을 받을 수 있음
    • 그냥 프록시랑 리버스 프록시

• Distribute 환경에서는 Robust해야 함

  • 원격에서 서비스를 사용하기 위해서는 여러가지 복잡한 기술들이 사용됨
  • 그러므로 견고한 시스템이 필요하다

• Main frame 시기에서는 절차적인 언어만 가지고도 충분히 개발 기간이 길고, 오래 사용되었으므로 뭐 크게 상관없었음.

• 근데 Distribute가 되면서, 사람들이 여러 서비스를 이용할 수 있게 되면서 개발 기간도 짧아지고, 필요한 서비스들도 많아져서 빠르게 업데이트가 필요됨

  • 그래서 재사용성의 필요성이 대두
  • 절차지향적인 개발로는 이를 만족시킬 수가 없었음

• 원격에서는 Object를 어떻게 주고받아야하는가?

  • Object를 통으로 주고받을 수는 없다
  • 그래서 DTO의 경우 Serializable 을 써서 주고받았음.
  • 서버의 프록시에서 직렬화 해주면 클라이언트의 프록시에서 역직렬화해서 사용한다던가 하는 식

• 서로 다른 언어, 서로 다른 플랫폼에서는 그럼 어떻게?

  • 여기서 Markup 언어인 XML을 사용하기 시작
    • JSON을 썼으면 좋았을텐데..

• 2010년대부터 시작해서 인프라, 데이터의 변화가 발생

  • 이전에는 무결성이 중요했음.
  • 저장 공간이 부족했기때문에 중복을 없앴어야 함
  • 하지만 이제 메모리나 하드 용량이 매우 커짐.
  • 그래서 빠르게 처리하는 것이 중요해졌고, 무결성을 위배하는 것이 나은 경우가 생김
  • 그래서 NoSQL등이 많이 필요해졌음
  • 여기서부터 필요해진 특성

    • Anti-fragile

      • Auto-scaling
        • 해당 서비스를 자동으로 늘리고 줄이는 것들을 해줘야 함
      • Microservices
        • 가장 작은 서비스 단위로 쪼개는 것
        • SOA를 모놀리틱하게 한번에 다 구축하는 것이 아니라 서비스단으로 쪼개는 것
        • REST, Stateless
          • Stateless로 인해 인증 방법에 대한 고안이 필요해짐
          • Tx가 정확하게 지켜지지 못함
            • 해당되는 트랜잭션을 위해 무엇을 해야하는가
            • 카프카같은 Messaging Service를 이용해서 트랜잭션을 event driven으로 처리하기 시작
              • CQRS같은 것들
      • Chaos engineering
        • 여러 서비스가 통신하고 작용해야하므로 매우 복잡해서 카오스 엔지니어링이 됨
        • 하나가 죽더라도 다른 서비스에 영향을 덜미침
        • 서비스 추가하기도 쉬워짐
      • Continuous Deployments
        • CI/CD
        • 위 작업이 가능하려면 지속적으로 배포 자동화가 일어나야 함
        • 클라우드에 분산된 여러 서비스를 자동관리해줘야 함

    • Resilient

      • 이게 위에서 말한 무결성 위배하고 빠르게 처리하는 측면에 해당

    • Cloud Native - 방법론

      • Iaas(Infrastructre as a service)
      • Paas(platform as a service)
      • Saas(Software as a service)
      • Faas(Function as a service)
      • Cloud Native Application을 만들기 위한 방법론에 대해 공부해야 함
        • 기술문서 제공블로그들 매우 많음
          • 개발할때는 스펙, 기술을 제공해주는 도큐먼트를 가장 먼저 보고
          • 면접을 준비할 때는 기술 블로그를 보면서 모니터링하는 것이 도움이 됨
          • Cloud Native Application에 대한 관리, 설명이 잘 나와 있음
      • 이 Cloud Native가 시작되면서 독립적 기능 중심의 Component Based Development가 Service Oriented Architecture로 옮겨가기 시작한다.
      • 실제로 해당되는 Service Oriented Architecture의 초창기 표준으로
        • 이거 잘 이해 안됨
        • 프록시에 서비스를 등록하는 WSDL이라는 XML 표준이 있었음
        • Registry를 인터넷이라는 공간에 XML로 정의하는 UDDI라는 표준이 있었음.
        • WSDL을 받아서 서비스를 요청하면 HTTP 프로토콜에서는 SOAP이라는 XML 기반의 프로토콜 바디에 통신
        • 위와 같은 과정을 거쳐 해당하는 서비스가 인터넷에서 여러 벤더들에 의해 제공됨
      • UDDI 레지스트리를 제공해주는 곳
        • 대표적으로 IBM, MS가 있음
        • 여기서 서비스를 제공해주면 이것을 가져다 쓰는 형식으로 사용
        • 모놀리틱함
      • 근데 클라우드 형태로 발전이 되면서
        • XML 기반의 표준은 파싱 어렵다
        • REST형태로 통신을 시작
          • XML 기반으로 구현하기가 어려우니까 REST형태로 SOA를 구현하자! 라고 함

    • 서비스를 모놀리틱하게 했을때는 스케일 업밖에 방법이 없었음

    • 근데 1년중 한달만 사용자가 많고 나머지의 경우 거의 없다고 하면?

    • 근데 클라우드를 쓰면 쓴만큼만 내면 됨

    • Anti-Fragile을 만족시키려면