Junbyeol Blog

No title

200524 JPA

Tags: Java, Server

Layered Architecture

Presentation layer : View
Control layer: Controller
Business layer: Service
Persistence layer: DAO(Data Access Object, Repository) ← 데이터에 영속성을 부여해줌
Domain Model layer: VO(Value Object), DTO(Data Transfer Object)

DTO

로직을 갖지 않는 순수한 데이터 객체
속성과 getter, setter만으로 이루어진 클래스!
VO는 DTO와 거의 비슷하나 read only 속성을 가짐
DTO는 전송되는 데이터의 컨테이너, VO는 데이터 그 자체(객체)의 의미로 사용됨

DAO

DB로의 접근을 전담하는 객체

Persistence(영속성)

Entity를 영구적으로 저장해주는 환경
프로그램을 종료해도 데이터를 잃지 않도록, DB에 데이터를 저장하는 것 == 영속성을 부여하는 것
Persistence Framework는 SQL Mapper와 ORM으로 구분

ORM(Object-relational mapping)

객체와 테이블의 매핑
객체의 메소드 호출만으로 쿼리를 수행할 수 있음
- ex) SELECT * FROM user == user.findAll()
이 둘을 mapping하는 것은 ORM framework
Persistant API라고도 부름
ex) JPA, Hibernate

cf) SQL Mapper

→ ORM이 객체 - 데이터의 매핑이라면, SQL Mapper는 객체 - SQL 쿼리의 매핑

→ ex) Mybatis, JdbcTempletes

JPA(Java Persistence API)

Copy of JPA YouTube 강의

ORM을 사용하기 위한 표준 인터페이스 모음
- 이 때, JPA를 구현하는 Implementation들을 ORM Framework라 부른다
- ex) Hibernate, EclipseLink, DataNucleus, OpenJPA
세가지 구성요소
1. javax.persistence.* 패키지로 정의된 API 그 자체
2. JPAL(Java Persistence Query Language)
3. 객체/관계 메타데이터

JDBC(Java Database Connectivity)

DB에 접근할 수 있도록 Java에서 제공하는 API
모든 Persistence Framework가 내부적으로 사용하고 있다
DB에서 자료를 쿼리, 업데이트하는 방법 제공

Hibernate

JPA의 구현체 중 하나
JDBC API가 내부에서 동작하고 있지만, 개발자가 직접 SQL을 작성할 필요는 없음

JPA의 동작과정

JPA는 애플리케이션과 JDBC(Java DB connectivity)사이에서 동작한다

→ 개발자가 직접 JDBC를 쓰는 것은 아님

JPA를 사용하는 이유

SQL 중심적 개발 대신 객체 중심으로 개발 가능
Java Collection에 데이터를 넣었다 뺐다 하듯이 사용 가능(간단한 CRUD)
유지보수가 편리하다

→필드가 바뀌어도 모든 SQL을 수정할 필요가 없다
Object와 RDB들 간의 패러다임의 불일치들을 해결해준다

[JPA] JPA란 - Heee’s Development Blog

[JDBC] JDBC, JPA/Hibernate, Mybatis의 차이 - Heee’s Development Blog

트랜잭션(Transaction)

:DB의 상태를 변환시키는 작업 단위

ACID(트랜잭션의 특징)

[DB이론] 트랜잭션(transaction)과 ACID 특성을 보장하는 방법

[Database] 8. 트랜잭션, 동시성 제어, 회복

Atomicity(원자성)
- 트랜잭션의 연산은 DB에 모두 반영되거나, 모두 반영되지 않아야 한다
- 하나의 연산이라도 오류가 발생하면 트랜잭션 전체가 취소되어야 한다
- Transaction은 Commit되거나 Rollback된다
Consistency(일관성)
- 트랜잭션이 DB의 고정요소들을 변화시키지 않는 것/ 제약조건을 위배하지 않는 것
- ex) 트랜잭션이 계좌 엔티티의 잔고 필드를 integer에서 string으로 바꾸면 안된다
- ex) 트랜잭션 수행 후
Isolation(격리성)
- 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들어서는 안된다
Durability(지속성)
- 성공적으로 수행된 트랜잭션은 영원히 반영된다

