Python(Django) 또는 Js/Ts(Node.js)?

Django

Django는 MVC패턴과 유사한 MVT(Model, View, Template)구조를 기반으로하는 웹 프레임워크입니다.

• Model
  데이터베이스와 연결 및 관리를 담당합니다.
• View
  MVC패턴에서 C(Controller)담당합니다. 비즈니스 로직을 처리하며 Model과 Template사이에서 데이터를 주고 받는 역할을 합니다.
• Template
  MVC패턴에서 View를 담당합니다. 클라이언트에게 보여질 UI등의 처리를 담당합니다.
  

위의 패턴을 기반으로한 동기식 처리 방식을 기본으로 합니다.

Node.js

Node.js는 싱글 스레드의 이벤트 루프기반 비동기식 I/O 처리 모델을 가지고 있는 Javascript Runtime 환경입니다.

• Event Loop
  이벤트가 발생하면 event loop 는 해당 이벤트가 동기 이벤트인지 비동기 이벤트인지 판별 합니다. 동기 이벤트이면 call stack으로 해당 이벤트를 push하며 만약 해당 동기 이벤트가 callback함수를 가지고 있다면 callback 을 event queue에 담습니다. 비동기 이벤트면 O/S kernel 에게 해당 작업을 위임합니다.

• Call Stack
  두가지 이벤트 타입중 동기 작업만 수행합니다. call stack은 event loop에 의해 push된 이벤트를 실질적으로 수행하는 역할을 하며 같은 스레드를 사용하는 event loop는 자동으로 blocked됩니다.

• Event Queue
  event loop가 만나는 이벤트들 중 callback함수를 포함하고 있는 이벤트들이 있는데 이 callback 함수들이 event queue에 들어가게 됩니다. 그리고 처음 이벤트 작업이 call stack에서 완료될 시 event loop는 위 설명처럼 blocked 되어 있다가 event queue의 callback 을 꺼내 다시 call stack 에 넣어줍니다.
  

위의 설명처럼 비동기식 처리 방식을 기본으로 합니다.

그래서 어떤거?

• 개인적으로는 둘 다 적합하다고 생각됩니다만, Linko 서비스 특성 상, 잦은 이벤트를 처리해야할 것이며, 많은 네트워크 요청이 있을 것으로 예상됩니다. 이에 따른 장단점을 생각해본다면

  • Django
    • 웹 프레임워크로써 다양한 기능이 탑재되어 있어 초기 빠른 개발이 용이할 수 있다.
    • 추후 만약 AI관련 기능이 추가된다면 Python으로 개발하는 것이 좋을 수 있다.
    • 하지만 없다면, 비동기 처리 작업이 많을 것으로 예상되는 Linko서비스에는 부적합 할 수 있다.
  • Node.js
    • 기본으로 비동기식 처리 작업을 지원하여 많은 네트워크 요청을 보다 간편하게 처리할 수 있다.
    • 만약 AI기능이 추가된다면, Python보다는 부적합할 수 있다.

아키텍처?

• SaaS - Silo Isolation
  Linko는 사용자에게 딱 필요한 자동화 업무를 제공하는 서비스입니다. 만약 온프레미스 환경을 지원하는 서비스라고 한다면, 만약 지원 가능한 플랫폼이 증가되거나, 버그 수정, 트리거/이벤트 증가 등의 업데이트가 이루어진다면, 매일 소비자는 저희에게 적용을 요청하거나 직접 요청할 것입니다. 이런 것을 방지하여 사용자가 업데이트 적용 필요없이 서비스에 접근해서 자신만의 환경을 구축하여 사용하는 것이 바람직해보입니다.
  또한, Silo(tenant간의 리소스 공유 불가), Pooled(tenant간의 리소스 공유 가능)중, 저희 서비스를 이용하는 사용자 중, 리소스를 많이 사용하는 사용자가 있을 경우, 다른 tenant에게 영향을 끼쳐선 안되므로 Silo Isolation 전략을 채택하여 SaaS를 구축하는 것이 바람직한 것 같습니다.

• MSA
  Linko는 다양한 기능이 있는데, 특히 트리거, 이벤트 처리, 사용자 관리 등의 기능이 필수적으로 구현되어야합니다. 또한 추후에 플루션의 기능 추가, 즉 유지보수가 필수적인 상황에서 Monolithic 아키텍처 기반 개발 환경이라면 매우 난감한 상황이 될 것 같습니다. 그리하여 기능 추가,업데이트 등의 유지보수가 용이한 MSA를 구축하는 것이 좋을 것 같습니다.
• gRPC 통신

인프라?

• 사용할 것으로 예상되는 인프라는 AWS이며, 사용할 서비스로는 다음과 같습니다.
  

  • AWS Lamda
    - 이벤트에 의해 자동으로 트리거되는 환경을 제공합니다. 저희는 여러 엔드포인트를 호출할 것으로 예상되며 이벤트 기반 아키텍처를 사용하는데 용이할 것으로 예상됩니다.

    

  • AWS API Gateway
    - 위 사진처럼 여러개의 엔드포인트 호출이 발생했을 때, API gateway로 요청을 보내게 되고, API Gateway에서 각각의 Microservice로 전달하는 일종의 프록시 역할을 해주는 서비스입니다.

디자인패턴?

여러 디자인 패턴 중, Pub/Sub모델로 알려진 옵저버 패턴이 Linko서비스와 가장 잘 어울린다고 생각되어 옵저버 패턴에 대해서만 설명하겠습니다.

• Observer Pattern

  • Observer Pattern은 Observer(관찰자)들이 관찰하고 있는 Subject(대상자)의 상태가 변화가 있을 때마다 대상자는 직접 목록의 각 관찰자들에게 통지하고, 관찰자들은 알림을 받아 조치를 취하는 패턴입니다.

    즉, Subject(트리거)의 이벤트가 발생하면, Observer들이 해당 이벤트를 수신하여 지정된 액션을 취하는 패턴으로, 이벤트 함수(Subject)가 실행되면, 그에 따른 콜백함수(Observer)가 실행되는 것으로 이해했습니다.

    예를 들어 Naver의 이메일이 도착하면(Subject, trigger) 지정해둔 Slack또는 Discord에 메세지를 보낸다(Observer, action).
    또는, 구독해둔 유튜버의 동영상이 업로드되면(Subject, trigger), 구독자들에게 알림이 간다(Observer, action).

    저희 Linko서비스는 어떤 플랫폼을 기준으로 트리거를 설정해두고, 트리거가 발동된다면 지정해둔 액션을 취하는 서비스이므로 Observer 패턴이 적합하다고 생각합니다.