
## 概要

社内の新規アプリケーション開発時にマルチテナント対応をしたいという話になり、Railsでそれを実現するGemを選定して実装した際の振り返り

## 背景

PostgresqlのRLS([Row Level Security](https://www.postgresql.jp/document/9.6/html/ddl-rowsecurity.html))も考慮してテナントごとのデータを安全に扱いたかったため、それを前提にGemを探した

RLSのGemは [https://github.com/suus-io/rls_rails](https://github.com/suus-io/rls_rails) も候補としてあったが、DSLみが強くconfigが複雑になりそうだったので不採用。

色々探した結果、SmartHRさんがRLSのGemを公開したという[記事](https://tech.smarthr.jp/entry/2022/02/15/202241)を読んで、結果的にそのGem ([https://github.com/kufu/activerecord-tenant-level-security](https://github.com/kufu/activerecord-tenant-level-security)) を採用。

採用したGemが [https://github.com/citusdata/activerecord-multi-tenant](https://github.com/citusdata/activerecord-multi-tenant) でのマルチテナント実装を推奨していたため、それを元に進めた。

## 詳細

まず[usage](https://github.com/kufu/activerecord-tenant-level-security#usage)に書かれているようにconfigでテナント分離できる設定を追記。

```ruby
TenantLevelSecurity.current_tenant_id { MultiTenant.current_tenant_id }
```

その後下記手順で動作確認を行なった。

- テスト用のテーブルをマイグレーション（tenant_idをカラムにもたせる）
- テストレコードのINSERT
- Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成
- テストユーザーでのコネクション確立
- テナント分離動作確認

### 手順1: テスト用のテーブルをマイグレーション

usageに従いpolicyをテーブルに付与（tenant_idのカラムも持たせる）してマイグレーション

```ruby
class CreateEmployee < ActiveRecord::Migration[6.0]
  def change
    create_table :employees do |t|
      t.integer :tenant_id
      t.string :name
    end
    create_policy :employees
  end
end
```

DB側でもpolicyが付与されていることを確認

```plaintext
development=# d employees
                  Table "public.employees"
  Column   |         Type          | Collation | Nullable |               Default
-----------+-------------------+-----------+----------+---------------------------------------
  id       | bigint           |           | not null | nextval('employees_id_seq'::regclass)
  tenant_id | integer         |           |          |
  name      | character varying |           |          |
Indexes:
  "employees_pkey" PRIMARY KEY, btree (id)
Policies (forced row security enabled):
  POLICY "tenant_policy"
    USING (((tenant_id)::text = current_setting('tenant_level_security.tenant_id'::text)))
    WITH CHECK (((tenantid)::text = currentsetting('tenant_level_security.tenant_id'::text)))
```

### 手順2: テストレコードのINSERT

```ruby
2.times do |i|
  Employee.create(tenant_id: i+1, name: "e#{i+1}")
end;nil
```

この段階ではテナント分離されておらず全レコード取得できる

```plaintext
irb(main):003:0> Employee.all
  (0.2ms) SET tenant_level_security.tenant_id TO DEFAULT
  Employee Load (0.6ms)  SELECT "employees".* FROM "employees"
=> [#<Employee:0x0000ffffb2ef9770 id: 1, tenant_id: 1, name: "e1">, #<Employee:0x0000ffffb2c8acf0 id: 2, tenant_id: 2, name: "e2">]
```

### 手順3: Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成

テストユーザーにはSELECTだけ付与

```plaintext
$ CREATE USER user WITH PASSWORD 'password';
$ c development;
$ GRANT SELECT ON employees To user;
```

### 手順4: テストユーザーでのコネクション確立

ActiveRecordの[establish_connection](https://api.rubyonrails.org/classes/ActiveRecord/ConnectionHandling.html#method-i-establish_connection)を利用してテストユーザーでコネクション確立

```plaintext
irb(main):017:1* app_user_config = {
irb(main):018:1*   adapter: "postgresql",
irb(main):019:1*   encoding: "UTF8",
irb(main):020:1*   database: "development",
irb(main):021:1*   username: "user",
irb(main):022:1*   password: "password",
irb(main):023:1*   host: "db",
irb(main):024:1*   port: 5432,
irb(main):025:0> }
=> {:adapter=>"postgresql", :encoding=>"UTF8", :database=>"development", :username=>"user", :password=>"password", :host=>"db", :port=>5432}
irb(main):026:0> ActiveRecord::Base.establish_connection(app_user_config)
```

### 手順5: テナント分離動作確認

tenant_idが1のレコードのみ返却される

```plaintext
irb(main):016:1* TenantLevelSecurity.with(1) do
irb(main):017:1*   Employee.pluck(:name)
irb(main):018:0> end
  (0.9ms) SHOW tenant_level_security.tenant_id
  (0.5ms) SET tenant_level_security.tenant_id TO DEFAULT
=> ["e1"]
```

これだけではまだ使い物にならないので、実装時に裏側でコネクション確立するような実装や明示的にコネクション抜ける方法も考えないといけない。

## まとめ

RLSという単語を初めて知ったので新しい知見を得られた。Gemの選定も運用を考えた現実的なラインで判断できたので良い経験になった。


マルチテナント対応のGemに触れた話


## 概要

CTIで設計したテーブルをアプリケーションに落とし込むために[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)を利用したのでその振り返り

## 背景

- サブクラスごとに異なるカラムを使う前提があった
- 今後の拡張時に既存処理の影響を与えずにロジックを記述できるようにしたかった
- そのため、STIよりかはCTI（MTI）的にサブクラスごとにテーブルを分けてその状態を実現したかった
- STIのような共通インターフェースでサブクラスにアクセスしたかった

要は、サブクラスごとにテーブルを分けたいけれど、STIのように共通インターフェースでサブクラスにアクセスしたかった。

最初は[https://max.engineer/mti#multiple-table-inheritance-simulated](https://max.engineer/mti#multiple-table-inheritance-simulated)などを見て、メタプロで実現しようと考えていた。

ただ、納期が迫っていたのでメタプロでやり切れるのか不明瞭だったのと、今後の保守性 / 拡張性まで考えると懸念があった。

調査した結果、[https://stackoverflow.com/a/63273663](https://stackoverflow.com/a/63273663) でどうやらMTIがRails6.1.0からネイティブサポートされたという情報を見つけた。それが[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)。

メタプロよりネイティブサポートされた機能を使う方がベターだと考え、これを使って実装をしていこうと決断。（そのためにRailsのバージョンまで上げた）

## 詳細

[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)は委譲（Delegate）を使って、スーパークラスから具象サブクラスへアクセスできるようにしている。

クラス設計は下記のようになる。

まず、スーパークラスとしてEntryが存在しており、具象サブクラスとして`Message` / `Comment`が存在している。

スーパークラスには`delegated_type`の宣言をしており、サブクラスには`Entryable`モジュールをincludeしている。

```ruby
# Schema: entries[ id, account_id, creator_id, created_at, updated_at, entryable_type, entryable_id ]
class Entry < ApplicationRecord
  belongs_to :account
  belongs_to :creator
  delegated_type :entryable, types: %w[ Message Comment ]
end

module Entryable
  extend ActiveSupport::Concern
  included do
  has_one :entry, as: :entryable, touch: true
  end
end
```

```ruby
# Schema: messages[ id, subject, body ]
class Message < ApplicationRecord
  include Entryable
end

# Schema: comments[ id, content ]
class Comment < ApplicationRecord
  include Entryable
end
```

スーパークラスの`entryable_id`に具象サブクラスのプライマリID、`entryable_type`にサブクラスのtypeが格納される。

スーパークラス側の`delegated_type`メソッドの`types`オプションで許可するtypeを定義できる。

上記例では、`Message`と`Comment`typeのみ許可することになっている。

この時、スーパークラスとサブクラスのレコードは下記のようになっている。

```plaintext
[1] pry(main)> Entry.first
=> #<Entry:0x0000ffff7c3996b8
    id: 1,
    account_id: 1,
    creator_id: 1,
    entryable_id: 1,
    entryable_type: "Comment"
    created_at: Wed, 26 Oct 2022 07:04:34 UTC +00:00,
    updated_at: Mon, 28 Nov 2022 05:42:32 UTC +00:00,
    >
    [1] pry(main)> Comment.first
=> #<Comment:0x0000ffff7c3996b8
    id: 1,
    content: "content"
    >
```

これにより、下記のようにスーパークラスから`entryable`インターフェースを経由して具象サブクラスにアクセスできる。（ifによるtype分岐などは必要としない。尋ねるな命じよ(Tell, Don't Ask!)）

```ruby
Entry.first.entryable
# => Comment.first

Entry.first.entryable.id
# => Comment.first.id

Entry.first.entryable.content
# => Comment.first.content
```

## まとめ

[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html) を選定することで新たな知見を得られたのが良かった。

STIとCTIの違いを抑えられただけでなく、Railsのアップグレード（[こちら](https://kdevlog.com/posts/7oo2u06co)の記事）についても知見を得られたのもGood。


Delegated typesを利用した際の知見


## 概要

自分の会社でproduction運用しているアプリケーションのRailsバージョンをアップグレードした際の振り返り

## 背景

新機能追加にあたってCTIでテーブル設計をして、[ActiveRecord::DelegatedType](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)（以下DelegatedType）を利用したかった

ただ、DelegatedTypeはRails6.1.0からしか利用できないので、アップグレードが必要だった

## 詰まったこと

- `GLIBC_2.29`以上が必要だった
  - それに伴いRubyのバージョンをアップグレード
- PostgreSQLのバージョンが見当たらなかった

## GLIBC_2.29以上が必要だった

Railsを6.0.2から6.1.0にアップグレードした際、`nokogiri`インストール時に`GLIBC_2.29`がないと怒られた

```plaintext
ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:
  /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so) - /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so
  If that's the case, then please install Nokogiri via the `ruby` platform gem:
    gem install nokogiri --platform=ruby
  or:
    bundle config set force_ruby_platform true
```

アプリケーションのRubyイメージ（`2.6.7-slim`）では、GLIBCが2.28であることから、GLIBC2.29以上が同梱されたイメージを利用する必要があった

そのため、Rubyのアップグレードも同時に行いイメージを`2.7.6-slim`にして、GLIBCを2.31にしたらinstallに成功

```plaintext
# ldd --version
ldd (Debian GLIBC 2.31-13+deb11u4) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
```

良い機会だからRubyのアップグレードまで行ったが、GLIBCの指定バージョンをインストールするだけでも良かった

## PostgreSQLのバージョンが見当たらなかった

修正前は`deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main`で探していたが見つからないと怒られる

```plaintext
#5 33.87 Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
#5 34.28 OK
#5 35.11 cat: /tmp/Aptfile: No such file or directory
#5 35.11 Reading package lists...
#5 35.42 Building dependency tree...
#5 35.52 Reading state information...
#5 35.57 E: Unable to locate package postgresql-client-11
```

Rubyのimageを変えたのでDebianバージョンが変わったから見つからないのではと考えたらその通りだった

```plaintext
$ docker run --rm ruby:2.7.6-slim sh -c "cat /etc/*-release"
Unable to find image 'ruby:2.7.6-slim' locally
2.7.6-slim: Pulling from library/ruby
3d898485473e: Already exists
755e58a55855: Already exists
68a9083723f3: Already exists
b8edf3cdc5de: Already exists
93fc5708079e: Already exists
Digest: sha256:86f0a40ff15ddb9fbdc0a64bcf9ad4e048fec31a3e538a79a526b0461fca9bf8
Status: Downloaded newer image for ruby:2.7.6-slim
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUGREPORTURL="https://bugs.debian.org/"
```

`bullseye`だったので、`deb http://apt.postgresql.org/pub/repos/apt/ bullseye-pgdg main`で探すと見つかった

## まとめ

本番稼働しているアプリケーションのFWバージョンを上げるのは中々できないと思うのでとても良い経験になった
色々と詰まってしまったが、自分で一つ一つ調査して解決できた経験を次に活かしたい


Railsアップグレードをした際の知見


## 概要

STIとポリモーフィック関連の理解が混同していたので改めて整理した記事。

## STIとは

1つのテーブルを継承して複数のモデルを表現する形式。

### 具体例

carsテーブルとtrainsテーブルがvehiclesテーブルを継承すると仮定する。

クラス間の関係性は下図のようになる。

![STI Models](/images/sti_models.png)

STIはテーブル一つで表現するため、DBに存在するテーブルはvehiclesテーブルのみ。

![STI Table](/images/sti_table.png)

vehiclesテーブルのtypeカラムを使って、trains or carsの判別をする。

### メリット

- テーブルが増えない
- Railsの場合だと[STIをサポートしている](https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html)ので実装容易性がある
- サブクラスのレコードを取得するためにJOINする必要が無い

### デメリット

- カラム数が多くなる
- 別のサブクラスで利用しなければnull値が増える
- 特定のサブクラスのみを参照すべき他テーブルの外部キー制約が、誤ったサブクラスを参照することを防げない

### 参考

[https://qiita.com/yebihara/items/9ecb838893ad99be0561](https://qiita.com/yebihara/items/9ecb838893ad99be0561)

## ポリモーフィック関連とは

複数のモデルから同じモデルを参照する際の関連付けの仕組み。

多態性という言葉より複数のモデルに対して共通のインターフェースを設けられる。

[https://guides.rubyonrails.org/association_basics.html#polymorphic-associations](https://guides.rubyonrails.org/association_basics.html#polymorphic-associations)

### 具体例

ProductモデルとEmployeeモデルはPictureモデルを参照すると仮定（railsガイドそのまま）

```ruby
class Picture < ApplicationRecord
  belongs_to :imageable, polymorphic: true
end

class Employee < ApplicationRecord
  has_many :pictures, as: :imageable
end

class Product < ApplicationRecord
  has_many :pictures, as: :imageable
end
```

picturesテーブルには参照元の親テーブルを表すカラム（`imageable_id` / `imageable_type`）を持たせる。

```ruby
class CreatePictures < ActiveRecord::Migration[7.0]
  def change
    create_table :pictures do |t|
      t.string  :name
      t.bigint  :imageable_id
      t.string  :imageable_type
      t.timestamps
    end
    add_index :pictures, [:imageable_type, :imageable_id]
  end
end
```

`@picture.imageable`を介して親テーブルにアクセスできる。

`@picture`がどの親に紐づいているかどうかの分岐が必要ない。（typeによる分岐等）

### メリット

- DRYに書ける
  - 中間テーブルを省いて相互に関連付けが可能
  - 共通インターフェースで関連付けが可能

### デメリット

- 外部キーを貼れないので参照整合性制約が担保されない

## まとめ

ポリモーフィックとSTIの言語の意味を考えると自然とどちらか分かる。

言語の意味をしっかり抑えようと思った。


STIとポリモーフィック関連の整理


## 概要

先日社内のPRコードレビューを受けて、`Array#include?`より`Set#include?`の方が高速だということを知った

その時にソースを追ってみたまとめ

## 要約

- `Array#include?`は計算量が`O(n)`
- `Set#include?`は計算量が`O(1)`

## Array#include?

```c
VALUE
rb_ary_includes(VALUE ary, VALUE item)
{
  long i;
  VALUE e;
  for (i=0; i<RARRAY_LEN(ary); i++) {
    e = RARRAY_AREF(ary, i);
    if (rb_equal(e, item)) {
      return Qtrue;
    }
  }
  return Qfalse;
}
```

refs. [https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430](https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430)

```c
/**
 * This function is an optimised version of calling `#==`. It checks equality
 * between two objects by first doing a fast identity check using using C's
 * `==` (same as `BasicObject#equal?`). If that check fails, it calls `#==`
 * dynamically.  This optimisation actually affects semantics, because when
 * `#==` returns false for the same object obj, `rb_equal(obj, obj)` would
 * still return true.  This happens for `Float::NAN`, where `Float::NAN ==
 * Float::NAN` is `false`, but `rb_equal(Float::NAN, Float::NAN)` is `true`.
 *
 * @param[in] lhs          Comparison LHS.
 * @param[in] rhs          Comparison RHS.
 * @retval     RUBY_Qtrue   They are the same.
 * @retval     RUBY_Qfalse  They are different.
 */

VALUE rb_equal(VALUE lhs, VALUE rhs);
```

refs. [https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178](https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178)

説明によるとオブジェクト同士の比較ということ

```ruby
describe "rb_equal" do
  it "returns true if the arguments are the same exact object" do
    s = "hello"
    @o.rb_equal(s, s).should be_true
  end
  it "calls == to check equality and coerces to true/false" do
    m = mock("string")
    m.should_receive(:==).and_return(8)
    @o.rb_equal(m, "hello").should be_true
    m2 = mock("string")
    m2.should_receive(:==).and_return(nil)
    @o.rb_equal(m2, "hello").should be_false
  end
end
```

refs. [https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779](https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779)

念の為テストも確認して同値比較メソッドであることを確認

つまり`Array#include?`は1つずつ同値比較をしているので計算量が`O(n)`

## Set#include?

```ruby
# Returns true if the set contains the given object.
#
# Note that <code>include?</code> and <code>member?</code> do not test member
# equality using <code>==</code> as do other Enumerables.
#
# See also Enumerable#include?

def include?(o)
  @hash[o]
end
alias member? include?
```

refs. [https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406](https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406)

hashでのアクセスにより `O(1)`の計算量を実現していることが分かった

ちなみにSetはイニシャライズでhashとして扱われている

```ruby
def initialize(enum = nil, &block) # :yields: o
  @hash ||= Hash.new(false)
  enum.nil? and return
  if block
    do_with_enum(enum) { |o| add(block[o]) }
  else
    merge(enum)
  end
end
```

refs. [https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255](https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255)


Kdevlog

マルチテナント対応のGemに触れた話

Delegated typesを利用した際の知見

Railsアップグレードをした際の知見

STIとポリモーフィック関連の整理

SetとArrayのinclude?の違い