저작권 안내: 저작권자표시 Yes 상업적이용 No 컨텐츠변경 No

스프링5 입문

JSP 2.3

JPA 입문

DDD Start

인프런 객체 지향 입문 강의

윈도우에서 git 체크아웃 받는 과정에서 아래와 같이 파일 이름이 길어서 파일을 생성할 수 없다는 오류가 발생할 때가 있다.


error: unable to create file ...파일경로 (Filename too long)


이는 윈도우 API의 파일 경로 길이가 260자 제한을 갖기 때문이다. 이 제한을 없애려면 다음 명령어를 사용해서 git의 core.longpaths 설정을 true로 지정하면 된다.


git config --system core.longpaths true



Posted by 최범균 madvirus
TAG GIT

댓글을 달아 주세요


"OKKYCON 2017 소통, 개발에 숨을 불어넣다"에서 집중해서 들은 세션 내용 요약:


개인적 소감은 "가길 잘했다"!


XP 더 나은 소프트웨어 품질을 위한 일의 방법 (정윤진)


프로젝트를 통해 배운 것

  • 작은 규모 팀이 효율적
  • 다른 전문성이 모여 어려운 문제 해결
  • 문제를 즉각 공유해야 빠른 해결 가능
  • 팀 구성원의 성향이 다르면 감정적 문제가 커지는 경향
  • 스타트업은 제품보다는 보통 팀이 깨져서 무너짐
작은 팀은 소통에 도움이 됨
  • 소통 횟수가 줄어듬
  • 팀이 커지면 소통 비용 증가(허락을 구하기 위한 미팅 시간 증가)
  • 팀이 작으면 쉽게 공유
밸런스팀
  • 매니저, 사용자, 엔지니어, 데이터 사이언스 등으로 구성된 팀
  • 가치: 신뢰, 경험 공유(배움), (작은) 실패를 환영하는 문화, 다양한 목소리
  • 적은 스트레로 더 대단한 걸 더 빠르게 이룸
XP/TDD
  • 결국 모든 것은 빠르고 안전하게 제품을 내보내기 위함
  • 예: TDD - 여러 이유로 테스트 작성을 포기하지만, 지속적으로 빠르게 가려면 테스트 필수
  • 예: 페어 - 돈이 아까울 수 있으나, 2명이 같이 일하면 생산성은 20% 떨어지나 품질은 80% 향상
피보탈 업무 패턴
  • 8:30 아침 식사 (대화)
  • 9:00 스탠드업 (5분 진행)
  • 9:05 팀 스탠드업 (페어 결정), 해결할 스토리는 트래커에 존재, 늦어도 9:30분을 넘기지 않음
  • 9:20 페어 업무 시작
  • 11:30 점심 식사
  • 13:00 오후 시작
  • 18:00 아무도 없음

채용시 하루 동안 페어를 하고 결정한다는 것이 인상적



애자일은 애자일이란 단어를 버려야 한다. (신정호)


애자일의 형식적인 부분을 버려야 함. 형식으로 망하는 프로젝트 징후:

  • 애자일에 대한 맹신
  • 목표 없는 작은 주기
  • 의미 없는 회의
  • 기준 없는 추정
  • 자발적이지 않은 교육
  • 겉치레 시스템 평가
역할

직책보단 역할에 집중

  • 스크럼 마스터니 PO니 하는 직책보다는 "파악, 결정, 책임" 역할을 수행해야 함
파악
  • 파악을 하지 못하면 결과적으로 결정할 수 없음
  • 파악하기 위한 도구: 정책, 요구사항 기록, 통신 프로토콜, UI/UX, 진행사항, 테스트 케이스, 커밋기록, 현황판 중심 데일리 미팅, 리스트 목록 등
  • 팀내/팀외적으로 놓치는 일이 없는지 계속 확인 필요
결정
  • 결정에 필요한 배경, 결정할 케이스를 객관식으로 제공
책임
  • 파악 -> 좋은 결정 -> 책임은 작아짐(없어짐)
구성원(내부/외부 포함) 간 협업, 부딪칠 수 있는 경우를 정리
  • 기획자 vs 디자이너
    • 기획자는 와이엎프레임 없이 요구사항 위주 정리, 디자이너는 사용자에 맞는 디자인
  • 기획자 vs 개발자 vs 품질 책임자
    • 테스트케이스 중심 개발(상호 간 인식 차이 줄임), 테스트케이스 공유 시간
  • 기획자 vs 품질 책임자
    • 정책이 정해지지 않은 경우 데일리 정책 회의
  • 디자이너 vs 개발자
    • TODO 목록
  • 최고의사결정자 vs 팀/TFT
    • 일정 관련 정량적인 수치 기반 상황 공유
  • 팀 vs 팀

