고라니 블로그

Monolithic?

모든 것을 하나의 바구니에 담는다.

- 리스크 따위 신경쓰지 않는 상남자가

모든 logic(인증, 결제 등등)이 하나의 application 으로 묶여 단일 database를 공유하는 전통적인 구조

MSA (Microservice Architecture)?

각자의 역할에 맞춰 철저히 쪼갠다

- 모든 걸 신경써야하는 완벽주의 결벽증 환자가

각각의 business 역할에 따라 application을 나누어 각자 독립된 database를 가진 service로 동작하는 구조

Monolithic의 한계!

monolithic의 구조는 잘못된 것이 아니다!

다만 service의 규모가 거대해져 traffic이 발생했을 때 그에 대응하지 못하는 한계가 있다!

확장에서의 비효율

service를 운영하다보면 event 기간이 있을 수 있는데, 이 때 ‘결제’ traffic이 평소의 10배로 늘어났다고 가정해보자

• Monolithic
  → 모든 기능이 포함된 전체 application server를 10대로 복사해야 함 (Scale-out)

• MSA
  → 결제 service의 server만 10대로 복사, 그 외 나머지 service는 평소대로 유지
  이렇게 traffic이 늘어난 service에만 정확하게 자원을 투자하여 비효율성을 낮추는 것이 가능하다!

Build / 배포의 두려움

UI에 사소한 오타가 발생하여 이를 고치는 상황을 가정해보자

• Monolithic
  → UI 외에도 모든 logic이 담긴 code를 모두 다시 build하고 test한 뒤 전체 service를 멈추고 재배포해야 함

• MSA
  → UI 만 수정하여 UI 만 배포하는 것이 가능

장애의 연쇄

‘image upload’ 기능의 logic에 개발자의 실수로 무한 loop가 발생한 상황을 가정해보자

• Monolithic
  → 이 bug로 인해 server의 memory가 가득차 server 전체가 down 되어 모든 service가 동시에 마비 (장애 전파)

• MSA
  → ‘image upload’를 담당하는 service만 마비되고 다른 인증, 결제 등의 service들은 정상적으로 동작 (장애의 격리)

기술 Stack 의 종속

AI 기능이 필요해진 상황, python의 도입이 필요해졌다고 가정해보자

• Monolithic
  → 기존에 사용하던 언어가 python이 아니라면 도입할 수 가 없음!

• MSA
  → 기존의 service들과 상관없이 python을 사용하는 독립적인 service를 구현하는 것으로 도입이 가능!

MSA는 만능인가?

Monolithic의 한계에 부딪혀 나타난 MSA가 만능인가에 대한 얘기를 해보자

Database 분리로 인한 transaction 정합성 붕괴

고객이 결제를 통해 제품을 가져가는 상황에서 [결제 내역 저장], [상품 재고 감소] 두가지의 일이 동시에 일어난다!

• Monolithic
  → Database가 단일 구성이기에 결제중에 error가 발생하면 db의 transaction rollback 기능을 통해 안전하게 원상태로 복구하는 것이 가능

• MSA
  → 결제 database와 재고 database가 분리되어 있기 때문에 결제는 성공했는데 재고 server에 재고 감소를 위해 api를 호출하는 순간 network가 끊긴다면 db의 rollback 기능만으로 결제 database를 원상태로 복구하는 것이 불가능 (개발자가 직접 결제 취소 API를 호출하는 등의 logic이 추가적으로 필요)

Infra의 복잡도와 비용의 증가

Database를 설치하고 자동 배포(CI/CD) 환경을 구축하여 운영을 위한 준비를 하는 상황이라면?

• Monolithic
  → 하나의 RDBMS와 하나의 배포 pipeline만 관리하면 끝!

• MSA
  → 각 service마다 DB, 배포 pipeline을 관리하기 위한 docker, kubernetes 와 같은 infra 도구를 도입해야 함

분산되어 있지만 결합된 구조

사용자 정보를 관리하는 service에서 사용자 정보 format을 수정하는 상황 (ex. userId → user_id 변경)

• Monolithic
  → 수정하여 재배포하면 끝!

• MSA
  → 주문 service에서 사용자 정보를 사용하기에 format이 수정되면 주문 service도 수정되어야 함. MSA에서 중요한 ‘독립된 배포’가 불가능해지고 기능간 네트워크 지연 시간만 추가된 monolithic 구조와 다를 바 없어지게 되는 상황이 생김

