P2IM

• Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling(Usenix 2020)
• Processor-Peripheral Interface Modeling
• 펌웨어를 MCU의 펌웨어로 국한
  
  
  

[Open Challenges]

1. Hardware Dependence

하드웨어 의존은 퍼징하는데 delay를 만들고, 병렬처리를 하는데 한계가 존재.
즉, 병렬 퍼징이 힘들다.

2. Wide Range of Peripherals

최근에는 펌웨어의 에뮬레이션 기반 퍼징만 제안이 있어왔음.
그러나 에뮬레이팅된 MCU를 생성하는것은 비 실용적이고, 존재하는 에뮬레이터는 MCU를 지원하지 않음.
때문에 보통 퍼징이나 테스팅을 위해 에뮬레이터를 커스터마이징함.
이른 에러도 많고, MCU의 종류가 많아 현실적으로 힘든 부분이 존재.

3. Diverse OS & System Design

기존의 퍼저들을 펌웨어 퍼징에 적용하기 어렵다.
MCU는 일반적인 OS(Linux)가 아닌 MCU를 위해 설계된 OS를 사용.

4. Incompatible Fuzzing Interface

펌웨어의 모든 인풋은 다양한 종류의, 자신만의 convention을 가진 peripheral을 통해 들어옴.
그래서 일반 퍼저들의 인풋 인터페이스는 MCU 펌웨어에 부적절.

[Processor-Peripheral Interfaces]

• 펌웨어는 직접 off-chip에 접근할 수 없기 때문에 On-chip peripheral만 다룸.
• 레지스터와 인터럽트를 통한 peripheral I/O 인터페이스를 다룸.
• DMA를 통한 peripheral I/O 인터페이스는 제외.
  
  

[P2IM]

1. Abstract Model

- P2IM에 접근할때 펌웨어가 따르는 컨벤션이나 패턴들을 MCU Device 데이터 시트 또는 프로세서 Doc를 통해 수집.
- 이 단계는 전문가들에 의해 이루어지는 오프라인 수작업 단계(only manual step in P2IM).
- 일단 ARM Cortex-M 프로세서만 available.
- 다른 아키텍쳐를 위한 abstract model을 정의하는건 미리 정의된 템플릿이 있기때문에 많은 노력없이도 가능.
- 이 단계는 MCU 아키텍쳐별로 한번만 이루어지는 과정이고, 대부분의 MCU는 동일한 아키텍쳐(ARM Cortex-M)를 사용.
- first, peripheral 레지스터를 4개로 분류후, 각 레지스터별 엑세스 패턴과 엑세스 핸들링 방법을 제공.
    * Control Register(CR)
    * Status Register(SR)
    * Data Register(DR)
    * Control-Status Register(C&SR)
- second, peripheral을 대신해 에뮬레이터가 인터럽트할 방법을 정의.
    * ex) 인터럽트가 인풋이 준비되었다는 신호를 펌웨어에 보내면, ISR(Interrupt service routine)이 동작하고, 데이터 레지스터에 있는 인풋을 읽음
    * 인터럽트 전략은 간단한 방식인 Round-Robin.

2. Model Instantiation

- abstract model을 인스턴스화 하여 분석할 펌웨어를 완전한 모델로 생성하는 단계.
- firmware-specific한 정보를 자동으로 추론.
- deterministic하고 repeatable한 작업.
- 인스턴스화 된 모델은 펌웨어 특화된 정보를 포함.
    1. 식별된 memory mapped 레지스터, 메모리 위치, 타입
    2. 레지스터 타입별 엑세스 핸들링 전략.
    3. enabled 인터럽트 전략.
- peripheral config 관련정보는 불포함.

- peripheral을 에뮬리이팅 하지않은 에뮬레이터에서 펌웨어를 실행.
- 펌웨어가 Processor Peripheral Interface에 접근할때 계속적으로 모델을 인스턴스화 함.

[Implementation]

• QEMU + AFL
• AFL은 유저모드 에뮬레이션만 지원하는데, AFL을 QEMU의 full system 에뮬레이션 모드에 연결되도록 브릿지 해야함.
• TriforceAFL은 full system 에뮬레이션을 지원하기 때문에, TriforceAFL의 코드를 통해 AFL을 QEMU에 연결.
• 퍼저에 의해 생성된 인풋은 DR(Data Register)를 통해 펌웨어에 전달.
• QEMU를 통해 코드커버리지 정보를 수집후 퍼저에 전달.
  
  
  