스케줄링


중요한 건 결국 정량적 파악. 다음을 고려:

  • 근무일수, 휴가, 테스트 일수
  • 개발 완료 기준
  • 늘 어디쯤인지 파악할 수 있어야 함

스트린트 회의

  • 정책과 요구사항 발표
  • 구현 이슈 논의
  • 모호한 상황을 명확하게 파악하고 결정
  • 회고를 했다면 이어서 진행
스트린트
  • 기획 중심 기간, 구현 중심 기간, 테스트 기간 중심에 따라 알맞게 진행
    • 예, 기획 중심 기간에는 부문 미완성이지만 흐름을 먼저 보임
    • 예, 구현 중심 기간에는 부문 완성으로 기능을 먼저 보임

회고


회고는 해결한 것과 해결할 것을 명확히 하는 시간

  • 진행 상황 공유
    • 목표로 했는데 한 것 못 한 것 공유
    • 결과 보기(가장 중요)
    • 이슈 현황판, 데일리 미팅 기록
    • 남은 일(테스트케이스로 관리)
  • 리스크 확인
  • 마지막 스트린트에 좋은 점, 나쁜 점(감정 고려)


애자일은 말이나 형식이 아닌 행동으로 보여주는 것



협업도구로 제대로 말하기 (김동수)


협업 도구를 제대로 쓰게 하는 것이 어려웠음

  • 구성원들의 변화 필요성이 있거나 확실히 지금 문제를 해결할 솔루션이 되는 경우, 정착할 가능성이 높아짐

협업 도구를 변경하고 싶다면

  • 협업을 더디게 만드는 것을 식별
  • 구성원의 요구사항 수집
  • 영향력있는 조력자(대표, staff 부서) 필요
  • 비용 발생시, 최종 결정권자를 설득

협업 도구 평가 기준

  • 사용이 쉬운가
  • 검색할 수 있는가
  • 공유가 쉬운가
  • 다른 도구와 연동
  • 사용료 대비 가치가 충분한가

마켓컬리 적용

  • 도구에 대한 교육 진행
  • 도구에 대한 계정 관리를 관리팀에 맡김
  • 프로필 사진은 소통에 도움
도구로서의 말
  • 상대방이 이해할 수 있는 단어
  • 단어가 정확해야 함
  • 날짜가 정확
  • 검색 가능하게
  • 에티켓


생산성 지향의 커뮤니케이션과 기업 문화(최영근)


커뮤니케이션

  • 소프트 스킬 > 하드 스킬 (소프트 스킬이 18% 더 높음)
  • 소통 == passive skill
    • 소통에서 90% 전달은(10% 손실) 매우 낮은 완성도임, 6회 쌓이면 53%
  • 소통은 정보 전달 목적 -> 청자 중심

소통법

  • 경영진에게
    • 신속한 의사 결정 목적 -> 단기적 효과, 숫자 사용
    • 집행 요약(executive summary) 사용
  • 세일즈
    • '고객이 원하잖아요'에 숨어있게 하지 말라
    • 요구를 끌어내는 대화 (목적, 대안 등을 끌어낼 필요)
  • 자기 자신
    • 철저한 자기 검열 필요 (나를 위한 결정은 아닌지)
    • 성과를 위한 결정인가?

관성, 조직

  • 규칙화, 문서화(성문화), 선언 --> 무언의 압박
  • 넥플릭스 사례: 스포츠팀처럼
    • 계약 관계, 전문가, 조직의 비즈니스 목표 달성
  • 유비쿼터스 언어
  • 회의록 작성
    • goal, discussion point, agreement, action item을 담음
  • 박터지게 싸우자
    • 팁1, 우리 잘되려고 하는 거지 --> 나 자신도 흥분을 가라 앉히는 효과
    • 팁2, 설득되면 확실하게 리액션
  • 메신저 : 정원사 필요
    • 정원사는 검열을 하지 않는다는 것을 느끼게 해야 함

협업의 미신 5가지 - 근거 기반 협업으로 가기 위해 (김창준)


미신1 : 프로그래밍은 잘 하는데 협업은 잘 못 해? 또는 반대 협업은 잘 하는데 프로그래밍은 딸려?


프로그램과 협업은 별개라는 사고!


뿌리:

  • 잘못된 연구 방식 (1960년대)
    • 뛰어난 프로그래밍을 측정한 기준이 잘못 됨(예, 문제를 잘 푼 사람이 뛰어난 프로그래머라 가정하는 식)
    • 한 명으로 실험실에서 혼자두고 측정

1990년대부터 여러 명을 두고 측정해 보니,

  • 뛰어난 프로그래머 그룹의 조언 : 사회적 조언 포함 (70%)
  • 평균적인 그룹의 조언 : 사회적 조언이 적음 (20%)
  • 실제로 성과를 잘 내는 프로그래머일수록 대화에 많은 시간 투입
  • 프로그래밍을 재정의해야 하는 순간이 옴
