FAQ

Q: 모던 애플리케이션이란 무엇입니까?

모던 애플리케이션은 팀이 더 빠르게, 자주, 일관되게, 안전하게 가치를 실현할 수 있도록 하는 최신 기술, 아키텍처, 소프트웨어, 제공 방식, 운영 프로세스의 조합입니다. 이 같은 애플리케이션은 일반적으로 느슨하게 결합된 분산 기술과 이벤트 중심의 서버리스 구성 요소를 활용합니다. 이 같은 기술과 구성 요소 덕분에 팀은 획일적이고 부담스러운 작업에서 벗어나 고객에게 가치를 제공하는 데 더 많은 시간을 할애할 수 있습니다. 또한 모던 애플리케이션은 운영 및 보안 도구를 활용하여 배포의 안정성과 일관성을 높이는 동시에, 하루에 여러 번 배포하더라도 문제가 발생하지 않게 합니다. 인프라, 보안 및 배포의 자동화를 활용하면 모던 애플리케이션을 소유한 팀이 수동 프로세스에 의존하거나 훨씬 복잡한 운영 관리 작업을 수행해야 할 때보다 신속하게 전환할 수 있습니다.

Q: 기업들은 모던 애플리케이션을 어떻게 구축하고 있습니까?

일반적으로 모던 애플리케이션은 애플리케이션의 범위를 축소하여 운영상의 민첩성을 높이고 운영을 간소화하여 위험 요소를 해결하는 방식으로 구축됩니다. 모던 애플리케이션의 개발자는 선택한 아키텍처가 애플리케이션의 목적에 잘 부합하도록 적절한 도구를 선택하는 데 초점을 맞춥니다. 예를 들어 일반적으로 주소 및 연락처 정보와 같은 관계를 표시하기 위해 통합되는 데이터에 관계형 데이터베이스가 아니라 그래프 데이터베이스를 활용하여 개인 및 여러 친구, 가족 및 동료 그룹과 같이 긴밀하게 연결된 관계를 관리하고 시각화합니다. 관계형 데이터베이스를 사용하여 후자를 구축할 수도 있지만, 해당 문제를 해결하는 데에는 그래프 데이터베이스가 가장 적합합니다. 그리고 다음 단계로 선택한 도구의 운영 관리 작업을 최소화하고 AWS 빌딩 블록을 최대한 활용하는 것을 목표로 합니다. 마지막으로, 기업은 가능한 모든 부분에서 자동화를 통해 모던 애플리케이션을 관리 및 유지하고 있습니다. 덕분에 모던 애플리케이션은 경량화되고, 신뢰성, 확장성 및 보안성이 뛰어나 소유자가 보다 빠르게 더 자주 가치를 실현할 수 있습니다.

Q: AWS를 기반으로 모던 애플리케이션을 구축하면 어떤 점에서 고유한 이점이나 더 나은 점이 있습니까?

AWS는 기업이 놀랍도록 다양한 애플리케이션을 구축할 수 있는 폭넓은 서비스와 기능을 제공합니다. 현재 AWS는 개발자가 획일적이고 부담스러운 작업에서 벗어나게 하는 AWS Lambda, AWS Step Functions, Amazon API Gateway, AWS Fargate 등의 다양한 서버리스 기능을 제공하며, 서비스는 계속 늘어나고 있습니다. 꾸준히 확장되며 완성도가 높아지고 있는 AWS Developer Tools 제품군은 인프라 및 구현의 자동화를 통해 DevOps 개발 방식을 지원합니다. AWS Cloud9을 활용해 서버리스 개발을 진행할 수 있는 간단한 환경도 있습니다. 빌드 단계부터, 커밋, 릴리스 단계까지, AWS는 기존 오퍼링과 같은 운영상의 문제 없이 탄력적인 지속적 제공을 지원하는 완벽한 도구 제품군을 제공합니다. 마지막으로, AWS는 마이크로서비스 아키텍처를 가장 먼저 채택한 업체 중 하나였으며, 조직이 마이크로서비스 아키텍처를 구축하고 관리할 수 있도록 풍부한 전문성과 도구를 갖추어왔습니다.

