🌈 [Section4] 10. [Cloud] 운영 환경 구성

📕 오늘 배운 내용!

• 클라우드 컴퓨팅 (Cloud Computing)
• Deploy
• EC2 (Elastic compute Cloud)
• RDS (Relational Database Service)
• S3 (Simple Storage Service)
• 3 Tier-Architecture 배포 전략

---

✏️ 클라우드 컴퓨팅 (Cloud Computing)

• 인터넷(클라우드)을 통해 컴퓨팅 서비스를 제공하는 서비스
  Ex. 서버, 스토리지, 데이터베이스 등을 제공

• 기업에서 직접 리소스를 조달하거나 구성, 관리할 필요 X

• 데이터 센터와 비슷한 역할을 하지만 물리적인 컴퓨터가 아닌, 가상의 컴퓨터를 대여하여 사용
  ( 가상화(Virtualization) 기술 사용 )

[참고] https://cloud.google.com/learn/what-is-cloud-computing?hl=ko

✔ 클라우드 서비스의 장점

• 필요할 때마다 컴퓨팅 능력 유연하게 조절 가능

• 사용한 만큼의 요금만 지불
  ( 온프레미스는 고정적인 비용이 들어감 )

• 컴퓨터의 스냅샷(이미지)을 이용해 다른 컴퓨터로 즉시 이주(migration) 가능

  Ex. 저번에 컴퓨터 SSD 바꾸러 갔을 때, 컴퓨터 스냅샷 이용해서 깔려있는 어플들 그대로 있을 거라고 했었음

✔ 클라우드 서비스의 단점

• 운영환경 자체가 클라우드 제공자에게 종속
  ➜ 클라우드 서비스 자체에 문제가 생길 경우, 내가 배포/관리 해야하는 환경에도 영향을 미침

  💡 운영환경이 특정 클라우드 사업자(vendor)에게 종속
  ➜ 백엔드 구성 자체가 특정 회사의 기술로만 구성해야하는 경우가 발생할 수도 있음

✔ 클라우드 서비스 형태

⭐ 온-프레미스 (On-premise)

• 소프트웨어 등 솔루션을 클라우드같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치하여 운영하는 방식

• 데이터 센터에서 제공하는 서버의 자원과 공간, 및 네트워크 환경

• 첨부터 끝까지 다 내가 구성 관리 해야함

• 고정적인 관리 비용 들어감

✔️ 클라우드 vs 온프레미스
⠀
✔️ 클라우드

• 사용한 만큼 + 초기 비용 없이
• 확장성 유리
• 구축에 걸리는 시간이 빠름

---

✔️ 온프레미스

• 초기비용 + 유지비용
• 확장성 불리
• 구축에 걸리는 시간이 꽤 됨

⭐ IaaS (Infrastructure as a Service)

• 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우

• 하드웨어의 기본적인 IT 자원만 제공 (컴퓨팅 리소스를 네트워크를 통해 제공)
  ➜ 사용자가 운영체제/미들웨어/런타임/데이터 등을 직접 구성하고 관리해야함
  ( 새로 컴퓨터를 구매하는 개념 )

  Ex. 아마존의 AWS(Amazon Wed Service), 마이크로소프트의 애저(Azure), 구글의 GCE(Google Compute Engine) 등

  ✔️ IaaS 장점

  • 물리적 자원을 서비스 형태로 사용하기 때문에 고정비가 들지 않음
  • 물리적 자원에 대한 규모의 확장과 축소가 자유로움

  ---

  ✔️ IaaS 단점

  • 구축에 전문성이 필요
  • 유지보수의 범위가 넓음

⭐ PaaS (Platform as a Service)

• 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우

