1. MSA 개발 12 Factors

클라우드 네이티브 애플리케이션이 갖추어야 할 12가지 설계 원칙이다.

1. 코드베이스 (Codebase):
   • 버전 관리가 가능한 하나의 코드베이스를 유지하며 이를 통해 개발, 스테이징, 운영 등 여러 환경에 배포
   • 개발/운영 환경마다 code가 동일하게 배포 되어야 한다.
   • 환경마다 코드가 동일하게 배포되지 않으면 운영/디버깅의 지옥
2. 종속성 (Dependencies):
   • 애플리케이션이 시스템 전체 패키지에 암묵적으로 의존하지 않도록 종속성을 명시적으로 선언하고 분리
3. 설정 (Config):
   • 배포 환경마다 달라지는 설정들을 소스 코드와 분리하여 환경 변수에 저장함.
   • k8s를 사용하면 자연스럽게 지켜지는 설계 원칙이다.
4. 백엔드 서비스 (Backing Services):
   • DB, 메시지 큐, 캐시 등을 교체 가능한 리소스로 취급하여 코드 수정 없이 서비스 전환이 가능해야 한다.
   • 컨테이너에다가 하나로 모두 다같이 만들어 놓으면 안되고 백엔드로 아예 뒤쪽으로 빼서 백엔드 부분을 바꿨을 때 원래 pod에 영향이 안 가게 끔 설계해야 한다.
5. 빌드, 릴리즈, 실행:
   • 빌드(번들 변환), 릴리즈(설정 결합), 실행(프로세스 시작) 단계를 철저히 분리하여(독립적) 버전별 추적이 가능하게 함.
6. 무상태 프로세스 (Stateless Processes):
   • 앱은 무상태(Stateless)로 세션/파일/캐시 같은 상태(Stateful)은 외부 저장소로하여 스케일 아웃, 복제, 장애 복구에 편리하게 설계해야 한다.
   • 저장소는 scale out 될 일이 거의 없다.
7. 포트 바인딩 (Port Binding):
   • 앱 자체가 실행 가능한 서비스 단위가 되어 특정 포트를 바인딩하여 서비스를 공개해야 한다.
8. 동시성 (Concurrency):
   • 프로세스 모델을 통해 수평적으로 확장(Scale-out)할 수 있도록 설계하여 작업 부하를 분산
9. 폐기 가능성 (Disposability):
   • 빠른 시작과 안정적인 종료(Graceful shutdown)를 통해 시스템의 회복력과 민첩성을 높여야 한다.
   • 갑작스러운 셧다운에도 문제를 만들지 않고 작업을 큐로 되돌릴 수 있도록 진행
   • 빠르게 부팅되고, 종료 신호에 문제 없이 종료될 수 있도록 설계
10. 환경 일치 (Dev/prod parity):
    • 개발과 운영 환경의 격차를 최소화하여 배포 오류를 방지
    • but 개발 환경과 운영 환경을 동일하게 만들기 어려워 잘 지켜지지 않는다.(돈이 너무 많이 든다.)
11. 로그 (Logs):
    • 로그를 파일로 관리하지 않고 이벤트 스트림으로 취급하여 별도의 수집/분석 시스템이 처리하도록 함.
    • 요즘은 elastic search 보다는 fluentd, 프로메테우스 쪽으로 많이 넘어갔다고 한다.
12. Admin 프로세스:
    • 마이그레이션이나 데이터 정리 같은 관리 작업은 일회성 프로세스로 실행해야 한다는 것

2. CRUD와 MSA의 연계성

MSA 아키텍처에서 조회(Read)와 쓰기(Write)를 분리해야 하는 6가지 이유

1. Read와 Write는 성격의 차이가 있다. 조회는 트래픽이 많아 속도와 확장성이 중요하고, 쓰기는 데이터 정합성과 정확성이 우선임.
2. CRUD를 한 곳에 모으면 서비스가 거대해져 유지보수와 확장이 어려워지는 모놀리식화가 발생하여 여러 가지 장애가 발생할 수 있음.
3. 정책 변화가 잦은 쓰기 로직과 데이터 형태가 고정적인 조회 로직을 분리하여 안정성을 높임.
4. 확장 방식의 차이: 조회는 Scale-out이 쉽지만 쓰기는 트랜잭션 일관성 때문에 확장에 제약이 있어 각각의 특성에 맞는 전략이 필요