본문 바로가기

Development/ETC

enum 수정 후 deploy 시 문제점.

필요에 의하여 enum을 수정할 일이 있었다.

즉, enum에 값을 추가한 뒤, 해당 값을 사용하는 로직을 배포했다. 

그런데 갑자기 Error가 엄청나게 올라오기 시작했다. 

로직의 결함은 전혀 없었는데 도대체 왜 Error가 발생 했을까?




이 2가지 상황을 고려하면 내가 발생시킨 Error는 당연한 것으로 보인다.


내가 배포한 서비스는 다수의 서버에서 실행된다.

다수의 서버를 동시에 배포하면 서비스에 차질이 있므로, 순차적으로 배포했다.





다음의 예를 보면 알 수 있다.


기존의 서비스에서 한 enum 클래스가 아래와 같이 존재할 때,


[Old Enum]

1
2
3
4
5
public enum Color {
        BROWN,
        YELLOW,
        WHITE
}
cs

이 Enum을 아래와 같이 변경한다.



[New Enum]

1
2
3
4
5
6
public enum Color {
    BROWN,
    YELLOW,
    WHITE,
   BURGUNDY //added
}
cs


그리고 이 추가된 BURGUNDY를 사용하고 저장하는 아래 로직 또한 추가되었다고 하자.


[New Logic]

1
2
Paint paint = new Paint(3030, Color.BURGUNDY); // 30x30 size의 BURGUNDY 색상 Paint 객체 생성
PaintDAO.save(paint); //DB에 저장
cs




위와 같이 개발을 마치고, 이제 deploy를 하려고 한다.

앞서 말했듯이, 서비스 영향도를 위해 순차적으로 배포를 한다.


자 1번 서버 먼저 배포가 완료되었다고 하자.


자 그렇다면 현재 상황은 아래와 같을 것이다.



이 순간 클라이언트가 Server 1로 타게 되면(Request)

[New Logic] 을 통해 BURGUNDY 색상을 가진 Paint 객체를 생성하고, DB에 저장할 수 있다.


그리고 몇초 뒤 다시 들어와서는 자신의 Paint를 조회하고자 한다.

하지만 클라이언트는 불행하게도 Server 2(또는 3,4)로 요청하게 된다. 


이때 Server 2,3,4는 DB에서 가져온 Paint의 BURGUNDY를 알 수 없기 때문에 Error가 발생한다.


이것이 오늘 내가 에러를 만든 상황이다.

Server 1,2,3,4 전체 배포가 완료되기 전에는 해당 Error는 지속적으로 발생할 것이다.


자 그렇다면 위와 같은 상황에서, 가장 근본적인 해결책은 무엇일까?


내가 내린 결론은 2번 배포하는 것이다.


1. 변경된 enum을 먼저 배포.

2. 전체 서버에 적용이 완료 되었을 때, 추가된 enum 값을 사용하는 로직을 다시 한번 배포.


더 좋은 해결책들이 분명히 있을 것 같지만, 오늘의 느낀 점을 잊지 않기 위해 정리한다.


이와 같은 문제가 enum에만 국한되는 문제는 절대 아닌 것은 누가 봐도 잘 알 것이다.

여러 대의 서버를 두고 운영되는 서비스에 배포를 할때면 많은 고려할 사항이 생기는데.

앞으로는 조금 더 신중한 개발을 할 수 있도록.

정신차리자.