12/9 MSA 1차시

12/9 MSA 1차시

 

Micro Service Architecture

• 소프트웨어 아키텍처는 소프트웨어를 구성하는 요소와 요소 간의 관계를 정의한 청사진

• 소프트웨어의 전체적인 구성관계인 구성요소와 구성요소간의 포함관계, 호출관계 등을 표현

• 소프트웨어 구성 전체를 조망하고 이해하는 데 유용

• 소프트웨어 설계자, 개발자, 사용자 등 관련된 이해관계자들이 기술 구조를 이해, 소통 도구 역할

 

✔모놀리스 아키텍처

• 모든 업무 로직이 하나의 애플리케이션 형태로 패키지되어 서비스

• 한 곳에 모든 데이터를 참조하여 서비스하는 것이 일반적인 형태

• 비즈니스의 변화가 빠르고 수시로 애플리케이션을 변경해서 적용해야 하는 환경에서 유연하게 대처할 수 없음

• 단일 애플리케이션 중 일부 프로그램만 수정하려고 해도 관련 없는 기능들까지 빌드, 배포해야 함.

                => 새롭게 변화하는 환경에 민첩하게 대응할 수 있는 새로운 아키텍처 대두

 

 

1. 마이크로서비스 아키텍처

• 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성요소간의 관계를 정의한 아키텍처

• 서비스 중심의 아키텍처

• 아키텍처의 구성요소는 서비스와 이를 실행할 수 있게 하는 여러 기술적 환경

 

1. 서비스지향 아키텍처(SOA)

• 대규모 시스템에서 업무 처리 단위를 각각의 서비스로 반영하여 데이터 중심이 아닌 전체 시스템을 서비스 중심으로 설계하는 아키텍처 스타일

• 서비스의 생성과 활용을 높여서 비즈니스 환경 변화와 업무 변화에 민첩하게 대응

**SOA와 마이크로서비스 아키텍처 차이점

• 비즈니스 변화 대응을 위한 서비스중심의 아키텍처라는 점에서 공통점

• SOA는 비즈니스측면에서의 서비스 재사용성을 강조하는 반면, 마이크로 서비스는 한가지 작은 서비스에 집중하기를 강조

• SOA는 많은 서비스의 공유를 위해 서비스 채널을 이용하여 서비스를 공유하고 재사용하는데 초점을 맞춘다면, 마이크로서비스는 각각의 서비스가 독립되어 실행되는 것을 지향

 

 

1. 클라우드 네이티브의 이해

• 클라우드 네이티브(cloud native)는 클라우드 환경에 친화적인 애플리케이션(application), 아키텍처(architecture), 인프라(infrastructure) 등의 환경을 의미

 

            *클라우드 서비스

• IaaS(Infrastructure as a Service)

• 서버를 운영하기 위해 서버자원 IP, Network, Storage 등등 인프라 구축을 제공

• 기존 서버 호스팅보다 H/W 확장성이 좋고 탄력적이며 빠른 제공을 할 수 있는 가상화 기술

• PaaS(Platform as a Service)

• 서비스를 개발할 수 있는 안정적인 환경(Platform)과 그 환경을 이용하는 프로그램을 개발할 수 있는 API까지 제공

• Saas(Software as a Service)

• Cloud 환경에서 동작하는 응용프로그램을 서비스형태로 제공

• 메일서비스, 회원가입서비스 등등

 

 

 

-지속적 통합과 배포(CI : Continuous Integration)

• 지속적 통합은 개발 환경에서 개발 중인 코드를 통합하고 필요에 따라 테스트로 병행 수행하는 일련의 포르세스를 의미

• 지속적 통합을 구성 요소로 통합 서버(CI), 소스관리(SCM), 빌드도구(tool), 테스트도구

• 가장 많이 알려진 빌드 도구로 젠킨스(Jenkins)가 있음

-데브옵스(결정권은 데브옵스에게 주어짐)

