시작

입사

회사 입사시, 사실 나는 네트워크엔지니어겸 개발자로 입사하였다. 당연히 NE로써 IP나 장비 관리에 관심이 갔고, 특히 IP 에 대해 관심이 컸다.

그런데...

IP 를 엑셀로 관리하고 있으며, 현황 자체도 제대로 파악이 안되고 있을 줄이야.

역시 급한게..

어느 시점부터 IP 충돌 이슈가 인프라 부서내에 많이 이야기 되고 있었다. IP 충돌은 사실 Protocol Level 에서 검증이 가능하긴 하지만, 그러기 위해서는 모든 L3 Switch(혹은 라우터)에 RARP 기능이 필요할 뿐더러, Log Event를 Trap 하여 전파하는 기능이 필요하다. 그리고 운영상 가장 중요한, 도데체 누가 왜 이 IP 를 사용하려 했는지 파악을 해야하는데, 이는 장비만으로는 알 수 없는 내용이다.
이에, 다른 NE 분께서 엑셀로 관리되던 IP 정보등을 Web 상에서 다같이 보면서 관리하고 싶은데 어떻게 안될까요?라고 요청을 주셔 개발을 시작하게 되었다. (사실 IP충돌 장애로 인한 실장님의 격노를 피할 궁리로 개발 요청을 주신 듯한 감도 있었다)

설계

IP 할당 설계

IP 자체에 대한 데이터 관리에 앞서, IP를 누구에게 어떤 용도로 할당을 했으며, 해당 IP 는 어떤 리소스에서 사용중인지에 대한 메타 정보 관리가 더 시급했다. NE와의 논의 끝에, IP 사용 신청과 IP 사용 승인기능을 나눠 IP 할당에 대해 좀 더 타이트하게 관리 해 보자는 의견이 제시되었다.

복잡하고 수고스러움이 생길지라도 IP를 마구잡이로 사용하는 경우를 제어하자라는 취지가 강했던 것으로 기억한다.

IP 데이터 관리

앞서 이야기 했듯, IP 데이터는 IP address, Network, state 등 데이터들도 중요하지만 메타 데이터가 훨씬 중요하였다. 특히 NE 혹은 관제팀과의 커뮤니케이션 등도 필요하여 하나의 IP 에 파생되는 메타 데이터는 생각보다 많았다.
또한, IP 가 현재 어디에서 사용 중인지에 대한 현행화도 만만치 않은 작업이었다. 이를 위해 CMDB의 네트워크 데이터 및 서버 IP 데이터등에 대한 수집, 전처리를 담당하는 Batch Script 를 개발하였다.

생각보다..?

약 1년정도의 서비스 기간동안 NE 에게 받은 Feedback 은

아.. 확인 절차 생각보다 너무 귀찮은데요..?

였다.
내 생각에도 그럴 것 같았다. 특히나 약 4~5개월차쯤 부터는 IP 충돌도 많이 사라지고, IP를 함부로 사용하는 케이스도 적어지기 시작하였다.
그리고 IPMS 를 이용하여 IP 를 사용해야하는 다른 Self-service 나 백오피스 서비스(ex: Zero-touch provisioning, LBaaS, FWaaS, ... )등에서 IPMS 의 API 를 사용해야 하는 케이스가 발생하며 이러한 복잡한 승인 절차에 대해 다시 생각하는 계기가 되었다.

다시

IP 할당 재 설계

기존에 IP에 대한 승인 절차를 없애고 사용자가 Self-service 로 IP 를 획득할 수 있게 변경하였다. 다만, 이렇게 되면 사용하지 않아야 하는 Network 대역 혹은 IP 대역에 대해서도 획득할 수 있기 때문에 "Reserved" 라는 State 를 두어 이를 사전에 방어하거나 사용자가 IP를 잘못 사용할 경우 강제로 회수하는 기능을 넣는 등 관리자 기능에 대한 강화를 추가하였다.

타 솔루션 연동 및 Public Cloud IP

IPMS가 회사에서 서비스용 IP에 대한 모든 IP를 다루게 되며, Baremetal Server Provisioning 을 개발 중이신 팀원 분께서 해당 서비스와의 연동을 요청하셨다. 또한 LBaaS, FWaaS 등 구성에 IP 를 직접 할당해야 하는 서비스들도 IPMS 와 연동을 하며 IP의 사용 목적등에 대한 History 가 자연스럽게 쌓이고 관리도 되어가고 있었다.
추가로, Public Cloud 에서 사용하는 IP 에 대한 데이터를 추가하여 불필요하게 사용중인 Network 나 IP 로 인한 비용 절감에도 기여를 하게 되었다.

마치며

Private Cloud 혹은 사내 네트워크를 직접 관리하는 회사에서는 절대적으로 필요한 솔루션이다. Open Source 나 상용 솔루션을 사용하는 분들이 많은 것으로 알고 있다. 하지만 그럴 경우 원하는 데이터를 넣거나 자동화로 관리하는게 어려운 경우도 많다.
하지만 개발 난이도나 복잡성으로 인하여 In-house 로 개발하는 것이 무조건 좋지는 않다. 특히 그렇게 개발하면 개발자는 운영과 개발을 동시에 해야하는 리스크가 있기 때문에 이에 대해서도 잘 가늠하고 진행해야 할 것이다.