[IBM Cloud] Building Cloud Native and Multi-cloud Applications

2021. 1. 21. 05:12IBM C:LOUDERs

728x90

학습목표

  • 클라우드 네이티브와 멀티클라우드의 동작과 컨셉을 이해하기
Microservice
DevOps
CI/CD
Docker
Kubernetes
Openshift


클라우드 네이티브란 ?

  • 클라우드 컴퓨팅 제공 모델의 이점을 활용하는 애플리케이션 구축 및 실행 접근 방법
  • 핵심은 "App을 어떻게 만들고/배포하는지에 있으며" , 위치는 중요하지 않다.
  • 그렇기 때문에 아래의 4가지 핵심요소가 필연적으로 수반된다.

클라우드 네이티브가 뜨게 된 이유, 그리고 클라우드 네이티브의 의미를 찾기 위해서는 역사를 봐야한다.


시스템 관리 방법의 진화

1. 정적인프라 2. 동적인프라 3. 컨테이너
과거의 서버는 하드웨어와 한몸을 이루고 있습니다. 
HW에서 설치된 OS,M/W 등에 종속되었고, 그 위에 올려진 서버는 한번 생성되면 변경되기 어려운 점을 지니고 있습니다.
Hypervisor의 등장으로 정적인프라의 단점을 탈피할 수 있었습니다.
HW위에서 구현되었던 기술을, OS가상화 기술을 통해 SW(코드)로써 구현함으로 HW에서 분리될 수 있었습니다.
(HW 종속성, 의존성 해체)
그럼에도 불구하고, OS(커널)은 매우 무겁기 때문에, 재기동에 오래걸립니다.
컨테이너는 프로세스를 가상화 함으로써 , 더욱더 자유도가 높고 어디에는 실행/배포가 가능합니다.

 

 

컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(1/3)

클라우드 네이티브 컴퓨팅에 대한 내용을 요약하여 공유 합니다. 길이가 길어 총 3편으로 나누 었습니다 1편 : 컨테이너 기반의 클라우드 네이티브 컴퓨팅 시대 도래(지금 글)2편 : DevOps 컨테이너

itchain.wordpress.com


 

Module 1 - Cloud Native and Multicloud Concepts and Goal

  • Cloud Native의 목표는 Microservice Architecture 주체를 중심으로 구성된 느슨하게 결합된 시스템을 지원하는 설계 패턴, 패러다임 및 기술을 채택하는 것
  • 프로세스를 사용하여 자동화됨, 여러 클라우드 환경에서 쉽게 작동 가능 또는 관리 가능, 모든 애플리케이션 개발 라이프사이클 단계에서 관찰 가능, 운영 장애에 대한 탄력성 등을 제공
  • 컨테이너 기술을 통해 , OS의 종속성이 사라짐 ( OS 가상화 ) 

  • 컨테이너의 워크로드는 Kubernetes, OpenShift 관리 플랫폼을 통해 스케줄링, 조정 할 수 있습니다.
  • CNA(Cloud Native App)은 기존의 App과는 다릅니다.
    • App의 Runtime을 아래로 내립니다 --> Micro Service
    • 이 Runtime에는 Load Balance, API, Log 등이 포함됩니다.
    • 따라서 신속하게 변화하고, 확장된 개발이 가능합니다.

  • 변화와 혁신을 강조하려면 신속하게 제공해야합니다.
  • 이러한 지향은 Agile이라고 하며, Scrum과 Kanban을 포함합니다.
  • Agile은 변화에 대응하는데 우선순위를 둡니다.

  • 그러다보니 개발자의 코드는 자주 변경될 수 있습니다.
  • CI : 변경된 소스코드를 관리하고 그러한 지속적인 시스템을 말합니다.
  • CD : Delivery와 Deployment가 연결되는것으로 간주하는 경우가 꽤 있습니다.
Release (출시) : 하나이상의 변경된 서비스로, 예를 들어 2.2.1 ver to 2.2.2 ver 같은 것이 있다 ( ISO 20000 정의)
- 방법은 2가지가 있습니다.
-- 카나리 : 일부 사용자에게만 릴리즈
-- 다크런칭 : 알게 모르게 잠수 업데이트
Deploy (배포) : 환경을 migration 하는 것. 환경의 예로, 개발환경,테스트환경,스테이징환경(실데이터),프로덕션 환경이 있다
- 배포의 방법으로는 과거에는 빅뱅방식(한번에 퇑 !) 했지만, 요즘은 blue-green 방법이 있다. ( 서서히 서비스 전환 )
 

Deploying vs Releasing Software: What’s The Difference?

BMC Software

www.bmc.com

 

개발환경에 대한 이야기
 

개발 환경(dev,stage,qa,production)

서버 개발을 가정하고, 먼저, 개발 및 운영에 사용할 서버를 어떻게 배치 해야할지를 살펴보자 일반적인 서버 개발환겨은 아래와 같이 local,dev,integration,qa,staging 그리고 production 환경을로 나뉘어

bcho.tistory.com

