과거의 웹 개발은 프론트엔드와 백엔드처럼 포지션이 별도로 구분되지 않았습니다. 하지만 점점 뷰(View)의 영역이 커지며 각 영역을 전문적으로 개발하는 현재의 구조가 되었습니다. 우리가 만든 서버엔 뷰(View) 단이 빠져있기 때문에 배포 흐름에 대한 이해가 쉽지 않습니다. 따라서 이번 유닛에서 진행할 실습은 웹 애플리케이션 배포의 정확한 이해를 위해 풀스택 배포로(Client + Server + Database) 진행합니다.
우리가 만들고 있는 웹 서비스는 배포가 되지 않는다면, 더 이상 의미를 가질 수 없습니다. 따라서 웹 개발자는 배포에 대한 기본 지식을 탑재하고 있고, 간단한 배포 정도는 혼자 할 수 있어야 합니다.
이 시간에는 배포를 위한 클라우드 서비스 Amazon Web Service(이하 AWS)를 이용해서 웹 애플리케이션을 배포합니다. 가상화 기술의 발전과 AWS의 등장은 클라우드 컴퓨팅에 혁신을 불러일으켰습니다. 만일 AWS가 없었더라면 우리는 아래와 같이 직접 서버를 구축하고, 관리해야 했을지도 모릅니다.
하지만, 이제는 클릭 몇 번으로 서버를 사용할 수 있고, 확장할 수 있으며, 또한 사용한 만큼 돈을 지불할 수도 있습니다. 어떻게 이 모든 것들이 가능할까요? 이번 시간에 클라우드 컴퓨팅의 기본과 배포의 개념, 그리고 AWS가 제공하는 주요 서비스를 직접 다뤄보면서, 이 모든 것이 어떻게 가능한지 알아봅시다.
Before You Learn
3 Tier Architecture의 구성을 이해한다.
리눅스 운영체제(OS, WSL)에서 개발 환경을 처음부터 구축할 수 있다.
기본적인 리눅스 명령어를 이해할 수 있다.
Precautions
AWS 사전안내서를 읽고 실습 규칙을 인지한 후 실습을 진행해야 합니다.
학습 목표
Cloud와 Deployment의 의미를 각 각 알고, 내 코드를 남에게 배포할 수 있다.
클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
Deployment의 의미를 이해할 수 있다.
개발한 서비스를 다른 사용자가 이용 가능하도록 배포할 수 있다.
사용하는 서비스들의 특징과 사용해야 하는 이유를 이해할 수 있다.
RDS와 EC2에 설치된 데이터베이스의 차이를 이해할 수 있다.
S3의 높은 가용성과 안정성을 이해할 수 있다.
CloudFront의 콘텐츠 로딩시간 단축의 효과들을 이해할 수 있다. (advanced)
Route53을 이용해 요청을 쉽고 안전하게 원하는 곳으로 보낼 수 있음을 이해할 수 있다. (advanced)
커스텀 도메인을 이용해 요청을 원하는 곳으로 라우팅 할 수 있다. (advanced)
DNS가 무엇인지 이해할 수 있다. (advanced)
커스텀 도메인을 이용해 인증서를 발급받고 SSL을 적용할 수 있다. (advanced)
AWS Regulations
AWS 실습 관련 규정 안내
💁🏻♀️ 시작하기 전에
여러분 안녕하세요. 드디어 배포의 핵심, 클라우드에 대해 학습하는 시간입니다. 클라우드 서비스를 제공하는 밴더사(Vendor)는 여러 곳이 있지만, 학습에서는 AWS를 사용하여 실습을 진행할 예정입니다.
대부분의 클라우드 서비스 업체는 다음과 같은 기본 장점을 가지고 있습니다.
신속한 인프라 구축
유연한 인프라 관리
예상치 못한 트래픽 폭주 대응
손쉬운 글로벌 서비스
강력한 보안과 장애 없는 서비스
합리적인 요금제
이 중에서도 합리적인 요금제와 신속하고 유연한 인프라 구축이 가능하다는 점을 주목하셔야 합니다. 과거에는 물리적인 공간과 하드웨어를 갖춘 서버실을 구축하기 위해 막대한 시간과 비용을 들여야 했습니다. 하지만 이젠 클라우드를 통해 클릭 몇 번, 또는 코드 몇 줄로 거대한 서버실에 해당하는 네트워크를 구축할 수 있게 되었습니다. 또한, 유지보수 측면에서도 큰 변화가 있었습니다. 자체 서버실을 유지, 운영, 구축하기 위해 초기 비용과 유지/관리 비용이 들었다면, 클라우드를 사용하게 된 지금은 사용한 만큼 비용을 지불하는 온디맨드(On-Demand) 방식의 요금제가 도입되어 보다 합리적인 서비스 운영이 가능하게 되었습니다.
다시 말해, 클라우드 상에서 웹 애플리케이션을 배포하고 인프라를 구축하기 위한 실습을 진행할 때 AWS의 리소스를 사용하는 만큼 온디맨드 방식으로 비용을 지불하는 것은 당연한 원칙입니다. 여러분은 직접 AWS 계정을 생성하고, 자신의 결제 수단을 사용해야 합니다. 하지만 이러한 비용에 대한 걱정과 우려를 해소하기 위해 SE 부트캠프에서는 비용이 발생하지 않는 프리 티어를 활용하여 실습을 진행합니다.
On-Demand, On-Premises
온디멘드(On-Demand)
정의
온디멘드는 필요할 때마다 즉시 사용할 수 있도록 제공되는 IT 서비스 또는 소프트웨어를 의미합니다. 주로 클라우드 컴퓨팅 환경에서 사용됩니다.
사용자는 필요한 자원이나 서비스를 즉시 요청하고 사용할 수 있으며, 일반적으로 사용한 만큼 비용을 지불합니다.
특징
유연성: 사용자가 필요할 때마다 자원을 추가하거나 제거할 수 있어 매우 유연합니다.
비용 효율성: 사용한 만큼만 비용을 지불하므로 초기 투자 비용이 적습니다.
빠른 배포: 신규 서비스나 자원을 빠르게 배포할 수 있습니다.
접근성: 인터넷만 있으면 어디서든 접근 가능합니다.
자동화: 많은 클라우드 서비스 제공자들이 자동화 도구를 제공하여 관리가 용이합니다.
예시
클라우드 스토리지 서비스(AWS S3, Google Drive)
클라우드 컴퓨팅 서비스(AWS EC2, Google Cloud Compute Engine)
소프트웨어 애즈 어 서비스(SaaS) 애플리케이션(Office 365, Google Workspace)
장점
초기 비용이 낮음
확장성과 유연성이 뛰어남
유지보수 및 관리가 용이
단점
데이터 보안 및 프라이버시 문제
인터넷 연결에 의존적
장기적으로 사용 시 비용이 증가할 수 있음
온프레미스(On-Premises)
정의
온프레미스는 조직 내 물리적 서버 및 IT 인프라를 직접 소유하고 관리하는 방식입니다.
소프트웨어와 하드웨어가 모두 조직의 데이터 센터 내에 위치하며, 모든 유지보수와 관리가 내부에서 이루어집니다.
특징
보안성: 데이터와 시스템이 내부에 있으므로 보안이 더 강화될 수 있습니다.
제어권: 모든 하드웨어와 소프트웨어에 대한 완전한 제어권을 가집니다.
성능: 네트워크 연결 상태에 영향을 덜 받으며, 최적의 성능을 유지할 수 있습니다.
맞춤화: 특정 요구 사항에 맞게 시스템을 커스터마이징 할 수 있습니다.
예시
내부 데이터 센터
자체 호스팅 애플리케이션
ERP 시스템
장점
높은 데이터 보안성
완전한 제어권
인터넷 연결 없이도 사용 가능
단점
초기 투자 비용이 높음
유지보수 및 관리 비용이 높음
확장성 및 유연성이 낮음
요약 비교
AWS 실습 기본 가이드라인
AWS 계정
AWS 서비스 활용 기간은 다음과 같습니다.
[Project] 애플리케이션 운영 환경 구성
수강생은 AWS 학습 기간 동안 실습을 진행하기 위해 AWS 서비스에 회원가입을 진행해야 합니다.
AWS 계정을 생성하기 위해 해외결제가 가능한 신용카드 혹은 체크카드가 준비되어야 합니다.
AWS 계정을 이미 가지고 있는 경우에는 기존의 계정을 활용할 수 있습니다. 프리 티어 기간이 지났는지 꼭 확인해주세요.
AWS 비용 관리
AWS 리소스를 사용하는 데 있어 실습 기준안과 콘텐츠에 해당하는 실습만 진행되어야 합니다.
실습 기준안과 콘텐츠에 해당하는 실습이외의 서비스를 사용하면 추가적인 비용이 발생될 수 있습니다.
인스턴스 생성시, 비용이 발생하지 않는지 다시한번 확인해야 합니다.
AWS 실습 기준안
AWS 실습 기준안은 다음과 같습니다.
수강생은 아래 표와 같은 AWS 서비스를 사용하게 되며, 해당 서비스는 커리큘럼의 내용 및 제반 상황에 따라 달라질 수 있습니다.
Chapter - Amazon Web Service
💁🏻♀️ 시작하기 전에
여러분 안녕하세요. 드디어 배포의 핵심, 클라우드에 대해 학습하는 시간입니다. 클라우드 서비스를 제공하는 밴더사(Vendor)는 여러 곳이 있지만, AWS를 사용하여 실습을 진행할 예정입니다.
대부분의 클라우드 서비스 업체는 다음과 같은 기본 장점을 가지고 있습니다.
신속한 인프라 구축
유연한 인프라 관리
예상치 못한 트래픽 폭주 대응
손쉬운 글로벌 서비스
강력한 보안과 장애 없는 서비스
합리적인 요금제
이 중에서도 합리적인 요금제와 신속하고 유연한 인프라 구축이 가능하다는 점을 주목하셔야 합니다. 과거에는 물리적인 공간과 하드웨어를 갖춘 서버실을 구축하기 위해 막대한 시간과 비용을 들여야 했습니다. 하지만 이젠 클라우드를 통해 클릭 몇 번, 또는 코드 몇 줄로 거대한 서버실에 해당하는 네트워크를 구축할 수 있게 되었습니다. 또한, 유지보수 측면에서도 큰 변화가 있었습니다. 자체 서버실을 유지, 운영, 구축하기 위해 초기 비용과 유지/관리 비용이 들었다면, 클라우드를 사용하게 된 지금은 사용한 만큼 비용을 지불하는 온디맨드(On-Demand) 방식의 요금제가 도입되어 보다 합리적인 서비스 운영이 가능하게 되었습니다.
다시 말해, 클라우드 상에서 웹 애플리케이션을 배포하고 인프라를 구축하기 위한 실습을 진행할 때 AWS의 리소스를 사용하는 만큼 온디맨드 방식으로 비용을 지불하는 것은 당연한 원칙입니다. 하지만 이러한 비용에 대한 걱정과 우려를 해소하기 위해 AWS 실습 기준안에 따라 AWS Free Tier 서비스를 이용하여 여러분의 학습 효율을 높이는 방향을 만들고자 합니다.
지난 실습에서 세션 매니저를 이용해 EC2 인스턴스의 연결 상태를 확인했습니다. 이번 실습에서는 EC2 인스턴스를 이용하여 서버를 실행하고 접속합니다.
주의 : 개인 PC의 로컬이 아닌 EC2 인스턴스에서 진행합니다.
1. 인스턴스에 개발 환경 구축하기
우리는 EC2 인스턴스를 생성하는 것이 가상 PC 한 대를 임대하는 것이라고 배웠습니다. 컴퓨터 운영체제를 처음 구입하면 필요한 프로그램을 설치해야 하듯이, EC2 인스턴스에 처음 접속하면 서버를 구동하는 데 필요한 개발 환경을 구축하는 것부터 시작해야 합니다. 저번 실습에서 EC2 인스턴스와 연결한 터미널에서 아래 명령어를 입력합니다. 패키지 매니저가 관리하는 패키지의 정보를 최신 상태로 업데이트하기 위해서 아래 명령어를 사용합니다.
$ sudo apt update
어느 정도 시간이 지나고 업데이트 과정이 끝나면 java를 설치해야 합니다.
$ sudo apt install openjdk-11-jre-headless
아래와 같은 확인창이 나올 경우 "Y"를 입력하시면 됩니다.
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libasound2 libasound2-data libgraphite2-3 libharfbuzz0b
Suggested packages:
libasound2-plugins alsa-utils libnss-mdns fonts-dejavu-extra fonts-ipafont-gothic fonts-ipafont-mincho fonts-wqy-microhei
| fonts-wqy-zenhei fonts-indic
The following NEW packages will be installed:
libasound2 libasound2-data libgraphite2-3 libharfbuzz0b openjdk-11-jre-headless
0 upgraded, 5 newly installed, 0 to remove and 70 not upgraded.
Need to get 37.9 MB of archives.
After this operation, 173 MB of additional disk space will be used.
Do you want to continue? [Y/n]
설치 과정이 마무리되면, java -version 명령어를 입력하여 java 라이브러리가 설치가 완료되었는지 확인합니다. 명령어를 입력했는데 오류가 난다면 java 설치 과정이 정상적으로 마무리되지 않은 것입니다.
샘플 애플리케이션 준비
Getting Started
이번 과제는 IntelliJ를 사용하여 직접 코드를 작성하고, 테스트를 통해 정확한 코드를 입력했는지 확인할 수 있습니다.
이번 실습은 생성한 EC2 인스턴스에 실행 환경을 구축하고, 테스트용 샘플 애플리케이션을 활용하여 배포를 완료하고, Postman을 통해 배포가 잘 진행되었는지 테스트를 진행합니다.
아래 순서에 맞게 진행해 주세요.
애플리케이션 빌드
애플리케이션을 실행할 수 있는 형태(.jar)로 패키징한다.
✔ IntelliJ IDE를 이용한 빌드
Spring Boot은 Gradle 빌드 툴을 이용해 애플리케이션을 빌드할 수 있는 플러그인을 지원하기 때문에 Gradle task 명령을 통해 애플리케이션을 손쉽게 빌드할 수 있습니다.
java -jar DeployServer-0.0.1-SNAPSHOT.jar 명령어를 통해 실행할 수 있습니다.
해당 명령어를 이용하여, 빌드된 파일을 실행합니다.
위와 같은 메시지를 통해 정상적으로 서버가 실행되었음을 확인할 수 있습니다. 이제 EC2 인스턴스의 IP 주소로 접근해서 테스트를 진행합니다. IP 주소는 EC2 대시보드에서 생성한 EC2 인스턴스를 클릭하면 확인할 수 있습니다.
애플리케이션 동작 확인
AWS EC2 서비스로 이동합니다. 인스턴스를 클릭합니다.
2. 현재 실행중인 EC2 인스턴스의 ID를 클릭합니다.
3. 퍼블릭 IPv4 DNS 주소를 복사(메모)합니다.
아래 화면에서 강조된 부분을 보시면, 두 가지 형태의 주소가 존재하는 것을 확인할 수 있습니다. 퍼블릭 IPv4 주소와 퍼블릭 IPv4 DNS는 형태만 다를 뿐 같은 주소입니다. 둘 중 어떤 주소를 사용하셔도 문제가 없습니다. 이번 실습에서는 퍼블릭 IPv4 DNS 주소를 이용하여 접속 테스트를 진행하겠습니다.
4. Postman을 실행하여, 복사한 주소에 실행중인 애플리케이션의 포트번호(8080)이 추가된 주소를 넣고, GET 메서드로 요청을 보냅니다.
5. 아래 화면처럼 “Hello Spring World!”라는 응답이 출력되어야 합니다.
6. 회원가입을 위한 엔드포인트로 테스트를 진행합니다. 엔드포인트 마지막에 /signin을 추가하고, HTTP Method를 POST로 변경합니다. Body에 raw - JSON 데이터를 추가합니다.
{
”username”: “김코딩”,
”password”: “1234”
}
모두 작성했다면, Send 버튼을 클릭합니다.
7. 아래 화면과 같이, 로그인이 성공했다면 유저의 정보가 암호화된 토큰값을 확인할 수 있습니다. 해당 값을 복사합니다.
8. 엔드포인트의 마지막 주소를 /status로 변경하고, HTTP Method로 GET으로 변경합니다. Headers에 앞에서 응답으로 돌아온 토큰값을 추가합니다. Key는 authorization으로, Value에 해당 토큰값을 추가하고, Send 버튼을 클릭합니다.
9. 아래 이미지와 같이, login은 true의 값이, connectedToDatabase의 값은 false인 응답이 온다면 애플리케이션의 동작 확인작업이 모두 종료됩니다.
하지만 해당 명령어로 실행하였을 때 foreground에서 동작을 해서 실행시킨 창을 항상 열어놔야 하는 단점이 있습니다. 추후 여러분이 사용하게 될 수 있는 Jenkins 같은 곳에서 배포된 jar파일을 실행했을 때도 문제가 되기도 합니다.
그래서 만약 여러분에 애플리케이션이 background에서 실행도 가능해야 하고 애플리케이션이 제대로 실행되고 있는지 체크를 해야 한다면 이를 편하게 하기 위한 실행 스크립트를 만들어야 합니다.
이때 사용 되는 것이 "Shell Script"입니다!
셀 스크립트는 셀이나 명령 중 인터프리터에서 돌아가도록 작성된 스크립트입니다. 운영체제를 위한 스크립트라고 생각하면 됩니다. 셀 스크립트에 경우 따로 공부할 필요는 없습니다!
아래 내용을 따라 하면서 대략적 구조만 파악을 하고 필요에 따라 검색을 통해 필요한 셀 스크립트를 가져다 조합하면 됩니다.
셸 스크립트에 경우 한번 작성하면 재작성하는 일이 매우 적습니다. 그렇기 때문에 따로 공부하기보다 여러 경우에 스크립트를 모아두어 때에 따라 사용하는 편입니다.
Spring Boot 백 그라운드 실행
그러면 셸 스크립트를 작성해 보겠습니다!
셸 스크립트는 실행 명령을 미리 작성해 둔 것이어서 ".sh"라는 파일 형태로 만들어 사용합니다.
$ nano restart.sh // 에디터로 파일을 생성한 후 아래 내용을 붙여넣기 해주세요.
================================================================================
#!/bin/bash
# DeployServer-0.0.1-SNAPSHOT.jar가 실행 중이라면 프로세스를 종료합니다.
ps -ef | grep "DeployServer-0.0.1-SNAPSHOT.jar" | 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
# DeployServer-0.0.1-SNAPSHOT.jar를 다시 실행하기 위한 과정을 진행합니다.
echo "my-application Restart!"
echo $1
# nohup 명령어를 통해 백그라운드에서 DeployServer-0.0.1-SNAPSHOT.jar를 실행합니다.
nohup java -jar build/libs/DeployServer-0.0.1-SNAPSHOT.jar --spring.profiles.active=dev > /dev/null 2>&1 &
리눅스에 위와 같이 파일을 저장하고 아래 명령어를 통해 실행 권한을 부여합니다.
chmod 755 restart.sh
위와 같이 명령어를 수행하였으면 아래 명령어를 통해 실행이 가능합니다.
./restart.sh
경우에 따라 권한 이슈로 실행이 되지 않는 경우가 있는데, 이 경우 sudo를 붙여 실행하면 오류 없이 실행이 됩니다.
위의 셸 스크립트는 DeployServer-0.0.1-SNAPSHOT.jar를 종료하고, 다시 실행하는 과정이 적혀있습니다. 즉, 빌드 후 빌드 결과물을 실행할 때에, 이미 동일한 프로젝트가 실행중인 경우 해당 프로세스를 종료(kill)한 후 실행하도록 작성되었습니다.
단, 위의 코드는 각 단계를 매우 간단하게 적어놓았기 때문에 애플리케이션 실행에 대한 모든 로그를 남기진 않습니다. 셸 스크립트를 실행한 후 서버가 실행되지 않는다면 빌드 여부, 빌드 결과물 이름과 셸 스크립트 비교, 셸 스크립트 전체가 저장되어 있는지, 셸 스크립트의 저장 위치에서 빌드 파일에 접근이 가능한지 수동으로 살펴보시기를 바랍니다.
(Advanced) 단순히 셸 스크립트를 실행했을 때 위의 진행 과정에 추가로 프로젝트 재 빌드까지 이뤄지게 한다면 어떤 과정이 추가되어야 할지 고민해 보세요.
