12 Factor App과 나의 의견

TIP

구 블로그에 남겨둔 기록을 옮겨왔다.

The Twelve-Factor App (한국어) (opens new window)

너무 이상적인 부분도 존재해서 난 동의하지 못하는 부분도 있다.

3. 환경 같은 경우는 os env로 설정하는 일이 쉽지 않다. 특히 간단하고 빠르게 구성하는 환경에서는.

heroku같은 곳이야 자체적으로 env를 제공하지만, 자체 서버 운영 같은경우는 어쩔 수 없이 .env같은 파일로 관리하는게 현실적이다. 권장사항 정도로 받아들이자.

나만의 법칙

• .env.sample 샘플 환경변수를 관리하자.
• 환경파일은 env.ENV=[heroku, cafe24.linux, aws.ec2.linux] 1개만 정의하여, 파일에서 로드할지 말지 결정하자.
• main의 처음에 바로 env 패키지를 사용해서 환경변수를 로드. 명시적 구조체로 로드해서 사용하자.
• ui, api등 인터페이스는 필수적인 입력 검증과 간단한 로직만 수행하며, 복잡한 로직은 service로 분리.
• 재사용 가능한 부분은 library로 분리.
• libaray는 호출만 가능한 수동적 모듈.
• 자체적으로 동작이 필요한 능동적 모듈은 active-service로 분리하자.
• active-service는 start, status, stop 인터페이스가 필요하다.
• 외부 시스템들은 래핑하여 passive-service로 분류.
• service는 동작이 불가해도 일단 프로세스 기동은 가능해야 하며, 사용시에 에러를 핸들링 하자.
• 여러 환경에서 구동 가능하도록 실제 앱 객체와 main을 분리한다.
• ORM은 사용하지 않는다.
• db를 사용할 때는 model로 분류하여 다룬다.
• model에서는 실제 db driver와 인터페이스하여 원하는 결과만 외부 인터페이스로 노출한다.
• db역시 service이며 model이 service.database를 사용한다.
• 로컬 개발중 service 연결이 어려울 때는, 가상의 모듈을 구현하여 대체한다.
• fake service를 구현하고, 앱 기동때 fake를 연결한다.
• db같은 경우는, fake database 구현이 복잡하면, model을 로컬용으로 별도 구현?
• 프로세스 외부에서 프로세스에 중단 신호를 보내서 graceful shutdown이 가능하게 한다.
• 로그는 환경에 따라 다르지만, stdout이나 파일로 출력 가능하게 한다.
• 파일 로그는 롤링이 가능해야 하며, 에이징을 위한 service를 구현한다.