Q: 마이크로서비스의 경계는 어떻게 정합니까?

마이크로서비스의 경계를 정할 때 가장 중요한 요인은 적용 범위와 종속성입니다. 일반적으로 단일 팀(일반적으로 5~10명)이 다른 서비스나 팀의 도움을 받지 않고 서비스를 소유, 관리, 확장, 배포할 수 있을 정도로 작은 범위로 만드는 것을 목표로 합니다. 대개 팀의 역량을 고려하여 경계를 정하게 되며, 일반적으로 단일 데이터 또는 비즈니스 분야로 한정됩니다. 서비스의 규모는 서비스를 소유한 팀의 소유권과 자율성만큼 중요하지 않습니다. 예를 들어 결제 금액을 보내거나 요청하는 기능을 제공하는 결제 마이크로서비스의 경우 보통 API라고 하는 서비스 인터페이스에 의해 서로 연결되는 스토리지, 통합 및 컴퓨팅 구성 요소로 구성됩니다. 이 서비스는 단일 팀이 효과적으로 소유하고 관리할 수 있습니다.

Q: 바로 클라우드로 마이그레이션해야 합니까? 아니면 먼저 모놀리스식에서 벗어나야 합니까?

기업은 클라우드로 마이그레이션하기 전에 리팩터링해야 한다고 생각하며 전환 프로세스를 시작하는 경향이 있습니다. 마이그레이션하기 전에 반드시 리팩터링해야 하는 경우도 있지만, 리팩터링을 최소화하여 최소한의 작업으로 마이그레이션할 수 있는 가장 빠른 경로를 찾는 것이 좋습니다. 현실적으로, 클라우드와 사내에서 리팩토링을 수행할 경우 애플리케이션의 최종 아키텍처와 구성이 크게 달라집니다. 예를 들어 클라우드에서 AWS 빌딩 블록을 사용하여 다른 방식으로 리팩터링할 수 있습니다. 또한 클라우드 내 인프라의 온디맨드 가용성을 통해 투자 비용을 절감하고 보다 안전하게 리팩터링 및 테스트를 수행할 수 있습니다.

Q: 모던 아키텍처는 어떻게 보안을 강화해줍니까?

마이크로서비스 자체가 자율적인 소규모 팀이 소유하고 운영할 수 있는 소규모 시스템을 제공할 뿐만 아니라, 마이크로서비스 구축에 사용되는 기술도 자동화, 확장 및 보안을 위한 새로운 기회를 제공합니다.

AWS 고객 Travellex는 모던 아키텍처가 어떻게 보안을 강화하는지 보여주는 좋은 사례입니다. Travellex는 130개 국가에서 사업을 운영하며 환전 서비스로 전 세계적으로 신뢰받고 있는 기업입니다. 이 회사는 모놀리식 온프레미스 데이터 센터 모델에서 벗어나 현재보다 릴리스에 주기(연간 8회)를 단축하고 보안을 강화하기를 원했습니다. 수십 년간 재무 규정에 대응해온 경험이 있지만 클라우드 워크로드에 대한 승인을 받는 것은 새로운 도전이었습니다.

향상된 보안 기능을 갖춘 설계 덕분에 Docker 및 Amazon Elastic Container Service와 AWS Key Management Service, Amazon VPC, Amazon Web Application Firewall을 포함한 보안 제어 프레임워크를 이용하여 마이크로서비스 아키텍처를 승인받고 배포할 수 있게 되었습니다. 이 고객은 자동화되고 감사 가능하며 조작이 불가능한 배포 파일을 생성하고 있습니다. 또한 보안 침해에 따른 피해를 줄이기 위해 24시간 후에 모든 컨테이너를 폐기하고 새 보안 인증서를 사용해 재배포하는 프로세스를 설계했습니다. 따라서 중요한 구성이 유실 또는 도용될 경우 피해가 최소화됩니다. 이전의 주기가 긴 모델에서처럼 연간 8회가 아니라 주당 수백 회도 배포할 수 있게 되었으며, 자동화를 구현한 덕분에 전반적인 보안 상태도 강화되었습니다.

