[데이터베이스를 지탱하는 기술] - 가용성과 데이터의 복제

가용성과 데이터 복제

데이터베이스가 크래쉬되었을 때 어떻게 하면 서비스를 다운시키지 않고 계속해서 운용할 수 있을까? 주제를 다룬다. 현재의 정석은 복제이지만, 장애 시의 데이터 로스를 어느 정도 허용할 수 있는지에 따라 방침은 변한다. 현재의 트랜드를 살펴보도록 하자.

# 데이터베이스는 어떤 때에 크래쉬되는가?

세상에서 인기를 얻고 있는 서비스는 24시간 365일 끊임없이 방대한 액세스가 발생하고 있다. 동시에 데이터베이스에도 많은 트래픽이 발생하고 있다. 이러한 `언제든지 필요할 때 동작해야 하는` 서비스에서는 생각하지 않으면 안 되는 것이 바로 장애에 대한 대책이다.

  장애는 어느 날 갑자기 발생한다. 평상시 사용하고 있는 PC가 Windows의 트러블로 블루 스크린을 표시하거나 디스크 고장으로 사용할 수 없게 되거나 하는 경험은 독자들로 한두 번은 경험이 있을 것이다. 이와 비슷한 장애는 데이터베이스 서버에서도 일어날 수 있다. 그 영향이 매우 크기 때문에 장애에 대한 대비가 필요하다.

전형적인 장애 시나리오

장애 대책으로서는 먼저 어떤 장애 패턴이 있는지를 정리하여 각각에 대해 적절한 대책을 마련하는 것이 중요하다. 대표적인 장애 패턴은 다음과 같다.

1. 소프트웨어 장애
   MySQL 등의 데이터베이스 프로그램의 폭주와 충돌처럼 소프트웨어 주변의 결함으로 인해 서비스를 제공할 수 없는 유형의 장애다. 문제의 심각성에 따라 데이터 자체가 파괴되어 다시 시작되지 않는 등 치명상이 될 수도 있다.
     소프트웨어 장애는 품질이 장애 빈도와 심각성에 결정적인 영향을 미친다. 오픈 소스/상용 제품에 관계없이 실적이 있고 노하우도 갖춘 제품을 사용하는 것이 중요하다. 자사 제품이면 충분한 코드 검토 등을 통해 품질 높은 소프트웨어를 만들어 내야 한다.  제품을 평가하는 데 있어서 기능과 성능에만 눈이 가기 쉽상이지만, 장기간 운용하기 위해서는 품질도 이들에 준하는 중요한 지표가 된다.
2. OS 장애
   Windows의 블루 스크린 또는 Linux 커널 패닉과 같은 OS 주변의 장애로 인하여 서비스를 제공할 수 없게 되는 패턴이다. 일반적으로 소프트웨어 장애로 분류되지만, 문제 해결에는 OS 및 하드웨어 주변의 고급 기술이 요구 되기 때문에 RDBMS와 같은 미들웨어 장애와는 또 다른 어려움이 존재한다. 발생 빈도에 있어서도 OS장애로 인하여 서비스를 제공할 수 없게 되는 경우가 결코 드물지 않다. 따라서 대규모 웹 서비스 화사는 유명한 Linux 개발자를 고용하기도 한다. 
   현실적으로 발생 빈도가 높은 문제로서는 장치 드라이버의 버그가 있다. 예를 들어 고부하 처리가 일정 시간 이상 지속 후 갑자기 디스크 액세스를 전혀 할 수 없게 되는 문제가 발생하기도 한다. OS 설치 시 기본적으로 따라오는 드라이버는 버전이 오래 되서 이미 알려진 결함이 있을 수 있다. 최신 버전으로 업데이트하자.
     반면, 어느 정도 사용되는(검증된) 기술을 사용하는 것도 중요하다. 예를 들어 가상화 환경은 데이터베이스 서버로서는 아직 실적이 충분히 있다고 말할 수 없다. 가상화된 환경 Xen에서 MySQL을 운용하고 있을 때 자주 커널 패닉이 일어나게 되어 상당히 남감했었다는 경우도 있다.
