반응형

 

구글에서 대용량 아키텍쳐 설계 대한 2일짜리 워크샵을 진행한다고 해서 신청을 했다. 신청한 사람 중에 일부만 참석할수 있는 워크샵 이어서 선정이 안될까 조마조마 했다. 워크샵 내용은 아래 표처럼 이틀동안 강의도 듣고 실습도 해볼수 있는 일정이었다. 교육은 "대용량 아키텍처와 성능 튜닝" 저자인 조대협님께서 직접 해주셨다.

 

우선 기술적인 자세한 내용들은 워낙 방대하고 적을수 없어서 여기에다 일일이 적지는 않겠다.  기술적인 내용보다는 첫날 들었던 "아키텍트"는 어떻게 해야 하는지에 대해서 몇가지 인상깊었던 것에 대해 적어보려고 한다. 


아키텍트는 전달을 잘해야 한다. 

아키텍트는 설계를 하는 사람이다. 아니, 설계만 하는 사람이라고 생각을 했었다. 그런데 그것도 중요하지만 다른 중요한것이 있었다. 바로 커뮤니케이션이다. 아키텍트는 설계를 한후 개발팀이 설계한 것을 보고 개발을 할수 있도록 전달을 해야 한다. 그렇기 때문에 개발팀과의 커뮤니케이션이 정말 중요하다. 보통 설계 문서를 주지만 이건 한계가 있다. 왜냐? 개발자들은 설계문서를 잘 안본다는 안타깝지만 사실에 가까운 팩트이다. 결국 찾아다니면서 설명을 해줘야 한다. 그리고 말보다는 그림이 더 설명을 하기도, 이해를 하기도 쉽다.



위 사진을 한번 살펴보자. 인스타그램 같은 앱에서 사진을 올렸을 경우 사진을 저장하는 절차를 설계한 그림이다. 모바일컨트롤러(MC) 에서 API Gateway를 거쳐서 인증을 받은후 API 서버를 거쳐서 사진을 저장하게 된다. 각각의 흐름에는 번호가 붙어 있다. 각각의 트랜잭션이 일어날때 마다 필요한 DATA 와 받는 Data도 표현을 해준다. 각각의 번호는 하나의 RestAPI 로 설계가 될수 있다. 이런 형태로 하나 하나 다 정의를 해줘야 한다고 한다.(아키텍트는 정말 힘든 직업인것 같다 ㅡㅡ;;)  


그리고 커뮤니케이션과 더불어서 개발팀의 능력치 파악도 중요한 포인트이다. 개발팀의 능력에 따라서 일의 양이나 일정을 결정 할 수 있다. 그리고 누구한테 어떤 일을 맡겨야하는것 까지 파악이 된다면 정말 도움이 많이된다. 이런 것들을 잘 파악하기 위해서는 같이 술을 먹어야 한다고...


아키텍처는 상황에 따라서 변한다.

설계 변경이야 늘 있는 일이라서 새삼 놀랍지도 않은 일이다. 아침에 받았던 설계를 점심 이후에 다시 가져와서 수정해야 된다고 들은적이 정말 많다. 그런데 하나의 product를 유지하기 위해 환경이 변화해서 전체 아키텍처가 변경이 된다는 말에서 놀랐다. 

처음 product  를 만들 때에는 정해진 feature를 만들어서 제공하기 위한 제품 위주의 아키텍처 였다고 가정해 보자. 제품을 출시하고 나면 다른 경쟁사들에게 뒤쳐지지 않기 위해서 빠르게 개발해서 빠르게 대응할 수 있는 아키텍처가 필요하다고 한다. 이런 형태로 처음 구상했던 아키텍처를 끝까지 가지고 가는게 아니라 변화하는 상황에 빨리 대응하기 위한 형태로 아키텍처를 그때 그때 알맞게 변경을 해야 한다고 한다. 생각해 보면 하루에도 수십개, 수천개씩 쏟아져 나오는 product들 사이에서 살아 남으려면 변화는 필수인것 같다. 그리고 아키텍처도 예외는 아니라는 것이다. 


이틀간의 짧은 시간동안 많은 내용을 배웠다. 모든 내용을 다 이해해서 내 머릿속에 담을수 있었으면 더 좋았겠지만 아직은 좀 무리였다. 하지만 앞으로 공부를 더 해나가면 발전할 수 있을거라는 생각은 한다. 오랜만에 다녀온 워크샵에서 좋은 지식과 자극을 같이 얻을수 있어서 너무 좋았다. 


