분류 전체보기 (8) 썸네일형 리스트형 [Primary-Secondary Replication 5] 운영 지표와 Failover 테스트, 그리고 구조의 한계 서론이전 글에서는 WAL Timeline과 pg_rewind, WAL Replay를 이용해 Old Primary를 New Primary의 Standby로 다시 구성하는 과정을 살펴보았습니다. Primary 장애가 발생하면 Secondary 하나를 New Primary로 Promotion하여 쓰기 서비스를 복구할 수 있습니다.이후 Old Primary의 WAL 이력을 확인하고, 필요한 경우 pg_rewind 또는 새로운 Base Backup을 이용해 Old Primary를 다시 Standby로 구성합니다.Primary 장애 ↓Old Primary Fencing ↓Secondary Promotion ↓애플리케이션 연결 전환 ↓Old Primary 재동기화 .. [Primary-Secondary Replication 4] WAL Timeline과 pg_rewind를 이용한 Failover Recovery 서론이전 글에서는 Primary 장애가 발생했을 때 Secondary를 New Primary로 Promotion하는 과정과 Split-Brain을 방지하기 위한 Fencing을 살펴보았습니다. 안전한 Failover를 위해서는 Old Primary가 더 이상 쓰기를 처리하지 못하도록 차단한 뒤, Primary의 변경을 가장 많이 반영한 Secondary 하나를 New Primary로 Promotion해야 합니다.Primary 장애 판단 ↓Old Primary Fencing ↓Secondary 상태 비교 ↓New Primary Promotion ↓애플리케이션 연결 전환 이 과정을 완료하면 애플리케이션은 New Primary를 통해 다시 쓰기 요청을 처리할 .. [Primary-Secondary Replication 3] Primary 장애 대응: Promotion, Fencing, Split-Brain 서론이전 글에서는 동기 Replication과 비동기 Replication에서 쓰기 성공이 의미하는 범위를 살펴보았습니다. 비동기 Replication에서는 Primary가 Secondary의 처리를 기다리지 않고 성공을 반환할 수 있습니다.이로 인해 쓰기 응답 시간을 비교적 짧게 유지할 수 있지만, Primary의 변경이 Secondary에 전달되기 전에 장애가 발생하면 성공한 쓰기가 Failover 이후 사라질 수 있습니다. 동기 Replication에서는 Primary가 설정된 Secondary 처리 단계까지 기다린 뒤 성공을 반환합니다.그 대신 네트워크 전송, WAL 저장 또는 WAL Replay에 필요한 시간이 클라이언트의 쓰기 대기 시간에 포함됩니다.하지만 어떤 Replication 방식을 선.. [Primary-Secondary Replication 2] 동기·비동기 Replication과 쓰기 성공의 의미 서론이전 글에서는 Primary-Secondary Replication의 기본 구조와 읽기 요청 분산 방법을 살펴보았습니다. Primary는 쓰기를 처리하고, Secondary는 Primary의 변경을 전달받아 자신의 데이터에 적용합니다.지연을 허용할 수 있는 읽기 요청을 Secondary로 보내면 Primary의 읽기 부하를 줄일 수 있습니다. 하지만 Primary에서 쓰기가 성공한 시점과 Secondary에서 해당 변경을 조회할 수 있는 시점이 반드시 같지는 않습니다.Primary에서 Commit ↓Replication Log 전송 ↓Secondary가 로그 수신 ↓Secondary가 로그 저장 ↓Secondary가 로그 적용 ↓Secon.. [Primary-Secondary Replication 1] 기본 구조와 읽기 요청 분산 서론서비스 초기에는 하나의 애플리케이션 서버와 하나의 데이터베이스만으로도 충분할 수 있습니다.[Client] ↓[Application] ↓[Database] 이 구조는 단순합니다. 모든 읽기와 쓰기가 하나의 데이터베이스에서 처리되기 때문에 데이터의 현재 상태를 파악하기도 쉽습니다.하지만 사용자가 늘어나고 요청량이 증가하면 애플리케이션 서버만 확장해서는 해결되지 않는 문제가 나타납니다.애플리케이션 서버를 여러 대로 늘리더라도 모든 요청이 결국 하나의 데이터베이스로 전달되기 때문입니다.[Application 1] ─┐[Application 2] ─┼─→ [Single Database][Application 3] ─┘이 구조에서는 다음 두 가지 문제가 발생할 수 있습니다.읽기와 쓰기가 동일한 데이터.. AWS AI Practitioner 시험 후기(AIF-C01) AWS Certified AI Practitioner를 취득했습니다. 취준을 위해 가성비 있는 자격증을 따고 싶었는데, AIF-C01는 다음과 같은 이유로 선택했습니다.Practitioner라 공부에 대한 부담이 덜함 관련 바우처 제공AI에 대한 최소한의 관심이 있음을 어필 https://www.pearsonvue.com/us/en/aws/aif2cloud.html AWS AI & Cloud Foundational CertificationsExplore the AWS AI from Cloud promotion. Get ready for certification with clear AI concepts, real‑world use cases, and AWS services that build job‑rea.. 바닐라 자바스크립트로 보는 클라이언트 상태 관리의 흐름과 한계 서론SPA에서 상태 관리를 이야기하면 React의 useState, Context, Zustand 같은 도구를 먼저 떠올리기 쉽습니다.이러한 도구를 보다 정확히 이해하기 위해서는 왜 이러한 개념이 등장했는지, 도구를 사용하기 전에는 어떻게 구현해야 했는지 등을 알아야 한다고 생각합니다. 이번 글에서는 바닐라 자바스크립트를 사용해 기존 방식에서 SPA 방식으로 구현하는 예제를 살펴보고, 한계를 확인해보도록 하겠습니다. 요구사항타입에 맞는 포켓몬의 사진, 도감 번호, 이름을 보여주는 간단한 포켓몬 타입 도감입니다.각 타입에는 12마리의 포켓몬이 있고, 무한 스크롤로 포켓몬 이미지를 계속 불러와 확인할 수 있습니다. 왼쪽에 타입을 선택하면 지정한 타입의 포켓몬만을 확인할 수 있습니다. 포켓몬 이름 검색이 가능.. MPA에서 SPA로 전환과 상태 관리 서론SPA에서 상태 관리를 이야기하면 React의 useState, Context, Zustand 같은 도구를 먼저 떠올리기 쉽습니다.이러한 도구를 보다 정확히 이해하기 위해서는 왜 이러한 개념이 등장했는지, 도구를 사용하기 전에는 어떻게 구현해야 했는지 등을 알아야 한다고 생각합니다. 이를 위해 이번 글에서는 MPA와 SPA를 비교하고, 상태 관리의 책임이 어떻게 이동되었는지, 왜 SPA에서 클라이언트 상태 관리가 필요해졌는지 정리해보겠습니다.단순한 요구사항단순한 요구사항에서는 화면 전체가 새로 그려지는 방식도 크게 문제가 되지 않았습니다. 예를 들어, 게시글 목록처럼 페이지마다 보여줄 내용이 명확히 나뉘어 있는 화면을 생각해보겠습니다.1페이지에는 1번부터 4번까지의 글이 있고, 2페이지에는 5번부터 .. 이전 1 다음
