3.11 클라우드 아키텍처

개요와 동기

클라우드 컴퓨팅은 다른 사람의 인프라를 필요할 때 네트워크로 빌리고, 쓴 만큼 과금되고, 끝나면 반납하는 것입니다. 클라우드 아키텍처는 그렇게 빌린 자원을 옛 데이터 센터의 빌린 복사본이 아니라 본래의 집으로 다루는 시스템을 설계하는 규율입니다. 그 구분이 이 장 전체의 요점입니다. 레거시 애플리케이션을 설계는 하나도 바꾸지 않고 클라우드 제공자로 옮길 수 있으며, 그러면 더 큰 청구서와 거의 같은 취약성을 얻습니다. 또는 클라우드를 위해 설계해서 탄력성, 차별화되지 않는 작업의 부류 전체를 지워 주는 관리형 서비스, 누구도 호출하지 않고 건물 전체의 장애에서 살아남는 능력을 얻을 수 있습니다. 이는 3.1장의 기본기 위에 직접 서 있습니다. 클라우드 아키텍처는 소유하지 않은 기반 위에 적용되는, 같은 트레이드오프와 품질 속성을 지닌 아키텍처입니다.

큰 팀에서는 클라우드가 누가 무엇을 하는지를 다시 배선하므로 이해관계가 더 높습니다. 팀이 몇 분 안에 데이터베이스, 큐, 글로벌 로드 밸런서를 프로비저닝할 수 있게 되면 병목은 조달이 아니라 거버넌스가 됩니다. 수십 개 팀이 동시에 이를 할 때의 비용, 보안, 일관성입니다. 클라우드는 모든 엔지니어에게 법인 카드와 전동 공구가 가득한 창고를 줍니다. 똑같이 멋지고 똑같이 위험합니다. 아키텍처를 제대로 한다는 것은 이점(속도, 탄력성, 복원력)을 얻으면서 지출, 보안 태세, 데이터 거주를 통제하에 두는 가드레일을 설치하는 것입니다.

기업과 정부는 양쪽 날을 날카롭게 느낍니다. 기업은 수십 년 된 기존 시스템과 함께 오므로 클라우드 이야기는 대개 하이브리드 연결과 어려운 만들기 대 사기 판단으로 가득한 이전 이야기입니다. 정부는 주권, 인가 체계, 법적으로 특정 국경을 벗어날 수 없는 시민의 데이터라는 추가된 무게를 집니다. 어떤 서비스 모델, 몇 개의 제공자, 장애 도메인이 어디에 있는지, 무엇이 관리형 서비스로 돌고 무엇이 자체 코드로 도는지에 대한 이 결정은 10년간 비용과 위험을 형성합니다.

핵심 원칙

데이터 센터를 사진 찍지 말고 클라우드를 위해 설계하십시오. 탄력성, 관리형 서비스, 장애 도메인 인식이 여기 있는 이유이며, 리프트 앤 시프트는 이를 버립니다.
모든 것을 코드로 프로비저닝하십시오. 사람이 클릭해서 존재하게 했다면 문서화되지 않았고, 반복할 수 없으며, 감사할 수 없습니다.
장애 도메인에 걸쳐 의도적으로 설계하십시오. 리전, 가용 영역, 서비스는 실패합니다. 그것이 어깨 으쓱인지 장애인지는 아키텍처가 결정합니다.
공동 책임 모델은 구호가 아니라 계약입니다. 제공자가 어느 선까지 보호하고 여러분이 어느 선을 보호하는지 정확히 아십시오.
차별화되지 않는 것은 사고, 차별화하는 것은 만드십시오. 관리형 서비스는 배관에 실제 돈 값어치가 있습니다. 경쟁 우위는 직접 쥐고 있으십시오.
종속은 가격을 매길 비용이지 피할 죄가 아닙니다. 이식성에는 가격이 있고 지렛대에는 가치가 있습니다. 반사적이 아니라 의도적으로 결정하십시오.
비용은 일급 품질 속성입니다. 클라우드에서 아키텍처와 청구서는 같은 결정입니다.

권장 사항

서비스 모델을 의도적으로 고르고, 기본은 관리형으로 한다

클라우드 제공자는 서비스형 모델이 담는 스펙트럼을 따라 팝니다. 서비스형 인프라(IaaS)는 원시 컴퓨트, 스토리지, 네트워킹을 빌려주고, 서비스형 플랫폼(PaaS)은 서버를 돌보지 않고 코드를 배포하도록 관리형 런타임을 빌려주며, 서비스형 소프트웨어(SaaS)는 완성된 애플리케이션을 빌려줍니다. 함수와 관리형 이벤트 기반 서비스를 포함하는 서버리스 컴퓨팅은 이를 더 밀고 갑니다. 코드나 설정을 제공하면 제공자가 모든 프로비저닝을 처리하고 유휴 시 0까지 확장합니다. 스펙트럼을 한 단계 올라갈 때마다 통제를 지렛대와 맞바꿉니다. 통제와 운영 부담이 가장 많은 IaaS에서 둘 다 가장 적은 서버리스까지입니다.