협력도 프로그래밍의 한 부분으로 인지하기 시작


협업은 프로그래밍을 잘 하는데 있어 필수적인 요소



미신2 : 팀의 퍼포먼스는 가장 뛰어난 사람이 결정


MIT의 연구:

  • CQ(집단 지성) - 어떤 팀은 어떤 일을 줘도 잘 하고, 어떤 팀은 어떨 일을 줘도 못함
    • 가장 잘 하는 사람, 평균 IQ도 팀의 성과에 영향을 주지 못함
  • CQ 성과에 영향을 주는 지표 
    • 공감력
    • 말을 골고루 함(여러 명이 골고루 할 때)
구글 연구: 탁월한 팀의 특정 찾기
  • 팀의 성과는 개기인의 기술적 전문성이 중요하지 않음,
  • 심리적 안정감이 높을수록 성과가 좋음

일이 복잡할수록 더 그러함


미신3 : 전문가를 모아두면 협력을 잘 할 것이다


  • 전문성에서 사회적인 요소를 빼고 봄
  • 오래 본다고 협력이 늘지 않음 (예, 양치질), 협력 훈련을 받은 적이 거의 없음
  • 협력할지 논의한 뒤에 일을 진행하면 성과가 좋아질 수 있음

의식적인 협력의 중요성 : 어떻게 협력할까를 먼저 고민



미신4 : 협력을 잘 하는 것은 서로 좋은 관계를 유지하는 것이다


  • 미신: 협력 잘 하는 것 = 인간 관계 좋은 것 = 술 자주 마시는 것
  • 회피적으로 좋은 관계인지 고민 필요 -> 갈등을 처리하는데 능숙하지 못함
  • (건설적으로) 부정적인 감정을 얘기할 수 있는 팀이 성과가 좋음, 솔직하게 불만을 얘기할 수 있어야 좋은 관계

미신5 : 분업을 잘 하는 것이 협업을 잘 하는 것이다

  • 분업 외에는 협업에 대한 아이디어가 없음
  • 리차드 행만: 
    • 팀과 워크 그룹 구분
      • 팀 : 구성원 사이에 네트워크로 연결
      • 워크 그룹 : 구성원 사이에 트리/스타 구조로 연결
    • 팀의 성과가 압도적으로 높음
    • 일이 불확실할수록 팀의 성과가 높음
  • 왜 잘하게 되느냐?
    • 기본적으로 피어 코칭 때문(동료 간 소통)
  • 공통점, 팀의 효과성을 예측하는 변수 : 상호 간 모니터랑하는 팀 -> 성과가 높음
    • 서로 의견 제시하는 팀

70 20 10

    • 성과의 70%는 팀원이 만나기 전에 이미 결정
    • 20%는 시작하는 시점에 결정
    • 10%는 일을 하는 과정에서 결정
  • 미리 사전에 어떻게 일할 지를 미리 정하고, 초반에 굉장히 신경 써야 함
분업을 너무 많이 해서 문제가 된 에피소드: "131번 서버 누구 담당입니까?"


상호 작용이 중요함


QA에 나온 이야기

  • 조직의 미션: 개인의 일을 한다는 느낌을 없애야 함!
    • 우리 팀의 최고 우선순위가 뭡니까?
  • 사람이 계속 바뀌는 환경에서는 더더욱 사회적인 요소에 신경을 많이 써야 함
  • 의견 내기가 무섭다 --> 일단 우리 안에서 해보는 것!
    • 예: 단계를 구분 - 아이디어를 내는 것과 누가/어떻게 할 지를 정하는 것을 구분
      • 누가 할지 고를 때 팀이 함: 독박이 아니고 팀원이 협력하게 유도
      • 누군가 해야 하는데 하기 싫은 일 -> 팀이 회의를 해서, 어떻게 전환을 하면 재미있어질 것인지 논의
  • 문화 -> 작은 상호작용이 쌓이면서 주변에 영향을 미침


Posted by 최범균 madvirus

댓글을 달아 주세요

윈도우8 PC에 Virtualbox를 설치하고 게스트OS로 윈도우7을 생성했다. 그런데, 이상하게 윈도우7 머신에서 네트워크가 안 되는 문제가 발생했다. 그래서 Vagrant로 Centos 머신을 생성했다. 역시나 Centos 머신도 네트워크가 안 됐다. 포트포워딩 설정을 해도 Centos에 붙질 않았다.


