
## 概要

仕事で新しい社内アプリケーションを作る機会があり、`Cloudformation`を使って0から`AWS`インフラを構築したので、振り返りも兼ねてやってきたことや苦労したことをまとめる。

## 技術スタック

- `Rails` 7系
- `Ruby` 3系

社内の技術ナレッジ的に`Rails`がベストなのでそちらを採用していた。

## やったこと

大まかにやったことは下記の通り。

1. `AWS`リソース構成図を書く
2. `Cloudformation`でざっくりとリソースを定義
3. `Cloudformation`をデプロイしてスタックを作りながら微調整
4. `Dockerfile`を本番用にビルドして`ECR`にpush
5. スタックを更新してアプリケーションが動くように微調整
6. ドメインの取得と`SSL`化

### 1. AWSリソース構成図を書く

`Fargate`でWebアプリケーションを動作させて、DBは`RDS`を利用するシンプルな構成。

`Gateway`があって、`LoadBalancer`を挟んでトラフィックを受け入れる形。

ひとまず下図のような形になった。

![AWS構成図](/images/aws_resouce_image.png)

### 2. Cloudformationでざっくりとリソースを定義

`Cloudformation`で大まかにリソースを定義していった。

`ChatGPT`やサンプルテンプレートを参照してリソースを定義し、公式docを見ながら正しいこと確認する流れで進めた。

&nbsp;

`ChatGPT`が出力したリソース例だと割とエラーになるケースが多く、公式docをベースにしつつエラーが起きた場合だけ、`ChatGPT`に聞きつつ進めるという形に落ち着いた。

特にAWS公式が出している下記の`ECS`テンプレートスニペットはかなり重宝した。

