AWS에서 Google Cloud로 마이그레이션: Amazon EC2에서 Compute Engine으로 마이그레이션

Last reviewed 2024-11-20 UTC

Google Cloud는 Amazon Elastic Compute Cloud(Amazon EC2)의 데이터와 함께 가상 머신(VM)을 Compute Engine으로 마이그레이션하는 도구, 제품, 가이드, 전문 서비스를 제공합니다. 이 문서에서는 Amazon EC2에서 Compute Engine으로의 마이그레이션 계획을 설계, 구현, 검증하는 방법을 설명합니다.

이 문서의 설명은 마이그레이션 프로세스를 계획하고 구현하는 방법에 대한 세부정보를 원하는 클라우드 관리자를 대상으로 합니다. 또한 마이그레이션 기회를 평가하고 마이그레이션 과정을 살펴보려는 의사 결정권자를 대상으로 작성되었습니다.

이 문서는 AWS에서 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부로서 이 시리즈에는 다음 문서가 포함됩니다.

Google Cloud로의 마이그레이션의 경우 Google Cloud로 마이그레이션: 시작하기에 설명된 마이그레이션 프레임워크를 따르는 것이 좋습니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

일련의 반복 작업을 통해 원본 환경에서 Google Cloud로 마이그레이션할 수 있습니다. 예를 들어 일부 워크로드를 먼저 마이그레이션하고 나중에 다른 워크로드를 마이그레이션할 수 있습니다. 개별 마이그레이션을 반복할 때마다 일반 마이그레이션 프레임워크 단계를 수행합니다.

  1. 워크로드와 데이터를 평가하고 탐색합니다.
  2. Google Cloud에 대한 기초를 계획하고 빌드합니다.
  3. 워크로드와 데이터를 Google Cloud로 마이그레이션합니다.
  4. Google Cloud 환경을 최적화합니다.

이 프레임워크 단계에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

효과적인 마이그레이션 계획을 설계하려면 계획의 각 단계를 검증하고 롤백 전략이 있는지 확인하는 것이 좋습니다. 마이그레이션 계획을 검증하려면 Google Cloud로 마이그레이션: 마이그레이션 계획 검증 권장사항을 참조하세요.

원본 환경 평가

평가 단계에서는 원본 환경을 Google Cloud로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

평가 단계는 마이그레이션의 성공에 매우 중요합니다. 마이그레이션하려는 워크로드, 요구사항, 종속 항목, 현재 환경에 대해 자세히 알고 있어야 합니다. Google Cloud 마이그레이션을 성공적으로 계획하고 실행하려면 시작점을 이해해야 합니다.

평가 단계는 다음 작업으로 구성됩니다.

  1. 워크로드의 포괄적인 인벤토리를 빌드합니다.
  2. 워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에서 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총 소유 비용(TCO)을 계산합니다.
  6. 워크로드에 적합한 마이그레이션 전략을 선택합니다.
  7. 마이그레이션 도구를 선택합니다.
  8. 마이그레이션 계획 및 타임라인을 정의합니다.
  9. 마이그레이션 계획을 검증합니다.

평가 단계와 이러한 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요. 다음 섹션은 해당 문서의 정보를 기반으로 합니다.

Amazon EC2 인스턴스의 인벤토리 빌드

마이그레이션 범위를 지정하려면 Amazon EC2 인스턴스의 인벤토리를 만듭니다. 그런 다음 인벤토리를 사용하여 해당 인스턴스에 워크로드를 배포하기 위한 배포 및 운영 프로세스를 평가할 수 있습니다.

Amazon EC2 인스턴스의 인벤토리를 빌드하려면 현재 환경에서 Google Cloud까지의 엔드 투 엔드 클라우드 여정을 가속화하는 데 도움이 되는 Google Cloud의 통합 플랫폼인 Migration Center를 사용하는 것이 좋습니다. Migration Center를 사용하면 Amazon EC2 및 기타 AWS 리소스에서 데이터를 가져올 수 있습니다. 그러면 Migration Center에서 마이그레이션할 수 있는 관련 Google Cloud 서비스를 권장합니다.

