aws

Amplify CLI에서 로컬 모의 동작 및 테스트 기능 사용해 보기 Amplify Framework는 AWS CloudFormation을 통해 백엔드 리소스를 프로비저닝하여 웹 또는 모바일 앱에 정교한 클라우드 기능을 쉽게 추가할 수 있는 라이브러리, UI(사용자 인터페이스) 및 CLI(명령줄 인터페이스) 세트를 제공합니다. 지난 주 Amplify 팀은 새로운 인공 지능 기능인 예측(Predictions) 카테고리를 공개했습니다. 이 기능을 사용하면 웹이나 모바일 앱에 기계 학습 기능을 빠르게 추가할 수 있습니다. 오늘 소개하는 기능도 마찬가지입니다. 이제 Amplify CLI를 사용하여 제공하는 가장 널리 사용되는 클라우드 서비스 몇 가지를 모의하고 로컬에서 애플리케이션을 100% 테스트할 수 있습니다! 실제 백엔드 구성 요소(클라우드 서비스인 경우 API)를 사용하는 대신, 모의 동작(Mocking) 기능을 통해 API의 단순화된 로컬 에뮬레이션을 대신 사용할 수 있습니다. 이러한 에뮬레이션에서는 개발 중 테스트에 필요한 기본적인 기능을 제공합니다. (하지만 프로덕션 서비스에서 이용할 수 있는 전체 동작을 지원하지는 않습니다.) 이러한 모의 동작 기능을 통해 각ㄱ 단계에서 사용하는 클라우드 리소스를 프로비저닝하거나 업데이트하지 않고도 변경 사항을 빠르게 [ more… ]

Amazon Aurora Multi-Master를 통한 고가용성 MySQL 애플리케이션 만들기 Amazon Aurora는 고성능 상용 데이터베이스의 성능과 가용성에 오픈 소스 데이터베이스의 간편성과 비용 효율성을 결합하였으며 클라우드를 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스입니다. MySQL 호환 버전의 Aurora는 동일한 하드웨어에서 실행되는 표준 MySQL의 처리량을 최대 5 배까지 제공합니다. 또한 하나 이상의 가용 영역(AZ) 및 리전(Region)에서 단일 쓰기 마스터와 최대 15 개의 읽기 전용 복제본을 지원합니다. 이번에 새로 출시된 Aurora 다중 마스터 기능은  여러 가용 영역에 걸쳐 다중 쓰기 인스턴스를 생성 할 수 있습니다. 이를 통해 지속적인 쓰기 가용성을 달성 할 수 있습니다. 인스턴스 또는 가용 영역 장애가 발생하는 경우, Aurora Multi-Master를 사용하면 다운 타임 없이 읽기 및 쓰기 가용성을 유지할 수 있으며, 별도의 DB 장애 조치가 필요하지 않습니다. 우선 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 미국 서부 (오레곤) 및 EU (아일랜드) 리전의 Aurora MySQL 5.6에서 사용할 수 있습니다. RDS 관리 콘솔에서 몇 [ more… ]

AWS Lake Formation – 데이터레이크 구축 및 관리 서비스 정식 출시 데이터를 디지털 형식으로 변환할 수 있게 되면서 다양한 회사에서는 CRM(고객 관계 관리) 및 ERP(엔터프라이즈 리소스 관리) 시스템처럼 운영 체제의 데이터를 수집하는 데이터 웨어하우스를 구축하고 이 정보를 사용해 비즈니스 의사 결정을 지원할 수 있게 되었습니다. 데이터 저장을 위한 스토리지 비용이 절감되었고 다량의 데이터 관리에서 비롯되는 복잡성은 더 큰 폭으로 줄었습니다. 이를 위해 Amazon S3 같은 서비스를 활용해 구조화되지 않은 원시 데이터를 포함하여 로그, 이미지, 비디오 및 스캔된 문서 등 더 많은 정보를 보존할 수 있게 되었습니다. 데이터 레이크의 개념은 모든 데이터를 하나의 중앙 리포지토리에 원하는 규모로 저장하는 것입니다. Netflix, Zillow, NASDAQ, Yelp, iRobot, FINRA 및 Lyft 같은 고객이 이 접근 방식을 사용합니다. 이러한 고객은 단순 집계부터 복잡한 기계 학습 알고리즘에 이르는 분석을 더 큰 데이터 세트에서 실행하여 데이터의 패턴을 알아내고 비즈니스를 이해할 수 있습니다. 지난 해 re:Invent에서 소개된 AWS Lake [ more… ]

Amazon EMR 클러스터 탄력성에 따른 Spark 노드 손실 문제 해결 방법 AWS 고객은 Amazon EMR의 클러스터 탄력성을 활용하여 작업량에 따라 사용 인스턴스 수를 조정해서 비용을 절감할 수 있습니다. 특히, EC2 스팟 인스턴스를 사용하면, 빠르게 끝나는 작업에 대해서 80-90%의 저렴한 비용으로 작업을 할 수 있습니다. 또한, Amazon EMR의 오토 스케일링 기능을 통해 고객은 클러스터 사용이나 기타 작업 관련 지표에 따라 클러스터를 동적으로 확장 및 축소 할 수 있습니다. 다만, 이 기능을 통해 리소스를 효율적으로 사용할 수 있지만 작업 실행 중에 EC2 인스턴스가 중단될 수도 있습니다. 그 결과 계산 및 데이터가 손실될 수 있으며 이는 작업의 안정성을 저해하거나 재컴퓨팅을 통해 중복 작업을 초래할 수 있습니다. 이에 대한 해결 방법으로 실행 중인 작업에 영향을 미치지 않고 노드를 정상적으로 중단하기 위해 Amazon EMR은 Apache Hadoop의 폐기 메커니즘을 사용할 수 있습니다. Amazon EMR 팀은 이 메커니즘을 개발하여 오픈 소스로 공헌하기도 했습니다. 이 메커니즘은 대부분의 하둡 [ more… ]

Parquet 형식의 EMRFS S3 최적화 커미터를 통한 Apache Spark 쓰기 성능 개선하기 EMRFS S3 최적화 커미터는 Amazon EMR 5.19.0부터 Apache Spark 작업에 사용할 수 있는 새로운 출력 커미터입니다. 이 커미터는 EMRFS(EMR 파일 시스템)을 사용하는 Amazon S3에 Apache Parquet 파일을 쓸 때의 성능을 개선합니다. 이 게시물에서는 최근 성능 벤치마크를 실행하여 신규 최적화된 커미터를 기존 커미터 알고리즘(FileOutputCommitter 알고리즘 버전 1 및 2)과 비교하여 어떻게 Spark 쓰기 성능이 개선되었는지 알아봅니다. 실제 사용 시, 제약 사항에 대해 설명하고 가능한 해결 방법을 제시해 드리고자 합니다. EMRFS S3와 FileOutputCommitter와 비교 Amazon EMR 버전 5.19.0 이하에서는 Amazon S3에 Parquet를 쓰는 Spark 작업에는 기본적으로 FileOutputCommitter라고 하는 Hadoop 커밋 알고리즘이 사용해 왔습니다. 이 알고리즘에는 버전 1과 버전 2의 두 가지 버전이 있습니다. 두 버전 모두 임시 위치에 중간 작업 출력을 쓰는 방법을 활용합니다. 그런 다음 이름 바꾸기 작업을 수행하여 작업 완료 시간에 데이터를 표시합니다. 알고리즘 버전 1에는 두 가지 [ more… ]