live the life you love

신입 취준의 끝. 19년 하반기부터 21년 상반기까지

돌돌김 — Thu, 22 Jul 2021 02:16:17 +0900

신입 취준의 끝

졸업 후 약 1년 6개월만에 크래프톤에 최종 합격하게 되어 신입 취준을 끝냈다. 6개월 간의 교육과 1년간의 중소기업 생활을 거친 뒤 이직하게 되었다.

원티드로 지원하여 합격 화면 같은게 없다.

전체 지원 이력

약 2년간의 취준생활을 하며 총 36번의 신입 서류지원(ssafy제외)을 하였고 11번의 서류 합격을 했다. 주로 대기업 SI를 하는 회사 위주로 넣었다. 당시 SI 위주로 넣은 이유는 개인적으로 생각하기에 네카라 같은 서비스 회사를 가기에는 실력이 좀 부족하다고 판단을 한 것 같다.

카카오, 라인, 네이버 등 서류를 쓰지 않고 코딩테스트 응시 기회를 주는 회사에도 지원을 했지만 전부 코테에서 떨어졌으므로 서류지원 카운트에는 넣지 않았다.

19년도 하반기

미흡한 코테 준비

서류는 가장 많이 붙었지만, 코테 준비가 하나도 되어있지 않아서 면접 한 번 못가본 시기이다. 사실, 19년도 상반기에 SK C&C 채용형 인턴을 하였지만, 전환이 되지 않아서 멘탈이 가장 많이 흔들리던 시기였다.

SK에서 인턴을 하였지만 지원하는 직무와 관련이 없는 것을 하여 실질적인 도움은 되지 않았다. 단지 이력서에 한 줄 추가하는 정도였다
카카오톡 오픈채팅방에서 알고리즘 관련 채팅방, 취준방에 처음으로 들어갔다
어떻게 해야할 지 잘 모르는 시점이었는데 많은 도움을 받았다

지원한 모든 기업에서 탈락하고, 우연히 자소설 닷컴에서 본 멀티캠퍼스 국비교육과정을 신청하여 12월부터 6개월 간 진행하는 교육과정을 시작하였다.

20년도 상반기

국비 교육 수강

멀티캠퍼스에서 운영하는 '클라우드 기반의 MSA 전문가 양성과정'을 수강하였다. 싸피 서류탈락을 해서 국비 지원 마감 2일전에 수강신청을 하였는데 좋은 선택이었던 것 같다.

대부분의 국비 교육이 좋지 못한 평을 듣는다. 그 이유는 트렌드에 맞지 않는 교육과정, 대충 가르치는 강사, 웹 에이전시 or 중소 SI 연계 등 안좋은 점이 많기 때문이다. 하지만 다행스럽게 내가 들은 교육과정은 커리큘럼도 좋았고 많은 걸 배울 수 있었다. 배운 기술 스택은 다음과 같다.

프론트엔드 : React, JS
백엔드 : Java, SpringBoot
클라우드, 인프라 : Docker, AWS, Docker Swarm

또한 팀운도 많이 따랐다. 팀원들의 실력도 좋았고 전부 열심히 참여해주었다. 덕분에 최종 팀 프로젝트에서 1위를 할 수 있었다.

팀원들과 백준 스터디도 같이 하며 알고리즘 공부를 가장 많이 했을 시기이다. 팀원들 전부 나보다 코테도 잘해서 배울 점이 많았다.

교육이 끝나고 약 1주일 뒤, 교육에 멘토로 참여했던 분에게 본인 회사에서 일해보지 않겠냐는 제의가 왔다. 마침 상반기도 다 떨어진 상태인터라 돈 받고 공부한다는 마인드로 다녀보기로 결심했다.

20년도 하반기

6개월 간의 인턴

면접에서는 MSA 관련한 업무를 한다고 했는데, 막상 가보니 회사에 Java를 할 줄 아는 사람이 없어서 Java 코드로 되어있는 프로젝트의 해외 인증을 받는 업무를 담당하게 되었다.

급여 또한, 내채공이 포함된 액수로 말했었다. 심지어 인턴 기간도 6개월 이었다;

해당 코드를 개발한 담당자와 유선으로 연락을 해가며 막히는 부분을 고쳐나갔고, 2개월 뒤 프로젝트에 필요한 인증을 받을 수 있었다.

하지만 그 후가 문제였다. 인증을 받고나니 프론트 작업을 시켰다. 국비 때 잠깐 리액트를 배웠지만 프론트는 잘 맞지 않아서 하기 싫었는데 어쩌다보니 프론트 작업을 하게 되었다.

