AWS re:Invent 2022 - Building and operating at scale with feature management 요약

Building and operating at scale with feature management

Background

• AWS re:invent 2022 에서 Launch Darkly 가 진행한 세션으로 feature flag 를 통해서 효과적으로 대규모 운영 및 관리를 하는 방법에 대한 내용을 설명한다. 

---

지표

• 약 4,000 개 이상의 고객사
• 약 24M 정도의 동시 Streaming API connection 수
• 매일 약 20T 이상의 feature flag 평가 
• 초당 약 16M API request

---

Architecture

• 대략적인 시스템은 아래 이미지와 같고 전체적인 아키텍쳐는 AWS East 1 에 3개의 AZ 에 걸쳐 호스팅 되어 있다고 한다. 
• 실제로는 global distribution 형태로 multi-region 으로 시스템을 구축 해두었다고 한다. 

 

 

• 아키텍쳐에는 3가지의 주요 컴포넌트로 이루어져 있다고 한다. (사실은 1개 더 있다고 함)

Gonfalon Application

• Go 로 짜여진 상당히 전통적인 모놀리틱 웹 어플리케이션 
• flagging  과 관련된 REST API, front end 로 구성된 대시보드 어플리케이션 

Event Ingestion Pipeline

• 16 millon RPS(Request Per Second)의 처리 성능을 가지며 150 TB 데이터가 저장되어 있다고 한다. 
• Kinesis, Dynamo DB, Elastic Cache 를 비롯한 AWS Managed Service 를 heavily 하게 사용하고 있다고 함

Flag Delivery Network

• Dashboard 에서 변경되는 flag 의 상태를 거의 즉시 고객의 SDK 에 설정 정보를 전파하기 위한 네트워크 모델
• streaming model (aka. push base model) 로 구성되어 있으며 고객의 SDK <-> Streaming API 를 persistent HTTPS connections 형태로 연결하여 Server-Sent Events 형태의 프로토콜로 변경 사항이 생겼을 때 SDK 로 메시지를 push 해주는 방식이라고 한다. 
  • 물론 polling 방식도 하나의 옵션이었지만 운영 관점에서 발생할 수 있는 문제를 해결하고자 streaming 방식을 택했다고 함
  • eventualy consistency 로 인한 여러 디바이스 혹은 infra 간의 설정 불일치 문제 등등
• 흥미로운 점은 Server-Sent Events 프로토콜이 그리 많이 사용되는 프로토콜은 아니라고 한다. (기껏 해봐야 Twitter 의 DM infrastructure 정도)
• 일종의 단방향 웹 소켓 방식으로 양방향 통신이 필요 없고 (Web Socket 은 불필요한 복잡도도 언급) 단지 변경사항을 단방향으로 push 만 해주면 되기 때문에 해당 방식을 택했다고 한다. 
• 이러한 방식을 통해서 현재느 20 ~ 40 millon 정도의 동시 connection 을 처리하고 있다고 한다. 
• 좀 더 디테일하게는 client side (mobile, browser) 와 server side (Java, Python 등) SDK 의 방식이 다르다고 함

Giant Elastic Search Cluster

• 보통 feature flagging event 가 발생하면 context 라고 하는 정보를 넘겨주게 된다. 
• 일종의 user 프로퍼티 정보를 의미하며 이 context 를 기반으로 rule engine 이 동작한다. 
  • ex) user property 기반의 roll out, 타겟팅 등등
• 이러한 context 정보는 유저가 대시보드에서 설정할 때 반드시 필요한 정보들이며 이를 통해서 개발자가 아닌 직군들이 쉽게 값을 찾을 수 있게끔 할 수 있다. 
• 현재까지 약 14 billion 이상의 document 들이 ES 클러스터에 저장되어 있다고 한다. 

---

User Case 1: Application Modernization

• MongoDB + PostgresSQL -> CrDB 로의 마이그레이션 과정에서 Feature Flag 를 효과적으로 사용했다고 한다. 
• 해당 예제에서는 단계별로 Mode 를 나누고 Feature Flag 의 Variation 을 활용하여 각 Mode 별 rollout 을 관리하는 용도로 사용을 하였다. 

 

Mode A

• 기존 DB 만 사용하여 Read & Write 를 수행하는 단계로 문제가 생길 경우 roll back 을 해야하는 mode 이기도 하다. 

 

 

Mode AB

• 새로운 DB 에 기존 DB 데이터를 backfill 한 후 Dual Write 를 수행하는 단계로 consistency 가 맞춰진 상태를 가정한다. 

 

 

Mode BA

• 새로운 DB 에 일부 read 트래픽을 할당하여 Dual Write 를 수행하는 단계로 기존 DB 로의 검증 단계가 수반된다. 
• 이 단계에서 만약 문제가 발생한다고 하더라도 언제든지 roll back 이 가능하다. 

 

Mode B

• 신규 DB 검증이 완료되어 fully 새로운 DB 로 스위칭이 완료된 단계를 의미힌다. 

 

• Launch Darkly 에서 실제로 활용한 F/F 의 설정 화면으로 Multi Variation 으로 위 Mode 를 각각 구성한 모습이다. 
• F/F 를 이용하면 각 단계별로 점진적으로 roll out 을 할 수가 있다는 것을 강조한다. 

---

User Case 2: Compliance

• Compliance 는 여러 Third Party 를 이용하는 SaaS 기업에 있어서 골치 덩어리이다. 
  • 특히나 global SaaS 인 경우 상황에 따라서 준수해야 하는 규정들이 굉장히 다양한 것 같다 .. 
• 일례로 FedRAMP (미국 연방 위험 및 권한 부여 관리 프로그램) 을 준수해야 하는 경우 사용할 수 있는 vendor 에 대한 제약사항이 생긴다고 한다. 
• 그렇기 때문에 이를 해결하기 위해서는 단일 code base 가 아닌 여러벌의 코드 혹은 인스턴스를 관리해야 하는 pain point 가 생기는데 이를 해결하기 위해서 Feature Flag 를 사용할 수 있다고 한다. 

 

 

• 아래는 상황에서 따라서 각각의 vendor 를 사용하는 코드를 control 하는 예 

---

User Case 3: Cost and performance optimization

• 일부 서비스를 전통적인 X86 아키텍쳐에서 Graviton 으로 마이그레이션 하는 과정에서 Feature Flag 를 이용함
• Feature Flag 를 이용하여 비교적 간단하게 (?) 각 워크로드에 대해서 traffic 을 routing 하고 결과에 대해서 측정할 수 있었다고 한다. 

 

• 그 결과 아래와 같은 비용 절감 효과와 더 높은 퍼포먼스를 얻을 수 있었다는 것을 강조하였다. 
  • Feature Flag 의 이점 보다는 결과치에 대해서 강조를 하는 느낌이었음 ..