メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックリーディングカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

特定保健指導"フィッツプラス"事業を支えるモノリシック Rails + VIPER Swift アーキテクチャ

みなさんこんにちは。フィッツプラス開発エンジニアの福本(@terry_i_)です。
早いもので入社して半年が経ちました。普段はRailsを中心に色々と書いてます。

リモートワークが長く続いていることもあって、最近は自宅の開発環境を(過剰に)整備するのがマイブームです。先日はlogicoolのPCスピーカーを買いました。所得がゴリゴリ削られていってツラい。

さて今回は、これまで忙しくて紹介する機会のなかったフィッツプラスの事業概要や、アーキテクチャおよび使用する技術についてお話しします。

アーキテクチャに悩むエンジニアの方の参考になったり、皆さんのフィッツプラスへの事業理解が深まれば幸いです。


特定保健指導とは?

いきなり技術の話に入る前に、タイトルの”特定保健指導”という事業ドメインについて簡単にご説明します。

www.mhlw.go.jp

この”特定保健指導”という単語で、すぐピンと来るエンジニアの方は多くないでしょう。というのも、特定保健指導は健康保険に加入している40歳以上の方を対象に実施されているためです。

私も例に漏れずピチピチの若エンジニアですので、あまりよく知りませんでした。今は若い方もその内お世話になることと思います。

特定保健指導は、特定健康診査という定期検診で対象となった(要するに”引っかかった”)方の生活習慣病の予防および改善を目的に行われています。

具体的な内容としては、有資格者が対象者と最初に面接をし、その後一定期間継続的にサポートするプログラムです。それを”管理栄養士”という国家資格を有する専門職の方が、食生活を中心としたアドバイスを行って、生活習慣改善のサポートを行っています。

フィッツプラスはその”特定保健指導”を行うtoB向けのWebサービスを中心に、一般の方向けにも食事のアドバイスを行うアプリを開発・運営しています(後述)。つまり、フィッツプラスはメドピア内で”食”の観点から予防医療をケアする立ち位置で事業を推進していることになります。

メドピアグループはヘルステック企業として、幅広い医療領域を技術でサポートしています。中でも「予防領域」は、高齢化社会により高騰した医療費の削減などの社会的背景から、昨今とても重要視されております。

アーキテクチャ

f:id:terryyy:20200620202230p:plain

さて、この章から具体的な技術の話をしていきます。上記の図は、先ほど説明したフィッツプラス事業のサービスの中核であるRailsアプリケーション(dietplus-serverと呼んでいます)と、関連するアプリやサービスとの関係を図にしたためたものです。

「関連する」という表現ですが、この図には記載されていないWebサービスが複数稼働しています。モダンなプロジェクトで言うと、Nuxt.js + Rails6 でのSPA構成のサービスを絶賛開発してたりします。完成した暁には、そちらの担当エンジニアが記事を書いてくれると思うのでマァ首を長くして待っていてください。

上記の図をすべて解説すると薄い本が1冊書けてしまうので、中心となるRailsサービス『dietplus-server』と、上部オレンジ色の領域にあるiOSアプリケーション『DietPlus』のふたつに的を絞って今回はお話します。

以降では、まず裏側を支えているdietplus-server(Rails)について、その後にDietPlus(iOS)について解説します。そうすることで、現状のアーキテクチャ全体でのトータルなメリットや課題感をお伝えできればと考えています。

そういった目的上、RailsとSwiftの両方について触れています。「Swiftの話だけ聞きたいんだ俺は」という方は、お手数ですが、”VIPER Swift”の章から読んでいただけると幸いです。

モノリシック Rails

f:id:terryyy:20200620193739p:plain

中核となるRailsですが、先ほどの図では詳細が分かりづらいので、今回お話したいAPIと管理画面に関わるライブラリを記載した図を別途作ってみました。特徴的な部分について説明していきます。

ちなみに、2020年6月1日時点のrails stats では以下のような結果となりました。Rails のサイズ感が伝われば幸いです。

+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Controllers          |  11144 |   9420 |     223 |     840 |   3 |     9 |
| Helpers              |    212 |    175 |       0 |      27 |   0 |     4 |
| Jobs                 |    447 |    364 |      14 |      18 |   1 |    18 |
| Models               |  13809 |   8639 |     167 |     799 |   4 |     8 |
| Mailers              |    586 |    502 |      26 |      66 |   2 |     5 |
| Channels             |      8 |      8 |       2 |       0 |   0 |     0 |
| JavaScripts          |     67 |     21 |       0 |       4 |   0 |     3 |
| Libraries            |   1019 |    909 |       7 |       9 |   1 |    99 |
| Mailer specs         |      8 |      6 |       1 |       0 |   0 |     0 |
| Decorator specs      |     67 |     60 |       0 |       0 |   0 |     0 |
| Loyalty specs        |    205 |    147 |       0 |       0 |   0 |     0 |
| Model specs          |   6153 |   5438 |       0 |       0 |   0 |     0 |
| Request specs        |  10968 |   9586 |       0 |       0 |   0 |     0 |
| System specs         |   6937 |   5931 |       0 |       0 |   0 |     0 |
| Lib specs            |    659 |    560 |       0 |       0 |   0 |     0 |
| Job specs            |    154 |    123 |       0 |       0 |   0 |     0 |
+----------------------+--------+--------+---------+---------+-----+-------+
| Total                |  52443 |  41889 |     440 |    1763 |   4 |    21 |
+----------------------+--------+--------+---------+---------+-----+-------+
  Code LOC: 20038     Test LOC: 21851     Code to Test Ratio: 1:1.1

ActiveModelSerializers

APIでJSONを返すオブジェクトの作成はActiveModelSerializersで行っています。いちいちviewファイルを作ってレンダリングさせる必要がなく、関連オブジェクトの指定もRailsっぽく書けます。メドピアでは過去に他のチームでも採用情報があり、かつ一般的にもよく使われるgemなので特に違和感なく使えています。

tech.medpeer.co.jp

OpenAPI

各APIの定義はOpenAPI仕様のドキュメントをSwagger Editorで書き、Swagger UIで閲覧しています。

特徴としては、当初のアーキテクチャ図の通りAPIのレスポンスを返す先のアプリケーションが2つ(図のオレンジと緑の領域)ある点です。幸い2つのAPIは互いに独立しているので、各レスポンス先ごとに spec.yml の参照パスを分けた docker-compose のコマンドを、以下のようにMakefileを作って運用しています(一部改変しています)。

# Makefile
## Swagger-ui
### DietPlus
dietplus/api/docs:
    docker run --rm -p 8591:8080 -v $(CURDIR)/${DIETPLUS_API_SPEC_PATH}:/usr/share/nginx/html/spec.yml -e API_URL=spec.yml swaggerapi/swagger-ui
### DietPlus Pro
dietpluspro/api/docs:
    docker run --rm -p 8591:8080 -v $(CURDIR)/${DIETPLUS_PRO_API_SPEC_PATH}:/usr/share/nginx/html/spec.yml -e API_URL=spec.yml swaggerapi/swagger-ui

OpenAPIについては、私が後からSwaggerを導入したため、モック環境など一部整っていない部分があります。引き続き徐々に環境整備を進めていきたいという気持ちです。気持ちはあります。

Houston(プッシュ通知)

RailsからiOSアプリに対してのプッシュ通知(いわゆるAPNs)は、HoustonというgemをActiveJobと併用して行っています。Houston::Notificationをインスタンス化するだけで、iOSアプリに送る通知のバッヂや音声を簡単に設定し送信できます。

問題としては、執筆時点でmasterがiOSのバージョン13のプッシュ通知に対応していない点が挙げられます。

詳細は以下のIssueに記載されていますが、Apple Developersが要求するheaderの情報をgemで設定できないことが原因です。

github.com

幸いにもこのIssueに対応するPRが上げられているので、現在はGemfileのgitオプションを使用し該当するcommitを取り込む形で対処しています。実際には以下のように記述しています。

# ios push notification
# TODO: マージされたら git オプション外す
gem 'houston', git: 'https://github.com/ab320012/houston', ref: 'efbeb6c'

上記の対応には若干懸念が残っていて、オプションでcommit hashを直接指定している関係上、ハッシュ値が変わってしまった場合にbundle installできなくなります。rebaseforce pushなどが行われると、参照しているcommit hashの値が変わってしまう危険性があるようです。*1

Banken(権限管理)

管理画面にログインするユーザー権限の管理手法として、Bankenを採用しています。

github.com

前提として、後述の『DietPlus』を含む複数のスマホアプリを同じ管理画面を用いて管理しています。そして、アプリごとにメニューから画面を切り替えて操作するようになっており、(当然ですが)他のアプリの管理栄養士や管理者がユーザーの個人情報を見られないようにしています。また、同じアプリ内の画面でもセンシティブな情報(例: ユーザーとのチャットのやり取り)が含まれるものがあったりするため、画面ごとの細かい権限の制御が必要です(詳細は後述)。

アプリごとの namespace (実際はmodule)が複数存在し、画面ごとに権限を定義する必要があるため、Controllerベースで権限を付与するBankenは違和感なく使えています。RSpecでテストコードを書く際は、Request Spec内で権限ごとにループでテストを回しています(以下例)。

shared_examples_for "アプリの管理者と開発者のみアクセスできる" do
  [
    { name: 'アプリ管理者', trait: :app_admin },
    { name: '開発者', trait: :developer },
  ].each do |user_value|
    context user_value[:name] do
      let!(:user) { create(:admin_user, user_value[:trait]) }

      it { expect(response.status).to eq 200 }
    end
  end
end

context '各権限でアクセスする' do
  before { get admin_app_index_path }

  it_behaves_like "アプリの管理者と開発者のみアクセスできる"
end

VIPER Swift

f:id:terryyy:20200620194007p:plain

ここからは、クライアントサイドであるSwiftコードの設計と使用するライブラリについてお話できればと思います。

今回スポットを当てるアプリ『DietPlus』ですが、食事の写真を投稿すると管理栄養士の方がアドバイスをしてくれるサービスです。2019年10月にiOSアプリをフルリニューアルしてリリースし、その後いくつかの機能追加や改善を行いました。

medpeer.co.jp

