<개요>

- Azure Cosmos 의 경우 RU 단위로 과금을 한다.

<내용>

- 400RU 가 최소단위이다.

- Partition Key를 잘 설정하지 않으면 HotSpot이 발생하여 RU만큼의 성능을 못 느낄 수도 있다.

- RU는 결국 초당 Read/Write를 위해서 접근하는 데이터의 양이라고 볼 수 있는데, 최적화를 잘못할 경우 기대한 한큼은 Throughput이 나오지 않을 수 있다.

- RU는 database 레벨에서 설정할 수도 있고 개별 Collection 단위로도 설정이 가능하다.

- 물리 1파티션당 10기가 용량제한이 있어서 이를 염두해야 한다.

<Scale설정화면>

- 개별 Collection 의 사용빈도나 데이터가 다르다면 별도로 세팅하는 것이 좋다.

database 레벨에서 RU를 설정할 경우 각 컨테이너의 RU는 별도설정이 불가능하고 database RU를 공유하는 방식이 된다.

전체 사용량이 많지 않다면 공유하는 방법을 추천한다. (과금은 RU단위로 되기 때문)

<결론>

-400RU 로만 사용하면 월 5만원 안쪽으로 부담이 크지 않다.

-그러나 지역중복을 체크하면 x로 비용이 추가된다.

-RU를 초과하는 요청에 대해서는 즉시 응답이 오지 않으며 대기하다가 처리하는 방식으로 이루어진다.

-timeout이 발생하는 경우는 명시적으로 exception 이 발생한다.

-전체 data가 많을 경우 스캔해야하는 범위가 늘어나므로 RU최적화를 위해서는 data tts를 조정하는 것도 하나의 방법이 될 수 있다.

-파티션키 조정을 통해서 HotSpot발생을 줄이고 퍼포먼스를 증가시키는 것은 일반적인 NoSQL 과 유사하다.

기존에 Spring Boot 를 잘 사용중이었는데 어느날 신규API를 추가한 뒤로 기존 API에서 404 Not Found가 발생하기 시작했다.

maven 빌드를 다시 해보기도 하고 API depth를 바꿔보기도 했다. 대소문자도 다시 확인하고.. 

대략 30분정도 삽질을 하다가 예전에 프레임워크 작업할 때 생각났던 component scan 옵션을 찾아봤다!

아무 패키지도 설정하지 않으면 기본적으로 최상위 패키지부터 순차적으로 찾아가는데 신규 API를 추가하면서 패키지구조가 약간 틀어졌다.

     <기존> org.apache.telemetry

-> <변경> org.apache.service.telemetry

<신규> org.apache.status

이렇게 수정이 되니 신규로 추가된 최상위 패키지인 org.apache.status 만 읽게 되고 org.apache.service 하위는 읽지 않는 문제가 발생한 것이다.

org.apache.service.telemetry

org.apache.service.status 

와 같은 형태로 맞추어주니 다시 동작하지만 동일한 상황이 재발하는 것을 방지하기 위해서 명시적으로 다음 선언을 추가하였다.

@ComponentScan(basePackages="org.apache.service")

@Test
    public void updateDeviceTelemetryInterval() throws Exception {

        int deviceId = 1;
        String serviceName = "AAAService";

        //given service info
        ServiceDto serviceDto = new ServiceDto();
        serviceDto.setServiceId(1);
        AzureIotHubEntity azureIotHubEntity = new AzureIotHubEntity();
        azureIotHubEntity.setAzureIotHubConnectionString("");
        serviceDto.setAzureIotHub(azureIotHubEntity);
        //given device info
        DeviceDto deviceDto = new DeviceDto();
        deviceDto.setDeviceId(1);
        //given interval info
        Gson gson = new Gson();
        DeviceDto device = new DeviceDto();
        device.setTelemetryInterval(1);
        String str = gson.toJson(device);

        given(serviceService.findServiceByName(serviceName)).willReturn(serviceDto);
        given(deviceService.findDeviceById(deviceId)).willReturn(deviceDto);

        //when then
        MockHttpServletRequestBuilder createUserRequest = post("/ServiceName/setTelemetryInterval/1")
                .contentType(MediaType.APPLICATION_JSON_UTF8_VALUE)
                .content(str);

        this.mvc.perform(createUserRequest)
                .andExpect(status().is2xxSuccessful());
    }

이와 같은 테스트코드는 정상적 상황을 테스트하는 상황입니다.

만약 해당하는 서비스가 없는 상황에서는 다음과 같은 Exception이 발생하도록 내부적으로 정의했습니다.

@ResponseStatus(value= HttpStatus.NOT_FOUND, reason="No such Service")
public class ServiceNotFoundException extends Exception {

    public ServiceNotFoundException(String message){
        super(message);
    }

    public ServiceNotFoundException(String message, Throwable cause) {
        super(message,cause);
    }
}

이와 같은 Exception이 의도한 것처럼 발생하는지 우리는 일반적으로 TestCode에서 아래와 같은 annotation을 통해서 처리합니다.

@Test(expected = ServiceNotFoundException.class)

그런데 여기서 주의해야 할점이 있습니다!!! 

우리가 일반적으로 Spring mvc를 사용할때 위와 같은 형태로 Exception을 정의할 경우, 내부적으로 Exception을 catch하여 밖으로 나가지 않도록 하고 HTTP STATUS코드를 변경하게 됩니다.

따라서 위와 같이 @Test(expected) 를 추가하더라도 Exception은 잡히지 않습니다.

어떻게 하면 내가 의도한 Exception을 잡아낼 수 있을지 Spring 내부소스를 살펴보았습니다.

final class TestDispatcherServlet extends DispatcherServlet {

@Override
	protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response,
			@Nullable Object handler, Exception ex) throws Exception {

		ModelAndView mav = super.processHandlerException(request, response, handler, ex);

		// We got this far, exception was processed..
		DefaultMvcResult mvcResult = getMvcResult(request);
		mvcResult.setResolvedException(ex);
		mvcResult.setModelAndView(mav);

		return mav;
	}
 

위와 같이 result에 resolvedException에 발생한 Exception정보를 저장하고 있습니다.

