백엔드, 기계 학습 및 서버리스 - XNUMX월 Habr 컨퍼런스에서 가장 흥미로운 내용

Habr 회의는 데뷔 이야기가 아닙니다. 이전에는 300~400명을 대상으로 상당히 큰 규모의 토스터 이벤트를 개최했지만 이제는 소규모 주제별 회의가 적합하다고 결정했으며, 예를 들어 댓글에서 방향을 설정할 수 있습니다. 이 형식의 첫 번째 컨퍼런스는 XNUMX월에 열렸으며 백엔드 개발에 전념했습니다. 참가자들은 State Services 포털에서 백엔드에서 ML로의 전환 기능과 Quadrupel 서비스 설계에 대한 보고서를 듣고 서버리스 전용 라운드 테이블에도 참여했습니다. 행사에 직접 참석하지 못하신 분들을 위해 이번 포스팅에서 가장 흥미로운 내용을 알려드리겠습니다.

백엔드 개발부터 머신러닝까지

데이터 엔지니어는 ML에서 무엇을 하나요? 백엔드 개발자와 ML 엔지니어의 업무는 어떻게 유사하고 다른가요? 첫 번째 직업을 두 번째 직업으로 바꾸려면 어떤 길을 택해야 합니까? 10년간의 백엔드 작업 끝에 머신러닝에 입문한 Alexander Parinov가 이런 말을 했습니다.

알렉산더 파리노프

현재 Alexander는 X5 Retail Group에서 컴퓨터 비전 시스템 설계자로 일하고 있으며 컴퓨터 비전 및 딥 러닝(github.com/creafz)과 관련된 오픈 소스 프로젝트에 기여하고 있습니다. 머신러닝 경진대회 중 가장 인기 있는 플랫폼인 캐글 마스터(kaggle.com/creafz) 세계랭킹 100위권 안에 참여해 그의 실력을 입증했다.

머신러닝으로 전환하는 이유

500년 반 전, 구글의 딥러닝 기반 인공지능 연구 프로젝트인 구글 브레인(Google Brain)의 책임자인 제프 딘(Jeff Dean)은 어떻게 구글 번역의 XNUMX만 줄의 코드가 단 XNUMX줄로 구성된 텐서 플로우(Tensor Flow) 신경망으로 대체되었는지 설명했습니다. 네트워크를 훈련한 후 데이터 품질이 향상되고 인프라가 단순해졌습니다. 이것이 우리의 밝은 미래인 것 같습니다. 우리는 더 이상 코드를 작성할 필요가 없으며 뉴런을 만들고 데이터로 채우는 것으로 충분합니다. 그러나 실제로는 모든 것이 훨씬 더 복잡합니다.

Google의 ML 인프라

신경망은 인프라의 작은 부분일 뿐입니다(위 그림의 작은 검은색 사각형). 데이터 수신, 처리, 저장, 품질 확인 등을 위해서는 더 많은 보조 시스템이 필요하며, 교육을 위한 인프라, 프로덕션에 기계 학습 코드 배포 및 이 코드 테스트가 필요합니다. 이러한 모든 작업은 백엔드 개발자가 수행하는 작업과 정확히 유사합니다.

기계 학습 과정

ML과 백엔드의 차이점은 무엇인가요?

클래식 프로그래밍에서는 코드를 작성하고 이것이 프로그램의 동작을 결정합니다. ML에는 작은 모델 코드와 모델에 제공하는 많은 데이터가 있습니다. ML의 데이터는 매우 중요합니다. 서로 다른 데이터로 학습된 동일한 모델이 완전히 다른 결과를 표시할 수 있습니다. 문제는 데이터가 거의 항상 서로 다른 시스템(관계형 데이터베이스, NoSQL 데이터베이스, 로그, 파일)에 분산되어 저장된다는 것입니다.

데이터 버전 관리

ML에는 기존 개발에서처럼 코드 버전 관리뿐만 아니라 데이터 버전 관리도 필요합니다. 모델이 학습된 내용을 명확하게 이해하는 것이 필요합니다. 이를 위해 널리 사용되는 Data Science Version Control 라이브러리(dvc.org)를 사용할 수 있습니다.

데이터 마크업

