2017-03-24

Terraform 0.9がリリース。0.8.xから0.9.xのStateマイグレーション手順をまとめました。

Terraform

HashiCorpからTerraform 0.9がリリースされました。「よし、最新バージョンにあげよう。」と作業をはじめましたがremoteコマンドが使えない。どうやら0.9からはremoteコマンドが廃止されたようです。このエントリではTerraform 0.9にバージョンアップをして0.8以前のterraform stateをマイグレーションする方法をまとめます。

remoteコマンドの廃止

remoteコマンドが廃止になりました。代わりにbackendsを利用してS3などのremoteにあるtfstateファイルの管理を行います。

remote stateがbackendsに置き換わる過程は次のPull Requestから確認できます。 github.com

0.8以前を利用している場合はbackendを有効にしたtfstateファイルを用意する必要があります。次からは0.8.xまでのリソース状態を保持したまま新機能のbackendを有効にしたtfstateファイルへのマイグレーション手順についてまとめていきます。

マイグレーション手順

次の環境のマイグレーション手順になります。

0.8.8から0.9.1へのバージョンアップする
これまではremoteにS3をつかっていて、これからもS3を利用する
ロールバックできるように、これまでのtfstateファイルは保持して新しいtfstateファイルを用意する
0.8.8と0.9.1のterraformを使うのでtfenvを使ってterraformを切り替えながらマイグレーションを行う

１：tfファイルに`terraform`セクションを追加して`backends` を設定する

次のように設定しました。

terraform {
  backend "s3" {
    bucket = "tfstate-bucket" // 自身のbucket名を設定します
  }
}

AWSのaccess_key, secret_key, regionはそれぞれ環境変数のAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGIONを設定しているため省略しています。
S3のkeyは必須ですが省略しています。後述するinitコマンドの-backend-config オプションで開発環境や本番環境ごとにS3のkeyを分けているためterraformセクションでは省略します。

※ その他bucketなどのS3の変数はこちらにまとまっています。

２：0.8.8のterraformをつかい`remote config`をしてtfstateファイルをローカルに同期する

tfenvでインストールしたバージョンリスト

terraform/dev ➤ tfenv list
0.9.1
0.8.8

0.8.8を使いremote configする

terraform/dev ➤ tfenv use 0.8.8
Terraform v0.8.8

terraform/dev ➤ terraform remote config -backend=S3 -backend-config="bucket=tfstate-bucket" -backend-config="key=dev"
Initialized blank state with remote state enabled!
Remote state configured and pulled.

S3のkeyは開発環境のdevとしています

３：0.9.1のterraformをつかい`init`をしてtfstateファイルをマイグレーションする

terraform/dev ➤ tfenv use 0.9.1
Terraform v0.9.1

terraform/dev ➤ terraform init -backend-config "key=dev"
Initializing the backend...
New backend configuration detected with legacy remote state!
・・・省略・・・

最初のaskでremote stateから変更するか？と聞かれるので yesを入力します。これをすることでtfstateファイル内のremoteがbackendに置き換わります。
次のaskでremoteのstateをローカルのstateにコピーする？と聞かれるのでローカルのstateを保持したければnoを入力、コピーするのであればyesを入力します。すでにローカルにstateがあるのでnoと入力。

４：マイグレーションしたtfstateファイルをS3にアップロードする

マイグレーション後に0.8.8にロールバックするかもしれないので、0.8.8で運用したtfstateファイルを残したいです。そのため新しいS3のkeyをdev0.9と決めマイグレーションしたtfstateファイルをS3にアップロードします。

terraform/dev ➤ aws s3 cp ./.terraform/terraform.tfstate s3://tfstate-bucket/dev0.9

こうすることで開発中のtfstateファイルに影響が及ぶことはなくマイグレーションのロールバックができる状態にします。

４：最後に`plan`を実行して新しいtfstateファイルにリソースの差分がないか確認する

