Error Reviewer

2년을 함께한 프로젝트 회고 Feat.개발자 회고

GiTo — Thu, 5 Oct 2023 11:17:29 +0900

프로젝트명: 메타버스 앱 개발
참여기간: 2021.11.25 ~ 2023.09.27

했던 일

결제/블록체인 관리자 페이지 개발
웹뷰 프론트 개발
웹뷰 백엔드 개발
AA & TA Role

기술스택

Vue.js 2.0
Spring boot
Mysql
AWS
EKS
Code Pipeline
AWS Lambda

2021.11 ~ 2022.01

경력직으로 입사 후 바로 투입된 프로젝트에서 결제파트 업무를 시작했다.
메타버스 플랫폼에 블록체인을 통한 경제시스템을 구축한다는 큰 그림 속 결제 시스템을 구축하는 파트였다.

기술스택은 시니어 개발자가 미리 정해둔 상태로 필요한 기능을 개발하면 되는 상태.

다소 수동적인 자세로 개발을 진행하며

AWS 에서 제공하는 CI 도구인 Code Pipeline 과 EKS 에 대해 얕게 배울 수 있는 기간이었다.

배운 점
CI / CD 에 대해 적극적으로 학습하여 배우려고 함

아쉬운 점
막내 포지션으로 수동적인 기능개발만 진행함

2022.02 ~ 2022.06

블록체인 파트로 편입되어 관리자 페이지 개발을 담당
블록체인 기술에 대해 전반적으로 학습할 수 있는 기간이었고

클레이튼을 이용한 블록체인 네트워크에 대하여 접할 수 있는 기간이었다.

Smart Contract, FT, NFT, Gas fee 등 새로운 용어들을 접하며 배울 것이 많았다.
백엔드 개발자 두 명이 API 개발을 진행하였고 나는 관리자페이지 개발을 진행하였다.

배운 점
블록체인 기술에서 사용하는 용어들 학습
클레이튼 기반 블록체인 네트워크에 대한 이해

아쉬운 점
프론트 개발을 혼자 진행하며 협업이나 클린코드보다는 업무를 쳐내기에 급급했던 점
가나슈와 솔리디티를 사용한 스마트컨트랙트 개발에 대하여 학습하고

내 것으로 만들 수 있는 기회를 놓친 점(이건 정리해 둔 게 있어서 추후에 할 수 있지 않을까..)

2022.07 ~ 2023.01

앱 오픈 및 웹뷰 개발을 진행하던 시기이다.
앱에 웹뷰를 붙여서 이벤트나 공지사항 등 앱배포와 무관하게 진행할 수 있는 영역을 추가했던 시기이다.

막내를 벗어나서 후배들이 일을 하나씩 가져가던 시기..
이때부터 시니어 한분과 기획 검토 및 백엔드 개발도 함께 진행하였다.
클라우드 전담 인력이 빠지면서 시니어 개발자분과 TA 영역도 하나씩 배워갔던 시기.
구축된 Spring Boot 에 REST API 를 추가개발하고 프론트 개발도 같이 진행하였다.

기획서를 기준으로 기능을 분해하고
테이블 설계 및 검토를 진행하고 (거의 검토)
백엔드 기능을 개발하고 (시니어님이 많이 진행)
프론트 개발을 진행하였다 (메인)

배운 점
앱에 웹뷰를 붙이는 아키텍처에 대해 학습
서비스 설계에 대한 경험 쌓기
AWS 및 EKS 운영을 위한 TA 업무 습득

아쉬운 점
Spring Boot 기반 백엔드 개발을 깊게 파보지 못한 점
시니어가 있을 때 깊게 파봤으면 좋았을 것 같다.
프론트 개발을 메인으로 진행하였는데 코딩 컨벤션이나 린트,

