나라의 IT 잡아먹기

SAGA 패턴은 서비스 별 각 트랜잭션이 단일 서비스 내의 데이터를 갱신하는 일련의 로컬 트랜잭션을 의미한다. 첫번째 서비스의 트랜잭션이 완료되면 두번째 서비스의 트랜잭션이 동작하도록 트리거 되는 방식이라 생각할 수 있다. SAGA 패턴은 크게 두가지 방식으로 구현할 수 있다. Event / Chreography : 각 로컬 트랜잭션이 이벤트를 발생시키고, 다른 서비스가 트리거 하는 방식 Command / Orchestration : 오케스트레이터가 어떤 트랜잭션을 수행할 건지 알려주는 방식 그럼 각 방식에 대해 간단히 살펴보자. Event/Chreography 각 서비스 마다 자신의 트랜잭션을 관리하며 현재 상태를 변경한 후 이벤트를 발생시키고, 그 이벤트를 다른 서비스에 전달하는 방식으로 트랜잭션이 ..

개요 마이크로서비스 특히 분산DB 환경에서 CQRS는 매우 중요한 개념이다. CQRS는 CUD(쓰기)와 R(읽기)의 책임을 분리하는데 착안한 방식으로 아키텍처 패턴이 아닌 코드 패턴이다. 인터넷의 성장으로 인해 소수의 사용자를 위해 응용 프로그램을 만드는 것은 생각할 수 없다. 대부분의 새로운 애플리케이션은 확장성, 성능 및 가용성을 전제로 하며, 이러한 유형의 아키텍처는 서버를 확장함으로써 해소할 수 있다. 클라우드 컴퓨팅으로 마이그레이션하고 수요에 따라 Auto Scaling을 적용할 수 있다. 이는 응용 프로그램의 성능과 가용성을 해결하는 손쉬운 방법 중 하나이다. 다만, 애플리케이션 서버를 확장하는 것만으로 모든 문제가 해결되는 것은 아니다. DeadLock, TimeOut 및 속도 저하로 인해 ..

CQRS는 CUD와 R을 구분하는 방식을 의미한다. CUD : 데이터의 변형이 발생하는 경우를 Command로 표현 R : 조회와 같은 역할을 Query로 표현 각각의 역할을 구분하여 처리하는 애플리케이션을 구성하고 Event Store는 하나의 RDBMS 또는 CUD는 RDBMS, R은 NoSQL로 구성하여 중계 브로커를 통해 CUD 결과를 NoSQL과 동기화 하는 방식을 적용할 수 있다. 이는 브로커의 가용성과 신뢰도가 보장되어야 하는 위험요소가 존재하지만, 높은 성능을 낼 수 있다. CQRS가 적용되지 않은 마이크로서비스의 경우 여러 서비스에 혼합된 데이터를 조합하기 위해 Composite Application이 별도로 구성되어야 하며, 각 서비스 간 결합도가 높아지는 결과가 나타난다. 반면에 위와..

개요 마이크로서비스 아키텍처는 독립적으로 배포 및 확장 될 수 있는 서비스(Loosely Coupled)들을 조합하여 하나의 애플리케이션을 완성하는 아키텍처이다. 마이크로서비스를 적용하면 빠른 배포 주기와 장애 확산 차단, 대용량 분산환경 시스템 구축, 폴리그랏 프로그래밍 적용 등의 장점을 얻을 수 있으며, 최근 아니 2~3년 전부터 빠르게 Enterprise IT시장을 잠식해 나가고 있는 핫한 아키텍처라 할 수 있다. 마이크로서비스 아키텍처를 통해 분해된 서비스는 경량화 기반 민첩성/유연성을 보장하고, 확장성을 제공하며, 장애 탄력성을 통한 복구전략을 수립하는 등 Container Management Platform과 상통하는 아키텍처 방식으로 많은 주목을 받고있다. 다만 마이크로서비스 아키텍처는 In..

서론 애플리케이션의 성능을 높일 수 있는 다양한 방법이 있다. 때로는 어려운 과정을 거쳐 1%의 성능을 향상 시킬 수 있지만, 때로는 손쉬운 과정을 거쳐 10%의 성능을 향상 시킬 수도 있다. 캐싱 기능을 적용하면 사용자 응답시간을 향상 시키고 서버의 부하를 경감하기 위하여 다양한 영역과 위치에서 여러가지 캐싱 기술들을 적용할 수 있으며 이는 성능을 높이는 꽤 간단한 방법 중 하나이다. 일반적으로 캐싱 기능은 클라이언트와 가까울 수록 그 효과가 증대되지만, 변경에 따른 빠른 반영 등의 문제가 발생할 수 있다. [브라우저 캐싱(Cache-Control) - CDN(Static Page) - WEB(Sticky) - WAS(Session, Response, ResultSet) - Database] 지금부터 ..

