Cloud Native Architecture, Application

본 포스팅은 인프런
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
강의를 기반으로 작성된 포스팅입니다.

 

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

 

---

https://wonuk.tistory.com/186

Software Architecture

 

---

목표

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

 

Cloud Native Architecture의 특징

확장 가능한 아키텍처

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

 

Scale Up, Scale Out

   시스템 확장을 의미하는 스케일링은 크게 Scale Up, Scale Out으로 나눌 수 있는데
   Scale Up이라는 것은 하드웨어의 사용을 높이는 (CPU, Memory의 스펙을 높인다.)
   Scale Out은 같은 사양의 서버(인스턴스)를 여러대 배치함으로써
   동시에 더 많은 사용자 요청을 처리할 수 있도록 하는것을 말한다.

Cloud Native Architecture

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

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

기존의 서버 가상화 방식과 더불어 컨테이너 방식의 가상화를 같이 사용하게 되었다.
또한 Cloud Native에 구축된 가상서버와 리소스들은 다양한 모니터링 도구를 이용해서
현재 사용되고 있는 시스템의 상황 및 리소스의 사용량 등을 확인 할 수 있다.

 

탄력적 아키텍처

Cloud Native Architecture는 탄력적인 아키텍처를 가지고있다.
어플리케이션을 구성하는 각 기능을 하나의 분리된 서비스로 개발하고
이렇게 분리되어 개발된 서비스들을 통합하고 배포하는 시간을
CI / CD로 처리함으로써 시스템 환경에 적용하는 시간을 단축하게 되었다.

엔터프라이즈 어플리케이션으로 갈수록 개발 인력의 증가뿐만 아니라
수많은 개발환경, 테스트환경, 운영환경, 예비서버를 고려하여 준비해야 하기때문에

(이러한 환경은 적게는 3~4개 많게는 수십, 수백개의 환경일 수 있다.)

이렇게 무수히 많은 환경에 같은 내용을 서비스 배포하는 과정이 자동화 되어있지 않다면

개발자는 비지니스 로직을 개발하는 시간보다 빌드, 배포에 많은 시간을 들이게된다.

 

마이크로 서비스

마이크로 서비스는 작게 분리된 독립적인 서비스라고 한다.

전체 어플리케이션을 구성하고있는 도메인의 특성에 따라 서비스의 경계를 잘 구분하고

거기에 맞게 서비스를 잘 개발하여야 한다.

 

서로 분리된 서비스들간에 원활한 통신을 위해 각각으 서비스들은 종속성을 최소화 시켜야하고

상태를 갖지않는 서비스를 제공하려고 노력해야 한다.

 

전체 어플리케이션을 구축하는 마이크로 서비스들은 자신들이 배포될때

자신들의 위치가 어디에 있는지 등록을 해야한다.

그래야 다른 서비스들이나 외부에 연결되어있는 타서비스에서도

해당 서비스를 검색하고 사용할 수 있다.

 

마이크로 서비스들의 존재는 디스커버리 서비스라는 곳에 등록되고 삭제되는 작업을 하게된다.

 

장애 격리 - 장애 복구에 뛰어나다.

여러개로 분리되어 개발되고있는 마이크로 서비스들은 하나의 작은 단위의 어플리케이션과 같다.

따라서 하나의 마이크로 서비스에 생기는 문제점이나 오류 사항들은 다른쪽 서비스로의 영향을 최소화 할 수 있게된다.

어떤 특정적인 부분에 대해서 수정한다 하더라도 전체 서비스를 배포해야 하는것이 아니라

특정 서비스만 배포할 수 있기 때문에 다른 시스템에 영향을 주지 않을 수 있게 된다.

 

---

Cloud Native Application

Cloud Native Architecture에 의해 설계되고 구현되는 Application

특징

1. 마이크로 서비스로 개발된다.

2. CI / CD 시스템에 의해서 자동으로 통합되고 빌드 테스트 배포라는 과정을 거치게 된다.

3. 마이크로 서비스에 문제가 발생하였을 경우 바로 수정하여 다시 배포하는 과정을 반복할 수 있다.

    -> 이러한 특징을 DevOps라고 한다. 처음에 시스템이 기획, 구현, 테스트, 배포 되는 과정을

         시스템이 종료될때까지 무한 반복함으로써 고객이 원하는 최선의 결과물을 만드는것에

         그 목적을 두고있다.

4. 하나의 어플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해서는

     컨테이너 가상화 기술을 사용하게 된다.

지속적인 통합이란 CI?

하나의 어플리케이션을 여러 팀이나 개발자들에 의해서

함께 개발하고 있는 경우에 결과물을 통합하기 위한 형상관리를 뜻할 수 있고

통합된 코드를 빌드하고 테스트하는 과정 자체를 의미하기도 한다.

 

CI 시스템은 Git과 같은 형상관리 시스템과 연동하여 사용한다.

파이프라인을 잘 연동하게되면 개발자가 코드를 완성한 후

Git과같은 형상관리 시스템에 해당코드를 업로드 커밋한다면

그와 동시에 빌드, 테스트와 같은 과정을 거쳐 다른쪽의 코드와

