3. AWS 서버리스 서비스
AWS Fargate
• 서버 프로비저닝 / 관리 없이 컨테이너 실행
• EC2 인스턴스 없이, Auto-scaling 지원
• On-Demand 과금 정책
• High-availability (다중 AZ 서비스)
• 지정된 ECR 이미지를 수행하도록 설정 가능
4. AWS 서버리스 서비스
• 서버 프로비저닝 / 관리 없이 코드 실행
• Auto-scaling 지원
• On-Demand 과금 정책
• High-availability 서비스 제공
• 자동 복구
AWS Lambda
5. 개발 프로세스 동작 방식
• 애플리케이션 호스팅부터 사용자 클릭 데이터 수집까지 서버리스로 진행
• EC2의 사용은 개발을 위해 사용된 Cloud9 서비스 이외에는 없음
• 개발 종료 이후에는 EC2 사용 없이 서비스 지속 가능
• AWS 튜토리얼 “현대적 웹 애플리케이션 구축“ 을 따라 진행
6. 프로세스
구축 단계
&
이용 서비스
S3 서비스를 이용하여 웹 Front-end 구성
• CloudFormation 템플릿을 통한 인프라 구성
• Fargate 서비스로 서비스 배포
• CodePipeline을 이용하여 CI/CD 구현
Back-end 구성
DynamoDB를 이용하여 Database 구성
API Gateway, Cognito를 이용한 사용자 인증 구성
Lambda와 Kinesis Firehose를 이용한 사용자 클릭 데이터 수집
7. 1. 웹 Front-end 구성
• Cloud9 서비스를 이용하여, AWS-CLI를 통해 진행
• 단순히 S3의 정적 웹 호스팅 기능을 이용하여 F/E 구성
8. 2.1. CloudFormation 인프라 구성
• CloudFormation 템플릿을 이용하여 인프라를 구성
• 위와 같이 1개의 VPC, 2개의 public, 2개의 private 서브넷으로 구성
9. 2.2. AWS Fargate를 이용한 배포
• 로드밸런서를 이용한 AWS Fargate 서비스를 활성화
• S3 버킷에 담긴 페이지 주소를 수정하여 API 호출 값을 나타냄
21. 진행 중 발생한 문제(1)
Fargate의 파일을 변경하기 위해 커밋하였는데, Code build 실패 발생
단계 세부정보에도 docker build가 실패하였다는 정보만 출력
22. 진행 중 발생한 문제(1) 해결
- 빌드 로그를 통해, python-pip 패키지 설치가 안되고 있는 상황 확인
- 구글링을 통해 해결 방법 확인 (참고 링크) => 빌드 오류 해결
23. 진행 중 발생한 문제(2)
문제(1) 해결 직후, 발생한 문제
- API 호출 시(ApiEndPoint) 접근이 되지 않고, ‘Permission denied’ 문제 발생
- 사용한 스택의 콘솔로 접속한 결과, ELB 타겟 그룹에 문제 확인
24. 진행 중 발생한 문제(2)
확인 결과,
타겟 그룹에 존재하는 Fargate 프로세스의 Status가 생성 이후 즉시
draining 또는 unhealthy 상태로 변하는 문제 확인
25. 프로젝트 진행 중 발생한 문제(2) 해결
- Fargate의 상태 확인을 위해 Codecommit 상태 확인
- 코드 커밋 시 누락된 파일 추가 후 다시 푸시 => 문제 해결
26. AWS Lambda vs. AWS Fargate
• 공통점
• 두 서비스 모두 서버리스 컴퓨팅을 구현하는 서비스
• Auto-scaling을 지원
• On-Demand 요금 정책 사용
• 차이점
• 람다는 코드 중심, Fargate는 컨테이너 중심의 서비스
• 비용모델의 차이
• 그래서, 어떤 것이 합리적일까?
27. AWS Lambda vs. AWS Fargate
• 개발 관점
• Fargate
• 기존 개발 방식에서 자주 이용하는 docker container 기반 서비스
• 익숙한 방식을 사용하여 개발자들의 접근이 용이
• Lambda
• 새로운 개발과정을 도입하거나 익혀야 한다는 점에서 리스크 존재
• 규모가 큰 서비스(업체)의 경우 적용이 힘들다는 약점
• 다만, 신속하게 서비스를 개발할 필요가 있는 경우 우세
28. AWS Lambda vs. AWS Fargate
• 비용 관점
• Fargate
• 시간당 CPU와 메모리 사용량을 기반으로 과금
• Lambda
• 처리 요청수, 처리 소요시간, 메모리 사용량을 종합하여 과금
29. AWS Lambda vs. AWS Fargate
• 하지만 남은 중요한 이슈!
• Lambda는 예열되지 않은(최근 실행된 적 없는) 상태에서 함수
호출 시 Cold Start가 발생
• 지속적으로 함수를 호출하여, 문제를 해결 가능 하지만 추가비
용 발생
• 이러한 점을 고려하여, 자신의 서비스 특성에 맞는 서비스 선택!
https://medium.com/harrythegreat/aws-lambda를-시작하기-전-알았으면-좋았을것들-788bd3b3bdd2
30. 그 이외에 사용한 AWS 서비스들
• AWS Cloud9
• EC2를 이용하여 가상의 개발환경과 웹 IDE를 제공
• 언제, 어디서나 동일한 개발환경을 가질 수 있음
• CodeCommit, CodeBuild, CodeDeploy, CodePipeline
• CI/CD를 위한 AWS CodeServices
• CodeCommit : 프라이빗 Git repo를 제공
• CodeBuild : 코드 빌드 및 테스트
• CodeDeploy : 코드 배포 자동화
• CodePipeline : CD를 위한 코드 파이프라인 제공
31. 그 이외에 사용한 AWS 서비스들
• AWS DynamoDB
• 완전관리형 NoSQL 데이터베이스
• 뛰어난 확장성, 높은 성능
• Elastic Load Balancer
• 해당 프로젝트에서는 NLB(Network Load Balancer)를 사용
• 대상 그룹(타겟 그룹)으로 트래픽 부하를 분산
• Health check 등을 통해 서비스 가용성 확보를 위해 사용
32. 그 이외에 사용한 AWS 서비스들
• Amazon API Gateway
• 손쉽게 빠른 API를 만들 수 있는 서비스
• 프로비저닝이 필요 없다는 장점
• Amazon Cognito
• 사용자 풀, 자격 증명 풀 제공 서비스
• 앱 사용자의 로그인 기능 제공
• 앱에서 사용 시 ‘앱 클라이언트’를 발급받아 사용
33. 그 이외에 사용한 AWS 서비스들
• Amazon Kinesis Data Firehose
• 지속적으로 데이터를 수집, 변환하여 스트리밍 데이터를 특
정 목적지에 전달
• 프로젝트에서는 로그인 사용자의 클릭 데이터를 스트림으
로 S3 버킷에 저장
• AWS CloudFormation
• 템플릿을 통해 AWS 서비스 상의 리소스를 생성, 관리
• AWS-CLI와 함께 사용할 경우 매우 강력한 기능
• 템플릿을 실행하여 언제 어디서나 동일한 Infrastructure를
제공받을 수 있음
34. 프로젝트 진행하며 느낀 점
• 프로젝트는 튜토리얼에 안내되어 있음에도 서비스를 이용하여 그대로 구
성하는 것이 쉽지 않았다.
• AWS CLI와 CodeFormation을 통해 AWS 서비스를 이용해보았다. Git 사용
시 CLI와 CodeFormation을 이용하면, 다른 사람과의 협업에도 AWS를 효
율적으로 이용할 수 있음을 느꼈다.
• CI/CD툴을 이용해보며, 평소 진행하는 프로젝트(리트머스 등...)에도 이러
한 툴을 적용하여 편리하게 작업을 하면 좋겠다는 생각이 매우 들었다.
• 개인적으로 시간이 부족하여, 서비스들을 이용하여 나만의 프로젝트를 진
행하지 못한 점이 크게 아쉽다.
안녕하세요, 정종범입니다.
“서버리스 기반의 웹 애플리케이션 개발~” 프로젝트에 대해 발표하도록 하겠습니다.
혹시 서버리스 컴퓨팅이라는 말, 들어보셨나요?
서버리스... 라면, 서버가 없다는 말일까요?
네 맞습니다. 서버가 없이 컴퓨팅 파워를 이용하는 것이죠.
가장 큰 장점으로는 슬라이드에 보이듯이 서버를 프로비저닝하거나 관리할 필요가 없다는 것이죠!
나머지 3가지는 AWS 서버리스 서비스를 이용했을때의 장점입니다.
그러면, 저희는 서버리스 서비스를 통해 구현한 저희 프로젝트에 대해 살펴보도록 하겠습니다.
바로 시나리오에 대해서 안내해 드릴텐데, 궁금하신 분들은 슬라이드에 각 서비스별 특징이 나와있으니깐, 확인해주세요!
앞서 말씀드렸듯이 제 프로젝트 주제는 서버리스 웹 애플리케이션 구축입니다.
단순히 서버리스 웹을 구현하는 것은 간단하기 때문에, AWS의 다양한 서비스들을 활용하여 현대적인 형태의 웹 애플리케이션을 구축하였습니다.
이를 통해 실제 AWS가 production 수준에서 어떻게 사용되는 지 직접 체험해보았습니다.
발표에 앞서 제 프로젝트는 AWS 튜토리얼을 따라 진행한 내용입니다.
튜토리얼에 대해 궁금하신 분들은 링크를 접속하시면 튜토리얼에 대한 정보를 확인해보실 수 있습니다.
먼저 프로세스 구축 단계입니다.
다음 슬라이드부터는 단계별로 어떻게 구축하였는지에 대해 말씀드리겠습니다.
먼저 웹 FE 구성입니다.
Cloud9과 AWS CLI를 이용하여, S3 버킷을 생성하고, html 파일을 업로드하였습니다.
이후에 S3 정적 웹 호스팅 기능을 이용하여, 해당 웹을 정적으로 호스팅하였습니다.
여기서 부턴 2단계 BE 구성입니다.
CloudFormation 서비스를 이용하여서 제공되는 템플릿을 통해 서비스의 인프라를 구성합니다.
이전단계에세 구성한 인프라 위에 ECS에 존재하는 Fargate를 이용하여, Python Flask앱을 배포합니다.
서로 다른 AZ에 존재하는 2개의 서비스를 구성하여 고가용성, 안정성을 유지합니다.
또한 이전 단계에 저장하였던 S3 버킷의 주소를 수정하여 해당 ECS에 접근할 수 있는 로드밸런서의 주소를 전달합니다.
지금까지 보면 FE에 비해 BE가 설정이 복잡하기 때문에 실제 개발 시에는 BE가 개발의 병목지점이 될 수 있습니다.
따라서 AWS Codepipeline을 이용해서 CI/CD를 구현해두면, 개발 병목 현상을 막고, 더욱 최신의 서비스를 빠르게 사용자들이 받을 수 있게 됩니다.
2.3 단계에서는 이러한 작업을 수행을 하였습니다.
그리고 이제 BE에 AWS DynamoDB를 이용하여, 데이터를 저장하고 읽는데 편리하게 서비스를 수정하였습니다.
그리고, API Gateway와 AWS Cognito를 통해 사용자 인증 서비스를 추가하였습니다.
마지막으로, 로그인 사용자의 클릭 데이터 스트림을 Kinetic Firehose를 통해 Lambda에서 처리한 후 S3 버킷에 스트림을 저장하였습니다.
위 링크로 접근하시면 실제 서비스를 체험하실 수 있습니다.
(가입)
(로그인)
(입양)
(로그아웃)
(로그인)
(입양 상태)
AWS의 서비스 중 서버리스 컴퓨팅 서비스는 2가지가 있습니다.
Lambda와 Fargate.
둘은 모두 오토 스케일링과 온디맨드형 과금 정책을 가지고 있는데요, 그렇다면 어떤 것을 쓰는 것이 좋을까요?
우선 개발의 관점에서 Fargate는 컨테이너 기반, 람다는 코드 기반이라는 중요한 차이점이 있습니다.
Fargate가 가지고 있는 컨테이너 기반은 기존의 개발자들이 자주 사용하던 개발 방식입니다.
다만 어디에서 컨테이너를 실행시키느냐의 차이만 존재할 뿐, 굉장히 친숙한 개발 방식입니다.
반면 람다는 아직 개발자들에게 익숙한 개발 패러다임은 아닙니다.
때문에 만약 서비스를 람다를 이용해 개발하기로 했다면, 개발자들이 이에 익숙해지는데 시간이 필요할 수 있습니다.
다만, 신속하게 서비스를 진행해야한다거나, 간단한 API 같은 경우 Fargate에 비해 Lambda가 생산성 면에서 뛰어날 수 있습니다.
또한 비용을 생각하지 않을 수가 없죠.
다만 둘의 과금 정책은 비교 할 수 없습니다. 과금 모델이 다르기 때문이죠.
Fargate는 생성 시 책정한 정책의 CPU와 메모리 사용량에 따라 과금을 하며,
람다는 코드 처리 요청수, 소요시간, 메모리 사용량을 종합하여 과금합니다.
이 부분은 AWS Pricing calculator를 이용하여 비교해보시면 어떤 서비스가 합리적인지 확인하실 수 있습니다.
그리고 마지막으로 람다의 경우 충분히 준비되지 않은 상태에서 호출하게 되면, 속도가 낮아지는 Cold start가 발생합니다.
빠른 응답이 중요하지 않은 경우, 문제가 되지 않을 수도 있지만, 때로는 심각한 문제가 되기도 합니다.
따라서 상황에 맞는 서비스를 선택하는 것이 좋겠습니다.
이외에도 프로젝트를 진행하며 이용했던 다양한 서비스들에 대한 간략한 설명입니다.
마지막으로, 프로젝트를 진행하며 느낀 점에 대해 말씀드리겠습니다.
발표에서는 간략하게 “어떠한 서비스를 어디에 추가하였다”라는 식으로 말씀을 드렸습니다.
각각의 서비스에 대한 이해가 없는 상태에서 튜토리얼을 따라만 하는 것은 의미가 없다고 생각하여, 각각의 서비스들이 어떠한 목적을 가지고 존재하는지 파악하고자 최대한 노력하였습니다.
서비스들을 이해하고 진행해보고자 하였음에도, AWS CLI 환경에서 진행하는 프로젝트 였기에 진행하는 것도 쉽지 않았습니다.
또한 AWS CLI와 CodeFormation을 사용하여 프로젝트를 진행해보았습니다. 이전부터 이러한 AWS 서비스들은 다른 사람들과 어떤 식으로 협업하여 유지할까라는 생각을 했었는데,
이번 경험을 토대로 AWS 서비스들을 협업에 이용할 수 있을 것 같습니다.
이번 프로젝트에 포함되었던 CI/CD툴을 이용해보니 굉장히 편리하다는 느낌을 받았습니다. 기존에 서비스에도 적용할 수 있는 기회가 되어 적용할 수 있으면 좋겠다는 생각을 했습니다.
마지막으로 개인적으로 시간이 부족하여, 이러한 다양한 서비스들을 저의 프로젝트에 적용시켜 진행하지 못했다는 아쉬운 점이 남습니다.
이제 이러한 서비스들을 익혔으니, 추후에 프로젝트를 진행하게된다면 AWS 서비스들을 적절히 선택하여 진행하도록 하겠습니다.
