어쨋든 Public Cloud에서는 AWS가 1위고, Azure가 2위입니다. 그러나, 이러한 수치 뿐만이 아니라, 각각의 Cloud마다의 특성이 존재하고, 어떠한 프로젝트를 운영할 때, 그 특성에 맞는 Cloud를 선택하는게 맞는것 같습니다.(물론 전 AWS가 좋다고 생각을 합니다.) 다만, 운이 좋게 Azure의 IaaS를 많이 사용할 기회가 생겨서 사용하던 중, Azure의 재미있는 특성(이라고 말하고 미친듯이 삽질을 했던 경험이라고 씁니다.)을 몇가지 소개해 드리면서 소견을 말씀드리겠습니다.
1. Azure의 VM Socket Idle Timeout
많은 삽질을 한 TCP Idle timeout입니다. 현재 Azure는 VM의 TCP idle timeout은 4분 ~ 30분(default : 4분)입니다. Linux 자체의 tcp_keepalive_time이 7200초(2시간)인데 비하여 현저히 짧은 시간입니다. 물론 이 설정은 Linux 자체가 아무리 tcp_keepalive_time을 높게 설정해도 끊기게 됩니다.
참고 : https://azure.microsoft.com/ko-kr/documentation/articles/load-balancer-tcp-idle-timeout/
2. Azure의 Concurrent Connection Limitation
사실 위에 있는것은 Portal에 있어서 눈여겨 보지 않아서 생긴 삽질일 수 있습니다. 하지만 Concurrent Connection Limitation은 약간은 놀랍습니다.
https://azure.microsoft.com/ko-kr/documentation/articles/azure-subscription-service-limits/
다음과 같은 페이지에서 확인하면 Concurrent Connection Limitation을 확인할 수 있습니다.
현재 Azure의 VM당 최대 TCP Concurrent Connection은 50만입니다. 50만이면 많다고 하면 많은 양일 수 있지만, VM에 Load Balancer를 올리게 되면 아무리 해도 25만 Connection 밖에 연결할 수 없다는 것이 되기 때문에 HAProxy와 같은 Load Balancer는 사실상 못올린다고 볼 수 있습니다. 사실 25만 Connection은 많은 양은 아니기 때문이죠.
이러한 IaaS의 특성을 보게 되면 Azure는 연결 지향성이 뛰어난 Cloud는 아니라는 생각이 듭니다. 물론 Microsoft에서 계속 말하는 Reactive System과 Stateless가 Cloud에서 매우 유리한 강점을 갖고는 있지만, Azure상에서 연결 지향적인 서비스를 구축하는것은 쉽지 않아보입니다.