Migration Center를 사용하여 환경을 평가한 후에는 Migration Center 탐색 클라이언트 CLI를 사용하여 기술 마이그레이션 평가 보고서를 생성하는 것이 좋습니다. 자세한 내용은 오프라인 평가를 위해 Amazon EC2 인스턴스에서 게스트 데이터 수집을 참조하세요.

Migration Center와 Migration Center 탐색 클라이언트 CLI가 제공하는 데이터는 원하는 측정기준을 완전히 캡처하지 못할 수 있습니다. 이 경우 이 데이터를 AWS API, AWS 개발자 도구, AWS 명령줄 인터페이스를 기반으로 하는 사용자가 만든 다른 데이터 수집 메커니즘의 결과와 통합하면 됩니다.

Migration Center 및 Migration Center 탐색 클라이언트 CLI에서 가져오는 데이터 외에도 마이그레이션하려는 각 Amazon EC2 인스턴스에서 다음 데이터 포인트를 고려합니다.

  • 배포 리전 및 영역
  • 인스턴스 유형 및 크기입니다.
  • 인스턴스가 시작되는 Amazon Machine Image(AMI)
  • 인스턴스 호스트 이름 및 다른 인스턴스와 워크로드가 이 호스트 이름을 사용하여 인스턴스와 통신하는 방법입니다.
  • 인스턴스 태그 및 메타데이터 및 사용자 데이터
  • 인스턴스 가상화 유형
  • 인스턴스 구매 옵션(예: 주문형 구매 또는 스팟 구매)입니다.
  • 인스턴스 스토어 및 Amazon EBS 볼륨 사용과 같이 인스턴스가 데이터를 저장하는 방법
  • 인스턴스 테넌시 구성
  • 인스턴스가 특정 게재위치 그룹에 있는지 여부
  • 인스턴스가 특정 자동 확장 그룹에 있는지 여부
  • 인스턴스가 속한 보안 그룹
  • 인스턴스와 관련된 모든 AWS 네트워크 방화벽 구성
  • 인스턴스에서 실행되는 워크로드가 AWS Shield와 AWS WAF로 보호되는지 여부
  • 인스턴스의 프로세서 상태를 제어할지 여부와 인스턴스에서 실행되는 워크로드가 프로세서 상태에 따라 달라지는 방식
  • 인스턴스 I/O 스케줄러의 구성
  • 인스턴스에서 실행되는 워크로드를 AWS 환경에서 실행되는 클라이언트(예: 다른 워크로드) 및 외부 클라이언트에 노출하는 방법

배포 및 운영 프로세스 평가

배포 및 운영 프로세스의 작동 방식을 명확하게 이해하는 것이 중요합니다. 이러한 프로세스는 프로덕션 환경과 그 환경에서 실행되는 워크로드를 준비하고 유지관리하는 관행의 중요한 부분입니다.

배포 및 운영 프로세스에서 워크로드가 작동하는 데 필요한 아티팩트를 빌드할 수 있습니다. 따라서 각 아티팩트 유형에 대한 정보를 수집해야 합니다. 예를 들어 아티팩트는 운영체제 패키지, 애플리케이션 배포 패키지, 운영체제 이미지, 컨테이너 이미지 등일 수 있습니다.

