개발 효율을 높이고 비즈니스 성과를 올리는 AWS 활용법 매우 쉽게 사용할 수 있다는 클라우드의 장점으로 새로운 시스템이나 인프라스트럭처를 구축할 때 클라우드 사용을 검토하는 비율이 높아졌다. 하지만 적절하게 리소스를 활용하면서 안정적으로 시스템을 유지하고 운용하는 것은 어렵다. 클라우드가 제공하는 혜택을 누리고 싶다면 구축하는 시스템을 정확하게 이해한 상태에서 클라우드 제공의 다양한 서비스를 효율적으로 조합하고, 팀을 적절하게 배치하며, 클라우드 서비스나 비용을 정확하게 통제하면서 클라우드에서만 할 수 있는 유지보수를 운용해야 한다. 이 책은 단순히 클라우드가 제공하는 서비스나 애플리케이션 나열에 그치지 않고, 개발 대상 서비스와 인프라스트럭처에 관계없이 시간이 지나도 적용할 수 있는 노하우를 제공한다. 1장에서 클라우드 특징과 클라우드가 가져온 시스템 개발의 변화를 살펴본 후, 2장과 3장에서 클라우드에서 제공하는 각 서비스 특징 및 서비스 선정 포인트를, 4장에서 올바른 비기능 요건 활용법을 알아본다. 5장에서는 1~4장까지의 노하우를 가상의 시스템에 적용하고, 6장에서는 직접 AWS 다중 계정 아키텍처를 구축해본다. 이어 7장에서 클라우드에서 구축한 시스템을 유지보수하는 방법을, 8장에서는 다양한 관점에서 클라우드 시스템을 올바르게 평가하는 방법을 설명한 후 클라우드 기반의 성공적인 개발 사례를 소개하면서 마무리한다. 클라우드만의 장점과 혜택을 충분히 만끽하고, 비즈니스에서 성과를 얻고 싶다면 바로 이 책을 펼쳐보자. 주요 내용 ● 클라우드의 기술적인 특징과 시스템 개발의 변화 ● 클라우드 서비스 선정 포인트 ● 올바른 비기능 요건 구현 ● 아키텍처링 판단 포인트 ● 다중 계정 아키텍처 구축 ● 클라우드로 구축한 시스템의 안정적인 유지 방법 ● 투자 대비 효과를 평가하는 방법

