클라우드 보안

Pillars of Cloud Native

DevOps

• Dev
  • Plan
  • Code → 여기까지는 Git, SVN, JIRA 같은 툴이 많이 사용된다.
  • Build → Maven, Gradle (최근에는 거의 대부분 Gradle만 사용한다.)
  • Test → JUnit, Selenium
• Ops
  • Deploy
  • Operate → Docker, Vagrant, Ansible, Terraform, Kubernetes
  • Moniter → Nagios, Fluntd, ELK Stack

- Agile: 2001년부터 시작

소프트웨어 프로젝트를 일련의 선형적 순서로 구성하는 Waterfall 방식의 프로젝트 관리 기법의 단점을 보완하기 위해서 등장했다.

→ 큰 프로젝트는 애자일 방법론으로 할 수가 없다. 큰 프로젝트는 데모를 만들기 쉽지가 않기 때문에 Waterfall 방식(피드백 x)을 많이 사용한다.

소프트웨어 개발자 그룹이 애자일 소프트웨어 개발에 대한 선언물을 작성(The Manifesto for Agile Software Development)

반복적인 개발 주기와 자기 조직화 팀을 강조하는 일련의 관행

Agile Manifesto

• 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선한다.
• 작동하는 소프트웨어가 포괄적인 문서보다 우선한다.
• 고객과의 협업이 계약 협상보다 우선한다.
• 변화에 대응하는 것이 계획을 따르는 것보다 우선한다.

- ITIL(IT Infrastructure Library)

1980년대 영국 정부의 CCTA(Central Computer and Telecommunications Agency)에서 IT 인프라 운영의 최고 사례를 모아 발간

2000년대 ITIL v2부터 IT 인프라 운영관리 **de facto(사실상의 표준)**로 전 세계 IT 서비스 기업의 운영 방법으로 자리 잡았다. (ITSM)

2019년 ITIL v4부터 Agile, Lean, DevOps 등의 방법론과의 연계성을 강화한 Service Value System 개념으로 전체 체계를 변환했다.

• DevOps
  • DevOps는 IT 서비스 설계, SW 개발, 릴리즈 및 운영에 이르기까지 전체 서비스 수명 주기에 함께 참여하는 IT 서비스 운영 및 개발 엔지니어의 업무 방식이다.
  • 개발과 운영을 따로 보지 않고 하나로 본다.
  • 팀이 애플리케이션 개발에서 프로덕션 운영에 이르는 전체 프로세스를 소유하는 방법론
  • 일련의 기술 구현을 넘어 문화와 프로세스의 완전한 변화를 요구한다.
  • DevOps는 전체 기능이 아닌 작은 구성 요소에서 작업하는 엔지니어 그룹을 요구해 일반적인 오류 소스인 핸드 오프를 줄인다.
  • DevOps는 소프트웨어 개발과 운영의 합성어로서 소프트웨어 개발자의 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화이다.
  • 소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것이 목적이다.
  • 기술이 아닌 철학이며 변경이 아닌 변화이다.
• Tool Chain
  • 계획(Plan): 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각해 계획한다.
  • Code: 코드 개발 및 검토, 버전 관리 도구, 코드 병합
  • Build: 지속적 통합 도구(CI), 빌드 상태
  • Test
  • Package: 애플리케이션 디플로이 이전 단계
  • Release: 변경 사항 관리, 릴리스 승인, 릴리스 자동화
  • Operate: 인프라스트럭쳐 구성 및 관리, IaC 도구
  • Monitoring: 애플리케이션 성능 모니터링, 최종 사용자 경험
• SOA(Service Oriented Architecture) → Microservice → Functional Microservice
• Agile Teams → DevOps Agile Mindset → Enterprise DevOps
• Cloud Infra Automation → CI/CD → DevOps Automation
• 이점
  • 속도(Agile) - Time to Market, MicroServices
  • 신속한 제공(Delivery) - CI/CD
  • 안정성(Reliability) - 모니터링과 로깅
  • 확장(Scale) - IaC(Infra as Code, 코드형 인프라)
  • 협업 강화(Collaboration)
  • 보안(Security) - Policy as Code(코드형 정책)

