[aws] aws클라우드 아키텍처 구성

업데이트:

안녕하세요!👋
오늘은 aws클라우드 아키텍처 구성과 분산시스템 그리고 왜 분산을 하였는지에 대해 이야기하겠습니다

🙏요약

aws클라우드 아키텍처 구성에 대해 알아봅시다.

  1. 말선생 프로젝트의 aws클라우드 아키텍처

📝말선생 프로젝트의 aws클라우드 아키텍처

말선생 프로젝트는 제가 소프트웨어 마에스트로 과정에서 진행했던 프로젝트 인데요 좀더 자세히 알고싶으신 분들은 제 깃허브를 참고해주세요

제가 프로젝트를 하며 구성했던 aws클라우드 아키텍처 구조와 왜 이렇게 구성했는지 이야기해보려 합니다.
image
aws환경에서 클라우드를 구성하는 방법은 이후 글에서 자세히 설명하도록 하겠습니다.

이번에는 왜 이렇게 구성했고 어떠한 점이 좋은지 말씀드리도록 할게요

  • public 과 private subnet

    public과 private subnet을 나누었습니다 AZ를 나누어 2개씩 구성하였죠 이렇게 구성한 이유는 db에 바로 접근할 수 잇는 WAS나 분석 서버등을 외부로부터 보호할수 있기 때문입니다.

    public에는 nginx와 같은 webserver만을 놔두고 private에는 public에서 구성한 webserver를 통해서만 접근할 수 있는 WAS(django)서버를 구성하였습니다.

    또한 이 방식을 통해 서버의 스케일 아웃이 정말 간편해 졌습니다.

    그저 private subnet에 ec2를 하나 더 생성하고 git pull한 후 webserver에서 하나 더 연결만 해주면 서버 증설이 끝나게 되죠 물론 k8s등을 통해 자동으로 할 수도 있지만 시간적,금전적 비용이 많이 들게 됩니다.

    저는 이와같이 서버가 눈에 딱 들어오고 안전하며 확장성이 있는 서버를 구성하기 위해 public과 private를 나누어 서버를 구성하였습니다

  • 서버 분산과 로드밸런싱

    로드밸런서를 사용하여 각 AZ별 public subnet에 요청을 분산하였습니다.

    각 웹서버가 받는 부하가 분산되는 효과도 있지만 중요한 것은 하나의 AZ가 마비되어 서버가 꺼지더라도 다른 서버에서 동작할 수 있도록 서버를 구성하였다는 것입니다.

    적어도 2개는 필수적이라고 생각하고 있습니다. 또한 private subnet의 WAS서버도 2개로 분산하여 public의 양쪽 웹서버에서 나오는 부하도 분산하여 각각 받도록 구성하였습니다.

    이와같이 구성한 이유는 위의 이유와 같이 부하를 분산하는 것, 한 AZ의 서버가 꺼지더라도 동작하는 것도 중요하지만. WAS서버의 경우 수정사항이 많기 때문에 배포부분에서도 이유가 있습니다.

    수정된 코드를 배포할 때 한 서버를 끄고 배포하는 롤링 배포 방식을 보통 사용하게 되는데 이때 서버가 종료되지 않도록 두개의 서버를 구성하였습니다

    이와같은 이유로 서버를 분산하여 여러개를 구성하였고 로드밸런싱을 했습니다 aws 구조도에 대한 자료가 많지만 제 구조가 이 글을 보는 분들에게 도움이 되었으면 좋겠습니다

    ‘다음 글은 jmeter를 사용한 서버 부하 분산테스트에 관한 글을 올릴 예정입니다’

긴글 봐주셔서 항상 감사합니다 앞으로도 유용한 내용을 많이 공유하겠습니다 그럼 안녕 👋

댓글남기기