대규모 서비스를 지탱하는 기술 - 규모 조정의 요소

규모 조정의 요소

여는 글

서비스의 흥행으로 이용량이 증가하게 되면 시스템의 확장이 필요해진다. 그렇다면 시스템의 확장을 위한 방법에는 어떤 것이 있을까?

스케일 업(scale-up) vs 스케일 아웃(scale-out)

스케일 업(scale-up)

스케일 업은 서버의 하드웨어 스펙을 올리는 것을 말합니다.

예를 들어, CPU 1 core, Memory 1 GB 인스턴스를 CPU 4 core, Memory 4 GB로 올리는 것을 말합니다.

스케일 업에는 두 가지 유의사항이 있습니다.

첫 번째는, 성능 향상에 들어가는 비용이 정비례 하지는 않는다는 점 입니다.

위 사진과 같이 16배의 성능 향상을 위해서는 기존 대비 비용이 30배 이상 들어갈 수 있습니다.

두 번째는 물리적인 한계점 입니다. 물리적으로 메인보드에 꼽을 수 있는 CPU와 메모리 카드의 개수는 제한되어 있으며 AWS에서 제공되는 인스턴스 유형 또한 상한이 있습니다.

그런데 스케일 아웃은 위와 같은 2가지 유의사항을 극복할 수 있는 확장 방법입니다.

스케일 아웃(scale-out)

스케일 아웃은 동일한 스펙의 장비를 여러 대를 추가하고 이들 장비 간에 부하를 분산하는 방식을 말합니다. 그래서, 스케일 업보다 비용 적으로 좀 더 저렴하게 성능을 늘리는 것이 가능합니다.

이에 더하여, 운영 중인 장비의 수가 늘어난 만큼 일부 인스턴스가 죽더라도 서비스는 중단되지 않습니다.

한 대로 운영 되던 인스턴스가 여러 대로 늘어남에 따라 유의해야할 사항이 있습니다.

첫 번째는, 늘어난 인스턴스에게 부하를 나눠줄 부하 분산 장비가 필요 해진다는 점입니다. L4/L7 스위치나 AWS의 ELB 등 부하를 나눠줄 장비가 필요해지고, 이 장비들 또한 이중화를 통해 가용성을 높여주어야 합니다.

두 번째는, 상태에 대한 전략을 정해야 한다는 점 입니다. stateless한 서비스를 운영하거나, stateful한 서비스를 운영하되 WAS 혹은 Redis를 통한 session clustering이나 L4를 통한 sticky-session 등을 통해 상태를 유지하기 위한 방법을 고민 해야합니다.

위 두 가지 유의사항 때문에 비용적인 이점이 상쇄될 수 도 있을것 같습니다.

스케일 아웃해서 서비스 하다보면 사용량이 많은 10 ~ 16시에는 인스턴스를 많이 운영하고 그 외에는 인스턴스를 최소 숫자만 운영하고 싶다는 생각이 들 수 있습니다. 이러한 니즈를 위해서 Amazon EC2 Auto Scaling이 있습니다.

Amazon EC2 Auto Scaling

앞서 위에서 설명한 바와 같이 평시에는 최소한의 숫자만 운영하다가 CPU, Network IO 증가와 같은 특정 상황에만 인스턴스를 추가해서 운영하고 싶을 때 사용할 수 있는 것이 Amazon EC2 Auto Scaling 입니다

Amazon EC2 Auto Scaling의 구성요소

위와 같은 구성요소를 통해 관리자의 니즈에 맞춰 원하는 댓수만큼의 인스턴스를 운영할 수 있습니다.

EC2 외에도 DynamoDB Auto Scaling, Aurora Auto Scaling, Elastic Container Service Auto Scaling 도 있습니다.

규모 조정의 요소

 

일반적으로 서비스는 위 사진과 같은 3 tier 구조와 비슷한 경우가 많습니다. 그 중에서 AP 서버는 CPU 부하가 많고 DB는 IO 부하가 많습니다. 그래서 하드웨어/인스턴스 유형을 선정할 때도 이러한 특성을 고려해서 선정하는 것이 좋습니다.

CPU 부하가 많은 AP 서버는 stateless 하다면 큰 고민없이 운영 대수만 늘리더라도 부하를 분산해서 커버하는 것이 가능합니다.

하지만 DB는 확장이 어렵습니다.

DB 확장의 어려움

DB 확장의 어려움은 디스크 IO 부하, 복제란 2가지 관점에서 볼 수 있습니다.

첫 번째는 디스크 IO 부하입니다.

DB는 데이터의 저장과 조회가 디스크를 통해 이뤄지는 만큼 디스크 IO가 많은데 디스크는 다른 하드웨어 구성요소 중에서 가장 느립니다. 그래서 데이터가 커져서 메모리에서 처리 못하고 디스크 상에서 처리할 수 밖에 없게 될 수도 있습니다. 그래서 가능한 메모리에서 처리할 수 있도록 하는 방법을 고민해야 합니다.

두 번째는 복제입니다.

데이터베이스의 일관성이 유지되려면 데이터베이스간에 복제도 원활히 이뤄져야 합니다. 복제에는 여러 전략이 있는데 리더 없는 복제, 단일 리더 복제, 다중 리더 복제 등이 있으며 이 복제도 동기 복제와 비동기 복제가 있습니다.

예를 들어, 특정 리더 노드가 모든 쓰기를 맡고 이를 여러 팔로워에게 복제하는 단일 리더 복제의 경우 복제가 동기로 이뤄지면 리더 노드에 장애가 발생하더라도 팔로워가 대체할 수 있지만, 비동기로 복제가 이뤄지면 일관성이 떨어질 수 있습니다.

복제에 대한 자세한 내용은 각 복제 전략의 특성과 현실 예시를 통해 다른 글에서 다뤄봐도 좋을 것 같습니다.

이 처럼 시스템에서 해당 데이터베이스가 맡는 역할에 따라 확장시 고려해야할 사항이 많습니다.

참고 자료

• 쉽게 설명하는 AWS 기초 강좌 12 - EC2 Autoscaling(오토스케일링): https://www.youtube.com/watch?v=Mkr0PxydGSE
• 데이터 중심 애플리케이션 설계 - 복제 : https://johngrib.github.io/wiki/study/ddia/05-replication/
• Amazon EC2 Auto Scaling: https://aws.amazon.com/ko/ec2/instance-types/?trk=68913a17-4967-41f6-a766-0f2eb338dd04&sc_channel=ps&s_kwcid=AL!4422!3!588924203019!e!!g!!ec2&ef_id=Cj0KCQjw54iXBhCXARIsADWpsG-zLgcE6vVc8PWtaOgJATlT0vxYmgZd3Pw9UWoR6TWZZLDvzjvHl3oaAmRnEALw_wcB:G:s&s_kwcid=AL!4422!3!588924203019!e!!g!!ec2
• Amazon EC2 Auto Scaling: https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
• Clustering vs Replication vs Sharding: https://jordy-torvalds.tistory.com/entry/Clustering-vs-Replication-vs-Sharding