2021.08.05

블로그 | '대화가 필요한' 클라우드 데이터베이스와 클라우드 인프라

David Linthicum | InfoWorld
개발팀과 배치팀 대부분은 이전보다는 클라우드 컴퓨팅 관련 작업을 잘한다. 또한 애자일과 데브옵스/데브섹옵스의 부상으로 운영팀과 개발팀이 좀 더 밀접하게 일할 수 있는 기반이 마련됐다. 이제 개발팀은 운영팀과 함께 일하는 데 부담을 느끼지 않는다.
 
ⓒ Getty Images Bank

하지만 이런 체계에도 빈틈은 있다. 말하자면, 클라우드 데이터베이스 설계 담당자는 인프라 아키텍트와 제대로 동기화되지 않은 것으로 보인다. 스토리지와 컴퓨트 등 클라우드 데이터베이스에 중요한 자원을 제공하는 사람인데 말이다.

이런 관계는 결국 나쁜 결과물로 이어진다. 핵심 비즈니스를 처리하는 데이터베이스가 자원이 부족해지고, 누군가의 모니터링 콘솔에 경고 메시지가 나타난 후에나 고쳐진다. 하지만 그러는 동안 데이터베이스를 제 기능을 못하고 중요한 비즈니스 트랜잭션은 타격을 받는다. 확실한 서비스 중단이 발생할 수도 있다. 트랜잭션을 처리 중에 자원이 떨어진 데이터베이스가 아무런 경고도 없이 동작을 멈추는 것이다. 이 사태는 데이터베이스 자체를 붕괴시킬 수 있기 때문에 마지막 백업만이 살 길이 된다.

문제는 클라우드 기반 데이터베이스가 모두 똑같지 않은데, 클라우드 인프라 엔지니어는 똑같다고 생각한다는 것이다. 물론 일부 서버리스 방식 데이터베이스는 필요한 자원을 자동으로 할당하고 담당자는 월말에 사용한 만큼의 비용만 내면 된다. 하지만 대부분 클라우드 데이터베이스는 인프라 담당자가 데이터베이스에 대한 상당한 지식을 갖출 것을 요구한다. 데이터베이스의 수는 물론, 용량, 필요한 스토리지의 종류, 데이터베이스 성장 속도, 데이터 캐시 사용, CPU 종류와 규모 등을 파악해야 한다.

온프레미스 데이터베이스를 구성하고 서버 규모를 잡는 것과 너무 비슷하게 느껴질 것이다. 사실이 그렇다. 인기있는 전통 데이터베이스 중 다수가 여전히 온프레미스와 퍼블릭 클라우드를 구분하지 않는다. 그래서 특정 데이터베이스를 위한 시스템 규모를 설정하고 사용량을 가정하는 과정은 거의 같다.

해법은 모두가 알고 있다. 진짜 문제는 실제로 데이터베이스를 운영할 때 발생한다. 클라우드 기반 데이터베이스를 설계하고 구성하고 배치하는 담당자와 데이터베이스가 필요로 하는 자원을 관장하는 담당자 간의 커뮤니케이션이 깨질 때가 있기 때문이다. 충분히 피할 수 있는 데이터베이스 중단 사태가 필요 이상으로 발생하고, 비즈니스에 부정적인 영향을 미치게 되는 이유이다.

문제를 바로잡는 것은 쉽다. 특정 데이터베이스를 선정하고 배치하는 개발 및 운영 프로세스에 세부 요구사항에 대해 자원을 할당하고 구성하는 인프라팀과 커뮤니케이션하는 단계를 추가한다. 이 단계는 데이터베이스의 보안과 거버넌스, 관리 문제를 해결할 시간으로, 다른 이해관계 부서와도 이야기할 수 있는 시간이 된다.

데이터베이스 담당자에게는 미안하지만, 필자의 해법은 이렇다. 데이터베이스 관리자와 인프라 관리자가 두 부서의 커뮤니케이션이 공생 관계라고 생각하는 것이다. 하지만 데이터베이스 구현을 책임지는 사람은 인프라 담당자보다는 좀 더 주의를 기울여야 하며, 좀 더 적극적으로 나서야 한다. 

컴퓨팅이나 스토리지 자원을 넉넉하게 구매하던 시절은 지나갔다. 필요한 만큼 딱 맞게 자원을 가져오는 것이 중요하며, 자원이 다 떨어져 갈 때도 마찬가지다. 이 일은 데이터베이스 담당자가 해야 하며, 클라우드 인프라 담당자의 지원이 필수적이다. 

특히 데이터베이스 담당자는 자사의 퍼블릭 클라우드 호스트가 내부적으로 어떻게 동작하는지를 좀 더 잘 파악할 필요가 있다. 온프레미스 데이터베이스가 중심인 환경에서는 퍼블릭 클라우드와 온프레미스 데이터베이스는 섞이지 않았다. 이제 두 데이터베이스가 함께 동작하도록 해야 한다. editor@itworld.co.kr