재활용 가능한 컴포넌트 단위 개발, 코드리뷰가 부족했던 점 등 아쉬운 부분이 많다..
나도 후배들도 구현만 많이 해보고 클린코드에 대한 접목을 못했던 점이 아쉽다.

2023.02 ~ 2023.06

AA 라는 롤을 부여받은 시기..
AA 가 뭔지부터 할 일이 뭔지 정리해야 했다.
Application Architect...
AA 는 기술스택을 선정하고
AA 는 개발방법론과 프레임워크를 선정하고
AA 는 어플리케이션 설계를 담당하며
AA 는 코드작성 가이드라인을 제공하며
AA 는 인프라 관련 요구사항을 정의할 수 있어야 한다

AA 는 PM 을 도와 구현에 필요한 일정 산정을 돕고
AA 는 PM 을 도와 비용과 효과에 대해 고민하고
AA 는 PM 에게 기술적인 충고를 할 수 있다.
[출처] Java EE 아키텍처 핸드북 2판 - 성공적인 아키텍

[출처] https://luceatluxvestra.tistory.com/59

AA 는 너무 광범위하고 높은(?) 자리여서 역할을 온전히 수행하지 못한 느낌이다.

다행히 시니어 개발자가 AA 의 롤에 대해 많은 조언을 해줘서 프로젝트를 잘 마무리할 수 있었고

이 기간 동안 AWS 관리업무도 많이 관여하게 되었다.

(시니어 개발자의 롤이 TA & PL & 백엔드 개발)

이 기간동안 개발보다는 성능개선이나 기획서를 분석해서 아키텍처를 잡는 역할을 많이 진행하며

단순히 개발만 하는 게 아닌 조금 더 넓은 시야로 서비스 전체를 내 것으로 만드는 시간이었던 것 같다.

배운 점

AA 의 역할에 대한 이해

TA 업무 수행경험 (주로 EKS, CI / CD 관리)

아쉬운 점

AA 에 대한 사전지식이 부족했고 아직은 같은 롤에 대해 부담스럽게 느껴짐

AWS 각 서비스에 대해 조금 더 깊게 파보고 싶었으나 집중하지 못했음

개발에 거의 손을 놓게 되었지만 클린코드 접목에 대한 갈증이 남음

2023.07 ~ 2023.09

마지막 3개월..

프로젝트 연장에 대한 의사결정이 늦어져서 시니어 개발자가 떠났다.

AA, TA 업무를 모두 맡게 되었고 우선순위를 나눠 어느 정도 가지치기를 진행했다.

개발자가 할 수 있는 부분은 권한을 주고 일을 알려주는 방식으로 짐을 나누니 시너지가 좋아졌다.

그렇게 필요한 부분에 대해 가이드 문서를 작성하고 공유하는 시간도 가졌다.

인계 준비도 하면서 작성할 문서가 꽤 많았고

노션 기반으로 같이 작성할 수 있는 부분은 나눠서 작성하였다.

업무 배분과 가이드 작성 관련 일을 주로 하다 보니 몸은 편한 느낌이었지만 피로는 누적되는 느낌이었다.

(회의 -> 기획서 분석 -> 아키텍처 설계 -> 업무배분...)

같은 업무를 계속하고 있는 주니어 개발자들은 다이렉트로 설계까지 경험하게 되었다.

(회의 -> 기획서 분석 -> 아키텍처 설계 -> 검토 리뷰)

배운 점

AA, TA 업무를 동시에 맡으며 일을 나누는 방법에 대해 고민하고 실행한 점

아키텍처 설계 경험 축적

아쉬운 점

손이 부족한 느낌을 받았고 경험 많은 개발자가 한 명 더 있었으면 좋았을 것 같다

위 이유에 대해 혼자서 커버하지 못한 점 (추후에는 더 매끄럽게 일처리를 하면 좋겠다)

회고를 작성하며 일기장 같다는 느낌을 많이 받았다.

