클라우드 네이티브

 

총평

클라우드가 보편화된 시대에 클라우드에 적합한 어플리케이션/아키텍쳐를 이용하기 위한 거의 모든 사항을 담아놓은 듯한 책이다. 모든 사항을 자세하게 설명하는 건 불가능하기 때문에 때로는 소개에 그치는 경우도 있지만, 중요한 사항을 잘 설명하고 있다. 클라우드 네이티브에 필요한 핵심 요소로 마이크로서비스, CI/CD, DevOps, 컨테이너를 들 수 있고 이 책에서 여러 페이지에 걸쳐 설명하고 있는데, 사실 클라우드 네이티브 어플리케이션이 아니더라도 이미 여러가지 문제를 해결하기 위해 사용하던 중요한 기술들이다. 각각의 기술을 더 깊게 살펴봐야 할 때는 당연히 전문 서적을 더 봐야겠지만, 혹시 모르는 기술이 있거나, 전체적인 조망이 필요하다면 이 책은 정말 큰 도움이 된다.

Ch1. 클라우드 네이티브 소개

기본 개념 및 가정 소개. 분산 시스템에서 하지 말아야 할 가정(e.g. 네트워크가 안정적이고 지연이 없다)과 NoSQL을 통해 널리 알려진 CAP 이론, 12요소 앱 https://12factor.net, SLA 등을 설명한다. 다른 건 다 알고 있었지만 12요소 앱은 처음 들었는데, 하나 하나 따로 보면 무심코 지나치더라도 생각해보면 중요한 항목들을 모아서 잘 정리했음을 알 수 있었다. 평소에 생각하던 logging의 중요성을 별도의 항목으로 한게 특히 마음에 들었다.

Ch2. 기본지식

도커와 쿠버네티스로 대표되는 컨테이너 기술로 시작한다. 특성상 컨테이너가 기본적으로 필요한 사항이기도 하지만 의도적으로 기본지식의 첫 번째로 배치하지 않았을까 생각이 들었다. 도커와 쿠버네티스의 기본적인 용어나 기초적인 이해를 위한 설명을 한다.

서버리스 컴퓨팅과 함수 항목은 하나로 묶어서 이야기해도 될 거 같다. 서버리스 컴퓨팅에 대한 설명은 한 페이지도 되지 않아서 조금 부족한 느낌이 있지만, 함수 부분에서 FaaS (Function as a Service)를 이야기하며 그 부족함을 약간이나마 채워준다.

마지막으로는 마이크로서비스의 장단점을 논한다. 이미 흐름은 MSA가 최선인 듯한 분위기로 넘어갔으나, 사실 하나의 서비스 파악은 용이해도 전체 서비스 파악은 오히려 어려워질 수도 있다는 점(네트워크로 호출하면서 오히려 전체 시스템의 흐름이 복잡해질 수 있음, 로깅/디버깅/테스트/모니터링의 어려움 등), 을 감안하면 적절한 수준에서 서비스를 나눠야 하는데, 분야를 막론하고 “적절함"은 항상 정해진 기준이 없고 상황에 따라 가변적이라는 점에서 쉽게 결정할 수 없는 문제이다.

Ch3. 클라우드 네이티브 어플리케이션 설계

기초에 해당하는 키워드는 다음과 같다. 자동화 모니터링 문서화 점진적인 변화 장애대비 보안 신뢰성 가용성 확장성 비용. 경험상 자동화와 모니터링은 비교적 잘 하기 쉬운 부분이고, 문서화와 점진적인 변화는 대부분의 기업에서 제대로 되지 않을 가능성이 높고, 나머지 항목은 비용에 영향을 받는 경우가 많다.

그 다음으로 클라우드 네이티브 어플리케이션과 전통적인 아키텍쳐의 차이점을 보여주는 데 가장 큰 차이점은 상태가 어플리케이션 외부에 존재한다는 점이며, 이로 인해 마치 함수형 프로그래밍과 같이 확장이 용이하지만 데이터의 흐름은 이해하기 어려운 문제가 생긴다.

API 문서화는 개인적으로 가장 중요한 부분 중 하나라고 생각하는데, swagger를 이용해 API 문서화를 자동화하는게 보편화되었지만, 여전히 이런 자동 생성된 API 문서는 실제 사용할 때 종종 어떻게 동작하는지 이해하기 어려운 경우가 있어서 이것만으로 만족하면 안된다고 생각한다.

이후로는 서비스 커뮤니케이션 — 프로토콜, 멱등성, pub/sub, 동기/비동기, 게이트웨이, 서비스 메시 등 시스템 디자인에 필요한 여러가지 항목이 나오고 마지막으로 아키텍쳐 예제를 통해 몇 가지 간단한 아키텍쳐 다이어그램과 기본적인 사항을 알려준다.

Ch4. 데이터 다루기

