aws architecture experience

신규 서비스 개발을 위한 AWS 사용 경험기

2023-02-04 (수정 :2023-02-06 22:50:00)
Table of Contents

AWS를 활용하여 신규 서비스 개발하기

작년 한 해 동안 신규 조직에서 새로운 서비스를 개발하는 미션을 부여받았다. 이전까지는 on prem 를 기반으로한 private cloud를 활용한 인프라스트럭처 구조를 사용했었는데, 이번에는 AWS를 사용하여 서비스를 개발해야 하는 상황이었다. 그동안의 커리어 중에서 AWS를 접해본건 2011년 처음 접해보았고, 2016년도에도 AWS를 기반으로 서비스를 개발해보았었지만, 밑바닥부터 AWS를 사용하여 주도적으로 인프라를 설계한 것은 이번이 처음이었다. 아쉽게도 프로젝트가 도중에 중단되는 바람에 더 이상 서비스 개발을 진행하지는 못했지만, AWS를 사용해서 인프라스트럭처를 설계하고 개발해본 경험을 정리해보았다.

서비스 요구사항

  1. 해외 사용자를 대상으로하는 신규 앱을 위한 백엔드 인프라. REST API와 모바일 앱을 제공하는 것.
  2. API 서버 애플리케이션은 K8S 환경위에 돌아가는 구조를 마련하기.

적용 컨셉

  1. 빠른 시간내에 인프라 스트럭처를 구성하는 것을 목표로 하였다.
  2. 기존 on prem 환경에서 k8s 기반 개발 경험이 있으므로, 이와 유사하게 AWS EKS 기반으로 인프라 구조를 잡기로 했다.

사용한 AWS 서비스

  1. S3 (스토리지)
  2. CloudFront (CDN)
  3. EKS : K8S 클러스터 사용
  4. EC2 : EKS Worker 로 EC2 인스턴스를 사용하여 직접적으로 사용하지는 않았다.
  5. ElasticCache (Redis) : Redis 캐시를 위한 ElasticCache
  6. Kinesis, SQS, SNS : Mobile Notification 용도로 사용
  7. Lambda : 이미지 썸네일 생성 및 모니터링 알림 용으로 사용
  8. Route 53 & Certificate Manager : 도메인 및 인증서 관리

인프라 스트럭처

AWS infra structure
설계한 인프라 스트럭처 요약

보안

계정 관리 정책

  1. root 계정은 사용하지 않고, administrator 계정을 별도로 생성하여 사용하였다.
  2. 개발용 계정과, Production 에서 사용하는 AWS Account 분리하여 관리하였다.
  3. 개발자 개인 계정을 생성하되, 필요한 권한만 부여하여 권한 부여를 최소화 하였다.
  4. 모든 개인 계정은 MFA 활성화 하여 접근하도록 관리했다.

권한 부여

  1. 기본적으로 Role Base 권한 체계를 지향하였다.
  2. Web Application (Spring boot)이 구동될 때는 EC2 인스턴스에 Role을 부여 하여 AccessKey & Secret 을 직접 사용하지 않도록 하였다.
  3. S3 는 퍼블릭 엑세스를 제한하고 Role 을 통한 접근만 허용하였다.

네트워크

  1. AWS 네트워크는 사내 내부망과 DirectConnect 로 연결하였다.
  2. 모든 Web Application 은 private subnet 에서 구동되도록 하여 외부에서 접근할 수 없도록 하였다
  3. EKS 는 private api 만 접속을 허용하였다.
  4. RDS 는 사내 내부망 or VPC 대역에서만 접근을 허용하였다.
  5. VPC 내부에서 AWS managed service 에 접근하기 위한 VPC EndPoint 를 생성하고 이를 위해서 endpoint 전용 subnet을 생성하였다.

고민들

