본문 바로가기
Backend boot camp/Session4

[Cloud] 운영 환경 구성

by orioncsy 2022. 12. 9.

AWS Regulations

AWS 규정

클라우드 서비스 장점

  • 신속한 인프라 구축
  • 유연한 인프라 관리
  • 트래픽 폭주 대응
  • 글로벌 서비스
  • 강한 보안, 장애 없는 서비스
  • 합리적 가격

AWS 기능

Cloud Computing

기존 서버 방식

  • 전산실에 컴퓨터를 배치하고 인터넷을 연결하여 서비스 제공
  • 같은 공간에 더 많은 컴퓨터를 사용하거나 성능을 높이는 방식을 사용

기존 서버 방식 문제점

  • 주기적인 관리가 필요
  • 물리적인 공간 부족
  • 거대 기업이 데이터 센터를 세우고 자원을 대여하는 서비스 등장
  • 서버의 자원, 공간, 네트워크 환경 제공을 빌려 사용하는 클라우드 컴퓨팅 등장

클라우드 등장

  • 데이터 센터에서는 서버 자원의 공간, 네트워크 환경 제공(온프레미스)
  • 클라우드는 데이터 센터와 달리 가상 컴퓨터를 대여
  • 클라우드 서비스는 기존 온프레미스 방식과 달리 장점 존재
    • 필요할 때마다 컴퓨팅 능력 조절
    • 고정 비용이 들어가는 온프레미스와 달리 사용하는 만큼만 지불
    • 스냅샷을 이용해 다른 컴퓨터로 즉시 이주 가능

클라우드 환경의 단점

  • 운영 환경이 클라우드 제공자에게 종속
  • 클라우드 사업자에게 종속되어 클라우드 서비스에 문제가 생기면 영향을 받는다.

클라우드 서비스 제공 범위

  • SaaS : Software As A Service 네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스, 애플리케이션 지원
  • PaaS : Platform As A Service 네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스 지원
  • IaaS : Infrastructure As A Service 네트워크, 하드웨어 지원(AWS의 경우 해당)

Deploy

배포(Deployment) 과정

  • Development
    • 로컬 환경에서 개발 및 테스트
    • sample data(더미 데이터) 이용
    • 모든 구성원 각자 환경에서 진행
  • Integration
    • 각자 환경에서 개발된 부분 취합
    • 코드 간 conflict가 없는지 확인
    • 다른 코드에 문제를 발생시키지 않는지 확인
  • Staging
    • production 단계와 가장 유사한 환경에서 테스트
    • 복제된 실제 데이터를 이용해 테스트
    • 관계자들이 검증
  • Production
    • 개발환경과 구분된 환경
    • 실제 데이터 사용
    • 실제로 서비스가 제공되는 단계

Development 환경과 Production 환경 차이

  • 개발 환경과 production의 환경은 다를 수 있다.
  • 환경 설정을 코드와 분리해야 한다.
  • 작성한 코드가 다른 환경에서 작동하기 위한 방법
    • 절대 경로 대신 상대 경로 사용
    • 환경에 따라 포트를 분기할 수 있도록 환경 변수 설정
    • Docker와 같은 개발 환경 자체를 통일시키는 솔루션 사용

EC2

Amazon EC2(Elastic Compute Cloud)

  • 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스
  • 원격으로 제어할 수 있는 가상의 컴퓨터 한대를 빌리는 것
  • 인터넷을 통해 서버, 스토리지, 데이터베이스 등 컴퓨팅 서비스를 제공
  • 비용, 성능, 용량에서 탄력적인 클라우드 컴퓨터 제공

EC2 장점

  • 구성하는데 시간이 짧다.
  • 다양한 운영체제 선택 가능
  • CPU, RAM 용량 구성

Instance

  • AWS에서 빌리는 컴퓨터
  • 컴퓨터로 할 수 있는 일 가능
  • 컴퓨터를 조작하기 위해 네트워크를 통해 제어
  • 웹서버를 설치하과 웹 서버를 통해 사용자가 웹 브라우저를 통해 요청하는 서비스 제공

AMI

  • Amazon Machine Image는 소프트웨어 구성이 기재된 템플릿
  • 운영체제만 깔려있는 템플릿 부터 런타임 설치 템플릿(우분투 + node,js, 윈도우+JVM)까지 제공
  • 운영체제, 런타임으로 구성된 setting을 선택 가능

EC2 생성 의미

  • AMI를 토대로 운영체제,CPU, RAM, 런타임 구성된 컴퓨터를 빌리는 것

RDS

Relational Database Servcie

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

