Cloud Computing On Demand

Cloud Platform 을 사용할 때 가장 조심해야 하는 것 중 하나가, 각 플랫폼이 가지고 있는 QoS (Quality of Service) 수치를 넘지 않도록 해야 한다는 것입니다. 물론, 이 수치는 Support Ticket 등을 통해 늘리는 것이 가능하지만 시간이 소요될 수 있기 때문에 이벤트 등 대규모 사용자가 몰리는 이벤트가 준비중이라면 미리 체크를 해두어야 합니다. 

CDN 제품인 AWS CloudFront 도 마찬가지인데요, 적용되고 있는 여러가지 제한 중 이벤트 트레픽에 대한 고려사항은 크게 1) 대역폭에 대한 Limit 과 2) 요청수에 대한 Limit 이 있습니다. AWS 공식 문서에서는 `할당량` 또는 `Quotas` 로 제품 문서에서 확인할 수 있는 내용입니다. 

대역폭과 전송량 제한

CloudFront 의 할당량 정책은 기본적으로 Distribution 당으로 적용됩니다. 참고로 시장 지배 사업자인 아카마이 Akamai 의 경우 Bucket 이라는 컨셉이 있고 CP Code 단위로 대역폭에 대한 관리만 하고 있습니다. 아카마이와 달리 CloudFront 의 경우 대역폭과 요청량의 두가지 제한이 있습니다. 

Distribution 을 `배포` 라고 표현하고 있는 부분은 늘 적응이 잘 안되네요. API 에서도 distid 등을 사용하니 Distribution 으로 인지하는 것이 편합니다. 공식 문서에 나온 것처럼 대역폭은 150Gbps 가 기본 제한이고 요청량은 250,000rps 가 기본 제한으로 들어가 있습니다. 바로 아래에 있는 `더 높은 할당량 요청`이 있는 이유는 조정이 가능하기 때문이겠죠? ^^

`더 높은 할당량 요청`을 누르면 Support 페이지로 넘어가고 `Service Limit Increase` 타입의 티켓을 열어 할당량을 높이는 방식입니다. 느낌이 오시겠지만 시간이 좀 걸릴 수 있는 부분이라 예측하지 못한 트레픽 Burst 가 아니고 계획된 이벤트라면 미리 할당량을 조정해 두시는 것이 정석입니다. 

할당량 초과는 어떻게 알 수 있을까?

CloudFront 에서는 위의 할당량이 초과 되었다 하더라도 알려주는 것은 없습니다. 요행히 CloudWatch 로 Distribution 의 에러 비율에 대한 알람을 걸어두었다면 메일을 통하여 한템포 늦게 인지할 수 있는 방법이 있긴 합니다. 다른 방법으로는 CloudFront 의 Monitoring 화면에서 사용자의 트레픽이 급격히 늘면서 5xx 에러가 증가했는지를 확인하는 방법이 있습니다.

후행적으로 확인하는 방법은 (이미 장애는 났고... 사용자는 영향을 받았고...) CloudFront 의 Access Log 를 통하는 방법이 있습니다. Access Log 의 필드중 2020년 12월 3일 기준으로 14번째 컬럼인 `x-edge-result-type` 이나 23번째 컬럼인 `x-edge-response-result-type` 의 값을 이용해서 확인할 수 있습니다. 

이 필드의 값으로 `LimitExceeded` 가 특히 할당량, Limit 초과에 대한 부분입니다. 문제는 LimitExceeded 가 어떤 Limit 을 초과한 것인지를 알려주지 않습니다. 알고 싶다면 <또> Support Ticket 을 열어야 합니다. 해보신 분들은 아시겠지만 Ticket 을 열면서 꼭 샘플 로그를 추출해서 제공해 주셔야 합니다. 

용량관리는 인프라에서 무척 중요한 부분입니다. 우리가 클라우드 서비스를 이용하는 이유중 하나는 그런 용량 관리로부터 조금이나마 자유롭고 싶어서 이지만, 결국 클라우드 서비스도 그들 입장에서는 용량관리를 해야만 합니다. 때문에 위와 같은 제한들이 존재하고 사용하고 있는 사업자의 숫자들을 기억해 둘 필요가 있습니다. 

> 참고 URL

CDN 의 핵심은 두가지입니다. 하나는 캐싱을 통한 사용자와 서버간의 거리 단축이고, 다른 하나는 사용자와 캐싱 서버 (=엣지 서버) 간의 거리를 줄여 불확실한 구간을 최소화 하는 것입니다. 이 두가지는 표현이 조금 다르고 추구하는 바가 달라보이기는 하지만 결국 <사용자의 지연 Latency 를 최소화 한다> 라는 공통된 목적을 가지고 있습니다. 

