Fire Engine

化学の修士号→消防士→ITエンジニア(2016年11月〜)

「A Tour of Go」でGoに再入門した

もうかれこれ4ヶ月くらいGoを書いているんだけど、最初に文法を体系的に学ばずにいきなり書き始めたので、「A Tour of Go」で復習がてら文法を学びました。
実際にやってみると、理解が曖昧だったり、知らなかったことも出てきたので、そういったものだけピックアップして備忘録的にまとめていきます。

deferへ渡した関数はスタックされる

呼び出し元の関数がreturnするとき、 deferへ渡した関数はLIFO(last-in-first-out)の順番で実行される。

package main

import "fmt"

func main() {
    defer fmt.Println("1")
    defer fmt.Println("2")
    defer fmt.Println("3")

    fmt.Println("return")
}

//=>
return
3
2
1

型推論

明示的な型を指定せずに変数を宣言する場合(:=var =のいずれか)、変数の型は右側の変数から型推論される。

package main

import "fmt"

func main() {
    i := 10
    var j = 3.14
    fmt.Printf("%T\n", i)
    fmt.Printf("%T\n", j)
}

//=>
int
float64

ポインタ(*と&について)

package main

import "fmt"

func main() {
    i := 10

    p := &i         // アドレス演算子「&」を使うと、任意の型からそのポインタ型を生成できる
    fmt.Println(*p) // 演算子*をポインタ型の変数の前に置くことで、ポインタ型が指し示すデータのデリファレンスができる
    *p = 20         // ポインタを通してiに値をセットする
    fmt.Println(i)  
}

//=>
10
20

スライスは配列への参照のようなもの

スライスはどんなデータも格納しておらず、単に元の配列の部分列を指し示している。
スライスの要素を変更すると、その元となる配列の対応する要素が変更される。

package main

import "fmt"

func main() {
    names := [3]string{
        "John",
        "Paul",
        "George",
    }
    fmt.Println(names)

    a := names[0:2]
    fmt.Println(a)
    a[0] = "Tsurubee"
    fmt.Println(names)
}

//=>
[John Paul George]
[John Paul]
[Tsurubee Paul George]

下は配列リテラル

[3]bool{true, true, false}

そして、これは上記と同様の配列を作成し、それを参照するスライスを作成する

[]bool{true, true, false}

スライスは長さ(length)と容量(capacity)をもつ

package main

import "fmt"

func main() {
    s := []int{1, 2, 3, 4}
    fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)

    s = s[:2]
    fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

//=>
len=4 cap=4 [1 2 3 4]
len=2 cap=4 [1 2]

mapに要素が入っているか確認

キーに対する要素が存在するかどうかは、2つの目の返値で確認する。
もし、keyがあれば、変数okはtrueとなり、存在しなければ、okはfalseとなる

package main

import "fmt"

func main() {
    m := make(map[string]int)
    m["Answer"] = 10

    v, ok := m["Answer"]
    fmt.Println(v, ok)
}

//=>
10 true

アサーション

インターフェースの値が特定の型を保持しているかどうかをテストするために、型アサーションは2つの値(基になる値とアサーションが成功したかどうかを報告するブール値)を返すことができる。

package main

import "fmt"

func main() {
    var i interface{} = "hello"

    s, ok := i.(string)
    fmt.Println(s, ok)

    f, ok := i.(float64)
    fmt.Println(f, ok)
}

//=>
hello true
0 false

型switch

型switchは通常のswitch文と似ているが、型switchのcaseは型(値ではない)を指定し、それらの値は指定されたインターフェースの値が保持する値の型と比較される。

package main

import "fmt"

func do(i interface{}) {
    switch v := i.(type) {
    case int:
        fmt.Println("Int type!")
    default:
        fmt.Printf("I don't know about type %T!\n", v)
    }
}

func main() {
    do(10)
    do("hello")
    do(true)
}

//=>
Int type!
I don't know about type string!
I don't know about type bool!

selectで複数のチャネルを処理する

selectは、複数あるcaseのいずれかが準備できるようになるまでブロックし、準備ができた caseを実行する

package main

import "fmt"

func main() {
    ch1 := make(chan int, 1)
    ch2 := make(chan int, 1)
    ch2 <- 1

    select {
        case <-ch1:
            fmt.Println("ch1!")
        case <-ch2:
            fmt.Println("ch2!")
        default:
            fmt.Println("default!")
    }
}

//=>
ch2!

Golangで軽量なSSHサーバを実装する

今回は、Golanggolang.org/x/crypto/sshパッケージを使って、SSHサーバを構築してみました。
かなりミニマムな実装ですが、リモートからSSH接続して、対話的にコマンドが実行できるところまで実装しました。

コード

github.com

package main

import (
    "golang.org/x/crypto/ssh"
    "log"
    "net"
    "io/ioutil"
    "fmt"
    "os/exec"
    "github.com/kr/pty"
    "sync"
    "io"
)

