AWS S3 WebHosting이 가진 특성과 주의사항들을 소개하고 이들을 응용하여 OneClick으로 AngularJS 같은 Single Page Application을 배포하는 방법을 소개합니다. - 이 발표는 2017 AWS Community Day에 발표한 자료입니다.

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
윤제상, CTO (HBSmith Inc.)
AWS S3를 이용한 효과적인 SPA 배포
S3 Website Hosting의 특성과 주의사항

2. 본 강연에서 다룰 내용
AWS S3와 SPA의 정의
S3 Website Hosting의 특성과 주의사항
OneClick으로 S3에 SPA 배포하는 방법

3. 소개

4. 안녕하세요 SW 개발자 윤제상 입니다
(전) 삼성전자 무선사업부 서비스 개발팀 선임연구
원
(전) 주식회사 카니자랩 CTO
(현) HBSmith Inc. CTO
링크드인: jesangyoon
GitHub: @yoonjs2
Email: yoonjs2@hbsmith.io
Blog: https://medium.com/@yoonjs2

5. S3 그리고 SPA의 정의

6. S3: Simple Storage Service
•Cloud 기반의 Object File System
•특징
•MetaData, Key & Value
•장점
•저렴한 비용, 무제한 용량, 빠른 속
도
•단점???
•고기용성: 최근 장애로…

7. SPA: Single Page Application
•HTML 기반 Web Application
•특징
•Ajax + Template = Dynamic Contents
•Index.html 단일 페이지에서
동적으로 DOM을 변경하여 컨텐츠를 보여줌
•대표 Framework
•AngularJS, BackboneJS 등등…
•장점
•높은 코드 재 사용성, 데이터 절약, 높은 생산
성

8. S3에서 HTML을 호스팅하는 방법
•S3를 Apache Web Server 처럼 사용가능
•설정방법
•S3 Bucket에 웹 콘텐츠 업로드
•Bucket Policy 설정: GetObject 권한부
여
•Enable website hosting 켜기
•장점
•S3의 모든 장점 + 웹서버 관리부담 Zero

9. S3 Website Hosting의 특성과 주의사항