Virtualbox와 Vagrant를 재설치해보고 보안 관련 프로그램도 살펴봤는데 영 문제가 해결되지 않앗다. 이래 저래 삽질을 하면서 증상은 다음과 같음을 알 수 있다.

  • 게스트OS에서 ping은 됨
  • 게스트OS에서 TCP 연결이 안 됨 (예, 윈도우 게스트OS에서 브라우저로 연결이 안 됨. telnet으로 외부 서비스에 특정 포트로 연결이 안 됨)

증상이 이상해서 범위를 좁혀서 구글에서 검색을 하다가 아래 명령어를 통해서 해결할 수 있음을 알아냈다.


netsh winsock reset


그런데, 이 명령어를 실행하고 나니 DB 보안 프로그램인 샤크라맥스가 동작하지 않았다. 실제 원인은 샤크라와 버추얼박스 간에 문제였던 것있다. 샤크라맥스를 언인스톨하고 다시 설치했더니 이제 샤크라맥스도 정상 실행되고 버추얼박스에 생성한 게스트OS의 네트워크도 정상 동작한다.


정확히는 모르지만 버추얼박스를 설치한 뒤에 샤크라를 설치해야 버추얼박스의 네트워크 기능이 정상 동작하는 듯 하다.

Posted by 최범균 madvirus

댓글을 달아 주세요

  1. 2017.06.21 09:25  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

오는 3월 21일 신림프로그래머 공개 모임의 "이벤트 소싱 학습 내용 공유" 시간에 사용할 발표 자료입니다.



Posted by 최범균 madvirus

댓글을 달아 주세요

  1. 2015.03.22 00:09  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  2. bluepoet 2015.06.05 14:56 신고  댓글주소  수정/삭제  댓글쓰기

    전에 들었던 이벤트소싱이 어떤 내용인가 자료 살펴봤는데

    내용만으로도 상당히 잼있을 것 같네요.

    나중에 저도 실습한번 해봐야겠슴돠^^

