컴퓨터 구조 내 명령어(Instruction)는 컴퓨터가 수행해야 할 동작을 지시하는 기본적인 단위이다. 명령어는 일련의 비트로 구성되며, 이진 코드로 표현. 이진 코드는 0과 1로 이루어진 비트열로, 컴퓨터가 직접 이해하고 처리할 수 있는 형태.

명령어는 주로 연산(덧셈, 뺄셈, 곱셈, 나눗셈 등), 메모리 접근(예: 데이터 읽기, 쓰기), 제어 흐름(예: 조건부 분기, 반복문) 등의 작업을 수행하고 이러한 명령어는 CPU가 해석하고 실행한다.

며

명령어의 구조

• 오퍼랜드(Operand)

  • 오퍼랜드는 명령어에서 조작되는 데이터 또는 명령어의 피연산자.
  • 명령어가 어떤 작업을 수행할지 결정하는 데 필요한 데이터나 값.
  • 예를 들어, 덧셈 명령어에서는 덧셈할 두 개의 숫자가 오퍼랜드.

• 오퍼레이션(Operation)

  • 오퍼레이션은 명령어에서 수행되는 작업이나 동작.컴퓨터에서 실행되는 작업, 즉 연산이나 조작의 종류를 의미.
  • 예를 들어, 덧셈, 뺄셈, 곱셈, 나눗셈과 같은 산술 연산이나 논리 연산, 비트 연산 등이 오퍼레이션.

• 주소(Address)

  • 주소는 컴퓨터의 메모리에서 데이터나 명령어의 위치를 나타내는 값.
  • 명령어나 데이터가 저장된 메모리의 위치를 가리키는데 사용.

문자 집합은 컴퓨터에서 문자를 표현하는 데 사용되는 일련의 문자들의 집합. 컴퓨터에서는 다양한 문자 집합이 사용될 수 있으며, 이는 언어, 국가, 문자열의 형식 및 다양한 기타 요소에 따라 다를 수 있다.

문자 인코딩

문자 인코딩은 컴퓨터에서 문자를 표현하고 저장하는 방법을 정의하는 체계. 문자 집합에 속한 문자여도 컴퓨터는 그대로 이해할 수 가 없다. 그래서 텍스트 데이터는 컴퓨터에서 이진 숫자로 저장되며, 이를 위해 문자를 숫자로 매핑하는 방법이 필요.

문자 디코딩

문자 디코딩은 이진 데이터를 문자로 변환하는 과정. 컴퓨터에서 텍스트 데이터는 주로 이진 형태로 저장되기 때문에, 이진 데이터를 사람이 읽을 수 있는 문자 형태로 변환이 필요.

문자 인코딩은 문자를 이진 데이터로 변환하는 과정이며, 문자 디코딩은 그 반대 과정입니다. 문자 인코딩과 디코딩은 서로 대응되는 과정으로, 올바른 인코딩 방식을 사용하여 데이터를 디코딩해야 원래의 문자를 올바르게 복원이 가능하다.

인코딩 방식

아스키(ASCII) 코드

아스키(ASCII) 코드는 컴퓨터에서 문자를 표현하기 위해 사용되는 표준 문자 인코딩 방식. 아스키 코드는 영문 알파벳, 숫자, 특수 문자 등을 7비트나 8비트의 이진 숫자로 표현. 각 문자에는 해당하는 고유한 숫자 값이 할당되어 있다

아스키 코드는 미국 국립표준협회(ANSI)에서 제정되었으며, 주로 영문 기반의 텍스트 데이터를 다룰 때 사용한다. 아스키 코드는 0부터 127까지의 범위에 대한 표준을 제공하며, 이 범위 내에서는 영문 알파벳 대소문자, 숫자, 특수 문자 등이 각각 고유한 숫자 값으로 매핑된다.

예를 들어, 대문자 'A'의 아스키 코드 값은 65이고, 소문자 'a'의 아스키 코드 값은 97입니다. 숫자 '0'의 아스키 코드 값은 48이고, 특수 문자 '&'의 아스키 코드 값은 38이다.

하지만, 아스키 문자 집합에 속한 문자들은 7비트로 표현하기에 128개보다 많은 문자를 표현하지 못한다. 훗날 1비트 추가된 8비트의 확장 아스키가 나왔지만 그래도 모든 문자의 수를 다루지 못한다.

EUC-KR

EUC-KR은 한글 문자를 처리하기 위한 문자 인코딩 방식. EUC-KR은 "Extended Unix Code-Korean"의 약자로, 주로 한국에서 사용되는 인코딩 방식이다. EUC-KR은 한글, 영문, 숫자, 특수 문자 등을 다룰 수 있다.

