aws에서 ec2 인스턴스에 속한 iam을 변경하는 경우 위와 같은 문구를 만날때가 있다. 근데 찾아보면 'IAM 역할 없음' 선택 후 저장하면 된다고 하는데 그래도 위 에러가 계속 발생하는 경우가 있다. 찾아보니까 이런 경우는 aws cli로 커맨드를 직접 날려서 해결해야한다고 하더라.
2. 해결방법
1. AWS CLI 설치
아래 링크에서 설치하고 오십쇼
2. AWS CLI 로그인
aws configure 명령어를 쳐서 IAM User의 accesap-northeast-2s key와 secrert key를 입력한다. 참고로 서울의 지역은 ap-northeast-2 이다.
잘 모르겠으면 아래 링크에서 IAM User 생성과 로그인까지 나와있으니 참고.
3. AWS IAM에 EC2 권한 부여
로그인 한 IAM에 "AmazonEC2FullAccess" 권한을 부여한다. 그리고 바로 권한 갱신이 안되는 것 같으니 콘솔창 다시한번 껏다켜준다.
권한이 정상적으로 부여됐는지 확인하기 위해 현재 ec2 인스턴스들의 IAM 부여 정보를 확인하는 명령어를 쳐본다.
intellij gradle 프로젝트 생성 후, 원하는 dependency가 있는데 설치하는 방법을 안내하겠다.
2. 문제상황
김영한 님의 JPA 강좌를 듣는데 강좌 초기 부분에서 일단 maven으로 하자고 하셨는데, 꼭~~~! 말 안 듣고 gradle로 하는 사람이 있다. 물론 본인도 평소에 gradle로 개발을 해왔기 때문에 말 안 듣고 gradle로 설치하였다. 문제는 원하는 hibernate, h2 database 2개를 설치해야하는데 어떻게 찾아야 하는지 아예 감도 안 잡히는 분들을 위해 간단한 글을 작성해 봤다.
3. 해결방법
본인이 원하는 dependency의 이름과 버전을 생각해 본다. 해당 강좌에서는 각각 "hibernate 5.3.10.Final", "com.h2database 1.4.199"이다.
구글에 검색한다 gradle depedency "이름 버전"
그러면 가장 첫 번째 게시물로 저 사이트가 나온다.
보면 본인의 상황에 맞는 gradle을 선택하면 gradle.build에 작성해야 하는 코드가 나온다.
람다라는 서비스를 통하여 serverless 구조로 기존의 dedicated 서버 형식 API 또는 백엔드 서버가 없는
본인은 올해로 6년 차 개발자이며, 작년 9월부터 이직했고 회사에 도착해 보니 보통 알고 있던 ec2기반 백엔드 + 프론트 서버의 형태가 아닌 sam(serverless application model) 백엔드 + 클라우드프론트, 앰플리파이를 통한 완전히 aws 서비스만으로 모든 서버의 유지부터 배포를 끝내는 아키텍쳐를 경험했다. 해당 회사에서 지금 4월까지 얼추 6개월정도 해당 아키텍처를 기반으로 신규 프로젝트 구축부터 유지보수를 진행했다. 비록 일시적이지만 게시판, VOD, 회원가입, 결제가 최소한으로 들어간 4개의 프로젝트의 시작부터 종료까지 함께했다.
이 정도면 꽤 실험적이 아닌 실무적으로 aws lambda 서비스를 활용했다고 믿을 수 있지 않을까? 우선 람다는 핵심 서비스의 장기적인 개발 관점에서 탈락이다. 큰 단점이 매우 많이 존재한다. 한번 해볼까? 하는 마음가짐으로 람다를 가볍게 도입하려는 분께는 내가 미리 똥이란 것을 알아넀으니 단호하게 No라고 하겠다.
장점
1. aws에서 콘솔로 관리 : 단순 정보는 조회에 용이
어디에 무엇이 있는지 aws 콘솔에 전부 나와 있기 때문에 알 수 없는 정보란 존재하지 않는다. 말이 어려운데 예를 들자면 프로젝트에 API 서버가 4개가 있고 이를 아무도 모아놓은 docs가 없다고 해보자. aws에 구축해놓았다면 서비스 콘솔에 모든 정보가 바로 뜨기 때문에 한눈에 서비스를 보기에는 빠르고 쉽다.
2. 함수형 지향, 기능 구현에 집중 할 수 있음
우리가 API 서버를 구축한다고 하면 정말 많은 것을 고려해야 하지만 sam 방식은 정말로 API로 쓰일 핵심 함수만 구축하면 되기 때문에 기능 구현에 초점 집중 할 수 있다. 나아가 모든 기능을 함수로 제공하는 것을 강제하기 때문에 유저는 자연스럽게 재사용, 함수형 개발을 할 수 있다.
3. 토이 프로젝트로 가볍게 몇개 올리기에는 좋다
위와 마찬가지로 API 서버를 구축하려면 인프라 차원에서 세팅해야 하는 부분이 많다. 하지만 aws lambda를 활용하면 자동으로 git repository 생성부터 자동 배포까지 알아서 해준다. 이는 여러 인프라 세팅 단계를 스킵할 수 있기 때문에 매우 편하다.
4. https 설정, 도메인 연동 용이
aws에 붙어 있는 서비스라서 도메인, 거의 자동으로 https 프로토콜 적용이 가능하며 도메인 연동에 용이하다.
5. 함수별 호출 에러, 로그 조회 자동으로 상세화
직접 서버를 구축한 경우, 특별히 로깅 시스템을 구축하지 않았다면 에러가 발생했을 시 stacktrace 형식으로 에러가 발생한 부분을 찾을 것이다. 그러다 보면 정확히 원인이 발생한 지점까지 확인하지 못할 수도 있다 lambda는 함수단위로 에러 로그를 조회 할 수 있는 시스템이 기본으로 구축되어 있어 발생한 에러에 대한 파악이 쉽고 빠르다.
여기까지 봤을때는 와... 이걸 외 안씀? 이럴 수 있는데 극적 반전을 위해 단점을 아래 배치했다. 나의 한이 서린 원념을 담아서 작성해보겠다. 쭉 읽어보라
단점
실제 프로덕트에 쓰기에는 다양한 문제점을 동반
본 글의 요지이자 핵심인데 장점을 초월하는 실제 프로덕트에 쓰기에는 너무 많은 단점이 존재한다. 이는 개발을 어렵게, 불가능하게 만들 뿐더러 결과론적으로 더 오래걸리고 품질이 낮은 서비스가 될 가능성을 높여준다. 실제로 현재 다니고 있는 회사는 API의 dev 서버가 따로 존재하지 않으며, api 서버의 배포를 한 번 하는데 10~15분정도 걸리며, 구체적인 서버 커스터마이징이 불가능하다.
1. 구조 부재 : 지옥
모든 개발 프로젝트가 동일하지만... 람다라는 서비스는 초심자가 활용하게 된다면 가이드가 없기 때문에 함수형을 가장한 안티패턴이 될 가능성이 높다. 본 회사는 모든 함수에 로우쿼리가 들어가 있어 데이터의 CRUD를 재사용 하지 못하고 있다... ㅠㅠ (사실 모든 함수에 로우쿼리가 존재하는 것에 대한 문제인식이 안되는 것 부터 문제긴 하다.) 람다만이 가질 수 있는 함수형으로 인한 안티 패턴 특성이라 하면 함수 단위 하나가 스스로 돌아가기만 하면 되기 때문에 재사용성을 강요하지 않으면(기본이지만) 정말로 비슷한 함수임에도 불구하고 재사용을 1도 하지 않을 수 있다. 다시말해 일반적인 구조보다 함수마다 완전 다른 형태의 로직과 템플릿을 가질 수 있다.
2. 직접 디버깅 불가, 로깅 불편
치명적인 단점인데 직접 디버깅을 할 수 있는 방법이 없다. 브레이크포인트 찍으면 바로 잡을 문제를 하나씩 전부 로그찍게 만들어서 디버깅을 힘들게 만든다. 심지어 로그도 제대로 안돼서 매번 JSON.stringfy를 써야한다.
3. 활용 불가능한 로컬 개발 환경
우선 api 서버를 로컬에서 구동하려면 docker가 필수적으로 실행되어 있어야 한다.(이건 딱히 문제가 안될 수 있다.) 그리고 api 주제에 각 api를 컨테이너로 구동하기 때문에 pc 리소스를 많이 잡아먹는다.(이것까지도 딱히 문제가 안될 수 있다.)
가장 크리티컬한 부분은 cold start라서 최초 호출 시 엄청오래 걸린다.(약 5~10초?) 이는 테스트가 불가능할정도이며 존재하는 모든 문서를 찾아봤는데 현실적으로 방법이 없다.(warm start -> api 개수가 너무 많으면 모든 api를 warm start로 구동하는데 하루종일 걸림) 결국 나도 내 신념을 포기하고 프론트엔드 개발자 분 보고 개발서버로 로컬개발 하듯이 사용하라고 했다.
그동안 어쩔 수 없이 꾹참고 로컬로 테스트 하던 상황이 생각나 너무 화나서 욕좀 한번 박겠다. 병신같은 서버리스 어플리케이션 모델~~ 나의 진심어린 분노가 여러분께 전달되어 한분이라도 이 똥을 안찍어먹을 수 있기를 바란다.
4. 배포 개느림
아 욕 안할려했는데 저 사진 다시보니까 욕나옴 ㅋㅋ 시발진짜 급해 뒤지겠는데 언제끝날지도 모르고 뭐할때마다 개오래걸리고 후...
api가 100개정도 넘어가는 시점부터 배포하는데 거의 15분정도 걸린다. 이거 때문에 배포만 빨라도 금방끝내고 퇴근할걸 야근당한적도 몇번 있었다.
5. 자료가 많이 없다.
다른 이슈들에 비해 그리 크리티컬하지는 않으나 aws lambda에 대한 개발 자료가 월등히 적다. 초보 개발자라면 굉장히 고통받을 것이다.
짤막한 사용 팁
6개월동안 구르면서 직접 터득한 노하우들이다. 간략히라도 쓰려고 했는데 위에 단점쓰면서 화가 너무나서 이 글 게시물 조회수 좀 나오면 후속 게시물로 쓰겠다.
- 우측에서 플로팅으로 따라다님 - 게시물 내 h2태그 기준 목차 자동으로 추출 - 목차 클릭 시 해당 목차에 해당하는 영역으로 자동 이동 - 게시물에서 수정하거나 삽입 할 필요 없이 javascript로 후처리 하여 간편한 사용 - 만드는데 3시간 정도 걸렸음. 이걸 자기가 만든 것 처럼 무단배포 하는 착한 사람이 있으면 내가 이런 꿀정보를 공유 못함.
2. 적용 방법
본인은 square 스킨을 사용 중, 다른 스킨을 사용하면 HTML 코드 구조가 다를 수 있으니 유의!
꾸미기 > 스킨 편집
html 편집
이후 아래 3개의 코드를 적절한 위치에 추가해주면 된다. 이미지를 참고하여 위치를 확인 후 코드를 복사해서 넣어주자.
1. 개요 2. 블록체인 기본 개념 3. 채굴이 그래서 뭐요? 4. POW란? 5. POW - hashcash 6. 여기서 다시 짚어보는 채굴 행위란? 7. 비트코인 채굴 난이도 8. 채굴 난이도 동적 조절
1. 개요
인터넷에 블록체인의 채굴에 대한 설명이 많은데 대략 어떤 느낌이구나... 싶은 글은 많지만 그런 글들을 읽어도 "그래서 채굴이 뭔데?" 라고 물어보면 비개발자는 물론이고 개발자도 충족시켜줄 만한 답변을 찾기 쉽지 않다.
왜 완벽한 이해가 안됐는지 돌이켜보면 사실 채굴 행위 자체에 대한 의해는 큰 의미가 없으며, 블록체인 세상에서 채굴이라는 행위가 갖는 맥락적인 이해까지 해야 진정한 의미를 알 수 있다.
그래서 일하면서 틈틈이 공부해서 얻어낸 채굴에 대한 전반적인 지식을 정리해서 배포해보도록 하겠다.
2. 블록체인 기본 개념
비개발자
채굴에 대한 이해를 하기 위해서 최소한 블록체인에 대한 이해를 해야 한다.
왜 이런 것이 생겨났냐? 지금 세상의 데이터의 관리 주체는 마치 당신의 핸드폰 정보를 삼성, 아이폰이 갖고 있는 것처럼 특정 개인이 하고 있다.
근데 이것이 맘에 안 들어서 세상 모두가 관리 주체가 되자는 느낌으로 탄생한 이념이 web3며 기반 기술은 블록체인이다.
"마치 우리 스스로 잘 해낼 수 있다!" 이를 탈중앙화라고 하며 IT계의 무정부주의 같은 느낌이다.
왜 탈중앙화를 해야 하나? 과거 네이버 실시간 검색어에 대한 조작 논쟁이 끊이지 않았던 것 기억하는가?
네이버 실시간 검색 랭킹을 누구도 조작할 수 없도록 시스템을 만든다고 생각하면 된다. 이념이 좀 이해가 되는가?
탈중앙화는 데이터에 대한 투명성을 보장해주며, 이는 곧 시스템에 대한 투명성으로 이어진다.
그럼 어떻게 우리 스스로 데이터를 배포하고 관리하느냐?
"데이터를 블록으로 쪼개고 우리 모두가 데이터를 읽는(read) 동시에 쓰면(write) 된다." 라고는 하지만 사실 우리는 읽기(read)만 하고 데이터를 쓰는(write) 사람을 나눠놨다. 그리고 보통 데이터를 쓰는 사람을 채굴자라고 하며 채굴을 통해 데이터를 블록체인상에 올릴 수 있다.
개발자
솔직히 블록체인 하도 많이 들어서 이런 얘기는 시시콜콜하죠?
네 압니다. pass
3. 채굴이 그래서 뭐요?
말이 길었다. 그래서 채굴이 뭐냐? 6번에서 한번 더 설명할 것이지만 일단 간단히 채굴이 뭔지 에피타이저로 맛보도록 하자.
비개발자
돈을 벌고 싶은 누군가가 본인의 컴퓨터를 사용하여 엄청나게 어려운 수학 문제를 푼다. 그 수학 문제를 풀면 블록체인 네트워크상에 데이터를 올릴 수 있는 방법을 알게 되고 그곳에 데이터를 올리고 싶은 사람의 데이터를 받아서 대신 올려준다. 그러면 문제를 풀고 데이터를 올려준 사람은 보상으로 코인을 얻게 된다. 이것이 채굴의 기본적인 의미다. 여기서 어려운 수학 문제를 Proof Of Work라고 하는데 아래에서 POW의 유래와 의미를 알아보도록 하자.
개발자
스택오버플로우에서 누군가가 mining을 이렇게 표현했다. mining is doing the work of finding nonce so that sha256(sha256(data+nonce)) < difficulty 즉 누군가 올리고자 하는 데이터를 받아서 거기에 어떤 난수를 추가해서 해시를 엄청나게 돌리는데 그 해시의 값이 특정 조건을 만족할 때까지 난수를 찾는다.
여기서 만족하는 해시를 찾을 것을 POW라고 하며 다양한 POW가 존재한다. POW의 유래와 정확한 의미를 알아보자.
4. POW란?
Proof Of Work의 의미를 보면 스팸 방지를 위해서 만들어놓은 일정의 지연 장치다. POW의 유래는 자꾸 스팸메일을 보내서 막기 위해 메일을 요청하기 전에 일정 시간을 쓸 수밖에 없도록 어떠한 조건을 걸어놓은 것이다.
이것을 이해하기 쉽게 비슷한 것을 들고 왔다. 바로 captcha다. 자꾸 사람들이 과도한 반복 요청, 매크로를 하니까 이를 막기 위해 어느 정도 시간이 걸리는 문제를 내는 것인데 거의 비슷하다고 보면 된다.
POW에는 다양한 형태가 있는데 사실 그건 중요하지 않다. POW라는 것이 과도한 요청을 막기 위해 존재한다는 것이 가장 중요하다.
비개발자
왜 10분이라는 시간이 지나야 데이터를 쓸 수 있도록 불편하게 설계해놨는지 궁금할 수 있는데 데이터의 읽고 쓰는 것이 너무 쉬워버리면 보안성, 효율성이 떨어지게 된다. 그렇기 때문에 비트코인은 문제를 푸는데 대략 10분이라는 시간이 걸리도록 세팅을 해놨다.
개발자
POW의 해결 시간을 왜 평균적으로 10분으로 해놨는지 다양한 의견이 있다. 그중 한 가지 예를 들자면 트랜잭션이 블록체인에 올라가면 전체 네트워크에 전파되기까지 약 1분 정도 걸린다고 한다. 그러면 1분 동안 채굴하기 위해 소모된 리소스가 아무 의미가 없어진다. 만약 10분이라는 시간이 POW의 해결 시간이면 대략 10%의 해시 파워가 낭비된다고 볼 수 있다. 만약에 이 시간이 2분으로 짧아지면? 50%의 해시 파워가 낭비되는 것으로 볼 수 있다.
비트코인은 왜 10분이라는 시간을 트랜잭션의 생성 시간으로 했는지 오래 탐구해봤는데 간단한 내용은 아니라서 추후에 다른 게시물에서 정보를 정리할 생각이다. 일단은 이 정도로만 알고 넘어가자!
따지고 보면 "갓토시 나가모토가 10분으로 해놔서" 가 정답이다 ㅋㅋ
5. POW - hashcash
블록체인의 POW에는 다양한 유형이 있다.
한번 알아보자
그만 알아보자
비트코인이 사용하는 POW는 hashcash라고 해서 최초의 작업 증명(POW)이며 유명하다.
비슷한 로직의 소스코드도 널리 퍼져있어서 hashcash POW에 대해서 탐구해보도록 하겠다.
비개발자
상식적으로 생각해보면 보통 수학 문제를 낼 때 잘 만든 문제를 내기 위해서는 출제자가 더 오래 고민한다. 그러면 문제를 어떻게 내주길래 고성능의 컴퓨터가 푸는데만 10분이 걸리는 문제를 생성할 수 있는 걸까?
hashcash POW의 원리는 문제의 정답을 알았을 때는 이것이 정답이라는 것을 순식간에 알 수 있지만 정답을 찾는 과정은 아직 현대 기술로는 엄청난 시간이 걸리는 형태의 문제다.
sha256이라는 암호화 기술이 있는데 아무 문자를 암호화시키면 해시 코드라고 해서 규칙성 없는 일련의 코드를 생성한다. 이 해시 코드의 특징은 해시 코드만으로는 원래 문자열이 뭔지 알아내기 힘들지만 원본 문자를 아는 경우 해당 원본 문자가 정말 해시 코드의 원본 데이터인지 진위여부를 판단하는 것은 굉장히 쉽다.
여러분의 계정 비밀번호도 위와 같이 암호화를 통하여 DB에 저장된다. 비밀번호 원문을 저장하는 건 법에 걸리기 때문에 여러분이 원문을 입력할 때마다 동일한 암호화를 통하여 해시값이 동일한지 판단하여 로그인을 시켜준다.
그럼 각설하고 POW의 hashcash는 어떤 형태의 값을 찾도록 하는지 말해보겠다.
데이터와 특정 문자를 합쳐서 sha256 암호화를 하면 해시가 생성되는데 그 해시의 맨 앞자리에 0으로 연속된 숫자가 나오도록 하는 것이다.
예를 들면 이번 데이터를 올리기 위해서 맨 앞자리가 0000으로 시작하는 해시를 필요로 하면 컴퓨터는 올리고 싶은 데이터에 랜덤 값을 추가해서 앞자리가 0000인 해시가 될 때까지 계속해서 연산 작업을 하는 것이다.
개발자
sha256과 해시에 대해서 충분히 알 것이라고 가정하고 얘기하도록 하겠다.
POW hashcash의 대략적인 로직은 위와 같다. 데이터를 올리고 싶은 사람의 data와 반복될 일 없는 nonce라는 값을 포함시켜서 sha256 해시를 만들고 그 해시의 앞자리에 difficulty 값만큼 0이 반복되는 해시가 나올 때까지 계속해서 돌리는 것이다.
6. 여기서 다시 짚어보는 채굴 행위란?
여기서 한번 더 큰 시점으로 채굴이라는 행위에 대한 이해를 해보자.
먼저 데이터를 올리고 싶은 수많은 이용자가 있을 것이고 채굴자는 이 중 수수료가 높은 데이터 위주로 데이터를 넘겨받아 POW를 통하여 해당 데이터를 블록체인상이 올릴 수 있도록 기여를 하고 보상으로 코인을 받는다.
근데 여기서 난이도라는 개념이 빠지면 또 섭섭하기 때문에 마지막은 채굴 난이도에 대하여 설명하면서 마치도록 하겠다.
7. 비트코인 채굴 난이도
채굴이 꿀이라는 소문이 여기저기 퍼지면서 채굴자는 기하급수적으로 늘어나기 시작했다. 채굴자가 많아진다면 아무래도 문제를 푸는 데 걸리는 시간은 더 짧아질 수밖에 없다. 하지만 비트코인은 채굴자가 많아지더라도 해당 상황을 인지하여 POW 문제를 해결하는 데 걸리는 시간을 절대적으로 동일할 수 있도록 난이도를 가변 변수로 설정해놨다. 즉 채굴자가 많아질수록 난이도가 높아지는 것이고 그렇게 되면 아까 POW에서 필요로 하는 앞자리 0의 개수를 점차 늘리는 것이다.
위 사이트는 과거 비트코인 채굴자의 채굴 이력을 볼 수 있는 페이지다.
해시를 보면 앞자리 0이 들어가 있는 것을 볼 수 있고 아래 당시 채굴 난이도(Difficulty)도 적혀있다.
위 그래프는 비트코인의 채굴 난이도를 의미한다. t는 trillion으로 조를 의미하며 난이도가 비트코인이 꿀이라는 소식이 여기저기 퍼지면서 점차 난이도가 상승하는 것을 볼 수 있다.
난이도가 상승할수록 채굴 대비 떨어지는 수익률이 줄어들기 때문에 자연스럽게 개인 채굴자는 줄어들 것이며 대형 채굴업체들이 다 같이 만족할 만큼의 인프라가 형성될 것이다.
채굴 비용이 너무 과하면 자연스럽게 채굴자가 줄어들 것이고 채굴 효율이 너무 좋으면 다시 채굴자가 늘어날 것이기 때문에 난이도라는 가변 변수 앞에 인간들이 통제된다고 볼 수 있다.(??)
위 사진은 난이도에 따른 해시값에 대한 예시다. POW - hashcash 방식이 대충 이런 느낌으로 돌아간다고 보면 된다.
8. 채굴 난이도 동적 조절
그럼 여기서 궁금한 것이 있다. 비트코인은 어떻게 난이도를 가변 변수로 설정해놨을까?
굉장히 복잡할 것 같지만 엄청 간단한 로직이라서 채굴 난이도 동적 조절에 대한 개념적인 부분까지 설명하고자 한다.
비개발자
채굴이 정상적으로 이뤄질 때마다 당시 시간이 기록된다.
비트코인의 이상적인 채굴 시간은 10분으로 설정되어 있는데 100번째 채굴이 10시 30분에 이뤄졌고 101번째 채굴이 10시 35분에 이뤄졌다면 예상했던 것보다 5분 빠르게 채굴된 것이기 때문에 난이도가 너무 쉬워졌다고 볼 수 있다.
블록체인 네트워크는 인지하여 난이도를 올리고 다음 블록은 해당 난이도를 반영하여 채굴하게 된다.
위의 그림과 같이 채굴이 너무 빠르면 난이도를 높여주고 채굴이 너무 오래 걸리면 난이도를 줄여주는 것을 볼 수 있다.