AWS에서 그 유명한 AWS로 넘어간 사연입니다.

개요

회사도 커졌고, 자사도 현재 유행하는 AWS로 옮겼기 때문이다.당사는 원래 사회에서 자주 사용하는 AWS 클라우드를 위해 서비스하고 있습니다.다른 사람들도 같은 상황을 만날 수 있을 것 같아서 AWS에서 AWS로의 과도와 그곳에서 얻은 지식을 참고로 말씀드리겠습니다.
주요 특징은 마비 시간을 억제하기 위해 VPC 천공기를 사용하여 단계적으로 이동하는 것이다. 그 부분에 대해 특히 상세하게 기술했다.
제목은 선생님 편을 들어 생각해 주십시오.

컨텐트 마이그레이션

준비물

마이그레이션 소스의 AWS 환경

목적지의 AWS 환경

새로운 타겟 AWS 계정을 만들고 새로운 환경을 마련했습니다.

소스 구조(Old)

미묘하게 마이크로 서비스의 모습(계좌 관리를 관리하는 내부 API가 있고 각 서비스는 기본적으로 독립된) 구조를 보였다.응용 서버는 ELB(EC2 Instance 서비스 A, B, C...)를 통해(EC2 Instance 서비스 E, F, G...)네.자세한 내용은 아래를 보십시오.

이번에 옮긴 물건.

도메인 as Route 53

기계asEC2

데이터베이스 as RDS

개체 스토리지 as S3

대상 구조(New)

모바일 소스와는 거의 변화가 없지만 모든 웹 서버와 API 서버는 개인 서브넷에 놓여 있고 ELB를 통해 웹 페이지를 방문할 때 외출할 때 NAT를 통해 실례가 된다.
그림에 적힌 것을 잊었지만, 낡은 것과 새 것이 SSH로 연결된 페달 실례가 있다.

마이그레이션 단계

No
작업
네트워크 서버
내부 API
DNS
데이터베이스
서비스 중단
1
웹 서버 이동
New
Old
Old
Old
없음
2
내부 API 전송
New
New
Old
Old
없음
3
DNS 전송
New
New
New
Old
없음
4
데이터베이스 이동
New
New
New
New
있다

미리 한 일

VPC 천공을 통해 기존 환경과 새로운 환경을 연결합니다.

단계적으로 전환 단계를 진행하고자 하기 때문에 새로운 환경에서 낡은 환경의 내부 API와 데이터베이스에 접근할 수 있도록 낡은 환경과 새로운 환경 사이에서 VPC 등등을 진행하였다.따라서 어플리케이션 서버는 새 환경에, 어플리케이션 서버에서 액세스하는 내부 API는 이전 환경에 설정됩니다.VPC 펀치로 RDS에 접근할 수 있어 편리하다.VPC 귀걸이 아가씨.

내부 API의 끝점은 내부 DNS를 통해 관리됩니다.

내부 API의 단점은 AWS가 발행한 인터넷 호스트 이름이나/etc/hots에 내부 API와 호스트 이름의 대응을 기술하고 호스트 이름을 프로그램 내 설정 파일에 기술합니다.그러나 이것은 불편하다. 전자라면 운용된 실례를 바꾸거나 하나의 실례에서 API를 힘들게 하거나, 후자는 내부 API에 접근한 실례의 모든/etc/hosts를 동기화해야 한다.
이러한 문제를 해결하기 위해 이동하기 전에 내부 API의 끝점은 Route 53을 사용하는 내부 DNS로 관리됩니다.이로 인해 발생하는 부차적인 효과로서 이전에 제본과 공식 작업에서 모두 설정 파일을 통해 내부 API의 단점을 전환했지만 제본과 공식의 각 내부 DNS에서 내부 API의 단점과 호스트의 대응 관계를 정의했다구성 파일을 사용하여 전환할 필요는 없습니다.

Chef 만들기 메뉴

이번에는 비전의 테로가 존재하기 때문에 AMI와 rsync의 이동은 모두 셰프가 환경을 구축한다.이렇게 되면 호흡이 줄어들면서 정식 공연과 무대극도 같은 디자인을 할 수 있게 된다.구성을 간략하게 소개해드려요.

enviroments에서 정식 상태와 제본 전환을 진행합니다.관리

서비스 도메인

해소분지

어플리케이션 설정 파일

액세스 시 인증

각 실례에서 nodes에 사용되는 식단을 기술

templates에서nginxconf의 각종 모형을 정의

definition에서 서비스 프로그램의 초기 형태를 정의

recipe에서 기본 환경을 조정하는 식단, definition을 사용하는 각 서비스의 제작 식단(10이상)

정의

data_bags에 암호화된 개인 키 저장

NAT 인스턴스 준비

당사는 몇 개의 외부 API를 사용하였는데, 그 중 일부는 방문원을 신청해야 하는 IP 주소가 있습니다. (신청하지 않으면 방문할 수 없습니다.)그러나 API를 사용하는 인스턴스는 증가 또는 감소할 수 있으며 소스 인스턴스에 대한 액세스는 고정되지 않습니다.매번 증감할 때마다 방문원 IP를 신청하는 것은 매우 번거롭기 때문에 NAT 실례를 세우고 정적 IP를 흔들며 외출할 때 반드시 그 실례를 통과해야 한다.이렇게 되면 외부 API에 신청하는 IP는 하나로, API를 이용한 실례 증감도 더는 신청할 필요가 없게 된다.

실제 이동

1. 네트워크 서버의 이동

오래된 데이터는 이미 옛 환경으로 옮겨져 네트워크 서버로만 옮겨졌다.

2. 내부 API 전환

계정 관리 내부 API가 전송되었습니다.

3. DNS의 전환

먼저 새로운 환경의 움직임을 확인했다.그리고 지금까지 일반 사용자의 접근은 Old로 갔지만, New로 갔습니다.

4. 데이터베이스 이동

서비스가 정지되어 데이터베이스를 옮겼습니다.동작을 확인했습니다.

끝맺다

수십 개의 서비스가 있지만 서비스 중단은 몇 시간밖에 걸리지 않는다.
그림에 미묘한 오류가 있습니다(S3은 VPC Peering을 통해 방문하지 않았고 EBS는 VPC Peering을 통해 방문할 수 없습니다). 하지만 최선을 다했기 때문에 성야가 오기 전에 투고하는 것을 허락해 주십시오.