EUC-KR은 2바이트로 이루어진 고정 폭 인코딩 방식입니다. 한글 한 글자를 표현하기 위해 2바이트를 사용하며, 이러한 특성 때문에 EUC-KR은 영문과 숫자를 포함한 ASCII 문자와 호환이 가능하다. EUC-KR은 국제 표준이 아닌 국내 표준으로 개발되었으며, 주로 한국에서 사용하고 있다.

EUC-KR은 최대 2350자의 한글을 표현할 수 있으며, 기본적으로 한글 완성형(KSC 5601)에 따라 한글 문자를 처리. 이러한 특성으로 인해 EUC-KR은 주로 한글 텍스트 파일, 웹 페이지, 데이터베이스 등에서 사용된다

그러나 EUC-KR은 유니코드(Unicode)와 비교하여 한글 외의 다국어 처리에는 적합하지 않을 수 있다.

유니코드

유니코드(Unicode)는 전 세계의 모든 문자를 표현하기 위한 국제 표준 문자 인코딩 방식이다. 문자, 숫자, 기호 등 모든 언어의 문자를 일관되게 표현할 수 있는 방법을 제공한다. 이전의 문자 인코딩 방식들은 특정 국가나 지역의 문자만을 다루는 한계가 있었지만, 유니코드는 이러한 제약을 극복하고 다양한 언어와 문자를 하나의 표준으로 통합하여 사용이 가능하다.

유니코드는 각 문자에 고유한 코드 포인트를 할당하여 문자를 식별한다. 이 코드 포인트는 16진수로 표현되며 U+로 시작합니다. 예를 들어, 영문 대문자 'A'의 코드 포인트는 U+0041이고, 한글 '가'의 코드 포인트는 U+AC00입니다.

유니코드는 다양한 문자 인코딩 형식을 지원이 가능한데, 대표적으로 UTF-8, UTF-16, UTF-32 등이 있다. 각 형식은 다른 바이트 시퀀스로 유니코드 문자를 표현하며, UTF-8은 가변 길이 인코딩 방식으로 가장 널리 사용된다.

유니코드는 다국어 환경에서 소프트웨어, 웹 페이지, 데이터베이스 등에서 문자를 표현하고 처리하는 데 사용되며 다양한 플랫폼과 기기 간의 상호 운용성을 보장하고, 다국어 텍스트 처리 및 국제화에 필수적인 요소로 많이 사용하고 있는 방식이다.

비트 (Bit): 컴퓨터에서 가장 작은 데이터 단위. 이진 숫자 0 또는 1의 값으로 표현. 두 가지 상태만을 가지며, 정보의 최소 단위로 사용된다. 바이트 (Byte): 8개의 비트로 구성된 데이터 단위. 하나의 바이트는 보통 문자 하나를 나타내며, 256가지의 다른 값(0부터 255까지)을 표현할 수 있습니다. 컴퓨터에서 가장 기본적인 데이터 단위 중 하나이며, 메모리 주소를 통해 접근.

이러한 비트와 바이트는 컴퓨터가 정보를 저장하고 처리하는 데 필수적인 단위이다. 정보를 표현하고 전송하기 위해 이러한 단위들을 사용한다.

이진법

이진법은 0과 1 두 개의 숫자만을 사용하여 숫자를 표현하는 방법. 각 자릿수는 2의 거듭제곱으로 증가하며, 각 자릿수는 0부터 2-1까지의 값을 나타낸다. 예를 들어, 이진법에서 10은 2^1 + 0*2^0이므로 1010으로 표현된다.

이진법은 컴퓨터에서 디지털 신호를 표현하는 데 사용된다. 컴퓨터는 전기적 신호를 사용하여 정보를 처리하며, 이러한 전기적 신호는 on과 off 두 상태로 표현된다. 이진법을 사용하면 이러한 두 상태를 표현할 수 있으며, 따라서 컴퓨터는 이진법을 사용하여 데이터를 저장하고 처리한다

2의보수

2의 보수는 컴퓨터에서 음수를 표현하는 방법이다. 양수를 이진수로 표현할 때는 가장 왼쪽 비트가 부호를 나타내며, 0은 양수를, 1은 음수를 나타냅니다. 2의 보수는 음수를 표현할 때 사용되는데, 어떤 수를 음수로 만들기 위해서는 그 수의 모든 비트를 반전한 후 1을 더하면 된다. 이렇게 하면 양수와 음수 간의 덧셈 연산을 동일한 방식으로 처리할 수가 있다. 이러한 방법은 컴퓨터에서 음수를 표현하고 처리하는 데 사용되며, 산술 연산 및 데이터 처리에 필수적.

