앞선 글에서 다뤄봤던 가용성이 시스템이 정지되지 않도록 대비하는 것 이라면,
성능과 확장성 영역은, 시스템 사용 현황을 바탕으로 사전에 미래를 예측하고, 시스템 사용자 수가 증가함에 따라 서버 부하가 높아질 때를 대응하는 것 처럼 이른바 예상되는 미래에 대비하는 것이라고 볼 수 있다.
사전에 예비 CPU를 탑재하거나, 탑개 가능하게끔 슬롯을 준비한다거나..
그런 것들도 확장성이라고 볼 수 있겠다.
성능 및 확장성을 고려한 설계
시스템의 성능 및 확장성을 고려할 때 전제하는 정보의 대표적인 항목은 다음과 같다.
- 시스템을 사용하는 사용자 수
- 동시에 시스템에 접속하는 사용자 수
- 시스템에서 다루는 데이터양과 보관 기간
- 응답 시간의 목표 값
- 처리율(스루풋) 목표 값
해당 조건들을 충족시키려면 리소스와 서버가 어느정도 필요한지 어림잡아 추정해야한다.
이를 사이징이라 한다.
사실 인프라라는게 처음에 계획한대로 수정 없이 진행된다면 참 좋겠지만.. 현실은 그렇지 않다.
실제 운영 환경에 필요한 견적은 정확히 산정할 수 없다.
따라서 추정한 값에 일정한 안전율을 곱하여 사용하는 것을 권장한다고 한다. (일반적으로 1.2~1.5)
3계층 시스템을 대상으로 대표적인 구성 요소별로 살펴보자.
서버 메모리와 CPU 선정
CPU, 메모리, 디스크를 사람에 비유한다면
- 책상 : 메모리 -> 넓을수록 많은 작업을 동시에 할 수 있음
- 두뇌 : CPU -> 빠를수록 일을 빠르게 처리할 수 있음
- 서랍 : 디스크 -> 서랍 용량이 커지면 많이 보관할 수 있음
위와 같이 비유할 수 있다.
CPU와 메모리 둘 다 시스템의 업무 처리량, 응답 시간, 단위 시간당 처리율 등의 요구사항에 따라 사양이 결정된다. 사양을 정할때에는 각 제조사의 벤치마크 정보를 활용하면 성능을 어느 정도 예측할 수 있다.
그 중에서도 CPU는 코어수를 특히 고려해야한다. 아무리 성능이 우수한 CPU더라도 코어 한 개는 작업 하나만 처리할 수 있다. 따라서 매우 고사양 CPU 하나를 탑재하는 것이 효율적일 수도 있고, 보통 성능의 cpu를 여러개 탑재하는 것이 효율적일 수도 있다. 성능과 비용의 균형을 고려하여 시스템 특성에 맞는 CPU를 선정해야 한다.
또 한가지는 스케일업과 스케일아웃이다.
간략하게, 스케일업은 서버 자체 성능을 높이는 방법이고, 스케일아웃은 서버 수를 늘리는 방법이다.
애플리케이션 변경, 사용자 수의 급격한 변화 등 다양한 이유로 시스템 리소스가 부족할 수 있으므로 확장을 지원하는 모델을 선정해야 한다.
애플리케이션 서버의 힙 메모리 영역 설정
애플리케이션 서버는 기동할 때 애플리케이션에서 사용하는 메모리 공간을 애플리케이션 서버 내에서 일정 영역 확보한다. 이 영역을 힙 메모리 영역이라고 한다.
힙 메모리 영역은 크기에 제한이 있으므로, 여유 공간 이상의 객체를 생성할 수 없다. 여유 공간 이상의 객체를 만들려고 하면 자바의 Out Of Memory가 발생하고 자바 프로세스가 종료된다.
그렇다면, '힙 메모리를 무조건 크게하면 되는거 아닌가?' 라는 생각을 할 수 있다.
애플리케이션에서 더 이상 힙 메모리 영역에 할당된 객체를 사용하지 않더라도 특별히 아무것도 하지 않으면 그대로 메모리 영역에 남아있다. 즉, 아무것도 하지 않고 그대로 두면 힙 메모리 영역은 사용되지 않는 객체로 가득 차게 된다는 것 이다. (쓸데없이 옷장 공간만 차지하는 입지 않는 옷들 느낌일까..)
기본적으로 애플리케이션 서버에는 이런 불필요한 객체를 삭제하는 매커니즘인 가비지 컬렉션 기능이 있다. 이를 수행하는 주체인 가비지 컬렉터가 동작할 때, 힙 메모리의 크기가 영향을 준다고 한다.
또한, 가비지 컬렉터는 사용자가 인지하지 못 할 정도의 짧은 시간만에 청소를 끝내지만, 동작 중에는 애플리케이션 본연의 기능이 중지되므로 이 역시 힙 메모리를 무제한으로 크게 만들기 어려운 이유이다.
적절한 힙 메모리 영역은 부하테스트 등을 통해 맞춰나가야한다.
데이터베이스 메모리 설정
DB 성능에는 메모리 설정이 영향을 많이 미친다.
그 중에서 DB의 대부분을 차지하는 가장 중요한 메모리 영역인 데이터 캐시 영역의 설정을 중심으로 살펴보자.
DB 시스템은 자신이 보관하는 데이터를 조회, 갱신할 때 처리 시간이 걸리는 디스크 공간에 접근하기 전에 처리가 매우 빠른 메모리의 데이터 캐시 영역에 접근하여 필요한 정보가 있는지를 먼저 찾아본다. 데이터 캐시 영역에 찾는 데이터가 없다면 다시 디스크 영역에 접근해서 정보를 찾는다.
즉, 데이터 캐시 영역은 시스템 성능을 높이고자 사용 빈도가 높은 데이터에 빠르게 접근하게 하는 데이터 보관 공간이다.
그렇다면, '모든 데이터를 데이터 캐시 영역에 보관한다면, 조회 속도를 월등히 올릴 수 있는 것 아닌가'? 라는 생각이 들지도 모른다. 하지만, 수백 GB, TB에 이르는 데이터를 메모리에 보관한다는 것은 매우 비현실적이라고 한다.(이 부분은 다소 이전에 기록되었던 책에 있는 내용이기에, 지금은 개선되었을수도 있다. 후에 더 자세히 찾아봐야겠다)
또한, 이론적으로는 데이터 캐시 영역을 크게 설정할수록 캐시 히트율이 높아지고 그로 인해 성능이 향상되는 것이 맞지만, 실제로는 일정 수준 이상부터는 성능이 좋아지지 않는 지점이 존재한다고 한다.
가상화 서버를 이용한 시스템 확장
가상화 서버는 서버(or 물리 서버?) 1대에 복수의 가상 서버를 정의하여 사용하는 방식을 말한다. 각 가상화 서버에서는 독립적으로 OS나 소프트웨어를 실행시킬 수 있으며, 물리 서버 하나를 마치 복수의 독립된 서버처럼 사용할 수 있다.
장/단점
장점
- 서버 수 감소에 따른 운영 비용 절감
- 서버 관리의 단순화
- 리소스의 효율적인 활용
- 오래된 OS나 소프트웨어 사용 (하드웨어 의존도가 낮기에 가능)
단점
- 기대하는 성능이 나오지 않을수도..
- 물리 서버의 내결함성(장애 대응 등) 설계가 복잡하다
- 가상화에 대한 전문 지식 필요 (결국 물리 서버 1대의 리소스를 분할 구축하는 것)
확장성
물리 서버와 가상화 서버의 확장성 영역에 있어 가장 결정적인 차이점은 그 방법에 있다. 가상화 서버의 CPU나 메모리 등 리소스는 한 곳에 탑재되어 있다. 따라서, 스케일업을 수행할때는 (여분의 리소스가 있다는 것을 전제로) 그때마다 리소스를 추가할 필요는 없고, 각 가상 서버의 리소스양을 작성한 정의 파일을 수정하여 서버를 재시작하는 것만으로도 작업이 완료된다.
물리적으로 부품을 갈아끼우거나 해야 하는 것이 아니기 때문에, IDC에 가지 않고 원격으로도 작업자가 작업할 수 있다. 또 최근에는 서버 재기동조차 불필요하고, 정의 파일을 변경하는 것만으로도 동적으로 리소스를 추가할 수 있는 가상화 소프트웨어도 존재한다고 한다.
책의 이번 장의 마지막에 이런 문구가 써있었다.
'''
인프라 설계자는 사용자 요구사항을 듣고 이런 인프라 환경 중에서 최적의 조합을 선택해야 합니다.
차례로 등장하는 최신기술에 항상 관심을 가져야 한다는 의미입니다. 사용자가 최신 기술에 대해 문의했을 때 '아, 잘 알지 못해서 죄송합니다' 하고 대답한다면 인프라 설계자로 좋은 평가를 받지 못할 수 있습니다.
'''
앞으로 점점 더 클라우드 엔지니어, 인프라 엔지니어의 경계, 그리고 각 파트 별 개발자의 경계가 무너지지 않을까 싶다. 한 사람이 더 많은 일을 할 수 있게되었지만, 그만큼 한 사람이 감당하고, 알아야 할 것들도 많아졌달까.
가상화같은 클라우드 기술도 더 공부해야겠다.