기본은 요구 사항이 허용하는 만큼 스펙트럼을 높이 올라가는 것이어야 합니다. 패치, 백업, 페일오버, 확장을 처리하는 관리형 데이터베이스는 거의 항상 직접 운영하는 것보다 엔지니어를 더 잘 쓰는 일입니다. 낮은 수준의 IaaS는 정말 필요한 경우에 남겨 두십시오. 특수 하드웨어, 특이한 컴플라이언스 경계, 라이선스 제약, 관리형 제품이 충족할 수 없는 성능입니다. 이유를 아키텍처 결정 기록(3.1장)으로 적어 두십시오. “우리는 자체 메시지 브로커를 운영한다”는 해마다 다시 정당화해야 할 주장이기 때문입니다.

리전과 가용 영역에 걸쳐 명시적 장애 도메인으로 설계한다

클라우드 리전은 지리적 영역이고, 그 안에서 가용 영역은 독립적인 전력, 냉각, 네트워킹을 가진 물리적으로 분리된 데이터 센터로, 낮은 지연의 복제를 하기에 충분히 가깝지만 하나가 실패해도 다른 것들을 쓰러뜨리지 않을 만큼 멀리 있습니다. 이것이 클라우드가 깨지는 이음새이므로, 아키텍처는 이를 일급으로 다뤄야 합니다. 진지한 워크로드의 기준선은 다중 영역입니다. 컴퓨트와 데이터를 적어도 둘, 이상적으로는 셋 영역에 퍼뜨려 하나를 잃어도 장애가 아니라 용량 저하에 그치게 합니다. 이것은 건너뛸 좋은 변명이 거의 없는 싼 보험입니다.

다중 리전은 더 무거운 결정이며, 복원력과 복구 목표(3.5장) 및 재해 복구 계획(9.5장)에 묶입니다. 리전에 걸쳐 퍼뜨리면 리전 전체 장애에서 살아남고 데이터를 사용자에게 더 가깝게 둘 수 있지만, 리전 간 동기 복제는 느리고 비동기 복제는 페일오버 시 데이터 손실을 받아들인다는 뜻이므로 실제 비용, 지연, 일관성 문제를 들여옵니다. 막연히 “고가용”이기를 바라는 것이 아니라 명시적인 복구 시간 및 복구 시점 목표에 근거해 결정하십시오. 대부분의 시스템은 견고한 다중 영역과 테스트된 다중 리전 복구 경로가 필요하고, 리전 간 액티브-액티브가 정말 필요한 경우는 드물며, 필요 없이 만든 곳은 그 복잡성에 매일 값을 치릅니다.

공동 책임 모델을 아키텍처 경계로 다룬다

클라우드 보안은 공동 책임 모델로 돌아갑니다. 제공자는 클라우드 자체(물리 시설, 하이퍼바이저, 관리형 서비스 내부)를 보호하고, 여러분은 클라우드에 넣은 것(데이터, 접근 통제, 네트워크 설정, 코드)을 보호합니다. 정확한 선은 서비스 스펙트럼을 올라갈수록 움직입니다. IaaS에서는 운영체제를 패치합니다. 관리형 데이터베이스에서는 하지 않지만, 누가 연결할 수 있고 데이터가 암호화되는지는 여전히 여러분의 몫입니다. 가장 비싼 인시던트는 이 선을 잘못 읽는 데서 옵니다. 가장 유명한 것은 제공자가 기본적으로 비공개로 만들었으리라 누군가 가정했기 때문에 수백만 레코드를 유출한 열린 스토리지 버킷입니다.

설계에서 경계를 명시하고 세부는 인프라와 클라우드 보안을 깊이 다루는 4.3장에 넘기십시오. 아키텍처적으로 명령은 일정합니다. 기본으로 저장 시와 전송 중 데이터를 암호화하고, 네트워크 위치가 아니라 신원을 통해 최소 권한을 부여하고, 단일 자격 증명의 영향 범위를 작게 유지하고, 인터넷에서 닿는 모든 자원이 몇 분 안에 탐색당한다고 가정하십시오. 팀이 상속하도록 이를 랜딩 존에 구워 넣으십시오.

거버넌스가 있는 랜딩 존 안에서 모든 것을 코드로 프로비저닝한다