• 데브옵스(DevOps)는 애플리케이션과 서비스 개발에서 배포 운영까지 빠르게 제공하기 위한 조직의 협업 문화를 의미

• 마이크로서비스 개발하고 운영하기 위한 팀의 구성과도 매우 밀접한 관계를 가짐

• 개발에서 운영까지를 하나의 파이프라인으로 형성하여 소스코드의 배포가 필요할 때 즉시 반영되는 게 목표

• 가장 이상적인 팀 구성 모델은 서비스의 기획, 설계, 개발, 배포 및 운영까지 서비스 생명주기가 한 팀으로 같은 작업 공간에서 결정되고 수행

 

-컨테이너

• 컨테이너(Container) 의미는 선박에 보다 효율적으로 화물을 수송하기 위해 규격화 된 틀

• 격리된 공간으로 잘 봉인되어 컨테이너 내 물건들이 외부의 환경에 영향을 받지 않음

• 컨테이너 단위의 독립된 공간 단위로 서비스를 패키지 할 수 있으므로 격리된 만큼 필요한 자원을 할당하여 경량화된 서비스를 구성할 수 있음

• 격리된 공간은 다른 서비스에 영향을 주지 않고 자유롭게 배포할 수 있음

• 마이크로서비스는 컨테이너 단위로 묶어서 즉시 필요한 시점에 배포할 수 있는 장점

 

-가상화 & 컨테이너

• 격리된 공간에서 수행되는 프로세스는 다른 공간에서 동작하는 프로세스에 영향을 받지 않음

• 가상화는 하이퍼바이저(Hypervisor)라는 소프트웨어를 이용하여 하나의 시스템에서 여러개의 운영체제를 사용할 수 있게 지원하는 기술

• 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 통해 가상의 격리된 공간을 생성하는 기술

 

• 가상화는 격리된 가상환경으로 호스트 운영체제와는 완전히 분리된 게스트 운영체제를 구성할 수 있는 장점은 있지만, 운영체제설치와 관련 라이브러리 등을 공간별로 할당하고 구성해야 하는 오버헤드가 발생

• 컨테이너는 하이퍼바이저라는 소프트웨어 없이 컨테이너 엔진을 통해 가상의 격리된 공간을 생성

• 호스트 운영체제의 자원을 공유하지만, 프로세스 간의 격리를 통해 가상의 공간에 독립성을 부여하는 방식

• 마이크로서비스와 같이 작은 서비스를 패키지하고 배포하기에는 아주 적절한 기술

 

-도커 컨테이너

• 도커는 애플리케이션 뿐만 아니라 실행에 필요한 시스템 환경을 모아 컨테이너로 관리

• 이렇게 만든 것을 도커 이미지(Docker Image)라고 함

• 도커 이미지로 만든 컨테이너는 도커가 설치된 곳이라면 어디든 똑같이 동작

 

-도커 이미지

• 도커 엔진에서 사용하는 기본 단위

• 도커 컨테이너를 생성하는 요소로 가상머신의 이미지 파일과 비슷하게 이해

• 도커는 애플리케이션과 실행에 필요한 라이버르러, 미들웨어, OS, 네트워크 설정 등 모든 파일을 모아서 도커 이미지를 만듦

• 도커 이미지는 명령어를 이용해 수동으로 생성할 수도 있지만, 자동으로 빌드와 배포를 하는 CI/CD 환경에서 도커 설정 파일(Dockerfile)을 이용해 자동으로 생성할 수 있음

 

 

-도커 컨테이너

• 도커 컨테이너는 도커 이미지를 독립된 공간을 할당하여 실행한 런타임 객체

• 도커 엔진 위에서 기동되며 가상의 IP와 포트, 이름을 가질 수 있음

• 컨테이너 내부로도 접근하여 내부 파일 시스템을 제어 가능

 

-쿠버네티스

• 2014년 구글에서 컨테이너를 관리하는 오픈소스를 발표

