클라우드 용량 부족으로 인스턴스 유형을 넓힙니다. 비용·아키텍처·성능·보안 조건을 어떻게 보존하나요?
꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
01
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
후보 유형을 넓히면 용량 확보 가능성을 높일 수 있지만 architecture·CPU 성능·메모리·네트워크·보안·가격이 달라집니다. 앱의 이미지·native 의존성·성능 기준을 유지해야 합니다.
허용 범위를 NodePool 등 정책에 명시하고 비용 상한·기본 최소 용량을 둡니다. 실제 부족·회복·혼합 하드웨어에서 workload p99와 준비 시간을 비교합니다. 단순 노드 생성 성공을 동등 서비스 용량으로 세지 않습니다.
02
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 후보 유형을 넓히면 용량 확보 가능성을 높일 수 있지만 architecture·CPU 성능·메모리·네트워크·보안·가격이 달라집니다. 앱의 이미지·native 의존성·성능 기준을 유지해야 합니다.
- 단순 노드 생성 성공을 동등 서비스 용량으로 세지 않습니다.
03
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: 후보 유형을 넓히면 용량 확보 가능성을 높일 수 있지만 architecture·CPU 성능·메모리·네트워크·보안·가격이 달라집니다.
04
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.