스푼라디오에서 플랫폼 엔지니어링으로 가기 위한 여정 — 2편

Martin Choi

Published in

Spoonlabs

10 min readMar 26, 2024

안녕하세요.
Spoonradio에서 SRE팀을 Lead하고 있는 Martin(최상기)입니다.

스푼라디오에서 플랫폼 엔지니어링으로 가기 위한 여정 — 1탄

안녕하세요 스푼라디오에서 SRE 팀에서 DevOps업무를 담당하고 있는 Paul(백영진)이라고 합니다. SRE팀은 지난 5년 동안 AWS Multi-Account Multi-Region에서 서비스의 안정성과…

medium.com

위 “스푼라디오에서 플랫폼 엔지니어링으로 가기 위한 여정 — 1탄”은 복수개의 AWS Account와 Region에서 개발팀은 주도적으로 개발부터 빌드, 테스트, 배포, 그리고 모니터링까지의 작업을 수행할 수 있는 셀프 서비스 환경에 대한 Delivery Infrastructure에서 이야기 하였습니다.

다음으로, 스푼라디오 글로벌 서비스를 효과적으로 운영하기 위해 다수의 AWS Account를 어떻게 관리하고 유지하는지에 대해 공유하고자 합니다.

스푼라디오는 AWS의 Multi Account 및 Multi Region 구성을 활용하여 글로벌 서비스를 제공하고 있으며, 각 서비스 지역마다 조금씩 서로 다른 인프라 구성을 갖추고 있습니다. 이러한 구성은 각 국가별 서비스의 독립성과 보안을 강화하는 동시에, 인프라 운영 비용을 효과적으로 관리할 수 있는 이점을 제공합니다.

그러나, 마치 정원을 잘 관리하기 위해 정원의 목적에 맞게 계획하고 설계하며, 토양 관리, 식물 심기 및 관수, 해충 및 잡초 통제 등 다양한 노력이 필요한 것처럼, AWS의 Multi Account 및 Multi Region 환경을 구성하고 운영하는 것도 여러 고민과 노력을 필요로 합니다.

AWS는 기본적으로 각 Account와 Region 내에서 서비스들을 격리하여 구성함으로써, 각 Account와 Region마다 독립적인 환경을 제공합니다. 그러나 이러한 구조는 동시에 복잡성을 증가시키며, 특히 Multi Account 및 Multi Region 환경에서는 다음과 같은 어려움을 가중시킵니다.

복잡성 증가

동일하지만 조금씩 상이한 보안 정책, 액세스 권한, 네트워킹 설정, 그리고 서비스 인프라 구성 등을 개별적으로 즉 반복적으로 구성하고 관리 해야 합니다.
격리된 네트워크로 서로 네트워크 통신이 필요할 경우 Public으로 처리하거나, 비용과 안정성을 고려해 네트워크 구성을 위해 VPC Peering, Transite Gateway, CloudWan 설정 등으로 복잡성이 증가 됩니다.

비용 관리

복수개의 Account와 Region에 대한 비용 추적관리를 위해 비용 Tag 설정을 보다 적극적으로 진행해야 합니다.
비용 최적화를 각 Account 및 Region 사용 패턴을 지속으로 관리하고, 최적화를 진행해야 합니다. (Savings Plan는 AWS Account와 Region에 제약이 없으나, 아직까지도 Region에 국한된 Reserve Instances 구입 해야 하는 서비스 항목들이 다수 존재 합니다.)

보안 및 규정 준수

다수의 Account와 Region에 걸쳐 보안 정책과 규정을 준수해야 합니다.
IAM 정책과 권한 또한 여러 Account과 Region에 걸쳐서 일관적으로 구성해야 합니다.

데이터 전송 및 지연 시간

여러 Region간 Data를 전송은 추가 비용을 발생시킵니다.
데이터 분석을 위해 서로 멀리 떨어진 Region에 데이터 전송에는 지연 시간이 발생되며, 이는 특히 실시간 분석에 영향을 줍니다.

이 외에도 다양한 고려 사항들이 있고, 이를 극복하기 위한 다양한 방법들이 있습니다. 이중에서 Mutli Account 관리와 보안 및 규정 준수 사항에 말씀 드리겠습니다.

AWS Control Tower

스푼라디오 서비스는 글로벌 서비스로, 각 서비스 지역마다 상이한 인프라 구성을 갖추고 있습니다. 각 워크로드들은 서로 격리된 환경에서 독립적으로 실행되어야 하며 감사, 보안 및 추적성을 확보 할 수 있도록 구성해야 했습니다.

처음에는 서비스 목적별로 Account를 구성(Production, Testbed, 로그수집 등)하여 사용 하였고, 이 개별 Account는 SSO를 통해 접근하도록 구성하였습니다. 이 방법은 나름의 체계(Landing Zone)를 가지고 있다고 볼 수 있으나, 특히 새로운 Account를 추가 할 때마다 동일 반복 설정이 필요했습니다.

그래서 이런 반복 행위를 하지 않고 체계적인 구성(Landing Zone)을 위한 방법을 알아 보다 AWS Control Tower(이하 CT)라는 서비스를 확인하였습니다. 이를 도입하여 현재는 아래와 같이 구성하여 사용을 하고 있습니다.