• 쿠버네티스는 컨테이너를 대규모로 조율하고 전체 애플리케이션 스택을 관리하는 역할

• 여러 개의 컨테이너, 앤드포인트, 데이터를 애플리케이션 스택과 서비스로 묶어놓은 핵심요소를 제공해 높은 차원의 오케스트레이션 관리를 제공

 

 

-마이크로 서비스

• 마이크로서비스는 소규모의 조직이 독립적으로 개발하고 배포하여 운영할 수 있는 서비스

• 마이크로서비스는 논리적으로 분할할 수 있는 기능들이 분리 구성되어 독립적으로 실행할 수 있는 애플리케이션

 

-마이크로서비스 특징

    ✔작은 서비스

           - 서비스들이 합쳐져 작은 비즈니스가 된다.

           - 작은 서비스를 만들기 위해 크기를 식별하는 기준으로 조직이 맡은 업무의 특성과 경계를 참고

           - 바운디드 콘텍스트(bounded context)는 하나의 서비스에 담을 수 있는 기능들의 그룹이자 서비스 수준의 경계

    ✔독립된 서비스

           - 독립적으로 실행할 수 있고, 다른 서비스들과 결합이 없는 서비스

     ✔응집된 서비스

            - 하나의 서비스는 기능적으로 응집되어야 한다.

            - 해당 기능에만 집중되어야 한다.

     ✔자율적 서비스

            - 서비스를 기획, 개발, 테스트, 배포 및 서비스의 운영까지 담당 조직이 독립적으로 의사결정하고, 서비스에 대한 소유                  권을 가지고 관리되는 서비스

 

 

-마이크로서비스 식별전략

• 도메인, 요구분석, 조직분석

• 마이크로서비스 원칙수립

• 상관분석

• 서비스식별

 

 

ex) 커피주문 서비스

 

 

 ✔설정 서버

• 서비스 프로파일을 관리하는 서버

• 서비스에서 사용할 설정파일은 깃 서버에 저장

• 설정 정보를 xxx.yml이라는 임의의 이름으로 만들고 설정 정보를 기술

 ✔유레카 서버

• 마이크로서비스의 등록과 삭제에 대한 상태 정보를 동적으로 감지하는 역할

• 줄(Zuul), 터빈(Tubine) 등 마이크로서비스와 직접 관련 있는 서비스들에게 유용한 정보 제공

• 유레카 서버는 마이크로서비스가 자신의 정보를 유레카 서버에 등록할 수 있게 서버 주소를 알려주어야 함

• 설정값 중 default : http://localhost:9091/eureka/부분이 마이크로서비스가 참조하는 유레카 서버주소

 ✔줄 서버(Zuul server)

• 줄 서버는 부하 분산 설정과 서비스 라우팅 기능을 수행

• 부하 분산은 동일한 서비스가 여러 서버에 배포되어 있을때 부하를 분산시켜 주는 기능

• 서비스 라우팅은 콘텍스트 패스를 기준으로 마이크로 서비스를 라우팅해 주는 역할

• 외부로 노출된 줄 서버의 REST URL은 http://localhost:9090/이고, 만약 콘텍스트 경로를 /coffeeOrder로 요청하면 줄 서버 설정 값은 path 중 /coffeeOrder에 매핑되어 마이크로 서비스인 ma-service-coffee-order 커피 주문 마이크로서비스로 연결된다.

 ✔터빈 서버

• 마이크로서비스에 설치된 히스트릭스 클라이언트 스트림을 통합해 주는 기능을 제공

• 히스트릭 클라이언트는 스트림은 마이크로서비스로의 서비스 처리 요청에 대한 결과값을 스트림으로 전달

 ✔히스트릭스 대시보드 서버

• 히스트릭 클라이언트에서 생성하는 스트림을 시각화하여 웹 화면에 보여 주는 대시보드 화면 역할

 

 

cloud, docker, Devops + 스프링 기반기본 개발 = MSA 구현 가능