1960 ~ 1980년도(Fragile, Cowboys) : 하드웨어나 시스템 자체가 상당히 고가였기 때문에 서비스의 기능을 수정/변경하기 어려워 소프트웨어보다 하드웨어 사양에 맞춰 개발되던 시기이다.
1990 ~ 2000년도(Robust, Distributed) : 분산/안정화된 시스템 덕분에 안정성 있는 높은 서비스를 제공할 수 있는 시기이다.
2010년 ~ (Resilient/Anti-Fragile, Cloud Native) : 시스템은 로컬환경에서 클라우드로 이전 되었으며 확장/안정성이 강화 되었고 지속적인 개선 및 변경사항이 생겨도 시스템을 탄력적으로 운영할 수 있게 되었다. 그러므로 비용또한 저렴하게 운영이 가능했다.
Anti-Fragile부터 DevOps라는 문화가 생겨났고, IT 아키덱처 측면에서는 Cloude Native 아키텍처로 전환되었다.
Anti-Fragile
오토 스케일링의 특징은 Auto scaling, Chaos engineering, Continuous, deployments가 있다.
Autoscaling
: Auto scaling은 자동 확장성을 갖는 특징이다. 시스템을 구성하고 있는 인스턴스를 하나의 Auto scaling group으로 묶어 유지되어야 하는 최소한의 인스턴스를 지정할 수 있고, 사용량에 따라 인스턴스의 수를 증가/감소할 수 있는 환경을 의미한다.
Micoroservices 넷플릭스의 마이크로서비스 구성도
: Cloud Native Architecture의 핵심 기술이다. 기존 시스템들이 하나의 거대한 서비스로 구성되었다고 가정한다면 마이크로서비스는 시스템을 구성하고 있는 개별적이 모듈, 기능을 독립적으로 개발/배포/운영할 수 있도록 세분화된 서비스라고 볼 수 있다.
Chaos engineering
: Chaos engineering이란 시스템이 급격하고 예측하지 못한 상황들을 견딜 수 있고 신뢰성을 쌓기 위해 운영 중인 소프트웨어 시스템의 실행하는 방법/규칙을 의미한다. 변동, 예견/예견되지 않은 불확실성에 대해서도 안정적인 서비스를 운영할 수 있도록 구축되어야 한다.
Continuous deployments
: CI/CD와 같은 배포 파이프라인을 예로 들 수 있다. CI/CD는 지속적인 통합, 지속적인 배포를 의미하며 Cloud Native System의 경우 많은 Micro Service로 도메인이 분리되 개발되며 많게는 수십, 수백개의 서비스로 구성될 수 있다. 이 수많은 서비스를 수작업으로 빌드/배포하는 것은 사실상 불가능에 가깝다. 이 문제를 Continous deployments를 통해 자동화된 시스템을 구축하고 하나의 작업에서 다른작업으로 연계되는 과정을 파이프라인으로 연결시키면 작은 변화 뿐만 아니라 전체적인 시스템 업그레이드에서도 빠르게 적용할 수 있다.
Cloud Native Architecture
기존에 로컬환경에서 구축/개발 하였던 시스템을 클라우드 환경으로 전환하기 위해서 어떤 아키텍처를 가져야 하는지 알아보자.
확장 가능한 아키텍처 - 시스템의 필요에 따라 확장 가능한 형태로 발전하였다. 특히 시스템의 수평적 확정으로 인해 더 많은 사용자의 요청을 처리할 수 있게 되었다.
- 확장된 서버로 시스템의 부하 분산, 가용성을 보장 하였다. : 시스템 확장을 의미하는 스케일링은 scale-up, scale-out으로 나뉜다. scale-up은 하드웨어 (CPU, 메모리 등)의 사양을 높이는 것을 의미한다. scale-out은 같은 사양의 서버 즉 인스턴스를 여러 개를 배치함으로써 동시에 더 많은 사용자의 요청을 처리할 수 있도록 하는 것을 의미한다. 위에서 말했듯 시스템을 양적으로 증가 시킬 경우 비용이 증가하겠지만 클라우드 네이티브 아키텍처에서는 클라우드 서비스 업체로부터 가상의 서버/스토리지/네트워크 등을 빌려 사용하므로 이러한 비용을 최소화 시켰다. (scale-up, scale-out으로 증가 되었던 시스템을 필요 유무에 따라 리소스를 사용/반납해 비용을 낮출 수 있다.)
- 시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지) : 기존의 서버 가상화 방식과 더불어 컨테이너 방식의 가상화를 같이 사용하게 됨. - 클라우드 네이티브에 구축된 가상 서버와 리소스들을 다양한 모니터링 도구를 이용해 관리감독할 수 있다. : 시스템의 현재상황, 리소스 사용량 등을 확인.
탄력적 아키텍처 - 서비스 생성/통합/배포/비지니스 환경 변화에 대응시간을 단축 시켰다. - 어플리케이션의 도메인 특성에 따라 서비스를 구분해 개발한다. - 분리된 서비스들은 종속성을 최소화하고 상태를 갖지 않는 무상태 통신 프로토콜을 제공해야 한다. - 마이크로 서비스들의 존재는 Discovery Service에 등록되어 서비스의 추가와 삭제가 자동으로 감지된다.
장애 격리(Fault Isolation) - 특정 서비스에서 오류가 발생하더라도 다른 서비스에 영향을 주어서는 절대 안된다. (독립성)
Cloud Native Application
: 클라우드 네이티브 아키텍처에 의해 설계/구현되는 어플리케이션을 클라우드 네이티브 어플리케이션이라고 한다. Anti-Fragile이나 Cloud Native Architecture의 특성을 갖고있다.
1. 마이크로 서비스로 개발된다. 2. 개발된 마이크로 서비스들은 CI-CD 시스템에 의해 자동으로 통합/빌드/테스트/배포라는 과정을 거치게 된다. 3. 마이크로 서비스에 문제가 발생 시 바로바로 수정해 다시 배포하는 과정을 반복할 수 있는 형태(DevOps) 가 된다. : DevOps는 시스템의 기획/구현/테스트/배포 과정을 시스템이 종료될 때까지 무한 반복함으로써 고객이 원하는 결과물을 만드는 데 목적을 두고 있다. 4. 어플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포/사용하기 위해 컨테이너 가상화기술을 사용.
Cloud Native Application - CI/CD
지속적인 통합, CI(Continuous Integration) : 통합된 코드를 빌드하고 테스트하는 과정 자체를 의미. - 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구 ex) Jenkins, Team CI, Travis CI 등의 시스템을 통해 Git과 같은 형상관리 시스템에 연동해 사용. (CI 시스템의 파이프라인을 잘 연동하게 되면 소스 변경 후 commit함과 동시 빌드/테스트/실행을 통해 다른쪽 소스 코드에 문제 발생여부를 바로 확인할 수 있다)
지속적 배포(CD) : Continuous Delivery(지속적인 전달), Continuous Deployment(지속적인 배포) 두가지 뜻을 가진다. Git과 같은 소스 장소에 업로드된 코드를 패키지화해 실행환경에 어떻게 배포하는지에 따라 달라질 수 있다고 볼 수 있다. - Continuous Delivery : 패키지화되어 있는 결과물을 실행 환경에 수작업으로 배포하는 과정이 필요한 경우이다. - Continuous Deployment : 운영자, 관리자의 개입없이 실행 환경까지 완벽하게 자동화 배포되는 경우이다. - 시스템을 반영함에 따른 방식은 카나리배포, 블루그린 배포가 있다.
Cloud Native Application - DevOps
- Development와 운영을 뜻하는 Operation이 합쳐진 용어이며 개발조직과 운영조직의 통합을 의미한다. 통합으로 인해 고객의 요구사항을 빠르게 반영해 만족도 높은 결과물을 제시하는 것에 목적을 두고 있다. 엔터프라이즈 어플리케이션은 개발 기간이 길기 때문에 변경사항이나 요구사항에 바로 대처하기 어려운 단점을 보완할 수 있다. 물론 요구사항에 즉각적으로 대처하는건 개발 일정을 더디게 하는 요인이 되지만 긍극적으로 고객의 요구사항에 맞는 프로그램일 개발하는게 목표이기 때문에 문제될 부분은 없다. 따라서 연속적인 테스트/피드백/ 업데이트 하는 과정을 거쳐 전체 개발일정이 완료될 때까지 진행하는 것을 DevOps라고 볼 수 있다.
- 클라우드 네이티브 어플리케이션은 이러한 DevOps를 환경에 맞춰 서비스의 구조를 작은 단위로 분할하여 더 자주 통합/테스트/배포할 수 있는 구조를 만들어 운영할 수 있다.
Cloud Native Application - Contrainer가상화
: 가상화는 Cloud antive Architecture의 핵심이다. 기존 로컬에서 운영하던 시스템을 클라우드 환경으로 이전해 적은 비용으로 탄력성 있는 시스템을 구축할 수 있기 때문이다. 즉 기존의 하드웨어/서버 가상화에 비해 적은 리소스를 사용해 가상화 서비스를 구축할 수 있다.
