[TechReport] 하이브리드 클라우드 아키텍처 설계를 위한 제언

[한국IBM=이화용] 하이브리드 클라우드 아키텍처는 복잡한 환경을 하나로 관리할 수 있는 IT 인프라 형태로 통합하는 것이다. 환경은 지리적으로 분산된 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스 인프라에 걸쳐있다.

일반적인 기업은 하이브리드 클라우드 인프라를 활용할 때, 퍼블릭 클라우드 서비스에서 몇 가지 API를 호출할 수 있도록 한다. 이는 온프레미스 데이터 센터에서 레거시 애플리케이션을 호스팅하는 형태의 구현이다. 그러나 이것은 기초적 구현으로, 하이브리드 클라우드 인프라를 최적으로 활용하는 대표적인 유즈 케이스는 아니다.

하이브리드 클라우드 잠재력을 최대한 실현하려면 ▲서비스형 인프라(Infrastructure-as-a-Service, IaaS) ▲서비스형 플랫폼 (Platform-as-a-Service, PaaS) ▲서비스형 소프트웨어(Software-as-a-Service, SaaS) 기능과 온프레미스, 프라이빗, 퍼블릭 클라우드 및 엣지 환경을 함께 사용해 애플리케이션을 호스팅할 수 있어야 한다. 그 후 종속성 없이 멀티클라우드 접근이 가능한 유연성을 갖추는 것이다. 이렇게 설계 패턴과 고려할 핵심 요인을 이해하는 것은 하이브리드 클라우드 아키텍처의 복잡성을 해소하는 데 도움이 된다.

◆ 현대적 하이브리드 클라우드 아키텍처의 기본 요소
최근의 하이브리드 클라우드 접근법은 일반적으로 일부 서비스를 온프레미스 인프라에서 퍼블릭 또는 프라이빗 클라우드로 마이그레이션(migration)하고 서비스 간 통신을 허용하는 것이다. 이 접근법은 퍼블릭 클라우드에서 호스팅할 신규 애플리케이션을 구축하는 경우에도 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)를 고수한다.

오늘날에는 마이크로서비스 기반 아키텍처가 하이브리드 클라우드 모델의 핵심이다. 마이크로서비스는 배포의 용이성을 위해 애플리케이션을 작은 구성 요소 또는 서비스로 분할하는 접근법이다. 마이크로서비스가 SOA 기반 서비스와 다른 점은 자체적인 기술 스택을 가지고 있다는 것과 마이크로서비스와 종속된 라이브러리가 포함된 경량의 실행파일로 컨테이너에 배포되는 것이다. 컨테이너는 머신 운영 체제(Operating System, OS)의 커널을 공유하고, 마이크로서비스와의 종속성만 가지므로 가볍다. 모든 OS 종속성은 컨테이너가 있는 하드웨어로부터 공유된다.

즉,  컨테이너 OS 레벨 가상화를 통해 마이크로서비스를 온프레미스 또는 클라우드 환경에 독립적으로 배포할 수 있다. 
또한 마이크로서비스와 SOA는 자급자족적 특징으로 많은 차이점을 가지고 있으며 클라우드 배포에 더 적합하다. 클라우드 배포 환경에서 클라우드 리소스를 최적화하기 위해서는 탄력성과 유연성이 가장 중요하다.

모든 환경에서의 프로세스 격리를 위한 패키징 모델로서의 컨테이너화는 새로운 개념이 아니었지만, 2013년 컨테이너 엔진으로 도커(Docker)가 등장하면서 범용적인 패키징 구조가 만들어졌다. 

쿠버네티스(Kubernetes)와 같은 컨테이너 오케스트레이션 플랫폼은 하이브리드 클라우드 환경에서 Docker나 컨테이너 기술에 대한 표준화(Open Container Initiative, OCI)를 준수하는 기타 모든 컨테이너의 배포를 자동화한다.

◆하이브리드 클라우드에 대한 컨테이너화 패러다임의 영향

컨테이너화(containerization)의 등장은 하이브리드 클라우드의 이점을 활용하는 데 큰 도움이 됐다. 이로 인해 자신이 선택한 클라우드 환경으로의 쉬운 이식성과 서비스 자동 배포로 중요도가 바꼈다.