프론트 하기 싫음과 못함이 합쳐져 결국 해당 작업은 다른 사람이 맡게 되었고, 기존에 사내 클라우드를 담당하던 인력이 외부 프로젝트를 계속 나가게 되어 사내클라우드를 맡게 되었다. 제대로 인수인계는 없어서.. 그냥 혼자 공부하는 시간이 대부분이었고 코로나도 심해지며 시간이 붕 뜨게 되어 방황하는 하반기를 보냈다.

이직 준비

이 당시에는 사실 돈이 중요한게 아니었다. 거의 최저시급 수준인 월 200을 받았지만 업무량이 별로 많지 않았고, 열심히 준비 해서 2년 내로 이직한다. 라는 마인드가 강하게 박혀있어서 퇴근 후 코테 준비와 면접 준비를 열심히 했다.

회사를 다니며 이직 준비하는 것이 쉽지만은 않았다. 퇴근하고 집에와서 밥먹으면 거의 9시가 되었다. 소화 시키고 좀 쉬다보면 금새 11시, 12시가 되었고 그때 부터 새벽 2~3시까지 공부했던 적이 많았다. 회사 출근이 10시까지라서 아침에 너무 일찍 일어나지 않아도 괜찮았기 때문에 늦게까지 공부할 수 있었던 것 같다.

혼자하다 보면 의지가 약해지는 시기가 온다. 그럴 때는 코테, CS 관련 스터디를 운영하기도 하고 참여하기도 했다. 대략 4~5개 정도의 스터디를 했던 거 같다.

2곳의 면접, 그리고 최종 탈락

회사를 다니며 백준, 프로그래머스를 풀며 준비는 할 수 있었지만 자기소개서를 쓰는게 여간 힘든 것이 아니었다. 특히, 기존에 써오던 자소서에 현재 진행형인 회사 업무를 녹여내야 했기에 거의 모든 자소서를 새로 써야했다. 그러다 보니 많은 곳에 지원하지는 못했고 대부분 기존에 지원했던 회사들 위주로 많이 지원했다.

서류와 코테를 모두 마치고 최종적으로 SK C&C와 현대 IT&E 두 곳의 최종면접을 보게 되었다.

현대 IT&E는 실무면접, 임원면접의 형식으로 2번의 면접을 진행하였으며 1차 실무면접은 합격을 했다.
SK C&C의 경우 원데이 면접으로 직무 + 협상 면접을 진행하였다.

우선, 현대 IT&E 경우 실무 면접을 그렇게 잘봤다는 생각을 못했는데, 합격을 했다. 하지만 화상으로 진행되는 임원면접이 음성도 잘 안들리고 매끄럽게 진행되지 못한 부분이 많았다. SK C&C의 경우 실무 면접과 협상면접 둘 다 잘 봤다는 생각이 들었다.

역시.. 잘 봤다는 느낌이 들면 떨어진다. IT&E의 경우 대답을 잘 못한 부분이 있었지만, 특별히 못한 부분도 없었다. 하지만 IT&E는 최종 면접으로만 뽑지 않고 이전 전형의 점수도 합한다고 들었다. 코테도 1문제였나 못푼게 있었고 실무 면접도 가까스로 통과했던 것 같아서 최종 합산에선 점수가 부족했을 것 같다.

C&C에서 탈락한 이유는 아직도 잘 모르겠다. 면접 질문에 대부분 잘 대답했다고 생각했는데, 아쉬웠다. 아마 답을 틀리게 한 부분이 있었을 것이다.

그렇게 20년도의 취준도 마무리가 되었다.

21년도 상반기

DevOps의 시작

21년이 되고, 회사에서 애매한 직무에 있던 상황이었는데 클라우드 관련한 업무를 맡게되며 쿠버네티스를 공부하기 시작했다. 당시 Docker Swarm으로 되어있는 환경을 K8s로 전환하는 과정이었는데 그 과정을 같이 하게 되었다.

사실 쿠버네티스는 인강을 보며 공부만 하였다. 기존 리소스를 K8s로 마이그레이션 하는데 필요한 도메인 지식이 부족하여 실질적인 작업은 하지 못했다.
K8s 대시보드를 위해 Rancher를 설치하고 Azure AD 연동을 했다.

또한, 사내 CI/CD 구축을 담당했다. 기존까지는 제대로 갖추어지지 않아 수동으로 배포 하고 있었다. 이를 조금이나마 자동화 하려고 했다.