Microservices

비즈니스 민첩성

• Amazon 이나 Netflix, Uber를 비롯해 성공한 Unicorn 기업들의 공통된 특징은 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화된 서비스를 제공한다는 것
• 자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선했다.
• 아마존의 배포 속도는 11.6초 정도이고 배포 주기는 1초에 1.5번이다.
• Cloud Infra의 등장으로 가능하다.(참신한 서비스를 가진 스타트업들이 서비스를 빠르게 선보이는데 지대한 영향을 준다.)
• 특정 서비스만 탄력성 있게 확장한다.
• 모놀리식(Monolithic)
  • 하나의 단위로 개발되는 일체식 애플리케이션
  • 보통은 3 Tier라고 사용자 인터페이스와 데이터베이스, 서버 애플리케이션 3개의 부분으로 구성한다. → 하나로 묶어버리니까
  • 서버 측 애플리케이션이 일체 즉 논리적인 단일체로서 아무리 작은 변화라도 새로운 버전으로 전체를 빌드해서 배포해야 하고 애플리케이션은 단일 프로세스에서 실행되기 때문에 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 하는데 보통 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해서 수평으로 확장한다.
  • 변경이 발생하면 이 방식의 단점이 극대화되는데 여러 개의 Monolithic 시스템이 수평으로 확장된 상태이므로 여러 개의 Monolithic 시스템 모두를 다시 빌드하고 배포해야 하고 확장 시 애플리케이션이 병렬로 확장되어 사용량 증가에 대응할 수 있지만 데이터베이스는 통합되어 하나이기 때문에 탄력적으로 대응할 수 없다. → 사전에 성능을 감당하기 위한 스케일 업을 통해 용량을 증설해야 한다.
    • 백엔드 서버는 Scale Out 할 수 있지만 db는 데이터 불일치가 발생할 수 있기 때문에 Scale Out 안하고 Scale Up을 해야 한다.

Micro Service

• 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩되는데 여러 서비스 인스턴스가 모여서 하나의 비즈니스 애플리케이션을 구성하고 각기 저장소가 다르므로 업무 단위로 모듈 경계를 명확하게 구분한다.
• 확장 시에는 특정 기능 별로 독립적으로 확장할 수 있고 특정 서비스를 변경할 필요가 있다면 해당 서비스만 빌드해서 배포하면 된다.
• 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있다.

SOA와 Microservice

• 모듈화 개념의 발전 흐름을 보면 단순히 기능을 하향식 분해해서 설계해나가는 구조적 방법론부터 객체 단위로 모듈화하기 위한 객체 지향 방법론, 모듈화의 단위가 기능 별로 재사용할 수 있는 컴포넌트 개념으로 개발을 하는 CBD(Component Based Development) 등이 등장했고 컴포넌트를 모아서 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)로 이어진다.
• CBD와 SOA도 넓게 보면 단위 컴포넌트나 서비스를 구성해서 시스템을 만드는 개념이고 Microservice 시스템의 구조와 매우 유사하다.
• Microservice 기반으로 시스템을 개발하는 아키텍쳐 및 개발 방식을 Micro Service Architecture(MSA)라고 한다.
  • SOA랑 MSA는 거의 똑같다.
  • SOA는 이론적인 형태이고 Cloud의 등장으로 구체화된 것이 MSA (그냥 용어가 바뀐 거다.)

MSA의 정의

