전체 글

단계별로 성장하자!
· 🛳 DevOps
FEP (Front End Processor) 보통 금융 관련으로, 전용선을 통해 대외적 거래 또는 B2B 연계에 사용되는 통신 방식으로, Client와 BE Server 사이에서 통신 제어 및 처리를 위한 시스템을 의미한다. 암호화되어 FEP 서버로 전달된 외부 전문을 내부 전문으로 변환하여 내부 서버에서 사용할 수 있게 해주는 역할도 한다. EX) 금결원에 고객의 계좌를 조회 or 증권사에서 거래소의 주문 시스템에 접근 FEP를 통해 외부 전문이 내부 전문으로 변환되면 코어 시스템이나 배치 시스템 같은 곳에 전달되어 활용된다고 생각하면 된다. 위에 작성했듯이 개인이 적립받은 포인트를 현금으로 전환하고 싶다고 했을 때, FEP와 금결원이 연결된 전용선을 통해 계좌를 조회할 수 있다.
· 🌐 Backend
Thread Process의 작업은 Thread 단위로 나눌 수 있다. 그리고 CPU Core가 Thread 단위로 작업을 처리하게 된다. 결론적으로 Thread는 CPU Core의 실행 단위이다. Thread를 사용함으로서 하나의 Process에서 두 가지 이상의 작업을 동시에 실행 가능하게 된다. Thread를 단순하게 사용할 때 문제점 새로운 요청이 들어올 때마다 새로운 Thread를 생성한다고 가정하고 문제점을 생각해보자. 생성 비용이 큰 Thread Thread는 생성 비용이 크다. 따라서 해당 방식으로는 요청에 대한 응답시간이 늘어날 수 밖에 없다. 아래 그림을 보면서 더 자세하게 알아보자. Java는 One-to-One Threading-Model로 Thread를 생성한다. User Thre..
· 🌐 Backend
XSS(Cross-Site Scripting) 공격자가 웹 상에서 SQL Injection과 같은 방법으로 공격하려는 사이트에 악의적인 스크립트를 주입하는 공격이다. 주로, 다른 웹 사이트와 정보를 교환하는 방식으로 동작하기 때문에 Cross Site Scripting이라고 명칭한다. 해당 취약점은 웹 애플리케이션이 사용자의 입력값을 제대로 검사하지 않고 사용할 경우 나타날 수 있으며, 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 강제로 실행하게 된다. 일반적으로 쿠키, 세션, 토큰을 탈취하거나 다른 민감한 정보를 탈취하거나 클라이언트 코드를 재작성하여 해킹하기도 한다. 악의적인 컨텐츠로는 자바스크립트를 사용하여 공격하는 경우가 많다. 1) 쿠키나 세션 정보 탈취 2) 접속자를 자신이 의도한 ..
인증의 필요성 HTTP 통신은 요청과 응답이 종료되면 연결을 끊는 Connectionless 특성과 연결이 끊어지면 어떠한 상태도 유지하지 않는 Stateless한 처리 방식이다. 따라서, 로그인을 유지하기 위해서 쿠키, 세션, 토큰을 사용한다. Connectionless 프로토콜 클라이언트가 서버에 요청하고 응답을 받으면 연결을 끊는 처리 방식 Stateless 프로토콜 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다. 1. 쿠키 🍪 쿠키는 Key-Value 형식의 문자열로 사용자에게 맡겨도 되는 공개 가능한 정보를 사용자 브라우저에 저장시킨다. 쿠키 동작 방식 서버는 클라이언트의 로그인 요청에 대해 응답할 때, 클라이언트를 식별하는 작은 정보를 Response Header의 set-cooki..
MySQL의 격리 수준 트랜잭션의 격리 수준(Isolation Level)이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 격리 수준은 크게 4가지로 나뉜다. Read UNCOMMITTED Read COMMITTED REPEATABLE READ SERIALIZABLE 1번부터 4번까지 뒤로 갈수록 각 트랜잭션 간의 데이터 격리(고립) 정도가 높아지며, 동시 처리 성능도 일반적으로 떨어질 수 있다. 격리 수준이 높아질수록 MySQL 서버의 처리 성능이 많이 떨어질 것으로 생각할 수 있지만, 사실 SERIALIZABLE 수준이 아니라면 크게 성능 저하가 발생하지는 않으니 안심해도 된다. 하나 특별한 부분이 있다..
JOIN이 어떻게 인덱스를 사용하는지에 대해 쿼리 패턴별로 알아보고 주의사항에 대해서 알아보고자 한다. 1. JOIN의 순서와 인덱스 인덱스 레인지 스캔은 인덱스를 탐색(Seek)하는 단계와 인덱스를 스캔(Scan)하는 과정으로 구분할 수 있다. 일반적으로 인덱스를 이용해서 쿼리하는 작업에서는 가져오는 레코드의 건수가 소량이기 때문에 인덱스 스캔 작업은 부하가 작지만 특정 인덱스 키를 찾는 인덱스 탐색 작업은 상대적으로 부하가 높다. 조인 작업에서 드라이빙 테이블을 읽을 때는 인덱스 탐색 작업을 단 한 번만 수행하고, 그 이후부터는 스캔만 실행하면 된다. 하지만 드리븐 테이블에서는 인덱스 탐색 작업과 스캔 작업을 드라이빙 테이블에서 읽은 레코드 건수만큼 반복한다. 드라이빙 테이블과 드리븐 테이블이 1:1..
DevPoong
Poong