10월 30일 (수)에 우아한형제들 컨퍼런스 우아콘 2024를 다녀왔다!

이에 대해서 느낀 점들을 기록해보려고 한다.

🚪 신청 및 입장

우아콘은 사전 신청을 받은 후에, 일부 신청자들에 한해서만 입장권을 제공해줬다. 그래서 나는 떨어져서 슬펐는데.. 🥲 큐시즘을 함께 하는 친구가 고맙게도 양도를 해줘서 갈 수 있었다!

위치는 삼성역 그랜드 인터컨티넨탈 서울 파르나스 호텔 내부였다! 호텔에서 하는 건 몰랐는데.. 그래서 그런지 시설이 너무 좋아서 놀랐다.

오전 10시부터 시작이었는데, 아침에 일어나기가 너무 힘들어서 키노트는 듣지 못 하고 두 번째 세션부터 들을 수 있었다. 요즘 컨퍼런스를 자주 다녀서 일주일에 한 번은 코엑스를 가는 것 같은데 너무 멀다 🤣

입장해서 이름표를 받은 후에 세션에 입장할 수 있었다!

그럼 이제부터 세션 내용 정리와 느낀 점들을 대해 적어보도록 하겠다.

🧑🏻‍🏫 세션

1. 배달의민족 API 게이트웨이 - 권용근님

  • 프론트 서버 != API Gateway
  • MSA에서 도메인드링 분할되면서 발생하는 문제를 프론트 서버가 해결해 줌

Conway’s law

  • 조직의 비즈니스 영역 -> 하나의 마이크로 서비스로 구성
  • Reverse Conway's law도 적용 가능

횡단관심사 문제

  • 서비스 간을 횡단
  • 인증, 보안, 탄력성 등..
  • 유지보수 비용 증가되는 문제 발생
  • 서비스가 성장할 수록 더욱 문제가 커짐 -> MSA를 사용하기 위해서는 해당 문제를 반드시 해결해야 한다

API Gateway

  • 단일 처리
  • API Gateway Pattern과는 다름!
  • 특정 비즈니스를 수용할 수 없다 -> 어느 하나의 비즈니스에 종속되면 안됨

배달의민족 API Gateway

  • Scalable하게 -> 필요시 인프라가 허용되는 한에서 확장 가능
  • 스프링 클라우드 게이트웨이 사용
  • 별도의 커스텀 필터체인 만들어 사용
    1. 라우팅 서비스 결정 2) 필터 서비스 결정

사용중인 기능

  1. 인증 필터를 통해 인증 관련 횡단관심사 문제 해결
  2. 라우팅
  3. 보안 : 어뷰징과 같은 보안적 문제를 하나의 프론트 서버에서 해결
  4. 흐름제어 : 1) Rate Limiting 2) Circuit Breaker

Rate Limiting : 서버가 특정 임계치까지만 클라이언트의 요청을 허용하는 정책 링크 Circuit Breaker : 장애가 발생한 서비스에 대한 접속 차단을 자동화하는 것 링크

인증 서비스 : 단일실패지점 (SPOF)

단일 장애점은 시스템구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소를 말한다. 링크

  • 배달의 민족은 로그인이 필요한 서비스, 서비스가 확장되면서 인증 서비스에 의존하는 서비스들이 늘어남

<정리> 첫 번째 세션에서는 배달의 민족에서 API Gateway를 어떻게 사용하고 있는지를 알 수 있었다. 우선 유사한 이름이지만 근본적으로 다른, 1) API Gateway 2) API Gateway Pattern의 차이점에 대해 알려주셨다. 그리고 MSA 구조에서 발생할 수 밖에 없는 횡단관심사 문제를 언급하시며 이를 어떠한 방법들로 해결했는지를 이어서 말씀하셨다. 배달의 민족에서는 API Gateway를 Scalable하게 사용하고 있으며, 별도의 커스텀 필터체인을 만들어서 사용한다고 한다. 또한 스프링 클라우드 게이트웨이를 사용하는데, 여기서 인증 필터, 흐름제어(Rate Limiting, Circuit Breaker) 기능 등을 활용하고 있다고 한다.