terraform/dev ➤ rm -rf ./.terraform

terraform/dev ➤ tfenv use 0.9.1
Terraform v0.9.1

terraform/dev ➤ terraform init -backend-config "key=dev0.9"
Initializing the backend...
・・・省略・・・

terraform/dev ➤ terraform plan --refresh=false
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.

0.9.1からはremote configを使わずinitを使いtfstateファイルをローカルに同期します

まとめ

0.9.1へtfstateファイルのマイグレーション手順をまとめました。
0.8.xまではremote configを利用していましたが、0.9.1からはinitを利用します。
backendではtfstateのリソース情報がメモリ上に管理されます。0.8.xまではリソース状態がtfstateファイルを開けば確認できましたがbackendでは確認できません。リソース状態の管理がセキュアになりました。
backendはSTATE LOCKINGを機能が有効になります。複数人でapplyを実行した場合にstateをロックし競合を防ぎます。CIなどでapplyが同時に稼働しても安心です。
もし0.7.xからのマイグレーションの場合はリソース状態に差分が生まれているのでリソース状態を0.8系に合わせる必要があります。

参考URL

2017-03-17

gRPC streamingをつかうとマイクロサービスの責務が整理できるし省コネクションでメリットあるよね、という話

gRPC Go Java

今回はgRPCをマイクロサービス間通信に導入することってメリットあるよね、というエントリです。定期的に処理を実行してくれるバッチはよくあるものですがバッチの駆動をgRPCを使って次のような構成で動かしました。

f:id:n_soushi:20170317102154j:plain

Batch ControlとBatch ServerはBidirectional gRPC streamingでコネクションする。
Batch ControlはRedisのPub/Subで特定のチャンネルを監視する。
Batch Controlはチャンネルにキューが投げられたらBatch Serverへバッチ処理スタートのリクエストを送る。
Batch Serviceはリクエストを受け取りバッチを動かし処理結果をBatch Controlに送る（レスポンスを送る）。
チャンネルにキューが投げられる度に上記の流れでバッチを稼働させる。

上記の構成を踏まえ次からはメリットをまとめます。

gRPCをマイクロサービスに導入するとメリットあるよね

キューのRead権限をバッチサーバから剥がせる

キュー駆動でバッチを動かしている場合、例えばAmazon SQSを導入しているとRead権限が必要です。上記の構成であればキューを監視するのはバッチサーバではなくコントロールサーバになります。そのためキューを監視する権限をコントロールサーバに集約できるメリットがあります。

ログ集約サーバへの送信責務もバッチサーバから剥がせる

図のとおりgRPCのBidirectional streamingを使えば複数のレスポンスを送信することができます。バッチ処理結果や各種ログはコントロールサーバへ送り、ログ集約サーバへの送信はコントロールサーバが行います。gRPCで各サービスをつないでおいてログを送り、受けとったクライアントにログの集約を任せる、といった構成は導入メリットの１つな気がします。（ログの送信漏れ考慮は必要ですが）

そもそものgRPCのメリット

そもそものgRPCのメリットがあります。異なる言語のマイクロサービス間の通信でもProtocol Buffersを定義することで容易に通信を確立できますし、streamingの方式を用途に合わせて選択することで省コネクションでマイクロサービス間のやり取りが行えます。

GoとJavaでBidirectional gRPC streamingをつかったデモ

上記の図の構成をもとにgRPCのクライアントをGoでサーバをJavaで通信方式はBidirectional streamingを採用してデモを作ってみました。

どのようなバッチサービス？

Bidirectional streamingを採用しているので、リクエストが複数あってレスポンスも複数、または１つのようなサービスを考えました。

結果、数値を受け取り割り算をして商と余りを返すサービスを実装しました。

Redisからキューを送信してクライアントがリクエストとレスポンスを受け取ったイメージです。

# Redis
$ redis-cli
127.0.0.1:6379> PUBLISH my_queue '{"serviceName" : "division", "numbers" : [10, 3]}'

