대규모 인프라 운영 13. 아키텍처 전문가 되기 1
대규모 인프라를 운영하려면 좀 더 나은 기술을 사용해야 한다.
대규모 인프라 운영 경험을 공유합니다.
실제 대형 사이트에서 사용 중인 12가지 운영 노하우입니다.
중소기업에서는 어떻게 하면 좋을지 저만의 의견도 적어봅니다.
1. 가상 서버는 OS, WEB/WAS, DB가 설치된 이미지를 준비하라.
문제점
OS 설치 후, WEB/WAS, DB설치 시간이 많이 걸린다.
이벤트 등이 생기면 20대 정도 늘려야 하는데 시간이 부족하다.
해결방안
OS, WEB/WAS, 애플리케이션, DB를 한 서버에 설치하고 그 이미지를 만들어두고 재사용한다.
해당 이미지는 보안점검도 미리 받아 나중에 따로 보안점검을 받는데 시간을 낭비하지 않도록 한다.
표준 OS와 표준 WEB/WAS, 설치 위치 등 사전에 표준이 정해져 있어야 한다.
이미지 관리가 필수이다.
중소기업에서는 설치가 많지 않으므로 그냥 OS 설치, WEB/WAS, DB설치 등 하나씩 해도 차이는 없다^^
2. 네트워크 장비 L4를 이용하여 디폴트 이중화하라.
문제점
서버 1대로 운영 중 서버 장애 시 서비스가 중지됨
해결방안
서버는 2대 이상으로 구축하고, 네트워크 L4 장비를 이용해 서비스를 이중화하라.
서버는 24시간 켜놓는 장비라 언제든 고장 날 수 있다.
1대 고장이 난다고 서비스가 중지되면 안 된다.
중소기업에서는 DNS A레코더를 2개 주어 이중화하거나(수동 Fail-over가능)
클라우드의 L4기능을 이용하여 저렴한 비용으로 사용하면 된다.(자동 Fail-over 됨)
AWS L4기능 제공하는 Route53 https://brunch.co.kr/@topasvga/28
MS에 저, 구글 Cloud, 알리 Cloud L4기능은 확인해보고 별도 업데이트하겠다^^
3. L7 Check설정을 통한 WAS, DB 장애까지 모니터링하라.
문제점
L4를 쓰더라도 WAS장애 시 Fail-over가 되지 않는다.
해결방안
L7 Check설정으로 WAS, DB오동작까지 모니터링하여 Fail-over를 한다.
L4에서 WEB서버 장애는 잘 모니터링되고 Fail-over가 되지만, WAS 안된다.
L7 Check설정을 통해 해결을 한다.
WEB에서 WAS를 모니터링하는 부분을 만들어 L4에서 모니터링한다.
L4가 L7 Check를 지원해야 하며, L4 장비 부하가 늘어나므로 장비 성능 고려를 반영해야 한다.
4. 웹 Cache 등 기술 플랫폼을 적용한다.
문제점
이벤트 등으로 급격히 트래픽이 늘어나는 경우 웹서버 부하가 늘어나 서비스 지연이 발생
해결방안
Web과 Was사이에 Cache기술 플랫폼을 적용하여 부하를 감소시킨다.
적용사례: 대선사이트 Varnish 적용 http://d2.naver.com/helloworld/352076
5. CDN을 활용하라~
문제점
사용자가 빠른 네트워크에서 콘텐츠를 받지 못한다.
해결방안
CDN 서비스를 이용해 사용자가 가까운 네트워크에서 콘텐츠를 받도록 한다.
CDN 운영기술 https://brunch.co.kr/@topasvga/9
6. MySQL DB 이중화를 MMM을 활용하라
문제점
Mysql MasterDB 가 장애 발생하는 경우 서비스가 중지된다.
해결방안
Mysql MMM(Mysql Multi-Mmaster) 설정하여, DB가 자동 Fail-over 되도록 한다.
7. 사용자가 늘어 DB 성능이 부족한 경우 , Read-Only DB를 사용하여 분산한다.
문제점
사용자가 늘어 DB HW를 업그레이드(Scale-UP) 해야 하는데, HW슬롯이 없어 증설이 불가하여
서비스가 느려지는 경우 발생
해결방안
애플리케이션에서 읽기 기능은 Slave DB를 바라보도록 변경하여 Master DB로 집중되는 걸 분산하여 해결한다.
8. 주간단위로 인프라 모니터링 리뷰하는 시간을 가져라.
문제점
서비스 오픈 후 서버 사용률이 높아져 장애로 이어지고 있다.
해결방안
주간단위로 모니터링 리뷰하며, 사용량이 부족한 경우 증설하여 장애를 예방할 수 있다.
모니터링 시스템의 데이터를 이용한다.
Zabbix의 Screen기능으로 주요 서비스 WEB, WAS, DB의 CPU, MEM, DISK, SWAP,. 네트워크 트래픽을 주간단위로 리뷰하라.
트래픽 변경이 왜 생겼는지 사업, 개발팀과 커뮤니케이션하여 성능을 개선하라..
WEB, WAS, DB용 표준 서버를 각각 사전에 정의하고, DB경우 좀 넉넉하게 정의하라.
DB용량 부족한 경우, 전체 서비스 장애로 이어진다.
DB증설 작업을 해야 하는 경우는 작업자 리소스가 낭비된다.
9. 회사 핵심 서비스는 데이터센터 이중화를 하라.
문제점
회사의 핵심 서비스인데, IDC 랙 전원이 나가거나 화재의 경우, 서비스 전체적으로 안 되는 경우가 발생한다.
해결방안
DNS와 L4를 이용해 IDC이중화한다.
GSLB 장비 또는 AWS Route53을 이용해 IDC이중화한다.
Read가 많은 뉴스 서비스의 경우 IDC이중화가 가능하다.
Write가 되는 서비스의 경우는 IDC이중화가 쉽지 않다. (데이터 동기화에 대한 고민이 필요)
10. IDC 전체 서버 이전작업 시 GSLB기능을 이용해 가중치를 두어 영향을 최소화한다.
문제점
IDC의 서버를 전체 이전 시 서비스 영향도가 크다.
해결방안
GSLB 장비나 AWS Route 53의 GSLB기능을 이용하여, 가중치를 두어 서비스를 넘기도록 한다.
AWS Route53 GSLB기능 사용법 https://brunch.co.kr/@topasvga/28
11. 장애가 길어질 경우 공지 페이지 서버군을 준비하라.
문제점
장애가 발생되고 해결에 시간이 길어질 경우 사용자에게 오류 페이지가 장시간 보인다.
해결방안
장애 시 긴급 점검 중이라는 페이지가 보이도록 미리 준비한다.
장애 공지용 서버군을 외부에 구축한다.
장애가 길어지면 DNS에서 해당 서비스 도메인을 장애 공지용 서버팜으로 전환
장애 공지용 서버팜에서는 *. 도메인명. com으로 유입이 되면 특정 장애 공지 페이지를 보여주도록 설정한다.
장애 공지 팜은 외부에 두어야 한다.
Aws s3와 route53을 이용해도 괜찮을 거 같다.
12. 정기점검 시 사용자가 필수 서비스는 받도록 Read-Only DB를 활용하자
문제점
정기점검을 하면 매번 서비스가 모두 중지된다.
해결방안
정기점검 시에도 사용자에게 필수 기능인 읽기 기능은 제공되도록 한다.
Read OnlyDB를 사용하여 읽기 기능은 작업 중에도 제공한다.
게시판 서비스의 경우 쓰기를 막는다.
주기적인 서비스 관리는 쉽게 따라 할 수 있지만, 비용이 들어가는 부분은 고려가 필요하다.
그리고, 위 기술을 모두 적용하려 하지는 말아라.
해당 기업의 규모와 특성에 맞게 가면 된다.
한 번에 하나씩 ^^
감사합니다.
