응용 프로그램을 무 상태로 유지하는 방법

이것은 복잡한 질문 일 수 있지만 무국적 상태를 더 잘 이해하려고합니다.

내가 읽은 것을 기반으로 웹 응용 프로그램은 상태가 없어야합니다. 즉, 각 요청은 독립적 인 트랜잭션으로 취급됩니다. 결과적으로 세션과 쿠키는 피해야합니다 (둘 다 상태 저장 상태이므로). 더 좋은 방법은 서버에 아무것도 저장되지 않기 때문에 상태 비 저장 토큰을 사용하는 것입니다.

세션을 위해 보관중인 데이터 (예 : 장바구니의 항목)가있을 때 어떻게 웹 응용 프로그램이 상태 비 저장 상태가 될 수 있습니까? 이것들은 실제로 어딘가에 데이터베이스에 저장된 다음 주기적으로 제거됩니까? 쿠키 대신 토큰을 사용할 때 어떻게 작동합니까?

그리고 관련 질문으로 주요 웹 사이트 (Amazon, Google, Facebook, Twitter 등)가 실제로 상태가 없습니까? 토큰이나 쿠키 (또는 둘 다)를 사용합니까?

"웹 응용 프로그램은 상태가 없어야합니다" 는 "상태를 가져야 할 이유가없는 한 웹 응용 프로그램은 상태가 없어야합니다" 로 이해해야 합니다 . "장바구니"는 설계 상 상태 저장 기능이며, 이는 비생산적이라는 점을 부인합니다. 쇼핑 카트 패턴의 요점은 요청 간 응용 프로그램 상태를 유지하는 것입니다.

쇼핑 카트를 구현하는 상태 비 저장 웹 사이트로 상상할 수 있는 대안 은 단일 페이지 응용 프로그램으로, 쇼핑 카트를 완전히 클라이언트 측으로 유지하고 AJAX 호출로 제품 정보를 검색 한 다음 한 번에 서버로 전송합니다. 사용자는 체크 아웃을 수행합니다. 그러나 사용자가 여러 브라우저 탭을 사용할 수 없으며 실수로 탭을 닫을 때 상태를 유지하지 않기 때문에 누군가 실제로 그렇게하는 것을 보지 못했습니다. 물론 로컬 저장소를 사용하는 것과 같은 해결 방법이 있지만 서버 대신 클라이언트에서만 상태가 다시 나타납니다.

페이지 뷰간에 데이터를 유지해야하는 웹 응용 프로그램이있을 때마다 일반적으로 세션을 소개하여 수행합니다. 요청이 속한 세션은 쿠키 또는 모든 링크에 추가 한 URL 매개 변수로 식별 할 수 있습니다. 쿠키는 URL을보다 편리하게 유지하고 사용자가 실수로 URL을 session-id와 공유하지 못하도록하기 때문에 쿠키를 선호해야합니다. 그러나 쿠키를 비활성화하는 사용자에게는 URL 토큰을 폴백으로 사용하는 것이 중요합니다. 대부분의 웹 개발 프레임 워크에는 즉시 사용 가능한 세션 처리 시스템이 있습니다.

서버 측에서 세션 정보는 일반적으로 데이터베이스에 저장됩니다. 서버 측 메모리 내 캐싱은 선택 사항입니다. 응답 시간을 크게 향상시킬 수 있지만 다른 서버간에 세션을 전송할 수는 없습니다. 따라서 폴백으로 영구 데이터베이스가 필요합니다.

주요 웹 사이트 (Amazon, Google, Facebook, Twitter 등)는 실제로 상태가 없습니까? 토큰이나 쿠키 (또는 둘 다)를 사용합니까?

그들은 당신이 로그인 할 수 있습니까? 그런 다음 탭을 닫고 사이트를 다시 방문해도 여전히 로그인되어 있습니까? 그렇다면 쿠키는 쿠키를 사용하여 세션 간 신원을 유지합니다.

웹 응용 프로그램은 상태 비 저장이어야합니다. 그러나 세션 변수, 쿠키 및 토큰이 모두 클라이언트 (웹 브라우저)에 저장된 경우이를 위반하지 않습니다. 요청의 매개 변수 일 수 있습니다.

단순화 된 모델은 다음과 같습니다.

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