원자성/지속성 보장

회복 관리자 프로그램을 이용
롤백 세그멘트(rollback segment)에 트랜잭션 수행 직전의 상태를 보관
오류가 발생해도 롤백이 가능하다
일부만 진행된 트랜잭션을 취소시킨다(원자성)
값을 트랜잭션 이전의 상태로 복원한다 지속성

일관성/격리성 보장

동시성 제어로 해결해야 한다
- 무결성 제약 조건을 통해 일관성을 보장한다

No title

200525 TLS/SSL

Tags: Network

암호화

대칭키 암호

암호화키와 복호화키가 동일

공개키 암호(비대칭키 암호)

암호화키와 복호화키가 따로 있음
외부에 공개되는 키가 암호화/복호화 용인지에 따라

공개 키 암호

공개키로 암호화, 비밀키로 복호화
비밀키를 갖고있는 사용자만 해독 가능

→ 아무나 우체통에 편지를 넣을 수 있지만, 꺼내는 사람은 키를 가진 사람 한 명 뿐!

공개 키 서명

비밀키로 암호화, 공개키로 복호화
비밀키를 갖고있는 사용자만 암호화 가능

→ 인장으로 편지봉투를 봉하면 누구나 열어볼수 있지만, 발신자가 무조건 본인임을 증명 가능

참고) 해시

데이터를 특정길이의 다른 데이터로 전환하는 것!
복호화할 수 없으므로 엄밀하게 암호화는 아니다

TLS/SSL

TCP/IP 계층에서 Application Layer에 속함
TLS 1.0 == SSL 3.0, 같은 말이라는 뜻

악수(HandShake) ⇒ 전송(Session) ⇒ 통신종료

이중 HandShake가 너무너무너무너무 중요함

SSL Handshake

데이터 전송(Session) 때 사용할 대칭 키를 서로 안전하게 확보하는 것이 목표!

사진출처) 내가 만듦

⇒ 복잡한 과정이지만 아무튼 요지

서로간의 대칭키를 안전하게 확보하면서 공개키 암호와 대칭키 암호의 각각의 장점만을 취함

SSL이 이렇게 튼튼하다!

No title

200524 Spring Framework

Tags: Java, Server

:Java EE 개발을 위한 오픈소스 애플리케이션 프레임워크

cheese10yun/spring-guide

특징

경량 컨테이너로 자바 객체를 직접 관리
POJO 방식의 프레임워크
IoC Container
DI 지원
AOP
영속성과 관련된 다양한 서비스 지원
높은 확장성

POJO(Plain Old Java Object)

[java] POJO란?

:말 그대로 오래된 방식의 간단한 자바 객체를 의미한다

개발자의 노고를 덜기 위해 EJB라는 개념이 널리 사용되었음
그런데 EJB의 1만큼을 사용하기 위해 99의 짐을 추가로 지고 가야하는/ 배보다 배꼽이 더 큰 상황 발생
POJO 기반의 프레임워크를 사용하자!

현재의 POJO 프로그래밍의 의미 : 객체지향적인 설계원칙을 잘 따르며, 의존성이 적고, 테스트가 용이한 코드

Spring Bean

:Spring이 다루는 POJO

Spring IoC Container에 의해 인스턴스화, 관리, 생성된다

기본적으로 Spring은 모든 bean을 singleton으로 생성하여 관리한다!
- Singleton: 하나의 bean 정의에 대해, 하나의 객체만 존재한다
- Prototype: 하나의 bean 정의에 대해, 다수의 객체가 존재한다

제어의 역전(IoC, Inversion of Control)

: 프로그래머가 작성한 코드가 외부 라이브러리의 코드를 호출하는 경우가 아니라, 외부 라이브러리(프레임워크)의 코드가 프로그래머의 코드를 호출하는 것

프레임워크가 전체 프로그램의 흐름을 결정하게 하자!
어떻게 하면 프레임워크가 내 코드를 호출하게 할 수 있을까?
- 프레임워크의 interface, abstract를 구현한 후 프레임 워크에 넘겨준다
- == 객체를 프레임워크에 주입한다(DI)

