클라우드 기반: 더 빠르고 더 수익성 있는 클라우드 마이그레이션을 위한 십계명

[힘힘]

클라우드 기반: 더 빠르고 더 수익성 있는 클라우드 마이그레이션을 위한 십계명

2022년 4월 21일| 기사

Aaron Bawcom , Sebastian Becerra , Beau Bennett , Bill Gregg 작성

공유하다

인쇄

다운로드

구하다

조직이 올바른 클라우드 기반을 구축하는 데 투자하지 않는 한 클라우드 마이그레이션은 빠르게 실패합니다.

다운로드

기사(6페이지)

클라우드로 전환하는 많은 기업의 경우 단기 이익에 집중하면 장기적인 고통을 겪게 되고 클라우드의 1조 달러로 추정되는 가치 잠재력 중 훨씬 더 큰 부분을 포착하지 못하게 됩니다 . 일반적으로 시스템 통합업체의 지원을 받는 IT 부서가 초기 이점을 포착하기 위해 가능한 한 빨리 일련의 애플리케이션을 클라우드로 마이그레이션할 때 발생합니다. 그 단기적인 초점은 종종 중대한 결과를 가져옵니다.

공유하다

사이드바

클라우드 기반이란 무엇입니까?

그 범인? 회사의 전체 클라우드 전략의 성공을 결정하는 섹시하지 않지만 중요한 구조적 토대인 클라우드 기반에 대한 관심 부족(사이드바 "클라우드 기반이란 무엇입니까?" 참조). 몇몇 대형 은행은 그 대가를 치르고 있으며, 처음부터 올바른 기본 아키텍처를 마련하지 않았기 때문에 수백 명의 클라우드 엔지니어를 고용해야 합니다.

혁신 엔진 의 일부로 견고한 클라우드 기반을 구축한다고 해서 재정적 수익을 지연시키거나 상당한 리소스를 투자하는 것은 아닙니다. 수행해야 할 중요한 단계를 알고 이를 잘 실행하면 됩니다. 우리의 경험에 따르면 견고한 클라우드 기반을 마련한 기업은 클라우드 프로그램을 지연시키지 않고도 클라우드 마이그레이션 및 채택 속도를 잠재적으로 8배 가속화하고 장기적으로 마이그레이션 비용을 50% 절감하는 형태로 이익을 얻습니다.

최고의 소비재(CPG) 회사는 클라우드 마이그레이션 프로그램이 상당한 지연을 겪고 있었습니다. 각 애플리케이션을 마이그레이션하는 데 최대 2개월이 걸렸습니다. 비즈니스의 일부가 매각됨에 따라 재무 및 법무 부서는 회사에서 신속하게 회사에서 격리하도록 압력을 가했습니다. 클라우드 기반의 결함으로 인해 지연이 발생하고 있음을 깨닫고 클라우드 기반 강화에 집중하기 위해 마이그레이션을 일시 중지하는 반직관적인 결정을 내렸습니다.

예를 들어 중요한 인프라 기능을 자동화하고 보안 소프트웨어를 배포하여 규정 준수를 자동화하고 재사용 가능한 애플리케이션 패턴을 배포하고 격리 영역을 생성하여 워크로드를 서로 격리하고 한 영역의 잠재적인 문제가 확산되는 것을 방지했습니다. 이러한 개선 사항이 적용되자 회사는 응용 프로그램을 빠르고 안전하게 마이그레이션할 수 있었으며 단일 응용 프로그램은 몇 주가 아니라 며칠이 걸렸습니다.

올바른 클라우드 기반을 구축하기 위한 10가지 조치

강력한 클라우드 기반을 구축하는 것은 "비즈니스 수행 비용"이 아닙니다. 속도와 가치 측면에서 상당한 보상을 거둘 중요한 투자입니다. 다음 10가지 조치는 이 기반을 구축하는 데 가장 중요합니다.

1. 가장 빠른 'idea-to-live' 프로세스를 가능하게 하는 기술 최적화

워크로드가 클라우드에 있든 기존 데이터 센터에 있든 많은 회사는 지연과 좌절을 초래하는 구식의 관료적인 작업 방식을 가지고 있습니다. 클라우드 기반은 안전과 보안을 희생하지 않으면서 아이디어가 프로덕션 환경에서 시작부터 실행까지 빠르게 진행될 수 있도록 구성되어야 합니다.

