IoT 에 대한 통찰을 길러보자. 
AWS IoT, Amazon Kinesis Firehose, Amazon Athena, and Amazon QuickSight

by Ben Snively | on  |  |  Comments

o_IoT_Minutes_1

AWS IoT 

보안이 제공되고, MQTT 와 HTTPS 프로토콜 기반으로 쉽게 디바이스와 연결할 수 있습니다. IoT 룰엔진은 끊임없이 들어오는 메세지를 처리하여 다른 AWS 서비스들에게 전달하여 상호 작용을 할 수 있습니다.

Amazon S3 

당신의 모든 데이터 (크던,작던)에 대해서 높은 신뢰성,보안성,확장성을 제공하는 객체 저장소이다.
99.99999999% 내구성을 갖도록 설계되었습니다.

Amazon Kinesis Firehose 

Amazon Kinesis Analytics, Amazon S3, Amazon Redshift, and Amazon Elasticsearch Service 로 자동적으로 데티러를 로드하여 스트리밍하게 하고, 캡처할 수 있게 합니다. 실시간 비지니스 인텔리전스를 가능케하고 데쉬보드를 사용 할 수 있습니다.

Amazon Athena 

SQL 을 사용하여 Amazon S3 의 데이터를 쉽게 분석할 수 있게 하는 상호작용적인 쿼리 서비스입니다. 

Amazon QuickSight 

클라우드 파워를 가지고 빠르게 비지니스 분석을 할 수 있는 서비스입니다. 간단한 ad-hoc 분석을 수행 할 수 있으며, 당신의 데이터에 대한 빠른 비지니스적 통찰을 얻을 수 있습니다.  Athena 를 S3에 저장된 데이터를 SQL 쿼리하여 사용하고, QuickSight 를 통해서 비지니스 데쉬보드를 구축하세요.



실습: Heartrate sensors


이 실습에서는 IoT MQTT 토픽에 메시지를 게시하는 여러 센서를 대리하는 스크립트를 실행하여 매 초마다 하나의 실습 메시지가 발행됩니다. 그 이벤트는 IoT 규칙이 구성되는 AWS IoT로 전송됩니다. IoT 규칙에 의해 모든 메시지를 캡처하여 Firehose로 전송합니다. 거기에서 Firehose는 메시지를 일괄적으로 S3에 저장된 객체에 씁니다. S3에서 Athena에서 테이블을 설정하고 QuickSight를 사용하여 IoT 데이터를 분석합니다.


더 자세한 사항은 아래 레퍼런스를 참고하세요. 



레퍼런스: AWS Big data blog



아마존 웹서비스 (AWS) 이용 가격


세부적으로는 요금계산기를 통해 알아보고 대충 머리속에 기억하고 있을만한 내용만 적어보았다.
여기서 나오는 가격은 모두 대략 이란 것을 명심하라. 각종 옵션에 따라 매우 달라진다.


정확한 계산을 위한 계산기는 여기 http://calculator.s3.amazonaws.com/index.html



S3 (스토리지) 


- 일반적인 저장소로서 1TB 저장하는데 한달에 대략 5만원  (1기가당 50원) 

- 같은 리전에 있는 EC2 와 S3 간의 데이터 전송에는 전송 요금이 청구되지 않음.

- Copy 요청을 통해 S3 지역에서 데이터를 전송한 경우 데이터 전송 요금이 청구되지 않음.

- S3 에서 인터넷으로의 데이터 송신은 1TB 월당 대략 15만원 ( GB 당 150원 )

 S3 의 get/set 횟수에 따른 요금이 부과된다.


Glacier (백업 스토리지)


백업용 저장소로서 1TB 저장하는데 한달에 대략 1만원  (1기가당 10원) 



EC2 (컴퓨팅)


온디맨드 (선결재나 장기 약정 없이 사용한 만큼) 


- t2.medium CPU 2개, 메모리 4기가 : 시간당 100원 한달 대략 7~8만원 