2021.08.05

블로그 | '대화가 필요한' 클라우드 데이터베이스와 클라우드 인프라

David Linthicum | InfoWorld
개발팀과 배치팀 대부분은 이전보다는 클라우드 컴퓨팅 관련 작업을 잘한다. 또한 애자일과 데브옵스/데브섹옵스의 부상으로 운영팀과 개발팀이 좀 더 밀접하게 일할 수 있는 기반이 마련됐다. 이제 개발팀은 운영팀과 함께 일하는 데 부담을 느끼지 않는다.
 
ⓒ Getty Images Bank

하지만 이런 체계에도 빈틈은 있다. 말하자면, 클라우드 데이터베이스 설계 담당자는 인프라 아키텍트와 제대로 동기화되지 않은 것으로 보인다. 스토리지와 컴퓨트 등 클라우드 데이터베이스에 중요한 자원을 제공하는 사람인데 말이다.

이런 관계는 결국 나쁜 결과물로 이어진다. 핵심 비즈니스를 처리하는 데이터베이스가 자원이 부족해지고, 누군가의 모니터링 콘솔에 경고 메시지가 나타난 후에나 고쳐진다. 하지만 그러는 동안 데이터베이스를 제 기능을 못하고 중요한 비즈니스 트랜잭션은 타격을 받는다. 확실한 서비스 중단이 발생할 수도 있다. 트랜잭션을 처리 중에 자원이 떨어진 데이터베이스가 아무런 경고도 없이 동작을 멈추는 것이다. 이 사태는 데이터베이스 자체를 붕괴시킬 수 있기 때문에 마지막 백업만이 살 길이 된다.

문제는 클라우드 기반 데이터베이스가 모두 똑같지 않은데, 클라우드 인프라 엔지니어는 똑같다고 생각한다는 것이다. 물론 일부 서버리스 방식 데이터베이스는 필요한 자원을 자동으로 할당하고 담당자는 월말에 사용한 만큼의 비용만 내면 된다. 하지만 대부분 클라우드 데이터베이스는 인프라 담당자가 데이터베이스에 대한 상당한 지식을 갖출 것을 요구한다. 데이터베이스의 수는 물론, 용량, 필요한 스토리지의 종류, 데이터베이스 성장 속도, 데이터 캐시 사용, CPU 종류와 규모 등을 파악해야 한다.

온프레미스 데이터베이스를 구성하고 서버 규모를 잡는 것과 너무 비슷하게 느껴질 것이다. 사실이 그렇다. 인기있는 전통 데이터베이스 중 다수가 여전히 온프레미스와 퍼블릭 클라우드를 구분하지 않는다. 그래서 특정 데이터베이스를 위한 시스템 규모를 설정하고 사용량을 가정하는 과정은 거의 같다.

해법은 모두가 알고 있다. 진짜 문제는 실제로 데이터베이스를 운영할 때 발생한다. 클라우드 기반 데이터베이스를 설계하고 구성하고 배치하는 담당자와 데이터베이스가 필요로 하는 자원을 관장하는 담당자 간의 커뮤니케이션이 깨질 때가 있기 때문이다. 충분히 피할 수 있는 데이터베이스 중단 사태가 필요 이상으로 발생하고, 비즈니스에 부정적인 영향을 미치게 되는 이유이다.

문제를 바로잡는 것은 쉽다. 특정 데이터베이스를 선정하고 배치하는 개발 및 운영 프로세스에 세부 요구사항에 대해 자원을 할당하고 구성하는 인프라팀과 커뮤니케이션하는 단계를 추가한다. 이 단계는 데이터베이스의 보안과 거버넌스, 관리 문제를 해결할 시간으로, 다른 이해관계 부서와도 이야기할 수 있는 시간이 된다.

데이터베이스 담당자에게는 미안하지만, 필자의 해법은 이렇다. 데이터베이스 관리자와 인프라 관리자가 두 부서의 커뮤니케이션이 공생 관계라고 생각하는 것이다. 하지만 데이터베이스 구현을 책임지는 사람은 인프라 담당자보다는 좀 더 주의를 기울여야 하며, 좀 더 적극적으로 나서야 한다. 

컴퓨팅이나 스토리지 자원을 넉넉하게 구매하던 시절은 지나갔다. 필요한 만큼 딱 맞게 자원을 가져오는 것이 중요하며, 자원이 다 떨어져 갈 때도 마찬가지다. 이 일은 데이터베이스 담당자가 해야 하며, 클라우드 인프라 담당자의 지원이 필수적이다. 

특히 데이터베이스 담당자는 자사의 퍼블릭 클라우드 호스트가 내부적으로 어떻게 동작하는지를 좀 더 잘 파악할 필요가 있다. 온프레미스 데이터베이스가 중심인 환경에서는 퍼블릭 클라우드와 온프레미스 데이터베이스는 섞이지 않았다. 이제 두 데이터베이스가 함께 동작하도록 해야 한다. editor@itworld.co.kr

X