Jenkins, ArgoCD를 구축했다.
GitLab 레파지토리와 연동하여 코드가 푸시되면 빌드가 되게끔 하였다.

모니터링도 달아보았다. 다양한 오픈소스 중 많은 회사에서 사용하는 Promethus와 Grafana를 활용하였다.

마지막으로 IaC를 끄적여보았다. IaC는 정말 Azure Docs를 따라하며 Terraform 기본 인프라만 구성해보았다

최종적으로 약 4개월 간 DevOps 겉핥기 정도의 업무를 수행하였다. 어디까지나 돌아가게 구축만 해놓은 상태라 제대로 배포 자동화까지 이뤄지지는 못했다. 깊이 있는 업무를 수행하지 못한 아쉬움이 있다.

첫 수시채용 지원

하반기에 비해 상대적으로 적은 채용과 코로나가 겹쳐져서 상반기는 많은 공고가 없었고, 대부분 수시채용으로 바뀌어서 많은 지원을 하지는 못했다.

이 때 ,원티드를 처음으로 활용하였다. 원티드를 사용한 이유는 지원 양식이 사람인, 잡코리아 등등과 달리 깔끔한 형식으로 내가 실제 했던 업무들을 개조식으로 예쁘게 적을 수 있고 클릭 몇 번으로 지원 되는 점이 편했다.

작년까지 지원한 백엔드 개발 보다는 DevOps 관련 직무가 보이면 지원을 하였다. 하지만 DevOps 직군은 대부분 경력을 요구하므로 마땅히 넣을 공고가 많지는 않았다.

그러던 중 우연히 크래프톤의 공고를 보았는데 경력 무관이라는 말에 바로 지원을 했다. 항상 공채만 지원했었고 수시채용은 처음이라 큰 기대를 하지 않고 면접 경험만이라도 쌓아보자는 마음으로 지원했다

떨어진 줄 알았던 직무 면접

DevOps 직군으로 처음 지원한 면접이었기에, 좋은 회사의 면접은 어떤게 나올까? 면접을 통해 많이 배워야겠다 라는 마음가짐이었다. 게임회사의 면접은 처음이라 공고에 써있는 기술, CS 위주로 많이 공부했다. 특히 OS와 네트워크 부분을 많이 보았다.

운영체제는 유튜브 강의를 많이 보았다. 특히 출퇴근 시간에 계속 들으며 다녔다.

네트워크는 우테톡의 영상을 많이 참고하였고, 면접 빈출 질문을 공부하였다.

OSI 7 Layer

실무 면접은 대면면접이었다. 서초 오피스에서 이루어졌고, 2시간 동안 진행되었다. 면접 일자와 시간을 선택할 수 있었다.

1시간 동안 CS 관련한 서술형 질문을 풀고, 그 후 1시간 동안 실무 면접을 보았다.
CS 질문은 대학교 전공 시험 같았고 실무 면접은 해당 답을 왜 그렇게 적었는지 부터 시작해서 밑바닥 까지 파고드는 질문이 주를 이루었다.
이직을 하는 것이기 때문에 왜 이직하려는지에 대한 질문이 들어왔다.
혼자서 하다보니 한계가 많이 느껴졌고, 관련 직무를 같이 하는 사람들이 많은 환경에서 성장하고 싶다고 답했다.

경력이 길지 않았기에, 기존 회사에서 진행한 프로젝트 보다는 CS위주로 많은 질문이 들어왔다. DB와 멀티프로그래밍 관련한 질문에 대해 답을 잘 하지 못했다.

약 2주 정도 뒤, 합격 메일을 받았다.

임원 면접은 화상으로 진행되었고 1시간 이었는데, 30분만에 끝나버렸다.

임원면접은 주로 '이 직무를 왜 지원했는지'가 주된 질문이었다.
나의 경우, 해당 직무에 관심을 갖는 계기가 명확한 부분이 있어서 어필이 잘 된 것 같다.

마치며..

처음으로 지원한 게임회사, 처음으로 지원한 DevOps 직군에 합격을 해버렸다.

아직 한 달도 채 되지 않았지만, 정말 배울게 많고 팀 동료분들 실력도 뛰어나서 출근하는게 즐겁다. 이전 회사에서 채우고 싶었던 욕구들이 많이 충족되고 있다.

앞으로도 더 열심히 공부하고 업무를 하며 6개월 뒤, 회고록을 쓸 시점에는 업무적으로 많은 성장을 해있기를 바란다.

[Terraform] merge를 사용하여 변수 합치기

돌돌김 — Tue, 20 Jul 2021 21:28:44 +0900