- m4.xlarge CPU 4개, 메모리 16기가 : 시간당 400원 한달 대략 25 ~만원 


스팟 인스턴스 ( 시작 및 종료 시간이 자유로운 애플리케이션, 컴퓨팅 가격이 저렴해야하는 경우)

 - 온디맨드보다 대략 반정도 싸다고 생각하면 된다. 


예약 인스턴스 ( 수요가 꾸준한 애플리케이션, 1년~3년동안 약정할 수 있는 고객)

 - t2.medium 은 1년 약정 기준 한달에 대략 6만원 , 3년 약정 기준 2만원 



RDS (관계형 데이터베이스)


PostgreSQL 기준 ( RDS 를 이용하면 스토리지 관리,업그레이드,복제,백업등을 관리) 


온디맨드 DB 인스턴스

- db.t2.medium  100기가 스토리지 + 100기가 백업 스토리지:   한달에 대략 10만원 

- db.m4.xlarge   100기가 스토리지 + 100기가 백업 스토리지:   한달에 대략 40만원 



Route53 (DNS) 


- 한달에 100만 쿼리면 천원 , DNS Failover Health Check 하면 만원까지 올라감. 



CloudFront (컨텐츠 캐쉬)


- Data Transfer Out 의 한달량이 1기가이고 10kb 데이터가 만번 요청되면 5만원.



IoT 플랫폼


- 메세지 백만개당 (512바이트 블록 기준, 최대 128kb 를 하나의 블록으로 전송)  7천원 
- 키네시스와 다른 점은 이것은 스트리밍 처리가 아니라는 점


예) 1개 디바이스가 10초당 1개의 500바이트 메세지를 IoT 로 보낼때 : 1 * 6 * 60 * 24 * 30 = 259200개 
     즉 4개의 디바이스가 10초에 한번씩 메세지를 전송하면 한달에 7천원 든다. 
     디바이스 4000개면 한달에 7백만원이다. 



Lambda (분산 실행 모듈)


-  모듈에 함수를 요청 할때 마다 과금됨.

-  매월 첫 요청 1백만 회까지 무료, 이후 요청 1백만회당 200원 
-  Lambda 에서 처리한 데이터를 S3 에 put 하는데는 S3 의 get/set 의 요금이 부과된다.

예) 1개의 디바이스가 전송한 데이터를 분삭할 모듈을 호출한다고 해보자. 10초에 한번씩 전송하면 
     한달에 1 * 6 * 60 * 24 * 30 = 259200번 호출된다.  디바이스 4개면 천원 든다.
     디바이스 4000 개를  분석하기위한 호출을 하는데 한달에 백만원이다. 



Kinesis Streams (데이터처리 스트림)
-  중요한건 스트리밍이라는 점.. ( 외부에서 생성된 ,디바이스라든지 데이터가 끊임없이 밀려들어 오는것 처리)


-  종량 과금제 

-  샤드 1개는 초당 1MB 의 데이터 입력 및 2MB 의 데이터 출력 용량을 제공

-  샤드 1개는 초당 최대 1,000개의 레코드를 지원한다.  

-  각 샤드에 대한 시간 단위로 사용료가 부과

-  샤드 시간 (초당 1MB 수신, 초당 2MB 송신 ) :   10원 

-  PUT 페이로드 유닛, 1백만개 유닛당 : 20원



Kinesis Firehose (데이터처리 인프라)


-  중요한건 스트리밍이라는 점.. ( 외부에서 생성된 ,디바이스라든지 데이터가 끊임없이 밀려들어 오는것 처리)


Amazon S3로 로드하기 위해 미국 동부 리전의 Amazon Kinesis Firehose로 스트리밍 데이터 레코드를 초당 1,000개 전송하고, 각 레코드 크기는 3KB인 경우, 월별 요금은 다음과 같이 계산됩니다.

월별 요금

미국 동부 리전의 수집 데이터 요금은 GB당 0.035 USD입니다.

3KB의 레코드 크기를 5KB 단위로 올림 처리 = 5KB

