플젝 구현내용 정리 (17) 썸네일형 리스트형 Scalable Distributed Systems 구축 사례 정리 이번 SI 프로젝트에서 관련 서비스를 Distributed and Scalable Systems으로 설계 후 구축을 진행했다. 나는 TA 역할로 참여했으며, Distributed and Scalable Systems을 구성하고 아키텍처를 설계 하는데 있어 여러 요소들을 고려해야 했다. 관련 이야기를 하자면 아래와 같다.프로젝트 수행 이야기프로젝트 초기 단계에서 나는 시스템의 Scalability(확장성)를 최우선으로 고려했다. 일단 이전의 AS-IS기반의 사용자를 대비하여 시스템 확장을 고려하면 되지 않을까 하였지만 이번 프로젝트는 여러개의 시스템을 하나의 시스템으로 통합시키는거라 Scalability를 어느정도로 잡아야 할지 고민이 되었다. 그나마 다행인건 EKS의 pod로 올라가고 Fargate 형태.. OSI 7 Layer와 AWS 인프라 예전부터 궁금했던 건데 누가 정리를 이렇게 잘해 놓았네. ㅋㅋ 이번 플젝하면서 구현된 서비스를 AWS와 OSI7 Layer를 기반으로 정리를 해보았다. 위의 그림과는 좀 다른 거 같은데...모든 계층은 하위 계층에서 상위 계층으로의 연계 후 서비스가 동작 한다고 보면 된다. 예를들어 TCP/IP를 통해 소켓 통신을 맺는다면 1 - 2 - 3 -4 계층으로 순차적으로 실행 후 4계층에서 TCP/IP 소켓을 클라이언트와 서버간에 뙇 맺는다고 보면 된다. 상암동 데이터 센터와 AWS를 연결하여 수행한 SI 프로젝트를 OSI 7 계층 모델과 AWS 서비스에 적용하여 설명하면 다음과 같다.물리 계층 (Physical Layer):상암동 데이터 센터와 AWS 간의 물리적 연결은 AWS Direct Connect를 .. 공공기관과 TCP/IP 연계 내용 정리 플젝을 하면서 공공기관과 TCP/IP로 연계를 했었다.관련 내용을 정리하면 아래와 같다. 참고로 여기서 ME는 우리쪽이고 OG가 공공기관 이었다. 보통은 SYN과 ACK 플래그 값에 특정 값을 같이 보내서 서로 해당 값을 확인후 연결을 맺고 끊는다.3 Way Handshake (연결 설정)SYN (Synchronize)ME가 OG에 연결 요청을 보낸다. 이 요청은 SYN 플래그가 설정된 패킷으로 이루어진다.ME: "안녕하세요, OG님! 연결을 맺고 싶어요. (SYN=1, Seq=x)"SYN-ACK (Synchronize-Acknowledge)OG는 ME의 요청을 받고, 연결 요청을 수락한다. 이때 OG는 SYN과 ACK 플래그가 설정된 패킷을 보낸다.OG: "안녕하세요, ME님! 연결 요청을 수락합니다.. TCP/IP 4계층 모델로 AWS 인프라를 구현 TCP/IP 4계층 모델과 AWS 서비스 적용네트워크 인터페이스 계층 (Network Interface Layer)AWS Direct Connect: 상암동 데이터 센터와 AWS 간의 물리적 연결을 통해 안정적이고 고속의 네트워크 연결을 확보.데이터 링크 계층: AWS Direct Connect를 통해 상암동 데이터 센터와 AWS 간의 전용 네트워크 연결을 설정하여 데이터 전송의 안정성과 보안을 강화.인터넷 계층 (Internet Layer)Amazon VPC: AWS 내에서 가상 네트워크를 생성하고 관리하여 상암동 데이터 센터와 AWS 간의 네트워크 트래픽을 효율적으로 관리.Elastic IP: 고정된 공인 IP 주소를 할당하고, 공공기관과의 연계를 위해 네트워크 설정을 최적화.전송 계층 (Transp.. PostgreSQL DB에 INDEX를 적용 했을 때 여전히 느린 경우 SI 프로젝트 수행 중 대량 데이터가 저장되어 있는 테이블의 조회 속도가 너무 느려서 Index를 설정했었다.그런데 Index를 설정 해도 여전히 느렸는데 이유를 알고 보니 중복 값이 너무 많았었다.PK이지만 중복값이 많을때에는 아무리 인덱스를 걸어도 제 속도가 안 나오는 거 같았다.그래서 다른 컬럼에 인덱스를 걸어서 다중 칼럼 인덱스로 인덱스를 설정 후 보다 나은 검색속도를 보였던 것을 기억한다. 그래서 아래의 내용을 정리해 보고자 한다. PostgreSQL에서 특정 컬럼에 중복값이 많으면 검색 속도가 느려질 수 있다. 인덱스는 중복값이 적을 때 더 효율적으로 작동한다. 중복값이 많으면 인덱스의 선택성이 낮아져서 검색 성능이 저하될 수 있다. 이를 해결하기 위해 다음과 같은 방법을 고려할 수 있다:다중.. CentOS와 UbuntuOS 선정 하기 SI 프로젝트에서 Docker 이미지로 빌드할 OS를 선택할 때, Ubuntu 하고 CentOS 중에 나는 Ubuntu를 선택했었다. 나는 우분투가 훨씬 편했고, 훨씬 빨랐고, 레퍼런스도 많아서 사용하기가 편했었다. 선택지는 CentOS와 UbuntuOS 즉 2가지의 선택지가 존재했다. 둘 중 하나는 무조건 선택을 했어야 했다. 관련 내용을 정리해 보면 아래와 같다. 먼저 CentOS와 Ubuntu의 장단점을 살펴보자.CentOS의 장점:안정성: CentOS는 Red Hat Enterprise Linux(RHEL)를 기반으로 하여 매우 안정적이다. 이는 주로 서버 환경에서 중요한 요소중 한 가지 이므로 매우 중요하다. (CentOS의 LTS(Long Term Support) 기간은 10년이다.) 우.. NoSQL관련 PoC 사례 정리 이전 회사에서 PoC로 NoSQL 관련 내용을 정리한게 있다. 관련 내용을 시간 있을때 정리 해놓자. NoSQL 데이터베이스를 적용하려고 고민중에 실제로 구현해볼 기회가 생겼다. 조건은 JSON 형태의 저장과 REST API를 기반으로 하는 트랜잭션 처리가 조건 이었다.그래서 적합한 NoSQL 데이터베이스를 찾고 있었는데 종류로는 아래와 같다. 먼저, NoSQL 데이터베이스의 주요 유형을 보면 몇가지로 분류 할 수 있다.1. 문서 지향형 데이터베이스 : MongoDB, CouchDB 2. 키-값 저장소 : Redis, DynamoDB 3. 열 지향형 데이터베이스 : Cassandra 4. 그래프 데이터베이스 : Neo4j 각각의 데이터베이스는 고유한 장점과 단점을 가지고 있다. 첫번째로, 문서 지향형 .. 프로젝트에서 쿠키(Cookie)와 세션(Session)을 적용한 사례 정리 최근 수행한 SI 프로젝트에서 보안을 강화하기 위해 쿠키와 세션을 활용한 사례가 있다. 이 프로젝트에서는 사용자 인증과 세션 관리를 통해 보안성을 높였고, 구현 사례는 아래와 같다. 먼저, 사용자가 로그인하면 서버는 사용자에게 고유한 세션 ID를 생성하여 쿠키에 저장한다. 이 쿠키는 클라이언트 측에 저장되며, 이후 요청 시마다 서버로 전송된다. 서버는 이 세션 ID를 통해 사용자를 식별하고, 세션 정보를 조회한다. 조회 후 정상적인 요청이면 로그인을 수행하고, 비정상적인 요청이라면 거부한다. 특히, 세션 정보는 AWS Elasticache에 저장하여 관리했는데, AWS Elasticache는 인메모리 데이터 저장소로, 빠른 속도로 세션 데이터를 읽고 쓸 수 있어 성능을 향상시킨다. 또한, 분산 환경에.. 이전 1 2 3 다음
