코딩하는 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

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) 조대협의 서버사이드 : 대용량 아키텍처와 성능 튜닝

IBM API Connect

• 클라우드 간 API 작성, 관리를 수행할 수 있는 확장형 API 플랫폼 (보안성/검증성/확장성/직관성/유연성/강력성)
• 애플리케이션과 데이터가 있는 모든 위치에서 작동 가능 (예: 온프레미스, 컨테이너, 클라우드)
  • Docker 컨테이너 지원가능한 모든 위치에 배치됨
  • 멀티클라우드 환경에서 서비스와 데이터를 안정적으로 관리, 보호

• 고급기능
  1. API 관리자 : 내부 용도로 API를 관리하거나 REST 또는 SOAP API로서 서비스를 외부에서 수익화하고 관리할 수 있게 하는 사용자 인터페이스
  2. IBM DataPower Gateway : 엔터프라이즈 레벨에서 API 트래픽, 상호작용을 보호, 제어, 로깅/ 컨테이너 지원
  3. 개발자 포털 : 회사 브랜드 포털을 이용해 API를 애플리케이션 개발자와 공유. 개발자는 API 검색, 등록, 연관 애플리케이션 등록, 배치가능
  4. 개발자 툴킷 : API, LoopBack® 애플리케이션을 모델링, 개발, 테스트
  5. 클라우드 관리자 : 간단한 사용자 인터페이스를 이용해 API Connect 온프레미스 클라우드를 구성, 관리, 모니터링

DataPower Gateway

• API connect의 보안 구현
• 완성도/효율성/안전성
• 공통 보안, 트래픽, 중개 및 가속화 기능을 중앙 집중화
• 드래그앤드롭 보안 정책

• 주요정책
  1. 레코드의 시스템 과부하를 방지하는 속도 제한
  2. 데이터 변환(예: JSON에서 XML로 변환)을 위한 중개 정책
  3. 올바른 서비스로 수신 트래픽을 지능적으로 라우팅하는 트래픽 관리
• IBM CloudTM 또는 OVA나 Docker 파일이 설치될 수 있는 모든 위치에서 실행 가능
  1. 써드파티 퍼블릭 클라우드 (예: Amazon Web Services, Microsoft Azure, Google Cloud Platform)
  2. 온프레미스 데이터 센터 (예 : IBM Cloud Private)
  3. 프라이빗 클라우드 (예 :  표준 Kubernetes)

Reference

www.ibm.com/kr-ko/cloud/api-connect/secure

언어의 목적 : 페이지의 동적 제어

객체 기반의 스크립트 언어 (컴파일 X, 텍스트로 실행)

함수기반 언어 (변수 함수 내에서만 사용가능)

웹 브라우저에서 실행 (html/css에 의존적)

모듈화 미지원

동적타입 (변수 타입 지정 없어도 가능)

멀티 패러다임 언어 (객체 지향/함수형 프로그래밍 둘다 지원)

자바스크립트가 주로 사용되는 프로젝트

▷ 동적인 싱글 페이지 애플리케이션(SPA)
▷ 제이쿼리(jQuery), 앵귤러JS(AngularJS), 백본(Backbone.js), 엠버(Ember.js), 리액트(React.js) 등
▷ 노드(Node.js), 몽고디비(MongoDB), 익스프레스(Express.js) 등
▷ 모바일 앱 개발 : 리액트 네이티브(React Native), 폰갭(PhoneGap) 등

Reference

React 와 Vue는 차이점보다 유사점이 더 많은 UI 라이브러리이다.

공통점

• Javascript 기반의 Frontend Framework
• 반응적이고 조합 가능한 컴포넌트 제공 (Reactive Component)
• Virtual DOM 으로 빠른 렌더링
• 경량 라이브러리
• Server Side Rendering
• 라우터, 번들러, state management 와 결합이 쉬움
• 훌륭한 개발자 커뮤니티와 지원

차이점

• React에서는 모든 것(HTML, CSS...)이 JavaScript 이다
• Vue는 고전적인 웹기술들을 받아들여서 그 기반 위에 만들어짐

• Vue.js는 사용자에게 쉽게 느껴지는 API를 제공하기 위해 라이브러리가 직접 헤비 리프팅을 하는 경우가 많다.
• React는 Vue.js에 비해 사용자 및 사용처에 대해 더 적은 가정을 하고, 컴포넌트 기반의 선언적 UI 렌더링이라는 가장 핵심적인 기능과 관련된 부분만 코어에 포함한다.

Vue 의 장점

• Template 과 Render Function 을 모두 사용할 수 있는 옵션
• 간편한 Syntax 와 프로젝트 설정
• 빠른 렌더링과 더 작은 용량

React 의 장점

• 큰 규모에서 더 빛을 발하고, 테스팅이 수월
• Web 과 Native 앱 개발에 모두 사용 가능
• 더 큰 개발자 생태계에서 오는 많은 레퍼런스와 도구들

Reference