옮긴이 머리말 ix 베타리더 후기 xi 추천 서문 xii 이 책에 대하여 xiv 감사의 글 xix CHAPTER 1 클라우드 스탠다드 시대의 시스템 개발 1 1.1 시스템 개발에서 클라우드의 등장 3 __1.1.1 클라우드에 관한 사전 지식 3 __1.1.2 클라우드의 특징 6 __1.1.3 시간에 따른 클라우드 서비스의 변화 7 1.2 클라우드를 이용한 시스템 개발 8 __1.2.1 개발 현장의 상황 8 __1.2.2 클라우드의 등장이 IT 시장에 미친 영향 11 1.3 시스템 개발 체제 정비 방법 15 __1.3.1 시스템 개발 방법 선택 15 __1.3.2 개발팀 분리에 관한 사고방식 19 CHAPTER 2 아키텍처링에 관한 사고방식 23 2.1 아키텍처링의 필요성 25 __2.1.1 아키텍처 패턴 25 __2.1.2 아키텍처링에서 알 수 있는 것 29 2.2 클라우드 아키텍처 검토 31 __2.2.1 IaaS Only 31 __2.2.2 매니지드 서비스 활용 31 2.3 클라우드 아키텍처 참고 자료 33 __2.3.1 AWS Well-Architected Framework 33 __2.3.2 AWS 백서 및 안내서 34 __2.3.3 AWS Trusted Advisor 활용 35 CHAPTER 3 클라우드 아키텍처링과 서비스 선정 39 3.1 대상 서비스에 적합한 아키텍처링 41 __3.1.1 엔터프라이즈 계열 시스템(클라우드) 41 __3.1.2 웹 기반 모바일 애플리케이션 42 3.2 시스템 구축 시의 요건 43 __3.2.1 클라우드 네이티브 요건 43 __3.2.2 클라우드로의 마이그레이션 패턴 46 3.3 클라우드에서만 가능한 구성 52 __3.3.1 Well-Architected Framework 활용 52 __3.3.2 Auto Scaling 사용 여부 54 __3.3.3 매니지드 서비스 사용 여부 56 __3.3.4 VPC 연결 방법 57 __3.3.5 온프레미스와의 연결 59 __3.3.6 멀티 리전, 멀티 클라우드가 필요한가? 64 __3.3.7 업데이트 방식 검토 65 __3.3.8 AWS Marketplace 활용 67 3.4 기능 요건과 비기능 요건 69 __3.4.1 기능 요건 69 __3.4.2 비기능 요건 69 3.5 구현 및 운용 계획 시 유의점 71 __3.5.1 클라우드에서 시스템을 만드는 이유를 명확히 한다 71 __3.5.2 클라우드 이용 방침을 만든다 72 __3.5.3 AWS 서비스 업데이트 시 대응 방침 74 3.6 시스템의 대략적인 예상 비용 설정 76 __3.6.1 AWS Pricing Calculator 사용 방법 76 __3.6.2 더욱 정확한 예상 비용 설정 방법 81 CHAPTER 4 비기능 요건 노하우 83 4.1 계정 관리 85 __4.1.1 ‘계정’은 무엇을 가리키는가? 85 __4.1.2 AWS 계정 관리 86 __4.1.3 루트 사용자 관리 89 __4.1.4 IAM 사용자와 IAM 역할 관리 92 __4.1.5 예방 제어와 탐지 제어 97 4.2 가용성과 DR 100 __4.2.1 가용성 확보 100 __4.2.2 백업 전략 102 __4.2.3 DR 확보 104 4.3 클라우드 시스템에서의 성능 확보 110 __4.3.1 인스턴스 유형 선택 110 __4.3.2 스케일 업과 스케일 아웃 113 4.4 관측 가능성 확보 116 __4.4.1 시스템을 감시하는 목적은 무엇인가? 116 __4.4.2 로그와 트레이스 수집 121 __4.4.3 온프레미스에서 클라우드로의 모니터링 마이그레이션 125 __4.4.4 경고 취급 127 CHAPTER 5 클라우드 아키텍처링 포인트 131 5.1 시스템 요건 133 __5.1.1 설정한 가공의 요건 133 5.2 구성 검토 포인트 134 __5.2.1 다중 계정 아키텍처 134 __5.2.2 RTO/RPO에 맞춘 백업/DR 전략 135 __5.2.3 Auto Scaling 사용 여부 138 __5.2.4 비용 관리/절감 전략 139 __5.2.5 로그 취급 144 5.3 구축 시 검토 포인트 145 __5.3.1 어떻게 구축할 것인가? 145 __5.3.2 어디부터 만들 것인가? 146 CHAPTER 6 다중 계정 아키텍처 구축 151 6.1 실습 구성 153 __6.1.1 시스템 개요 153 __6.1.2 시스템 구성도 155 6.2 AWS 계정 준비 161 __6.2.1 관리 계정 설정 161 __6.2.2 AWS Control Tower를 이용한 다중 계정 환경 준비 172 __6.2.3 사용자에게 MFA 디바이스 이용을 강제한다 177 __6.2.4 사용자 등록 179 __6.2.5 AWS Control Tower를 이용한 멤버 계정 설정 194 __6.2.6 AWS IAM Identity Center 관리 권한을 로그인용 계정에 위임하기 197 __6.2.7 예산 설정 199 __6.2.8 AWS Security Hub 활성화 206 __6.2.9 Amazon GuardDuty 활성화 211 __6.2.10 멤버 계정의 Security Hub와 GuardDuty 활성화 214 CHAPTER 7 클라우드 시스템을 안정적으로 지속시키는 방법 217 7.1 클라우드와 온프레미스의 공통점 219 __7.1.1 물리 기기의 고장 219 7.2 클라우드만의 특징 221 __7.2.1 서비스 사양 변경 221 __7.2.2 장애 대응: 사고가 발생했다면 어떻게 하는가? 223 __7.2.3 비용 모니터링의 중요성 225 __7.2.4 AWS Support 활용 228 CHAPTER 8 클라우드 시스템을 올바르게 평가하는 관점 233 8.1 비용 관점 235 __8.1.1 인프라스트럭처 비용 관점 235 __8.1.2 인적 비용 관점 236 __8.1.3 시간적 비용 관점 238 8.2 보안 관점 239 8.3 운용 관점 241 8.4 비즈니스와 조직 관점 242 __8.4.1 비즈니스 관점 242 __8.4.2 조직 관점 243 CHAPTER 9 클라우드의 장점을 살린 개발 사례 245 9.1 인터넷 공개 웹사이트의 호스팅 247 __9.1.1 시스템 개요 247 __9.1.2 클라우드의 장점 활용 247 9.2 사내 시스템으로서의 데이터 분석 인프라스트럭처 251 __9.2.1 시스템 개요 251 __9.2.2 클라우드의 장점 활용 251 9.3 공개 사례: 주식회사 발 연구소 254 __9.3.1 시스템 개요 254 __9.3.2 클라우드의 장점 활용 254 9.4 공개 사례: 홋카이도 TV 방송 주식회사 256 __9.4.1 시스템 개요 256 __9.4.2 클라우드의 장점 활용 256 찾아보기 259