728x90
반응형

'Development > Tech&Seminar' 카테고리의 다른 글

TCC가 뭐지???  (0) 2018.09.07
Openssl로 SSL 을 위한 인증서 발급하기 (HTTPS)  (2) 2018.08.22
#2 OpenID Connect Flow  (0) 2018.08.14
#1 Open ID Connect 가 뭐야???  (0) 2018.08.07
Google Cloud Study Jams 후기  (0) 2018.05.15
반응형

추구자가 된 에일로이는 이제부터 모험을 떠나기 시작한다. (이건 내 추측이다. 나도 엔딩을 아직 못봤으니깐.)

그리고 이번에 처음으로 스트라이더를 강제 전환해서 탈수 있게 된다. 강제 전환이라는 것은 스트라이더를 접촉해서 전환을 시키면 온순한 상태로 되는데 그때 탈수 있다. 뒤에 가면 스트라이더 뿐만 아니라 다른 기계들도 적용될거라 예상이 된다. 강제전환은 마치 영화 아바타에서 날아다니는 공룡같은거 올라탈때 꼬리에 있는 것을 연결 하듯이 전환을 시키는 것과 유사하다. 


그리고 관문을 지키고 있는 바를 과 대화를 하고 전투 족장을 찾아보겠다는 퀘스트를 받게 된다. 여기에서부터는 퀘스트가 한개만 존재하는게 아니라 여러개가 동시에 진행되는것 같다. 이 퀘스트 뿐만 아니라 다른 퀘스트도 계속 열려서 약간 뭐부터 진행을 해야 할지 헷갈린다.






확인해보니 내가 진행하던 퀘스트를 다 안끝내고 다른 퀘스트를 또 얻어서 이렇게 된것 같긴하다. -_-;;;

그리고 내가 퀘스트 진행하면서 정말 어이없게 많이 죽은 톨렉 강제전환하기.

처음에는 쉽게 강제전환이 될줄 알았다. 딱보니 등에 올라타서 가시같이 생긴거 잡고 올라가면 될것 같아서 해봤는데 이상하게 잘 안됐다. 그리고 계속 떨어져서 죽었는데 알고보니 등쪽에 너무 붙어서 점프를 누르면 이게 뛰질 않고 밑으로 매달리는 것이었다. 너무 등쪽에 가깝게 붙어있지 않고 점 떨어져서 점프를 누르니 그제서야 다른 방향에 있는 가시를 잡고 올라타기 시작했다.



정말 쉬운 퀘스트인에데 어이없게 많이 죽었다. 


728x90
반응형
반응형

아침 저녁으로 출퇴근 하면서 생활코딩의 "지옥에서 온 Git" 을 듣고 있는데 재미있는 내용이 있었다.


https://www.youtube.com/playlist?list=PLuHgQVnccGMA8iwZwrGyNXCGy2LAAsTXk


Git 을 사용하면 프로젝트 폴더 안에 .git 이라는 폴더가 생긴다. 생긴다라고만 알고 있었고 여기에 뭔가 history 가 저장되겠거니 라는 추측만 했었다. 실제로 열어본적도 없어서 뭐가 들어있는지도 몰랐다. 그런데 강의 내용중에 Git 명령어를 실행될 때에 어떻게 그 History를 저장하고 추적하는지에 대해서 설명을 해주었다. 


Git 을 사용할 경우 Add 명령을 이용해서 새로 생성된 파일을 stage area 영역으로 추가할수 있다. 이때에 .git 디렉토리 안에 objects 라는 폴더에 새로운 폴더가 생성된다. 


  


왼쪽 화면과 오른쪽 화면을 보자. 왼쪽화면은 잘은 안보이겠지만 현재 내가 작업하고 있는 WORKSPACE 에서 파일을 수정하고 "git status" 명령어를 실행했을 때의 모습이다. 빨갛게 파일 이름이 보이고 modified 라고 써있다. 그리고 오른쪽은 gistory 라는 git log 분석하는 툴이다. 오픈소스 툴이며 https://github.com/egoing/gistory 에 가면 설치 방법을 확인 할 수 있다. 내가 지금가지 commit 한 내용이 오른쪽 처럼 표현되고 있다. 


 


