RailsのデザインパターンのひとつにQueryオブジェクトがあります。
これはコントローラからActiveRecordモデルに対する絞り込みなどの操作を、ひとつの責務としてクラスに切り出すパターンです。
コントローラの肥大化を防ぎ、またテストが書きやすくなります。
このQueryオブジェクトについて示します。

## Queryオブジェクトとは

以下、ActiveRecord::Relationを単にRelationと表記します。
Queryオブジェクトは「**Relationに対し結合や絞り込み、ソートなどの操作を定義し、Relationを返すクラス**」です。
ActiveRecordモデルのscopeとして設定することで、チェーンの一部として使用できるようになります。

よく見られるQueryオブジェクトの例として、Relationではなく配列などほかのクラスを返すものがあります。
ただ、クラスやデザインパターンからはインタフェースや返り値が予想できるべきです。
「QueryオブジェクトはRelationを返す」というルールのもとに設計することで、コードの品質が保たれることにつながります。

## Queryオブジェクトの必要性

Queryオブジェクトは「コントローラからクエリ操作の責務を分離し、ActiveRecordモデルと疎結合に保つため」に必要なデザインパターンです。

コントローラからクエリを操作する場合、複雑なクエリは長くなり、肥大化してしまいます。
また正しいRelationが取得できているかのテストが書きづらくなります。
再利用性もありません。

たとえば「1日以内に記事を投稿したユーザの一覧」を取得するコードを見てみます。
コントローラに書くと、次のようになります。

```ruby
class UsersController < ApplicationController
  def index
    @users = User.joins(:posts)
      .where(
        posts: {
          published_at: 1.day.ago..
        }
      )
      .order(created_at: :desc)
  end
end
```

この例ならまだいいですが、これに「PVが100以上の記事を書いたユーザ」「フォロワーが3人以上ついたユーザ」のように条件がふえていくと、コントローラがどんどん肥大化していきます。

コントローラの責務はモデル層に命令を出し、ビュー層にデータを渡すことにあります。
モデル層の操作を組み立てることではありません。
コントローラがモデル層の知識を知りすぎると、モデル層の変更の影響を受けてしまいます。

Queryオブジェクトは、コントローラからクエリ操作の責務を分離し、クラス間を疎結合に保つためのデザインパターンです。

## Queryオブジェクトの例

ここでは、上述したユーザ一覧の例をQueryオブジェクトで書いてみます。

### 動作環境

この記事にあるコードは次の各バージョンで動作を確認しています。

| 名前 | バージョン |
| - | - |
| Ruby | 2.7.1 |
| Ruby on Rails | 6.0.3.2 |

### コントローラ

まず、Queryオブジェクトの使われ方を把握するために、コントローラを見てみます。
コントローラからは次のようにActiveRecordモデルのscopeとして呼び出します。
引数として日付を指定しています。

```ruby
# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def index
    @users = User.recently_posted(3.days)
  end
end
```

### ActiveRecordモデル

次にActiveRecordモデルです。
scopeとしてQueryオブジェクトを渡しています。
AcitveRecordモデルのscopeにすることで、「返ってくるのがそのモデルのRelationである」ことが自明になるというメリットがあります。

```ruby
# app/models/user.rb
class User < ApplicationRecord
  scope :recently_posted, RecentlyPostedUsersQuery
end
```

### Queryオブジェクト

最後にQueryオブジェクトです。
QueryオブジェクトのベースとなるQueryクラスと、それを継承したRecentlyPostedUsersQueryクラスを定義しています。

ActiveRecordモデルのscopeとしてオブジェクトを渡すと、そのオブジェクトの`#call`メソッドが呼ばれます。
これを`#new`に委譲することで、Queryオブジェクトの`#call`が実行される仕組みです。
`#call`に引数を定義することで、コントローラから渡せるようになります。

```ruby
# app/queries/query.rb
class Query
  class << self
    delegate :call, to: :new
  end

  def call
    raise NotImplementedError
  end

  private

  attr_reader :relation
end

# app/queries/recently_posted_users_query.rb
class RecentlyPostedUsersQuery < Query
  DEFAULT_FROM = 1.day

  def initialize(relation = User.all)
    @relation = relation
  end

  def call(from = DEFAULT_FROM)
    relation
      .joins(:posts)
      .where(
        posts: {
          updated_at: from.ago..
        }
      )
  end
end
```