이것은 소프트웨어 엔지니어링 스택 교환에서 작동 할 수 있습니다 . 입력하고있는이 답변은 웹 브라우저 상태의 일부입니다. 그것이 유일한 장소 인 한, 나 외에는 누구에게도 접근 할 수 없습니다. 그러나 Post your Answer브라우저를 누르 자마자 웹 서버로 보냅니다. 웹 서버는 자체 상태를 사용하지 않고 게시물을 처리합니다. 내 브라우저와 데이터베이스에서 내가 누군지 알게됩니다. 내 게시물을 확인하고 데이터베이스에 추가하면 웹 서버가 즉시 나를 잊어 버립니다.

이것이 무국적의 의미입니다. 서버는이를 기억할 책임이 없습니다. 그것은 직업이 아닙니다.

이를 수행하면 많은 장점이 있습니다. 웹 서버에 메모리 누수가있는 경우 메모리 풋 프린트가 커지지 않아야하므로 감지 할 수 있습니다. 웹 서버가 충돌하면 내 신분이 그대로 유지됩니다. 누군가가 서비스 거부 공격을 시도하면 웹 서버 상태 자원을 사용하여이를 수행 할 수 없습니다. 웹 서버는 세션간에 상태를 할당하지 않기 때문입니다. 이것은 모두 웹 서버를 안정적으로 만드는 것을 목표로합니다. 이런 식으로 실행이 시작되면 계속 실행됩니다.

이제는 데이터베이스의 리소스를 사용하고 있지만, 웹 리소스를 적용하는 상태가없는 비즈니스 규칙 인 데이터베이스를 야생 및 엉뚱한 웹으로부터 보호하기 위해 신뢰할 수있는 것으로 인해 허용 범위에 대해 먼저 리소스를 확인했습니다.

웹 애플리케이션은 상태 비 저장이어야합니다

무의미한 말. 웹 요청 은 상태 비 저장이어야합니다. 보다 정확하게는 웹 요청 은 상태 비 저장입니다.

그러나 전체 응용 프로그램 이 무국적이어야한다고 말하는 것은 완벽한 말이 아닙니다.

각 요청은 독립적 인 거래로 취급됩니다.

예, 정확하게 . 또는 더 정확하게, 예, 반드시 . HTTP를 통해 각 요청은 본질적 으로 다른 모든 요청과 독립적입니다. HTTP에 "상태 저장"을 추가하려면 각 "상태 저장"요청에 대해 "상태"를 명시 적으로 식별, 저장 및 검색해야합니다. 노력이 필요하고 성능이 저하되며 복잡성이 증가합니다.

이러한 이유로 인해 상태 비 저장 상태 가 될 수 있는 각 요청은 상태 비 저장 상태 여야합니다.

결과적으로 세션과 쿠키는 피해야합니다 (둘 다 상태 저장 상태이므로). 더 좋은 방법은 토큰을 사용하는 것입니다

몇 가지 사항 : 토큰은 세션 저장소에도 연결될 수 있습니다. 쿠키는 세션 저장소에 연결될 필요 가 없습니다 . 토큰은 종종 쿠키에 저장됩니다. 때로는 세션이 작업에 적합한 도구 일 수도 있습니다.

즉 적어도 것을 의미한다 때때로 , 세션과 쿠키 그냥 토큰으로 "더 나은"로합니다!

[토큰]은 서버에 아무것도 저장되지 않기 때문에 상태 비 저장입니다.

그게 다야 이것이 바로 "무국적"교리에 관한 것입니다. 분명히, "아무것도"서버에 저장하는 것이 아니라 세션 상태를 서버에 저장하지 않는 것 입니다.

예를 들어 내 Gmail받은 편지함이 상태입니다. 그리고 그것은 서버에 잘 저장하는 것이 좋습니다 ! 그러나 세션 상태 가 아닙니다 .

따라서 작은 식별자를 가져 와서 자신이 누구인지 파악할 수있는 서버를 보유하는 대신, 상태 비 저장 응용 프로그램은 자신이 누구인지, 모든 피 묻은 요청으로 무엇을하고 있는지 상기시키기를 원합니다 . 응용 프로그램 상태는 여전히 존재하며 클라이언트는이를 유지해야합니다.

