도커 컨테이너 활용 사례 Codigm - 남 유석 개발팀장 :: AWS Container Day

코다임
개발팀장 남유석
youseok.nam@goorm.io
클라우드 코딩 서비스 구름에서의
DOCKER CONTAINER 활용 사례
http://goorm.io
contact@goorm.io
클라우드 SW교육 솔루션

클라우드 코딩 서비스
발표 순서
1.  What is the goorm?
2.  Why Docker?
3.  Docker in goorm
2

먼저, 구름을 개발하고 있는 ㈜ 코다임을 소개 합니다.
TEACHING
LEARNINGDEVELOPING
Vision
은 클라우드 인프라에 대한 깊은 이해와, 웹 애플리케이션 개발에 대한 적지 않
은 노하우로 국내를 넘어서 글로벌 서비스를 표방하는 기술 기반 스타트업입니다.
사명의 의미는 CODE와 PARADIGM의 합성어로서, 누구든지 언제 어디서나 소프트웨어를
배우고 개발할 수 있도록 패러다임을 바꾸고자 하는 저희의 비전을 담고 있습니다.
codigm은 현재 언제 어디서나 SW를 배우고, 개발할 수 있도록 해주는 클라우드 코딩
서비스 브랜드인 구름(goorm)을 개발하고 서비스하고 있습니다.
SW
4

Vision
TEACHING
LEARNINGDEVELOPING
SW
누구나 SW를 쉽게 개발할 수 있는 세상을 만듭니다.
이를 통해 SW가 만드는 더 나은 미래를 꿈꿉니다.
클라우드 코딩 서비스를 통해
“개발 환경 구축이라는 장벽을 낮추어
더 많은 사람들이 소프트웨어로
자신의 생각을 실현하도록 돕습니다.”
“소프트웨어 개발을 위한 인력 양성에
긍정적인 순환 구조를 제공하고자 합니다.”
클라우드 개발 환경을 통해 개발의 편의성과
최신 개발 도구에 대해 경험할 수 있습니다.
지난 3년간 대학의 프로그래밍 강의 도구로 활용되면서 SW교육을 위한 특화 기능을 지
속적으로 개발하여 교수자에게 많은 편리함을 제공하고 있습니다.
다양한 학습 방법과 언제 어디서나 사용할 수 있는 교육환경,
연속적인 개발은 학생들에게 많은 호응을 얻고 있습니다.
5

PROBLEM
•  개발 환경 설치 세팅의 어려움 / 시간 낭비
•  학교(실습실) 외 공간에서 학습하기 어려움
•  다양한 협업 과제를 가능하게 해주는 솔루션
•  실제 SW개발까지 해볼 수 있는 수준의 솔루션
•  교육이 실무로 이어지는 솔루션
•  다양한 수준의 학생 개개인의 관리가 어려움
•  부족한 조교의 활용을 극대화 하는 솔루션
•  초등 – 대학까지 이어지는 단계적인 솔루션 부족
•  학교 단위의 소프트웨어 교육에 적합한 솔루션
•  컨텐츠 제작 및 활용을 손쉽게 해주는 솔루션
오늘날 소프트웨어 교육 환경의 한계
6

PROBLEM
•  개발 환경 설치 세팅의 어려움 / 시간 낭비
•  학교(실습실) 외 공간에서 학습하기 어려움
•  다양한 협업 과제를 가능하게 해주는 솔루션
•  실제 SW개발까지 해볼 수 있는 수준의 솔루션
•  교육이 실무로 이어지는 솔루션
•  다양한 수준의 학생 개개인의 관리가 어려움
•  부족한 조교의 활용을 극대화 하는 솔루션
•  초등 – 대학까지 이어지는 단계적인 솔루션 부족
•  학교 단위의 소프트웨어 교육에 적합한 솔루션
•  컨텐츠 제작 및 활용을 손쉽게 해주는 솔루션
오늘날 소프트웨어 교육 환경의 한계
7