<느낀 점> 🧑🏻‍💻 아직 API Gateway에 대해서는 얕게만 알고 있는 상태인데, 구조적으로 조금 더 이해할 수 있어서 좋았던 것 같다. 또한 API Gateway와 API Gateway Pattern의 차이점에 대해서 알 수 있어서 더 유익했던 것 같다! 👍🏻

2. Kafka를 이용하는 메시지 플랫폼에서 장애를 겪으며 아키텍처를 개선한 이야기 - 허창오, 김동환님

  • 작년, 올해 41건의 장애 발생 (외부 장애가 70%)

아키텍처 개선을 결심하게 된 장애

  • 작년 발생한 3건의 큰 장애
  • 특정 파티션의 컨슘 중단

kafka Exactly Once

  1. 멱등성 Producer : 중복된 메시지를 막음
  2. Transaction
  • 유지 비용 절감을 위해 제거하기로 결정

중복 제거를 위한 노력

  • Redis로 캐싱
  • API 요청이 들어오면 해시값 생성 -> Redis로 캐싱하며 요청 중복 제거
  • Redis에 부하가 와서 롤백 진행

3배 트래픽을 위한 여정

  • 초기에는 파티션 수를 3배로 늘려 해결하려 했음 -> 하지만 이것이 답이 아닌 걸 알게 됨
  • 더 적은 수의 파티션으로 더 많은 트래픽을 받아야 했음

1) 아웃라이어 제거

  • 15분 이상 미응답 -> 리밸런싱 발생
  • FCM Timeout 처리를 해도 똑같은 문제가 발생
  • 별도로 TimeLimiter를 적용함 Sender <-> TimeLimiter <-> FCM

2) 동시 처리량 증가 : 비동기 전환

  • 일시적인 실패에 대해서는 Dead Letter에 넣은 후, 나중에 다시 보내는 방식
  • 역할에 따른 스레드 풀 분리
  • 실시간성, 배치성, 광고성

3) 불필요한 카프카 요청 제거

4) 배치 리스너 적용

  • 메시지 수만큼 커밋이 발생
  • 비동기 처리하므로 1번의 커밋으로 전환

결과

  • 파티션 수 720개 -> 100개
  • 2배 트래픽 최대 1분 이내 지연 발송까지 확인

<정리> 두 번째 세션에서는 kafka 메시지 플랫폼에서 발생하는 장애들을 해결하기 위해서, 아키텍처를 개선한 스토리에 대해 들을 수 있었다. 외부 장애가 70%이기는 하지만 2년 간 41건의 장애가 발생을 하였고, 특히 작년 3건의 치명적인 장애로 인해서 당시의 아키텍처 구조를 개선해야겠다는 판단을 했다고 한다. 기존에는 Kafka Exactly Once 기능을 사용했었지만, 이를 제거하기로 결정을 했고, Redis로 캐싱을 해 보는 등의 노력이 있었다. 그러던 중 어느 날 3배의 트래픽을 받을 수 있게 해달라는 요청이 들어왔으며, 심지어 파티션 수를 늘려서 해결할 수도 없는 구조였다. 때문에 아웃라이어 제거를 위해 별도의 TimeLimiter를 만들어 적용하고, 비동기 전환, 배치 리스너 적용 등을 적용하며 결과적으로 파티션 수를 100개까지 줄일 수 있었다고 한다.

<느낀 점> 🧑🏻‍💻 Kafka를 프로젝트에서 한 번 사용을 해봐서 그나마 조금이라도 이해를 할 수 있었던 것 같다. 이렇게 기업에서 발생하는 장애를 개선하는 스토리를 들으며 느끼는 점은, 동일한 기술이어도 이를 어떻게 적용하느냐에 따라 결과가 천차만별이라는 것이다. 그러니 꼭 어려운 기술을 사용하는 것이 중요한 게 아니라, 하나의 기술에 대해 깊이 이해하고 이를 현재 상황에 맞춰 적재적소에 사용할 수 있는 능력을 갖추는 게 더 중요할 듯 하다! Kafka에 대한 다양한 용어 및 기술, 그리고 해결 방법에 대해 자세히 들을 수 있어서 재미있는 세션이었던 것 같다 👍🏻

