<필요사항>

- AWS ECS상 워크로드 중 특정서비스의 로그를 수집/가공 하여 통계 정보를 제공

- 기존에 사용중이던 AWS SDK S3 와 호환성 

 

<개요> 

- https://docs.aws.amazon.com/cloudwatch/index.html

 

https://docs.aws.amazon.com/cloudwatch/index.html

 

docs.aws.amazon.com

- AWS는 Cloudwatch 내에서 특정 로그그룹에 대하여 쿼리할 수 있는 툴 (Insight) 를 제공하고 있다.

- 해당 기능을 Web, SDK등 다양한 형태로 제공하고 있으며 Java SDK를 사용했다.

 

<내용>

- Java용 AWS SDK는 크게 버전 1.x , 2.x 가 있으며 특히 2.x 부터 비동기 NonBlocking 및 CompletableFuture를 제공하고 있기 때문에 신규 개발의 경우 가급적 2.x 를 권장하고 있다.

- 현재 서비스에서 S3용  1.x SDK를 이미 사용중이고 CloudWatchLogs는 2.x SDK를 사용할 예정이기 때문에 Mig 를 하던지 두 가지 버전을 병행하던지 선택한다.

- 기존 기능에 큰 문제가 없기 때문에 일단 병행하기로 결정

 

<환경설정 및 변경사항>

1. pom.xml

- groupId 변경

ver 1.x ver 2.x
com.amazonaws software.amazon.aws.sdk
<dependency>
	<groupId>com.amazonaws</groupId>
	<artifactId>aws-java-sdk-s3</artifactId>
	<version>1.11.762</version>
</dependency>

<dependency>
	<groupId>software.amazon.awssdk</groupId>
	<artifactId>cloudwatchlogs</artifactId>
</dependency>

<dependencyManagement>
  <dependencies>
      <dependency>
          <groupId>com.amazonaws</groupId>
          <artifactId>aws-java-sdk-bom</artifactId>
          <version>1.12.1</version>
          <type>pom</type>
          <scope>import</scope>
      </dependency>
      <dependency>
          <groupId>software.amazon.awssdk</groupId>
          <artifactId>bom</artifactId>
          <version>2.16.1</version>
          <type>pom</type>
          <scope>import</scope>
      </dependency>
  </dependencies>
</dependencyManagement>

 

2. @Configuration

public BasicAWSCredentials awsCredentials(){
        BasicAWSCredentials awsCreds = new BasicAWSCredentials(accessKey, secretKey);
        return awsCreds;
    }

    @Bean
    public AmazonS3 amazonS3Client(){
        AmazonS3 amazonS3 = AmazonS3ClientBuilder.standard()
                .withRegion("ap-northeast-2")
                .withCredentials(new AWSStaticCredentialsProvider(this.awsCredentials()))
                .build();
        return amazonS3;
    }

 - 기존에는 BasicAWSCredentials 를 사용하고 있었으며 Region 이 String 으로 사용되고 있어서 오타의 위험이 있다.

@Configuration
public class AmazonCloudWatchLogsConfig {

    @Value("${spring.cloud.aws.credentials.access-key}")
    private String accessKey;

    @Value("${spring.cloud.aws.credentials.secret-key}")
    private String secretKey;

    public AwsBasicCredentials awsBasicCredentials(){
        AwsBasicCredentials awsCreds = AwsBasicCredentials.create(accessKey, secretKey);
        return awsCreds;
    }

    @Bean
    public CloudWatchLogsAsyncClient cloudWatchLogsAsyncClient(){

        CloudWatchLogsAsyncClient cloudWatchLogsAsyncClient = CloudWatchLogsAsyncClient.builder()
                .region(Region.AP_NORTHEAST_2)
                .credentialsProvider(StaticCredentialsProvider.create(this.awsBasicCredentials()))
                .build();
        return cloudWatchLogsAsyncClient;
    }

- Ver2에서는 AwsBasicCredentials로 변경이 되었으며, new 를 사용하지 않고 create를 사용한다.

- Region 설정이 enum type으로 변경되어 사용자의 실수를 막아준다.

- 또한 필요에 따라서 HttpClient를 Netty로 변경할 수 도 있다.

 

<AWS SDK를 사용하여 AWSCloudWatchLog를 활용하는 방법>

- SDK에서 사용할 IAM을 사전에 생성할 필요가 있다.

- Log를 조회하는 것은 크게 2단계로 나누어진다.

 a. startQuery

StartQueryResponse ret = cloudWatchLogsAsyncClient.startQuery(StartQueryRequest.builder()
                                                .endTime(endTime)
                                                .startTime(startTime)
                                                .limit(n)
                                                .logGroupName("")
                                                .queryString(query)
                                                .build()
                                  ).join();

 쿼리 수행을 마치고 나서 결과값으로 unique한 queryId를 돌려주는데 이 값을 사용하여 쿼리결과를 조회한다. 

 

b. getQueryResults

GetQueryResultsResponse queryReponse = cloudWatchLogsAsyncClient.getQueryResults(GetQueryResultsRequest.builder().queryId(queryId).build()).join();

 queryId를 통해서 GetQueryResultsResponse 를 얻어올 수 있다.

여기서 주의해야 할 것은 GetQueryResultsResponse 내에는 QueryStatus가 존재하며 Running, Scheduled등 일 경우 전체결과가 조회되지 않을 수 있다는 점이다.

처음 작업할때 ComletableFuture의  join을 호출하는 시점에 모든 결과가 있을것으로 예상하여 원하는 값이 나오지 않아서 고민했었다.

 

c. Async방식

 위에서 언급한 것 처럼 AsyncClient를 사용할 경우 CompletableFuture를 return하도록 되어있기 때문에 callback을 작성하여 불필요한 대기를 최소화할 수 것으로 예상했다.

 하지만 구조자체가 응답으로 queryId를 받아와야 하고, 또 쿼리 결과를 조회할때에도 Complete 상태에 이르러야 완벽한 결과값이 세팅되는 점을 감안한다면 해당 API를 사용하는 유저시나리오는 Async-blocking에 가깝다.

 

<결론>

- 해당 기능을 통해서 AWS Cloudwatch 에 수집되고 있는 로그그룹에 접근하여 일정시간 동안 많이 입력된 키워드, 로그인한 사용자, requestUri정보 등을 집계하여 API로 제공중이다.

- 쿼리 사용시 주의해야할 점은 Scan하는 Log의 양만큼 비용을 지불하기 때문에 startTime, endTime을 적절하게 조정해야 한다.

 

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 사가 현황을 공유하였습니다. JUNIPERSDN을 비롯한 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입니다. ApplicationScale 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 HatMicrosoft도 같이 일합니다!

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이 그렇지 않다면 무슨 인프라를 사용하던 크게 나아지지 않음



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

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

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



'컨퍼런스' 카테고리의 다른 글

Azure Everywhere 2019 후기  (0) 2019.01.12
Spark Summit 2017  (0) 2017.02.16

+ Recent posts