Category: AWS re:Invent*


AWS 개인 상태 대시 보드 – 신규 기능 제공

2008년 AWS는 서비스 상태 대시 보드를 시작했습니다. 그 당시에는 AWS 클라우드는 비교적 새로운 서비스였기 때문에 이 서비스는 고객이 각 서비스의 상태를 확인할 수있는 제일 좋은 방법이었습니다 (해당 블로그 게시물의 간단한 스크린 샷을 현재 대시 보드와 비교해서 보시면, 8년 만에 얼마나 기능이 개선되었는지 모실 수 있습니다.)

사실 현재 대시 보드는 각 AWS 서비스의 전체 상태를 표시하는 데는 적합하지만, 개인화된 정보를 제공하지는 않습니다. AWS 서비스의 전반적인 상태보다 내가 사용중인 AWS 서비스 및 리소스의 상태가 더 중요 할 수 있습니다.

개인 상태 대시 보드 출시
여러분에게 가장 중요한 정보를 제공하기 위해 오늘 부터 AWS 개인 상태 대시 보드를 제공합니다.

이름에서 알 수 있듯, 본 대시 보드는 여러분이 사용중인 AWS 서비스의 성능 및 가용성에 대한 개인화 보기와 함께 서비스 상태 변화에 의해 자동으로 알림을 제공합니다. 여러분의 클라우드 자원와 관련한 정보를 한곳에 모아 두도록 만들어졌으며, 영향을 줄 수있는 모든 문제를 보다 잘 파악할 수 있습니다.

대시 보드에 관심있는 항목이 포함되어 있으면, 콘솔 메뉴에 알림 아이콘이 표시됩니다. 요약 내용을 보려면 클릭하십시오.

미해결 문제를 클릭하면, AWS 인프라에 영향을 줄 수있는 문제가 표시됩니다. (테스트 데이터입니다.)

항목을 클릭하면 문제를 해결하는 방법에 대한 지침을 비롯하여 자세한 정보가 제공됩니다.

본 대시 보드는 예정된 활동에 앞서 미리 알려줍니다.

관심 있게 봐야 할 모든 정보를 제공하고 있습니다.

고급 사용자를 위한 추가 API 기능
CloudWatch 이벤트를 사용하여, 알림에 대한 응답 및 예약 활동에 대한 알림을 자동화 할 수도 있습니다. 예를 들어, 여러분의 EC2 인스턴스가 임박한 유지 관리 알림을 받았을 때, 신규 인스턴스로 적극적으로 이동하는 응답을 할 수 있습니다.

여러분의 회사가 AWS Business Support 또는 AWS Enterprise Support에 가입하면 새로운 AWS Health API에 접근할 수 있습니다. 본 API를 사용하여 기존 사내 혹는 서드파티 IT 관리 도구를 개별 대시 보드 정보와 통합 할 수 있습니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 New – AWS Personal Health Dashboard – Status You Can Relate To의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Batch – 배치(Batch) 컴퓨팅 관리 서비스 출시

제가 대학에 들어갔던 1978년에 Montgomery College 전산학과에는 IBM 370/168라는 메임 프레임이 있었고, 저는 카드 천공기를 통해 Job Control Language (JCL) 문법을 작성하는 것을 배웠습니다. (그 뒤로 FORTRAN, COBOL, PL/I 컴파일러가 나왔죠.) 작업한 카드 덱을 제출하기 위해 각 작업 식별자와 교환하여, IT 부서 운영자에게 건네 주면 인쇄된 결과와 카드 덱을 받으러 몇 시간 후에 다시 와야 했습니다. 결과물을 공부하고, 앞의 작업을 다시 하고 몇 시간 후에 오던 것을 반복하곤 했는데, 나중에 우리 작업의 실행 시간은 불과 몇 초 밖에 걸리지 않았다는 것을 알고 충격을 받았습니다. 학교 IT 부서에서 수행할 작업이 네 번째 우선 순위에 배정되었다면, 학생들이 준 것은 여덟번째로 매우 낮은 것이었습니다. 과거 우선 순위 선정 매커니즘의 목표는 중요한 업무에 우선해서 값비싼 하드웨어를 전부 사용하는 것이었습니다. 학교에서 학생들의 생산성은 자원을 효율적으로 사용하는 데 있어 후순위였던 것이죠.

현대적인 배치(Batch) 컴퓨팅
오늘날 배치(Batch) 컴퓨팅은 매우 중요합니다! 영화 스튜디오, 과학자, 연구원, 수치 분석가 및 기타 사람들이 쉽게 대용량 ​​컴퓨팅 성능에 접근할 수 있게 되어, 컴퓨팅 사이클에 대해 활용하고자 하는 열의를 갖게 되었습니다. 많은 기업 조직에서는 오픈 소스 또는 상용 작업 스케줄러로 사내 컴퓨팅 클러스터를 직접 구축하여, 이러한 요구 사항을 충족시키기 위해 노력해 왔습니다. 그런데, 여전히 과거와 같이 우선 순위를 적용할 수 밖에 없는 충분한 양의 컴퓨팅 용량은 아닌 것 같습니다. 이들 기존 사내 클러스터는 구축 및 유지 보수에 비용이 많이 들고, 동일한 서버에 동일한 사양의 대형 프로세서로 구성되는 경우가 많습니다.

우리는 클라우드 컴퓨팅을 통해 다양한 타입의 EC2 인스턴스를 신속히 제공할 수 있고, 변화하는 요구 사항에 따라 확장 및 축소 할 수 있는 확장성과 사용한 만큼 지불하거나 경매를 통한 가격 책정 모델을 통해 배치 컴퓨팅 모델을 보다 효과적으로 변경할 수 있다고 생각했습니다. 과거에는 AWS 고객 역시 EC2 인스턴스, 콘테이너, 알림, CloudWatch 모니터링 등을 사용하여 자체 배치 처리 시스템을 구축했습니다. 이런 것들이 매우 일반적인 AWS 사용 사례 였기 때문에 이를 위한 관리형 서비스가 필요하다는 결론을 얻었습니다.

AWS Batch 서비스 출시
배치 컴퓨팅에 대한 전체 관리형 서비스인 AWS Batch를 오늘 출시합니다. 이를 통해 배치 관리자, 개발자 및 사용자들은 배치용 클러스터를 따로 구축, 관리 및 모니터링 할 필요 없이 대용량 클라우드 컴퓨팅 자원을 활용할 수 있게 되었습니다. 소프트웨어 구매나 설치도 필요도 업습니다.

AWS Batch에서는 관리 상 불필요한 부담을 덜면서 동적으로 확장되는 EC2 인스턴스 세트에 여러분의 콘테이너 이미지와 애플리케이션을 통해 배치 작업을 할 수 있습니다. 클라우드를 통한 효율적이고 사용하기 쉬운 서비스로서 Amazon EC2 및 EC2 스팟 인스턴스가 제공하는 탄력성을 통한 대용량 병렬 작업을 할 수 있게 되었고, Amazon S3, DynamoDB 및 SNS 같은 기존 서비스와도 안전하고 쉽게 연동할 수 있습니다.

