TDDトリプロをやってみた話

この記事はJX通信社Advent Calendarの11日目です。

前回にアドベントカレンダーの4日目の記事を書いたJX通信社でNewsDigestというiOS版アプリの開発担当として参画してますmoaibleです。

弊社では月に一度開発メンバーを集めて勉強会を実施する時間が設けられています。

11月に勉強会の幹事を担当した際にTDDトリプロをやってみたところ、思ったより盛り上がったのでその紹介をしていきます。

そもそもTDDとは?

f:id:moapp:20181211182810p:plain
tdd cycle

「TDD = Test Driven Development = テスト駆動開発」のことですね。

色んな方が普及してる開発手法なのもあって名前を聞くことも少なくないと思いますが、改めて簡単にやり方を説明しますと、

  1. テストコードを書いて失敗する状態にする
  2. 1のテストコードを失敗から成功する状態にする
  3. 2のコードがテストが成功する状態を保ったまま整理する

これを上記図の内容を借りると、

レッド → グリーン → リファクタリング

これを繰り返しながら動作もするし品質が保たれたコードを組み立てていく、という開発手法になります。

この記事ではTDDのこのサイクルを利用してちょっとしたゲーム形式っぽくみんなでTDDをやってみた話をします。

TDDトリプロ

「TDDしながらトリオでプログラミングしてみた」をこの記事ではTDDトリプロと勝手に呼びます。

TDDトリプロでは、TDDのサイクルである

レッド → グリーン → リファクタリング

のレッドとグリーン・リファクタリングをフェーズで分けます。

つまり、

  1. レッドフェーズ
    • テストが失敗するテストコードを書く
  2. グリーン・リファクタリングフェーズ
    • レッドフェーズで書いたテストコードを成功させリファクタリングまで済ませる

ということですね

あと2フェーズだけだと3人いてもクルクル回るだけで終わるので単純作業感が出てしまいます

それが嫌だったので更に制約を設けて、

ロール 役割
ライター フェーズでコードを書く人
オペレーター フェーズでコードを書く人に指示を出す人
オブザーバー ただ二人を傍観するだけの人

というような3つのロールを回しながら3人で1つのPCを操作しながら進めていく、というルールにで実際にやってもらいました

f:id:moapp:20181211183222p:plain
tdd group torio

(実際にトリオでグループ毎に分かれた図)

ただ始めると問題になるのが、身についてるプログラミング言語だったりテストフレームワークだったりキーボードはJISなのか英字なのか...etcのように人によって違う部分って色々あると思います

そこで、緩和してくれるTDDに特化したwebサービスを今回は利用してみました

Cyber dojo

http://cyber-dojo.org/cyber-dojo.org

f:id:moapp:20181211183434p:plain

こちらがcyber-dojoと言われる、ブラウザ上でテストコード込みで実装を進められることができるサービスです、ひとまず開いたら「I'm on my own」から入場してみましょう

f:id:moapp:20181211183549p:plain

豊富に用意されている各種言語、テストフレームワーク、お題を選ぶことができます

今回の例ではひとまず「Python + pytest」の開発環境で 「FizzBuzz」のお題に挑戦してみます

実際にTDDでテストを回してみる

f:id:moapp:20181211183807p:plain

まずはデフォルトで用意されてる状態のままテストを実行してみたいので、「test」を押してみます

f:id:moapp:20181211183838p:plain

そうすると実際に実行されて・・・

f:id:moapp:20181211184729p:plain

無事失敗しましたね(?)これでレッドフェーズはクリアしました

次の人に交代して今度はグリーン・リファクタリングフェーズに入ります

失敗してるテストコードをみてみます

import hiker

def test_life_the_universe_and_everything():
    '''a simple example to start you off'''
    douglas = hiker.Hiker()
    assert douglas.answer() == 42

テストケースとして42であるべき、と求められていますが実装の方はというと

class Hiker:

    def answer(self):
        return 6 * 9

はい、「6 * 9 = 42」ではないので失敗することが分かりますね!

これを正しいコードに直して再度testを実行してみます

f:id:moapp:20181211183949p:plain

今度は通りましたね!🎊

この例だとリファクタリングできるほどコード量もないのでグリーン・リファクタリングフェーズはクリアになりました

じゃあ次にPCを操作する人がレッドフェーズとして失敗するテストコードを書いて...というのを繰り返す、というのがこの勉強会でやってみたTDDトリプロの全容になります

やってみて分かったこと

勉強会はいつも2時間ぐらい取ってるのですが最初のお題で出したFizzBuzzが終わったら違うお題に挑戦してみたり、言語を変えてもう一回やってみようっていうグループもあったりして誰かが退屈するってことがなく無事終わることができました

