Polpid's Pensieve

 클라우드를 이용한 개발 및 운영이 지금은 당연한 것으로 생각되고 있다. 그만큼 클라우드는 어느 순간 개발에 대한 영역에서 중요한 포지션을 차지하고 있다. 프로젝트를 시작하게 되면 코드관리, 배포, 운영에 대한 모든 인프라 환경이 클라우드로 변경되어가고 있다. 하지만 우리의 어플리케이션은 그런 환경에 맞게 개발되고 있는가라고 질물을 한다면 대답하기가 쉽지 않다.

이러한 어려움들을 해결하기 위해서 우리는 패턴이라는 것을 사용한다. 각각의 요건과 환경에 맞게 이미 시도해본 사람들의 경험을 바탕으로 만들어진  형식들이 바로 패턴이다. 이 책에서는 우리가 클라우드 환경에서 어플리케이션을 개발하고 운영하고 배포하기 위해서 적합한 패턴들이 어떤것들이 있는지 알려준다. 이 책을 통해 알게 되었는데 패턴이 생각보다 정말 많다.

많은 패턴들을 총 6가지의 큰 주제로 묶어서 설명을 해주고 있다.

통신패턴
연결성 및 조합 패턴
데이터 관리 패턴
이벤트 주도 아키텍처 패턴
스트림 프로세싱 패턴
API 관리 및 사용 패턴

각각의 패턴 하위에 관련된 수많은 패턴들이 있는데 다음과 같은 형식으로 설명을 해주고 있다.

패턴 정의 ---> 동작방법 ---> 사용방법 ---> 고려사항 ---> 관련 패턴

동작 방법에 대한 설명은 아래와 같이 그림들을 통해서 이해를 도와주고 있다. 아무래도 패턴이 어떻게 동작되는지 이해하기 위해서는 글보다는 전체적인 그림을 보는게 더 나은데 각 패턴마다 이렇게 동작에 대한 그림들이 있어서 이해하는데 도움이 된다.

위에서도 말했듯이 각 주제별로 정말로 많은 패턴들이 있다. 그래서 읽다보면 각 패턴에 대한 내용이 헷갈릴 때도 있다. 그래서 이책에서는 각 패턴에 대한 주제 안에서도 또 묶어서 설명을 한 후에 그 내용이 끝날때마다 비교를 해준다. 간략하게 정리가 되어있어서 앞에서 봤던 내용들을 정리도 할수 있고 차이점을 한눈에 볼 수 있다. 

그리고 제일 마지막 8장에서는 "클라우드 네이티브 패턴 적용하기" 라는 주제로 "온라인 쇼핑몰" 를 설계를 할때 어떤 패턴들을 적용하는지 나와있다. 쇼핑몰에 필요한 기능들과 그 기능들을 연결하기 위해서 어떠한 아키텍처들이 필요하고 어떤 패턴들이 알수 있다. 이부분을 통해서 직접 코드로 구현을 해보면 쇼핑몰이라는 주제를 통해 다양한 패턴들을 경험할 수 있어서 좋을것 같다. 

계속해서 말하지만 정말 많은 패턴들을 다루고 있기 때문에 각각의 패턴들에 대한 상세한 내용들이나 유즈케이스를 원한다면 다시 찾아보는 수고로움이 필요하다. 하지만 이런 패턴들이 존재한다는 것을 알고 찾는것과 모르고 찾는것은 시작점부터가 다르다고 생각한다. 그래서 클라우드 네이티브 아키텍처에 관심이 있는 분들이라면 각각의 패턴을 이해하는데 도움이 될거라 생각된다. 

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

책을 읽어보기 전까지는 단어의 의미조차 알지 못했던 Developer Relations 에 대한 책을 읽게 되었다. 단어 자체가 길다보니 보통은 축약해서 DevRel(데브렐) 이라고 표현을 하는것 같다. 

처음에는 데브렐의 역할이 기업의 마케팅이나 영업과 비슷하다고 생각을 했으나 알고 보니 전혀 다른 역할이었다. 내가 책을 읽으면서 간략하게 파악한 그들의 역할은 다음과 같았다.

개발자들을 위한 문화를 만드는데 고민한다. 커뮤니티를 만들고 활성화 될수 있도록 돕는다. 하지만 이런 행동들이 기업의 홍보를 위한것이 아니어야 한다. 