1. VPC 대역정하기

  • AWS의 시작은 뭐니뭐니 해도 VPC이기 때문에 VPC 설계를 어떻게 해야할지 고민이 되었다.
    • VPC 대역을 얼마나 크게 잡아야 할까?
    • 흔히 VPC 설계 튜토리얼 문서에 나오는 10.0.0.0/16 대역은 너무 크다.
    • 다른 리전에서도 VPC를 활용중이기 때문에 대역이 겹치면 나중에 통신에 문제가 발생한다! (처음에 고민을 잘해야한다)
    • 초기 활용하는 주요 서비스는 EKS 클러스터 이므로 이 클러스터가 운용할 Pods 수량에 맞춰서 잡아야 한다.
    • EKS 클러스터는 관리차원에서 클러스터 버전업을 해야할 때가 있는데, 이 경우 라이브로 production EKS 클러스터를 업그레이드 하는 것은 너무 리스크가 크다. 따라서 신규 EKS 클러스터를 셋업하고 트래픽을 넘기는 방향으로 진행하기로 한다. -> 이를 위한 예비 대역이 필요하다.

2. 인프라스트럭처 (Subnet 구성)

  • VPC 대역을 결정한 다음 subnet 을 어떻게 할것인지 고민을 했다.
    • 프로젝트의 서비스는 흔한 모바일 API 를 제공하는 기능을 필요로 했다.
    • 외부 트래픽을 받는 ALB를 위한 public subnet 이 필요했다. (+Nat gateway)
    • EKS Worker 를 위한 private subnet 이 필요했다.
    • 데이터베이스를 위한 private subnet 을 구성하기로 했다.
    • AWS Managed Service (ElasticCache, S3 등)과 연결하기 위한 VPC Endpoint 용 private subnet 을 구성하기로 했다.
    • 최종적으로 public 1 개, private 3 개로 구성하였다.
  • AZ는 몇개나 사용해야할지 고민했다.
    • 기본적으로 2 AZ는 고려했는데 3개로 할지 2개로 할지 고민되었다.
    • 당연히 3 AZ로 가면 좋겠지만 그만큼 비용이 추가되기 때문이다.
    • AWS aurora가 아닌 RDS mysql 을 사용하기로 해는데 데이터베이스의 write / read replica 설정에 따라 3AZ를 필요로 하기도 했다.
    • 최종적으로는 2AZ로 구성하기로 했다. (3AZ는 과해보여서)

3. EKS 클러스터 사이즈

  • EKS Node Group 인스턴스 타입 정하기 EKS 클러스터를 구성할 때에는 얼마나 큰 node size를 정해야 하는지 고민이 되었다.

4. 배포파이프라인

  • 배포를 어떻게 할 것인가? 다음으로 배포를 어떻게 할 것인가에 대해서 고민이 했었다.
    • 이건 뭐 정답이 없기 때문에 오히려 더 고민이 되었다.
    • 최종적으로는 on prem 에서 container 이미지를 만들고
    • 만들어진 container 이미지를 ECR 에 push 한 다음
    • Codebuild 를 트리거 하여 EKS에 rolling update 했다.
    • Code Commit + ECR + Code Build 구성을 할 수도 있었지만,
    • on prem 에서 운영하던 Image Security Scanning 기능을 더 선호하였기 때문에 이렇게 구성하였다.

5. 기타

  • 이미지 썸네일 생성을 위한 방법
    • 서비스를 만들다 보니 이미지 썸네일 생성 기능이 필요했는데 다음의 2가지를 리서치 했다.
      • lambda를 사용하여 이미지 업로드시 미리 생성해두기
      • on demand 로 생성하기
    • 그 중에서 일단 lambda를 사용하여 이미지 업로드시 미리 생성해 두는 방식으로 했는데 이게 더 간편하고 시간이 덜걸려서 이 방법으로 개발하였다.
  • Mobile App Push Notification 구조
    • SQS+SNS를 통해서 APNS, Firebase FCM notification을 사용하도록 설계하였다.
    • SNS의 mobile push 를 iOs, Android 용으로 각각 생성하였다.