[Unit Test on MCU Peripheral & OS]

• On-Chip에서 가장 popular한 8개의 Peripherals.
• OS/system libraries(NuttX, RIOT, and Arduino)
• SoCs (STM32 F103RB, NXP MK64FN1M0VLL12, and Atmel SAM3X8E)

[Real MCU Firmware Test]

드론 펌웨어 : MCU기반 Autopilot 컨트롤러. 센서, 라디오, 모터등을 조종하고, PID 제어기같은 컨트롤 알고리즘 구현.

• Quad-copter drone, Pluto drone
  
  
  

• ACC : 레지스터 분류 정확도
• SR : Status Register
• Time : 모델 인스턴스화 하는데 걸리는 시간

[Fuzzing]

• AFL 퍼저말고 다른 퍼저는 고려하지않음.
• Data Register를 통해 인풋을 펌웨어에 전달.
• memory error detector는 NDSS18 What you corrupt is not what you crash에서 소개한 segment tracking heuristic을 사용.

• 코드 커버리지 측면에서 수치적으로 여전히 낮게 보일수있음.
• dead code(사용하지 않는 라이브러리), 복잡한 path 조건에 최적화되지않은 AFL등의 이유를 원인으로 볼수있음.
• 그러나 input value 뿐만 아니라, input duration(얼마나 오래 인풋 값/신호가 지속되는지)이 펌웨어 실행에 영향을 줄 수 있음.
• MCU 펌웨어 퍼징에 대한 유일한 Challenge는 input duration으로 보고있음.