몇 년 전에는 하이브리드 클라우드 아키텍처에 관한 논의의 주요 질문은 각 워크로드를 클라우드 또는 온프레미스 환경에서 실행해야 하는 지와 서로 다른 환경들을 어떻게 서로 통신하게 할 것인지에 초점이 맞춰져 있었다. 본질적으로, 호스팅 위치와 물리적 연결이 주된 고려 사항이었다.

예를 들면, 중요한 데이터를 다루는 애플리케이션은 프라이빗 클라우드에서 호스팅하거나 현대화가 어려운 레거시(Legacy) 애플리케이션은 계속 온프레미스에 남아 있었다. 이외의 퍼블릭 클라우드 환경으로 확장해야 하는 애플리케이션은 전면 전환 방식(Lift-and-Shift)으로 이동했다. 그 후, 환경 간 통신을 위해 가상사설망(Virtual Private Network, VPN) 터널 또는 메시지 스트림과 같은 채널을 구축했다.

이러한 요소들은 여전히 중요한 고려 사항이지만, 컨테이너화 패러다임으로 초점은 호스팅 위치와 물리적 연결에서, 한 환경에서 다른 환경으로 원활하게 워크로드를 이동하는 유연성으로 이동했다. 

이어 프라이빗 클라우드 또는 퍼블릭 클라우드 중 어디에서 애플리케이션을 호스팅해야 하는지를 까다롭게 결정할 필요가 없어졌다. 방식의 효과가 미미할 경우, 환경 간 컨테이너로 패키지화된 워크로드를 쉽게 이동하고 확장 및 축소를 수행할 수 있다. 심지어 다른 환경에 동일한 서비스의 인스턴스를 실행할 수도 있다.

이 모든 것으로 고성능, 리소스 효율성, 비용 절감을 제공하는 현대적이고 가용성이 높으며 유연한 아키텍처가 탄생했다.

◆ 하이브리드 클라우드 아키텍처 설계 시 주요 고려 사항
하이브리드 클라우드 아키텍처 설계 및 구현 시 기업의 비즈니스 목표, 현재의 기술 환경, 디지털 혁신 목표 및 보안 고려 사항을 비롯한 많은 요소를 고려해야 한다. 여러 하이브리드 클라우드 솔루션을 사용하는 아키텍처는 매우 빠르게 복잡해질 수 있으므로 원활하고 확장 가능한 중앙집중식 클라우드 관리를 위한 운영 도구를 활용하는 것이 중요하다. 아래는 하이브리드 클라우드 전략 수립 시 고려해야 할 몇 가지 요소들이다.

현대화 전략
대부분의 조직에서 하이브리드 컴퓨팅 클라우드의 아이디어는 애플리케이션 현대화 또는 온프레미스에서 클라우드로 애플리케이션을 이동하는 것에서부터 시작하며, 이를 실행하는 방법은 몇 가지가 있다.

전면 전환(Lift-and-Shift)은 현대화를 시작하는 가장 일반적인 방법이다. 전체 애플리케이션을 오프프레미스(Off-premises)에서 클라우드 환경으로 이동한다. 이를 위해서는 안전하고 확장 가능한 클라우드 컴퓨팅 리소스와 인프라 서비스를 활용하기 위해 기반 하드웨어 변경 작업이 필요하다. 리팩터링 또는 재설계 시간이 충분하지 않을 경우 좋은 옵션이다.

리팩터링(Refactoring)을 이용할 때는 모놀리식 애플리케이션(monolithic application)을 클라우드로 이동하는 것보다 한두 개 서비스를 식별해 리팩터링 한 후, 클라우드에 배포하는 것이 더 편리하다. 이러한 단계적 이동은 테스트 및 학습 기회를 위해 소량의 트래픽을 클라우드 새 인스턴스로 라우팅하고 궁극적으로 서비스의 모든 인스턴스를 클라우드로 이동하게 된다.