의존성 주입(DI, Dependency Injection)

:의존성+주입+의존성 분리

[DI] Dependency Injection 이란?

의존성: A클래스 내부에서 B클래스 변수로 사용한다? → A클래스는 B클래스에 의존한다
주입: 외부에서 객체를 생성해서 넣어주는 것
- 생성자 주입
- Setter 주입
- 인터페이스 주입
의존성 분리: SOLID의 ‘D’에 의거, interface를 이용하여 상위 계층이 하위 계층에 의존하는 상황에서 하위 계층의 구현으로 부터 독립됨
- 제어의 주체를 interface가 갖게된다 ⇒ IoC

의존성 주입의 의의

의존관계의 설정이 컴파일 단계가 아닌 실행 단계에서 이루어져 모듈들 간의 결합도를 낮춤
코드 재사용성을 높임
Mock 등을 이용한 Unit Testing의 편의성을 높여줌

관점지향 프로그래밍(AOP, Aspect-Oriented Programming)

AOP 정리 (3)

ClassA, B, C들에 반복 사용되는 흩어진 관심사(Crosscutting Concerns)

cross-cutting concern
흩어진 관심사를 관점(Aspect)로 모듈화하여, 비즈니스 로직 내에서 재사용하자!
OOP는 상속, 위임으로 공통된 기능을 재사용하지만, 전체 애플리케이션 여기저기서 사용되는 부가기능들을 처리하는 데에는 한계가 있다

Copy of Annotation

Spring 모듈

: Spring Framework는 20여개의 모듈로 구성된다

⇒ 경량성을 강조하던 프레임워크였으나 점차 무거워지기 시작

⇒ 필요한 라이브러리만 추가하면 되나, 어떤 라이브러리를 추가해야 할지 알기 어렵다…!!

⇒ Spring-Boot 탄생

Spring Boot

자주 사용하는 Spring 하위 모듈을 미리 모아놓음

ex) spring-boot-starter-web을 Gradle 설정만 해주면 관련 라이브러리를 받아옴
필요한 설정을 자동으로 수행함

ex) @SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan
Tomcat 내장서버를 포함하고 있다

SpringMVC

MVC pattern, Front-Controller pattern

Model: 실질적인 비즈니스 로직 동작, 뷰 템플릿에 렌더링할 데이터 관리
View: 사용자에게 보여줄 화면 관리
Controller: Model과 View 사이의 상호작용 제어
- Front-Controller: 수많은 요청들이 여러 컨트롤러로 분산되기 이전, 모든 요청을 받아 제어하는 가장 앞에 서 있는 컨트롤러 ⇒ 이것을 이용하는 패턴이 Front-Controller Pattern

SpringMVC

사용자는 인터넷 브라우저를 통해서 웹사이트에 접속한다.
웹서버(Nginx)는 WAS(Tomcat, servlet container)에 Reverse Proxy 처리를 수행하고, DispatcherServlet에서는 요청을 받는다. ⇒ FrontController의 역할!
HandlerMapping의 도움을 받아 어떤 Controller에 위임을 할지 결정한다
HandlerMapping의 도움으로 선택된 Controller에 요청을 보낸다. Controller는 적절한 응답을 모델을 통해 반환한다.
ViewResolver의 도움을 받아, View이름에 매핑된 View를 반환한다.
View는 화면을 템플릿 작업을 통해 반환하고, DispatcherServlet에 의해 사용자에게 반환된다.

SpringMVC의 한계와 Spring WebFlux

Spring WebFlux는 어떻게 적은 리소스로 많은 트래픽을 감당할까?

Tomcat의 default thread size는 200에 불과하다
200개가 넘는 요청이 동시에 들어오면 남는 요청은 queue에서 대기해야 한다

