클라우드 네이티브 애플리케이션

클라우드 네이티브는 12요소 애플리케이션과 특성이 비슷하지만 똑같지는 않다. 클라우드 네이티브 애플리케이션은 플랫폼에서 실행되도록 설계되었으며, 이를 기반으로 회복성, 애자일성, 운영성, 관측 가능성을 갖추도록 설계되었다.

​

회복성(resiliency)는 장애를 막아내려 애쓰기보다는 포용하며, 플랫폼에서 수행되는 동적 특성을 활용한다.

​

애자일성(agility)은 신속한 배포와 빠른 반복을 가능하게 한다.

​

운영성(operability)은 외부 프로세스와 모니터링 시스템에 의존하는 대신 애플리케이션 내에 수명주기를 제어한다.

​

관측 가능성(observability)은 애플리케이션 상태에 대한 정보 조회 기능을 제공한다.

​

​

http://cncf.io/about/charter

​

​

마이크로서비스

​

단일 엔티티(entity)로 관리되고 배포되는 애플리케이션을 흔히 일체형 애플리케이션(monolith)이라고 부른다. 이러한 애플리케이션은 복잡성이 커지면 일체형 애플리케이션의 장점은 줄어든다. 애플리케이션을 이해하기 어려울 뿐더러, 엔지니어가 추론해 코드를 변경하기가 더 어렵기 때문에 애자일성이 떨어진다.

​

복잡성을 줄어들게 하는 방법으로는 명확하게 정의된 기능을 소규모 서비스로 분리하고, 각 서비스를 독립적으로 반복되게 만드는 방법이 있다. 이렇게 하면 애플리케이션 일부를 필요에 따라 더 쉽게 변경할 수 있기 때문에 애플리케이션의 애자일성이 향상된다. 그리고 모든 마이크로서비스는 독립적인 팀에서 관리하고, 적절한 언어로 작성하며, 필요에 따라 독립적으로 확장 할 수 있다.

​

이러한 각 서비스들은 튼튼한 계약을 따르고, 신속하게 개선하거나 변경할 수 있다. 하지만 이런 마이크로서비스 아키텍처로 이동하기 위한 고려사항은 많다. 이중 최소한의 조건은 회복성 있는 네트워크 통신이다.

​

클라우드 네이티브 애플리케이션의 운영성을 높이려면 애플리케이션에서 정상 상태 확인 health check 기능을 제공해야 한다.애플리케이션이 자체 검사를 수행한 후 응답할 수 있는 명령어나 프로세스 시그널로 이를 구해야 한다.

​

——————

구글 보그 사례

​

보그에서 실행되는 거의 모든 작업은 작업의 상태와 수천 가지 성능 매트릭(RPC 대기 시간 같은)에 대한 정보를 공표하는 내장 HTTP 서버를 포함하고 있다. 보그는 상태 확인 URL을 감시하다가, 즉시 응답하지 않거나 HTTP 오류 코드를 반환하는 프로세스는 재시작한다.

다른 데이터는 대시보드에서 제공하는 모니터링 도구에 의해 추적되고, 이것이 서비스 수준 목표(SLO)를 위반한 경우 경고한다.

​

—————

-> 프로세스를 감시하고 이상 있을 시 재구동 하는 정책에 대한 것은 일단 회복성을 준수하도록 초점을 맞춘다면 어떤 형태이건 상관 없지 않을까 싶다. 우아한 어떤 처리 방법을 생각할 때 따른 대책이 없다면 빠른 회복성을 적용할 수 있도록 해야 할 것 같다.

​

측정 데이터

​

측정 데이터(telemetry)는 의사 결정에 필요한 정보다.

비즈니스 목표를 알려준다.

이러한 메티륵을 종종 서비스 수준 지표 (SLI , Service Level Indicator) 또는 핵심 성능 지표(KPI, Key Performance Indicator)라고 부른다.

​

이러한 지표들을 통하여 애플리케이션의 성능이 지표상 적합한 위치에 있는지 확인해야 한다.

​

분당 요청수는 얼마인가