EC2 인스턴스에 설치된 DB 엔진 단점

  • EC2 인스턴스에 DB를 설치하여 데이터를 관리할 수 있지만 유지 보수에 대한 부담을 해야 한다.
  • EC2 인스턴스에서 데이터베이스 관련 자동으로 담당하는 부분이 매우 적기 때문에 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 진행해야 한다.
  • 가용성, 내구성이 확보되지도 않아 데이터가 유실되는 확률이 커지고 추후 확정도 어렵다.

RDS 장점

  • 데이터베이스 유지 보수에 대해서 자동 관리
  • 초기 설정만 사용자가 한다.
  • 데이터베이스 엔진을 다양하게 선택 가능

S3

Cloud Storage

  • 인터넷 공간에 데이터를 저장하는 장소
  • 웹 환경이라면 언제 어디서나 파일에 접근 가능

S3: Simple Storage Service

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

S3 장점

  • 확장성이 높아 보다 쉽게 스토리지 규모 확장/축소 가능
  • 사용한 만큼만 비용 지불하여 효율적
  • 내구성이 높아 저장된 파일을 유실할 가능성이 적어진다.(S3는 99.999999999%)
  • 가용성이 높아 저장된 파일을 정상적으로 사용할 시간이 길어진다.(99.99%)
  • 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버 위치
    • 가용 영역(Availability Zone)은 리전 안에 존재하는 데이터 센터(IDC)를 의미
    • 한 곳의 가용영역이 재난이나 사고가 나도 다른 가용 영역에 백업을 해놓아 문제없이 서버 구동
  • 다양한 스토리지 클래스 제공
    • standard vs Glacier 클래스
    • standard는 범용적인 목적으로 사용, 데이터 빠른 속도로 접근, 데이터 액세스 요청에 대한 처리 속도가 빠르나 보관 비용이 높음
    • Glacier의 경우 데이터 접근 속도 느리지만 보관 비용이 저렴
    • Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등 여러 스토리지 클래스
  • 정적 웹 사이트 호스팅이 가능
    • 정적 파일 : 서버의 개입 없이 생성된 파일
    • 동적 파일 : 서버에 요청을 보내면, 서버가 생성한 파일
    • 웹 호스팅 : 서버의 한 공간을 임대해 주는 서비스
    • S3에서 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간 제공
      • 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하여 정적 웹 사이트를 배포 가능
      • S3에 저장되는 모든 파일은 버킷 안에 저장되어야 하고 각각의 버킷은 이름을 가진다.
      • 버킷의 이름은 버킷이 속해 있는 리전에서 유일해야 한다.
      • 버킷 정책을 생성해 다른 유저의 접근 권한 수정 가능
      • S3에서 버킷에 담기는 파일을 객체라고 한다.
      • 데이터를 저장할 때 키-값 페어 형식으로 데이터 저장
      • 파일의 값에 실제 데이터 저장, 데이터의 최대 크기 5TB
      • 키는 고유 식별자 역할, 메타데이터는 객체의 생성일, 크기, 유형과 같은 객체 정보가 담긴 데이터
      • 모든 객체는 URL 주소를 가지고 있고 http://[버킷이름].S3.amazonaws.com/[객체키] 형태

3 Tier-Architecture 배포 전략

Client Application 제공

  • S3 서비스로 사용자들에게 client를 제공 가능
  • 로컬 환경에서는 자체 개발 서버를 이용해서 클라이언트 앱을 실행
  • 클라이언트 앱을 정적 파일로 빌드하여 제공

빌드

  • 불필요한 데이터를 없애고 퍼져있는 데이터들을 통합, 압축하여 배포하기에 최적화된 상태를 만드는 것이다.
  • 데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빠르다는 장점
  • 일반적인 의미의 빌드는 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미
    • HTML, CSS, JS의 형태로 배포하는 경우는 정적 파일 형태로 만들어야 한다.
    • asset 자체가 정적인 경우 그대로 배포
    • react의 경우 npm run build 명령으로 정적 파일 형태로 배포

CloudFront

  • AWS에서 제공하는 CDN(Content Delivery Network) 서비스
  • 데이터센터에 데이터를 분산시켜서 저장해 가까운 지역에 데이터를 주는 방식

Server Application

  • AWS EC2를 사용하여 서버 구성 및 서비스 제공

DB

  • RDS 서비스를 이용하여 즉시 데이터베이스 사용 가능

도메인 주소

  • 도메인을 통해 접속하려면 AWS에서 Route 53 서비스를 통해 직관적인 도메인 주소를 통해 서비스 접근 가능

