AWS와 같은 클라우드 서비스를 웹 콘솔만 이용하여 사용하다보면 각 리소스의 상세 설정이 어떻게 되어있는지, 리소스들간의 관계는 어떻게 되어있는지 한눈에 파악하기가 어렵다. 특히 해당 리소스에 대해 권한을 갖고있는 여러명이 공동 작업을 하는 경우 내가 아닌 다른 사람이 어떤 설정 변경을 했는지 히스토리를 추적하는것이 불가능하다. 이때 테라폼(Terraform)이나 풀루미(Pulumi) 등의 IaC(IaC, Infrastructure as Code) 플랫폼들을 이용해서 리소스를 코드로 표현하여 관리하면 이러한 문제를 해결하는 것이 가능하다. 클라우드 리소스를 코드 형태로 관리할 수 있게 되면 다음과 같은 이점들이 생긴다. ...
AWS S3 + 클라우드플레어를 사용하면 사용자와 클라우드플레어 CDN간의 대역폭 비용은 무료이지만 여전히 S3에서 클라우드플레어로 전송되는 대역폭에 대한 비용을 지불해야합니다. 즉, 클라우드플레어 CDN에서 캐시 미스(cache miss)가 많이 발생해서 오리진까지 요청이 많이 가면 오리진까지 도달한 해당 요청/응답에 사용된 대역폭 비용을 AWS에 지불해야 한다는 뜻 입니다. 반대로 말해 클라우드플레어에서 캐시 히트(cahce hit)가 되는 경우에는 S3까지 요청이 도달하지 않으니 S3 비용도 발생하지 않습니다. 클라우드플레어 CDN에서 100% 캐시 히트가 될 수는 없으니 일부 요청은 오리진으로 도달할 것이고 이 요청이 많아질 수록 비용이 발생하게 되는데, 이러한 비용을 내지 않기 위해서 S3를 대체할만한 서비스들 중 클라우드플레어와 Bandwidth Alliance 로 맺어진 회사의 서비스를 사용하면 됩니다. 여기서는 대표적으로 Backblaze라는 서비스를 검토해 보겠습니다. ...
이 글은 스퀘어랩 기술 블로그에도 동일하게 업로드되어있습니다. https://squarelab.co/blog/update-nginx-ingress-controller/ AWS 상에서 쿠버네티스(k8s) 클러스터를 운영할때 NLB(Network Load Balancer)와 nginx ingress controller 를 조합해서 사용하면 매우 편리합니다. 일단 k8s 클러스터로 들어가는 모든 트래픽을 원하는 하나의 네트워크 로드밸런서로 몰아서 사용이 가능하기 때문에 로드밸런서 비용을 절약 가능하고, 여기에 추가로 nginx에서 제공하는 다양한 기능을 모두 사용할 수 있는 장점이 있습니다. 이렇게 사용하다보면 외부에서 클러스터 내부로 들어오는 대부분의 트래픽이 nginx ingress controller 를 통해서 들어올 것이기 때문에 nginx ingress 관련 설정을 변경하거나, 버전을 올리거나 할 때의 작은 실수가 클러스터 내에서 실행중인 모든 서비스에 대한 장애로 이어질 수 있기 때문에 항상 주의해야합니다. ...
AWS의 Application Load Balancer(LB)를 통해 실제 서버가 연결되어있을 때 서버가 죽어서 응답을 해주지 않으면 LB에서 대신 502 Gateway Error로 응답을 해준다. 이때 502 HTTP status code와 함께 LB의 디폴트 에러페이지가 응답으로 나가게된다. 개발을 하다보니 이 디폴트 에러를 보여주는 대신 customize 한 응답을 내려줘야 할 필요가 생겨서 리서치를 해보았으나, 안타깝게도 설정이 불가능 하다는 것을 확인했다. LB에서 request URL path에 따라서 리디렉션이나 포워딩 또는 정해진 스태틱 응답을 내보내는 것은 설정 가능하지만, 특정 에러코드에 대해서 에러 응답 내용을 변경하는 것은 불가능하다. ...
https://github.com/colinbjohnson/aws-missing-tools/tree/master/ec2-automate-backup 위 스크립트를 이용하여 다음과 같은 명령어를 cron이나 jenkins job으로 등록하여 매일 한번씩 호출되게 해준다. ec2-automate-backup.sh -n -p -r ${region} -v ${ebs_volume_id} -k ${delete_after_days} -n 스냅샷 백업시에 태그에 있는 내용들을 name 필드에도 설정 -p 스냅샷에 태깅된 시간보다 현재시간이 더 큰경우 스냅샷 삭제(purge) -r 지역 설정 (ex: ap-northeast-1) -v 백업하려는 EBS volume ID (ex: vol-00cb123456789) EC2 콘솔에서 확인 가능 -k 스냅샷 생성시 며칠 후 까지 보관하면될지 시간을 태깅 (ex: 7, 7일) 예를 들어, 아래와같은 스크립트를 매일 한번 실행하면, ap-northeast-1에 있는 vol-00cb123456789 스토리지에 대한 스냅샷을 매일만들면서, 7일 이상 된 스냅샷은 자동으로 삭제해 준다. ...
AWS에서 Elastic Beanstalk나 EC2에서 직접 오토스케일링 설정해서 사용하다보면 트래픽이 늘었을 때 인스턴스의 갯수가 늘어났다가(scale out) 트래픽이 줄어들면 불필요해진 자동으로 인스턴스를 shutdown하게 된다(scale in). 이때 shutdown 될 인스턴스에 연결되어서 진행중인 요청(in-flight request)이 있다면 어떻게 될까? 먼저 해당 인스턴스로 새롭게 추가 요청이 가지 않도록 연결된 로드밸런서(Load Balancer, LB)에서 shutdown 될 등록 해제 프로세스(Deregistration process)를 시작한다. 이때 LB에서 인스턴스로의 연결이 열려있는것이 있다면 설정된 시간동안 연결이 자연스럽게 종료 되도록 기다려준다. (이를 connection draining 또는 deregistration delay라고 부른다.) 이 시간을 초과하면 열려있는 연결이 있더라도 강제로 종료한 후 LB에서 완전히 제외되며 인스턴스를 종료시킨다. ...