Solution
언제 어디서나 프로그래밍을 배우고, 소프트웨어를 개발할 수 있는 클라우드 서비스와 함께
TEACHING,
LEARNING
CODING,
DEVELOPING
ANYTIME,
ANYWHERE
ANYONE
8

Solution
언제 어디서나 프로그래밍을 배우고, 소프트웨어를 개발할 수 있는 클라우드 서비스와 함께
TEACHING,
LEARNING
CODING,
DEVELOPING
ANYTIME,
ANYWHERE
ANYONE
Docker Container 안에서 마음껏! 코딩하세요!
9

Product
개인별 가상 머신 제공실시간 동시 편집 및 협업 기능 지원다양한 프로그래밍 언어 지원 온라인 실행 (컴파일/빌드/디버그)
goormIDEgoormEDU Cloud Integrated Development EnvironmentCloud Software Development Education Platform
TEACHING, LEARNING CODING, DEVELOPING
구름
10

Product
구름
11

Product
구름
12

튜토리얼 기반 학습 서비스의 주요 특징
13
① 단계별 학습
실제로 코드를 작성해보면서 단계별로 학
습을 진행할 수 있습니다.
그림
② 다양한 인터랙션 방법
기본적으로 콘솔 입/출력을 지원할 뿐만 아
니라 캐릭터나 그래픽을 조작하면서 학습
할 수도 있습니다.
그림 그림
그림 그림
그림
그림
③ 다양한 프로그래밍 지원
네이티브 및 웹 개발 언어까지 다양한 언어
를 사용할 수 있고, 웹에서 코드 편집하는
것뿐만 아니라 실제로 실행하거나 실시간
린트 기능까지 지원합니다.
⑥ 자동 채점, 코드 분석
언어의 구분 없이 자동 채점을 지원하며,
제출된 코드들을 분석해주어 학생별 성취
도를 확인할 수 있습니다.
⑧ 다양한 기본 컨텐츠 제공
기존의 오프라인 강의안이나 도서들을 온
라인화시킨 기본 컨텐츠를 제공하여, 질높
은 SW교육 진행이 가능합니다.
④ 엔트리/Blockly 지원
프로그래밍 교육에 앞서 CT(Computatio
nal Thinking)도 진행할 수 있도록 엔트리
와 Blockly를 지원합니다.
⑦ 온라인 코딩 시험
튜토리얼 기반 학습은 온라인 코딩 시험 기
능을 제공할 수 있으므로, 중간고사, 기말
고사에 활용도 가능합니다.
⑤ 강의 작성 기능
온라인 튜토리얼들은 강의자가 직접 작성
하거나 기존 컨텐츠들을 수정하여 사용할
수도 있습니다.
그림

기업
기관/학교
고객 & 파트너
14

기업
기관/학교
고객 & 파트너
15
?!

구름EDU: 튜토리얼 기반 학습 서비스의 기본 화면
16goorm CONFIDENTIAL
강의 내용 및 실습 내용
개념을 이해한 뒤에 실습을 진행할 수 있도
록 HTML / PDF / Slideshare.net / You
Tube 등의 다양한 형태의 강의 내용 전달
매체를 지원합니다.
소스 코드 작성, 콘솔, 파일 입/출력
컨테이너와 연결된 소스 코드 에디터로서 사용자 별로 독립적인 소스 코드
편집 및 실행을 할 수 있습니다. 콘솔의 경우 언어별 REPL 콘솔을 지원하
여 콘솔을 통한 상호작용도 가능합니다.
터미널 입/출력 결과
우측의 에디터에서 작성하여 실행한 코드의 결과는 표준 입
/출력으로 확인할 수 있습니다.

