웹 서비스 확장 전략
한 서버의 성능을 높이는 스케일업 작업은 한계가 있기때문에 분산 처리를 위해 여러 대의 서버들을 놓게 되는 스케일아웃(Scale-out) 작업을 하게 되는데,이 때 서버들로 대규모의 네트워크 트래픽 분산 처리하는 기술을 로드밸런싱(Load Balancing)이라고 합니다.
스케일업을 통한 확장
‘스케일 업’은 서버에 CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법을 의미합니다. 예를 들어, ‘1’의 처리 능력을 가진 서버 한 대를 ‘5’의 처리 능력을 가진 서버로 업그레이드시키는 것입니다. CPU나 RAM을 추가하기로 했다면 현재 서버에 추가 부품을 장착할 수 있는 여유 슬롯이 있어야 하며, 그렇지 않은 경우 서버 자체를 고성능으로 교체하는 것이 필요합니다. 스케일 업의 경우, 서버 한 대에 모든 부하가 집중되므로 장애 시 영향을 크게 받을 수 있는 위험성이 있습니다. 한 대의 서버에서 모든 데이터를 처리하므로 데이터 갱신이 빈번하게 일어나는 ‘데이터베이스 서버’에 적합한 방식입니다.
스케일아웃을 통한 서비스 확장
‘스케일 아웃’이란 서버를 여러 대 추가하여 시스템을 확장하는 방법입니다. 예를 들어, ‘1’의 처리 능력을 가진 서버에 동일한 서버 4대를 더 추가하여, 총 ‘5’의 처리 능력을 만드는 것입니다. 서버가 여러 대가 되기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 ‘로드밸런싱’이 필수적으로 동반되어야 합니다. 스케일 아웃의 경우, 서버 한 대가 장애로 다운되더라도 다른 서버로 서비스 제공이 가능하다는 장점이 있습니다. 반면 모든 서버가 동일한 데이터를 가지고 있어야 하므로, 데이터 변화가 적은 ‘웹 서버’에 적합한 방식입니다.
스케일아웃 시 배포방식
이전 버전을 blue 환경으로, 새 버전은 green 환경으로 부를 수 있습니다. 프로덕션 트래픽이 blue에서 green으로 완전히 이전되면 blue는 롤백에 대비하여 대기 상태로 두거나 프로덕션에서 가져온 후 업데이트하여 다음 업데이트의 템플릿으로 삼을 수 있습니다.
이와 같은 지속적 배포 모델에는 단점이 있습니다. 환경에 따라서는 업타임 요구 사항이 다르거나 blue-green과 같은 CI/CD 프로세스를 제대로 수행할 리소스가 없을 수도 있습니다. 그러나 애플리케이션을 지원하는 기업의 디지털 트랜스포메이션이 본격화되면서 많은 애플리케이션이 이러한 지속적 제공을 지원하도록 진화하고 있습니다.
서버 부하 분산을 위한 네트워크
서버: 무언가를 제공하느 대상 혹은 주체
부하: 트래픽이 몰려 Load가 오래 걸림
네트워크: 통신설비를 갖춘 컴퓨터를 이용해 서로 연결시켜주는 조직이나 체계
방화벽(firewall): 내부 시스템과 외부 시스템 간 필터링 기능을 수행하는 프로세스1) 외부에서 내부로의 접근 통제
2) 내부에서 외부로의 접근 통제(허용)
3) 외부의 특정사이트로만, 특정사이트에서 접근만 허용
4) 인터넷 서비스를 선별적으로 지원 등 통제
알아야 할 용어들
L2 스위치: OSI의 2계층에 속하는 장비, 일반적으로 부르는 스위치를 의미함. MAC주소(네트워크 어댑터의 고유번호)를 기반으로 프레임을 전송한다. 동일 네트워크끼리만 연결 가능함.
L3 스위치: OSI의 3계층에 속하는 장비, L2 스위치에 라우터 기능이 추가된 것으로, IP 주소를 기반으로 패킷을 전송한다. 서로 다른 네트워크 간의 연결이 가능함.
L4 스위치: OSI의 4계층에 속하는 장비, 로드밸런서가 달린 L3 스위치로, IP 주소 및 TCP/UDp를 기반으로 사용자들의 요구를 서버의 부하가 적은 곳에 배분하는 기능을 한다.
L7 스위치: OSI의 7계층에 속하는 장비, IP 주소, TCP/UDP 포트 정보에 패킷 내용까지 참조하여 세밀하게 로드밸런싱한다.
백본 스위치(Backbone Switch): 네트워크들을 연결하는 중추적 역할하는 네트워크를 백본(Backbone)이라 하고, 백본에서 스위칭 역할을 하는 장비를 백본 스위치라고 한다. 주로 L3 스위치가 백본 스위치의 역할을 하며, 대규모 트래픽 처리시 고성능의 백본 스위치를 사용해야 한다.
DMZ(demilitarized zone): 외부에서 DMZ는 자유롭게 들어올 수 있게 설정하고 외부에서 내부로는 못들어오게 필터링을 합니다. 또한 내부에서 외부나 DMZ로 가는 것은 자유롭게 설정을 합니다.
(실제 개발자가 신경써야하는 영역, DNS & Host 관리)
VIP(Virtual IP)는 하나의 호스트에 여러 개의 IP주소를 할당하는 기술이다. 이 기술을 이용하면, 하나의 네트워크 인터페이스에 여러 개의 IP 주소를 줄 수 있다. 바깥에서는 마치 하나 이상의 네트워크 인터페이스가 있는 것으로 보일 것이다.
VIP는 흔히 HA나 로드밸런싱을 위해서 널리 사용된다.
읽기 요청 부하 분산
API서버가 하나일 때는 요청이 들어왔을 때에 local cache에서 값을 저장했다가 같은 요청에 대하여 DB를 참조하지 않고 cache에 있는 값을 가져온다.
그렇다면 서버가 여러대 있고 각 서버에 대하여 각 요청 또한 각각의 cache에 저장되어 참조할 수가 없는 상황이 생긴거나 도중에 DB가 바뀐다면? 이럴 때는 아래와 같이 cache 서버를 새로 두어야한다.
DB증설 클러스터링, 레플리케이션
클러스터링(Clustering)
여러 개의 DB를 수평적인 구조로 구축하는 방식이다. 클러스터링은 분산 환경을 구성하여 Single point of failure와 같은 문제를 해결할 수 있는 Fail Over 시스템을 구축하기 위해서 사용된다.
장점
노드들 간의 데이터를 동기화하여 항상 일관성있는 데이터를 얻을 수 있다.
1개읜 노드가 죽어도 다른 노드르 통하여 시스템을 계속 장애없이 운영할 수 있다.
단점
여러 노드들 간의 데이터 동기화 시간이 있어서 Replication에 비해 성능이 떨어진다.
데이터를 나눠서 효율성을 성능증가!: 샤딩(sharding)
하나의 거대한 데이터베이스 테이블을 수평 분할(Horizontal Partitioning)하여 여러 개의 작은 단위로 나눈 후, 물리적으로 다른 위치에 분산하여 저장·관리하는 기술이다. 여러 서버에서 대규모 데이터베이스를 위한 비공유 파티셔닝 체계로 간단히 정의할 수 있어 새로운 수준의 데이터베이스 성능과 확정성을 달성할 수 있다. 수평 분할된 1개의 작은 테이블을 샤드(Shard)라고 하는데, 이 샤드를 여러 분산 서버에 분산시킨다.
레플리케이션(Replication)
단순히 확장만 하는 것이 아니라 메인으로 사용할 Master 서버와 이를 복제한 Slave 서버로 구성하게 된다. Master와 Slave로 구성된 구조를 자세히 살펴보면 Master 서버에는 INSERT, UPDATE, DELETE 작업이 전달되고 Slave 서버에는 SELECT 작업이 전달되는 것을 볼 수 있다. Slave는 결국 Master 서버에서 복제된 데이터이기 때문에 데이터의 조작이 발생할 수 있는 INSERT, UPDATE, DELETE 작업은 Master로 전달이 되고 조회만을 하는 SELECT 작업은 Slave 서버를 통하여 진행하게 된다. 그림에서는 Slave 서버가 하나뿐이지만 서비스에 맞게 Slave 서버를 여러 개 가져갈 수 있다. 데이터베이스에서 발생하는 대부분의 쿼리는 조회인 SELECT인데 이러한 것을 Slave 서버틀 통해 분산처리하여 성능 향상을 야기한다.
장점
DB 요청의 60~80% 정도가 읽기 작업이기 때문에 Replication만으로도 충분히 성능을 높일 수 있다.
비동기 방식으로 운영되어 지연 시간이 거의 없다.
단점
노드들 간의 데이터 동기화가 보장되지 않아 일관성있는 데이터를 얻지 못할 수 있다.
Master 노드가 다운되면 복구 및 대처가 까다롭다.
출처: https://mangkyu.tistory.com/97 [MangKyu's Diary]
https://tecoble.techcourse.co.kr/post/2021-09-18-replication_clustering/
https://moaimoai.tistory.com/75
https://library.gabia.com/contents/infrahosting/1222/
https://red.ht/3kWZ6Em
https://bit.ly/3L4ItRV
'스프링 > cloud' 카테고리의 다른 글
| [스프링 클라우드] Ch03. API 게이트웨이 (0) | 2022.05.15 |
|---|---|
| [스프링 클라우드] ch02 스프링 클라우드 소개 (0) | 2022.05.13 |