func main() {
    serverConfig := &ssh.ServerConfig{
        NoClientAuth: true,
    }

    privateKeyBytes, err := ioutil.ReadFile("id_rsa")
    if err != nil {
        log.Fatal("Failed to load private key (./id_rsa)")
    }

    privateKey, err := ssh.ParsePrivateKey(privateKeyBytes)
    if err != nil {
        log.Fatal("Failed to parse private key")
    }

    serverConfig.AddHostKey(privateKey)

    listener, err := net.Listen("tcp", "0.0.0.0:2222")
    if err != nil {
        log.Fatalf("Failed to listen on 2222 (%s)", err)
    }
    log.Print("Listening on 2222...")

    for {
        tcpConn, err := listener.Accept()
        if err != nil {
            log.Fatalf("Failed to accept on 2222 (%s)", err)
        }

        sshConn, chans, reqs, err := ssh.NewServerConn(tcpConn, serverConfig)
        if err != nil {
            log.Fatalf("Failed to handshake (%s)", err)
        }
        log.Printf("New SSH connection from %s (%s)", sshConn.RemoteAddr(), sshConn.ClientVersion())

        go ssh.DiscardRequests(reqs)
        go handleChannels(chans)
    }
}

func handleChannels(chans <-chan ssh.NewChannel) {
    for newChannel := range chans {
        go handleChannel(newChannel)
    }
}

func handleChannel(newChannel ssh.NewChannel) {
    if t := newChannel.ChannelType(); t != "session" {
        newChannel.Reject(ssh.UnknownChannelType, fmt.Sprintf("Unknown channel type: %s", t))
        return
    }

    sshChannel, _, err := newChannel.Accept()
    if err != nil {
        log.Fatalf("Could not accept channel (%s)", err)
        return
    }

    bash := exec.Command("bash")

    close := func() {
        sshChannel.Close()
        _, err := bash.Process.Wait()
        if err != nil {
            log.Printf("Failed to exit bash (%s)", err)
        }
        log.Printf("Session closed")
    }

    f, err := pty.Start(bash)
    if err != nil {
        log.Printf("Could not start pty (%s)", err)
        close()
        return
    }

    var once sync.Once
    go func() {
        io.Copy(sshChannel, f)
        once.Do(close)
    }()
    go func() {
        io.Copy(f, sshChannel)
        once.Do(close)
    }()
}

コードについていくつか補足します。

ローカルPCとSSHサーバのSSHセッションを確立する前に、まずTCPレイヤーのコネクションを確立する必要があります。私の中でTCPコネクションはローカルマシンとリモートマシンのソケット同士の論理的な回線というイメージで、SSHセッションというと、SSHのレイヤーすなわちアプリケーションレイヤーまで広がり、セッションの中でコネクションが管理されているイメージです。
実際のコードでは、net.ListenTCPをListenし、Acceptして返ってきたTCPコネクションを、ssh.NewServerConnに渡すことで、認証を行った後、SSHのセッションが確立されます。

SSHのセッションが確立されると、あとはSSH経由でコマンドを実行して、その結果が対話的に表示されるようにしたいです。この対話的の部分にはio.Copyを使います。
io.Copyを使うと、io.Readerインターフェースからio.Writerインターフェースにそのままデータを渡すことができます。これを使って、擬似端末(pty)とSSHチャンネル(goのchannelとは違う、SSHのコネクションのようなもの)の間で双方向にCopyしてやると、入出力が対話的にやれます。

使い方

SSHサーバのホスト認証のために、公開鍵と秘密鍵のペアを作成し、リポジトリのルートディレクトリの置きます。

ssh-keygen -t rsa -N '' -f ./id_rsa

生成された公開鍵(id_rsa.pub)はローカルPCのknown_hostsに以下のような感じで登録しておきます。

[localhost]:2222 ssh-rsa AAAAB3・・・・

あとは下のコマンドでDocker上にSSHサーバが起動します。

$ docker-compose up
Starting gosshd_gosshd_1 ... done
Attaching to gosshd_gosshd_1
gosshd_1  | ==> Installing Dependencies
gosshd_1  | go get -u github.com/golang/dep/...
gosshd_1  | dep ensure
gosshd_1  | go run main.go
gosshd_1  | 2018/07/28 12:44:31 Listening on 2222...

ローカルPCからポート2222にSSH接続すると、コンテナの中に繋がります。

$ ssh tsurubee@localhost -p 2222
root@9cd2bdaf33c0:/go/src/gosshd#

今回ユーザ認証の機能はOFFにしているのでユーザ名はなんでも大丈夫です。 あとは普通にサーバにSSHで繋いだときのようにコマンドが実行できます。

root@9cd2bdaf33c0:/go/src/gosshd# pwd
/go/src/gosshd
root@9cd2bdaf33c0:/go/src/gosshd# ls
Gopkg.lock  Makefile   docker-compose.yml  id_rsa.pub  vendor
Gopkg.toml  README.md  id_rsa          main.go

さいごに

