[MSA] MSA알아보기- 1

hanana·2023년 10월 16일
0

본 포스팅은 인프런 Dowon Lee님의
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의를 토대로 작성되었습니다.

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

IT시스템의 발전역사

  • 1960 ~ 1980s : Fragil
    Mainframe 시기
    Software보다는 Hardware가 중요시되었던 시기.
    하드웨어의 사양이나 성격에 맞춰서 서비스를 개발.
    하드웨어나 및 시스템 자체가 상당히 고가였기 때문에변경이나 수정이 상당히 어려웠고
    깨지기 쉬운 시스템이라는 특징이 있음.

  • 1990 ~ 2000s Robust, Distributed
    이 시기부터 시스템이 안정화 되었고, 분산화된 시스템 덕분에
    서비스에 변화가 발생한다 하여도 안정성 있고 고성능을 유지할 수 있게 되었다.

  • 2010s ~ Resilient / Anti-fragile, CloudNative
    시스템은 점차 클라우드에서 의존되었으며 확정성과 안정성이 더욱 개선되었으며
    지속적인 변경 및 개선사항이 생기더라도 시스템이 탄력적으로 운영 될 수 있게 되었다.

AntiFragile

안티티티티 프레젤
직역하면 Anti + 깨지기 쉬운단어로

안티프레젤은 네가지 핵심적인 특징이 있다.

1. Auto scaling
자동 확장성이라는 말로 시스템을 구성하고 있는 인스턴스를 하나의 ScalingGroup으로 묶은 후
사용량에 따라 인스터스를 증가 시킬수 있는 환경을 의미함.

2. MicroServices
하나의 거대한 서비스로 구축된 기존 시스템과 달리
MicroService는 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을
독립적으로 개발/배포/운영할 수 있도록 세분화된 서비스이다.

3. ChaosEngineering
카오스엔지니어링 이란,
시스템이 예상하지 못한 급격한 상황이라도 견딜 수 있어야 한다는 말로
변동되거나 불확실성에 대해서도 안정적으로 서비스를 제공할 수 있어야 한다는 뜻이다.

4. Continuos deployments
CI/CD. 지속적인 통합/지속적인 배포라는 의미로
Cloud Native Architecture는 도메인별로 서비스가 분리되어 있으므로
하나의 애플리케이션을 구성하는 수많은 서비스들을 일일히 수동으로 빌드하고 배포하는 과정은 매우 귀찮은 일일 것이다.
이러한 과정을 파이프라인으로 연결하여 편리하게 일련의 작업이 가능해진다.


Cloud Native Architecture

Cloud Native Architecture는 다음과 같은 3가지 특징이 있다.

  • 1. 확장가능한 아키텍쳐
    시스템의 수평적인 확장을 통해서 더 많은 사용자의 요청을 처리할 수 있다.
    확장된 시스템을 통해서 시스템의 부하를 분산하고, 가용성을 보장할수 있다.

    기존의 환경에서 Scale Up을 하게된다면 하드웨어의 비용 등을 고려해야 했지만
    클라우드환경에선 업체로 부터 가상의 서버, 스토리지, 네트워크 등을 빌려 사용하므로써 확장이 가능하고
    반대의 경우는 리소스를 줄여서 비용을 절감시키는것도 가능해진다.

  • 2. 탄력적 아키텍쳐
    애플리케이션을 구성하는 각 기능을 개별의 서비스로 개발하고
    이러한 서비스들을 통합하고 배포하는 시간을 CI/CD를 이용한 파이프라인을 통해 처리함하여 변화에 즉각적인 대응이 가능해진다.

    작게 분리된 독립적인 서비스간의 경계를 잘 구분하고,
    원할한 통신을 위해 각 서비스들 간의 종속성을 최소화시켜야 하기위해 노력해야 한다.

  • 3. 장애격리
    여러개로 분리된 서비스의 특성상
    특정 서비스에 오류가 발생해도 다른 서비스의 영향을 미치지 않는다는 장점이 있다.

Cloud Native Application

앞서 Cloud Native Architecture에 대해서 살펴보았다.
Cloud Native Architecture에 의해 설계되고 구현된 애플리케이션을 Cloud Native Application이라고 한다.

Cloud Native Application은 아래와 같은 방법으로 개발 및 운영이 된다.

MicroService로 개발이 된다.
-> 이렇게 개발된 서비스들은 CI/CD 시스템에 의해서 자동으로 배포가 이루어지며,
-> 문제가 발생시 바로바로 수정해서 배포가 가능해다.
-> 마지막으로 하나의 애플리케이션을 구성하는 각각의 MicroService들을 배포하고 사용하기 위해서는 container 가상화 기술을 사용하게 된다.