• 개발자를 대상으로 제공
  ➜ 코드만 개발해서 배포하면 고객에게 서비스 할 수 있는 환경 제공

  Ex. 플랫폼 호스팅을 제공하는 Heroku, 레드햇의 OpenShift, 구글 앱 엔진, 마이크로소프트 애저(Azure) 등

  ✔️ PaaS 장점

  • 필요한 플랫폼만 소비 형태로 사용하기 때문에 초기 비용 / 시간 절감 가능
  • 개발 및 배포 프로세스 빠르게 확보 가능
  • 서비스 / 애플리케이션 개발에 전념 가능

  ---

  ✔️ PaaS 단점

  • 특정 플랫폼 서비스에 종속될 수 있음
  • 개발 환경의 커스터마이즈 가능성이 낮음

⭐ SaaS (Software as a Service)

• 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우

• 대부분을 클라우드사에서 제공하는 형태

• 별도의 설치 과정이 필요 X
  ➜ 인터넷 네트워크에만 연결되어 있으면 제공되는 서비스를 이용 가능

  Ex. 네이버 클라우드, 구글 드라이브, MS Office 365, 노션 등

  ✔️ SaaS 장점

  • 필요한 서비스를 구독 즉시 사용 가능
  • 시간 / 장소에 구애받지 않고 사용 가능

  ---

  ✔️ SaaS 단점

  • 명확하게 제약이 걸려있어 커스터마이징 불가

참고 1
참고 2

✔️ 피자로 예를 들면

• On-site ➜ 내가 하나부터 열가지 다 만들어 먹기
• IaaS ➜ 밀키트/냉동피자같이 기본적인 건 갖춰져 있고 내가 거기에 행동을 더해 먹기
• PaaS ➜ 피자를 배달시켜 먹기 / 나는 먹을 장소만 있으면 됨
• SaaS ➜ 내가 준비할 건 아무것도 없고 그냥 가서 먹으면 됨

---

✏️ 소프트웨어 배포 (Deploy)

• 소프트웨어 시스템을 사용할 수 있도록 만드는 모든 활동
• 최종 사용자에게 소프트웨어를 전달하는 과정

✔ 서비스 배포 과정

1. Development

• local 환경에서 개발/테스트하는 과정

• 실제 데이터가 아닌 더미 데이터를 이용하여 테스트

• 변경사항이 있어도 문제 X

• 모든 구성원이 각자의 환경에서 진행

2. Integration

• 각자의 환경에서 작성된 코드를 합치는 과정

• 코드 간 conflict가 없는지 확인하는 단계

3. Staging

• 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트 진행

• 실제 데이터를 복사해서 다양한 환경에서 테스트

• 모든 관계자들이 검증하는 단계

4. Production

• 개발된 서비스를 출시하는 단계
  -> 문제가 생기면 안되는 단계

• 사용자가 접속 가능한 Production 환경에서 코드를 구동하고 서비스 제공
  ( 개발 환경과는 구분된 환경 )

❗ Development 환경과 Production 환경이 서로 다를 수 있기 때문에,
환경 설정을 코드와 분리하는 것이 중요 !

✔ 작성 코드가 다른 환경에서도 정상 작동할 수 있게 하려면

• 설정을 환경 변수에 저장
  ➜ 코드 변경 없이 배포 때마다 쉽게 변경 가능
  ➜ 잘못해서 코드 저장소에 올라갈 가능성 낮음

  💡 환경변수 - environment variable / envvars / env라고도 불림

• 절대경로 대신 상대경로 사용

• 환경에 따라 포트를 분기할 수 있도록 환경변수 설정
  Ex. application-server.yml

• 개발 환경 자체를 통일시키는 솔루션 사용
  Ex. Docker와 같은 가상화 도구를 사용하여 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경 통일

---

✏️ EC2 (Elastic compute Cloud)

• AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스

• 사용한 만큼의 비용 지불

• 필요에 따라 성능/용량 자유롭게 조절 가능

✔️ Elastic
➜ 탄력(신축성)있는, 유연한

