프로젝트 기술 스택에 대한 정리

프로젝트에 사용한 기술 스택 / 아키텍쳐에 관하여 간단하게 정리해보고자 합니다.

📖 해당 포스팅은 크게 2가지에 맞춰 설명합니다.

• 기술에 관한 설명 (자세한 설명은 포스팅 링크 참조)
• 기술을 선택한 이유 (ex. 적용한 방법, 필요한 이유, 다른 방법과의 비교)

AWS

EC2

이 기술을 프로젝트에 적용한 이유는 무엇인가?
만약 클라우드 없이 개인이 서버를 관리한다면 개인 서버에서 문제가 생겼을때 서비스 자체의 접속에 문제가 생기게된다. 이를 클라우드를 통해 서버를 대여함으로써 관리를 용이하게 하는 것이다.

클라우드 컴퓨팅의 장점은 확장성, 탄력성, 접근성, 장애허용성이 있다.

• 확장성 측면에서, 개인이 서버를 확장하는 것보다 훨씬 서버를 확장시키기 용이하다.
• 탄력성 측면에서, 트래픽이 늘어날 때 관리하는 것이 용이하다.
• 접근성 측면에서, 언제 어디서든 보안키를 통해서 접속이 가능하다.
• 장애허용성 측면에서, 자연 재해 등의 문제나 대체제 측면을 대비,방지할 수 있다.

어떻게 적용했는가?
EC2 Service에서 서버를 구축하고 nginx를 spring boot 앞단에서 프록시 서버로 사용했다.
이때 데이터베이스는 따로 분리하여 RDS에서 MySQL을 사용했다.

RDS

기술에 대한 설명
데이터베이스를 간편하게 클라우드에서 설정, 운영, 확장이 가능하도록 지원하는 서비스이다.

이 기술을 프로젝트에 적용한 이유는 무엇인가?
기본 서버와 데이터베이스 서버를 분리하여 관리하면 N:1 확장성, 보안, 편리성의 이점을 지닌다.
EC2를 구축하였을 때, EC2 안에서 데이터베이스 MySQL 을 설치하고 사용하였다.
하지만 EC2에 문제가 생긴다면 데이터베이스에도 함께 접근하지 못하는 문제가 생긴다.
그래서 기본 서버와 데이터 베이스를 분리하여 관리하기 위해 사용하였다.

[비교] 데이터베이스를 분리하여 사용하는 방안 2가지

1. EC2에 데이터베이스를 직접 설치
   → AWS에 지불하는 비용만 놓고 비교하면 사용 중인 데이터베이스를 직접 설치하는 것이 저렴할 수 있다.

2. RDS 사용 (선택)
   → OS 및 데이터베이스의 설치 및 관리 그리고 업데이트를 따로 할 필요가 없어진다. 또한 AWS 콘솔이나 AWS API를 통해 손쉽게 백업이나 복구(recovery)가 가능하여 잠재적으로 보았을 때 비용을 절감할 수 있다.

Ngnix

웹 서버에 대한 설명
Nginx, Apache 모두 클라이언트로부터 http 요청을 받아 요청에 해당하는 파일을 http 통신을 통해 응답해주는 웹 서버 프로그램이다.
WAS(ex.Tomcat)가 동적 데이터를 처리하는 서버라면 웹 서버(ex.Nginx,Apache)는 정적인 데이터를 처리 하는데 특화되어있다.

• [비교] Tomcat
  WAS(Web Application Server)는 DB와 연결되어 데이터를 주고 받는다. (목적이 다른 것이다)
  http://~~.jsp 라는 주소를 보았을 때, WAS는 JSP(java server page)를 처리하는 프로그램이다. Java로 만들어진 프로그램을 웹 서버에서 돌려서 결과값을 클라이언트에 돌려준다.

기술에 대한 설명

• 비동기 Event-Driven 구조로, 하나의 스레드 내에서 여러 클라이언트 요청을 처리하는 구조이다.
• 적은 양의 스레드만 사용되기 때문에 Context Swiching 비용이 적고, CPU 소모가 적다.
• 대용량 트래픽을 처리하기 위해 가벼움과 높은 성능을 목표로 한다
• 하지만, 복잡한 처리가 필요한 요청의 경우 시스템 큐에 쌓이게 되어 성능이 저하될 수 있다.