refs. [https://docs.aws.amazon.com/ja_jp/AWSCloudformation/latest/UserGuide/quickref-ecs.html](https://docs.aws.amazon.com/ja_jp/AWSCloudformation/latest/UserGuide/quickref-ecs.html)

### 3. Cloudformationで作成したリソース定義をもとにスタックを作りながら微調整

作成したリソース定義をもとにスタックを作りながら動作等を微調整していった。

スタック作る過程で`RDS`のリソース作成はかなり時間がかかるということが分かってきた。（それはそう）

そのため、`RDS`と`ECS`は別々でリソース作成するように進め方を変更した。

&nbsp;

まず、`RDS`単体のリソース単体で作成できることを確認し、その後`ECS`単体のリソース作成を確認。

最後に両者を紐づけていく流れにしていった。

#### 3-1. RDS周り

今回のアプリケーションは`I/O`負荷等が高くないので、`RDS`は小さめの構成を選択した。

`RDS`インスタンスのクラスも小さめだし、ストレージタイプも小さいものを選んだ。マルチAZもなし。

refs. [https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage)

#### 3-2. ECS周り

`ECS`のリソースを定義する過程で下記のようなエラーに遭遇し、`CloudTrail`や`CloudWatch Logs`等を確認しつつ対応していった。

- `ECS`のタスク実行ロールにポリシーが足りないためスタック作成時にエラー
- ゲートウェイがデタッチできないエラー

### ECSのタスク実行ロールにポリシーが足りないためスタック作成時にエラー

`ECS`タスク実行ロール権限を付与したロールを作成し、`ECS`のタスクから各AWSリソースにアクセスするためにポリシーを付与。

最初は、AWS管理の `AmazonECSTaskExecutionRolePolicy`を付与すればすんなりいけるのかなと思っていたが、中身を見てみると `CloudWatch Logs` のWrite、`ECR` のReadしか許可されていなかった。

&nbsp;

そのため、追加で`RDS`や`S3`、`Systems Manager`などのリソースにアクセスできるようにポリシーを付与した。

今回は利用しなかったが、`CloudTrail`イベントに基づいてポリシーを生成できる機能が便利そう。

### ゲートウェイがデタッチできないエラー

```plaintext
Network vpc-xxxxxxxx has some mapped public address(es). Please unmap those public address(es) before detaching the gateway.
```

大幅なスタック変更を反映しようとすると、`Internet Gateway`がデタッチできず`Cloudtrail`で上記のエラーが出ていた。

どうやら、スタックを作り替える際に`VPC`からパブリックIPをアンマッピングする前に`Internet Gateway`をデタッチしようとしているよう。

&nbsp;

下記の記事でも同じエラーに遭遇していた。

記事によると、一度リソースを削除してみるしかないようで、削除したら解決した。

refs. [https://hyp0th3rmi4.medium.com/aws-Cloudformation-adventures-part1-build-your-own-vpc-d3f6d990d1fd](https://hyp0th3rmi4.medium.com/aws-Cloudformation-adventures-part1-build-your-own-vpc-d3f6d990d1fd)

&nbsp;

この作業を通じて `NAT Gateway`の存在を知った。

`NAT Gateway` は `Private Subnet`内のインスタンスからネットワーク接続するためのアドレス変換サービスのよう。

### 4. Dockerfileを本番用にビルドしてECRにpush

`Dockerfile`は事前にビルドして`ECR`に格納した上で利用していたが、そのイメージが正しくなかったので修正した。

`docker-compose.yml`側に寄せていたため、`Dockerfile`単体のイメージにリポジトリのファイルがマウントされておらず、そのまま`ECS`にあげても `rails Command not found`となってしまっていた。

そのため、本番環境用に`Dockerfile`を作り直してビルドした上で利用した。

&nbsp;

その際にやったことをリストにまとめると下記のようになる。

- `Systems Manager`で環境変数を渡すようにする
- イメージビルドと同時に`precompile`しておく
- `AWS_ACCESS_KEY`などの秘匿情報は渡さずにECSタスク実行ロールにポリシーを付与
- `SECRET_KEY_BASE`の渡し方を工夫する
- `Dockerfile`で`x86_64`のプラットフォームを指定
- `ENTRYPOINT`を追加し`shell`スクリプトでサーバー起動

#### 4-1. Systems Managerで環境変数を渡すようにする

元々`docker-compose.yml`に環境変数をベタ書きしていた。

プライベートリポジトリだから漏洩リスクが低いことと、スピード感を優先した結果、そういう構成になっていた。

&nbsp;

ただ、`Dockerfile`のイメージに環境変数を含めるのはリスクなので、`Systems Manager`のパラメータストアに格納した環境変数を利用するようにした。

#### 4-2. イメージビルドと同時にprecompileしておく

当初はコンテナ起動時にサーバー起動と一緒に`precompile`をしていた。

ただ、それだと後々起動に時間がかかってしまうというレビューをいただき、イメージビルド時に`precompile`することにした。

#### 4-3.AWS_ACCESS_KEYなどの秘匿情報は渡さずにECSタスク実行ロールにポリシーを付与

ローカルで`S3`と接続する際に `AWS_ACCESS_KEY_ID`などを環境変数で渡していた。

環境変数をパラメータストアから注入する形にすると、事前にローカルでイメージビルドする際に`precompile`でこける。(`AWS_ACCESS_KEY_ID`がないため)

&nbsp;

そもそも本番環境で`S3`にアクセスさせるために、`AWS_ACCESS_KEY_ID`など必要ではなく、ECSタスク実行ロールに`S3`へのアクセスポリシーを付与すれば良いというレビューをいただいた。

&nbsp;

そのため、ローカル環境なら`AWS_ACCESS_KEY_ID`を環境変数として利用し、本番環境ではポリシー付与することで該当の環境変数を不要にした。

#### 4-4. SECRET_KEY_BASEの渡し方を工夫する

`precompile`を成功させるには`SECRET_KEY_BASE`の環境変数が必要になる。

当初は`RUN --mount=type=secret`を使って`SECRET_KEY_BASE`の秘匿情報を渡していた。

refs. [https://docs.docker.com/engine/reference/builder/#run---mounttypesecret](https://docs.docker.com/engine/reference/builder/#run---mounttypesecret)

&nbsp;

しかし、`RoR`の下記issueを確認したところ、そもそもビルドステップ時において本物の`SECRET_KEY_BASE`を渡す必要がないとのことで、`dummy`の値を渡すように変更した。（buildのコマンドも短くなってスッキリする）

refs. [https://github.com/rails/rails/issues/32947#issuecomment-470380517](https://github.com/rails/rails/issues/32947#issuecomment-470380517)

&nbsp;

また、ビルド時に`production`という変数を渡せば`precompile`するし、そうでなければしないようにすることで、ローカル環境と本番環境で`Dockerfile`を併用できるようにした。

#### 4-5. Dockerfileでx86_64のプラットフォームを指定

`M1 Mac`だとビルドすると`arm`のイメージが作成されてしまい、`ECS`タスク起動時に下記エラーが吐かれる。

```plaintext
[FATAL tini (8)] exec /bin/sh failed: Exec format error
```

ECSタスクのデフォルトアーキテクチャは`x86_64`なので、そちらに合わせて`Dockerfile`内でプラットフォームを`x86_64`に指定した。

#### 4-6. ENTRYPOINTを追加しshellスクリプトでサーバー起動

当初は`Cloudformation`のECSタスク定義の`Command`オプションにサーバー起動のコマンドを記述していた。

ただ、`ECS`タスク起動時に`Dockerfile`の`ENTRYPOINT`が実行されると公式ドキュメントに記載されていたのでそちらに変更。

`ECS`タスク起動時に`docker run`するから実行されるとのこと。

refs. [https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/task_definition_parameters.html](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/task_definition_parameters.html)

### 5. スタックを更新してアプリケーションが動くように微調整

ここまできたらアプリケーションが動くかなと思っていたが、タスク起動時にヘルスチェックに失敗し続けていた。

ヘルスチェックのエンドポイントがなかったのでコケ続けていたため、`ELB`のタイムアウト設定を追加(`HealthCheckIntervalSeconds`など)して、専用のエンドポイントを設定したところ、ヘルスチェックに成功した。

&nbsp;

また、`ActionView::Template::Error (The asset "application.css" is not present in the asset pipeline.)`エラーが出たので、`RAILS_SERVE_STATIC_FILES`の環境変数を正しく設定した。

&nbsp;

さらに、コンテナ側では80番ポートを開けているのに、`Rails`サーバー起動時に3000番ポートで動かしてしまいエラーが出たので、ポートを80番で起動させるように修正した。(ローカルのやつそのままコピペしてた)

&nbsp;

加えて、`RDS`起動後に`ECS`を立ち上げるように`DependsOn`で立ち上げ順序の指定を行うなどした。

### 6. ドメインの取得とSSL化

- ドメインの取得
- ドメインに`LB`を割り当て
- `SSL`化

基本的に下記の記事を参考にして行った。

refs. [https://qiita.com/NaokiIshimura/items/654f1f82adb039f1ad47](https://qiita.com/NaokiIshimura/items/654f1f82adb039f1ad47)

#### 6-1. ドメインの取得

`Route53`でドメイン名を取得した。円安....

#### 6-2. ドメインにLBを割り当て

`ECS`と紐づいている`LB`にドメインを割り当てることで、ドメイン名を入力してアクセスできるようになる。

#### 6-3. SSL化

`ACM`にて証明書の発行リクエストを行い、`LB`に紐づいている`Security Group`のインバウンドルールに`HTTPS`での通信を許可し、`LB`のリスナーに`HTTPS`を追加すればOK。

## デバッグについて

基本的には記述した`Cloudformation`で`stack`を作成しイベントログや`CloudTrail`を参照してリソース作成時のエラーを確認。

アプリケーション立ち上げ時には、`CloudWatch Logs`を確認していた。

また、必要に応じて下記コマンドで`ECS`タスク内部に入ってファイル等を確認することを行った。

```plaintext
$ aws ecs update-service --region region-name --cluster cluster-name --service service-name --enable-execute-command
```

&nbsp;

上記のコマンドで`ECS`クラスター内のサービスでコマンド実行を可能にする。

```plaintext
$ aws ecs describe-services --cluster cluster-name --services service-name | jq '.services[].enableExecuteCommand'
```

&nbsp;

上記のコマンドでクラスター内のサービスでコマンド実行が可能状態かどうか確認。

```plaintext
$ aws ecs update-service --force-new-deployment --service service-name --cluster cluster-name
```

&nbsp;

上記のコマンドでクラスター内のサービスで強制デプロイをかけることで、コマンド実行可能なタスクが作成される。

```plaintext
$ aws ecs execute-command --region region-name --cluster cluster-name --task task-name --container container-name --interactive --command "/bin/sh"
```

その上で新規作成したタスク名を指定して。コマンドを実行することでコンテナに入る。

`RDS`に接続して`DB`が作成されているかどうかなど確認した。

## デプロイについて

1. イメージをビルド
2. `ECR`にpush
3. タスクの新規登録
4. `ECS`サービスの更新

### 1. イメージをビルド

```plaintext
$ docker build -t image-name:version -f Dockerfile . --build-arg RAILS_ENV=production
```

`RAILS_ENV`の引数を渡したら`precompile`が走るようになっている。

&nbsp;

```plaintext
$ docker tag image-name:version *******.dkr.ecr.ap-northeast-1.amazonaws.com/repository-name:version
```

イメージにタグを付与する。

### 2. ECRにpush

```plaintext
$ aws ecr get-login-password --region resion-name | docker login --username user-name --password-stdin ********.dkr.ecr.resion-name.amazonaws.com
```

`ECR`にログイン

&nbsp;

```plaintext
$ docker push **********.dkr.ecr.resion-name.amazonaws.com/repository-name:version
```

`ECR`にイメージpushする。

### 3. タスクの新規登録

```plaintext
$ aws ecs register-task-definition --family family_name --cli-input-json "$(aws ecs describe-task-definition --task-definition task_definition_name:{$number} | jq '.taskDefinition' | jq 'del(.taskDefinitionArn, .revision, .status, .requiresAttributes, .compatibilities, .registeredBy, .registeredAt)')"
```

`jq`を使って`describe-task-definition`で取得したタスク定義から不要なものを取り除いた上で新規のタスクを登録している。

&nbsp;

下記の記事にもあるように、`describe-task-definition`で取得したタスク定義の`JSON`はそのままだと登録できず、不要な項目を省いて登録する必要がある。

refs. [https://dev.classmethod.jp/articles/describe-task-definition-to-register-task-definition/](https://dev.classmethod.jp/articles/describe-task-definition-to-register-task-definition/)

### 4. ECSサービスの更新

```plaintext
$ aws ecs update-service --cluster cluster-name --service service-name --task-definition task_definition_name:{$number}
```

3のコマンドを実行すると、`JSON`が返却されてタスク定義名が返却されるので、そちらを指定して`ECS`を更新する。

そうすることで、新しいタスクが実行されてデプロイが完了する。

## まとめ

0から`AWS`リソースを構築することができたのはとても良い経験になった。

社内の既存アプリケーションのインフラはコード化されておらず、今回のアプリケーション作成を通じて`IaC`の基盤を構築できたということも一つ成果として挙げられる。

&nbsp;

インフラ構築は経験したことがなかったので、最初はリソースの調査をしつつ、1つ1つ定義していった。

`stack`の作成・更新を通じてエラーが出てそれを直すという繰り返しで、エラー駆動で進めていた。

&nbsp;

エラーの原因がよく分からないとなった時は、どこのリソースまで定義したらエラーになるんだっけ等、問題の分割ができるのも新しい発見だった。

`AWS`コンソール画面で手動作成するのではなく、`Cloudformation`を使ったからそれがやりやすかったのではないかという印象を受けている。

社内でインフラに精通しているエンジニアの方にアドバイスももらいつつ進められた。この場を借りて改めて感謝したい。


Cloudformationを使って0から社内アプリケーションのAWSインフラを構築した


## 概要

仕事でVPCピア機能を使ってピアリング接続してみたまとめ

## やりたかったこと

同じリージョンにある、別のAWSアカウント上のVPC間でインターネットを介さずプライベートIPを使用して、通信を行いたかった

=> AWS VPCピア機能というものがあることを知る

## VPCピア機能とは

AWS VPC間でプライベートIPを使用してトラフィックをルーティングできるようにする機能

https://docs.aws.amazon.com/ja_jp/vpc/latest/peering/what-is-vpc-peering.html

## やったこと

1. リクエスタVPCにてピアリング接続を作成(アクセプタVPCに接続確立要求)
2. アクセプタVPCでリクエスタVPCからの接続要求を承認
3. リクエストVPCにてルートテーブルにアクセプタVPCのIPアドレスを追加(アクセプタVPCでも同様)
4. 各EC2のセキュリティグループに通信許可を設定
5. リクエスタVPCのEC2からアクセプタVPCのEC2にHTTPリクエストが行えることを確認

## 所感
プライベートIPでの疎通設定がこんなに簡単にできるとは思わなかった

作業している中でVPCのResource mapがかなり便利だなということを再認識した

以前はVPCとサブネット、ルートテーブルの関連性が把握しにくかった


AWS VPCピア機能を使ってみた


## 概要

仕事で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コネクションプールサイズについて


## 概要
失敗から学ぶRDBの正しい歩き方を再度読み直したら、MySQLのギャップロックとネクストキーロックの理解が曖昧になっていたので、復習がてらまとめてみた


## ギャップロック
ギャップロックとは

> ギャップロックは、インデックスレコード間のギャップのロック、または最初のインデックスレコードの前または最後のインデックスレコードの後のギャップのロックです。 たとえば、SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;では、範囲内の既存のすべての値間のギャップがロックされているため、カラムにそのような値がすでに存在するかどうかにかかわらず、他のトランザクションが 15 の値をカラム t.c1 に挿入できなくなります。

https://dev.mysql.com/doc/refman/8.0/ja/innodb-locking.html#innodb-gap-locks


存在しない単一レコードの取得や削除、範囲指定でレコード取得などを行う場合に発生する。

### 具体例
下記のようなテーブルを考える。

```plaintext
mysql> desc test;
+-------+--------------+------+-----+---------+----------------+
| Field | Type         | Null | Key | Default | Extra          |
+-------+--------------+------+-----+---------+----------------+
| id    | int          | NO   | PRI | NULL    | auto_increment |
| value | varchar(256) | NO   |     | NULL    |                |
+-------+--------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)

mysql> select * from test;
+----+-------+
| id | value |
+----+-------+
|  1 | foo   |
|  5 | test  |
|  6 | test  |
|  8 | baz   |
|  9 | baz   |
+----+-------+
```

#### 存在しない単一レコードの取得/削除

トランザクションAで存在しないレコードを取得(空振り)すると、id=2..4にギャップロックが発生する。

id=3を中心にして、存在するレコードのid=1,5の間は全てギャップロックされる。

削除の場合も同じ事象。

##### トランザクションA

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select test from a where id = 3 for update;
Empty set (0.00 sec)
```

##### トランザクションB

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

# トランザクションAのギャップロックによって待機が発生
mysql> insert into test values (2,"test");
mysql> insert into test values (3,"test");
mysql> insert into test values (4,"test");
```

#### 範囲指定でレコード取得

範囲指定でレコードを取得した場合、存在しないレコード列までギャップロックするので、先ほどと同じようにINSERTするとロック待ちが発生。

トランザクションAでid=5..9を範囲指定して取得すると、id=6,7もギャップロックされる。

そのため、トランザクションBでロック待ちが発生する。

また、ギャップロックは競合しないのでレコード取得は可能。

##### トランザクションA

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test where id between 5 and 9 for update;
+----+-------+
| id | value |
+----+-------+
|  5 | bar   |
|  8 | baz   |
|  9 | baz   |
+----+-------+
3 rows in set (0.00 sec)
```

##### トランザクションB

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

# トランザクションAのギャップロックによって待機が発生
mysql> insert into test values (6,"test");

# ギャップロックは競合しないので取得は可能
select * from a where id = 6 for update;
```

### ネクストキーロック

ネクストキーロック = レコードロック + ギャップロック

> インデックスレコードのレコードロックと、インデックスレコードの前のギャップのギャップロックの組み合わせです。

https://dev.mysql.com/doc/refman/8.0/ja/innodb-locking.html#innodb-next-key-locks

ギャップロックでロックした後、次の実レコードが存在する行をレコードロックしたものがネクストキーロックになる。

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test where id < 4 for update;
+----+-------+
| id | value |
+----+-------+
|  1 | foo   |
+----+-------+
1 row in set (0.00 sec)
```

```plaintext
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

# id=1はレコードロックがかかっているのでロック待ち
mysql>　select * from test where id = 2 for update;

# id=2 はギャップなのでギャップロックがかかるが、ギャップロックは競合しないので取得可能
mysql> select * from test where id = 2 for update;
Empty set (0.00 sec)

# id=3はギャップロックがかかっているのでロック待ち
mysql> insert into test values (3,"test");

# id=5はid=2-4の次に存在するレコードなので、ネクストキーロックがかかっているのでロック待ち
mysql>　select * from test where id = 5 for update;

# id=6は今回ロックされたギャップではないのでinsert可能
mysql> insert into test values (6,"test");
Query OK, 1 row affected (0.00 sec)
```

## ロックの存在理由
ファントムリード(他のトランザクションで挿入してコミットしたレコードを読み込めてしまう)の発生を防ぐため。

InnoDBのデフォルトのトランザクション分離レベルは、`REPEATABLE-READ`なのでそれが発生しないようにするためのロック。

`READ COMMITTED`場合は、ギャップロックを無効にできる。

https://dev.mysql.com/doc/refman/8.0/ja/innodb-locking.html#innodb-gap-locks


## 所感

Railsアプリケーションでギャップロックを発生させるようなコードを書いて、指摘をもらったことを思い出した。

不要なレコードを定期的に削除して3ヶ月分だけ残すためのworkerを実装していて、下記のようなクエリを書いていた。

```ruby
Model.where(created_at: ..Time.zone.now.ago(3.month)).limit(1000).delete_all
```

これがslow queryになっていたので、id直指定で取ってきてdelete_allするように修正した。

これにより存在するレコードだけを取得してギャップロックを発生させないようにしたのを思い出した。

```ruby
ids = Model.where(created_at: ..Time.zone.now.ago(3.month)).limit(1000)
return if ids.blank?
Model.where(id: ids).delete_all
```


InnoDBのギャップロックとネクストキーロックについておさらい


## 概要

半年前とかに読んだ[Java言語で学ぶデザインパターン入門第3版](https://www.hyuki.com/dp/) 感想まとめ

サンプルコードは書き慣れたTSで記述している(Javaは書き慣れていないので)

参考: [https://github.com/torokmark/design_patterns_in_typescript](https://github.com/torokmark/design_patterns_in_typescript)

## Adapterパターン

クラスのインターフェイスを、クライアントが期待する別のインターフェイスへ変換を実現するパターン

互換性のないインターフェースのためにできなかったクラス同士の連携が可能になる

## Singletonパターン

インスタンスが1つしか存在しないことを保証するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton](https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton)

#### Singletonパターンの定義

- コンストラクタは外部に公開しない
  - `new Singleton`が外部から不可能になる
- インタンス取得用のメソッドのみ外部公開する
  - 内部実装的にはFactory Methodのようになっている
  - インスタンスがすでに作成済み確認する

```typescript
namespace SingletonPattern {
  export class Singleton {
    private static singleton: Singleton;
    private constructor() {}
    public static getInstance(): Singleton {
      if (!Singleton.singleton) {
        Singleton.singleton = new Singleton();
      }
      return Singleton.singleton;
    }
  }
}
```

#### 呼び出し

```typescript
namespace SingletonPattern {
  export namespace Demo {
    export function show(): void {
      const singleton1 = SingletonPattern.Singleton.getInstance();
      const singleton2 = SingletonPattern.Singleton.getInstance();
      if (singleton1 === singleton2) {
        console.log('two singletons are equivalent');
      } else {
        console.log('two singletons are not equivalent');
      }
    }
  }
}
```

## Prototypeパターン

新しいインスタンスを作る際にクラスではなく既存のインスタンスから複製するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype](https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype)

#### Prototypeパターンの定義

- 複製対象クラスは自身を複製できるcloneメソッドをインターフェースとして持っている
- Builderクラスに複製対象クラスを表す文字列(ex. c1)を渡すと透過的に複製できる

```typescript
namespace PrototypePattern {
  export interface Prototype {
    clone(): Prototype;
    toString(): string;
  }

  export class Concrete1 implements Prototype {
    clone(): Prototype {
      return new Concrete1();
    }

    toString(): string {
      return 'This is Concrete1';
    }
  }

  export class Concrete2 implements Prototype {
    clone(): Prototype {
      return new Concrete2();
    }

    toString(): string {
      return 'This is Concrete2';
    }
  }

  export class Builder {
    private prototypeMap: { [s: string]: Prototype } = {};

    constructor() {
      this.prototypeMap['c1'] = new Concrete1();
      this.prototypeMap['c2'] = new Concrete2();
    }
    createOne(s: string): Prototype {
      console.log(s);
      return this.prototypeMap[s].clone();
    }
  }
}
```

### 呼び出し

```typescript
namespace PrototypePattern {
  export namespace Demo {
    export function show(): void {
      var builder: PrototypePattern.Builder = new PrototypePattern.Builder();
      var i = 0;
      for (i = 1; i <= 2; i += 1) {
        console.log(builder.createOne('c' + i).toString());
      }
    }
  }
}
```

### 所感

このコードでは複製時に`new`キーワード使っているので、生成コストは同じだと思った。

要件次第ではディープコピーを採用することになるので、そこのロジックは考えないといけないと思う。

また、生成時に複数のパラメータが必要な場合、生成コストはそこまで変わらないし、むしろ上がるのではと思う。

ただ、APIレスポンスをパラメータとしている場合は、複製する方がコスト低い(APIリクエストが発生しない)ので複製した方が良さそう。

## Abstract Factoryパターン

関連したオブジェクトの集まりを具象クラスを指定することなく生成できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory](https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory)

### Abstract Factoryパターンの定義

基本的に`Abstract.*`はインターフェースとして定義されており、メンバの集合体となっている

`Concreate.*`_は_`Abstract.*`のインターフェースの中身を定義している

`Abstract.*`では最終的に生成するオブジェクトの形式だけを決めておいて*、*`Concreate.*`でオブジェクトの実際の中身を返している

```typescript
namespace AbstractFactoryPattern {
  export interface AbstractProductA {
    methodA(): string;
  }
  export interface AbstractProductB {
    methodB(): number;
  }

  export interface AbstractFactory {
    createProductA(param?: any): AbstractProductA;
    createProductB(): AbstractProductB;
  }

  export class ProductA1 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA1';
    };
  }
  export class ProductB1 implements AbstractProductB {
    methodB = () => {
      return 1;
    };
  }

  export class ProductA2 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA2';
    };
  }
  export class ProductB2 implements AbstractProductB {
    methodB = () => {
      return 2;
    };
  }

  export class ConcreteFactory1 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA1();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB1();
    }
  }
  export class ConcreteFactory2 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA2();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB2();
    }
  }

  export class Tester {
    private abstractProductA: AbstractProductA;
    private abstractProductB: AbstractProductB;

    constructor(factory: AbstractFactory) {
      this.abstractProductA = factory.createProductA();
      this.abstractProductB = factory.createProductB();
    }
    public test(): void {
      console.log(this.abstractProductA.methodA());
      console.log(this.abstractProductB.methodB());
    }
  }
}
```

#### 呼び出し

- `ConcreteFactory1`や`ConcreteFactory2`はどちらも`AbstractFactory`型なので、結局どのFactoryなのかクライアント側で気にする必要はない
- 気にする必要があるのは、生成されたオブジェクトが`test`メソッドを持つということだけ
- 生成ロジックは隠蔽されている

```typescript
namespace AbstractFactoryPattern {
  export namespace Demo {
    export function show() {
      // Abstract factory1
      var factory1: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory1();
      var tester1: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory1);
      tester1.test();

