
## 概要

仕事でDBコネクションプールの適切な数について調査したのでそれの振り返り

## 事象

稼働しているアプリケーションで下記のエラーが発生してしまった。

```plaintext
could not obtain a connection from the pool within 5.000 seconds (waited 5.002 seconds); all pooled connections were in use (ActiveRecord::ConnectionTimeoutError)
```

重いクエリが発行されてコネクションを占有してしまっており、それがコネクションの最大値だったので他のスレッドでコネクションを獲得しようとして、該当エラーが生じてしまった。

## 原因

`pumaのスレッド数 > DBのコネクションプール数` となっていたこと。

明らかにDBのコネクションプールサイズが足りていなかった。

## 最適なコネクションの数について

pumaを利用している場合には、`pumaのスレッド数 = DBのコネクションプール数`であれば良い。

### refs

- https://devcenter.heroku.com/articles/concurrency-and-database-connections
- https://dev.icare.jpn.com/dev_cat/how-do-you-determine-the-number-of-threads-and-connection-pools-for-puma-and-sidekiq-in-rails

ただ、sidekiqのconcurrencyを設定している場合は、DBのコネクションプール数は気をつけた方が良さそう。
Railsのinitializerの中でARを使っていた場合、コネクションが貼られてしまうので `sidekiqのconcurrency = DBのコネクションプール数`だとエラーになるケースもあるとのこと。

ref. https://repl.info/archives/659/


DBコネクションプールサイズについて


## 概要

社内の新規アプリケーション開発時にマルチテナント対応をしたいという話になり、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バージョンを上げるのは中々できないと思うのでとても良い経験になった
色々と詰まってしまったが、自分で一つ一つ調査して解決できた経験を次に活かしたい


Kdevlog

DBコネクションプールサイズについて

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

Delegated typesを利用した際の知見

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