OpenShift Origin 프로젝트 목록을 살펴보려고 GitHub에 들어갔는데, origin이라는 못보던 저장소가 생성되어 있었다.

이건 뭔가 싶어 들어갔더니 README에  OpenShift Origin 3.0 이라고 떡하니 적혀있다.


!?


공식적으로 3.0 발표에 대한 내용을 다루고 있는 글은 OpenShift 블로그의 Announcing OpenShift Origin V3을 통해 공개되었는데, 이 기사는 2013년 12월 19일에 올라왔고, 저장소는 7월 30일에 생성된 것으로 보아 그 사이 적용 기술 검토와 설계를 하고, 이제 개발에 착수한 것 같다.


README.md 파일의 첫 부분을 보면 


This is the source repository for the next version of OpenShift - the third architectural revision. It is based around Docker containers and images and the Kubernetes container management solution.


OpenShift Origin은 Docker 컨테이너와 Kubernetes 컨테이너 관리 솔루션에 기반한다고 되어있다.

그동안 분석을 해오면서, Docker가 적용되어 있나? 없나?에 대한 고민이 많았는데, 다른 분들은 적용되어 있다고 하시고, 난 아무리 코드를 뒤져봐도 Gear 생성을 위한 Docker 코드를 확인할 수 없었기 때문이다.


GEARD 프로젝트야 Gear-Docker에 관한 프로젝트가 맞지만, 이 GEARD를 origin-server에서 사용하는 것을 본적이 없다. cgroups를 통해서 시스템 자원을 관리하는 거라면 모를까.


이 OpenShift Origin 3.0 저장소가 생성되기 전에 OpenShift 3 PEP가 있었는데, 여기에 나온 설계와 실제 코드가 너무 상이해서 뭔가 싶었는데, OpenShift Origin 3.0은 PEP를 토대로 개발이 진행된다고 한다.

OpenShift Origin의 버전이 명확히 공개된 문서가 없어서 이런 혼란스런 상황이 되지 않았나 싶다. 이제야 조각이 맞춰지는 느낌이다. 실제로 우리는 기존 OpenShift Origin Server의 브랜치 중에서 release 3, release 4 등의 릴리즈 번호를 보고 이게 버전이라고 추정했는데, 단지 릴리즈 번호로써의 숫자이지, 버전은 아니었던거다.


새로 3.0 버전의 개발이 시작되었지만, 우리가 분석하는 건 당연히 기존의 버전으로 진행한다.

다만 문제는 OpenShift의 강점으로 내세웠던 Docker를 이용한 컨테이너 기술인데, 이렇게 되면 헛분석한게 된다. 기존의 Gear컨테이너의 격리는 CGroups와 SELinux를 통해서 이루어지고 lib-virt를 통해서 관리된다.

OpenShift의 개발은 그쪽대로 진행이 되고 우리의 분석은 우리대로 진행이 될 것이지만, 그간의 분석이 소스코드를 중심으로 하지 않고, 노출된 문서들을 바탕으로 하다보니, 실제로 적용된 기술과 분석의 결과는 차이가 있을 수 밖에 없는 것 같다.

앞으로의 일정대로라면 분석을 위한 시간이 충분하진 않겠지만, 개인적으로라도 소스코드를 중심으로 좀 더 깊게 살펴봐야겠다.


Parameters

  • app_name : 애플리케이션 이름
  • cartridges : 생성할 애플리케이션에 추가할 카트리지 목록
  • scalable : 확장 여부(기본값 false)
  • available : HA 여부
  • init_git_url : 애플리케이션 템플릿 GIT URL
  • gear_profile, gear_size, default_gear_size : 기어 사이즈
  • config : 설정값
  • environment_variables : 환경 변수
  • initial_git_branch : init_git_url에서 사용할 브랜치

Preconditions
  • 애플리케이션 이름이 Blacklist에 등록되어 있는지 확인(OpenShift::ApplicationContainerProxy)
  • Git URL 스키마 확인(OpenShift::Git)
  • 카트리지 스펙 확인(CartridgeInstance)
  • 설정에서 HA가 비활성화 되어있는지 확인(Rails.configuration.openshift - allow_ha_applications)
  • 유저가 HA 애플리케이션을 생성할 수 있는 권한이 있는지 확인