当たり前なんですが、みんな今まで過ごしてきた環境も違うし経験も違います

これって業務にも通ずる話で当たり前なのですが、持ってる物が違う中でみんなで協力して物事を解決まで進めるってことが体感できるって意味でも良い時間が生まれたのかな、って所感でした

f:id:moapp:20181211184253j:plain

おわりに

いかがでしたでしょうか

是非この記事を見て、もしやってみたいって思ったらTDDトリプロ気軽に試してみてください 😃

CNNを使った分類問題の判断根拠(画像編)

この記事は JX通信社Advent Calendar の 12 日目です。

FASTALERT チーム機械学習エンジニアの mapler です。FASTALERT の機械学習とサーバーサイドの開発をしています。

FASTALERT(ファストアラート)は、SNSから事件・事故・災害等の緊急情報を検知し、配信する緊急情報配信サービスです。その処理の中でも画像認識は欠かせない存在です。

今回お話しするのは CNN (Convolutional Neural Network,または畳み込みニューラルネットワーク) というニューラルネットのモデルです。CNN は行列の空間情報を捉えるため、特に画像認識分野では非常に有効な手法です。

convolution
from Performing Convolution Operations

CNN の解釈性

ニューラルネットワークはとても有効な一方、その根拠が解釈しにくいとよく言われています。FASTALERT でも、ニュースの価値を判別するアルゴリズムを改善するためにモデルの判定結果を解釈することは重要です。

CNN もしくは深層学習の解釈性について、icoxfog417さんディープラーニングの判断根拠を理解する手法 でたくさんの研究や手法が紹介されています。

今回は Grad-CAM という判定根拠の可視化方法について実験してみようと思います。

Grad-CAM の仕組み

p
from Introduction to Deep Learning: What Are Convolutional Neural Networks?

上の図に、入力画像の受容野(Receptive field)がいくつかの Convolution + ReLU + Pooling 層を通って、一次元ベクトルに Flatten される直前まで、位置が変わらないことがわかります。(左上の部分が複数の Convlution 層を通った後の出力でも左上にあります)

A number of previous works have asserted that deeper representations in a CNN capture higher-level visual constructs [5, 35]. Furthermore, convolutional features naturally retain spatial information which is lost in fully-connected layers, so we can expect the last convolutional layers to have the best compromise between high-level semantics and detailed spatial information.

from: Grad-CAM: Visual Explanations from Deep Networks via Gradient-based Localization

(拙訳)たくさんの研究によって、より深い層ではより高度、豊富な特徴が捉えられると示されています。しかし、Flatten によって、空間情報は分類の fully-connected 層で失われます。最後の CNN 層は分類特徴と空間情報を両方持つ、可視化に最も利用できる層になります。

Grad-CAM はこの最後の CNN 層の勾配を利用して、どのニューラルのどの部分が出力のどの分類に一番貢献したかを計算します。

CAM
CAM from Learning Deep Features for Discriminative Localization

上の図は CAM という Grad-CAM が登場する前の CNN 根拠可視化手法です。

CAM は Grad-CAM と異なり、勾配を利用するのではなく、CNN 層の後の Fully-Connected 層と一つの GAP(Global Average Pooling)に入れ替えています。この GAP は(豊富な特徴情報を持っている)最後の CNN の出力の特徴図(Feature Map)を Pooling して、分類のクラスとマッピングします(Class Activation Mapping)。

上の図で犬(Australian terrier)を示す w_2(赤い四角)と w_n(緑の四角)の特徴図の重みは w_1(青い四角)より強いのがわかります。(逆に人間を判定する場合、w_1 の重みは強くなるでしょう。)

f:id:maplerme:20181212104555p:plain
from: Learning Deep Features for Discriminative Localization
こうやって重み w を付けて特徴図の加重合計(Weighted Sum)の結果、できた図は Class Activation Map(CAM)となります。 一方、Grad-CAM は GAP 層の入れ替え不要で、逆伝播の時の勾配を利用して、特徴図の重みを実現しています。
f:id:maplerme:20181212104717p:plain
from: Grad-CAM: Visual Explanations from Deep Networks via Gradient-based Localization
上の式の \alpha^{c}_k は CNN の出力特徴図(Feature Map)A^{k} がクラス c に判定される確率の y^{c} に対する偏微分、もしくは勾配(gradient)となります。