수집 데이터(초당 GB) = (레코드 1,000개/초 * 5KB/레코드) / 1,048,576KB/GB = 0.004768GB/초

수집 데이터(월별 GB) = 30일/월 * 86,400초/일 * 0.004768GB/초 = 12,359.62GB/월

월별 요금 = 12,359.62GB * 0.035 USD/GB = 432.59 USD

Amazon S3와 Amazon Redshift로 로드하기 위해 미국 동부 리전의 Amazon Kinesis Firehose로 스트리밍 데이터 레코드를 초당 5,000개 전송하고, 각 레코드 크기는 7KB인 경우, 월별 요금은 다음과 같이 계산됩니다.

월별 요금

미국 동부 리전의 수집 데이터 요금은 GB당 0.035 USD입니다.

7KB의 레코드 크기를 5KB 단위로 올림 처리 = 10KB

수집 데이터(초당 GB) = (레코드 5,000개/초 * 10KB/레코드) / 1,048,576KB/GB = 0.0476837GB/초

수집 데이터(월별 GB) = 30일/월 * 86,400초/일 * 0.0476837GB/초 = 123,596.19GB/월

월별 요금 = 123,596.19GB * 0.035 USD/GB = 4,325.87 USD


Kinesis Analytics (데이터 분석 인프라)


-  중요한건 스트리밍이라는 점.. ( 외부에서 생성된 ,디바이스라든지 데이터가 끊임없이 밀려들어 오는것 처리)

고객은 Amazon Kinesis Analytics를 사용하여 Kinesis Firehose에서 캡처한 스트리밍 데이터를 지속적으로 필터링하고 원하는 레코드만 보관합니다. 이 고객의 월별 Kinesis Analytics 요금은 다음과 같이 계산됩니다.

월별 요금

미국 리전의 요금은 스트림 처리 애플리케이션에서 사용한 KPU별로 시간당 0.11 USD입니다. 1KPU는 메모리 4GB, 컴퓨팅 1vCPU 및 해당 네트워킹 기능과 동일한 스트림 처리 용량을 제공합니다.

이 간단한 스트리밍 필터는 Firehose의 데이터를 처리하는 데 1.7GB의 메모리와 1vCPU의 50%를 사용합니다.

스트리밍 SQL 쿼리가 메모리를 4GB 미만 그리고 컴퓨팅을 1vCPU 미만으로 사용하므로, 애플리케이션에서 워크로드를 처리하는 데 1KPU만 있으면 됩니다.

월별 요금 = 30일 * 24시간 * (1KPU * 0.11 USD/시간) = 79.20 USD


고객은 Amazon Kinesis Analytics를 사용하여 Kinesis Stream에 캡처되어 있는 온라인 쇼핑 트랜잭션에서 판매된 항목의 1분 슬라이딩 윈도우 합계를 계산합니다. 이 스트림은 보통 초당 레코드 1,000개의 속도로 데이터를 수집하지만, 데이터는 하루에 한 번 프로모션 캠페인 중에 1시간 미만 동안 초당 레코드 6,000개의 속도로 급증합니다. 이 고객의 월별 Kinesis Analytics 요금은 다음과 같이 계산됩니다.

월별 요금

미국 리전의 요금은 KPU별로 시간당 0.11 USD입니다. 1KPU는 메모리 4GB, 컴퓨팅 1vCPU 및 해당 네트워킹 기능과 동일한 스트림 처리 용량을 제공합니다.

