AWS 아키텍처 개선 하기

AWS 아키텍처 개선

 

처음부터 AWS의 서비스들을 체계적으로 설계한건 아니였습니다.

 

하나의 계정에서 시작하여 서비스들을 하나씩 추가하다 보니 점점 서비스별 비용 추적이 어려워졌고, 규칙이 정해저있지 않고, 여러 작업자가 참여하면서 어떤 서비스가 어디에 연결 되어있는지 찾는것또한 쉽지 않았습니다.

또한, 모든 작업자가 AWS의 기능을 완벽히 이해한 상태가 아니었고, 필요에 따라 학습하며 서비스를 구축하다 보니 초기 설계가 최적화되지 않았습니다.

이에 따라 운영 및 유지에 필요한 AWS 비용을 분석하고, 이를 바탕으로 비용 절감이 가능한 부분을 개선하는 작업을 진행하였습니다.

 

 

 

 

문제점

개선작업을 진행하기전 어떤 문제가 있는지 문제의 큰 줄기들을 정리해봤습니다.

1. 하나의 AWS 계정에 크고 작은 여러 서비스가 운영되고 있어, 각 서비스별 비용 추적이 어려움
2. 불필요한 서비스 정리 및 관리 필요
3. 서비스별 네이밍 규칙이 없어 가독성이 떨어지고 관리가 어려움
4. 보안 문제

 

 

---

 

개선 작업

 

1. AWS 계정 분리

대형 서비스별로 새로운 AWS 계정을 생성하여 개별적으로 관리하고, 공통 서비스는 기존 계정에서 유지하여 효율적인 관리를 가능하게 하였습니다.

AWS 계정을 분리하면 서비스별 비용을 보다 쉽게 추적할 수 있는 장점이 있지만, 관리해야 할 포인트가 많아진다는 단점이 있었습니다. 서비스를 이전하는 과정에서 발생하는 크고 작은 사이드 이펙트는 수정하면서 해결할 수 있었지만, 계정이 많아질수록 운영 관리의 복잡성이 증가하는 것은 계속 해결해야 할 과제로 남았습니다.

그럼에도 불구하고, 서비스별로 계정을 분리하는 것이 장점이 크다고 판단되어 분리 작업을 진행하였으며, 이후 팀장님께서 AWS Switch Role을 적용하여 계정을 쉽게 전환하며 사용할 수 있도록 설정해 주셨습니다. 이 자리를 빌려 다시 한번 감사드립니다. 😊

 

• 대형 서비스별로 새로운 AWS 계정을 생성하여 개별적으로 관리
• 공통 서비스는 기존 계정에서 유지하여 효율적인 관리 가능

 

 

2. 사용하지 않는 서비스 정리

AWS 환경을 점검하면서 사용되지 않는 다양한 리소스를 발견할 수 있었습니다. 예를 들어, 불필요한 VPC, Subnet, 라우팅 테이블, 사용하지 않는 EC2 인스턴스 등이 있었습니다.

 

이러한 리소스를 즉시 삭제하기보다는, 새로운 계정으로 서비스를 이전하는 과정에서 반드시 필요한 서비스만 선별하여 이동하였고, 남은 불필요한 서비스는 한 번에 정리하는 방식을 선택하였습니다.

이를 통해 운영 중인 서비스에 영향을 최소화하면서도 불필요한 리소스를 효과적이고 안전하게 제거하여 비용을 절감할 수 있었습니다.

 

 

3. AWS 서비스 네이밍 규칙 정리

네이밍 규칙이 없으면 서비스 관리가 어려워지고, 불필요한 서비스 정리에도 혼란이 발생할 수 있습니다. 실제로 사용하지 않는 서비스를 정리하는 과정에서 네이밍 규칙이 없던 것이 큰 어려움으로 작용했습니다. 예를 들어, 서브넷 이름이 test-subnet이라 하더라도 실제 사용 여부를 명확히 알기 어려웠고, 연결 상태를 일일이 확인해야 했습니다.

