tech 27

[MySQL] InnoDB 스토리지 엔진 아키텍처

MySQL의 InnoDB 스토리지 엔진은 MySQL에서 가장 널리 사용되는 트랜잭션 기반 스토리지 엔진 중 하나로, ACID(Atomicity, Consistency, Isolation, Durability) 속성을 지원하는 아키텍처를 제공한다. 오늘은 InnoDB 스토리지 엔진의 주요 아키텍처와 이를 통해 제공되는 중요한 기능들을 정리한다.1. InnoDB 아키텍처 개요InnoDB는 트랜잭션과 데이터 무결성을 보장하면서 고성능을 제공하기 위해 설계된 스토리지 엔진이다. MySQL에서 기본 스토리지 엔진으로 사용되며, 다양한 기능을 통해 데이터베이스 운영을 효율적으로 관리할 수 있다. 주요 구성 요소는 다음과 같다버퍼 풀(Buffer Pool): InnoDB 스토리지 엔진에서 매우 핵심적인 부분. 디스크..

tech/database 2024.09.15

openvpn으로 특정 리전의 mongodb 접속이 안될때

vpc flow log 를 확인해보니 아얘 안찍히고 있었다.1. 아얘 해당 vpc 로 패킷인입자체가 안되는 것 이므로, 첫번째로 dns 로 ip를 못찾는지 확인해보았음(nslookup) private ip 를 잘 확인할 수 있는것을 확인하였음2. 서브넷에서 해당 vpc 에 연결이 안되어있는것인지 routing table 과 vpc-peering 확인해보니 되어있음3. 같은 서브넷에서 연결시도해보았으나 되는것을 확인4. openvpn 설정에서 막히는것이 있는지 확인해보니, private subnet 접근 설정이 따로 필요한 부분이 있었고 여기에 해당 vpc 네트워크대역이 빠져있는것을 확인하여 추가해주었음5. 연결잘됨

[보안&인증] aws imds(Instance Metadata Service) 에 관하여

회사에서 c# dotnet core 를 사용하고 있는데, c# aws sdk 를 사용해 aws api call 을 하는 경우 ec2에 적용된 iam role 이 자동으로 적용되는 것이 신기하여 어떤 원리로 가능한 것인지 조사해 보았다.Overviewaws sdk 는 ec2 인스턴스 메타데이터 서비스라는 것을 통해 ec2에 부여된 iam 역할의 임시자격증명을 발급하고 이를 api 호출에 사용한다. 여기서 ec2 인스턴스 멘타데이터 서비스란 ec2인스턴스 내에서 실행중인 애플리케이션이 현재 인스턴스 관련 정보를 얻을 수 있도록 하는 서비스를 의미한다. 인스턴스 관련 정보엔 iam 역할이름 및 인스턴스 id 등이 있고 인스턴스 정보조회 말고도 ec2에 부여된 iam role역할의 임시 자격증명 발급또한 가능하..

tech/보안&인증 2024.06.24

[보안&인증] openID와 SSO 비교 정리

OpenID정의: OpenID는 인터넷 사용자들이 여러 웹사이트에서 하나의 아이디로 로그인할 수 있게 하는 인증 프로토콜역할: OpenID는 인증 과정을 표준화하고, 사용자가 특정 OpenID 제공자(IdP)를 통해 여러 웹사이트(Relying Party, RP)에 인증할 수 있게 한다.구현 예: OpenID Connect는 OAuth 2.0을 기반으로 하는 인증 프로토콜로, 현재 널리 사용되는 OpenID 표준SSO (Single Sign-On)정의: SSO는 사용자가 한 번 로그인하면 동일한 자격 증명으로 여러 애플리케이션이나 시스템에 접근할 수 있게 하는 기능이자 개념역할: SSO는 사용자 편의성을 높이고, 보안성을 강화하며, 관리 비용을 절감하는 것을 목표로 한다. SSO 자체는 특정 기술이나 프..

tech/보안&인증 2024.06.23

AWS Elasticache vs MemoryDB 비교

elasticache 와 memorydb의 가장 두드러지는 차이는 데이터 쓰기시 memorydb 는 transaction log 기록 후 응답을 전송하고, elasticache for redis는 그렇지 않다는것이다. 이 차이로 인해서 가격, 쓰기성능, 장애발생시 데이터유실가능성(내구성) 면에서 차이가 발생하게 된다. 엘라스티캐시는 특수한 경우에 데이터가 유실될수있고 데이터의 완전한 내구성을 보장하지 않는다. 이 이유는 위에서 언급한 레디스 자체가 노드간 데이터복제를 통해 싱크 할때 비동기방식만 제공하기때문이다. 프라이머리가 다운될때 아직 리플리카로 전달되지않은 데이터가 있는 경우엔 그대로 데이터유실이 된다. 메모리디비에서는 별도의 트랜잭션로그를 기록하는 저널로그공간을 별도로 관리한다. 여기에 기록이되면..

tech/database 2024.05.31

