Azure Everywhere

 퍼블릭 클라우드 하면 떠오르는 세 곳이 AWS, MS Azure, GCP 입니다.

AWS가 전 세계의 시장을 점유하고 있으며, GCP는 약간은 다른 노선을 걷고 있는가운데 최근 MS Azure의 적극적인 B2B시장 공략이 눈에 보입니다.

이와 관련하여 첫번째로 summit행사가 열렸으며 그 이름이 Azure Everywhere 입니다.


<오전세션>

오전세션은 다음과 같았습니다. 

키워드는 다음과 같습니다.

 - 개발자 중심

 - AI 대중화

 - 기술변화에 따른 사업구조 변화


<GitHub : 개발자 중심의 클라우드 플랫폼 응용과 진화의 방향>

세션의 설명에 앞서서 수년간 변화해온 IT를 살펴볼 필요가 있습니다.


 과거에는 IT의 핵심가치가 <원가절감>, <생산성 향상>에 있었습니다. 전통적인 산업의 비지니스가 존재했고 그 비지니스 프로세스를 그대로 모델링하여 IT시스템을 구축하여 서포트하는 것이었습니다. EA를 설계하고 각 도메인의 SA,DA,TA위에 비지니스를 분석하여 설계하면 개발자는 그대로 개발하는 것이었습니다. 각 영역을 담당하는 전문가들이 있었으며 대부분 외부 인력이였기 때문에 공정과 절차가 중요했으며 소프트웨어도 납품받아서 사용하는 것이 일반적이었습니다.


 그러나 사업환경이 점차 급변하면서 IT자체를 상품으로 하는 새로운 비지니스들이 출현하기 시작했습니다. 산업간의 경계가 무너지고 모든 기업이 소프트웨어 기업이 되어야만 하는 세상이 다가왔습니다.

 이제는 IT의 핵심이 <가치>가 되었습니다. 끊임없이 변하는 시장환경에 전통적인 개발방법론으로는 대처하기가 어렵고, 뭔가를 개선하고자 프로젝트를 계속 진행해도 여러 한계점만 나타나게 되었습니다. 

(일정지연, SW인력의 소모품화, 요구를 충족하지 못하는 제품, 높은 시스템 유지비용 및 변경비용 등.)


 전 세계적으로 이러한 상황을 극복하기 위해서 많은 시도가 이루어졌고 애자일이 대표적인 사례입니다.

(애자일 선언문은 업종에 관계없이 꼭 한번 읽어보시기를 강추드립니다. 참여하신 분들 이름만 봐도 ㄷㄷㄷ..

다양한 영역에서 애자일하게 일하려는 시도가 있을만큼 배울점이 많습니다.)

 소규모의 팀(6~8명)이 자체적으로 기획/설계/개발/테스트를 빠르게 반복하여 고객에게 가치 있는 제품을 만드는 것을 목표로 합니다. 이러한 과정속에서 자체적으로 개발/운영을 수행하고 본인들에게 필요한 소프트웨어는 오픈소스를 기반으로 직접 만들고 개선하는 것이 일반적이 되었습니다. 특히 오픈소스 진영은 전 세계의 개발자가 함께 개발하는 만큼 그 완성도나 속도는 벤더사를 넘어선지 오래입니다.


 이제 중요한 것은 공정과 절차가 아니라 사람, 신뢰, 협업, 문화입니다. 모든 팀원이 주인정신을 가지고 일해야 합니다. 특히 개발자(과거 아키텍트,개발자,QA등으로 분리되어있던 역할 )가 자주 언급될 수 밖에 없는 것은 최종 결과물(소프트웨어)이 가장 중요하기 때문입니다. 개발자는 앞으로 더욱 주도적으로 제품개발에 참여하며 그 속에서 문제를 파악하고 해결방법을 찾아서 적용해야 하며 과거보다 훨씬 넓고 깊은 역량을 보유하고 있어야 하며 협업을 생활화해야 합니다.

 다시 돌아와서 Github세션을 살펴보겠습니다.

MS가 GitHub을 인수하고 개발자 중심의 회사로 변신한 것은 대단한 일입니다.

 과거 MS는 리눅스와 같은 오픈소스를 적대시하고 탄압했습니다. "리눅스는 암"이라는 유명한 말도 있었죠.  자신들의 비지니스의 걸림돌이었기 때문입니다. 절대로 상용제품을 대체할 수 없다고 했고 무시하며 개발자중심의 세상을 비판했습니다. 