재설계(Rearchitect)는 모든 시스템 구성 요소를 단일 책임 원칙(Single-responsibility principles, SRP)을 따르는 마이크로서비스로 모듈화해 컨테이너화 한다. 가장 정교한 접근법이다. 이것은 프로덕션 및 컨테이너화에 대한 독립적인 경로를 가지고 있다. 이 접근법은 완전한 재작성이 필요하며, 비용이 많이 들지만 이득을 극대화할 수 있다. 

통합 컨트롤 플레인
엔터프라이즈 운영 팀은 환경 전반에 걸쳐 유기적이고 일관된 클라우드 운영 경험을 제공하는 통합 컨트롤 플레인을 통해 클라우드 환경을 관리한다. 통합 컨트롤 플레인은 워크로드 스케줄링(Workload Scheduling), CI/CD(Continuous Integration and Deployment) 파이프라인, 로깅(Logging), 텔레메트리 및 페더레이션된 보안(Telemetry and Federated Security)과 같은 핵심 클러스터 관리 기능을 지원한다.

목표는 기업에서 애플리케이션 팀에서는 개별 클라우드 서비스 제공업체(Cloud Service Provider, CSP) 및 런타임의 기본 복잡성을 추출하고 운영 팀은 워크로드를 관리할 수 있도록 공통 인터페이스를 제공하는 것이다.

통합 컨트롤 플레인의 장점은 ▲가상 머신, 컨테이너 또는 서버리스 배포 환경 전반에 걸친 동적 워크로드 배치 전략의 활용 ▲최소한의 리소스로 추가 공급업체 또는 엣지 위치를 온보딩할 수 있는 기능 ▲가용성 높고 다양한 클라우드 환경에서 작동하는 FaaS(Function-as-a-Service)와 같은 PaaS 기능 구현 ▲규정 준수 관리의 중앙 집중화 등이 있다.

API 게이트웨이 및 서비스 메시
중앙집중식 API 게이트웨이(API gateway) 및 서비스 메시(Service mesh)와 같은 아키텍처 패턴은 ▲라우팅 ▲서비스 간 통신 ▲보안 ▲속도 제한 및 관찰 가능성(Observability)과 같은 클라우드 기능을 투명하게 관리할 수 있게 지원한다.

API 게이트웨이는 ▲모든 리전에서 통합된 프론트 도어 역할을 수행 ▲내/외부(north-south) 트래픽 기능 ▲사용자 인증 및 권한 부여 ▲스로틀링(Throttling) 및 속도 제한 ▲트래픽 관리 ▲API 라이프사이클 관리 ▲클라우드 보안 가드레일 ▲엣지 분석의 기능을 처리한다.

반면, 서비스 메시는 서비스 종속성 간의 내부(East-West) 트래픽을 처리하는데, 내용으로는 ▲클러스터 내 안전한 서비스 간 통신 ▲로드 밸런싱, 라이팅 규칙, 재시도, 페일오버, 재해 복구 및 폴트 인젝션을 통한 트래픽 관리 ▲클러스터 이그레스(Egress) 및 인그레스(Ingress)를 포함한 클러스터 내 모든 트래픽에 대한 메트릭, 로그 및 트레이스에 대한 텔레메트리 ▲서비스 바운더리를 넘어 리퀘스트의 흐름을 측정하는 분산 추적 기능 ▲서비스 검색 자동화 등이 있다.

예를 들어, 이스티오(Istio)는 클라우드 관리자가 제공한 사전 정의된 구성에 따라 서비스 간 통신을 지시하는 오픈 소스 서비스 메시 레이어이다. 이스티오는 쿠버네티스 오케스트레이션 레이어에서 사이드카 패턴으로 수행되며 프로그래머와 관리자에게는 보이지 않는 컨테이너로 동작한다.

보안
하이브리드 클라우드 아키텍처의 복잡성으로 인해 엔드 투 엔드 보안 및 보호를 보장하기 위해서는 서로 다른 레이어에서 다중 계층 접근 방식을 취해야 한다.