수신 Kinesis 스트림은 초당 레코드 1,000개의 속도로 데이터를 전송합니다. 하지만 하루에 한 번 1시간 미만 동안 Stream이 초당 레코드 6,000개로 급증합니다. 

  • 하루 24시간 중 23시간 동안 발생하는 '안정 상태'의 경우:

    슬라이딩 윈도우 쿼리는 데이터를 처리하는 데 3.2GB의 메모리와 1vCPU의 50%를 사용합니다.

    스트리밍 SQL 쿼리가 메모리를 4GB 미만 그리고 컴퓨팅을 1vCPU 미만으로 사용하므로, 이 시간 동안은 애플리케이션에서 워크로드를 처리하는 데 1KPU만 있으면 됩니다.

  • 하루 24시간 중 1시간 동안 발생하는 '스파이크 상태'의 경우:

    슬라이딩 윈도우 쿼리는 스트림의 더 큰 데이터 처리량을 처리하는 데 6.4GB의 메모리와 1vCPU의 75%를 사용합니다. 이 스트리밍 SQL 쿼리는 단일 KPU에서 제공하는 메모리를 초과하여 사용하지만, 2개의 KPU에서 제공하는 메모리 양인 8GB보다는 적게 사용합니다. 이 고객에게는 하루 24시간 중 1시간은 2개의 KPU에 대한 요금이 부과됩니다.

월별 요금: 

안정 상태 = 30일 * 23시간 * (1KPU * 0.11 USD/시간) = 75.90 USD

스파이크 상태 = 30일 * 1시간 * (2KPU * 0.11 USD/시간) = 6.60 USD

요금 합계 = 75.90 USD + 6.60 USD = 82.50 USD


사물인터넷을 위한 빅데이터 처리를 위한 AWS 살펴보기


다양한 기기로 부터 거대하게 생산되는 스몰데이터들을 빠르고 정확하게 처리하기 위한
AWS 의 솔루션을 살펴보면 IoT / 키네시스 / 람다가 발견된다. 과연 이들이 무엇이고 어떻게 다른지 살펴본다.
아직 본인도 개념이 많이 부족하기때문에 차츰 차츰 보완해나갈 예정이다.

먼저 다음 그림을 보고 대략 느낌을 받아보자~ (다양한 시나리오를 살펴보자)

AWS IOT ->  AWS 키네시스 -> Lamda 로 보내진다.


1. AWS IOT에서 데이터를 수집후 (룰엔진을 거칠수도 있고 안거칠수도 있고)
2-1. 데이터 그대로 S3 에 저장 또는 
2-2.키네시스로 보내져서 분석한후에 스토리지에 저장. 

1. AWS IOT에서 데이터를 수집후 (룰엔진을 거칠수도 있고 안거칠수도 있고)
2. 키네시스에서 분석
3. S3 에 저장
4. 람다서비스를 통하여 다양한 DB 에 저장 


1. AWS IOT에서 데이터를 수집후 (룰엔진을 거칠수도 있고 안거칠수도 있고)
2. S3 , DynamoDB, 키네시스등을 거쳐서
3. 사용자 서비스



overview 

1. 엣지디바이스로 부터 오는 데이터를 인증서비스에서 거르고 디바이스게이트웨이로 받는다.
2-1. 게이트웨이에서 데이터는 룰엔진에게 전달되어 데이터를 간략하게 룰대로 분석하여 반응한다.
2-2. 메세지 그대로 클라이언트에게 보여준다. 

방식

클라이언트AWS IoT 에서 제공되는 클라이언트 라이브러리 (C, Python 등)를 이용하여 우리측 GW 에서 MQTT 등 프로토콜을 가지고 AWS IoT 와 연결하고, 인증하고, 메세지를 보내준다. => SDK 받기

AWS IoT 디바이스 게이트웨이 :  게시/구독모델을 사용하여 디바이스와 메세지를 교환 합니다. 디바이스 게이트웨이는 인프라 프로비저닝 없이 수십억 개의 디바이스를 지원하도록 자동으로 확장합니다.
프로비저닝(provisioning) : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

