[네트워크기초이론]#12. WAS, JVM 그리고 RESTful API

WAS

- 웹 시스템에서 처리 주체

- 왼쪽으로는 리소스를 수신하는 웹서버

- 오른쪽에는 DataBase

- 본인은 처리 주체로서의 연산

MVC architecture

• view: 눈에 보이는 무엇을 다룬다 (웹서버가 정적 데이터를 가지고 있다가 처리)
• model: 데이터, 자료구조
• service: 프로세스 로직, 비즈니스 로직
• control: 리소스뒤에 URL/URI, 이것과 관련된 체계 (www.naver.com/~~ ~~에 따라 다른 화면)

URI (Uniform Resource Identifier)

• 정의: 웹에서 자원(리소스)을 식별하기 위한 고유한 문자열이다.
• 비유: 책에 있는 책 이름과 같다. 당신이 어떤 책을 찾고자 할 때 그 책의 이름을 통해 찾을 수 있다.

URL (Uniform Resource Locator)

• 정의: 웹에서 자원(리소스)을 식별하고 위치를 지정하는 문자열이다. URL은 URI의 하위 분류에 해당하므로, 모든 URL은 URI이다. 그러나 모든 URI가 URL인 것은 아니다.
• 비유: 책에 있는 책 이름 + 그 책의 정확한 위치(어떤 서점의 어떤 선반 위에 있는지)와 같다.

예시

• URI: www.example.com/products
  • 여기에서는 "products"라는 자원을 식별한다.
• URL: http://www.example.com/products?id=1
  • 여기에서는 "products"라는 자원을 식별하고, 그 위치는 http 프로토콜을 사용하여 www.example.com 도메인에서 id=1인 상품을 찾아나간다.

결론

• URI는 웹의 자원을 식별하는 역할이다.
• URL은 웹의 자원을 식별하고, 그 위치를 지정하는 역할이다.

간단히 말하면, 모든 URL은 URI이다. 그러나 모든 URI가 URL인 것은 아니다. URL은 그 자원의 '어디에 있는지'까지 알려준다!

처리할 때 사용하는 프로그래밍 언어

- CPU: 컴퓨터를 이루는 핵심적 구성요소. CPU에 다라 컴퓨터의 정체성이 결정됨, Machine이라고 함

JVM

- java는 paltform independent: 플랫폼이 무엇이 됐든 상관 없이 작동한다

➡️이렇게 되게 하기 위해서 CPU를 S/W에 구현 

- Machine인데 S/W로 구현 → Virtual Machine

- Java라는 언어에 대해서만 작동하는 VM → Java Virtual Machine

Java byte code

- JVM이 작동할 때는 이 VM이 인식할 수 있는 기계어로 작동한다

Module

- JVM에서 작동할 수 있는 모듈들

- DB다루기, I/O 기능 ...

Middle Ware

- 이것들을 다 모아 하나의 새로운 S/W를 만들어

- 이 S/W는 이 자체로서 존재 의미를 갖지 않고, 또 다른 S/W들이 존재할 때 그 SW들이 작동하기 좋게 만들어줌

- SW를 위한 또 다른 SW

- SW와 HW 중간 연결고리가 되어주는 SW

- WAS

Frame Work

- Middle ware를 대충 만들지 못하도록 Frame work를 집어 넣는다

- Frame work에 의해 개발되도록 강제

- 초보자 실수 X

- 효율적 운영

- Spring, Sprign boot ...

- 웹 백엔드 개발이 이거 개발하는거

상단 로직을 Script로

"상단 로직을 Script로 해낼 수 있다" ?

• 웹 개발의 맥락에서 "스크립트"는 주로 클라이언트 측 코드를 의미합니다. 웹 페이지에서 동적인 기능(예: 버튼 클릭 시 팝업창 띄우기)을 구현하기 위해 JavaScript를 사용하곤 합니다.
• JSP(Java Server Pages), PHP, ASP(Active Server Pages) 등은 웹 서버에서 실행되는 스크립팅 언어입니다. 이들은 웹 페이지를 동적으로 생성하는 데 사용되며, 사용자의 요청에 따라 콘텐츠를 바꿔서 제공할 수 있습니다.
• 스크립트 언어 (Scripting Language): 이는 프로그래밍에서 특정 작업을 자동화하거나, 빠르게 프로토타이핑하기 위해 사용되는 프로그래밍 언어를 의미합니다. Python, JavaScript, Ruby와 같은 언어들이 여기에 해당합니다.