우선 AWS Batch에서 사용되는 몇 가지 중요한 용어와 개념을 살펴 보겠습니다. (배치 작업을 많이 하시는 경우 이미 익숙하실 수 있습니다.)

  • 작업(Job) – AWS Batch에 제공되는 하나의 작업 단위 (쉘 스크립트, 리눅스 실행 파일 또는 콘테이너 이미지)입니다. 작업 정의(Job Definition)에 의해 정의한 파라미터 값을 통해 EC2에서 콘테이너화 되어 실행 합니다. Job에서 다른 작업을 ID로 참조할 수 있습니다. AWS Batch에서는 각 작업을 독립적으로 실행하고, (파라메트릭 스윕 및 몬테카를로 시뮬레이션에 적합한) 어레이 작업(Array Jobs) 역시 지원합니다. 어레이 작업은 병렬적으로 작업이 되고, 동시에 가용 컴퓨팅 자원을 관리하면서 실행합니다.
  • 작업 정의(Job Definition) – 작업을 어떻게 실행할지 정합니다. AWS Identity and Access Management (IAM) 역할을 포함한 AWS 자원 접근 제어, CPU와 메모리와 요구 사항 등의 값을 설정합니다. 이러한 정보를 통해 개별 콘테이너 설정 값, 환경 변수, 마운트 지점 등을 정하게 됩니다. 개별 작업을 시작 될 때, 이들 값들이 재정의 됩니다.
  • 작업 큐(Job Queue) – 컴퓨팅 환경이 예약 될 때까지 작업이 있는 곳으로, 우선 순위 값은 각 대기열와 연결됩니다.
  • 스케줄러(Scheduler) –작업 큐와 함께 작업을 언제 어디서 어떻게 실행할지 결정합니다. AWS Batch 스케줄러는 FIFO(First-in, first-out) 기반이며 작업 사이의 의존성을 인지합니다. 우선 순위를 지정하고, 같은 컴퓨팅 환경 내에서 높은 우선 순위의 큐에 있는 작업부터 낮은 순서로 실행하게 됩니다. 스케줄러는 작업을 위한 적정한 크기의 컴퓨팅 환경을 설정하기도 합니다.
  • 컴퓨팅 환경(Compute Environment) – 작업을 실행하기 위한 관리 혹은 비관리 컴퓨팅 자원으로서, 관리 환경에서는 세부적인 수준에서 인스턴스 타입을 정의할 수 있습니다. c4.2xlargem4.10xlarge 같은 특정한 인스턴스 타입을 지정하거나, 여러분이 원하는 신규 인스턴스 타입을 간단히 지정해도 됩니다. 또한, Spot Market의 경매에 따른 백분율 값에 따라 최소, 희망 혹은 최대 vCPU 숫자를 지정하거나, VPC 서브넷을 지정할 수 있습니다. 이러한 지정 파라미터와 제약 사항을 기반으로 AWS Batch가 원하는 EC2 인스턴스를 효과적으로 켜고 관리하고 종료하게 됩니다. 또한, 직접 컴퓨팅 환경을 구성할 수도 있는데, 이 때 AWS Batch가 사용할 Amazon ECS 클러스터를 직접 설정하고 확장성을 관리하셔야 합니다.

AWS Batch 살펴 보기
AWS 관리 콘솔에서 AWS Batch를 사용할 수 있으며, , AWS Command Line Interface (CLI)나 AWS Batch API를 사용할 수 있습니다.

잠깐 살펴보면 상태 대시보드에 작업, 작업 큐 및 컴퓨팅 환경을 보실 수 있습니다.

Compute environments을 선택하고 Create environment를 통해 작업을 시작할 수 있습니다. 우선 관리형 환경(Managed environment)으로 작업 이름과 IAM 역할(자동으로 생성)을 선택합니다.

그리고 프로비저닝 모델(온디멘드 혹은 스팟)을 설정하고, 원하는 인스턴스 타입(또는 특정 타입) 및 컴퓨팅 환경(vCPU로 측정되는) 크기를 설정합니다.

컴퓨팅 자원과 보안 그룹 등에 필요한 VPC 서브넷를 선택함으로서 설정을 완료합니다.

이제 Create를 누르면, 배치 작업을 위한 컴퓨팅 환경이 (MainCompute) 몇 초내에 생성됩니다.

다음으로, 컴퓨팅 환경에 보낼 작업 큐가 필요합니다. Queues를 선택한 후 Create Queue를 클릭해서 설정을 진행합니다. 모든 값을 기본값으로 선택 한 뒤, 작업 큐를 내 컴퓨팅 환경에 연결하고 Create queue를 누릅니다.

이 역시 몇 초안에 진행 됩니다.

이제 작업 정의를 할 차례입니다. Job definitions를 선택하고, Create를 눌러 작업에 대해 정의합니다. (아래는 아주 간단한 작업으로 아마 여러분은 더 잘하실 수 있을 겁니다.) 제가 만든 작업은 sleep 명령어로 128MB 메모리와 1 vCPU에서 진행됩니다.

환경 변수를 전달하고 접근 권한을 비활성화한 뒤, 프로세스 사용자 이름을 지정하고 콘테이너 내에서 파일 시스템을 사용할 수 있도록 할 수 있습니다.

Save를 눌러 작업 정의를 완료합니다.

이제 작업을 돌려볼 차례입니다. Jobs을 선택한 후 Submit job를 누릅니다.

다양한 측면의 작업의 재정의, 부가적인 태그 추가 등의 기능을 활용할 수 있으며, 이제 Submit을 누릅니다.

그 뒤에 결과가 나옵니다.

Ruby, Python, Node, 또는 Bash 스크립트를 통해서도 작업을 정의할 수 있습니다. 예를 들어, 아래는 루비 코드로 만든 작업입니다.

콘솔에서 작업한 것과 같이 커맨드 라인에서도 create-compute-environment, describe-compute-environments, create-job-queue, describe-job-queues, register-job-definition, submit-job, list-jobs, describe-jobs 명령어로 같은 작업을 수행할 수 있습니다.

AWS Batch API를 사용하여 좀 더 흥미로운 방식으로 배치 작업을 할 수 있습니다. 예를 들어, 새로운 개체(예를 들어, 엑스레이 사진, 지진파 데이터 영상, 3D 이미지 정보)가 Amazon S3 버킷에 업로드 되었을 때 AWS Lambda 함수를 통해 개체를 조사하고, 이를 분석하여 메타 데이터를 뽑아 내거나 하는 작업을 수행할 수 있을 것입니다. SubmitJob 함수는 그렇게 얻어진 데이터를 Amazon DynamoDB에 저장하고 Amazon Simple Notification Service (SNS)로 알림을 보낼 수도 있을 것입니다.

정식 출시 및 가격
AWS Batch는 오늘 부터 US East (Northern Virginia) 리전에서 사용 가능하며, 곧 지원 리전을 계속 확대할 예정입니다. 추가적인 리전 확대와 아울러 AWS Lambda 함수 기반 작업 등 다양한 추가 기능도 선보일 예정입니다.

AWS Batch에는 추가 비용은 없으며, 여러분이 사용하는 AWS 컴퓨팅 리소스 비용만 지불하시면 됩니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Batch – Run Batch Computing Jobs on AWS의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스

온라인 세계는 우호적인 장소는 아닐 수 있습니다. 웹 사이트를 온라인으로 올리자마자 다운되거나 침입 당할 수 있는 여러 가지 유형의 공격 대상이 될 수 있습니다. DDoS (Distributed Denial of Service) 공격은 흔히 발생하는 문제 중 하나입니다. 인터넷 전체에서 취약한 자원을 모아서 특정 대상을 공격할 수 있게 됩니다.

아래에 세 가지 일반적인 유형의 DDoS 공격 타입이 있습니다.

응용 프로그램 계층 공격: 응용 프로그램 리소스를 사용하도록 설계되어 있지만, 실제로는 악의적인 요청 (HTTP GET 및 DNS 쿼리가 많이 사용됨)으로 구성됩니다. 예를 들어, 여러 개의 HTTP 연결을 열어 몇 초 또는 몇 분 동안 요청을 해서 과도한 메모리가 소모되도록 합니다.

고갈 상태 공격: 상태 별 프로토콜을 어뷰징하고, 각 통신 연결 당 많은 리소스를 소비함으로써 방화벽 및 로드 밸런서에 강한 스트레스를 유발합니다.

볼륨 공격: 실제 처리 할 수 있는 것보다 많은 트래픽을 네트워크에 보내거나, 가짜 쿼리를 발행하여 네트워크를 혼란시킵니다.

AWS Shield 신규 서비스
AWS Shield는 DDoS (Distributed Denial of Service) 공격으로부터 웹 애플리케이션을 보호하는 새로운 관리 서비스입니다. Elastic Load Balancing, Amazon CloudFront, Amazon Route 53와 함께 작동하며 다양한 유형, 모양 및 크기의 DDoS 공격으로부터 사용자를 보호합니다. 두 가지 계층의 서비스가 있습니다. 여기에 두 가지 계층의 서비스가 있습니다.

AWS Shield Standard: 비용 없이 모든 AWS 고객이 사용할 수 있습니다. SYN/ACK Floods, 반사 공격 및 HTTP 저속 읽기와 같은 가장 일반적인 공격의 96 %를 방지합니다. 이 보호 방식은 Elastic Load Balancer, CloudFront 배포 및 Route 53 리소스에 자동으로 적용됩니다.