AWS 태그와 같이 map 타입의 리소스에서 1개의 값만 바꾸고 싶을 경우가 있다. 예를 들어, default_tag를 다음과 같이 정의할 수 있다.

# vars.tf
variable "default_tags" {
  type = map(string)
  default = {
    Name = "resource_name"
    Owner = "doldol-dev"
    Author = "doldol@naver.com"
    Phase = "dev"
  }
}

생성할 AWS 리소스에 위의 태그를 똑같이 활용해야 하는데, 리소스 별로 Name 값만 다르게 하려면 아래와 같이 할 수 있다.

local 변수에 바꾸려는 값만 정의한다.
바꾸려는 값과 기존의 값을 merge 한다.
- 이때, default 값이 무조건 앞에 들어가야한다. merge 함수의 특징상 뒤에 오는 파라미터가 앞의 파라미터를 덮어쓰기 때문이다.
해당 태그가 필요한 리소스에 merge된 값을 넣는다.

# main.tf
locals {
  state_tags = {
    Name = "doldol-tfstate"
  }
  tags_merge = merge(var.default_tags, local.state_tags)
}

resource "aws_s3_bucket" "tf-state" {
  bucket = "doldol-tf-state-bucket-test"
  acl = "private"
  versioning {
    enabled = true
  }

  tags = local.tags_merge

  lifecycle {
    prevent_destroy = true
  }
}

terraform plan을 보면 다음과 같다.

# aws_s3_bucket.tf-state will be updated in-place
  ~ resource "aws_s3_bucket" "tf-state" {
        id                          = "doldol-tf-state-bucket-test"
      ~ tags                        = {
          + "Author"    = "doldol@naver.com"
          ~ "Name"      = "doldol-tf-state" -> "doldol-tfstate"
          + "Owner"     = "doldol-dev"
          + "Phase"     = "dev"
        }
      ~ tags_all                    = {
          + "Author"    = "doldol@naver.com"
          ~ "Name"      = "doldol-tf-state" -> "doldol-tfstate"
          + "Owner"     = "doldol-dev"
          + "Phase"     = "dev"
        }
        # (9 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

AWS CLI Configure 설정 (Ubuntu 20.02, WSL2 사용)

돌돌김 — Wed, 14 Jul 2021 15:46:10 +0900

AWS에 리소스를 배포하기 위해 콘솔에서 GUI로 작업할 수도 있지만, cli를 활용하여 구성하는 것이 편할 때가 있다.

또한, Terraform을 사용하는 경우에는 AWS CLI가 필수이다.

가장 기본이 되는 AWS 공식 문서는 아래와 같다.

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-configure-files.html

구성 및 자격 증명 파일 설정 - AWS 명령줄 인터페이스

이러한 설정은 전적으로 선택 사항입니다. 이러한 설정을 구성하지 않고도 aws s3 이전 명령을 성공적으로 사용할 수 있어야 합니다. 이러한 설정은 성능을 조정하거나 aws s3 명령을 실행 중인 특

docs.aws.amazon.com

액세스 키 발급

우선 콘솔에서 작업해야하는 순서는 다음과 같다.

aws 콘솔 로그인 -> 내 보안 자격증명 -> CLI, SDK 및 API 액세스를 위한 액세스 키 에서 액세스 키 만들기를 클릭한다.

이 때, 발급되는 key값은 따로 저장해두거나 복사해둬야 한다.

AWS CLI 설치

aws cli는 별도의 설치 과정이 필요하다. 아래 문서에 잘 나와있으니 OS에 맞게 설치하면된다. WSL2 환경의 경우 Linux가이드를 참고하면 될 것이다.

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/install-cliv2.html

AWS CLI 버전 2 설치, 업데이트 및 제거 - AWS 명령줄 인터페이스

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

설치가 완료되면 터미널에 aws --version 입력하여 정상적으로 출력이 되는 지 확인한다.

doldol@doldol-w$ aws --version
aws-cli/2.2.14 Python/3.8.8 Linux/5.4.72-microsoft-standard-WSL2 exe/x86_64.ubuntu.20 prompt/off

AWS Configure 설정

이제, 사용자의 계정과 발급받은 액세스 키를 넣어줄 차례다. 폴더를 보면 .aws라는 폴더가 있고 그 안에 config 파일과 credentials 파일이 있을 것이다. config 파일에는 profile의 정보가 담기고 credentials에는 access key와 secret 정보가 담긴다.

혼자서 하나의 계정만 관리하는 경우에는 default 로 설정을 해도 되고 다른 이름으로 설정하는 경우 별도의 이름을 줄 수 있다.

터미널에서 aws configure 명령어를 입력한 뒤 Access Key ID에는 엑세스 키 ID를, Secret Access Key에는 복사해둔 키를 입력한다. region은 원하는 리전 이름을 아무거나 하면 된다. ex) ap-southeast-1