- JSP: 예전에 많이 씀

- PHP: (WAS가 tomcat이나 JAVA 기반 돌리는 게 아니면), WAS가 PHP가 인식될 수 있는 걸 써야해

- ASP: 윈도우, 예전에 많이 씀 (요즘엔 JSP, ING?)

- node.js: WAS쪽이 JavaScript로 작동하는 것

- Java 코드로 다 해야되는 건 아니고 Script만으로 해결할 수 있다

 

웹서비스를 이루는 구성 요소는 3놈이 있다!

- 각각을 tier라고 함

- 각각의 tier들이 연결된 형태

- 셋이 힘을 합치면 3 - tier web solution(service)

 

웹서비스 성능 결정 요건

- 누군가 요청(자료 요구나 처리 요구) ➡️ 웹서버가 수신 ➡️ WAS에 넘김 ➡️ DB에서 처리 그리고 여기서 응답

- 지연 / 장애 = DB가 반응이 늦는 것

     - DB의 응답 속도

- WAS의 처리 연산에 걸리는 시간

     - Java byte code

APM (application performance management system)

- 이 두가지를 열심히 모니터링하는 APM

- 대표적으로 Scouter APM이 있다

Scouter APM이란?

Scouter는 "Application Performance Management"의 줄임말인 APM 도구 중 하나입니다. APM 도구는 애플리케이션의 성능을 모니터링하고 분석하는 데 사용되는 도구들입니다. Scouter는 이 중에서도 오픈 소스로 제공되는 도구로, 특히 자바 기반 애플리케이션의 성능을 모니터링하는 데 특화되어 있습니다.

Scouter APM을 애플리케이션의 '건강 검진 도구'로 생각해보세요.

예를 들어, 사람이 병원에 건강 검진을 받으러 간다고 상상해보세요. 병원에서는 여러 가지 검사를 통해 우리 몸의 건강 상태를 확인하고, 문제가 있으면 그 원인을 찾아내기 위해 추가적인 검사를 진행합니다. 마찬가지로, Scouter APM도 애플리케이션의 '건강 상태'를 체크하고, 문제가 있으면 그 원인을 찾아내는 역할을 합니다.

결론적으로, Scouter APM은 애플리케이션의 성능 문제를 빠르게 감지하고 원인을 찾아내는 데 도움을 주는 도구입니다.

Scouter APM의 주요 기능

1. 성능 모니터링: 애플리케이션의 응답 시간, 처리량, 실패율 등 주요 성능 지표를 실시간으로 모니터링합니다.
2. 트랜잭션 추적: 문제가 발생한 특정 트랜잭션을 추적하여 성능 저하의 원인을 파악할 수 있습니다.
3. 알림: 성능 이상이 감지되면 관리자에게 알림을 보낼 수 있습니다.

- Jennifer

제니퍼(JENNIFER)란?

제니퍼는 제니퍼 소프트가 개발한 APM(Application Performance Management) 도구입니다. APM 도구는 애플리케이션의 성능을 모니터링하고, 문제가 발생할 경우 원인을 파악하게 도와주는 도구들입니다. 제니퍼는 이런 APM 도구 중에서도 많은 기능과 세밀한 모니터링 능력으로 국내외에서 널리 사용되고 있습니다.

제니퍼의 주요 기능:

1. 실시간 모니터링: 애플리케이션의 성능, 트랜잭션, 에러 등을 실시간으로 모니터링할 수 있습니다.
2. 성능 진단: 성능 저하나 문제가 발생했을 때 그 원인을 빠르게 파악하게 도와줍니다.
3. 시각화: 다양한 차트와 그래프를 통해 성능 데이터를 쉽게 파악할 수 있게 해줍니다.
4. 알림 기능: 문제가 발생하면 사용자에게 알림을 보내줍니다.

- Web client와 Web server 사이에서는 네트워크 속도가 빨라야 한다

- WAS에서는 처리속도

- DB는 응답속도

     - 성능 높이기 위해 튜닝 (퍼포먼스 튜닝)

     - 검색 속도 높이던, 데이터 쓰기 속도 높이던

 

용어 정리

Front-end Server

- Web Server 왼쪽으로는 Client, 즉 고객을 맞이하는 경계에 있다

