단일 클라우드 환경의 기능만으로도 비즈니스에 도움이 된다면, 여러 클라우드의 기능을 이용하면 더 좋을 수밖에 없지 않겠는가?

멀티클라우드 아키텍처가 여러 클라우드 서비스 업체의 특화된 기능을 활용할 수 있는 최상의 환경을 제공한다는 것은 사실이지만, 한 가지 문제가 있다. 기업의 개발 프랙티스가 새로운 환경에 도전할 준비가 되어 있는 경우에만 해당된다.

멀티클라우드용 코드를 작성하는 것은 기존 클라우드 컴퓨팅과는 전략, 아키텍처, 운영 측면에서 큰 변화를 의미한다. 컨테이너 오케스트레이션부터 통합 가시성, 내부 도구에 이르기까지 개발 프로세스의 모든 부분이 인프라의 복잡성에 맞게 진화해야 한다.

Infoworld는 이를 제대로 수행하고 있는 엔지니어링 책임자 및 클라우드 아키텍트와 이야기를 나눴는데, 이들 전문가는 때로 실수도 했다고 인정했다. 현장 전문가들이 그동안의 성공과 실수로부터 얻은 교훈을 확인해 보자.

멀티클라우드 공략 계획 세우기

개발팀이 멀티클라우드 환경을 위한 코드를 한 줄 작성하기 전에 왜 그렇게 해야 하는지를 알아야 하며, 이는 관리의 영역에 속한다.

플루럴사이트(Pluralsight)의 수석 클라우드 전략가인 드루 퍼먼트는 “멀티클라우드는 개발자의 문제가 아니다”라며, “개발팀이 특정 클라우드 기능을 언제, 어디서, 왜 사용하는지 정의하는 명확한 클라우드 운영 모델이 필요한 전략 문제다”라고 강조했다. 이런 모델이 없으면 기업은 높은 비용, 열악한 보안, 궁극적으로는 프로젝트 실패로 이어질 위험이 있다고 경고했다. 이를 방지하려면 기업은 비즈니스 목표에 부합하고 멀티클라우드 결정에 대한 소유권과 책임을 명확하게 할당하는 전략적 프레임워크에서 시작해야 한다.

멀티클라우드 환경을 운영하면 기능과 유연성 측면에서 분명한 이점이 있지만, 복잡한 프로세스를 거쳐야 한다. 성공적인 멀티클라우드 개발을 위한 5가지 핵심 사항은 다음과 같다.

• 성공적인 멀티클라우드 도입은 특정 클라우드 기능을 언제 어디에 왜 사용하는지를 정의하는 명확한 클라우드 운영 모델을 세우는 것부터 시작한다.
• 완전한 서비스 업체 중립성을 목표로 삼지 않는다. 과도한 엔지니어링으로 이어질 수 있다. 개별 클라우드 서비스 업체의 기능을 그대로 이용하면서 핵심 기능과 공통 서비스를 추상화하는 것이 좋다.
• 쿠버네티스나 도커 같은 기술은 표준화된 배포를 위한 기반이며, 핵심 비즈니스 로직이 여러 클라우드 간을 이동할 수 있도록 보장해 준다.
• 이동성을 유지하고 업체 종속을 줄이기 위해 클라우드 API/SDK를 내부 라이브러리에 포함시키고 주 코드베이스에 대한 범용 인터페이스를 노출하고 특정 클라우드에 대한 의존성을 격리한다.
• 멀티클라우드 환경은 복잡하며 실패하기 쉽다. 이런 위험을 줄이기 위해 로깅과 모니터링을 중앙집중화하고 배포 프로세스를 자동화한다. 그리고 API 타임아웃이나 지연시간 증가 같은 공통의 실패 지점을 예상해 설계한다.

이 프로세스는 하향식으로만 진행해서는 안된다. 레베뉴 옵스(Revenue Ops)의 CEO 헤더 데비이스 램은 부서 간 커뮤니케이션의 필요성을 강조한다. 데이비스 램은 “서로 대화하라”라며, “멀티클라우드 프로젝트에는 개발자, 운영, 보안, 때로는 법무팀까지 포함된다. 문제는 대개 잘못된 코드가 아니라 잘못된 의사소통에서 비롯된다. 정기적인 점검과 솔직한 대화가 큰 도움이 된다”라고 말했다.