💡 AWS EC2 인스턴스를 생성한다
➜ AMI를 토대로 운영체제 / CPU / RAM / 런타임 등이 구성된 컴퓨터를 빌리는 것
( ➜ 컴퓨터로 할 수 있는 일 모두 가능 )
⠀
But, 이 빌린 컴퓨터는 아마존의 데이터 센터(인프라)에 만들어져 있어서
네트워크(인터넷)을 통해 컴퓨터 제어해야함

✔️ 인스턴스
1대의 컴퓨터를 의미하는 단위
⠀
💡 인스턴스를 생성한다 == AWS에서 컴퓨터를 빌리는 것

✔ EC2 장점

• 구성하는데 필요한 시간이 짧음
  ( 몇번의 클릭만으로 PC 구성 가능 )

• 용도에 따라 다양한 운영체제에 대한 선택 가능
  ➜ EC2에서 제공하는 AMI로 필요에 따라 손쉽게 운영체제를 선택하고 구성 가능
  ( 운영체제뿐만이 아니라 CPU / RAM / 용량까지도 손쉽게 구성 가능 )

  ✔️ AMI (Amazon Machine Image)

  • 인스턴스를 생성하는 데 필요한 소프트웨어 구성이 포함된 템플릿
    Ex. 운영체제 / 애플리케이션 서버 / 애플리케이션
    ⠀⠀
  • AMI를 통해 사용 용도에 맞게 운영체제 / 런타임 등이 구성된 Setting 가능
    ⠀⠀
  • 이미지 종류로는 단순히 운영체제만 깔려있는 템플릿을 선택할 수도 있고,
    아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있음
    Ex.
    • 운영체제만 깔려있는 템플릿 - 윈도우/우분투 리눅스 등
    • 특정 런타임이 설치되어 있는 템플릿 - 우분투 + node.js, 윈도우 + JVM
      ⠀⠀
  • 많은 양의 Image가 AWS에 준비되어 있고,
    선택된 Image를 바탕으로 Instance의 운영체제가 결정됨
    ( 이미지는 그냥 운영체제 + 버전, 런타임 + 버전 등이 정해져있는 거라고 생각하면 됨 )

---

✏️ S3 (Simple Storage Service)

• AWS에서 제공하는 클라우드 스토리지 서비스

  ✔️ 클라우드 스토리지 (Cloud Storage)
  ➜ 인터넷 공간에 데이터를 저장하는 저장소
  Ex. 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스
  ⠀
  ✔️ 장점

  • 뛰어난 접근성
    ➜ 웹 환경이라면 언제 어디서나 저장된 파일에 접근 가능
    ( 굳이 컴퓨터가 아니어도 웹 접속이 가능하면 다른 전자기기도 가능 )

  ---

  ✔️ S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스

  • Standard 클래스
    • 범용적인 목적으로 사용하기 좋음
    • 데이터에 빠른 속도로 접근 가능
    • 데이터 액세스 요청 처리 속도가 빠름
    • But, 보관 비용이 높게 발생하기 때문에 데이터를 오래 보관하기엔 좋지 않음
      ⠀
  • Glacier 클래스
    • 장기적인 보관 목적으로 사용스
    • 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴
      ⠀
  • 이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등이 존재

✔ S3 장점

• 뛰어난 접근성

• 높은 확장성
  ➜ 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소 가능

• 데이터 무한히 저장 가능 / 사용한 만큼 비용 지불
  ➜ 비용적 측면에서 매우 효율적

• 강력한 내구성 (99.999999999%의 내구성 보장)
  ➜ 저장된 파일 유실 가능성 적어짐
  ( S3에 저장된 파일을 잃어버릴 확률보다, 길을 걷다 벼락맞을 확률이 700배나 더 큼 ㅋㅋ )

• 높은 가용성 (99.99%의 가용성 보장)
  ➜ 가용성이 높을 수록 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 기간이 길어짐

( 사진은 여기서 가져옴 )
⠀
✔️ 리전 (Region)

• AWS에서 클라우드 서비스를 제공하기 위해 운영하는 물리적인 서버의 위치
  ⠀
• 위 지도에서 주황색 동그라미 쳐진 지역
  ⠀
