State

여러분의 앱이 생성한 인프라를 추적합니다.

상태

여러분이 앱을 배포할 때, SST는 앱의 인프라 상태를 추적하기 위해 로컬에 상태 파일을 생성합니다.

이렇게 하면 변경 사항이 있을 때, SST가 상태와 차이를 비교하여 변경된 부분만 배포할 수 있습니다.

여러분의 앱 상태는 다음을 포함합니다:

리소스에 대한 상태 파일. 이는 JSON 파일입니다.
상태의 비밀을 암호화하는 데 사용되는 암호.

이 외에도, SST는 앱이 처음 배포될 때 몇 가지 다른 리소스도 생성합니다. 이에 대해서는 아래에서 살펴보겠습니다.

상태는 로컬에서 생성되지만, 다음을 사용하여 프로바이더에 백업됩니다:

상태를 저장하기 위한 버킷. 일반적으로 sst-state-<해시>라는 이름으로 생성됩니다. 이는 여러분의 home 지역에 생성됩니다. 이에 대해서는 아래에서 더 자세히 설명하겠습니다.
비밀을 암호화하는 데 사용되는 암호를 저장하기 위한 SSM 파라미터. 이는 /sst/passphrase/<앱>/<스테이지> 아래에 생성됩니다. 또한 여러분의 home 지역에 생성됩니다.

암호는 모든 비밀과 민감한 정보를 암호화하는 데 사용됩니다. 이 암호가 없으면 SST는 상태 파일을 읽고 앱을 배포할 수 없습니다.

홈

sst.config.ts 파일에서 앱의 상태를 저장할 프로바이더를 지정합니다. 이를 앱의 홈이라고 부릅니다.

{
  home: "aws"
}

여러분은 사용할 프로바이더를 지정할 수 있습니다. 현재 aws와 cloudflare가 지원됩니다.

홈 프로바이더를 지정하면, SST는 해당 프로바이더를 앱에서도 사용할 것으로 간주하고 내부적으로 프로바이더 목록에 추가합니다. 따라서 위의 코드는 아래와 동일합니다.

{
  home: "aws",
  providers: {
    aws: true
  }
}

이는 aws 프로바이더의 리전을 변경하면, 홈의 리전도 함께 변경된다는 의미입니다.

홈 프로바이더에 대해 더 자세히 알아보려면 Config 문서를 참고하세요.

Bootstrap

SST가 여러분의 앱에 리소스를 배포하기 시작하면, 몇 가지 추가적인 bootstrap 리소스를 생성합니다. 앱에 Lambda 함수나 Docker 컨테이너가 있다면, SST는 해당 리소스와 동일한 리전에 다음을 생성합니다:

함수 패키지를 저장하기 위한 assets 버킷, 일반적으로 sst-asset-<hash>라는 이름으로 생성됩니다.
컨테이너 이미지를 저장하기 위한 ECR 리포지토리, sst-asset라는 이름으로 생성됩니다.
assets 버킷 이름과 ECR 리포지토리를 저장하기 위한 SSM 파라미터, /sst/bootstrap 아래에 저장됩니다.
Live를 지원하기 위한 AppSync Events API 엔드포인트.

SSM 파라미터는 이러한 리소스의 위치를 조회하는 데 사용됩니다.

SST 앱을 제거할 때, _state_나 bootstrap 리소스는 제거되지 않습니다. 이는 다른 앱이 이를 사용하고 있을지도 모르기 때문입니다. 따라서 SST가 생성한 모든 리소스를 완전히 제거하려면, 배포한 리전에서 수동으로 제거해야 합니다.

리셋

실수로 부트스트랩 리소스를 제거하면 SST CLI가 시작되지 않을 수 있습니다.

이 문제를 해결하려면 부트스트랩 리소스를 리셋해야 합니다.

파라미터에 나열된 리소스를 제거합니다. 예를 들어 asset 또는 state 버킷, 혹은 ECR 리포지토리를 제거합니다.
SSM 파라미터를 제거합니다.

이제 SST CLI를 실행하면 계정을 다시 부트스트랩합니다.

작동 방식

상태 파일은 여러분의 앱이 생성한 모든 저수준 리소스의 JSON 표현입니다. 클라우드 프로바이더의 리소스 상태를 캐시한 버전입니다.

따라서 배포를 하면 다음과 같은 일이 발생합니다.

