
## 概要

自分の会社で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とポリモーフィック関連の整理


## 所感

ドメイン駆動設計に関して本格的に学ぼうと思って読んだ1冊
ドメインモデルをうまく表現することの利点や技法などをバラバラだった知識をまとめられた印象
ビジネスドメインを丁寧にモデリングして扱えるようにしたい

## Chapter2

### 「システムに最適な値が必ずしもプリミティブな値であるとは限らない」

ドメイン固有の値をどう扱うと良いのかにフォーカスすることが大事。

イミュータブルであることによりデータの信頼性が向上されるし、それにより交換可能になる。（逆に言うと交換以外で値を変更できない）

クラスとして実装していくことで値オブジェクト固有のバリデーションロジックも内包できるというのも扱いやすくなるポイントかなとも思う。

### 値オブジェクトとして扱う基準

また、値オブジェクトとして扱うべきかどうかの判断基準として「そこにルールが存在しているか」「それ単体で取り扱いたいか」という点を筆者が重視しているという点も印象に残った。

ドメイン内で特別視されている（ドメイン固有の呼び名が付いているなど）の場合は、値オブジェクトになり得るのかなと思った。

値オブジェクトに関しては下記のpodcastもとても参考になる。

[https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0](https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0)

## Chapter3

### 値の同一性

- エンティティは識別子(ID)で同一性を判断
- 値オブジェクトは値で同一性を判断
  - 別のオブジェクトだとしても値が同じであれば同一とみなす

### エンティティの判断基準

「ライフサイクルが存在し、そこに連続性が存在する」ことがエンティティかどうかの基準。

作成されて誕生し、削除されて死を迎える。つまりCRUD処理が発生し得る可変なオブジェクト。

値オブジェクトは不変であるため、エンティティではないということが分かる。

### ドメインオブジェクトを定義するメリット

印象に残ったのは「仕様書というのはマクロな要件については有効であってもミクロな要件については無力であることが多い」ということ。

その通りであるし、そこまで記述する必要がないからそうなっているはず。

だからこそ、コードからその要件を汲み取りやすくしておく必要があるなと再認識した。

クラスにドメインオブジェクトのルールを記述して凝集度は高く保つというのは、ドキュメンテーションという文脈においても重要。

## Chapter4

### サービスへのロジック切り出しはドメインモデル貧血症を引き起こす

ドメインモデルの振る舞いをサービスに切り出しすぎると、ドメインモデルがデータだけを保持している無口なオブジェクトになってしまう。

れによってドメインモデル自身が語るべきことを語っていない状態が出来上がってしまう。

データと振る舞いが点在してしまうことで可読性や保守性に欠けてしまう。

そうならないために、ドメインモデルに不自然な振る舞いのみサービスに切り出すことが重要。

複数のモデルを横断する操作を行う際など、ドメインモデル固有ではないロジックが出てきた場合は検討の余地あり。

## Chapter5

### ビジネスロジックをより純粋なものに昇華する

リポジトリパターンを利用して永続化処理を抽象化して隠蔽することで、ビジネスロジックを簡潔にできる。

自分の会社のフロントエンドアプリケーションはリポジトリパターンを利用しており既知の知識としてある。

だからこそ、今一度下記のようなアンチパターンを実装してしまわないように意識したい。

