클라우드 아키텍처의 설계 원칙

클라우드 아키텍처의 설계 원칙 4가지

1. 장애 대비 설계

구성 요소가 어떻게 실패를 일으키는지 파악하고, 실패를 중심으로 설계하여 복원력을 더할지 고려

예) 단일 서버에서 실행 가능한 애플리케이션을 구축하되 서버를 2대 이상 사용하는 것.
      단일 서버의 장애를 고려하여 아키텍처 설계

 

2. 모놀리스 아키텍처와 대비되는 분리된 구성 요소 

• 모놀리스 아키텍처란 모든 프로세스가 밀결합되거나 연결되어 단일 서비스로 실행되는 경우
• 모놀리스 아키텍처는 애플리케이션의 프로세스 하나에 대한 수요가 급증하면 전체 아키텍처를 확장해야 한다.
• 모놀리스 아키텍처는 상호 연결성 수준이 높기 때문에 개선하고 업데이트하기가 훨씬 어렵다.

ex) 다른 애플리케이션 구성 요소를 데이터베이스에서 분리하면 각각의 개별적 수요에 따라 크기를 조정하고 관리할 수 있게 된다. 그래서 다른 애플리케이션 구성 요소에 장애가 발생해도 데이터베이스에 곧바로 장애가 발생하지 않음. 

 

3, 온프레미스와 대비되는 클라우드에서의 탄력성 구현

• 탄력성은 클라우드에서 구축하는 일반적인 이유이다.
• 온프레미스 환경에서는 현재 배포한 수준을 넘어 수요가 증가할 경우 추가 수요를 관리하기 매우 어렵다.
• 또한, 수요가 줄어들면 사용되지 않는 용량 때문에 비용이 낭비된다.
• AWS Cloud에서 수요를 기반으로 용량을 동적으로 변경할 수 있다. 

 

4, 병렬 처리 고려

• 직렬 및 순차적 처리는 밀결합된 모놀리스 아키텍처와 비슷하게 대단히 제한적이다.
• 종속성 때문에 전체 프로세스가 실행되거나 중단될 수 있고 이 체인에 장애가 발생하면 전체 작업이 실패한다.
• 병렬처리는 작업을 가장 간단한 형식으로 나눈 다음 이 부하를 여러 구성 요소에 분산해 수요를 처리하는 것을 말한다.
• 모든 요청을 순차적으로 처리하는 서버에 갑자기 많은 요청이 들어오면 서버는 제한된 수의 요청만 처리할 수 있다.
• 장애는 아니더라도 요청 하나가 서버를 잡아두고 있다면 모든 후속 요청은 대기해야 한다. 
• 더 나쁜 경우 관리 가능한 부하 수준이 될 때까지 처리가 거부된다. 
• 이를 수정하는 방법은 서버를 확장한 다음 로드 밸런서 같은 요소로 요청을 여러 서버에 분산하는 것.
• 그러면 서버는 나머지 요청을 대기시키지 않고 처리 가능

 

---

문제 예시

Q, 다음 중 AWS Cloud 아키텍처 설계 원칙은 무엇입니까?

a. 단일 장애 지점 구현
b. 느슨한 결합 구현
c. 모놀리식 설계 구현
d. 수직적 크기 조정 구현