Open binchoo opened 9 months ago
kth990303
commented
8 months ago 이거 제가 정확하게 이해한게 맞는지 모르겠어서...
elasticache 또는 h2와 같이 인메모리 DB이나 클라우드 또는 네트워크 상으로 접근하는 속도 > 로컬 환경이지만 MySQL, PostgreSQL과 같이 i/o cost 존재하는 DB에 접근하는 속도
위 문구를 이렇게 이해하면 될까요?
맞다면 위 내용을 네트워크 i/o 비용 vs 디스크 i/o 비용로 이어서 연관지어도 괜찮은지도 궁금합니다!
binchoo
commented
8 months ago 네 짚어주셔서 감사합니다. 엄밀하게는 내부 네트워크 I/O 비용과 로컬 디스크 I/O 비용으로 생각하고 있었습니다.
2010 즈음 한 커뮤니티에서 비슷한 논의와 참고 자료를 확인해 봤는데요. 여기서 얻은 수치 비교입니다.
(A) + (B) = 10.74 ms 를 네트워크 비용이라고 했을 때 (D)처럼 하드디스크 기반이면 로컬 액세스 비용이 확연히 낮은 퍼포먼스를 보입니다만 (C)처럼 SSD 기반이라면 또 모를 일인 것 같습니다?
binchoo
commented
8 months ago (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 데이터 송수신 시간을 재는 방법은? |
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 이내 얘기하고 있습니다.
인스턴스 스토어는 일반 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를 읽거나 쓰기에 무리 없는 성능입니다.
*C타입이라 별로 같지만, I타입으로 가면 이론상 수치가 EBS 볼륨들을 훨씬 능가합니다. EBS라면 10ms 이내 라운드 트립과 대역에 따른 데이터 전송 속도도 고려해야 하죠.
연관 챕터
7
조사 내용
한편 네트워크는 다른 누군가의 메모리에 접근하는 속도가, 자체 디스크에 접근하는 것보다 더 빠를 정도로 충분히 빨라졌다.(p.99) 라는 한 줄이 인상 깊었는데요, 비교해 주는 벤치마크 수치를 리서치 해 두면 좋을 것 같아요.관련 논문 찾는 것 부터 시작해서, 없으면 테스트 해 보는 걸로요. 추후 아키텍처 결정에서 두고두고 참고하기 좋은 근거 자료가 될 것 같습니다.
@caffeine-library/readers-release-everything