今回はミニマム実装なので、実用的なSSHサーバになるまでには、認証周りの実装や、 SSHグローバルリクエストやチャネルリクエストの取り回しも実装しないといけないです。
これからやりたいのはRFCを読んでSSHプロトコルに関する理解を深めるのと、SSHのリバースプロキシを実装してみることです。

参考

GitHub - mattn/go-sshd: DEPRECATED: Please use https://github.com/gliderlabs/ssh instead

「Working with TCP Sockets」を読んだ

最近Golangを書いていると、自分でTCPをListenしたり、Acceptしたりする処理を書くことがよくあるのですが、何をやっているのか全くイメージが沸いてなかったので、「Working with TCP Sockets」を読んで勉強しました。

Working With TCP Socketswww.jstorimer.com

だいたいこの手のソケットプログラミング関連の本は、C言語で解説されていることが多いと思うのですが、本書はサンプルコードが全てRubyなので、非常に読みやすいです。残念ながら英語版しかありません。
以下、私がポイントだと思ったことだけをまとめた読書ノートです。

読書ノート

前半はソケットとは?から始まり、ソケットプログラミング自体の入門的な内容で、そのあたりの理解が曖昧だった私にはとても勉強になりました。
後半は、ソケットプログラミングを使った実用的なアーキテクチャパターンの話でした。Preforkとかイベント駆動とかWebサーバの実装において非常に重要な概念が解説されていましたが、今私が一番知りたいこととは離れていたため、斜め読みしました。

Your First Socket

  • IPアドレスとポート番号のペアはそれぞれのソケットでユニークでなければならない。

Establishing Connections

  • ソケットは、以下のいずれかの役割を持つ
    1.initiator
    2.listener

いわゆるクライアントとサーバ

Server Lifecycle

  • サーバソケットの典型的なライフサイクル
    1.create
    2.bind
    3.listen
    4.accept
    5.close

  • bindは、createしたソケットとlistenするポートをbind(結びつける)
    他のソケットは同じポートをbindできない。

  • acceptメソッドでサーバが受付状態になる。
    acceptは「ブロッキング」な処理である。新しい接続を受け取るまで、現在のスレッドの処理を停止させる

  • acceptの返り値としてconnectionがreturnされるが、connectionはただのSocketクラスのインスタンスである(Rubyの場合)
    connectionのファイルディスクリプタはサーバソケットのものと異なる。各connectionは新しいSocketオブジェクトとして表され、サーバソケットはそのまま残り、新たなconnectionを受け続けることができる。

  • すべてをファイルとして扱うUnixの世界ではSocketもファイルだ。

  • それぞれのTCPコネクションは、ローカルホスト・ローカルポート・リモートホスト・リモートポートの組み合わせで一意に識別される

  • ソケットは双方向通信(読み/書き)なので、いずれか片方だけを閉じることができる

Client Lifecycle

  • クライアントの典型的なライフサイクル
    1.create
    2.bind
    3.connect
    4.close

  • クライアントでは、bindを使うことはまれである。bindを使わなかった場合、クライアントソケットはランダムなエフェメラルポートが与えられる。クライアントは外部からの接続を受け付ける必要がないので、ポート番号を明らかにする必要もない。

  • connectを呼び出すと、リモートのソケットへの接続が始まる

Exchanging Data

  • TCPコネクションは、ローカルソケットとリモートソケットをつなぐ管の連なりのようなイメージ(論理的な回線)

Sockets Can Read

  • UNIXにおいては、全てをファイルとして取り扱う。read(2)やwrite(2)はシステムコールレベルで共通しているので、ファイル、ソケット、パイプ等で共通して利用できる。

  • readの呼び出しは、全てのデータが届くまで待ちを発生させる
    この問題に対する解決策は2つある

  • クライアントがEOFを送る
    EOFは、文字というよりも、状態を表すイベントである。クライアントからEOFを送る際の最も簡単な方法は、ソケットを閉じることである。

  • サーバが部分的な読み取りを使用する
    読み取るデータの最大長を指定して、ブロックせず、すぐに利用できるデータだけが返す。

Buffering

  • writeを呼び出し、エラーなく完了した場合、それは「データの送信に成功し、クライアントが受け取った」ことを意味しない。それは、OSのカーネルによってデータが処理可能な状態になったことが保証されているだけである。

  • バッファリング
    ネットワークを越えたデータ送信は遅いので、できるだけ回数を減らしてパフォーマンスを向上させたい。
    一般的には、一度に全てを書き込むと良いパフォーマンスが得られるが、メモリに載らないよう大きなデータやファイルは分割すべきである。

  • readに読み込みの最大長を渡すと、最大長を超える部分はバッファリングされる
    カーネルは、readの読み込みに指定したサイズのメモリを確保するため、そのサイズが大きすぎると、リソースの無駄が多くなる。
    一方、サイズが小さすぎると、システムコールの呼び出し回数が増えるためパフォーマンスが劣化する。
    どのくらいの読み込みサイズが適切かは、プログラムが取り扱うデータのサイズによって異なる。

