이 글은 2019 졸업생 엔지니어 Advent Calendar 2019의 나흘째 글이다.
엔지니어로서 업무 중에 알게 된 서비스 메시라는 디자인 마인드가 흥미롭기 때문에 자신의 언어로 개요를 설명하는 동시에 간단한 서비스 메시를 만들어 알려준다.

Service Mesh의 개요

서비스 메시의 끝은?

Service Mesh란 네트워크 주변의 Gonigo를 애플리케이션 계층에서 다른 계층으로 옮기는 것입니다. 잘 부탁드립니다.라고 디자인 마인드를 밝혔다.아마 그렇지 않을 것이다.솔직히 새로운 분야로 서비스 메시(istio와 linked)를 구가하는 제품인데 앞으로 어떤 느낌을 받을지.하지만 이번에는 이런 정의에 따라 하고 싶어요.
네트워크 주위의 처리 방법의 실례는 다음과 같다.

재시도

라우팅

캐나다 디자인

AB 테스트

고장 주입

회로 표지

상호 TLS 통신

Logging

어떻게 실현합니까?

서비스 메시는 데이터 평면과 제어 평면 두 개로 구성됩니다.
데이터 평면이란 애플리케이션별로 하나씩 준비된 프록시 서버로, 애플리케이션의 In/Out 통신은 모두 프록시를 통해 이루어집니다.
제어 평면은 데이터 평면을 조작하는 데 사용되며 현재 반영된 설정을 전달하고 도량을 수집하며 인증서를 관리하는 역할을 한다.
Service Mesh에서는 에이전트를 사용하여 다양한 처리를 처리합니다.따라서 응용 프로그램은 무의식적으로 이루어질 수 있다.
구체적인 서비스 메시 제품은 다음 웹 사이트를 참조하십시오.
프록시 서버는kubernetes에서 기본적으로 프록시용 용기를 만들어 실현하지만 반드시 용기가 필요하지 않고 물리적 기계, VM 등으로 실현할 수 있다.

Service Mesh가 뭐가 그렇게 좋아요?

왜 특별히 Service Mesh를 사용합니까?재시도 등 처리라면 응용 프로그램에서 실현할 수 있고, 중간에 프록시 서버가 끼면 통신하는lantencty도 나빠진다.또 데이터 평면을 관리하고 운용하며 평면을 제어하는 부품을 관리하는 시간도 늘어난다.
이러한 단점을 뛰어넘을 수 있는 장점은 다음과 같다.

통신을 명시적으로 관리할 수 있음

예를 들어 재시도를 위해 수속을 쓰지 말고 세 번 해보세요!

통신 주위의 변경 시 Application의 원본 코드를 바꾸지 않을 수 있음

상기 통신을 처리할 때 언어나 프레임워크에 얽매이지 않아도 된다

Application 자체를 낮추지 않고 변화를 반영할 수 있다

이를 요약하면 앱과 통신 주변의 관계를 해소할 수 있다는 것이 Servish Mesh의 장점이다.
서비스 메시와 네트워크 처리가 더 중요해진 Micro Service는 친화력이 있지만, 반드시 Micro Service의 컨텍스트에서 서술해야 하는 것은 아니고, 단일한 방법에서도 효과적인 아이디어로 이해하는 것이 좋다.

서비스 메시를 만들어 보도록 하겠습니다.

서비스 메시를 조금 더 접하기 위해 간단한 서비스 메시를 만들기로 했다.필자는 Ruby만 쓸 줄 알기 때문에 구성 요소는 모두 Ruby로 쓰고 docker-compose로 작동합니다.

이번 구성.

Service Mesh를 만들기 위해 다음과 같은 구성을 고려해 보겠습니다.
success/failure를 바디의 서버에 1:9 비율로 넣습니다.rb

control.rb에서 얻은 횟수를 다시 시도하다.rb

proxy.rb에 대한 대답을 다시 해야 하는 횟수.rb

server.rb 응용 분야에서proxy.rb와 control.rb는 Service Mesh의 구성 요소입니다.일반적인 경우, 정확한 반응을 얻기 위해서는 재시도 처리가 필요하지만, 우리는 proxy로 처리를 쓸 것입니다.

소스 코드당
server.rb

require 'webrick'

server = WEBrick::HTTPServer.new({ 
    :Port => 3001
})

server.mount_proc '/' do |req, res|
    if rand(10) == 0
        puts res.body = "success\n"
    else
        puts res.body = "failure\n"
    end
end

server.start

proxy.rb

require 'webrick'
require 'webrick/httpproxy'
require 'uri'
require 'retryable'
require 'net/http'

handler = Proc.new() do |req,res|
  retry_count = Net::HTTP.get  URI.parse('http://host.docker.internal:3002')
  p "retry-setting: #{retry_count}"
  Retryable.retryable(tries: retry_count.to_i, sleep: 0) do |retries, exception|
    if res.body == "failure\n"
      res.body = Net::HTTP.get req.request_uri
      raise "error"
    else
      puts "retry: #{retries}"
    end
  end
rescue
  res.body = "failure\n"
end

s = WEBrick::HTTPProxyServer.new(
  :Port => 3000,
  :ProxyContentHandler => handler
)

Signal.trap('INT') do
  s.shutdown
end

s.start

control.rb

require 'webrick'

server = WEBrick::HTTPServer.new({ 
    :Port => 3002
})

server.mount_proc '/' do |req, res|
    res.body = ENV["RETRY"] || 10
end

server.start

FROM ruby:2.5

RUN apt-get update

WORKDIR /home/ruby

docker-compose.yml

version: '2'

services:
  proxy:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./:/home/ruby
      - bundle_install:/usr/local/bundle
    ports:
      - "3000:3000"
    depends_on:
      - server
    command:
      ruby proxy.rb
  server:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./:/home/ruby
    ports:
      - "3001:3001"
    command:
      ruby server.rb
  control:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./:/home/ruby
    environment:
      - RETRY=10
    ports:
      - "3002:3002"
    command:
      ruby control.rb
volumes:
  bundle_install:
    driver: local

상술한 구성을 제작함으로써

curl host.docker.internal:3001 -x host.docker.internal:3000

위에서 말한 바와 같이 프록시 요청을 통해 원래 10%의 성공률로 재시도 수가 높은 성공률을 얻을 수 있었다.

고찰하다.

이번에는 간편하게 요구하는 쪽이 대리를 가리키기 위해 반전 대리의 형식을 요구하는 쪽이 정확한 형식이라는 것을 의식하지 못했다고 본다.
또한 요청할 때마다 컨트롤 평면에 현재 설정된 요청을 확인하지만 매번 확인하는 것은 자원 낭비이기 때문에 먼저 캐시를 하거나 변경이 있을 때push를 해야 한다.
우리를 위해 이런 일을 잘 해줄 수 있는, 바로 아이티오 같은 제품이죠.

참고 자료

https://servicemesh.io/
https://www.oreilly.com/library/view/istio-up-and/9781492043775/