본문 바로가기

클라우드 네이티브 GO

클라우드 네이티브란 무엇인가?

클라우드 네이티브란 무엇인가?

클라우드 네이티브라는 용어는 어떻게 정의 할 수 있을까요? 

CNCF(Cloud Native Computing Foundation)에서는 이렇게 정의를 한다고 합니다

클라우드 네이티브 기술은 기업들이 퍼블릭,프라이빗, 하이브리드 클라우드 처럼 현대적이고 동적인 환경에서 확장성 있는 어플리케이션을 빌드하고 실행할 수 있도록 해줍니다. 이들은 확장 가능하고느슨하게 결합되어 있고, 탄력적이며, 관리 가능하고, 관찰 가능합니다. 이러한 특징들을 잘 구성된 자동화와 함께 사용한다면 엔지니어로 하여금 영향도가 높은 변경 작업들을 자주 그리고 최소한의 노력으로 할 수 있게 해준다.

1. 확장성

확장성(scalability)는 클라우드 컴퓨팅 관점에서 현저한 요청량 증감을 만났을 때 기대되는 동작을 하는 시스템의 능력입니다. 시스템이 급격한 요청량 증가 전후로 리팩터링 없이 의도한 동작을 수행한다면 확장성이 있다고 이야기할 수 있습니다

 

- 수직적 확장

시스템은 할당된 하드웨어 자원을 늘려(또는 축소하여) 수직적 확장(스케일 업)을 할 수 있습니다. 예를 들어 데이터베이스 서버의 메모리를 늘리거나 CPU를 추가하는 것이 대표적인 예입니다. 기술 관점에서 (상대적으로) 직관적이라는 장점이 있지만, 주어진 인스턴스의 자원이 지나치게 늘어날 수 있습니다.

수직적 확장

 

- 수평적 확장

시스템은 서비스 인스턴스를 추가하여(또는 제거하여) 수평적 확장(스케일 아웃)을 할 수 있습니다. 예를 들어 로드밸런서의 연결된 노드의 수를 늘리거나, 쿠버네티스 혹은 다른 컨테이너 오케스트레이션 환경에서 컨테이너를 늘림으로써 수평적 확장을 할 수 있습니다. 이러한 전략은 복수의 자원을 통한 고가용성, 사용 가능한 인스턴스 크기의 제약으로부터 자유를 얻는 것과 같은 여러가지 장점을 얻습니다. 그러나 복수의 자원이 있으면 시스템 디자인이나 관리 복잡도가 커진다는 의미며, 모든 서비스가 수평적으로 확장될 수 없다는 한계가 있습니다.

수평적 확장

 

2. 느슨한 결합

느슨한 결합(Loose Coupling)은 시스템 속성이 하나로, 특정 시스템 구성 요소가 다른 구성 요소에 대하여 최소한의 정보를 갖도록 하는 디자인 전략입니다. 다른 시스템을 변경할 필요 없이 시스템 하나를 변경할 수 있을 때 이 두 시스템은 느슨하게 결합되었다고 합니다.

예를 들어 웹 서버와 웹 브라우저는 느슨하게 결합되어 있다고 생각할 수 있습니다. 서버는 언제든 업데이트 할 수 있고, 우리가 사용하는 브라우저에 아무런 영향을 주지 않으면서 완전히 새로운 장비로 교체될 수 있습니다. 이는 표준 웹 서버는 일련의 표준 프로토콜을 이용하여 통신할 것이라는 동의가 기반되어있기에 가능합니다.

 

3. 탄력성

탄력성(Resilience)은 시스템이 얼마나 에러나 장애를 잘 견디는지 나타냅니다. 시스템 일부분에 문제가 생겼을 때 완전히 중지되지 않고 가능한 수준에서 지속적으로 동작 가능할 때 시스템이 탄력성을 가지고 있다고 합니다. 탄력성을 갖도록 시스템을 설계하는 방법은 여러가지가 있습니다. 컴포넌트를 중복 배포하는 것은 아마도 가장 널리 사용되는 방법일 것입니다. 서킷브레이커와 재시도 로직은 고장이 컴포넌트간에 전파되지 않도록 하기 위해서 사용될 수 있습니다.

 

4 . 관리 용이성

시스템의 관리 용이성(Managability)은 보안이 유지되는 조건 아래에서 변화하는 요구 사항을 원할하게 준수하도록 동작을 수정할 수 있는 용이성을 말합니다. 예를 들어 서비스와 데이터베이스, URL로 데이터베이스에 접근하는 서비스로 구성된 가상의 시스템을 생각해봅시다. 만약 서비스가 또 다른 데이터베이스를 참조하도록 업데이트 해야한다면?  관리가 용이한 시스템이라면 이 값을 쉽게 수정할 수 있도록 환경변수로 나타냈을 것이고 쿠버네티스 환경이라면 시스템 동작을 변경하는 작업은 컨피그맵(ConfigMap)값을 업데이트 하는 작업이었을 것입니다. 정답은 없습니다 ㅎㅎ

관리 용이한 시스템은 적응성을 위해 설계되었으며 변화하는 기능, 환경, 보안 요구 사항을 수용하도록 쉽게 조정 가능합니다. 반면 그렇지 못한 시스템들은 자주 임시 방편의 변경이 필요합니다. 그 결과 이러한 시스템을 관리하는 데 필요한 오버헤드는 확장성, 가용성, 신뢰성에 대한 근본적인 제한을 야기합니다.

 

5 . 관찰 가능성

시스템의 관찰 가능성(Observability)은 시스템의 출력값을 토대로 시스템 내부의 상태를 얼마나 잘 추론할 수 있는지에 대한 척도입니다. 새로운 코드 작성이나 재구축 없이 최소한의 사전 지식만으로 빠르고 일관되에 시스템과 관련된 새로운 질문을 할 수 있을 때 관찰 가능하다고 이야기 합니다

관찰 가능성에 대한 새로운 사례는 모니터링 도구의 발전으로 볼 수 있습니다. 복잡한 시스템을 계측함으로써 미래에 여러분이 아직 하지 않는 질문에 답할 수 있도록 하는 것이 기본이라는 점을 명심하시길 바랍니다.

 

6. 결론 

궁극적으로 클라우드 네이티브와 관련된 모든 화려한 수식어들은 오늘날의 어플리케이션은 많은 사람들에게 신인성 있는 서비스를 제공해야한다라는 지점으로 귀결되게 됩니다. 그래서 클라우드 네이티브라 부르는 기법과 기술은 현재 확장 가능하고 적응력이 뛰어나며 탄력적인 서비스를 구축 할 수 있는 모범 사레를 대표하게 됩니다.

클라우드 네이티브가 Go언어가 어떤 관계가 있을까요 라는 의문이 생기게 될텐데 클라우드 네이티브 인프라에는 클라우드 네이티브 도구가 필요하며 여기에는 Go가 꼭 필요합니다. 라고 이야기 할 수 있습니다. 그럼 다음 글에서는 이것이 정확히 어떤 의미인지 알려드리겠습니다