🧪 우버의 새로운 실험플랫폼 우버에는 만들어진지 7년 넘은 feature flagging과 A/B testing을 지원하는 Morpheus라는 실험 플랫폼이 있었습니다. 만든 이후로 지금까지 우

🧪 우버의 새로운 실험플랫폼 우버에는 만들어진지 7년 넘은 feature flagging과 A/B testing을 지원하는 Morpheus라는 실험 플랫폼이 있었습니다. 만든 이후로 지금까지 우버는 크게 성장을 했고, 2020년 초에 플랫폼을 다시 살펴보니 많은 실험들이 실험중에 문제들이 생겨서 다시 진행되어야 하는 경우가 있었습니다. Morpheus가 더 이상 우버의 다양한 유즈 케이스를 커버하지 못하다보니 우버는 새로운 실험플랫폼을 처음부터 만들기로 했습니다. 우버가 새로운 실험플랫폼을 어떤 목표로 만들었고, 코어 기능들은 무엇인지 간략하게 요약했습니다. 더 자세한 내용은 원문을 참고해주세요. ⭐️ 새로운 실험플랫폼의 목표 새로운 실험플랫폼은 다양한 종류의 실험들을 높은 퀄리티로 빠르게 진행할 수 있게 하려고 했습니다. - 높은 퀄리티 어떤 실험을 설계를 하던, 실험 결과를 신뢰할 수 있도록 만들어야 했습니다. - 높은 생산성 빌드/릴리즈 사이클과 실험을 decoupling해서 모바일의 복잡성을 줄여야 했습니다. 그래서 client에서 사용하는 실험플랫폼 관련 interface를 더 간소화 했습니다. 모바일/백엔드에 파편화되어있던 configuration 플랫폼들도 통합해야 했습니다. 마지막으로, 기존에는 실험의 대상을 유저로만 할 수 있었고 지표가 표준화 되어있지 않아서 조직들마다 다른 지표를 봐서 혼란을 야기할 수 있는 상황이었습니다. 이런 점들을 해결해서 생산성을 높혀야 했습니다. - 다양성 우버의 다양한 유즈 케이스를 커버할 수 있어야 했습니다. 백엔드, 모바일, 웹 등 다양한 플랫폼에서 실험이 가능해야 했고, holdout이나 다른 실험의 의존적인 실험등 계층적인 실험도 지원이 되어야 했습니다. ⚙️ 아키텍처 1. 파라미터를 활용해서 실험과 decoupling을 했습니다. 파라미터 값만 override하면 새로운 실험도 쉽게 진행할 수 있기에 추가적인 코드 변경이 필요 없어졌습니다. 2. Flipr라는 backend configuration 시스템 위에 실험플랫폼 파라미터들을 둬서, 실험플랫폼 파라미터들이 더 우선순위를 갖으면서 파라미터를 전달할 수 있게 했습니다. 기존 backend 플랫폼 위에 실험플랫폼 파라미터 기능을 뒀기 때문에 전체 시스템을 하나로 통합할 수 있었습니다. 3. randomization이나, treatment plan을 개선해서 여러 실험들이 하나의 파라미터로 진행될 수 있도록 했습니다. 4. 파라미터마다 제약조건들을 둬서 더 복잡한 실험들을 가능하게 했습니다 (ex. 특정 실험에 의존적인 실험, 우버 전사 단위의 holdout이나 조직 단위의 holdout). 5. 데이터 파이프라인을 더 generalize해서 randomization unit이 바뀌어도 추가작업 없이 파이프라인이 돌아갈 수 있게 했습니다. 6. UI에서나 DS분들이 사용하는 jupyter notebook에서 같은 Python 패키지를 사용 할 수 있도록 했습니다. 그리고 지표 통일화를 했습니다. 7. fallback 시나리오에 대해서도 잘 대응할 수 있도록 했고 그 외의 SDK 안정성을 챙겼습니다 (ex. default value를 항상 갖고 있어서 네트워크 fail에도 대응할 수 있게 하기, 실험 파라미터 사용 전에 자동으로 로깅해서 수동 로깅으로 인한 버그들 없앰, 등) 서비스가 성장할수록 다양한 기능들이 생기는 것처럼, 실험플랫폼도 서비스가 성장함에 따라 그 다양한 기능들을 쉽고 빠르게 실험할 수 있도록 계속 고도화되어야 하는 것 같습니다.