어려웠던 점

  1. AWS에는 수많은 기능들이 존재한다. 따라서 필요한 기능을 적재적소에 활용할 수 있으면 쉽고 빠르게 인프라를 준비하고 서비스를 개발 할 수 있다. 그렇지만, 그 만큼 방대한 내용을 이해하고 있어야 하는데, 짧은 기간안에 서비스를 만들어 냈어야 하는 나의 입장에서는 그 많은 내용들을 빠르게 이해하고 적용하기가 쉽지 않았다. SA분들과 AWS 파트너의 지원이 없었다면 빠르게 대응하기 어려웠을 것이다.
  2. 인프라 스트럭처를 구성하는데 정답이 없다. 따라서 프로젝트의 성격, 처한 상황에 따라서 절절한 스트럭처를 구성해야했는데 이게 계속해서 결정을 해야하는 상황이다 보니 그런 점에 있어서 피로감이 많이 쌓여갔다.
  3. 이런 AWS의 문제라기 보다는 우리 팀의 사정이었는데, 서버 개발 인원이 나를 포함하여 6명이었는데 그 중에 AWS 서비스 운영 경험자가 나뿐이었기 때문에 초반에 설계하고 정보 공유하는 역할을 도맡아 하느라 힘든 부분이 있었다.

소감

  1. 이번에 AWS를 활용한 인프라 구성을 경험하면서 느낀점이 필요한 기능들이 참 적재적소에 잘 준비되어 있다는 점이었다. 과거 2011년 처음 AWS를 접했을 때는 VPC도 없고, EC2 만 덩그러니 있었던 시절이라, 참 많이 좋아졌구나를 알 수 있었다.
  2. AWS에는 무수히 많은 세부 서비스들이 존재한다. 하루가 멀다하고 신규 서비스와, 기능 업데이트 공지가 올라오기 때문에 세부 서비스들에 대해서 모두 알기는 어렵다. 다행히 커뮤니티의 도움과 SA분들의 도움을 받을 수 있었지만, 계속 공부해야 한다는 점이 쉽지는 않다. 그만큼 함께 고민을 나누고 경험을 나눌 수 있는 커뮤니티 활동이 더 중요하다고 생각들었다.

마치며

길다면 길고 짧다면 짧은 기간동안 AWS를 기반으로 밑바닥 부터 인프라를 설계하여 서비스를 런칭해보았다. 앞으로 또 다른 프로젝트에서 다시 사용해보는 경험을 기대해본다.

comments powered by Disqus
FEATURED TAGS
accesscontrol alpine-linux ansible ansible-tower apache2.4 architecture argocd aws awx backoffice beautiful-goodbye begining-docker benchmark blockhound blocking-code blog book brew-cask build-cache collaboration communication composer confluence cronjob curl customizing customlog data.sql database developer difference docker docker-desktop dockerize dos-attack eks elasticsearch empty-string environment-to-do-well errorlogformat event-driven experience file-upload filebeat fluentd forwarded-option fuse.js golang graceful-deploy happy-new-year haproxy haproxy-1.8 haproxy-acl-logging haproxy-custom-variable-logging haproxy-metric haproxy-reload-fail haproxy-stat heap-memory how-do-i-work hugo index-alias install installation instance-type inverted-index istio iterm java jdk-21 jekyll jekyll-to-hugo jetbrains json k8s k8s-api kmooc kubernetes leadership learning-in-2019 lets-encrypt letsencrypt limit_req_zone logstash m1-macbook-pro macro macro-key-mapping mapping match match_phrase maven microservice-설계-및-구현 migration mm multi-datasource mysql nginx nginx-ingress nginx-regexp ngram null openjdk partial-matching phpstorm poeaa query-dsl rate-limit rate-litmiting rds reindex rss-template seamless-reload search-on-hugo service-account-role sidebar-search speed-up speedup spring spring-boot spring-camp spring-camp-2023 spring-event ssh struct study system-manager systemd-reload template term throughput timezone tips traffic-management ulid unused-plugins uuid ux-consideration virtual-thread vm-options webflux wildcard zero-downtime 만들면서-배우는-클린-아키텍처 시작하세요-도커 엔터프라이즈-애플리케이션-아키텍처-패턴 쿠버네티스-시작하기