# Client
12:27:50.452 Request : {serviceName:'division', message:'10', time:'time string'}
12:27:50.452 Request : {serviceName:'division', message:'3', time:'time string'}
12:27:50.455 Response: {serviceName:'division', message:'quotient:3', time:'time string'}
12:27:50.456 Response: {serviceName:'division', message:'remainder:1', time:'time string'}

クライアントは10と3のリクエストを２つ送り、商が3と余りが1の結果を受け取ります。（余りが0であればレスポンスは１つになる）

protoファイル

protoファイルは次のようになりました。

syntax = "proto3";

option go_package = "protobuf";
package proto;

service MicroService {
  rpc MicroService (stream Request) returns (stream Response) {}
}

message Request {
  string name = 1;
  string message = 2;
  string time = 3;
}

message Response {
  string name = 1;
  string message = 2;
  string time = 3;
}

クライアントのコード（Go）

リクエストを送信してレスポンスを受け取っている通信周りのコードの抜粋です。

※コード全体はgithubにあります。

waitc := make(chan struct{})
go func() {
    for {
        in, err := stream.Recv()
        if err == io.EOF {
            close(waitc)
            return
        }
        if err != nil {
            log.Error("Failed to receive a message : %v", err)
            return
        }
        responseLog.Info("{serviceName:'%s', message:'%s', time:'%s'}", in.Name, in.Message, in.Time)
    }
}()

for {
    message, err := pubSub.ReceiveMessage()
    if err != nil {
        panic(err)
    }
    requests, err := getRequests(message)
    if err != nil {
        panic(err)
    }

    for _, request := range requests {

        requestLog.Info("{serviceName:'%s', message:'%s', time:'%s'}", request.Name, request.Message, request.Time)
        if err := stream.Send(&request); err != nil {
            log.Error("Failed to send a message: %v", err)
        }
    }
}

stream.CloseSend()
<-waitc

サーバのコード（Java）

リクエストを受け取りレスポンスを送信している通信周りのコードの抜粋です。

割り算をする数値が分けられて送られてきます。１回目のリクエストでキーを生成してリクエストを保持しながら２回目のリクエストで割った結果を送信しています。

※コード全体はgithubにあります。

return new StreamObserver<Microservice.Request>() {
    public void onNext(Microservice.Request req) {
        Long key = getTime(req);
        Observable.just(req)
                .subscribe(new Observer<Microservice.Request>() {

                    @Override
                    public void onSubscribe(Disposable d) {
                        Log.i("Request", getRequestLog(req));
                    }

                    @Override
                    public void onNext(Microservice.Request request) {
                        if (!routeNumber.containsKey(key)) {
                            routeNumber.put(key, Arrays.asList(req));
                        } else if (routeNumber.get(key).size() == 1) {

                            Microservice.Request prevRequest = routeNumber.get(key).get(0);
                            Integer leftTerm = Integer.parseInt(prevRequest.getMessage());
                            Integer rightTerm = Integer.parseInt(req.getMessage());

                            Integer quotient = leftTerm / rightTerm;
                            Integer remainder = leftTerm % rightTerm;

                            if (remainder == 0) {
                                responses.putIfAbsent(key, Arrays.asList(
                                        getResponse(req.getName(), String.format("quotient:%d", quotient))));
                            } else {
                                responses.putIfAbsent(key, Arrays.asList(
                                        getResponse(req.getName(), String.format("quotient:%d", quotient)),
                                        getResponse(req.getName(), String.format("remainder:%d", remainder))));
                            }
                        } else {
                            Log.w(String.format("waring, unknown state. key:{%s}, value:{%s}", key, routeNumber.get(key)));
                        }
                    }

                    @Override
                    public void onError(Throwable e) {
                        Log.e(String.format("onError %s", e.getMessage()));
                    }

                    @Override
                    public void onComplete() {
                        if (responses.containsKey(key)) {
                            Observable.fromIterable(responses.get(key))
                                    .subscribe(res -> {
                                        responseObserver.onNext(res);
                                        Log.i("Response", getResponseLog(res));
                                    });
                            routeNumber.remove(key);
                            responses.remove(key);
                        }
                    }
                });
    }

    public void onError(Throwable t) {
        logger.log(Level.WARNING, "microService cancelled");
    }

    public void onCompleted() {
        responseObserver.onCompleted();
    }
};

