toast meetup2015 - 구름 cloud ide (류성태)
TRANSCRIPT
http://[email protected]
클라우드 코딩 서비스
99DEV 구름은어떻게구름으로개발되고있는가
류성태 / 구름
2015. 11.26 / [email protected]
4 / TOAST Meetup
회사소개
은 클라우드 인프라에 대한 깊은 이해와, 웹 애플리케이션 개발에 대한
적지 않은 노하우로 국내를 넘어서 글로벌 서비스를 표방하는 기술 기반 스타트업
입니다.
사명의 의미는 CODE와 PARADIGM의 합성어로서, 누구든지 언제 어디서나 소프
트웨어를 배우고 개발할 수 있도록 패러다임을 바꾸고자 하는 저희의 비전을 담고
있습니다.
codigm은 현재 언제 어디서나 SW를 배우고, 개발할 수 있도록 해주는 클라우드
코딩 서비스 브랜드인 구름(goorm)을 개발하고 서비스하고 있습니다.
Teach, Learn and Develop SW
5 / TOAST Meetup
Vision
TEACHING
LEARNINGDEVELOPING
SW
누구나 SW를쉽게 개발할수 있는 세상을만듭니다.
이를통해 SW가만드는더 나은 미래를꿈꿉니다.
클라우드코딩 서비스를통해
“개발 환경 구축이라는 장벽을 낮추어
더 많은 사람들이 소프트웨어로
자신의 생각을 실현하도록 돕습니다.”
“소프트웨어 개발을 위한 인력 양성에
긍정적인 순환 구조를 제공하고자 합니다.”
6 / TOAST Meetup
추구하는솔루션
언제 어디서나프로그래밍을배우고, 소프트웨어를개발할수있는클라우드 서비스
TEACHING,LEARNING
CODING,DEVELOPING
ANYTIME,ANYWHERE
ANYONE
7 / TOAST Meetup
제품소개
Docker EnabledReal-time Collaborative EditingVarious Programming Languages Online Build / Debug
goormIDEgoormEDU Cloud Integrated Development EnvironmentCloud Software Development Education Platform
TEACHING, LEARNING CODING, DEVELOPING
구름
8 / TOAST Meetup
서비스로드맵 (~2016)
오픈 베타 미/일 대상 서비스 확대 3.0 유료 서비스 출시, 중어 지원
온라인 코딩 테스트 서비스 출시민간 클라우드 지원 사업 (NIA) 일본 대상 서비스
오픈 베타 정식 유료 출시
SW교육 플랫폼대학용 실습 환경 제공온라인 코딩 테스트
클라우드IDE 서비스무료/유료 버전서비스형/설치형 모두 제공
SW교육 컨텐츠 포탈
구름EDU
구름IDE
구름코딩.com
10 / TOAST Meetup
구름의기본화면
좌측 레이아웃- 프로젝트/클라우드
애플리케이션 개발에 관련된모든 파일들을 프로젝트 단위로관리하거나 클라우드 스토리지를통해 관리할 수 있습니다.
우측 레이아웃- 채팅/문서뷰어/작업내역/아웃라인
우측 레이아웃을 통해 협업 개발자와 채팅을 하거나 문서 뷰어를 함께 보고 해당 소스 코드의 변경 내역이나 전체 구조를 확인할 수 있습니다.창 단위로 관리되는 워크스페이스
소스 코드 에디터나 터미널 등을 창 단위로 관리할 수 있는 워크스페이스가 제공됩니다.
하단 레이아웃 – 디버그/터미널/검색/빌드 아웃풋
하단 레이아웃을 통해 디버그/터미널/검색/빌드 아웃풋에 대한결과를 확인하고 상호작용할 수 있습니다.
기본 툴바
자주 사용하는 기능을 쉽게 선택할 수 있는 버튼들로 구성된 툴바
11 / TOAST Meetup
구름 IDE의주요특징
① 언제 어디서나
웹브라우저만있으면언제어디서나
연속성있는개발을할수있습니다.
그림
② 일관된 개발환경
매번새롭게개발환경을구축할필요없이일
관된개발환경을사용할수있습니다.
그림 그림 그림
③ 다양한 프로그래밍 지원
네이티브및웹개발언어까지다양한언어를
사용할수있고, 코드편집/빌드/서버실행/실
시간린트등을지원합니다.
⑥ 온라인 편집/실시간 협업
별도의에디터설치없이웹에서바로코드를
편집할수있고, 다른팀원들과함께작업할수
있습니다.
⑧ 소스 코드 관리(GIT,SVN)
GIT과SVN을완벽하게지원하며, 원클릭으로
저장소에액세스하고, 작업내용을커밋할수
있습니다.
④ 온라인 빌드/디버그/실행
별도의빌드/디버깅도구를설치하지않고,
웹에서바로빌드및디버깅할수있습니다.
⑦ 협업 도구 제공
메신저수준의채팅기능뿐만아니라
슬라이드, PDF 를공유하여프로젝트의
생산성을높입니다.
⑤ 터미널 연결 기능
자신이작업중이던개발환경을 웹에서바로
터미널로연결하여 필요한작업을수행할수
있습니다.
14 / TOAST Meetup
개발표준 / 제품표준
• 개발 표준
– 개발 언어
• Backend
– Main : node.js
– Sub : C/C++
• Frontend
– Core : javascript (including jquery)
– UI Lib : jQuery UI, bootstrap
– 도구
• 이슈 관리 : Trello
• 형상 관리 : github.com
• 빌드/배포 도구 : 자체 개발 스크립트, grunt
• CI 도구 : (미정)
• 테스트 도구 : nightwatch.js
• WIKI : (미정)
• 제품 표준
– 서비스 성능
• 클라이언트 로딩 시간 : 5초 이내
• 최대 지연 시간 : 3초 이내 (네트워크 원할 시)
– 브라우저 지원
• 1순위 지원 : Chrome / Firefox / Safari
• 2순위 지원 : Edge / IE / Opera
– 서비스 사양
• 개인 컨테이너 사양 (기본 무료)
– 512 MB RAM / 5 GB Storage
– 동작 환경
• 서비스형
– Arch : x86
– OS : Ubuntu 12.04 이상
• 설치형
– Arch : x86, ARM
– OS : Ubuntu 12.04 이상, Mac OSX 10.6 이상
15 / TOAST Meetup
goorm-DEVOPS 프로세스
Doing To be tested
Done
이슈 관리 도구 (트렐로)
Tasks
신규 작업 할당
– 내부 기획을 통해
– 사용자 피드백을 통해
– 테스트 결과를 통해
– dev.goorm.io에서 버그 발견 시
크로스 테스트
– 작업을 완료한 사람과 작업 완료 여부를 판단하는사람은 서로 다른 사람
– UI 테스트 케이스 기반의검증 절차 진행
CARD
테스트 수행 (매일 새벽 1시)
– qa.goorm.io 대상으로 nightwatch.js 를 이용한전체 테스트 케이스수행
개발팀
서비스관리도구 (admin.goorm.io)
서비스 모니터링
– 운영 서버 / 인프라 / 비용 모니터링
– 사용 로그 / 에러 로그 분석
서비스운영스테이지
DOG FOODINGQUALITY
ASSURANCEOPERATION
소스 코드 저장소 (github.com)
UI 테스트 케이스 저장소
– 테스트 케이스 문서 기반으로 자동화를 위한 UI 테스트 케이스 저장소
테스트 자동화 (nightwatch.js)
QA 팀
테스트 결과 레포팅 (매일 오전 7~8시)
– E-MAIL로 전 팀원들에게 레포팅
서비스 관리
– 사용자 관리 (기본 회원 관리, 방문시간, 사용 시간 등)
– 사용자 피드백 관리
– 사용자별 컨테이너 관리
서비스 품질 검증 [개발팀, QA팀]
– 매주 목요일 수행
– 테스트 통과율 100%일 경우에만 릴리즈(수동 테스트 포함)
– 릴리즈 노트로 공지되는 신규 기능/버그 픽스 사항은 매니저급이 실제로 검수
– 대규모 동시 협업 테스트
서비스 애플리케이션 저장소
– 실제 서비스 관련 모든 서비스 애플리케이션 저장소
서비스기획 / 개발프로세스
작업처리우선순위
1. 서비스 중단, 치명적 오류
2. 비즈니스 우선 순위에 따른 개발 작업 (B2B 사업, 서비스 데모 준비 등)
3. 서비스 모니터링 시 이메일/SLACK으로 레포팅되는 에러/버그 사항
4. 크로스 테스트에서 실패되어 리턴된 작업
5. 매일 레포팅되는 테스트 결과에서 통과하지 못한 부분
6. 사용자 피드백 중 버그, UI 깨지는 부분에 대한 작업
7. 사용자 피드백 중 신규 기능인프라 품질 검증 [인프라팀]
– 서비스 API 과부하 테스트
– DOCKER CONTAINER 생성 과부하 테스트
– 각 서비스 접속 부하 테스트 (AS, LB 테스트)
릴리즈전최종품질검증
dev.goorm.io qa.goorm.io goorm.io
19 / TOAST Meetup
장애대처프로세스
모니터링 장애 발생 시 알람(Email, Slack) 복구 처리 장애 원인 분석 장애 재발 방지 대책
• 모니터링
– 인프라 레벨 모니터링 : 대부분은 Amazon API 활용 및 Cloud Watch 서비스 활용
– 시스템 레벨 모니터링 : SSL 인증서 만료 확인 / 시간 동기화 확인 / 프로세스 개수 (데몬들) / RDS, Redis 아마존 콘솔로 모니터링 / goorm-client 동작 여부 확인 / 파일 시스템 데몬 확인
– 어플리케이션 레벨 모니터링 : Rest API 또는 WebSocket Routing 결과에 대한 주기적인 확인
• 인프라 테스트 자동화
– 모니터링에 경우에는 지금까지 있었던 모든 장애에 대한 케이스를 확인할 수 있도록 스크립팅 예정
22 / TOAST Meetup
인프라구조 –이전버전
Editing History DB
Amazon EC2 Instance
FS Daemon
Project ABC
FS Daemon
Project ABC
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
User 1
User 2
User 3
Collaborators
Amazon S3
Amazon EC2 Instance
FS Daemon
Project XYZ
Docker Image
Docker Image
Docker Image
User 2’s Docker Image
User 1’s Docker Image
User 3’s Docker Image
Amazon EC2 Instance
FS Proxy Server
Project XYZ
Project XYZ
Project ABC
Project ABC
Amazon EC2 Instance
Project Manager Server
Au
to-S
calin
g
File
Sys
tem
Mo
un
t
File Editing
File Editing
File Editing
A.js
A.js
X.c
Mongo DB
Project DB
Member DB
23 / TOAST Meetup
인프라구조 –이전버전
클로즈 베타를 통한 문제점 인식
• 문제점 #1 - “로딩 속도”
– S3로부터 사용자의 도커 이미지를 가져오는 것이 너무 느리다.
– S3로부터 프로젝트를 가져오는 것이 너무 느리다.
최초 접속 후 IDE 실행 속도 문제
– 결론: 실제 운영해보니, Cloud-backed Storage의 장점(비용) 대비 단점(속도)이 크다.
• 문제점 #2 – “비효율적인 공유”
– 실시간 협업을 위한 Proxy Storage Server 를 운영했었으나, Scaling의 어려움 발생
– S3에 연결된 프로젝트 데이터의 Strong Consistency 에 대한 문제점 인식 연구적으로 접근 중
– AUFS 등 도커의 특성들을 잘 활용하고 있지 못하다는 내부 의견
– 결론: 보안, 속도, 개발 편이성 측면에서 sshfs 만 사용하는 것이 가장 좋을 것으로 판단
25 / TOAST Meetup
인프라구조 –현재버전
Editing History DB
Amazon EC2 Instance
FS Daemon
Project ABC
FS Daemon
Project ABC
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
User 1
User 2
User 3
Collaborators
Amazon EBS
Amazon EC2 Instance
FS Daemon
Project XYZ
Docker Image
Docker Image
Docker Image
Infra Agent
Amazon EC2 Instance
Au
to-S
calin
g
File Editing
File Editing
File Editing
A.js
A.js
X.c
Mongo DB
Project DB
Member DB
LiveMigration
User 2’s Root Volume
User 1’s Root Volume
User 3’s Root Volume
User 2’s Workspace Volume
User 1’s Workspace Volume
sshfsroot /
root /
root /
26 / TOAST Meetup
인프라구조 –현재버전
인프라 개선 효과
• “빨라진 로딩 속도”
– S3를 사용하지 않음으로써
– 이전에 비해 3~4배 빨라진 최초 로딩 시간
– 프론트엔드 최적화와 함께 극적인 성능 향상 효과
• “컨테이너 관리 효율성 향상”
– 기본 이미지를 두고, 사용자 전용 영역을 2가지 볼륨으로 만들어서 관리
– 도커 레파지토리 관리가 불필요하고, 전체적인 용량이 줄어드는 효과
– 호스트 머신 당 동시 동작할 수 있는 도커 개수가 늘어남
• 문제점
– 비용: S3에 비해 상대적으로 비싼 EBS
– 스케일링: 고정 용량으로 제공되는 EBS를 추가로 매니지해야 함
– EFS가 해결책이 되줄 수 있을지도… (혹은 S3-based In-memory FS)
28 / TOAST Meetup
구름 IDE로개발되는구름서비스
”구름개발서버dev.goorm.io
구름 홈페이지 ▶
▼ 구름IDE
구름의 모든서비스와 홈페이지는
구름IDE로 개발되고있습니다.“
구름의모든 개발 팀원
32 / TOAST Meetup
1) 소스코드저장소(github.com)과연동
소스 코드 저장소 (github.com)
UI 테스트 케이스 저장소
– 테스트 케이스 문서 기반으로 자동화를 위한 UI 테스트 케이스 저장소
서비스 애플리케이션 저장소
– 실제 서비스 관련 모든 서비스 애플리케이션 저장소
dev.goorm.io
node.js 개발용 컨테이너
Site Project IDE Project IDE Build
34 / TOAST Meetup
2) 트렐로에서개발이슈획득 –자기가하고싶은거! (하지만중요한거)
Doing To be tested
Done
이슈 관리 도구 (트렐로)
Tasks
CARD
개발팀
CARD
36 / TOAST Meetup
dev.goorm.io
3) 구름에서구름실행하기
node.js 개발용 컨테이너
Site Project IDE Project IDE Build
로그인
47 / TOAST Meetup
5) 정기 QA를통해이슈완료처리
서비스 운영 스테이지
dev.goorm.io qa.goorm.io goorm.io
DOG FOODINGQUALITY
ASSURANCEOPERATION
서비스 품질 검증 [개발팀, QA팀]
– 매주 목요일 수행
– 테스트 통과율 100%일 경우에만 릴리즈(수동 테스트 포함)
– 릴리즈 노트로 공지되는 신규 기능/버그 픽스 사항은 매니저급이 실제로 검수
– 대규모 동시 협업 테스트
인프라 품질 검증 [인프라팀]
– 서비스 API 과부하 테스트
– DOCKER CONTAINER 생성 과부하 테스트
– 각 서비스 접속 부하 테스트 (AS, LB 테스트)
릴리즈 전 최종 품질 검증
Doing To be tested
Done
이슈 관리 도구 (트렐로)
Tasks
개발팀
CARD CARD
50 / TOAST Meetup
구름서비스관리도구 – admin.goorm.io
<구름 DEVOPS TOOL>
• DEVOPS 를 지향하며 개발하여 사용 중인 자체 관리 도구
• 향후 DEVOPS as a Service를 위한 서비스형 관리 도구로 제품화하고자 하는 계획
– 빌드/실행/테스트 사이클을 위한 CI 기능을 일부 내장하는 것을 계획 중
– 컨테이너 이미지 관리를 유연하게 할 수 있도록 관련 기능을 강화하는 것을 계획 중
• 현재 설치형으로 제공되는 구름IDE의 경우 아래의 기능들로만 구성된별도 관리도구가 고객에게 제공됨
– 사용자 관리
– 프로젝트 관리
– 컨테이너 관리
– 서비스 모니터링
– 로그 관리
67 / TOAST Meetup
Summary
• 나름대로 DevOps를 해보고자 프로세스 짜서 아둥바둥
– 테스트 자동화는 정말 어렵지만 해야할 부분
– 개발 프로세스 개선을 위한 현업 전문가들의 조언이 절실
– 개발 조직이 커질 때를 대비한 준비 필요
• 인프라 구조는 몇 회의 대규모 개선을 통해 지금은 해외 클라우드IDE와 경쟁할만한 수준의 퍼포먼스
– 하지만 앞으로 더 많은 개선의 여지가 있음
– AWS에 종속적인 부분은 거의 없어짐
– 그러나 구름을 구성하는 모든 서비스들이 도커 컨테이너 단위로 되어 있어 ECS 도입은 고려 중
• 99dev는정말맛있는개밥이었음
68 / TOAST Meetup
구름으로구름개발… 정말잘되고있는지?
• 클라우드IDE 서비스 특성상 일반적인 서비스들에 비해 초기 버전에서 실제 사용자 층을 확보하기 힘듦
이 때문에 “구름으로 구름개발하기”라는 Dog Fooding은 서비스 품질을 끌어올리는 데 아주 큰 도움
• 현재는 네이티브 개발 환경이 더 불편하게 느껴질 만큼 99dev에 의존성이 높아짐
• 언제 어디서나 개발을 진행할 수 있다는 장점을 개발팀 스스로 느끼고 있음
서비스에 대한 자신감, 자존감 ⬆
• 그럼에도 불구하고, 아직 갈 길이…
Dog fooding! It’s delicious!
69 / TOAST Meetup
앞으로는어떻게… - “품질과의전쟁”
• 지속적인 개발 프로세스 개선
– 빌드 스크립트 개편 (sh 파일 -> grunt)
– 코드 리뷰에 더 많은 시간을!
– 외부 연사 초청 세미나 개최를 통해 현업의 개발 방법론, 경험, 지식 도입
– JIRA Agile 도입 예정
– 조직이 확대될 것을 대비하여 WIKI를 통한 각종 문서화에도 초점
– IDE는 클라우드에, 개발 환경은 로컬에 인프라 비용 효율화
• admin.goorm.io 의 기능 고도화
– 서비스 모니터링 / 장애 알람
– 테스트 자동화 고도화
– 컨테이너 관리 고도화 - Chef 활용
– 유료 결제 모듈 결합 후 분석 기능까지
• HA, 보안 강화 달성을 위한 노력
– Zookeeper 기반 분산 자원 관리
– 보안 관련 인력 확충