이 계획 프로세스는 멀티클라우드가 왜 기업에 좋은 아이디어인지, 그리고 인프라 내에서 특정 플랫폼을 최대한 활용하는 방법에 대한 질문으로 시작해야 한다.

퍼먼트는 “멀티클라우드의 궁극적인 역설은 클라우드 대혼란을 일으키지 않으면서 클라우드 기능을 최적화하는 방법이다”라며, “첫 번째 경험 법칙은 여러 클라우드에서 공통적으로 사용되는 핵심 공유 서비스를 추상화하는 동시에 고유한 고객 가치를 제공하는 클라우드별 서비스를 분리하는 것이다. 예를 들어, 모든 클라우드에서 표준 인증 및 컴퓨팅 계층을 사용하는 동시에 아마존 S3와 아테나(Athena)를 사용하는 대규모 데이터 세트의 쿼리 비용과 성능을 최적화하는 것이다”라고 설명했다.

범용 클라우드 vs. 전문 클라우드

특정 클라우드 서비스 업체에 밀접하게 연결된 코드를 언제 어떻게 작성해야 하는지, 크로스 플랫폼 코드를 언제 작성해야 하는지에 대한 질문은 멀티클라우드 개발팀의 고민 대부분을 차지할 것이다. 그리고 많은 팀이 클라우드 간에 코드를 완전히 이식할 수 있도록 만들려고 노력한다.

데이비스 램은 “좋은 생각이지만 실제로는 과도한 엔지니어링과 더 많은 골칫거리로 이어질 수 있다”고 지적한다. 또, 개발 속도가 느려지고 복잡성이 증가할 정도로 인프라를 추상화하는 것에 대해 경고했는데, “누구든 어디에서나 작동할 수 있도록 추가 계층을 만들고 있다면, 잠시 멈춰야 할 때이다”라고 덧붙였다.

페야라 서비스(Payara Services)의 수석 소프트웨어 엔지니어인 패트릭 두디츠도 이에 동의한다. 두디츠는 통일성을 구현하기 위한 과도한 추상화라는 잘못된 시도를 하는 경우가 흔하다며, “아키텍처를 클라우드 기능의 ‘최저 공통 분모’로 제한하려는 것은 일반적인 실수 중 하나이다. 실제로는 각 클라우드의 강점을 포용하는 것이 더 성공적인 전략이다”라고 강조했다.

두디츠는 서비스가 동일한 구현의 필요성에 의해 서로 얽매이지 않고 각각의 클라우드에서 독립적으로 운영될 수 있는 자율성을 염두에 두고 시스템을 설계할 것을 조언했다.

엄격한 통일성이 아닌 자율성이라는 원칙은 톰슨 로이터의 플랫폼 엔지니어링 지원 부문 부사장 매트 디미치가 멀티클라우드 설계에 접근하는 방식에서도 핵심적인 역할을 한다. 디미치는 “우리의 목표는 애플리케이션을 실행하는 플랫폼에서 민첩성을 확보하는 것이지만, 완전한 통일성은 원하지 않는다”라며, “매년 더 저렴하고 빠른 컴퓨팅의 혁신이 이뤄지고 있으며, 이를 더 빨리 활용할수록 고객에게 더 많은 가치를 제공할 수 있다”고 설명했다. 디미치는 개별 클라우드 서비스 업체의 기본 서비스를 적절히 활용하면서 동시에 긴밀한 결합을 피하는 데 주의를 기울이는 균형 잡힌 접근 방식을 강조한다.

데이비스 램은 비즈니스 로직과 인프라를 분리할 것을 제안하며, “API, 컨테이너화된 앱, 파이썬이나 노드와 같은 공유 언어 등 핵심 비즈니스 로직은 이식성이 정말 중요하다. 하지만 인프라나 오케스트레이션에 관해서는 특정 클라우드가 가장 잘하는 것을 활용하라”라고 말했다.

두디츠도 “여러 클라우드를 활용하는 이유는 의도한 애플리케이션 내에서 특정 작업에 대한 이점이 분명하기 때문이다. 단순히 여러 서비스 업체에 동일한 스택을 미러링하는 것만으로는 진정한 복원력을 달성하기 어렵고 새로운 복잡성을 초래하는 경우가 많다”라고 덧붙였다.

