ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 클라우드 마이크로 서비스 - 소프트웨어 아키텍쳐,Cloud Native Architecture
    Infra/클라우드 2023. 12. 8. 11:21

    Software Architecture

    Atifragile

    1. Auto scaling

    Auto scaling 시스템을 구성하고 있는 인스턴스를 하나의 Auto Scaling group으로 묶은 다음 그룹에서 유지 되어야 하는 최소 인스턴스를 지정할 수 있다.(최소 규모) 더불어 사용량에 따라 자동으로 인스터스를 증가 할 수 있는 환경을 의미한다.

     

    서비스에 특수한 이벤트가 있는 기간에는  서버의 운영개수(인스턴스)를 늘리고, 비수기에는 서버의 운영 개수를 줄인다.  Auto scaling을 활용하면 이런 작업이 관리자 또는 운영자에 의해 수동으로 설정되는 것이 아니라 CPU,메모리,네트워크,데이터베이스 사용량이나 조건에 따라서 자동으로 처리 할수 있다.

     

     

    2. Microservices

     

    위 그림은 Netflix의 온라인 서비스 구성도 이다.복잡하게 연결되어 있는 서비스 구성이 바로 Microservices이다. 파란색 선은 서비스간의 연동이나 통신을 의미하고, 초록색은 넷플릭스라는 전체 서비스를 구축하고 있는 각각의 마이크로 서비스를 나타낸다.

     

    넷플릭스와 아마존은 클라우드 서비스를 가장 잘 구축하고 활용하고 있는 기업이다. 본 게시글에서 사용하려는 많은 부분이 넷플릭스에서 개발되었고 스프링 재단으로 기부된 것만 보더라도 넷플릭스라는 기업 얼마나 클라우드 서비스에 적극적이 였는 지를 알수 있다.

     

    마이크로 서비스는 클라우드 네이티브 아키텍쳐, 클라우드 네이티브 어플리케이션에 핵심이라고 볼 수 있다. 기존 시스템들이 하나의 거대한 형태로 구축되어서 서비스 되었다고 하면 마이크로 서비스는 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발하고 배포하고 운영할 수 있도록 세분화 된 서비스이다.

     

     

    3.Chaos engineering

     

    • 변동
    • 예견된 불확실성
    • 예견되지 않는 불확실성
    • 카오스 불확실성

     

    chaos engineering이란 시스템이 예측하지 못한 상황에 놓인다고 하더라도 견딜 수 있게 하는 것이다. 즉 운영중인 소프트웨어에 실행중인 방법이라던 규칙이라고 일환이다. 시스템의 변동이나 이견 예견되거나 예견되지 못한 불확실성에 모두에 대해 안정적인 서비스를 제공할 수 있도록 구축 되어야 한다는것을 의미하기도 한다.

     

     

    4.Continuous deployments

     

     

    CI/CD는 지속적인 통합 지속적인 배포라는 것으로 해석할 수 있다. 클라우드 네이티브 어플리케이션은 적게는 수십개 많게는 수백개 이상 마이크로 서비스로 도메인이 분리되어 개발되는 경우가 일반적이다. 하나의 어플리케이션을 구성하는 수십 수백개의 서비스들을 일일히 test한뒤에 build하고 최종적으로 운영환경에 deploy하는 등의 작업을 수동으로 한다고 가정하면 시스템 자체의 복잡성을 떠나서 이일련의 과정이 하나의 커다란 업무이자 작업의 로드가 심하게 걸리는 부분이 되어 버릴 수도 있다.

     

    그래서 이러한 수십 수백개의 마이크로 서비스를 빌드하고 배포함에 있어서 자동화된 시스템을 구축하고 하나의 작업에 다른 작업으로 연계되는 과정을 파이프라인으로 연결시켜 놓게되면 시스템의 작은 변화를 줄때 뿐만 아니라 전적인 업그레이드 작업에서도 빠르게 적용할 수 있다.

     

    CI/CD라는 개념은 클라우드 네이티브나 마이크로 서비스에서만 새롭게 사용된 개념이 아니라 이전부터 시스템의 통합적인 관리와 운영을 위해 사용된 시스템이다. 클라우드 네이티브의 마이크로 서비스가 활발히 사용되는 이 시점에 더 빠질 수 없는 필수적이 기술이 되었다.

     

    Cloud Native Architecture

    확장 가능한 아키텍쳐

    • 시스템의 수평적 확장에 유연
    • 확장된 서버로 시스템의 부하 분산, 가용성 보장
    • 시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지)
    • 모니터링

    시스템은 필요에 따라서 확장 가능한 형태의 아키텍쳐로 발전 되었다. 특히 시스템의 수평적 확장으로 인해 더 많은 사용자의 요청을 처리할 수 있게 되었고, 이렇게 확장된 시스템으로 인해 시스템 부하를 분산시킴과 동시에 가용성을 보장할 수 있게 되었다. 

     

    🖥️시스템 확장

    • scale - up : 하드웨어의 사양을 높이는 작업으로 시스템에 CPU나 메모리의 스펙을 높이는 작업 (질적 개선)
    • scale - out : 같은 상야의 서버 즉 인스턴스를 여러 개 배치함으로 동시에 더 많은 사용자의 요청을 처리하 수 있도록 하는 것 (양적 확장) 

    일반적으로 시스템을 스케일 아웃 하기 위해서는 하드웨어 비용이 증가하게 되겠지만 클라우드 네이티브 아키텍쳐에서는 클라우드 서비스를  제공하는 업체로 부터 가상의 서버, 가상의 스토리지, 가상의 네트워크 등을 빌려서 사용함으로써 이러한 비용을 최소화 시켰고, 양적으로 증가되었던 시스템을 더 이상 사용하지 않을 경우에는 다시 빌렸던 리소스를 반납해서 비용 낮출 수 있게 되었다. 

     

    따라서 클라우드 네이티브에서는 가상 서버의 기술이 핵심적으로 필요하게 되었다. 기존의 서버 가상화 방시과 더불어서 컨테이너 방식의 가상화를 같이 사용하게 되었다. 또한 클라우드 네이티브에 구축된 가상 서버와 리소스들은 다양한 모니터링 도구를 이용해서 현재 사용되고 있는 시스템의 상황 및 리소스의 사용량 등을 확인할 수도 있다.

     

     

    탄력적 아키텍쳐

    • 서비스 생성 - 통합 - 배포, 비지니스 환경 변화에 대응 시간 단축 
    • 분활 된 서비스 구조
    • 무상태 통신 프로토콜
    • 서비스 추가와 삭제 자동으로 감지
    • 변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리)

    두 번째로 클라우드 네이티브 아키텍쳐는 탄력적인 아키텍처를 갖고 있다. 어플리케이션을 구성하는 각 기능을 한의 분리된 서비스로 개발을 하고 이렇게 분리되어 개발된 서비스들을 통합하고 배포하기까지 걸리는 시간을 CI/CD라는 자동화 파이프라인을 통해서 처리함으로 써 변경이 시스템 환경에 적용되는 시간을 단축 할수 있게 되었다. 

     

    엔터프라이즈 어플리케이션으로 갈 수록 개발인력의 증가 뿐만 아니라 수 많은 개발 환경, 테스트 환경, 심지어는 실제 운영 환경들을 예비서버를 고려해서 준비해야 한다. 예비 서버는 적게는 3~4개  많게는 수십개에서 수백개 일 수 있다. 이렇게 무수히 많은 예시 서버에 같은 내용의 서비스를 배포하는 과정이 자동화 되어 있지 않다면, 수많은 인력이 낭비될 것이다.  

     

    마이크로 서비스는 작게 분리된 독립적인 서비스 이다. 전제 어플리 케이션을 구성하고 있는 도메인 특성에 따라 각 서비스 간의 경계를 잘 구분하고 거기에 맞게 서비스를 개발해야 한다. 서로 분리된 서비스 간에 원활한 통신을 위해 각각의 서비스들이 서로에게 가지는 종속성을 최소화 시켜야 한다. 또 상태를 갖지 않는 서비스를 제공할려고 노력해야 한다.

     

    전체 어플리케이션을 구축하는 마이크로 서비스들은 배포될 때 자신들의 위치가 어디에 있는지 등록을 해야 된다. 그래야 다른 서비스들이나 외부에 연결되어 있는 타 시스템에서도 해당 서비스를 검색하고 사용할 수 있게 된다. 이렇게 마이크로 서비스들의 존재는 Discovery Service라는 곳에 등록되고, 삭제되는 작업을 하게 된다. 

     

     

    장애 격리(Fault isolation)

    • 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않는다. 

    마지막으로 클라우드 네이티브 아키텍쳐는 장애복구에 뛰어나다느 특징을 가지고 있다. 여러 개로 분리되어 개발되고 있는 마이크로 서비스들은 하나의 독립적인 작은 단위의 어플리케이션과 같다. 따라서 하나의 마이크로 서비에 생기는 문제점이나 오류사항은 다른 쪽 서비스로 영향을 최소화 해야 한다. 어떤 마이크로 서비스에 특정부분을 수정한다 하더라도 전체 서비스를 다시 배포해야 되는 것이 아니라 해당 서비스에만 다시 배포하기 때문에 다른 시스템에 영향을 주지 않을 수 있다. 

     

     

     

    [출처 - Spring Cloud로 개발하는 마이크로 서비스 애플리케이션, 저 Dowon Lee]

    https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

     

    Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

    Spring framework의 Spring Cloud 제품군을 이용하여 마이크로서비스 애플리케이션을 개발해 보는 과정입니다. Cloud Native Application으로써의 Spring Cloud를 어떻게 사용하는지, 구성을 어떻게 하는지에 대해

    www.inflearn.com

     

    댓글

Designed by Tistory.