그러나 2014년 "MS는 리눅스를 사랑한다"라고 발표했고, 현시점 오픈소스 기여자 1위는 MS입니다!

(2위가 구글입니다..)


 본 세션에서도 개발자의 생산성을 증가시키고 협업을 가속화하는 것에 집중하여 발표하고 있습니다. 많은 사람들의 우려와는 다르게 Github의 역할은 당분간 계속 변함이 없을 것으로 보입니다.



“MS는 개발자를 최우선으로 하는 기업이며

깃허브와 함께함으로써 개발자의 자유, 개방성, 혁신에 대한 우리의 의지를 강화할 것

“우리는 이번 인수 계약에 담긴 ‘공동체에 대한 책임’을 인식하고 있으며, 

모든 개발자가 시급한 문제를 해결하고 혁신할 수 있도록 돕는 데 최선을 다하겠다”

사티아 나델라 MS 회장, 발표문-



현실은 여전히 많은 개발자들이 소스코드를 작성하는데 50%미만의 시간을 쏟고 있습니다. 


Top 과 Low 의 차이입니다. 새로운 일에 할당하는 비율과, 잡무(?)에 할당하는 비율이 눈에 들어옵니다.

특히 이 그래프를 보면서 지금 아마존에서 일하고는 있는 개발자 친구들이 생각났습니다. 그 친구들의 말에 의하면 80%이상의 시간을 개발에 전념할 수 있도록 모든 절차와 제도가 마련되어 있다고 합니다.


 여러 방법과 도구, 문화를 통해서 이러한 변화를 주도하고 있음을 보여줍니다. 

(개발자들이 사용하는 모든 것이 오픈소스기반으로 Github에 모여있다고 해도 과언이 아닙니다. 누구나 가져가서 쓸수 있습니다. 그러나 쉬운 일은 아니고 공짜도 아니며 본인도 기여해야 합니다.)


최근 마이크로소프트의 행보를 보면

- Github인수등 오픈소스 적극지원

- Windows 10 리눅스 탑재

- VisualStudio Code 오픈소스화 (스크립트 부분에서는 VS Code가 점유율 90% !  )

- MS Azure의 리눅스 지원, 크로스 플랫폼, Intellij Plugin 지원등

등 시장의 반응을 봤을 때 방향은 제대로 잡고 가고 있다는 느낌을 받습니다.


<Databricks : 1% + 99% = AI 대중화>

 말이 필요없는 Databricks입니다. Spark는 Hadoop의 뒤를 이어서 거대한 생태계를 구축하고 있습니다. 

과거에는  자체적으로 클라우드 환경을 구축하고 서비스하려고 시도했지만 퍼블릭클라우드 변화에 맞춰서 MS Azure에 탑재하는 쪽으로 방향을 빠르게 전환한 듯 합니다. 

이전글: http://icthuman.tistory.com/entry/Spark-Summit-2017?category=572958


 Spark를 간단히 설명하면 대용량 병렬처리 프레임워크입니다. 

과거 Hadoop이 가지고 있던 디스크기반의 대용량처리의 한계점을 DAG의 개념을 통해서 메모리기반 처리로 바꾸어 최대 100배의 성능향상을 끌어냈습니다. 대부분의 ML에서는 반복작업이 많은데 Spark는 특히 반복문에서 성능향상이 탁월하기 때문에 ML분야에서 그 효과를 인정받았고 많은 라이브러리들이 Spark기반으로 변환되었습니다. 또한 SparkSQL을 통해서 프로그래밍 없이 SQL로 데이터를 조회할 수 있도록 사용자의 편의성을 증대시켰으며, lambda문법을 활용해서 데이터분석에 반드시 필요한 ETL의 기능까지도 흡수해버렸습니다. 추가로 Spark Streaming,(최근에는 Structured )를 활용해서 배치성 뿐만 아니라 실시간성 데이터까지도 처리합니다.

 이 모든기능을 포함하면서 다양한 분석함수들을 내장해서 누구나 쉽게 데이터분석을 할 수 있도록 하는것이 목표입니다. (Data Engineer와 Data Scientist가 같은 도구를 사용할 수 있다는 것은 큰 메리트입니다.)


Big Data를 해보신분들은 다 아시는 내용입니다. 왜 데이터 분석(AI) 가 어려울까요? 알고리즘이 어려워서? 