그렇다면 아래와 같이 테스트 코드를 작성하면 될것이라고 추측됩니다.

@Test
    public void updateDeviceTelemetryIntervalNonExistService() throws Exception {

        //given
        ServiceDto serviceDto = new ServiceDto();

        Gson gson = new Gson();
        DeviceDto device = new DeviceDto();
        device.setTelemetryInterval(1);
        String str = gson.toJson(device);

        given(serviceService.findServiceByName("TestService")).willReturn(serviceDto);

        //when then
        MockHttpServletRequestBuilder createUserRequest = post("/AAAService/setTelemetryInterval/1")
                .contentType(MediaType.APPLICATION_JSON_UTF8_VALUE)
                .content(str);

        this.mvc.perform(createUserRequest)
                .andExpect((result)->assertTrue(result.getResolvedException().getClass().isAssignableFrom(ServiceNotFoundException.class)))
                .andExpect(status().is4xxClientError());
    }

테스트 결과 404 NotFound  와 exception의 유형을 모두 확인할 수  있습니다.

 수년간 오픈소스 기반으로 시스템을 개발하다가 이번에 Public Cloud를 사용하면서 경험했던 부분을 간단히 공유하겠습니다.

기존에 처리하던 방식입니다. 대부분의 Client로부터의 요청은 Kafka로 전달됩니다. 전달받는 데이터 소스위치에 따라서 Kafka 앞에 하나의 Layer를 더 두는 것이 일반적입니다.

이렇게 개발하다보면 로직자체의 개발보다 때로는 오픈소스의 사용법, 버그패치, 운영시 발생하는 설정상 문제에 더 많은 시간을 사용하고는 합니다. 지금 개발하는 곳에서는 예전보다 개발 리소스가 더 부족한 상황이어서 과감하게 Azure PaaS 를 사용하도록 결정했습니다.

지금 개발중인 시스템은 데이터 입력채널이 대부분 IoT Device, Sensor의 영역인 것을 제외하고는 기존에 개발하던 시스템들과 구조가 90%이상 동일합니다. 

기존에는 Nifi -> SparkStreaming -> Druid, NoSQL, HDFS -> Grafana 를 사용하던 구조였으며 이와 매칭되는 구성요소들을 Azure 에서 찾기 시작했습니다.

MS Azure에 있는 다양한 PaaS 요소를 사용하여 IoT Device Data를 수집하는 간단한 예제를 만들어 보았습니다.

(소요시간은 과거 오픈소스를 사용할때와는 비교할 수 없을만큼 단축되었습니다!)

https://docs.microsoft.com/ko-kr/azure/architecture/reference-architectures/iot/

 여기에 나오는 아키텍처와 크게 다르지 않으나 실시간 분석처리등은 간소화를 위해서 일단 제외하고 진행했습니다.

아키텍처를 그대로 진행하더라도 각 구성요소의 설정 및 구성에 따라서 동작방식이 달라지기 때문에 살펴봐야 하는 부분에 대해서 간단히 정리해봤습니다.

1. Azure IoT Hub

- 각 계정별로 무료 Hub는 1개 생성가능하고 그 외 유료 Hub의 경우 가격정책에 따라 메시지량이 정해진다. (S1 월 28000원)

- 각 Tier별로 Scale Out이 가능하지만 수작업이 필요하며, 높은 Tier를 한 개 쓸것인지 낮은 Tier에서 x times로 늘릴 것인지는 선택필요

- 자체적으로 event hub가 내장되어 있어서 별도 event hub 생성 없이 간단히 사용가능하다.

  그러나 바로 사용하는 것은 권장하지 않고 event hub로 endpoint를 연결하는 것을 권장한다.

  IoT Hub는 디바이스와의 연결을 담당하며 장애가 발생할 경우 변경할 수 도 있다. 그런데 기타 로직을 구성하는 Application이 IoTHub에 바로 연결되어 있다면 변경사항에 영향을 받기 쉽다(설계5대원칙의 OCP를 생각해보세요) 

 또한 실환경에서는 하나의 메시지큐에 여러 개의 Application 으로 확장되는 것이 일반적이며, 이 때 Consumer Group을 여러 개 두고 병렬처리를 각각 하고 파티션을 조정하는 등의 행위가 필요한데, IoT Hub는 이러한 부분에 제약사항이 있다.

- 메시지의 속성값, 내용에 따라서 Routing기능을 활용할 수 있으나 UTF-8 인코딩에 JSON String 을 사용해야만 한다.

- 개별 Device를 등록하는 방법에는 대칭키, 인증서 등의 방식이 있다.

- D2C, C2D 메시지 전송이 가능하며, 디바이스 제어를 위해서는 Device Twin 이나 Method Invoke를 사용하는 것으로 가이드한다.

2. Azure Event Hub

 - Apache Kafka와 유사한 구조로 만들어진 Message Queue이다.

 - IoT Hub의 경우 위치가 변경될 수 있으며 Fail over가 필요한 경우도 있다. 또한 직접적으로 Device와 연결되는 부분이기 때문에 Layer Architecture구성을 위해서 실제 메시지 소비는 Event Hub에서 이루어 지는 것을 권장한다.

 - Namespace를 생성 후 각 필요에 따라서 실제 Event Hub 를 생성하는 방식이다.

 - 보관주기를 정할 수 있으며 옵션으로 스냅샷을 Storage Account에 저장할 수 있다. (Cold Storage)

 - 필요에 따라서 파티션 수와 보관주기를 설정할 수 있다.

 - Kafka Enabled를 활성하면 기존 Kafka Consumer Application을 그대로 사용할 수 있다!

3. Azure App Services - Functions

 - AWS의 Lambda와 같은 Serverless이다. 지원하는 방식이나 언어가 Lambda보다는 제한적이지만 크게 사용에 어려움은 없다.

 - Azure의 PaaS 구성요소에 대해서 Trigger, Input, Output 연결이 가능해서 보다 빠르게 Application을 구성할 수 있다.

 - Azure DevOps나 Github등의 소스를 연결하여 자동배포가 가능하도록 구성할 수 있으나 현재 Trigger, Input, Output등을 사용할 경우 Extension Plugin설치가 필요한데 이러한 부분의 자동화는 아직 지원하고 있지 않다.

 - 실행 횟수에 따라 요금이 부과되지만 크게 부담되는 수준은 아니며 주요 과금은 묶여있는 App Service Plan의 사양에 따라서 결정된다.

