아마존 클라우드 AWS Essential 12강 AWS 설계 방안 > AWS 클라우드

 

이번 시간에는 aws 설계 요소 중에서 클라우드 네이티브 앱에 대한
설계에 요소들 간단한 것들에 대해서 말씀드리도록 하겠습니다.
그리고 aws 에서 서비스 모범 사례를 통해서 실제로 어떻게 효과적으로
설계를 할 수 있는지에 대해서 말씀드리도록 하겠습니다.
그리고 마지막으로 비용 최적화 관점에서 어떻게 효율적으로 비용을 운영을
하고 관리를 할 수 있는지에 대해서 말씀드리도록 하겠습니다.
4 클라우드 네이티브 앱의 설계 요소
첫번째로 클라우드 데이 tv 라는 클라우드 환경 위에서 aws 뿐만이
아니고 애 젖 은 구글 클라우드 플랫폼이 든 다양한 클라우드 환경 위에서
앱을 설계를 할 때 어떤 것들을 조금 요소를 고려해서 설계를 해야
되는지에 대해서
여기 열두 가지의 클라우드 네이티브 앱의 요소들에 대한 인터넷 그 공개가
된 전문의 있는데 이것을 통해서 실제로 클라우드 위에서 올라오는 앱들의
설계를 많이 하고 있고요
그래서 그 중에서도 이번 시간에는 간단한 5 코드 베이스 라던가 아니면
배포 라던가 다양한 서비스 요소들에 대해서 알아볼텐데요 첫번째로 이제
코드 베이스 실제로 클라우드 네이티브 앱과 클라우드 환경에서 올라오는 앱
같은 경우는 버전관리 그 코 소스 코드에 대한 보정 관리가
실제로 잘 활용이 돼야 되구요.
이거 를 통해서 버전을 추적을 하고 나중에 올빽 을 할 수도 있는거고
홍군 새로운 뭐 사용자가 돌아왔을 땐 다양한 프렌치를 통해서 여러
사용자들이 한꺼번에 같이 작업을 할 수 있는 환경을 구성을 하셔야 됩니다.
그리고 실제로 이 코드 베이스를 통해서 목이 시나 혹은 서브버전 같은
코드 베이스를 통해서
앱을 배포를 하구요 실제로 예불 배포를 할 때는 이제 상용 환경 그
다음에 목회의 환경 혹은 개발 환경 개발 환경에서도 개발환경이 사용자마다
개발한 명을 별도로 가져갈 수가 있으니까
첫번째 개발한 계모 두번째 개발환경 이렇게 항상 중앙에 있는 코드 관리
대파 지터를 통해서 항상 최신의 코드들을 서로가 관리를 할 수가 있고
그리고 이 코드를 베이스로 해서 새로운 개발을 또 추가로 진행 했을 때
기존에 있는 코드와 새로운 코드가 충절 되지 않게끔 잘 관리를 해주셔야
됩니다.
이게 첫 번째로 말하는 코드 베이스 라는 요소 구요
코드 베이스 이후에 5 다양한 이제 또 요소들이 있지만 또 두 번째로
말씀드리는 것은 이제 종속성 에 대한 부분입니다.
실제로 서비스를 여러분들이 구성을 하다보면 다양한 소프트웨어가 설치가 될
수밖에 없고요
이 소프트웨어가 설치가 될 때 그 소프트웨어
1 단일의 소프트웨어가 설치가 되더라도 그 앞에 선수로 종속된
소프트웨어는 또 존재를 할 수 밖에 없습니다.
그래서 항상 종속성 패키지 를 명시적으로 선언하고
종속 써넣은 파일 같은 매니페스트 같은 파일 같은거 를 별도로 1 두셔서
엄격하게 관리를 하시고요
그리고 항상 어떤 사람이 오더라도 2
우리의 시스템을 새롭게 설치를 한다. 라고 했을 때는 간단하게 설치할 수
있게끔 혹은 간단하게 개발할 수 있게끔 항상 종속성 에 대한 명시적으로
관리를 해주셔야 됩니다.
이게 이제 종속성 에 대한 요소 였구요 다음은 설정에 대한 부분입니다.
설정 같은 경우는 여러분들이 쉽게 환경설정 이라고 아시면 될 것 같구요
개발 환경이나 스테이지 환경이나 상용 환경에서 별도로 달라지는 것들
모든 것들을 여러분들이 환경 설정 값에 가지고 있으셔야 됩니다.
실제로 환경 설정 같은 경우는 서비스 코드 하는 엄격하게 분리를 시키셨다
되고요
만약 이게 코드 5m 아냐 에 갇힌 어져 있다라고 했을 때는 여러분들이
개발 환경에서 개발했던 코드와 상용 환경에서 배포하는 코드는 달라질
수밖에 없습니다.
하지만 클라우드의 네이티브앱 에서는 그런 것들을 지향하고 있고요
그래서 환경 설정 값들은 항상 서비스 코드 하는 분리시키고 분리 에
대해서 여러분들이 안정적으로 나중에 서비스 코드 패치 라던가 홈 환경
설정에 대해서 뭐 쉽게 변경하고 운영할 수 있도록 지원을 할 수가
있습니다.
그리고 그 다음에는 - & 서비스라고 있는데요 백엔드 서비스 같은 경우는
여러분들이 서비스를 구성을 하시는데 항상 그 서비스 자체의 단일 서비스
자체도 다른 서비스의 연결된 니 소스로 지급을 하시구요
예전에 강의에서 말씀드렸던 것처럼 컴퍼넌트의 소 결 합 을 가질 수
있게끔 항상 뺏긴 뜨 시스템을 구성 을 하셔야 됩니다.
그래서 이 기존에 있는 시스템 자체가
소결 앞에서 기존의 밀 결합이 되어 있었다면 은 소 * 합을 시키셔서
여러분들이 뒤에 백핸드 시스템들 리소스로 항상 연결 하시구요
그 연결이 된 상황 이라며 는 나중에 여러분들이 확장성이 나 탄력성 에
대한 높은 수준의 서비스 운영을 하실 수가 있습니다.
그 다음은 프로세스의 입니다. 프로세스가 같은 경우는 여러분들이 상태 정보
가 스테이트 뭐 데이터베이스의 고객정보 라던가 홍은 유저 센 정보 같은
것들을 웹 서버나 흥분 앱 서버에서 남기지 않고 이런 것들이 만약에
저장이 필요할 경우는 뒤에 있는 - & 서비스의 저장을 해야 된다 라는
개념입니다.
실제로 여러분들이 서비스를 구성을 하실때 정보가 유지가 되어야 될
필요성이 있는 것들도 있고 5 필요없는 것도 있는데 정보가 저장될 필요가
있는 것들은 뒤에 db 라던가 혹은 4 있으나 혹은 뭐 유저 세션의 를
관리할 수 있는 스토리지 같은 것들을 별도로 뺏기는 시스템으로 구현을
하셔서
앞에서 말씀드렸던 것처럼 서비스의 소 결 합 을 통해서 여러분들이 나중에
확장성이 나 탄력성 a 가지고 있는
에이블 개발 하실 수 있도록 설계를 하셔야 됩니다.
이게 이제 프로세스의 관점 이었구요 앞으로 여러분들이 설계를 하실 때
이런 백엔드 시스템 그리고 프로세스에 대해서 여러분들이 컷 설계의
관점에서 항상 고민을 하시고 설계를 하셔야지 탄력적인 서비스가 될 수
있습니다.
그 다음은 비드 릴리즈 실행 2 구성입니다.
실제로 클라우드 데이 티브 앱을 떠나서 기존 있는 앱이 라도 이런 세
단계의 단계는 항상 지키는 추세 구요
그래서 빌드 늘 이즈 실행에 단계를 엄격하게 서비스로 분리 시켜야 됩니다.
이게 하나의 시스템에서 bd 를 하고 릴리즈를 하고 실행을 한다.면은
이 코드가 중복되거나 호금 다양한 환경 같은게 중 복되다 가 실제로 상용
에 갔을 때는 문제가 발생할 요지가 있습니다.
그래서 항상 이 단계들을 여러분들이 분리를 시키시고
그리고 이 단계가 분리가 됐다 며 는 여러분들이 각각의 환경에서 5
추가적인 테스트를 확인할 수가 있습니다.
예를 들면 은 유니테스트 라던가 혹은 뭐 전체적인 테스트를 어떤 각
단계별 여러분 직접 수행 하실 수가 있구요.
이런 것들을 분리가 되어야지만 여러분들이 나중에 효율적으로 서비스
대한 폐포를 가져 오실 수가 있습니다. 그리고 항상 실행 단계에서는
최종적으로 마지막 단계에서는 코드를 당연히 변경할 수가 없고요 코드
변경은 뭐 빌드를 하고 혹은 그 전의 유니테스트 라던가 혹은 개발단계에서
코드에 대한 확인을 하시고요
그리고 만약에 실행 단계에서 어떤 문제가 발생했을 때는 코드 변경 이
아닌
이전 버전으로 놀 백을 되돌릴 수 있도록 여러분들이 시스템을 설계를
하셔야 합니다.
그래서 항상 효율적으로 여러분들이 앱 이라던가 웹 서비스를 운영을 하실
수 있게끔 새로운 패치가 나왔을 때 이런 각각의 순서에 맞춰서 여러분들이
효율적으로 관리를 하고 있다 며 는
주조 4 배포가 잘못되 더라도
전에 버전의 데이터를 가지고 여러분들이 서비스를 할 수 있게끔 로 빼게
된 시스템 도 고민 하셔야 됩니다.
이게 이제 필드 릴리즈 실행에 대한 구성 요소 였읍니다
4 다음은 포트 바인딩 에 대한 요소입니다.
포트 바인딩 이라는 것은 아까 말씀드렸던 백엔드 시스템과 약간 연관이
되는 이야기라고 할 수가 있는데요
항상
어떤 서비스 안에 들어 있는 앱들 같은 웹 홍콩 가스 데이터베이스
이런 것들 뿐만이 아니고 다양한 여러분들이 구성하는 내부의 시스템 자체가
다른 서비스를 위한 뺏기는 서버 가 될 수가 있다고 가정을 하셔야 되고요
비다 정을 통해서 항상 포트를 바인딩 한다.
예를 들면 api 통신을 위한 api
뭐 표준 인터페이스를 만든다거나 혹은 뭐 다양한 스펙 들을 정리해서
추후에 이 서비스 역시도 뺏긴 트 서비스로 활용될 수 가 있게 끔
여러분들이 설계를 하셔야 됩니다.
그래야지 추후에 확장성이 라던가 다양한 클라우드 의 특징들을 이용하시는데
효율적으로 사용하실 수가 있습니다.
그 다음에는 일회성
실제로 프로세스가 같은 경우는 클라우드 환경에서 2 클라우드 안경은 뭐
장애를 대체를 해야 되고
그리고 확장성 그리고 탄력성이 매우 중요한 환경이기 때문에 빠르게
프로세스를 시작을 하거나 종료 할 수가 있구요.
그리고 이러한 특징을 통해서 신 충성 있고 뭐 코드를 빨리 배포를
한다.거나 혹은 변경을 빨리 한다.거나 해서 여러분들이 안정적으로 여러 가지
환경
뭐 특히 프로덕션 환경 같은 상용 한경우 같은 경우는 간접적으로 운영을
하셔야 되구요.
그래서 이런 빠르게
서 땅을 시킬 수도 있고 빠르게 스타트를 시킬 수도 있고 이런 것들이 잘
맞춰야지 나중에 여러분들이 어떤 작업을 하실때 이 앞에 있는 서비스
특성에 따라서 시간이 오래 걸리고 쫓게 걸려고 가 아니고 여러분들이
표준화된 은 체계를 통해서 안정적으로 운영을 하실 수가 있습니다.
다음은 대부 프로덕션의 일치 입니다.
당연한 이야기겠지만 개발 환경과 상용 환경
뭐 스테이징 환경 같은 경우도 동일 하겟지만
다른 백엔드 서비스 의 설계를 지향 아 하셔야 됩니다.
실제로 모 데이터베이스 엔진 버전 2 개발환경 같은 경우는 몸 아이
스킬인데 상용 은경 같은 경우는 뭐 오라클이 다
이럴 경우에는 여러분들이 그런 뺏기는 시스템에 다르며 는 개발 환경에서
개발하던 코드와 상영 환경에서 개발을 해야 되는 코드 자체가 달라질 수가
있습니다.
실제로 이렇게 서비스를 구성을 환경들을 구성을 하시면 안되고요
그래서 항상 동일한 백엔드 서비스를 설계를 하셔야 됩니다.
그리고 항상 그 버전을 맞추고 그리고 같은 버전의 종류 그리고 같은
시스템 들은 활용할 수 있게끔 여러분들이 잘 융합해서 설계를 하셔야
되구요.
그래서 환경의 차이를 최소로 하고요
그러다 보면 여러분들이 상용 가기전에 스테이징 가기전에 개발 환경에서
개발했던 코 소스 코드들을 동일하게 프로덕션 환경 스테이징 환경에도
배포를 하실수가 있습니다.
왠 항상 지속적인 배포가 가능하도록 여러분들이 서비스를 디자인 하셔야
됩니다.
다음은 로그에 대한 요소입니다.
모구 같은 경우는 여러분들이 서비스의 동작 확인 에 대한 부분으로 도
활용을 하실 수가 있고요 아니면 은 특정 성능에 대한 지표로 확인을
하실수가 있습니다.
하지만 이 시스템 로그에 대한 부분을 시스템화 하지 않고 별도의 서비스
에서 여러분들이 운영 하신다면 은 매번 그 별도의 서비스 의 시스템에
들어가셔서 요구를 확인을 하셔야 되고요
그거를 통합해서 보기에는 매우 어렵습니다. 클라우드 네이티브 앱의 설계
요소 중에서 로고가 중요한 이유는 이런 것들을 중앙에서 집중 해서 관리를
하고 그거에 대해서
분석 시스템 혹은 보관소로 전달해서 장시간에 걸친 에 배 동작 상태를
열람은 하거나 혹은 저장을 하셔야 g
추후에 여러분들이 로그를 통해서 어떠한 서비스에 대해서 확장을 할 건지
혹은 어떻게 서비스 품질을 높일 건지에 대한 고민을 하실 수가 있습니다.
그래서 이런 로그에 대한 부분이 최근 들어서 매우 중요해지고 있습니다.
두번째 aws 모범 살게 사례에 대해서 말씀드리도록 하겠습니다.
aws 에서 실제로 모범 사례로 제공을 해주는 시스템을 제가 여기에
설명을 드릴 거구요
실제로 웹에 대한 부분 메모 미디어 시스템에 대한 부분 게임 시스템에
대한 부분에 대해서 말씀드리도록 하겠습니다.
여러분들이 앞에 강의에서 다 들으셨던 내용이 쉴 거구요
실제로 이것들을 어떻게 제 서비스로 묶어서
어떻게 시스템을 묶어서 서비스를 제공 할 건지에 대한 이야기를 해드리려고
하고 있습니다.
첫 번째로 맵 같은 경우는
한테 웹 군이 있을거구요
웹서버 분이 있을 거구요 그 다음에 어플리케이션 서버 뭐 와 쓰 같은
것들이 있을 수가 있고요 그 다음에 뒤 딴 이제 데이터베이스 서버 쿤
이렇게 3t 어의 구조로 많이 이루어지고 있습니다.
기본적 에 이제 웹 어플리케이션의 구조라고 볼 수가 있구요.
실제로 사용자가 웹 서비스의 접근했을 때
네트워크 aws 의 네트워크 서비스 중에 한 개인 cdn 서비스 클라우드
프론트 를 통해서 실제로 이 제리 소스 뭐 이미지 파일이 라던가 혹은
영상 파일에 접근을 할 수 있게끔 o s3 에 연동이 될 거고요
혹은 웹서버에 대해서 어떤 뭐 로그인 이라던가 다양한 트랜잭션이
이루어진다 라고 했을 때는
뒤 딴 의 이제 웹서버로 트래픽이 트럭 할거구요
이 트래픽이 들어간 이후의 이 웹 서버들은 뭐 엔진 s 라던가 흥분
아파치 같은 하나의 웹 서버 군 읽었구요 그 6 뜰 역시도 모토
스케일링을 통해서 다 중에 사용자들
대규모의 트래픽 들이 들어오더라도 효율적으로 운영할 수 있게끔 오토
스켈링 구성을 하셔야 되구요.
그 뒤에 이 웹 플리 케이션 으로 들어오는 트래픽 뜰을 처리해 주기 위한
어플리케이션 서버 들
마스 서버라고 도 많이 표현을 하는데 이와 스 서버로
이제 로드 밸런서 에서 효율적으로 트래픽을 분산 시켜서
이와 스 서버들에게 전달을 하구요 이와 스 서버 들에서 실제로 이제
트랜잭션에 대한 작업들이 수행이 되는 거고
만약에 데이터 베이스 쪽으로 뭐 염 둥이 필요하다 로그인 같은 경우는
이제 이 사용자가 우리가 가지고 있는 데이터베이스에 있는 사용 장과
아닌가를 위해서 데이터베이스의 5 확인 요청 혹은 뭐 업데이트 요청
같은것을 진행을 하게 되는데 그 뒤 딴에 있는 rds 같은 거 를 통해서
환경 데이터베이스를 통해서 여러분들이 목 고객정보 라던가 상품 정보
같은거 를 저장 하실 수가 있습니다.
당연히 이제 rds 데이터베이스 역시도 이중화 구성 2
aws 기능을 제공하고 있구요. 그래서 마스터와 슬레이브 를 여러분들이
분산시켜서 나중에 뭐 장애를
대응하는 디자인을 하실수가 있습니다.
이랬을 경우는 실제로 웹의 트래픽 들으니 웹서버에서 받아 주고요 그에
대한 처리는 어플리케이션 서버 이사 하고요
그거에 대한 스테이트 뭐 상태 혹은 정보 같은 경우는 데이터베이스 저장
하구요
실제로 이미지 파일의 라던가 다양한 태교 큰 빨 같은 경우는 s3 에
저장 돼서 cdn 을 통해서 글로벌 엣지 포인트를 여러분들이 활용하셔서
글로벌 사용자에게 서비스를 제공 하실수도 있구요.
혹은 뭐 로컬에 있는 뭐 한국에 있는 시스템에서 h p 에서 한국
사용자들에게 서비스를 제공할 수도 있구요.
이렇게 웹 어플리케이션을 간단하게 그리고 몸쪽으로 여러분들이 설계를 하실
수가 있습니다.
다음은 미디어 서비스에 대한 모범 설계 사례입니다.
실제로 미디어 서비스 역시도 사실은 미디어 데이터 들까 영상 이라던가
혹은 사진 같은 미디어 빨 같은 경우가 대규모로 저장이 되어야 되는데 그
때에 매우 중요한 게 이제 쓰리 앞에서 웹서비스 에서도 말씀드렸듯이 이런
정적인 파일들이 저장되는 효율적인 공간 이네스 스리 저장이 될 거구요
그래서 엔드 유저가 사용자가 어떤 것들에 대한 컨텐츠를 필요로 할 때는
s3 로 다이렉트로 바라볼 수가 있을 거구요
그리고 뭐 라이브 부위 가 예를 들면 스트리밍 에 대한 부분들 그 거
역시도 클라우드 프론트에서 스트리밍 rtmp 프로토콜을 지원을 해주고
있습니다.
그래서 여러분들이 뒤 딴엔 라이브 서버 아까 뭐 스트리밍 서버를 뒤 땀에
구현 하실 수도 있구요.
그 다음에 여러분들이 뭐 특정 5
데이터베이스 혹은 뭐 여러분들이 프라이 b 서버에 있는 콘텐츠를 제공해야
된다 할 때 역시도 이제 클라우드 프론트 를 통해서 여러분들이 서비스를
주고 받고 그리고 뭐 캐싱 하실 수도 있고 다양한 방법으로 여러분들이
미디어 서비스를 구성할 하실수가 있습니다.
그래서 실제로 이 컴퍼넌트의 각각 소결 학을
설계를 하셔야 되고요 이소 결함이 설계가 됐을 때 나중에 뭐 스트리밍 에
대한 여러분들의 서비스 기능을 확장시킬 수도 있구요.
혹은 기존의 스태틱 안 콘텐츠에 대한 뭐 스토리지 확장을 사실 s3 같은
경우는 무제한으로 저장할 수 있는 스토리지 이기 때문에 여러분이 언제든지
원하는 데이터들을 보실수가 있구요.
그리고 이 미디어 서비스가 저장된 실제로 가장 중요한 정보가 저장된 s3
역시도 5 추후에 다른 리전 으로 리플리케이션 할수도 있고 미러링을 할
수가 있기 때문에 글로벌 서비스로 나가는 데도
5표 육적으로 시스템을 구성을 하실수가 있습니다.
마지막으로 게임 서비스에 대한 모범 사례 입니다.
스트로 게임 서비스 같은 경우는 분석이 좀 더 들어가야 될 수도 있구요.
당연히 웹 서버 웹 서비스도 분석이 필요할 수도 있고요
하지만 이제 여기서 뭐 본 사례에서는 게임 서비스에서 분석을 통해서
고객의 특정한 마케팅을 할 수가 있게 끔 설계를 해 논 모범 설계
사례입니다.
그래서 여러분들이 뭐 여러분들이 설계 하시는 게임 서비스의 사용자들이
트래픽을 통해서
뭐 인터랙션을 요청했을 때
웹서버에서 일차적으로 받아줄 거고요
아까 말씀드렸던 웹 서버 웹 서비스에 대한 부분이 이쪽과 동일하다고
보시면 될 것 같습니다. 그래서 사용자들의 트래픽을 오토 스케일링을 통한
웹 서버 군에서 트래픽을 받아줄 거고요
그 뒤에 제거 게임 서비스 같은 경우는 뭐 정형화된 데이터 당연히
있겠지만 b 정형화된 데이터를 유저들의 액션 로그 라던가 다양한 트랜잭션
로그 들이 남기어 질수가 있습니다.
그런 것들을 관계형 데이터베이스 도 당연히 활용 가능 하지만 다이나모
db 라는 비정형 데이터 베이스를 통해서 여러분의 효과적으로 데이터를
저장 하실 수가 있구요.
그리고 만약에 다이나모 db 의 여러분들이 유저의 액션 로 같은것을
만약에 남겼다 라고 했을 때는 뒤 딴에 - & 이것도 다 뺏겨 &
시스템으로 연동이 된다고 보시면 될 것 같습니다.
그래서 이 뒤에 분석을 할 수 있는 하드 클러스터 aws emr 을
연동해서 여러분들이 게임분석 의 효과적으로 사용하실 수가 있구요.
2 뭐 로그 파이드 라던가 혹은
다양한 여러분들의 그 사용자의 스테이트 를 조장하는 파일들을 s3
같은걸로 저장을 하실 수가 있구요.
이 역시도 동일하게 엘라스틱 맵리듀스 를 통해서 사용자 패턴 분석을 하실
수가 있습니다.
혹은 전에 말씀드렸던 거죠 뭐 머신 러닝 을 통해서 패턴을 예측을 하실
수가 있구요. 상관관계를 분석을 하실 수가 있구요.
그 다음에 이 사용자에 대해서 어떻게 마케팅 캠페인을
펼칠지 에 대해서 여러분들이 또 비즈니스 쪽으로 가치를 높일 수가 있을
것 같습니다.
부상만 해서 끝나는게 아니고 사용자에게 이 분석된 데이터를 마케팅 용도로
써야 되기 때문에
sms 같은 ses 같은
aws 심플 이메일 서비스를 통해서
어드민 일하던 혹은 사용자에게 직접 뭐 마케팅을 하실수도 있구요.
이렇게 게임 서버를 여러분들이 운영을 하신다 라고 했을 때는 이 뒤 딴에
있는 이러한 시스템들을 aws 에서 효과적으로 제공해주기 때문에
여러분들이
* 게임 코드 게임에 대한 부분만 집중 하시면은 분석 이라던가 혹은
이메일로 전송 이라던가 혹은 다양한 시스템에 대해서 여러분들이 aws
위에서 모범적으로 설계를 하실 수가 있습니다.
4 세 번째 aws 비용 관리에 대한 부분에 대해서 말씀드리도록
하겠습니다.
실제로 비용에 대한 부분은 여러분들이 항상 효과적으로 운영 을 하셔야
되고요
비즈니스 목표를 달성하기 위해서 불필요한 비용을 제거하시고 경제적으로 d
소스를 운영해서 여러분들의 비즈니스의 가치를 높이 셔야 되는 하나의 요소
입니다.
aws 에서는 이러한 요소를 지켜주기 위해서 비용 투명한 라던가 소외
비용절감 그 다음에 종량제 기반의 운영비용 마음에 규모의 경제 를 통해서
사용자들에게 우리에게 효과적으로 비용의 최적화를 할 수 있게끔 기능들을
제공해 주고 있습니다.
특히 뭐 빌링 페이지 라던가 혹은
뭐 종양 대에 대한 운영 비용 같은 것을 통해서 우리가 사용량에 맞게 끔
혹은 개괄적으로 명시적으로 비용을 분석을 할 수가 있고요 그 다음에
aws 를 통해서 클라우드 프로바이더를 통해서 위한 서비스를 활용을 하기
때문에 직접 운영하는 거에 대한 소위 비용에 대한 절감을 가져올 수가
있구요.
그리고 클라우드 프로바이더 에서 규모의 경제 를 통해서 인프라 자원들을
구매하고 운영을 하기 때문에 보자 저희가 운영하는 것보다 가 병 비용을
낮출 수가 있다 라는 개념입니다.
그래서 이렇게 여러분들을 aws 를 통해서
비용 최적화 를 가져올 수가 있습니다.
실제로 좀 더 자세하게 말씀 드리 쓸 때 컴퓨팅 자원의 구매옵션 같은
경우는 다양한 모델이 있습니다.
네 가지의 모델이 있는데요 크게는 모세가 g 의 모델이라고 볼 수 있을
것 같습니다.
온 디맨드 1 특성 을 가진 비용의 9 족 실제로 사용량 에 기반해서
여러분들이 서비스를 구성을 하실 때 그 약정없이 그리고 쓴 만큼 에 대한
부분 기본적인 클라우드 의 종량제 비용 구조 로 사용할 수 있는
옵션입니다.
비즈니스 예측하기 어려운 신규서비스
혹은 중단이 발생하면 안 되는 서비스의 적합하고 요
실제로 온 디맨드 가 기본적으로 사용하는 블링 모델입니다.
그 다음에 약정에 대한 리저브 드 예약제 인스턴스에 대한 빙 모델입니다.
실제로 여러분들이 이제 서비스를 런칭 하시고 서비스 에 대한 뭐 유지
지속 가능한 기간이 1년 혹은 3년 이상으로 바라 보신다 라고 했을 때는
약점을 통해서 가격 절감을 오스트 10% 까지 가져 오실 수가 있구요.
그래서 장기간 는 활용할 리소스의 적합한 비용 모델입니다.
스팟 인스턴스 픽셀 2차 이제 인스턴스 라고 많이 하는데요
경매 방식으로 aws 의 남은 리소스를
경매를 통해서 여러분들이 서비스를
할당을 받으실수가 있는 빌 필링 구조입니다. 그래서 온 디맨드 에 대비해서
80 에서 90% 까지 싸질 수 있구요.
하지만 경쟁 입찰이 기 때문에 나보다 높은 금액으로 입찰을 하는 사용자
겠다며 는 저의 기 소스는 회수가 되구요.
그래서 단기간으로 수요가 많은 서비스의 적합합니다.
로그분석 이라던가 혹은 예측 이라던가 단기간 1시간 혹은 뭐 짧은 시간
내의 수요가 필요한 것들 에 대해서 서비스의 적합하다고 볼 수 있습니다.
그 다음에 이제 테지 케이트 라고 하는 실제로 여러분들이 물 일이 있어서
자원이 필요할 경우에 뭐 규제나 법적인 민지 때문에 물리 리소스의 자원이
필요할 경우 같은 경우는
어데 d 케이트 라는 컴퓨팅 자원 옵션을 선택하실 수도 있습니다.
아라이 가격 절감에 대한 부분에 대해서 좀 더 상세하게 말씀드리도록
하겠습니다.
아라이 같은 경우는 아까 말씀드렸던 것처럼 약정 혹은 예약자 인스턴스
라고 말씀 드렸는데요
실제로 알아 이를 처음에 구매를 하실때 뭐 1년 알아 이냐 혹은 3년
아라이 냐를 여러분들이 결정 하셔야 되구요.
당연히 여러분들 서비스의 지속 가능한
기간에 맞춰서 구매를 하셔야 지 효과적입니다.
그래서 결론적으로 봤을 때는 밀려 나라의 같은 경우는 의 정도의 또한
30% 40% 의 가격 절감을 가져올 실 수가 있고요
3년 아라의 같은 경우는 최대한 70% 80% 이상이 가격 절감을 가지고
오실 수가 있습니다.
세로 여러분들이 약정을 건 다 라고 했을 때 처음 이 부분에 대해서 약정
금액을 지불 하셔야 되기 때문에 가격이 첫 딸 아라의 로 구매한 첫
달에는 약간 드러난 것처럼 보일 수가 있지만 전체적으로 봤을때는 실제로
여러분들의 서비스 가격이 절감 됐다 라고 확인을 하실수가 있습니다.
스팟 인스턴스 에 대한 사례에 대해서도 말씀드리도록 하겠습니다.
스팟 같은 경운 아까 말씀드렸던 것처럼 이제 2차 이제
가격 인스턴스 인데요 새로 여기 그래프에서 보시듯이 특정 나 외과 뭐
어떤 아래
이가격 자체의 입찰을 하는 금액이 다르다 보니 이런 그래프 형태로
여러분들이 스토리를 보실 수가 있습니다.
그래서 여러분 단기간에 수요가 많은 서비스를 구성을 하신다 라고 했을
때는 이렇게 2차 이제 인스턴스 를 통해서 기존 대비 의 뭐 최소 70
혹은 최대의 한 90% 정도의 가격 절감을 가지고 오실 수가 있구요.
그래서 이 aws 스팟 인스턴스 히스토리 페이지를 통해서 여러분들이
효과적으로 입찰자 인스턴스 의 가격을 결정 하실수가 있습니다.
그리고 비용 관리에 대한 대시보드에 대해서도 간략하게 설명드리도록
하겠습니다.
비용 관리에 대한 대시보드를 대시보드는
여러분들이 좀 더 투명하게 비용을 관리하고 그리고 객관적인 지표를 통해서
여러분들의 비용 설계를 하실 수가 있는 하나의 대시보드 라고 보실 수
있을 것 같습니다.
그래서 지금 현재 사용하고 있는 금액 그리고 어떤 류의 서비스들을 즉
많이 사용하고 있고 이 어떻게 비율이 이루어지는 지에 대한 부분 그리고
추후에 어떤거 뜰까 저희가 원하는 그래프 형태로 뭐 만드실 수도 있습니다.
그래서 이렇게 비용관리 대시보드를 통해서 여러분들이 효과적으로 비용
운영을 하실 수 있습니다.
이번 시간에 설계 방안에 대해서 알아보았습니다.
실제로 첫번째로 클라이언트 네이티브 앱의 설계 요소의 다양한 방안들을
알아보았는데요
5 코드 베이스 부터 로그 까지 다양한 클라우드 네이티브 앱에 대한 구성
요소 그리고 우리가 어떤 식으로 설계를 고민 해야 되는지에 대한 부분에
대해서 말씀드렸습니다.
이렇게 고민을 하신다면 은 여러분들이 추후에 여러분들 서비스 수준을 높일
수가 있고요 비즈니스 가치 로 도 연결될 수 있습니다.
두번째 aws 모범 설계사례 이번 시간에는 웹 그리고 미디어 온라인 게임
서비스의 몹은 사례에 대해서 알아보았는데요
이러한 설계지침 그룹 모험 사례를 통해서 여러분들이 기존에 가지고 계시던
설계 개념들을 보관하시고 그리고 다양한 클라우드에 대한 기능들을 활용하실
수 있게끔 서비스를 설계 하실 수 있습니다.
세번째 비용관리 aws 에서 투명하고 객관적으로 비용을 관리할 수 있게끔
빌링 콘솔을 통해서 비용 분석 만이 아니고 다양한
비용에 대한 구조를 지원을 하고 있구요. 또한 컴퓨팅 자원의 과금 모델이
여러개가 있는데 이것을 통해서 여러분의 효과적으로 비용을 운영 하실 수가
있습니다.