안녕하세요, 지인과 이야기를 하다가
AWS는 호스트 머신이 죽어도 VM이 그대로 살아있다는 소리를 들었습니다.
여기서 생긴 의문이...
결국 VM는 하이퍼바이저 위에 올라가는거고
스토리지는 스토리지 서버에 연결해둬서 문제가 없겠지만
VM이 사용하는 메모리는 물리서버의 메모리를 할당받아서 사용하기 때문에
호스트머신이 하드웨어 트러블(전원이든 뭐든)으로 갑자기 떨어지면
VM는 페일오버 등으로 다른 호스트머신에서 재부팅 된 것 같은 상황으로 살아난다... 라는게 제 인식이었는데
지인 말로는 AWS나 OpenStack으로 구성한 경우 컴퓨트 노드가 메모리 또한 공유하기 때문에
갑작스럽게 호스트 머신에 HW트러블이 생겨도 다른 호스트에서 리얼타임으로 마이그레이션이 되기 때문에
서비스 중단이 없이 그대로 이어진다고 하더군요.
VoIP 전화쟁이라, 만약 가능하다면 그런 VM 서비스를 사용해야할 것 같긴한데...
VM호스트의 메모리라면 128GB 이상일테고 메모리의 대역폭을 생각하면 리얼타임으로 동기하기 위해서는
PCI-E 로 직접 각 호스트를 연결해도 리얼타임 동기는 힘들 것 같은데 어떻게 그런것이 가능한지가 궁금합니다.
암튼 그래서 지인 말로는 AWS는 네트워크 트러블 말고는 장애 자체가 없다고...
VoIP 전화쟁이한테는 치명적이네요 이건 또... ㅋㅋ
고가용성은 애플리케이션 레이어에서 구현해야 합니다.
그런 써비스가 있다면.. 공항이나 은행. 증권사등.. 비싼데에 쓸건데요.
기술적으로는 가능해 보입니다. 비싸서 그렇지.
2년 정도 전에 AWS 가 인천공항 서비스 하고 있었는데 6시간 정도 서비스를 못했어요.
티켓팅관련하여.. 그때는 통신장애라고 했던것 같은데.. 당연 이중화 되어 있었을 건데..
AWS 사고 많이 났는데요. 대략 1년에 2번 정도는 문제가 생기는 것 같어요.. 지금까지는
그러지 않고 버티면 end 날짜에 EC2가 자동 재기동 됩니다.
실시간으로 메모리도 복제하고 그래야되니 IO적인 성능이 그렇게 좋을리는 없을거 같은데 네트워크에선 CARP 기능이 실시간으로 세션을 복제하긴 합니다. 그래서 페일오버되면 세션 안끊기고 바로 턴받아서 처리되니까 안끊어진것처럼 보입니다.
그 외에 Proactive HA를 구성할 경우, BMC 로그를 트리거로 장애가 발생하기 전에 VM을 evacuate 할 수 있습니다.
하지만 OpenStack이나 AWS에서 이러한 기능을 지원하지는 않습니다.
아니 CPU 레벨에서 동기라는게 가능한거였어요!? 덜덜덜
vSphere FT 라도 voip rtp 중계서버의 무중단은 어려워보였는데
FT Server 라면 그런것도 가능할 것 같네요 +ㅁ+
이 때 기존의 통신하고 있던 세션은 90분간 고정되어 버려서 90분이상 완전히 통신이 끊어지지 않는 이상
해당 IP:port 와의 통신은 1주일 이상 계속되어서 안될거라고 생각했는데
cpu 명령어 레벨에서 동기화 한다고 하셨기도 했고 설명을 다시 읽어보니
확실히 잠시 rtp 패킷 몇개가 손실될 수는 있겠지만 가능하겠네요...
여러모로 항상 가르침을 받습니다. 감사합니다.
잠시 suspend 시키고 다른걸로 옮겨서 바로 서비스 되게 해줄줄 알았쓴데 말이죠
지인이 없다고 하니까 뭔소린가 싶었습니다. ㅋㅋㅋ;
도대체 비싸기만 하고 별룬데 이걸 왜 쓰지? 싶어지긴 합니다 ㅎㅎ
가격적인 메리트가 없어보이는데 AWS가 뭐가 좋은지 모르겠었는데
직접 써보신 분께서 그리 말씀을 하시니,
제가 그래도 2cpu 눈팅하면서 아무것도 모르는건 아니었구나 싶네요 으하핫;;
심지어 서버리스 서비스인 Lambda를 써도 오래 쓰다보면 nodejs 버전 업데이트 필요하다고 메시지가 옵니다..
웹 UI로 관리가 편한 서비스이지, 기반에는 하드웨어 장비가 없을 수 없으므로 원인에 따라 당연히 연속적인 서비스가 안될 수 있더라고요.
HW 레벨에서 폴트난걸 VM (EC2)가 자동으로 HW를 변경하거나 이동하는 기능은 없습니다. (이동하면 더 문제가 발생합니다. 라이센스 등등)
하드웨어 장애가 발생하면 해당 하드웨어 위에 올라 가 있는 인스턴스 (EC2, RDS, 컨테이너 등) 의 소유자에게 연락이 갑니다.
(일반 사용자는 메일, 비즈니스/엔터프라이즈 서포트 등급은 담당 AM이 직접 연락 줍니다)
그 다음 위에서 말씀 주신것 처럼 재부팅 하면 인스턴스가 가용영역 (AZ) 내 다른 HW에서 부팅 됩니다.
인스턴스에 할당된 스토리지 (EBS 볼륨)는 별도의 HW + 다중화가 기본으로 설정되어 있기 때문에 영향이 없습니다.
저런 장애 상황을 회피하기 위해 가용성과 복원력이 있는 아키텍처를 설계 하라고 권장 드리고는 있습니다만...
현실적인 문제 (비용 등)가 많아 도입이 더딘 경우가 많습니다.
요즘에는 멀티클라우드/하이브리드 클라우드 등을 이용하여 저러한 장애를 더더욱 줄이기 위해 노력하는 고객사도 계십니다.
지금은 서비스를 종료한 라쿠텐 클라우드는 failover 때 자동으로 올라오긴하는데 40분가량 걸렸던게 생각나네요 ㅎ;
저희도 비용에 꽤나 민감? 해서 스토리지 10엔(/월) 추가로 들어가는걸 아끼겠다고
인력을 갈아넣는 븅신짓을 하... 아 아닙니다. ㅋㅋ
이중화...해보고 싶네요 ㅋㅋ
애당초 라쿠텐을 썼던건 윗분들의 사정이었던지라 해방된 지금은 훨~~~~씨ㄴ 성능 좋은걸 써서
행복해지기는 했는데... 뭐 아쉬운게 아에 없지는 않네요 ㅋㅋ