다음 작업은 데이터 라벨링입니다. 예를 들어, 그림의 모든 개체를 표시하거나 해당 개체가 속한 클래스를 말합니다. 이는 API를 통해 작업이 크게 단순화되는 Yandex.Toloka와 같은 특수 서비스를 통해 수행됩니다. "인적 요소"로 인해 어려움이 발생합니다. 동일한 작업을 여러 수행자에게 맡기면 데이터 품질을 향상하고 오류를 최소한으로 줄일 수 있습니다.

텐서보드의 시각화

결과를 비교하고 일부 측정항목을 기반으로 최상의 모델을 선택하려면 실험 로깅이 필요합니다. 텐서보드(Tensor Board)와 같은 시각화를 위한 다양한 도구 세트가 있습니다. 그러나 실험을 저장하는 이상적인 방법은 없습니다. 소규모 회사에서는 Excel 스프레드시트를 사용하는 경우가 많은 반면, 대규모 회사에서는 결과를 데이터베이스에 저장하기 위해 특수 플랫폼을 사용합니다.

머신러닝을 위한 플랫폼은 많지만 그 중 어느 것도 요구 사항의 70%를 충족하지 못합니다.

훈련된 모델을 프로덕션에 투입할 때 직면해야 하는 첫 번째 문제는 데이터 과학자들이 선호하는 도구인 Jupyter Notebook과 관련이 있습니다. 모듈성이 없습니다. 즉, 출력은 논리적 조각, 즉 모듈로 나누어지지 않은 코드의 "발보"입니다. 클래스, 함수, 구성 등 모든 것이 뒤섞여 있습니다. 이 코드는 버전 관리 및 테스트가 어렵습니다.

이 문제를 어떻게 처리합니까? Netflix처럼 스스로 사임하고 이러한 랩탑을 프로덕션에서 직접 실행하고 데이터를 입력으로 전송하고 결과를 얻을 수 있는 자체 플랫폼을 만들 수 있습니다. 모델을 프로덕션에 적용하는 개발자가 코드를 정상적으로 다시 작성하여 모듈로 나누도록 할 수 있습니다. 그러나 이 접근 방식을 사용하면 실수하기 쉽고 모델이 의도한 대로 작동하지 않습니다. 따라서 이상적인 옵션은 모델 코드에 Jupyter Notebook 사용을 금지하는 것입니다. 물론 데이터 과학자들이 이에 동의한다면 말입니다.

블랙박스로 모델링

모델을 생산에 투입하는 가장 쉬운 방법은 모델을 블랙박스로 사용하는 것입니다. 일종의 모델 클래스가 있고 모델의 가중치(훈련된 네트워크의 뉴런 매개변수)가 주어졌으며 이 클래스를 초기화하면(예측 메서드 호출, 그림 제공) 특정 결과를 얻게 됩니다. 출력으로서의 예측. 내부에서 일어나는 일은 중요하지 않습니다.

모델과 별도의 서버 프로세스

또한 별도의 특정 프로세스를 발생시켜 RPC 대기열을 통해 보낼 수도 있습니다(그림이나 기타 소스 데이터 포함). 출력에서 ​​예측을 받게 됩니다.

Flask에서 모델을 사용하는 예:

@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)

이 접근 방식의 문제점은 성능 제한입니다. 데이터 과학자가 작성한 Phyton 코드가 느리고 최대 성능을 끌어내고 싶다고 가정해 보겠습니다. 이를 위해 코드를 네이티브로 변환하거나 프로덕션에 맞게 조정된 다른 프레임워크로 변환하는 도구를 사용할 수 있습니다. 모든 프레임워크에 이러한 도구가 있지만 이상적인 도구는 없으므로 직접 추가해야 합니다.

ML의 인프라는 일반 백엔드와 동일합니다. Docker와 Kubernetes가 있으며 Docker의 경우에만 NVIDIA에서 런타임을 설치해야 합니다. 이를 통해 컨테이너 내부 프로세스가 호스트의 비디오 카드에 액세스할 수 있습니다. Kubernetes가 비디오 카드로 서버를 관리하려면 플러그인이 필요합니다.

기존 프로그래밍과 달리 ML의 경우 인프라에는 확인하고 테스트해야 하는 다양한 이동 요소(예: 데이터 처리 코드, 모델 교육 파이프라인 및 프로덕션)가 있습니다(위 다이어그램 참조). 파이프라인의 다양한 부분을 연결하는 코드를 테스트하는 것이 중요합니다. 부분이 많고 모듈 경계에서 문제가 자주 발생합니다.