AWS Organization

여러 AWS Account를 OU(Organization Units) 단위로 조직을 구분하였고, OU 단위 별 SCP(Service Control Policy)를 적용하여 관리를 하고 있습니다. 예로, SCP를 통해 필수 Tag를 설정하지 않을 경우 AWS Resource 생성을 제한 하는 등 다양한 관리 정책을 추가하여 사용하고 있습니다.

AWS Identity and Access Management

여러 Account에 일관된 접근을 구성하였고, 외부 IDP로 Okta를 사용하고 있습니다.

개별 Account에는 IAM 사용자가 없으며, Long-Team Credentials 또한 존재 하지 않습니다. 그 결과 AWS Access Key 노출 위험이 없어졌습니다. 필요시 Tempoary Credientilas를 제공해 사용자의 편의성과 보안을 동시에 보장하였습니다.

Account Factory

AWS Cloudformation과 AWS Service Catalog를 통해 새로운 Account를 일관된 방법(Landing zone)으로 손쉽게 구성을 할 수 있습니다. (예로, Default VPC가 존재 하지 않거나, 사용자 정의 VPC Cidr 등을 구성할 수 있습니다.)

사전 구성된 로그 아카이브 및 계정에 대한 감사 엑세스

Control Tower내 모든 Account의 Cloudtrail, Guardtrails내 Config Log는 LogArchive Account에 적재됩니다. 또한 새로운 Account가 생성될 때마다 전부 중앙에 집계에 되어 적재되는 기본 기능 입니다. 기존에는 Account를 생성할 때마다 수동으로 개별 Account에 설정 후 로그 수집 Account S3 Permission 설정 등 여러 단계를 걸쳐서 구성을 하였던 것이 Control Tower 통해 자동화되어 손쉽게 처리 됩니다.

Controls Library

Account 운영 및 자원 설정시 회사가 정한 보안 규칙에 어긋나지 않도록 처리하기 위한 다양한 Controls libray가 제공 됩니다. 각 항목에 대한 동작 방식이 사전(SCP)과 탐지(Config)가 있는데, 특히 사전용 정책을 적용할 경우 기존에 CT에 편입전 잘 동작하던 서비스들이 동작하지 않수 있기 때문에 테스트 통한 적용이 필요 합니다. 스푼에서는 사전적 동작은 Tag로만 국한해 설정하였고, 나머지는 대부분 탐지인 Config로 구성 하였여 운용하고 있습니다.

CFCT(Customizations for AWS Control Tower)

AWS Control Tower는 멀티 계정 구성을 위한 체계적인 구축을 돕는 유용한 Landing Zone을 제공합니다. 그러나 기본 제공되는 설정을 넘어 추가적인 구성이 필요할 수 있습니다. 예를 들어, 계정별 VPC CIDR 할당, 사용자 정의 IAM 역할 생성, 그리고 추가적인 Control Library 설정 등이 사용자의 환경에 맞춰 필요할 수 있습니다. CFCT는 AWS Control Tower의 기본 제공 Landing Zone을 사용자의 특정 요구 사항에 맞게 확장할 수 있는 방법을 제공합니다. 이 과정에는 AWS Lambda, AWS Config, AWS SCP 등 다양한 AWS 서비스를 CloudFormation을 활용하여 Landing Zone을 확장합니다.

스푼에서는 주로 아래와 같은 기능을 OU 단위 기준으로 Landing Zone을 확장하고 있습니다.

사용자 정의 사전 처리: 특정 Tag가 포함가 되지 않는 경우 AWS Resource를 구성할 수 없도록 사전 처리(SCP).
사용자 정의 탐지 및 자동 문제 해결: unassociated eip 그리고 unattached volmume에 대한 탐지와 이를 자동으로 삭제, CloudWatch Log에 Retention이 적용되지 않은 항목 탐지와 적용, 필수는 아니지만 필요한 Tag가 생성되지 않은 Resource에 대한 탐지 등
사용자 정의 IAM Role: CT 내 여러 Account에 공통 IAM Role 생성시에 활용

2~3개의 AWS Account에 위와 같은 기능을 일관적으로 적용하는 그닥 어려운 일은 아닙니다. 그러나 10개가 넘어가는 Account에 동일 정책을 일관적으로 배포하는 것은 IaC를 사용하더라도 어느 정도의 중복이 발생될 수 있습니다. 그러나 CT Landing Zone을 확장을 도움을 주는 CFCT를 사용하게 되면 보다 편의하게 처리할 수 있습니다.

마치며

스푼라디오에서는 AWS Control Tower를 도입함으로써 AWS 클라우드 환경의 복잡성을 줄이고, 보안 및 컴플라이언스 표준을 유지하며, 클라우드 리소스를 효율적으로 관리하게 되었습니다.

정원 관리는 끝이 없는 작업이며, 충실히 관리하지 않으면 문제가 발생할 수 있습니다. 마찬가지로, 스푼라디오는 앞으로도 AWS Control Tower를 지속적으로 활용하여 글로벌 서비스를 확장해 나갈 것입니다.