데이터 스토리지 시스템의 종류에 대해 설명하는 걸로 시작한다. 저장 유형에 따른 분류(오브젝트, 파일, 분산파일시스템 등)와 키밸류, 문서, 관계형, 그래프, 컬럼, 시계열 뿐만 아니라, 스트림/큐, 블록체인까지 같이 이야기한다. 이렇게 다양한 데이터 시스템을 선택하는 기준을 기능/비기능 요구 사항에 따라 20가지 넘게 제시하는데, 개인적으로는 언제나 시작은 99% 관계형 DB로 하고 서비스 성숙도 및 사용자 증가에 따라 필요시 다른 형태로 바꾸는 게 맞다고 본다.

클라우드를 설명하는 책이기 때문에 데이터도 분산 저장하게 되는데, 이 때 가장 어려운 문제는 일관성과 무결성을 제공하는 일이다. 로그나 트랜잭션을 수행해 이런 문제를 해결할 수 있다. 데이터를 수집하면 이걸 분석해야 서비스 향상을 위한 자료로 사용할 수 있는데 이를 위해 ETL 및 데이터 레이크도 사용할 수 있다. 어플리케이션 확장을 위해 데이터 복제를 해야 하므로 데이터 샤딩으로 부하를 분산하기도 하고, 응답속도 향상을 위해 캐싱이나 CDN을 이용할 수도 있다.

Ch5. 데브옵스

인프라의 발전이나, 클라우드 사용이 증가하면서 많은 부분이 자동화되었지만 여전히 설정이나 운영 측면에서 사람의 손이 많이 간다. 그래서 기술 서적이지만 사람, 협업, 공유의 중요성을 강조하면서 이번 장을 시작한다.

두번째는 테스팅인데, 아마 여기 나오는 모든 테스팅 종류를 실천은 고사하고 모두 아는 사람도 드물지 않을까 하는 생각이 들었다. 유닛, 서비스, UI, 젭슨, 성능, 부하, 보안, 침투, A/B, 인수, 이용성, 설정, 스모크, 통합, 카오스, 퍼지, 카나리 테스트.

이외에도 개발 도구와 환경, CI/CD, 모니터링, 설정 관리 등 서비스 운영에 필요한 거의 모든 부분을 설명한다.

Ch6. 모범사례

기존 모놀리스 아키텍쳐를 이전할 때 고려할 점, 장애와 보안에 대해 생각할 점, 데이터 관리와 성능 및 확장성을 위해 필요한 점, 서버리스 아키텍쳐에서 알아둘 점, 운영, 로깅, 모니터링, 알림, 서비스 커뮤니케이션(서비스나 클라이언트, DB와의 통신 등), 컨테이너까지 각 항목 별로 점검하고 참고할만한 사항을 알려준다. 이 장은 일종의 팁 모음과도 같단 생각이 들었다.

Ch7. 이식성

본문의 설명처럼 고객의 요구에 따라 특정 클라우드 서비스를 이용하는 경우뿐만 아니라 자사의 인프라가 변경되는 경우에도 어플리케이션을 다시 배포할 필요가 발생한다. 그러므로 이식성은 아키텍쳐만큼이나 중요한 요구 사항이다. 특정 벤더에 종속되는 상황을 피하기 위해서는 당연히 유연하게 이식이 가능해야 하는데, 이런 기능 구현을 위해서는 시간과 비용 및 복잡도가 증가하기 때문에 다른 아키텍쳐 요구 사항을 고려할 때처럼 트레이드 오프를 고려해야 한다.

어플리케이션 이식성과 마찬가지로, 아니, 더 중요한 정도로 데이터 이식성도 고려해야 하는데, 데이터가 클수록 이전도 어렵기 때문에 아마존의 경우 이미 몇 년 전에 스노우볼이라는 물리 디스크를 통한 데이터 이전을 지원하는 서비스를 발표하기도 했다.

이식성에서 가장 중요한 건 표준화된 인터페이스를 사용하는 부분인데, 이런 표준화된 인터페이스가 존재하면 훨씬 용이하게 이식을 할 수 있겠지만 실제로는 모든 상황을 만족하는 경우는 존재하지 않기때문에, 특정 벤더에 종속된 부분은 직접 구현해야만 한다. 이런 이식성 관련 도구들 중 인프라 관리를 추상화하기 위해 하시코프의 테라폼을 이용할 수 있는데, 대부분은 동일하지만 결국 특정 벤더에 관련된 부분이 없을 수는 없다. 스토리지 추상화를 위해 MinIO를 이용해 AWS, Azure, Google Cloud 및 로컬 파일시스템을 이용할 수 있다(고 한다. 이건 처음 들어봄).

여기서 다시 쿠버네티스가 나오는데, 클라우드 공급자 인프라를 추상화하기 위해 사용이 가능하다. 쿠버네티스가 사실상의 표준이 되면서 거의 모든 클라우드에서 관리형 쿠버네티스 서비스를 제공하기 때문에 가장 효율적이면서 동시에 거의 유일한 인프라 추상화 방법이다.