以上となります。
コントローラからRelationに対する操作の責務をひとつのクラスに分離できました。
ActiveRecordモデルに変更があってもコントローラへの影響がなくなり、またテストも書きやすくなりました。

## Queryオブジェクトのルール

以上の内容をもとに、Queryオブジェクトを設計するときのルールについてまとめます。

* ファイルは`app/queries`に配置する
* ベースとなるQueryクラスを定義する
* 接尾辞にQueryをつける
* クラス名から返るRelationが予想できる名前にする
* `#call`を定義し、ActiveRecord::Relationクラスのオブジェクトを返す
* ActiveRecordモデルのscopeをとおして**のみ**使用する。これにより、返るオブジェクトのクラスが自明となる
* `#call`は副作用のないメソッドにする

### アンチパターン

Queryオブジェクトの例として、ひとつのクラスに複数のpublicメソッドを定義する例を見かけます。
これはひとつのクラスに複数の責務をもつことになります。
ある責務の変更が別の責務のメソッドに影響を及ぼすため、避けるべきだと考えます。

ひとつの責務をひとつのクラスに切り出し、単一責任の原則を守って設計することで、保守しやすいコードにすることができます。

RailsのデザインパターンのひとつであるQueryオブジェクトは、コントローラからActiveRecordモデルに対する絞り込みなどの操作を、ひとつの責務としてクラスに切り出すパターンです。コントローラの肥大化を防ぎ、またテストが書きやすくなります。このQueryオブジェクトについて示します。

Railsのデザインパターン: Queryオブジェクト

Ruby on Railsでフォームを扱うとき、ロジックをコントローラやビューに書くとコードの肥大化につながります。
またテストが書きづらく、モデルの変更による影響を受けやすいという問題もあります。

Formオブジェクトを採用することで、コントローラやビューにちらばるロジックをひとつのクラスにカプセル化できます。
ユーザのフォームからの入力を扱うときに採用する価値のあるデザインパターンです。
これについて示します。

## Formオブジェクトとは

まず、この記事におけるFormオブジェクトについて定義します。
Formオブジェクトはモデル層に属するクラス群で、**コントローラ層からユーザの入力を受けとり整形・検証し永続化する責務**をもちます。
また**ビュー層に表示するためのデータを提供する**、という役割もあります。

FormオブジェクトはActiveRecordモデルと1対1の場合もありますが、そうでなくてもかまいません。
複数のActiveRecordモデルの場合もあれば、対応するActiveRecordモデルがない場合にも採用できます。

## Formオブジェクトの必要性

Formオブジェクトはフォームの責務をカプセル化し、コントローラやビューを疎結合に保つために必要なデザインパターンです。

ユーザの入力の整形や永続化をコントローラだけで行うと、コントローラが肥大化してしまいます。
この原因はコントローラがモデル層の知識をもちすぎるためにあります。
このときビューもフォームを表示するための知識をもつことになるため、コントローラと同じような問題が起こってしまいます。
このことは単一責任の原則に反し、**モデル層の変更がコントローラやビューに影響を及ぼす**ことになります。

逆にActiveRecordモデルにこういった責務をもたせると、今度はActiveRecordモデルがフォームの知識を持ちすぎてしまいます。
フォームという独立した責務があるのであれば、これをひとつのクラスにカプセル化する、というのがFormオブジェクトの役割です。

Formオブジェクトにより、コントローラはFormオブジェクトの`#save`のようなたったひとつのインタフェースのみを使うため、クラス間を疎結合に保てます。
ビューもRailsのフレームワークに則った方法でフォームを表示できます。

FormオブジェクトはActiveRecordモデルの`#save`や`#update`のような単純な命令以外のことをするフォームに有用です。
たとえば複数のActiveRecordモデルを操作したり、複数の子レコードをつくるといったものがあたります。
また、フォームのふるまいに関するユニットテストが書きやすいというメリットもあります。