AWS Shield Advanced: 볼륨 공격, 지능형 공격 탐지 및 애플리케이션 및 네트워크 계층에서의 공격 완화를 위한 DDoS 완화 기능을 제공합니다. DDoS 공격의 여파로 인한 비용 청가 증가를 방지하기 위해 고급 실시간 통계  보고서 및 DDoS 비용 보호와 사용자 지정 완화를 위해 DDoS 대응 팀 (DRT)에 24 시간 연중 항상 지원 받을 수 있습니다.

더 자세한 사항은 AWS ShieldGet Started with AWS Shield Advanced를 참고하시기 바랍니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Shield – Protect your Applications from DDoS Attacks의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS CodeBuild – 완전 관리형 빌드 서비스 출시

모든 개발자는 소스 코드 변경이 일어날 때, 지속적인 통합 빌드(build) 생성 및 테스트를 실행하기 위해 공유 빌드 서버를 설정하고 운영 해야합니다. 유지 관리에 대한 부담으로 인해 다수 개발자들이 로컬 컴퓨터에서만 빌드를 만들어, 정식 서버에서 실행함으로서 한 명의 개발자에게는 동작하는데 다른 개발자에게는 동작하지 않는 상황을 초래합니다. 많은 개발 팀은 지속적 통합(Continuous Integration, CI) 및 배포 (Continuous Deployment, CD) 파이프 라인의 일부를 사용할 수 있습니다. 이러한 빌드팜의 설치 및 유지 보수 비용은 여전히 높으며 전혀 다른 운영 기술이 필요합니다. 사용률이 100%에 도달하고 빌드 요청 백 로그가 증가하는 경우를 제외하고는 가볍게 사용합니다.

AWS CodeBuild 서비스 소개
오늘 이러한 문제를 해결 해줄 AWS CodeBuild를 출시합니다. 빌드 서버를 설치, 설정 및 확장 및 패치 등에 신경쓰지 않고, CodeBuild를 활용하여 개발 과정에서 유연상을 보장하고 여러 형태의 빌드 상태나 호환성의 불일치 문제를 해결할 수 있습니다.

CodeBuild를 사용 하면, 사전에 빌드 서버를 프로비저닝 할 필요가 없으며, 대기중인 빌드를 쌓아 두는 대신에 빌드 볼륨을 활용할 수 있도록 자동으로 확장됩니다. 분당 $0.005부터 시작하는 가격으로 분당 기준으로 빌드 리소스에 비용을 지불하기 때문에 사용한 시간만 비용을 지불합니다.

CodeBuild는 완전 관리형 빌드 서비스로서, 탄력성과 확장 가능하며 사용하기 쉽습니다. 처음 빌드 서비스를 시작하려면 빌드를 수행하는 데 필요한 정보가 들어있는 빌드 프로젝트를 만들기만 하면 됩니다 빌드 프로젝트에 다음 요소가 포함됩니다.

  • 소스 레포지터리 – 소스 코드 위치 (AWS CodeCommit, GitHub 또는 S3 bucket).
  • 빌드 환경 – 언어 및 런타임 환경 (Android, Java, Python, Ruby, Go, Node.js, Docker).
  • IAM 역할 – 다른 AWS 자원으로 부터 CodeBuild  접근 허용.
  • 빌드 스펙 – YAML 양식 빌드 명령어.
  • 컴퓨팅 사양 – 사용할 컴퓨팅 및 메모리 사양  (최대 8vCPU 및 15 GB 메모리).

CodeBuild는 완전히 격리된 신규 콘테이너 기반 환경에서 각 빌드를 수행합니다. 빌드를 시작하면 아래와 같이 진행합니다.

  1. CodeBuild는 빌드 프로젝트에서 지정한 빌드 환경을 기반으로 콘테이너를 시작합니다. Android, Java, Python, Ruby, Go, Node.js 및 Docker (Docker 이미지 작성용)에 대한 맞춤형 발드 환경을 제공합니다. Docker 허브 또는 EC2 Container Registry를 참조할 수 있습니다. 선별된 빌드 환경에는 AWS SDK 및 AWS 명령 줄 인터페이스 (CLI)를 사용할 수 있습니다.
  2. CodeBuild는 빌드 도중 생긴 모든 커맨드 라인을 모아서 AWS 관리 콘솔에서 볼수 있습니다.
  3. CodeBuild는 빌드 프로젝트에 지정된 소스 저장소에서 코드를 가져옵니다.
  4. CodeBuild는 빌드 프로젝트에서 지정한 명령을 실행합니다. 각 명령은 프로젝트 빌드 스펙에서 식별된 설치, 사전 빌드, 빌드 및 빌드 후 단계를 포함 할 수 있습니다.
  5. CodeBuild 생성된 실행 파일 또는 결과물(artfacts)를 S3에 업로드합니다. AWS Key Management Service (KMS) 암호화는 선택 사항입니다.
  6. CodeBuild는 빌드에 사용 된 콘테이너를 삭제합니다.

AWS CodePipeline 빌드 서비스 공급자 중 하나로 CodeBuild를 사용할 수 있습니다. 기존 CI/CD 프로세스를 도입하고 있는 경우, 개발 프로세스를 완전히 자동화 할 수 있습니다. CodeBuild는 S3 및 AWS Identity and Access Management (IAM)와 같은 다른 AWS 서비스를 사용합니다.

선별된 빌드 환경에는 AWS CLI 및 AWS SDK가 포함됩니다. 이를 통해 CodePipelineAWS SAM를 사용하여 서버가 필요없는 응용 프로그램을 위한 완전 자동화된 CI/CD 워크 플로우를 만들 수 있습니다. npm 또는 pip 패키지를 만들고 AWS CLI를 사용하여 패키징 및 배포할 수 있습니다.

CodeBuild의 모든 기능은 AWS 관리 콘솔, API 또는 AWS 명령 줄 인터페이스(CLI)를 통해 실행할 수 있습니다.

AWS CodeBuild 사용해 보기
우선 전체 빌드 작업을 다 해 보기 보다는 우선 AWS CodeBuild  스크린샷을 통애 주요 기능에 대해 먼저 알려드리겠습니다.

아래는 빌드 목록 입니다.

하나의 빌드에 대한 상세 정보를 볼 수 있습니다.

빌드 기록도 볼 수 있습니다.

AWS CodeBuildAWS CodePipeline 빌드 서비스 제공자로 사용 가능합니다.

정식 출시
AWS CodeBuild는 정식 출시 되어 오늘부터 사용할 수 있습니다. 현재 리눅스 빌드 지원이 되며 향후 윈도 지원도 추가할 예정입니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS CodeBuild – Fully Managed Build Service의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS X-Ray – 분산 애플리케이션 추적 및 디버깅 서비스

지난 11월 미국 대통령상 수상자인 Grace Hopper디버깅(Debugging)이라는 용어를 처음으로 사용한 분입니다. 이것은 프로그램에서 오류를 식별하고 제거하는 과정을 말합니다.

저도 컴퓨터에서 실제 버그를 추출하지는 못했지만, 예전에는 어셈블리 언어 프로그램을 디버깅 하는 데 많은 시간을 할애했습니다. 당시 디버깅은 코드를 한 단계 수행하고, 각 단계 전후의 각 프로세서 레지스터 내용을 검사하여 실제로 발생한 상황과 일치하는지 계속 확인했습니다. 상당히 지루한 과정이지만, 버그를 숨기지는 못하며 코드 작동 방식에 대한 심층적인 이해를 할 수 있었다는 보람이었습니다. 나중에 single-stepping은 출력(hello, stderr)을 디버깅하고 거기에서 로그 파일과 로그 분석 도구를 다시 디버깅하였습니다.

지난 십 년 동안 복잡한 분산 시스템이 등장하면서, 디버깅을 하는 방법도 변화되어 새로운 의미를 가지게 되었습니다. 개별 기능과 모듈이 예상대로 작동하는지 확인하는 단위 테스트와 함께 확장 시 실행 패턴도 검토해야 하는 문제가 있습니다. 클라우드 컴퓨팅, 마이크로 서비스 및 비동기식 알림을 기반한 새로운 아키텍처가 결합되어, 수백 혹은 수천 개의 서비스가 함께 움직이는 분산 시스템이 생겨났습니다. 이러한 복잡한 시스템에서 성능 문제를 확인해야 하는 문제는 점점 커지고 있는데, 이는 개별 서비스 수준에서 관찰한 결과를 의미있는 최상위 결과로 집계하는 데 어려움이 있기 때문입니다. 개발자가 EC2 인스턴스, ECS 컨테이너, 마이크로 서비스, AWS 데이터베이스 및 메시징 서비스를 통과 할 때 “스레드를 따라 갈(follow-the-thread)” 수 있는 쉬운 방법은 없었습니다.