[비교] Apache

• 스레드/프로세스 기반 구조로, 하나의 스레드가 하나의 클라이언트 요청을 처리하는 구조이다.
• 다양한 동적 모듈을 로드하기 위한 더 많은 문서와 자원을 제공한다는 장점이 있다.
• 하지만, 클라이언트 접속마다 스레드를 생성하므로 동시 접속 수가 많다면 많은 스레드가 생성되어 메모리, cpu 낭비가 심해질 수 있다.

이 기술을 프로젝트에 적용한 이유는 무엇인가?
Spring Boot는 기본적으로 8080번 포트에서 서비스 된다.
하지만, 대부분의 서비스가 HTTP 기본 포트인 80번 포트에서 제공되기 때문에 80포트로 변경해줘야한다. (이를 위해서는 스프링 부트에서 루트 권한으로 80번 포트로 지정하여 사용할 수 있지만, 루트권한으로 실행시켜야 한다는 단점과 SSL을 적용하기 어렵다는 문제가 발생한다.)

때문에 Reverse Proxy Server로 사용하기 위하여 Nginx를 사용하였다.
Apache보다 동작이 단순하고, 단순하게 전달자의 역할만 하기 때문에 동시 접속 처리에 있어 효율적이라고 생각하였다. 또한 무중단 배포 자동화를 구현할 수 있다는 장점이 있다.

프로젝트에서는 Nginx에서 Certbot을 통해 SSL(TLS)을 발급받아 HTTPS로 리다이렉션하도록 적용하였다.(SSL과 적용 과정에 대한 설명은 밑에서 설명)

Reverse Proxy
Reverse Proxy란, 외부의 요청을 받아 백엔드 서버로 요청을 전달하는 것을 의미한다.
프록시 서버(80번 포트)는 외부에서의 요청을 단순하게 전달(포워딩)하고, 실제 요청에 대한 작업은 내부에 있는 애플리케이션 서버(8080번 포트)에서 처리하게 된다.

Proxy에 관한 더 자세한 설명은 포스팅을 참조하면 된다.

SSL(TLS)

기술에 대한 설명
SSL과 TLS는 모두 웹 서버와 사용자의 웹 브라우저 간 통신을 암호화 하는데 사용되는 프로토콜이다.

공개 키와 개인 키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용한다. (TLS는 SSL의 업데이트 버전으로, MAC 함수 생성을 위해 다른 암호화 알고리즘을 사용하며 이는 이전 버전의 SSL보다 많은 경고 코드를 포함하고 있다)

SSL 디지털 인증서는 클라이언트와 서버간의 통신을 공인된 제3자(CA) 업체가 보증해주는 전자화된 문서이다.

SSL 작동 원리
Client가 Request를 하면 TCP Level에서 연결이 맺어진 이후 SSL/TLS Handshake를 수행한다.

이 기술이 프로젝트에 필요한 이유는 무엇인가?
먼저, HTTP 프로토콜에 대한 이해가 필요하다.

• HTTP 프로토콜은 인터넷 상에서 정보를 주고 받기위한 프로토콜로,
  평문 통신으로 직접 TCP와 통신하기 때문에 패킷 스내핑등 보안적 약점이 생길 수 있다.

• HTTPS는 HTTP의 이러한 보안적 약점을 보완한 프로토콜이다.
  HTTPS로 접속하기 위해 먼저 SSL을 인증함으로써 정보를 암호화하고 해독하지 못하도록하여, 개인 정보 유출 등을 막으며 좀 더 안전한 인터넷 통신을 주고받을 수 있다.

요약하자면, SSL(TLS)을 설정해야하는 이유는 서버와 클라이언트간 통신상의 암호화를 위해서이고, HTTPS로 접속하기 위해 SSL(TLS) 인증이 필요하다.

[정리] HTTP vs HTTPS

