글쓰는 감자

• Route 53 호스팅 영역에 레코드 생성

(현재 나는 aws 상에 호스팅 영역이 있다. 구매했었음.)

호스팅 영역에 들어가 레코드 생성을 해보자.

원하는대로 설정해준다..

나는 CloudFront로 해당 도메인을 사용해 정의할 예정이다.(CloudFront 배포를 이미 생성했음.)

• CloudFront 배포 설정

생성해둔 배포 설정으로 들어간다.

대체 도메인 이름에 아까 Route 53에서 생성했던 레코드를 넣어주고 해당 사용자 정의 SSL 인증서도 받아야 한다.

• AWS ACM 인증서 생성

AWS ACM을 통해 쉽게 생성이 가능하다. ACM을 생성할 땐 해당 인증서로 들어가서 인증서에 맞게 레코드 생성을 또 해줘야 한다.(Route 53 레코드에 해당 인증서에 대한 CNAME 레코드가 생성되어야 함.)

변경 사항을 저장하고 조금 더 기다린 뒤에 대체 도메인 이름을 사용해 들어가보자!

CloudFront + S3 배포

• S3 버킷 생성

버킷 이름만 정해주고 버킷을 생성한다.(다른 옵션들은 나중에 다뤄볼 것!)

test page를 작성해 객체 업로드(진짜 간단하게 작성해도 괜찮다.)

• CloudFront 배포 생성

해당 원본 도메인을 방금 생성한 버킷 도메인으로 설정한다.

다음으로 S3 버킷 액세스는 OAI를 사용할 수 있도록 체크하고 제어 설정 생성을 해준다.

(왜 갑자기 S3 버킷 정책을 수동으로 업데이트 하게 되는지 모르겠지만... aws가 업데이트가 되었나?)

CloudFront와 S3는 HTTP 연결을 하고 있고 우리가 할 최종 목표는 사용자와 CloudFront의 HTTPS 연결이니까 프로토콜을 Redirect로 해주자.(상황에 맞춰서 설정해주면 된다.)

기본값 루트 객체를 써 넣으면, 도메인 뒤에 따로 써주지 않아도 처음 들어갔을 때 해당 객체로 들어간다.

배포 생성을 누르면 아래와 같이 정책을 업데이트 하라고 뜨는데 해당 정책 복사를 클릭하고 업데이트 해주면 된다.

• S3 버킷 정책 업데이트

버킷 권한에서 버킷 정책을 편집하면 된다. 아까 복사해뒀던 정책을 넣어주자.

배포가 완전히 적용될 때 까지 잠깐 기다렸다가 생성한 배포 도메인을 복사해 붙여주면 원하는 test page를 확인할 수 있다.

CloudFront + EC2 배포

• EC2 생성

원하는 웹페이지나 테스트 페이지를 넣고 EC2에 올린다.(이거는 가볍게 apache 서버 올려서 테스트를 진행했다.)

보안 그룹이나 이런 것들도 잘 열어줘야 한다..(HTTP(80), HTTP(443), TCP(8080), SSH(22))

해당 인스턴스의 퍼블릭 IPv4 DNS를 복사해두자. (어차피 테스트 용으로 만든 거라 삭제 예정)

• CloudFront 배포 생성

S3와 같이 원본 도메인에 해당 복사해둔 퍼블릭 IPv4 DNS를 넣어주자.

(현재는 테스트라 ec2로 했는데 이중화를 원하거나 가용성을 원하면 ALB 구성이 필요하다.)

프로토콜 역시 원하는대로 선택하고 그냥 배포 생성하면 된다.

이것 또한 배포 도메인으로 웹 페이지를 확인할 수 있다.

CloudFront + EC2 + S3 (Multi Origin) 배포

아까 생성했던 CloudFront + EC2 배포에 추가 해보자.

해당 배포로 들어가 원본을 추가하자.

• 원본 생성

아까 설정했던 대로 S3 버킷 정책 업데이트까지 진행하자.

• 동작 생성

경로 패턴의 경우 아까 난 S3 버킷에 test.html 파일을 넣어두었기 때문에 해당 경로로 설정했다.

상황에 맞게 경로를 설정하자.

해당 설정까지 마치면 원본 2개, 동작 2개가 있어야 맞다.

조금 기다린 후 배포도메인만 사용하면 ec2의 화면이, 배포도메인/test.html 로 들어가면 s3의 화면이 나온다.

3-Tier Architecture?

어떤 플랫폼을 3 계층으로 나누어 별도의 논리적/물리적인 장치에 구축 및 운영하는 형태

•  
• Presentation Tier
  • 사용자가 직접 마주하게되는 계층
  • 주로 사용자 인터페이스 지원 → GUI, front-end
  • HTML, Javascript, CSS, 사진 자료 등
• Application Tier
  • 요청되는 정보를 어떠한 규칙을 바탕으로 처리하고 가공하는 것들을 담당 → Business Logic, Transaction 계층
  • 클라이언트 계층 관점에선 서버처럼 동작(응답), 세 번째 계층 관점에선 클라이언트처럼 행동(요청) → Middleware, back-end
  • PHP, Java 등 / API 호출
• Data Tier
  • 데이터베이스에 접근하여 데이터를 읽거나 쓰는 것을 관리 → DBMS(Database Management System)
  • back-end
  • MySQL, MongoDB 등
• 장점
  • 보다 신속한 개발: 각 계층이 서로 다른 팀에서 동시에 개발 가능
  • 확장성 개선: 필요에 따라 독립적으로 확장 가능
  • 안정성 향상: 한 계층의 가동 중단이 다른 계층에 영향이 없음
  • 보안성 강화: 프리젠테이션 계층과 데이터 계층이 직접 통신할 수 없으므로, 잘 설계된 애플리케이션 계층은 내부 방화벽의 일종으로 작동

웹 개발의 3계층 애플리케이션

• Web Server
  • 프레젠테이션 계층
• Application Server
  • 사용자 입력을 처리하는 데 사용되는 비즈니스 로직을 수용하는 중간 계층
• Database Server
  • 웹 애플리케이션의 데이터 또는 백엔드 계층

실습

1. VPC 구성
2. AZ 구성
3. Subnet 구성
4. Internet Gateway 구성
5. Route Table 구성
6. Web Server Tier: Private Subnet 안에 Web Server 역할을 할 수 있는 인스턴스 구축
7. Web Application Tier: Private Subnet 안에 Web Application 역할을 할 수 있는 인스턴스 구축
8. DB 구성
9. SSH 접근
10. WEB, WAS, DB에 대한 연동 확인
11. Load Balancer
12. Auto Scaling
13. IAM 관리자 설정