• 여러 개의 작은 서비스 집합으로 개발하는 접근 방법
• 각 서비스는 개별 프로세스에서 실행되고 HTTP 자원 API 같은 가벼운 수단을 사용해서 통신한다.
• 서비스는 비즈니스 기능 단위로 구성하고 자동화된 배포 방식을 사용한다.
• 서비스에 대한 중앙 집중적인 관리는 최소화하고 각 서비스는 서로 다른 언어와 데이터 저장 기술을 사용할 수 있다.
• 특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 가리켜 Polyglot 하다라고 표현한다.
• CBD나 SOA에서는 애플리케이션은 모듈 별로 분리했지만 저장소는 분리하지 못했다.

도입된 2가지 개념

• 서비스 별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화 하는데 다른 서비스의 저장소에 접근하는 수단은 오로지 API 호출이다.
• REST API 같은 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있다.

조직의 변화: 업무 기능 중심 팀으로 전환

• Conway’s low(콘웨이 법칙): Melvin Conway가 제안한 법칙으로, "조직의 의사소통 구조는 그 조직이 만든 시스템 구조에 반영된다." 즉, 사람들이 소통하는 방식이 소프트웨어 구조에도 영향을 준다는 법칙
• 예전에는 하나의 애플리케이션을 만드는데 UI팀, 서버 개발팀, DB팀과 같은 기술별로 팀이 나눠져 있고 하나의 애플리케이션을 만드는데 세 팀간의 의사 소통이 필요하기 때문에 시스템도 이러한 의사소통 구조를 그대로 반영하고 팀 간의 의사결정도 느리고 의사소통도 어려웠다.
• Micro Service를 만드는 팀은 업무 기능 중심의 팀이어야 하는데 업무 기능 중심 팀은 역할 또는 기술 별로 팀이 분리되는 것이 아니고 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것이다.
• 업무 기능 중심팀은 다양한 역할로 구성되고 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 갖추고 있다.
• 이 팀은 같은 공간 같은 시간을 공유하기 때문에 의사 소통도 원활하고 의사 결정도 빠르게 진행될 수 있다.
• 여러 기능들이 모여 있다는 의미에서 다기능 팀이라고도 한다.
• 이 팀은 자율적으로 담당 비즈니스에 관련된 서비스를 만들 뿐 아니라 개발 이후에 운영할 책임까지 진다.
• 아마존에서는 이러한 팀은 two pizza team이라고 표현한다.

관리 체계의 변화: 자율적인 분권 거버넌스, 폴리글랏

• 아마존에서는 다기능 팀이 개발과 운영을 책임진다고 했는데 이러한 조직 문화를 가리켜 You built it you run it. 이라는 모토로 표현하는데 우리가 만들고 우리가 직접 운영한다는 의미이다.
• 중앙의 강력한 거버넌스를 추구하지 않기 때문에 Micro Service 팀으로 구성된 조직은 중앙의 강력한 표준이나 절차 준수를 강요하지 않는다.
• 빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다.
• 자신의 서비스 성격에 맞는 최적의 언어와 저장소를 자율적으로 선택한다.
• 상품팀은 상품 검색 서비스를 위해서 빠른 검색에 특화된 NoSQL인 Mongo DB와 Node.js를 선택했고 계약팀은 계약 서비스를 위해 Java와 Oracle, Redis를 선택한다.

개발 생명 주기의 변화: 프로젝트가 아니라 제품 중심

• 기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였기 때문에 필요한 기술을 사용하는 인력들이 한시적으로 모여 장기간의 프로젝트를 통해 개발을 완료하고 나면 이를 운영 조직에 넘기는 방식으로 진행되어서 개발 조직과 운영 조직이 분리되었다.
• 초기에 모든 일정을 계획했는데 요구사항 정의를 통해 개발할 기능을 나열하고 이에 대한 설계를 진행하고 설계가 완료되면 개발이 진행되고 각 단계는 완료 데드라인이 있어서 그 일정을 완료함으로써 최종 기능을 제공하기 때문에 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못했다.
• Micro Service 팀의 개발은 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발 뿐 아니라 운영을 포함한 소프트웨어의 전체 생명 주기를 책임져야 하기 때문에 소프트웨어를 완성해야 할 기능의 집합으로 보는 것이 아니라 비즈니스를 제공하는 제품으로 바라보고 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어를 개발한다.

