Home 헬스체크 유예 기간으로 겪은 배포 이슈
Post
Cancel

헬스체크 유예 기간으로 겪은 배포 이슈

1. 글을 작성하게 된 계기


프로젝트 배포 과정에서 겪은 내용을 정리하기 위해 글을 작성하게 되었습니다.




2. Health Check Grace Period


Health Check Grace Period 은 Auto Scaling이 인스턴스를 InService 상태로 전환한 후, 헬스 체크를 하기 전 기다리는 시간 입니다. 이는 인스턴스가 완전히 시작되고 모든 서비스가 정상적으로 작동할 수 있도록 시간을 주기 위해 사용됩니다.

When you create the Auto Scaling group, enter the amount of time (in seconds) on the Configure advanced options page, Health checks, Health check grace period. This is how long Amazon EC2 Auto Scaling must wait before checking the health status of an instance after it enters the InService state.





즉, 인스턴스가 완전히 생성된 후, 유예 기간 동안은 인스턴스가 비정상 상태로 감지되더라도 이를 반영하지 않으며, 유예 기간이 끝난 후에야 정상적으로 헬스 체크를 수행합니다. 이는 기본적으로 5분 입니다.

  1. 인스턴스 생성 및 초기화
  2. InService 상태 전환
  3. 유예 기간 시작
  4. 유예 기간 종료 후 헬스 체크 시작







3. 이슈


개념이나 설정 자체는 정말 간단한데요, 테라폼을 쓰면서 조금 골치가 아파졌습니다. 테라폼을 apply 하면 아래와 같이 자원들이 프로비저닝 하는데, 자원이 많으면 이 시간이 꽤 깁니다. 사이드 프로젝트라 얼마나 오래 걸리겠나 했는데, 5분을 훌쩍 넘더라고요.

1
2
3
4
5
6
7
8
9
10
11
12
13
$ terraform apply
module.ecr.aws_ecr_repository.dailyge_api_dev: Refreshing state... [id=dailyge-api-dev]
module.vpc.aws_eip.dailyge_eip: Refreshing state... [id=eipalloc-0e0c5bbf98da62580]
module.ecr.aws_ecr_repository.dailyge_api_prod: Refreshing state... [id=dailyge-api-prod]
module.cloudfront.aws_cloudfront_origin_request_policy.dailyge_cloudfront_origin_request_policy: Refreshing state... [id=88cf0682-be20-414a-9e30-90630efe9885]
module.vpc.aws_vpc.dailyge_vpc: Refreshing state... [id=vpc-06fba03e9764604b0]
module.cloudfront.aws_cloudfront_cache_policy.dailyge_cloudfront_cache_policy: Refreshing state... [id=fbb8c004-aefc-42c0-9faa-cf162f6b003b]
module.s3.aws_s3_bucket.dailyge_client_bucket: Refreshing state... [id=dailyge-client]
module.ecr.aws_ecr_lifecycle_policy.dailyge_prod_ecr_lifecycle_policy: Refreshing state... [id=dailyge-api-prod]
module.ecr.aws_ecr_lifecycle_policy.dailyge_dev_ecr_lifecycle_policy: Refreshing state... [id=dailyge-api-dev]

......





문제는 프로비저닝 하는데 5분이 넘어가면, 이 유예기간이 끝나버리는 것이죠. 자원이 생성된 후 5분이 지나니, 헬스 체크가 자동으로 실패하고, 헬스 체크가 실패하니 ECS로 배포가 되지 않았습니다. 반나절을 이 문제로 보냈는데, 마지막에 이를 깨닫고 처리할 수 있었습니다.

  1. 프로비저닝 시간이 5분 초과
  2. 자동으로 헬스 체크 실패
  3. 헬스 체크가 되지 않으니, 배포 진행 불가





물론 우회해서 해결할 수도 있는데, Bastion 인스턴스 또는 EC2 Instance Connect Endpoint를 통해 private subnet에 있는 인스턴스에 접속한 후, 해당 프로그램을 실행하는 것입니다. 서버가 많아지면 사용하기 힘든 방법이지만, 알아두는 것은 나쁘지 않겠죠?

A bastion host is a special-purpose computer on a network specifically designed and configured to withstand attacks, so named by analogy to the bastion, a military fortification.







4. 정리


사실 별 내용은 없는데요, 오랜만에 정말 고생했던 문제라 잊지 않기 위해 포스팅 했습니다. CICD를 구축할 때, 이 유예기간을 넉넉하게 잡아서 고생하지 않았으면 합니다.


This post is licensed under CC BY 4.0 by the author.

IAC 도입과 사용하며 느낀점

프로젝트를 잘 관리하려면 어떻게 해야할까?