ここの勾配はニューラルネットワークの逆伝播で計算され、特徴図 A^{k}_{ij} の中の i、j 位置のピクセルの変化に対し、クラス c に判定される確率の影響を表しています。そして、この勾配はちょうど CAM の重みと同じになることを論文の中でも証明しています。(Grad-CAM は汎用化した CAM だと論文の作者は言ってます。)

f:id:maplerme:20181212104824p:plain
from: Grad-CAM: Visual Explanations from Deep Networks via Gradient-based Localization
CAM と同様に、重みの α と特徴図の A を加重合計して、重みの代わりに勾配(Gradient)を使った CAM (すなわち Grad-CAM)ができます。ちなみに、クラス判定にマイナス影響をする部分を"非表示"にするため、活性化関数 ReLU をかけています。

grad-cam
Grad-CAM Flow from http://gradcam.cloudcv.org/

Grad-CAM を火災画像で試してみる

モデルの作成:

学習データ:

火災 の画像約5000枚。
火災ではない 画像同じ約5000枚。

モデル:

f:id:maplerme:20181212105046p:plain
ResNet34 from https://arxiv.org/abs/1512.03385 (rotated)

ResNet34 の ImageNet の Pre-Train モデルを利用して、三番目のブロックから再学習します。最初の出力層は二項分類にします。

(学習バッチは PyTorch で実装していますが、省略させていただきます。)

評価

学習結果は以下になります

>> print(metrics.classification_report(gts, predict_labels))
(threshold = 0.5)
              precision    recall  f1-score   support

       False       0.78      0.57      0.66      5605
        True       0.66      0.84      0.74      5605

Confusion Matrix: f:id:maplerme:20181212105332p:plain

火災ではない画像が間違えて火災に判定されたことが結構多いです。True/False どっちも良い精度とは言えません。これから Grad-CAM でどこで間違えているのかを可視化してみましょう。

Grad-CAM を実装

PyTorch で実装となります。

class GradCAM:
    def __init__(self, model, feature_layer):
        self.model = model
        self.feature_layer = feature_layer
        self.model.eval()
        self.feature_grad = None
        self.feature_map = None
        self.hooks = []

        # 最終層逆伝播時の勾配を記録する
        def save_feature_grad(module, in_grad, out_grad):
            self.feature_grad = out_grad[0]
        self.hooks.append(self.feature_layer.register_backward_hook(save_feature_grad))

        # 最終層の出力 Feature Map を記録する
        def save_feature_map(module, inp, outp):
            self.feature_map = outp[0]
        self.hooks.append(self.feature_layer.register_forward_hook(save_feature_map))

    def forward(self, x):
        return self.model(x)

    def backward_on_target(self, output, target):
        self.model.zero_grad()
        one_hot_output = torch.zeros([1, output.size()[-1]])
        one_hot_output[0][target] = 1
        output.backward(gradient=one_hot_output, retain_graph=True)

    def clear_hook(self):
        for hook in self.hooks:
            hook.remove()

こちらは PyTorch の register_forward_hookregister_backward_hook メソッドで最終の CNN 層の出力(Feature Map)と逆伝播時の勾配(Gradient)を記録します。

画像を Grad-CAM に入れて可視化までの実装

まずはモデルをロードする。

image_model_path = "./fire.model"
image_model_save_point = torch.load(image_model_path)
image_model = models.resnet34(pretrained=False, num_classes=2)  # モデルを定義
image_model.load_state_dict(image_model_save_point['state_dict'])  # 保存したパラメータをモデルにロードする
image_model.eval()
id_to_label = {
    0: 'other',
    1: 'fire'
}

Grad-CAM class にモデルを代入するかたちになります。

grad_cam = GradCAM(model=image_model, feature_layer=list(image_model.layer4.modules())[-1])

PyTorch の ResNet モデルの layer4 は最後のブロックで、その最後の module (最終の CNN 層)を取得して、GradCAMの feature_layer に渡します。

画像を開いて前処理:

from PIL import Image
from torchvision.transforms.functional import to_pil_image

VISUALIZE_SIZE = (224, 224)  # 可視化する時に使うサイズ。PyTorch ResNet の Pre-Train モデルのデフォルト入力サイズを使います

normalize = transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225])

image_transform = transforms.Compose([
        transforms.Resize(VISUALIZE_SIZE),
        transforms.ToTensor(),
        normalize])

path = "./fire.jpg"
image = Image.open(path)
image.thumbnail(VISUALIZE_SIZE, Image.ANTIALIAS)
display(image)

# save image origin size
image_orig_size = image.size # (W, H)

img_tensor = image_transform(image)
img_tensor = img_tensor.unsqueeze(0)

画像を Grad-CAM に入れる

model_output = grad_cam.forward(img_tensor)
target = model_output.argmax(1).item()