3. 하드웨어 장애
   OS 및 소프트웨어 주변의 장애는 결함을 제거해 버리기만 한다면 몇 년 단위에 결쳐서 수십 대 이상의 서버를 장애로부터 막아낼 수 있다. 한편, 하드웨어 장애의 경우는 그렇게까지는 할 수 없다. HDD와 같이 물리적으로 작동하는 것은 한 개당 수명이 2~3년 정도로 그다지 길지 않다. 그것이 1,000대 규모의 서버에서 운용되고 있다면 하루 한 대는 어느 서버에선가 고장이 나는 일이 발생하게 된다. 대규모 웹 서비스 공급자라면 어디든 이러한 하드웨어 장애와 맞닥뜨리게 된다.
4. 조작 실수
   잘못해서 테이블을 지워 버리는 식의 조작 실수에 의한 장애가 많다. 물론 방지할 수 있으면 방지하는 것이 좋겠지만, 많은 사람들이 참여하면 할 수록 이런 문제가 일어날 확률이 높아진다. 나중에 설명하겠지만 조작 실수에 의한 장애는 종종 복구가 매우 복잡한 경우가 있다.

디스크 이중화로 데이터 손실 방지하기

지금까지 언급한 문제를 발생시키지 않는 것이 최선이겠지만, 현실적으로 발생 확률을 제로로 하는 것은 불가능하다. 물론 확률을 줄이는 노력은 필요하나, 서비스를 운ㅇ녕하는 관점에서 보면 장애가 발생해도 서비스를 제공할 수 있도록 설계하는 것 에 중점을 두어야 한다.

  장애 대첵 중에서도 특히 중요한 것이 데이터 손실 방지다. 데이터를 잃어 버리면 비록 서버가 복구되었다 해도 필요한 데이터가 없기 때문에 서비스를 계속할 수 없기 때문이다. 따라서 장애 중에도 데이터 손실을 막기 위한 대책이 결정적으로 중요하다.

RAID

현재 데이터베이스의 데이터는 HDD에 저장되는 것이 보통이다. 그러나 불행히도 HDD는 하드웨어 중에서 가장 고장률이 높은 부품이다. 그래서 하나의 서버에 여러 개의 HDD를 탑재하고 동일한 데이터를 두개 이상의 HDD에 분산시키는 기술이 사용되고 있다. 이 기술을 RAID라고 한다. 디스크 한 개가 망가져도 괜찮다라는 것이다. 기준은 용량에 여유가 있으면 RAID1, 여유가 없는 경우는 RAID5를 사용하는 것이 일반적이다.

  RAID의 구성에 따라 다르지만, 한 개가 망가지 상태에서 방치하면 성능이 크게 저하될 수 있고, 그대로 두 번째가 손상되면 데이터 손실의 위험이 있다. 그래서 첫번째가 손상된 경우에 서비스를 멈추지 않고 망가진 HDD와 새로운 HDD를 교체하여 복구하는 핫 스왑 이라는 기술도 병용된다.

서버 이중화에 의한 다운 타임 줄이기

실제로는 RAID를 사용하는 것만으로는 서비스를 운영하는 데 충분하지 않다. 장애의 원인이 되는 것은 디스크만이 아니기때문이다. cpu 고장, 커널 패닉도 있으며, 데이터베이스 프로세스 장애도 있다. RAID 구성을 짜고 있다 해도 서버가 하나밖에 없으면 시스템은 즉시 다운되어 버린다. 

  따라서 서버는 두 대 이상 필요하다. 두 대로 동일한 데이터를 가지고 있게 하면 어느 하나가 크래쉬가 발생한 경우에도 남은 한 대를 사용하여 적어도 서비스를 계속할 수 있다. 이후로는 이 구성에 대해서 살펴보도록 하자.

방식	설명
RAID 0 (스트라이핑)	복수의 HDD에 데이터를 기록하여 일고 쓰기를 고속화시키는 방식, 이동 가능 용량은 디스크의 개수만큼이다.
RAID 1 (미러링)	두 대의 HDD에 동일 데이털르 작성하는 방식, 이용 가능 용량은 디스크수의 절반이다.
RAID 5	오류 정정 부호인 패리티 데이터와 함께 분산하여 기록하는 방식, 이용 가능 용량은 N - 1개가 된다.
RAID 6	오류 정정 부호인 패리티를 두 개 생성하고 데이터와 함께 분산하여 기록하는 방식, 이용 가능 용량은 N개의 경우 N - 2개가 된다.

=>결론

장애 패턴 종류에 대해서 알게되었다. 크게 4가지의 패턴이 발생할 수 있다는 것을 알게되었고 다음과 같다.

