성능¶
10G 트래픽 송출이 가능한 서버를 위한 고려사항은?¶
Hint
디스크 I/O와 HIT율에 따라 다릅니다.
100% 히트율만 생각한다면 8코어에 16GB 메모리로도 10G는 서비스 가능합니다. 하지만 현실적으로 각 서버구성요소(CPU, 메모리, NIC)를 가성비 관점에서 구성하시는 것이 좋습니다.
서비스 구성을 결정짓는 가장 어려운 점은 디스크 I/O입니다.
메모리 캐싱은 99% HIT 되는 콘텐츠 서비스를 위해 다다익선입니다.
공용팜 수준으로는 12~16코어, 32GB이상, SSD 5장 정도가 보편적인 수준으로 판단됩니다.
여기에 콘텐츠가 커질수록 디스크가 추가되며, 디스크 I/O가 높아지면 메모리가 추가됩니다.
압축, 암호화, 이미지처리 등 부가 함수가 붙게되면 CPU가 추가되는 것이 패턴입니다.
Note
예를 들어 1천만장의 이미지를 동시에 서비스하는 상황이라면 메모리를 32GB를 두어 메모리 인덱싱 속도를 높이고, SSD를 5장 정도 DAS형태로 구성하면 충분합니다. 이런 식이면 99% 이미지는 메모리에서 서비스되고 1%의 이미지만 디스크에서 로딩하게 되어 품질이 좋아집니다.
반면 동영상이나 게임 서비스 같은 경우 콘텐츠가 집중되는 서비스라면 디스크 랜덤접근이 줄어듭니다. 다만 콘텐츠 크기가 워낙 크니 디스크가 10장 이상 구성되는 경우도 있습니다.
UDS (Unix Domain Socket) 지원이 되나요?¶
Hint
지원되지 않습니다.
기술적 관점의 이유는 아래와 같습니다.
UDS는IPC(Inter Process Call)중 가장 빠른 방법으로 널리 알려져 있으나, 우리가 다루는 문제가IPC가 아님에 주목할 필요가 있습니다. 일반적으로 IPC의 경우 작고 빈번한 메시지 또는 1:1의 대규모 전송 상황을 가정하는 경우가 많습니다. 이는M2가 가정하는 서비스 환경과 큰 차이가 있다고 볼 수 있습니다.Redis benchmark 를 참고하면
UDS와Loopback Socket의 차이는 미비합니다.UDS의 성능이점은 많이 통신하고 데이터가 클수록 사라지는 경향이 있습니다. 심지어 여기서도 가장 가혹한 환경이 100byte로 1Gbps 수준이지만 우리는 보통 10Gbps에 100KB부터 10GB 까지 예측할 수 없는 페이로드를 다룹니다.네트워크 프로그래밍 자료를 찾다보면 여전히 15년 전 글들이 유효한 것처럼 돌아다는 것을 보곤 합니다. 10년이 넘는 기술지원을 통해 Linux TCP/IP 커널의 성능향상을 해마다 체감하곤 합니다. 업계에 오래 계셨던 분들이라면 Cent 7이 나왔을 때 Apache 성능이 최소 5배 가량 향상되었던 경험이 있으실 것입니다. Linux TCP/IP 커널에 기대는 편이 성능향상에 유리하다고 판단하고 있습니다.
솔루션 정책적 관점의 이유도 있습니다.
서비스 종단에 있는 솔루션이라면
UDS등 다양한 동작방식을 제공할 수 있다고 생각합니다. 하지만 M2 는 중간에 있는 솔루션입니다. 즉 서버의 입장뿐만 아니라 클라이언트의 입장도 있게 되는데 양쪽 소켓을 브릿지하는 경우도 있습니다. 이때 서버 세션과 클라이언트 세션의 관리방법이 다를 경우 예측할 수 없는 문제가 발생할 수 있습니다.M2는 기능적으로 재귀 세션이 사용됩니다. M2도 내부 구현적으로 여러 함수를 연결하고 분산하며 사용하는데 이때 원본에 대한 위치투명성을 가지게 됩니다.
UDS는 원본서버에 접속할 수 없으니 위치투명성을 확보할 수 없게 됩니다.