AutoML 작동 방식

AutoML 서비스는 목적에 맞는 최적의 모델을 선택하고 학습시킬 것을 약속합니다. 하지만 이해해야 할 점은 ML에서 데이터는 매우 중요하며 결과는 데이터 준비에 달려 있다는 것입니다. 마크업은 사람이 수행하므로 오류가 많습니다. 엄격한 통제 없이는 결과가 쓰레기일 수 있으며 아직 프로세스를 자동화하는 것도 불가능하므로 전문가(데이터 과학자)의 검증이 필요합니다. 이것이 바로 AutoML이 무너지는 지점입니다. 그러나 이미 데이터를 준비하고 일련의 실험을 실행하여 최상의 모델을 찾으려는 경우 아키텍처를 선택하는 데 유용할 수 있습니다.

머신러닝에 입문하는 방법

ML을 시작하는 가장 쉬운 방법은 모든 딥 러닝 프레임워크(및 일반 프레임워크)에서 사용되는 Python으로 개발하는 것입니다. 이 언어는 이 활동 분야에서 실질적으로 필수입니다. C++는 자율주행차 제어 시스템과 같은 일부 컴퓨터 비전 작업에 사용됩니다. JavaScript 및 Shell - 시각화 및 브라우저에서 뉴런 실행과 같은 이상한 작업을 위한 것입니다. Java 및 Scala는 빅 데이터 작업 및 기계 학습에 사용됩니다. R과 Julia는 수리통계학을 공부하는 사람들에게 사랑받는 존재입니다.

실무 경험을 쌓기 위한 가장 편리한 방법은 Kaggle을 이용하는 것입니다. 플랫폼 대회에 참가하면 XNUMX년 이상의 이론 공부가 가능합니다. 이 플랫폼에서는 다른 사람이 게시하고 주석을 단 코드를 가져와서 개선하고 목적에 맞게 최적화할 수 있습니다. 보너스 - Kaggle 순위가 급여에 영향을 미칩니다.

또 다른 옵션은 백엔드 개발자로 ML 팀에 합류하는 것입니다. 동료의 문제 해결을 도와줌으로써 경험을 쌓을 수 있는 머신러닝 스타트업이 많이 있습니다. 마지막으로 데이터 과학자 커뮤니티 중 하나인 Open Data Science(ods.ai) 및 기타 커뮤니티에 가입할 수 있습니다.

발표자는 해당 주제에 대한 추가 정보를 링크에 게시했습니다. https://bit.ly/backend-to-ml

"Quadrupel" - "State Services" 포털의 타겟 알림 서비스

예브게니 스미르노프

다음 연사는 전자정부 인프라 개발 부서의 책임자인 Evgeny Smirnov였으며 Quadruple에 대해 이야기했습니다. 이는 Runet에서 가장 많이 방문하는 정부 리소스인 Gosuslugi 포털(gosuslugi.ru)에 대한 대상 알림 서비스입니다. 일일 시청자 수는 2,6만 명이며 사이트에 등록된 사용자는 총 90천만 명이며 그 중 확인된 사용자는 60천만 명입니다. 포털 API의 부하는 30RPS입니다.

국가 서비스의 백엔드에 사용되는 기술

"Quadrupel"은 특별한 알림 규칙을 설정하여 사용자가 자신에게 가장 적합한 순간에 서비스 제안을 받을 수 있도록 지원하는 타겟 알림 서비스입니다. 서비스 개발 시 주요 요구 사항은 유연한 설정과 적절한 메일링 시간이었습니다.

쿼드루펠은 어떻게 작동하나요?

위의 다이어그램은 운전 면허증을 교체해야 하는 상황의 예를 사용하여 Quadrupel의 작동 규칙 중 하나를 보여줍니다. 먼저 서비스는 만료일이 한 달 안에 만료되는 사용자를 찾습니다. 적절한 서비스를 받을 수 있다는 제안이 포함된 배너가 표시되고 이메일로 메시지가 전송됩니다. 기한이 이미 만료된 사용자의 경우 배너와 이메일이 변경됩니다. 권리 교환이 성공적으로 완료되면 사용자는 신원 정보를 업데이트하라는 제안과 함께 다른 알림을 받습니다.

