나라의 IT 잡아먹기

개요 앞선 포스팅에서 마이크로서비스 분산DB 환경에서 데이터 조회를 위한 방안에 대해 살펴보았다. 자세한 내용은 아래 포스팅을 참고하기 바란다. 마이크로서비스 분산DB 설계 (분산DB 조회 설계) : https://waspro.tistory.com/724 마이크로서비스 아키텍처의 기준과 DB 분리 : https://waspro.tistory.com/718 앞서 살펴본 분산 DB 조회 설계에서는 이미 분할된 데이터에 대한 접근을 어떻게 효과적으로 할 것이냐에 포커싱을 맞추었다면, 이번 포스팅에서는 어떻게 데이터를 모놀리식 DB에서 분할할 것인냐에 대해 알아보도록 하자. 중요한 포인트는 바로 특정 데이터가 어느 분산 DB에 존재하는 것이 좋은지에 대한 결정을 내리는 일이다. 모놀리스에서 서비스를 분리할 때 ..

개요 앞선 포스팅에서 마이크로서비스 환경의 데이터베이스 분리 기준에 대해 알아보았다. 모놀리식 어플리케이션을 마이크로서비스 아키텍처로 전환하기 위해서는 단일DB를 분산DB 형태로 분리해 나가야 한다. 물론 한번에 모든 DB를 서비스 별로 쪼개는 것은 리스크를 확대시킬 수 있다. 서비스간 결합도가 낮은 마이크로서비스로부터 하나씩 DB를 분리해 나가면서 점진적 결합도를 낮추는 것이 무엇보다 중요하다는 점을 기억하고 다음 포스팅을 읽어주었으면 한다. 마이크로서비스 아키텍처의 기준과 DB 분리 : https://waspro.tistory.com/718 데이터베이스의 분리는 단순하게 DB의 스키마를 나누는데에 그치지 않는다. 하나의 프로젝트에서 분석/설계라는 과정을 거쳐 어플리케이션과 테이블, 인터페이스를 정의하..

개요 최근 3년 사이 마이크로서비스 아키텍처의 급격한 유행에 따라 많은 프로젝트에서 MSA로의 전환을 시도하고 있으며, 성공적으로 전환한 케이스가 있는 반면, 실패한 경우도 종종 발생하고 있다. 포스팅의 시작점에서 우리가 말하는 성공적인 마이크로서비스 전환 사례란 무엇인지에 대해 알아보도록 하자. 마이크로서비스 아키텍처의 성공기준 RESTFul API가 적용된 프로젝트 독립적인 배포가 가능하도록 결합도를 낮춘 프로젝트 클라우드가 적용된 확장성, 가용성이 확보된 프로젝트 자동화된 배포 체계가 갖추어진 프로젝트 DevOps 조직 체계를 적용한 프로젝트 ...... 마이크로서비스로의 전환이 진행중인 또는 완료된 프로젝트 사례들을 살펴보면 위와 같은 공통의 목표를 달성해 내고자 했을 것이다. 다만, 이와 같은 ..

개요 급격하게 확대되고 있는 오픈소스 시장에서 소프트웨어 업그레이드를 이용한 공격사례가 증가하고 있다. 어떠한 악성 코드가 반영되어 있는지 확인하기 어렵고, 어떠한 소프트웨어가 설치되어 있는지 확인하기 어려운 상태에서 인터넷 상에 떠도는 오픈소스 소프트웨어를 업그레이드 하거나, 파일을 반입하는 것은 공격의 대상으로 타켓팅 될뿐 아니라, 때로는 심각한 정보들를 유출하는 심각한 문제를 초래하기도 한다. 따라서 오픈소스를 구축하고 운영할 경우 업그레이드 관리에 많은 비용과 시간을 투자해야 함을 반드시 인지해야한다. 도커 이미지 역시 마찬가지이다. 이미지 내부에는 어떠한 파일과 소프트웨어가 설치되어 있는지 판단하기 어려운 상태에서 반입하는 경우가 많다. 따라서 이미지는 도커 허브와 같은 공식 사이트에서 검증된 ..

서론 DevSecOps란 개발, 보안, 운영이라는 세가지 중요한 측면을 원활하게 수행하기 위한 방식 또는 조직을 의미한다. DevOps에서 확장된 개념이라 볼 수 있다. 이는 전체 어플리케이션 라이프 사이클을 공동 책임으로 관리한다는 조직관리 관점에서 확장된 것이지만, 사실 확장이라는 개념에 어울리지 않게, 그간 우리는 보안이라는 요소를 기술의 Sub System 정도로 취급해 왔던 것이 사실이다. 특히 컨테이너 기술에 대한 이해가 높지 않은 상황에서 보안을 논의하기 보다는 기술의 완성도를 높이는데에만 집중해 오지 않았나 싶다. 최근 프로젝트에서 DevSecOps가 논의된 적이 있다. 당시 마이크로서비스를 설계하는 아키텍처 입장에서 나부터 보안에 대한 고려가 깊지 않았다는 생각을 하게 됐다. 이제는 그 ..