こちらもコードのサイズ感をお伝えすると、2020年5月時点でのcloc の実行結果は以下のとおりです。

$ cloc --include-lang=Swift,Objective\ C --exclude-dir=Pods,Carthage ./
    6401 text files.
    6269 unique files.
    5721 files ignored.

github.com/AlDanial/cloc v 1.86  T=4.17 s (168.1 files/s, 13199.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Swift                          697           9707          11423          33492
Objective C                      5             86             37            363
-------------------------------------------------------------------------------
SUM:                           702           9793          11460          33855
-------------------------------------------------------------------------------

DietPlusのSwiftコードにおける特徴は、ピュアなVIPERアーキテクチャで構築されている点でしょう。VIPERについて詳細に書くと薄くない本が数冊書けてしまうので割愛しますが、いわゆるClean Architectureの一種です。

qiita.com

Rubyエンジニア的に言うと、フレームワークの『Hanami』に近いイメージがあります。Actionごとにクラスを切って1画面≒1クラスになる点や、ViewsとTemplateファイルが独立している点などが、VIPERのViewやPresenterの仕組みと似通っていると感じました。*2

Entityがキモ

f:id:terryyy:20200616231704p:plain

さて、VIPERにおいて最も設計が難しい点のひとつ(諸説あり)は、Entityに何を置くかでしょう。Clean ArchitectureではEntityを「アプリケーションに依存しないドメインおよびビジネスロジック(を示すデータの構造やメソッドの集合)」だとしています。*3

このEntityをインターフェースやDBから完全に切り離し、依存の方向を一方向にすることで(図参照)UIなどの変更が多い部分を変更しやすく、そうでない部分に影響を与えないようにします。この設計をいかに維持できるかで、プログラムの変更を容易にできるかが決まります。

DietPlusにおけるEntity

DietPlusにおけるEntityですが、結論から言うと「ユーザーの食事」と「食事の日付」に関わる部分が、最も中心的なドメインロジックとなっています。

人間の食事習慣や日付といった概念は普遍的なものですが、その食事や日付に対して「どうコメントを返信するか」「どういう」は、サービスを提供する私たち側の問題です。これをしっかり分けて考えることで、変更の多い部分をできる限りInteractorPresenterに切り出せています。

具体的にはこんな感じのコードが、ユーザーの食事投稿を表示するPresenterに書かれていて、Entityである食事(Meals)をUIで表現するデータに変換しています。

// MARK: - MealRecordPresenterProtocol
final class MealRecordPresenter: MealRecordPresenterProtocol {

    struct Constant {
        // 反映可能食事枚数の上限
        static let maxMealPhotoCount: Int = 4
    }

    
    struct InitialState {
        var date = Date(second: nil)
        var memo = ""
        var selectedCategory: MealCategory = .breakfast
        var selectedStyle: MealStyle = .home
        var tags: [MealTag] = []
    }
    
    // 取得可能枚数の上限
    private var maxAddableCount: Int {
        return Constant.maxMealPhotoCount - photos.count + deletePhotos.count - addedImages.count
    }
    private(set) var date = Date(second: nil)
    private(set) var photos = [Photo]()
    private(set) var deletePhotos = [Photo]()
    private(set) var addedImages = [UIImage]()
    var memo: String = ""
    var mealTags = [MealTag]()
    var selecetedCategory: MealCategory = .breakfast
    var selectedStyle: MealStyle = .home
    
    private(set) var mealDetail: MealDetail? // Editの場合に取得
    private(set) var initialState: InitialState?
    private var completionHandler: (() -> Void)?
    
    weak var view: MealRecordViewProtocol!
    var interactor: MealRecordInteractorProtocol!
    var router: MealRecordRouterProtocol!
    
    init(completionHandler: (() -> Void)?) {
        self.completionHandler = completionHandler
    }
}

一方、食事を表すEntityであるMeal.swiftはシンプルに書かれています。

ここにすべては記載できませんが、ファイル内のSwiftコードはExtensionの拡張を含めて66行でした。主要なEntityとしては薄い部類だと感じます。

struct Meal: Codable {
    
    let id: ID
    let time: Date
    let category: MealCategory
    let style: MealStyle
    var content: String?
    var memo: String?
    let createdAt: Date
    let updatedAt: Date
    var photos: [Photo]
    var mealTags: [MealTag]
    
    struct ID: Identifiable {
        let rawValue: Int
    }
    
    enum CodingKeys: String, CodingKey {
        case id
        case time
        case category = "categoryCode"
        case style = "styleCode"
        case content
        case memo
        case createdAt
        case updatedAt
        case photos
        case mealTags
    }
 
}

Embedded Frameworkによるマルチモジュール構成

また、VIPERのレイヤーの分割や依存関係の構造を守るために、UIコンポーネントや拡張メソッドを別のモジュールに切り出して管理しています。具体的には、以下の3つにモジュールが分かれています。

# DietPlus(App)
    - アプリ本体のコード
    - 画面に関するModule(View, Interactor, Presenter, Router)
    - Entityおよびサービスクラス(API、Database, Keychain, UserDefaultsなど)
# UIComponent
    - 各種UIパーツの格納
    - Color Asset, Image Assetも基本的にはこっちで管理
    - UITableViewCell, UICollectionViewCellといったCellクラスもUIComponentに追加
    - アプリ本体のモジュールはImportしない(依存は一方向のみ)
# Common
    - Extensionメソッド(UIは除く)
    - Standard Libraryに関するUtilityクラス
    - UIに限定されない各種定義値

アーキテクチャの設計を遵守できるのはもちろん、依存の方向性をある程度強制できるので「UIComponent →アプリ本体」という依存を作り循環参照が起きてぐちゃぐちゃになるそしてしぬ…ということが防げます。他にもnamespaceをきっちり分けることで、呼び出すモジュールやクラスを明確にできるという利点があります。

qiita.com

まだ実施していませんが、EntityやAPIは他のアプリのコードと比較して変更の頻度が速くないため、これも別モジュールに切り出して良いかもしれません。

現状のメリット/課題

さて、冒頭から偉そうに解説していますが、RailsとSwiftのどちらも私が設計したものではなく、過去に在籍したエンジニアの方が設計したものです(そのため私の解釈がある程度混ざっています)。私はその恩恵に預かっているわけですが、これまで半年間の開発で感じたアーキテクチャの「メリット」と「課題」についてお話します。

メリット

少人数のエンジニアリソースで開発できる

個人的にはこれが最も大きなメリットだと感じるのですが、コードベースの大きさと比較すると、人数の少ないチームで開発を進められます。

著書『人月の神話』の中で、フレッド・ブルックスは基本的な原則を明らかにしました。小さなチームなら、どんな方法論もうまくいくのです。―ケイト・トンプソン 『ZERO BUGS シリコンバレープログラマの教え』*4

実際に2020年5月の執筆時点で、フィッツプラスはサーバサイド4名とアプリエンジニア1名の計5名で開発を行っています。今回ご紹介したサービス以外にもRailsアプリケーションが2つにPHPのサービスやPythonスクリプトなどがあり、それらの存在も考えると少ない人数ではないでしょうか。小さなチームではコミュニケーションコストを低く抑えられ、サービスの前提やコードの変更状況などの共有がとてもラクです。

また、一般的な話をすると、そもそもベンチャー企業では物理的に大量のエンジニアを採用しづらいパターンもあるかと思います。まず最初はサービスをモノリシックに作り、市場に必要とされる機能を開発していくスタイルは、オーソドックスですがひとつの解ではあると思いました。

拡張性が高く複数のアプリケーションを展開しやすい

これはVIPERのくだりでドメインを定めたおかげですが、Entityで閉じ込めたロジックが複数のアプリケーションで共有されやすい状態だと感じます。

社内にはDietPlusに近いドメインを持ったiOSおよびAndroidのアプリ(冒頭アーキテクチャ図参照)が他にも存在していますが、アプリやバックエンドともに既存アプリと同じようにコードを書くことで再現できる部分が多く、後から入った身としては助かります。

また、テストを書く際に、テストケースを豊富に書くべき部分が明確になります。具体的には、日付に関しては境界値テストを必ず書いたり、APIリクエスト時のパスが想定しない日時だった場合の異常系のテストなどを増やしケースを充実させています。一方で、管理画面上(View)では課金などのクリティカルな処理を行っていないので、System Specは薄くて済みます。

実はサーバサイドと連携するアプリを他にも増やす予定があり(まだ喋れないやつ)、現在私が担当者としてモリモリとコードを書いているのですが、こういったことを簡単にできるのはひとつの強みです。

課題

アカウントや権限の管理が複雑になる

Bankenの章でピンと来た方がいるかもしれませんが、複数の権限が必要なアプリが複数存在しているため権限が複雑になってきています。

それぞれユーザーの権限を各Modelのenumで判断しているため、権限の説明やコンテキストをコードで表現・管理するのが難しいです。マイグレーション時にDBにコメントを残すことができますが、そこに盛り込むのに権限の説明は少し長すぎます。Model内に長文でコメントアウトを残すのが妥当なラインでしょうか。

長期的には、太ってきた権限を他のテーブルに分割していく等の改善方法があるかと考えています。権限の説明をコードで把握するのを諦めて、しっかりドキュメントを残すことも大切でしょう(視線を泳がせながら🐟)。

Swiftのファイル数が多くなる

VIPERに限らず、Clean Architectureでは”ファイル数が多くなりがち”です。責務を分割すればひとつのファイル(あるいはレイヤー)あたりのコード数が少なくなるので、その裏返しと考えれば当然です。

ひとつの画面を作るために、VIPERの頭文字(E除く)とStoryboardがひとつ(不要な場合もある)の合計5つのファイルを作成する必要があります。RailsならViewファイルを作成して、Controllerとrouteファイルに追記するくらい(諸説あり)なので、比べるとやはり多いと感じます。

これについては、コードとファイルの自動生成gemのGenerambaを用ることで工数を削減しています(アプリ開発のライブラリにRuby製のgemが使われていると、Rubyistとしては少し嬉しい気持ちになります)。工数の削減以外にも、Module構成やクラス記述などを統一できるメリットもあります。

github.com

他の自動生成ツールとしては、SwiftGen でリソースと型の作成を自動で行ったりしています。

一部のコードがmodule間でDRYにならない(しづらい)

A::UserB::Userといった別moduleの類似クラス(AやBはアプリ名)が数多く存在するのですが、共通化すべきコードとそうでないコードの見極めが難しいと感じます。各アプリでグロース速度が異なるのでなおさらです。普段コードを書いていて「あっ、このscopeってBの方には生えてなかったのか...」ということがよくあります。共通化するにも「3つ以上のmodule間で共通して使われ続けるであろう処理」かどうかの判断は容易ではありません。

個人的には、ヘンに共通化して罠にハマるくらいなら、メンテナンスするコード量が多少増えても、影響範囲をmodule内に閉じ込めておく方が無難なのではないかと考えます。

さいごに

長くなりましたが以上です。最後までお付き合いいただきありがとうございました。アプリケーションのアーキテクチャや使用するgemなど、皆さまになにか得るものがありましたら幸いです。

冒頭で事業について触れましたが、メドピアはメインサービスである「MedPeer」を中心に、さまざまな医療領域をカバーするため新しい事業をつぎつぎと立ち上げています。事業やプロダクトが社内にたくさんある現状から学べること・経験できることはとても多く、エンジニアとしてとても魅力的な環境だと思います。

ステマみたいになりました しかし、プロダクトをより良くするために、私たちにはエンジニアの力がもっと必要です。というか一生「足りない」って言い続けてる気がしますが、そんな中でも一緒に走りながらお互いを高めあえるエンジニアの方はぜひメドピアへ!

■募集ポジション

medpeer.co.jp

■開発環境

medpeer.co.jp

*1:リポジトリをforkしprotect branchすればケア可能: 参考

*2:実際、HanamiはClean Architectureに影響を受けているそうです: 『Hanamiフレームワークに寄せる私の想い(翻訳)』https://techracho.bpsinc.jp/hachi8833/2018_03_28/54381

*3:『クリーンアーキテクチャ(The Clean Architecture翻訳)』https://blog.tai2.net/the_clean_architecture.html

*4:"37.象の多くの側面"より引用

Terraform用のGitHub Actionsをterraform-github-actionsから後継のsetup-terraformに移行する

SREの侘美です。

最近はfirst call for オンライン診療の開発でRailsのコードを書いてました。

hashicorp/terraform-github-actions から後継である hashicorp/setup-terraformへ移行した際にいくつか設定でハマったので、そのことについて書いていきたいと思います。

背景

メドピアではterraformでAWSのインフラを管理しています。
terraformのリポジトリでは、レビューがスムーズに行えるようにGitHub Actions上で terraform planterraform applyterraform fmt 等を実行できる hashicorp/terraform-github-actions を利用し、下の画像のようにplan結果をPRに自動で投稿するようにしていました。

f:id:satoshitakumi:20200520154554p:plain

新サービスをリリースし仕事も一段落した先日、TerraformのGitHub Actionsに関するとあるドキュメントが更新されていることを発見しました。

Teraform GitHub Actions - Terraform by HashiCorp

なんと hashicorp/terraform-github-actions のメンテナンスが終了されていました!

メンテナンスされていないActionsを利用したままでは、最新のterraformのバージョンに対応できない日がやってきそうなので、さっそく後継の setup-terraform でGitHub Actionsの設定を書き換えることにしました。

準備

まずGitHub Actionsの設定を修正する前に、 terraform-github-actions と 後継である setup-terraform の特徴と terraform plan の実行例を比較してみました。

terraform-github-actions

リポジトリ

github.com

特徴

  • 各ステップで uses: hashicorp/terraform-github-actions@master を指定して、 initplan などのサブコマンドを指定して使う
  • tf_actions_comment: 'true' を指定することで、plan結果をPRに投稿してくれる
  • planの差分が無い場合はPRに投稿はしない

Actions上でterraform planを実行するサンプル

steps:
  - uses: actions/checkout@v2

  - name: Terraform Init
    uses: hashicorp/terraform-github-actions@master
    with:
      tf_actions_version: ${{ env.TF_VERSION }}
      tf_actions_subcommand: 'init'

  - name: Terraform plan
    uses: hashicorp/terraform-github-actions@master
    with:
      tf_actions_version: ${{ env.TF_VERSION }}
      tf_actions_subcommand: 'plan'
      tf_actions_comment: 'true' # PRへplan結果を投稿する設定

setup-terraform

リポジトリ

github.com

特徴

  • 文字通りterraformをsetupし、 terraform コマンドが利用できるようにする
  • GitHub Actionsのoutput等に対応するようにscriptでwrapされている
  • plan等は run: terraform plan で実行する
  • その他の機能は無く、plan結果のPRへの投稿などは自前で設定する必要がある

Actions上でterraform planを実行するサンプル

steps:
  - uses: actions/checkout@v2

  - uses: hashicorp/setup-terraform@v1
    with:
      terraform_version: ${{ env.TF_VERSION }}

  - run: terraform init

  - run: terraform plan -no-color

setup-terraformへの乗り換え

特徴が把握できたところで、setup-terraformを利用してPRにplan結果を投稿する設定をしていきます。 基本的には terraform-github-actions の仕様を再現する形としています。

具体的には下記の3点です。

  • PRへのplan結果の投稿
  • 差分が無い場合は投稿を抑制
  • 差分以外の余計な出力の削除

PRへのplan結果の投稿

setup-terraform の README に記載されている設定を参考にします。

下記のように actions/github-script を使い createComment 関数でコメントを投稿します。
secrets.GITHUB_TOKEN はActions上で自動で定義される変数です。

- uses: actions/github-script@v1
  env:
    # id: planのステップの出力を参照
    STDOUT: "```terraform\n${{ steps.plan.outputs.stdout }}```"
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    script: |
      const output = `<details><summary>tf plan:</summary>\n\n${process.env.STDOUT}\n\n</details>`;

      github.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: output
      })

