인프라 아키텍처

1. 집약형 아키텍처

• 대형 컴퓨터는 하나의 컴퓨터에서 모든 처리를 수행하기 때문에 ‘집약형’ 아키텍처라고 한다.
• 이 방식은 기업의 모든 업무를 단일 시스템에서 처리하기 때문에, 고장이나 오류로 인해 업무가 중단되지 않도록 발전해왔다.
• 한정된 리소스를 효율적으로 관리하여 여러 개의 서로 다른 업무를 동시에 처리할 수 있도록 설계된다.
• 주로 '기간 시스템'(ex. 은행의 계정 시스템)과 같은 기업의 핵심 업무 시스템에서 사용된다.
• 그러나 대형 컴퓨터는 도입 및 유지 비용이 크고, 확장성에 한계가 있다는 단점이 있다.

---

2. 분할형 아키텍처

• 여러 대의 컴퓨터를 조합하여 하나의 시스템을 구축하는 구조를 '분할형' 아키텍처'라고 한다.
• 이 방식은 소형 컴퓨터 여러 대를 활용하기 때문에 상대적으로 낮은 비용으로 시스템을 구축할 수 있으며, 확장성이 뛰어나다.
• 하지만 서버 수가 증가할수록 관리 구조가 복잡해지는 문제가 있다.
• 또한, 특정 서버가 고장 날 경우 전체 시스템에 미치는 영향을 최소화할 수 있도록 아키텍처를 설계해야 한다.

---

2.1 물리 서버와 논리 서버의 차이

분할형 아키텍처에서 사용되는 컴퓨터는 주로 '서버'라고 하며, 이는 소프트웨어(SW)와 하드웨어(HW) 두 가지 관점에서 사용된다.

• SW(논리 서버): 웹사이트 접속 시 사용자 입력을 처리하고 HTML을 생성하는 웹 서버처럼, 소프트웨어적으로 동작하는 서버를 의미한다.
• HW(물리 서버): 실제 컴퓨터 하드웨어를 가리키며, 서버의 부품을 교체하거나 확장할 수 있는 실체적인 장비를 의미한다.

※ 분할형에서는 각각의 서버가 전혀 다른 작업을 하는지, 비슷한 작업을 하는지 역할 분담에 대해 고려해야 한다.

---

3. 수직 분할형 아키텍처

3.1 클라이언트-서버형 아키텍처

• 클라이언트 측에 전용 소프트웨어(애플리케이션)가 설치되어 있으며, 정기적인 업데이트가 필요하다.
• 서버가 모든 요청을 처리하므로, 서버의 부하가 증가하면 확장성에 한계가 발생할 수 있다.

📌 예시

• 웹 애플리케이션: 클라이언트(웹 브라우저) → 서버(웹 서버, DB 서버)
• 게임 서버: 클라이언트(게임 앱) → 서버(게임 데이터 처리 서버)
• 이메일 시스템: 클라이언트(메일 앱) → 서버(메일 서버)

---

3.2 3계층형 아키텍처

• 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층으로 분리되어 있으며, 각 계층의 역할이 명확히 구분된다.
  • 🔹 프레젠테이션 계층 (Presentation Layer)
    • 사용자의 입력을 받고, 웹 브라우저 화면을 표시하는 역할.
    • 예시: HTML, CSS, React, Vue.js
    🔹 애플리케이션 계층 (Application Layer)
    • 사용자의 요청을 받아 업무 로직을 처리하는 계층.
    • 예시: Java(Spring), Python(Django), Node.js
    🔹 데이터 계층 (Data Layer)
    • 애플리케이션 계층의 요청에 따라 데이터를 입출력하는 계층.
    • 예시: MySQL, PostgreSQL, MongoDB  

 

• 3계층형 아키텍처의 특징
  • ✅서버 부하 감소 : 특정 요청(예: 이미지 파일 요청) 처리 시 애플리케이션 계층에서 직접 응답할 수 있어, 불필요한 데이터베이스 접근을 줄일 수 있음.
  • ✅ 확장성 향상 : 각 계층을 독립적으로 확장할 수 있어, 트래픽 증가에도 유연하게 대응 가능.
  • ❌ 구조가 복작함 : 클라이언트-서버형 아키텍처보다 설계 및 유지보수가 어려울 수 있음.

---

4. 수평 분할형 아키텍처

• 동일한 용도의 서버를 여러 대 운영하는 방식으로, 서버 대수를 늘려 확장성을 높이는 구조다.
• 서버가 분산되어 있기 때문에 한 대의 서버에 장애가 발생하더라도 시스템 전체에 미치는 영향이 적어 안정성이 향상된다.

---

4.1 단순 수평 분할형 아키텍처

서버가 각각 독립적으로 운영되며, 시스템의 전체적인 처리 성능을 향상시키고 독립성을 유지할 수 있다.

 

✅ 장점

• 서버 간 업무가 분리되어 시스템 성능이 향상됨.
• 특정 서버에서 장애가 발생해도 다른 서버에 영향을 주지 않음.

❌ 단점

• 데이터를 일원화해서 조회할 수 없으며, 여러 서버에 분산되어 있어 관리가 어려울 수 있음.
• 애플리케이션을 업데이트할 경우, 모든 서버에 동시에 반영해야 함.
• 처리량이 균등하게 분배되지 않으면, 일부 서버에 부하가 집중되는 문제가 발생할 수 있음.

---

4.2 공유형 아키텍처

단순 수평 분할형과 달리 일부 계층에서 서버 간 상호 연결이 이루어지는 방식이다.

 

✅ 장점

• 서버 간 데이터 공유가 가능하여 일관된 데이터 관리가 가능함.

❌ 단점

• 분할된 시스템 간 독립성이 낮아짐, 즉 한 서버의 장애가 다른 서버에 영향을 미칠 가능성이 있음.
• 일부 계층이 공유되므로, 공유된 계층의 확장성이 제한될 수 있음.

---

4.3 지리 분할형 아키텍처

업무 연속성 및 시스템 가용성을 높이기 위해 물리적으로 분리된 여러 지역에 서버를 배치하는 방식이다.

 

---

 4.3.1 스탠바이형 아키텍처

 물리적으로 최소 두 대 이상의 서버를 준비하여, 한 대가 고장 나면 다른 서버가 자동으로 업무를 이어받는 방식이다.

• 이때, 장애가 발생하면 자동으로 다른 서버에서 소프트웨어를 재시작하는 기능을 "페일오버(Failover)"라고 한다.

 ✅ 장점

• 장애 발생 시 빠르게 복구할 수 있어 서비스 가용성이 높아짐.

 ❌ 단점

• 대기 중인 서버가 평소에는 사용되지 않아 리소스 효율성이 낮음.

---

 4.3.2 재해 대책형 아키텍처

• 자연재해, 전력 장애 등의 대형 사고로부터 시스템을 보호하기 위해 별도의 사이트(재해 복구 센터)를 운영하는 방식이다.
• 서버 장비 및 소프트웨어 환경을 본 서버와 동일하게 구성하여, 재해 발생 시 타 사이트의 서버를 통해 정상적으로 서비스를 제공할 수 있도록 한다.

 ✅ 장점

• 재해가 발생해도 서비스 운영을 지속할 수 있음.
• 데이터 손실을 최소화할 수 있음.

 ❌ 단점

• 별도 사이트 구축 비용이 크고 유지보수 비용이 많이 발생함.