AWS S3를 이용하여 AngularJS 같은 Single Page Web Application을 효과적으로 배포하는 방법을 소개합니다.

1. AWS S3를 이용한 효과적인 SPA 배포
윤제상 (yoonjs2@hbsmith.io)
HBSmith
2017.4.5

2. 발표자 소개
• 윤제상 (Jesang Yoon)
• (현) HBSmith Co Founder, CTO
• (전) Kanizsa Lab CTO
• (전) 삼성전자 무선사업부 선임연구원
• 연락처
• LinkedIn: jesangyoon
• GitHub: @yoonjs2
• Email: yoonjs2@hbsmith.io
• Blog: https://medium.com/@yoonjs2

3. S3: Simple Storage Service
• Simple Storage Service
• 클라우드 기반의 Object File System
(MetaData, KeyValue, One level)
• 저렴한 비용, 큰 용량, 빠른 접근
• 고가용성: 최근 장애로 좀…

4. SPA: Single Page Application
• HTML 기반 Web Application
• Ajax + Template = Dynamic Contents
• index.html 단일 페이지에서
동적으로 DOM을 변경하여
컨텐츠를 보여주는 형태
• AngularJS, BackboneJS 등
• 높은 코드 재 사용성, 데이터 절약, 높은 생산성

5. S3에서 HTML 호스팅하기
• S3를 Apache Web Server 처럼 사용
• Bucket Policy: GetObject
• Enable website hosting
• S3의 높은 가용성 + 서버관리 부담 Zero

6. 문제: SPA Routing
• SPA의 Routing 기능은
URL따라 페이지를 동적으로 생성
• 동적으로 생성되기 때문에
웹서버 상에 실제 존재하지 않는 페이지임
(Angular에서 #으로 시작하는 주소)
• html5의 history 기능(html5mode)을 이용할 경우
‘#’문자 제거 가능 (#은 deprecated 됨)
• #이 없으면 웹서버에서 존재하지 않는 페이지를 가져오
려고 시도한 것으로 간주하여 404 Not Found를 반환
• 존재하지 않는 페이지를 존재하는 것처럼 만드는 방법은?
http://foobar.com/#/mypage
http://foobar.com/mypage
/mypage/index.html
200 OK 404
Not Found
/index.html
200 OK

7. 문제: Eventual Consistency
• S3는 고가용성을 위해 데이터를 분산 복제
• 빠른 응답성능을 위해
데이터가 모든 곳에서 동기화 되기전엔
과거 데이터를 읽어올수도 있음
(덮어쓰기 PUT, DELETE)
• Read after Write Consistency:
새로운 Key로 업로드한 데이터는
분산복제가 끝나기 전엔 읽어올수 없음
(신규 PUT)
• 업데이트를 해도 과거 데이터가
다운로드 되는 문제를 해결할 방법은 없을까?
(모든 유저가 가급적 최신 컨텐츠를 볼수 있도록)
key: x key: x
User A User B
덮어쓰기

8. SPA Routing in S3
• S3의 Redirection Rule 기능을 사용하여 구현가능
• 404 Not Found가 발생할 경우
Error Page 대신 특정 패턴의 URL로
이동하도록 하는 기능을 응용
• 단점: #!이 잠시 노출됨
• 주의: https를 명시적으로 붙여주지 않으면
앞단에서 https를 강제해도 http로 접속가능하게 됨 Request
S3 Routing
HTTP 301 Redirect
HTML5 mode
(#! 제거)

9. Eventual Consistency 회피
• S3의 신규 Key를 가진 Object에 대한
Read after Write Consistency를 이용
(처음 업로드 하는 파일들에 대한)
• S3에서 제공되는 웹 컨텐츠 파일들의 이름에
Timestamp 또는 Hash 값(MD5, SHA1, …)을 붙여서
계속 Key가 바뀌게 함
• Index.html 같이 Key가 변경되면 안되는 파일들은
CloudFront/CDN 등에서 Purge 또는 Invalidate 시켜
강제로 최신 컨텐츠가 빨리 배포될수 있게 해줌
• 주의: SPA 처럼 index.html 하나에서
모든 컨텐츠를 불러올수 있는 경우에 유리한 방법
(index.html 하나만 Eventually Consistency를 신경쓰면 됨)
파일 내용에 대한 MD5 해시값을 계산하여 이용
: 변경사항이 없을 경우 Eventually Consistent Read의 장점을 이용가능
(빠른 컨텐츠 제공)

10. Bucket간 sync를 응용한 SPA 배포
• AWS CLI S3 sync 명령어로 bucket 간
내용 동기화가 가능
• sync를 이용, source bucket의 내용으
로 target bucket의 내용을 채움
• —delete 옵션으로 source bucket에 없
는 target bucket의 내용을 청소가능
• Jenkins/TravisCI 내에서 Git, Grunt/
Gulp와 AWS CLI sync를 엮어 완전한
SPA 배포 자동화를 실현 가능
Source bucket Target bucket
(Web Hosting Enabled)
퍼블리싱 작업
컨텐츠 최적화
보안처리
Cache Breaker 적용
S3 Sync
Purge
Cache

11. 주의: 계정간 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
계정 A 계정 B
S3 Sync
X X
CID: A CID: A

12. 더 많은 자료는
페이스북 AWS KRUG 그룹
또는
https://medium.com/@yoonjs2
에서
얻어가세요~