디지털 변환에 대한 놀라운 진실: 클라우드 카오스

이 글은 디지털 혁신으로 인해 발생하는 과제를 다루는 시리즈의 두 번째 블로그입니다.

• 디지털 변환에 대한 놀라운 진실

클라우드 카오스.

지금 어떤 똑똑한 엔지니어가 이 문구가 중복적이라고 말하고 있습니다. 결국 클라우드는 혼란 그 자체입니다. 클라우드는 거버넌스가 부족하고 앱을 보안하는 데 있어 방임주의적 접근 방식을 취하고 있으며, 잘 정의된 일정도 없이 푹신한 흰색 깊은 곳에 던져져 있습니다.

여기서 잠깐, 클라우드와 관련된 혼란은 기술적인 문제가 아니라 대부분 사람 과 프로세스의 문제라는 점을 기억해 두십시오.

이는 클라우드와 관련된 기술적, 적어도 건축적 과제가 없다는 것을 의미하지 않습니다. 그 중 일부는 가상 네트워킹의 복잡성과 관련이 있습니다. 하지만 대부분은 건축적입니다. 이러한 구조적 과제 중 하나는 애플리케이션별 초점을 맞춘 클라우드의 특성과 관련이 있습니다.

생각해 보면, 퍼블릭 클라우드와 그 배포 모델은 이상적인( 플라톤주의자들이 부르는 '클라우드 형태' ) 클라우드 형태로 여겨집니다. 즉, 프라이빗 클라우드 역시 이 원칙을 따라야 하며 동일한 특성을 가져야 합니다.

즉, API와 셀프 서비스 프로비저닝을 의미합니다. 대시보드 및 웹 기반 콘솔. 하지만 이는 단일 애플리케이션에만 초점을 맞춘 배포 방식으로의 아키텍처 전환을 의미합니다.  

클라우드에서는 앱별 아키텍처가 일반적입니다. 서비스는 한 번에 하나의 앱을 지원하도록 배포되고 구성되며, 해당 서비스를 통과하는 사용자에서 엔드포인트까지 단일 데이터 경로를 생성합니다. 이는 상당수의 네트워크와 애플리케이션 서비스 인프라가 공유되는 기존 데이터 센터 네트워크 설계와는 극명한 대조를 이룹니다.

퍼블릭 클라우드와 마찬가지로 앱 중심인 DevOps 및 Agile 개발 세계에서 '공유 인프라'라는 개념은 문제가 됩니다.

기존의 공유 인프라와 네트워크는 '출입구에서 앱까지 이르는 하나의 진정한 경로'를 제공합니다. 오늘날의 빠르게 움직이는 디지털 세계에서 이러한 접근 방식으로 인해 발생하는 과제는 다음과 같습니다.

• 인프라 버전 정렬. 어떤 앱은 업그레이드나 패치로 제공되는 기능이 필요할 수 있고, 다른 앱은 기존 버전에 따라 달라질 수 있습니다. 공유 인프라는 일반적으로 동일 시스템에서 다양한 버전을 허용하지 않으므로, 한 애플리케이션을 방해하여 다른 애플리케이션을 선호하게 만들 수 있습니다.
• 배치 일정이 엇갈립니다. 공유 리소스에 영향을 미치는 경우 기업은 애플리케이션 이해 관계자가 배포 일정의 충돌을 해결하려고 시도하는 협상 단계를 시작합니다. 이 과정은 길 수 있으며(그리고 항상 고통스럽습니다) 일정 충돌로 인해 새로운 앱이나 업데이트가 지연되면 누구도 이득을 얻지 못합니다. 
• 폭발 반경. 말할 것도 없이, 내 앱이 공유 시스템을 실패하게 만들면 해당 시스템을 의존하는 모든 앱도 실패하게 됩니다. 공유 인프라의 폭발 반경은 매우 크며, 이는 IT 부서 외부인에게 배포 파이프라인에 대한 접근성을 확대하려는 의지를 약화시키는 중요한 요인입니다.
• 문제 해결. 모인 통나무를 헤치려고 하는 것은 고통스럽다. 매우 성공적인 회사들은 방대한 로그를 마이닝하고 데이터를 애플리케이션별 흐름으로 분리하는 능력만을 바탕으로 구축되었습니다. 공유 시스템의 문제 해결은 복잡하고 시간이 많이 걸리며, 현대 IT의 중요한 KPI인 평균 문제 해결 시간에 부정적인 영향을 미칩니다.

