爆速でGo!

GoGo!

Go × Clean Architectureのサンプル実装

クリーンアーキテクチャとは

以下を実現することで、関心の分離をするアーキテクチャパターンです。

詳しくは様々な記事で説明されているので、今エントリでは割愛し実装パターンに絞って紹介します。

サンプルアプリケーション

↓サンプルコード

github.com

仕様は、/users にPOSTすることでユーザー登録するだけのapiです。
基本はmanuelkiessling/go-cleanarchitecturehirotakan/go-cleanarchitecture-sampleを参考にしていますがこれらはDBアクセスに直接sqlドライバーを使用しているため、今回はORMを使用した実装パターンを作ってみました。ORMライブラリはgormを使用しています。

app設計概要

f:id:NakaWatch:20180711163231j:plain

何層に分けるかは自由なのですが、原文に従って4層に分けました。
この時、外側から内側に向かって単一方向に依存することを徹底します。

ディレクトリ構成

       ├── adapter
       │   ├── controllers
       │   ├── gateway
       │   └── interfaces
       ├── domain
       ├── external
       │   └── mysql
       ├── main.go
       └── usecase
           └── interfaces

ディレクトリは、それぞれ以下の層の役割をしています。

ディレクト
external frameworks & drivers
adapter interface adapters
usecase app business rules
domain enterprise business rules

依存関係の徹底(重要)

実装の説明に入る前に、大事なルールを一つ説明します。
前述したとおり、依存関係は外側から内側へ単一方向へ保つ必要があります。
しかしながらどんなプログラムにも入力と出力があり、内側で処理した結果を外側へ出力するということが頻繁に起こります。
つまり、内側から外側へ依存したい場面が必ず現れます。その矛盾を依存関係逆転の原則を用いて解決することが、クリーンアーキテクチャをクリーンに保つための鍵となります。

依存関係逆転の原則(DIP)とは

簡単に言うと、内側は外側に依存するのではなく、抽象に依存するべきであるという原則です。
よくわからないと思うので、実際にコードを見てみましょう。

func (i *UserInteractor) Add(u domain.User) (int, error) {
    return i.UserRepository.Store(u)
}

これは、内から2番目の層、app business rules層 の実装です。
この層の外側から渡されたユーザデータを、外側にあるDBに保存しようとしています。
ここでやってしまいがちなのが、そのまま外側の層にアクセスしてしまうことです。
しかし外側に直接アクセスしてしまうと依存関係が内→外に向いてしまうので避けたいところです。
そこで依存関係逆転の原則を使います。Goではこれをinterfaceを定義することで実現します。

type UserRepository interface {
    Store(domain.User) (int, error)
    FindByName(string) ([]domain.User, error)
    FindAll() ([]domain.User, error)
}

同じ層にrepositoryインターフェースを定義し、このインターフェースに依存するようにします。
そして具象は外側で定義しておき、実行時に外側から渡してあげることで外→内の依存関係を保つことができます。
これが依存関係逆転の原則です。
ここを見ると分かりやすいかと思います。
サンプルコードでは、抽象に依存するためのinterfaceを各層のinterfacesディレクトリにまとめてあります。

各層の実装

内側の2層はプロジェクトによって結構変わってくると思うので、ここでは外側の2層に絞って説明していきます。

Frameworks & Drivers

DBアクセス

以下のようなDB接続等の外部との仲介実装はこの層で完結するようにします。

var db *gorm.DB

func Connect() *gorm.DB {
    var err error

    db, err = gorm.Open("mysql", "root:@tcp(db:3306)/hoge")

    if err != nil {
        panic(err)
    }
    db.Table("users").CreateTable(&gateway.User{})
    return db
}

func CloseConn() {
    db.Close()
}

ルーティング

http通信処理もこの層で完結します。今回はWAFにginを使用していますが、この層が独立しているので差し替えが容易になっています。
また、DBのコネクションやlogger等の具象型もここで内側の層に渡すようにしています。
こうすることで、前述した依存関係逆転の原則を実現しています。

var Router *gin.Engine

func init() {
    router := gin.Default()

    logger := &Logger{}

    conn := mysql.Connect()

    userController := controllers.NewUserController(conn, logger)

    router.POST("/users", func(c *gin.Context) { userController.Create(c) })

    Router = router
}

