Collecting Event Data 0. Entire Pipeline (전체 파이프라인)

 

이제와서 느끼는건데 너무 프로젝트 초반부터 블로그에 글을 쓰면 정말 기록용 정리되지 않은 개발새발 글이 될 수 있는 것 같다. 그런 글도 필요하긴 하지만.. 내 블로그의 정체성이 노트인지 정리용인지 희미해지는 순간

 

Main Purpose

- Collecting users' viewed/clicked event data

- Build a separate server for event data to prevent serveice server overloaded

 

Pipeline

 

- API Server: AWS Elastic Beanstalk (Stage, Production)

- Data Lake: AWS S3 (Tier1, Tier2)

- Data Warehouse: AWS Redshift

- Dashboard: Preset (Managed Apache Superset)

- ETL Tool: AWS Glue job

- Batch Scheduling: AWS Stepfunctions + AWS Eventbridge

- Monitoring/ Alarm: AWS Cloudwatch, Slack

 

Why EB (Elastic Beanstalk) as API server?

- EB가 인프라 구성, 운영, 애플리케이션 스택을 관리해주기 때문에 쉽고 빠르게 웹 서버를 구축할 수 있다.

(EB manages the infrastructure configuration, operation, and application stack so we can build a web server quickly and easily)

- 로드 밸런싱, 오토 스케일링, 모니터링을 한 콘솔에서 할 수 있다.

(Load balancing, auto scaling, and monitoring can be done from one console)

- EB 자체는 무료이고 리소스에 대한 비용만 지불하기 때문에 별도로 구축하는 것과 비용 차이가 나지 않는다.

(Since EB itself is free and we just need to pay only for resources, there is no difference in cost from building all infrastructures separately)

 

 EC2를 사용하면서 모두 별도로 구성하는 것과 비용이 동일하게 나오면서 서버 구축, 관리에 드는 리소스가 줄고, 배포가 간단하다는 장점 - 특히 웹 서버를 자동으로 구축해준다는 점이 가장 큰 장점이었다. 더군다나 자체 서버가 없는 상황이어서 선택지가 EC2, Continer형식(ECS or EKS), EB 세 가지 밖에 없었다.

 ECS나 EKS를 쓰려면 어차피 컴퓨팅 리소스인 EC2나 Fargate를 써야하기 때문에 굳이 선택할 이유가 없었고, 더군다나 이벤트만 받을 서버라 띄울 서버가 Nginx밖에 없어 오케스트레이션이 필요하지 않았다.

 

Easier deployment, management and configuration was the best part of EB for me - especially the part that EB build Nginx web server itself for the same cost as building all the infrastructures separately so I don't need to build Nginx web server neither pay for it (awesome..)

You also can consider ECS or EKS as another option, but I didn't because I only need to deploy Nginx so orchestration wasn't required.

 

Well, just fyr, here are 3 downsides of EB.

- You need to learn how .ebextensions works for detailed configurations (Especially if you want to keep every configures in text)

- Limited runtime languages

- The server may temporary shut down during eb is deployed (You can configure a deployment policy (doc))

 

Plan

- Configure & Deploy EB

- Nginx configures

- Copy Log from EC2 -> S3 Seoul -> S3 Tokyo (Data Lake Tier1)

- Data Lake Tiering

- Glue job: ETL Data Lake Tier1 -> Data Lake Tier2

- EB deployment policy

- Alert to Slack: Server Error 400, 500

- Alert to Slack: S3 Replication Failure