강의 내용 및 실습 내용
개념을 이해한 뒤에 실습을 진행할 수 있도
록 HTML / PDF / Slideshare.net / You
Tube 등의 다양한 형태의 강의 내용 전달
매체를 지원합니다.
구름EDU: 튜토리얼 기반 학습 서비스의 기본 화면
소스 코드 작성, 콘솔, 파일 입/출력
컨테이너와 연결된 소스 코드 에디터로서 사용자 별로 독립적인 소스 코드
편집 및 실행을 할 수 있습니다. 콘솔의 경우 언어별 REPL 콘솔을 지원하
여 콘솔을 통한 상호작용도 가능합니다.
터미널 입/출력 결과
우측의 에디터에서 작성하여 실행한 코드의 결과는 표준 입
/출력으로 확인할 수 있습니다.

구름EDU: 튜토리얼 기반 학습 서비스의 기본 화면 (강의자 모드)
내가 만든 과목 리스트
강의자는 여러 형태의 과목을 손쉽게 만들고, 관리할 수 있습니다.

강의 커리큘럼 관리
마치 블로그 글을 관리하듯, 책을 집필하듯 강의 커리큘럼을 구
성할 수 있습니다.
강의 구성 요소별 컨텐츠 관리
강의를 구성하는 각 요소들을 클릭하여 컨텐츠를 추가/편집할 수 있
습니다.

코딩 실습 내용 편집
코딩 문제 편집기를 통해, 기본으로 제공되는 코드 및 실습 내용, 정
상적으로 코딩을 진행했는 지를 확인할 수 있는 정답 코드를
손쉽게 추가/편집할 수 있습니다.

IDE 서비스의 주요 특징
① 언제 어디서나
웹 브라우저만 있으면 언제 어디서나
연속성 있는 개발을 할 수 있습니다.
그림
② 일관된 개발환경
매번 새롭게 개발환경을 구축할 필요 없이
일관된 개발환경을 사용할 수 있습니다.
그림 그림
그림 그림
그림
그림
③ 다양한 프로그래밍 지원
네이티브 및 웹 개발 언어까지 다양한 언어
를 사용할 수 있고, 코드 편집/빌드/서버 실
행/실시간 린트 등을 지원합니다.
⑥ 온라인 편집/실시간 협업
별도의 에디터 설치 없이 웹에서 바로 코드
를 편집할 수 있고, 다른 팀원들과 함께 작
업할 수 있습니다.
⑧ 소스 코드 관리(GIT,SVN)
GIT과 SVN을 완벽하게 지원하며,
원클릭으로 저장소에 액세스하고,
작업 내용을 커밋할 수 있습니다.
④ 온라인 빌드/디버그/실행
별도의 빌드/디버깅 도구를 설치하지 않고,
웹에서 바로 빌드 및 디버깅할 수 있습니
다.
⑦ 협업 도구 제공
메신저 수준의 채팅 기능 뿐만 아니라
슬라이드, PDF 를 공유하여 프로젝트의
생산성을 높입니다.
⑤ 터미널 연결 기능
자신이 작업 중이던 개발 환경을
웹에서 바로 터미널로 연결하여
필요한 작업을 수행할 수 있습니다.
21

구름IDE: 기본 화면
좌측 레이아웃
- 프로젝트/클라우드
애플리케이션 개발에 관련된
모든 파일들을 프로젝트 단위로
관리하거나 클라우드 스토리지를 통
해 관리할 수 있습니다.
우측 레이아웃
- 채팅/문서뷰어/작업내역/아웃라인
우측 레이아웃을 통해 협업 개발자와 채팅을
하거나 문서 뷰어를 함께 보고 해당 소스 코드
의 변경 내역이나 전체 구조를 확인할 수 있습
니다.창 단위로 관리되는 워크스페이스
소스 코드 에디터나 터미널 등을 창 단위로 관리할 수 있는 워크스페이스가 제공
됩니다.
하단 레이아웃 – 디버그/터미널/검색/빌드 아웃풋
하단 레이아웃을 통해 디버그/터미널/검색/빌드 아웃풋에 대한
결과를 확인하고 상호작용할 수 있습니다.
기본 툴바
자주 사용하는 기능을 쉽게 선택할 수 있는 버튼들로 구성된 툴바

