
## 経緯

2024年6月に新卒入社して5年勤めた会社から、株式会社タイミーにジョインした。

試用期間が終わったタイミングでこの記事を残してみようと思う。

前職ではエンジニアマネージャーという役割まで任せていただいてとても感謝しているが、どうしても新しい挑戦がしたくなった。

今までの自分が培ってきた常識や慣習の外側で働きたいと思った。

将来的にCTOとして技術と経営をつなげたいと思っている。

そのために井の中の蛙は大海を知りたいと思って飛び出した。

自分がプロダクト開発を通じて実現したい世界観とマッチする企業が、株式会社タイミーだった。

深くはないけど自分の技術的ケイパビリティとビジネスサイドとのコミュニケーションを活かして、ミッション達成に向けて試行錯誤していく所存。


転職した


## 概要

仕事でAurora MySQLを3系にアップグレードで失敗してたくさんの学びを得たのでその振り返り

## 背景

Aurora MySQLのメジャーバージョンが標準サポートが終了するにあたって、社内のAurora MySQLを3系にバージョンアップグレードする必要があった。

## 対応流れ

1. 影響範囲の洗い出し
2. スケジュール決め
3. テスト環境にてテストのアップグレードを行う
4. 関係者にリスクと対応方針の説明会
5. 実施
6. 残対応

ざっくり上記の流れで進めていった。

## やったこと - タイムライン -

前提としてEC2のRailsアプリケーションがAurora MySQLとコネクションを確立している。

### 1. 影響範囲の洗い出し

MySQLコミュニティ公式のドキュメントや、AWSの公式ドキュメントを読み込んで影響範囲を調査していった。

https://dev.mysql.com/doc/refman/8.0/ja/upgrading-from-previous-series.html

https://dev.mysql.com/doc/refman/8.0/ja/mysql-nutshell.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html

自社のアプリケーションはtoBということもあり、COLLATIONに関する要件は高くないので特に設定等変えていない。

### 2. テストケースの用意と実施

テスト環境にて動作テストを行うためにテストケースを用意していった。

主要な機能のテストケースは特に丁寧にケースを洗い出して整理した。

テスト環境のAurora MySQLを3系にアップグレードして動作確認を進めていった。

### 3. アップグレード方法の検討

並行してアップグレード方法の検討をしていった。

当初はBlue/Green Deploymentを利用してアップグレードを考えていた。

その時はマルチAZのAurora MySQLはBlue/Green Deploymentできないと勘違いしており、インプレースアップグレードの検討をしていった。

ただ、事業部長などとも相談した結果、インプレースアップグレードだとサービスダウンの時間が長すぎるので別の方法を再検討した。

> その時はマルチAZのAurora MySQLはBlue/Green Deploymentできないと勘違いしており

レプリケーションを使ってエンドポイントで切り替える方が良いかと考えていたが、再調査の結果上記が勘違いと分かり、Blue/Green Deploymentを使ってアップグレードを実施することに決定。

＊マルチAZのRDSクラスターはBlue/Green Deploymentを利用できないが、AuroraクラスターはマルチAZであっても利用できる。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html#blue-green-deployments-limitations-general

### 4. パフォーマンステスト

パフォーマンステストのために本番のRDSをクローンしてデータをマスクしていった。

クローンDBをテスト環境のEC2に接続し直すと、CPU使用率が100%で高止まりしてしまいテスト環境で動かせなかった。

原因としてはEC2のスペックが本番と同等になっていないこと。

EC2のスペックを検討して構築しなおした上でテストする時間がなかったため、Green環境で`OPTIMIZE TABLE`を実行して実行計画を最適化した上で、移行後に遅いクエリがあったら適宜対応する方針で進めていった。

### 5. 移行テスト

Blue/Green Deploymentを利用して環境移行の動作確認を行なった。

確認してみると、Blue環境からGreen環境の切り替え時に10分間程度、Green環境のエンドポイントを参照できずにエラーとなる時間帯があった。

おそらくRails側でDBのコネクションキャッシュが効いている可能性があり、その時間はどうしてもサービスダウンせざるを得ないということ分かった。

### 6. 本番のBlue/Green環境作成

Blue/Green環境を作成し、Green環境で`OPTIMIZE TABLE`を実行した。

### 7. 本番移行

深夜時間帯に自分一人でBlue/Green Deploymentを行なった。

### 8. 移行後のスロークエリを修正

`COUNT(*)` 系のクエリや集計系のクエリが重すぎてタイムアウトするという問い合わせが多発。