4. Azure App Services - Web App

 - Web을 위한 Tomcat등의 WAS를 Managed 형태로 제공한다.

 - WAR, JAR배포를 지원하며 Spring Boot를 올리는 것도 가능하다.

 - 외부로 나타나는 EndPoint로만 접근하면 되고, 내부적으로 구성한 App Service Plan에 따라서 서버자원의 자유로운 확장이 가능하다.

5. Azure App Service Plan

 - Azure App Service를 이용하기 위해서 반드시 생성해야 한다.

 - Azure App Service를 위한 서버자원을 묶음형태로 정의한다고 보면 이해가 쉽다.

 - OS, CPU, Storage등의 옵션과 Tier를 설정하고 사용할 실제 App Service (Functions, Web app)를 연결하면 해당 어플리케이션들이 수행될때 지정된 만큼의 자원을 자유롭게 사용한다.

 - Linux/Windows선택에 따라서 사용하는 App Service형태에 일부 제약이 있을수도 있으니 확인이 필요하다.

6. Azure Database for MySQL

 - 일반적으로 사용하는 MySQL과 크게 다르지 않다.

 - AWS RDS와 유사하다.

7. Azure Cosmos DB

 - Azure에서 제공하는 NoSQL 이다. (AWS의 DynamoDB유사)

 - 사용할 수 있는 SQL API를 4가지 중에 선택가능하며 이론상 기존 API와 버전만 맞다면 호환이 된다.

 - 생각보다 비용이 비싸서 몇가지 고려해야 하는점이 있다.

 a. RU 및 Storage사용량에 따라서 과금이 늘어난다. https://docs.microsoft.com/en-us/azure/cosmos-db/understand-your-bill

 b. Partition관련 Hotspot이 생기지 않도록 Key를 잡는 것이 중요하다. 선택을 잘못한다면 RU를 설정한 것보다 성능이 나오지 않는다.

    일반적인 NoSQL의 특성과 크게 다르지 않은 부분이다. 인덱스는 Collection별로 세팅이 가능하다.

 c. Multi Region 선택시 비용도 Multi로... 들어갑니다..;

추가로 현재 Cosmos에 Spring JPA를 사용하여 개발시 고려해야하는 부분이 몇 가지 있는데

 ㄱ. Top keyword, Custom Query

https://github.com/Microsoft/spring-data-cosmosdb/issues/144

 ㄴ. page처리시 next page에 관련된 이슈 -> 이부분은 제가 지금 테스트했을때는 발생하지 않고 있습니다.(2019.08.05)

https://github.com/Microsoft/spring-data-cosmosdb/issues/225

https://github.com/Microsoft/spring-data-cosmosdb/issues/363

오픈소스에 비해서 커스터마이징할 수 있는 영역이 부족하고 몇몇 기능의 부재가 있지만 개발시간은 체감상 20%도 되지 않는듯 합니다.

특히 사용량에 따른 자세한 설정이나 모니터링을 위한 다양한 도구들이 더욱 사용을 편리하게 해주고 있습니다.

물론 전체적인 아키텍처와 원리를 잘 이해하고 있어야 최적의 설계를 통해서 성능을 최대화하고 비용을 최소화하는 것이 가능합니다.

<참고사이트>

https://intellipaat.com/blog/tutorial/hadoop-tutorial/introduction-hadoop/

https://www.xenonstack.com/blog/iot-analytics-platform/

 가장 많이 사용하고 있는 Spring Boot + JPA 로  Azure Cosmos DB를 연결하는 작업을 진행해보았다.

https://docs.microsoft.com/ko-kr/java/azure/spring-framework/configure-spring-boot-starter-java-app-with-cosmos-db?view=azure-java-stable

1. maven pom.xml에 아래와 같이 추가하고.

<dependency>

   <groupId>com.microsoft.azure</groupId>

   <artifactId>azure-documentdb-spring-boot-starter</artifactId>

   <version>2.0.4</version>

</dependency>

2. JPA에서 제공하는 CRUD Repository를 이용해서 다음과 같이 작업했다.

public interface DeviceTelemetryRepository extends DocumentDbRepository<DeviceTelemetry, String>{

    List<DeviceTelemetry> findAll();

    @Query(value="SELECT * FROM DeviceTelemetry where deviceId= ?1 and date >= ?2 and date <= ?3", nativeQuery = true)
    List<DeviceTelemetry> findDeviceTelemetryByDeviceIdAndDateGreaterThanAndDateLessThan(@Param("deviceId") int deviceId,
                                                               @Param("from") long from,
                                                               @Param("to") long to    );

}

3. Entity클래스의 경우 테이블에 따라서 잦은 변경이 일어나기 때문에 Controller, Service Layer에서는 DTO클래스를 별도 로 사용하는 것을 권장한다. (디자인 패턴 참고)

@Service
public class DeviceTelemetryService {
    @Autowired
    private DeviceTelemetryRepository deviceTelemetryRepository;

    @Autowired
    private ModelMapper modelMapper;

    public List<DeviceTelemetryDto> getDeviceTelemetry(int deviceId, long from, long to){
        return deviceTelemetryRepository.findDeviceTelemetryByDeviceIdAndDateBetween(deviceId, from, to).stream()
                .map(deviceTelemetry -> modelMapper.map(deviceTelemetry, DeviceTelemetryDto.class))
                .collect(Collectors.toList());
    }

}

4. Controller 까지 완성하여. 테스트하였는데 아래와 같은 오류가 발생한다.

@RequestMapping(path="/api/")
public class DeviceTelemetryController {

@Autowired
private DeviceTelemetryService deviceTelemetryService;


@RequestMapping(value="/{serviceId}/{deviceId}/telemetry", method= RequestMethod.GET)
public @ResponseBody
List<DeviceTelemetryDto> getAllDeviceTelemetry(@PathVariable("deviceId") int deviceId,
@RequestParam("from") long from,
@RequestParam("to") long to) {

return deviceTelemetryService.getDeviceTelemetry(deviceId,from,to);
}
}