하지만 작성하며 다음 프로젝트에서 하고 싶은 일과 하기 싫은 일, 더 배우고 싶은 점이 정리되는 느낌이 들었다.

다음 프로젝트에서 하고 싶은 일

클린코드 작성

코드 컨벤션 및 코드작성 가이드라인을 팀 전원에게 적용

다음 프로젝트에서 하기 싫은 일

업무에 급급하여 기능만 되는 코드를 작성

배우고 싶은 점

프론트나 백엔드에 무관하게 하나의 언어를 깊게 파보고

코드 컨벤션 및 코드작성 가이드라인을 제공할 수 있는 개발자가 되고 싶다.

(다음 프로젝트가 정해지면 주력 스킬에 대해 깊게 파보는 시간을 가져야겠다)

AWS 에 대해 얕게 배운 것 같아서 조금 더 깊게 배울 수 있는 기회가 있으면 꼭 잡고 싶다.

인앱리뷰로 앱 평점 급상승 경험공유

GiTo — Wed, 6 Sep 2023 17:37:01 +0900

오늘은 앱 개발 프로젝트에 2년여간 참여하며 앱 평점을 관리했던 경험을 공유하려 합니다.

제목 후보로 있던 '앱의 라이프 사이클' 이라는 느낌으로 작성되었습니다.

앱 오픈 초창기

앱을 오픈하고 초창기에는 대대적인 마케팅을 진행하였습니다.

대대적인 마케팅 -> 대량의 유저유입 -> 예상치 못한 오류들 발생

이 결과는 곧 앱 평점 테러로 이어집니다.. (별점테러)

에러만 나면 떨어지는 평점

앱 안정기

앱 오픈 초창기의 오류들을 수정해나가면서 점차 안정적인 운영을 해나가고 있습니다.

버그픽스 및 최적화를 진행하며 앱을 더 사용하기 좋게 만들 수 있는 기간입니다.

2차 마케팅 및 신규 콘텐츠 추가

앱이 안정적이라 생각되며 신규 기획에 대한 아이디어들이 넘쳐나는 시기입니다.

수익화와 킬러콘텐츠 확보를 위해 아이디어가 넘쳐흐르며 개발자와 싸우는 시기입니다.

하고 싶은 건 많지만 개발자가 할 수 있는 일은 한정적입니다.

이러한 시기를 겪으면 완성도가 떨어진 콘텐츠가 추가될 가능성이 높습니다.

그렇게 다시 바닥으로..

이렇게 또다시 떨어진 평점은 다시 돌아올 생각을 하지 않습니다..

문제가 있을 때만 쓰게되는 리뷰와 평점들..을 보고만 있을순 없었습니다.

인앱리뷰 도입 검토

문제가 있을 때 (장애라던가..) 만 리뷰를 쓴다는 관점으로 접근하여

긍정유저가 리뷰를 남기도록 유도하자는 의견이 이어져 인앱리뷰 도입을 검토하게 되었습니다.

러프하게 조사한 내용으로는

정책상 횟수 제한이 있다.
구글스토어로 이동시키는 행위는 횟수 제한이 없다.
리워드를 지급하는 형식으로 높은 별점을 유도하면 안된다.

이정도의 내용으로 회의를 이어갔고

지금의 상태로 리뷰를 더 받아도 좋게 평가될 수 있을지 모르겠고

이러한 상태에서 횟수 제한이 있는 인앱리뷰 도입은 아닌 것 같다는 의견을 수렴

앱 안정화 이후 도입을 재검토하기로 결정되었습니다.. (신규콘텐츠 안정화!)

인앱리뷰 드디어 도입

일단 좋은 리뷰를 받기 위해 어떤 시점에 호출할지 정해야했다.

아이디어를 받던 중 나온 최적의 상황은 리워드가 생길 때 였다.

유저 유입을 위한 출석체크 이벤트를 진행중이였고, 현금성 리워드를 받은 이후에 인앱리뷰를 띄우게 되었다.

