kikiundo (❖,❖)@kikiundo3
gRialo! 🐎
오늘은 병렬 실행에 대해 공부했습니다!
가장 궁금했던 점은 왜 병렬 실행이 필요한지, 그리고 병렬 실행이 정확히 무엇인지였습니다.
블록체인은 기본적으로 트랜잭션을 순차적으로 실행합니다. 이 방식은 구현이 단순하고 항상 정확한 결과를 보장한다는 장점이 있지만, 한 번에 하나의 트랜잭션만 처리할 수 있기 때문에 속도와 처리량에 명확한 한계가 있습니다.
이러한 한계를 극복하기 위해 등장한 개념이 병렬 실행입니다.
병렬 실행은 여러 트랜잭션을 동시에 처리하여 CPU의 여러 코어와 스레드를 최대한 활용하는 방식입니다.
예를 들어 CPU에 8개의 코어가 있다면, 이론적으로는 8개의 트랜잭션을 동시에 실행할 수 있어 전체 처리 속도를 크게 높일 수 있습니다.
하지만 여기서 중요한 문제가 하나 발생합니다. 동시에 실행된 트랜잭션이 과연 올바른 결과를 낼 수 있는가? 하는 점입니다.
병렬 실행의 결과가 순차 실행의 결과와 동일할 때만, 우리는 그 병렬 실행을 정확하다고 말할 수 있습니다.
이를 이해하기 위해 작은 카페를 예로 들어볼 수 있습니다. 바리스타가 한 명뿐인 카페에서는 손님이 여러 명 와도 주문을 하나씩 차례대로 처리합니다.
모든 주문은 정확하게 처리되지만, 손님이 많아질수록 시간이 오래 걸립니다.
반대로 바리스타를 여러 명으로 늘리면, 각 바리스타가 동시에 주문을 처리할 수 있어 훨씬 빠르게 커피를 제공할 수 있습니다.
이 상황에서 CPU의 여러 코어는 여러 명의 바리스타에, 동시에 처리되는 트랜잭션은 동시에 주문하는 손님에 비유할 수 있습니다.
그러나 병렬 실행이 항상 좋은 결과만을 가져오는 것은 아닙니다.
여러 바리스타가 동시에 같은 그라인더를 사용하려고 할 때 문제가 발생할 수 있습니다.
예를 들어 모든 바리스타가 동시에 하나뿐인 그라인더를 사용하려 한다면, 이 과정에서 오류가 생길 수 있습니다.
이것이 바로 트랜잭션 충돌, 즉 conflict입니다. 여러 트랜잭션이 동시에 동일한 상태 데이터에 접근하고 수정하려 할 때 발생하는 문제입니다.
이러한 충돌을 해결하기 위해 규칙이 필요합니다.
한 사람이 다루는 동안 다른 사람은 기다리게 하는 방식은 비관적 제어: 락 기반제어
반대로 일단 동시에 작업을 진행한 뒤, 문제가 생기면 다시 시도하는 방식은 낙관적 제어: 재시도 기반 제어
어떤 방식을 선택하느냐에 따라 시스템의 성능과 복잡성이 달라집니다.
충돌이 실제로 어떻게 발생하는지를 계좌 예시로 살펴볼 수 있습니다.
계좌의 초기 잔액이 100달러라고 가정하고, 동시에 두 개의 트랜잭션이 들어옵니다. 하나는 30달러를 출금하는 트랜잭션이고, 다른 하나는 50달러를 입금하는 트랜잭션입니다. 순차적으로 실행하면 먼저 출금이 이루어져 잔액이 70달러가 되고, 이후 입금이 실행되어 최종 잔액은 120달러가 됩니다. 이 결과는 항상 동일하고 예측 가능합니다.
하지만 두 트랜잭션이 병렬로 실행되면 상황이 달라집니다.
두 트랜잭션이 동시에 잔액 100달러를 읽고 각자 계산을 시작하면, 출금 트랜잭션은 70달러를 쓰고 입금 트랜잭션은 150달러를 쓰게 됩니다.
이때 어떤 트랜잭션이 마지막으로 상태를 기록하느냐에 따라 최종 잔액이 70달러가 될 수도 있고 150달러가 될 수도 있습니다.
이는 순차 실행의 결과인 120달러와 전혀 다른 값이며, 병렬 실행이 아무 제어 없이 이루어질 경우 얼마나 쉽게 잘못된 상태가 만들어질 수 있는지를 보여줍니다.
이는 현실에서도 자주 발생하는 문제로, 여러 사람이 동시에 같은 재고나 데이터를 수정할 때 이전 상태를 기준으로 덮어써 버리는 상황과 매우 유사합니다.
이처럼 병렬 실행은 성능을 획기적으로 개선할 수 있는 강력한 방법이지만, 충돌을 제어하지 않으면 정확성을 잃게 됩니다.
따라서 병렬 실행을 안전하게 사용하기 위해서는 동시성 제어가 필수적이며, 이 역할과 구체적인 접근 방식에 대해서는 이후에 더 깊이 공부할 필요가 있습니다.
그건 퇴근 후에..! 😉
(그림은 내가 그림판으로 그린 그림!)
@RialoHQ @RialoKorea @itachee_x @silverwave1000
Today, I studied parallel execution.
The questions I was most curious about were why parallel execution is necessary and what parallel execution exactly is.
Blockchains fundamentally execute transactions sequentially. This approach has the advantage of being simple to implement and always guaranteeing correct results, but because it can process only one transaction at a time, it has clear limitations in speed and throughput.
Parallel execution is the concept that emerged to overcome these limitations.
Parallel execution is a method that processes multiple transactions simultaneously to fully utilize multiple CPU cores and threads.
For example, if a CPU has eight cores, it can theoretically execute eight transactions at the same time, significantly increasing overall processing speed.
However, an important problem arises here. The key question is whether transactions executed simultaneously can truly produce correct results.
Only when the result of parallel execution is identical to the result of sequential execution can we say that the parallel execution is correct.
To understand this, we can consider a small café as an example. In a café with only one barista, even if many customers arrive, orders are handled one by one in sequence.
All orders are handled correctly, but as the number of customers increases, it takes more time.
On the other hand, if the number of baristas is increased, each barista can handle orders simultaneously, allowing coffee to be served much faster.
In this situation, multiple CPU cores can be compared to multiple baristas, and simultaneously processed transactions can be compared to customers ordering at the same time.
However, parallel execution does not always produce good results.
Problems can occur when multiple baristas try to use the same grinder at the same time.
For example, if all baristas try to use the only available grinder at the same time, errors can occur during this process.
This is what is called a transaction conflict, or conflict. It occurs when multiple transactions simultaneously access and modify the same state data.
Rules are required to resolve such conflicts.
The approach where others wait while one person is handling the resource is pessimistic control, or lock-based control.
In contrast, the approach where work proceeds simultaneously first and is retried if a problem occurs is optimistic control, or retry-based control.
Depending on which approach is chosen, the system’s performance and complexity change.
We can examine how conflicts actually occur using a bank account example.
Assume the initial account balance is 100 dollars, and two transactions arrive at the same time. One transaction withdraws 30 dollars, and the other deposits 50 dollars.
If executed sequentially, the withdrawal happens first, reducing the balance to 70 dollars, and then the deposit is executed, resulting in a final balance of 120 dollars. This result is always the same and predictable.
However, the situation changes when the two transactions are executed in parallel.
If both transactions read the 100-dollar balance at the same time and begin their calculations, the withdrawal transaction writes 70 dollars and the deposit transaction writes 150 dollars.
At this point, depending on which transaction writes the state last, the final balance may become either 70 dollars or 150 dollars.
This is completely different from the sequential execution result of 120 dollars and shows how easily incorrect states can be created when parallel execution occurs without any control.
This is a problem that frequently occurs in the real world and is very similar to situations where multiple people simultaneously update the same inventory or data and overwrite changes based on a previous state.
In this way, parallel execution is a powerful method that can dramatically improve performance, but it loses correctness if conflicts are not controlled.
Therefore, concurrency control is essential for using parallel execution safely, and its role and specific approaches need to be studied more deeply later.
That will be after work !