때문에 많은 CDN 벤더들은 계층형 캐시를 사용할 수 있는 방법을 제공하고 있습니다. AWS 에서 CloudFront 제품의 기능으로 새롭게 출시한 Origin Shild 도 계층형 캐시 기능이라고 보면 거의 맞습니다. 이름에서 느껴지는 것처럼 원본 (=Origin Server) 입장에서 봤을 때 제한적인 IP 에서만 접근이 이루어진다는 보안 관점의 효과를 제외하면 2차 캐시라고 봐도 무방합니다. 

AWS CloudFront 가 제공하는 계층형 캐시

AWS 의 CloudFront 는 컴퓨팅 자원들과는 조금 다른 리전을 기반으로 합니다. Edge Location 이라고 불리우는 이 리전들은 CloudFront 엣지 서버들과 Route53 의 자원들을 중심으로 일부 제품 기능을 수행하는 서버들이 위치한 리전입니다. CloudFront 로 일컫어지는 AWS 의 CDN 제품을 생각해보면 사용자로부터 1-hop 거리에 있는 캐시 서버가 동작하고 있는 리전이기도 합니다. 

일반적으로 이러한 Child Cache 서버들은 댓수가 많기 때문에 상대적으로 캐시 효율이 떨어질 수 있습니다. 캐시의 기본은 요청을 집중시키는 것이기 때문에 넓은 지역에 퍼져 사용자들로부터 적은 지연을 확보하는 것과 반비례 관계에 있습니다. 이를 보완하기 위해 AWS 의 CloudFront 가 제공하는 것이 REC, Regional Edge Cache 로 불리우는 상위 캐시 레이어입니다. 

AWS 에서 종종 봤을 위의 그림을 보면 Edge Location, 즉 사용자 접점의 캐시가 배치된 리전은 가능한 넓은 지역에 퍼져 있는 것을 볼 수 있습니다. 반면 오렌지색 원으로 표현된 Regional Edge Cache, 즉 상위 레이어의 캐시 혹은 2차 캐시는 특정 지역 (=보통 컴퓨팅 리전과 일치합니다) 에만 배치되어 있는 것을 볼 수 있습니다. 

일반적으로 Edge Location 에 비하여 REC 의 서버들은 스토리지 공간이나 컴퓨팅 파워가 더 우수한 것으로 알려져 있습니다. 요청들이 원본 서버로 전달되기 전에 한번 거쳐가는 레이어이기 때문에 더 여유로운 장비를 배치하는 것이 당연합니다. 이처럼 계층형 캐시를 제공함으로써 CloudFront 는 1) 원본으로 전달되는 요청을 줄이고, 2) AWS 네트워크 내에서 가능한 트랜잭션을 처리함으로써 사용자 입장에서 더 좋은 컨텐츠 전송 지연 경험을 해주도록 설계가 되어 있습니다. 

Origin Shield 도 REC다!?

이러한 CloudFront 의 구성에서 Origin Shield 는 어떤 차이를 가지고 있는걸까요? 결론을 먼저 이야기하면 Origin Shiled 도 REC 의 일부입니다. REC 는 앞서 보신 그림에서 나타난 것처럼 Edge Location 보다는 Pop이 적지만 여전히 여러 곳에 퍼져 있습니다. 이들 중 원본 서버에서 가까운 혹은 선호하는 REC 리전을 지정해 줌으로써 1) 사용자는 자신에게서 가까운 Edge Location 으로 접근, 2) Edge Location 은 캐시 효율을 위해 REC 에 접근, 3) REC 는 (도메인에 따라) Origin Shield 역할로 지정된 REC 에 다시 한 번 접근함으로써 캐시 효율을 높이고 원본 서버에게 제한적인 대역에서의 접근을 보장할 수 있게 됩니다. 

결국 Origin Shield 도 REC 라는 것이 여기에서의 한줄 요약입니다. 당연히 캐시 효율은 높아질 수 있고 원본에서는 접근하는 대역을 제한 함으로써 보안적인 효용을 얻을 수 있게 됩니다. 사실 REC 는 사용자가 사용 유무를 제어할 수 없다는 것이 한계였고, 상황에 따라서는 (보통은 no-store 성격의 컨텐츠 전송시) Edge Location 이 REC 를 경유하지 않는 경우가 발생하곤 했습니다만 Origin Shield 를 이용할 경우 지정된 REC 를 언제든 경유한다는 장점이 생기게 됩니다.

비용 계산은 어떻게 될까?

