클라우드 네이티브로 전환한다는 것은 단순히 애플리케이션을 컨테이너나 함수로 변경하는 것이 아니다. 애플리케이션이 다루는 데이터는 어디에 어떤 구조로 저장해야 하는지, 마이크로서비스에서 비동기 통신은 어떻게 동작하는지, 배포를 위한 CI/CD 환경은 어떻게 구성해야 하는지, 운영 중인 앱의 모니터링은 어떻게 하는지, 멀티 클라우드 공급자를 사용할 때는 무엇을 주의해야 하는지 등 전반적인 내용이 필요하다.
분산 시스템을 이해해야 함
컨테이너, 서버리스(FaaS) 같은 새로운 기술을 이해해야 함
클라우드 네이티브 애플리케이션을 개발할 때 신경써야 할 것들을 파악하고 패턴을 이해해야 함
첫 장애물 : 분산 시스템
⇒ 잘못된 가정들
네트워크는 안정적이다.
네트워크 지연이 없다.
대역폭은 무한대다.
DDD나 CQRS 같은 데이터 패턴은 대역폭이 커야 하는 환경에서 매우 유용하다.
네트워크는 안전하다.
토폴로지는 변하지 않는다.
pet vs cattle (컨테이너의 등장과 함께 인기를 얻은 용어)
더 이상 장비들을 정적 IP가 할당된 엔티티(pet)으로 다루지 않는다. 장비들은 특별한 속성이 없는 무리(cattle) 로 다룬다. 클라우드 환경은 탄력성을 제공하므로 더욱 이런 관점이 필요함
전송 비용이 없다.
대부분의 클라우드 업체는 들어오는 데이터에 대해서는 과금하지 않지만 나가는 데이터에 대해서는 과금을 한다.
CAP 이론
Consistency
Availability
Partition
현실에서는 항상 네트워크 파티션이 발생한다. 즉, consistency와 availability 만 최적화가 가능하다. SQL 기반 시스템들은 보통 ACID(atomicity, consistency, isolation, durability) 원리를 지키기 위해 Consistency를 위해 Availability를 희생합니다.
Backing services (백엔드 서비스)
백엔드 서비스 : 앱이 일반적인 동작을 위해 네트워크를 통해 사용하는 모든 서비스
결합도를 떨어뜨리고 외부 설정 시스템에 저장된 설정 정보로 백엔드 서비스에 접근하는 것(DNS?)
Build, release, run
CI CD
Processes
상태가 없는 하나 이상의 프로세스로 실행 for 탄력성
Port binding / 데이터 격리
데이터 격리 : MSA의 핵심, 자신의 데이터는 자기가 관리하고 API 통해서만 접근할 수 있도록
Concurrency
수평 확장, 애플리케이션은 여러 개의 물리적인 머신에서 돌아가는 여러 개의 프로세스로 확장 가능해야 한다.
Disposability
컨테이너, FaaS를 통해 빠른 시작과 그레이스풀 셧다운을 통한 안정성 극대화
Dev/prod parity
컨테이너는 서비스의 종속성을 패키징할 수 있다. 이로 인해 각 환경의 차이를 줄여준다.
Logs
로그를 이벤트 스트림으로 취급
로그는 모든 실행 중인 프로세스와 백그라운드 서비스의 아웃풋 스트림으로부터 수집된 이벤트가 시간 순서로 정렬된 스트림이다.
로깅은 분산 시스템에서 가장 중요한 작업이다.
app은 로그 파일을 작성하거나 관리하려고 해서는 안된다. 그 대신 외부 시스템으로 보내야 한다.
Admin processes
admin, maintenance 작업을 일회성 프로세스로 실행(관리 작업을 일회성 프로세스로 실행)
관리 적업은 수명이 짧은 프로세스로 실행하라는 의미, 함수와 컨테이너는 이렇게 할 수 있는 훌륭한 도구들이다.
별도의 설치나 구성없이 REPL shell(Read Eval Print Loop)을 제공하는 언어를 강하게 선호한다.
클라우드 네이티브로 전환한다는 것은 단순히 애플리케이션을 컨테이너나 함수로 변경하는 것이 아니다. 애플리케이션이 다루는 데이터는 어디에 어떤 구조로 저장해야 하는지, 마이크로서비스에서 비동기 통신은 어떻게 동작하는지, 배포를 위한 CI/CD 환경은 어떻게 구성해야 하는지, 운영 중인 앱의 모니터링은 어떻게 하는지, 멀티 클라우드 공급자를 사용할 때는 무엇을 주의해야 하는지 등 전반적인 내용이 필요하다.
첫 장애물 : 분산 시스템
⇒ 잘못된 가정들
CAP 이론
현실에서는 항상 네트워크 파티션이 발생한다. 즉, consistency와 availability 만 최적화가 가능하다. SQL 기반 시스템들은 보통 ACID(atomicity, consistency, isolation, durability) 원리를 지키기 위해 Consistency를 위해 Availability를 희생합니다.
12 factor application
https://12factor.net/ko/
초기 클라우드(IaaS, PaaS) 환경에서 애플리케이션 개발에 새로운 방법에 대한 니즈가 있었음. 클라우드 네이티브 애플리케이션의 초석이라고 볼 수 있으며, 클라우드 환경에서 애플리케이션을 개발하기 위한 모범 사례로 heroku의 엔지니어들이 처음 소개했다.
가용성과 SLA