Summary 현재 Terraform으로 ECS 인프라를 생성하고, CircleCI에서 docker image를 빌드하고 ECR에 푸시하는 과정을 자동화하고 있다. 이 과정에 있어서 docker image를 빌드하는 것에서 문제가 발생했다. CircleCI에서 script를 실행하는 환경은 Container 기반으로 되어 있기 때문이다. Docker image를 빌드하기 위해서는 docker가 설치되어 있는 환경이어야 했다. docker-in-docker라는 개념으로 docker hub에 “docker"라는 docker image가 있다. 하지만 이 이미지로는 프로덕션 이미지를 빌드하고 배포할 때 사용하는 기본 패키지가 없는데, 이러한 기본패키지를 추가하여 CircleCI에서 docker를 빌드할 수 있는 이미지 생성하는 방법 및 CircleCI 설정을 정리해보았다. ...

Summary 2018년 AWSKRUG에서 8회에 걸쳐 진행하는 핸즈온 중 하나인 Serverless Hands-on 입니다 제목: 손쉽게 시작하는 Serverless Architecture 내용: Serverless Architecture는 말그대로 서버를 올리지 않는 아키텍처를 의미합니다. 기존에는 각 서버에 운영하는 어플리케이션들을 배포했지만, Serverless Architecture를 적용하면 운영 부담없이 비지니스 로직에만 집중할 수 있습니다. 서버없이 Web Application과 Crawler를 만들어 운영이 필요없는 데모 서비스를 구성합니다. Serverless Group First Hands-on Part 1 AWSKRUG Serverless Group의 첫번째 핸즈온 Part.1 웹어플리케이션 만들기입니다.😁 바로가기 Serverless Group First Hands-on Part 2 AWSKRUG Serverless Group의 첫번째 핸즈온 Part.2 웹크롤러 만들기입니다.😁 ...

Summary 개인용 개발계정, 회사계정, 워크샵 전용 계정 등등 여러 계정들을 사용하다보니 Default로 Access Key ID 와 Secret Access Key를 관리하고 싶어졌다. Default로 두고 사용하다가 잘못하면 회사계정에 잘못된 인프라를 생성 및 변경할 수도 있기 때문이다. AWS Configure –profile 기본적인 aws cli를 설정하는 것은 어렵지 않다. AWS Console의 IAM에서 유저를 생성하고 Access Key를 생성하면 된다. 생성된 키를 통해 로컬이 AWS의 권한을 사용하도록 설정하는 것은 다음과 같다. # 생성된 키와 리전을 입력하면 된다. $ aws configure AWS Access Key ID [****************aaaa]: AWS Secret Access Key [****************aaaa]: Default region name [ap-northeast-2]: Default output format [json]: 그렇다면 여러 계정을 관리하려면 어떻게 해야할까? ...

Summary 안드로이드 개발 언어의 트렌드는 바뀌었다. 최근 Google I/O에서 나오는 샘플 코드들은 Kotlin으로 짜여져 있었다. 또한 안드로이드 개발 컨퍼런스의 주제는 Kotlin으로 개발한 경험담이 주를 이루고 있다. Kotlin으로 개발하는 것이 낫다는 내용을 많이 보기도 하였고 개발에 욕심이 있다보니, 이번에는 기존에 JAVA로 개발되어 있던 코드에 Kotlin을 적용하여 새로 구성하거나 변경하는 클래스를 Kotlin으로 구성해보았다. 다음은 이런 과정을 거치면서 느낀 장점과 단점에 대한 고찰이다. 고찰 Kotlin의 장점을 느끼기 전에는 치명적인 단점(?)과 싸워야만 한다. 무엇보다 가장 크게 힘들었던 점은 손에 익은 Java 대신에 인내하며 억지로 Kotlin으로 작성해야된다는 점이었다. 개발자가 새로운 기술을 받아들여야 할 때 나타나는 문제점이었다. 기존에 잘하는 것으로 개발하면 바로 끝낼 수 있지만 새로운 것을 받아들이면 공부하고 적용하는데까지 시간이 몇배로 들기 때문이다. 이런 경우에 기술을 받아들일지는 상황에 따라 결정하게 된다. 상급자의 명령에 따라 빠른 퍼포먼스를 보여줘야하는 경우에는 기존의 기술을 택한다. 반면에 중간중간에 공부를 해두어서 적용할 수 있는 단계가 된 경우이거나 개발의 주체가 기술에 대한 욕심이 있고 새로운 것에 대해 무리없이 받아들이는 경우에는 새로운 기술을 택한다. 솔직히 후자라고 주장하고 싶지만 지난 몇번의 시도를 하였지만 다시 Java로 개발했었다. 편하게 살고싶은 마음을 이겨내는 것이 제일 힘들었다. ...

Summary If you’re a lazy JAVA developer, you concatenate Strings by using the plus sign (“Some text” + " added text") But if you want to level-up your skills as a JAVA developer, you should be more careful about the Class that you choose. Let’s take a glance at the use cases of String, StringBuilder and StringBuffer. Feature of Classes It’s necessary to be familiar with the Java API documents before getting your hands dirty. ...

