고객 설명
시작 모듈에서는 Tailwind Traders에 대해 설명했습니다. Tailwind Traders의 중앙 운영 팀과 플랫폼 팀은 회사의 기존 데이터 센터를 관리해본 경험이 있습니다. 두 데이터 센터를 Azure로 마이그레이션하기 위해 진행 중인 프로젝트는 해당 회사의 현재 기술 세트로 해결할 수 없는 몇 가지 중요 학습 곡선을 이미 드러내고 있습니다.
중요 제약 조건
현재 비즈니스는 마이그레이션에 높은 우선 순위를 두며 데이터 센터에서 벗어나기 위한 시간 제약 조건을 충족하고 있습니다. 비즈니스 우선 순위 때문에 비즈니스 및 IT 팀은 핵심 클라우드 플랫폼 개발을 완료할 수 있을 때까지 장기적인 보안 및 규정 준수 요구 사항에 대한 우선 순위를 낮췄습니다.
Tailwind Traders는 클라우드에 익숙하지 않으므로 운영, 플랫폼 또는 IT 관리 팀의 구성원 중 클라우드를 사용해본 경험이 있는 구성원은 거의 없습니다. 회사는 최신 운영, 보안, 거버넌스로 천천히 전환하려고 하지만, 그러한 전환의 대상이 점점 더 중요해짐에 따라 이러한 요구를 충족하도록 스케일링할 수 있는 클라우드 기반이 여전히 필요합니다.
지금까지 Tailwind Traders는 중앙 운영의 관점에서만 운영되었습니다. 따라서 워크로드 팀은 프로덕션 환경과 상호 작용할 수 없습니다. 회사는 자산(가상 머신, 데이터, 앱)을 정의된 워크로드에 매핑하는 손쉬운 방법이 없으므로 각 워크로드의 경계가 때때로 명확하지 않을 수 있습니다.
Azure 랜딩 존에 맞춤
운영 및 플랫폼 팀은 다음 조정에 동의했습니다.
- Azure 랜딩 존의 개념적 아키텍처는 클라우드 환경의 미래 상태에 대한 장기 비전 역할을 할 것입니다. 영향을 받는 모든 팀은 클라우드 기술을 빌드하고 클라우드 환경을 구성하기 위한 기반으로 해당 아키텍처를 사용합니다.
- 팀은 Azure 랜딩 존 가속기를 사용하여 환경 구성을 시작합니다.
- 팀이 나중에 환경을 사용자 지정해야 하는 경우 초기 가속기 기반 배포에 맞추거나 확장하는 사용자 지정 구현 옵션 중 하나를 사용합니다.
표준 Azure 랜딩 존 지침의 편차
다음 목록에서는 각 결정의 영향과 함께 제약 조건으로 인해 Tailwind Traders가 Azure 랜딩 존의 디자인 원칙에서 벗어나는 방법을 간략하게 설명합니다.
정책 중심적 거버넌스: Tailwind Traders는 지금까지 회사 정책을 자동화하지 않았습니다. 데이터 센터를 신속하게 마이그레이션해야 한다는 압박 때문에 회사는 랜딩 존의 초기 배포를 포함하여 거버넌스의 양을 최소화하기로 결정했습니다.
또한 회사는 초기 환경을 구성한 후 클라우드 채택 프레임워크의 거버넌스 방법론에 대한 Learn 모듈을 완료하기로 약속했습니다. 클라우드 마이그레이션을 전담하는 IT 직원의 제한 사항은 이러한 편차를 크게 좌우하는 요인에 속합니다. 이러한 편차는 완전 클라우드 거버넌스 또는 “Azure Ops”에 대한 비즈니스 및 IT 저항에 의해 더욱 적용되었습니다.
구독 민주화: 중앙 운영 팀은 모든 워크로드에 대한 프로덕션 운영에 대한 책임을 유지합니다. 중앙 운영 팀은 워크로드 팀이 프로덕션 환경에 액세스할 수 있도록 허용하는 경우가 거의 없으므로 구독 민주화의 디자인 원칙을 따르지 않습니다.
워크로드 팀에 편차가 필요한 경우 중앙 운영 팀은 사례별로 개별 워크로드에 대한 전용 랜딩 존을 고려합니다. 그 외에 Tailwind Traders는 중앙 운영을 유지하기 위해 최선을 다하고 있으며 격리된 프로덕션 환경(또는 애플리케이션 랜딩 존)에서 워크로드의 인스턴스가 제한될 수 있습니다.
애플리케이션 중심 서비스 모델: 중단 관련 프로세스는 특히 중요 업무용 워크로드를 지원하는 자산의 경우 워크로드를 고려할 수 있습니다. 그러나 중단을 제외하면 중앙 운영 팀은 운영 관리 프로세스에 대한 워크로드 또는 애플리케이션을 서로 구분하지 않습니다. 팀의 기본 프로세스는 워크로드 경계 또는 아키텍처에 관계없이 모든 리소스를 동일한 방식으로 운영, 관리, 변경, 최적화합니다. 이 마이그레이션에 대한 시간 제약 조건을 고려할 때 Tailwind Traders가 앱 경계를 정의하여 앱 중심 서비스 모델을 설정하는 것은 불가능합니다.
앞의 목록에 있는 많은 용어는 이 Learn 모듈의 이후 단원에서 설명합니다. 그중 몇몇 용어는 교육 기회를 제공하기 위해 메모에 반영됩니다.
이러한 편차는 맞춤 계약에서 벗어나지 않습니다. 그러나 이러한 편차는 Azure 랜딩 존 가속기를 배포할 때 일부 옵션에 영향을 미칩니다. 이러한 편차는 자산을 클라우드로 마이그레이션하기 시작한 후 배포되는 개별 애플리케이션 랜딩 존의 디자인에도 영향을 미칩니다.
또한 이러한 편차를 사용하려면 Tailwind Traders 팀이 초기 환경이 배포된 후 클라우드 채택 프레임워크의 관리, 보안, 거버넌스에 대한 Learn 모듈을 완료해야 합니다.
추가 제약 조건
다음 추가 제약 조건은 Tailwind의 결정에 영향을 줄 수 있습니다.
작업
중앙 운영 팀은 전체 포트폴리오를 관리하기 위한 일련의 프로세스와 컨트롤을 유기적으로 구축했습니다. 팀은 운영 기준을 위해 System Center Operations Manager와 Microsoft Configuration Manager를 사용합니다.
또한 팀은 가상 머신 관리, 인시던트, 구성 관리 추적, 네트워크 모니터링, 보안 운영, 거버넌스 컨트롤 등을 위한 동종 최고의 도구들을 기타 도구 간에 통합했습니다. 이러한 도구들은 대부분 Azure와 기본적으로 통합되어 있으며 그것이 바로 Azure를 회사의 기본 클라우드 공급자로 사용하기로 하는 근거가 되었습니다. 이러한 도구들을 운영하려면 상당한 인력과 자본이 필요합니다.
운영 도구
운영 관리 도구(하이퍼바이저 포함)에 대한 라이선스는 하드 비용(hard cost)에 대한 IT 예산의 20% 이상을 소모합니다. 신임 CIO(최고 정보 책임자)는 클라우드 중심의 대안 또는 통합 운영 대안을 찾기 위해 이러한 도구들과 프로세스를 재평가할 것을 팀에 요청했습니다. 신임 CIO는 이 마이그레이션의 성공을 가늠하는 초기 지표인 도구 비용 감소를 지켜볼 것입니다.
운영 프로세스
IT 관리자는 중앙 운영 팀을 지원할 신입 사원 2명을 채용할 것을 요청했습니다. 이들은 과도한 스트레스를 받는 팀의 업무 부하를 조절하는 데 도움이 될 것입니다. 특히 이들은 BCDR(비즈니스 연속성 및 재해 복구) 관행과 패치 규정 준수 프로세스를 지원합니다.
회사는 특히 중요 업무용 애플리케이션에서 클라우드 네이티브 운영으로 본격 전환할 준비가 되어 있지 않습니다. CIO는 클라우드 네이티브 운영 도구에 대한 일부 투자가 그러한 책임의 일부를 클라우드 공급자에게 이양함으로써 중앙 운영 팀의 업무 부담을 줄이는 데 도움이 될 것으로 판단합니다.
CIO는 직원 만족도를 높이고 중앙 운영 팀의 업무 부하를 줄이기 위해 운영 전환을 지켜볼 것입니다. 또한 CIO는 채택 계획이 BCDR 및 패치 작업에 미치는 영향에 대한 최신 정보를 자주 요청할 것입니다.
서비스 수준 약정
운영과 관련된 모든 노력과 비용에도 불구하고 팀은 기본 데이터 센터의 중요 업무용 시스템에서 90% 작동 시간의 SLA(서비스 수준 약정)를 주기적으로 준수하지 못합니다. 이는 CIO와 CEO(최고 경영자)의 입장에서 볼 때 비용이 많이 드는 문제에 속합니다. 오래된 하드웨어와 데이터 센터의 새로 고침 주기가 지연된 이유로 빈번하지만 짧은 중단이 발생했습니다.
회사는 이러한 SLA를 마지못해 수락했으나 신임 CIO는 이에 만족하지 않았습니다. 재무 비용 절감과 관계없이 신임 CIO는 마이그레이션 후 중앙 운영 팀이 훨씬 더 높은 SLA를 제공할 것으로 기대하고 있습니다.
소매 혁신
시작 모듈의 고객 설명에서는 Tailwind Traders 내부의 소매 혁신 팀을 소개했습니다. 이 팀은 원래 Tailwind Traders가 인수한 스타트업이었습니다. 해당 스타트업의 원래 CEO는 이제 Tailwind의 CTO(최고 기술 책임자)입니다. 해당 CTO는 실험과 혁신을 우선시하면서 마치 스타트업처럼 해당 부서를 계속 운영하고 있습니다.
현재 운영 관리에 대한 프로세스에서는 해당 팀의 모든 새로운 혁신이 릴리스 프로세스를 거쳐야 합니다. IT 부서 내 중앙 운영 팀은 보안, 거버넌스 및 운영 관리 문제에 대한 아키텍처를 검토합니다. 팀이 솔루션에 익숙해지면 솔루션을 중앙 관리형 프로덕션 환경으로 릴리스합니다. 이 프로세스는 클라우드에서 계속 진행될 것으로 예상됩니다.
ID 관리
Active Directory는 Tailwind Traders 데이터 센터에서 인증 및 액세스 제어를 위한 ID 저장소 및 기본 도구입니다. 해당 회사는 ID를 다단계 인증 솔루션으로 확장하기 위해 동종 최고의 시스템을 사용했으며, Microsoft 365 솔루션을 배포하기 위해 ID를 페더레이션했습니다. 그러나 이러한 경우에도 Tailwind Traders에서 ID를 관리하는 방법은 Active Directory입니다.
이제 회사는 클라우드에서 IaaS(서비스 제공 인프라) 인프라에서 실행되는 Microsoft Entra ID 또는 Microsoft Entra Domain Services와 같은 더 많은 옵션을 보유하게 되었습니다. 중앙 운영 팀은 여러 옵션을 비교하고 클라우드 채택 계획에 가장 적합한 ID 솔루션을 선택하기 위해 노력하고 있습니다.
네트워크 토폴로지 및 연결
Tailwind Traders는 MPLS(Multiprotocol Label Switching) 선을 사용하여 데이터 센터 및 물리적 저장소를 연결합니다. 모든 인터넷 트래픽은 기본 데이터 센터를 통해 유입됩니다. 두 데이터 센터 간의 IP(인터넷 프로토콜) 충돌로 인해 트래픽이 격리되며 라우팅은 복잡한 라우팅 테이블에 종속됩니다. 외부에서는 가상 사설망을 통해 데이터 센터 또는 회사 사무실과 연결합니다. 이러한 연결은 제한적이며 권장되지 않습니다.
기본 및 보조 데이터 센터에는 유지 관리되고 명확하게 구성된 일관된 IP 주소 스키마가 있습니다. 세 번째 데이터 센터에는 일관성이 거의 없고 명확한 조직 또는 구분 계획이 없는 50개의 서로 다른 IP 블록이 포함됩니다. 연속 혁신 주기는 세 번째 데이터 센터에 국한되지만, 이는 클라우드에서 네트워크 토폴로지 및 라우팅을 정의할 때 문제를 야기할 수 있습니다.
리소스 조직
데이터 센터 간의 리소스 구분에서는 각 워크로드 컬렉션을 하나의 큰 자산 블록으로 간주했습니다. 그런 다음, 각 컬렉션은 워크로드 간에 제한된 네트워킹 흐름을 허용하기 위해 격리 및 제어된 세그먼트를 생성하도록 위험 프로필에 따라 분할되었습니다. 보호되지 않은 네트워크에서 수신 네트워크 연결이 필요한 워크로드는 각 데이터 센터를 구성하는 하나 이상의 경계 네트워크 세그먼트로 격리됩니다.
그러한 기본 조직 외에도 구성 관리 데이터베이스 내에 불일치가 있으므로 어떤 자산이 어떤 워크로드와 연결되어 있는지 파악하기가 어렵습니다. 워크로드 소유자 및 인시던트 에스컬레이션 체인은 중요 업무용 워크로드에 대해 잘 정의되어 있지만 이는 대부분의 다른 워크로드에는 존재하지 않습니다.
중요도가 낮은 워크로드의 경우에는 식별된 소유자가 Tailwind Traders의 전직 직원인 경우가 일반적입니다. 구성 매핑은 종료된 가상 머신을 종종 참조합니다. 마찬가지로 지원되는 자산의 30% 이상은 단일 워크로드에 명확하게 매핑되지 않습니다. 회사는 마이그레이션 중에 종속성 분석과 적절한 리소스 구성을 진행하려면 연습이 필요합니다.