• 1 번 글에서 언급한 바처럼

이번 멘토링에서 사용할 기술 스택은 다음과 같다

 

  • Python
    • Flask
  • AWS
    • Lambda
    • API Gateway
    • S3
    • DynamoDB
    • ECS
  • Deploy
    • Gitlab
    • Zappa

이제 해당 내용에 대해 정리를 해보고자 한다.

 

Python 

https://namu.wiki/w/Python

개발을 몰라도 한번씩은 들어봤을 언어이다. 

최근에는 대학교 1학년 필수교양에도 들어가는 것 같던데 나의 경우에는 졸업 직전 여름방학 멀티캠퍼스에서 아주 잠깐...

경험해보고 카카오톡 챗봇을 단시간에 만들어 본 것이 유일한 경험이고

이후에 뭔가 만들어봐야 한다고 생각만 하고 공부를 못했었다.

주요 특징이라면 인터프리터 언어이고 생각보다 오래된 언어이다. 이후에 데이터 엔지니어링 관련 라이브러리들이 많이 나오면서 정말 급상승 한 언어로 인지하고 있다.

아무래도 설치나 환경변수 잡는 등의 세팅이 자바나 다른 언어보다 용이? 하고 쉽기에 많이 입문하는 것으로 보인다.

 

 Flask

플라스크는 Python의 웹 애플리케이션 개발을 위한 프레임워크, Django(장고)도 웹 프레임워크이고 비교도 많이 되며 같이 쓰는 경우도 있다고 한다.

어떤게 더 가볍고 무겁다 이런 비교글들도 있지만 크게 차이는 없는 듯 하며 그냥 개발자의 선호도에 따라 나뉘는 듯? 하다.

누군가는 Flask가 더 배우기 쉽다고 말하기도 하고 사실은 더 어렵다 라는 글도 보인다.

 

프로젝트 레이아웃이 다르고 DB접근 방법에 대한 차이와 내가 원하는 기능을 추가할때의 편의성에 대한 차이가 Django에 대한 주요 차이점으로 보인다.

또한 Django는 RDBMS에 특화되어있고 NoSQL을 사용 한다면 그냥 Flask를 사용한다.

그러면 이제 RDB와 NoSQL에 대한 차이를 알아야 할 듯 하다.

 

RDBMS와 NoSQL의 차이 

  1. RDBMS
    1. 저장방식은 SQL(Strucured Query Language)에 의해 저장
    2. 정해진 스키마(데이터 구조와 제약조건에 관한 명세 기술, 속성 개체 관계)에 따라 데이터를 저장
    3. 테이블과 테이블이 관계를 맺고 있는 집합체 ( 외래키를 사용하여 Join)
  2. NoSQL
    1. 데이터가 증가하며 Scale-Up에 따른 비용 과다 등에 대한 대체 목적을 갖고 등장
    2. 일관성 포기 -> 데이터 분산 ( Scale-Out) - 클러스터링으로 하나의 DB 구성
    3. 유연성, 확장성, 고성능, 고기능성이라는 특징을 갖음
    4. 주로 키 - 값의 관계 ( Key-Value, Wide Columnar, Document(JSON, XML), Graph 등의 구조로 나뉨)
    5. 테이블간 연결 조회하는 join 없음

 

AWS

아마존 웹 서비스 

IT 인프라 구축에 필요한 다양한(엄청) 서비스를 제공한다.

원하는 만큼만 사용하고 비용을 측정하는 방식으로 사용

내가 하고 있는 SAP에서도 On-Premise와 Cloud(Rise)로 나뉘는 부분에서 Cloud에 해당

장기적으로 보면 On-Premise가 비용은 저렴한 듯 하지만, 소규로로 작업하거나 특정 트래픽때 사용하기에 유용함

 

  • Lamda
    • 서버를 프로비저닝, 관리 하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스
    • 코드 실행, OS유지 관리, 용량 확장, 모니터링, 로깅 등 모든 컴퓨팅 리소스 관리를 수행
    • 코드는 Lamda함수로 구성, C# GO Java 파이썬 루비 등 언어 지원
  • API Gateway
    • 규모에 관계 없이 API를 손쉽게 생성, 게시, 유지관리, 모니터링 할 수 있는 완전관리형 서비스
    • RESTful API,  WEBSOCKET API 지원
    • 서버 앞단에서 모든 API서버들의 엔드포인트를 단일화 해주는 또 다른 서버
    • https://tommypagy.tistory.com/143
  • S3
    • Simple Storage Service
    • 주로 파일서버의 역할을 함
    • 사용자 과다로 트래픽이 늘어나도 시스템적인 작업 안해도 됨
    • 저장 파일 제한 없음
    • REST, SOAP 인터페이스 제공
    • 데이터 중복저장으로(이중화) 데이터 손실시 자동 복원
    • 버전관리
    • 보호수준 차등 선택가능 - 비용 절감
    • https://opentutorials.org/course/608/3006
  • DynamoDB
    • NoSQL < - > RDBMS
    • MongoDB와 같은...
    • ACID에 대응
    • 일관성 데이터즉시반영 포기 , 확장성을 특징
    • RDBMS의 경우에는 띄우는 순간부터 비용이지만 DynamoDB는 거의 안나옴(용도에 따라)
    • 키워드에 DB가 붙어있긴 하지만 세일즈포인트가 아닐까?
    • 도큐먼트 엔진같은 느낌 JSON처럼
    • 쿼리가 없음
  • ECS
    • Elastic Container Service
    • 컨테이너를 적절하게 분배 확장 축소하는 서비스
    • 멘토링에서 할 데이터가 하루 70~80mb가량이 들어오는데 람다에서는 처리시간이 10초가 넘기면 메모리를 늘린다고 해도 죽어버리고 맘...
    • 그렇다고 EC2를 사용하기엔 하루 15분 가량을 사용하는데 너무 리소스가 아까움
    • 이를 스케쥴링 해서 필요한 시간만 사용, 과금을 낮춤
    • 너무 사이즈가 커지면 컨테이너를 늘려서 병렬처리 하고자 함

Deploy

  •  GitLab
    • 비공개된 GitHub?
    • 트렐로와 같은 협업툴처럼 협업 기능을 적극적으로 사용해서 GitHub + 트렐로의 느낌
    • 버전관리, 원격저장, issue tracker 지원
    •  
  • Zappa
    • Serverless를 구출을 가능하게 해주는 Python Pakage
    • 자원을 분산 -> 함수는 함수대로 DB는 DB대로 나누어 연동
    • AWS APIGateway Path 추가 작업 안해도 되서(자동으로 해줌) 귀찮음 해소
    • 명령어 한줄로도 배포 가능!
    • 비용 저렴
    • Zappa를 사용하면 람다에는 덜 신경 써도 됨

 

이렇게 아주.. 간단하게 정리해보았는데

정리하면서도 아직 많이 부족함을 느꼈고 , 해당 부분을 공부하면서 더 채워 넣어야 할 것 같다.

기술스택 정리하면서도 마음이 웅장해진다... (긍정적의미로...)

 

'Data Engineering with 멘토링' 카테고리의 다른 글

Data Engineering 멘토링 1 - 멘토링 계획 및 개요  (0) 2021.07.10

+ Recent posts

티스토리툴바