우측 레이아웃
- 채팅/문서뷰어/작업내역/아웃라인
우측 레이아웃을 통해 협업 개발자와 채팅을
하거나 문서 뷰어를 함께 보고 해당 소스 코드
의 변경 내역이나 전체 구조를 확인할 수 있습
니다.창 단위로 관리되는 워크스페이스
소스 코드 에디터나 터미널 등을 창 단위로 관리할 수 있는 워크스페이스가 제공
됩니다.
기본 툴바
자주 사용하는 기능을 쉽게 선택할 수 있는 버튼들로 구성된 툴바
구름IDE: 기본 화면
좌측 레이아웃
- 프로젝트/클라우드
애플리케이션 개발에 관련된
모든 파일들을 프로젝트 단위로
관리하거나 클라우드 스토리지를 통
해 관리할 수 있습니다.
하단 레이아웃 – 디버그/터미널/검색/빌드 아웃풋
하단 레이아웃을 통해 디버그/터미널/검색/빌드 아웃풋에 대한
결과를 확인하고 상호작용할 수 있습니다.

Origin of goorm
•  project.goorm
–  SINCE 2008 (나름 originality)
–  처음에는 OPEN SOURCE로 시작 (현재 버전은 코어 공개를 위해 준비 중에 있음)
–  IDE로서 갖춰야 할 기능에 집중
–  공모전 수상, 정부 과제를 통한 사업화 준비 (2009~2012)
–  그 사이 북미에서 비슷한 경쟁 서비스 등장 (2010~)
•  사업화? 사업 = 돈을 버는 일
–  고민 1 : 클라우드IDE를 사용하면 효과적인 곳이 어디일까?
•  당시 대학/대학원 재학생들로 구성되어 있었기 때문인지
자연스럽게 대학교 프로그래밍 실습 환경에
눈을 돌림
–  고민 2 : 클라우드IDE 서비스가 기존의 IDE와 경쟁하려면 무엇이 필요할까?
•  막강한 편집 기능, 네이티브에 버금가는 속도와 UI/UX
•  컴파일/빌드 뿐만 아니라 디버깅과 실행까지 가능한 독립된 개발 환경

서비스로서의 독립된 개발 환경 제공에 대한 고민
•  하나 또는 여러 대의 머신을 공유해서 사용하려면?
–  DB를 이용한 사용자/프로젝트 구분
–  클러스터링을 통한 안정화
–  사용자를 위한 각자의 개발환경을 구성하여, 웹 터미널 제공
•  각자의 개발환경을 꾸밀 수 있도록
•  필요한 CLI 커맨드도 실행해 볼 수 있도록
•  각 사용자의 개발환경은 구체적으로 어떤 환경인가?
–  웹 터미널 내에서 자신의 환경과 프로젝트에 접근할 수 있어야 함
–  웹 터미널 내에서 다른 사용자의 환경이나 프로젝트에는 접근할 수 없어야 함
26

사용자 별 개발 환경을 제공하기 위한 여정…
•  사용자를 위한 각자의 개발환경을 위한 서비스 모델은 어떻게 구성될 수 있을까?
–  DB 서버 + 1인 1서버 구조 è 가장 단순한 구조
•  1개의 서버에 서비스를 올려놓고, 온전히 그 서버는 한 명의 유저가 활용
•  관리의 어려움과 엄청난 유지 비용
•  클라우드를 쓰지 않고 데스크탑을 서버로 쓰던 시절이었기 때문에 사실상 구성이 불가능
–  DB 서버 + 1서버 (다수의 유저) 구조
•  결국 하나의 머신에서 다수의 유저가 각자의 개발환경을 가지게 해야 함
è 결국 하나의 머신 내에서 다수의 가상 머신을 고려할 수 밖에…
27