이제 좀전의 build.gradle 파일을 ADD 명령어를 이용해서 ADD를 했다. 어떤 변화가 일어났는지 확인을 해봤다. 오른족에 보면 맨 위에 2개 파일에 just now라고 써있다. 그 2개가 변경이 됐다는 의미이다.



우선 objects를 선택해서 보니 내가 변경한 파일의 내용이 보여진다. [blob]a97..... 라는 key로 되어있다. 그리고 보면 앞에 a9는 objects 폴더의 하위 디렉토리 명으로 되어있다. 





이번에는 좀전에 그 파일을 commit 을 해보았다. 그랬더니 위에 화면처럼 많은 파일들이 변경이 되었다. 그중 몇개 파일을 살펴 보았다.



이 파일에는 [commit] 이라는 타입의 object 이다. 안에 내용을 보면 tree 라는 것이 있고 parent 라는 것이 있다. 그리고 commit 을 한 사람 정보가 나오고 마지막에는 commit 할때 작성했던 message 가 있다. tree 는 현재 commit 한 시점의 모든 file 들이 tree 형태로 존재를 하고 있다. 그리고 parent 는 이전 commit 에 대한 정보들을 담고 있는 object 이다. parent 도 tree 처럼 구성이 되어있을 것이다. 이처럼 commit 을 하게 되면 현재의 파일들을 현재 모습 그대로 snapshot을 찍게 된다. 



그리고 tree 를 클릭해보면 이렇게 파일들을 볼수 있다. 파일의 형태는 단일 파일일 경우 blob 으로 표시 되어있고 또 폴더 일 경우 tree 로 표시가 되어있다. 


결론적으로 Git 이라는 툴은 파일이 변경되고 추가되고 한 작업의 모든 부분을 object 화 해서 관리를 하고 있다. 그 object 가 단일파일일 경우도 있고 tree 형태를 할 경우도 있다. 그리고 commit 자체도 하나의 object 로 관리가 되고 있다. 이런 형태로 파일들이 관리가 되고 있었다니 정말 놀라웠다. 


Git을 쓰고 있긴 하지만 부족한것 같아서 듣기 시작한 강의 였는데 정말 듣기를 잘했다는 생각이 들었다. 아직 다 듣지 않아서 앞으로 들을 내용들이 더 기대가 된다.


728x90
반응형
반응형

Oauth 2.0 에 대해서 공부를 하다가 용어에 대한 명확한 이해가 필요해서 정리를 했다.


Access Token : 보호된 리소스에 일정 기간동안 접근할 수 있는 권한을 가진 문자열

- Scope : Token 소유자가 접근할수 있는 보호된 리소스 셋


Client : Resource를 이용하려고 하는 Web 이나 App. 

Resource Sever : 실제 정보를 가지고 있는 대상. 

Resource Owner : Resource 에 대한 소유자.


Access Token 을 얻는 절차는 아래처럼 설명할 수 있다.


Resource Owner 

 Client

 Resource Server

 1. Client 에게 정보 요청


 

 

 2. Resource Server 에 있는 Resource Owner의 정보를 접근 할수 있는 권한 요청

 

3. Resource Server 에 로그인

(Client 에서 Resource 서버에 로그인할수 있는 페이지를 바로 연결해줌)

 


 4. Resource Server에 있는 Resource Owner의 특정 정보에 Client가 접근하는것을 허용하는지 여부 확인 (Yes/No)

 

 

 

 

 5. Resource Owner 가 Client의 접근을 허용할 경우 Client 에게 Code를 보냄

 

 6. Code를 받아서 Client_id, secret를 code와 함께 Resource Server로 보냄

 
  

 7. Client가 보낸 client_id, secret, code를 확인한 후 access tockent을 발급

 

 8. 발급받은 access token으로 Resource Server 에 있는 owner 의 정보에 접근.

 


위 표에서 설명한 것은 Access Token을 얻는 방법중 한가지에 대해서 설명한 것이다. 꼭 이것과 동일하지 않을 수 있다. 그렇지만 저런 한가지 흐름을 알아 두면 다른것을 이해하기에 도움이 될거라 생각이 된다. 


728x90
반응형
반응형
이번 퀘스트는 "산의 자궁" 이라는 퀘스트이다. 1,2,3번 동영상 까지는 스토리 전개 느낌이 많이 난다. 
앞 퀘스트에서 습격을 받은 에일로이는 죽을뻔 하지만 로스트 덕분에 살아남는다. 하지만 부상때문에 한동안 누워있다가 깨어나게 된다.


