Unicode

• ES6에 유니코드 관련 프로퍼티와 메소드 추가
• 유니코드는 U+0031 형태로 표현
• 코드 포인트
  • 0031이 코드 포인트 또는 문자 코드로 알려져있음
  • 코드 포인트 값으로 문자/기호/이모지/아이콘 등 표현
  • 4자리 이상의 UTF-16 진수 형태
  • 110만개 이상 표현 가능
• plane : 코드 포인트 전체를 17개 평면(plane)으로 나눔
  • 하나의 plane은 65535개
  • 첫번째 plane을 BMP(Basic Multillingual Plane)
    • 일반적인 문자가 여기에 속함
• euc-kr은 사용하면 안됨.
  • 해외에서는 깨진 문자열로 표시될 수 있음
• 유니코드 이스케이프 시퀀스
  • \x31\x32를 유니코드로 작성한 형태
    • \u0031\u0032
• 유니코드 코드 포인트 이스케이프
  • \u{1f418} 과 같은 형태는 ES6에서 처음 제시
  • ES5에서 호환하기 위해 surrogate pair 사용
• Unicode Table 추천
• https://unicode-table.com/kr/

Array

• from()

  • 이터러블 오브젝트를 Array로 변환
    • Array-like 포함

• entries() : Array를 이터레이터 오브젝트로 생성하여 반환

  constvalues= [10, 20, 30];
  constiterator=values.entries();
  
  for (const [key, value] of iterator) {
      console.log(key, ": ", value);
  }

• find()

  • find()와 filter()는 모두 Array에서 특정 값을 찾는 메소드이지만 find는 값과 일치하는 것을 찾으면 찾기를 중단하지만, filter는 값과 일치하는 것을 찾은 후에도 배열 끝까지 찾음

  • 첫번째 인자는 콜백 함수

    • 실제 값의 비교는 콜백함수에서 수행하고 반환되는 값에 따라 find 메소드가 발견 여부를 판단
    • ES6 들어서면서 콜백함수의 활용도가 높아짐
    • Find 메소드 자체는 실제 작업을 콜백 함수에 위임

    result = [1, 2, 1].find(
    	function(value, index, all) {	// value는 현재 값, index는 현재 인덱스, all은 배열 전체 값return value ===1&& value ===this.key;
    	},
    	{key:1}
    );

정규표현식

• 플래그
  • u(unicode) : 매치 대상을 유니코드로 인식
  • y(sticky) : lastIndex 값을 설정
    • lastIndex는 기본값이 0이기 때문에 정규표현식의 패턴매칭을 0번 인덱스부터 시작함.
    • 만일 매치 시킬 문자열의 인덱스를 알고 있다면 lastIndex값을 설정해서 패턴 매칭할 위치를 지정할 수 있다.

Generator

• Generator function : function* 키워드를 사용한 함수

• Generator function을 호출하면 함수 블록을 실행하지 않고 Generator 오브젝트를 생성해서 반환

  • 오브젝트를 만드는 과정과 블록을 실행하는 부분을 나누어서 관리

• Generator function을 통해 반환된 오브젝트를 사용해서 함수 블록을 실행(next 메소드)

  • bind의 경우에도 이와같이 함수를 실행할 오브젝트를 반환해서 사용한다는 면에서 비슷

  constsports=function*(one, two) {	// Generator 함수 선언console.log("함수 블록");
      yield one + two;
  };
  
  constgenObj=sports(10, 20);  //이 때는 함수가 호출되지 않고 generator object가 반환됨constresult=genObj.next(); // next 메소드를 호출하여 함수 블록을 실행console.log(result);

• yield : 제너레이터 함수를 멈추거나 재실행

  function*genFunc1(one) {
      consttwo=yield one;
      constparam=yield two + one;
      yield param + one;
  };
  
  constgenObj=genFunc1(10);
  
  let result =genObj.next();
  console.log(result);
  
  result =genObj.next();
  console.log(result);
  
  result =genObj.next(20);
  console.log(result);
  
  function*genFunc2() {
      return10;
  }
  
  constgenObj2=genFunc2();
  result =genObj2.next();
  console.log(result);

  • yield 표현식 평가를 완료하면 {value: 값, done: true/false} 형태로 반환
    • yield가 정상적으로 수행되면 done 값은 false
    • next를 호출했을 때 더이상 수행할 yield가 없다면 done 값은 true

• next() : yield 또는 return을 만날 때까지 Generator Function 내용을 실행

  • Next 메소드를 수행하면 yield를 만날 때까지 함수 내용을 진행함
    • yield를 만나기 전에 return으로 반환 될 경우 함수처럼 값을 반환하여 {value: 값, done : true}가 됨
    • done이 true 이기 때문에 또 다시 next()를 호출하게되면 value는 undefined가 됨
  • Next 메소드에 인자를 전달하면 현재 수행 중인 yield 구문의 왼쪽 변수에 값이 할당됨
    • 위 예제에서 첫 yield를 수행한 후 next 인자로 20을 전달하면 two에 20이 할당됨
  • Generator 함수를 정의할 때는 yield를 항상 작성해주고, Generator 오브젝트에서 반환된 값에서 done을 체크하여 Generator 오브젝트 수행 완료를 판단

• return() : Generator 오브젝트의 iterator 수행을 종료

  • next를 수행하고 값을 반환한 것과 동일, 이 때 done 값은 true

• throw() : Generator 함수 내에서 Exception을 발생시킴 (마지막으로 수행한 yield 위치에서)

• yield* : 이터러블 오브젝트를 오른편에 선언할 경우 해당 이터러블 오브젝트를 수행

Class

• Function 오브젝트가 바탕
  • 별도로 class가 존재한다기 보다 function을 조금 더 객체지향적으로 사용할 수 있게끔 만들었다고 생각하면 좋을 듯
  • 객체 지향에서 사용하는 Syntax 추가
    • static, super
  • 자바스크립트의 객체지향은 C++이나 자바와 같은 기본적인 객체지향의 개념이라기 보다는 기존과 동일하게 prototype을 기반으로 한다.
    • 스펙의 Object 절 참고

class 선언문

window.onload=function() {
    classMember {
        getName() {
            return"이름";
        }
    }

    constobj=newMember();
    console.log(obj.getName());
};

• 기존에 생성자 역할을 하는 function을 정의한 경우 prototype을 정의하고 new 연산자로 인스턴스로 생성할 경우 __proto__ 프로퍼티 하위에 prototype에 정의한 것들을 할당하게 되는데 class를 사용할 경우 prototype 정의 없이 메소드 선언만 해도 엔진이 알아서 __proto__ 하위에 메소드를 할당한다.

• Member class의 내용을 확인해보면 function으로 정의한 것과 동일한 구조를 가진다.

  constMember=class {
  	getName() {
  		return"이름";
  	}
  }

  • Member:class

    • arguments:(...)

    • caller:(...)

    • length:0

    • name:"Member"

    • prototype:

      • constructor:class
      • getName:ƒ getName()
      • __proto__:Object

• Class도 function 정의와 동일하기 때문에 property에 메서드를 직접 접근해서 추가가 가능하다.

• prototype에 메소드를 추가하면 모든 인스턴스에서 공유한다.

• Class 정의는 Window 오브젝트에 설정되지 않는다. 즉, 글로벌 오브젝트에 포함되지 않는다.

constructor

• constructor를 작성하지 않으면 디폴트 constructor가 호출됨
• 빌트인 오브젝트를 반환하는 경우 이를 무시하고 Class의 오브젝트를 반환
• 빌트인 오브젝트 외 오브젝트를 반환할 경우 해당 오브젝트가 반환됨. (주의)

classMember {
    constructor(name) {
        this.name= name;
    }
}

• 기존에는 constructor가 prototype 하위에 가려져 있었는데, class 사용 시에는 밖으로 드러남

getter

classMember {
    getgetName() {
        return"이름";
    }
};

constobj=newMember();
// console.log(obj.getName());	// 오류 발생console.log(obj.getName);

• 메소드 선언 시 get 명시
• obj.getName()으로 호출하면 에러남
• obj.getName으로 호출해야함

setter

classMember {
    getgetName() {
        returnthis.name;
    }

    setsetName(param) {
        this.name= param;
    }
};

constobj=newMember();
obj.setName="이름변경";
console.log(obj.getName);

• Class 멤버 변수(프로퍼티) name을 선언하지 않더라도 존재하지 않으면 this.name으로 프로퍼티가 추가됨

상속

• ES5에서는 prototype에 Object.create를 사용하여 상속 받을 super 클래스를 할당하는 방식으로 상속

  Soccer.prototype=Object.create(Sports.prototype, { ...메소드 선언 생략 ... });
  Soccer.prototype.constructor= Soccer; // Object.create로 인해 constructor가 제거되기 때문에 다시 할당

• ES6에서는 extends 키워드로 상속 구현

  classsubClassextendssuperClass {}

• ES6 상속 예제

  classSports {
      constructor(member) {
          this.member= member;
      }
  
      setItem(item) {
          this.item= item;
      }
  }
  
  classSoccerextendsSports {
      setGround(ground) {
          this.ground= ground;
      }
  }
  
  constobj=newSoccer("박지성");
  obj.setItem("축구");
  obj.setGround("상암");
  console.log(obj.member);
  console.log(obj.item);
  console.log(obj.ground);

• 상속 구조

  • obj:Soccer
  • ground:"상암"
  • item:"축구"
  • member:"박지성"
  • __proto__:Sports
    • constructor:class Soccer
    • setGround:ƒ setGround(ground)
    • setItem:ƒ setItem(item)
    • __proto__:
      • constructor:class Sports
      • setItem:ƒ setItem(item)
      • __proto__:Object

• 같은 이름의 메소드가 존재하는 경우 상속 구조에서 Sub 클래스를 우선적으로 메소드를 찾음.

  • Soccer 클래스 > Sports 클래스 > Object 클래스

• super 키워드 사용 방법은 자바와 동일

• 빌트인 오브젝트 상속도 가능

• Object.setPrototypeOf를 사용해서 상속을 구현할 수 있음

  Object.setPrototypeOf(Soccer, Sports)

• ES6는 OOP 구현이 기반을 제공

• OOP는 설계가 필요

static

• class에 정적 메소드 선언

• prototype에 연결되지 않고 class에 직접 연결됨

• 인스턴스에서 접근이 불가능하고 Class 명을 통해서 접근

  classSports {
      staticgetItem() {
          return"sports";
      }
  }
  
  console.log(Sports.getItem());

• 코딩하다보니 인스턴스로 들어갈 메소드와 static 메소드의 구분이 어려워짐.

  • 문법적인 부분은 아님
  • 그래서 static 메소드만 모아 놓은 오브젝트를 따로 만들어서 사용하는 것도 괜찮은 방법인 듯

• static 메소드 내의 this는 해당 클래스를 나타냄

  • this로 변수에 접근하면 이는 인스턴스화되지 않는 클래스 내의 프로퍼티가 됨

hoisting

• class는 호이스팅이 되지 않음

• 즉, class 선언문보다 먼저 사용할 수 없음

• 메소드명에 변수를 사용할 수 있음

  • 대괄호로 표현

    classSports {
        static ["get"+Type]() {
            
        }
    }

DOM Interface 상속

classExtendsImageextendsImage {
    constructor() {
        super();
    }
    
    setProperty() {
        this.src="file/rainbow.jpg";
        this.alt="그림 설명";
        this.title="무지개";
    }
}

constobj=newExtendsImage();
obj.setProperty();
document.querySelector("body").appendChild(obj);

• DOM Interface를 상속받아 Custom 한 오브젝트를 만들 수 있음
• 복잡하게 DOM 코딩하지 말고, 이런 방식으로 컴포넌트화 하면 깔끔

들어가며

백엔드 개발자로 경력을 쌓아오던 중 그동안은 편의를 위한 간단한 운영툴 정도의 웹 개발만 해왔었기 때문에 jquery 외에는 다른 라이브러리들은 크게 고려하지 않고 개발을 진행해왔었다. 하지만 최근들어서는 서비스를 제공하기 위한 웹 개발을 하다보니 점차 기능도 많아지고 난이도 높은 개발들이 증가되고 있어서 프론트엔드 개발이 내 발목을 잡게 되었다. 자바스크립트에 대한 기본이 부족하고, 라이브러리 사용 경험 또한 적어서 공부의 필요성을 느끼고 강의도 다니며 자바스크립트 학습에 지속적으로 시간을 들이게 되었다.

프론트엔드 개발 중에 가장 고민되고 어려웠던 부분이 ajax를 사용하여 백엔드 서버와 데이터를 주고 받을 때 이 부분을 어떻게 하면 일관되게 처리하고, 버그가 발생하지 않도록 빈틈없이 처리를 할 수 있을까였다. 어떤 경우에는 동기식으로 서버의 처리 결과가 마무리 되는 것을 기다려야 할 때도 있었고, 비동기 식으로 프론트에서 주기적으로 상태를 체크해야하는 부분도 있었기 때문에 점차 로직이 복잡해지고 다양한 버그를 발생시켰다. 그러던 중 75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍을 알게 되었고, 여유 있을 때마다 카페에 와서 찬찬히 읽어보았다.

책을 읽으며

75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍 책을 읽으면서 이런 부분에서 매우 효과적으로 처리를 할 수 있겠다는 생각이 들었다. 하지만 곧바로 도입해서 사용하기에는 내용이 생각보다 많았고, 개념 또한 숙지해야할 부분들이 많아서 충분한 학습 시간이 필요할 것이라 생각이 들었다.

먼저 책에서 소개하는 RxJS는 ReactiveX 프로젝트에서 출발한 리액티브 프로그래밍을 지원하는 자바스크립트 라이브러리이다. 이를 이해하기 위해서는 리액티브 프로그래밍이라는 개념을 알아야하는데, 리액티브 프로그래밍은 비동기 프로그래밍 패러다임 중 하나이고, 자바스크립트에서 발생하는 이벤트를 비동기로 처리해서 변화에 유연하게 반응하는 것을 의미한다. 이 리액티브 프로그래밍은 자바스크립트에만 적용되는 것이 아니라 RxJava와 같이 다른 언어에서도 사용할 수 있는 프로그래밍 기법이라고 생각하면 좋을 것 같다. RxJS와 리액티브 프로그래밍에 대해서는 책의 도입부에서 자세하게 다루고 있으니 충분히 이해할 수 있을 것이라 생각된다.

책 제목처럼 각 개념들이 등장할 때마다 예제로써 독자들의 이해를 돕고 있다. 굉장히 자세하게 개념들을 하나씩 설명하고 있지만 개인적으로는 그림이 많이 포함되어 있었다면 이해가 더 쉽지 않았을까하는 아쉬운 마음이 들었다. 책을 읽어가며 글로는 잘 이해가 되지 않아 몇 번이나 다시 읽었던 적이 여러번이었기 때문이다. 그래도 여러번 읽고나면 이해에는 크게 무리가 없었다. 책 구성 또한 기본 이해부터 라이브러리의 각 요소들을 하나씩 풀어가며 설명하고 있기 때문에 읽는 재미가 있었다. 책의 주제가 RxJS이다 보니 RxJS에 대한 설명이 선행된 후 후반부에서 ES2015+에 대한 설명이 이어진다. 만약 ES2015+에 대한 기본 지식이 없는 경우에는 후반 부를 먼저 읽고 난 후에 앞부분을 읽는 다면 이해에 더 도움이 될 것이라 생각이 든다.

