Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

AWS S3를 이용한 효과적인 SPA 배포

1 517 vues

Publié le

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

Publié dans : Logiciels
  • Login to see the comments

AWS S3를 이용한 효과적인 SPA 배포

  1. 1. AWS S3를 이용한 효과적인 SPA 배포 윤제상 (yoonjs2@hbsmith.io) HBSmith 2017.4.5
  2. 2. 발표자 소개 • 윤제상 (Jesang Yoon) • (현) HBSmith Co Founder, CTO • (전) Kanizsa Lab CTO • (전) 삼성전자 무선사업부 선임연구원 • 연락처 • LinkedIn: jesangyoon • GitHub: @yoonjs2 • Email: yoonjs2@hbsmith.io • Blog: https://medium.com/@yoonjs2
  3. 3. S3: Simple Storage Service • Simple Storage Service • 클라우드 기반의 Object File System
 (MetaData, KeyValue, One level) • 저렴한 비용, 큰 용량, 빠른 접근 • 고가용성: 최근 장애로 좀…
  4. 4. SPA: Single Page Application • HTML 기반 Web Application • Ajax + Template = Dynamic Contents • index.html 단일 페이지에서
 동적으로 DOM을 변경하여 
 컨텐츠를 보여주는 형태 • AngularJS, BackboneJS 등 • 높은 코드 재 사용성, 데이터 절약, 높은 생산성
  5. 5. S3에서 HTML 호스팅하기 • S3를 Apache Web Server 처럼 사용 • Bucket Policy: GetObject • Enable website hosting • S3의 높은 가용성 + 서버관리 부담 Zero
  6. 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. 7. 문제: Eventual Consistency • S3는 고가용성을 위해 데이터를 분산 복제 • 빠른 응답성능을 위해 
 데이터가 모든 곳에서 동기화 되기전엔
 과거 데이터를 읽어올수도 있음
 (덮어쓰기 PUT, DELETE) • Read after Write Consistency:
 새로운 Key로 업로드한 데이터는 
 분산복제가 끝나기 전엔 읽어올수 없음
 (신규 PUT) • 업데이트를 해도 과거 데이터가 
 다운로드 되는 문제를 해결할 방법은 없을까?
 (모든 유저가 가급적 최신 컨텐츠를 볼수 있도록) key: x key: x User A User B 덮어쓰기
  8. 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. 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. 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. 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. 12. 더 많은 자료는 페이스북 AWS KRUG 그룹 또는 https://medium.com/@yoonjs2 에서 얻어가세요~

×