서버 배포

EC2 Instance 연결

  • 인스턴스 탭에서 연결하고자 하는 인스턴스 선택 후 연결 버튼 클릭
  • Session Manager 연결을 클릭
  • bash를 입력하여 터미널 환경 접속
  • 연결 종료하고 싶을 시 종료 버튼 혹은 exit 입력

EC2 instance 서버 실행

인스턴스 개발 환경 구축

  • sudo apt update를 통해 패키지 정보 업데이트
  • sudo apt install openjdk-11-jre-headless를 통해 java 설치
  • SSH 등록
    • ssh-keygen을 입력하여 ssh 키 생성
    • cat ~/.ssh/id_rsa.pub를 통해 공개키를 복사
    • github에 settings에 ssh and GPG keys에 new ssh key에서 입력하고 등록

git을 통해 서버 코드 클론 받기

  • git clone을 통해 코드 가져오기
  • 해당 디렉터리로 이동
  • ./gradlew build로 빌드

EC2 인스턴스 서버 실행

  • java -jar build/libs/[파일 이름].jar을 통해 서버 실행
  • 인스턴스 대시보드에서 퍼블릭 IPv4 DNS 혹은 IPv4주소 중에 하나를 선택하여 웹 브라우저에서 접근

백그라운드 실행하는 명령어

  • nohup java -jar [빌드된 jar파일].jar &
  • ps -ef | grep java를 통해 검색
  • kill -9 [프로세스 아이디]를 통해 종료(-9 강제 종료, -15 안전하게 종료)

Security Group

보안 그룹

  • 인스턴스로 들어(인바운드)가고 인스턴스로 나가(아웃바운드)는 트래픽에 대한 가상 방화벽

인바운드 규칙

  • EC2 인스턴스로 들어오는 트래픽 규칙
  • 허용되지 않은 규칙은 접근 불가
  • 기본적으로 SSH 접속을 위한 규칙이 생성

인바운드 규칙

  • EC2 인스턴스에서 나가는 트래픽에 대한 규칙
  • 기본적으로 나가는 모든 트래픽 허용

보안 그룹 설정

  • 인스턴스 탭 우측에 어떤 보안 그룹에 속해있는지 확인 가능
  • 보안 그룹 탭에서 보안 그룹을 클릭하면 규칙을 설정 가능
  • 인바운드 규칙에서 인바운드 규칙 편집을 통해 편집 가능
    • 규칙 추가 버튼을 눌러 추가
    • EC2 인스턴스에서 실행 중인 서버가 인터넷 요청을 받을 수 있도록 설정해야 한다.
    • 포트 번호와 유형을 선택
    • 소스에 따라 요청을 허락하고 거절할 수 있다.
    • 규칙 저장을 하면 설정 완료
    • postman을 통해 테스트하여 확인 가능
    • 8080 포트로 설정하면 해당 포트로 접속 가능

Shell Script

shell script

  • java -jar build/libs/[빌드 파일 명].jar를 통해 EC2에서 실행
  • 해당 명령어는 foreground에서 동작해 실행시킨 창을 항상 열어놔야 한다.
  • 백그라운드에서 실행 가능하고 제대로 실행되고 있는지 체크해야 할 때 작성
  • 셀이나 명령 중 인터프리터가 돌아가도록 작성된 스크립트

Spring Boot 백 그라운드 실행

  • vi example.sh를 통해 에디터로 파일 생성 후
  • 아래 작성
#실행 중이면 프로세스 종료
ps -ef | grep "[빌드된 파일명]" | grep -v grep | awk '{print $2}' | xargs kill -9 2> /dev/null

# 종료 이력을 보고 문구 출력
if [ $? -eq 0 ];then
    echo "my-application Stop Success"
else
    echo "my-application Not Running"
fi

#다시 실행하기
echo "my-application Restart!"
echo $1

nohup java -jar build/libs/[빌드된파일명] --spring.profiles.active=dev > /dev/null 2>&1 &
  • chmod 755 example.sh를 통해 실행 권한 부여
  • 권한이 없다면 sudo 사용
  • 이후 ./example.sh로 실행을 하면

서버 배포 완료

  • EC2 인스턴스로 서버 실행 후 Postman으로 테스트 진행

클라이언트 배포

환경 설정

nvm 설치

설치 확인

  • 터미널을 닫고 재실행
  • nvm —version 입력하여 설치 확인

node.js 설치

  • nvm install —lts 로 설치
  • node -v 로 node.js 설치 확인

S3 호스팅