kvm: the Linux Virtual Machine Monitor (Linux symposium '07)

www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf

[Kernel-based Virtual Machine]

1. 배경

   • 다른 유사한 시스템을 실행하는 컴퓨터를 사용하는 아이디어는 자원을 유틸화 하고 테스팅 하는 목적에 유용하다고 일찍이 인식댐.
   • ibm, vmware, xen등 최근에 기업에서 여러 가상시스템기술을 움직이고있음

2. x86 가상화 확장

   -   x86은 가상화 하기 어려운데
   -   가상화의 중요성을 인식하고 인텔,amd에서 가상화를 좀더 쉽게 만들기위해 x86에 extension들을 추가함
   -   이 extension들은 서로 호환이 잘 안되서 그들은 서로 반드시 유사해야했음
       -   새로운 guest operating 모드 : 시스템이 선택적으로 특정한 명령이나 레지스터접근을 요청하는것 말고는 일반적인 운영모드의 권한을 가지는 guest 모드로 프로세서가 switch 할수있다.
       -   하드웨어 상태 switch : guest모드로 switch할때, 하드웨어는 프로세서 운영모드에 영향을 주는 control 레지스터를 switch한다.
       -   종료 사유를 기록하기 : guest모드에서 다시 호스트 모드로 switch가 발생하면 하드웨어는 switch하는 이유를 기록해서 소프트웨어가 적당한 action을 취하도록 할수있다.

3. 일반적인 kvm 구조

   • kvm은 /dev/kvm에 device node를 열어서 가상머신을 만듬

   • 게스트는 자신의 메모리를 가지고 userspace와 분리댐

   • 가상 CPU는 스스로 스케쥴링 못함

     /dev/kvm

     • kvm은 꽤 전형적인 linux character device로 구성댐

     • 새로운 가상머신 만들고, 가상머신에 메모리 할당, 가상cpu 레지스터 읽고쓰기, 가상cpu로 인터럽트 삽입, 가상 cpu실행

     • user 메모리처럼 커널은 guest address 공간에 형성하기위해 비연속적인 페이지를 할당함.

     • 커널모드 유저모드 이외의 새로운 실행모드인 guest 모드가 추가댐(Figure 2 -> guest mode execution loop 설명)

       명령어 셋의 차이점 조화하기

     • x86 명령어셋과 달리 하드웨어 가상화 extensions는 표준화되지 않음, 인텔과 amd는 명령어, 문법 모두 다름

     • kvm은 커널모듈을 통해 이러한 차이점을 조절함

4. Memory Management Unit 가상화

   • x86은 사용자가 볼수있는 가상 주소를 bus에 접근하기위해 사용되는 물리주소로 변환하는 가상 메모리 시스템을 제공함 => MMU.
     [MMU의 구성]
     • virtual <-> physical 변환하는 radix tree
     • 시스템에 변환오류를 알리는 mechanism
     • page table lookup 을 가속화하는 단일 캐시
     • 독립적인 주소공간을 공급하기 위해 translation root를 변환하는 명령어
     • TLB(Translation Lookaside Buffer)를 관리하는 명령어
   • MMU는 한가지 레벨에서의 변환(guest-virtual => guest-physical)은 제공하지만, 가상화가 요구되는 두가지 레벨(guest-physical => host-physical)에서의 변환은 불가하다.
   • 이에대한 근본적인 해결책은 guest가 제공한 원본 page를 가지고 하드웨어 interaction을 에뮬레이션 하는동안, guset-virtual에서 host-physical로의 변환을 인코딩하는 분리된 page table을 실제 MMU에 나타내는 하드웨어 가상화 능력 사용하는것이다.
   • shadow page table 생산은 증가세이다. 그것은 비워지고 있으며, 변환 실패가 host에 기록되어 missing entry가 추가되었다.
   • guest page table은 원본 메모리에 존재하기 때문에 shadow page table과 동기화하는것은 어렵고 문제가 된다.

   4.1 가상 TLB 실행

    - kvm에서 shadow page table의 초기버전은 성능을 희생하여 코드내 많은 버그를 줄이는 복잡하지 않은 방법을 사용했다.
    - 이러한 방법은 guest가 tlb 관리 명령어를 tlb를 동기화 하는데 사용해야한다는 사실에 의존했다.
    - 그러나 tlb 관리 명령어의 대부분은 컨택스트 스위칭이 대부분이었고, 이는 모든 tlb를 무효화했다.
    - 이것은 shadow page table이 tlb를 refill 하는것보다 좀더 많은 비용을 요구했기 때문에, 다양한 프로세스들의 작업량에 많은 고통을 받는다는것을 의미했다.  

   4.2 가상 MMU 캐싱

    - guest system의 성능을 개선하기 위해, 가상 mmu 실행은 page table이 컨택스트 스위칭을 통해 캐시되도록 하는것을 가능하도록 함으로써 강화되었다.
    - 이것은 code complexity가 증가하는 대신 막대한 성능 증가를 실현했다.
    - guest의 write에 대한 notification을 받기위해 guest page table에 쓰기권한을 protect로 설정했으나, 이것은 추가적인 연쇄적 요구사항을 만들어 이를 충족시켰고, kvm 컨택스트 스위칭 성능이 현재는 적절하게 되었다.
    [요구사항]
        1. 각각의 guest page를 참조하는 모든 writable 변환의 reverse mapping이 유지되어야한다.
        2. x86 명령어 인터프리터를 사용하는 access를 에뮬레이팅 함으로써, 우리는 미리 guest memory와 shadow page table에 미치는 영향을 알 수 있다.
        3. guest는 page table page를 kvm에게 알리지않고 일반 page로 재활용한다.  

5. I/O 가상화

   • VMM은 실제 s/w, h/w에서 처럼 pio(Programmed I/O), mmio(memory mapped I/O)를 에뮬레이팅 하고 가상 하드웨어에서 인터럽트를 받아 시뮬레이션 할 수 있어야함

   5.1 guest측 I/O 명령어 가상화

    - pio를 trap하는것은 복잡하지 않고, mmio를 trap하는것은 꽤 복잡함
    - kvm에서 I/O 가상화는 user 영역에서 진행됨
    - kvm은 user 영역이 guest로 인터럽트를 보내는 메커니즘을 제공함

   5.2 host측 가상 인터럽트

    - guest가 인터럽트를 받을 준비가 되었을때 인터럽트 플래그가 set되고, guest가 준비되면 인터럽트가 보내진다.
    - 이는 kvm이 x86기반의 시스템에 있는 복잡한 인터럽트 컨트롤러들을 에뮬레이팅 하도록한다.

   5.3 Framebuffer 가상화

    - Framebuffer는 memory-mapped I/O 장치의 중요한 부분
    - 전형적인 mmio와 다른 특성(대역폭, 메모리 등가)
    - kvm은 임의의 주소에 비 mmio 메모리를 맵핑하도록 함, 이것은 물리적으로 메모리를 alias하도록하는 VGA windows에 포함됨
    - 또한 framebuffer의 변화를 기록함으로써, display window가 점차 최신화 될수있음  

6. Linux Intergration

   • 리눅스로 통합되는것은 kvm에 중요한 이익을 줌
   • 개발자 측면에서 커널 내 존재하는 기능을 재사용하도록 많은 기회를줌
   • 사용자 측면에서 기존에 있던 리눅스의 프로세스 관리 인프라(top, taskset, kill)를 재사용 하도록함

7. Live Migration

   • 가상화를 진행하는 이유중 하나
   • 이는 한 guest를 한 host에서 다른 host로 쉽게 옮길 수 있도록함
   • 병렬적으로 guest 메모리를 타겟 호스트로 복사함
   • guest page를 복사 후 수정이 발생하면 다시 복사함
   • 마지막에 kvm은 page 로그를 제공하는데 이는 마지막 호출 후 수정된 페이지의 비트맵을 user 영역에 제공함

8. 추후 방향성

   • Guest OS에서 symmetric multiprocessing 지원하기
   • 반가상화 적용하기
   • 메모리 관리 통합하기
   • CPU 스케쥴링 통합하기
   • 새로운 하드웨어 가상화 기법들을 kvm으로 통합하기
   • CPU 아키텍처 확장하기

9. Conclusion

   • kvm 짱

letsencrypt에서 발급하는 인증서는 3개월짜리 단기 인증서이다. 

때문에 서버에서 3개월마다 인증서를 갱신해주어야한다.

letsencrypt 인증서를 관리해주는 certbot을 통해 갱신하는데 certbot은 자동갱신기능이 없다.

때문에 크론탭을 통해 인증서를 갱신해야한다.

[Adaptive AUTOSAR]

80년대 자동차 산업에서 처음 ECU가 등장하였고, 프로그램 크기와 complexity의 관점에서 ECU 내부의 소프트웨어는 간단하계 설계되었다.
현재는 자율주행의 완성도가 점점 높아지고 있으며, telematics, 인포테인먼트, IoT 장비 등등 많은것들이 차량 내부에 설치되고있다.
그러나 소프트웨어들이 많아질수록 다양한 OEM에서 다양한 규격의 소프트웨어들이 제작되었고, 제각각인 소프트웨어에 대한 표준이 필요했는데 그게 바로 AUTOSAR이다.
2002년 AUTOSAR가 처음 소개되었고, 차량 소프트웨어 개발의 관점에서의 기준 제시였다.
그러나 AUTOSAR 위에서 개발된 소프트웨어는 소프트웨어 lifecycle 내에 소프트웨어 업데이트가 이루어지지 않는다는 전제가 깔려있고, 최근에 개발되는 소프트웨어들은 빈번한 업데이트가 필요하기 때문에 Classic AUTOSAR는 맞지않다.
이는 Classic AUTOSAR가 구식이라는 이야기는 아니고, 자율주행과 같은 미래시대의 needs를 충족시키기 위한 다른 기준의 필요성 정도이다.
어쨋든 이러한 needs를 충족시키기 위해 나온 새로운 기준이 Adaptive AUTOSAR이다.

[Adaptive AUTOSAR의 필요성]

Advanced Driver Assistance System

ADAS는 자율주행의 핵심기술로 라이다, 레이더, 고성능 카메라와 같은 센서들을 기반로 동작한다.
사실상 다이나믹 통신, 유연하고 안전한 플랫폼, 빠른 데이터 전송과 프로세싱등을 제공하는 Adaptive AUTOSAR를 요구한것은 자율주행이라고 할 수 있겠다.
자율주행은 신호등, 다른 차량과 통신을 하고, 센서와 카메라를 통해 얻은 차량 외부 환경에 관련된 데이터를 가지고 핸들을 조향하고 속도를 줄이는등 차량을 조작한다.
라이다, 레이더와 같은 센서를 통해 얻은 데이터는 실시간으로 ECU에 전송되어 빠르게 처리되어야한다.
빠른 차량내부 통신을 위해서 기존의 통신 프로토콜인 CAN, LIN, Flexray 등은 충분한 속도를 내지 못하고 이더넷, SOME/IP와 같은 프로토콜이 도입되어야한다.

Vehicle Architecture

센서와 직접 연결된 기존의 ECU와 다르게, 새로운 Domain Controller Architecture는 자율주행에서 새로운 트렌드가 되고있다.
분리된 컨트롤러대신 이 컨트롤러는 Body Control, 인포테인먼트, 파워트레인 등 각각의 도메인들에 할당된다.
전기차의 경우 충전소와 차량간의 통신은 유일하고 안전해야 한다.
Classic AUTOSAR는 이러한 요구조건에 맞게 설계되지 않았다.

Firmware-Over-The-Air Update(FOTA)

OTA란 새로운 소프트웨어, 업데이트 등을 무선 네트워크를 통해 배포하는것인데 FOTA는 펌웨어를 무선으로 다운받아 업데이트 한다는 것이다.
Classic AUTOSAR는 FOTA를 제공한다.
그러나 ECU 내부 각각의 어플리케이션을 업데이트할 수는 없고, 이는 Classic AUTOSAR에서 FOTA에 대한 의존성을 약화시켰다.
flexible한 Adaptive AUTOSAR는 새로운 주안점을 가지고 소프트웨어를 업데이트하고 확장시켰다.

[Classic AUTOSAR와 Adaptive AUTOSAR의 아키텍쳐]

[두 AUTOSAR는 공존 가능한가?]

위에서도 언급했듯이 Adaptive AUTOSAR는 Classic AUTOSAR의 대체가 아니고 자동차 생태계에서 상호공존을 의미한다.
두 플랫폼 모두 각기다른 문제에 대한 솔루션이며, 이것들의 공존은 높은 가치를 창출한다.

위 사진은 두 플랫폼이 차량 내에서 공존하는 overview이다.
CAN, LIN등의 차량 내부 프로토콜을 사용하던 Classic AUTOSAR와 달리, Adaptive AUTOSAR가 가져온 가장 큰 변화는 이더넷 프로토콜이다.

그렇다면 Adaptive와 Classic ECU는 어떻게 통신할까?
첫번째 시나리오는 gateway ECU이다.
Classic ECU는 게이트웨이로써의 역할을 하고, BUS 시스템에서 Adaptive ECU가 읽을수 있는 서비스로 신호를 패킹한다.
다만 포맷에대한 변화는 필요하다.
Classic ECU는 단지 신호기반이고, 신호를 서비스로 패킹할 수 없다는 또 다른 시나리오가 있다.
여기서 Classic ECU는 신호를 UDP 프레임으로 변환하고, 이를 이더넷으로 전송한다.
Adaptive ECU는 UDP 프레임을 서비스로 변환하기위해 'signal to service'라는 맵핑 feature를 갖추고있다.

[AUTOSAR의 미래]

Classic과 Adaptive AUTOSAR는 상호 보완하고 공존이 가능하다.
Classic AUTOSAR는 소프트웨어가 깊게 embedded된 functional ECU에 특화된 플랫폼이고, 자율주행을 실현시켜주는 미래지향적인 플랫폼이 Adaptive AUTOSAR이다.
그리고 자동차 산업에서 두 플랫폼은 모두 필요하다.
언젠가 Adaptive AUTOSAR가 ECU 소프트웨어 개발에 있어서 단독 플랫폼이 될지도 모르지만 아직 그렇게 생각하기에는 이르다.

www.embitel.com/embedded-blog/adaptive-autosar-vs-classic-autosars

ctags

소스코드를 분석해 소스코드 심볼(함수, 변수, 클래스 등)을 수집하고, 이 정보들을 모아 위치를 기록해 인덱싱하여 tags파일을 생성한다.

이 유틸은 vi로 소스코드 분석을 매우 편리하게 해준다.

usage

ctags -R명령어를 프로젝트의 루트 디렉토리에서 실행해 tags 파일을 생성한다

vi로 tags파일을 열면 태그 / 파일 / 소스코드 정규식 순으로 프로젝트의 모든 심볼들이 저장되어있다.

여기서 tj(tags jmp) 명령어를 통해 원하는 함수명을 찾는다.

이 프로젝트의 모든 main 함수들이 나오고 점프하고싶은 main함수의 번호를 입력하면 위치로 간다.

코드를 분석하다가 점프하고 싶은 함수가 있으면 커서를 해당함수명으로 위치하고, ctrl + ] 를 입력하면 점프한다.