프로세스 상세

  1. Gear 스펙 Hash Array 생성
  2. 지정된 이름의 도메인을 찾거나, 없을 시 생성
  3. 인증
  4. 권한 체크
  5. Application 모델 객체 생성
  6. config 타입 변환
  7. app에 user agent 정보 추가 - 로깅용..?
  8. 인스턴스 변수에 생성된 app 객체 설정
  9. 기어 최대 생성 수보다 많은 지 확인
  10. envorionment_variables 가져옴
  11. user environment variable 유효성 확인(Application.validate_user_env_variables)
  12. cartridge 탐색 및 다운로드(CartridgeCache.find_and_download_cartridges)
  13. 최대 스토리지 사용량 초과 확인
  14. 웹 프레임워크 유효성 확인
  15. 구 버전 카트리지 확인
  16. 요청 결과 생성
  17. 분석 데이터 트래킹(@analytics_tracker 인스턴스 변수)
  18. 카트리지 include
  19. 요청 결과 렌더



OpenShift 분석을 위해 (얕게라도) 알아야 할 것들


아키텍처

  • 아키텍처 설계
  • 아키텍처 문서화
  • 아키텍처 평가


클라우드

  • 클라우드 개념 및 아키텍처
  • CloudForms
  • OpenStack
  • HyperV
  • Xen Hypervisor


리눅스

  • User & Accounts Management
  • SELinux
  • CGroups
  • Shell Script
  • Docker
  • LXC
  • libcontainer
  • libvirt
  • iptables
  • 기타 리눅스 관리를 위한 명령어


언어

  • Ruby, Rails
  • Go


서버

  • DNS Binding
  • 네트워크 개념 전반
  • Routing
  • Load Balancing
  • Clustering
  • Sharding
  • Scaling (Up/Down, In/Out)
  • Redundancy


기타

  • CI(Jenkins or Husdon)
  • Maven


There are known knowns. These are things we know that we know. There are known unknowns. That is to say. there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.

Donald Rumsfeld

도널드 럼즈펠드가 어떤 사람인지는 잘 모르지만 저 말은 좋아한다.

아는 것을 아는 것, 모르는 것을 아는 것, 모르는 것을 모르는 것. 어디선가는 이 사람이 횡설수설하며 한 말이라고 하는 얘기도 하지만, 무엇인가를 아는 상태를 말할 때 딱 맞아 떨어지지 않나 싶다.


입사를 하기 전에는 서버, 안드로이드, 프론트엔드 개발에 관심이 있어 공부한 것들은 그 쪽에 치우쳐 있었다.

소마 때 멘토링을 받았던 멘토님께서 PaaS 플랫폼인 OpenShift 분석 프로젝트에 대해서 말씀하시면서 프로젝트 참여를 제안해 주셨고, 다른 프로젝트와 일정이 겹쳤던 탓에 바로 시작하지는 못했었지만 진행 중이던 프로젝트가 끝나고,

멘토님 회사로 입사해서 OpenShift 분석 프로젝트를 하고 있다.


내게 클라우드는 관심은 있었지만 공부를 한 적이 없어서 그야말로 뜬 구름 잡는 듯한 기술의 모임이다.

클라우드를 비롯해서 OpenShift 내에서 사용하는 기술, 언어들도 하나같이 생소하다.

자바를 좋아해서 자바만 해왔었으니, 루비나 Go 같은 건 제대로 본 적이 없는 탓이다.



모르는 것을 알고 있는 것

OpenShift는 레드햇에서 개발 하고 있는 Open Source PaaS 플랫폼으로 리눅스 기반 환경에서 동작한다.

여기서부터 모르는 것이 생기기 시작하는데, 리눅스 자체도 그렇고, init.d를 대체한다는 systemd, CPU, 메모리, Disk 등의 자원을 격리하는 cgroups, 보안을 위한 SELinux,  DNS BIND...

Containerization 관련 기술인 LXC나 Docker. Orchestraition 이란 용어도 이 프로젝트를 하면서 처음 접했고,

Puppet, Vagrant, Chef Solo 같은 툴들, 이 외에도 수많은 라이브러리들이나 서비스. 하나 같이 모르겠다.

그나마 이건 그래도 모르는 것을 알고 있다에 속하는 걸까? 아마 인지하지 못한 모르는 것들도 많을 것이다.

점점 모르는 것들을 알고 있는 상태의 것들이 많아지고 있다. 많아도 너무 많다.

이 전에 개발하던 분야에서 너무나 많은 것들이 바뀌어서, 프로젝트를 진행하면서 이것들을 모두 따라잡기가 버겁다.