AWS IoT 인증/권한 : 디바이스와 AWS IoT 간에 입증된 자격 증명 없이는 데이터가 교환되지 않습니다.
AWS 의 인증방법 (SigV4) 뿐 아니라 X.509 인즈서 기반 인증을 지원합니다. MQTT를 사용하여 연결하면 인증 기반 인증서를 사용할 수 있으며,  AWS IoT 에서 생성한 인증서 뿐 아니라 선호하는 인증 기관 (CA) 에서 서명한 인증서도 사용 할 수 있습니다. 이런 디바이스 인증서는 AWS IAM 를 사용해 구성된 관련 정책으로 프로비저닝 및 활성화 하고 해당 정책과 연결 할 수 있습니다.
앱 사용자에 대한 고유 식별자를 생성하고 제한적인 임시 AWS 자격 증명을 가져오는 데 필요한 모든 단계를 처리하는 Amazon Cognito 를 사용하여 사용자의 모바일 앱으로부터의 연결도 지원. 

AWS IoT 레지스트리 : 디바이스에 대한 자격 증명을 설정하고 디바이스의 속성 및 기능 같은 메타데이터를 추적합니다. 예를 들어 센서가 온도를 보고하는지 그리고 데이터가 화씨인지 섭씨인지와 같은 디바이스의 기능을 설명하는 메타데이터를 지원합니다. 

AWS IoT 디바이스 쉐도우: 디바이스의 최신 상태가 포함된 각 디바이스의 영구,가상 버전 또는 "섀도" 를 생성하여 애플리케이션이나 다른 디바이스가 메세지를 읽고 해당 디바이스와 상호 작용 할 수 있습니다.

AWS IoT 룰 엔진: 인프라를 관리할 필요 없이 글로벌 규모로 연결된 디바이스에서 생성된 데이터를 수집,처리,분석하고 이를 기반으로 조치를 취할 수 있습니다. 규칙 엔진은 AWS IoT 에 게시된 수신 메세지를 평가하고 정의한 비지니스 규칙에 따라 다른 디바이스나 클라우드 서비스로 이를 변환 및 전송합니다. 
규칙엔진은 AWS Lamda, Kinesis, S3, ML , DynamoDB, CloudWatch, Elasticsearch 같은 AWS 엔드포인트로 메세지를 라우팅 할 수 있습니다.  또한 규칙은 AWS Lambda 에서 Java, Node.js 또는 Python 코드가 실행되도록 트리거 할 수 있습니다.

전기충전데이터 <-> 게이트웨어 <--> AWS 게이트웨이 <--> 룰엔진 <--> 람다,키네시스 
<--> RDB,NoSQL,웹서버 <--> 클라이언트


충전인증요청처리 :  키네시스? 람다? 웹서버?  요청받으면 확인해서 DB 상태변경하고 
                          ㅇㅋ 콜 기기로 보내고..클라Noti

하트비트처리 (5분) : 키네시스? 람다? 웹서버?   DB 에 기기 상태 체크.

미터량 (15분 혹은 사용자가 요청하면 즉시) : 키네시스? 람다? 웹서버?   DB 상태변경하고 클라에 Noti

착,탈착 이벤트 :  키네시스? 람다? 웹서버?   DB 상태변경

즉 클라에게 즉시 노티가 필요하면 웹서버에서 처리, 아니면 상위 레이어(키네시스,람다)에서 처리.


* 롤엔진은 그냥 AWS 서비스로 라우팅만 해주는것은 어떨까?

우리 GW 는 MPC-1 역할
AWS GW 는 MMARS 역할
AWS IoT 룰엔진은 TRAMS 역할 
AWS Lamda 는 TRAMS 역할 
AWS EC2 (BeansTalk) 는 TRAMSDriver, W-MOS 역할  
패턴분석을 룰엔진/키네시스/람다중 어디에서 할지 고민. 아마도 키네시스에서 해야하지 않을까..

* 사용자가 앱에서 직접 콜하는건 미터 사용량 즉시 알기위한 이벤트밖에 없다. 
* 사용자가 받는 정보는 충전상태정보. 


AWS 키네시스

키네시스는 클라우드에서 장착해 아마존의 클라우드 내 데이터베이스, 레드시프트(Redshift)같은 웨어하우스, NoSQL 데이터베이스인 다이나모DB 또는 관계형 데이터베이스 등 다양한 소스에서 데이터를 받을 수 있는 애플리케이션이다. 이 툴은 데이터를 분석하고 데이터를 원 상태로 되돌려 놓는다. AWS는 자사 하드웨어와 소프트웨어를 결합해 사용하면서 이 툴을 개발했다. 시스템 도 확장성이 우수하며 수 천 개의 소스에서 가져온 데이터를 한 시간에 수 테라바이트까지 처리할 수 있다.