$ aws configure
$ AWS Access Key ID [****************6FN4]:
$ AWS Secret Access Key [****************lX64]:
$ Default region name []:

AWS CLI에서 프로파일 사용

터미널에서 vi ~/.bashrc 를 입력한 뒤 맨 밑으로 가서 export AWS_PROFILE=doldol 을 입력하고 빠져 나온 뒤 source ~/.bashrc 로 적용을 해준다. aws cli 명령을 할 때마다 --profile 을 넣어주는 것은 번거롭기 때문에 basrch 파일에 환경변수로 넣어놓으면 편리하게 사용 가능하다.

# 1) .bashrc에 접속
$ vi ~/.bashrc

# 2) .bashrc에 추가
export AWS_PROFILE=doldol

# 3) .bashrc 설정 적용
source ~/.bashrc

Jenkins Plugins 최신으로 업데이트 하기(ex, Token Macro Plugin)

돌돌김 — Mon, 24 May 2021 17:44:38 +0900

Jenkins Plugin의 버전이 낮아서 가끔 문제가 생기는 경우가 있다. Microsoft Teams에 Webhook을 보내기 위해서는 Token Macro Plugin이 설치되어 있어야 하고, 버전이 2.13이어야 한다.

지금은 업데이트 되어서 2.15로 보이지만, 원래는 2.13만 나와있고 2.15로 업그레이드 하게 해주는 버튼이 활성화 되지 않았다.

이를 업데이트 하기 위해서는 수동으로 플러그인을 다운받아서 업데이트 해줘야 한다.

아래 사이트는 jenkins 플러그인의 최신버전을 다운 받을 수 있는 주소이다. 여기서 업데이트 하려는 플러그인을 검색한 뒤, .hpi 확장자를 가진 파일을 다운 받는다.

https://updates.jenkins.io/experimental/latest/

Permalinks to latest files

updates.jenkins.io

다운 받은 뒤, Plugin Manger의 고급 탭에 들어가 다운받은 플러그인을 올린다

Jenkins를 재시작하면 새로운 버전으로 업데이트 된 플러그인을 볼 수 있다.

[BOJ 백준, 삼성 SW 역량 테스트 기출 문제] 20058번 : 마법사 상어와 파이어스톰 Python, 파이썬)

돌돌김 — Thu, 25 Mar 2021 02:48:48 +0900

www.acmicpc.net/problem/20058

20058번: 마법사 상어와 파이어스톰

마법사 상어는 파이어볼과 토네이도를 조합해 파이어스톰을 시전할 수 있다. 오늘은 파이어스톰을 크기가 2N × 2N인 격자로 나누어진 얼음판에서 연습하려고 한다. 위치 (r, c)는 격자의 r행 c

www.acmicpc.net

DFS 함수에서 재귀가 터져서 sys.setrecursionlimit을 사용했다. 실제 삼성 코딩테스트에서는 sys 라이브러리를 사용할 수 없으니, DFS를 재귀로 짜지 않고 스택으로 짜거나 BFS로 대체하여 풀어야 할 듯 하다.

회전하는 부분을 제대로 구하지 못해서 다른 블로그 글을 참조했다. 리스트의 회전은 어렵다..

소스코드

import sys, copy
sys.setrecursionlimit(10 ** 5)
dy = [-1,1,0,0]
dx = [0,0,-1,1]

visited = set()

def maxIce(y, x):    
    visited.add((y, x))
    ret = 1
    for k in range(4):
        ny = y + dy[k]
        nx = x + dx[k]
        if 0<= ny < 2**N and 0 <= nx < 2**N:
            if (ny, nx) not in visited and board[ny][nx] > 0:
                ret += maxIce(ny, nx)   
    return ret

def melt():
    melt_ice = []
    for y in range(2**N):
        for x in range(2**N):
            ice = 0
            if board[y][x] == 0: 
                continue
            for k in range(4):
                ny = y + dy[k]
                nx = x + dx[k]
                if 0 <= ny < 2**N and 0 <= nx < 2**N :
                    if board[ny][nx] >= 1:
                        ice += 1
            if ice < 3:
                melt_ice.append([y, x])
    
    for y, x in melt_ice:
        board[y][x] -= 1
    return