Interface Adapters

ORMのマッパーもここで定義します。
ここでは、DB用に最適化された型をドメインロジック用に最適化された型に変換することで、インピーダンス・ミスマッチを解決することに徹しています。
adapter層は抽象に依存しているとはいえ、この層で定義するinterfaceは外側のライブラリにある程度依存してしまいます。
原則では、

「抽象」は実装の詳細に依存してはならない

とされていますが、この層は変換が目的なので、ある程度どちらのことも知っているのが自然かと思います。
ここに関してもっと良い実装パターンをご存知の方がいらしたらご教授願いたいです。

type (
    UserRepository struct {
        Conn *gorm.DB
    }

    User struct {
        gorm.Model
        Name  string `gorm:"size:20;not null"`
        Email string `gorm:"size:100;not null"`
        Age   int    `gorm:"type:smallint"`
    }
)

func (r *UserRepository) Store(u domain.User) (id int, err error) {
    user := &User{
        Name:  u.Name,
        Email: u.Email,
    }

    if err = r.Conn.Create(user).Error; err != nil {
        return
    }

    return int(user.ID), nil
}

まとめ

見ての通り、user登録するだけのapiでもこんな大きなプロジェクトになってしまいます。
抽象化することで関心を分離することができますが、そこまでして分離する必要があるかはよく考える必要がありそうです。
基本的に抽象化するとコードは複雑化し、直感的ではなくなるので、アプリケーションの規模が小さい場合は効力を発揮しない場合が多いと思います。
何か間違いがあればご指摘頂けると大変助かります。

参考

csvをGoの構造体にマッピングする

Goでcsvを扱う際は、標準パッケージのendording/csvで対応できますが、いちいちスライスを扱うのは少しつらいものがあります。
大抵の場合構造体にマッピングした方が扱いやすいため、その方法を紹介していこうと思います。
csvマッピングライブラリはjszwec/csvutilgocarina/gocsvがありますが、今回は前者を使っていきます。

github.com

mapperの定義

User struct {
    ID              int    `csv:"id"`
    Name            string `csv:"name"`
}

以下のuser.csvを読み込みます。

id, name
1, nakabonne
2, ryo nakao

Unmarshal

var users []User
// バイト列を読み込む
b, _ := ioutil.ReadFile("user.csv")
// ユーザー定義型スライスにマッピング
_ := csvutil.Unmarshal(b, &users)

Marshal

// ユーザー定義型スライスの作成
users := []User{
    {ID: 1, Name: "nakabonne"},
    {ID: 2, Name: "ryo nakao"},
}
// バイト列に変換
b, err := csvutil.Marshal(users)

【Go】エディタ操作用簡易ライブラリを作った

はじめに

しっかりエディタでファイルオープンするとなると意外に煩雑になることに気づきました。 そこでedindというライブラリに切り出したので、今回はその紹介をしたいと思います。

github.com

使い方

クイックスタート

Factoryを生成し、エンドユーザーのシェルで実行可能なエディタを検出します。

import "github.com/nakabonne/edind"

// Factory生成
f := edind.NewEditorFactory()

// 実行可能なエディターを検出
editor, _ := f.DetectEditor()

// pathを渡してファイルを開く
_ = editor.Open("sample.txt")

選択肢追加

エディタ検出時の選択肢を追加したい場合、以下のように AddChoices メソッドを使用します。

f := edind.NewEditorFactory()
f.AddChoices(
        []string{"vi"},
        []string{"oni", "-w"},
)

5分でElasticsearch+Kibanaの環境を作る

動機

とりあえずローカルで一刻も早く動かしたい場合にサクッと構築する手順をまとめます。

手順

1, Dockerのインストール
2, dokcer-compose.ymlを作成し、以下をコピペする

version: "3.0"
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:5.1.1
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.graph.enabled=false
      - xpack.monitoring.enabled=false
      - xpack.security.enabled=false
      - xpack.watcher.enabled=false
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
      - es-data:/usr/share/elasticsearch/data

  kibana:
    image: docker.elastic.co/kibana/kibana:5.1.1
    ports:
      - "5601:5601"
    links:
      - elasticsearch:elasticsearch