3. 장애 같은데? 일단 STOP! : 배달 서비스 장애감지/차단 시스템 구축 경험담 - 김지언, 천은정님

딜리버리프로세싱팀

  • 고객이 배민 앱에서 주문하는 상품을 고객의 문 앞까지 전달하는 배달 과정의 백엔드 시스템을 담당

장애 조치 시간 단축을 위한 해결 방안 3가지

1. 빠른 이상상황 감지

2. 즉각 조치

3. 효율적인 커뮤니케이션

어떻게 해결할까?

  • 예시 : 도요타 생산공장 : 안돈시스템
  • 공정별 품질 상태를 알리는 품질 관리 시스템
  • 안돈시스템 컨셉을 적용해 보자!

개념 및 판단 기준 정의

1. 이상상황 감지 -> 사람이 개입해서 판단해야 함

2. 품질 기준 지표는 뭘까?

  • 구간 간 전환 실패 또는 지연이 발생하면, 고객에게 좋은 배달 경험을 제공할 수 없다
  • 실시간 배달 건 별로 적합/부적합 여부를 검사
  • 부적합한 배달 건들을 모아서 카운팅
  • 해당 지표의 급증 지점을 모니터링하며 시스템 이상상황을 감지함 -> 얼마나 급증하면 이상상황일까? -> 수치가 많이, 빠르게, 연속적으로 증가한다면 장애

필요한 것들을 더 고민해보자

  1. 우리가 만든 기준을 계속 모니터링할 필요는 없을까?
  2. 시스템이 선조치 했는데, 다시 복구하려면 어떻게 해야 하지?
  3. 변경된 장애프로세스를 어떻게 유관 부서와 연결 짓지?

이상상황 감지 이후 프로세스

  • 이상상황 감지 -> 주문 유입 조절 -> 유관부서와 담당자에게 해당 내용 공지 -> 이후 대응 매뉴얼 제공

원하는 결과를 얻었을까?

  • 자동화 프로세스로 1분 이내에 처리할 수 있었음
  • 하지만 즉시 대응하지 못 한 경우 -> 주문량 조절로 인해서 사업적 손해를 볼 수도 있었음
  • 그래서 선조치가 맞을까? 하는 고민이 발생
  • 선조치를 하지 않았다면 주문이 취소될 수도 있는 심각한 문제가 될 수 있기에, 고객 경험을 우선시하는 초기의 생각을 바꾸지 않기로 결정함

이렇게 해결했어요!

  • 옵스지니라는 툴을 연동하여, 담당자 호출 체계를 강화함
  • 장애 여부 판단 지표를 정의함
  • 모니터링 대시보드 구축
  • 역할 재분배

과제를 진행하면서 배운 것

  1. 부담감을 책임감으로 승화시키기
  2. 본질이 무엇인가?를 끊임없이 고민하기
  3. 넓은 시각으로 프로덕트를 바라보기
  • 계속 질문을 통해 우리만의 정답을 찾아 나가보려 한다!