データが多い企業は画面を開くとタイムアウトするという報告が上がってきていた。

まず、発行されているクエリの実行計画を確認して、他のデータを使って対象件数を絞り込めないか検討してhotfixでリリース。

さらにBIツールのクエリもタイムアウトしていたので、クエリの実行計画を確認しながらクエリを最適化したり、ヒント句を使ってINDEXを使うように指定したりして対応した。

### 9. 移行後にGlueジョブからRDSのリーダーインスタンスに接続できない

Glueジョブで集計処理を行っており、RDSのリーダーインスタンスに接続して集計している。

その集計処理がタイムアウトしてしまっており、集計数値が欠損する事象も発生した。

ひとまずライターインスタンスに接続して集計処理を再開させ、過去文のデータをもとにGlueジョブ動かし、欠損した集計数値の復旧を行った。

### 10. テスト用に作成したRDSの削除

テスト用に作成したRDSを削除する必要があったので削除していった。

ここで誤って本番RDSを誤停止してしまい、1時間ほどサービスダウンさせてしまった。

すぐに復旧させたが、エンジニア人生で中々経験できないミスをしてしまった。

## 次同じ失敗を起こさないために

- 移行タスクはPJとして複数人で進めていくこと
- インフラ更新系は複数人で作業すること
- パフォーマンステスト環境を用意しておくこと

ここまでの作業はほぼ自分一人で進めてしまっており、移行日も当初の予定より遅れて実施した。

自分がリーダーポジションであり、チームメンバーも自分以外ジュニアで、PMもおらずという状況だったので、自分一人で背負いすぎてしまった感じが否めない。

これをタスクとして捉えてしまったのが良くなかった。こういったタスクはPJとして複数人を無理にでもアサインして進めるべきだった。

そうすれば、移行前の準備作業や予定日調整を行えるリソースの余白が生まれていたと思う。

ただ、詰まるところ自分の調整力不足の無さを痛感したので、この教訓を次に活かしたい。


Aurora MySQL 3系へのアップグレードで失敗した話


## 概要

画面表示の速度を10倍にした際の振り返り

## 背景

サービスの成長に伴いクライアントが増えてきて、データ量も倍々で増えてきており、ある画面の表示速度がかなり遅くなっていた。

ローディング中のまま一向に必要な要素が表示されないという状況。

それにより作業効率が低下しており、課題として顕在化していた。

表示速度はデータ量によってばらつきがあるが、30秒ほど時間がかかっているケースもあった。

## 原因調査

そもそも該当画面でGraphQLのクエリが叩かれまくっていたのとN+1が起きていたので、他のエンジニアがN+1を修正していたが、それでもまだ遅かった。

コードを確認すると、画面表示するために必要なデータを全部取ってくるまでローディングをしていることが分かった。

画面構成要素の一部であるセレクトボックスの選択肢に表示するデータを全件取得しようとしていた。

下記のように`Promise.all`を使っているので、`Promise`が全解決するまでずっとローディング中のままになっていた。

```js
Promise.all([promise1, promise2, promise3]).then((val) => { ... })
```

しかも、ページネーション等も存在しておらず、全てのデータをセレクトボックスの数だけ持ってきてたので、データ量が増えればその分遅くなるという構造になっていた。

## 方針

上述の課題を解決するために下記の方針を立てた。

- 初回の画面表示は行いつつ、セレクトボックス側が描画されたタイミングでレコードを取得する
- 全件取得を避けるためにページネーションを用意

つまり、セレクトボックスの選択肢に必要なレコードは初回描画時に遅延ローディングする。

セレクトボックスごとにレコードを取得することで、APIリクエストを並列化させて全体のリードタイムを抑えつつ、ページネーションを用意して初回取得上限を設ける。

これによりセレクトボックスの選択肢が揃うまで、他の要素の設定（テキストボックス入力など）をしておける状態に持っていける。

&nbsp;

また、特定件数だけ取得して残りはページネーションを用意することで、大量にレコード取得してGraphQLのクエリが何回も発行されることを避けるようにする。（元々全件取得するために無限ローディングしていた）

まとめると、遅延ローディング + デマンドフェッチ。

上記方針で改善を進めていった。

## やったこと

- 描画時にレコードを取得して選択肢を格納するセレクトボックスコンポーネントの作成
  - 以下、遅延ローディングコンポーネント