결과는 성공적.. ★★★★★

1.9까지 내려갔던 플레이스토어 리뷰평점이 4.7까지 상승했다.

ios 는 정책상 횟수 제한이 안드로이드보다 적다고 전달받았고 9월중에 도입 예정입니다.

돈도 안드니(일은 추가되지만) 도입하지 않으셨다면 검토해보는 것을 추천드립니다!

참고사이트

모바일게임의 평점과 리뷰로 어플삭제사례 기사

구글 플레이스토어 정책

구글 플레이스토어 인앱리뷰 개발자가이드

[MariaDB] 운영시간에 Index 추가해보기

GiTo — Mon, 4 Sep 2023 17:53:16 +0900

오늘은 운영시간에 Index 를 추가해볼 일이 생겨 접하게된

MariaDB Index 추가에 대해 정리해보려 합니다.

왜?

신규 서비스를 오픈하고 RDS 에 CPU Utilization 70% 알람이 와서 점검을 해봤다.

신규 서비스에서 요청하는 쿼리가 눈에 띄었고 해당 쿼리 점검 (풀스캔 쿼리 당첨)

인덱스를 추가하면 개선이 될 것 같았다.

해도 되나?

내 기억속에 Index 를 추가하는 작업은

'운영시간에 하면 안되고 lock 을 발생시킬 수 있다'

라는 생각이 들었다.

하지만 세상이 좋아진건지 검색을 해봤더니 아래와 같은 내용들이 나왔다.

인덱스가 생성되는 동안 테이블은 읽기 및 쓰기 작업을 계속 사용할 수 있습니다. 

명령문 CREATE INDEX 는 테이블에 액세스하는 모든 트랜잭션이 완료된 후에만 완료되므로 
인덱스의 초기 상태는 테이블의 최신 내용을 반영합니다.

보조 인덱스 추가를 위한 온라인 DDL 지원은 
일반적으로 보조 인덱스 없이 테이블을 생성한 다음 
데이터가 로드된 후 보조 인덱스를 추가하여 
테이블 및 관련 인덱스 생성 및 로드의 전체 프로세스 속도를 높일 수 있음을 의미합니다.

CREATE INDEX 또는 ALTER TABLE 문의 실행이 완료될 때 테이블에 커밋된 데이터만 포함됩니다.

여기에는 커밋되지 않은 값, 이전 버전의 값 또는 삭제 표시가 되었지만 
이전 인덱스에서 아직 제거되지 않은 값이 포함되어 있지 않습니다.

구글 번역이 불편하지만..

Mysql 공식 도큐먼트에서 Online DDL 이라는 키워드로 검색하면 아래와 같은 내용이 나온다.

Online DDL 이라는 기술로 인덱스 생성 작업중에도 읽기 및 쓰기에 영향이 없다는 내용이였다.

혹시나 락이 걸리거나 하는 일이 있을 수 있어서 Create Index Downtime 이라는 키워드로 추가 검색을 해봤다.

용량에 비례해서 인덱스를 생성할 때 얼마나 걸리는지가 궁금했다.

1억건 20여분..

3억건 30몇분..

대량의 데이터는 분할해서 인덱싱할 수 있게 짜야된다.. 라는 내용이 나왔고

대부분의 내용은 테스트를 해보는 방법뿐!

개발계에서 동일한 데이터로 테스트를 해봤다.

1초도 안걸리길래 운영계에도 인덱스 추가완료!

기존 120ms 가 걸리던 쿼리가 10ms 로 개선되었다.

기존 풀스캔 14만건 조회하던 쿼리가 100개 미만 데이터 조회로 개선되었다.

argocd git credential 변경하기

GiTo — Fri, 16 Jun 2023 13:58:34 +0900

오늘은 argocd git credential 변경 방법에 대해 공유드리려합니다.

건강했던 argocd 가 어느날 아프기 시작했습니다.