실제로 이는 샌드박스 요청, 방화벽 변경, 많은 수의 격리된 네트워크의 온디맨드 생성, ID 및 액세스 관리(IAM), 애플리케이션 등록, 인증서 생성, 규정 준수, 등등. 이러한 단계를 자동화하는 것은 클라우드에서와 마찬가지로 기존 데이터 센터에서도 중요합니다. 그러나 클라우드는 자동화를 더 쉽게 만드는 고유한 도구를 제공하고 클라우드로의 이동으로 인해 조직이 전체 전략을 재고하게 되므로 마이그레이션 프로세스의 시작이 IT 운영 방식을 변경하기에 적절한 시기인 경우가 많습니다.

Cloud by McKinsey 에 대해 자세히 알아보시겠습니까 ?

2. 확장할 수 있도록 클라우드 아키텍처 설계

기업이 제대로 한다면 큰 변화 없이 500명 이상을 지원하도록 확장할 수 있는 5명을 기반으로 클라우드 아키텍처를 구축할 수 있습니다. 클라우드 공간이 커짐에 따라 잘 설계된 아키텍처는 더 많은 애플리케이션 패턴, 격리 영역 및 기능을 포함하여 더 많은 구성 요소를 수용할 수 있어야 합니다. 이 확장을 지원하려면 구성 요소 간에 간단하고 잘 설계된 인터페이스가 필요합니다. 이것은 처음에 제대로 하기 어렵기 때문에 이전에 대규모로 수행한 클라우드 아키텍처 엔지니어가 큰 이점입니다.

3. 아키텍처를 반영하는 조직 구축

Conway의 법칙 에 따르면 팀 구성 방식에 따라 팀이 개발하는 기술의 형태가 결정됩니다. IT 조직에는 팀을 위한 정해진 구조가 있으며 이로 인해 클라우드 아키텍처의 형태에 맞지 않는 것을 구축할 수 있습니다.

예를 들어 일부 회사에는 각 비즈니스 단위에 대해 별도의 클라우드 팀이 있습니다. 이로 인해 각 팀은 해당 비즈니스 단위에 대해 서로 다른 클라우드 기능을 구축하고 다른 비즈니스 단위에서 재사용할 수 있도록 설계하지 않을 수 있습니다. 이로 인해 한 팀의 변경 사항이 다른 팀의 사용에 영향을 미칠 때 속도 저하 및 지연이 발생할 수 있습니다.

IT는 먼저 클라우드 아키텍처를 설계한 다음 해당 구조를 기반으로 조직을 구축해야 합니다. 즉, 그룹 간의 종속성과 중복성을 줄이고 궁극적으로 낮은 비용으로 잘 설계된 구성 요소를 제공하기 위해 기본 팀, 격리 영역 팀 및 애플리케이션 패턴 팀이 있는 조직을 구축해야 합니다.

4. 이미 존재하는 클라우드 활용

많은 회사가 특정 클라우드 서비스 공급자(CSP)에 종속되는 것을 두려워하여 운영하므로 해당 위험을 완화할 방법을 찾습니다. 일반적인 패턴은 컨테이너에 대한 과도한 의존으로 비용과 시간이 많이 소요될 수 있으며 기업이 CSP에서 얻을 수 있는 진정한 이점을 실현하지 못하게 합니다. 이에 대한 한 가지 예는 클라우드 자체 복원 도구를 사용하는 대신 클라우드에서 컨테이너 플랫폼을 만든 회사입니다. 중단이 발생했을 때 영향이 너무 커서 시스템을 다시 온라인 상태로 만드는 데 며칠이 걸렸습니다. 결함이 비클라우드 도구의 핵심에 포함되었기 때문입니다.

제한된 잠금 시간 프레임을 정의하고 필요한 경우 신속한 전환을 가능하게 하는 관행과 시스템을 배치하는 것과 같이 CSP 잠금을 완화하는 다른 방법이 있습니다. 고유하지 않은 복원력 기능을 구축하려고 시도함으로써 회사는 본질적으로 경험, 전문 지식 또는 리소스 없이 CSP와 경쟁하고 있습니다. 이 문제의 근본 원인은 회사가 여전히 CSP를 소프트웨어 파트너가 아닌 하드웨어 공급업체인 것처럼 취급하는 경향이 있다는 것입니다.

5. 클라우드 서비스가 아닌 클라우드 제품 제공