마치며

75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍 책은 비단 RxJS를 위한 것이 아니라 ES2015+에 대한 지식을 익히고 싶은 독자들에게도 충분히 도움이 될 것이라 생각한다. 나 또한 처음에는 RxJS라는 생소한 단어로 인해 뭔가 새로운 지식을 익혀야 한다는 부담감과 실무에 도입할 수 있을지에 대한 의구심 때문에 꺼려지는 부분이 있었는데 읽다보니 이는 라이브러리일 뿐이고 개발의 효율을 위해 얼마든지 도입할 수 있으며, 자바스크립트 기본과도 동떨어져 있지 않다는 것을 느꼈다. 이러한 이유로 자바스크립트를 사용하여 개발을 하고 있고, 실력 향상에 갈증을 느끼는 독자들이라면 꼭 한번 읽어볼만한 책이라고 생각한다.

Session 1. 올바른 데이터 시각화와 탐색적 부석 도구를 찾아서 

서버 관점에서의 데이터

• 무수히 많은 트랜잭션을 표현하는 좋은지표 찾기
  • 평균 응답시간에 주의
    • 평균 값은 노멀했지만 사실 특정 시점에 문제가 있었을 수 있다
    • 백분위도 정확하지 않은 것은 마찬가지
  • 수많은 APM이 분포도를 사용
• 운영 곤점에서는 수많은 서버들 중 어떤 서버에 지연이 발생했는지 파악하는 것에 관심
  • 서버간의 관계
  • 지연시간

블록체인에서의 데이터

• 블록을 일정 시간마다 예전것부터 차례차례 가져옴
• ETL을 위해 Fluentd로 데이터 수집해서 엘라스틱서치, RDB, 하둡에 저장
  • 엘라스틱스택은 굉장히 단순한 구조로 사용

돈 버는 시각화를 위한 데이터 플랫폼

• 흐름 따라 데이터를 파악하기에는 엘라스틱스택이 적합하지만 그룹핑이나 데이터를 여러 방면으로 조합해서 보기에는 적합하지 않은 듯
• 비정형/정형/반정형 데이터 상관없이 분석할 수 있는 플랫폼을 만드는 것이 목표
• 데이터를 수집하는 커넥터들이 무수히 많은데 모든 커넥터를 만들 수는 없음
  • 로그스태시, fluentd, filebeat 등등
• 실시간 데이터와 CRM데이터를 결합하기 위해서는 키 기반의 연관성이 필요
• 시각화
  • 차트, 대시보드를 그리는 것만 중요한 것이 아니라 사소한 UI, UX에도 신경 써야함
    • 기존의 기능들을 어떻게 쉽게 잘 쓰도록 할 수 있을까를 고민
  • 원천이 되는 데이터들에 대한 고려
    • 정말 필요한 지표인가?
      • 단순 UV가 아닌 어떠한 이유로 UV가 하락했는지를 판단하기 위해서는 더 많은 지표가 필요
  • 시각화된 차트가 나오기까지의 전처리/분석 고려
    • 전처리가 나을지 후처리가 나을지 분석 설계
    • 자유도와 정합성을 동시에 만족 시킬 수 있는가 (가장 어려움)
  • 시각화 구현 자체의 고려
    • 쿼리의 복잡도
    • 필터링
  • 모니터링과 EDA는 명확한 차이가 있음
    • 차이를 혼돈하지 않는 것이 중요
  • 시각화는 개발이 끝났다고 안주하면 안됨. 다른 시각에서, 다른 더 유용한 차트를 만들기 위해서 끊임 없이 노력해야 발전하고 돈을 벌 수 있음

패널토론

• 각 구축 단계에서 고민 또는 준비해야할 것들은?
  • 어떤 데이터를 어떻게 수집할지 정하는 것이 중요
  • 데이터간의 연관성
  • 필요한 데이터만 수집하기 위해 정형화
  • 전문가들이 고객에게 어떠한 뷰를 보여줄지를 먼저 계획하고 설계
    • 시각화 요소들을 결정 후 개발 가능 여부를 판단
    • APM의 경우 개발하는 사람들의 여러 패턴들을 모두 수용할 수 있는 어플리케이션을 만드는 것이 어려웠음
      • 개발자의 입장에서 생각했던 도구에서 운영자의 입장에서 생각하는 도구로 관점 전환 중
  • 도구를 선택할 때 특정 기능에 특화된 도구를 원하는지, 아니면 범용적인 도구를 원하는지를 잘 파악해야함
• 시각화 도구
  • 서버/데브옵스/운영자들간의 원하는 시각화 도구가 다름
    • 시각화 도구에 대한 리서치를 충분히 해야 분야별 대응이 가능
  • 기본 시작은 오픈소스로 할 수 있겠지만 오픈소스의 커뮤니티 성향이나 회사의 방향성에 따라 다르기 때문에 자신의 서비스와 맞지 않을 수 있음
    • 결국에는 오픈 소스 기반에서 자체 개발로 전환하게 됨
• 모델링이 먼저인가? 아니면 수집이 먼저인가?
• 모델링을 할 수 있는 인재가 있으면 탐다운 방식으로 진행하는 것이 베스트
• 인재가 없으면 일단 데이터를 수집하는 것이 중요
• 조직에서 의사결정을 내리는데 중요한 키워드나 지표들을 파악한 후에 조직에 필요한 데이터를 모델링
• 어떤 것을 모델링 해야할지 모를 때는 조직을 먼저 관찰하는 것이 좋을 듯

Session 2. 글쓰는 개발자

글쓰는 목적

• 내적 동기가 꾸준함을 만들기 떄문에
• 약간의 강제성이 발전에 도움이 됨
  • 독서 모임에서 독후감을 쓰도록 강제
• 슬럼프를 이겨내기 위해 일기 쓰기 시작
  • 평소 생각, 스쳐지나가는 이야기들
  • 감정, 느낀점 등
• 업무에서 글쓰기 능력이 많은 도움이 됨
  • 메일, 보고서 등

글쓰기와 코딩의 상관관계

• 글쓰기 능력이 수반되어야 코딩을 짤때도 깔끔하고 논리있게 작성할 수 있다.
• 다른 사람의 코드를 봤을 떄 그 사람의 스타일이나 성향을 파악할 수 있는 것 처럼 글의 문체나 글의 내용에 따라 그 사람의 인생이나 경험을 단편적으로나마 볼 수 있다.
  • 자신의 경험을 기술하는 측면에서 코딩과 글쓰기는 유사한 것 같다.

개발자와 블로그

• 강연자 : 우아한형제들 이동욱

• 티스토리 유료 스킨 사용 중

• 티스토리 댓글 너무 구림

  • 티스토리 댓글 API 이용해서 utterance 댓글로 마이그레이션

• 일일커밋

  • 코딩 + 글

마크다운 포스팅

• 티스토리 에디터 너무 구림
  • 생산성이 떨어짐
• markdown-tistory 제작
  • Jojoldu/markdown-tistory
• VSCode로 마크다운 파일로 제작 후 변환

글쓰기에서 책쓰기까지

• 강연자 : 유동환
• 블로그에 글쓰면서
  • 의식적인 글쓰기
  • 흥미로운 제목 만들기
  • 쉬운 글쓰기
  • 연말 회고

일기를 쓰는 이유

• 강연자 : 아이펀팩토리 이기곤
• 삶의 의미를 찾기 위한 목표
  • 삶을 스프린트 단위로 관리해보자
    • 일기 쓰기
• 일기
  • 직장 / 출퇴근시 / 개인적인 일을 일기로 쓰기

글쓰기가 어렵기만 한 개발자에게

• 강연자 : 트레바리 정원희
• 잘쓴 글
  • 문장이 유려하거나 멋진 것보다는 읽기 쉽고 이해가 잘되는 글
• 개발자도 글을 잘써야 한다고 생각
  • 코딩도 글
  • 궁극적으로 코드는 요구사항을 표현하는 언어 - 로버트 C 마틴
  • 글 잘쓰는 사람의 코드는 간결하고 논리정연
• 개발자도 글을 쓰며 일함
  • 커밋 메시지
  • 코드 리뷰
• 개발자도 글을 잘 쓸 수 있을까?
  • 개발자들은 간결하고 읽기 쉬운 코드를 고민한다.
    • 글도 읽기 쉬워야한다.
  • 리팩토링을 통해 코드를 다듬고 다듬는다.
    • 글도 마찬가지로 다듬는 작업을 반복
  • 다른 사람 코드를 유심히 읽으며 배운다.
    • 오픈소스나 동료 코드를 보며 배우려 노력한다.
    • 글쓰기도 다른 사람의 글쓰기에서 어휘나 단어 선택을 유심히 보고 배운다.
  • 상호 피드백을 통해 더 나은 코드가 된다는 사실을 안다
    • 코드 리뷰를 통해 서로의 코드에서 배운다.
    • 다른 직종보다 다른 사람이 피드백 주는 것에 거부감이 덜하다.
• 혼자 하면 오래 걸리고 힘듬
  • Github과 같은 지식 공유

개기자의 글쓰기

• 강연자 : 마이크로소프트웨어 오세용 기자
• 서평쓰기
• 블로그 운영
  • 칼럼 쓰기
    • 스타트업 창업하면서 느낀 것들
• 사색노트
  • 일기처럼 아무 생각이나 글로 표현
  • 글쓰기는 나를 보기 위함
  • 상세히 작성하다보면 원인을 발견하게 됨

Session3. SW 품질프로세스로 보는 SI 프로젝트의 기술부채

• 강연자 : 강희석
• 분석/설계의 부재 = 시간의 부재
  • 기획 단계에서 요구사항 분석을 자세히 해야 함
• SI에서도 최근 코드 품질에 관심이 높아짐
  • 컨벤션 체크 -> 코드 품질 검사 -> 눈으로 확인
• 개발 시작 단계가 가장 중요하다고 생각
  • 분석/설계 과정이 중요하기 때문에 3~4개월은 분석/설계 기간을 할당
  • 하지만 산출물 만들기에 급급해서 깊게 고민한 설계 문서가 아님
• 산출물의 의미를 잘 생각하자
  • 무언가를 이해하고 그려내고 서내려가는 과정에서의 고민의 결과
  • 보여주기 식의 의미없는 문서는 안됨
  • 그림으로 그려볼 수 있다는 것은 시스템에 대한 이해가 있다는 의미
• 기술 부채를 제거하기 위해 해야할 일
  • 분석 단계
    • 요구분석 단계에서 프로젝트 구성원들이 같이 읽어보고 고민하는 시간을 많이 갖기
    • 대화 많이 하기
    • 코드 품질 올리기
  • 설계 단계
    • 구현을 할 수 있는 묘사를 할 수 있어야 함
    • 화면 설계 -> 프로그램 설계 -> 데이터베이스 설계
  • 개발 단계
    • 진척률 관리의 맹점 확인
    • 모든 구성원이 프로젝트에 관심을 가져야함
    • 기획이 없어서 못했든 QA가 없어서 버그가 발생했든 모든 구성원의 협업이 이루어지지 않았기 때문에 발생한다고 생각
    • 개발 -> 테스트 -> 결함관리

Session4. 더 웨더 컴퍼니에서의 데브옵스

• 강연자 : 조지훈
  • chj2339@naver.com

일반적인 데브옵스

• 데브옵스 란
  • 개발 방법론은 아니라고 생각함
  • 개발 라이프사이클을 단축 시키는 것이 목표
  • 빨리 더 자주 고객들을 위해 서비스를 업데이트
  • 비즈니스 목표와 연관이 되어야함
• CAMS (데브옵스를 바라보는 관점)
  • Culture
    • 문화가 가장 중요하다고 생각
    • 사일로의 해체
      • 개발/테스트/기획 하는 조직이 명확하게 구분이 되어 있는 것을 타파하고자 하는 것이 데브옵스의 문화
      • 명확히 구분되어 있으면 커뮤니케이션이 단절됨
      • 문화적인 요소는 가장 관계가 크다고 생각
    • 리더십의 지원
      • 각 조직의 분리를 합하려면 리더십의 지원이 필요
    • 비즈니스 목표가 공통된 목표
    • 조직의 구조
  • Automation
    • 인프라에서 서비스까지 모든 것을 자동화
    • 라이프 사이클의 각 단계를 파이프라인화
    • 도구도 팀과 협업 문화가 기반이 된 상태여야 퍼포먼스를 낼 수 있음
    • 실수를 최소화
  • Measurement
    • 시스템 모니터링
    • 시스템 로그
    • 사용자의 피드백
    • 라이프 사이클 주기
  • Sharing
    • 지식과 경험의 공유
      • 공유가 잘 이루어지면 앞의 세가지 모두 개선될 확률이 높아짐
    • 자유로운 접근
    • 사일로의 탈피
    • 리더십의 지원

더 웨더 컴퍼니의 데브옵스

• 릴리즈 주기
  • 애자일 방식으로 개발 진행
    • 스프린트, 스크럽, 코드 리뷰
  • 2주 단위로 릴리즈 수행 (스프린트 단위)
    • 신규 API는 충분한 품질 점검 과정을 거쳐 릴리즈 수행
    • 개발팀 단위로 업무 시간 내 다운타임 없이 릴리즈 수행
• Culture
  • 데브옵스 엔지니어의 업무는 대부분 옵스에 해당
    • 옵스 업무를 자동화 하기 위해 개발
    • 데브옵스와 데브옵스 엔지니어는 개념이 다름
  • 팀 구성
    • 팀 리더 : 프로젝트 총괄
    • 세일즈 엔지니어링 : 고객 상대
    • 개발팀(애자일 스프린트 팀 - 6~8명으로 구성)
      • 프로덕트 오너 : 개발팀 총괄
        • 리드 디벨로퍼 : 스크럼 마스터
        • 디벨로퍼 : 3~4명
        • QA : 1 ~2명
        • DevOps Engineer : 1명
  • 커뮤니케이션
    • 슬랙
      • 언제든지 대화에 참여해서 함께 토론
      • 커뮤니케이션 비용이 낮아짐
      • 리모트 업무 특성상 시차가 발생하여 커뮤니케이션이 어려운데 히스토리가 남기 때문에 대화가 이어짐
      • 굉장히 중요한 역할 수행하고 있음
  • 리더십
    • 사일로간의 벽을 허무는데 중요한 역할자
    • 조직간 협업 지원
  • 작은 변화와 많은 릴리즈
    • 릴리즈 배포 주기를 짧게함
    • 롤백이 쉬움
• Automation
  • Terraform
  • Chef
  • Docker와 Kubernetes를 도입하게 되면 Terraform이나 Chef의 역할이 줄어들기 때문에 시스템 구성을 조정 할 필요가 있음
• Measurement
  • 모니터링
    • Datadog
  • 알람
    • pagerduty
• Sharing
  • 슬랙
    • 메신저
    • 화상회의
    • 자료공유
    • 히스토리
    • 주제별 채널
    • DataDog, PagerDuty등의 서비스 연계

Session5. 기술 부채의 늪 탈출기

• 강연자 : 허진수 럭스로보

• 이슈 관리

  • 컨플루언스
  • 지라

• 데일리 스탠드업 미팅

  • 오프라인에서 안하고 슬랙에서 미팅
  • 어제한일/오늘할일/불편한점