デモ

f:id:n_soushi:20170317114216g:plain

まとめ

Bidirectional streamingは１回のコネクションでクライアントとサーバ間で複数回のリクエストとレスポンスを送ることができます。リクエスト／レスポンスの度にコネクションを確率しないので省コネクションのメリットがあります。
クライアントはgRPCのコネクションを確立してからチャンネルのsubscribeを継続して行っています。キューが送られる度にgRCPのコネクションを繋いでいません。１回のgRCPコネクションを確立するだけでバッチサーバのコントロールが行うことができました。
gRPCで考えてみましたがHTTP／API／JSONの通信形式であっても権限や責務を１つのサーバに集約させるメリットは受けられます。何よりProtocol Buffers定義による複数言語のサポートとstreaming方式の便利さが運用しているマイクロサービスに嵌まれば導入機会を検討するべきです。引き続きgRPCのメリットを受けられるようなユースケースを考えていきます。

コードを公開しています

コード全体はgitbubで確認できます。

github.com

2017-03-10

CourseraのMachine Learningから線形回帰を学んだのでまとめてみた

機械学習線形回帰 Coursera

CourseraのMachine Learningを受講しています。時間を見つけてはコツコツ進めて今のところWeek4に差し掛かったところです。Week4ではNeural Networksの話に入り一段とレベルが高くなった印象を受けています。Week1からWeek3までに学んだことを復習する必要があるなと焦りが生まれました。

受講中は配布される資料や動画を見たり他の日本人の方のブログを拝見したりと課題に取り組んできました。このタイミングで復習して整理することでWeek4以降の学習が快適になるのではないかと淡い期待を込めてWeek1からまとめてみます。

Machine Learning - Stanford University | Coursera

こちらが受講しているMachine Learningのコースです。MOOCは好きな時間に進められるし前編英語（動画は日本語字幕あり）なので英語の学習になってオススメです。

www.coursera.org

どこまでの内容をまとめるか

このエントリではWeek1の内容に触れています。

線形回帰とは？

ある土地の家の価格とその家の部屋数の相関をグラフで表すと以下のようになったとします。

f:id:n_soushi:20170310101210p:plain

Xが部屋数（RM）でYが価格（MEDV）です。

（出典：Housing Data Set）

※ このデータは部屋数以外に、その土地の犯罪率だったり児童と教師の比率など複数の要素から構成されています。

部屋数が4つの場合や部屋数が7つの場合はグラフから予想できそうです。このとき頭の中ではグラフに右肩上がりな直線をイメージして予想できますが、この直線を数式から導き出すことを学びました。この導き方は統計学では回帰分析の一種として線形回帰と呼ばれています。

仮定関数と目的関数

部屋数をX、部屋の価格をYとすると相関を表すグラフを引くための1次関数の式は次のようになります。（懐かしい数式）

$\displaystyle Y = aX + b$

Machine Learningのコースではθをつかって次のような式で定義しています。

$\displaystyle h_\theta (X) = \theta_0 + \theta_1(X)$

$h_\theta (X)$ は仮定関数と呼ばれます。家の価格予想に最適な直線を引くために $\theta_0$ と $\theta_1$ の数値を変えながらグラフにフィットした仮定関数を導き出します。つまり右肩上がりの直線のグラフを引くために最適な $aX + b$ の aとbを決めるということですね。

仮定関数がフィットしているか計算するための関数である目的関数があります。