Q: 소유권과 자율성을 지원하려면 팀을 어떻게 구성해야 합니까?

Amazon에는 피자 두 판 팀이 있습니다. 피자 두 판 팀이라고 부르는 이유는 피자 두 판으로 모든 팀원이 배불리 먹을 수 있는 규모, 즉 5~10명으로 이루어진 팀이기 때문입니다. 이들 팀은 애플리케이션에 대해 완벽한 소유권과 자율성을 부여받으며, 애플리케이션을 제공하는 데 필요한 모든 역량을 갖추고 있습니다. 따라서 핸드오프, 팀간 커뮤니케이션, 종속성이 최소화됩니다. 클라우드로 전환하면서 애자일 방식과 DevOps 방식을 도입하는 조직이 늘고 있습니다. 이 같은 방식과 기술은 독자적으로 활용할 때도 가치를 제공할 수 있지만, 진정한 민첩성을 실현하고 제공하는 가치를 극대화하기 위해 조직들은 이들 방식을 피자 두 판 팀 개념과 결합하여 속도와 자율성을 극대화합니다. 결국, 이 같은 혁신에서 피자 두 판 팀의 효과를 극대화하려면 기존과 다른 행동과 다른 구조를 필요로 합니다. 따라서 전형적인 공유 서비스 모델은 구축하는 서비스를 소유하고 운영하는 팀에 유리하게 축소되는 경향이 있습니다.

일례로 Cox Automotive는 전사적으로 SAFe(확장형 애자일 프레임워크)를 구현하고, 전체 환경을 AWS로 전환하고, “구축한 주체가 운영까지 맡는” 환경으로 발전시킴으로써 인력, 프로세스, 기술의 혁신에 착수했습니다. Cox Automotive는 Scrum, Kanban 또는 기타 애자일 방법론을 사용하는 소규모 팀을 구성했으며, 소유권과 자율성을 높이기 위해 대개 팀을 8~10명의 인원으로 구성했습니다. 이는 Amazon의 피자 두 판 팀과 매우 유사합니다. Cox Automotive는 공동 제공, 운영 및 기술 전략을 구현함으로써 SAFe 상위 수준에 제품, 엔지니어링, 아키텍처 및 비즈니스 리더 팀을 구성하여 IT와 비즈니스를 통합할 수 있었으며, 결과적으로 더욱 투명한 협업 환경을 구축할 수 있었습니다. 이 모델은 우선 과제의 연관성을 제시하고, 고객 문제를 해결하기 위한 컨텍스트를 팀에 제공했습니다. 

Q: 팀은 어떻게 재교육해야 합니까?

많은 기업들이 계속 변화하는 개인과 조직의 성숙도에 따라 지속적인 교육 프로그램을 구축합니다. 클라우드를 처음 도입할 때는 안전한 시작 환경, 비용 관리, 클라우드 서비스 및 서버리스와 같은 개념에 초점을 맞춘 기본 교육을 권장합니다. 이후 조직 전반에서 학습과 아키텍처의 진화를 유도하기 위해 Well Architected Reviews를 활용해야 합니다. 클라우드 기반이 구축되면 DevSecOps를 포함한 애자일 방식으로 전환하면서 소프트웨어 개발 수명주기와 자동화에 대한 교육을 시작할 수 있습니다. 교육은 기업의 출발점에 따라 달라질 수 있습니다.

Q: 과도기의 아키텍처와 조직 구조에서 보다 전략적인 형태로 전환하기 위해 필요한 기본 요소는 무엇입니까?