AWS 키네시스 Firehose http://www.itworld.co.kr/news/95914

AWS의 새로운 키네시스 파이어호스(Kinesis Firehose) 서비스는 기업이 모든 종류의 디바이스로부터 데이터 스트림을 모을 수 있도록 하는 데 중점을 두고 있다. 이 서비스는 사물 인터넷의 일부인 임베디드 디바이스를 포함해 다양한 스트리밍 데이터 소스를 AWS의 스토리지와 연결해 준다.기업은 단일 PUT API 호출을 사용해 디바이스의 전체 데이터 스트림을 가져와 AWS의 레드시프트 데이터베이스 서비스나 S3로 보낼 수 있다. 일단 데이터가 파이어호스에 도달하면, AWS는 이들 데이터를 즉각 선택된 스토리지나 서비스로 전송한다.
아마존은 기존에도 키네시스 스트림(Kinesis Streams) 서비스를 통해 비슷한 기능을 제공하고 있지만, 실제로 IoT 디바이스와 애플리케이션을 서비스에 연결하기 위해서는 기업이 맞춤형 애플리케이션을 구축해야 한다. 하지만 이 과정에 상당한 시간이 걸리는 것이 문제인데, 새로운 키네시스 파이어호스는 이런 시간이 없거나 핵심 프로젝트에 집중하고자 하는 기업에 유용할 것으로 기대된다. 또한 AWS가 마이크로소프트 애저의 IoT 스위트와 경쟁하는 데도 일조할 것으로 보인다. 
잉?? AWS IoT 랑 뭔차이?  룰엔진없는거?  이놈도 디바이스를 직접 통신하네? 

AWS IoT 가 있는데 AWS Kinesis Firehose 는 왜 만든건가요? 
(AWS IoT + 기타등등) + AWS Kinesis = AWS Kinesis Firehose -.-a

서비스가 사물과의 통신이면 AWS IoT 만 쓰던지, AWS IoT + AWS Kinesis 를 쓰던지하고 , IoT 가 아니라면 GW 역활 + AWS kinesis 를 합쳐서 AWS firehose 를 써라. 라고 이해하고 있습니다. 맞는지요?

근데 AWS Kinesis firehose 가 AWS IoT 를 대체할 수도 있는지요? 만약 그렇다면 AWS IoT 를 사용했을때와 달라지는점은 무엇일까요?


질문을 던져봅니다.

AWS 람다  http://www.bloter.net/archives/221869 (블로터 참고) 

특정 이벤트가 발생했을 때만 함수가 작동된다. AWS가 람다를 ‘이벤트 기반 컴퓨팅 서비스(An event-driven computing service for dynamic applications)’라고 표현하는 것도 이 때문이다. 현재 람다는 ‘S3’ 버킷 알림, ‘다이나모DB’ 스트림이나 ‘키니시스’ 스트림 이벤트, 커스텀 이벤트에서 얻은 정보로 함수를 실행시킨다.

좀 더 자세히 살펴보자. 블로그 사진 썸네일을 만드는 함수가 있다고 치자. 사용자는 썸네일을 생성하는 애플리케이션을 만들 수 있다. 이 애플리케이션은 블로그에 있는 사진을 읽고 크기를 조절하고 웹 저장소에 올리는 기능을 수행한다. 작은 기능이지만 애플리케이션을 실행하려면 운영체제, 미들웨어, 네트워크 등 인프라가 필요하다.

람다를 이용하면 다르다. 코드만 있으면 된다. 해당 함수를 실행시키기 위한 인프라 자원은 걱정할 필요 없다. 보안도 알아서 관리해준다. 해당 함수가 잘 작동되는지 분석 그래프를 볼 수도 있다. 마쿠 레피스토 에반젤리스트는 “서버 없이도 원하는 서비스를 만들 수 있다”라고 설명했다.