Orchestration : 배포와 운영에 자동화된 "동적관리"를 한다
- 스케줄링 : 가용량에 따라 자원 할당
- 컨트롤링 : 상태 유지
- 자가복구 : 재기동
- 오토스케일링 : 수평적 스케일 ( scale-out ). 늘림
- 롤링 업데이트 : 서비스에 영향없이 컨테이너 업데이트

모니터링 : 오케스트레이션 하려면 기준이 있어야겠죠? 측정 합니다.
Micro Service : 측정하고 스케일 아웃하기에는 딱이죠?

 


Module 2 - Migrating Apps to Advantage Cloud Infrastructure

 

SOA : Service Oriented Architecture


  • Language Runtime : Cobol와 같은 Legacy 언어도 지원할 수 있다

 

  • VM 은 덩어리가 커서, Load, Restart 할 때 느릴 수 있습니다. 또 물리적인 리소스를 많이 사용합니다.
  • Namespace로 프로세스를 추상화/격리하고
  • Cgroup으로 물리자원을 제한하고 분리합니다.
  • 이러면 더 가벼워 집니다.

  • 모든 App의 핵심은 Data 입니다.
  • 다양한 지역의 고객을 위해 컨텐츠 제공 속도를 개선합니다. 에지 서버에 클라우드 기반 CDN(Content Delivery Network)을 만들 수도 있습니다.
  • API 게이트웨이 기능을 활용하여 다양한 소비자 및 비즈니스 역할에 대한 데이터 액세스를 보호하고 제어할 수 있습니다
  • 제공업체는 모든 고객 "개인 식별 정보"(PII)의 취급을 규정하는 날로 진화하는 정부 개인정보 보호법을 준수해야 합니다.
  • 네트워크를 통해 "이동 중"이고 스토리지 장치에서 "정지 중"인 동안 강력한 암호화 방법을 통해 데이터 전송이 보호되어야 합니다.대상 장치의 원본 장치에서 데이터가 전환될 때 "보관 체인"을 추적하는 감사 가능한 문서도 제공되어야 합니다

Module 3 - Modernizing Applications to be CN

  • Monolithic은 재사용과, 장기적 유지보수가 어렵고, 운영이 취약해짐
  • MSA는 OpenAPI(Swagger) 표준을 사용함

  •  Event Interception : “Tapping” into events at the data services layer correct

리액티브 : 데이터 흐름을 먼저 정의하고 데이터가 변경되었을 때 연관되는 함수나 수식이 업데이트되는 방식
기존 pull 방식의 프로그래밍 개념을 Push 방식으로 바꿈
기존의 명령형 프로그래밍 (Pull 방식)
컴퓨터 하드웨어를 대상으로 프로그래머가 작성한 코드가 정해진 절차에 따라 순서대로 실행된다.

예를 들어, 편의점의 연간 매출액을 구하려고 했을 때 특정 월 매출액의 값이 늘거나 줄었을 경우 기존의 명령형 프로그래밍에서는 Pull 방식으로 새롭게 바뀐 데이터와 함께 기존에 변경되지 않은 월 매출액들을 모두 조회하여 처음부터 계산할 것입니다. 그러나 리액티브 프로그래밍에서는 Push 방식으로 새롭게 바뀐 데이터만 기존에 구성한 수식에 전달하여 더욱 효율적으로 계산 가능합니다.

출처: https://juyeop.tistory.com/40 [글 쓰는 개발자의 꿈]
 

리액티브 프로그래밍 소개

안녕하세요, 오늘은 어려울 수도 있는 주제인 RxJava에 대해서 여러분들께 소개하려고 합니다. RxJava는 리액티브 프로그래밍에 속하며 지금까지와는 달리 새로운 관점으로 이를 살펴보아야 합니

juyeop.tistory.com

서버리스 : 함수는 실행 요청이 있을 경우 혹은 특정 이벤트가 트리거(trigger) 할 경우 클라우드에서 실행될 수 있다

서버리스 컴퓨팅은 클라우드컴퓨팅의 한 실행 모델이며 실행에 필요한 하드웨어 자원의 배분 및 할당을 클라우드에서 동적으로(dynamically) 관리해 주는 것이다. 애플리케이션이 실제 사용한 자원 분량에 대해서만 과금되어 미리 확보해 놓은 자원에 대해 과금하는 기존 클라우드 방식과 대비된다.

FaaS(Function as a Service)라 부른다. 애플리케이션 개발자는 각각의 함수를 개발하여 클라우드에 업로드한 후 필요할 경우 호출만 하면 된다. 클라우드상에서 서버를 할당받고, 확장하고, 데이터베이스를 따로 관리하는 등의 백엔드에서 필요한 작업을 전혀 신경 쓸 필요가 없다.

모노리식 아키텍처가 서버 가상화 수준에 적합하다면, 마이크로서비스는 컨테이너 오케스트레이션이 중요하며, 서버리스 아키텍처의 경우 컨테이너 오케스트레이션 수준보다 더 작은 단위의 함수관리(function handler)기능이 필요하다.



Module 4: Applying CI/CD to CN application

 


Module 5: Managing Applications in Multicloud Deployments