ssh(secure shell) 이해하기

자주 사용해 왔지만 좀더 정확하게 이해하고 사용하고 싶어 간략하게 정리한다. ssh 는 secure shell 을 의미하며 주로 원격 컴퓨터에 로그인하고 명령을 실행하거나 파일을 전송하는등등에 사용된다. ssh 는 secure가 붙은 것 처럼, 이 과정에서 데이터를 암호화하여 네트워크를 통해 정보가 노출되는 것을 방지한다. ssh 과정을 간략하게 요약해보면 아래와 같다 접속되는 서버는 접속하는 사용자의 공개키를 가지고 있는 상태를 가정한다 접속하는 사용자는 접속시 본인의 공개키를 전송한다. 접속되는 서버는 챌린지를 보내고, 접속하는 사용자는 이것을 비밀키를 통해 응답한 후, 접속되는 서버에서 이를 공개키로 검증하여 개인키가 유효한지 확인한다. 개인키가 유효한 것으로 확인되면, 연결이 허용된다 이제 데이터..

tech/보안&인증 2024.04.10

AWS Elasticache(redis) 내부동작 정리

Overview 새로운 서비스에 AWS Elasticache 를 캐시 데이터베이스로 사용할 예정이어서, Redis와 Elasticache 운영에 필요한 내용들을 정리하려 한다. 레디스 Deployment Architecture 레디스 아키텍처 레디스의 아키텍처는 4가지 타입으로 구분될 수 있다. 싱글 노드 High Avaliability(HA 구성) primary node, secondary node Redis Sentinel 2번으로인해 SPF를 방지할 수 있지만, instance down을 감지하지 못하면 의미가 없다. sentinel은 지속적으로 instance가 healthy한지 모니터링하고 발견되면 spinning up하는 역할을 하며, 이외에도 primary 가 다운되면 쿼럼에 기반한 합의알고..

tech/database 2024.03.31

캐시 구현 패턴 정리

1,2 번은 읽기 전략이고 3,4번은 쓰기 전략이다.cache aside클라이언트는 캐시에서 먼저 조회 후, 없으면 database에서 캐시에 캐싱후 읽는다read-through클라이언트는 캐시에서 조회한다. 존재하지않으면 클라이언트가 직접하는게 아니라 캐시쪽에서 자동으로 DB에서 데이터를 조회해 저장 후 반환한다. 클라이언트는 사실상 캐시만 바라보게 되어 코드구조는 매우 단순해진다.write throughwrite 할 일이 있을때마다, 캐시에 먼저 반영 후 데이터베이스에 반영한다. 캐시와 데이터베이스의 일관성이 매번 지켜지므로, 이 성질이 매우 중요한 경우 고려해볼 수 있다. 또한 쓰기작업은 적은데 읽기작업이 많은 경우 + 실시간으로 최신데이터가 필요한 경우 write through 방식이 적극 고려..

tech/architecture 2024.03.29

분산시스템 CAP 이론에 대하여

Overview CAP이론은 분산 데이터베이스의 속성을 기술하는데 사용된다. CAP 이론을 이해하다 보면 분산시스템에서 발생 할 수 있는 일들과 이에 대한 대응을 하나하나 따져보게 되는데, 이점이 분산시스템이 가지고 있는 본질적인 성능에 관해 이해하는데 도움을 준다. Consistency (C)— 어떤 시간에서의 읽기를 하더라도 가장 최근 쓰기된 데이터가 읽힌다 Availability (A)— 어떤 상황에서도 항상 reasonable 시간안에 reasonable한 응답을 한다 Partition Tolerance(P) — network partition 발생하더라도 계속 동작한다 간단한 AP, CP 시스템 CAP이론은 간단하게 분산시스템은 CAP에서 최대 2가지의 속성만 만족할 수 있다이지만, 좀더 생각해..

tech/architecture 2024.03.24

[k8s] 서비스를 통한 트래픽 전달 과정

서비스는 여러 파드들에 트래픽을 로드밸런싱해주는 역할을 한다. 부족하지만 이 과정에 대해 이해한 것들을 정리해 보려 한다 서비스의 IP,Port로 보낸 트래픽이 Pod의 Ip,Port 로 로드밸런싱 되는 상세 과정 k8s에서 서비스를 생성하고 pod를 매핑시키게 되면 서비스의 IP,Port가 생성된다. 이렇게 생성된 서비스의 IP와 Port로 향하는 트래픽은 패킷이 노드를 떠날때 노드마다 설치된 kube-proxy 에 의해서 매핑된 파드중 하나의 IP,Port로 랜덤하게 전달된다. 정확하게는 패킷이 노드를 떠날때 커널에서 kube-proxy에 의해 설정된 iptables 규칙을 참고하여 도착지의 Ip,Port 가 서비스의 Ip,Port쌍중에 하나인지를 확인한 후, 맞다면 그에 매핑된 파드의 Ip,Port..

tech/k8s 2024.03.02