서론 마이크로서비스 환경에서 서비스를 잘 모델링하는 것 만큼 중요한 것이 바로 컨테이너 이미지를 설계하는 것이다. 어플리케이션을 잘 설계하여 소스도 경량화 되고, 확장성을 확보했다고 생각할 수 있지만, 사실은 어플리케이션을 감싸고 있는 컨테이너 이미지가 최적화되어 있지 않을 경우 어플리케이션의 경량화는 의미가 퇴색될 수 있다. 지금부터 살펴볼 내용은 컨테이너 이미지를 생성할때 고려해야 할 사항에 대해 본인의 노하우를 섞어 알아보도록 하자. 첫번째, 경량화 역시나 첫번째로 고려해야 할 부분은 바로 컨테이너 이미지의 경량화이다. 이미 수도 없이 강조했지만, 컨테이너 이미지는 작으면 작을 수록 좋다. Scalability를 강조하기 위해서는 무엇보다 가벼운 이미지가 중요하며 경량화를 위한 노력을 무엇보다 지속..

docker container는 host kernel을 공유하지만, 때로는 구분된 limit 정보를 구성해야할 경우가 발생한다. 예를 들어, nofile(open files)나 nproc(max user processes)의 경우 application의 요구사항에 따라 또는 솔루션의 요구사항에 따라 변경하여 적용할 필요가 있다. 아래는 docker container를 사용할 경우 ulimit을 일괄 변경하는 방법에 대해 알아보도록 하자. systemctl show docker 먼저, docker의 variable 정보를 확인한다. [root@ip-192-168-114-198 ~]# systemctl show docker Type=notify Restart=always NotifyAccess=main Re..

Kubeflow 란? Kubeflow는 Kubernetes 환경에서 머신러닝을 분석할 수 있는 오픈소스 기계 학습 플랫폼이다. Kubeflow를 이용하면, 손쉽게 분석환경을 구축할 수 있으며, 직접 커스터마이징한 이미지를 구동하여 접속할 수 있는 대시보드 환경을 제공한다. kubeflow가 제공하는 다양한 기능에 대해서는 하나씩 구축해 나가면서 알아보기로 하자. Minimum system requirements 먼저 Kubeflow 구축 과정이다. 앞서 이야기한데로 Kubeflow가 구성되기 위해서는 Kubernetes 환경이 사전에 구축되어 있어야 한다. 실제로 Kubeflow는 복잡한 시스템을 배포, 확장 및 관리하기 위해 Kubernetes를 기반환경으로 사용한다. Kubeflow는 Kubernet..

서론 Amazon EKS는 Kubernetes를 기반으로 동작하는 PaaS 플랫폼으로 Kubernetes가 제공하는 Rolling Update 방식을 그대로 적용하여 기본 제로 다운타임 배포를 구현할 수 있다. 다만, EKS 자체의 제로 다운타임배포는 가능하지만 배포 장애에 대한 대응방안과 Managed Service 간의 배포 호환성 등의 검증은 여전히 필요하다. 예를 들어 EKS의 Ingress type으로 ALB Ingress Controller 등과 연계하여 아키텍처를 설계할때 Pod로 라우팅하는 ALB Ingress의 TargetGroup이 재생성 되는 과정에서 연결 장애가 발생할 수 있기 때문이다. 즉 EKS는 연결되어 있는 Managed Service를 포함하여 제로 다운타임을 함께 고민해야..

서론 Legacy 환경에서 각 환경별(개발, 테스트, 운영)로 설정을 구분하기 위해 우리는 Property를 활용해 왔다. Property를 적용하기 위해 application.properties나 application.yml과 같은 설정 파일 기반으로 적용하거나 @Configuration 어노테이션을 사용하여 각 환경 별 구분된 환경 정보를 가져갈 수 있었다. 이러한 방식은 모두 애플리케이션 레벨에서 환경 설정을 관리하는 방법이라 할 수 있다. 최근 애플리케이션은 Cloud Native하게 개발하기 위해 개발방식도 변화되어 가고 있다. 특히 Spring Boot 기반의 가볍고 빠른 개발을 지원하는 Runtime Framework의 활용도가 높아지고 있으며, 이는 Cloud Platform에 빠르게 이식..