• 깃

  • 깃랩 사용
  • Git Flow 사용
    • 팀에 맞는 규칙으로 변형해서 사용
    • master/develop 브랜치는 언제든 릴리즈 될 수 있는 브랜치이기 때문에 엄격하게 관리
      • GitLab MR을 거쳐야만 머지
      • GitLab MR 요청 시에는 요청 내용에 대해 상세히 작성하도록 강제
      • 요청 내용이 명확해야 코드리뷰를 하는 사람이 편함
      • 진행 상황에 대해서는 커뮤니케이션을 줄이기 위해 이모티콘에 의미 부여해서 사용

• 코드 리뷰

  • 자질구레한 것들에 집중하는 것을 피해야함
  • 각 줄의 실수를 잡아내는 것이 아님
  • 전체적인 큰 그림 파악과 방향성 검토

• CI/CD

  • Jenkins
    • 코드 커밋이 발생하면 빌드 수행해서 오류가 없는지 파악
    • GitLab MR이 열리면 코드를 머지해서 오류가 없는지 파악
    • 태그를 붙여서 자동 릴리즈 수행 (tag-push)
    • Jenkins Pipeline 사용

Session1. Spinnaker on Kubernetes

• 해외에서 스피너커로 많이 발음
• Spinnaker
  • 넷플리에서 시작
  • 구글과 함께 오픈소스로 공개 후 관리
• 클라우드에서 Spinnaker
  • Inventory + Pipelines

핵심 기능

• Cluster

  • 쿠버네티스의 클러스터가 아닌 어플리케이션의 집합

• Deployment

  • 배포

• 멀티 클라우드

  • 대부분의 Public Cloud, Private Cloud 지원
    • 오픈스택은 V3 API 지원
  • 테라폼도 지원 예정

• 알림 기능

• 승인 기능

  • 관리자 판단 하에 수동으로 배포 진행할 수 있는 단계

• 딜리버리 영역의 대부분의 작업을 스피너커가 대신 해줌

• Chaos Monkey 오픈소스가 내장되어 있어서 카오스엔지니어링 지원

• 배포 전략

  • 블루/그린
  • 카나리
  • 롤링

커뮤니티

• Community.spinnaker.io가 활발

주요 마이크로서비스

• Clouddriver : 멀티 클라우드 관련
• Kayenta : 카나리 배포 분석 관련
  • 카나리 배포 시 배포 내용은 분석하는 것을 Spinnaker에서 제공
• Orca : 오케스트레이션 관련

CLI 도구

• Halyard
  • CLI 도구
  • kubectl과 같이 Spinnaker를 관리하기 위한 도구

Spinnaker on kubernetes

• Legacy(V1) 버전과 Maifest(V2) 버전이 지원됨
  • V1에서는 Spinnaker와 Kubernetes의 중복 용어들이 존재하여 혼란이 있었음
  • V2에서 개선
    • 파일로 형상 관리
    • 외부 저장소를 사용하여 관리 가능
    • 대부분 V2를 사용

젠킨스와 비교

• 젠킨스는 CI 도구
• Spinnaker는 클라우드 API를 직접 호출하기 떄문에 스크립팅 요소가 적음
• 빌드가 필요한 경우 Spinnaker에서 젠킨스를 호출해서 사용할 수 있음

Native 쿠버네티스와 비교

• 다양한 배포 전략
  • 승인 기능
  • 인프라 관리
  • 빠른 롤백 등
• Spinnaker를 관리해야하는 관리비용이 있음

파이프라인

• Stage : 워크플로우 단위
• 코드 커밋 -> docker hub에서 트리거 -> Spinnaker 웹 훅 -> 스테이징에 배포 -> QA 담당자가 테스트 후 승인 -> 라이브 배포
• 모니터링은 프로메테우스로

정리

• 단일 소스를 대상으로 신뢰성있는 배포를 위한 좋은 전략
• 실행에 대한 감사 기능
• 코드와 컨테이너 이미지 검증
• 베스트 전략 : Spinnaker + Jenkins + Packer + Helm + Terraform
• Redis에 성능저하가 발생하면 Spinnaker 전반적인 성능에 영향
  • 튜닝 포인트
• 모니터링에는 Datadog, Prometheus, Stackdriver
• 노드 로깅은 fluentd, ElasticStack
• 개발팀은 골든 이미지 생성, 운영팀이 Spinnaker를 통한 배포면 좋지 않을까

Session2. Chaos Engineering

클라우드 여정을 통해 배운 점

• 서비스 운영의 숙명 '장애'

  • 빨리 전파되고 늦게 복구 됨
  • 어디든 장애는 날 수 있음
  • 어떻게 빠르고 안전하게 복구 할 수 있는 가가 중요

• 많은 회사들의 장애 대응 히스토리 : github.com/danluu/post-mortems

• Jesse Robbins

  • 실제 서비스에서 장애가 발생하면 어떻게 복구가 되는가
  • 넷플릭스에서 2011년에 인프라를 위한 장애 대응 서비스 제안 - 카오스 몽키
    • 2008년에 데이터 센터 장애 발생 이후 클라우드로 이전 시작

• 넷플릭스의 마이크로서비스

  • ELB -> Zuul (API Gateway) -> 각 서비스로 전파
  • 마이크로서비스간 인터페이스 이슈 해결
    • Hystrix
      • Circuit Breaker
      • Fallback
      • 장애가 발생하면 조기에 Circuit Breaker가 차단하고 장애 확대를 방지
      • Circuit Breaker가 가동되면 미리 만들어진 응답 제공
    • Ribbon
      • Client Side Load Balancer
        • 서버의 부하 방지
    • Eureka
      • 서비스 디스커버리

Chaos Engineering 적용 방법

• 넷플릭스는 모든 인프라에 대한 실패를 가정하고 인프라를 운영
• 카오스 엔지니어링은 실제 서비스에 장애를 주입
  • 출시 전 테스트에서 드러나지 않은 아키텍처상의 문제를 직접 드러내는 것
• Chaos Monkey
  • 실제 서비스를 죽이면 어떤 현상이 발생할까를 테스트
• Chaos Gorilla
  • 가용 영역을 날려버리면 어떤 현상이 발생할까를 테스트
• Chaos Kong
  • 리전을 날려버리면 어떤현상이 발생할까를 테스트
• 장애 발생 방법
  • 애플리케이션 부하 테스트
  • …
• 카오스 엔지니어링의 목적은 문제를 만들려는 것은 아니고 문제를 해결하기 위한 것
• 넷플릭스에는 별도의 카오스팀이 존재
  • 카오스 엔지니어링에도 원칙이 있음
    • 폭발 반경 최소화 등
  • 책도 출간함
• 진행 과정
  • 정상 상태 : 실제 노말하게 운영되고 있는 상태
    • 노말하냐의 기준은 실제 비즈니스에서 산정되는 통계치를 기준으로 삼음
  • 가설 수립 : 장애가 나타날 수 있는 상황의 가설을 세움
  • 실험 디자인 : 어떤 시나리오로 테스트를 할 것인지를 계획하고 전파
    • 카나리 배포
  • 실험 결과 측정
    • 장애 감지 시간, 문제 인지 및 알림 시간, 사내 전파 시간, 자동 롤백 시작 시점, 복구되는 시간 등등
  • 문제점 수정
    • Post Mortems 및 오류 해결
• 전제 조건
  • 클라우드 환경
  • 마이크로서비스 환경
  • DevOps 문화

Kubernetes를 위한 카오스 도구

Kube Monkey

• Chaos Monkey와 의미가 동일
• Kube Monkey는 Kubernetes의 Pod들을 임의로 죽임
• Config 파일을 통해 전략을 설정
• Kube Monkey도 Kubernetes의 Deployment로 생성됨
• 데모
  • Redis Master/Slave 안정성 테스트
  • 운영 중인 Redis 클러스터를 Kube Monkey를 통해 주기적으로 랜덤하게 Terminate 시키는데 정상 운영이 되는 지를 확인

Istio

• 서비스메시 : 라이브러리 방식을 벗어나 경량 프록시로 비즈니스 로직과 내부 네트워크 분리
  • 서비스 구동 시 통신을 위한 Proxy를 함께 배포하고 서비스간 통신은 Proxy를 통해서만 수행 (사이드카)
    • Service Mesh Plane을 통해 Proxy 통신에 대한 데이터를 수집하고 관리
• Istio는 서비스 매시용 오픈소스
  • 마이크로 서비스의 서비스간 통신, 운영 및 배포 복잡성을 해결하기 위한 분산 서비스 관리 도구
    • 지능적 라우팅, 로드밸런싱
    • 언어 및 프레임워크 독립적인 복원성
• Proxy로 Envoy 오픈소스 사용
  • 다른 프록시를 사용해도 무관함
• 트래픽 관리
  • 서비스별로 로드 밸런싱 조절 가능
  • 트래픽 정책 설정으로 Circuit Breaker 역할 수행도 가능
  • Fault Injection 기능을 통해 카오스 엔지니어링
    • Timeout
    • HTTP Abort

그 외 오픈소스 도구

• Chaos Toolkit

• PowerfulSeal

• Gremlin

  • 카오스 엔지니어링 관련 가장 상품성 있는 제품을 만들고 있음

Session3. Kubernetes Calico

프로덕션에 필요한 요소

• 마스터
  • Calico
  • Etcd
    • Key-Value로 쿠버네티스의 모든 정보 저장
  • Kube-API
  • Kube-Scheduler
  • Kube-Controller
  • Kube-Proxy
  • kubelet
• 워커 노드
  • Calico
    • 쿠버네티스 네트워크 모듈
  • Nginx
    • Master 노드의 API와 밸런싱하게 통신하게 하기 위함
  • Kube-Proxy
  • Kubelet

쿠버네티스를 설치하는 방법

• kubespray

  • Ansible 기반
  • 사전 준비 작업 필요
    • swapoff
      • 네트워크가 안되거나 메모리가 부족하면 쿠버네티스는 관리할 수 없다고 판단하여 팟들을 죽임
      • 팟들이 갑자기 죽는 다면 노드 분산 필요
    • 패스워드 없이 sudo 권한을 사용 해야 한다던가, Ansible을 설치해야한다거나 등등
  • Ansible Inventory 파일을 샘플로 제공
    • 중요 파일
      • k8s-cluster.yml
        • 쿠버네티스에 관련된 설정 모음
      • etcd.yml
        • etcd는 메모리를 늘려놔야함 기본값이 적게 설정되어 있음
    • Inventory 내 그룹명들은 수정하면 안됨
  • Calico가 기본으로 설치됨
    • Mesh 형태로 구성
      • 따로 설정하지않으면 BGP 피어링을 기본으로 메시 구성
    • Mesh 구조는 노드가 50대 이내 일때만 사용 권장. 그 이후부터는 메시구조가 너무 복잡해짐
  • 관리용 Ansible playbook
    • cluster.yml
    • reset.yml
    • scale.yml
    • upgrade.yml

• CNI 선정 기준 중 하나는 네트워크 통신 방식

  • Calico는 iptables를 사용하는데 더 빠른 것을 원한다면 ipvs 기반의 CNI를 선택

• kubespray에 설정된 기본 설정 그대로 사용하는 것을 권장

  • 버전 정보 정도만 수정해서 사용

• local volume의 경우에는 파일시스템에 따라 생성 실패할 수도 있음 Pod 재생성하면 해결됨

Kubeadm vs kubespray

• kubeadm을 사용하면 각 노드마다 동일 설정 명령을 수행해야함
• 자동화를 위해서는 결국 Ansible을 사용해야하지 않을 까
• kubespray에서도 kubeadm 사용을 지원
  • 설정을 통해 쿠버네티스 설치 시 내부적으로 kubeadm을 사용

Tip

• kubespray 원본은 놔두고 동일 레벨에 사용자디렉토리 생성 후 참조할 yml 파일의 경로를 상대경로로 지정해서 사용
• 쿠버네티스 코드를 분석하고 중간에 로그를 삽입해서 디버깅 용도로 활용하고 있음
• CNI 플러그인을 체이닝 방식으로 여러가지를 연계해서 사용할 수는 있는데 굳이 써야하나 생각이 듬
  • Calico는 Network Policy 지정이 가능
  • 질문자 중에 Calico를 ipip 터널링을 위해 사용

Keyword

• BGP
• NAT outgoing
• ipipMode

SK 활용

• 오픈스택을 전부 컨테이너기반으로 전환

  • CI/CD
    • Jenkins, Rally/Tempest, Chaos Monkey
    • 마스터 노드에 Jenkins 마스터를 설치하고, 설정은 SAP에 안전하게 보관
    • Jenkins에서 Job을 실행하면 워커 노드에 Jenkins Slave가 생성되고 실행됨
  • OpenStack Container
    • Docker, Kolla

Session4. Serverless in K8S

• 서버리스란?
  • BaaS나 FaaS, 혹은 둘 다를 이용한 어플리케이션 아키텍처 설계 방법론
  • AWS의 대표적인 FaaS는 Lambda, BaaS는 S3, DynamoDB 등
• 사용자의 요청은 FaaS의 API Gateway를 거쳐 추상화된 Controller가 요청에 해당하는 Function을 실행하고, 필요 시 BaaS(내부 서비스나 데이터베이스)를 사용하여 응답을 사용자에게 반환

Serverless vs Serverless Functions vs FaaS

• Serverless는 사상
• Serverless Functions는 서버리스 사상으로 커스텀한 함수를 실행시킬 수 있도록 하는 것
• FaaS는 이러한 Serverless Functions를 각 클라우드 프로바이더가 각 환경에 적합한 서비스로 제공하는 것

MSA vs Serverless Functions

• 구분 짓기 애매
• MSA가 서비스 단위로 잘게 쪼갰다면 Serverless Functions는 더 잘게 쪼갬 (코드 조각)

서버리스 장점

• 저렴
• 서버 관리 불필요
• 확장성
• 작은 비즈니스에 유리
• 빠른 프로토타입

서버리스 단점

• 콜드 스타트
  • 첫 실행 시 컨테이너가 구동되는 시간이 필요
• Nano Service
  • 너무 잘개 쪼개져있어서 관리의 어려움
  • 안티패턴
• 서버리스도 서버가 있음
  • 사내에서 자체 구성하기 위해서는 서버리스 서비스를 제공하는 부서에서는 서버 관리가 필요
  • 클라우드 프로바이더가 제공하는 서비스는 서버 관리를 프로바이더에서 하기 때문에 서버리스라 할 수 있음

SK에서 활용

• Private FaaS를 위해 자체 구현
• 쿠버네티스 기반으로 구현
  • Fission 오픈소스
    • Serverless Functions Framework
    • CNCF에 등록된 오픈소스
    • 서버리스 출현이 근래이기 떄문에 대부분의 오픈소스가 인지도가 없었음
    • 콜드 부팅의 문제가 가장 적은 오픈소스를 선택
    • 함수를 생성/삭제/관리 할 수 있는 오픈소스
    • Fission Workflow 오픈소스
      • 너무 잘개 쪼개진 함수들의 관리가 어려운데 이를 묶어서 워크플로우를 생성해주는 프로젝트
  • Dispatch 오픈소스
    • 서버리스 프레임워크
    • Dispatch 위에 Fission이 올라가는 방식