<정리> 세 번째 세션에서는 배달 서비스 과정에서 장애가 발생하는 경우, 이를 감지하고 차단하는 시스템을 구축한 경험에 대해 들을 수 있었다. 딜리버리프로세싱팀에서는 배달 과정의 백엔드 시스템을 담당하는 팀이다. 배달 과정에서 문제가 생겼을 때 빠르게 감지하고 즉각 조치할 수 있도록, 도요타 생산공장의 안돈시스템 컨셉을 적용해보고자 했다고 한다. 이를 위해서 부적합한 배달 건을 집계하며 모니터링을 진행했고, 어떤 때에서 장애라고 판별할 수 있는지 기준을 잡았다. 그렇게 시스템을 구축해 둔 후, 실제로 장애가 발생해서 이를 이전과 대비해 빠르게 처리할 수 있었다. 하지만 선조치 이후 담당자가 연락을 바로 받지 못 하게 된다면, 주문량 유입 조절로 인해서 사업적인 문제가 발생할 수도 있었다. 때문에 이를 해결하기 위해서 옵스지니라는 툴을 연동해 메인 담당자가 연락을 받지 못 하면 서브 담당자에게 연락을 취하고, 모니터링 대시보드를 구축하는 등 조치 이후 프로세스를 보완했다고 한다. 해당 과정을 통해서 본질이 무엇인가?에 대해서 끊임 없이 고민해야겠다는 생각을 했고, 앞으로도 질문을 통해 우리만의 정답을 찾아 나가보려고 한다고 말씀하셨다.

<느낀 점> 🧑🏻‍💻 세 번째 세션은 서버가 아닌 PM의 트랙에 참여하게 되었다. 개인적으로 문제를 해결하고 그 과정에서 느낀 점을 듣는 것이 재미있어서 자주 듣게 되는 것 같다. 이번에는 어떠한 시스템을 구축하는 데 있어서 PM들을 어떤 생각들을 가지고 있는지, 또 어떤 점들을 중요한 가치로 삼고 진행하는지를 들을 수 있었다. 특히 선조치 프로세스가 맞을지에 대해 고민을 한 후에, 본질은 고객 경험을 우선시 하는 것임을 다시 상기하며 초기 생각한 프로세스를 고수한 점이 인상 깊었던 것 같다. 생각한 대로 일이 흘러가지 않을 때, 본질을 잘 생각하지 못 하고 상황에 맞춰 바꿔버리는 경우가 많은데, 그렇게 되면 정체성을 잃을 수 있다고 생각한다. 가까운 거리에서 재미있는 이야기를 들을 수 있었던 것 같아서 좋았고, 나도 일이 잘 되지 않을 때 항상 본질은 무엇인지에 대해 떠올려보아야겠다는 생각을 했다 👍🏻

4. DDD 그거 그렇게 하는 거 아닌데 - 박재성님

도메인 주도 설계

  • 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 다양한 원칙과 패턴
  • 개념적 기반은 객체지향과 애자일

완벽한 설계

  • 완벽한 설계란 존재하지 않는다.
  • 요구 사항은 끊임없이 변화하고 있으며 기획자조차도 이를 완벽하게 파악하지 못한다.

유비쿼터스 언어

  • 클래스나 함수의 이름을 짓기가 어렵다 -> 유비쿼터스 언어를 도입한다
  • 개발자만 영문 이름을 고민해야 하는 것은 아니다
  • 바운디드 컨텍스트 내에서만 정의할 필요는 없다
  • 한글, 영문 이름을 모두 정하고 용어 사전에 기록한다

용어 사전

  • 살아있는 문서로 만들기 위해, 프로젝트에 리드미 파일로 유지 관리한다
  • 용어도 코드 리뷰 대상이다
  • 회의 & 기획 & 디자인 & 개발 등 프로젝트의 모든 곳에서 이를 사용하도록 노력한다

인수 테스트

  • 고객, 개발자, 테스터가 함께 작성하는 테스트
  • 고객의 관점에서 소프트웨어가 어떻게 작동해야 하는지를 고려한다

비즈니스 도메인

  • 소프트웨어로 해결하고자 하는 문제 영역
  • 소프트웨어를 사용하는 사용자의 활동이나 관심사와 관련
  • 다른 산업 내에서 발생하는 다양한 비즈니스 문제를 해결한다는 점에서 독특함