      // Abstract factory2
      var factory2: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory2();
      var tester2: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory2);
      tester2.test();
    }
  }
}
```

### 所感

単一責任の原則に従っているし、クライアントと生成ロジックが密結合しないのはメリットだと感じた

ただ、関連するオブジェクトの集まりが少ない場合は、普通に`Factory Method`パターンで良いと思った

似たUIが複数生成する必要がある場合は、このパターンを採用しても良さそう

仮にこのパターンを採用する場合、コードが複雑になるのは避けられないので、トレードオフを丁寧に評価する必要がある

## Bridgeパターン

抽象部分と実装部分を切り離し、両者を独立して変更できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts](https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts)

### Bridgeパターンの定義

![image of bridge pattern](https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/44f2a99ed7a84cd0b44c1a37ccf0d420/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-05-21%209.47.35.png?w=1000&h=348)

- `Abstraction`は実装から独立した操作を定義したクラス
  - `Implementator`への参照を保持し、メソッドを定義
- `RefinedAbstraction.*`は`Abstraction`クラスの具体的なサブクラス
  - `Abstraction`クラスで定義したメソッドの具体的な動作を定義
- `Implementor`は抽象化から独立した操作を定義したクラス
- `ConcreteImplementor.*`は`Implementor`クラスの具体的なサブクラス
  - `Implementor`クラスで定義したメソッドの具体的な動作を定義

```typescript
namespace BridgePattern {
  export class Abstraction {
    implementor: Implementor;
    constructor(imp: Implementor) {
      this.implementor = imp;
    }
    public callIt(s: String): void {
      throw new Error('This method is abstract!');
    }
  }

