SLASH21 #토스 서비스를 구성하는 서버 기술

컨퍼런스 내용 요약과 새롭게 찾아본 내용 정리

Opening keynote

토스는 송금뿐 아니라 보험, 금용, 투자등 금용회사로 변모, 사용자 1800만

토스팀에서는 성취를 느낄수 있다. 사용자들의 입장에서 불편함을 해결하기 위해 모든 기술적인 역량을 집중한다.

토스 컨퍼런스에서 고객만족을 위해 토스팀의 엔지니어들이 문제를 해결하기위한 과정을 확인 할 수 있다.

토스 서비스를 구성하는 서버 기술

Data Center x 2(Active - Active) + AWS 일부 서비스

Active - Active?

L4 스위치등 로드밸런싱을 통해 기능이나 성격에 따라 두개의 서버중 한곳에서 처리하도록 한다 이후 DB에 접근할때도 2개 이상의 서버를 사용

Active-Standby도 서버를 이중화 해서 구성하지만 동시에 부하분산을 통해 모든 기기에 서비스하는게 아니라 장애시 서비스를 이전하여 운영하는 형태

쿠버네티스 a.k.a K8s?

• 컨테이너화된 서비스를 관리하기 위한 확장 가능한 오픈소스 플랫폼(구글이 만듬)
• Go 언어로 구현, 도커 뿐만 아니라 rkt, Hyper container등 다양한 컨테이너 엔진을 지원

가상화 단계별 요약

 1. 기존에는 운영체제에 여러 어플리케이션을 올려서 사용함
 2. 가상화 도입되고는 가상화된 OS위에서 각 VM간 app을 격리하여 사용 리소스 관리가 용이해 졌으나 각 가상 머신은 OS를 독자적으로 운용한다
 3. VM과 유사하지만 app간 OS는 공유한다. 자체 파일 시스템, cpu 점유, 메모리 등이 있다.
 - 기민한 생성과 배포, 개발과 운영의 분리, 이식성, 애플리케이션 중심 관리

컨테이너수가 적으면 VM 확장시 직접 배포하면 되지만 무수히 많은 컨테이너를 관리하기 위해서는 어디에 배포할지 결정이 필요 각 컨테이너마다 필요한 사이즈가 다르기 때문에 최적화도 필요, 컨테이너의 동작 체크도 필요

• 확장성, 유연성, 이식성
• 쿠버네티스는 시스템의 카나리 배포를 쉽게 관리
• 현재상태를 모니러팅하면서 관리자가 설정한 상태의 값과 다르면 설정한 값으로 바꿔줌

Canary 배포?

롤링 배포 - 단순하게 서버를 구성하여 배포하는 전략, 구 버전에서 신 버전으로 트래픽을 점진적으로 전환하는 배포

블루 그린 - 신 버전을 배포하고 일제히 전환하여 모든 연결을 신 버전을 바라보게 함 빠른 롤백이 가능하고 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신 버전 테스트 가능 하지만 두배로 시스템 자원이 필요

카나리 배포 - 지정한 서버 또는 특정 User에게만 배포했다가 정상이면 전체를 배포한다 서버의 트래픽 일부를 신 버전으로 분산

지능형 라우팅과 분산 트렌젝션 로그 추적을 하는 기능들이 Envoy 라는 솔루션으로 나오고 이를 중앙 통제하기 위한 Istio.io 와 같은 서비스 메쉬 솔루션 까지 나오기에 이르렀다.

Istio?

Istio는 애플리케이션 네트워크 기능을 유연하고 쉽게 자동화할 수 있는 투명한 언어 독립적 방법을 제공하는 현대화된 서비스 네트워킹 레이어인 서비스 메시입니다. 클라우드 기반 애플리케이션을 구성하는 다양한 마이크로서비스를 관리하는 데 널리 사용되는 솔루션입니다. Istio 서비스 메시는 또한 이러한 마이크로서비스가 서로 통신하고 데이터를 공유하는 방법을 지원합니다.

조직이 클라우드로의 이동을 가속화하면서 필요에 따라 애플리케이션도 현대화하고 있습니다. 그러나 모놀리식 레거시 앱을 클라우드 기반 앱으로 전환하면 DevOps팀에 문제가 발생할 수 있습니다.

개발자는 클라우드에서 이동성을 보장하기 위해 느슨하게 결합된 마이크로서비스를 사용하여 앱을 어셈블하는 방법을 학습해야 합니다. 동시에 운영팀은 점점 더 커지는 하이브리드 및 멀티 클라우드 환경 내에서 새로운 클라우드 기반 앱을 관리해야 합니다. Istio를 사용하면 이러한 작업을 수행할 수 있습니다.

Istio는 애플리케이션 코드를 변경할 필요 없이 서비스 간 트래픽 흐름을 관리하고 액세스 정책을 적용하며 원격 분석 데이터를 집계합니다. Istio는 기존의 분산형 애플리케이션에 투명하게 레이어링하여 배포 복잡성을 완화합니다.

Envoy?

기존의 대표적인 프록시 솔루션으로는 nginx, haproxy, apache 서버등이 있는데, 이러한 프록시들은 보통 TCP/IP 레이어에서 L4 로 작동을 하였다. 이보다 복잡한 라우팅 요건이 필요해서 HTTP URL에 따른 라우팅 등.. L7 프록시가 필요하게됨

Istio의 메인 프록시인 Envoy Proxy

MSA시장이 커지면서 서비스들은 네트워크를 통해 서로 통신해야했고, 이러한 서비스에서 사용하는 핵심 네트워크 프로토콜은 HTTP, HTTP/2, gRPC, Kafka, MongoDB등의 L7프로토콜입니다.

HTTP L7 라우팅 지원을 통한 URL 기반 라우팅, 버퍼링, 서버간 부하 분산량 조절등

트래픽을 한쪽으로 옮기는 이유?

• 장애가 났을때 해결보다는 복구에 집중, 장애가 없는 데이터 센터로 트레픽 전환

• 장애 여파를 줄이기 위해 트래픽을 한쪽으로 옮기고 설정 변경후 트래픽을 점진적으로 늘려나간다

19년도에서 dc/os -> 쿠버네티스로 전환

쿠버네티스 전환할때 Istio도 같이 전환, Istio가 프록시로 container로 붙어서 개별 어플리케이션에서 처리하는 일을 infra로 전환

service에 sidecar로 붙어서 실행된다. 네트워크 문제에 대해 통계적인 자료를 제공한다

route의 weight로 1% canary 가능

서비스에 대한 응답을 일부로 지연시켜 서비스 test가능

Spring WebFlux?

web-flux는 client, server에서 reactive 스타일의 어플리케이션 개발을 도와주는 모듈

개발자는 Reactive Stack 를 사용할지, Servlet Stack 를 사용할지 선택을 해야 한다. 두개의 stack 을 동시에 사용할 수 없다.

Publisher 의 구현체인 Mono와 Flux 를 활용하여 데이터를 발행하는 객체를 만들고 Controller 로 리턴을 하면 Spring 에서 알아서 subscribe 하도록 되어 있다.

Webflux 는 Asynchronous Non-blocking I/O 을 방식을 활용하여 성능을 끌어 올릴 수 있는 장점이 있다. 그런데 이 말은 즉, Non Blocking 기반으로 코드를 작성해야 한다.

신기술이라고 무조건 적용하는게 아니라 명확한 문제 정의 후 선행된 기술 도입