알고리즘은 크게 중요하지 않습니다. 아니 물론 중요하기는 합니다만 전문가들은 대부분 다음과 같은 이유를 꼽습니다.


1. (잘 전처리 된) 데이터가 없다. 

2. 무슨 도구를 써야 될지 모르겠다. (딥러닝 프레임워크는 정말 많습니다. Tensor Flow가 유명하긴 합니다.)

3. Data Scientist, Data Engineer가 없다. 혹은 협력이 어렵다.

이에 대해서 Databricks Runtime을 제공하여 ML을 돕는 환경을 Azure상에서 제공한다고 합니다.


또한 Data Preparation 부터 Model 생성/배포를 하나로 묶어주는 mlflow 역시 제공한다고 합니다. 저도 비슷한 것을 만들어봤던 경험이 있는데, Databricks가 한다니 완성도가 기대됩니다.

 각 유형에 따라서 MS Azure상에서 PaaS를 어떻게 활용하여 아키텍처를 구성할 수 있을지에 대한 가이드도 제공하고 있습니다. 다만 배치처리와 온라인처리를 동시에 하는 것이 최근의 추세인만큼 해당 내용을 반영하는 PaaS 구성요소도 빨리 제공이 되었으면 하는 바램입니다. (예를 들면 Druid라던지... )


이와 같은 시도를 통해서 AI의 대중화는 조금 더 빨리 찾아올 것으로 보입니다.


<레드햇 세미나와의 비교>

일전에 레드햇 세미나에서는 주로 클라우드로 인한 어플리케이션의 변화를 다루었습니다.

- 클라우드라는 의미처럼 인프라는 이제 구름속에서 보이지 않게 지탱해주는 존재가 되었습니다. 보다 비지니스와 어플리케이션에 집중할 수 있는 환경이 되었습니다. 또한 예전에는 각자 설치하고 사용했던 많은 환경들이 클라우드 서비스형태로 편하게 제공이 되기 때문에 이를 활용해서 더 많은 효과를 볼 수 있습니다.

- 모든 인프라의 요소들이 기능으로 제공됩니다.  이를 적절하게 활용하여 개발하면 장애복구, 배포/테스트, 릴리즈 등의 많은 작업을 자동화 시킬 수 있습니다. 소프트웨어 디파인이 가능합니다.

- Agile, Devops, CI/CD 등의 요소들도 클라우드에서 제공하기 때문에 연계가 가능합니다.


이번 MS Azure 세미나에서는 클라우드로의 통합, 활용방안, 앞으로의 방향성에 중점을 준 것으로 보입니다.

- 클라우드 도입으로 다양한 산업의 기술 / 비지니스 변화

- 클라우드로 전환할 때 정책, 비용, 도구, 고려사항

- 클라우드를 이용할 때 기존 요소들의 보완기능 (예, 오픈소스의 단점 등)

- 클라우드를 통해서 더 빠르고 쉽게 할 수 있는 것들 (AI, Data, Devops, Application)


<정리>

 여러 회사들이 주최하는 각 행사들은 알게 모르게 본인들의 강점을 어필하고 경쟁사와의 우위를 점하려는 의도들이 숨어있습니다. 대놓고 이야기하는 경우도 있고 아닌 경우도 있습니다. 그러나 여러 회사들이 동일하게 말하는 부분은 주의깊게 들을 필요가 있습니다. 세상이 변화하고 있는 방향이기 때문입니다. 

 모든 회사는 소프트웨어 회사가 될 것이다.
  우리나라 뿐 아니라 전 세계의 유명한 회사들을 보면 이를 명확히 알 수 있습니다. 기존의 도메인은 의미가 없습니다. 구글,네이버,카카오는 광고회사일까요? 애어비엔비는 숙박? 쿠팡, 카카오뱅크, 토스, 배달의 민족... 등 많은 유명한 회사들은 왜 이렇게 열심히 개발자를 뽑고 있을까요..
자체적인 소프트웨어 역량을 보유하고 산업전반의 기술변화와 더불어 사업구조도 같이 변화해야 합니다.

소프트웨어 역량, 그 중심에 개발자가 있습니다. 
 문제를 분석하고 논리적인 해결방법을 찾아서 기술을 통해서 구현하는 것이 개발자(팀)의 본질입니다. 수많은 개발자들이 오픈소스의 세상에서 다양한 제품를 만들고 공유하며 빠르게 개선해 나가고 있습니다. 과거처럼 벤더사가 주도해왔던 솔루션에 대한 종속성도 없어지고 있습니다. 또한 클라우드의 도입으로 많은 부분이 자동화되면서 인프라 또한 소프트웨어의 영역으로 넘어가고 있습니다. 개발자가 사용할 수 있는 기능들이 무궁무진합니다.