그렇다면 비용 계산은 어떻게 되는 걸까요? AWS 를 사용하면 참 편리하고 좋은 것들이 많지만 늘 걱정되는게 비용이기 때문에 비용은 확실하게 확인하고 넘어갈 필요가 있습니다. Origin Shiled 는 기본적으로 REC 이기 때문에 기존의 REC 의 가격 정책과 마찬가지로 과금을 안하는 것이 기본입니다. 다만, REC 가 요청량, 전송량 모두에 대해 별도 과금이 없는 것과 달리 Origin Shield 경유시 요청량에 대한 과금이 발생합니다. (전송량 단위의 과금은 없습니다)

AWS 의 가격 테이블을 확인해보면 어떤 리전에 위치한 REC 를 사용하는가에 따라 위의 테이블에 나온 것과 같은 요청량 기반의 과금을 하게 됩니다. 테이블에 나와 있는 가격은 1만개의 요청당 요금이기 때문에 사용중인 도메인에서 발생하는 원본으로의 요청이 얼마나 되는가가 과금에 영향을 주게 됩니다. 

여기서 또 중요하게 봐야 할 비용 관련 부분은 Origin Shield 로 지정된 리전이 2차 캐시 레이어로 활용되었는가? 하는 부분입니다. 앞서 언급드린 것처럼 Origin Shield 리전도 REC 이기 때문에, Edge Location 이 직접 Origin Shield 로 지정된 리전을 접근한 경우는 증분 레이어 Incremental Layer 로 인정하지 않아 과금되지 않습니다. 다만 다른 REC 를 경유해서 Origin Shield 로 지정된 리전에 접근했을 경우만 증분 레이어로 보고, 요청량을 카운트하여 과금하게 됩니다 

위의 설명에 나온 것처럼 1) 동적인 컨텐츠, 2) 캐시 컨텐츠 유무에 따라 과금 요청량 카운트는 또 달라집니다. 동적인 컨텐츠는 캐시되지 않기 때문에 언제나 Origin Shield 를 경유해서 원본으로 전송됩니다. 이 요청들은 모두 과금 대상 요청이 됩니다. 반면 캐시 가능한 컨텐츠의 계산은 조금 다릅니다. <캐시 가능한 요청수 x (1-캐시히트율) x REC 에서 Origin Shield 를 통해 원본으로 전송된 비율 x Origin Shield 과금 기준> 계산을 통해 과금 대상 요청량을 산정하게 됩니다. 

언제 쓰는게 유리할까?

AWS 는 과금 정책이 늘 복잡합니다. 이번에 공개된 CloudFront 의 Origin Shield 역시 마찬가지입니다. 그렇지만 CDN 좀 써본 분이라면 아시겠습니다만 2차 캐시의 효과는 요청량이 어느정도 된다면 가성비가 훌륭한편에 속합니다. CloudFront 에서도 2차 캐시를 잘 활용하고 싶다면 Origin Shield 를 써야할 것 같은데, 과연 언제 쓰는게 유리한걸까요?

첫번째 케이스로 실제 비용 청구를 따져보긴 힘들겠지만, 사용자의 경험 관점에서 1) 원본 서버가 위치한 지역에 대다수의 사용자가 위치해있고, 2) 일부 해당 지역외 사용자들이 서비스를 종종 이용할 때가 비용을 적게 들이면서도 효과를 볼 수 있는 대표적인 사례가 될 것 같습니다. 1) 에 해당하는 사용자들은 대부분 Origin Shield 레이어를 증분 레이어로 쓰지 않을거라 비용 추가 부담이 적을 겁니다. 2)에 대당하는 사용자들은 약간의 비용 기여(?)를 하겠지만 REC - Origin 구간의 네트워크에서 발생하는 불확실성을 줄여준고 캐시 효율을 높이는 관점에서 사용에 대한 의미가 있을거라 생각합니다.

이런 대표적인 시나리오에서는 확실히 써주는 것이 좋을거라 봅니다만 그 외의 케이스들에서는 일부 트래픽의 적용 등을 통해 검증이 필요합니다. 아시겠지만 모든 케이스에 두루 적용되는 솔루션은 현실 세계에서는 거의 없기 때문이겠지요. 새롭게 런칭된 AWS CloudFront 의 Origin Shield 기능을 통해 사용자 경험을 향상시키는 계기를 만들어 보시기 바랍니다.

Facebook 에서 CDN 과 관련한 이야기를 나눌 그룹을 만들어 운영하고 있습니다. 여러 CDN 벤더의 엔지니어들이 참여하고 계시기 때문에 많은 인사이트와 흥미로운 지식들을 얻어가실 수 있습니다. 

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격 근무를 진행하고 있고 코로나 바이러스 초기에 각 VPN 회사들이 제공해 주었던 임시 라이센스 등을 잘 활용해 왔습니다. 

