전체 글

전체 글

    [k8s] containerd란? 쿠버네티스와의 관계

    오랜만에 돌아왔습니다~! 오늘은 containerd에 대해서 이야기해보려고합니다. 참고로 읽을때는 컨테이너드가 아니라 컨테이너 디(d)로 읽습니다. 여기서 d는 daemon을 뜻합니다. Containerd의 탄생과 배경Containerd의 탄생 배경은 Docker와 쿠버네티스에 아주 밀접하게 관계가 있기 때문에 이 둘을 먼저 집고 넘어가겠습니다.  Docker2013년 Docker가 처음 세상에 등장한 이후, IT 업계는 급격한 변화를 겪었습니다. Docker는 애플리케이션 배포 단위를 war, jar, zip에서 Docker 이미지로 바꾸었고, 애플리케이션은 container에서 실행되며 OS에 종속되지 않고 Windows나 Ubuntu 같은 다양한 환경에서 동일하게 동작할 수 있게 되었습니다. Doc..

    [MQ] RabbitMQ 미러링(Mirroring)

    이 글을 이해하기 위해서는 RabbitMQ 클러스터링에 대한 이해가 먼저 필요합니다. 혹시 아직 RabbitMQ 클러스터링에 대해 잘 모르신다면 여기를 먼저 보고와주세요! RabbitMQ 클러스터의 한계 RabbitMQ 클러스터는 "Queue를 제외"한 모든 정보를 모든 노드가 공유한다고 했던것을 기억하시나요? 따라서 결국 모든 클러스터에는 하나의 Unique한 Queue만 존재합니다. 따라서 만약 하나의 노드가 Fail 하는 경우, 다른 노드와 connection을 맺어서 클러스터와의 연결을 유지할 수는 있지만 해당 노드에 속해있던 Queue에 저장된 Message는 유실이 됩니다. 따라서 이같은 Message 유실을 최소화하기 위해 나온 기법이 바로 Queue Mirroring 입니다. Queue 미..

    [MQ] RabbitMQ 클러스터링(Clustering)

    혹시 RabbitMQ에 대한 이해가 필요하시다면 여기를 먼저 보고와주세요! RabbitMQ 클러스터링이란? 다수의 RabbitMQ 노드(RabbitMQ가 설치된 서버)를 마치 하나의 RabbitMQ를 사용하는 것처럼 사용할 수 있는 기법입니다. 위 그림처럼 클러스터에 노드가 3개 존재한다면 어떤 노드에 연결해도 나머지 두 개 노드의 RabbitMQ에 접근할 수 있습니다. 어떻게 그게 가능한가요? 클러스터에 구성된 RabbitMQ들은 Queue를 제외한 모든 정보와 상태값이 공유됩니다*. 예시로 Exchange 같은 경우 클러스터내에 있는 모든 RabbitMQ에 동일하게 존재합니다. 따라서 하나의 노드에만 connection이 맺어져있어도 노드가 queue를 보유하고있는지 상관없이 원하는 Exchange를..

    [클라우드] 오픈스택(OpenStack) 이란?

    OpenStack이란? OpenStack은 IaaS 형태의 프라이빗/퍼블릭 클라우드 구축을 위한 오픈소스 플랫폼(오픈소스 소프트웨어 프로젝트의 집합)입니다. NASA와 Rackspace가 진행하던 프로젝트가 2010년에 오픈소스화된것이며 현재는 OpenStack 재단에서 운영되고 있습니다. 현재 클라우드 인프라를 구축할 수 있는 가장 거대한 오픈소스 프로젝트이고 6개월에 한번씩 새로운 버전을 릴리즈(버전 확인)하고 있습니다. 왜 만들어진건가요? 클라우드 컴퓨팅에 사용되는 서버를 구축하고 제어하려면 하드웨어와 운영체제에 대한 전문적인 지식이 필요합니다. 당연히 하드웨어와 운영체제에는 많은 종류가 있기 때문에 환경이 바뀔때마다 새롭게 지식을 습득하고 적용해야하는 문제가 생깁니다. 그래서 서버의 하드웨어와 운..

    [MQ] RabbitMQ 란?

    RabbitMQ는 쉽고 간편하면서 AMQP를 구현한 오픈소스 메시지 브로커(Message Broker) 입니다. 메시지 브로커(Message Broker)란? 메시지 브로커는 sender application이 발송한 메시지를 receiver application에게 전달해주는 툴입니다. 메시지 브로커는 메시지를 전달하면 메시지를 보관하지 않고 삭제합니다. AMQP(Advanced Message Queuing Protocol)란? 메시지 지향 미들웨어를 위한 표준 응용 계층 프로토콜입니다. 탄생 배경은 AMQP이전에 상용화된 MQ는 플랫폼에 종속적인 경우가 많았었기 때문에 다른 이기종간에 메시지를 교환하기 위해서는 메시지 브릿지를 사용하거나 (성능 저하 이슈), 시스템 자체를 통일 시켜야하는 (대공사) ..

    [네트워크] 커버로스(kerberos)란?

    kerberos는 그리스 신화에서 유래하여 "지옥에서 온 머리가 3개 달린 경비견" 이라는 뜻으로 케르베로스 라고도 불리기도하죠. 이러한 이름을 가지고 있는 kerberos는 MIT에서 개발한 티켓 기반의 컴퓨터 네트워크 인증 프로토콜입니다. 왜 만들어졌나요? 프로젝트 Athena가 제공하는 네트워크 서비스를 보호할 목적으로 처음에 만들어지게 되었습니다. 하지만 일반적으로는 보안이 보장되지 않은 네트워크 환경에서 유저와 서버의 신뢰성을 확보하기 위해서 사용됩니다. 더 쉽게 말하면 인증된 클라이언트만이 서버에 접속할 수 있도록 관리해줍니다. 신뢰성을 어떻게 확보하죠? 바로 위에서 말한 티켓을 사용하여 진행됩니다. 커버로스에서 티켓은 아래 정보를 안전하게 전달하는데 사용되는 정보 패킷입니다. 유저 아이디 유..

    [MySQL] MMM, MHA

    MMM (Multi-Master Replication Manager) MMM은 DB에 장애가 발생했을때 자동으로 Failover 프로세스를 실행해주는 Perl 스크립트 기반의 Auto Failover 오픈소스 입니다. DB서버를 모니터링하는 MMM 모니터가 존재하고, DB서버는 Agent실행 후 MMM모니터와 통신합니다. 따라서 모니터 Agent 통신 방식입니다. MMM 구조 Multi-Master 라는 이름에 맞게 MMM은 Master DB를 두 개를 두고 양방향 복제를 합니다. Master(Active)는 읽기/쓰기가 가능하고, Master(Standby)는 읽기전용 모드 (readonly)로 모니터에서 제어됩니다. 만약 Slave가 추가된다면 Master(Active)로 부터 단방향 복제 Slave..

    [Cache] EHCache 란?

    EHCache(ehcache) 는 Spring에서 간단하게 사용할 수 있는 Java기반 오픈소스 캐시 라이브러리 입니다. 보통 캐시 엔진하면 redis, memcached가 떠오르만, 이 둘과 달리 ehcache는 데몬을 가지지 않고 Spring 내부적으로 동작하여 캐싱처리를 합니다. 따라서 ehcache는 Spring Application과 라이프사이클을 함께합니다. (애플리케이션이 죽으면 같이 죽습니다) 왜 redis, memcached를 놔두고 ehcache를 사용하죠? 가장 큰 이유는 가볍고 빠르다 입니다. redis, memcached 같은 경우 우선 별도의 데몬으로 실행되야합니다. 벌써 도입시점부터 관리포인트가 늘어난것이죠. 그에비해 ehcache는 spring 내부적으로 동작하며 단순 캐시 ..

    [네트워크] SaltStack 이란?

    SaltStack은 대규모 인프라를 관리하기 위한 자동화 관리 시스템 입니다. 위 그림처럼 Salt-master 하나가 여러개의 Salt-minion에게 명령을 publish 하고 그 결과를 취합하여 보여주는 구조입니다. 1대의 master가 수천대의 minion을 관리할 수 있습니다. Salt-Master Server 의 역할을 담당하며 minion들에게 명령을 publish 하고 그 결과를 보여줍니다. 따라서 데이터 저장소, 원격 명령 실행, 다른 시스템 상태 제어 센터의 역할을 담당합니다. ZeroMQ 라는 비동기 메시징 라이브러리를 통해 minion에게 통신합니다. Salt-Master를 설치하면 ZeroMQ도 함께 설치됩니다. Salt-Minion Agent 역할을 담당하며 구성 자동화를 하기위..

    [Maven] Maven dependency의 Scope 옵션

    Maven 빌드 툴 사용시 pom.xml 내 dependency 태그안에서 을 보신적이 있지 않으신가요? 이는 해당 의존성을 어느 시점에 포함을 시키고 어느시점에 포함시키지 않을지를 결정하는 옵션입니다. compile: scope을 명시하지 않았을 때 기본으로 적용되는 옵션입니다. 컴파일 시점에도 필요하고 배포할때도 필요할 때 사용되는 옵션입니다. 또한 이 프로젝트를 dependency로 불러온 다른 프로젝트에서도 포함됩니다. provided: 컴파일 시점에는 필요하지만 배포시점에는 불필요할때 사용되는 옵션입니다. 주로 JDK, servlet API, Java EE API 등이 해당됩니다 runtime: 컴파일시점에는 필요없지만 runtime 시점에는 필요할때 사용되는 옵션입니다. system: repo..