바운디드 컨텍스트

  • 바운디드 컨텍스트 : 특정 도메인 모델이 적용되는 경계를 정의하는 개념
  • 컴퓨터에서 가장 기본적인 알고리즘인 분할과 정복 활용
  • 팀이 이미 분리되어 있다면? -> 콘웨이의 법칙
  • 팀이 아직 분리되어 있지 않다면 -> 역콘웨이의 법칙

콘웨이의 법칙 : 소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다. 역콘웨이의 법칙 : 어떤 점에서는 개발자도 마이크로서비스와 같을 것이라는 것을 의미한다. 링크

복잡성을 제어하는 것이 소프트웨어의 본질

은총알은 없다

  • 생산성, 신뢰성, 단순성을 10배 이상 향상시킬 발전은 나타나지 않을 것이다
  • 링크

결론

  1. DDD는 개발자만이 소프트웨어 개발에 참여하는 사람이 아니라는 점을 상기시켜준다
  2. 좋은 DDD는 “DDD에서는”으로 시작하지 않는다
  3. DDD는

추천 도서

  1. 소프트웨어 장인
  2. 팀 토폴로지
  3. 소프트웨어 아키텍처 101

<정리> 네 번째 세션에서는 도메인주도 설계와 관련한 내용들을 들을 수 있었다. 도메인 주도 설계란 무엇인지 그 본질에 대해 알 수 있었던 것 같다. 또한 유비쿼터스 언어, 즉 팀원들이 모두 이해하고 사용할 수 있는 언어를 도입하는 것에 대해 말씀해주셨다. 보통 개발자만 패키지, 함수, 변수명 등을 고민하곤 하는데, 그럴 필요가 없이 함께 고민해야 한다고 하셨다. 이를 용어 사전에 정리를 해둔 후에, 회의 & 기획 & 디자인 & 개발 등 프로젝트 모든 곳에서 이를 사용하도록 노력한다고 한다.

<느낀 점> 🧑🏻‍💻 DDD에 대해서 들을 수 있는 시간이었는데, 아직 공부해 본 적이 없어 명확히 이해하지는 못 한 듯하다. TDD, DDD는 중요한 아키텍처이기에 다음에 꼭 공부해보아야겠다는 생각이 들었다. 특히 유비쿼터스 언어와 용어 사전 부분이 흥미로웠는데, 생각해 보면 왜 개발자만 이러한 영문 이름을 고민해야하지? 라는 생각이 들었다. 최근에도 프로젝트를 하면서 기획 & 디자인이 사용하는 용어와 내가 사용하는 영문 용어가 달라서 이를 맞추느라 고민했던 적이 있었다. 때문에 이를 용어 사전으로 한 곳에 정리해 두고 팀원 다같이 이를 맞춰 사용한다면 훨씬 빠르게 이해할 수 있지 않을까라는 생각이 들었다. 아직 고민은 조금 더 해보아야겠지만, 실제로 프로젝트에 적용해 보고 싶은 새로운 부분들을 들을 수 있어서 좋았던 것 같다 👍🏻

5. 200여 개의 백오피스에 인증/인가, 컴플라이언스 적용하기 - 이현재님

  • 우아한 형제들 사내 백오피스 개수는 206개

문제점

  1. 컴플라이언스 관리의 어려움
  2. 동일 기능 중복 개발
  3. 사용자의 사용 경험 저하

인증

  • 1인 1계정 발급, 비밀번호 작성/변경 규칙, 로그인 만료 정책 등..
  • 로그인 화면을 1개로 통일시킴

SSO (Single Sign On)

  • SAML, OIDC 프로토콜로 보통 해결할 수 있는 문제
  • 인증 기능 (w/ SSO, 2FA …) 지원, 컴플라이언스 관리

정책과 권한

  • 정책 : 사용자가 수행할 수 있는 행위 (HTTP API)

  • 권한 : 정책의 그룹

URL Base로 접근 제한

  • 자원 + 행동을 가장 잘 구현할 수 있는 것이 API (Path + Method)