사용자 별 개발 환경을 제공하기 위한 여정…
•  한 서버에서 어떻게 사용자를 위한 각자의 개발환경을 구성할 수 있을까?
–  각 유저만을 위한 시스템 유저를 생성
•  회원가입 시에 유저 아이디가 goorm이라면, 해당 서버에도 goorm이라는 시스템 유저를 생성
•  /home/goorm/을 유저 만의 개발 환경으로 연결
•  uid, gid가 있으므로, 다른 유저의 환경으로 접근 불가능
28

테스트베드에서의 실제 사용과 문제점 파악
•  성균관대학교 C/C++실습 과목에 적용, 그 결과는?
–  서버 1개에 30 ~ 40명이 접속
–  동시에 회원가입, 프로젝트 생성, 빌드, 실행…
•  백엔드의 퍼포먼스가 낮아 느렸음 à 백엔드 최적화 필요
–  중요한 것은, 학생들이 돌리는 무한루프 프로그램이 서버 리소스를 잡아먹어,
서버가 다운되는 현상 발생
•  이를 위해 시스템 유저에 cgroup을 적용하여 cpu를 제한
•  실제로 서비스를 운영해보고 찾은 문제점과 피드백들
–  시스템 유저 관리 리스크
•  서비스는 root로 돌고, 사용자는 각자 Uid, gid를 가지고 있어, 서비스가 파일, 폴더 생성 시 사용자
의 uid,gid를 일일히 넣어줘야 함 (넣어주지 않으면 root로 생성되어, 사용자가 접근 불가능)
–  CPU 제한의 부작용
•  무한루프로 인한 서버 다운은 없어졌으나, java의 경우 빌드/실행에 대한 속도가 현저히 다운
–  Root 권한을 원하는 사용자들
29

해결책#1 : LXC (Linux Containers)
•  문제점과 피드백을 해결하기 위하여 LXC를 도입
–  기존 가상화 기술에서는 Hypervisor (쉽게 VM웨어) 가 Host OS에서 돌면서, 게스트 OS를 올렸
음
–  LXC는 Hypervisor 없이 Host OS에서 “컨테이너”를 올렸음
•  LXC를 통해 다음과 같은 문제를 해결함
–  한 유저당 하나의 LXC 컨테이너를 제공하여 Root 권한 적용
–  시스템 유저 관리 리스크가 현저히 줄어듬
–  LXC 컨테이너 밑에서 사용자의 프로그램이 돌기 때문에, LXC 컨테이너에 리소스를 제한하여 무한
루프를 막음
•  이렇게 하여 완성된 goormIDE 1.5 스펙과 1차 오픈 베타 시작
–  LXC 도입을 통해 인프라 문제들을 해결
–  다만, LXC 자체 관리 리스크가 매우 컸음
•  LXC를 쉽게 사용할 수 있는 도구가 없어 일일히 shell 스크립트를 활용
•  Shell 스크립트 도중 에러가 나면, 모두 복구하고 다시 그 부분을 Full Cycle..
–  1차 오픈 베타를 통해, 인프라 안정성 확보가 가장 큰 우선순위로
•  AWS를 활용하게 된 계기
30

해결책#2: DOCKER
•  DOCKER의 특징
–  LXC의 특성을 그대로 담고 있음
–  높은 성능
–  관리를 도와주는 편리한 인터페이스
–  이식성이 좋다
•  이미지/컨테이너 기반이라, 이미지만 옮기면 원래 사용하던 컨테이너 그대로 사용 가능
–  자원 활용에 있어 효율적
32

인프라 구조 – 이전 버전
34

서비스 초기 Docker 사용 방법
•  초기 Docker 컨테이너 관리 정책
–  사용자가 여러 컨테이너를 가질 수 있도록
–  Docker 이미지를 활용하여 VM에 종속되지 않도록
–  S3를 도커 레파지토리로…
goorm
IDE
VM
VM
AWS S3
User Docker Image
Push/Pull
User Docker Container
Run/Commit
VM
35