• 소프트웨어 장애
• OS 장애
• 하드웨어 장애
• 조작 실수 

각각의 패턴이 다른 만큼 대응 방법이 다르다고 생각한다. 장애 대응은 예측하기 어려운 장애와 어느정도 예측이 되는 장애가 있다고 생각이 든다. 예를 들면 소프트웨어 장애 혹은 OS장애는 예측하기 어렵다고 생각이 들며, HDD 용량 부족에 의한 장애, 미숙한 사용에 의한 장애는 어느정도 예측이 가능하다 라고 생각이 든다. 예측하기 어려운 장애는 복제 등과 같은 방식을 통해서 예측이 일어나더라도 서비스를 가용가능하게 대응하는 방법이 적절해보이고 예측이 어느정도 된다면 일어나지 않도록 하는 방법을 적용하는 것이 좋지 않을까 생각이 들었다.

 

장애가 발생하면 데이터가 소실될 가능성이 있기 때문에 이것을 막기 위한 방법으로 RAID가 있다는 것을 알았고 RAID는 데이터 여유공간에 의해서 적용하는 RAID 방식의 차이가 있다는 것을 알게 되었다. (용량이 많으면 RAID 1, 용량이 적으면 RAID 5)

# 복제

웹 서비스를 중심으로 현재 가장 널리 사용되고 있는 중복화 방식이 복제이다. 복제는 문자 그대로 레플리카를 다른 서버에 생성하는 기술로, 비록 하나의 서버가 다운되더라도 나머지 서버에 동일한 데이터가 있기 때문에 서비스를 계속 할 수 있다. 그렇다고는 해도 복제에는 다양한 유형이 있어 성능을 희생하여 데이터 무결성을 중시하는 것이 있는가 하면, 반대로 데이터 소실의 리스크를 소융하면서 성능을 추구하고 있는 것도 있다. 여기서는 MySQL에 도입되어 있는 것을 중심으로 소개하겠다.

단방향 복제

우선 가장 전통적이고 이해하기 쉬운 단방향 복제를 소개하겠다.

단방향/비동기

단방향/비동기 복제는 마스터에서 갱신한 결과가 슬레이브에 비동기로 전파하는 유형의 복제다.

  이것은 MySQL에서 표준으로 사용되는 복제 기능이다. MySQL에서는 마스터에서 실행한 갱신계의 SQL문이 바이너리 로그라는 전용 로그 파일로 기록된다. 이 로그 파일의 내용이 슬레이브로 전송되어 저장된다. 슬레이브는 저장된 로그 파일을 순차적으로 실행함으로써 결과적으로 마스터와 슬레이브의 상태가 일치되는 구조가 된다. 슬레이브에는 바이너리 로그 수신과 바이너리 로그 실행이라는 2단계로 구성되어 있다. 각각 별도의 스레드가 담당하고 있으며, 전자는 I/O 스레드, 후자는 SQL스레드가 실행되고 있다. 이 모두가 비동기다. 디스크에 비해 네이트워 병목현상이 되는 일은 적기 때문에 수신은 거의 동기에 가까운 속도로 진행된다. 그러나 바이너리 로그에 기록되어 있는 쿼리의 실행은 테이블에 액세스하여 내용을 변경할 수 있다는 성질상 디스크가 병목현상을 일으키면 처리가 늦어지는 경향이 있다. 

  마스터가 장애를 일으킨 경우 슬레이브에서는 지금까지의 업데이트 결과가 반영되지 않을 수 있다. 이 반영되지 않은 상황이라는 것은 다음의 두 가지 패턴이다.

1. 마스터에서  생성한 바이너리 로그가 슬레이브에서는 마지막까지 수신되지 않는 상황
2. 슬레이브에서의 바이너리 로그의 실행이 마지막까지 종료되지 않는 상황

1 은 슬레이브의 I/O 스레드가 비동기이기 때문에 발생할 수 있는 현상이다. 마스터는 이미 죽어 있기 때문에 발생할 수 있는 현상이다. 마스터는 이미 죽어 있기 때문에 최근의 바이너리 로그를 전송할 수 있는 서버는 어디에도 없다. 이 경우는 슬레이브가 수신한 최종 결과와 마스터의 최종 결과 사이의 데이터가 손실될 수 있다. 다만 MySQL;이 크래쉬되었을 뿐 OS는 살아있는 경우 SSH 접속하여 바이너리 로그를 가져오는 구제 조치도 가능해 실제로 그러한 처리를 하는 경우도 있다. 