予測された class を取得して、逆伝播にいれる

grad_cam.backward_on_target(model_output, target)

最終層の勾配と出力を取得して、hooks をクリア

import numpy as np
# Get feature gradient
feature_grad = grad_cam.feature_grad.data.numpy()[0]
# Get weights from gradient
weights = np.mean(feature_grad, axis=(1, 2))  # Take averages for each gradient
# Get features outputs
feature_map = grad_cam.feature_map.data.numpy()
grad_cam.clear_hook()

勾配(重み weights)と出力の特徴図(Feature Map)の加重合計で CAM を算出して、ReLU を通します

# Get cam
cam = np.sum((weights * feature_map.T), axis=2).T
cam = np.maximum(cam, 0)  # apply ReLU to cam

CAM を可視化するために、resize して正規化

import cv2
cam = cv2.resize(cam, VISUALIZE_SIZE)
cam = (cam - np.min(cam)) / (np.max(cam) - np.min(cam))  # Normalize between 0-1
cam = np.uint8(cam * 255)  # Scale between 0-255 to visualize

元画像に CAM を合成

activation_heatmap = np.expand_dims(cam, axis=0).transpose(1,2,0)
org_img = np.asarray(image.resize(VISUALIZE_SIZE))
img_with_heatmap = np.multiply(np.float32(activation_heatmap), np.float32(org_img))
img_with_heatmap = img_with_heatmap / np.max(img_with_heatmap)
org_img = cv2.resize(org_img, image_orig_size)

可視化

import matplotlib.pyplot as plt
plt.figure(figsize=(20,10))
plt.subplot(1,2,1)
plt.imshow(org_img)
plt.subplot(1,2,2)
plt.imshow(cv2.resize(np.uint8(255 * img_with_heatmap), image_orig_size))
plt.show()

実際の画像を入れてみる

Flickr にある Commercial use allowed の火災写真をモデルに入れてみます。

まずは正解例から:

f:id:maplerme:20181212105805p:plain
Image Source: https://flic.kr/p/Pf9dW3
(other: 0.0100, fire: 0.9900)

この写真は 0.99 で正しく火災写真と判定されました。Grad-CAM の結果も正しく火災の場所を特定できていると思います。(消防員も特定してほしかった、、、後、この写真は火災訓練っぽいので、本当は 火災ではない が正解かもしれません。)

もう一つ正解例:

f:id:maplerme:20181212105840p:plain
Image Source: https://flic.kr/p/M9wgsU
(other: 0.2345, fire: 0.7655)

モデルは煙をうまく見つけています。

悪い例をも見てみましょう:

f:id:maplerme:20181212105855p:plain
Image Source: https://flic.kr/p/29d3vTz
(other: 0.7869, fire: 0.2131)

Grad-CAM は正しそうに炎に特定したが、判定結果をみたら 0.7869 で other と判定されました。つまり、学習したモデルはこの炎で写真は火災写真ではないと判定しました、、、(たしかに炎がすごすぎで、フェイクっぽいかもしれないですね)

ちなみに強制で 火災 にしてみたらどうなるでしょうか?

# target = model_output.argmax(1).item()  # 予測値をコメントアウトして target を 1 に指定して逆伝播させる
target = 1
grad_cam.backward_on_target(model_output, target)

f:id:maplerme:20181212105936p:plain (other: 0.7869, fire: 0.2131)

消防車の部分を見ていました!

※ 上記のソースコードは https://github.com/mapler/gradcam-pytorch においてあります。

まとめ

今回は Grad-CAM という手法で CNN が画像のどこを見て判定しているかを可視化してみました。Grad-CAM を利用したモデルを可視化することによって、モデルが何を学習したか、何を学習不足なのかがわかるので、実業務の中でモデルのチューニング、学習データの選別などの領域で活用できます。

FASTALERT が扱うような SNS の投稿には、一般的に、画像だけでなくテキストも含まれていますが、このような自然言語の分類タスクに関しても TextCNN などの CNN を使った先行研究が存在しています。次回は、GradCAM を使った TextCNN の可視化を紹介したいと思います。

References


JX通信社で一緒に働いてくださる機械学習エンジニアを絶賛募集中です。
アプリエンジニア、サーバサイドエンジニアも募集しています。
まずは話を聞くだけでも構いませんので、気軽にご連絡ください

www.wantedly.com

Dockerイメージを簡単に作成できるjibの紹介

この記事はJX通信社Advent Calendarの9日目です。

Androidエンジニアのsakebookです。NewsDigestというアプリを開発しています。

普段は業務でKotlinばかり触る自分が紹介するのは「jib」というツールです。

