7월의 프로젝트 (직군 배분 완료)

최근 프로젝트를 하면서 직군을 나누었고 해당 해야하는 일 또한 배정하였습니다.

그러면서 저는 프로젝트에 있어서 데이터베이스 인프라와 로그 파이프라인을 담당하기로 정했습니다.
또한 지금은 사용자도 없고 로그도 없는데 어떻게 해야하고
사용자가 어느정도 있다는것을 가정하고 해야하는것일까?

로그 파이프라인의 고민

로그를 전달하고 지나갈 파이프라인을 정하면서 서비스모듈을 선정하는것 또한 매우 고민이 많았습니다.
이런 고민들중에 제가 중요하게 생각한것들은 아래와 같습니다.

1. 얼마나 로그가 유실없이 적재가 가능할까
2. 로그 데이터에대한 안정성은 얼마나 있는가
3. 만약 사용자가 많아 확장을 해야한다면 어떻게 할것인가

이러한 고민들중 최종 후보 2가지의 파이프라인이 정해졌습니다.

1. ELK 스택
2. Logstash -> Kafka -> BigQuery

둘중 저는 2번을 선택해서 사용하기로 했습니다.

---

Logstash -> Kafka -> BigQuery 선택한 이유

ELK를 사용하여 실시간으로 로그데이터를 색인하고 시각화하는 것도 매우 장점이 많지만
로그의 유실이 없고, 분산 처리가 가능한 2번을 선택하였습니다

Logstash

django에서 나오는 로그를 파일로 저장을 하고있고 장기적으로 로그파일을 적재해야하기때문에
파일은 생성되면서 로그를 처리할수 없을까 고민중 logstash가 있었습니다.
logstash는 ELK에서도 들어가서 공부를 조금 한 상태이기도 하고 미들웨어로서 좋은 장점들이 많았습니다.

1. 다양한 input과 output의 플러그인
2. 유연한 Filters

이러한 장점들을 통해서 프로젝트 중간에 서비스모듈이 바뀌거나 보낼 서비스 모듈이 많아진다면 대처가 가능하기 때문입니다.

Kafka

저는 선정하는 과정중 데이터가 유실이 없는것이 가장 중요하다고 생각했습니다.
그러면서 데이터에대한 처리도 빠르고 분산으로 처리하기때문에 안전한 Kafka를 선택하게 되었고

kafka는 고가용성 측면에서 클러스터를 구성하여 하나가 고장이나도 다른 카프카가 지속적으로 사용이 가능하며
큐의 역할 즉 데이터를 저장하는 버퍼의 역할도 수행가능하기때문입니다.

bigquery대신 다른 데이터베이스를 쓰거나 또다른 컨슈머가 생기게 되면
아직 소비되지 않은 메세지부터 전달이 가능하거나 처음부터 전달이 가능하다는 장점또한 매우 좋았습니다.

BigQuery

데이터베이스 인프라를 구성하는 단계에서 서버의 부하나 그걸로 인해 웹서버가 영향을 받아 성능이 저하가 없는것을 목표로 하였고 그러면서 분석환경을 구성하고 분석전용 데이터베이스가 있어야 겠다고 생각했습니다.

그러면서 저희 팀은 bigQuery를 분석데이터베이스 즉 데이터마트로 활용하기로 했습니다.

그러면 만약 트래픽이 발생했을경우 대응하는 방법으로 구글 클라우드 플랫폼을 사용하여 대응할수 있겠다는 생각이 들었습니다.