예전 김창준님의 강의 영상을 보고 정리한 내용(강의 영상은 '개인이 조직을 변화시키는 법 http://agile.egloos.com/5742985 에서 볼 수 있음)


성공한 창업가들의 5가지 원칙


Bird in hand principle

  • 성공한 창업가 : goal 생각 없이 mean을 생각하고, 방법으로 뭘 할 수 있을지?
    • goal은 안정된 환경인 경우
  • mean 중심 전략의 세 가지 좋은 출발 점: What I know, Whom I know, Who I am

Crazy Quilt principle

  • stakeholder를 늘려나가는 것
  • 사람을 내 편으로 만들기
  • TDD 도입 성공하는 모습의 예: 초기부터 스터디를 같이 해서 내 편 만들기
Affordable loss principle 
  • ROI 중심이 아니라, 잃어도 되는 돈의 양을 정하고 착수
  • 랜덤한 상황에서는 오래 살아 남아야 함

Pilot in the plane principle

  • 예측은 못 해도, 제어를 할 수 있음 (non predictable control)
  • 제어할 수 있는 만큼은 예상 안 해도 된다.

Lemonade principle

  • 생각못한 상황이 발생할 때, 그것을 이용해라

관련 링크:

  • http://en.wikipedia.org/wiki/Effectuation


Posted by 최범균 madvirus

댓글을 달아 주세요

신림프로그래머 모임에서 발표할 'JI 개발 이야기 리뷰' 자료입니다.



Posted by 최범균 madvirus

댓글을 달아 주세요

신림프로그래머 모임에서 공유했던 '리뷰의 기술' 책 소개 자료입니다.



Posted by 최범균 madvirus

댓글을 달아 주세요

스프링캠프 2014에서 정리해 놨던 걸 이제서야 블로그에 옮긴다.


실용적 소프트웨어 설계를 위한 근본적인 질문들 (안영회)

- SW는 유기체

- Contract & Integrity: 유비쿼터스 랭귀지, 스펙 등

- Contract & Integrity >> 표준화

- 용도에 맞는 설계 적용: 예, 복잡한 상태 변화를 표현하기 위한 상태 다이어그램

- 레거시 수정의 어려움 중 하나: 멘탈 모델이 그려지지 않음 (예, 이름을 잘 정해서 응집을 높이는 등 멘탈 모델을 향상시킨다.)

- 개발 팀 별 컨텍스트를 아우르는 협업


마이크로 서비스 구축 사례 (박찬욱)

- 10년간 운영해 온 커머스 사이트 시스템을 RESTful API 기반 마이크로 서비스로 쪼개는 과정

- 화면과 API를 쪼개고, 각 화면과 API도 별도로 분리

- 20개 사이트!!! 그 동안 프로젝트를 Copy&Paste&Modify 해서 사이트 추가 -> 수정의 어려움, 비용과 제약 (기술부채) 확산

- 그 과정:

 > 한 통의 WAR를 두 개 코드 분리: 화면 코드 - 로직(API) 코드

 > 화면을 위한 확장(예, 디바이스 추가)은 화면용 프로젝트(WAR)만 추가

 > 재사용 단위를 API로 맞춤

- 장점:

 > 영역별 확장

 > 분산해서 개발할 수 있는 환경

- REST 클라이언트를 스프링데이터처럼 런타임에 자동생성되도록 함

- API Spec을 별도 메이븐 모듈로 작성해서, 양쪽에서 의존으로 추가 -> 의존성 관리 어려움으로 코드가 아닌 스펙만 제공하는 것 고려 중

- 무엇을 API로 뽑아야 하나?

- Join의 최소화를 위해 적극적 캐시 도입

- 문제 발생시 문제 발생한 곳을 찾는 어려움 (여러 장비의 로그를 확인해야 함) -> Trace Key를 모든 로그에 보관


주키퍼, Vert.x 활용 실시간 푸쉬 서비스 개발 (이연복)

- 철가방 시스템에서 주문중계 서비스의 실시간 알림 기능 구축 사례

- 사용자가 앱으로 주문 발생시 가맹점에 어떻게 (최대한 실시간으로) 전달할 것인가?

- 쉬운 방법: 주문이 들어오면 전화로 다시 가맹점에 주문 전달 (정보 누락 등 문제 발생)

- 가맹점에 주문을 통지 받을 수 있는 프로그램을 배포(Flex Air로 제작)

- Flex Air와 서버 간 통신은 BlazeDS를 사용

- Flex Air와 Zookeeper 간의 중간 통신은 Vert.x로 만든 LB로 사용

- Vert.x의 분산 이벤트 버스로 클러스터 구현

- 이벤트버스를 이용해서 버티클 간 통신(데이터 전달 등)


스타트업 망한 이야기 (강규영)

(들었던 내용을 모두 옮겨 적고 싶었지만 서서 들은 관계로..... 아래 두 가지만 적음)

- 넘치는 쪽지를 비활성 유저에게 보내기: 일단 유저에게 통지하고, 그 유저가 액티브 상태가 되면, 실제 쪽지 전송 (미리 보내지 않음)

- 한글 자소 분리해서 필터 학습


REST (김강우)

- REST: REpresntional State Transfer

- REpresntational -> Resource

- State Transfer

 > State: 상태의 전이가 발생

 > 상태 전이를 위한 방법: POST(C), GET(R), PUT(U), DELETE(D)

 >> POST(C): /order (성공: 201 응답이면 좋을 것, Location: /order/{생성된ID})

 >> GET(R): /order/{id}

 >> PUT(U): /order/{id} (200(데이터 보냄), 204(데이터는 안 보냄), 409(Conflict, 예, 누군가 이미 변경했다면, 즉, 낙관적 락!))

 >> DELETE(D): /order/{id}

- Hypermedia 응답에 상태 전이를 위한 링크 포함 (HATEOAS: Hypermedia As The Engine Of Application State)

 > 장점1: 다음 전이 상태를 쉽게 응답으로 알 수 있음

 > 장점2: 연결되는 주소를 알 수 있음 (결제 주소가 넘어 옴)

- EntityTag(etag)

 > 수정시, etag를 일종의 Resource의 버전으로 사용가능

- 전체 수정, 부분 수정: POST? PUT?


Posted by 최범균 madvirus

댓글을 달아 주세요

이클립스 Luna (4.4)에 Dark 테마가 추가됐다. 뭔가 있어 보여서 Dark 테마를 적용해 봤는데, 아래 그림처럼 에디터 부분이 어울리지 않는 색상을 사용하는 것이 거슬렸다.



뭐가 있겠지 싶어서 구글 신께 여쭤보니 Eclipse Color Theme 라는 걸 설치하라고 알려주신다. Help -> Eclipse Market Place에서 Eclipse Color Theme 플러그인을 설치하면 된다. 이 플러그인을 설치하면 아래 그림처럼 Preferences > General > Appearance에 color Theme 메뉴가 생기는데, 이 메뉴에서 Dark 테마에 어울리는 색상 테마를 선택하면 된다.



다음은 색상 테마로 Sublime Text 2를 적용한 결과 에디터 화면이다.






Posted by 최범균 madvirus

댓글을 달아 주세요

2014년 2월 27일 코엑스에서 열린 Gaming on AWS 세미나에서 기억나는 내용을 정리해 본다. 세미나 제목에도 있지만, 게임 업계의 AWS 적용 후기가 주된 내용이다.


여러 세션을 종합해보면 AWS를 사용하는 이유는 다음의 몇 가지로 좁혀진다.


이유

내용 

글로벌 서비스

해외 IDC에 장비를 둘 경우, 해외의 엔지니어 고용, 해외 법, 장애 대응 등 서비스 운영에 많은 어려움이 있다. 각 지역별로 서버를 둬서 최종 사용자의 위치에 따라 가까운 서버에 연결하도록 만들려면 어려움은 더욱 배가 된다. AWS를 사용하면 이런 문제점을 대부분 해소할 수 있다. 


AWS는 북미, 유럽, 남미, 동남아, 중국, 일본 등 10여개의 리전이 있고, 50여개의 Edge가 존재한다. 또한, Route53을 통해 최종 사용자의 위치에서 가장 가까운 리전이 사용되도록 할 수 있다.

운영 민첩성

새로운 인스턴스를 생성하는데 소요되는 시간이 불과 몇 분에 불과하다. 또한, 트래픽 변동성이 심한 서비스에 대해, 트래픽 상황에 따라 자동으로 인스턴스를 생성하거나 제거할 수 있다.

재시작을 통해 같은 인스턴스의 스케일업/다운이 가능하다.

비용

최대 트래픽 기준으로 인프라를 구축할 필요가 없고 실제 사용량에 따라 비용을 지불하기 때문에 전체적인 운영비용을 절감할 수 있다. 또한, RC(Reserved Capacity)를 사용하면 할인된 금액으로 서비스를 사용할 수 있다.


한빛소프트의 경우 미국IDC를 AWS로 옮겨서 운영 비용을 32% 낮출 수 있었다고 한다. (6억 3천에서 4억 3천으로 낮춤)


AWS 인스턴스의 성능/서비스와 관련해서 다음의 내용을 언급했다.

  • 네트워크 Latency: SR-IOV를 지원하는 인스턴스 타입 추가해서 Latency 감소
    • SR-IOV: 가상 머신이 하이퍼바이저를 거치지 않고 랜카드와 직접 통신
  • EBS(Elastic Block Store)를 이용해서 DISK IO 속도 높일 수 있음
  • ELB: Pre Warm을 통해 급작스런 트래픽 증가시 발생하는 ELB의 성능 저하 현상을 방지할 수 있음
  • CDN: 전 세계에 50개의 Edge가 있고, 한국에도 존재
  • 분석을 위한 서비스 제공: Redshift(DW도구), Kinesis(실시간 분석 도구), EMR(맵리듀스)
  • 보안 서비스
    • 기존과 같은 방식의 관제 서비스를 받기 어렵지만, 마켓플레이스를 이용해서 보안 서비스를 제공받을 수 있음
    • VPC를 통한 VPN 지원
  • 최근 서울-Tokyo리전에 대한 Latency가 200ms에서 40ms 수준으로 떨어졌음. 따라서, 국내 대상 서비스를 하는 경우에도 Tokyo 리전이 매력이 있음
재미났던 점: 쿠키런 발표 내용 중 AutoScale 관련한 내용
  • Chef를 이용해서 서버 설정 관리
    • Chef를 이용해서 설정한 서버를 AMI로 만들어서 S3에 보관,
    • AutoScale 시에는 이 AMI를 이용해서 서버 확장
    • AMI 생성 시점과 그 이후의 변동분은 Chef에 의해 반영
  • CloudFormation 이용해서 인프라 형상 관리 (예, 평균 CPU 사용률이 60%가 넘으면 인스턴스가 4개 추가와 같은 규칙을 설정 파일로 관리)
  • CircleCI를 이용해서 최신 WAR 파일을 S3에 보관하고, 자동 추가되는 인스턴스는 Chef에 의해 S3에서 WAR를 가져와서 실행 (새로운 인스턴스는 새 버전을 사용)
  • 새 버전 배포 방식: 새 인스턴스를 실행하고 기존 인스턴스를 제거하는 방식으로 롤링 업데이트
  • 로그는 LogStash를 이용해서 수집, Elastic Search에 보관해서 로그 탐색 (1달치 보관)
    • 인스턴스 종료시 10분이 넘어가면 AWS에서 인스턴스를 강제로 제거함
    • 따라서, 인스턴스 종료시점에 후처리가 10분을 넘기면 데이터 유실이 발생함, 이 점에 주의
흥미로웠던 부분: 게임 분석과 관련해서 5Rocks에서 발표한 내용
  • 한국 게임 서비스들의 트래픽을 분석해보면 최소/최대 사이에 10배 정도 차이가 남
  • 최대 트래픽이 발생하는 시점은 오후12시~1시 (점심 시간), 그 다음은 9시~11시
  • 분석 역량의 차이가 게임의 흥망과 연결
    • 못하는 회사: 단순히 DAU(Daily Active User), Session Count, ARPU 통계만 확인
    • 잘하는 회사
      • 추가로 (구매, 빈도, 레벨 등 기준으로) 상위 User와 비교
      • 레벨/종복/기타 분류 별 ARPU 비교
    • 일본 회사가 잘하는 것: FQ(Frequency) 분포를 이용한 분석
      • 방문회수,게임시간 등으로 그룹을 나눠 분석
      • 휴면 유저도 휴면일수 등으로 구분해서 관리/분석


Posted by 최범균 madvirus

댓글을 달아 주세요

오늘(2014-02-05) 있었던 SSAG 2차 세미나(http://beyondj2ee.wordpress.com/2014/01/23/2309/) 내용을 두서없이 생각나는대로 정리해 본다.


첫 번째 세션, MongoDB를 사용하면서 알게 된 것들, 한대희님 발표


이음 서비스로 유명한 이음소시어스에서 Hey라는 서비스를 구축하면서 사용했던 MongoDB 적용 후기

  • Hey 서비스에 MongoDB를 사용한 이유
    • 설치 쉬움
    • RDBMS와 유사한 인덱스 지원
    • Ruby ORM 존재
    • 매칭 데이터가 증가하지 않을까 기대감 (샤딩 고려)
  • 인프라 구성
    • AWS에서 MongoDB 이미지를 이용해서 3대로 Replica Set 구성
    • 구성: Primary 1대, Secondary 1대, Arbiter 1대
  • 모니터링
    • NewRelic / MMS (mms.mongodb.org): 모니터 + 백업 지원 (연간 50$ 이하 사용시 무료라 함)
  • 사용하면서 불편했던 점
    • 익숙하지 않은 쿼리 (SQL 만큼 편하지 않음)
    • 데이터 타입 문제
    • 빈번한 Update시 데이터 블록 재구성에 따른 성능 저하
    • DB Level Lock (진짜인지 추가로 확인 필요)
  • 서비스의 규모가 최초 예상을 밑돌아 샤딩 등의 확장성 검증은 하지 못했음
  • 어디에 쓰면 좋을까?
    • 데이터가 간 관계가 없음
    • 데이터가 순차적으로 증가
    • Insert 위주 (예, 로그나 채팅 메시지 등)
    • 수평 확장 대상
  • 적용 전 고민
    • 데이터 간 조인이 필요 없는지?
    • Update나 Delete가 자주 발생하는지?
    • Schemaless가 필요한지?
    • Write 성능이 중요한지?
    • 데이터가 샤딩을 필요로 할 만큼 커지는지?
  • 기타 두 분의 배틀 내용 중 기억나는 단어
    • MariaDB DokuDB 성능 좋음
두 번째 세션, AWS 인프라 구축 경험, 김민태님 발표

목소리나 발표 모습이 매우 낯이 익다 했더니, 작년 12월에 있었던 OKJSP 13주년 컨퍼런스에서 프론트 관련 주제로 발표한 분이셨다.
  • checkit.us 서비스를 만들면서 적용한 이야기
  • 서버 측 기술: nodejs, MongoDB
  • 최초: heroku를 선택했음
    • 프로토타입 목적으로는 적합할지 모르나, 너무 느림
  • AWS를 선택한 이유
    • 레퍼런스가 많음
    • PaaS 보다 자유로움 + PaaS 만큼 편리한 부분도 있음
    • 글로벌 서비스에 장점이 있음
  • 도입
    • 최초: t1.micro로 테스트
    • AWS로 이전하는데 약 1달 정도 소요 (최초 2주는 AWS 자체를 알아가는 과정)
    • 현재 구성: EC2 1개, MongoDB 3개, ELS (서비스 트래픽에 따라 EC2 인스턴스가 2개까지도 가는 상황)
      • 월 비용은 1,000$ ~ 1,300$ 사이
  • 한국은 약간 느린 감이 있지만, 서비스엔 충분함
세 번째 세션(?), AWS 비용 최적화 방법 안내

아마존에서 직접 오셔서 최적화 방법을 안내함
  1. 과하게 자원을 쓰지 말 것 (90% 이상 펑펑 놀고 있다면, 스펙을 낮춰야 함)
    1. CPU, Disk 등 과도하게 놀지 않도록
  2. 자동 수평 확장 기능을 사용할 것 (쓴 만큼 내므로)
    1. 예, 쿠키런의 경우 트래픽이 없을 땐 2대에서 많을 땐 60대로 자동 확장/축소
  3. RI(Reserved Instance)를 사용해라
    1. 연 단위 계약을 하면 비용이 절감 됨
    2. RI를 적용할 인스턴스는 약간 고사양 장비로 맞추고, 자동 확장되는 인스턴스는 RI에 비해 상대적으로 낮은 스펙을 사용하는 방식 등을 고려




Posted by 최범균 madvirus

댓글을 달아 주세요

윈도우에서 작성한 리눅스 쉘 파일을 리눅스에 배포할 때, 종종 실행이 제대로 되지 않는 경우가 있는데, 그것은 윈도우의 라인 구분자가 CR(캐리지 리턴, \r)-LF(라인 피드, \n)인 반면에 리눅스는 LF이기 때문이다. 라인 구분에 포함된 캐리지리턴으로 인해 잘못된 텍스트 값을 사용하게 되고 이로 인해 파일이름이라든가, 여러 부분에서 문제가 발생하는 것이다.


리눅스에서 CR-LF를 LF로 변환해주는 몇 가지 방법이 있지만 (검색해보니 다양한 방법이 있다), 개발PC가 윈도우다 보니 배포 과정에서 어떻게 처리하는 방법이 없을까 고민했는데, 배포 도구로 사용중인 Ant에서 처리하는 방법을 찾았다.


Ant에 보면 FixCRLF 라는 태스크가 있는데, 이 태스크를 사용하면 특정 파일의 라인 구분자를 손쉽게 변경할 수 있게 된다. 아래는 이 태스크의 사용 예를 보여주고 있다.


<target name="deploy" depends="package">

<copy todir="./target-real">

<fileset dir="./src/script">

<include name="*.sh"/>

</fileset>

</copy>

<fixcrlf srcdir="./target-real" includes="**/*.sh" eol="lf" />

...

<echo message="===== Complete Deploying ======" />

</target>


위 코드에서 <fixcrlf> 태그는 ./target-real에 있는 모든 sh의 라인 구분자를 LF로 변환해주기 때문에, 별도의 귀찮은 작업들(리눅스에서 변경해준다거나, 개발 환경의 라인 구분자를 변경한다거나 하는 등)을 할 필요가 없다.

Posted by 최범균 madvirus

댓글을 달아 주세요

김창준님의 "당신이 제자리 걸음인 이유: 지루하거나 불안하거나(http://agile.egloos.com/5749946)" 글을 필요할 때 마다 매 번 읽으면 좋겠지만, 보다 수시로 볼 수 있도록 책상 주변에 붙여놓기 위해 아래 이미지를 한 장 만들어본다.





Posted by 최범균 madvirus

댓글을 달아 주세요

  1. 개발자 2014.01.20 10:02 신고  댓글주소  수정/삭제  댓글쓰기

    좋은글 공유할께요

글을 읽다 보면 1급 함수(first-class function)처럼 1급(first-class)이란 단어가 나오는데, 이 단어의 의미를 간단히 정리해 보았다.

  • 파라미터로 전달될 수 있다
  • 리턴 값으로 사용될 수 있다
  • 변수에 할당할 수 있다
  • 런타임에 생성될 수 있다
first-class function 의 의미는 함수를 파라미터로 전달하고, 변수에 할당하고, 리턴 값으로 함수를 받을 수 있고, 런타임에 함수를 생성할 수 있다는 의미가 된다.



Posted by 최범균 madvirus

댓글을 달아 주세요

  1. 이루리 2013.06.20 15:22 신고  댓글주소  수정/삭제  댓글쓰기

    그러면 1급함수가 아닌 함수는 어떤것인가요? 검색해두 정보를 못찾아 질문드려요~

    • 최범균 madvirus 2013.06.21 08:49 신고  댓글주소  수정/삭제

      1급함수가 아닌 함수가 아니라,,, 언어에서 함수를 1급으로 처리하느냐에 대한 겁니다.
      자바의 경우는 다음과 같은 코드가 안 되죠.

      // public void myFunc()이 있다고 가정
      Some some = new Some();
      some.callAny(myFunc); // 파라미터로 메서드 자체를 줄 수 없음

      자바에서는 메서드가 1급으로 처리되지 않기에, 메서드 자체를 생성자나 변수나 파라미터 등에 전달할 수 없습니다. 메서드만 따로 생성하는 것도 안 되구요.

      반면에 자바스크립트에서는 아래와 같은 코드가 가능하죠.

      function someFunc() { ... }
      otherFunc(someFunc) // 함수 자체를 파라미터로 전달 가능
      var a = someFunc; // 함수를 변수에 할당 가능

      즉, 자바 스크립트에서는 함수를 1급으로 처리하고 있습니다.

  2. 지나가다 2017.06.08 17:57 신고  댓글주소  수정/삭제  댓글쓰기

    좀 엉뚱한 질문같지만, 그러면 왜 굳이 "1급" 이라고 부르나요?
    1급 함수가 있으면 2급(second-function), 3급도 있다는 소린가요?

팀에서 했던 빅데이터 개요 발표 자료


Posted by 최범균 madvirus

댓글을 달아 주세요