github.com

jib

jibはJavaのアプリケーションをOCI Image Formatに則った形式でDockerイメージにしてくれるツールです。

jibを使うことで利用者は既存のJavaアプリケーションを少しの作業でDockerイメージにできます。

jib自体を簡単に使うためにMavenとGradleのプラグインが合わせて公開されています。

今回はGradleプラグインでの利用方法の紹介をします。

導入

既存のアプリケーションにプラグインを追加するだけで利用できます。

  • build.gradle
plugins {
  ...
  id 'com.google.cloud.tools.jib' version '0.10.1'
}

ターミナルで次のように実行すればDockerイメージが作成されます。

$ ./gradlew jibDockerBuild

Dockerfileの生成のタスクもあったんですが、0.10.1で削除されました

デフォルトで利用されるベースイメージはDistrolessと呼ばれるものを利用します。

これはExecutableなDockerイメージで、shellすらもないイメージです。そのため、jibで生成されるイメージは必要最低限のものになり、軽量なものになります。

Registryに登録

プラグインでは作成したイメージをRegistryに登録することもサポートしています。Credential Helperにも対応しており、設定していると次のようにシンプルに書けます。

  • build.gradle
jib.to.image = 'gcr.io/REPLACE-WITH-YOUR-GCP-PROJECT/image-built-with-jib'

直接認証する場合の例は次のようになります。

  • build.gradle
jib {
    to {
        image = "registry.hub.docker.com/XXXXXXX/YYYYYYYY"
        auth {
            username = USERNAME
            password = PASSWORD
        }
    }
}

DockerHubの USERNAMEPASSWORD は何らかの方法で渡します。 gradle.properties とかが簡単です。

  • gradle.properties
USERNAME=YOUR_USERNAME
PASSWORD=YOUR_PASSWORD

次のコマンドを実行すると指定したRegistryにイメージがPushされます。デフォルトだとDockerHubです。

$ ./gradlew jib

ファイル作成が手間だったら引数に渡すこともできます。

$ ./gradlew jib \
    -Djib.to.auth.username=YOUR_USERNAME \
    -Djib.to.auth.password=YOUR_PASSWORD

使ってみた

普段から使っているKotlinでDockerイメージが動かせるということなので、少し欲しかった機能を作りました。

弊社ではGitLabをホスティングしてます。GitLab CIでDockerが動くので、今回欲しかった機能はそこで動かすことにしました。

github.com

放置されてるissueが無いように定期的に呼びかけてくれるやつです。

GitLab CIでScheduling Pipelinesという機能があるのでそちらで上記のDockerイメージを動かします。

  • .gitlab-ci.yml
services:
  - docker:dind

job:on-schedule:
  only:
    - schedules
  script:
    - docker run -i --rm 
      -e DUE_DATE_REMINDER_HOST=$DUE_DATE_REMINDER_HOST
      -e DUE_DATE_REMINDER_PROJECT_ID=$DUE_DATE_REMINDER_PROJECT_ID
      -e DUE_DATE_REMINDER_GITLAB_TOKEN=$DUE_DATE_REMINDER_GITLAB_TOKEN
      -e DUE_DATE_REMINDER_LIMIT=$DUE_DATE_REMINDER_LIMIT
      -e DUE_DATE_REMINDER_SLACK_WEB_HOOK_URL
      sakebook/gitlab-issue-reminder

直接Dockerイメージを指定すると、ExecutableなDockerイメージだからか2度動いてしまう問題があったのでDocker in Dockerの構成で動かしました。このあたりはプラグインでDockerイメージを生成するときの設定か、ymlの書き方で解決できそうな気もしています。

動くとこんな感じでお尻を叩いてくれます。

f:id:sakebook:20181208140517p:plain
過ぎてるもののほうが多い

まとめ

ExcecutableなDockerイメージの生成を、ほぼ設定無しでできるのは便利です。JVMでありがちなクラスパス周りとかメイン関数のパスの指定とかも諸々をよしなにしてくれます。

さらにjibの開発は活発なので、今後にも期待できます。issueを上げてもすぐに対応してくれました。 この記事を読んだ人にとって、何かアプリケーション作成の選択肢が増えると幸いです。

参考

Introducing Jib — build Java Docker images better / Google Cloud Platform Blog

Golangでモックサーバーのライブラリを実装してみた話

この記事はJX通信社Advent Calendarの4日目です。

今年の10月からJX通信社でNewsDigestというiOS版アプリの開発担当として参画してるmoaibleです。