마지막 문장이 정말 의미심장하다. 기업의 홍보를 위한것이 아니어야 한다. 정말 쉽지 않은 일이고 단시간이 이루어 질수 없는 일이다. 분명 꾸준한 노력과 인내, 그리고 속한 조직의 지지가 있지 않고서는 달성하기 힘든 목표이다. 

그럼에도 불구하고 이런 역할을 필요로 한다는 것은 그만큼 개발자라는 역할이 중요해졌다는 의미이다. 책 뒷쪽에 있는 국내 회사에서 데브렐 역할을 하고 있는 분들의 인터뷰를 읽으면서 정말 부러웠다. 우리 회사도 저렇게 생각을 하고 문화를 키워 나가면 좋을 텐데, 아직은 많이 부족하구나 라는 생각을 했다. 

그렇기에 이 책은 조직을 이끌어 가는 리더들이 한번쯤은 읽어봐야 한다고 생각한다. 개발자들을 위한 문화는 어떻게 만들어 가야 하는지 그리고 어떤 부분들이 필요한지 많은 도움을 받을 수 있을 것이다.

    "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

집에 있는 헤드셋이 이상하게 인식이 안되서 이어폰을 사게 되었다. 3만원 이하로 커널형, C타입 이어폰을 찾다가 이 제품을 선택했다.

브리츠 P900GX C타입 커널형 이어폰.

우선 제품을 꺼내보고 처음에는 당황했다. 이어폰이 사진에서 처럼 납짝했기 때문이다. 그런데 막상 귀에 껴보니 밖으로 튀어나오지도 않고 딱 맞게 들어가서 착용감이 좋았다. 좌, 우가 좀 헷갈리는것 빼고는 만족스러웠다. 약간 무게감도 있고 귀에 쏙 들어가고 음질도 괜찮았다. 이정도면 가격대비 만족스러운 퀄리티 인것 같다.

• 컬랙션 객체임을 JPA 에 알려주는 Annotation.

  @Entity 
  public class Person { 
  	@Id 
      private Long id; 
      private String email; 
      
      @ElementCollection 
      @CollectionTable( name = "address", joinColumns = @JoinColumn(name = "person_id") ) 
      List<AddressInfo> addressInfoList = new ArrayList<>(); 
  }

• Entity 와 라이프 싸이클을 같이 하며 독립적으로 사용 불가능 하다.
• 부모 Entity가 삭제될 경우 같이 삭제된다. (실제 클래스에 cascade 를 설정하는 옵션이 없다.)
• ElementCollection의 Fetch 전략은 기본이 Lazy 이다.
• 실제 테이블은 FK 를 이용해서 생성된다.

  Hibernate: create table address (person_id bigint not null, address1 varchar(255), address2 varchar(255), zip_code varchar(255))
  Hibernate: create table person (id bigint not null, email varchar(255), primary key (id))
  Hibernate: alter table address add constraint FK81ihijcn1kdfwffke0c0sjqeb foreign key (person_id) references person

• CollectionTable Annocation 을 사용하지 않을 경우에는 다음과 같이 테이블이 생성된다.

  Hibernate: create table person_address_info_list (person_id bigint not null, address1 varchar(255), address2 varchar(255), zip_code varchar(255))

JPA 가 엔티티 데이터에 접근하는 방식을 지정한다.

1. AccessType.FIELD : 필드에 직접 접근한다.

@Access(AccessType.FIELD)
private String address1;

2. AccessType.PROPERTY : 프로퍼트로 접근한다. 

@Access(AccessType.PROPERTY)
public String getAddress2() {
	return address1 + address2;
}

3. AccessType 이 지정되지 않은 경우는 @Id 위치에 따라 지정된다.

@Entity
public class OrderInfo {
    @Id
    private Long id;
    private String address1;
    @Transient
    private String address2;

    @Access(AccessType.PROPERTY)
    public String getAddress2() {
        return address1 + address2;
    }

    public void setAddress2(String address2) {
        this.address2 = address2;
    }
}

- @Id 위치가 필드에 있기때문에 기본적으로 AccessType.FIELD 가 적용된다. AccessType.PROPERTY를 같이 적용하기 위해서는 메소드 위에 AccessType.PROPERTY 를 넣어주면 된다.

4. 기타 설명들

@Access is used to specify how JPA must access (get and set) mapped properties of the entity. If access type is set to FIELD, the values will directly be read/set on the field, bypassing getters and setters. If set to PROPERTY, the getters and setters are used to access the field value.

FIELD 로 정의하면 다이렉트로 field를 read/set 하고 PROPERTY로 설정하면 getter, setter 메소드를 통해서 접근한다.
https://stackoverflow.com/questions/19264871/what-is-the-use-of-the-access-annoation-in-jpa-means-at-the-entity-level

