WiseN

AWS 업데이트 읽어주기 19년-10월

Blog thumbnail

여기서 다루는 내용

· 들어가며
· 10월 업데이트 소개
· 마치며 


들어가며



안녕하십니까. GS네오텍 최준승입니다.

블로그가 최근에 새집으로 이사를 왔습니다.
했던 얘기를 할머니처럼 또 하는 이유는 제가 아직도 블로그 디자인에 익숙해지지 않았기 때문입니다.
글의 가독성이란 측면에서 형식과 내용은 아주 밀접한 관계에 놓여있기 때문에
형식(디자인)이 고정된 환경에서는 '내용을 펼쳐보이는 방식'을 형식에 맞출 필요가 있습니다.

오늘은 10월에 발표된 AWS 업데이트를 살펴볼 예정인데요.
앞에서 말씀드렸듯이 내용을 전개하는 방식을 매번 바꾸어 적용해보려고 합니다.
이번 회차에는 참고할만한 그림이나 표를 실험적으로 몇개 넣어보려고 해요.

각설하고 그럼 시작하겠습니다. 


10월 업데이트 소개


오늘 소개드릴 업데이트는 총 6개입니다.

순서는 '업데이트 중요도' 순이 아니라 (업데이트와 연관된) '서비스의 중요도' 순입니다.
각 제목을 클릭하면 AWS 공식 링크가 새창으로 뜰 수 있게 태그를 달아놨으니 참고하세요.

Introducing Amazon EC2 M5n, M5dn, R5n, and R5dn instances featuring 100 Gbps of Network Bandwidth

새로운 인스턴스 계열이 또 출시되었습니다. 이번에 출시된 계열은 m5(d)n, r5(d)n입니다.
인터넷에 돌아 다니는 정보에 따르면 뒤에 붙어있는 소문자들의 작명 규칙은 다음과 같습니다
  • a → for AMD CPUs
  • ​ for Extra Capacity (Storage or RAM)
  • → for Networking Optimized
  • d  for Directly-​Attached Instance Storage (NVMe)
기존에 m5(d)/r5(d). 계열은 이미 있었으니 이번에는 n이 붙은 애들이 추가된 셈입니다. 작명 규칙에 따르면 n이 붙은 애들은 네트워크 성능이 크게 향상되었겠네요. 좀 더 엄밀히 말하면 EBS Bandwidth에는 변경 사항이 없고 Network Bandwidth 스펙값이 상향되었습니다.



사실 c5 라인에서는 이미 2018년부터 c5n 계열을 통해 동일 수준의 네트웍 대역폭을 제공하고 있었기 때문에, 이처럼 큰 네트웍 대역폭이 필요한 경우에는 vcpu와 memory 비율과 무관하게 c5n 타입을 써야 했습니다. 이제는 m5/r5 계열도 유사한 선택지가 생겼기 때문에 선택의 폭이 좀 더 넓어졌다고 할 수 있겠죠. 이러한 큰 네트웍 대역폭은 S3와 같이 거리가 가깝고 병렬방식으로 접근할 수 있는 스토리지와 데이터를 주고 받을때 큰 효과를 볼 수 있습니다. 단가는 확인해보니 동일 크기의 인스턴스 타입에서 n이 붙는 경우 평균 15% 정도 비싸집니다. 리눅스 기준이니 라이센스 비용이 묻어있는 OS의 경우 그 비율 차이는 더 작아질 수 있습니다.

 

Windows Nodes Supported by Amazon EKS

Amazon EKS 서비스에서 windows 기반 worker node를 공식 지원합니다. 참고로 19년 초부터 Public Preview를 쭉 진행해 오다가 어느정도 안정화가 이뤄진 후에 정식 출시한 것으로 보입니다. 물론 몇가지 제약사항이 있습니다.

  • Kubernetes v1.14 이후 환경에서 동작
  • Host networking mode 미지원
  • EKS cluster 내에 최소 1개 이상의 Linux worker node가 포함되어 있어야 함
AWS에서는 이에 발맞춰 ​Windows Server 2019를 기반으로 한 2가지 버전의 EKS-optimized AMI를 리전 단위로 제공합니다. 해당 AMI의 ID는 ssm 서비스를 통해 질의하거나 아래와 같은 AWS 안내페이지를 통해 확인할 수 있습니다.