이제 그 상태가 작 으면 괜찮을 것입니다. 어떤 경우에는 매우 좋습니다.

그리고 물론, 우리는 단순히 상태가 좋을 것으로 예상되는 것들이 있습니다 ...

내 세션에 보관중인 데이터 (예 : 장바구니의 항목)가있을 때 웹 응용 프로그램을 상태 비 저장 상태로 만드는 방법은 무엇입니까? 이것들은 실제로 어딘가에 데이터베이스에 저장된 다음 주기적으로 제거됩니까?

두 가지 옵션이 있습니다. 세션이 있거나 거부 중입니다!

...하지만 진지하게. 일반적으로 쿠키에 장바구니를 저장하지 않습니다. 쇼핑 카트와 같은 것은 "전통적인"세션에 저장되거나 Cart서버가 후속 요청으로 가져 오기 위해 사용하는 일종의 ID를 가진 개체 로 저장됩니다 . .. uhh ... ... err ... 세션 과 같은 종류 .

진지하게 : 두 의사 소통 상담원이 대화에서 메시지를 컨텍스트화할 수있을 때 "상태 저장성"이라고 부르는 정도가 상당히 높습니다. 그리고 전통적으로 이해되는 세션은 우리가 일반적으로 이것을 발생시키는 메커니즘이라고 부릅니다.

서버가 처리하는 각 요청에 대해 토큰을 사용하든 "세션"을 사용하든 관계없이 해당 요청을 컨텍스트 화하여 처리해야한다고 주장 합니다. 컨텍스트가 필요 하지 않으면 가져 오지 마십시오. 상황 이 필요한 경우 근처에있는 것이 좋습니다.

그리고 관련 질문으로 주요 웹 사이트 (Amazon, Google, Facebook, Twitter 등)가 실제로 상태가 없습니까? 토큰이나 쿠키 (또는 둘 다)를 사용합니까?

아마 둘 다. 그러나 일반적으로 말하면 정확하게 사용자의 작업을 수행합니다. 대규모 "세션"데이터베이스에서 "상태"레코드를 식별하도록 쿠키를 설정합니다.

가능한 경우 중앙 저장소에 대한 불필요한 경합을 피하기 위해 기본 ID 클레임을 단기 "토큰"에 넣었다고 생각합니다. 그러나 이러한 서비스 중 다수가 "다른 모든 위치에서 로그 아웃"할 수 있다는 사실은 토큰을 전혀 사용하지 않는 경우 반 전통적인 세션 모델에서 최소한 "지원"되고 있다는 것을 나타내는 좋은 지표입니다. .

Statefulness는 반드시 나쁜 것은 아니지만 Stateful 앱과 Stateless 앱의 차이점을 이해해야합니다. 즉, 상태 저장 앱은 현재 세션에 대한 정보를 유지하지만 상태 비 저장 앱은 유지하지 않습니다. 사용자 계정의 일부로 영구적으로 저장된 정보는 세션에 저장 될 수도 있고 저장되지 않을 수도 있지만, 사용자 계정과 관련된 정보를 저장한다고해서 응용 프로그램이 상태를 유지하는 것은 아닙니다. 상태 저장을 위해서는 서버가 클라이언트 브라우저가 유지 관리하는 것 이상으로 현재 사용자의 세션에 대한 정보를 유지해야합니다. 예를 들어, 클라이언트는 JSESSIONID 쿠키를 인증하고받을 수 있으며, 각 쿠키는 요청마다 서버로 전송됩니다. 서버가이 JSESSIONID를 기반으로 애플리케이션의 세션 범위에 항목을 저장하기 시작하면 상태 저장 상태가됩니다.

무국적

