[컨퍼런스 후기] AWS Community Day 2023 Seoul

JOY·2024년 1월 8일

2023년 10월, 아키텍처·데브옵스 트랙을 들으러 AWS Community Day Seoul 행사에 다녀왔다. 아키텍처·데브옵스, 서버리스, 분석·인공지능 총 3가지 트랙이 동시에 다른 장소에서 진행되었는데, 아키텍처·데브옵스 트랙만 해도 100명 넘는 개발자들이 참석한듯 했다. (주최측에서 공유해주신 행사 현장 사진들을 보다가, 내 얼굴이 찍혀있어서 가져와봤다. 😝)

행사에 입장할 때 네임 뱃지와 여러 굿즈들이 제공되었다. 그때는 몰랐는데 네임 뱃지 다시 보니 이름을 html name 태그로 감싼 형태인게 너무 귀엽다!! 굿즈는 우산, 티셔츠, 에코백 등등 센스있는 제품들로 가득했지만, 무엇보다도 가장 마음에 든건 "개발자 전투 식량"이었다.

개발자 전투 식량은 전투 식량처럼 꾸며진 패키지에 달콤한 간식들이 잔뜩 들어 있었다. 🍬 특히 패키지 앞면에 작은 글씨로 적혀있던 "과잉 섭취는 과도한 개발 의욕을 불러일으켜 지나친 야근 및 피로에 시달릴 수 있음"이라는 주의 문구가 인상적이었다. 🤭

백엔드 개발자가 AWS DevOps 트랙에 관심을 가진 이유가 뭘까?

당시 재직중이던 회사에는 인프라팀이 따로 있어서, 내가 직접 회사 인프라를 다룰 기회는 없었다. 하지만 사이드 프로젝트를 할 때 AWS로 인프라를 구축하거나 개선해야하는 경우가 종종 있다. 현재 작업하고 있는 Scents Note의 인프라 부터 배포 파이프라인까지 직접 구축 및 관리하고 있다. 뿐만 아니라, 인프라를 직접 다룰 일이 없더라도 인프라에 대한 지식이 풍부하면 서버 코드를 효율적으로 설계하고 성능을 향상시킬 수 있다.

회사마다 백엔드 개발자의 업무 범위가 다르기 때문에 백엔드 개발자가 DevOps까지 관여하는 경우도 많이 볼 수 있다. 그만큼 인프라는 시스템을 구축하고 운영하는데에 백엔드와 필수적으로 연관되어 있으므로, 백엔드 개발자에게도 꾸준히 공부해야하는 영역이다.

Session - 어쩌다 AWS 인프라 구축

by 안정수 발표자님 (카카오 서버 엔지니어)

안정수 발표자님은 회사에서 신규 프로젝트 개발팀에 영입을 제안 받으셨다. 자유롭게 실험할 수 있는 환경이 마련되고, 해외 타겟팅 서비스이며 AWS 인프라 사용이 가능하다는 점들에 매력을 느끼고 조인하셨다고 한다. 그러나, 자유가 커질수록 책임감도 늘어났다. 서버 6명 중 AWS 유경험자는 정수님 뿐이었고 혼자 이끌어가기엔 경험이 부족한 상황이었다.

프로젝트의 요구사항은 다음과 같다.

4개월 동안 제품 2개 동시 개발
해외 리전 사용
기존 사내 프라이빗 클라우드와 연결된 구조
사내 보안가이드 준수

이를 위해 필요한 과정은 다음과 같다.

네트워크 기반 구성
사용할 서비스 선택
배포환경 구성
모니터링

Step 1. VPC 어떻게 설계할까?

너무 크지 않으면서 겹치지 않게!

우선, 잘 정리된 AWS VPC 튜토리얼을 살펴보자. 주의해야할 점은 ipv4 CIDR block: 10.0.0.0/16이 매우 큰 사이즈의 네트워크 대역이므로, 시작하는 단계에서는 오버 스펙일 수 있다. 초기 설정할 때 신중해야하므로, 사용하는 API가 몇 개일지 추정하고 그에 맞는 대역을 정하는것이 좋다.

이 외에도 사내 네트워크 대역과의 연결도 고려해야한다. 다른 팀과의 VPC 대역과 겹치지 않으면서, 개발 환경과 운영 환경을 구분해서 설계해야한다.

Step 2. Subnet 구성을 어떻게 할 것인가?

역할에 따라 구분하여 구성하자.

총 4개의 Subnet으로 구성했으며, private Subnet을 기준으로 각각의 역할에 따라 구분하였다. public에는 Nat를 구성하였고, private 3개에는 각각 EKS Woker, Database, 그리고 VPC Endpoint를 구성하였다.

Step 3. AZ는 몇 개로 해야할까?

많을 수록 좋지만, 비용도 생각하자.