AWS 람다 실습해보기 블로그 가기

내 환경 

- 클라이언트 : windows 8.1

- EC2 서버 :  Ubuntu  14


http://theweak.tistory.com/52

http://behonestar.tistory.com/63


참고해서 했는데 안됬다. ㅜㅜ  왜 안될까 -.-a




아마존 웹 서비스 클라우드 디자인 패턴 설계 가이드 요약 


기본패턴

Snapshot패턴 (데이터 백업)



Stamp 패턴 (서버 복제) 



Scale up 패턴 ( 동적 서버 사용 업 / 다운 ) 



OnDemand 디스크 패턴 ( 동적 디스크 용량 증감)



가용성 향상 패턴

Multi-Server패턴 (서버이중화)

Multi-DataCenter패턴 (데이터센터 레벨의 이중화)

Floating IP패턴 (IP어드레스 동적 이동)

Deep Health Check패턴 (시스템 상태 확인)


동적 컨텐츠 처리 패턴

Scale Out패턴(서버 수의 동적 증감)

Clone Server패턴(서버 클론)

NFS Sharing 패턴 (공유 컨텐츠 이용)

NFS Replica패턴 (공유 컨텐츠 복제)

State Sharing 패턴 (상태 정보 공유)

URL Rewrite 패턴 (정적 콘텐츠 이전)

Rewrite Proxy 패턴 (URL 변경 프락시 설치)

Cache Proxy패턴(캐쉬설치)

Seheduled Scale Out 패턴(스케쥴에 의한 서버증감)


정적 콘텐츠 처리 패턴

Web Storage패턴( 고가용성의 인터넷 스토리지 활용)

Direct Hosting 패턴(인터넷 스토리지 직접 호스팅)

Private Distribution 패턴 (특정사용자에게 데이터 배포)

Cache Distribution패턴 (사용자와 물리적으로 가까운곳에 데이터 배치)

Renaming Distribution패턴(변경지연없는 배포)

Private Cache Distribution패턴 (CDN 을 이용한 프라이빗 배포)


데이터 업로드 패턴

Write Proxy 패턴 (인터넷 스토리지로 고속 업로드)

Storage Index 패턴(인터넷 스토리지 효율화)

Direct Object Upload 패턴(업로드 절차 간소화)


관계데이터베이스 패턴

DB Replication패턴 (온라인 DB 복제)

Read Replica 패턴 (읽기전용 레플리카를 통한 부하분산)

InMemory DB Cache 패턴(자주사용되는 데이터 캐쉬화)

Sharing Write 패턴 (쓰기 효율화)

Queuing 패턴 (시스템간의 낮은 의존도 구성)

 Priority Queue 패턴 (우선순위 변경)

Job Observer패턴(작업감시와 서버 추가/삭제)

Scheduled AutoScaling 패턴 (일괄처리서버의 자동 가동/정지)


운용보수 패턴

BootStrap패턴 (가동설정의 자동수집)

Cloud DI패턴(변경이 많은 부분의 분리)

Stack Deployment패턴(서버군 가동 템플릿화)

Server Swapping패턴(서버이전)

Monitering Integration 패턴 (모니터링 툴 일원화)

Web Storage Archive 패턴 (대용량 데이터 아카이브화)

Weighted Transition패턴(가중치 라운드 로빈 DNS를 이용한 이전)


네트워크 패턴

OnDemand NAT패턴(유지보수시 인터넷 설정 변경)

Backnet 패턴(관리용 인터넷 설치)

Funtional Firewall패턴(단계적 엑세스 제한)

Operational Firewall패턴(기능별 엑세스 제한)

Multi Load Balancer패턴 (복수 로드밸런서 설치)

WAF Proxy패턴(고가의 Web application firewall 의 효율적 활용)

Cloud Hub패턴(VPN지점 설치)



 


+ Recent posts