전략적인 형태를 실행하기 전에, 경영진의 참여와 동의, 변화에 초점을 맞추는 조직들을 많이 봅니다. 혁신은 경영진의 행동과 지원의 직접적인 결과로서 그 성패가 좌우되는 경향이 있습니다. 많은 조직이 보다 전략적인 혁신 활동을 시작하기 전에 클라우드, 애자일 개발 및 DevOps 방식에 섣불리 투자합니다. 교육은 새로운 기술이나 방식을 채택하는 데 있어 중요한 부분이지만, 궁극적으로는 행동을 바꾸고 소위 고속도로의 게이트에서 가드레일로 이동하는 것이 비즈니스 민첩성을 높이는 길입니다. 오늘날의 고속도로를 생각해 보십시오. 차선, 진입로 및 출구, 추월 차선 및 제한 속도가 표시되어 있습니다. 차는 밤낮 가리지 않고 자유롭게 드나들 수 있고 궁극적으로는 다른 도로보다 훨씬 빨리 이동할 수 있게 됩니다. 팀을 위해 바로 이런 환경을 만들어야 합니다. 모두가 규칙을 알고 빠르고 유연하게, 그리고 지속적으로 시행할 수 있는 환경 말입니다. 이를 실현하기 위해 필요한 활동과 신념을 확고히 이해하는 것은 리더에게 있어 중요한 출발점입니다.

Q: 마이크로서비스 아키텍처를 유의미한 수준으로 도입하기 전에 어떤 문화적 변화를 실현해야 합니까?

제품 또는 서비스에 대한 자율성과 소유권을 가진 소규모 팀으로 조직 구조와 제공 방식을 구성하는 것이 이상적입니다. 문화나 조직 구조를 변경하지 않고도 마이크로서비스를 도입할 수 있지만, 서비스를 실제 도입할 지지자를 확보하고 중복을 방지하기가 어려울 수 있습니다. 응집력 있는 전략이나 제공 모델이 없다면 결과는 달라질 것입니다. 변화에 접근하는 최적의 유일한 방법은 없지만, 분명 잘못된 방법은 많습니다. 성취하고자 하는 목표에 초점을 맞추는 것으로 시작해야 합니다. 해결하려고 하는 문제는 무엇이며, 문제가 성공적으로 해결되었는지 어떻게 알 수 있을지 고민해보십시오. 거기서부터 작게 시작해서 계속 반복하십시오.

Q: 팀에 CI/CD를 도입하려면 무엇부터 시작해야 할까요?

현대화가 진전됨에 따라, CI(지속적 통합) 및 CD(지속적 배포) 도구를 활용하면 급격한 변화와 관련한 위험을 최소화할 수 있습니다. 실제로 대부분의 조직은 지속적 통합부터 시작하여, 처음 몇 개의 애플리케이션을 수동으로 프로덕션 환경에 구축하고 릴리스 프로세스에 착수하기 위한 최종 인적 점검 단계를 그대로 유지할 수 있습니다. 서로 통신하는 소수의 서비스가 있거나 특별한 통신 기능이 필요한 기존 애플리케이션으로 통합하는 복잡한 작업을 수행해야 할 경우에 비로소 CI를 고려해야 합니다. 운영 방식의 성숙도가 높아지고 자동화가 확대됨에 따라, 조직은 일반적으로 릴리스에 대한 자신감이 높아지고 자동화된 안전 점검에 더욱 익숙해지게 됩니다. 일반적으로 이때 수동 단계를 없애면서 CI/CD로 전환하게 됩니다.

Q: 가치 제공을 가속화할 수 있는 열쇠는 무엇일까요?

속도를 높이는 가장 간단한 방법은 작업의 범위를 줄이는 것입니다. 시간, 에너지, 돈을 가장 가치 있는 활동에 집중하는 것뿐만 아니라, 무엇을 할 것인지 선택하고, 그 우선순위를 꾸준히 학습하고 수정하는 데 능숙한 조직일수록 가치 제공을 가속화하는 데 탁월한 능력을 발휘합니다. 도움이 되는 몇 가지 도구, 기법, 기술이 있습니다. 우선 인프라, 보안, 구축, 테스트 및 롤백을 자동화하는 지속적 제공 파이프라인을 만드는 것부터 시작할 수 있습니다. 이를 통해 배포의 일관성을 높이고, 복구 및 변경에 소요되는 평균 시간을 단축하는 동시에 배포 빈도를 높일 수 있습니다. 클라우드에서는 작업에 적합한 도구를 선택하면서 운영 및 유지 관리 작업을 오프로드할 수 있습니다. 이는 조직에 적합하지 않은 솔루션을 구축하게 되는 문제를 방지하면서 가치에 초점을 맞추는 데 도움이 됩니다. AWS Lambda, AWS Fargate 또는 Amazon DynamoDB 같은 완전관리형 서비스와 서버리스 오퍼링을 선택하여 운영 및 유지 관리 부담을 덜 수 있습니다. 업무에 적합한 도구에 집중하고 획일적인 작업을 최소화함으로써 비즈니스와 고객의 가치를 높이는 솔루션을 구축하는 데 더 많은 시간을 할애할 수 있습니다. 또한 솔루션을 단순화함으로써 변경 비용을 절감하고 전환 및/또는 반복하는 속도를 높일 수 있습니다.