• Private 할 필요가 없다면 퍼블릭 클라우드를 이용하는 것이 좋음
• 콜드 스타트 문제를 해결하기 위해 고생함
  • 프리웜을 수행하는 방식으로 해결
  • 요청 -> 런타임생성 -> 코드 설치 -> 의존성 설치 -> 함수 실행
  • Fission은 런타임생성까지 프리웜하는 것으로 콜드 스타트 개선
  • SK에서는 코드 설치까지 프리웜 진행
    • 코드 설치는 코드가 커밋되면 docker volume을 통해 실제 호스트에 동기화
  • 각 코드와 자원에 따른 컨테이너들을 미리 구동시켜놓고 재사용
    • 구동된 컨테이너는 콜드 스타트 문제 때문에 정해진 개수만큼은 풀로 관리
    • 함수 실행 요청이 끝나면 해당 함수에 대한 부분만 메모리에서 제거하는 방식으로 사용
    • 이전 코드로 인해 환경이 변경될 수 있는 위험 요소가 있음
      • 이를 위해 컨테이너를 재생성하는 전략이 필요
    • 사용자의 니즈에 따라 컨테이너 지속성이 필요한 경우를 선택적으로 할 수 있도록 함
      • 선택에 따라 주기적으로 컨테이너가 종료되거나 유지를 결정
    • Fission내에 이러한 재사용에 대한 설정을 위해 3가지 타입을 제공
• 사용자 코드에 따른 부하 관리
  • 사용자 코드에 부하를 줄만한 코드가 있는지 검사하는 것은 불가능
  • 이를 검증하기 위해 노드를 분리
    • 미리 정상 범위의 메트릭을 산정하고 이를 초과하는 컨테이너들을 별도 관리
  • Management Worker Node
    • nodeSelector 방식
      • Pod이 노드를 선택해서 들어감
  • Runtime Worker Node
    • Taint & tolerations 방식
    • 이 방식을 사용하여 부하 분산
• 부하 관리
  • Docker는 현재 상태 지표를 파일로 저장함
    • /sys/fs/cgroup
  • 파일의 정보를 기반으로 부하를 많이 먹고 있는 사용자의 컨테이너를 제한

Tip

• Helm의 업데이트 히스토리 관리가 어려워서 Helm은 Template를 생성하는 용도로만 사용하고 이를 통해 나온 yaml 파일을 kubectl apply 명령으로 실행
  • kubectl apply 명령은 히스토리 관리가 가능

Session5. Journey to Windows Kubernetes

• 쿠키워즈에서 게임서버는 리눅스, 운영 도구는 윈도우

Windows Kubernetes

• 기존의 쿠버네티스와 크게 다르지 않음
• 고성능의 IOCP를 사용할 수 있다는 장점
• 기존 레거시 시스템을 쿠버네티스 환경으로 전환하여 클러스터 관리를 편하게 할 수 있다는 장점
• 안정화까지는 다소 시간이 걸릴 것으로 예상 됨
  • Windows Server 2019에서 안정화 될 것으로 예상
• Windows Server VM 필요
• 설치과정이 네트워크 설정부터 각 종 raw level의 설정을 수동으로 했어야 했는데 Rancher를 사용하여 어느정도 자동화 가능
• Windows 10에서는 컨테이너 기술을 사용하려면 무조건 가상화 기술이 필요

HCS(Host Compute Service)

• 쿠버네티스는 Docker REST API로 컨테이너 관리
• Docker는 HCS와 HNS로 커뮤니케이션
• 윈도우에서 컨테이너를 구동한다는 것은 커널에 있는 HCS를 사용해서 구동한다는 것

HNS(Host Network Service)

• Windows에서 쿠버네티스를 사용할 때 팟마다 네트워크 인터페이스가 생성되어서 엄청나게 많은 네트워크가 생성되는 문제가 발생함
• 이러한 이슈를 해결하기 위해 한단계 상위의 네트워크를 구성하게 되었는데 이것이 HNS (잘 이해 못함)

그 외

• 윈도우 10과 윈도우 서버에서 구동되는 Docker는 다름
• Rancher를 사용하는 경우 CNI로 flannel을 권장.
  • linux와 windows가 다르게 구현되어 있음
• 컨테이너용 windows server os가 따로 있음
중첩 가상화를 사용할 수 있는 환경이 필요
• Azure : 3세대 VM 이상
• AWS: i3.baremetal 혹은 유사 인스턴스

들어가며

백엔드 개발을 주로 해오다가 최근에는 프론트엔드 개발까지 병행하게 되었다. 프론트엔드도 굉장히 빠르게 발전하고, 다양한 도구들이 등장하면서 복잡도가 많이 증가하게되었기 때문에 짧은 시간 내에 능숙하게 다루기란 정말 쉽지 않다. 백엔드 개발도 하면서 프론트엔드 공부와 개발을 병행하다보니 작은 기능 구현에도 굉장히 많은 시간이 소요되고, 결과물에서 많은 버그가 발생하였다. 이 과정에서 이러한 문제들을 해결하려면 어떻게 해야할지에 대해 고민을 많이 했고, 그 때마다 내린 결론은 기본기였다. 현재는 기본기가 부족하기 때문에 지속적으로 습득하고 있는 지식들을 그때 그때 적용하려다보니 코드의 일관성도 떨어지고, 혼자 개발했지만 갈수록 다양한 사람이 개발한 것 같은 모양새가 되고 있었다.

기본기를 위해 자바스크립트 강의도 듣고, 책도 여러권 구입해서 정독하면서 점차 익숙해지고 있었는데 또 다시 내 발목을 잡은 것은 HTML과 CSS 였다. 이론적인 부분은 쉽게 따라갈 수 있었지만 이 HTML과 CSS를 잘 조합해서 사용자에게 편리함을 제공하고, 일관된 화면을 제공하기 위한 UI, UX 적인 소질이 많이 떨어짐을 느꼈다.

그렇게 여러책을 찾아보게 되었고, "모두의 HTML5&CSS3 : 16일 만에 배우는 웹 사이트 제작 기초"를 읽게 되었다. 시중에 HTML과 CSS 각각의 주제만으로도 굉장한 두께의 책들을 쉽게 볼 수 있는데, 이 책은 그에 비해 부담없이 짧은 시간 내에 볼 수 있는 분량이었다. 두꺼운 책들을 시도했다가 여러번 완독에 실패했던 나로써는 이 부분이 매력적이었다.

책을 읽으며

이 책은 HTML과 CSS를 완전히 처음 접하는 독자들도 이해할 수 있도록 굉장히 쉽게 설명하고 있다. 저자분께서 독자들이 쉽게 이해할 수 있도록 다양한 비유를 들기도 하고, 컬러풀한 그림을 통해 시각적으로 보여주기도 하는 등의 노력을 여러 부분에서 느낄 수 있었다.

아쉬운 부분도 있었는데, 우선은 저자분께서 쉬운 이해를 위해 비유를 들어주는 것은 정말 좋았지만 개념적인 부분에서도 비유가 등장해서 오히려 혼란스러웠던 부분도 있었다. 예를 들면 태그의 특성을 혈액형을 비유로 든 부분이 있었는데, 같은 사람이라도 서로 다른 혈액형을 가지고 있는 것처럼 태그들도 그 태그만의 특성들이 있다는 의미로이해를 했다. 하지만 갑자기 태그의 혈액형이라는 것이 등장해서 정말로 있는 개념인건지, 태그의 style을 의미하는 건지, id를 의미하는 건지 아니면 여러 특성을 하나로 퉁쳐서 표현한 것인지 혼란스러운 부분이 있었다.

그리고 예제의 경우에는 완전히 기초적인 예제로 진행하다가 마지막에 갑자기 완성도 있는 프로젝트를 진행하게되어서 당황스러웠는데 각 챕터별로 배운 내용을 가지고 조금씩 프로젝트를 완성시켜보는 것도 좋았지 않았을까라는 생각이 들었다.

정리하며

책을 읽으면서 누구나 읽을 수 있는 책이지만 HTML과 CSS에 약간의 지식이 있는 독자들에게는 너무 쉽게 느껴져서 만족감이 떨어질 수도 있겠다는 생각이 들었다.

하지만 HTML과 CSS를 아예 모르지도 않고, 잘 알지도 않는 나로써는 이론을 정리하는데 많은 도움이 되었고, 읽어 갈 수록 기본기가 점점 탄탄해지는 것을 느낄 수 있었다. 쉬운 내용들은 빠르게 넘어가고 몰랐던 개념들은 찬찬히 보다보면 어느새 마지막 페이지에 와 있을 정도로 술술 읽히는 책이었다.

들어가며

해마다 IT 트렌드에 대한 도서들이 출간되는 것은 알고 있었지만 봐야할 필요성을 크게 느끼지 못하고 있었다. SNS나 IT 뉴스들을 통해 대략적인 IT 트렌드의 흐름은 인지하고 있었고, 책에 포함된 내용들이 크게 와닿는 부분들이 없었기 때문이었던 것 같다. 

2018년도는 급변하는 환경을 직접적으로 느끼고 트렌드에 대한 중요성을 너무나 느꼈기 때문에 더욱 관심이 생겼다. 그래서 마이크로소프트웨어도 정기 구독 신청하고, 관련 컨퍼런스에도 자주 참석하게 되었다. 

또한 이번에는 IT 트렌드에 대한 책도 한번 읽어보자는 생각이 들어서 읽기 시작하게 되었다.

책을 읽으며

책을 읽으며 작가의 필력에 감탄했었다. 나도 글쓰기를 자주 하는 편이기 때문에 이해하기 쉽게 잘 작성하는 것이 얼마나 힘들고 어려운지 잘 알고 있었는데, 어려울 수 있는 IT 기술 이야기를 이해하기 쉽고 재미있게 잘 작성하셔서 몰입하면서 읽을 수 있었다.

그 중에서도 가장 기억에 남았던 것은 5G에 대한 이야기였는데 벌써부터 광고에도 등장하고 있기 때문에 더욱 관심이 갔었던 것 같다. 내용을 읽으며 다가 올 현실을 자꾸만 상상하게 되고, 관련 내용을 더 공부하고 싶다는 욕구가 들기도 했다. 

산업이 발전하게되면 이로 인해 직장을 잃게 되는 사람도 많겠지만 새로운 사업이 창출되고, 이로 인해 실제로는 일자리가 더욱 늘어난다는 말에 생각해보니 최근에만 해도 VR과 AR이 등장하면서 관련 매장들도 늘어나고, 엄청나게 많은 사람들이 이 새로운 산업에 종사하고 있다는 것이 느껴져 신기하기도 하고 재미있었다.

책의 내용 중 머신러닝에 대한 이야기는 너무도 많이 들어왔고, 블록체인에 대한 부분은 요즘 화두가 되고 있기 때문에 궁금했었는데, 이 책으로 인해 어느 정도 궁금증이 해소 되었다. 블록체인 분야도 매우 전망이 있을 것이라는 생각이 들어서 공부해보고 싶기도 했다. 또한 각 장마다 포함된 기술 컬럼을 통해 전문 지식까지 습득할 수 있어서 좋았다.

정리

결론적으로 IT 트렌드 관련 책은 해마다 읽어봐야겠다는 생각이 들었다. 어렴풋이 알고 있던 주제들이 흐름을 알게 되고, 논리적으로 이해가 되면서 만족감을 크게 느꼈다. 

이런 내용들은 재미있게 읽었다가도 금방 잊어버리기 때문에 곁에 두고 주기적으로 훑어보는 것도 좋을 것 같다. 앞으로도 트렌드에 지속적으로 관심을 가지면서 뒤쳐지지 말고 다가올 미래에 대비해야겠다.

Number

• 자바스크립트는 IEEE 754에 정의된 double-precision floating-point format numbers로 숫자 표시

  • 변수 생성 시 타입 지정이 없는 자바스크립트는 엔진이 알아서 소수인지 정수인지 판단
  • 64비트 유동 소수점 형태로 수를 표시
    • RGB 표현의 경우에는 1바이트만으로도 충분하게 표현이 가능한데 64비트는 8바이트이기 때문에 7바이트가 낭비됨
      • 이를 방지위해 typed array가 등장함
      • 숫자 표현의 경우에는 typed array 사용 권장

• safe integer란

  • 지수(e)를 사용하지 않고 나타낼 수 있는 값까지만 표현
    • Number.MAX_SAFE_INTEGER
    • Number.MIN_SAFE_INTEGER
  • 2의 53승 보다 큰 값(Number.MAX_SAFE_INTEGER)의 경우 지수표현

• Number.EPSILON : 미세한 값 차이로 인해 일치되지 않을 때 사용

  • 예를 들어 0.1 + 0.2는 0.3이어야 하는데 실제 값은 0.30000000000000004가 되어서 0.1 + 0.2 === 0.3 이 false가 됨

• 8진수 표현시 ES5에서는 첫자리에 영문 o/O를 작성했었음. 다른 진수 표현(2진수의 경우 0b0101과 같이 표현)과 달라서 혼동되는 문제가 발생

  • ES6에서는 영문자 o/O 앞에 숫자 0 추가

• isNaN()

  • NaN === NaN의 결과가 false
    • NaN은 자바스크립트에서 값임 (숫자가 아니라는 것을 나타내는 값)
    • 값 비교인데 false가 반환되었기 때문에 논쟁이 있었음
  • 이 후 isNaN(), Number.isNaN(), Object.is(NaN, NaN) 이 출현함
    • isNaN()은 글로벌 오브젝트
      • Number에 의존하고 있는 기능을 글로벌 오브젝트에 포함시킨 것은 잘못된 것이라 생각
    • ES6에서 Number.isNaN()이 등장
      • Number에 포함되면서 제자리를 찾음
      • 사용 권장

• Tip

  빌트인 오브젝트에 내장된 타입들의 프로퍼티나 메소드에 대해서는 외우지말고 MDN 참조해서 필요한 것을 찾아 사용하자.
  - 각 함수 또는 메소드마다 사용 방법이나 반환 값이 미세하게 다를 수 있기 때문에 기억에 의존하지 말고, 정확히 확인해서 사용.
  

• isInteger()

  • 소수점 뒷자리가 0인 경우에도 정수로 판단
    • 1.0도 정수로 판단

• isSafeInteger() : 2의 53승 범위 내의 정수인지 확인

• isFinite() : 파라미터가 유한 값인지 확인

  • 처음에 글로벌 오브젝트에 포함됨
  • ES6에서 Number의 메소드로 포함됨
    • 글로벌 오브젝트와 결과가 다름
    • Number.isFinite() 사용 권장

Math

• Math.trunc() : 소수를 제외한 정수 반환

  • 양수이면 Math.floor()와 같음
  • 음수이면 Math.ceil()과 같음

• 32비트 계산 관련

  • 이전에 C++로 작성된 게임의 경우에는 32비트 정수를 사용하기 때문에 자바스크립트와 호환이 되지 않아서 웹에서 동작하기가 어려웠음
  • 웹 어셈블리를 통해 C++ 바이너리를 컨버팅 할 수 있게 되면서 일부 자바스크립트로 제어가 가능해짐
  • 이 때 32비트와 맞추기 위해 Math.clz32()와 Math.fround() 사용
  • Emscripten 참고

Unicode

