사내 서버를 AWS로 옮기기 전에, 무엇을 먼저 정해야 합니까

사내 서버실의 장비가 오래됐거나, 가상화 장비의 구독 조건이 바뀌었거나, 지사에서 본사 시스템을 여는 일이 잦아졌을 때 클라우드로 옮기는 이야기가 나옵니다. 그리고 대화는 대개 곧장 방법으로 넘어갑니다 — 어떤 도구로 옮기는지, 얼마나 걸리는지, 얼마인지.

이 글은 그 앞자리를 다룹니다. 옮기는 방법은 여러 개가 있고 그중 무엇을 쓸지는 환경을 봐야 정해지지만, 그 전에 고객이 정해 두지 않으면 누구도 대신 정할 수 없는 것이 넷 있습니다. 무엇을 풀려고 옮기는지, 지금 그대로 옮길 수 있는 상태인지, 언제 멈춰도 되는지, 어긋났을 때 어디로 돌아가는지입니다.

이 넷이 정해져 있으면 견적서를 비교하는 일이 쉬워집니다. 정해져 있지 않으면 견적서마다 전제가 다른 채로 금액만 나란히 놓이게 되고, 그때는 가장 싼 곳이 가장 적게 하기로 한 곳일 가능성이 큽니다.

옮겨서 풀리는 문제와 옮겨도 남는 문제

먼저 확인할 것은 지금 겪는 문제의 원인이 서버가 놓인 자리에 있는가입니다.

자리를 바꿔서 풀리는 것은 자리에서 오는 문제입니다. 장비의 수명이 다해 교체 비용이 눈앞에 있는 경우, 자원이 모자란데 늘리려면 장비를 새로 사야 하는 경우, 서버실의 전원과 냉방과 물리 보안을 계속 감당해야 하는 경우, 재해가 났을 때 복구할 다른 장소가 없는 경우가 그렇습니다. 이런 문제는 자원을 늘리고 줄이는 일이 구매가 아니라 설정이 되는 환경으로 가면 성격 자체가 바뀝니다.

반대로 자리를 바꿔도 그대로 따라오는 문제가 있습니다.

• 데이터와 화면 구조에서 오는 느림 — 한 화면이 수십 번 질의를 보내고 있거나 정리되지 않은 데이터를 매번 전부 읽고 있다면, 서버가 어디에 있든 같은 일을 합니다.
• 거리에서 오는 지연 — 접속하는 사람과 서버 사이가 멀어서 생기는 느림은 서버를 옮긴다고 사라지지 않습니다. 옮긴 자리가 접속 지점에서 더 멀어지면 오히려 늘어납니다.
• 정리되지 않은 데이터 — 무엇을 남기고 무엇을 버릴지 정해지지 않은 상태는 옮기는 비용을 키우고, 옮긴 뒤에도 저장 비용으로 계속 남습니다.
• 사람과 절차의 공백 — 지금 그 서버를 아무도 설명하지 못한다면, 옮긴 뒤에도 설명하지 못합니다.

저희가 수행한 이관 가운데 옮긴 뒤에도 기대만큼 빨라지지 않아 고객이 기존 환경 유지를 선택한 건이 있고, 그 결과를 이관 사례로 그대로 공개해 두었습니다. 느림의 더 큰 원인이 데이터 정리에 있었다는 것이 그때의 결론이었습니다. 옮기는 일은 원인을 바꾸지 않습니다. 원인이 자리에 있을 때만 자리를 바꾸는 값이 나옵니다.

지금 그대로 옮길 수 있는 상태인가

두 번째로 볼 것은 조건입니다. 여기서 걸리면 이전 일정이 아니라 이전 앞의 일정이 먼저 생깁니다.

마지막 줄은 특히 미뤄지기 쉬운 항목입니다. 백업 작업이 성공했다는 표시와 그 백업으로 실제로 되살아난다는 것은 다른 사실이고, 그 차이가 어디서 생기는지는 백업이 있는데 복구가 안 되는 이유에서 따로 다룹니다.

옮기는 방식은 세 갈래로 갈립니다

방식은 크게 셋입니다. AWS 문서는 이 갈래를 더 잘게 나눠 일곱 가지로 설명하지만, 처음 판단할 때 실제로 갈리는 지점은 지금 돌아가는 것을 얼마나 그대로 두는가 하나입니다.

첫 번째 방식의 값어치는 자주 과소평가됩니다. 쓰던 것을 통째로 떠서 올리면 원래 되던 것이 안 되는 상황이 거의 생기지 않습니다. 프로그램을 다시 깔고 설정을 다시 잡는 과정에서 누락되는 것이 이전 사고의 큰 몫이기 때문입니다.

