엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤크 CEO::AWS 마이그레이션 A to Z 웨비나

4. © 2022, Amazon Web Services, Inc. or its affiliates. 엔터프라이즈 마이그레이션 단계 4 Cut over : 운영중이던 Service Application을 중단하고(Down) 다른 시스템으로 이관하는 일련의 행위 Phase-1 Phase-2 Phase-3 Phase-4 Phase-5 Phase-6 Phase-7 Phase-8 D O W N T I M E

5. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 전/진행/후 고객 선행 요건 및 점검 사항 5 구축 전 고려사항 I. 준비 단계 II. 분석 단계(요구사항 / 아키텍처) III. 설계 단계 (핵심/부가 구성요소) 구축 진행 고려사항 I. 설계 단계 II. 환경구축 단계 III. 연계 테스트 및 검증 단계 구축 진행 테스트 연계 테스트 통합 테스트 단위 테스트 응용/테스트 성능 테스트 가용성 테스트

6. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 준비/분석 단계 고려사항 6 준비 단계 전환 전 고려사항 ▪ 클라우드 아키텍처 구성은 Service, Management, Governance Layer로 구성되며 기존의 IDC센터와는 VPN을 통해 연계하고 외부 인터넷 서비스는 필요한 보안 서비스와 Internet Gateway를 통해 Service를 구성합니다. ▪ 고객(응용 부문)과의 R&R 에 대해서 명확히 확정한 이후 면담 등 수행 필요 ▪ R&R 이 명확치 않은 상태서 면담을 할 경우 업무범위에 대한 혼선 초래 ▪ 불필요한 데이터 정리 부문을 고객 주관부서에서 현업에 강력히 요청하는 절차가 필요 ▪ SAN, NAS를 이용한 데이터의 성격을 파악해서 cloud 로 전환 시 용도에 맞는 자원을 사용하도록 사전에 홍보하는 것이 필요 (EFS, S3, EBS로 이관 등) ▪ 대외 연계의 경우는 해당 고객사의 NW, 보안조직과 공조를 통해 현황내역을 명확히 식별하는 것이 필요 ▪ 초기 R&R 수립 시 NW, 보안 운영 조직에도 역할 할당 필요, 응용팀에서는 인프라에 대한 관리 정보가 미흡하여 이관 시 문제가 될 수 있음 ▪ 대내외 시스템간 통신은 서비스 도메인을 통해 유통되도록 표준을 정하고 IP 주소로 통신하는 경우는 서비스 도메인으로 변경 유도 ▪ 응용 소스 내 IP 주소로 등록되어 있는 부문은 식별하여 도메인으로 변경 유도 ▪ 소스 내 IP 주소 존재 여부는 툴을 이용하여 식별 분석 단계 (요구사항 / 아키텍처) ▪ 현황분석 내역은 To-Be 아키텍처 설계를 위해 필요한 내역을 위주로 진행 ▪ 시스템 운용 현황 : 해당 시스템 영향 범위, 이관 시 Down-Time(업무상 허용 가능한), 관리자 정보 등 ▪ 대내외 연계 내역 식별 : 해당 시스템 이관 시 영향받는 내부 시스템 및 대외 기관 시스템 식별 ▪ Cloud 자원 생성시 필요한 내역 : EC2, EBS, EFS, S3 등 자원 생성 시 필요한 용량, 계정 등 ▪ 애플리케이션 소스, 운영 스크립트 및 백업, 시스템 설정 확인(OS버전, JDK 버전, 커널 파라미터 등) ▪ 애플리케이션 분석 ▪ JSP/Servlet, EJB 사용 시 특이사항 확인, 프레임워크 사용여부 확인, 연계 시스템 확인 ▪ 변경 요소 식별 ▪ CentOS → Amazon Linux 2, NAS → EFS, S3, HA 솔루션 + EBS 등, IP 주소로 통신 → 도메인으로 변경 통신(Source 내 IP 주소는 전수 변경이 원칙)

7. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 설계 단계 고려 사항 7 설계 단계 (핵심/부가 구성요소) 구축 전 고려사항 ▪ 고객사는 Cloud 환경에 대한 표준 아키텍처 수립 및 가이드 수립을 위해 별도 조직을 구성하여, PJT 초기에 표준가이드를 제시하고 시스템 이관 시 표준 준수여부를 검증하는 절차(서비스 연계 점검/설계 시점)를 설계 단계에 반영하여 진행 ▪ 표준 아키텍처 수립 시에 영역별 전문가들이 주도적으로 참여하여 지원을 하고, 분석/설계 단계에서는 수립된 표준에 맞게 아키텍처를 설계하고 이를 검증하는 절차 를 반영, 진행 ▪ 시스템 구성 시 공통적으로 사용되는 Cloud 자원에 대해서 표준 구성 가이드 및 사양에 대해서 규정을 정하고 이에 대한 준수여부를 설계 단계에서 점검을 진행 ▪ 표준 아키텍처 적용한 설계 : 설계서에 표준 아키텍처 체크리스트를 포함시켜서 표준 준수 확인 ▪ 핵심 구성요소 식별 : EC2, EBS, EFS, S3, ELB(ALB, NLB), Redis, Route 53 ▪ AS-IS 및 요구사항 분석 내역과 Cloud 표준 아키텍처를 반영한 결과를 설계서에 반영하여 운영팀과의 업무 공조에 활용 ▪ To-Be 구성 내역 요약, To-Be 아키텍처 모델 ▪ 설계서 : AS-IS, To-Be 시스템 구성도, 시스템 내역, 인터페이스 정보, 대외연계내역, 표준 준수 checklist, 운영 조직 , 모니터링, 백업 등 기재) 구축 진행 고려사항 설계 단계 ▪ Replatform 전환의 경우 운영관리의 편의를 위해 WEB/WAS/DBMS 등 공통 시스템 S/W 설치 계정의 통일을 고려하는 경우가 많음 (LINUX OS 에만 해당) ▪ 공통 시스템 S/W 설치 계정의 UID/GID를 AS-IS 시스템에서 사용하지 않는 숫자 대역으로 설정하여 AS-IS UID/GID 를 반드시 사용해야 하는 상황에 대비 ▪ 이관 대상 AP 계정이 본 이관 시 대량의 증분 파일 데이터 이관이 필요한 경우 UID/GID 변경에 따른 영향 및 Downtime 충족 가능여부에 대한 판단이 반드시 필요 ▪ EFS 로 대량 파일을 이관해야 하는 경우 파일 복제 Task 외에 UID/GID 수정 Task 에 많은 시간이 소요될 수 있음 ▪ EC2 Type 결정시 CPU, MEM 수량만을 기준으로 선정하는데 디스크 I/O 가 많은 시스템의 경우는 EC2 Type 별로 지원되는 I/O 처리량도 고려가 되어야 함 ▪ 이관 시 장애요소 중 SG 내 정책 미 반영으로 인한 시스템간 통신 불능 현상이 초기 이관 시 빈번하게 발생 ▪ 시스템간 인터페이스 정보를 명확히 식별하여 설계에 반영하는 것이 중요 ▪ Public Cloud 환경으로 전환 시 대외 연계 구성 내역을 어떻게 전환할 지에 대한 검토가 설계 단계 초기에 고객과 협의 필요 ▪ 전용선, VPN, 인터넷을 통한 연계 등 다양한 연계방식으로 구성된 환경에서는 To-Be 경로를 어떻게 가져갈 것인지 충분한 협의가 필요 ▪ PRD VPC 환경의 경우 PRD 오픈이전으로 폐쇄망 환경 임에 따라 사전 구성 현황 공유 및 필요 조치 사항 List up 필요 ▪ 초기 생성시 폐쇄망 상태로 접속 필요 오픈 대상 정보에 대해 사전 파악/접수 후 영향도 검증을 통해 반영 필요함 (Security Group, 방화벽, 라우팅 등)

8. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 구축/검증 단계 고려사항 8 구축 진행 고려사항 환경 구축 단계 ▪ MIG Account 내 MIG VPC 를 기존 통합 VPC 환경과 별도 구성함 ▪ 운영 비용과 이전 비용 분리, 운영 환경에 영향을 주지 않도록 폐쇄 망 구성 ▪ 연계 테스트 환경 구성 ▪ IDC 내 STG 및 DEV 망 연계, AWS 내 STG 및 DEV VPC 와 연계 구성 ▪ AD/DNS 환경 구성 ▪ 운영 DNS 와 별개로 MIG Account 내 Private Route53(AWS DNS) 별도 구성, 사용자 테스트를 위한 Route53 Inbound Resolver 구성 연계 테스트 및 검증 단계 ▪ AWS 이관 진행 전 시스템 : IDC 내 STG/DEV 서버와 테스트 진행 ▪ AWS 이관 진행중인 시스템 : MIG VPC 내 서버 간의 연계 테스트/검증 진행 ▪ AWS 이관 이후 시스템 : 이관 완료된 시스템의 AWS STG/DEV VPC 내 서버와 연계 테스트 진행 ▪ MIG VPC 환경 내에서 가용성/성능 점검, 통합테스트 진행함 ▪ MIG VPC 검증 서버 image 로 생성함에 따라 PRD 반영 시 최종 반영할 type 확인후 최종 구성 진행 필요 ▪ MIG VPC 환경의 경우 검증 환경임에 따라 운영 환경 대비 1/2 이하의 자원 사용으로 PRD 환경 반영 시 최종 AMI 반영 시 To-Be 자원 type 을 확인후 적용 ▪ 성능 테스트로 자원 증설 필요시 해당 내역 반영된 자원으로 할당 필요함 ▪ 대.내외 연계 검증 진행 시 기본적으로 PRE-PRD VPC – DEV/STG 환경과의 연계로 검증 진행 후 최종 PRD 전환 전 To-Be 환경으로 적용 필요 ▪ 연계 검증 진행 시 기존 운영환경에의 영향을 차단/최소화 하기 위해 기본 정책상 DEV/STG 환경과의 연계 검증을 기본 정책으로 함 ▪ 연계 대상 시스템의 DEV/STG 환경 미보유 및 제약적으로 PRD 과의 검증 필요시 영향도에 대해 고객 의사결정 기준으로 구성 진행함. (Read 성 업무 기준) ▪ 최종 PRD 전환 이전 AWS PRD – 기존 PRD 간의 연계 설정 적용이 필요하므로 해당 내역 최종 확인하여 PRD 전환 진행함 (Readiness check 이전 응용 담 당자 확인 필요) ▪ AWS PRD 환경으로의 사전 동기화 필요 대상 식별 및 동기화 작업 진행 필요 ▪ Cut-over 이전 미리 이관 필요 대상 DB Data 범위 및 Downtime 확보 기준에 따른 DB 이관 방식 협의 필요 (export/import, CDC 등) ▪ 본 단계는 실제로 고객측 부서에서 주관을 수행하는 단계로서 테스트가 정상적으로 수행되었는지 확인하는 것이 필요합니다. ▪ 고객사의 PJT PMO 조직이 개별 응용시스템의 단위 테스트, 통합 테스트 및 연계 테스트를 수행했는지 확인하는 Role 을 초기에 명시해서 진행 필요 ▪ 성능테스트는 대상 시스템을 반드시 초기에 고객과 협의, 확정 필요 (PJT 진행중에 협의하면 다수가 성능 테스트를 요구할 수 있음)

9. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 테스트/이행 단계 고려사항 9 구축 진행 고려사항 응용/테스트 ▪ 응용 수정/테스트 절차는 응용 개발 부서의 주관으로 진행되며, 통합 테스트 시점에 수행되는 가용성 테스트는 인프라 위주로 이관팀 주관으로 진행 ▪ 테스트는 기능, 단위, 통합 테스트 및 대내/외 연계 테스트를 포함하여 진행합니다. 또한, 성능테스트는 고객과 협의를 통해 성능 이슈가 있는 시스템에 한해 진행 단위 테스트 ▪ 단위테스트는 각 업무 그룹별 응용 작업자가 프로그램 목록 기준 응용 프로그램 수정/개발 후 각 기능에 대해서 단위와 관련된 기능의 적정성 및 요구사항을 만족하는지 검증하는 것으로, 단위테스트를 수행하고 결과서를 작성 통합 테스트 ▪ 통합테스트는 각 업무 그룹별 응용 작업자가 통합되는 프로그램의 단위 항목들 간의 시스템 내부 기능, 관련된 연계 기능에 대한 모든 거래의 정상 작동을 검증하는 것으 로, 통합 테스트 계획을 수립하고 수행 후 결과서를 작성 연계 테스트 ▪ 대내 시스템간 연계 확인 (서비스 URL 과 서비스 포트 정확성 및 Cloud 자원(ELB, SG 등)에 등록된 정보의 정확성 확인 ▪ 대외 연계 테스트는 해당 경로에 포함되어 있는 방화벽, 네트워크장비 라우팅 정보 등이 반영되어 있는 지 사전 확인 성능 테스트 ▪ 성능테스트는 사전에 고객과 협의를 통해 대상시스템을 정하고 테스트 시나리오 초안 (기존 고객 측에서 수행해 오던 절차, 환경이 있을 수 있음)을 마련하고 이를 테스 트 담당자가 검토, 수정하여 진행 가용성 테스트 ▪ 가용성테스트는 MIG VPC 에서 진행하고, 실제 운용 환경인 PRD VPC 에서는 설정 내역을 점검하는 수준으로 진행 구축 후 고려사항 Fail Back ▪ Cut-Over 간 의사결정 단계 시 Critical 이슈(복제 데이터 정합성 이슈, 서비스 긴급 재계, 연계 시스템에 대한 미 확인된 이슈 발견 등) 발생에 따른 원복 작업으로 Cut- Over 시 진행된 Task 의 역순으로 수행됩니다. Fail Back 1 단계 (의사결정 1 차) ▪ 데이터 최종분 동기화 전 단계로 전환 대상 시스템의 재 기동을 통해 원복 수행 ▪ 미 식별된 연계 대상 시스템 존재, 고객 요구에 따른 긴급 기동 요청 등으로 인해 FailBack 의사결정이 될 수 있음 ▪ DB 리스너 및 DBMS JOB/Scheduler 기동, AP 서비스 및 연계 서비스 기동 점검을 통해 복구 수행 처리함 Fail Back 2 단계 (의사결정 2 차) ▪ 데이터 최종분 동기화 후 비 정상 데이터로 인해 기 정의된 Downtime 내 복구 불가능 시 전환 대상 시스템이 원복 재 기동 수행 ▪ 데이터 복제의 장시간 소요로 인한 작업 진행 불가, 복제된 데이터의 정합성 및 일부 데이터 누락 이슈 등에 따라 FailBack 의사결정 될 수 있음 ▪ Fail Back 1 단계와 동일하게 DB 리스너 및 DBMS JOB/Scheduler 기동, AP 서비스 및 연계 서비스 기동 점검을 통해 복구 수행 처리하며, 복제 간 데이터의 ReadOnly 로 바뀐 대상(Directory, 파일, DB 데이터 등)은 원복 처리 ▪ 이슈 원인 분석을 위한 Dump 및 LOG 취합, Status 정보 등 최소 분석 가능한 정보를 백업을 받아 분석 진행하며, 향후 재 작업 또는 타 시스템 작업 시 적용

10. © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 이행/안정화 단계 고려사항 10 구축 후 고려사항 Fail Back 마지막 단계 (최종 Open 의사결정 단계) ▪ 응용 테스트 후 Open 이 불가능한 결함이 발생된 경우 Failback 조치 함 ▪ 응용 및 연계 시스템 점검 간 Critical 결함 발견 및 데이터 정합성 이슈가 발생, AWS 구성 상 미 도출된 결함 등으로 인해 Failback 의사결정 될 수 있음 ▪ 전환 AP/DB 시스템 Down 및 네트웍/DNS, SG 등을 기존 정보로 원복 수행 후, 2 단계 FailBack 절차를 수행하여 최종 원복 수행 완료 이행 안정화 ▪ 전체 이관 완료 후 공통 운영(운영팀/이관팀) 단계로 D+3 일 동안 응용 Trouble Shooting 을 진행하며, 해당 기간 중 발생되는 문제 또는 이슈 사항에 대한 대 응 수행 오픈 후 이슈/결함관리 실시 ▪ 차수별 이관 수행 완료 및 오픈 공지 이후 3 일간 안정화 진행하여, 이 기간 중에 식별된 이슈 및 결함 조치에 대한 통합 관리를 수행하면서 운영으로의 이관 지원 수행 공동 운영 및 안정화 ▪ 오픈 당일을 포함한 3 일간 공동 운영을 수행하며, 이 기간 중 발생한 결함은 이관 조직에서 적극 해결하며, 중대 결함이 해결된 이후에 운용 조직으로 인수/인계를 완료 함 이관 수행 결과 ▪ Open 이후 고객에게 Cut-Over 완료 보고를 수행하며, 안정화 기간(D+3)이 지나면 이관 수행 결과 및 운영 인수인계 보고를 통한 본 이관을 완료 Cut-Over 완료 보고 ▪ 작업 진행 시간 및 전환 결과, 결함 내역, 모니터링 결과를 취합하여 완료 보고 수행 운영 인수인계 보고 ▪ 3일간 공동 운영 결과 및 안정화 기간 동안 도출된 결함 처리내역, 특이사항, 운영 인수인계 결과서, 전환 시스템의 최종 아키텍처 설계서를 포함하여 운영 담당자 에게 인수인계 수행하고, 해당 결과를 고객과 공유하여 운영 전환 수행 함 ▪ 운영 인수인계 결과서 포함 내용 이관 수행 결과서 보고 ▪ 전환 대상 시스템에 대한 이관 결과 및 결함 처리 내역, 주요 이슈 Lessons Learned 를 포함하여 고객 전달 및 보고 수행 함 ▪ 이관 수행 결과서 포함 내용

12. © 2022, Amazon Web Services, Inc. or its affiliates. 사전 준비! 클라우드 전환 프로세스 확정 12 1. Legacy Analysis 2. Preparation of Cloud Environment 3. Service Environment and Test 4. Cut over and Stabilization Check Service status Define migration scope Legacy status analysis WEB WAS DBMS Service Usage and volume info. Migration tool requirements Gathering / Analysis Start to design Cloud architecture Classification according to usage business relevance Sizing plan based on capacity and network I/O Reflecting additional requirements and final review Completion of Infra architecture design Deployment of Cloud architecture Migration Tool Function Test Performance Test Integrated Test Cut over process review Cut-Over Roll-back ? Completion of Migration Monitoring Final Report Stabilization Legacy status analysis WEB WAS DBMS Service Yes No Yes No Critical error in main systems? Rollback decision / Announcement Stop New Service Rollback all configuration changes Start old Service Checking Business processes Cutover Preparation

13. © 2022, Amazon Web Services, Inc. or its affiliates. 중요! 사전의 각자의 역할 명확히! 13 Migration Milestone RACI Matrix Customer Project Team Infra PL PO ITO Project PLAN R Transition Architecture Analysis/Design S/C S S/C R Infrastructure / Middleware Construction S/C S/C R Application Migration • JAVA - Change / Compile program sources S S/C R • C - Change / Compile program sources S R S/C • Deployment plan for dual managed sources R R • Integrated Test R A S/C S/C • Handover Test R S/C Cutover S/C R CI/CD S/C R Monitoring and Stabilization C C S/C R R: Responsibility A: Approval C: Consult I: Inform S: Supportive Seamless collaboration between CSP, MSP, and Application is the most important factor in project success.

14. © 2022, Amazon Web Services, Inc. or its affiliates. 영역별 전환 위험 요소의 식별 14 분류 예상 RISK 심각도 해결 방안 소스 관리 • 소스 관리 솔루션이 없거나, 버전 관리를 하지 않는 경우, 소스코드가 분실될 우려가 높아 전환 작업 수행 어려움 상 • 소스 관리를 하지 않는 경우, 이행 이전의 영향 분석을 통한 미사용, 소스 부재 파악을 TO-BE ALM 적용이 가능하도록 구성 • 애플리케이션 소스 내의 IP, 하드 코딩된 정보 등에 대한 검색 및 전환 규칙 생성 AP 마이그레이션 • 상용 SW 및 서비스 마이그레이션 이전 환경 상 • AP 소스코드 자동 분석 Tool을 이용하여, 고객의 현행시스템의 애플리케이션을 누적된 마이그레이션 Factor 정보를 기반으로 마이그레이션 소요 기간 산정으로 납기 기간 예측 • 마이그레이션 경험 인력 투입으로 효율적이며 안정적인 마이그레이션 업무 수행 지원 • 안정적 마이그레이션을 위해 최대한 동일버전으로 이행 (인터페이스 변경 최소화) • 버전 관리가 되어있지 않아, AP 마이그레이션에서 현행시스템의 소스 수정 및 삭제, 오류 발생 시 다른 시스템 영향 중 • 오류가 발견된 경우, AP 소스코드 자동분석 Tool을 이용하여 오류분석 시행 및 자동 영향 분석을 통해 오류 요인 해결 • AP 소스코드 자동 분석 도구를 활용하여 추후 발생 가능한 오류까지 찾아내어 수정 보완 및 문서화 DB • 전환 시 다운 타임 상 • 차수에 걸친 마이그레이션과 데이터 실시간 동기화를 통한 다운타임이 최소화되도록 CDC 솔루션을 활용하여 데이터 이관 • 구체화되지 않은 볼륨사이즈 상 • 이관 대상의 볼륨 및 이관 일정에 대한 명확한 사전 진단 후 적절한 이관 방법 판단 가능 • Oracle의 EC2 이관 시 상호 인증 관련 문제 상 • DB 전환 버전에 따른 메이저/마이너 업그레이드 여부 판단 • https://docs.oracle.com/cd/E11882_01/relnotes.112/e23558/toc.htm#CJAFHBIA WEB/WAS • 세션 클러스터링 등의 부가적인 설정 정보(예: 웹로직 코헤런스) 중 • 세션 클러스터를 위한 WAS 환경 설정, 데이터 소스 설정 변경 등의 작업수행 • EOS로 인한 OS/JDK AS-IS 버전 설치불가 하 • 기존 서버의 EOS된 솔루션을 신규 버전으로 업그레이드하고 각 업무에 대한 테스트를 진행 • 애플리케이션 EJB 구성 시 DD(Deployment Descriptor) 변경 어려움 상 • 애플리케이션 EJB 구성 시 deployment descriptor의 변경과 JNDI Context Factory 코드 변경이 수반되어야 함

16. © 2022, Amazon Web Services, Inc. or its affiliates. 다중 계정 환경에 대한 거버넌스 체계 16 Vpc: network-ext Vpc: hq-adm Vpc: dev Vpc: prod Vpc: network-int DC Account: ddc-network IDC Direct Connect Account: local-billing AWS Organizations Vpc: network-ext Vpc: network-int Account: ist-dev Account: ist-prd AWS WAF Account: cust-security Account: cust-logging Central logs Account: hq-billing AWS Organizations AWS WAF Account: hq-security Account: hq-logging Central logs Proxy symantec Proxy Account: hq-adm Int-services (vault, bastion …) Vpc: dev Vpc: prod Account: cust-tsp Account: mkt-prd Seoul Vpc: dev Vpc: prod Account: mgt-ope Account: mig-dev HQ Vpc: prd Account: mig-ope Account: hq-network Proxy Direct Connect

17. © 2022, Amazon Web Services, Inc. or its affiliates. Mission Critical! DB 마이그레이션 17 Private subnet Public subnet ON-PREMISE Source DB AWS Cloud Replication Instance Target Endpoint Source Endpoint DMS Target DB CDC with SCN EBS Test DB EBS Copy Target DB server Test DB server Web server WAS server Cutover Replication 1 3 4 5 Prod DB server Cutover Data Pump 2 6 expdp with SCN impdp 7 Meta data & LOB type data • 데이터 파일 복제, export/import와 AWS DMS를 활용한 CDC 활용 • Cut-over 시 초기 복제 이후의 메타 데이터(프로시저, LOB 데이터) 전송 • Cut-over 시 운영 테스트 DB를 운영 DB로 전환(역할 변경: Test DBserver → Product DB server) Database Migration Strategy 1. AWS DMS set up between on-premise and AWS EC2 as target 2. Expdp with SCN number & impdp 3. CDC (change data capture) with SCN number running 4. Create a clone DB for test 5. Test using Test DB - modify sources 6. Cutover: Change data volume mount (EBS) from Test DB to Target DB 7. Meta data (Procedure, Function, Trigger and etc.) LOB type data expdp & impdp

18. © 2022, Amazon Web Services, Inc. or its affiliates. U2L, L2C 솔루션 사용 18 Server Creation and Configuration System Assessment Application Property Configuration Cut-over Check-list Re-Platform process (U2L) is a system assessment and migration solution for cloud migration of L2C and U2C. EC2 Instance creation (based on Template Image) File copy from legacy servers to created EC2 Instances Template Image creation in AWS DB: AIX 6.1 → RHEL 7.9 AIX/HPUX/Solaris -> AMZL 2 Windows 2003 → Windows2012 System Assessment ▪ 클라우드 마이그레이션 자동화 ✓ 마이그레이션 도구를 활용한 인벤토리 등록된 AS-IS 시스템의 자동 이전 ✓ EC2 인스턴스 생성 및 파일 동기화 ▪ 비용 효율과 호환성 고려 ✓ Re-platform(Unix to Linux) ✓ OS Re-host(Linux on VMWare to Amazon Linux) ✓ 레거시 웹 서버를 AWS ALB로 전환

19. © 2022, Amazon Web Services, Inc. or its affiliates. 19 마이그레이션 팁! 요약 1. 최적의 아키텍처 설계를 위한 Review Board 구성이 필요하며, 2. 사전 평가(pre-assessment)를 통해 전환 우선 순위 산정하여 위험을 줄여야 하며, 3. 애자일과 같은 Iteration 방식으로 Cut-over Phase를 구분해야 하며, 4. 조직간 마찰을 줄이기 위한 R&R을 명확히 하는 Matrix를 구성하고, 5. 전환 전략 하의 철저한 데이터, 인터페이스 검증을 해야 합니다.

22. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 사례 – 1 (NCP to AWS 마이그레이션) 월 예상 요금 : 306,100 원 c6g.2xlarge : 229.40 USD, 287,025 원 t4g.xlarge : 126.03 USD, 157,688 원 8 VCPU, MEM 16GB, SSD 50GB 8 VCPU, MEM 16GB, SSD 50GB 4 VCPU, MEM 16GB, SSD 50GB

23. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 사례 – 2 (CDN) 월 예상 요금 : 12,900,000 원 월 300TB 사용시 월 예상 요금 : 34,908,480 원 월 300TB 사용시 월 예상 요금 : 11,260,800 원 월 300TB 사용시 (스마일샤크 제공시)

24. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. 마이그레이션 사례 – 3 (AWS Serverless) • AWS의 장점을 살린 아키텍쳐로 마이그레이션 • Lambda, DynamoDB, S3, CloudFront 등을 사용 • 서버 관리의 어려움 해소 • 스마일샤크 홈페이지 서버리스 웨비나 참조 (https://www.youtube.com/watch?v=RSbRZCsUP4E)

25. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. GBaaS 마이그레이션 • 해외 GBaaS 서비스로 운영 중 기술문의 어려움으로 뒤끝으로 마이그레이션 • 국내 런칭 예정 게임서비스를 해외 GBaaS 서비스로 PoC 중 레이턴시 문제로 뒤끝으로 마이그레이션 • 국내 GBaaS 서비스로 신규 게임 PoC 중 체팅, 뒤끝 펑션 등의 다양한 기능으로 뒤끝으로 마이그레이션

27. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. 회원가입/로그인 유저 정보 관리 회원 탈퇴 공지사항 게임내 이벤트 관리 결제관리 랭킹관리 친구/길드/쪽지/우편 기능 뒤끝 서비스 소개 뒤끝베이스 뒤끝챗 채팅 귓속말 공지/운영자 채팅 비속어 필터링 유저 신고/ 차단 뒤끝매치 1:1 개인전 팀전 친구 초대 기능 재접속 기능 뒤끝펑션 커스텀 로직 개발 클라이언트 해킹이 걱정되는 기능 27

28. UPDATE DOCUMENT TITLE IN SLIDE MASTER © 2022, Amazon Web Services, Inc. or its affiliates. 뒤끝 서비스 사용 예시 회원가입/로그인 기능 예시 // 회원가입 BackendReturnObject bro = Backend.BMember.CustomSignUp ( "id" , "passwor if(bro.IsSuccess()) { Debug.Log("회원가입에 성공했습니다"); } // 로그인 BackendReturnObject bro = Backend.BMember.CustomLogin( "id" , "password" if(bro.IsSuccess()) { Debug.Log("로그인에 성공했습니다"); }

엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤크 CEO::AWS 마이그레이션 A to Z 웨비나

Esté a ler uma amostra.

Confira estes a seguir

엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤크 CEO::AWS 마이그레이션 A to Z 웨비나

Mais Conteúdo rRelacionado

Semelhante a 엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤크 CEO::AWS 마이그레이션 A to Z 웨비나 (20)

Mais de Amazon Web Services Korea (20)

Mais recentes (20)