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에서 완전히 제외되며 인스턴스를 종료시킨다. ...
원격 서버에 ssh로 접속한 후 실행시간이 긴 명령어를 수행중에 ssh 연결을 끊거나 네트워크 오류로 인해 연결이 끊어지게되면 실행중이던 명령어도 같이 종료되어버린다. ssh를 통해 실행된 shell에서 실행한 프로세스는 shell의 child 프로세스로 연결되어있기 때문에 이런 현상이 발생하는데, 이를 방지하려면 child 프로세스를 parent에서 detach하여 독립된 프로세스로 만들면 된다. 이를 위해 해당 명령어를 nohup 등의 명령어를 이용할 수도 있지만 tmux 명령을 사용하면 가장 손쉽게 해결 할 수 있다. 설치 Ubuntu에서는 다음 명령어로 설치가 가능하고, 다른 계열의 OS에서는 해당 OS에맞는 패키지 매니저를 사용하면 된다. ...
카프카 Consumer를 사용하다 보면 offset을 reset해야하는 경우가 종종 있다. 개발 테스트를 진행하다가 필요에의해 offset을 리셋 실제 production에서 사용중에 예상치 못한 에러 등으로 데이터 누락이 발생하여 일정기간 전으로 다시 offset을 rewind해서 사용하고자 하는 경우 이런 경우에 Consumer API를 사용중이라면 직접 코드 레벨에서 programmatic하게 reset도 가능하고, 아니면 kafka에서 제공하는 reset tool을 이용해서 reset이 가능하다. 카프카 바이너리 설치 카프카 바이너리를 설치한다. Mac에서 brew가 있다면 아래 명령어로 간단히 설치 할 수 있다. (Mac을 기준으로 설명 한다.) ...
RDBMS만큼의 정합성과 영속성을 보장할 필요가 없는 데이터들을 빠르게 처리하거나 일정 기간동안만 보관하고 있기 위한 용도로 레디스(Redis), memcached 등의 in-memory 기반 저장소가 많이 사용된다. 그중에서도 Redis는 빠른 성능을 유지하면서도 일정 수준 이상의 persistence를 제공하고, 다양한 native 데이터 구조들을 제공하여 효율적이고 편리한 사용이 가능하게 해주기 때문에 다양한 use-case들이 존재한다. 이 글은 실제 명령어를 날려서 레디스를 직접 사용해보는 것을 배우기 보다는 어떤 in-memory 저장소를 선택할지 고민하는 분들을 위해서 주요 운영 방식, 레디스의 내부 동작 방식 및 특징, 주요 클라이언트들에 대한 정보를 제공하는 쪽에 초점이 맞춰져 있다. ...
“클라우드플레어(Cloudflare)를 적용만 하면 당신의 사이트의 속도를 빠르게 할 수 있다” 라는 클라우드플레어 광고 문구를 보고 도대체 클라우드플레어가 중간에서 어떤일을 하는지 궁금해서 조금 자세히 찾아보았다. 사이트 접속시에 어떤 일이 일어날까? 사용자가 http://example.com 주소를 입력했을때 일반적으로는 DNS에 example.com을 조회하면 그에 해당하는 서버의 IP주소를 알려주고, 해당 IP주소로 실제 HTTP요청이 일어난다. 하지만 클라우드플레어(Cloudflare)를 사용하게되면 모든 요청이 클라우드플레어 서버를 먼저 한번 거친 후, 필요한 경우에만 실제 서버의 IP주소까지 요청이 도달한다. 일반적인 접근: DNS -> Server IP 클라우드플레어 설정 후: DNS -> Cloudflare Server(CDN) -> Your IP (Origin) ...