Back-end Server

- 가장 안쪽에!

Server Farm

- Front ~ Back 안에 들어가 있는 애들이 서버들

- 그 서버들을 모아 놓은 것이 서버팜

 

최근의 웹

- 요청이 가면 응답이 오는 것은 같아

- request가 날라가서 GET(Read)을 하던, POST(Write)를 하던 (+ 그 외 메서드 여러개 더 있음)

     - 입출력을 한다

- 그럼 옛날에는 HTML이 날라왔는데

- 요즘에는 단순히 데이터만 날라온다

      - 거의 대부분 JSON 형태

      - HTML이 아니야 (자료만 덜렁 오는 것)

- 최근 UI가 매우 다양해짐

     - 다양한 OS와 기기들의 등장으로...

- HTML은 환경의 특수성에 영향을 많이 받는다

- 서버쪽에서 iOS거 따로, Android거 따로... 준비하는 것아 ❗아니라❗

- 데이터만 보낸다.

- 클라이언트 쪽에서 스스로 자신에게 맞는 HTML을 생성하자

- 생성시 프로그래밍 언어를 JavaScript를 쓰는 것

- JS로 코딩하면 코드가 길어져.. 여기도 Frame work가 들어감

      - React, View.js, Angular...

- 브라우저가 뭐가 됐든, 환경이 뭐가 됐든 각자 환경에 맞게 생성

 

CRUD

• Create: 생성
• Read: 읽기
• Update: 쓰기 (갱신)
  • 덮어 쓰기
  • 수정
• Delete: 삭제

- 어떤 웹 시스템을 하나의 기능 요소로 보고 CRUD의 기능을 제공

- 클라이언트는 CRUD 수행되는 기능을 단지 Call(호출)하면 됨

➡️ RESTful API가 탄생

RESTful API란?

RESTful API는 웹 상에서 서버와 클라이언트(대부분의 경우 웹 브라우저나 앱)가 서로 통신하는 방식 중 하나입니다.

상상해보세요. 당신이 레스토랑에 가서 주문을 합니다.

1. 메뉴 보기(Read): 메뉴판을 보고 음식을 선택합니다.
2. 주문하기(Create): 원하는 음식을 주문합니다.
3. 주문 변경(Update): 주문한 음식의 추가 요청이나 변경을 합니다.
4. 주문 취소(Delete): 주문한 음식을 취소합니다.

이처럼 레스토랑에서 음식을 주문하는 과정을 웹상에서 정보를 주고받는 것으로 생각해보면, 서버는 레스토랑, 클라이언트(당신의 웹 브라우저나 앱)는 손님, API는 주문하는 방식과 비슷합니다.

RESTful은 그 주문 방식을 '약속'한 것과 같습니다. 모든 레스토랑(서버)가 같은 방식으로 주문을 받는다면, 손님(클라이언트)은 어디서든 같은 방식으로 주문할 수 있겠죠? 그렇게 일관된 방식으로 정보를 주고받는 약속을 'RESTful'이라고 합니다.

결론적으로, RESTful API는 웹상에서 서버와 클라이언트가 정보를 주고받을 때의 일관된 '약속' 또는 '규칙'을 의미합니다!

- API 형태로 만들고 그거에 따른 자료만 넘겨 받는 방식으로, 필요한 HTML은 스스로 생성하도록 웹이 발전

 

보안

- 인터넷망과 WebServer가 붙을 때 항상 3가지 요소가 들어간다

• IPS (침입 방지 시스템)

IPS (침입방지시스템)란?

IPS는 "침입방지시스템"의 약자입니다. 컴퓨터 네트워크에서 해커나 악성 소프트웨어의 공격을 감지하고, 그것을 차단하는 장치나 프로그램을 말합니다.

상상해보세요. 당신의 집에 첨단 보안 시스템이 설치되어 있다고 가정해봅시다.

1. 감지: 누군가 문을 흔들거나 창문을 열려고 시도하면, 보안 시스템은 그 움직임을 감지합니다.
2. 차단: 누군가 집안으로 들어오려고 시도하면, 보안 시스템은 문이나 창문을 자동으로 잠궈서 침입을 막습니다.

IPS는 이러한 집의 보안 시스템과 유사합니다. 해커나 악성 소프트웨어가 네트워크에 침입하려고 시도할 때, IPS는 그 시도를 감지하고 공격을 차단하여 네트워크를 보호합니다.

