단순한 아키텍처를 옹호하며 (2022)
(danluu.com)- Wave는 70명의 엔지니어를 보유한 $1.7B(2.3조원) 규모의 회사 (아프리카를 위한 모바일 뱅킹 서비스 제공)
- Postgres 기반의 Python 모놀리스인 표준 CRUD 앱 아키텍처로 되어있음
- 단순한 아키텍처를 시작으로 복잡성을 최소화하며 문제를 해결함으로써 사용자에게 가치를 제공하는 작업에 엔지니어가 집중할 수 있었음
- Stackoverflow는 단일체(monolith)를 확장하여 18억 달러에 인수될 정도로 성공적으로 성장함
단순한 아키텍처의 효율성에도 불구하고 대부분의 언론은 복잡한 아키텍처를 좋아함
- 기술 컨퍼런스에서는 복잡한 마이크로서비스 기반 아키텍처에 대한 발표가 많으나 단순한 모논리스에 대한 발표는 없음
- 많은 기업들이 작은 규모 애플리케이션임에도 불구하고 복잡한 기술을 모방하고 그걸로 컨퍼런스 및 HN에서 인기를 얻음
- 우리가 사용하는 아키텍처는 너무 단순해서 아키텍처 다이어그램을 작성할 필요도 없음
단순함을 유지하는 방법
- Wave는 동기식 Python을 사용하고 있으며, 이는 서버 프로세스가 I/O를 기다리는 동안 차단됨을 의미함
- Eventlet 같은 비동기 프레임워크를 시도했지만, 버그가 너무 많아서 그 비용이 운영상의 고통을 감당할 가치가 없다고 판단했음
- 복잡성을 증가시키는 대신, 긴 실행 시간이 필요한 작업은 큐로 분리하여 처리함
- 데이터 거주 규정을 준수하기 위해 일부 국가에서는 온프레미스 데이터센터를 운영해야 함
- 세네갈/코트디부아르는 클라우드였지만, 우간다와 다른 국가들은 규정때문에 온프레미스를 필요로 함
- 이럴때 복잡한 아키텍처보다 단순한 아키텍처가 훨씬 간단함
구매 대신 구축
- 소수 인원팀이라 초기에는 소프트웨어 구매를 선호했으나, 중대한 버그를 해결할 수 없는 경우에는 자체 도구를 개발함
- 자체 도구 구축은 우리가 감당하고 싶지 않은 복잡성이지만, 일부 제품 카테고리에서는 상당히 광범위한 조사 후에도 우리에게 적합한 제품을 제공할 수 있는 공급업체를 찾지 못함
- 핵심 역량 외에도 자체 도구를 개발하고 내부 전문성을 유지하는 것이 때로는 필요함
재고 중인 선택들
- RabbitMQ, Celery, SQLAlchemy, Python 등의 기술 선택에 대해 재고 중이며, 이들은 복잡성을 증가시키거나 유지 관리 부담을 높임
- 새로운 코드베이스를 시작한다면 이러한 기술 선택에 대해 신중하게 고려할 것임
만족하는 선택들
- GraphQL, 사용자 정의 트랜스포트 프로토콜, Kubernetes 등의 선택에 만족함
- GraphQL은 자체 문서화, 코드 생성, GraphiQL 인터랙티브 탐색기 등의 장점이 있음.
- GraphQL을 사용하면 장점이 단점보다 더 크다고 생각
- 장점
- 정확한 반환 유형에 대한 자체 문서화
- 정확한 반환 유형의 코드 생성으로 인해 클라이언트가 더 안전해짐
- GraphiQL 대화형 탐색기로 생산성 향상
- 다양한 앱(사용자 앱, 지원 앱, Wave 에이전트 앱 등)이 대부분 하나의 API를 공유할 수 있어 복잡성이 줄어듦
- 구성 가능한 쿼리 언어를 사용하면 클라이언트가 특수 목적 엔드포인트를 많이 구축할 필요 없이 단일 패킷 왕복으로 필요한 데이터를 정확하게 가져올 수 있음
- RESTful API로 간주되는 항목에 대한 bikeshedding (중요한 안건을 미뤄둔 채 덜 중요한 일에 대해 깊이 의논하고 시간을 보내는 것) 제거
- 단점
- GraphQL 라이브러리는 GraphQL을 채택했을 당시엔 훌륭하지 않았음
- 기본 GQL 인코딩은 중복되며 많은 고객이 낮은 대역폭을 사용하기 때문에 크기 제한에 많은 관심을 기울이고 있음
- 장점
- Kubernetes는 국가별 데이터센터 운영 요구 사항을 충족시키기 위해 사용됨
결론
- 애플리케이션 아키텍처를 최대한 단순하게 유지함으로써 비즈니스에 도움이 되는 복잡성이 있는 곳에 복잡성(및 인력) 예산을 지출할 수 있음
- 복잡함을 더할 강력한 이유가 없는 한 가능한 한 간단하게 일을 처리한다는 생각을 통해 우리는 일반적으로 어려운 사업이라고 여겨지는 아프리카 금융 사업을 운영하고 있음에도 불구하고 엔지니어가 많이 없이도 상당히 큰 사업을 구축할 수 있었음
"구축 대신 구매"는 "구매 대신 구축"이 맞는것 같아요.
Another area is with software we’ve had to build (instead of buy).
"복잡도가 올라가면 비용(돈, 사람, 시간...)도 증가한다"
"심플한 아키텍처로 해결할 수 있는 문제를 복잡한 아키텍처로 해결하려 하지 마라."
Hacker News 의견
-
마이크로서비스에 대한 엔지니어 조언
- 마이크로서비스는 성능 향상 전략이 아니라, 잠재적인 비용 절감 전략과 엔지니어링 조정 전략임.
- 수평적으로 확장 가능한 모놀리식 애플리케이션과 마이크로서비스 간에는 큰 차이가 없음, 특정 기능을 축소하고자 할 때를 제외하고.
- 모놀리식 앱에서는 앱의 일부만 축소하는 것이 불가능함.
- 비용 절감은 대규모에서 시작되며, 최소 3개의 복제본이 필요함.
- 대부분의 회사에서 실제 이점은 엔지니어링 조정에 있음.
- 단일 저장소를 가진 모놀리식에서는 한 팀이 소유하고 관리할 수 있지만, 공유 모놀리식에서는 아무도 소유하지 않아 관리가 어려워짐.
-
마이크로서비스에 대한 토크
- 일반 기술 컨퍼런스에서 마이크로서비스 아키텍처의 복잡성과 부작용에 대한 여러 발표가 있었으나, 단순한 모놀리식 구축에 대한 발표는 없었음.
- David Schmitz의 마이크로서비스 실패에 대한 팁을 다룬 강연이 인상적이었으며, 그의 유머러스한 발표 방식이 매력적임.
-
인지적 편향과 단순성
- 사람들은 종종 무언가를 추가하는 것에 집중하며, 간단한 해결책을 간과함.
- 연구에서는 레고 구조물에 벽돌을 추가하는 대신 제거함으로써 문제를 해결하는 것이 더 나은 해결책임을 보여줌.
-
과도한 엔지니어링과 경험 부족
- 아키텍처는 "충분히 단순하면서 필요한 만큼 복잡해야" 하지만, 이를 달성하는 것은 경험이 필요함.
- IT 산업은 경험이 부족한 경향이 있으며, 경험은 시간이 걸림.
- 경험이 부족한 엔지니어와 관리자는 종종 불필요한 기술이나 메트릭스를 사용함.
-
일과 삶의 균형을 중시하는 회사
- 제품 개선에 집중하고 나머지 시간을 개인 생활에 할애하고 싶은 회사를 찾고 있음.
-
Dan Luu에 대한 개인적 경험
- Dan Luu는 블로그 팬과의 소통에 관대하며, 소프트웨어와 하드웨어 경계에 대한 전문 지식을 가지고 있음.
- 그의 통찰력과 전문성을 공유하는 데 아낌없으며, 그로부터 배우는 것은 매우 즐거운 경험임.
-
단순한 아키텍처의 중요성
- 대부분의 경우 필요한 아키텍처는 SSL 지원 로드 밸런서, 여러 앱 서버, 샤딩된 데이터베이스, 메시지 큐 등 기본적인 구성 요소임.
-
아키텍처와 엔지니어링 팀의 사회적 구조
- 아키텍처는 엔지니어링 팀의 사회적 구조를 반영해야 하며, 이를 고려하지 않으면 혼란과 비효율이 발생할 수 있음.
- 대규모 모놀리식 저장소와 단순한 아키텍처는 관리가 어려울 수 있으며, 구글과 메타와 같은 회사들도 내부적으로 많은 툴을 개발함.
- 아키텍처는 팀 간 협업을 지원하거나 방해할 수 있으므로, 기술 리더십은 이를 고려해야 함.
-
단순한 아키텍처의 선호
- 단순한 아키텍처와 모놀리식이 대부분 적합하지만, 동기식 IO로 인한 문제가 발생하지 않도록 주의해야 함.
- 데이터 무결성 버그는 금융 시스템에서 피해야 할 중요한 문제임.