쵸코쿠키의 연습장

CQRS(Command Query Responsibility Segregation : 명령 조회 책임 분리 서비스의 성능향상을 위해 서비스 Instance를 Scale Out하여 여러 개로 실행한 경우에 데이터 읽기/업데이트 작업으로 인한 리소스 교착 상태가 발생할 수가 있습니다. CQRS 패턴이라고 합니다. Command Query Responsibility Segregation, 명령 조회 책임 분리 패턴입니다. CQRS는 기존의 일반적인 개념이었던 동일한 저장소에 데이터를 넣고, 입력/수정/삭제/조회하는 방식에 도전하는 흥미로운 패러다임을 도입하고 있습니다. 일반적으로 사용자의 비즈니스 요청은 시스템 상태를 변경하는 명령과 시스템의 상태를 가져오는 조회의 두 부분으로 크게 나눌 수 있습니다. 사실 ..

약한 참조 약한 참조는 원시 포인터 해제에 영향을 끼치지 않습니다. 약한 참조 카운트는 약한 참조의 수를 저장하는 데 사용됩니다. 약한 참조로 참조되는 개체는 강한 참조 카운트가 0이 될 때 소멸됩니다. 순환 참조 문제의 해결책입니다. #include #include "Persion.h" int main() { std::shared_ptr owner = std::make_shared("pp"); std::weak_ptr weakOwner = owner; return 0; } 약한 포인터로 공유 포인터 만들기 #include #include "Persion.h" int main() { std::shared_ptr owner = std::make_shared("pp"); std::weak_ptr weakOw..

서비스별 데이터베이스 Soa와 구분되는 Msa 특징으로 각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터를 소유하고 있다는 것입니다. 그렇기 때문에 이러한 소유한 데이터는 다른 서비스에 직접 호출되게 하지 않고, 자신의 API를 통해서만 액세스 할 수 있습니다. 주문서비스가 주문수행을 위해 고객 정보를 필요로 한다면, 바로 고객 테이블을 질의를 할 수 없습니다. 반드시 고객 서비스의 API를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다. 여러 서비스 간에 데이터 일관성을 유지하는 방법 두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처..

std::shared_ptr #include #include"Vector.h" int main() { std::shared_ptr vector = std::maked_shared(10.f, 30.f); // ... } 두개의 포인터를 소유합니다. 데이터를 가리키는 포인터와 제어 블록을 가리키는 포인터입니다. std::unique_ptr와 달리, 포인터를 다른 std::shared_ptr와 공유할 수 있습니다. 참조 카운팅 기반이라 할 수 있습니다. 원시 포인터는 어떠한 std::shared_ptr에게도 참조되지 않을 때 소멸됩니다. 포인터 재설정하기 std::shared_ptr vector = std::maked_shared(10.f, 30.f); std::shared_ptr copiedVector = ..

마이크로 서비스 통신 방법 Rest API는 클라이언트에서 서버 쪽에 존재하는 마이크로서비스를 호출할 때 기본 통신방법이 되며, 다양한 클라이언트 채널 연계나 외부에 API의 공개를 원활하게 하기 위한 방법으로는 API G/W를 사용하는 것을 살펴봤습니다. 제일 먼저 검토해야 할 방법은 Rest API 같은 동기식 호출입니다. Sync 방식이라고도 합니다. 동기식 호출은 Request를 하면 바로 Response가 오는 방식을 말합니다.모바일 UI에서 상품서비스에 Post 방식의 요청을 하고, 상품은 주문 서비스에 Get 방식의 동기호출을 하고 있습니다. 그에 따라 바로 응답이 발생하고, 200이라는 OK 코드도 받아오는 것을 볼 수 있습니다. 바로 요청하면 응답이 오는 패턴이기 때문에 가장 많이 쓰이는..

자동 메모리 관리 std::shared_ptr를 배우기 전에, 자동 메모리 관리에 관해 알아야 합니다. 주로 쓰는 두가지 기법이 있었습니다. 첫번째는 가비지 컬렉션이고, 두번째는 참조 카운팅이 있습니다. 가비지컬렉션은 Java와 C#에서 활용되고 있으며, 참조 카운팅은 Swift와 오브젝트 C에서 지원됩니다. 가비지 컬렉션 보통 트레이싱 가비지 컬렉션을 의미합니다. 메모리 누수를 막으려는 시도에서 나오게 되었습니다. 주기적으로 컬렉션을 실행합니다. 충분한 여유 메모리가 없을 때 컬렉션이 실행됩니다. 스케쥴에 따라 또는 수동으로도 실행 가능합니다. 매 주기마다 GC는 루트를 확인합니다. 즉, 전역 변수, 스택, 레지스터들을 확인합니다. 힙에 있는 개체에 루트를 통해 접근할 수 있는 지 판단합니다. 접근할 ..

Presentation Layer Presentation Layer에서 가장 많이 쓰이는 패턴은 Model View Controller로 이루어진 MVC 패턴입니다. MVC 모델은 초기 컨트롤러와 모델이 어떤 기술을 쓰느냐에 따라 발전해왔습니다. 최근에는 JSP가 View의 역할을, POJO가 모델의 역할, 서블릿이 이 두 개의 요소를 연계하는 컨트롤러의 역할을 수행하는 방식으로 발전해왔습니다. 그렇지만 현재는 JSP 서블릿뿐만 아니라 웹, 모바일, 태블릿, 인터넷, PC, 셋톱박스와 같은 다양한 인터페이스의 등장으로 인해서 이를 지원하기 위한 다양한 화면 플랫폼이 등장했습니다. Spring의 Thymeleaf나 페이스북이 공개한 React, 기존에 유명했던 ANGULARJS, 그리고 Vue.js 등의 ..

std::unique_ptr 포인터 대신 아주 많이 활용되고 있습니다. 직접 메모리 관리하는 것 만큼 빠릅니다. Resource Acquisition is initialization 원칙에 잘 들어맞습니다. 자원 할당은 개체의 수명과 관련되어 있습니다. 생성자에서 new를 하고 소멸자에서 delete를 해주어야하는데 유니크 포인터 멤버 변수가 알아서 동작하여 줍니다. 따라서, 실수하기 어려우며, 다양한 곳에서 활용하여도 좋습니다. 예제 #include #include #include "UsingUniquePointersExample.h" #include "MyVector.h" using namespace std; namespace samples { void UsingUniquePointersExample..

Layer 간의 의존성 UI 클라이언트가 Presentation Layer를 이용하고, Presentation 층이 Business Logic 층을 호출하고, Business Logic 층이 Data Access 층을 호출하고, Data Access 층이 저장소를 접근하게 됩니다. 어플리케이션에서 모든 영역이 중요하겠지만 가장 핵심적인 부분은 아무래도 어플리케이션이 제공하는 주요 서비스의 업무 로직을 담고 있는 Business Logic 층입니다. Presentation 층과 Data Access 층은 기술 트렌드에 따라 다양하게 교체 변화 가능하나, 핵심 비즈니스 기능은 한 번 정의되면 잘 변경되지 않습니다. 따라서 시스템의 확장성과 유연성을 높이기 위해 Layered Architecture는 이러한 ..

reset() int main() { std::unique_ptr vector = std::make_unique(10.f, 30.f); vector.reset(new Vector(20.f, 40.f)); vector.reset(); } 이거 말고 nullptr를 써야할까? vector.reset(); vecotr = nullptr; 두 코드의 의미는 같습니다. nullptr가 reset() 보다 가독성이 더 좋습니다. reset()은 vector가 원시 포인터가 아님을 분명하게 보여줍니다. 따라서, 취향에 맞게 구현하여도 무방하다고 합니다. reset()은 결국 포인터를 교체하는 것을 의미합니다. std::unique_ptr가 재설정 될 떄, 소유하고 있던 원시 포인터는 자동으로 소멸됩니다. get() ..

Tier와 Layer Tier는 물리층을 의미하며, Layer는 논리층을 의미합니다. Tier는 물리적인 장비, 서버 컴퓨터가 될 수 있습니다. Layer는 이러한 Tier 내부의 논리적인 분할을 의미합니다. 1:1이 될 수도 있지만 Tier의 내부를 제공하는 기능 성격에 따라 논리적 구분을 할 수 있습니다. 여기 어플리케이션 서버라는 중간층은 세 가지 Layer로 구별될 수 있습니다. 가장 일반적인 어플리케이션 Layer인 Presentation, Business Logic, Data Access층으로 나눠질 수 있습니다. Layered Architecture Layered Architecture는 설계자들이 복잡한 시스템을 분리할 때 흔히 사용하는 패턴 중 하나로 상위는 하위를 호출하여, 상위는 하위..

스마트 포인터 - unique_ptr - shared_ptr - weak_ptr 예시: 포인터 #include "Vector.h" int main () { Vector* myVector = new Vector(10.f, 30.f); // delete myVector; return 0; } 항상 포인터를 생성하는 순간, delete를 구현해주어야 합니다. 하지만 프로그래머들이 가끔 실수를 할 수 있습니다. 더 이상 포인터가 필요하지 않을 때 메모리를 해제해야 합니다. 스마트 포인터를 쓰면 delete를 직접 호출할 필요가 없습니다. 그리고 가비지 컬렉션보다 빨라집니다. unique_ptr #include #include "Vector.h" int main() { std::unique_ptr myVector..

어플리케이션 아키텍처 우선 마이크로서비스 Architecture를 내외부로 구분했을 때 외부 Architecture가 Architecture를 이루는 구성요소의 관계를 설명한다면, 내부 Architecture는 구성요소 자신의 내부 구조를 상세히 정의하는 것을 말합니다. 이런 어플리케이션의 내부 구조를 정의하는 활동을 Application Architecture라고 하는데요. 마이크로서비스의 Inner Architecture, 다른 말로 하면 Application Architecture에 대해 자세히 살펴보도록 하겠습니다. Application Architecture는 어플리케이션이 동작하는 구조, 즉 동작하는 공통 메커니즘을 정의하는 것입니다. 웹 어플리케이션 구조 클라이언트 쪽에 브라우저 및 모바일 ..

std::array 요소 수를 기억하지 않습니다. 단순히 C 스타일 배열을 추상화한 것이라 생각하면 좋습니다. 요소 수를 기억하지 못하므로 std::array가 아쉬울 수 있습니다. 아마 std::algorithm을 쓸 수 있고, 반복자를 쓸 수 있어서 나온 것일까요. 현재 사이즈를 접근할 필요가 없고, 고정형 크기의 배열이 필요하다면 선택지로 사용할 수 있는 컨테이너라는 생각이 들었습니다. 다만 프로젝트에서 그러한 경우가 그렇게 많지 않을 것으로 생각이 되었는데, 만약 그러한 상황이어도 굳이, 익숙하지 않은 array를 꺼내지 않아도 얼마든지 다른 방법으로도 충분히 해결 가능합니다. 이러한 컨테이너가 있다는 것을 기억해두고 좋은 기회가 오면 활용해보는 것도 좋을 것 같습니다. #include int m..

인증, 인가 API 게이트웨이에서 인증 인가를 처리할 수 있습니다. 그런데 그것은 자체 기능으로 처리하지 않고 OAuth 서비스를 사용합니다. OAuth는 각각의 리소스 서비스가 자체적으로 인증 인가를 처리하는 것이 비효율적이고 독립성을 떨어뜨리기 때문에 등장한 서비스입니다. 동작 메커니즘을 살펴보면 우선 사용자가 API 게이트웨이를 통해 OAuth에게 각 서비스 리소스에 액세스할 권한이 있는지 요청합니다. 그럼 OAuth 서비스는 인증된 사용자인지 이 리소스에 권한이 있는지 확인하고 그것이 확인됐다면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급해 줍니다. 그러면 API 게이트웨이는 다시 요청을 준비하고 각각의 리소스 서비스는 이런 리퀘스트가 액세스 토큰이 있는지 판단하여 리소스를 허용하는 것입니다..

범위 기반 for 반복문 int scores[3] = { 10, 20, 30}; for ( int score : scores) { std::cout

마이크로 서비스의 역사 우선 기반 서비스가 어떠한 과정을 거쳐서 발전되었는지 마이크로서비스 발전 과정을 살펴보도록 하겠습니다. 그때부터 소프트웨어 업계가 거대한 계획이나 프로세스 대신 빠른 실패와 피드백을 기반으로 하는 실용적인 실천 방법을 선호하게 되었습니다. 우선 AWS가 IaaS 개념으로 2006년도에 EC2를 발표했고 넷플릭스가 스트리밍 사업을 시작하고 아마존의 클라우드 서비스인 AWS로 시스템을 이동하기 시작했습니다. 그러다가 데이터베이스 스토리지가 한 번 크게 망가져서 서비스가 큰 장애를 겪게 됩니다. 이걸 계기로 넷플릭스는 큰 덩어리의 모노리식 시스템에서 마이크로서비스 기반의 시스템으로의 전환을 시작했다고 합니다. 그런데 넷플릭스는 그런 마이크로서비스 기반 시스템을 만들고 운영하면서 여러 어..

set 자동 정렬되는 컨테이너입니다. 키들을 저장하고, 이진 탐색 트리를 기반으로 합니다. 탐색 시간은 O( log n ) 입니다. 삽입과 제거가 빈번해지면 느립니다. undorderd_set std::map과 동일한 문제로 나오게 되었습니다. 자동 정렬되지 않는 set이라고 생각하면 됩니다. 해쉬 테이블 기반으로 합니다. 탐색시간이 O(1) 이며 최악의 경우 O(n) 입니다. 버킷 때문에 메모리 사용량이 증가할 수 있습니다. #include #include #include #include #include "SpeedTestExample.h" using namespace std; namespace samples { void SpeedTestExample() { // RUN THIS EXAMPLE IN R..

인프라 영역 MSA에서 인프라 영역은 클라우드 환경을 의미합니다. 인프라로서의 서비스, 즉 IaaS, 플랫폼으로서의 서비스, 즉 Paas로 나눠집니다. 힘들게 구축했던 인프라를 세계적인 플랫폼 사업자들이 자동화된 기능으로 제공합니다. 예를 들면 시스템의 자원 구성, 할당, 관리, 모니터링 등 일련의 작업들을 몇 번 만의 버튼 클릭만으로 자동화, 시각화해서 제공하고 있습니다. 인프라 영역에서 클라우드 사업자가 제공하는 IaaS를 선택할지, 기존 베어 메탈 장비나 가상 머신인 VM을 선택할지 결정해야 합니다. 그다음 위에 플랫폼 영역에서는 마찬가지로 클라우드 사업자가 제공하는 Paas를 선택할지 또는 직접 오픈 소스로 프라이빗한 Paas를 구축할지 결정해야 합니다. 각각의 관계가 어떤 것을 선택할지라도 유연..

unordered_map std::map은 자동으로 정렬되는 컨테이너입니다. 그래서 요서 삽입, 제거가 빈번할 경우에는 성능이 저하됩니다. 그래서 그부분을 해결하기 위해 나온 것이 unordered_map입니다. #include #include #include int main() { std::unordered_map scores; scores["nana"] = 60; scores["mocha"] = 70; scores["coco"] = 100; for (auto it = scores.begin(); it != scores.end(); ++it) { std::cout first