• 주황색 동그라미 안에 수 ➜ 리전에 위치한 가용 영역의 수

---

✔️ 가용 영역 (Availability Zone)

• 각 리전 안에 존재하는 데이터 센터(IDC)
  ⠀
• 가용 영역은 각각 개별적인 위치에 떨어져서 존재
  ( 한 곳의 가동이 불가능해지더라도 다른 곳에서 백업 데이터를 이용하여 문제 없도록 )

✔ S3 사용 시 이점

• 버킷을 통해 정적 웹 사이트 호스팅 가능

✔️ 정적 파일

• 서버의 개입 없이 클라이언트에 제공될 수 있는 파일

---

✔️ 동적 파일

• 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일

✔️ 웹 호스팅 (Web Hosting)

• 서버의 한 공간을 임대해주는 서비스
  ( 이 이 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스 배포 가능 )

✔️ 버킷

• 파일(객체)을 담는 바구니 (최상위 디렉토리)
• 무한히 많은 파일(객체) 저장 가능
• 버킷의 이름은 각 리전에서 고유해야함
• 버킷의 정책을 생성하여 액세스 권한 부여 가능

✔️ 객체

• 버킷에 담기는 파일
  ➜ S3에서 저장소에 데이터 저장할 때 키-값 페어 형식으로 데이터 저장하기 때문에 객체라고 함
• 파일 / 메타 데이터로 구성
  ➜ 파일 : 실제 데이터 저장 (최대 크기 5TB)
  ➜ 메타데이터 : 객체에 대한 정보가 담긴 데이터
• 모든 객체는 고유한 키 가짐 ( 식별자 역할 )
• URL 주소를 통해 객체에 접근 가능
  ➜ http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태
• 객체 고유 키, URL 주소 각각으로 원하는 데이터에 접근 가능

✔ 정적 웹 사이트를 호스팅하는 과정

1. 정적 웹페이지 빌드

2. 버킷 생성 및 정적 웹 사이트 호스팅 용으로 구성

3. 빌드된 정적 웹 페이지 업로드

4. 퍼블릭 액세스 차단 해제 및 정책 생성

---

✏️ RDS (Relational Database Service)

• AWS에서 제공하는 관계형 데이터베이스 서비스

• 데이터베이스 유지 보수 관련 일들을 자동 관리해줌
  ( 사용자가 해야할 일은 초기 설정 / 저장된 데이터 관리 뿐 )

• 다양한 데이터베이스 엔진 선택지 제공
  ➜ 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 선택하여 효율성 높일 수 있음
  Ex. MySQL / Oracle 등

💡 EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진 설치하지 않고,
굳이 데이터베이스만 따로 분리해서 RDS 서비스 이용하는 이유
⠀
➜ EC2 인스턴스 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적음
➜ 따라서, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업 등의 일을해야하고,
가용성과 내구성이 확보되지 않기 때문에
데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어려움 !

---

✏️ 3 Tier-Architecture 배포 전략

( 위 방식들 총 정리 )

✔️ client application 배포 방법

➜ AWS 서비스 중 하나인 S3를 사용하여 client application을 정적 파일로 빌드하여 사용자들에게 배포

💡 빌드 (Build)

• 불필요한 데이터를 없애고, 통합/압축하여 배포하기 최적화된 상태를 만드는 것
  ➜ 데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빨라짐
• 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정
• 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있음

✔️ Server Application 배포 방법

➜ AWS 서비스 중 하나인 EC2를 사용하여 손쉽게 서버를 구성하고 서비스 제공

💡 Server Application
➜ 사용자들이 제공받은 Client Application을 통해 요청을 전달하는 역할

❗ S3, EC2를 이용해서 배포된 서비스는 IP주소나 서비스와 상관없는 긴 도메인주소로 접근해야함
Ex. www.hello.ap-northeast-2.compute.amazonaws.com
⠀
➜ AWS에서 제공하는 Route 53 서비스를 이용하면,
직관적인 도메인 주소를 통해 서비스에 접근하도록 할 수 있음
Ex. www.hello.com