java.lang.IllegalArgumentException: unsupported keyword: GREATER_THAN (1): [IsGreaterThan, GreaterThan]
	at com.microsoft.azure.spring.data.documentdb.repository.query.DocumentDbQueryCreator.from(DocumentDbQueryCreator.java:82) ~[spring-data-cosmosdb-2.0.3.jar:na]
	at com.microsoft.azure.spring.data.documentdb.repository.query.DocumentDbQueryCreator.and(DocumentDbQueryCreator.java:56) ~[spring-data-cosmosdb-2.0.3.jar:na]
	at com.microsoft.azure.spring.data.documentdb.repository.query.DocumentDbQueryCreator.and(DocumentDbQueryCreator.java:25) ~[spring-data-cosmosdb-2.0.3.jar:na]
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createCriteria(AbstractQueryCreator.java:122) ~[spring-data-commons-2.0.10.RELEASE.jar:2.0.10.RELEASE]
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:95) ~[spring-data-commons-2.0.10.RELEASE.jar:2.0.10.RELEASE]
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:81) ~[spring-data-commons-2.0.10.RELEASE.jar:2.0.10.RELEASE]
	at com.microsoft.azure.spring.data.documentdb.repository.query.PartTreeDocumentDbQuery.createQuery(PartTreeDocumentDbQuery.java:38) ~[spring-data-cosmosdb-2.0.3.jar:na]
	at com.microsoft.azure.spring.data.documentdb.repository.query.AbstractDocumentDbQuery.execute(AbstractDocumentDbQuery.java:25) ~[spring-data-cosmosdb-2.0.3.jar:na]

5. Azure Cosmos DB에 문의하니 다음과 같은 답변을 받았다.

spring-data-cosmosdb 2.0.6을 사용해야 하는데 아무리 찾아도 azure-documentdb-spring-boot-starter에 포함된 최신버전은 2.0.4가 최신버전이다!

다시 문의를 했다. 수동으로 업데이트해야하는가?

결론은 "azure-documentdb는 구 네이빙 버전입니다. 신버전을 사용하세요."

Thanks for filing issue, according to your stack trace, seems you are using version 2.0.3, if you are using Spring Boot 2.0.x, try upgrading to 2.0.6.

You can use the azure-cosmosdb-spring-boot-starter(not azure-documentdb-spring-boot-starter) version 2.0.13, which uses spring-data-cosmosdb 2.0.6. Between should have been supported in 2.0.6, check this issue. Also you can reference the integration tests in this repo for the usage.

6. pom.xml에서 azure-cosmosdb-spring-boot-starter 최신버전으로 변경하였다.

<dependency>
   <groupId>com.microsoft.azure</groupId>
   <artifactId>azure-cosmosdb-spring-boot-starter</artifactId>
   <version>2.0.13</version>
</dependency>

7. 하지만 Spring JPA의 naming rule에 같은컬럼을 중복해서 사용하면 에러가 발생한다.

BETWEEN 쿼리로 변경!

(GREATER_THAN, BETWEEN등은 위에서 언급한 2.0.6 버전에서 정상지원한다.)

8. Repository 소스 변경(@Query는 없어도 쿼리를 자동으로 생성하여 동작한다)

public interface DeviceTelemetryRepository extends DocumentDbRepository<DeviceTelemetry, String> {

    List<DeviceTelemetry> findAll();

//    @Query(value="SELECT * FROM DeviceTelemetry where deviceId= ?1 and date >= ?2 and date <= ?3", nativeQuery = true)
    List<DeviceTelemetry> findDeviceTelemetryByDeviceIdAndDateBetween(@Param("deviceId") int deviceId,
                                                               @Param("from") long from,
                                                               @Param("to") long to    );
}

9. Azure Cosmos DB에서 정상적으로 데이터를 조회하는 것을 확인할 수 있다.

[

    {
        "id": "3ebd07c0-0740-466f-acb4-1e04a58cdf1a",
        "serviceId": 1,
        "deviceId": 1,
        "contents": "{\"temperature\":34.797642257199705,\"humidity\":79.18982439419167,\"illuminance\":100}",
        "date": 1552376519931
    },
    {
        "id": "9424f15a-e452-4dcc-8ff6-bc3707b7ec3a",
        "serviceId": 1,
        "deviceId": 1,
        "contents": "{\"temperature\":25.964463142640522,\"humidity\":73.64654000868197,\"illuminance\":100}",
        "date": 1552376579937
    },
    {
        "id": "c72aed1b-b4d0-4338-a21f-ae8b7e5b4eba",
        "serviceId": 1,
        "deviceId": 1,
        "contents": "{\"temperature\":28.32913263660401,\"humidity\":73.40374660917695,\"illuminance\":100}",
        "date": 1552376639938
    },
    {
        "id": "c1571a80-7eb6-49dc-be9f-32457e41f69a",
        "serviceId": 1,
        "deviceId": 1,
        "contents": "{\"temperature\":30.035071643495087,\"humidity\":70.52682127516005,\"illuminance\":100}",
        "date": 1552376699940
    }
]

참고사이트)

1. 위 내용 관련하여 MS Github에서 주고 받은 내용들

https://github.com/Microsoft/spring-data-cosmosdb/issues/347

2. 현재 google 에서 조회하면 가장 상단에 Azure SDK for Java Stable 나오는 페이지

https://docs.microsoft.com/ko-kr/java/azure/spring-framework/configure-spring-boot-starter-java-app-with-cosmos-db?view=azure-java-stable

Azure Everywhere

 퍼블릭 클라우드 하면 떠오르는 세 곳이 AWS, MS Azure, GCP 입니다.

AWS가 전 세계의 시장을 점유하고 있으며, GCP는 약간은 다른 노선을 걷고 있는가운데 최근 MS Azure의 적극적인 B2B시장 공략이 눈에 보입니다.

이와 관련하여 첫번째로 summit행사가 열렸으며 그 이름이 Azure Everywhere 입니다.

