아키텍처 - 마이크로서비스, MSA - JSON (RFC-8279)

 

• 원래 JSON 함수는 3단계로 동작
  1. JSON을 C코드가 쉽게 처리가능한 내부용 바이너리 포맷으로 파싱
  2. 요청한 작업 수행. 특정 필드를 찾거나 JSON을 수정하거나 하는 등
  3. 작업이 JSON을 변경했다면, 내부 바이너리 포맷을 RFC-8279 JSON 문자열로 바꿔서 출력 또는 저장
• 2단계 말고 1과 3은 오버헤드임

 

제이슨(JSON, JavaScript Object Notation)

 

o 웹과 컴퓨터 프로그램에서 용량이 적은 데이터를 교환하기 위해 데이터 객체를 속성·값의 쌍 형태로 표현하는 형식.

 

 o 자바스크립트(JavaScript) 토대로 개발되었다. 

 

 o 여러 프로그래밍 언어에도 사용할 수 있어 독립형 언어이며 텍스트로 기술하여 사람도 쉽게 읽고 작성할 수 있다.

 

 o 웹 브라우저와 웹 서버 간 비동기 통신, 웹 서버 간의 데이터 교환 등에 주로 사용된다. 

 

  o IETF RFC 7159(The JavaScript Object Notation(JSON) Data Interchange Format) 표준과 ECMA-404(The JSON Data Interchange Syntax) 표준으로 제정되어 있다.

  o JSON은 자바스크립트(ECMA-262 3rd edition, 1999)를 토대로 개발되었으며, 2000년대 미국의 컴퓨터 프로그램 개발자인 더글라스 크락포드(Douglas Crockford)가 확산시켰다. 

 

  o 특히, 웹 브라우저에서 비동기 처리에 사용되는 에이잭스(AJAX)가 데이터 교환 형식으로 JSON을 사용하면서 널리 알려졌다. 

 

  o AJAX가 기존 사용하던 XML 기반의 메시지 포맷은 시작 태그와 끝 태그를 포함하여 메시지 크기가 커지는 문제가 있었다. 

 

  o 이를 해결하기 위해 JSON으로 대체하였다. 대부분의 웹 기반 애플리케이션에서 데이터 교환 형식으로 XML 대신 JSON을 활용한다.

 

 

1. JSON이란 무엇인가? 

  • avaScript Object Notation라는 의미의 축약어로 데이터를 저장하거나 전송할 때 많이 사용되는 경량의 DATA 교환 형식

  • Javascript에서 객체를 만들 때 사용하는 표현식을 의미한다.
  • JSON 표현식은 사람과 기계 모두 이해하기 쉬우며 용량이 작아서, 최근에는 JSON이 XML을 대체해서 데이터 전송 등에 많이 사용한다.
  • JSON은 데이터 포맷일 뿐이며 어떠한 통신 방법도, 프로그래밍 문법도 아닌 단순히 데이터를 표시하는 표현 방법일 뿐이다.

 

 

2. JSON 특징
  • 서버와 클라이언트 간의 교류에서 일반적으로 많이 사용된다.
  • 자바스크립트 객체 표기법과 아주 유사하다.
  • 자바스크립트를 이용하여 JSON 형식의 문서를 쉽게 자바스크립트 객체로 변환할 수 있는 이점이 있다.
  • JSON 문서 형식은 자바스크립트 객체의 형식을 기반으로 만들어졌다.
  • 자바스크립트의 문법과 굉장히 유사하지만 텍스트 형식일 뿐이다.
  • 다른 프로그래밍 언어를 이용해서도 쉽게 만들 수 있다.
  • 특정 언어에 종속되지 않으며, 대부분의 프로그래밍 언어에서 JSON 포맷의 데이터를 핸들링 할 수 있는 라이브러리를 제공한다.

 

 