여기 겹쳐있는 스레드 들이 스레드 풀
- 스레드를 만들거나 지우는 일은 cost가 많이 드는 일이다
- 스레드도 결국 객체, 빈 객체를 잔뜩 만들어두고 필요한 요청에 맞게 실행할 메소드, 전달받은 파라미터들을 스레드 메모리 공간에 담는 것이 스레드를 할당하는 것이다
스레드들은 힙에 있는 Controller Singleton에 제각각 요청을 날린다
사실 request들을 처리하는 일에서 가장 많은 시간을 잡아먹는 일은 ‘기다리기’이다
스레드가 Singleton에 요청을 날리고, 적절한 대답을 받기까지 기다리는 동안 요청들은 큐에서 대기중인 것이다!

→ 사실 이런 스레드풀의 개념은 앞단(클라이언트 → 서버) 간의 통신 뿐만 아니라, 뒷단(서버→DB)에도 있다 그것이 DB connection pool(DBCP)

Spring WebFlux는 Event Loop를 통해 다수의 요청을 처리한다
worker thread default size는 서버의 core 개수와 같음
core가 4개라면 thread도 4개뿐
그럼에도 불구하고 더 많은 request를 효율적으로 처리할 수 있다
Spring MVC와 Spring Web Flux의 효율성 차이는 위에서 말한 ‘기다리기’를 줄이는 것이 핵심
Event Loop에는 수많은 ‘일감’들이 돌고있다
Worker thread는 이 ‘일감’들을 메인 로직에 던져주고 알아서 처리된 일감들을 Event Loop로 다시 넣게끔 하거나, 처리된 일감을 응답으로 외부에 송출하는 등의 일을 한다
이 Event Loop는 돌고있는 일감의 개수와 관계없이 계에에에속 돌고 있다 → size가 0인 루프다

No title

200525 TCP/IP

Tags: Network

용어

Protocol

서로 다른 기기/사용자 간 정보를 주고받을 때, 그 정보의 형식, 순서, 에러 검출 방법 등을 결정하는 규칙

ex) HTTP, FTP, TCP
통신규약

Hosts

통신장비

ex) 공유기에 연결된 내 노트북, 핸드폰, 데스크탑 모두 다 Hosts, 공유기도 Hosts

Packet

통신할 때 주고 받는 소포(?) 같은 것

TCP/IP

Transmission Control Protocol/Internet Protocol
가장 널리 쓰이는 프로토콜
4계층으로 이루어짐

Encapsulation

캡슐화 - 각 단계에서 담아야 할 새로운 정보들을 기존 패킷에 추가하고(감싸고) 하위 계층으로 넘겨줌
Decapsulation - 각 단계에서 필요한 정보만 추출하고 패킷에서 해당 정보를 삭제한 다음(벗기고) 상위 계층으로 넘겨줌
각 계층은 다른 계층에서 일어나는 일을 신경쓰지 않아도 되므로 개발에 필요한 로드 감소

Application Layer

웹 브라우저 - 서버 HTTP
파일 전송 FTP
메일 수신/발신 SMTP, IMAP, POP
도메인 주소 해석 DNS
암호화된 원격 Shell 접속 SSH

Transfer Layer

두 호스트 간의 통신 방식을 정의
TCP/UDP가 여기에 속함
TCP : initialization이 필요하나 신뢰성 있는 전송
UDP : 간단하지만 패킷 손상/손실 가능성
TCP와 UDP의 포트는 프로세스에 할당됨

Internet Layer

패킷을 어떻게 보낼 것인지 결정
IPv4, IPv6
라우터는 IP를 기반으로 패킷을 라우팅한다

Network Access Layer

네트워크 상의 기기들을 위한 규약
Ethernet
MAC 주소를 할당

로컬 네트워크에서 일어나는 일

공유기(Router)

우리 집에 인터넷에 연결하고 싶은 Hosts가 3개가 있음
하나의 Public IP를 할당받아 인터넷과 연결
내부의 Hosts들이 인터넷과 연결할 수 있도록 도와주는 놈!

59.6.66.238(Public IP)

WAN(Wide Area Network)과 이어짐

새로운 Host가 공유기와 연결하는 과정

모든 통신장비 고유의 번호인 MAC 주소로 소통!
그리고 이에 관련된 가장 널리 쓰이는 규약이 DHCP(Dynamic Host Configuration Protocol)