폰 노이만 구조는 컴퓨터 시스템을 설계하는 데 사용되는 전통적인 구조 중 하나. 이 구조는 프로그램 명령어와 데이터가 메모리에 함께 저장되고, 중앙 처리 장치(CPU)가 이러한 명령어를 순차적으로 읽어 들여 실행하는 방식을 기반.

폰 노이만 구조의 주요 특징

• 프로그램과 데이터의 메모리 통합

  • 명령어와 데이터가 동일한 메모리 공간에 저장(프로그램의 구조를 유연하게 만든다)

• 순차적 명령어 처리

  • CPU는 메모리에서 명령어를 순차적으로 읽어 들여 실행
  • 즉, 하나의 명령어를 완전히 처리한 후에 다음 명령어를 처리

• 단순한 구조

  • 단순하고 직관적인 설계

폰 노이만 구조의 장단점

장점

• 간결한 설계
  • 명령어와 데이터를 하나의 버스로 처리하여 간단하고 효율적인 설계가 가능
• 쉬운 프로그래밍
  • 명령어의 순차적 처리로 프로그래밍이 상대적으로 간편함
• 높은 유연성
  • 명령어와 데이터를 메모리에 저장하므로 프로그램을 자유롭게 수정과 실행이 가능

단점

• 병목 현상
  • 명령어와 데이터를 하나의 버스로 처리하므로 메모리 접근 속도에 따라 성능이 제약
• 효율성 저하
  • 명령어 실행과 메모리 접근이 순차적으로 이루어지기 때문에 병렬 처리가 어려움

현대 컴퓨터 구조와의 차이

• 하버드 구조 vs. 폰 노이만 구조

  • 하버드 구조는 명령어와 데이터가 별도의 메모리에 저장. 이는 명령어와 데이터를 동시에 읽어들이거나 처리할 수 있도록 만든다.
  • 반면에 폰 노이만 구조는 명령어와 데이터가 동일한 메모리 공간에 저장.

• 파이프라이닝(Pipelining)

  • 현대 컴퓨터 구조에서는 파이프라이닝 기술이 적용. 이는 CPU가 여러 단계의 처리 과정을 동시 수행이 가능.
  • 하나의 명령어를 실행하는 동안 다음 명령어를 디코딩하는 등의 동시 작업 가능. 이러한 기술은 처리량을 향상시키고 성능을 향상.

• 다중 코어(Multi-core)

  • 다중 코어 프로세서를 사용하여 병렬 처리를 지원.
  • 여러 개의 CPU 코어가 동시에 작업을 처리하여 전체적인 성능을 향상.

• 캐시 메모리(Cache Memory)

  • 현대 컴퓨터는 캐시 메모리를 사용하여 주기억장치와 CPU 간의 속도 차이를 극복.
  • 캐시 메모리는 CPU가 빠르게 액세스할 수 있는 작고 빠른 메모리.

• TCP 프로토콜은 IP 프로토콜 위에서 동작하는 프로토콜로, 신뢰성 있는 데이터 통신을 제공
• 데이터의 순서를 보장하고, 재전송 및 에러 복구 기능을 제공하여 신뢰성을 보장(데이터 전달 보증, 순서 보장)
• 신뢰 가능한 프로토콜
• 연결형 서비스 제공(연결 지향 : TCP 3 way handshake)
  • 데이터를 전송하기 전에 먼저 연결 확인을 한다
  • 물리적 연결이 아닌 가상, 논리적인 연결이다
• 현재 대부분 애플리케이션을 TCP 프로토콜 사용
• IP 프로토콜로의 문제점들을 해결

TCP 3 wah handshake

UDP 프로토콜 (User Datagram Protocol)

• UDP 프로토콜 또한 IP 프로토콜 위에서 동작하는 프로토콜(TCP와 같은 계층)
• 거의 기능이 없음
  • IP 프로토콜 + PORT 정보(같은 애플리케이션 내 구분 가능) + 체크섬(메시지 유효성 체크)
• 데이터 전송에 대한 신뢰성을 보장하지 않음. 데이터를 전송할 때 에러 검사 및 재전송을 수행하지 않음.
  • 단순하고 빠르다
• TCP보다 더 빠르고 가벼우며 실시간 응용 프로그램에서 자주 사용.
• 비 연결형 서비스 제공(TCP 3 way handshake 사용하지 않음 X)
• TCP 보다 빠르고 가벼워서, 사용자가 커스터마이징하여 최근에 많이 사용함.

cf) IP 프로토콜 (Internet Protocol)

• IP 프로토콜은 인터넷에서 데이터를 주고받는 데 사용되는 기본 프로토콜
• 데이터 패킷의 라우팅 및 전송을 담당하며, 출발지와 목적지 간의 통신
• IP 주소를 사용하여 각각의 장치를 식별하고, 데이터 패킷을 전달
• 주로 인터넷에서 데이터를 전송하는 데 사용되며, 비연결형 서비스 제공