가지고 있던 포커스를 통해 다른 사람과 통신을 하거나 이야기를 들을 수 있다는 것을 알게 된다. 생각해보니 드래곤볼에 나오는 스카우터랑 비슷하다는 생각이 들었다. 모양은 다르지만 귀에 꼽고 뭔가를 탐지하고 정보를 얻는 기능이 있으니 스카우터랑 거의 똑같다고 봐도 될것 같다.


티어사는 에일로이를 추구자로 임명한다. 그리고 에일로이는 신성한 땅의 경계 너머로 모험을 떠나게 될것 같다. 




레시는 역시 에일로이가 추구자로 된것이 못마땅해보인다. 아마도 레시가 게임 마지막까지 살아있다면 거의 끝에 가서야 에일로이를 인정해줄것 같다. 그리고 레시와 대화를 하던중 기계들의 습격을 받게 된다. 그런데 기존과 다른 점은 한 기계가 다른 기계를 조종해서 습격을 하도록 유도했다는 점이다. 



오염된 기계들을 쳐 부수고 다 때려부수면 이 산의 자궁 퀘스트는 끝이 난다. 이번 퀘스트는 실제로 싸우는 것보다는 이야기가 많아서 수월하게 끝났다. 


728x90
반응형
반응형

Spring Security 를 적용하는 내용을 처음부터 차근차근 정리를 해보려고 한다. 

목표는 Spring Security 를 공부하면서 각각의 기능들을 적용해보는것이다. 진행하다보면 Spring Security 뿐만 아니라 다른 내용들도 점점 추가될것 같다. 다 만들고 나서는 git에 소스를 공유할 생각이다. ^^;; 언제가 될지는 잘 모르겠다.


환경 : java 1.8, Spring Boot 1.5.3 Release, Maria DB, JPA, gradle


build.gradle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
buildscript {
    ext {
        springBootVersion = '1.5.3.RELEASE'
    }
    repositories {
        jcenter()
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}
 
apply plugin: 'java'
apply plugin: 'org.springframework.boot'
 
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
 
repositories {
    jcenter()
    mavenCentral()
}
 
 
dependencies {
    compile('org.springframework.boot:spring-boot-starter-web')
    compile('org.springframework.boot:spring-boot-starter-data-jpa')
    compile('org.springframework.boot:spring-boot-starter-security')
 
    testCompile('org.springframework.boot:spring-boot-starter-test')
 
    runtime ('org.mariadb.jdbc:mariadb-java-client')
}
cs



아직 초반이어서 라이브러리가 몇개 없다. spring-boot 에서 사용하는 jpa, security, test, web 라이브러리가 끝이다. 그리고 DB를 사용하기 위한 mariadb client까지만 추가되어있다.


도메인.

Account.java

1
2
3
4
5
6
7
8
9
10
11
12
13
@Entity
public class Account {
    @Id
    private String loingId;
 
    private String username;
 
    private String password;
 
    private String email;
 
    private boolean enabled;
}
cs


Account 도메인이 있다. 만들기는 더 여러개 만들어놓았는데 우선은 이것만 필요해서 적었다. 위 Account.java 소스에는 getter/setter 메소드는 삭제하고 올렸다. (너무 길어서)


다음은 Account 관련 Service와 Repository 이다. 


AccountRepository.java

1
2
public interface AccountRepository extends JpaRepository<Account, String> {
}
cs


AccountService.java

1
2
3
4
public interface AccountService {
    Account get(String loginId);
}
 
cs


AccountServiceImpl.java

1
2
3
4
5
6
7
8
9
10
11
@Service
public class AccountServiceImpl implements AccountService {
 
    @Autowired
    private AccountRepository accountRepository;
 
    @Override
    public Account get(String loginId) {
        return accountRepository.findOne(loginId);
    }
}
cs


Repository를 다이렉트로 호출해도 되긴 하지만 아무래도 구조상 service 레이어가 있는게 맞다고 판단해서 repository는 Service 에서 호출하도록 한번 감쌌다. 지금은 간단히 호출만 하지만 나중에는 로직도 들어갈것이 예상된다.


CustomUserDetailService.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Service
public class CustomUserDetailService implements UserDetailsService{
 
    @Autowired
    private AccountService accountService;
 
    @Override
    public UserDetails loadUserByUsername(String loginId) throws UsernameNotFoundException {
 
        Account account = accountService.get(loginId);
 
        List<GrantedAuthority> grantedAuthorities = new ArrayList<>();
 
        User user = new User(account.getLoingId(), account.getPassword(), grantedAuthorities);
 
        return user;
    }
}
cs


UserDetailsService에 있는 loadUserByUsername 메소드를 제정의 해서 UserDetails 객체를 정의해준다. UserDetails는 사용자의 인증정보를 담고있다. 위에서 Account Service에서 loginId로 정보를 조회해서 가져온 id, password, 권한(아직 미구현으로 객체만 생성했다) 정보를 user로 생성해주고 있다.




ResourceSecurityConfiguration.java

1
2
3
4
5
6
7
8
9
10
11
12
@Configuration
@EnableGlobalAuthentication
public class ResourceSecurityConfiguration extends WebSecurityConfigurerAdapter {
 
    @Autowired
    private CustomUserDetailService customUserDetailService;
 
    public void init(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(this.customUserDetailService);
    }
}
 
cs


WebSecurityConfigurerAdapter에 있는 init 메소드를 사용해서 AuthenticationManangerBuilder에 userDetailService를 내가 새로 만든 CustomUserDetailService를 사용하겠다고 설정해준다.


StudySpringApplication.java

1
2
3
4
5
6
7
8
9
10
@SpringBootApplication
public class StudySpringApplication {
 
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(StudySpringApplication.class);
 
        app.run(args);
    }
}
 