1. 정적 웹 페이지 빌드

  • 빌드
    • 불필요한 데이터를 없애고 통합 및 압축하여 배포
  • 빌드 전 터미널에 client 디렉터리로 이동 후 의존성 모듈 설치
  • 해당 디렉터리에 들어가서 npm install을 통해 설치
  • 환경 변수 설정
    • .env 파일을 수정하여 REACT_APP_API_URL=[서버 주소]로 설정
    • 서버 주소는 http://에서 포트까지 작성
  • npm run build 를 실행하여 웹 페이지 빌드
  • nvm use 16 명령어를 통해 안정된 버전에서 사용해야 오류 발생하지 않는다.
  • 빌드가 완료되면 디렉터리 하위에 build 폴더가 생성

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

  • AWS S3에 접속
  • 리소스를 찾아서 버킷 클릭
  • 속성으로 이동하여 정적 웹 사이트 호스팅 편집을 들어가 활성화로 변경
    • 인덱스 문서 부분에는 처음 접속 기본 페이지 지정
    • 오류 문서는 오류 발생할 때 페이지 지정
    • 변경 사항 저장
  • 변경 사항 저장되면 버킷 웹 사이트 엔드 포인트가 생성

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

  • 객체 메뉴에 들어가 업로드 버튼 클릭
  • build 폴더 안에 포함된 파일을 드래그 앤 드롭하여 업로드

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

  • 권한 탭으로 가서 퍼블릭 액세스 차단 옵션에서 편집하고 모든 퍼블릭 액세스 차단 옵션 체크 해제 후 변경 사항 저장
  • 권한 탭의 버킷 정책 부분 편집 후 정책 생성기 클릭
  • Select Type of Policy에서 S3 Bucket Policy 선택, Principal은 을 입력, Actions는 GetOject 선택, Amazon Resource Name에는 버킷 정책 편집에 나와있는 ARN 복사 후 /를 붙여서 사용(arn:aws:s3:::<버킷이름>/)
  • Generate Policy 버튼 클릭하면 정책 생성되고 JSON 데이터를 복사하고 close
  • 버킷 정책에 붙여 넣고 변경사항 저장
  • 속성으로 들어가서 버킷 웹 사이트 엔드포인트로 접속하여 테스트

데이터베이스 연결

RDS 인스턴스 연결

RDS 인스턴스 생성

  • AWS RDS 접속
  • 사이드바에서 데이터베이스 클릭하여 이동
  • 데이터베이스 생성 버튼을 누르고 엔진 옵션에 MySQL 선택
  • 템플릿 옵션에서 프리 티어로 선택
  • DB 클러스터 식별자 이름, 마스터 사용자 이름, 암호 지정
  • RDS 인스턴스 클래스는 t2.micro 선택
  • 연결 옵션에서 퍼블릭 액세스 가능을 예로 설정
  • 보안 그룹은 기본값 default 그룹 선택
  • 추가 연결 구성에는 일반적인 포트 번호 3306 대신 13306 지정
  • 추가 구성에서는 초기 데이터베이스 이름을 설정(예시 test)
  • 데이터베이스 생성하고 나서 상태에서 사용 가능으로 변경될 때까지 대기

데이터베이스 연결

  • AWS RDS에서 데이터베이스 메뉴에 DB 식별자를 찾아 클릭
  • 엔드포인트 주소를 확인하고 복사하고 포트 번호를 확인
  • 터미널에서 MySQL을 통해 DB 인스턴스 접속
  • mysql -u [마스터 이름] —host [엔드 포인트 주소] -P [포트 번호] -p 를 실행 후 마스터 비밀번호 입력
  • show databases;를 통해 초기 데이터베이스 존재하는지 확인

서버 환경 설정

서버 코드에 저장된 application.properties 파일에 환경변수 설정

  • EC2 인스턴스 터미널에서 application.properties 수정
  • vi src/main/resources/application.properties
    • spring.datasource.url={AWS RDS 엔드포인트 주소:포트}/test?useSSL=false&characterEncoding=UTF-8&serverTimezone=UTC
    • spring.datasource.username={마스터 사용자 이름}
    • spring.datasource.password={암호}
    • config.domain=http://{S3 엔드포인트 주소}
    • 내용을 변경하고 저장
  • ./gradlew clean으로 이전 빌드 제거 후 다시 빌드한다.

서버 실행

  • java -jar build/libs/{빌드된 파일 명}.jar를 통해 서버 실행
  • S3 버킷의 엔드포인트 주소로 접속해서 연결 확인

도메인 주소를 이용한 HTTPS 인증

