서비스 환경 변수 정복기

프로젝트 환경 변수 관리에 어려움을 겪고 있어 데브옵스 팀과 함께 환경 변수 정복을 시도한 과정을 기록했습니다.

상황

환경 변수 관리에 어려움을 겪고 있습니다. 동일한 값을 매핑하지만 키가 다른 경우가 있거나 같은 키를 가지지만 값이 다른 경우가 있어서 관리에 차질이 생기고 있습니다.

문제

문제는 두 가지로 정의할 수 있습니다.

문제 1 : 서비스 마다 존재하는 환경 별 구성 파일

새로운 환경 변수가 추가되면 모든 환경에 맞게 구성하는 번거로움이 발생했습니다.

문제 2 : 환경 변수 별 약간의 오차

같은 value지만 key가 다르거나 같은 key지만 value가 다른 케이스가 있어 매핑 과정이 껄끄럽지 못합니다.

원인

원인 또한 두 가지로 정의할 수 있습니다.

• 환경마다 큰 차이가 없지만 따로 관리해 복잡도를 높이고 있다.
• 관리 방법이 달라 환경 변수에 오차가 생기고 있다.

두 가지 원인으로 배포마다 휴먼 에러가 발생해 피로감 누적되고 있습니다. 이번 기회에 데브옵스 팀과 함께 환경 변수 정복해보려 합니다.

해결

원인 해결

문제 해결에 집중해 고민했던 내용을 정리했습니다. 원인을 해결은 동일한 환경 변수를 바라보게 세팅하는 방법으로 충족 가능합니다. 각 서비스는 동일한 템플릿을 구성하고 환경 별 변수를 매핑하는 방식으로 고민을 시작했습니다.

두 번째는 인프라마다 설정 파일을 관리해 주입하는 방식으로 구성해 인프라 설정마다 발생하는 오차를 줄이도록 고안했습니다.

원인을 넘어선 횡단 관심사와 종단 관심사

팀 그라운드 룰로 적용하기에는 수정과 확장에 대응하지 못해 부족함을 느꼈습니다. 확장에 자유로운 구조를 고민하기 위해 개념을 추상화했습니다.

횡단적인 관심사를 분리해 시각화하면서 관리 대상에 맞는 책임을 명확히 할 수 있습니다.

종단적인 관심사를 구분했을 때는 고민이 컸습니다. 환경 변수 관리 영역 특수성이 있기 때문입니다.

환경 변수 관리 영역 특수성에 맞게 책임을 분리할 필요가 있습니다. 시스템은 운영 환경과 운영 환경 외 환경으로 격리되서 관리됩니다. 그럼 인프라를 기준으로 설정하게 되도 운영 환경은 따로 격리되서 관리됩니다. 그렇기에 오히려 휴먼 에러 발생 가능성을 높일 수 있습니다.

인프라 기준 분리한 경우는 다음과 같습니다.

환경 기준 분리한 경우는 다음과 같습니다.

격리된 채로 인프라 기준을 분리한다면 간단하지만 특정 환경이 격리된다면 누락된 데이터가 발생할 수 있습니다. 반면 환경 기준으로 분리한다면 복잡할 뿐더러 환경 별로 누락된 데이터가 존재할 수 밖에 없습니다. 두 방식 모두 누락된 데이터가 없도록 환경 설정 방식 프로세스를 고안해야 했습니다.

해당 방식으로 히스토리를 남기는 방법이 있으면 좋아보입니다. Flex를 활용한 워크플로우나 Git을 활용해 이력을 지속적으로 함께 관리하는 것도 방법 같습니다. 여기까지 해결 방법을 정리했습니다. 횡단적인 책임과 종단적인 책임으로 개념을 추상화해 확장에 유리한 구조를 고안하며 팀은 큰 걱정 없이 수정이 가능해졌습니다.

규칙이란건 작업할 때의 걱정을 덜어주곤 합니다. 반면 규칙으로 행동의 제약이 생기기도 합니다. 규칙을 세우면서 팀 행동에 제약이 생기지 않고 걱정을 덜어주는 방식을 고민하는 건 신경쓰는 기회가 됐습니다. 행동 제약이 생길지는 아래 질문을 던져 진행했습니다.

• 인프라 시스템 교체에 불편하지 않은가?
• 환경 변수 변경에 불편하지 않은가?
• 각 환경 별로 독립적인 환경 변수는 어떻게 관리할 생각인가?

결과

앞으로 어떤 방식으로 고민한 내용을 적용할지 고민해볼 생각입니다. 대표적으로 spring cloud config, aws system manager parameter store 등을 고민하고 있습니다.

적절한 방식이 결정되면 추후 업데이트 진행하겠습니다.