ICT CoC 멤버가 자유롭게 소통할 수 있는 커뮤니티입니다.
ICT CoC 멤버가 자유롭게
소통할 수 있는 커뮤니티입니다.
| 제목 | 앱 중심 미래를 향해 가는 쿠버네티스…OAM과 Rudr로 멀티클라우드 분산 앱 확장 |
|---|---|
| 날짜 | 2019-10-25 |
| 첨부파일 | 없음 |
|
쿠버네티스는 클라우드의 큰 성공 사례다. 무에서 시작해 불과 몇 년 만에 애플리케이션 개발의 슈퍼스타로 떠올랐다. 쿠버네티스가 빠른 속도로 성장하자 개발자들은 쿠버네티스 호스팅 애플리케이션을 구축하고 관리하기 위한 더 나은 방법을 찾고 있다. 쿠버네티스를 위한 확장은 풍부하다. 헴(Helm)과 같은 툴을 사용하면 클러스터에 리소스를 손쉽게 배포할 수 있고, CNAB(Cloud Native Application Bundle)는 애플리케이션과 모든 종속성을 즉시 배포 가능하도록 래핑한다. 하위 수준에서는 드래프트(Draft)와 같은 서비스가 기본적인 서비스를 설계하고 빌드하는 데 도움이 된다. 코드를 빌드해서 익숙한 컨테이너를 사용해 배포할 수 있고, 각 요소를 손쉽게 쿠버네티스 애플리케이션으로 조합할 수 있다. 애저 쿠버네티스 서비스를 사용해서 관리를 자동화할 수도 있다. 서비스 인프라를 백그라운드에 두고 있다는 점을 고려하면(구글의 보그(Borg) 작업), 쿠버네티스와 이를 둘러싼 각종 툴이 기본적으로 운영에 초점을 두는 것은 지극히 자연스럽다. 분산 시스템 운영은 오랜 과제이며, 보그에서 메소스(Mesos), 도커 스웜과 쿠버네티스에 이르기까지 전반적인 데이터센터 OS 추세에는 데브옵스 중에서 ‘데브’보다 ‘옵스’ 측면이 훨씬 더 크다. 이 상황을 넘어 쿠버네티스의 데브 측면을 강화하려면 어떻게 해야 할까? 생태계를 구축하고, 마이크로서비스 원칙을 기반으로 하는 분산 애플리케이션을 구축하기 위한 패턴과 방법을 코드화하는 측면에서는 많은 일이 이뤄졌다. 이제 이 모든 조각을 모아서 전체 그림에서 빠진 조각이자 개발자에게 필수적인 조각, 즉 쿠버네티스에 대한 애플리케이션 중심의 시야를 확보해야 한다. OAM(Open Application Model)마이크로소프트와 알리바바 클라우드는 최근 현대적인 분산 애플리케이션을 구성하는 다양한 계층과 역할 간의 경계에 대한 이해를 바탕으로 마이크로서비스 기반 애플리케이션 구축과 관리에 초점을 두는 OAM(Open Application Model)을 발표했다. OAM은 모든 쿠버네티스 기반 환경이 다르다는 점을 명확히 하지만, 데브옵스 문화가 주는 혜택을 버리지 않고도 애플리케이션을 인프라의 지원 서비스로부터 분리할 수 있는 공통적인 부분이 여전히 있다.OAM의 시작은 현대적인 애플리케이션의 구축과 운영에 관여하는 팀의 역할과 책임을 정의하는 것이다. 개발자와 운영자라는 전통적인 구분 대신 조금 더 세분화된 방식을 사용하며, 애플리케이션 운영자와 인프라 운영자 역할이라는 개념을 사용한다. 합리적인 모델이다. 쿠버네티스와 같은 툴과 이를 둘러싸는 서비스는 본실적으로 기반 데이터센터 및 코어 애플리케이션의 추상화다. OAM에는 개발 팀이 제공하는 마이크로서비스를 관리하고 배포하는 애플리케이션 운영자가 있다. 이들은 팟과 컨테이너를 관리하고 배포하면서 모니터링 및 관찰 툴을 사용해서 애플리케이션 안정성과 확장성을 보장하는 팀이다. 또한 서비스 메시 구성요소를 사용해서 애플리케이션 네트워크와 그 동작을 정의하고, 선언적인 툴을 사용해서 서비스 정책을 구축하는 팀이기도 하다. 인프라 운영자는 전통적이 옵스 역할과 비슷하지만 쿠버네티스 자체, 또는 서비스 메시 정책에 의해 관리되는 소프트웨어 정의 네트워크와 마찬가지로 책임의 범위가 인프라 서비스에 국한된다. 이들은 실행 중인 애플리케이션에 대해 알아야 할 필요가 없으며, 제공하는 모든 서비스가 가용하며 API가 작동하도록 보장하기만 하면 된다. 이들의 역할이 가진 중요성을 폄하하려는 것이 아니다. 갈수록 복잡해지는 현대 시스템 운영을 위해서는 서비스 수준에서 숙련된 전문가가 필요하다. 예를 들어 다중 테넌트 데이터베이스의 관리와 배포에는 상당한 지식과 기술이 필요하다. OAM의 애플리케이션 정의OAM의 중심에는 애플리케이션 개념이 있다. 이는 애플리케이션이 배포되는 방법, 기반 인프라와 통합되는 방법으로부터 애플리케이션을 분리한다. 이것은 내가 다른 사람과 다른 방법으로 애플리케이션을 배포하고 관리하며, 애저와 AWS가 애플리케이션을 다루는 방식이 서로 다르다는 것을 이해하는 길이다.애플리케이션은 구성요소로 이뤄진다. 구성요소는 배포 패키지에 포함될 수도, 그렇지 않을 수도 있다. 애플리케이션 구성요소는 호스팅되는 데이터베이스이거나 네트워킹 규칙 집합, 또는 메시지 엔드포인트 집합일 수 있다. 이러한 요소가 구현되는 방법은 기반 플랫폼에 따라 결정되지만, 애플리케이션은 제자리에 배치되기 전에는 배포할 수 없다. 다양한 애플리케이션 구성요소 간의 관계는 매니페스트에 설명되며 이 매니페스트를 사용해서 애플리케이션 마이크로서비스를 배포 가능한 모듈로 빌드할 수 있다. 애플리케이션을 패키징하는 CNAB와 같은 툴에 사용되는 방법에서 한 걸음 더 나간 것이다. 패키지를 제공하는 대신, 가용한 플랫폼 리소스를 사용해서 사이트 또는 서비스별 애플리케이션 버전으로 조합된 구성요소를 제공한다. 그 결과는 애플리케이션 패키징과는 전혀 다른 접근 방법이다. 애플리케이션 운영자 측의 작업이 더 많이 필요하고 인프라 운영자 측에서 필요한 작업은 줄어든다. 트레이트를 사용한 인프라 작업애플리케이션 패키지를 플랫폼에서 분리하면 그 결과는 앱을 어디에 설치하든 모든 구성요소와 리소스가 동일한 표준화된 퍼블릭 클라우드, 그리고 기성 하드웨어와 구글 클라우드 플랫폼의 안토스(Anthos) 같은 툴을 혼합한 맞춤형 온프레미스 프라이빗 클라우드 간의 차이점에 대처할 수 있는, 애플리케이션 개발에 대한 더 불가지론적인 접근 방법이다. 이를 위한 열쇠는 OAM의 트레이트(Trait) 개념이다.트레이트는 애플리케이션 환경이 어떻게 작동해야 하는지를 기술하는 데 사용되며 기계와 사람이 모두 읽을 수 있는 방식으로 확장 및 기타 주요 분산 컴퓨팅 개념을 설명한다. 트레이트에는 이름과 일련의 속성이 있다. 예를 들어 자동 확장 트레이트는 허용되는 최소 및 최대 복제본 수를 정의하고, 이는 쿠버네티스 설치를 위한 적절한 YAML로 변환되거나 서비스 메시 또는 KEDA(쿠버네티스 기반 이벤트 중심 자동 확장)와 같은 서비스를 위한 구성 파일로 변환될 수 있다. 결국 OAM이 확산되면 네트워킹 및 보안 툴과 기타 클라우드에서 사용 중인 인프라 자동화 기능에서 직접 트레이트와 트레이트 정의를 지원해야 한다. 트레이트와 다른 OAM 애플리케이션 개념은 벤더 중립적이어야 한다. 그러면 어느 인프라에서든 관계없이 애플리케이션을 설치하고 실행할 수 있다. 이 접근 방법은 코드가 클라이언트 가까이에서 실행되고 가용한 장비가 클라우드플레어(Cloudflare)와 같은 콘텐츠 제공 네트워크 또는 AT&T와 같은 대도시 수준 통신 사업자에 의존할 수 있는 엣지 환경에서 잘 작동할 것이다. Rudr, 쿠버네티스를 위한 OAM 기준 구현OAM과 같은 사양에는 기준 구현이 필요하다. 마이크로소프트는 쿠버네티스와 함께 사용하기 위한 구현인 Rudr를 출시했다. Rudr은 OAM 정의를 취해서 맞춤형 리소스 정의를 사용해 쿠버네티스 구성요소 및 서비스로 변환한다. 흥미로운 점은 러스트(Rust)로 작성되어 이 언어의 메모리 안전 기능을 활용해 애플리케이션의 위험을 낮춘다는 것이다. 공개된 가이드를 사용해서 간단한 파이썬 앱 컨테이너를 호스팅하는 기본적인 구성요소를 만들 수 있다.
원문보기: http://www.itworld.co.kr/news/134587#csidx8fe494bc5d6857fa749616e40e9b85b |
|