Summary 현재 공통적인 모듈을 Git으로 따로 관리하여 npm private module로 사용한다. 또한 Webpack을 사용하여 Typescript로 작성된 서버를 번들링한다. 로컬에서는 모두 정상적으로 동작하지만 CircleCI에서 빌드할 경우에는 CircleCI의 권한이 해당 repository에 대한 권한만 가지고 있기 때문에 npm private module을 가져올 수가 없다. 이와같은 문제를 해결하기 위해서 트러블 슈팅을 하였다. Problem npm install을 할 때에 github에 있는 repository를 사용하는 방법은 두가지가 있다. https ssh ssh로 사용할 경우 관련 명령어는 다음과 같다. # ssh 키 생성하기 $ ssh-keygen -f id_rsa_kh -C "" # 생성한 키를 ~/.ssh 에 추가하기 $ cp id_rsa_kh ~/.ssh/id_rsa_kh # 생성한 키의 권한 수정하기 $ chmod 600 ~/.ssh/id_rsa_kh # 생성한 키의 퍼블릭 키를 출력하기. 이때 받은 키를 github private repo에 ssh키를 추가하여야 한다. $ cat id_rsa_kh.pub # ssh의 개인키 개수 확인하기 $ ls -al ~/.ssh/ # ssh-agent 실행하기 $ eval "$(ssh-agent -s)" # ~/.ssh 디렉터리에 있는 개인키를 모두 ssh agent에 등록하기 $ grep -slR "PRIVATE" ~/.ssh/ | xargs ssh-add # 현재 등록되어 있는 ssh key의 fingerprint 확인하기 $ ssh-add -l -E md5 위와 같이 키를 입력하였으면 이제 npm install을 해본다. ...

Summary 각 사용자들의 연관 관계 분석을 위하여 GraphDB를 도입하려한다. 시작하기에 앞서서 GraphDB에 대해서 이해가 필요했다. 다음에서 GraphDB의 기본 내용을 담았다. Graph Database란? In computing, a graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation. ...

문제인식 서비스가 성장해가면서 기존에는 보이지 않던 문제점들이 나타났다. 처음에는 Slow query의 최적화를 필요로하지도 않았고, DB에 부하가 몰려서 Bottle neck point가 되는 것을 상상만 했지 직접 경험하지는 못했었다. 하지만 점차 Query의 optimization이 필요한 경우가 생겼고, DB로 몰리는 부하를 분산하기 위해 어떻게 처리해야하는지 고민하기 시작했다. Cache me if you can 다행히도 AWSKRUG활동을 하면서 AWS re:Invent행사에 참석한 경험이 도움이 되었다. 들었던 세션중에서 가장 감명깊은 것중에 하나는 “Cache me if you can"이었다. 주된 내용은 점차 서비스가 커져감에 따라서 우린 Database로 몰리는 부하를 분산시켜야만 하고, 그것을 해결하기 위해서는 각 요청에 따라 Cache로 처리할 수 있는 부분은 모두 Cache로 해결해야 된다는 내용이었다. ...

Summary AWS Lambda와 API Gateway를 연동하여 웹서버를 Serverless architecture로 운영하고 있다. 관리할 서버가 없고 비지니스 로직에만 집중할 수 있어서 좋기도 하지만 항상 Lambda container가 대기중인 상태가 아니다 보니 Cold start관련하여 요청사항이 발생했다. 일정시간이 경과된 후에 해당 페이지를 접속할 경우에 로딩이 3~4초이상 걸리기 때문에 사용이 불편하였다. 이를 해결하기 위해 5분마다 각 api를 health check하는 scheduler를 두기로 결정하였다. 그렇게되면 지속적인 lambda 호출로 인해 항상 하나이상의 lambda container가 대기하는 형태가 되어 lambda의 cold start의 가장 큰 시간을 소비하는 DB connection의 시간을 느낄 수 없다. ...

Summary MySQL에서 Max Connection에 대해서 알아보려고 한다. AWS Lambda container가 지속적으로 생성될 때 Database가 감당할 수 있는 Max connection이 얼마인지 알아야 대응할 수 있기 때문이다. 만약 Lambda container가 MySQL이 감당할 수 없을 정도로 계속 생성된다면 Database에 connection이 일어나지 않게 되고, too many connections error가 발생하여 웹서버 역할을 해야하는 Lambda가 동작하지 않을 수 있다. 물론 MySQL에 접속하는 다른 Worker들도 동작하지 않는다. RDS를 사용하면 스케일 업이 될 때마다 Max connection 설정을 따로 하지 않더라도 알아서 늘어난다. 별다른 고민할 것 없이 Max connection이 생길 때마다 RDS를 scale up 해주어도 되겠지만 개발자이기 때문에 더 Graceful하게 문제를 해결해야한다. ...