@cosmeシステムの一部を AWSへ移行した際に躓いたこと&感想

アーリーとレイターのIT企業が語る「システムリプレイス」事例LT & 交流会の登壇資料です。
イベントURL: https://istyle.connpass.com/event/311938/

Transcript

1. © istyle Inc. 0 @cosmeシステムの一部をオンプレから
 AWSへ移行する際に躓いたこと&感想
 株式会社アイスタイル - 工藤 正隆（kudoma）
 No.0
2. © istyle Inc. 自己紹介
 No.1 工藤 正隆（kudoma）
 
 所属
 株式会社アイスタイル
 T&C開発センター
 第1開発本部 メディア開発部 メディア開発2グループ 
 
 主な役割
 バックエンド開発(2年半)、AWSへの移行(半年) 
 
 趣味
 海釣り、アニメ、筋トレ

3. © istyle Inc. Rebornプロジェクト
 No.2 近年、アイスタイルはRebornプロジェクトを進めている
 
 Rebornプロジェクトとは
 • インフラやDBレイヤの物理障害のコスト削減のために、オンプレからクラウドへ移行
 • システムの密結合状態による拡張性、柔軟性の阻害、管理、権限分離の阻害を解消
 • アプリケーションシステムのセキュリティレベル、耐障害性を上げるために推奨言語を設け、順次そ の言語に置き換え

4. © istyle Inc. Rebornプロジェクト
 No.3 近年、アイスタイルはRebornプロジェクトを進めている
 
 Rebornプロジェクトとは
 • インフラやDBレイヤの物理障害のコスト削減のために、オンプレからクラウドへ移行
 • システムの密結合状態による拡張性、柔軟性の阻害、管理、権限分離の阻害を解消
 • アプリケーションシステムのセキュリティレベル、耐障害性を上げるために推奨言語を設け、順次そ の言語に置き換え

5. © istyle Inc. Rebornプロジェクトのアプローチ
 No.4 インフラやDBレイヤの物理障害のコスト削減のために、オンプレからクラウドへ移行
 
 ★アプローチ
 AWSへのオールクラウド化

6. © istyle Inc. 移行したシステムの概要
 No.5 • Webアプリ
 • 記事作成
 • Nginx, PHP-FPM
 • 記事公開
 • Nginx, PHP-FPM
 • API
 • Nginx, PHP-FPM
 • バッチ

7. © istyle Inc. 6 オンプレからAWSへ移行する際に
 躓いたこと
 No.6
8. © istyle Inc. No.7 アプリケーション
 画像データ 移行
 パフォー マンス
 改善
 Cloud
 Front
 Amazon Linux 2
9. © istyle Inc. Amazon Linux 2
 No.8 躓き：
 オートスケーリンググループで新しいEC2インスタンスを起動した際に、CodeDeployのライフサイクルでヘ ルスチェックが30分終わらない
 
 原因：
 • /runディレクトリがtmpfsファイルシステムでマウントされていて、OSを再起動すると
 /run (=/var/run)配下は全て削除される
 • 結果php-fpmのソケットファイルを用意できず、php-fpmが正常に起動できなかった

10. © istyle Inc. Amazon Linux 2
 No.9 原因：
 • /runディレクトリがtmpfsファイルシステムでマウントされていて、OSを再起動すると/var/run配下は全 て削除される
 • 結果php-fpmのソケットファイルを用意できず、php-fpmが正常に起動できなかった
 
 解決：
 /etc/tmpfiles.d/hoge.confを作成し、以下を記述
 d /var/run/php-fpm 0755 root root
11. © istyle Inc. 画像データ移行
 No.10 躓き：
 現行オンプレをAWS CLIの実行環境にして、s3 syncで差分移行をしていた
 CPU使用率が100%に到達しそうで本番怖い
 
 解決：
 2枚窓にして片方top、片方s3 syncを実行して、負荷をリアルタイムで監視
 CPUが80%を超えそうになった瞬間、強制終了
 CPUが落ち着いたら再度実行！（※差分移行だからできることw）
 
 並列リクエスト数を抑える方法もあるらしいが、リリースまでに検証間に合わなかった

12. © istyle Inc. パフォーマンス改善 No.11 躓き：
 どんだけスケールアウト/スケールアップしてもエラー率/レスポンスタイムがよくならない

13. © istyle Inc. パフォーマンス改善 No.12 躓き：
 どんだけスケールアウト/スケールアップしてもエラー率/レスポンスタイムがよくならない
 
 調査結果：
 普段2~3秒で終わるクエリが、スパイク/ストレステストで2分かかっていた
 
 原因：
 CPUが100%に到達してる
 
 解決：
 スケールアップじゃね？

14. © istyle Inc. パフォーマンス改善 No.13 原因：
 インデックスが貼られてなくてフルスキャンしていた
 そのクエリがリクエストされすぎてパフォーマンスが落ちた
 
 解決：
 実行計画を見ながら、インデックスを貼っていく
 
 結果：
 エラー率が63.4％から1.2%まで落ち着いて、CPU使用率も落ち着いた

15. © istyle Inc. CloudFront - エッジキャッシュ No.14 やりたいこと：
 • APIレスポンスをキャッシュし、オリジンへの負荷を下げる
 • キャッシュ条件はクエリ文字列だけ
 • HTTPステータスコードが200の場合は3分間キャッシュされている

16. © istyle Inc. CloudFront - エッジキャッシュ No.15 キャッシュポリシーの設定

17. © istyle Inc. CloudFront - エッジキャッシュ No.16 ① 00:00:00
 初回アクセスだからキャッ シュヒットしない
 キャッシュヒット!
 ② 00:00:05

