[additional] 메모리를 네트워크로 접근 vs. 로컬 디스크를 접근하기 속도 비교

[binchoo]

연관 챕터

#7

조사 내용

한편 네트워크는 다른 누군가의 메모리에 접근하는 속도가, 자체 디스크에 접근하는 것보다 더 빠를 정도로 충분히 빨라졌다. (p.99) 라는
한 줄이 인상 깊었는데요, 비교해 주는 벤치마크 수치를 리서치 해 두면 좋을 것 같아요.

관련 논문 찾는 것 부터 시작해서, 없으면 테스트 해 보는 걸로요. 추후 아키텍처 결정에서 두고두고 참고하기 좋은 근거 자료가 될 것 같습니다.

---

@caffeine-library/readers-release-everything

[kth990303]

이거 제가 정확하게 이해한게 맞는지 모르겠어서...

elasticache 또는 h2와 같이 인메모리 DB이나 클라우드 또는 네트워크 상으로 접근하는 속도 > 로컬 환경이지만 MySQL, PostgreSQL과 같이 i/o cost 존재하는 DB에 접근하는 속도

위 문구를 이렇게 이해하면 될까요?

맞다면 위 내용을 네트워크 i/o 비용 vs 디스크 i/o 비용로 이어서 연관지어도 괜찮은지도 궁금합니다!

[binchoo]

네 짚어주셔서 감사합니다. 엄밀하게는 내부 네트워크 I/O 비용과 로컬 디스크 I/O 비용으로 생각하고 있었습니다.

2010 즈음 한 커뮤니티에서 비슷한 논의와 참고 자료를 확인해 봤는데요. 여기서 얻은 수치 비교입니다.

• 네트워크가 디스크보다 이제 빠른가요?
• Designs, Lessons and Advice from Building Large Distributed Systems by Dr. Jeff Dean
  ㄴ 이걸 이미지로 쉽게 비교해 준 Gist: https://gist.github.com/l2dy/924a4650422ae762d26f97596a01fb0a

• 1MB 데이터를 기준으로 봤을 때
  • (A) 데이터센터 라운드 트립: 500 마이크로 초 = 0.5 ms
  • (B) 1Gbps 대역 네트워크에서 전송 속도: 10,240 마이크로 초 = 10.24 ms
  • (C) SSD 순차 액세스 = 1 ms
  • (D) HDD 순차 액세스 = 20 ms

(A) + (B) = 10.74 ms 를 네트워크 비용이라고 했을 때
(D)처럼 하드디스크 기반이면 로컬 액세스 비용이 확연히 낮은 퍼포먼스를 보입니다만
(C)처럼 SSD 기반이라면 또 모를 일인 것 같습니다?

[binchoo]

PoC 계획

• 데이터 크기: 1MB
• 디스크 쓰기/읽기 성능을 n회씩 기록

(A) EC2(bash) <-> EBS (gp3)
(B) EC2(bash) <-> EBS (st1)
(C) EC2(bash) <-> EC2 instance store
(D) EC2(redis-client) <-> another EC2(redis-server)

고민하기

	고민	해법
1	gp3, st1 볼륨 처리량은 얼만큼 설정해야 하나?	인스턴스 사양 내에서 IO 단위, IOPS, 처리량 성능을 구성하고 이론상 기대 시간을 계산해 둡시다.
2	EC2 인스턴스 스토어를 사용하기 위한 준비사항은?	NVMe 또는 일반 SSD인지 확인합니다. 블록 장치 경로 매핑이 필요할 수 있습니다.
3	1MB 더미 데이터를 디스크 및 레디스 서버에 저장시키는 방법은?
4	1MB 데이터 송수신 시간을 재는 방법은?

1. 볼륨 처리량 설정

EBS 볼륨 유형과 사양
EBS 최적화 인스턴스와 EBS 성능

gp3는 SSD 볼륨, st1은 HDD 볼륨입니다. 둘다 EC2와 네트워크로 연결되는 볼륨이기 때문에 다음 사항을 고려해야 합니다.

a. 인스턴스 타입: 결국 인스턴스의 네트워킹 지원이 EBS 최대 성능을 발목잡는 요인이 되어 제일 신경씁니다. 인스턴스 타입이 제공하는 네트워크 대역폭이 다릅니다. 또 EBS 전용 대역폭을 제공하는 EBS 최적화 유형도 있고요. 어떤 인스턴스는 하루에 30분만 최대 대역폭을 지원하고, 그외에는 쫀쫀따리 기준 대역폭으로 제공합니다.

지금은 EBS 두 개를 물릴 것이고 순차로 PoC 할 거라, 인스턴스 한계 내에서 볼륨 성능을 설정할 수 있습니다. EBS 최적화와 인스턴스 스토어를 지원하는 타입을 하나 선정해 볼게요.

➡️ c5d.large를 써볼까요?

• gp3를 3000 IOPS로 할당하면, 16KiB I/O Size x 3000 IOPS로 처리량 45.77MB/s를 활용 가능하네요. PoC인 1MB를 16KiB로 66번 I/O하는 데 무리가 없는 구성입니다. 3000 IOPS를 할당했으니 이론적으로 66/3000*1000 = 22ms에 처리되겠네요.

• st1을 할당하면, 1MB I/O Size x 500 IOPS = 500MB/s 활용이 가능한데요. 네트워킹 최대 대역폭이 593.75MB/s이니 무리 없어 보입니다. 당연히 PoC인 1MB를 1MB 크기로 1번 I/O 하는 데도 무리 없지요. 이론적으로 1/500*1000 = 2ms에 처리가 되겠네요.
  gp3 처럼 16KiB로 66번 I/O 시켜야 할까요? 그럼 시퀀셜 연산에 강한 HDD 사용 의미가 퇴색되는 것 같습니다. 굳이 2ms에 처리할 수 있는 거 132ms에 처리해야 할까용?

b. I/O할 블록 단위: 블록 단위는 IOPS와 곱해서 처리량이 됩니다. AWS가 제공한 처리량 기준이 gp3: 16KiB, st1: 1MB 이므로 이것을 기준으로 IO 하겠습니다. 실제 물리 계층에서 쓰는 블록 크기와 동일한지 미지수네요.

c. 네트워크 지연: EBS 공식 문서는 10ms 이내 얘기하고 있습니다.

2. 인스턴스 스토어 사용 준비

인스턴스 스토어 볼륨 유형
컴퓨팅 최적화 유형의 인스턴스 스토어 성능

인스턴스 스토어는 일반 SDD와 NVMe로 나뉩니다. 전자는 인스턴스를 띄울 때 별도로 경로를 잡아줘야 합니다. 인스턴스 스토어 활성 과정은 공식 메뉴얼을 참고합니다.

c5d.large는 NVMe이므로 별달리 구성할 내용은 없겠습니다. 또 인스턴스에 실부착되는 볼륨이라 네트워킹 영향도를 제외합니다.

• 4KB I/O Size * 20000 IOPS = 78.128 MB/s 읽기 처리량
• 4KB I/O Size * 9000 IOPS = 35.156 MB/s 쓰기 처리량

따라서, 4KB 블록을 256번 IO하여 1MB를 읽거나 쓰기에 무리 없는 성능입니다.

• 256/20000*1000 = 12.8 ms
• 256/9000*1000 = 28.44 ms

*C타입이라 별로 같지만, I타입으로 가면 이론상 수치가 EBS 볼륨들을 훨씬 능가합니다. EBS라면 10ms 이내 라운드 트립과 대역에 따른 데이터 전송 속도도 고려해야 하죠.

3. 더미 생산 및 저장

공식문서 EBS 볼륨 벤치마킹