TCP, IP 패킷 정보

• TCP 세그먼트 안에는 전송 제어, 순서, 검증 정보가 포함되어 있다

프로토콜 계층 화면

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

네트워크에서 패킷은 데이터를 전송하는 데 사용되는 기본적인 단위. 데이터를 전송할 때, 일반적으로 큰 데이터를 작은 패킷으로 분할하여 전송하고, 수신 측에서는 이러한 패킷을 다시 모아서 원래의 데이터로 재구성.

IP 프로토콜의 한계

• 비연결성
  • 패킷을 받을 대상이 없거나 수신 측 서비스 불능 상태여도 패킷 전송하는 특징이 있음(결과를 알 수 없음)
• 비신뢰성
  • 중간에 패킷이 사라지거나(중간에 서버가 망가지거나) 패킷이 순서대로 전달되지 않은 경우가 있음
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

JSON 구조

JSON은 키-값 쌍의 집합으로 구성되며, 각 키-값 쌍은 중괄호 {}로 둘러싸인 객체로 표현.

{ key : value }

{
  "name": "John",
  "age": 30,
  "isStudent": false,
  "languages": ["Java", "JavaScript", "Python"],
  "address": {
    "city": "New York",
    "zipcode": "10001"
  },
  "nullValue": null
}

또한 JSON의 데이터는 배열, Boolean, Null, 숫자, 객체, 문자열 등으로 표현이 가능하다.

• 배열

  {
    "Influencers" : [ 
        {
         "name" : "Jaxon", 
         "age" : 42, 
         "Works At" : "Tech News"
        },
        {
         "name" : "Miller", 
         "age" : 35
         "Works At" : "IT Day"
        }
    ] 
  }

• 객체 : JSON 객체 데이터는 {}(중괄호) 사이에 삽입된 한 쌍의 이름 또는 값. 키는 반드시 문자열이어야 하며, 쉼표로 구분되고, 고유 값이어야 함

{
    "Influencer" : { "name" : "Jaxon" ,  "age" : "42" ,  "city" ,  "New York" }
}

크롬 확장 프로그램

PostMan

API는 "Application Programming Interface"의 약어로, 소프트웨어 애플리케이션들이 서로 상호 작용할 수 있도록 허용하는 인터페이스를 의미. 간단히 말해, API는 두 개 이상의 소프트웨어 시스템이 서로 통신하고 상호 작용할 수 있도록 정의된 메소드 및 규약의 모음.

REST(RESTful) API

REST는 "Representational State Transfer"의 약어로, 분산 시스템에서 리소스를 관리하기 위한 아키텍처 스타일. 인터넷 상의 시스템 간의 상호 운용성(interoperability)을 제공하는 방법. REST API는 독립적 진화를 허용하는 것이 설계하는데에 지켜야할 규약이 나오게 된다.

독립적 진화를 허용한다는 것은 RESTful 서비스가 클라이언트와 서버 간의 독립적인 진화를 허용한다는 것을 의미. 서버 측의 변경이나 업데이트가 있더라도 클라이언트에 영향을 주지 않고, 클라이언트 측에서는 서버의 변경을 사전에 알 필요가 없도록 설계된다 -> 즉 REST API는 시스템 간 최소화된 의존성으로 통신하기 위한 방식.

아래의 특징들은 모두 독립적 진화를 허용함으로써 나온 내용들이다.

• 자원(리소스) 지향적 모든 자원(데이터 또는 서비스)은 고유한 식별자(URI)를 갖는다. 클라이언트는 이 URI를 통해 자원을 식별하고 상태를 조작할 수 있음

• HTTP 메서드 사용 REST API는 HTTP 프로토콜을 사용하여 자원에 대한 작업을 수행.

• 무상태(Stateless) 통신 서버는 클라이언트의 상태를 기억하지 않음. 각 요청은 모든 필요한 정보를 포함하고 있어야 한다.

• 캐싱 가능(Cachable) 클라이언트는 응답을 캐싱이 가능하다. 서버는 응답에 캐시 제어 정보를 포함하여 클라이언트가 적절하게 캐싱할 수 있도록 함.

• 계층 구조(Layered System) 클라이언트는 서버와 직접 통신할 수 있으며, 필요한 경우 중간 서버(로드 밸런서, 캐시 서버 등)를 통해 통신할 수 있음.

• 인터페이스 일관성 URI 디자인과 HTTP 메서드 사용은 일관성을 유지해야 한다. 이는 사용자가 예측 가능하고 이해하기 쉬운 API를 사용하기 위함.