18. © istyle Inc. CloudFront - エッジキャッシュ No.17 ① 00:00:00
 初回アクセスだからキャッ シュヒットしない
 ② 00:00:05
 ③ 00:00:10
 どうなる？

19. © istyle Inc. CloudFront - エッジキャッシュ No.18 ① 00:00:00
 初回アクセスだからキャッ シュヒットしない
 キャッシュヒット!
 ② 00:00:05
 ③ 00:00:10
 キャッシュヒットしない 
 キャッシュヒット!
 ④ 00:00:15

20. © istyle Inc. CloudFront - エッジキャッシュ No.19 躓き：キャッシュがクライアント毎に異なる
 
 

21. © istyle Inc. CloudFront - エッジキャッシュ No.20 躓き：キャッシュがクライアント毎に異なる
 
 原因：
 Accept-Encodingリクエストヘッダーの値によりキャッシュが異なる
 
 例）圧縮サポートでBrotli, Gzipを有効にしていた場合
 CloudFrontは、Accept-Encodingリクエストヘッダーの値がbr, gzip, [なし] の3種類のリクエストを個別に キャッシュする

22. © istyle Inc. CloudFront - エッジキャッシュ No.21 キャッシュポリシーの設定

23. © istyle Inc. CloudFront - エッジキャッシュ No.22 ① 00:00:00
 初回アクセスだからキャッ シュヒットしない
 キャッシュヒット!
 ② 00:00:05
 ③ 00:00:10
 キャッシュヒットしない 
 キャッシュヒット!
 ④ 00:00:15
 Accept-Encoding: 
 gzip, deflate, br
 Accept-Encodingなし 

24. © istyle Inc. CloudFront - エッジキャッシュ No.23 解決：
 • Accept-Encodingをクライアントシステムの担当者と調整して統一する
 • 圧縮サポートなし
 
 実際のアプローチ：
 クライアントシステムでHTTPヘッダーを指定するために改修が必要なので、スケジュール優先で圧縮サ ポートをなし
 ただ、CloudFrontは転送量を減らすとコスト削減になるので、リリース後作業としてAccept-Encodingの統 一を進める

25. © istyle Inc. CloudFront×Nginx - 圧縮 No.24 やりたいこと：
 リリース時に圧縮しないにしろ、すぐ圧縮できるように検証しておきたい
 
 設定

26. © istyle Inc. CloudFront×Nginx - 圧縮 No.25 kudoma$ curl "https://hoge.fuga.net/aaa?test=1 " \ -H "Accept-Encoding:gzip" -I; HTTP/2 200 content-type: text/html; charset=utf- 8 date: Fri, 08 Mar 2024 05:13:25 GMT server: nginx x-cache: Hit from cloudfront via: 1.1 aaaaaaaaaaaaaaaaaaaaaaaaaa .cloudfront.net (CloudFront) age: 2 躓き：
 圧縮されていたらContent-Encodingレスポンスヘッダーが存在する
 圧縮されてない...

27. © istyle Inc. CloudFront×Nginx - 圧縮 No.26 原因：
 • CloudFrontがviaリクエストヘッダーを付与してNginxにリクエスト
 • Nginxはviaリクエストヘッダーがある場合、プロキシされたと判断する
 • プロキシされたリクエストに対する応答のGzip圧縮が無効になっていた
 
 解決：
 Nginxでgzip_proxiedをanyに設定する 
 ▶ 参考: Module ngx_http_gzip_module#gzip_proxied | NGINX

28. © istyle Inc. CloudFront×Nginx - 圧縮 No.27 kudoma$ curl "https://hoge.fuga.net/aaa?test=1 " \ -H "Accept-Encoding:gzip" -I; HTTP/2 200 content-type: text/html; charset=utf- 8 date: Fri, 08 Mar 2024 05:13:25 GMT server: nginx content-encoding: gzip x-cache: Hit from cloudfront via: 1.1 aaaaaaaaaaaaaaaaaaaaaaaaaa .cloudfront.net (CloudFront) age: 2 圧縮されてる！

29. © istyle Inc. CloudFront×Nginx - 圧縮 No.28 そもそもCloudFrontの自動圧縮はなぜ機能しないのか

30. © istyle Inc. CloudFront×Nginx - 圧縮 No.29 CloudFrontの自動圧縮はなぜ機能しないのか
 
 検証してないので本当かわからんですが、条件があるみたいです
 1. [オブジェクトを自動的に圧縮する] 設定がはいになっている 2. キャッシュポリシーを使用してキャッシュ設定を指定し、Gzip と Brotli の設定がどちらも 有効になっている 3. キャッシュポリシーの TTL 値が 0 より大きい値に設定されている ▶ 参考: 圧縮ファイルの供給 | aws

31. © istyle Inc. 30 感想
 No.30
32. © istyle Inc. 感想 No.31 AWS移行を完遂したので感想！
 • 上手くいかない時、前より見える範囲が広くなったから、1人で解決できることが増えた
 • ネットワークとかDNSとかなんとなくイメージできる
 • 手段がわからないタスクを完了できるようになった
 • ドキュメント作成ありがとうの気持ち
 • ものによると思うけど1回作れば他の人に貢献できるの素敵じゃない？✨
 • ドキュメント作成が定着できたのは、前任のPMがノウハウ共有会を週一でやっていたから
 • ハードルはめっちゃ下げてなんでも共有
 • アラート設定がないともう具合悪くなる（安心して寝れない）
 • AWS移行する前に、システムの理解度上げを絶対やった方がいいよ
 • 機能テストガバる→リリース後障害発生→障害解消に時間がかかる→夜ご飯が冷たい

33. © istyle Inc. No.32 あざした！