이 글이 무엇에 관한 것인지 더 쉽게 이해하기 위해, Stack Overflow의 평균 일일 통계 변화부터 살펴보겠습니다. 다음 수치는 2013년 11월 12일 기준 통계에서 나온 것입니다:
- 로드 밸런서는 148,084,833개의 HTTP 요청을 수용했습니다
- 이 중 36,095,312장이 페이지 로드였습니다
- 전송에 사용되는 HTTP 트래픽은 833,992,982,627바이트(776GB)
- 총 286,574,644,032바이트(267GB)의 데이터가 수신되었습니다
- 총 1,125,992,557,312바이트(1,048 GB)의 데이터가 전송되었습니다
- 334,572,103개의 SQL 쿼리(HTTP 요청만을 포함)
- 412,865,051건의 Redis 요청
- 태그 엔진 요청 3,603,418건
- SQL 쿼리에 558,224,585 ms(155시간)가 소요되었습니다
- Redis 요청 처리에는 99,346,916ms(27시간)가 소요되었습니다
- 태그 엔진 요청에 132,384,059 ms(36시간)를 소요했습니다
- ASP.Net 프로세스 처리에는 2,728,177,045 ms(757시간)가 소요되었습니다
다음 데이터는 2016년 2월 9일 기준 통계 변동을 보여주므로 비교할 수 있습니다:
- 부하 분산기가 수신한 HTTP 요청: 209,420,973 (+61,336,090)
- 66,294,789 (+30,199,477) 페이지가 로드됩니다
- 전송된 HTTP 데이터: 1,240,266,346,053 (+406,273,363,426) 바이트 (1.24 TB)
- 수신된 총 데이터량: 569,449,470,023 (+282,874,825,991) 바이트 (569 GB)
- 전송된 총 데이터 양: 3,084,303,599,266 (+1,958,311,041,954) 바이트 (3.08 TB)
- SQL 쿼리(HTTP 요청만): 504,816,843 (+170,244,740)
- 레디스 캐시 조회수: 5,831,683,114 (+5,418,818,063)
- 탄력적 검색: 17,158,874건 (2013년 추적 미완료)
- 태그 엔진 요청: 3,661,134 (+57,716)
- SQL 쿼리 실행에 소요되는 누적 시간: 607,073,066 (+48,848,481) ms (168시간)
- Redis 캐시 히트 소모: 10,396,073 (-88,950,843) ms (2.8시간)
- 태그 엔진 요청 소요 시간: 147,018,571 (+14,634,512) ms (40.8시간)
- ASP.Net 처리 소요 시간: 1,609,944,301 (-1,118,232,744) ms (447시간)
- 22.71 (-5.29) ms 49,180,275 이슈 평균 렌더링 시간 (이 중 19.12 ms ASP.Net 소요)
- 11.80 (-53.2) ms 6,370,076 첫 페이지 평균 렌더링 시간 (이 중 8.81 ms 소모 ASP.Net)
왜 ASP.Net 가 하루에 6,100만 건의 요청을 더 처리하면서도 처리 시간은 757시간이나 줄어들고 있는지 궁금하실 수 있습니다(2013년 대비). 이는 주로 2015년 초 서버 업그레이드와 많은 인앱 성능 최적화 작업 덕분입니다. 잊지 마세요: 성능은 여전히 판매 포인트입니다. 구체적인 하드웨어 세부사항이 궁금하다면 걱정하지 마세요. 이 사이트들을 운영하는 서버에 대한 구체적인 하드웨어 정보는 다음 기사에서 부록 형태로 제공할 예정입니다(적절한 시기에 이 링크를 업데이트하겠습니다).
그렇다면 지난 2년 동안 무엇이 변했을까요? 별거 아니고, 서버와 네트워크 장비 몇 개 교체하는 정도입니다. 현재 귀하의 웹사이트를 운영하는 데 사용된 서버들에 대한 개요를 소개합니다(2013년 이후 어떻게 변했는지 참고하세요).
- 4대의 Microsoft SQL Server 서버(이 중 2대는 새로운 하드웨어를 사용)
- 11대의 IIS 웹 서버 (신형 하드웨어)
- 2대의 Redis 서버(신형 하드웨어)
- 3개의 태그 엔진 서버(그중 2대는 신형 하드웨어를 사용)
- 3 Elasticsearch 서버 (위와 동일)
- 4대의 HAProxy 부하 분산 서버 (CloudFlare를 지원하기 위해 2대 추가)
- 네트워크 장치 2대(Nexus 5596 코어 + 2232TM 패브릭 익스텐더, 모든 기기가 10Gbps 대역폭으로 업그레이드됨)
- Fortinet 800C 방화벽 2개 (Cisco 5525-X ASA를 대체함)
- Cisco ASR-1001 라우터 2대 (Cisco 3945 라우터 대체)
- Cisco ASR-1001-x 라우터 2대 (새로워!) ）
Stack Overflow를 작동시키려면 무엇이 필요할까요? 2013년 이후로 크게 달라진 것은 없지만, 앞서 언급한 최적화와 새로운 하드웨어 덕분에 이제 웹 서버는 단 하나만 필요하다. 우리는 이미 여러 차례 우연히 이 상황을 시험해 보았고, 성공을 거두었습니다. 참고로 말씀드리자면: 저는 그냥 효과가 있다고 말한 것뿐, 좋은 생각이라고 말한 것은 아닙니다. 하지만 이런 일이 일어날 때마다 꽤 흥미롭습니다.
이제 서버 확장 아이디어에 대한 기본 수치를 알았으니, 어떻게 멋진 웹페이지를 만들었는지 살펴보겠습니다. 완전히 독립적으로 존재하는 시스템은 드물며(우리 시스템도 예외는 아니며), 이 부분들을 통합하는 총체적 관점이 없으면 건축 계획의 의미가 크게 축소됩니다. 우리의 목표는 전체 상황을 파악하는 것입니다. 앞으로 각 분야별로 깊이 다루는 글들이 많이 나올 것입니다. 이 글은 핵심 하드웨어의 논리 구조를 요약한 것이고, 다음 글에서는 이 하드웨어에 대한 구체적인 세부 사항을 다룰 것입니다.
이 하드웨어가 현재 어떻게 생겼는지 보고 싶다면, 2015년 2월에 서버를 업그레이드할 때 제가 찍은 캐비닛 A 사진 몇 장을 첨부합니다 (캐비닛 B는 정확히 동일합니다):
이제 아키텍처 레이아웃을 살펴보겠습니다. 다음은 주요 기존 시스템의 논리 아키텍처에 대한 요약입니다:
기본 원칙
다음은 차례로 소개할 필요가 없는 몇 가지 일반적인 원칙들입니다:
- 모든 기기에는 중복 백업이 있습니다.
- 모든 서버와 네트워크 장치는 최소 두 개의 10Gbps 대역폭 연결을 갖추고 있습니다.
- 모든 서버는 두 개의 전원 공급원을 갖추고 있으며, 이 두 개의 UPS 유닛 세트, 그 뒤에 두 개의 발전기, 그리고 두 개의 그리드 전압 피드포워드를 통해 전력을 공급합니다.
- 모든 서버는 랙 A와 랙 B에 중복 백업이 있습니다.
- 모든 서버와 서비스는 별도의 데이터 센터(콜로라도)에 이중 중복 백업을 가지고 있지만, 저는 주로 뉴욕을 다루고 있습니다.
- 모든 기기에는 중복 백업이 있습니다.
인터넷
먼저 저희 웹사이트를 찾아야 하는데, DNS 관련 서비스입니다. 웹사이트 찾기가 빠르기 때문에, 이제 CloudFlare에 이 서비스를 제공하고 있습니다. 그들은 전 세계 구석에 DNS 서버를 보유하고 있기 때문입니다. 우리는 API를 통해 DNS 레코드를 업데이트하며, API가 DNS를 "관리"하는 역할을 맡고 있습니다. 하지만 우리의 악랄한 마음속에는, 깊은 신뢰 문제 때문에 여전히 자체 DNS 서버를 가지고 있습니다. 종말이 종말처럼 심각할 때—아마도 GPL, Punyon, 캐싱 문제 때문일 수 있습니다—사람들이 여전히 주의를 돌리기 위해 프로그래밍을 원할 때, 우리는 자체 DNS 서버로 전환합니다.
브라우저가 우리의 숨겨진 장소를 찾으면, 뉴욕의 4개 ISP(Level 3, Zayo, Cogent, Lightower)에서 온 HTTP 트래픽이 네 개의 고급 라우터 중 하나로 들어옵니다. 우리는 네트워크 제공업체의 피어 투 피어 트래픽을 제어하고 가장 효율적인 접근 방식을 제공하기 위해 국경 게이트웨이 프로토콜(BGP, 매우 표준적인 프로토콜)을 사용합니다. ASR-1001과 ASR-1001-X 라우터는 두 그룹으로 나뉘며, 각각 액티브/액티브 모드를 사용해 두 네트워크 제공업체의 트래픽을 처리해야 합니다 – 여기에는 중복 백업이 있습니다. 모두 동일한 물리적 대역폭인 10Gbps를 가지지만, 외부 트래픽은 외부 VLAN과 독립적이며 별도로 부하 분산에 연결되어 있습니다. 트래픽이 라우터를 통과하면 로드 밸런서로 넘어가게 됩니다.
두 데이터 센터 간에 10Gbps 대역폭의 MPLS가 있다는 점을 언급할 때가 된 것 같지만, 이는 웹사이트 서비스와는 직접적으로 관련이 없습니다. 우리는 이 기술을 사용하여 특정 비상 상황에 대응하기 위해 오프사이트 복제와 신속한 데이터 복구를 수행합니다. "하지만 닉, 이건 중복이 없어!" 기술적인 관점에서 보면(긍정적인 의미에서) 맞습니다. 이 수준에서는 단일 고장 지점입니다. 하지만 잠깐만요! 네트워크 제공업체를 통해 두 개의 추가 OSPF 장애 전환 경로도 있습니다(MPLS가 첫 번째 선택이고, 비용 문제로 두 번째와 세 번째 선택입니다). 앞서 언급한 각 장치 세트는 장애 조치 시 네트워크 트래픽의 부하 분산을 위해 콜로라도 데이터 센터에 적절히 연결됩니다. 물론, 이 두 장치를 서로 연결해 네 개의 경로 세트가 될 수도 있었겠지만, 그건 잊고 다음으로 넘어가겠습니다.
부하 분산 (HAProxy)
로드 밸런싱은 CentOS 7(우리가 가장 좋아하는 리눅스 버전)에서 실행되는 HAProxy 1.5.15로 구현되었습니다. 그리고 HAProxy에 TLS(SSL) 보안 전송 프로토콜을 추가하세요. 또한 HTTP/2 프로토콜 지원을 즉시 제공할 HAProxy 1.7도 주시하고 있습니다.
듀얼 10Gbps LACP 네트워크 연결을 가진 다른 서버와 달리, 각 로드 밸런서는 외부 네트워크용과 DMZ용 두 개의 10Gbps 연결을 가지고 있습니다. 이 서버들은 SSL 프로토콜 계층을 보다 효율적으로 처리할 수 있도록 64GB 이상의 메모리를 갖추고 있습니다. 더 많은 TLS 세션을 메모리에 캐시하고 재사용할 수 있을 때, 동일한 클라이언트에 연결할 때 소모하는 컴퓨팅 자원이 줄어듭니다. 이로 인해 세션을 더 빠르고 저렴하게 복원할 수 있습니다. 메모리는 너무 저렴해서 쉽게 선택할 수 있습니다.
로드 밸런싱 자체는 쉽게 설정할 수 있습니다. 우리는 여러 IP에서 서로 다른 웹사이트를 듣고(주로 인증서와 DNS 관리 목적으로), 트래픽을 주로 호스트 헤더에 따라 다른 백엔드로 라우팅합니다. 여기서 하는 유일한 일은 속도를 제한하고 웹 계층에서 헤더 정보를 스크래핑해 HAProxy 시스템 로그 메시지에 로그인하는 것입니다. 이렇게 하면 각 요청마다 성능 지표를 기록할 수 있습니다. 이 부분은 나중에 자세히 언급하겠습니다.
웹 계층 (IIS 8.5, ASP.Net MVC 5.2.3, .Net 4.6.1)
로드 밸런싱은 우리가 주 웹 서버(01-09)라고 부르는 9대와 2대의 개발 웹 서버(10-11, 테스트 환경) 간에 트래픽을 분산시킵니다. 메인 서버는 Stack Overflow, Careers, 그리고 모든 Stack Exchange 사이트를 운영하며, meta.stackoverflow.com 와 meta.stackexchange.com 은 두 개의 다른 서버에서 실행됩니다. 메인 Q&A 앱 자체는 다중 테넌트(multi-tenant)로, Q&A 사이트의 모든 요청을 단일 앱이 처리합니다. 즉, 하나의 애플리케이션 풀에서 전체 Q&A 앱을 하나의 서버에서 실행할 수 있습니다. Careers, API v2, Mobile API 등 다른 앱들은 독립적입니다. 마스터 서버와 개발자 서버에서 IIS에서 볼 수 있는 내용은 다음과 같습니다:
다음은 Opserver(내부 모니터링 대시보드)에서 볼 수 있는 Stack Overflow 웹 계층의 분포입니다:
그리고 이 웹 서버들의 자원 소비량은 다음과 같습니다:
왜 우리가 너무 많은 자원을 제공하는지에 대해서는 후속 기사에서 더 자세히 다룰 예정이며, 롤링 빌드, 여유, 중복성에 초점을 맞추겠습니다.
서비스 계층(IIS, ASP.Net MVC 5.2.3, . NET 4.6.1과 HTTP. SYS)
웹 계층 옆에는 서비스 계층이 있습니다. 또한 Windows 8.5R2에서 IIS 2012 위에서 실행됩니다. 이 계층은 웹 계층과 운영 환경의 다른 내부 시스템을 지원하는 내부 서비스를 실행합니다. 주요 서비스로는 태그 엔진을 실행하며 http.sys(IIS가 아님)를 기반으로 하는 "Stack Server"가 있습니다; Providence API(IIS 기반). 흥미로운 사실: 스택 서버가 2분 간격으로 문제 목록을 새로고침할 때 L2와 L3 캐시에 매우 자주 접근하기 때문에 두 프로세스를 서로 다른 소켓에 연결해야 했습니다.
이 서비스를 실행하는 기기들은 태그 엔진과 백엔드 API에 매우 중요하므로 중복되어야 하지만 9배 중복되어서는 안 됩니다. 예를 들어, 우리는 데이터베이스에서 모든 기사와 태그를 n분마다 불러오는데(현재는 2분) 이 정도는 적지 않습니다. 웹 계층에서 이 로드 작업을 9번 반복하고 싶지 않고, 3번이면 안전합니다. 또한 태그 엔진과 탄성 인덱스 작업(이 계층에서 실행됨)의 계산 및 데이터 로딩 특성을 최적화하기 위해 이 서버들에 대해 다양한 하드웨어 구성을 사용합니다. "태그 엔진" 자체는 비교적 복잡한 주제로, 전용 글에서 다룰 예정입니다. 기본 원리는 /questions/tagged/java 주소에 접근할 때, 태그 엔진을 방문해 그에 맞는 질문을 받는다는 것입니다. 엔진은 /search를 제외한 모든 태그 매칭을 처리하기 때문에, 새로운 내비게이션을 포함한 모든 곳에서 이 서비스를 통해 데이터를 받습니다.
캐싱 및 게시/구독 (레디스)
저희도 일부 지역에서 Redis를 사용했는데, 안정성이 매우 안정적입니다. 월간 최대 1,600억 건의 작업이 있지만, 인스턴스당 CPU는 보통 더 낮은 2%를 넘지 않습니다:
저희는 L1/L2 수준의 캐싱 시스템에 Redis를 사용합니다. "L1" 레벨은 웹 서버나 유사한 애플리케이션에서 작동하는 HTTP 캐시입니다. "L2" 레벨은 이전 레벨 캐시가 실패한 후 Redis를 통해 데이터를 얻는 것입니다. 우리의 데이터는 Marc Gravel이 작성한 protobuf-dot-net을 통해 구현된 Protobuf 형식으로 저장됩니다. Redis 클라이언트에서는 자체 개발한 오픈소스 라이브러리인 StackExchange.Redis 라이브러리를 사용했습니다. 웹 서버가 L1과 L2 캐시 모두에 도달하지 못하면, 데이터 소스(데이터베이스 쿼리, API 호출 등)에서 데이터를 가져와 결과를 로컬 캐시와 Redis에 저장합니다. 다음 서버는 같은 데이터를 가져올 때 L1 캐시에서 빠질 수 있지만, L2/Redis에서 데이터를 가져와 데이터베이스 쿼리나 API 호출이 필요 없습니다.
또한 Q&A 사이트도 많이 운영하는데, 각 사이트마다 L1/L2 캐시가 있습니다: L1 캐시에는 키가 프리픽스로, 데이터베이스 ID는 L2/Redis 캐시에 있습니다. 이 주제는 앞으로의 기사에서 깊이 다룰 예정입니다.
모든 사이트 인스턴스를 실행하는 두 개의 주요 Redis 서버(마스터 하나와 슬레이브 하나) 외에도, 두 개의 전용 슬레이브 서버를 사용해 머신러닝 인스턴스(주로 메모리 문제를 위해)를 구축했습니다. 이 서버 그룹은 홈페이지에 질문을 추천하거나 더 나은 일자리 매칭을 제공하는 데 사용됩니다. 이 플랫폼은 프로비던스(Providence)라고 불리며, 케빈 몬트로즈가 이에 대해 글을 썼습니다.
메인 Redis 서버는 256GB RAM(약 90GB 사용)을 가지고 있고, Providence 서버는 384GB 메모리(약 125GB 사용)를 가지고 있습니다.
Redis는 단순히 캐싱용이 아니라, 한 서버가 메시지를 게시하고 다른 구독자들(서버 내 다운스트림 클라이언트의 Redis 포함)이 메시지를 받을 수 있는 게시 및 구독 메커니즘도 갖추고 있습니다. 우리는 이 메커니즘을 사용하여 웹 서버에서 캐시 일관성을 유지하기 위해 다른 서비스의 L1 캐시를 지웁니다. 하지만 또 다른 중요한 용도가 있습니다: 웹소켓입니다.
Websockets(NetGain)
웹소켓을 사용해 상단 바의 알림, 투표, 새로운 내비게이션, 새로운 답변, 댓글 등 실시간 업데이트를 사용자에게 전달합니다.
소켓 서버 자체는 웹 계층에서 네이티브 소켓을 사용하여 실행됩니다. 이 애플리케이션은 오픈소스 라이브러리 구현인 StackExchange.NetGain을 기반으로 한 매우 작은 애플리케이션입니다. 피크 시간대에는 약 50만 개의 동시 웹소켓 연결이 있었는데, 이는 많은 브라우저입니다. 재미있는 사실: 이 브라우저들 중 일부는 18개월 이상 운영되어 있는데, 개발자들이 아직 살아있는지 확인하려면 누군가를 찾아야 할 것입니다. 다음 차트는 이번 주 웹소켓 동시성 패턴을 보여줍니다:
왜 웹소켓을 사용하나요? 우리 규모에서는 여론조사보다 훨씬 효율적입니다. 이렇게 하면 적은 자원으로 더 많은 데이터를 전달하고 사용자에게 더 실시간으로 대응할 수 있습니다. 하지만 이 접근법에도 문제가 있습니다: 임시 포트, 로드 밸런서에서 소진된 파일 핸들 등이 매우 흥미로운 문제이며, 이에 대해서는 나중에 다루겠습니다.
탐색 (Elasticsearch)
스포일러: 여기서 흥분할 만한 것은 별로 없습니다. 웹 계층은 Elasticsearch 1.4를 사용하며, 초경량, 고성능 StackExchange.Elastic 클라이언트를 구현합니다. 대부분의 것과 달리, 이 부분은 오픈소스로 만들 계획이 없습니다. 왜냐하면 이 부분은 우리가 사용해야 할 API의 아주 작은 부분만 노출되기 때문입니다. 공개하는 것이 손실보다 크고 개발자들을 혼란스럽게 할 뿐이라고 확신합니다. 이런 곳에서는 elastic:/search를 사용해 관련 질문을 계산하고 질문할 때 제안을 합니다.
각 Elastic 클러스터(각 데이터 센터별 하나)는 3개의 노드로 구성되며, 각 노드는 고유한 인덱스를 가지고 있습니다. 커리어 사이트에도 추가 색인이 있습니다. 탄력적인 구성에서 약간 덜 표준적인 부분은 3대 서버 클러스터가 일반 구성보다 약간 더 강력하다는 점입니다: 각 서버는 SSD 스토리지, 192GB 메모리, 10Gbps 대역폭의 듀얼 네트워킹을 사용합니다.
Stack Server라는 동일한 애플리케이션 도메인(네, 여기서 .Net Core에 의해 이리저리 흔들렸습니다)에도 태그 엔진이 탑재되어 있으며, 이 엔진은 연속 인덱싱을 위해 Elasticsearch를 사용합니다. 여기서는 SQL Server(데이터 소스)에서 ROWVERSION을 사용해 Elastic의 '마지막 장소' 문서와 비교하는 작은 요령을 사용합니다. 순차적이기 때문에, 마지막 방문 후에 수정된 콘텐츠가 있으면 쉽게 크롤링하고 색인화할 수 있습니다.
우리가 SQL 전체 텍스트 검색 같은 기술 대신 Elasticsearch를 사용하는 주된 이유는 확장성과 비용 효율성 때문입니다. SQL은 CPU에서 상대적으로 비싼 반면, Elastic은 훨씬 저렴하고 최근에 많은 새로운 기능이 있습니다. 왜 솔르를 사용하지 않나요? 네트워크 전체를 탐색해야 하는데(동시에 여러 인덱스를 사용하면서), Solr는 이 시나리오를 지원하지 않습니다. 아직 2.x를 사용하지 않은 이유는 2.x에서 타입이 많이 바뀌어서 업그레이드하려면 모든 것을 다시 인덱싱해야 하기 때문입니다. 요구사항 변경이나 마이그레이션을 계획할 시간이 부족합니다.
데이터베이스 (SQL Server)
우리는 SQL Server를 단일 진실의 출처로 사용합니다. Elastic과 Redis의 모든 데이터는 SQL Server에서 나옵니다. 저희는 두 개의 SQL Server 클러스터를 보유하고 있으며 AlwaysOn 가용성 그룹으로 구성되어 있습니다. 각 클러스터는 뉴욕에 주 서버(거의 모든 부하를 담당)와 복제 서버, 그리고 콜로라도에 있는 복제 서버(재해 복구 데이터 센터)를 보유하고 있습니다. 모든 복사 작업은 비동기식입니다.
첫 번째 클러스터는 각각 384GB 메모리, 4TB 용량의 PCIe SSD, 그리고 두 개의 12코어 CPU를 갖춘 Dell R720xd 서버 세트입니다. 여기에는 Stack Overflow, Sites(별로인 이름이라 나중에 설명할게요), PRIZM, 그리고 모바일 데이터베이스가 포함되어 있습니다.
두 번째 클러스터는 768GB 메모리, 6TB 용량의 PCIe SSD, 그리고 2개의 8코어 CPU를 탑재한 Dell R730xd 서버 세트입니다. 이 클러스터에는 경력, 오픈 ID, 채팅, 예외 로그, 기타 Q&A 사이트(예: 슈퍼 유저, 서버 결함 등)가 포함됩니다.
데이터베이스 계층에서는 CPU 사용률을 매우 낮은 수준으로 유지하고자 하지만, 실제로는 계획된 캐싱 문제가 발생할 때(이를 문제 해결 중) CPU 사용률이 약간 더 높아질 수 있습니다. 현재 NY-SQL02와 04가 주 서버이고 01과 03이 복제 서버이며, SSD 업그레이드 때문에 오늘 재부팅했습니다. 지난 24시간 동안 그들의 성과는 다음과 같습니다:
SQL의 사용은 매우 간단합니다. 단순하다는 것은 빠르다는 뜻입니다. 일부 쿼리 문은 왜곡될 수 있지만, SQL 자체와의 상호작용은 꽤 네이티브한 방식으로 이루어집니다. 저희는 일부 기존 Linq2SQL을 사용하고 있지만, 모든 신규 개발은 POCO를 사용하는 오픈소스 마이크로 ORM 프레임워크인 Dapper를 사용합니다. 다른 방식으로 설명하자면: Stack Overflow는 데이터베이스에 저장 프로시저가 하나뿐이고, 이 마지막 남은 저장 프로시저를 제거하고 코드로 대체할 예정입니다.
도서관
그럼 생각을 바꿔보자, 여기 좀 더 직접적으로 도움이 될 수 있는 것들이 있어. 전에 몇 가지 언급한 적이 있지만, 저희가 관리하고 모두가 사용하는 많은 오픈소스 .Net 라이브러리 목록을 드리겠습니다. 우리는 이들을 오픈 소스로 만들었는데, 이들은 핵심 비즈니스 가치가 없기 때문이지만, 전 세계 개발자들을 도울 수 있기 때문입니다. 지금 여러분도 잘 활용할 수 있길 바랍니다:
- Dapper (.Net Core) – ADO.Net 를 위한 고성능 마이크로 ORM 프레임워크
- StackExchange.Redis – 고성능 Redis 클라이언트
- MiniProfiler – 모든 페이지에서 사용하는 경량 프로파일러 (Ruby, Go, Node도 지원합니다)
- Exceptional – SQL, JSON, MySQL 등에서 오류 기록을 위한 기능
- Jil – 고성능 JSON 직렬화 및 디직렬라이저
- Sigil – .Net CIL 생성 도우미 (C#이 충분히 빠르지 않을 때 사용)
- NetGain – 고성능 웹소켓 서버
- Opserver – 대부분의 시스템을 직접 폴링하며 Orion, Bosun, WMI에서 정보를 가져올 수 있는 모니터링 대시보드
- Bosun – 백그라운드에서 모니터링 시스템, Go로 작성됨
|
게시됨 2018. 4. 11. 오후 5:33:18
|
|
|
|