그렇다면 IPS가 중요한 이유는?

인터넷의 세계는 우리 집과 같습니다. 여러 가지 위협이 존재하고, 그 위협으로부터 우리의 데이터나 시스템을 보호해야 합니다. IPS는 그러한 위협을 감지하고 방어하는 역할을 해줍니다.

결론적으로, IPS는 컴퓨터 네트워크의 "보안 경비원"과 같은 역할을 합니다. 해커나 악성 코드의 공격을 감지하고 차단하여 네트워크를 안전하게 보호해줍니다!

• SSL (암호화 부분 처리)

SSL이란?

SSL은 "Secure Socket Layer"의 약자입니다. 이는 인터넷 상에서 데이터를 안전하게 전송하기 위한 기술 중 하나입니다.

상상해보세요. 당신이 중요한 편지를 친구에게 보내려고 합니다. 그 편지는 개인적인 내용이므로 다른 사람이 읽으면 안 됩니다. 일반 편지봉투에 담아서 보내면, 중간에 누군가가 편지봉투를 열고 내용을 읽을 수 있습니다. 그래서 당신은 그 편지를 특별한 잠금이 있는 봉투에 넣어서 보냅니다. 친구만이 그 잠금을 풀 수 있는 열쇠를 가지고 있기 때문에, 중간에 누군가가 그 편지를 가로채도 내용을 읽을 수 없습니다.

SSL은 이런 "특별한 잠금이 있는 봉투"와 같습니다. 인터넷 상에서 정보를 보낼 때, SSL은 그 정보를 암호화하여 안전하게 전송합니다. 이렇게 되면 중간에 누군가 정보를 가로채도, 그 내용을 복호화할 수 있는 열쇠가 없기 때문에 정보를 읽을 수 없습니다.

그렇다면 SSL의 표시는?

웹 브라우저의 주소창을 보면, 일부 웹사이트 주소 앞에 "https://"로 시작하는 것을 볼 수 있습니다. 이 "https"는 해당 웹사이트가 SSL을 사용하여 안전하게 데이터를 전송한다는 것을 나타냅니다. 또한, 종종 자물쇠 아이콘이 주소창에 표시되기도 합니다.

결론적으로, SSL은 인터넷 상에서 데이터를 안전하게 전송하기 위한 보안 기술입니다. 이를 통해 사용자의 정보가 안전하게 보호됩니다!

• WAF (Web application Firewall)

WAF란?

WAF는 "Web Application Firewall"의 약자입니다. 그 이름에서 알 수 있듯이, WAF는 웹 애플리케이션을 보호하기 위한 특별한 방화벽입니다.

상상해보세요. 당신의 집에는 문과 창문이 있습니다. 이 문과 창문을 통해 사람들이 집안으로 들어오거나 나갈 수 있습니다. 하지만 도둑이나 원치 않는 사람들도 이 문과 창문을 통해 집안으로 들어올 수 있기 때문에, 보안 시스템이나 잠금 장치가 필요합니다.

이 보안 시스템이 집의 문과 창문을 보호하는 것처럼, WAF는 웹 애플리케이션의 "문과 창문"을 보호합니다. 웹 애플리케이션도 정보를 주고 받기 위한 '문'과 '창문'이 있는데, 해커들은 이를 통해 악의적인 행동을 시도할 수 있습니다. WAF는 이러한 악의적인 행동을 감지하고 차단하여 웹 애플리케이션을 보호합니다.

그렇다면 WAF의 역할은?

WAF의 주요 역할은 웹 애플리케이션에 들어오는 트래픽을 검사하고, 악성 트래픽(즉, 공격 시도)을 감지하고 차단하는 것입니다. SQL 인젝션, 크로스 사이트 스크립팅(XSS)과 같은 다양한 웹 공격 유형을 감지하고 방어할 수 있습니다.

결론적으로, WAF는 웹 애플리케이션의 경비원과 같은 역할을 합니다. 해커나 악의적인 행동을 감지하고 차단하여 웹 애플리케이션을 안전하게 보호해줍니다!

- 또 다른 이슈를 만들어냄

- 실무에서는 이런 것 까지 알아야해

 

 

출처: https://cafe.naver.com/windev/10953

 

 

 

 

출처: https://youtu.be/poKkQHUBt9A?si=ha6_WOZuzOxl16SO