volumes:
  es-data:
    driver: local

3, docker-compose.ymlが存在するディレクトリでdocker-compose upする(お使いのdocker-composeバージョンによってはyamlファイル内のversionを変更する必要があります)
4, http://localhost:5601にブラウザでアクセスし、kibanaの画面にアクセス

補足

xpackというパッケージの機能を全てオフにすることで、認証なしでリクエストを送ることが出来るようになります。
なので、サクッとローカルで試したい場合はこれらを外すことでスムーズに行なえます。
xpackとは何でしょうか。公式ガイドには以下のように書かれています。

X-Packは、セキュリティ、アラート、モニタリング、レポート、グラフの機能をインストールしやすい1つのパッケージにまとめたElastic Stackの拡張機能です。

GAE/Goからelasticsearchへ接続する

クライアントライブラリの選定

以上の2つが候補としてあげられます。どちらかというとGoらしく書ける印象だった2つ目のolivere/elasticを今回は使用します。

クライアントの生成

olivere/elasticは使用しているelasticsearchのバージョンごとにライブラリのブランチも切られています。
今回はelasticsearchバージョン5を使用しているので、gopkg.in/olivere/elastic.v5をimportして使用します。

import (
        elastic "gopkg.in/olivere/elastic.v5"
       "google.golang.org/appengine/urlfetch"
)

const ESURL = "https://35.174.182"

func main(){
    c := context.Background
    httpCli := urlfetch.Client(c) // URL Fetch Serviceの使用
    cli, err := elastic.NewClient(elastic.SetURL(ESURL), elastic.SetHttpClient(httpCli)) // clientの生成
    if err != nil {
        panic(err)
    }
}

NewClient(options ...ClientOptionFunc) (*Client, error)を呼び出すことによってクライアントを生成します。
ClientOptionFunc型の値を引数に与えることによってクライアントの設定を行います。

URL Fetch Service

GAE/Goから外部にリクエストを送る場合は、URL Fetch Serviceを使用します。
そのため、NewClient時にHTTPクライアントをurlfetch.Clientに差し替える必要があります。

操作

先程生成したクライアントを使用してelasticsearchのデータを操作していきます。
詳しくはwikiを参照して下さい。

func main(){
    cli.Start()
    defer cli.Stop()

    // ドキュメントの追加
    _, err := cli.Index().
        Index("index").
        Type("type").
        Id("id").
        BodyJson(struct{}).
        Do(c)

    // ドキュメントの削除
    _, err := cli.Delete().
        Index("index").
        Type("type").
        Id("id").
        Do(c)

}

Feature Flagを用いたA/B TestingツールをGCPで設計する

先日、AbemaTVが開催する「AbemaTV x A/B Testing」にてFeature Flagを用いたA/B Testingツールのインフラアーキテクチャ設計を行いました。
その時の学びをまとめていきます。

要件

Feature Flagを用いてA/Bテストできれば良いのですが、以下は守る必要がありました。

  • Uiの表示速度に影響しない
  • データに対して柔軟に素早く集計・分析できるようにする
  • スケーラブル

アーキテクチャ構成図

f:id:NakaWatch:20180312110231p:plain

僕達の最終的なアウトプットはこのようになりました。
色々書いてありますが、大事なのは以下の2つです。

  • 構成図下部のclientアプリがフォアグラウンドに切り替わったタイミングでfeature flagを受け取る。
  • test対象のclientは定期的にaction logをlogging service(構成図右下)にpostする。

Feature Flag取得時のキャッシュ戦略

f:id:NakaWatch:20180312113110p:plain

上図の通り、とりあえずUIを表示し非同期で取得し次回起動時に反映するという方式をとりました。
こうすることで、「UIの表示速度に影響しない」という要件を満たします。
しかしデメリットもあります。
それはFeature Flag取得までにラグがあることです。
すぐにFlagを切り替えたい時に、二回のアプリ起動が必要になります。
そのためアプローチとして以下の措置をとりました。

  1. プッシュ通知でアップデートフラグをローカルに立てる
  2. クライアントが次回アクティブになった時に強制的に反映(ロードが生じる)

わざわざローカルにフラグを立てるのは、プッシュ通知時に一斉にアップデートするというモデルはスケーラブルではないからです。