오랜만의 포스팅이네요.

이전에 NVM을 CentOS에 설치하는 방법을 포스팅한 글에서 NVM에 대한 설명을 대충 해두었으니 아래 링크에서 확인해보시고, 본 글에서는 macOS에서의 설치 방법과 간단한 사용법을 적어볼까 합니다.

NVM (Node Version Manager)을 이용한 NodeJS 설치 (in CentOS)

NVM 설치

💡 시작 전에 homebrew가 설치되어 있지 않은 경우 아래의 링크를 참고하여 설치하고 진행해주세요.
Mac OS 에 Homebrew 설치하기

1. nvm 설치

   > brew install nvm

2. 설치 확인→ 버전이 출력되지 않는다면 환경변수 설정을 해보자

   # 폴더 생성
   > mkdir ~/.nvm
   
   # 환경변수 설정
   > vi ~/.zshrc
   
   ...
   # NVM
   export NVM_DIR="$HOME/.nvm"
    [ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && . "/opt/homebrew/opt/nvm/nvm.sh"
   # This loads nvm
    [ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && . "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"
   # This loads nvm bash_completion
   ...
   
   # 만약 안된다면 terminal을 종료후 다시 시도
   > nvm -v
   0.40.0

Node version 관리

• node 설치

  > nvm install $version
  
  # ex
  > nvm install v16.16.0

• 설치된 node 확인

  > nvm list
  -> v16.16.0 
  default -> v16.16.0 
  iojs -> N/A (default) 
  unstable -> N/A (default) 
  node -> stable (-> v16.16.0) (default) 
  stable -> 16.16 (-> v16.16.0) (default) 
  lts/* -> lts/iron (-> N/A) 
  lts/argon -> v4.9.1 (-> N/A) 
  lts/boron -> v6.17.1 (-> N/A)
  lts/carbon -> v8.17.0 (-> N/A)
  lts/dubnium -> v10.24.1 (-> N/A)
  lts/erbium -> v12.22.12 (-> N/A)
  lts/fermium -> v14.21.3 (-> N/A)
  lts/gallium -> v16.20.2 (-> N/A)
  lts/hydrogen -> v18.20.4 (-> N/A)
  lts/iron -> v20.17.0 (-> N/A)

• 사용할 node version 변경

  > nvm use $version
  
  # ex
  > nvm use v16.16.0
  Now using node v16.16.0 (npm v8.11.0)

• node 삭제

  > nvm uninstall $version
  
  # ex - 사용중인 version은 삭제 불가
  > nvm uninstall v16.16.0
  nvm: Cannot uninstall currently-active node version, v16.16.0 (inferred from v16.16.0).

애플리케이션 추가하기

1. 카카오 계정으로 로그인을 하고 내 애플리케이션 메뉴로 들어갑니다.

2. `애플리케이션 추가하기` 버튼을 클릭하면 아래와 같은 화면이 나타납니다.
    필요한 정보를 입력하고 `저장` 버튼을 눌러줍니다.

3. 추가한 애플리케이션을 클릭합니다.

4. 아래와 같이 `요약 정보`가 나오면 완료입니다.

Client Secret 코드 발급

REST API를 사용할 경우 Client Secret 코드를 생성하여 보안을 강화할 수 있습니다.
아래의 절차를 따라 코드를 생성해 봅니다.

1. `내 애플리케이션` > `제품 설정` > `카카오 로그인` > `보안`
    위의 차례로 메뉴를 들어가면 아래와 같은 화면이 나타납니다.

2. 위 화면에서 코드 생성 버튼을 누르면 아래와 같이 확인 창이 나타납니다.
    `생성`을 눌러줍니다.

3. 그럼 아래와 같이 코드가 발급됩니다.
    `재발급` 버튼을 통해 다시 발급받을 수 있습니다.

4. 활성화 상태에서 `설정`을 눌러 `사용함` 상태로 변경해 주면 완료입니다.

Redirect URI 등록

1. `내 애플리케이션` > `제품 설정` > `카카오 로그인`
    위 메뉴로 들어가서 활성화 설정 상태를 `ON` 으로 변경해 줍니다.

2. 하단에 `Redirect URI` 항목에서 OAuth용 Redirect URI를 설정합니다.