git login 정보가 변동되면서 발생한 사이드 이펙트였는데요.. (안쓰는줄 알았던 IAM 을 날려버려서.. 비밀번호가 바뀌었다)

그래서 Repository 설정을 바꿔주면 되겠지 했는데.. 설정이 없습니다.

다음으로 시도한 방법은 새로 Connect 설정을 추가하는 것 이였는데..

동일한 target 을 바라보는 설정은 추가가 불가능하였고 upsert 하라는 메세지를 반환했습니다.

argocd document 를 찾아보니 repo_add 에 upsert 가 있는 것을 찾았고 해당 방법으로 다시 시도합니다.

https://argo-cd.readthedocs.io/en/release-1.8/user-guide/commands/argocd_repo_add/

1. kubernetes 에서 argocd pod 조회

2. argocd server pod 에 접속

3. upsert command 실행

이렇게 하면 되겠지 하고 도전..

FATA[0000] Argo CD server address unspecified

address 를 못찾겠다.. 는 메세지를 봤으나 실패인줄 알고 또 헤메다가 다시 돌아왔습니다.

argocd 서버에서 argocd 명령을 실행시켰다고 바로 실행되는 것이 아닌 로그인 절차가 필요했습니다.

최종 성공한 방식은 아래와 같습니다.

1. kubernetes 에서 argocd pod 조회

$ kubectl get services -n argocd

2. argocd server pod 에 접속

$ exec kubectl exec -i -t -n argocd argocd-server -c argocd-server -- sh -c "clear; (bash || ash || sh)"

3. argocd host login (host 를 입력하고 login 명령어를 실행하면 id / pw 를 물어봅니다)

$ argocd login {host}

4. upsert command 실행

$ argocd repo add {git path} --username {username} --password {password} --upsert

argocd git credential 변경이 필요할 때 도움이 되셨으면 좋겠습니다.

AWS Bastion 개념 정리 (Bastion 이 뭐야?)

GiTo — Tue, 7 Mar 2023 15:49:05 +0900

bastion 뜻

Bastion [ˈbæstiən]. "요새", "보루"를 뜻하는 영어 단어이다. 성형 요새에서 돌출 지점마다 건설된 포루를 의미하기도 한다. 이때에는 능보(稜堡), 치성(雉城)이라고도 흔히 번역된다. 모난 작은 성

그러나 자주 사용되지는 않고 이러한 의미로는 fortress가 압도적으로 많이 쓰인다. 이 단어는 오히려 은유적으로 어떤 것이 요새를 이룰 만큼 강성하게 모여있을 때 많이 사용하는 단어다. 그렇다고 요새로 사용해도 어색한 단어는 아니다. 더 나아가 "수호자"라는 의미로 은유되곤 한다.

바스티유 감옥 습격사건으로도 유명한 프랑스 바스티유 요새(bastille)의 지소형 bastillon에서 유래했다. "시침질 하다"를 의미하는 baste와 관련이 있을 가능성이 있다고 한다.#

창작물 중에 이 단어를 고유명사로 한 것이 많으나 한글 표기는 통일되어있지 않다. [ˈbæstiən]을 한글로 전사하면 '배스티언'이지만 미국 중서부 영어로는 "배스천"[bæstʃ(ə)n]이라 읽는다. 맥밀런 영어사전 한글 표기는 '배스천', '바스티온'이 대부분이다.
출처: 나무위키

AWS Bastion Architecture

출처 : https://aws.amazon.com/ko/blogs

Bastion 은 외부에서 내부로 접근할 수 있는 게이트웨이 역활을 한다.
AWS 기준으로 Bastion host 를 Public Subnet 에 구성하고
내부 Instance 들을 Private subnet 에 구성하여
내부 Instance 접속을 Bastion host 에서만 가능하도록 허용한다.

내부 Instance 접속경로가 제한되므로 Bastion host 에
보안구성을 통해 제어 및 관리가 용이해지는 장점을 가진다.

