본문 바로가기

블로그

LG CNS 기술블로그 DX Lounge에서 최신 IT 소식을 만나보세요!

AWS Ambassador

랜딩존, 끊임없는 혁신으로의 시작

2023.02.01

[ 머리말 ]

이번 화는 랜딩존의 개념에 대한 공감을 위한 글입니다. 시장에서 랜딩존이라는 개념이 존재한지 오랜 시간이 지났고, 수많은 고객이 랜딩존 기반 아키텍처를 활용하고 있습니다. 하지만 때론 만들면 좋다고 만들었을 뿐 무엇이 좋은 것 인지 고객도 담당자도 공감하지 못하고 또 그 공감 부족에서 오는 랜딩존의 효율성 / 활용성 저하도 목격해왔습니다. 

공감과 이해가 충분히 따라오지 못하면 랜딩존은 그 자리에서 정지하게 되고 이는 랜딩존이 더 진화할 시간을 놓치게 됩니다. 
Landing zone 구축 시 어떤 것이 반영되어야 하는지 모르고 있다면 Control tower의 도입시에도 역시 똑같은 상황이 발생할 것입니다.
이번 화에선 랜딩존이 어떤 장점 / 단점을 가지고 있는지와 어떤 목적을 가지고 있는지, 어떤 것을 고려해야 하는지 분석해 보고자 합니다. 

[ intro ]

랜딩존이 무엇인가? 왜 랜딩존이 필요한가? 이 질문을 참 많이 받았습니다.
결론부터 확실히 말씀드릴 수 있습니다. 모두에게 랜딩존이 필요한 것은 아닙니다. 
단, 이 결론을 위해선 몇 가지 전제조건이 확실해야 합니다.
AWS에 구축된 시스템이 향후 확장되지 않을 것이며,  보안과 운영의 중요성이 강조되지 않아야 합니다. 예를 들어보겠습니다.

하나의 시스템을 AWS에 만드는 것을 벌판에 하나의 집을 짓는 것으로 생각하겠습니다.
먼저 집을 지어야 합니다. 수도관, 가스관, 전기선 등을 땅을 파고 연결합니다. 집을 위한 기반 작업입니다.
그 위로 시멘트를 올려 기반을 다지고, 벽을 올리고 지붕을 올리고 층계를 짓습니다. 벽지를 붙이고 조명도 달았으며 가구를 들여서 집이 완성됩니다. 

AWS도 같습니다. 계정을 만들고 전용선을 연결하고 VPC 네트워크를 생성하고 서브넷, 라우팅, endpoint 등을 만들었습니다.
시스템을 올리기 위한 기반 네트워크 작업이죠. 그 위에 서버를 올리고, EFS, S3와 같이 저장 공간도 만들었으며 필요에 따라 lambda, EMR,EKS, Sagemaker와  같은 PaaS형 서비스도 올렸습니다. 그리고 그 위에 애플리케이션을 올림으로서 서비스를 완성했습니다. 

자 이렇게 한 집을 만들어 살고 있는데, 옆집이 필요하다고 합니다. 
다시 땅을 파야 합니다. 수도관, 가스관, 전기선 등을 작업하고 똑같은 반복 작업을 수행했습니다.
단 그 집은 그 주인의 마음이다 보니 다른 디자인, 다른 형태, 다른 크기를 가지고 있습니다.
이렇게 계속 집이 확장되어 하나의 마을을 이루었습니다. 

이제 문제가 발생하기 시작합니다.

(1) 매번 집을 지을 때마다 기반 작업을 한 탓에 수도관 가스관 등이 너무 복잡해졌습니다. 
    따라서 기존 구성의 보수작업 및 신규 작업이 더 어려워지고 시간이 더 소요되며 비용이 많이 듭니다.
(2) 집의 형태가 다 다르다 보니 마을을 관리하는 쪽에서 집마다 문서를 다르게 작성해야 합니다.
    관리가 어렵고 복잡해졌습니다. 보수할 수 있는 사람도 집을 지은 사람만 가능하고 정보 업데이트도 어렵습니다.

하나의 집을 만들 땐 괜찮습니다. 집이 늘어나면서 비용, 효율성, 관리 등 모든 측면에서 문제가 발생합니다. 

 * Tips! 

