日本語에서 번역 • 원문 보기 안녕하세요. 저는 Azure 엔지니어인 아키야마입니다. 이번에는 AWS에서 Azure로 LAMP 시스템을 이전하는 방법에 대해 글을 쓰겠습니다.
이주 이전 건축
시스템은 정통 LAMP 구성입니다.
다음은 일반적인 구성입니다.
- DNS(53번 도로)
- 부하 분산기(ELB)
- 웹 서버 (EC2)
- 배치 서버 (EC2)
- 캐시 (엘라스티캐시)
- 데이터베이스(RDS)
문제들
우리가 해결하고자 했던 문제들은 다음과 같았습니다.
- 웹 서버가 과다 사양
- 운영 환경으로의 배포는 AMI가 개발 환경의 EC2를 복사하여 수행합니다. 또한, 개발 환경은 하나뿐이며 소스 코드는 버전 관리가 되어 있지 않습니다
- 외주 제작이지만 회사 내 아무도 하지 않았다.
- Azure 회원들이 관심을 갖는 서비스가 AWS에서 실행되고 있습니다
이주 이후 건축
이 시스템은 내부에서 운영되지만 사용자 수가 많지 않고 서비스 다운 시간의 영향도 적어, 현재 프리뷰 중인 Linux와 Azure Database for MySQL에서 WebApp을 도입했습니다. 이로 인해 IaaS를 제거한 PaaS 전용 구성이 되었습니다.
2017/09/12 업데이트: 리눅스용 웹앱이 컨테이너용 웹 앱으로 GAdated되었습니다.
- DNS(AzureDNS)
- 웹 서버 (리눅스의 WebApp)
- 배치 서버 (로직 앱)
- 캐시 (레디스)
- 데이터베이스 (AzureDatabase for MySQL)
- 응용 인사이트
웹 요청에 따라 배치 처리가 발생했지만, EC2 크론에서 Logic App으로 전환함으로써 IaaS를 없애고 비용을 절감했습니다. 우리는 Application Insight 가용성 테스트를 통해 서비스를 모니터링하며, Slack에서 Logic App을 웹훅으로 알림을 제공합니다.
미리보기 서비스를 계속 사용하고 싶다면 약간의 다운타임을 준비해야 합니다.
무슨 일이 있었던 일이야
문제들을 하나씩 되돌아보자.
웹 서버 확장
문제
웹 서버가 과도하게 사양되어 있습니다.
결과
리눅스의 WebApp은 윈도우 버전처럼 유연하게 확장할 수 있습니다. 이제 최소 요구 사양까지 쉽게 낮출 수 있습니다.
EC2에서 축소해야 해서 못 한 건 아니지만, 오히려 더 쉽게 할 수 있었어요.
배치 흐름
문제
프로덕션 배포는 AMI가 개발 환경의 EC2를 복사하여 수행합니다.
결과
이전에는 소스 코드의 버전 관리조차 할 수 없었지만, 이제는 GitHub로 푸시하는 배포 플로우로 스테이징 환경이 업데이트되었습니다. 모든 것이 괜찮아 보인다면 교체만 하면 끝입니다.
정비
문제
아웃소싱으로 제작되었지만, 회사 내 누구도 이에 대해 아무런 조치를 취하지 않았습니다.
결과
이 마이그레이션 과정 덕분에 적어도 직접 작업할 수 있었습니다. 이 글을 쓰면서 인프라 구성과 배포 흐름을 문서화하는 데도 도움이 되었습니다. 저희 프로그래머라면 문제없을 것입니다.
퍼블릭 클라우드 선택
문제
Azure 회원들이 관리하는 서비스가 AWS에서 실행되고 있습니다.
결과
여러 퍼블릭 클라우드 벤더와 협력해 왔습니다. 이 시스템은 Azure 멤버들이 관리했기 때문에, 마이그레이션 과정에서 검증하던 최신 Azure 기술을 테스트할 수 있는 장소로 사용할 수 있었습니다.
결론
Azure뿐만 아니라 퍼블릭 클라우드 서비스도 매우 빠르게 진화하고 있습니다. 서비스를 적절히 결합하면 최소한의 모니터링을 달성하고 개발 환경을 현장에 적용할 수 있습니다. 개발에 집중할 수 있는 환경을 원하신다면 언제든지 연락해 주세요.
