회원가입 API, 앱 버전 검사 API 이 2개의 API를 제외하고는 모두 jwt방식을 통한 인증을 수행할 계획입니다.
api-gateway 에서 rest-api로 api호출을 전달할 때, 인증의 결과를 어떻게 전달할 것 인지 논의가 필요합니다.

발급할 access_token은 Device 테이블을 조회해서 생성하며, user_id 를 claim에 넣을 계획입니다

1. panic에 대한 recover

ERRO[0002]/home/jinsu/workspace/depromeet/everybody/rest-api/infra/http/middleware.go:19 
github.com/depromeet/everybody-backend/rest-api/infra/http.errorHandle() 
runtime error: invalid memory address or nil pointer dereference

runtime error: invalid memory address or nil pointer dereference 와 같은 에러는 panic을 유발하고 recover 해주지 않으면 프로세스가 종료된다. 하지만 매번 recover해주는 것은 비효율적이므로 이런 경우 fiber의 recover middleware를 사용할 수 있다. 그리고 이때 StackTrace를 enable 시켜주면 아래와 같이 stack trace를 할 수 있다.

app := fiber.New(fiber.Config{
	ErrorHandler: errorHandle,
})
app.Use(recover.New(recover.Config{EnableStackTrace: true}))

이렇게 stack trace를 할 수 있다.

2. 일반적인 error에 대한 stack trace

fmt.Errorf()를 이용해 에러를 wrapping한 경우 에러가 발생해도 어떤 곳에서 에러가 발생했는지 trace할 수가 없다. 기존에 사용하던 builtin errors 패키지의 errors.New()는 단순히 문자열 정보만 포함하고 Wrapping 조차되지 않는 에러를 생성하므로 이 역시 trace 불가능.

https://github.com/pkg/errors 패키지를 이용하면 errors.New() (앞선 errors 패키지와 패키지 명은 동일하지만 다른 패키지)를 통해 에러에 대한 문맥을 추가할 수 있다.

trace 할 수 없는 에러 상황 예시

GET /pictures/{{picture_id}} 을 통해 사진의 세부정보를 조회할 때 {{picture_id}}는 Long형 숫자여야한다. 하지만 숫자가 아닌 문자 같은 것을 전달하면 에러가 발생한다.

ERRO[0035]/home/jinsu/workspace/depromeet/everybody/rest-api/infra/http/middleware.go:19
github.com/depromeet/everybody-backend/rest-api/infra/http.errorHandle()
strconv.Atoi: parsing "wrong_number": invalid syntax
13:56:49 | 500 |      0s |       127.0.0.1 | GET     | /pictures/wrong_number    | strconv.Atoi: parsing "wrong_number": invalid syntax

하지만 슬프게도 http.errorHandle()에서는 에러를 출력할 뿐 이 에러가 어디서 발생한 지 알 수 없다... 거의 strconv가 호출되는 부분을 모두 점검해봐야한다...

...
pictureID, err := strconv.Atoi(param)
if err != nil {
	return errors.WithStack(err)
}
...

하지만 위와 같이 pkg/errors 패키지의 .WithStack 메소드를 이용해 에러가 발생한 문맥을 추가하면 다음과 같이 stack trace가 가능하다.

한 가지 단점은 error을 WithStack으로 Wrapping할 때마다 Stack 정보가 추가되는데 이게 매번 중복돼서 추가된다는 점이다. 예를 들어
A -> B -> C로 에러가 래핑됐으면 C를 출력할 때 C의 stack만 trace하면 좋겠는데 A, B, C 모두의 stack을 한 번씩 다 trace 한다는 것이다. 그래도 큰 불편은 아니니 우선 사용해보면서 좀 더 가다듬는 게 좋을 것 같다.

과거에 빌드, 배포할 때에 메모리 이슈로 인해 프리티어인 t2.micro를 사용하지 못했던 경우가 있어 한 번 더 t2.micro로 Spring boot app을 돌릴 수 있을지 확인해보고자합니다.

주로 메모리를 점유하는 것은 다음과 같을 것으로 예상됩니다.

• Spring boot 서버
• Elastic Beanstalk Agent (Elastic Beanstalk 관련 작업들을 수행하기 위해 떠있는 프로세스)
• 새로 배포할 Spring boot 앱을 build하거나 download하는 작업

최소한 JPA와 Spring MVC 의존성은 포함을 해야 정확할 것 같아 이 의존성들을 포함하여 배포해보겠습니다.

약 1000MB 중 빌드에 26.5%의 메모리, 기존 버전 서버 실행에 19.5%의 메모리 buff/cache에 약 288MB가 사용중이라 빌드 중엔 free memory가 65MB밖에 없어서 좀 아슬아슬하긴하다...

과거 경험 상으론 새 패키지를 install 해야하는 빌드의 경우 특히 메모리를 많이 사용했던 것 같기도 하다.

• 현재는 rest-api만 5000번 포트로 eb에 배포되도록 구성되어 있는데 api-gateway + rest-api를 한 ec2 인스턴스에 같이 배포되도록 구축해야 함(API-Gateway만 외부와 통신할 수 있도록...)
• Github Action으로 자동 api-gateway + rest-api elastic beanstalk으로 자동 배포되도록 설정해야 함

• As Is
  • Opencv로 mp4 영상을 만들고 파일로 저장 후 AWS S3로 업로드하는 형태로 구현한 상황
• To Be
  • 생성된 mp4 바이트 데이터로 넘겨주는 방법으로 개선이 필요(공부를 더 해서 개선해볼게요...)