기업에서 IT와 비즈니스의 클라우드 사용을 돕기 위해 내부 클라우드 서비스 팀을 만드는 것이 일반적입니다. 일반적으로 이러한 서비스 팀은 주문 처리 센터처럼 운영되며 승인된 클라우드 서비스에 대한 액세스 요청에 응답합니다. 비즈니스는 일관성 있는 아키텍처 없이 수십 개의 클라우드 서비스를 독립적으로 사용하게 되므로 복잡성, 결함 및 사용에 대한 투명성이 저하됩니다.

대신 기업은 애플리케이션 팀을 위해 간단하고 확장 가능하며 재사용 가능한 클라우드 제품을 만들고 관리하기 위해 숙련된 클라우드 설계자와 엔지니어로 구성된 전담 제품 팀이 필요합니다. 클라우드 제품을 중심으로 정렬함으로써 부과되는 제약은 비즈니스가 올바른 방식으로 올바른 기능을 사용하도록 하는 데 도움이 될 수 있습니다.

제품 팀에 클라우드 제품 인벤토리가 있으면 애플리케이션 팀이 이를 사용하여 클라우드 마이그레이션을 빠르게 추적하도록 장려할 수 있습니다. 그러나 각 애플리케이션 팀의 적성과 관심은 새로운 클라우드 제품을 얼마나 빠르고 쉽게 채택하는지에 영향을 미칩니다. 클라우드 경험, 기술 또는 관심이 거의 없는 팀은 단계별 지원이 필요한 반면 다른 팀은 지침이 거의 없이 빠르게 이동할 수 있습니다. 따라서 제품 팀은 클라우드 마이그레이션 과정에서 다양한 수준의 애플리케이션 팀 참여를 지원할 수 있는 운영 모델이 필요합니다.

하나의 효과적인 경로는 세 가지 수준의 참여(전시)를 제공합니다.

• 컨시어지 수준: 참여 팀은 애플리케이션 팀에 필요한 모든 것을 구축합니다.
• 포함된 수준: 중앙 클라우드 팀의 설계자는 애플리케이션 팀에 포함되어 올바른 애플리케이션 패턴을 구축하도록 돕습니다.
• 파트너 수준: 파트너 팀은 기본 기반의 핵심 기능(예: 네트워킹, 로깅 및 ID)을 사용하여 자체 격리 영역을 구축하고 실행합니다.

전시하다

우리는 장애가 있는 개인이 우리 웹사이트에 동등하게 접근할 수 있도록 노력합니다. 이 콘텐츠에 대한 정보를 원하시면 기꺼이 도와드리겠습니다. McKinsey_Website_Accessibility@mckinsey.com 으로 이메일을 보내주십시오.

클라우드 제품, 이를 지원하는 팀, 애플리케이션 팀이 제품 팀과 협력할 수 있는 모델을 설정함으로써 비즈니스는 클라우드 전략을 신중하게 확장할 수 있는 메커니즘을 갖출 수 있습니다 .

6. 애플리케이션 팀은 클라우드에서 애플리케이션을 설계하고 배포하는 방법을 재발명해서는 안 됩니다.

조직이 애플리케이션 팀에게 클라우드 공급자로 애플리케이션을 마이그레이션하도록 무료로 권한을 부여하면 결과적으로 전체 인벤토리의 지속적인 유지 관리를 어렵게 만드는 서로 다른 클라우드 기능 및 구성의 무리가 됩니다.

대신 조직은 애플리케이션의 배포 기능을 독립 실행형 제품으로 취급하여 애플리케이션 패턴을 사용하여 일반적인 문제를 해결해야 합니다. 애플리케이션 패턴은 공유 리소스 구성, 배포 파이프라인 표준화, 품질 및 보안 준수 보장을 담당할 수 있습니다. 애플리케이션 인벤토리를 지원하는 데 필요한 패턴의 수가 적을 수 있으므로 ROI를 극대화할 수 있습니다. 예를 들어, 한 대형 은행에서는 필요한 사용 사례의 95%를 충족하기 위해 단 10개의 애플리케이션 패턴만 성공적으로 사용했습니다.

McKinsey Insights의 클라우드

기사 읽기

7. 격리 영역을 사용하여 대상 변경 관리 제공

