IT 환경의 변화
1. 개발 방법
1) 폭포수(Waterfall) 이론 ( ~2000년대)
- 가장 고전적인 소프트웨어 개발 방법. 순차적으로 꼼꼼한 점검을 통해 프로그램을 개발이 특징.
- 고객의 요구사항에 매우 둔해 개발기간이 길어진다는 단점이 있다.
2) 애자일(Agile) 이론 (2000년대~)
- 폭포수 이론을 보완, 신속한 반복 개발을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 방법론.
- 고객의 대응에 매우 신속하여 고객 만족도를 높인다.
- 서류 작업에 대해 많은 시간을 소모한다.
3) DevOps (2010~)
- 개발과 운영이 하나된 조직과 프로세스를 가진 방식.
- 개발자는 IT 운영 담당자와 협력하여 소프트웨어 빌드, 테스트, 출시 속도를 가속화 한다.
- DevOps의 핵심은 자동화이다.
2. Application Architecture
1) Monolithic ( ~2000년대)
- 개발의 모든 소스코드를 하나의 파일로서 관리하고, 단일 배포하는 방식이다.
- (장점) : 소스코드가 통합되어 있어 배포가 간단하고 개발 환경이 통합되어 있으며 네트워크에 의한 지연이 없다.
- (단점) : 프로젝트가 커질 경우 내부 함수 및 패키지 종류가 너무 많아져 오히려 유지보수가 어려워지고 성능이 저하될 수 있다.
- (단점) : 하나의 언어나 프레임워크에 종속될 가능성이 크다.
2) N-Tier (2000년대~)
- 소프트웨어를 여러 계층으로 나누어 설계하는 구조. 각 계층 별로 담당하는 역할이 다르다.
- Presentation / Application / Data / Service Layer로 나뉜다.
- (장점) : 모듈화를 통한 확정성과 재사용성이 좋고 유지보수가 간편하다.
- (단점) : 모듈이 많아지면 전체 시스템의 복잡성이 증가할 수 있고, 모듈 간의 통신에서 네트워크에 의한 지연이 발생할 수 있다.
3) MicroService (2010~)
- 독립적인 서비스들의 모음이 경량화된 API를 통해 통신하는 구조이다.
- 아래의 그림을 예시로 설명하자면, 마이크로서비스는 기본적으로 UI를 통해 상호작용을 하고 관련된 마이크로서비스를 API를 통해 가져와 해당 서비스의 핵심 기능만 독립적으로 작동하도록 설계한다.
3. Deployment & Packaging
1) 물리 서버(Physical Server) (~2000년대)
- 물리서버는 실제 하드웨어를 기반으로 한 서버이다. 말 그대로 서버 룸이나 데이터 센터에 설치된 물리적인 기계이다.
- (장점) : 성능을 쉽게 파악할 수 있고, 특정 요구에 맞춰 서버를 커스터마이징이 가능하며, 서버가 물리적으로 분리되어 있어 상대적으로 보안에 유리하다.
- (단점) : 설치에 비용이 많이 들고 서버 추가 및 확장에 물리적인 공간과 장비가 추가적으로 필요하여 확장성과 유연성이 낮은 단점이 있다.
2) 가상 서버(Virtual Servers) (2000년대~)
- 하나의 물리 서버에서 가상 서버 인스턴스를 생성하여 사용하는 방식이다.
- 하이퍼바이저를 통해 하나의 물리 서버를 여러 개의 가상 서버로 나누어 사용한다.
- (장점) : 하나의 물리 서버에 여러 가상 서버를 생성하여 사용하므로 효율성, 유연성과 비용 절감에서 효율적이다. 또한 가상 서버 자체에서 스냅샷을 지원하므로 백업과 복구가 쉽다.
- (단점) : 하나의 물리 서버를 나누어 사용하므로 성능 저하가 되기 쉽고, 가상 서버에 대한 보안 문제가 발생한다. 가상화를 위한 추가적인 도구가 필요하므로 관리 복잡성이 증가한다.
3) Containers (2010~)
- 하나의 물리적인 장비 위에 소프트웨어실행에 필요한 운영체제, 리소스 등을 하나로 묶어 실행할 수 있도록 만든 환경
- 기존의 환경에서 소프트웨어 실행하기 위해서는 개발/운영/테스트의 환경이 모두 다르다. 그러나 container로 만들어 사용하게 될 경우 환경을 다르게 만들 필요 없이 하나의 container에서 수행할 수 있다.
=> 개발 = 운영 구조로 만들어줌
- 외부적인 요인에 전혀 영향을 받지 않고 프로그램을 실행할 수 있다.
ex) docker
4. Application Infrastructure
1) 데이터센터 (Datacenter) (~2000년대)
- 대규모의 자원과 인프라를 물리적으로 보관하고 있는 시설이다.
- (장점) : Depolyment & Packaging과 마찬가지로 보안과 확장성에서 장점이 있다. 통제가 쉽고 고성능 하드웨어와 최적화된 네트워크를 구축하고 있어 높은 성능과 안정성을 제공한다.
- (단점) : 물리적으로 구축해야 하기 때문에 초기비용이 높고 유연성과 운영 복잡성이 부족하다.
2) 호스팅 (Hosted) (2000년대~)
- 서버나 앱을 외부 서비스 제공자에게 맡기는 방식
- (장점) : 외부의 자원을 빌려 사용하는 것이기 때문에 초기 구축 비용이 없고 관리와 유지보수가 편리하며, 유연성과 확장성이 확보된다.
- (단점) : 같은 의미에서 외부 자원을 빌려 사용하는 것이기 때문에 보안 및 서비스의 성능에 대한 통제가 부족하고, 외부 서비스 제공자에 의존성이 생길 수 있다.
3) Cloud (2010~)
- 클라우드 서비스는 제공업체가 인터넷을 통해 사용자에게 제공하는 인프라, 플랫폼 또는 소프트웨어를 말한다.
- 인터넷이라는 네트워크를 통해 타사의 가상화된 다양한 자원들을 빌려쓰고 사용한 만큼 비용을 지불한다.
- 클라우드 서비스를 통해 자원을 효율적으로 관리할 수 있게 하고, 클라우드 네이티브 앱 구축과 클라우드 내에서의 작업 유연성을 증가시킨다.
위 내용을 정리하여 도식화하면 아래와 같이 표현할 수 있다.
5. 리액티브 선언문 (The Reactive Manifesto)
- 현대 애플리케이션이 갖춰야 할 바람직한 속성들
- 응답이 잘되고 탄력적이며 유연하고 메시지 기반으로 작동하는 시스템을 리액티브 시스템(Reactive System)이라고 한다.
1) 응답성 (Responsive)
- 시스템이 가능한 한 즉각적으로 응답하는 것.
- 응답성이 있다는 것은
신속하고 일관성 있는 응답 시간을 제공,
신뢰할 수 있는 상한선을 설정하여
일관된 서비스 품질을 제공한다.
2) 유연성 (Elastic)
- 시스템의 작업량이 변화하더라도 응답성을 유지하는 것.
- 시스템에서 병목 현상이 발생하지 않도록, 구성요소를 샤딩하거나 복제하여 입력을 분산시키는 것을 의미한다.
3) 탄력성 (Resilient)
- 시스템이 장애 상태에 빠지더라도 응답성을 유지하는 것.
- 탄력성은 복제 / 봉쇄 / 격리 / 위임에 의해 실현된다.
4) 메시지 구동 (Message Driven)
- 리액티브 시스템은 비동기 메시지 전달에 의존하여 구성요소 사이에 느슨한 결합 / 격리 / 위치 투명성을 보장하는 경계를 형성한다.
- 명시적인 메시지 전달은 시스템에 메시지 큐를 생성하고, 모니터링하여 필요시 배압을 적용함으로 유연성을 부여, 부하 관리 및 흐름제어를 가능하게 한다.
클라우드 네이티브
1. 정의. CNCF(Cloud Native Compution Foundation) Cloud Native Definition v1.0
- 클라우드를 사용하는 이유는 "자원을 효율적으로 활용하기 위함"이다.
- 클라우드 네이티브 기술은 조직이 public / private / hybrid 클라우드 환경에서 확장 가능한 앱을 개발하고 실행할 수 있게 해준다.
ex) Container, Service Mesh, Microservice, Immutable Infra (불변 인프라), Declarative API (선언형 API)
- 회복성 / 관리 편의성 / 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다.
- 클라우드 이민 (Cloud Immigrant) VS 클라우드 네이티브 (Cloud Native)
* 클라우드 애플리케이션 성숙도 단계
2. 구성요소 및 원칙
1) 마이크로서비스 (Microservice)
: 애플리케이션의 민첩성과 유지&관리 편의를 위해 기존 monolithic architecture를 작은 기능 단위인 서비스로 분리하고 API를 통해 서로 소통할 수 있게 하여 독립적으로 개발/배포/운영을 가능하게 한다.
- 주요 특징 :
소규모 서비스
독립적 서비스 운영
다영한 언어 및 기술 적용 (Polyglot)
유지보수 용이
2) 컨테이너 (Container)
: 어떠한 클라우드 환경에도 즉각적인 배포가 가능하도록 확장성과 이식성이 필요하며 이를 위해 기존의 서버보다 훨씬 가벼운 프로세스 수준의 가상 서버, 컨테이너를 마이크로서비스의 배포 및 실행 환경으로 제공한다.
- 주요 특징 :
효율적 개발환경 구축
경량화
높은 이식성
확장성
3) 데브옵스 (DevOps)
: 클라우드 네이티브 환경에서는 하나의 대규모 릴리스 및 업데이트를 기다리는 것이 아닌 수많은 마이크로서비스 중 변경되는 서비스들이 하나의 배포 단위로 앱을 쉽게 출시할 수 있다.
- 주요 특징 :
서비스단위 개발 및 운영 조직의 협업
신속한 서비스 개발 및 배포
4) CI/CD (Continuous Integration / Continuous Delivery or Depolyment)
: 수 많은 마이크로서비스 개별 팀에서 수시로, 빠른 속도로 변경하기 위해서는 클라우드 플랫폼내에 개발, 배포 프로세스의 자동화가 필요하다.
- 주요 특징 :
프로세스 자동화
소규모 서비스 단위 배포
1) 애자일 방법론 (Agile Method)
: 사용자의 요구사항을 신속하게 반영하기 위해 개발주기를 짧게 설계하여 빠르게 프로토타입을 개발, 사용자의 피드백과 방향성을 확인하고 지속적인 개선 작업을 짧은 주기로 반복하는 개발 방법론이다.
- 클라우드 네이티브와의 공통점은 작은 서비스 단위로 사용자의 요구사항을 지속적 & 반복적으로 반영하여 개선을 수행한다는 것이다.
- 주요 특징
사용자와 개발자의 지속적인 소통을 통해 요구사항을 신속하게 수용
팀의 목적과 사용자의 의견을 중요시
내부 구조 개선을 통한 품질 향상과 비용 절감을 목표
팀원들과의 의사소통
개발 과정에 지속적으로 사용자의 피드백을 받음
2) 12가지 요소 (12 Factors)
: 2012년 헤로쿠(Heroku)에서 일하던 개발자들이 클라우드에 적합한 SaaS 앱 개발과 배포에 맞는 12가지 원칙을 개념화한 것이다. 클라우드 환경에 적합하게 적용되어야할 부분과 지켜야할 부분을 원칙으로 정의하고, 클라우드 네이티브 앱 개발시 이 원칙을 준수해야 한다.
(1) 코드베이스 (Codebase)
- 하나의 코드베이스(소스코드)로 버전관리하며, 이를 여러 곳에 배포한다.
(2) 종속성 (Dependencies)
- 패키지, 라이브러리 등 종속이 필요한 경우 명시적으로 선언하고 분리시켜 실행 환경의 종속성 제거
(3) 설정 (Configuration)
- 소스 코드와 설정 정보를 분리, 실행 시 코드에서 읽어서 사용한다.
- 설정 정보가 없어도 실행은 가능하다.
(4) 백엔드 서비스 (Backing services)
- 앱 작동에 필요한 서비스 (DB, 메시지 큐, 캐시 등)를 연결된 리소스 취급하여 연결과 분리가 용이
(5) 빌드 / 릴리즈 / 실행 (Build / Release / Run)
- 빌드 / 릴리즈 / 실행 단계를 엄격히 분리한다.
(6) 프로세스 (Process)
- 앱 실행 시 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행
* 무상태 : 함수 등
(7) 포트 바인딩 (Port binding)
- 앱은 독립적이고, HTTP 같은 포트 바인딩을 통해 외부에서 서비스를 제공한다.
(8) 동시성 (Concurrency)
- 앱을 수평적으로 확장하며, 무상태 특성이 이런 확장을 단순하게 만든다.
(9) 폐기기능 (Disposabillity)
- 빠른 시작과 안정적인 종료(graceful shutdown)을 통한 안정성을 극대화한다.
(10) 개발 / 운영환경일치 (Dev / Prod parity)
- 개발 / 검증 / 운영 환경을 가능한 비슷하게 유지함으로써 지속적인 개발 및 배포를 가능하게 한다.
(11) 로그 (Log)
- 로그 파일을 이벤트 스트림으로 취급하여 이를 취합, 인덱싱, 분석할 수 있어야 한다.
(12) 운영관리 프로세스 (Admin process)
- 시스템 관리 작업은 필요 시에 프로세스를 만들어서 실행한다.
3. 클라우드 네이티브 도입 효과 및 적용 사례
장점 1. 마이크로 서비스별 독립적 서비스 운영
장점 2. 탄력적 시스템 운영
장점 3. 마이크로서비스 중심의 효율적인 조직 구성
- 각각의 마이크로서비스는 소규모 개발 및 운영 팀에서 독립적으로 개발 및 배포가 가능하다.
장점 4. 데브옵스 및 CI/CD에 의한 개발 기간 단축
장점 5. 작은 서비스 단위의 신속한 요구사항 반영
장점 6. 컨테이너를 활용한 이식성 확보
단점 1. 마이크로서비스의 분산에 따른 아키텍처 복잡성 증가
- 서비스 분산으로 인한 관리 포인트 증가
- 복잡성 증가로 인한 전체적인 구조 파악 어려움
- 분산 시스템 추가 시 고려사항 증가 (네트워크 대기 시간 / 내결함성 / 직렬화 등)
단점 2. 분산 데이터베이스에 의한 중복 발생
- 중복 데이터 저장 필요 (반정규화)
- 데이터의 일관성 깨짐
- 멀티 데이터베이스에 대한 트랜잭션 처리 필요 & 이에 대한 여러움 증가
단점 3. 잦은 빌드 및 배포 시 보안위험 노출
단점 4. 클라우드 특정 서비스에 대한 종속성
* 도입 효과
: 애플리케이션 배포 속도가 160% 향상
서버 자원 사용량 80% 감소
서비스 롤백/장애 복구 시간 1/3로 감소
커뮤니케이션 비용 70% 감소
Spring Cloud
- 마이크로서비스의 개발, 배포, 운영에 필요한 아키텍처를 쉽게 구성할 수 있고, MSA 를 지원하는 스프링 부트 기반 프레임워크
- 클라우드 네이티브 패턴 중 일부에 집중하여 다양한 라이브러리를 제공하는 스프링 부트를 확장하며, 분산시스템에서 일반적인 패턴을 빠르게 조합할 수 있도록 해준다.
1. 주요 특징
1) 분산 및 버전 설정 관리 (Distributed / versioned configuration)
2) 서비스 등록 및 조회 (Service registration and discovery)
3) 라우팅 (Routing)
4) 서비스 대 서비스 호출 (Service-to-service calls)
5) 서비스 분산 로딩 (Load balancing)
6) 서비스간 호출 분리, 서킷 브레이커 (Circuit breakers)
7) 글로벌 락 (Global locks)
8) 리더십 선출 및 클러스터 상태 (Leadership election and cluster state)
9) 분산 메시징 (Distributed messaging)
정적 & 동적 분석
1. 정적 분석
- 실행하지 않은 상태에서의 분석. 소스코드와 구문에 대해서 오류를 찾고 수정한다.
ex) 코드 분석
2. 동적 분석
- 기본적으로 실행이 포함되어 있다. 작성한 코드에 대해서 원하는 실행결과가 나오는지 확인하는 작업.
ex) debug, 부하 테스트
CI/CD (Continuous Integration / Continuous Delivery or Depolyment)
- 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법.
- 개발 및 운영팀에서 발생할 수 있는 문제(=통합지옥)을 해결할 수 있는 방법이다. 단어 뜻대로 지속적인 통합 / 전달 / 배포가 핵심이며 이를 구축한 것을 "CI/CD 파이프라인"이라 한다.
ex) GitHub action, 젠킨스
소프트 웨어 확장 큐브
Polyglot
: 마이크로서비스별로 고유한 언어와 기술요소 적용이 가능하므로, 실험적으로 새로운 기능을 적용해보고 다른 마이크로서비스로의 변경이 가능함을 말한다.
'Study > seSAC 금천 4기' 카테고리의 다른 글
| 컨테이너 애플리케이션 개발_1일차_240912 (1) | 2024.09.26 |
|---|---|
| 네트워크 및 시스템 관리_1일차_240910 (0) | 2024.09.25 |
| React를 활용한 B/E API 통합_1일차_240813 (1) | 2024.09.18 |
| 개발환경 구축하기 (2) | 2024.09.14 |
| SeSAC 특강 - 이노그리드 운영본부 이사님_240912 (0) | 2024.09.12 |