3. JSON의 장점
  • 단순 텍스트이며 표기가 직관적이므로 사람이 이해하기 쉽습니다.
  • 속성과 값 쌍으로 이루어지므로 CSV와 다르게 특정 값이 어떤 의미를 지니는지 이해하기 쉽습니다.
  • XML의 요소는 <name>Kim</name> 과 같이 여는 태그가 있으면 닫는 태그가 있기 때문에 데이터 자원 소모가 상대적으로 크지만 JSON은 key : value 방식이므로 상대적으로 데이터 자원 소모가 적습니다.
  • 거의 대부분이 HTTP를 이용한 웹 환경에서 데이터 교환이 이루어 지므로 데이터의 크기가 적다는 것은 매우 큰 의미를 지닙니다.
  • 특정한 언어나 플랫폼에 독릭접이므로, 규칙만 지켜주면 어떤 시스템간이든 교환이 가능합니다.
  • 대부분의 언어 및 플랫폼에서 JSON을 더욱 정교하게 다루기 위한 api를 제공하며, 브라우저에서도 json 파서를 내장하고 있습니다.

 

 

4. XML vs JSON
 

데이터를 나타낼 수 있는 방식은 여러가지가 있지만, 대표적인 것이 XML이고, 이후 가장 많이 사용되는 것이 아마도 JSON일 것이다.

 

  o XML
   데이터 값 양쪽으로 태그가 있다.
   (HTML을 근본으로 했기에 태그라는 것이 없을 수가 없는데, 그 태그를 줄인다 해도 최소한 표현하려면 양쪽에 몇글자씩이 있어야 한다.)

 

  o JSON
   태그로 표현하기 보다는 중괄호({}) 같은 형식으로 하고, 값을 ','로 나열하기에 그 표현이 간단하다.

 

5. JSON 문법

  o JSON은 자바스크립트(JavScript)의 구문 형식을 따르지만, C, C++, C#, 자바(Java), 파이선(Python) 등의 프로그램 언어와도 함께 사용되어 플랫폼과 프로그래밍 언어 면에서 독립적인 언어이다. 

  o 데이터 구조는 속성(name)과 값(value) 한 쌍으로 구성되며, “속성: 값” 형식으로 데이터 객체를 표현한다.
값(value)의 자료형으로 수(number), 문자열(string), 객체(object), 배열(array), 참/거짓(boolean), 또는 빈값(null)이 지원된다. 

  o 배열(array)은 대괄호([ ])로, 객체는 속성·값 쌍의 집합으로 중괄호({ })를 사용하여 표현하며, 객체 간의 구분은 쉼표(,)로 한다. 

 