差分が無い場合は投稿を抑制

実装方法としては2通りあります。

1つはterraformの -detailed-exitcode オプションを使うやり方です。
このオプションを付与することで、コマンドのexit codeが下記のようになります。

  • 0: 成功かつ差分なし
  • 1: エラー
  • 2: 成功かつ差分あり

GitHub Actionsではexit codeが0以外の場合はエラーとなりworkflowで利用するには continue-on-error: true をplanのステップに追加する必要があります。

steps:
  # 他のstepは省略
  - name: terraform plan
    id: plan
    run: terraform plan -detailed-exitcode
    continue-on-error: true # 0以外のexit codeでもworkflowを継続する
  
  - name: comment on PR
    if: ${{ steps.plan.outputs.exitcode == 2 }}
    # 以下PRにコメントする処理

2つめは単純に出力内容の文字列から取得する方法です。
こちらはあまりロバストではないですが、 continue-on-error: true を利用しなくてすむため、今回はこの方法を採用しています。

steps:
  # 他のstepは省略
  - name: terraform plan
    id: plan
    run: terraform plan
  
  - name: comment on PR
    if: ${{ !contains(steps.plan.outputs.stdout, 'No changes.') }}
    # 以下PRにコメントする処理

差分以外の余計な出力の削除

terraform-github-actions ではterraform planを実行した際に大量に出力される <resource_id>: Refreshing state... のような出力を削除した上でPRにコメントしてくれます。

f:id:satoshitakumi:20200520154554p:plain

terraform-github-actionsの実装 を確認してみると、 sed コマンドで ------(略 の区切り線を基準に行を削除していました。

terraform-github-actions 同様に sed コマンドで消しても良いのですが、PR投稿のgithub-script内でついでに整形する実装にします。

steps:
  - uses: actions/github-script@v1
    env:
      STDOUT: "${{ steps.plan.outputs.stdout }}"
    with:
      github-token: ${{ secrets.GITHUB_TOKEN }}
      # NOTE: 区切り文字で囲まれた範囲のみを出力する
      script: |
        const lines = process.env.STDOUT.split('\n')
        const separator = '-'.repeat(72)
        let index = lines.indexOf(separator)
        let outputLines = lines.slice(index + 1)
        index = outputLines.indexOf(separator)
        if (index) {
          outputLines = outputLines.slice(0, index)
        }
        const planOutput = '```' + outputLines.join('\n') + '```'
        const output = `<details><summary>plan:</summary>\n\n${planOutput}\n\n</details>`;

        github.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: output
        })

最終的なGitHub Actionsの設定

最終的な設定は下記のようになりました。

steps:
  - name: Checkout Repo
    uses: actions/checkout@v2

  - name: setup Terraform
    uses: hashicorp/setup-terraform@v1
    with:
      terraform_version: ${{ env.TF_VERSION }}

  - name: terraform init
    run: terraform init

  - name: terraform plan
    id: plan
    run: terraform plan -no-color -lock=false

  - uses: actions/github-script@v1
    if: ${{ !contains(steps.plan.outputs.stdout, 'No changes.') }}
    env:
      STDOUT: "${{ steps.plan.outputs.stdout }}"
    with:
      github-token: ${{ secrets.GITHUB_TOKEN }}
      # NOTE: 区切り文字で囲まれた範囲のみを出力する
      script: |
        const lines = process.env.STDOUT.split('\n')
        const separator = '-'.repeat(72)
        let index = lines.indexOf(separator)
        let outputLines = lines.slice(index + 1)
        index = outputLines.indexOf(separator)
        if (index) {
          outputLines = outputLines.slice(0, index)
        }
        const planOutput = '```' + outputLines.join('\n') + '```'
        const output = `<details><summary>tf plan:</summary>\n\n${planOutput}\n\n</details>`;

        github.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: output
        })

所感

terraform-github-actions から比べるとPRへplan結果を投稿する付近の処理を自前で用意しなければならず、難易度は上昇したように思えました。
ですが、無事に後継の setup-terraform へ移行することができたので、terraformの最新バージョンへの追従する際のActions関連の懸念を減らすことができました。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

最小手数で始めるTailwind CSS

パクチーパクパク小宮山です。
掲題通りTailwind CSSの始め方を最小手数で書いていきます。余談は一切ありません。

tl;dr

CSS管理は諦めてTailwind CSSを使おう。

Get Started

tailwindcss.com