REST API는 다양한 형태의 데이터를 전송할 수 있으며, JSON 또는 XML 형식의 데이터를 주로 사용. 이러한 특징들로 인해 REST API는 널리 사용되며, 웹 서비스 및 모바일 애플리케이션과 같은 다양한 소프트웨어 시스템 간의 통합에 사용.

https://www.youtube.com/watch?v=RP_f5dMoHFc REST API에 대한 발표영상 참조

일관된 인터페이스(Uniform Interface)

REST API 중 가장 중요한 특징으로 설계할 때 지켜야할 규약 중 하나이다.

• Identification of resources (리소스 식별) 각 리소스는 고유한 식별자(URI)로 식별되어야 한다.

• Manipulation of resources through representations (표현을 통한 리소스 조작) 클라이언트는 리소스에 대한 조작을 표현을 통해 수행해야 한다.

• Self-descriptive messages (자기 기술적인 메시지) 각 메시지는 해당 메시지가 어떻게 처리되어야 하는지 충분한 정보를 포함한다. 이는 HTTP 메시지의 헤더 및 상태 코드와 관련이 있음. 클라이언트는 서버로부터 받은 응답을 해석하고 처리할 수 있어야 한다. (메시지를 보고 무엇을 해야하는 건지 이해가 되어야 한다.)

• Hypermedia as the engine of application state (HATEOAS) 클라이언트는 서버로부터 받은 리소스와 연관된 하이퍼미디어 링크를 통해 상태 전이를 수행할 수 있어야 한다. 이는 클라이언트와 서버 간의 상호 작용을 동적으로 만들어내며, 서버 측 리소스의 상태 변화에 대해 클라이언트가 알지 못하더라도 동작할 수 있도록 한다

REST API가 맞는가?

네이버 서비스API Docs

< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 26 Sep 2016 09:04:44 GMT
< Content-Type: text/xml;charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Keep-Alive: timeout=5
< Vary: Accept-Encoding
< X-Powered-By: Naver
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
<
<rss version="2.0">
    <channel>
        <title>Naver Open API - shop ::'가방'</title>
        <link>http://search.naver.com</link>
        <description>Naver Search Result</description>
        <lastBuildDate>Tue, 04 Oct 2016 13:23:58 +0900</lastBuildDate>
        <total>17161390</total>
        <start>1</start>
        <display>10</display>
        <item>
            <title>허니트립 보스턴백</title>
            <link>http://openapi.naver.com/l?AAABWLsQ7CIBRFv+Z1JLzSShkYqLajRmPcG6TQRCgiNunfizdnODnJfX9N2iUMCnoKHYWh/4sSlUtmli7nCExBPRY+bo1xCZaEaTOJ6NWXaKdsSHAB2Lg8gZ2QMmybA0cuqiyx4W0ZZR2KrvJyx2CPV3RQ95fbnDT3r+Fh2kbfz5su7x8wIs7ZjgAAAA==</link>
            <image>http://shopping.phinf.naver.net/main_1031546/10315467179.jpg</image>
            <lprice>6700</lprice>
            <hprice>0</hprice>
            <mallName>허니트립</mallName>
            <productId>10315467179</productId>
            <productType>2</productType>
            <brand></brand>
            <maker>허니트립</maker>
            <category1>패션잡화</category1>
            <category2>여행용가방/소품</category2>
            <category3>보스턴백</category3>
            <category4></category4>
        </item>
        ...
    </channel>
</rss>

• self-descriptive X 응답 값이 rss 형식이지만 Content-Type을 보면 단순 text/html로 되어있음. rss에 맞는 header값이 있음. self-descriptive 하지 못하므로 REST API라 볼 수 없다. 응답 메시지만 봐도 해석이 가능해야하므로, 응답을 설명해줄 profile 링크가 있어야 한다.

• HATEOAS O

  http://search.naver.com 링크 정보가 포함되어 있음.

HAL

HAL(Hypertext Application Language) 은 RESTful API에서 사용되는 하이퍼미디어 타입 중 하나이다. 이것은 클라이언트와 서버 간의 통신을 위한 자원을 표현하기 위한 형식.

RESTful API는 상태를 전이하는데에 있어서 하이퍼미디어의 개념을 활용한다. 클라이언트는 서버에서 받은 하이퍼미디어를 기반으로 다음에 취해야 할 동작을 결정할 수 있다. HAL은 이러한 하이퍼미디어 원칙을 따르는 하나의 형식. 따라서 HAL은 REST API를 설계하고 구현할 때 사용되며, 클라이언트와 서버 간의 통신을 단순화하고 유연성을 높이는데 사용. HAL을 사용하면 클라이언트는 하이퍼미디어를 통해 가능한 동작을 자동으로 인식할 수 있으므로, API의 변경에 유연하게 대응할 수 있음.

