Spring/SpringBoot-MSA

SpringBoot MSA (1) - Cloud Native Architecture

ChrisMare 2023. 10. 3. 16:06

MSA 스터디하며 정리하는 시간을 가지기 위해서 작성한 내용입니다.

 

Cloud Native Architecture

  • 확장 가능한 아키텍처
    • 시스템의 수평적 확장에 유연
    • 확장된 서버로 시스템의 부하 분산, 가용성 보장
    • 시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지)
    • 모니터링
  • 탄력적 아키텍처
    • 서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축
    • 분활 된 서비스 구조
    • 무상태 통신 프로토콜
    • 서비스의 추가와 삭제 자동으로 감지
    • 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)
  • 장애 격리(Fault isolation)
    • 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음

위의 특징들을 정리하자면,

기존 모놀리식 구조의 아키텍처일 경우, 

예를들어) 생산, 영업, 원가, 제조 등 여러 모듈들이 하나의 시스템에 존재한다고 가정하는 모놀리식 구조이며,

이떄, 생산 개발팀에서 오류가 터지거나 배포등을 진행했을 때! 다른 서비스들이 진행이 불가능하다는 단점과 생산의 배포만 진행되지만 다른 서비스 역시 같이 묶어서 배포를 진행해야된다는 단점등이 존재합니다.

뿐만아니라, 배포시간도 덩달아 커지는 단점이 있습니다.

 

마이크로 서비스 아키텍처로 진행한다면!

확장에 용이하다! 이말은 즉, 기존 서비스 구조를 템플릿화 시켜서 바로 수평적으로 붙이는 구조를 진행한다면

빠르게 개발이 가능하고, 서버의 부하도 분산효과도 가지고 갈 수 있을 뿐만아니라, 생산의 서버가 배포 혹은 죽더라도 다른 서비스에 영향을 주지 않는 장점이 있습니다.

하지만, 서버를 구축하는데 난이도가 존재하는 단점을 가지고 있습니다.

 

Cloud Native Application

1. MicroServices로 구축된다.

2. MicroService로 개발된 서비스들은 CI/CD를 통해서 자동으로 통합 혹은 빌드 배포의 과정을 거치게된다.

3. 해당 서버스들이 운영중 문제가 발생하거나 개선이 필요할 때 바로 수정하여 배포하는 형태가 반복되는 특징을 가지는데 이를 DevOps 라고 한다.

4. 마지막으로 만들어진 서비스들을 클라우드 환경에 배포하기 위한 Container 가상화기술이 존재한다.

 

CI/CD

  • 지속적인 통합, CI(Continuous Integration)
    • 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구 등... (ex: Jenkins, Git~~)
  • 지속적 배포
    • Continuous Delivery ( git과 같은 소스 저장소에서 수작업 배포시 )
    • Continuous Deployment ( 수작업 업시 실행환경 자동 배포 반영시 )
    • Pipe line

DevOps

개발, 테스트, 인프라 관리등을 통해 고객에게 효과적으로 지원을 하고 경쟁할 수 있는 모델을 말한다.

DevOps의 이점으로는 속도, 신속한 제공, 안정성, 확장, 협업 강화, 보안등을 말할 수 있다.

 

DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있습니다.

 

Container 가상화

App
Bin/Library
Container		 App
Bin/Library
Container		 App
Bin/Library
Container
Container Runtime
Operating System
Hardware

하나의 하드웨어에 여러 가상 컨테이너를 뛰워서 구동함으로써 리소스를 줄일 수 있는 장점이 있다.

 

 

12 Factors

1. CodeBase

애플리케이션의 1개의 코드 베이스(Git, SVN)를 통해 관리되어야 하며, 동일한 코드로 운영/개발에 배포하여야 한다.

 

2. Dependencies

애플리케이션의 모든 종속성을 명시적으로 선언하여 사용한다. 애플리케이션이 필요로 하는 라이브러리를 dependency manifest 파일에 (Gemfile, POM 등) 명시적으로 선언하여 사용한다. SaaS는 상황에 따라 다양한 환경(window, mac, linux)에 배포될 수 있다. Gemfile, pom 등을 사용하여 다양한 환경에서도 SaaS가 정상 동작할 수 있음을 보장할 수 있다. 예를 들어 curl 등을 사용하여 lib를 사용할 경우 os에 따라 오동작 할 수 있다.

 

3. Config

모든 설정 정보는 코드로부터 분리된 공간에 저장되어야 하고, 런타임에서 코드에 의해 읽혀야 한다. SaaS는 동일한 코드를 여러 환경(운영/개발)에 배포한다. 이를 위해 환경마다 달리 사용되어야 하는 정보를 분리한다.

 

4. Backing services

백엔드 서비스를 연결된 리소스로 취급한다. SaaS의 리소스는 자유롭게 배포에 연결되거나 분리할 수 있고, 코드 수정 없이 전환이 가능해야 한다. 예를 들어 DB를 MySQL에서 Amazon RDS로 전환할 때 코드 수정 없이 가능해야 한다.

 

5. Build, Release, Run

코드 베이스는 build > release > run의 단계를 거쳐 배포로 변환되며, 각 단계는 엄격하게 분리되어야 한다.

 

6. Process

실행 환경에서 앱은 하나 이상의 프로세스로 실행되며, 각 프로세스는 stateless로 아무것도 공유하지 않아야 한다. SaaS는 여러 개의 인스터스로 배포될 수 있다. 각 인스턴스는 메모리 파일 등을 공유할 수 없으며, 인스턴스가 재실행 될 때 local file, session과 같은 상태 정보는 모두 초기화된다.

 

7. Port Binding

배포된 SaaS 애플리케이션을 타 애플리케이션에서 접근할 수 있도록 포트 바인딩을 통해 서비스를 공개한다. 앱도 백엔드 서비스처럼 URL을 제공하고, 라우팅 레이어가 외부에 공개된 호스트 명의로 들어온 요청을 포트에 바인딩 된 웹 프로세스에 전달한다. Factor4. Backing services의 확장으로, 포트 바인딩에 의해 공개되는 서비스는 HTTP뿐만 아니라 ejabberd나 Redis 같은 모든 종류의 서버 소프트웨어가 해당된다.

 

8. Concurrency

앱은 수평으로 확장할 수 있어야 하고, Factor6. Processes에 의해 동시성을 높일 수 있다.

 

9. Disposability

프로세스는 shut down 신호를 받았을 때 graceful shut down 해야 한다. SaaS는 요청에 의해 Scale up/down이 빈번히 발생한다. Disposability를 준수함으로써 이러한 사용에 안정성을 얻을 수 있다. 예를 들어 Scale down 시점에 graceful shut down 이 아니라면 db lock 등으로 인해 타 프로세스에 영향을 주게 된다.

 

10. dev/prod parity

development, staging, production 환경을 최대한 비슷하게 유지한다. SaaS 애플리케이션은 개발 환경과 production 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인되어야 한다.

 

11. Logs

로그를 이벤트 스트림으로 취급하여 로그를 로컬에 저장하지 않는다. SaaS는 언제든지 인스턴스가 생성/삭제될 수 있다. 이때 로컬에 저장된 로그는 초기화되기 때문에 로그는 스트림으로 취급하여 별도의 저장소에 보관해야 한다.

 

12. Admin Process

admin/maintenance 작업을 일회성 프로세스로 실행해야 한다.

저작자표시 비영리