cs


application.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
server:
  port: 9000
 
spring:
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost:3306/holmes
    username: root
    validation-query: select 1
    test-while-idle: true
    time-between-eviction-runs-millis: 300000
    test-on-borrow: false
 
  jpa:
    database: mysql
    show-sql: true
    hibernate:
      ddl-auto: update
    properties:
      hibernate:
        format_sql: true
        dialect: org.hibernate.dialect.MySQLDialect
        default_schema: holmes
cs


이제 어플리케이션을 실행해보면 로그인 페이지가 나온다. 





위에 소스와 약간 차이가 있을수 있지만 아래 Git repository 에 가면 소스를 확인할 수 있다. 


https://github.com/blusky10/study_spring


728x90
반응형
반응형

드디어 에일로이가 증명의 의식을 참가하게 된다. 


증명의 의식은 2가지의 퀘스트로 진행되는데 하나는 "버려진 용사의 길 달리기" 이다. 증명의 의식 자체가 이 용사의 길의 끝을 누가 빨리 도착하느냐에 따라서 우승자가 가려진다. 그렇기 때문에 다른 참가자들보다 빨리 이 길을 통과해야 한다. 모든 조작이 사용자에게 맞겨지는것은 아니기 때문에 천천히 가도 되는것같다. 가는 길을 좀 헷갈려서 몇번 떨어져 죽긴 했지만 그래도 무사히 도착할수 있었다. 



다른 참가자들이 날고 기고 한다고 하더라도 역시 우승은 에일로이이다. 하지만 기쁨을 누리는것도 잠시뿐이었다. 갑자기 화살이 날아오고 주변에 같이 있던 참가자들은 다 죽고 만다. 그리고 바로 "공격자사살하기" 퀘스트로 이어진다. 



공격자 사살하기 퀘스트는 날아오는 화살을 피하면서 진행을 해야한다. 숲풀에 숨어서 옆으로 돌아가서 쳐도 되지만. 일단 숨어서 기다리다 보면 적 2명이 다가오는데 이 2명을 죽이고 나면 데스브링어건을 얻을수 있다. 그런데 생각보다 적 2명이 쎄다. 그냥 설렁설렁 대충 하면 바로 죽는다. 현재 에일로이보다 전투력과 방어력이 높은것 같다. 어쨌든 데스브링어건을 얻긴 하는데 이게 무거워서 이동하는데 정말 극악이다. 들고 움직이다가 포탄 맞아서 몇번 죽기도 했다. 조준도 힘들어서 그냥 당겼더니 어느새 총알이 다 떨어져버렸다. 그래서 역시 옆길로 돌아가서 적들을 다 해치우지만 방심하다가 적에게 잡힌다. 