ひたすら公式通りに進めます。例によってフロントエンドプロジェクトの環境構築はひたすら面倒なので、Tailwind CSS以外のツールチェインはなるべく使わない構成を目指します。

installします。

$ yarn init
$ yarn add tailwindcss

セットアップします。

$ yarn tailwindcss init

こういうファイルが作られました。

tailwind.config.js

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

スタイルのエントリーポイントなるCSSファイルを作成します。ファイル名は任意です。このファイルをTailwind CSSが用意しているCLIでビルドすることで、実際にhtmlファイルで読み込むCSSファイルが出力されます。

tailwind.css

@tailwind base;

@tailwind components;

@tailwind utilities;

TODOリスト感のある素朴なHTMLファイルを用意します。この時点ではpublic/style.cssはまだ生成されていません。

見た目だけの実装なのでフォームも飾りです。

public/index.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" href="style.css">
    <title></title>
  </head>
  <body>
    <h2>New Todo</h2>
    <form>
      <input type="text" />
      <button>submit</button>
    </form>
    <h2>List Todo</h2>
    <ul>
      <li>
        <p>todo 1</p>
        <p>2020 05/12</p>
      </li>
      <li>
        <p>todo 2</p>
        <p>2020 05/12</p>
      </li>
      <li>
        <p>todo 3</p>
        <p>2020 05/12</p>
      </li>
    </ul>
  </body>
</html>

public/style.cssを生成するためのscriptを用意しておきます。

package.json

{
  "name": "minimum-tailwindcss",
  "version": "1.0.0",
  "scripts": {
    "build:css": "tailwindcss build tailwind.css -o public/style.css"
  },
  "dependencies": {
    "tailwindcss": "^1.4.6"
  }
}

実行します。

$ yarn build:css

お好きなwebサーバーを起動してpublic/index.htmlを開きます。package.jsonを汚したくなかったのでnpxでずるして最小手数の体裁を保ちます。

$ npx http-server ./public

スタイルが何もあたっていない状態のwebサイトが完成しました。Tailwind CSSにはnormalize.cssが含まれている(v1.4.6時点)ので、リセット系CSSを別で用意する必要はありません。

f:id:robokomy:20200518174836p:plain
ネイキッドウェブサイト

準備が整ったので早速Tailwind CSS流にスタイルを当てていきます。

  <body>
    <h2 class="mb-2 px-2 text-xl">New Todo</h2>
    <form class="mb-4 px-4">
      <input type="text" class="p-2 border" />
      <button class="ml-2 p-2 rounded text-white bg-blue-500">submit</button>
    </form>
    <h2 class="mb-2 px-2 text-xl">List Todo</h2>
    <ul class="py-2 px-4">
      <li class="p-2 border">
        <p class="border-b">todo 1</p>
        <p class="text-sm">2020 05/12</p>
      </li>
      <li class="mt-2 p-2 border">
        <p class="border-b">todo 2</p>
        <p class="text-sm">2020 05/12</p>
      </li>
      <li class="mt-2 p-2 border">
        <p class="border-b">todo 3</p>
        <p class="text-sm">2020 05/12</p>
      </li>
    </ul>
  </body>

大分それっぽくなりました。

f:id:robokomy:20200511191309p:plain
それっぽい見た目

使い方は見た目通りで、classがそれぞれ特定のCSS定義として用意されています。

例えばp-4ならpadding: 1rem;mt-2ならmargin-top: 0.5rem;といった感じです。インラインスタイルを簡略化したような使用感です。

デフォルトスタイル余談

tailwindcss.com

Tailwind CSSを使う上でまず最初に注意したほうがよいことは、line-heightのデフォルト値です。デフォルトでline-height: 1.5;htmlにあたっているので、全ての余白を自力で指定してピクセルパーフェクトを目指す場合は少し厄介です。

htmlに反映されていることもあり、気にせずスタイルを当てていって途中で変更したくなってしまうと相当な被害になることが予想されます(私です)。それっぽいline-heightを全体に当てておくか、パーフェクトを目指して全てを自力で当てるかの方針はなるべく早期フェーズでの選択がおすすめです。

Vendor Prefixes余談

ターゲットとするブラウザ次第では必要になるであろう、みんな大好きVendor Prefixesです。結論を言ってしまうとTailwind CSS自体にはVendor Prefixes的な対応は入っていません。

それを解決するのはもっとうまくやれる他のツールに任せているというのが公式スタンスです。ドキュメントでもAutoprefixerとの併用が紹介されています。

tailwindcss.com

この先はもうPostCSSの話題になってしまうので深入りはしませんが、Tailwind CSSをPostCSSのプラグインとして利用することも可能なので導入もそんなに手間ではありません。

ファイルサイズ問題

Tailwind CSSを活用する上で無視することのできない非常に重要な問題がファイルサイズです。

実際にtailwindcss buildを叩いてみた方なら、このような表示がされて既に嫌な予感を持っていたかもしれません。

   🚀 Building... tailwind.css

   ✅ Finished in 1.56 s
   📦 Size: 1.95MB
   💾 Saved to public/style.css

✨  Done in 4.11s.

「📦 Size: 1.95MB」です。これは相当に大容量です。normalize.cssが含まれているとはいえ、scriptもfontも含まれていないただのCSSファイルでこれは流石に無視できるサイズではありません。

ファイルサイズが肥大化する理由は明白で、p-4mt-2といったCSSのプロパティと数値の組み合わせが無数に存在するからです。さらにレスポンシブ対応でsm:p-4なんて指定も用意されているので、それら全てが含まれていると考えれば膨れるのも当然なわけです。

実はあのBootstrapにもこのようなutility的なclass群は存在しています。しかし用意されているものは必要最低限で、Tailwind CSSほどの汎用性も拡張性もありません。

内部事情までは知りませんが、おそらくファイルサイズの肥大化という問題は少なからず意識して絞っているのではないでしょうか。

getbootstrap.com

Bootstrapがおそらく敢えて避けているであろう、ファイルサイズがひたすら肥大化していくutility的なclass群という方向にTailwind CSSは振り切っているわけです。その方向に振り切る以上、便利さと引き換えにファイルサイズは諦めなければならない・・という時代もかつてはあったのかもしれません。しかし今は令和です。あれも欲しい、これも欲しいもっともっと欲しいを実現してくれる強力なツールが存在します。

PurgeCSSです。

PurgeCSS

purgecss.com

まただよ、またフロントエンド開発環境に登場人物が増えたよ即ブラウザバックしかけた方はちょっとだけ待ってください。なんとTailwind CSSは最近のリリースでPurgeCSSも内包するようになったので、設定ファイルを微修正するだけです。Tailwind CSS陣営としても、ファイルサイズ肥大化は重要な問題で、その解決法を明示する必要があると判断したのでしょう。

github.com

デフォルトの設定ファイルから、purge部分を少しだけ変更します。Tailwind CSSのclass表現を使っているファイルが全て含まれるようにパスを指定します。そうすることで、そのファイル内で現れていない不要なclassが全て削除されます。

tailwind.config.js