성숙한 클라우드 실천에서 어떤 프로덕션 자원도 누군가 콘솔을 클릭해서 존재하지 않습니다. 모든 것이 코드형 인프라(8.2장)로 선언되고, 버전 관리되고, 리뷰되고, 파이프라인을 통해 적용되므로, 인프라는 재현 가능하고, 감사 가능하고, diff 가능합니다. 이것이 다중 영역, 다중 리전, 재해 복구를 포부가 아닌 현실로 만듭니다. 환경이 기억이 아니라 프로그램이므로 새 리전에 동일한 환경을 세울 수 있습니다.

그 코드를 랜딩 존으로 감싸십시오. 모든 팀이 그 위에 짓는, 미리 구축되고 다스려지는 계정(또는 구독이나 프로젝트), 네트워킹, 신원, 로깅, 가드레일의 기반입니다. 별도 계정을 영향 범위와 청구 경계로 써서 한 팀의 실수가 다른 팀의 데이터에 닿지 않고 모든 달러가 소유자에게 추적되게 하십시오. 가드레일을 사후 검토에 의존하는 대신 금지된 설정(공개 데이터베이스, 암호화되지 않은 볼륨, 허용되지 않은 리전의 자원)을 막는 코드형 정책으로 시행하십시오. 중앙 플랫폼 팀이 대개 랜딩 존을 소유하며, 이는 이 장을 플랫폼 엔지니어링(8.4장)과 컨테이너 및 클라우드 네이티브 런타임(8.3장)에 연결합니다.

종속의 가격을 정직하게 매기고 멀티 클라우드를 회의적으로 본다

벤더 종속은 제공자를 바꾸는 비용이며, 이분법이 아니라 스펙트럼입니다. 제공자의 관리형 큐를 쓰면 약간의 종속이 생기고, 독점 머신러닝 플랫폼을 쓰면 많이 생깁니다. 이에 대한 반사적 두려움은 팀이 결코 행사하지 않을 이식성을 지키려고 실제 지렛대(클라우드를 쓸 가치가 있게 하는 관리형 서비스)를 희생하게 만듭니다. 정직한 수는 가격을 매기는 것입니다. 중요한 의존성마다 떠나는 데 실제로 얼마가 드는지 추정하고 그 서비스가 지금 아껴 주는 것과 저울질하십시오. 이식성을 유지하려고 관리형 서비스를 추상화로 가리는 일은 흔히 막으려는 이전이 결코 들이지 않았을 것보다 영구적으로 더 많이 듭니다.

그래서 진정한 멀티 클라우드(같은 워크로드를 두 제공자에 걸쳐 운영)는 대개 전략이 아니라 화물 숭배입니다. 최소 공통분모로 밀어붙이고, 운영 표면을 두 배로 하고, 팀이 지녀야 할 전문성을 곱절로 늘리며, 모두 거의 현실화하지 않는 위험을 헤지하려는 것입니다. 둘 이상의 제공자를 건드릴 정당한 이유는 있습니다. 두 번째 벤더의 최고 SaaS, 규제 기관의 복원력 의무, 의도적인 주권 요구(10.11장)입니다. 일부 시스템을 온프레미스에 두고 클라우드에 연결하는 하이브리드 클라우드는 기업 이전 중과 법적으로 이동할 수 없는 데이터에 흔히 불가피합니다. 슬라이드가 “멀티 클라우드”라고 해서가 아니라 분명한 눈과 서면 정당화로 이를 고르십시오.

비용을 위해 설계하고 잘 설계된 사고를 채택한다

클라우드에서 아키텍처 결정은 지출 결정입니다. “혹시 몰라서” 과잉 프로비저닝하면 다음 달 청구서에 나타납니다. 비용을 설계 대상인 품질 속성으로 다루고, 클라우드 지출에 대한 공유된 재무 책임성의 규율인 FinOps 실천(9.4장)을 채택해 엔지니어링, 재무, 제품이 함께 청구서를 소유하게 하십시오. 모든 자원에 소유자를 태깅하고, 팀별 서비스별 비용을 보이게 하고, 지속적으로 적정 크기로 조정하고, 피크가 아니라 부하에 대해 값을 치르도록 오토스케일링을 쓰고, 클라우드가 제공하는 가격 지렛대(약정 사용 할인, 중단 가능한 작업을 위한 스팟 용량)를 활용하십시오.

비용을 넘어 잘 설계된 프레임워크를 리뷰 체크리스트로 쓰십시오. 주요 제공자가 각각 하나씩 발행하며, 같은 기둥으로 수렴합니다. 신뢰성, 보안, 비용 최적화, 성능 효율성, 운영 우수성, 지속 가능성입니다. 설계 시와 이후 주기적으로 가벼운 리뷰를 실행해 시스템을 각 기둥에 대해 점수 매기고 간극을 추적되는 작업으로 기록하십시오. 눈치채지 못한 트레이드오프를 잡는 싼 방법입니다.