이 문제를 해결해 봅시다!

AWS X-Ray 서비스 소개
오늘 AWS X-Ray 에 대해 소개합니다. 이를 통해 앞서 언급했던 모든 부분에서 처음부터 끝까지 요청을 추적 할 수 있습니다. 분산 시스템을 이해하고 확장하려는 경우, 발생하는 문제를 해결하고 이를 수행하기 위해 필요한 정보와  인사이트를 제공합니다.

X-Ray는 EC2 인스턴스 (ECS 컨테이너 포함), AWS Elastic Beanstalk, Amazon API Gateway에서 실행되는 코드를 추적하고 데이터를 캡처합니다. 쓰레드 추적(follow-the-thread)을 위해 HTTP 헤더 (고유 ID 포함)를 추가하고, 다음 번 티어에 요청 처리 시 헤더를 전달하는 방식으로 구현합니다. 각 엔드포인트에서 수집 된 데이터는 세그먼트(Segment)라고하며, JSON 데이터로 저장합니다.

각 세그먼트는 작업 단위를 나타내며, 요청 및 응답 타이밍과 더 작은 작업 단위를 나타내는 선택적 하위 세그먼트 (적절한 도구를 제공 할 경우, 프로그램 코드까지)를 포함합니다. 통계적으로 의미있는 세그먼트 샘플은 AWS X-Ray (데몬 프로세스가 EC2 인스턴스 및 컨테이너 내부에서 처리)에서  트레이스(Trace, 공통 ID를 공유하는 세그먼트 그룹)를 만듭니다. 트레이스와 세그먼트는 서비스간 관계를 시각적으로 표시하는 그래프 를 만들기 위해  사용됩니다.

위의 모든 것이 잘 구성되어 있는 지 보려면, X-Ray 콘솔을 살펴 보면 됩니다.  콘솔이 제공하는 몇 가지 샘플 앱을 사용할 수 있습니다.

각 샘플 앱은 AWS CloudFormation 템플릿에 의해 실행할 수 있습니다. 위의 앱은 최신 AWS SDK를 사용합니다. 이 SDK는 X-Ray를 인식하고 엑스레이 세그먼트를 수집 및 저장하는 프로세스에 참여합니다. Java, Node.js 및 .NET SDK에서 X-Ray 지원이 됩니다. 나중에 가능한 한 빨리 업데이트 할 것입니다.

자신의 애플리케이션을 측정하고 실행할 준비가 되면, X-Ray Console에서 수행해야 할 작업을 표시합니다.

우선 두 개의 앱을 출시하고, 잠시 실행 한 다음 X-Ray 콘솔로 넘어 가서 무슨 일이 일어나고 있는지 확인했습니다. 아래 Service Map은  최상위 레벨 구성도를 제공합니다.

날짜 / 시간 범위 선택기를 사용하여 관심 있는 시간 프레임을 볼 수 있습니다.

그래프의 모든 노드를 클릭하여 그 뒤에 있는 흔적을 살펴볼 수 있습니다.

페이지 상단에 보면, 회원 가입이 적고 (4.12 %) 다른 두 작업보다 대기 시간이 더 길다는 것을 알 수 있습니다. 먼저 URL별로 정렬하여 회원 가입을 그룹화 한 다음, 특정 트레이스에 기여하는 세그먼트를 모니터링 합니다. 다음은 DynamoDB 및 SNS에 대한 호출을 포함하는 예제입니다.

위에서 보면  특정 진입 점에서 호출 될 때 DynamoDB에 대한 호출이 오래 걸리는 것을 나타냅니다. DynamoDB에 대한 호출은 한 자리 밀리 초 단위로 실행되므로 자세히 살펴 봐야합니다. 메타 열에 초점을 맞추고 문서 아이콘을 클릭 한 다음 리소스 탭을 검토하여 진행 상황을 확인합니다.

클라이언트 SDK는 재시도 중에 일부를 수행하는 것처럼 보입니다. 대부분의 경우 테이블에 추가 읽기 또는 쓰기 처리량이 제공되어야 하기 때문입니다.

X-Ray UI는 필터식 개념을 기반으로 합니다. 몇 가지 주요 기능을 위한 전용 UI 요소가 있지만 나머지 부분은(개발자 지향 도구에 적합) 페이지 상단의 텍스트 상자에 간단히 입력하는 자유 형식 필터로 제공됩니다. 다음은 몇 가지 간단한 예제입니다.

  • responsetime > 5 – Response time more than 5 seconds.
  • duration >= 5 AND duration <= 8 – Duration between 5 and 8 seconds.
  • service("dynamodb") – Requests that include a call to DynamoDB.

또한, 날짜, 추적 ID, HTTP 메소드  및 상태 코드, URL, 사용자 에이전트, 클라이언트 IP 주소 등이 포함됩니다. 지금까지 본 것보다 더 많은 기능은 X-Ray API 및 AWS  CLI를 참조하십시오. 이를 통해 많은 종류의 고급 도구, 시각화 및 파트너 기회가 열립니다.

정식 출시
AWS X-Ray는 오늘 부터 12개의 모든 공개 AWS 리전에서 미리보기 형식으로 제공합니다.

Jeff

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS X-Ray – See Inside of Your Distributed Application의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Snowmobile – 엑사 바이트(Exabyte) 데이터를 몇 주 만에 클라우드로

클라우드 이전 중 기존 데이터 센터 혹은 회사에 대용량 데이터가 있다면, 이전이 매우 어려울 수 있습니다. 고속 인터넷을 통해서도 영상 파일, 금융 기록, 위성 이미지 등 페타바이트에서 엑사 바이트(Exabyte)에 이르는 데이터를 옮기는 건 매우 어렵고, 간단히 계산을 해봐도 수년에서 수십 년이 걸릴 수 있습니다.

작년에 AWS Snowball (출시 뉴스 참고)를 통해 손쉽게 대용량 장치를 통해 마이그레이션을 하기 위한 첫 단계를 밟았습니다. 80TB의 스토리지를 담은 전용 스토리지 장치를 배송 받아 데이터를 클라우드로 업로드 하는 방식을 통해 많은 고객들이 도움을 받고 있습니다.

그러나 여전히 엑사 바이트급 데이터를 운용하는 경우라면, 80TB 장치 관점에서 보면 엄청나게 많은 수의 장비와 이동에 대한 곤란한 점이 많습니다.

AWS Snowmobile 저장 콘테이너
이러한 고객들의 요구 사항에 맞추어, 오늘 Snowmobile을 출시합니다. 최고 100PB의 데이터를 실을 수 있는 전용 트럭을 통해 몇 주 안에 엑사 바이트 데이터를 AWS로 이전할 수 있습니다. 금융 서비스, 미디어 및 엔터테인먼트, 과학 및 기타 산업에서 고객의 요구를 충족 시키도록 설계된 Snowmobile은 네트워크에 연결되어 로컬 NFS 마운트 볼륨으로  보이게 됩니다. 기존 백업 및 아카이브 도구를 사용하여 Amazon Simple Storage Service (S3) 또는 Amazon Glacier에 데이터를 채울 수 있습니다.

Snowmbile은 길이 45 피트, 높이 9.6 피트, 너비 8 피트의 견고한 변조 방지를 지원하는 선적용 콘테이너입니다. 방수 기능이 있으며 기후에 영향을 받지 않으며 기존 데이터 센터에 인접해,  지붕이 있는지 상관없이 주차 할 수 있습니다. 각 Snowmbile은 약 350KW의 AC 전원을 소비합니다. 현장에 충분한 용량이 없는 경우 발전기를 마련 할 수 있습니다.