다만 첫 번째로 옮긴 상태가 최종 상태일 필요는 없습니다. 먼저 그대로 옮겨 안정된 것을 확인한 뒤, 비용과 성능을 다듬는 일을 그다음 단계로 두는 순서가 일반적입니다. 한 번에 옮기면서 동시에 개선하려는 계획이 가장 자주 어긋납니다 — 문제가 생겼을 때 옮긴 탓인지 바꾼 탓인지 가릴 수 없기 때문입니다.

무엇을 표로 만들어야 순서가 정해지는가

옮길 대상이 여럿이면 순서를 정해야 하고, 순서는 감이 아니라 표에서 나옵니다. 아래 서식을 채워 보시면 어느 것을 먼저 옮길지가 대체로 드러납니다.

같은 표에 도입 시점과 자원 사용량과 장애 이력을 나란히 놓으면 교체와 이전의 순서를 판단할 근거가 만들어집니다. 오래됐고 자원이 남고 장애가 잦은 것은 옮기기 전에 정리할 후보이고, 오래됐지만 자원이 빠듯하고 조용한 것은 옮겨서 자원을 늘려야 할 후보입니다.

순서를 정할 때 쓰는 원칙은 하나 더 있습니다. 되돌리기 쉽고 영향 범위가 좁은 것을 먼저 옮기는 것입니다. 업무에 직접 닿지 않는 영역을 먼저 옮겨 운영 방식을 확인한 뒤, 멈추면 곧바로 매출이 깎이는 영역은 확인이 끝난 다음에 계획을 따로 잡습니다.

멈춰도 되는 시간을 먼저 정합니다

이전 계획에서 가장 먼저 정해져야 하는 값은 방식도 도구도 아니라 멈춰도 되는 시간입니다. 이 값이 없으면 어떤 계획도 검증할 수 없습니다.

정하실 것은 셋입니다.

• 얼마나 멈춰도 되는가 — 몇 분인지, 몇 시간인지, 하루가 가능한지.
• 언제 멈춰도 되는가 — 야간인지 주말인지, 특정 마감일을 피해야 하는지.
• 멈춘 동안 무엇으로 버티는가 — 수기로 받아 두는지, 아예 받지 않는지.

이 셋이 정해지면 계획이 그 창 안에 들어가는지로 판정할 수 있습니다. 창이 짧으면 한 번에 넘기는 대신 나눠서 옮기게 되고, 나누면 각 단계의 중단 시간이 짧아지는 대신 전체 기간이 길어집니다. 어느 쪽이 나은지는 업무가 정합니다.

한 번에 전환일을 잡아 끊는 방식은 되돌릴 여지가 적습니다. 옛 환경과 새 환경을 얼마 동안 함께 두고 넘어가는 편이 대체로 안전한데, 그 판단이 어떤 축에서 갈리는지는 맞춤 시스템과 SaaS를 가르는 기준에서 같은 성격으로 다룹니다.

무중단을 약속하는 답에는 그 근거를 함께 물어보시는 편이 좋습니다. 멈추지 않고 넘기는 구성이 불가능하지는 않지만, 그 구성은 시스템이 그렇게 만들어져 있을 때에만 성립하고 대개 비용과 준비 기간이 함께 붙습니다. 저희는 멈추지 않는다고 약속하는 대신 멈춰도 되는 시간대를 먼저 여쭙고, 운영에 영향이 적은 범위부터 나눠서 옮깁니다.

되돌아갈 자리가 있어야 옮기는 것입니다

이전에서 가장 값이 큰 준비는 원래 환경을 살려 두는 것입니다.

원본 장비를 지우거나 끄지 않고 사본으로 옮기면, 새 환경에서 무엇이 어긋나도 어제까지 쓰던 자리가 그대로 남아 있습니다. 저희가 수행한 이관에서도 사내 원본 장비를 그대로 두고 사본으로 진행해 언제든 원래 환경으로 돌아갈 수 있는 상태를 유지했습니다.

여기서 확인하실 것은 되돌릴 수 있다는 말 자체가 아니라, 되돌리는 절차가 작업 전에 문서로 적혀 있는가입니다. 문제가 생긴 뒤에 되돌리는 방법을 정하기 시작하면 그때는 이미 선택지가 줄어 있습니다. 저희가 착수 전에 문서로 정하고 그대로 이행한다고 밝히는 것도 수행 범위와 조회 권한 사용 여부, 그리고 되돌리는 절차 이 셋입니다.

문서에 들어가야 하는 것은 다음과 같습니다.

• 무엇이 어긋나면 되돌리기로 하는가 — 판단하는 기준
• 누가 그 판단을 내리는가
• 되돌리는 데 얼마나 걸리는가
• 되돌린 뒤 원본 환경을 언제까지 유지하는가

