[Infra] Cloud Native Architecture/Application

확장 가능한 아키텍쳐

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

탄력적 아키텍쳐

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

장애 격리(Fault isolation)

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

Cloud Native Application

CI/CD

• 지속적인 통합, CI(Continuous Integration)
  • 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구
  • ex) Jenkins, Team CI, Travis CI
• 지속적 배포
  • Continuous Delivery (지속적 전달 > 수동 반영)
  • Continuous Deployment (지속적 배포 > 자동 반영)
  • Pipe line

DevOps

• 애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크
• 애플리케이션 개발 팀(Dev)과 해당 IT 운영 팀(Ops) 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려

Container 가상화

• 로컬 환경에서 운영/유지하는 것을 클라우드 환경에서 적은 비용으로 탄력성있는 시스템을 구축하는 것
• 기존의 하드웨어 가상화 또는 서버 가상화에 비해서 적은 리소스를 사용하여 가상화 서비스 구축
• 운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 작성하고 컨테이너 가상화에서는 공통적인 라이브러리나 리소스 같은 것들을 공유하여 각자 필요한 부분에서에 대해서만 독립적인 영역에 실행

12 Factors(Cloud Native Application 구축에 필요한 12가지 항목)

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 Service)
   • 백엔드 서비스를 연결된 리소스로 취급한다.
   • 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 작업을 일회성 프로세스로 실행해야 한다.