<오전세션>

오전세션은 다음과 같았습니다. 

키워드는 다음과 같습니다.

 - 개발자 중심

 - AI 대중화

 - 기술변화에 따른 사업구조 변화

<GitHub : 개발자 중심의 클라우드 플랫폼 응용과 진화의 방향>

세션의 설명에 앞서서 수년간 변화해온 IT를 살펴볼 필요가 있습니다.

 과거에는 IT의 핵심가치가 <원가절감>, <생산성 향상>에 있었습니다. 전통적인 산업의 비지니스가 존재했고 그 비지니스 프로세스를 그대로 모델링하여 IT시스템을 구축하여 서포트하는 것이었습니다. EA를 설계하고 각 도메인의 SA,DA,TA위에 비지니스를 분석하여 설계하면 개발자는 그대로 개발하는 것이었습니다. 각 영역을 담당하는 전문가들이 있었으며 대부분 외부 인력이였기 때문에 공정과 절차가 중요했으며 소프트웨어도 납품받아서 사용하는 것이 일반적이었습니다.

 그러나 사업환경이 점차 급변하면서 IT자체를 상품으로 하는 새로운 비지니스들이 출현하기 시작했습니다. 산업간의 경계가 무너지고 모든 기업이 소프트웨어 기업이 되어야만 하는 세상이 다가왔습니다.

 이제는 IT의 핵심이 <가치>가 되었습니다. 끊임없이 변하는 시장환경에 전통적인 개발방법론으로는 대처하기가 어렵고, 뭔가를 개선하고자 프로젝트를 계속 진행해도 여러 한계점만 나타나게 되었습니다. 

(일정지연, SW인력의 소모품화, 요구를 충족하지 못하는 제품, 높은 시스템 유지비용 및 변경비용 등.)

 전 세계적으로 이러한 상황을 극복하기 위해서 많은 시도가 이루어졌고 애자일이 대표적인 사례입니다.

(애자일 선언문은 업종에 관계없이 꼭 한번 읽어보시기를 강추드립니다. 참여하신 분들 이름만 봐도 ㄷㄷㄷ..

다양한 영역에서 애자일하게 일하려는 시도가 있을만큼 배울점이 많습니다.)

 소규모의 팀(6~8명)이 자체적으로 기획/설계/개발/테스트를 빠르게 반복하여 고객에게 가치 있는 제품을 만드는 것을 목표로 합니다. 이러한 과정속에서 자체적으로 개발/운영을 수행하고 본인들에게 필요한 소프트웨어는 오픈소스를 기반으로 직접 만들고 개선하는 것이 일반적이 되었습니다. 특히 오픈소스 진영은 전 세계의 개발자가 함께 개발하는 만큼 그 완성도나 속도는 벤더사를 넘어선지 오래입니다.

 이제 중요한 것은 공정과 절차가 아니라 사람, 신뢰, 협업, 문화입니다. 모든 팀원이 주인정신을 가지고 일해야 합니다. 특히 개발자(과거 아키텍트,개발자,QA등으로 분리되어있던 역할 )가 자주 언급될 수 밖에 없는 것은 최종 결과물(소프트웨어)이 가장 중요하기 때문입니다. 개발자는 앞으로 더욱 주도적으로 제품개발에 참여하며 그 속에서 문제를 파악하고 해결방법을 찾아서 적용해야 하며 과거보다 훨씬 넓고 깊은 역량을 보유하고 있어야 하며 협업을 생활화해야 합니다.

 다시 돌아와서 Github세션을 살펴보겠습니다.

MS가 GitHub을 인수하고 개발자 중심의 회사로 변신한 것은 대단한 일입니다.

 과거 MS는 리눅스와 같은 오픈소스를 적대시하고 탄압했습니다. "리눅스는 암"이라는 유명한 말도 있었죠.  자신들의 비지니스의 걸림돌이었기 때문입니다. 절대로 상용제품을 대체할 수 없다고 했고 무시하며 개발자중심의 세상을 비판했습니다. 

그러나 2014년 "MS는 리눅스를 사랑한다"라고 발표했고, 현시점 오픈소스 기여자 1위는 MS입니다!

(2위가 구글입니다..)

 본 세션에서도 개발자의 생산성을 증가시키고 협업을 가속화하는 것에 집중하여 발표하고 있습니다. 많은 사람들의 우려와는 다르게 Github의 역할은 당분간 계속 변함이 없을 것으로 보입니다.

“MS는 개발자를 최우선으로 하는 기업이며, 

깃허브와 함께함으로써 개발자의 자유, 개방성, 혁신에 대한 우리의 의지를 강화할 것”

“우리는 이번 인수 계약에 담긴 ‘공동체에 대한 책임’을 인식하고 있으며, 

모든 개발자가 시급한 문제를 해결하고 혁신할 수 있도록 돕는 데 최선을 다하겠다”

- 사티아 나델라 MS 회장, 발표문-

현실은 여전히 많은 개발자들이 소스코드를 작성하는데 50%미만의 시간을 쏟고 있습니다. 

Top 과 Low 의 차이입니다. 새로운 일에 할당하는 비율과, 잡무(?)에 할당하는 비율이 눈에 들어옵니다.

특히 이 그래프를 보면서 지금 아마존에서 일하고는 있는 개발자 친구들이 생각났습니다. 그 친구들의 말에 의하면 80%이상의 시간을 개발에 전념할 수 있도록 모든 절차와 제도가 마련되어 있다고 합니다.

 여러 방법과 도구, 문화를 통해서 이러한 변화를 주도하고 있음을 보여줍니다. 

(개발자들이 사용하는 모든 것이 오픈소스기반으로 Github에 모여있다고 해도 과언이 아닙니다. 누구나 가져가서 쓸수 있습니다. 그러나 쉬운 일은 아니고 공짜도 아니며 본인도 기여해야 합니다.)

최근 마이크로소프트의 행보를 보면

- Github인수등 오픈소스 적극지원

- Windows 10 리눅스 탑재

- VisualStudio Code 오픈소스화 (스크립트 부분에서는 VS Code가 점유율 90% !  )