2 는 슬레이브의 SQL스레드가 지연되었기 때문에 일어나는 현상이다. 슬레이브는 바이너리 로그를 받을 수 있기 때문에 마스터가 죽어 있어도 슬레이브에 저장된 바이너리 로그를 사용하여 지연의 해소가 가능하다. 마스터가 죽었을 경우 애플리케이션은 죽은 마스터 대신에 슬레이브를 새로운 마스터로 보고 업데이트를 하게 될 것이다. 이때 주의가 필요한 것은 마스터가 죽었다고 해서 슬레이브로 갑자기 업데이트를 걸어 버리게 되면 슬레이브에서는 부분적으로만 업데이트가 끝나지 않은 상황이므로 불일치가 발생할 위험이 있다.

  제대로 복구를 하려면 슬레이브가 바이너리 로그를 마지막까지 실행한 것을 확인하고 나서 업데이트 트래픽을 옮길 필요가 있다. 이것을 수동으로 실행하려고 하면 복잡하지만 세상에는 이런 일을 자동화해 주는 도구도 존재하고 있다. 널리 보급되어 있는 제품인 만큼 컴팩트한 기능을 구비한 유용한 도구가 갖춰져있다.
단방향/준동기화

MySQL의 경우에는 1 슬레이브가 바이너리 로그를 수신 부분을 도익화 방식으로 할 수 있다. 이것을 준동기식 복제라고한다. 1이 동기 방식으로 됨으로써 마스터를 업데이트한 클라이언트는 그 결과를 마스터의 데이터베이스 상에서 확정하는 것뿐만 아니라 대상 슬레이브로 전송하여 그 확인응답이 반환될 때까지 기다리게 된다. 따라서 클라이언트에서 응답을 받았을 때 그 업데이트가 슬레이브에 도착해 있는 것이 보증된다. 이에 따라 마스터 손실에 의한 데이터 손실의 위험을 되도록 억제할 수 있다. -> 단점이 있다. 마스터 - 슬레이브 간의 바이너리 로그의 교환을 기다리는 동안만큼 응답 시간이 나빠진다. 준동기 복제는 데이터 손실의 위험과 긍답 시간의 악화에 대해 균형을 취한 현실적인 방식이라고 할 수 있다. 

단방향/동기

MySQL에서는 기능으로서 구현되어 있지 않지만, 슬레이브에 대해 업데이트 결과의 반영까지 마친 상태에서 처음으로 클라이언트에 응답을 반환하는 방식도 생각할 수 있다.

  준동기 복제는 마스터가 장애를 일으킨 경우 슬레이브 바이너리 로그를 모두 실행 완료될 때까지 기다릴 필요가 있다. 이에 대해 동기 복제는 슬레이브에서도 업데이트 결과가 반영되어 있기 때문에 즉시 슬레이브에서 서비스를 재개할 수 있다.

양방향 복제

지금까지 소개한 구성은 마스터 -> 슬레이브는 단방향 이라는 제약이 있기 때문에 업데이트는 마스터에서만 할 수 있다.

또한 대부분의 경우에서 슬레이브는 단일 스레드로 복제를 담당하게 되어 있으므로 갱신의 동시성이 없다. 최근의 하드에웨어는 SSD와 멀티코어 CPU와 같이 여러 스레드에서의 병렬성을 높일 수 있도록 되어 있기 때문에 그 해택을 받을 수 없다는 것은 문제가 될 수 있다. 그래서 마스터를 두 개 이상 갖게 하고 각각의 마스터를 업데이트할 수 있도록 한 멀티 마스터 라는 구성도 생각할 수 잇따. 

Active/Standby형의 클러스터 구성
여기서는 북제 구성만을 다루고 있지만, 이외에도 "Active/Standby"라는 구성을 사용함으로써 하드웨어가
단일 장애점이 되는 것을 방지할 수 있다.
다만, Standby하고 있는 시스템이 일반적으로는 가동되지 않고 하드웨어가 절반은 쓸모없게 되어 버리기 
때문에 웹 서비스에서는 그다지 사용되는 일이 없는 구성이다. 반대로, 부하가 높지 않고 높은 가용성이
요구되는 환경이나 사내 애플리케이션 등에서는 곧잘 사용되고 있다.

양방향 복제는 기술적으로 어렵다.