장단점

접근 방식	장점	단점
리프트 앤 시프트 (리호스트)	빠름. 낮은 초기 노력. 데이터 센터를 빨리 벗어남	옛 취약성 유지. 탄력성과 관리형 서비스를 놓침. 흔히 더 비쌈
클라우드 네이티브 재설계	완전한 탄력성, 복원력, 관리형 서비스 지렛대	더 높은 선행 노력과 기술. 흡수해야 할 더 큰 변화
단일 클라우드, 깊은 통합	단순성. 최대 지렛대. 더 낮은 운영 표면	집중된 종속과 제공자 위험
멀티 클라우드 (같은 워크로드, 두 제공자)	제공자 장애 헤지. 협상 지렛대	최소 공통분모 설계. 두 배의 운영과 전문성
하이브리드 (클라우드 + 온프레미스)	데이터 거주와 레거시 제약 충족. 단계적 이전	네트워크 복잡성. 동시에 운영할 두 가지 운영 모델
서버리스 / 높은 관리형	최소한의 잡무. 0까지 확장. 빠른 전달	통제가 적음. 제공자 전용. 콜드 스타트와 할당량 한계

핵심 긴장은 통제 대 지렛대이며, 모든 행에 흐릅니다. 제공자에게 넘기는 것이 많을수록 더 빨리 움직이고 덜 운영하지만, 더 깊이 결합됩니다. 해법은 한 극을 고르는 것이 아니라 각 워크로드를 의도적으로 배치하는 것입니다. 범용 배관에는 관리형 스펙트럼을 높이 올라가고, 통제가 정말 값을 하는 곳에서는 낮게 머물고, 이식성을 공짜로 의존을 죄로 다루는 대신 양방향으로 종속의 가격을 매기십시오. 대규모 조직이 곤경에 빠지는 것은 두려움(종속, 클라우드, 비용에 대한)이 이 선택을 분석 대신 반사로 내리게 둘 때입니다.

팀과 논의할 질문