보안 측면에서 Snowmobile은 보관성(chain-of-custody) 추적 및 비디오 감시와 같은 여러 단계의 논리적 및 물리적 보안을 통합적으로 제공합니다. 여러분의 데이터를 쓰기 전에 AWS Key Management Service (KMS) 키로 암호화합니다. 각 콘테이너에는 GPS 추적 기능이 포함되어 있으며, 셀룰러 또는 위성 연결을  통해 AWS에 다시 연결합니다. Snowmobile이 운송 중일 때 보안 차량 호위를 준비 할 것입니다. Snowmobile이 구내에있는 동안 전용 경비원을 배치 할 수도 있습니다.

각 Snowmobile에는  초당 40Gb의 다중 연결을 통해 초당 1Tb의 데이터 전송을 지원하는 고속 스위치에 연결된 네트워크 케이블을 포함합니다. 해당 네트워크에서 이 속도로 데이터를 전송할 수 있다고 가정하면, 약 10 일 후에 Snowmobile을 채울 수 있습니다.

Snowmobile 실제 보기
엑사 데이터 규모의 데이터 센터도 본 적이 없고, 저희 집에 45 피트 길이의 콘테이너를 보관할 수 있는 공간도 없기 때문에, Snowmobile을 준비하고 사용하는 과정을 설명하기 해 LEGO 테이블에 앉아 (Doc Brown 전통에 따라) 작은 모형을 만들었습니다 . 레고 기반의 스토리 텔링을 즐기시기 바랍니다!

먼저 데이터 센터에서 시작해보겠습니다. 건물 안에 랙은 다수의 디스크 및 테이프 드라이브로 가득 차 있습니다. 각 드라이브에는 중요한 데이터를 저장합니다. 여러분 동료들은 바닥을 열어 많은 시간을 들여 케이블을 짜고 이를 연결하려고 노력 하고 있습니다.

관리자는 너무 일이 힘들어 다음에 무엇을 해야 할지 걱정부터 앞섭니다.

다행히 동료 중 한 명이 AWS 블로그를 읽고 공부를 해서 무엇을 해야 할지 알게 되었습니다.

홈페이지의 연락하기를 통해 AWS와 연결이 되어 미팅 일정을 잡습니다.

모두 모여서 AWS에 대해 배우고, 대용량 데이터 마이그레이션을 위한 Snowmobile에 대한 이점을 알고 계획을 세우기 시작합니다.

Snowmobile의 확장 모델에 대해 많은 관심이 가지고 (심지어 강아지까지 보러 왔네요!). 신기해서 사진도 한 장 남깁니다.

이제 Snowmobile이 데이터 센터로 와서 주차를 합니다.

AWS 프로페셔널 서비스에서 어떻게 연결을 하고 데이터 전송을 하는지 알려줍니다.

작업이 완료되면 Snowmobile은 AWS로 돌아가 바로 클라우드로 데이터 이동을 시작합니다.

DigitalGlobe의 Snowmobile 활용 사례
저희 고객사인 DigitalGlobe는 100PB의 위성 이미지를 AWS로 옮기기 위해 Snowmobile을 사용했습니다. Jay Littlepage (VP of Infrastructure & Operations at DigitalGlobe) 다음과 같이 언급했습니다.

“많은 대기업과 마찬가지로 저희도 IT 운영에 있어 기존 데이터 센터에서 AWS로 마이그레이션하는 과정에 있습니다. 대용량 지리 공간 데이터 플랫폼 인 GBDX는 처음부터 AWS에 기반을 두고 있습니다. 그러나, 지구 표면의 60억 제곱 킬로미터를 시각화하는 고해상도 위성 이미지는 16 년 동안 저희 시설내 백업 아카이브에 저장되었습니다. 아카이브 내 데이터를 AWS로 서서히 옮겨 왔지만, 그 과정은 느리고 비효율적이었습니다. 위성 및  항성 데이터는  더 많은 지구 이미지를 생성합니다 (10 PB).

우리는 100 PB 아카이브를 이동할 수있는 방법이 필요했지만, AWS Snowmobile은 지금까지 찾지 못했던 해법이었습니다. DigitalGlobe는 한 번의 Snowmobile 전송을 통해 Amazon Raw Glacier Vault로 직접 전체 원본 이미지 아카이브를 마이그레이션하고 있습니다. AWS Snowmobile는 운영자가 기본 구성, 모니터링 및 물류 관리만을 담당하면 되는 맞춤형 서비스를 제공합니다. Snowmobile의 데이터 전송 기능을 사용하면, 시간이 지나면 계속 생성되는 이미지 아카이브를 보다 신속하게 클라우드로 가져와 고객 및 파트너가 방대한 데이터 세트에 접근할 수 있습니다. GBDX 내에서 AWS의 탄력적인 컴퓨팅 플랫폼을 사용함으로서, 빠른 속도와 경제적인 방식에 따라 인프라에 대한 통찰력을 얻은 다음 분산 이미지 분석을 수행할 수 있습니다.  Snowmobile을 통해서 짧은 시간에 대량의 데이터를 전송하고, 고객에게 새로운 비즈니스 기회를 창출 할 수 있었습니다. 스노우 모빌은 진정한 게임 체인저입니다!”

알아두기
마지막으로 Snowmobile에대해 알아 두면 좋을 몇 가지만 소개합니다.

  • 데이터 내보내기 – 초기에는 데이터 가져 오기 (온-프레미스에서 AWS)에만 집중합니다. 저희도 일부 고객이 재해 복구 (DR) 사례를 중심으로 데이터 내보내기에 관심을 갖고 있음을 알고 있습니다.
  • 가용성 – Snowmobile은 모든 AWS 지역에서 사용할 수 있습니다. 이전에 언급해서 아시겠지만, 본 서비스는 셀프 서비스가 아닙니다. AWS 영업 및 기술 담당자들이 데이터 가져 오기 요구 사항에 대해 여러분과 상의한 후 제공 됩니다.
  • 가격 책정 – 아직은 공유할 수 있는 가격 정보가 없습니다. 그러나 Snowmobile은 네트워크 기반 데이터 전송 모델을 사용하는 것보다는 훨씬 빠르고 비용이 적게 듭니다.

참고로 레고 기반 스토리 텔링에 대한 고화질 이미지를 보시려면, Snowmobile Photo Album을 참고하세요. 특별히 마지막 작업과 사진 촬영에 도움을 준 Matt Gutierrez (Symbionix)에게 감사하게 생각합니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Snowmobile – Move Exabytes of Data to the Cloud in Weeks의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Snowball Edge – 클러스터링 및 용량 추가, 로컬 엔드포인트와 Lambda 함수 지원

작년에 AWS Snowball을 출시(블로그 참고) 한 뒤, 많은 업데이트가 있었습니다. 물리적 50TB 데이터 전송 저장 장치로 보안 및 운송의 편리성을 통한 클라우드 데이터 이동에 대한 아주 간단한 해법으로서  그 이후에도, 용량 확대 및 리전 추가 지원 (80 TB), 작업 관리 API 및 S3 어댑터, HIPAA 호환, HDFS 가져오기 지원 등의 업데이트가 이루어졌습니다.

위의 모든 개선 사항 역시 중요했지만, 제품 기본 특성은 변경하지 않았습니다. 지난 1년간 많은 AWS 고객이 Snowball을 활용하여 다양한 유형의 대용량 데이터 이전, 유전학 데이터 수집 작업 등에서 물리적 환경에 필요한 다양한 작업을 진행하였습니다. 그 와중에 좀 더 기능적으로 필요한 몇 가지 여지가 있음을 알게 되었습니다.

어떤 고객은 네트워크 연결이 제한적이거나 아예 존재하지 않는 극단적인 상황에서도 많은 양의 데이터 (수백 테라 바이트)를 생성하기도 합니다. 예를 들어, 농장, 공장, 병원, 항공기 및 석유 시추 위치에서 생성하는 데이터를 수집할 필요가 있습니다.  각 작업 현장 측정 위치에서 비디오 감시, IoT 장치로 수집 된 정보에 이르기까지 고객은 개별 데이터 저장 및  수집에 넘어서서 데이터가 도착할 때 일부 로컬 처리를 수행 가능한 모델에 관심이 있습니다. 수집한 데이터를 필터링, 정리, 분석, 구성, 추적, 요약 및 모니터링하여, 특정 패턴이나 이슈에 대해 들어오는 데이터를 검색하여, 흥미로운 것이 발견되면 신속하게 경고를 하는 경우가 있습니다.