상태 비 저장은 서버와 클라이언트가 사용자 세션에 대한 최신 정보를 유지 관리하지 않음을 의미합니다. 클라이언트와 서버는 요청간에 인증을 제공하기 위해 특정 형식의 토큰을 사용할 수 있지만 다른 현재 정보는 저장되지 않습니다. 이러한 솔루션의 일반적인 사용 사례는 대부분의 사용자 (신규 소비자)가 정보를 소비하지만 사이트로 돌아가는 정보를 생성하지 않는 뉴스 사이트 일 수 있습니다. 이 경우 사이트는 현재 사용자 세션에 대한 정보를 유지할 필요가 없습니다. 사이트는 여전히 쿠키를 사용하여 사용자를 식별하고 해당 사용자의 사이트 사용에 대한 정보를 저장할 수 있지만, 기록 된 모든 것이 트랜잭션 가능할 수 있으므로 (예 : 사용자가 클릭 한 링크, 서버이지만 사용자 세션에서는 유지되지 않습니다.

서버의 상태 저장

서버에서 상태 저장 앱은 현재 사용자에 대한 상태 정보를 저장합니다. 이 방법은 일반적으로 쿠키를 사용하여 사용자 시스템을 식별하여 요청간에 서버에서 상태를 유지할 수 있도록합니다. 응용 프로그램의 컨텍스트에 따라 세션이 인증되거나 인증되지 않을 수 있습니다. 상태 저장 서버 앱은 서버에서 사용자 상태 정보를 캐싱하여 조회 및 페이지 응답 시간을 단축하는 이점을 제공합니다. 단점으로, 세션 범위에 정보를 저장하는 것은 비용이 많이 들고, 규모에 따라 리소스를 많이 사용하게됩니다. 또한 해커가 세션 식별자를 가로 채서 사용자 세션을 도용 할 수있는 잠재적 공격 경로를 만듭니다. 상태 저장 서버 앱은 서버 장애와 같은 예기치 않은 서비스 중단으로부터 사용자 세션을 보호해야하는 어려움이 있습니다.

클라이언트의 상태 저장

JavaScript 및 sessionStorage와 같은 최신 브라우저 기술을 사용하여 응용 프로그램은 이제 해당 사용자의 장치에서 사용자 세션에 대한 상태 정보를 쉽게 저장할 수 있습니다. 전반적으로 응용 프로그램은 여전히 ​​상태 저장으로 간주 될 수 있지만 상태 유지 작업은 클라이언트로 이동되었습니다. 이 접근 방식은 각 사용자가 실제로 자신의 상태를 유지하고 서버 인프라에 부담이 없다는 점에서 서버의 상태를 유지하는 것보다 웹 응용 프로그램의 관리자에게 큰 이점이 있습니다. 웹 규모에서 이러한 종류의 아키텍처 선택은 하드웨어 및 전기 비용에 큰 영향을 미칩니다. 서버의 상태를 유지하는 데 문자 그대로 연간 수백만 달러가 소요될 수 있습니다. 클라이언트에서 상태를 유지 관리하는 시스템으로 이동하면 연간 수백만 달러를 절약 할 수 있습니다.

토큰 대 쿠키

쿠키는 클라이언트 장치 / 브라우저의 식별자 역할을합니다. 그것들은 모든 방법을 저장하는 데 사용될 수 있지만 일반적으로 CFML 앱에 CFID / CFTOKEN과 같은 식별자 형식을 저장합니다. 쿠키는 사용자 브라우저에 오랫동안 존재하도록 설정할 수 있으므로 브라우저 세션간에 앱에서 인증을 유지하는 등의 작업을 수행 할 수 있습니다. 쿠키는 메모리 전용으로 설정하여 사용자가 브라우저를 닫을 때 쿠키가 만료되도록 할 수도 있습니다.

토큰은 일반적으로 서버에서 생성되고 (정보를 스크램블하기 위해 암호화를 사용하여) 클라이언트에 전달 된 후 후속 요청과 함께 서버로 반환되는 사용자에 대한 일종의 식별 정보입니다. 요청 및 응답 헤더에 전달 될 수 있으며 이는 단일 페이지 애플리케이션에서 공통적 인 패턴입니다. 이상적으로는 각 요청 / 응답으로 인해 새로운 토큰이 생성되므로 나중에 공격자가 토큰을 가로 채서 사용할 수 없습니다.

단일 페이지 앱 및 클라이언트 상태

SPA를 사용하면 상태 정보가 클라이언트 브라우저에로드되어 유지됩니다. 소셜 미디어 계정에 업데이트를 게시하는 등 상태가 변경되면 클라이언트는 해당 새 트랜잭션을 서버에 릴레이합니다. 이 경우 서버는 해당 업데이트를 데이터베이스와 같은 영구 데이터 저장소에 저장하고 업데이트를 기반으로 서버와 동기화해야하는 모든 정보를 클라이언트에 다시 중계합니다 (예 : 업데이트 ID).

클라이언트에서이 상태 저장 패턴은 약간 사용 가능한 응용 프로그램을 가지고있는 동안 서버에서 연결을 끊을 수 있다는 점에서 온라인 / 오프라인 경험에 이점을 제공합니다. Twitter는이 사례의 좋은 예입니다. Twitter 서버 앱에서 연결이 끊긴 경우에도 Twitter 피드에로드 된 클라이언트 측을 검토 할 수 있습니다. 이 패턴은 또한 서버와 클라이언트 간 동기화의 복잡성을 야기하며, 이는 자체 주제입니다. 솔루션의 복잡성은 클라이언트에서 상태를 유지할 수있는 트레이드 오프입니다.

클라이언트의 상태 저장 기능은 웹 앱을 기존 데스크톱 앱처럼 느끼고 동작하도록 만듭니다. 데스크톱 앱과 달리 일반적으로 모든 계정 정보가 브라우저의 클라이언트 세션에로드되지는 않습니다. 많은 경우 비현실적이고 나쁜 경험을하게 될 것입니다. 전체 Gmail 상자를 브라우저에로드하려고한다고 상상할 수 있습니까? 대신 클라이언트는보고있는 레이블 / 폴더 및 찾고있는 폴더의 전자 메일 목록과 같은 정보를 유지 관리합니다. 유지해야 할 상태 정보와 필요에 따라 요청해야 할 사항의 균형을 맞추는 것도이 패턴의 또 다른 엔지니어링 과제이며, 실용성과 우수한 사용자 경험 제공 간의 균형을 나타냅니다.

쇼핑 카트 등

쇼핑 카트와 같은 세부 사항은 실제로 솔루션에 달려 있습니다. 쇼핑 카트는 서버의 데이터베이스에 저장되거나 서버의 세션 범위에만 저장되거나 클라이언트에 저장 될 수도 있습니다. 아마존은 로그인 한 사용자를위한 영구 쇼핑 카트와 익명 사용자를위한 "임시"카트를 가지고 있지만,이 카트는 어느 정도 영구적입니다.

실제로 같은 브랜드로 존재하는 다양한 애플리케이션 인 Google과 같은 것에 대해 이야기 할 때 공통 아키텍처를 공유하지 않을 수 있으며 각 아키텍처는 사용자의 요구를 가장 잘 충족시키는 방식으로 구축됩니다. 사이트 구축 방법을 배우려면 브라우저에서 개발자 도구를 열어서보십시오. 쿠키를 확인하고 네트워크 트래픽을보고 쿠키가 어떻게 실행되는지 확인하십시오.

이 답변이 약간 삐걱 거리면 죄송하지만 Statefulness는 복잡한 주제입니다.

세션과 쿠키는 피할 필요가 없습니다. 상태 비 저장 웹 응용 프로그램으로 계속 사용할 수 있습니다.

Java와 Ruby on Rails에는 큰 차이가 있습니다. Java 앱은 쿠키에 저장된 세션 키를 사용하여 세션을 메모리에 저장합니다. 사용자 상태와 쇼핑 카트를 빠르게 검색 할 수 있습니다. 그러나 항상 세션과 동일한 서버에 충돌해야합니다.

Rails 앱은 사용자 ID를 서명되고 암호화 된 쿠키에 저장합니다. 조작 할 수 없습니다. 페이지를로드하면 웹 앱이 데이터베이스에서 상태, 사용자 및 장바구니를 가져옵니다. 이 속도는 느리지 만 열쇠는 모든 인스턴스를 공격 할 수 있다는 것입니다 ! 이를 통해 원하는대로 인스턴스를 다시 시작, 확장 및 종료 할 수 있습니다. 매우 편리합니다. Redis와 같은 메모리 내 공유 캐시 데이터베이스를 사용하여 더 빠르게 만들 수도 있습니다. 또는 쿠키가 충분히 작은 경우 쇼핑 카트를 쿠키에 저장할 수 있습니다.

따라서 영리한 기술을 통해 무국적 상태를 달성하고 마음대로 확장 할 수있는 기능을 추가 할 수 있습니다.

프로토콜은 무 상태입니다.

그러나 프로토콜을 사용하는 응용 프로그램이 상태 비 저장이어야한다는 것을 반드시 따를 필요는 없습니다.

차이점을 잘 설명하는 몇 가지 관련 StackOverflow 답변이 있습니다.

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

RESTful HTTP 서비스와 같은 상태 비 저장을 언급 할 때 서버 측에 상태를 저장하지 않으려 고합니다. 기껏해야 백엔드의 데이터베이스 나 다른 영구 저장소에 상태를 저장하지 않는 것도 포함됩니다. 명확히하기 위해 나는 일반적으로 데이터가 아닌 상태에 대해 이야기하고 있습니다. 일부 사람들이 일을 섞고있는 것 같습니다.

상태 비 저장 통신에는 특히 확장 성 및 가용성과 관련하여 몇 가지 이점이 있습니다.

더 좋은 방법은 서버에 아무것도 저장되지 않기 때문에 상태 비 저장 토큰을 사용하는 것입니다.

(특정 인증 및 권한 부여 프로토콜의 경우) 사실입니다. 토큰은 요청 자체 내에 사용자를 인증하거나 조치를 승인하는 데 필요한 모든 정보를 제공 할 수 있습니다 (그러나 자체는 아님). 예를 들어 JWT를 살펴보십시오 .

세션을 위해 보관중인 데이터 (예 : 장바구니의 항목)가있을 때 어떻게 웹 응용 프로그램이 상태 비 저장 상태가 될 수 있습니까? 이것들은 실제로 어딘가에 데이터베이스에 저장된 다음 주기적으로 제거됩니까? 쿠키 대신 토큰을 사용할 때 어떻게 작동합니까?

장바구니 예와 관련하여. 세션 또는 쿠키를 사용하지 않고 모든 장바구니 항목을 클라이언트 측에 저장하는 것은 문제가 없습니다. smashingmagazine.com 에서 예제를 찾을 수 있습니다 . 그러나 쿠키를 사용하여 상태 비 저장 장바구니를 실현할 수도 있습니다 (적어도 구색이 크지 않고 4kb 저장 공간이 충분할 경우).

잘못 이해하지 마십시오. 어떤 가격으로도 쇼핑 카트를 무 상태로 구현해야한다는 의미는 아닙니다. Amazon 또는 기타 대규모 온라인 쇼핑 플랫폼은 확장 성과 같은 기술적 비 기능적 요구 사항을 충족시키는 것보다 사용자 경험과 유용성이 더 중요하기 때문에 상태 저장 쇼핑 카트 구현을 사용하고 있습니다.

일반적으로 토큰은 장바구니 항목과 같은 정보를 저장하는 데 사용되지 않습니다. 상태 비 저장 인증 및 권한 부여에 사용됩니다.

그리고 관련 질문으로 주요 웹 사이트 (Amazon, Google, Facebook, Twitter 등)가 실제로 상태가 없습니까? 토큰이나 쿠키 (또는 둘 다)를 사용합니까?

쿠키 나 인증을 위해 쿠키를 사용하고 있는지 묻는다면 두 가지를 모두 사용하는 것입니다. 대부분의 경우 기술 클라이언트의 쿠키는 대부분 토큰이 사용됩니다.

당신이 인용 한 규칙은 기술적으로 올바르지 않습니다. 웹 응용 프로그램의 모든 계층에는 상태가 있습니다.

규칙의 의도는 "세션 별 상태 서버 측을 보유하지 않음"입니다.

즉, ASP의 세션 변수 는 일반적으로 바구니 / 사용자 이름의 항목 등을 수행하는 데 사용됩니다.

그 이유는 응용 프로그램이 더 많은 사용자를 확보함에 따라 서버의 메모리가 부족하기 때문입니다. 저장소에 데이터베이스 나 공유 캐시를 이동해도 여전히 병목 현상이 발생해도 문제가 해결되지 않습니다.

이 문제에 부딪치지 않고 사용자 별 응용 프로그램 상태를 유지하려면 상태를 클라이언트쪽으로 이동하십시오. 예를 들어 바스켓 품목을 쿠키 또는 고급 클라이언트 측 스토리지에 넣습니다.

클라이언트 수는 사용자 수에 따라 확장되므로 응용 프로그램 전체에 병목 현상이 발생하지 않으며 확장 성이 우수합니다.