ECS로 Nexus 구축하기

최근에 Jenkins 서버의 용량이 가득 차면서 함께 올라가있던 다른 서비스들도 멈춰버리는 문제점이 발견되었습니다. 그래서 그 중 하나인 Nexus를 분리하고 Blob Store를 Local Storage가 아닌 S3로 설정하여 비용 절감을 꾀하기로 합니다. 기왕 이렇게 하기로 결정하였으니, ECS에 서비스 형태로 올려보고자 합니다. EFS 설정하기 ECS의 Fargate는 EBS를 지원하지 않습니다. 대신에 조금 더 비싼 요금을 자랑하는 EFS를 볼륨으로 제공합니다.…

Continue reading ECS로 Nexus 구축하기

ECS 서비스에 Auto Scaling 적용하기

EC2를 이용하여 서비스의 크기를 조절하기 위해서는 충분한 시간이 필요했습니다. Auto Scaling 기능의 매력은 충분하나, 급변하는 트래픽이나 사용량에 대해서 민첩하게 대응하기는 어렵습니다. 아무래도 OS부터 부팅되고 서비스가 올라가려면 5분 정도의 시간이 필요한데 그때쯤에는 급격한 트래픽이 다시 돌아오기에 충분하죠. 컨테이너 이미지의 장점은 이러한 상황에서도 빠르게 대응하는 것이 가능하다는 점일 것입니다. 준비된 OS 레이어 위에서 서비스만 배포되면 되기 때문에…

Continue reading ECS 서비스에 Auto Scaling 적용하기

ECS 서비스 배포 파이프라인 구축하기

제가 OpsNow의 레거시 환경을 개선하기 위해서 가장 처음 도입하고자 마음먹은 것은 어쩌면 당연하게도 개별 서비스를 컨테이너로 만드는 것입니다. 그리고 이렇게 생성된 컨테이너 이미지를 ECS에서 Fargate에 배포함으로써 Serverless 서비스를 만들고자 하였습니다. 많은 시간과 노력을 들인 끝에, 코드에서부터 서비스 배포까지 이어지는 CI/CD 파이프라인을 구축할 수 있었습니다. 이번 글을 통해서 어떻게 OpsNow의 레거시 서비스가 Serverless로 나아갈 수 있었는지…

Continue reading ECS 서비스 배포 파이프라인 구축하기

ECS의 Service Discovery 소개

ECS에서 Fargate로 서비스를 생성하고 로드 밸런서에 연결하게 되면, 추후 서비스 배포를 위해서는 반드시 CodeDeploy를 이용해야 합니다. 그리고 블루/그린 배포는 선택이 아닌 필수가 됩니다. 그리고 의외로, 이러한 설정 과정은 결코 쉽지가 않습니다. ECS의 구성으로 EC2를 선택하면 Rolling Update 같은 방식을 제공하지만, Fargate는 그렇지가 않았기 때문입니다. 그렇다고 배치성 작업이라 할지라도 호출이 필요한 서비스를 로드 밸런서에 연결하지 않을…

Continue reading ECS의 Service Discovery 소개

EC2에서 EKS가 아닌 ECS로 전환한 이유

OpsNow가 처음 개발이 시작될 때부터 지금까지 대다수의 서비스는 EC2에 올라가 있습니다. 초창기에는 AWS 인프라로부터의 독립성을 보장받고 싶었고 그에 따라서 대부분의 기능을 EC2에 올려서 단순 VM처럼 이용했기 때문입니다. 시간이 지남에 따라서 비용 절감과 유지보수를 최소화하기 위한 노력이 시도되었는데, 이를 위해서는 AWS의 다양한 관리형 서비스를 이용하는 것이 훨씬 유리하다는 사실을 알게 되었습니다. 관리형 서비스는 개발자가 정말로 서비스…

Continue reading EC2에서 EKS가 아닌 ECS로 전환한 이유

AWS에서 워드프레스 블로그에 CDN 구축하기

앞에서 이미 워드프레스 블로그를 구축하였는데, 굳이 S3와 CloudFront를 이용해야 하는 이유가 무엇일까요? S3를 사용하는 이유는 블로그에 업로드하는 모든 컨텐츠를 분리 보관하여 추후 재해 복구 상황을 대비하기 위함과 동시에 정적 콘텐츠를 제공하는 것에 대한 리소스 부담을 덜어내기 위함입니다. CloudFront를 사용하는 이유는 이러한 정적 콘텐츠를 CDN으로 서비스하여 보다 빠르게 콘텐츠를 전달하고 CFRC (CloudFront Reserved Capacity)를 이용하여 비용을…

Continue reading AWS에서 워드프레스 블로그에 CDN 구축하기