워크로드 중 어느 것이 리프트 앤 시프트되었으며, 데이터 센터 아키텍처에 클라우드 가격을 내고 있습니까? 마감 아래서 이전하고, 모든 것을 그대로 리호스트하고, 승리를 선언한 뒤, 청구서가 데이터 센터보다 높고 복원력이나 탄력성의 이점이 하나도 실현되지 않았음을 발견하는 일은 흔합니다. 정직한 감사는 주요 워크로드를 나열해 각각을 리호스트, 리플랫폼, 진정한 재설계로 표시한 다음, 어느 것이 여전히 고정 크기, 상시 가동, 단일 영역 풋프린트에서 도는지 보는 것입니다. 일부 리프트 앤 시프트는 정당한 첫 단계이므로 질문은 했느냐가 아니라 더 나아갈 계획과 일정이 있느냐입니다. 워크로드별 비용과 인시던트 이력을 가져오십시오. 비싸면서 취약한 워크로드가 재설계가 가장 빨리 본전을 뽑는 곳이기 때문입니다. 이전 1년 뒤에도 모든 것이 여전히 옛 데이터 센터의 모양이라면, 더 비싼 데이터 센터를 산 것입니다.
가용 영역이나 리전 전체가 실패하면 실제로 무슨 일이 일어나며, 테스트해 보았습니까? 많은 팀이 장애 도메인을 설계하거나 확인하려고 플러그를 뽑아 본 적 없이 클라우드에 배포했다는 이유로 자신이 복원력 있다고 믿습니다. 구체적으로는 이렇습니다. 각 핵심 시스템이 몇 개의 영역에 걸치고, 문서화된 복구 시간 및 복구 시점 목표는 무엇이며, 영역을 실패시키거나 리전 복구를 리허설한 게임 데이를 마지막으로 한 것은 언제입니까? 다중 영역은 특별할 것 없는 기준선이어야 하므로 핵심 단일 영역 워크로드는 발견 사항입니다. 다중 리전은 기본으로 채택하는 것이 아니라 명시적 복구 목표에 묶인 더 무겁고 비싼 결정입니다. 의존성 지도를 가져오십시오. 아픈 실패는 대개 아무도 장애 도메인을 도식화하지 않은 공유 서비스(데이터베이스, 신원 제공자)의 실패이기 때문입니다. 한 번도 테스트하지 않은 복원력은 속성이 아니라 가설입니다.
가장 큰 제공자 의존성에서 떠나는 데 실제로 얼마가 들며, 그것이 피할 가치가 있는 가격입니까? 종속 논쟁은 숫자보다 이념으로 진행되는 경향이 있습니다. 한 진영은 이식성을 지키려고 모든 관리형 서비스를 추상화로 가리고, 다른 진영은 집중 위험을 완전히 무시합니다. 근거를 대십시오. 가장 깊은 의존성 셋을 골라 각각을 교체하는 실제 엔지니어링 비용과 경과 시간을 추정하고, 그 서비스가 오늘 아껴 주는 것 및 언젠가 전환할 가능성과 저울질하십시오. 이식성이 해결하지 못하는 위험, 곧 규제 기관이 두 번째 공급원을 요구하거나 데이터가 어디에 살 수 있는지에 대한 주권 규칙을 얹으십시오. 그런 것은 순수한 경제성이 정당화하지 않더라도 멀티 클라우드나 하이브리드를 정당화할 수 있습니다. 목표는 일괄 정책이 아니라 의존성마다 의도적이고 서면화된 입장입니다. 일단 가격을 매기면 두려워하던 대부분의 종속은 그것을 피하려고 만든 추상화 계층보다 받아들이는 편이 더 싸다는 것이 드러납니다.
제공자가 기꺼이 대신 운영해 줄 서비스를 우리가 직접 운영하고 있는 것은 어느 것이며, 그 선택이 엔지니어 시간으로 얼마의 비용입니까? 클라우드의 모든 지렛대는 패치, 백업, 페일오버, 확장을 그 일이 전업인 누군가에게 넘기는 것이지만, 팀은 습관이나 잘못된 자부심으로 직접 운영하는 데이터베이스, 메시지 브로커, 검색 클러스터를 일상적으로 유지합니다. 대규모 조직에서 비용은 한 팀의 잡무가 아니라 열두 구석에서 재발명되는 같은 차별화되지 않는 운영이며, 각각이 호출 대기 로테이션이자 표류의 원천입니다. 상충하는 고려는 진짜입니다. 특수 하드웨어, 라이선스 조건, 특이한 컴플라이언스 경계, 관리형 제품이 충족할 수 없는 성능이 스펙트럼에서 낮게 머무는 것을 정당화할 수 있으므로, 답은 일괄이 아니라 서비스별입니다. 직접 운영하는 서비스의 목록, 각각이 유지보수와 인시던트에 소비하는 엔지니어 시간, 관리형 대안의 가격을 가져오고, 해마다 다시 정당화되는 모든 “우리는 직접 운영한다”에 아키텍처 결정 기록을 요구하십시오. 기업과 정부 환경에서는 직접 운영 선택이 실제로 컴플라이언스나 라이선스 제약인지, 제약으로 위장한 관성일 뿐인지 더하십시오. 감사자와 예산 소유자가 같은 질문을 할 것이기 때문입니다.
이번 달 모든 팀과 서비스가 우리에게 얼마의 비용인지 볼 수 있으며, 지명된 누군가가 그 숫자에 책임을 느낍니까? 엔지니어가 몇 분 안에 글로벌 데이터베이스를 프로비저닝하게 해 주는 같은 셀프서비스가 영원히 피크 크기로 켜 두게도 하고, 어떤 단일 청구 항목도 놀랍지 않아 보이기 때문에 클라우드 지출은 조용히 부풀어 오릅니다. 팀별 서비스별 비용 가시성이 없는 대규모 조직에서 재무는 문제를 몇 달 늦게 발견하고 반응은 규율 있는 쪽을 낭비하는 쪽과 함께 벌주는 무딘 동결입니다. 긴장은 실제입니다. 모든 달러를 쫓으면 전달이 느려지므로, 목표는 긴축이 아니라 책임성과 적정 크기 조정이며, 비용을 사후에 읽는 보고서가 아니라 설계하는 품질 속성으로 다룹니다. 팀별 비용 분석, 태그되지 않았거나 귀속할 수 없는 지출의 비중, 프로비저닝 용량 대비 현재 사용률, 약정 사용 할인이나 스팟 용량이 놓치고 있는 곳을 가져오십시오. 기업과 정부 기관에서는 이를 FinOps 실천과 공공 지출 정밀 조사에 연결하십시오. 태그되지 않은 자원은 낭비일 뿐 아니라 곧 나올 감사 지적이기 때문입니다.
팀이 지금 공개 데이터 저장소, 암호화되지 않은 볼륨, 금지된 리전의 자원을 세울 수 있으며, 우리가 알기나 하겠습니까? 가장 비싼 클라우드 인시던트는 제공자의 침해가 아니라 잘못된 설정이며, 공동 책임 모델은 유출되는 스토리지 버킷이나 인터넷에 열린 데이터베이스가 전적으로 여러분 쪽 선에 있다는 뜻입니다. 많은 팀 규모에서 이를 막는 것은 랜딩 존의 문제입니다. 기록이 이미 유출된 뒤에야 찾아내는 사후 검토 대신, 금지된 설정이 생기기 전에 막는 코드형 정책으로 시행되는 가드레일입니다. 상충하는 압력은 개발자의 자율입니다. 너무 빡빡한 가드레일은 팀을 그림자 계정으로 밀어내므로, 설계는 정말 위험한 것은 막으면서 움직일 여지를 남겨야 합니다. 실제로 시행되는 가드레일 목록, 실제 계정에서 비준수 자원을 프로비저닝해 보려는 정직한 시도, 예방이 실패했을 때의 탐지 지연을 가져오십시오. 규제되고 정부의 맥락에서는 이를 데이터 거주와 인가 체계에 연결하십시오. 허용되지 않은 리전의 자원은 스타일 위반이 아니라 감사자가 보고 대상 사건으로 다룰 법적 위반이기 때문입니다.