어떤 오류가 발생되는가?

애플리케이션 대기 시간은 어느정도인가?

요청 후 응답까지 얼마나 오래 걸리나

​

이러한 데이터를 집계하기 위해 프로메테우스(Prometheus) 또는 인플럭스디비 (InfluxDB) 같은 시각화 데이터베이스에 저장된다.

​

이때 최소한 정보로는 RED( 속도 Rate, 오류 Error, 지속 시간 Duration) 메소드로 구현하는 방식이 가장 좋다.

​

속도 : 수신된 요청 수

오류 : 애플리케이션의 오류 수

지속 시간 : 응답을 받는 기간

​

그리고 동적이고, 자가 치유 (self healing)이 가능한 환경에서는 개별 애플리케이션 인스턴스 생명주기 보다 성능 지표에 대해 더 관심을 기울여야 한다.

​

회복성

​

회복성은 원래 인프라스트럭처의 책임이었다. 하지만 클라우드 네이티브 애플리케이션은 이 작업 중 일부를 자동으로 실행해야 한다.

​

​

​

**마이크로 서비스 아키텍처 **

가벼운 API로 서로 다른 서비스와 통신하고, 개발팀 IT팀에 독립적으로 운영 되는 것

​

컨테이너 화

컨테이너 기술을 가볍고, 쉬운 이식성을 통해 신뢰성 있게 배포

​

데브옵스로의 자동화

빌드 배포 구현등을 자동화 하여 휴먼 에러나 다운 타임이 발생할 수 있는 부분등을 감소

​

신속한 변환

신속한 배포 및 출시

​

인프라스트럭처

​

도표로서의 인프라스트럭처

스크립트로의 인프라스트럭처

• 스크립트의 런타임은 정의된 순서대로 각 단계를 실행하지만, 런타임 자체는 이 스크립트가 생성하는 결과를 알지 못한다.

​

문제점 두가지

• 처음 실행된 환경이 두번째 환경과 달라진다.

현재 사용중인 Deploy 방법인 aws code deploy랑 비슷하다고 해야 할 것 같다.

Auto scaling 처럼 동일한 환경에 배포되어 사용할 수 있도록 하기 위해 초기 셋팅부터 담고 있다.

​

• 선언적 상태의 결핍

수행할 단계만 제공되기 때문에 스크립트의 런타임은 종료 상태를 이해하지 못한다.

​

스크립트만으로 배포를 한다면 위 와 같은 문제가 발생할 수 있다. 그럼 어떤 조합을 사용해야 이런 이슈들을 잘 해결 할 수 있을까?

​

​

구성 관리(형상 관리)는 기존 인프라스트럭처 표현 부분에서 제왕이었다.

​

인프라스트럭처를 수동으로 운영하던 엔지니어들은 이제 코드를 개발하게 됨.

-> 높은 수준의 추상화 관리도구가 탄생.

​

​

형상 관리란,

​

형상관리는 프로젝트의 수명주기 동안 제품의 무결성과 추적성을 확보하기 위한 활동으로 정의할 수 있다. 형상관리의 대상은 프로젝트의 수행을 통해 고객에게 인도되는 제품과 그와 관련되는 문서가 그 대상이다. 형상관리는 프로젝트에 참여하는 프로젝트 관리자, 프로젝트 개발자, 품질보증 담당자 및 고객에게 제품의 진행상태에 대한 가시성을 확보하도록 하기 위한 활동이다. 형상관리 활동을 가장 잘 표현하는 말로서는 “누가 그것을 변경하였는가? 그리고 무엇을 변경하였는가?”에 대한 해답을 제시하는 것이다.

​

​

​

부트스트랩

​

더 복잡한 도구를 만들 수 있도록 단순 도구를 만들거나 적재함으로서 복잡한 소프트웨어 도구를 만들거나 컴퓨터를 시작하는 것을 말한다. 줄여서 시동이라고 할 수 있으며, 이는 컴퓨터를 시작하는 과정을 서술해준다.

​