Non-blocking IO

  • ノンブロッキングIOは、コネクションの多重化によって実現される。

  • ノンブロッキングIOしたあと、読み込み書き込み可能になるまでを知るにはIO.selectを使う
    selectは登録したソケットをブロッキング状態で監視し、いずれかがデータ受信するとブロッキング状態を解除する。

Multiplexing Connections

  • コネクションの多重化とは、同時に複数のアクティブなソケットを使用することである。

  • select(2)は監視対象のコネクション数が増えると、線形的にパフォーマンスが低下する
    poll(2)はselect(2)の代替だがそれほどの差はない

  • (Linux)epoll(2) または (BSD)kqueue(2) は、select(2)およびpoll(2)のモダンな代替である

SSL Sockets

  • SSLは、公開鍵暗号によって、ソケット上でデータを安全にやりとりできる仕組みを提供する。
    SSLTCPを置き換えるので飯買う、SSLによるsecure layerはTCPの上に追加されるイメージ。

Preforking

Preforkパターンでは、接続がくるたびに子プロセスをforkするのではなく、サーバ起動時にプロセスをまとめてforkしておく
ワークフローは以下の通りである

  1. メインのサーバプロセスがlistenするソケットを作成
  2. メインのサーバプロセスが一群の子プロセスをfork
  3. それぞれの子プロセスが共有されたソケットから接続を受け取り、独立して処理する
  4. メインのサーバプロセスは子プロセスを監視する

Evented (Reactor)

イベント駆動のパターンはNginxを始めとした有名なライブラリで採用されている。
このパターンはシングルスレッド・シングルプロセスで、並列性を実現する
ワークフローは以下の通りである

  1. サーバはソケットでコネクションをモニターする
  2. 新しいコネクションを受け取ると、モニター対象ソケットのリストに追加する
  3. サーバはアクティブなコネクションをモニターしながら、ソケットをlistenする
  4. アクティブなコネクションが読み込み可能になった通知を受け取ると、サーバはコネクションからデータを読み取り、関連するコールバックを実行する
  5. アクティブなコネクションがまだ読み込み可能であるという通知を受け取ると、サーバはコネクションからデータを読み取り、再びコールバックを実行する
  6. サーバが新しいコネクションを受け付けたら、モニター対象ソケットのリストに追加する
  7. サーバは最初のコネクションが書き込み可能になったという通知を受け取ったら、レスポンスが書き込まれる

Working With TCP Sockets (English Edition)

Working With TCP Sockets (English Edition)

ユーザ名から特定したホストにコマンドを実行するSSHプロキシを書いてみる

今回は、勉強のために簡単なSSHプロキシサーバを実装してみました。
動作としては、ユーザがプロキシサーバに対してSSH接続した際に、ユーザ名からプロキシ先ホストを動的に決定し、SSH接続します。そして、接続したホストに対してhostnameコマンドを実行し、実行結果をクライアント側が受け取るという感じのものです。

やりたいこと

今回の実装はまだ実用的なものではありませんが、最終的にはSSHのユーザ名ベースで接続先のバックエンドを切り替えられるSSHプロキシサーバを構築したいと思っています。
イメージは下のような感じです。

f:id:hirotsuru314:20180722151037p:plain

これは一見ProxyCommandなどを使って踏み台サーバ経由でSSH接続をしているだけのように見えるのですが、大きな違いは ユーザ側が接続先サーバのことを全く意識しない ことです。
ProxyCommandの場合、ユーザ側が接続先サーバと踏み台サーバの情報を知っていますが、私がやりたいことは、ユーザはSSHプロキシサーバにSSH接続するだけで、勝手に特定のホストに接続が振り分けられる、というものです。

実際にこのような動作をするSSHプロキシサーバはOSSとして存在します。

github.com

このsshpiperは非常によくできていて、ユーザと接続先サーバの紐付け情報をMySQLで管理して、SSH接続をトリガーに接続先ホストの情報をDBからSELECTするような処理も実装されています。
一方で、DBに投げるクエリがコードに直書きされていて、使う側がテーブル構成等を合わせないといけなかったり、若干柔軟性に欠ける実装になっています。

コード

github.com

package main

import (
    "github.com/gliderlabs/ssh"
    gossh "golang.org/x/crypto/ssh"
    "log"
    "bytes"
    "errors"
    "io"
    "strings"
)

func findUpstreamByUsername(username string) (string, error) {
    if username == "tsurubee" {
        return "host-tsurubee", nil
    } else if username == "bob" {
        return "host-bob", nil
    }
    return "", errors.New(username + "'s host is not found!")
}