Q: Lambda 및/또는 컨테이너를 사용해야 할지 여부는 어떻게 결정합니까?

AWS Lambda와 컨테이너를 선택하여 민첩성을 극대화한 모던 애플리케이션을 구축하는 고객이 늘고 있습니다. 고객의 선택은 워크로드의 복잡성, 일반적인 작업 실행 시간 및 호출 패턴에 따라 크게 달라집니다. 컨테이너는 애플리케이션 설정보다 뛰어난 이식성과 유연성을 제공하기 때문에 가장 인기 있는 패키징 코드 옵션이자 기존 애플리케이션을 현대화하는 데 있어 훌륭한 도구입니다. Lambda를 사용하면 가장 편리합니다. 고객이 작성할 코드가 비즈니스 로직뿐이기 때문입니다.

컨테이너는 코드, 구성 및 종속성을 단일 개체로 패키징하는 표준 방법을 제공하므로, 어디서나 실행하고, 빠르게 확장하고, CPU 및 메모리 활용도를 세부적으로 설정할 수 있습니다. 실제로 대부분의 컨테이너 워크로드는 모두 AWS에서 실행됩니다. 컨테이너를 실행하려면 Amazon EC2 또는 AWS Fargate 같은 컴퓨팅 서비스가 필요합니다. Fargate는 컨테이너를 서버 없이 실행할 수 있게 해줍니다. Amazon ECS나 Amazon EKS 같은 오케스트레이션 서비스도 필요합니다.

Lambda는 S3에 추가된 새 파일 또는 DynamoDB의 새 테이블 항목과 같은 이벤트 또는 트리거에 대한 응답으로 코드를 실행하거나, API를 호출하여 직접 코드를 실행합니다. Lambda에는 115개의 이벤트 트리거가 있는데, 이는 시장의 다른 어떤 솔루션보다 많은 수입니다. 고객이 코드를 업로드하기만 하면, Lambda에서 높은 가용성으로 코드를 실행 및 확장하는 데 필요한 모든 작업이 처리됩니다. 고객은 사용한 컴퓨팅 시간만큼만 비용을 지불하면 되고, 코드가 실행되지 않을 때는 요금이 부과되지 않습니다. 고객은 서버를 프로비저닝하거나 관리하지 않고 사실상 모든 유형의 애플리케이션 또는 백 엔드 서비스의 코드를 실행합니다.

Q: 어떤 컨테이너 오케스트레이션 서비스를 선택해야 합니까?

운영 편의성 또는 애플리케이션 설정 제어와 관련한 기업의 현재 전문성 수준과 선호하는 옵션에 따라 달라집니다. 운영 부담을 최소화하기 위해서는 서버를 관리하지 않고도 컨테이너를 실행할 수 있는 유일한 컴퓨팅 엔진인 AWS Fargate를 권장합니다. Fargate를 사용하면 컨테이너 이미지를 구축하고 실행할 방법과 위치를 정의할 수 있으며, 리소스에 대한 요금을 지불하면 됩니다. 따라서 올바른 인스턴스 유형을 선택하거나, 인스턴스에 보안, 패치 및 업그레이드를 적용하거나, 클러스터를 확장할 필요가 없습니다.