아티팩트 유형 외에도 다음 태스크를 완료하는 방법을 고려하세요.

  • 워크로드 개발. 개발팀이 워크로드를 빌드하기 위해 마련한 프로세스를 평가합니다. 예를 들어 개발팀이 워크로드를 어떻게 설계, 코딩, 테스트하는지 평가합니다.
  • 원본 환경에 배포하는 아티팩트 생성. 원본 환경에 워크로드를 배포하기 위해 컨테이너 이미지 또는 운영체제 이미지와 같은 배포 가능한 아티팩트를 생성하거나 소프트웨어를 설치 및 구성하여 제3자 운영체제 이미지와 같은 기존 아티팩트를 맞춤설정할 수 있습니다. 이러한 아티팩트를 생성하는 방법에 대한 정보를 수집하면 생성된 아티팩트가 Google Cloud 배포에 적합한지 확인하는 데 도움이 됩니다.

  • 아티팩트 저장. AWS의 Artifact Registry에 저장하는 아티팩트를 생성하는 경우 Google Cloud 환경에서 아티팩트를 사용할 수 있도록 해야 합니다. 다음과 같은 전략을 사용하면 수행할 수 있습니다.

    • 환경 간 통신 채널 설정: 원본 환경의 아티팩트를 대상 Google Cloud 환경에서 연결할 수 있도록 합니다.
    • 아티팩트 빌드 프로세스 리팩터링: 원본 환경과 대상 환경 모두에 아티팩트를 저장할 수 있도록 원본 환경의 마이너 리팩터링을 완료합니다. 이 방식은 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하기 전에 아티팩트 저장소와 같은 인프라를 빌드하여 마이그레이션을 지원합니다. 이 접근 방식을 직접 구현하거나 통신 채널을 먼저 설정하는 이전의 접근 방식으로 빌드할 수 있습니다.

    원본 환경과 대상 환경 모두에서 아티팩트를 사용할 수 있으면 마이그레이션의 일환으로 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하지 않고도 마이그레이션에 집중할 수 있습니다.

  • 코드 스캔 및 서명. 아티팩트 빌드 프로세스의 일부로 코드 스캔을 사용하여 일반적인 취약점과 의도하지 않은 네트워크 노출을 방지하고, 코드 서명을 사용하여 신뢰할 수 있는 코드만 환경에서 실행되도록 할 수 있습니다.

  • 원본 환경에 아티팩트 배포. 배포 가능한 아티팩트를 생성한 후 원본 환경에 배포할 수 있습니다. 각 배포 프로세스를 평가하는 것이 좋습니다. 이 평가는 배포 프로세스가 Google Cloud와 호환되는지 확인하는 데 도움이 됩니다. 또한 프로세스를 리팩터링하는 데 필요한 노력을 파악하는 데도 도움이 됩니다. 예를 들어 배포 프로세스가 원본 환경에서만 작동하는 경우 Google Cloud 환경을 타겟팅하도록 이를 리팩터링해야 할 수 있습니다.

  • 런타임 구성 삽입. 특정 클러스터, 런타임 환경 또는 워크로드 배포에 대한 런타임 구성을 삽입할 수 있습니다. 이 구성으로 환경 변수와 보안 비밀, 사용자 인증 정보, 키와 같은 기타 구성 값이 초기화될 수 있습니다. 런타임 구성 삽입 프로세스가 Google Cloud에서 작동하는지 확인하려면 원본 환경에서 실행되는 워크로드를 구성하는 방법을 평가하는 것이 좋습니다.

  • 로깅, 모니터링, 프로파일링. 원본 환경의 상태, 관심 측정항목, 이러한 프로세스에서 제공하는 데이터 사용 방식을 모니터링하기 위해 마련한 로깅, 모니터링, 프로파일링 프로세스를 평가합니다.

  • 인증 원본 환경에 대해 인증하는 방법을 평가합니다.

  • 리소스 프로비저닝 및 구성. 원본 환경을 준비하기 위해 리소스를 프로비저닝하고 구성하는 프로세스를 설계하고 구현했을 수 있습니다. 예를 들어 구성 관리 도구와 함께 Terraform을 사용하여 원본 환경에서 리소스를 프로비저닝하고 구성할 수 있습니다.

기반 계획 및 빌드

계획 및 빌드 단계에서는 다음을 수행하도록 인프라를 프로비저닝하고 구성합니다.

  • Google Cloud 환경에서 워크로드를 지원합니다.
  • 원본 환경과 Google Cloud 환경을 연결하여 마이그레이션을 완료합니다.

계획 및 빌드 단계는 다음과 같은 태스크로 구성됩니다.

  1. 리소스 계층 구조를 빌드합니다.
  2. Google Cloud의 Identity and Access Management(IAM)를 구성합니다.
  3. 결제 설정.
  4. 네트워크 연결을 설정합니다.
  5. 보안을 강화합니다.
  6. 로깅, 모니터링, 알림을 설정합니다.