def rotate(L):
    global board
    K = 2**L
    for i in range(0,2**N, K):
        for j in range(0, 2**N, K):
            new_board = [board[r][j:j+K] for r in range(i, i+K)]
            for y in range(K):
                for x in range(K):
                    board[i+x][j+K-1-y] = new_board[y][x]                
    return

N, Q = map(int, input().split())
board = [list(map(int, input().split())) for _ in range(2**N)]
magic = list(map(int, input().split()))

for L in magic:
    rotate(L)
    melt()

# 남아있는 얼음의 총합
sumOfIce = 0
for i in range(2**N):
    for j in range(2**N):
        sumOfIce += board[i][j]

# 남아있는 얼음 중 가장 큰 덩어리가 차지 하는 칸의 개수
maxOfCnt = 0
cnt = 0
for y in range(2**N):
    for x in range(2**N):        
        if (y, x) not in visited and board[y][x] > 0:   
            maxOfCnt = max(maxOfCnt, maxIce(y, x))

print(sumOfIce)
print(maxOfCnt)

[BOJ 백준] 20056번 : 마법사 상어와 파이어볼 (Python, 파이썬)

돌돌김 — Thu, 25 Mar 2021 02:43:37 +0900

www.acmicpc.net/problem/20056

20056번: 마법사 상어와 파이어볼

첫째 줄에 N, M, K가 주어진다. 둘째 줄부터 M개의 줄에 파이어볼의 정보가 한 줄에 하나씩 주어진다. 파이어볼의 정보는 다섯 정수 ri, ci, mi, si, di로 이루어져 있다. 서로 다른 두 파이어볼의 위치

www.acmicpc.net

문제에서 구현하라는 대로 푸는 전형적인 시뮬레이션 문제였다. 하지만, 시간이 3980ms로 가까스로 TLE를 면한듯 하다.

같은 칸에 파이어볼이 여러개 있을 수 있으므로 board 안에 deque를 넣어서 파이어볼이 추가로 들어오면 append 시켜줬다.

소스코드

import sys, copy
from collections import deque

dy = [-1, -1, 0, 1, 1, 1, 0, -1]
dx = [0, 1, 1, 1, 0, -1, -1, -1]

n, m, k = map(int, input().split())
board = [[deque() for _ in range(n)] for _ in range(n)]

for i in range(m):
    r, c, m, s, d = map(int, input().split())
    board[r-1][c-1].append([m, s, d])

for _ in range(k):    
    # 이동하는 중에는 같은 칸에 여러 개의 파이어볼이 있을 수도 있다.
    new_board = [[deque() for _ in range(n)] for _ in range(n)]
    for i in range(n):
        for j in range(n):
            while len(board[i][j]) > 0: # 이 부분이 if로 되어 있어서 파이어볼을 1개만 처리했었다
                next_y, next_x = i, j
                cur_m, cur_s, cur_d = board[i][j].popleft()
                next_y = (next_y + (cur_s * dy[cur_d])) % n
                next_x = (next_x + (cur_s * dx[cur_d])) % n
                new_board[next_y][next_x].append([cur_m, cur_s, cur_d])
    board = copy.deepcopy(new_board)    
    # 이동이 모두 끝난 뒤, 2개 이상의 파이어볼이 있는 칸에서는 다음과 같은 일이 일어난다.
    for i in range(n):
        for j in range(n):
            isEven, isOdd = False, False 
            sumMass, sumSpeed = 0, 0 # 합쳐진 파이어볼의 질량, 속도
            newMass, newSpeed = 0, 0 # 나누어져 새로 만들어진 파이어볼의 질량, 속도
            if len(board[i][j]) >= 2:                
                lenBall = len(board[i][j])
                while board[i][j]:
                    curMass, curSpeed, curDir = board[i][j].popleft()
                    sumMass += curMass
                    sumSpeed += curSpeed
                    if curDir % 2 == 0:
                        isEven = True
                    else:
                        isOdd = True           
                newMass = sumMass // 5  # 질량은 ⌊(합쳐진 파이어볼 질량의 합)/5⌋이다.
                newSpeed = sumSpeed // lenBall # 속력은 ⌊(합쳐진 파이어볼 속력의 합)/(합쳐진 파이어볼의 개수)⌋이다.
                if newMass == 0:    # 질량이 0인 파이어볼은 소멸되어 없어진다.
                    continue
                # 파이어볼은 4개의 파이어볼로 나누어진다.
                # 합쳐지는 파이어볼의 방향이 모두 홀수이거나 모두 짝수이면, 방향은 0, 2, 4, 6이 되고, 그렇지 않으면 1, 3, 5, 7이 된다.
                if isEven == True and isOdd == True: # 방향이 홀수, 짝수가 섞여 있음 -> 방향이 1, 3, 5, 7
                    for newDir in range(1, 8, 2):
                        board[i][j].append([newMass, newSpeed, newDir])
                else:
                    for newDir in range(0, 8, 2):
                        board[i][j].append([newMass, newSpeed, newDir])           

