2017.07.25

블로그 | 클라우드 애플리케이션이 느린 이유는 클라우드 때문이 아니다

David Linthicum | InfoWorld
아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다.

이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가?

사실은 그렇지 않다.

필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다.

하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자.

“엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.”

퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다.

현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다.

이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케이션이 부분적으로 클라우드 네이티브 기능을 이용하도록 하는 작업이 포함된다. 예를 들어 네이티브 I/O나 데이터베이스 캐시 등 애플리케이션이 클라우드 상에서 더 잘 구동하도록 만드는 여러 가지 기법이 필요하다.

필자는 클라우드를 무조건 지지하는 사람은 아니다. 하지만 클라우드로 이전할 때 엉성하게 설계된 애플리케이션을 재설계할 시간을 반드시 확보하기 바란다. 그렇지 않으면 아무리 일찍 출근해도 느린 클라우드 애플리케이션은 빨라지지 않을 것이다.  editor@itworld.co.kr



2017.07.25

블로그 | 클라우드 애플리케이션이 느린 이유는 클라우드 때문이 아니다

David Linthicum | InfoWorld
아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다.

이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가?

사실은 그렇지 않다.

필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다.

하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자.

“엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.”

퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다.

현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다.

이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케이션이 부분적으로 클라우드 네이티브 기능을 이용하도록 하는 작업이 포함된다. 예를 들어 네이티브 I/O나 데이터베이스 캐시 등 애플리케이션이 클라우드 상에서 더 잘 구동하도록 만드는 여러 가지 기법이 필요하다.

필자는 클라우드를 무조건 지지하는 사람은 아니다. 하지만 클라우드로 이전할 때 엉성하게 설계된 애플리케이션을 재설계할 시간을 반드시 확보하기 바란다. 그렇지 않으면 아무리 일찍 출근해도 느린 클라우드 애플리케이션은 빨라지지 않을 것이다.  editor@itworld.co.kr

X