${ \displaystyle J(\theta_0, \theta_1) = \frac{1}{2m}\sum_{i=1}^{m} (h_\theta (X_i) - Y_i)^2 }$

この目的関数をつかって $J(\theta_0, \theta_1)$ を最小にする $\theta_0$ と $\theta_1$ を導き出します。

最急降下法

目的関数を最小にする方法に最急降下法があります。

${ \displaystyle \theta_j = \theta_j - \alpha \sum_{i=1}^{m} (h_\theta (x^{(i)}) - y^{(i)}) x_j\ ^{(i)} }$

ここで微分が出てきます。微分は傾きを求めますがこのアルゴリズムを使い傾きが最小になるまで学習を繰り返していきます。傾きの値が最小になるほどグラフにフィットした $\theta_j$ が求められます。 $\alpha$ は学習率と呼ばれ数値が大きいほど傾きの変動幅が大きくなりフィットしたデータが得られず、小さいほど学習はゆっくりと進み確実にデータにフィットした値が求められます。

Octaveでプログラム化する

コースの課題ではOctaveを使いプログラミング課題を提出します。最初に示した家の価格と部屋数のグラフのデータを使い、更にこれまでのアルゴリズムからデータにフィットした直線をグラフにプロットしてみます。

目的関数

function J = computeCost(X, y, theta)
    m = length(y);
    J = sum((X*theta -y).^2) / (2* m);
end

最急降下法

function [theta, J_history] = gradientDescent(X, y, theta, alpha, num_iters)
    m = length(y);
    J_history = zeros(num_iters, 1);

    for iter = 1:num_iters
        theta = theta - alpha / m * X' * (X * theta -y);
        J_history(iter) = computeCost(X, y, theta);
    end
end

目的関数を求めグラフにプロットする。そして部屋数が5つのときの価格を予想する。

%% Initialization
clear ; close all; clc
data = load("housing.txt");
x = data(:, 6);
y = data(:, 14);
m = length(y);

theta = zeros(2, 1);
X = [ones(m, 1), x]

%% Compute Cost
J = computeCost(X, y, theta)

%% Gradient Descent
iterations = 1500;
alpha = 0.01;
[theta J_history] = gradientDescent(X, y, theta, alpha, iterations);

%% Output
fprintf('Initial cost = %f\n', J);
fprintf('Final cost = %f\n', J_history(iterations));
fprintf('Theta found by gradient descent: ');
fprintf('%f %f \n', theta(1), theta(2));

%% Plot data
figure; hold on;
plot(x, y, 'r+', 'LineWidth', 2);
plot(X(:,2), X*theta, '-')
xlabel('RM');
ylabel('MEDV');

%% Predict
fprintf('for RM = 5, MEDV = %f\n', [1, 5] *theta);

出力したグラフ

f:id:n_soushi:20170310115327p:plain

データにフィットした直線がプロットできたようです。

出力した数値

J =  296.07
initial cost 296.073458
final cost 27.131052
Theta found by gradient descent: -5.254087 4.477681
for RM = 5, MEDV = 17.134317

部屋数が５つのときに 17.134317と予想できました。グラフにプロットされたデータとフィットされているようです。

まとめ

最後に出したグラフですが、もう少し角度が急な直線のほうがグラフにフィットしているようです。プロットして上手く行かなければ調整して再度プロットして、の繰り返しが機械学習の大事な工程なのでしょう。
線形回帰はこの先で学ぶ機械学習の知識のベースになっています。データを分類する場合などに流用できます。
今回の学習データは部屋数の１つでしたが部屋数に加え犯罪率、児童と教師の比率などの複数の要素からも線形回帰をベースに家の価格を予想できる。（重回帰分析）この内容はWeek2で学びました。
MOOCで学び、コースを修了した先輩たちのブログで学び、自分のブログでアウトプットする、など多角的に学ぶことが大事。（ここに書籍を読んで学ぶも入れたい:money_with_wings: ）
数式書くの大変。