スケーラブル戦略

最も瞬間的にアクセスが集中する部分はflag取得前のtestユーザーチェックだと考えました。
(↓緑で囲われてる部分)

f:id:NakaWatch:20180314093944p:plain

そこで、MySQLの前段にRedisを置くことを決断しました。
set型の集合にuser_idをkeyにして、testユーザーチェック等の処理に必要な情報を置いておきます。
こうすることで、O(1)でのreadが可能になります。
また、Redis Clusterを使用することで複数ノードに自動的に分散することができます。 永続化とクラスタリングにはデータ更新時に整合性の問題がありますが、今回はtest終了時まで更新はないので問題ありません。

各micro serviceの仕事

lab receive service(構成図左下)

  • Labからセグメント情報もらう
  • ユーザーがアンケート等で直接入力した値と比較し、いい感じに挿入

logging service(右下)

  • clientから生のaction logを受け取る
  • redisからuserが参加中のtest情報を受け取り、BigQueryに挿入

aggregate service(右上)

  • バッチでBigQueryに対してクエリを実行
  • 管理画面からの呼び出しによって人為的にクエリ実行

cache service(左上)

  • テスト実行者が設定した情報をもとに、前段に置く値を決定する

フィードバック

構成図右部のlog集計部分をLambda Architectureに従って設計するべきだとのフィードバックを受けました。

f:id:NakaWatch:20180314094938p:plain

Lambda Architecture

Lambda Architectureとは、以下3つのレイヤーから構成される設計指針です。

バッチレイヤー:ログをバッチで集計するので正確だけど、リアルタイムではない
サービスレイヤー:バッチレイヤーの集計結果を提供する
スピードレイヤー:データはリアルタイムだが、データは少し不正確の可能性ある

スピードレイヤーの集計で得た最新の値とバッチレイヤーの集計によって得た確定した値をマージすることで、素早く推定することが出来るというモデルらしいです。
まだあまり理解していないので、詳しくは以下書籍を読んでみます。

www.oreilly.co.jp

まとめ

無知は罪だということを痛感しました。引き続きインプットの質を高めていこうと思います。

GoでDDD設計する際のrepositoryをどう定義するか

GoDDDでrepositoryを設計する際に色々考えたのでメモ

アーキテクチャ

この記事では、レイヤードアーキテクチャを使用します。
しかし正式なレイヤードでなく、以下のようにinfra層がdomain層に依存する形で設計します。

f:id:NakaWatch:20180210164321p:plain

ディレクトリ構成

.
├── app
├── domain
│   └── user
│       ├── user.go
│       └── user_repository.go
├── infra
│   └── mongo
│       └── user_repository.go
└── ui

repository定義

今回は以下のUserエンティティを永続化することを想定して勧めていきます。

package user

type User struct {
    ID   uint
    Name string
}

repositoryはinfra層とdomain層の2層に定義します。

domain層

domainディレクトリ配下に、
以下のようなRepositoryをインターフェースとして定義しておき、このRepositoryを実装すればUserエンティティが返ってくることを保証しておきます。

domain/user/user_repository.go

type UserRepository interface {
    Find(id int64) (User, error)
    FindAll(limit int) ([]User, error)
}

infra層

infraディレクトリ配下に、
domain層のRepositoryインターフェースを実装したRepositoryを定義します。

infra/mongo/user_repository.go

package mongo

type UserRepository struct {
    Context context.Context
}

func (r *UserRepository) Find(id int64) (user.User, error) {
    return r.find(r.Context, id)
}
func (r *UserRepository) FindAll(limit int) ([]user.User, error){
    return r.findAll(r.Context, limit)
}

repositoryの使用

package main

import (
    "fmt"

    "../domain/user"
    "../infra/mongo"
)

func main() {
        // Userエンティティが取得できることを保証
    var repo user.UserRepository
    repo = getUserRepoFromInfra()
    user, _ := repo.Find(1)
    fmt.Printf("type is %T", user) // => type is user.User
}

func getUserRepoFromInfra() user.UserRepository {
    return &mongo.UserRepository{}
}

窓口の抽象化

以上のように、domain層とinfra層の窓口を抽象化しておくことでインフラの差し替えを容易にする事が出来ます。