AZ(Availability Zone)는 비용 측면과 VPC 대역을 고려하여 결정해야 한다. 보통 많을수록 안정성이 높아지지만 비용 증가와 VPC 대역을 고려해야 한다. Aurora와 같이 다중 AZ를 사용하는 경우 3개의 AZ가 좋은 선택이 될 수 있지만, 비용을 고려해서 2개로 설정하였다.

Step 4. 어떤 AWS 서비스를 선택할까?

Best practice를 많이 살펴본 후 선택하자.

Computing - Amazon EKS
Aws managed라서 편리하길 기대했지만, 도입하는데 시간이 오래 걸렸다. 언젠가 다시 4개월치 프로젝트를 구성한다면 선택하지 않을 거라고 하셨다.

EKS를 도입하는데 오래 걸린 이유는 크게 3가지였다.
1. EKS 노드 그룹 선택
  인스턴스 타입 및 사이즈만 정하면 되는 'managed' 그룹과 pod에 정의된 리소스에 맞게 알아서 맞춰주는 'fargate' 그룹 중에서 고민하다가, fargate 그룹이 좋아보여서 선택했다. 하지만 fargate는 CPU와 메모리 조합이 정해져있어서, cpu나 메모리가 많이 필요한 어플리케이션에는 적합하지 않았다. Fargate 를 사용하기 어려운 경우도 있으므로, 어플리케이션의 요구에 따라 적합한 그룹을 선택하는 것이 중요하다는 점을 기억하자.
2. EKS 노드 사이즈 선택
  Pod 는 IP 할당시 VPC 대역의 IP를 할당 받기 때문에, pod이 많을수록 vpc 대역에 남는 IP 자원이 줄어든다는 문제가 있었다. 따라서 EKS 노드 사이즈를 너무 작지 않게 지정하는것이 중요하다.
3. EKS OIDC 연결 (여기서 가장 많은 시간 소요!)
  AWS는 IAM, Kubernetis에도 RBAC가 잘 되어있기 때문에, IAM에 대해서만 신경을 쓰면 될줄 알았다. 그러나 IAM에 EKS 접근 권한 부여했는데도 EKS와 IAM간의 연결이 이루어지지 않아 많은 시간이 소요되었다. 알고보니, OpenID Connection도 같이 고려해야 했다.
DB - RDS
Aurora와 같은 고성능 데이터베이스 서비스는 대규모 처리 또는 높은 부하를 감당할 때 뛰어난 성능을 보이는데, 이 정도의 성능이 필요하지 않은 상황이었다. 따라서, 가장 익숙한 MySQL을 선택하였다.
Storage - S3
IA 기능 활성화해서 비용 절감 구조 만듬. private subnet 에서 vpc endpoint 연결해서 접근할 수 있게끔함
Push Integration - SNS, SQS, Kinesis
Push Integration은 데이터나 이벤트를 한 시스템에서 다른 시스템으로 전송하는 과정인데, 이를 위해 2개 제품에 각각 SNS, Kinesis를 적용했다. Kafka에 익숙해서 Kinesis를 선택해봤는데, 아무래도 신규 프로젝트에는 오버 스펙이었던것 같다.

Step 5. 어떻게 배포할 것인가?

ECR로 Mirroring

ECR은 Docker 컨테이너 이미지를 저장하고 관리하는 서비스이다. 파이프라인이 만든 Docker 컨테이너 이미지를 ECR에 복사하거나 동기화하여, 이미지를 안전하게 저장하고 배포할 수 있도록 설정하였다.

Step 6. 모니터링

CloudWatch + OpenSearch

Cloudwatch를 주로 사용하되, 일부 로그는 OpenSearch로 확인하였다. CloudWatch로 수집된 로그 중 일부 로그가 Elasticsearch를 사용하는 OpenSearch로 전송되는데, 그 이유는 Elasticsearch의 강력한 검색 기능을 로그 분석에 활용하고자 하는 것이다.예를 들어, 특정 유형의 요청 또는 특정 이벤트에 대한 로그를 OpenSearch에서 검색하여 이상 현상을 분석하고 식별할 수 있다.

7. InfraStructure 관리는 어떻게 할까?

Terraform을 사용해서 코드로 관리하자.

Terraform은 인프런 강의로 공부하고 적용하셨다고 한다. Terraform은 InfraStructure를 코드로 관리할 수 있는 자동화 도구이다. 코드로 인프라를 관리하면 변경 사항을 추적하거나 버전 관리에 용이하다는 이점이 있다. 또한, 인프라 구축 및 변경을 자동화할 수 있어서 안정적인 인프라를 유지하는 데 도움이 된다. Terraform을 도입할때 기본 설정값을 그대로 쓰기보다는, 실제 운영 환경에 필요한 설정값을 잘 파악한 후 적용해야 한다는 것을 기억하자.