- MS Azure의 리눅스 지원, 크로스 플랫폼, Intellij Plugin 지원등

등 시장의 반응을 봤을 때 방향은 제대로 잡고 가고 있다는 느낌을 받습니다.

<Databricks : 1% + 99% = AI 대중화>

 말이 필요없는 Databricks입니다. Spark는 Hadoop의 뒤를 이어서 거대한 생태계를 구축하고 있습니다. 

과거에는  자체적으로 클라우드 환경을 구축하고 서비스하려고 시도했지만 퍼블릭클라우드 변화에 맞춰서 MS Azure에 탑재하는 쪽으로 방향을 빠르게 전환한 듯 합니다. 

이전글: http://icthuman.tistory.com/entry/Spark-Summit-2017?category=572958

 Spark를 간단히 설명하면 대용량 병렬처리 프레임워크입니다. 

과거 Hadoop이 가지고 있던 디스크기반의 대용량처리의 한계점을 DAG의 개념을 통해서 메모리기반 처리로 바꾸어 최대 100배의 성능향상을 끌어냈습니다. 대부분의 ML에서는 반복작업이 많은데 Spark는 특히 반복문에서 성능향상이 탁월하기 때문에 ML분야에서 그 효과를 인정받았고 많은 라이브러리들이 Spark기반으로 변환되었습니다. 또한 SparkSQL을 통해서 프로그래밍 없이 SQL로 데이터를 조회할 수 있도록 사용자의 편의성을 증대시켰으며, lambda문법을 활용해서 데이터분석에 반드시 필요한 ETL의 기능까지도 흡수해버렸습니다. 추가로 Spark Streaming,(최근에는 Structured )를 활용해서 배치성 뿐만 아니라 실시간성 데이터까지도 처리합니다.

 이 모든기능을 포함하면서 다양한 분석함수들을 내장해서 누구나 쉽게 데이터분석을 할 수 있도록 하는것이 목표입니다. (Data Engineer와 Data Scientist가 같은 도구를 사용할 수 있다는 것은 큰 메리트입니다.)

Big Data를 해보신분들은 다 아시는 내용입니다. 왜 데이터 분석(AI) 가 어려울까요? 알고리즘이 어려워서? 

알고리즘은 크게 중요하지 않습니다. 아니 물론 중요하기는 합니다만 전문가들은 대부분 다음과 같은 이유를 꼽습니다.

1. (잘 전처리 된) 데이터가 없다. 

2. 무슨 도구를 써야 될지 모르겠다. (딥러닝 프레임워크는 정말 많습니다. Tensor Flow가 유명하긴 합니다.)

3. Data Scientist, Data Engineer가 없다. 혹은 협력이 어렵다.

이에 대해서 Databricks Runtime을 제공하여 ML을 돕는 환경을 Azure상에서 제공한다고 합니다.

또한 Data Preparation 부터 Model 생성/배포를 하나로 묶어주는 mlflow 역시 제공한다고 합니다. 저도 비슷한 것을 만들어봤던 경험이 있는데, Databricks가 한다니 완성도가 기대됩니다.

 각 유형에 따라서 MS Azure상에서 PaaS를 어떻게 활용하여 아키텍처를 구성할 수 있을지에 대한 가이드도 제공하고 있습니다. 다만 배치처리와 온라인처리를 동시에 하는 것이 최근의 추세인만큼 해당 내용을 반영하는 PaaS 구성요소도 빨리 제공이 되었으면 하는 바램입니다. (예를 들면 Druid라던지... )

이와 같은 시도를 통해서 AI의 대중화는 조금 더 빨리 찾아올 것으로 보입니다.

<레드햇 세미나와의 비교>

일전에 레드햇 세미나에서는 주로 클라우드로 인한 어플리케이션의 변화를 다루었습니다.

- 클라우드라는 의미처럼 인프라는 이제 구름속에서 보이지 않게 지탱해주는 존재가 되었습니다. 보다 비지니스와 어플리케이션에 집중할 수 있는 환경이 되었습니다. 또한 예전에는 각자 설치하고 사용했던 많은 환경들이 클라우드 서비스형태로 편하게 제공이 되기 때문에 이를 활용해서 더 많은 효과를 볼 수 있습니다.

- 모든 인프라의 요소들이 기능으로 제공됩니다.  이를 적절하게 활용하여 개발하면 장애복구, 배포/테스트, 릴리즈 등의 많은 작업을 자동화 시킬 수 있습니다. 소프트웨어 디파인이 가능합니다.

- Agile, Devops, CI/CD 등의 요소들도 클라우드에서 제공하기 때문에 연계가 가능합니다.

이번 MS Azure 세미나에서는 클라우드로의 통합, 활용방안, 앞으로의 방향성에 중점을 준 것으로 보입니다.

- 클라우드 도입으로 다양한 산업의 기술 / 비지니스 변화

- 클라우드로 전환할 때 정책, 비용, 도구, 고려사항

- 클라우드를 이용할 때 기존 요소들의 보완기능 (예, 오픈소스의 단점 등)

- 클라우드를 통해서 더 빠르고 쉽게 할 수 있는 것들 (AI, Data, Devops, Application)

<정리>

<참고사이트>

https://agilemanifesto.org/iso/ko/manifesto.html

http://www.hani.co.kr/arti/economy/it/847716.html#csidx143ed953ac12498ac9e048e89f9c66a 

https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C

https://spark.apache.org/

RedHat은?

RedHat은 오픈소스 진영에서 가장 오래된 기업 중 하나입니다. 사업구조는 라이선스를 받는 것이 아니라 교육프로그램, 기술지원, 컨설팅으로 수입을 창출합니다. (기업용 소프트웨어를 판매하기도 합니다!)

사용하는 제품들은 대부분 오픈소스로 구성되어 있습니다. 주로 오픈소스 기반으로 공유하면서 개발을 진행하고 중요한 개선사항들이 발생하면 이를 기업용에 반영하는 사이클을 가져갑니다.

최근 IBM이 RedHat을 인수했으나 당분간 변화없이 갈 계획이라고 합니다.

OpenSource