Amazon ECS는 고객이 AWS 구성에 익숙하고, 주로 컨테이너 인프라의 일부로 AWS 도구 및 서비스를 사용하려는 경우 컨테이너를 실행하기에 가장 적합한 서비스입니다. ECS는 처음부터 완전히 새롭게 구축되었고 로드맵이 완벽하게 제어되므로, IAM, CloudWatch, Auto Scaling, Secrets Manager 및 Load Balancer와 같은 AWS 서비스와 기본적으로 빠르게 통합할 수 있을 뿐 아니라 컨테이너를 배포하고 확장할 수 있는 친숙한 환경을 제공합니다.

Kubernetes를 실행하는 방식을 원한다면, 클라우드에서 Kubernetes를 가장 안정적으로 실행할 수 있는 Amazon EKS를 추천합니다. EKS는 여러 AWS 가용 영역에 걸쳐 실행되어 이중화와 복원 능력을 기본적으로 제공하므로 신뢰할 수 있습니다. 또한 EKS 고객에게 항상 최신 보안 패치가 적용되도록 합니다. 즉, 최신 버전의 픽스를 따로 추출해 지원되지 않는 버전에 적용하여 EKS 애플리케이션의 안정성 및 가용성 문제를 방지합니다.

Q: 직접 관리하는 것보다 서버리스 기술을 선택하는 편이 효과적인 경우는 언제입니까?

귀사의 핵심 역량이 인프라와 운영을 관리하는 것이 아닌 한, 고객에게 이익이 되는 혁신에 주력할 수 있도록 해당 작업을 오프로드하는 것이 좋습니다. 대부분의 AWS 고객은 사용하지 말아야 할 특별한 이유가 없다면, 서버리스 기술을 이용하는 서버리스 우선 접근 방식을 취하고 있습니다. 서버리스 기술을 사용할 경우 복잡한 기반 인프라 관리 작업의 부담이 사라져 개발자가 비즈니스 로직에 집중할 수 있게 됩니다. 애플리케이션을 구성하는 기능에 대해 잘 알고 있는 경우, 서버리스 기술을 개별 구성 요소로 분해하여 개발자가 결과에 집중하도록 할 수 있습니다.

Q: 서버리스 기술을 사용하는 것이 멀티 클라우드 전략에 영향을 미칩니까?

서버리스 기술을 사용하기로 하는 결정은 클라우드 공급업체를 선택하기 위한 전반적인 결정의 일부분이며, 다중 클라우드 전략에 점진적으로 영향을 미치지는 않습니다. 클라우드 전략을 계획하는 과정에서 기업들은 클라우드에서 워크로드를 2~3개 공급업체 간에 비교적 균등하게 나눌 것으로 생각하고 시작하는 경우가 많습니다. 하지만 실제로 평가 과정에 돌입하면 그렇게 되는 경우는 매우 드뭅니다. 대부분 여러 가지 이유로 단일 공급업체를 선정합니다. 우선, 여러 클라우드에서 실행하기가 쉽지 않습니다. 개발 팀이 여러 클라우드 플랫폼에 능숙해야 한다는 문제 때문입니다. 또한 팀이 특정 공급업체의 더 포괄적인 기능을 활용하기 보다, 일반적으로 사용되는 가장 낮은 수준의 플랫폼으로 표준화하도록 만듭니다. 마지막으로, 클라우드 공급업체 간에 워크로드가 분산되면 고객의 구매력과 볼륨 할인 혜택이 그만큼 작아집니다. 따라서 대부분의 고객은 주로 단일 인프라 또는 클라우드 공급업체를 선택합니다.

Q: 보안은 모던 애플리케이션으로 어떻게 강화됩니까?

모던 애플리케이션 설계의 핵심 요소는 개발 프로세스의 "초기에 자주" 보안을 통합하는 것입니다. 기획, 설계, 개발, 테스트, 출시 단계에서 보안, 위험 및 규정 준수 요인이 고려됩니다. 주요 보안 제어 기능의 자동화와 CI/CD 파이프라인의 보안 트리거는 개발 프로세스에서 보안을 고려하게 해줄 뿐만 아니라 수작업(테스트 및 수정)의 필요성을 없앱니다.

