1교시
JSP를 통해 웹브라우져 입력값을 DB로 전달하는 걸 해설하셨다.
구체적인 문법보다 맥락을 이해해야한다. (어쩌피 스프링으로 할거다.)
웹브라우저가 HTTP로 요청한 것을
톰 캣이라는 웹 어플리케이션 서버가 자바 프로그램을 실행해주고
자바 프로그램은 JDBC를 통해 DB서버에 접속한다.
보안
- 네트워크보안 (패킷, 방화벽)
- 시스템 보안 (리눅스 설정, 백신 프로그램)
- 소프트웨어 보안 (취약점 10top 공격 (owasp) 대비)
2교시
SQL injection 막는 법 2가지 (로직 또는 매서드나 객체 바꾸기)
스프링이 알아서 해준다. 하지만 해야한다는 건 알고 가자.
로직 원리 : 입력값으로 sql문을 실행하지 않으면 된다.
입력값 검증 : 사용자가 입력한 값으로 sql를 실행하는 것을 지양하자.
사용자를 의심하라. 꼭 검증해야한다.
프로그램 문법에 사용되는 특수문자들을 주로 막는다.
특히 <, > 이거를 <, > 으로 repalce 해주자.
자바 스크립트를 이용해서 다른 사람 컴퓨터에서 실행되는 코드를 넣는 걸 막는 것이다. (XSS 공격)
객체바꾸기: prepareStatement를 이용해보자 (★★★)
3교시
잘못된 접근을 통제
권한 설정
인증(Authentication)과 인가(Authorization)
로그인 기능 세션과 토큰 방식
스프링은 기본으로 세션 방식을 지원한다.
이제 성능적인 부분에 대해서 수업한다.
웹 어플리케이션 서버에서 GET요청을 받을 때마다 DB에 연결하면
성능에 좋지 않다.
따라서 한 번만 연결해두고 유지해야한다.
그래서 Connection Pool를 이용한다. 우리는 hikiricp라는 걸 이용할 거다.
4교시
hikaricp 설정
라이브러리 가져오기
https://github.com/brettwooldridge/HikariCP
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>4.0.3</version>
</dependency>InteliJ에 build.gradle에 추가하면 자동으로 Gradle에 맞춰서 바뀐다.
main/resource/hikari.properties 작성
dataSourceClassName=org.postgresql.ds.PGSimpleDataSource
dataSource.user=test
dataSource.password=test
dataSource.databaseName=mydb
dataSource.portNumber=5432
dataSource.serverName=localhost위에 내용을 자신에게 맞게 수정하자. 그대로 쓰면 당연히 안된다.
db를 연결하고 싶은 곳에 객체를 만든다.
HikariConfig config=new HikariConfig("/hikari.properties");
HikariDataSource dataSource = new HikariDataSource(config);5교시
hicaricp를 써보면
연결이 10개씩 열리고, 닫히지도 않고, 요청 올 때마다 계속 생긴다.
이유는 hikaricp에 있는 close는 연결을 끊는 것이 아니라 connection pool로 반납하는 것을 뜻한다. 따라서 객체를 생성할 때마다 연결이 계속 생긴다.
이러면 안 쓰느니 못하다.
따라서 싱글톤으로 따로 구현해줘야한다.
6교시
성능 비교 방법
아파치 JMeter로 부하테스트를 해보자
JMeter 다운로드
https://dlcdn.apache.org//jmeter/binaries/apache-jmeter-5.6.2.zip
1) 부하테스트란?
우리가 만든 웹 서비스가 목표 응답시간 기준으로 얼마만큼의 동시 접속자 수를 견딜수 있는가를 테스트하기 위한 목적
동시접속자 수를 TPS로 환산하여 자원적인 관점으로 사용자 대비 용량 산정
즉, 사용자의 추이에 따라 적절한 자원을 배분하는 것, 더 나아가 병목구간을 찾아 제거하는 것
출시 전 대부분의 어플리케이션이 성능 저하를 일으키는 병목구간을 가지고 있다.
출시 전에 얼마나 이 부분을 많이 해결하느냐가 매우 중요
즉 부하를 발생시키는 것도 중요하지만, 병목구간이 무엇인지 찾아내는 것이 필요
APM (Application Performance Monitoring)과 인프라 모니터링(Infrastructure Monitoring)의 지표들을 읽어내고,
병목 구간의 문제가 코드의 잘못인지, 자원의 부족인지, 세팅값의 잘못인지 찾아내어 개발자 레벨로 설명을 해주는 능력이 필요 2) 부하테스트의 종류
(1) 부하 테스트 (Load Test)
특정한 부하를 제한된 시간을 두어서 웹 어플리케이션에 이상이 없는지 파악하는 테스트
(2) 지속성 테스트 (Endurance Test)
Load Test와 유사하나 오랜 기간 부하를 줘서 하는 테스트
(3) 스트레스 테스트 (Stress Test)
부하의 임계점을 찾기 위해 점진적으로 부하를 올리면서 진행하는 테스트
(4) 최고 부하 테스트 (Peak Test)
일순간 감당할 수 없을 만큼 부하를 주고, 웹 어플리케이션이 죽지 않고 제대로 동작하고 회복하는지 보는 테스트
수강신청이나 이벤트 등 대규모 상황을 대비하기 위해 진행 3) 부하테스트 프로그램의 종류
JMeter, Load Runner, nGrinder, Gatling
4) APM의 종류
부하를 발생시킨 후, 웹 어플리케이션의 주요 병목지점을 찾아내는 것이 중요
웹 어플리케이션의 병목을 찾아주는 MRI같은 장치가 APM
APM의 가장 대표적인 솔루션은 제니퍼소프트
네이버에서 개발한 pinpoint나 jaeger와 같은 도구도 있음 5) jmeter 사용법
Test Plan 우클릭 -> Add -> Thread(Users) -> Thread Group
Name : Thread Group의 이름 입력
Action to be taken after a sampler error : 테스트 수행 중 에러가 발생될 때의 상황 설정
Thread Properties
Number of Threads : 이 Thread Group에 생성될 Thread의 개수를 지정
Ramp-up Period : 한 Thread가 시작한 후 다음 Thread가 시작될 때까지의 대기 시간을 지정
Loop Count : 각 Thread가 Thread Group에 속한 작업의 반복 횟수를 지정
Scheduler : Thread Group의 시작 및 종료 스케줄을 설정할 것인지 체크
Thread Group 우클릭 -> Add -> Sampler -> Http Request
Name : 요청의 이름 입력
Server Name or IP : 서버에 접속할 수 있는 주소를 입력, 도메인 주소 or IP주소
Port Number : 서버에 접속할 때 사용할 서버의 포트번호 입력
Protocol : 사용할 프로토콜 입력
Method : 메소드 입력
Content encoding : 인코딩 방식 입력
Path : 접속할 URL 입력
Parameters : 서버에 전송할 데이터 입력
Thread Group 우클릭 -> Add -> Listener -> View Results in Table
Thread Group 우클릭 -> Add -> Listener -> View Results Tree
Thread Group 우클릭 -> Add -> Listener -> Summary Report
스트레스 테스트 수행
Thread Group에서 Thread 수를 100에서부터 올려가면서 테스트
언제 실패하는 사용자가 나오는지 테스트- 히카리 안 썼을 때.
- 히카리 썼는데 싱글톤 적용 안했을 때.
- 싱글톤까지 적용했을 때.