• ES6에 유니코드 관련 프로퍼티와 메소드 추가
• 유니코드는 U+0031 형태로 표현
• 코드 포인트
  • 0031이 코드 포인트 또는 문자 코드로 알려져있음
  • 코드 포인트 값으로 문자/기호/이모지/아이콘 등 표현
  • 4자리 이상의 UTF-16 진수 형태
  • 110만개 이상 표현 가능
• plane : 코드 포인트 전체를 17개 평면(plane)으로 나눔
  • 하나의 plane은 65535개
  • 첫번째 plane을 BMP(Basic Multillingual Plane)
    • 일반적인 문자가 여기에 속함
• euc-kr은 사용하면 안됨.
  • 해외에서는 깨진 문자열로 표시될 수 있음
• 유니코드 이스케이프 시퀀스
  • \x31\x32를 유니코드로 작성한 형태
    • \u0031\u0032
• 유니코드 코드 포인트 이스케이프
  • \u{1f418} 과 같은 형태는 ES6에서 처음 제시
  • ES5에서 호환하기 위해 surrogate pair 사용
• Unicode Table 추천
• https://unicode-table.com/kr/

Array

• from()

  • 이터러블 오브젝트를 Array로 변환
    • Array-like 포함

• entries() : Array를 이터레이터 오브젝트로 생성하여 반환

  constvalues= [10, 20, 30];
  constiterator=values.entries();
  
  for (const [key, value] of iterator) {
      console.log(key, ": ", value);
  }

• find()

  • find()와 filter()는 모두 Array에서 특정 값을 찾는 메소드이지만 find는 값과 일치하는 것을 찾으면 찾기를 중단하지만, filter는 값과 일치하는 것을 찾은 후에도 배열 끝까지 찾음

  • 첫번째 인자는 콜백 함수

    • 실제 값의 비교는 콜백함수에서 수행하고 반환되는 값에 따라 find 메소드가 발견 여부를 판단
    • ES6 들어서면서 콜백함수의 활용도가 높아짐
    • Find 메소드 자체는 실제 작업을 콜백 함수에 위임

    result = [1, 2, 1].find(
    	function(value, index, all) {	// value는 현재 값, index는 현재 인덱스, all은 배열 전체 값return value ===1&& value ===this.key;
    	},
    	{key:1}
    );

정규표현식

• 플래그
  • u(unicode) : 매치 대상을 유니코드로 인식
  • y(sticky) : lastIndex 값을 설정
    • lastIndex는 기본값이 0이기 때문에 정규표현식의 패턴매칭을 0번 인덱스부터 시작함.
    • 만일 매치 시킬 문자열의 인덱스를 알고 있다면 lastIndex값을 설정해서 패턴 매칭할 위치를 지정할 수 있다.

Generator

• Generator function : function* 키워드를 사용한 함수

• Generator function을 호출하면 함수 블록을 실행하지 않고 Generator 오브젝트를 생성해서 반환

  • 오브젝트를 만드는 과정과 블록을 실행하는 부분을 나누어서 관리

• Generator function을 통해 반환된 오브젝트를 사용해서 함수 블록을 실행(next 메소드)

  • bind의 경우에도 이와같이 함수를 실행할 오브젝트를 반환해서 사용한다는 면에서 비슷

  constsports=function*(one, two) {	// Generator 함수 선언console.log("함수 블록");
      yield one + two;
  };
  
  constgenObj=sports(10, 20);  //이 때는 함수가 호출되지 않고 generator object가 반환됨constresult=genObj.next(); // next 메소드를 호출하여 함수 블록을 실행console.log(result);

• yield : 제너레이터 함수를 멈추거나 재실행

  function*genFunc1(one) {
      consttwo=yield one;
      constparam=yield two + one;
      yield param + one;
  };
  
  constgenObj=genFunc1(10);
  
  let result =genObj.next();
  console.log(result);
  
  result =genObj.next();
  console.log(result);
  
  result =genObj.next(20);
  console.log(result);
  
  function*genFunc2() {
      return10;
  }
  
  constgenObj2=genFunc2();
  result =genObj2.next();
  console.log(result);

  • yield 표현식 평가를 완료하면 {value: 값, done: true/false} 형태로 반환
    • yield가 정상적으로 수행되면 done 값은 false
    • next를 호출했을 때 더이상 수행할 yield가 없다면 done 값은 true

• next() : yield 또는 return을 만날 때까지 Generator Function 내용을 실행

  • Next 메소드를 수행하면 yield를 만날 때까지 함수 내용을 진행함
    • yield를 만나기 전에 return으로 반환 될 경우 함수처럼 값을 반환하여 {value: 값, done : true}가 됨
    • done이 true 이기 때문에 또 다시 next()를 호출하게되면 value는 undefined가 됨
  • Next 메소드에 인자를 전달하면 현재 수행 중인 yield 구문의 왼쪽 변수에 값이 할당됨
    • 위 예제에서 첫 yield를 수행한 후 next 인자로 20을 전달하면 two에 20이 할당됨
  • Generator 함수를 정의할 때는 yield를 항상 작성해주고, Generator 오브젝트에서 반환된 값에서 done을 체크하여 Generator 오브젝트 수행 완료를 판단

• return() : Generator 오브젝트의 iterator 수행을 종료

  • next를 수행하고 값을 반환한 것과 동일, 이 때 done 값은 true

• throw() : Generator 함수 내에서 Exception을 발생시킴 (마지막으로 수행한 yield 위치에서)

• yield* : 이터러블 오브젝트를 오른편에 선언할 경우 해당 이터러블 오브젝트를 수행

Class

• Function 오브젝트가 바탕
  • 별도로 class가 존재한다기 보다 function을 조금 더 객체지향적으로 사용할 수 있게끔 만들었다고 생각하면 좋을 듯
  • 객체 지향에서 사용하는 Syntax 추가
    • static, super
  • 자바스크립트의 객체지향은 C++이나 자바와 같은 기본적인 객체지향의 개념이라기 보다는 기존과 동일하게 prototype을 기반으로 한다.
    • 스펙의 Object 절 참고

class 선언문

window.onload=function() {
    classMember {
        getName() {
            return"이름";
        }
    }

    constobj=newMember();
    console.log(obj.getName());
};

• 기존에 생성자 역할을 하는 function을 정의한 경우 prototype을 정의하고 new 연산자로 인스턴스로 생성할 경우 __proto__ 프로퍼티 하위에 prototype에 정의한 것들을 할당하게 되는데 class를 사용할 경우 prototype 정의 없이 메소드 선언만 해도 엔진이 알아서 __proto__ 하위에 메소드를 할당한다.

• Member class의 내용을 확인해보면 function으로 정의한 것과 동일한 구조를 가진다.

  constMember=class {
  	getName() {
  		return"이름";
  	}
  }

  • Member:class

    • arguments:(...)

    • caller:(...)

    • length:0

    • name:"Member"

    • prototype:

      • constructor:class
      • getName:ƒ getName()
      • __proto__:Object

• Class도 function 정의와 동일하기 때문에 property에 메서드를 직접 접근해서 추가가 가능하다.

• prototype에 메소드를 추가하면 모든 인스턴스에서 공유한다.

• Class 정의는 Window 오브젝트에 설정되지 않는다. 즉, 글로벌 오브젝트에 포함되지 않는다.

constructor

• constructor를 작성하지 않으면 디폴트 constructor가 호출됨
• 빌트인 오브젝트를 반환하는 경우 이를 무시하고 Class의 오브젝트를 반환
• 빌트인 오브젝트 외 오브젝트를 반환할 경우 해당 오브젝트가 반환됨. (주의)

classMember {
    constructor(name) {
        this.name= name;
    }
}

• 기존에는 constructor가 prototype 하위에 가려져 있었는데, class 사용 시에는 밖으로 드러남

getter

classMember {
    getgetName() {
        return"이름";
    }
};

constobj=newMember();
// console.log(obj.getName());	// 오류 발생console.log(obj.getName);

• 메소드 선언 시 get 명시
• obj.getName()으로 호출하면 에러남
• obj.getName으로 호출해야함

setter

classMember {
    getgetName() {
        returnthis.name;
    }

    setsetName(param) {
        this.name= param;
    }
};

constobj=newMember();
obj.setName="이름변경";
console.log(obj.getName);

• Class 멤버 변수(프로퍼티) name을 선언하지 않더라도 존재하지 않으면 this.name으로 프로퍼티가 추가됨

상속

• ES5에서는 prototype에 Object.create를 사용하여 상속 받을 super 클래스를 할당하는 방식으로 상속

  Soccer.prototype=Object.create(Sports.prototype, { ...메소드 선언 생략 ... });
  Soccer.prototype.constructor= Soccer; // Object.create로 인해 constructor가 제거되기 때문에 다시 할당

• ES6에서는 extends 키워드로 상속 구현

  classsubClassextendssuperClass {}

• ES6 상속 예제

  classSports {
      constructor(member) {
          this.member= member;
      }
  
      setItem(item) {
          this.item= item;
      }
  }
  
  classSoccerextendsSports {
      setGround(ground) {
          this.ground= ground;
      }
  }
  
  constobj=newSoccer("박지성");
  obj.setItem("축구");
  obj.setGround("상암");
  console.log(obj.member);
  console.log(obj.item);
  console.log(obj.ground);

• 상속 구조

  • obj:Soccer
  • ground:"상암"
  • item:"축구"
  • member:"박지성"
  • __proto__:Sports
    • constructor:class Soccer
    • setGround:ƒ setGround(ground)
    • setItem:ƒ setItem(item)
    • __proto__:
      • constructor:class Sports
      • setItem:ƒ setItem(item)
      • __proto__:Object

• 같은 이름의 메소드가 존재하는 경우 상속 구조에서 Sub 클래스를 우선적으로 메소드를 찾음.

  • Soccer 클래스 > Sports 클래스 > Object 클래스

• super 키워드 사용 방법은 자바와 동일

• 빌트인 오브젝트 상속도 가능

• Object.setPrototypeOf를 사용해서 상속을 구현할 수 있음

  Object.setPrototypeOf(Soccer, Sports)

• ES6는 OOP 구현이 기반을 제공

• OOP는 설계가 필요

static

• class에 정적 메소드 선언

• prototype에 연결되지 않고 class에 직접 연결됨

• 인스턴스에서 접근이 불가능하고 Class 명을 통해서 접근

  classSports {
      staticgetItem() {
          return"sports";
      }
  }
  
  console.log(Sports.getItem());

• 코딩하다보니 인스턴스로 들어갈 메소드와 static 메소드의 구분이 어려워짐.

  • 문법적인 부분은 아님
  • 그래서 static 메소드만 모아 놓은 오브젝트를 따로 만들어서 사용하는 것도 괜찮은 방법인 듯

• static 메소드 내의 this는 해당 클래스를 나타냄

  • this로 변수에 접근하면 이는 인스턴스화되지 않는 클래스 내의 프로퍼티가 됨

hoisting

• class는 호이스팅이 되지 않음

• 즉, class 선언문보다 먼저 사용할 수 없음

• 메소드명에 변수를 사용할 수 있음

  • 대괄호로 표현

    classSports {
        static ["get"+Type]() {
            
        }
    }

DOM Interface 상속

classExtendsImageextendsImage {
    constructor() {
        super();
    }
    
    setProperty() {
        this.src="file/rainbow.jpg";
        this.alt="그림 설명";
        this.title="무지개";
    }
}

constobj=newExtendsImage();
obj.setProperty();
document.querySelector("body").appendChild(obj);

• DOM Interface를 상속받아 Custom 한 오브젝트를 만들 수 있음
• 복잡하게 DOM 코딩하지 말고, 이런 방식으로 컴포넌트화 하면 깔끔

들어가며

백엔드 개발자로 경력을 쌓아오던 중 그동안은 편의를 위한 간단한 운영툴 정도의 웹 개발만 해왔었기 때문에 jquery 외에는 다른 라이브러리들은 크게 고려하지 않고 개발을 진행해왔었다. 하지만 최근들어서는 서비스를 제공하기 위한 웹 개발을 하다보니 점차 기능도 많아지고 난이도 높은 개발들이 증가되고 있어서 프론트엔드 개발이 내 발목을 잡게 되었다. 자바스크립트에 대한 기본이 부족하고, 라이브러리 사용 경험 또한 적어서 공부의 필요성을 느끼고 강의도 다니며 자바스크립트 학습에 지속적으로 시간을 들이게 되었다.

프론트엔드 개발 중에 가장 고민되고 어려웠던 부분이 ajax를 사용하여 백엔드 서버와 데이터를 주고 받을 때 이 부분을 어떻게 하면 일관되게 처리하고, 버그가 발생하지 않도록 빈틈없이 처리를 할 수 있을까였다. 어떤 경우에는 동기식으로 서버의 처리 결과가 마무리 되는 것을 기다려야 할 때도 있었고, 비동기 식으로 프론트에서 주기적으로 상태를 체크해야하는 부분도 있었기 때문에 점차 로직이 복잡해지고 다양한 버그를 발생시켰다. 그러던 중 75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍을 알게 되었고, 여유 있을 때마다 카페에 와서 찬찬히 읽어보았다.

책을 읽으며

75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍 책을 읽으면서 이런 부분에서 매우 효과적으로 처리를 할 수 있겠다는 생각이 들었다. 하지만 곧바로 도입해서 사용하기에는 내용이 생각보다 많았고, 개념 또한 숙지해야할 부분들이 많아서 충분한 학습 시간이 필요할 것이라 생각이 들었다.

먼저 책에서 소개하는 RxJS는 ReactiveX 프로젝트에서 출발한 리액티브 프로그래밍을 지원하는 자바스크립트 라이브러리이다. 이를 이해하기 위해서는 리액티브 프로그래밍이라는 개념을 알아야하는데, 리액티브 프로그래밍은 비동기 프로그래밍 패러다임 중 하나이고, 자바스크립트에서 발생하는 이벤트를 비동기로 처리해서 변화에 유연하게 반응하는 것을 의미한다. 이 리액티브 프로그래밍은 자바스크립트에만 적용되는 것이 아니라 RxJava와 같이 다른 언어에서도 사용할 수 있는 프로그래밍 기법이라고 생각하면 좋을 것 같다. RxJS와 리액티브 프로그래밍에 대해서는 책의 도입부에서 자세하게 다루고 있으니 충분히 이해할 수 있을 것이라 생각된다.

책 제목처럼 각 개념들이 등장할 때마다 예제로써 독자들의 이해를 돕고 있다. 굉장히 자세하게 개념들을 하나씩 설명하고 있지만 개인적으로는 그림이 많이 포함되어 있었다면 이해가 더 쉽지 않았을까하는 아쉬운 마음이 들었다. 책을 읽어가며 글로는 잘 이해가 되지 않아 몇 번이나 다시 읽었던 적이 여러번이었기 때문이다. 그래도 여러번 읽고나면 이해에는 크게 무리가 없었다. 책 구성 또한 기본 이해부터 라이브러리의 각 요소들을 하나씩 풀어가며 설명하고 있기 때문에 읽는 재미가 있었다. 책의 주제가 RxJS이다 보니 RxJS에 대한 설명이 선행된 후 후반부에서 ES2015+에 대한 설명이 이어진다. 만약 ES2015+에 대한 기본 지식이 없는 경우에는 후반 부를 먼저 읽고 난 후에 앞부분을 읽는 다면 이해에 더 도움이 될 것이라 생각이 든다.