Q: 클라우드 및 모던 애플리케이션으로 전환하면 보안 방식과 옵션이 어떻게 바뀝니까?

모던 애플리케이션에서는 인프라가 코드로 존재하는 것처럼 보안도 코드로 적용됩니다. 보안 제어와 인프라 모니터링의 적용을 자동화하는 능력을 갖추게 되는 것은 많은 조직에게 획기적인 변화입니다. 이를 통해 자가 복구 인프라를 설계하고 구축할 수 있습니다. 또한 서버리스 기술을 사용하면 잠재적으로 취약한 코드가 필요할 때만 실행되기 때문에 애플리케이션의 공격 경로가 크게 감소합니다.

일례로, 추가로 1,000개의 비즈니스 크리티컬 애플리케이션과 데이터베이스를 AWS로 마이그레이션하고 있었던 Verizon은 보안 검증 프로세스를 확장할 방법이 필요했습니다. 인프라 팀뿐만 아니라 수천 명의 개발자가 클라우드 리소스에 직접 액세스할 수 있도록 해야 했습니다. 또한 개발자들이 하드웨어 및 보안 점검을 기다리지 않고 고객에게 새로운 가치를 제공하는 데 시간을 더 할애할 수 있도록 제약을 없애야 했습니다. 이에 자동화된 보안 검증 프로세스를 개발했고, 덕분에 팀이 원하는 일정으로 새로운 애플리케이션을 개발할 수 있게 되었습니다. 이 프로세스의 1단계에서는 배포하는 데 사용하기 전에 기본 구성 규칙을 분석하여 암호화, 로깅, 액세스 권한 구성을 확인합니다. 2단계에서는 검증된 템플릿을 테스트 환경에 배포하여 실시간 검증을 수행하고, AWS 기본 구성 서비스를 사용하여 배포된 시스템 구성을 감사합니다. 마지막으로 3단계에서는 3P 취약성 평가를 실행하여 누락된 OS 패치 또는 기타 취약성을 확인합니다. 이러한 단계가 모두 완료되면, 이 프로세스에서는 결과에 디지털로 서명하고, 자동 배포 파이프라인 검사에서 애플리케이션을 프로덕션 환경에 배포하도록 승인할지 여부를 결정하며, 이 검증 프로세스를 통과한 애플리케이션만 배포합니다.

Verizon의 자동화된 보안 검증 프로세스는 고객이 어떻게 자동화와 AWS 클라우드를 사용하여 팀 내에서 자율성을 확보함으로써 비즈니스 민첩성을 높이고 안전하고 신속한 전환을 지원하고 있는지 보여 주는 예입니다. 

Q: 서버리스 환경에서 실제로 보호하게 되는 대상은 무엇입니까? 도구와 프로세스가 변경됩니까?

여기서 주안점은 두 가지로 요약할 수 있습니다. 첫째는 모범 사례(예: OWASP 10대 규칙)에 따라, 개발/실행 중인 애플리케이션 코드에 보안을 적용하는 것이고, 둘째는 자격 증명, 탐지 제어, 인프라 보안, 데이터 보호 및 인시던트 대응에 초점을 맞춘 클라우드 모범 사례에 따라, 제어하는 인프라에 보안을 적용하는 것입니다.

Q: 이 새로운 환경에서 기존 보안 정책을 어떻게 구현해야 합니까?

많은 기업들이 보안 성과나 제어 목표에 집중하고, 보안을 특정 제품이나 서비스와 동일시하지 않으면서 목표를 실현함으로써 성공을 거두고 있습니다. 일반적으로 이를 위해서는 더 광범위하고 보안 및 규정 준수 목포에 더 초점을 맞춘 보안 정책을 다시 작성해야 합니다. 운영 설명서 수준에서는 보안 목표를 충족하거나 초과 실현하도록 플랫폼의 제어 방식을 구현하는 방법을 관련 정책을 통해 자세히 설명합니다.