육각형 아키텍처(Hexagonal Architecture)는 소프트웨어 설계 원칙 중 하나로, 비즈니스 로직을 중심으로 구성된 육각형 모양의 아키텍처. 이 아키텍처의 주요 개념 중 하나는 외부 세계와의 상호작용을 처리하기 위해 어댑터를 사용함.

육각형 아키텍처는 비즈니스 로직 중심으로 구성하는 계층화 아키텍처 스타일의 대안으로 볼 수 있다. 애플리케이션에 표현 계층 대신 비즈니스 로직을 호출하여 외부에서 들어온 요청을 처리하는 인바운드 어댑터와 영속화 계층 대신 비즈니스 로직에 의해 호출되고 외부 애플리케이션을 호출하는 아웃바운드 어댑터를 둔다. 비즈니스 로직이 어댑터에 전혀 의존하지 않는다는 것이 이 아키텍처의 가장 중요한 특장점임. 오히려 어댑터가 비즈니스 로직에 의존하게 된다. 주요 장점은 비즈니스 로직과 외부 세계 간의 의존성을 최소화하고 테스트가 용이하다.

구조

비즈니스 로직에는 하나 이상의 _포트_가(Port) 있다. 포트는 비즈니스 로직이 자신의 외부 세계와 상호 작용하는 방법이 정의된 작업(operation, 오퍼레이션)이다. 자바를 사용한다면 인터페이스가 포트에 해당함. 포트 종류는 인바운드/아웃바운드 두 가지이다. 인바운드 포트는 비즈니스 로직이 표출된 API로서, 외부 애플리케이션은 이 API를 통해 비즈니스 로직을 호출한다(서비스의 퍼블릭 메서드가 정의된 서비스 인터페이스). 아웃바운드 포트는 비즈니스 로직이 외부 시스템을 호출하는 방법을 담당한다(데이터 접근 작업이 정의된 리포지터리 인터페이스).

어댑터(Adapter) 는 비즈니스 로직 주변을 감싸고 있는 구조이다. 포트처럼 어댑터도 인바운드/아웃바운드 두 종류다. 인바운드 어댑터는 외부에서 들어온 요청을 인바운드 포트를 호출해서 처리한다(REST 엔드포인트, 웹 페이지가 구현된 스프링 MVC 컨트롤러, 메시지를 구독하는 메시지 브로커 클라이언트). 동일한 인바운드 포트를 여러 인바운드 어댑터가 호출할 수도 있다. 아웃바운드 어댑터는 비즈니스 로직에서 들어온 요청을 외부 애플리케이션/서비스를 호출해서 처리한다(DB 작업이 구현된 데이터 접근 객체(DAO) 클래스, 원격 서비스를 호출하는 프록시(proxy) 클래스). 아웃바운드 어댑터는 브로커에 메시지를 제공하도록 이벤트를 발행할 수 있다.

의미

이렇게 분리를 하면 비즈니스 로직만 따로 테스트하기도 쉽고, 현대 애플리케이션 아키텍처를 좀 더 정확하게 반영할 수 있게 된다. 제각기 특정한 API나 UI가 구현된 인바운드 어댑터가 비즈니스 로직을 호출하고, 비즈니스 로직은 다양한 외부 시스템을 호출하는 아웃바운드 어댑터를 호출하는 구조임. 육각형 아키텍처는 마이크로서비스 아키텍처를 이루는 각 서비스 아키텍처를 기술하는 가장 좋은 방법이다.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. by 멜빈 콘웨이

참조

올바른 MSA가 되기 위해서는 아키텍쳐와 서비스 구조, 개발 패턴도 중요하지만 올바른 조직과 프로세스가 뒷받침되어야 한다.

조직

규모가 큰 팀은 여러 팀으로 나누는 것이 좋다. 나눌수록 비즈니스 관점에서 팀의 목표는 명확해진다. 콘웨이 전략대로 애플리케이션 아키텍쳐는 그것을 개발하는 조직의 구조를 그대로 반영한다는 말따라, 조직의 구조가 마이크로서비스 아키텍쳐에 고스란히 반영되도록 설계해야 한다. 쪼개진 팀은 서비스와 느슨하게 결합이 되고 독립적으로 서비스를 개발, 배포, 확장이 가능해진다.

프로세스

폭포수 모델

폭포수(Waterfall)모델 은 단계적이며 선형적인 방식으로 소프트웨어를 개발하는 방법론으로, 각 단계가 순차적으로 이루어진다. 주요 단계에는 요구사항 정의, 시스템 설계, 구현, 테스트, 유지보수 등이 포함된다. 이러한 단계는 이전 단계의 완료 후에 진행되며, 각 단계에서 발생한 문제는 다음 단계로 넘어가기 전에 해결해야 한다. 간단하고 직관적이지만, 요구사항 변경이나 수정이 발생할 경우 유연성이 부족할 수 있습니다.