普段からアプリ・Webページのようなクライアントサイドとサーバーサイドの専任で開発担当が分かれていると、あるあるなのがスケジュール的にAPIの方が遅れていてクライアントサイド的にはレスポンスが無いと開発が進まないようなケースです。

そこでよくある解決策としては以下のようなパターンがあるのでは無いでしょうか。

  • クライアントサイド側でレスポンスをダミーとして固定ででっち上げる
  • モックサーバー環境があって本番で返す想定のレスポンスと同じ形式をとりまで返してもらう
  • モックサーバーをローカル環境として構築し、通信せずとも本番で返す想定のレスポンスと同じ形式を返すようにする

今回は上記太字の「モックサーバーをローカル環境として構築」にフォーカスを当て、環境構築を簡単にしたい、そのためにどうしたのかを話します。

既にあるモックサーバー用のライブラリ

まず既に「モックサーバーをローカル環境として構築」するようなライブラリはいくつも存在しており有名どころだと、

wiremock.org

オプションも多く特定のパラメータに合わせて細かい制御が効くこともあってよく名前が挙がるのでは無いでしょうか、ただ難点として環境構築・モックレスポンスの調整含めて慣れるのに時間がかかる印象です。

個人的によく使っていたモックサーバーとしては、

github.com

node製で、基本的に簡単な書式のroutingファイルだけ書いて後はjsonを設置するだけでモックAPIが出来上がるので簡単なAPIのmockingであれば十分に事足りるでしょう。

ただ細かいパラメータによるハンドリングまでは行えず、例えば特定のheaderの場合に準正常系なレスポンスを返すような調整をすることができませんでした。あとroutingに変更を加える場合はいちいちstubcellを再起動させねばならず若干使い勝手として面倒な印象もありました。

そこで簡単に環境構築ができて、さらに細かいパラメータの調整も可能な自分が欲しいライブラリを自分で実装してみることにしました。

gostub

github.com

これはディレクトリ構造を元にrouting定義として細かいハンドリングによって固定のjsonを返すことを可能にすることをコンセプトとしたGolang製のモックサーバーなライブラリです。

コードを見てもらっても分かるのですが特に他のライブラリに依存することなくGolangの標準ライブラリのみを組み合わせて実装しているためライブラリ実装自体も軽量なものとなっています。

導入

この記事ではGOPATHなどのGolang自体の環境構築は割愛しますが、Golangが動く状態で下記go getなコマンドを叩いてもらうだけで完了します。

$ go get github.com/gostub/gostub

コマンド

$ gostub -h

Usage of gostub:
  -o string
        output path (e.g. 'tests' -> ./tests)
  -p string
        port number (default "8181")

helpで出力されたままですが、

$ gostub -p :ポート番号 -o :モックサーバー起点となるディレクトリ

上記2つのオプションな引数のみとなります。

Hello, World!

GET /hello/world => { "greed": "Hello, World!" }

上記のようなリクエストに対して「Hello, World!」のレスポンスを固定で返すモックなAPIを構築します。

まずモックとして返すようにするためにディレクトリ構造を合わせていきます。

.
└── hello
    └── world
        ├── $GET.json
        └── response.json

ここで出てくる、$GET.jsonresponse.json が実際にリクエスト・レスポンスに関係するjsonです。

$GET.json

{
  "default" : {
    "body": "response.json",
    "status": 200
  }
}

response.json

{ "greed": "Hello, World!" }

動作確認

これで最低限の準備が整いました、試しにgostubを起こしてcurlを叩いてみます。

$ gostub -p 8081
Start gostub server...
port: 8181, output:

これで別窓でcurlを叩くと

$ curl http://localhost:8081/hello/world
{ "greed": "Hello, World!" }

という具合にレスポンスを確認することができました。

ただこれだけだとまだ良さが分からないので更に細かい機能の使い方を紹介していきます。

routing

さっきはGETなAPIのみの一例でしたが、実は見ての通り ${HTTPメソッド}.json で各種HTTPメソッドに対応することができます。

CRUDなREST APIに対応する場合は、

.
└── hello
    └── world
        ├── $GET.json
        ├── $POST.json
        ├── $PUT.json
        ├── $DELETE.json
        └── response.json

とすることで複数のHTTPメソッドに対応したモックAPIを実現できます。

特定のパラメータによるハンドリング

パラメータ種別 key名 定義
ヘッダー header "header": { "name" : "xxx" }
パス path "path": "xxx"
Query, Bodyパラメータ param "param": { "name" : "xxx" }

上記のパラメータをroutingのjsonに細かく追記することが可能です。

