Table Of Contents
- 배경
- 시스템 구조 및 설명
- 접근 1. 어떤 특성을 가진 클라우드 서비스를 활용할 것인가?
- 결론 1. AWS EC2 < AWS Lambda
- 접근 2. 데이터는 안전하게 이동하는가?
- 최종적인 Output
- 추가적인 정보들
- 1. Lambda 의 Cold Start
- 2. Lambda 사용시 주의할 점
- 3. Lambda 의 인터넷 액세스
- 마치며
개요
약 한달 전 쯤 AWS 공인 개발자와 AWS 솔루션 아키텍트 자격증을 두 가지를 취득했습니다.
오늘은 제가 최근 SFTP 와 Web-Scrapping 서비스의 AWS 클라우드 아키텍처를 설계를 한 경험을 소개하려고 합니다.
여기서
"SFTP 와 Web Scrapping" 을 == "배치잡"
"우리가 진행하는 프로젝트" 를 == "솔루션" 으로 간략히 부르겠습니다.
제가 참여하게 된 프로젝트는 이미 운영되고 있는 클라우드 네트워크에 추가되는 솔루션입니다.
서비스의 자세한 설명은 보안상 생략하겠습니다.
여러 정보들을 집계하여 통계를 내리는 등의 기능을 수행하며 기존 클라우드 네트워크와 함께 전반적으로 퍼블릭으로부터 격리되어 있습니다. 개발 환경 또한 Public Web 과는 연결이 되지 않을 예정입니다.
저에게는 솔루션의 기능들 중 퍼블릭 웹 접근을 필요로 하는 SFTP 와 Web-Scrapping 서비스를 설계하는 기회가 주어졌습니다.
시스템 구조 및 설명
하이레벨의 네트워크 및 시스템 구조는 아래 다이어그램과 같습니다.
1. 기존 Private Cloud에서 가동될 프로젝트(솔루션) 입니다.
2. 제가 참여하는 부분입니다.
설계시 고려 대상인 부분들은 다음과 같습니다.
- 기능
- SFTP : File Transfer, 스토리지 서비스인 AWS S3 에 저장
- Web-Scrapping : 파이썬으로 작성된 프로그램을 통해 데이터 수집 (클라이언트 제공) 후 RDS 데이터베이스에 저장
- 보안
- 네트워크 Isolation 레벨은 최대한 그대로 유지하기
- 네트워크
- SFTP 와 Web-Scrapping을 위해서는 퍼블릭 웹에 접근 필요
- 솔루션은 기존 VPC (가상 클라우드 네트워크) 내부에서 가동
- 사용패턴
- 고정적인 실행 패턴. 일정 주기로, 특정 시간대에 실행
접근 1. 어떤 특성을 가진 클라우드 서비스를 활용할 것인가?
일반적인 Batch Job 과 마찬가지로 솔루션의 배치잡 또한 사용패턴이 (일정 주기로, 특정 시간대에 실행) 고정적입니다. 배치잡 실행 이후에는 메모리를 보존할 필요도 없습니다. 배치잡 실행 외 시간에는 서버 작동을 유지 할 필요가 없으니 On-Demand / Pay-Per-Use 방식의 클라우드 서비스를 활용하여 자원 사용과 발생 비용을 동시에 최적화하는 접근을 할 수 있습니다.
그러한 AWS 서비스로 IaaS(Infrastraucture as a Service) 인 AWS EC2 와, FaaS(Function as a Service) AWS Lambda 가 있으며 아래에 이 두 가지를 비교해 보았습니다.
결론 1 : AWS Lambda 활용하기
- 비용
- 매월 10000GB 정도의 연산을 수행한다는 가정하에 EC2 와 Lambda의 매월 발생 비용은 유사합니다.
- 예상 가능한 서비스의 Metrics을 가지고 다음 URL에서 모든 AWS 서비스의 예상 발생 금액을 계산해 볼 수 있습니다. https://calculator.aws/#/addService
- 보안 & 리소스
- 솔루션은 클라이언트의 Virtual Private Cloud 에서 가동됩니다.
- 배치잡을 EC2 인스턴스 위에서 실행한다면 public 노출의 이유로 별도의 VPC 내부에서 가동시켜야 합니다. 즉, 배치잡을 위해 추가로 서버와 AWS Account 운영해야합니다. 그러므로 보안, 리소스 관리를 AWS에게 위임하며 서비스에 집중 할 수 있는 Lambda 사용이 유리하다는 결론을 내렸습니다.
- 프로그램 관리
- 우리의 배치잡은 정확히 SFTP 와 웹 스크래핑 두 가지의 기능을 수행하게 됩니다. 배치잡은 매우 고정적인 동작패턴을 가진 부분이므로 서버 관리는 AWS에 위임하고 기능에 집중하는 방향을 고려하게 되었고 이 부분에서 역시 Lambda 사용이 유리하다는 결론을 내렸습니다.
- AWS 에서 운영하는 Lambda Function와 개발팀이 직접 운영하게될 EC2 인스턴스를 비교해보겠습니다.
- Lambda 활용시 필요한 노력과 자원은 10N, EC2 는 50N 정도가 필요하다고 가정해볼 수 있습니다.
- 만약 최악의 경우, 서비스의 치명적인 결함으로 인해 운영중인 서비스를 다른 하나로 전환해야하는 상황이 온다면 최소한의 자원을 투자한 Lambda에서 EC2로 전환하는 노력과 상대적으로 많은 자원을 투입한 EC2 에서 다시 Lambda 로 전환하기 위한 노력을 비교해본다면 Lambda 로 서비스를 하는 것이 더 나은 선택인 것을 알 수 있습니다.
- 확장성
- 수직, 수평적 확장은 두 서비스 모두 가능합니다.
접근 2. 데이터는 안전하게 이동하는가?
이번에는 EC2 vs Lambda 비교 분석을 데이터 보안 수준에 적용해 보겠습니다.
우리는 기존 클라우드 네트워크의 보안 수준을 최대한 유지하며 데이터를 전송해야 합니다.
만약 EC2 와 Lambda 모두 같은 데이터 암호화 방식과 같은 인증 방식을 사용한다면 이 둘의 보안 수준은 동일할까요?
아닐 가능성이 크며 그 이유는 아래 다이어그램을 통해 설명해보겠습니다.
1번은 Lambda 에서 RDS와 S3로의 데이터가 이동하는 프로세스를 나타낸 것이며 2번은 EC2 사용시를 나타낸 것입니다.
여기서 Lambda, RDS, S3 이 세가지는 모두 fully-managed by AWS, 즉 AWS에서 운용하는 서비스입니다.
즉 AWS 가 관리하는 네트워크들 중 어딘가에서 작동하고 있습니다.
하지만 EC2 는 사용자가 직접 운영하는 서버이며 분리된 VPC에서 작동하니 RDS, S3 접근시 라우팅 되는 과정을 한번 더 거쳐야 합니다.
이를 바탕으로 근본적인 보안수준에서 Lambda 가 앞선다는 근거를 내렸습니다.
참고자료 : Security : EC2 vs Lambda
Final Output
- Lambda 를 메인으로 배치잡 서비스 아키텍처를 구성했습니다.
- 예상을 뛰어넘는 단순한 구성도가 도출되었습니다. 보안적인 이유로 생략한 부분들이 있다는 점, 복잡한 것이 더 나은 성능을 뜻하는 것은 아니라는 점을 고려해서 봐주셨으면 합니다.
- 우선 Lambda Function을 WebScrapping 과 SFTP 두가지 목적으로 나누어 작성합니다.
- SFTP 로 수집된 파일과 웹스크래핑한 데이터는 write-only 권한(IAM Role)이 부여된 S3와 RDS의 특정 공간에 저장되며 솔루션은 메인네트워크에서 S3 와 RDS 에만 접근하여 데이터를 활용할 수 있습니다.
- 여기서 Cloud Watch는 스케줄링 및 로깅 목적을 사용됩니다.
- CloudWatch 는 설정한 이벤트에 반응하는 Event-Driven 서비스입니다.
- 소스코드 업데이트, EC2 인스턴스의 과부하, 스케줄링 등의 이벤트 발생시 CloudWatch로 알람이 전송되며 CloudWatch 는 알람을 확인 후 대상 작업을 트리거하는 역할을 수행합니다.
- CloudWatch는 AWS에서 운영합니다. CloudWatch 와 Lambda 조합은 자주 사용되는 패턴이며 다음 AWS의 블로그에서 설명 확인이 가능합니다. https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents.html
추가적인 정보 1. Lambda 의 Cold Start
1. 파이썬이 AWS Lambda Function 위에서 작동하기 최적화 되어있는가? 에 대한 질문으로 웹 서핑을 하던 중 Lambda Cold Start에 비교 글을 보았습니다. Lambda 또한 (사용자가 관리하지 않을 뿐) 어떤 서버에서 실행되고 있습니다. 그러므로 다른 클라우드 서버들과 마찬가지로 Cold Start 라는 개념이 존재합니다.
위는 csharp, Java, Python, NodeJS의 Lambda ColdStart (지연시간) 를 비교하는 그래프입니다. 정적 타입 언어인 자바와 CSharp가 동적 타입의 python 과 nodejs 보다 100배 정도 긴 지연시간을 소모한다는 결과입니다.
이 4개의 언어를 Compiled 와 Interprted 두가지로 다시 분류해보아도 결과는 유사하다는 것을 알 수 있습니다.
추가적인 정보 2. Lambda 사용시 주의할 점
람다 사용시 주의할 점은 Lambda function은 호출 당 15분 시간 제한이 있다는 점입니다.
Lambda function의 메모리는 (function 당) 10000MB 로 늘려서 컴퓨팅 파워를 높일 수는 있지만, 그보다는 여러 Lambda Function을 병렬 처리를 고려하는 것이 더 효율적이라 생각이 됩니다.
추가적인 정보 3. Lambda 의 인터넷 액세스
Lambda Function 에서도 일반 프로그램 처럼 API 호출이 가능하며 관심이 있으신 분들은 아래 관련 블로그들을 참고하시면 좋을 것 같습니다.
Serverless Architecture for a Web Scraping Solution (웹스크래핑 솔루션을 위한 서버리스 아키텍처)
FAQ : Amazon VPC에 연결된 Lambda 함수에 인터넷 액세스 권한을 부여하려면 어떻게 해야 합니까?
https://aws.amazon.com/ko/premiumsupport/knowledge-center/internet-access-lambda-function/
Make API calls from AWS Lambda to access backend database ( AWS Lambda 에서 백엔드 DB 로 API 요청하기 )
https://shawn-shi.medium.com/make-api-calls-from-aws-lambda-to-access-backend-database-e23abcbfc45a
마치며
저의 다른 자료들도 참고 바랍니다.
- 🌱 Blog (Medium) : https://medium.com/@beanskobe
- 🌱 Blog (티스토리) : https://vince-kim.tistory.com/
- 📫 Portfolio (포트폴리오) : https://romantic-golick-a520aa.netlify.app
- ✏️ LinkedIn (링크드인) : https://www.linkedin.com/in/joo-hyuk-kim/
- 🌎 Contact me : beanskobe@gmail.com
읽어주셔서 감사합니다!