개발 환경의 변화: 인프라 자동화

• 배포해야 할 서비스가 여러 개이므로 수동으로 배포하는 방식은 바람직하지 않고 자동화된 배포 방식을 사용한다.
• 코드만 작성하고 업로드를 하면 컴파일, 빌드, 유닛 테스트, 기능 테스트, 통합 테스트, 인수 테스트, 성능 테스트 및 배포가 자동으로 이루어지도록 한다.
• 빌드/배포 파이프라인은 일반적으로 소스 코드 작성 및 수정 → 컴파일 → 빌드 → 개발 환경 배포 → Staging 환경 배포(운영 환경과 거의 동일한 환경을 만들어 놓고 운영 환경으로 이전하기 전에 Security, 성능, 장애 등의 비기능적 부분을 검증하는 환경) → 운영 환경 배포
  • Staging 환경을 거치고 이상 없으면 운영 환경으로 push
  • 개발 환경(기능 테스트) → Staging 환경(비기능적 요소 테스트) → 운영 환경
  • ex. 비밀번호를 넣고 배포하려고 하면 Staging 환경에서 막아줌
• 빌드/배포 파이프라인 프로세스는 도구를 통해 자동화해야 하는데 최근에는 배포환경이 Micro Service 개수에 따라 급격하게 늘어나기 때문에 이를 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식인 IaC가 각광받았다.
• 인프라 구성을 코드로 하게 되면 수많은 하드웨어 리소스 설정을 동일하게 통제할 수 있고 상황에 따른 적절한 설정을 쉽게 복제하고 누구한테나 공유할 수 있게 돼서 인프라를 매우 효율적으로 관리할 수 있다.

저장소의 변화: 통합 저장소가 아니라 분권 데이터 관리

• Monolithic 시스템은 단일 통합 데이터베이스를 사용한다.
• 단일 데이터베이스를 유지하는 방식은 과거 스토리지 가격 및 네트워크 속도에 따른 데이터의 안정성과 효율성을 추구한 결과로 데이터를 잘 정리하는 정규화가 반드시 추구해야 할 가치였지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커져서 데이터를 억지로 꾸깃꾸깃 뭉쳐서 작은 공간에 넣을 필요가 없다.
• Micro Service는 폴리글랏 저장소 접근법을 선택하며 서비스 별로 데이터베이스를 갖도록 설계하는데 각 저장소가 서비스 별로 분산돼 있어야 하며 다른 서비스의 저장소를 직접 호출할 수 없고 API를 통해서만 접근해야 한다.
• 이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요한데 여기서 반드시 등장하는 문제가 바로 각 Micro Service의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제이다.
  • 읽기와 쓰기의 분할: CQRS
  • ex. 회원 가입(쓰기) → MySQL 로그인(읽기) → Mongo DB