windows worker node를 배포하는 절차는 기존과 크게 다르지 않습니다. 몇가지 사전작업을 완료하고, 위에서 확인한 AMI ID를 지정해서 worker node를 배포한 후, 이후 컨테이너를 배포할때 nodeSelector 항목을 적절히 지정해주면 됩니다. 암튼 이제 IIS같은 윈도우 환경의 어플리케이션도 컨테이너 환경에 좀 더 쉽고 자연스럽게 배포할 수 있게 되었네요.

AWS Firewall Manager now supports management of Amazon VPC security groups

AWS가 잘 하는 것중 하나는 다계정의 운용에 대해 항상 신경을 쓰고 있다는 점입니다. 목적이 관리주체의 분리든 비용의 분리든간에 AWS 계정을 여러개로 분리해서 운용해야 하는 상황이 꽤나 빈번하게 발생합니다. 문제는 이렇게 계정을 분리하고 나면, 내부 리소스와의 연동 문제나 산발적으로 흩어지는 관리 포인트들을 각기 따로 신경써야 하는 부작용이 생기는데요. 이런 단점을 보완하기 위한 여러가지 방법을 AWS가 개발해서 단위 기능 형태로 제공하곤 합니다.

Firewall Manager라는 서비스는 다계정 환경에서 방화벽 룰을​ 통합 관리할 수 있는 매니저 역할을 합니다. 이전에는 WAF와 Shield Advanced 서비스를 대상으로 내부 정책을 (동일 organization으로 묶인) 여러 계정에 동시 반영할 수 있는 기능을 제공했습니다.



그리고 이번 업데이트로 VPC의 Security Group 룰도 동일한 방식으로 통합 관리할 수 있게 되었습니다.


 

아직 테스트해보진 않았지만 그림상으로 보면 primary 객체가 있고 이 객체에 룰을 수정하면 하위에 묶인 각 계정의 security group에 룰이 복제되는 방식으로 보이네요. 물론 organization으로 사전에 계정들을 묶어줘야 한다는 점과 관리포인트가 하나로 응집되는만큼 마스터 객체의 관리에 더욱 신경써야 한다는 과제가 생기긴 합니다. 어쨌거나 사용자에게 다양한 선택지를 준다는 점은 장점입니다.

이후에는 Kinesis Data Firehose를 둘러싼 몇몇 업데이트를 짧게 언급하고 마무리하겠습니다.

Amazon API Gateway now supports access logging to Amazon Kinesis Data Firehose

API Gateway Access Log를 Kinesis Data Firehose로 보낼 수 있게 되었습니다. 기존에는 Cloudwatch logs로 보내는 기능만 제공했던 것으로 기억하는데요. Kinesis Data Firehose에서 로그 스트림을 일부 변형해서 원하는 위치로 떨구는 것이 더욱 용이하게 되었습니다.

Amazon Kinesis Data Firehose adds support for data stream delivery to Amazon Elasticsearch Service 7.x clusters

Kinesis Data Firehose에서 Amazon Elasticsearch 7점대 버전에 데이터를 넘겨줄 수 있게 되었습니다. 기존에는 6점대 버전으로 넘겨주는 기능만 제공했던 모양입니다.

Amazon Kinesis Data Firehose adds cross-account delivery to Amazon Elasticsearch Service
타 계정의 Elasticsearch 객체에 데이터를 넘겨줄 수 있게 되었습니다. 이 또한 다계정 환경의 사용자에게 편리함을 선물하는 기능이네요.

 

드디어 오늘 준비한 업데이트 소개가 끝났습니다. 정리하겠습니다. 


마치며


앞서 말씀드린대로 오늘은 보조 이미지나 표를 이것저것 추가해 보았습니다.
글만 쭉 적혀있던 이전 형식에 비해 가독성이 조금이라도 좋아지셨는지 모르겠네요.

이제 10월 말이니 해마다 찾아오는 AWS 리인벤트 행사도 코앞으로 다가왔습니다. 작명 기획을 참 잘한것 같아요. Reinvent라니
그때까지 형식에 대한 고민도 좀 더 해보고. 그 수많은 업데이트를 정리하기 위한 체력도 미리 충전해 놓도록 하겠습니다. 

그럼 마칩니다. 끝!