OCI 용량 조회가 AVAILABLE이어도 생성은 실패할 수 있다

Об этом предложении

10월 2일 20시 44분의 운영 기록에는 용량 보고서 6,979회가 쌓여 있었다. 그런데 새 인스턴스는 없었다. 숫자만 보면 생성 요청을 수천 번 보낸 것처럼 보이지만, 이번에 추가한 것은 생성 시도 전에 용량을 확인하는 별도의 경로 다. 지난 글 에서는 결과를 모르는 요청의 기록을 언제, 어떤 근거로 정리할지 다뤘다. 이번에는 그 이후인 9월 27일 밤에 적용한 용량 감시 기능을 정리한다. 핵심은 재시도 간격을 무조건 줄이는 것이 아니라, 새 요청을 골라도 되는 상태와 기존 요청을 이어가야 하는 상태를 분리하는 것 이었다. 이 글은 OCI A1 재시도기의 구현과 운영 기록에 관한 글이다. 서버 확보 성공 후기가 아니다. AVAILABLE 이후의 성공·경쟁·타임아웃 분기는 모의 응답으로 검증했고, 실제 운영 관찰과 구분해서 적었다. 이번 변경을 한눈에 보기 상황 이번 구현의 판단 미확정 요청이 없음 용량 보고서를 조회해 새 후보를 고른다 요청한 후보가 모두 용량 부족 생성하지 않고 다음 조회를 예약한다 유효한 보고서에 AVAILABLE 후보가 있음 선택한 사양으로 사전 점검한 뒤 생성 요청을 보낸다 이전 요청의 결과가 불명확함 새 후보를 고르지 않고 원래 요청을 이어간다 보고서의 범위나 내용이 예상과 다름 생성으로 우회하지 않고 중단한다 설명용 흐름도다. 실제 실행 루프는 기존 인스턴스·완료 기록 확인과 저장된 다음 예약 처리를 먼저 수행한다. 용량 보고서는 예약권이 아니다 기존 방식은 정해진 사양으로 생성 요청을 보내고, 용량 부족 응답을 받으면 다시 기다리는 구조였다. 변경 후에는 미확정 요청이 없는 동안 A1 1 OCPU의 메모리 6GB·2GB·1GB 후보를 보고서 하나에 담아 조회한다. 유효한 AVAILABLE 후보 중 메모리가 가장 큰 것을 선택한다. 여기서 보고서의 역할을 좁게 정의했다. Oracle은 용량 보고서를 인스턴스 생성이나 사양 변경 전에 호스트 용량을 확인하는 수단 으로 설명한다. 조회의 compartment_id 에는 루트 구획을 사용하도록 명시되어 있다. 공식 용량 보고서 문서 용량을 미리 확보하는 Capacity Reservation은 별도의 기능이다. 이번 구현은 그 기능을 사용하지 않는다. 따라서 보고서를 받은 뒤 실제 생성 요청이 처리되기까지 용량이 달라질 수 있다고 보고 설계했다. AVAILABLE 은 다음 검사를 진행할 신호이지, 생성 성공이나 내 몫의 자원 확보를 뜻하지 않는다. 공식 용량 예약 문서 내 코드의 경쟁 상황 테스트도 이 전제를 따른다. 보고서는 AVAILABLE 을 반환하지만 생성 API는 Out of host capacity 를 반환하게 만든다. 기대 결과는 성공 처리나 연속 생성이 아니라, 미확정 기록이 남지 않은 명확한 용량 부족 실패를 기록하고 다음 용량 조회로 돌아가는 것이다. 후보 선택보다 먼저 응답을 검증한다 처음 떠올리기 쉬운 코드는 AVAILABLE 인 항목 하나를 찾는 것이다. 하지만 잘못된 AD(가용성 영역)의 응답이나 후보가 빠진 응답에서 하나만 골라도 되는지는 별개의 문제다. 실제 구현에서는 다음을 확인한 뒤에만 후보를 선택한다. 응답의 테넌시와 AD가 요청 범위와 일치하는가 shape와 OCPU가 요청한 값인가 메모리 크기가 허용 후보에 속하고, 중복 항목이 없는가 요청한 후보가 모두 응답에 존재하는가 상태 값이 알고 있는 값인가 이번 요청은 fault domain을 지정하지 않는다. 응답의 fault domain도 None 인지 확인하도록 좁게 구현했다. 공식 문서는 fault domain을 생략하면 모든 fault domain에 대한 정보를 포함한다고 설명한다. 이 검사는 현재 클라이언트가 받아들이는 응답 형태 이지, 어떤 형태의 응답에도 동작하는 범용 파서는 아니다. 공식 응답 모델 문서 상태 값도 낙관적으로 해석하지 않는다. UNKNOWN_ENUM_VALUE 나 후보 누락이 있으면 다른 항목이 AVAILABLE 이어도 중단한다. HARDWARE_NOT_SUPPORTED 는 일시적인 용량 부족과 다르게 취급하고, 요청한 후보가 모두 미지원이면 계속 기다리지 않는다. 반대로 available_count 가 없다는 이유만으로 가용성을 0으로 바꾸지는 않았다. 이 구현의 후보 선택은 검증된 availability_status 를 기준으로 한다. available_count=None 이면서 AVAILABLE 인 모의 응답도 테스트했다. 실제 운영에서 AVAILABLE을 관측했다는 뜻은 아니다. 권한도 따로 확인해야 했다. 이름은 조회지만 API는 CreateComputeCapacityReport 이고, 정책 표에는 manage compute-capacity-reports 의 COMPUTE_CAPACITY_REPORT_CREATE 권한이 연결되어 있다. read 라는 단어만 보고 충분하다고 가정하면 안 된다. 권한 실패 때 생성 요청으로 우회하지 않는 테스트도 추가했다. 공식 IAM 권한 표 AVAILABLE 뒤에도 사전 점검을 다시 한다 보고서는 호스트 용량에 관한 신호다. 내 작업이 이미 인스턴스를 만들었는지, 현재 사용량이 도구에 설정한 상한을 넘는지, 네트워크와 이미지가 여전히 유효한지까지 대신 판단해 주지는 않는다. 그래서 빈 용량을 기다릴 때는 보고서 API를 사용하되, 후보가 나오면 선택한 메모리 크기로 사전 점검을 다시 수행 한다. 다음은 watched_cycle() 에서 해당 부분을 발췌한 코드다. 앞선 초기화·미확정 요청 분기는 생략했으며 독립 실행 예제는 아니다. selected = self.capacity_selection(self._watch_ads) if selected is None: self.last_retry_kind = "capacity_wait" return None ad_name, memory = selected ads, image = self.preflight(memory_gbs=memory) ads = [ad for ad in ads if ad.name == ad_name] if not ads: raise FatalOCIError( "reported availability domain is no longer usable" ) return self.launch_cycle(ads, image, memory_gbs=memory) 이 지점에는 의도적인 한계도 있다. 먼저 가장 큰 AVAILABLE 후보를 고른 뒤 사전 점검하므로, 그 후보가 사용량 상한에 걸리면 자동으로 다음 작은 후보를 골라 계속하지 않는다. 현재는 중단하는 보수적인 정책이다. “남은 예산 안에서 최적의 사양을 찾아주는 자동 배치기”까지 구현한 것은 아니다. 용량 확인과 사전 점검을 통과해도 실제 생성 결과는 별도로 처리한다. 중복·사용량 점검은 필요한 방어지만, 조회와 생성 전체를 하나의 원자적 작업으로 만들어 주지는 않는다. 미확정 요청은 새 용량 보고서보다 우선한다 가장 신경 쓴 경계 사례는 작은 사양으로 보낸 요청의 응답을 잃는 경우였다. 1GB 후보만 AVAILABLE이라서 1GB 요청을 보낸다. 통신이 끊겨 서버가 요청을 받아들였는지 모른다. 프로그램이 재시작한다. 이제 6GB가 가능해 보인다는 이유로 새 요청을 만들면 어떻게 될까. 네 번째 단계에서 원래 작업을 잃어버리면, 아직 끝나지 않은 요청과 새 요청이 동시에 존재할 수 있다. 따라서 이 상태에서는 용량 보고서를 다시 기준으로 삼지 않는다. 기존 인스턴스 확인으로 결과를 찾지 못했다면, 원래 요청 사양으로 사전 점검하고 동일 요청을 이어간다. 실제 코드에서는 후보 선택보다 이 분기가 먼저 나온다. pending = self.state.data.get("pending") if pending: memory = self._request_memory( pending.get("memory_gbs", self.memory_gbs) ) ads, image = self.preflight(memory_gbs=memory) return self.launch_cycle(ads, image, memory_gbs=memory) launch_cycle() 은 저장된 토큰·AD·이미지·최초 요청 시각과 메모리를 사용한다. 새 요청이라면 전송 전에 선택한 메모리까지 pending에 저장 한다. 새 이미지가 조회되더라도 미확정 요청의 이미지를 바꾸지 않는다. 23시간 중단 기준 역시 기존대로 유지한다. 이 구분은 후보 목록 변경에도 적용된다. 허용 메모리 후보는 설정 지문에 포함하지만, 조회 간격은 포함하지 않는다. 후보 추가는 실제로 만들 수 있는 자원의 범위를 바꾸고, 간격 변경은 기다리는 정책을 바꾸기 때문이다. 기존 상태에서 후보를 추가하면 곧바로 실행하지 못하도록 막고, 동일 후보의 순서 변경과 조회 간격 변경은 요청 정체성을 바꾸지 않는지 테스트했다. 조회 횟수와 실패 횟수는 다른 지표다 감시 주기는 기본 60초에 ±10초 지터를 적용해 50~70초의 대기를 둔다. 이는 이 도구의 운영 설정이며 Oracle의 권장 호출 주기나 처리량 보장이 아니다. 실제 조회 시작 간격에는 API 처리 시간도 더해진다. 모든 오류에 이 짧은 주기를 적용하지도 않는다. 결과 현재 운영 정책 유효한 보고서에 가용 후보가 없음 생성하지 않고 50~70초 대기 신규 생성이 명확한 용량 부족으로 실패하고 pending이 없음 50~70초 뒤 다시 조회 429 또는 통신·일시 서버 오류 별도의 10~60분 백오프 원래 미확정 요청의 재전송에서 용량 부족 응답 pending을 보존하고 기존 4~6분 대기 정책 적용 권한 오류·알 수 없는 응답·안전 기한 초과 중단하고 확인 이를 구분하려고 capacity_reports , last_capacity_report , last_failure_kind , next_attempt_at 을 남겼다. 중요한 것은 이름이 아니라 증가 조건이다. capacity_reports 는 응답 검증을 마치고 처리한 보고서 수다. 실패한 조회 시도까지 포함한 HTTP 호출 총수가 아니다. AD가 여러 개라면 실행 루프 한 번에 여러 보고서가 기록될 수도 있다. failed_cycles 도 정확한 생성 API 실패 횟수는 아니다. capacity_wait 는 제외하지만, 조회·통신 오류 등 성공하지 못한 다른 사이클은 포함할 수 있다. 이름만 보고 생성 실패 횟수로 해석하면 운영 상태를 잘못 읽게 된다. 10월 2일 20:44 KST에 저장된 스냅샷에서는 다음이 확인됐다. 실시간 수치가 아니라 그 시점의 기록 이다. 확인 항목 기록된 상태 서비스 active / running, 재시작 횟수 0 처리한 용량 보고서 6,979회 failed_cycles 4,216으로 감시 전환 당시 값 유지 마지막 분류 capacity_wait 마지막 보고서의 6GB·2GB·1GB 후보 모두 OUT_OF_HOST_CAPACITY 미확정 요청 없음 조회된 비종료 인스턴스 기존 Micro 1대, 신규 A1 없음 이 기록은 감시 경로가 동작했다는 근거다. 용량을 확보했다는 근거나 성공 확률이 높아졌다는 측정 결과는 아니다. 외부 알림 채널도 아직 연결하지 않았다. 테스트로 확인한 범위 10월 2일에는 용량 감시 테스트 파일을 로컬 가상환경에서 다시 실행했다. mock과 임시 상태 파일을 사용하는 16개 테스트가 통과했다. Ran 16 tests in 2.617s OK 핵심 검증은 정상 생성만이 아니었다. 가용 후보가 없는 보고서에서는 생성하지 않기, AVAILABLE 뒤 용량 부족이 발생하면 조회로 복귀하기, 사전 점검 실패 시 생성하지 않기, 후보 누락·범위 불일치·권한 오류에서 멈추기를 확인했다. 응답을 잃은 1GB 요청은 같은 토큰·이미지·메모리로 재전송하고, 이때 보고서 API를 호출하지 않는지도 확인했다. 오래된 미확정 요청을 새 사양으로 대체하지 않는 테스트와, 저장된 다음 예약이 재시작 후에도 유지되는 테스트도 포함되어 있다. 이번 글을 준비하며 운영 서버를 재시작하거나 설정·권한을 변경하지 않았다. 테스트 중 실제 생성 API도 호출하지 않았다. 모의 AVAILABLE 분기 통과, 운영에서의 조회 성공, 실제 인스턴스 확보는 서로 다른 검증 단계다. 용량 감시를 붙이기 전 체크리스트 보고서 조회와 자원 예약을 구분했는가 루트 구획·AD·shape·후보 사양을 응답과 대조하는가 누락되거나 알 수 없는 응답을 가용 상태로 간주하지 않는가 AVAILABLE 이후에도 선택한 사양으로 사전 점검하는가 점검 실패 시 작은 사양으로 내려갈지 중단할지 정책이 명확한가 미확정 요청이 있으면 후보 재선택보다 원래 요청 처리를 우선하는가 선택한 사양과 요청 정체성을 전송 전에 저장하는가 조회 오류의 백오프와 정상 용량 대기를 구분하는가 지표가 보고서 수인지 호출 수인지 실패 사이클 수인지 설명할 수 있는가 다음에 보완할 운영 관찰 이번 변경으로 “용량이 없어 기다리는 상태”와 “요청 결과를 몰라 확인해야 하는 상태”를 코드와 기록에서 구분할 수 있게 됐다. 하지만 기록이 있다는 것과 사람이 필요한 시점에 알림을 받는 것은 다르다. 다음에는 조회가 오래 멈춘 경우, 수동 확인이 필요한 경우, 실제 확보가 완료된 경우를 나눠 알림 조건을 정리하려 한다. 아직 구현되지 않은 부분이다. 우선 이번 글의 결론은 단순하다. 가능해 보인다는 관찰을, 이미 성공했다는 사실로 바꾸지 않는다.