- セレクトボックスでページネーションを導入
- `Promise.all`を剥がす
- GraphQLを用いた各種APIリクエストの調整

基本的にはセレクトボックスを新規作成して、`Promise.all`を剥がしていった。

### 遅延ローディングコンポーネントの作成

#### ライブラリのバージョンアップグレード

セレクトボックスのコンポーネントは [react-select](https://react-select.com/home) を使っていた。

`react-select`のセレクトボックスを使って遅延ローディングするには、`Async`のpropsを利用する必要があるようだったので、ライブラリのバージョンをアップグレードした。

その上で遅延ローディングのコンポーネントを作成してみたが、関数が発火せずレコードが取得できず調査が難航した。

#### OSSのコードを引っこ抜いて自前で実装

上述した通りうまく作成できなかったので、他のライブラリで実現できないかを調査した。

調査したところ、[react-select-async-pagenate](https://www.npmjs.com/package/react-select-async-paginate)が利用できそうだった。

しかし、リリースノートやタグが切られておらず、破壊的な変更がサイレントで入ってくるリスクがあったので採用できず。

そのため、同ライブラリのコードの中身を引っ張ってきて自前で実装する決断をした。

&nbsp;

https://github.com/vtaits/react-select-async-paginate/blob/52f2e2f0fe99f57bb8536b202ecda409a558b9a5/src/index.jsx

上述のURLは同ライブラリの遅延ローディングの部分であり、クラスコンポーネントで実装されている。

それを関数コンポーネントに直しつつ微調整していった。

最初は難しいかもなと思っていたが、そんなに難しいことはなく初回描画時にAPIリクエストして、stateに詰めているだけなので思ったより簡単。

#### ページネーションを実装

上述したコンポーネントを作成後、そのコンポーネントにページネーションの仕組みを導入した。

リストを最後までスクロールするとGraphQLクエリを発行して次ページを取得するようにした。

加えて、入力値を用いてリスト検索した場合、GraphQLクエリを発行して取得するように実装した。

これにより、無限ローディングを剥がして、デマンドフェッチの仕組みを実装した。

#### 余談

本アプリケーションのフロントエンドはリポジトリパターンで構築されている。

画面描画時の親コンポーネントで必要なデータを取得するために、リポジトリ層を呼び出してレコードを取得している。（ユースケース層を呼び出した方が良いと思うが）

それによって、親コンポーネントのimportがどんどん増えていき、ファイル行数がかなり多くなっており、見通しが悪い状態。700くらいだった。

それが気持ち悪かったので、それを解消するためにレコードを一覧取得する関数だけまとめたファイルを作成して、それをimportする形に変更した。

150くらいファイル行数が減っただけでなく、データ取得の責務をそちらのファイルに分割できた。（神クラスみたいにならないよう運用する際の注意が必要。）

### 小さくデプロイ

コンポーネント自体が完了した後、既存のセレクトボックスを徐々に書き換えるために小さくデプロイをし続けた。

影響範囲を小さく保ち不具合を起こさないようにするため。

全部で20回くらいデプロイしたが、不具合を起こしたのは1回だけだった。（0に抑えたかったが）

### フロントエンドのコンテナがメモリ不足で落ちる問題を解消

開発時にメモリ不足でコンテナが落ちまくっており、~~流石に腹が立って~~ 改善チャンスだったので対応した。

10行くらいファイルを変更して反映を待っていたら、コンテナが`heap out of memory`で毎回落ちていた。

どうやらwebpackがホットリロード時に変更対象ファイルを検知してメモリに載せすぎていたよう。`node_modules`まで検知しようとしていた。

また、webpackのビルド結果をキャッシュするように設定を追加した。

この変更により問題がかなり解消された。

## 結果

レコード数によってまちまちだったが、遅い企業様で画面表示されるまで約25秒かかっていたところを、約1-2秒までに短縮した。

1-2秒は全企業様で固定値だったので、かなり改善できた。

## 開発リードタイムを早めるためにできたこと

- 最初からOSSのコードを参考にする
- コンテナ落ちる問題を早めに対処しておくべきだった
- レビュー会の実施

### 最初からOSSのコードを参考にする

最初は、海外のエンジニアがブログ等に載せているコードを参考に検証を進めていたが、うまく動かなかった。

OSSコードを参考にして検証した方がより確実に動くし早かった。

OSSへの敷居の高さみたいなものを感じていたのと、おそらく自身が読み解くのに面倒さを感じてしまっていた。

カジュアルな内容をもとに簡単に実装できたら良いなという願望のもとに動いていた気がする。

検証段階こそ正確な情報を参照すべきだと痛感した。

### コンテナ落ちる問題を早めに対処しておくべきだった

開発時間の1/4はコンテナ再起動に使っていたかも。

最初は原因がわからずに後回しにしていたが、早い段階から着手しておけばよかった。

本筋以外だとどうしても優先度が下がってしまいがちだが、そこの時間を測ってインパクトを定量化しておくべき。

### レビュー会の実施

20回もデプロイするくらいなのでPR数も多くなっていた。

レビューリードタイムを削減するために、周りを適切に巻き込む必要があった。

ある程度の規模の開発をレビューするとなると、口頭で確認しあうタイミングを設けないとリードタイム削減はしにくいなと感じた。

コンテキストを埋めるのが難しいだけでなく、そこに思考コストがかかるので後回しになりがち。

## まとめ

パフォーマンス改善のタスクってかなり達成感があるのでやっぱり好きだなと感じた。

ただ、この開発を通じて改善点を見つけられたので、今後に活かしていきたい。


画面表示速度を約10倍にした話


## 2023年総括

マネージャーというロールの大変さ・難しさを痛感した一年だった。

## 技術的にやったこと

- CloudformationでAWSインフラを構築した
- プライベートでGolangを触ってアプリを開発中
- OAuth2.0を完全に理解した

もっと技術的に色々したかったなという気持ちがある。

今年はOSS活動したいと思ってたけど、できていなかったし、なかなか時間取れていなかったな〜

&nbsp;

Cloudformationを触ってAWSインフラ構築をしたことで、フロント / バックエンド / インフラとフルスタックに触るという経験ができたのは一つ収穫だった。IaCのメリットを実感できたというのも大きい。

## その他・雑記

マネージャーというロールの大変さを痛感した。メンバーに任せるということの大事さと難しさ。

&nbsp;

応用情報技術者試験に合格した。スキマ時間うまく活用できたなと思う。

&nbsp;

今後の人生設計を考える上で大学に行きたいという気持ちが強くなってきたことは、一つの指針になってきそう。

&nbsp;

また、将来的にアーキテクトみたいな動き方をしていきたいと思い始めた。そのためにシステムだけでなく組織体制などにも知見を溜めたい。アーキテクチャってドメインやシステムだけでなく組織によっても規定されるような気がするので。

&nbsp;

あと、プレゼンスを高めていきたい。機会の最大化を目指したい。

なので、自分のブログだけでなくZennやXを積極的に活用しようと思う。コミュニティとの関わりももっと増やしていこうと思っている。

## 今年の目標

- OSS活動をする
- 個人開発で何かリリース
- ZennやXでアウトプットをする
- コミュニティと関わる
- 大学に行く


2023年振り返り


## 概要

Cloudformationで社内のインフラを構築した際に、GitHub ActionsでECS自動デプロイのワークフローを構築した際の振り返りを兼ねてまとめる。

## やったこと

GitHubがオフィシャルで出してるECSデプロイのサンプルワークフローをそのまま使った。

https://docs.github.com/en/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service#prerequisites

1. ECRにログイン
2. イメージビルドしてECRにpush
3. タスク定義を元にECSをデプロイ

環境変数やパスを指定し直すだけだったので本当にすぐできた。

タスク定義のJSONは、`containerDefinitions`配下のものを指定しないとダメなのは注意。

```plaintext
$ aws ecs describe-task-definition --task-definition task-definition-cfn:${number}
```

上記のコマンドでJSONをそのまま出力すると、下記のような構造になり、`taskDefinition`プロパティが邪魔をしてしまう。

```json
{
    "taskDefinition": {
        "taskDefinitionArn": "xxxxx",
        "containerDefinitions": [
            {
                "name": "xxxxx",
                "image": "xxxxx",
                ....
            }
        ]
    }
}
```

なので下記のようにして`taskDefinition`配下のJSONを出力する必要がある。


```plaintext
$ aws ecs describe-task-definition --task-definition task-definition-cfn:${number} | jq '.taskDefinition' > path/task-definition.json
```

## まとめ

GitHubがサンプルテンプレートを出していてありがとうという気持ち。
自動デプロイは本当に楽で良い。


Kdevlog

転職した

Aurora MySQL 3系へのアップグレードで失敗した話

画面表示速度を約10倍にした話

2023年振り返り

GitHub ActionsでECS自動デプロイのワークフローを構築した