[MSA] 12-Factors App? +3

클라우드 네이티브 애플리케이션을 구축함에 있어 고려해 봐야 할 12 가지 항목에 대해 알아 보았다. 

 

12 팩터스는 클라우드 서비스 중 플랫폼 애저 서비스 즉 파스라라는 형태의 서비스 형태를 제공하는 Heroku 라는 플랫폼에서 제시한 12가지 항목으로서 클라우드 네이티브 애플리케이션을 개발하거나 서비스를 운영할 때 고려해야 될 항목을 정리한 것이다. 

 

1. 코드베이스 (Codebase)

• 설명: 애플리케이션은 반드시 단일 코드베이스를 가져야 하며, 버전 관리 시스템(Git 등)을 사용하여 관리해야 한다.
• 핵심 내용:
  • 여러 애플리케이션은 서로 다른 코드베이스를 사용한다.
  • 동일한 코드베이스가 여러 배포 환경(개발, 테스트, 운영)에서 사용될 수 있다.

 

자체 레파지토리에 저장된 각 마이크로 서비스에 대한 단일 코드베이스를 뜻한다. 버전을 제어하기 위한 목적이고 형상관리를 위해서 코드를 한곳에서 배포를 하는 것이 주 목적이다. 

 

코드의 통일적인 관리를 위해 가장 중요한 항목이다. 

---

2. 종속성 (Dependencies)

• 설명: 모든 외부 라이브러리나 의존성은 명시적으로 선언하고, 시스템에 내장된 종속성에 의존해서는 안 된다.
• 핵심 내용:
  • Node.js에서는 package.json, Python에서는 requirements.txt와 같은 파일에 명시한다.
  • 의존성은 애플리케이션과 격리된 환경(예: 가상환경)에서 관리한다.

 

각 마이크로 서비스는 자체 종속성을 가지고 패키지 되어 있어서 전체 시스템에 영향을 주지 않은 상태에서 변경되고 내용을 수정할 수 있어야 한다는 뜻이다. 

---

3. 설정 (Config)

• 설명: 애플리케이션 설정은 코드베이스에 포함하지 않고, 환경변수를 통해 관리한다.
• 핵심 내용:
  • 데이터베이스 URL, API 키 등 환경별로 달라지는 값은 코드에 하드코딩하지 않는다.
  • 환경변수를 사용하여 배포 환경마다 다른 설정을 적용한다.

---

4. 백엔드 서비스 (Linkable Backing Services)

• 설명: 데이터베이스, 메시지 큐, 캐시와 같은 백엔드 서비스는 독립적인 리소스로 취급하고, URL 등을 통해 연결한다.
• 핵심 내용:
  • 로컬과 원격 서비스 간의 차이를 최소화하여 쉽게 교체할 수 있도록 설계한다.
  • 예를 들어, 개발 환경에서는 로컬 MySQL, 운영 환경에서는 클라우드 RDS를 사용하더라도 동일하게 작동해야 한다.

---

5. 빌드, 릴리스, 실행 (Build, Release, Run)

• 설명: 애플리케이션의 빌드(코드 컴파일), 릴리스(구성 결합), 실행(코드 실행)을 엄격히 분리해야 한다.
• 핵심 내용:
  • 빌드 단계: 코드에서 실행 가능한 파일 생성.
  • 릴리스 단계: 빌드와 설정을 조합하여 배포 가능한 패키지 생성.
  • 실행 단계: 생성된 패키지를 실행하여 애플리케이션 동작.

 

필요한 이 상태에 대해서 처음에 개발 서버에서 만들어진 이 코드를 나중에 배포를 하기 위해서 실행 단계까지 옮기는 이 과정을 엄격하게 분리를 해야 될 것이다. 각각은 고유한 아이디로 태그를 가지고 있어야 되고 이전 상태로 돌아가는 롤백 기능을 지원해야 되며 CI/CD 시스템을 완벽하게 이용을 해서 자동화된 시스템을 구축하는 것이 좋다. 

---

6. 프로세스 (Processes)

• 설명: 애플리케이션은 독립된 실행 프로세스들로 구성된다.
• 핵심 내용:
  • 각 프로세스는 상태가 없는(stateless) 방식으로 설계해야 한다.
  • 프로세스 간 데이터는 공유되지 않고, 외부 저장소(데이터베이스, 캐시)를 통해 공유한다.