Editing History DB
인프라 구조 – 이전 버전
36
Amazon
EC2 Instance
FS Daemon
Project ABC
FS Daemon
Project ABC
Client (Web Browser)
HTML/CSS
Javascript
Web Socket
HTML/CSS
Javascript
Web Socket
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
Amazon
EC2 Instance
FS Proxy Server
Project XYZ
Project XYZ
Project ABC
Project ABC
Amazon
EC2 Instance
Project Manager
Server
Auto-Scaling
FileSystemMount
File Editing
File Editing
File Editing
A.js
A.js
X.c
Mongo DB
Project DB
Member DB

클로즈 베타(2015.08~2015.10) 를 통한 문제점 인식
•  문제점 #1 - “로딩 속도”
–  사용자가 로그아웃 할 때마다 이미지에 Commit
•  이미지 크기가 한없이 커져, VM으로 이미지를 pull 받을 때 갈수록 다운로드 시간이 길어짐
•  이미지에 Commit 할 수 있는 횟수가 255번으로 정해져 있음
•  255번 이상 Commit된 이미지는 Container로 Run 할 수 없음
è  S3로부터 사용자의 도커 이미지를 가져오는 것이 너무 느리다.
è  S3로부터 프로젝트를 가져오는 것이 너무 느리다.
è  최초 접속 후 IDE 실행 속도 문제
–  결론: 실제 운영해보니, Cloud-backed Storage의 장점(비용) 대비 단점(속도)이 크다.
37

클로즈 베타(2015.08~2015.10) 를 통한 문제점 인식
•  문제점 #2 – “비효율적인 공유”
–  실시간 협업을 위한 Proxy Storage Server 를 운영했었으나, Scaling의 어려움 발생
–  S3에 연결된 프로젝트 데이터의 Strong Consistency 에 대한 문제점 인식 è 연구적으로 접근 중
–  AUFS 등 도커의 특성들을 잘 활용하고 있지 못하다는 내부 의견
–  결론: 보안, 속도, 개발 편이성 측면에서 sshfs 만 사용하는 것이 가장 좋을 것으로 판단
38

AWS S3
오픈 베타 (2015.11~) 를 위한 개선
Docker 이미지를 공유하는 방식 è
Docker 컨테이너에서 생성되는 aufs의 diff 파일/폴더들을 공유하는 방식
39
VM
Cached Ima
ge
접속
User Docker Co
ntainer
원본 Image
Diff File
AUFS
Diff File
VM
Cached Ima
ge
User Docker Co
ntainer
AUFS
Diff File
goorm
IDE
사용자
변경 사항
(프로젝트 코드, 직접 설
치/구성한 APP들)
이후 추가 접속
반영된 사용자
변경 사항
(프로젝트 코드, 직접 설
치/구성한 APP들)

오픈 베타 (2015.11~) 를 위한 개선
•  기존 방식과의 차이점
–  기본이 되는 이미지 파일이 커질 필요가 없음
–  사용자가 고유의 Docker 이미지를 갖는 방식에서 전체적으로 사용되는 Docker 이미지 하나
만 쓰게 되므로 관리가 쉬워짐
–  AUFS의 DIFF 파일/폴더가 곧 실제 변경 내역이므로,
이미지에 Commit되는 크기보다 작음
–  이미지를 다운로드 받는 시간보다 DIFF 파일/폴더 공유 받는 시간이 훨씬 빨라,
퍼포먼스 향상
40

최근 개편된 인프라 구조
41
S3는 Hibernated
사용자 도커 이미지
저장용도로