ArgoCD Slack Notification Setting

GiTo — Mon, 6 Mar 2023 17:47:37 +0900

오늘은 ArgoCD Slack Notification Setting 을 해보았다.

참고사이트

https://argocd-notifications.readthedocs.io/en/stable/services/slack/

https://argocd-notifications.readthedocs.io/en/stable/catalog/#triggers

출처: https://argocd-notifications.readthedocs.io/en/stable/services/slack/

slack configuration

1. noti 를 보낼 slack app 생성
https://api.slack.com/apps

2. 1 에서 생성한 slack app 에 write 권한 추가
OAuth & Permissions 탭에서 Scopes 추가
chat:write:bot 항목 추가

3. Install App to Workspace
noti 를 받을 workspace 에 앱 추가
해당 과정에서 OAuth Access Token 은 아래 kubernetes configuration 에서 사용함

kubenetes configuration

1. argocd 에서 제공하는 notification 패키지 다운로드

https://argocd-notifications.readthedocs.io/en/stable/

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml

2. slack secret 을 등록하기 위한 configmap 생성

# argocd-notifications-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: argocd-notifications-secret
stringData:
  slack-token: {"slack application secret token"}

3. argocd configmap 에 등록

$ kubectl apply -f argocd-notifications-secret.yaml

4. argocd configmap 수정

$ kubectl edit cm argocd-notifications-cm -n argocd

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  service.slack: |
    token: {"slack application secret token"}

5. argoCD 에서 noti 설정
Name 에는 slack noti trigger, value 에는 채널명을 기입

trigger 참고사이트
- https://argocd-notifications.readthedocs.io/en/stable/catalog/#app-health-degraded

key value 참고사이트
- https://argocd-notifications.readthedocs.io/en/stable/upgrading/0.x-1.0/#recipientsubscription-annotation

예시
Name: notifications.argoproj.io/subscribe.on-health-degraded.slack
Value: argo_noti_channel

Windows 에 OpenShift 3.11 CLI 설치하기 (Windows Install OpenShift 3.11 CLI)

GiTo — Tue, 31 May 2022 11:16:38 +0900

해당 글은 Windows 에 OpenShift 3.11 CLI 를 설치하는 과정을 작성하였습니다.

OS : Windows 10 Home

구글에 검색하기

위에 있는 openshift docs 에 접속하면 OS 별로 OpenShift CLI (이후 oc) 를 설치하는 방법이 서술되어 있다.

Red Hat Linux 는 RHSM 을 통해서 설치할 수 있으나
Mac 과 Windows 는 Red Hat Customer Portal 을 통해서 다운받으라고 되어있다.

하지만 해당 링크를 통해 접속 후 로그인하면 서브스크립션을 가져오라고 한다.
자기네 제품의 평가판이라도 받아서 활성화하면 다운로드를 하게 해줄듯 하다..

~~우리는 이 방법 외에 다른 방법을 선택하기로 합니다.~~

다시 구글에 검색하기

첫 사진의 아래를 보면 GitHub 의 Releases 페이지가 있습니다.
해당 페이지의 제일 아래를 보면...

이렇게 친절하게 zip 파일을 확인할 수 있습니다.

다운로드 후 압축풀고 windows PATH 까지 잡아주면 끝

[Spring Boot] 개발환경 세팅 및 프로젝트 생성

GiTo — Wed, 13 Apr 2022 17:02:09 +0900

해당 예제는 송자바코딩님의 "자바 스프링부트 활용 웹개발 실무용" 강의를 따라 진행하며 기록하였습니다.

개발환경

OS : Windows 10 Home

IDE : Eclipse 2021-09 버전

Java : openjdk11

E01 서버개발 프로젝트 생성 + Mybatis + MariaDB 연동

Eclipse Marketplace 에서 Spring Tool 설치

스프링 프로젝트 생성