func main() {
    ssh.Handle(func(sess ssh.Session) {
        username := sess.User()
        upstream, err := findUpstreamByUsername(sess.User())
        if err != nil {
            log.Fatal(err.Error())
        }
        log.Printf("Connecting for %s by %s\n", upstream, username)

        config := &gossh.ClientConfig{
            User: username,
            Auth: []gossh.AuthMethod{
                gossh.Password("test"),
            },
            HostKeyCallback: gossh.InsecureIgnoreHostKey(),
        }

        clientConn, err := gossh.Dial("tcp", upstream + ":22", config)
        if err != nil {
            panic(err)
        }
        defer clientConn.Close()

        usess, err := clientConn.NewSession()
        if err != nil {
            panic(err)
        }
        defer usess.Close()

        var b bytes.Buffer
        usess.Stdout = &b
        if err := usess.Run("hostname"); err != nil {
            log.Fatal("Failed to run: " + err.Error())
        }
        r := strings.NewReader(b.String())
        io.Copy(sess, r)
    })

    log.Println("Starting ssh server on port 2222")
    ssh.ListenAndServe(":2222", nil)
}

検証用にDocker環境を用意したのでまずはそちらを立ち上げます。

docker-compose up

これでローカルホストの2222ポートでプロキシサーバが立ち上がり、プロキシ先ホストとして、host-tsurubeehost-bobが立ち上がります。
すると、下記のように、ユーザ名tsurubeeでSSH接続したときは、プロキシサーバ経由で、tsurubee用ホスト(host-tsurubee)でhostnameコマンドを実行した結果がクライアント側に出力され、bobユーザのときはbob用ホスト(host-bob)のhostnameの結果が返ってきています。

$ ssh tsurubee@127.0.0.1 -p 2222
host-tsurubee

$ ssh bob@127.0.0.1 -p 2222
host-bob

このように同じローカルホストの2222番に接続してもユーザ名を元にプロキシされるサーバが振り分けられています。

今回、ユーザ名からプロキシ先ホストを特定するfindUpstreamByUsername関数に簡単に条件分岐を書きましたが、本来この処理はDBから取得するなり、APIサーバから取得するなりしておきたいところです。

また、SSHサーバの構築には、gliderlabs/sshを使いました。これを使うと簡単に指定のポートでListenするSSHサーバを立てられるので便利です。

gliderlabs/sshでListenしたSSHサーバにリクエストがきて、セッションが確立されると、ハンドラーが呼ばれるため、そのハンドラーはプロキシ先に対するSSHクライアントとして動作するように書いています。

最後に

本来は接続先のサーバに対して、ターミナルからサーバにログインした時のように対話的に操作できるようにしたいんだけど、いまいちセッションとかコネクションの取り回しが理解しきれていないため勉強中。
しかし、中途半端でも実装してみると、学びは多かったので、コードファーストで学んでいくスタイルは効率が良さそうに思えた。
もうちょいプロトコルに対する理解や、Golangの抽象化レイヤーへの理解を深めていって、いい感じに書けるようにしていきたい。

PyCon Kyushu 2018 Fukuokaの実行委員をした

2018年6月30日に開催されたPyCon Kyushu 2018 Fukuokaの実行委員をしました。

pycon-kyushu.connpass.com

やったこと

実行委員は主に以下の4つの役割に別れて運営を行いました。

  • 事務局
  • 企画
  • 会場
  • 広報

私はこの中でも会場の担当で、会場のレイアウトを考えたり、当日の設営・撤収の流れを考えたりしました。

参加のきっかけ

私はもともと初めてのエンジニアとしての仕事がPython案件で、非常にPythonには愛着があります。その当時の同僚とPyFukuokaという小さなコミュニティを運営しており、そのコミュニティ活動が今回実行委員をやるきっかけとなりました。
PyFukuokaというコミュニティを始めたきっかけは自分自身のアウトプットの場が欲しいとかそんなんだった気がしますが、コミュニティをやる中で結果としていろんな方々と繋がりができて、今回もこのような素晴らしい機会もいただけたため、改めてコミュニティ活動の大事さを実感しました。

反省点

今回のイベント運営を通して大きな反省点があります。それは私自身「Pythonを多くの方に知ってもらいたい」とか「Pythonをもっと普及したい」といった信念がないままに実行委員として参加したことです。
私はPythonという言語が大好きです。でも、それを広めたいといった気持ちは強くありません。それはおそらく人がどうこう言ってる場合じゃなく、自分が技術・知識をつけることにいっぱいいっぱいだからだと思います。 そういった強い信念がないまま実行委員をした場合、自然な思考回路として、「なるべく時間を割きたくない」という風になってしまいます。
これは本来の実行委員のあるべき姿ではないと思うので、もし次やる機会があれば、強い信念を持って取り組みたい。(持てないならやらない)

まぁ何はともあれ、イベントは大成功!?したのでよかった。
来年は夏に沖縄開催が決定している!!有給取ってバカンスがてらオーディエンスとして参加したい!!

f:id:hirotsuru314:20180702224554j:plain

Site Reliability Engineering – 10章 時系列データからの実践的なアラート

こんにちは、つるべーです。
先日、福岡のインフラ界隈のエンジニアの方々がやっているSRE本の輪読会に参加し、発表をさせていただいたので、その時の内容をまとめます。
私は、10章の「時系列データからの実践的なアラート」を担当させてもらいました。