애자일 모델

애자일(Agile)모델 은 소프트웨어 개발을 위한 반복적이고 유연한 방법론이다. 애자일은 초기에 계획을 엄격하게 고정하는 대신, 변경에 대응하고 고객의 피드백을 수용하는 데 중점을 둔다. 이 방법론은 민첩한 방식으로 작업하면서 변화에 대응하는 것을 강조한다. 가장 널리 알려진 애자일 개발 방법론으로는 스크럼(Scrum), 익스트림 프로그래밍(XP), 칸반(Kanban) 등이 있다.

• 고객과의 상호작용 : 개발자와 고객 간의 지속적인 소통과 협력을 강조합니다.

• 작은 배포 단위 : 작은 기능 또는 모듈을 작업하고 이를 지속적으로 배포하여 빠른 피드백을 얻습니다.

• 반복적인 개선 : 개발 팀은 주기적인 회고를 통해 프로세스를 개선하고 효율성을 높입니다.

• 변화에 대한 대응 : 요구사항이나 우선순위가 변경될 때, 빠르고 유연하게 대응합니다.

배포 프로세스

CI/CD

CI/CD는 "지속적인 통합" (Continuous Integration, CI)과 "지속적인 배포" (Continuous Deployment, CD)의 약자로, 소프트웨어 개발 및 전개 프로세스를 자동화하고 개선하기 위한 방법론을 나타낸다.

• 지속적인 통합 (Continuous Integration, CI) : 개발자들이 코드를 지속적으로 공유하고 통합하는 프로세스를 의미한다. 여러 명의 개발자가 동시에 작업할 때 코드 통합을 늦추지 않고 자주 통합함으로써 통합 오류를 최소화하고 품질을 유지한다. 코드 변경이 이루어질 때마다 자동으로 빌드 및 자동화된 테스트를 수행하고, 통합된 코드베이스의 상태를 지속적으로 확인합니다.

• 지속적인 배포 (Continuous Deployment, CD) : 코드 변경이 통합되고 테스트를 통과하면 자동으로 프로덕션 환경에 배포되는 프로세스를 의미한다. 이를 통해 새로운 기능이나 버그 수정이 빠르게 사용자에게 전달된다. CI 이후 자동으로 배포 파이프라인이 실행되며, 프로덕션 배포를 자동화하여 인프라 및 서비스를 최신 코드로 업데이트한다.

위와 같은 조직과 개발 방법론, 배포 프로세스가 모두 이루어져야만 성공적인 MSA를 실천할 수 있다.

저장 프로시저 또는 스토어드 프로시저(stored procedure)는 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합이다. 데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로, 영구저장모듈(Persistent Storage Module)이라고도 불린다.

데이터베이스 언어 표준 SQL에서는 SQL / PSM 기준으로 책정되어 있다. 벤더(제조사) 각사 모두 정적, 동적 SQL에 커서 처리 및 제어 구문, 예외 처리 등을 포함한 사양의 확장 언어로 절차를 설명할 수 있는 DBMS를 제공하는 경우가 많다. 또한 C 언어로 작성된 컴파일한 외부 모듈(공유 라이브러리) 및 Java 클래스 라이브러리에서 함수나 클래스 메소드를 호출하는 것으로 실현하는 ‘외부 프로시저’ 기능을 구현하는 것도 있다. 저장프로시저를 사용하여 다음과 같은 장점이 있다.

하나의 요청으로 여러 SQL문을 실행할 수 있다. (네트워크에 대한 부하를 줄일 수 있다.) 미리 구문 분석 및 내부 중간 코드로 변환을 끝내야 하므로 처리 시간이 줄어든다. 데이터베이스 트리거와 결합하여 복잡한 규칙에 의한 데이터의 참조무결성 유지가 가능하게 된다. 간단히 말하면 응용 프로그램 측 로직을 가지지 않고도 데이터베이스의 데이터 앞뒤가 맞게 될 수 있다. JAVA 등의 호스트 언어와 SQL 문장이 확실하게 분리된 소스 코드의 전망이 좋아지는 것, 또한 웹사이트 등 운용 중에도 저장프로시저의 교체에 의한 수정이 가능하기 때문에 보수성이 뛰어나다. 저장프로시저를 많이 사용하면 다음과 같은 단점이 있다.

데이터베이스 제품에 대해 설명하는 구문 규칙이 SQL / PSM 표준과의 호환성이 낮기 때문에 코드 자산으로의 재사용성이 나쁘다. 비즈니스 로직의 일부로 사용하는 경우 업무의 사양 변경 시 외부 응용 프로그램과 함께 저장프로시저의 정의를 변경할 필요가 있다. 이때 불필요한 수고와 변경 실수에 의한 장애를 발생시킬 가능성이 있다 참조:위키피디아