영어의 장벽

국내에 널리 쓰이는 기술이 아니다보니 대부분의 자료가 영어다.

중학교 때나 고등학교 때는 이런 생각을 했던 적이 있다.

"왜 영어를 잘 해야하지? 일하는 데 영어로 할 것도 아니고, 우리말로 할텐데, 점수 때문에 공부해야 하나?"

... 그때로 돌아가서 한대 때리고 싶다.

"다른 분야는 몰라도 니가 가고 싶어하는 분야는 영어를 못하면 힘들걸??"

그때는 필요성을 몰라서 영어 공부를 소홀히 했고, 영어가 필요하다고 느끼는 요즘에는 바쁘다는 핑계로 여전히 소홀히 하고 있다.

얼마 전 OpenShift 관련해서 외부 전문가 분들과 회의 후에 술자리가 있었는데, 이런 얘기가 오갔다.

"저는 아이들 대학교 먼저 보내지 않을거예요. 필드에서 1년 정도 뛰게 한 후에 대학교를 보내든지 하려구요.

아마 본인의 경험을 바탕으로 대학교 때 배우는 것들이 분명 필요한 것들이지만,

몸소 필요성을 느껴보지 않고 그것들을 배우면 맹목적으로 공부하게 되기 때문에 필드에 나가서

직접 겪어보고 무엇이 필요한지 알게 되고 그때 가서 대학교에 입학해서 공부하면 분명한 목적을 가지고

공부를 할 수 있기 때문에 그런 말씀을 하셨던 것 같다.


나는 특히 과목 중 네트워크가 그러한데, 어디에 어떻게 써먹는 줄도 모르겠고 왜 해야하는 지도 모르는 상태에서

단순 암기식으로 수업을 진행하다보니 시험을 위한 공부를 했고, 시험이 끝나면 대부분의 기억이 소멸됐다.

요즘엔 영어를 제대로 하지 않았던 것 처럼 네트워크를 제대로 하지 않은 자신에게 얘기해주고 싶다.

"너 네트워크에서 배우는 거 하나같이 다 쓰는 거야."


어쨌거나 그때부터 공부를 했어도 모자를 판에 지금은 거기에 더해서 해야할 것들이 더 많아졌으니 부지런히 하는 수밖엔 없다. 그나마 다행인 것은 기술에 대한 호기심이 많은 탓인지 배움에 있어서 재미를 느낀다는 점이다.

힘내자 아자아자!



'마음이 뛰다' 카테고리의 다른 글

멀쩡하던 OpenShift가 죽었다.  (0) 2014.10.17
OpenShift Node 설정 중...  (0) 2014.09.18
Do you want to stay here?  (0) 2013.11.22
뚜렷도?  (0) 2013.10.10
Noblesse Oblige  (0) 2013.08.29



Chef Solo 입문

저자
이토 나오야 지음
출판사
제이펍 | 2014-02-21 출간
카테고리
컴퓨터/IT
책소개
[서버/인프라를 지탱하는 기술]의 저자 이토 나오야의 신작! D...
가격비교





거침없이 배우는 JBoss

저자
전준식 지음
출판사
지앤선 | 2014-02-27 출간
카테고리
컴퓨터/IT
책소개
대표적인 오픈소스 미들웨어 JBoss EAP 6 & AS 7 완...
가격비교


1. 프로젝트 트리(디렉토리)



2. 파일 포함 프로젝트 트리


'밤을 지새다 > OpenShift Origin' 카테고리의 다른 글

OpenShift Origin 설치 트러블 슈팅: Node  (0) 2014.09.22
OpenShift Node Host 설치 [1] - 작성 중  (0) 2014.08.18
OpenShift Origin V3  (2) 2014.08.14
ApplicationsController- create  (0) 2014.08.05
공부할 것들  (0) 2014.07.28

간단히 UML 다이어그램을 그릴 일이 있어 알아본 웹 다이어그램 드로잉 툴

많은 서비스가 나와 있겠지만 단순히 검색해서 상위에 나온 두 가지를 비교했다.

파워포인트를 써도 되었겠지만 좀 더 손쉽게 그리기 위해서이다 :)


1. Gliffy.com

UML을 포함해 순서도, 와이어프레이밍, 관계도 등의 작업을 할 수 있다. 

