이제 일주일이 조금 지났지만, 로스앤젤레스 클라우드 캠프에서 세션과 토론을 통해 좋은 시간을 보냈고 몇 가지를 배웠습니다. 저는 데이터 확장에 관한 세션을 제안했고, 결국 세션을 이끌었습니다. 사실 저는 이 세션을 '데이터 확장'이라는 제목으로 제안했습니다: 필요하기 전과 후 모두"라는 제목으로 제안했습니다.
제가 이 세션을 제안한 이유 중 하나는 세션 제안 과정에서 CAP 정리에 대한 논의가 있었는데, 언급된 내용이 약간 어긋났기 때문입니다. CAP는 많은 곳에서 잘 논의되고 있습니다(좋은 블로그 중 하나는 CTO이자 Streamy. CAP는 일관성, 가용성 및 에 대한 허용 오차 네트워크 파티션. 흥미롭게도 많은 사람들이 마지막 P 성능을 만들거나 성능을 혼합에 도입하려고 계속 시도했습니다. 성능(또는 적어도 관련된 트레이드오프)은 W+R>N이라는 다른 글자로 더 잘 설명할 수 있습니다. LA 다운타운에 있는 Microsoft 사옥의 한 방은 거의 데이터 확장에 전념하는 공간이었습니다. 첫 번째 세션은 .... 의 진행으로 CAP 정리를 다루었습니다. 처음에는 Microsoft 기술을 현명하게 사용하면 이 세 가지를 모두 얻을 수 있다는 주장이 있었기 때문에 약간 논쟁의 여지가 있었지만, 방에서 토론을 통해 결국 서로의 의견에 동의하게 되었습니다. 이 세션은 짐바테크의 아비짓 가드카리가 진행했습니다. 그 후 Microsoft의 자체 SoCalDevGal (Lynn Langit)이 프레젠테이션을 진행했습니다. SQL Azure. Microsoft가 무엇을 제공하고 개발자들이 무엇을 요구하는지 확실히 알게 되었습니다. 심지어 세 글자로 된 새로운 암호명도 몇 개 배웠습니다. :) SQL Azure는 Microsoft의 호스팅 관계형 데이터베이스 서비스입니다. 프레젠테이션을 통해 처음에 Microsoft는 완전한 SQL 호환 호스트 데이터 저장소를 계획하지 않았다는 사실을 알게 되었습니다(즉, Amazon의 SimpleDB나 Google의 App Engine을 통해 액세스하는 Google의 BigTable과 비슷하게 만들려고 했습니다). 결국, 고객의 피드백에 따라 모든 Microsoft 개발자 도구와의 통합을 포함하여 가능한 한 많은 SQL을 제공하기로 다시 결정했습니다. 흥미롭게도 Microsoft는 확장성을 위해 데이터 샤딩을 제안하고 있습니다. 이는 부분적으로 초기 제품이 10GByte 데이터베이스로 제한되어 있기 때문입니다. 하지만 이는 초기 제한일 뿐이며, 일정을 맞추기 위해 몇 가지를 양보해야 했습니다. 나머지 토론을 고려할 때 적절하다고 생각한 SQL Azure에 대한 또 다른 흥미로운 부분은 CAP와 관련하여 SQL Azure를 CA 시스템으로 만들기로 결정한 것 같다는 것이었습니다. 제가 확인을 요청하기도 했는데, 실제로 그런 의도가 있었습니다. 이것이 저에게 중요한 이유는 데이터센터 간 복제와 함께 이 설계 결정이 데이터센터가 네트워크에서 단절될 경우 시스템을 오프라인으로 전환하는 것(또는 일부의 안전)만이 제대로 작동하는 유일한 방법이라는 것을 의미하기 때문입니다. 모든 데이터가 최소 두 곳의 데이터센터에 있고 어느 데이터센터인지 알 수 없으므로 데이터센터가 '쌍' 이상일 수 있으며, 이는 단일 데이터센터의 완전한 파티션은 최소 두 곳, 어쩌면 그 이상에 대한 중단을 의미할 수 있음을 의미합니다. 이는 애플리케이션과 완벽하게 호환된다는 점에서 사용자에게는 좋지만, 언젠가 통신사 장애로 인해 다수의 SQL Azure 고객이 오프라인 상태가 되는 'CNN 순간'이 발생할 수 있음을 의미하기도 합니다. 오해하지 않도록 말씀드리자면, 이는 Microsoft의 기술에 대한 비판이나 극복했어야 할 결함이 아닙니다. 단지 SQL Azure 팀이 내린 설계상의 선택이었을 뿐입니다. 모든 설계에는 장단점이 있기 마련입니다. 이것이 바로 '엔지니어링' 분야입니다. 저녁에 진행된 마지막 세션은 결국 제가 맡게 되었습니다. 저는 제 소개를 간단히 하고 멤캐시드, 기어맨, Haoop HBase, 카산드라 등을 살펴본 적이 있는 사람이 누구인지 간단히 평가했습니다. 아무도 이에 대해 생각해 본 사람이 거의 없다는 것이 밝혀졌습니다. 이는 부분적으로는 Microsoft가 이 행사를 위해 객석에 꽁초를 잘 배치했기 때문이라고 생각합니다. 청중이 이런 것들을 경험했기 때문에 저는 세션을 이해하는 데 약간의 두뇌 운동으로 진행했습니다. 왜 데이터를 저장하는 다른 방법을 알아보고 싶을 수도 있습니다. 제가 모든 것을 다루지는 못했지만 몇 가지 이유를 말씀드렸습니다:
- 확장성 - 분산 컴퓨팅 아키텍처에서 일부 인텔리전스를 클라이언트로 이동하면 구성 요소를 더 간단하게 분할하여 확장할 수 있습니다. 또한 캐싱을 데이터가 사용되는 위치에 더 가깝게 이동하는 것이 훨씬 쉬워져 확장에 도움이 됩니다.
- 개발자 생산성 - 데이터를 저장하고 검색하는 새로운 방법을 배워야 하는 것은 생산성을 떨어뜨리지만, 데이터 모델 변경을 선언할 필요 없이 데이터 구조와 지속성 메커니즘을 발전시킬 수 있다는 점에서 양쪽 모두에 도움이 됩니다(DBA를 참여시키는 등).
- 가용성 - 일부 애플리케이션의 경우, 현재 일부만 사용할 수 없더라도 대부분의 데이터를 사용할 수 있는 것이 전적으로 합리적일 수 있습니다.
- 지리적 분포 - 데이터에 대해 조금만 다르게 생각하기 시작하면 데이터를 지리적으로 쉽게 배포할 수 있습니다.
머지않은 미래에 이에 대해 더 많은 글을 써야 할 것 같습니다. 이전 작업(학술 논문도 일부 포함)을 많이 살펴봤는데 흥미로운 아이디어가 몇 가지 있습니다. 추신: TechZulu에서 세션을 녹화했습니다. 언젠가는 그들의 사이트에 있을지도 모릅니다... 링크를 확인했지만 아직 없습니다.