성능 면에서의 이상형을 추구해 나가면 양방향 복제 쪽이 우수하다. 그러나 현재 양방향 복제는 기술적인 과제가 많아 그것을 극복하고 있는 제품이 한정되어 있기 때문에 오픈 소스 데이터베이스를 많이 사용하는 웹 업계에서는 그다지 접해 볼 기회가 없다. 

  특히 어려운것은 "업데이트가 서로 충돌하면 어떻게 하느냐" 라는 점이다. 예를 들어 대전 게임이라 대전 게임에서 어느 한 사용자 Z의 현재 체력이 100이었다고 하자. 한 세션은 DB서버 A에 그 체력을 10을 증가하는 처리를 실시하고, 다른 세션에서는 DB서버 B에 체력 20을 감소하는 처리를 했을 경우에 대해 생각해보자. 결론은 90이 되어야 할 것이다.

  그러나 DB 서버 A로의 업데이트 및 DB 서버 B로의 업데이트가 동시에 발생되면 100 -> 110 -> 80 순서로 처리로 처리가 진행되고, DB 서버 B에서는 100 -> 80 -> 110의 순으로 처리된다. 이것은 불일치를 낳게 되기 때문에 그것을 방지하는 분산형 배타 제어의 구조가 필요하다. (Race 컨디션)

  MySQL과 같이 비동기/준동기 복제를 기반으로 한 제폼에서는 이런 배타 제어를 실현하는 것이 어렵다. 그래서 ID가 홀수인 것은 마스터 A에 건네고, ID가 짝수인 것은 마스터 B에 건네는 등 동일 ID에 대한 업데이트를 별도의 DB서버로 향하지않도록 애플리케이션 로직을 제어하는 것이 필요하다.

  이에 대해 데이터베이스 제품에 따라서는 여러 서버에 각각 업데이트를 할 수 있으며, 또한 그들이 자동으로 동기화되는 구조를 가진 것이 있다. 오픈 소스 제품의 경우 MySQL Cluster라는 제품이 이러한 양방향 복제의 구조를 가지고 있다. MySQL Cluster는 데이터 노드라고 하는 특수 서버에서 데이터를 가지고 있다. 중복성을 위해 두 개 이상의 데이터 노드에서 동일한 데이터를 서로 보관한다. 한 데이터 노드에 적용된 업데이트는 다른 쪽 데이터 노드에 동기적으로 반영된다. 동일한 기본 키 값을 업데이트하는 경우는 동일 서버에 대해서 액세스되도록 하고 있다. 때문에 동일한 기본 키에 있는 세션에서는 A -> B, 다른 세션에서는 B -> A의 순서로 업데이트가 행해지는 일이 없다.

장애로부터의 복구 방법

장애가 발생한 나머지 돌연사해 버린 서버를 후에 어떠한 방법으로 복구할 수 있을까? 슬레이브가 장애를 일으켜 못쓰게 된 경우를 생각해보자.

  슬레이브 하드웨어 오류로 인해 해당 서버의 데이터를 소실했을 경우, 다른 살아 있는 슬레이브 또는 마스터에서 데이터를 복원하거나 정기적으로 백업을 받았다면 그것으로 되돌릴 수밖에 없다. 한편, OS 장애 등의 의해 일시적으로 사용할 수 없게 되었으나 데이터 자체는 디스크에 남아있는 유형의 장애도 있다. 이때는 그냥 다시 시작하면 복제를 재개해 줄 거라 생각할지도 모르겠다. 그러나 운용의 설정이 적절하지 않으면 필요한 데이터가 남아있지 않아 복제를 재개할 수 없거나 불일치를 일으키게 된다.

  MySQL을 예로 들면, MySQL에서는 복제가 어디까지 진행되고 있었는가? 라는 상태 정보를 전용 파일로 관리하고 있다. -> 복제가 진행되면 동시에 그 파일이 갱신된다. 그러나 이 파일은 디스크에 대해 동기적으로 쓰기를 한다는 보장이 없다. -> OS 장애 등에 의해 크래쉬가 발생하면 "실제로 업데이트된 위치와 파일에 기록되는 위치"가 어긋나게 된다. 실제로 제 6장에서 설명할 트랜잭션의 무넺도 있어, 만일 동기적으로 쓰기를 했다 해도 100% 정확한 위치를 보증할 수 없다. 

인위적 실수에 대한 해결

