Datadog Oracle AI Database 모니터링 방법과 비용 관리 활용

실무 맥락: 앱과 DB 사이에 끼는 사각지대

Oracle 데이터베이스를 클라우드 앱과 같은 곳에 두면 온프레미스 관리 부담은 줄지만 새 문제가 생깁니다. 앱은 클라우드 사업자 환경에서, DB는 OCI에서 돌다 보니 앱이 느려졌을 때 원인을 찾기 어려워요. 이전 직후 성능을 검증하는 일도, 클라우드 사업자와 Oracle의 청구서가 따로 오는 상황에서 DB 비용을 귀속하는 일도 어렵습니다. 앱 팀은 앱을 보고 DBA 팀은 DB를 보는 사이에 근본 원인이 걸려 있는 경우가 많습니다.

이번 내용: Bits Chat으로 장애 원인 좁히기

DBM은 Oracle DB에서 워크로드 지표, 쿼리 샘플, 실행 계획을 모읍니다. DBM의 Bits Chat Database Investigations는 이 데이터를 스택 전반의 로그와 함께 분석해 근본 원인과 해결 단계를 제시해요. Oracle 전문 지식이 깊지 않은 엔지니어도 한 번의 조사로 지연 원인까지 갈 수 있다는 게 Datadog의 설명입니다.

원문 예시는 서비스 엔드포인트 지연이 치솟은 상황이에요. APM 트레이스를 따라 DBM으로 넘어가 조사를 시작하면, 옵티마이저가 인덱스 조회 대신 풀 테이블 스캔을 주기적으로 고르는 것이 원인으로 나옵니다. 제안된 조치는 cursor cache에서 불러온 SQL Plan Baseline으로 좋은 실행 계획을 고정하는 것인데, 이는 옵티마이저가 계획을 바꾸지 못하게 막는 Oracle 기능이에요. 조치 후에는 Bits에게 지표를 다시 확인해 기준선 복귀 여부를 보게 할 수 있습니다.

Databases 뷰에서는 활성 연결을 wait group별로 나눠 CPU, I/O, 락 중 무엇을 기다리는지 볼 수 있어요. Top Queries 뷰는 정규화된 SQL별 실행 횟수, 평균 소요 시간, 총 실행 시간을 보여줍니다. 쿼리 샘플의 태그 메타데이터로 부하가 큰 쿼리를 애플리케이션별로 묶어 우선순위를 정할 수도 있어요.

이전 후 검증과 비용 귀속

온프레미스 Oracle을 클라우드로 옮긴 직후에는 컷오버 뒤 성능 검증이 필요합니다. Datadog은 DBM 쿼리 샘플에 APM 트레이스 ID를 붙여서, 샘플링된 트레이스마다 그 뒤에 있는 쿼리를 보여줘요. 상위 APM 서비스별로 DB 연결을 쪼개면 새 DB에 부하를 가장 많이 거는 애플리케이션이 드러납니다. 트레이스 안에서 explain plan과 실행 이력도 열어볼 수 있는데, 샘플링된 wait event, 평균 지연, 유사 쿼리의 최근 계획이 들어 있어서 지금 보는 현상이 이 쿼리의 평소 모습인지 비정상인지 가릴 수 있어요.

비용 쪽은 CCM이 OCI와 클라우드 사업자의 비용을 한 데이터셋으로 모으고 FOCUS 태그로 정규화합니다. OCI 비용 수집을 설정하면 매일 비용 데이터를 가져와서 청구 주기가 끝나기 전에 지출 변화를 볼 수 있어요. OCI 비용 데이터의 resource_id 태그가 DB 비용과 관측 데이터를 잇는 연결고리입니다.

실무 적용 포인트

• 비용은 높은데 쿼리 활동이 적은 DB는 사이즈 조정(rightsizing) 후보로 볼 수 있어요.
• 특정 애플리케이션 서비스가 쿼리 활동 대부분을 차지하면 어느 팀이 비용을 끌어올리는지 확인됩니다.
• Datadog Notebooks로 엔지니어링과 FinOps 팀이 성능과 비용 데이터를 같이 보며 사이즈 조정안을 논의할 수 있어요.
• 공급자마다 제각각인 태그는 Tag Pipelines로 표준화하고, 비용 배분의 빈틈은 Tag Explorer로 찾습니다.
• OCI 지출이 예상 밖으로 늘면 cost monitor로 알림을 받고, multi-provider 예산과 예측으로 Oracle 비용을 다른 클라우드 지출과 나란히 추적합니다.
• 시작은 AWS, Azure, Google Cloud 중 쓰는 쪽의 sub-integration 설정부터이고, Datadog 계정이 없으면 14일 무료 체험이 있습니다.

자주 묻는 질문

Datadog으로 Oracle AI Database를 모니터링하는 방법은 뭔가요?

AWS, Azure, Google Cloud 각각의 표준 연동 안에 있는 Oracle AI Database sub-integration을 설정하면 됩니다. 연동마다 50개 이상의 기본 제공 지표와 대시보드가 따라와요. 쿼리 성능은 DBM, 앱 요청과의 연결은 APM으로 봅니다.

Bits Chat Database Investigations는 무엇을 하나요?

DBM이 모은 워크로드 지표, 쿼리 샘플, 실행 계획을 스택 전반의 로그와 함께 분석해 근본 원인과 해결 단계를 알려주는 기능이에요. 원문 예시에서는 옵티마이저가 풀 테이블 스캔을 고르는 문제를 SQL Plan Baseline으로 고정하라고 제안했습니다. 조치 후 지표를 다시 확인해 달라고 요청할 수도 있어요.

멀티클라우드 Oracle DB 비용은 어떻게 팀별로 나누나요?

CCM이 OCI와 클라우드 사업자의 비용을 FOCUS 태그로 정규화해 매일 수집하고, resource_id 태그로 DB 비용을 쿼리 활동과 연결합니다. 이를 바탕으로 DB 부하를 만드는 애플리케이션 서비스를 찾아 팀별로 귀속시킬 수 있어요.

Oracle DB를 클라우드로 이전한 뒤 성능은 어떻게 검증하나요?

DBM과 APM을 연결해 앱 서비스에서 DB까지 요청을 따라가며 확인합니다. 쿼리 샘플에 APM 트레이스 ID가 붙어서 트레이스마다 그 뒤의 쿼리를 볼 수 있고, 새 실행 계획이 지연의 원인인지도 이력과 함께 비교할 수 있어요.