네임스페이스 생성부터 하게 될텐데 처음엔 테스트를 해보기 위해 생성부터 했었지만 문득 생각이 들었다. 무슨 기준으로 네임스페이스를 구분해서 생성할까?

경험상 뭔가의 프로젝트를 처음 진행할 때 첫번째 고민 포인트가 항상 이 부분 이었던 것 같다. 어떻게 분류해서 네이밍하고 전략을 세울 것인가? 고민이 되는 부분이기에 결정하게 된 과정을 간단하게 작성한다.

네임스페이스

먼저 네임스페이스에 대해 알아둘 필요가 있다. 공식 문서를 읽는 것은 달가운 일이 아니지만 읽지 않으면 많은 시간을 버리게 될 때가 있다. 공식 문서를 요약하면 아래와 같다.

• 클러스터를 다수의 사용자 그룹이 나눠서 사용 할 수 있도록 한다.
• 클러스터를 생성하면 초기 네임스페이스 default, kube-system, kube-public 3개가 있다.
• kube- 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다.
• 네임스페이스는 유효한 DNS 레이블 이어야 한다.
  • 최대 63개 문자를 포함
  • 소문자 영숫자 또는 ‘-‘만 포함
  • 알파벳 문자로 시작
  • 영숫자로 끝남
• 네임스페이스를 삭제하면 내부의 모든 구성요소가 제거된다.
• 네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 전혀 고려할 필요가 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자. (공식 문서 그대로 발췌)

그럼 언제 쓰라고?

결국 여러 개의 팀에서 많은 개발 인력이 있을 때야 비로소 네임스페이스 구분이 기능적으로 유의미 하다는 것. 다만 경험상 개인 프로젝트의 경우에도 최소한의 구분은 필요하다고 생각한다. 아래와 같은 이유로 나는 네임스페이스를 분리하기로 결정했다.

• 서비스 확장 가능성
  서비스 확장이 고려되지 않은 네이밍은 나중에 일을 피곤하게 만든다. 처음에 설계 과정에서 10의 노력이 필요했다면 구축이 완료된 후 고려하고 분리하기 위해선 3~40 이상의 노력이 들어간다고 느껴진다.
  
• 장애는 나의 적
  아무리 개인 프로젝트라 하지만 수정 즉시 배포될 때 장애가 발생하는 것은 참 불쾌한 일이다. 최소한 배포 서버 환경에서 테스트 해볼 수 있도록 구성하는게 그나마 장애 발생률을 줄일 수 있다.

어떻게 구분하나?

네임스페이스 공식 문서에 예시를 든 것은 development, production 으로 환경별 구분을 하여 사용한 예시가 나온다. 비교적 규모와 상관 없이 타당한 구분 방법이라고 생각된다. 네임스페이스를 구분하는 것에 정답은 없다. 프로젝트의 크기, 팀의 구성, 환경, 보안 요구사항, 자원 관리 등의 요소에 따라 집단에 맞게 생성하면 된다.

• 환경별 구분
  가장 흔한 네임스페이스 구분 방식으로, 각 환경마다 별도의 네임스페이스를 생성하여 자원들을 격리합니다. 이를 통해 환경별로 다른 구성과 설정을 적용할 수 있다.
  예시: development, staging, production, …
  
• 기능(도메인) 또는 애플리케이션별 구분
  프론트엔드, 백엔드, 데이터베이스와 같은 애플리케이션의 기능이나 도메인별로 네임스페이스를 구분할 수 있다. MSA 프로젝트의 경우 세부 도메인으로 나누는 것도 방법이지만 너무 세분화된 구분이 될 경우 관리 복잡도가 증가 할 수 있으므로 주의
  예시 : front-end, back-end, database, user-api, payment-api, …
  
• 프로젝트 또는 팀별 구분
  프로젝트 또는 팀 단위로 네임스페이스를 구분하여 리소스를 관리하는 방식. 여러 팀이 같은 클러스터를 사용하면서 각 팀의 리소스를 독립적으로 운영할 때 유용하다.
  예시 : team-user, team-payment, team-product, …
  
• 보안 및 권한 관리
  네임스페이스는 RBAC(Role-Based Access Control)과 같은 권한 관리를 용이하게 한다. 각 네임스페이스에 대해 접근 권한을 달리 설정하여, 민감한 자원에 대한 접근을 제한하거나 각 팀에 적합한 권한을 부여할 수 있다. 관리해야 할 권한이 많아지면 관리 복잡도가 많이 높아질 수 있다.
  
• 리소스 제한 및 할당
  네임스페이스별로 리소스 쿼터(Resource Quotas)를 설정할 수 있다. 이를 통해 각 네임스페이스가 사용할 수 있는 CPU, 메모리, 스토리지 등의 자원을 제한하고 관리할 수 있다. 특정 네임스페이스가 자원을 과다하게 사용하는 것을 방지할 필요가 있을 때 유용하다.
  

네임스페이스를 생성하는 전략은 이외에도 여럿 있을 수 있다. 자신이 진행할 프로젝트에 따라 전략을 세우고 생성, 관리하면 된다.

나는 환경별로 구분하여 생성하는 전략을 사용하려한다.