분야별 관점

스타트업. 첫날부터 단일 제공자에서 클라우드 네이티브로 가고 의도적으로 종속을 받아들이십시오. 가장 희소한 자원이 이식성이 아니라 주의이므로, 0까지 확장하는 서버리스와 관리형 서비스에서 돌려 엔지니어 두 명이 플랫폼 전체를 소유하게 하십시오. 지출에 엄격한 상한을 두고, 바이럴 순간이 장애가 되지 않도록 모든 것을 코드형 인프라로 유지하고, 임시라고 가장하는 대신 규모에서 재검토할 의도적 종속 결정을 적어 두십시오.

소기업. 플랫폼 엔지니어도 빠듯한 예산도 없으니 클라우드를 운영하는 것이 아니라 소비하는 것으로 다루십시오. 직접 운영하는 어떤 것보다 SaaS와 완전 관리형 서비스를 선호하고, 제공자의 안전한 기본값에 기대고, 관리형 데이터베이스가 백업과 페일오버를 처리해 아무도 하지 않아도 되게 하십시오. 선택을 사는 쪽에 강하게 엄지를 얹은 사느냐 만드느냐로 구성하고, 잊힌 자원이 한 달을 소진하지 못하도록 청구 경보를 설정하고, 인력을 댈 수 없는 서버를 세우기 전에 로코드나 관리형 옵션에 손을 뻗으십시오.

대기업. 클라우드 이야기는 많은 팀에 걸친 이전 이야기이므로 아키텍처는 사실상 거버넌스 문제입니다. 영향 범위와 청구 경계로서의 사업부별 계정, 기본 암호화 가드레일, 공개 데이터 저장소를 막는 코드형 정책을 갖춘 다스려지는 랜딩 존을 세우고, 중앙 플랫폼 팀이 그 기반을 소유하게 하십시오. 팀별 쇼백으로 FinOps를 운영하고, 중요한 설계는 잘 설계된 리뷰로 관문 통제하고, 수년간 움직이지 않을 레거시 기록 시스템과의 하이브리드 연결을 관리하십시오.

정부. 조달 규칙, 투명성, 주권이 모든 결정을 형성합니다. 인가되었거나 정부용인 클라우드 리전에 배포하고, 감사자를 위해 공동 책임 경계선을 한 줄씩 문서화하고, 허용되지 않은 리전의 자원을 막는 코드형 정책으로 스토리지와 처리를 국내 영역에 고정하십시오. 요구되는 인가 체계를 추구하고, 감사 증거를 허둥대는 일이 아니라 git 이력으로 유지하고, 직접 인증해야 하는 맞춤 인프라보다 제공자가 컴플라이언스 태세를 증명해 줄 관리형 서비스를 선호하십시오.

사례

스타트업. 열두 명 규모의 스타트업이 첫날부터 단일 제공자에서 클라우드 네이티브로 구축하며 죄책감을 느끼지 않습니다. API는 밤새 0까지 확장하는 서버리스 함수에서 돌고, 데이터는 자동 백업과 다중 영역 페일오버가 있는 관리형 Postgres에 살며, 백그라운드 작업은 관리형 큐에서 돕니다. 이 모든 것이 코드형 인프라로 정의되고, 제공자가 어려운 부분을 운영하므로 엔지니어 두 명이 플랫폼 전체를 소유합니다. 바이럴 순간에 한 시간 만에 트래픽이 쉰 배로 오르자 오토스케일링이 이를 흡수하고 청구서는 실제 사용량에 비례해 올랐다가 다시 내립니다. 창업자들은 작은 팀으로 빠르게 움직이는 값으로 종속을 의도적으로 받아들이고, 규모에서 재검토하도록 그 결정을 적어 두었습니다.