10. 문제 1: SPA Routing이 동작안함
•URL따라 페이지를 동적으로 생성해주는 기능
•http://foobar.com/#!/product -> 상품 View 보여줌
•http://foobar.com/#!/cart -> 카트 View 보여줌
•특징
•동적으로 생성되기 때문에 실제 파일이 있는 주소가 아님
•html5mode를 이용, URL에서 보기싫은 ‘#!’ 문자를 제거할수
있음
(‘#!’ 포함된 주소는 Google에서 deprecated 됨)
•문제
•# 이 없으면 웹서버, S3 모두 HTTP 404만 반환
(존재하지 않는 페이지를 가져오려고 시도한 것으로 간주)
•존재하지 않는 페이지를 존재하는 것처럼 만드는 방법은?
http://foobar.com/#!/mypage
/index.html
mypage
http://foobar.com/mypage
/index.html
????

11. 문제 2: Eventual Consistency 발생
•S3는 고가용성을 위해 데이터를 분산 복제하므로 다음 특성이
존재
•Read after Write Consistency
•새로운 Key로 업로드한 데이터는 분산복제가 끝나기 전엔
읽어올수 없음
•신규 업로드 PUT 시 해당
•Eventual Consistency
•빠른 응답성능 위해 데이터가 모든 곳에서 동기화 되기전엔
과거 데이터를 읽어올수도 있음
•덮어쓰기 PUT, DELETE 시 해당
•문제
•모든 유저가 같은 최신 Contents를 볼수 있도록 하는 법?
A A A
B B A
B
B

12. 문제 1의 대안: Redirection Rule 응용
•S3의 Redirection Rule 기능을 사용하여 대응가능
•트릭
•404 Not Found가 발생할 경우 Error Page 대신
특정 패턴의 URL로 이동하도록 하는 기능을 응용
•단점
•‘#!’ 이 잠시 노출됨
•주의
•https를 명시적으로 붙여주지 않으면
앞단에서 https를 강제해도 http로 접속가능하게 됨
요청을 보냄
S3 Routing 때문에
잠시 # 주소로 이동
AngularJS의
HTML5 mode 때문에
#이 제거됨

13. 문제 2의 대안: Eventual Consistency 회피
•Read after Write Consistency를 응용하여 회피가능
(덮어쓰기 하지 않고 매번 새로 파일을 올리는 식으로)
•Cache Breaker 전략을 쓰자
•S3에서 제공되는 웹 컨텐츠 파일들의 이름에
Timestamp 또는 데이터 Hash 값(MD5, SHA1, …)을 붙여
서
업로드 될때마다 Object Key가 바뀌게 함
•Cache Breaker 전략을 못쓴다면?
•index.html 같이 Object Key가 변경되면 안되는 파일들은
CloudFront/CDN 등에서 Purge 또는 Invalidate 시켜
강제로 최신 컨텐츠가 빨리 배포될수 있게 해줌
•장점
•SPA 처럼 index.html 하나에서
모든 웹 컨텐츠를 동적으로 불러오는 형태일 경우 매우 유리
(index.html 하나만 Eventual Consistency를 신경쓰면 됨)
파일 내용에 대한 MD5 해시값을 계산하여 Key 값을 변경
= 변경사항이 있는 파일만 분산복제 끝나고 공유
= 최신 Contents를 모든 유저가 똑같은 시점에 확인

14. S3로 One Click SPA 배포

15. Bucket 간 Sync 응용한 배포
•Bucket간 S3 Sync를 이용하여 Web Contents를 배포
•테크닉
•임시 저장용인 Bucket A 생성, 웹서비스용인 Bucket B 생성
•Bucket A에 Publish된 Web Contents 업로드
•AWS CLI S3 sync 사용하여 Bucket A의 내용을
Bucket B에 덮어쓰기
•Bucket B의 Root에 있는 파일들을 CDN Cache에서 Purge
•추가 팁
•—delete 옵션으로 Bucket A 에 없는 Bucket B의 내용을 청소
더이상 사용되지 않는 파일을 삭제, S3 용량 절약
•장점
•Jenkins/TravisCI 내에서 Git, Grunt/Gulp와
AWS CLI sync를 엮어 완전한 SPA 배포 자동화를 실현 가능
Bucket A Bucket B
퍼블리싱 작업
컨텐츠 최적화
보안처리
Cache Breaker 적용
S3 Sync
Cache
Purge

16. HBSmith에선 어떻게 하는가?
1) Git 클론
2) Grunt 빌드 (유닛 테스트 및 퍼블리싱)
3) Bucket A로 복사
4) Bucket A 에서 Bucket B로 싱크
7) CDN Cache 삭제
$ aws s3 cp . s3://xxx-ap-northeast-2-xxxx/web/xxxx --recursive
$ aws s3 sync s3://xxx-ap-northeast-2-xxxx/web/xxxx s3://foobar.com --delete
5) [안해도 됨] Bucket B의 태그 업데이트 (배포된 Source의 Git 버전 추적용)
6) Bucket A 청소
$ grunt build
$ aws s3api put-bucket-tagging --bucket foobar.com --tagging TagSet=[…]
$ aws s3 rm s3://xxx-ap-northeast-2-xxxx/web/xxxx --recursive
$ curl -X DELETE https://api.cloudflare.com/client/v4/zones/xxx/purge_cache
이 모든 과정이
운영 Git 브랜치가
업데이트 되면 CI로
자동 수행됨
개발자는 운영 Branch
Merge만 신경쓰면 됨

17. 주의: 계정간 Bucket Sync 의 맹점
•AWS CLI S3 명령어는 계정간에 적접 Object를 이동시킬때
Object Metadata의 Canonical ID를 알아서 변경해주지 않음
(이 내용은 문서화가 잘 되어있지 않아 실수할 가능성이 있음)
•문제상황
•계정 A의 Object X를 계정 B의 버켓으로
CLI를 통해 버켓간에 직접 이동시키면 (cp, mv, sync)
X의 소유주 Canonical ID는 여전히 계정 A가 됨
•따라서 X는 계정 B에 존재하지만,
계정 B의 Root ID로도 접근할수 없는 Object가 되어버림
(삭제밖에 안됨)
•대응
•이런 현상을 막으려면 Access Delegation 을 이용하여
계정 B에서 계정 A의 X를 접근할때 Canonical ID를
계정 B의 것으로 변경할수 있도록 허용해 줘야 함
•자세한 내용: https://goo.gl/ukQNbs
Bucket 1
소유주
User A
Bucket 2
소유주
User B
S3 Sync
X
X
소유주: User A
소유주: User B
소유주: User A

18. 마무리
- S3 Website Hosting의 특성을 알고 사용해야 당황하지 않는다.
- SPA 특성상 S3와 궁합을 위해서 몇가지 조정이 필요하다.
- 요런것들만 갖춰진다면 S3로 강력한 Website Hosting이 가능
하다.
S3 Loves Website Hosting

19. 본 강연이 끝난 후…
API 개발팀을 위한 모니터링 서비스 HBSMITH의
Early Bird 유저를 모집하고 있습니다.
https://goo.gl/EdoRUJ <- 클릭하여 신청하세요!
아직도 AWS KRUG 가입하지 않으셨다구요?
https://www.facebook.com/groups/awskrug/
저희 사이트에서 AWS팁 가져가세요!
홈페이지: http://bit.ly/2rFzuhS
블로그: https://medium.com/@yoonjs2

20. @awskrug
#AWSKRUG 해시태그로 소셜 미디어에 여
러분의 행사 소감을 올려주세요.