Editing History DB
최근 개편된 인프라 구조
Amazon
EC2 Instance
FS Daemon
Project ABC
FS Daemon
Project ABC
HTML/CSS
Javascript
Web Socket
HTML/CSS
Javascript
Web Socket
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
Auto-Scaling
File Editing
File Editing
File Editing
A.js
A.js
X.c
Mongo DB
Project DB
Member DB
Live
Migration
User 2’s Root Volume
User 2’s Workspace Volume
User 1’s Workspace Volume
sshfs
root /
root /
root /
42

개선 효과
•  “빨라진 로딩 속도”
–  S3를 사용하지 않고, EBS에 도커 이미지를 두고 관리
–  이전에 비해 3~4배 빨라진 최초 로딩 시간
–  프론트엔드 최적화와 함께 극적인 성능 향상 효과
•  “컨테이너 관리 효율성 향상”
–  기본 이미지를 두고, 사용자 전용 영역을 2가지 볼륨으로 만들어서 관리
–  도커 레파지토리 관리가 불필요하고, 전체적인 용량이 줄어드는 효과
–  호스트 머신 당 동시 동작할 수 있는 도커 개수가 늘어남
•  문제점
–  비용: S3에 비해 상대적으로 비싼 EBS
–  스케일링: 고정 용량으로 제공되는 EBS를 추가로 매니지해야 함
–  EFS가 해결책이 되줄 수 있을지도… (혹은 S3-based In-memory FS)
43

DEMO?
http://goorm.io
44

SUMMARY
•  goorm.io - 유저별로 독립된 개발 환경을 제공하기 위한 노력
–  리눅스 유저 그룹 à qemu à LXC à Docker 로 변화
–  변화의 과정 속에서 Docker는 너무나도 알맞은 타이밍에 등장
–  Docker 기반의 다양한 인프라를 구성해보는 시행착오
–  더 규모 있는 서비스를 운영해보지는 못했기 때문에 정확한 답을 찾기는 어려움
è 서비스를 발전시켜나가면서 더 빠르고 비용효율적인 운영 방안을 찾아가는 재미!
45

SUMMARY
•  Future? è DevOps as a Service, Container as a Service
–  Docker를 단순히 개발환경으로만 제공하는 것이 아니라, PaaS 형태로 제공할 예정
•  Docker 컨테이너에 MySQL이나 mongoDB를 담아 제공
•  ECS, EFS
–  구름 서비스를 구성하는 각 컨테이너는 ECS를 활용하여 운영
•  서비스에 사용되는 모든 어플리케이션을 Docker 컨테이너 레벨로 묶을 예정
•  구름 서비스의 운영 및 배포가 쉽도록
–  사용자별 프로젝트 파일 시스템은 EFS 도입 고민?
46

FUTURE?
47
DevOps as a Service – 편리하게 개발하고, 그 결과물을 손쉽게 배포하고 서비스로 운영하는 환경을 클라우드로 제공
서비스 목표
VM 성능 선택 소프트웨어 스택 선택 컨테이너 구성 및 저장컨테이너 성능 선택
게임 서버
쇼핑몰
개인 블로그
웹 서비스
모바일 앱
업무용 도구
SW교육
서비스
운영/관리
빌드/실행
테스트
협업 개발
ONE CLICK ONE CLICK ONE CLICK ONE CLICK
ONE CLICK

글로벌 클라우드 코딩 서비스를 향하여 노력하겠습니다.
감사합니다
http://codigm.com
contact@codigm.com
http://goorm.io
contact@goorm.io

도커 컨테이너 활용 사례 Codigm - 남 유석 개발팀장 :: AWS Container Day

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 도커 컨테이너 활용 사례 Codigm - 남 유석 개발팀장 :: AWS Container Day

Ähnlich wie 도커 컨테이너 활용 사례 Codigm - 남 유석 개발팀장 :: AWS Container Day (20)

Mehr von Amazon Web Services Korea

Mehr von Amazon Web Services Korea (20)

도커 컨테이너 활용 사례 Codigm - 남 유석 개발팀장 :: AWS Container Day