인위적 실수에 대한 장애 대책이 있다. 예로 필요한 테이블을 실수로 지워 버리는 경우다. 복제와 같은 실시간 이중화 기술은 실수에 강하다고는 말할 수 없다. 왜냐하면 마스터에서 지워버린 테이블은 슬레이브에 즉시 반영되어 슬레이브가 같이 지워진다. 이럴 때 필요한 것이 백업이다. 백업을 정기적으로 해두면 db서버에서 데이터가 손실된 경우라 할지라도 백업 시점으로 복구 할 수 있다.

백업을 복원한 후 어떻게 하면 좋은가?

백업을 해주었다면 백업 시점으로 복구할 수 있다. 그러나 그것뿐이라면 대부분의 경우 곤란을 겪게 된다. 

  백업이란 전체 데이터베이스를 복사하는 묵직한 처리이므로 항상 실행할 수 있는 것은 아니다. 대게는 새벽 4시 등 부하가 적은 시간대에 하루에 한 번만 실행하는 방법으로 백업을 수행ㅎ나다. 여기서 의심이 생기는 것이 마지막 백업부터 반나절 경과후에 데이터가 손실되면 백업 이후에 업데이트된 결과는 어떻게 될까?라는 것이다. 데이터베이스는 시점 복구 기능이 문제를 해결해 주고 있다. 

  MySQL에서는 마지막 백업 이후의 업데이트 로그가 성공적이면 마지막 백업을 복구한 후에 그 이후의 업데이트로그를 순차적으로 적용해 나가는 것으로 장애 이전 상태로 복구할 수 있다. 제대로 동작시키려면 업데이트 로그의 어느 위치가 마지막 백업 시점인가를 파악해야 한다. 가장 손쉬운 방법은 일시적으로 업데이트를 멈추고 맥업을 하여 그 시점에서의 업데이트 로그의 위치를 특정하는 방법이 있다.

트랜잭션 구조를 응용하면 업데이트를 멈추지않고 배업을 하는 온라인 백업 기능을 제공한다. 

고의로 지연시킨 복제

비공기 복제를 응용하여 인위적 실수에 대비하는 솔루션도 있다. 타임 딜레이드 레플리케이션 이라는 기술이다. 이것은 마스터에서 수행한 업데이트를 즉시 슬레이브에 반영하지않고 1시간 등 어느 정도의 시간이 흐른 뒤에 반영하는 방식이다. 이 방법의 단점은 슬레이브가 1시간 뒤에 상태이므로 어플리케이션에서 참조할 수 없다는 것이다. 이 방식은 단지 어디까지나 예상치 못한 사태에 대비하기 위한 구성이다.

서비스를 운영하는 데 필수라고도 말할 수 있는 가용성과 그것을 실현하기 위한 데이터 복제 방법에 
대해 알아보았다. 현재의 트랜드로서는 비동기 복제가 주류이지만, 보다 데이터를 엄격하게 보호해야
하는 환경에서는 동기화 복제가 사용된다. 
복구의 수고를 생각하면 동기화 복제 쪽이 뛰어난 면이 많은 것도 사실이다. 하드웨어의 고속화나
오픈소스의 진화에 따라 동기 및 준동기 복제를 사용하는 기회도 점차 증가하게 될 것이다.

=> 결론

데이터베이스가 장애를 일으켰을 때도 서비스를 계속하기 위한 방법을 처음 보는 것이라서 충분한 이해가 되었다고 생각은 하지않는다. 방식은 단방향 복제와 양방향 복제로 나뉘어있다.
먼저, 단방향 복제
특히 비동기, 준동기, 동기 방식의 명확한 차이가 무엇인지 이해가 되지않았다. 다른 자료들도 참고해 보며 이해를 해봐야겠다. 이해한 바로 정리를 해보면 비동기 방식은 마스터가 슬레이브로 처리 방식을 전송 실행하는 두가지 단계가 모두 비동기로 이루어진다.라는 뜻으로 이해했다. 여기서 동기와 비동기는 tcp와 udp 방식의 차이 라고 생각했다. (tcp는 응답을 받고나서 다음 처리를한다. udp는 응답을 받지 않고도 다음 처리를 한다.) 비동기로 처리하다보니 성능상에서 장점이 있을 지언정 두가지 문제가 발생하였고 이에 따라 준동기, 동기 방식은 그러한 문제를 해결하지만 성능이 나쁜 방식들 이라고 생각했다.