{
  "default": {
    "body": "default.json",
    "status": 200
  },
  "handlers" : [
    {
      "content": {
        "body": "failed_auth.json",
        "status": 401
      },
      "header": {
        "X-USER-ID" : "invalid user id",
      }
    }
  ]
}

上の例だと X-USE-IDinvalid user id という文字列だった場合に401を返す定義になります。

起動中でも動的にjsonを設置できる

大抵のモックサーバーなライブラリだとroutingを書き換えるのに再起動しないといけなかったりするのですが、routingのjsonも含めて常に動的に内部でハンドリングをしているため起動するだけで後は動かしながら好きに編集することができます。

モックサーバーを終了させる

CIなどでモックサーバーを立ち上げてユニットテストを実施するような場合だと二重に起動して動作しないようなケースに遭遇することも稀にあります。

そこでgostubではモックサーバーを終了するために GET /gostub/shutdown を叩くことで強制的に終了することが可能です。

終わりに

いかがでしたでしょうか。

モックの開発は一長一短で本番環境に近いことがベストだとは思いつつも、いざという場面で気軽に使えるGolang製のライブラリの紹介でした。

クライアントサイドで開発してる際に困った時にはモックサーバーは十分に選択肢の1つとしてあり得ると思うので、自分たちで開発環境を良くできるように立ち回っていきたいですね 💪

Go の GraphQL API のパフォーマンス改善のために分散トレーシングを導入した話

この記事はJX通信社Advent CalendarGraphQL Advent Calendarの1日目です。

JX通信社でNewsDigestというアプリを開発しているyamitzkyです。

NewsDigest では、アプリから利用する API に GraphQL を利用 しています。本番での利用を始めてからちょうど1年を過ぎました。

f:id:yamitzky:20181130001740p:plain

JX 通信社ではプログラミング言語として Python が使われることが多く、この GraphQL API も Python で作ってサーバーレス環境(AWS Lambda)にデプロイ していました。しかし、Lambda では要件が合わなくなってしまったため、現在では Amazon ECS で作った Docker クラスタ内で動いています。また、非サーバーレス化に合わせて、パフォーマンス要件を満たすために Go でのリプレイスを行いました。

f:id:yamitzky:20181130130648p:plain

この マイグレーションに伴って最も困難だったところがパフォーマンスチューニング です。 今回の記事では、Go で作った GraphQL API をどのようにパフォーマンスチューニングしたのかを紹介します。

ライブラリ選定

GraphQL の API は、一般的な API とは異なり、リクエストのパースやレスポンスの構築が難しい 、という点が挙げられます。RESTful API であれば「JSON」や「URLに対して正規表現をかける」など、言語標準のライブラリだけで簡単に実現しやすいのですが、GraphQL の場合は GraphQL の専用のスキーマやクエリなどの仕様があります。そのため、 ライブラリ選定が重要 になってきます。

f:id:yamitzky:20181130130618p:plain

NewsDigest では、 99designs/gqlgen というライブラリを選定しました*1。gqlgen はスキーマファーストで、冗長なボイラープレートが少なく、type safe で、 検証したライブラリの中で最も良いパフォーマンス (ns/op)でした。個人的な意見ですが、Go で GraphQL をやるのであれば、 gqlgen 一択だと思います。

他に検討したライブラリは以下のとおりです。*2

  • graphql-python/graphene:元々利用していたライブラリ。パフォーマンスが悪かったため不採用
  • graphql-go/graphql:スキーマ定義を Go でやる必要があり冗長だったのと、型安全ではなかったため不採用
  • graph-gophers/graphql-go:一個一個の resolver 定義が必要で冗長だったため不採用
  • samsarahq/thunder:パフォーマンスは gqlgen よりも少し良かったが、Interface に対応しておらず、移行できなかったため不採用
  • playlyfe/go-graphql:メンテが止まっていたため不採用

GraphQL API のパフォーマンスチューニング

ユーザー体験を最大化するためには、なるべく API のレスポンスにかかる時間を短くしたいです。

通常の API のチューニングであれば、「どのエンドポイントが遅いのか?」をまず探ると思うのですが、GraphQL API の場合は /graphql という単一のエンドポイントしかありません。

f:id:yamitzky:20181130125335p:plain

そこで、GraphQL の API でボトルネックを探る際には、 「どのリソースが遅いのか」をトレーシング するための、専用のツールなどを入れる必要があります。

gqlgen のトレーシング

GraphQL のパフォーマンスのメトリクスを取る際は、一般的には Apollo Tracing などが使われることが多いと思います。Apollo Tracing を使うと、どのリソースの解決に時間がかかっているかなどがよくわかります。 (この例では、 book のフィールドに author というものがあります)

