<aside> 📎

업무 배경

업무 목표

업무 성과 및 의의

신규 API 도입 이후 발생한 문제를 CS 지식으로 해결

NAT 구축 및 적용, 문제 해결

</aside>

업무 내용

✈︎ 업무 배경

신규 도입 API 사용을 위해 Allowed List에 IP를 등록했습니다. GCP의 MIG(Managed Instance Group) 배포 방식에 따르면 outbound IP가 배포 시마다 변경되므로, 개발자가 수동으로 매번 IP를 등록하는 위험성이 존재했습니다.

✈︎ 업무 목표

• outbound IP 고정
• 기존 아키텍처 유지

✈︎ 업무 성과 및 의의

• 신규 API 도입 이후 발생한 문제를 CS 지식으로 해결

  신규 API 도입 이후 다음 두 가지 사항이 요구되었습니다:

  • 기존 배포 방식 유지
  • API 요청 host 필드값 고정

  기존 배포 방식을 유지하면서 신규 API 운영에 문제가 없도록 네트워크 구성을 최적화하였습니다. NAT(Network Address Translation)를 활용하여 host 필드값을 고정함으로써, 개발자가 수동으로 IP를 등록해야 하는 번거로움과 위험성을 제거하였습니다.

업무 과정

1) 두 가지 요구사항

1. 기존 배포 방식 유지

   

   GCP MIG의 배포 방식, Substitute

   GCP MIG의 Substitute 방식을 통해 무중단 배포로 서버를 운영하고 있었습니다. 서비스 특성상 24시간 서버 가동이 필수적이었기에 무중단 배포는 반드시 유지해야 했으며, Terraform이나 Ansible 같은 IaC를 도입할 만한 리소스가 부족한 상황이었습니다.

2. host 필드값 고정

   

   [ NICE API 요청 과정 ]

   1. WebClient를 통해 NICE 서버에 Request.
      • 이때, 공인 IP를 요청 헤더 host 필드값으로 입력
   2. NICE 측에서 화이트리스트에 등록된 IP와 비교
   3. IP가 동일하다면, 본인인증 관련 응답

   기존 배포 방식을 유지하면, 매 배포마다 IP가 변경됩니다. 이러한 과정과 기존 배포 방식의 충돌로, 개발자의 번거로움과 서버 운영의 위험성을 초래하였습니다.

2) 문제 해결 방법 ⇒ NAT