Project Explorer 에서 우클릭 -> New -> Spring Boot -> Spring Starter Project

선택한 패키지가 pom.xml 에 자동으로 선언된다.

Next -> Finish 로 생성

생성된 프로젝트 확인

Run Spring Boot App

에러가 발생한 것을 확인할 수 있으며 메세지를 확인해보면 database 설정 관련 문제인 것으로 보인다.

아래 내용으로 검색하면 많은 예시가 있다.

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.

예제를 따라 Configuration 관리를 위한 패키지를 생성하고

DatabaseConfiguration Class 를 작성해준다.

@ (어노테이션) 을 작성하고 Ctrl + Space Bar 단축키를 사용하면 필요한 Class 를 import 할 수 있다.

@Configuration 어노테이션 아래 @Bean 어노테이션을 선언하고 메소드를 작성하면

해당 메소드가 스프링 컨테이너의 빈으로 등록된다.

[Spring] 빈 등록을 위한 어노테이션 @Bean, @Configuration, @Component 차이 및 비교 - (1/2)

기존의 Spring MVC에서는 xml을 활용하여 Bean을 등록하고 있었다. 하지만 프로젝트의 규모가 커짐에 따라 사용하는 요소들을 xml에 등록하는 것이 상당히 번거로워 져서 어노테이션(Annotation, @)를 활

mangkyu.tistory.com

이후 resources\application.properties 에 spring.datasource 설정값을 입력하면 해당 설정이 반영된다.

application.properties 를 작성하고 다시 Run Spring Boot App

정상적으로 실행된다.

강의에서는 mariaDB jdbc 를 pom.xml 에 dependency 로 등록하지만 현재 버전에서는 바로 실행이 된다.

스프링부트가 실행된 8080 포트로 접속했을 때 Whitelabel Error Page 가 보일 것이며

접속한 로그가 Console 에 찍힌 것을 확인할 수 있다.

배운점

@Bean 과 @Configuration 의 등록방법과 Bean 이 무슨 역활을 하는지 얕게라도 알게됨

Spring Boot 프로젝트를 만들면 바로 실행가능한 상태가 아니라는 것을 알게됨

느낀점

Spring 이 왜 대규모사이트에서 사용하는지 알것 같다.

생각보다 기본라이브러리가 많아서 공부할 점이 많아보인다.

참고사이트

https://mangkyu.tistory.com/75

https://youtu.be/AcbzhJoQ-OY

[AWS CI/CD] CodeBuild 정리

GiTo — Tue, 28 Dec 2021 17:44:07 +0900

AWS 의 CI/CD 툴인 CodePipeline 의 기능 중 Build Stage 를 담당하는

CodeBuild 의 Flow 에 대해 정리해두려고 합니다.

미리 보면 좋은 내용

2021.12.06 - [AWS] - AWS CI/CD CodePipeline 개념정리

AWS CodeBuild 란?

소스코드를 컴파일하고 테스트를 진행, 배포준비까지 담당하는 지속 통합 서비스라고 설명되어 있습니다.

설명은 사진으로 대체하고 등록방법 및 Flow 에 대해 알아봅시다.

AWS CodeBuild 빌드 프로젝트 생성

Step1

CodeBuild - 빌드 프로젝트 - 빌드 프로젝트 생성

간단하게 이름을 작성

Step2

소스 추가

빌드대상의 소스코드 저장 위치를 등록한다.

GitHub 을 사용해도 무관하며 AWS CodeCommit 도 GitHub 과 유사하다.

Step3

Build 환경 및 서비스 역할 지정

빌드환경은 aws linux 를 써도 무관하며 서비스 역할이 있을 시 등록해주면 됩니다.

새 서비스 역할이 지정되면 위와 같이 codebuild 가 신뢰할 수 있는 개체로 등록된 것을 확인할 수 있습니다.

Step4

Build Command 입력