✔️ 데이터베이스 배포 방법

➜ AWS에서 제공하는 Database 특화 서비스인 RDS 서비스를 사용하여 자동 유지 보수 및 즉시 데이터베이스 사용이 가능하도록
EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스 배포 가능

❗ 결론적으로 배포는 대략 RDS ➜ EC2 ➜ S3 ➜ Route53 이 서비스들을 거쳐 완료됨 !

✔️ 빠르게 서비스 제공하는 방법

• AWS에서 제공하는 CDN 서비스인 CloudFront를 사용하여 사용자에게 콘텐츠를 더 빨리 배포 가능
  ➜ CloudFront를 통해 각지의 데이터센터에 데이터를 분산시켜 저장해두었다가 가까운 지엑에서 데이터를 주는 방식으로 빠르게 서비스 제공

---

😜 실습

AWS에서 EC2 / S3 / RDS 세가지를 연동하는 실습을 했다 !

사실 자세한 거 하나하나 적기가 힘들고 적는다면 사진까지 캡쳐해야할 부분이 너무 많아서 AWS에 들어가서 설정한 부분은 빼고 터미널로 내가 작성한 사진들만 가져왔다.

EC2 부분은 캡쳐를 못했기에 일단 넘어가도록 하고,

유어클래스 내의 클라이언트 배포 / 데이터베이스 연결 이 두개 실습만 보려고 한다 !

나머지는 유어클래스 - Section4 - [Cloud] 운영 환경 구성 부분을 참고하기 !

1. 일단 먼저 우분투를 켜서 nvm과 node.js를 설치한다.
( nvm은 수시로 바뀌는 node.js의 버전을 관리하기 위함 )

// nvm 설치
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
⠀
nvm --version // 잘 설치됐는지 버전 확인
⠀
// node.js 설치
nvm install 16
⠀
node -v // 잘 설치됐는지 버전 확인

2. 유어클래스의 Repository 클론 후, 해당 폴더의 client 폴더로 들어간다.
( 나는 fork하고 clone했는데, 그냥 clone해도 되는지는 모름 )

cd mnt/c/Users/USER/Desktop/git/be-sprint-deployment/clinet
// 우분투로 Desktop 들어갈려면 이렇게 들어가야함 !!! ( 이거 몰라서 1시간 헤맨듯 )
// 나는 Desktop의 git 파일에 clone 함

3. npm을 설치해준다.
( 클라이언트의 의존성 모듈 )

npm install

4. client 폴더 내의 .env.example 파일에 들어가서,
REACT_APP_API_URL= 뒤에 http:// + 내 EC2 서버 주소:포트번호를 작성한다.

5. 환경 변수 설정을 완료하고, 우분투로 돌아와서 아래 명령어를 입력한다.

npm run build

사실 처음에 에러가 떴었는데,
아까 설치해주었던 nvm 16 버전을 사용하기 위해 nvm use 16으로 nvm의 버전을 바꿔주고
다시 명령어 입력하면 잘 된다 !
( 실습 사진은 처음부터 16 버전을 설치한 것이 아니라 중간에 16 버전을 설치해주었다 )

6. 이렇게 빌드가 완료되면 client 폴더 내에 build 폴더가 생성된 것을 확인할 수 있다.

7. 이제 AWS 홈페이지의 S3 콘솔로 가서 정적 웹사이트 호스팅을 위해 여러가지 설정해주고,
( 유어클래스 - 클라이언트 배포 챕터 내의 S3 호스팅 튜토리얼 참고 )

8. S3 속성 맨 밑에있는 버킷 웹 사이트 엔드포인트의 주소로 들어가면 아래와 같이 로그인 화면을 볼 수 있다.

But, 이 화면은 아직 RDS 와 연결하지 않았기 때문에 로그인을 눌러도 응답하지 않는다.

