배치 개선 기록 2

이번에는 구체적으로 배치를 어떻게 개선했는지 정리해보겠습니다. 크게 불필요한 작업을 없애거나 순서를 변경하는 것으로 프로세스를 개선한 건과 작업 병렬화를 통해 처리 시간을 줄인 개선 건이 있습니다. 작업 프로세스 개선 여러 Case가 있었지만, 대표적 2가지만 적어보고자 합니다. Case 1 : 기존에는 단순히 Mart라는 이유로 같이 묶어서 병렬로 처리하였는데, 그 마트들을 데이터의 선,후행 관계를 분석하여 데일리 마트, 빌링…

Continue reading 배치 개선 기록 2

배치 개선 기록 1

처음 보는 서비스를 개선하라는 업무가 나에게 주어졌을 때 무엇부터 해야할까요?구체적인 내용은 별도 포스트로 다루고, 제가 실제로 진행 했던 순서대로 간단히 기록해보려고 합니다. 상황 파악 어느날 갑자기 빌링 정보를 처리하는 배치의 성능 개선을 맡게 되었습니다. 대략적으로 파악해보니, 기존의 Spring으로 구현되어 있던 것을 배치 작업에 적합한 Spring Batch로 마이그레이션하였으나 성능이 예상보다 떨어지는 상황임을 파악하였습니다. 기술부채 갚아나가기 구현된…

Continue reading 배치 개선 기록 1

AWS ElastiCache Redis Troubleshooting

이번에는 ElastiCache Redis를 운영하면서 발생했던 이슈와 해결했던 경험들을 공유해보려고 합니다. ElastiCache Clustered Redis 다중 키 작업 문제 클러스터로 구성하면서 다중 키를 작업하면 아래와 같은 에러가 발생할 수 있습니다. 해당 에러는 다중 키 작업시 키가 동일한 해시 슬롯에 있지 않아서 발생하는 문제입니다. 해결 방법은 2가지가 있습니다. 첫번째 방법은 Redis 클러스터를 지원하는 Redis 클라이언트 라이브러리를 사용하는 것입니다.…

Continue reading AWS ElastiCache Redis Troubleshooting

AWS ElastiCache Redis 구성 팁

ElastiCache Redis을 실제로 사용했을 때, 유용하게 사용할 법한 팁들을 공유해보려고 합니다. ElastiCache Redis Cluster Automatic Failover 복제본 개수가 1개 이상일 경우 다중 AZ를 꼭 활성화해서 생성해야 장애시 자동 장애조치를 수행할 수 있습니다. 실제로 자동장애조치가 잘 동작하는지 보고 싶으면, ElastiCache Redis 노드 관리 화면에서 작업-기본 장애 조치를 수행하여 볼 수 있습니다. Optional Cache 캐시 기능을 ON/OFF…

Continue reading AWS ElastiCache Redis 구성 팁

AWS ElastiCache 캐싱 전략

대표적인 캐싱 전략 ElastiCache를 이용해서 캐싱하는 전략에는 대표적으로 2가지가 있습니다. Lazy loading Write-through Lazy loading은 말 그대로 지연 로딩으로, 데이터 요청이 있을 때만 캐싱됩니다. 즉, 최소 1번은 데이터를 조회해야만 캐싱이 되고, 최초 조회시 DB에 직접 요청하므로 느리다는 점이 단점입니다. 반면에, 데이터가 갱신되었을 때 기존에 캐싱된 데이터만 무효화 시키면 되는 점은 장점입니다. Write-through 방식은 데이터 갱신시…

Continue reading AWS ElastiCache 캐싱 전략

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 적용하기

Terraform 시작하기

인프라 관리를 시작하고 처음 든 생각은 이것이었습니다. 왜 배포 환경 (이하 스테이지)마다 인프라 형상이 다른가? 같은 형상으로 배포하는 것은 정말로 어려운 일인가? 원인은 크게 두 가지라고 생각합니다. 첫째는 인프라 구축을 담당하는 팀이 따로 있었는데, 능동적으로 서비스 개발에 참여하는 것이 아니라서 인프라를 잘 모르는 개발팀의 요건을 그대로 수용하였던 것입니다. 둘째는 이러한 상황에서 개별 이슈 처리를 위해…

Continue reading Terraform 시작하기

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 소개