시작

사내 클라우드 플랫폼 개발 관련하여, Firewall as a Service 에 대한 개발을 요청 받았다. 네트워크 장비에 대한 제어를 하는 솔루션이기 때문에 LBaaS 와 크게 다르지 않아 빠른 개발이 가능할 것이라 예상하여 혼자 개발을 진행하게 되었다.

Like LBaaS Achitecture

앞서 이야기 했다시피 본 서비스는 LBaaS 와 유사한 구조를 갖게 되었다. 다른점이라면 컨트롤 해야 하는 대상 장비의 수는 현저히 적다는 것과, 대상 장비의 관리 CPU 가 현저히 좋지 않았다는 점이다. CPU Load 가 높은 상태로 유지되면 Web Console 접속이나 API를 이용한 접근이 불가해지기 때문에 API call에 Throttling 을 추가하였다. (기억으로는 10 qps 로 하였다). Backend 에서 Broker 로의 메시지는 1개라 하여도 Broker 에서 장비로의 API call 은 여러개가 될 수 있다. 이 부분에 대한 Throttling 을 추가하였다고 보면 좋을 것 같다.

Firewall 설정

방화벽은 바깥으로부터 안을 보호하는 역할이라 보면 된다. (방화벽 위키피디아)
간단히 말하자면, 차로 유료 주차장에 들어설 때 있는 차단기 같은 역할이라 보면 된다.

PC 는 PC 내부의 리소스를 보호하기 위해 OS 자체에서 방화벽을 제어 할 수 있다.

하지만 우리가 해야할 것은 내부 네트워크 및 리소스를 보호 해야하는 방화벽이기 때문에 해당 방화벽은 외부 네트워크와의 통신과 인접된 곳에 설치되어 있고, 이를 제어해야 하는 것이다.

Firewall에 고성능 Router 기능이 포함되어 있으면 CE Router 대신 Firewall 이 모든 것을 할 수 있겠지만, 보통은 그렇게 안하는 것으로 알고 있다 😀
방화벽 설정은 간단하게 말하자면 접근 관리라고 볼 수 있다. Source/Destination 을 지정하고 어떤 내용에 대해서는 허용하고 차단할 것인지를 설정한다고 보면 된다. Source/Destination 에 대해서는, 회사에서 다루는 네트워크 내 IP는, Outbound 일 경우는 Source 가 되고 Inbound 일 경우 Destination 이 된다. Outbound 는, 간단히, 내부망에서 외부망으로 나가는 것이고 Inbound 는 그 반대로 보면 된다. 기준은 당연하지만 장비 자체라고 보면 된다. 따라서 장비에도 Interface 를 내부/외부용으로 구분하여 관리할 필요가 있다. 마지막으로 접근 관리용 프로파일은 일반적으로는 설정되어 있는 위에서 아래 방향으로 적용된다고 보면 된다. (혹은 priority 가 있는 경우 작은 값에서 큰 값으로 적용된다)

데이터 관리

기본적인 데이터 관리는 접근 관리용 Rule 에 대한 관리라고 볼 수 있다. 기본 요구사항 중 클라우드 내 서버에서 외부 네트워크 접근 관련하여 많이 사용하는 사이트에 대해서는 White List 로 관리되면 좋겠다라는 사항이 있었다. 이를 위해 유저가 설정하는 Private-rule 과 관리자가 미리 열어두는 Public-rule 에 대한 테이블을 따로 관리하게 하였다.

사내 클라우드 서비스는 "project" 와 "organization"을 기반으로 관리되고 있기 때문에 해당 단위별로 네트워크를 논리적으로 분할해야 했다. 따라서 Private-rule 은 이에 맞춰 데이터를 구분할 필요가 있었다.

서버 데이터 동기화

개발 타겟인 방화벽은 사내 클라우드 서비스를 목적으로 하고 있었다. 때문에 클라우드에서 생성한 서버를 대상으로 장비에 등록을 할 필요가 있었다. 이를 매번 사용자가 UI 를 통해 등록하면 번거롭고 생산성이 떨어지게 된다. 따라서 서버 생성시 자동으로 방화벽에 관련 IP가 등록되도록하는 방안을 마련했다.

그림과 같이 서버 IP 등록에 대한 State 를 두게 되었다. Batch Job 을 통해 해당 DB 의 state 를 참고하여 장비에 등록하는 Message 를 Queue 로 보내게 되어 있었다. 각 State 는 아래와 같이 동작한다.

• add: 새로 등록될 서버. 다음 Batch Job 시 참조하게 된다.
• delete: 삭제될 서버. 다음 Batch Job 시 참조하게 된다.
• syncing: 장비에 설정 중인 서버. 다음 Batch Job 시 참조하지 않는다.
• add-fail/delete-fail: 장비에 설정이 실패한 서버. 다음 Batch Job 시 참조하게 된다.
• done: 동작이 마무리된 서버. 다음 Batch Job 시 참조하지 않는다.

위 내용 외로, 혹여나 누락이 발생할 경우를 대비하여 GC 역할을 하는 Script 를 추가하여 생성된 VM IP 대비 방화벽에 등록된 IP 에 대한 Sync 를 맞추는 노력을 진행하였었다.

마무리

갑자기 급하게 개발된 것도 있고, 타 부서와의 힘겨루기도 있어 지금 생각하면 참 맞나.. 싶은 요구사항도 꽤 있었다.😅 서비스 오픈 일정을 고려해서 2주이내 완성을 목표로 요청 받았지만 1주 정도만에 1차 완성 후 QA 하며 완성도를 올렸었고, 나름 이 프로젝트로 생산성에 대한 평가를 좋게 받은 계기가 되었던 것으로 기억하고 있다. LBaaS와 비슷한 내용이 많았지만, 데이터 형상이나 관리, 장비의 성능 등의 다른 부분도 있어 약간의 신선함 느낌도 있었다.