はじめに

なぜ「時系列データからの実践的なアラート」が必要かを考えてみた。
Webサービスの大規模化や複雑化に伴い、サーバ台数の増加やシステム構成の複雑化が進んだことで、サーバのメトリクス等の情報を高解像度かつ長期間保持したいという要望が高まっている。また、サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいといったシーンも増え、時系列データベースに溜め込んだデータを用いた柔軟なアラーティングの需要が高まっているのではないだろうか。

概要

  • 10章ではBorgmonと呼ばれるGoogleの内部システムについての話が中心だが、「アラートを発するためのデータソースとして時系列データを扱う」という発想は、汎用性が高く、最近ではPrometheus、Riemann、Heka、BosunといったOSSのツールを通じて広く受け入れられている。
  • 大規模なシステムにおいて如何にメンテナンスコストを抑えながら、適切なモニタリングを行うかが重要である。
  • 大量の時系列データを継続的に収集することで、アラーティングの精度・柔軟性を高めることができる。

まとめノート

大規模システムのモニタリングが難しい理由

  • 単にモニタリング対象となるコンポーネントの数が多すぎる。
  • システムに対する責任を負うエンジニアのメンテナンスの負荷を低く保つ必要がある。

大規模システムの場合、1台のマシンが不具合を起こしているくらいでアラートを発するのはノイジー過ぎる。(きちんと冗長化されている場合の話だが)
大規模システムでは、個々のコンポーネントの管理を求めるのではなく、データを適切な粒度で集約して、異常値のみを拾い上げるべきである。
また、必要に応じて個々のコンポーネントの調査もできる粒度に情報を保っておいてくれるようなモニタリングシステムが求められる。

10.1 Borgmonの誕生

  • 大量の収集を行うためにメトリックスのフォーマットは標準化されている必要がある。
  • 単一のターゲットに対する全てのメトリクスの収集を1回のHTTPのフェッチで行えるように定められている。 /varzエンドポイントを叩くとメトリクスが取得できる。
$ curl http://webserver:80/varz
http_requests 37
errors_total 12

10.2 アプリケーションのインスツルメンテーション

  • 全てのエクスポートされた変数をkey/value式のプレーンテキストで返す
  • スキーマレスなテキストベースのインタフェースは、新しいメトリクスを追加するのが簡単である
  • ひとつの変数に対して複数のラベルをつけて出力できるようになった。 例えば、HTTP200のレスポンスが25件、500のレスポンスが12件の場合、下のように出力される。
http_responses map:code 200:25 404:0 500:12

10.3 エクスポートされたデータの収集

  • Borgmonでは、サービスディスカバリを利用してモニタリング対象のリストを動的に生成するため、リストのメンテナンスコストが下がり、モニタリングのスケーラビリティを高めることができている。
    サービスディスカバリを有する点はPrometheusも同じ。PrometheusにはAWS、Azure、GCP、OpenStack、Kubernetesなど多種多様なプラットフォームのメタデータを元にサービスディスカバリすることができるし、Consulとの連携もできる。
  • Borgmonは一定間隔ごとにターゲットのエンドポイント(/varz)を叩いて、結果をメモリに貯める。(Pull型の監視)
  • データの収集をHTTP経由で行っているのは、HTTPのオーバーヘッドが問題になるケースはほとんどないことや、そもそもメトリクスが取れないことそのものを シグナルとして利用することができるからである。

10.4 時系列のアリーナにおけるストレージ

  • データポイントは(timestamp, value)という形式を持ち、 時系列データ と呼ばれる時間順のリストとして保存される。
  • それぞれの時系列データはname=valueという形式で、ユニークなラベルが付与される。 時系列データの概念は、時間と共に進んでいく数値からなる1次元の行列(列ベクトル)であり、変数に対して複数のラベルの組み合わせを追加すると、多次元の行列になる。
  • Borgmonは全てのデータをインメモリデータベースに保存し、定期的にチェックポイントを実行して、時系列データベース(Time-Series Database: TSDB)にアーカイブされる。 Borgmonでは、TSDBに対してもクエリを実行できる。TSDBはインメモリデータベースより低速だが、低コストで大容量である。

時系列データとは(補足)

時系列データとは、時間の推移ととともに観測されるデータのこと。世の中の実務の現場に貯まっていく多くのデータは時系列のデータである。
ITインフラの現場においても、サーバのメトリクス、ネットワークトラフィックなどといった時系列データが時々刻々と蓄積されている。
データ分析において、隣り合う時刻の観測値同士には明らかに相関関係がある(時間依存性を持つ)時系列データの取り扱いは、他のデータ(クロスセクションデータなどと言われる)に比べて、理論的にも実銭的にも難しいとされている。

時系列データベースとは(補足)

時系列データの保存・処理に特化したデータベースである。
Webサービスの大規模化に伴うサーバ台数の増加や、複雑化により、高い解像度の様々なメトリクスを長期間保持したいという要望や、サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいという要望などがあり、時系列データベースの需要が高まっている背景がある。