크로스 플랫폼 코드 작성

핵심 비즈니스 로직을 모든 클라우드에서 최대한 이식 가능하게 만드는 비결은 무엇일까? 거의 모든 전문가가 컨테이너 오케스트레이션 플랫폼인 쿠버네티스를 언급했다.

앤시스(Ansys)의 수석 데브옵스 엔지니어인 라다크리슈난 크리슈나 크리파는 애저, AWS, 온프레미스 환경을 아우르는 쿠버네티스 기반 플랫폼 구축을 지원해 왔다. 크리파는 “쿠버네티스와 도커 컨테이너를 사용해 배포를 표준화한다. 이를 통해 코드를 한 번 작성하면 최소한의 변경만으로 AKS, AWS EKS 또는 온프레미스 클러스터에서 실행할 수 있다”라고 설명했다.

벨럼(Vellum)의 CTO인 시드 시세팔리도 같은 생각이다. 시세팔리는 “우리는 서비스 업체별 서비스가 아닌 쿠버네티스를 사용하므로 쿠버네티스 클러스터가 있는 곳이면 어디든 일관되게 배포할 수 있다”라고 밝혔다. 벨럼은 템플릿화된 헬름 차트를 사용해 클라우드별 구성을 추상화하고 KOTS와 같은 도구를 사용해 배포 사용자 정의를 간소화한다.

미리어드360(Myriad360)의 대표 솔루션 아키텍트인 닐 와일리에게 쿠버네티스는 기반에 불과하다. 와일리는 “쿠버네티스를 기반으로 구축하면 헬름을 사용해 애플리케이션 정의와 배포를 표준화할 수 있으며, 일반적으로 아르고CD 같은 도구를 사용해 깃옵스 워크플로우를 통해 롤아웃을 자동화한다”라며, 이런 접근 방식은 “진정한 워크로드 이동성”을 제공하는 동시에 CI/CD 파이프라인을 통해 일관되고 검증된 배포를 보장한다고 설명했다.

CI/CD에 대해 말하자면, 코드의 개발 파이프라인을 지원하는 도구는 코드가 실행될 인프라만큼이나 중요하다. 크리파는 깃허브 액션(Actions)이나 테라폼 클라우드 같은 클라우드 중립적인 도구를 사용해 파이프라인을 표준화할 것을 권장한다. 크리파는 “앤시스는 주로 애저를 사용하지만 깃허브 액션과 같은 도구를 사용하면 일관된 워크플로우로 여러 환경에서 빌드 및 인프라를 관리할 수 있다”라고 설명했다. 이런 일관성은 서비스 업체 간에 워크로드를 이동하거나 하이브리드 환경으로 배포할 때 개발자의 부담을 줄이는 데 도움이 된다.

하지만 아무리 코드를 표준화하더라도 개별 클라우드 서비스 업체의 API 및 SDK와 인터랙션해야 한다. 에이도라(Aidora)의 CTO인 아난트 아가왈은 이식성을 희생하지 않으면서도 이를 수행할 수 있는 패턴, 즉 어댑터 계층을 사용한다. 아가활은 “우리는 모든 클라우드 API 또는 SDK를 종속성처럼 취급한다. 내부 라이브러리로 래핑하고 나머지 코드베이스에 깔끔하고 일반적인 인터페이스를 노출한다”라고 설명했다. 이런 접근 방식은 클라우드별 로직을 격리하고 교체할 수 있어서 핵심 애플리케이션 로직을 유지 관리하기 쉽고 플랫폼 종속성에 대한 저항력을 높인다.

오픈소스 커뮤니티는 특히 독점적인 클라우드 기능으로 인해 마찰이 발생했던 부분을 메우는 데도 도움을 주고 있다. 와일리는 서버리스 워크플로우 프로젝트를 예로 들며, “CNCF 환경을 주시하며 새로운 프로젝트를 살펴보는 것을 좋아하는데, 일반적으로 새로운 프로젝트가 해결하려고 하는 것은 바로 이런 ‘고질적인’ 점이다”라고 강조했다.

멀티클라우드 복잡성 극복하기