신규 Snowball Edge 디바이스
오늘 Snowball Edge라는 새로운 저장 장치를 추가로 제공합니다. 이 장치는 기존 Snowball 기능에 더해 연결성, 스토리지, 클러스터링을 통한 수평적 확장, 기존 S3 및 NFS 클라이언트, Lambda 기반 처리를 통한 신규 스토리지 엔드포인트 지원이 가능합니다.

물리적으로 Snowball Edge는 집에서 부터 아주 열악한 환경인 농장, 군대 및 항공 분야에서도 사용 가능합니다. 새로운 랙 마운트 장착용으로 클러스터 기능이 있는 것이 장점입니다.

몇 가지 새로운 기능을 살펴 보겠습니다.

연결성 확대
다양한 고속 네트워크 연결에 대한 선택 사항이 높아졌습니다. 10GBase-T, 10 또는 25 Gb SFP28, 또는 40 Gb QSFP+를 사용 가능합니다.   IoT 기기가 데이터 업로드를 할 수 있도록  3G 모바일 혹은 Wi-Fi를 지원합니다 또한, 기타 IoT 기기를 위한  Zigbee, USB 3.0 포트, PCIe 확장 포트 등 다양한 접속 방법도 지원 합니다.

Snowball Edge에 데이터를 복사 할 수 있는  대역폭은 초당 최대 14Gb까지 확보 할 수 있습니다. 따라서, 19 시간 내에 100TB를 복사 할 수 있습니다. 시작부터 끝까지 (S3에서 사용 가능한 데이터로 전송 시작) 전체 과정은 배송 및 처리 과정을 포함하여 일주일이 소요됩니다.

스토리지  용량 확대
Snowball Edge는 100 TB 스토리지를 포함합니다.

클러스터링을 통한 수평적 확장 기능Snowball Edge 어플라이언스 두 개 이상을 클러스터로 쉽게 구성하여 용량을 늘리고 내구성을 높이는 동시에 모든 스토리지에 단일 엔드 포인트를 통해 접근할 수 있습니다. 예를 들어, 6개의 기기를 클러스터링을 하면 400TB의 스토리지와 99.999%의 내구성을 갖춘 고가용성 클러스터를 생성합니다. 이를 통해 2개의 기기를 제외하고 데이터 보호를 할 수 있습니다.

클러스터링을 통해 페타 바이트 단위로 용량을 확장 할 수 있으며, 손쉽게 클러스터에서 기기 추가 및 제거가 가능합니다. 클러스터는 자체 관리가 가능하므로 소프트웨어 업데이트 등에 대해 걱정할 필요가 없습니다.

Local compute and storage only를 체크하여 클러스터를 주문하고, Make this a cluster를 통해 작업을 설정하시면 됩니다.

신규 스토리지 엔드 포인트 (S3 및 NFS)
기존 데이터 백업 및 아키이빙, 데이터 전송을 위해 S3나 NFS를 사용하여 Snowball Edge를 활용할 수 있습니다. 2개 이상의 기기로 클러스터를 만들어도, 같은 엔드 포인트를  사용 가능합니다. 클러스터를 로컬 네트워크 저장 장치로 사용할 수 있습니다.

Snowball Edge 는 S3 API, 즉 LIST, GET, PUT, DELETE, HEAD, Multipart Upload 등을 지원 하며, NFS v3 및 NFS 4.1. 역시 지원합니다.

Snowball Edge를 파일 스토리지 게이트웨이로 만들어 NFS로 접근 가능합니다. 이러한 기능을 활용하여 데이터 이전, AWS Storage Gateway 연동, 온-프레미스 앱에서 온-프레미스 데이터를 처리 가능합니다.

Lambda 기반 로컬 작업 지원
AWS Lambda 함수를 사용하여 Snowball Edge를 S3 버킷으로 연계해서 업로드가 가능합니다.

본 기능을 통해 (앞서 언급한 대로) 수집한 데이터를 필터링, 정리, 분석, 구성, 추적, 요약 및 모니터링하여, Snowball Edge를 좀 더 지능적이고 스마트하게 데이터 수집 및 처리를 할 수 있도록 해줍니다

우선 S3 PUT 에 대해 버킷당 하나의 함수를 사용 가능합니다. 함수는 Python 언어로 작성해야 하고 128 MB 메모리로 람다 함수 실행 환경을 설정하면 됩니다.

아래와 같이 Snowball Edge 환경 설정에 람다 함수를 지정하면 됩니다.

주문하기 전에 클라우드에서 기능을 테스트하는 것을 권장합니다.

정식 출시 및 가격 정보
Snowball Edge는 플러그앤 플레이 기반으로 배포합니다. 현장에서 이를 다루는 분은 설정을 할 필요는 없으며, LCD 보드를 통해 상태 정보나 설정 동영상을 볼 수 있습니다. 보드 상에 설정 코드는 자동으로 업데이트되고 소프트웨어 업데이트 관리도 필요 없습니다. AWS 관리 콘솔 (API 또는 CLI 접근 가능)을 통해 상태를 확인하고 배치 된 장비에 대한 최신 구성 변경 사항을 작성할 수 있습니다.

각 Snowball Edge은 배송료 포함 $300 입니다. 10일까지 장비를 사용할 수 있으며, 그 이후로는 일 $30이 추가됩니다. 로컬에서 Lambda 함수 실행은 무료입니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Snowball Edge – More Storage, Local Endpoints, Lambda Functions의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Greengrass – 유비쿼터스 및 실세계 컴퓨팅 서비스

데이터 센터나 사무실 안에서 컴퓨팅 작업이나 및 데이터 처리는 용이합니다. 기본적으로 양호한 네트워크 연결성과 지속적인 전력 공급을 기대할 수 있으며, 가능한 만큼 온 – 프레미스 또는 클라우드 기반 스토리지에 접근하여 컴퓨팅 성능을 활용할 수 있습니다. 하지만, 밖으로 나오면 상황이 매우 다릅니다. 네트워크 연결은 간헐적이거나 신뢰할 수 없으며, 속도와 확장면에서 제한적일 수 있습니다. 전원 공급은 저장 용량 및 컴퓨팅 성능을 제한 할 수 있습니다.

따라서, 현실에서 흥미롭고 잠재적으로 가치 있는 많은 데이터가 수집 및 처리하여, 지능형 서비스를 제공하는 것은 매우 중요합니다. 이러한 데이터는 자원 채굴 현장이나 병원이나 공장 또는 심지어 (Curiosity)가 있는 화성처럼) 다른 행성, 지구 표면 아래 몇 마일 떨어진 해저 등에서도 얻어야 할 수 있습니다.

지금까지 많은 고객은 AWS 클라우드의 서비스 규모와 성능을 활용하여, 이러한 열악한 조건에서 로컬 처리를 시도할 수 있도록 다양한 피드백을 주셨습니다.  먼저, 데이터를 측정, 감지 및 제어하는 시스템을 로컬에 구축합니다. 그런 다음, 클라우드와 유사한 로컬 환경에 데이터를 저장하고 로컬 내부에서 독립적으로 수행하도록 일단 구성을 합니다. 이런 작업을 위해서는 로컬 프로세싱 및 스토리지 자원을 구성하고 활용하는 동시에 특수 센서 및 주변 장치에 연결할 수 있어야 합니다.

AWS Greengrass 소개
AWS Greengrass라는 서비스는 AWS 프로그래밍 모델을 작고 단순한 필드 기반 장치로 확장하여 위에서 설명한 문제점을 해결할 수 있도록 설계되었습니다.

Greengrass는 AWS IoTAWS Lambda를 기반으로 하며 다른 AWS 서비스에도 접근할 수 있습니다. 오프라인 작업을 위해 제작되었으며, 로컬에서 프로그래밍 구현을 단순하게 만들어 주게 됩니다. 현장에서 실행되는 프로그램 코드를 통해 데이터를 새로 수집, 필터링 및 집계한 후 장기적으로 저장하고, 추가 분석을 할 수 있도록 클라우드로 전송할 수 있습니다. 또한, 현장에서 실행되는 프로그램 코드는 클라우드에 대한 연결을 일시적으로 사용할 수 없는 경우에도 매우 신속하게 조치를 취할 수 있습니다.

