하이브리드 클라우드 아키텍처는 기업이 엄격하게 통제된 온프레미스 인프라와 퍼블릭 클라우드 서비스의 파워를 결합할 수 있게 합니다. 높은 유연성 덕분에 하이브리드 클라우드 솔루션은 기존 및 레거시 애플리케이션을 현대화하는 데 가장 선호되는 옵션입니다.
이 기사는 하이브리드 클라우드 아키텍처 입문서입니다. 기업이 퍼블릭 또는 프라이빗 클라우드 단독으로는 달성하기 어려운 기술적, 비즈니스 목표를 더 효과적으로 달성하기 위해 하이브리드 시스템을 구축하는 방법을 알아보세요.
하이브리드 클라우드 아키텍처는 퍼블릭, 프라이빗, 커뮤니티 클라우드, 베어 메탈 등 두 가지 이상의 서로 다른 유형의 인프라가 단일 시스템으로 결합되어 워크로드와 데이터의 완벽한 이동성을 보장하는 것입니다. 이러한 아키텍처는 비즈니스 요구에 따라 다양하지만, 가장 일반적인 시스템은 다음과 같이 결합합니다:
퍼블릭 클라우드와 프라이빗 클라우드 비교를 통해 두 가지 가장 일반적인 클라우드 배포 모델의 주요 차이점을 확인하세요.
구체적인 설정과 관계없이 모든 하이브리드 클라우드 아키텍처는 네 가지 공통 특성을 가집니다:
서로 다른 구성 요소 간의 연결이 하이브리드 클라우드의 주요 특징입니다. 하이브리드는 관리자가 서비스들을 환경 간에 이동할 수 있는 통합된 클라우드 컴퓨팅 시스템을 제공합니다.
구성 요소 간에 통합이 없다면 하이브리드 시스템이 아닙니다. 대신 여러 클라우드가 병렬로 실행되는 설정이며, 이는 멀티 클라우드의 한 형태일 가능성이 높습니다.
하이브리드 아키텍처 설계의 세 가지 주요 측면은 연결성(Connectivity), 앱 현대화(App Modernization), 클라우드 보안(Cloud Security)입니다.
연결성과 상호 운용성은 하이브리드 클라우드 아키텍처의 핵심 개념입니다. 이 기능은 다음을 가능하게 합니다:
연결성 수준은 하이브리드 클라우드가 얼마나 잘 작동하는지에 직접적인 영향을 미칩니다. 하이브리드 환경에서 상호 연결성의 중요성을 이해하기 위해 주식 거래 및 저장 애플리케이션의 예를 들어보겠습니다. 아래 다이어그램과 같이 이 앱은 프라이빗 클라우드와 퍼블릭 클라우드에 의존합니다.
누군가 예시 앱에 접속하면 사용자는 프라이빗 클라우드의 엔드포인트에 도달하고 온프레미스 Kubernetes 클러스터로 들어갑니다. 이 클러스터에는 수많은 서비스가 포함되어 있습니다:
포트폴리오는 프라이빗 클라우드에서 연산을 실행하지만, 이 서비스도 퍼블릭 클라우드의 작업에 의존합니다. 퍼블릭 클라우드의 핵심 서비스는 Investors Exchange(IEX)에서 주식 가격을 가져오는 서비스입니다.
MQ 서비스는 사용자 충성도 수준을 추적합니다. 이 서비스도 퍼블릭 클라우드에 접근해야 하며, 사용자의 충성도 상태나 포트폴리오 변경 사항을 실시간으로 알립니다.
우리 앱은 프라이빗 클라우드와 퍼블릭 클라우드 간의 높은 수준의 상호 연결성을 필요로 합니다. 워크로드가 환경 간에 흐르고 전체 시스템이 단일 엔티티로 작동합니다. 프라이빗과 퍼블릭 클라우드 간의 연결은 필수적이며, VPN, WAN, API를 통해 두 클라우드를 연결할 수 있습니다.
모놀리식 앱을 현대화하고 클라우드로 이전하는 것은 하이브리드 클라우드 채택의 가장 큰 과제 중 하나입니다.
우리의 주식 거래 앱이 모놀리식 온프레미스 시스템으로 시작했다고 가정해 봅시다. 이 앱은 Java 기반이었으며 퍼블릭-프라이빗 클라우드 설정과 동일한 서비스들을 가졌습니다:
어느 시점에서 아키텍트는 사용자 지연을 방지하기 위해 가상의 앱을 분해하고 클라우드에 배포해야 했습니다.
앱 분해는 모놀리식에서 어떤 부분을 분리하여 클라우드에 배포할지 결정하는 것에서 시작합니다. 일부 구성 요소가 다른 것보다 더 나은 선택입니다. 우리 예시에서 포트폴리오를 클라우드에 배포하면 불필요한 네트워크 홉이 많이 발생하고 지연이 더 악화될 것입니다.
UI를 클라우드로 이동하는 것은 좋은 옵션입니다. 지연이 주요 문제이므로 앱의 프론트엔드를 여러 위치에 배포하면 더 나은 사용자 경험을 제공할 수 있습니다.
클라우드로 갈 조각을 정했다면 다음 단계는 리팩토링(Refactoring)입니다. 아키텍트는 서비스 간 통신 경로를 유지할 수 있는 접착 코드(glue code)를 만들어야 합니다. UI를 리팩토링한 후 서비스를 퍼블릭 클라우드에 배포할 수 있습니다. 새로운 흐름을 테스트하면서 사용자의 작은 비율만 클라우드로 유도합니다.
퍼블릭 클라우드 설정이 오류 없이 완료되면, 이전 UI 부분을 폐기(Deprecate)하고 모든 트래픽에 클라우드를 사용하기 시작할 수 있습니다. 이제 다른 서비스를 마이그레이션하고 하이브리드 클라우드 아키텍처를 확장하는 것을 고려할 수 있습니다.
하이브리드 시스템에서 클라우드 보안은 팀이 서로 다른 환경과 그 사이를 이동하는 데이터를 보호해야 하므로 까다롭습니다. 하이브리드 클라우드 아키텍처 설계 시 두 가지 주요 보안 우려 사항이 있습니다:
출발점은 남북(North-South) 및 동서(East-West) 네트워크 트래픽과 관련된 클라우드 보안 위험을 결정하는 것입니다. 남북 트래픽은 최종 사용자에서 데이터 센터나 클라우드 환경으로 이동하는 모든 활동입니다. 동서 트래픽은 하이브리드 클라우드 구성 요소 간에 흐르는 데이터입니다.
온프레미스 구성 요소가 있는 하이브리드 클라우드 아키텍처에서는 경계 보안이 중요합니다. 베어 메탈 데이터 센터나 프라이빗 클라우드를 실행 중이든, 경계에 다음이 있는지 확인하세요:
퍼블릭 클라우드 보안은 주로 공급자의 책임이지만, 고객도 역할을 합니다. 예를 들어, 클라우드에 여러 서비스로 설정된 Kubernetes 워커가 있다면, 해당 구성 요소의 엔드포인트 보안과 요청 인증을 세밀하게 조정하는 것은 고객의 책임입니다.
하이브리드 클라우드 아키텍처에서 동서 트래픽을 보호하려면 환경 간 안전한 통신을 보장해야 합니다. 네트워크 세분화는 동서 트래픽을 보호하는 좋은 전술입니다. 사용자, 관리자, 프로세스가 접근할 수 있는 세그먼트를 제한하는 엄격한 정책을 만드세요.
Kubernetes 환경에서 마이크로 세분화는 마이크로서비스 간 요청에 TLS 인증서를 설정해야 합니다. 요청과 데이터(인플라이트 및 저장 데이터 모두)를 수명 주기 초기에 가능한 한 빨리 암호화하세요. 또 다른 Kubernetes 모범 사례는 초기 인증 후 추가 검증 단계를 추가하는 승인 컨트롤러(admission controller)를 설정하는 것입니다.
프라이빗 클라우드는 각각 고유하고, 모든 퍼블릭 클라우드 공급자가 서로 다른 서비스를 제공하므로, 만능 하이브리드 솔루션은 없습니다. 하지만 모든 하이브리드 클라우드는 전통적 하이브리드 클라우드 아키텍처와 현대적 하이브리드 클라우드 아키텍처라는 두 가지 주요 유형 중 하나에 해당합니다.
전통적 하이브리드 클라우드 아키텍처는 데이터 센터를 프라이빗 클라우드로 변환하는 데 중점을 둡니다. 온프레미스 설정이 준비되면 팀은 퍼블릭 클라우드와의 연결을 설계하여 원활한 워크로드와 데이터 흐름을 만듭니다. 이 통합 IT 인프라는 다음과 같은 경우에 이상적입니다:
일반적으로 전통적 하이브리드 클라우드 아키텍처는 미리 패키지된 솔루션이나 엔터프라이즈급 미들웨어에 의존하여 환경 전반에서 클라우드 리소스를 통합합니다. 중앙 콘솔과 통합된 클라우드 모니터링 도구가 설정을 건강하게 유지합니다.
현대적 하이브리드 클라우드 아키텍처는 구성 요소 간의 연결성보다 워크로드의 이동성에 더 중점을 둡니다. 이렇게 하면 시스템이 모든 작업에 가장 적합한 환경을 원활하게 사용할 수 있습니다.
이 유형의 하이브리드 클라우드 아키텍처는 조직이 클라우드 네이티브 기술을 활용하고 마이크로서비스를 사용하여 앱을 더 작고 재사용 가능한 구성 요소로 분해할 수 있게 합니다. 마이크로서비스는 서로 다른 클라우드와 공급자 전반에서 일관되고 신뢰할 수 있는 배포, 관리, 성능을 보장합니다.
현대적 하이브리드 클라우드 아키텍처에서는 퍼블릭과 프라이빗 클라우드 간의 경계가 덜 뚜렷합니다. 많은 공급자가 이제 고객의 온프레미스 데이터 센터에서 실행되는 퍼블릭 클라우드 서비스를 제공합니다. 전통적으로 온프레미스에서 실행되던 프라이빗 클라우드는 이제 다음에서 작동할 수 있습니다:
Infrastructure-as-code(IaC)는 현대적 하이브리드 클라우드 아키텍처의 중요한 측면입니다. IaC는 개발자가 새로운 환경을 신속하고 온디맨드로 구축할 수 있게 합니다.
하이브리드 클라우드 아키텍처를 설계하기 전에 아래 체크리스트를 고려하여 계획에 함정이 없는지 확인하세요.
하이브리드 클라우드는 서로 다른 환경 간의 복잡한 통합에 의존하므로, 고강도 워크로드와 분산 시스템에 이상적입니다. 앱에 강렬한 워크로드가 없고 흐름 중첩이 필요하지 않다면, 더 단순한 클라우드 모델을 배포하는 것이 더 나은 옵션일 수 있습니다.
앱과 사용자 기반이 성장하면 성능 수준을 유지하기 위해 하이브리드 클라우드로 확장을 고려하세요.
각 워크로드가 어떻게, 어디서 실행될지 결정하여 아키텍처 설계를 시작하세요. 이 계획은 다음 사이의 섬세한 균형을 요구합니다:
각 워크로드에 사용할 환경을 계획할 때 다음 요소를 고려하세요:
회사가 민감한 데이터를 처리한다면, 해당 정보를 어디에 저장할지, 어떤 시스템이 중요한 데이터에 접근할지 계획하세요. 또한 일부 레거시 시스템이 클라우드 환경에서 올바르게 작동하지 못할 수 있는지 고려하세요.
워크로드를 처리할 수 없는 플랫폼에 하이브리드 클라우드를 구축하면 향후 비용이 많이 드는 문제가 발생할 수 있습니다.
SaaS 파트너를 찾는 팀은 더 큰 오류 여유가 있지만, PaaS 또는 IaaS 공급자를 통해 앱을 구축하려는 회사는 처음부터 올바른 선택을 하여 심각한 벤더 락인 문제를 피해야 합니다. 클라우드 서비스 공급자를 선택할 때 다음을 고려하세요:
클라우드 운영 체제는 팀이 단일 도구 세트를 통해 하이브리드 환경을 모니터링하고 관리할 수 있게 합니다. 클라우드 OS는 관리를 단순화하고 민첩성을 부여해야 하므로, 개발자의 요구에 맞는 소프트웨어를 선택하세요. 가장 인기 있는 옵션은 다음과 같습니다:
올바른 데이터 관리 접근 방식을 제공하는 도구를 기반으로 클라우드 OS를 선택하세요. 이상적으로는 OS가 전체 IT 직원을 재교육할 필요가 없어야 합니다.
보안 제어와 정책을 하이브리드 클라우드 아키텍처의 기본 요소로 다루세요. 보안은 사후 고려 사항이 아니어야 하므로, 적절한 보호 수준이 모든 환경의 빌딩 블록이 되도록 하세요.
설계 프로세스 초기에 사이버 보안 위험에 대해 생각하세요. 클라우드 시스템을 구축할 때 처음부터 보안을 고려하고 싶다면 DevSecOps가 좋은 접근 방식입니다.
하이브리드 클라우드 아키텍처는 클라우드를 기존 IT 인프라에 연결하여 기업이 앱을 현대화할 수 있게 합니다. 이 접근 방식은 클라우드 컴퓨팅을 활용하면서 IT 설정을 엄격하게 통제하려는 모든 회사에 이상적인 옵션입니다.
클라우드 컴퓨팅
페이지 응답 시간 1초 차이가 고객 기반의 최대 7%를 잃게 할 수 있으므로, 올바른 호스팅 모델 선택은 중요한 비즈니스 결정입니다. 최고 수준의 성능과 가동 시간을 원한다면 클라우드와 전용 서버가 두 가지 인기 있는 선택이지만, 이 호스팅 모델은 서로 다른 사용 사례에서 탁월합니다. 어느 것이 귀사의 비즈니스 요구에 적합한 옵션일까요? 이 기사는 클라우드와 전용 서버의 차이점을 설명하고 두 호스팅 유형의 특징을 개괄합니다. 정보에 입각한 결정을 내리고 사용 사례, 비즈니스 요구, 예산에 맞는 호스팅 옵션을 식별하는 데 필요한 모든
클래식한 하드웨어 기반 설정과 비교할 때, 클라우드 컴퓨팅 아키텍처는 훨씬 더 많은 유연성, 설계 선택권, 비용 절감 기회를 제공합니다. 그러나 이러한 이점은 대가를 치르는데, 클라우드 플랫폼은 일반적인 온프레미스 물리적 인프라보다 이해하기 더 복잡하고 더 많은 움직이는 부품을 가지고 있기 때문입니다. 이 글은 클라우드 컴퓨팅 아키텍처 입문서로, 클라우드 환경 내에서 작동하는 구성 요소들을 다룹니다. 계속 읽어보시면 서로 다른 시스템들이 어떻게 협력하여 기능적인 클라우드를 만들고 최종 사용자에게 온디맨드 IT 리소스(서버, 앱, 데