SVG, JPG, PNG  자체 포맷인 Gliffy로 저장할 수 있으며, 저장하거나 외부 이미지를 가져오려면 회원 가입이 필요하다. 가입은 무료.





2. Creately

Createle도 Gliffy와 비슷한 템플릿을 제공하며, 무료 회원 가입 후 로그인하여 저장 및 가져오기가 가능하다. 환경에 따라 다르겠지만 에디터 로딩은 Creately가 조금 더 느린 듯 하다.



설문 조사 폼을 만들이 있어서 작업 중에 설문 조사의 질문과 선택 옵션의 수는 가변적이므로 Parameter 컬렉션을 사용했다. 작업을 마무리 한 후 정상적으로 동작하는 지 테스트를 한 후 서버에 배포했다.


그런데.


이른바 "내 컴퓨터에서는 잘 되는데요?" 문제가 발생했다.


그렇다. 테스트를 할 때는 아무리 많은 질문과 옵션을 추가해도 잘 동작하던 것이, 서버에스는 IndexOutOfBound 예외를 내면서 설문이 제대로 처리되지 않는 문제가 발생했다.


설문 조사를 올리시는 분께서는 "음.. 7개가 넘어가면 설문 내용이 없어져요."라고 했고, 나는 "그럴리가 없다! 그 부분에 있어서 내 로직이 틀릴 리가 없다!" 라고 했다.

무지하면 용감하다더니, 어찌도 그리 당당할 수 있었을까? 다시 생각하니 부끄럽다.


서버에 배포된 설문 조사 폼을 확인해 보니, 정말 7개 이상으로 질문을 추가하면 죽는 것이 아닌가? 똑같은 설문 내용으로 내 컴퓨터(개발 컴퓨터)에서 테스트를 하니 "내 컴퓨터에서는 잘 된다."..


이 때까지는 자바스크립트로 설문 내용을 추가하는 부분에 이상이 있을 것으로 예상했다. 그런데 역시 이때까지는 Integer의 범위를 벗어나는 것도 아니고, 왜 하필 7개일까? 라며 이상하게만 생각하고는 자바스크립트 부분을 확인해 봤지만, 역시 이상은 없었다.


그러다 문득 톰캣 이 자식이 방해 공작을 하는 것이 아닐까 하는 생각에

"tomcat post form input limit length"를 키워드로 검색하니 한 블로그 글이 검색됐다.

그리고 그 글에는 내 문제의 원인이 무엇인지 명확하게 나와있었다. 그렇다. 파라미터의 수를 제한하는 설정이 있었던 것이다.


테스트 서버의 톰캣 설정은 그 파라미터 갯수 제한이 무한대라서 파라미터 갯수의 제한이 있다는 걸 모르는 상태에서는 그런 문제가 발생할 지 전혀 예측할 수 없었고,

실서버에서는 maxParameterCount="50" 으로 50개의 제한이 있었다.


질문 하나를 구성하는 속성은 제목, 질문 타입, 옵션 5개로 7개였으니, 톰캣이 수용할 수 있는 최대 질문의 수는 7개가 되는 것이고, 그 수 이상이 되면 서버가 빵~ 예외를 터뜨린다. 여태까지 파일 업로드 크기의 제한이 있는 줄은 알았지만, 파라미터의 수에 제한이 있을 줄은 몰랐다. 폼 파라미터의 갯수 및 크기 제한을 하는 설정은 아래와 같다.


server.xml 파일


maxParamterCount 속성은 폼 파라미터의 최대 수이고, maxPostSize는 폼의 최대 전송 용량(byte)이다. 값을 -1로 하는 경우 제한을 두지 않도록 한다.



"내 컴퓨터에서는 잘 되는데요?"

"님 컴퓨터에서도 잘 돌아가요"가 될 수 있도록 내가 사용하는 것들을 잘 알고 써야겠다.

다르다.

몰랐다.

그래서

한참을

돌았다.

그런데.

똑같네?

다른줄

알았다.


이게 무슨 소리지..

처음엔 내가 잘못 알고 있나? 싶었다. 


어떤 숫자가 있는지 없는지만 확인하면 되는 로직에 HashSet<Integer>를 사용했다.

거기에 0부터 24까지의 정수를 추가했다고 하면,

위와 같은 코드가 될 것이다.


그리고 저 아래와 같은 코드를 실행하면 출력 결과가 true인 것은 자명하다.


System.out.println(set.contains(1));