서론 최근 Hardware는 Serverless로 대표되는 물리 노드 없이 사용 가능한(사실 서버리스라고 해도 아에 없는 것은 아니긴 하다) 시대가 도래했고, Software는 정형화 된 상용 소프트웨어와 미들웨어들이 이제는 오픈소스로 변화하고 있으며, 그마저도 개인만의 내재화 된 커스텀 애플리케이션을 사용하는 시대가 되었다. 그럼에도 불구하고 모든 프로젝트의 목적은 이를 서비스하는데 있기 때문에 Network는 절대 빠질 수 없는 프로젝트의 구성요소이다. 본 포스팅에서는 네트워크를 구성하는 기술 몇가지를 살펴보고자 한다. 본론 1. 웹 방화벽 (WAF) 웹 방화벽은 네트워크 방화벽과는 다르게 애플리케이션 보안에 특화되어 애플리케이션 레벨에서 http, https 프로토콜에 대한 트래픽을 감시하여 외부로..

SonarQube 정적분석으로 소스 품질 확보하기 SonarQube는 소스코드의 품질을 검증하기 위한 정적분석 도구 오픈소스로 Jenkins와 CI/CD를 통합하여 동작할 수 있다. 정적분석 도구를 적용하지 않고 애플리케이션의 검증을 진행하기 위해서는 Runtime 환경을 구성하여 UI를 기반으로 테스트를 진행해야하지만, 이는 검증에 소요되는 시간이 많이 소비될 수 있다. 따라서 정적분석도구를 적용하여 Runtime 환경을 구성하지 않고도 검증할 수 있는 환경을 마련해야 한다. 1. SonarQube 설치 a. SonarQube 설치 SonarQube를 Manually하게 설치할 수도 있지만, Docker로 기동하여 SonarQube를 기동해 보도록 하자. [root@ip-192-168-123-141 ~..

본 포스팅에서는 Kubernetes 기반 Nginx Ingress Proxy를 사용할 경우 발생할 수 있는 Request Entity Too Large Response 이슈에 대한 해결 방안을 제시한다. Infra : Private Cloud (OpenStack) PaaS : Kubernetes Ingress Controller : Nginx Proxy Web Server : Apahce Httpd Application Server : Wildfly17 Kubernetes 기반의 Application Pod에 10MB 이상의 파일을 전송할 경우 Request Entity Too Large Response 응답이 발생하며, 파일 업로드가 이루어 지지않는 현상 파일 업로드 제한에 대한 각 구간 별 진단 수행..

서론 Spinnaker는 넷플릭스에서 개발한 오픈소스 Continuous Delivery 플랫폼이다. AWS, Azure, Google Cloud 등 Public Cloud는 물론, Native Kubernetes, OpenStack 등의 Private Cloud 기반에도 적용할 수 있다. Spinnaker 역시 Jenkins와 같이 Pipeline으로 여러 Stage를 하나의 동작으로 묶어 관리할 수 있으며, UI에 강점이 있어 보다 운영 편의성을 제공한다. Spinnaker는 Jenkins 등 CI 툴에서 생성한 Base Image를 기반으로 CD를 수행하는 오픈소스 플랫폼이다. Spinnaker를 적용할 경우 Jenkins의 두 스텝 중 Base Image, Custom Image 설계/빌드가 완료..

서론 본 포스팅에서는 쿠버네티스에서 포드 기동 장애 발생 시 트러블슈팅에 활용할 수 있는 유용한 명령어에 대해 살펴본다. 쿠버네티스에서는 포드의 장애 발생 시 kubectl logs, kubectl describe 등의 명령어를 사용하여 어느 정도 수준은 분석이 1차로 가능하다. 다만 logs가 발생되지도 않으면서 describe에 표출되는 정보 역시 무관하거나, 막연한 정도의 수준으로 표출되는 경우 포드의 상태를 검증하는데 어려움이 있을 수 있다. 이때 포드 기동 문제를 검증하기 위해 아래와 같은 3가지 유용한 명령어를 활용하여 트러블슈팅을 진행할 수 있다. 본론 1) kubectl edit deployment [deployment_name] 먼저 kubectl edit를 활용하는 방법이다. 다음은 현..