CNCF Day Review; 클라우드 네이티브 환경으로의 전환

CNCF Community Day의 몇가지 세션에 참석하며 메모한 내용을 Archiving한다.

아래 내용의 출처는 모두 원발표자님들께 있으며, 보통 webinar를 들을 때 집중력이 많이 깨지는 편인데 CNCF Community Day의 세션들은 모두 다 재밌었던 내용이라 지루할 틈이 많이 없었다.

Kubernetes korea 유튭 채널에서 공개되어 있으니 틈틈이 하나씩 보시면 될듯

https://www.youtube.com/watch?v=-D0r_b5BRYU&list=PLj6h78yzYM2OO9_EWXS13LxAe-Bkn0xXt&index=2

첫번째 세션 (14:00)

Netflix : 데이터센터 모놀리스에서 클라우드 Kubernetes로 : 클라우드 네이티브로의 성공적인 이전을 위한 전략

Cloud Native 환경으로의 전환이 가지는 장점

• Cloud Native란

  클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다.

  이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다.

  Cloud Native Computing Foundation은 벤더 중립적인 오픈 소스 프로젝트 생태계를 육성하고 유지함으로써 해당 패러다임 채택을 촉진한다. 우리 재단은 최신 기술 수준의 패턴을 대중화하여 이런 혁신을 누구나 접근 가능하도록 한다.

  (출처 : https://github.com/cncf/toc/blob/main/DEFINITION.md#%ED%95%9C%EA%B5%AD%EC%96%B4)

• Cloud native 환경의 목적

  Cloud native 환경의 이상향은.. 몇가지 조건이 있다

  • Predictable: 변화에 대한 예측이 가능하고
  • Immutable and disposable : 변경이 불가능하고 / 파기가 가능하며
  • CI/CD : 지속적인 packaging, testing, deploy가 가능하고
  • Observable: 변경사항에 대한 감시가 이루어질 수 있는 인프라 환경 등의 조건을 만족하면 된다.

• 고려하는 원칙에 관한 링크는 아래에! The twelve factor app이라고 한다.

  https://12factor.net/ko/

• Cloud native에서 제시하는 방향성을 잘 따라가는 인프라 스트럭쳐인 Kubernetes를 이용해 Cloud Native 환경을 주로 구축한다.

• 참고할만한 도서

  DDD distilled / DevOps handbook / Team Topologies

Considerations

• 현재 기능들은 유지한 채, 데이터센터의 인프라를 클라우드를 이전하고, 모놀리스를 해체해 작은 서비스들로 전환하고,
• 동시에 오래 간 쌓여 온 Tech debt를 청산하고,
• 새로운 기슬 스택을 적용하며
• 동시에 데이터 누락/손상 있으면 안되고
• 이 모든 이전 작업 동안 user들에게 악영향을 줘서는 안된다

(보잉 747기가 날면서 동시에 엔진을 교체하는 작업으로 종종 비유됨)

Cloud native 환경전환에 관한 여러가지 방법론

Big Bang Rewrite 방법론

(처음 접근한 방법론)

Strangler Fig Pattern

데이터센터 모놀리스를 과거의 영광, 클라우드의 마이크로서비스를 밝응ㄴ 미래로 보고 현재 컴포넌트를 클라우드 네이티브에 맞게 처음부터 새롭게 작성한다는 방법론 적용

단점

• 생각보다 오랜 시간 / 리소스 사용

• 기존의 기능이 100% 동작할지 테스트 어려움

• 장시간의 인프라 공존

• 종료시점의 예측이 어렵다

• 참고할만한 링크: microservices.io

교살자 무화과 나무.. 라는 무시무시한 뜻이 있음(새들이 씨를 먹고 변을 보면 거기서 씨가 자라 원래 숙주나무를 말라죽게 해서 숙주나무를 죽게한다는 background가 있음)

• 기존의 시스템에 새로운 기능을 추가하는 것을 중지하고
• 점진적으로 새로운 시스템을 구성하며, 새로운 시스템에 기능이 추가됨에 따라서 기존의 시스템에서 조금씩 기능을 삭제하는 방식 (해체하기 쉬운 작은 단위의 서비스부터..~ )

Infra Migration Strategy

Lift and Shift

• (지게차로 옮기듯이) 기존의 모놀리스를 그대로 docker로 패키징해서 새로운 쿠버네티스에 옮겨가는 방식
• 중요한 것은 이제 Database migration인데, DB는 계속 transaction이 있기 때문에 어떻게 이전하는지가 중요함 (많은 곳에서는 DB 미러링 등의 방법 해결)
• 기존으로 가던 트래픽을 잘라서 Request router를 통해 모든 request를 새로운 데이터센터로 받으며, 기존의 monolith를 kill
• 장점 : 기존의 monolith를 deprecate 시키는 시간이 짧게 들음
• 단점 : 심플한 인프라 스트럭쳐에만 가능하다는 한계가 있음

Hybrid infrastructure

• Request router를 통해 트래픽을 조절하며 (초기 : request분배 / 나중 : 클러스터에만 request)
• 새로운 feature를 조금씩 추가할 수 있다는 장점이 있음
• 두 다른 인프라를 사이에 캐시 레이어를 두고 퍼포먼스 / 최적화 전략으로 여유있게 migration할 수 있음

Tips & Tricks

Microservice Chassis를 활용하기

Centralized / bootstrapping

• Code generator / sdk
• Basic docker config
• Automate instrumentation

등의 툴 들을 제공함으로서 개발자들이 logging / metrics 등을 신경쓰지 않아도 되도록 함

Release with confidence!!

• 프로덕션 릴리즈 전에 꼭 로드테스팅을 시행하기

• Public cloud/ kubernetes 100% 활용하기

  • Spot instance를 활용해 kuber의 affinity를 활용해 중요한 pod들은 long-lived node에 배치하고(ingress, dns..)

    https://github.com/kube-aws/kube-spot-termination-notice-handler

• Kubernetes cluster 내부의 캐싱을 적극 활용하기

괜찮았던 Q&A 메모

Q: 저희도 모놀리스에서 MSA로 상당수 전환은 하였는데, 개발자 인원이 적어서 그런지 오히려 한 사람이 많은 repository를 담당하게 되는 불편함도 생겼습니다. MSA에서 개발 인원이 부족하다면 어쩔 수 없는 문제일까요?

A: 사실 개발인원은 아주 적더라도 필요에 따라서 MSA를 사용할 수 있을 것 같아요. 문제는 현재 불필요한 도메인이 너무 많거나, 각 서비스들의 커플링이 너무 심하면, 각 마이크로서비스의 독립성을 보장할 수 없을 때 생기는 문제 일 수 있을 것 같아요

예를들어 10명의인원이 50개의 마이크로서비스를 관리할 때, 이 모든 마이크로서비스를 계속 개발/관리/유지보수를 해야 하는 상황이면 힘들겠지만, 실제로 개발하거나 특별한 상황이 없을 때 손 봐야 할게 2~3개 정도면 지속적으로 관리 가능한 아키텍쳐라고 볼 수 있는것 처럼이요 😄

Q. 개인적으로 distributed monolith가 되는 경우를 경험하게 되었는데요, (micro services architecture 이지만 coupling이 너무 강한...) 새로운 마이크로 서비스가 생기거나 새로운 도메인이 만들어진다고 할 때, 내부적으로 검증? 토론? 결정? 프로세스가 있나요?

A. 아 맞습니다. 그게 마이크로서비스 구성에 가장 흔히 일어나는 실수같아요. 보통은 데이터베이스 디펜던시를 잘라내지 못하고 여러가지의 서비스들이 종속이 되다보면 대표적으로 이런일이 발생하기 때문에.. 가장 좋은 방법은 DDD에서 제시한 것과같은 도메인에 따른 데이터베이스 분리/ Saga 도입 같은것들이 중요한 것 같아요. microservices.io/patterns/data/saga.html

예를들면 Netflix같은 경우에는 Memo문화가 잘 되어있어서 자신이 프로젝트를 끌고가는 사람이라면 (Informed Captain) , 이 사람이 자신의 서비스에 영향을 받을 수 있는 사람을 자유롭게 포함시켜서 합의를 이루는 방식이 많은 것 같아요.

Netflix나 제가 전에 있던 Zillow의 경우에는 SAR (Security & Architecture Review) 세션이 있어서, 새로운 서비스가 필요하면, 각 팀내의 스테익홀더를 포함해서 리뷰를 진행하게 되어있었어요

대체로 꼭 lead급 만 하지 않고, 주니어라도 언제든지 참여할 수 있다는 점이 좋은 점 같아요. 이건 Netflix, Zillow둘다 해당사항입니다.