첫 프로젝트와 첫 호스팅에 대한 회고
개발일기
Spring5를 이용한 첫 프로젝트로 쇼핑몰을 선택했고,
이를 잘 완성하고 호스팅까지 해내며 느낀 점을 정리한다.
처음엔 Cafe24를 이용하여 호스팅을 할 계획이었다.
호스팅을 하기 전에 내가 가진 네트워크 지식을 전체적으로 한번 정리해야했다.
웹서비스 배포를 위해 알아야 할 지식들이 많았기 때문이다.
막상 호스팅을 하려고 보니 Cafe24는 Oracle RDB를 지원하지 않아 다른 방법을 찾게 되었는데,
최종적으로 결정하게 된 부분은 AWS를 이용한 호스팅이었다.
💡 What AWS?
AWS(Amazon Web Services) 는 아마존에서 제공하는 클라우드 컴퓨팅 서비스다.
네트워크를 기반으로 가상 머신과 스토리지를 비롯한 각종 네트워크 인프라를 제공해준다.
쉽게 얘기하면 AWS를 이용한다는 건 대부분의 네트워크 인프라를 아마존의 시스템에 의존해 구축하는 것이다.
더 쉽게 얘기하면 아마존에서 구축해놓은 데이터 센터에서 컴퓨터를 빌려다가 자신의 서비스를 구축&배포하는것이다.
💡 Why AWS?
우선 프리티어라 해서 무료로 제공하는 서비스가 매우 괜찮았었고,
취준생 입장에서 많은 회사들이 AWS를 사용하고 있다는 걸 아는데
왜 AWS를 많이 사용하는지 직접 느껴보기에 좋은 기회라고 생각했다.
그래서 AWS의 EC2를 이용한 웹 애플리케이션 배포를 생각하게 됐다.
그리고 애초에 Cafe24가 Oracle을 지원 안 해줬던게 가장 크긴 했다.
💡 What EC2?
Amazon EC2(Amazon Elastic Compute Cloud),
번역해보자면 아마존의 탄력적인 클라우드 컴퓨터?라고 볼 수 있으려나??
그냥 단순하게 내 서비스를 아마존의 인프라를 통해 구현하기 위해
아마존에서 가상 머신(컴퓨터)을 한대 빌리는 걸 말한다.
이렇게 빌려서 생성된 가상 머신을 인스턴스라고 부른다.
이 인스턴스는 처음 구축할 때 다양한 OS를 선택할 수 있고 기본적으로 SSD를 제공해주며,
이는 지불하는 요금에 따라 탄력적(Elastic)으로 변경될 수도 있었다.
또한 기본적으로 유동 IP가 설정되어있어 웹 애플리케이션 서비스 중 접속 장애가 일어날 수 있는데
이는 아마존에서 제공하는 고정 IP를 연동시켜 안정적인 서비스를 이루어 내 문제를 해결 할 수도 있으며,
그 외 수십 종의 다양한 AWS 서비스를 이용할 수 있다.
처음 EC2 인스턴스를 생성할 때 별생각 없이 윈도우 OS를 선택했다.
왜냐하면 나는 태어나서 윈도우 외의 다른 OS를 직접 만져본 적이 없었기 때문이다.
하지만 만들자마자 바로 리눅스(우분투)를 선택하게 됐는데 이유가 뭐냐 하면
프리티어(체험판) EC2의 경우 최대 30GB의 하드디스크 용량을 얻을 수 있는데,
윈도우로 인스턴스를 생성할 시 30GB 중 14GB를 OS가 잡아먹는 것이었다.
대충 용량을 보고 계산해보니 오라클 등의 필수 패키지를 설치하고 웹 애플리케이션을 배포하면 용량이 간당간당할 것 같았다.
쇼핑몰이기 때문에 이미지 파일이 많이 들어가기 때문이었다.
그래, 이참에 나도 리눅스를 한번 써 보자 생각하여 인스턴스를 반납하고 우분투 OS를 선택해 EC2 인스턴스를 새로 생성했다.
일단 정보처리기사를 공부하면서 리눅스가 CLI기반의 OS라는 건 알고는 있었는데 막상 모든 걸 CLI로 조작하려니 생각보다 어렵기도 했고 무엇보다 재미있기도 했다.
정보처리기사를 공부하면서 봤던 리눅스 명령어란 명령어는 다 써봤고 추가적인 명령어도 검색해서 써보게 되더라.
역시 백문이 불여일타(?)라고, 직접 해보는 것만큼 확실하게 숙달되는 게 없다고 다시금 느끼게 되는 좋은 계기였다.
30GB의 용량 중 OS가 이미 깔려있음에도 27GB 이상의 용량을 사용할 수 있음에 “와..? 이래서 리눅스 쓰는 건가?”라고 감탄하게 됐다.
우선 간략하게 순서를 나열해보자면
푸티(Putty)를 이용하여 서버(인스턴스)에 대한 원격 시스템을 구축
JVM환경 구축을 위해 JDK를 설치하고 환경변수 설정
Tomcat(WAS)을 설치하고 환경변수 설정
파일질라(FileZilla)를 이용하여 로컬에 설치된 Tomcat경로에 war 배포
Oracle RDB 구축 및 WAS와 연동(포트 포워딩)
WAS를 구동하여 웹 애플리케이션 실행
정상 구동 확인 후 DNS 서버 구축
우선 푸티는 간단하게 얘기해서 다른 컴퓨터에 원격으로 접속할 수 있게 도와주는 툴이다.
AWS자체에서 원격 서비스를 지원해주긴 하지만 웹 브라우저 기반이라
사용하는데 불편함을 많이 느껴 직접 SSH프로토콜을 이용하여 원격제어 시스템을 구축했다.
첨언하자면 여기서 SSH(Secure Shell)프로토콜은 암호화 보안이 적용된 원격지 접속을 위한 프로토콜이다.
이 녀석이 사용되기 전엔 텔넷이라는 프로토콜을 많이 사용했다고 하는데, 이 텔넷은 암호화를 하지 않아 보안에 취약했다고 한다.
텔넷과 다르게 SSH를 이용하기 위해서는 개인정보를 암호화한 Key파일이 필요하고 이는 AWS에서 제공해준다.
푸티를 통해 인스턴스에 접속하고 인스턴스에 JDK를 설치하여 JVM이 돌아갈 환경을 만들어주었고,
WAS로 로컬에서 개발할 때 사용했던 Tomcat9.0.41을 설치해줬다.
파일질라는 TCP/IP 기반으로 동작하는 FTP(File Transfer Protocol) 파일 업로드 툴인데,
다른 컴퓨터에 접속한다는 건 푸티와 동일하지만 이 파일질라는 그냥 파일 전달에 특화돼있는 친구다.
FTP 자체가 역사가 매우 깊은 프로토콜이지만 간단하고 강력하다는 점에 아직도 널리 사용된다 느꼈다.
파일질라로 파일 전송을 할 때 SFTP를 지원하길래 이를 통해 파일 업로드를 했는데, SFTP는 FTP+SSH를 뜻한다.
이 역시 SSH이므로 Key파일이 필요하고 이 Key파일은 AWS에서 제공한 파일을 사용하였다.
인스턴스에 Tomcat이 설치되어 로컬에서 인텔리제이를 이용해 개발한 프로젝트를 Maven을 통해 war로 Build 했고,
이렇게 만들어진 war파일을 호스팅 서버의 tomcat/webapps 경로에 배포해줬다.
Oracle RDB를 구축하고 이 RDB에 외부에서 접속할 수 있게끔 포트 포워딩을 진행해야 했다.
포트 포워딩이란 개발자가 아닌 일반인들도 많이 하는 경우가 있는데, 일상생활에서 하는 공유기 설정이 대표적인 예이다.
IP주소는 문이다.
행복아파트 5층에는 10가구가 살고 있다고 한다면,
이 5층에는 10개의 현관문이 있는 셈이다.
이를 네트워크로 비유하자면 10개의 IP주소가 있는 것과 같다.
그리고 아파트의 공동현관문을 게이트웨이(Gateway)라고 볼 수 있겠다.
포트(Port)는 정확한 주소다.
굳이 비유하자면 각 가구의 문(IP)을 지나 집 안에 들어서면
각 방을 Port라고 비유할 수 있을 것 같다.
최종 도착지(End Point)인 셈이다.
그래서 웹 애플리케이션을 개발하여 WAS를 통해 가동하였을 때
URL상에서 localhost:8080 이런 식으로 나오게 되는 것인데
localhost는 WAS를 돌리는 컴퓨터의 IP주소이고 :8080은 해당 컴퓨터의 WAS Port인 셈이다.
그래서 Port는 한 컴퓨터에 여러개가 있을 수 있다.
192.168.0.1(localhost)의 8080 포트(=Tomcat)에 접속한다면
Tomcat내부 Root폴더(webapps)에 진입하게 되는 것이다.
아무튼, 외부에서도 Oracle RDB에 접속할 수 있게끔
1521(Oracle Port Number) 포트를 모든 IP에 대해 개방해주고
내 컴퓨터에서 SQLDeveloper.exe를 실행 해 RDB에 접속 테스트를 하였고,
성공적으로 접속이 되어 DB구축을 하게 되었다.
또한 RDB를 새로 구축한 만큼 웹 애플리케이션의 설정 파일을 바꿔줘야 했는데,
대표적으로 Tomcat의 server.xml을 커스터마이징해 Context Path를 변경해주어야 했고,
웹 애플리케이션의 root-context.xml에 설정된 DataSource 또한 바꿔주어야 했다.
Context Path를 바꾸어주지 않는다면 192.168.0.1(임의의 IP주소):8080/Project명/이라는
Context path가 Default값으로 설정되기에
웹 애플리케이션이 정상적으로 동작하지 않을 위험이 있기 때문이었으며,
root-context에는 로컬에 구축된 DB의 정보가 들어있기 때문에
이를 서버에 새로 구축한 DB의 정보로 업데이트해줬다.
결론적으로 정상적으로 호스팅이 되는 걸 확인했고,
가비아에서 도메인을 구매한 후
AWS Route53을 사용해 내가 배포한 웹 애플리케이션의 도메인을 변경해줬다.
DNS(Domain Name System) 서버란 사람이 기억하기 힘든 IP주소를 사람이 알아보기 쉬운 문자의 나열로 URL을 바꿔주는 서버다.
내가 만든 웹 애플리케이션을 호스팅 하는 컴퓨터의 IP주소를 DNS 서버에 등록하고,
DNS 서버가 해당 IP에 요청을 받으면 도메인을 반환하게끔 작동한다. 반대로도 가능하다.
그래서 192.168.0.1(임의의 IP) 이란 IP가 DNS 서버에 등록되어 있고,
www.naver.com라는 도메인을 반환하게끔 설정되어 있는 상태에서
이 IP로 접속을 한다면 DNS는 맵핑되어 있는 문자열을 반환해주는 것이다.
이를 실험해보려면 다른 웹 사이트에 ping을 보내 해당 사이트의 IP를 알아내고
웹 브라우저 URL창에 해당 IP를 입력하면 정상적으로 접속되는 것을 확인할 수 있을 것이다.
결과적으로 EC2 인스턴스의 고정 IP:8080이었던 URL이 www.hklmart.shop으로 바뀐 것이다.
😎 후기
적어놓고 나니 굉장히 간략한데. 처음 해보는 것이기도 했고 알고 있는 지식을 실전에 적용해보며 많은 시행착오가 있었다.
아침 9시에 시작해서 새벽 1시에 끝냈고, 하루 종일 몰입하느라 아무것도 먹지 못해 새벽 1시에 야식을 시켜먹었다.
(문제 해결 후 먹는 족발이 그렇게 맛있을 수가 없었다.)
이번에 많은 시행착오를 겪으면서 많은 걸 배우고 느꼈는데 간략하게 정리해보자면
첫 번째로 우선 가장 많은 시간을 빼앗긴 타임존 이슈가 있겠다.
DNS 구축 전 최종적으로 웹 애플리케이션을 가동할 때 서블릿 컨테이너 이니셜 라이징중에 빈 생성 에러가 발생했는데, ORA-01882(타임존) 에러였다.
이 에러의 근본적인 원인은 한참의 삽질 끝에 알아냈다.
EC2 인스턴스의 타임존, OS의 타임존, WAS의 타임존, DB의 타임존 4박자가 모두 일치하지 않을 경우 발생하는 에러였는데
가상 머신이 한국에 있지 않다는데서 오는 게 가장 큰 원인이었던 것으로 보인다.
그래서 EC2 인스턴스를 이미지화해 한국으로 리전(Region)을 옮겼으며, 모든 타임존을 KST로 변경하고나서야 해결이 되었다.
타임존이 안 맞으면 접속이 안된다는 것도 처음 알았는데 큰 수확이었던 것 같다.
두 번째로 war파일을 이용한 배포를 처음 해보았다는 것이다.
war를 Tomcat/webapps에 배포하고 Tomcat을 Restart 할 경우 war가 자동으로 압축해제가 된다는 것도 처음 알았고,
이 war파일을 삭제할 경우 프로젝트 폴더도 같이 없어진다는 것도 처음 알았다.
평소 압축파일을 풀면 압축파일을 삭제하거나 정리하는 버릇이 있어 war파일이 압축 해제된 걸 확인하고 “얘는 이제 없어도 되겠지~”
라며 war를 지웠는데 갑자기 웹 애플리케이션이 먹통이 돼서 404 에러를 뿜어대는 것이었다.
알고 보니 war 삭제되면 압축 해제한 프로젝트 폴더도 사라지더라. 그래서 404를 뿜어댔던 것이고…
세 번째로 서버와 로컬의 환경 차이에서 발생하는 이슈였다.
이게 정말 큰 문제였는데 로컬(내 컴퓨터)의 인텔리제이로 돌릴 땐 정상 동작하던 것들이
서버로 마이그레이션(Migration) 하여 구동시키자 온갖 버그가 발생하는데
정말 사람 뒷목 잡게 만드는 상황이었다.
아마 JVM이 아니었다면 쓰러졌을지도 모르겠다.
나름 OOP니 SOLID니 하며 신경 써서 만들었던 코드들인데 (구리지만…)
이런 버그들이 발생하는 걸 보니 마음이 편치는 않았다.
그래도 배우는 입장이니 좋은 경험 했다고 긍정적으로 생각해본다.
마지막으로 리눅스를 사용해보았다는 것이다.
인스턴스 생성 중 OS를 선택하기 전에 리눅스에 대해 알아보았는데
데미안, 레드햇, 우분투 세 종류의 리눅스 선택이 가능했었다.
Spring Security를 채택&적용해 개인정보 암호화, XSS 공격 방지, 중복 로그인 방지 등
보안에 나름대로 많은 신경을 썼던 프로젝트였기 때문에
보안 업데이트가 끝나 보안에 취약하다는 레드햇은 보자마자 최우선 배제대상이었다.
남은 건 데비안과 우분투였는데 우분투가 데비안에서 나온 녀석이기도 하고,
내가 리눅스를 아예 사용해보지 않은 초짜 중의 초짜라
데비안은 너무 진입장벽이 높지 않을까 하는 생각에 우분투로 시작을 해보자고 생각하게 됐다.
이 걱정은 기우였던 걸로 생각이 되는데, 리눅스가 생각보다 어렵지 않았다.
오히려 재미있었다.
영어공부도 많이 되는 것 같고… 리눅스는 앞으로 노트북에 설치해서 두고두고 공부해볼까 하는 생각도 들었다.
이번의 시행착오(삽질)는 앞으로 더 크게 발전할 수 있는 기반이 됐다고 생각한다.
왜냐하면 공부해서 머릿속으로만 알고 있던 지식의 대부분을
실전에 적용해보았던 첫 경험(역대급 삽질 퍼레이드)이었기 때문이다.
추상적으로 막연하게만 느끼고 있던 부분들도 대부분 이해하게 됐던 게 그야말로 가장 큰 수확이었다고 생각한다.