• 데이터 일관성 처리를 위해서는 보통 2단계 커밋 같은 분산 트랜잭션 기법을 사용하는데 각각 다른 서비스를 하나의 트랜잭션으로 묶어서 처리하는 것인데 이렇게 묶다 보면 각 서비스의 독립성도 침해되고 NoSQL 저장소는 2단계 커밋을 지원하지 않는 경우도 있기 때문에 Micro Service는 데이터 일관성을 해결하기 위해 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조한다. 이를 가리켜 결과적 일관성이라는 개념으로 표현하기도 하는데 두 서비스의 데이터가 일시적으로 불일치하는 시점이 있고 일관성이 없는 상태지만 두 데이터가 같아진다는 개념이다.
• 여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 각각 수행하고 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성을 맞추는 개념이다.
• ex. 주문 서비스와 배송 서비스가 있고 저장소가 분리되어 있는 경우
  • 주문이 발생하면 반드시 배송 처리가 되어야 하는 비즈니스
  • 두 업무를 2단계 커밋과 같은 분산 트랜잭션 기법을 사용해서 하나로 묶으면 배송 서비스가 실패했을 때 트랜잭션에 포함된 주문 서비스도 함께 rollback 되도록 처리해서 데이터의 일관성을 맞출 수는 있지만 하나의 데이터베이스가 2단계 커밋을 지원하지 않으면 이렇게 하기가 불가능하다.
  • 분산 트랜잭션으로 묶으면 두 서비스가 강하게 결합되어 있어 서비스를 분리한 효과를 누리기 힘들 것이다.
    • 트랜잭션을 분리하고 Queue 매커니즘을 이용
    • 주문 서비스가 주문 처리 트랜잭션을 수행
      • 주문 이벤트를 발행
      • 주문 이벤트가 메시지 큐로 전송
      • 배송 서비스가 주문 이벤트를 인식
    • 배송 서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행
    • 배송 처리 트랜잭션 중 오류로 트랜잭션을 실패
      • 배송 처리 실패 이벤트를 발행
      • 배송 처리 실패 이벤트가 메시지 큐로 전송
      • 주문 서비스가 배송 처리 실패 이벤트를 인식
    • 주문 서비스는 주문 취소(보상 트랜잭션)을 수행

비동기 - 백그라운드

동기 - 포그라운드 (일이 끝나야 할 수 있다.)

위기 대응 방식의 변화 - 실패를 고려한 설계

• 버너 보겔스는 소프트웨어는 모두 실패한다고 말을 했는데 시스템은 언제든 실패할 수 있으며 실패해서 더는 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 한다는 의미로 이러한 성격을 내결함성(fault tolerance)라고 한다.
• 예전의 아키텍처는 무결함이나 실패 무결성을 추구했는데 시스템이 다운되지 않고 중단되지 않기 위해서는 완벽을 추구해야 했고 강건해야 했지만 어떤 시스템도 실패하지 않을 수 없기에 실패하지 않는 시스템을 만드는 것보다는 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이다.
• 다양한 실패에 대해서 완벽히 테스트 할 수 있는 환경을 마련해야 하고 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다.
• 이러한 예로 Circuit Breaker 패턴을 들 수 있는데 이 패턴은 회로 차단기처럼 각 서비스를 모니터링 하고 있다가 한 서비스가 다운되거나 실패하면 이를 호출하는 서비스의 연계를 차단하고 적절하게 대응하는 것을 의미한다.
• 넷플릭스에서는 카오스 몽키(chaos monkey)라는 장애를 일부러 발생시키는 도구를 만들어 이러한 탄력적인 아키텍처가 제대로 동작하는지 점검한다.

MSA의 이해

리액티브 선언: 현대 애플리케이션이 갖춰야 할 바람직한 속성들

• 응답성(Responsive): 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공하는 것, 가치에 해당하는 부분에 유지 보수성과 확장성을 추가하기도 한다.
• 탄력성(Resilient): 장애가 발생하거나 부분적으로 고장나더라도 시스템 전체가 고장나지 않고 빠르게 복구하는 능력
• 유연성(Elastic): 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미하며 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력
• 메시지 기반(Message Driven): 비동기 메시지 전달을 통해 위치 투명성(사용자는 실제 처리가 되는 위치를 몰라도 됨), 느슨한 결합(하나의 서비스가 다른 서비스와 연계는 하지만 하나의 서비스의 중단이 다른 서비스에게 영향을 주지 않도록 결합하는 것), 논블로킹 통신(비동기적으로 통신)을 지향하는 것

강결합에서 느슨한 결합의 아키텍쳐로 변화