If you use field-based access, your JPA implementation uses reflection to read or write your entity attributes directly. It also expects that you place your mapping annotations on your entity attributes. If you use property-based access, you need to annotate the getter methods of your entity attributes with the required mapping annotations. Your JPA implementation then calls the getter and setter methods to access your entity attributes.

5 reasons why you should use field-based access
Better readability of your code
Omit getter or setter methods that shouldn’t be called by your application
Flexible implementation of getter and setter methods
No need to mark utility methods as *@Transient*
Avoid bugs when working with proxies

https://thorben-janssen.com/access-strategies-in-jpa-and-hibernate/

개발과 관련된 일을 하는 사람이라면 한번쯤은 구글에서 일하는 생각을 해봤을것이다. 나또한 그랬으며 항상 동경의 대상처럼 여겨졌다. 그들이 하는 일들은 항상 앞서 나가고 무엇인가 혁신적이고 세상을 바꿀것 같은. 그런 기본적은 생각들이 밑바탕에 깔려있었다. 이번에 읽게된 "구글 엔지니어는 이렇게 일한다" 는 그런 구글러들이 어떻게 일하는지, 무엇을 생각하는지에 대해 배워볼수 있는 책이다. 

- 이 책은 개발자들만을 위한 책이 아니다.

이 책은 소프트웨어 엔지니어링에 대한 내용을 많이 다룬다. 프로그래밍과 구분되게 소프트웨어 엔지니어링은 소프트웨어를 개발하기 위해 설계부터 시작하는 모든 라이프 사이클을 포함한다. 그게 개발관련된 일이 될수도 있고 그안의 구성원들인 사람이 될수도 있다. 따라서 이책의 제목에 있는 "구글 엔지니어"들이 일하는 것을 떠올리면 개발자들를 떠올리는게 당연하겠지만 내가 읽어본 이책은 개발자들만을 위한 책은 아니다. 개발자, 디자이너, 관리자등 모든 영역의 사람들이 읽는다면 큰 도움을 얻을 수 있는 책이다. 영역이 IT 관련된 일이 아니더래도 이 책은 많은 사람들에게 도움을 줄 수 있는 책이다. 

- 구글러들도 우리가 생각하는 것들을 동일하게 생각한다.

내 기준에서 구글을 생각하면 항상 특별할 거야 라는 생각이 전제되어있었다. 내가 겪고 있는 일들은 그들은 겪지 않을 거야 라는 생각을 했다. 하지만 그것은 잘못된 생각이었다. 그들도 나와 같은 고민을 하고 나와 같은 어려움을 부딪쳐왔다. 단지 차이점은 그들은 그것을 극복하기 위해 많은 시도와 노력을 해왔고 그 결과 지금의 모습을 만든 것이다. 현재의 모습이 하루아침에 만들어 지지는 않았다. 수도없이 반복되는 노하우들이 쌓이고 쌓여서 만들어낸 결과이다. 누가 시켜서 만든것도 있지만 그들 스스로 만들고 발전시켜나간 일들도 많다. 그게 바로 그들의 문화이고 가치인것이다. 

- 기술을 발전 시키려면 어떻게 해야하는지 그들은 알고 있다.

코드리뷰, 테스트는 개발자에게는 필수조건처럼 따라 다니는 단어이다. 하지만 이게 개발자들에게 익숙해지기 까지는 상당한 시간이 걸린다. 코드리뷰를 무시하거나, 단위 테스트를 무시하게 되면 후에 모든것들이 기술부채로 다가오게 된다. 작은 버그들이 점점 스노우볼 굴리듯 굴러가서 큰 오류를 발생시기고 만다. 그걸 방지하기 위한 행위들중 하나가 코드리뷰와 단위 테스트이다. 실제 구현되는 코드들보다 중요하게 생각해야 하는 부분이 테스트 코드이고, 내 코드가 잘못되어있는지 또는 실수는 하지 않았는지, 아니면 더 나은 방법은 없는지 찾아볼수 있는 방법이 코드리뷰이다. 그들은 그것이 중요하다는 것을 알았으며 지금도 꾸준히 실천하고 있다. 

이 책은 마치 백과사전처럼 읽으면 읽을 수록 배울것이 많은 책이다. 하지만 그들이 했던 방법들이 모두다 내게 맞는 방법은 아닐수도 있다. 하지만 최소한 그들이 해왔던 방법들을 알고 있다면 비슷한 문제를 마주했을때 좀더 현명하게 풀어갈수 있을것이다. 

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

