Day 1: AWS Developer Bootcamp for Startup
둘째날에도 첫째날과 마찬가지로 같은 교육장에서 진행됐다. 둘째날 주제는 Observability, CI/CD, IaC - CDK 등의 주제를 AWS 서비스를 활용해서 세션을 진행해주셨다.
아래 내용은 2일차 AWS 부트캠프를 듣고 리마인드할 내용을 적었습니다.
10:00 - 11:00: Observability
사용자가 많아질수록 서비스는 점점 복잡해지기 마련입니다. 복잡한 서비스에서 발생하는 다양한 문제를 조기에 식별하기 위해 우리는 Observability(o11y) 환경을 고민하게 됩니다. AWS 환경에서 어떻게 o11y 인프라를 구성할 수 있는지 o11y에 대한 개념부터 관리형 서비스로 구성하는 방법까지 살펴봅니다.
Observability
우리는 어떤 메트릭을 모니터링할지 지정하고, 오류 조건이 발생했을 것으로 가정/예상 되는 임계치를 기반으로 알람을 설정한다. 알람이 발생하게 되면 대시보드와 인프라를 확인하고 대시보드에서 이전 메트릭들의 패턴을 보고 문제 상황을 인식하게 된다. 추가적으로 모니터링이 필요한 지표가 발견되면 대시보드에 추가한다.
우리는 이렇게 모니터링을 하고 있지만, 예측 불가능한 새로운 이슈가 발생했을 때 근본 원인 파악이 어렵다. 또한 사용자 경험 이슈와 데이터 품질 문제를 간과하고 있고, 복잡한 시스템 아키텍처 이해에 어려움을 겪고 있다. 이렇게 문제 발생 시 장기간 원인 분석에 많은 인력과 비용이 투입돼서 운영 비효율이 발생한다.
이런 문제를 해결하려면 시스템 전반의 상세 데이터를 기반으로 근본 원인을 효율적으로 분석하고 개별 사용자 요청의 전체 컨텍스트 데이터와 요청/응답 데이터를 수집하고 파악한다. 개별 요청의 종단 간 추적으로 전체 시스템에 대한 이해도를 높히고 데이터 기반의 체계적인 분석으로 문제를 신속하게 파악하여 해결한다.
Observability란
Observability는 o11y라고도 표현하며 시스템의 내부 작동을 알지 못해도 해당 시스템에 대해 질문할 수 있게 함으로써 외부에서 시스템을 이해할 수 있게 해준다.
o11y와 Monitoring의 차이
o11y는 빙산 전체를 바라보는 것과 같다. 풀스택을 모니터링하고, 시스템 전반을 이해하기 위해 로그와 매트릭과 traces(요청이 들어왔을 때 병목현상이 어디서 발생했는지 추적)를 수집한다. 이 문제가 왜 발생했는지, 이 문제가 어떻게 발생했는지, 문제가 일어나기 전에 선제 조치한다.
monitoring은 시스템 일부만 알 수 있다. 빙산의 일각이다. 단순히 컴포넌트를 모니터링한다.
o11y는 더 중요해지고 있다. 잠재적 문제를 식별하여 트러블 슈팅 시간을 줄여서 생산성 향상, 고객의 이탈을 막는다.
o11y의 구성 요소
- 계측: 시스템의 상태를 이해하기 위한 데이터 수집 및 분석 과정, 텔레메트리 개념 포함
- 수집 및 저장: 속도, 확장성, 내구성, 비용 고려 / 통일된 수집기, 스토리지 티어링
- 시각화: 수집되고 저장된 데이터를 쿼리 / 런타임의 첫 디버깅 도구
계측
계측은 코드를 사용하여 소프트웨어에서 이벤트를 측정하는 것이다. 화이트박스 모니터링의 일종이다. 계측에 사용되는 도구로는 Prometheus, Grafana, OpenTelemetry 등이 있다. 특히 OpenTelemetry는 다양한 언어를 지원하고 오픈소스이다. 분산된 로그들을 수집하기 좋다.
가장 많이 사용되는 o11y 도구는 Prometheus라고 한다.
CloudWatch
AWS NATIVE SERVICES 중에 o11y tools로 CloudWatch가 있다. 리소스, 애플리케이션 및 서비스에서 준실시간으로 로그를 수집하고 저장한다. 수집 대상으로는 EC2, 온프레미스 서버, VPC Flow logs, AWS CloudTrail, AWS Lambda, 기타 AWS 서비스이다. 비용은 PUT log 이벤트 비용과 로그 양 비용을 더해서 산출된다. 따라서 비용을 줄이기 위해 Agent 레벨에서 패턴을 추가하여 필요없는 로그는 전송하지 않게 구성한다.
X-RAY
애플리케이션의 성능 문제 및 오류의 근본 원인을 파악한다.
- 분산 애플리케이션의 성능 분석 및 디버그
- 대기 시간 분포를 확인하고 성능 병목 현상을 정확히 찾아낸다.
- 애플리케이션 전반에 걸쳐 특정 사용자 영향을 식별한다.
- 다양한 AWS 및 온프레미스에서 작동한다.
- 실시간 짧은 지연시간으로 프로덕션에서 사용 가능하다.
11:00 - 11:50 : CI/CD
애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 DevOps 개념을 살펴봅니다. 그리고 AWS CodePipeline을 통해 어떻게 조직이 안전하고 안정적으로 애플리케이션 및 인프라를 업데이트할 수 있는지 알아봅니다. 본 세션에서는 AWS CodePipeline 데모를 통해 빌드에서 배포까지 소프트웨어 릴리즈 프로세스를 자동화하는 방법에 대해 확인할 수 있습니다.
CI/CD
-
CI (지속적 통합): 개발자가 커밋을 하면 빌드와 테스트가 자동화 되는 과정
-> 목표: 버그를 빠르게 발견, 배포 주기를 빠르게, 소프트웨어 품질 향상 -
CD (지속적 전달&배포): 실제 프로덕션 환경에 배포하는 과정
-> 전달과 배포의 차이: 사용자의 승인이 필요한가 아닌가에 따라 다름 -
배포 주기는 짧으면 짧을수록 오류율이 낮다. 빠르게 배포하는것이 중요하다.
AWS에서 CI/CD 파이프라인 구축하기
- 소스 단계
- 소스를 안전하게 관리해야 한다.
- 소스 취약점을 탐지해야 한다.
AWS CodeCommit:
완전 관리형, 조직의 코드를 프라이빗 저장소에 안전하게 저장한다.
깃허브 서비스와 다른점은 완전 관리형이기 때문에 리소스를 관리할 필요가 없고 확장도 자동, 전송하는 과정에서 암호화가 되기 때문에 보안측면에서도 우수하다. IAM과 연동되어 코드 커밋에 대한 권한도 컨트롤 할 수 있다. 리포지토리 사이즈 리미트도 없다.
CodeGuru: 코드 취약점을 발견해주는 서비스
- 빌드&테스트 단계
AWS Codebuild:
젠킨스 같은 경우에는 직접 서버를 운영해야 한다.
코드 빌드 같은 경우에는 완전 관리형 서비스로 별도의 서버 운영이 필요없다.
여러 빌드를 동시에 처리할 수 있고 빌드 작업이 몰렸을 때 latency가 없다.
캐싱 기능을 제공해 빌드 시간을 더 빠르게 단축시킬 수 있다.
사용한만큼 지불하는 온디멘드 방식이여서 합리적인 가격으로 사용 가능하다.
- 배포 단계
AWS CodeDeploy:
코드 배포를 자동화하는 완전 관리형 배포 서비스
각 단계를 엮어서 파이프라인을 구축한다.
AWS CodePipeline:
- 모니터링 단계
CloudWatch, X-Ray, Grafana를 활용하여 모니터링한다.
13:30 - 15:30: IaC - CDK
Infrastructure as Code(IaC)의 개념과 필요성에 대하여 알아보며, AWS CloudFormation, AWS Cloud Development Kit(CDK) 등 AWS 환경에서 IaC 환경을 구성할 수 있는 도구들에 대하여 소개합니다.
IaC - CDK
AWS 웹 콘솔을 사용해서 인프라를 구축한다면 편리하긴 하지만, 애플리케이션이 커지고 같은 리소스를 반복해서 배포한다면 많은 시간과 관리하는데 어려움이 있을 수 있다.
- 수동 설정
- 많은 시간 소요
- 관리, 감사의 어려움
- 오류에 취약
- 재사용 불가
IaC (Infrastructure as Code) - AWS CloudFormation
- 전체 스택을 배포하기 위한 단일 정보 소스
- 복제, 재배포 및 용도 변경이 가능한 인프라
- 인프라와 애플리케이션의 버전 관리를 함께 제어
- 서비스 실패 시, 마지막 정상 상태로 롤백
- 인프라 구축 및 CI/CD 파이프라인을 통해 실행
AWS CDK
- 클라우드 인프라를 재사용 가능한 구성 요소를 모델링하기 위한 오픈 소스 다국어 소프트웨어 개발 프레임워크
- 인프라 구조를 코딩하는 것이라고 생각하면 됨
- 언어도 많은 언어를 지원해서 컨텍스트 스위칭할 부담이 없음
-> 타입스크립트, 파이썬, 자바, 자바스크립트, C#, Go
장점
- 인프라를 로직을 통해서 정의
- 객체 지향 기술을 통해서 시스템의 모델을 생성
- 높은 레벨의 추상화
- IDE의 자동완성 기능을 통해 더 빠르게
AWS CDK 예시
CDK Prerequisites and Installation
AWS CDK Toolkit을 명령어를 통해 설치:
npm install -g aws-cdk
설치된 AWS CDK의 버전을 확인:
cdk --version
가장 많이 사용하는 CDK CLI 명령어
cdk bootstrap- AWS 환경(계정+리전)에서 CDK를 사용하기 위해 처음 한번 초기화 작업
cdk init - 새로운 CDK 프로젝트를 생성
cdk synth- 스택에 대한 AWS CloudFormation 템플릿을 합성하고 출력
cdk deploy - 스택을 AWS 계정에 배포
cdk diff - 현재 배포된 스택 인프라와 업데이트된 버전 간의 차이 표시
cdk destroy- 스택 삭제
실습 - CDK 코드를 사용해서 CDK 앱을 만들고 배포해보자
실습을 진행하기 전에 환경 구축을 했다. 아마존 Q를 직접 세팅하여 사용해보았다.
코드를 입력하게 되면 아마존 Q가 어떤 코드를 칠지 예측하여 제시한다.
정의했던 람다함수가 호출되는것을 확인했다.
15:40 - 17:00: AWS 개발자의 생산성 높이기
개발자 분들이 AWS를 처음 사용할 때 알고 있으면 유용한 팁과 Amazon Q Developer와 같이 AWS에서 개발 생산성을 높일 수 있는 도구의 활용에 대해 이야기 합니다.
AWS 개발자의 생산성 높이기
AWS CLI
- AWS 웹 콘솔에서는 지원하지 않고 CLI에서만 지원하는 기능들이 있다. CLI를 잘 활용하자.
- Command Completion: CLI 자동완성 기능
- Tab 키를 사용해서 명령을 완성할 수 있는 bash 호환 명령 완성 기능
(명령, 매개 변수, 리소스를 제안)
- Auto prompt: 명령을 보다 쉽게 입력할 수 있는 도구
-> 화살표 키를 사용해서 제안을 탐색하고 Enter 키를 사용해서 명령을 완성
세션 매니저
서버에 ssh를 통해 접속하면 로그가 남지 않고, 키가 노출 돼었을 때 큰 보안사고 발생
세션 매니저를 사용함으로써 키 발급이 필요없고, 세션 매니저를 통해 접속한 활동들은 모든 로그가 남게 된다.
참고자료
AWS Startup 팀(https://www.awsstartup.io/)에서 제공해준 발표자료