각 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기반 계획 및 빌드를 참조하세요.

워크로드 마이그레이션

Amazon EC2에서 Compute Engine으로 워크로드를 마이그레이션하려면 다음 단계를 따르세요.

  1. Amazon EC2에서 Compute Engine으로 VM을 마이그레이션합니다.
  2. VM 디스크를 영구 디스크로 이전합니다.
  3. Compute Engine에서 실행되는 워크로드를 클라이언트에 노출합니다.
  4. Amazon EC2를 타겟팅하는 대신 Google Cloud를 타겟팅하도록 배포 및 운영 프로세스를 리팩터링합니다.

다음 섹션에서는 이러한 각 작업에 대해 자세히 설명합니다.

VM을 Compute Engine으로 이전

Amazon EC2에서 Compute Engine으로 VM을 마이그레이션하려면 완전 관리형 서비스인 Migrate to Virtual Machines를 사용하는 것이 좋습니다. 자세한 내용은 Migrate to VMs를 사용한 마이그레이션 여정을 참조하세요.

마이그레이션 과정에서 Migrate for VM은 필수 구성 변경을 수행할 뿐만 아니라 Amazon EC2 인스턴스를 현재 상태로 마이그레이션합니다. Amazon EC2 인스턴스에서 맞춤설정된 Amazon EC2 AMI를 실행하는 경우 Migrate to Virtual Machines는 이러한 맞춤설정을 Compute Engine 인스턴스로 마이그레이션합니다. 하지만 인프라를 재현 가능하게 만들려면 나중에 이 문서의 뒷부분에서 설명하는 대로 배포 및 운영 프로세스의 일부로서 Compute Engine 운영체제 이미지를 빌드함으로써 동급의 맞춤설정을 적용해야 할 수 있습니다. Amazon EC2 AMI를 Compute Engine으로 가져올 수도 있습니다.

VM 디스크를 Persistent Disk로 마이그레이션

Migrate to VMs를 사용하여 소스 Amazon EC2 VM에서 영구 디스크로 디스크를 마이그레이션할 수도 있습니다. 이때 Amazon EC2 VM에서 실행 중인 워크로드의 중단을 최소화할 수 있습니다. 자세한 내용은 VM 디스크를 마이그레이션하고 새 VM에 연결을 참고하세요.

예를 들어 Amazon EC2 VM에 연결된 데이터 디스크를 영구 디스크로 이전하고 새 Compute Engine VM에 연결할 수 있습니다.

Compute Engine에서 실행되는 워크로드 노출

Amazon EC2 인스턴스를 Compute Engine 인스턴스로 마이그레이션한 후에는 워크로드를 클라이언트에 노출하도록 Google Cloud 환경을 프로비저닝하고 구성해야 할 수 있습니다.

Google Cloud는 워크로드를 클라이언트에 노출하기 위한 안전하고 안정적인 서비스와 제품을 제공합니다. Compute Engine 인스턴스에서 실행되는 워크로드의 경우 다음 카테고리의 리소스를 구성합니다.

  • 방화벽
  • 트래픽 부하 분산
  • DNS 이름, 영역, 레코드
  • DDoS 보호 및 웹 애플리케이션 방화벽

이러한 각 카테고리의 경우, 상응하는 카테고리의 AWS 서비스 및 리소스를 구성한 방식과 유사한 기준 구성을 구현하는 것으로 시작할 수 있습니다. 그런 다음 구성을 반복하고 Google Cloud 서비스에서 제공하는 추가 기능을 사용할 수 있습니다.

다음 섹션에서는 이러한 카테고리의 Google Cloud 리소스를 프로비저닝하고 구성하는 방법과 이러한 리소스가 유사한 카테고리의 AWS 리소스에 매핑되는 방식을 설명합니다.

방화벽