마치며

75가지 핵심 문법과 예제로 익히는 RxJS 기초 RX JS 프로그래밍 책은 비단 RxJS를 위한 것이 아니라 ES2015+에 대한 지식을 익히고 싶은 독자들에게도 충분히 도움이 될 것이라 생각한다. 나 또한 처음에는 RxJS라는 생소한 단어로 인해 뭔가 새로운 지식을 익혀야 한다는 부담감과 실무에 도입할 수 있을지에 대한 의구심 때문에 꺼려지는 부분이 있었는데 읽다보니 이는 라이브러리일 뿐이고 개발의 효율을 위해 얼마든지 도입할 수 있으며, 자바스크립트 기본과도 동떨어져 있지 않다는 것을 느꼈다. 이러한 이유로 자바스크립트를 사용하여 개발을 하고 있고, 실력 향상에 갈증을 느끼는 독자들이라면 꼭 한번 읽어볼만한 책이라고 생각한다.

Session 1. 올바른 데이터 시각화와 탐색적 부석 도구를 찾아서 

서버 관점에서의 데이터

• 무수히 많은 트랜잭션을 표현하는 좋은지표 찾기
  • 평균 응답시간에 주의
    • 평균 값은 노멀했지만 사실 특정 시점에 문제가 있었을 수 있다
    • 백분위도 정확하지 않은 것은 마찬가지
  • 수많은 APM이 분포도를 사용
• 운영 곤점에서는 수많은 서버들 중 어떤 서버에 지연이 발생했는지 파악하는 것에 관심
  • 서버간의 관계
  • 지연시간

블록체인에서의 데이터

• 블록을 일정 시간마다 예전것부터 차례차례 가져옴
• ETL을 위해 Fluentd로 데이터 수집해서 엘라스틱서치, RDB, 하둡에 저장
  • 엘라스틱스택은 굉장히 단순한 구조로 사용

돈 버는 시각화를 위한 데이터 플랫폼

• 흐름 따라 데이터를 파악하기에는 엘라스틱스택이 적합하지만 그룹핑이나 데이터를 여러 방면으로 조합해서 보기에는 적합하지 않은 듯
• 비정형/정형/반정형 데이터 상관없이 분석할 수 있는 플랫폼을 만드는 것이 목표
• 데이터를 수집하는 커넥터들이 무수히 많은데 모든 커넥터를 만들 수는 없음
  • 로그스태시, fluentd, filebeat 등등
• 실시간 데이터와 CRM데이터를 결합하기 위해서는 키 기반의 연관성이 필요
• 시각화
  • 차트, 대시보드를 그리는 것만 중요한 것이 아니라 사소한 UI, UX에도 신경 써야함
    • 기존의 기능들을 어떻게 쉽게 잘 쓰도록 할 수 있을까를 고민
  • 원천이 되는 데이터들에 대한 고려
    • 정말 필요한 지표인가?
      • 단순 UV가 아닌 어떠한 이유로 UV가 하락했는지를 판단하기 위해서는 더 많은 지표가 필요
  • 시각화된 차트가 나오기까지의 전처리/분석 고려
    • 전처리가 나을지 후처리가 나을지 분석 설계
    • 자유도와 정합성을 동시에 만족 시킬 수 있는가 (가장 어려움)
  • 시각화 구현 자체의 고려
    • 쿼리의 복잡도
    • 필터링
  • 모니터링과 EDA는 명확한 차이가 있음
    • 차이를 혼돈하지 않는 것이 중요
  • 시각화는 개발이 끝났다고 안주하면 안됨. 다른 시각에서, 다른 더 유용한 차트를 만들기 위해서 끊임 없이 노력해야 발전하고 돈을 벌 수 있음

패널토론

• 각 구축 단계에서 고민 또는 준비해야할 것들은?
  • 어떤 데이터를 어떻게 수집할지 정하는 것이 중요
  • 데이터간의 연관성
  • 필요한 데이터만 수집하기 위해 정형화
  • 전문가들이 고객에게 어떠한 뷰를 보여줄지를 먼저 계획하고 설계
    • 시각화 요소들을 결정 후 개발 가능 여부를 판단
    • APM의 경우 개발하는 사람들의 여러 패턴들을 모두 수용할 수 있는 어플리케이션을 만드는 것이 어려웠음
      • 개발자의 입장에서 생각했던 도구에서 운영자의 입장에서 생각하는 도구로 관점 전환 중
  • 도구를 선택할 때 특정 기능에 특화된 도구를 원하는지, 아니면 범용적인 도구를 원하는지를 잘 파악해야함
• 시각화 도구
  • 서버/데브옵스/운영자들간의 원하는 시각화 도구가 다름
    • 시각화 도구에 대한 리서치를 충분히 해야 분야별 대응이 가능
  • 기본 시작은 오픈소스로 할 수 있겠지만 오픈소스의 커뮤니티 성향이나 회사의 방향성에 따라 다르기 때문에 자신의 서비스와 맞지 않을 수 있음
    • 결국에는 오픈 소스 기반에서 자체 개발로 전환하게 됨
• 모델링이 먼저인가? 아니면 수집이 먼저인가?
• 모델링을 할 수 있는 인재가 있으면 탐다운 방식으로 진행하는 것이 베스트
• 인재가 없으면 일단 데이터를 수집하는 것이 중요
• 조직에서 의사결정을 내리는데 중요한 키워드나 지표들을 파악한 후에 조직에 필요한 데이터를 모델링
• 어떤 것을 모델링 해야할지 모를 때는 조직을 먼저 관찰하는 것이 좋을 듯

Session 2. 글쓰는 개발자

글쓰는 목적

• 내적 동기가 꾸준함을 만들기 떄문에
• 약간의 강제성이 발전에 도움이 됨
  • 독서 모임에서 독후감을 쓰도록 강제
• 슬럼프를 이겨내기 위해 일기 쓰기 시작
  • 평소 생각, 스쳐지나가는 이야기들
  • 감정, 느낀점 등
• 업무에서 글쓰기 능력이 많은 도움이 됨
  • 메일, 보고서 등

글쓰기와 코딩의 상관관계

• 글쓰기 능력이 수반되어야 코딩을 짤때도 깔끔하고 논리있게 작성할 수 있다.
• 다른 사람의 코드를 봤을 떄 그 사람의 스타일이나 성향을 파악할 수 있는 것 처럼 글의 문체나 글의 내용에 따라 그 사람의 인생이나 경험을 단편적으로나마 볼 수 있다.
  • 자신의 경험을 기술하는 측면에서 코딩과 글쓰기는 유사한 것 같다.

개발자와 블로그

• 강연자 : 우아한형제들 이동욱

• 티스토리 유료 스킨 사용 중

• 티스토리 댓글 너무 구림

  • 티스토리 댓글 API 이용해서 utterance 댓글로 마이그레이션

• 일일커밋

  • 코딩 + 글

마크다운 포스팅

• 티스토리 에디터 너무 구림
  • 생산성이 떨어짐
• markdown-tistory 제작
  • Jojoldu/markdown-tistory
• VSCode로 마크다운 파일로 제작 후 변환

글쓰기에서 책쓰기까지

• 강연자 : 유동환
• 블로그에 글쓰면서
  • 의식적인 글쓰기
  • 흥미로운 제목 만들기
  • 쉬운 글쓰기
  • 연말 회고

일기를 쓰는 이유

• 강연자 : 아이펀팩토리 이기곤
• 삶의 의미를 찾기 위한 목표
  • 삶을 스프린트 단위로 관리해보자
    • 일기 쓰기
• 일기
  • 직장 / 출퇴근시 / 개인적인 일을 일기로 쓰기

글쓰기가 어렵기만 한 개발자에게

• 강연자 : 트레바리 정원희
• 잘쓴 글
  • 문장이 유려하거나 멋진 것보다는 읽기 쉽고 이해가 잘되는 글
• 개발자도 글을 잘써야 한다고 생각
  • 코딩도 글
  • 궁극적으로 코드는 요구사항을 표현하는 언어 - 로버트 C 마틴
  • 글 잘쓰는 사람의 코드는 간결하고 논리정연
• 개발자도 글을 쓰며 일함
  • 커밋 메시지
  • 코드 리뷰
• 개발자도 글을 잘 쓸 수 있을까?
  • 개발자들은 간결하고 읽기 쉬운 코드를 고민한다.
    • 글도 읽기 쉬워야한다.
  • 리팩토링을 통해 코드를 다듬고 다듬는다.
    • 글도 마찬가지로 다듬는 작업을 반복
  • 다른 사람 코드를 유심히 읽으며 배운다.
    • 오픈소스나 동료 코드를 보며 배우려 노력한다.
    • 글쓰기도 다른 사람의 글쓰기에서 어휘나 단어 선택을 유심히 보고 배운다.
  • 상호 피드백을 통해 더 나은 코드가 된다는 사실을 안다
    • 코드 리뷰를 통해 서로의 코드에서 배운다.
    • 다른 직종보다 다른 사람이 피드백 주는 것에 거부감이 덜하다.
• 혼자 하면 오래 걸리고 힘듬
  • Github과 같은 지식 공유

개기자의 글쓰기

• 강연자 : 마이크로소프트웨어 오세용 기자
• 서평쓰기
• 블로그 운영
  • 칼럼 쓰기
    • 스타트업 창업하면서 느낀 것들
• 사색노트
  • 일기처럼 아무 생각이나 글로 표현
  • 글쓰기는 나를 보기 위함
  • 상세히 작성하다보면 원인을 발견하게 됨

Session3. SW 품질프로세스로 보는 SI 프로젝트의 기술부채

• 강연자 : 강희석
• 분석/설계의 부재 = 시간의 부재
  • 기획 단계에서 요구사항 분석을 자세히 해야 함
• SI에서도 최근 코드 품질에 관심이 높아짐
  • 컨벤션 체크 -> 코드 품질 검사 -> 눈으로 확인
• 개발 시작 단계가 가장 중요하다고 생각
  • 분석/설계 과정이 중요하기 때문에 3~4개월은 분석/설계 기간을 할당
  • 하지만 산출물 만들기에 급급해서 깊게 고민한 설계 문서가 아님
• 산출물의 의미를 잘 생각하자
  • 무언가를 이해하고 그려내고 서내려가는 과정에서의 고민의 결과
  • 보여주기 식의 의미없는 문서는 안됨
  • 그림으로 그려볼 수 있다는 것은 시스템에 대한 이해가 있다는 의미
• 기술 부채를 제거하기 위해 해야할 일
  • 분석 단계
    • 요구분석 단계에서 프로젝트 구성원들이 같이 읽어보고 고민하는 시간을 많이 갖기
    • 대화 많이 하기
    • 코드 품질 올리기
  • 설계 단계
    • 구현을 할 수 있는 묘사를 할 수 있어야 함
    • 화면 설계 -> 프로그램 설계 -> 데이터베이스 설계
  • 개발 단계
    • 진척률 관리의 맹점 확인
    • 모든 구성원이 프로젝트에 관심을 가져야함
    • 기획이 없어서 못했든 QA가 없어서 버그가 발생했든 모든 구성원의 협업이 이루어지지 않았기 때문에 발생한다고 생각
    • 개발 -> 테스트 -> 결함관리

Session4. 더 웨더 컴퍼니에서의 데브옵스

• 강연자 : 조지훈
  • chj2339@naver.com

일반적인 데브옵스

• 데브옵스 란
  • 개발 방법론은 아니라고 생각함
  • 개발 라이프사이클을 단축 시키는 것이 목표
  • 빨리 더 자주 고객들을 위해 서비스를 업데이트
  • 비즈니스 목표와 연관이 되어야함
• CAMS (데브옵스를 바라보는 관점)
  • Culture
    • 문화가 가장 중요하다고 생각
    • 사일로의 해체
      • 개발/테스트/기획 하는 조직이 명확하게 구분이 되어 있는 것을 타파하고자 하는 것이 데브옵스의 문화
      • 명확히 구분되어 있으면 커뮤니케이션이 단절됨
      • 문화적인 요소는 가장 관계가 크다고 생각
    • 리더십의 지원
      • 각 조직의 분리를 합하려면 리더십의 지원이 필요
    • 비즈니스 목표가 공통된 목표
    • 조직의 구조
  • Automation
    • 인프라에서 서비스까지 모든 것을 자동화
    • 라이프 사이클의 각 단계를 파이프라인화
    • 도구도 팀과 협업 문화가 기반이 된 상태여야 퍼포먼스를 낼 수 있음
    • 실수를 최소화
  • Measurement
    • 시스템 모니터링
    • 시스템 로그
    • 사용자의 피드백
    • 라이프 사이클 주기
  • Sharing
    • 지식과 경험의 공유
      • 공유가 잘 이루어지면 앞의 세가지 모두 개선될 확률이 높아짐
    • 자유로운 접근
    • 사일로의 탈피
    • 리더십의 지원

더 웨더 컴퍼니의 데브옵스

• 릴리즈 주기
  • 애자일 방식으로 개발 진행
    • 스프린트, 스크럽, 코드 리뷰
  • 2주 단위로 릴리즈 수행 (스프린트 단위)
    • 신규 API는 충분한 품질 점검 과정을 거쳐 릴리즈 수행
    • 개발팀 단위로 업무 시간 내 다운타임 없이 릴리즈 수행
• Culture
  • 데브옵스 엔지니어의 업무는 대부분 옵스에 해당
    • 옵스 업무를 자동화 하기 위해 개발
    • 데브옵스와 데브옵스 엔지니어는 개념이 다름
  • 팀 구성
    • 팀 리더 : 프로젝트 총괄
    • 세일즈 엔지니어링 : 고객 상대
    • 개발팀(애자일 스프린트 팀 - 6~8명으로 구성)
      • 프로덕트 오너 : 개발팀 총괄
        • 리드 디벨로퍼 : 스크럼 마스터
        • 디벨로퍼 : 3~4명
        • QA : 1 ~2명
        • DevOps Engineer : 1명
  • 커뮤니케이션
    • 슬랙
      • 언제든지 대화에 참여해서 함께 토론
      • 커뮤니케이션 비용이 낮아짐
      • 리모트 업무 특성상 시차가 발생하여 커뮤니케이션이 어려운데 히스토리가 남기 때문에 대화가 이어짐
      • 굉장히 중요한 역할 수행하고 있음
  • 리더십
    • 사일로간의 벽을 허무는데 중요한 역할자
    • 조직간 협업 지원
  • 작은 변화와 많은 릴리즈
    • 릴리즈 배포 주기를 짧게함
    • 롤백이 쉬움
• Automation
  • Terraform
  • Chef
  • Docker와 Kubernetes를 도입하게 되면 Terraform이나 Chef의 역할이 줄어들기 때문에 시스템 구성을 조정 할 필요가 있음
• Measurement
  • 모니터링
    • Datadog
  • 알람
    • pagerduty
• Sharing
  • 슬랙
    • 메신저
    • 화상회의
    • 자료공유
    • 히스토리
    • 주제별 채널
    • DataDog, PagerDuty등의 서비스 연계

Session5. 기술 부채의 늪 탈출기

• 강연자 : 허진수 럭스로보

• 이슈 관리

  • 컨플루언스
  • 지라

• 데일리 스탠드업 미팅

  • 오프라인에서 안하고 슬랙에서 미팅
  • 어제한일/오늘할일/불편한점

