아마존 클라우드 AWS Essential 14강 AWS 성공 사례 > AWS 클라우드

AWS클라우드

아마존 클라우드에 대한 정보를 공유합니다

아마존 클라우드 | AWS Essential 14강 AWS 성공 사례

본문

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

 


 이번 시간에는 aws 성공 사례 중에서 플립보드 에 대한 서비스 설계
및 관리 사례에 대해서 이해 하실 수가 있습니다.
그리고 두번째로 슬랙 시스템에 대한 서비스 구성에 대한 부분에 대해서도
이해하실 수 있습니다.
그리고 iot 시스템 사례에 대해서도
말씀드리도록 하겠습니다.
첫번째 클리포드 성공사례에 대해서 말씀드리도록 하겠습니다.
플립보드 같은 경우는 여기 아래의 그림에서 보실 수 있듯이 크레이 칭
해서 펄스널 매거진 앱을 만들어 주는 하나의 앱입니다.
글로벌하게 성공한 매거진 앱 있고요
aws 위에서 서비스가 설계 되서 관리되고 운영되고 있습니다.
실제로 플립보드 같은 경우는 뭐 다양한 잡지만 영계 를 해야 되구요.
그것을 가지고 그 이미지를 가지고 뭐
다수 개 매거진 으 저희 사용자가 직접 만들 수가 있습니다.
제가 뭐 저도 많이 사용하고 있는데요 이런 다양한
뉴스들을 한 곳에 모아서 볼 수 있다는 큰 장점이 있구요.
그러다 보면 은 다양한 시스템들을 연동을 해야 되고 이 시스템과 어떻게
효율적으로 운영을 할 지에 대한 관리도 매우 중요하다고 생각합니다.
플립보드 구조 aws 에서 구현 된 클립보드에 구조에 대해서 간략하게
설명드리도록 하겠습니다.
실제로 프리 포드의 비 스
모바일 디바이스의 깔 있구요. 그 모바일 디바이스에서 프리 포드의 연동을
햄 다 라고 했을때 인증 이라던가 사용자 관리 같은 것들을 처음에 인증을
해야 되기 때문에 이쪽 웹서버 클리포드 프론트엔드 서버라고 분류해 는 웹
채 픽 뜰을 받아들 수 있는 하나의 인터페이스로 들어갈 거구요 트래픽
뜰이
그 뒤에 고객정보 라던가 혹은 뭐 상품 정보 매거진 정보 같은게 저장돼
있는
데이터베이스가 있을거구요 그 데이타베이스 와 연결되서
읽기 기능을 최대로 뽑아줄 수 있는 40 플립보드 같은 경우는 라이트가
많은 서비스 라기보다 리드가 90% 대부분의 트래픽 뜰 차지하는 하나의
서비스 라고 볼 수 있습니다.
그러다보니 데이터베이스에서 다양한 정보들을 읽어 와야 되는데 그 때
사용하는 블라스트 캐시의 memcached 기반의 블라스트 캐시가
있을거구요
그리고 분석을 위해서 oh 바스 가 있을 수도 있구요.
이렇게 돼 있는 고객정보 라던가 혹은 상품정보 매 거의 정보를 표적으로
서비스를 딜리버리 하고요
그 뒤에 실제로 플립보드 이미지
앱에 대해서 여러분들에게 서비스를 저장 전달을 해 주기 위한 하나의 관리
배치해 주는
웹의 트래픽 뜰을 웹 프론트엔드 에서 받아주고 요 이거에 대한 제
데이터베이스를
데이터베이스의 혹은 memcached 를 통해서 가지고 있구요.
여러분들이 원하는 매거진과 이런 것들을 잘 조합을 해서 줘야 되기 때문에
이런 백핸드 시스템에서 이 실제 매거진을 조합을 한다. 라고 보시면 될 것
같습니다.
그러면은 축제 e 서버들은
이미지를 조합을 한다.기보다 이미지의 메타 값들 어디에 어떤 이미지가 있고
절 s3 안에 있겠죠
어디에 어떤 이미지가 있고 그리고 이것들을 어떻게 조합을 할 건지 가
이쪽 단계에서 결정이 될 거구요
그래서 s3 로 바라보게 하구요
그러면은 클라우드를 통해서 플립보드 앱을 우리가 접근을 한다. 라고 했을
때 실제로 이 어떠한
페이지의 어떠한 이미지 어떠한 뉴스 어떠한 이미지가 저희가 앱에서 확인할
수 있는데
스트로 이 정보들은 msd 의 url 로 돼 있을 겁니다
그래서 이 이거에 대한 메타 정보를 이쪽 웹 쪽에서 트래픽을 트리퍼
데이빗 같고요
클리포드 앱이 그 다음에 수행될 때는 세로 이미지가 저장돼 있고 이
이미지를 캐싱을 하고 있는 클라우드의 프론트 h p
를 통해서 이미지들이 전달이 되게 됩니다.
그랬을 경우는 실제로 한 번의 트랜잭션 웹의 로그인 이라던가 이 사용자의
어떤 카테고리를 보여줘야 될 지가 이쪽 틀에 p e 에서 처리가 될
거고요
실제로 이미지 파일 같은 경우는 이 쪽을 통해서 가져오기 때문에 5
데이터 혹은 서비스가 소 결합되어 있다라고 보실수가 있습니다.
이렇게 됐을 때 글로벌로 나갈 때도 크게 문제가 발생하지 않는게
2 h p 가 전세계적으로 다 캐싱 이 되서 있기 때문에 플리 포드에서
이런 메타데이터 값들 만 정상적으로 잘 전달 해 줄 수가 있다면 실제로
중요한 이미지나 혹은 매거진의 파일 같은 경우는 s3 클라우드 프론트 를
통해서 어느 지역에 있는 사용자 더라도 효율적으로 서비스를 제공해 줄
수가 있습니다.
그리고 또한 서비스를 구성을 하고 그 다음에 다른 소셜 미디어 와 연동을
해야 된다 라고 했을 때는 비동기 형인 s qs 를 통해서 서비스 확장을
기능을 가져올 수도 있습니다. 그래서 이렇게 필히 포드가 aws 에서
심플하게 구성이 되고 있구요. 이 심플하지만 실제로 대규모 인프라 그리고
글로벌한 서비스가 클리포드 가 지금 하고 있는 서비스 입니다.
플립보드 사례 그리고 프리퍼드 가 aw 을 통해서 어떠한 부분을 기대
했는지에 대해서 간단하게 말씀 드리도록 하겠습니다.
첫번째로 플립보드 는 글로벌 향 서비스 였고 그리고
이미지 4 일드 영상 데이터들이 트래픽이 많기 때문에 대금 뭐 유저
트래픽의 도
수용할 수 있게끔 효율적인 인프라를 만들어야 했었습니다.
aws 를 통해서 뭐 다양한 특징 중에서 탄력성이 확정 성의 특징을 통해
유저 수용의 매우 효과적 이었구요 그리고 aws 를 통해서 5 클라우드
프론트 같은 경우는 비용 효율적으로 사용한 양에 비해서 줄 쓸 수가 있기
때문에 별도의 계약이 필요한 다른 cdn 콘텐츠 딜리버리
5 프로바이더 와 다르게 사용량 기반으로 사용을 할 수가 있기 때문에
가격 절감 및 글로벌 서비스로 나가는 뭐 그런 기능들 에 대한 성능
역시도 증대할 수 가 있습니다.
그래서 aws 를 통해 서플리 포드가 서비스 특성에 맞게끔 적절하게
시스템을 클라우드 서비스 앱을 클래스 서비스 활용을 함으로써 다양한 이런
확장성 탄력성 가격 절강
그리고 성능이 확장까지 가지고 왔다 라고 말하고 있습니다.
특히 이 그래프에서 볼 수 있듯이
사용자 당 들어가는 운영비용이 처음보다 지금이 훨씬 줄어 든다는 것을 볼
수 있습니다.
실제로 aws 에서 필 포드가 서비스를 런칭하고
사용자가 급격하게 늘어나고 있는 반면에
산 사용자 당 드러나는 비용은 오히려 절감이 되고 있습니다.
이 말은 aws 에서 서비스를 설계를 하고 활용을 할 때 적절한 비용
구조를 가진 서비스 들 그리고 이스턴 스타 입대를 최적화 시키고 그리고
오토 스케일링을 통해서 고객이 2명 들었더라도 인프라가 2배가 되는 게
아니고 고객의 2배 들더라도 그 고객에게 서비스 트랙 측의 맞게끔
인프라를 들리고 줄이고 탄력성 확장성을 가지고 오면서 이렇게 가격이 절감
됐다 라고 볼 수 있습니다.
그래서 실제로 처음에 이각이 올라간 부분이 있긴 한데 이거 같은 경우는
프리 포드가 3년 약장 계약을
걸면서 이 비용 초기 약정 비용이 들어가 따라 볼 수가 있구요. 그
다음부터는 할인 폭 그리고 적절한 인프라 구성을 통해서 효과적으로 인프라
수용을 했다고 볼 수 있습니다.
두번째 슬레 게 성공사례에 대해서 말씀드리도록 하겠습니다.
슬랙 같은 경우는 뭐 이 메시징 앱 이고요
뭐 이렇게 쳐 법 관리 툴로 도 현재 많이 쓰이고 있습니다.
그래서 뭐 다양한 뭐 채널 들 그리고 뭐 메세지들을
이 하나의 앱에서 관리를 할 수가 있구요.
슬랙 이 최근 들어서 다양한 환경에서 적절하게 많이 사용을 하고 있습니다.
기존의 운영을 하던 이메일 방식의 채팅 이메일 방식의
5 프로세스를 걷어내고 슬래브 로 많이 변화하고 있구요.
그래서 이 슬랭 역시도 aws 를 통해서 이런 데이터들을 안전하게
저장하고 고가용성 이 있는 서비스를 설계를 할 수 있었다고 합니다.
그에 대해서 간략하게 살펴보도록 하겠습니다.
실제로 슬랙 같은 경우는 뭐 앞에서 말씀드렸던 플리퍼 들은 비슷하겠지만
예측 불가한 대규모의 트래픽을
수용을 했었어야 됐습니다.
플리 포드와 비슷하게 끔 슬랙 또 런칭한 지 모 18개월 수준의 사용자
110만 그리고 3천만 꺼내 메세지들을 수용을 해야 됐구요
이거에 대해서 사실은 대규모의 트래픽이 발생 할 거고 이거에 대한 수용을
효과적으로 해야만 했습니다.
그리고 클리포드는 변화는 비즈니스에 적합한 it 를 활용해야 됐었습니다.
슬랩 같은 경우는 다양한 협업 관리툴 다양한 툴도 과 연동을 해야 했기
때문에
5 혁신을 지원하는 it 환경이 필요 했구요
당연히 실 속해야 되고요 그리고 민항 구조의 부서 들 그리고 이 다양한
서비스가 나오는 반면에 낮은 비용으로 운영을 해야 된다
이러한 챌린지 가 있었습니다. aws 에서 슬랙 의 구조에 대해서 간단하게
살펴보도록 하겠습니다.
아까 플립보드 와 약간 비슷한 그림일 수도 있습니다.
aws 에서 서비스 앱 을 설계하는 뭐 정석과 같은 하나의 그런 아키텍처
라고 볼 수가 있는데요
세로 이제 아마 전 라우 tc 를 통해서 도메인 왜 예를 들면 은 어떠한
서비스로 갈지 에 대한 결정을 위해서 해주고요
예를 들면 은 뭐 채팅에 대한 부분 그리고 데이터 저장에 대한 부분 s
를 통한 데이터 저장 그리고 오토 스케일링 지금 이력이 그림에서는 나와
있지는 않겠지만
20 2e 포토 스캔이 그래서 다양한 사용자들이 대규모의 트래픽을
일으키더 라도 이 하나의 웹 서버에서
적절하게 서비스를 받을 수 있는 오토 스켈링 이 마련돼 있을 거구요
그리고 마이 sql 같은 사용자 정보를 실제로 안전하게 저장을 해야 되기
때문에 집단 의 ys 퀘를 통해서 말 스킬 역시도 이 중 아 를 통해서
슬랩 같은 경우 이제 마스터 마스터 리플리케이션 을 활용을 했구요
이러한 것들을 작은 애들이 직접 운영을 하고 관리를 하고 있구요.
그리고 뭐 다양한 메시징 서버 역시도 awc 스트로 이루어지고 있고요 그
다음에 뭐 다른 시스템 들과 능동 할 수 있게끔 5 다르게 api
인터페이스 들이 프록시 형태로 저장 제공이 되고 있구요.
이렇게 슬릭 2 그 안에서
대규모의 트래픽 그리고 it 혁신을 가져 오기 위한 기능들을 계속 연동을
해야 되는 그 환경 이었구요 그 외에 대해서 aws 가 적절했다 라고
말을 하고 있습니다.
aws 에서 슬랙 이 설계를 하고 부서나 운영을 하면서 어떠한 부분을
기대할 수 있었는지에 대해서도 말씀드리도록 하겠습니다.
aws 위에서 에쎄 증액 같은 경우는 365일 24시간 안정적으로
돌아가야 되는 하나의 써 있습니다.
2 클라우드 aws 에서 지속적으로 클라우드 서비스를 제공함으로써
안정성을 높이고 그리고 슬링 에서 요구하는 it 혁신 들 을 가져오기
위한 다양한 기능들을 제공을 aws 에서 해주다 보니 자기네 슬랭 역시도
서비스의 품질 향상
기타 영화를 가지고 왔고 입어 에 대해서 기대하는 효과가 크다 라고 말을
하고 있습니다.
그리고 슬랙 같은 메세징 엡 에서 가장 중요한 것은 앞에서 말씀드렸던
플립보드 와 다르게 고객의 데이터를 안전하게 보관을 해야 되고 적절한
dr 시나리오가 있어야 됩니다.
플립보드 같은 경우에 실제로 저희의 고객 데이터가 들어가진 않고 요
고객이 원하는 어떠한 매거진에 카탈로그 정도만 수집이 되는 것이 실제로
제가 거기 위해 뭐 파일을 올려 된다거나 혹은 제 정보가 울린다 거나
이런 것들은 하신 클리포드 에서는 뭐 그런 서비스의 는 그렇게 정보를
수집하지 않습니다.
하지만 슬랙 같은 경우는 메시징 앱 이고 그 위에 올라가는
텔타 들이 제 고객 데이터 한거고 그게 안정적으로 보관이 되어야 되고요
그리고 그 하나의 환경이 무너졌을 때 다른 쪽에서 백업된 할 시나리오를
해서 서비스의 품질을 계속 약속된 품질의 맞게끔 제공할 수 있게끔
했었어야 됐습니다.
그래서 슬랙 에서는 aws 위해서
앞에서 앞차 스에서 말씀드렸던 것처럼 drc 날이요 그리고 다양한
서비스를 통해서 빠른 복구 및 장애 이벤트 대응을 가는 했다 라고 안
하고 있습니다.
마지막으로 iot 사례에 대해서도 말씀드리도록 하겠습니다.
iot 사례는 제가 직접 구성을 하고 설계라고 운영했던 사례의 이고요
그래서 iot 같은 경우는 우선 간략한 개념에 대해 설명드리면 은 사물의
다양한 센서와 통신기능 모듈을 탑재해 서 그리고 그 탑재된 임베디드
시스템을 통해서 데이터를 수집하고 제어하는 기술이 라고 말씀드릴 수가
있습니다.
그래서 저같은 경우는 스트라이 5치 기반 뭐 인텔 에디슨 기반의 iot
디바이스의
수집된 데이터를 awa 스스로 분석을 시켰구요 그거에 대해서 시각화 및
데이터 저장 까지 ars 수행을 했었습니다.
iot 자체가 기본적으로 이렇게 영역이 3가지 단계로 이루어진다 고
보실수가 있구요.
aws 에서 담당할 수 있는 단계가 2까지 단계라고 보실수가 있습니다.
이거는 iot 제 클라이언트에서 12
대대는
테이트 하구요 그래서 이런 것들을 aws 어떻게 효과적으로 설계할 수
있고 운용할 수 있는지에 대해서 뒤에서 자세하게 말씀 드리도록 하겠습니다.
뭐 구현 내역에 대해서는 뭐 자세하게 말씀 드린다 이보다 이러한 내역으로
저희가 부서 구현을 했고 실제로 실시간 스트리밍 서비스 킹의 시스 라던가
혹은 뭐 이에 말이 라던가 이런 것을 통해서 우리가 데이터를 가공하고
정보화 된 형태로 뽑아냈다 라고 보실 수가 있을 것 같습니다.
동작 방법 역시도 기본적으로 iot 기기처럼 뭐 센서를 통해서 수집을
하고요
그 다음에 저희가 뭐 심박수 감정 온도 그리고 다양한 센서를 통해서
데이터를 사용자 데이터를 가져 같구요
그것을 데이터 수집 한 다음 있 지금 제가 하고 있는 몸 상태와 제가
원래 기준으로 가지고 있는 몸 상태를 비교해서 대 풍류를 로 가공을
하고요
이거를 활용을 해서 다양한 것들로 사용을 할수가 있다는 것을 착안해서
설계를 하였습니다.
그래서 저희 같은 경우는 이러한 백분율을 토대로
저희가 운동을 할 때 제가 실제로 이것을 빨리 하고 있는지 혹은 오버
페이스를 하고 있는지 아니면 열심히 안하고 있는지를 객관적인 수치로
판단을 해서 그가 mr 은 많이 오버 페이스를 하고 있다 며 는 느린
비트의 음악을 틀어져서 좀더 컴 다운 할 수 있게끔 혹은 제가 열심히
하고 있지 않다면 빠른 비트의 음악을 틀어져서 조금 더 빨리 그리고
표적으로 운동할 수 있게끔 도와주는 1 art 길이었습니다. 그래서 그
이런 것들을 이해 말 혹은 뭐 다양한 laws 서비스를 통해서 구현
하였구요
그리고 끝난 쓸 때 운동량 레포트 역시 로 제공할 수 있게끔 설계를
하였습니다.
그래서 이 부조 에 대해서 자세하게 설명 드리도록 하겠습니다.
서비스 구조에 대해서 자세하게 설명 드리도록 하겠습니다.
서비스 구조 같은 경우는 앞에서 보셨던 뭐 클립보드 나 혹은
슬랩 꽈 좀 다르게 실시간 썽 데이터 분석이 필요한 경우가 iot
기계에는 많이 발생하고 요 그래서 실제로 사용자들
저같은 운동을 하는 사용자들이 이런 온도나 심박수 진동 감정 센서 같은
것들을 iot 5 수집이 되구요.
이것들이 처음에 당연히 it 기기 등록 뜰이 인증 같은 것들을 수행할
거구요
그 다음에 인증이 완료 가 됐다면 은 데이터 전송 같은 것들을 아마존
키네스 실시간으로 보통 시간에 분석을 할 수 있는 실시간 스트리밍 아마
적힌 의 실수로 수집을 하고 이거에 대해서 제가 공을 하고요
예를 들면 백분율 단위로 10초 단위로 업데이트 해서 뽑아내 줘야 되는데
그 외에 대한 가공을 여기 콜렉터 에서 의 가공을 하고요
그거에 대한 상태 같은 것들을 저장하는데
실제로 상태 저장 할때 백분율 단위로 저장을 하고 그것에 대한 비교
수치는
2 데이터베이스 에 있기 때문에 기존의 있는데 기준 운동 평균 상태 값과
오늘 상태 값 쯤 실시간 들어온 상태 비교해서
여기서 지금 내가 500% 로 운동을 하고 있는지를 판단할 수 있습니다.
이미 거 역시도 이해 말로 분석을 가능하도록 저희가 연동 했구요
그리고 이 상태 정보에 따라서 사용자에게 내가 많이 5 페이스를 하고
있다
아니면 더 열심히 해야 된다라는 상태 2 를 전달 해 주고요
이 상태만 전달 응 거 에서 끝나는게 아니고 왜 스트리
mp3 같은 파일이 있구요. 이것들을 스트리밍 형태로
제공을 할 수 있게끔 i 5th 기라 연동을 하겠습니다.
그래서 실제로 봤을 때 사용자 입장에서는 iot 기기를 통해서 내
정보들을 수집 2 되구요. 분석 영역 2
대구 요 그 다음에 전달 영역이 이런 부분이 된다 라고 보시면 될 것
같습니다.
이렇게 서비스를 구현 하실 때
앞에서 앞차 수 전차 수에서 계속 말씀 드렸던 것처럼 속여라 장애에 대한
디자인 g 탄력성 확장성을 항상 고민을 하시고 서비스 설계를 하셔야
됩니다.
다양한 서비스 트래픽 뜰이 들어오게 되면 사용자들이 대규모의 사용자들이
발생하게 되며 는 이 각각의 컴포넌트 별로 확장성 있게 구성을 하였고
요소 결합된 형태로 그래서 이 중앙에서 관리할 수 있는 데이터베이스
그리고 분석되는 모처 장소 그 다음에 뭐 인증하는 서버 다음에 수집되는
서버를 각각 별도로 분리해서 추후에 하나의 각각 독립적으로 확장을 하고
혹은 줄일 수도 있고 서비스의 활용도에 맞춰서 다양한 기능들은 붙일 수
있게 있게끔 못 백 엔드 서버 로드 활용할 수 있게끔 설계를 하였습니다.
이렇게 iot 기능에 대해서 aws 에서 5
수집 그리고 정보통 아 그리고 분석까지 할 수 있는 하나의 서비스 구조
돌을 표명 들었습니다.
4 지금까지 aws 성공사례에 대해서 살펴보았습니다.
첫번째 플립보드 3 플립 퍼 드 같은 경우는 말씀드렸던 것처럼 영상이나
이미지 같은 정적 파일 들이 많은 서비스 였구요
이것들을 전세계에 배포를 해야되고 서비스의 품질을 높일 수 있도록
클레이아트 프론트 활용을 적절하게 하였고요
클라우드 프론트 포맨이 아니고 다양한 aws 서비스를 통해서 서비스의
가치를 높이고 사용자들에게 적절한 큐레이션 을 할 수 있는 매거진 앱 을
성공적으로 런칭 할 수 있었습니다.
두번째 슬레 개 의 성공 사례 실제로 메세지나 정보 같은 것들은 안전하게
보관이 돼야 되고요 그리고 항상 접근할 수 있게 가능성이 높게 관리가
되어야 되는데 클라우드 환경 위에서 뭐 컴퍼넌트의 속여라 그리고 장애를
고려한 디자인을 통해서 항상 안전하고 가능성 높게 관리할 수 있었구요
이것을 바탕으로 서비스의 성공을 거둘 뿐만이 아니고 aws 의 다양한
서비스를 활용해서 비즈니스 it 혁신을 가지고 올 수 있는 비즈니스의
기능들을 지속적으로 추가 하고 있습니다.
마지막 라 25t 사례 젤 iot 를 디바이스를 통해서 수집된 데이터를
실시간 처리 뿐만이 아니고 분석 및 저장까지 aws 에서 다할 수 있게
설계를 할 수가 있구요.
그리고 디바이스와 디바이스 간의 상호 작용 혹은 디바이스와 서버 간의
활발한 상호작용이 가능하도록 설계할 수 있었습니다.
이렇게 aws 를 통해서 혹은 이런 컴포넌트에 대한 소개 랍 장애를
고려한 디자인 탄력성 확장성 다양한 클라우드의 의 기능 특징들을 통해서
여러 분들 역시도 성공할 수 있는 사례를 반드시 길을 기원 하도록
하겠습니다.

댓글 0개

등록된 댓글이 없습니다.

Total 14건 1 페이지

본 사이트의 컨텐츠는 명시적으로 공유기능을 제공하고 있는 공개된 자료를 수집하여 게시하고 있습니다.

저작권, 강의등록, 광고, 제휴등은 "관리자에게 문의"로 메세지 주시면 확인후 답변드립니다.

Menu