• HTTP
  인터넷 상에서 정보를 주고 받기위한 프로토콜이다.
  평문 통신으로 직접 TCP와 통신한다.

• HTTPS
  HTTP의 보안적 약점을 보완한 프로토콜이다. (HTTP+Secure)
  모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
  인증서를 통해 통신하고 있는 상대가 접근이 허가된 상대인지 확인한다.
  HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다.

Let's Encrypt

Let’s Encrypt는 SSL 인증서를 무료로 발급해주는 CA(Certificate Authorities)이다.
SSL인증은 다 똑같은 것이 아니라 신뢰수준에 따라 보안레벨이 달라진다.
SSL 인증서를 발급받기 위해 무료로 발급해주는 Let's Encrypt 인증서를 사용하였다. 하지만, Let's Encrypt는 사이트들이 블로킹되는 경우도 많이 있어서 무조건 안전하고 좋다고 볼 수는 없다.

Certbot

Let's Encrypt 는 무료 SSL인증서를 발급해주는 곳이라면, Certbot는 Let's Encrypt 인증서를 자동으로 발급 및 갱신을 해주는 프로그램이다. LetsEncrypt를 사용하여 SSL 인증서를 얻기 위해서는 서버에 Certbot를 설치해야한다.
무료로 HTTPS를 간단하게 적용할 수 있고, 자동으로 갱신할 수 있다는 이점이 있다.

Certbot을 이용해 인증서를 받기위해선 서비스를 운용하는 서버 & 서비스할 도메인 주소 가 필수적으로 필요하다. (때문에 ec2 인스턴스를 생성하였다면 도메인 주소를 할당 받고 DNS 설정을 해야한다.)

[요약] HTTPS 적용 과정

1. nginx 설치
2. 포트 포워딩 (80번 포트가 들어오면 8080번 포트로 포워딩)
3. certbot 설치
4. SSL 인증서 받기, HTTPS 포트 인바운드 규칙 설정
5. certbot 자동 갱신 설정

Spring Boot

기술에 대한 설명
Spring Framework는 Java 기반의 오픈소스 프레임워크이다.

Spring Boot는 스프링을 편리하게 사용할 수 있도록 지원해주는 기능이다.
내장된 톰캣을 제공해 웹 서버를 설치하지 않아도 서버를 바로 실행할 수 있다는 차이점이 있다.
(스프링을 지원해주는 역할이기 때문에 스프링 프레임워크과 별도로 사용할 수는 없다)

더 자세한 Spring에 관한 설명은 포스팅을 통해 정리하였으니 참고하면 좋다!

[설명] Spring Boot의 Tomcat
Spring Boot에서는 톰캣과 서블릿 서버가 자동으로 설정(내장)되어있다.
따라서 스프링부트 애플리케이션을 실행하면 톰캣이 생성되고 서블릿이 추가가 되면서 애플리케이션이 정상적으로 작동한다.

[추가 설명] 서블릿 컨테이너 동작 방식에 대한 포스팅

이 기술을 프로젝트에 적용한 이유는 무엇인가?
Java는 객체지향 언어인데, 이때 Spring이 지원해주는 IoC,DI 등을 통해 객체지향이 지닌 다형성이라는 특징을 편리하게 이용할 수 있어, 개발자는 핵심 비즈니스 로직에만 집중하고 애플리케이션을 변경용이하고 확장가능성있게 개발 할 수 있기 때문에 사용하게 되었다.

[비교] Node.js
그렇다면 Node.js 대신 Spring을 사용한 이유는 무엇인가?

Node.js는 비동기식 함수를 통해 Non-blocking I/O를 처리하는데 최적화된 플랫폼이다.
내부적으로 싱글 스레드를 사용하기 때문에 메모리를 크게 잡아 먹지도 않아 효율적이다.
때문에, 진행하고자 하는 프로젝트의 주제가 동시요청과 실시간 환경이 중요한 애플리케이션에서 보다 효율적이다.