오픈소스는 소스가 공개되어 있어 누구나 가져가서 사용할 수 있지만 무료를 의미하는 것은 아니니 오해하면 안됩니다. 어떻게 설정하고 어떻게 사용하느냐에 따라서 성능이 천차만별이고, 제품의 발전속도가 빠르다는 것이 특징입니다. 결국 잘 사용하기 위해서는 기술적 이해도와 개발역량등이 매우 중요합니다. 현재 시장에서 사용되는 기술스택은 거의 차이가 없습니다. 중요한 것은 KnowHow이고 RedHat은 여기에 초점을 맞추고 있습니다.

(간단히 사용하는 것은 쉬우나, 마스터하는 것은 어렵다. Like 게임)

개인적으로 Red Hat의 방향성이 참 마음에 든다. 오픈소스 시장에 딱 맞는 모델이 아닐지.. win win전략

-오전 세션

<Business Keynote: Digital Transformation & the Open Organization TBA>

새로 출현하는 모든 것들은 기존의 것들에 많은 영향을 주는데 Digital Transformation도 그러합니다. 조직, 문화, 도구 많은 것들이 변화하며, 모든 산업 영역이 도전을 받고 있습니다. 롯데카드 김창권 CEO가 나와서 간단히 사례를 공유하였습니다. 모든 것이 변화해야 Digital Transformation을 추진할 수 있습니다. 특히 Hybrid Cloud가 자주 언급되었는데 뒤에서 설명합니다.

<Simple Path To Secure and Automated Multicloud>

RedHat의 파트너인 JUNIPER 사가 현황을 공유하였습니다. JUNIPER는 SDN을 비롯한 Network분야를 전문으로 하며 멀티클라우드를 운영하는 것에 대해서 간단히 소개하였습니다.

자동화의 영역이 늘어난다는 것은 결국 Software Define xxx가 늘어나는 것을 의미합니다. (Network, DataCenter, Deployment ..)

<Technical Keynote : BigPharm Morphs into a Digitally Transformed Business>

BIG PHARM 과 BIONODE 라는 두 회사가 하나로 합쳐지는 과정을 시뮬레이션하면서 데모를 하는 시간이었습니다. 두 개의 회사가 어떻게 다른 회사의 데이터모델을 공유하고 이를 어플리케이션에 반영하는지를 간단히 데모를 통해서 보여주었습니다.

 다른 도메인의 모델과 프로세스를 어떻게 엮을 것인지가 핵심 포인트며 이 부분을 코딩이 아닌 UI를 통해서 쉽게 할 수 있도록 하는 것이 목표라고 하였습니다. (정말?? IT업계의 마르지 않는 떡밥느낌이다..)

주로 간단한 예를 중심으로 데모가 진행되었기 때문에 아직 실제 비즈니스와는 Gap이 있다고보입니다. 

<Using Innovation to Drive Business Transformation>

Open Organization이야기가 다시 나옵니다. 전통적인 조직구조에서는 상위의사결정자가 무엇(WHAT)을 할지 결정하고, 중간관리자가 어떻게(HOW) 할지를 고민하면, 구성원은 이걸 왜(WHY) 해야하는지 고민했습니다.

Open Organization에서는 구성원 스스로 일의 목적, 이유(WHY)를 찾습니다. 스스로 동기부여를 합니다. 중간관리자는 어떻게(HOW) 하면 일이 되게 만들지를 고민하며, 상위의사결정자는 전체적인 방향성(WHAT)을 설정합니다. 조직의 모습과 문화와 일하는 방식이 바뀌어야 합니다.

Open Source가 발전하게 된 것도 비슷한 맥락입니다. 사용하는 사람들, 만드는 사람들이 일을 찾아내기 때문에 빠르고 동기부여가 됩니다. 모든 것이 투명하게 관리되고 문제를 숨기는 것이 아니라 공유하고 빠르게 해결하는데 초점을 맞춥니다. 필요에 따라 개발됩니다.

Agile, DevOps등도 결국 일하는 방식의 변화하는 바가 가장 큽니다.

<Session A-1 Red Hat과 함께하는 하이브리드 클라우드 구축 방안>

멀티클라우드는 단순히 여러 종류의 클라우드를 사용하는 것이지만 하이브리드 클라우드는 이러한 여러 종류의 클라우드를 하나의 기술(OpenStack)로 관리하는 것이 목표입니다. 나아가서는 기존 Legacy까지!

물론 아직 갈길이 멉니다. (ex, 리전이 다를경우 Storage공유가 불가능함)

 일반적으로 사람들이 혼돈하는 것은 클라우드에서 중요한 것은 인프라라고 생각하는 것입니다.

중요한 것은 Application입니다. Application이 Scale Out가능하고 fault tolerance하게 개발되어야 하는 것이 먼저입니다. Application이 그렇게 개발되어 있다면 BareMetal, PrivateCloud, PublicCloud는 사실 크게 의미가 없습니다. 기존에도 MicroService는 있었습니다. 인프라는 이것을 기능적으로 더 편리하게 해주는 것입니다. 말 그대로 Cloud(구름)이기 때문에 DB, Network가 어떻게 구성되어 있는지 신경을 쓸 필요가 없게 되는 것입니다.

이제는 모든 것이 Software Define으로 가능합니다. “모든 기업은 소프트웨어 기업이다” 라는 말처럼 상품/비즈니스/개발/배포/인프라 모든 것이 소프트웨어를 통해 자동화가 됩니다. 적절한 API를 잘 사용하는 사람이 중요합니다.

<Session B-2 클라우드 네이티브 애플리케이션 개발을 위한 8가지 단계>

기술변화에 대한 배경이해가 필요합니다. 새로운 것을 개발하는 측면과 기존 것을 운영하는 측면의 대립을 의미하는 것이 아니라 보다 빠르게 개발하고 빠르게 배포하는 것이 궁극적인 목표입니다.

Service-based, API-Driven, Containers, DevOps가 일반적인 클라우드 네이티브App의 요소로 볼 수 있습니다.

결국 시장이 빠르게 변하고 있기 때문에 그에 맞춰서 개발도 빠르게, 변경/배포도 빠르게 되어야 합니다.

8단계를 통한 설명 (8단계는 선택적으로 가능함!)