answer = 0
for i in range(n):
    for j in range(n):
        if len(board[i][j]):
            for ball in board[i][j]:
                answer += ball[0]

print(answer)

[Kubernetes] .kube/config 수정하기(삭제)

돌돌김 — Wed, 24 Mar 2021 18:56:45 +0900

현재 설치된 Kubernetes Cluster의 정보, context, user의 정보가 Config map으로 .kube/config에 저장되어 있다.

유저를 추가하거나, 클러스터를 추가하면 해당부분에 자동으로 추가가 된다.

더이상 안쓰는 클러스터, 유저를 삭제하려면 아래와 같은 명령어로 삭제가 가능하다. config파일은 굳이 수동으로 지우는것은 권장되지 않는다.

kubectl config unset PROPERTY_NAME [options]

# 클러스터 삭제(실제로 삭제는 아니고 여기서 연결을 끊는 것)
kubectl config unset clusters.cluster_name

# 컨텍스트 삭제
kubectl config unset contexts.context_name

# 유저 삭제
kubectl config unset users.user_name

[CKA 준비] yaml 생성 템플릿 명령어

돌돌김 — Sun, 21 Mar 2021 03:05:32 +0900

Create an NGINX Pod

kubectl run nginx --image=nginx

Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

kubectl run nginx --image=nginx --dry-run=client -o yaml

Create a deployment

kubectl create deployment --image=nginx nginx

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run) with 4 Replicas (--replicas=4)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Service와 Pod연결해서 생성하기, yaml 파일 생성하지 않고 테스트로 보기

kubectl run httpd --image=httpd:alpine --port 80 --expose --dry-run=client -o yaml 

# 실제 생성 할 때
kubectl run httpd --image=httpd:alpine --port 80 --expose                          
service/httpd created
pod/httpd created

명령어 정리

# 오브젝트에 대해 모든 네임스페이스에서 검색
kubectl get pods --all-namespaces

[Kubernetes Study - 11] Pod - Qos(Quality of Service) Class

돌돌김 — Mon, 22 Feb 2021 17:13:42 +0900

Pod의 남은 리소스가 부족한 경우, Pod는 다운되버린다. 하지만 Pod는 중요도가 각기 다르기 때문에, 중요한 Pod가 죽어버리면 서비스에 큰 문제가 생길 수 있다. 그렇기 때문에 상대적으로 중요도가 낮은 다른 Pod를 down 시키고 그만큼의 리소스를 중요도가 높은 Pod에 할당 할 수 있다.

쿠버네티스가 Pod를 생성할 때 다음의 3가지 QoS 클래스 중 하나를 할당한다. 각각을 명시적으로 설정할 수는 없고 컨테이너에 정의된 resources의 request, limits에 따라 쿠버네티스가 알아서 클래스를 적용해주는 것이다.

Guranteed(가장 나중에 삭제)

모든 Container에 Request와 Limit가 설정되야 한다.
Request와 Limit에는 Memory와 CPU가 모두 설정되야 한다.
각 Container 내에서 Memory와 CPU에 대한 Request와 Limit 값이 같아야 한다.

Burstable

모든 컨테이너에 Request와 Limit가 설정되어 있지만, Request와 Limit에 할당한 memory와 cpu의 값이 서로 다른 경우
Request만 설정되어있고, Limit는 설정해놓지 않은 경우
Pod의 컨테이너가 2개인데, 1개의 컨테이너에만 Request, Limit를 완벽하게 설정하고 나머지 하나의 컨테이너에는 설정하지 않은 경우
- Request, Limit가 설정된 컨테이너는 Memory와 CPU에 대한 Request와 Limit 값이 같아야 한다.

BestEffort(가장 먼저 삭제)

어떤 Container내에도 Request와 Limit를 설정하지 않은 상태

OOM(Out of Memory) Score

