Part 1에서는 AWS의 이중화 구성과 고가용성에 대한 검증을 완료하였습니다.
본 글에서는 Azure의 구성을 완료하고, AWS와 Azure간의 VPN 연결을 통해 내부망으로 DB 복제까지 알아보도록 하겠습니다.

아래와 같은 순서로 진행할 예정이며, Azure 서비스 구성을 포함하여 주요 내용 위주로 알아보도록 하겠습니다.

[순서]

Azure 서비스 구성
VPN 구성
DNS 구성
DB 복제

1. Azure 서비스 구성

Azure 서비스는 아래와 같은 순서로 배포할 수 있습니다.

Resource Group 생성
NSG(Network Security Group) 생성
- 최소한의 보안을 위한 web-subnet에 할당할 NSG 생성
  - Inbound Open : 22, 3306, 8080
Virtual Network 생성
- IP : 192.168.0.0/16
- Subnet 생성
  - web-subnet : 192.168.2.0/24
  - db-private-subnet : 192.168.1.128/26
  - ApplicationGatewaySubnet : 192.168.4.0/24
  - dns-resolver-in : 192.168.1.64/28
  - dns-resolver-out : 192.168.1.80/28
  - AzureBastionSubnet : 192.168.1.0/26 (Bastion 생성시에 같이 생성됨)
  - GatewaySubnet : 192.168.0.0/24(VPN Gateway 생성시에 같이 생성됨)
Bastion 생성
- VPN 구성전에 WEB 서버용 VM과 Mysql에 접속하기 위한 용도
Virtual Machine 2개 생성
- WEB 서버로 AWS EC2(Part 1)에서 만든것과 동일하게 구성
Mysql Flexible Server 생성
- 반드시 프라이빗 엑세스(VNet 통합)로 만들어야함
Application Gateway 생성
- Tier : Standard V2 / WAF 기능은 필요없음.
- Backend Pool : 생성한 VM 2대 연결
- Backend Setting : 8080
- Listner : 80
- Rule : 위 생성한 Backend Pool, Backend Setting, Listner 선택

여기까지 Azure 서비스 구성을 완료하면 Application Gateway의 Public IP:8080을 호출하면 다음과 같은 페이지를 확인 할 수 있습니다.

추가로 AWS와 동일한 도메인으로 호출하기 위해 Azure DNS를 구성하고 설절하면 도메인명으로 호출이 가능합니다.(Part 3에서 서비스 장애에 따른 DNS전환시에 함께 구성할 예정입니다.)

2. VPN 구성

AWS와 Azure간의 VPN을 구성하고 연결하기 위해서는 두 CSP 모두 생성하고 연결하는 작업이 필요하며 아래 순서대로 CSP를 번갈아 가면서 작업을 수행해야 합니다.

Azure 가상 네트워크 게이트웨이
- 게이트웨이 유형 : VPN
- SKU : VPNGw2AZ
- 세대 : Generation2
- 가상네트워크 : 생성한 Vnet
  - Subnet은 자동으로 생성됨