마지막 줄이 자주 빠집니다. 원본을 언제 폐기할지 정해 두지 않으면 두 벌을 계속 유지하는 비용이 조용히 이어지고, 반대로 너무 일찍 지우면 되돌아갈 자리가 사라집니다.

옮긴 뒤에 무엇을 확인하면 끝난 것인가

서버가 켜졌다는 것은 완료가 아닙니다. 무엇을 충족하면 완료로 볼지가 적혀 있지 않으면 완료 시점에 대한 판단이 서로 달라지고, 그 차이는 대개 대금 지급 시점에 드러납니다.

확인 목록은 옮기기 전에 만들어야 합니다. 옮긴 뒤에 만들면 지금 되는 것을 기준으로 적게 됩니다. 목록에는 최소한 아래가 들어가야 합니다.

• 접속 — 쓰던 사람이 쓰던 경로로 들어가진다. 사내에서만이 아니라 실제로 쓰는 모든 위치에서 확인한다.
• 기능 — 자주 쓰는 업무 흐름을 처음부터 끝까지 한 번씩 돌려 본다.
• 데이터 — 건수와 최근 기록이 옮기기 전과 맞는다.
• 연결 — 다른 시스템과 주고받던 것이 그대로 붙는다.
• 백업 — 새 환경의 백업이 실제로 복구된다.
• 권한 — 있어야 할 사람만 들어갈 수 있고, 사내망 전제로 열려 있던 것이 밖으로 열려 있지 않다.

항목마다 담당자와 기한, 그리고 무엇을 보면 통과인지를 함께 적어 두시면 확인이 의견이 아니라 판정이 됩니다.

구성을 코드로 정의해 두면 확인의 성격이 한 번 더 바뀝니다. 같은 구성을 처음부터 다시 세워도 같은 결과가 나오는지 확인할 수 있게 되고, 그러면 그 구성은 사람의 기억이 아니라 기록에 남습니다. 저희 이관에서도 네트워크와 서버 구성을 코드로 작성해 같은 구성을 두 번 세워 재현되는 것을 확인했습니다.

옮기고 나서 새로 생기는 일

옮기는 일이 끝나면 없던 일이 하나 생깁니다. 매달 쓴 만큼 청구되는 환경을 관리하는 일입니다.

사내 장비는 사 놓으면 그 뒤로 비용이 크게 변하지 않지만, 옮긴 뒤에는 켜 둔 시간과 주고받은 데이터의 양이 그대로 금액이 됩니다. 그래서 옮긴 직후에는 무엇이 얼마를 쓰고 있는지 보는 습관을 먼저 만드셔야 하고, 청구액이 갑자기 늘었을 때 어디를 보는지는 AWS 비용이 갑자기 오르는 원인이 항목별로 다룹니다.

두 번째로 생기는 일은 운영입니다. 옮기고 나면 장비를 만질 일은 없어지지만 상태를 보고 판단하는 일은 그대로 남고, 오히려 늘어나는 경우도 있습니다. 그 일을 직접 할지 맡길지, 맡긴다면 어느 폭까지 맡길지는 자체 운영과 위탁의 총비용과 어느 수준으로 계약할 것인가가 각각 다룹니다.

한 가지만 미리 갈라 두시면 좋습니다. 옮기는 일과 옮긴 뒤 운영하는 일은 다른 계약입니다. 옮기는 일은 정해진 범위와 끝이 있는 작업이고, 운영은 끝나는 시점 없이 이어지는 계약입니다. 이 둘을 한 줄로 묶어 받은 견적서는 나중에 무엇이 끝났고 무엇이 이어지는지를 가리기 어렵게 만듭니다.

다음 단계

옮길지 말지를 아직 정하지 못하셨다면, 먼저 지금 환경에서 무엇이 문제인지부터 정리하시는 편이 순서에 맞습니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 지금 구조에서 무엇부터 봐야 하는지를 정리해 드립니다. 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

옮기는 쪽으로 방향을 정하셨다면 AWS 구축 · 이전에서 설계와 이전의 범위를 확인하실 수 있고, 옮긴 뒤의 구성이 대략 얼마가 될지 먼저 가늠해 보고 싶으시면 AWS 비용 계산기로 연락처 없이 계산해 보실 수 있습니다.

옮긴 구성이 화면에서 어떻게 보이는지 먼저 눌러 보고 싶으시면 아래 데모를 열어 보시고, 지금 환경을 놓고 옮기는 안과 지금 자리에서 다듬는 안을 함께 비교해 보고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS 마이그레이션 전략 — 7가지 이전 방식
• AWS Application Migration Service 개요
• AWS VM Import/Export — 가상 머신 이미지 가져오기
• AWS Well-Architected — 안정성 원칙