필요한 자원이 있다고 하면 캐시라던가 데이터 저장소와 같은 형태를 이용해서 외부와 데이터 교환을 하면서 데이터 동기화를 해야한다.  

---

7. 포트 바인딩 (Port Binding)

• 설명: 애플리케이션은 자체적으로 포트를 바인딩하여 외부와 통신해야 한다.
• 핵심 내용:
  • HTTP 서버를 내장하고, 플랫폼이 제공하는 포트로 요청을 처리한다.
  • 예를 들어, Flask는 WSGI 서버를 통해 실행되며 지정된 포트를 바인딩한다.

---

8. 동시성 (Concurrency)

• 설명: 프로세스를 확장하여 동시성을 처리한다.
• 핵심 내용:
  • 작업 유형별로 프로세스를 분리하고 병렬 처리 가능하도록 설계한다.
  • 프로세스 매니저(Foreman, Kubernetes 등)를 활용하여 수평적 확장을 지원한다.

동일한 서비스가 여러 pc, 여러 인스턴스 나눠서 서비스가 되고 있기 때문에 동시성을 가져야 한다. 

---

 

9. 폐기 가능성 (Disposability)

• 설명: 프로세스는 빠르게 시작되고, 종료될 때도 안전하게 처리되도록 설계한다.
• 핵심 내용:
  • 애플리케이션은 종료 신호(Signal)를 받을 때 현재 작업을 정상적으로 정리(clean up)한다.
  • 배포, 확장, 장애 복구에 적합한 구조를 제공한다.

---

10. 개발/운영 환경 일치 (Dev/Prod Parity)

• 설명: 개발, 테스트, 운영 환경 간의 차이를 최소화해야 한다.
• 핵심 내용:
  • 개발자는 운영 환경과 동일한 도구를 사용해야 한다.
  • 환경 차이로 인한 버그를 줄이기 위해 컨테이너(Docker)와 같은 기술을 사용한다.

운영 프로그램의 수명 주기 전반에 걸쳐서 최대한으로 많은 서비스를 직접 액세스하는 기능을 방지해서 환경 자체를 최대한 다른 쪽에 있는 작업과 중복되지 않고 다른 쪽의 작업과 종속적이지 않은 상태로서 서비스를 유지할 수 있어야 한다. 

---

11. 로그 (Logs)

• 설명: 애플리케이션은 로그를 표준 출력(stdout)으로 기록하고, 로그 관리 도구에서 이를 수집하여 분석한다.
• 핵심 내용:
  • 로그 파일을 직접 생성하거나 관리하지 않는다.
  • 로그는 상태를 유지하지 않는 스트림으로 취급한다.
  • 로그 분석을 위해 Splunk, ELK Stack 같은 도구를 사용한다.

즉 하나의 시스템 안에서 구성되고 있는 로그를 출력하는 로직은 기존에 있었던 애플리케이션 로직과 분리가 돼서 애플리케이션 자체가 실행되지 않는 상태라 하더라도 로그만은 정상적으로 작동할 수 있어야 한다. 

---

12. 관리 프로세스 (Admin Processes)

• 설명: 일회성 관리 작업(예: 데이터베이스 마이그레이션)은 독립적으로 실행해야 한다.
• 핵심 내용:
  • 관리 작업은 동일한 환경에서 실행해야 한다.
  • 애플리케이션과 동일한 코드베이스, 설정, 환경을 사용하여 실행한다.

---

 

13(2). API- first 

 

• 설명 : 모든 마이크로 서비스에대해서는 API 형태로 한 서비스가 제공이 될텐데 API 구축함에 있어서 사용자 측에서 어떤 형태로 쓸 것인가를 먼저 고민해서 개발해야 된다는 것이다. 

 

14. Telemetry

 

• 설명: 이전 말했던 개발 관리 항목과 유사한 항목이지만 모든 지표는 수치화되서 시각화되어 관리할 수 있는 항목이어야 한다.

 

15. Authentication and authorization

 

• 설명: API를 사용함에 있어서 인증 작업은 필수일텐데 마이크로 서비스간에 분리되어 있는 형태로 개발이 된다 하더라도 우리가  구현하고 있는 마이크로 서비스는 적절한 인증을 가지고 있는 리소스, 인증을 가지고 있는 서비스라던가 외부 시스템에서는 데이터를 전달하고 교환하는 작업이 가능해져야 된다는 얘기다.