“소프트웨어를 신뢰할 수 있는 능력은 엔지니어링 성공에 매우 중요하다.”

​

인프라 스트럭처는 신뢰할 수 있게 만들어야 한다.

​

신뢰할 수 있게 만드는 방법 3가지

​

인프라스트럭처가 의도한대로 작동하는지 증명한다.

인프라스트럭처에 실패가 없음을 증명한다.

다양한 예외 조건에서 두 가지 조건이 모두 충족됨을 증명한다.

​

​

카오스 도입

카오스 도입은 인프라구성이 완료된 시점부터 진행해야 한다.

그리고 카오스 측정은 암묵적으로 시간에 따른 카오스의 측정을 말한다.

​

넷플릭스에서 도입한 카오스 몽키(Chaos Monkey) 사례

카오스몽키(chaos monkey) 어떤 문제도 해결이 가능한 엔지니어가 대기하게 만들어, 계속 시스템의 약점을 파악해서 이를 해결하는 자동복구 메커니즘을 만들 수 있었다. 원숭이들은 소프트웨어로서 인프라스트럭처와 조정자 패턴을 사용하기 좋은 예다.

​

코드로서 인프라 스트럭처와 소프트웨어로서의 인프라 스트럭처의 기본적인 차이점은 소프트웨어가 지속적으로 실행되고 조정자 패턴을 기반으로 인프라스트럭처를 생성하거나 변경한다는 것이다.

​

​

사이드카 패턴

사이드카 패턴은 클라우드 디자인 패턴의 일종입니다.

기본 Application 외 필요한 추가 기능을 별도의 Application으로 구현하고 이를 동일한 프로세스 또는 컨테이너 내부에 배치하는 것입니다.

동일한 프로세스 또는 컨테이너에 배치된 사이드카 Application은 저장 공간, 네트워크 등의 리소스를 공유하며 모니터링, 로깅, 프록시 등의 동작을 합니다.

​

사이드카 Application은 기본 Application과 별도의 Application입니다.

기본 Application의 로직을 수정하지 않고도 추가 기능을 수행할 수 있습니다.

기본 Application을 polyglot 프로그래밍을 적용해 요구 사항에 최적화된 환경에서 개발을 진행할 수 있습니다.

사이드카 Application은 기본 Application과 리소스를 공유할 수 있습니다. 이를 통해 모니터링에 필요한 Metrics 수집, 프록시 동작 등을 수행할 수 있습니다.

​

서비스 메시 및 사이드카

​

​

폐기

​

빠르게 이동하는 환경에서는 새로운 애플리케이션과 서비스 배포가 일반적이다. 애플리케이션의 폐기(retire)역시 애플리케이션 생성과 같은 방식으로 셀프 서비스여야 한다.

​

-> 애플리케이션, 배포된 인스턴스 관리도 자동적으로 관리되어야 한다는 것.

​

폐기되어야 하는 서비스와 자원을 식별하는 작업은 비즈니스와 관련이 깊다. 애플리케이션의 원격 측정 데이터에서 얻은 실증 데이터를 사용해서 애플리케이션이 사용 중인지 여부를 알 수 있지만, 애플리케이션을 폐기하는 결정은 비즈니스에서 이루어져야 한다.

인프라스트럭처 구성요소(VM 인스턴스와 로드밸런서 종단점 같은)는 필요하지 않은 경우에 자동으로 정리되어야 한다.

​

자동 구성 요소 정리의 한 예는 넷플릭스의 재니터 몽키(Janitor Monkey)다.

​

재니터 몽키는 자원에 규칙 집합을 적용해 정리 후보가 되어야 하는지 여부를 결정한다. 이때 자원이 정리 대상이라고 판단되면, 재니터 몽키는 자원을 점찍어두고 정리할 시간을 예약한다.

​

자동 스크립트를 인간이 작성하는 대신, 구성 요소의 메타 데이터와 결합된 조정자 패턴을 사용해 현재 문맥을 기반으로 높은 수준에서 이뤄질 필요가 있는 작업을 끊임없이 결정하고 실행한다.

​

