Feature flag

어뷰징을 막기 위해서 하드코딩되어 있었던 파라미터를 동적으로 변경하고 싶은 요구사항이 있었습니다. 그래서 db로 파라미터를 저장하고 수정할 수 있는 기능을 만들고 조회는 글로벌 캐시를 이용하여 구현을 하였습니다.

getBooleanValue, getIntValue, getStringValue 총 3개의 메서드를 지원하였고 그룹 기능과 값 변경에 대한 히스토리를 조회할 수 있도록 하였습니다. 해당 값들은 시스템에 중요한 역활을 하는 부분이라 변경시에 알림을 받아 볼 수 있도록 하였습니다.

내부 구현이 변경되는 작업이 있을 경우 as-is 코드를 제거하고 to-be 코드를 작성하는 방식이 아니라 as-is 코드와 to-be 코드를 그대로 유지한 체 getBooleanValue를 이용하여 as-is 코드와 to-be 코드를 선택할 수 있도록 하여 예기치 못한 상황에 대해서 빠른 롤백을 할 수 있게 하여 서비스의 안정성을 높이는 방법으로도 사용하고 있습니다.

나중에 알게 된 거지만 이것을 Feature flag라 부르는 개념이고 널리 사용하고 있는 기법이라는 것을 알게 되었습니다.

위에 단계적 배포라는 부분이 있는데 특정 기능을 카나리 배포와 유사한 방식으로 사용자 요청을 샘플링하여 점진적으로 새로운 기능으로 전환할 수 있도록 getIntValue를 이용하여 0 ~ 100까지 변경해가면서 모니터링을 하면서 작업을 한 적도 있습니다.

또 다른 용도로는 1,500개 정도의 테스트가 자동으로 실행되고 있는데 가끔 통합 테스트에 사내 api에서 문제가 생기는 경우가 발생하는데 이때 마다 테스트 케이스를 변경하는 것은 매우 귀찮은 작업이라 해당 테스트 케이스에 대한 feature flag를 만들고 해당 테스트 케이스가 실패를 하더라도 무시하게 처리했다가 사내 api가 정상화가 되면 다시 테스트가 실행되도록 하여 편리하게 테스트를 관리할 수 있도록 하였습니다.

이 후에 request가 매우 많은 부분에도 사용해야 하는 경우가 생겼는데 글로벌 캐시에 부하를 방지하고 성능향상을 위해서 로컬 캐시 기능도 구현을 하였습니다.

서버 외에도 client에도 사용하고 싶다는 요구사항이 있어서 http api를 만들어 제공도 하고 있습니다.

getBooleanValue, getIntValue, getStringValue와 총 3가지의 타입만 지원했지만 복잡한 데이터 구조가 필요한 경우도 발생하여 json을 지원하는 기능도 추가하였습니다. json 데이터는 내용이 많을 경우가 있어서 변경시에 어떤 부분이 변경되었는지 인지하기 어려운 부분이 있어서 diff 부분만 알림을 보내어서 어떤 부분이 어떻게 변경되었는지 빠르게 인지할 수 있도록 하였습니다.

기존에는 조회하는 http api만 있었지만 feature flag를 동적으로 생성해야 하는 요구사항도 있어서 CRUD를 모두 지원하는 http api로 확장도 되었습니다.

feature flag는 소프트웨어 개발시에 여러 이점을 있으므로 잘 사용해보시면 좋을 것 같습니다.