비용 지불 여력이 되면 유료 계약으로 라이센스를 추가하는 경우도 있겠지만, 소규모 사업장이나 여력이 되지 않는 곳에서는 다른 옵션을 찾아보는 것도 방법이 되겠습니다. 몇 개의 포스팅으로 나누어 소개할 OpenVPN 은 은근 손이 가긴 하지만 저렴하게 VPN 을 구축하는 방법이 될 수 있습니다.

AWS EC2 - OpenVPN 서버 구축 개요

본 포스팅은 OpenVPN 을 설치하여 사용하는 환경으로 IPv4 와 IPv6 를 모두 제공하는 것을 목표로 합니다. VPN 서버를 어디에 구축하느냐에 따라 달라지는 부분들이 있겠습니다만, 널리 사용되는 AWS 의 EC2 를 OpenVPN 서버로 활용하는 방법을 설명하도록 하겠습니다. 작업 순서는 아래와 같습니다.

1. AWS 환경 준비
   • IPv6 대역을 갖고 있는 신규 VPC 생성
   • VPC 내에 Public Subnet 생성
   • Gateway 구성 : Internet Gateway / Egress Only Gateway
   • Routing Table 조정
   • IPv6 주소를 갖는 EC2 배포
2. OpenVPN 설치 및 구성
3. VPN 접속 시험
4. 기타
   • 라우팅 조정

OpenVPN 을 IPv4 전용으로 사용하는 경우에는 절차가 조금 더 간단합니다. 하지만, 미래 지향적인 작업을 추구하는 동시에 AWS 환경에서 IPv6 를 어떻게 활성화 하는지 공부해 본다는 관점에서 단계를 따라해 주시면 좋겠습니다 ^^

1-1. IPv6 대역을 갖고 있는 신규 VPC 생성

AWS 콘솔에 접속후 VPC 를 먼저 생성하겠습니다. VPC 생성시 몇 가지 옵션 항목이 나오는데 <IPv6 CIDR Block> 의 두번째 옵션인 "Amazon provided IPv6 CIDR block" 을 선택합니다. 

IPv4 와 달리 IPv6 는 AWS 에서 자동으로 할당하는 대역을 이용하게 되며, 공인 IPv6 주소를 할당 받습니다. 이렇게 되는 이유는? 저도 조금 더 공부를 해보고 포스팅으로 정리해 보도록 하겠습니다. (요약 : 아직 잘 모르겠습니다) 

1-2. VPC 내에 Public Subnet 구성

VPC 가 생성되었으니 이번엔 Public Subnet 을 구성하도록 하겠습니다. 서비스에서 쓸 서버들이라면 역할에 맞게 Public, Private Subnet 을 구성해야하지만 OpenVPN 서버는 외부 접근이 필수인 서버이니 Public Subnet 만 구성하도록 하겠습니다.

Sunet 생성시 VPC 가 IPv6 를 활성화 해 둔 VPC 가 맞는지 확인하셔야 하구요, 가장 마지막에 있는 <IPv6 CIDR block> 을 "Custom IPv6" 로 선택하여 해당 Subnet 에 할당할 /64 블럭을 입력해 주어야 한다는 정도만 잘 챙기시면 됩니다. 제 경우에는 00 으로 지정을 했습니다.

Subnet 이 생성되었으면 Subnet 의 속성을 조정해 주어야 합니다. IPv6 를 지원해야 하기 때문에 Subnet 에 생성되는 자원에 IPv6 주소를 자동으로 할당하도록 해보겠습니다. 네, 유심히 보셨다면 아시겠지만 "Public" 이라는 단어가 나오지 않습니다. IPv6 주소 체계는 IPv4 와 묘하게 다른 점들이 있는데, 조금 더 공부하고 포스팅으로...

자동 할당 정책들 중 가장 마지막에 있는 <Auto-assign IPv6> 의 체크박스를 체크해 줍니다. 이후 해당 Subnet 에 자원이 생성되면 IPv6 주소를 자동으로 할당 받게 되고, Network ACL, Security Group 에 문제가 없다면 할당된 주소로 Public 에서 접근할 수 있게 됩니다. 

여기까지 문제 없으셨나요? 다음 포스팅에서는 인터넷 구간으로의 통신을 위해 필요한 두가지 Gateway 설정을 해보도록 하겠습니다. 하나는 쉘 접근을 위한 Internet Gateway 이고, 다른 하나는 IPv6 터널링시 외부로의 통신에 필요한 Egress Only Internet Gateway 입니다. 왜 두개를 따로 써야 하는지는 다음 포스팅! 에서 말씀 드리겠습니다.

2020.12.25 - 다음 포스팅이 올라왔습니다. 아래의 링크로 고고!

Stay tuned..!

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 

IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 

AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

본 포스팅은 소정의 수수료를 받을 수 있습니다.