- active-active 모드 : 사용 안 함
AWS 고객 게이트웨이
- IP주소 : Azure 가상 네트워크 게이트웨이의 공용 IP(Public IP)
- 선택사항은 미입력
AWS 가상 프라이빗 게이트웨이
- ASN : Amazon 기본 ASN
AWS Site-to-Site VPN
- 라우팅 옵션 : 정적
  - Azure의 VNet(Virtual Network) 대역(여기서는 192.168.0.0//16)
- 터널1, 터널2 미입력해도 자동으로 생성됨
- 생성 후 "구성 다운로드" 후 "Tunnnel의 공인 IP", "PSK(Pre-Shared Key)"를 확인
Azure 로컬 네트워크 게이트웨이
- IP 주소 : 위에서 확인한 AWS VPN Tunnel의 공인 IP
- 주소 공간 : AWS VPC의 IP 대역(여기서는 10.20.0.0/16)
Azure 연결
- 연결 형식 : 사이트 간(IPsec)
- 인증 방법 : 공유 키(위에서 확인한 PSK 입력)
- 그 외는 기본값으로 유지
AWS 라우팅 전파
- AWS의 VPC 내에 연결된 라우터에 라우팅 전파 편집에서 전파를 "활성화"로 수정
연결 상태 확인
- AWS : Azure측에 한개의 터널만 연결하여 Tunnel 1에 대해서 상태 "위로(up)"으로 정상 확인

Azure : 상태 : 연결됨으로 확인

Ping 테스트
- 대상 자원 AWS EC2 WEB 01(10.20.128.250) / Azure VM WEB 02(192.168.2.6)
- AWS EC2 -> Azure VM Ping 테스트 정상 확인
- Azure VM -> AWS EC2 Ping 테스트 정상 확인

3. DNS 구성

IP만 사용하게 되면 VPN연결이 된 시점에서 추가적으로 할 필요는 없는 사항일 수 있습니다.
하지만, Mysql Replication 프로시저를 사용할 때 Azure Mysql DNS에 대한 질의가 불가능한 문제가 있어 해당 구성도 추가로 진행합니다.

AWS와 Azure 두 CSP 모두 DNS Resolver를 구성합니다.

Azure - DNS Private Resolver(DNS 프라이빗 확인자) 구성

인바운드 엔드포인트 구성
- 위에서 생성한 Subnet을 사용(dns-resolver-in : 192.168.1.64/28)
- 정적으로 192.168.1.68 지정(임의로 지정)

아웃바운드 엔드포인트 구성
- 위에서 생성한 Subnet을 사용(dns-resolver-out : 192.168.1.80/28)

규칙은 지정하지 않습니다.

AWS - Route53 - 확인자 - 인바운드/아웃바운드 엔드포인트, 규칙 구성

인바운드 엔드포인트 구성
- VPC 중 Private Subnet 2개 선택

아웃바운드 엔드포인트 구성
- VPC 중 Private Subnet 2개 선택

규칙 구성
- 규칙 유형(전달)
- 도메인 이름(privatelink.mysql.database.azure.com)
- VPC(사용중인 VPC)
- 아웃바운드 엔드포인트(위에서 생성한 아웃바운드 엔드포인트)
  - 대상 IP 주소 : Azure DNS Resolver에서 생성한 인바운드 엔드포인트 IP

해당 구성이 정상적으로 완료되면 Azure에서 생성한 Mysql의 서버이름으로 nslookup을 할 때 정상적으로 되는 것을 확인 할 수 있습니다.

[적용 전]

[적용 후]

4. DB 복제

설치형 DB가 아니기 때문에 Parameter 수정은 각 CSP 콘솔에서 수행해야하며, 적용을 위해 재부팅이 필요한 경우도 있습니다.
순서는 아래와 같이 설정하고 복제를 확인할 수 있습니다.

Master : 원본 -> AWS RDS
Slave : 복제할 대상 -> Azure Mysql

Master : 복제용 계정 생성 및 권한 부여
Master : bin log 파일명, Position 값 확인
Slave : Replication 세팅 및 시작

1. Master : 복제용 계정 생성 및 권한 부여

CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'Password!234';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%';

2. Master : bin log 파일명, Position 값 확인

show master status;

File, Position에 값을 확인해두며, 다음 단계 Slave에서 Replication 설정시에 필요합니다.

3, Slave : Replication 세팅 및 시작

CALL mysql.az_replication_change_master('lshdb-instance-1.chexnsxtdiva.us-east-1.rds.amazonaws.com','repl_user','Password!234',3306,'mysql-bin-changelog.000003', 889,' ' );

CALL mysql.az_replication_start;

4. 복제 확인

show slave status\G;

명령어 확인시 아래와 같은 결과를 확인 할 수 있으며, 중요한 부분은 아래 두 개 입니다.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

두 개의 값이 모두 Yes로 되어있어야합니다.

*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: lshdb-instance-1.chexnsxtdiva.us-east-1.rds.amazonaws.com
                  Master_User: repl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin-changelog.000003
          Read_Master_Log_Pos: 889
               Relay_Log_File: relay_bin.000002
                Relay_Log_Pos: 336
        Relay_Master_Log_File: mysql-bin-changelog.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: mysql.%,information_schema.%,performance_schema.%,sys.%
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 889
              Relay_Log_Space: 540
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: /app/work/primary_ca.pem
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 676896162
                  Master_UUID: ae943007-b375-3ecb-b641-667173a91242
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 0
            Network_Namespace: 
1 row in set, 1 warning (0.00 sec)

ERROR: 
No query specified

복제 테스트

Master에서 데이터 삽입 후 Slave에 동일하게 되어있는지 확인

[Master에 값 삽입 전 Master 테이블 조회 / Slave도 동일]

[Master에 값 삽입 후 Master 테이블 조회]

[Master에 값 삽입 후 Slave 테이블 조회]

결론

VPN(또는 DX)를 구성하게 될때 PaaS 서비스 또는 On-Premise의 서비스의 통신 여부를 상세히 체크해야 함.
AWS는 VPN 구성시 터널을 기본 2개 제공, 한개만 사용할 수 있음
타 CSP에서 제공하는 Managed 서비스(Ex PaaS)는 설정, 명령어 등 차이가 존재함.
- N/W 또한 차이가 존재.
  - AWS RDS는 Private하게 사용하고자 할 경우 특별히 선택하거나 추가 구성할것이 없음
  - Azure Mysql은 Private Endpoint 사용시에 DNS로 사용 불가능하며, 일부 사용에 제한이 있어 Vnet Integration으로 사용해야함

서비스 소개

서비스

사용자 가이드

지원

CloudZ

Blog

[순서]

Azure 서비스 구성

VPN 구성

DNS 구성

DB 복제

1. Azure 서비스 구성

Resource Group 생성

NSG(Network Security Group) 생성

Virtual Network 생성

Bastion 생성

Virtual Machine 2개 생성

Mysql Flexible Server 생성

Application Gateway 생성

2. VPN 구성

Azure 가상 네트워크 게이트웨이

AWS 고객 게이트웨이

AWS 가상 프라이빗 게이트웨이

AWS Site-to-Site VPN

Azure 로컬 네트워크 게이트웨이

Azure 연결

AWS 라우팅 전파

연결 상태 확인