인프라스트럭처는 애플리케이션을 지원하는 모든 소프트웨어와 하드웨어를 말함
이러한 인프라스트럭처의 관리에는 엄청나게 많은 시간 및 자금이 발생됨
이러한 인프라스트럭처를 수년간 수많은 사람의 노력으로 운영 및 발전이 되었다.
클라우드 네이티브 인프라스트럭처는 클라우드 네이티브 어플리케이션을 효과적으로 관리하기위한 방법이 될수있다.
하지만 올바른 설계와 관례가 없다면 최고의 클라우드 네이티브 어플리케이션도 쓰레기가 될수 있다.
올바른 클라우드 네이티브 인프라스트럭처의 패턴을 개척한 사람들의 경험에 집중해야 한다.
- 클라우드 네이티브의 이점
클라우드 네이티브의 패턴은 구글이나 넷플릭스 아마존과 같은 대규모의 인프라를 관리하는 글로벌 기업의 경험을 통해서 만들어 졌다.
이러한 기업들의 경험을 100% 동일하게 적용할수 없지만 수많은 노하우를 나만의 인프라스트럭처에 적용을 할 수 있다.
퍼블릭클라우드에서 인프라스트럭처를 운영하는 방식을 선택하게 된다면 비지니스에 대해 집중을 할수 있게된다.
물리서버 -> 가상화 -> IaaS -> PaaS(SaaS)
@Heroku 사의 개발자가 준수해야하는 12가지 주요요소의 정의 (참고자료 필요함)
- 클라우드 네이티브 인프라스트럭처
클라우드 네이티브라는 용어는 마케팅에서 가지고와서 사용하게 되었다.
이 글에서 정의하는 클라우드 네이티브라는 용어는 퍼블릭 클라우드 공급업체가 존제하는 세상에서의 기술적 진화를 의미한다.
추상화 뒤에 감춰진 인프라스트럭처 (API에 의한 제어, Software를 통한 관리, Application 의 실행)의 목적을 가지고 있음
확장성, 효유적인 방식의 관리패턴의 생성이 발생됨
추상화가 구체화 됨으로 복잡성을 성공적으로 숨길수가 있게 되었다.
SDN, SDDC, 등의 여러가지 SDx 가 예시
클라우드 네이티브 인프라스트럭처의 추상화를 위해 IaaS영역을 추상화 해야한다. IaaS의 영역을 제어할 뿐 아니라 자체적인 API를 제공하여서 사용자가 제어할수있게 하여야 한다.
소프트웨어로 제어되는 인프라스트럭처는 확장이 가능, 회복성과 권한설정, 유지보수성을 개선하는데도 주요한 역활을 함
- 클라우드 네이티브 인프라스트럭처가 아닌것은 무엇인가
퍼블릭 클라우드에서 인프라스트럭처를 실행하는것이 유일한 목적이 되는건 클라우드 네이티브 인프라 스트럭처로 이야기 할수 없다.
컨테이너상에서의 애플리케이션의 실행도 클라우드 네이티브 인프라스트럭처를 의미하지 않는다.
컨테이너 오케스트레이터만 실행한다는 의미도 아니다. (K8S, Mesos)
오케스트레이터의 사용은 클라우드 네이티브 인프라스트럭처의 훌륭한 첫걸음이기는 앞으로 해야할 여러가지 일들이 남아 있다.
클라우드 네이티브는 "마이크로서비스", "IaC(Infrastructure as code)"가 아니다.
마이크로서비스는 더 작은 기능을 더 빠른 개발주기로 개발을 할수있게 해주지만, 일체형 애플리케이션에도 소프트웨어에 의해 효과적으로 관리될 수 있는 동일한 기능이 있기에 클라우드 네이티브 인프라스트럭처의 이점을 얻을수 있다.
IaC는 코드로 인프라스트럭처는 컴퓨터로 해석이 가능한 언어 혹은 DSL(Domain-Specific Language)로 인프라스트럭처를 정의하고 자동화 한다.
전통적인 IaC 도구는 Chef, Puppet 과같은 구성관리 도구가 포함된다.
이러한 도구들은 작업 자동화 및 일관성 제공에는 큰 도움이 되지만 단일 서버를 넘어서는 인프라스트럭처를 정의하는 추상화를 제공하기에는 부족함이 많다.
- 클라우드 네이티브 애플리케이션
플랫폼에서 실행되도록 설계, 이를 기반으로 회복성, 애자일성, 운영성, 관측 가능성을 갖추도록 설계됨
회복성(resiliency) - 장애를 막아내려 애쓰기보다는 포용하며, 플랫폼에서 수행되는 동적 특성을 활용
애자일성(agility) - 신속한 배포, 빠른반복을 가능하게함
운영성(operability) - 외부 프로세스와 모니터링 시스템에 의존하기 보다는 애프리케이션 내에서 수명주기를 제어함
관측 가능성(observability) - 애플리케이션 상태에 댛산 정보 조회기능을 제공함
클라우드 네이티브의 정의는 계속해서 발전해 나가고 있다.
CNCF 와같은 기관에서 사용하는 정의를 참조하자 ( http://cncf.io/about/charter )
% CNCF (Cloud Native Computing Foundation)
K8S 가 만들고 리눅스 재단이 참여한 클라우드 네이티브 표준 단체이며 구글등의 기업이 참여해 활발히 활동중이다.
% 클라우드 네이티브 애플리케이션은 퍼블릭 클라우드 환경, 사내구축 환경, 물리서버환경등에서 실행되는거에 따라 구분이 되는것은 아니다.
애플리케이션의 복잡성이 커지면 커질수록 일체형 애플리케이션의 이점이 줄어들게 된다. 이러한 복잡성을 이겨내기위해 명확하게 정의된 기능을 소규모 서비스로 분리하고 각 서비스를 독립적으로 반복하게 방법이 있다. 이러한 경우 애자일성이 회복된다.
모든 마이크로 서비스는 독립적인 팀에서 관리가 가능하며, 팀별로 적절한 언어로 작성되며, 독립적으로 확장이 가능하게 된다.
- 정상상태 보고
애플리케이션의 정상상태에 대해서 개발자보다 더 잘알수 있는 사람은 없다.
인프라스트럭처의 관리자는 자신들이 실행해야하는 애플리케이션의 정상적인(healthy) 상태의 의미를 파악하려고 하였다. 어떠한 조건에서 애플리케이션이 실행되는것에대해 모른체 애플리케이션의 상태만을 모니터링해서 비정상 상황일때 경고를 생성하는 시도는 100% 안전하다고 이야기 할 수 없다.
클라우드 네이티브 애플리케이션의 운영성을 높이려면 애플리케이션에서 정상 상태 확인(healthy check) 기능을 제공해야 한다.
애플리 케이션에서의 자체검사를 수행한 후 응답가능한 명령어나 프로세스 시그널로 이를 구현해야 한다.
일반적으로는 HTTP 응답 코드를 통해 정상 상태를 반환하는 경우도 있다.
% 구글 보그의 논문에서는 "실행되는 거의 모든 작업은 작업의 상태와 수천가지 성능 메트릭에 대한 정보를 알려주는 HTTP 서버를 포함한다. 보그는 상태확인 URL 를 감시하며, 해당 응답에 따른장애처리를 한다. "
정상 상태 관리의 책임을 애플리케이션으로 옮기게되면 애플리케이션을 훨씬 쉽게 관리하고 자동화를 할수 있게된다.
정상 상태 확인을 제공하는 대표적인 애플리케이션은 Zookeeper 의 "ruok" 명령어와 etcd 의 "HTTP /health end point" 이다.
애플리케이션은 단순히 정상/비정상 으로 상태값을 체크하기보다는 좀 더 구체적인 내용이 포함된 상태보고가 필요하다.
- 측정 데이터
측정 데이터는 의사결을 하기위해 필요한 데이터를 이야기한다. 측정 데이터는 정상 상태 보고와 다소 겹칠수 있지만 목적이 다르다.
정상상태보고는 애플리케이션의 수명주기에 대해 알려주지만, 측정 데이터는 비즈니스 목표를 알려준다.
측정 가능한 메트릭을 종종 서비스 수준 지표 / SLI(Service Level Indicator), 또는 핵심 성능 지표 / KPI(Key Performance Indicator) 라고 한다.
이런 애플리케이션에 밀접한 데이터를 통해 애플리케이션의 성능이 서비스 수준 목표 / SLO(Service Level Objective) 내에 있는지 확인을 해야한다.
측정과 메트릭은 다음과 같은 질문을 해결하는데 사용된다.
ㄴ 애플리케이션이 받는 분당 요청 수는 얼마인가?
ㄴ 어떤 오류가 있는가?
ㄴ 애플리케이션 대기 시간은 어느정도 인가?
ㄴ 주문을 하려면 얼마나 걸리나?
데이터는 집계를 위해 시계열 데이터베이스에 저장된다. (Prometheus, InfluxDB ...)
측정 데이터에 대한 유일한 요구사항은 데이터를 수집하는 시스템이 요청하는 대로 형식을 마추는 것이다.
애플리케이션에서 수집하는 최소한의정보(RED, Rate, Error, Duration)
ㄴ 속도(Rate) : 수신된 요청 수
ㄴ 오류(Error) : 애플리케이션의 오류 수
ㄴ 지속 시간(Duration) : 응답을 받는 기간
정상 상태 모니터링 보다는 측정 데이터를 경고에 사용함이 옳바르다.
동적이고 자가 치유가 가능한 환경에서는 개별 애플리케이션 인스턴스 수명주기에는 관심을 적게두고 전체직인 애플리케이션 SLO 에 더많은 신경을 써야 한다. 자동화 애플리케이션 관리를 위한 정상상태모니터링은 여전히 중요하지만 이정보를 기반으로 엔지니어게 호출 정보가 가서는 안 된다.
1개 혹은 50개, N개의 애플리케이션의 인스턴스가 비정상 적이라도 애플리케이션에 대한 비지니스 요구사항이 충족되는경우에는 경고메시지에 신경을 꺼도 된다. 메트릭을 사용하게되면 SLO를 만족하는지 애플리케이션이 어떻게 사용되는지, 애플리케이션에서 어떤것이 정상인지 알 수 있다.
경고와 로깅이 혼동되서는 않된다. 로깅은 디버깅, 개발, 패턴 관찰에 사용된다. 로깅은 애플리케이션 내부 기능을 공개한다.
- 회복성
측정을 통해 모니터링 데이터가 수집되면 애플리케이션이 장애로부터 회복성을 유지하도록 만들어야 한다. 이러한 회복성은 인프라스트럭처의 책임이였다. 하지만 클라우드 네이티브 애플리케이셔는 이러한 작업중 일부를 자동으로 실행해야 한다.
%모든 플렛폼, 특히 클라우드에서 가장 중요한 기능은 신뢰성이다.
클라우드 네이티브 애플리케이션에서는 장애 상황에 대한 설계 와 단계적 성능 저하 이 두가지에 대한 회복성을 고려해야 한다.
[장애 상황에 대한 설계]
유일하게 장애가 발생하면 안되는 시스템은 생명 유지 장치이다.
절대로 서비스가 다운되지 않는다면 이는 역설적으로 장애를 극복하는데 너무 많은 시간을 소모하는것이라고 볼 수 있다.
SLO은 서비스에 필요한 가동시간을 결정하며, 이를 초과하는 가동시간은 엔지니어링 하는데 소비하는 어떤 자원도 낭비라고 할 수 있다.
모든 서비스에 대해 두가지 값
장애평균시간 (MTBF, Mean Time Between Failure)
복구 평균 소요 시간 (MTTR, Mean Time To Recover)
은 반듯이 측정되어야 한다. 모니터링과 메트릭을 이용하게되면 SLO을 충족시키는지를 감지할 수 있지만 애플리케이션이 실행되는 플랫폼은 MTBF를 높게 유지하고 MTTR 을 낮게 유지하는게 중요하다.
45 Page
작성중 ...................