AWS 업데이트 읽어주기 19년-9월
여기서 다루는 내용
· 들어가며
· 업데이트 소개
· 마치며
들어가며
안녕하십니까. GS네오텍 최준승입니다.
블로그가 새집으로 이사를 왔습니다.
일단 페이지 디자인이 바뀌었고, 글쓰는 환경도 여러모로 낯선 느낌이네요.
오늘은 지난 한달간 발표된 AWS 업데이트를 훑어보도록 하겠습니다.
업데이트 소개
총 10개의 업데이트 아이템을 골랐습니다.
순서는 업데이트 중요도 순이 아니라 (업데이트와 관련된) 서비스 중요도 순입니다.
각 제목을 클릭하면 AWS 공식링크로 이동합니다.
Introducing Amazon EC2 G4 Instances with NVIDIA T4 Tensor Core GPUs
새로운 인스턴스 계열이 또 출시되었습니다. 이제는 AWS가 제공하는 인스턴스 계열이 하도 많아져서, 이런 소식을 전하는 의미도 날로 줄어드는 느낌입니다. 이번에 새로 출시된 계열은 G4 계열입니다. 이름은 ‘g4dn.’으로 시작하구요. GPU를 탑재하고 있습니다. 세부적인 스펙이나 가격은 공식 페이지를 참고하시면 됩니다. 보통 AWS에서 새로운 인스턴스 계열을 내놓을때는 이전 계열에 비해 가성비가 상대적으로 낫도록 가격을 셋팅합니다. 따라서 G3 계열에 비해서 같은 싸이즈에서 스펙은 좀 더 좋고 가격은 비슷하거나 약간 싸게 되어 있습니다. 현재 Spot 이나 RI 옵션도 자유롭게 활용할 수 있다고 하니, 사람들이 잘 모를 시기에 Spot 옵션으로 싸게 한번 써보도록 합시다.
NLB가 SNI에 대응하여 복수의 TLS 인증서를 지정할 수 있게 되었습니다. 여러개의 LB를 만들기 싫어하는 사람이 있다고 가정해 봅시다. 이 사람은 클라이언트의 모든 요청을 하나의 NLB로 처리하고 싶어합니다. 서비스 도메인은 여러개고, 인증서 처리는 LB 계층에서 해야 합니다. 기존에는 이 모든 조건을 만족시키려면, 인증서가 ‘와일드카드 인증서’나 ‘멀티-도메인(SAN) 인증서’ 였어야만 했습니다. 왜냐하면 NLB의 각 Listener 설정에 하나의 인증서만 등록할 수 있었기 때문입니다. 하지만 앞으로는 복수의 TLS 인증서를 등록해도 됩니다. NLB가 SNI에 대응하여 클라이언트의 요청에 따라 어느 인증서를 사용할지 스마트하게 골라주기 때문입니다. 사용자가 어느 방식으로 인증서를 만들어 관리할지 선택지가 늘어난 셈입니다. 참고로 ALB는 이미 2017년부터 SNI에 대응하여 복수의 인증서를 등록하여 사용할 수 있었습니다.
Amazon S3 introduces Same-Region Replication
S3 서비스의 관리기능 중에 Replication(복제)라는게 있습니다. 말그대로 Source 버킷에 새로운 객체가 올라오면 해당 객체를 Target 버킷에 자동으로 복제해주는 기능입니다. 직관적인 기능이지만 세부적인 복제 규칙으로 들어가면 셈법이 좀 복잡합니다. 아무튼 이 기능의 제약사항 중 ‘Target 버킷은 반드시 Source 버킷과 다른 Region에 위치해야 한다’라는게 있었습니다. 이번 업데이트로 앞으로는 Source 버킷과 Target 버킷이 같은 Region에 있어도 됩니다. 참고로 이 복제 기능은 예전부터 AWS 계정을 넘나들 수 있게 만들어져 있는데요. ‘동일 리전으로 복제를 설정할 수 있다’와 ‘다른 계정으로 복제를 설정할 수 있다’가 결합하면 활용도가 크게 좋아집니다. 예를 들어 로그 수집/처리/분석 전용의 AWS 계정(L)을 하나 만들었다고 해봅시다. 복수의 AWS 계정을 활용하는 환경이라면, 복제 기능만으로 S3에 떨어지는 로그들을 이 L이라는 AWS 계정 내에 쉽게 중앙화할 수 있습니다. 리전과 관계없이 말이죠. 로그를 하나의 리전내에 모두 모을 수도 있고, 각 리전 단위로 모을수도 있습니다. 이렇게 데이터를 처음부터 예쁘게 잘 모아놓으면 이후 Athena로 쿼리를 하든 다른 로그 프로세싱을 하든 이후 처리 작업이 좀 더 단순해질 수 있겠죠.
AWS Direct Connect support for AWS Transit Gateway is Now Available in Six Additional Regions
AWS 업데이트 글을 읽을때는 반드시 주어를 정확하게 파악할 필요가 있습니다. 주어의 범위에 따라 중요한 업데이트가 되기도 하고, 그렇지 않은 것이 되기도 하니까요. 이번 업데이트는 기존에 ‘Transit G/W에 Direct Connect를 연결’할 수 있었는데, 대상 리전이 6개 추가되었다는 내용입니다. 그리고 추가된 6개 리전에 서울 리전이 포함되어 있습니다. 보통 Transit G/W에 D/X 연결을 매핑하려면 Transit Gateway – D/X Gateway – D/X 구성을 따릅니다. Transit Gateway는 동일 Region의 객체만 연결할 수 있습니다. D/X Gateway는 D/X의 물리적 위치와 상관없이 타 리전에 D/X 연결점을 끌어 갈수 있는 기능입니다. 즉, 이번 업데이트로 서울 리전에서 Transit Gateway의 활용도가 크게 높아졌습니다. 다른 리전의 D/X 연결을 D/X Gateway로 서울 리전으로 끌고 와 Transit Gateway로 연결할 수 있게 되었습니다. 기존에는 EC2 베이스로 CSR같은 허브 계층을 올려써야 했다면, 이제 Transit Gateway같은 매니지드 서비스로 허브 계층을 전환하여 가용성 관리의 굴레에서 벗어날 수 있습니다.
Announcing General Availability of Amazon Quantum Ledger Database (QLDB)
Amazon QLDB라는 서비스가 공식 출시(GA) 되었습니다. 정확한 서비스 컨셉과 기능은 단계적으로 확인이 필요할 것 같구요. 데이터의 무결성 및 갱신 기록을 완벽하게 유지해야 하는 용도의 DB라고 합니다. 매니지드 서비스 컨셉이구요. 블록 체인이나 금융 기관에서 활용할 것으로 기대한다고 하네요. 이번에 서울 리전은 출시되지 않았고, 미주와 아일랜드, 도쿄 리전에 출시되었습니다.
Amazon EKS Adds Support to Assign IAM Permissions to Kubernetes Service Accounts
제가 꿀팁을 하나 드리겠습니다. AWS 시험에서 IAM 관련된 문제가 나왔을때 엥간하면 맞출 수 있는 방법이 있습니다. 선택지에서 IAM Role을 찾으시면 됩니다. 그럼 80% 이상은 맞습니다. 특정 AWS 서비스에서 다른 AWS 서비스의 API를 호출할때 IAM Role을 활용하는 것은 그만큼 모범 사례라는 말이죠. EC2 환경에서도 마찬가지입니다. 그럼 EKS 환경에서는 어떠했을까요? EKS 환경의 Pod는 해당 Pod이 위치한 호스트의 권한을 상속받았습니다. 이 말은 동일 객체에 위치한 Pod들은 모두 같은 IAM 권한을 들고 있었다는 말이 됩니다. 이렇게 통으로 다루게 되면 권한을 일종의 합집합(?)으로 정의해야 하므로 관리도 어렵고 보안상으로도 좋지 않았습니다. 이번 업데이트로 쿠버네티스상의 ‘Service Account’와 IAM Role을 1:1로 매핑해서, Pod 단위로 IAM 권한을 제어할 수 있게 되었습니다. 세부적으로 들어가면 OIDC 설정을 하고 약간 복잡하긴 한데, 아무튼 EKS 환경에서 Pod 단위로 IAM 권한을 제어할 수 있게 되었다는 점만 기억하도록 합시다.
Container monitoring for Amazon ECS, EKS, and Kubernetes is now available in Amazon CloudWatch
Cloudwatch에 보면 Namespace라는 단위가 있습니다. 이게 값을 구분지어 보관하는 일종의 통같은 개념인데, AWS 서비스 단위라고 생각하면 얼추 맞습니다. ECS의 경우에도 ‘AWS/ECS’ 라는 네임스페이스를 통해 각종 메트릭값을 확인할 수 있었는데요. 아주 제한적인 정보를 보여주기 때문에 사실상 큰 도움이 되지 못했습니다. 하지만 이번 업데이트를 통해 앞으로는 ECS든 EKS든 클러스터/서비스/노드 단위의 값을 세부적으로 볼 수 있게 되었습니다. 단 해당 메트릭(Namespace: Container insight)을 보기 위해서는 약간의 사전 작업이 필요합니다. 무엇보다도 Cloudwatch 환경으로 컨테이너 환경의 객체 지표를 끌고 들어왔기 때문에, 이후에 Cloudwatch의 다양한 기능과 AWS 연동 포인트들을 쉽게 활용할 수 있다는 것이 가장 큰 장점입니다.
Amazon Forecast Now Generally Available
Amazon Forecast 서비스가 공식 출시(GA)되었습니다. AWS가 잘하는 것중의 하나가 서비스를 다계층으로 참 풍부하게 만들어 놓는다는 것입니다. 아무래도 돈이 많아서 그렇겠죠. 이를테면 Sagemaker라고 하는 머신러닝 서비스가 이미 있습니다. 이 Sagemaker가 약간 파쓰(PaaS)스러운 서비스라면, Forecast는 조금 더 싸쓰(SaaS)에 가까운 서비스입니다. 시계열(time-series) 예측 전용의 ML 서비스구요. 특정 도메인(재고예측,판매량,웹트래픽 등등)을 선택하고 데이터만 밀어주면 모델링을 해다가 향후 예측값을 쭉 뽑아줍니다. 상대적으로 커스텀할 수 있는 범위는 좁지만 반대로 그만큼 캐주얼하게 접근하기는 쉬운 장점이 있습니다. ’19년 9월 기준으로 서울 리전에는 출시되지 않았습니다. 궁금하신 분은 미주나 도쿄 리전에서 테스트해보시면 됩니다.
Sagemaker 얘기 나온 김에 하나 더 소개하겠습니다. 클라우드는 종량제 기반이므로 클라우드를 잘 쓴다는건 비용-대비-효율적으로 자원을 잘 활용한다는 말이 됩니다. 그런데 애초에 서비스 단가가 너무 비싸다면 어떨까요? (물론 Sagemaker 과금 정책이 비싸다는 말은 아닙니다) 안쓰겠죠. 아마도 사용자는 다른 비용-효율적인 방법을 찾아볼 겁니다. 이번 Sagemaker 업데이트에서는 (가장 큰 비용을 차지하는) Training 단계에서 Spot 인스턴스 자원을 활용할 수 있게 되었습니다. 사용자가 Spot 활용과 관련된 몇몇 파라미터만 지정해주면, Sagemaker에서 알아서 Spot 인스턴스를 할당 받고 훈련하다 뺏기면 멈췄다가 나중에 다시 할당받아서 재시작까지 해준다는 것이죠. 세부적으로 내가 얼마에 비딩을 했고 이런 정보는 보여주지 않습니다. 그냥 작업이 완료된 후에 기존에 On-Demand 방식에서 과금되는 시간이 100초라고 하면 Spot을 활용해서 (예를 들어) 30초 비용만 받는다는 식으로 알려줍니다. 사용자는 내가 최대 얼마까지 기다릴 수 있는지 ‘MaxWaitTimeInSeconds’만 지정해주고 작업이 끝날때까지 기다리면 됩니다.
Lower Threshold for AWS WAF Rate-based Rules
AWS WAF라는 서비스에는 여러 계층의 단위 객체가 있습니다. 그 중 ‘Rule’ 이라는 단위가 있구요. 이 Rule의 속성에 ‘Rule Type’이란게 있습니다. Rule Type에는 ‘Regular’와 ‘Rate-Based’가 있죠. 이 중 ‘Rate-Based’ Rule은 거의 사용하는 사람이 없었습니다. AWS WAF 자체가 딱히 인기 있는 서비스도 아닐 뿐더러, Rate-Based Rule의 제약사항이 너무 강해서 활용성이 떨어졌기 때문입니다. 제약조건에서는 특정 조건에 부합하는 요청이 5분당 2,000개 이상일 때, 해당 요청을 Allow하거나 Block할 수 있었습니다. 여기서 설정할 수 있는 2,000이라는 최소 임계점이 너무 하드했던것이 문제였습니다. 이번 업데이트로 이 최소 설정값이 기존 2,000에서 100으로 변경되었습니다. 서비스를 제공하는 AWS 입장에서는 저 값을 줄이는 부담(프로세싱)이 적지 않아 보임에도 불구하고, 어쨌든 사용자-활용성이라는 측면에서 의미 있는 수준까지 기능을 개선한 것으로 보입니다.
10개 끝났습니다. 정리하겠습니다.
마치며
이미지 없이 글만 많으니 읽기가 좀 빡빡한 측면이 있네요.
참고로 동일한 내용을 사내 엔지니어분들께 공유할때는 최대한 그림과 캡쳐 위주로 설명을 진행합니다.
누가 읽고/보느냐에 따라 가급적 형식을 달리 하려고 합니다.
다음 회차에서는 포스팅에 그림을 선택적으로 추가해보도록 하겠습니다.
끝!
최신 댓글