Search

Yimin An’s Blog

“그래봤자 개발, 그래도 개발”
Search
Development Posts

Redirect

예시

1.
Client → Server 최초 요청
2.
Client ← Server 새로운 URL 응답
3.
Client → Server 새로운 URL로 재요청 (새로운 요청정보로 요청)
4.
Client ← Server 응답

사용하는 경우

최초 요청 정보는 Server에 반영되지 않습니다. URL 정보는 최초 요청이후에 전달된 New URL로 변경되어 요청해야합니다.
시스템(Session, DB)에 변화가 생기는 요청(로그인, 회원가입, 글쓰기)의 경우 Redirect 방식이 적절 사용자가 보낸 정보를 이용하여 글쓰기 기능을 사용하면, Forward 경우 요청 정보에 대한 객체가 그대로 있기에 글이 중복 등록될 수 있습니다. 하지만 Redirect 경우 처음 글을 작성할 때 보냈던 요청정보는 존재하지 않고 새롭게 응답된 URL로 다시 요청해야합니다. 그렇기에 글쓰기가 여러번 수행되지 않습니다.

Forward

예시

1.
Client → Server 최초 요청
2.
Server → Server 새로운 URL로 재요청 (최초 요청의 요청정보를 그대로 재활용)
Redirect와 Forward의 차이점
2023/01/16 05:59
network

“A syntax extension to JavaScript.”

= “JavaScript” + “XML/HTML”

JSX 장점

1.
코드의 간결함
2.
코드의 가독성 향상
3.
Injection Attack, XSS 방어로 보안성 향상

JSX 기능

•
JSX 는 내부적으로 XML/HTML 코드를 JS 코드로 변환합니다.
•
ReactDOM 은 랜더링하기 전에 임베딩된 값을 모두 문자열로 변환합니다. 그렇기 때문에 명시적으로 선언되지 않은 값은 괄호 사이에 들어가지 않습니다. XSS 를 방어할 수 있습니다.
•
React 에서 JSX 를 사용하는 것은 필수는 아닙니다. 하지만 JSX 사용하는게 절대적으로 장점이 많습니다.
•
JSX 코드를 JS 코드로 변환은 React.createElement() 함수가 합니다.

JSX 렌더링 예시

JSX 역할에 대해서
2022/11/14 09:29
react
jsx

상태관리 라이브러리를 사용하는 이유

•
React 는 부모→자식으로 단방향 데이터 흐름을 가집니다.
•
자식에서 부모의 상태를 바꾸려면 props 를 넘겨줘야하는데, “props drilling”을 해야하고, 그 과정에서 “props depth”가 증가해서 불필요한 리렌더링이 일어나게 되기에 비효율적입니다.
•
코드에서 데이터의 상태를 쉽게 관리하기 위해서 사용하게 됩니다.

상태관리 라이브러리들

Context API

•
React 가 자체적으로 가지고 있는 라이브러리
•
Context API 에서 제공하는 Provider 로 감싸진 부분은 업데이트가 되지 않은 state에서도 리렌더링 됩니다.
•
정적 데이터 위주로 처리하거나 업데이트가 빈번하지 않을 때 적합합니다.
•
불필요한 리렌더링을 보완하기 위해 Recoil 이 나왔습니다.

Redux

•
최초 상태관리 라이브러리, 환경구성에 많은 코드가 필요합니다.
•
보일러플레이트 코드로 action, reducer, selector, store를 세팅합니다.
React 상태관리 라이브러리 둘러보기
2022/11/13 10:02
react
library
Virtual DOM 을 이해하기 위해서는 DOM(Document Object Model) 부터 이해해야합니다.

DOM(“Document Object Model”) 이란?

•
하나의 웹사이트에 대한 정보를 모두 담고 있는 큰 모델
•
DOM은 브라우저에서 다룰 HTML 문서를 파싱하여 "문서의 구성요소들을 객체로 구조화하여 나타낸 것"입니다.
•
DOM은 HTML Elements, Attributes, CSS styles, Events, Methods 등을 제어할 수 있는 표준 인터페이스를 제공합니다.
•
"웹 페이지 구성 요소를 구조화한 객체고 이 객체를 이용해서 웹 페이지 구성요소를 제어할 수 있다"

Virtual DOM 이란?

1. Virtual DOM이란?

→ "DOM을 추상화한 가상의 객체"
•
Virtual DOM 은 웹페이지와 실제 DOM 사이에서 중간 매개체 역할을 합니다.
•
React 에서는 Virtual DOM 을 활용해서 직접 DOM 을 수정하지 않고, 업데이트 해야할 최소 부분만 찾아서 업데이트하는데 활용합니다.

2. 왜 Virtual DOM 이 나오게 되었을까?

1.
문제: DOM 조작에 의한 비효율적인 렌더링
2.
문제: SPA(Single Page Application) 구현으로 인해 DOM 복잡도 증가에 따른 최적화 및 유지 보수가 더 어려워짐
Virtual DOM 에 대한 이해
2022/11/12 10:20
dom
프레임워크는 미리 만들어둔 반제품이나, 확장해서 사용할 수 있는 추상 라이브러리의 집합이 아니다. 프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다. 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 프레임워크에는 분명한 [제어의 역전] 개념이 적용되어 있어야 한다. 애플리케이션 코드는 프레임워크가 짜 놓은 틀에서 수동적으로 동작해야 한다. From 토비의 스프링 3.1 中

프레임워크