もちろん、時系列データを格納するためにバックエンドとして、MySQLのようなRDBMSを使用することもできるし、RRD(ラウンドロビンデータベース)のような時系列データに特化したデータベースもある。しかし、最近の時系列データベースでは共通して、時系列データの符号化方式や、メモリもしくはストレージの使用法などのアーキテクチャに工夫がなされており、 ストレージ容量の節約や、解析時に使用するメモリ量の削減などの効果を上げることができる。 また、ほとんどの時系列データベースにおいて、SQL等をベースにしたデータ解析の方法が用意されているという特色もある。

【参考】

階層型のデータストアアーキテクチャについて(補足)

データの保持期間に応じた階層型のデータストアアーキテクチャは、時系列データの保存においてはいくつか事例も見受けられる。

【参考】

10.4.1 ラベルとベクタ

  • 時系列データの名前はラベルセットである。ひとつの時系列データをユニークに探すためには、最低でも次のラベルが必須である。
var    :変数名
job    :モニタリング対象のサーバー の種類
service:サービスを提供するジョブの集合
zone   :データを収集したBorgmonのデータセンタ

これらをまとめて、以下のように変数式として表現できる。

{var=http_requests,job=webserver,instance=host0:80,service=web,zone=us-west}
  • 時系列データに対するクエリでは、これらのラベルセットに対して検索を行うと、マッチする全ての時系列データが返される。

10.5 ルールの評価

  • Borgmonルールと呼ばれるBorgmonのプログラムコードは時系列データから別の時系列データを算出する。
  • ルールの書き方自体は特に重要でない。 ポイントは、「10分間におけるHTTPエラーの比率」といったように、適度な幅で集計をしている点である。(さらにその幅は自由に調整できる)これは時系列にデータを溜め込んでいるからできる。

10.6 アラート

  • 「10分間のエラー率が1%以上で、1秒に1回以上のエラーが 2分以上出るときにアラートをあげる」といったことができるのも時系列データを溜めているからできる。

10.7 モニタリングのトポロジーのシャーディング

  • Borgmonは他のBorgmonから時系列データをインポートできる。そのため、データセンターごとにBorgmonで監視対象の時系列データを取得して、グローバルなBorgmonが各データセンターのBorgmonから時系列データを取得するといったシステム構成が組める。

10.8 ブラックボックスモニタリング

  • Borgmonはホワイトボックスモニタリングであり、調べるのはターゲットのサービス内部の状態のみである。したがって、ブラックボックスモニタリングも組み合わせないと、ユーザーにインパクトのある障害に気づけなくなる場合がある。

10.9 設定のメンテナンス

  • Borgmonではルールの定義をモニタリングの対象となるターゲットから分離しているため、同じルールセットを多くのターゲットに対して一斉に適用できる。これによりモニタリングのメンテナンスコストが大幅に削減できる。

10.10 10年が経過して

  • Borgmonは「アラートの診断のための大量の変数の収集と時系列データに対する集中化されたルールの評価」というモデルである。
  • メンテナンスコストがサービスのサイズに比例しないようにすることがモニタリングをメンテナンス可能にするための鍵である。

最後に…インフラ監視 × データサイエンス

  • Prometheusなどの時系列データベースや次世代監視ツールの発展と人工知能などデータサイエンス分野の発展が相まって、
    サーバの異常状態を予測して自動で制御するような時代が来るかもしれないなどと考えている。
    そのためにも、まずデータを高解像度・長期間溜め込むことは重要だ。さらに、溜め込んだデータを単なる閾値ベースの判定だけでなく、統計学機械学習を駆使したより高度なデータ分析を適用することで、アラーティングの柔軟性を高め、必要なアラートだけを発するようにする。自動制御はその先の世界…

参考

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

インフラエンジニアになって覚えたLinuxコマンド その2(ネットワーク系コマンド編)

こんにちは、つるべーです。
今回の記事は以前の続きで、インフラ業務の中で覚えたLinuxコマンドについてです。

blog.tsurubee.tech

今回はネットワーク系のコマンドに絞ってまとめていきます。

環境

目次

ping

ICMPを使ってネットワーク上のホストの接続を確認する

$ ping www.example.com
PING www.example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=63 time=123 ms
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=2 ttl=63 time=123 ms
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=3 ttl=63 time=123 ms
^C
--- www.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 123.096/123.361/123.551/0.345 ms

dig

DNSサーバに問い合わせてドメイン名(またはIPアドレス)を調べる。

dig [@DNSサーバ] ドメイン [検索タイプ]

DNSサーバは指定しない場合は、/etc/resolv.confに記述されたDNSサーバを使用する。
検索タイプはデフォルトではAレコード
-x AAA.BBB.CCC.DDDで逆引き問い合わせもできる。

$ dig google.com

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50236
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     279 IN  A   216.58.197.174

;; Query time: 28 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Fri May 04 23:08:38 JST 2018
;; MSG SIZE  rcvd: 55