문제가 발생하는지 여부를 바로 확인할 수 있다.

 

ex) Jenkins, Team CI, Travis CI

 

지속적 배포란 CD?

Continuous Delivery, Continuous Deployment 두가지, 지속적인 전달과 배포

위 두가지는 Git과같은 소스 저장소에 업로드된 코드를 가져와서

패키지화된 형태의 결과물을 실행환경에 어떻게 배포하는지에 따라서 다르다.

 

만약 패키지화 되어있는 결과물을 실행환경에 수작업으로 배포하는 과정이 필요하다면

Continuous Delivery라고 할 수 있고,

운영자나 관리자의 개입없이 실행 환경까지 완벽하게 자동화 되어있는 배포를 쓴다면

Continuous Deployment이다.

일종의 서비스를 배포할때는 무작정 기존의 코드를 버리고

새로 작성된 코드를 바로 올리지 않는다, 가장 중요한것은 시스템의 정상적인 운영이고

시스템의 다운타임을 최소화하는 것이다.

 

변경된 시스템을 무조건 바로 반영하기보다 기존 시스템과 같이 운영함으로써

사용자의 이질감, 문제점등을 최소화 하는것이 필요하다.

 

카나리 배포와 블루그린 배포

 

 

DevOps

DevOps는 말 그대로 Development와 운영을 뜻하는 Operation이 합쳐진 용어이다.

개발 조직과 운영 조직의 통합을 의미한다.

이러한 통합으로 고객의 요구사항을 빠르게 반영하고

만족도 높은 결과물을 제시하는것에 그 목적을 두고있다.

 

기존의 엔터프라이즈 어플리케이션들은 고객의 요구사항에 맞게

도메인을 분석하고 시스템을 설계, 어플리케이션 구현과 테스트, 배포 과정을 거쳐

시스템 개발을 완료하게된다. 이러한 과정은 적게는 3 ~ 6개월 많게는 수년까지 걸리게 된다. 

 

물론 개발 조직에 따라서는 프로세스나 조직적인 특성으로 인해서 거쳐야하는 필수적인 과정이 있을 수 있다.

개발 기간이 길어진다는것은 그만큼 변경사항, 요구사항에 바로 대처하기 어렵다는 단점을 가질 수 있다.

고객의 요구사항은 언제든지 변경될 수 있다. 그리고 이러한 사항들은 시스템의 개발 막바지에

발생하는것보다 필요할때마다 바로 반영되고 수정할 수 있는 구조가 좋다.

 

그때그때 고객의 요구사항을 반영하고 개발된 내용의 테스트를 자주하는것은

전체 개발일정이 지연되는 요인이 될 수 있지만 회사가 개발하는 서비스, 어플리케이션은

궁극적으로 고객의 요구사항에 맞는 에러없는 완성물이어야 한다.

 

따라서 자주 테스트하고 업데이트, 테스트 하는 과정을 거쳐 전체 개발 일정이 완료될때까지

지속적으로 끊임없이 진행하는것을 DevOps라고 볼 수 있다.

 

Cloud Native Application은 이러한 DevOps환경에 맞춰서

서비스의 구조를 작은 단위로 분할할 수 있게 함으로써

더 자주 통합, 테스트, 배포할 수 있는 구조가 될 수 있습니다.

Container 가상화

가상화는 Cloud Native Architecture의 핵심이다.

기존의 로컬 환경에서 운영하고 유지해야만 했던 시스템을

클라우드 환경으로 이전해서 적은 비용으로 탄력성 있는 시스템을 구축하게된 배경이

컨테이너 가상화 기술이다.

 

하드웨어 가상화

기존의 하드웨어 가상화, 서버 가상화에 비하여 적은 리소스를 사용하여

가상화 서비스를 구축할 수 있다.

전통적인 방식의 개발 시스템은 하드웨어 시스템 위에 운영체제를 설치하고

그 다음 어플리케이션을 운영하게된다.

 

가상화

가상화를통한 개발 시스템에서는 운영체제 위에 하이퍼바이저 기술을 통한 가상머신을 기동한다.

이러한 가상머신은 시스템이 가지고있는 물리적인 하드웨어(호스트 시스템)를 쪼개어

사용하는 개념으로써 하나의 가상머신은 독립적인 운영체제를 가지고 실행될 수 있다.

각각의 가상머신에 어플리케이션을 운영할 수 있다는 이야기가 된다.

 

그러나 가상머신에서 작동되는 어플리케이션은 호스트 운영체제에 많은 부하를 주게되고

시스템 확장에 한계가 있을 수 밖에 없다.

 

컨테이너 가상화

운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 작동하게 되고

공통적인 라이브러리나 리소스를 공유하여 사용한다.

각자 필요한 부분에 대해서만 독립적인 영역에 실행할 수 있는 구조이다.

 

기존의 하드웨어 가상화 기술보다 더 적은 리소스를 사용하게 될 수 있고

컨테이너 가상화 위에서 작동되는 서비스들은 가볍고 빠르게 운영할 수 있다는 특징이있다.