•
원하는 기능 구현에 집중하여 개발할 수 있도록 일정한 형태와 필요한 기능을 갖추고 있는 골격, 뼈대를 의미합니다.
•
애플리케이션 개발 시 필요한 코드, 구현패턴, 자료구조, DB 연동과 같은 기능을 위해 뼈대(구조)를 제공하고 이 뼈대 위에서 코드를 작성하여 애플리케이션을 개발합니다.
•
앱/서버 등의 구동, 메모리 관리, 이벤트 루프 등의 공통된 부분은 프레임워크가 관리하며, 사용자는 프레임워크가 정해준 방식대로 클래스, 메서드, … 를 구현합니다.

예시

•
Java 서버 개발에 사용되는 Spring
•
Python 서버 개발에 사용되는 Django, Flask
•
안드로이드 앱 개발에 사용되는 Android
•
아이폰 앱 개발에 사용되는 Cocoa Touch
•
웹 개발에 사용되는 Angular, Vue.js 등
•
자바 기반의 JSP를 위한 프레임 워크 Struts
•
루비로 작성된 MVC패턴을 이용하는 Ruby on Rails

라이브러리

•
소프트웨어를 개발할 때 컴퓨터 프로그램이 사용하는 비휘발성 리소스를 모아둔 것입니다.
프레임워크와 라이브러리(Framework and Library) 차이
2022/11/12 07:40
framework
library
AWS RDS 인스턴스를 생성하면, DB의 기본 Character Set이 "latin-1"입니다.
그렇기 때문에 한글 사용하면 글자가 "???"처럼 깨지게 됩니다.
파라미터 그룹을 통해 인코딩 값을 UTF-8로 변경하여 한글깨짐을 해결할 수 있습니다.

해결방법

1.
RDS Dashboard 이동
2.
왼쪽 사이드바에서 "Parameter groups" 클릭
3.
"Create parameter group" 클릭
4.
원하는 "Group name", "Description"을 입력
5.
"Create" 클릭
6.
만들어진 parameter group 클릭
7.
"Filter parameters"에 "character_set"으로 검색
8.
수정하기 위해서 "Edit parameters" 클릭
9.
검색에서 나온 모든 파라미터들을 "utf8"로 변경
10.
"Save changes" 클릭
11.
왼쪽 사이드바에서 "Databases"를 클릭
RDS MySQL 한글이 깨질 때는 어떻게 할까?
2022/02/27 17:47
aws
rds
mysql

기존에는 MPA(Multi Page Application)로 웹 애플리케이션을 구현했습니다.

그런데 페이지가 바뀌면, 페이지마다 새로운 HTML 파일이 필요하게 됩니다.
페이지별로 HTML을 만들다보면 수십개 수백개가 되기도 합니다.

HTML이 관리하기 힘든 문제를 해결하기 위해서 SPA 가 나오게 됩니다.

SPA 는 React 와 같은 라이브러리에서 구현에 활용하고 있고,
HTML 파일 하나가 페이지가 되고, 파일 안에 <body> 태그에는 아무 내용도 없습니다.
필요시, <body> 태그 안에 동적으로 콘텐츠를 가져와서 페이지를 완성하는 방식으로 SPA 를 구현합니다.
왜 SPA(Single Page Application)를 구현할까?
2022/11/11 15:51
spa
mpa

HTML은 “Hyper Text Markup Language” 의 약자입니다.

•
Markup 은 문서, 데이터를 처리하기 위해서 문서에 추가되는 정보입니다.
•
HTML 은 Markup Language 의 한 종류입니다.
•
HTML 은 웹사이트의 뼈대를 구상하기 위해서 사용하는 Markup Language 입니다.
•
HTML은 Tag 를 사용하여 웹사이트의 구조를 만들고, 웹사이트에 들어갈 내용을 채웁니다.
•
Tag 는 <html></html> 과 같은 형태를 이야기합니다.

HTML 의 기본적인 Tage 구성

<head>…</head>

•
웹사이트가 어떤 웹사이트인지 알 수 있는 속성 (”title”, “description” 등) 을 선언하는 태그

<body>…</body>

•
웹브라우저를 통해서 우리가 보는 웹사이트 내용들을 선언하는 태그
HTML 이란?
2022/11/11 12:29
html

React Developer Tools

•
React 개발시 디버깅에 필요한 플러그인입니다.
•
Chrome 에서 제공하는 가장 기본적인 React 플러그인입니다.
•
개발자도구(F12)에서 Tab “Components”, “Profiler” 탭을 활용할 수 있습니다.

Wappalyzer

•
Web page 방문 시, 사용된 모든 Tech Stack 을 보여주는 플러그인입니다.
•
Chrome 에서 제공하는 부분 유료 React 플러그인입니다.
React 개발에 도움주는 Plug-In
2022/10/25 03:30
react
plugin

Prerequisite

Need installation

Check installation

Create new React application

Run created React application

Open created React application project in VSCode

VSCode 로 React 시작하기
2022/10/10 09:20
react
vscode

매직 리터럴(매직 넘버)란?

매직 리터럴(매직 넘버) : 프로그래밍에서 비즈니스적 의미를 가진 숫자나 문자를 그대로 표현한 것. (단, 의미 없는 선언 또는 함수 하나에만 쓰이고 그 함수가 맥락 정보를 충분히 제공한다면 상수로 바꿔 사용하는 것에 이득이 없습니다.)

매직 리터럴 예시

매직 리터럴의 문제점

•
매직 리터럴은 단순히 코드만 보았을 때, 작성한 사람이 아니라면 그 의미를 파악하기 힘듭니다.
•
코드의 가독성이 낮아져 비용이 증가하고, 결국에는 유지보수성을 저하시키는 원인이 됩니다.

매직 리터럴의 리팩터링

•
매직 리터럴은 다음과 같은 방식으로 리팩터링합니다.
•
원하는 방식을 선택해서 적용해도 좋고, 중복으로 선택 적용해도 좋습니다.

1. 상수 선언 방식

: 매직 리터럴은 의미를 알기 쉬운 이름으로 상수로 선언하여 사용합니다.

2. 메서드 추출 방식

: 의미가 불분명한 단위의 로직을 의미있는 네이밍 메서드로 고립시키는 방식을 적용합니다.
매직 리터럴(매직 넘버)을 다루는 법
2022/04/20 13:31
java

목적

Ubuntu 에서 리부팅을 진행하여도, 시스템이 Bootstrap 으로 해당하는 스크립트를 자동 실행할 수 있게 해야하는 경우 구현합니다.

구현 과정

1.
스크립트는 /etc/init.d 에 위치해야합니다.
2.
스크립트는 실행 단계 디렉터리에 심볼릭 링크로 걸어주어야 합니다.
3.
심볼릭 링크는 update-rc.d 가 수행합니다.

구현

Ubuntu 스크립트 자동실행
2022/09/02 12:36
ubuntu
CLI에 대해서 익숙하시지 않은 분들은 보통 인터넷에서 인코딩 디코딩 웹툴을 이용하게 됩니다.
그런데 인코딩이나 디코딩 해야하는 파일이 웹에 올리면 안되는 경우에, 결국 로컬에서 인코딩을 진행해야합니다.
그래서 로컬 CLI로 Base64 인코딩, 디코딩을 하는 방법에 대해서 설명하겠습니다.
Example)
•
인코딩: A.jpeg파일 => output.b64파일
•
디코딩: output.b64파일 => A.jpeg파일

Linux 환경에서

Windows 환경에서

MacOS 환경에서

로컬에서 Base64 인코딩, 디코딩 하기 (MacOS, Linux, Windows)
2022/02/27 15:53
base64
키(Key)란? : 데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 구분할 수 있는 기준이 되는 속성(애트리뷰트)

키(Key)의 종류

예시 릴레이션

후보키(Candidate Key)

•
후보키는 릴레이션의 속성 중에서 튜플을 유일하게 식별할 수 있는 속성의 부분 집합이다.
•
기본키로 사용할 수 있는 속성들을 말한다.
•
하나의 릴레이션에서는 중복된 튜플들이 있을 수 없다.
•
모든 릴레이션에는 반드시 하나 이상의 후보키가 존재한다.
•
후보키는 릴레이션에 있는 모든 튜플에 대해서 유일성과 최소성을 만족시켜야 한다.

Example)

<학생> 릴레이션에서 학번이나 주민등록번호는 유일성과 최소성을 만족하므로 후보키가 된다.
<수강> 릴레이션에서는 (학번, 과목명)으로 조합해야 유일성과 최소성을 만족하기 때문에 (학번, 과목명)으로 조합된 것이 후보키가 된다.
※ (학번, 과목명)과 같이 2개 이상의 필드를 조합하여 만든 키를 복합키(Comoisite Key)라고 한다.
유일성(Unique) : 하나의 키값으로 하나의 튜플만을 유일하게 식별할 수 있어야한다. 최소성(Minimality) : 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성만으로 구성되어 있어야한다.
RDBMS Key 종류 (기본키, 후보키, 대체키, 슈퍼키, 외래키)
2022/04/26 04:44
rdbms
SQL (Structured Query Language)

DDL(Data Definition Language) - 데이터 정의 언어

•
데이터베이스의 스키마(schema)를 정의하고 변경하는데 사용
•
DDL 명령어를 입력하면, 데이터베이스의 테이블에 명령어에 해당하는 작업이 즉시(AUTO COMMIT) 반영됩니다.

DML(Data Manipulation Language) - 데이터 조작 언어

•
데이터베이스의 데이터를 관리하는 데 사용됩니다.
•
DML 명령은 자동으로 커밋되지 않습니다. 데이터베이스에 영구적이지 않아 롤백할 수 있습니다.
•
DML(INSERT, UPDATE, DELETE, SELECT) 명령어의 경우, 조작하려는 테이블을 메모리 버퍼에 올려놓고 작업을 하기 때문에 실시간으로 테이블에 영향을 미치는 것은 아닙니다.
•
버퍼에서 처리한 DML 명령어가 실제 테이블에 반영되기 위해서는 COMMIT 명령어를 입력하여 TRANSACTION을 종료해야 합니다.

DCL(Data Control Language) - 데이터 제어 언어

•
데이터베이스에 권한 부여
•
DCL 명령어를 입력하면 명령어에 해당하는 작업이 즉시(AUTO COMMIT)되어 데이터베이스 테이블에 반영됩니다.
SQL 구성 (DDL, DML, DCL, TCL)
2022/02/28 17:12
sql

개요

AWS RDS Proxy은 "DB Connection Pool Management" 또는 "Automatic Failover를 위한 Proxy" 기능을 제공합니다.
결국, AWS RDS Proxy를 사용하는 이유는 HA(High Availability)를 구현하기 위함입니다.
Solution을 사용하기 앞서서, HA(High Availability)를 위한 Multi-AZ(Multi Availability Zone) 개념을 시작으로 이야기를 풀어가보겠습니다.
RDS는 HA(High Availability)를 위해서 Multi-AZ(Multi Availability Zone)를 권장합니다. Downtime 없는 DB Instance를 사용하기 위함입니다.
Multi-AZ를 통한 DB 구성과 Application에서 활용하는 방식은 다음과 같습니다.
Multi-AZ 구성과 Application에서 활용
여기서 AZ(Availability Zone)의 개념은 물리적으로 구분된 IDC라고 생각하시면 됩니다.
예를 들면, Zone A는 Seoul, Zone B는 Daegu, Zone C는 Busan과 같이 보통 지역으로 분리해놓습니다.
Multi-AZ를 구성하고, 어느 하나의 AZ 또는 DB Instance에 장애가 발생하였을 때 장점은 다음과 같습니다.
•
Enhanced durability: 장애가 발생한 Workload를 안전하게 보장해서 DB에 반영해줍니다.
•
Increased availability: Aurora는 1분 이내, MariaDB는 30초 이내, 다른 DB Engine은 1~2분 이내로 Automatic failover를 통해서 정상화시킵니다. 그리고 maintenance 또는 backup이 발생했을 때도 DB에 반영할 Workload를 보장해줍니다.
•
Protection of your database performance: MySQL, MariaDB, Oracle, PostgreSQL Engine에서 Backup이 발생하였을 때, I/O workload를 지속적으로 보장해줍니다. Aurora를 사용하고 있는 경우에도 마찬가지로 I/O workload를 보장하고, 장애가 발생하여도 Automatic Failover과 Read Replica를 통해서 Performance를 유지시켜줍니다.
AWS RDS Proxy를 활용한 Aurora Failover 구현하기
2022/02/25 13:53
aws
rds
JPA를 사용하면서 더티 체킹과 트랜잭션의 관계에 대해서 알고 있지 않으면,
비즈니스 로직에서 다루는 엔티티 데이터가 꼬이는 경우가 발생합니다.
데이터가 꼬이는 경우를 방지하려면,
더티 체킹(Dirty Checking)이 어떤 상황에 사용이 되는지 알고 있어야 합니다.
여기서는 더티 체킹이 어떤 상황에서 발생하는지 확인해보려고 합니다.

더티 체킹(Dirty Checking)이란?

JPA는 엔티티 매니저가 엔티티를 저장, 조회, 수정, 삭제를 합니다.
그런데 엔티티 매니저의 메서드를 찾아보면, 저장(persist), 조회(find), 수정(?), 삭제(delete)로 수정에 해당하는 메서드가 없습니다.
대신에 수정(?)에 해당하는 더티 체킹(Dirty Checking)을 지원합니다.
더티 체킹은 Transaction 안에서 엔티티의 변경이 일어나면, 변경 내용을 자동으로 데이터베이스에 반영하는 JPA 특징입니다.
데이터베이스에 변경 데이터를 저장하는 시점
1.
Transaction commit 시점
2.
EntityManager flush 시점
JPA Dirty Checking 이란?
2022/02/27 15:26
jpa
보통 레거시 서비스를 마이그레이션 하면서 세 가지가 가장 큰 숙제라고 봅니다.
1.
DB 마이그레이션 : Legacy DB ⇒ New DB
2.
DB를 사용하는 애플리케이션 마이그레이션 : Legacy Application ⇒ New Application
3.
미디어 저장소 마이그레이션 : Legacy Media(jpg, mp4, ...) Storage ⇒ New Media Storage
여기서는 3. 애플리케이션용 미디어 마이그레이션을 다루겠습니다.
미디어 저장소로 AWS S3를 사용하는 경우 마이그레이션입니다.

AWS 새로운 계정의 S3 Bucket으로 Object를 옮기는 과정

마이그레이션에 준비해야하는 것

1.
AWS 계정 2개
•
Source Account :기존 S3 Bucket Objects가 있는 계정
•
Destination Account : 기존 S3 Bucket Objects가 옮겨질 계정
AWS S3 Bucket 마이그레이션 하기 (서로 다른 계정 간)

Git Flow 사용

보통은 공통으로 사용하는 master(main), development 를 메인 브랜치로 두고, 코드를 형상관리합니다.
메인 브랜치에서 새로운 브랜치를 만들어서 작업하고, 메인 브랜치에 코드를 merge하는 방식으로 진행합니다.
이 과정에서 코드를 반영하는 전략을 다르게 가져갈 필요가 있습니다.
이 이유에서 Merge 방식을 다르게 사용하게 됩니다.

Git Merge 전략

1.
Merge Commit
2.
Rebase and Merge
3.
Squash and Merge

1. Merge Commit

“작업 Commit들을 시간 순서대로 대상 브랜치에 Merge하고 Merge Commit을 남기는 방식”
Git Merge란? 기준이 되는 대상 checkout branch에 다른 branch의 코드를 병합하는 것 주로 사용하는 Git Merge 방식 1. Fast-Forward-Merge 2. 3-Way-Merge ...

Merge Commit 처리 과정

1.
“branch develop”를 “branch master”로 Merge한다.
Git Merge 전략 정리
2022/02/22 07:34
git

개요

쿠키와 세션은 개발자 말고도 인터넷 사용자라면 누구나 많이 들어본 단어입니다.
하지만 개념에 대해서는 많은 사람들이 헷갈려 하기에 쉽고 간단하게 정리해보려고 합니다.
일단 쿠키를 발급받고 사용하는 과정에 대해서 그림으로 보여드리고,
쿠키와 세션에 대한 설명을 하도록 하겠습니다.

목차

1.
HTTP의 특징과 쿠키와 세션을 사용하는 이유
2.
쿠키 ( Cookie )
3.
세션 ( Session )
4.
쿠키와 세션의 차이
5.
세션을 사용하면 좋은데 왜 쿠키를 사용할까?
6.
쿠키/세션은 캐시와 엄연히 다르다!

1. HTTP의 특징과 쿠키와 세션을 사용하는 이유

쿠키를 발급받고 사용하는 과정
쿠키와 세션 개념
2022/02/13 16:36
http
cookie
session

목적

사용하던 EBS Volume 의 크기가 부족해진 경우,
시스템을 그대로 유지하면서,
EBS의 디스크의 사이즈만 증설하는 방법에 대해서 이야기합니다.

구현

1. AWS Dashboard에서 EBS Volume 사이즈 증설

OS 설치시, 파티션으로 나누어서 활용합니다.
HDD or SSD 가 100GB 라고해서, 파티션 C Drive 가 반드시 100GB 가 되지 않습니다.
여기서 우리는 EBS Volume 이라는 전체 드라이브를 증설합니다.
증설된 전체 드라이브에서 원하는 용량만큼 더 추가적으로 파티셔닝을 하면 됩니다.
즉, 전체 드라이브가 커졌다고 파티션된 EBS Volume이 자동으로 늘어나는게 아닙니다.

2. EBS Volume을 사용하는 EC2 Instance System 접속

원하는 방식으로 시스템에 접속합니다.
AWS EBS Volume 확장 방법
2022/09/03 08:07
aws
ebs

Template Engine 이란?

: 템플릿 양식에 필요한 데이터를 결합한 html 문서를 만들어 반환해주는 SW
•
프레젠테이션 계층과 비즈니스 로직을 분리하기 위한 수단
•
프레젠테이션 계층에서 로직을 쉽게 표현하고, 개발 유연성을 향상, 유지보수 향상시킨다.

Template Engine 종류

•
JSP(Java Server pages) - SSR
•
FreeMarker, Groovy, Thymeleaf, Mustache ... - CSR

Server Template Engine (SSR: Server Side Rendering)

•
서버에서 DB 혹은 API에서 가져온 데이터를 미리 정의된 Templete에 넣고 HTML을 만들어 클라이언트에 전달해주는 역할을 합니다.
•
HTML에서 고정적인 부분은 템플릿으로 만들어두고, 동적으로 변화하는 부분만 템플릿에 데이터를 끼워 넣는 방식으로 동작합니다.
•
Rendering 과정

Client Template Engine (CSR: Client Side Rendering)

•
html 형태로 코드를 작성할 수 있고, 동적으로 DOM을 그릴 수 있습니다.
•
클라이언트에서 데이터를 받아서 DOM 객체에 동적으로 그려주는 프로세스를 담당합니다.
•
javascript 라이브러리로 랜더링이 끝난뒤 (즉, HTML DOM이 다 그려진 뒤)에 서버 통신 없이 화면 변경이필요한 경우에 필요합니다.
SpringBoot Thymeleaf 알아보기(기본 개념, 초기 셋팅)
2022/04/27 12:33
spring

H2 연결 모드

총 3가지 방식으로 연결 모드를 활용합니다.
1.
Embedded mode (local connections using JDBC)
2.
Server mode (remote connections using JDBC or ODBC over TCP/IP)
3.
Mixed mode (local and remote connections at the same time)

H2 연결 모드 장단점

Embedded Mode

임베디드 모드에서 애플리케이션은 JDBC를 사용하여 동일한 JVM 내에서 데이터베이스를 엽니다. 가장 빠르고 쉬운 연결 모드입니다.
단점은 데이터베이스가 한 번에 하나의 가상 머신(및 클래스 로더)에서만 열릴 수 있습니다.
모든 모드에서와 마찬가지로 영구 데이터베이스와 메모리 내 데이터베이스가 모두 지원됩니다.
동시에 열려 있는 데이터베이스 수 또는 열려 있는 연결 수에는 제한이 없습니다.
임베디드 모드에서 I/O 작업은 SQL 명령을 실행하는 애플리케이션의 스레드에 의해 수행될 수 있습니다. 응용 프로그램은 이러한 스레드를 인터럽트하지 않을 수 있습니다.
JVM이 스레드 인터럽트 동안 I/O 핸들을 닫기 때문에 데이터베이스 손상으로 이어질 수 있습니다. 애플리케이션 실행을 제어하는 다른 방법을 고려해야합니다.
H2 Embedded Mode 초기 셋팅
Load more
Search
Trouble Shooting Posts

배경

Spring 3.0부터 등장했던 HTTP Template Module ‘RestTemplate’를 사용하면서 큰 문제는 없게 사용했지만, Spring 5.0에서 ‘WebClient’가 나왔고 WebClient 사용을 권고하였기에 WebClient를 주로 프로젝트에 사용해왔습니다. WebClient의 사용하면서 기존에 RestTemplate의 (멀티 스레딩, Blocking 방식) 에서 WebClient (싱글 스레드, Non-Blocking)으로 변경되어 얻을 수 있는 성능과 관리에 이점이 있었습니다. 이 글에서는 WebClient를 사용하면서 발생한 “Connection reset by peer“에 대해서 어떻게 해결해 나갔는지에 대해서 이야기해보려고 합니다.
발생한 예외: (자세한 내용은 펼치기) org.springframework.web.reactive.function.client.WebClientRequestException: readAddress(..) failed: Connection reset by peer;

해결 과정

“Connection reset by peer” 발생
현상을 이야기하면, 구현하고 변경이 없는 Thirdparty 호출 코드에서 발생한 적이 없는 예외가 발생하였습니다. 현재 프로젝트에서 WebClient를 사용하면서, “Client(Application) → Server(Thirdparty) 모델” 관계를 가지고 있습니다. 코드의 변경이 없다는 것은 다음과 같은 경우에서 예외를 발생할 가능성이 있다고 판단하였습니다. 1. Client 코드가 예외를 보완할 수 없는 경우 2. “Framework 또는 Library”와의 Integration에 문제가 있는 경우 3. 호출 대상인 Thirdparty의 Server와의 Integration에 문제가 있는 경우

“Connection reset by peer” 에러는 왜 발생하였나?

위키를 통해서 왜 “Connection reset by peer”이 발생하였는지 찾아봤습니다. 내용은 다음과 같습니다.
A “connection reset by peer” error means the TCP stream was closed, for whatever reason, from the other end of the connection. In other words, the TCP RST was sent and received, but the connection is closed. This issue may happen when you send a packet on your end of the connection, but the other end doesn’t recognize the connection. It’ll send back a packet with an RST bit to close the connection. The error can happen when the peer crashes. Other times, it’s due to poorly-written applications that don’t shut their TCP connections properly.
중요한 내용은 첫 문단입니다. 요약하자면, “‘Connection reset by peer’ 에러 발생은 TCP stream이 닫혔다는 것을 의미한다.”입니다. TCP는 “데이터 전송 제어 프로토콜”로 종단간 연결을 통해서 데이터를 어떻게 전송할지 정의합니다. 그러면 어떻게 TCP 흐름이 중단 되었는지 살펴보겠습니다. 현재 우리 서비스는 HTTP/2를 활용하고 있습니다. HTTP/2는 HTTP/1.1를 호환하는데, HTTP/1.1(RFC 2068)에서 추가된 커넥션 관련 기능인 “Keep-Alive”가 적용되면 다음 이점을 얻을 수 있습니다. 1. latency 감소 : 3-way handshake에 필요한 round-trip이 줄어들기 때문에 그만큼 latency가 감소합니다. 2. 네트워크 비용 감소 : 커넥션을 재사용하기 때문에 새로운 TCP 연결을 만들기 위해서 필요한 CPU, 메모리 리소스를 줄여줍니다. 3. HTTP 파이프라인 커넥션 : 여러 개의 요청을 파이프라이닝 할 수 있다.
그러면, 우리는 여기서 발생한 “Connection reset by peer” 에러에서 왜 TCP Stream이 닫혔는가를 살펴보기 위해서 Server에서 ‘Http Keep-Alive’를 제공하고 있는지부터 확인해보겠습니다.

Thirdparty Server는 ‘Http Keep-Alive’를 제공하는가? “아니다”

“Connection reset by peer” Exception 해결 과정
2023/01/10 11:37
http
현재 글로벌 서비스를 통해서 웹과 앱을 만들고 있습니다. 글로벌 서비스는 국내 서비스보다 개발 기획과 설계 단계에서 많은 요소를 추가 고려해야 합니다. 예시로는 ‘글로벌 언어 제공’, ‘글로벌 결제 기능 제공’, ‘글로벌 계정 인증’ 등이 있습니다. 이번에는 글로벌 서비스가 취약한 계정시스템에 대한 해커의 어뷰징 행위를 어떻게 해결하고 있는 지 정리해보려고 합니다. ** 물론! 회사와 서비스에 관련된 민감한 정보는 제외하고 작성하도록 하였습니다.
설명할 “글로벌 서비스에서 계정시스템을 지켜온 과정”은 간략하게 다음과 같습니다. 다음 3가지의 구분된 과정으로 설명합니다. 1. Business(B) : 비즈니스에 필요한 서비스 구현 2. Attack(A) : 구현된 서비스에 대한 해커의 공격 3. Reinforce(R) : 해커 공격을 방어하고 강화 4. Monitoring(M) : 서비스의 상태 모니터링 현재까지 계정시스템을 방어해온 과정은 간략하게 다음과 같습니다. B ”이메일 계정 API MVP 개발” → A “이메일 회원 가입 API DDoS 공격” → R “이메일 인증 프로세스 도입” → M “이메일 인증 프로세스 도입 이후, 어뷰징 사용자 지표 확인” → A “이메일 가입 여부 확인 API Brute Force 공격” → A “이메일 로그인 API Brute Force 공격” → R “‘AWS WAF’-’Web ACLs’-’Rule’ 적용” → M “계정 탈취 공격 방어 후, 지표 확인” → B “사용자 휴대폰 SMS 인증 도입” → A “사용자 휴대폰 SMS 인증 API Brute Force 공격” → R “Application IP Block 정책 적용” → R “Application SMS 번호인증 횟수 제한 정책 적용” → R “Application 이메일 유효성 확인 정책 적용” → M “‘휴대폰 SMS 인증’, ‘이메일 회원가입’ 어뷰징 확인”
여기서 부터는 어떻게 계정시스템이 지켜져왔는지 자세하게 설명하겠습니다.

1. Business: 이메일 계정 API MVP 개발

•
MVP Open API 개발 배포

2. Attack: 이메일 회원가입 API DDoS 공격

“이메일 회원가입” API 배포 이후, 얼마 지나지 않아 다음과 같은 어뷰징 스크립트 DDoS 공격 들어왔습니다. DDoS의 영향 DDoS 공격으로 신뢰할 수 없는 회원가입이 이루어졌고, 실제 사용자 계정과 관련없는 더미 데이터들이 DB에 쌓이게 되었습니다.
동시에 계정을 관리하는 인증서버는 트래픽을 견디지 못하였습니다. Auto Scaling을 적용하였지만, Scale-out 속도와 DDoS 공격속도는 일정하지 않아서 한동안은 로그인이 지연되거나 실패하는 장애로 이어졌습니다. 최고점에는 평소 트래픽의 8배의 RPM(Requests Per Minute)을 발생시켰습니다. 물론 Scale-out이 진행된 후에는 장애로 이어지지 않았습니다. Scale-out 동안 장애를 발생시키지 않기 위해서 새롭게 만들어진 Instance의 Health Check 주기를 최대한 줄여서 트래픽을 처리할 수 있게 하였습니다.
이 문제를 사용자의 최소 인증을 통해서 해결해야한다고 생각했고, 비즈니스팀과 공감하여 “이메일 인증 프로세스 도입”을 추진하였습니다.
글로벌 서비스에서 계정시스템을 지켜온 과정
2023/01/07 10:28
security
waf
hacking

Trouble Shooting 이란?

“시스템에서 발생하는 복잡한 문제들을 종합적으로 원인을 진단하고 해결하는 것.”

Trouble Shooting 과정

1. 문제 정의

•
문제 동작 확인 분석 후, 문제를 정의한다.

2. 문제 사실 수집

•
‘정의된 문제’를 바탕으로 대략적으로 점검할 항목과 내용을 결정한다.
•
‘정의된 문제’를 재현하는 방법도 수집한다.

3. 문제 원인 추론

•
‘수집된 사실’을 바탕으로 문제의 ‘원인 추론’을 한다.

4. 문제 조치 방안 작성과 조치 구현

•
‘추론한 원인’에 따른 ‘조치 방안’을 마련하고 구현 단계를 거쳐 ‘문제 해결’을 한다

5. 구현이 반영된 후, 결과 관찰

•
‘조치 방안’을 관찰할 ‘조사 방법’을 마련하고 ‘관찰 결과’를 기록한다.
나는 어떻게 Trouble Shooting 하고 있는가?
2022/11/14 12:07
software engineering

1. 장애 탐지

2022.04.16
서비스 장애로 사용자들의 CS 문의가 빗발치기 시작했다.
백엔드에서는 몇가지 작은 에러 로깅이 있었고, 슬랙 알림이 발생했다. 이후에는 심각한 징후도 발견되지 않았다.
QA를 진행한 동료들의 일부는 앱은 서비스가 되고, 웹은 안된다고 하였고, 또 일부는 서비스가 모두 정상적으로 된다고 하였다.
이전에 발생했던 장애와 다른 형태의 장애가 발생한 것이다.
일반적으로 대규모 장애인 경우에 백엔드가 우선적으로 알아차릴 수 있었다.
하지만 이번 장애는 백엔드에서 선제적으로 알아차리지 못했다.
나열된 단서들을 가지고, 장애 전파와 해결에 활용해야한다.

2. 장애 전파

백엔드에서 발생하는 기본 장애 알림은 Slack 채널을 통해 자동화되어 있었다.
그리고 서비스의 전반적인 장애가 발생하였기 때문에 서비스 관련자가 있는 Slack 채널에 @Channel 알림으로 장애에 대한 상황을 전파했다.
그리고 탐지한 이슈 관련자들과 DM을 만들어서 Huddle 을 시작했다.

3. 장애 해결

도메인의 만료를 확인하고, 도메인을 구입한 벤더에서 구매하여, 장애를 해결하였다.
서비스 도메인 갱신 장애
2022/04/16 15:39
domain

에러 발생 원인

•
로컬에서 요청할 DNS 서버 정보가 잘못 설정되어 있는 경우
•
DNS 서버에 내 Domain이 업데이트 되어있지 않는 경우
•
내 Domain이 사용 기간이 만료된 경우
(Domain, IP) 정보를 찾는 이유는 인터넷 세상에서는 IP Addres를 기준으로 요청이 전달되기 때문입니다.

에러 발생 해결

•
로컬에서 요청할 DNS 서버 정보가 잘못 설정되어 있는 경우
•
DNS 서버에 내 Domain이 업데이트 되어있지 않는 경우
•
내 Domain이 사용 기간이 만료된 경우
DNS_PROBE_FINISHED_NXDOMAIN
2022/03/11 15:40
dns
Solution : "An error occurred (TargetNotConnected) when calling the StartSession operation: {instance-id} is not connected."
2022/02/14 16:37
aws

문제 배경

사용자가 서비스에 접속하면, “접속 정보"를 가져오고, DB에 영속화되어 관리되어집니다.
관리되어지는 가장 큰 이유는 비정상적인 또는 Fraud 여지가 있는 사용자들을 구분하기 위해서 입니다.
하지만,
IP와 Geo Location 정보는 시점에 따라서 달라질 수 있습니다.
그래서 사용자의 Geo Location 정보를 최신화하여, DB에서 관리되어지는게 중요합니다.
현재 사용자 접속 정보가 최신 정보가 아니라서 CX팀에서 최신화된 정보를 요구하고 있습니다.

문제 정의

“최신화되지 않은 Geo Location 정보가 영속화되어 변경된 정보와 매칭되지 않습니다”

문제 해결

1. Upgrade “Application Dependency Version” for ‘com.maxmind.geoip2’

AS-IS with 2.12.0
TO-BE with 2.16.1
“사용자 접속 정보” 최신화 하기
2022/08/29 11:29
geo location
data
장애 탐지 → 장애 전파 → 장애 해결 → 장애 보고 → 장애 회고

장애 탐지

2022.08.04

환경

•
Amazon Linux 2 AMI - Kernel 5.10
•
JDK 1.8
•
Spring Boot 2.4
1.
Third-party API를 호출 시, 아래와 같은 장애가 발생
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
예외 발생
2.
SSL 인증서로 기존 “Comodo” 인증서가 “Sectigo”로 변경되면서, 리눅스 시스템 내 Root/chain 인증서가 반영이 안되었고, JAVA SSL HandshakeException 및 Curl 오류가 발생
SSL 인증서

장애 전파

Java 기반에서 SSL 접속시, PKIX path building failed 오류
2022/08/04 04:50
java
ssl
Search
Books
Book Report “오늘, 또 일을 미루고 말았다”
“인생은 한 치 앞을 알 수 없다”로 책은 시작된다. 너무나 당연한 이야기지만 이 책에 모든 기본이 되는 문장이었다. 나에게 이 책은 “기본은 사람이 되어야하고 남을 의식하지 않는 노력을 해야한다” 라는 이야기를 알려주었다. 삶의 의미를 하나씩 사유하며 살아간 분들이라면 조금이라도 공감되는 이야기가 아닐까 생각한다. 책에서 손웅정님은 나의 자식을 사람으로써 한 개인으로써 대하고 배려한 부분이 인상적이었다. 아들들이 축구를 시작할 때도 강요하지 않았고 오히려 아들들의 의지를 보고 도와주는 방식으로 일류의 축구선수로 코칭하였다. 좋은 지도자란 ‘기회를 주는 사람’이라는 것을 이야기하였고, 기회는 결국 준비된 사람에게 온다는 것을 알고 있었기에 꾸준하게 의식적인 노력을 해왔다는 것이다. 어린 시절 서산에서 자란 손웅정님은 초등학교 때부터 축구를 해왔다. 지금처럼 선진화된 축구가 발전되지 못한 한국의 어느 시골에서는 ‘기본’을 충분히 연마하지 못하였고 그렇게 프로 축구까지 가서 국가대표 2군까지 되었지만, 부상때문에 빠른 은퇴를 할 수 밖에 없었다는 것을 보곤 참 슬픈 이야기였다. 손웅정님은 어렸을 때부터 몸을 혹사시켜서 은퇴와 충분한 기량을 보여줄 수 없었던 많은 어린 선수들을 보면서 안타까움을 가진 것도 코칭에 있어서 많은 도움이 되었던 것 같았다. 내가 느낀건 “뱁새가 황새따라 가다 가랭이 찢어진다” 라는 이야기처럼 사람들은 각자 때가 있고 그 때를 만나기 위해서는 기다릴 줄도 알아야하고, 때가 왔을 때 알아볼 줄 알아야한다. 그렇기 위해서 준비되어야한다. 유튜브에서도 많이 보았던 말씀인데, “지금 흘러가는 이 시간, 네 인생에서 다신 안와” 라는 말이 마음을 후벼 팠다. 맞아 지금 내 인생 다신 안오지… 이 책에서 나오는 말 하나하나가 다 주옥같다. 그리고 책을 읽으면서 많은 반성을 하게 된다. 물론 손웅정님은 나를 반성하게 하려고 책을 쓴 건 아니지만 말이다. 성장에 대한 관심이 많은 책인데, 재미있는 일화가 있다. 이건 책에서도 손세이셔날 영상에서도 봤던 것인데, 손흥민이 성장하면서 과정에 받았던 모든 상은 재활용품이나 일반쓰레기가 되었다는 것이다. 과거에 발목잡히지 않고 항상 성장을 하기 위해서는 지난날의 영광을 잊어야한다는 것이다. 맞다. 보통의 우리는 이런 말을 많이 한다. “내가 10년 전에는 말이야” 이런 류의 이야기. ”나를 성장시키려고 마음먹고 나를 초월하고 나를 넘어서겠다고 다짐했을 때 성장이 찾아온다.” 라는 이야기를 스티브 잡스의 “Stay hungry, Stay foolish” 의 이야기로 대신 하였다. 현실에 안주하지 않고 어리석어 보일 정도로 끊임없이 노력해야한다. 남들의 시선을 마음에 담아두지 않았다. ”남들이 뭐라건 중요하지 않다. 나의 중심이 잡히고, 확신을 가지면 된다.” 이 가장 근본적인 문장에서 인생을 살아왔던 것 같다. 끝으로 내가 느끼기엔 정말 멋있는 분이다. 책을 읽는 내내 바이블을 읽는 느낌마저 들게 하는 구절이 많았다. 책을 다 읽고 나니 다시 처음으로 돌아가 “모든 것은 기본에서 시작한다”라는 이야기를 하면서 마쳐야겠다.
Book Report “모든 것은 기본에서 시작한다”
블록체인으로 이루어진 자산들의 실체를 찾아다니면서 투자하는 투자자의 책이다. 저자는 미래에 올 디지털 자산에 대해서 이야기를 하는데, 사실 나는 디지털 자산이 어떻게 이루어져있는지 그 실체가 무엇인지가 쓰여있다고 해서 봤는데 그런 내용을 담진 않은 것 같다. 디지털 자산투자를 어떤 마음으로 어떻게 해야하는지에 대해서 남겨져있는 책이었다. 다른 투자 서적들과 다른 점은 단순히 방법론을 설명하는 방법으로 이야기를 전개해나가지 않고, 인간 중심적으로 인본주의를 기반한 투자에 대해서 설명하였다. 결국 스스로 사람다움을 가지고 인내할 수 있는 환경을 만들어야 투자에서 성공할 수 있다는 이야기라고 볼 수 있었다. 내가 원하는 기술적인 블록체인의 미래에 대한 내용은 없어서 조금 아쉬웠지만 인본적인 내용은 흥미로웠다.
Book Report “키웨스트의 디지털자산투자”

Study Roadmap

Contact