1차 아키텍처(1st Sprint)

1. 구조의 특성
   1. 우리의 프로젝트는 전형적인 대규모 Data Pipeline Architecture를 지닌다.
      1. 더 단순한 아키텍처를 사용, 개발 공수를 줄일 수도 있었지만 적어도 100 팀 이상을 끌어들일 목적으로 한 우리 서비스의 목표 상, data gravity를 피하기 위해 처음부터 아키텍처를 크게 잡았다.
      2. 조병욱 멘토님의 말씀을 인용하자면, 얼마든지 구조를 바꿀 수 있는 일반적인 데이터 처리 흐름과 달리, 다양한 도메인의 데이터를 모으고, 처리해주는 Product의 경우 BM에 따라(Public Web에 배포하여 서비스를 제공할 것인지 / 각 회사에 프로그램을 제공하여 각자 사용하게 할 것인지 등 ) 처리할 수 있는 용량이 다른 아키텍처를 사용하는 것이 맞고, Public에 올릴 경우 현재의 Over Engineering으로 보일 수 있는 Architecturesm는 과부화가 자주 발생할 수 있는 우리 서비스에 적합할 것이다.
   2. 수많은 채널에서 들어오는 Events에 대한 정보를 Webhook으로 받아야하며. 대용량으로 들어오는 raw한 데이터들을 유의미한 데이터로 변환할 수 있기 위해서는 여러가지 Challenge가 존재한다. 이를 하나하나의 Task로 나눠 해결 방법을 나열하는 방식으로 진행하겠다.
   3. 이 구조는 1차 Skeletone Architecture에 쓰인 방식이며, Pros/Cons 에 대해 설명한 이후 다음 포스팅에서 달라진 Architecture에 대해 설명할 수 있도록 하겠다.
2. Webhook들 (Raw Data Collection / Integration)
   1. 우리는 팀 개발 상황에 대한 정보를 얻는 방식을 Webhook으로 정했다.
   2. 정보의 Domain은 Github, Jira, Github Action이 될 예정이며, 이 채널들에서 동시다발적으로 들어오는 데이터들과 통신을 처리하기 위해서는 Serverless를 사용하기로 했다.
   3. 또한, 이러한 데이터가 나올 때 마다 Storage에 넣어줄 수는 없다. 실시간성이 그렇게까지 중요하지 않은 서비스이기도 하거니와 데이터가 들어올 때 마다 연산을 처리해야한다면 쓸데없는 transaction이 기하급수적으로 증가하고 말 것이다.
   4. 그렇기 때문에, 우리는 이러한 데이터를 모아준 이후 주기적으로 처리할 수 있는 Batch 형식의 Infra 요소를 사용하여 데이터 Collection/Integrition을 실행하기로 하였다.

내가 했다! 내가 했다!

1. Multi Cloud Azure(Microsoft) + GCP(Google) 에 대한 이야기(Data Transforming / Store)
   1. 사실… 데이터를 분석해주는 서비스는 Azure에도 Synapse Analistic이라는 상품이 존재한다.
   2. 하지만 이번 azure 사용을 하면서 알게 된 것인데, azure는 정말 불친절하다. docs의 영문판도 부족한데, 번역마저 허술해서 그냥 구글 번역기를 돌린 수준이다. Biceps가 이두박근이라고 써져있다니.(이걸 이야기하니 MS 소속 멘토님께서 너무 재미있어 하셨다.)
   3. 뭐 그것도 그렇고… 가장 쉽게 사용할 수 있는 Google BigQuery를 일단 사용하기로 했다. 우리의 아키텍처가 맞는지부터 확인하는 것이 우선 이었기 때문이다.
   4. 그래서 Azure Blob → Azure Function → GCP Storage → GCP BigQuery로 가는 미친 데이터의 흐름이 완성되었는데, 이것에 대한 이야기이다.
   5. 위에 사진에 보면 알다시피, 돌아다니는 데이터들은 Raw하다. 기껏 해놓은 것은 Raw Data(<25MB) 를 Event Hub(<64KB) 로 넣기 위해 필요한 정보만 추려 축소 시켜놓은 정도?
   6. 그렇기 때문에 추가적인 데이터를 가져오기 위해 중간에 있는 Azure Function에서 Parsing 및 추가적인 데이터 작업을 해주게 된다.(Github PR Open Event에 있는 commits_url을 가지고 commit들의 데이터를 가져온다거나…)
   7. 이를 GCP Storage에 넣어 GCP BigQuery로 분석을 진행해주게 되는데, 이 또한 힘든 일이라고 한다.(사실 여기서 부터는 내 일이 아니라서 자세한 설명이 불가능 하겠다.)
      1. Storage → BigQuery(데이터 복사) → 분석 → BigQuery(분석 데이터 저장) 순으로 진행되는 것으로 알고 있다.
2. 새로 알게 된 사실들
   1. Azure Cloud
      1. azure cloud는 세계 2위의 cloud service로 서비스 요금이 꽤 저렴한 편이다.
      2. 그럼에도 불구하고 docs가 좀 불친절하며 레퍼런스가 부족해서 cloud를 처음 사용하는 사용자는 위험에 빠질 가능성이 꽤 있다.
      3. 그래도 뭐… 경험하기 좋다.
   2. Cloud Events Project
      1. 다양한 특성을 지닌 Events들을 일반적인 데이터로 변환하여 사용하자! 라는 목표를 가진 프로젝트이다.
      2. 우리는 이 프로젝트에서 파생된 Azure 상품 중 하나인 Event Hub를 사용하여 Batch 작업을 진행한다.
      3. Serverless Architecture에 특화되어 있으며, Kafka 등을 이용한 Pub/Sub 이라던가 Message Queue, Batch 작업등을 다양한 SDK를 통해 실행할 수 있기 때문에 우리 프로젝트에서 중심이 되는 인프라 요소 중 하나가 되었다.
   3. Multi Cloud && Hybrid Cloud
      1. Hybrid Cloud는 Multi Cloud의 하위 개념이다.
      2. 뭐 둘을 혼동할 수도 있지만 Hybrid Cloud는 현재 우리의 아키텍처처럼 GCP나 Azure가 빠질 경우 동작하지 않는다.
      3. 하지만 Multi Cloud는 다르다. GCP가 없어지더라도 동작할 수 있다.
      4. 대충 이런 개념이다.
   4. 데이터 정규화의 필요성 (Canonical Form)
      1. 이번 스프린트에서 Github 데이터를 처리함에 있어 문제를 많이 겪었는데 바로 데이터 정규화에 대한 문제이다.
      2. 아직까진 문제 없이 동작하는 모든 데이터명은 jira/github action 등이 들어올 때 컬럼명이 이것저것 생기며 망가질 것이다.
      3. 이것을 막기 위해 정규화가 필요한 것인데 이것에 대한 고민을 다시 하고 포스팅할 예정에 있다.
3. 앞으로 해야할 일
   1. 1차 canonical format 확정
   2. JIRA, GItHub Action의 데이터 가져오기
   3. 안정적인 데이터 Infra를 위한 scaling에 대한 고민
   4. GCP를 Azure로 다시 가져오자. 비용이 많이 드는 불필요한 방식인듯 하다.

고민을 많이 하긴 한다.