## Formオブジェクトのユースケース

Formオブジェクトは、たとえば次のようなケースに適用できます。
ユーザの入力があり、ActiveRecordモデルの単純な`#save`や`#update`の命令で完結しない処理を行う場合に検討します。

* **サインアップ処理**: ユーザの作成と他ユーザのフォローを同時に行うなど、複数のActiveRecordモデルを作成する
* **複数のタグを作成**: 複数の子レコードを作成するとき。`accepts_nested_attributes_for`を使うような場面だけど使いたくないとき
* **ブログの検索フォーム**: Elasticsearchへのリクエストなど、ActiveRecordモデルを使用しない場合

## Formオブジェクトの例

Formオブジェクトの例を、ブログの記事作成フォームをとおして示します。
全体的な使い方を示せるよう、「作成・更新どちらにも対応」「検証」「複数の子要素を作成」をふまえています。

要件として、記事はタイトルと本文をもち、また複数のタグをもちます。
制約としてタイトルが必須、またタグは1つ以上の入力を必要とします。
これを1つのトランザクション下で行います。

説明しやすいよう、タグはカンマ区切りでひとつの入力欄に記述する形式をとっています。

### 動作環境

この記事で示すコードは、次の各バージョンにおいて動作を確認しています。

| 名前 | バージョン |
| - | - |
| Ruby | 2.7.1 |
| Ruby on Rails | 6.0.3.2 |

### テーブル設計

ブログの記事作成フォームを設計する上で、次のようなテーブルを想定したコード例を示します。

| Table | Column | Type | Not Null |
| - | - | - | :-: |
| posts | id | integer | ◯ |
| | name | string | ◯ |
| | content | text | - |
| tags | id | integer | ◯ |
| | name | string | ◯ |
| taggings | post_id | integer | ◯ |
| | tag_id | integer | ◯ |

### コントローラ

まずコントローラを示し、Formオブジェクトのインタフェースを確認します。
その上でFormオブジェクト、ビューを示していきます。
なお、ActiveRecordモデルやルーティング、例外処理など、本質でないコードは省略しています。

次のコードは記事の作成・編集を行うコントローラです。
フォームを扱うとき、一般的にはActiveRecordモデルのインスタンスをビューに渡しますが、代わりにFormオブジェクトのインスタンスを渡しています。
Formオブジェクトの初期化時に、`#create`と`#update`のときはユーザの入力を渡しています。
また編集画面の`#edit`と`#update`には編集対象となる`@post`オブジェクトを渡しています。

```ruby
class PostsController < ApplicationController
  def new
    @form = PostForm.new
  end

  def create
    @form = PostForm.new(post_params)

    if @form.save
      redirect_to posts_path, notice: 'The post has been created.'
    else
      render :new
    end
  end

  def edit
    load_post

    @form = PostForm.new(post: @post)
  end

  def update
    load_post

    @form = PostForm.new(post_params, post: @post)

    if @form.save
      redirect_to @post, notice: 'The post has been updated.'
    else
      render :edit
    end
  end

  private

  def post_params
    params.require(:post).permit(:title, :content, :tag_names)
  end

  def load_post
    @post = current_user.posts.find(params[:id])
  end
end
```

### Formオブジェクト

次に本題のFormオブジェクトです。
Formオブジェクトは、ユーザの入力と`post`オブジェクトを受け取り、作成・更新処理を行います。

```ruby
class PostForm
  include ActiveModel::Model

  attr_accessor :title, :content, :tag_names

  validates :title, presence: true
  validates :split_tag_names, presence: true

  delegate :persisted?, to: :post

  def initialize(attributes = nil, post: Post.new)
    @post = post
    attributes ||= default_attributes
    super(attributes)
  end

  def save
    return if invalid?

    ActiveRecord::Base.transaction do
      tags = split_tag_names.map { |name| Tag.find_or_create_by!(name: name) }
      post.update!(title: title, content: content, tags: tags)
    end
  rescue ActiveRecord::RecordInvalid
    false
  end

  def to_model
    post
  end

  private

  attr_reader :post

  def default_attributes
    {
      title: post.title,
      content: post.content,
      tag_names: post.tags.pluck(:name).join(',')
    }
  end

  def split_tag_names
    tag_names.split(',')
  end
end
```

