배열 분할의 역사
IT 분야의 많은 기본 지식, 특히 중소기업(SMB) 분야의 지식은 다양한 요인으로 인해 1990년대 후반에 형성되었습니다. 가장 큰 요인은 점점 더 작은 기업들이 컴퓨터화를 서두르기 시작했고, Microsoft가 Windows NT 4를 충분히 안정적으로 만들어 SMB IT의 모든 것이 중심을 두는 표준 기반이 되었으며, 인터넷 시대가 본격적으로 자리를 잡았고, Microsoft가 업계의 지식 보급 방식을 재편한 인증 및 교육 프로그램을 도입했다는 것입니다. 이 모든 것이 합쳐져 새로운 교육과 모범 사례에 대한 필요성이 생겼고, 새로운 사고, 저술, 문서, 교육, 모범 사례, 경험칙 등의 엄청난 폭발을 일으켰습니다.
몇 년간 거의 전체 분야가 같은 소규모 지식 세트로 교육을 받았고, 많은 경험칙이 사실상의 표준이 되었으며, 당시의 많은 지식은 달달 외워서 배우고 멘토에서 인턴으로 전달되는 방식으로 1998년의 기술 지식 대부분이 2012년의 의심할 여지 없고 고정된 프로세스로 이어졌습니다. 당시에는 그 관행들이 적절했기 때문에 효과적이었지만, 그것은 15년 전의 일이었고, 그 이후로 기술, 경제, 사용 사례, 지식이 크게 변했습니다.
이 중 가장 좋은 예가 바로 유명한 Microsoft SQL Server 권장 사항이었습니다. 운영 체제에는 RAID 1, 데이터베이스 파일에는 RAID 5, 로그에는 또 다른 RAID 1을 사용하는 것이었습니다. 이 설정은 제품의 전체 수명 기간 동안 거의 그대로 유지되었으며 너무나 널리 알려져서 SMB 공간의 거의 모든 서버 설계 측면으로 퍼졌습니다. 운영 체제에 RAID 1을, 데이터에 RAID 5를 사용하는 것이 너무나 광범위하게 퍼져서 이것이 왜 당시에 권장되었는지에 대한 어떠한 고려도 없이 종종 그냥 당연한 것으로 여겨집니다.
역사를 살펴보고 R1/5/1이 1998년에는 좋았지만 오늘날에는 존재해서는 안 되는 이유를 알아봅시다. 맥락을 좀 유지해 봅시다. 이 권장 사항이 처음 나왔을 때(1995년 초)와 오늘날의 차이는 엄청납니다. 정신적으로 1995년으로 돌아가서 당시의 동등한 차이를 생각해보세요. 그것은 마치 초기 인터넷 시대에 Apple ][ 첫 소유자들을 위한 가정용 컴퓨팅 필요에 기반한 권장 사항을 사용하는 것과 같을 것입니다! 8비트 가정용 컴퓨터 시대는 1978년에 막 시작되고 있었습니다. Commodore는 첫 가정용 컴퓨터(VIC-20)를 출시하기까지 2년이 남아 있었으며, 전체 Commodore와 Commodore Amiga 시대를 거치고 파산하여 사라지기까지 1995년 이전이었습니다. Apple ][+는 아직 1년이 더 남아 있었습니다. 사람들은 막 아날로그 카세트 드라이브를 스토리지로 사용하기 시작하려 하고 있었습니다. COBOL과 Fortran이 사용 중인 유일한 비즈니스 언어였습니다. 기본적으로 그 차이는 믿을 수 없을 정도입니다. 세상은 변합니다.
먼저, 우리의 역사적인 설정을 필요하게 만든 1990년대 후반에 존재했던 요인들을 살펴봐야 합니다.
- 드라이브는 작았습니다, 매우 작았습니다. 대규모 데이터베이스 배열은 단일 배열에 약 6GB의 사용 가능한 스토리지 공간을 제공하는 R5 배열의 2.1GB SCSI 드라이브 4개로 구성되었을 수 있습니다. 패리티 RAID 장애에 대한 장애 도메인은 매우 작았습니다(URE 실패율 같은 것에 비하면).
- 드라이브 연결 기술은 병렬이었고 느렸습니다. 당시의 하드 드라이브는 오늘날 드라이브보다 약간만 느렸지만, 연결 기술은 상당한 병목 현상을 나타냈습니다. 버스 병목 현상을 줄이기 위해 트래픽을 분산시키는 것이 일반적이었습니다.
- SCSI 드라이브 기술이 서버에 사용되는 유일한 기술이었습니다. 서버에서 PATA(당시에는 IDE라고 불렸던)를 사용하는 것은 생각할 수도 없는 일이었습니다.
- 기가바이트당 드라이브 비용이 높았기 때문에 용량을 유지하면서 비용 절감이 거의 모든 기업의 핵심 문제였습니다.
- 파일시스템은 취약했고 드라이브보다 더 자주 실패했습니다.
- 하드웨어 RAID가 필요했으며 RAID 1과 5의 기본 RAID 레벨만 일반적으로 사용 가능했습니다. RAID 6와 RAID 10은 대부분의 기업에서 접근할 수 있게 되기까지 수년이 걸렸습니다. RAID 0은 중복성이 없으므로 제외됩니다.
- 스토리지 시스템은 서버 간에 거의 공유되지 않았으므로 액세스는 거의 항상 단일 요청 대기열에 전용으로 사용되었습니다.
- 스토리지 캐시가 작거나 존재하지 않아 드라이브 액세스 제한이 운영 체제에 직접 전달되었습니다. 이는 서로 다른 읽기/쓰기 또는 랜덤/순차 액세스 혼합을 처리하기 위해 서로 다른 특성을 가진 다른 배열이 필요했음을 의미했습니다.
- 드라이브 실패가 일반적이었고 스토리지 시스템 설계에서 주요 관심사였습니다.
- 종종 드라이브 배열 크기가 물리적 제한에 의해 제한되어 배열 분할 결정이 선택이 아닌 필요에 의해 이루어지는 경우가 많았습니다.
- 위의 요인들의 조합으로 인해 RAID 1은 크기가 작아도 되고 액세스가 매우 순차적이거나 쓰기 집약적인 시스템 일부에 적합했고, RAID 5는 신뢰성보다 용량이 중요하고 액세스가 매우 랜덤하고 읽기 집약적인 다른 부분에 적합했습니다.
원래 권장 사항이 발표된 이후 거의 20년 동안 이러한 요인들 모두 변했습니다. 어떤 경우에는 변화가 연쇄적으로 일어나서 일반 용도 RAID 5에서 일반 용도 RAID 10으로의 전환이 공통적인 두 가지 배열 유형인 RAID 1과 RAID 10이 액세스 특성을 공유하게 되어 부하 유형에 따라 하나 또는 다른 것을 사용하고자 하는 필요성이나 욕구가 사라졌습니다.
- 드라이브는 이제 엄청나게 커졌습니다. 필요한 것을 억지로 넣으려 하는 대신, 일반적으로 용량 여유가 있습니다. 1테라바이트가 넘는 단일 드라이브는 서버에서도 일반적입니다. 패리티에 대한 장애 도메인은 엄청납니다(URE 실패율 같은 것에 비하면).
- 드라이브 연결은 직렬이고 빠릅니다. 드라이브 연결은 더 이상 병목 현상이 아닙니다.
- SATA는 이제 서버에서 일반적으로 사용되어 이전에는 존재하지 않았던 방식으로 URE에 대한 잠재적 위험을 왜곡합니다.
- 용량은 이제 저렴하지만 성능과 신뢰성이 이제 지출 대비 핵심 관심사입니다.
- 파일시스템은 오늘날 매우 강력하며 파일시스템 오류는 배열 신뢰성의 더 큰 그림에서 “배경 소음”입니다.
- 하드웨어 RAID와 소프트웨어 RAID 모두 오늘날 옵션으로 제공되며 다양한 RAID 레벨을 포함하지만, 가장 중요하게도 RAID 10이 어디서나 사용 가능합니다.
- 스토리지 시스템은 일반적으로 공유되어 순차 액세스가 더욱 드물어졌습니다.
- 스토리지 캐시는 일반적이고 종종 매우 큽니다. 512MB와 1GB 캐시는 오늘날 일반적인 것으로 간주되어 RAID 컨트롤러의 메모리에 1995년의 많은 배열이 완전히 들어갈 수 있습니다. 스토리지 용량에 비해 빠르게 증가하는 캐시와 최근 2년간 스토리지에서 L2 캐시로 솔리드 스테이트 드라이브가 추가된 것으로 인해, 소규모 기업도 데이터베이스와 다른 성능 민감한 애플리케이션이 캐시에서 완전히 실행될 수 있는 상황이 불가능한 것이 아닙니다.
- 드라이브 장애는 드물고 스토리지 시스템 설계에서 사소한 관심사입니다(다른 유형의 장애에 비해).
- 드라이브 배열 크기는 물리적 제한에 의해 거의 제한되지 않습니다.
- 오늘날 주요 배열 유형으로 RAID 1과 RAID 10을 사용하는 것은 성능 튜닝을 위해 다른 배열 레벨을 사용할 이점이 없음을 의미합니다.
이러한 요인들은 1995년에 분할 배열 시스템이 왜 완벽하게 합리적이었는지, 그리고 왜 오늘날에는 의미가 없는지를 보여줍니다. 오늘날의 표준인 OBR10은 당시 사용할 수 없었고 비용이 너무 높았습니다. RAID 5는 1995년에는 상대적으로 안전했지만 오늘날은 그렇지 않습니다. 결정 과정에 관련된 거의 모든 요인이 지난 17년 동안 극적으로 변했으며, SSD가 더 일반화되고 자동 계층화, 더 큰 캐시, 순수 SSD 스토리지 시스템이 등장함에 따라 계속 변화할 것입니다.
지난 20년간 스토리지 설계의 변화는 IT 분야의 많은 부분이 엔지니어링에서 일반적인 것처럼 기본 “경험칙” 또는 “모범 사례”를 배우면서 그 결정을 이끄는 기본 원칙을 반드시 이해하지 못하는 데서 오는 위험성을 강조합니다. 이는 그 모범 사례를 언제 적용하지 않아야 하는지, 또는 더 중요하게는 그 규칙이 더 이상 적용되지 않는다는 것을 인식해야 할 때를 알기 어렵게 만듭니다. 경력 중에 새로운 발전과 중요한 요인 변화가 한 번 또는 전혀 발생하지 않을 수 있는 전통적인 기계 또는 토목 엔지니어링과 달리, IT는 경력 내에 기본 경험칙의 완전한 재검토가 여러 번 필요할 만큼 여전히 빠르게 변합니다. 매년은 아니더라도, 10년에 한 번 이상은 거의 항상 필요합니다.
단일 처리에서 멀티스레드 아키텍처로의 현재 전환은 IT 분야가 시스템 설계를 처리하는 방식을 완전히 바꿔야 하는 또 다른 유사하고 중요한 변화입니다.