<정리> 우아한형제들 사내 백오피스 개수는 206개로 많은데, 기존에는 각각 모두 분리되어 있었기 때문에 이를 관리하고 개발하는 데 어려움이 있었다. 때문에 로그인 화면을 1개로 통일하는 등 여러 방법으로 개선을 진행했다. 특히 다른 방식이 아닌 URL Base로 접근 제한을 하였는데, 왜냐하면 자원과 행동을 가장 잘 구현할 수 있는 것이 API 방식이기 때문이다. (자원은 Path로, 행동은 Method로) 이에 대한 권한 관리는 1) 정책과 2) 권한으로 나누었는데, 정책은 사용하가 수행할 수 있는 행위, 즉 HTTP API 목록을 보여주며, 권한은 정책을 그룹화하여 나눈 것이라고 볼 수 있다.

<느낀 점> 🧑🏻‍💻 마지막 세션으로는 백오피스에 인증/인가, 컴플라이언스를 적용하는 내용을 들을 수 있었다. 백오피스라는 용어는 처음 들었는데 어드민이라고 생각하면 될 듯하다. 또한 컴플라이언스도 처음 들었는데, 법규 준수 시스템이라는 뜻으로 회사가 자발적으로 관련 법력을 준수하기 위해 위험을 통제하고 사전 조치를 취하는 행위나 정책이라고 이해하면 될 것 같다. 해당 세션에서는 실제로 우아한 형제들의 백오피스가 어떻게 생겼는지, 어떻게 정책과 권한을 관리하고 있는지를 알아서 신기하고 흥미로웠던 것 같다! 최근 들어 Spring Security를 공부하며 보안 및 인증인가에 관심이 조금 더 생긴터라 더욱 재미있게 들을 수 있었다 👍🏻

🛍️ 기타 볼거리 및 굿즈

기타 볼거리

세션 외에도 볼만한 것들이 많았다!

이렇게 다양한 이벤트나 네트워킹을 할 수 있는 공간들도 있었으며,

배달의 민족 쇼핑 앱은 어떠한 알고리즘으로 구축되었는지도 볼 수 있었다.

그리고 배달의 민족에도 이제 AI를 도입하려고 하는 듯 한데, 간단하게 체험해 본 후에 2천원 상품권을 받을 수 있었다! 방금 잘 사용했다 ㅎㅎ

굿즈

입장할 때 위와 같이 굿즈들이 담긴 파우치를 받을 수 있었다!

내부 구성은 티셔츠, 팜플렛, 쿠키, 스티커가 있었다! 스티커도 나름 귀엽고, 티셔츠도 편해서 집에서 개발할 때 애용하려 한다 🧑🏻‍💻

💡 느낀 점

  1. 우아한 형제들이 돈을 많이 벌었구나…컨퍼런스 장소가 너무 좋았던 것 같다. 알아보니 작년에도 동일한 곳에서 했다고 한다! 의자들도 편했고 내부가 쾌적해서 세션에 잘 집중할 수 있었던 것 같다.
  2. 인원이 많은데도 통제가 잘 되었던 것 같다. 스태프나 세션 강연자 등 모두 일을 깔끔하게 하는 것 같다는 인상이 들었다.
  3. 트랙이 다양했고, 다른 트랙에 가서 자유롭게 들을 수 있어서 좋았던 것 같다! 계속해서 기술적인 이야기만 듣다 보면 힘이 들 수 있어서.. 중간에 한 번 환기하면서 재미있게 들을 수 있었다.
  4. 네트워킹, 멘토링, 이그나이트 트랙 등 참여하지는 못 했지만 참가자들이 참여할 수 있는 여러 장치들을 마련해둔 것 같아서 준비를 잘한 것 같다는 생각이 들었다.
  5. 우아한 형제들, 배달의 민족에서는 어떠한 기술들을 사용하고 어떤 식으로 문제를 해결하고 있는지 들을 수 있어서 재미있었다. 생각한 것보다 훨씬 스케일이 컸기에, 내 생각보다 더 큰 기업이구나라는 걸 깨닫을 수 있었다.