- AI는 빠르게 대중화가 될 것입니다. 
 오픈소스 그 중심에 AI가 있습니다. 더욱 넓은 분야에 활용될 것으로 보이며, 바로 가져다 쓸수 있는 데이터와 협업구조 개선, 도구의 출현들이 그 속도를 더욱 가속화 시킬것입니다. 
과거의 시스템에서는 데이터는 보존의 대상이었지만 이제는 활용의 대상이기 때문에 시스템을 만들때부터 접근을 다르게 해야 합니다. 최근 주목받는 여러 프로그래밍의 패러다임 변화역시 Control -> Data 중심으로 변화하고 있습니다.

- 전통적인 아키텍트, 개발자, QA등의 역할은 점차 사라지고 개발자로 통합됩니다.
 Product Owner/Manager등을 제외한 팀 멤버는 모두 제품(소스코드)에 관여합니다. 과거에 개발자만 소스코드를 작성했던 것과는 다르게 이제는 클라우드 배포를 위한 템플릿(인프라)부터 Layer구조/프레임워크/공통부(아키텍처), 비지니스 어플리케이션, 데이터, 테스트코드, 기술문서등 전 영역의 작업의 결과물이 소스코드로 완성되기 때문에 모든 인력이 개발자로 통합되고 있습니다. 포괄적인 문서보다 작동하는 소프트웨어를 중요시 하기 때문입니다.

<참고사이트>

https://agilemanifesto.org/iso/ko/manifesto.html

http://www.hani.co.kr/arti/economy/it/847716.html#csidx143ed953ac12498ac9e048e89f9c66a 

https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C

https://spark.apache.org/






'컨퍼런스' 카테고리의 다른 글

Red Hat Forum 2018 Seoul 후기  (0) 2018.11.07
Spark Summit 2017  (0) 2017.02.16

 최근 몇 년전만 해도 응답시간 수초, 수십개의 서버, 기가단위의 데이터로 시스템이 구성되었지만 오늘날에는 모바일, 수천대의 클라우드 기반환경으로 변화하면 millisecond단위의 응답시간, 페타바이트 데이터 등의 요건으로 인해서 과거의 소프트웨어 아키텍처로는 이를 수용하기가 어려운 상태이다.

 결국 우리는 Responsive, Resilient, Elastic and Message Driven 한 시스템을 원하고 이것을  Reactive Systems이라고 부른다. ( 보다 유연하고 scalabe하면서 장애도 방지하는 그런 시스템)

Reactive Systems are:

Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.

Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.

Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.

Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.

Large systems are composed of smaller ones and therefore depend on the Reactive properties of their constituents. This means that Reactive Systems apply design principles so these properties apply at all levels of scale, making them composable. The largest systems in the world rely upon architectures based on these properties and serve the needs of billions of people daily. It is time to apply these design principles consciously from the start instead of rediscovering them each time.

참고)http://www.reactivemanifesto.org/

===============================================================================================================

슬라이드쉐어에서도 공유가 되고 있으니 참고할 수 있다.

http://www.slideshare.net/mircodotta/go-reactive-eventdriven-scalable-resilient-responsive-systems?qid=bc7cfcab-8c5b-4d37-a122-11590578803f&v=qf1&b=&from_search=11

===============================================================================================================

 디스크, 메모리, 서버등의 자원은 갈수록 저렴해지고 일반적이 되어가고 있으며 동시사용자는 기하급수적으로 늘어났다.

과거 중요한 서비스는 반드시 죽지 않아야 하고 고정되어 requset/response를 보장한다는 개념에서,

이제는 수백,수천개를 띄워놓고 사용자 수에 따라서 서비스량을 조정하면서도 약간의 문제는 상관하지 않고 돌아간다는 개념으로 변화하고 있다.

 

 

패러다임 변화에 따라서 어플리케이션도 변경이 되어야 한다는 내용.

이러한 내용을 반영하여 나온 것이 reactive programming으로 현재 typesafe에서 주도하고 있다.

akka,scala를 통해서 이를 구현하고 있으며 많은 IT서비스기업에서 사용하고 있다.

+ Recent posts