고객이 소형 장치용 임베디드 시스템을 이미 개발 중인 경우, 최신 클라우드 기반의 개발 도구 및 워크 플로를 활용할 수 있습니다. 클라우드에서 코드를 작성하고 테스트 한 다음, 로컬에서 배포 할 수 있습니다. 디바이스 이벤트에 응답하는 Python 코드를 작성할 수 있으며 MQTT 기반 pub/sub 메시징을 사용하여 통신 할 수 있습니다.

Greengrass에는 GreenGrass Core (GGC)와 IoT Device SDK의 두 가지 구성 요소가 있습니다. 이 두 구성 요소는 현장에서 직접 하드웨어에서 실행됩니다.

Greengrass Core는 128MB 이상의 메모리와 1GHz 이상의 x86 또는 ARM CPU를 갖춘 장치에서 실행되도록 설계되었으며, 필요한 경우 추가 리소스를 이용할 수 있습니다. AWS Lambda 기능을 로컬에서 실행하고, AWS 클라우드와 상호 작용하면서도 보안 및 인증을 관리하면서 주변의 다른 디바이스와 통신할 수 있습니다.

IoT Device SDK는 (일반적으로 LAN 또는 기타 로컬 연결된) 코어를 호스팅하는 디바이스장치에서 실행하는 응용 프로그램을 개발하는 데 사용합니다 . 이런 애플리케이션은 센서에서 데이터를 캡쳐하고, MQTT 토픽를 구독하며 AWS IoT 디바이스 섀도우를 사용하여 상태 정보를 저장 및 검색합니다.

AWS GreenGrass 사용
AWS Management Console, AWS APIs, AWS Command Line Interface (CLI)를 통해 Greengrass의 여러 측면을 설정하고 관리 할 수 ​​있습니다.

새 허브 장치를 등록한 후, 원하는 람다 함수를 구성하며 디바이스에 전달할 배포 패키지를 만들 수 있습니다. 여기에서 경량 디바이스와 허브와 연결 시킬 수 있습니다.

미리 보기 출시
오늘 AWS Greengrass  미리보기를 시작합니다. 참여하고 싶으시다면, 가입하신 후 기다리시면 초대해 드립니다. 각 AWS 고객은 1 년 동안 3 개의 기기를 무료로 사용할 수 있습니다. 그 이후에는 각 활성 Greengrass Core의 월간 비용은 최대 10,000 개의 장치에 대해 $ 0.16 (연간 $ 1.49)입니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Greengrass – Ubiquitous, Real-World Computing의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

Amazon Aurora 업데이트 – PostgreSQL 호환 서비스 출시

2년전 Amazon Aurora 발표를 통해 RDS 팀에서 생각한 클라우드에서 관계형 데이터베이스의 모델을 설명한 신선한 아이디어를 제공한 바 있습니다.

이후 많은 고객으로 부터 정말 가슴 따뜻한 피드백을 받았습니다. MySQL 호환성을 유지하면서도, 고가용성 및 기본 암호화 기능에 대해 만족하고 있으며, Aurora를 통해 빠른 장애 복구와 10GB부터 64 TB까지 자체 스토리지 확장 등의 기능 등에 전적인 신뢰를 보여주셨습니다. Aurora는 6개의 복제본을 세 개의 가용 영역(AZ)에 분산 저장하여 가용성이나 성능 영향 없이 S3를 스토리지 공간으로 사용하고 있습니다. 확장이 필요할 때, 15개의 낮은 지연 속도의 읽기 복제본을 만들수도 있습니다. 더 자세한 사항은 Amazon Aurora 성능 평가 정보를 참고해 주시기 바랍니다.

고객들이 서비스에 대해 다양한 요구를 하고 있기 때문에 이에 대해 바르게 이해하고, 아래와 같이 고객의 피드백에 부합하는 기능을 계속해서 출시해 왔습니다.

PostgreSQL 호환 서비스 출시
기능적인 측면 뿐만 아니라 추가적인 데이터베이스 엔진 호환성에 대한 요청도 많이 받았습니다. 그 가장 우선 목록이 바로 PostgreSQL호환 서비스입니다. 20년 이상 개발되어온 오픈 소스 데이터베이스 엔진으로서 많은 엔터프라이즈 기업 및 스타트업에서 사용해 오고 있습니다. 특히, 고객들이 (SQL 서버나 오라클이 제공하는) 엔터프라이즈 기능과 성능 이점, PostgreSQL과 연계한 지리 정보 데이터 처리 기능에 만족하고 있는데, 이제 이들 기능을 Aurora가 제공하는 다양한 이점과 함께 활용해 볼 수 있게 되었습니다.

오늘 Amazon Aurora용 PostgreSQL 호환 서비스를 미리보기로 출시합니다. 위에 언급한 장점과 함께, 높은 내구성과 고가용성 그리고 빠르게 읽기 복제본을 생성 및 배포할 수 있게 됩니다. 여기에 몇 가지 여러분이 좋아할 만한 사항을 소개합니다.

성능 – Aurora는 기존 환경에서 보다 2배까지 PostgreSQL 성능을 높였습니다.

호환성 – Aurora는  PostgreSQL (version 9.6.1) 오픈 소스 버전과 완벽하게 호환됩니다. 스토어드 프로시저에서도  Perl, pgSQL, Tcl, JavaScript (V8 자바스크립트 엔진 기반)을 지원할 예정입니다. 또한,   Amazon RDS for PostgreSQL에서 제공하는 모든 확장 기능 및 플러그인 역시 지원할 예정입니다.

클라우드 네이티브 – Aurora를 통해 기존 AWS 서비스를 충분히 활용할 수 있으며, 아래의 서비스와 직접 연동이 가능합니다.

RDS 콘솔에서 이제 Aurora 중에서 PostgresSQL Compatible 을 선택할 수 있습니다.

그 다음 DB 인스턴스 타입과 멀티 AZ 배포 조건을 선택하고, 데이터베이스 인스턴스의 이름과 아이디와 암호를 설정합니다.

Amazon Aurora용 PostgreSQL 호환 서비스는 오늘 부터 US East (Northern Virginia) 리전에서 미리 보기로 사용 가능하며, 미리 보기 신청을 통해 바로 써 보실 수 있습니다!

몇 가지 성능 비교 사항
Dave Wein는 Amazon Aurora용 PostgreSQL 호환 서비스와  PostgreSQL 9.6.1를 비교하는 몇 가지 테스트를 진행했습니다. 비교를 위해 m4.16xlarge 인스턴스 기반 데이터베이스 서버와   c4.8xlarge 인스턴스 기반 클라이언트를 사용했습니다.

PostgreSQL는 ext4 파일 시스템 기반 15K IOPS EBS 볼륨 세 개로 이루어진 45K의 Provisioned IOPS  스토리지로 구성하고, WAL 압축 기능 및 오토 버큠(Autovacuum)을 사용하여 양쪽의 같은 워크로드로 성능 테스트를 하였습니다.

우선 쓰기 기반 Sysbench 워크 로드 (20GB 데이터베이스- 250 테이블 및 15만개 열)에서 시작해서, 매회 데이터베이스 재생성을 진행하여 시간이 지남에 따라 아래와 같은 결과를 얻었습니다.

각 실행 시 전체 소요 시간은 아래와 같습니다.

progress: 1791.0 s, 34248.7 tps, lat 29.143 ms stddev 12.233
progress: 1792.0 s, 36696.2 tps, lat 27.363 ms stddev 10.882
progress: 1793.0 s, 26287.4 tps, lat 37.549 ms stddev 20.430
progress: 1794.0 s, 31377.7 tps, lat 31.993 ms stddev 17.408
progress: 1795.0 s, 36219.6 tps, lat 27.522 ms stddev 10.942
progress: 1796.0 s, 35786.4 tps, lat 27.731 ms stddev 11.262
progress: 1797.0 s, 34926.6 tps, lat 29.108 ms stddev 12.176
progress: 1798.0 s, 35663.6 tps, lat 27.766 ms stddev 11.544
progress: 1799.0 s, 36472.6 tps, lat 27.608 ms stddev 10.923
progress: 1800.0 s, 34215.3 tps, lat 28.999 ms stddev 12.095
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 2000
query mode: prepared
number of clients: 1000
number of threads: 1000
duration: 1800 s
number of transactions actually processed: 61665153
latency average = 29.175 ms
latency stddev = 14.011 ms
tps = 34250.027914 (including connections establishing)
tps = 34267.524614 (excluding connections establishing)