f:id:yamitzky:20181130113741p:plain

しかし、Apollo Tracing への対応は、ライブラリ依存です。2018年3月当時は、gqlgen が対応していなかったため、この方法でのトレーシングはできませんでした*3。そのかわり OpenTracing というトレーシングに当時から対応していたため、こちらで対応することにしました。

OpenTracing / 分散トレーシング

OpenTracing は分散トレーシング(Distributed Tracing)のための規格のようなものです。あくまで規格なので、OpenTracing 自体はプログラムや個別の OSS ではありません。Jaeger や Zipkin のような OSS や、DATADOG のようなウェブサービスが、OpenTracing の規格に対応しています。

分散トレーシングというのは、一般的にはマイクロサービスのためのトレーシングに使われます。マイクロサービスの計測では、「ある1つのリクエスト」が、複数のマイクロサービスへのリクエストになり、ボトルネックが探りにくい、という問題があります。まさに、GraphQL API の計測が抱えていた問題と一緒です。

f:id:yamitzky:20181130125652p:plain

そこで、どの通信にどれくらい時間がかかったかや、どこで失敗したかを探りたい、というのが分散トレーシングの目的となります。

f:id:yamitzky:20181130125910p:plain

Jaeger の選定

OpenTracing は規格でしかないので、gqlgen の計測をする OSS の選択肢はいくつかあります。その中でも、Jaeger という OSS を選定しました。今回は、分散トレーシング自体初めてでいろいろわからなかったというのもあり、DATADOG のようなサービスは選定から外していました。

https://www.jaegertracing.io/img/jaeger-logo.png

  • Go 製の OSS
  • ストレージとして Elasticsearch と Cassandra に公式対応
  • Go、Python、Java、Node、C/C++ などに対応
  • HTTP だけでもメトリクスを集められる*4
  • アイコンが可愛い

分散トレーシングは個別のリクエストのトレーシングが注目されることが多く、「全体的にはどのリソースが遅いのか?」という統計的なものを得られる OSS は少ないのではないかと思います。その点 Jaeger は Elasticsearch に対応しており、 Kibana 上で集計して見ることもできるので良かったです。

Jaeger と Elasticsearch によるボトルネックの確認

こちらは実際の Jaeger の画面です(一部加工済み)。こちらの画面を見ると、どこでエラーが起きていて、どこの処理に時間がかかっているのがわかります。この場合、Query_piyo (piyo というリソース)の redis の処理が、ボトルネックとなっていることがわかります。

f:id:yamitzky:20181130122935p:plain

ただしここでわかるのは、あくまで個別のリクエストについてです。そこで、Kibana を使って、全体的なメトリクスを確認します(operationName で絞るのがポイントです)。こうしてみると、全体的には hoge のリソースの取得遅いようです。

f:id:yamitzky:20181130123612p:plain

(一部加工済みです)

Jaeger を入れてみてわかったこと

Jaeger を試してみてわかったのは、分散トレーシングの仕組み自体は、「GraphQL API」や「マイクロサービス」に限って便利なわけではない 、ということです。GraphQL であれば「どのリソースがボトルネックか」を知りたく、マイクロサービスであれば「どのマイクロサービスがボトルネックか」を知りたいのと同様、一般的なモノリスな API であっても「DB がボトルネックか、Redis がボトルネックか、アプリケーションがボトルネックか...」というのは知りたい情報です。実際、NewsDigest での利用方法でも、Redis やデータベースのアクセスのタイミングでトレーシングを仕込んでおり、Redis がボトルネックであることに気づいたりもしました。

f:id:yamitzky:20181130130248p:plain

APM サービスは他にもあるので、分散トレーシングの仕組みをわざわざ入れなくてももっと賢い方法はあるかもしれませんが、トレーシングが規格化されているのは特定のウェブサービスに依存しなくて済むのでいいなと感じました。

余談

今年の ISUCON は、GraphQL API のチューニング・・・とまではいかないまでも、マイクロサービスがお題になったりしないかな、と予想していました(笑)

JX 通信社では GraphQL API をもっと速くしてくれるサーバーサイドエンジニアを募集中です。

*1:当時は、vektah/gqlgen でした

*2:2018年3月に検証したため、現在は異なる可能性があります

*3:検証していませんが、現在は対応済みのようです。ありがとうございます。 https://github.com/99designs/gqlgen/pull/404

*4:一般的には、 HTTP 通信でマイクロサービス用の計測をすると遅い(無駄)なので、 udp を使うことが多いと思います。JX のインフラは AWS の Application Load Balancer を使うことが多いので、 HTTP で集められるのは助かりました