IBM Cloud, Amazon Web Services(AWS), Microsoft Azure 및 Google Cloud와 같은 CSP는 서비스 수준 계약(Service Level Agreement, SLA)에 따라 경계(Perimeter) 레이어에서 모든 호출을 인증하고 권한을 부여한다. 이를 통해 엔터프라이즈 애플리케이션 주변에 방화벽을 구축한다. 

이러한 책임에는 서비스 거부(Denial of Service, DoS) 방어와 GDPR(General Data Protection Regulation), HIPAA(Health Insurance Portability and Accountability Act)와 같은 개인 정보 보호 규정 준수가 포함된다.

온프레미스 인프라에서 경계(Perimeter) 보안은 모든 API 엔드포인트를 보호하는 API 게이트웨이를 사용해 유지할 수 있다. 데이터 센터 외부에 있는 웹 서비스 또는 모바일 애플리케이션의 모든 호출은 API 게이트웨이를 통해 유효성을 검증하고 라우팅해야 한다.

클라우드 컴퓨팅 환경에는 서비스 메시에 정의된 제어 정책 및 오케스트레이션 플랫폼에 의해 노출된 API 형태로 추가 보안 레이어가 포함된다. 이러한 정책은 보안이 적용된 호출만 쿠버네티스 노드로 그리고 노드에서 마이크로서비스로 전달되도록 한다.

또한, 환경을 서로 다른 논리적 보안 세그먼트로 분할해 각 서비스와 워크로드에 대한 액세스 제어 정책을 정의하는 마이크로 세분화 개념을 사용하기도 한다. 이를 통해 환경 내에서 실행되는 서비스 간의 보안 수준을 구축하고 정의할 수 있다. 마지막으로, 암호화 정책은 추가적인 데이터 보호 레이어 역할을 수행한다.

네트워크 연결
단일 클라우드 리전에서 가용성 영역은 네트워크의 모든 노드를 연결하는 전용 파이버 네트워크가 있어 기업은 대역폭에 제한 없이 네트워크 레이턴시가 낮은 고가용성 아키텍처를 만들 수 있다. 그러나 리전 및 여러 클라우드 제공업체 간 통신은 공용 인터넷을 통해 라우팅되며, 이 경우 레이턴시 및 장애 가능성이 높아진다.

하이브리드 클라우드 아키텍처에는 기본 공급자 간의 데이터 교환을 위한 세가지 패턴이 있다. ▲인터넷을 통한 공용 IP 주소 ▲VPN과 같은 관리형 서비스 ▲공통 POP(points of presence)를 통한 전용 상호 연결이다. 이러한 옵션들은 전송 속도, 레이턴시, 신뢰성, SLA, 복잡성 및 가격 측면에서 차이가 있으므로 네트워크 연결 레이어를 설계하기 전에 제약 사항과 이점을 따져 보는 것이 중요하다.

개발 플랫폼의 오픈소스에 대한 편견
하이브리드 클라우드는 워크로드를 한 환경에서 다른 환경으로 이동할 수 있고, 모든 클라우드에서 실행되는 애플리케이션 개발 플랫폼을 보유할 수 있는 기능을 의미한다.

진정한 클라우드 네이티브 방식이 되려면 특정 기술, 플랫폼 또는 심지어 CSP에 대한 의존도가 높아서는 안 되며, 기업은 시장의 변화에 민첩해야 한다.

오픈 소스 아키텍처는 개발자가 구현에 사용된 기술에 상관없이 기반 인프라를 관리할 수 있도록 해 개발에 대한 통합 접근 방식을 가능하게 한다. 오픈 소스는 더 이상 비용 효율성 때문에 주류가 돼 풍부한 기능, 품질, 및 커뮤니티 기반 개발로 중심적 위치를 차지하고 있다.

또한, Red Hat Report on The State of Enterprise Open Source(엔터프라이즈 오픈 소스에 대한 Red Hat 보고서)에 따르면 보안과 같은 민감한 영역에서도 이제 오픈 소스 소프트웨어는 좋은 선택지로 인식되고 있다. 클라우드 네이티브 아키텍처에 대한 보안, 품질 및 지원은 기업들이 오픈 소스에 대해 의식적인 편견을 보이는 주요 원인이다.