기술적인 관점에서 볼 때 이는 코드가 작성되는 멋진 스크립트입니다. 입력은 데이터이고 출력은 true/false, 일치/일치하지 않음입니다. 사용자의 생일(현재 날짜가 사용자의 생년월일과 동일) 결정부터 복잡한 상황까지 총 50개 이상의 규칙이 있습니다. 매일 이러한 규칙은 알림이 필요한 사람인 약 백만 개의 일치 항목을 식별합니다.

쿼드러플 알림 채널

Quadrupel의 내부에는 사용자 데이터가 저장되는 데이터베이스와 세 가지 애플리케이션이 있습니다. 

• 노동자 데이터 업데이트를 위한 것입니다.
• 휴식 API 배너 자체를 선택하여 포털과 모바일 애플리케이션에 전달합니다.
• 스케줄러 배너 재계산 또는 대량 메일 발송 작업을 시작합니다.

데이터를 업데이트하기 위해 백엔드는 이벤트 기반입니다. 두 가지 인터페이스 - 나머지 또는 JMS. 이벤트가 많은데, 불필요한 요청이 발생하지 않도록 저장하고 처리하기 전에 집계됩니다. 데이터가 저장되는 테이블인 데이터베이스 자체는 사용자의 키와 값 자체와 같은 키 값 저장소처럼 보입니다. 관련 문서의 존재 여부를 나타내는 플래그, 유효 기간, 서비스 순서에 대한 집계 통계 이 사용자 등.

데이터를 저장한 후 배너가 즉시 다시 계산되도록 JMS에 작업이 설정됩니다. 이는 즉시 웹에 표시되어야 합니다. 시스템은 밤에 시작됩니다. 작업은 사용자 간격으로 JMS에 전달되며 이에 따라 규칙을 다시 계산해야 합니다. 이는 재계산에 관련된 프로세서에 의해 선택됩니다. 그런 다음 처리 결과는 다음 대기열로 이동하여 배너를 데이터베이스에 저장하거나 사용자 알림 작업을 서비스로 보냅니다. 이 프로세스는 5~7시간이 소요되며, 언제든지 핸들러를 추가하거나 새 핸들러로 인스턴스를 생성할 수 있기 때문에 쉽게 확장할 수 있습니다.

서비스는 꽤 잘 작동합니다. 하지만 사용자가 늘어나면서 데이터의 양도 늘어나고 있습니다. 이로 인해 Rest API가 복제본을 본다는 사실을 고려하더라도 데이터베이스의 로드가 증가합니다. 두 번째 요점은 JMS인데, 알고 보니 메모리 소비량이 많아 적합하지 않습니다. 대기열 오버플로로 인해 JMS가 중단되고 처리가 중단될 위험이 높습니다. 이후에는 로그를 지우지 않고 JMS를 올리는 것은 불가능합니다.

데이터베이스의 로드 밸런싱을 허용하는 샤딩을 사용하여 문제를 해결할 계획입니다. 또한 데이터 저장 방식을 변경하고 JMS를 Kafka로 변경할 계획도 있습니다. Kafka는 메모리 문제를 해결하는 내결함성 솔루션입니다.

서비스로서의 백엔드와 서버리스

왼쪽부터: 알렉산더 보르가트, 안드레이 토밀렌코, 니콜라이 마르코프, 아라 이스라엘얀

서비스형 백엔드인가요, 아니면 서버리스 솔루션인가요? 원탁에서 이 시급한 문제를 논의한 참가자는 다음과 같습니다.

• Ara Israelyan, CTO CTO이자 Scorocode의 창립자.
• Aligned Research Group의 수석 데이터 엔지니어 Nikolay Markov.
• RUVDS 개발 부서의 책임자인 Andrey Tomilenko. 

대화는 수석 개발자 Alexander Borgart가 진행했습니다. 청취자들이 참여한 토론을 축약 버전으로 제시합니다.

— 귀하가 이해하는 서버리스란 무엇입니까?

앤드류: 이것은 컴퓨팅 모델입니다. 즉, 결과가 데이터에만 의존하도록 데이터를 처리해야 하는 Lambda 함수입니다. 이 용어는 Google이나 Amazon 및 AWS Lambda 서비스에서 나왔습니다. 공급자가 용량 풀을 할당하여 이러한 기능을 처리하는 것이 더 쉽습니다. 동일한 서버에서 다양한 사용자를 독립적으로 관리할 수 있습니다.
니콜라스: 쉽게 말하면 IT 인프라와 비즈니스 로직의 일부를 클라우드, 아웃소싱으로 이전하는 것입니다.
잉꼬: 개발자 입장에서는 자원을 절약하려는 좋은 시도이고, 마케팅 담당자 입장에서는 더 많은 돈을 벌기 위한 좋은 시도입니다.

