sangyun-han / study

0 stars 0 forks source link

Cloud Native #9

Open sangyun-han opened 3 years ago

sangyun-han commented 3 years ago

클라우드 네이티브로 전환한다는 것은 단순히 애플리케이션을 컨테이너나 함수로 변경하는 것이 아니다. 애플리케이션이 다루는 데이터는 어디에 어떤 구조로 저장해야 하는지, 마이크로서비스에서 비동기 통신은 어떻게 동작하는지, 배포를 위한 CI/CD 환경은 어떻게 구성해야 하는지, 운영 중인 앱의 모니터링은 어떻게 하는지, 멀티 클라우드 공급자를 사용할 때는 무엇을 주의해야 하는지 등 전반적인 내용이 필요하다.

첫 장애물 : 분산 시스템

⇒ 잘못된 가정들

CAP 이론

현실에서는 항상 네트워크 파티션이 발생한다. 즉, consistency와 availability 만 최적화가 가능하다. SQL 기반 시스템들은 보통 ACID(atomicity, consistency, isolation, durability) 원리를 지키기 위해 Consistency를 위해 Availability를 희생합니다.

12 factor application

https://12factor.net/ko/

초기 클라우드(IaaS, PaaS) 환경에서 애플리케이션 개발에 새로운 방법에 대한 니즈가 있었음. 클라우드 네이티브 애플리케이션의 초석이라고 볼 수 있으며, 클라우드 환경에서 애플리케이션을 개발하기 위한 모범 사례로 heroku의 엔지니어들이 처음 소개했다.

  1. Codebase 버전 관리와 CI/CD있어야 하고 이를 기반으로 개발, 테스트, 프로덕션 등 다양한 환경에 배포가 가능해야 함
  2. Dependencies 명시적인 선언과 분리 maven, npm & chef, puppet, ansible, terraform
  3. Config 코드와 분리된 설정, 외부 설정 방식, k8s의 configmap
  4. Backing services (백엔드 서비스) 백엔드 서비스 : 앱이 일반적인 동작을 위해 네트워크를 통해 사용하는 모든 서비스 결합도를 떨어뜨리고 외부 설정 시스템에 저장된 설정 정보로 백엔드 서비스에 접근하는 것(DNS?)
  5. Build, release, run CI CD
  6. Processes 상태가 없는 하나 이상의 프로세스로 실행 for 탄력성
  7. Port binding / 데이터 격리 데이터 격리 : MSA의 핵심, 자신의 데이터는 자기가 관리하고 API 통해서만 접근할 수 있도록
  8. Concurrency 수평 확장, 애플리케이션은 여러 개의 물리적인 머신에서 돌아가는 여러 개의 프로세스로 확장 가능해야 한다.
  9. Disposability 컨테이너, FaaS를 통해 빠른 시작과 그레이스풀 셧다운을 통한 안정성 극대화
  10. Dev/prod parity 컨테이너는 서비스의 종속성을 패키징할 수 있다. 이로 인해 각 환경의 차이를 줄여준다.
  11. Logs 로그를 이벤트 스트림으로 취급 로그는 모든 실행 중인 프로세스와 백그라운드 서비스의 아웃풋 스트림으로부터 수집된 이벤트가 시간 순서로 정렬된 스트림이다. 로깅은 분산 시스템에서 가장 중요한 작업이다. app은 로그 파일을 작성하거나 관리하려고 해서는 안된다. 그 대신 외부 시스템으로 보내야 한다.
  12. Admin processes admin, maintenance 작업을 일회성 프로세스로 실행(관리 작업을 일회성 프로세스로 실행) 관리 적업은 수명이 짧은 프로세스로 실행하라는 의미, 함수와 컨테이너는 이렇게 할 수 있는 훌륭한 도구들이다. 별도의 설치나 구성없이 REPL shell(Read Eval Print Loop)을 제공하는 언어를 강하게 선호한다.

가용성과 SLA

sangyun-han commented 3 years ago

참고 : hexagonal architecture