들어가며안녕하세요, 당근페이 머니서비스팀에서 백엔드 엔지니어로 근무 중인 윌리엄(William)이에요. 머니서비스팀에서는 사용자들에게 가치 있는 금융 서비스를 제공하기 위해 다양한 은행 및 카드사와 제휴를 맺어 금융 프로덕트를 만들고 있어요. 최근 출시한 당근머니 체크카드가 대표적인 사례예요.이번 글에서는 제휴업체 연동 과정 중 TCP 통신을 사용하게 된 배경과 당근페이에서 TCP 연동을 안정적으로 수행할 수 있었던 과정을 소개해 드리려고 해요. TCP 통신에 대해 궁금하거나 연동을 준비하고 계신 분들에게 제 글이 조금이라도 도움이 되었으면 좋겠어요.제휴업체 연동당근페이 머니서비스팀은 은행, 카드사, VAN사 등 다양한 대외기관과 통신해요. 지금까지는 HTTP와 JSON 포맷으로 통신해 왔기 때문에 큰 어려움 없이 외부와의 연동 작업을 진행했어요.하지만 제휴를 맺는 과정에서 HTTP가 아닌 TCP 프로토콜로 통신해야 하는 제휴업체들이 생겨났어요.TCP 방식의 통신은 이제껏 사용해 오던 HTTP 방식과 통신 인터페이스가 많이 다르기 때문에 별도의 개발이 필요했어요. 구체적으로 어떤 부분이 다른지 살펴볼게요.TCP 통신 방식TCP 통신은 주로 전용선에서 전문을 주고받는 방식으로 이루어져요.전문의 개념과 형태전문이란 서버와 클라이언트가 주고받을 데이터의 포맷을 정해두고 고정된 길이의 데이터 패킷을 송수신하는 것을 의미해요. 전문은 보통 ‘공통부’와 ‘개별부’로 나누어져 있는데요. 하나의 대외기관에서는 동일한 공통부를 사용하면서 전문의 목적에 맞게 개별부를 나누어 사용해요.이해를 돕기 위해 간단한 전문 명세서를 작성해 봤어요.계좌 잔액조회 전문 (전문코드: 2000, 전문길이: 50, 인코딩 방식: ASCII)위 같은 전문 명세서에는 각각의 필드들이 고정된 크기와 순서로 정의되어 있어요.공통부의 크기는 항상 고정되어 있기 때문에 정해진 크기만큼의 공통부를 먼저 읽어 해석해요. 공통부의 ‘전문구분코드’를 통해 어떤 개별부를 사용했는지 판단하는 거죠. ‘전문구분코드’에 맞는 개별부를 찾았다면, 개별부의 전문 크기만큼 나머지 바이트 배열을 읽으면서 전체 전문을 해석할 수 있어요.공통부 전문 예시를 보면서 전문을 읽고 해석하는 방식에 대해 알아볼게요. 공통부 예시 : 0x32303030303030303031 바이트 배열을 하나씩 해석해 보면, 아래와 같은 정보를 도출해 낼 수 있어요.나머지 개별부에 대해서도 위와 같은 방식으로 해석이 가능해요.전문 통신 방식이제 전용선에서 전문을 송수신하는 방식을 살펴볼게요. TCP 통신은 대외기관에 따라 “동기방식”과 “비동기방식”을 나누어서 사용해요.동기방식: HTTP 통신방식과 비슷하게 클라이언트에서 요청을 보낼 때 세션을 생성하고, 서버는 요청받은 세션에 응답을 내려주는 방식이에요. 클라이언트가 응답을 받으면 사용한 세션은 종료돼요.비동기방식: 서버와 클라이언트가 약속된 개수의 세션을 미리 생성하고 연결을 계속 유지시켜 두는 방식이에요. 클라이언트는 맺어진 세션 중 하나의 세션에 요청을 보내고, 응답받을 서버