장점

• 복잡한 데이터 로직 데이터베이스 내에서 복잡한 계산이나 로직이 필요한 경우에는 스토어드 프로시저를 활용. 데이터베이스 내에서 로직을 처리하면 네트워크 오버헤드가 감소하고, 성능 향상을 기대할 수 있음.

• 트랜잭션 관리 스토어드 프로시저는 데이터베이스 내에서 트랜잭션을 관리하는 데에 유용. 복잡한 비즈니스 로직을 트랜잭션으로 묶어 일관성을 유지하고 롤백이 필요한 경우 트랜잭션을 롤백할 수 있음.

• 보안 및 권한 관리 스토어드 프로시저는 데이터베이스 레벨에서 실행되므로 데이터베이스의 보안 및 권한 모델을 활용하여 접근 제어를 관리할 수 있음.

• 성능 최적화 스토어드 프로시저는 데이터베이스 서버에서 미리 컴파일되고 최적화되어 있기 때문에 실행 속도가 빠르다. 특히 많은 양의 데이터를 다루거나 복잡한 계산이 필요한 경우 성능 측면에서 이점을 제공.

• 데이터 정제 및 가공 데이터베이스에서 데이터를 정제하거나 가공해야 하는 경우에는 스토어드 프로시저를 사용하여 데이터를 일관되게 가공이 가능.

단점

• 데이터베이스 종속성 특정 데이터베이스 제품에 의존하며, 이로 인해 특정 데이터베이스에 강하게 결합. 이는 데이터베이스를 변경하거나 다른 종류의 데이터베이스로 이전하는 데 어려움을 초래.

• 유지보수 어려움 스토어드 프로시저는 일반적으로 별도의 언어로 작성되며, 이는 일반적으로 애플리케이션 코드와 다르다. 유지보수 어려움.

• 테스트 어려움 스토어드 프로시저의 테스트는 종종 어려울 수 있다. 일부 데이터베이스에서는 테스트를 위한 적절한 도구 및 프레임워크가 부족할 수 있음.

• 버전 관리 어려움 스토어드 프로시저는 데이터베이스 내에서 관리되기 때문에 코드 버전 관리가 어려움. 코드 변경 사항을 추적하고 롤백하는 일이 복잡함.

• 언어 제약 주로 SQL이나 특정 데이터베이스 제공 언어로 작성. 이로 인해 특정 언어의 기능이나 생태계를 활용하기 어려움.

• 이벤트 기반 구조와 부적합 이벤트의 비동기적인 흐름을 처리하는 데에는 제약이 있음.

redis 설치 : https://github.com/microsoftarchive/redis/releases

PlainFinder API 서버 : https://github.com/springboot-up-and-running/SpringBootUpAndRunning-Spring-Boot-3/tree/chapter6end/java/planefinder

스프링 데이터의 미션은 "기본적인 데이터 저장의 특수한 속성을 유지하면서 데이터에 액세스하는 친숙하고 일관된 스프링 기반 프로그래밍 모델을 제공하는 것"이라고 합니다. 어떤 데이터베이스 엔진이나 플랫폼을 사용하든 간에 스프링 데이터의 목표는 개발자가 가능한 한 간단하고 강력하게 데이터에 액세스하게 하는 것입니다.

모놀리식 애플리케이션의 장점

• 간단한 관리와 개발: 하나의 코드베이스를 관리하기 때문에 개발 및 유지보수가 간단합니다. 초기 개발 단계에서 빠르게 결과물을 얻을 수 있습니다.
• 적은 배포 및 운영 복잡성: 단일한 실행 가능한 단위로 배포되기 때문에 배포 및 운영 관리가 단순합니다.
• 로컬 개발 및 디버깅 용이성: 하나의 코드베이스에서 모든 기능을 테스트하고 디버깅할 수 있어 로컬 개발이 용이합니다.
• 설계의 간결함: 작은 규모의 애플리케이션에서는 모놀리식 아키텍처가 설계를 간소화할 수 있습니다.

모놀리식 애플리케이션이 유효한 경우

• 도메인과 도메인의 경계가 모호할 때
• 제공된 기능이 긴밀하게 결합됐고, 모듈 간 상호작용에서 유연함보다 성능이 절대적으로 더 중요할 때
• 관련된 모든 기능의 애플리케이션 확장 요구사항(Scailing requirements)이 알려져있고 일관적일 때
• 기능의 변동성이 없을 때, 즉 변화가 느리거나 변화 범위가 제한적일 때, 모두 해당될 때
• 애플리케이션의 요구사항이나 기능이 단순할 때
• 다양한 컴포넌트 간의 강력한 통합이 필요하지 않을 때