SLASH23 - 새로운 은행을 위한 Modern 대외 연계 시스템 구축기

https://www.youtube.com/watch?v=eS9tukmYBLI&list=PL1DJtS1Hv1PiGXmgruP1_gM2TSvQiOsFL&index=24

 

토스뱅크의 Server Developer 이상민 님의 발표를 요약해 보겠습니다.

 

은행의 시스템 구조

 

채널계에서는 유저의 요청을 받습니다.

계정계에서는 은행에서 다른 은행으로 돈을 보내거나 대외기관을 통해 신용점수등을 조회합니다.

FEP는 Feont End Processor의 약자로 대외기관과 계정계가 통신할 때 사용됩니다.

 

 

FEP의 핵심 - 대외기관과 메시지 주고받기

FEP는 TCP로 세션 관리에 역할을 수행합니다.

대부분의 은행이 그래왔듯이 토스뱅크도 외부 업체가 만든 FEP 솔루션을 사용 중이었습니다.

 

FEP 단점 1 - 생산성 감소

솔루션에 의존적이기 때문에 ELK, Grafana, goCD등과 연동이 제한적이기 때문에 생산성이 줄어듭니다.

HTTP 일부기능 미지원

 

FEP 단점 2 - 안정성

토스뱅크 시스템은 물리적으로 분리된 Data Center 2개에 Active Active로 구성되어 있습니다.

하지만 FEP는 Active Standby로 구성되어 있었습니다.

 

또한 FEP는 제한적인 인스턴스로 서로 다른 도메인의 대외업무가 공유되므로 장애 도메인이 확산되는 문제를 가졌습니다.

 

하나의 대외업무에서 문제가 발생했을 때 인스턴스의 Blocking I/O로 인한 쓰레드 고갈이 발생할 가능성도 커지게 됩니다.

 

FEP 단점 3 - 유지보수

전문 인력만 FEP를 관리 유지보수할 수 있음

 

 

Modern 대외연계 시스템을 만들자

FEP와 대외기관의 통신은 전문이라고 부르는 Fixed Length Format으로 구성되어 있습니다.

TCP Body에는 Byte가 나열되어 있습니다.

 

전문설계서에 해당 내용이 정의되어 있고 내용을 토대로 Byte를 잘라서 파싱 할 수 있습니다.

이때 문자와 Byte의 매핑정보를 Charset이라고 부릅니다.

각 항목이 어떤 Charset으로 Encoding 된 것인지 알아야 하며 설계서에 해당내용도 주어집니다.

 

Kotlin으로 전문설계서를 매핑시키기

TelegramInterface를 활용하여 어노테이션을 정의합니다.

전문명, 대외업무명, 필드에 대한 내용, 전문명에 대한 어노테이션을 인터페이스로 정의합니다.

 

전문은 보통 HTTP Header와 같은 공통정보부 HTTP BODY와 같은 데이터부로 만들어집니다.

공통정보부는 대외기관별로 모두 동일하게 때문에 하나의 클래스로 전문명, 전문길이를 Class로 정의합니다.

 

공통정보부를 상속받고 데이터부에 대한 추가 내용을 정의하면서 전문내용을 모두 코드로 정의하였습니다.

 

전문 읽고 쓰기

Encode, Decode를 수행하는 컴포넌트를 Codec이라고 부릅니다.

 

Encode Codec 동작

정렬된 필드 얻기, 전문 정보를 습득하고 Charset에 따라 Encode, ByteArray에 쓰기

순서를 알기 위해서는 런타임에서 Annotation에 접근해야 하며 Reflection을 활용하여 접근할 수 있습니다.

 

 

Decode Codec 동작

Encode는 Reflection을 써서 Class 정보를 얻어왔는데 Decode시에는 Byte에서 어떻게 Class 정보를 얻을 수 있을까요?

공통정보부의 전문명을 별도의 Annotation으로 표현해 놓았기 때문에 전문명을 이용하여 전문 Class를 얻을 수 있습니다.

 

Reflections 서드 파티 라이브러리를 활용하여 특정 패키지에 있는 Class의 정보를 가져올 수 있습니다.

여러 개의 공통정보부의 모두 다 가져와서 지금 처리하는 대외업무명으로 필터링을 수행하면 원하는 공통정보부를 얻을 수 있습니다.

 

이제 대외업무명 -> 전문명을 통하여 필터링을 2번 수행해 주면 전문 Class를 찾을 수 있습니다.

 

 

전문 송수신하기

Agency는 대외기관을 뜻합니다.

이때 Blocking I/O를 활용하면 안정성에 동일한 문제가 생길 수 있습니다.

TCP구간에서는 Netty, HTTP 구간에서는 WebFlux, WebClient를 활용하여 Non-Blokcing 한 I/O를 사용할 수 있습니다.

 

Modern FEP Active- Active

토스뱅크의 클러스터는 물리적으로 2대로 분리되어 있습니다.

이때 FEP1에서 request를 보냈지만 FEP2에서 response를 받게 되면 Service는 Timeout를 만나게 됩니다.

 

FEP1로 응답이 오지 않는 이유는 TCP에는 요청, 응답의 개념이 없습니다.

요청 세션과 응답 세션을 분리해서 활용하고 있기 때문입니다.

 

이런 문제를 해결하기 위해서 Service에서는 Redis를 Polling 하면서 값을 읽어옵니다.

FEP는 요청을 받자마자 200 응답을 주고 TCP 요청을 수행합니다.

이후에 FEP2로 요청이 들어오게 됩니다.

Redis pus-sub을 활용할 수도 있지만 at-most-once이기 때문에 신뢰성을 위해 Polling을 사용합니다.

 

 

 

Modern FEP 제작의 핵심요소

• 기존에 잘 동작하였지만 더 나은 시스템을 향한 공감대
• 임팩트에 집중한 업무 문화
• 적극적인 협업과 지원