o 자바 스크립트 언어에 익숙한 사람이라면 다음의 규칙은 매우 익숙할 것 입니다.

 • JSON 객체는 중괄호 블록 "{", "}" 으로 표기합니다.
 • JSON 배열은 대괄호 블록 "[", "]" 으로 표기합니다.
 • 속성(Key)과 값(Value) 쌍으로 이룹니다.
 • 속성과 값이 쌍을 이룰 때 콜론으로 구분하며 속성 : 값 형태로 표기합니다.
 • 속성은 쌍따옴표(")로 묶어 표기하며, 값은 자료형에 따라 표기 방법이 달라집니다. ex) "age" : 3
 • 속성이 여러개인 경우 ,(콤마)로 구분합니다.

o 아래는 ‘paul’이라는 사람에 대한 정보(나이, 주소 등)를 JSON 형식으로 표현한 예시이다.

 

‘name’ 속성에 대한 값은 ‘paul’이며, ‘age' 속성에 대한 값은 ‘27’이다. 

전화번호(phone)는 집(home) 전화와 휴대폰(cellphone) 객체 2개를 갖는 배열로 표현한다.

 

{
"name": "paul",
"age": 27,
"address": {
"Address": "11Ro Seoul Korea"},
"phone": [
{ "type": "home",
"number": "02-000-0000" },
{ "type": "cellphone",
"number": "010-0000-0000" },
],
"children": [],
"spouse": null
}

 

https://cafe.naver.com/rapid7/3624

MSA와 NoSQL을 무슨 관련인가?

 

마이크로 서비스MS의 반대 개념인 한통구조Monolithic의 핵심에는 단일 데이터베이스, 다시 말해 전사적 데이터 모델링[1]에 의존하는 데이터 관리 프로그래밍 방식 해결과 밀접하게 관련이 있기 때문이다. 그래서, 이를 이해하지 못하거나 NoSQL을 위 문제와 연관지을 수 없다면 아키텍트 관점이 없다고 보기 때문이다.

 

둘째로 아키텍처 측면에서 보는 개발자(혹은 나처럼 개발자 출신인 …)들이 있다. 상대적으로 소수인데, 대체로 아래와 같은 고민을 목격한 바 있다.

• 우리 조직에서 이것을 어떻게 할 수 있을까? (한숨부터 나온다.)
• 나는 하고 싶은데, 주변에서 따라주지 않는다. (설득으로 지쳐가며 시간 보내고 싶지 않은데…)
• 거품이 낀 말이다. (그냥 하면 되는데…)
• 서비스를 어떻게 나눌까? (참조할 기준이 있으면 좋겠는데…)

 

나에게 MSA는 RESTful 아키텍처 다음 여정

프레임워크[2]가 아닌 프로토콜 수준의 제약이 주는 자유도가 시스템 수준의 객체(혹은 컴포넌트) 사이에 느슨한 연결Loosely Coupled을 가능하게 해준다.

 

왜 RESTful 아키텍처가 아니고 MSA인가?

 

• 운영조직은 바뀌지 않았다. 만든 사람이 따로 있다보니, 전부터 운영하던 개발자들이 완전히 바뀐 구조와 기술을 단시간에 학습하는 일은 불가능하다. 이런 상황에서 인수인계란 개발자를 궁지로 모는 일이란 사실을 당시 관리자들은 전혀 알지 못했다.[4]
• 단일 데이터 모델을 그대로 두고 프론트 API 영역만 RESTful 아키텍처로 변경하는데 그쳤다. 진정한 복잡도는 그대로 두고 당장 급한 부분 즉, 모바일 대응만 할 수 있게 조치했다. 당장 비즈니스는 견디지만, 수정은 점점 더 어려워지는 레거시로 변하는 현상은 오히려 가중된다. 가중되는 레거시를 드러내는 증상은 (1) 필연적인 하드코딩, (2) CDC나 EAI 솔루션에 의존해서 데이터를 밤에 복제하는 일, (3) 새로운 비즈니스 상황에 대해서 가능한지 아닌지 아무도 즉답을 못해주는 현상 등이 있다.

MSA를 적용 혹은 실현했다고 자신있게 말하려면 무엇이 필요한가?

 

• 데이터베이스가 물리적뿐만 아니라 논리적으로도 완전히 나눠져 있는가?
• 서로 다른 서비스를 개발하는 개발자와 인프라 운영자 사이 혹은 개발팀간 소통이 잘 되고 있는가? 데브옵스라 할 정도는 아니라도 최소한 CI 환경은 돌아가는가? 다시 말해 Jenkins는 당연하고, Git을 쓰고 Jira나 Github/lab은 활발히 쓰고 있는가?

 

첫 항목은 어쩌면 MSA에서 마이크로 서비스의 적당한 단위에 대한 훌륭한 안내자가 될 수 있다. 비즈니스(혹은 도메인 지식)에 맞춰 자른 데이터베이스 단위가 마이크로 서비스 단위로 쓰일 수 있다. 주의할 점은 여기서 자른다는 말은 전통적으로 DB 모델러가 정의하는 주제 영역 구분과는 다른다. 그 정도가 아니라 ERD를 개별적으로 그리는 수준의 분리이다.

두번째는 데브옵스 구축이라는 말로 대신할 수도 있다. MSA 구축과 데브옵스는 어쩌면 불가분의 관계다. 필자는 현재도 지속하고 있는 2년 가까운 경험에서 이 부분을 매우 중요하게 다뤘고, 그 이야기를 작년에 마이크로 서비스 구축 경험이란 글로 공유한 바 있다. Micro Service, Docker로 할 수 밖에 없었던 사연 역시 같은 공간에서 벌어진 일에 대한 다른 관점을 기록하고 있다.[5]