바로 여기서 랜딩존의 장점이 나타납니다. 
(1) 처음 기반 작업을 할때 아예 언제든 확장이 가능한 구조로 수도관, 가스관, 전기선을 포설 합니다. 
즉, 이후 들어오는 집은 그저 연결만 하면 됩니다. 계정 및 네트워크, 관리 요소가 완성되어 있기 때문에  시스템 구축의 속도가 향상되고
구축 비용이 감소됩니다.
(2) 집이 모두 균일한 형태와 구조를 가지고 있습니다. 어느 누구든 보수 및 작업이 가능하며 같은 정보를 공유하고 있습니다. 
일관된 규칙 적용 및 모니터링이 가능하여 훨씬 용이한 관리가 가능해졌습니다.

* Tips!

장점은 아래와 같습니다! 
 (1) 최초 구성 시엔 시간이 더 걸릴 수 있으나 향후 빠른 구축 및 유연한 확장 가능
 (2) 장기적 관점에서 아키텍처 확장 시에 구축 비용의 절감 가능
 (3) 보안 / 운영의 관점에서 균일한 정책 반영을 통해 구현이 용이하고 및 향후 감사에도 손쉬운 대응 가능 

단점은 단순합니다.
(1) 최초 구성 시 도입 비용이 증가
(2) 최초 아키텍트에 대한 복잡성이 증가 

실제 예시를 들어 설명해 보겠습니다. 같이 고민해 보시면 더 공감이 가능합니다.
랜딩존이 도입되기 전, 대부분 아키텍트는 아래와 비슷했습니다. 

1. 단일 Account에 대부분 리소스 구현 
2. Multi VPC 기반의 운영 / 개발 분리 
3. IGW 및 인터넷 관문 다중 배포 

여기서 보안 감사를 받으면 이런 요구 조건이 추가됩니다.

(1) 운영 및 개발의 네트워크를 분리할 것
(2) 사용자에게 최소한의 권한만을 부여할 것
(3) 모니터링 및 각종 운영용 SW 설치 시 management 및 콘솔의 위치, 로그의 누적 위치 등의 애매함의 존재

비용적 효용성을 위해서 이런 고민이 추가됩니다. 

(1) UTM / WAF 등 매우 고가의 3rd party SW 도입 개수 증가 
(2) 리소스가 단일 계정에 혼재되어 비용 관리 시 정리가 어려움 

운영적 측면에선 이런 문제가 있습니다

(1) 서로 다른 naming, 서로 다른 Tag 
(2) 다수 서버를 운영하는 입장에서 서로 다른 형태의 시스템은 장애 대응의 리스크 상승 
(3) 신규 환경 구축 시 기존 VPC에 남아 있는 IP가 많은 상태에서도 분류를 위해 신규 VPC 생성 필요 

그래서 위와 같이 진화하게 됩니다.

      (1) 운영 및 개발의 네트워크를 분리할 것  > account를 분리함으로서 본질적인 분리 수행 
      (2) Multi VPC 기반의 운영 / 개발 분리 > 운영 / 개발과 같은 특수 계정을 제외하고는 모두 단일 VPC 구현 및 네트워크 ip 낭비 최소화
          운영 계정의 VPC를 공유함으로써 유연하고 빠른 적용 가능 
      (3) 인터넷 관문 통일을 통한 보안정책 단일화 및 3rd part SW 구매 대수 감소, 비용 효율화 
      (4) 로그 저장의 단일화를 통해 로그 파일 조작과 같은 보안 사고 방지 및 관리 용이화 
      (5) 관리를 위한 콘솔 및 계정 관리의 단일화를 통한 환경 분리, 관리 용이화 


[ 결론 ]

결국 랜딩존의 탄생은, 위 [그림] 과 같은 경험을 통해 어려운 점들을 한데 모아 진화한 형태인 것이며 고정된 형태가 아니라 끊임없이 구축과 운영을 통해 더 낫고 효율적인 구성을 찾아가야 합니다. 엔터프라이즈, 공공, 은행 등 높은 보안 기준과 운영 정책을 보유한 고객일수록 랜딩존의 도입은 효과적이고 필수적입니다. 이렇게 장점을 갖춘 랜딩존 아키텍처를 갖춘 후에도 사용을 늘리지 않고 또 다른 AWS 계정을 생성하고 비용, 보안, 운영적으로 균일한 정책 반영을 활용하지 않을 것이라면 그 경우엔 랜딩존을 갖추지 않아도 좋습니다. 하지만 그렇지 않다면, 랜딩존은 단점보단 장점을 훨씬 많이 갖춘 아키텍처입니다.  

챗봇과 대화를 할 수 있어요