2022.04.20 AWS 인프라 구성하기 사내 세미나

사내에서 AWS 인프라를 세팅하는 과정을 세미나 형식으로 진행하게 되었다. L 서비스를 함께 개발했던 동료분이 대부분의 API 구현을 해주셨고, 나는 인프라 같이 보이지 않는 일들 위주로 진행했다. 함께 QA용 서버를 구성하면서 인프라 인수인계 해달라고 요청주셔서 겸사겸사(!) 팀원들 대상으로 AWS 세미나를 진행했다.

진행방식

온라인으로 진행됐다. 동료분이 드라이버(Driver)로 화면을 공유해주셨고, 내가 네비게이터(Navigator)로 진행했다.

팀원분들에게는 구글밋으로 Optional로 초대해서 혹시 흥미 있으신 분들은 온라인 미팅 참석하실 수 있게 했는데, 예상외로 모든 팀원분들이 참석해주신다고 하셔서 인수인계 목적에서 세미나 성격이 더 강해졌다. 그래서 듣는 사람이 인프라에 낯설 수도 있다는 가정을 하고 진행했다.

총 3시간이었고, 50분 진행 후 10분 휴식 시간을 가졌다.

세미나 목적

• L 서비스의 QA 서버 구성
• 인프라 인수인계
• 인프라가 낯선 팀원분들이 있다면 진입 장벽을 조금이라도 낮추기

L 서비스 구성도

개발서버는 대략 아래 다이어그램처럼 구성되어 있다.

• 공통적으로 사용해도 되는 자원들은 dev와 qa가 공용으로 사용 (S3, CodeDeploy 어플리케이션 등)
• 일부 자원 및 스크립트는 QA용으로 신규 생성함 (DNS, 로드밸런서, 타겟그룹, 인스턴스, CodeDeploy 배포그룹 및 스크립트, Github Actions Workflow 스크립트 등)

서버 구성도

• 개발자의 커밋
  1. 개발자가 특정 브랜치에 커밋을 push
  2. Github Actions이 트리거되어 Application을 빌드하여 S3 업로드
  3. 빌드파일 업로드 후 CodeDeploy에게 알림
  4. CodeDeploy는 타겟 인스턴스에 S3에 업로드된 빌드파일을 가져옴
  5. Deploy를 위한 CodeDeploy 스크립트 수행
• 사용자의 요청
  1. 사용자가 API 요청
  2. DNS 서버(Route 53)는 해당 요청을 받아줄 곳을 탐색하여 로드밸런서로 요청 전달
  3. 로드밸런서는 요청을 지정된 타겟 그룹에게 전달 (+로드밸런서에 SSL 적용함)

---

세미나 진행 순서

QA 서버 띄우기

• EC2 생성하기
  • 개발서버와 동일한 OS와 AMI 선택
  • EC2 이름은 개발서버와 동일한 패턴으로 명명
  • 모든 AWS 자원 생성 시 Name 태그는 반드시 입력하기
• 보안그룹 연결
  • 일종의 방화벽으로 AWS가 추상화한 개념
  • 기존에 생성한 개발서버와 동일하게 매핑
  • 보안그룹 적용 후 SSH 접속이 가능한지 확인하기
  • 만약 접속이 되지 않는다면 보안그룹 규칙을 확인하기
• 수동 배포 (자동배포는 아래에서 다룸! 이 작업이 얼마나 번거로운 지 안내하기 위함)
  • 로컬에서 수동으로 Spring Application 빌드하여 jar 파일 얻기
  • Linux scp 명령어를 이용하여 jar 파일을 생성된 서버에 업로드
  • jar 파일 실행
  • 서버의 Public IP를 통해 Health Check처럼 단순한 API 호출해보기

로드밸런서 붙이기

• 로드밸런서 생성
• 타겟그룹 지정하기
• 로드밸런서 Public DNS로 Health Check처럼 단순한 API 호출해보기
  • 만약 되지 않는다면 보안그룹을 확인하기
  • 만약 되지 않는다면 로드밸런서의 라우터와 타겟그룹을 확인해보기
• 로드밸런서의 장점과 사용이유에 대해 언급

호스팅 (예쁜 이름 붙이기)

• Route53
• 호스팅된 주소로 Health Check처럼 단순한 API 호출해보기

SSH 인증서 붙이기

• DNS 서버(Route 53)에 등록한 주소로 HTTPS 요청을 해보자 → 안됌!
• 로드밸런서에 SSH 인증서를 연결해 HTTPS 프로토콜로 요청 가능하게 함
• HTTPS 프로토콜로 Health Check처럼 단순한 API 호출해보자 → 되야함!