하지만 이번에 진행했던 프로젝트의 주제는 I/O 요청이 많은 양의 작은 데이터를 주고 받는 서버가 아니었기 때문에 Spring이 조금 더 적합하다고 판단하였다. 또한 Spring의 경우 Spring Security를 통해 OAuth를 지원받을 수 있고, Spring JDBC를 통해 DB 커넥터의 변경이 보다 자유롭다고 판단하여 사용하였다.
(다음번에 실시간성이 중요한 프로젝트를 진행하게 된다면 Node.js로 진행해보고 싶다!)

MySQL

이 기술을 프로젝트에 선택한 이유는 무엇인가?
해당 프로젝트는 주된 영화(컨텐츠) 라는 데이터가 '제목', '감독', '평점', '줄거리' 등 추후에 확장되기보다는, 데이터의 구조가 명확한 정형 데이터라고 판단하였다.

때문에 RDBMS는 NoSQL과 달리모든 데이터를 2차원 테이블 형태로 관리할 수 있다는 점에서 적합하다고 판단하여 사용하게 되었다.

어떻게 사용했는가?
JdbcTemplate 사용해서 SQL을 직접 작성하였다.
JdbcTemplate에 드라이버 로딩, DB연결, 자원해제 기능을 맡기기 때문에, 개발자는 SQL작성/전송에 집중할 수 있다는 장점이 있다고 생각하였다.

하지만, 추후에 리팩터링을 진행하기 시작하며 깨달은 결과 쿼리문에 따른 유지보수가 불편하고, SQL query문을 작성해야 하기 때문에 객체 지향 개발이 어렵다는 것을 깨달았다.
때문에 JPA를 학습하며 JdbcTemplate 대신 ORM 기반의 JPA로 리팩터링을 진행하고 있다.

REST API

기술에 대한 설명
REST란 필요한 자원에 접근하는 방식을 정해놓은 규칙이다.
URI를 통해 자원을 명시하고, HTTP 메소드를 통해 자원에 대한 연산을 처리한다.

• 장점
  REST는 HTTP 프로토콜을 그대로 사용하므로 별도의 인프라를 구축할 필요가 없고, HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. 또한 REST API를 통해 메시지가 의도하는 바를 명확하게 나타내므로 이해하기 용이하다는 장점이 있다.

• 유의할 점
  다만, HTTP Method 형태가 4가지로 제한적이고 정확한 표준이 없기 때문에 설계 규칙들을 잘 지키며 작성해야한다. (REST에는 여러 가지 설계 규칙이 있는데, 이러한 규칙을 잘 지켜서 작성한 API를 REST API 혹은 RESTful한 API라고 한다.)

더 자세한 REST API에 대한 설명은 포스팅을 참조할 수 있다.

이 기술을 프로젝트에 적용한 이유는 무엇인가?
시작할 당시 클라이언트가 앱,웹 등 어떤 플랫폼으로 구현할지 정하지 않았었기에 REST API로 개발하게 되면 다양한 플랫폼으로의 확장이 가능하다는 장점이 있었고,
RESTful API 로 설계한다면 다른 애플리케이션들도 RESTful API를 통해 (서버가 데이터를 보내줌으로써) 상호간에 통신이 편리하다고 생각했기 때문에 REST API로 개발하게 되었다.

[참조]
https://velog.io/@jjonggang/Spring-Boot-Nginx%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-Spring-Boot%EB%A5%BC-80%EB%B2%88-%ED%8F%AC%ED%8A%B8%EB%A1%9C-%ED%94%84%EB%A1%9D%EC%8B%9C%ED%95%98%EA%B8%B0
https://dokdogalmaegi.tistory.com/55
https://velog.io/@deannn/Apache%EC%99%80-NginX-%EB%B9%84%EA%B5%90-%EC%B0%A8%EC%9D%B4%EC%A0%90
https://sorjfkrh5078.tistory.com/289
https://velog.io/@davidko/Nginx%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0#%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%97%90-%EB%8F%84%EC%9E%85%ED%95%9C-%EC%9D%B4%EC%9C%A0
https://steady-coding.tistory.com/629
https://steady-benny.medium.com/which-is-your-choice-springboot-or-nodejs-1f44696488e7