Filebeat + Logstashでrails6のログをElasticsearchへ取り込む設定

FilebeatとLogstashを使ってrails6のログをElasticsearchへ取り込もうとしたがなかなか難しかったので書く。

Elastic Stackのセッティングメモ

Elastic Stackのセッティングをしてみたのでメモ。

対象OSはUbuntu18.04

参考）

www.elastic.co

Elastic Stackで作るBI環境　Ver.7.4対応改訂版 (技術の泉シリーズ（NextPublishing）)

GKEからHerokuに引越したまとめ

実験・練習としてnekone.loveというtwitterに投稿されてる猫画像をひたすら表示しているサイトを運用している。
以前、k8sの使用感とかの確認のためにGKEを使って運用してたが、今回Herokuに移行したのでその時の作業メモなどを書く。

k8s(GKE)はなんだかんだで難しく規模の大きなシステム向き

k8sを触りたくてk8sで運用してたけど、わかったのはk8sはなんだかんだで難しいということだった。
「相当な専門性を持ってあたらないと、とても片手間で制御しきれるものではない」という印象だった。

「シンプルな構造にすれば保守性があがる」わけではないという話

こんがらがったシステムの保守開発で苦労した経験から新規開発では「シンプルな構成・シンプルな実装にしよう」という話が出る。
目指す方向としては間違って無いように思えるのに、それだけだとうまく行かない。

「保守しやすい構造」とはそれなりに多くの知識が必要なので、これらの知識を持たず単純に「シンプルな構成・シンプルな実装」を目指すと失敗する。

「保守しやすい構造」を作るには「どういう構造が保守しやすいのか？」を学ぶ必要がある。

これについて書く。

「シンプル」を目指したつもりが複雑になって失敗する例

まずは、ありがちな失敗例を示す。

リファクタしてて「やっぱ静的言語はいいよなぁ〜」と思った件

DDDの実践練習として作成している趣味プロダクト（Go言語）で、ちょっと設計をミスったのでリファクタをした。
リファクタ内容は「2つのエンティティとして扱っていたものを、1つの集約として扱うようにする」。

エンティティはシステム内で広く使われるデータ型なので修正範囲が結構大きかった。

作業風景をyoutubeにアップしてて、以下の「契約管理システムを作る #115」から「#122」くらいまでがその作業にあたる。

youtu.be

なんとかリファクタ完了して「やっぱ静的言語はいいよなぁ〜（respect 志村けん）」と思ったので書いてみる。

ビルド時エラーが対応必要リストになる

とりあえずエンティティを変更すると、ビルドが失敗しまくる。

gomockを使って「N回目呼ばれたらエラーを返す」を実現する方法

mockを使ってのテストは主に「起こしにくいエラーを再現する」場合にのみ使っている。
gomockにて、「N回目呼ばれたらエラーを返す（それ以外は実際の処理が実行される）」モックの用意の仕方をメモする。

スタブを使う。
github.com

ctrl := gomock.NewController(t)
defer ctrl.Finish()

// 商品リポジトリのモック作成
productRep := mock_interfaces.NewMockIProductRepository(ctrl)

callCount := 0 // カウンタを用意する
productRep.EXPECT().GetById(gomock.Any(), gomock.Any()).DoAndReturn(func(id int, executor gorp.SqlExecutor) (*entities.ProductEntity, error) {
    callCount += 1
    if callCount == 3 {
        // 3回目にエラーを発生させる
        return nil, errors.New("Productデータの取得に失敗しました")
    } else {
        // それ以外は本物で実際に処理を行う
        rep := repositories.NewProductRepository()
        return rep.GetById(id, executor)
    }
}).AnyTimes()

やっぱり正規化をベースにしたテーブル設計しか勝たん

テーブル設計は正規化を基本にして設計する手法しか成功しない気がしてる。

DBやテーブル設計系の書籍を読むとどれにも「正規化」による設計手法が書かれているけど、現場ではなぜかあまり正規化に重きをおいた設計が行われていない場合が多かった。

先人の経験から「教科書通りにいけば理想的だが、現実はなかなかそうは行かない」という事なのかと思っていたが、結局はどれもあまりうまくはいっていないように見えた。

個人プロジェクトは正規化をベースに設計したテーブルで開発を行っているが、とてもうまくいっている。 テーブル設計はやはり正規化を基本にして行うべきだと、改めて思ったので書いてみる。

正規化とは？

テーブルからデータの重複を排除し整合性を保持してデータを扱えるようにするための手法。