AWS의 클라우드 네이티브 최신 애플리케이션 개발 및 디자인 패턴
본 문서는 총 4부로 구성되어 있으며 이 글은 2부입니다.
1부 링크 : AWS에서의 현대적 애플리케이션 개발 1/4
3부 링크 : AWS에서의 현대적 애플리케이션 개발 3/4
4부 링크 : AWS에서의 현대적 애플리케이션 개발 4/4
CI / CD를 사용한 배포 자동화
회사는 가능한 빨리 고객에게 최대한의 가치를 제공하기 위해 혁신을 신속하게 진행하려고 노력합니다. 이를 위해 최신 응용 프로그램은 CI / CD (Continuous Integration and Continuous Delivery)를 사용하여 테스트 구축 및 실행, 스테이징으로 아티팩트 홍보, 프로덕션으로의 최종 배포와 같은 전체 릴리스 프로세스를 자동화합니다.
CI / CD는 알려진 취약점 검색 및 정적 분석 수행과 같은 특정 보안 제어를 자동화 할 수도 있습니다. 전체 CI / CD 파이프 라인은 임의의 수의 품질 게이트와 컨트롤로 구성 될 수 있으며, 새로운 코드를 생산하기 전에 모두 성공적으로 전달되어야 합니다.
전체 빌드 / 테스트 / 배치 프로세스를 자동화하면 더 재현 가능할 뿐만 아니라 더 빨라집니다. 또한 훨씬 더 자주 (아마도 하루에 여러 번) 수행 할 수 있습니다. 즉, 각 개별 배포는 적은 변경과 적은 위험으로 구성됩니다. CI / CD는 위험이 높고 손에 닿는 모든 이벤트가 아니라 프로덕션 배포가 일상적인 일이 되도록 합니다. 마지막으로 코드가 배포 될 때까지의 시간이 수동 프로세스보다 훨씬 짧기 때문에 우선 순위가 높은 보안 수정 또는 구성 변경에는 더 이상 특별한 핫 패치가 필요하지 않지만 표준 파이프 라인을 통과 할 수 있습니다.
AWS 고객은 오픈 소스 옵션 및 타사 마켓 플레이스 외에도 AWS CodeBuild, AWS CodePipeline 및 AWS CodeDeploy와 같은 완전 관리 형 CI / CD 서비스를 활용할 수 있습니다.
코드로 인프라 관리
CI / CD의 이점을 최대한 활용하려면 전체 응용 프로그램 및 IaaC (Infrastructure as Code)에 대한 모델을 만들어야 합니다. 인프라를 코드로 모델링하여 표준 애플리케이션 개발 라이프 사이클에 통합하고 CI / CD 파이프 라인에서 인프라 변경을 실행하며 구성 오류 감소 및 프로비저닝과 같은 추가 이점을 얻을 수 있습니다. AWS는 다양한 IaC 도구를 제공합니다. 하나의 도구는 AWS CloudFormation9입니다. 이 도구는 간단한 템플릿 파일에서 필요한 클라우드 인프라를 지정한 다음 인프라를 프로비저닝 할 수 있는 서비스입니다. 또 다른 도구는 AWS Serverless Application Model (SAM) 10으로, 서버리스 애플리케이션을 구축하기위한 추가 도구 및 편의 기능을 갖춘 AWS CloudFormation을 기반으로 합니다. CDK (AWS Cloud Development Kit) 11은 선택한 언어를 사용하여 코드로 클라우드 인프라를 설계 한 다음 CloudFormation으로 프로비저닝 할 수 있는 프레임 워크를 제공하는 도구입니다.
모니터링 및 로깅
최신 응용 프로그램 개발자는 모니터링 및 로깅 도구를 사용하여 런타임에 응용 프로그램의 동작을 모니터링하고 해당 데이터를 사용하여 고객 경험을 유지하거나 향상시켜야 합니다. 최신 디지털 제품에서 이는 애플리케이션 로그, 모바일 장치의 데이터, 웹 클릭 스트림, IoT 센서 데이터 또는 기타 사용 데이터를 포함하여 많은 데이터 유형을 모니터링하는 것을 의미 할 수 있습니다. 최신 응용 프로그램 개발자는 제품을 계속 확장하고 향상시킬 때이 모든 데이터를 활용해야 합니다.
AWS에서는 Amazon CloudWatch를 사용하여 모든 애플리케이션 구성 요소에 대한 모니터링, 로깅 및 경보를 설정할 수 있습니다. 로깅에 대한 자세한 내용은 로그 집계를 참조하십시오.
최신 응용 프로그램 점검표
다음 정보를 사용하여 응용 프로그램의 현대화 레벨을 확인하십시오.
· 응용 프로그램 수명주기 동안 보안 및 규정 준수 기능이 내장되어 있습니다
· 응용 프로그램은 마이크로 서비스 모음으로 구성됩니다
· 서버리스 기술은 가능한 모든 곳에서 사용됩니다
· CI / CD는 고품질 기능을 빠르게 제공하는데 사용됩니다
· 인프라는 코드로 개발 및 배포
· 모니터링 도구는 응용 프로그램의 동작에 대한 통찰력을 얻는 데 사용됩니다
현대적인 응용 프로그램 디자인 패턴
최신 응용 프로그램 개발의 모범 사례는 패턴을 사용하여 응용 프로그램을 디자인하고 구현하는 것입니다. AWS 서비스를 이러한 애플리케이션의 빌딩 블록으로 사용하면 구현 노력을 크게 줄이고 안정성과 가용성을 달성 할 수 있으므로 개발자는 애플리케이션에 가치를 더하는 비즈니스 로직에 집중할 수 있습니다.
AWS Services를 사용하여 마이크로 서비스 아키텍처 구현
모범 사례에 따라 마이크로 서비스에 공통 패턴을 사용하고 AWS 서비스를 사용하여 이를 구현할 수 있습니다.
API Gateways
API 게이트웨이 패턴은 백엔드 서비스에 대한 많은 호출이 있고 클라이언트 인터페이스 또는 디바이스 유형에 따라 제공되는 컨텐츠가 다른 경우에 사용할 수 있습니다. API 게이트웨이는 통합 된 API 뒤에 다양한 백엔드 서비스를 통합하고 각 장치에 필요한 콘텐츠를 제공 할 수 있습니다.
AWS 클라우드에서 API 게이트웨이 패턴을 사용하려는 경우 Amazon API Gateway를 사용하여 백엔드 엔드 포인트와 통합 할 수 있습니다. Amazon API Gateway를 사용하면 모든 규모의 REST 또는 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호 할 수 있습니다.
Amazon API Gateway는 스로틀 링, 캐싱, 로깅, API 토큰, Amazon Cognito와 통합 된 인증 또는 권한 부여, 사용자 지정 권한 부 여자 및 다른 AWS 서비스에 대한 요청 프록시와 같은 프로덕션 급 API에 필요한 다른 많은 기능을 제공합니다. Amazon API Gateway가 프록시 요청을 보낼 수 있는 필수 AWS 서비스 중 하나는 서버 인프라를 관리하지 않고 임의의 웹 서비스를 생성하기 위한 기반인 AWS Lambda입니다.
Amazon API Gateway는 AWS에서 관리하므로 운영 및 유지 관리에 대해 걱정할 필요가 없습니다. Amazon API Gateway를 사용하면 보안, 안정성 및 가용성이 향상되어 개발자가 핵심 애플리케이션 기능에 더 많은 시간을 할애 할 수 있습니다.
서비스 발견 및 서비스 레지스트리
시스템에 여러 개의 마이크로 서비스가 포함 된 경우 서비스는 의존하는 다른 서비스의 위치를 찾을 수 있어야합니다. 마이크로 서비스는 확장 가능하고 탄력적이어야 하며, 구성 요소에 장애가 발생하면 지속적인 가용성을 유지하기 위해 새로운 인스턴스 또는 컨테이너를 온라인 상태로 만들어야 합니다. 이는 마이크로 서비스에 있는 인스턴스 또는 컨테이너의 IP 주소가 지속적으로 변경 될 수 있음을 의미합니다. 서비스의 각 인스턴스는 가용성을 지속적으로 모니터링해야 합니다. 로드 밸런서를 사용하여 안정적이고 사용 가능한 엔드 포인트를 제공 할 수 있으며, 이는 일반적으로 공개 웹 엔드 포인트에 가장 적합한 선택입니다. 그러나 로드 밸런서는 추가 컴퓨팅 리소스가 필요하고 대기 시간이 발생합니다. 마이크로 서비스 간의 호출과 같이 클라이언트가 제어 할 수 있는 경우 서비스 감지 패턴을 사용하는 것이 더 효율적일 수 있으며, 이를 클라이언트 측 로드 밸런싱으로 생각할 수도 있습니다.
서비스 발견 패턴에서, 발견 될 서비스에 대한 정보는 어딘가에 등록되어야 합니다. 서비스 레지스트리는 호출 될 서비스가 개별 컨테이너 또는 인스턴스가 시작될 때 자신에 대한 정보를 저장할 수 있는 중앙 위치입니다.
AWS Cloud Map을 사용하여 AWS Cloud에서 서비스 레지스트리 및 서비스 검색 패턴을 구현할 수 있습니다. AWS Cloud Map은 클라이언트가 DNS를 사용하여 서비스 인스턴스의 IP 주소 및 포트 조합을 조회하고 HTTP 기반 서비스 검색 API를 통해 URL 또는 ARN (Amazon Resource Names)과 같은 추상 엔드 포인트를 동적으로 검색 할 수 있도록 하는 완전 관리형 서비스입니다 .
회로 차단기
회로 차단기 패턴은 애플리케이션의 마이크로 서비스 간 호출을 조정합니다. 사용자 요청에 응답하기 위해 애플리케이션의 마이크로 서비스는 서로를 호출합니다. 서비스 A가 서비스 B로 호출을 보내지만 서비스 B의 리턴 호출이 지연되거나 오류가 발생하면 서비스 A는 사용자에게 오류를 리턴합니다. 서비스 A가 오류를 리턴하는 대신 호출을 재 시도하는 경우, 더 나은 사용자 경험을 제공 할 수 있지만 재시도는 추가 로드 및 긴 지연을 생성 할 수 있으며 사용자에게 리턴 된 오류로 끝날 수 있습니다. 대신 서비스 A는 서비스 B가 다운되었음을 인식하고 가능하면 정상적으로 성능을 저하시킵니다.
회로 차단기 패턴에서 다른 서비스에 대한 호출이 예상보다 오래 걸리거나 오류를 반환하면 회로 차단기는 발생 횟수를 유지하고 카운트가 구성 한도를 초과하면 열린 상태로 변경됩니다. 개방 상태에 있을 때 회로 차단기는 다운 스트림 서비스를 호출하지 않고 즉시 호출자에게 오류를 반환합니다.
고정 된 시간이 지나면 회로 차단기가 닫힌 상태로 되돌아가 다운 스트림 서비스에 대한 호출이 정상으로 돌아갈 수 있습니다.
이전에는 서비스 코드에서 라이브러리 또는 프레임 워크를 사용하여 회로 차단기를 구현하는 것이 가장 좋은 방법 이었지만 이제는 종종 사이드카가 있는 컨테이너화 된 마이크로 서비스에서 처리됩니다. 사이드카는 주요 서비스를 제공하는 기본 컨테이너와 함께 시작되는 별도의 도우미 컨테이너입니다. Envoy Proxy는 사이드카의 대표적인 예입니다. Envoy 프록시는 자체적으로 배포 할 수 있지만 종종 서비스 메시의 일부로 배포됩니다. 이 유형의 배포에서 Envoy 프록시는 데이터 플레인이고 AWS App Mesh 또는 Istio와 같은 도구가 컨트롤 플레인입니다.
명령 쿼리 책임 분리
CQRS (Command Query Responsibility Segregation)는 시스템의 데이터 변이 또는 명령 부분을 쿼리 부분에서 분리합니다. 업데이트 및 쿼리는 일반적으로 단일 데이터 스토어를 사용하여 완료됩니다. 처리량, 대기 시간 또는 일관성에 대한 요구 사항이 서로 다른 경우 CQRS를 사용하여 이 두 워크로드를 분리 할 수 있습니다. 명령과 쿼리 기능을 분리하면 독립적으로 확장 할 수 있습니다. 예를 들어 가로로 확장 가능한 읽기 전용 복제본에 쿼리를 보낼 수 있습니다. 명령 및 쿼리 기능을 보다 효과적으로 분리하기 위해 업데이트 및 쿼리에 다른 데이터 모델 및 데이터 스토어를 사용할 수 있습니다. ORM (object-relational mapping)을 통해 관계형 데이터베이스의 정규화 된 모델에 대한 쓰기를 수행하고 API에 필요한 것과 동일한 형식 (데이터 전송 객체 또는 DTO)으로 데이터를 저장하는 비정규 화 된 데이터베이스에 대해 쿼리를 수행 할 수 있습니다. 처리 오버 헤드를 줄입니다.
이 예제는 관계형 데이터베이스에서 일관된 쓰기 및 지연 시간이 매우 짧은 읽기를 위해 아키텍처를 최적화하지만 대신 매우 높은 쓰기 처리량과 유연한 쿼리 기능을 최적화 할 수 있습니다. 이 상황에서는 Amazon DynamoDB와 같은 NoSQL 데이터 스토어를 사용하여 데이터를 추가 할 때 잘 정의 된 특정 액세스 패턴이 있는 워크로드에서 높은 쓰기 확장성을 얻을 수 있습니다. 그런 다음 Amazon Aurora와 같은 관계형 데이터베이스를 사용하여 복잡한 일회성 쿼리 기능을 제공 할 수 있습니다.
이 옵션을 사용하면 Amazon Aurora의 데이터를 최신 상태로 유지하기 위해 적절한 업데이트를 수행하는 AWS Lambda 함수로 데이터를 보내는 Amazon DynamoDB 스트림을 사용할 수 있습니다.
CQRS 아키텍처의 명령 부분을 이벤트 소싱 패턴과 결합 할 수도 있습니다 (다음 섹션 참조). 이러한 패턴을 결합하면 업데이트 이벤트를 재생하여 서비스 조회 데이터 모델을 최신 애플리케이션 상태로 다시 빌드 할 수 있습니다. CQRS 패턴은 일반적으로 쿼리 된 데이터 스토어와 기록 된 데이터 스토어간에 최종 일관성을 유지한다는 점을 기억해야합니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Modern Application Development on AWS (2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
