이전에 1편 포스팅을 해놓고 바로 후속을 한다는게 ..
먹고사니즘이 크다 보니 오래걸렸다..
두개로 나뉘어서 했던 이유는
- 메이저 버전변경의 필요가 생겼을때 어떠한 기준으로 변경을 버전을 선택할 것인가.
라면
- 실제 버전변경은 어떻게 할 것인가
의 차이이다.
기술적으로의 방법은 간단하다 클러스터 '수정' 으로 들어가서 버전을 변경하고 적용하면 끝날 뿐이다.
인스턴스에서 고려 할 부분은 최신버전에서 사용가능한 Aurora I/O 최적화와
서버리스v2 또는 6세대 기반의 인스턴스로 교체를 할것인가에 대한 고민이 추가적으로 필요하다.
두가지 모두 성능적 비용적으로 좀 더 나아질 수 있음을 기대할 수 있는 좋은 선택지이지만 어떤내용인지는 알아야 할테고 두개 다 각각의 포스팅을 한다 쳐도 너무 멀고 긴 내용이라, 인사이트 위주로 짧게 작성하는 내 블로그 포스팅과는 맞지 않는다. (쓸때없는 짤이나 밈 붙이기도 귀찮고 트래픽낭비다.)
Aurora serverless v2
aurora 서버리스는 클러스터에 적용되는 '쓰는만큼돈낸다' 의 접근이다
Aurora instance class
r6g r7g의 경우는 aws에서 직접 설계한 칩으로 돌아가는 인스턴스 들이다.
스냅드래곤이나 애플의 실리콘칩을 생각한다면 이는 상당히 유용한 선택옵션이다.
어찌 됐든 버전을 포함한 모든 버전을 변경 후 반영을 하면 인스턴스 재기동을 하게 되며,
업그레이드 실패시 복원에 필요한 스냅샷생성 작업과 같이 이뤄진다.
작업중에 찍어주는 진행사항은 로그에서 확인이 가능하며,
업그레이드 실패시 로그를 기반으로 추가적인 작업을 해주면 된다.
업그레이드가 실패하는 케이스는 너무 다양해서 나열하기 어려우나
1. 익스텐션의 의존성(버전, 미지원등)
2. 시스템테이블을 기반으로한 뷰 또는 머터리얼 뷰
3. 일반사용 목적이 아닌 퍼블릭스키마의 사용 등이 있었다.
어찌 됐건 이렇게 버전변경을 하면 '꼭' 통계정보 업데이트를 해줘야한다.
-- DB 전체 풀 실행
vacuum full analyze;
-- DB 전체 간단하게 실행
vacuum verbose analyze;
-- 해당 테이블만 간단하게 실행
vacuum analyse [테이블 명];
-- 특정 테이블만 풀 실행
vacuum full [테이블명];
심플하게 너무 간단하게, 인스턴스를 갈아 끼웠으니
테이블 갱신이 아니라 전체를 대상으로 해야하며 full이건 심플이건 선택지는 이쪽뿐이다.
특히 운영환경에서 갱신 후 통계정보 갱신을 하지 않는다면
서비스타임에 지옥을 맛볼 수 있을 것이다.
버전의 선택, 실제 작업 방식에 대해서 알게 되는것은
사실 구글링을 통해서 많은 부분 해결 할 수 있으며
오히려 작업중 서비스 중단 시간에 대한 예측,
인스턴스를 교체할것인지 아니면 스냅샷만 생성하고 원본인스턴스를 업데이트 할지 에 대한 고민.
변경후 테스트방법과 검증방안.
이러한 것들이 더 크고 어려운 문제이다.
물론 클라우드의 보급 이후로 si쪽을 제외한다면
전문 dba인력을 보유하거나 해당 롤을 운영하는 곳이 이전보다 많이 줄어들었기 때문에
서비스 운영자, 시니어 엔지니어, 클라우드 담당자, db담당자 가 모두 같이 모여
의견을 내고 협의하에 의사결정을 하며 진행을 해야한다.
가장 무난하고 이상적인 플랜은
금융권에서의 접근과 동일한 형태로 넉넉한 기간동안 버전별 제품을 병행가동하며
안정성 테스트를 하고, 사용자 이용 시나리오 기반으로 테스트를 진행하는 것이다.