대기업. 레거시 애플리케이션 300개를 가진 한 다국적 보험사가 “6 R”(리호스트, 리플랫폼, 재구매, 리팩터, 퇴역, 유지)로 다스려지는 다년 이전을 운영합니다. 가치가 낮은 범용 앱은 마감에 맞춰 데이터 센터 두 곳을 빠져나오도록 빠르게 리호스트되고, 핵심 계약 플랫폼은 클라우드 네이티브로 리팩터링되며, 자체 제작 도구는 SaaS로 재구매되고, 낡은 시스템은 퇴역합니다. 중앙 플랫폼 팀이 사업부별 계정, 기본 암호화 가드레일, 공개 데이터 저장소를 막는 코드형 정책을 갖춘 랜딩 존을 소유하고, 하이브리드 연결이 클라우드를 수년간 움직이지 않을 메인프레임 기록 시스템에 잇습니다. 비용은 사업부별 쇼백이 있는 FinOps 실천으로 다스려지고, 잘 설계된 리뷰가 각 애플리케이션의 프로덕션 출시를 관문 통제합니다.

정부. 시민 급여 서비스를 제공하는 한 국가 기관은 법적으로 주민 데이터를 국경 안에 두고 인가된 인프라에서 운영해야 합니다. 제공자의 정부 클라우드 리전에 배포하고 미국의 FedRAMP 같은 체계(컴플라이언스 작업은 4.6장)에서 인가를 추구하며, 감사자를 위해 공동 책임 경계를 한 줄씩 문서화합니다. 데이터 거주와 더 넓은 주권 고려(10.11장)가 스토리지와 처리를 국내 영역에 고정하고 코드형 정책으로 허용되지 않은 리전의 자원을 막는 아키텍처를 이끕니다. 시스템은 테스트된 영역 간 복구 계획으로 세 개 가용 영역에 걸치며 모든 것을 코드로 프로비저닝하므로, 감사 증거는 허둥대는 일이 아니라 git 이력입니다.

비즈니스 사례: 동기, ROI, TCO

클라우드의 대표 약속은 자본 지출을 운영 지출로 바꾸는 것입니다. 수요보다 몇 해 앞서 서버를 사서 낮은 사용률로 돌리는 대신, 쓴 만큼 지불하고 비즈니스와 함께 확장합니다. 그것은 실재하지만, 더 깊은 수익은 속도와 집중입니다. 패치, 백업, 페일오버를 지워 주는 관리형 서비스는 그 엔지니어 시간을 제품 작업에 돌려주고, 몇 달이 아닌 몇 분의 프로비저닝은 아이디어에서 프로덕션까지의 시간을 압축합니다. 탄력성은 1년에 두 번 쓰는 피크 용량에 대한 지불을 멈추게 합니다. 아키텍처가 맞을 때 이것들이 누적되어 비용과 능력 모두에서 데이터 센터를 이기는 총소유비용이 됩니다.

잘못했을 때의 비용도 똑같이 실재하므로 비즈니스 사례는 정직해야 합니다. 재설계 없는 리프트 앤 시프트는 흔히 이점은 하나도 주지 못하면서 비용을 올리고, 통제되지 않은 지출은 재무가 경보를 울릴 때까지 수십 개 팀에 걸쳐 조용히 부풀 수 있습니다. 리더십에게는 세 가지 지렛대를 중심으로 논거를 세우십시오. 속도(더 빠른 전달과 더 짧은 프로비저닝), 복원력(더 적고 짧은 주요 인시던트), 선택 가능성(데이터 센터 프로젝트 없이 새 시장이나 리전에 진입). 피한 데이터 센터 교체, 범용 인프라의 줄어든 인력, 막은 장애 시간에 숫자를 붙여 이전 비용과 지속적인 FinOps 및 플랫폼 투자에 견주십시오. 가장 강한 논거는 날것의 비용 절감인 경우가 드뭅니다. 여전히 하드웨어를 기다리는 경쟁자보다 빨리 움직이는 선택 가치입니다.

안티패턴과 함정

리프트 앤 시프트하고 “클라우드”라 부르기. 데이터 센터 설계를 빌린 인프라로 리호스트하면 비용은 취하고 이점은 하나도 얻지 못합니다.
콘솔로 클릭한 인프라. 손으로 만든 자원은 반복할 수 없고, 문서화되지 않았고, 복구하거나 감사할 수 없습니다. 수동 프로덕션 변경은 결함으로 다루십시오.
화물 숭배 멀티 클라우드. 드문 위험을 헤지하려고 같은 워크로드를 두 제공자에 걸쳐 운영하며, 매일 복잡성과 최소 공통분모 설계로 값을 치르는 것.
단일 영역 “고가용성”. 클라우드가 기본적으로 복원력 있다고 믿으면서 테스트된 페일오버 없이 핵심 워크로드를 한 영역에서 운영하는 것.
공동 책임의 오독. 실제로는 여러분 소유인 것을 제공자가 보호한다고 가정하는 것. 수백만 레코드를 유출하는 공개 버킷으로 가는 전형적인 길.
사후 생각으로서의 비용. 지출을 고려하지 않고 설계했다가 청구서가 아키텍처 결정을 대신 내렸음을 발견하는 것.