그렇다면 1 대신에 1l 또는 (long)1을 넣으면 true일 것이라고 예상했다.

헌데 결과는 false 이다.

내가 아는 바로는 int 의 표현 범위 내에서 int 와 long은 같은 hashCode를 가진다.

그래서 확인을 해봤다.


System.out.println(Integer.hashCode(1));

System.out.println(Long.hashCode(1));


실행 결과는 생각한대로 둘 다 1이다. int 범위 내의 어떤 값이든 그렇다.

그리고 정수 기본타입은 자신의 값이 곧 자신의 해시코드라고 알고 있었는데,

HashSet 이란 놈이 이렇게 배신을 할 줄이야.

이름만 보면 Set에 포함된 엘리먼트들의 유일성을 Hash 값으로 판단한단 말이 아닌가?


HashSet의 코드를 뜯어보니 HashSet은 내부적으로 엘리먼트의 저장을 HashMap을 사용한다.

왜인지는 모르겠다. 코드의 중복을 줄이기 위해서인지? 구현 편의인지.

HashMap은 Entry를 사용하니까 엘리먼트 하나를 저장하는 것보다 키, 밸류를 저장하는 게 손해아닌가..?

HashSet에서는 HashMap의 Entry의 value 값에 빈 Object객체를 넣는다.

빈 Object 객체는 static 변수로 선언되어 있다.

(private static final Object PRESENT = new Object();)


어쨌거나 어디서부터 잘못 이해하고 있는지 확인 하기 위해서 HashSet에서 contains 메서드가 호출하는 HashMap.containsKey 메서드를 살펴봤다.

containsKey에서는 map의 get메서드가 호출하는 getEntry(key)를 호출하고, key를 이용해서 Entry를 가져오지 못하면 null일 때 containsKey는 false가 되고 있으면 true가 된다.

그럼 getEntry에서는 무엇을 하느냐? key의 해시값을 이용해서 HashMap이 가지고 있는 hashSeed값과 적절한 연산을 통해 해시 값을 만들고, 이 해시를 이용해서 해시 테이블에 있는 엔트리를 찾는다.


결국 hash값으로 찾는게 맞단 소리고, HashMap의 hash 메서드의 인자를 long과 int 타입으로 테스트해보니 값이 같을 때 같은 값이 나온다.


여기까지의 결론으로는 결국 set.contains(1) 이나, set.contains((long)1) 이나 같은 결과를 보여야 하는게 정상인데..

왜 false라는 값이 나올까..?? map과 set을 좀 더 파헤쳐봐야겠다.



검색 중 Why you should not user HashSet/HashMap for Integer number 글 발견..

관련있는 글

안드로이드에서 Gson을 이용해서 서버에서 받은 Json 문자열을 파싱 할 때

필드 중에 Date 타입이 있다.


Gson에서 사용하는 날짜 포맷을 "yyyy-MM-dd HH:mm:ss:SSS z Z" 로 해두고, 서버쪽도 같은 포맷으로 날짜를 문자열로 변환하도록 해두었다.


서버의 타임존을 UTC로 사용하다가 편의상 KST(한국 표준시)로 변경해서 사용하니

받은 날짜의 문자열의 포맷은 아래처럼 된다.


"2014-03-15 21:07:32:221 KST +0900"


정확하게 멀쩡해 보이는 이 문자열을 Date 타입으로 변환하려면 오류가 발생한다.

Date 포맷이 아니라고 한다.

문제는 타임존을 의미하는 KST 부분,

까닭은 안드로이드에서 KST 타임존을 지원하지 않는다.


시간 설정을 한국, 서울 시간으로 해두어도 GMT로 적용되어 간다.


TimeZone.getAvailableIDs()나, TimeZone.getAvailableIDs(int rawOffset)을 이용해서 확인해보고 사용할 것을 그랬다. 라는 생각은 지금에서야 드는 생각이고, 저 예외가 생길 때는 도대체 정말 멀쩡한 문자열이 파싱이 안되서 미치는 줄 알았다. KST가 안되는 줄 꿈에도 몰랐다.

안드로이드에서 테스트하기 귀찮아 그냥 자바 프로젝트에서 같은 문자열을 Date 객체로 변환했을 땐 아~주 문제 없이 잘 파싱이 되었으니깐 말이다.


Moneycomb 진행하면서 시간의 표현에 대해서 많이 배우고 있다.


+ Recent posts