나는 책을 통해서만 백엔드를 경험했지 밑바닥부터 내가 뭔갈 만들어 본 경험이 스프링 부트 3 한 번 밖에 없다.
프로젝트를 시작하면서 백엔드 진도를 나갈 필요가 있어 작업하면서 공부도 할 겸 '백엔드 30일 완성' 책을 구매했다.
앞으로 내가 위와 같은 제목으로 남기는 기록은 책을 읽으면서 내가 몰랐던 내용을 기록하는 것이다.
나는 GPT랑 계속 대화하면서 배우고 그를 통해 알게 된 사실을 블로그에 남기는 걸 좋아한다. 이게 나에게 딱 맞다.
따라서 본 블로그의 글들은 거의 나만을 위한 것이다. 남들 보기 좋으라고 친절하게 정리한 게 거의 없다.
그래도 나의 '관점'이 블로그 방문객들에게 도움이 될 수도 있다고 생각한다.
내가 잘 몰랐던 걸 남도 잘 모를 수 있는 거니까.
(8p)
Java 기반 웹 서버를 생성하고 이를 NodeJS의 Express와 같은 프로덕션 준비 서버와 비교할 수 있도록 안내한다.
둘의 차이가 있나?
일반 웹 서버와 프로덕션 준비 서버의 차이는 주로 성능, 안정성, 보안, 확장성 측면에서 나타납니다.
일반 웹 서버
- 개발용: 주로 개발 및 테스트 단계에서 사용.
- 성능: 기본적인 요청 처리 성능 제공.
- 설정: 최소한의 설정으로 동작.
- 안정성: 높은 트래픽이나 스트레스 테스트에 적합하지 않을 수 있음.
- 보안: 보안 기능이 충분하지 않을 수 있음.
- 예: Python의 Flask, Ruby의 WEBrick.
프로덕션 준비 서버
- 운영용: 실제 서비스 환경에서 사용.
- 성능: 고성능 요청 처리 및 다중 스레드/프로세스 지원.
- 설정: 세밀한 설정 가능, 고급 설정 옵션 제공.
- 안정성: 높은 트래픽을 견딜 수 있도록 설계.
- 보안: 강화된 보안 기능 제공.
- 예: Java의 Tomcat, Spring Boot 내장 서버, Node.js의 Express, Nginx, Apache.
주요 차이점 요약
- 성능: 프로덕션 준비 서버는 더 많은 트래픽과 요청을 효율적으로 처리할 수 있습니다.
- 안정성: 고가용성과 오류 복구 기능이 더 잘 갖춰져 있습니다.
- 보안: 프로덕션 준비 서버는 보안에 더 중점을 둡니다.
- 설정: 더 복잡하고 세밀한 설정이 가능합니다.
- 확장성: 확장성을 고려한 아키텍처를 갖추고 있습니다.
개발 단계에서는 간단한 일반 웹 서버를 사용해도 되지만, 실제 서비스 운영 단계에서는 프로덕션 준비 서버를 사용하는 것이 좋습니다.
뭔가 이상한데?
자바 톰캣이랑 스프링 부트 내장 서버는 프로덕션 준비 서버라는데?
그래서 서버의 종류를 확인해 봤다.
1. 웹 서버 (Web Server)
- 역할: HTTP 요청을 처리하고, 웹 페이지를 클라이언트(브라우저)에게 제공.
- 예: Apache, Nginx, Microsoft IIS.
2. 애플리케이션 서버 (Application Server)
- 역할: 웹 서버와 데이터베이스 서버 사이에서 동적 콘텐츠를 생성하고 비즈니스 로직을 처리.
- 예: JBoss, Tomcat, WebLogic.
3. 데이터베이스 서버 (Database Server)
- 역할: 데이터베이스를 관리하고, 데이터를 저장, 검색, 수정하는 기능 제공.
- 예: MySQL, PostgreSQL, Oracle, Microsoft SQL Server.
4. 파일 서버 (File Server)
- 역할: 파일 저장, 관리 및 공유 기능 제공.
- 예: Samba, FTP 서버, Windows Server의 파일 공유 기능.
5. 메일 서버 (Mail Server)
- 역할: 이메일 송수신, 저장, 관리 기능 제공.
- 예: Microsoft Exchange Server, Postfix, Sendmail.
6. DNS 서버 (DNS Server)
- 역할: 도메인 이름을 IP 주소로 변환하는 기능 제공.
- 예: BIND, Microsoft DNS, Cloudflare DNS.
7. 프록시 서버 (Proxy Server)
- 역할: 클라이언트 요청을 대신하여 처리하고, 요청을 다른 서버로 전달.
- 예: Squid, HAProxy, Nginx (프록시 모드).
8. 캐시 서버 (Cache Server)
- 역할: 자주 요청되는 데이터를 캐싱하여 응답 속도 향상.
- 예: Varnish, Redis, Memcached.
9. 인증 서버 (Authentication Server)
- 역할: 사용자 인증 및 권한 부여 관리.
- 예: LDAP 서버, Kerberos, OAuth 서버.
10. 미디어 서버 (Media Server)
- 역할: 비디오, 오디오 등의 미디어 콘텐츠 스트리밍 제공.
- 예: Wowza, Plex, Red5.
11. 게임 서버 (Game Server)
- 역할: 온라인 게임의 데이터와 상태를 관리하고 동기화.
- 예: Photon, Unity Multiplayer, AWS GameLift.
12. 클라우드 서버 (Cloud Server)
- 역할: 클라우드 환경에서 가상화된 컴퓨팅 자원 제공.
- 예: AWS EC2, Google Cloud Compute Engine, Microsoft Azure.
13. 컨테이너 오케스트레이션 서버 (Container Orchestration Server)
- 역할: 컨테이너화된 애플리케이션의 배포, 관리, 스케일링 제공.
- 예: Kubernetes, Docker Swarm.
프록시 서버가 잘 이해가 안 된다.
프록시 서버(Proxy Server)는 클라이언트와 실제 서버 사이에서 중개 역할을 하는 서버입니다. 클라이언트의 요청을 받아서 실제 서버로 전달하고, 실제 서버의 응답을 받아 클라이언트로 전달하는 역할을 합니다. 프록시 서버는 여러 가지 용도로 사용되며, 다음과 같은 주요 기능과 이점을 제공합니다:
주요 기능
- 트래픽 관리: 네트워크 트래픽을 제어하고 분산하여 서버 부하를 줄이고 성능을 향상시킵니다.
- 캐싱: 자주 요청되는 콘텐츠를 캐시하여 요청 속도를 향상시키고 네트워크 대역폭을 절약합니다.
- 보안: 클라이언트의 IP 주소를 숨기고, 악성 트래픽을 차단하여 보안을 강화합니다.
- 콘텐츠 필터링: 특정 웹사이트나 콘텐츠에 대한 접근을 제한할 수 있습니다.
- 로깅 및 모니터링: 네트워크 트래픽을 기록하고 모니터링하여 분석할 수 있습니다.
프록시 서버의 종류
- 포워드 프록시 (Forward Proxy)
- 역할: 클라이언트가 요청을 보낼 때 중개하여 요청을 실제 서버로 전달.
- 사용 예: 내부 네트워크 사용자가 외부 인터넷에 접근할 때 사용.
- 장점: IP 주소 숨김, 접근 제어, 캐싱 등을 통해 보안 및 성능 향상.
- 리버스 프록시 (Reverse Proxy)
- 역할: 클라이언트 요청을 받아 여러 백엔드 서버로 전달하여 처리.
- 사용 예: 외부 사용자가 웹 애플리케이션에 접근할 때 사용.
- 장점: 로드 밸런싱, SSL 종료, 캐싱, 보안 강화 등을 제공.
- 오픈 프록시 (Open Proxy)
- 역할: 누구나 접근할 수 있는 프록시 서버.
- 사용 예: 익명성을 위해 사용.
- 장점: 개인의 IP 주소를 숨기고 익명으로 인터넷을 사용할 수 있게 함.
- 주의: 보안 취약점이 있을 수 있고 악용될 가능성이 있음.
- 투명 프록시 (Transparent Proxy)
- 역할: 클라이언트가 프록시 서버를 인식하지 못한 채로 요청을 처리.
- 사용 예: 조직 내에서 인터넷 트래픽을 모니터링하고 제어할 때 사용.
- 장점: 사용자가 별도의 설정 없이 사용할 수 있음.
프록시 서버의 이점
- 보안 강화: 클라이언트와 서버 간의 직접적인 연결을 차단하여 보안을 강화.
- 속도 향상: 캐싱을 통해 자주 요청되는 콘텐츠의 응답 시간을 단축.
- 로드 밸런싱: 리버스 프록시의 경우, 트래픽을 여러 서버에 분산시켜 서버의 부하를 균형 있게 유지.
- 액세스 제어: 특정 콘텐츠에 대한 접근을 제한하고, 사용자의 인터넷 사용을 제어.
예시
- 포워드 프록시: 회사 내부 네트워크에서 직원들이 외부 웹사이트에 접근할 때 프록시 서버를 통해 접속.
- 리버스 프록시: 웹 애플리케이션 서버 앞에 위치하여 클라이언트의 요청을 백엔드 서버로 분배.
프록시 서버는 다양한 방식으로 네트워크 트래픽을 관리하고 보안을 강화하며, 시스템 성능을 최적화하는 데 중요한 역할을 합니다.
마지막으로 개발 환경 체크 한 번 했다.
1. 개발 환경 (Development Environment)
- 목적: 새로운 기능 개발, 버그 수정.
- 특징: 개발자들이 코드를 작성하고 테스트하는 환경. 변경 사항을 빠르게 적용하고 테스트할 수 있음.
- 예: 로컬 컴퓨터(예: 맥미니), IDE, 로컬 데이터베이스 등.
2. 테스트 환경 (Testing Environment)
- 목적: 개발된 기능과 수정된 코드가 제대로 작동하는지 검증.
- 특징: QA(품질 보증)팀이 다양한 테스트(기능 테스트, 통합 테스트, 시스템 테스트 등)를 수행. 실제 운영 환경과 유사한 환경을 구성.
- 예: 별도의 테스트 서버, 가상 환경 등.
3. 스테이징 환경 (Staging Environment)
- 목적: 실제 운영 환경으로 배포되기 전에 마지막으로 점검.
- 특징: 운영 환경과 거의 동일하게 구성. 최종 테스트 및 검증을 위한 단계.
- 예: 운영 환경과 동일한 설정의 서버 또는 클라우드 환경.
4. 운영 환경 (Production Environment)
- 목적: 실제 사용자에게 서비스 제공.
- 특징: 고가용성, 안정성, 보안이 중요. 실시간 트래픽과 사용자 데이터를 처리.
- 예: 실제 서비스가 배포되는 서버(예: 라즈베리파이).
5. 통합 환경 (Integration Environment)
- 목적: 여러 개발자들의 코드 변경 사항을 통합하고 테스트.
- 특징: 통합된 코드를 지속적으로 빌드하고 테스트. CI/CD 파이프라인의 일부.
- 예: CI 서버(Jenkins, GitLab CI 등).
6. UAT 환경 (User Acceptance Testing Environment)
- 목적: 최종 사용자가 새 기능을 테스트하고 승인.
- 특징: 실제 사용자나 비즈니스 팀이 새로운 기능을 검토하고 피드백 제공.
- 예: 스테이징 환경과 유사하게 구성.
요약
- 개발 환경: 로컬 개발 및 테스트.
- 테스트 환경: QA팀의 테스트.
- 스테이징 환경: 운영 환경과 동일한 설정으로 최종 점검.
- 운영 환경: 실제 사용자에게 서비스 제공.
- 통합 환경: 코드 통합 및 빌드 테스트.
- UAT 환경: 사용자 승인 테스트.
라즈베리파이를 운영 환경으로 사용하고, 로컬 맥미니를 개발 환경으로 사용한다면, 다음과 같이 정리할 수 있습니다:
- 개발 환경: 맥미니.
- 운영 환경: 라즈베리파이.
- 추가 환경: 테스트와 스테이징 환경을 설정하면, 더 철저한 검증이 가능합니다. 예를 들어, 테스트 환경을 별도로 설정하여 QA 작업을 수행할 수 있습니다.
개발 환경에서도 테스트를 한다. 다른 곳에서도 테스트를 한다.
차이가 있다면 개발 환경에서는 해당 환경을 사용 중인 개발자가 로컬 환경을 대상으로 유닛 테스트 정도의 작은 테스트를 한다.
개발이 진척되면 여러 개발자의 산출물이 CI/CD에 모인다. 그 지점이 통합 환경이다.
거기서 또 테스트하고 빌드하다가 마켓에 디플로이 하기 전에 스테이징 환경에서 최종 리허설을 한다.
이 부분은 이 정도면 정리된 것 같다.
가기 전에 릴리즈랑 디플로이 차이 한 번 보자.
릴리즈(Release)와 디플로이(Deploy)는 소프트웨어 개발 및 배포 과정에서 서로 다른 의미와 목적을 가진 두 가지 중요한 개념입니다. 이 둘의 차이를 이해하는 것은 개발 및 운영 프로세스를 효율적으로 관리하는 데 도움이 됩니다.
릴리즈 (Release)
- 목적: 소프트웨어의 새로운 버전을 준비하고 이를 공식적으로 발표하는 과정입니다.
- 내용:
- 버전 관리: 새로운 기능, 버그 수정 등이 포함된 소프트웨어의 특정 버전을 정의하고 관리합니다.
- 릴리즈 노트 작성: 새로운 기능, 수정 사항, 알려진 이슈 등을 문서화합니다.
- 마일스톤: 릴리즈는 일반적으로 프로젝트의 중요한 마일스톤으로 간주되며, 릴리즈 계획에 따라 일정이 관리됩니다.
- 준비 단계: 릴리즈 준비 단계에서는 모든 기능이 완성되고, 테스트가 완료된 상태여야 합니다.
- 예시: 소프트웨어 버전 2.0을 릴리즈하며, 사용자에게 새로운 기능과 변경 사항을 알립니다.
디플로이 (Deploy)
- 목적: 릴리즈된 소프트웨어 버전을 실제 운영 환경에 배포하여 사용자에게 제공하는 과정입니다.
- 내용:
- 배포 프로세스: 소프트웨어를 서버, 클라우드 환경 또는 사용자의 디바이스에 설치하거나 업데이트합니다.
- 자동화 도구 사용: CI/CD 파이프라인을 통해 자동화된 배포를 수행하는 경우가 많습니다.
- 환경 설정: 운영 환경에 맞게 소프트웨어를 설정하고 구성합니다.
- 모니터링 및 롤백: 배포 후 문제를 감지하고 필요시 롤백할 수 있는 계획이 포함됩니다.
- 예시: 릴리즈된 버전 2.0을 실제 운영 서버에 배포하여 사용자들이 새로운 기능을 사용할 수 있도록 합니다.
요약
- 릴리즈:
- 목적: 소프트웨어의 새로운 버전을 준비하고 공식적으로 발표.
- 활동: 버전 관리, 릴리즈 노트 작성, 릴리즈 계획 수립.
- 결과: 릴리즈된 소프트웨어는 준비 완료 상태가 됩니다.
- 디플로이:
- 목적: 릴리즈된 소프트웨어를 운영 환경에 배포하여 사용자에게 제공.
- 활동: 배포 프로세스 실행, 환경 설정, 모니터링 및 롤백 계획.
- 결과: 사용자들이 릴리즈된 소프트웨어를 실제로 사용하게 됩니다.
실제 시나리오
- 릴리즈: 개발 팀이 모든 기능을 완료하고, 테스트를 마친 후 버전 1.0을 릴리즈합니다. 릴리즈 노트에는 새로운 기능, 수정된 버그, 알려진 문제 등이 포함됩니다.
- 디플로이: 릴리즈된 버전 1.0을 운영 팀이 실제 서버에 배포합니다. 배포가 완료되면 사용자는 새로운 기능을 사용할 수 있게 됩니다.
이처럼 릴리즈와 디플로이는 소프트웨어 개발 및 배포 과정에서 서로 다른 단계와 목적을 가지고 있으며, 각각의 단계가 성공적으로 완료되어야 전체 프로세스가 원활하게 진행될 수 있습니다.
한 줄을 이해하는데 이렇게나 많은.. 부가 설명이... 필요했다....
나 이제 '8페이지'인데... 😊...
(30p)
절차 기반 애플리케이션이 이벤트 기반 웹 애플리케이션이 되는 방법은 무엇일까?
Glue라는 것이 코드를 변환하는 역할을 한다고 한다.
프로그래밍에서 "glue"라는 용어는 일반적으로 서로 다른 시스템, 언어, 또는 패러다임을 연결하고 상호작용하게 만드는 코드나 도구를 의미합니다. 이 개념은 다양한 맥락에서 사용될 수 있지만, 주된 역할은 호환성이나 통합을 쉽게 만들어주는 것입니다.
Glue 코드
Glue 코드는 서로 다른 소프트웨어 구성 요소를 연결하는 코드를 의미합니다. 예를 들어, 하나의 시스템이 다른 시스템의 API를 호출해야 하는 경우, 이를 위한 인터페이스를 제공하여 두 시스템이 원활하게 통신할 수 있도록 합니다.
예시
- API 게이트웨이:
- 여러 서비스의 API를 단일 진입점에서 관리하고, 필요한 변환 작업을 수행하는 역할을 합니다.
- 번역 레이어 (Translation Layer):
- 서로 다른 데이터 형식이나 프로토콜을 사용하는 시스템 간의 데이터 변환을 처리합니다.
- 예: JSON 데이터를 XML로 변환하여 SOAP 기반의 웹 서비스와 통신할 수 있게 합니다.
- 프로그래밍 언어 인터페이스:
- 서로 다른 프로그래밍 언어로 작성된 코드가 상호작용할 수 있도록 인터페이스를 제공합니다.
- 예: Python 코드에서 C 라이브러리를 사용할 수 있게 하는 SWIG(Simple Wrapper and Interface Generator) 도구.
- 미들웨어 (Middleware):
- 애플리케이션과 네트워크 서비스 간의 중개 역할을 하며, 데이터 변환, 메시지 큐 관리, 서비스 호출 등을 처리합니다.
- 예: 메시지 브로커인 RabbitMQ는 다양한 프로토콜과 언어를 지원하여 애플리케이션 간의 메시징을 처리합니다.
Glue 코드의 필요성
- 이질적인 시스템 통합: 서로 다른 시스템이나 서비스가 통합되어야 할 때 필요한 변환 및 중개 작업을 수행합니다.
- 언어 간 상호운용성: 서로 다른 프로그래밍 언어로 작성된 모듈이 통합될 때, 이를 중개하는 역할을 합니다.
- 패러다임 전환: 함수형 프로그래밍과 객체지향 프로그래밍 등 서로 다른 프로그래밍 패러다임 간의 전환을 지원합니다.
결론
"Glue"라는 개념은 서로 다른 시스템, 언어, 또는 패러다임을 연결하고 상호작용하게 만드는 코드나 도구를 의미합니다. 이는 소프트웨어 개발에서 호환성 문제를 해결하고, 다양한 구성 요소를 원활하게 통합하는 데 중요한 역할을 합니다.
'개발 상식 시리즈 > 백엔드 상식' 카테고리의 다른 글
백엔드 30일 완성을 읽고 배운 것(60페이지까지) (0) | 2024.05.18 |
---|---|
주요 아키텍처 패턴 (0) | 2024.05.16 |
주요 API 아키텍처 스타일 (0) | 2024.05.16 |