오픈 준비, 오픈, 안정화

오픈 준비

운영서버 준비

개발이 끝나갈 때쯤엔 오픈 시기가 다가온다. 기본적으로 운영서버가 들어와야 되고, 거기에 서버 담당자가 OS나 기본 소프트웨어를 설치하고, 애플리케이션을 실행할 WAS나 솔루션 등이 설치된다. SWA는 유료 솔루션은 엔지니어에 설치를 요청하고, 무료 소프트웨어는 직접 설치와 설정을 진행한다. 그리고, 기본 설치 소프트웨어가 정상적으로 작동하는지 애플리케이션을 배포하고, DB에 데이터를 올려서 테스트를 진행한다. 여기까지가 운영서버가 들어온 후 기본적으로 하는 테스트이다.
보통 1개의 인스턴스로만 구성하는 개발서버와 달리 운영서버는 2개 이상의 서버 또는 WAS 인스턴스로 구성한다. 여기서 신경 써야 할 것이 있다.
- WAS에서 HTTP Session을 이용해서 사용자 정보를 저장하도록 개발한 경우에는 반드시 세션클러스터링을 구성해야 한다. WAS 자체에서 제공하는 세션클러스터링을 사용하든, 외부의 세션저장소를 사용하든 반드시 세션클러스터링이 되어야 어떤 WAS 인스턴스에 접속되었든 같은 사용자 정보를 참조할 수 있다.
- 파일 업로드/다운로드 기능을 사용할 경우에 모든 WAS 인스턴스들이 동일한 경로로 접근할 수 있는 공용디스크(예를 들면, NAS 등)를 붙여야 한다. 파일이 업로드되는 WAS서버와 다운로드하는 WAS서버는 다를 수 있기 때문에 어떤 서버에 파일을 업로드하고 어떤 서버로부터 파일을 다운로드하든 같은 디스크를 보도록 해야 한다.
- DB나 HTTP 등의 커넥션풀의 사이즈와 타임아웃 등의 설정값을 운영환경의 처리용량에 맞춰서 조정해야 한다. 한 가지 주의할 것은 커넥션풀의 사이즈는 각 WAS 인스턴스 하나마다 생성되는 크기라는 것이다.

운영서버 빌드/배포

개발서버에 대한 빌드/배포는 대개 개발 브랜치의 최신버전 소스를 사용하도록 구성하면 되지만, 운영서버에 배포하는 소스는 개발서버에서 검증된 소스만 허용해야 되므로 별도의 브랜치를 사용하고, 배포할 때마다 브랜치나 태그를 따로 생성해야 한다. 그래야 운영에 배포된 소스에 문제가 있을 경우 빠른 시간 안에 이전에 성공적으로 배포된 버전의 소스로 원복 할 수 있다.
이를 위해 운영서버에 대한 빌드/배포 정책은 정교하게 수립되어야 한다. 브랜치 생성과 배포승인, 배포를 실행하는 담당자와 배포 후에 대한 기능 검증 등에 대해 잘 정리해 두어야 한다.

통합 테스트

개발이 완료되어 단위 테스트가 끝나 갈 무렵에는 복합적인 업무에 대해 전체적인 처리 흐름을 확인하기 위해 통합 테스트를 진행한다. 되도록 위에서 구성한 운영서버 빌드/배포쳬계를 이용해 운영서버에서 진행한다.
SWA는 보통 운영서버 빌드/배포를 전담하는 담당자로 매일 정해진 시간에 배포하거나, 통합테스트 관리자로부터 요청을 받는 경우 비정기적으로 배포를 실행한다.

가용성 테스트

가용성 테스트는 서버나 장비 또는 인스턴스 일부에 장애가 발생했을 때, 전체 서비스가 멈추지 않고 계속되는지 확인하는 테스트이다. 그래서, 다중화된 웹서버나 WAS, DB 인스턴스나 서버 중 일부를 내리고 서비스가 진행되는지 확인하는 것으로 일반적으로 큰 문제없이 짧은 시간에 테스트가 완료된다. 여기서 중요한 것은 어떤 부분까지 장애가 발생했을 때 서비스가 가능해야 하는지 내릴 인스턴스나 서버를 정하는 것이다.
SWA는 가용성 테스트를 진행하거나 관리자로부터 요청을 받아서 테스트 중에 웹서버나 WAS를 재기동하고 프로그램이 제대로 수행되는지 확인하는 역할을 담당한다.

성능 테스트

