BTP 인스턴스 실수 3가지 #shorts #SAP #BTP

BTP 서비스 인스턴스 관리에서 자주 발생하는 실수

SAP BTP Cloud Foundry 환경에서 서비스 인스턴스를 생성하고 관리하는 과정에서 반복되는 실수들이 있습니다. 이 실수들은 배포 실패, 보안 취약점, 불필요한 비용으로 이어집니다. 3가지 핵심 실수와 올바른 처리 방법을 다룹니다.

실수 1: 서비스 플랜을 환경에 맞게 선택하지 않음

# 실수: Trial 환경의 플랜을 운영에 그대로 사용
# Trial BTP에서 개발한 mta.yaml
resources:
  - name: myapp-hana
    type: com.sap.xs.hdi-container
    parameters:
      service: hana
      service-plan: schema    # Trial 전용 플랜

# 운영 배포 실패 → 운영 환경에는 schema 플랜이 없음

# 올바른 방법: 환경별 mtaext 파일로 플랜 분리
# production.mtaext
_schema-version: '3.1'
extends: com.mycompany.myapp

resources:
  - name: myapp-hana
    parameters:
      service-plan: hdi-shared  # 운영 플랜

# trial.mtaext
_schema-version: '3.1'
extends: com.mycompany.myapp

resources:
  - name: myapp-hana
    parameters:
      service-plan: schema      # Trial 플랜

# 배포 시
cf deploy myapp.mtar -e production.mtaext  # 운영
cf deploy myapp.mtar -e trial.mtaext       # Trial

실수 2: 서비스 키를 소스 코드에 하드코딩

# 실수: Service Key를 .env나 소스에 하드코딩
# .env 파일 (Git에 올라가면 보안 사고)
HANA_HOST=abc123.hana.ondemand.com
HANA_PORT=443
HANA_USER=SYSTEM
HANA_PASSWORD=SuperSecret123!

# Node.js에서 직접 사용
const hana = require('@sap/hana-client');
const conn = hana.createConnection();
conn.connect({
  host: process.env.HANA_HOST,  // .env에서 읽음
  port: process.env.HANA_PORT,
  uid: process.env.HANA_USER,
  pwd: process.env.HANA_PASSWORD  // 하드코딩 패스워드
});

# 올바른 방법: BTP 서비스 바인딩으로 자격증명 자동 주입
# mta.yaml에서 바인딩 설정
modules:
  - name: myapp-srv
    requires:
      - name: myapp-hana    # 자동 바인딩

# 앱에서는 VCAP_SERVICES 환경변수만 읽음
const vcap = JSON.parse(process.env.VCAP_SERVICES || '{}');
const hanaCredentials = vcap.hana?.[0]?.credentials;
// host, port, user, password가 자동으로 주입됨
# 소스 코드에 자격증명 없음

실수 3: 사용하지 않는 인스턴스를 방치 (비용 낭비)

# BTP 서비스 인스턴스 현황 조회
cf services

# 출력 예시:
# myapp-hana      hana    hdi-shared   create succeeded
# test-hana-old   hana    hdi-shared   create succeeded  (사용 안 함)
# poc-xsuaa       xsuaa   application  create succeeded  (POC 종료됨)

# 사용하지 않는 인스턴스 삭제
cf delete-service test-hana-old
cf delete-service poc-xsuaa

# 삭제 전 바인딩 확인
cf service test-hana-old
# No bound apps  → 안전하게 삭제 가능

# 자동화: 미사용 인스턴스 감지 스크립트
#!/bin/bash
echo "=== 바인딩 없는 서비스 인스턴스 ==="
cf services --no-header | while read name service plan status; do
  bound_apps=$(cf service "$name" | grep "bound apps" | awk '{print $NF}')
  if [ "$bound_apps" = "none" ]; then
    echo "미사용: $name ($service/$plan)"
  fi
done

추가 실수: XSUAA 앱 이름 중복

# xs-security.json에서 xsappname은 BTP 서브어카운트 내 유일해야 함
# 실수: 같은 이름으로 여러 인스턴스 생성 시도
{
  "xsappname": "myapp"  # 이미 존재하면 오류
}

# 올바른 방법: 환경을 포함한 고유 이름 사용
{
  "xsappname": "myapp-prod-2026"   # 운영
}
# trial.mtaext에서 xsappname 오버라이드
{
  "xsappname": "myapp-trial-2026"  # Trial
}

서비스 인스턴스 업데이트 주의사항

# XSUAA 인스턴스 파라미터 업데이트 (스코프 추가 시)
cf update-service myapp-xsuaa -c xs-security.json

# 주의: 업데이트 후 바인딩된 앱 재시작 필요
cf restart myapp-srv
# 재시작하지 않으면 새 스코프가 앱에 적용되지 않음

체크리스트

환경별(Trial/Dev/QA/Prod) 서비스 플랜이 올바른가
자격증명이 소스 코드나 환경변수에 노출되지 않았는가
미사용 서비스 인스턴스를 주기적으로 정리하는가
XSUAA 업데이트 후 앱을 재시작했는가
mta.yaml의 서비스 이름이 실제 인스턴스 이름과 일치하는가

공식 문서

BTP 서비스 인스턴스 관리 가이드는 SAP BTP 공식 문서에서 확인하세요.

댓글 0