Burstable 상태에서 어떤 Pod가 먼저 Down되야 할지를 정하는데, OOM Score를 활용한다.
OOM Score를 측정하는 방법은, 실제 어플리케이션이 사용하는 메모리 대비 Request 메모리가 몇퍼센트인지 비율로 계산한다.
예를 들어, 2개의 Pod에서 돌아가는 어플리케이션은 둘 다 4GB인데, Request Memory가 각각 5GB, 8GB라면, 사용량은 75%, 50%이다.
- 이런 경우 OOM Score가 높은(사용량이 높은 Pod) Pod가 먼저 제거된다.

[Kubernetes Study - 10] Pod - readinessProbe, livenessProbe

돌돌김 — Mon, 22 Feb 2021 16:34:10 +0900

Pod의 기본적인 라이프 사이클

Pending → Running → Succeeded → Failed

Pending : 파드가 쿠버네티스 클러스터에서 승인되었지만 아직 컨테이너가 설정되지 않았음. 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함

Probe

Probe의 상태 : Success, Failure, Unknown

startupProbe : 어플리케이션이 시작 되었는지를 판단

startupProbe를 세팅한 경우, startupProbe가 OK신호를 보내줘야 readinessProbe 와 livenessProbe가 돌아간다.

readinessProbe : 컨테이너가 요청을 처리할 준비가 되었는지

Pod가 새로 배포되고 Running 상태여도 그 안에 있는 컨테이너에서 배포되는 어플리케이션도 재시작하고 구동하는데 걸리는 시간이 있기 때문에, 이 시간 동안은 어플리케이션에 접속을 하려고 하면 오류가 발생한다.

이를 막기 위해, ReadinessProbe가 어플리케이션이 구동되기 전까지는 서비스와 연결되지 않게 해준다. ReadinessProbe가 성공하기 전까지는 Pod가 Running 상태여도 ConainerReady, Ready가 false로 유지된다. 이렇게 false 상태로 유지되면 Service의 엔드포인트에서는 NotReadyAddr로 간주하여 Service에 연결하지 않는다.

successThreshold의 값에 맞는 성공 횟수를 반환하면 true가 되면서 Service에서 Endpoint의 연결이 정상적으로 동작한다.

기본 상태는 Success이다. 실패 시, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스의 엔드포인트에서 파드의 IP주소를 제거한다.

주기적으로 호출되며 특정 파드가 클라이언트 요청을 수신할 수 있는지를 결정한다. 성공을 반환하면 컨테이너가 요청을 수락할 준비가 된 것이다.

livenessProbe : 애플리케이션의 내부 상태를 체크(서버가 제대로 응답하는지, 컨테이너가 제대로 동작중인지)

Pod는 Running 상태이지만, 어플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지한다.(ex, 메모리 오버플로 등) 문제를 감지하면 Pod를 재실행하게 만들어서 어플리케이션의 문제를 해결한다.

LivenessProbe는 비교적 자주 실행되야 하기 때문에 너무 많은 연산 리소스를 사용하면 안되고, 1초 내에 완료되야 한다.

기본상태는 Success이다. 실패한다면 kubelet이 컨테이너를 죽이고 재시작하게 한다.
ReadinessProbe의 유형, 옵션은 동일하게 가져간다. HttpGet 기반으로 많이 쓰이는 듯 하다.

3가지 유형의 Handler
Readiness Probe (LivenessProbe에서도 동일) - 쿠버네티스(kubelet)에서 제공하는 기능

HTTP GET Probe : 지정한 포트 및 경로에서 컨테이너 IP 주소에 대한 HTTP GET요청 수행. 응답의 상태코드가 200이상 400미만이면 성공으로 간주.
- 포트번호, Host, Path, http 헤더 등을 정의
TCP Socket Probe : 지정된 포트에서 컨테이너 IP주소에 대해 TCP 검사를 수행. 포트가 활성화 되어 있으면 성공으로 간주
Exec Probe : 특정 쉘 명령어를 날려서 확인. 명령어가 상태코드 0으로 종료되면 성공으로 간주

옵션 값

initialDelaySeconds : 최초 Probe를 만들기 전 딜레이 시간(default : 0초)
- 이 값을 설정하지 않으면 컨테이너를 시작하자 마자 프로브를 시작한다. Pod가 만들어지고 어플리케이션이 구동하는데 어느정도 시간이 걸리므로 이 값은 꼭 설정해주는게 좋다.
periodSeconds : Probe를 체크하는 간격(default : 10초)
timeoutSeconds : 지정된 시간까지 결과가 와야함(default : 1초)
successThreshold : 몇번의 성공 결과를 받아야 성공한 것으로 할 것인지(default : 1회)
failurThreshold : 몇번의 실패 결과를 받아야 실패한 것으로 할 것인지(default : 3회)