확장성 있는 TCP 통신 시스템 구축하기들어가며안녕하세요, 당근페이 머니서비스팀에서 백엔드 엔지니어로 근무 중인 윌리엄(William)이에요. 머니서비스팀에서는 사용자들에게 가치 있는 금융 서비스를 제공하기 위해 다양한 은행 및 카드사와 제휴를 맺어 금융 프로덕트를 만들고 있어요. 최근 출시한 당근머니 체크카드가 대표적인 사례예요.이번 글에서는 제휴업체 연동 과정 중 TCP 통신을 사용하게 된 배경과 당근페이에서 TCP 연동을 안정적으로 수행할 수 있었던 과정을 소개해 드리려고 해요. TCP 통신에 대해 궁금하거나 연동을 준비하고 계신 분들에게 제 글이 조금이라도 도움이 되었으면 좋겠어요.제휴업체 연동당근페이 머니서비스팀은 은행, 카드사, VAN사 등 다양한 대외기관과 통신해요. 지금까지는 HTTP와 JSON 포맷으로 통신해 왔기 때문에 큰 어려움 없이 외부와의 연동 작업을 진행했어요.하지만 제휴를 맺는 과정에서 HTTP가 아닌 TCP 프로토콜로 통신해야 하는 제휴업체들이 생겨났어요.TCP 방식의 통신은 이제껏 사용해 오던 HTTP 방식과 통신 인터페이스가 많이 다르기 때문에 별도의 개발이 필요했어요. 구체적으로 어떤 부분이 다른지 살펴볼게요.TCP 통신 방식TCP 통신은 주로 전용선에서 전문을 주고받는 방식으로 이루어져요.전문의 개념과 형태전문이란 서버와 클라이언트가 주고받을 데이터의 포맷을 정해두고 고정된 길이의 데이터 패킷을 송수신하는 것을 의미해요. 전문은 보통 ‘공통부’와 ‘개별부’로 나누어져 있는데요. 하나의 대외기관에서는 동일한 공통부를 사용하면서 전문의 목적에 맞게 개별부를 나누어 사용해요.이해를 돕기 위해 간단한 전문 명세서를 작성해 봤어요.계좌 잔액조회 전문 (전문코드: 2000, 전문길이: 50, 인코딩 방식: ASCII)위 같은 전문 명세서에는 각각의 필드들이 고정된 크기와 순서로 정의되어 있어요.공통부의 크기는 항상 고정되어 있기 때문에 정해진 크기만큼의 공통부를 먼저 읽어 해석해요. 공통부의 ‘전문구분코드’를 통해 어떤 개별부를 사용했는지 판단하는 거죠. ‘전문구분코드’에 맞는 개별부를 찾았다면, 개별부의 전문 크기만큼 나머지 바이트 배열을 읽으면서 전체 전문을 해석할 수 있어요.공통부 전문 예시를 보면서 전문을 읽고 해석하는 방식에 대해 알아볼게요. 공통부 예시 : 0x32303030303030303031 바이트 배열을 하나씩 해석해 보면, 아래와 같은 정보를 도출해 낼 수 있어요.나머지 개별부에 대해서도 위와 같은 방식으로 해석이 가능해요.전문 통신 방식이제 전용선에서 전문을 송수신하는 방식을 살펴볼게요. TCP 통신은 대외기관에 따라 “동기방식”과 “비동기방식”을 나누어서 사용해요.동기방식: HTTP 통신방식과 비슷하게 클라이언트에서 요청을 보낼 때 세션을 생성하고, 서버는 요청받은 세션에 응답을 내려주는 방식이에요. 클라이언트가 응답을 받으면 사용한 세션은 종료돼요.비동기방식: 서버와 클라이언트가 약속된 개수의 세션을 미리 생성하고 연결을 계속 유지시켜 두는 방식이에요. 클라이언트는 맺어진 세션 중 하나의