AWS 보안 그룹과 AWS 네트워크 방화벽 정책 및 규칙을 구성한 경우 Cloud 차세대 방화벽 정책 및 규칙을 구성할 수 있습니다. VPC 서비스 제어 규칙을 프로비저닝하여 VPC 내부의 네트워크 트래픽을 규제할 수도 있습니다. VPC 서비스 제어를 사용하여 Compute Engine 인스턴스에 대한 원치 않는 네트워크 연결을 차단하고 데이터 무단 반출 위험을 완화할 수 있습니다.

예를 들어 AWS 보안 그룹을 사용하여 Amazon EC2 인스턴스에 대한 연결을 허용하거나 거부하는 경우, Compute Engine 인스턴스에 적용되는 Virtual Private Cloud (VPC) 방화벽 규칙을 구성할 수 있습니다.

트래픽 부하 분산

AWS 환경에서 Elastic Load Balancing (ELB)을 구성한 경우 워크로드의 확장성을 향상시키기 위해 네트워크 트래픽을 분산하도록 Cloud Load Balancing을 구성할 수 있습니다. Cloud Load Balancing은 전송 레이어 및 애플리케이션 레이어 등 OSI 모델의 다양한 레이어에서 작동하는 전역 및 리전 부하 분산 제품을 지원합니다. 워크로드의 요구사항에 적합한 부하 분산 제품을 선택할 수 있습니다.

또한 Cloud Load Balancing에서는 네트워크 트래픽을 암호화하도록 전송 계층 보안(TLS)을 구성할 수 있습니다. Cloud Load Balancing에 TLS를 구성할 때는 요구사항에 따라 자체 관리형 또는 Google 관리형 TLS 인증서를 사용할 수 있습니다.

DNS 이름, 영역, 레코드

AWS 환경에서 Amazon Route 53을 사용하는 경우 Google Cloud에서 다음을 사용할 수 있습니다.

예를 들어 Amazon Route 53을 사용하여 도메인을 등록한 경우 도메인 등록을 Cloud Domains로 이전할 수 있습니다. 마찬가지로 Amazon Route 53을 사용하여 공개 DNS 영역과 비공개 DNS 영역을 구성한 경우 해당 구성을 Cloud DNS로 이전할 수 있습니다.

DDoS 보호 및 웹 애플리케이션 방화벽

AWS 환경에서 AWS Shield 및 AWS WAF를 구성한 경우 Google Cloud Armor를 사용하여 DDoS 공격 및 일반적인 악용으로부터 Google Cloud 워크로드를 보호할 수 있습니다.

배포 및 운영 프로세스 리팩토링

워크로드를 리팩터링한 후에는 배포 및 운영 프로세스를 리팩터링하여 다음을 실행합니다.

  • 소스 환경에서 리소스를 프로비저닝하는 대신 Google Cloud 환경에서 리소스를 프로비저닝하고 구성합니다.
  • 워크로드를 빌드 및 구성하고 원본 환경에 배포하는 대신 Google Cloud에 배포합니다.

이 프로세스 앞부분의 평가 단계에서는 이러한 프로세스에 대한 정보를 수집한 바 있습니다.

이러한 프로세스에 대해 고려해야 하는 리팩터링 유형은 이를 설계하고 구현한 방법에 따라 달라집니다. 리팩터링은 또한 각 프로세스에서 원하는 최종 상태에 따라 달라집니다. 예를 들어, 다음 사항을 고려해 보세요.

  • 이러한 프로세스를 소스 환경에서 구현했으며 Google Cloud에서 유사한 프로세스를 설계하고 구현하려고 할 수 있습니다. 예를 들어 이러한 프로세스를 리팩터링하여 Cloud Build ,Cloud Deploy 및Infrastructure Manager 를 사용할 수 있습니다.
  • 이러한 프로세스를 원본 환경 외부의 다른 제3자 환경에서 구현했을 수 있습니다. 이 경우 원본 환경 대신 Google Cloud 환경을 타겟팅하도록 이러한 프로세스를 리팩터링해야 합니다.
  • 앞선 접근 방식을 조합합니다.