Formオブジェクトのコードについて解説します。
まず[ActiveModel::Model](https://github.com/rails/rails/blob/v6.0.3.2/activemodel/lib/active_model/model.rb)をincludeしています。
これは値の代入やバリデーション、コールバックなど、モデルのふるまいをするための、Formオブジェクトに必要となるモジュールです。

`#initialize`ではFormオブジェクトの値を初期化しています。
`#super`はActiveModel::Modelの`#initialize`を呼び出しており、書き込みメソッド（`#title=`など）を用いて値を代入しています。
つまり、Formオブジェクトで用いる値は書き込みメソッドを定義する必要があります。

また、更新にも対応する場合は`#default_attributes`のように保存済みのレコードをもとに値を設定する必要があります。
更新に対応しない場合は`#initialize`を定義する必要はありません。
この場合はActiveModel::Modelの`#initialize`により自動で値の初期化を行ってくれます。

値に書き込みメソッドだけでなく読み取りメソッドも定義しているのは、**ビューのフォームに必要なため**です。
たとえば`form.text_field :title`は`PostForm#title`から値を取得します。
フォームの内容に応じてメソッドを定義する必要があります。

`#persisted?`と`#to_model`はビューの表示（`#form_with`）に必要なメソッドです。
`#persisted?`は作成・更新に応じてフォームのアクションを`POST`・`PATCH`に切り替えてくれます。
また`#to_model`はアクションのURLを適切な場所（ここでは`posts_path`や`post_path(id)`）に切り替えてくれます。

バリデーションについては、ここでは`presence`のみを検証しています。
ActiveRecordモデルと同じく、`#validate`を用い独自のバリデーションを設定できます。
`errors`オブジェクトにエラーを追加すれば、`#valid?`での検証失敗時にユーザにフィードバックを表示することもできます。

### ビュー

最後にビューについて示します。
次の内容は`posts/_form.html.erb`です。
`posts/new.html.erb`と`posts/edit.html.erb`から`@form`を`form`として渡す想定です。

Formオブジェクトに`#persisted?`と`#to_model`を定義したことで、作成・更新画面に応じてフォームの内容を切り替えてくれます。

```erb
<%= form_with model: form, local: true do |form| %>
  <%= form.text_field :title %>
  <%= form.text_area :content %>
  <%= form.text_field :tag_names %>
  <%= form.submit %>
<% end %>
```

以上です。
これまでの内容で記事を作成・更新でき、あわせて複数のタグを登録できるようになりました。

Formオブジェクトを使わないと、上記のロジックがコントローラやモデル、ビューに散らばることになります。
Formオブジェクトにより、フォームのロジックをひとつのクラスにカプセル化できました。

## Formオブジェクトのルール

これまでの内容をもとに、Formオブジェクトを設計するときのルールについてまとめます。

* [ActiveModel::Model](https://github.com/rails/rails/blob/v6.0.3.2/activemodel/lib/active_model/model.rb)をincludeする
* クラス名は接尾辞を`Form`にする（例：`PostForm`）
* `#save`や`#search`など、クラス名から推測可能な単一の処理用メソッドを定義する。失敗時に`false`を返す
* `#persisted?`と`#to_model`に反応するようにする
* バリデーションを実装する。ただしActiveRecordモデルとの整合性に気をつける
* Formオブジェクトがもつべき責務を明確にし、肥大化しないようにする。たとえばレコード作成時にメールで通知するのはモデル層でなくコントローラ層で行う

Formオブジェクトは、コントローラやビューにちらばるフォームのロジックをひとつのクラスにカプセル化します。ユーザのフォームからの入力を扱うときに採用する価値のある、Ruby on Railsのデザインパターンのひとつです。このFormオブジェクトについて示します。

Railsのデザインパターン: Formオブジェクト

機密情報管理サービスとは、ひとことでいうと機密情報のためのキーバリューストアです。
代表的なものとして[AWS Secrets Manager](https://aws.amazon.com/jp/secrets-manager)や[Systems Managerパラメータストア](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-parameter-store.html)、[Hashicorp Vault](https://www.vaultproject.io)があります。
TerraformやAnsibleなどでインフラを構築するときに、機密情報管理サービスを用いることで安全性を高めることができます。

この記事では上記3つのサービスについて、Infrastructure as Codeの文脈で比較します。
またプロダクトにあった選び方について述べます。

## 用語の定義

まず、この記事における用語の定義について示します。

### 機密情報とは

機密情報とは「意図しない第三者に知られると悪用されるおそれのある情報」をいいます。
パスワードやAPIキーなどがあてはまります。
機密情報が漏洩すると、たとえばサーバに不正にアクセスされ、個人情報を取得されるおそれがあります。
あるいは、クラウドリソースを消費され、巨額の費用を請求されるかもしれません。

機密情報をソースコード内に直接記述すると、バージョン管理システムをとおして意図しない人に公開される可能性があります。
機密情報管理サービスを用いることで、このような問題を防ぐことにつながります。

### 機密情報管理サービスとは

機密情報管理サービスとは「機密情報を暗号化し、安全に保管した上で、権限をもったユーザにAPIをとおして提供する機能をもつキーバリューストア」です。
パスベースのものが広く使われており、たとえば次のようにパスをキーとして値を格納します。

| キー | 値 |
| -: | :- |
| `/example-com/production/google-api-key` | `abcde…` |

値はAES-256などのアルゴリズムで暗号化されます。
AWSなどの信頼できるマネージドサービスを用いることで、暗号化された値を安全に保管できます。
また、値へのアクセス権限をポリシーにより管理する仕組みがあります。

## 機密情報管理サービスの要件

機密情報管理サービスには代表時なものにSecrets Managerとパラメータストア、Vaultがあると述べました。
これらサービスがIaCという文脈で満たすべき要件として、次のことがあります。

1. 暗号化されること
2. 安全に保管されること
3. アクセス権限を管理できること
4. APIにより情報を取得できること

この4つの項目を上記サービスはすべて満たしています。
たとえば暗号化について、Secrets ManagerとパラメータストアはAWS Key Management Service (KMS)、VaultはAES-256を用いて暗号化します。

機密情報が保管されるストレージバックエンドについては、Secrets Managerとパラメータストアはマネージドになります。
VaultはS3やAzure、PostgreSQLなどクラウドやリージョン、ストレージを自由に選択できます。

権限管理について、Secrets ManagerとパラメータストアはAWS Identity and Access Management (IAM)によりポリシーベースでアクセス権限を管理できます。
Vaultもポリシーを[HCL](https://github.com/hashicorp/hcl)で定義できます。

## 比較項目

次にプロダクトにあったサービスを選ぶ基準として、コスト、シークレットローテーション、パスワード生成という3つの項目で上記サービスを比較します。

| 項目 | Secrets Manager | パラメータストア | Vault |
| -: | :-: | :-: | :-: |
| コスト | 有料 | 基本的に無料 | 無料/有料 |
| シークレットローテーション | ◯ | - | ◯ |
| パスワード生成 | ◯ | - | ◯ |

まずコストについて、Secrets Managerは機密情報1つにつき$0.4/月、また10,000回のAPIコールあたり$0.05かかります。
パラメータストアは標準パラメータは無料、アドバンストパラメータは機密情報1つにつき$0.05/月かかります。
機密情報の基本的なユースケースにおいては標準パラメータの利用で問題ありません。
パラメータの種類については「[パラメータ層の管理](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/parameter-store-advanced-parameters.html)」をお読みください。

VaultはOSSを利用する場合はサーバ代やメンテナンスコストがかかります。
SaaS版は問い合わせによる料金開示となります。

シークレットローテーションとは、機密情報を定期的に自動で変更する機能で、安全性の向上に役立ちます。
Secrets ManagerとVaultが対応しています。
パスワードを生成する機能もSecrets ManagerとVaultのみが対応しています。

## サービスごとの特徴

上記比較項目以外にも、サービスごとの特徴があります。
機密情報管理サービスを選ぶ上での重要なポイントになります。
以下に特徴を示します。

### Secrets Manager

Secrets ManagerのシークレットローテーションはAmazon RedshiftといったAWS各サービスと統合しやすいという特徴をもっています。
また、Amazon VPCエンドポイントをサポートしているため、機密情報がパブリックインターネットに送信されることを防げます。

そのほか、AWS CloudTrailを用いてログ監査ができます。
CloudWatchやIAMとの統合もしやすいです。
また、Secrets ManagerにはSLA99.9%が設定されています。

### パラメータストア

Secrets Managerと同じくVPCエンドポイントをサポートしていたり、CloudTrailやIAMなどと統合することができます。
SLAは標準パラメータには設定されていませんが、アドバンストパラメータにはSecrets Managerと同じレベルが設定されています。

スロットルについて、パラメータストアは1秒間に最大1,000リクエストがサポートされています。
インフラ構築という文脈では十分な数値といえます。

### Vault

Vaultのアーキテクチャはバックエンドストレージを信頼しておらず、Vaultサーバをとおるすべてのデータはセキュリティバリアという機構により自動的に暗号化されます。
セキュリティバリアからデータが読みとられると改ざんが検出されるなど、安全性を高める仕組みがあります。

またVaultサーバへのアクセスキーはShamir's Secret Sharingというアルゴリズムで分割されます。
これを複数の端末に配置することで、安全性を向上させることができます。

VaultにはDynamic Secrets: 有効期限つきの認証情報を動的に生成して安全性を高める機能があります。
たとえば有効期限つきのIAMユーザを作成できます。

## 選び方

パラメータストアはInfrastructure as Codeに必要な最低限の機能をもっています。
無料で使用できるため、パラメータストアをベースに考えます。

シークレットローテーションやパスワード生成の機能が必要で、AWSのその他サービスを利用しており、かつ有償サービスも採用可能な場合はSecrets Managerが候補になります。

Vaultはもっとも高機能ですが、その分学習コストがかかります。
OSS版の場合は運用コストも考慮しなければなりません。
セキュリティに対する要件が高かったり、Dynamic SecretsなどVaultでしか対応が難しい機能がある場合にはVaultの採用を検討するとよいでしょう。

Terraformなどでインフラを構築するときに安全性を高めるための機密情報管理サービスについて、AWS Secrets Manager、Systems Managerパラメータストア、Hashicorp Vaultの3つを比較します。

IaCにおける機密情報管理サービス比較: Secrets Manager, パラメータストア, Vault

バッチ処理はプログラムの実行方式のひとつで、まとまった処理を一度に行います。時間がかかる処理や定時処理などに有用で、ビジネス側の要件を満たすために重要な役割をもちます。

このバッチ処理の設計にはいくつか重要なポイントがあります。このポイントについて以下に示します。

## バッチ処理とは

![バッチ処理とは](//images.ctfassets.net/pppgbgujcovf/6eUcA9vLljkbwlCXlhwrpi/6b0129d679076d95d16b84eda778e2b5/about-batch-processing.png)

まず、この記事におけるバッチ処理の定義について示します。バッチ処理とは「入力があり、その入力を加工し出力するプログラム」をいいます。たとえばデータベースから処理対象となるデータを取得し、データを変更した上で更新するプログラムがバッチ処理にあたります。

この処理はなんらかのトリガーによって起動します。たとえば時間がトリガーとなって起動します。

## バッチ処理が満たすべき要件

次にバッチ処理が満たすべき要件を定めます。この記事で示す各ポイントは、次の要件を満たすことを目的とします。

* ビジネス側の要件を満たすこと
* 問題をできるだけ起こさないこと
* 処理の状況を把握できること
* 異常時にリカバリできること
* リソースの消費を抑えること

## 抑えるべきポイント

上記の要件を満たすために、バッチ処理を設計する上で抑えるべきポイントは次のとおりです。各ポイントごとに書いていきます。

1. ビジネス側の要件を明確にする
2. Dry Runできるようにする
3. APIを叩く処理はリトライする
4. 外的要因に依存しないようにする
5. テストコードを書く
6. ログを出力する
7. コミュニケーションツールに通知する
8. 冪等性をもたせる
9. 処理対象を引数で指定できるようにする
10. リソースの消費を減らす

### 1. ビジネス側の要件を明確にする

バッチ処理にはビジネス側の要件があります。いつはじまっていつ終わるのか、どの処理の後にはじめるのか。処理対象はなにか。どういう処理をし、どう出力するのか。こういった要件を明確にした上で設計に入ります。

### 2. Dry Runできるようにする

バッチ処理を実行する際のオペレーションミスを防ぐため、Dry Runの仕組みをとりいれます。

バッチ処理はビジネス上重要な処理であることが多いです。処理対象を間違えるとリカバリをする必要があります。場合によってはメンテナンスモードに入ることになります。これはユーザのUXを低下させてしまいます。

このような問題を防ぐため、処理を実行する前にふるまいをチェックする仕組みをつくります。正しい処理対象に正しい処理が行えるか。これを標準出力をとおして確認できるようにします。

より安全な運用をするために、バッチ処理のデフォルトのふるまいをDry Runにすることも検討します。

### 3. APIを叩く処理はリトライする

APIの利用制限にひっかかるとバッチ処理全体が失敗してしまいます。これを防ぐため、APIを叩く処理はリトライするようにします。

APIによってはRate Limitなどのリクエストに関する制限があります。あるいはAPIが一時的にダウンしているかもしれません。リトライを行うことでことで、処理全体が成功する可能性を高めることができます。

リトライの時間間隔はExponential Backoffという手法が有用です。

### 4. 外的要因に依存しないようにする

処理が外的要因に依存すると、それが利用不能になった場合にバッチ処理全体が失敗してしまいます。可能な限り依存しないようにします。

たとえばバッチ処理内で運用者にSlackで通知したとします。この通知を同期的に行うと、エラーハンドリングしない限りバッチ処理全体が失敗します。通知の失敗が許容できるケースでは失敗してもいいようにします。具体的には非同期での実行などの方法をとります。

### 5. テストコードを書く

バッチ処理も、アプリケーションのコードと同じくテストコードを書きます。このことが問題の防止につながります。

テストコードは処理のふるまいを定義し、テストによって正しくふるまっているかを検証します。これを継続的にテストすることで、バッチ処理の品質を保つことができます。

### 6. ログを出力する

バッチ処理に問題が発生したとき、その調査やリカバリにログを利用します。このためログはバッチ処理において重要な役割を果たします。

ログを設計する際は5W1Hを意識すると効果的です。バッチ処理をいつ開始したか、いつ終了したか。処理対象はなにか。どういう処理を行ったか、行わなかったか。なぜその対象なのか。どの処理か──これは一意の処理IDをログに付与すると、ログ監視ツールで調査しやすくなります。

また、エラーが発生したときはスタックトレースをログに記録します。

### 7. コミュニケーションツールに通知する

バッチ処理の状況を把握するために、処理内の主要なポイントでSlackなどのコミュニケーションツールに通知します。これによりバッチ処理が正しく動作していることを確認できます。問題が発生したときにはすぐ気づくことができ、リカバリ作業に移行できます。

この通知はエンジニア以外のメンバーにもわかりやすい形で通知します。こうすることで、ユーザへのフォローまで含めたリカバリを行うことができます。

### 8. 冪等性をもたせる

バッチ処理は、何度実行しても一度処理した対象を二重に処理しないようにします。「何度実行しても同じ結果が得られる性質」を冪等性といいます。冪等性をもたせることで、処理が失敗したときに再度処理すれば未処理のもののみ処理にかけることができます。

### 9. 処理対象を引数で指定できるようにする

未処理のデータを指定して処理にかけられるよう、処理対象を引数で指定できるようにします。バッチ処理が失敗したとき、処理されたものと未処理のものが出てきます。未処理のもののみ再実行できるとリカバリしやすくなります。

これは冪等性をもたせることが難しいバッチ処理に対して特に効果的です。

また、Dry Runと組み合わせることも有用です。今後実施予定のバッチ処理を、処理対象を指定した上で事前に確認できるようになります。

### 10. リソースの消費を減らす

バッチ処理は、その性質上コンピューティングリソースを消費しやすいです。できるだけ消費を減らせるよう、実装上の工夫をします。

たとえばデータベースにある大量のレコードを扱うとき、全件をメモリ上に展開すると多くのリソースを消費してしまいます。この場合、分割して処理することを検討します。

またトランザクションも有用ですが、大量のデータに対するトランザクションはデータベースリソースの消費につながります。適切な粒度で行う必要があります。

## おわりに

![バッチ処理を設計する上で抑えるべきポイント](//images.ctfassets.net/pppgbgujcovf/6UENtMZ6qz8aN11xADtVnU/4c50c03629cb43f89c0c9ba8f972570e/points-on-designing-batch-processing.png)

以上のポイントを意識して実装することで、ビジネス側の要件を満たしつつ、問題が起きづらいバッチ処理を運用することができます。問題が起きたときにも対処しやすいため、可能な限りポイントを抑えるようにします。

バッチ処理はプログラムの実行方式のひとつで、まとまった処理を一度に行います。時間がかかる処理や定時処理などに有用で、ビジネス側の要件を満たすために重要な役割をもちます。

このバッチ処理の設計にはいくつか重要なポイントがあります。このポイントについて以下に示します。

バッチ処理を設計する上で抑えるべきポイント

「上位のモジュールは下位のモジュールに依存してはならない」という原則。
下位のモジュールに依存すると、モジュールが変更されたときに影響を受けてしまう。
各モジュールの間に抽象クラスを導入し、各モジュールはこの抽象クラスに依存することで、モジュールを疎結合に保てる。

依存性逆転の原則

「クライアントにとって不要なインタフェースに依存することを強制してはならない」という原則。
依存するインタフェースがふえると、インタフェースの変更による影響を受けやすくなる。
責務に応じてインタフェースを分けるよう設計する。

インタフェース分離の原則

「サブクラスはスーパークラスに置き換え可能であるべき」という原則。
置き換えられないということは、つまりサブクラスへの知識をもつということ。
これは密結合の原因となってしまう。
スーパークラスの知識のみをもち、サブクラスは置き換え可能であるように設計することで、クラスを疎結合に保てる。

リスコフの置換原則

「クラスは拡張に対して開いていて、修正に対して閉じているべき」という原則。
コードの変更は、既存のクラスを修正するのではなく、新しくコードを追加することによって行うよう設計する。
これにより既存のクラスが影響を受けなくなる。

オープン・クローズドの原則

「クラスのもつ責務はひとつであるべき」という原則。
責務が複数あると、その責務の数だけクラスを変更する理由が生じる。
このとき、ある責務に対する変更が、関係ない別の責務に影響を与えてしまう。
複数の責務をもつクラスは最小限にし、クラスには単一の責務だけをもたせるよう設計する。

単一責任の原則

Web APIのための規格。
APIリクエストのためのクエリ言語と、APIの仕様を記述するためのスキーマ言語からなる。
必要なリソースのみをクエリに記述するため、結果が予測可能となる。
またひとつのリクエストで多くのリソースを取得できるため、ネットワーク接続が遅い環境下に対応しやすい。

GraphQL

Webページの情報を提供するための標準化されたデータ形式。
Googleがページをクロールする際、より正確に情報を収集できるようになる。
また検索結果に画像などのコンテンツを表示できるようになる。

構造化データ

アプリケーションの実行モデルのひとつで、サーバの運用が不要なモデルのこと。
イベント駆動により、実行に必要なサーバが立ち上がる。
従量課金制によるコスト削減や、サーバのアップデート・スケーリングといった管理が不要になるなどのメリットがある。
これにより開発者がプロダクトの価値向上にリソースを使うことができるようになる。

Posts

Railsのデザインパターン: Queryオブジェクト

Railsのデザインパターン: Formオブジェクト

IaCにおける機密情報管理サービス比較: Secrets Manager, パラメータストア, Vault

バッチ処理を設計する上で抑えるべきポイント

Words

Tags