2 분 소요

2010년대 이후부터 IT 시스템은 Antifragile 또는 Cloud Native Architecture 형태로 발전되어왔다.
기존에 로컬 한경이나 사내에서 구축하고 운영하였던 시스템을 클라우드 환경으로 전환하기 위해서 어떠한 아키텍처를 가져야 하는지 알아보자

Cloud Native Architecture의 특징

확장 가능한 아키텍처

  • 시스템의 수평적 확장에 유연 -> 더 많은 사용자 요청을 처리할 수 있게 됨
  • 확장된 서버로 시스템의 부하 분산, 가용성 보장
  • 시스템 또는 서비스 애플리케이션 단위의 패키지 (컨테이너 기반 패키지)
  • 모니터링

스크린샷 2022-09-20 오후 9 47 21 스크린샷 2022-09-20 오후 9 48 14

보통 시스템 확장은 scale-up과 scale-out으로 나눌 수 있는데,
스케일 업(scale-up)은 쉽게 말하면 기존의 서버를 보다 높은 사양으로 업그레이드하는 것을 말한다.
하드웨어적인 예를 들면, 성능이나 용량 증강을 목적으로 하나의 서버에 디스크를 추가하거나 CPU나 메모리를 업그레이드시키는 것을 말한다.
이처럼 하나의 서버의 능력을 증강하기 때문에 수직 스케일링(vertical scaling)이라고도 한다.
소프트웨어적인 예로는 AWS의 EC2 인스턴스 사양을 micro에서 small, small에서 medium 등으로 높이는 것으로 생각하면 된다.

스케일 아웃(scale-out)은 장비를 추가해서 확장하는 방식을 말한다.
기존 서버만으로 용량이나 성능의 한계에 도달했을 때, 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터 용량이 증가할 뿐만 아니라 기존 서버의 부하를 분담해 성능 향상의 효과를 기대할 수 있다.
서버를 추가로 확장하기 때문에 수평 스케일링(horizontal scaling)이라고도 불린다.
클라우드 서비스에서는 자원 사용량을 모니터링하여 자동으로 서버를 증설(Scale Out)하는 Auto Scaling 기능도 있다.

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

Cloud Native에서는 가상 서버의 기술이 핵심적으로 필요하게 되었다.

탄력적 아키텍처

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

어플리케이션을 구성하는 각 기능을 하나의 분리된 서비스로 개발하고,
이렇게 분리되어 개발된 서비스들을 통합하고 배포하기까지 걸리는 시간을 (CI/CD 라는 파이프라인을 통해 처리함으로써) 단축할 수 있게 되었다.

마이크로 서비스는 작게 분리된 독립적인 서비스라고 했다.
전체 어플리케이션을 구성하고 있는 도메인의 특성에 따라, 서비스의 경계를 잘 구분하고 그에 맞게 서비스를 개발해야한다.
서로 분리된 서비스들 간의 원활한 통신을 위해 각각의 서비스들은 종속성을 최소화 시켜야 하고 Stateless한 서비스를 제공하도록 노력해야한다.

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

장애 격리 (Fault isolation)

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

Cloud Native Architecture는 장애복구에 뛰어나다는 장점을 가지고 있다.
여러 개로 분리되어 개발되고 있는 마이크로 서비스들은 하나의 독립적인 작은 단위의 어플리케이션과 같다.
따라서 하나의 마이크로 서비스에 생기는 문제점이나 오류 사항이 다른 서비스에 미치는 영향을 최소화 할 수 있다.

특정 부분을 수정하는 경우에도 전체 서비스를 다시 배포해야하는 것이 아닌,
특정 서비스만 배포할 수 있기 때문에 다른 시스템에 영향을 주지 않을 수 있다.



💛 개인 공부 기록용 블로그입니다. 👻

맨 위로 이동하기