• Image 를 export 하는 방법

​ docker save [option] [tar filename] [image name]

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    fa5269854a5e   2 weeks ago   142MB

docker save -o test.tar fa5269854a5e

• 실행중인 컨테이너를 export 하는 방법

​ docker export [container name or containter ID] > [tar filename]

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                NAMES
791601bf0587   nginx:latest   "/docker-entrypoint.…"   33 minutes ago   Up 33 minutes   0.0.0.0:80->80/tcp   mystifying_benz

docker export 791601bf0587 > test.tar

지난달 CKA 자격증 취득에 이어서 CKAD 자격증도 따게 되었다. 이것도 작년에 사놓은 바우처가 올해 12월 까지 였는데 CKA 자격증 준비하면서 공부했으니 잊어버리기 전에 같이 해보는게 좋을것 같다는 생각을 했다. CKAD 를 먼저 본 분들의 후기를 보면 최근에 본 글들이 많이 없었다. 거의다 작년에 변경되기 전에 시험을 보신분들이 많았다. 일단 변경된 시험 범위는 아래 와 같다. 

• CKA 와 CKAD 문제 구성의 차이점

- docker, heml

CKA 준비할때에는 k8s 의 리소스를 생성하고 수정하는 것은 많이 연습을 해봤는데 docker 나 helm 까지는 많이 해보지는 않았다. 그래서 부랴부랴 udemy 강의에서 변경된 부분에 대한 강의만 다시 들어보았다. 강의와 연결된 실습도 크게 어려움없이 풀었다. 문제에서는 이미지를 build 하고 이미지를 export 하는 문제가 나왔었다. 

- job, cronjob

job 을 생성하는 문제, cronjob 을 생성하는 문제들이 다양하게 섞어서 나왔다. 특히 job 에 대한 옵션들을 많이 주어지는데 그런 부분들을 다 반영해서 만들어야 한다. 

- probe

job 만큼이나 많이 나온 문제이다. probe 를 생성하는 문제, probe 때문에 pod 가 기동이 안되고 있는데 수정하라는 문제등의 문제가 나왔었다. 

- securtyContext

이부분은 serviceAccount와 연계해서 나온 문제들이었는데 sa를 생성해서 pod 에 정의해주라는 문제와 pod 로그를 보고 문제점을 해결하라는 문제였는데 그건 sa 이름이 실제와 이름이 달라서 생긴 문제였었다. 

• 문제를 잘 읽자

CKA 시험과 마찮가지로 문제의 요구사항이 한가지가 아닌경우가 많다. 문제를 끝까지 읽어야 하고 주어진 조건을 반드시 모두 반영을 해야 한다. 그리고 문제에 Pod 를 수정하거나 삭제하지 말고 진행하라는 요구사항들도 주의깊게 봐야 한다. 영어를 번역하는데 헷갈린다면 구글 번역기 크롬 플러그인을 깔아서 확인해보는것도 방법이다. 이것은 문제 삼지 않는다.

• 결과

총 16문제였는데 문제 하나하나 마다 대부분 배점이 높아서 정말 난감했다. 4점짜리는 많이 못본것 같다. 그리고 진짜 시간이 부족했다. 내가 몰라서 찾아본것이 있어서 그런것도 있겠지만 CKA 시험보다는 시간이 정말 빠듯했다. 그래서 마지막에 내가 완벽히 못푼 문제들의 배점을 세어봤다. 그랬더니 34점 점도가 됐었다. ㅡ,.ㅡ;;; 통과 점수는 66점인데 34점이면 완벽히 못푼 문제들을 제외하고 나머지는 다 맞아야 한다는 결론이었다. 이 34점 중에 8점자리 하나는 "맞겠거니" 라고 생각했던 문제가 있었는데 74점인거 보면 아마도 그게 맞지 않았나 싶다. 실제 결과는 알수가 없지만..

그래서 예상을 하기에 66점으로 딱 pass하거나 떨어지면 근소한 차이로 또 떨어지겠거니 했는데 다행스럽게도 pass를 했다. 물론 만족할 만한 점수는 아니지만 그래도 붙어서 다행이다.

자격증을 땄다고 해서 그걸 잘 아는것은 아니기 때문에 앞으로도 더 공부를 해야 하겠지만 지난번 시험이후에 또 한가지 무언가를 했냈다는데에 큰 기쁨을 얻었다.