— 서버리스는 마이크로서비스와 동일합니까?

니콜라스: 아니요, 서버리스는 아키텍처 조직에 가깝습니다. 마이크로서비스는 일부 논리의 원자 단위입니다. 서버리스는 "별도의 엔터티"가 아닌 접근 방식입니다.
잉꼬: 서버리스 함수는 마이크로서비스로 패키징될 수 있지만 이는 더 이상 서버리스가 아니며 Lambda 함수도 아닙니다. 서버리스에서는 함수가 요청되는 순간에만 작동이 시작됩니다.
앤드류: 수명이 다릅니다. Lambda 함수를 시작하고 잊어버렸습니다. 몇 초 동안 작동했으며 다음 클라이언트는 다른 물리적 시스템에서 해당 요청을 처리할 수 있습니다.

— 어느 것이 더 잘 확장됩니까?

잉꼬: 수평으로 확장할 때 Lambda 함수는 마이크로서비스와 정확히 동일하게 작동합니다.
니콜라스: 복제본 수에 관계없이 설정한 만큼만 존재하므로 서버리스는 확장에 문제가 없습니다. Kubernetes에서 복제본 세트를 만들고 "어딘가"에서 20개의 인스턴스를 시작했으며 20개의 익명 링크가 귀하에게 반환되었습니다. 앞으로!

— 서버리스에서 백엔드를 작성할 수 있나요?

앤드류: 이론적으로는 그렇지만 말이 안 됩니다. Lambda 함수는 단일 저장소에 의존하므로 보장이 필요합니다. 예를 들어, 사용자가 특정 거래를 수행한 경우 다음에 연락할 때 해당 사용자는 거래가 수행되었으며 자금이 입금되었음을 확인해야 합니다. 모든 Lambda 함수는 이 호출을 차단합니다. 실제로 여러 서버리스 기능은 데이터베이스에 대한 병목 현상이 발생하는 액세스 지점이 하나 있는 단일 서비스로 전환됩니다.

— 어떤 상황에서 서버리스 아키텍처를 사용하는 것이 합리적입니까?

앤드류: 공유 스토리지가 필요하지 않은 작업 - 동일한 채굴, 블록체인. 계산을 많이 해야 하는 곳. 컴퓨팅 능력이 크다면 "거기서 뭔가의 해시를 계산하세요..."와 같은 함수를 정의할 수 있습니다. 하지만 예를 들어 Amazon의 Lambda 함수와 분산 스토리지를 사용하면 데이터 스토리지 문제를 해결할 수 있습니다. . 그리고 당신은 정규 서비스를 작성하고 있는 것으로 나타났습니다. Lambda 함수는 스토리지에 액세스하고 사용자에게 일종의 응답을 제공합니다.
니콜라스: 서버리스에서 실행되는 컨테이너는 리소스가 극히 제한되어 있습니다. 기억력과 그 밖의 모든 것이 거의 없습니다. 그러나 전체 인프라가 Google, Amazon과 같은 일부 클라우드에 완전히 배포되고 이들과 영구 계약을 맺고 이 모든 것에 대한 예산이 있는 경우 일부 작업에 서버리스 컨테이너를 사용할 수 있습니다. 모든 것이 특정 환경에서 사용하도록 맞춤화되어 있으므로 이 인프라 내부에 있어야 합니다. 즉, 모든 것을 클라우드 인프라에 연결할 준비가 되었다면 실험해 볼 수 있습니다. 장점은 이 인프라를 관리할 필요가 없다는 것입니다.
잉꼬: 서버리스에서는 쿠버네티스, 도커, 카프카 설치 등을 관리할 필요가 없다는 사실이 자기기만이다. 동일한 Amazon과 Google이 이것을 설치하고 있습니다. 또 다른 점은 SLA가 있다는 것입니다. 직접 코딩하는 것보다 모든 것을 아웃소싱하는 것이 좋습니다.
앤드류: 서버리스 자체는 저렴하지만 데이터베이스 등 다른 Amazon 서비스에 대해서는 많은 비용을 지불해야 합니다. 사람들은 API 게이트에 엄청난 금액을 청구했기 때문에 이미 그들을 고소했습니다.
잉꼬: 돈에 관해 이야기한다면 이 점을 고려해야 합니다. 모든 코드를 Serverless로 이전하려면 회사의 전체 개발 방법론을 180도 바꿔야 합니다. 이 작업에는 많은 시간과 비용이 소요됩니다.