성숙도 모델

1단계, 시작: 클라우드 사용이 즉흥적이고 반응적입니다. 팀들이 공유 계정에 자원을 클릭해 만들고, 워크로드는 리프트 앤 시프트되며, 랜딩 존도 비용 가시성도 없고, 복원력은 설계되지 않고 가정됩니다. 첫 심각한 장애나 청구서 쇼크는 놀람입니다.
2단계, 발전: 기본 실천이 나타나지만 팀마다 다릅니다. 일부 핵심 인프라가 코드로 프로비저닝되고 일부 워크로드가 다중 영역으로 돌며 몇몇 계정이 분리되지만, 범위는 고르지 않습니다. 서비스 모델과 종속 선택은 습관으로 이루어지고, 비용은 사후에 지켜보며, 가드레일은 일관되지 않고, 다중 리전 복구는 테스트되지 않았습니다.
3단계, 표준화: 코드형 정책 가드레일을 갖춘 다스려지는 랜딩 존이 문서화되어 조직 전체에서 시행됩니다. 플랫폼 팀이 기반을 소유하고, 프로덕션의 모든 것이 코드로 프로비저닝되며, 잘 설계된 리뷰가 중요한 설계를 관문 통제하고, 만들기 대 사기와 장애 도메인 결정이 모든 팀에서 의도적이고 일관되게 기록됩니다.
4단계, 관리: 자산이 기준선에 대해 측정되고 통제됩니다. 팀별 서비스별 비용이 목표에 대해 FinOps로 추적되고, 복구 시간 및 복구 시점 목표가 주장이 아니라 검증되며, 가드레일 위반과 설정 표류가 지표로 드러나고, 적정 크기 조정은 사용률 데이터가 이끌며, 각 진행 여부 결정은 비용, 신뢰성, 보안 대시보드의 증거가 뒷받침합니다.
5단계, 오케스트레이션: 클라우드 아키텍처가 비즈니스 및 위험 계획과 통합되어 지속적으로 개선됩니다. 장애 도메인이 일상적인 게임 데이로 실행되고, 적정 크기 조정과 가격 책정이 자동화되고, 주권과 거주가 정책으로 시행되며, 서비스 모델과 종속 입장이 정기 주기로 다시 가격 매겨지고, 시장, 가격, 위험 그림이 이동함에 따라 워크로드 포트폴리오가 적응적으로 재균형됩니다.

논의를 위한 아이디어

IaaS에서 서버리스까지의 스펙트럼에서 주요 워크로드 각각은 어디에 있으며, 실제로 필요한 통제를 잃지 않고 운영 잡무를 덜어 내도록 더 높이 올라갈 수 있는 것은 있습니까?
주요 제공자가 가격을 급격히 올리거나 며칠짜리 리전 장애를 겪는다면 실제 계획은 무엇이며, 그것이 지고 있는 멀티 클라우드나 하이브리드의 복잡성을 정당화합니까?
랜딩 존과 그 가드레일은 누가 소유하며, 팀이 오늘 비준수 자원(공개 데이터 저장소, 암호화되지 않은 볼륨, 허용되지 않은 리전)을 출시할 수 있습니까?
규제되거나 주권 워크로드에서, 공동 책임 경계와 인가된 설정을 소동 없이 증거로 제시할 수 있습니까?

핵심 요점

데이터 센터를 사진 찍지 말고 클라우드를 위해 설계하십시오. 탄력성, 관리형 서비스, 장애 도메인 인식이 여기 있는 이유입니다.
범용 작업에는 서비스 모델 스펙트럼의 관리형과 서버리스 쪽으로 올라가고, 통제가 정말 비용만큼 값을 하는 곳에서만 낮게 두십시오.
리전과 가용 영역을 명시적 장애 도메인으로 만드십시오. 다중 영역이 기준선이고, 다중 리전은 테스트된 복구 목표에 묶입니다.
코드형 정책 가드레일, 별도 계정, 기반을 소유하는 플랫폼 팀이 있는 다스려지는 랜딩 존 안에서 모든 것을 코드로 프로비저닝하십시오.
벤더 종속의 가격을 양방향으로 정직하게 매기고, 구체적인 규제, 주권, 최고 제품의 이유가 요구하지 않는 한 멀티 클라우드를 회의적으로 보십시오.
FinOps로 비용을 일급 품질 속성으로 다루고, 놓친 트레이드오프를 잡도록 잘 설계된 리뷰를 실행하십시오.

참고 문헌과 더 읽을거리

Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework and Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (and the “6 Rs” migration strategies)
J.R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, FedRAMP programme documentation and security baselines
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing