코딩하는 eroke

SOLID 란 ?

- 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 적용할 수 있는 원리이다.

- 5가지 원칙들의 약어 첫 문자를 따서 SOLID라 칭한다.

SOLID 구성 5원칙

1. SRP	단일 책임 원칙 (Single responsibility principle) : 한 클래스는 하나의 책임만 가져야 한다. - 클래스는 하나의 기능만 가지며 모든 서비스는 그 하나의 기능을 수행하는데 집중(책임)되어야 함   어떤 변화에 의해 클래스를 변경하는 이유도 오직 하나이어야 함   (가독성 향상, 유지보수 용이)
2. OCP	개방-폐쇄 원칙 (Open/closed principle) : 소프트웨어 요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.  - 변경을 위한 비용은 줄이고 확장을 위한 비용은 극대화 해야함 - 변경이 발생하더라도 기존 구성은 수정이 일어나지 말아야함 = 기존 구성요소를 확장해서 재사용
3. LSP	리스코프 치환 원칙 (Liskov substitution principle) : 서브타입은 언제나 기반 타입으로 교체할 수 있어야 함 - 서브클래스가 확장에 대한 인터페이스를 준수해야 함 (public ,인터페이스, 메소드의 예외 등)
4. ISP	인터페이스 분리 원칙 (Interface segregation principle) : 하나의 범용 인터페이스보다 여러 개의 구체적인 인터페이스가 낫다. (인터페이스의 단일 책임 강조) - 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 함 1) 클래스 상속을 이용해 분리 : 인터페이스에 서비스가 제한될 수 있음 2) 객체 인터페이스 위임을 이용해 분리 : 책임을 다른 클래스/메소드에 맡김
5. DIP	의존관계 역전 원칙 (Dependency inversion principle) : 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. - 하위레벨 모듈이 상위레벨 모듈의 변경을 요구하는 관계를 끊는 것 - 둘의 관계를 직접 연결하는 게 아니라 추상레벨로 연결 = 상위 모듈의 확장성 보장  - 예시 : 소켓프로그래밍 비동기 모델 클라이언트 스레드가  직접 send(), recv() 하지 않고 훅 메소드를 실행    클라이언트 스레드의 잦은 응답확인을 제거, 클라이언트 스레드는 응답 확인할 시간에 다른 작업 가능해짐

+ 상속 시 주의할 점

is-a : 상속관계

일반적 개념-구체적 개념의 관계 (동물-사람, 동물-사자 등)

일반클래스를 구체화하는 상황에서 사용

하위 클래스가 상위 클래스에 종속 됨 (상위 수정 시 하위 미치는 영향 큼 -> IS-A 관계여야만 하는 이유)

has-a : 포함관계 (상속X)

다른 클래스의 기능(변수/메소드)을 사용.  (컴퓨터클래스 - CPU클래스, RAM클래스 등)

Reference

SQL 성능개선 팁을 정리해보려 한다.

1. 인덱스 사용 시 주의사항 

- 조회(SELECT, WHERE)시에는 속도에 도움을 주지만 삽입(INSERT), 갱신(UPDATE)시에는 오히려 느려진다.

- 데이터가 적은 경우에는 사용하지 않는 게 좋다.

- 조회쿼리 성능개선을 위해 WHERE 절에 자주 사용되는 컬럼은 인덱스로 지정하기도 하는데 주의할 점이 있다.

- 구간 별 선택이 많은 컬럼은 클러스터 인덱스 추천 

특정 컬럼을 인덱스로 지정해도 사용할 수 없는 경우

• LIKE '%'을 변수 앞에서 사용 > 무조건 FULL SCAN
• IS NULL, IS NOT NULL 사용
• 여러컬럼에 OR 사용
• 부정비교에 사용 (예시 : NOT, <>, !=. NOT EXISTS )
• 컬럼을 변형한 경우 (예시 : substr() )

2. 데이터 추출 시 주의사항

• select에 필요한 컬럼만 지정 (select * 지양, 사용하지 않는 데이터 호출에도 부하가 발생할 수 있음)
• where 절 조건문 작성 시, 가장 많은 데이터를 걸를 수 있는 컬럼을 우선적으로 작성
• where 절 조건문 작성 시, 왼쪽은 되도록 변형되지 않은 순수 컬럼을 사용
• 정렬 (order by)하지 않고 limit, top을 사용중인지 확인
• 백만건이 넘어갈 시에는 파티셔닝을 고려
• IN < EXISTS < INNER JOIN 순으로 가독성은 떨어지지만 성능이 좋음
• 서브쿼리보다 JOIN을 지향 (상황에 따라 서브쿼리로 추출 후 조인 시 성능이 개선될 수도 있음)
• COUNT()보다 EXISTS() 지향
  • COUNT()는 모든 레코드 중 관련 데이터를 필터링 한 후 함수를 수행
  • EXISTS()는 필터링 시 하나라도 레코드가 있을 때 반환  

추후 개선 알게되는 팁은 계속해서 추가할 예정입니닷,,

Reference

• OS 인강 - 반효경 교수님 KOCW 강의

• 깃허브 기술 면접 Repository
• https://github.com/JaeYeopHan/Interview_Question_for_Beginner
• https://github.com/WooVictory/Ready-For-Tech-Interview
• https://github.com/gyoogle/tech-interview-for-developer
• https://github.com/WeareSoft/tech-interview

Reference

INDEX 인덱스 (색인)

• 책으로 비유하자면 목차
• DBMS에서 저장 성능을 희생하여 데이터 읽기 속도를 높이는 기능
• 데이터가 정렬되어 들어감
• 양이 많은 테이블에서 일부 데이터만 불러 왔을 때, 이를 풀 스캔 시 처리 성능 떨어짐

• 종류
  • B+-Tree 인덱스 : 원래의 값을 이용하여 인덱싱
  • Hash 인덱스 : 칼럼 값으로 해시 값 게산하여 인덱싱, 메모리 기반 DB에서 많이 사용
  • B>Hash
• 생성시 고려해야 할 점
  • 테이블 전체 로우 수 15%이하 데이터 조회시 생성
  • 테이블 건수가 적으면 인덱스 생성 하지 않음, 풀 스캔이 빠름
  • 자주 쓰는 컬럼을 앞으로 지정
  • DML시 인덱스에도 수정 작업이 동시에 발생하므로 DML이 많은 테이블은 인덱스 생성 하지 않음

JPA (Java Persistence API) 

JAVA에서 제공하는 API / 자바 어플리케이션에서 RDB를 사용하는 방식을 정의한 인터페이스 

자바 ORM 기술에 대한 표준 명세 (스프링 X)

데이터를 객체지향적으로 관리 > 개발자가 비즈니스 로직에 집중 

동작 과정

Java 애플리케이션과 JDBC 사이에서 동작

개발자가 JPA 사용 (개발자가 JDBC API 사용 X) > JPA 내부에서 JDBC API 사용 > SQL호출 > DB 통신

ORM (Object-Relation Mapping) : DB데이터 <-mapping-> Object 필드

객체-관계 매핑 = 자바 클래스와 DB 테이블을 매핑

SQL 매핑 X, SQL 자동 생성됨 (JPA, Hibernate)

필드 변경 시 JPA에 추가만 하면 됨

JPA : 자바객체-DB 매핑 위한 인터페이스 제공

JPA 구현체(인터페이스) : Hibernate, EclipsLink, DataNucleus, OpenJPA, TopLink Essentials

Spring Data JPA : 스프링에서 제공하는 JPA 프레임워크

> Spring Data JPA가 Hibernate보다 구현체 교체/ 저장소 교체 용이

SQL Mapper : SQL <- mapping -> Object 필드

SQL로 DB 조작 (Mybatis, jdbcTemplate)

필드 변경 시 모든 SQL 수정해야 함

JDBC  : Java Data Access 기술의 근간 (자바 API)

계층화 아키텍처

Reference

RPC : Remote Procedure Calls

= 다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램을 허용하는 프로토콜

개발자가 원격 상호 작용에 대한 세부 정보를 명시적으로 코딩하지 않아도 됨

프레임워크가 자동 핸들링

클라이언트 코드에서는 직접 서버 코드의 함수를 호출하는 것처럼 보임

클라이언트 코드 언어 ≠ 서버 코드 언어 : 다른 언어로 쓰일 수 있음

gRPC = Communication 프레임워크

마이크로서비스는 여러 PL들로 만들어짐 (ex : back-end = Go, front-end = java)

이 서비스들 간의 소통 필요

마이크로서비스 간의 교환되는 메시지 수 = 엄청나게 많음 >>> 빠른 소통이 좋음

개발자는 핵심 로직구현만 집중하도록 하고 소통은 프레임워크에게 맡기기

gRPC = High-performance Open-source Feature-rich Framework

• originally developed by Google
• 지금은 Cloud Native Computing Foundation 파트 (CNCF - like 쿠버네티스)
• gRPC 메시지는 기본적으로 Protobuf (이진형식)로 인코딩 됨 > 송수신 효율적 but 사람이 못읽음

gRPC는 Protocol Buffers를 통해 클라이언트 코드와 서버 인터페이스 코드를 생성.
옵션에 따라 생성하는 언어 변경 가능
>>> 하나의 proto 파일을 사용해서 go, python, java, swift 등 다양한 언어의 서버/클라이언트 코드를 생성할 수 있음

'g'는 gPRC 릴리스마다 다름 (https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md)

gRPC 작동원리

1. 클라이언트는 stub 생성 (서버랑 같은 메소드 제공)
2. stub는 gRPC 프레임워크를 호출 (내부 네트워크를 통해서 호출)
3. 클라이언트와 서버는 서로 상호작용을 위해 stubs 사용 >>> 서로의 코어 서비스 로직의 권한만 필요)

gRPC - HTTP API 비교

.proto 파일 : gRPC서비스/ 메시지 계약 정의

gRPC 한계

브라우저에서 gRPC 서비스 직접 호출 불가능

> gRPC-Web 사용 (양방향 스트리밍 불가, 서버 스트리밍 제한적)

> RESTful JSON Web API 에서 HTTP 메타데이터로 .proto 파일에 주석으로 gRPC 서비스 사용

(애플리케이션= json Web API, gRPC 둘다 지원)

Reference

유튜브 TECH SCHOOL 의 [gRPC #1~3] 강의

출처(Origin)란?

Protocol과 Host, 포트 번호(:80, :443)까지 모두 합친 것

동일 출처 정책?

서로 다른 출처의 리소스 간 상호작용을 방지하기 위해 클라이언트 측 웹 애플리케이션(웹브라우저 등)에서 적용되는 보안 정책

> 악의적인 행동 뿐 아니라 origin 간의 적법한 상호작용도 방지함 > 해결 방안 = CORS

CORS란? (교차 출처 리소스 공유)

웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조

도메인/ 포트가 다른 서버의 자원을 요청하는 것 

추가 HTTP 헤더를 사용해 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행함

웹페이지는 교차 출처 이미지, 스타일시트, 스크립트, iframe, 동영상을 자유로이 임베드할 수 있음

특정 cross-domain 요청, 특히 Ajax 요청은 기본적으로 금지됨 (동일-출처 보안 정책 위배)

CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의함

CORS 요청 유형

1) 단순 요청 : 바로 시작 가능

(1) 브라우저가 Origin 헤더(리소스 공유를 위한 리소스 출처를 포함)를 요청에 추가함 

(2) 대상은 http 메소드와 Origin 헤더 값을 CORS 구성의 메소드/출처 정보와 비교

(3) 일치하면 Access-Control-Allow-Origin 헤더를 응답에 포함시킴 (초기 요청의 Origin 헤더의 값 포함)

2) 실행 전 요청 : 기본 요청 진행 전에 '실행 전' 요청을 서버에 보내 권한 받아야 함 

• GET, HEAD, POST 외의 메서드 사용
• POST 메서드를 text/plain, application/x-www-form-urlencoded, multipart/form-data가 아닌 Content-Type과 함께 사용
• 커스텀 헤더를 설정. (ex: X-PINGOTHER)

(1) 브라우저가 기본 요청의 Requested Method/ Requested Headers 를 포함하는 OPTIONS 요청 보냄

(2) 대상은 리소스 허용하는 http 메소드/ 헤더값 반환

    > 실행전 요청의 메소드/헤더 중 하나라도 대상 리소스에서 허용하는 메소드/헤더 집합에 없으면 요청 실패

관련 헤더

요청 헤더

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

응답 헤더

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

Reference

SW 아키텍처에 대한 책을 읽다가 DevOps에 대한 재밌는 칼럼이 있어 정리해봤다.

기존 개발 운영체계는 개발팀, 운영팀이 분리되어 있다.

문제점
개발팀은 애플리케이션에만 몰두
운영팀은 인프라에만 몰두

장애 발생 시 서로에게 책임 전가, 회피 !!!
>>> 강제적으로 모여야 원인 파악이 가능

배포 후 고객은 운영팀에게 개선 요구 >>> 처리는 개발팀이 가능
=파국

이 문제점들은 실제로 운영, 개발을 해본 경험상 매우 공감되는.. 사실 개발, 운영팀이 분리된 기업의 현실 그 자체다 ㅋㅋ..

대안
DevOps = 개발과 운영을 합치자!
적극 활용 기업 = Netflix
잦은 배포 가능, 배포 실패율도 감소

테스트도 개발과정의 일부로 = TDD(Test Driven Development), CI(Continuos Integration)

한 팀 내에서 개발, 테스트, 배포, 운영, 사용자 피드백 수용
>>> 개발 사이클 매우 빠름. 연속적. 연결적





Reference
조대협의 서버사이드 : 대용량 아키텍처와 성능 튜닝 (조대협)

요즘 출퇴근하면서 요런 책을 읽고 있다.

모놀리식 아키텍처

기존의 웹 기반 애플리케이션
서비스 간 호출 = Call by Reference
• UI, 비즈니스로직, DB액세스로직, ... 모두가 하나의 애플리케이션 산출물로 패키징, 배포됨
• 각 팀의 변경이 있을 때마다 애플리케이션 전체를 빌드, 테스트, 배포해야함
• 애플리케이션 규모가 커질 수록 각 팀의 의사소통, 조정비용이 증가함

마이크로서비스

서비스 간 호출 = API
• 애플리케이션을 제한된 책임을 담당하는 컴포넌트로 분해 (전통적 복잡성 문제 해결)
• 느슨히 결합된 작은 분산 서비스
• 각 팀이 코드/ 인프라스트럭쳐 (앱서버, DB)를 독립적으로 가짐
• 팀 단위로 빌드, 테스트, 배포 가능 (상호독립적)
• 확장성, 회복성 향상
• http, json 같은 경량 프로토콜 사용 = 기술 중립적 = 다양한 언어, 기술 사용 가능

MSA : 마이크로 서비스 아키텍처

- SOA 사상에 근간을 둠
- 컴포넌트를 서비스로 정의 (구현)
- REST API 같은 표준인터페이스로 기능을 외부에 제공
- 서비스경계 = 도메인경계
- 서비스 : 독립적인 war파일로 개발, 독립된 톰캣 인스턴스에 배치
- 톰캣 인스턴스 : 횡적으로 스케일가능 (인스턴스 더함), 서비스 간 로드 분산시킴 (앞단에 로드밸런서 배치)
UX(Front-end) - 로드밸런서 - 톰캣(war)

• SOA(서비스 지향 아키텍처) : 엔터프라이즈 시스템 중심으로 고안됨
프로젝트 실패 원인 > ESB (Enterprise Service Bus)
: 메시지를 내부적으로 xml로 변환해서 처리함(EAI 통합기능 처리를 위해...) > 파싱에 대한 오버헤드 발생
> 대안= API Gateway = EAI기능 제거, API처리 기능에만 집중

•  API Gateway
- MSA의 주요 컴포넌트 (미들웨어) = SOA의 ESB 경량화 버전
1) 모든 API의 엔드포인트 통합 (like Proxy) 기능
Hub & Spoke 방식으로 서비스 간 호출 단순화 가능
(MSA는 API 엔드포인트=서버 URL이 각기 다름=사용자관점 불편해짐 >>> 통합필요)
2) 오케스트레이션 (like Mashup) 기능
여러 서비스를 묶어 하나의 서비스로 만듬 (넷플릭스)
3) 공통 기능 처리 기능
API 인증/로깅 같은 공통 기능 담당 > API는 비즈니스 로직에만 집중하도록 함
4) 중재 기능
xml, 네이티브 메시지포맷 -> json 상호변환
프로토콜 변환
서비스 간 메시지 라우팅

• MSA의 단점
서비스 호출(API통신)시 json/xml -> 프로그래밍 데이터 모델 (ex: java객체) 변환하는 오버헤드 발생
메모리 사용량 증가 (독립 서비스 독립 서버 분할 배치)
운영관점 대상 시스템, 필요 기술 증가
서비스간 트랜잭션처리 (모노리틱은 롤백) 구현필요 (복잡)



Reference
스프링 마이크로서비스 코딩 공작소 (존 카넬)

조대협의 서버 사이드 : 대용량 아키텍처와 성능 튜닝 (조대협)

• Interface : 상호작용

• API ( Aplication Programming Interface): SW가 다른 SW로부터 지정된 형식으로 요청, 명령받을 수 있는 수단

• REST API : 웹>서버, 앱>서버 에 주로 사용되는 서비스 형식(REST)의 API
기존에 복잡했던 SOAP 방식 대체
각 요청이 어떤 동작, 정보를 위한 것인지 그 요청의 모습 자체로 추론가능함

ex) URI : 자원을 구조와 함께 나타냄
https://(도메인)/classes/2/students/15
: 2반의 15번 학생
https://(도메인)/classes/2/students?sex=male
: 남학생 조건
https://(도메인)/classes/2/students?page=2&count=10
: 한페이지에 10명 지정, 즉 11~20번 학생 (2page)

서버에 REST API로 요청 보낼때=HTTP 규약에 따라 신호 전송
- GET/ DELETE/ (BODY) POST/ PUT/ PATCH
body=get, delete 보다 정보를 많이, 비교적 안전하게 보낼 수 있음

• REST API의 보안

1) 인증
- API key : 특정 사용자만 아는 문자열. 클라이언트가 같은 키 공유 > 보안 취약

- API token : id/pw로 사용자 인증 후에 API호출 기한이 있는 토큰 발급 > 토큰으로 사용자 인증
= pw 유출의 연쇄적인 보안 문제 방지

token 방식 :
HTTP Basic Auth : 헤더에 id/pw 인코딩형태(Base64)로 인증
Digest Access Authentication : Base64 인증 단점 보강. 클라이언트가 인증 요청 시 서버로부터 nonce (난수) 발급 받음
id/pw를 nonce를 이용해 해시화, 서버에 전송

2) 인가 : 사용자 권한 체크 (해당 리소스에 대해 사용자가 리소스 사용 권한 있는지)

3) 네트워트 레벨 암호화 (https 보안 프로토콜)



• RESTful :
CRUD를 목적에 따라 구분해서 사용해야 함
URI 는 동사가 아닌 명사로 이뤄져야 함!
(restful api design guidelines 참고)

이어서...
GraphQL : 용도에 따라 REST API의 대안으로 사용됨


Reference
1)

2) 조대협의 서버사이드 : 대용량 아키텍처와 성능 튜닝