클라우드에서는 이런 일이 일반적으로 문제가 되지 않습니다. 앱은 일반적으로 자체 환경에서 자체 일정에 따라 배포되므로 앱당 하나의 경로가 있습니다. 이는 종종 서로 다른 팀에 의해 배포됩니다. 

우리의 정신 건강(과 데이터 센터)을 지키기 위해서는 프라이빗 클라우드든 아니든 사내에서 이러한 접근 방식을 채택해야 합니다.

여전히 공유 네트워크 서비스를 사용하게 됩니다. 방화벽, IPS/IDS, DDoS 및 사용자 검사는 애플리케이션과 관련해 매우 중립적이며 회사 전체에 적용될 수 있습니다(적용해야 합니다). 그 외의 모든 것에는 앱별(원한다면 앱별) 서비스와 인프라가 있습니다. 이러한 논리적 분리는 앱에 가까운 보다 변동성이 크고 불안정한 환경을 활성화하는 동시에 비즈니스의 안정성과 보안을 유지합니다. 또한 최신 앱에 필요한 속도와 지원이 필요하지 않은 기존(레거시 및 헤리티지) 앱에 대한 데이터 경로도 보존합니다. 앱별 네트워크는 프라이빗 클라우드이거나, 여러 컨테이너 클러스터이거나, 그 조합일 수 있습니다.

두 가지를 결합하면 보다 안정적이고 회복성이 뛰어나며 유연하고 빠른 네트워크가 탄생합니다. 

네트워크에 대한 앱별 접근 방식은 공유 접근 방식과 최신 앱 아키텍처 및 제공 모델이 결합되어 발생하는 문제를 완화하는 것 외에도 다양한 이점이 있습니다.

• 개별 파이프라인 및 일정 배포가 준비되면 내 앱이나 인프라에만 영향을 미치기 때문에 배포 일정을 직접 조정할 수 있습니다. 이는 최신 데이터 센터에서 지원해야 하는 다양한 일정을 지원할 수 있는 유연성을 제공합니다.
• 제한된 폭발 반경. 내 배포로 인해 전용 시스템에 충돌이 발생하면 전적으로 내 책임입니다. 다른 앱에는 영향을 미치지 않습니다. 이러한 전용 앱별 데이터 경로 접근 방식은 모든 시스템의 로그와 오류 메시지가 나와 내 애플리케이션에 속한다는 확신을 가질 수 있으므로 문제 해결이 더욱 쉬워집니다.
• 규모는 플랫폼 리소스에 국한되지 않습니다. 매우 불안정하고 역동적인 세상에서 다음 방문자가 언제 올지, 어떤 콘텐츠가 바이러스처럼 퍼질지, 아니면 하늘이 금하시는 일이지만 공격을 받을지 아는 것은 거의 불가능합니다. 원인이 무엇이든, 공유 시스템(하드웨어나 소프트웨어)의 앱에 대한 수요가 급증하면 플랫폼에서 사용할 수 있는 리소스로 확장성이 제한됩니다. 앱별 아키텍처를 사용하면 이러한 제약이 완화되고 수요를 충족하기 위해 필요에 따라 개별 구성 요소를 확장할 수 있습니다.
• 코드 모델로서 진정한 인프라를 지원합니다. 공유 시스템은 앱별 정책이 적용된 기본 구성일지라도 공유 구성을 사용합니다. 해당 모델은 인프라를 코드 모델로 구현하려고 할 때 혼란을 야기할 수 있으며, 특히 여러 앱이 동시에 업데이트하려고 할 때 더욱 그렇습니다. 변경 사항은 경고 없이 다른 앱에 영향을 미칠 수 있으며, 필요할 때 다른 사람이 리소스를 잠그면 커밋 및 복제 작업이 실패할 수 있습니다. 앱별 아키텍처는 배포 아티팩트가 하나의 앱에만 속하고 앱 소유자(dev, DevOps, NetOps 또는 )가 적절하게 관리할 수 있도록 보장합니다.

앱별 아키텍처가 디지털 혁신으로 인해 발생하는 모든 문제를 해결할 수는 없지만, 클라우드로 인해 발생하는 혼란을 줄이는 데는 큰 도움이 될 수 있습니다. 이는 보안을 표준화 하고 대부분 기업이 전환하고 있는 멀티 클라우드 환경을 지원할 수 있는 더 큰 기회를 제공합니다.

이 시리즈의 다음 게시물을 기대하세요. 이 게시물에서는 디지털 혁신으로 인해 발생하는 시장 압박으로 인해 보안을 건너뛰는 사람들을 다루는 방법을 자세히 살펴보겠습니다.