이전 API Version 관리를 포스팅했던 내용에 이어 이번에는 Feature Flags 내용을 작성해보려고 한다.
현재까지 나는 신규 프로젝트를 개발하는 일이 잦았다.
신규프로젝트를 진행하며 빠르게 변동되는 API들을 관리할 필요성이 있었고 서비스 도중 사용하지 않는 API를 제외시키기 위해 업데이트 후 재 배포를 했던 경우도 여럿 있었다.
그러다 문득, 들었던 생각은 굳이 API 필터링을 위해 배포 비용을 감안해야 할까?라는 의문이 들었었고 이를 해결할 수 있는 방법은 없을지 최근 생각하게 되었었다.
이런 고민에 대한 이야기를 민수님, 건수님께 꺼냈을 때 민수님께서 Feature Flags란 키워드를 알려주셨었고 해당 키워드에 대해서 한번 학습을 진행해 보았고 이를 잊지 않기 위해 정리를 함께 진행했다.
이번 글에서는 Feature Flags에 대한 이야기, 간단한 구현과 내 생각을 함께 적어보려고 한다.
Feature Flags는 다른 말로는 Feature Toggles, Feature Bits, Feature Flippers이라고도 이야기할 수 있다.
Feature Flags는 팀에서 코드를 변경하지 않고도 시스템 동작을 수정할 수 있는 기술이다. 해당 기술은 새로운 기능을 빠르고 안전하게 고객에게 제공할 수 있는 하나의 패턴으로도 생각할 수 있다.
( 나는 해당 기술을 접하며 Toggle의 기능을 한번 상기시켜 보았었다. )
또한, 예를 들어, 나는 해당 기능을 보며 다음과 같은 생각을 했었다.
이와 더해 Feature Flag를 사용하는 정책을 어떻게 정하고 활용하는지에 따라 발전할 수 있는 가짓수는 다양할 수 있겠단 생각도 함께 들었다.
하지만, 해당 기술을 접목하게 될 때 토글의 기능의 설계, 관리하는 부분에서 복잡성을 야기할 수도 있겠다는 생각도 함께 들었다. 이 생각은 Martin Fowler의 Feature Toggles 아티클에서도 이야기하고 있음을 알 수 있다.
예를 들어, 전자 상거래 사이트에서 배송 파트너 중 하나에 대해서만 동작하는 새로운 예상 배송 날짜 기능을 사용자에게 표시하지 않고, 모든 배송 파트너에 대해 해당 기능이 구현될 때까지 기다리는 걸 선호할 수 있다.
Feature Flags를 적용하고 사용할수록 더 이상 OFF로 관리가 필요 없는 API나 데이터가 쌓일 것이다.
이와 같은 상황이 발생하면 결국 사용하지 않는 레거시 데이터에 의해 데이터베이스의 비용이 증가할 것이다.
나는 위 상황을 생각했을 때 이전 FCM 푸시를 개발했을 때 Topic의 신선도 보장이라는 키워드가 함께 생각났다.
FCM 또한 Topic을 서버에서 관리를 진행해줘야 했기에 적재를 진행했었고 사용하지 않는 Topic들을 제거해줘야 했었다.
즉, 각 Flags들 간 어느 정도의 기간이 경과되었을 때 데이터 신선도를 관리할지 의사결정을 하여 관리하는 게 중요하단 생각이 들었다.
실습을 진행할 때 현재 내가 업무에서 직면하고 있는 문제를 토대로 한번 요구사항을 부여해 개발하면 좋겠다고 생각을 했다.
요구사항은 다음과 같다.
또한, 백오피스 등에서 활성화되어있는 API들의 관리를 위한 Page가 존재해야 한다.
이번 실습에서는 다양한 Toggles 기법이 존재하지만 현재 문제를 해결하기 위해 운영환경에서 On / Off를 할 수 있는 단순 상황을 토대로 생각을 하고 개발을 진행하였다.
실습 코드의 경우 일반적인 다른 CRUD와 차이점은 없기에, 불필요한 내용은 생략하고 주요 포인트만 다뤄보려고 한다.
먼저, 각 서비스 API의 관리를 위해 Feature Flag 어노테이션을 구현했다.
해당 어노테이션은 앞으로 각 API 메서드에 포함될 경우 각 선언한 API 명칭에 따라 On / OFF 여부를 검증하게 된다.
해당 어노테이션의 Aspect는 다음과 같다.
해당 구현에 의해 만약 요청이 들어왔을 경우 활성화되어있지 않은 API의 경우 다음과 같은 에러를 반환한다.
“현재 해당 API는 사용할 수 없습니다.”
해당 어노테이션은 Member Controller에 적용하였다.
실행을 하고 각 관리되고자 하는 Name을 추가하게 될 경우 아래와 같이 페이지에서 관리가 가능하다.
최초 추가 시, API는 활성화가 되어있는 상황이다.
해당 API에 요청을 보낼 경우 정상적으로 동작이 수행된다.
만약 이때 회원가입 API를 비활성화한다고 가정해 보겠다.
위와 같이 설정을 진행한 이후, 재 요청을 보내게 될 경우 사용할 수 없다는 에러를 반환하게 된다.
이처럼 각 On / Off에 따라 유연하게 API 관리를 진행할 수 있다.
현재 예제에서는 정말 간단한 요소가 추가되었지만 위에서 설명했던 것과 같이 각 Flag 정책에 따라 관리될 포인트를 나눠 적용할 수도 있다.
해당 부분은 한번 더 발전을 시켜보려고 한다.
( 해당 예시와 키워드를 알려주신 민수님께 다시 한번 감사드린다. )
위 설명한 것에 더해 Readme에도 작성을 진행하였다.
구현한 내용은 아래 링크에서 확인할 수 있다.
https://github.com/JoeCP17/Feature-flag-web
처음 해당 키워드를 접하고 학습을 진행하며 알게 모르게 많은 기업들에서 해당 기술을 고려하고 사용하고 있는 곳이 있음을 알 수 있었다.
내가 생각했던 고민을 이미 이전부터 정말 훌륭하신 개발자분들께서 하시고 계셨고 이에 대한 산출물이 나왔다고 생각한다.
이전 카프카 포스팅을 작성했을 때 카프카 탄생배경에 대해 간략하게 이야기했던 적이 있는데 이번 학습을 진행하며 당연한 이야기겠지만 현재상황에서의 어려움을 직면하고 불편함을 마주했을 때 이를 개선하기 위해 새로운 기술 또는 프레임워크가 탄생하고 이는 성장으로 가는 한 발자국의 발자국이 되고 있구나를 다시 한번 느낄 수 있었다.
아직, 부족함이 많지만 나 또한 어려움에 직면했을 때 이를 해결할 수 있는 여러 요소들을 고민하고 기여하고 싶단 생각을 다시 한번 하게 된 계기가 되었다.
Feature Toggles (aka Feature Flags)
Feature Toggles (aka Feature Flags)
Chained Transaction Manager 파헤치기 (1) | 2023.12.09 |
---|---|
실시간 코인시세 어디까지 알아봤니? part 1 (1) | 2023.08.14 |
빗썸 API를 활용한 매수 / 매도 데이터 적재 (1) | 2023.06.11 |
[Spring Boot + Chat GPT] Open AI API 적용기 (1) | 2023.04.16 |
분산락과 네임드락 그리고... 동시성 (1) | 2023.02.02 |