9. RDS에서 데이터베이스를 생성해주고, 해당 엔드포인트의 주소를 복사해와서
터미널에서 MySQL을 실행해 아래 명령어로 연결한다.

mysql -u [마스터 이름] --host [엔드 포인트 주소] -P 13306(포트 번호) -p

✔️ MySQL 클라이언트를 통해 RDS의 DB 인스턴스에 연결을 위해 필요한 정보
1. DB 인스턴스 생성 시 기재한 마스터 이름, 마스터 비밀번호
2. 포트 번호
3. 생성한 DB 인스턴스의 엔드 포인트 주소

MySQL 터미널로 들어가서 했더니 명령어가 안먹는 게 있어서,
명령 프롬프트에 들어가서 하려고 했더니 MySQL과 연동이 안되어있길래
https://e2e2e2.tistory.com/22
위 링크대로 따라해서 환경변수에 추가를 해준 후에 실행하였다.

터미널을 열어서 mysql -u root -p 하고 비밀번호를 적으면 터미널에서 mysql을 사용할 수 있다고 한다 !

10. 위와 같이 연결해주었고 우리가 만든 데이터베이스의 이름인 test가 보이면 성공 !

11. 이제 EC2 인스턴스 터미널로 가서, 아래 명령어 치기.

bash // bash 쉘 사용
⠀
cd ~ // 루트 디렉토리로 이동
⠀
cd be-sprint-deployment/DeployServer/ // 이전 실습에서 clone하여 EC2와 연결한 레포로 들어가기
⠀
nano src/main/resources/application.properties
// application.properties 파일에 환경변수 설정하기
⠀
// 설정 완료 후
ctrl + x // 저장
y
enter

✔️ nano 해서 바꿔야할 것들은 ( 아래 사진 참고 )

• spring.datasource.url - AWS RDS '엔드포인트 주소:포트'가 들어가야 함
• spring.datasource.username - AWS RDS Mysql 마스터 사용자 이름
• spring.datasource.password - AWS RDS Mysql 마스터 암호
• config.domain - AWS S3 Endpoint 주소
  ( 꼭 앞에 http:// 포함 )
  ( CORS 설정을 위해 통신할 클라이언트의 도메인 입력이 필요 )

12. 환경 설정이 완료되면, 이전 빌드를 삭제하고, 다시 빌드를 진행한 이후에, 서버 다시 실행

./gradlew clean // 이전 빌드 삭제
⠀
./gradlew build // 빌드 진행
⠀
java -jar build/libs/DeployServer-0.0.1-SNAPSHOT.jar // 서버 실행

13. 이후, S3 엔드포인트 주소로 접속해서 로그인을 하면 아래와 같이 성공한 화면이 나옴 ~

참고로 만났던 에러 중에,
아래 사진과 같이 인스턴스의 퍼블릭 DNS 주소와 로그인 페이지에서 로그인을 한 후 F12를 눌렀을 때 보이는 에러 메세지의 리다이렉트되는 서버 주소가 달라서 에러가 난 적이 있었다.
⠀
➜ .env 파일에 주소를 다시 작성 후에 S3 설정도 다시 해보니 주소도 같아지고 응답이 잘 오는 것을 확인할 수 있었다 !

---

🌈 느낀점

AWS를 사용하여 인스턴스 서버를 하나 만들고 돌려보는 실습을 했는데 뭔가 바로바로 결과가 눈에 보여서 그런지 재밌었고,
근데 또 AWS에서 뭔가를 잘못누르거나 어떻게 돼서 과금되는 사람들이 많길래 좀 무섭기도 했다,,
사실 어제까지 괜찮았는데 오늘 S3 + RDS 실습하면서 에러를 너무 많이 만나서 사실 좀 고단한 하루였는데 그래도 정말 몇시간이고 걸려서 어떻게 잘 해결했다..!
하면서 내가 이해를 하면서 하는 건지는 모르겠지만 ..^^ 몰라 나도 ㅎ
곧 프로젝트라니 말도 안돼