module.exports = {
  purge: ['./public/**/*.html'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

パージ機能を有効にするにはNODE_ENV=productionの指定が必要です。早速実行してみます。

NODE_ENV=production yarn build:css
   🚀 Building... tailwind.css

   ✅ Finished in 1.29 s
   📦 Size: 12.08KB
   💾 Saved to public/style.css

✨  Done in 1.87s.

CSSのファイルサイズ肥大化は、人類にとって最早克服された問題だったのです。PurgeCSSが存在するからこそTailwind CSSのutility-firstという方針が成立すると言っても過言ではないかもしれません。これぞシナジーです。Cookie Clickerをやり込んだ皆さんなら、シナジーが如何に強力かつ重要なのかは身をもって体験しているはずです。

続けて拡張の話題に移りますが、そこでもPurgeCSSという存在が控えていることが非常に重要となります。

PurgeCSS余談: 禁忌事項

PurgeCSSを使う上で、いつか足元を撃ち抜くかもしれない禁忌事項が1つあります。それは、classを必ず完全な形で記述する」ことです。

例えばfont-sizeを動的に指定しようとして、こんな記述をしてしまうかもしれません。

fontSize = 'text-' + size; // size: 4 | 6 | 8

撃ち抜きました。完全に撃ち抜いて水中から氷の天井を見上げています。理由は単純で、PurgeCSSは正規表現によって、使われているclassを探します。つまり動的に生成されたclassは発見のしようがなく、無慈悲にproductionビルド時に削除されます。

多少遠回りになっても、classを完全一致な文字列としてファイル内に記述しなければいけません。例えばこのように。

fontSize = { 4: 'text-4', 6: 'text-6', 8: 'text-8' };

PurgeCSSの要請からこのような完全一致で書く必要があるわけですが、CSSセレクタをこのように完全一致で書くことを習慣つけるのはものすごくおすすめです。以前似たような話題で開発ブログも書きました。

tech.medpeer.co.jp

以前まではgrepがしにくいというやや個人的かもしれない理由だったんですが、今ではPurgeCSSの要請という強力な後ろ盾を得たのでバンバン推していきます。

拡張

デフォルトで用意されているclassでも不便はあまりないんですが、どうしてもそれだけでは足りないシーンというのもあります。

例えばTailwind CSSはremベースの指定が基本となっています。p-4ならpadding: 1rem;'、p-6なら1.5rem`といった具合です。

なんかそれっぽい感あってrem指定いいですよね。しかし残念ながら世の中そんな甘くなく、往々にしてpx単位ベタ打ちのピクセルパーフェクトを求められてしまうことだってあります。pxremに変換してなんとか表現するという努力も悪くないですが、なかなかに不毛な作業です。

そんなときはさくっとTailwind CSSを拡張してしまいましょう。

tailwind.config.js

module.exports = {
  purge: ['./public/**/*.html'],
  theme: {
    extend: {
      spacing: {
        // px単位
        ...[...Array(120)].reduce((m, _, i) => {
          m[`${i}px`] = `${i}px`
          return m
        }, {}),
      },
    },
  },
  variants: {},
  plugins: [],
}

豪快にp-1pxからp-120pxまで用意してみました。ピクセルパーフェクトし放題です。僅かばかりの良心で120pxにしましたが、必要な分だけ増やしてしまってください。

さて、こんなことをしたらファイルサイズがどんなことになるか想像はつくと思いますが、せっかくなのでそのままビルドしてみます。

   🚀 Building... tailwind.css

   ✅ Finished in 4.59 s
   📦 Size: 4.97MB
   💾 Saved to public/style.css

✨  Done in 6.11s.

やばいですねぇ、これはやばい。それではオチも何もなく結果も見えていますがPurgeCSSを通したビルドを行なってみます。

   🚀 Building... tailwind.css

   ✅ Finished in 4.42 s
   📦 Size: 11.79KB
   💾 Saved to public/style.css

✨  Done in 4.99s.

そういうことなんですね。Tailwind CSSの拡張は本来ならばファイルサイズ肥大とトレードオフで、神経すり減らしながら必要最小限になるよう調整しなければなりません。しかし今は令和です。我々の後ろにはPurgeCSSという対不要CSS最終防衛兵器が控えています。

ファイルサイズが2倍に膨れるようなこんな拡張を施しても、使わなかった分は全て削除されます。常に必要最小限の拡張が達成可能です。

レンダリング関数との組み合わせ

この頃流行りのライブラリと組み合わせてみます。最小手数と宣言してしまっているのでなるべく最小手数で使えそうなツールを探しました。探す手間は私が負ったので見逃してください。

サンプルコードが何の環境構築もなしに簡単に動いたので今回はPreactでいきたいと思います。まともに使った経験はないのでなんとなくで使っていきます。

preactjs.com

Getting Startedにて紹介されている最小手数っぽい方法でさきほどのTodoページを書き換えてみます。リスト部分のみです。

  <body class="p-2">
    <script type="module">
      import { h, render } from "https://unpkg.com/preact?module";

      const li = i => h(
        'li',
        { class: 'mt-2 p-2 border border-red-500' },
        [
          h('p', { class: 'border-b' }, `todo ${i}`),
          h('p', { class: 'text-sm' }, '2020 05/12'),
        ]
      )

      const app = h('div', null, [
        h('ul', { class: 'py-2 px-4 border border-red-500' }, [1, 2, 3].map(i => li(i)))
      ]);

      render(app, document.body);
    </script>
  </body>

jsxのセットアップをしだすと最小手数をはみ出しそうなのでh関数でゴリゴリと書きます。ReactしかりVueしかりElmしかり大体同じ使い心地です。結局のところTailwindCSSを使うときはclassの当て方にしか関心を持つ必要がないので、どんなツールを使おうが相性が悪くなることはないです。

f:id:robokomy:20200511200704p:plain
こんな感じ

レンダリングをscriptで制御できる利点の1つといえばリストをループでまとめて書けることです。ただループで回す欠点として、当然ですが全ての要素に同じclassが当たります。

'mt-2 p-2 border border-red-500'

そうするとこのように、端っこの要素に付けたくないmarginborderが付いてしまうことがよくあります。

f:id:robokomy:20200511200721p:plain
気になる隙間

まず浮かぶ解決策は普通にclassを付けてcssを当てていく方法です。

.item:first-child { margin-top: 0; }

しかしせっかくTailwindCSS使っているのだから、見通しをよくするためにも独自のclassは極力使いたくないという欲が出てきます。よし分かったcssを使いたくないなら、scriptで制御してしまえばよいではないか方針に切り替えます。

'p-2 border border-red-500' + (i === 0 ? '' : 'mt-2')

確かにこれで解決して世界は平和になったように見えるんですが、我々が求めているのは本当にこれだったのかという疑問が残ります。

そんなところで、TailwindCSSは新たな解を用意してくれています。

これを、

'mt-2 p-2 border border-red-500'

↓こうする。

'mt-2 p-2 border border-red-500 first:mt-0'

first:mt-0'というclassが増えました。見た通りです。これを付けると&:first-child { margin-top: 0; }と同様な効果があり、リストの先頭要素だけmargin-top0にすることができてしまいます。

f:id:robokomy:20200511201224p:plain
しゅっ

後出しですが注意点として、このfirst:mt-0という機能はデフォルト設定のままでは使えません。このようなprefixで制御するスタイル機能は複数あり、すべてを有効にすると相当なファイルサイズになってしまうからです。

tailwindcss.com

有効にするにはvariantsという設定を拡張します。firstlasthoverなど有用なものは揃っているので、気になったものはとりあえず有効にしちゃいましょう。使っていないものはどうせPurgeCSSで削除されます。

追加した設定はデフォルトのものとマージはされず、上書きされるので注意してください。

tailwind.config.js

module.exports = {
  purge: ['./public/**/*.html'],
  theme: {
    extend: {},
  },
  variants: {
    margin: ['responsive', 'first', 'last'],
  },
  plugins: [],
}

first:m-0first:m-1first:mt-0という風に用意されるclassが倍々で増えるので当然ですがcssファイルサイズも相当に膨れます。

   🚀 Building... tailwind.css

   ✅ Finished in 1.69 s
   📦 Size: 2.12MB
   💾 Saved to public/style.css

はい、PurgeCSSの出番です。

   🚀 Building... tailwind.css

   ✅ Finished in 1.44 s
   📦 Size: 11.79KB
   💾 Saved to public/style.css

レンダリング関数との組み合わせ: Elm余談

メドピアでElmは一切使われていないので完全に余談なんですが、Tailwind CSSはElmプロジェクトにものすごくおすすめです。

自分自身Elmは最近少し触っているくらいでそこまで詳しくはないという前置きをしておいて、script部分に関してはその徹底した関数型言語特性から非常に強力なんですが、スタイルに関しては重要視されていないのかあまりよい戦略が見つかりません。探せばなくもないんですが、模索中な段階だったりやたらとややこしかったりするものが多いです。

ベストプラクティスじゃなくてもいいからとにかく手軽にスタイルを当てたいんだということで、結局素のCSSファイルをindex.htmlで読み込んだり、インラインスタイルを使っていくとう場面が結構あるのではないでしょうか。そして古き良きweb開発におけるスタイル管理苦難の旅路を追体験していくわけです。

そんなあなたにTailwind CSS。

div [ class "p-2 border text-blue-500" ] [ text "hello world!" ]

ただclassを提供するだけで特定フレームワークに依存しないので、もちろんElmとも相性ばっちりです。PurgeCSSは正規表現で使われているclass名を探しているだけなので.htmlでも.jsxでも.elmでもファイル形式は問題になりません。

インラインスタイルを超えて

Tailwind CSSの使い心地はインラインスタイルライクですが、そのポテンシャルはインラインスタイル特有の制約をものともしません。先ほども紹介した、first:mt-0というprefix付きの指定方法(variants)がそれです。

インラインスタイルの泣き所として、first:hover:といったセレクタや、レスポンシブのためのメディアクエリを使うことができません。まともなwebページを作る上でこれらの制約は致命的です。仕方ないから無理な部分だけCSSを別で作って対応したとしても、今度はインラインスタイルとCSSファイル内のスタイルが散らばって管理が面倒になっていきます。

一方でTailwind CSSはインラインスタイルライクではあっても中身はセレクタ指定のCSSなので、このような制約もうまく回避してくれています。

first:hover:は先の例で既に示しました。そしてレスポンシブも同じく、xs:p-1sm:p-2という風にprefixを付けるだけで分岐が可能です。

余談: そうはいっても万能ではなかった

残念ながら万能ではありません。実際に使ってみて、これは辛いなと感じたシーンもちょくちょくあります。

例えば親要素がhoverされたら子要素をdisplay: none;にしたいなんていう場面です。1つ1つのDOMに対してclassを当てていくという使い方になるので、親子であろうとDOMを跨いだスタイル制御をすることは現状だと厳しそうです。敗北した気分でしぶしぶCSSを書きましょう。

Tailwind CSS上級者の方々ならもしかしたら解決策を持っているかもしれません。求む情報発信。

実際に導入したNuxt.jsプロジェクトでのCSS比率余談

Tailwind CSS流のclassだけで実際どこまでスタイルを作れるのかは気になる点だと思います。どうしても素のCSSを書かなければならない場面があったとしても、そういう場面が多すぎたらTailwind CSSの導入はかえってスタイル定義の散逸を招いてしまうからです。

ということでNuxt.js利用の実際のプロダクトで集計してみました。.vueという拡張子のファイル153個に対して、<styleという文字列grepでヒットしたファイルが13個です。

その13個の内容はざっと見た限りこのようなものです。

  • html全体にかかるfont-familyなどの設定
  • <slot />で挿入した要素に対してのスタイル指定
  • <select>へのappearance: none;
  • アニメーション関係(transitionanimation@keyframes
  • DOM跨ぎのhover:制御

少なくないといえば少ないかもしれませんが、前向きに捉えればこれら以外はすべてTailwind CSS流儀でカバーできているわけです。まずまずな結果ではないでしょうか。

ちなみにそのプロダクトというのはこちらです。こっそりデバッグツールで覗いてみてもらうとTailwind CSSの雰囲気が分かるかもしれません。

spot-rmc.medpeer.jp

まとめ

近年のフロントエンド関連技術は激しく進化しまくっているものの、CSS関連の話題はどうしても置き去りにされやすいです。そうはいっても辛さは無視できないので様々な手法も考案されてきてはいますが、フレームワーク依存だったりまた新たな辛さが出てきたりとなかなか明る い未来は見えてきません。

そういう状況の中で、主観ベースですが、Tailwind CSSは過去最高に使い勝手が良かったです。インラインスタイルライクなのに制約が少なく拡張性が高い、そしてCSSファイルを管理する必要がほぼない。この特徴が非常に強力です。

CSS管理は諦めてTailwind CSSを使おう。現時点で私から提示できるCSS戦略のベストプラクティスです。


これは全く余談ではないんですがメドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html


中途で入社したての私からみたメドピア開発環境のいいところ

2020年1月付けで入社した社長室 エンジニアの芝田と申します。 社長室ではkakariという、かかりつけ薬局化を支援するサービスをやっており、そちらでサーバーサイドエンジニアとして働いています。

エンジニアとしてのキャリアはメドピアで2社目で、まだまだ勉強中の身です。 今回はメドピアでの開発を始めて、開発環境のいいところや実装のtipsを一部ご紹介したいと思います。

開発環境のいいところ

CIでRSpecやRubocopをはじめとする複数のLint👮が通っていないと原則マージできない

Rubyは自由な記法ができるメリットの反面で、記法のばらつきが比較的出がちです。そこは、Lintによってある程度カバーすることが可能です。

また、ClassLengthLineLengthAbcSize等によって、ファイルの肥大・コードの複雑度合いを知ることができます。 kakariではClassLength 100行以上はマスターデータではない限り許可していないので、読むのを諦めたくなるファイルは無いです。

Dangerを使い、他のファイルと合わせてこう書いてほしいというレビュー漏れを無くしている

例えば、プルリクエストを出した際に、XXX.created_at.strftime('%Y/%m/%d %H:%M')をチーム内ではl(XXX.created_at, format: :datetime_with_slash)と書いてほしい時に、Dangerで設定しておくと自動で警告を出してくれます。

API~フロントエンド間で開発前にOpenAPIを使って、送るパラメータと期待するレスポンスを決定している

yamlを書くだけでSwagger Editor上やChromeの拡張でリッチなUIのAPI仕様書を自動生成してくれたり、committeeを使って、OpenAPIで定義したレスポンスをRspecで自動チェックしてくれたりします💪

kakariのメンバーが以前作成した資料がありますので、ご興味ある方は併せて確認お願いします。

speakerdeck.com

可能な限りパフォーマンスの良い書き方を求められる。

bulletでテスト時にN+1を検知したり、無駄な繰り返し処理をできるだけ減らす書き方を求められます。

例えば、対象となる患者を探すロジックを書きたい時、account.patients.not_deleted.select do |patient|だと論理削除されていない患者全体を取得し、患者数分繰り返し回してしまい患者数が多いほどパフォーマンスが悪くなります。

この場合、wherefindメソッドを使って一気に対象患者を検索するようにすることが望ましいです。 また、関連付けされた値をキャッシュしたかったり、テーブル同士をjoinやキャッシュする必要がある場合は、eager_loadpreloadメソッドを適切に使うようにしています。

テストをしっかり書いている

入社する前の私はどちらかというとテストは書かず、ブラウザで動作確認をしていました。しかし、テストがない環境では、バージョンアップやリファクタリングが辛かったり、動作が要件通りになっているだけ(行が長かったり引数が多い)のメソッドを書きがちです。

特にレビューや仕様追加によって、コードを変更した際、常に要件通りのチェックを毎回するのか?となり、テストを書かなかった工数分が後で確認工数増加やデグレとして降りかかってきます。

社内全体でテストがしっかり書く習慣となっているため、kakariでは最新のRails6系やRuby 2.7系を使っており、他の依存ライブラリも常にアップデートされています。また、リファクタリング系のissueにはテストが既に書かれているため、書いた本人以外でも着手しやすいようになっています。

実装のtips

プレーンなRubyファイルで書かれたPOROでロジックをこまめに切り出す

私はまとまったロジックが必要になった時、モデル側にインスタンスメソッドやクラスメソッドを書いて実装しがちでした。しかし、ロジックがモデルに集中すると、関心事が入り乱れてテストし辛いコードになりがちです。

kakariではFoo::Updaterのようなクラスを切り、クラスメソッドでcallすることが多いです。-er(~する人)が呼ばれる(call)という名前だと、メソッド名に悩まされにくく、読み手側の頭にも入ってきやすいかと思います。

class Foo::Updater
  def self.call(params:)
    new(params).call
  end

  def initialize(params)
    @params = params
  end

  def call
    update
  end
  
  private
  
  attr_reader :params
  
  def update
    # 何かの処理
  end
end

POROに関しては弊社の技術顧問である@willnetさんが書いた記事もありますので、ご興味ある方は併せて確認お願いします。

tech.medpeer.co.jp

繰り返し参照されるメソッドは変数に格納する

2度目も参照されるロジックの場合、結果を変数に格納しています。初回はインスタンス変数がnilになるので、右側の式が実行されます。

2度目以降の実行では変数が使われるので、2度目以降に引数を変えて異なる結果を取得したい場合は意図しない挙動になるので注意してください。

def foo_object
  @foo_object ||= Foo::Creator.call
end

列挙型で使いたいカラムはデフォルト値をDB側で定義するのではなく、モデル側で定義する

enumerizeを使う場合、モデルにデフォルト値を持つことが可能です。メリットとして、項目が増えたときにデフォルトの値を変えたい際、migrateファイルを発行せずに済みます。またtextで指定できるので、何の値をデフォルトにしているかが明確です。

class CreateFooBars < ActiveRecord::Migration[6.0]
  def change
    create_table :foo_bars do |t|
      t.integer :age_code, default: 4
      t.timestamps
    end
  end
end

ではなく、下記のようにモデル側で定義する。

class Foo < ApplicationRecord
  extend Enumerize

  enumerize :age_code, in: {
    all: 0, older_forty: 1, older_fifty: 2, older_sixty: 3, older_sixty_five: 4,
    older_seventy: 5, older_seventy_five: 6, older_eighty: 7
  }, default: :older_sixty_five
end

名前の重複のない関連付けの参照をする

例えばモデルとしてはfoo_answerfoo_questionで示したいが、関連付けする際には、デフォルトでfoo_answer.foo_questionとなってfooが冗長です。 Railsのデフォルトのinverse_ofから外れてfoo_answer.questionfoo_question.answersとしたい時はinverse_ofを明示的に設定します。

class FooQuestion < ApplicationRecord
  has_many :answers, class_name: 'FooAnswer', dependent: :destroy,
                     foreign_key: :question_id, inverse_of: :question
end
class FooAnswer < ApplicationRecord
  belongs_to :question, class_name: 'FooQuestion', inverse_of: :answers
end

Viewでしか使わない整形用のメソッドはDecoratorに切り出す

erbやHamlで実装している箇所はDecoratorを使ってviewにロジックを直接書かないようにしています

module FooDecorator
  def full_name
    "#{last_name} #{first_name}"
  end
end

おわりに

私は今までの考え方として、スピードを優先するときはある程度汚い状態のコードがリリースされるのは仕方がないと思っていました。しかし、メドピアではビジネスのスピード感を犠牲にせず、そしてマンパワーにも頼らず、便利なライブラリで賢く仕組み化して、コードの品質を落とさない取り組みを実践しているという部分に触れられたことが、入社して良かった点の1つです。なので、このような開発環境で成長したい人にとっては、メドピアへの入社というのは良い選択肢の一つだと感じました。

今回は他の記事と比べて1つの事項を深掘りした内容ではありませんが、「お、使ってみようかな」・「メドピアの開発環境のことをもっと知りたいな」と思っていただける内容が1つでもあれば幸いです!読んでいただき、ありがとうございました。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html


ビジュアルリグレッションテストを導入した話

f:id:mpg-kazuhiro-kobayashi:20200408153648p:plain

こんにちは。フロントエンドエンジニアの小林和弘です。

Vue.js + Atomic Designでつくられたプロジェクトにビジュアルリグレッションテストを導入しました。

ビジュアルリグレッションテストでUIの安全性を高める

コンポーネントの改修、新機能の追加、ライブラリのアップデートを行う際、UIに不要な変更が入っていないか不安になることがあると思います。リファクタリングをしようにも、意図しないところでUIが壊れないか心配になります。

画面表示に関わるコードを改修するたびに、ローカル環境やステージング環境で全UIコンポーネントを確認するのは難しいです。

また、ステージング環境と本番環境を並べて変更されたUIを目視で確認するのも非現実的です。

ビジュアルリグレッションテストはその名前の通り、視覚的な回帰テストを指します。改修前後のスクリーンショットの差分を検証するためのテストです。
開発におけるUIの安全性を高め、安心してUI改善を行えるようにビジュアルリグレッションテストの導入を行いました。

使用したツール

  • reg-suit
    • ビジュアルリグレッションテストのためのテスティングツール
    • 差分レポートを作成してくれる
    • GitHubへのPull Request通知機能があり、PR毎にUI差分が見れる
  • Storybook
    • UIコンポーネントのカタログを作成する
    • 実装済のUI、UIパターンをすぐに確認できる
    • 画面上でコンポーネントの挙動把握ができる
    • アドオンが豊富でデバイスサイズ変更時のUI表示確認などができる
  • Storycap
    • Storybookから各コンポーネントのスクリーンショットを作成する
    • reg-suitと同じGitHub Organizationのreg-viz内で管理されている

Storybookの導入

まずは比較画像の元となるStorybookを導入します。
インストール用のnpm@storybook/cliが提供されているのでnpxコマンドでインストールをします。
今回はVue.jsプロジェクトに導入するのでtypeオプションにvueを設定します。

$ npx -p @storybook/cli sb init --type vue

インストール時に行われるのは

  • Storybookと依存モジュールのインストール
  • StorybookのAddonのインストール
  • npm scriptsにStorybookを実行するスクリプト追加
  • storiesディレクトリの追加
  • 設定ファイルを格納する.storybookディレクトリの追加

になります。

storiesディレクトリ内にはサンプルのStoryファイルとVueコンポーネント(Welcome, MyButton)が格納されています。

package.jsonにはstorybook, build-storybookが追加されます。

{
  "scripts": {
    "storybook": "start-storybook -p 6006",
    "build-storybook": "build-storybook"
  }
}

storybookを実行するとnpm scriptsに設定されたポート番号 6006 でStorybookが立ち上がります。

$ yarn storybook

f:id:mpg-kazuhiro-kobayashi:20200407121031p:plain

Storycapの導入

次にStorybookに登録されたStoryのスクリーンショットを作成して、reg-suitで画像の比較ができるようにしていきます。
スクリーンショット作成のためにStorycapをインストールします。

$ yarn add storycap --dev

次に.storybook/config.jsを作成して、StorybookのAddonとしてStorycapを登録します。
今回はVue.jsのプロジェクトなので@storybook/vueからaddDecoratorを呼び出しています。

import { addDecorator } from '@storybook/vue';
import { withScreenshot } from 'storycap';

addDecorator(withScreenshot);

package.jsonにStorycapを実行するnpm scriptsを追加します。

{
  "scripts": {
    "screenshot": "storycap --serverCmd \"start-storybook -p 6006\" http://localhost:6006"
  }
}

実際にコマンドを実行すると、__screenshots__ディレクトリにスクリーンショットが保存されます。

スクリーンショット画像はバージョン管理に含める必要がないので.gitignoreに追記してGitの管理下から外しておきます。

__screenshots__

reg-suitの導入

まずreg-suitをインストールします。

$ yarn add reg-suit --dev

次にローカルのreg-suit initコマンドを実行します。対話形式でreg-suitの設定ができます。

$ yarn reg-suit init

Plugin(s) to install (bold: recommended)
使用するプラグインを選択します。
今回は下記の3つを選択しています。


Working directory of reg-suit. => .reg
テストの結果を出力するディレクトリを指定します。デフォルトの.regディレクトリのままで問題ありません。


Append ".reg" entry to your .gitignore file. => Yes
reg-suitの出力結果はAWS s3で管理するので、Gitの管理下から外すためYesにします。


Directory contains actual images. => __screenshots__
テストに利用する画像のディレクトリを指定します。
Storycapのデフォルト値の__screenshots__を指定します。


Threshold, ranges from 0 to 1. Smaller value makes the comparison more sensitive. => 0
テストの差分比較の閾値を設定します。
厳密に差分検知をしたい場合は0を指定します。


notify-github plugin requires a client ID of reg-suit GitHub app. Open installation window in your browser => Yes
GitHub Appのreg-suitの登録を行います。
reg-suitの設定ページがブラウザで開くので、ビジュアルリグレッションを導入したいリポジトリを選択します。
Client IDをクリップボードにコピーしておきます。

f:id:mpg-kazuhiro-kobayashi:20200407164809p:plain


This repositoriy's client ID of reg-suit GitHub app => {Client ID}
GitHub AppのページでコピーしたClient IDを設定します。


Create a new S3 bucket => No
AWSにログイン済みでs3の作成権限があればYesにしてbucketの作成を行います。
権限がなかったので今回はNoで回答しました。


Existing bucket name => ***
s3のBucketが作成済みの場合、ここでbucket名を設定します。


Update configuration file => Yes
ここまで回答した設定を、設定ファイルのregconfig.jsonに反映します。


Copy sample images to working dir => No
サンプル画像のコピーは不要なのでNoで回答します。


以上でreg-suitの設定が完了です。

次にpackage.jsonのnpm scriptsにreg-suitのコマンドを追記します。

{
  "scripts": {
    "regression": "reg-suit run"
  }
}

AWS s3の権限があればローカル実行で動作します。

$ yarn regression

CircleCIの設定

GitHubのリモートブランチへpushした時に自動でテストを実行するために、CIの設定を追記します。

今回使用しているのはCircleCIです。

GitHubアカウントでCircleCIにログインして、Projectsから対象のプロジェクトを選択します。

f:id:mpg-kazuhiro-kobayashi:20200407120526p:plain

プロジェクト選択後、Project Settings > Environment VariablesからAWS s3のAccess Key IDとSecret Access Keyを設定します。

reg-suitコマンドではデフォルトでAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY変数を参照するようになっています。

別の変数名を定義したい場合(今回は仮にREGRESSION_ACCESS_KEY, REGRESSION_SECRET_KEY)、npm scriptsのregressionで変数を代入しておきましょう。

{
  "scripts": {
    "regression": "AWS_ACCESS_KEY_ID=$REGRESSION_ACCESS_KEY; AWS_SECRET_ACCESS_KEY=$REGRESSION_SECRET_KEY; reg-suit run"
  }
}

次にCircleCIの設定ファイルconfig.ymlにJOBを追加します。

jobs:
  visual_regression:
    steps:
      - checkout
      - restore_cache:
          name: Restore node_modules
          key: yarn-{{ checksum "yarn.lock" }}-{{ .Environment.CACHE_VERSION_NPM }}
      - run:
          name: Install dependencies
          command: yarn install
      - save_cache:
          name: Cache node_modules
          key: yarn-{{ checksum "yarn.lock" }}-{{ .Environment.CACHE_VERSION_NPM }}
          paths:
            - ~/workspace/node_modules
      - run:
          name: install jp fonts
          command: sudo apt-get install fonts-ipafont-gothic fonts-ipafont-mincho
      - run:
          name: screenshots
          command: yarn screenshot
      - run:
          name: regression
          command: yarn regression --quiet

デフォルトでは日本語フォントがTofuになってしまうため、IPAフォントをインストールしています。

実際に使う

実際にGitHub上でPRを作成するとCircleCI上でvisual_regressionが実行され、完了したらキャプチャ画像のような結果レポートのコメントが追加されます。

f:id:mpg-kazuhiro-kobayashi:20200407120737p:plain

this reportのリンクをクリックすると、s3にアップロードされた差分比較ができるページに遷移します。

f:id:mpg-kazuhiro-kobayashi:20200407190805p:plain f:id:mpg-kazuhiro-kobayashi:20200407190820p:plain

差分があった場合、もしくは新規でスクリーンショットが追加された場合、reg-suitのチェックが失敗します。

レビュアーがreg-suitのPRのコメントやレポートを確認して問題がないか確認します。

UI変更に問題があった場合はPR上でUIの修正を進めます。

UIの変更に問題がなければ、Approveをします。Approveするとreg-suitのチェックがパスするようになります。

まとめ

Storybook + reg-suitによるビジュアルリグレッション導入はこれで完了です。

やっていることとしては

  • StorybookでUIのカタログを作成
  • StorycapでStorybookのスクリーンショットを作成
  • reg-suitでGitのブランチ間のスクリーンショットの比較レポートを作成
  • reg-suitのGitHub AppでPR上にコメントを通知

になります。

実際に非レスポンシブなサイトを部分的にレスポンシブ対応する際にビジュアルリグレッションテストでUI破壊をいくつか検知でき、その恩恵を受けることができました。

意図しないUI破壊を防ぐためにビジュアルリグレッションテストを導入しましたが、大元となるのはStorybookに登録されたStoryです。
なのでStorybookのメンテナンスを怠るとテストが形骸化してしまいます。

Storybookはメンテナンスコストが高く、導入が難しいという意見もあります。しかしStorybookによるUIのカタログ化は、メンテナンスコストを差し引いても大きなメリットがあると考えています。
ビジュアルリグレッションテストのスクリーンショットに利用できるだけではなく、実装済みUIの再実装を未然に防いだり、Storybook上でコンポーネントの動作を確認しながらUI開発ができたり、Addonを使ってレスポンシブ表示を確認できたりと様々なメリットがあります。

この記事で皆様の安全なUI管理に少しでも貢献できれば幸いです。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html


バックグラウンドで実行するバッチ処理の改善のためSidekiq Enterpriseを導入しました🥳

こんにちは、エンジニアの森田です。 MedPeerでは、バックグラウンドで非同期に処理を実行させる方法としてSidekiqを使っておりましたが、今回Sidekiq Enterprise(Proを含む)を導入しました。

https://sidekiq.org/products/enterprise.html

今回はSidekiq Enterpriseを導入するにあたって解決したかった課題と実際の導入方法、導入後の活用事例をを紹介できればと思います!

Sidekiq Enterpriseとは?

Sidekiq Enterpriseとは、その名の通りエンタープライズ向けの機能拡張が行われた有料版のSidekiqです。(Sidekiq Enterpriseとは別にSidekiq Proもありますが、Sidekiq Enterpriseを導入するとSidekiq Proの機能も使用出来るようになります。)

ProとEnterpriseそれぞれで主に下記のような拡張がされています。

Sidekiq Pro

  • RELIABILITY
  • BATCHES

Sidekiq Enterprise

  • RATE LIMITING
  • PERIODIC JOBS
  • ENCRYPTION

詳しい機能の紹介は公式のWikiが充実しているので、興味の有る方はそちらをご確認いただくのが良いかとおもいます。

Home · mperham/sidekiq Wiki · GitHub

Sidekiq Enterprise導入に至った背景

MedPeerではバックグラウンドで実行するバッチ処理にSidekiqを使用しています。サービスの成長に伴い日々Jobは増えていて、100を超えるJob(2020/03/19現在)が実行されています。

+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Jobs                 |   4482 |   3607 |     106 |     500 |   4 |     5 |
+----------------------+--------+--------+---------+---------+-----+-------+

Jobの中には、利用者へのインセンティブ進呈に関わる等、影響が大きいものもありJobにおける処理の信頼性の担保が今まで以上に求められるようになってきました。

またデプロイによるJobへの影響も当時の問題として発生しておりました。 実行完了までに長時間かかるようなJobがあり、デプロイ時のSidekiqのプロセス再起動により実行が中断されるとJobの処理が中断され再実行しても正常に完了できず、毎日運用担当の方からメール配信のスケジュールを共有いただき、エンジニア側でデプロイタイミングがかぶらないように注意するような運用をしていました。。。

f:id:madogiwa0124:20200325115651p:plain

このような背景から解決方法を探していたところ弊社技術顧問である前島さんからSidekiq Enterpriseを導入してみてはどうかと提案いただき、導入を検討することとなりました。

結果として上記のような問題は、Sidekiq Enterpriseの導入により解決することが出来ました🎉

Sidekiq Enterpriseの導入方法

ではSidekiq Enterpriseの具体的な導入方法について書いていきます✍

Sidekiq Enterprise申し込み

導入にあたってまずは、Sidekiq Enterpriseの下記のページから申し込みを行います。

https://billing.contribsys.com/sent/new.cgi

金額は100スレッドで月額$179(2020/03/19現在)です。スレッド数が増えていく毎に金額があがっていきます💸

You can use Sidekiq Enterprise with any number of apps and processes and machines as long as their total worker thread count in production is <= the licensed amount. Development and staging environments are free and unlimited. https://github.com/mperham/sidekiq/wiki/Commercial-FAQ

この金額に影響を与えるスレッド数は本番環境で実行されているスレッド数となっているようでstagingやdevelopmentといった本番以外の環境は自由に使うことができます。

申し込みを行うとSidekiq Enterpriseのinstall時の認証に必要なキー情報がメールにて送付されます 📩

Sidekiq Enterpriseのインストール

Sidekiq Enterpriseをアプリケーションに導入する場合は下記のようにGemfileに追記します。

source "https://enterprise.contribsys.com/" do
  gem 'sidekiq-ent'
  gem 'sidekiq-pro'
end

そして下記のようにbundle configまたは環境変数に申込時に受け取った認証用のキー情報を設定します。

export BUNDLE_ENTERPRISE__CONTRIBSYS__COM=foo:bar
# or
bundle config --local enterprise.contribsys.com foo:bar

上記のGemfileと認証用のキー情報の設定が完了したらbundle installを実行することでSidekiq Enterpriseを導入することができます 🎉

※導入したい機能によっては、initializer/sidekiq.rb等で起動時に有効化する必要があるものもございますので、Wikiを読んで導入方法を確認することをおすすめします。

ActiveJobからSidekiq::Wokerへ書き換え

Sidekiq Enterpriseの全ての機能を利用するためにはActiveJobではなくSidekiq::Wokerを使用する必要があります。そのため弊社ではSidekiq Enterpriseの機能を利用したいJobまたは新規のJobについては、ActiveJobではなくSidekiq::Workerをincludeする形式で実装するようにしています。

# before
class MyJob < ApplicationJob
  queue_as :default
  
  def perform(*_args)
    # something logic
  end
end

# after
class MyJob
  include Sidekiq::Worker
  sidekiq_options queue: :default
  
  def perform(*_args)
    # something logic
  end
end

ActiveJobを継承したJobをSidekiq::Workerをincludeする形式に修正するにあたって、引数でActiveRecordのオブジェクトを受けるような形式になっている場合には注意が必要です。

The arguments you pass to perform_async must be composed of simple JSON datatypes: string, integer, float, boolean, null(nil), array and hash. https://github.com/mperham/sidekiq/wiki/Best-Practices#1-make-your-job-parameters-small-and-simple

ActiveJobは良しなに引数のオブジェクトをシリアライズしてくれますが、SidekiqではWikiに記載の通り引数の値をto_sしてRedisにエンキューする都合上、Sidekiq::Workerをincludeしたときのperform_laterに当たるpeform_asyncの引数には単純な値しか渡すことは出来ません。そのため、下記のようにuserではなくuser_idとして取得してUserのオブジェクトを取得するような形で修正が必要となります。

# before
class MyJob < ApplicationJob
  queue_as :default
  
  def perform(user:)
    # something logic
  end
end

# after
class MyJob
  include Sidekiq::Worker
  sidekiq_options queue: :default
  
  def perform(user_id:)
    user = User.find(user_id)
    # something logic
  end
end

これでSidekiq Enterpriseの機能を使う準備が整いました🎉

Sidekiq Enterpriseの活用事例

最後に弊社におけるSidekiq Enterpriseの活用事例としてReliabilityを使ったJob実行の信頼性の向上を紹介いたします。

Reliabilityを使ったJob実行の信頼性の向上

Jobにおける処理の信頼性の担保が課題としてあげられていたので、Sidekiq Proの機能であるReliabilityを使って信頼性の向上を図っています。

Reliabilityとは、Sidekiq Proの機能である信頼性向上のための機能です。クライアント側(エンキューする側)とサーバー側(デキューして実行する側)に機能が追加されています。

https://github.com/mperham/sidekiq/wiki/Reliability

弊社でも下記の2つを活用しています。

  • Redisへのenqueueに失敗した場合にメモリ上にenqueueしておいて、接続可能となったタイミングでenqueueできるReliability Client

  • Sidekiqのプロセスが停止した場合にもRedisを総なめして孤立したqueueを実行するsuper_fetch

ネットワーク障害等によりRedisに一時的に接続出来ないために失われていたJobや、実行中にSidekiqのプロセスが停止し孤立してしまったJobの実行を担保出来るようになり、信頼性を向上させることが出来ました🎉

Ent Rolling Restartsを使った安全な再起動

デプロイ時のSidekiqのリスタートによる完了までに長時間掛かるJobの中断を防ぐために、Sidekiq Enterpriseの機能であるEnt Rolling Restartsを使って安全に再起動しています。

通常のSidekiqのリスタートではTSTP+TERMを使ったリスタートを行うと思います。通常であればこの方式で安全に再起動出来るのですが、長時間完了までに掛かるJobの中断を防ぐことは出来ません。

Sidekiq EnterpriseのEnt Rolling Restartsを使うことで、長時間掛かるJobの完了を待って安全に再起動を行うことが出来ます。

There is no limit to the time it can continue running. Upon signalling a rolling restart, a new process will be started to pick up new jobs. https://github.com/mperham/sidekiq/wiki/Ent-Rolling-Restarts

具体的にはRolling Restartsを検知した際に、下記のような形で再起動が行われます。

  • 旧プロセスは新規のJobの実行を停止し、既存のJobの実行が終わったら停止する。
  • 新プロセスが起動して新規のJobの実行を開始する。

弊社でも導入の背景に記載したとおり、長時間完了までに掛かるJobがデプロイ時に中断される問題がありましたが、Ent Rolling Restartsの機能のおかげで現在はデプロイ時にJobの実行有無を確認する必要はなくなりました🎉

おわりに

Sidekiq Enterpriseについて弊社の事例をご紹介しました。もしもSidekiq Enterpriseの導入検討の一助になれば幸いです✨

運用担当とのやりとりやJob実行の信頼性の向上のための内製化コード、なども省けて金額以上のメリットを感じています!

またSidekiq Enterpriseの導入をすすめる中でSidekiqのWikiを読んだのですが、すごく充実した内容になっているので導入に関わらずSidekiqを触っている方は読んで見ると色々と役に立つ内容が多そうでした🙌

それでは👋


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html


CIで稀にSegmentation faultが起きてRubyが死ぬ問題と対応

CTO室SREの@sinsokuです。

先日、弊社のCIで稀によく Segmentation fault が起きるようになりました。

f:id:sinsoku:20200313181753p:plain

_人人人人人人_
> 突然の死 <
 ̄Y^Y^Y^Y^Y ̄

調べてみた

最初は気づかなかったけど、画像の右端のダウンロードっぽいアイコンをクリックすると、実行結果のログを全文見ることができます。

[BUG] Segmentation fault at 0x000056529cd6d5e0
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0059 p:---- s:0312 e:000311 CFUNC  :[]
c:0058 p:0016 s:0307 e:000306 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/execution_wrapper.rb:105
c:0057 p:0004 s:0303 e:000302 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/execution_wrapper.rb:83
c:0056 p:0008 s:0298 e:000297 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/reloader.rb:72
c:0055 p:0011 s:0294 e:000293 BLOCK  /home/circleci/*******/vendor/bundle/gems/activejob-5.2.3/lib/active_job/railtie.rb:27 [FINISH]
c:0054 p:---- s:0289 e:000288 CFUNC  :instance_exec
c:0053 p:0145 s:0283 e:000282 BLOCK  /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:118
(途中略)
c:0008 p:0022 s:0029 e:000028 BLOCK  /home/circleci/*******/spec/jobs/conference_mail_sending_job_spec.rb:89
c:0007 p:0003 s:0026 e:000025 BLOCK  /home/circleci/*******/spec/support/multithreaded.rb:5
(以下略)

どうやらマルチスレッドに関する何かで問題が起きているっぽい。

再現した

とりあえず、手元で20回くらい実行しても稀に死ぬのは分かった。

$ for n in $(seq 1 20); do \
    bundle exec rspec spec/jobs/conference_mail_sending_job_spec.rb:96; \
  done

調べてみた

  • 100%再現させる方法が分からない
  • エラーの起きるActiveSupport::ExecutionWrapperに怪しいコードはない
  • Thread についてあまり詳しくない

調べたけど、何も分からない...

ruby-jp で相談した

f:id:sinsoku:20200313181953p:plain

相談したら、少し経ってシンプルな再現コードが見つかった。ありがたい。

f:id:sinsoku:20200313182030p:plain

その後、笹田さんが原因と100%再現するコードを投稿。(すごい)

f:id:sinsoku:20200313182043p:plain

そして、いつの間にか笹田さんが問題を解決するパッチをコミットし、Issueの登録も済んでいた。(すごい)

https://bugs.ruby-lang.org/issues/16676

どうやら、 #hash の実行中に他スレッドから同じHashを弄ると問題が起きるようです。

テストコードの修正

すでにRubyのmasterブランチでは修正されていますが、CIで2.8.0-devを使うわけにもいきません。

Rubyの新しいバージョンがリリースされるまでのワークアラウンドとして、Railsにパッチを当てる事で対応します。

まず、以下の内容で lib/patches/fix_execution_wrapper.rb を作成します。

# frozen_string_literal: true

raise('Consider removing this patch') if RUBY_VERSION != '2.6.5'

module Patches
  # Rubyが稀にSegmentation faultでエラーになる問題を修正するパッチ。
  #
  # `Thread.current` の代わりに `Thread.current.object_id` を使うこと
  # で#hashの実行時に他スレッドがテーブルを弄るのを避けます。
  #
  # 元の実装は以下を参照してください。
  # ref: https://github.com/rails/rails/blob/v6.0.2.1/activesupport/lib/active_support/execution_wrapper.rb
  #
  # ## Issue
  #
  # `#hash` can change Hash object from ar_table to st_table
  # ref: https://bugs.ruby-lang.org/issues/16676
  module FixExecutionWrapper
    def self.active?
      @active[Thread.current.object_id]
    end

    def run!
      self.class.active[Thread.current.object_id] = true
      run_callbacks(:run)
    end

    def complete!
      run_callbacks(:complete)
    ensure
      self.class.active.delete Thread.current.object_id
    end
  end
end

ActiveSupport::ExecutionWrapper.prepend(Patches::FixExecutionWrapper)

このパッチを config/environments/test.rb で読み込む。

Rails.application.configure do
  # 中略
end

require 'patches/fix_execution_wrapper'

これで本当に直るかは自信なかったのですが、1週間くらいCIの様子をみていても Segmentation fault が起きませんでした。
たぶん大丈夫です。

まとめ

自分1人で調べていても全く再現コードを作れなかったし、再現コードを見ても原因に検討もつきませんでした。

  • ruby-jpに感謝
  • 笹田さんすごい
  • ThreadとRubyは難しい

もしスレッド周りで同じ問題を踏んだとき、この記事が参考になれば幸いです。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html