기본적으로 buildspec 파일을 사용하도록 설정되어 있습니다.

buildspec 명령은 공식문서를 참고할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/build-spec-ref.html

저는 install, build, post_build phase 를 사용하여

Docker 설치, docker image commit (ECR), helm-chart commit 과정을 진행합니다.

Step5

아티팩트 설정으로 빌드에 사용된 파일을 S3 버킷에 캐싱할 수 있습니다.

해당 설정을 통해 빌드속도가 비약적으로 상승할 수 있습니다.

여기까지 완료했다면 위와 같은 관리 페이지에 접근할 수 있으며

해당 페이지에서는 빌드, 빌드 기록 확인, 세부정보 등을 확인할 수 있습니다.

결과적으로 CodeBuild 과정을 거치면 application 을 사용할 수 있는 준비가 완료되며

이를 어디서든 활용하면 됩니다.

이후 CodePipeline 에 연결하여 자동배포하는 과정에 대해 정리해보겠습니다.

[AWS CI/CD] CodePipeline 개념정리

GiTo — Mon, 6 Dec 2021 16:10:12 +0900

AWS 의 CI/CD 툴인 CodePipeline 에 대해 정리해보려고 합니다.

미리 보면 좋은 내용

2021.04.17 - [Linux/Docker] - Docker 사용해보기 - 1 (Why Docker 2편 + CentOS 7.9 Docker 설치)

2021.05.10 - [Linux/Docker] - Docker 사용해보기 - 3 (python 모듈 Docker 에서 실행하기)

2021.05.24 - [Linux/Docker] - Docker 사용해보기 - 4 (오케스트레이션 도구소개)

AWS CodePipeline 이란?

코드가 변경될 때마다 코드를 빌드, 테스트 및 배포하도록 하는 자동화 도구

CI/CD 툴이라고 생각하면 된다.

*CI : Continuous Integration

*CD : Continuous Delivery / Deployment

출처: Devops Explained

AWS CodePipeline Flow

AWS CodePipeline 의 Flow 는 아래와 같다.

Source Stage -> Build Stage -> Deploy Stage

1. Source Stage

Source Stage 는 Source Code 형상관리 툴이다. (github 과 유사하다)
AWS 에서는 CodeCommit 이라는 개발자 도구를 제공한다.
CodeCommit 을 기준으로 특정 Branch 에 Push 가 발생할 시 Pipeline 이 동작한다.
Repository 와 BranchName 기준으로 target 을 정할 수 있다.

2. Build Stage

Build Stage 는 Source Stage 를 기준으로 Docker Image 로 빌드하는 단계이다.
AWS 에서는 CodeBuild 라는 개발자 도구를 제공한다.
Source Stage Repository 에 buildspec.yml 을 기준으로 빌드를 진행한다.
Build Stage 는 세 단계 (phase) 로 나누어 진행한다. (install -> post build -> build)
빌드에 성공한 이미지는 ECR 과 같은 repo 에 push 한다.
- *ECR 은 Elastic Container Registry 의 약자로 Docker repo 와 유사하다.
빌드 시 필요한 이미지나 라이브러리는 S3 또는 로컬에 cache 로 저장하며 최초 1회만 오래걸린다.

3. Deploy Stage

Deploy Stage 는 빌드된 이미지를 기준으로 배포하는 단계이다.
AWS 에서는 CodeDeploy 라는 개발자 도구를 제공한다.
ECR 에 Commit 이 발생하면 배포 target 에 업데이트한다.
현재 진행해본 케이스는 target 이 EKS 인 경우이다.
CodeDeploy 를 사용해도 되나 내부 사정상 ArgoCD 연동을 하였다.

AWS Pipeline 에 대해 가볍게(?) 알아보았습니다.

설정 예제의 경우 추후 업무외적으로 프리티어를 사서 사이드 프로젝트를 하게되면 작성하게 될지도 모르겠습니다..

감사합니다.