[https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf](https://qiita.com/mikesorae/items/ff8192fb9cf106262)

## Chapter6

### アプリケーションサービスはオブジェクトの操作に徹する

ドメインロジックの責務外の振る舞いを記述することに徹する。

サービスオブジェクトはロジックが雑多になりがち（ドメインロジックが記述されてる / 責務が複数等）なので、今一度サービスクラスを作る際は注意したいと思う。

[Qiitaのリンク](https://qiita.com/joker1007/items/25de535cd8bb2857a685)

## Chapter7

### 依存を避けるよりコントロールせよ

抽象に依存することが重要。依存関係逆転の原則。

抽象に依存することで変更箇所が最小になる。

改めて思うのは良い設計は変更容易性が担保されていること。

## Chapter12

### オブジェクトの境界線が秩序をもたらす

デメテルの法則（最小知識の原則）を元にコード設計する。

Wikipediaによると、デメテルの法則の基本骨子は下記である。

> 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべき

[デメテルの法則 - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)

つまり、他のオブジェクトの情報（どういう状態/値であるのか等）を知らなくて良いということ。

「尋ねるな、命じろ」というソフトウェアの格言があるが、その通りに設計していけばルールが漏れ出すのを防げる。

変更が面倒な時は大体同じロジックが書かれているので、改めて意識してコードを書いていきたい。

[Qiita](https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B)

## Chapter13

### 仕様オブジェクトがドメインルールの点在を防ぐ

#### 仕様オブジェクトについて

ドメインの重要なルールだが処理が複雑になってしまうロジックを格納するオブジェクト

目的としては、ロジックの点在を防ぐこと。

例えば、こういったロジックはサービス層で実装されがちだが、それだとドメインルールが点在してしまう。

そういった状況を防ぐために仕様オブジェクトでロジックをラップする。

#### リポジトリのフィルターとしても機能する

リポジトリに仕様オブジェクトを渡してメソッドを呼び出すようにすることで、ドメイン知識を記述せずに済むようになる。

```java
// 仕様オブジェクト
public class CircleRecommendSpecification {
  private readonly DateTime executeDateTime;

  public CircleRecommendSpecification(DateTime executeDateTime) {
    this.executeDateTime = executeDateTime;
  };

  public bool IsSatisfiedBy(Circle circle) {
    if(circle.CountMembers() < 10) {
      return false;
    }
    return circle.Created > executeDateTime.AddMonths(-1);
  };
}

// リポジトリ
public class CircleRepository: CircleRepository {
  private readonly ICircleRepository circleRepository;
  private readonly DateTime now;

  public CircleGetRecommendResult GetRecommend(CircleGetRecommendRequest request) {
    var circleRecommendSpecification = new CircleRecommendSpecification(now);
    // リポジトリに仕様を引き渡して抽出(フィルタリング)
    var recommendCircles = circleRepository.Find(circleRecommendSpecification).Take(10).ToList();
    return new CircleGetRecommendResult(recommendCircles);
  };
}
```

## Chapter14

### レイヤーの隔離と責務の分割

本書ではドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することと説明されている。

レイヤードアーキテクチャやクリーンアーキテクチャなどのアーキテクチャも依存の方向を定めて、レイヤーごとに責務を分割している。

ドメイン駆動設計の文脈上で最も重要なのはドメインの隔離を促すこと。

## Chapter15

### 軽量DDDに陥らないこと

デザインパターンなどを盲目的に利用してそれで終わらないこと。

重要なのはドメインの本質に向き合い続けること。

ユーザーを知り対話を続けドメインを改善していくことを意識したい。

## まとめ

依存の方向性 / 責務の分割 / ロジック隠蔽を意識したいと思った。

パターンはある程度分かったが、エリックエヴァンスの書籍を読んで根本的な思想の部分を知りたい。


<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本


## 概要

先日社内の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)


SetとArrayのinclude?の違い


## 概要

発売前から気になっていたこの書籍を読んだので学びをつらつらと書いていく。

自分が業務で担当しているアプリケーションもパフォーマンスがボトルネックとなることがあるので、少しでも何か吸収できれば。

## 1章: チューニングの基礎知識

本書ではリクエストレスポンス一連の動作が完了するまでの時間（RTT: Round Trip
Time）が短いWebサービスを高速なWebサービスと定義している。

Webサービスのキャパシティは単純化すると個々の性能×数になり、それを調整するアプローチは**垂直スケーリング（スケールアップ:
性能UP）**か**水平スケーリング(スケールアウト: 数増やす)**の2種類がある。

パフォーマンスチューニングの基本は下記2点

- ボトルネックだけにアプローチする
- ボトルネックの特定は外側から順番に
  - 2021年の一般的なWebサービスにおいてボトルネックになりがちな箇所はCPU、メモリ、ディスクI/O、ネットワークI/Oとのこと

負荷試験を実施して改善してのサイクルになる。負荷試験と言えるほどちゃんとしたものをやったことが無いな。

## 2章: モニタリング

モニタリングは外形監視と内部監視の2種類がある。

- 外部監視
  - アプリケーションの外側からモニタリングする手法。
  - 外部からリクエストを行って期待通りのレスポンスが返ってくるか確認。
- 内部監視
  - アプリケーション内部からモニタリングする手法。
  - CPU利用率やメモリなどの状態をウォッチ。

本書では[Prometheus](https://prometheus.io/)というPull側のモニタリングツールを使用している。

基本的には内部監視の方が多いんじゃないかなと考える。外部監視だとネットワークの状態に左右されるから再現性が低そう。

## 3章: 基礎的な負荷試験

各種指標をどう見るかが大事。
本書では下記の数値が紹介されており、MySQLのボトルネックになっている箇所を調査していく流れ。
（スロークエリの発見。実行計画を見ていく）

- CPU2コアのうち50%程度が利用されている
- MySQLのプロセス(mysqld) がCPUを100%(1コア)程度利用
- WebアプリケーションのプロセスはCPU1% / Webサーバーのプロセスは0.3%

実務でもスロークエリログがあってCPU使用率が跳ね上がった経験がある。

あのような事象はかなりインシデントにつながるので、普段からパフォーマンスをより意識したい。

## 4章: シナリオを持った負荷試験

この章の内容は自分の勤務先でもやりたい...！

どの画面表示時に遅いのかをシナリオを使って調査して可視化できるのはとても良い。

よりユーザー目線に立ったテコ入れができると感じる。

テスト環境ではデータ量が足りず、どうしてもクライアントのボトルネックに気付けないという問題がある。

ローカルだと開発生産性に影響するのでやりたくないから、それ用の環境を作るとかになるのかな。
コスパとの相談かも

それを事前に検知できる仕組みが欲しい。

書籍だとOSSの[k6](https://k6.io/open-source/)というツールを紹介している。

## 5章: データベースのチューニング

特に印象に残ったのはインデックス周りのこと。二分探索に適した構造であるBツリーについて。

インデックスの走査についてかなり丁寧に説明されていた。

- `Covering Index`
- インデックスを貼る基準として頻繁に使われるカラム。それ以外は「ORDER BY」で並び替えを行うカラムに貼る

### Covering Index について

ref. [https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index](https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index)

> クエリーによって取得されたすべてのカラムを含むインデックス。完全なテーブル行を見つけるためのポインタとしてインデックス値を使用する代わりに、クエリーはインデックス構造から値を返し、ディスク I/O
> を節約します。InnoDB セカンダリインデックスには主キーカラムも含まれるので、InnoDB は MyISAM よりも多くのインデックスにこの最適化方法を適用できます。InnoDB
> は、トランザクションが終わるまで、そのトランザクションによって変更されたテーブルに対するクエリーにこの方法を適用できません。正しいクエリーの場合、どのカラムインデックスまたは複合インデックスでも、カバリングインデックスとして機能できます。可能な場合は必ず、この最適化方法を活用するようにインデックスおよびクエリーを設計してください。

usersテーブルのnameカラムにindexが貼ってあるとする。

これだとidがプライマリーインデックス / nameがセカンダリインデックスとなる。

下記のSQLクエリ結果セットで利用しているカラムはidとnameだけなので`Covering Index`が有効になる。（EXPLAIN結果のExtraにUsing
Indexが付与される。）

これにより、テーブルフルスキャンでなくインデックススキャンのみで結果を返すのでパフォーマンスが良くなる。

`SELECT *`の場合は、全てのカラムにインデックスを貼っていないので `Covering Index` は無効となる。

```sql
SELECT id
FROM users
WHERE users.name = 'hoge'
```

## 6章: リバースプロキシの利用

リバースプロキシが必要な理由としてアプリケーション側のHTTPコネクションでは捌ききれないというものがある。

本書では例としてunicornを利用したRubyアプリケーションのマルチプロセス・シングルスレッドを紹介している。

- クライアントからの1リクエストを1プロセスが処理する。
  - そのプロセスは処理を行なっている間に他のリクエストを処理できない。（プロセス数 = 最大リクエスト数）
    - 大量リクエストの場合、パフォーマンスが極端に低下するC10K問題を抱えている（1万リクエストを受け取ると処理が急激に悪化する問題）
      - プロセス切り替え時のコンテキストスイッチが大量発生。新しいプロセス用のキャッシュ切り替え => 処理悪化
      - 異なるプロセス同士では通常メモリ共有ができないためメモリ使用量が多くなる

このように大量のリクエストを捌くのが難しいので、リバースプロキシでクライアントとのHTTPコネクションを解決する。

代表的なものとしてNginxがある。

マルチプロセス・シングルスレッドは同じだがイベント駆動アーキテクチャであるため、1プロセスが複数クライアントのリクエストを処理できる。

ノンブロッキングI/O（他の処理でのファイル読み書きが完了するまで待たない）と多重I/Oを活用し、イベント駆動でリクエスト・レスポンスを大量に捌くことでC10Kを解決している。

業務でもNginxを利用しているがあまり触っていないため色々と忘れがちなので、適宜振り返っていきたいと思う。

## 7章: キャッシュの活用

この章を読んでキャッシュは慎重に利用したいと感じた。

- 古いデータが表示されるリスク
- 想定外データを表示して情報流出のリスク
- キャッシュミドルウェアがシステムの障害点に
- プログラムの実装が複雑になる

本書ではこのような問題があるのでまずはキャッシュを使わない方法を模索してみようと記述されている。

確かに扱い方によってはリスクを孕んでいる。

また、アプリケーションのインメモリで管理するか外部のミドルウェア（Redis等）で管理するかも考慮ポイント。

- キャッシュの生存時間（TTL）
- Thundering herd problem
  - キャッシュ無い状態で大量リクエスト
    - => キャッシュ生成するまで処理が続くかつ大量リクエスト
    - => パフォーマンス悪化

などの問題をちゃんと考慮しないといけないということを認識できた。

## 8章: 抑えておきたい高速化手法

特に印象深かったものだけ

- 同一ホストへのコネクションを使い回す
  - イテレーションで毎回コネクションを作るなどナンセンス。毎度TCPのハンドシェイクが必要になり大量のオーバーヘッドが発生してしまう。確立したコネクションを変数に入れて使い回すなどの対応が必要
- 適切なタイムアウトを設定
  - 常に通信が成功するとは限らないので、ネットワーク障害などに備えて処理時間上限を設けておかないとそこがボトルネックになる。
- HTTPヘッダーを活用してクライアント側にキャッシュさせる
  - 画像ファイルやCSSファイルなどは更新頻度が低く、参照頻度が高いためCache-Controlヘッダーを活用してキャッシュデータを使いまわせるようにする
  - Cache-Controlヘッダーの期限切れの場合にのみリクエストを行うことで、無駄なリクエストを減らせる
- 静的ファイル配信をリバースプロキシから直接配信する
  - RDBMSに画像データを持たずに静的ファイルにしてNginxから配信させると、無駄な処理を省ける（RDBMSの場合大きなデータを読み込むのでMySQLのメモリを圧迫したり、ネットワーク帯域を圧迫するなど）
- CDN上にHTTPレスポンスをキャッシュする
  - キャッシュしたレスポンスを返すことでアプリケーションサーバーへのリクエストを減らせる。
  - クライアントから近いCDNエッジからレスポンスを直接返せるので、高速な処理が実現できる

最近、CDN周り（特にCloudflare Workers）をちゃんと触ってみたい欲がすごい。

## 9章: OSの基本知識とチューニング

割とOS周りが詳しく記述されているがポイントだけ。Linux周りがまだ分からないことだらけなのでもっと学びたい。

- Linux Kernelの基礎知識
  - カーネル空間 / ユーザー空間
    - System Callを発行する側（アプリケーションやブラウザなど）: ユーザー空間
    - System Callを受け取ってハードウェアを制御する側: カーネル空間
  - プロセス
    - ユーザー空間で実行中のプログラム単位（Webサーバー等）
  - init / systemd
    - Linuxにはinitという親プロセスがありその下に子プロセスが紐づく（initの実装は最近systemdが多い）
  - コンテキストスイッチ
    - 複数のプロセスを動作させるため、超高速でプロセスを切り替えることで擬似的に複数プロセスが同時に動作しているように見せる => コンテキストスイッチ
  - ディスクI/O
    - 逐次読み書き: シーケンシャルリード / ライト
    - 現代では保存領域を上から逐次読み書きするのは現実的ではなくランダムリード/ライトが重視
  - I/Oスケジューラ
    - ディスク読み書き制御用パラメータ
    - Ubuntu20.04では、mq-deadlineスケジューラが採用
  - ファイルディスクリプタ
    - プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子
    - プロセス側からOSに対してこの識別子を指定することで読み書きできる
  - UNIX domain socket
    - 同じホスト内の別プロセスに対して高速にデータを送受信する仕組み
    - 同じホスト内であることが前提のためネットを介さないことを活かした高効率な通信。

## まとめ

パフォーマンスチューニングの書籍だけれど、ミドルウェアの設計やアーキテクチャの基礎知識に対する説明が丁寧にされていたのが好印象。

`Covering Index`の概念を知れたのはよかった。Linux周りがまだ分からないことだらけなのでもっと学びたい。あとCDNも。


Kdevlog

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

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

<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

SetとArrayのinclude?の違い

<書評> 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践

Kdevlog

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

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

<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

SetとArrayのinclude?の違い

<書評> 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践

<書評> 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践