자동 배포

• 수동 배포가 얼마나 번거로운 과정인지 확인하였으니 이제 자동화가 필요해짐
• CI/CD를 지원해주는 툴 선택하기
  • 굉장히 다양한 선택지가 존재 → Github Actions, Travis, Jenkins, AWS CodeDeploy, AWS Beanstalk...
  • 지금 설정하는 과정이 낯설어도 괜찮음. 내 필요에 맞는 CI/CD 툴을 선택한 다음 사용 방법은 그때 공식 문서를 보고 배우면 됨. 어지간하면 친절하게 가이드가 되어있으니 사용 방법이 바로 이해가지 않아도 괜찮음. 여기서 이해해야할 건 ‘맨 처음에 했던 수동 배포 과정을 어떤 툴을 이용해서 자동화하는 것일 뿐’ 이라는 것!
  • 현재 개발서버와 동일한 구성으로 선택 → Github Actions, AWS CodeDeploy
• Github Actions : jar 빌드 및 CodeDeploy를 수행하는 데에 필요한 스크립트를 압축하여 S3에 업로드 후, CodeDeploy 배포그룹 트리거 실행하는 workflow.yml 스크립트 작성
  • Github Actions는 깃헙에서 제공하는 무료 컴퓨팅 자원이라고 생각하면 편함!
  • 깃헙에서 제공하는 표현 방식으로 스크립트를 작성하면 되는데, 물론 sh 파일을 작성 후 이를 실행시킬 수도 있음
  • 개인적으로 생각하는 장점은 Git 브랜치나 특정 파일에 변경이 생겼을 경우 이벤트 트리거가 가능하고, 코드와 함께 관리할 수 있고, PR 시 Github Actions 수행 내역을 바로 볼 수 있다는 점
• CodeDeploy : 배포그룹 생성하고 공식 가이드대로 appspec.yml 스크립트 작성

---

전달하고 싶었던 말 요약

• 수동배포 괴롭다! 자동화해보자!
  • Github Actions : 수동으로 jar 빌드하고 서버에 업로드 했던 부분을 Github Actions로 자동화
    • 자동화하면서 추가된 작업 : 트리거 시점(ex: qa 브랜치에 push 되었을 때), AWS 인증, 서버에 바로 업로드하지 않고 S3에 파일 업로드, Github Actions 가이드대로 workflow yml 스크립트 작성
  • AWS CodeDeploy : 서버에 접속하여 수동으로 jar 실행시켰던 부분을 CodeDeploy로 자동화
    • 자동화하면서 추가된 작업 : CodeDeploy appspec.yml 스크립트 작성, jar 실행을 위한 shell 파일 작성
  • 근데 Github Actions, AWS CodeDeploy 같은 툴들의 사용 방법들은 몰라도 된다. 나중에 필요해지면 공식문서와 구글링을 해보면 다 나와있다! 어떤 작업을 자동화하기 위해 썼는지만 알면 된다! 그리고 나중에 다른 툴을 사용하게 될 수도 있다!
• 로드밸런서(AWS ALB)의 장점과 사용 이유
  • 부하 분산
  • 다양한 분산 알고리즘
  • SSL 처럼 공통적인 보안 적용 가능
  • 로드밸런서에 대해 공부하고 싶으면 Reverse Proxy도 함께 공부
• 호스팅
  • AWS의 Route 53은 DNS 서버를 우리가 사용하기 편하게 추상화 해놓은 것
  • Route 53 설정이 어렵다? → AWS가 문서를 어렵게 작성해 놓음
  • Route 53에서 제공하는 옵션을 이해할 수 없다? → 내가 DNS에 대한 이해도가 부족한 거니까 공부하면 됌! DNS가 왜 필요한 지, 어떤 기능을 제공해주는 지 알면 AWS가 얼마나 사용하기 쉽게 추상화해놓은 지 알 수 있음
• SSL
  • HTTPS 프로토콜 사용하기 위해 인증서 등록 (거의 필수적인 작업! AWS ACM에 이미 등록해둔 인증서를 로드밸런서에 붙임)
  • 각 서버가 HTTPS 요청을 받아들일 수 있게 인증서 등록을 했어야했는데, 앞단에 있는 로드밸런서에 인증서를 등록하여 HTTPS 프로토콜 사용 가능하도록 함