이기종 멀티클라우드 환경은 복잡하며, 개발 프로세스가 이런 특성을 소화해야 한다는 것은 의심의 여지가 없다. 가시성은 특히 중요하며, 가시성을 제대로 확보하려면 로그와 알림을 중앙집중화하는 것부터 시작해야 한다. 에이도라의 아가왈은 “에이도라는 모든 로그를 통합 가시성 플랫폼(데이터독 기반)으로 라우팅하고 통합 뷰를 생성한다”라며, “최신 도구로는 완벽한 커버리지를 확보하기가 어렵지만 중앙집중화를 통해 인시던트를 빠르게 분류하고 클라우드 서비스 업체 전반에 걸쳐 가시성을 유지할 수 있다”라고 설명했다.

페야라의 두디츠도 비슷한 접근 방식을 강조한다. 두디츠는 “멀티클라우드 환경 전반에서 높은 수준의 메트릭을 위해 서비스 업체 중립적인 중앙 대시보드에 투자할 것을 권장한다”라며, “이 통합 뷰는 개발자와 운영팀이 서비스 업체별 도구를 통해 심층적인 진단을 수행하더라도 서비스 업체 전반의 문제를 신속하게 발견하는 데 도움이 된다”라고 강조했다.

레네뷰 옵스의 데이비스 램은 멀티클라우드 환경에서 가장 중요한 도구 중 하나로 우수한 로깅을 꼽는다. 데비이스 램은 “하나의 클라우드를 디버깅하는 것만으로도 충분히 어렵다. 서너 개의 클라우드에서 작업하는 경우, 로깅과 모니터링이 잘 이뤄지면 몇 시간 또는 며칠의 작업을 절약할 수 있다. 초기에 바로잡아야 한다”라고 강조했다. 하지만 로그를 수집하고 알림을 설정하는 것을 목적으로 하지 말라고 경고한다.

자동화는 멀티클라우드 개발 환경을 길들일 수 있는 또 다른 도구이다. 아가왈은 “서비스 업체 간 조율은 오류가 발생하기 쉽기 때문에 배포 프로세스는 완벽해야 한다”라며, “에이도라는 스키마 변경, 코드 배포 및 서비스 업데이트가 동기화되도록 깃허브 액션을 사용하여 모든 것을 자동화한다”라고 밝혔다.

또한 내부 AI 도구가 복잡한 멀티클라우드 워크플로우를 간소화할 수 있다는 점도 언급했다. 아가왈은 “내부 플레이북을 ‘이 서비스를 어디에 배포할 것인가?’ 또는 ‘어떤 서비스 업체가 파일 업로드를 처리할 것인가?’와 같은 상황에 맞는 질문에 즉시 답하는 맞춤형 GPT로 전환했다. 마찰을 더욱 줄이기 위해 동일한 규칙을 커서(Cursor)에 코드화해 개발자가 IDE 내에서 바로 인라인 안내를 받을 수 있도록 했다”라고 설명했다.

마지막으로 가장 중요한 것은 실패에 대비한 계획을 세우는 것이다. 데이비스 램은 “더 많은 클라우드와 서비스를 함께 연결할수록 일반적으로 연결 지점에서 문제가 발생할 가능성이 높아진다. 따라서 API 시간 초과, 인증 토큰 만료 또는 비정상적인 지연 시간 급증과 같은 문제가 더 자주 발생한다. 이런 종류의 장애를 드문 이벤트로 취급할 것이 아니라 예상해야 한다. 실제로 재시도해야 할 것과 그냥 실패하고 누군가에게 알려야 할 것을 생각해 보자. 모든 실패가 자동으로 재시도 루프 또는 폴백을 트리거해서는 안 됩니다. 때로는 프로세스를 멈추고 누군가의 주의를 환기시키는 것이 더 낫다”라고 설명했다.

데이비스 램은 “결국 멀티클라우드 개발은 지저분하지만, 이를 예상하고 계획한다면 더 나은, 더 강력한 코드를 작성할 수 있다”라며, “뭔가 고장 날 것을 전제하고 이를 생각하며 구축하라. 비관적인 것이 아니다. 현실적인 것이다”라고 강조했다.
dl-itworldkorea@foundryco.com