토스의 백엔드로 오는 요청은 모두 Spring Cloud Gateway 기반의 API Gateway를 통해 클러스터로 들어와요. 그리고 클러스터 안에서는 수많은 서버들이 Spring WebClient를 통한 REST API로 통신해 요청을 처리해요.최근 두 가지 도구에서 동일한 Memory Leak 이슈를 경험했는데요. 원인이 같았습니다. 문제 원인을 찾은 과정과 그 내용을 공유드릴게요어느 날 한 게이트웨이로부터 OOMKilled 알림을 받았습니다. OOMKilled 알림은 OS가 프로세스를 죽였다는 알림인데요. 해당 컨테이너에 지정된 메모리 상한을 컨테이너가 사용하는 총 메모리가 초과했음을 뜻해요. 죽은 게이트웨이에는 최근에 변경된 사항이 없었고, 게이트웨이가 OOM으로 죽은 적이 처음이라 의아한 상황이었어요. 그래서 하나하나 증거를 살펴보기로 했습니다.우선 컨테이너가 OOMKilled로 죽었다는 것은 JVM에서 일반적으로 사용하는 Heap 영역의 문제일 가능성이 거의 없습니다. 토스에서는 메모리 할당에 드는 오버헤드를 최대한 줄이기 위해 JVM 옵션을 사용하고 있는데요. 이 옵션을 사용하면 어플리케이션 부팅 시 Heap 영역만큼의 메모리를 미리 할당하고 시작하기 때문입니다. 그래서 일반적으로 토스의 서버들은 RSS 메모리 지표가 부팅할 때를 제외하고는 큰 변화가 없습니다.하지만 이번에 OOM으로 죽은 서버의 residential set size (RSS) 메모리 지표를 살펴보면 변화가 있었을 뿐 아니라 꾸준히 우상향 중이었습니다. 여기서부터는 JVM heap 영역이 아닌 native 영역의 메모리를 사용하는 부분을 샅샅이 뒤져 범인을 찾아야 합니다. 하지만 문제가 된 게이트웨이는 JNI나 JNA같이 native 영역의 메모리를 쓰는 곳은 없어서 어디에서 문제가 발생했는지 바로 알기 어려웠습니다.한 가지 더 이상한 점은 한 쪽 데이터센터의 게이트웨이만 RSS가 증가한다는 것이었습니다. 토스는 안정적인 서비스 운영을 위해 Active-Active 구조로 이중화 된 데이터센터를 구축하고 있기 때문입니다. 이런 상태에서는 대부분의 트래픽이 양쪽 데이터센터에 1:1의 비율로 인입되는 게 정상입니다.게이트웨이 접근 로그를 통해 확인해보니, 특정 라우트에 대한 요청은 RSS 지표가 우상향하는 데이터센터로만 인입되고 있었습니다. 그리고 그 라우트에서 다른 라우트에는 없는 필터가 있는걸 확인했습니다. 필터였는데요. 캐시로 인한 memory leak. Spring Cloud Gateway에서 기본으로 제공하는 필터지만 이게 범인일 가능성이 크겠다는 생각이 들었습니다.그래서 Spring Cloud Gateway Github을 살펴보니 관련된 수정 사항을 확인할 수 있었습니다. 요청 바디를 캐싱한 후 이 메모리를 제대로 해제하지 않아 memory leak이 발생한 것이었습니다. 그리고 위 수정은 캐싱된 메모리를 제대로 해제하도록 수정한 내용이었어요. 관련 내용이라는 생각이 들어 그 수정사항이 반영된 버전을 사용해봤더니 native memoery leak이

안녕하세요, DevOps 팀의 Sammie입니다. Hyperconnect에서는 대부분의 service workload를 AWS 위에서 운영하고 있고, 다른 모든 회사와 동일하게 AWS 비용 절감은 중요한 주제입니다. AWS 비용을 절감할 수 있는 항목을 찾던 중, AWS Graviton Processor를 발견했습니다. Graviton2 instance는 기존 Intel 계열 (5th generation) instance와 비교하여 가격이 20% 정도 저렴하며, 최대 40% 더 빠르다고 홍보[1]하고 있었습니다. 정말로 가격대비 성능이 40% 향상되었는지는 실험 전까지는 알 수 없으나, 동일 CPU core당 가격이 저렴하기 때문에 일단 개발 환경부터 도입해 보기로 했습니다.몇몇 managed service와 workload를 migration 해봤고, 적어도 성능이 더 나빠지지는 않았으므로 대부분의 production workload을 Graviton으로 migration 하기로 하고 다양한 작업을 진행했습니다. 그 결과, 2022년 5월 전까지만 해도 회사 전체에서 ARM64 사용 비중은 거의 0%였지만, 2023년 5월 기준 EC2 instance 요금의 47% 이상을 차지할 정도로 빠르게 전환하여 많은 비용을 절감할 수 있었습니다.이번 글에서는 Kubernetes 위에서 작동하는 100개 이상의 microservice를 ARM64로 migration 했던 작업에 초점을 맞춰 긴 여정을 소개하려고 합니다. 전반적인 process, Kubernetes의 Node와 각종 system component를 ARM64로 전환하는 과정, AMD64와 ARM64 이미지를 동시에 build 하기 위해 CI/CD pipeline을 어떻게 수정했는지, 그리고 실제 이전하면서 문제가 되었던 것을 설명해 드리겠습니다.본격적으로 migration 과정을 설명하기에 앞서, ARM64와 Graviton processor에 대한 간략한 소개와 migration을 진행한 이유를 설명하겠습니다. ARM64는 cpu archicture의 한 종류로, Intel과 AMD에서 사용하는 ADM64 archicture 대비 전력 소모면에서 강점을 가집니다. 따라서, ARM64는 주로 mobile 환경에서 사용되었으며, 지난 2018년 re:Invent에서 ARM64 기반의 Graviton processor와 2019년 12월 Graviton2 processor를 발표한 이후 서버 시장에서도 유의미한 비중을 차지하게 되었습니다.Graviton processor의 장점은 다음과 같습니다.• Graviton processor를 사용하는 c6g, m6g, r6g 등의 instance는 Intel 기반 c5, m5, r5보다 20% 저렴합니다.• 일부 workload에는 40% 더 뛰어난 가격 대비 성능을 보여준다고 합니다. 물론 각 workload 특성에 따라 성능 향상의 수준은 달라지므로 stage 환경에서 load-test를 해보거나, production에 도입하기 전까지 얼