Azure VHD 디스크 생성 시 캐시 지정에 관하여

Microsoft Azure에서 실행되는 VM은 Azure BLOB Storage를 사용하여 VHD 디스크를 동적으로 연결하여 사용합니다. 이것은 광의로 해석하면 Storage Area Network 위에서 실시간으로 호스팅되는 가상 디스크를 마운트하여 사용하는 셈인데, 실제로 Microsoft Azure의 VM이 시험판 단계일 때에는 예기치 않은 문제들이 제법 많았습니다. (물론 지금은 그런 일도 없고, 또 그렇게 되어서는 안되겠죠.)


 


 


Azure BLOB Storage 그 자체도 내부적으로 상당히 많은 추상화가 이루어져있는 복잡한 기술이지만, 이것을 기반으로 하는 VHD를 사용한다는 것은 어떻게 생각하면 추상화의 극을 달린다는 느낌에 가깝습니다. 물론, 이토록 고도화된 시스템을 사용하기 때문에 얻을 수 있는 이점으로는 무중단 상태에서 같은 지역은 물론 여러 지역에 걸쳐 VHD를 실시간으로 미러링하여 백업하거나 VHD 자체를 로드밸런싱하는 등의, 종전의 클라우드 서비스 공급자들도 상상하기 어려운 스케일의 서비스를 제공할 수 있게 된 점은 있습니다. 하지만 흔히 기대하는 베어메탈급의 고성능 서버와는 거리가 멀리 떨어진 듯한 느낌을 지울 수는 없겠지요.


엄밀히 말해서, 정말 빠른 디스크 I/O를 필요로 한다면 오히려 클라우드 환경에 의존하기 보다는 직접 고성능 서버를 구입하여 구축하는 것이 훨씬 더 이치에 맞습니다. 하지만, 단순히 디스크 I/O가 빨라야 하는 요구 사항을 고려하는 것이 아니라면, 대부분의 인프라의 가치는 장애 대비와 적시 복구인 경우가 많습니다. 이런 점을 고려하여, 어느정도 만족할만한 수준의 디스크 성능과 안정성을 동시에 거둘 수 있는 간단한 팁을 하나 올립니다.


Azure에서 VM을 만들고 디스크를 추가로 생성하여 연결할 때, 다음 그림과 같이 질문을 받습니다.


001


여기서 제일 아래쪽의 호스트 캐시 기본 설정이라는 항목이 제가 오늘 말씀드리려는 내용에 대한 것입니다.


호스트 캐시란 앞에서 이야기한 대로 실제 디스크 I/O를 처리하기 위한 과정에서 중간에 관여하는 구성 요소로, 원칙대로라고 한다면 Azure Storage의 VHD에 대해 발생하는 디스크 I/O를 Azure Storage가 완전히 처리해서 응답을 되돌려주기까지의 과정을 운영 체제의 입장에서는 기다려야 하는 셈입니다. (물론 여기서 다 설명하기에는 어려울 정도로 복잡한 메카니즘이 있어서 정말 순진하게 캐시를 사용하지 않는다고해서 무작정 기다리기만 하는 것은 아닙니다.)


그러나 좀 더 적극적으로 개입해서, 실제로 디스크 I/O가 저멀리 있는 Azure Storage에 전달이 되기 이전이라고 하더라도, 확실하게 디스크 I/O에 대한 요청이 접수되었고 처리가 되었음을 기억하여 정확한 응답을 되돌려주면서, 다른 한편으로는 그 내용을 실제 Azure Storage의 VHD에 지속적으로 보내주는 역할을 따로 수행하게 됩니다.


다르게 말하면, 만약 Azure Storage와 연결이 끊어지거나 문제가 발생하는 경우 캐시의 유효성이나 지속성에 문제가 생겨서 서비스 장애로 이어지는 불상사가 벌어질 수 있습니다. 그러나 바꾸어 말하면 캐시를 사용하지 않을 때에는 이것이 직접적으로 VM 위에서 돌아가는 프로그램에 대한 OS의 IO API 호출에 대한 실패로 직격탄이 되어버립니다. 이런 점을 고려해보면, 문제의 전파나 영향 범위를 최소화하는 관점에서 캐시가 미미하지만 어느정도 역할을 수행하는 것도 가능합니다.


이러한 성격의 캐시를 사용할 수 있는 방안은 두 가지가 있는데, 읽기 작업을 위한 캐시만 사용하는 경우와, 읽기/쓰기 작업을 모두 관리하는 캐시를 사용하는 경우입니다. 운영 체제용으로 만들어지는 VHD는 읽기/쓰기 작업을 모두 관리하는 캐시를 기본으로 사용하도록 하고 있습니다. 그리고 추가 연결하는 디스크에 대해서는 디스크 I/O 빈도가 높지 않을 것임을 가정하고 기본적으로는 캐시 없이 직접 Azure BLOB Storage와 연결되도록 하는 것이 기본입니다.


이러한 상황에서, 만약 디스크의 읽기 성능이 중요하다면 읽기 캐시를 사용하도록 해주는 것이 필요합니다. 이렇게 하면 최초로 캐시에서 가지고 있지 않은 데이터 영역에 대한 요청이 들어왔을 때, 이를 캐시에 저장하고 다음 회차 요청 때 좀 더 빠르게 전달할 수 있도록 해주는 식이 됩니다. 물론 쓰기나 다른 동작에 의해 변경이 발생하게 되면 이에 맞추어 당연히 캐시도 다시 형성됩니다.


여기에 쓰기 캐시를 사용하는 것 까지 포함하게 되면, 쓰기 캐시에 들어오는 요청과 읽기 캐시의 내용을 병합하여 중간 버퍼를 형성하고 Azure Storage의 VHD와 동기화하는 작업을 적극적으로 개입하여 수행하게 됩니다.


결론을 이야기하면, 쓰기 작업이 많은 응용프로그램을 위해 디스크를 추가할 때는 읽기/쓰기 캐시 사용을, 웹 사이트나 읽기 작업이 많은 응용프로그램을 위해서는 읽기 캐시 사용을 권할 수 있습니다.


사실 클라우드 서비스를 사용한다는 것이 어떤 의미인지 본질적으로 잘 이해하고 계시다면, 그리고 필연적으로 사람이 하는 일에 있을 수 있는 결함성을 인정하신다면, 이러한 아키텍처 속에서 갑작스럽게 나타날 수 있는 예외 상황은 항상 관리해야 할 리스크가 될 수 있습니다.


적절한 설정을 확인하고 검증하는 단계를 통해 더 성공적으로 클라우드 서비스를 현업에 투입할 수 있게 될 것입니다.


 

댓글 남기기