그런데 어디선가 나타난 로스트가 적과 싸우지만 역부족이었다. 로스트와 에일로이 근처에 설치된 폭탄을 보고 로스트는 에일로이를 살리기 위해 낭떠러지로 밀고 자신은 죽는다. 이렇게 증명의 의식 퀘스트는 마무리 된다.



728x90
반응형
반응형


회사에서 Spring boot를 사용하기 시작한지는 한 1~2년 정도 된것 같다. 쓴다기 보다는 Spring 사이트에 있는 소스들을 가져다 붙이는 수준이었다. 체계적으로 공부해본적은 없고 눈앞에 닥치면 찾아서 하다보니 부족한 점이 많이 느껴졌다. 이번에 받은 이 "실전 스프링 부트 워크북"은 그런 부족한 점을 채워줄수 있는 좋은 가이드가 되었다. 


Chapter 1에서 부터 4까지는 Spring Boot를 실습하기 위한 준비 단계정도로 볼수 있다. 기본적인 이론과 설명들, 프로젝트 구성에 대해서 소개를 해주고 있다. 그리고 Chapter 5부터 본격적으로 Spring Boot를 가지고 Web 어플리케이션을 만들기 시작한다. 



특히 Chapter 6 을 보면 Spring Boot Test 에 대해서 설명을 하고 있는데 책을 읽을 당시 회사에서 Spring Boot Test에 대한 내용을 한참 구글링 하던 시기였다. 내가 개발중인 코드에 대한 Controller Test case를 어떻게 작성을 해야 하나 고민을 하던 중이었는데 책의 내용들이 내게 많은 도움이 되었다. 아마도 이 책이 없었으면 코드가 뭐가 뭔지도 모를 코드들을 가져다가 썼을것이다. 




그리고 이 책의 좋은 점이 실제 작성된 코드에 대해서 중요한 부분에 대한 설명들이 많이 있다는 점이다. 다른 Spring 관련 책들도 소스 코드에 대한 설명들이 있기는 하지만 너무 추상적이거나 어렵게 설명한 책들이 많다. 하지만 이책에서는 적어도 내 기준에는 각각의 소스 코드에 대한 설명들이 이해하기가 쉬웠다. 그리고 개발관련 서적의 딱딱함이 덜 하다는 느낌이 들었다. 


기본적인 Spring Boot 에 대한 설명부터 시작해서 security, 메세징등 기본적으로 알아야 할 기능들은 잘 설명해 놓은 책이다. 물론 이거 한권으로 Spring Boot에 대한 모든 기능을 마스터 할수는 없지만 기본기를 다지기에는 아주 좋은 책이라고 생각이 든다. 단지 아쉬운 점은 이 책에도 중간중간 언급이 되어있지만 지금 사용하고 있는 Spring Boot 최신 버전과는 약간 차이가 있을 수 있다는 점이다. 책에서는 1.3.3 Release 버전을 사용하고 있는데 현재 Spring Boot 최신 버전을 1.4를 넘어 1.5, 2.0을 바라보고 있다. 이부분에 대한 것만 제외 한다면 Spring Boot에 관심 있는 분들에게 한번쯤 읽어보라고 추천해주고 싶다. 


728x90
반응형
반응형
AWS 에 가상서버를 하나 만들면 이 서버를 시작하고 정지 할 때마다 공인 IP 주소가 변경된다. 그래서 AWS 는 Elastic IP 라는 고정 공인 IP 주소를 할당해 주는 서비스를 제공해주고 있다. 


EC2 서비스에 보면 왼쪽에 Elastic IPs 라는 메뉴가 보인다. 



메뉴에 들어가보면 위와 같은 화면이 나온다. Allocate new address를 클릭하면 아래와 같이 Elastic IP가 할당된다.



IP가 할당되었으니 이제 가상서버하고 연결을 해주면 된다.





Actions 메뉴에 있는 Associate address를 선택한다. 




Instance 항목에 가상 서버의 인스턴스 ID를 입력하면 된다. 콤보박스로 선택하게 되어있다. 



그러면 이렇게 연결이 완료된다. 


가상 서버 만드는 것만큼이나 아주 간단하고 쉽다. 



728x90
반응형

'Development > AWS' 카테고리의 다른 글

네트워크 관련 내용들  (0) 2023.01.13
[AWS] EC2 Ubuntu 서버에 FTP 서버 설정  (0) 2018.04.01
[AWS]AWS 에 가상서버 만들기  (0) 2017.06.17

+ Recent posts