(참고로, 현재 AWS UI에서는 VPC와 Subnet, 라우팅 테이블 등의 연결 상태를 한눈에 볼 수 있도록 개선되어 개인적으로 좋은 업데이트라고 생각합니다.)

이에 따라, 공통적인 네이밍 규칙을 수립하고 서비스별로 VPC부터 EC2까지 모든 리소스의 이름을 엑셀로 정리하여 컨펌을 받은 후 서비스 이전 작업을 진행하였습니다.

 

 

프로젝트 당시 사용한 네이밍 규칙중 일부

• 서비스명은 대문자로 통일
• 단어 간 구분자는 - 사용
• {AWS서비스명}-{개발|운영}-{가용영역} 형식 적용

 

 

4. Application Load Balancer(ALB) 구조 개선

기존 구조

• 각 인스턴스마다 개별적인 Load Balancer(LB)를 운영하는 1:1 구조
• 각 LB는 하나의 Target Group만 바라보며 별다른 설정 없이 운영됨

변경 전

 

개선 사항

• 개별적으로 운영되던 LB를 공유 ALB로 통합
• Application Load Balancer의 규칙을 활용하여 요청을 적절한 Target Group으로 분배
• 불필요한 LB를 줄임으로써 운영 관리가 용이해지고 비용 절감 효과 발생 (약 N분의 1 비용 감소 예상)

변경 후

 

 

5. 개발 환경 Private Subnet으로 전환

기존 개발 환경은 Public Subnet에 위치하여 보안상 취약점이 존재했습니다. 따라서 개발 환경을 Private Subnet으로 이전하여 외부 접근을 차단하고 보안을 강화하였습니다. 이를 통해 개발 리소스에 대한 불필요한 외부 노출을 방지하고, 네트워크 내부에서만 접근이 가능하도록 구성하여 더욱 안전한 개발 환경을 구축할 수 있었습니다.

 

• 기존에 Public Subnet에 위치하던 개발환경도 Private Subnet로 이전
• 운영환경은 기존에도 Private Subnet에 위치했습니다.

 

 

 6.  S3 접근 방식 변경

기존 방식

• AWS SDK를 사용하여 EC2에서 S3로 직접 접근하여 파일 업로드
• S3는 VPC 외부에 존재하므로 Internet Gateway 또는 NAT Gateway를 통해 접근
• 외부 인터넷 비용 발생 및 트래픽 노출 위험 존재

변경 전

개선 방식

• VPC 내부에 VPC Endpoint(VE) 구성하여 내부 네트워크를 통해 S3 접근
• 외부 인터넷을 거치지 않으므로 보안 강화 및 비용 절감 효과
• 정책세부 설정 필요

변경 후

 

 

전체 서비스 구성도

서비스 구성도

 

 

 

 

---

 

회고

 

이번 AWS 개선 작업은 내가 직접 코드 작업을 많이 하기보단 AWS 인프라 작업을 주로 하게 된 프로젝트였습니다.

처음에는 모든 것이 낯설고 많이 어려웠지만, 매일 공부하고 고민하면서 "이런 방법이 있었구나!" 라는 깨달음을 얻으며 작업을 진행했다. 결과적으로, 이 과정은 저에게 매우 값진 경험이었고, 앞으로 AWS로 서비스를 구성해야 할 일이 생기면 자신감을 가지고 작업할 수 있을 것 같다.

 

처음부터 Best Practice를 적용하는 것이 이상적이겠지만, 사실 항상 최고의 선택을 할 수는 없는것 같다.

빠르게 변화하는 IT 트렌드와 예측할 수 없는 새로운 기능, 그리고 크고 작은 이슈들 속에서 문제를 하나씩 해결해 가는 과정이 중요한 노하우로 쌓이며, 결국에는 마주한 문제에서 가장 최선의 선택을 할 수 있도록 도와주는 것 같다.