main함수에서 av_packet_alloc함수로 넘어왔는데 이전 위치로 가고싶으면 ctrl + t 를 입력하면 된다.

위 내용은 tags 파일을 직접 열어서 분석하는 방법이고 특정 파일에서 함수 원형을 찾고싶을때는 마찬가지로 프로젝트 루트 디렉토리에서 tags파일을 생성하고, ~/.vimrc파일에 아래와 같이 추가해주면 해당 경로의 tags 파일을 참조해 분석 가능하다.

[리버스 프록시 서버로 사용하기]

• 준비물 : 리버스 프록시 서버 1대, 웹 서버 2대

먼저 리버스 프록시서버로 사용 할 서버 1대(www.tmdahr1245.com)에 nginx를 설치해주고,

웹서버는 외부에서 접근하지 못하도록 사설IP 192.168.152.129를 사용하는 서버에 3000번과 4000번으로 각각 웹서버를 열었다.

/etc/nginx/nginx.conf 파일을 서버 상황에 맞게 적절히 세팅한다.

나는 include /etc/nginx/sites-enabled/*; 이부분을 주석처리 했다.

이후 nginx가 설치된 서버에 /etc/nginx/conf.d/web.conf 라는 파일을 생성하고 아래 설정값을 넣어준다.

위 설정값은 http://www.tmdahr1245.com/a 라는 URL로 요청이 들어오면 http://192.168.152.129:3000/a 로 request 패킷을 전송하겠다는 설정이다.

http://www.tmdahr1245.com/a의 엑세스로그에는 정상적으로 로깅이 되며,

request는 웹서버(192.168.152.129:3000, 192.168.152.129:4000)에서 처리하여 response를 다시 http://tmdahr1245.com/a 로 전달하고,

해당 리버스 프록시 서버에서 클라이언트에게 response를 준다.

[로드밸런서로 사용하기]

• 준비물 : 로드밸런서용 서버 1대, 웹 서버 2대

로드밸런서 역할을 할 서버 1대(www.tmdahr1245.com)에 nginx를 설치해주고, 동일한 기능의 웹서버 2대를 준비한다.

이후 nginx가 설치된 서버에/etc/nginx/conf.d/web.conf라는 파일을 생성하고 아래 설정값을 넣어준다.

위 설정값은http://www.tmdahr1245.com/a라는 URL로 요청이 들어오면,

http://192.168.152.129:3000/a, http://192.168.152.129:4000/a로 request 패킷을 번갈아 전송하겠다는 설정이다.

실제로 client는 계속 www.tmdahr1245.com/a에 접속을 하지만, www.tmdahr1245.com에서는 192.168.152.129의 3000번 포트 웹서버와 4000번 포트 웹서버로 번갈아 요청이 가는것을 확인할 수 있다.

로드밸런싱 알고리즘

• 기본적인 로드밸런싱 알고리즘을 upstream 옵션을 통해 설정하고 이외에도 여러 옵션들이 있다.

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream

한 서버에서 여러개의 MariaDB 인스턴스를 동작시키는 방법

[테스트 버전 정보]

• 서버 : ubuntu 14.04

• DB : Mariadb : 5.5.64

서버, DB 모두 좀 오래되긴 했지만 문제는 없다.

기본적으로 MariaDB를 구동하면 mysql 기본포트 3306으로 한개의 인스턴스가 동작한다.

vi /etc/mysql/my.cnf 

[mysql]이라는 항목이 있을텐데 [mysql3306]으로 바꿔준다.

앞으로 여러개의 인스턴스를 관리하려면 여러 인스턴스들을 GNR(Group Number)로 관리해줘야 하는데,

config 파일에서 [mysqldGNR] 형식으로 GNR을 정의한다.

이후 새로운 인스턴스의 설정들을 config 파일(my.cnf)에 정의해준다.

나는 3311번 포트를 사용하는 인스턴스를 생성하려고 한다.

config 파일에 새로운 인스턴스(3311번)의 설정들을 정의해주면 mysql_install_db 명령어를 통해 새로운 인스턴스를 설치한다.

이후 mysqld_multi start {GNR} 명령어로 새로운 인스턴스(3311번)를 실행한다.

기존의 3306번 서비스이외에 새로 추가한 인스턴스가 3311포트로 새로 동작하는것을 확인할 수 있다.

두 인스턴스를 보면 다른 데이터베이스임을 확인할 수 있다.

드림팩토리를 통해 자동으로 RESTAPI를 생성해보자.

[드림팩토리 설치]

드림팩토리를 설치하기 위해 먼저 설치되어야할 소프트웨어들이 있다.

• PHP 7.2 이상

• Git

• 웹서버

• 데이터베이스(드림팩토리 자체에서 사용할 용도)

• Composer

https://github.com/dreamfactorysoftware/dreamfactory.git에서 클론을 받는다.

드림 팩토리는 PHP Laraval Framework를 통해 개발된것을 볼 수 있으며 composer를 통해 패키지를 설치해준다.

artisan 커맨드를 통해 드림팩토리에서 사용할 데이터베이스의 정보 및 사용자 정보를 입력한다.

환경설정이 완료되었으면 서버를 시작한다.

host 옵션을 주지않으면 디폴트로 127.0.0.1로 서버가 열리는데 내부에서만 접근 가능하므로,

0.0.0.0으로 서버를 열고 방화벽 정책을 통해 화이트리스트 기반으로 접근제어하는게 좋겠다.

드림팩토리를 리눅스에 설치해야하는데 리눅스에서 웹브라우저로 서비스를 이용해도 괜찮다면 127.0.0.1로 열어도 괜찮다.

[RESTAPI 만들기]

먼저 Services 탭에서 서비스를 생성한다.

서비스 생성시 Config탭에서 연결할 DB의 정보를 입력한다.

이후 해당 서비스에 접근할 권한을 설정하기 위해 role 탭에서 해당 서비스 전용 role을 생성한다.

위 세팅은 sakila서비스에 있는 모든 프로시져에 대해 get과 post 메소드만을 허용한다는 의미이다.

이제 해당 권한을 적용할 어플리케이션을 Apps 탭에서 생성하고 위에서 생성한 role을 적용한다.

어플리케이션을 생성하면 위에서 생성한 서비스에 접근할 수 있는 API Key를 생성해준다.

해당 API Key를 가지고 sakila 서비스에 있는 모든 프로시져에 대해 get과 post 메소드를 통해 접근할 수 있다.

Data탭에 sakila 서비스를 선택 후 테이블 목록이 제대로 조회된다면 드림팩토리와 데이터베이스 연결이 제대로 된다는 뜻이다. 

보통은 외부 데이터베이스에서 접근 통제 rule을 설정해서 허용해 주어야 하기 때문에 바로 연결되지 않을것이다.

외부 데이터베이스 RESTAPI read용도의 Stored Procedure를 생성해 두었다.

해당 프로시저를 실행하면 이렇게 결과를 준다.

postman을 통해 헤더에 API Key를 추가하여 API를 호출하면,

Stored Procedure의 결과를 Json형태로 파싱해 response를 받을 수 있다.

위 예제에서 https://xxxxxx.apps.dreamfactory.com/api/v2/sakila/_proc/getRental와 같이 드림팩토리의 URL을 사용해야 하는데,

express류의 서버를 포팅서버로 두고 express 내부에서 드림팩토리로 통신하여 

https://test.com/sakila/getRental과 같이 URI를 사용함으로써 리소스를 좀더 명확하게 표기할 수 있다.

또한 /example/{id} 형태의 가변적인 API가 필요할 경우 드림팩토리 상에서 /_proc/{procedure_name} 형태에

post 메소드를 통해 request를 보내고 id는 body에 포맷에 맞게 붙여주면 된다.

RESTAPI의 여러가지 사용법은 위 이미지 처럼 API Docs 형태로 가이드가 존재하니 설명대로 사용하면 되겠다.