당신이 인생의 사랑을 만났던 그 시절을 떠올려 보세요. 감정은 서로 같았습니다. 세상은 더 나은 곳처럼 보였고, 당신은 중요한 사람과 함께 흥미진진한 여정을 하고 있었습니다. 당신들은 함께 삶을 계획하며 “모두 다 들어갔다”고 할 수 있었습니다.
인생은 놀라웠습니다… 그때까지는.
일이 계획대로 되지 않을 때, 관계를 정리하는 힘든 작업을 해야 합니다. 서로와 다른 사람들과 소통하고, 공동 구매를 정리하고, 앞으로 나아가는 것입니다. 아휴.
믿거나 말거나, 우리와 기술과의 관계도 크게 다르지 않습니다.
서비스와의 이별
여러분이 서비스를 채택하기로 결정했던 시절이 있었습니다. 아마 SaaS, PaaS 또는 더 일반적인 서비스였을 것입니다. 예전에는 더 이상 그 서비스를 사용하지 않겠다고 생각하면서 결정을 내렸나요? 아마도 아니었을 것입니다. 여러분은 미래의 모든 멋진 가능성만을 생각하고 있었을 것입니다.
하지만 그 서비스가 더 이상 당신의 이익에 부합하지 않을 때는 어떻게 될까요? 이제 당신은 도전에 직면하게 됩니다. 그것은 서비스 포기라고 부릅니다. 서비스는 적당한 노력으로 종료할 수 있지만, 기본 데이터를 얻는 것은 문제가 될 수 있습니다. 이는 종종 서비스의 종류와 해당 서비스 제공자가 소유한 데이터의 양에 따라 다릅니다.
때때로 이상적인 정리는 이렇게 보입니다: 서비스를 중단하되, 일정 기간 동안 데이터 소스에 대한 접근을 유지하는 것입니다. 이것이 가능한 일인가요? 네, 가능합니다!
VPC 피어링의 힘
주요 클라우드 제공업체들은 리소스 간의 연결성을 구축하는 사실상의 접근 방식으로 가상 사설 클라우드 (VPC) 네트워크를 채택했습니다. 예를 들어, AWS의 EC2 인스턴스는 VPC 및 VPC 엔드포인트 서비스를 사용하여 데이터 소스에 접근할 수 있습니다. 이를 점대점 연결로 생각해 보세요.
VPC는 동일한 클라우드 제공업체의 다른 리소스에 대한 접근 권한을 부여할 수 있지만, 외부 서비스에 대한 접근 권한을 부여하는 데에도 사용할 수 있습니다. 최근에 중단된 서비스가 있지만 원래 데이터 소스는 그대로 남아 있는 상황을 고려해 보세요. 다음과 같이 보일 수 있습니다:
이 개념을 VPC 피어링이라고 하며, 다른 네트워크에서 사설 연결을 설정할 수 있게 해줍니다.
서비스 마이그레이션 예제
보다 구체적인 예제를 생각해 봅시다. 귀하의 조직에서는 클라우드에서 운영 방식을 간소화하기로 비즈니스 결정을 내렸습니다. 일부 AWS 서비스를 계속 활용하면서도, 귀하의 조직은 AWS에서 실행되는 제3자 클라우드 기반 서비스를 종료하여 애플리케이션을 구축, 배포 및 관리하는 방식을 최적화하고자 했습니다. 그들은 비용을 계산한 결과 내부 소프트웨어 엔지니어들이 Heroku에서 새 자동 확장 서비스를 구축하고 지원하는 데 드는 비용이 제3자 제공업체에 지불하던 비용의 일부에 불과하다는 결론에 도달했습니다.
그러나 서비스 제공업체와의 장기 계약으로 데이터 원본을 이전하는 것은 곧바로 선택 사항이 아닙니다. 서비스를 받고 싶지 않지만 데이터를 옮길 수 없으며 여전히 데이터에 액세스하려고 합니다. 다행히 제공업체는 데이터를 계속 호스팅하고 VPC 피어링을 통해 액세스를 제공하기로 합의했습니다.
새로운 계약은 다음과 같이 보일 것입니다:
Heroku와의 VPC 피어링
새로운 서비스(하루코 앱)가 AWS의 원본 데이터 원본에 액세스하려면 먼저 앱을 개인 스페이스 내에서 실행해야 합니다. 자세한 내용은 안전한 클라우드 채택 및 내가 하루코 프라이빗 스페이스를 발견한 것을 읽어볼 수 있습니다.
다음으로, 다음 간단한 네트워크 요구사항을 충족해야 합니다:
- VPC는 네트워크 구성에서 호환되는 IPv4 CIDR 블록을 사용해야 합니다.
- VPC는 RFC1918 CIDR 블록(
10.0.0.0/8,172.16.0.0/12, 또는192.168.0.0/16)을 사용해야 합니다. - VPC의 CIDR 블록은 개인 스페이스의 CIDR 범위와 겹치지 않아야 합니다. 기본 범위는
10.0.0.0/16,10.1.0.0/16, 그리고172.17.0.0/16입니다.
개인 스페이스가 실행되면, 피어링 정보를 검색해야 합니다:
$ heroku spaces:peering:info our-new-app
=== our-new-app Peering Info
AWS Account ID: 647xxxxxx317
AWS Region: us-east-1
AWS VPC ID: vpc-e285ab73
AWS VPC CIDR: 10.0.0.0/16
Space CIDRs: 10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20
Unavailable CIDRs: 10.1.0.0/16
AWS 계정 ID (647xxxxxx317) 및 AWS VPC ID (vpc-e285ab73)를 메모하세요. 이 정보를 AWS 데이터 소스를 제어하는 제3자 공급업체에 제공해야 합니다. 그러면 그들은 AWS 콘솔이나 CLI 중 하나를 사용하여 피어링 연결을 생성할 수 있습니다. 그들의 작업은 다음과 같을 것입니다:
$ aws ec2 create-vpc-peering-connection \
--vpc-id vpc-e527bb17 \
--peer-vpc-id vpc-e285ab73 \
--peer-owner-id 647xxxxxx317
{
"VpcPeeringConnection": {
"Status": {
"Message": "Initiating Request to 647xxxxxx317",
"Code": "initiating-request"
},
"Tags": [],
"RequesterVpcInfo": {
"OwnerId": "714xxxxxx214",
"VpcId": "vpc-e527bb17",
"CidrBlock": "10.100.0.0/16"
},
"VpcPeeringConnectionId": "pcx-123abc456",
"ExpirationTime": "2025-04-23T22:05:27.000Z",
"AccepterVpcInfo": {
"OwnerId": "647xxxxxx317",
"VpcId": "vpc-e285ab73"
}
}
}
이렇게 하면 피어링을 요청합니다. 제공업체가 이 작업을 수행한 후 Heroku 쪽에서 보류 중인 요청을 확인할 수 있습니다:
$ heroku spaces:peerings our-new-app
아래 스크린샷에서 피어링 연결의 보류-수락 상태를 볼 수 있습니다.
여기서 피어링 연결 요청을 수락할 수 있습니다:
$ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app
Accepting and configuring peering connection pcx-123abc456
요청 상태를 두 번째로 확인합니다:
$ heroku spaces:peerings our-new-app
피어 연결이 활성 상태인 것을 확인합니다.
이 시점에서 Heroku Private Space에서 실행 중인 앱은 AWS 데이터 소스에 문제없이 액세스할 수 있게 됩니다.
결론
삶에서 불행한 진실은 관계가 오래 지속되는 것만큼 종종 실패할 수 있다는 것입니다. 이는 사람에게도 적용되며 기술에도 적용됩니다.
기술 결정에 있어서 때로는 변화하는 상황과 요구 사항이 우리를 다른 방향으로 이동하도록 합니다. 때로는 그냥 맞지 않을 때도 있습니다. 이러한 상황에서 가장 큰 도전은 종전 구현을 해체하는 것인데, 지속적인 데이터에 대한 액세스를 잃지 않는 것이 종종 가장 어려운 부분입니다.
행운히도 Heroku는 기존 클라우드 기반 솔루션에서 천천히 이동할 수 있는 해결책을 제공하며 외부 호스팅된 데이터에 대한 액세스 권한을 유지할 수 있습니다. AWS와의 VPC 피어링을 간편하게 통합하여, 유산 구현에 남아 있는 리소스에 액세스할 수 있게 해줍니다.
이러한 접근 방식을 채택하면 새로운 서비스가 소비자에게 서비스 중단 없이 번창할 수 있습니다.
Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out