Cloud Native Application의 특징

  • 1. CI/CD
    Micro Service 특성상 빌드할 결과물이 많아지고, 이를 일일히 태스트-빌드-배포 하는 일은 번거롭다. 파이프 라인을 잘 구축해서 자동적으로 구성해야 한다.

  • 2. DevOps
    말그대로 개발과 운영에 관련된 모든 환경으로
    고객의 요구사항을 빠르게 반영하고 만족도 높은 결과를 제공하는 것에 목적을 두고 있다.
    고객의 요구사항은 언제든 변경될 수 있다.
    개발자는 결국 궁극적으로 고객의 요청사항에 맞게 에러없는 애플리케이션을 제공하여야 하므로
    자주 테스트하고 자주 피드백을 받고,
    자주 업데이트하는 과정을 전체 개발일정에서 끊임없이 진행하는것이 좋은 선택지 일것이다.
    Cloud Native Application은 각각의 작은 서비스들로 이루어져서
    이러한 과정이 비교적 쉽게 이루어지고, 더 자주 테스트하고, 통합하고, 배포가 가능해진다.


  • 3. Container 가상화
    Cloud Native Application의 가장 핵심적인 특징 중 하나이다.

    컨테이너 가상화 기술을 통해서 기존의 로컬환경에서 유지하던 시스템을 클라우드 환경으로 이전해서 ScalingGroup을 통해 적은 비용으로도 더 탄력적인 운영이 가능해진다.

12 Factors

헤로쿠에서 자사의 고객들을 상대로
CloudService시에 발생했었던 문제점과 개선점 시행착오 등을 문서화 하여 제시한
CloudNativeApplication을 구축함에 있어서 고려해야 할 12가지 항목이다.

  • 1. CODE BASE(코드 통합)
    애플리케이션은 1개의 코드베이스(git,svn)를 통해 관리되어야 하며, 동일한 코드로 운영/개발에 배포해야 한다.

  • 2. DEPENDENCY ISOLATION (종속성 격리)
    종속성을 명시적으로 선언 및 격리하라는 의미.
    각 서비스는 자체 종속성을 가지고 패키징화 하여서 전체 애플리케이션에 영향을 주지 않은채로 내용을 변경,수정, 확장이 가능해야 한다.

  • 3. CONFIGURATIONS (구성)
    모든 설정정보는 코드 내부가 아닌 코드 외부에서 관리되어야 한다.

  • 4. LINKABLE BACKING SERVICES (보조 서비스 지원)
    백엔드 서비스를 연결된 리소스로 취급한다.
    BackingService란 네트워크를 통해서 사용할 수 있는 모든 서비스로, DB, 캐시 SMTP서비스등을 의미한다.

    클라우드 환경에서 하나의 트랜잭션에 여러 서비스가 강결합되어 실행될 때, Orchestration이 진행되면서 트랜잭션이 끊어지고, 요청을 보존할 수 없게된다.
    반면 Message-queue를 활용하여 트랜잭션을 분리하는 경우, 서비스에 장애가 발생하여도, 영속성이 유지된다는 장점이 있다.

  • 5. STAGES OF CREATION(Build, Release, Run)
    빌드, 릴리즈, 실행환경을 분리하라는 의미이다.

  • 6. STATLESS PROCESSES (무형 프로세스)
    실행 환경에서 앱은 하나 이상의 프로세스로 실행되며, 분리되어서 stateless로 각 프로세스는 다른 프로세스와는 아무것도 공유하지 않아야 한다.
    필요한 경우에는 캐시나 DB와 같은 형태를 이용해야 한다.

  • 7. PORT BINDING (포트바인딩)
    각각의 서비스들은 타 서비스에서 접근이 가능하도록 포트바인딩을 통해 서비스를 공개한다.
    이를 통해 격리된 서비스간의 통신이 가능하다.

  • 8. CONCURRENCY (동시성)
    앱은 수평으로 확장할 수 있어야 하고,
    하나의 큰 프로세스를 여러 서비스가 기능별로 분리된 프로세스를 실행하기 때문에 동시성을 가지고 있어야 한다.

  • 9. Disposability (처분가능성)
    서비스 인스턴스 자체가 삭제가능하고, Scale up/down이 빈번하게 일어날 때
    이를 안정적으로 서비스해야한다.

  • 10. DEV/PROD PARITY (개발, 운영 환경 분리)
    개발단계와 운영단계를 분리해야한다.
    또한 애플리케이션은 개발환경과 운영환경의 차이를 최소로 하여, 지속적인 배포가 가능하도록 해야한다.

  • 11. LOGS
    발생되는 로그를 이벤트 스트림으로 처리해야한다.
    CloudApplication는 언제든지 서비스의 인스턴스가 삭제되고, 생성될 수 있는데,
    인스턴스 삭제 시 로컬에 저장된 로그는 초기화되기 때문에
    로그는 스트림으로 취급하여 별도의 저장소에 보관해야 한다.
    이를 위해 별도의 모니터링 도구를 사용할 수도 있다.

  • 12. ADMIN PROCESS
    admin/maintenance 작업을 일회성 프로세스로 실행해야 한다는 의미.
    각 서비스들이 어떤형태로 서비스 되어지고 있으며, 리소스사용량 등을 한번에 파악하기 위한 적절한 관리도구가 있어야 한다.

profile
성숙해지려고 노력하지 않으면 성숙하기까지 매우 많은 시간이 걸린다.

0개의 댓글