— Amazon과 Google의 유료 Serverless에 대한 가치 있는 대안이 있습니까?

니콜라스: Kubernetes에서는 어떤 종류의 작업을 시작하면 실행되고 종료됩니다. 이는 아키텍처 관점에서 볼 때 서버리스에 해당합니다. 큐와 데이터베이스를 사용하여 정말 흥미로운 비즈니스 논리를 만들고 싶다면 이에 대해 좀 더 생각해 볼 필요가 있습니다. Kubernetes를 떠나지 않고도 이 모든 문제를 해결할 수 있습니다. 나는 추가 구현을 끌어내지 않을 것입니다.

— 서버리스에서 무슨 일이 일어나고 있는지 모니터링하는 것이 얼마나 중요합니까?

잉꼬: 시스템 아키텍처 및 비즈니스 요구 사항에 따라 다릅니다. 기본적으로 공급자는 DevOps 팀이 가능한 문제를 이해하는 데 도움이 되는 보고를 제공해야 합니다.
니콜라스: Amazon에는 Lambda의 로그를 포함하여 모든 로그가 스트리밍되는 CloudWatch가 있습니다. 로그 전달을 통합하고 보기, 경고 등에 별도의 도구를 사용합니다. 시작하는 컨테이너에 에이전트를 채울 수 있습니다.

- 요약해보자.

앤드류: Lambda 함수에 대해 생각하는 것이 유용합니다. 마이크로서비스가 아닌 요청을 작성하고 데이터베이스에 액세스하고 응답을 보내는 서비스를 직접 생성하는 경우 Lambda 함수는 멀티스레딩, 확장성 등과 관련된 여러 문제를 해결합니다. 논리가 이러한 방식으로 구축되면 나중에 이러한 Lambda를 마이크로서비스로 전송하거나 Amazon과 같은 타사 서비스를 사용할 수 있습니다. 기술은 유용하고 아이디어도 흥미롭습니다. 이것이 비즈니스에 얼마나 정당한지는 여전히 열려 있는 질문입니다.
Nikolay: 서버리스는 일부 비즈니스 로직을 계산하는 것보다 운영 작업에 더 잘 사용됩니다. 나는 항상 그것을 이벤트 처리라고 생각합니다. Amazon에 있고 Kubernetes에 있다면 그렇습니다. 그렇지 않으면 서버리스를 스스로 시작하고 실행하기 위해 상당한 노력을 기울여야 합니다. 구체적인 비즈니스 사례를 살펴볼 필요가 있습니다. 예를 들어, 현재 내 작업 중 하나는 파일이 디스크에 특정 형식으로 나타나면 해당 파일을 Kafka에 업로드해야 한다는 것입니다. WatchDog이나 Lambda를 사용할 수 있습니다. 논리적인 관점에서는 두 옵션 모두 적합하지만 구현 측면에서는 서버리스가 더 복잡하고 저는 Lambda가 없는 더 간단한 방법을 선호합니다.
잉꼬: 서버리스는 흥미롭고 적용 가능하며 기술적으로 매우 아름다운 아이디어입니다. 조만간 기술은 모든 기능이 100밀리초 이내에 실행되는 수준에 도달할 것입니다. 그러면 원칙적으로 대기 시간이 사용자에게 중요한지 여부에 대해서는 의문의 여지가 없습니다. 동시에 동료들이 이미 말했듯이 서버리스의 적용 가능성은 전적으로 비즈니스 문제에 달려 있습니다.

많은 도움을 주신 후원자분들께 감사드립니다.

• IT 컨퍼런스 공간 «봄» 회의 장소용.
• IT 이벤트 일정 Runet-ID 그리고 출판 "숫자로 보는 인터넷» 정보 지원 및 뉴스를 확인하세요.
• «아크로니스"선물용.
• 아 피트 토 공동창작을 위해.
• "전자통신협회" RAEC 참여와 경험을 위해.
• 메인 스폰서 RUVDS - 모든!

출처 : habr.com