  // ... 以下のコードは省略 ...
}
```

### 呼び出し

```typescript
namespace BridgePattern {
  export namespace Demo {
    export function show(): void {
      var abstractionA: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionA(
          new BridgePattern.ConcreteImplementorA(),
        );
      var abstractionB: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionB(
          new BridgePattern.ConcreteImplementorB(),
        );

      abstractionA.callIt('abstractionA');
      abstractionB.callIt('abstractionB');
    }
  }
}
```

### 所感

ここまでやるかは別として、抽象と実装を切り分けることで、コアロジックと詳細なロジックを分離できる点はメリットだと思う
それにより変更容易性がある程度担保されている
デザインパターンは単一責任の原則が色濃く出ているなと思う

## Strategyパターン

同じインターフェースだが振る舞い(アルゴリズム)をユースケースごとに分離して実行できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy](https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy)

### Strategyパターンの定義

- それぞれの振る舞い(アルゴリズム)を`Strategy.*`クラスに分離する
- `Strategy.*`クラスは`Strategy`インターフェースを持つ
- `Context`クラスは渡された`Strategy.*`クラスを呼び出す

```typescript
namespace StrategyPattern {
  export interface Strategy {
    execute(): void;
  }

  export class ConcreteStrategy1 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy1 is being called');
    }
  }

  export class ConcreteStrategy2 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy2 is being called');
    }
  }

  export class ConcreteStrategy3 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy3 is being called');
    }
  }

  export class Context {
    private strategy: Strategy;

    constructor(strategy: Strategy) {
      this.strategy = strategy;
    }
    public executeStrategy(): void {
      this.strategy.execute();
    }
  }
}
```

### 呼び出し

```typescript
namespace StrategyPattern {
  export namespace Demo {
    export function show(): void {
      var context: StrategyPattern.Context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy1(),
      );

      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy2(),
      );
      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy3(),
      );
      context.executeStrategy();
    }
  }
}
```

### 所感

個人的にはかなり現実的なパターンだと考えている。

生成ロジックの分離に重きを置いたPrototypeやFactory、Bridgeパターンより、Strategyパターンのような振る舞いを分離する方がコスパよく変更の影響範囲を最小化できそうな気がしている。

最初からPrototypeやFactoryパターンなどを実装しているプロジェクトは少ないと思っていて、そうなるとStrategyパターンで振る舞いを分離して置いた上で他のデザインパターンを適用していくという考え方もあるのでは。

## まとめ

デザインパターンを愚直に適用するのは良くないけれど、考え方自体を知っておくのはとても有用だと思う。

残りのデザインパターンは別記事にまとめる。

- Compositeパターン
- Visitorパターン
- Facadeパターン
- Mediatorパターン
- Proxyパターン
- Commandパターン
- Interpreterパターン


Kdevlog

Cloudformationを使って0から社内アプリケーションのAWSインフラを構築した

AWS VPCピア機能を使ってみた

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

InnoDBのギャップロックとネクストキーロックについておさらい

<書評> Java言語で学ぶデザインパターン入門第3版第1弾

Kdevlog

Cloudformationを使って0から社内アプリケーションのAWSインフラを構築した

AWS VPCピア機能を使ってみた

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

InnoDBのギャップロックとネクストキーロックについておさらい

<書評> Java言語で学ぶデザインパターン入門第3版 第1弾

<書評> Java言語で学ぶデザインパターン入門第3版第1弾