sst.config.ts에 있는 컴포넌트들이 저수준 리소스 정의로 변환됩니다. 이 정의들은 상태 파일과 비교됩니다.
두 파일 간의 차이점은 클라우드 프로바이더에 전달되는 API 호출로 변환됩니다.
- 새로운 리소스가 있으면 생성됩니다.
- 리소스가 제거되었다면 삭제됩니다.
- 리소스 설정에 변경 사항이 있으면 적용됩니다.
상태 파일은 이러한 리소스의 새로운 상태를 반영하도록 업데이트됩니다. 이제 sst.config.ts, 상태 파일, 그리고 클라우드 프로바이더의 리소스가 모두 동기화됩니다.

동기화 불일치

이 과정은 여러분이 클라우드 프로바이더의 콘솔을 통해 리소스를 수동으로 변경하기 전까지는 잘 작동합니다. 하지만 수동으로 변경하면 상태와 리소스가 동기화되지 않게 됩니다. 이는 경우에 따라 문제를 일으킬 수 있습니다.

몇 가지 시나리오를 살펴보겠습니다.

예를 들어, Function을 { timeout: 10 seconds" }로 설정하여 배포했다고 가정해 봅시다. 이 시점에서는 설정, 상태, 리소스가 모두 동기화되어 있습니다.

리소스 변경하기

이제 AWS 콘솔에서 타임아웃을 20초로 변경합니다.
- 설정과 상태는 여전히 10초로 설정되어 있어 리소스와 동기화되지 않습니다.
앱을 배포하면 설정이 상태와 비교됩니다.
- 차이점이 없기 때문에 리소스를 업데이트하지 않습니다.

설정과 상태는 리소스와 동기화되지 않은 상태로 유지됩니다.

설정 변경하기

설정을 { timeout: 30 seconds" }로 변경하고 배포를 진행한다.
설정과 상태 간에 차이가 발생한다.
SST는 AWS에 요청을 보내 리소스의 타임아웃을 30초로 설정한다.
- 업데이트가 완료되면, 상태 파일을 현재 리소스 상태와 일치하도록 업데이트한다.

설정, 상태, 리소스가 다시 동기화된다.

리소스 제거하기

다음으로 AWS 콘솔로 이동해 함수를 제거합니다.
- 설정과 상태에는 여전히 타임아웃이 30초로 설정된 함수가 남아 있습니다.
설정을 { timeout: 60 seconds }로 변경하고 배포를 진행합니다.
설정과 상태가 달라집니다.
SST는 리소스의 타임아웃을 60초로 업데이트하기 위해 호출을 시도합니다.
- 하지만 이 호출은 함수가 존재하지 않기 때문에 실패합니다.

이제부터 배포가 실패할 것입니다. 상태 파일에는 리소스가 존재한다고 표시되지만 실제로는 존재하지 않기 때문입니다. 이 문제를 해결하려면 상태 파일을 _새로고침_해야 합니다.

리소스 동기화

클라우드의 리소스가 앱의 상태와 동기화되지 않은 상황을 해결하려면 다음 명령어를 실행해야 합니다.

sst refresh

이 명령어는 몇 가지 간단한 작업을 수행합니다:

상태에 있는 모든 리소스를 하나씩 확인합니다.
클라우드 프로바이더에 요청을 보내 리소스를 확인합니다.
- 설정이 다르면 상태를 업데이트하여 변경 사항을 반영합니다.
- 리소스가 더 이상 존재하지 않으면 상태에서 제거합니다.

이제 상태와 리소스가 동기화됩니다. 앞서 AWS 콘솔에서 함수를 제거했지만 설정이나 상태에서는 제거하지 않은 상황을 예로 들어보겠습니다. 이 문제를 해결하려면 다음 단계를 따릅니다:

sst refresh를 실행합니다.
- 이 명령어는 상태에서도 함수를 제거합니다.
이제 설정을 { timeout: 60 seconds }로 변경하고 배포를 진행합니다.
설정과 상태를 비교하면 해당 설정을 가진 함수가 존재하지 않음을 확인합니다.
SST는 AWS에 요청을 보내 주어진 설정으로 새로운 함수를 생성합니다.

일반적으로 클라우드 프로바이더에서 리소스를 수동으로 변경하는 것은 상태를 동기화되지 않게 만들기 때문에 권장하지 않습니다. 하지만 이러한 상황에 처하게 되면 sst refresh 명령어를 사용하여 다시 동기화할 수 있습니다.