격리 영역은 애플리케이션이 있는 클라우드 환경입니다. 클라우드 마이그레이션을 가속화하기 위한 노력의 일환으로 CSP와 시스템 통합자는 일반적으로 모든 애플리케이션을 호스팅하는 단일 격리 영역에서 시작합니다. 하나의 애플리케이션을 지원하기 위한 구성 변경이 의도치 않게 다른 애플리케이션에 영향을 미칠 수 있기 때문에 이는 위험성이 높은 접근 방식입니다. 다른 극단(각 애플리케이션에 대해 하나의 격리 영역)으로 이동하면 구성 변경을 효율적으로 배포할 수 없으므로 많은 격리 영역에서 동일한 작업을 수행해야 합니다.

일반적으로 회사는 비즈니스 규모와 다음 질문에 대한 답변에 따라 5~100개의 격리 구역을 보유해야 합니다.

• 응용 프로그램이 인터넷에 직면합니까?
• 어떤 수준의 복원력이 필요합니까?
• 영역에서 실행되는 애플리케이션에 필요한 위험 보증 수준 또는 보안 태세는 무엇입니까?
• 법적인 목적을 위해 구역을 변경하는 방법에 대한 결정 권한을 가진 사업부는 무엇입니까?

8. 모든 CSP에서 사용할 기본 기능을 한 번 구축합니다.

대부분의 회사는 여러 클라우드에 있습니다. 이러한 혼합은 종종 한 워크로드의 약 60%, 다른 워크로드의 30%, 나머지는 세 번째 워크로드로 분류됩니다. 기업은 모든 CSP에서 동일한 기본 기능(예: 네트워크 연결 및 라우팅, ID 서비스, 로깅 및 모니터링)을 구축하는 대신 한 번 구축하고 모든 격리 영역에서 기능을 재사용해야 합니다. 기지에서 CSP.

9. 기본 기반의 또 다른 인스턴스를 배치하여 인수 통합 속도를 높입니다.

인수하는 동안 IT 자산을 병합하는 것은 어렵고 시간이 많이 걸립니다. 클라우드는 인수하는 회사가 인수되는 회사의 자산을 실행할 수 있는 "통합 기반 기반"을 만들면 합병 프로세스를 가속화하고 복잡성을 완화할 수 있습니다. 이를 통해 인수한 회사에서 이미 시행 중인 IAM, 보안, 네트워크 및 규정 준수 정책을 계속 유지할 수 있으므로 기존 워크로드가 설계된 대로 계속 작동할 수 있습니다. 시간이 지남에 따라 이러한 워크로드는 측정되고 예측 가능한 속도로 통합 기반에서 기본 기반으로 마이그레이션될 수 있습니다.

이 접근 방식을 사용하여 회사는 다른 구성의 동일한 소프트웨어를 사용하여 인수뿐만 아니라 핵심 클라우드 자산을 효율적으로 운영할 수 있습니다. 이것은 일반적으로 통합 시간을 2년에서 3년에서 3개월에서 9개월로 단축할 수 있습니다.

10. 예방적이고 자동화된 클라우드 보안 및 규정 준수를 초석으로 만들기

모든 소프트웨어 구성 요소와 시스템은 보안 계층을 통과해야 합니다. 기존의 사이버 보안 메커니즘은 인간의 감독 및 검토에 의존하므로 민첩성과 속도라는 클라우드의 이점을 최대한 활용하는 데 필요한 속도를 맞출 수 없습니다. 이러한 이유로 기업은 클라우드 워크로드를 보호하기 위해 새로운 보안 아키텍처와 프로세스를 채택해야 합니다.

SaC( 코드형 보안 )는 속도와 민첩성으로 클라우드 워크로드를 보호하는 가장 효과적인 접근 방식이었습니다. SaC 접근 방식은 프로그래밍 방식으로 사이버 보안 정책 및 표준을 정의하므로 클라우드 시스템을 프로비저닝하는 데 사용되는 구성 스크립트에서 자동으로 참조할 수 있습니다. 클라우드에서 실행되는 시스템은 보안 정책에 따라 평가되어 규정 준수에서 벗어나는 변경 사항을 방지할 수 있습니다.

---

"작게 시작하여 성장"하는 것은 처음부터 기본 빌딩 블록이 생성된 경우에만 실행 가능한 클라우드 전략입니다. 기업은 클라우드로 향하는 모든 IT 워크로드를 지원하는 재사용 가능하고 확장 가능한 플랫폼을 제공하기 위해 클라우드 기반을 설계하고 구축해야 합니다. 이 접근 방식은 클라우드가 제공하는 이점을 활용하고 궁극적으로 전체 가치를 포착합니다.