• 예전의 아키텍처의 구성 요소들을 각 기업이나 특정 벤더의 제품에 전적으로 의존해서 구축하거나 수정이 필요한 부분만 별도로 직접 개발하는 경우가 많았기 때문에 특정 벤더 솔루션이나 프레임워크가 변경될 경우 그것에 의존하는 애플리케이션의 많은 부분들을 변경해야 할 정도로 강결합 되어 있었다.
• 특정 벤더 중심의 아키텍쳐는 검증된 유명 제품군을 사용한다는 점에서 품질이 보장된다고 할 수 있는 반면, 특정 벤더에 의존한다는 점에서 특정 기술에 Lock In 되어 쉽게 변경하거나 확장하지 못한다는 단점이 있다.
• 최근에는 이러한 분위기를 바꿔 하나의 벤더에 의존하거나 직접 구축할 필요가 적어지는데 Cloud 환경 하에서 사용되는 오픈소스 또는 오픈소스를 기반으로 한 사용 제품들이 이전의 유명 벤더의 제품군만큼이나 품질이 높아지고 다양한 기능을 지원하면서 서로 다른 오픈소스 제품 간에도 충분한 호환성을 제공하기 때문이다.
• 레이어 별로 다른 오픈 소스를 사용한다. → 애플리케이션 개발은 Spring, Jenkins와 SonarQube로 오케스트레이션은 쿠버네티스로 런타임은 도커로 프로비저닝은 테라폼으로 IaaS는 AWS의 ES2로 작업한다.

MSA 구성 요소 및 MSA 패턴

• 인프라 구성 요소: Pulic Cloud, Bear Metal, Private Cloud emd
  • 아키텍트가 할 일은 기존의 물리적인 메탈 장비를 구매해서 구축하느냐 아니면 가상화 환경을 선택해서 이용하느냐 그리고 가상화 환경을 사용한다면 Cloud 사업자가 서비스로 제공하는 퍼블릭 IaaS, PaaS를 선택할 지 또는 직접 구매하거나 기존에 보유한 베어메탈 서버에 Private PaaS를 구축할 지를 고민하는 것이다.

VM과 컨테이너

• VM은 하이퍼바이저라는 소프트웨어를 이용해 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술인 반면 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성하는 것이다.
• 하이퍼바이저는 게스트 운영체제의 명령을 호스트 운영체제의 명령으로 바꾸기 위한 오버헤드가 발생한다.
• 게스트 운영체제의 유무가 차이점인데 게스트 운영체제를 사용하는 가상머신에서는 운영체제 패치 설치나 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생하기 때문에 Micro Service 같은 작은 서비스를 패키지하고 배포하기에는 컨테이너 환경이 더 적합하다.
• 가장 대표적인 컨테이너 기술로는 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 Docker가 가장 유명하고 가장 많이 사용된다.
• 도커 컨테이너는 레이어 단위의 이미지를 포개는 방식으로 구성되며 밑에서부터 애플리케이션 구동을 위한 기반 이미지, 운영체제, 런타임, 애플리케이션이 이미지로 정의된다.
• 도커 컨테이너를 사용했을 때 이점은 이식성, 신속성, 재사용성이다.
• 컨테이너 오케스트레이션
  • 컨테이너를 관리하기 위한 기술
  • 컨테이너가 많아지면 그에 따라 컨테이너의 자동 배치 및 복제, 장애 복구, 확장 및 축소, 컨테이너간 통신, 로드 밸런싱 등의 컨테이너 관리 기능이 필요한데 이러한 기술이 컨테이너 오케스트레이션이다.
  • 컨테이너 오케스트레이션의 도구
    • Docker Swarm, Apache Mesos 등이 있고 최근에는 구글이 자사의 도커 컨테이너 관리 노하우를 CNCF 재단에 제공해서 Kubernetes(k8s)가 많이 사용된다.
  • 쿠버네티스나 AWS 같은 플랫폼 사업자가 제공하는 대부분의 PaaS UI는 시각적인 대시보드를 제공하는데 이곳에서 컨테이너 배포 단위에 해당하는 Pod, Deployment, ReplicaSet 등의 정보를 확인할 수 있다.