ELB 생성 및 ACM을 통한 인증서 발급

  • EC2 메인 콘솔 이동
  • 사이드바에 로드 밸런서 탭 클릭
  • load balancer 생성 클릭, application load balancer 클릭
  • 이름에 ELB, 프로토콜에 http 포트 번호 80, HTTPS 포트번호 443으로 등록 후 다음 버튼 클릭
  • vpc에서 기본값을 설정하고 가용 영역 선택 후 다음
  • ACM에서 인증서 선택을 누르고 ACM으로부터 새 인증서 요청 클릭
  • 도메인 이름 입력 후 다음, DNS 검증 선택 후 다음, 검토 클릭, 확인 및 요청, Route 53에서 레코드 생성을 클릭 후 생성 후 계속
  • 검증 보류 상태 확인하고 인증서 발급 완료되면 발급 완료 상태 확인하고 load balancer 생성 창으로 돌아가 recurring 아이콘 클릭
  • 인증서 이름에 인증서를 선택 후 다음 클릭
  • 보안 그룹을 선택 후 라우팅 구성 클릭, 대상 그룹 이름을 설정, 고급 상태 검사 설정에서 성공 코드 201로 입력 후 다음 클릭
  • EC2 인스턴스를 체크한 후 등록된 항목에 추가를 클릭, 선택한 EC2 인스턴스 등록 여부를 확인하고 다음 클릭
  • 내용을 검토하고 생성 클릭하면 생성 완료 확인
  • 로드 밸런서 메뉴로 돌아가서 DNS 이름 주소를 이용하여 접속 테스트 진행

호스팅 영역에 별칭 레코드 생성

  • Route53 콘솔로 이동하여 호스팅 영역을 클릭
  • 해당 호스팅 역역을 접속하여 레코드 생성을 클릭하고 별칭을 클릭
  • Application/classic load Balancer에 대한 별칭 클릭
  • 리전을 서울 리전으로 선택
  • 로드 밸런서에서 생성한 로드밸런서를 클릭
  • 레코드 생성 여부를 확인하고 접속 테스트 진행

리소스 생성

인스턴스 생성

  • AWS EC2 서비스를 검색하고 인스턴스 시작 버튼 클릭
  • 프리티어 사용 가능 태그를 확인하여 과금이 되지 않도록 유의
  • 인스턴스 유형을 선택할 때 CPU, RAM, 용량 선택 가능
  • 검토 및 시작 버튼을 클릭하면 SSH 원격 접속을 위한 key 생성 및 다운로드 진행
    • 새 키 페어 생성 메뉴를 확인하고 이름을 정하고 다운로드하면 인스턴스 시작 버튼 활성화
    • SSH 프로토콜은 서로 다른 pc가 인터넷과 같은 public Network를 통해 통신할 때 안전하게 통신을 하기 위한 규약
  • EC2 프라이빗 키 파일(.pem 파일)
    • 인스턴스 생성 마지막 단계에서 다운로드 한 파일은 ssh 통신을 위한 키 페어 중 프라이빗 키가 기록된 파일로 .pem 파일이다.
  • 우측 하단에 인스턴스 보기를 통해 생성된 인스턴스 확인 가능
  • name 칼럼에서 해당 인스턴스 이름을 설정하면 인스턴스 구분 용이

인스턴스 연결

  • ssh 연결을 통해 인스턴스 접속
  • 인스턴스 선택 후 연결 버튼 클릭하고 ssh 클라이언트 클릭
  • 로컬 터미널에서 ssh 프로토콜을 이용해 인스턴스와 연결 가능
  • pem 키 파일에 대한 권한을 수정해야 한다.
  • chmod 400 [pem 키].pem 나에게만 읽기 권한이 있도록 부여
  • 권한 설정을 하지 않는 경우 너무 open되어 있다는 경고 발생
  • 권한 설정을 하면 ssh 명령어를 통해 인스턴스 접속 가능
    • 접속 주소는 인스턴스를 클릭하면 보이는 세부 정보 탭에서 확인 가능
  • ssh -i {다운로드한 키 페어 파일 경로} {사용자 이름}@{ssh접속주소}를 통해 접속

'Backend boot camp > Session4' 카테고리의 다른 글

[Cloud] 배포 자동화  (0) 2022.12.09
[Cloud]배포 컨테이너  (1) 2022.12.09
[Spring WebFlux] Spring WebFlux  (0) 2022.12.09
[Spring WebFlux] Reactor  (0) 2022.12.09
[Spring WebFlux] 리액티브 프로그래밍  (0) 2022.12.09

관련글

티스토리툴바