• 단계적으로 HealthCheck API를 호출하여 잘 진행되는 지 확인한 이유
  • 나도 인프라 뉴비인지라, 내가 원하는 대로 동작이 안될 때 추적이 어려웠음 (=디버깅 미리미리)
  • 테스트를 하면 각 세부단계별로 어떤 동작이 되야하는 지 이해하기 좋음 (=공부에 좋다)

---

회고

세미나하면서 나온 의견

• QA 타겟그룹을 가르키는 로드밸런서는 제거하고, 기존 Dev 로드밸런서 사용하기
  • QA로 세트로 한벌 만든다는 생각에 로드밸런서도 따로 만들었는데, 로드밸런서 하나에 A 레코드 2개를 연결해서 각각의 dev, qa 타겟그룹을 가르키게 해도 될 거 같다!
  • AWS 덕분에 이 작업 자체는 클릭 몇 번으로 쉽게 변경 가능한데, 이거는 다른 분이 작업하면서 배웠던걸 세미나하면 좋지 않을까 싶다!

아쉬운 점

• 제한된 시간(3시간) 안에 더 가볍고 알차게 우겨넣지 못한 것들
  • L 서비스의 기존 서버 구성을 먼저 안내하지 않았던 점이 아쉬움. 먼저 말씀드리고 목차를 말했더라면 더 와닿지 않았을까 싶음. 이미 3시간 진행한터라 더 넣긴 애매했겟지만 틈틈이
  • 기존서버구성 안내 → 어떻게 진행할지 목차 안내 → 서버생성 → 수동배포 → 로드밸런서 연결 → 호스트 연결 → SSL 적용 → 자동배포 순으로 진행했으면 좋았겠다.
• 보안그룹 설정 같은 것도 요즘 유행하는(?) 베스트 프락티스들이 조금씩 다르다는 걸 알려줄 걸! 여러 회사에서 사용하는 방법들 리서치해서 알려줄걸!
• 순차적으로 진행하느라 각각의 툴들에 대한 세부적인 설명을 못한게 아쉽다. 설명을 못했더라도 간단하게 이게 어떤거고 이런 옵션들이 있고, 이 옵션들이 어떤 의미인지, 조금이라도 더 알려주었으면 좋았을텐데..!
• 매끄러운 세미나 진행을 위해서 어떻게 진행할지, 말씀드려야하는 옵션들이 뭐가 있을 지 미리 검토해본 뒤라서, 설정하는 과정이 너무 술술술(?) 되는 거 처럼 보였을 것 같음. 그래서 나도 단계마다 몇 시간 헤맸고 지금 세미나는 미리 준비해둔 내용이라고 말씀드리긴 했는데 충분했을까 의문임
• 좀 더 응원해줄걸!

좋았던 점

• 동료가 드라이버, 내가 네비게이터
  • 설명의 부담(나)과 조작의 부담(동료분)을 분리해서 좋았음! 내가 조작하면서 말까지 했으면 너무 떨렸을 거 같은데 동료분이 컨트롤하시면서 작업을 안내하고 설명만 하니까 재미있었다
  • 같이 설정하면서 ‘서로 이렇게도 할 수 있겠네요~’라고 하며 알고 있는 지식을 나누는 과정이 좋았음
• AWS 구체적인 구현 가이드와 AWS가 추상화해놓은 서비스를 분리해서 설명하려고 노력한 거
• 세부적인 구현 방법은 몰라도 되고, 나중에 구현해야할 때 이런 게 있다 정도만 알아달라고
• 위에서 느꼈던 아쉬웠던 점들을 해소하기 위해 이것저것 정리해서 팀 슬랙에 공유함
  • 기존 서버 구성도를 그려서 세미나에서 진행했던 작업들이 뭐였는 지
  • 세미나에서 사용한 AWS 서비스가 어떤 걸 추상화한 건지
• 응원을 다시 했는데!! 효과가 있었을까?!
  • 응원 1 : 언젠가 인프라 작업을 하게 되니까 그때 공부하면 된다! 지금 공부하던 거를 멈출 필요는 없고 이런게 있다 정도만 아시면 된다!
  • 응원 2 : 툴(Github Actions, CodeDeploy 등) 사용법을 몰라도 괜찮고, 왜 하는지만 알면 됌! 나중에 다른 툴 쓸 수도 있으니 그때가서 공식문서 참고하면 됌
  • 응원 3 : 정답은 없고 서로 적합하다고 생각하는 아키텍쳐와 기술을 선택하면 되는 것! 그리고 이건 불변이 아니라 시간이 지나면 언제든지 변경될 수 있음!

---

함께 읽으면 좋은 자료

• Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2
• AWS 아키텍처 기본