• 깃

  • 깃랩 사용
  • Git Flow 사용
    • 팀에 맞는 규칙으로 변형해서 사용
    • master/develop 브랜치는 언제든 릴리즈 될 수 있는 브랜치이기 때문에 엄격하게 관리
      • GitLab MR을 거쳐야만 머지
      • GitLab MR 요청 시에는 요청 내용에 대해 상세히 작성하도록 강제
      • 요청 내용이 명확해야 코드리뷰를 하는 사람이 편함
      • 진행 상황에 대해서는 커뮤니케이션을 줄이기 위해 이모티콘에 의미 부여해서 사용

• 코드 리뷰

  • 자질구레한 것들에 집중하는 것을 피해야함
  • 각 줄의 실수를 잡아내는 것이 아님
  • 전체적인 큰 그림 파악과 방향성 검토

• CI/CD

  • Jenkins
    • 코드 커밋이 발생하면 빌드 수행해서 오류가 없는지 파악
    • GitLab MR이 열리면 코드를 머지해서 오류가 없는지 파악
    • 태그를 붙여서 자동 릴리즈 수행 (tag-push)
    • Jenkins Pipeline 사용

Session1. Spinnaker on Kubernetes

• 해외에서 스피너커로 많이 발음
• Spinnaker
  • 넷플리에서 시작
  • 구글과 함께 오픈소스로 공개 후 관리
• 클라우드에서 Spinnaker
  • Inventory + Pipelines

핵심 기능

• Cluster

  • 쿠버네티스의 클러스터가 아닌 어플리케이션의 집합

• Deployment

  • 배포

• 멀티 클라우드

  • 대부분의 Public Cloud, Private Cloud 지원
    • 오픈스택은 V3 API 지원
  • 테라폼도 지원 예정

• 알림 기능

• 승인 기능

  • 관리자 판단 하에 수동으로 배포 진행할 수 있는 단계

• 딜리버리 영역의 대부분의 작업을 스피너커가 대신 해줌

• Chaos Monkey 오픈소스가 내장되어 있어서 카오스엔지니어링 지원

• 배포 전략

  • 블루/그린
  • 카나리
  • 롤링

커뮤니티

• Community.spinnaker.io가 활발

주요 마이크로서비스

• Clouddriver : 멀티 클라우드 관련
• Kayenta : 카나리 배포 분석 관련
  • 카나리 배포 시 배포 내용은 분석하는 것을 Spinnaker에서 제공
• Orca : 오케스트레이션 관련

CLI 도구

• Halyard
  • CLI 도구
  • kubectl과 같이 Spinnaker를 관리하기 위한 도구

Spinnaker on kubernetes

• Legacy(V1) 버전과 Maifest(V2) 버전이 지원됨
  • V1에서는 Spinnaker와 Kubernetes의 중복 용어들이 존재하여 혼란이 있었음
  • V2에서 개선
    • 파일로 형상 관리
    • 외부 저장소를 사용하여 관리 가능
    • 대부분 V2를 사용

젠킨스와 비교

• 젠킨스는 CI 도구
• Spinnaker는 클라우드 API를 직접 호출하기 떄문에 스크립팅 요소가 적음
• 빌드가 필요한 경우 Spinnaker에서 젠킨스를 호출해서 사용할 수 있음

Native 쿠버네티스와 비교

• 다양한 배포 전략
  • 승인 기능
  • 인프라 관리
  • 빠른 롤백 등
• Spinnaker를 관리해야하는 관리비용이 있음

파이프라인

• Stage : 워크플로우 단위
• 코드 커밋 -> docker hub에서 트리거 -> Spinnaker 웹 훅 -> 스테이징에 배포 -> QA 담당자가 테스트 후 승인 -> 라이브 배포
• 모니터링은 프로메테우스로

정리

• 단일 소스를 대상으로 신뢰성있는 배포를 위한 좋은 전략
• 실행에 대한 감사 기능
• 코드와 컨테이너 이미지 검증
• 베스트 전략 : Spinnaker + Jenkins + Packer + Helm + Terraform
• Redis에 성능저하가 발생하면 Spinnaker 전반적인 성능에 영향
  • 튜닝 포인트
• 모니터링에는 Datadog, Prometheus, Stackdriver
• 노드 로깅은 fluentd, ElasticStack
• 개발팀은 골든 이미지 생성, 운영팀이 Spinnaker를 통한 배포면 좋지 않을까

Session2. Chaos Engineering

클라우드 여정을 통해 배운 점

• 서비스 운영의 숙명 '장애'

  • 빨리 전파되고 늦게 복구 됨
  • 어디든 장애는 날 수 있음
  • 어떻게 빠르고 안전하게 복구 할 수 있는 가가 중요

• 많은 회사들의 장애 대응 히스토리 : github.com/danluu/post-mortems

• Jesse Robbins

  • 실제 서비스에서 장애가 발생하면 어떻게 복구가 되는가
  • 넷플릭스에서 2011년에 인프라를 위한 장애 대응 서비스 제안 - 카오스 몽키
    • 2008년에 데이터 센터 장애 발생 이후 클라우드로 이전 시작

• 넷플릭스의 마이크로서비스

  • ELB -> Zuul (API Gateway) -> 각 서비스로 전파
  • 마이크로서비스간 인터페이스 이슈 해결
    • Hystrix
      • Circuit Breaker
      • Fallback
      • 장애가 발생하면 조기에 Circuit Breaker가 차단하고 장애 확대를 방지
      • Circuit Breaker가 가동되면 미리 만들어진 응답 제공
    • Ribbon
      • Client Side Load Balancer
        • 서버의 부하 방지
    • Eureka
      • 서비스 디스커버리

Chaos Engineering 적용 방법

• 넷플릭스는 모든 인프라에 대한 실패를 가정하고 인프라를 운영
• 카오스 엔지니어링은 실제 서비스에 장애를 주입
  • 출시 전 테스트에서 드러나지 않은 아키텍처상의 문제를 직접 드러내는 것
• Chaos Monkey
  • 실제 서비스를 죽이면 어떤 현상이 발생할까를 테스트
• Chaos Gorilla
  • 가용 영역을 날려버리면 어떤 현상이 발생할까를 테스트
• Chaos Kong
  • 리전을 날려버리면 어떤현상이 발생할까를 테스트
• 장애 발생 방법
  • 애플리케이션 부하 테스트
  • …
• 카오스 엔지니어링의 목적은 문제를 만들려는 것은 아니고 문제를 해결하기 위한 것
• 넷플릭스에는 별도의 카오스팀이 존재
  • 카오스 엔지니어링에도 원칙이 있음
    • 폭발 반경 최소화 등
  • 책도 출간함
• 진행 과정
  • 정상 상태 : 실제 노말하게 운영되고 있는 상태
    • 노말하냐의 기준은 실제 비즈니스에서 산정되는 통계치를 기준으로 삼음
  • 가설 수립 : 장애가 나타날 수 있는 상황의 가설을 세움
  • 실험 디자인 : 어떤 시나리오로 테스트를 할 것인지를 계획하고 전파
    • 카나리 배포
  • 실험 결과 측정
    • 장애 감지 시간, 문제 인지 및 알림 시간, 사내 전파 시간, 자동 롤백 시작 시점, 복구되는 시간 등등
  • 문제점 수정
    • Post Mortems 및 오류 해결
• 전제 조건
  • 클라우드 환경
  • 마이크로서비스 환경
  • DevOps 문화

Kubernetes를 위한 카오스 도구

Kube Monkey

• Chaos Monkey와 의미가 동일
• Kube Monkey는 Kubernetes의 Pod들을 임의로 죽임
• Config 파일을 통해 전략을 설정
• Kube Monkey도 Kubernetes의 Deployment로 생성됨
• 데모
  • Redis Master/Slave 안정성 테스트
  • 운영 중인 Redis 클러스터를 Kube Monkey를 통해 주기적으로 랜덤하게 Terminate 시키는데 정상 운영이 되는 지를 확인

Istio

• 서비스메시 : 라이브러리 방식을 벗어나 경량 프록시로 비즈니스 로직과 내부 네트워크 분리
  • 서비스 구동 시 통신을 위한 Proxy를 함께 배포하고 서비스간 통신은 Proxy를 통해서만 수행 (사이드카)
    • Service Mesh Plane을 통해 Proxy 통신에 대한 데이터를 수집하고 관리
• Istio는 서비스 매시용 오픈소스
  • 마이크로 서비스의 서비스간 통신, 운영 및 배포 복잡성을 해결하기 위한 분산 서비스 관리 도구
    • 지능적 라우팅, 로드밸런싱
    • 언어 및 프레임워크 독립적인 복원성
• Proxy로 Envoy 오픈소스 사용
  • 다른 프록시를 사용해도 무관함
• 트래픽 관리
  • 서비스별로 로드 밸런싱 조절 가능
  • 트래픽 정책 설정으로 Circuit Breaker 역할 수행도 가능
  • Fault Injection 기능을 통해 카오스 엔지니어링
    • Timeout
    • HTTP Abort

그 외 오픈소스 도구

• Chaos Toolkit

• PowerfulSeal

• Gremlin

  • 카오스 엔지니어링 관련 가장 상품성 있는 제품을 만들고 있음

Session3. Kubernetes Calico

프로덕션에 필요한 요소

• 마스터
  • Calico
  • Etcd
    • Key-Value로 쿠버네티스의 모든 정보 저장
  • Kube-API
  • Kube-Scheduler
  • Kube-Controller
  • Kube-Proxy
  • kubelet
• 워커 노드
  • Calico
    • 쿠버네티스 네트워크 모듈
  • Nginx
    • Master 노드의 API와 밸런싱하게 통신하게 하기 위함
  • Kube-Proxy
  • Kubelet

쿠버네티스를 설치하는 방법

• kubespray

  • Ansible 기반
  • 사전 준비 작업 필요
    • swapoff
      • 네트워크가 안되거나 메모리가 부족하면 쿠버네티스는 관리할 수 없다고 판단하여 팟들을 죽임
      • 팟들이 갑자기 죽는 다면 노드 분산 필요
    • 패스워드 없이 sudo 권한을 사용 해야 한다던가, Ansible을 설치해야한다거나 등등
  • Ansible Inventory 파일을 샘플로 제공
    • 중요 파일
      • k8s-cluster.yml
        • 쿠버네티스에 관련된 설정 모음
      • etcd.yml
        • etcd는 메모리를 늘려놔야함 기본값이 적게 설정되어 있음
    • Inventory 내 그룹명들은 수정하면 안됨
  • Calico가 기본으로 설치됨
    • Mesh 형태로 구성
      • 따로 설정하지않으면 BGP 피어링을 기본으로 메시 구성
    • Mesh 구조는 노드가 50대 이내 일때만 사용 권장. 그 이후부터는 메시구조가 너무 복잡해짐
  • 관리용 Ansible playbook
    • cluster.yml
    • reset.yml
    • scale.yml
    • upgrade.yml

• CNI 선정 기준 중 하나는 네트워크 통신 방식

  • Calico는 iptables를 사용하는데 더 빠른 것을 원한다면 ipvs 기반의 CNI를 선택

• kubespray에 설정된 기본 설정 그대로 사용하는 것을 권장

  • 버전 정보 정도만 수정해서 사용

• local volume의 경우에는 파일시스템에 따라 생성 실패할 수도 있음 Pod 재생성하면 해결됨

Kubeadm vs kubespray

• kubeadm을 사용하면 각 노드마다 동일 설정 명령을 수행해야함
• 자동화를 위해서는 결국 Ansible을 사용해야하지 않을 까
• kubespray에서도 kubeadm 사용을 지원
  • 설정을 통해 쿠버네티스 설치 시 내부적으로 kubeadm을 사용

Tip

• kubespray 원본은 놔두고 동일 레벨에 사용자디렉토리 생성 후 참조할 yml 파일의 경로를 상대경로로 지정해서 사용
• 쿠버네티스 코드를 분석하고 중간에 로그를 삽입해서 디버깅 용도로 활용하고 있음
• CNI 플러그인을 체이닝 방식으로 여러가지를 연계해서 사용할 수는 있는데 굳이 써야하나 생각이 듬
  • Calico는 Network Policy 지정이 가능
  • 질문자 중에 Calico를 ipip 터널링을 위해 사용

Keyword

• BGP
• NAT outgoing
• ipipMode

SK 활용

• 오픈스택을 전부 컨테이너기반으로 전환

  • CI/CD
    • Jenkins, Rally/Tempest, Chaos Monkey
    • 마스터 노드에 Jenkins 마스터를 설치하고, 설정은 SAP에 안전하게 보관
    • Jenkins에서 Job을 실행하면 워커 노드에 Jenkins Slave가 생성되고 실행됨
  • OpenStack Container
    • Docker, Kolla

Session4. Serverless in K8S

• 서버리스란?
  • BaaS나 FaaS, 혹은 둘 다를 이용한 어플리케이션 아키텍처 설계 방법론
  • AWS의 대표적인 FaaS는 Lambda, BaaS는 S3, DynamoDB 등
• 사용자의 요청은 FaaS의 API Gateway를 거쳐 추상화된 Controller가 요청에 해당하는 Function을 실행하고, 필요 시 BaaS(내부 서비스나 데이터베이스)를 사용하여 응답을 사용자에게 반환

Serverless vs Serverless Functions vs FaaS

• Serverless는 사상
• Serverless Functions는 서버리스 사상으로 커스텀한 함수를 실행시킬 수 있도록 하는 것
• FaaS는 이러한 Serverless Functions를 각 클라우드 프로바이더가 각 환경에 적합한 서비스로 제공하는 것

MSA vs Serverless Functions

• 구분 짓기 애매
• MSA가 서비스 단위로 잘게 쪼갰다면 Serverless Functions는 더 잘게 쪼갬 (코드 조각)

서버리스 장점

• 저렴
• 서버 관리 불필요
• 확장성
• 작은 비즈니스에 유리
• 빠른 프로토타입

서버리스 단점

• 콜드 스타트
  • 첫 실행 시 컨테이너가 구동되는 시간이 필요
• Nano Service
  • 너무 잘개 쪼개져있어서 관리의 어려움
  • 안티패턴
• 서버리스도 서버가 있음
  • 사내에서 자체 구성하기 위해서는 서버리스 서비스를 제공하는 부서에서는 서버 관리가 필요
  • 클라우드 프로바이더가 제공하는 서비스는 서버 관리를 프로바이더에서 하기 때문에 서버리스라 할 수 있음

SK에서 활용

• Private FaaS를 위해 자체 구현
• 쿠버네티스 기반으로 구현
  • Fission 오픈소스
    • Serverless Functions Framework
    • CNCF에 등록된 오픈소스
    • 서버리스 출현이 근래이기 떄문에 대부분의 오픈소스가 인지도가 없었음
    • 콜드 부팅의 문제가 가장 적은 오픈소스를 선택
    • 함수를 생성/삭제/관리 할 수 있는 오픈소스
    • Fission Workflow 오픈소스
      • 너무 잘개 쪼개진 함수들의 관리가 어려운데 이를 묶어서 워크플로우를 생성해주는 프로젝트
  • Dispatch 오픈소스
    • 서버리스 프레임워크
    • Dispatch 위에 Fission이 올라가는 방식