성능 테스트는 아주 중요하고, 실제로 설계부터 테스트를 진행하는 과정까지 굉장히 길고 어려운 과정을 거친다. 보통은 성능 테스트 담당자가 프로젝트에 투입되어 성능 목표치와 테스트 대상 업무 선정, 스크립트 기록 및 부하까지 진행하기 때문에 SWA는 시키는 일만 잘 준비해 놓고 있다가 WAS가 솔루션을 내렸다가 기동하고 쌓인 로그를 지우는 역할을 주로 한다. 그런데, 성능 테스트하는 동안 네트워크에 부하가 많이 가기 때문에 다른 서비스에 영향을 주지 않기 위해서 주로 새벽시간에 테스트를 진행한다는 것이다. 그리고, 성능 테스트 중에 프레임워크나 업무프로그램 또는 설정에 문제가 있어서 원하는 만큼의 성능이 나오지 않을 때는 SWA가 이 부분을 고쳐야 한다. 성능 테스트도 가용성 테스트와 마찬가지로 개발프레임워크 뿐만 아니라 인터페이스나 기타 솔루션 중 성능 테스트가 필요한 부분을 성능 테스트에 포함시키도록 해야 한다.
성능 테스트 중에 애플리케이션에서 문제가 발생하면 SWA는 문제를 찾아서 해결해야 한다. 보통 부하를 주기 전에는 잘 돌아가던 프로그램이 성능 테스트 때 문제가 발견되는 경우가 많기 때문에, 일단 개발 프레임워크를 만들 때부터 이런 상황이 발생하지 않도록 주의를 기울여야 한다. 성능 테스트 때 문제가 발생하면 로그를 확인하고, jstack이나 jmap 등을 이용해서 문제의 원인을 찾은 후 코드나 설정을 수정해서 문제를 해결해야 한다.
성능 테스트 중에 SWA는 Singleton 클래스나 풀의 설정 문제로 병목이 생겨 처리용량이 linear 하게 못 올라가는지, thread-safe 등의 문제로 예상과 다른 응답이 오는지 확인해야 한다. 로그파일도 계속 모니터링하면서 예상하지 않았던 오류가 발생하는지도 확인한다.

 

오픈

오픈이 1~2주일 앞으로 다가오면 오픈일의 오픈 시간에 맞춰서 할 일을 아주 세세하게 계획한다. 마지막 소스 배포부터 WAS 및 프로그램 기동, 기본 기능 테스트까지 동작 하나하나를 계획해서 실수로 빠뜨리는 작업이 없도록 하려는 것이다. 오픈일이 되면 견디기 힘든 무거운 분위기가 사무실 전체를 감싼다. 누구 하나라도 실수하면 자신 때문에 오픈을 실패했다는 책임을 질 수 있기 때문에 더욱 긴장하게 된다. 그래서, 이렇게 상세하게 계획을 세우는 것이고, 이 계획만 잘 세우면 오픈도 문제없이 할 수 있다.

 

안정화

개발 및 테스트를 잘 진행하고 오픈 준비까지 완벽하게 했으면 좋겠지만, 완벽한 준비는 신의 영역인지라 언제나 오픈 후에 크고 작은 문제가 발생한다. 오픈 직후에 큰 문제가 발생하면 실패 결정을 내리고 오픈을 연기하게 되고, 작은 문제가 발생해서 어떻게든 오픈을 유지할 수 있으면 문제를 해결하면서 버틴다.
이렇게 오픈 후에 문제를 고쳐 나가는 기간이 안정화 기간이다. 안정화가 잘 되면 별로 할 일이 없지만, 안정화가 아주 많이 필요한 경우에는 수시로 프로그램을 고쳐서 운영서버에 배포를 해대야 한다. 운영서버 배포는 보통 SWA 쪽에서 수행하기 때문에 하루 종일 앉아서 배포만 할 수도 있다. 배포 및 재기동 중에 문제만 일으키지 않겠다는 마음으로 차례차례 절차만 잘 지키면서 배포해 주면 된다. 언제나 문제는 서두르다가 절차를 빼먹거나 잘못 수행해서 발생하는 것이다. 조금 더 빨리 배포한다고 SWA에게 득 될 것은 없다. 빨리 배포하겠다고 서두르다가 실수해서 문제가 생기면 책임이 생길 수는 있어도.

 

 

1. 소프트웨어 아키텍트란?

2. 요구사항 조사

3. 소프트웨어 아키텍처 설계

4. 개발 프레임워크 설계

5. 로컬 개발환경 구성

6. 개발프레임워크 준비

7. 개발가이드 작성 및 개발자 교육

8. 개발단계에서의 개발자 지원

9. 오픈 준비, 오픈, 안정화