AWS Reinvent 2019 – 15분 안에 복습하기
들어가며
안녕하십니까. GS네오텍 최준승입니다.
클라우드 분야에서 일을 함에 있어(또는 사용함에 있어) 새로 나온 것들을 살펴보는 것만큼 중요한 일이 있을까 싶습니다. 신규 서비스도 개선된 기능들도 등장하는 속도가 워낙 빠르기 때문에, 클라우드를 제대로 활용하려면 자기 환경에 맞게 새로 나온것들을 선택적이고 영리하게 취해야만 합니다. 물론 기존의 방법론을 고수할 수도 있지만, 사용자의 피드백으로부터 만들어진 더 편하고 효율적인 수단들을 굳이 마다할 필요는 없겠죠. 한편 그 새로운 것들을 정리하고 요약하는 입장에서는 과거(AS-IS) 히스토리부터 알아야 하고, 현재의 이슈나 제약사항을 살핀 후, 앞으로(미래) 어떤 영향을 끼칠 덩어리인지를 판단해야 합니다. 각 주제별로 과거/현재/미래를 두루치기하는 작업이라고 생각합니다.
암튼 그래서 오늘은 Reinvent 2019에 등장한 무수한 업데이트들을 15분 요약 버전으로 정리하고자 합니다. 자세한 내용을 다루기에 앞서, 각각의 업데이트가 대충 어떤 컨셉이고 이것이 독자의 환경과 유관한지 정도를 판단할 수 있는 정도의 정보를 드리려고 합니다. 이 과정에서 일부 설명은 지나치게 추상적이거나 생략되거나 반대로 지엽적일 수 있는 부분은 양해 부탁드립니다.
바로 시작하겠습니다. 각 주제별로 제목을 클릭하면 관련 AWS 링크로 이동합니다.
AWS Reinvent 2019 업데이트 몰아보기
크게 4개의 카테고리로 나눠서 살펴보도록 하겠습니다.
▨ Compute
새로운 인스턴스 계열(Inf1)이 또 나왔습니다. 출시 기준으로는 4개의 Size를 선택해서 사용할 수 있습니다. Inferentia chip이 최대 16개까지 구성되어 있어 ML 작업에 최적화된 사양을 지원한다고 하네요. Accelerated Computing 군으로 비용 효율에 따라 G4나 P3 계열을 대체할 수 있습니다. `19년 12월 기준, virginia와 oregon 리전에서만 사용 가능합니다.
Fargate는 컨테이너를 호스팅할때 기반이 되는 인스턴스(EC2) 관리가 필요 없는 서버리스 기반의 옵션입니다. ECS 서비스의 경우 호스팅하는 위치를 EC2 또는 Fargate를 선택할 수 있었는데요. 이에 반해 EKS는 EC2 환경에만 컨테이너를 호스팅할 수 있었습니다. 이번 업데이트로 EKS 에서도 Fargate 환경에 컨테이너를 배치할 수 있게 되었습니다. 물론 Fargate 환경을 사용함에 있어 몇몇 제약사항이 존재합니다만, 궁극적으로는 제반 인프라에 대한 관리/선택 요소를 최대한 줄이고 어플리케이션 개발에 집중하라는 최신 트랜드에 적합한 업데이트가 아닐까 싶네요.
클라우드 환경에서는 대부분의 자원(수량)을 빠르게 재배치할 수 있기 때문에, 공유 자원 중 일부를 미리 할당하는 것은 일종의 낭비라고도 볼 수 있습니다. Lambda 또한 비슷한 이유로 Cold Start 현상이나 다량의 동시 요청시 늘어지는(?) 현상이 발생하곤 했는데요. 이 문제를 어메리카답게 돈으로 해결할 수 있는 옵션이 생겼습니다. 원하는 수량의 Provisioned Concurrency 값을 미리 설정해 놓으면, 동시 수행에 필요한 만큼의 자원을 미리 준비해 놓는다는 개념입니다. 물론 그만큼의 비용이 추가로 발생한다는 점도 꼭 알아두셔야 겠죠?
AWS Outpost라는 이름의 신규 서비스가 등장했습니다. 신규 서비스는 무엇보다 컨셉을 잘 이해하는것이 중요한데요. 규격화된 AWS의 물리 인프라를 나와 가까운 위치에 배치한다는 개념입니다. 서버가 위치하는 물리 환경(공간, 전원, 네트워크 등)은 사용자가 관리하고, 이를 제외한 패치/업데이트 등의 작업은 AWS가 매니지드 형식으로 관리합니다. 이를테면 RDS 인스턴스를 띄워주는 인프라를 1) 원하는 위치에 2) 독립적으로 구성할 수 있는 셈입니다. 한국에서도 주문할 수 있으며, [3년 약정]/[엔터프라이즈 서포트 사용] 등의 전제 조건이 있습니다.
AWS는 Optimization(최적화) 관점에서 사용자에게 많은 힌트를 줍니다. AWS Compute Optimizer 서비스도 그 연장선 상에 있습니다. 이전에도 Trusted Advisor나 Cost Explorer의 Rightsizing 항목에서 EC2 자원의 스펙 대비 자원 활용량을 어느정도 보고받을 수 있었는데요. Compute Optimizer 서비스는 그 판단 기준에 ML을 접목시킨 개념입니다. 현재 설정한 EC2 스펙이 실제 사용량에 비해 과도한지/적정한지/부족한지, 대안 스펙은 무엇인지, Auto Scaling은 적절하게 설정되었는지 등을 알려줍니다. 학습이 필요하므로 별도 Opt-In 설정이 필요하며, 히스토리에 따라 권장사항을 도출하기 위한 일정 시간이 필요합니다.
붕어빵처럼 인스턴스를 찍어내는 가상화 환경에서는 표준 이미지를 잘 잡아놓는 작업이 (보안적으로 특히) 중요한 일입니다. 문제는 이 작업이 번거롭고 반복적이기 때문에, 중요한걸 알지만 하지 않는다는 것인데요. 이런 분들을 위해 이미지를 생성하고, 패치하고, 테스트하고, 배포/공유하는 일련의 파이프라인을 자동화한 서비스(EC2 Image Builder)가 나왔습니다. 각 단계별로 관련 레시피를 미리 정의해 놓으면, 해당 규칙에 따라 이미지를 생성하고 후속 작업을 수행합니다. 이 과정에서 타 AWS 서비스와 잘 통합되어 있어 이미지 공유 범위를 참조하거나 테스트 액션을 정의할 수 있습니다.
▨ Security and Network
이번에도 신규 서비스입니다. 이름이 IAM Access Analyzer니까, IAM 과 관련된 어떤것을 분석해주는 모양입니다. 사전적인 정의에 따르면 “당신 계정의 Resources” 중 “External Principals”와 공유하고 있는 것이 무엇인지 알려준다고 합니다. 여기서 말하는 [External Principals]은 타 AWS 계정 / 루트 사용자 / IAM User(Role) / Federated User 등이 되고, [Resources]는 S3 버킷 / IAM Role / KMS 키 / SQS 큐 / Lambda 함수 등이 됩니다. 이를 바탕으로 내 계정 내의 자원이 외부에 어떤식으로 권한을 위임하고 있는지를 원큐에 점검할 수 있습니다. 활성화는 리전 단위로 해야 하며, 별도 과금은 없습니다.
S3 버킷 레벨에서 접근 규칙을 정의하는 일반적인 방법은 Bucket Policy를 사용하는 것이었습니다. 하지만 복수의 정책이 하나의 Bucket Policy 내에 짬뽕되어 있다보니, 이후 정책을 갱신/관리하기가 쉽지 않았습니다. 이번에 발표된 S3 Access Point는 용도별로 Access Point 끝점을 따로 생성하고, 그 단위단위별로 접근 정책을 각자 설정할 수 있습니다.
이 업데이트 핵심은 VPC의 Internet G/W나 Virtual G/W에 Route Table을 매핑할 수 있게 되었다는 것입니다. 예전에는 할 수 없었죠. 이게 편리한 점은 가상의 G/W로 통해 유입된 트래픽을 Destination에 따라 특정 ENI로 보내버릴 수 있다는 것입니다. 예를 들면 특정 VPC Subnet 주소로 향하는 트래픽을 특정 인스턴스(IDS/IPS 같은)의 ENI로 라우팅해서 필터링할 수 있게 된 것이죠. 위 그림에 나온 IGW의 Route Table을 잘 살펴보시기 바랍니다.
말그대로 Transit Gateway에서 Inter-Region Peering을 지원한다는 내용입니다. 이로써 서로 다른 리전의 Transit Gateway간 Peering을 설정할 수 있게 되었습니다. 연동하는 구간이 복잡해질수록 결국에는 Transit Gateway의 효용이 커지기 때문에, 해당 기능의 활용성이 점점 좋아진다고 생각하면 되겠네요. 참고로 `19년 12월 기준, seoul 리전은 지원하지 않습니다.
이번 것도 Transit Gateway와 관련된 업데이트입니다. Network Manager는 Transit Gateway에 연결된 객체들의 상관관계를 시각적으로 보여줍니다. 각 구간별 연결상태는 어떤지, 연결정보는 무엇인지를 하나의 뷰에서 직관적으로 확인할 수 있습니다. 기존에 AWS Marketplace에서 파는 네트웍 제품들에서 대부분 지원하던 편의 기능인데, 스물스물 AWS도 이런 부분까지 내재화하고 있네요.
▨ Guitar
Step Function에서 Express Workflow라는 것이 새로 생겼습니다. 기존 Standard Workflow가 Long-running / Durable / Auditable 에 적합한 특성이라면, Express Workflow는 뭔가 짧은시간에 집약적인 것들을 처리할 수 있는 컨셉으로 설계되어 있습니다. 동작방식 / 제약사항 / 과금 기준까지 모두 상이하기 때문에, 차이점은 위 비교표를 확인하시기 바랍니다.
Redshift에서 사용할 수 있는 새로운 노드 타입(RA3)이 생겼습니다. 기존 DC2/DS2 타입의 경우 컴퓨팅과 스토리지 부분을 통합팩으로 팔았다면, RA3의 경우 컴퓨팅과 스토리지 영역이 분리되어 있습니다. 스토리지 특성상 DC2 타입보다는 DS2 타입을 대체(대용량의 스토리지 + 성능 대비 개선된 가격)할 것으로 보입니다.
▨ Machine Learning
Introducing Amazon SageMaker Autopilot
Sagemaker Autopilot은 AutoML 계열 서비스입니다. Training 과정에서 사용자가 설계하는 변수들 [알고리즘 / 하이퍼파라미터 최적화 / 인스턴스(클러스터) 크기 등]을 자동으로 선택(=가능한 실험 조합을 구성하고 시뮬레이션을 수행)해주는 서비스입니다. Autopilot 작업을 완료하면 두개의 ipynb 파일을 S3에 내려줍니다. 사용자는 해당 노트북 파일을 통해 수행 작업의 상세 내용을 확인할 수 있습니다.
Sagemaker Model Monitor는 (추론) 모델의 (입/출력값과 관련된) 이모저모를 모니터링해주는 서비스입니다. 1) 추론 모델로 유입된 입력값(+출력값)을 캡쳐하도록 설정 2) 훈련 데이터 기반으로 기준(Baseline)을 생성 3) 모니터링 옵션(시점, 통계)을 지정 4) 원하는 결과값(통계값, 잘못된 입력 등)을 확인하는 순으로 구성되어 있습니다. 사용자는 이를 통해 실제 프로덕션 환경에서 유입되는 입력값을 모니터링하고, 이것이 기존 훈련 데이터의 결에서 크게 벗어나지 않는지 등의 직관적인 정보를 빠르게 확인할 수 있습니다.
Sagemaker Debugger는 훈련 과정에서 무언가 빠르게 디버깅을 할 수 있도록 도와주는 서비스입니다. 디버깅을 하려면 문제 상황을 인지해야 하고, 문제 상황을 판단하려면 일정한 기준이 필요하겠죠? 예를 들어 현재 훈련 과정에서 overfit이 발생하고 있다고 판단된다면 이 지점을 CloudWatch에 이벤트 형태로 리포팅 해주는 개념입니다. `19년 12월 기준으로 15개 정도의 Built-In Rule이 정의되어 있으며, 사용자가 Custom 형태로 직접 정의하는 것도 가능합니다.
Sagemaker Experiments는 훈련과 관련된 각종 메타 정보를 쉽게 관리/확인할 수 있도록 하는 일종의 툴 개념입니다. 해당 정보들을 Pandas의 DataFrame 형식으로 받을 수 있기 때문에, 향후 데이터를 원하는대로 가공하거나 시각화하기 쉬운 장점이 있습니다.
마지막으로 Sagemaker Studio는 ML 전용 IDE(Integrated Development Environment) 서비스입니다. 위에서 설명한 타 Sagemaker 단위 기능들과 긴밀하게 통합되어 있습니다. `19년 12월 기준, Ohio 리전에서만 제한적으로 사용할 수 있습니다. 현재 Sagemaker Studio Notebook이 Preview 상태기 때문에, 이 부분이 GA되고 나면 좀 더 나은 환경에서 Sagemaker Studio 서비스를 활용할 수 있을 것으로 보입니다.
마치며
올해는 예년에 비해 업데이트 수가 상대적으로 적은 느낌입니다.
AWS는 그만큼 더 나올게 없는 성숙한(?) 플랫폼이라서 그런가 싶기도 하네요.
오늘 포스팅은 어떤 업데이트가 있었는지 대략적으로 환기하는 차원이구요.
참고로 오늘 정리에서는 Preview 상태인 아이템는 제외했는데, 이 부분은 이후에 갱신되는대로 다시 다룰 예정입니다.
참고로 오늘 정리에서는 Preview 상태인 아이템는 제외했는데, 이 부분은 이후에 갱신되는대로 다시 다룰 예정입니다.
각 주제별로 상세한 포스팅은 차주부터(크리스마스 전까지) 본격적으로 진행하도록 하겠습니다.
그럼 마칩니다. 끝!
최신 댓글