[Application / DevOps] The Twelve-Factor App이란??? / 어플리케이션 아키텍쳐의 베스트 프랙티스 방법론

안녕하세요. 이번 포스팅에서는 Web Application에 대한 베스트 프랙티스를 모든 웹 문서인 The Twelve-Factor App 에 대해서 포스팅을 작성해보도록 하겠습니다.

 

---

 

0. DevOps를 위한 아키텍처?

DevOps는 여러 의미로 해석될 수 있지만 IT의 개발과 운영이 조화롭게 병행되는 형태를 말합니다.

이러한 DevOps를 위한 아키텍처, DevOps를 위한 인프라에 대해서 생각하게 되면 전제가 되는 어플리케이션 아키텍쳐 자체를 같이 생각하지 않으면 DevOps 운용의 본질적인 문제 해결이 되지 않습니다.

어플리케이션과 인프라는 동행해야 하고, 서로 밀접하게 관계되어 상호 간 결합하는 듯한 구성을 취할 필요가 있습니다.

이러한 DevOps의 전제가 되는 어플리케이션 아키텍처를 알아보도록 하겠습니다.

 

 

 

---

 

1. The Twelve-Factor App

DevOps를 위한 어플리케이션을 개발할 때, 어느 정도 베스트 프랙티스(Best-Practice)를 도입하면서 안티패턴(Anti-Pattern)을 피해야 합니다.

 

The Twelve-Factor App은 Web 어플리케이션에 대한 베스트 프랙티스들을 모아 놓은 웹문서로써 Heroku(www.heroku.com) 멤버들에 의해서 기재됬습니다.

 

우선 최신의 Web App은 기본적으로 아래 사항들을 이야기합니다.

 

-선언적인 Format으로 Setup 과정이 자동화
-Scale Up/Scale Out이 큰 변경없이 가능
-개발, 운영 환경에 종속되지 않고 지속적인 Deploy가 가능
-어플리케이션에 환경 간의 이식성이 있고 이것을 클라우드 환경에서 Deploy가 가능하다.

이러한 Web App인 The Twelve-Factor App은 12개의 방법론에 기반합니다.

 

1. 의존 관계: 모든 라이브러리 의존성을 Manifest(의존 관계 선언 파일)에 기술하고 특정 시스템이나 라이브러리에 의존하지 않도록 작성합니다.
2. 설정
   : 코드 설정에 리소스, 환경 정보등을 하드코딩하지 않고 이를 환경 변수에 저장합니다.
3. Code Base
   : 운영 환경 또는 테스트 환경의 여부에 관계없이 하나의 코드에서 Release가 가능한 상태가 되도록 합니다.
4. Back-end 서비스
   : Back-end 서비스는 네트워크를 통해 이용하는 모든 서비스를 말합니다. 메세지 큐, 캐시 등에 대해 로컬 서비스와 클라우드 서비스를 구분하지 않고, 어플리케이션의 변경없이 전환이 가능해야 합니다.
5. Build, Release, 실행
   : 코드를 Release 하기까지의 단계는 Build / Release / Run 으로 Stage들이 나눠집니다. Build stage에서는 의존 관계를 해소하여 로컬에서 Build 하고, Release Stage에서는 Build 된 것에 각 환경이 갖고 있는 설정을 결합하며, Run Stage에서는 선택한 Resource에서 프로세스를 기동합니다.
6. 프로세스
   : 프로세스는 Stateless 하게 설계하며, 상태 정보가 필요할 때는 Back-End 서비스에서 갖도록 합니다. 세션은 데이터 스토어에 저장하고 Sticky 세션등에 의존하지 않습니다.
7. Port Binding
   : 어플리케이션에서 독자적으로 수행하도록 설계하며 Apache나 Tomcat을 사용하지 않고 어플리케이션이 직접 포트에 바인딩하여 HTTP 서비스로 공개합니다.
8. 병행성
   : 서비스 데몬을 실행하는 UNIX 프로세스 모델을 사용하여 개별 워크 로드 유형을 프로세스 타입에 할당함으로써, 개발자는 어플리케이션이 다양한 워크로드를 처리할 수 있도록 설계합니다.
9. 개발/운영 환경 일치
   : 지속적인 배포가 가능하도록 개발 환경, 검증 환경, 운영 환경을 최대한 일치시킨 상태를 유지하도록 설계합니다.
10. 로그
    : 로그 파일에 기록하여 관리하지 않고 출력 스트림의 발송 대상 및 스토리지에 대하여 관여하지 않도록 설계합니다.
11. 관리 프로세스
    : DB 마이그레이션, 레코드 수정, 검사용 명령어 등 관리 프로세스는 일회성 프로세스로 수행될 수 있도록 하고, 관리용 코드는 일반 어플리케이션과 동일한 저장소에서 관리하고 Deploy 합니다.
12. 폐기 용이
    : 기동 시간을 최소화하고 즉시 기동,종료할 수 있도록하여 SIRTERM 시그널을 받으면 정상적인 종료 과정으로 동작할 수 있도록 설계합니다.

 

이 The Twelve-Factor App 방법론을 사용함으로써 Web 베스트 프랙티스를 실천하는 것이 가능하고 이는 간소화 및 자동화가 더욱 뛰어난 어플리케이션의 구축을 가능하게 합니다.

 

---

 

본 포스팅의 내용 및 이미지를 무단 전재, 재배포 또는 복사를 금지합니다.

인용 시 출처와 같이 공개해주세요!

도움이 되셨다면 댓글 또는 공감 부탁드립니다!