아마존 클라우드 | AWS Essential 7강 탄력성 있는 구현
본문
※ 영상을 선명하게 보기 안내
- 유튜브 영상에서 오른쪽하단에 톱니바퀴를 클릭합니다.
- 팝업목록에서 "품질" 선택하세요.
- 원하는 해상도를 선택해주세요.
※ 모바일에서 Wifi가 아니라면 데이타가 소진될 수 있으니 주의바랍니다.
아마존 클라우드님의 AWS 클라우드강의 청각장애인을 위한 자막

이번 차 시에서는 탄력적인 구성 방법 중에서 컴퓨트 영역의 구성
방법에 대해서 이해 하실 수가 있습니다.
그리고 탄력적인 코드 레벨에서 배포 방법에 대해서도 이해하실 수가
있습니다.
그 다음에 관리 영역에서 탄력적으로 운영할 수 있는 방안에 대해서 이해할
수 있습니다.
그래서 첫번째로 aws 컴퓨팅 영역에서 탄력성을 가져올 수 있는
방안에 대해서 말씀드리도록 하겠습니다.
첫번째로 가장 많이 쓰는 1나 스틱 로드 밸런서 라고 하는 컴퓨팅 영역을
탄력적으로 가져올 수 있게 하는 네트워크 부하 분배기를 이루어질 수가
있는데요
네트워크 프와 분배기를 통해서 네트워크 트래픽을 높게 탄력적으로 그리고
높은 가용성 으로
이스트 인스턴스 앞단에 서 트래픽을 효율적으로 분산 시켜주는 서비스 라고
볼 수 있습니다.
여러 인스턴스 앞에서 실제로
빌라 스팅 로드 밸런서 가 존재하고 있구요.
2 1st 로드 밸런서 를 통해서 써 비스트 입히기 의미 되구요.
그 유입이 되는 트래픽을
이스트 인스턴스의 http 프로토콜의 잇던 혹은 tcp 의 특정
프로토콜을 통해서 보낼 수 있게 됩니다.
이렇게 트래픽을 자동으로 라우팅을 하여서 실제로 웹 서비스가
여러대가 있을거구요 이 여러 대중의 한대가 장애가 발생하더라도 시체로
여러분들 서비스 에 서비스 창이 스킬 되지 않도록 서비스를 설계 하실 수
있습니다.
그래서 특히 내 경험 쌍을 높이고 요 그 다음에 오토 스케일링과 함께
서비스를 추해 탄력적으로 확장시킬 수 있는 하나의 컴포넌트 라고 볼 수
있습니다.
4 플라스틱 로드 밸런서 의 활용 사례에 대해서 살펴보도록 하겠습니다.
첫번째로 일랑 씩 로드 밸런서 는 말씀드린 것처럼 이 시투 앞 딴 의 서
인스턴스 들을 트래픽을 모니터링하고 그리고 트래픽을 부하를 분산시켜 주는
역할을 하게 되고요
이때 인스턴스의 상태를 감지를 할 수가 있습니다.
예를 들면 특정 프로토콜 혹은 특정 포트가 열리지 않았다거나 혹은 특정
url 이 지금 현재 열리지 않았을 경우 비정상적으로
플라스틱 로드 밸런서 가 확인을 하구요 이 비 정상적인 이스 투에
트래픽을 흘리지 않고 그리고 정상적인 트래픽을
정상적인 서버 에게만 트래픽을 전달 하기 때문에 실제로 서비스의 내 겨
남성을 향상시키게 됩니다.
한나의 이스트 인스턴스의 장애가 발생하더라도 그 장애를 elb 가 감지를
하고 그쪽으로 트래픽을 보내지 않기 때문에 전체적으로 고객 입장에서
서비스 입장에서 봤을 때는 장애가 발생 했는지 뭐 발생하지 않는지
요즘은 알수가 없습니다. 그래서 또한 elb 를 통해서 통합적으로 인증서
ssl 인증서 같은걸 관리를 할 수가 있습니다. 그래서
lb 딴 에서 앞단에 있는 로드 밸런서 딴 에서 ssl 보컬을 제공을
해주기 때문에 중앙에서 인증서를 관리해서 실제로 웹서버에 각기 웹 서버에
인증서를
뭐 설치하고 그리고 구성하는 게 아니고 앞단에 있는 로드 밸런서 에서
인증서를 복호화 하는 기능이 있기 때문에 중앙에서 관리가 가능하다 라고
볼 수가 있습니다.
또한 암호화 를 복구하고 혹은 그리고 이것들 ssl 인증서를 처리해 주기
위해서 cpu 리소스가 들게 되는데 이 시피 인스턴스 를
이스트 에서 cpu 자원을 사용하는게 아니고 el 밑단 에서 보컬을
제공해주기 때문에 실제로 이 스투 인스턴스에서 는 써비스 트래픽 만
수용을 할 수가 있고 그것에 대해서 자원 활용도를 추가적으로 높일 수가
있습니다.
그리고 로드 밸런서 를 인터넷 으로 나가는 그리고 인터넷에 들어오는
서비스의 만 쓰는게 아니고
내부 어플리케이션 딴 에서도 쓸 수가 있습니다.
예를 들면 은 웹서버가 있을거구요
웹서버 2대가 있다라는 가정하에
뒤 딴 의 마스 서버가 있을거구요
마스 서버에 d 트래픽이 흐르게 되는데
이때 웹서버에서 들어오는 트래픽을 와 서버 에서 처리를 하는데
마스 서버 단에서 확장성이 필요하다 라고 했을 때는 특정 악의 앞 따내
로드 밸런서 를 통해서 네트웍을 마쓰 3번 에게도 부하를 분산시킬 수
있게끔 뒤 딴 에서 설계를 하실 수가 있습니다.
이렇게 4구 트래픽 역시도 효율적으로 처리할 수가 있으며 또한 서비스를
탄력적으로 수행을 시킬 수 있습니다.
4 컴퓨팅 영역 의 탄력성 중에서 가장 대표적인 인 모터 스케일링에
대해서 알아보도록 하겠습니다.
오토 스케일링은 실제로 이 시투 용 년 cp 용량 그리고 메모리의 용량
같은것들 사용자가 정의한 조건에 따라서 자동적으로 확장시키고 축소 시켜서
실제로 저희 어플리케이션 단 혹은 서비스 안에서 품질을 유지 시켜 주는
서비스다 라고 볼 수 있습니다.
실제로 트래픽이 들어올 경우 수요가 급증할 경우 이스트 인스턴스가 하나의
이스트 인스턴스 혹은 웹 서버에서 처리할 수 있는 트래픽 의 개수는
제한이 되어있습니다.
하지만 뒤 딴 에서 오토 스케일링을 통해서 병렬적으로 수평적으로 확장을
시키기 때문에 이 스 터 스 스 를 자동으로 증가를 시키고 요
오토 스케일링 통해서 그러기 때문에 시체로 서비스 의 성능은 그대로
유지가 되게 됩니다.
실제로 여기 크래프트를 보시면은 제 알수가 있는데요
쉘 사용량에 이렇게 늘어나고 있고 출하 드는 와중에 실제로
웹서버에 용량 웹 서비스를 트래픽을 처리할 수 있는 서버에 용량 역시
함께 늘어나고 함께 줄어들기 때문에 서비스의 품질을 안정적으로 보장 할
수가 있습니다.
전에 챕터에서 말씀드렸던 것처럼 오토 스케일링 아웃
스케일 아웃 스켈 2인 을 통해서 유연하게 서비스를 탄력적으로 가져갈
수가 있고요
이 역시 이런 부분에서는 비용절감 효과 역시 가져올 수가 있습니다.
그래서 수여가 적을 경우는 자동으로 스케일 인 혹은 다운을 시켜서 비용
낭비를 제거할 수 있습니다.
실제로 토스 킬링 에서는 스킬 아웃과 스케일 인에 대한 병렬적으로
수평적으로 확장시키고 확장을 줄이는 그 역할을 수행할 수가 있습니다.
그래서 오토 스케일링에 구성 요소에 대해서 간단하게 추가적으로 알아보도록
하겠습니다.
총 3가지의 구성 요소가 있는데요 첫번째 그룹 그리고 시작 구성
그 다음에 확장 계획 실제로 여러분들이 스켈링을 하기 위해서 필요한 구성
요소입니다.
첫번째로 그룹 이라고 하는 것들은 괄 논리적인 인스턴스 다니라고 볼 수가
있는데요 실제로 저희가 오토 스켈링 그룹을 설정을 한다. 라고 했을 때는
어떠한 인스턴스 들을 오토 스켈링 가능하도록 울음을 지울 건지를 결정을
첫번째로 하셔야 됩니다.
그래서 최소 원 인스턴스 개수와 최대 인스턴스 개수를 정 하셔야 되구요.
여기 아래 그림에서 볼수 볼 수 있듯이 최소 개수와 최대 개수를 포토
스케일링 크룩 설정할 때 그룹의 설정을 하셔야 됩니다.
그리고 시작 구성 실제로 오토 스케일링을 할 하는데 어떠한 것들을
바탕으로 토 스케일링을 할 거냐 이 필요시 확장되는 서버 들을
어디 어떤 이미지로부터 배포를 할 거고 뭐 어떤 그룹을 어떤 보안
시큐리티 그룹이라 단건 어떤 사이즈로 확장을 시킬 거냐
그게 이제 시작 구성의 들어가는 구성 정보라고 보실 수 있습니다.
실제로 이 시투 인스턴스로 구성할 때 활용하는 템플릿 앞에서 말씀드렸던
am i
아마존 머신 이미지를 통해서 어떤 골드 이미지로 구성 하실지 를 결정
하셔야 되고요
그 다음에 이미지 정보가 실제로 ami 와 동일한 이야기 있구요.
사이즈 다음에 보안 그룹 그리고 시장의 관련한 정보를 지정할 수가
있습니다.
실제로 인스턴스 오토 스케일링 그룹을 설정을 하시고 개수를 지정 하셨다면
은 그 이후에 필요시 확장되는 서버 들에 대해서 2 스토리 디스턴스 들에
대해서 어떤 조건으로 혹은 어떤 사이즈로 어떠한 보안 그룹으로 올라올지
를 미리 결정을 해 놓으셔야 되구요.
그래서 뭐 동일한 사이즈를 보통 시작 사이즈로 지정을 할 수 있습니다.
그래서 이러한 정보들을 바탕으로 실제로 여러분들이 스케일링을 하기 위해서
트리거 링 하는 인계 값을 지정 하셔야 되는데 이 이제 값을 지정하는
부분은 확장 계획 부분에 있습니다.
그래서 아래 그림에서 말씀드리도록 하겠습니다. 오토 스켈링 그룹을 총
이런식으로 지정을 했다 라고 가정 하에 실제로 처음에 그룹을 지정을 할
때 최소 베스와 최대 개수를 지정 하시고요
그리고 필요시 확장될 때 몇 개를 한꺼번에 확장시킬 g
예를 들면 2개를 만들지 혹은 4개로 만들지 이런 것들을 지정을 할 수가
있습니다.
너 필요시 확장을 할 수 있는 개수를 추가적으로 그룹의 넣으시구요
그리고 난 다음에 시작 구성에 대해서 그래서
이 서버들이 추후에 늘어날 건데 어떤 정보를 가지고 드러날 건지를 시작
구성하는 부분에서 설정을 하실 수 있습니다.
그리고 실제와 앞에서 혹은
모니터링 관점에서 말씀드렸을 때 얘네들이 추가로 드러나 기 위해서
2 6 들을 모니터링 하고 있다가 어떤 값이 예를 들면 트래픽의 사용량이
500gb 이상이 됐을 때 들어 난다거나 홍은 cp 5 2 서버 2
cpu 자원이 지금 70퍼센트 이상 넘어갈때 트리거 링을 해서 서버를
요구되는 필요시 확장되는 부분을 채운다 거나 이런 것들을 확장 계획에
설정하셔야 서 여러분들이 오토 스켈링을 구성 하실 수 있습니다.
4 두번째로 aws 에서 코드 레벨로 의 확장성 에 대해서 알아보도록
하겠습니다.
실제로 aws 에서는 인프라스트럭처 해 줘 서비스 형태 롬 제공하는
서비스도 많이 있구요.
그리고 플랫폼에서 서비스 형태로 파스 형태로 제공해 주는 서비스도 많이
있습니다.
그중에서 이제 대표적인 예가 엘라스틱 빈즈 토크 라고 불리울 수 가
있는데요
여러분들이 개발하는 소스 코드 같은 것들을 보다 간편하게 배포하고 확장할
수 있게 해주는 서비스 라고 볼 수 있습니다.
여러분들이 구성하는 뭐 어플리케이션 이라던가 웹 같은 경우는
뭐 자바기반 이라던가 단 넷이 라던가 혹은 모습이 같은 것들 위에 그리고
아파치 뭐 톰캣 그 다음에 엔진 x
이런 것들이 같이 서버에 연동이 되서 여러분들의 웹서비스 라던가 앱
서비스를 구성을 하게 되는데 이런 것들을 자동으로 확장을 해 주고 그리고
로드밸런싱 이라던가 혹은 j 시투 의 용량 프로비저닝 로드 밸런서
오토 스케일링을 자동으로 해주는 서비스라고 볼 수 있습니다.
그래서 플라스틱 빈즈 토크를 활용했을 때 여러분들이 소스 코드만 개발이
완료가 되면 은
타이트 마켓을 타임 투 마켓 되는 시간을 절감할 수가 있고요
이거 역시 aws 에서 다양한 방법들로 제공을 기능을 제공해주기 때문에
여러분들이 코드 레벨에서 확장성 탄력성을 가지고 올 수가 있습니다.
4 코드 레벨의 확장성 중에서 또 대표적인 옵스 웍스 라는 기능이
있습니다.
실제로 옵 쏙 쓰는 셰프 라는 프로비저닝 자동화 툴을 통해 가지고
어플리케이션을 구성을 자동화 시키고 대규모의 자원의 구성 정보를 관리하고
운영 해 주는 서비스 다 라고 볼 수 있습니다.
실제로 이제 셰프 서버나 셰프 클라이언트를 활용을 해 보셨던 분들은
아시겠지만 쉐프를 통해서 다양한 구성 환경을 여러분들이 손쉽게 빌드하고
자동화 시킬 수가 있습니다.
이런 것들을 아마존 땅에서 추상화된 레이어에서 제공을 해주는 게 옵스
웍스 라고 하는 서비스 구요
실제로 여러분들이 옵스 웍스 를 통해서 시스템을 혹은 서비스를 배포 할
수가 있구요.
이거에 대해서 이러한 구성 요소를 가져갈 수 있습니다.
첫번째 스택 이라고 하는 여러분들이 5회 마쓰 데이터베이스를 구성 한다.고
했을 때 그 하나의 나는 이 구조에 대한 템플릿을 가져가게 따
이게 이제 스택 이라고 볼 수가 있구요. 그 안에 들어가는
그의 레이어드 예를 들면 뭐 웬 레이어 마쓰 레이어 뭐 데이터 베이스
레이어 뜰을 스택 안에서 추가적으로 구성할 수가 있습니다.
그래서 이 스택을 통해서 레이어를 뭐 3t 원아 호투 태워 로 구성을
하실 수가 있구요.
그 안에서 귀 스테 꽈 레이어를 바탕으로 여러분들이 어플리케이션을
자동으로 배포 할 수가 있습니다.
그리고 자동으로 배포하고 끝나는게 아니고 추후에 버전 관리 라던가 혹은
패치 같은 것들을 중앙에서 관리할 수 있도록 스택을 관리를 하면서 추후에
벌어지는 관리 썽 작업들을 여러분들이 웁스 웁스 를 통해서 대체 하실수가
있습니다.
그래서 여기서 말씀드리는 것처럼 스택 이나 그룹에 이어 앱 같은 개념을
활용해 서
어플리케이션을 모델링 한다. 라고 많이 표현을 하고 있습니다. 4
어플리케이션 모델링하고 카탈로그와 시켜서 이런 것들을 실제로 시각화하고
대시보드를 통해서 어플리케이션 레이어의 웬 레이어 마쓰에 에 지금 상태가
어떤지 그리고 어떠한 구성 정보가 지금 이 안에 들어가 여 있는지를
실제로 서버에 들어가지 않고도 이 대시보드에서 여러분들이 확인하실 수가
있습니다.
이 옵소서 를 통해서 여러분들 코드 레벨에서 탄력성을 가져 오실 수가
있습니다.
4 aws 에서 코드 레벨의 탄력성을 가지고 올 수 있는 코드 디플로이
에 대해서도 설명 드리도록 하겠습니다.
코드 디플로이 라는 서비스는 모든 인스턴스 에 대해서 코드 배포를 자동화
시키며 그리고 안전하고 신속하게 어플리케이션을 배포할 수 있는 서비스 다
라고 말씀드릴 수가 있습니다.
실제로 여러분들이 서비스를 구성하고 추의 변경 군이 발생을 했다 라고
가정했을 때 여러분들이 개발 서버 라던가 홈스테이 징 서버 혹은 어떤
것들은 프로덕션 레벨의 서비스 서버들에게 배포를 하셔야 되는데
이런것들을 보다 간편하고 안전하고 신속하게 할 수 있는 서비스다 라고 볼
수 있습니다.
실제로 여기 아래 그림에서 확인을 하실 수가 있었는데요
저희가 보면은 제 소스 코드에 대한 변경 분들 어플리케이션에 대한 변경
분들이
한나 2개 3개 정도가 존재할 수가 있고요
이거에 대해서 어떠한 변경 분이 지금 상용 에 적용할 수 있을지에 대해서
여러분들이 코드 레벨에서 확인을 하셨을 겁니다
이거에 대해서 배포를 이제 일괄적으로 진행을 하셔야 되는데 이것을 뭐
상용 환경 서버 그룹에 다가 배포를 할 건지 혹은 개발환경 서버 그룹에
다가 배포 할 건지를 여러분들이 이 중앙에서 구성을 하실수가 있습니다.
그래서 여러분들이 이 구성된 정보와 변경 분 을 바탕으로
aws 코드 디플로이 로 활용을 하면 은 실제로 어느 서버에 만 이것을
배포를 시킬지 를 결정을 하실 수가 있습니다.
예를 들면 는 역 그림 같은 경우는 이제 구성돼 있는 변경 분 두 번째
것들이 실제로 개발 환경에서 돌렸더니 문제가 없고 사용환경에 갈 수 있는
버전 이라고 가정하고 요 이 변경 분투 에 대해서 배포 구성 할 때
실제로 구성에 대한 서버들을 이렇게 3가지로 구성 을 하게 됩니다.
하나의 서버 는 실제로 오토 스캔 그룹에 있는 서버 될 수가 있고요
오토 스캔 그룹의 있지 않은 다른 서버 도 배포 가능합니다.
그래서 이렇게 배포를 구성했을 때 이게 만약에 상영 환경이라면 은
여러분들이
심 손쉽게 변경 분에 대해서 코드를 업데이트하고 유지할 수가 있습니다.
이렇게 콘솔 aws 콘솔 웹 대시보드 혹은 cli 를 통해서 손쉽게 배포
상태를 중앙에서 추적할 수가 있구요.
그리고 어플리케이션 별로 짐 현재 수정 버전이 언제고 그리고 어떤
인스턴스의 지금 적용이 돼 있는지 또한 중앙에서 관리를 할수가 있습니다.
이렇게 관리를 할수가 있으며 는 여러분들이 추가적으로 발생되는 변경 분에
대해서 안전하고 신속하게 서비스의 적용시킬 수가 있습니다.
4 세번째 aws 관리 영역에 탄력성 에 대해서 알아보도록 하겠습니다.
특히 aws 에서는 말씀드린 것처럼 api 라던가 웹 인터페이스가 잘돼
있기 때문에 관리가 편의 하고요
편리한 것 중에서 가장 대표적인 예가 클라우드와 칠하는 모니터링 솔루션
입니다.
여러분들의 실제로 인프라스트럭처를 구성하고 시스템을 구성을 한 다음에 이
모니터링을 통해서 운영을 효과적으로 하셔야 됩니다.
하지만 클라우드 환경 같은 경우는 다양한 리소스 들이 함께 동작을 하기
때문에 모니터링에 표준을 가져오기는 매우 어렵구요
그래서 aws 에서 관리 영역에서 탄력성을 가지고 올 수 있게끔 서비스를
제공해 주는 게 클라우드 가출하는 서비스 입니다.
대표적으로 클라우드 아치의 기능은 장애에 대한 디자인의 구성
실제로 지금 장애가 발생을 하는 서버 혹은 장애가 발생할 것 같은 지금
시피 의 cg 라던가
o 트래픽을 바탕으로 그거에 대한 알람 모니터링 같은것도 제공해 주고
있구요.
그것을 디자인을 할 수가 있습니다. 그래서 실시간 모니터링
그리고 장애 감지 역시 수행을 할 수가 있구요.
그걸 클라우드 아치 에서 aws 에서 간편하게 여러분들이 추가적인
소프트웨어 설치 필요없이
대시보드 라던가 api 를 통해서 여러분의 원할 때 원하는 데이터들을
수집해서 볼 수가 있습니다.
그리고 또한 이 오토 스케일링과 같이 연관이 되어서 추후에 발생되는 모터
스켈링 작업 의
인계 값들 뭐 예를 들면 cpu cg 이니까 72 넘어갔다 뽑은 네트워크
트래픽이 지금 뵙기가 이상 넘어가고 있다 라고 판단을 클라 같이 해서
하고요
그것과 연동이 오토 스켈링 와 돼서 시체로 여러분들이 요구되는 cpo
인스턴스 자원들 이스 투블 통해서 서비스의 품질을 안정적으로 유지할 수
있게 됩니다.
그래서 aws 에서 클라우드 아치의 데이터와 그리고 여러분들이 커스텀
하게 인스턴스 에다가
뭐 특정 스크립트를 통해서 데이터 수집 요청을 클러치와 연동시켜 산다면
은 두가지 같이 이 모니터링 매트 리게 수집이 될거구요
엘 드 메 cpu cgl 들면 은 뭐 뭐 다른 트래킹 uc g
그 다음에 여러분들 프로세스 자벨 따른 어떠한 uc 지 사용량 이런
것들을 매트 립 설정을 통해서 여러분들이 상태 정보를 확인하실 수도 있고
어떤 트리거 박스를 통해서 추후에 알람을 발생 시킬 수도 있습니다.
알람 발생을 할 때 여러분들이 앞차 시에서 말씀드렸던 것처럼 sns 나
ses 를 통해서 여러분들께 푸시 메세지 라던가 이메일 서비스를 통해서
여러분들께 알람을 발생을 시킬수가 있습니다.
또한 이 알람을 기본으로 해서 인계 값들을 기본으로 해서 오토 스케일링을
할 수도 있고요
오토 스켈링 하면은 실제로 우리가 요구하는 요구 사항에 맞게 끔 이스틴
인스턴스 들 자원들이 드러나고 줄어들고 하는 것들을 통해서 여러분들의
서비스의 품질을 또한 높일 수가 있습니다.
이것들을 실제로 여러분들이 관리 콘솔이 라던가 서비스 상태를 확인할 수
있는 api 를 통해서 여러분들이 원하는 데이터들을 여러분들이 구성하는
서비스 모니터링 페이지에 빌트인 하실수도 있구요.
이런 것들을 통해서 aws 관리 영역에 탄력성을 가져올 수가 있습니다.
4 그리고 관리 영역에 탄력성 중에서 클라우드 포메이션 이라고 하는
서비스의 대해서도 말씀드리도록 하겠습니다.
클라우드 포메이션 이라고 하는 것들은 실제로 인프라 리소스의 모금 저희가
구성하는 서버나 네트워크 그리고 스토리지에 대한 자원들을 실제로 여러분
대규모 시스템을 구성 을 하다 보면은
이게 쉽게 구성을 다시 할 수 있거나 이걸 재 사용하기에는 매우
어렵습니다.
하지만 클라우드 포메이션을 통해서 2부 꿈에 대한 정보를 쉽게 생성 하실
수가 있고요 그리고 구성하고 관리 하실 수가 있습니다.
셋째로 리 소스 환경을 명시적으로 코드와 하여서 프로비저닝 및 업데이트를
탄력적으로 관리할 수 있게끔 이런식으로 아래 그림처럼 코드와 베이스로
그리고
ui 베이스로
관리를 하실 수가 있습니다. 그러면 여러분들이 it 엔지니어 전문적인 it
엔지니어가 아니더라도 이런 서비스 플로우 에 맞게끔 뭐 데이터베이스
라던가 후 금액 서버 라던가 혹은 뭐 블라스팅 로드 밸런서 라던가 보트
스켈링 그룹을 여기서 설정을 하시면 은 실제로 명시적으로 코드와 돼서
관리가 되구요. 이것을 통해서 여러분들이 개발환경 상용 환경 로 스테이징
환급 최 환경을 동일한 인프라 리소스의 묶음으로 배포도 가능하십니다
이렇게 클라드 포메이션을 통해서 배포 리소스 묶음에 인프라 리소스의
묶음에 배포에 자동화를 가져올 수가 있구요.
이렇게 됐을 때 추후에 여러분들이 옥체 이라던가 혹은 다양한 테스트를
하기 위해서 별도의 환경을 꾸려서 기존에 있는 상용 이라던가 개발 환경에
영향을 주지 않는 상태로 리소스의 묶음을 대포 하시고 거기서 상태 정보를
체크하고 코드를 테스트를 하실 수가 있습니다.
이렇게 관리 영역에서 탄력성을 가지고 올 수 있는 서비스가 클라우드
포메이션 입니다.
이번 차 시에서는 탄력성 있는 구성 방법에 대해서 살펴보았습니다.
첫번째로 aws 컴퓨팅 영역의 탄력성 에 대해서 알아보았습니다.
네트워크를 부하를 분산시킬 수 있는 효율적으로 분산 시킬 수 있는
플라스틱 로드 밸런싱 예비 라는 서비스 에 대해서 알아보았는데요
이렇게 elb 가 이스틴 스턴 스압 땅에서 효율적으로 트래픽을 처리를
회식 해주기 때문에 여러분들의 서비스의 품질을 높게 가져갈 수가 있구요.
또한 오토 스케일링을 통해서 여러분들이 특정 트래픽의 사용량에 맞춰서
서비스 e2c 필 자원들을 늘리고 줄임 에 따라서 내 결 함성과 서비스의
성능을 향상시킬 뿐만이 아니고 효율적인 비용 운영도 가능하게 합니다.
두번째 aws 코드 레벨에서 탄력성 aws 에서는 인프라스트럭처 에즈 어
서비스 모델 뿐만이 아니고 다양한 파스 모델을 제공하고 있습니다.
추상화된 레이어 라고 보실수가 있는데요 멀라 스틱 빈즈 토크 를 통해서
여러분들이 소스 코드만 가지고 이 컴퓨팅 환경에 대한 부정을 작용으로 할
수 있다거나 혹은 옵스 웍스 를 통해서 여러분들이 컴퓨팅 환경 구성에
대한 스택 이라던가 레이어드를 여러분들이 원하는 데로 카탈로그와 시켜서
서피스 형태로 만들 수도 있는거구요
그리고 코드 디플로이 를 통해서 시체로 여러분들이 코드에 대한 변경 분이
발생을 하였을 때 어떤 서버 에 어떻게 100번 할 건지에 대해서
탄력적으로 운영할 수가 있고 손쉽고 빠르게 다양한 서비스 레이어의
효과적으로 관리를 할 수가 있습니다.
하지만 5 관리 영역에 탄력성 모니터링에 대한 부분이 많이 나왔는데요
클라우드와 7을 통해서 여러분들의 aws 컴포넌트에 대한 관리를
탄력적으로 할 수가 있구요.
특히 크아도 가치의 알람 트리 거닝 기능이라 더 모니터링을 통해서 오토
스켈링 과 연관시켜 추후에 성능에 대한 향상 부분도 가져올 수가 있구요.
그리고 클라우드 포메이션 이라는 서비스를 통해서 여러분들이 환경 될 뭐
개발환경 상용 환경 mq 애완견 같은 다양한 환경들을 여러분들이 묶음
화해서 코드와 해서 관리를 할 수 있어서 보다 명치 적이고 보다
탄력적으로 여러분들의 awd 소스를 운영 가능 합니다.
댓글 0개
등록된 댓글이 없습니다.