또한 비슷한 실행의 마지막 40 분을 다루는 초당 처리량 그래프를 아래와 같이 공유했습니다.

위에서 보시다시피, Amazon Aurora는 PostgreSQL보다 높은 처리량을 제공하여 지터의 1/3 (표준 편차는 각각 1395 TPS 및 5081 TPS)입니다.

David와 Grant는 2017 년 초에 보다 자세한 결과물을 공유하기 위해 데이터를 수집하고 있습니다.

곧 출시 – 성능 확인 기능
앞으로 아주 다양한 측면에서 데이터베이스 성능을 이해할 수 있도록 디자인한 새로운 도구를 출시할 예정입니다. 각 질의에 대한 세부적인 사항과 데이터베이스가 어떻게 질의를 처리하는지 상세히 볼 수 있습니다. 아래는 미리보기 스크린샷입니다.

본 미리 보기 기능에 새로운 성능 보고 기능을 포함할 예정이고, 계속해서 관련 소식을 본 블로그를 통해 전달해 드리겠습니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 Amazon Aurora Update – PostgreSQL Compatibility의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

Amazon Rekognition – 딥러닝을 기반한 이미지 탐지 및 인식 서비스

아래 사진이 무엇으로 보이시나요?

당연히 여러분은 동물이라고 인지하실 겁니다. 또한, 애완견으로서 골드리트리버 종이죠. 위의 그림과 이러한 메타 정보가 결합되는 것은 여러분의 뇌에서 바로 인지하기 때문입니다. 이는 여러분이 이미 수백 수천번 이러한 이미지와 데이터 간의 훈련을 통해 학습을 한 것입니다. 이런 방식으로 식물과 동물의 차이, 개와 고양이의 차이 그리고 골드 리트리버와 다른 견종과의 차이를 인지하는 것입니다.

이미지 인식을 위한 딥러닝(Deep Learning)
컴퓨터를 통해 인간과 동일한 수준의 이해력을 요구하는 것은 매우 어려운 작업임이 입증되었습니다. 수십 년 동안 컴퓨터 과학자들이 이 문제에 대해 여러 가지 다른 접근 방식을 취해 왔습니다. 오늘날 이 난제를 해결할 수 있는 가장 좋은 방법은 딥러닝 학습(deep learning)이라는 점에 공감대가 형성되었습니다. 딥러닝은 추상화와 신경망 결합을 사용하여 (Arthur C. Clarke가 말한 것처럼) 마술과 구별할 수 없는 결과를 산출합니다. 그러나 상당한 비용이 듭니다. 첫째, 데이터 훈련 단계에 많은 작업을 투입해야 합니다. 학습 네트워크에 다양한 텍스트 예제 (“this is a dog”, “this is a pet” 등)를 표시하여 이미지의 특징을 라벨과 연관 지어야 합니다. 이 단계에서 신경망의 크기와 다층 적 특성으로 인해 계산 비용이 많이 들게 되는 거죠. 트레이닝 단계가 완료된 후, 트레이닝 네트워크에서 새 이미지가 들어왔을 때 평가하기가 용이합니다. 쉽습니다. 그 결과는 일반적으로 신뢰 수준 (0-100%)으로 표현됩니다. 이를 통해 응용 프로그램에 적합한 정밀성 정도를 결정할 수 있습니다.

Amazon Rekognition 서비스 소개
오늘 Amazon Rekognition 서비스를 공개합니다. 딥러닝 기술을 이용하여 컴퓨터 비전 연구팀이 수 년에 거쳐 수십 억장의 이미지를 매일 훈련 시키는 완전 관리형 서비스입니다. 정확히 훈련된 수 천개의 객체와 장면에 대한 정보를 여러분의 애플리케이션에 사용할 수 있습니다. Rekognition 데모를 통해 사용 방법 및 샘플 코드를 보실 수 있고, 더 자세한 사항은 Rekognition API를 참고하실 수 있습니다.

Rekognition은 확장성을 고려해서 설계되었습니다. 각종 장면, 객체, 얼굴 등을 인식하여 이에 해당하는 레이블(Lavel) 정보를 반환해 주게 됩니다. 이미지에 하나 이상의 얼굴이 포함되어 있다면, 각 얼굴 경계선에 대한 정보를 제공합니다. 아래는 위의 골드 리트리버 이미지에 대한 정보입니다.

보시다시피 Rekognition을 통해 animal, dog, pet, golden retriever 등의 높은 신뢰 수준의 정보를 제공합니다. 이러한 정보들은 독립적이고 서로 명시적 관계성 없이 각자 딥러닝 모델을 통해 생성되는 것입니다. 예를 들어 개와 동물은 완전히 다른 트레이닝 결과입니다. 다만, Rekognition 결과 중 두 레이블이 동시에 강아지 중심의 훈련 자료에 동시에 나타나기도 합니다.

이제 제 와이프와 제가 찍은 사진을 한번 올려 보겠습니다.

Amazon Rekognition를 통해 두 사람의 얼굴과 경계선을 얻을 수 있습니다. 와이프가 행복한 표정을 짓고 있다는 것도 알려주네요. (이 사진은 와이프 생일날 찍은 것입니다.)

또한, Rekognition는 얼굴을 비교하고 해당 이미지 인식을 요청한 많은 얼굴 중 하나가 포함되어 있는지 확인합니다.

모든 기능은 API 함수를 통해 더 자세하게 제공됩니다. (콘솔에서는 간단한 데모를 보시는데 좋습니다.) 예를 들어, DetectLabels로 첫 번째 예제를 프로그래밍으로 처리하고, 두번째로 DetectFaces를 실행합니다. Rekognition에서 IndexFaces을 여러 번 호출해서 인식할 이미지를 준비시킬 수도 있습니다. 실행 할 때마다, 몇 기지 주요 정보(face vectors)를 이미지에서 추출해서 벡터로 저장하고 이미지를 없앱니다. 하나 이상의 인식용 모음을 만들어서 각각 페이스 벡터의 관련 그룹에 저장할 수 있습니다.

RekognitionAmazon Simple Storage Service (S3)에 있는 이미지를 직접 가져올 수도 있습니다. AWS Lambda 함수를 통해 새로 업로드 되는 이미지 인식 작업을 수행할 수 있는데, 이 때 AWS Identity and Access Management (IAM)으로 Rekognition API 접근을 하게 하고 AWS CloudTrail로 API 사용 로그를 남길 수도 있습니다.

Rekognition 애플리케이션
이미지 인식 서비스에 대한 응용 분야는 무궁무진합니다. 만일 많은 사진 정보가 있다면 Amazon Rekognition를 통해 태깅 및 색인 작업을 할 수 있습니다. Rekognition은 클라우드 서비스로서 저장 인프라 설치와 처리 그리고 확장성에 염려할 필요가 없기 때문입니다. 이미지 검색 기능, 태그 기반 브라우징 등 어떤 종류의 대화형 검색 서비스에 적합니다.

또한, 다양한 인증 및 보안 서비스에도 활용할 수 있습니다. 웹캠을 통해 신분증 정보를 확인하거나, 사무실 출입이나 보안 영역 출입 허가를 할 수도 있고, 시각적 감시를 수행하고, 관심 있는 대상 및 사람들을 위해 안면 검사를 할 수도 있습니다. 궁극적으로 영화에 나오는 것 같은 얼굴 인식 정보를 통한 “스마트” 광고판을 만들어 볼 수도 있을 것입니다.

정식 출시
Rekognition은 오늘 부터 US East (Northern Virginia), US West (Oregon), EU (Ireland) 리전에서 서비스를 시작합니다. AWS 프리티어(무료 체험판)을 통해 한달에 5,000개의 이미지는 비용 없이 분석 가능하고 일년에 1,000 개의 페이스 벡터를 저장할 수 있습니다. 그 이상에 대해서는 이미지량과 저장 볼륨에 따라 금액이 책정됩니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 Amazon Rekognition – Image Detection and Recognition Powered by Deep Learning의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.