최근에 Jenkins 서버의 용량이 가득 차면서 함께 올라가있던 다른 서비스들도 멈춰버리는 문제점이 발견되었습니다. 그래서 그 중 하나인 Nexus를 분리하고 Blob Store를 Local Storage가 아닌 S3로 설정하여 비용 절감을 꾀하기로 합니다. 기왕 이렇게 하기로 결정하였으니, ECS에 서비스 형태로 올려보고자 합니다. EFS 설정하기 ECS의 Fargate는 EBS를 지원하지 않습니다. 대신에 조금 더 비싼 요금을 자랑하는 EFS를 볼륨으로 제공합니다.…
EC2를 이용하여 서비스의 크기를 조절하기 위해서는 충분한 시간이 필요했습니다. Auto Scaling 기능의 매력은 충분하나, 급변하는 트래픽이나 사용량에 대해서 민첩하게 대응하기는 어렵습니다. 아무래도 OS부터 부팅되고 서비스가 올라가려면 5분 정도의 시간이 필요한데 그때쯤에는 급격한 트래픽이 다시 돌아오기에 충분하죠. 컨테이너 이미지의 장점은 이러한 상황에서도 빠르게 대응하는 것이 가능하다는 점일 것입니다. 준비된 OS 레이어 위에서 서비스만 배포되면 되기 때문에…
인프라 관리를 시작하고 처음 든 생각은 이것이었습니다. 왜 배포 환경 (이하 스테이지)마다 인프라 형상이 다른가? 같은 형상으로 배포하는 것은 정말로 어려운 일인가? 원인은 크게 두 가지라고 생각합니다. 첫째는 인프라 구축을 담당하는 팀이 따로 있었는데, 능동적으로 서비스 개발에 참여하는 것이 아니라서 인프라를 잘 모르는 개발팀의 요건을 그대로 수용하였던 것입니다. 둘째는 이러한 상황에서 개별 이슈 처리를 위해…
제가 OpsNow의 레거시 환경을 개선하기 위해서 가장 처음 도입하고자 마음먹은 것은 어쩌면 당연하게도 개별 서비스를 컨테이너로 만드는 것입니다. 그리고 이렇게 생성된 컨테이너 이미지를 ECS에서 Fargate에 배포함으로써 Serverless 서비스를 만들고자 하였습니다. 많은 시간과 노력을 들인 끝에, 코드에서부터 서비스 배포까지 이어지는 CI/CD 파이프라인을 구축할 수 있었습니다. 이번 글을 통해서 어떻게 OpsNow의 레거시 서비스가 Serverless로 나아갈 수 있었는지…
ECS에서 Fargate로 서비스를 생성하고 로드 밸런서에 연결하게 되면, 추후 서비스 배포를 위해서는 반드시 CodeDeploy를 이용해야 합니다. 그리고 블루/그린 배포는 선택이 아닌 필수가 됩니다. 그리고 의외로, 이러한 설정 과정은 결코 쉽지가 않습니다. ECS의 구성으로 EC2를 선택하면 Rolling Update 같은 방식을 제공하지만, Fargate는 그렇지가 않았기 때문입니다. 그렇다고 배치성 작업이라 할지라도 호출이 필요한 서비스를 로드 밸런서에 연결하지 않을…
OpsNow가 처음 개발이 시작될 때부터 지금까지 대다수의 서비스는 EC2에 올라가 있습니다. 초창기에는 AWS 인프라로부터의 독립성을 보장받고 싶었고 그에 따라서 대부분의 기능을 EC2에 올려서 단순 VM처럼 이용했기 때문입니다. 시간이 지남에 따라서 비용 절감과 유지보수를 최소화하기 위한 노력이 시도되었는데, 이를 위해서는 AWS의 다양한 관리형 서비스를 이용하는 것이 훨씬 유리하다는 사실을 알게 되었습니다. 관리형 서비스는 개발자가 정말로 서비스…
AWS에서는 EC2에 대해서 정말 많은 기능을 제공하고 있지만, 특이하게도 스케쥴링 기능을 네이티브로 제공하고 있지 않습니다. 필요하면 알아서 만들어서 사용하라고 가이드는 하고 있습니다. (관련 문서) 이러나 저러나, 사용자가 직접 만들어야 한다면 역시 태그를 기반으로 하는 스케쥴러가 가장 좋은 방법일 것입니다. 그래서 본 글에서는 OpsNow의 개발계에서 사용하는 EC2 스케쥴링 방법과 그 사용 방법을 소개하고자 합니다. Lambda 함수…
얼마 전에 갑자기 비용이 소폭 상승하여 그 원인을 찾고자 다양한 메트릭을 확인하게 되었습니다. 이번 글에서는 그 과정을 기록 차원에서 남겨보고자 합니다. 이상 비용 AWS 조직 계정에서 비용을 살펴보던 도중에 최근 비용이 증가하는 것을 발견하였습니다. 비용 절감 차원에서 다양한 시도를 하고 있는데 비용이 증가할 리는 없으니 무언가 잘못되었다는 신호가 분명합니다. 여러 차원으로 살펴본 결과, 두 가지…
이번에 도메인 관리 계정 B를 새로 AWS Organization에 멤버 계정으로 포함시키면서 다른 계정 A에 있던 도메인들을 이전하게 되었습니다. 해당 작업은 콘솔 상에서 할 수 없는 작업이라서 CLI 작업을 통해야만 합니다. 별로 어려운 작업은 아니지만, 그 과정을 공유하고자 합니다. 도메인 이전 요청 먼저 A 계정에서 도메인을 B로 이전하겠다고 요청을 해야합니다. 예시 도메인인 example.com을 통해서 명령어를 살펴보도록…
기존에 OpsNow에서는 GoDaddy를 통해서 도메인을 구매하고 DNS를 관리하였습니다. 물론 GoDaddy도 훌륭한 서비스입니다만, AWS 위에서 서비스를 개발하고 도메인을 연결하려면 무조건 Route 53을 쓰는 것이 유리합니다. 그 이유는 다음과 같습니다. AWS 리소스 엔드포인트를 A Record로 지정 가능 단순 라우팅 외의 다양한 라우팅 정책 사용 가능 조금 더 훌륭한 UI 그래서 DNS 관리 주체를 GoDaddy에서 Route 53으로 변경하기…