• 쿠버네티스가 제공해주는 기능
  • 자동화된 자원 배정: 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에 요청하면 컨테이너를 노드에 맞춰 자동으로 배치한다.
  • 셀프 치유: 컨테이너의 이상 유무를 점검해서 실패한 경우 자동으로 교체하고 재스케쥴링한다.
  • 수평 확장: CPU 및 메모리 사용량이 일정량을 초과하면 자동으로 확장된다.
  • 쿠버네티스는 애플리케이션으로 구현 가능한 일부 Micro Service 운영/관리 패턴을 자체적으로 내장하고 있기 때문에 최근에는 AWS, Azure, Google Cloud 등 자체적인 컨테이너 기반의 PaaS 서비스를 제공하는 CSP 사업자들도 별도로 쿠버네티스 기반의 컨테이너 서비스를 제공한다.

그 밖의 다양한 Cloud 인프라 서비스

• 애플리케이션 형태를 MSA가 아닌 Monolithic 시스템으로 구성하기 위해서는 가상 머신 Cloud 제품군인 AWS의 EC2, Azure의 Web App, Google의 App Engine 등의 PaaS를 고려할 수 있다.

서비스 유형별 대표적인 Cloud 서비스

• IaaS: AWS의 EC2, GCP의 Compute Engine, Azure VM
• CaaS: Azure Kubernetes Service, AWS Elastic Kubernetes Service, Google Kubernetes Engine, AWS ECS
• PaaS: Azure Web App, Google App Engine, Cloud Foundary, Heroku, AWS Elastic Beanstalk

플랫폼 패턴

• 개발 지원 환경: 데브 옵스 환경
  • Micro Service를 빌드하고 테스트 한 뒤 배포할 수 있게 도와주는 개발 지원 환경
  • 개발 및 운영을 병행할 수 있는 조직 또는 그 문화를 일컫는 용어
  • 개발과 운영을 병행 가능하게끔 높은 품질로 소프트웨어를 빠르게 개발하도록 지원하는 빌드, 테스트, 배포를 위한 자동화 환경
  • 자동화된 빌드나 배포 작업을 보통 CI/CD 라고 하며 여기서 CI는 지속적 통합(Continuous Integration)을 가리키는데 원래 지속적 통합은 애자일 방법론 중 켄트 백이 만든 XP(eXtreame Programming)의 주요 Practice로 시작되었으며 오랜 시간이 걸리는 빌드를 자동화해서 개발 생산성이나 소스 코드 품질이 높아진다는 경험에서 출발했다.
  • 개발팀에서 소스 코드를 작성하거나 수정해서 소스 코드 저장소(형상 관리)에 push를 하면 형상 관리 도구 CI/CD(대표적으로 Jenkins) 도구에 pull을 하도록 해서 자동으로 통합하고 테스트 하고 리포트로 남기고(CI) 실행 환경에 자동으로 배포(CD, 개발 환경, 테스트 환경, 스테이징 환경, 운영 환경 모두 포함)
  • 빌드/배포 파이프라인은 통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 절차로 구축하는 것인데 어떤 단계를 거치고 어떤 도구로 그 단계를 구성할지를 결정해야 한다.
  • 레포지토리 → 빌드 및 유닛 테스트 → 정적 분석 → 통합 테스트 → 배포

API Gateway 패턴

• 여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 되면 매우 복잡한 호출 관계가 만들어질 것인데 이러한 복잡성을 통제하기 위한 방법이 필요하다.
• 그 중에 하나가 API Gateway이고 단일 진입점을 만드는 방식이다.

CQRS 패턴

• 읽기와 쓰기 작업을 분리

Containers

Continuous Delivery(CI/CD)