+shortオプションをつけると目的の情報だけを表示する

$ dig +short -x 216.58.197.174
nrt12s02-in-f174.1e100.net.
nrt12s02-in-f14.1e100.net.

whois

whoisを利用してドメイン情報を取得する

$ whois gihyo.jp
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.jprs.jp

domain:       JP

organisation: Japan Registry Services Co., Ltd.
address:      Chiyoda First Bldg. East 13F,
address:      3-8-1 Nishi-Kanda
address:      Chiyoda-ku Tokyo 101-0065
address:      Japan

(省略)

tcpdump

ネットワークインターフェイスを通過するパケットを観察する。
tcpdumpと打つだけでもパケットが流れる様子が観察できるが、大量に流れてくるため通常は以下のように条件を絞って観察する。

tcpdump -i [interface name] port [port number]

実際の実行例は下のような感じ。

$ tcpdump -i eth1 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
02:09:24.936395 IP 192.168.10.1.50796 > nginx.http: Flags [F.], seq 2273804563, ack 848006729, win 4117, options [nop,nop,TS val 715484926 ecr 28938], length 0
02:09:24.936422 IP 192.168.10.1.50797 > nginx.http: Flags [F.], seq 1504651190, ack 642584441, win 4117, options [nop,nop,TS val 715484926 ecr 28938], length 0
02:09:24.936425 IP 192.168.10.1.50798 > nginx.http: Flags [F.], seq 2028803151, ack 3632381970, win 4117, options [nop,nop,TS val 715484926 ecr 28938], length 0
02:09:24.936428 IP 192.168.10.1.50799 > nginx.http: Flags [SEW], seq 3820785142, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 715484926 ecr 0,sackOK,eol], length 0
02:09:24.936447 IP nginx.http > 192.168.10.1.50799: Flags [S.E], seq 2665692678, ack 3820785143, win 28960, options [mss 1460,sackOK,TS val 43425 ecr 715484926,nop,wscale 6], length 0

(省略)

これを見るだけでもパケット届いてるなーとかまではわかるが、出力結果をちゃんと見るには下の記事がすごく参考になった。

qiita.com

-w ファイル名でファイル出力もでき、出力したファイルをWiresharkで見ると良さそう。

ip

ipコマンドは様々なネットワーク関連の設定を確認/変更できるコマンドである。
CentOS7では、ifconfig、route、netstatなどといったコマンドが入っているnet-toolsパッケージが廃止予定であり、iproute2パッケージに含まれる「ip」「ss」などのコマンドを使用することが推奨されているようです。これについては以下の記事に非常にわかりやすくまとめられています。

enakai00.hatenablog.com

ネットワークデバイスの設定を確認

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:5f:94:78 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 83407sec preferred_lft 83407sec
    inet6 fe80::5054:ff:fe5f:9478/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:2e:38:d9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.11/24 brd 192.168.10.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe2e:38d9/64 scope link
       valid_lft forever preferred_lft forever

aaddrの略。ifconfigコマンドに相当するコマンド。

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::5054:ff:fe5f:9478  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:5f:94:78  txqueuelen 1000  (Ethernet)
        RX packets 32746  bytes 17741551 (16.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 22008  bytes 2394181 (2.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.11  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::a00:27ff:fe2e:38d9  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:2e:38:d9  txqueuelen 1000  (Ethernet)
        RX packets 161  bytes 26250 (25.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 3146 (3.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ルーティングの確認

$ ip r
default via 10.0.2.2 dev eth0 proto static metric 100
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.11 metric 100

rrouteの略。routeコマンドに相当するコマンド。

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     100    0        0 eth1

-nオプション:ホストの名前解決をせずにIPアドレスを表示

上で表示したネットワークデバイスやルーティングの設定は、adddelなどを使って設定情報を追加、削除できる。

ss

ソケットの状態を表示する。

$ ss -tan
State      Recv-Q Send-Q                                            Local Address:Port                                                           Peer Address:Port
LISTEN     0      128                                                           *:111                                                                       *:*
LISTEN     0      128                                                           *:80                                                                        *:*
LISTEN     0      128                                                           *:22                                                                        *:*
LISTEN     0      100                                                   127.0.0.1:25                                                                        *:*
ESTAB      0      0                                                     10.0.2.15:22                                                                 10.0.2.2:50759
LISTEN     0      128                                                          :::111                                                                      :::*
LISTEN     0      128                                                          :::22                                                                       :::*
LISTEN     0      100                                                         ::1:25                                                                       :::*

-tオプション:TCPソケットを表示
-aオプション:接続待ち(LISTEN)も含めて表示
-nオプション:ポート番号を表示(デフォルトではサービス名)
ssコマンドはnetstatコマンドに相当するコマンド。

$ netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
tcp        0      0 10.0.2.15:22            10.0.2.2:50759          ESTABLISHED
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 ::1:25                  :::*                    LISTEN

参考

[改訂第3版]Linuxコマンドポケットリファレンス

[改訂第3版]Linuxコマンドポケットリファレンス