배포 및 운영 프로세스를 리팩터링하는 작업은 복잡할 수 있으며 상당한 노력이 필요할 수 있습니다. 워크로드 이전의 일부로 이러한 작업을 수행하려고 하면 워크로드 이전이 더 복잡해지고 위험에 노출될 수 있습니다. 배포 및 운영 프로세스를 평가하면 프로세스의 설계와 복잡성을 파악할 수 있습니다. 배포 및 운영 프로세스를 리팩터링하는 데 상당한 노력이 필요하다고 판단되면 별도의 전용 프로젝트의 일부로 이러한 프로세스를 리팩터링하는 것이 좋습니다.

Google Cloud에서 배포 프로세스를 설계하고 구현하는 방법에 관한 자세한 내용은 다음을 참고하세요.

이 문서에서는 배포할 아티팩트를 생성하고 대상 런타임 환경에 배포하는 배포 프로세스에 중점을 둡니다. 리팩터링 전략은 이러한 프로세스의 복잡성에 따라 크게 달라집니다. 다음 목록은 가능한 일반적인 리팩터링 전략을 간략히 보여줍니다.

  1. Google Cloud에서 아티팩트 저장소를 프로비저닝합니다. 예를 들어 Artifact Registry를 사용하여 아티팩트와 빌드 종속 항목을 저장할 수 있습니다.
  2. 원본 환경과 Artifact Registry 모두에 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
  3. 대상 Google Cloud 환경에 워크로드를 배포하도록 배포 프로세스를 리팩터링합니다. 예를 들어 먼저 Artifact Registry에 저장된 아티팩트를 사용하여 Google Cloud에 워크로드의 일부를 배포합니다. 그런 다음 마이그레이션할 모든 워크로드가 Google Cloud에서 실행될 때까지 Google Cloud에 배포된 워크로드 수를 점차 늘립니다.
  4. Artifact Registry에만 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
  5. 필요한 경우 배포할 이전 버전의 아티팩트를 원본 환경의 저장소에서 Artifact Registry로 마이그레이션합니다. 예를 들어 컨테이너 이미지를 Artifact Registry에 복사할 수 있습니다.
  6. 더 이상 필요하지 않으면 원본 환경에서 저장소를 사용 중단합니다.

마이그레이션 중 예기치 않은 문제로 인한 최종 롤백을 용이하게 하기 위해 Google Cloud로 마이그레이션이 진행되는 동안 Google Cloud의 현재 아티팩트 저장소에 컨테이너 이미지를 저장할 수 있습니다. 마지막으로 원본 환경을 지원 중단하는 과정에서 컨테이너 이미지 빌드 프로세스를 리팩터링하여 Google Cloud에만 아티팩트를 저장할 수 있습니다.

마이그레이션의 성공에 중요하지 않을 수도 있지만 이전 버전의 아티팩트를 원본 환경에서 Google Cloud의 아티팩트 저장소로 마이그레이션해야 할 수 있습니다. 예를 들어 워크로드를 임의의 시점으로 롤백하는 기능을 지원하려면 이전 버전의 아티팩트를 Artifact Registry로 마이그레이션해야 할 수 있습니다. 자세한 내용은 서드 파티 레지스트리에서 이미지 마이그레이션을 참조하세요.

Artifact Registry를 사용하여 아티팩트를 저장하는 경우 액세스 제어, 데이터 무단 반출 방지, 취약점 스캔, Binary Authorization과 같은 아티팩트 저장소를 보호하는 데 도움이 되는 제어 기능을 구성하는 것이 좋습니다. 자세한 내용은 액세스 제어 및 아티팩트 보호를 참조하세요.

Google Cloud 환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 대상 환경이 최적화 요구사항을 충족할 때까지 최적화 태스크를 반복합니다. 각 반복 단계는 다음과 같습니다.

  1. 현재 환경, 팀 및 최적화 루프를 평가합니다.
  2. 최적화 요구사항 및 목표를 설정합니다.
  3. 환경 및 팀을 최적화합니다.
  4. 최적화 루프를 조정합니다.

최적화 목표에 도달할 때까지 이 순서를 반복합니다.

Google Cloud 환경 최적화에 대한 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화 및 성능 최적화 프로세스를 참조하세요.

다음 단계

참여자

작성자: 마르코 페라리 | 클라우드 솔루션 설계자