현재 클라우드를 전제로 하는 시스템 개발은, 그 목적 달성에 맞는 기술의 조합을 온프레미스의 그것과 비교해 훨씬 짧은 거리로 실현 가능하게 됐다고 느낍니다. 물론 클라우드라 하더라도 그 뒤에서는 실제 기기에서 동작하는 것을 상상할 수 있으므로, 기존의 개발 방법을 통해 학습한 지식을 활용할 수 있는 부분도 있습니다. 그러나 하나의 서비스를 구현하는 프로세스에 관해서는 간단하게 생각할 수 있게 됐습니다. 바로 이 속도감이 큰 매력이 됐으며, 오늘날 기술자(특히 초심자)들은 당연하게 대응하고, 단축한 시간은 다양한 서비스 향상을 위한 개선과 효율화 수행에 투입할 수 있게 됐으며, 비즈니스 측에서도 새로운 경험을 즉시 반영할 수 있게 됐습니다. (9쪽) 엔터프라이즈 계열 시스템에서는 이용하는 애플리케이션이 패키지 제품인 경우가 많아, 컨테이너와 마이크로서비스 아키텍처로는 대응할 수 없는 경우가 많습니다. 그렇기 때문에 EC2 인스턴스를 주축으로 아키텍처를 생각해야 합니다. 그 경우라도 데이터베이스는 매니지드 서비스를 이용할 수 있는 경우가 많으므로, 애플리케이션의 요건을 확인합시다. 그리고 애플리케이션의 라이선스 형식이 클라우드 이용에 대응하고 있는지도 확인해야 합니다. 물리 코어 수에 비례해 비용이 발생하는 라이선스 형식, OS 식별자 등에 연결된 라이선스 형식의 경우는 클라우드상에서 이용하면 비용이 높아지거나, 인스턴스 이미지를 복사해서 인스턴스를 실행하더라도 애플리케이션을 기동할 수 없을 수 있습니다. (41쪽) 클라우드로 만드는 시스템의 아키텍처, 최소한으로 필요한 가상머신 등 컴퓨팅 리소스 규모를 알았다면 AWS 예상 비용 도구를 사용해 얼만큼의 비용이 들 것인지 어림 계산합니다. 그리고 이제부터 예산 확보를 담당하지만 예상 비용을 내보지 않았더라도 가상머신만이라도 좋으니 AWS의 예상 비용 도구를 다뤄볼 것을 권장합니다. 예상 비용 설정 시에 어떤 매개변수가 필요한가를 미리 알아두면 예산 획득을 위해 무엇을 결정해야 하는지 알 수 있기 때문입니다. 실제 예상 비용의 어림 계산을 할 때는 아키텍처를 책정한 후 필요한 리소스의 매개변수를 결정하고, 예상 비용 도구를 사용해 어림 계산을 해서 예산 규모에 맞지 않으면 아키텍처나 리소스 매개변수를 변경하는 작업을 반복합니다. (77쪽) AWS 계정 하나라면 AWS의 서비스를 활용해 시스템을 구축할 수 있습니다. 하지만 권한 관리나 리소스 사이의 접근 관리 등과 같은 관리 업무의 번잡함을 피하기 위해 명시적인 환경 분리를 목적으로 여러 계정을 이용하는 경우가 많습니다. (...) 온프레미스 시스템이라면 개발용과 프로덕션용 환경을 물리적으로 나누면 예상 외의 변경이 발생하는 것을 방지할 수 있습니다. AWS 경우도 마찬가지입니다. 개발용과 프로덕션용으로 AWS 계정을 나누는 것이 좋습니다. 이렇게 여러 AWS 계정을 준비해서 시스템을 구성하는 것을 다중 계정 아키텍처(multi-account architecture)라 부릅니다. (86쪽) Security Hub와 GuardDuty 관리 권한을 위임한 AWS 계정을 사용해 다른 멤버 계정을 관리합니다. 이를 위해서는 AWS 접근 포탈에서 감사용 AWS 계정으로 로그인해야 합니다. 전환을 위해서는 먼저 감사용 AWS 계정(이번 실습에서는 Security OU 아래의 Audit)으로 대상을 변경하고, 6.2.4절 ‘사용자 등록’의 ‘그룹에 AWS 계정에 대한 권한 할당’ 순서를 따라 실행합니다. AWS 접근 포털에서 감사용 AWS 계정을 클릭해서 열고, ‘AWSAdministratorAccess’ 권한 세트의 [Management console]을 클릭하면 감사용 AWS 계정으로 로그인할 수 있습니다. (214쪽) AWS 데이터 센터는 제3자 인증을 받은 보안 대책이나 운용 체제를 제공하고 있으며, 데이터 센터 자체나 전기, 각종 하드웨어가 다중화돼 있음은 물론 예비 기기를 확보하고 있다는 점 또한 비용을 고려할 때 중요합니다. EC2 등에 설정할 수 있는 보안 그룹이나 디스크 암호화 등 AWS가 제공하는 가상머신의 동작 환경을 직접 준비하려면 많은 비용과 인력이 필요합니다. 클라우드 비용을 온프레미스와 비교할 때는 이러한 서비스나 기능이 포함된 것도 함께 고려해야 합니다. (235쪽)