인프라스트럭처에 대한 애플리케이션 요구사항

​

애플리케이션 런타임과 격리

자원 할당과 스케줄링

환경 격리

서비스 발견

상태 관리

모니터와 로깅

디버깅과 추적

​

**멀티테넌트 **

동일한 서버에서 여러 애플리케이션과, 공유 클러스터에서 애플리케이션을 실행하는 사용자를 일컫는다.

​

컨테이너

도커는 패키지를 만들고 격리된 환경에서 애플리케이션을 실행하는 방법을 기술하기 위해 컨테이너라는 용어를 널리 퍼트렸다.

단일 운영체제에서 프로세스를 격리하기 위해 커널기능이나 하드웨어 기능을 사용한다.

​

​

애플리케이션 보호

​

애플리케이션을 확장하는 방법을 학습해 인프라스트럭처를 확장한다.

애플리케이션 보안 방법을 학습해서 인프라스트럭처를 보호한다.

​

배포 분기 (번역 문제인지 애매 -_-)

​

모든 테스트가 끝난 후에만 배포가 가능하다.

새로운 애플리케이션인 경우에는 선임 개발자가 변경사항을 검토하고 pull request에 대해 주석을 달도록 요청 해야한다.

운영환경에 산출물을 밀어 넣는 행위는 배포 파이프라인에서만 할 수 있다.

​

적합성 테스트

어떤 인프라스트럭처에서든 특정 유형의 애플리케이션을 만드는데 권장되는 방법을 제공해야 한다. 이런 권장 사항은 사용자가 자신의 필요에 따라 소비하고 짜 맞추는 조립 블록이어야 한다.

​

클라우드 네이티브 애플리케이션은 컨테이너로 패키징 되고 오케스트레이터를 통해 소비 되도록 이미 권장되어 왔다.

​

-> 인프라스트럭처의 구성도 중요하지만, 애플리케이션도 이러한 요건 사항에 맞춰 개발이 필요해 보인다.

​

인프라스트럭처의 템플릿의 가장 중요한 측면은 올바른 일은 쉽게하고, 잘못된 일은 하기 어렵게 만드는 것이다.

​

표준을 지키지 않는 인프라스트럭처 예시

​

————

** - 자동 확장 그룹이 뒤에 있지 않은 애플리케이션**

** - 로드밸런서 뒤에 있지 않는 애플리케이션**

** - 데이터베이스와 직접 대화하는 프론트 엔드 계층**

————

​

표준을 위반하면 가능한 빨리 해당 애플리케이션을 종료해야한다. 이때 기한을 정해주고 담당자에게 통보를 한다.

​

준수성테스트

준수성 테스트는 아키텍처 설계를 테스트 하지 않고, 구성 요소 구현이 정의된 정책을 충실히 지키는지 확인 하는데 중점을 둔다.

​

객체 저장소는 사용자 접근이 제한 되어야 하고, 공개된 인터넷에서 읽거나 쓸 수 없다.

API 종단점은 모두 HTTPS를 사용해야 하며 유효한 인증서가 있어야 한다.

VM 인스턴스(있는 경우 해당)에 과도하게 허용된 방화벽 규칙은 없어야 한다.

​

활동테스트

자동 폐기 관리 등을 이야기 함.

-> 현재 이미지 수집에 사용되는 S3버킷 정책은 이러한 부분을 위반하고 있음.

​

​

클라우드 네이티브 패턴을 채택하기 위해서는 아래와 같은 분야에 중점을 둬야 한다.

​

사람

변화에 도전할 수 있는 사람, 주간 업무량의 20%만 업무에 투입하고 습득할 수 있는..

아키텍처

회복성, 보안 확장성, 배포 가능성, 테스트 가능성. 최소한의 수동 관리. 빈번한 변경. 회복성을 위한 아키텍처

카오스 관리

실패를 받아들이고 카오스를 기대해라.

회복성이 있는 시스템을 만들어야 하지만 과도하게 엔지니어링 하는 비용을 들여서는 안된다.

애플리케이션

​

​

​

​