1단계 : 대부분의 큰 조직들이 우리는 DevOps를 적용했다고 하지만 무엇을 하고 있는지에 대해서는 명확히 말하지 못합니다.

특히 사업,App,Infra등에서 실패를 겪는 것에 거부감을 가지면 안됩니다. 빠르게 극복하는 것에 초점을 두어야 합니다. 아무도 사용해본 적이 없고, 만들어 본적이 없기 때문에 당연히 실패합니다.  (ex, Google BigTable, Amazon OpenStack, )

2단계 : 기존 구조를 개선합니다. API기반으로 변경해나가고 Container형으로 만들어갑니다.

3단계 : 클라우드를 위한 서비스를 사용합니다.

4단계 : 필요에 따라 가장 적합한 기술을 선택합니다. (장표의 툴은 의미가 다릅니다.)

5단계 : 개발자가 필요에 따라서 인프라를 선택하고 사용합니다.

6단계 : 배포를 위한 내용들을 자동화합니다.

7단계 : CI/CD PipeLine을 구성합니다. 단순배포 뿐만 아니라 변경분만 배포, 실패시 Rollback, UnitTest등의 액션들을 자동화합니다.

8단계 : 부분적으로 점진적으로 Service형태의 아키텍처로 만듭니다. (과거 SOA, Web, 의 연장, 내외부 포함)

<Session B-3 API 중심의 애자일한 통합 방법 : API에서부터 iPaaS까지>

과거의 개발방식과 현재의 개발방식에는 많은 차이가 있습니다. 이를 어떻게 통합해 나갈 것인가.?

Hybrid Cloud는 Public Cloud, Private Cloud뿐만 아니라 과거의 시스템도 하나로 통합해야 한다고 봅니다.  (서비스, 어플리케이션, API, 데이터) 관점

주의해야 할 점은 Centralize가 아닌 필요한 곳만 통합하는 것이 되어야 한다는 점입니다.

(RedHat은 API, Disributed Integraion, Container 관점으로 접근

<Session B-5 Red Hat solutions on Azure와 함께하는 Empowering Digital Transformation>

기조 연설에 나왔던 내용입니다. 증기기관의 발명이 모든 것을 바꾸었고, 전기의 발명이 그러했듯Digital Transformation이 모든 기존의 방법을 바꾸고 있습니다.

오픈소스에 대한 마이크로 소프트의 접근도 바뀌어 가고 있습니다.

과거 Vendor사에 의존적이었던 것들이 이제 오픈소스로 누구나 접근할 수 있으며 필요에 의해 만들고 빠르게 공유하며 발전하는 세상이 되었습니다.

Red Hat과 Microsoft도 같이 일합니다!

Linux 든 Windonws 든 RedHat Midlleware구입하면 모두 지원한다고 함!)

심지어 OpenJDK도 OS관계없이 지원함.

<정리 >

RedHat Forum에서 전반적으로 말하는 것이 시장의 흐름과 크게 다르지 않습니다.

1.     Cloud의 등장이 Legacy의 사라짐을 의미하지는 않습니다. 다만 API를 중심으로 시스템들이 통합되어가는 모습이 될 것입니다.

2.     모든 기업은 소프트웨어 기업이 될것이다. 는 이미 이루어지고 있고..

3.     또한 IT내에서도 하드웨어 역시 소프트웨어로 통합되고 있습니다. (Software Defined Network, Datacenter)

4.     시스템개발 뿐만 아니라 운영/자원관리/배포/인프라의 영역도 개발로 전환되고 있으며 이에 따라 IT전문가의 영역도 개편되고 있습니다. 

     기존의 SA,TA,DA,DBA의 역할구분도 점점 없어짐. 주변에 보면 부지런한 DA,DBA들은 코딩 배워서 NoSQL병행하신지 오래되었고, SA,TA분들도 클라우드업체의 솔루션 아키텍트로 전환해서 제공되는 구성요소를 활용해서 고객에게 제공하는 (코딩) 영역으로 전환하고 있음.

     거꾸로 개발자들이 Network, DB, OS 공부해서 이제는 클라우드에서 알아서 골라서 설치하고 튜닝해서 사용하고 있음.

     기존의 영역만 고집하는 사람은 시장에서 도태됨.

5.     기술의 발전 흐름은 결국 시장의 변화에 대응하기 위함입 

     빠르게 개발하여 시장에 적기에 출시하는 것이 Agile이고 

      그 피드백을 반영하여 다시 제품에 녹이는 것이 DevOps

      CI/CD는 이러한 과정에서 수작업을 줄여서 속도를 개선하고 실수를 없애는 것

      사용량에 따라서 유동적으로 변화 가능한 Application구조가 MSA이며

      이를 뒷받침하는 기술이 container, cloud

       각각의 비즈니스 요건에 따라서 다른 기술을 사용하는 것이 polyglot, Service-Based이며, 

       이러한 시스템을 다시 하나로 합치기 위해서 API-Based가 중요해지고 있음.

6.   Cloud에서 인프라는 큰 의미가 없음. 중요한 것은 Application임. 

     Application이 Scale out, Fault tolerance 하도록 만들어져야 함. 예전에도 이러한 구조의 프로그램들은 있었으나 인프라기술이 뒷받침되지 못해서 수작업으로 진행해야 했던 부분들임

     이제는 Cloud에서 이러한 것들을 편하게 할 수 있도록 기술적으로 지원하고 있음

     말그대로 구름뒤는 신경쓸 필요없이 Application을 유연하게 만드는 것이 집중하면 됨.

     거꾸로 Application이 그렇지 않다면 무슨 인프라를 사용하던 크게 나아지지 않음

 모든 것이 연결된다. 기술이기도 하고 문화이기도 하고 도구 이기도 함!

 이중에 하나라도 결여가 되면 진정할 발전이 어려움

 (다들 잘 아시는 콘웨이의 법칙, 소프트웨어 구조가 소프트웨어를 개발하는 조직의 구조를 따라갑니다.)

최근 Reactive Programing이라는 개념이 많이 사용되고 있어서 관련하여 개념들을 정리를 해보려고 한다.

1. Event Driven