아마존 클라우드 AWS Essential 6강 컴포넌트에 대한 소결합 > AWS 클라우드

 

이번 차 시에서는 소개 랍 방식의 특징에 대해서 알아볼 건데요
첫번째로 aws 스토리지 서비스에 대해서 말씀드리도록 하겠습니다.
그리고 q 서비스를 통해서 어떤 식으로 aws 위에서 소개로 방식을
택해야 되는지에 대해서도 말씀드리도록 하겠습니다.
그 다음에 aws 의 앱 서비스 중에서 api 라던가 sns ses 에
대한 서비스를 통해서 소개 라 방식의 서비스 설계에 대해서 알아보도록
하겠습니다.
4 첫번째 aws 스토리지 서비스에 대해서 알아보도록 하겠습니다.
스토리지 란 말 그대로 디스크 들의 집합 혹은 2디스크 들의 집합을
어떠한 특정 프로토콜을 통해서 제공해 줄 수 있는 하나의 큰 데이터 볼륨
이라고 보실수가 있구요.
특히 이제 온 프라미스 환경 같은 경우는 다양한 방식으로 예를 들면 은
그림에서 볼 수 있듯이 센 뭐 다 쓰나 쓰 다음에 백업 혹은 아카이브
하는 스토리지 혹은 데이터베이스의 메모리 스토리지 같은 것들을 구축하여
서 사용할 해야 되는데 이런 데이터 스토리지 들이 패턴이 매우 다양하게
됩니다.
aws 에서도 스토리지 서비스가 다양한 패턴의 상 응하도록 스토리지
서비스들을 제공하고 있고요
특히 클라우드 환경에서 유연하고 비용 효율적이며 그 다음에 사용하게
편리한 특징들을 가지고 있습니다.
idc 에서 이렇게 다양한 스토리즈 들을
저희가 제공을 받고 있었고 구축을 해야 돼 썼구요
하지만 aws 위해서는
블락 스토리지 같은 쎈거 와 다 쓰나
가스 같은거 를 공유할 수 있는 블랙 스토리지 그 다음에 s3 혹은 뭐
클레이 5
까 튼 백업과 아카이브 혹은
앞장에서 말씀드렸던 rds 같은 데이터베이스 다음에 캐싱 서비스 인
플라스틱 케시
아 있습니다. 이렇게 온 프라미스 rt 환경에서 다양한 방식으로 제공해
주던 스토리지 서비스들을 그 패턴에 맞게
aws 에서도 다양한 방식의 소리지 서비스로 제공해 주고 있습니다.
그래서 aws 에서 제공하고 있는 스토리지 서비스의 목록에 대해서
간단하게 설명드리도록 하겠습니다.
첫번째 s3 확장성이 있는 웹 인터페이스에 클라우드 스토리지 라고 보실
수 있습니다.
저희가 http 기반 5 혹은 웹 프로토콜 기반으로
오브젝트들을 데이터들 뭔가 파일들을 업로드하고 다운로드 하실 수가 있고요
그것들을 확장성 있게 끔 제공해주는 스토리지 서비스다 라고 볼 수
있습니다.
그 다음에 클래시 어 라고 하는 아카이빙 스토리지 서비스 구요
특히 데이터를 저장해야 되는 것들 보관해야 되는 것들
예전에 데이터를 보관 해야 되는 아카이빙 용도의 스토리지 같은 경우는
당연히 낮은 비용으로
구성해 하셔야 됩니다. 이게 기본적인 일반적인 스토리지 보다 활용도가
떨어지기 때문에 낮은 비용 의 스토리지를 도입 하셔야 되구요.
그게 aws 에서는 근래 시어 라고 불리우는 서비스가 된다고 볼 수
있습니다.
블락 스토리지 중에서도 ebs
실제로 이스트 인스턴스의 연동되는
영속적인 블럭 스토리지 라고 볼 수 있습니다. clos 볼룸 이라던가
데이터 볼륨이 된다고 볼 수가 있구요.
여러분들이 데스크탑에서 가정했을 때 뭐 c 드라이브나
d 드라이브가 될 수가 있고요 리눅스의 관점에서 할 수 있는 모 루트
디스크 라던가 혹은 이 시스템에 있는 디스크가 될 수가 있을 거 같습니다.
그 다음에 블라스트 케시
실제로 이제 스토리지 중에서도 그 위에 올라오는 소프트웨어
위의 제 데이터베이스 와 같은 즉 캐싱을 하는 서비스가 존재를 하게
되고요
p0 스토리지의 물리적인 스토리지와 밀접하게 연관이 되는
임시적으로
으로 활용 하셔야 되는 캐싱 스토리지 라고 볼 수 있습니다.
임시 적이지만 가용성 은 뛰어나야 되구요.
추세로 데이터베이스 앞단에 서 캐싱을 해주기 위해서 존재하고 있는 서비스
이기 때문에 실제로 이 케시 서비스들이 스토리지를 다이렉트로 쓰지는
않지만 그 스토리지 바탕 위에 올라온 os 볼륨 위에 캐싱 메모리에
캐싱을 하기 때문에 개가 들고 있는 캐싱을 할 수 있는 데이터 블론
디스크 라던가 오노 이스 볼륨 같은 경우는 매우 가능성이 높아 야 되구요.
임시적인 특징을 가지고 또 있습니다.
그럼 레드 시프트 흔히
페타 바이트 규모의 빠르고 높은 성능을 내줄 수 있는 데이터 웨어하우스
라고 말씀드릴 수 있습니다.
여러분들의 서비스의 다양한 패턴이 라던가 혹은 다양한 트래픽 뜰의 조장이
될건데 소리지 형태로 저장이 될 건데 그런 것들을 추후에 통계 에 나
혹은 분석을 위해서 s3 보다는 레드 시프트 같은 데이터 웨어하우징 의
저장을 하셔야 g
추후에 보다 빠른 곳 높은 성능을 가지고 데이터를 저장을 하고
추출을 할 수가 있습니다. 엇 이렇게 다양한 스토리지 서비스가 있구요.
실제로 추가적으로 데이터베이스 서비스도 있지만 데이터베이스 서비스 같은
앞에서 설명을 드렸기 때문에 생략하도록 하겠습니다.
그래서 이제 이런 스토리지 서비스를 가지고 실제로 소결 합에 대한 설계를
어떻게 구성을 했냐 라고 봤을 때 하나의 예시로 들어서
aws 를 통해서
웹 스케일의 뉴스 서비스를 구성을 한다. 라고 가정했을 때 실제로 뉴스
서비스 같은 경우는 스토리지의 양이 매우 클 수 밖에 없구요
데이터 혹은 이미지 혹은 뭐 영상 같은게 저장이 되기 때문에 파일을
보관하는 보관 서도 있어야 되고요
이거를 공개를 할 수 있는 웹 베이스의 스토리즈 도 존재 하셔야 됩니다.
쉽게 말씀드려서 고객이 정보를 요청을 했다 라고 했을 때 그 웹서버를
돌리기 위한 os 볼륨 들이 있어야 되고요
그게 이제 ebs 라는 서비스로
존재 하게 되구요. 실제로 여기 위해 이스트 인스턴스가 함께 올라와서
이스트 인스턴스가 함께 올라와서 웹 아파치 라던가 통쾌 같은것을 같이 왜
베이스의 프로세스들을 돌릴 수 있게끔 지원을 해 주고요
그것들이 올라온 os 볼륨 에 데이터를 저장하는 게 아니고 세로 데이터
저장은
데이터베이스의 에 에 저장을 할 수가 있구요.
그리고 캐시를 통해서
앞단에 서 데이터베이스의 데이터를 유연하게 처리할 수가 있구요. 매끄럽게
처리를 할 수 있구요.
이렇게 저장이 정보를 요청을 받아서 뿌려 줘야 되는 상황이
실제로 웹 서비스 안에 있는 데이터 볼륨에서 저장을 공유 해 주는게
아니고 s3 를 통해서 이미지를 저장하고 공유할 수 있게 됩니다.
그리고 뉴스 서 비 스 같은 경우는
한달전 테이터 성분 1년 전 데이터 5년 전 10년 전 데이터 같은
것들을 어딘가는 보관을 하고 있어야 되는데 그 4일에 대한 보관을
브레이지어를 통해서 낮은 비용으로
팔 수 있게 됩니다. 이렇게 만약에 구성했을 때 여러분들이 기본적인 웹
서버에서 모든 데이터들을 처리해 주는게 아니고 기본적인 고객정보 데이터는
데이터베이스 혹은 케시
그 다음에 실제로 이미지 라던가 영상 같은 경우는 sc 를 통해서
저장하고 공유 하시고요
그 다음에 빨 저장소는 플레이어를 통해서 여러분들이 서비스를 보다 속여라
파악에 설계를 하실 수가 있습니다.
이렇게 소개 라파 게 설계를 했다 라고 가정 하에
보면은 웹 서버 웹서버 대로
확장성과 탄력성을 보자 하고 있구요.
데이터베이스 역시도 서로간의 탄력성과 확장성을 보장 할 수가 있습니다.
그리고 이미지 역시도 s 를 통해서 저장하기 때문에
웹서버 라던가 데이터베이스에 장애가 발생하더라도 소개 라비 돼 있기
때문에 추후에 esd 가 장애로 직결되어 있는 일은 발생하지 않습니다.
특히나 예전 데이터 같은 경우는 클래시 어 라는 팔봉 선생의 존재하기
때문에
s3 에서 장애가 발생 하더라도 이전에 사용하고 있던 데이터 같은 경우는
여러분들이 컨테이너 스하게 끙 게임업계 나중에 고개가 한테 정보를 제공할
수도 있구요.
이렇게 소 결 합 된 시스템을 구성을 하실수가 있습니다.
4 aws 앱 서비스 중에서 sq s 에 대해서 알아보도록 하겠습니다.
aws 에서 소 결합된 시스템 이라고 대표적으로 말하는 게 이렇게 이런
큐 서비스 구요
우선 q 서비스에 대해서 간략하게 먼저 말씀드리면 은 데이터의 손실이
없고 안전하며 확장성이 있는
메세지 대기 큐 서비스를 제공하는게 sq 에스라는 써 있습니다.
실제로 튜 서비스를 통해서 구성을 한다. 라고 했을 때는
여러분들이 첫번째로 이제 비동기 형태로 서비스를 구성할 수가 있구요.
또한 비용 효율적으로 관리 역시 가능할 수 있습니다.
간단하게 예시를 들어서 말씀드리도록 하겠습니다.
첫번째 이제동 기영 서비스인 싱크 론
버스 안 서비스인 경우 a 라는 사람이 b 라는 사람한테
뭔가 메시지를 전달을 할 때 동일한 시간 동일한 공간에서 특정 메시지를
전달 하고 응답을 받을 수 있는게
싱크로 나스 한 서비스가 볼 수가 있습니다. 하지만 이동일 시간과 공간의
있어야 하기 때문에 a 와 b 의 시간적인 재앙과 물리적인 세안이 존재할
수밖에 없고요
하지만 이제 비동기 형태로 구성한다. 라고 했을 때는
실제로 현재 실 생활에 살해 라고 볼수도 있는데요
우편함이 하나가 있구요. a 라는 사용자가 피라는 사용자에게 전달을 할
때는
실제로 비동기 형태로 메시지를
우편함에 다가 전달을 하구요
이 사용자는 시간이 될 때 혹은 다른 공간에서도
2 우편함에 접속을 해서 셋째로 자기가 받은 메세지들을 확인할 수가
있습니다.
제가 비동기 형태로 구성을 가능하게 해주는 계획
멧세지 서비스라고 볼 수가 있구요.
메세지 서비스가 구성이 실제로 가능하게끔 sq s 라는 형태로 atos
제공해주기 해주고 있고요
s 케이스를 제공을 해서 저희가 서비스 설계를 했을 때는 수평적인 확장을
가능하게 끔 합니다.
실제로 여기에 다른 시간과 다른 공간에 있는 사람이 메시지를 전달하는데
이 한 개가 아니고
5000개 라고 했을 때 아내의 동일시간 내에 동일 공간에 있다면은
2000개 에 자비 끝날 때까지 일하는 사람과 일하는 사람은 존재를 해야
됩니다.
하지만 a 라는 사양 사용자가 청결을 보내는데 이라는 사용자의 물리적인
공간이 라던가 시간에 제약없이
q 서비스를 통한다.면 은 청계 를 보내 놓구요
d 서비스는
시간이 좀 가능할 때 혹은 물리적으로 가능할 때 2000개 에 대한
메일을 읽을 수가 있습니다.
이렇게 만약에 구성을 했을 때 삐 라는 사용자가 아니고 모피 다시 라는
별도의 사람이 있다고 가정했을 때 는 이 두 사용자가 같이 이것들을
처리를 할 수 있기 때문에 수평적으로 확장이 가능 하구요
오피 다시 다시 또 날 수도 있구요. 이렇게 cpu 작업들
실제로 이 이스 사용자는 cpu 작업들을 수행하게 되어 있구요. 서버 라고
쳤을때 는 그래서 서버 가 서버를 수평적으로 확장해서 이런 메시지를
처리할 수 있게끔
수평적 의 확장이 매우 중요한 설계 방법 이라고 보실 수 있습니다.
그래서 보다 기술적으로 말씀을 드리도록 하겠습니다.
실제로 q 서비스를 통해서 소개 업된 서비스 설계에 대해서 이런 이제
그림이 많이 나오는데요
방금 앞에서 말씀드렸던 비동기 형태의 서비스 구조라고 보실 수 있습니다.
실제로 a 라는 컨트롤로
a 라는 프로세스가 하나가 있구요. p 라는 프로세스가 있구요.
c 라는 프로세스가 있는데 얘네들이 각각 데이터를 서로 주고받아야 된다
라고 가정하겠습니다.
서로의 데이터를 년 기본적으로 큐 서비스 를 통하지 않고 데이터를
전송하기 위해서는 직접 통신을 해야 되고요
이럴 경우는 이제 싱크로나이즈 트 1 서비스라고 볼 수가 있습니다.
그래서 aoa 가 서비스의 혹은 데이터를 보낼때
이 역시도 그거에 받을 수 있게끔 지금 되게 하고 있어야 되고요
삐 가 끝나는 동시에 씨에게 보낼 수 있도록 c 역시도 대기하고 있어야
됩니다.
이럴 경우는 리소스의 자원에 대한 낭비 라던 혹은 확장성이 떨어질 수
밖에 없습니다.
하지만 큐를 통한다.면 은
a 라는 서비스가 삐 라는 서비스로 보낼 때
추의 따 가만 데이터를 넣기 하면 되구요.
비 역시 가용 하는 시간에 취해서 작업을 받아와서 처리를 하게 할 수
있습니다.
이럴 경우 피라는 서비스의
트래픽이 큐에 목회 수가 많다 며 고 3때는 수평적으로 확장을 해서
이것들을 효율적으로 처리할 수가 있고요
b 역시도 작업이 얼려 두면 q 에다가 쌓고 씨가 이 취해서 받아갈 수
있게끔 설계를 할 수 있습니다.
이럴 경우 a 와 b 에 통신이 단절이 되는 장애 현상이 발생을 하더라도
실제 데이터는 큐에 있기 때문에 데이터의 로스는
없습니다. 데이터의 손실은 발생하지 않구요 피나는 서비스가 다시 올라와
오고 큐에서 데이터를 받아 갈 수만 있으면 은
이라는 서비스는 장애가 낮지만 영속적으로 서비스를 할 수 있는 컴포넌트가
될 수 있습니다.
이렇게 해서 소 결합된 서비스를 설계를 하셔야지 추후에 발생되는 장애
현상이 라던가 혹은 저희가 예상치 못한 트래픽에 대해서 대응을 하실수가
있습니다.
그래서 q 서비스를 통해서
구성원 1 컴퍼넌트의 특징에 대해서 말씀드리도록 하겠습니다.
컴퍼넌트 별로 소결 합이 되어 있기 때문에
음 다시 말해 독립적으로 분리가 되어 있다보니 확장성이 있구요.
앞에서 말씀드렸던 것처럼 a 라는 서비스 업 이라는 서비스와 시 라는
서비스가 같이 지금 현재 같은 시간에 같은 공간에 존재할 필요가 없고 추
를 통해서 독립적으로 존재를 할 수 있기 때문에
b 라는 서비스에 대해서 cpu 작업에 많이 필요하다 라고 했던 비를
확장성 있게 늘릴 수가 있구요.
그런 설계가 가능해 진다 라고 말씀드릴 수 있습니다.
그 다음에 말씀드렸던 것처럼 컴퍼넌트의 장애와 측 10 되지 않게끔
데이터 통신을 할 수 있습니다.
스트로 데이터의 손실이 없기 때문에
장애가 발생하더라도 저희가 중요하게 생각하는 데이터들은
손실이 없기 때문에 다른 서버 가 올라와 cpu 작업을 하고 처리를 할
수가 있구요.
이렇게 컴퍼넌트의 장애와 즉결 되지 않도록 데이터 동시 미추 를 통해서
할 수 있습니다.
세번째로 데이터 멧세지 운영에 대한 관리 소스 절감
실제로 여러분들이 큐 서비스 를 만든다 라고 가정했을 때 는 극히
서비스를 관리하기 위해서 관리하는 모니터링 서비스 라던가 공금 큐 서비스
이중화 구성 이라던가 고가 형성 일하다가 내 결함을 높이는 작업들을
하셔야 됩니다.
이런 관리 소스가 들어 갈 수 밖에 없구요 이거는 당연히 비용 문제와도
직결되는 부분이 부분입니다.
하지만 sq sat2 rs 제공하는 q 서비스를 통한다.면 은
관리 d 소스 역시 aws 에서
관리를 해주기 때문에 여러분들이 운영할 필요가 없이 그냥 안정적으로
쓰시려면 하시면 됩니다.
비슷하게 비용 효율성 역시도 확보할 수가 있습니다.
관리 소스가 들지 않고 내 결함이 높고 안정성이 있는 추 서비스를 제공해
주기 때문에 저희는 비용의 변의 하지 않고 효율적으로 비용을 관리할 수가
있다 라고 말씀드릴 수 있습니다.
4 세번째 aw 서비스 중에서도 api 서비스 sns ses 대해서
알아보도록 하겠습니다.
첫번째로 api 서비스 에 대해서 말씀드리도록 하겠습니다.
api 서비스 는 최근에 릴리즈된 서비스 고요 어떤 규모의 서든 개발자가
api 를 손쉽게 생성하고
개시하고 유지 관리하고 모니터링하고 보안 할 수 있게 해주는 완전 관련
서비스 라고 보실 수 있습니다.
실제로 앞에서 말씀드린 q 서비스와 동일하게 추상화된 레이어의 제공해주는
서비스 구요
aws 에서 인프라스트럭처 책임 모델이 아닌 앱스 트릭 tv 된 책임
모델을 관리해주는 모델이라고 보실 수 있습니다.
그래서 저희는 뭐 트랩 깨게 관리 허 남부역 엑세스 제어 모니터링 api
버전 관리
수십만 건의 잎의 호출과 동시에 작업된 은
호출되는 api 호출 되는 작업들과 모든 작업들을 api 서비스를 통해서
관리를 할 수가 있고 운영을 할 수가 있습니다.
실제로 저희가 api 서비스 를 활용한다.
저희가 만드는 서비스가 앱 서비스 중에서도 api 가 매우 중요한 서비스
다 라고 했을 때는 그 중앙에서 api 를 받아 주는
중앙 api 의 게이트웨이 같은 큰 서버 가 있구요. 안정적 이에 되어야
될 거구요
2 서버 안에서 컴퓨팅 자원 들에게
이것들을 트랙들을 라우팅을 시켜 주거나 혹은
프로토콜을 변화 시켜 주거나 혹은 보안 이라던가 옷 잇힝 에 대한
기능들을 제공을 하여야 됩니다.
이런 것들을 실제로 여러분들의 api 게이트웨이 왁스 탄 속성의 서버를
하나 만든다고 가정해 쓸 때는 이 중앙 구성 당연히 하셔야 되고요
spf 제가 얼음이 에서 이중 하고서 하셔야 되구요. 그리고
이것들의 소결 압둘 시키기 위해서 다양한 방식으로 시스템을 높게 기술적인
난이도가 있고 있는 시스템을 구성 을 하셔야 됩니다.
하지만 aws 에서는 api 게이트웨이 라는 것을 통해서 추상화된
서비스를 제공해 주고 있구요.
이것들을 활용했을 때 안정적이고 그리고 비용 효율적으로
라우팅 이라던가 이 pilot 프로토콜 편은 보안 이라던가 감시를
atos 지원을 해준다 라고 볼 수 있습니다.
그리고 두번째로 aws 에서 푸시 서비스가 있습니다.
sns 라고 말하는 심플 로트 pk 션 서비스 라고 불리우는데요
sns 는 어플리케이션 보건 최종 사용자의 디바이스의 알림을 전송하고
그리고 클라우드의 알림을 쓰신 하도록 하는 웹 서비스 라고 볼 수
있습니다.
실제로 sns 를 통해서 메시지를 젊다 를 했을 때
휴대성 높은 푸시 알람 서버를 제공하고 요
aws 에서 그리고 클라우드의 가장 큰 특징 중에 4가지 등 중에 1개인
종량제 과금 정책을 이 서비스 역시 따르기 때문에
운영 비용과 관리 비용의 효율성을 제공받게 됩니다.
실제로 fc 를 보내는 일은
여러분들 어플리케이션 1 구성하고 하루에 뭐 잦으면 한두번이 생길 수도
있지만 보통 한 달에 한 번 혹은 5주기 주기적으로 뭐 6개월에 한 번씩
뭐 알람 멧세지 라던가 혹은 노트 2를 보내게 되는데 그게 많이 있을
수도 있고 없을 수도 있는 상황에 푸시 서버를 1 난 우리가 구성을 해
가지고
푸쉬를 보낸다 라고 했을 때는 관리 비용과 운영 비용이 들 수 밖에
없습니다.
하지만 sns 를 통하면 은 안드로이드 라던가 ios fc 메세지를
저희가 원하는 시간에 원하는 만큼 보낼 수가 있구요.
이거 역시 과금을 종량제 베이스를 하기 때문에 건 당 얼마씩 황금을 하기
때문에 비용 효율적이다 라고 말씀드릴 수 있습니다.
4 그리고 이메일 서 비 스 ses 씸플비 메일 서비스에 대해서
알아보도록 하겠습니다.
앞에서 말씀드린 노티피케이션 푸시서비스 와 비슷하게
이메일을 보내는 서비스 구요 대량의 이메일을 발송할 수 있는 서비스 라고
볼 수 있습니다.
실제로 이메일 서버 역시도 여러분들이 구성을 많이 하게 된다 라고 했을
때는 서버관리 라던가 매트 워크 설정 그리고 isp 요구사항들을 알아야
되는데 이런 관리 소모적인 작업들을 aws 에서 대신 해주고요 저희가
원할 때 온 않은 만큼 종량제 베이스로 건당 얼마 c 고객에게 이메일을
점점 할 수가 있습니다.
그리고 추가적으로 모니터링 까지 같이 지원을 하고 있는데요
반송 이라던가 존 성 성공 실패 시 도 레 미 스팸처리 같은 것들을 하는
빌딩 패키지를 제공하고 요 그래서 이걸 모니터링을 통해서 효율적 인 매일
자원을 관리할 수가 있습니다.
그래서 실제로 여러분들이 매일 서버를 한나 구성 한다.고 가정했을 때 이런
다양한 서비스와 또 이중환 구성이 필요하구요 모니터링 까지 같이 필요한데
ses aws 에서 제공하는 팀플 이메일 서비스를 통한다. 라고 했을 때는
여러분들이 관리 부담 없이
다양한 고객에게 내일 을 손쉽게 대량으로 보낼 수 있고 그것 또한
모니터링 역시 가능하다 라고 볼 수 있습니다.
그래서 실제로 앱 서비스를 통해서 여러분들이 서비스를 설계를 하신다 라고
가정했을 때 어떻게 소 결 합 을 시킬 수 있냐 를 좀 더 자세하게 말씀
드리도록 하겠습니다.
실제 하나의 예로 aws 를 통해서 위치기반의 정보를 제공을 받고 싶은
서비스다 라고 가는 과정 했을 때
씨로 고객은 어느 위치에 가서 위치 데이터를
뭐 고객 디바이스의 깔려 있는 앱이 있을 거고요
앱을 통해서 현재 이 사람이 어디에 있다 라는 위치 데이터를 전송하게
됩니다.
금 api api 로 당연히 전송이 될거구요
mapi 를 처리해 주는 api 서버 가 있을 거고 그게 api 케이트
왜 라는 서비스로 존재하게 됩니다.
이 api 게이트웨이로 들어오는 api 들은
데이터 처리를 해야 되는데 축제로 어느 지점에 그리고 이 사용자가
사용자에게 추천해줄 수 있는 맛집 이라던가 혹은 정보 같은 것들을 처리를
해줄 수 있는 데이터 처리 에게 apk 트레이가 데이터를 옮기고 요
보면 데이터 처리는 20 투 인스턴스에서
뭐 cpu 작업을 통해서 데이터 처리를 하셔야 되구요.
뭐 당연히 집단 의 데이터베이스가 있을꺼고 그리고 이 가공된 데이터
그리고 정보가 처리가 완료된 데이터를 푸쉬 라던가 혹은 이메일로 전달을
9개는 시켜 줘야 됩니다.
고객 입장에서는 앱에서 계속 앱을 켜놓고 위치에 따라서 고객에게 정보
고객이 정보를 닿는 게 아니고 고객은 한번 요청한 다음에 워싱 크로노스
하게
데이터가 소개 라비 돼 있는 시스템에서 처리가 되고
푸쉬 메시지를 통해서 앱이 활성화 만 되어있다면 은 푸쉬를 받을 수 있게
됩니다.
혹은 이메일로도 정보를 전달할 수 있습니다. 그래서 실제로 실시간 내
기반한 위치기반으로
여러분들이 데이터 처리를 통해서 고객에게 보다 높은 품질의 서비스를
제공할 수가 있습니다.
4 지금까지 컴포넌트에 대한 소개 랩에 대해서 알아보았습니다.
첫번째로 aws 의 스토리지 서비스를 통해서 어떻게 컴포넌트를 소개 라
빌 시킬지 에 대해서 알아보았습니다.
실제로 온 프라미스 환경 뿐만이 아니고 다양한 환경이 여러 1 데이터들을
저장하고 관리하기 위해서는 다양한 패턴의 스토리지 서비스가 존재 해야
되고요
이와 상 되도록 aws 에서는 s3 라던가
ebs 라던가 플레이어 라던가 레드 시프트 같은 서비스를 제공해 주고
있습니다.
온 프라미스 학명 에 비해 보다 유연하고 비용 효율적이며 그 다음에
관리의 편리성 의 특징 또한 가지고 있습니다.
두번째로 aws 의 앱 서비스 중에서 sq s 에 대해서 알아보았습니다.
sq s 는 대표적인 소 결함에 대한 서비스 구요
데이터의 통신을 데이터의 손실 없이 안전하고 확장성이 있는 메시지 택이
서비스를 제공하고 요
비동기 의성에 특징을 가지고 있어서 추후에 발생되는 컴포넌트 의 구성 을
소개합 시키고 확장성 탄력성을 추가적으로 가져올 수가 있습니다.
마지막으로 웹서비스 중에서 api 서비스 sns 이메일 서비스는 ses
가 있습니다.
실제로 이런 q 를 비롯해서 api sns ses 는 aws 에서
추상화된 a 에서 제공하는 서비스 고요 그래서 aws 에서 제공을 해주기
때문에 안정적이며 확장 가능하고 그리고 여러분들의 서비스 품질을 여러분이
직접 뭐 만드는 서비스 보다 aw 관리해 주기 때문에 서비스의 품질을
극대화 시킬 수가 있고 그리고 과금 역시도 종량제 비용 구조로 하기
때문에 효율적인 비용 운용이 가능하다 라고 말씀드렸습니다.