Q: 어떤 데이터베이스가 용도에 가장 적합한지 평가하려면 어떻게 해야 합니까?

고객은 특정 성능 및 비즈니스 요구 사항을 충족하는 확장 가능하고 고성능의 기능을 갖춘 애플리케이션을 구축하기를 원한다고 말합니다. 애플리케이션을 지원할 데이터베이스를 선택할 때 고객은 데이터 모델 및 데이터 액세스 패턴뿐만 아니라 이러한 요구 사항도 고려해야 합니다.
이러한 다양한 고객 요구 사항을 충족하기 위해, AWS는 다음과 같이 특별히 구축된 다양한 데이터베이스 서비스를 제공합니다.

• Amazon RDS는 완전관리형 관계형 데이터베이스에 적합하고, Amazon Aurora는 상용 관계형 데이터베이스와 Amazon Aurora Serverless처럼 지속적으로 개선되는 기능 세트에 적합합니다.
• Amazon DynamoDB는 어떤 규모에서도 10밀리초 미만의 성능을 제공하는 키-값 및 문서 데이터베이스입니다.
• Amazon Neptune은 그래프 데이터베이스용 서비스입니다.
• Amazon DocumentDB는 MongoDB 워크로드를 지원하는 완전관리형 문서 데이터베이스입니다.
• Amazon Timestream은 IoT(사물 인터넷) 및 운영 애플리케이션을 지원하는 시계열 데이터베이스 서비스입니다.
• Amazon Quantum Ledger Database(QLDB)는 특별히 구축된 원장 데이터베이스입니다.
• Amazon Aurora Global Database는 여러 AWS 지역에 걸쳐 구축되지만 일반적인 1초 미만의 지연 시간으로 쓰기를 복제합니다.

Q: 기존 데이터베이스와 장기 라이선스 계약을 보유하고 있습니다. 모던 데이터베이스로 마이그레이션하는 프로세스를 시작하려면 어떻게 해야 할까요?

Database Freedom은 적격 고객이 기존 데이터베이스 엔진에서 AWS 기반의 클라우드 네이티브 엔진으로 마이그레이션하도록 지원하기 위해 고안된 고유한 프로그램입니다. Database Freedom은 클라우드용으로 구축된 Amazon Aurora(MySQL 및 PostgreSQL) 호환 관계형 데이터베이스, PostgreSQL, MySQL 및 MariaDB용 Amazon RDS, Amazon Redshift, Amazon DynamoDB, Amazon EMR, Amazon Kinesis, Amazon Neptune, Amazon QLDB, Amazon Timestream 및 Amazon DocumentDB로의 마이그레이션을 지원합니다. 또한 AWS Schema Conversion Tool과 AWS Database Migration Service는 고객이 데이터베이스를 이들 서비스로 신속하고 안전하게 마이그레이션하는 데 도움이 될 수 있습니다.
AWS는 적격 고객을 대상으로 애플리케이션 아키텍처, 마이그레이션 전략, 프로그램 관리, 그리고 기술 환경과 마이그레이션 목표에 따라 맞춤화된 직원 교육에 대한 자문을 제공합니다. 또한 마이그레이션의 실행 가능성을 보여주는 개념 증명도 지원합니다.

아울러, AWS Professional Services 팀과 Database Freedom Partners 네트워크를 통해 적격 고객이 AWS로 마이그레이션할 수 있도록 지원해 드립니다. 이들 팀과 조직은 다양한 데이터베이스 기술을 전문으로 하며 수천 개의 데이터베이스, 애플리케이션 및 데이터 웨어하우스를 AWS로 마이그레이션하여 얻은 풍부한 경험을 제공합니다. 마이그레이션의 재정적인 영향을 최소화하기 위해 적격 고객에게 서비스 크레딧도 제공합니다.

지금까지 3M, Verizon, Capital One, Intuit, Ryanair, Amazon.com 등의 고객이 데이터베이스의 속박에서 벗어나도록 지원한 풍부한 경험이 있습니다.

Database Freedom에 대해 자세히 알아보고 AWS에 문의하려면 여기에 접속하시기 바랍니다.