이 때, 공유기는 Hosts 하나에 고정된 IP를 할당할수도

→ Dynamic IP address

매번 그때그때 새로운 IP를 할당할수도 있다

→ Static IP address

Hosts가 Client로써 인터넷과 소통하는 과정

private IP와 public IP를 전환해주는 과정이 NAT(network address translation)

Hosts가 공유기에 192.168.0.4:80를 통해 요청을 보냄
공유기가 Public IP를 통해 Server로 요청을 대신 보냄
Server는 Public IP인 59.6.66.238:80으로 응답함
공유기는 이를 192.168.0.4:80으로 전환하여 Hosts에게 응답함

Hosts가 Server가 되려면?

외부에서는 공유기의 public IP만 알고 있으므로, 특정 Hosts를 찾아갈수가 없다!
공유기 차원에서 하나의 포트를 정해서 “이 포트로 들어오는 요청들은 이 Hosts의 이 포트로 연결해주면 되겠다!” 가 필요함

→ 포트포워딩!

IPv4

IPv4 : IP주소를 32비트로 나타냄 → 약 42억개
IPv6 : IP주소를 128비트로 나타냄 → 지구상의 모래알보다 많다

IP 클래스

IP의 앞부분은 네트워크 영역(서브넷, 지역), 뒷부분은 호스트 주소(상세 주소)를 가리킨다!

ex) 카이스트의 네트워크는 143.248.35.xx 다!
네트워크 영역에 몇 비트를 할당할지가 클래스!

클래스 C는 네트워크 하나에 ip를 254개 밖에 못받고…클래스 B는 충분하긴 하지만 16000개만 받으면 동남

CIDR(Classless Inter-Domain Routing)

네트워크 영역으로 사용될 비트의 수를 명시
143.248.35.11/24

→ 143.248.35.11 = 01001111 11110100 00100011 00001011

→ 255.255.255.0 = 11111111 11111111 11111111 00000000 ← 서브넷 마스크!

⇒ 앞에 24비트가 네트워크 영역이라는 뜻!

Javascript 표준

Thu, 17 Dec 2020 12:00:00 GMT

이 글은 윤준성의 개발꼬맹이 시절, 혼자 노션에 공부하며 정리해둔 것 중 괜찮은 것을 추려올린 글입니다. 기술블로그 글 기고 목적으로 작성되지 않아, 가독성이 좋지 않거나 알 수 없는 워딩이 있을 수 있습니다.

https://wormwlrm.github.io/2020/08/12/History-of-JavaScript-Modules-and-Bundlers.html

https://ahnheejong.name/articles/ecmascript-tc39/

ECMAScript

1990년대 중반, Netscape Navigator가 브라우저에 동적인 부분을 더하기 위해 개발
1996년, Microsoft가 상표권 이슈를 피하기 위해 JScript라는 자바스크립트의 방언을 개발
이들이 찾아간 곳은 ECMA 인터내셔널(Ecma International)
- 정보와 통신 시스템을 위한 국제적 표준화 기구
- ASCII 코드, CD-ROM 볼륨, JSON 등 온갖 표준을 책임지고 있다
이들간의 합의 끝에 ECMA-262(ECMAScript 언어 표준)이라는 표준이 탄생하고, 이를 ECMA 인터네셔널의 산하 위원회, TC39(Technical Committee 39)가 관리하게 된다
2020년 6월까지 ECMA-262의 개정판이 11판 까지 나왔다
- 개정 연도에 따라 ECMAScript 2015 혹은 ES2015로 불리는 것.
- 또한, 몇번째 개정판인지에 따라 ES6라고 불리기도 한다.
- 즉, 2015년에 나온 6번째 개정판이 ES6 == ES2015

즉, ECMAScript가 사양이라면, Javascript는 그 구현체.

Javascript 모듈화

원래 자바스크립트는 모듈화가 없었다

<html>
  <script src="/src/foo.js"></script>
  <script src="/src/bar.js"></script>
  <script src="/src/baz.js"></script>
  <script src="/src/qux.js"></script>
  <script src="/src/quux.js"></script>
</html>

그래서 여러 js 파일들을 일일이