• Private 할 필요가 없다면 퍼블릭 클라우드를 이용하는 것이 좋음
• 콜드 스타트 문제를 해결하기 위해 고생함
  • 프리웜을 수행하는 방식으로 해결
  • 요청 -> 런타임생성 -> 코드 설치 -> 의존성 설치 -> 함수 실행
  • Fission은 런타임생성까지 프리웜하는 것으로 콜드 스타트 개선
  • SK에서는 코드 설치까지 프리웜 진행
    • 코드 설치는 코드가 커밋되면 docker volume을 통해 실제 호스트에 동기화
  • 각 코드와 자원에 따른 컨테이너들을 미리 구동시켜놓고 재사용
    • 구동된 컨테이너는 콜드 스타트 문제 때문에 정해진 개수만큼은 풀로 관리
    • 함수 실행 요청이 끝나면 해당 함수에 대한 부분만 메모리에서 제거하는 방식으로 사용
    • 이전 코드로 인해 환경이 변경될 수 있는 위험 요소가 있음
      • 이를 위해 컨테이너를 재생성하는 전략이 필요
    • 사용자의 니즈에 따라 컨테이너 지속성이 필요한 경우를 선택적으로 할 수 있도록 함
      • 선택에 따라 주기적으로 컨테이너가 종료되거나 유지를 결정
    • Fission내에 이러한 재사용에 대한 설정을 위해 3가지 타입을 제공
• 사용자 코드에 따른 부하 관리
  • 사용자 코드에 부하를 줄만한 코드가 있는지 검사하는 것은 불가능
  • 이를 검증하기 위해 노드를 분리
    • 미리 정상 범위의 메트릭을 산정하고 이를 초과하는 컨테이너들을 별도 관리
  • Management Worker Node
    • nodeSelector 방식
      • Pod이 노드를 선택해서 들어감
  • Runtime Worker Node
    • Taint & tolerations 방식
    • 이 방식을 사용하여 부하 분산
• 부하 관리
  • Docker는 현재 상태 지표를 파일로 저장함
    • /sys/fs/cgroup
  • 파일의 정보를 기반으로 부하를 많이 먹고 있는 사용자의 컨테이너를 제한

Tip

• Helm의 업데이트 히스토리 관리가 어려워서 Helm은 Template를 생성하는 용도로만 사용하고 이를 통해 나온 yaml 파일을 kubectl apply 명령으로 실행
  • kubectl apply 명령은 히스토리 관리가 가능

Session5. Journey to Windows Kubernetes

• 쿠키워즈에서 게임서버는 리눅스, 운영 도구는 윈도우

Windows Kubernetes

• 기존의 쿠버네티스와 크게 다르지 않음
• 고성능의 IOCP를 사용할 수 있다는 장점
• 기존 레거시 시스템을 쿠버네티스 환경으로 전환하여 클러스터 관리를 편하게 할 수 있다는 장점
• 안정화까지는 다소 시간이 걸릴 것으로 예상 됨
  • Windows Server 2019에서 안정화 될 것으로 예상
• Windows Server VM 필요
• 설치과정이 네트워크 설정부터 각 종 raw level의 설정을 수동으로 했어야 했는데 Rancher를 사용하여 어느정도 자동화 가능
• Windows 10에서는 컨테이너 기술을 사용하려면 무조건 가상화 기술이 필요

HCS(Host Compute Service)

• 쿠버네티스는 Docker REST API로 컨테이너 관리
• Docker는 HCS와 HNS로 커뮤니케이션
• 윈도우에서 컨테이너를 구동한다는 것은 커널에 있는 HCS를 사용해서 구동한다는 것

HNS(Host Network Service)

• Windows에서 쿠버네티스를 사용할 때 팟마다 네트워크 인터페이스가 생성되어서 엄청나게 많은 네트워크가 생성되는 문제가 발생함
• 이러한 이슈를 해결하기 위해 한단계 상위의 네트워크를 구성하게 되었는데 이것이 HNS (잘 이해 못함)

그 외

• 윈도우 10과 윈도우 서버에서 구동되는 Docker는 다름
• Rancher를 사용하는 경우 CNI로 flannel을 권장.
  • linux와 windows가 다르게 구현되어 있음
• 컨테이너용 windows server os가 따로 있음
중첩 가상화를 사용할 수 있는 환경이 필요
• Azure : 3세대 VM 이상
• AWS: i3.baremetal 혹은 유사 인스턴스

들어가며

백엔드 개발을 주로 해오다가 최근에는 프론트엔드 개발까지 병행하게 되었다. 프론트엔드도 굉장히 빠르게 발전하고, 다양한 도구들이 등장하면서 복잡도가 많이 증가하게되었기 때문에 짧은 시간 내에 능숙하게 다루기란 정말 쉽지 않다. 백엔드 개발도 하면서 프론트엔드 공부와 개발을 병행하다보니 작은 기능 구현에도 굉장히 많은 시간이 소요되고, 결과물에서 많은 버그가 발생하였다. 이 과정에서 이러한 문제들을 해결하려면 어떻게 해야할지에 대해 고민을 많이 했고, 그 때마다 내린 결론은 기본기였다. 현재는 기본기가 부족하기 때문에 지속적으로 습득하고 있는 지식들을 그때 그때 적용하려다보니 코드의 일관성도 떨어지고, 혼자 개발했지만 갈수록 다양한 사람이 개발한 것 같은 모양새가 되고 있었다.

기본기를 위해 자바스크립트 강의도 듣고, 책도 여러권 구입해서 정독하면서 점차 익숙해지고 있었는데 또 다시 내 발목을 잡은 것은 HTML과 CSS 였다. 이론적인 부분은 쉽게 따라갈 수 있었지만 이 HTML과 CSS를 잘 조합해서 사용자에게 편리함을 제공하고, 일관된 화면을 제공하기 위한 UI, UX 적인 소질이 많이 떨어짐을 느꼈다.

그렇게 여러책을 찾아보게 되었고, "모두의 HTML5&CSS3 : 16일 만에 배우는 웹 사이트 제작 기초"를 읽게 되었다. 시중에 HTML과 CSS 각각의 주제만으로도 굉장한 두께의 책들을 쉽게 볼 수 있는데, 이 책은 그에 비해 부담없이 짧은 시간 내에 볼 수 있는 분량이었다. 두꺼운 책들을 시도했다가 여러번 완독에 실패했던 나로써는 이 부분이 매력적이었다.

책을 읽으며

이 책은 HTML과 CSS를 완전히 처음 접하는 독자들도 이해할 수 있도록 굉장히 쉽게 설명하고 있다. 저자분께서 독자들이 쉽게 이해할 수 있도록 다양한 비유를 들기도 하고, 컬러풀한 그림을 통해 시각적으로 보여주기도 하는 등의 노력을 여러 부분에서 느낄 수 있었다.

아쉬운 부분도 있었는데, 우선은 저자분께서 쉬운 이해를 위해 비유를 들어주는 것은 정말 좋았지만 개념적인 부분에서도 비유가 등장해서 오히려 혼란스러웠던 부분도 있었다. 예를 들면 태그의 특성을 혈액형을 비유로 든 부분이 있었는데, 같은 사람이라도 서로 다른 혈액형을 가지고 있는 것처럼 태그들도 그 태그만의 특성들이 있다는 의미로이해를 했다. 하지만 갑자기 태그의 혈액형이라는 것이 등장해서 정말로 있는 개념인건지, 태그의 style을 의미하는 건지, id를 의미하는 건지 아니면 여러 특성을 하나로 퉁쳐서 표현한 것인지 혼란스러운 부분이 있었다.

그리고 예제의 경우에는 완전히 기초적인 예제로 진행하다가 마지막에 갑자기 완성도 있는 프로젝트를 진행하게되어서 당황스러웠는데 각 챕터별로 배운 내용을 가지고 조금씩 프로젝트를 완성시켜보는 것도 좋았지 않았을까라는 생각이 들었다.

정리하며

책을 읽으면서 누구나 읽을 수 있는 책이지만 HTML과 CSS에 약간의 지식이 있는 독자들에게는 너무 쉽게 느껴져서 만족감이 떨어질 수도 있겠다는 생각이 들었다.

하지만 HTML과 CSS를 아예 모르지도 않고, 잘 알지도 않는 나로써는 이론을 정리하는데 많은 도움이 되었고, 읽어 갈 수록 기본기가 점점 탄탄해지는 것을 느낄 수 있었다. 쉬운 내용들은 빠르게 넘어가고 몰랐던 개념들은 찬찬히 보다보면 어느새 마지막 페이지에 와 있을 정도로 술술 읽히는 책이었다.

들어가며

해마다 IT 트렌드에 대한 도서들이 출간되는 것은 알고 있었지만 봐야할 필요성을 크게 느끼지 못하고 있었다. SNS나 IT 뉴스들을 통해 대략적인 IT 트렌드의 흐름은 인지하고 있었고, 책에 포함된 내용들이 크게 와닿는 부분들이 없었기 때문이었던 것 같다. 

2018년도는 급변하는 환경을 직접적으로 느끼고 트렌드에 대한 중요성을 너무나 느꼈기 때문에 더욱 관심이 생겼다. 그래서 마이크로소프트웨어도 정기 구독 신청하고, 관련 컨퍼런스에도 자주 참석하게 되었다. 

또한 이번에는 IT 트렌드에 대한 책도 한번 읽어보자는 생각이 들어서 읽기 시작하게 되었다.

책을 읽으며

책을 읽으며 작가의 필력에 감탄했었다. 나도 글쓰기를 자주 하는 편이기 때문에 이해하기 쉽게 잘 작성하는 것이 얼마나 힘들고 어려운지 잘 알고 있었는데, 어려울 수 있는 IT 기술 이야기를 이해하기 쉽고 재미있게 잘 작성하셔서 몰입하면서 읽을 수 있었다.

그 중에서도 가장 기억에 남았던 것은 5G에 대한 이야기였는데 벌써부터 광고에도 등장하고 있기 때문에 더욱 관심이 갔었던 것 같다. 내용을 읽으며 다가 올 현실을 자꾸만 상상하게 되고, 관련 내용을 더 공부하고 싶다는 욕구가 들기도 했다. 

산업이 발전하게되면 이로 인해 직장을 잃게 되는 사람도 많겠지만 새로운 사업이 창출되고, 이로 인해 실제로는 일자리가 더욱 늘어난다는 말에 생각해보니 최근에만 해도 VR과 AR이 등장하면서 관련 매장들도 늘어나고, 엄청나게 많은 사람들이 이 새로운 산업에 종사하고 있다는 것이 느껴져 신기하기도 하고 재미있었다.

책의 내용 중 머신러닝에 대한 이야기는 너무도 많이 들어왔고, 블록체인에 대한 부분은 요즘 화두가 되고 있기 때문에 궁금했었는데, 이 책으로 인해 어느 정도 궁금증이 해소 되었다. 블록체인 분야도 매우 전망이 있을 것이라는 생각이 들어서 공부해보고 싶기도 했다. 또한 각 장마다 포함된 기술 컬럼을 통해 전문 지식까지 습득할 수 있어서 좋았다.

정리

결론적으로 IT 트렌드 관련 책은 해마다 읽어봐야겠다는 생각이 들었다. 어렴풋이 알고 있던 주제들이 흐름을 알게 되고, 논리적으로 이해가 되면서 만족감을 크게 느꼈다. 

이런 내용들은 재미있게 읽었다가도 금방 잊어버리기 때문에 곁에 두고 주기적으로 훑어보는 것도 좋을 것 같다. 앞으로도 트렌드에 지속적으로 관심을 가지면서 뒤쳐지지 말고 다가올 미래에 대비해야겠다.

들어가며

백엔드 개발을 하다보면 데이터베이스는 뗄래야 뗄 수 없는 관계이고 데이터베이스의 중요성에 대해서는 누구나 다 알고 있는데도 생각해보면 깊이 있게 공부해 본 적이 없는 것 같다. 내부 원리를 이해하기 보다는 검색 조건에 해당하는 필드들에 인덱스를 걸어서 성능 향상이 있는지 체크 해보는 것이 고작이었었다. 아마도 개발이 주 업무이다보니 데이터베이스 보다는 개발 쪽에 치우치치 않았나 생각된다. 제대로 알지 못하고 데이터베이스를 설계하고, 복잡한 쿼리를 프로시저에 작성하면서 실제 운영에 들어갔을 때 엄청나게 고생을 했던 기억도 있다.

처음 접해봤던 PostgreSQL부터 MS-SQL, MySQL, MariaDB 등 다양한 데이터베이스를 사용하여 개발을 해왔는데 대부분의 쿼리가 비슷하다보니 각각의 엔진에 대해 크게 생각하지 않고 개발을 진행해왔었다. 책에서도 나와있듯이 각각의 데이터베이스들은 특징이 있고, 같은 쿼리라도 내부적으로는 다르게 동작하는 부분들이 존재한다. 그렇기 때문에 실제 프로덕션 레벨에서 관리를 수월하게 하려면 이러한 특징들에 대해 잘 알고 있어야 한다.

책을 읽으며

Oracle이나 MS-SQL의 경우에는 비용이 굉장히 비싸기 때문에 내가 거쳤던 회사들 중 큰 회사에서는 사용하는 경우가 있었지만 스타트업에서는 대부분 MariaDB를 사용했다. 그리고 주변에 얘기 듣기로도 MariaDB를 굉장히 많이 사용하고 있는 것으로 알고 있다. 그만큼 MariaDB에 대해 잘 알고 있다면 경쟁력을 가질 수 있을 것이라고 생각한다. 책을 읽을 수록 그 기반을 다지기 위해 "이것이 MariaDB다"라는 책이 적합하다는 생각이 들었다. MariaDB에 대한 책이 시중에 그리 많지 않다는 것도 한 몫하는 것 같다.

곧바로 쿼리에 대한 설명에 들어가지 않고 실무에서 프로젝트를 진행하는 단계를 설명하고, 데이터 모델링의 필요성과 모델링 하는 방법에 대한 설명이 선행되는 것을 보고 책의 구성이 참 잘 되어 있다고 느꼈다. 책의 저자분께서 데이터베이스 관련 책 집필도 많이 하시고 경험이 많으셔서 그런지 책을 읽어나가며 평소 궁금했던 부분들이 하나씩 풀리는 것을 느낄 수 있었다.

SQL 고급과 MariaDB 고급 장을 읽을 때는 내가 정말 많은 기능들을 모르고 썼구나를 느낄 수 있었는데, 알아두면 유용한 기능들이 많이 포함되어 있어서 실제 필요할 때 써먹어보려고 키워드들을 정리하기도 했다. 인덱스에 대한 개념도 매번 공부할 때마다 새로웠는데 어려운 개념을 이해하기 쉽게 잘 풀어서 작성되어 있어서 잊을 때마다 한번씩 꺼내보면 좋을 것 같다.

정리하며

사실 책만 봐서는 데이터베이스를 자유자재로 다루기는 어렵고, 실제 운영을 해보며 다양한 경험을 통해 많은 노하우를 쌓아야 한다고 생각한다. 데이터베이스를 사용하면서 발생하는 여러가지 상황에 대응 할 수 있으려면 데이터베이스에 대한 기반지식이 있어야 하고 그 기반지식을 쌓기 위해 "이것이 MariaDB다"로 시작하는 것이 좋은 방법 중 하나라고 생각한다.